JP2002528968A - インテリジェントネットワーク - Google Patents

Abstract

(57)【要約】 遠距離通信スイッチングネットワーク、即ち、インテリジェントネットワークアーキテクチャ（１７０）は、遠距離通信サービス処理が可能な複数のノード（２０３）へのサービス資源を管理しかつ追跡するために、新しい中央管理装置（５００）と資源複合体（１８０）とを具備する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】

本発明は、一般的には電気通信ネットワーク、より具体的にはサービス資源を
電気通信サービス処理ができる複数のサービスノードに管理及び追跡するための
新規な中央管理及び資源管理システムを含むインテリジェントネットワークアー
キテクチャに関係する。

【０００２】

【従来の技術および発明が解決しようとする課題】

ネットワークサービスは、１つ以上の加入者とのインタラクションに反応して
、データや電話技術などの通信ネットワーク、及びその関連する資源により実行
する機能である。例えば、着信転送又はヴォイスメールアクセスなどの電話技術
ネットワーク常駐サービスは、特別な順序の数字をダイヤルすることにより加入
者が呼び出すことができる。他のネットワークサービスは、セキュリティ、妥当
性検証、及び認証に関してネットワークの所有者の支援に向けることができる。
サービスを追加したり変更したりするには、通信ネットワークに変更を行う必要
がある。

【０００３】 従来の電気通信ネットワークはほとんど、相互接続されるスイッチと通信サー
ビスとからなる。これらスイッチはスイッチのメーカーが設計する所有権を主張
できるソフトウェア又はファームウェアが操作する一体型もしくは埋込型プロセ
ッサにより制御される。典型的には、スイッチのメーカーのソフトウェア又はフ
ァームウェアは、サービス処理、呼出し処理、ファシリティ処理及びネットワー
ク管理の機能面すべてをサポートしなければならない。つまり、ネットワークの
所有者が新しいサービスを実現したり、既存のサービスを変更したい場合には、
ネットワーク内のすべてのスイッチのソフトウェアを様々なスイッチメーカーが
改訂しなければならない。

【０００４】 ネットワークには様々なメーカーからの様々なスイッチが含まれているという
事実のために、新しいソフトウェアの開発、試験及び配置を注意して行う必要が
ある。新しいソフトウェアの開発、試験及び配置のために要する時間は、各スイ
ッチのコードサイズがそれぞれの新たな改訂によりさらに大きく、複雑になるた
め、長くなる。そのため、このプロセスが数年もかかることがある。また、この
ように複雑さが増すと、さらにスイッチプロセッサの負担が増し、スイッチの誤
作動の機会が増え、スイッチを変更又は交換しなければならないことがある。

【０００５】 さらに、複数のネットワークの所有者が共通のスイッチメーカーに依存してい
るという事実のために、競争を制限する２つの好ましくない状況が生じる。まず
、メーカーのソフトウェアのリリースは複数のネットワークの所有者が要求する
変更を組込もうとするため、ネットワークの所有者が自分のサービスをその競合
者が提供するサービスと本当の意味で違いを持たせるのを阻害する。これはまた
、何社かのネットワークの所有者には、メーカーが他のネットワークの所有者か
らの要求を新リリースに組込むまで待たせることにもなる。また、あるネットワ
ークの所有者が新しいサービスを行うために要求する機能を組込むスイッチのソ
フトウェアのリリースが、思いがけなく他のネットワークの所有者に利用できる
ようになる。

【０００６】 加入者の移動性の増加、トラフィックの多様性と帯域幅の増加、従来の番号計
画の崩壊、サービスの高度化、及び競争の激化のために、新しいネットワークサ
ービスの需要が過去５から１０年間の間に急激に増加してきたため、これらの問
題は耐えられないものになってきたそのため、新しいネットワークアーキテクチ
ャには、サービス論理を作成、配置及び実現するより柔軟な方法を組込む必要が
あると広く認識されている。これ以降説明する本発明の新規なアーキテクチャを
十分に評価するために、以下の関連する先行技術の説明を図１〜４を参照しなが
ら行う。

【０００７】 図１を参照して、本発明を含め、様々な交換アーキテクチャの論理的な代表例
を示す。一般的には２０で表示するモノリシックスイッチは、サービス処理機能
２２と、呼出し処理機能２４と、ファシリティ処理機能２６と、スイッチ構造２
８とからなる。これら機能２２、２４、２６及び２８はすべて、グループ３０の
記号で表されるように、ハードコード化され、束ねて画一化される。また、機能
２２、２４、２６及び２８はスイッチメーカーが設計し、メーカーによって異な
る所有権を主張できるプラットフォームで操作する。その結果、これら機能２２
、２４、２６及び２８はメーカーの支援なく変更することができず、サービスの
開発と実行が遅れ、新たなサービスを市場に出す費用が増加する。そのため、新
規で革新的なサービス、呼出し処理、データ処理、信号処理及びネットワーク操
作の開発は、メーカーの所有権のあるスイッチのハードウェアとソフトウェアに
おける管理、及び業界標準を確率並びに実行する内在的な難しさによって制限さ
れる。

【０００８】 サービス処理機能２２はモノリシックスイッチ２０内で符合化されて、ローカ
ルデータの内容とダイヤル数に基づいてこの処理をローカル管理できるだけであ
る。このローカル情報は、符合化されたサービス機能を実行するハードコード化
されたプロセスエンジンにより解読される。呼出し処理機能２４はハードコード
化されて、発呼と着呼機能を提供する。このプロセスは実際には呼び出しを完了
するために個々の接続を繋げたり切ったりする。同様に、ファシリティ処理機能
２６もハードコード化されて、呼出しに関わる物理的な資源に関連するデータ処
理すべてを提供する。スイッチ構造２８はスイッチとコンピュータのハードウェ
アコンポーネントを表し、ノーザン・テレコム・インクなどのスイッチメーカー
が提供するモノリシックソフトウェアを実装する。スイッチ構造２８は接続を確
立するために必要な物理的な設備を提供し、ベアラ装置（Ｔｌ及びＤＳＯ）、交
換マトリックス装置（ネットワークプレーン及びそのプロセッサ）、リンクレイ
ヤ信号プロセッサ（ＳＳ７、ＭＴＰ、ＩＳＤＮ、ＬＡＰＤ）及び専用回路（会議
ポート、音声トーン検出器）などを含むことができるが、それに制限されない。

【０００９】 前述した問題に対応する試みの中で、国際電気通信連合とヨーロッパ通信標準
化協会は、ＩＴＵ−Ｔインテリジェントネットワーク標準（「ＩＮ」）を採択し
た。同様に、ベルコアは改良インテリジェントネットワーク標準（「ＡＩＮ」）
を採択した。この２つの標準は表現と発展段階が異なるけれども、ほぼ同一の目
的と基本的概念をもつ。従って、これら標準を、サービス処理機能２２をスイッ
チから分離する単一のネットワークアーキテクチャとして考える。

【００１０】 ＩＮとＡＩＮのアーキテクチャを使用して、ネットワークの所有者は、新しい
サービス論理プログラム（「ＳＬＰ」）、つまり本質的には所定の種類の呼出し
中に呼び出されるサービス非依存ビルディングブロック（「ＳＩＢＢ」）のテー
ブルを作成及び配置することによって、新しいサービスが作り出させると想定で
きるであろう。このアプローチに従って、多数の固有エレメントの種類はＳＬＰ
と連動してネットワーク加入者にサービスを提供するために相互運用する。その
結果、新しいサービス又は潜在的なサービスは既存のＳＩＢＢＳによって制限さ
れる。

【００１１】 一般的には４０で表示されるＩＮ又はＡＩＮのアーキテクチャは、論理的には
モノリシックスイッチ２０の機能を、サービス制御ポイント（「ＳＣＰ」）４２
と、サービス交換ポイント（「ＳＳＰ」）及び交換機４４に分ける。ＳＣＰ４２
にはサービス処理機能２２が含まれ、一方ＳＳＰ及び交換機４４には呼出し処理
機能２４、ファシリティ処理機能２６及びスイッチ構造２８が含まれる。この場
合、呼出し処理機能２４、ファシリティ処理機能２６及びスイッチ構造２８は、
グループ４６の符合で表されるように、ハードコード化され、束ねられて画一化
される。

【００１２】 サービス交換ポイント（「ＳＳＰ」）は、加入者の信号方式がダイヤル数だけ
に基づいた単純なルーチング以上のものを必要とするときを認識するために、ス
イッチにある機能モジュールである。ＳＳＰはさらに、本質的には多数のスイッ
チのデータベースサーバーとして作用するリモートＳＣＰ４２への正確な呼出し
処理の照会を開始しながら呼出し処理を保留する。この処理の分割の結果、スイ
ッチから、固有サービスの呼出しを処理する頻繁ではないが時間のかかる仕事の
負担が軽減される。また、この適度な集中化により、全体のネットワークを扱う
容易に変更でき、負担の大きいリポジトリをもつことと、すべてのスイッチにリ
ポジトリの完全なコピーを配置することのバランスをとる。

【００１３】 ここで図２を参照して、ＩＮ又はＡＩＮのアーキテクチャを採用する電気通信
システムの図を示し、一般的には５０で表示する。ＩＳＤＮ端末５２、第１電話
５４、第２電話５６などの様々なカスタマシステムがＳＳＰ及び交換機４４に接
続される。ＩＳＤＮ端末５２は、信号線６０とトランスポートライン６２によっ
て、ＳＳＰと交換機４４に接続される。第１電話５４はトランスポートライン６
４によって、ＳＳＰと交換機４４に接続される。第２電話５６はトランスポート
ライン６８によってリモート交換機６６に接続され、リモート交換機６６はトラ
ンスポートライン７０によってＳＳＰと交換機４４に接続される。

【００１４】 図１の参照で前述したように、ＳＳＰ７０は、加入者の信号方式がダイヤル数
に基づく単純なルーチング以上のものを必要とするときを認識するために、スイ
ッチにある機能モジュールである。ＳＳＰ７０はさらに、正確な呼出しの処理の
照会を開始しながら、呼出しの処理を保留する。この照会はＳＳ７メッセージの
形で、リモートＳＣＰ４２に送信される。サービス制御ポイント４２がそのよう
に呼ばれるのは、この場所でデータベースの内容を変更することで、それが多く
の内在するスイッチにより接続される加入者に現れるときに、ネットワーク機能
を変更することができるためである。照会は信号線７２を介して単にこれらエレ
メントの間のＳＳ７メッセージのルータである信号中継点（「ＳＴＰ」）７４に
送られ、さらに信号線７６を介してＳＣＰ４２に送られる。

【００１５】 総合サービス管理システム（「ＩＳＭＳ」）７８が管理ツールとして構想され
て、サービスを配置又は変更する、あるいは加入者毎のサービスへのアクセスを
管理する。ＩＳＭＳ７８は主にＳＳＰ７０及びＳＣＰ４２内に記憶される操作論
理とデータを変更することによって操作する。ＩＳＭＳ７８は様々なユーザイン
ターフェース８０及び８２をもつ。このＩＳＭＳ７８は操作線８４によってＳＣ
Ｐ４２に接続され、操作線８６によってＳＳＰと交換機４４に、操作線９０によ
ってインテリジェントペリフェラル（「ＩＰ」）８８に接続される。インテリジ
ェントペリフェラル８８は、音声応答又は音声認識システムなど、スイッチでは
利用できない機能をネットワークに追加するために使用するデバイスである。Ｉ
Ｐ８８は信号線９２とトランスポートライン９４によってＳＳＰと交換機４４に
接続される。

【００１６】 ここで図２を参照して、先行技術に従った呼出し処理を説明する。呼出しはカ
スタマが受話器を取って、ダイヤル呼出しを始めると開始される。会社のスイッ
チのＳＳＰ７０がダイヤル呼出しを監視し、トリガーシーケンスを認識する。Ｓ
ＳＰ７０はさらに、サービス論理が相談できるまで、呼出し処理を保留する。Ｓ
ＳＰ７０は次に標準ＳＳ７メッセージを構成し、それをＳＴＰ７４を介してＳＣ
Ｐ４２に送る。ＳＣＰ４２はメッセージを受信して復号し、ＳＬＰを呼び出す。
ＳＬＰはＳＣＰを解読し、このＳＣＰは番号変換のためのデータベース探索など
の他の機能を起動するよう要求することができる。ＳＣＰ４２はＳＳ７メッセー
ジを呼出し処理に関してＳＳＰと交換機４４に戻し、又はメッセージをネットワ
ーク要素にディスパッチして、正しいサービスを実行する。呼出しの終わりに、
ＳＳ７メッセージはスイッチの中に送られて、呼出しを分解し、呼出しの詳細記
録を呼び出しに関わる各スイッチで作る。呼出し詳細記録は各呼出しに関してオ
フラインで収集、相関、解決されて、市外呼びの請求を得て、このように呼出し
処理を完了する。

【００１７】 ＩＮ及びＡＩＮのアーキテクチャは、標準セットの機能を予め定義して、予測
可能なサービスすべてをサポートしようとする。この標準機能はすべて、スイッ
チ内の様々な状態の機械にハードコード化される。残念なことに、新しい機能は
、おそらく新しい技術又は不測のサービスニーズに連動して生じるが、多くのベ
ンダーのプラットフォーム上のネットワークソフトウェアの広範な分解検査と試
験なく実装することはできない。また、新しい機能に標準化された呼出しモデル
、プロトコル、又はインターフェースの変更が必要な場合には、その機能を利用
するサービスの実施は変更を業界標準グループが批准するまで遅れることがある
。しかし、標準案がＩＮ及びＡＩＮがサポートする機能のセットを広げようとし
ているときでも、機器の供給者がコードの複雑さが驚異的に増すために、これら
標準案を採択するのを拒絶してきた。

【００１８】 さらに図２の図では、ＩＮ及びＡＩＮのアーキテクチャの他の制限が、スイッ
チ内で操作する呼出し処理及びファシリティ処理機能、つまりＳＳＰ７０をもつ
ことから生じている。その結果、これら機能はその所有権を主張できるソフトウ
ェアを使用する各スイッチメーカーが提供しなければならない。そのため、ネッ
トワークの所有者は新しい機能をサポートするためには、さらに大きくメーカー
のソフトウェアのリリースに依存する。この問題をさらに複雑にしているのが、
ネットワークの所有者は統一的な開発試験環境で、ＳＳＰ７０のモジュールを他
のモジュールと連動して試験することができない。また、スイッチメーカーの処
理環境向けのＳＳＰ７０が、ネットワーク所有者のサービス作成環境に適合する
という保証もない。

【００１９】 複数のネットワーク所有者がこのように共通のスイッチメーカーに依存してい
る結果、競争を制限する２つの好ましくない状況が生じている。まず、メーカー
のソフトウェアのリリースは複数のネットワーク所有者が要求する変更を組込も
うとすることがあるため、ネットワーク所有者が自分のサービスをその競合者が
提供するサービスと本当の意味で違いをつけることを阻害している。またこのた
めに、数社のあるネットワーク所有者は、メーカーが他のネットワーク所有者か
らの要求を新しいリリースに組込むまで待たされる。次に、あるネットワーク所
有者が新しいサービスを実施するために要求する機能を組込むスイッチソフトウ
ェアリリースは、思いがけず他のネットワーク所有者が利用できることになるこ
とがある。そのため、ＩＮ及びＡＩＮのアーキテクチャの意図にも関わらず、ネ
ットワーク所有者が新しいサービスを作成、試験及び配置することは、ネットワ
ーク所有者がネットワークのサービス行動を形作る機能的なエレメントの完全な
管理又はアクセス権をもたないため、さらに阻害される。

【００２０】 これら問題を解決するための他の試みの中では、一般的には１５０で参照され
る（図１）分離スイッチインテリジェンススイッチ構造（「ＳＳＩ／ＳＦ」）が
論理的にはＳＳＰ７０を交換機４４から分離する。ここでもう一度図１を参照し
て、スイッチインテリジェンス１５２は、円１５４と１５６の記号で表示される
、対応するハードコード化された状態機械エンジンで個別状態テーブルで符合化
される呼出し処理機能２４とファシリティ処理機能２６を内蔵する。スイッチ構
造機能１５８とスイッチインテリジェンス機能１５２の間のインターフェースは
、スイッチ構造１５８とスイッチインテリジェンス１５２が必ずしも物理的に同
じ場所に位置する必要がないように、同じプロセッサ内に実現するか、又は１対
１の対応を持たせることにより、通信ネットワークで拡張できる。次に、スイッ
チインテリジェンス１５２は、すべてのスイッチに共通した一貫した単純な非サ
ービス固有、非メーカー固有の機能をもつインターフェースを提供する。

【００２１】 インテリジェントコンピューティングコンプレックス（「ＩＣＣ」）１６０は
、サービス処理機能２２を内蔵し、複数のスイッチインテリジェンス要素１５２
と通信する。このアプローチはネットワーク所有者に、柔軟にサービスを実施す
る上での利点を提供する。これはすべてではないにしてもほとんどの基本的機能
がメーカー固有のコードの領域外で動くからである。また、サービス論理の作成
、開発、試験及び実現のためのより一体的な環境を提供することにより、改良が
実現できる。

【００２２】 前述したように、現在のネットワークスイッチはモノリシックな所有権を主張
できるハードウェア及びソフトウェアに基づいている。ネットワークスイッチは
多額のコストがかかることがあるが、このような機器は現在利用できるコンピュ
ータ技術に鑑みて、処理速度の点で比較的遅い。例えば、これらスイッチは６０
ＭＨｚの範囲で実行する縮小命令セットコンピュータ（「ＲＩＳＣ」）プロセッ
サに基づいており、交換ネットワークの様々なプラットフォームの間を典型的に
は９．６Ｋｂ／秒の伝送速度をサポートする、Ｘ．２５などのデータ通信プロト
コルを使用して互いに通信する。これは、２００ＭＨｚ以上で実行するプロセッ
サ内蔵のパーソナルコンピュータや、１５０Ｍｂ／秒のＦＦＤＩ及びＡＴＭイン
ターフェースを提供するハイエンドコンピュータワークステーションと比較する
と極めて遅い。従って、ネットワーク所有者は、所有権を主張できるハードウェ
アの代わりに、ハイエンドワークステーションを使用できなければならない。

【００２３】

【課題を解決するための手段】

本発明は、資源コンプレックス又は交換プラットフォームで受信するあらゆる
種類の呼出しのためのインテリジェント呼出し処理サービスを実行するために設
計されるインテリジェントネットワークを目指している。インテリジェントネッ
トワークは、複数の分配型サービスノードからなり、各ノードがその具体的なサ
ービスノードに関連するスイッチ又は資源コンプレックスで受信する場合に、呼
出しの処理に必要な呼出し処理機能性をすべて提供することができる。これは非
常にスケーラブルなアーキテクチャをもち、電気通信サービスを費用効果的な方
法で配置できることを保証するよう設計されている。インテリジェントネットワ
ークはさらに、呼出しを受信する呼出し交換プラットフォーム又は資源コンプレ
ックスと独立して、それにオンデマンドでインテリジェント呼出し処理サービス
を提供し、呼出し事象の処理に容易に適用される。このように、費用の高いベン
ダー固有のハードウェア、オペレーティングシステム、及び交換プラットフォー
ムへの依存が排除される。分配型インテリジェントネットワークはさらに、場所
非依存の呼出し処理サービスの実現をサポートするため、モジュラーソフトウェ
アプロセスが実質的にアーキテクチャ内のどこでも実行でき、これら分配型プロ
セスの中に場所独立型通信を提供し、さらにサービスノードの必要性を排除する
。

【００２４】 さらに具体的には、プラットフォーム非依存で、そのハードウェア及びオペレ
ーティングシステムのプラットフォームにも移植性があり、様々なコンピューテ
ィングプラットフォームの使用を可能にすることによって、システムの非互換性
の問題を排除する１つのインテリジェントネットワークアーキテクチャを提供す
る。本発明のインテリジェントネットワークは、あらゆる且つすべての考えられ
る呼出し処理サービスをサポートするよう設計された基礎となるシステムのイン
フラストラクチャからなり、そこで特定のサービスのための専用機能を同じネッ
トワークインフラストラクチャを使用して容易に書き込み及び配置されるハイレ
ベルロジックプログラムにカプセル化する。

【００２５】 本発明のインテリジェントネットワークはさらに、特定の呼出しを処理するた
めにすぐに利用できる所定のデータ及び／又はソフトウェアのサービスモジュー
ルを作成することを担うデータ管理コンポーネントを実現する。さらに、様々な
種類のコンピュータ及びオペレーティングシステムと交換プラットフォームとか
らなるネットワークでプラットフォーム非依存サービスを提供するためのソフト
ウェアサービスモジュールを実行できる共通のサービス論理実現環境を実現する
。

【００２６】 本発明はさらに、ネットワーク全体で使用する呼出し処理サービスモジュール
とデータコンポーネントを命名する、カタログ化する、分配する、起動する、監
査する、非活動化する、及び解除するための機能性をもつ集中サービス管理プロ
セスを実現する。

【００２７】 このように、発明に従って、呼出し処理サービスが必要な電気通信事象を受信
するためのネットワーク要素を有する電気通信交換ネットワークに、インテリジ
ェント呼出し処理とサービスの実行を提供するための１つ以上のノードを有する
インテリジェントサービスプラットフォームを提供し、そのサービスプラットフ
ォームが、以下に示すａ〜ｄの構成要素を具備し、その構成要素は、ａ）ｉ）そ
れぞれ個別の呼出し処理機能をカプセル化し、ビジネスオブジェクトに要求され
るあらゆるデータを含む１つ以上の再利用可能なビジネスオブジェクトを記憶す
るためのデバイスと、ｉｉ）選択したビジネスオブジェクト及び関連データを、
所定のノード構成の基準に基づいた交換ネットワークの選択した１つ以上のノー
ドに分配するためのデバイスと、ｉｉｉ）実時間の利用に備えてビジネスオブジ
ェクトを起動するためのデバイスと、からなる集中管理システムと、ｂ）ネット
ワーク要素で受信する事象に従ってサービスを実施するために必要なビジネスオ
ブジェクトを実行するために、ノード内に統合される計算システムと、ｃ）管理
システムにより分配される選択したビジネスオブジェクト及びあらゆる関連デー
タを検索及び記憶するため、及びサービスを実施するときに計算システムに利用
できるビジネスオブジェクト及び関連データを作成するために、ノード内に統合
されるシステムと、ｄ）ノードのサービス間の、及びインテリジェントサービス
プラットフォームのノード間で場所非依存の通信を提供するため、及び受信する
事象のニーズに反応してサービスを実施するための１つ以上のビジネスオブジェ
クトのインタラクションを調整するために、ノード内に統合されるシステムとか
らなり、サービスが、ネットワーク要素からなるある種のハードウェアとは独立
してネットワークに届く事象のために、プラットフォームで実現されることを特
徴とする。

【００２８】 有利なことに、後で説明するように、発明のインテリジェントネットワークは
、交換、オペレータ、コールセンター及びＡＴＭ／Ｖｎｅｔサービスを含めたサ
ービス、並びにインテリジェント呼出し処理のトータル管理を、汎用コンピュー
タに実装されるソフトウェアに提供し、交換機能を、スケーラブルなプログラム
可能なスイッチで利用できるものなど、所有権を主張できない又は高価でない交
換ハードウェアに提供できる。

【００２９】 発明を特徴付ける新規性の様々な特徴は、開示に添付されて開示の一部を形成
する請求項で具体的に指摘される。発明、その操作上の利点、及びその使用によ
り達成される具体的な目的をよく理解するために、発明の好適な実施形態を図示
及び説明している図面と説明部分を参照するべきである。

【００３０】 本発明の上記利点及び別の利点は、添付図面に関連付けて以下の説明を参照す
ることによって、よりよく理解できる。

【００３１】

【発明の実施の形態】

本発明は、これでインテリジェント分配型ネットワークアーキテクチャ（「Ｉ
ＤＮＡ」）または次世代インテリジェントネットワーク（「ＡＮＧＩＮ」）と交
互に呼ばれる包括的なインテリジェントネットワークアーキテクチャである。こ
れに説明するように、ＮＧＩＮアーキテクチャは、例えばスイッチ、ルーター、
ＩＰ端末アドレスなど、資源コンプレックス又は交換プラットフォームで受信す
るあらゆる種類の呼出しのためにインテリジェント呼出し処理サービスを行うよ
う設計される。

【００３２】 図１に図示するように、インテリジェント分配型ネットワークアーキテクチャ
（「ＩＤＮＡ」）は一般的には１７０として表示される。本発明はＩＣＣ１６０
とＳＳＩ／ＳＦアーキテクチャ１５０のスイッチインテリジェンス１５２を、イ
ンテリジェント呼出しプロセッサ（「ＩＣＰ」）１７２に一体化する。その機能
が状態テーブルで定義されるＳＳＩ／ＳＦアーキテクチャ４０のＩＮ又はＡＩＮ
とは異なり、ＩＣＰ１７２は、オブジェクト指向のプラットフォームの管理オブ
ジェクトとして、サービス管理機能２２と、呼出し処理機能２４、とファシリテ
ィ処理機能２６とからなり、ブロック１７４、１７６及び１７８の記号で表示さ
れる。ＩＣＰ１７２は論理的には資源コンプレックス１８０とは分離している。

【００３３】 ここで図３を参照して、本発明に従ったインテリジェント分配型ネットワーク
アーキテクチャを採用する電気通信システムを説明するが、一般的には２００で
表示する。広域ネットワーク（「ＷＡＮ」）２０２は、地理的に広い領域に渡っ
てアプリケーションとデータの分配をサポートする。転送ネットワークはＩＤＮ
Ａノード２０４を接続するために同期光通信網（「ＳＯＮＥＴ」）に基づくこと
ができ、このノード内のアプリケーションが互いに通信できるようにする。

【００３４】 各ＩＤＮＡ２０４は、インテリジェント呼出しプロセッサ（「ＩＣＰ」）１７
２と資源コンプレックス１８０からなる（図１）。図３は、資源コンプレックス
Ａ（「ＲＣＡ」）２０６と資源コンプレックスＢ（「ＲＣＢ」）２０８を有する
ＩＤＮＡノード２０４を図示する。ＩＣＰは、供給、料金請求及び修復などの既
存のサポート機能を提供する補助プロセッサ２１０にリンクできるが、これら機
能はネットワーク管理システム（「ＮＭＳ」）２１２が提供する機能性により吸
収できる。しかしながら、好適な実施形態では、これらサポート機能は、図４に
関してこれで説明するデータ管理（「ＤＭ」）コンポーネント４００を有する集
中サービス管理（「ＳＡ」）システム５００が提供する。さらに図３に図示する
ように、ＩＣＰ１７２は、信号方式２１６及びベアラリンク２１８を有するダイ
レクトリンク２１８を介して、他のＩＣＰ１７２、他のネットワーク（図示せず
）、又は他のデバイス（図示せず）にもリンクできる。ダイレクトリンクは接続
されるデバイス間の待ち時間を防ぎ、デバイスがその自己言語で通信することを
可能にする。ＩＣＰ１７２はＩＤＮＡノード２０４の「ブレーン」であり、好ま
しくは汎用コンピュータであり、ＩＤＮＡノード２０４の処理要求によって、１
つのメモリ記憶装置をもつ１つのプロセッサから大容量のコンピュータネットワ
ークまでの範囲にすることができる。好ましくは、汎用コンピュータは冗長プロ
セッシング、メモリ記憶装置、及び接続をもつ。

【００３５】 これで使用するように、汎用コンピュータは、電話交換アプリケーションのた
めに特別に構成され設計される専用デバイスとは反対に、既成コンポーネントで
組立てられる又は組立てることができるコンピュータと言える。呼出しネットワ
ーク内に汎用コンピュータを統合することで多数の利点が得られる。

【００３６】 汎用コンピュータを使用することにより、ＩＣＰ１７２は処理要求の増加を満
たすために追加のハードウェアで拡張することができる。この追加には、処理力
、データ記憶、通信の帯域幅を増加する能力が含まれる。この追加には、呼出し
ネットワークの各スイッチにあるメーカー固有のソフトウェア及び／又はハード
ウェアを変更する必要はない。その結果、新しいサービス及びプロトコルは、交
換ネットワークの個々のデバイスを変更することなく、グローバルな規模で実現
及びインストールすることができる。モノリシックスイッチ２０（図１）からイ
ンテリジェント呼出しプロセッサ１７２に変更することにより、本発明は前述の
利点と能力の向上を提供する。

【００３７】 より大きな処理力が必要なアプリケーションの場合、多重処理により、あまり
高価でないプロセッサを使用して価格／性能比を最適にすることができる。他の
アプリケーションでは、マイクロコンピュータなど、処理速度の速いよりパワフ
ルな機械を使用することが、有利、必要又は費用効果的であろう。

【００３８】 ＩＣＰ１７２は、前述したように、例えばＵＮＩＸ（登録商標）又はウィンド ウズＮＴ（登録商標）オペレーティングシステムで操作する汎用コンピュータの クラスタからなる。例えば、１つの資源コンプレックスで１００，０００個以下 のポートをサポートする大きなアプリケーションでは、ＩＣＰ１７２は、対称型 マルチプロセッサのクラスタで３３３ＭＨｚで操作する１６個の３２ビットのプ ロセッサからなる。このプロセッサは、例えば、それぞれ４個のプロセッサをも つ４個の個別サーバーに分けることができるであろう。個々のプロセッサはシス テム領域ネットワーク（「ＳＡＮ」）又はクラスタリング技術に接続されるであ ろう。プロセッサのクラスタは、冗長性をもつ非依存ディスクアレイ（「ＲＡＩ Ｄ」）のモジュラーデータ記憶装置へのアクセスを共有できるであろう。共有す る記憶は、モジュラーディスク記憶装置を追加したり又は取り外したりすること によって調整できる。クラスタのサーバーは好ましくは、ＲＣ１８０への冗長リ ンクを共有する（図１）。

【００３９】 図示するように、またパーソナルコンピュータの「プラグ・アンド・プレイ」
の特徴と同様に、ＩＣＰソフトウェアアーキテクチャはオープンプロセッシング
モデルで、これは（１）管理ソフトウェア、（２）ＩＣＰアプリケーション、（
３）コンピュータのハードウェア及びソフトウェア、（４）資源コンプレックス
コンポーネント、及び（５）サービスアプリケーション及び処理でさえも、その
互換性を可能にする。このような一般的なアプリケーションは標準化により保守
コストを減らし、規模の経済から得られる便益を提供する。

【００４０】 このように、本発明は開発作業とモジュラーツールの使用を区分する結果、サ
ービスをより早く開発及び実現できる。さらに、サービス管理の使用及び関連す
る側面は、固定メッセージプロトコル又は所定のメーカーが供給する特定のハー
ドウェア及びソフトウェアの組合わせによって課される制限とは反対に、必要に
応じた基準でネットワークオペレータの管理の範囲内にある。

【００４１】 管理オブジェクトを使用することによって、本発明はまた、サービスと機能を
、容量及び用途などのあらゆる数の要因に基づいて、ネットワーク全体に柔軟に
（「望む場合」）及びダイナミックに（「進行中に」）分配できる。サービス処
理２２（図１）、呼出し処理２４（図１）及びファシリティ処理２６（図１）が
同種のプラットフォームで動作するため、性能が改善される。さらに、本発明は
、以前には利用できなかったであろう呼出しのサブエレメントの監視と操作を可
能にする。本発明はまた、時代遅れになる又は使用しなくなるときに、削除でき
るように、機能又はサービスの用途を監視する機能を設ける。

【００４２】 資源コンプレックス（「ＲＣ」）１８０（図１）は、物理的デバイス又は資源
の集合であり、これはベアラ、信号方式及び接続サービスを提供する。インテリ
ジェントペリフェラル８８を含むことができるＲＣ１８０は、ＩＮ又はＡＩＮも
しくはＳＳＩ／ＳＦアーキテクチャのスイッチ構造２８及び１５８（図１）に置
き換わる。ＩＮ又はＡＩＮアーキテクチャとは異なり、ＲＣＡ２０６〔図３に図
示〕などの資源コンプレックスの制御は低いレベルである。さらに、ＲＣＡ２０
６は複数のスイッチ構造１５８を含むことができる。スイッチ構造１５８又は他
のカスタマインターフェース（図示せず）は、標準電話接続を介して複数の加入
者及び交換ネットワークに接続する。これらカスタマシステムには、ＩＳＤＮ端
末５２、ファックス機械２２０、電話５４、及びＰＢＸシステム２２２を含むこ
とができる。ＩＣＰ１７２は高速データ通信パイプ（最低でも１００Ｍｂ／秒の
イーサネット（登録商標）接続）２２４を介して、ＲＣ１８０（図１）、ＲＣＡ ２０６及びＲＣＢ２０８を制御し、それと通信する。ＲＣ１８０、２０６及び２ ０８はプリンタに類似させることができ、ＩＣＰ１７２はパーソナルコンピュー タをプリンタを制御するためのドライバとして使用するパーソナルコンピュータ に類似させることができる。ＩＤＮＡノード２０４の「ドライバ」は資源コンプ レックスプロキシ（「ＲＣＰ」）（図示せず）であり、これを図６を参照して以 下に説明する。これは、メーカーがＩＤＮＡモデルを組込むためにそのソフトウ ェアのすべてを書き換える必要なく、このインターフェースを使用するＩＤＮＡ 適合ノードを提供するのを可能にする。

【００４３】 さらに、資源コンプレックス１８０（図１）、ＲＣＡ２０６及びＲＣＢ２０８
の制御は、典型的にＡＩＮ又はＩＮアーキテクチャが提供するレベルよりも低い
。その結果、資源コンプレックスのメーカーは１つのインターフェースを提供し
て、ファシリティ及びネットワーク管理処理をサポートするだけでよく、ネット
ワーク所有者に特別な呼出し及びサービス処理を提供する必要はない。低レベル
のインターフェースはより分離した動作に引き離される。１つのインターフェー
スをもつことによって、ネットワーク所有者は価格と性能の判断に基づいて、幅
広い範囲の資源コンプレックスメーカーから選択できる。インテリジェンスをＲ
Ｃ１８０ではなくＩＣＰ１７２に追加して、ＲＣ１８０を変更と分離して、その
複雑さを減少する。ＲＣ１８０の役割は単純化されるため、変更はより簡単に行
われ、このように非同期転送モード（「ＡＴＭ」）などの代替の交換及び伝送技
術に軽減するのを簡単にする。

【００４４】 インテリジェントペリフェラル（「ＩＰ」）８８は、実際の呼出し伝送路内に
含まれる情報を処理しそれに作用する能力を提供する。ＩＰ８８は一般的にはＲ
ＣＢ２０８などの個別の資源コンプレックスの中にあり、ＲＣＡ２０６と類似の
方法でＩＣＰ１７２により制御される。ＩＰは、デジタル信号処理（「ＤＳＰ」
）技術を使用して、実際の呼出し伝送路内のデータを実時間で処理する能力を提
供する。

【００４５】 述べたように、ネットワーク管理システム（「ＮＭＳ」）２１２を使用して、
ＩＤＮＡネットワーク２００でハードウェア及びサービスを監視、制御できる。
提案されるＮＭＳ２１２の実現は、ＩＤＮＡネットワーク２００内でコンポーネ
ントの管理をする電気通信管理ネットワーク（「ＴＭＮ」）適合フレームワーク
となろう。より具体的には、ＮＭＳ２１２はサービスの配置を制御し、そのサー
ビスの健全性を維持し、そのサービスに関する情報を提供し、ＩＤＮＡネットワ
ーク２００にネットワークレベルの管理機能を提供する。ＮＭＳ２１２はＩＤＮ
Ａノード２０４内のエージェント機能性により、サービスとハードウェアにアク
セスして制御する。ＩＤＮＡノード２０４内のＩＣＰ−ＮＭＳエージェント（図
示せず）はＮＭＳ２１２が発行するコマンド又は要求を実行する。ＮＭＳ２１２
は標準操作リンク２２６によりＲＣＡ２０６及びＲＣＢ２０８を直接監視及び制
御できる。

【００４６】 さらに図３に図示するように、管理オブジェクト作成環境（「ＭＯＣＥ」）２
２８は、ＩＤＮＡネットワーク２００で実行するサービスを作成するためのサブ
コンポーネントからなる。サービス非依存ビルディングブロック及びＡＰＩは、
新しいサービスを作成するために使用するサービスデザイナーがＭＯＣＥの主な
サブコンポーネント、つまりグラフィカルユーザインターフェース（「ＧＵＩ」
）内に埋め込まれることを表す。ＭＯＣＥ２２８は、交互にサービス作成（「Ｓ
Ｃ」）環境と呼ばれる１つのユーザ環境又はプラットフォームでホストされる一
体的なツールの集合である。これは、サービス文書化、管理オブジェクトの定義
、インターフェースの定義、プロトコルの定義、及びデータ入力の定義など、管
理オブジェクトにカプセル化されるサービス作成、及びサービス試験のプロセス
全体で要求される操作の集合を表す。ネットワーク所有者は、管理オブジェクト
がそのネットワークのすべてのノードに適用することができるため、一旦ＭＯＣ
Ｅ２２８を使用すればサービスを開発するだけでよい。これは様々なスイッチメ
ーカーにそのサービスのバージョンを開発させる、つまりサービスを複数回開発
しなければならないネットワーク所有者とは対照的である。

【００４７】 ＭＯＣＥ２２８及びＮＭＳ２１２はともにリポジトリ２３０を介して接続され
る。リポジトリ２３０は、ＮＭＳ２１２が分配し、ＩＤＮＡ／ＮＧＩＮノード２
０４で使用する管理オブジェクトを内蔵する。リポジトリ２３０はまたＭＯＣＥ
２２８とＮＭＳ２１２の間にバッファを提供する。しかし、ＭＯＣＥ２２８はＮ
ＭＳ２１２に直接接続して「生の」ネットワーク試験を行うことができ、これを
点線２３２で示す。

【００４８】 図４に図示するように、発明の好適な実施形態に従って、ＩＤＮＡ／ＮＧＩＮ
システムは集中サービス管理（「ＳＡ」）コンポーネント５００からなり、この
コンポーネント５００は、これ以降説明するような付加能力とともに、ＩＤＮＡ
システム１７０の記憶（リポジトリ）２３０の機能性と一般的なネットワーク管
理（ＮＭＳ）２１２の機能性の両方を提供する。一般的には、図４に図示するＳ
Ａコンポーネントは、ＩＤＮＡ／ＮＧＩＮシステムのためのすべてのサービス及
びデータのオフライン記憶、命名、分配、起動及び解除をサポートし、さらにＩ
ＤＮＡサービスノードのサービスオブジェクトが使用するデータの走行時間の記
憶、複製、同期、及び利用を可能にするデータ管理（「ＤＭ」）機能を提供する
。

【００４９】 より具体的には、図５（ａ）に概念的に図示するように、サービス管理コンポ
ーネント５００は、ＩＤＮＡサービス処理ノードが使用するすべてのサービス及
びサービスデータを管理、記憶、及び分配するために、またシステムＩＤＮＡ／
ＮＧＩＮで実現するハードウェア及びソフトウェアコンポーネント両方を構成す
るために必要な機能をすべて行うコンポーネントである。一般的には、図５（ａ
）に図示するように、ＳＡコンポーネント５００は、ＭＯＣＥ（サービス作成）
２２８からデータを受信する；オーダーエントリー及び他のレガシーシステムか
ら２２９からカスタマオーダーデータ５０２を受信して、カスタマが使用するた
めにＩＤＮＡ／ＮＧＩＮシステムを供給する；データ、サービス非依存ビルディ
ングブロック（「ＳＩＢＢ」）、サービス論理プログラム（「ＳＬＰ」）、及び
他のサービスコンポーネント５０３を、例えばサービス作成プロセス中に、ＭＯ
ＣＥ／ＳＣＥユーザが要求するように例えばＭＯＣＥ２２８に配置する；ＭＯＣ
Ｅ２２８から完了した及び試験したサービスパッケージ、ＳＩＢＢ、ＳＬＰ、又
は他のサービスあるいはデータコンポーネント５０６を受信する；各サービスコ
ンポーネントに固有の名前を提供する；データ及び各サービスコンポーネント５
０９をローカル管理コンポーネント４００に分配する、ことを担い、これにより
詳細に説明する。また、図４に図示するように、サービス管理５００は、データ
管理コンポーネント４００がそのデータすべてを受信するＩＤＮＡ／ＮＧＩＮサ
ービス及びデータすべてから構成される、グローバルな記録のデータベース（「
ＤＢＯＲ」）を含むリポジトリ２３０を維持する。

【００５０】 サービス管理の他の責任には、データ及びサービスコンポーネント５１２を起
動して、すべてのデータ、ＳＩＢＢ、及び管理オブジェクト又はサービス論理プ
ログラムＳＬＰがデータ管理コンポーネント４００を介してノードに利用できる
ようにする；以下に詳細に説明するが、それとともに登録するために、その論理
名をネットワークオペレーティングシステム（「ＮＯＳ」）コンポーネント７０
０に送ることによって、データ、ＳＬＰ及びＳＩＢＢ５１５の名前を登録する；
データ及びサービスコンポーネント５１８を非活動化する；データ及びサービス
５２１をデータ管理コンポーネント４００を介してＩＤＮＡ／ＮＧＩＮシステム
から解除する、ことが含まれる。サービス管理はさらに、その命名プロセスによ
りバージョン化することに加え、各ＳＩＢＢ及びサービスの状態を維持すること
によって（事前試験、事後試験、配置など）、構成管理機能を行う。これにより
、そのサービスのすべてのコンポーネントがうまく試験されて構成されるまで、
サービスを配置しないようにする。

【００５１】 図５（ｄ）に関して説明すると、サービス管理コンポーネント５００はさらに
、ＳＡが受信する構成情報に従って、ＩＤＮＡ／ＮＧＩＮサービスノード２０４
を構成及び供給する機能を行う。具体的には、受信した構成情報に基づいて、Ｓ
Ａコンポーネント５００は各サービスノード２０４で各コンポーネントの能力を
判断し、どのサービス及びデータをどのノードに分配するか、どのサービスがサ
ービスノードにあるどのサーバーで実行するか、どのデータをＩＤＮＡ／ＮＧＩ
Ｎノードサーバーに関連してあるローカルメモリにキャッシュするかを判断する
。具体的には、ＳＡが各サービスノードに位置するローカルＬＲＭキャッシュで
記憶するために、サービスプロフィール（構成）ファイル５８０に内蔵される構
成規則をＮＯＳシステム７００のローカル（ノード）資源マネージャー（「ＡＬ
ＲＭ」）コンポーネント５７５に配置する。これにより詳細に説明するように、
これら構成ファイル５８０は、ＩＤＮＡノードでどのサービスを実行するかを判
断する。ＬＲＭはまずそのノードのローカルキャッシュに記憶されるこのサービ
スプロフィールファイル５８０を読取り、サービスプロフィールファイルの規則
に従ってサービスを実行するために、例えば仮想機械などの特定のサービス例や
実行環境（「ＳＩＥＥ」）を判断し、このサービスがＳＬＥＥで能動的に（持続
的なオブジェクトとして）実行される、又は要求がある場合にのみインスタンス
生成される。

【００５２】 図５（ｂ）はサービス管理コンポーネント５００のための好適な物理的アーキ
テクチャを図示する。サービス管理は集中機能であるため、グローバルＤＢＯＲ
２３０からなる共有ディスクアレイをもつデュアル冗長プロセッサから構成でき
るＳＡサーバー５６０と；インターフェースを有する各サイト５５０ａ、５５０
ｂにあるパーソナルコンピュータ（ＰＣ）又はワークステーション５５６ａ、ｂ
とからなる、各ＳＡサイトでの信頼性のために、例えばサイト５５０ａ、５５０
ｂなどの複数の冗長サービス管理サイトとして具現でき、ユーザがすべてのサー
バー管理機能にアクセスできるようになる、具体的にはサービスノード２０４と
して図５（ｂ）で描写される専用ＩＤＮＡ／ＮＧＩＮサービスノードにデータ及
びサービスの分配を開始する。前述のデータ及びサービス分配起動機能はすべて
、各サイトにある１つ以上のＳＡサーバー５６０で実行する。各ＳＡサイト５５
０ａ、ｂのコンポーネントは、イーサネットＬＡＮ５５９により接続され、それ
がそのままサービスノードと通信するためにＷＡＮ５６６にリンクされる。

【００５３】 図５（ｃ）は、図５（ａ）のサービス管理コンポーネント５００の主な機能的
コンポーネント及びサービス管理コンポーネント５００との外部インターフェー
スを強調した好適な物理的実施形態を図示する。図５（ｃ）に図示するように、
サービス管理コンポーネント５００はデータ分配サブコンポーネント５１０から
なり、これは、１）外部システムと信頼性のある通信を提供する、２）外部シス
テムからのデータを受信し、典型的には共通のデータ分配アプリケーションプロ
グラムインターフェース（ＤＤＡＰＩ）５０５を介してＳＡから外部システムに
データを分配するために、データの変換と機能のフォーマット化を行う、３）イ
ンベントリマネージャーサブコンポーネント５１６に入力するために、外部シス
テムから受信する通信メッセージからデータを抽出する、４）サービス／データ
パッケージのマルチポイント分配機能に、蓄積交換特徴と保証される転送及び回
復サービスをもたせる、５） ギャップ検査、重複検査、受信肯定応答に加えて
、連続してデータセットを転送させて、データ伝送のセキュリティを確保する。

【００５４】 ＳＡコンポーネント５００への入力送り機構は、サービスの組込むに使用され
るサービスコンポーネント、パッケージ及びＳＩＢＢモジュールを送込むＭＯＣ
Ｅ／ＳＣＥ２２８からの送り機構５０６と、カスタマのデータを入力してサービ
ス供給機能を行う会社のオーダーエントリー（「ＡＯＥ」）送り機構５０２と、
ユーザの仕様を入力してＳＣＥコンポーネント２２８が作成するサービスの分配
方法及び分配場所に関してＳＡ５００を指示する１つ以上の環境供給（「ＡＥＰ
」）システム送込み機構５０８とからなる。より具体的には、環境供給システム
送込み機構５０８に関して、ＮＧＩＮサービス処理環境の一部と考えられる各サ
ービスノードコンポーネント（コンピュータのハードウェア、オペレーティング
システム、ＳＬＥＥ、データ管理のローカルキャッシュ）は、そのノードの物理
的能力（例、記憶容量、メモリ容量、コンピュータの処理容量など）から構成さ
れるサービスノードのプロフィールとともに指定される。ＥＰシステム５０８の
ＧＵＩ（図示せず）を介して、ユーザは、各サービスノードのサービスノードプ
ロフィール（能力）に基づいて、どのサービスオブジェクト（例、ＳＬＰ、ＳＩ
ＢＢ、データなど）をどのノードのどのＳＬＥＥに配置するか、どのデータをど
のノードに配置するかを構成するサービスプロフィールと、各ＳＬＥＥ及びコン
ピュータのローカルキャッシュ戦略を指定する。これら仕様を環境マネージャサ
ブコンポーネント５３０によりＳＡに入力して、使用し、サービス及びデータの
正確な分配を指定する。

【００５５】 より具体的には、環境供給システムのインターフェースを使用して、サービス
ノードプロフィールを入力するとともに、サービスプロフィールの分配を適切な
サービスノードに向ける。サービスノードは、サービスノードの能力とサービス
プロフィールの要求事項に基づいて、自動的にサービスプロフィールに突き合わ
せることができるが、サービスプロフィールはサービスノードを手動で選択する
よう指定できる。サービスプロフィールが、サービスノードに対し手動で突き合
わせることを要求する場合、ＥＰシステム５０８を使用して突合せを行うまで、
サービスは分配されない。サービスプロフィールが、サービスを自動で分配する
よう要求する場合、サービスは自動的に突き合わされて分配されるが、環境供給
インターフェースはこれを無効にして、分配を後に変更することができる。

【００５６】 データ分配ＡＰＴ５０５はＳＡの機能をすべてを利用するために標準インター
フェースを提供し、さらにデータ分配サブコンポーネントと対話して、保証され
る転送／回復サービスを提供する。具体的には、ＤＤＡＰＩ５０５がサービス管
理クライアントが利用するための標準メッセージセットを提供し、これが各サー
ビスノードのローカルデータ管理コンポーネントとなる。ＳＣＥ及びＥＰシステ
ムもＤＤＡＰＩを介してサービス管理と対話するよう設計される。しかしながら
、ＯＥシステム２２９などの他の外部システムはＤＤＡＰＩを利用するよう設計
していないため、仲介プロセス５１１を利用して、上記外部システムの通信プロ
トコルとメッセージフォーマットをＤＤＡＰＩ５０５に適用できる。

【００５７】 図５（ｃ）に図示するように、すべての外部インターフェースには、１つのＤ
ＤＡＰＩとデータ分配プロセス５１０だけが必要できる。サービス管理とインタ
ーフェースする外部システムはすべて、それぞれに認められる特権によって、そ
の機能のすべてにアクセスできる。これによって、ＤＢＯＲのアップデートなど
の機能は、例えばそれを開始するものに関わらず同じ方法ですべて処理され、さ
らに特別な場合の処理を排除する。これはまた、あるシステム（例ＯＥ）に備わ
る同じデータの完全性の検査を他のシステム（例、ネットワーク要素）に提供さ
れ、さらにサービス管理とインターフェースするための外部システムの開発を促
進する。

【００５８】 また図５（ｃ）に図示するように、ＳＡコンポーネント５００は次のサブコン
ポーネントからなる。つまり、インベントリマネージャー５１６と；ＤＢＯＲマ
ネージャー５２０と；環境マネージャー５３０と；監査調整マネージャー５３５
と、監視ロギングマネージャー５４０である。これら各機能をここでさらに詳細
に説明する。

【００５９】 インベントリマネージャーサブコンポーネント５１６は、データ分配プロセス
５１０を介して、外部ソースからのすべてのデータ構成要素を受信する。これら
データ構成要素は、サービス作成からのサービス及びＳＩＢＢと、オーダーエン
トリーシステム送り機構５０２からのサービスデータ及びカスタマデータと、環
境供給送り機構５０８からの環境構成及び供給の仕様とからなる。インベントリ
マネージャー５１６は受信する各データ構成要素に、所定の命名規定に従って、
固有名称を提供する。これには同じデータ構成要素の複数のバージョンを含む。
インベントリマネージャーはまた、複数のソースから受信するデータの間のデー
タの完全性を保証し、あらゆる矛盾を解決する。例えば、インベントリマネージ
ャーが、同じカスタマの料金無料番号に関して２つの異なるＯＥソース、２つの
異なるネットワーク端末（インテリジェントルーチング特徴を適用することによ
って解決する）から受信する場合、インベントリマネージャーは各受信したデー
タ構成要素に監査を行うことによって、これを検出する。検出時、これは解決ア
ルゴリズムを行う（例、ネットワーク端末を最新日／時刻印で管理する）、又は
矛盾をユーザに通知することができる。またインベントリマネージャーは命名し
たデータ構成要素をＤＢＯＲで記憶する。これはＤＢＯＲマネージャー５２０を
使用して、実際にデータをＤＢＯＲに記憶する。インベントリマネージャーはま
た、環境マネージャーにＤＢＯＲの更新をすべて通知する。

【００６０】 ＤＢＯＲマネージャー５２０は、サービス管理の複数の機能コンポーネントに
１つのＤＢＯＲ２３０へのインターフェースを提供し、すべてのデータベース管
理機能を行う（追加、削除、検索、変更など）。これは、複数の種類のデータ、
つまりサービス用ＳＬＰ、ＳＩＢＢ、カスタマ及びサービスデータ用データセッ
ト、ＩＶＲサービス用のマルチメディアデータなどを記憶するために、ＤＢＯＲ
が実際に複数のデータベースから構成できる重要な機能である。好ましくは、Ｄ
ＢＯＲは、オブジェクトデータベースと関係データベースの両方から構成する。
これらデータベースは様々なベンダーが提供することができ、そのため、データ
ベース管理機能を行うためには様々なコマンドのセットが必要である。ＤＢＯＲ
マネージャー５２０は別のサービスコンポーネントからこれらバリエーションを
カプセル化して、ＤＢＯＲ機能を行う必要のあるあらゆるコンポーネントをＤＢ
ＯＲマネージャーが提供する共通のコマンドセットとデータ構成要素の名前を簡
単に実現するようにする。ＤＢＯＲマネージャー３２０は提供されるデータ構成
要素の名前を使用して、要求されるコマンドを特定のデータベースの種類が使用
するフォーマットにあわせて、要求される機能を実行する。ＤＢＯＲマネージャ
ーとインターフェースするサービス管理サブコンポーネントは３つあり、インベ
ントリマネージャー５１６と環境マネージャー５３０と監査調整マネージャー５
３５である。

【００６１】 環境マネージャーサブコンポーネント５３０は、サービス及びデータをＤＢＯ
ＲからＮＧＩＮサービスノードのローカルデータ管理コンポーネントに配置する
ことを担う。これは、まずどのサービス／データ構成要素をどのノードに分配す
る必要があるかを判断し、次に、ＤＢＯＲから抽出したデータ構成要素に従って
、適切な分配コマンドをデータ分配に発行することによって行う。ＥＰシステム
送り機構５０８を介してユーザが入力する環境供給の仕様は、ＤＢＯＲで記憶し
て、分配を決定するために環境マネージャーが使用する。このように、サービス
管理は各ＮＧＩＮサービスノードに、そのサービスノードが必要なデータ構成要
素のみを分配する。この特徴により、各サービスノードとネットワーク帯域幅で
の記憶の要求量を減らし、データの分配に必要な処理／伝送時間を短縮する。さ
らに、データ構成要素のコピーの数が最小化されるため、データの完全性を単純
にすることによって、ＮＧＩＮ機能のネットワーク全体の分配を可能にする。環
境マネージャーの機能にはサービス管理による複雑な処理が必要なこともあるが
、この複雑さは環境マネージャーにより適用される分配規則に容易にカプセル化
されることを理解するべきである。さらに、環境マネージャー５３０はＮＧＩＮ
システムアーキテクチャに提供される価値あるレベルの構成を示す。つまり、す
べてのデータをすべてのサービスノードに配置して、各ノードのすべてのサービ
スを可能にできるが、これは必ずしも必要ではない。ユーザはネットワークの設
計を最適にするためにどのノードでサービスを受けるかを決定することができ、
さらにそのサービスに必要なデータをそのノードに配置できる。

【００６２】 環境マネージャー５３０はさらに、インベントリマネージャー又はＤＢＯＲマ
ネージャーのいずれかによって、ＤＢＯＲが変更されるときは必ず、例えばサー
ビスが新しいバージョンに代わった時には通知されることができる。環境マネー
ジャー５３０は、影響を受ける各サービスノードを更新させることを保証する（
つまり、新しいサービスバージョンを受取る）。ＤＢＯＲのアップデートの通知
を受取る場合、更新されたデータを使用する各サービスノード、又はこれに説明
するように、各影響を受けるサービスノードのローカルデータ管理コンポーネン
トに、更新されたサービスを提供し、アップデートを分配する各サービスノード
を識別する。

【００６３】 監査調整（Ａ／Ｒ）マネージャー５３５は、監査ルーティンを実行して、ＤＢ
ＯＲ２３０のデータと様々なＤＢＯＲの抽出のいずれかのデータと比較すること
によって、ＤＢＯＲとその複数の抽出の間のデータの同期を保証する。また、複
数のデータベースを再同期させるための補正措置を判断する。これらの措置を実
現するために、Ａ／Ｒマネージャーはこれらデータを処理するデータ及びコマン
ドを含むデータパッケージを生成する。このデータパッケージはまた、複数のデ
ータベースを再同期させるための補正措置を実現するためにどのデータベースが
必要でも提供される。好ましくは、これは以下のとおり行うことができる。１）
システムのアイドル時間中に、監査ルーティンを実行して、ＤＢＯＲのデータと
ＤＢＯＲ抽出のデータのあらゆる矛盾を探して解決する。このデータはサービス
ノードのローカルデータ管理である。；２）実時間の呼出し処理中には、サービ
スアプリケーションが矛盾を発見し、例えば、サービスアプリケーションにデー
タ管理のデータルックアップ用のキーを与えられて、このキーでデータベースを
照会するが、記録が見つからない場合、アプリケーションがアラームを発生する
。このアラームはＡ／Ｒマネージャー５３５に送られて、そこで矛盾を解決する
。

【００６４】 監視ロギングサブコンポーネント５４０は、サービス管理プロセスの性能と安
定性を監視し、行われる一定のあるいはすべての事象を記録して、ユーザが後で
例えばどのデータをどのノードにいつ配置したかを見ることができるようにする
プロセスである。

【００６５】 説明したように、グローバルＤＢＯＲ２３０は、多くの異なる種類のデータ及
びサービスを記憶して管理するために区分される１つ以上の物理的データベース
とすることができる。データ及びサービスは、ＳＬＰ、ＳＩＢＢ、例えば、呼出
し記録情報、ファックス及びルーチング計画などのカスタマのプロフィールとい
ったサービスデータ及びカスタマデータ、及びインタラクティブサービスのため
のボイスメールメッセージ及び他のオーディオとビデオファイルもしくはオブジ
ェクトなどのマルチメディアファイルが含まれる。冗長性及び存続性のために複
数のＤＢＯＲが存在することができるが、あらゆる且つすべての他のＮＧＩＮの
機能コンポーネント及びプロセスに分配するために、ＤＢＯＲ２３０はすべての
ＮＧＩＮサービス及びデータの１つの論理的な記憶装置である。

【００６６】 また図５（ｃ）に図示するように、ＳＡコンポーネント５３０はＮＯＳコンポ
ーネント７００を実現して、様々なサービス管理プロセスの間の通信を提供する
。例えば、ＤＤＡＰＩ５０５はＮＯＳサービスを使用して、ＮＯＳの通信メカニ
ズムを使用するメッセージセットを提供し、外部システムとデータ分配５１０の
間のインターフェース、及びデータ分配５１０と他のＳＡサブコンポーネントの
間のインターフェースを可能にする。しかしながら、好適な物理的実施形態のこ
れらプロセスを同じ計算システムで実行するよう設計するとき、インベントリマ
ネージャー、環境マネージャー、Ａ／Ｒマネージャー及びＤＢＯＲマネージャー
のコンポーネントの間の通信にはＮＯＳ７００は必要ない。これらプロセスが異
なる計算システムで実行する分配型計算システムでさえも、これらプロセスは例
えばＴＣＰ／ＩＰソケットなどの他の内部ＡＰＩ及び通信プロトコルを使用して
、互いに通信できることを理解するべきである。当業者には、プロセス間通信の
ためにＮＯＳを使用するために、すべてのサービス管理内部プロセスを機能に備
える方法は明らかであろう。

【００６７】 ＳＡコンポーネント５００の好適な実施形態を説明してきたが、ここでサービ
ス管理が行う主要なサービスのより詳細な説明を、図５（ｃ）〜５（ｅ）を参照
しながら行う。

【００６８】 第１：述べたように、ＳＡ５００はサービス及びデータの命名とバージョン化
の実行を担う。つまり、ＳＡはサービス／データの構成要素をＤＢＯＲ２３０に
記憶する前に、すべてのサービス／データの構成要素のすべてのバージョンに固
有の名前をつけて、同じサービス／データの構成要素の複数のバージョンを維持
することができるようにする。ＳＡがデータ／サービスをデータ管理に分配する
とき、固有のバージョン名に従って、１つの論理名が各構成要素に提供されて、
ＳＬＰなどのプロセスは、どのバージョンが必要かを知る必要なく、共通の論理
名をもつサービス／データの構成要素を要求することができる。名前の登録の要
求することが、データ、ＳＩＢＢ、及びＳＬＰの名前を固有なものにする必要性
、及びＮＧＩＮのＳＡコンポーネント５００がこれら様々なコンポーネントのマ
スターコピーを維持するための必要性を詳細に理解することになることは理解す
るべきである。データ、ＳＩＢＢ、及びＳＬＰがＳＡに提供されると、これらコ
ンポーネントのクリエータはユーザ名を使用してそれを識別している。このユー
ザ名はＭＯＣＥ／ＳＣＥがコンポーネントをその項で識別する方法を規定する。
このユーザ名はまた、１つの論理名（つまり、共通の参照）で固有に識別される
。好ましくは、ＳＡは、新しい又は変更したコンポーネントを命名するときに命
名構造規定を実行し、ユーザ名と論理システムの固有名の間のマッピングを管理
する。データ、ＳＬＰ、ＳＩＢＢの要求を行うときには、ＳＡは論理システムの
固有名に加えて、ユーザ名を提供できる。

【００６９】 第２：サービス管理コンポーネント５００はサービスの供給、つまりサービス
をこれらサービスを提供するために必要なデータに供給することを担う。この種
のデータはオーダーエントリー送り機構５０２からＳＡに入力されて、グローバ
ルＤＢＯＲ２３０に記憶されてから、データ管理４００に分配される。この種の
データには、カスタマサービスオプション、カスタマ名及び料金データなどのカ
スタマプロフィールデータ、受信側の電話番号、呼出しルーチングデータ、オブ
ジェクト帯サービスのよびだしを処理及び完了するために潜在的に必要なあらゆ
るデータを含むことができるが、それに制限されない。例として、１−８００サ
ービスが企業カスタマ用のサービス作成で設定されるとき、ＯＥシステムから受
取るカスタマの名称、料金／請求情報、８００電話番号、受信側のネットワーク
アドレス、サービスオプション（ルーチング特徴、マルチメディアファイル識別
子）が、特定のサービスをＰＲＯＶＩＳＩＯＮするために必要である。この機能
では、サービス管理３００が適切なオーダーエントリー送り機構を解析して、Ｎ
ＧＩＮに統合した矛盾のないオーダーエントリー記録を作って、オーダーエント
リーシステムから又は供給システムから受取る各送り機構が肯定応答されること
を保証する。

【００７０】 第３：ＳＡコンポーネント５００は、サービスサポート供給、つまりＮＧＩＮ
の処理環境の構成（ハードウェア、オペレーティングシステム、ＳＬＥＥ、サイ
ト、サイトＬＡＮ、及びサイト間ＷＡＮ）とこれら構成を指定するデータの供給
を担う。具体的には、各ＩＤＮＡ／ＮＧＩＮサービスノードは、環境供給サブコ
ンポーネント５０８（図５（ｃ））を介してＳＡに入力され、計算システムの能
力を指定する関連サービスをもち、計算システムが割当てられる機能とサービス
の種類はそのサービスノードでサポートできる。ＳＡでフォーマット化されたデ
ータファイルとして具現できる、例のサービスノードプロフィールを、以下のよ
うに表１に表す。

【表１】 このように、表１の例のプロフィールでは、次のことが指定される。ノード名、
コンピュータが実装するサービスの論理プログラム用のオペレーティングシステ
ム、メモリ容量、ディスク及びデータの通信装置、ノードがＳＡからカスタマ固
有のデータを受信できることの表示（データ管理アクセス）、及びノードが特別
なサービス特徴、例えば音声再生機能をサポートできることの表示。例の表１に
は、資源の量に関連する他の種類の情報及び特定のサービスノードに関連する機
能を含むことができることは理解されるべきである。

【００７１】 各サービスのためにＳＡで追加的に生成するものは、サービスプロフィールで
、これはＳＡのフォーマット化されたデータファイルとして具現でき、そのサー
ビス＝ｓの要求事項とネットワーク内に配置するべきＳＬＥＥ及び／又はコンピ
ュータを指定する。ネットワーク内に特定のサービスを配置するための例のサー
ビスプロフィールを以下のように表２に表す。

【表２】

【００７２】 表２では、以下のことが指定される。例えばカスタマＸ用のサービス１００１
番などサービスプロフィール名；インスタンス生成時にサービスを実行するため
に必要な処理ユニット、メモリ、及びディスク空き容量；特定のサービス（例え
ばサービス論理プログラムとして具現される）がサービス管理に規定される所定
のビジネス規則に従ってインスタンス生成するときに、時間範囲を指定するノー
ドインスタンス生成フィールドと、指定される時間範囲中にＮＯＳがインスタン
ス生成できるそのサービスオブジェクト（ＳＬＰ）の最小数及び最大数を示す対
応する最小／最大フィールド；例えば、サービスが特定のサービスノード機能、
例えば音声再生などを要求することを示す特別要求事項フィールド；サービス開
始日及びサービス終了日。ノードは明らかにメモリの要求事項と音声再生サポー
トをもつため、ＳＡが表２の例のＳＡ１００１のサービス（及びサービスプロフ
ィール）を、表１に表すサービスノードプロフィールを有するサービスノードに
分配できることは容易に明らかであろう。さらに、表２のサービスプロフィール
に表される例のサービス１００１番には、特に、カスタマＸが提供するそのサー
ビス１００１番に固有の音声再生サービス通知から構成されるであろう、カスタ
マＸからのデータセットが必要であろう。ＳＡコンポーネント３００は、カスタ
マＸの音声再生通知を含むオーダーエントリー送り機構３０７を介してデータを
受信し、ＳＡ＝ｓのインベントリマネージャーはそれを、例えばＤＢＯＲ２３０
に記憶するためにデータセット１００１番に割当てる。このように、ＳＡはデー
タセット１００１番を、カスタマＸにサービス１００１番を提供するサービスノ
ードに自動的に分配できる。

【００７３】 これらサービスノードプロフィール（例、表１）及びサービスプロフィール（
例、表２）はＳＡに入力されて、それに記憶されて、１）各サービスノードの能
力、つまりコンピュータ及びＳＬＥＥの数とそれぞれの資源容量、２）どのサー
ビスおよびデータがどのサービスノードにいつ配置されるか、３）サービスの実
行の構成、つまり例えばいつの時点でＳＬＰを要求に対して持続的に実行するか
、という自動追跡を可能にする。ネットワーク内の各ノードとコンピュータの能
力を維持して、データ／サービスの分配、データ／サービスの起動、及びデータ
／サービスの解除を支配する単純及び複雑なビジネス規則を適用して、ＩＤＮＡ
／ＮＧＩＮのサービスノードでのサービスの実現を最適にする。このように、サ
ービスサポート供給機能の一部は、例えば、サービスノード間の負荷バランス、
ネットワーク呼出しルーチングの効率、及びサービス要求などの１つ以上の基準
に基づいた規則で、どのサービスをどのＳＬＥＥで持続的なオブジェクト（能動
的に実行する）としてインスタンス生成するか決定する。このサービスサポート
供給機能の例をここで説明する。あるサービスは他のサービスよりも時間に敏感
なため、発信者がある種のサービスでの遅れにもつ許容の程度を使用して、その
サービスが持続的なオブジェクトとしてＳＬＥＥで能動的に実行するかどうか、
例えば、そのサービスのデータをローカルメモリにキャッシュして待ち時間を短
縮するかどうか決定する。サービスの需要を考慮するとき、あるサービスは、例
えば夜に需要のピークを迎えることがある。このためＳＡ５００は、ユーザがこ
のサービスのためのＳＬＰを指定して、例えば、各サイトに従った現地時間で、
午後５：００から夜中の１２：００まで能動的に実行し（ＳＬＥＥで持続的オブ
ジェクトとしてインスタンス生成する）、他の時間は要求時のみインスタンス生
成できるようにする。ＳＡが生成するサービスプロフィールファイル（表２）の
規則はこれを反映している。

【００７４】 第４：ＳＡコンポーネント５００は、カスタマが指定する戦略に従って、サー
ビス及びデータを選択したＩＤＮＡ／ＮＧＩＮシステムノードのローカルデータ
管理機能コンポーネントに分配することを担う。これら戦略は、サービス作成環
境２２８で作成されるサービスパッケージの仕様として、またそのサービスサポ
ート供給機能の一部として、ＳＡ５００を介してユーザが入力する仕様として具
現される。この機能に含まれるものは、ＳＡがデータ、ＳＩＢＢ、及びＳＬＰの
現状を追跡する能力である（例、試験、配置）。状態を追跡するだけでなく、さ
らにサービスの特定のバージョン（様々な従属を含む）を作成するために必要な
データ、ＳＩＢＢ、ＳＬＰおよびさまざまなコンポーネント（つまり、データ、
ＳＩＢＢ、およびＳＬＰ）の現在のバージョンも追跡する。グローバルＤＢＯＲ
では、ＳＡはサービスの各バージョンを記憶し（つまり、サービスＳＬＰにカプ
セル化されるすべてのＳＬＰを含む）、さらに、ＩＤＮＡ／ＮＧＩＮネットワー
ク全体で、例えば、ＤＢＯＲ抽出などの様々なデータ管理リポジトリの構成（例
、物理的なアドレス）を追跡する。

【００７５】 さらに、ＳＡコンポーネント５００は、保全性を確保するために、分配された
サービスとデータを追跡する。例えば、サービスが上手くノードに配置されるが
、そのサービスに必要なデータの分配が失敗する場合、ＳＡはこれを検出し、デ
ータの分配を再試行するか、又はユーザに通知する。所定の構成可能な数の再試
行の後、指定されたリポジトリが分配を受信できない場合、ＳＡはアラームを発
して、保留中の分配を記憶する。

【００７６】 データ、ＳＩＢＢ及びＳＬＰをデータ管理に分配するためのＳＡ分配機能に加
えて、ＳＡはさらに以下のことを担う。１）端末相互通し試験のために、ＳＬＰ
、ＳＩＢＢ及びデータをネットワーク統合試験環境に分配する、２）許可された
ユーザが分配のための事前設定した時間、例えば、現在（オンデマンド）、本日
正午、明日午後３時などを構成できるようにする、３）事前設定した時間に基づ
いて分配を開始する、例えば、音声ファイルを明日午前１：１５時に配置する。
４）どのＮＧＩＮデータ管理リポジトリがＳＬＰ、ＳＩＢＢ及びデータを受信す
るか指定する分配規則を定義する、５）所定の分配規則に基づいて、データを分
配する場所を決定する、６）分配前に指定されるリポジトリの状態を検査する（
ＮＧＩＮ ＮＯＳコンポーネントを照会することによって）、７）オンライン表
示を報告するすべての指定リポジトリに分配を試みて、指定リポジトリがオフラ
イン表示を報告している場合には、将来の転送のためにそのリポジトリのために
分配を記憶する、８）オンライン表示を以前にオフラインだった指定リポジトリ
から受信したら、保留中のすべての分配をリポジトリに転送する、９）データ管
理への分配を監視する。例えば、分配が既存のＳＬＰ、ＳＩＢＢ又はデータ構成
要素の新バージョン用である場合、ＳＡは、分配を受信したときに、既存のデー
タをデータ管理で上書きしないことを保証する、１０）データ管理から成功又は
不成功の分配の状態表示を受取り、データ管理から受取る成功／不成功の分配状
態に基づいてすべてのデータの状態を更新する、１１）すべての分配をデータ管
理に記録する。

【００７７】 この点で、図５（ｄ）に描写するように、ＤＢＯＲ２３０を更新するために必
要な内部プロセスと、図５（ｅ）に描写するように、ＤＢＯＲからサービスパッ
ケージ及びデータ抽出を分配するために必要な内部プロセスを区別する必要ある
。ＤＢＯＲ２３０で保持されるデータのフォーマットは、外部ソースから入力さ
れるデータのフォーマット、及び分配のための抽出のデータのフォーマットとは
異なるため、個別のプロセスが必要である。そのため、データの完全性と同期を
有意義に監査及び保証するために、図５（ｄ）に描写されるＤＢＯＲの更新プロ
セスには、インベントリマネージャープロセス５１６とＤＢＯＲマネージャープ
ロセス５２０の呼出しが必要である。ＤＢＯＲから様々なＳＡエージェント（Ｄ
Ｍクライアント）にデータを抽出するとき、図５（ｅ）に描写するように、環境
マネージャープロセス５３０とＤＢＯＲマネージャープロセス５２０の呼出しが
必要である。このように、これら個別プロセスを実行すると、ＤＢＯＲを入力シ
ステムのデータで監査でき、ＤＢＯＲをデータ管理に分配される又は分配された
抽出データで監査できる。

【００７８】 第５：ＳＡコンポーネント５００は、上手くサービスノードに配置されるサー
ビスを起動する、つまりデータ、ＳＬＰ、又はＳＩＢＢをサービス処理で利用で
きるようにすることを担う。ＳＡサービス／データの起動とエラーが発生したと
きに必要な処理に属する要求事項には以下のことが含まれる。１）すべての分配
従属性（ＭＯＣＥ／ＳＣＥ２２８に定義される）は、ＳＬＰ、ＳＩＢＢ又はデー
タの起動を許可にする前に、完全であることを保証する。従属性の例は、ＳＬＰ
が特定のデータベースの仕様を必要することであろう。このため、ＳＡは、ＳＬ
Ｐの起動を許可にする前に、データベースを分配して起動していることを保証す
る。２）ＳＬＰ、ＳＩＢＢ又はデータ構成要素の起動前に、その指定リポジトリ
への分配状態を検査する、３）分配状態に基づいて、以前に分配されたデータが
上手く分配を受信されたすべての場所で起動できるかどうか、従属性、完了状態
及び所定の分配規則を決定する。ＳＡが、分配されるデータを起動できると判断
する場合、ＳＡはデータ管理に起動要求の送信を試みる。４）起動要求を送信す
る前に、指定リポジトリの状態を検査する（ＮＧＩＮ ＮＯＳを照会することに
より）、５）オンライン表示を報告するすべての指定リポジトリで起動を試みて
、指定リポジトリがオフライン表示を報告している場合には、将来の転送のため
にそのリポジトリのための起動要求を記憶して、そのリポジトリでは起動を試み
ない。指定リポジトリがオンライン表示を報告しているのに、何らかの理由のた
めに起動要求を処理できない場合、ＳＡはそのリポジトリへの起動を再試行する
。所定の構成可能な数の再試行の後、指定リポジトリが起動要求を処理できない
場合、ＳＡはアラームを発し、保留中の起動を記憶する。以前オフラインだった
指定リポジトリからオンライン表示を受取ったら、サービス管理は保留中の分配
及び起動をすべてそのリポジトリに転送する。６）データ管理から起動応答を受
信する。起動要求がすべての指定リポジトリでの成功を表示したら、ＳＡはデー
タ、ＳＩＢＢ又はＳＬＰのシステム固有名をＮＯＳで情報の物理的な場所を登録
する。物理的な場所の名前には、ハードウェアコンポーネントの名前の識別名が
含まれることは理解されるべきである。

【００７９】 好適な実施形態では、ＳＡは、所定の分配規則とデータ管理４００から受信す
る起動応答に基づいて、データがサービス制御管理オブジェクトで利用できるた
めに十分な場所で起動されたかどうかを判断する。サービス管理がデータがサー
ビス制御で利用できると判断する場合、ＳＡはシステム固有のデータ名と成功し
た分配先すべての物理的なデータの場所及びＮＯＳをもつ起動の場所を登録する
。起動されたデータがネットワーク内の既存のデータを置き換える場合、ＳＡは
、新しいデータに新しいサービス処理を開始しながら、古いデータで既存のサー
ビス処理を完了するスムーズな変換プロセスを保証する。これにより詳細に説明
するように、すべてのサービス処理がそこで完了したら、古いデータは非活動化
する。

【００８０】 より具体的には、サービス／データ起動工程の一部として、ＳＡは適切な時間
でサービスプロフィールをダウンロードさせるトリガーを実行する。サービスプ
ロフィール（例、表２に図示するとおり）はサービスノードにダウンロードされ
るとき、サービスプロフィールはサービスの開始時間と終了時間を含む。サービ
スプロフィールは、図５（ｆ）に関してより詳細に説明するように、情報をデー
タ管理に供給することによってサービスノードをダウンロードする。ＤＣクライ
アントとして作用するＮＯＳには、ＤＭ ＡＰＩを介してサービスプロフィール
の情報の変更が通知される。好適な実施形態では、ＳＡは各ＳＬＥＥでＮＯＳ名
前変換（「ＡＮＴ」）機能にメッセージを送信し、その各ＳＬＥＥで、サービス
を実行して名前変換機能を指示し、サービスの論理名を起動するバージョンの物
理的なアドレス又はオブジェクト参照に再指定する。

【００８１】 最後に、ＳＡは、データ、ＳＩＢＢ、又はＳＬＰが起動されるときに、適切な
プラットフォーム上で作動することを保証するリポジトリプラットフォーム特徴
を追跡する；起動又は不活動化に基づいて、データ、ＳＩＢＢ、又はＳＬＰの状
態を更新する；データ、ＳＬＰ、及びＳＩＢＢのすべての起動を監視論理コンポ
ーネント５４０（図５（ｃ））で記録する。

【００８２】 この第５番目の機能に従って、ＩＤＮＡ／ＮＧＩＮシステムがどのようにサー
ビス構成及び配置段階を処理するかの説明を、ここで図５（ｇ）及び５（ｈ）を
参照して行うが、この図はＩＤＮＡ／ＮＧＩＮシステムのために、つまり１−８
００コレクト（「１８Ｃ」）サービスのためにＳＬＰを構成及び配置する工程の
シナリオを図示している。図５（ｇ）の工程３３０で示すように、ＭＯＣＥ／Ｓ
ＣＥアプリケーションプログラムは、ユーザがＳＡから、１８Ｃ ＳＬＰの政策
に必要なＳＩＢＢ、ＳＬＰ、データ及び他のビルディングブロックのすべてにア
クセスできるようにする。例の１８Ｃサービスの状況では、上記ビルディングブ
ロックには次のものを含めることができる。プレイオーディオビルディングブロ
ック、集合ディジットビルディングブロック及び音声認識ビルディングブロック
。これら適切なビルディングブロックのコピーが、ＳＡによってグローバルＤＢ
ＯＲからＭＯＣＥ／ＳＣＥに出されて、図５（ｇ）の工程３３２で示すように、
１８Ｃサービス論理プログラムを開発するための基礎を提供する。また、工程３
３４で示すように、１８Ｃサービス論理プログラム及び音声ファイルなどの関連
するデータすべては、ＭＯＣＥ／ＳＣＥ内で試験されるユニットである。次に、
工程３３６で示すように、１８Ｃサービス論理プログラムは実時間ＭＣＩネット
ワークと非常に似た実験室環境で端末相互通し試験されて、サービス論理プログ
ラムは一旦ネットワークに分配されると正確に実行される。さらに、工程３３８
で示すように、１８Ｃサービス論理プログラムは、その分配前に、これに詳細に
説明する方法で命名及びカタログ化するためにサービス管理に提示される。

【００８３】 これに説明するように、サービス管理コンポーネントは、データ及び情報の分
配、データの起動及びデータの解除を支配する規則を導入することが可能である
。そのため、工程３４０で示すように、ＳＡコンポーネントは、ＳＬＰを受信す
るデータ管理リポジトリを指定する規則、及び１８Ｃ ＳＬＰの起動を許可する
前に、分配を受信しなければならない最低数のリポジトリに関する規則を検査す
る。これをするために、工程３４２で示すように、サービス管理は、これに説明
するように、ＮＯＳネットワーク資源管理機能にアクセスすることによって、ロ
ーカルＤＭリポジトリの状態を検査する。さらに、図５（ｈ）の工程３４４で示
すように、サービス管理コンポーネントは、「オンライン」状態を示すそのＤＭ
リポジトリを判断して、工程３４６で、１８Ｃ ＳＬＰをオンラインのＤＭリポ
ジトリすべてに分配する。オフライン状態を報告するリポジトリに関して、サー
ビス管理は、工程３４８で示すように、将来オフラインリポジトリに転送するた
めに、分配を記憶する。次に、工程３５０に示すように、サービス管理コンポー
ネントは、データ管理が分配の成功又は失敗を示す各リポジトリの状態が戻るま
で、ユニットを待機させる。工程３５２で判断が行われて、各ＤＭリポジトリか
ら確認を受信したかどうかを判断する。確認が受取られなかった場合、ＳＡは工
程３５５で示す確認を待つ。確認が受取られたら、プロセスは工程３５４に進み
、そこで１８Ｃ ＳＬＰが分配が上手く受信されたリポジトリすべてで起動でき
るかどうかをサービス管理で判断を行う。

【００８４】 具体的には、サービス管理は、１８Ｃ ＳＬＰが以下の起動基準の組合わせに
基づいて起動できるかどうかを判断する。１）分配の状態、２）データ従属状態
、３）所定の規則。これは、サービス管理５００が、サービス論理プログラムの
すべてのデータの従属が完了すること、つまり、上記データに従属するＳＬＰの
起動を許可する前に、分配及び起動することを保証する機能を行うためである。
このように、例の状況では、１８Ｃ ＳＬＰがその実行中に別のサービス論理を
使用する場合（例、ライン情報データベースへのインターフェースＳＬＰ）、サ
ービス管理が、他のＳＬＰ又はデータベースが１８Ｃ ＳＬＰの起動を許可する
前に分配及び起動されたことを保証する。あるサービスは、たとえ指定リポジト
リがすべてサービス論理プログラムの分配を受信しない場合でも、起動できるこ
とは理解されるべきである。これは以下のようないくつかの要因に依存する。Ｓ
Ａの分配及び起動規則で規定されるように、予想呼出し量、およびサービスの質
。たとえば、ある呼出し量の少ないサービスは起動される前にネットワークの２
つのＤＭリポジトリで記憶されるだけで十分なことがあり、一方サービスが指定
リポジトリすべてに位置してから、トラフィックを受取るために起動することを
要求するものもある。

【００８５】 このように、図５（ｈ）の工程３５６では、さらに起動基準の適合に基づいて
判断がなされる。ＳＬＰが起動できない場合、工程３６０に示すように、ＳＡは
、ＳＬＰの起動基準が満たされるまで待機する。そうでない場合、工程３５８に
示すように、ＳＡは指定データ管理リポジトリすべてに起動要求を送る。さらに
、工程３６２に示すように、データ管理は起動要求を処理して、各リポジトリに
関する起動応答を、起動の成功又は失敗を示すサービス管理に転送する。データ
管理から受取る成功した起動応答に基づいて、サービス管理は、工程３６４に示
すように、１８Ｃ ＳＬＰシステムの固有名とＮＯＳのある物理的なデータの場
所を登録し、例の状況では、ここで１８Ｃサービスが利用できるようになる。１
８Ｃ ＳＬＰの分配及び／又は起動を受信できなかったデータリポジトリは、こ
のサービス論理プログラムの有効な物理的なデータの場所として、ＮＯＳととも
に登録されない。

【００８６】 第６：ちょうどＳＡがサービスコンポーネントの分配及び起動ができるように
、ＳＡコンポーネント５００はサービスノードからサービスコンポーネントの廃
棄及び解除を提供する。関係する主要な工程は、その関連部分の計画、非活動化
、アンインストール、及び／又は廃棄、及び不良結果の試験である。例えば、サ
ービスの不活動期間の後、又はユーザが指定するように、サービスがあるノード
でもはや必要ない場合、典型的にはＮＯＳ ＮＴにメッセージを送って、サービ
ス管理が解除される、つまりサービスを非活動化して、ローカルデータ管理コン
ポーネントにメッセージを送ることによってＩＤＮＡ／ＮＧＩＮサービスノード
からサービスを解除して、そのサービスを削除することができる。サービス／デ
ータの非活動化及び解除のＳＡ機能に属する要求事項には以下のことが含まれる
。１）許可されたユーザがＳＬＰ、ＳＩＢＢ又はデータ構成要素の非活動化を要
求でき、非活動化の期間を指定できる、２）ＳＬＰ、ＳＩＢＢ、またはデータの
状態とデータ従属性を検査してから、データ管理に非活動化の要求を転送する。
ＳＬＰ、ＳＩＢＢ又はデータの状態が活動していて、データ従属性が存在しない
場合、ＳＡは、ＳＬＰ、ＳＩＢＢ、またはデータがもはやサービス処理を利用で
きない指定時期になるとき、ＮＯＳでＳＬＰ、ＳＩＢＢ又はデータの登録を抹消
する。３）ＮＯＳで名前の登録抹消を完了した時点で、特定のＳＬＰ、ＳＩＢＢ
又はデータ項目の非活動化の要求をデータ管理に転送する。ＳＬＰ、ＳＩＢＢ、
又はデータの状態が活動していない、又はデータの従属性が存在しない場合、Ｓ
Ａは非活動化の要求を無視し、要求者に通知する。４）データ、ＳＬＰ、及びＳ
ＩＢＢの非活動化すべてを記録する。５）許可されたユーザがＳＬＰ、ＳＩＢＢ
又はデータ構成要素の解除を要求できるようにし、解除の時期を指定する。６）
ＳＬＰ、ＳＩＢＢ又はデータの状態を検査してから、解除要求をデータ管理に転
送する。ＳＬＰ、ＳＩＢＢ又はデータの状態が非活動化されている場合、ＳＡは
指定時期になった時点で解除要求をデータ管理に転送する。ＳＬＰ、ＳＩＢＢ又
はデータの状態が非活動化されていない場合、ＳＡは解除要求を無視して、要求
者に通知する。７）データ管理からデータ、ＳＬＰ、ＳＩＢＢの解除すべてを記
録する。

【００８７】 サービス／データの起動に関して前述したように、ＳＡ５００のトリガーはＳ
Ａに適切な時期にサービスノードからサービスプロフィールを解除するためのコ
マンドをダウンロードさせる。このコマンドはデータ管理４００へのコマンドに
よってサービスノードに送られる。データ管理はそのテーブルを更新し、その結
果ＤＭクライアントとして作用するＮＯＳはサービスの変更の通知を受取る。

【００８８】 図５（ｉ）は、供給される１−８００コレクトＳＬＰサービスの例を参照して
、サービスの非活動化プロセスを図示する。図５（ｉ）に図示するように、最初
の工程３６８は、１８Ｃサービス論理プログラムを無効にする決定と、１８Ｃサ
ービス論理プログラムを解除する影響を試験するためにＭＯＣＥ／ＳＣＥの利用
に関わる。さらに、工程３７０に示すように、ＳＡは１８Ｃサービス論理プログ
ラムの無効に関わる規則を検証する。具体的には、サービス管理が、１８Ｃサー
ビス論理プログラムで活動する他のサービス論理プログラムの従属がないことを
検査して確認する。従属性が存在する場合、従属サービス論理プログラムが本当
に必要かどうか、計画工程を繰り返すかどうかを決定するための詳細な調査が必
要である。従属性が存在しない場合、サービス管理は、許可されたユーザが非活
動化の時期を指定できるようにする。ＳＬＰを無効にできると判断されたら、Ｓ
Ａは、工程３７２に示すように、非活動化要求を１８Ｃ ＳＬＰを内蔵するデー
タ管理リポジトリすべてに送る。データ管理は、工程３７４に示すように、非活
動化要求を処理し、非活動化応答を非活動化の成功又は失敗を示すＳＡに送る。
１８Ｃ ＳＬＰの非活動化が成功した時点で、ＳＡは、工程３７６に示すように
、ＮＯＳで１８Ｃ ＳＬＰの登録を抹消して、１８Ｃ ＳＬＰがもはやサービス
処理で利用できないようにする。このように、その後のサービスの要求は１８Ｃ
ＳＬＰを利用できなくなる。さらに、工程３７８で示すように、ＳＡは、許可
されたエージェントが存在するデータ管理リポジトリから１８Ｃ ＳＬＰすべて
を解除する時期を指定できるようにする。指定時期になったら、ＳＡは、工程３
８０に示すように、解除要求を１８Ｃ ＳＬＰを内蔵するデータ管理リポジトリ
すべてに送り、データ管理がそのリポジトリから１８Ｃサービス論理プログラム
を削除して、１８Ｃはもはや利用できなくなる。

【００８９】 第７：ＳＡコンポーネント５００は、監査を行うことを担う。サービス又はデ
ータ構成要素がＤＢＯＲに入力される前に、サービス管理がすでに使用されてい
る他のサービス／データ構成要素をもつ構成要素を監査して、矛盾が存在しない
よう保証する。同様に、サービス／データ構成要素がサービスノードに分配され
る前に、矛盾が存在しないことを監査して確認する。サービス管理はサービスノ
ードに分配されるＤＢＯＲ２３０のサービス及びデータ両方のプロセストリガー
監査とスケジュールトリガー監査の両方を提供する。プロセストリガー監査は、
不測の失敗の結果開始される監査である。例えば、ＳＡがサービスプロフィール
をダウンロードしようとして、プロフィールがすでに存在するためにダウンロー
ドが拒絶される場合、ＳＡはどうするかを判断するために監査を開始する。例え
ば、ＳＡはすでに存在するサービスをダウンロードしようとしたものと比較して
、それが同じか違うかを判断する。それが同じである場合、監査はそこで停止さ
れるであろう。それが異なる場合、監査プロセスは既存のプロフィールの削除を
開始して、正しいものをダウンロードする。スケジュールトリガー監査は、所定
のスケジュールに従って、又はシステムのアイドル時間中に又はユーザの要求に
より、監査ルーティンを開始するプログラム化された規則に従って、トリガーさ
れる。これらＳＡ監査規則は、ＳＡシステム５００のコンパイル済みコードとし
て、及びＳＡシステム内部で処理される解読規則として管理される。

【００９０】 再び図４を参照して、ＮＧＩＮデータ管理コンポーネント４００は、サービス
の寿命及びサービスの利用能力両方で機能する。サービス管理コンポーネントが
グローバルなデータベースの記録（リポジトリ）を保持する場合、データ管理コ
ンポーネント４００は各ＩＤＮＡ／ＮＧＩＮサービスノードにローカルデータ記
憶機能及びデータ管理機能を提供する。これには、以下のようなすべての種類の
データを含む。サービスプログラム及びＳＩＢＢ、サービス用のデータ（カスタ
マプロフィール、電話番号など）、マルチメディアファイル（対話型音声応答
（「ＩＶＲ」）サービスなど）など。具体的には、サービスノードのデータ管理
コンポーネント４００は、サービス管理が指定するローカルＮＧＩＮサービスノ
ードが行うサービスに必要なすべてのデータからなるＳＡグローバルＤＢＯＲの
抽出を受取る。これの機構は図５（ｆ）に関してこれ以降より詳細に説明する。

【００９１】 図５（ｆ）は、各ＩＤＮＡ／ＮＧＩＮサービスノードにローカルデータ記憶及
び管理機能を提供するＳＡコンポーネントのデータ管理コンポーネント４００を
図示する。具体的には、データ管理は１つ以上のデータベースのサービス管理か
ら受信するデータを記憶し、必要なデータをサービス制御コンピュータにある、
又は同じ場所にあるデータベースサーバーにあるメモリにキャッシュすることに
よって、サービス／データがサービス制御環境を容易に利用できるようにして、
サービス／データが最小の待ち時間でサービス制御サービスに提供できるように
する。より一般的には、データ管理コンポーネント４００は、サービス管理から
受取るか、又はサービス処理の結果として受取るかに関わらず、データの実時間
の記憶、複製、同期、及び利用を行う。ここで説明するように、これらデータ管
理機能はさらに次のように分類できる。１）データリポジトリ機能、２）データ
操作機能、３）データ利用機能、４）請求記録作成機能である。

【００９２】 データ保管機能 データ保管機能は、ＩＤＮＡ・ＮＧＩＮデータの記憶において求められる全て
の固有な機能性から構成される。一般に、データの保管所とは、例えば、ヴォイ
スファイル、オブジェクト、ＳＬＰ、ＳＩＢＢおよびデータベースなど、情報の
異なる全ての形式を保存する物理的装置である。データの保管所を管理する際、
データ管理機能について、保管場所の安全性、不具合ならびに構成管理が考慮さ
れる。

【００９３】 データ管理における保管所の記憶面では、１）永続データ、ＳＩＢＢ、ＳＬＰ
、オーディオファイル、コール文脈データ、スケジュールデータ、ファックスな
どのテキストファイルを保存する能力、２）保管所から消去される前にコール文
脈データを２、３日保存しておくことができる等の時間的な設定可能期間を特定
するデータを保持する能力、３）保管期間満了により特定データをその保管場所
から自動的に削除する能力、ならびに４）複数に及ぶ様々な保管データバージョ
ンをサポートする能力が含まれる。

【００９４】 記憶機能の一部として、データ・マネージメント４００では、問合せおよび配
布がオンライン上で動作している保管所に対してのみ行われるように、その保管
所の状態をチェックすることができる。このため、ある保管所がオフラインとな
っている場合、その保管所に対し問合せや配布は行われないことになる。この機
能の一部として、データ・マネージメントでは、各保管所が現在処理しているト
ランザクションに関しその保管所がどれほど多忙であるかを示している利用状態
の確認を行ったり、初期化においてＮＯＳ７０へ保管所の状態情報を送信したり
、状態に変更が生じたために、保管所がオフラインに変わるか、機能していない
場合にアラームを発生させるなど、保管所の状態について問合せを行い得るとと
もに、ＮＯＳ７００に対しオフライン状態にあることが報告されている保管所に
以降問合せや更新を発信しないように通知を行うことができる。

【００９５】 さらに、記憶機能の一部として、データ・マネージメントにより、構成管理、
不具合管理ならびにデータ保管所のログ管理を行える。構成管理に係わるＤＭ機
能により、権限のあるユーザは、データ保管所のスキーマの画定および拡大が可
能であるほか、保管所に割り当てられているシステム資源の問合せおよび変更、
ならびに戦略を指し示すｒｅｐｏｓｉｔｏｒｙ＝ｓの問合せおよび変更が可能と
なる。不具合の検出ならびにデータ保管所の保守に関するレポートの作成に係わ
るＤＭ機能には、保管所に割り当てられるシステム資源に関する不具合しきい値
および通知の画定を可能とする能力や、保管所内における媒体の不具合の検出お
よび報告、ｒｅｐｏｓｉｔｏｒｙ＝ｓの容量を満たす百分率に対する不具合しき
い値および通知の画定、ｒｅｐｏｓｉｔｏｒｙ＝ｓのログを満たす百分率に対す
る不具合しきい値および通知の画定を可能にする能力、ならびに保管所またはそ
のコンポーネント類のうちの一つ（例えばスキーマや保管データなど）が破損し
た際の通知が含まれる。データ・マネージメントにより所有される保管所におけ
るログの確立および管理に係わるＤＭ機能には、（ａ）トランザクションログ、
（ｂ）エラーログ、（ｃ）イベントログなどのこれらのログ形式を含み、保管所
における能力を記録する能力や、これらのログを外部媒体に保存する能力が含ま
れる。また記録する機能に関し、データ・マネージメントでは、ログを再度初期
化する前の設定可能期間においてログデータを保持し得る。さらに、権限のある
ユーザは、保管所におけるログの特性（例えばサイズやフィールド記述、イベン
トレポート方法など）の問合せや変更が行えるとともに、各ログに書き込まれる
データを特定することができる。例えば、トランザクションの量により、ユーザ
は、トランザクションログに、全てのトランザクションではなく「書込み」トラ
ンザクションのみを取り込むことが可能である。

【００９６】 ＤＭ操作機能 ＤＭのデータ・マニピュレーション機能は、配信されるデータの受信、保管所
をまたがるデータの複製、保管所内のデータの問合せ、検索および更新、トラン
ザクションの打ち切りおよびロール・バックの開始、ならびにデータ監査の実施
に求められる全ての固有な機能性から構成される。この機能性は、ａ）データ・
ディストリビューション、ｂ）データ・レプリケーション、ｃ）データ・リトリ
ーバル・アンド・アップデート、ｄ）データ・トランザクション、ｅ）データ・
オーディットの各領域に細分されるが、以下において、その一つ一つについて説
明を行う。

【００９７】 データ分配 ここで定義付けられるデータ分配とは、サービス・アドミニストレーションか
らデータ・マネージメント４００へのデータまたはサービスの分配を参照してい
る。データ分配機能に関し、ＤＭは、サービス・アドミニストレーションから配
信されるデータを受信し、システム内で展開されるデータの状態について報告を
行うとともに、各サービスに対しデータの使用を可能とするほか、データ・マネ
ージメントにより記憶されるデータの活動性を無効とし、それを排除する。

【００９８】 特に、データのサーバやＤＤ ＡＰＩ、ＤＢＯＲ抜粋保管所およびＤＢＯＲ抜
粋マネージャーのコンポーネント類（ＤＭ４００の図５（ｆ）） により具現化
されるように、データ・マネージメントは、サービス・アドミニストレーション
から配信されるデータやファイル定義、ＳＬＰおよびＳＩＢＢを受信するために
有効化される。保管所の容量が超過状態にある場合、配信されるデータを許容し
ようとする更なるあらゆる行為は、保管所内のデータへのアクセスが阻害される
ことなく遂行されない。ＤＭからＳＡへのデータの配信に応じて、ＤＭサーバ内
で実行されているプロセスは、配信の成功または失敗を示す信号によりＳＡに応
答する。データの配信に失敗した場合、ＤＭは、完了されなかったあらゆる配信
部分をもう一度やり直す。説明されているとおり、作動要請信号は、保管所の最
小限数に対しデータが成功裏に配信されたことを示すためにＳＡから配信され、
サービスの処理工程を「作動」させる。データ・マネージメントは、データ、Ｓ
ＩＢＢまたはＳＬＰの各作動の成功・不成功に基づき成功または失敗を示す作動
応答をサービス・アドミニストレーションに返信することにより、作動要請の受
信に対し応答を行う。ＤＭは、また、特定のデータ、ＳＬＰまたはＳＩＢＢをサ
ービス処理に対し無効とするためにサービス・アドミニストレーションから送信
される、ＳＡからの停止要請を受信し、処理することができる。データ・マネー
ジメントは、要請された停止の成功またはは失敗を示す停止応答をサービス・ア
ドミニストレーションに送ることにより、停止要請に対し応答を行う。

【００９９】 同様に、ＤＭは、さらに、ＤＭが特定のデータを指定された保管所から排除す
べくそれを指定するサービス・アドミニストレーションからの排除要請信号を受
信し、処理することも可能である。ＤＭは、排除要請の成功または失敗を示す排
除応答を、サービス・アドミニストレーションに返信する。但しここで、作動、
停止および排除要請は、ＳＬＰ、ＳＩＢＢまたはデータエンティティに対して可
能であることについて、十分理解されるべきである。

【０１００】 データ・レプリケーション ＤＭのデータ・レプリケーション機能には、特定の場所、すなわち、ローカル
サーバ貯蔵所であるサービスノードデータ保管所にデータを複製するために、ま
たＮＯＳに複製の成功・不成功を通知するために求められる全ての固有な機能性
が含まれる。ＩＤＮＡ・ＮＧＩＮシステムでは、ＳＡの構成ファイルにより提供
される定義済みの複製手段に基づきデータの複製を行う。ここで述べられる「複
製」という用語は、サービス処理の一環としてデータの書込みを行うためにデー
タを一つの保管所から別の保管所へ複写する行為を参照している。

【０１０１】 例えば、データ・マネージメントは、サービス処理中にデータが更新される際
にデータを他の保管所に複製する。初めに、データ・マネージメントは、ＳＡに
よりデータ入力用の構成ファイル内で提供される確立されている複製規則に基づ
きデータを複製する場所一式を決定するとともに、ターゲットとなっている保管
所の容量が超過したときに保管データを複製しようとする試みが、その保管所内
に現存するデータへのアクセスが妨害されることなく不首尾に終わるように操作
を行う。容量の超過により複製が行われなかった場合、データ・マネージメント
は、ＮＯＳコンポーネントに対し、その保管所に対し以降複製が再度試みられな
いように、特定されたデータがこの保管所において入手できないことを通知する
。保管所への複製が容量以外の理由により失敗した場合、データ・マネージメン
トは、その保管所に対し失敗した複製を再度試みることになる。事前に決定され
た再試行設定可能数終了後においても未だその保管所が複製信号を受信できない
場合、データ・マネージメントはアラーム信号を発信し、ＮＯＳコンポーネント
に対し、複製されるべく特定されたデータがこの保管所において入手できないこ
とを通知する。これにより、この場所に対しこのデータに関する問合せは行われ
なくなる。同期化ユティリティは、このため、保管所を同期化において元に戻そ
うとする。

【０１０２】 データ・リトリーバル・アンド・アップデート データ・リトリーバル・アンド・アップデートにおける機能性には、サービス
処理中にデータ・マネージメントにより記憶されるデータへアクセスするための
能力が含まれる。

【０１０３】 好ましい実施形態では、データ・マネージメントは、あらゆる特定のサービス
ノードにおいて、例えばＮＯＳを介し、サービス処理中に実施されるＳＬＥＥ内
で管理されるオブジェクトインスタンスを実行することにより発信されるデータ
要請信号を受信する。データ・マネージメントは、特に、要請者に対し（例えば
管理されているオブジェクト）、データ要請を理解することができない場合に通
知を行う。データ要請がデータエンティティの検索要請である場合、データ・マ
ネージメントは、要請されたデータを要請者（例えばＮＯＳを介して）に返信す
る。単一の保管所内の、あるいは複数の保管所にまたがるデータの操作およびそ
の問合せにおいて必要とされるあらゆるサポートは、ＤＭにより提供されること
について、十分理解されるべきである。データ・マネージメントは、さらに、複
数の保管所にわたる問合せの結果の収集ならびにその相関関係について、サポー
トを行う。ＤＭがデータ検索要請において要請されているエンティティの名前を
突き止めることができない場合、ＤＭは、ＮＯＳコンポーネントに通知を行う。
ＮＯＳコンポーネントは、また、データＴ￥エンティティの検索中にデータベー
スに不具合が発生した場合も。通知されることになる。データ・マネージメント
は、さらに、要請者（サービス制御オブジェクトを実行している）に対し、有効
な名前から特定のデータエンティティを検索できない旨についても通知を行う。
データ要請がデータエンティティの更新である場合、データ・マネージメントは
、そのデータエンティティを更新し、複製が求められるか否かについて決定を行
う。ＤＭは、データ要請において指定されるデータエンティティを更新できない
場合、要請者に通知を行うとともに、データ更新要請において要請されているエ
ンティティの名前を突き止めることができなかった場合、さらに、ＮＯＳに通知
を行う。また、ＤＭは、ＮＧＩＮ動作時は、いつでも、データエンティティの更
新中にデータベースに不具合が発生した場合、その旨をＮＯＳに通知する。デー
タ要請がデータエンティティの削除である場合、ＤＭは、そのデータ項目を削除
するとともに、そのトランザクションを他の保管所において開始させる必要があ
るか否かについて決定を行う。

【０１０４】 データ・トランザクション トランザクションとは、データをある矛盾のない状態から別の矛盾のない状態
に転移させるためのデータ一式の操作シーケンスとして定義される。トランザク
ションの例として、データ入力、現存するデータの格子、データ削除、データ複
写が挙げられる。ＤＭは、ＩＤＮＡ・ＮＧＩＮシステムとの関係において、保管
所におけるトランザクションを始動させたり、実行されているトランザクション
を打ち切ったり、トランザクションにおいて不具合が発生した場合に通知を行っ
たり、また全てのトランザクション上の不具合について記録することができる。
データ・マネージメントは、さらに、トランザクションに失敗した場合、そのト
ランザクションにより制御されるデータをその前の状態に戻すことにより回復手
段を実行するとともに、失敗したトランザクションを再度実施する。実行される
回復手段は、トランザクション開始時に、またはトランザクションが失敗した時
に定義される。

【０１０５】 データ・マネージメントは、また、事前に決定された、トランザクション開始
時に指定されるタイムアウトパラメータに従い、トランザクションを時間切れに
より未実行とする。さらに、データ・トランザクションの機能性には、一度に複
数のトランザクションに参加できる能力や、保留中のトランザクションを待ち行
列に入れることにより同時衝突を防止する方法をサポートするトランザクション
同時解決メカニズムの提供、何れかのトランザクションデータがトランザクショ
ンのスレッド外において変更された場合（すなわち破損された場合）におけるそ
の旨を示す信号の発信、トランザクション参加中にそのデータ状態をロール・バ
ックする能力、ならびに、トランザクション参加中に実施された全ての操作をロ
ール・バックする能力が含まれる。

【０１０６】 データ・オーディット ＩＤＮＡ・ＮＧＩＮシステムのデータ・オーディットに関する機能性において
は、保管所データの監査・回復環境の提供が含まれる。データ・マネージメント
との関係において、＞ａｕｄｉｔ＝は、２つ以上の保管所データのコピー間にお
ける同期化を試験し、結果を報告する工程である。＞ｒｅｃｏｖｅｒｙ＝は、コ
ピーを同期化するために監査結果として実施される動作の一式である。ここで述
べられる永続および・または複製データの全てが、監査の対象となる。さらに、
監査および回復目的において一次コピーモデルが確立され、＞ｃｏｒｒｅｃｔ＝
であるとして見なされる。このため、データ・マネージメントは、保管所の一次
コピーを指定することができる。さらに、ＤＭは、ＮＧＩＮとの関係において、
複数の保管所にまたがるデータの監査を行えるほか、全ての監査上の矛盾を記録
し、その監査上の矛盾を通知するとともに、識別された矛盾に関連する定義済み
の一式の規則に基づき、自動的にシステムを回復させることができる。好ましい
実施形態では、データ・マネージメントは、データ監査について、スケジュール
を組むことができる。

【０１０７】 データ・ユティリティ機能 データ・ユティリティとは、ＩＤＮＡ・ＮＧＩＮシステムとの関係において、
保管所の運転停止と始動、記憶データのバックアップ、破局的イベントに続くデ
ータの回復、保管所間のデータの同期化、ならびにデータ保管所の監視および保
守において求められる機能性を参照している。データ・マネージメントは、さら
に、保守あるいは回復目的において、保管書の運転を停止させることができる（
オフラインにする）。また、保管所の運転を停止させるか否かについて決定を行
ううえで、データ保管所の利用率を監視するメカニズムが取り付けられている。
これにより、ディスク空間お最適化やログの清掃を行うユティリティを含め、権
限が与えられているユーザによるデータ保管所の保守など、様々なユティリティ
が提供される。データ・マネージメントは、さらに、ローカルオペレーティング
システムのファイルコマンドを使って、保管所のバックアップならびに復元を行
うことができる。この際、保管所は、情報を損失することなく回復される。

【０１０８】 データ・マネージメントには、保管所データを外部媒体に保管するための、複
数の保管所にまたがる保管所データを同期化させるための、データのサブセット
を同期化させるための（部分同期化）、さらに保管所をオンラインに切り換える
ための追加ユティリティが装備されている。

【０１０９】 料金請求記録発生要求 ＮＧＩＮシステムの料金請求記録発生に関する機能性においては、ネットワー
クイベントの収集、ネットワークイベントの適切な記録（コール歴）への形式化
、形式化された記録の適切な位置への転送、ならびに潜在的に不正なコールの識
別が含まれる。料金請求記録発生機能が、カスタマがサービスに対し料金請求を
行う際に使用されることになる情報の形式化および転送について取り仕切ってい
るため、その精度は保証される。

【０１１０】 ネットワークイベントの収集 料金請求目的において使用される生のネットワークイベントは、Ｄａｔａ Ｍ
ａｎａｇｅｍｅｎｔ＝ｓの保管所から集められ、その完全性を検証するために再
検討される。様々な形式の下流料金請求システムにより利用されるコール歴の記
録を作成するうえで、各コール歴記録に対し固有のネットワーク識別子が振り当
てられているため、将来的な処理においてこれらの記録をその後においても操作
することができる。好ましい実施形態では、コール歴記録は、共有ラインで発生
したネットワークイベント情報を取り込むコール詳細記録（ＣＤＲ）や、個人的
なライン（例えばＶＮＥＴ）で発生したネットワークイベント情報を取り込むプ
ライベートネットワーク記録（ＰＮＲ）、共有ラインを使ってオペレータ業務が
実施される際に発生する情報を取り込むために使用されるオペレータ業務記録（
ＯＳＲ）、ならびに個人ラインを使ってオペレータ行業務が実施される際に発生
する情報を取り込むために使用されるプライベートオペレータ業務記録（ＯＳＲ
）など、これらの形式における記録を作成するために使用される情報を取り込む
ために使用される。上記で述べられる形式の各料金請求記録は、好ましくは拡大
され得るため、拡大されたコール詳細記録（ＥＣＤＲ）、拡大されたプライベー
トネットワーク記録（ＥＯＮＲ）、拡大されたオペレータ業務記録（ＥＯＳＲ）
および拡大されたプライベートオペレータ業務記録（ＥＰＯＳＲ）が作成される
。また、切換えイベント（例えばシステムの復旧や時間変更など）を識別する切
換えイベント記録（ＳＥＲ）や、料金請求データ記録（ＢＤＲ）を含み、ＤＭを
介し他の記録を追加することもできる。この機能には、さらに、長期間記憶検索
媒体（例えばテープなど）にコール歴記録を記憶させる機能も含まれる。

【０１１１】 コール歴記録転送要求 各コール歴記録は、作成後に、適切な下流システムに転送される。例えば、好
ましい実施形態では、ＣＤＲ、ＰＮＲ、ＯＳＲ、ＰＯＳＲおよびその各々に対応
する拡大バージョンであるＥＣＤＲ、ＥＰＮＲ、ＥＯＳＲ、ＥＰＯＳＲ、ならび
にＳＥＲおよびＢＤＲの全てが、システム・ストレージおよびベリフィケーショ
ン・エレメント「セーブ」（図示外）に送られ、最終的には、ネットワーク・イ
ンフォメーション・コンセントレータに配信される（ＮＩＣ）。ＤＭのシステム
機能により、セーブが成功裏にこれらの各コール歴記録を受信したかについて検
証が行われる。

【０１１２】 潜在的不正コールの識別 ＮＧＩＮシステムには、潜在不正コールを識別するためのメカニズムが内蔵さ
れている。このため、ＤＭコンポーネント４００は、ネットワークの不正使用を
監視するとともに、疑わしい不正を適切なフロード・ディテクション・システム
に通知する能力を有している。例えば、料金請求記録発生機能として、１）フロ
ード・ディテクション・システム（図示外）からプロファイルを取得し、フロー
ド・ディテクションに通知されるべきネットワークイベントの識別を行う機能と
、２）不正なプロファイルに対しネットワークイベントを評価する機能と、３）
潜在的な不正コールをリアルタイムでフロード・ディテクション・システムに転
送する機能が挙げられる。

【０１１３】 ここで図６を参照する。図６では、本発明によるインテリジェント配信回路網
アーキテクチャ２００を採用する電気通信システムの理論機能図が示されている
。ＩＣＰ１７２は、図示において、ＩＣＰ−ＮＭＳエージェント２４０とＳＬＥ
Ｅ２４２とが含まれており、これは、次に、基本階級管理オブジェクト２４４か
ら引き出される様々な管理オブジェクト２４６、２４８、２５０、２５２のホス
トとなる。

【０１１４】 一般に、管理オブジェクトは、ソフトウェアの各機能をまとめる方法であり、
各管理オブジェクトにより、その管理オブジェクトの機能を実行するための機能
インターフェースおよび管理インターフェースの両インターフェースが提供され
るが、管理インターフェースについては、管理オブジェクト機能にアクセスし得
るヒトおよびモノへのアクセスを制御する働きを有している。本発明では、イン
フラストラクチャソフトウェア以外の、ＩＤＮＡ・ＮＧＩＮノード２０４により
動作される電話用ソフトウェアの全てが、管理オブジェクトとして展開されると
ともに、ライブラリのサポートを行う。これにより、均一のインターフェースが
提供されることになるため、ＩＤＮＡノードソフトウェアの制御ならびに管理が
均一に行われる。

【０１１５】 ノードにより取り扱われる運搬路への接続、ルーティングおよび成端を行うネ
ットワークエレメントの集まりを、集合的に、リソース・コンプレックス（「Ｒ
Ｃ」）１８０またはＮＧＳと呼ぶことにする。ＳＬＥＥ上のサービス処理用アプ
リケーションでは、ＲＣ１８０への制御インターフェースとして、リソース・プ
ロキシー（「ＲＣＰ」）２４４を使用するが、ＲＣＰ２４４は、ＳＬＥＥ内のオ
ブジェクトから送られる機器独立コマンドを、ＲＣ１８０により実施される機器
特定コマンドに適応させるドライバ装置にリンクすることができる。ＲＣＰ２４
４は、ＲＣＰ２４４内に存在する資源の売手間において共通の基本的なコマンド
を実施するインターフェースとして描写することができる。ＲＣＰ２４４は、図
示されるように、ＩＤＮＡノード２０４上の一つまたは複数の管理オブジェクト
として実施可能である。または、この機能は、ＲＣ１８０の一部として取り付け
ることもできる。ＮＭＳ２１２、保管所２３０およびＭＯＣＥ２２８は、図３〜
５（ａ）で描写されるエレメントと同じである。

【０１１６】 図７では、ＩＣＰ１７２内部の機能インターフェースの各層について示されて
いる。ＭＯＣＥ２２８は、管理オブジェクトソフトウェアとその従属物を作成す
るシステムである。ＮＭＳ２１２は、ＩＣＰ１７２内に取り付けられているエー
ジェントの機能にインターフェースすることによりＩＣＰ１７２の実行状態を制
御するとともに、ＩＣＰ１７２上のローカル・オペレーティング・システム（「
ＬＯＳ」）２６０の動作の制御を行う。またＮＭＳ２１２は、工程の開始および
停止や、工程表の内容や工程状態に関する問合せ、オペレーティングシステムパ
ラメータの形成、ならびにＩＣＰ１７２のホストである汎用コンピュータシステ
ムの性能の管理を含み、ＩＣＰ１７２の動作についても制御を行う。

【０１１７】 ＮＭＳ２１２は、さらに、ワイド・エリア・ネットワーク・オペレーティング
・システム（「ＷＡＮＯＳ」）の動作について制御を行うが、ここでは、ＷＡＮ
ＯＳサポート工程の始動および動作状況、ならびにＷＡＮＯＳライブラリの構成
を、ＬＯＳ２６０のその制御部を介し、またＮＭＳ ＳＬＥＥ制御部により提供
されるあらゆるその他のインターフェースを介し制御するとともに、ＩＣＰ１７
２上の一つまたは複数のＳＬＥＥの２４２のインスタンス生成および動作につい
て制御を行う。ＬＯＳ２６０は、汎用コンピュータを操作するための市販規格品
オペレーティングシステムであり、ＷＡＮＯＳ２６２は、演算ノード間のシーム
レスな通信を促進するための市販規格品ミドルウェアソフトウェアパッケージ（
例えばオブジェクト要請ブローカー）である。ＳＬＥＥ２４２は、サービス処理
アーキテクチャを実行するソフトウェアインスタンスである管理オブジェクト２
４４の実行においてホストとなるが、ＳＬＥＥ２４２は、ＩＣＰ−ＮＭＳエージ
ェント２４０により、管理オブジェクト２４４の実行状況を制御するための手段
を履行するため、ＳＬＥＥ２４２インスタンスは、管理オブジェクトソフトウェ
アを展開させたり取り外したりすることができる、管理オブジェクトインスタン
スのインスタンス生成や破壊を行える、管理オブジェクトの相互作用ならびに協
力関係をサポートできる、ネイティブ・ライブラリ２６４へのアクセスを管理で
きる、さらに求められる制御を実施するなかでＮＭＳ−ＩＣＰエージェント２４
０を用いてインターフェースを実施できるソフトウェア工程となっている。

【０１１８】 ネイティブ・ライブラリ２６４は、ＬＯＳ２６０またはＷＡＮＯＳ２６２と、
固有汎用コンピュータの実行内容のみに依存してコード化されるライブラリ（例
えばコンパイルＣライブラリ）である。これらは、主に、ＳＬＥＥ２４２により
提供される本来の機能性を補足するために使用される。

【０１１９】 ＳＬＥＥライブラリ２６６は、ＳＬＥＥ２４２において実行されるべくコード
化されたライブラリである。これにより、ＳＬＥＥ２４２およびネイティブ・ラ
イブラリ２６４により提供される機能にアクセスすることができる。また管理オ
ブジェクト２４４は、ＳＬＥＥ２４２によりローディングされ、実施されるソフ
トウェアであり、ＳＬＥＥ２４２とＳＬＥＥライブラリ２６６（および恐らくは
ネイティブ・ライブラリ２６４）により提供される機能性にアクセスることがで
きる。

【０１２０】 ＩＣＰ−ＮＭＳエージェント２４０は、ＮＭＳ２１２に対し、ＩＣＰ１７２の
動作を制御する能力を提供するコンポーネントであり、ＩＣＰ−ＮＭＳエージェ
ント２４０は、ＬＯＳ２６０の動作および構成、ＷＡＮＯＳ２６２の動作および
構成、ならびにＳＬＥＥ２４２のインスタンス生成および動作を制御する能力を
履行させるものである。提示されているサービス処理アーキテクチャは、抽象概
念を増大させる層において動作するが、ＳＬＥＥ２４２から見たところ、ここに
は、ＮＭＳ２１２の制御下において相互に作用するオブジェクト層（ソフトウェ
アインスタンス）である管理オブジェクト層２４４と、管理オブジェクト２４２
またはＳＬＥＥ２４２自身の動作に対し補足的な機能を提供するソフトウェア層
（ＳＬＥＥ２４２またはＬＯＳ２６０のいずれかに対し固有の）であるライブラ
リ層２６４または２６６の２層のみが存在する。しかしながら、同一点において
、ＮＭＳ２１２は、管理オブジェクトインスタンスの正確な位置の制御を放棄す
ることも予期される。例えば、管理オブジェクトインスタンスは、要求に対する
応答など、一つまたは複数のアルゴリズムもしくはイベントに基づき、あるノー
ドから別のノードに移行し得る。

【０１２１】 ＬＯＳおよびＷＡＮＯＳの機能性は、集合的に、図７（ｂ）で示されるような
、プラットフォームや位置とは無関係のＩＤＮＡ・ＮＧＩＮシステム間の連結性
を提供するために機能する、ネットワーク・オペレーティング・システムとして
表すことができる。すなわち、ＮＯＳは、工程インターフェースを提供するとと
もに、他のＩＤＮＡ・ＮＧＩＮ機能コンポーネントとサブコンポーネント間の通
信を確立するためのネットワーク幅のサービス一式から構成され、各サービス間
において、オブジェクトの連結性、論理的な名前の翻訳、工程間通信、ならびに
ローカルにおけるシステム幅の資源管理（「ＲＭ」）がＮＯＳにより提供される
。例えば、図３で示されるように、ＮＯＳコンポーネント７００により、ローカ
ル（ＮＯＤＥ ＲＭ）におけるシステム幅の資源管理（ＳＹＳ ＲＭ）が提供さ
れる。特に、ＮＯＳコンポーネントは、サービスやデータを必要とする工程にお
けるあらゆるサービスの位置を包含しているため、各工程では、単一の論理名に
対してのみコールを行えばよいことになる。ＮＯＳコンポーネントは、次に、ど
のサービスインスタンスを使用するかについて決定を行い、そのインスタンスに
対し連結させる。ＮＯＳ７００では、部分的に、ＩＤＮＡ・ＮＧＩＮの幅広い配
信性ならびにＩＤＮＡ・ＮＧＩＮをプラットフォームから独立させることの両者
を実現させることができる。例えば、上述の論理プログラムでは、ＮＯＳコンポ
ーネント７００を、他の論理プログラムを呼び出すために使用しているため、同
一のサービスノードあるいは遠隔サービスノードのいずれかにおける異なるＳＬ
ＥＥ上の別の論理プログラムをコールし、呼び出すことができる。特に、ＳＡ５
００を介することにより、あるサービスのみを実施するためのサービスノードを
特定することができる。必要とされるサービス、例えば会議ブリッジの連結を実
施し得ない付随サービスノード２０４を有するスイッチ部にコールがかけられた
場合、ＩＤＮＡは、このようなサービスを提供すべく構築されている別のノード
に対しコールを行うための経路付けを実施する必要がある。好ましくは、ＩＤＮ
Ａは、ＮＯＳコンポーネント７００を介し、別の遠隔サービスノードにおいて必
要とされるサービスをコールし、コール処理を実行してから、もともとのノード
におけるスイッチに対し必要とされたサービスについて応答することになる。

【０１２２】 図８では、ＳＬＥＥ２４２が仮想計算機２７０内において実行される、ＩＣＰ
１７２内のネスティング処理文脈が示されている。仮想計算機２７０は、ＩＣＰ
１７２のＬＯＳ２６０内の工程として開始される。したがって、ＳＬＥＥ管理コ
ードは、ＶＭ工程２７０によりメインプログラム２７２としてローディングされ
、実行される。メインプログラム２７２として実行されるＳＬＥＥ管理コードは
、ＩＣＰ−ＮＭＳエージェント２４０機能にインターフェースされ、階級表２７
６に基づく管理オブジェクトインスタンス２７２の作成および破壊について監督
を行う。例えば、複数の以来を有し得る階級表２７６に存在する管理オブジェク
トＸが説明され、各管理オブジェクトＸは、その後ＮＭＳによる制御下、あるい
は加入者により要請される処理サービス実施途中のいずれかにおいて、必要とさ
れるＸ１、Ｘ２、Ｘ３としてインスタンス生成される。仮想計算機２７０を使用
することにより、サービスが生み出されるとともに、図１０（ａ）に関し本書で
更なる詳細が述べられる方法において、サービス論理が実行されることになる。

【０１２３】 ＩＮおよびＡＩＮアーキテクチャは、状態表としてコード化されるサービスに
向けられ構築されたアーキテクチャであり、このような状態表の内容は、コード
化サービス機能を実行するハードコードされた状態機エンジンにより解釈される
。結果的に、ＭＯＣＥ２２８とサービス・ロジック・インタープリータ（「ＳＬ
Ｉ」）の相互依存性が非常に高くなるため、固定された機能パレットのみが提供
されることになる。求められる新しいサービスにより、新たにビルディングブロ
ック機能の追加が求められる場合、ＭＯＣＥ２２８およびＳＬＩの両方が変更さ
れ、コンパイルしなおされ、徹底的に試験が行われ、調和された様式において展
開されなければならない。ＩＮまたはＡＩＮアーキテクチャでは、新しいＳＬＩ
コードの展開において、ネットワーク内で短い休止時間が必要となるが、これと
は対照的に、本発明では、新旧両ＳＬＩを同時に存在させることができる複数の
平行アーキテクチャが提供される。

【０１２４】 本発明では、これらの欠点を克服するために、仮想計算機２７０を使用してい
る。仮想計算機２７０は、コンピュータに相当する機能を有する、このような基
本的な機能レベル（すなわち論理オペレータや変数、条件付飛越しなど）におい
てプログラムが可能な、ホストにより管理されるプログラムにより、有限状態モ
デルとして簡単には表現されない機能を含め、あらゆる考えられる論理機能が本
質的に表現されるマシーンである。仮想計算機２７０の普遍性は、特に、好まし
さにおいて状態表を超え得る形式のコール処理論理が表現されるため、このアプ
リケーションにおいて有益である。これは、一般的に高いレベルの機能をサポー
トするとともに、プログラムの意味論ならびに表現の柔軟性において制限される
論理インタープリンタとは異なるものであり、ＩＮおよびＡＩＮアーキテクチャ
では、ＳＬＩは限られた構造ならびに限られ機能一式をサポートする。

【０１２５】 仮想計算機２７０のソフトウェアが汎用コンピュータにより操作される場合、
仮想計算機２７０は、アダプタ層として捉えることができる。仮想計算機２７０
内のプログラムとして動作を行うコードには、プロセッサ上で直接動作している
かのように、入出力および記憶に対する制御ならびにアクセスについて同程度の
粒度を持たせることができるうえ、さらに、全く同じプログラムを、同等の仮想
計算機環境で動作する全く別のプロセッサのハードウェアに移植することができ
る（すなわち異種環境において動作可能）。

【０１２６】 好ましい実施形態では、全ての電話用アプリケーションソフトウェアを表現す
るために、Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ社が開発した「Ｊａｖａ」プラッ
トフォームを使用する。これは、Ｊａｖａの普及により、プラットフォームの移
植性、開発ツール類やスキルセット類の偏在性、ならびにｆｔｐやｈｔｔｐなど
の現在使用されているプロトコルをサポートしている点などの、実際的な利点が
見込まれるためであり、Ｊａｖａは、Ｃ＋＋と類似する様式のオブジェクト統合
型プログラムに適応している。そこで、ＳＬＥＥのマネージメント・コード２７
２およびＳＬＥＥ２４２において示される全ての管理オブジェクト２７６がＪａ
ｖａバイトコードとしてコード化されており、ＳＬＥＥマネージメント・コード
２７２には、階級をインストール、排除またはインスタンス生成するための、ま
た事例の問合せや削除を行うための、また大域的価値および運転・停止状態を評
価するための機能が含まれる。

【０１２７】 上述の長所にもかかわらず、ＳＬＥＥ２４２として仮想計算機を、特にＪａｖ
ａ仮想計算機を使用する場合、ＩＮおよびＡＩＮアーキテクチャにより見過ごさ
れることになる。恐らく、対話式の音声応答などのより一般的な電話アプリケー
ションにより偏見が植え付けられているＩＮおよびＡＩＮ設計者は、固定された
機能パレットで十分であり、その明らかの平易性ならびに伝統的なコール処理モ
デルとの類似性がためにそのほうが好ましいと考えている。ところがＡＩＮアプ
ローチでは、固定のコールモデルと機能セット内におけるサービス発生速度のみ
が改善されるのに対し、本発明では、新しいサービス要求および新しいコール処
理パラダイムを満足すべく、内在するサービスフレームワーク全体を、容易に発
展させることができる。

【０１２８】 オブジェクト統合型ＳＬＥＥ２４２を選択することにより、依存性の管理や、
同時にインスタンス生成が実行されるオブジェクト間において共用される保護策
を含め、多くの重要な長所がもたらされる。モジュール性や多形性ならびに再使
用性などの好ましいオブジェクト統合型プログラミングにおける長所は、本発明
に準ずるＳＬＥＥ２４２において実現される。また、管理オブジェクトの受け継
がれる階層により、コールモデルやプロトコル、あるいはいくつかのその他のコ
ール処理における局面の変更において、例えば、相対的にローカル化されたコー
ドを信号の基本階級に変更することで、広く影響を受けることになる。さらに、
別の重要な長所として、各ＳＬＥＥ２４２内においてオブジェクトがインスタン
ス生成されるコード化階級を、ＳＬＥＥ２４２を無効あるいはリブートすること
なく更新することができる点が挙げられる。

【０１２９】 好ましい実施形態では、一組の動作規則をコード化し、物理的位置あるいは動
作条件に基づき、新しい階級の実現コードを、そこから送られてくるオブジェク
トのインスタンス生成を行うＳＬＥＥ２４２へ展開させる際に、それを許可また
は制限することができる。これらの規則は、ＮＭＳ２１２が展開のために使用す
るか、あるいはＳＬＥＥ２４２により作用する実際のオブジェクトコードに挿入
する管理オブジェクト画像の一部など、異なる位置においてコード化することが
できる。何れの場合も、ＮＭＳ２１２は、インスタンス生成に失敗した際のエラ
ー処理手順が設定されることになると考えられる。位置の制限は、ノードの物理
的位置（例えば、国家、州、市、通りの名または世界的な座標など）を特徴付け
るためのあらゆる手段となり得るであろう。

【０１３０】 さらに、コード化される一組の動作規則間の矛盾を解決する方法を取り入れる
こともできる。例えば、領域Ａおよび領域Ｂの両領域にまたがるノードＸにおい
てある特定のオブジェクトをインスタンス生成し、その一組の動作規則により、
その特定のオブジェクトのインスタンス生成を領域Ａでは禁止するが、領域Ｂで
は許可する場合、そのオブジェクトをノードＸでインスタンス生成しても良いか
について、矛盾が起こる。但し、矛盾解決規則により、簡単に、許可されている
場所でのみオブジェクトのインスタンス生成が可能となり、その矛盾は解決され
るとともに、特定のオブジェクトはノードＸではインスタンス生成されない。こ
の一組の動作規則を使用することで、幹線管理階級コードを、インテリジェント
コールプロセッサが実際に幹線資源を管理している状況に対し展開またはインス
タンス生成する際に、それを規制することが可能である。これらの規則は、また
、ある特定状態の料金請求規則に合わせて作られている料金請求プロセッサイン
スタンスをその状態の境界に制限するために使用することもできる。前に述べた
ように、これらの位置制限規則は、階級オブジェクトに対する内部あるいは外部
規則とすることが可能である。

【０１３１】 ここで図９を参照する。本発明の好ましい実施形態に準ずる管理オブジェクト
の階級階層について、説明する。抽象基本階級管理オブジェクト２４４には、全
ての引き出された階級がＳＬＥＥ２４２内のオブジェクトとして適切にサポート
されるように、共通の機能性ならびに仮想機能が含まれている。ここでは、特に
、サービス制御階級２５２、コール制御階級２５０、運搬制御階級２４８および
資源代理階級２４５の４つの個々の副階級が示されている。

【０１３２】 サービス管理階級２５２は、全ての機能オブジェクトにおける基本階級である
。セッションマネージャー階級２８０には、セッションに関係する情報および活
動が含まれている。一つのセッションについては、単数あるいは複数のコールま
たはその他のネットワーク機能の呼出しから成る構成とし得る。セッションマネ
ージャー階級２８０により、各セッションに対し固有の識別子が与えられる。コ
ール処理がノード様式で行われる場合、料金請求情報が集められなければならな
いが、この収集活動において、経費の掛かる相関処理を必要とする代わりに、各
コールに振り当てられる固有の識別子により、それが容易になる。サービス処理
では、プロトコルは、連続する抽象層により包まれるが、最終的には、プロトコ
ルは十分に抽象化され、セッションマネージャーの割当て・インスタンス生成を
保証することになる（例えばＳＳ７では、ＩＡＭメッセージを受信することによ
り、セッション管理行われたことについて保証されることになる。）。

【０１３３】 運搬能力階級２８２により、運搬におけるサービスの品質が変更される。サー
ビス制御階級２５２は、５６Ｋｂｉｔ／ｓからより高いレートに変更し、その後
元に戻すなど、コールのサービスの質（「ＱｏＳ」）に変更を加えることができ
るほか、運搬能力でさえ変更することができる。ＱｏＳは、接続マネージャー階
級３０１により管理される。例えば、ハーフレート副階級２８４は、コールのＱ
ｏＳを、通常の８Ｋｈｚサンプルレートではなく、４Ｋｈｚのサンプルレートに
落とすことになる。またステレオ副階級２８６では、左側および右側をサポート
するために、ユーザがコール内に２つの接続部を形成することもできるであろう
。

【０１３４】 サービス仲裁階級２８８は、サービスの矛盾とサービスの相互作用を調停する
際に、それをコード化する階級である。これは、サービス制御階級２５２が、特
に開始および終了において矛盾が生じ得るため、必要とされる。多くの実際的な
理由から、その他の形式の個々のサービス制御階級２５２を用いて、どのように
矛盾を解決するかについて認知させる際に、それを各サービス制御階級２５２内
でコード化することは望ましくない。その代わりとして、矛盾が識別されると、
矛盾を起こしているサービスとその保留中の要請を参照し、参照内容をサービス
仲裁階級２８８に送られ、サービス仲裁階級２８８は、恐らくローカルの文脈や
構成データならびに矛盾が発生しているサービスオブジェクトへのその後の問合
せなどを考慮に入れながら、妥当な措置について決定を行う。サービス仲裁階級
２８８を持つことにより、ハードコードや暗黙機構ではできない、明確なドキュ
メンテーションならびに矛盾解決アルゴリズムのコード化が可能となる。さらに
、サービスの更新または追加が行われる場合、現在使用しているサービスを更新
する必要がないため、単一のサービス内における様々な関係の変更が求められる
ことになり得るような、何らかの矛盾の変更は発生しない。

【０１３５】 特徴階級２９０により、電話に付随する標準的な能力一式（例えば３方向コー
ルやキャッチホンなど）が実行される。このような能力の一つとして、それを、
意図する相手につなげるために、現在つながっている電話を切る動作を開始させ
るためのオーバーライド２９２とし得る。また別の共通能力にコールブロック２
９４を含めることで、開始に関する基準一式に基づき、開始を行うためのオファ
ーが拒否される。

【０１３６】 コール処理中に他のサービスを選択的に呼び出すために、サービス識別階級２
９６を使用する。このサービス識別階級２９６は、また、サービスそのものとし
て副階級化される。サービス識別階級２９６により、柔軟な文脈依存サービスが
行われるとともに、各サービスオブジェクト内に、サービスを作動させる時期を
決定するための固定コードを設定する必要がなくなる。作動シーケンスは、サー
ビス自体からは分離されているため、例えば、加入者Ａと加入者Ｂが同一の一組
の特徴へのアクセス権を有しているとする。加入者Ａが、ある特定の一組の信号
を使って、単一あるいは複数の彼が使用できるサービスを選択的に呼び出す方法
を選んだのに対し、加入者Ｂは、彼が使用できるサービスを別の一組の信号を使
って作動させる方法を望んだとする。この場合加入者間における唯一の相違は、
彼らのサービスを作動させる方法である。このため、サービス自体から選択工程
を分離することが望まれる。ここで、２つの利用可能な解決方法が存在する。加
入者Ａと加入者Ｂに対するサービス選択工程を、別々のサービス識別階級２９６
においてコード化する方法と、ある一つのサービス識別階級２９６が加入者ごと
のプロファイルを使用することにより適切な情報を指示する方法とである。これ
は、使用するサービスの組合せがばらばらのより多くのユーザに適用するために
、般化が可能である。さらに、サービス識別階級２９６を使用することにより、
所定のコールの文脈または進度に基づき、サービスにアクセスする際のマッピン
グを変更することもできる。この階級を実行することで、様々な電話利用者が、
恐らく異なる作動入力法により、異なるサービスを作動させることができる。先
行技術において、スイッチの売手全員が、この能力が阻害された、柔軟性に欠け
るサービス選択機構をこれまで利用者に送り届けてきた。

【０１３７】 媒体独立サービス階級２９８は、蓄積交換３００や放送、リダイレクション、
強制排除、ＱｏＳおよび多数共同接続など、音声、ファックス、電子メールなど
を含むその他の媒体形式に適用される形式のサービス制御階級２５２である。サ
ービス制御階級２５２が展開され、それが各媒体形式に適用され得る場合に、サ
ービス制御階級２５２が、指し様可能なサービス制御階級２５２に細分される。
サービス制御階級２５２が媒体依存機能ならびに媒体独立機能（すなわち、サー
ビスならびに設定された媒体依存ラッパＳＣの媒体形式ごとの一つ一つを実行す
る媒体独立ＳＣ）に細分される場合、媒体独立階級２９８から引き出されたとお
りに、蓄積交換３００により、何らかの媒体形式にあるメッセージまたはデータ
ストリームを蓄積する包括的な能力と、その後あるイベントに基づきそのメッセ
ージまたはデータストリームを後で送達する能力とが提供される。またリダイレ
クションにより、接続部を指定された条件に基づきある論理アドレスから別のア
ドレスに移動させる能力が提供される。この概念は、転送電話（全ての形式）、
ＡＣＤ・ＵＣＤ、ＷＡＴＳ（１〜８００個のサービス）、ファインドミー・フォ
ローミー（ｆｉｎｄ−ｍｅ、ｆｏｌｌｏｗ−ｍｅ）およびモバイル移動などにお
ける基本である。強制排除については、協議されているケースあるいはその他の
ケースのいずれかにおいて、キャッチホンや優先割り込みなどのサービスが含ま
れる。またＱｏＳ変調接続により、音声・ファックスはもとより、ビデオの再生
およびファイルの転送など、パケット網を超えた将来的なサービスが実行される
。そのほか、多数共同接続には、３方向およびＮ方向ビデオカンファレンスなど
が含まれており、現在のところ主にユーザによる制御および入力は電話のキーを
使って実行されているが、将来的にはこれらの制御および入力は音声認識により
行われることが予想される。

【０１３８】 接続マネージャー階級３０２は、コールにかかわる様々な運搬制御２４８の接
続の調和ならびに仲裁に責任を有している。このため、複数のコールにおける関
係者間の連結性を管理する際、複雑さが伴われ、他の全てのサービスから取り除
かれている。サービスとコール処理は、接続部から切り離されており、これによ
り、コールのマッピングパラダイムが、一つから多数といった具合に、各接続部
に分けられる。ここで、コールからコールへのマッピングが多数から多数になる
。

【０１３９】 アーキテクチャ内の接続マネージャー３０２は、独立して動作を行うか、また
は対等者として共同で作業を行うかの、何れかの設計となっている。動作におい
て、サービス制御階級２５２は、接続マネージャー階級３０２に、コールセグメ
ントの追加、部分変更、排除について要請を行う。これらの変更を達成させる責
任は、接続マネージャー階級３０２にある。注記：接続部は、それ自体における
またはそれ自体の資源として、あるいは資源の属性として見なすことができるた
め、接続マネージャー階級３０２は、基本的な資源管理機能の代理人あるいはそ
の局面として実行可能である。

【０１４０】 コール制御階級２５０は、電話法において一般的に使用される基本的な有限状
態機械などの基本的なコール処理を行うとともに、コール処理をどのように発生
させるかについて特定する。２つの階級は、開始（コールの発生）３０４と終了
（コールの受付）３０６の機能的分離に沿って引き出され得る。

【０１４１】 運搬制御階級２４８は、資源代理２４５を介し、リソース・コンプレックス１
８０へ送られる、あるいはリソース・コンプレックス１８０から送られてくる特
定信号およびイベントを、コール制御オブジェクト２５０により理解され得る共
通信号および共通イベントに適応させることを目標とする。この階級から引き出
されるオブジェクトのある一つの期待される役割は、加入社のライン番号、サー
ビス階級、アクセス形式など、コールの開始成立に関する情報の収集である。副
階級は、信号の送信に付随する回路またはチャンネル数に基づき、区別される。
これらには、ＩＳＤＮプライマリー・インターフェース３１０内の運搬チャンネ
ル２３本ごとの信号送信チャンネルに適応されるチャンネル付随階級３０８や、
信号回路を制御するためにダイヤルを回す方法を使用するアナログ電話３１４に
おいて特徴的に備わっているチャンネル信号階級３１２、ならびに全面的に運搬
チャンネルから分離されているＳＳ７信号送信３１８により代表されるチャンネ
ル共通階層３１６を含み得る。

【０１４２】 資源代理階級２４６は、実行環境を運搬網における実世界スイッチおよびその
他のエレメントに連結させるべく、そのインターフェース動作を一身に行う。こ
のレベルにおいて実行され、全ての末裔階級により受け継がれる内部状態例は、
サービスに含まれるか、またはサービス外であるか、あるいは待機中または使用
中である。引出しが企図される階級は、リソース・コンプレックス１８０の特定
の資源形式に対応する、電話３２０（標準的な２５００セットにおける標準的な
代理）、音声応答ユニット（「ＶＲＳ」）３２２（音声応答ユニットにおける標
準的代理）、ＩＭＴ幹線接続３２４（デジタル幹線（Ｔ１・Ｅ１）回路における
標準的代理）、ならびにモデム接続３２６（デジタルモデムにおける標準的代理
）である。

【０１４３】 ここで、サービス・コントロール・コンポーネントが送られてくるサービス要
請に従いその役割を果たし得る好ましい方法について、例えば汎用コンピュータ
４００などのサービス制御サーバのオペレーティングシステム４３５内において
実行されるＳＬＥＥアプリケーション４５０、４５０’を有するサービス制御環
境４３０の別の実施形態を特に図解している図１０（ａ）をさらに参照しながら
説明する。

【０１４４】 図１０（ａ）で示されるように、ＳＬＥＥ４５０は、コール処理サービス、お
よび１）最初に切換えプラットフォームからのサービス要請を受信し、例えばコ
ールを求めてダイヤルされた番号など、幾つかの使用可能な回路に基づきコール
においてどのサービスを実施するかについて決定を行い、次に、そのコールを処
理するための別の適切なサービス・ロジック・プログラムを要求するサービス制
御階級・サービスディスクリミネータ階級２９６（図７）の副機能コンポーネン
トであるフィーチャー・ディスクリミネータ論理プログラム（「ＦＤ」）５１０
や、２）受信したサービス要請またはイベントのサービス処理を行うサービス制
御階級２５２（図７）の副機能コンポーネントであるサービス・ロジック・プロ
グラム（「ＳＬＰ」）オブジェクト５２０や、３）ネットワークアクセスライン
の現状を保持するサービス制御階級２５０（図７）の副機能コンポーネントであ
るライン・ロジック・プログラム（「ＬＬＰ」）オブジェクト５３０や、４）そ
の他の全ての論理プログラムがイベントの書込みを行うサービス制御・セッショ
ンマネージャー階級２６０（図７）の副機能コンポーネントであるイベント・ロ
ジック・プログラム（「ＥＬＰ」）オブジェクトや、５）コールの処理に関与す
るその他の全ての論理プログラムに対し接続点を提供することによりコール全体
の状態を保持するサービス制御・接続マネージャー階級３０２（図７）の副機能
コンポーネントであるコール・ロジック・プログラム（「ＣＬＰ」）オブジェク
トなどのその他のサポートサービス実施中に実行される少なくとも５つの形式の
論理プログラム（オブジェクト）において実行されるべく設計されているＪａｖ
ａ「仮想計算機」から成る。これらの論理プログラムは、各々、好ましくは、以
下で述べられるように、Ｊａｖａプログラミング言語を使って書き込まれている
ソフトウェア「オブジェクト」として具現化される。ＩＤＮＡ・ＮＧＩＮサービ
ス制御アーキテクチャは、これらのオブジェクトがＭＯＣＥ・ＳＣＥにおいて一
回限り書き込まれ、ネットワーク内のいずれかに存在するあらゆる形式のコンピ
ュータやあらゆる形式のオペレーティングシステム上のＳＬＥＥに展開されるよ
うに、設計される。

【０１４５】 偉大なる特殊性を有するＦＤ５１０は、１）最初に、例えば、そのサービスは
ＩＤＮＡ・ＮＧＩＮにより処理されるサービスであるとしてスイッチが識別を行
う際のスイッチなど、複合資源から送られてくるサービス要請を受信し、２）そ
のサービス要請に付随する情報を分析し、３）そのサービスを処理できるＳＬＰ
はどのＳＬＰであるかについて決定を行う統計副コンポーネントである。好まし
くは、ＦＤは、コールされた番号やコールしている番号、開始スイッチＩＤ、開
始幹線グループ、開始ライン情報およびネットワークコールＩＤを含むが、それ
に限られることのない、複合資源から提供されるデータを受信するためのシステ
ムタスクまたはインスタンス生成されたオブジェクトとし得る。ＦＤ５１０は、
ＮＯＳを介して、適切なＳＬＰ、ＣＬＰおよび開始ＬＬＰに対し、コールを処理
すべく、それを始動させる。好ましくは、ＦＤ５１０は、特定のコールやイベン
トに拘束されることない永続オブジェクトであり、常にサービス・コントロール
ＳＬＥＥ４５０内において積極的に動作を行う。 実施された分析の複雑性、な
らびにＦＤに対する要請量により、ローディングを共有し、リアルタイム効果を
発生させるためには、サービス・コントロールＳＬＥＥ４５０内で積極的に動作
を行っているＦＤのインスタンス数は、単数または複数となり得る。例えば、一
つのＦＤを使用して、受信したＳＳ７メッセージデータを分析し、もう一つのＦ
Ｄを使って、ＡＴＭメッセージデータを分析し得る。

【０１４６】 ライン・ロジック・プログラム（ＬＬＰ）５３０は、１）ネットワークへのア
クセスポイントの現状、また接続およびラインの現状を保持し、２）物理的なポ
イント、接続部またはラインに付随する特徴についてデータ・マネージメントに
問合せを行うとともに、３）通話割込み、キャッチホン、転送電話、ならびにコ
ール状況により要求される過剰時の経路付けなどの特徴に適用される副機能コン
ポーネントである。ここには、コールを開始させるラインに付随するＬＬＰ（以
降「ＬＬＰＯ」とする）と、コールを終了させる接続点あるいはラインに付随す
るＬＬＰ（以降「ＬＬＰＴ」とする）があり、ライン・ロジック・プログラムイ
ンスタンスがインスタンス生成されると、それ自身に対しスイッチファブリック
を登録する。以下で説明するように、ライン・ロジック・プログラム５３０は、
全てのイベントデータを、サービス処理に関し同じインスタンスを受けているＥ
ＬＰ副コンポーネントに送る。

【０１４７】 またダイナミック・サブコンポーネントは、サービス処理の異なるステップに
従って動的に構築されている、サービス処理以来が完了した時点で破壊される、
イベント・ロジック・プログラム（ＥＬＰ）、コール・ロジック・プログラム（
ＣＬＰ）およびサービス・ロジック・プログラム（ＳＬＰ）を含むコンポーネン
トである。

【０１４８】 イベント・ロジック・プログラム（ＥＬＰ）は、サービス処理中に作成される
利あるタイムのイベントデータを保管するために使用される副機能コンポーネン
トであり、サービス実行中に発生した全てのイベントデータを記録している。イ
ベント・ロジック・プログラムは、好ましくは、イベントを最初に受信したとき
にスイッチ部においてコール制御工程によりインスタンス生成される。スイッチ
がサービス要請をＮＧＩＮに送信すると、ＮＧＩＮは、イベントデータがそのコ
ールに結びついているこの論理プログラムに送られるように、ＥＬＰのアドレス
に沿って送信する。イベント・ロジック・プログラムは、サービス処理の同一イ
ンスタンス内にある全ての副コンポーネント、すなわちそのコールにかかわるＣ
ＬＰ、ＬＬＰおよびＳＬＰにアクセス可能である。各サービス処理コンポーネン
トは、そのコールを、サービスの実施において処理するため、そのサービス処理
コンポーネントは、前もって確立されている規則に従い、ＮＯＳを介して、ＥＬ
Ｐに対しイベントデータの書込みを行う。コールが完了すると、ＥＬＰ内のイベ
ントデータは、次に料金請求記録内にコンパイルされ、その後、料金請求を行う
ための、またトラフィックや使用法について報告するための下流システムに、さ
らにその他の内部機能にかかわる下流システムに送られる。特に、ＥＬＰは、１
）特定のコールにより発生したネットワークイベントを収集し、２）そのイベン
トを、コール詳細記録（「ＣＤＲ」）や料金請求データ記録（「ＢＤＲ」）など
の適切なコール歴記録にフォーマットし、３）例えばカスタマの料金請求などの
下流システムに将来的に転送するために、例えばデータ管理において、情報を検
証し、確認し、記憶するという機能を実行する。また、どのイベントをＥＬＰに
書き込むかを決定するための規則は、サービス・クリエーション部において確立
される点について、十分理解されるべきである。イベントデータは、不正管理お
よびネットワーク管理システムにより、追加的にアクセス可能である。

【０１４９】 コール・ロジック・プログラム（ＣＬＰ）５４５は、サービス処理にかかわる
各ＳＬＰの状態を保持するための副機能コンポーネントであり、全てのサービス
（ＬＰの）間において工程のインターフェースを提供する。ある実施形態では、
ＣＬＰは、コールに対するイベントサービス要請を最初に受信した時点でＦＤに
よりインスタンス生成されるか、または、スイッチ部に位置するコール制御コン
ポーネントによりインスタンス生成されることも可能である。あるいは、ＣＬＰ
５４５は、ＳＬＰにプログラムされているトリガー点に従い、サービス処理中に
何れかの点においてＳＬＰ５１０によりインスタンス生成され得るものであるが
、この方法の場合、ＣＬＰのインスタンス生成は、サービスに対し固有となり得
る。コール・ロジック・プログラムは、インスタンス生成時に、サービス処理の
同じインスタンス内における全ての副コンポーネント、すなわちＬＬＰおよびＥ
ＬＰのアドレスを受信する。ＣＬＰは、次に、ＳＬＰ，ＬＬＰＯ，ＬＬＰＴおよ
びＥＬＰをそのコールに対し結びつけるが、その後、サービス処理の同じインス
タンス内におけるこれらの全副コンポーネントによりアクセス可能となる。すな
わち、コール・ロジック・プログラムは、サービス処理の同じインスタンス内に
かかわるＳＬＰとＬＬＰとを通信させるための接続点である。コールが完了する
と、ＣＬＰは、サービス処理の同じインスタンス内における全ての副コンポーネ
ントに対し、コールが完了したことを通知し、それにより、その論理プログラム
の分解工程が開始されることになる。

【０１５０】 サービス・ロジック・プログラム（ＳＬＰ）５２０は、サービスを実行するた
めに求められる論理を提供する動的副コンポーネントである。ＳＬＰは、コール
ではなく、むしろサービスに結びついており、コールにおけるサービスやそれに
含まれる特徴を実施する。ＳＬＰがサービスに適用し得る特徴には、例えば、コ
ールの経路付けアルゴリズムやＩＶＲサービスなどが含まれる。また、ＳＬＰは
、頻繁使用されるサービスの永続オブジェクトとし得るし、あるいは、例えば頻
繁には使用されないサービスを対象とする、ＦＤにより要求され、その後コール
完了時に切断された時点でインスタンス生成されるプログラムとし得る。あるＳ
ＬＰを常に動作させておくは、時々動作させるか、あるいは要求があったときに
のみ動作させるかについては、図１１で示されるように、そのサービスにかかわ
るサービス・アドミニストレーションにより作成される構成ファイル５８０によ
り決定される。好ましくは、ＳＬＰには、サービス処理の同じインスタンス内に
おけるＣＬＰおよびＥＬＰ副コンポーネントへのアクセス権が与えられる。

【０１５１】 全てのＳＬＰがある特定のコールサービスに関連しているのではなく、幾つか
のＳＬＰを使って、他のＳＬＰにより必要とされ、求められるタスクを実行する
ことができる。このため、例えば、８００サービスにかかわるＳＬＰの場合、コ
ールの経路付けの翻訳を行うというそのタスクを完了するために、ライン・イン
フォメーション・データベースに問合せを行うＳＬＰを呼び出す必要性があると
考えられる。ＳＬＰは、また、コールにおけるコール処理制御信号を別のＳＬＰ
に送ることもできる。好ましくは、単一のサービス処理のインスタンスに対し、
ＳＬＰは、一度に、一つのみが動作を行っているものとする。ＳＬＰにより実行
されたサービスタスクの一部として作成されるあらゆるイベントデータは、サー
ビス処理の同じインスタンス内におけるＥＬＰコンポーネントに送られる。

【０１５２】 ＳＬＰには、オペレーティングシステムが動作を行うための全ての情報が含ま
れていないため、ＳＬＰは、直接、オペレーティングシステム内において実行さ
れることはない。さらに、ＳＬＰがフォーマットや内容を変更することなく別の
オペレーティングシステム内で動作させる必要がある場合、ＳＬＰとオペレーテ
ィングシステム間に存在するＮＯＳミドルウェアにより、複数のオペレーティン
グシステムを横断するＳＬＰの一貫性が保持される。

【０１５３】 図１０（ａ）でさらに示されるように、サポート機能および動作機能にかかわ
るＳＬＥＥ４５０内において実行されるその他の工程として、ＳＬＥＥ内を通る
サービスのローディングや作動、停止および排除に責任を有するうえ、さらにそ
のＳＬＥＥ内を通るその他の全てのサービスを監視し、ＮＯＳに、状態ならびに
利用データを報告する責任があるサービス・マネージャー（「ＳＭ」）オブジェ
クト５５４や、ＮＯＳサービスのインターフェースにおいて使用されるとともに
、ＮＯＳサービスを求めるためのそのＳＬＥＥ内を通る全てのサービスにより使
用されるＮＯＳ階級ライブラリ、すなわちＮＯＳへの通り口であるＮＯＳ従属工
程５５８、全てのＳＬＥＥ資源を拘束することなく同時にＮＧＩＮサービスを実
行させるために必要な機能性を提供するスレッドマネージャー（「ＴＭ」）５７
７、さらに、Ｚ８５（ｆ）を参照しながら本書において説明されるローカル貯蔵
所６１５とＤＭ４００の貯蔵所マネージャーコンポーネントをインターフェース
させるために使用されるデータ・マネージメントＡＰＩ（［ＤＭ ＡＰＩ］）と
が含まれる。

【０１５４】 また、図１０（ａ）で示されるＳＬＥＥにローディングされるその他のサービ
スインスタンスには、サービスエージェント（「Ｓａｇ」）インスタンス５５９
とそれに付随するスレッドマネージャーインスタンス５５７が含まれるが、これ
らは、本書において更なる詳細が述べられるように、サービスノードにおいてサ
ービス作動させるために利用される。

【０１５５】 図１１（ａ）では、ＳＬＥＥ工程に入るための主要点を提供する（ＳＬＥＥ．
Ｊａｖａ）工程の各ステップが図解されている。図１１（ａ）で示されるように
、ステップ６０１では、ＤＭシステムコンポーネントの使用可能性や、ＮＯＳ従
属工程５５８やＮＯＳ基本工程５６０（図１１）を含む、ＮＯＳサービスのイン
ターフェースにおいて使用され、ＮＯＳサービスを求めるためのＳＬＥＥ内を通
る全てのサービスにより使用されるＮＯＳ階級ライブラリを提供するＮＯＳサイ
トロケータシステムの、論理名やオブジェクト参照登録を受信するための使用可
能性、ならびに、例えばＷｉｎｄｏｗｓ ＮＴ、ＵＮＩＸ、ＰＣなどのサービス
制御サーバオペレーティングシステムにより、例えば主流（）および支流（）な
どのブートストラップを認識することでＳＬＥＥ工程をスタートさせる可能性が
当然のことながら見込まれる。また、ＮＯＳ基本コンポーネント５６０（図８）
は、コンピュータｓオペレーティングシステムや、ＮＯＳ従属工程５５８および
その他のシステムコンポーネント類５７１を、直接インターフェースする点につ
いて、十分理解されるべきである。好ましくは、ＮＯＳ基本工程５６０を、各Ｓ
ＬＥＥ上のＮＯＳ従属オブジェクト５５８をインターフェースするとともに、Ｎ
ＯＳサービスを提供するための全てのＮＯＳ階級ライブラリが含まれるネットワ
ークあるいはローカルノード上に配置する。次に、ステップ６０４において、サ
ービス制御構成ファイル、ならびに構成オブジェクトを構築するためのファイル
の構文解析内に、ステップ６０６で示されるようなキー値の組合せを含むハッシ
ュテーブルを含み得る。ＳＬＥＥは、２種類のパラメータ、すなわち名前と構成
ファイルを受け付ける。名前パラメータは、ＳＬＥＥのこのインスタンスを識別
するためのＮＯＳロケータサービスにより使用される、すなわちそのＳＬＥＥ自
身にＮＧＩＮロケータサービスを登録するためにＳＬＥＥにより使用される（ス
テップ６１２）固有のＮＧＩＮ名前ストリングであり、構成ファイルは、そのサ
イトロケータを見つけるためのろけたサービスにより使用される。例えば、この
テーブルは、ＳＬＥＥ構成プロパティを見つけるために使用され得る。ＮＯＳが
ＣＯＲＢＡを実行させるため、基本的なＣＯＲＢＡ機能性は、ステップ６０８に
おいて、次に始動される。その後ステップ６１０で、ＳＬＥＥクラスローダ階級
がインスタンス生成され、ステップ６１２で示されるように、ＮＯＳロケータ代
理サービスがＳＬＥＥ内においてインスタンス生成される。次に、ステップ６１
５で示されるように、サービス・マネージャー（ＳＭ）階級がクラスローダ階級
を介しローディングされ、インスタンス生成され、ローカルＮＯＳにより拘束さ
れる。すなわち、ＳＭオブジェクトに、ローカル代理ＮＯＳロケータサービスオ
ブジェクトが登録される。したがって、ローカルロケータサービスがサービス・
マネージャー登録を他のＮＧＩＮドメイン内のロケータサービスに伝搬する点に
ついて、十分理解されるべきである。図１１（ｂ）を参照しながら説明されるよ
うに、サービス・マネージャーオブジェクトにロケータサービスが登録された後
で、ＳＬＥＥに対し、あるいはＳＬＥＥからサービスをローディング、作動、停
止、排除させる処理サービス管理要請が可能となる。最後に、ステップ６１８で
示されるように、ＳＬＥＥを動作させつづけるとともに、本書においてその詳細
が説明されるように、サービス・マネージャー（ＳＭ）またはサービス・エージ
ェント（ＳＡｇ）を通りＮＯＳイベントが入ってきた場合に、ＳＬＥＥにその処
理をさせるＳＬＥＥスレッドである工程イベントループが実行される。

【０１５６】 図１１（ｂ）では、上記において、ステップ６１５の図１１（ａ）を参照しな
がら考察されるようにインスタンス生成されるサービスマネージャーオブジェク
トインスタンス５５４（図８）により実行される（ＳｅｒｖｉｃｅＭａｎａｇｅ
ｒＩｍｐｌ．ｊａｖａ）工程の各ステップが図解されている。好ましくは、ＳＭ
オブジェクトがＮＯＳに代わってサービス管理動作を行うために、ＯＲＢインタ
ーフェースを実行させる。当工程は、例えば（ローディング）、（動作）、（開
始）および（停止）方法により、ＳＬＥＥ内でサービスをローディングさせ、作
動させ、停止させ、動作させ、終了させるためにＳＭインスタンスにより実行さ
れるステップについて例証するものである。ＮＯＳによりＳＭオブジェクトイン
スタンスに送られるパラメータには、求められるサービスの論理参照や、ＮＯＳ
がそのサービスに対し、ＮＧＩＮローカル・ロケータ・マネージャー（ＬＲＭ）
サイトロケータを登録すべきであるか、またはそのサービスはそれ自身にＮＯＳ
を登録する責任を有しているかを示しているブールフラグが含まれる。ステップ
６２０で示されるように、サービスのローディング要請が最初に受信され、ステ
ップ６２２において名前付けサービス代理に手渡される。次に、ステップ６２４
において、例えば１〜８００収集（１８Ｃ）などの要請されているサービスが、
既にローディングされているかについて、すなわち、要請されているサービスを
具現化するオブジェクトがインスタンス生成されているかについての決定が行わ
れるが、要請されているサービスにかかわるオブジェクトが、既にインスタンス
生成されている場合、ＮＯＳは、ステップ６２６において、物理的なオブジェク
トインスタンスを突き止めるためにそのサービスのオブジェクト参照を返信する
ことになるとともに、この工程は、ステップ６３２に戻ることになる。要請され
ているサービスにかかわるサービスオブジェクト、例えば１８Ｃが、まだインス
タンス生成されていない場合は、クラスローダ階級がステップ６２５においてイ
ンスタンス生成され、これにより、要請されているサービスが依存する、他のＳ
ＬＰおよびＳＩＢＢを含む全ての階級をローディングするために、帰納的ローデ
ィングが実行される。帰納的ローディングは、例えば、ローカル貯蔵所からロー
カル構成ファイルを参照することにより可能であり、その際、特に、クラスロー
ダをこれらの従属階級全てにおいてＪＶＭに対し機能的にローディングするかを
示すフラグが送られる。最初のインスタンスにおけるサービスにかかわる階級が
ローディングされるときに、包括的なサービス・エージェント階級がそれまでに
ローディングされていない場合その階級がローディングされる点について、十分
理解されるべきである。次に、ステップ６２５において、全ての階級内における
ローディングが終了した後で、そのサービス自身に、ローカルＮＯＳ名前付けサ
ービス（代理）を登録させる必要があるかについて決定するため、ブール登録フ
ラグがチェックされる。例えばトルーに対しブール登録フラグが設定されている
場合、そのサービスは、ステップ６３０で示されるように、ＮＯＳ名前付けサー
ビスを登録させる責任を有している。また、この工程は、ＳＡｇ階級の裏付が行
われるステップ６３２まで継続され、その後、サービスエージェントオブジェク
トインスタンス５５８（図１１）と特定サービス間の連関が、すなわちＳＬＰオ
ブジェクト内でサービスエージェントインスタンスを送るなどの方法により、実
現される。次にステップ６３５において、新しいＳＬＥＥスレッドが説明される
ような方法で作成され、ＳＬＥＥスレッドにより、サービス・エージェントが作
動される。すなわち、ＳＬＥＥスレッドとサービス・エージェントが連関される
。最後に、ＳＭ工程を終了し、ＳＬＥＥ．ｊａｖａ工程に戻る。ＳＭ内で提供さ
れる方法により、そのＳＬＥＥ内を通るその他の全てのサービスを監視し、ＮＯ
Ｓに、状態ならびに利用データを報告する責任が追加される。

【０１５７】 ＳＭ工程に関し、さらに、（ＳＬＥＥＣｌａｓｓＬｏａｄｅｒ．ｊａｖａ）の
呼出について、ここで、図１１（ｃ）を見ながら詳細を説明する。特に、ＳＬＥ
Ｅクラスローダ階級は、ＪＶＭのクラスローダ階級の特殊階級であり、ＪＶＭの
クラスローダ階級を拡張するものである。このローダ階級は、ネットワークを越
えて階級をローディングさせることにより、システム階級ローダの動作を拡張す
るため、図１１（ｃ）の最初のステップ６８６で示されているように、クラスロ
ーダは、まず、ＳＬＥＥのインスタンスに付随するそのローカル貯蔵所をチェッ
クし、階級が既にローディングされ、定義付けられているかについて判断を行う
。階級が既にローディングされている場合、その工程は元に戻る。階級がローデ
ィングされていない場合、ステップ６８８において、その階級を使ってローディ
ングを行えるかについてローカルデータ記憶（ＤＭ）のチェックを行うために、
ＮＯＳを介し、メッセージが送信される。例えば、ＳＬＥＥクラスローダは、Ｊ
ＤＢＣデータベース連結により関連するデータベースから階級の検索を行うこと
ができるが、その際、ＪＤＢＣ ＡＰＩをサポートするあらゆる関連データベー
スから階級を検索し得ることは十分理解される。サービス階級がローカルデータ
記憶部において見つからない場合、ＳＬＥＥクラスローダは、ステップ６８９に
おいて、ローカルファイルシステムのチェックを行う。データ記憶部またはロー
カルファイルシステムのいずれかにおいて探している階級が見つかった場合、ス
テップ６９０で示されるように、その階級が取り出される。次に、ステップ６９
４において、定義階級方法が呼び出され、その階級をＪＶＭ実行環境で使用でき
るように変換が行われる。特に、（定義階級）法は、そのサービスを実行するた
めに特定される各階級を通り帰納的に実行され得るため、それにより、バイト列
を階級クラスのインスタンスに変換させる。この新たに定義付けられた階級のイ
ンスタンスは、次に、階級クラス内の新規インスタンス法により作成されるが、
この機能性により、ＳＬＥＥが新しいサービスのローディングやインスタンス生
成ができるようになるうえ、包括的に保持することができるようにもなる。好ま
しくは、ステップ６９５で示されるように、次にその階級がローディングされた
ときに、その場所が貯蔵所のヒットとなるように、ローカル貯蔵所を占める方法
が呼び出される。

【０１５８】 好ましい実施形態では、これらのインスタンス生成された各オブジェクトは、
下記のストリングにより一般的に例証される名前付け規則に準じて、それ自身に
、ＮＯＳロケータサービス、すなわちＬＲＭ５７７が登録される。 ．．． ｓｉｔｅ ｌｅｖｅｌ． ＳＬＥＥ Ｎｕｍｂｅｒ． ＳＬＰ ｎａ
ｍｅ ．．． 上記において、ｓｉｔｅ ｌｅｖｅｌはＮＧＩＮサービス制御サーバ４４０の物
理的な位置に関する情報であり、ＳＬＥＥ Ｎｕｍｂｅｒは、例えばＳＬＥＥ＃
１など、そのオブジェクトがインスタンス生成されている特定のＳＬＥＥを示し
ており、ＳＬＰ ｎａｍｅは、例えばフィーチャー・ディスクリミネータ＃１な
ど、サービスの論理名である。このストリングには、嫌悪数を含めることもでき
る。登録名は、新しいＮＧＩＮドメイン内の他のロケータの場所に伝搬されるが
、それは、この登録工程と、ＮＯＳコンポーネントがどの工程を展開しているか
、それらがどこで展開されているか、また現在どこでサービスを取得することが
できるかを知ることにより（説明される）ＮＯＳ資源の管理における機能性とに
より遂行される。

【０１５９】 階級ローダにより作成される方法ならびにオブジェクトの構築者は、他の階級
についても参照することができる。どの階級を参照するかを決定する際、Ｊａｖ
ａ仮想計算機は、保持目にその階級を作り出した階級ローダのロードクラス方法
を呼び出す。Ｊａｖａ仮想計算機が、その階級が存在するかについて決定を行っ
た後で、それが存在するが際に上の階級について知る必要がある場合に、「解明
」フラグがフォールスに送られる。但し、階級のあるインスタンスが作成される
か、その何れかの方法が呼び出される場合、階級もまた、解明されなければなら
ない。この場合、解明フラグはトルーに送られ、解明クラス方法が呼び出される
。この機能性により、サービスにより参照されるｃｌａｓｓｅｓ／ＳＩＢＢｓ／
ＪａｂａＢｅａｎｓも、また、ＳＬＥＥクラスローダにより解明されることが保
証される。

【０１６０】 図１１（ｄ）では、インスタンス生成におけるサービスエージェント階級工程
の流れが図解されている。ステップ６３９において示されるように、最初のステ
ップには、サービスエージェントに付随する、図１０（ａ）においてＴＭオブジ
ェクトインスタンスとして描かれているスレッドマネージャー（「ＴＭ」）オブ
ジェクトのインスタンス生成が含まれる。説明されるように、このスレッド管理
オブジェクトは、サービス要請により新しいＳＬＥＥスレッドを作成すべく機能
するスレッド工場のような、あるいはスレッド倉庫のような動作を行うためにイ
ンスタンス生成され得る、スレッド作成待ち時間が長い機械での使用において望
ましい、（スレッドマネージャー）階級に基づくものである。次に、ステップ６
４０において、サービスに付随するＳＡが、その（動作）階級法を介して工程イ
ベントループに入り、そこで、サービスに付随するコールイベントの受信待ちと
なる。

【０１６１】 ここで図１１（ｅ）を参照する。サービスエージェント階級の詳細が図解され
ているが、この階級では、その（開始）、（継続）および（終了）階級を介して
ＮＧＩＮサービス内に通り口を提供するものである。ＳＬＥＥ内の各サービスに
は、サービスインスタンス（コールインスタンス）の管理ならびにイベントのサ
ービスインスタンスへの指名に責任がある階級に基づく付随サービスエージェン
トオブジェクトが含まれている。図１１（ｅ）で示されるように、ＳＡｇオブジ
ェクトとがサービス・マネージャー（ローディング）法によりインスタンス生成
され動作を行った後で、サービスの受領を求めるコールが新たに作成されるたび
に、ＳＡｇの（開始）法が呼び出されるが、特に図１１（ｅ）で示されるように
、ステップ６４１において、ｔｉｄ、ｏｒｉｄコール識別子パラメータと、例え
ば、本書においてネクスト・毛年レーション・スイッチ（「ＮＧＳ」）として参
照されるＩＤＮＡ・ＮＧＩＮスイッチから送られてくるイニシャル・アドレス・
メッセージ（「ＩＡＭ」）により提供されるような、そのコールにおけるサービ
ス処理に関連するイベント情報を含むメッセージストリームが、まず初めに、Ｓ
Ａｇ開始法に送られる。次に、ステップ６４３において、例えば、そのサービス
インスタンスに関連する重要な情報を抜き取るための（解読）法を呼び出すこと
により、メッセージストリームの解読が行われる。さらに、抜き取られたメッセ
ージ情報を受信するために、コール文脈データの管理において使用されるコール
文脈オブジェクトが作成される。開始法では、ステップ６４５で示されるように
、また本書において図１１（ｇ）を参照しながら説明が行われているように、ス
レッドマネージャーインスタンスの割当て法を呼び出すことにより、そのコール
に対し新しいスレッドが割り当てられるか、あるいはそのサービスに対して幾つ
かのスレッドが事前にインスタンス生成されている場合は、スレッドのプールか
ら一本が引き出されることになる。または、ＳＡｇ（継続）法が呼び出される場
合、そのコールに対し割り当てられているスレッドに対応するオブジェクトの参
照が返信される。

【０１６２】 偉大なる特殊性を有するスレッドマネージャーオブジェクトは、好ましくは、
セッションＩＤに基づきスレッドを管理するスレッドマネージャー階級に基づく
オブジェクトである。（割当て）と（解放）の２つの方法が、それぞれ、スレッ
ドを割り当てるために、またスレッドを解放するために提供される。この割当て
および解放の両方において、スレッドの識別において使用可能なキーとしての固
有の識別子が求められる。この固有の識別子には、コールを受信したＮＧＳスイ
ッチにより設定されるトランザクションＩＤ（「Ｔｉｄ」）と、コールの発起者
を識別するオブジェクト参照ＩＤ（「Ｏｒｉｄ」）とが含まれており、これによ
りコールインスタンスの識別において使用される。図１１（ｆ）では、スレッド
マネージャー階級の（割当て）法の動作詳細が図解されている。図１１８ｆ）で
示されるように、ステップ６６０において、固有にコールトランザクション識別
するためのＴｉｄならびにＯｒｉｄ識別子がこの工程を通ることにより、その識
別子に基づき固有のキーが作成される。次に、ステップ６６２において、例えば
、キー値の組合せが入力されているハッシュテーブルをチェックすることにより
、キーの識別子が、既に存在しているスレッドを識別できるかについて問合せが
行われる。キーが認識された場合、すなわち既にサービススレッドがそのコール
に対し割り当てられている場合、ステップ６６４において、スレッドマネージャ
ーは、ハッシュテーブルを調べてから、スリースレッドインスタンス（スレッド
オブジェクト）を返信する。または、ステップ６６３において、インスタンス生
成されているサービススレッドの数を追跡するカウンタが増進され、その後ステ
ップ６６５においてシステムのローディングを監視することにより、そのサービ
スに振り当てられているスレッドインスタンス数の最大値を上回っているかにつ
いての決定が行われる。例えば、カウンタの値とサービス構成ファイルに記載さ
れている最大サービスインスタンス値とを比較したうえで、そのサービスにおけ
るスレッドインスタンス数が振り当てられている最大値を上回っている場合、ス
テップ６６７において、ＮＯＳに対し、例えば、ＮＯＳが、同じサイトで、また
は、例えば別のサービスノード位置などにおいてインスタンス生成されているサ
イトで実行される別のＳＬＥＥ内で使用可能な、そのサービスにおける別のイン
スタンスを探すことができるように、メッセージが発行され、その後工程は元に
戻る。さらに、スリースレッドインスタンス生成工程では、図１１（ｇ）を参照
しながら本書において詳細が説明されるように、その優先イベント待ち列のイン
スタンス生成が行われる。またそのサービスに振り当てられているスレッドイン
スタンス数の最大値を上回っていない場合、ステップ６６８において、そのサー
ビスに振り当てられているスレッドインスタンス数のしきい値を上回っているか
について決定が行われる。そのサービスに振り当てられているスレッドインスタ
ンス数のしきい値を上回っている場合、ステップ６６９において、図１１（ｆ）
に関し本書で詳細が述べられているように、ＮＯＳローカル資源管理機能に対し
、そのサービスがしきい値に達成していることについて、警告が発せられる。最
後に、ステップ６７０において、ステップ６６８でどのような出力が行われたか
に関係なく、要請されているサービスに対し新しいスリースレッドインスタンス
が割り当てられ、その要請されているサービスに対し優先イベント待ち列が始動
され、そのサービスにかかわるＳＡｇインスタンスに返信されることになる制御
信号によりそのスレッドが開始される。

【０１６３】 ここで図１１（ｅ）で示されるサービス・エージェント（開始）法の機能性に
戻るが、スレッドマネージャーがサービスインスタンスに対しスレッドを割り当
てた後で、ステップ６４６において、スレッドに関連するオブジェクト変数が初
期化され、要請されているサービスの新しいオブジェクトインスタンスが、（ク
ローン）法を呼び出すことによりインスタンス生成される。次に、ステップ６４
８において、新たにクローンされたＳＬＰインスタンスが、新たに割り当てられ
たスレッドに設定され、その後、ステップ６５０において、例えば入力メッセー
ジストリームから抜き出された全ＩＡＭ情報など、そのコールインスタンスに付
随させる必要性が認められるイベント情報が存在するかについて決定が行われる
。新しいクローン化ＳＬＰインスタンスに付随されるイベント情報が存在する場
合、その情報は、ステップ６５２で示されるように、そのスレッド上に押しやら
れることになる。またスレッドに押しやられるべきイベント情報が存在するか否
かに関係なく、そのＳＬＰに新たに割り当てられたスレッドは開始され、ＳＡ（
継続）法により処理されるサービス関連イベント情報の同時ではない到着待ちと
なる。ここで述べられているように、そのコールに割り当てられたスリースレッ
ドにより、処理中に受け取った全てのサービス関連イベント情報を保持するため
に、優先イベント待ち列がそのまま継続的に保留される。サービス処理にかかわ
る全てのイベントにはそれに付随する優先権が与えられるため、スレッドは、そ
の優先順位、すなわちｓｅｒｖｉｃｅ＝ｓイベント待ち列におけるその配置場所
に従いイベント情報の処理において管理が行われることになる。最後に、ステッ
プ６５４において、そのコールインスタンスに対し、スレッドイベントループが
開始される。

【０１６４】 ＳＡ(継続)方式は、図１１（ｅ）に示される(ビギン)方式と実質的に同一であ
ることを理解しなければならない。この場合、相違点として、ＳＡ(継続)方式は
、図１１（ｅ）に関して上述されるように、その呼インスタンスに対してすでに
インスタンス生成されているサービス処理スレッドにより実時間サービス関連事
象をチャネリングする。ゆえに、サービスエージェントの継続方式は、呼インス
タンスの事象および識別パラメーターを受信し、受信事象に対するＴｉｄ、Ｏｒ
ｉｄパラメーターに関連するサービススレッドを再割り当てし、事象をｔｈｒｅ
ａｄ＝ｓ事象優先キューに押し込む。ＳＡｇおよびSMクラスは、両方ともＮＯＳ
に対するＩＤLインターフェースを具備することも理解する必要がある。サービ
ス(ＳＬＰ)は、そのようなインターフェースを具備していないが、そのＳＡｇイ
ンターフェースを介してシステム全域と通信できる。

【０１６５】 実時間サービス処理中、ＳＬＥＥ４５０は、１)サービス処理中にＳＬＰおよ
びＳＩＢＢレベルで命令を翻訳し、２)入力事象をＳＬＰの指定インスタンスに
送信し、３)追跡フラッグが設定される場合に追跡データを生成し、４)ＳＬＰ、
ＳＩＢＢおよびＳＬＥＥレベルにおいてトレーシングをオンにし、トレースデー
タを指定出力に送信し、５)ＳＬＥＥ使用データを生成し、実行時使用データを
指定出力に送信し、６)遠隔通信管理ネットワーク(TMN)インターフェースに対す
る例外データ(エラー)を生成し、７)TMNインターフェースに対する性能データを
生成し、８)ＳＬＰまたはユーティリティプログラムの新規インスタンスを追加
するメッセージ/リクエストと、サービス処理を中断および劣化させることなく
そのような新規ＳＬＰおよびユーティリティプログラムインスタンスを追加する
ためのメッセージ/リクエストを受信し、９)負荷分割を目的とする多重サービス
制御インスタンスにより同一サービスをサポートする。

【０１６６】 サービスインスタンスが処理を終了すると、サービスを終了するか、あるいは
サービスとつながる別の処理を開始する。いずれにしても、ＳＡｇ(end)方式が
呼び出され、その呼に関連するスレッドインスタンスを終了するように機能する
。これは、スレッドマネージャー(リリース)方式を呼び出し、呼インスタンスを
一意的に識別するＴｉｄおよびＯｒｉｄ識別子にパスし、あらゆる事象をｔｈｒ
ｅａｄ＝ｓ事象キューに押し込み、呼をリリースすること、すなわちスレッドイ
ンスタンスを終了および/またはスレッドインスタンスをスレッドプールに戻す
ことにより達成される。

【０１６７】 好ましくは、Sleeスレッドクラスインスタンスは、すべてのＳＬＥＥ資源をタ
イアップすることなく実行し、協調的資源シェアリングを容易にするためにＩＤ
ＮＡ／ＮＧＩＮに要求される機能を供給する。特に、Sleeスレッドとサービスイ
ンスタンス間に一対一写像が存在する。この場合、ＳＬＥＥは、Sleeスレッドの
１つのインスタンスをサービスの１つのインスタンスに関連づける。すなわち、
サービスにより処理される各呼ごとに、その呼に関連するSleeスレッドの１つの
インスタンスが存在する。また、Sleeスレッドは、トランザクションid(tid)、
オブジェクトリファレンスid(orid)、オブジェクトリファレンス、例えば、ピア
とエージェント、ＳＬＰおよびＳＬＰに関連する優先事象キューを保存すること
によりサービスに対するデータウェアハウスのように機能する。より詳細には、
Sleeスレッドは、２つのキーインターフェース、すなわち、Sleeスレッド上に事
象を押し込むためにサービスエージェントを使用可能とするプッシュ消費者と関
連スレッドから事象を引き出すためにサービスを使用可能とするPull供給者を実
行することによりサービス(ＳＬＰ)とサービスエージェント間の事象チャネルの
ように機能する。このあと説明されるように、各Sleeスレッドは、インスタンス
、あるいは説明されるようにNGINイベントsをキューに入れるためのプライオリ
ティイベント待ち行列を有する。

【０１６８】 好ましくは、(プライオリティイベント待ち行列)クラスは、サービス(ＳＬＰ)
に関連する事象(NGINイベントの導出クラス)をキューに入れるプラットフォーム
独立クラスである。図１１（f）、ステップ６６７、６７０に関して示されるよ
うに、各Sleeスレッドオブジェクトは、事象のハッシュテーブルを含むこともあ
るプライオリティイベント待ち行列をインスタンス生成する。事象は、降順でキ
ューに入れられることもある。例えば、事象優先度は、NGINイベントベースクラ
スに定義され、例えば、１０が最高優先順序である場合、１０から１の範囲にわ
たる。ゆえに、各スレッドは、処理に利用不能な事象の数を追跡できるため、フ
ルサービス処理並列を使用可能にする。

【０１６９】 図１１（ｇ）は、ステップ６７５において示されるようにスレッドにより受信
される事象の優先度とプライオリティイベント待ち行列に対する事象のポスティ
ングを確認するための論理を密閉(保護)する(postイベント)方式を説明する。図
１１（ｇ）に示されるように、これは、本質的に押し込まれた事象の優先度と、
ステップ６７８において処理される優先キュー上の次の事象の優先度を比較し、
押し込まれた事象の優先度がステップ６８０において処理されるキューの次の事
象(存在する場合)の優先度より大きいかどうか判断し、押し込まれた事象をキュ
ーのトップに配置することによりステップ６８２ａに示されるように処理される
次の事象として設定するか、あるいはキューをループにし、そしてステップ６８
２ｂにおいて示されるようにその優先度にしたがって事象を保存しなければなら
ないキューのロケーションを判断することにより達成される。次にステップ６８
４において、Sleeスレッドは、システムから処理時間が割り当てられた時点で最
高優先順序の次の事象を処理する。

【０１７０】 より詳細には、PullSupplierインターフェースは、事象データが利用可能にな
るか、あるいは例外が引き起こされ、事象データをコンシューマーに戻すまでブ
ロックする”pull”操作、もしくはブロックしない”tryPull”操作を呼び出す
ことによりコンシューマーに対してサプライヤーからデータを要求する操作をサ
ポートするためにSleeスレッドにより実行される。すなわち、事象データが利用
可能な場合、事象データを戻し、hasイベントパラメーターを真に設定する。事
象が利用不能な場合、hasイベントパラメーターを偽に設定し、ヌル値が戻され
る。ゆえに、Sleeスレッドは、事象サプライヤーとして機能し、サービス(ＳＬ
Ｐ)は、コンシューマーの役割を引き受ける。サービス(ＳＬＰ)は、Sleeスレッ
ドから事象データを取り出すためにSleeスレッドpullまたはtryPullを使用する
。サービスは、事象データなく継続できない場合、pull操作を使用するか、それ
以外の場合、tryPull操作を使用する。

【０１７１】 プッシュ消費者インターフェースは、Sleeスレッドにより実行され、押込み操
作をスレッド上に呼び出し、事象データをパラメーターとしてそのｔｈｒｅａｄ
＝ｓ優先事象キューに移すことにより事象データをコンシューマーに伝達するサ
プライヤーの操作をサポートする総称プッシュ消費者インターフェースを実行す
る。ゆえに、Sleeスレッドは、事象コンシューマーとして機能し、サービスエー
ジェントは、サプライヤーの役割を引き受ける。サービスエージェントは、事象
データをSleeスレッドに伝達するためにSleeスレッド押込み操作を使用する。”
消去(kill)”サービス事象は、最高優先順序を含む可能性がある。事象に対する
優先度は、省略されることもあるが、あるいは新規に生成された事象クラスが設
計される場合は、サービスクリエーションにおいて確立されてもよい。

【０１７２】 説明されるように、特定のサービスのサービスエージェントインスタンスは、
サービス処理中に受信および生成されるすべての事象をその呼に対して生成され
るサービススレッドインスタンスに向ける。例えば、あるノードにおいてスイッ
チにより生成される初期事象は、クラスがＩＤＮＡ／ＮＧＩＮサービスコントロ
ールに初期サービスリクエスト、特にサービスリクエストが起動される時間、リ
クエストが発信されるスイッチＩＤ、呼が発信されるポートＩＤ、呼が発信され
る端末装置ＩＤ、発呼者番号、被呼者番号等の関連初期呼文脈情報を伝達する責
任を負う(サービス要求イベント)を含む可能性がある。NGINイベントを拡大する
(接続イベント)サブクラスは、接続発生時間、発呼者番号が接続されるステーシ
ョン番号をレポートし、ＡＴＭ−ＶＥＮＴサービスにおいて、着信バーチャルパ
スＩＤおよび発信バーチャルパスＩＤをレポートする。NGINイベントを拡大する
(リリースイベント)サブクラスは、リリース事象をレポートする。例えば、ＡＴ
Ｍ−ＶＥＮＴサービスにおいて、発呼または被呼者が呼を終了するか、あるいは
ユーザークレジットが切れた時点でリリースを発生できる。このようなクラスは
、リリース事象が生成される時間、リリース事象の生成原因と、発呼および被呼
者の接続からリリース事象が生成されるまでの経過時間を判断するためにＳＩＢ
ＢＳを実行する。これに加えて、終了メッセージをＮＧＩＮからＮＧＳに伝達す
るためにNGINイベントを拡大する(終了イベント)サブクラスを使用することもで
きる。このメッセージを受信した時点で、(モニタリリースイベント)サブクラス
は、NGINイベントを拡大し、メッセージをＮＧＳに送信するために使用され、リ
リース指示の受信時点でリリース指示をＮＧＩＮに転送するように命令する。Ｎ
ＧＳがモニターリリースメッセージを受信した時点で、(UniNotifyイベント)サ
ブクラスは、発信者(発呼者)に通知を送信するために呼び出される可能性がある
。(モニタ接続イベント)サブクラスは、NGINイベントを拡大し、接続メッセージ
が受信される時点でＮＧＩＮからＮＧＳにメッセージを送信するために使用され
るサブクラスであり、事象をＮＧＩＮに送信するようにＮＧＳに命令する。

【０１７３】 説明されるように、実時間サービス処理において、データ管理のデータ検索お
よび更新機能性は、サービス処理中にＤＭにより保存されるデータにアクセスす
る能力を含む。

【０１７４】 実施形態において、特定のサービスノードで、ＤＭは、サービス処理中に、例
えば、ＮＯＳを介してＳＬＥＥにおける実行被管理オブジェクトインスタンスか
らデータリクエストを受信する。データ管理は、特にデータリクエストを理解で
きない場合、リクェスター(例えば、被管理オブジェクト)に通知する。データリ
クエストがデータ実体の検索に関する場合、データ管理は、リクエストされたデ
ータを(例えば、ＮＯＳを介して)リクェスターに戻す。単一リポジトリーまたは
多重リポジトリーにおいてデータを操作し、照会するために要求されるあらゆる
サポートは、ＤＭにより供給されることを理解する必要がある。データ管理は、
付加的に多重レポジトリーにわたる照会の結果の収集および照合をサポートする
。ＤＭがデータ検索リクエストにおいてリクエストされた実体の名前を突き止め
ることができない場合、ＤＭは、ＮＯＳコンポーネントに通知する。また、ＮＯ
Ｓコンポーネントは、データ実体の検索中にデータベース不具合が発生した場合
に通知される。データ管理は、付加的に(サービス制御オブジェクトを実行する)
リクエスターに有効名から指定データ実体を検索不能なことを通知する。データ
リクエストがデータ実体の更新である場合、データ管理は、データ実体を更新し
、レプリケーションが要求されるかどうか判断する。ＤＭは、データリクエスト
に規定されるデータ実体を更新できない場合、リクエスターに通知し、付加的に
データ更新リクエストにおいてリクエストされた実体の名前を突き止めることが
できない場合、ＮＯＳに通知する。ＮＧＩＮ操作中の任意の時点において、ＤＭ
は、データ実体の更新中のデータベース不具合をＮＯＳに通知する。データリク
エストがデータ実体の削除である場合、ＤＭは、データ項目を削除し、他のレポ
ジトリーでトランザクションを開始する必要があるかどうか判断する。

【０１７５】 図５（f）は、一般的に実時間呼処理用にサービスノードにおいて呼サービス
データを利用可能にするサービス制御サーバーコンポーネント４０５と、ＳＡに
より維持されるデータの指定サブセットを保存および分散するための離散的デー
タベースサーバーとして実施されるデータベースコンポーネント４０７データ管
理コンポーネント４００の機能アーキテクチャーを説明する。特にサービス制御
サーバーコンポーネント４０５は、実データ管理アプリケーションであるデータ
管理(ＤＭ)クライアント４１０、ＤＭアプリケーションに接続され、ＤＭアプリ
ケーションがＳＡからデータを入手するために使用するインターフェースである
ＤＭ ＡＰＩ４１２、ローカルキャッシュ戦略に準拠して呼処理に利用可能なDBO
RExtract(ＤＢＯＲ抽出)から一部またはすべてのデータを保存するために使用さ
れるサービス制御サーバー上の共有メモリーであるローカルキャッシュ４１５と
、ローカルキャッシュ戦略を実施することによりローカルキャッシュの状態を維
持し、ＤＢＯＲ抽出からデータを検索するためにＤＭサーバーと通信するキャッ
シュマネージャー４２０を具備する。データベースコンポーネント４０７は、そ
のノードでサービス実行中に被管理オブジェクトインスタンスにより使用される
データを有する１つ以上のデータベースを含むＤＢＯＲ抽出４２７、サービスア
ドミニストレーションにおいてＤＢＯＲマネージャー５２０と同一機能を実行す
るが、ＳＡが保持する情報の指定サブセットを処理するＤＢＯＲ抽出マネージャ
ー４２６、サービスアドミニストレーションから受信されるデータをＤＢＯＲ抽
出マネージャー４２６に入力するＳＡクライアント４２２、ＳＡクライアント６
２２とＳＡのデータ分散プロセス間のプロセスインターフェースであるＤＤＡＰ
Ｉ４２４と、一般にＤＢＯＲ抽出マネージャー４２６からデータ抽出を処理する
データ管理サーバー４２５を具備する。

【０１７６】 ここで、データ管理操作を図５（f）に関してさらに詳しく説明する。ＳＬＥ
Ｅ内において、いくつかの機能タイプは、必ずしも限定されるものではないが、
被管理オブジェクト(STBB、ＳＬＰ等)とＮＯＳを含めてデータ管理４００からデ
ータを必要とする可能性がある。これらのそれぞれは、サービス制御ＳＬＥＥに
おいて実行するＤＭクライアントとして図５（f）に示される。ＤＭクライアン
ト４１０は、ＤＭ ＡＰＩ４１２がデータ管理とインターフェース接続するため
にすべてのＤＭクライアントに対する共通メッセージセットを供給する場合、Ｄ
Ｍ ＡＰＩ４１２を使用してデータのリクエストを生成する。また、ＤＭ ＡＰＩ
４１２は、ＤＭクライアントからデータを必要とする指定ロケーションを密閉(
保護)する。これは、このデータがローカルキャッシュ４１５またはＤＢＯＲ抽
出４２７だけに保存されることによる。ＤＭクライアント４１０は、論理名によ
りデータをリクエストし、そのデータを検索可能かどうか、あるいはＤＭサーバ
ーを介してＤＢＯＲ抽出からデータをリクエストすることが必要かどうかを判断
する。好ましくは、ローカルキャッシュ４１５は、制御サーバー４０５に供給さ
れる各ＳＬＥＥで作動している各プロセスに利用可能な共有キャッシュである。
つまり、異なるアプリケーション用に供給される１つ以上のローカルキャッシュ
、例えば、１-８００プロセスキャッシュ、ルーティングマネージャーキャッシ
ュ等が存在し、各共有キャッシュは、自己の各キャッシュマネージャーを有する
。

【０１７７】 ＤＭクライアント４１０がデータのリクエストを形成する場合、まず、ＤＭ
ＡＰＩは、ローカルキャッシュ４１５をチェックし、リクエストされたデータが
そこに保存されているかどうか確認する。リクエストされたデータがローカルキ
ャッシュ４１５に保存されている場合、ＤＭ ＡＰＩは、リクエストされたデー
タを検索し、例えば、ハッシングキーおよびアルゴリズム、あるいは索引順次ア
クセス方式のような標準データ検索テクニックを使用して、そのデータをＤＭク
ライアント４１０に供給する。

【０１７８】 リクエストされたデータがローカルキャッシュ４１５に保存されていない場合
、関連キャッシュマネージャー４２０は、ＤＭサーバー４２５を介してＤＢＯＲ
抽出４２７からデータを検索する。特に、ＤＭ ＡＰＩ４１２は、特定のデータ
を必要とすることをキャッシュマネージャー４２０に通知し、キャッシュマネー
ジャーは、リクエストをＤＭサーバー４２５に送信することにより応答する。次
にＤＭサーバー４２５は、データベースアクセス用のＤＢＯＲ抽出マネージャー
４２６を使用してＤＢＯＲ抽出からリクエストされたデータを検索する。ＤＭサ
ーバー４２５は、リクエストされたデータをキャッシュマネージャー４２０に戻
し、キャッシュマネージャーは、ＤＭ ＡＰＩ４１２を介してデータをＤＭクラ
イアント４１０に供給する。また、キャッシュマネージャーは、サービス要求と
作動するコンピューターのケイパビリティ、特にメモリー容量に依存するローカ
ルキャッシング戦略に応じてリクエストされたデータをローカルキャッシュ４１
５に書き込むこともできる。これらの仕様は、サービスアドミニストレーション
により生成されるサービスおよびコンピュータープロフィールから入手される。

【０１７９】 実施形態において、ＩＤＮＡ／ＮＧＩＮのＤＭ４００用のデータキャッシュマ
ネージャーコンポーネントは、各サービスノードにおいて”クライアント側キャ
ッシング(Client Side Caching)”戦略を採用している。この戦略にしたがって
、キャッシュマネージャールーチンおよび論理は、基本的に以下のように実行さ
れる。１)ローカルキャッシュは、ルーチンの最初に静的アレイとして維持され
る。２)まず、ルーチンは、リクエストされたデータがローカルキャッシュに存
在するかどうかを確認するためにチェックする。３)そのデータがローカルキャ
ッシュに存在する場合、フォーマットされ、発呼者に戻される。４)そのデータ
がローカルキャッシュに存在しない場合、そのデータは、一般的な”照会サーバ
ー”ルーチンを使用してデータサーバーから検索される。５)データがデータサ
ーバーから戻される場合、キャッシュ内に保存され、フォーマットされ、発呼者
に戻される。より詳細には、”照会サーバー”ルーチンは、データサーバーに対
する照会をフォーマットし、リクエストを送信し、応答を受信しない場合は、別
のリクエストを送信する。これは、応答を受信するまで、あるいはルーチンがエ
ラーにより戻る試行の設定回数まで継続する。

【０１８０】 好ましい実施形態において、コード論理は、キャッシュスペースを”静的変数
”としてではなく動的に分割する”キャッシュマネージャー”と呼ばれる別のプ
ロセスに存在する。さらに、実施形態において、キャッシュマネージャーは、一
般的なルーチン、すなわち、特定の表およびデータ要素に対するリファレンスを
含まない。その上、実施形態のキャッシュマネージャーは、多数のキャッシング
戦略を処理するための論理を実行し、データサーバーから一方的なデータメッセ
ージを処理するための論理を実行する。

【０１８１】 ローカルキャッシュ戦略は、ローカルキャッシュ内のすべてのデータを保存す
ることから単なる保存にまで及ぶが、典型的に”直前に使用されたデータ”また
は“最も頻繁に使用されたデータ”を検索する戦略を含む。ローカルキャッシュ
の供給が頻繁に使用されるサービスに対する(共有メモリーを使用する)迅速なデ
ータ検索を提供することにあるため、ローカルキャッシング戦略は、サービスコ
ントロールサーバーで実行されているサービスを判断するＳＡサービス供給機能
と密接に結合される。より詳細には、データが関連するデータ特性およびサービ
スに依存するシステムにおいて３レベルのデータキャッシングが存在する。すな
わち、１)ＤＭＡＰＩ、キャッシュマネージャーとＤＭサーバーおよびＤＢＯＲ
抽出デバイスを利用することによる本明細書に記載のローカルキャッシング計画
を実行するローカルレベルデータ、２)ＤＢＯＲを更新し、その変更をＤＭサー
バーを介してノードにおけるキャッシュマネージャーのすべてに送り返すため、
ＤＭ ＡＰＩ、キャッシュマネージャーおよびＤＭサーバーコンポーネントが実
行されるノードまたはサイトレベルデータと、３)データをＳＡにまで上げ、中
央データベースに適用し、そのデータをＳＡおよびすべてのＤＭサーバーを介し
てネットワーク内のすべてのローカルキャッシュに下げるためにＤＭ ＡＰＩ、
キャッシュマネージャーおよびＤＭサーバーコンポーネントが実行されるネット
ワークレベルデータである。また、２レベルのデータの永続性も存在することを
理解する必要がある。すなわち、１)ＤＢＯＲに書き込まれることを意図した永
久データと、２)データの特性に応じてローカルキャッシュに書き込まれる遷移
データである。

【０１８２】 図５（f）にさらに示されるように、遷移データのローカルキャッシングデー
タの一例として、サービスに対するＳＬＰがアクティブに作動する場合、すなわ
ち、予想サービス需要に基づいてＳＬＥＥ内の永久オブジェクトとしてインスタ
ンス生成される場合、ローカルキャッシング戦略は、ＳＡから構成ファイル、す
なわちサービスプロフィールに準拠する指定持続時間にわたりローカルキャッシ
ュ内にこのサービスに対するデータの保存を指定する。ＤＭサーバーは、アクテ
ィブ時間にわたってローカルキャッシュ４１５を保存するためにそのサービスに
対するデータをキャッシュマネージャー４２０に送信する。特に、ＳＬＥＥ環境
が供給されると、キャッシュマネージャー４２０は、実行されるサービスを指定
することによりＤＭサーバー４２５に登録する。これに基づいて、ＤＭサーバー
４２５は、キャッシュマネージャーが登録しているサービスに対するローカルキ
ャッシング戦略を満たすために要求されるデータをＤＢＯＲ抽出４２７から検索
し、キャッシュマネージャー４２０にダウンロードする。好ましくは、ＤＭサー
バー４２５は、各ローカルキャッシュごとのローカルキャッシング戦略と、その
サイトにおけるキャッシュマネージャーを認識する。ゆえに、また、ＤＭサーバ
ー４２５は、一方的データをキャッシュマネージャーに供給できる。例えば、ネ
ットワーク主導の更新が発生すると、その更新は、直接ＤＭサーバーによってそ
のＤＢＯＲ抽出および/または妥当性検査と他のデータ管理プラットフォームに
分散するためにサービスアドミニストレーションに向けられる。ＤＭサーバーが
ＳＡから更新を受信する場合、この更新をキャッシュマネージャーに送信するこ
とにより、ローカルキャッシュを更新する。この場合、ＳＡクライアントおよび
ＤＢＯＲ抽出マネージャー４２６がＤＢＯＲ抽出を更新することを理解する必要
がある。データ管理は、ＤＭサーバーにＤＢＯＲ抽出の更新を通知するためにＳ
ＡクライアントとＤＭサーバー間にプロセスインターフェースを供給する。

【０１８３】 好ましい物理的実施形態において、データ管理コンポーネント４００は、市販
のデータベース製品を使用し、大半のデータベース製品は、ＡＰＩ、オブジェク
トリクエストブローカー(“ORB”)またはネットワークファイルサービスのよう
なインターフェース機構を供給している。したがって、データ管理は、ＮＯＳコ
ンポーネント７００を使用しないが、データ管理に対するサービス制御インター
フェースは、ＮＯＳの使用に適している。データ管理機能は、各サービスノード
に局所的であるため、この機能は、ネットワークにおける異なるオブジェクトお
よびリレーショナルデータベースシステム/製品により実現される。典型的なリ
レーショナルデータベース製品は、Versantオブジェクト指向データベースに加
えて、Oracle、InformixおよびSybaseから購入できる製品を含む。サービス制御
とデータ管理間のインターフェースは、特定のサービスノードにおいて使用され
るどのデータベースシステム/製品によってもサポートされ、ノードごとに相違
する。ＮＯＳにより使用可能とされる分散処理は、ＳＬＥＥにおける処理中に発
生し、この場合、各プロセスは、ローカルノードの定位置にあるインターフェー
スを使用してそのローカルデータ管理コンポーネントとインターフェース接続さ
れる。

【０１８４】 ＩＤＮＡ／ＮＧＩＮネットワークオペレーティングシステム(ＮＯＳ)コンポー
ネント７００は、図１０（ａ）−１０（ｃ）において詳細に説明される。説明さ
れるように、ＮＯＳ機能は、プロセス間通信の許可、オブジェクト連結性および
ＩＤＮＡ／ＮＧＩＮシステム１７０用の資源管理機能を含む。すべてのＩＤＮＡ
／ＮＧＩＮプロセスは、広範囲に分散されるアーキテクチャーにおける各種ハー
ドウェアおよびオペレーティングシステムプラットフォーム上で実行するため、
ＮＯＳは、すべてのプロセス間でプラットフォーム独立および場所独立通信を提
供する。特に、ＮＯＳは、いくつかの機能サブコンポーネントで構成され、サー
ビス実行および制御間、サービスアドミニストレーションとデータ管理間のイン
ターフェースを含めてすべてのＮＧＩＮプロセス間にインターフェースを供給す
る。また、ＮＯＳは、スイッチファブリック(資源コンプレックス)と呼およびサ
ービス処理(図１)間のインターフェースでもあり、相互に通信するために２つま
たはそれ以上のプロセスを同一ＳＬＥＥ上で実行可能にする。

【０１８５】 図１０（ａ）−１０（ｃ）に示されるように、ＮＧＩＮＮＯＳ機能サブコンポ
ーネントは、１)リクエストされたオブジェクトが作動しているコンピューター(
ネットワークアドレスとして)とメモリーアドレスを識別する物理アドレスに対
してデータおよびサービスオブジェクトの論理名を決定する名前翻訳(“ＮＴ”)
プロセス５７０、２)サービスノードにおける資源のステータスを追跡および維
持するローカル資源管理(“ＬＲＭ”)プロセス５７５、５７７、３)ＮＧＩＮネ
ットワーク全体を通じてすべてのサービスノード資源のステータスを維持するグ
ローバルネットワーク資源ステータス(“ＮＲＳ”)プロセス５９０と、プロセス
間通信を供給するため、４)一定の実時間呼処理性能要件を満たすか、あるいは
上回るようにオブジェクトの論理名を物理アドレスにマッピングすることにより
異なるコンピューティングプラットフォームにおけるオブジェクト間の通信、Ａ
ＰＩメッセージセットおよびインターネットプロトコル(ＩＰ)通信を可能にする
共通オブジェクトリクエストブローカーアーキテクチャー準拠GRB、Cambridge、
MA、およびDublin、IrelandのIONA Technologiesにより開発されたOrbixまたは
同等品により提供されるようなオブジェクト連結性を供給するためのサービスセ
ットを含む。

【０１８６】 システムのブート時点において、ＳＬＥＥ４５０が起動され、その環境内にお
いてＮＯＳクライアントコンポーネント５５８およびサービスマネージャープロ
セスコンポーネント５５４のインスタンスを開始する。ＳＭＳＬＰ５５４は、直
ちにインスタンス生成されるべきサービスの論理名を含むそのｎｏｄｅ＝ｓ構成
ファイル５８０から他のコンポーネントの論理名を検索する。その後、ORBネー
ムサービスに対する論理名を供給し、物理アドレスに対する論理名をマップする
。ORBは、そのポイントからサービスオブジェクト連結性を維持する。また、ORB
ネームサービスは、その他のサービス登録用にも使用される。ＳＬＥＥ上で起動
される各サービスは、ＮＯＳに登録し、これらの登録を介して、ORBは、論理名
に対する物理アドレスを識別する。

【０１８７】 インタラクティブオブジェクト間のプラットフォーム独立通信を実行するには
、インターフェース定義言語(“ＩＤＬ”)により使用可能になるようにインター
フェースが定義される。現在、COBRAは、ＩＤＬをサポートしているが、リモー
ト方式呼び出し(RMI)プロトコルのような他のオブジェクト指向通信技術は、実
時間呼処理に対する性能要件が満たされることを条件として実行される。特に、
ＩＤＮＡ／ＮＧＩＮコンポーネントのそれぞれに対するインターフェースは、そ
れらの生成時点で定義され、ローカルＬＲＭ５７５に関連する永久データのスト
アーまたはライブラリー(示されていない)に保存することにより実行時に利用可
能にする。サービスは、このライブラリーを照会するために使用可能にされ、新
規オブジェクトインターフェースについて学習する。ＮＯＳクライアントプロセ
ス５５８およびＮＯＳマスター５６０は、ＮＯＳサービスとのインターフェース
接続用に使用され、ＮＯＳＮＴおよびＬＲＭサービスを要求するためにそのＳＬ
ＥＥ内で実行するすべてのサービスにより使用されるＮＯＳクラスライブラリー
であり、図１０（ｂ）−１２に関して説明される。

【０１８８】 図１０（ｂ）は、１つ以上のＳＬＥＥ４５０および４５０’を実行するコンピ
ューターに常駐するＮＯＳＮＴ機能サブコンポーネント５７０とＬＲＭ機能サブ
コンポーネント５７５の機能アーキテクチャーを説明する。この場合、ＮＴおよ
びＬＲＭサブコンポーネントは、各ＳＬＥＥに関連する。図１０（ｂ）は、個々
のＳＬＥＥコンポーネント４５０および４５０’と個々のＮＯＳコンポーネント
７００および７００’を実行する最低２つのコンピューティングシステム４４０
および４４０’を有する単一ＩＤＮＡ／ＮＧＩＮサービスノードまたは”サイト
”２０４の一例を説明する。個々のＳＬＥＥコンポーネント４５０および４５０
’と個々のＮＯＳコンポーネント７００および７００’は、個々のＮＴ機能サブ
コンポーネント５７０および５７０’と個々のＬＲＭ機能サブコンポーネント５
７５および５７５’を含んでいる。単一ＳＬＥＥは、セパレートコンピューター
上で実行するように示されているが、２つまたはそれ以上のＳＬＥＥが同一コン
ピューター上で作動可能なことを理解する必要がある。コールライン論理、サー
ビス論理または呼処理論理プログラム、永久的に実行する特性ディスクリミネー
ターオブジェクトプログラム、あるいはＮＯＳクライアントオブジェクト５５８
、もしくはその他のプロセスであるいくつかのサービスオブジェクトまたはプロ
セス(S１…S４と表示される)は、各ＳＬＥＥ４５０、４５０’上で実行されてい
る。

【０１８９】 本明細書に説明されるように、各ＮＯＳＮＴ機能サブコンポーネント５７０、
５７０’は、あるプロセスを他のあらゆるプロセスで呼び出し可能にし、被呼プ
ロセスの異なるバージョンおよびインスタンスを通して無変更に維持される単一
共通論理名を使用することにより使用するデータまたはサービスオブジェクトの
正しいバージョンと使用するそのオブジェクトの最適インスタンスを識別するた
めのプロセスを含んでいる。ゆえに、ＮＯＳＮＴコンポーネント５７０は、プロ
セスからオブジェクトリファレンス、バージョニングおよびインスタンスの物理
ロケーションを密閉(保護)する。

【０１９０】 本明細書に説明されるように、各サービスノードにおけるＮＯＳ７００の各ロ
ーカル資源マネージャー(“ＬＲＭ”)コンポーネント５７５、５７５’は、サー
ビスプロフィール(構成)ファイル５８０に保存される構成規則にしたがってノー
ドのＳＬＥＥ上で実行するサービスを決定する。サービスプロフィール(構成)フ
ァイルは、サービスプロフィールの内容を含み、その一例は、表２に説明され、
ローカルキャッシュに保存するためにＳＡコンポーネントから展開される。まず
、ＬＲＭは、そのノードにおいてローカルキャッシュ４１５(図１０（ａ）)に保
存されるこのサービスプロフィールファイル５８０を読み取り、サービスプロフ
ィールファイルの規則にしたがってサービスを実行する特定のＳＬＥＥと、その
ＳＬＥＥにおいて(永久オブジェクトとして)アクティブに実行するか、あるいは
オンデマンドでのみインスタンス生成されるサービスを決定する。

【０１９１】 特に、本明細書に説明されるように、ＳＡは、各サービス毎にＳＡ内にフォー
マットされたデータファイルとしてインスタンス生成されるサービスプロフィー
ルを生成し、サービスプロフィールは、サービス要件と配置する必要のあるネッ
トワーク内のＳＬＥＥおよび/またはコンピューターを指定する。ネットワーク
内に展開される特定のサービスに対する典型的なサービスプロフィールは、本明
細書の表２に示される。

【０１９２】 さらに図１０（ｂ）において、ＬＲＭ５７５は、詳細に説明されるように各サ
ービス資源のヘルスおよびステータスを追跡することによりサービス実行の実行
時構成および最適化を可能にする。特に、各ＬＲＭ機能サブコンポーネントは、
そのＳＬＥＥ上で実行するようにプログラムされるすべてのサービスリスト、Ｓ
ＬＥＥ上で実行中のサービスプロセス(オブジェクトリファレンス)および予め決
められた閾値に基づいてそのノードにおけるＳＬＥＥの現行負荷ステータス(処
理能力)のリストを維持する。

【０１９３】 より詳細には、ＮＯＳのＬＲＭコンポーネント５７５は、システム内の各オブ
ジェクト(論理プログラム)に対応するオブジェクトリファレンスのローカルキャ
ッシュに組み込まれるライブラリーセットであり、オブジェクトリファレンスは
、通信を可能にするためＩＰアドレスおよびポート番号のようなサーバーに関す
る情報を含んでいる。新規オブジェクトがシステム内で利用可能になると、ＮＯ
Ｓに登録される。すなわち、データ管理を介してローカルキャッシュに登録する
ために新規オブジェクトに対するオブジェクトリファレンスが作成される。

【０１９４】 直ちにインスタンス生成すべきサービスを決定するためにそのサービスプロフ
ィール(構成)ファイル５８０を照会した後、ＮＯＳＬＲＭコンポーネント５７５
は、ＳＬＥＥ４５０において実行するようにＮＯＳクライアントインスタンス５
５８を介してＮＯＳＮＴ５７０からＳＬＥＥのアクティブサービスマネージャー
オブジェクト５５４にサービス起動リクエストを送信する。SMオブジェクト５５
４は、ＳＬＥＥサービスの制御を可能にするためのＡＰＩオブジェクトである。
例えば、インアクティブサービスのリクエストを受信した時点で新規サービスを
インスタンス生成するケイパビリティを供給する。すなわち、インスタンス生成
され、サービスがＬＲＭ５７５を介してＮＯＳに登録された時点でプロセススレ
ッドをオブジェクトに割り当てることを可能にする。あるサービスは、その論理
名を使用して別のサービスにより呼び出されるため、ＬＲＭは、構成ファイル内
の規則を使用し、論理名をアクティブインスタンスの物理アドレスにマップする
ORBネームサービスを利用することにより呼び出されるインスタンスを決定する
。

【０１９５】 図１０（ｂ）に示されるように、セパレートコンピューター４４０’’または
コンピューター４４０またはコンピューター４４０’のような共有コンピュータ
ーにおいてＮＯＳコンポーネント７００”上で実行されるサイトＬＲＭ５７７は
、ＮＧＩＮサイトまたはサービスノード２０４に関連する。サイトＬＲＭ５７７
は、次のように機能する。１)各ＳＬＥＥ上で実行しているすべてのプロセスの
現行負荷の関数である各ＳＬＥＥにおけるサービスのアベイラビリティを追跡し
、２)各資源のＳＬＥＥ識別子を含めて、それぞれ個々のＳＬＥＥＬＲＭ５７５
のアクティブに更新されたコピーである資源ステータスリストを維持する。サイ
トＬＲＭサブコンポーネント５７７は、必ずしも限定されるものではないが、１
)発呼サービスインスタンスに対する被呼サービスインスタンスの近接度(異なる
ＳＬＥＥに対する同一、異なるサイトに対する同一)、２)被呼サービスにより要
求されるデータ管理データに対する被呼サービスインスタンスの近接度と、３)
現行システムおよびプロセス負荷を含むいくつかの判断基準に基づいて使用すべ
きリクエストされたサービスのインスタンスを決定する。

【０１９６】 図１１（ｂ）に説明される例のように、プロセス、例えば、ＳＬＥＥ１におけ
るS１が特定のプロセス、例えば、Vnetサービスを実行するためにＳＬＰ、S４を
インスタンス生成する必要がある場合、ＮＯＳは、まず、サービス、すなわちオ
ブジェクトリファレンスがローカルキャッシュ、例えば、ＳＬＥＥ１で利用可能
かどうかに関する決定を実施する。ローカルＬＲＭ５７５がリクエストされたオ
ブジェクトリファレンスを有していない場合、ＮＯＳは、サイトレベルＬＲＭ５
７７を検索し、リクエストされたサービスに対応するその特定のオブジェクトリ
ファレンスのロケーションを決定する。例えば、図１１（ｂ）に示されるように
、そのオブジェクトは、ＳＬＥＥ２に見られ、見つけられた時点で、ＮＯＳは、
ＳＬＥＥがそれを実行する能力を有している場合、すなわち利用閾値まで達して
いない場合、そのオブジェクトをインスタンス生成することによりそのサービス
を利用可能にする。

【０１９７】 さらに図１０（ｃ）に示されるように、各ＳＬＥＥ用の個々のＬＲＭ５７５と
各サイト用のＬＲＭ５７７に加えて、ＮＯＳコンポーネント７００は、さらにネ
ットワークワイドな資源管理機能を実行するプロセスであるネットワーク資源ス
テータス(“ＮＲＳ”)サブコンポーネント５９０を含む。特に、ＮＲＳは、ネッ
トワークの各サイトＬＲＭ、例えば、図１０のサイト４４０ａ−４４０cに対応
するサイトＬＲＭ５７７ａ、..５７７cにおいて各サイトＬＲＭにより維持され
るデータのサブセットを含む。ＮＲＳ５９０は、１)ＳＬＥＥリスト、２)各ＳＬ
ＥＥ上で実行するようにプログラムされるサービスのタイプと、３)各ＳＬＥＥ
上でアクティブに実行しているサービス、すなわちパーセント基準としてのＳＬ
ＥＥ＝ｓ現行負荷を含む。このＮＲＳサブコンポーネント５９０は、サイトＬＲ
Ｍ５７７ａ、…、５７７cが満たせないリクエストに対する別の伝搬レベルをＮ
ＯＳに供給する論理的集中機能である。付加的に、ＮＲＳサブコンポーネント５
９０は、各ＳＬＥＥ４５０に対するインジケーターを含んでおり、そのＳＬＥＥ
がアップまたはダウンであるか、そのＳＬＥＥがサービス利用閾値に達している
かどうかを示す。”アップまたはダウン”インジケーターおよび利用閾値アプリ
ケーションは、ＳＬＥＥが他のサービスからサービスリクエストを受け入れるた
めに利用可能であるか判断するために使用され、ＮＲＳサブコンポーネントは、
ＳＬＥＥが利用可能かどうかに関わらず、これらのインジケーターおよび閾値ア
プリケーションを条件として、単にバイナリーインジケーターを供給できるだけ
である。一例として、リクエストされたＳＬＰオブジェクトがＳＬＥＥ内に見ら
れるが、そのＳＬＥＥがリクエストされたプロセスをインスタンス生成する能力
を有していない場合、そのＳＬＥＥに対する利用閾値に達しているため、そのサ
ービスに対するそれ以上のリクエストを処理できないという通知をサイトＬＲＭ
５７７に送信する。また、この情報は、ＮＲＳコンポーネント５９０にも伝搬す
る。

【０１９８】 好ましくは、各ノードは、システム内の各ＳＬＥＥにおけるメモリー容量、デ
ータベース容量、リクエストされたオブジェクトに対するキューの長さ、キュー
の総時間およびその他の資源/負荷パラメーターをモニターするためにモニタリ
ングシステム５９５(図１０（ａ）)を実行する。これらの要素は、１つ以上のこ
れらの要素に基づくＳＬＥＥの利用閾値に関する判断を下すＮＯＳ７００に対し
て利用可能にされる。固定閾値に加えて、複数の閾値をヒステリシス用に使用す
ることもできる。

【０１９９】 ＮＴ、ＬＲＭおよびＮＲＳにより実行される機能は、ＮＯＳ７００がロケーシ
ョン独立処理を供給できるようにし、一方、ＮＧＩＮの全体的な処理能力の最適
化は、図１２（ａ）−１２（ｃ）および１５（ａ）と１５（ｂ）において詳しく
説明される。

【０２００】 図１０（ａ）と１２（ａ）に示されるように、ＳＬＰデータおよび他のコンポ
ーネントを含むサービスパッケージは、(構成パッケージとして)構成され、ＳＡ
コンポーネント５００から個々のサービスノードに配置されたノード構成プロセ
ッサー(“ＮＣＰ”)５６４に供給されるノード構成ファイルにダウンロードされ
、ＮＲＳ５９０にダウンロードされる。ＳＡにダウンロードされる構成データは
、１)サービスネーム(各サービス毎の)、２)各サービスに対するインサービス日
付/時間、３)各サービスに対するアウトサービス日付/時間(ある場合)、４)サー
ビス依存性、例えば、実行する現行サービスに対してメモリーおよび他のプロセ
ス(ＳＬＰ)によりロードすべきデータベース、５)サービスカレンダー、例えば
、開始時刻持続時間、立ち上げ負荷量(予想負荷)を含む祝日曜日、６)インスタ
ント当たりの負荷率と、７)閾値パーセントを含むサービスプロフィールに関す
るデータ構造を具備する。一例として、特定のサービスにおいて、ＳＬＥＥの負
荷閾値が１００/サービスインスタンスであり、予想負荷量が２００の場合、Ｓ
ＬＥＥにおいてそのサービスをサポートするため、最低２つ、好ましくは３つの
インスタンスを利用可能にする必要がある。

【０２０１】 ＮＲＳコンポーネント５９０に供給および維持される構成データは、各ノード
の各サービスに対するサービスネーム、サービスのケイパビリティ、すなわち、
そのサービスの実行に要求されるハードウェアおよびソフトウェアがノードで利
用可能であることを示すインジケーターと、サブクラス、すなわち１)アクティ
ブ、２)過負荷、３)アウトオブサービスおよび４)シャットダウン、例えば、メ
ンテナンスへの移行を含むそのサービスに対するノードステータスを具備する。
例えば、サービスノードは、サービスを供給することはできるが、インアクティ
ブ、すなわち、サービスがインスタンス生成されない。しかし、インスタンス生
成されることを可能にする。サービスがインスタンス生成されると、そのノード
のｓｅｒｖｉｃｅ＝ｓステータスはアクティブになる。ゆえに、ＮＲＳシステム
５９０は、ケイパビリティおよびステータスを監視し、特定のノードにおいてサ
ービスを起動するためにリクエストを受け入れるかどうかを判断する。

【０２０２】 さらに図１２（ａ）に示されるように、各ノード構成プロセッサー５６４は、
そのノードが現在実行中のものを含む情報を有するノードキャッシュステータス
(“ＮＣＳ”)データベース５６８を維持してアクセスする。この情報には、サー
ビスオブジェクト名およびオブジェクトリファレンス、ノードおよびＳＬＥＥ、
そのステータス(アクティブパーマネント/テンポラリー、アラームレベル、アウ
トオブサービス、削除)、最終ステータスメッセージのタイムスタンプ、最終変
更(更新)のタイムスタンプと、最終ＬＲＭステータスプロセスチェックのタイム
スタンプが含まれる。さらに、ＮＣＰ５６４は、構成ファイルに対するアクセス
を有することにより、プロセスの開始および停止時点をモニターできる。特に、
ノード構成プロセッサー５６４は、構成ファイルを読み取り、ＳＬＥＥのインス
タンス生成を開始するか、あるいは時間切れになった時点でパーマネントからテ
ンポラリーにステータスを変更する。ローカルサーバー構成エージェントプロセ
ス５６７は、ＳＬＥＥ４５０とＮＣＰ５６４およびＬＲＭシステム５７７間の通
信を可能にするメカニズムである(図１１)。ＳＬＥＥ４５０は、例えば、ＳＬＥ
Ｅにおけるサービスがもう、あるいは現時点で利用不能なことを示すアラーム閾
値信号５６２を発する。この信号は、アラームレベル、例えば、一時的なアウト
オブサービスまたは削除を示すためにノードキャッシュステータスデータベース
５６８内のサービスのステータスを変更し、さらに現在、このサービスが別のＳ
ＬＥＥで実行されているかどうか判断するためにＮＣＳノードキャッシュステー
タスデータベースを照会するサービスノード構成プロセッサー５６４に送信され
る。この判断に基づいて、別のＳＬＥＥをインスタンス生成するか、あるいは別
のＳＬＥＥ上のそのサービスに対する新規スレッドをインスタンス生成する。ゆ
えに、ＮＯＳがネーム翻訳割当てを実施する場合、ノード構成プロセッサー内の
データに基づく。

【０２０３】 ノードキャッシュステータスデータベース５６８により保存および維持される
付加的なデータは、サービスノードでインスタンス生成されるＳＬＥＥに関連す
るＳＬＥＥサービスステータスデータプロフィールを具備する。このＳＬＥＥス
テータスプロフィールは、ＳＬＥＥ名、ＳＬＥＥオブジェクトリファレンスと、
アクティブ、テンポラリー、アラーム、アウトオブサービスまたは削除を含むＳ
ＬＥＥステータス、ＳＬＥＥからノード構成プロセッサーに送信される最終ステ
ータスメッセージのタイムスタンプ、最終ステータス変更(更新)のタイムスタン
プ、メッセージがノード構成プロセッサーからＳＬＥＥをチェックするために送
信される最終時間を示している最終ハートビートのタイムスタンプと、アラーム
レベル解消時間を含む。ＳＬＥＥアクティブ時間のスケジュールと、シャットダ
ウンステータスがハード、すなわちＳＬＥＥが現在そのＳＬＥＥで呼サービスが
実行されているかどうかに関係なくシャットダウンするか、あるいはシャットダ
ウンステータスがソフト、すなわち、すべての呼が終了または削除された後、Ｓ
ＬＥＥがシャットダウンすることを意味するＳＬＥＥシャットダウン時間のスケ
ジュールＳＬＥＥは、ステータスデータの一部として付加的に維持される。

【０２０４】 実時間呼処理システムが資源メンテナンスシステムに関わりなく作動すること
、すなわち、同一データが使用されるが、異なるプロセスがメンテナンスを実行
することを理解するべきである。特に、図１２（ａ）に説明されるように、ＮＯ
Ｓネーミングプロセス５７０ａ、ｂは、実時間サービスリクエストを処理するた
めの実時間プロセスエージェントである。他方、今後、説明されるようにノード
構成プロセッサー５６４は、管理機能を実行し、ＳＡからの入力、ＳＬＥＥから
のアラームおよびステータス入力に応答し、ＮＯＳネーミングからの新規プロセ
スをインスタンス生成するようにリクエストする。

【０２０５】 図１２（ａ）および１２（ｂ）に示されるように、ＬＲＭシステム５７７は、
次のサブコンポーネント、すなわち、ＬＲＭステータスプロセッサー５７９、Ｎ
ＣＰ５６８、ＮＣＳ５６８および(ローカル)サーバーキャッシュステータスデー
タベース５６９で構成される。ＳＬＥＥとＮＣＰ５６４間のインターフェースと
して機能するローカルサーバー構成エージェント５６７は、オプションとして含
まれる。ＬＲＭステータスプロセッサー５７９は、ＮＣＳデータベース５６８を
読み取り、ステータス変更または更新(図１２（ａ）)を監視し、ステータスの変
更または更新をローカルキャッシュが維持されるローカルサーバーキャッシュス
テータスデータベース５６９に分配するオブジェクトである。図１２（ｂ）に示
されるように、まずノードキャッシュデータベース５６８は、更新の記録タイム
スタンプと共に各ＳＬＥＥにおける現行のアクティブ実行サービスにより更新さ
れる。ＬＲＭステータスプロセッサー(“ＬＳＰ”)５７９は、定期的に、例えば
、２秒毎にノードキャッシュデータベースにポーリングすることにより、各ＳＬ
ＥＥをサポートするコンピューティングシステムのキャッシュに分配される更新
変更を監視する。例えば、ＬＳＰは、ＮＣＳを読み取り、最終ＬＳＰポーリング
のタイムスタンプを上回るタイムスタンプを含むすべてのステータス変更をピッ
クアップし、さらにローカルサーバーキャッシュステータス５６９に対するコピ
ーを更新する。ゆえに、例えば、ノードキャッシュが不具合状態中に失われる場
合、ローカルノードは、ローカルレベル(サーバーキャッシュステータス)におい
てステータスの現行コピー上で実行される。

【０２０６】 図１２（ｃ）は、ノードキャッシュステータスデータベース５６８の詳細なア
ーキテクチャーを説明する。図１２（ｃ）に示されるように、好ましくは、異な
るサーバーに常駐する２つのキャッシュシステム、すなわち、１)現行キャッシ
ュ資源として機能するホットキャッシュ５７６ａと、２)ニアリアルタイムでホ
ットキャッシュ資源を維持するように機能するスタンバイキャッシュ５７６ｂが
供給される。本発明の資源管理システムの作動中の異なる時間において、ホット
キャッシュ５７６ａは、ノードキャッシュステータスデータのメインリポジトリ
ーとして使用される。このデータは、１つ、あるいはそれ以上のキャッシュマネ
ージャープロセス５７３ａ、ｂの制御下において１つまたはそれ以上のキャッシ
ュログ５７２ａ、ｂに対して定期的に更新される。これは、キャッシュマネージ
ャープロセス５７３ａ、ｂの機能であり、キャッシュログ５７２ａ、ｂを参照す
ることにより更新ステータス情報を取得し、冗長性を達成するためにスタンバイ
キャッシュ５７６ｂに入力する。実施形態において、ホットキャッシュ５７６ａ
がステータス更新を受信する時点とキャッシュマネージャーがスタンバイキャッ
シュ５７６ｂを更新するために要する時間の間に５−１５ミリ秒までの小さな遅
れ時間が存在する。ノードキャッシュデータベースに不具合が存在する場合、あ
るいはホットキャッシュ５７６ａが現時点でそれ以上の更新を受け入れられない
場合、システムは、ホットキャッシュ５７６ａからホットキャッシュとして機能
するスタンバイキャッシュ５７６ｂに切り替わる。最高性能を達成するため、ホ
ットキャッシュからスタンバイキャッシュへのキャッシュの切り換えは、約５０
ミリ秒以内に発生する。キャッシュマネージャーがホットキャッシュ５７６ａを
定期的にチェックすることにより、なお機能していること、そしてスタンバイキ
ャッシュ５７６ｂへの迅速な切換えを保証することを理解する必要がある。付加
的に、各キャッシュマネージャー５７３ａ、ｂは、ノード構成プロセッサー５６
４、ＬＲＭステータスプロセッサー５７９とノードＮＯＳネーミングプロセス５
７０ｂを含めてノードキャッシュステータスデータベースにアクセスする３つの
主要プロセスのそれぞれに登録する。これは、３つのエージェント、すなわち、
ＮＣＰ、ＬＲＭステータスプロセッサーとノードＮＯＳネーミングが切換えを通
知され、キャッシュの正しいコピーを参照する。

【０２０７】 好ましい実施形態において、図１３に示されるように、ノードにおける最初の
ＳＬＰインスタンス生成プロセスは、次の通りである。まず、ステップ４６０に
おいて示されるように、ＮＣＰは、そのノードの構成ファイルのサービスプロフ
ィールのすべてを読み取り、４６３において、例えば、時刻に基づいてインスタ
ンス生成すべきＳＬＰを決定する。そして、ＮＣＰは、ＳＬＥＥ＝ｓ現行負荷と
サービスデータ依存性に基づいてＳＬＥＥ/サーバーを選択する。例えば、デー
タベースをロードする必要がある場合(またはノードがインアクティブの場合)、
ＮＣＰ７６４は、キャッシュマネージャーに対して依存性データをサーバーデー
タ管理にロードすることをリクエストする。データがすでにＤＭからＳＬＥＥに
ロードされているか、あるいはデータをロードする必要がない場合、プロセスは
、ステップ４７０に進む。要求されたデータがＤＭによりロードされると、ＤＭ
は、ステップ４６８で実行される時点でＮＣＰに応答し、ＮＣＰは、ステップ４
７０においてＳＬＥＥにＳＬＰをロードするようにリクエストする。ＳＬＥＥは
、サービスがステップ４７２において利用可能である旨応答し、ＮＣＰ７６４(
図１２（ｂ）)は、ステップ４７４においてアクティブサービスネーム(ＮＯＳネ
ーム翻訳用に登録されたオブジェクトリファレンス)によりノードキャッシュス
テータスを更新する。付加的に、ステップ４７６において、そのノードにおける
サービスのステータスは、ＮＲＳ５９０において”アクティブ”に更新される。
続いて、そのサービスをインスタンス生成する場合、ＮＲＳサービスステータス
は、すでに”アクティブ”ステータスにあるため更新されない。ＮＣＰは、ＮＯ
Ｓを供給するためにネームおよび登録オブジェクトリファレンスによりノードキ
ャッシュ７６８を更新し、ＮＯＳがネーム変換を実行できるようにする。ゆえに
、ＮＯＳがリクエストを入手した時点で、オブジェクトリファレンスを有する。

【０２０８】 ＳＬＥＥ閾値処理プロセスは、図１４（ａ）に関して説明される。ステップ４
７０に示されるように、ＳＬＥＥ、例えば、ＳＬＥＥ１は、サービス閾値を上回
った時点でアラームを発信する。”警告”または”過負荷”(閾値レベル超過)を
含むいくつかの可能性のある閾値レベルがあるのが好ましい。ステップ４７２か
ら４８５は、図１３のステップ４６０から４７４に対応する。この場合、ステッ
プ４７２は、ノードキャッシュステータス７６８を読み取るためにＮＣＰの機能
を呼び出すことにより、サービスがそのサービスノードの他のＳＬＥＥで実行さ
れているかどうか判断する。ロードに基づいて、インスタンス生成プロセスは、
ＳＬＥＥ、例えば、ステップ４７４に示されるようなＳＬＥＥ２により開始され
、要求データの依存性は、ＤＭによりロードされる。ステップ４７８(ある場合)
におけるＤＭ応答の受信後、ＮＣＰは、ＳＬＰを選択したＳＬＥＥ２にロードす
るようにリクエストし、ＳＬＥＥ２は、サービスがＳＬＥＥ２においてインスタ
ンス生成された時点で応答する。最後にステップ４８５において、ＮＣＰ７６４
は、例えば、警告または”過負荷”状態に対して第１ＳＬＥＥ１のノードキャッ
シュステータスを更新する。さらに、ＳＬＥＥ２におけるサービスのステータス
は、ＮＲＳにおいてアクティブに設定される。この時点において、依然としてノ
ードに能力があり、サービスもアクティブであるため、ＮＲＳは、更新される必
要のないことを理解する必要がある。しかし、ノードがＳＬＥＥにより立ち上げ
るための余裕がないと判断される場合、ステータスは、過負荷になり、ネットワ
ーク資源ステータスは、ノードが過負荷であることを反映するために更新される
。

【０２０９】 図１４（ｂ）に示されるようなＳＬＥＥモニタリングプロセスは、付加的にロ
ーカル資源管理システムに組み込まれる。ＳＬＥＥモニタリングプロセスは、ノ
ードキャッシュステータスデータベース７６８に対するステータス変更の更新を
可能にするために必要である。特に、プロセスは、図１４（ｂ）のステップ４９
１に示されるようにノード構成プロセッサー７６４によるノードキャッシュステ
ータスデータベース７６８のノードサービスＳＬＥＥステータスデータプロフィ
ールの読み取りを可能にすることによって始まる。特に、ＮＣＰは、ステップ４
９２における先のＳＬＥＥステータス更新以降、予め決定された時間”X”が経
過しているかどうか判断する。最終ＳＬＥＥ更新ステータスが予め決められた時
間“X”を超える場合、ＮＣＰは、ステップ４９３に示されるようにローカルサ
ーバー構成エージェント７６７を介して照会メッセージをＳＬＥＥに送信する。
また、このＮＣＰの生成する照会メッセージは、ハートビートとしても知られて
いる。次に、ＮＣＰは、ステップ４９４に示されるようにハートビートメッセー
ジに対するＳＬＥＥから応答またはエラー応答を待つ。ＳＬＥＥが更新ステータ
スにより応答すると、ＮＣＰは、ステップ４９９に示されるようにノードキャッ
シュデータベースのＳＬＥＥステータスプロフィールを更新する。応答がないか
、あるいはエラー応答が受信されると、ＮＣＰは、ステップ６９５に示されるよ
うにＳＬＥＥプロフィールステータスを、例えば、”アウトオブサービス”に設
定する。付加的に、ＮＣＰは、そのＳＬＥＥ上の各サービスオブジェクトリファ
レンスをアウトオブサービスに設定し、ステップ４９６においてアウトオブサー
ビスＳＬＥＥに取って代わるようにスタンバイサーバーでＳＬＥＥインスタンス
生成プロセスを開始する。これは、現在ＳＬＥＥで実行されているサービスオブ
ジェクトに関する判断を下すため、オブジェクトリファレンスライブラリーの照
会を必要とし、また、ＳＬＥＥがアウトオブサービスになった時点でインスタン
ス生成されているサービスを判断するため、オリジナル構成ファイルの照会も必
要とする。ＳＬＥＥがアウトオブサービスであると判断した場合、他のフォルト
トレラントおよび/または冗長機構がシステムに組み込まれている場合を除いて
、そのＳＬＥＥで実行されているすべての呼状態が失われ、回復されない。新規
ＳＬＥＥの立ち上げは、ＳＬＥＥがダウンした時点で利用可能であったそれらの
オブジェクトインスタンスを回復するだけである。新規ＳＬＥＥがインスタンス
生成されると、ＮＣＰは、ステップ４９７に示されるように新規ＳＬＥＥの応答
を待つ。新規ＳＬＥＥが肯定的に応答すると、ＮＣＰは、ステップ４９９におい
てノードキャッシュステータスデータベースのＳＬＥＥステータスの更新を回復
する。ほかに、ＮＣＰは、新規ＳＬＥＥプロセスをサービスノードの別のサーバ
ーでインスタンス生成する。いずれにしても、プロセスは、ＳＬＥＥモニタリン
グステップ４９１に戻る。

【０２１０】 ＮＯＳ７００によるロケーションおよびプラットフォーム独立処理の供給を可
能にするＮＴ、ＬＲＭおよびＮＲＳを含むＮＯＳにより実行され、ＮＧＩＮの全
体的な処理能力を最適化する資源管理機能は、図１５（ａ）−１５（ｂ）に詳細
に説明される。図１５（ａ）および１５（ｂ）に関して説明されるＬＲＭプロセ
スフロー５８３において、サービス制御サーバー１のＳＬＥＥ１で実行されるサ
ービスS１は、ステップ５８５において示されるようにサービスS２を呼び出す必
要があることを前提とする。サービスS１は、スイッチファブリック呼制御から
事象サービスリクエストを受信しているFDまたはサービス論理プログラムであり
、例えば、呼処理を終了するために別のＳＬＰ、S２を呼び出す必要がある。

【０２１１】 特に、図１５（ａ）を見ると、サービスS１はＳＬＰ２の論理名を使用してＮ
ＯＳ７００に要求を発行する。サービスオブジェクトのＳＬＰ要求が受信される
と、ステップ５８６ａで表示されているように、要求されたサービスがローカル
のサービス制御サーバー上でアクティブに実行されていることをＮＯＳが認識す
るかどうか、すなわち、ＮＯＳが要求されたサービスの論理名に関連するオブジ
ェクト参照を持っているかどうかを判断するために、ＮＯＳ名変換関数５７０ａ
が実行される。ローカルサーバーキャッシュに格納されたデータは、次のＮＯＳ
名前付けデータフィールドを含むことが望ましい：１) 通常、サービスを記述
する論理名であり、機能ディスクリミネータデータがポイントする名前であるＳ
ＬＰ論理サービス名；２) たとえば、実行中のサービス、ノードなどの、その
バージョンを必要とする特定の顧客のために、必要とされる特定のサービスのバ
ージョンを記述するオプションのバージョン番号；３) 以下を含む状態：展開
された、すなわち、ＳＡがノードに対して作業パッケージを展開したが、サービ
スが起動されていない、アクティブ、すなわち、サービスが現在アクティブであ
ることを示す、またはフォールバック、たとえば迅速に反転するために、サービ
スオブジェクトの前のバージョンにフォールバックすることが望ましい場合；４
) ＩＰアドレス、ポートおよびオブジェクトインスタンスの物理位置を識別す
る他の情報を含むオブジェクト名または参照；５) 稼動開始日時および稼動停
止日時；６) たとえば、オブジェクトが使用できない場合や、起動できない場
合のエラープロセスオブジェクト名；７) フォールバック状態で実施されるフ
ォールバックオブジェクト名。図１１および１２について本明細書でさらに説明
するように、ローカルサーバーＮＯＳ名前付けプロセス５７０ａは、サービス制
御サーバー内の特定のＳＬＥＥ内で実行中の現在アクティブなサービスのみを用
いてローカルサーバーキャッシュ状態データベース５６９を更新する、ＬＲＭ状
態プロセッサ５７９によって供給されるサービスから恩恵を受ける。これはロー
カルサーバーＮＯＳ名変換関数が最初にローカルで実行されるようにするためで
ある。ＮＯＳが最初に名前要求を獲得すると、オブジェクト名（またはオブジェ
クト参照）を得るために論理名を検索する。ＮＯＳは論理名からオブジェクト名
を得て、ノードＬＲＭプロセスは、ステップ５８６ｂに示すように、１個以上の
以前示したビジネスルールに基づくアドレスに対し、要求されたオブジェクトの
最良のインスタンスを決定する。

【０２１２】 ステップ５８６ａにおいて、論理名が認識され、オブジェクト参照が使用可能
ならば、プロセスはステップ５８６ｂのＬＲＭ関数に進み、稼働率閾値などの一
定の基準に従って、ＳＬＥＥ１で実行中のS２のアクティブな（「使用可能な」
）インスタンスを決定する。アクティブなインスタンスが見つからない場合、Ｌ
ＲＭはS２がＳＬＥＥ１上で動作するようにプログラムされているかどうかを確
認することがあるが、インスタンス生成されていない。このような場合、ＳＬＥ
Ｅ１に使用可能な十分な容量があれば、ＮＯＳ７００はＳＬＥＥ１上でS２のイ
ンスタンスのインスタンス生成を行うことがある。先に述べたように、サーバー
レベルのＬＲＭは、サーバーにおいてアクティブなオブジェクトのみを知ってお
り、インスタンス生成されたオブジェクトを知っている。オブジェクトが現在ア
クティブであり、ローカルサーバーレベルでインスタンス生成されている場合、
このサービスの新たなスレッドのインスタンス生成用のオブジェクト参照が、Ｓ
ＬＰ要求に返される。ＮＯＳは、返されたオブジェクト参照に基づいて要求され
たサービスを実行するための新たなサービススレッドのインスタンス生成を開始
し、まだインスタンス生成されていない場合はオブジェクト参照を返す。

【０２１３】 ステップ５８６ａにおいて、ＳＬＥＥ１が使用可能な容量を十分に備えていな
いと判断された場合や、S２がＳＬＥＥ１上で実行できない場合は、ステップ５
８８ａにおいて、ＳＬＥＥ１上のＬＲＭがサイトＬＲＭ５７７ａにサービス要求
を送信する（図１４）。サイトＬＲＭは同様のビジネスルールを適用して、S２
のインスタンスがアクティブかどうかを判断するか、そのサイトの別のＳＬＥＥ
上でインスタンス生成する必要がある。したがってステップ５８８ａにおいて、
ノードＮＯＳ名前変換関数５７０ｂ（図１２（ａ））は、要求された論理名がそ
のノードで使用できるかどうか、すなわち、そのノードの同一または別のローカ
ルサービス制御サーバーにおける別のＳＬＥＥが、要求されたサービスの論理名
に関連付けられたオブジェクト参照を保持しているかどうかを判定するために実
行される。論理サービス名がステップ５８８ａで認識される場合、ＮＴサブコン
ポーネント５７０はＮＯＳＬＲＭ５７５に問い合わせを行って、S２のどちらの
インスタンスを使用するか決定する。するとノードＬＲＭは、要求されたサービ
スのための望ましいオブジェクト参照を検索するために、ステップ５８８Lでノ
ードキャッシュ状態データベース５６８（図１２（ａ））に対してビジネスルー
ルを適用し、アクティブならば、そのアドレスを通話ＳＬＰ（ステップ５８５、
図１５（ａ））に返す。サービスが現在、インスタンス生成されていない、ある
いは特定のＳＬＥＥ上の要求されたサービスが、プロセスロードや他の課された
制約によってインスタンス生成されない、と判断された場合は、図１３に詳細に
説明されているように、ステップ５８８cにおいて、ノードキャッシュ状態デー
タベース５６８をチェックし（図１２（ａ））、たとえばサービス接近、データ
接近、閾値処理、現在処理中のロードなどに関連するビジネスルールを実行し、
サービスオブジェクトがインスタンス生成可能であると判断された場合にはＳＬ
ＥＥ内の要求されたサービスをインスタンス生成することによって、割当ておよ
びローディングプロセスが実行され、通話ＳＬＰにアドレスが返される。１つの
ＳＬＥＥについて、インスタンス生成のために２つ以上のサービスが使用できる
場合は、インスタンス生成するサービススレッドを決定するためにラウンドロビ
ン方式が使用できることを理解する必要がある。

【０２１４】 図１５（ａ）に戻り、ステップ５８８ａにおいて、現在のノードが要求された
論理名を認識しない、すなわち、ノードキャッシュが要求されたサービスの論理
名に関連付けられたオブジェクト参照を備えていない、あるいは適用されたビジ
ネスルールによって、そのノードでオブジェクトをインスタンス生成しないと判
断された場合、グローバルネットワークリソース状態（ＮＲＳ）プロセス５９０
は、ステップ５９２で問い合わせされ、インテリジェントネットワーク１７０に
渡るＳＬＥＥの現在の状態がチェックされ、S２のためにサービス要求を処理で
きるＳＬＥＥが判定される。これに先立って、ステップ５９２に示したように、
ネットワークリソース管理がオブジェクト参照を検索するために問い合わせされ
た回数を示すインデックス数が、事前定義された限度、たとえば３回を超えたか
どうかを判定するためのチェックが行われる。この閾値を超えた場合、プロセス
は終了し、ステップ５９６に示すように、サービスオブジェクトが見つからず、
エラー状態が存在することが管理者に通知される。ＮＲＳ問い合わせ閾値を超え
ていない場合は、ステップ５９４に示すように、ＮＲＳプロセス５９０は、要求
されたデータを実行可能な、ネットワーク内のサービスノードを決定する。ステ
ップ５９４に示すようにインテリジェントネットワーク内のノードを決定した後
、プロセスは図１５（ｂ）のステップ５９８ａに続く。ここでは、要求されたサ
ービスの論理名に関連付けられたオブジェクト参照を獲得するために、ノードＮ
ＯＳ名前変換関数５７０ｂが実行される。そのノードの論理サービス名がステッ
プ５９８ａで認識されない場合、ＮＲＳ問い合わせインデックス数がステップ５
９９で増分され、プロセスは図１５（ａ）のステップ５９２に戻って、エラー状
態が存在するどの場合に、インデックス数閾値を超えたかをチェックする。図１
５（ａ）のステップ５９２において、ＮＲＳ問い合わせインデックスが事前定義
された閾値を超えていない場合、ＮＲＳプロセス５９０は、別のサービスノード
で使用可能なサービスの新しい位置を見つけるために、ステップ５９４で再度問
い合わせされる。

【０２１５】 論理名がステップ５９８ａで認識されると、プロセスは、許容可能な処理ロー
ドにしたがって、要求されたオブジェクト参照に関連付けられたアドレスを決定
するために、ステップ５９８ｂにて続行される。そして、このアドレスは、図１
５（ａ）のステップ５８５に示すように、要求ＳＬＰに返される。ステップ５９
８ｂにて、サービスが現在インスタンス生成されてい（アクティブで）ないと判
断された場合、プロセスはステップ５９８cに進み、そのノードのノードキャッ
シュ状態データベースをチェックし、ビジネスルールを実行し、サービスオブジ
ェクトがインスタンス生成可能であると判断された場合にはＳＬＥＥ内の要求さ
れたサービスをインスタンス生成することによって、割当ておよびローディング
プロセスを使用可能にする。その後、インスタンス生成されたオブジェクトＳＬ
Ｐのアドレスは、ステップ５９８ａで要求クライアントに返される。

【０２１６】 S２のアクティブなインスタンスが選択されると、そのS２インスタンスのオブ
ジェクト参照はＳＬＥＥ１上のＮＴに返される（ステップ８０２）。そしてＮＴ
は論理名S２を、S２の選択されたインスタンスのオブジェクト識別子に効率よく
変換し、S１とS２の間で進行中のプロセス間通信でS２のそのオブジェクト識別
子を使用する。オブジェクト識別子には、ＩＰアドレス、ポート、オブジェクト
インスタンスの物理位置を識別するその他の情報が含まれている。いったんオブ
ジェクト参照が決定されると、ＮＯＳは、ＣＯＲＢＡ準拠ＱＲＢを実行すること
によって２つのサービス間のオブジェクト連結性と、ＵＤＰ／ＩＰなどのデータ
通信コネクションレスプロトコルを供給する。呼出されたサービスの位置は、同
一のＳＬＥＥで、あるいは数千マイル離れた別のサイトの別のＳＬＥＥで実行さ
れているかにかかわらず、通話サービスにとっては完全に透過性である。したが
って、通話を処理するために必要なＳＬＰがリモートサイトのＳＬＥＥでインス
タンス生成される場合、その通話はなお、受信されたスイッチで保持されている
。たとえば、オブジェクト参照がＮＲＳレベルに経由の別のサイトでいったんア
クセスされた場合、ＮＯＳによって、オブジェクト参照が今後の参照のために要
求サイトにてキャッシュされ、サービス管理を通じて監査されるようにすること
が好ましい。したがって本発明の実施形態において、このサービスが再度必要に
なった場合にサイトＬＲＭ探索を開始して、さらに探索を行わずに済むようにす
るために、サービスS２のオブジェクト参照はその後、位置する場所にかかわら
ず、ＳＬＥＥ１のＬＲＭ５７５のローカルキャッシュでキャッシュされる。当業
熟練者にとっては、ＳＬＥＥにてサービスオブジェクト参照データを供給する各
種方法があることは明白であろう。たとえば、ＮＯＳデータ複製機構を採用して
、サイトＬＲＭ５７７のオブジェクト参照すべてを、そのサイトの各ＳＬＥＥの
それぞれのＬＲＭに複製してもよい。

【０２１７】 本明細書で好ましい実施形態として説明および記述した、この３層のリソース
管理階層（ＬＲＭ、サイトＬＲＭおよびＮＲＳ）は、当業熟練者によって変更可
能であることを理解する必要がある。たとえば、追加のＮＯＳリソース管理層を
、それぞれ単一のグローバルＮＲＳと通信できる、複数の区域内ＮＲＳコンポー
ネントが設けられた階層内に組み込んでもよい。

【０２１８】 ＮＧＩＮシステムの主要な機能コンポーネントについて記述したので、ここで
好ましい１つの実施形態を記述する。

【０２１９】 図１６は、サイト２０４とも呼ばれる、サービスノードの好ましい物理アーキ
テクチャを示す。図１６のサイトは、次世代スイッチ（"ＮＧＳ"）と呼ばれる交
換プラットフォームよりそれぞれ成る１個以上のネットワークスイッチコンポー
ネント１８０ａ.....１８０ｎを含むものとして示されている。サービス制御機
能は、IBMRS６０００、DECAlphaサーバー、Pentiumベースのパーソナルコンピュ
ータなどの汎用コンピュータである、サービス制御サーバー４０５によって実現
され、オペレーティングシステムは、それを実行するコンピュータと互換性のあ
る、たとえばMicrosoftWindowsNT、UNIX、SunSolarisまたはVMSなどの、実行中
の任意の標準オペレーティングシステムを使用できる。次に、ＮＧＩＮＳＬＥＥ
４５０はオペレーティングシステム上で動作し、各種サービス制御プロセスを実
行するためのサービス制御/ＳＬＥＥ環境を供給する。図１６に示すように、サ
イト４５には１個以上のサービス制御サーバー４０５ａ、....、４０５ｎがあっ
てもよい。好ましい実施形態において、サービス制御サーバーは複数のＳＬＥＥ
を実現できるが、１個のＳＬＥＥはサービス制御サーバー全体を消費することが
あり、ＬＲＭ（表示せず）も同一のサービス制御サーバー上で動作し、サイトＬ
ＲＭ（表示せず）はこのサイトのすべてのサービス制御サーバーで実行されてい
るサービスを追跡するために動作している。各ＮＧＳリソース複合体１８０ａ-
１８０ｎは、たとえばGagabitイーサネットスイッチなどのLANスイッチによって
供給された高速データリンク５７によって、サービス制御サーバー４０５ａ、…
、４０５ｎとインタフェースを行う。通話制御およびサービス制御は、リンク５
７を介してＮＮＯＳを使用して、サービス要求とサービス応答を交換する。ＮＧ
Ｓスイッチ１８０ａは特定のサービスノードに物理的に配置されていることがあ
るが、ネットワーク内のどこでも、ＮＮＯＳ経由でサービス制御機能にアクセス
できる。

【０２２０】 図１０（ａ）および１５をさらに詳しく見ると、ＤＭサーバー４２５、ＤＢＯ
Ｒ抽出マネージャ４２６、ＳＡクライアント４２２およびＤＤＡＰＩ４２６のデ
ータ管理コンポーネント４００機能は、サービス制御サーバーと同じ種類のコン
ピュータハードウェア/オペレーティングシステムであるが、ＳＬＥＥを必要と
しないバックエンドＤＭサーバー４０７ａ、...、４０７ｎで実現される。好ま
しい物理的実施形態において、データベースサーバー４０７は、ＤＢＯＲ抽出デ
ータベースより成る共有ディスクアレイを備えたデュアル冗長プロセッサとして
実装される。サービス制御サーバー４０５ａ、...、４０５ｎは、たとえばGagab
itイーサネットスイッチなどのＬＡＮスイッチによって供給された高速データリ
ンク５９によって、バックエンドＤＭサーバー４０７ａ、...、４０７ｎとイン
タフェースを行う。サービス制御/ＤＭサーバーＬＡＮ６１は、リソース複合体
（ＮＧＳ）をサービス制御サーバーにインタフェースさせるために用いるＮＧＳ
/サービス制御ＬＡＮ６３から分割される。なぜならＮＧＳ/サービス制御ＬＡＮ
６３はデータ集約型リアルタイム通話処理機能に使用されるのに対して、サービ
ス制御/ＤＭサーバーＬＡＮ６１は、大半の通話処理データがサービス制御サー
バー内のローカルメモリにキャッシュされるため、はるかにトラフィックが少な
いからである。ＤＭサーバー自体は、各種データの種類に従って分割される。た
とえば、サーバー４０７ａ、４０７ｂと対応する共有ディスクアレイ４０８のペ
アは、サービス（ＳＬＰ、ＳＩＢＢなど）およびサービスデータ（消費者プロフ
ァイル、ルーティングテーブルなど）に使用され、ＤＭサーバー４０７ｎ-１、.
..、４０７ｎと対応する共有ディスクアレイ４１８の第２のペアは、マルチメデ
ィアデータ（音声オブジェクト、ファックスオブジェクトなど）に使用される。
この第２セットのＤＭサーバーは、データスイッチ４２９経由で１個以上のイン
テリジェント周辺（"ＩＰ"）機器にアクセスされ、ＩＰ８８ａ、８８ｂ、ＤＭサ
ーバー４０７ｎ-１、４０７ｎ、マルチメディアデータ用の共有ディスクアレイ
４１８、高速データスイッチ４２９の集合アーキテクチャは、音声応答装置（"V
RU"）などの対話式サービスプラットフォームに最適である。

【０２２１】 図１６のアーキテクチャからわかるように、インテリジェント周辺機器はＳＬ
ＥＥ／ＮＮＯＳ環境内で動作するため、サービス制御サーバー４０５ａ、...、
４０５ｎからサービス応答を受信することができる。たとえば、サービス制御サ
ーバーは、発信者のために音声メッセージを再生するために、インテリジェント
周辺機器にサービス応答を送信できる。ＩＰ８８ａ、８８ｂは電話通話の受信お
よび処理が可能であり、（回路交換またはパケット交換される）音声リンク経由
でＮＧＳのスイッチファブリックに接続されていることが好ましい。ＩＰはデー
タスイッチ４２９を用いて、要求された音声オブジェクトをＤＭサーバーから検
索する。ＩＰにはさらに、ファックスサーバー、ビデオサーバー、会議ブリッジ
が含まれてもよい。すぐに理解できるように、表示したＮＧＩＮサイト２０４の
アーキテクチャは、追加のサービス制御サーバー、ＤＭサーバー、ＮＧＳプラッ
トフォームおよびインテリジェント周辺機器をサイトＬＡＮに接続し、サービス
管理にて設定することによって、用意に追加できるため、拡張性が高い。

【０２２２】 図１７に示すように、外部インタフェースもサイト２０４に接続して、ＩＰア
ドレスを与えてもよい。特に、通話処理に必要であるが、ＮＮＯＳ準拠ではない
、ＮＧＩＮと外部システムの間のプロセスインタフェースを供給するために必要
な、各種外部インタフェース８３は、ＮＧＩＮアーキテクチャに組み込める。し
たがって、外部インタフェースは、外部システムが使用する通信プロトコルとメ
ッセージングフォーマットが何であれ、ＮＮＯＳに適合させる。ある実施形態に
おいて、インタフェースは信号ゲートウェイより成り、この信号ゲートウェイは
、たとえばＬＩＤＤクエリーを実行する場合などに、ＮＮＯＳを使用するＮＧＩ
Ｎプロセスを、ＳＳ７などの信号システムを使用する外部システムとインタフェ
ースさせる。したがって、ＳＳ７ゲートウェイを使用してＮＮＯＳメッセージを
ＳＳ７メッセージに変換したり、ＳＳ７メッセージをＮＮＯＳメッセージに変換
したりする。別の実施形態において、外部インタフェースがリモートデータゲー
トウェイを構成する。これを用いて、たとえば、電気通信サービスプロバイダの
大規模顧客が所有しているような、外部サービス制御ポイント（図１）とＮＧＩ
Ｎをインタフェースさせる。ＲＤＧはＮＮＯＳメッセージを、リモートＳＣＰが
必要とする種類のメッセージと通信プロトコルに変換する。

【０２２３】 さらに詳細に、図１７は、２つ以上のサイト２０４ａ、...、２０４ｎをリン
クするルーターベースまたはスイッチベースのWAN６９と外部インタフェースネ
ットワーク７９より成る、ＮＧＩＮシステムドメイン１０００の物理アーキテク
チャの例を示す。ＮＮＯＳサービスは、どのサイトのどのプロセスも他のサイト
の他のどのプロセスとも通信できるように、このWANを行き来している。サイト
２０４については複数の各種構成を使用してもよい。たとえば、サービスノード
２０４ａ、２０４ｂは、リソース複合体（スイッチ）とサービス制御機能の両方
を実現するノードである。データ管理ノード２０７として示されているように、
データ管理専用のサイトもある。

【０２２４】 本発明を理解するには、ＮＧＩＮシステムが、ＮＮＯＳが供給する分散処理機
能および場所独立プロセス間通信によって、そして通常のＳＬＥＥが与えるプラ
ットフォーム独立性によって、専用サービスノードを一掃することが重要である
。サイト２０４では任意のサービスが供給されるため、専用サービスノードに通
話を移送するする必要がない、すなわち、通話は、アクセスする最初のＮＧＩＮ
サービスノードで処理される。しかし、ＮＧＩＮシステム１０００によって供給
される高レベルの設定可能性によって、ネットワークが専用サービスノードを装
備するように設定できることを理解する必要がある。たとえば、会議ブリッジな
どのネットワークリソースは、専用サービスノードを展開するためにさらに費用
効率がよい。

【０２２５】 本発明の原理に従って、ＩＤＮＡ/ＮＧＩＮによって実行される通話サービス
用途と機能は、これに限定されるわけではないが、以下の種類に分けることがで
きる：１) 顧客定義ルーティング；２) 着信通話、通話先ルーティング；通話
拡張、シグナリングおよびアクセス種類を含む通話処理；３) 通話対話；４)
サービス。

【０２２６】 代表的なＮＧＩＮの顧客定義ルーティング機能および特徴として次のことが挙
げられる：

【０２２７】 １) 顧客の加入特徴、ルーティングプランネットワーク、そして顧客の外部
ルーティングデータベーストリガを探索するための、ネットワークによる通話発
信情報（ダイヤルした番号、発信スイッチ/トランク）を使用する機能。ルーテ
ィングプランとは、顧客が注文した具体的な高度ルーティング機能情報のことを
さし、顧客が複数のルーティングプランを持つ場合もあることを理解する必要が
ある；２) ダイヤルされた国内および国際ＶＮＥＴ番号が遮蔽される機能；３)
国内または国際ＤＡＬおよび自動即時通話（ＤＤＤ）着信をサポートするため
に、ＶＮＥＴダイヤル番号の桁を、スイッチが理解できる（アウトパルスディジ
ットなどの）形式に変換する機能；４) ネットワークから受信した発信情報を
用いることにより、通話起点の地理的ポイント（呼出者の市外局番、州、国コー
ド）の決定を含む、通話をルーティングする国際キャリアを決定する機能；５)
国際着信にファックス送信を行うために、スイッチに高品質トランクを供給す
るよう指示する機能；６) 顧客自動通話ディストリビュータ（ＡＣＤ）、たと
えばＡＲＵ、または生のオペレータリソースが利用できいない場合、ＮＧＩＮは
通話をネットワーク内に保持して、顧客のリソースが利用できるようになるまで
待機する機能を供給する。通話は待ち行列に入れられ、音声または音楽で対応が
行われる。顧客ＡＣＤが通話を受け入れることが通知されると、待ち行列の最初
の通話が顧客ＡＣＤに移送される。優先順位の異なる待ち行列を複数展開するこ
ともできる（ネットワークベースの待ち行列）；７) ダイヤルプラン変換の失
敗、範囲制約または補助コード検証などによって完了できない通話を、特殊メッ
セージ処理のための専用アクセス回線（ＤＡＬ）にリルート可能にする、カスタ
マイズメッセージ通知（ＣＭＡ）&故障応答メッセージ（ＦＲＭ）特殊ルーティ
ング処理を供給する機能；８) 意図した着信まで完了できない高度オーバーフ
ロールーティング機能を第２のまたは代わりの着信にルーティングする、ネット
ワーク通話リダイレクト（ＮＣＲ）機能を供給する機能。ＮＣＲ通話は、着信Ｉ
Ｄを備えた、原因値およびオーバーフローホップカウントによって索引される特
殊テーブルを使用する；９) ユーザーに透過的な方法で、発信者から得た着信
アドレスを変更し、通話を別の着信にリルートする機能（通話リルーティング/
代用リルーティング）。代わりの着信は、ＮＡＮＰＤＤＤ番号、Ｖｎｅｔ着信、
携帯電話番号、国際着信番号ＩＤＤＤ、ＡＣＤまたは音声/ファックスメールシ
ステムなどでもよい；１０) 低料金回線選択機能を供給する機能、すなわち、
ＤＡＬ着信に変換する指定ＶＮＥＴ番号のルーティングは、発信および着信スイ
ッチＩＤに基づいて無効になることがある；１１) 着信変換を行う際に、通常
の地理探索情報の代わりに、交換コード、地域ＩＤ（顧客のＮＸＸ交換ルーティ
ングプランidを用いて検索）を使用することを含む、ＮＸＸ交換ルーティングを
供給する機能；１２) 顧客が発信者の発信地域に基づいて通話をルーティング
できるようにする、通話点ルーティングを供給する機能。細分性には、ＡＮＩ、
ＮＰＡ−ＮＸＸ、国コード、ＮＰＡまたは都市コードが含まれる；１３) たと
えば、エラー状態やディジット収集に関するメッセージを、通話発信者に対して
再生しなければならない場合に、処理/プリアンブル情報（アクションコード）
をネットワークスイッチに返送する機能。１４) ＶＮＥＴ通話を企業、ネット
ワークまたはアクセス（発信スイッチ、キャリアなど）のレベルで選別する機能
（範囲特権スクリーニング）；１５) ＤＡＬ着信の発信者のＡＮＩを問い合わ
せ、これらをスイッチに返送することによって、ＤＡＬ着信のためのリアルタイ
ム自動番号識別（ＡＮＩ）を供給する機能；１６) この機能に加入している場
合に、ＤＡＬ着信に対してアウトパルスディジットを構築する際に顧客定義ＤＮ
ＩＳディジットを含む機能である、リアルタイムダイヤル番号識別システム（Ｄ
ＮＩＳ）を供給する機能；１７) ＶＮＥＴにリモートアクセスを供給する、す
なわち、ＶＮＥＴへのリモートアクセスに８００、９００およびグローバルフリ
ーフォン番号を指定する機能。ある番号をダイヤルすると、許可されたＶＮＥＴ
アドレスの特性と同様に、ＶＮＥＴダイヤルトーンが聞こえ、収集する補助ディ
ジットの数が与えられる；１８) ルートデータ通話機能を供給する機能、すな
わち、顧客がそのＶＮＥＴサービスについてすべてのデジタルルーティングをオ
ーダーする機能；１９）サービス課金情報、すなわち、ネットワーク要素に返送
されるアクションコード、機能コードおよびアウトパルスディジットを供給する
機能。これらのフィールドの多くは、通話の課金に役立つように、課金記録で使
用される；２０) ダイヤルした番号に関連付けられたＰＩＮまたは補助コード
の、補助コードスクリーニングおよび検査を供給する機能；２１) たとえば通
話スクリーニングやルーティング変換に必要な場合に、スイッチに正しい数の補
助コードディジットを収集するよう指示することによる、補助コード収集を供給
する機能と、実際の着信の探索および変換、あるいはＥＶＳＡＲＵによる一連の
補助コード受信に基づく検索データによる、補助コード変換を供給する機能。個
人通信サービス（ＰＣＳ）を支援して、変換は、ＰＩＮ補助コードの受信に基づ
いて決定される；２２) 通話種類および通話状態によって、異なる着信変換テ
ーブルを使用する機能（着信変換/可変長アウトパルシング）。ネットワークス
イッチに返送される実際の着信アドレスが決定される（あるいは場合によっては
ＡＲＵ）。通話は、国内および国際スイッチ/トランク（ＤＡＬ）または自動即
時通話ＤＤＤに着信する；２３) リモート問い合わせに対するタイムアウト処
理を供給する機能。８００ゲートウェイに対するリモートデータ問い合わせのタ
イマー（トリガー要求）が使用され、タイムアウトに対するデフォルトルーティ
ング応答が生成される；２４) 通話が２つ以上の着信を利用できる場合、加入
顧客およびネットワークリソースに対して、パーセンテージ割当てルーティング
を供給する機能。これにより、複数の着信に渡るロードバランシングがもたらさ
れる。顧客はたとえば最大１００着信と、これらの着信に割当てられる通話のパ
ーセンテージを指定することができる。ＡＲＵ着信に渡るロードバランシングも
、パーセント割当てを使用して実行してもよい；２５) スイッチベースのルー
ティングを供給する機能、スイッチベースのサービスをルーティングする機能。
これには、３/６/１０ディジットルーティングと国コードルーティングが含まれ
る；２６) タイムアウトルーティング、すなわちディジット収集タイムアウト
の際に通話をオペレータサービスにルーティングすること、を供給する機能；２
７) 顧客プロファイルの情報に基づいた、たとえば時間、曜日、通日（ＴＯＤ
、ＤＯＷ、ＤＯＹ）ルーティングなどの、スケジュールルーティングを供給する
機能；２８) ソースアドレススクリーニングを供給する機能。ソースアドレス
スクリーニングは、発信者が禁止宛先に電話をかけないようにし、サービスキャ
リアが、顧客にネットワークの外から発信できないようにすることによって、顧
客の仮想私設データネットワークにセキュリティをもたらす。顧客はこの機能を
利用して、特定のソースが特定の宛先に発信しないようにしながら、ネットワー
クの内部セグメント化を行うこともできる。この種のスクリーニングを用いて、
ソースを宛先の除外リストに含まれているものに関連付けて、通話を完了しよう
とする前にチェックする；２９) 宛先アドレススクリーニングを供給する機能
。これはソースアドレススクリーニングに類似したタイプのセキュリティであり
、通話を宛先に届かないようにすることを加入者に許可して、私設ネットワーク
の完全性を保護するものである。顧客はこの機能を用いて、ネットワーク内の特
定の宛先に安全にアクセスできる。この種のスクリーニングを用いると、宛先は
包含リストまたは除外リストのいずれかに関連付けられ、その宛先に対する通話
を許可する前にこれらのリストがチェックされる；３０) 顧客が仮想私設デー
タネットワークを定義するために用いる、閉鎖ユーザーグループを供給する機能
。閉鎖ユーザーグループ内からの発信された通話は、同じく閉鎖ユーザーグルー
プ内にある宛先のみに接続可能である；３１) 以下に説明する、通話パーキン
グを供給する機能；指定されたアドレス（たとえばＡＴＭエンドシステムアドレ
スフォーマット）が現在使用できない場合、ＮＧＩＮは、宛先が使用可能になる
か、保持期限が終了するまで、通話を保持することがある。宛先が使用可能にな
ると、通話設定が進められる；宛先が保持期限終了間に使用可能にならない場合
、通話は中止されるか、別の宛先に送信されることがある；３２) ＡＡＬパラ
メータ内の設定に基づくルーティングを供給する機能。"Setup"および"Add part
y"信号メッセージによって、特定の種類の宛先を指定するのに使用できるユーザ
ー定義パラメータの指定が可能となる。たとえば、発信者がビデオオペレータの
既知の番号をダイヤルする場合、スペイン語を話すオペレータが必要であること
を指定できる；３３) 通話を課金する必要があるアカウントコードを識別する
機能（たとえば、ＡＴＭ適合パラメータを使用して）；３４) 加入者の加入レ
ベルを実施を考慮した、サービス品質の加入制御を供給する機能。加入者がＡＴ
Ｍネットワークプロバイダにサインアップする場合、特定のサービス品質に関連
付けられた料金を支払う。SetupまたはAdd Partyメッセージがその加入者から送
信される場合、そのメッセージに関連付けられたサービスパラメータの品質は、
その加入者の加入に対して確認する必要がある；３５) ソースアドレス妥当性
確認を供給する、すなわち、SetupまたはAdd Partyメッセージに指定されたソー
スアドレスが正しく、着信ポートでの使用を許可されていることを確認する機能
。これによって、課金された側が実際に通話を行ったかどうかを確認できる；３
６) ＮＧＩＮは通話優先順位（ネットワークＡＣＤ）供給するものとする、す
なわち通話側の番号に基づいて、ＮＧＩＮは、もっとも重要な通話を優先順位付
けされた待ち行列または予約された顧客サービスの代表に入れて、着信に優先順
位を付けることができる；３７) 着信速度制御を供給する、すなわち、通話を
処理する容量があると予測される場合にネットワークに通話を与える機能。自動
通話ギャッピングを用いて、ダイヤルされた番号に基づいて通話を調整すること
もできる；３８) 常に偶発時ルーティングプランをロードおよび起動し、いっ
たん起動したら、現在アクティブであるルーティングプラン（特徴/機能）の代
わりに使用できる機能；３９) 顧客の通話プランで集計されるプラン性能統計
を供給する機能。これらの統計から、顧客は通話が応答センターに渡された回数
と、メッセージノードにルーティングされた回数を判断できる；４０) ディジ
ット回送を供給する、すなわち、発信者がディジット列全体を入力するのを待つ
のではなく、入力されたディジットを、ディジットのブロックが入力されたよう
に変換する機能；４１) 会議処理を供給する機能、すなわち、顧客加入探索を
実施したのち、会議予約情報記録を検索できる。８００"meet me"会議では、各
参加者は指定された８００番号と補助"suppcode"をダイヤルする。この通話は、
meet me会議の同一会議ブリッジにルーティングされる。

【０２２８】 ＮＧＩＮによってサポートされる代表通話処理機能には、次のものが含まれる
：企業または住居顧客の個別ダイヤルプランのサポート；ユーザーが自分のダイ
ヤルプランが変更できるようにすること；自動通話ディストリビュータ（ＡＣＤ
）とのインタフェースの供給；ＮＧＳおよびメッセージ保存システムとの相互作
用によるサポートマルチメディアメッセージの保存/転送/検索サービス；制限リ
ソースを待っている着信のための、高度待ち行列機能の供給；宛先に転送する情
報の決定；使用可能な番号パラメータのための、番号スクリーニング機能のサポ
ート；ある機能の特定のインプリメンテーションを実装したが、試験、メンテナ
ンスまたは監視のために制限モードで実行する、すべてのサービス/機能のため
のメンテナンスモード操作のサポート；たとえば、連続または同時着信のための
、１回の発信で複数の宛先をサポート；"add party to conference（会議参加者
追加）"機能の供給；潜在的な不正通話のブロック；ユーザーが進行中の通話の
種類を変更する機能をサポート；データおよび音声通話を両方ともサポート；コ
ネクションレスモードサービスのサポート；２者間および多者間通話のサポート
；マルチメディア通話のサポート；タイマーイベント、発信者要求および外部シ
ステム要求などの各種トリガに基づくＮＧＳによる単一または複数通話の開始。

【０２２９】 ＮＧＩＮは、着信通話の処理に関して、以下の特徴および機能を供給する：１
) 着信通話の受け入れ、すなわち、着信通話の指示を受信し、その通話をサー
ビスするために必要なリソースとアプリケーションが使用可能かどうかを判断す
る機能。必要なリソースとアプリケーションが使用可能ならば、着信通話は受け
入れられ、通知がスイッチに返送される。要求されたリソースまたはアプリケー
ションが使用できない場合は、拒絶指示がスイッチに返送される。２) リスト
を用いた着信通話スクリーニング、すなわち、加入者が、着信通話を拒絶または
受け入れるためのスクリーニングリストを定義できるようにする。リストが受け
入れリストとして定義されている場合、リストにある着信通話はすべて通常どお
り処理される。リストが拒絶リストとして定義されている場合、リストにある着
信通話はすべて拒絶される。着信通話が拒絶されると、発信者は通知を受け、次
に音声メールに案内される。加入者は重要な発信者に対して、スクリーニングを
無効にするためのパスワードを割当てることができる；３) リストなしの着信
通話スクリーニング、すなわち、加入者が、通話を受け入れる前に発信者の名前
を聞くことができるようにする。その後、加入者は通話を受け入れるか、音声メ
ールボックスにリダイレクトするかを選択できる；４) あらゆる種類のリソー
スに対する着信通話の待ち行列、すなわち、リソース（着信、オペレータ、また
は高価なハードウェアリソース）が使用できない場合、リソースへの接続を要求
している通話は、本明細書で説明した方法で待ち行列に入れられる。上述したよ
うに、システムは同一リソースに対する通話の優先順位に基づいて、１つ以上の
待ち行列を維持している。待ち行列のサイズは、リソース数の変化に基づいてリ
アルタイムに変更できる。待ち行列が使用可能になると、システムはその通話を
待ち行列の上部に押し出し、使用可能なリソースに割当てる。呼出し側が待ち行
列内で通話を停止すると、システムはその通話を待ち行列から除去し、残りの通
話を待ち行列の上方に１段ずつ押し上げる。タイマーは、タイマーが終了した場
合にシステムが発信者に通知し、その通話をリダイレクトするか、切断するよう
に、待ち行列内の通話に適用することが好ましい。この機能は、呼出し側が待ち
行列内に残っている間に、呼出し側処理に対するユーザー対話機能とともに使用
できる。対話の間に呼出し側から受けた指示は、呼出し側を待ち行列から除去す
る動作をトリガーすることがある。たとえば、呼出し側は、接続を待っている間
いつでも、接続を待つ代わりに、メッセージを残すことを選択してもよい；５)
通話待ち行列、すなわち、リソースが使用可能になるのを待つ間、通話を待ち
行列に入れて、オペレータの位置に配布すること。通話は手動または自動化オペ
レータに送信される；６) 呼出し側ＩＤ引渡し、すなわち、警報や通話待ち信
号に影響を与えずに、呼出し側の番号または名前（たとえば英数字）を、バンド
内信号によって、加入者端末に引き渡す機能。システムは、追加情報または指示
のために、呼出し側ＩＤを別の任意の文字と連結することもできる；７) 通話
が必要とするサービス処理の種類を判断するために、着信通話パラメータを分析
する機能（識別サービス）。このプロセスは、着信通話が転送通話か、再発信通
話であるかも識別する。以下は、サービスの種類を判定するために使用可能なパ
ラメータの一部である：ＡＮＩ、呼出し番号、呼出し番号ＮＯＡ、情報ディジッ
ト；８) 任意のサービスのサービスプロファイル情報にアクセスし、修正する
機能（サービスプロファイル識別）。サービスプロファイルは、サービス処理に
必要なパラメータを指定し、あるサービスパラメータに対してあるレベルの設計
可能性を与える。サービス固有パラメータの例としては、世界電話メニュー選択
着信オプションの国固有ＤＴＭＦ遅延パラメータがあげられる；９) 通話に応
答する前に、異なる種類の警報信号パターンを呼出し側に対して適用する機能（
カスタマイズ警報）。サービス論理の制御下で、既存の警報信号はどれでも適用
できる。新たな信号はいずれも、レポジトリに容易に追加して使用することがで
きる；１０) ＡＮＩ機能による試行閾値、すなわちＡＮＩによる試行がカウン
トされ、設定可能な閾値と比較される。これを用いて、次回発信者が通話する際
には、手動オペレータに転送する必要があること示す；１１) たとえば、スイ
ッチから渡されたＤＮＩＳに基づいて、顧客スクリプトを選択/実行する。いっ
たん発見されると、アプリケーションは実行される；１２) ファックスを検出
する、すなわち、この通話がファックス装置によって発信されたかどうかを判断
するために、着信通話を監視すること。"非通話"装置通話が呼び出していること
を通知するために、ファックス装置によって送信されたＣＧＮトーン（たとえば
１０.５秒鳴って、３.０秒止まる１００ヘルツのトーン）として「聞こえる」；
１３) 手動オペレータに以下の機能を使用できるようにする、エージェント制
御サービス：エージェントログオン/ログオフ；エージェント更新（エージェン
ト監視）；実行可/実行不可；タイミングサービス；時間および料金；スーパー
バイザーサービス；観測エージェント；ＯＡ＆Ｍサービス；ＤＮ初期化；１４)
国際リダイヤル、たとえば加入者が海外着信の通話で、話中または応答なし状
態に遭遇した場合、ネットワークは加入者がリダイヤルサービスを使用すること
を要求する。加入者は電話を切って、通話が応答されるか、時間切れになるまで
、ネットワークが着信をリトライするのを待つ。海外の相手が通話に応答した場
合、ネットワークは自動的加入者にコールバックし、２者間を相互にブリッジす
る。加入者が、あきらめる前に再試行を待つ時間を指定することもできる；１５
) 以下の事項を含む、電源を上昇させた場合の、ＰＣＳが携帯電話を登録する
機能；移動局の端末認証；移動局のユーザー認証；パスワードの受け入れ；加入
者ＰＩＮアクセス；ＰＩＮインターセプト；ソースアドレスの妥当性確認。

【０２３０】 ＮＧＩＮの通話宛先ルーティング機能は、ネットワークが通話を着信させる宛
先を決定できるようにする機能である。通話は、ネットワーク内の多くの各種エ
ンティティにルーティングでき、通話のルーティング方法の決定は、多様な要素
の組み合わせによって影響を受けることがある。ＮＧＩＮは、複数の外部システ
ムと協力して、通話宛先ルーティングを処理する。ＮＧＩＮは、着信通話に関し
て以下の特徴および機能を備えている：

【０２３１】 １) 発信点、発信者の識別、日時、曜日、通日、宛先リソースの利用パーセ
ントに基づいて、最低コストで通話をルーティング；２) 通話が要求するスキ
ルとターミネータが持つスキルを一致させることによって、適切な相手に通話を
ルーティング；３) 各通話のルーティング方向について、外部顧客データベー
スで調べる、顧客制御ルーティング（ＣＣＲ）；４) 意図した宛先まで完了で
きない通話は、第２または代わりの宛先にルーティングする、オーバーフロー通
話ルーティング；５) 優先順位ルート選択；６) 通話をオペレータにルーティ
ング；７) 優先通話を行うために、非優先通話を中断；８) 発信トランクグル
ープに基づいて通話をルーティング；９) コールコンテキストデータの一部と
してルーティングデータを捕捉；１０) データの任意のサブユニット（たとえ
ば、最初の３桁、最初の６桁など）に基づくルーティング；１１) すべての中
間処理をバイパスして、通話プランが通話内で別のポイントを直接ポイントでき
るようにする、Goto機能；１２) ＢＴ登録公衆電話から発信された通話かどう
かによって、通話をルーティング；１３) ＩＳＤＮ回線で発信されたどうかに
よって、通話をルーティング。

【０２３２】 ＮＧＩＮは、呼出し拡張の処理に関して、以下の特徴と機能性を提供する。

【０２３３】 １）アウトバウンド呼出しのセットアップ。それは、プラットフォームから国
内および国際終端へ呼出しを拡張するものである。プラットフォームにおいて呼
出し拡張を試みると、アウトバウンド・ポートがアウトダイアルを利用できるか
どうか決定するために照合が行なわれる。この能力には、手動オペレータ、音声
メール・システム、ファックスメール・システム、カスタマー終端、オペレータ
からオペレータへの転送、あるいは外国語オペレータへの転送に向けた呼出し転
送が含まれる。２）ルート作成命令のリクエスト。それは、プラットフォームか
ら呼出し拡張を行なう場合に、適切なルート作成命令を決定するためにルックア
ップを実行するものである。ルート作成レスポンスは、ルート作成プラン、区域
外直通ダイアル通話（ＤＤＤ）、あるいは、呼出しを内部的に拡張する論理終端
（ＬＴＥＲＭ）である場合もある。３）呼出し持続の制限。それは、種々のパラ
メータ、例えば、プリペイド電話カードの残高、バジェットカード、詐欺の危険
性の高い一部の呼出し起点あるいは終端における制限に基づいて、呼出しに持続
時間制限を課すものである。制限に近づくと、サービス論理に状況を認識させる
ためにイベントが生成されることになる。すると、サービスは、サービス論理に
基づいて適切に動作し始める。４）呼出し割込み。それは、呼出し持続制限や外
部命令など、ある種のイベント受けに基づいて進行中の呼出しに割込むものであ
る。一部または全部の当事者が接続を切られる。その後、サービスは、別の動作
を続行することができる。５）外向呼出しのスクリーニング。それは、ある特定
の番号に対して起点からダイヤルすることを禁じるものである。例えば、加入者
は、住所からのダイヤル９００番呼出しを制限することができる。６）呼出し進
行検出。それは、加入者へ呼出しの転送を試みる場合に、生きた応答が返って来
るかどうか決定する役割を課されたものである。提供可能な呼出し進行検出の型
には、応答管理、ＳＩＴトーン、ビジー、ベル不応答、応答機、生きた応答、通
話接続、ファックスまたはモデム検出、ダイアルトーン不検出、返答ベル音なし
、応答挨拶の持続、および、応答挨拶の無音時間測定中が含まれるが、これらに
限定されるものではない。７）ビジー/ベル不応答（Ｂ／ＮＡＲ）。それは、回
線上でビジーまたはベル不応答状態を検出するものであり、あらかじめ定められ
た動作手順を実行した結果に基づく。呼出し進行はモニタされ、ダイアルアウト
がビジーまたはベル不応答である場合には、呼出し進行は、別ルートで呼出しを
呼出し処理論理中の指定された位置へ送る。８）ＮＧＳに指示して呼出しをブリ
ッジすることができる。例えば、呼出し拡張を行なう場合に、アウトダイアルは
別の回線で実行される。いったん応答の徴候を受け取ると、発呼者と受信当事者
は相互にブリッジされて、その結果、両者は互いに通話できる。９）ブリッジさ
れた呼出し上のブリッジの切断。例えば、相手が電話を切った徴候を受け取ると
、両当事者間のブリッジは切られる。発呼者を別の第三者へ転送したい、あるい
は、処理を進めるためにレスポンス・ユニットへの復帰させたい旨の活性化コー
ドを受けた場合にも、ブリッジは切断される。１０）両当事者間の現用ブリッジ
が、一方の当事者に他方の動作（例えば、アウトダイアル、メッセージ検索）を
行なうことを可能にしている場合に、同ブリッジの切断を必要とするブリッジさ
れた呼出しを受けた場合には、ＮＧＳに指示して呼出しを待機させておくことが
できる。いったん動作が完了すると、待機中の当事者は呼出しの中に再ブリッジ
されることになる。待機中の当事者に対しては待機中、音楽テープを再生する。
１１）ＮＧＳに指示して機械転送を実行することができる。それは、転送に先立
って第三者に言葉を掛けることなく、第三者に対して呼出しを転送するものであ
る。例えば、当事者Aが当事者Bに電話をかける。その呼出しに対して当事者Bは
、自分は正しい相手でないと判断し、あらかじめ当事者Cに告げることなく、当
事者Cに当事者Aを転送する。１２）ＮＧＳに指示して同行転送を実行することが
できる。それは、呼出しを第三者へ転送するが、転送に先立って受信側当事者が
第三者に声を掛けるものである。例えば、当事者Aが当事者Bに電話をかける。当
事者Bは当事者Aを待機中にして当事者Cに電話する。そして、当事者Aが当事者C
とブリッジすることができるよう今から電話を切るように、当事者Bは当事者Cに
告げる。１３）ＮＧＳに指示して会議当事者能力を提供させることができる。そ
れは、複数の当事者（３２名まで）が、会議呼出し上で相互にブリッジできるよ
うにするものである。１４）ＮＧＳに指示してハングアップを検出させることが
できる。例えば、結果として呼出しトーンを下げる、回線上のハングアップ状態
の検出など。１５）ＮＧＳに指示して呼出しを解体させることができる。それは
、例えばポートやアプリケーション等の呼出しのためのリソースを、使用可能に
するものである。ハングアップ状態が検出された場合、または、アプリケーショ
ンが終了した場合には、呼出しは分解される。１６）ＮＧＳに指示してリンク・
トランク解放（ＲＬＴ）信号を発信させる。それは、当事者たちが、インテリジ
ェント・プラットフォームに対してスイッチにブリッジできるようにして、イン
テリジェント・プラットフォーム上のリソースをセーブするものである。１７）
自動アウトバウンド率制御。それは、宛先スイッチのオーバーロードを防止して
、サージが原因で起こるスイッチクラッシュから、同スイッチに接続するカスタ
マーを保護するものである。１８）ＨＬＲおよびＶＬＲ能力。

【０２３４】 ＮＧＩＮは信号発信特徴を提供して、以下に含まれるが、それだけに限定され
ない機能をＮＧＳが実行できるようにする。

【０２３５】 １）デュアルトーン・マルチ周波数（ＤＴＭＦ）信号発信。それは、スイッチ
、PBX＝s、その他の電話方式プラットフォームにおいて利用可能なインバンド信
号発信である。ＤＴＭＦ信号発信は、呼出し再起点に用いられる♯-ディジット
検出用としても提供される。２）マルチ周波数（ＭＦ）信号発信。それは、スイ
ッチにおいて利用可能な１タイプのインバンド・アドレス信号発信であり、トー
ン音を生成する。３）ダイヤルパルス（ＤＰ）信号発信。それは、内部的には割
込みの数がディジットや文字の値に一致する送信末端における直流または交流の
規則的な瞬時割込みからなる１タイプのインバンド信号発信である。４）自動電
話操作会社（ＢＯＣ）カード呼出し処理に必要なボーン音信号発信。５）当事者
たちがインテリジェント・プラットフォームに対比してスイッチにブリッジでき
るようにして、インテリジェント・プラットフォーム上のリソースをセーブする
リンク・トランク解放（ＲＬＴ）信号発信。６）ＩＳＵＰリンク・トランク解放
機能は、ＳＳ７ＩＳＤＮユーザ部の便宜メッセージ、便宜リクエスト（ＦＡＲ）
、便宜受容（ＦＡＡ）、便宜拒否（ＦＡＪ）、呼出し作成、呼出し詳細記録、呼
出し解放、呼出し転送、呼出しブリッジ作成、およびアクセス・タイプを用いて
実行される。

【０２３６】 ＮＧＩＮは、さらに、以下の呼出し対話の処理に関する機能性をもつ、以下の
サービス・オブジェクトを提供する。

【０２３７】 １）能力をもつ/をすり抜けるＤＴＭＦの検出/受容。すなわち、発呼者は、シ
ステム・プロンプトに応じてＤＴＭＦトーンを入力することによって情報を交換
する。「すり抜け」は、システム・プロンプトが開始される前に発呼者がシステ
ム・プロンプトに応答できるようにするＤＴＭＦディジット・ストリングを受容
する能力に依存する。ＤＴＭＦコレクション内部では、以下の能力が可能である
。ＤＴＭＦコレクションの開始/停止、１個の信号検出、パターンに合致する信
号シークエンスの検出、指定された番号の信号の検出、特定の信号またはパター
ン・カウントを検出した場合の時間切れ処理。２）能力をもつ/をすり抜ける音
声入力の検出/受容。それは、音声を検出して、プラットフォームにおいて処理
中の呼出しの一部として認識できるようにするものである。音声入力は、データ
ベース問い合わせ、メニュー・ルート選択、あるいはＰＩＮ型使用において使用
される。３）例えば、カスタム・メッセージ、一般的なメッセージ、あるいは、
録音メッセージ等の事前録音の音声メッセージの再生。これらのメッセージは割
込みおよび反復（再生）が可能である。メッセージは索引位置および、とばされ
た部分からの再生が可能である。（音声、音楽などの）オーディオ・スクリプト
の再生によって、アプリケーションは、呼出し関係者にイベントを通知したり、
関係者を刺激して情報に向かわせたり、メッセージを再生したり、話された情報
を中継したりできる。以下の能力またはパラメータは、音声再生能力によってサ
ポートされる。プレーヤーの起動、一時停止モードでのプレーヤーの起動、指定
されたＤＴＭＦ動作に対応するプレーヤーの停止、アプリケーション制御に基づ
くプレーヤーの停止、再生待機の制御、指定増分に基づく前または後への飛び越
し、指定増分に基づく再生スピードのアップまたはダウン、再生の一時停止また
は再開、指定増分に基づく音量の加減、および、シークエンス（連結句）内の複
数音声スクリプトの再生。音声プロンプト用に特化したリソース・ストアをマル
チプル・プロダクトが必要とする限り、多重言語音声スクリプト作成はサポート
されることが望ましい。サービスの大半は多重言語をサポートするので、それら
は、また、上記の音声プロンプトの多重言語バージョンも記憶している。４）ペ
ージング会社との情報交換に使用されるＤＴＭＦ再生機能。各ページに伝達され
る情報は、ページング・サービス・プロバイダ特有のもので、メニュー選択およ
びページャーＰＩＮ、ページ・ストリングを含めて可能な情報をもつことが望ま
しい。５）メニュー・ルート作成。それは、発呼者がＤＴＭＦまたはＳＩＶＲ入
力を用いて、メニューに先行プログラムされたオプション・セットから選択する
ことを可能にするものである。オプションは、呼出しルート作成用、または、別
メッセージの再生用としても提供される。６）呼出し処理を援助するデータベー
ス・ルックアップおよび問い合わせの実行。問い合わせは、ＮＧＩＮデータベー
スまたはカスタマー・ホスト・データベースに対して行なうことができ、例えば
、音声メールボックスのステータスや、カスタマー・プロファイル、ファックス
・メールボックス・ステータスなどに関連する情報や、特定のルート作成情報に
関して行なうことができる。７）請求側第三者の確認。それは、コレクトコール
類似の方法によって、被請求側第三者の番号が支払い能力のあるものかどうか確
認できるようにするものである。さらに、同確認は、ＳＳ７ＬＩＤＢB（ライン
情報データベース）確認経由で実行できる。８）AT&Tカードの確認。それは、Ｂ
ＯＣカードに対して実行されるＬＩＤＢ確認類似の方法によってAT&Tカードの確
認を可能にするものである。９）請求側番号確認。それは、ある呼出しに対して
提出された請求側番号が実際に支払いを受けられることを保証するものである。
同機能は、以下のようなステップから成り立つ。請求側番号の長さおよび形式の
確認、被請求側番号の制限の照合（新発行カード、請求型制限など）、外部確認
（ＬＩＤＢ、ＡＭＥＸなど）。１０）ＢＯＣカード確認。例えば、適切なＢＯＣ
ＳＴＰＳＴＰに対して問い合わせを要求するＳＳ７ゲートウェーからＳＳ７ＴＣ
Ｐメッセージを送信することによってＢＯＣカードを確認する。ＢＯＣＳＴＰは
、ＬＩＤＢデータベースに問い合わせて、その結果をＩＳＮへ返す。１１）被呼
出し番号の確認によって、呼出しが同番号に帰着することを確かめるための幾つ
かの照合ができる。例えば、国際番号がダイヤルされた場合には、カスタマーが
同国/市コードへ帰着しうることを保証するための照合が行なわれ、同様に、他
の請求制限も適用可能である確認過程には以下の方法が含まれる。被呼出し番号
形式照合（例、１０デジィットまたは０１＋１６デジィット）、ＮＰＡ／ＮＸＸ
または国/市コード確認など。１２）コレクトコール番号請求確認によって、同
番号に対してコレクトコールが申し込まれた場合、宛先が支払い可能であること
の確認が可能になる。同確認は、ＳＳ７ＬＩＤＢ問い合わせ経由で提供される。
１３）国内商用クレジットカード確認によって、商用クレジットカードの確認が
可能になる。１４）国際商用クレジットカード確認によって、商用国際クレジッ
トカードの確認が可能になる。１５）ＶＮＥＴカードの確認によって、ＶＮＥＴ
カードの確認が可能になる。１６）データベース更新能力。例えば、ＮＧＩＮ独
自のデータベースやカスタマー・データベース等の様々な種類のデータベースを
更新する能力を含む。サービス論理、カスタマーおよび発呼者は、一定のデータ
ベースを更新することができる。例えば、音声メールが配達された際には、メー
ルボックス・ステータスが更新されるか、または、カスタマーが自分のルート作
成プランを変更することができる。１７）音声記録能力によって、加入者は「名
前による呼出しスクリーニング」特徴を実行することが可能になるので、発呼者
は当該名前を記録するよう促される。その後、名前は、ＡＲＵが１ファインド・
ミー番号の生きた応答を受信した際に、加入者に対して再生される。同音声ファ
イルはＡＲＵ上に永久に残っているわけではなく、発呼者が加入者に接続された
後、または、呼出しが終了した後で削除される。同能力によって、受信側当事者
に対して後刻再生するために、発呼者は情報を記録しておくことが可能になる。
同能力の使用には、音声メールの配達、または、後の呼出しスクリーニング時に
使用するための個人識別情報の記録が含まれる。１８）ファイル管理能力は、発
呼者が、ファイルとして記憶されているファックスまたは音声メールを作成した
り、削除、修正、または閲覧できるようにする。１９）ページング送信能力によ
って、英字＝数字ページの送信が可能になる。例えば、呼出しはモデム・プール
経由で行なわれ、「ＴＡＰ」プロトコルはページ送信に利用される。２０）ファ
ックス収集能力によって、発呼者がファックスメール・システムに送信されてい
る間、ＮＧＩＮはファックス・メッセージを収集することができる。システムは
、また、加入者がファックスメール・システムを使用してファックスを外部ファ
ックス装置に送信できるようにする能力もサポートする。ファックスメール・シ
ステムは、加入者から、ファックス配達情報とともにファックスを収集する。以
下のファックス収集能力は、ファックス収集のためにサポートされる。受信ファ
ックス待ち、ファックス・ネゴシエーション開始、ファックス・ネゴシエーショ
ン停止、ファックス再ネゴシエーション強行、単一受信ページ受信、全受信ペー
ジ受信、およびファックス受信停止。２１）ファックス送信能力によって、例え
ば、ファックスが外部ファックス装置に対して配達される場合に、ＮＧＩＮはフ
ァックス伝達送信ができる。ファックス送信の際、アプリケーションはファック
ス・ネゴシエーションのパラメータ（速度、解像度、ヘッダ/フッタ情報など）
を制御する。以下のファックス収集能力は、ファックス再生のためにサポートさ
れる。ファックス・ネゴシエーション開始、ファックス・ネゴシエーション停止
、ファックス再ネゴシエーション強行、単一ページ送信、全ページ送信、および
ファックス送信停止。２２)ファックス同報通信によって、ＮＧＩＮはファック
ス配達域リストを維持して、同配達域リストに対してファックスを配達するよう
指定することができる。同リストには、外部ファックス装置の電話番号や、その
他のファックス・メールボックス用の識別名が含まれることもある。２３）音声
同報通信によって、ＮＧＩＮ加入者は音声配達域リストを維持して、同配達域リ
ストに対して音声メッセージを配達するよう指定することができる。同リストに
は、外部電話番号や、その他音声メールボックス用の識別名が含まれることもあ
る。２４）ジョブ/メッセージのスケジュール配達。それは、加入者がファック
スまたは音声メール・システムに指示して、ファックス/音声メール・メッセー
ジを外部電話番号またはシステム内の別のメールボックスに送信させる際、加入
者が同メッセージの配達されるべき日時を指定することができるものである。２
５）発呼者・テイクバックによって、発呼者は、アウトダイヤル位置への呼出し
開始の後、アプリケーションへ復帰することができる。発呼者は、次の動作を開
始するために進行中のブリッジされた会話に割り込むことができ、また、受信側
当事者は電話を切って、次の動作のために発呼者をプラットフォームへ復帰させ
ることができる。２６）アプリケーション分岐によって、アプリケーション・ス
クリプトは、他スクリプトへ分岐した後、呼出し文脈が保存されている主スクリ
プトへ復帰することができる。これにより、主制御アプリケーションによって呼
出される、カスタマー向け特定機能を実行する小アプリケーションの設計が可能
になる。２７）例えば、声紋一致などの特定の話者を認識する能力を提供する話
者依存音声認識（ＳＤＶＲ）。発呼者音声は、安全なアクセスを提供するために
先に記憶させた声紋と一致可能である。個人化が達成されると、特定の発呼者は
、特定のプロンプトと、同プロンプトに対して再生するメッセージを確保する。
２８）発呼者に対して音声でディジットを返答する能力を提供するための音声返
答ディジット。それは、完全なテキスト音声能力の部分集合である。２９）テキ
スト音声能力によって、テキストは音声に転換され、発呼者に対して再生される
。同能力の使用には、Ｅメールを読むこと、および、発呼者に対するデータベー
ス問い合わせの結果が含まれる。３０）音声テキスト能力は、発呼者が提供する
（電話に向かって話された）情報を利用して、データ操作のために同情報をテキ
スト・ストリングへ転換することによって、音声をテキストに転換する。３１）
さらにより大きな、指定された語彙をもつＳＩＶＲの拡張であり、音素に基づい
た大語彙音声認識（ＬＶＶＲ）。ＬＶＶＲは、例えば、ディジット単独または「
はい/いいえ」という語に対比して、相互ファンド名などの、全ストリングを認
識する能力を提供する。３２）キーワード識別によって、ＮＧＩＮは、話された
１文全体に含まれるキーとなる句を認識することができる。３３）呼出し記録の
生成によって、プラットフォーム時刻、呼出し到着時間、終端、選択オプション
、発生イベントおよび発生時刻等の、呼出し特有の情報を含む呼出し記録の生成
が可能になる。呼出し記録は、正確な送り状と報告書を作成するための請求・報
告システムに対する入力として使用される。３４）聴覚障害者のためのテレタイ
プ能力によって、聴覚障害者が使用するテレタイプ・ターミナルへオペレータ位
置を接続することができる。３５）ファインド・ミー番号リストで指定された番
号に対してＮＧＩＮが連続して電話をかけることが可能なファインド・ミー・サ
ービスによる連続電話。同シナリオでは、現用の番号が無応答の場合にのみ、次
の番号がダイヤルできるようになる。これに加えて、加入者の位置を確認する時
間を短縮するためにＮＧＩＮがファインド・ミー番号リストで指定された全番号
または番号グループに一斉に電話をかけることが可能なファインド・ミー・サー
ビスにおいる同時電話機能が提供されることが望ましい。加入者がそれらの場所
のどこかにいた場合には、加入者は発信当事者と接続されることのなる。３６）
分散型データベース・アクセス。それは、サービス論理が実行するローカル・ノ
ード上にデータがない場合に、サービス論理が、いつでも必要な時に分散型デー
タベース上のデータを引き出し、修正し、削除できるようにするものである。デ
ータが種々の物理ノード中に分割されている場合、アプリケーションに対して位
置の透明性が維持される。複製データ・コピーがネットワーク上に存在する場合
には、ネットワーク上の全コピーに対してリアルタイムで更新データが移植され
る。３７）外部データベース・アクセス。それは、検索と更新のために外部デー
タベースに対するアクセスを可能にするものである。データベースは、首位のカ
スタマーの下や、別ネットワーク内に置くことができる。問い合わせメッセージ
を伝達するために使用されるプロトコルは、システム毎、ネットワーク毎に異な
っている場合があるが、アプリケーションから特定のプロトコルを隠すために１
メカニズムが提供される。３８）回送と配達のためにあらゆる型のメッセージの
記憶が可能な、ネットワーク大のリポジトリ能力を提供する、収集/配信/検索の
ためのメッセージ・リポジトリ。メッセージを記憶するメッセージ形式は、必要
とされる使用者ターミナルの型に基づいて配達されたり検索されたりするので、
別の形式にも転換可能である。期待されるメッセージ形式は、音声、ファックス
、ビデオ、テキスト、またはバイナリー・ファイルである。同能力は、音声/フ
ァックス・メール、Ｅメール・サービス/特徴によって使用されることができる
。メッセージは、宛先、認証要求、タイムスタンプ、形式、長さなどの自己に関
する全情報を備えた自己格納型オブジェクトである。メッセージはネットワーク
を横切って配達されるが、加入者は、どこからでもメッセージにアクセスするこ
とができる。幹線メッセージ配達システムは、リアルタイム・メッセージ配達を
保証するために提供される。３９）会議呼出し関係者のリストである主リストは
、各呼出しに備えて名前と電話番号を集める作業を簡便化するシステム管理によ
ってファイル上に保持されることができる。４０）持続的な指定。すなわち、規
則正しくスケジュールされ繰り返し発生する会議呼出しから、ＮＧＩＮは上記リ
ストを生成し、各呼出しのために新規に指定する必要をなくす。４１）関係者通
知。それは、全関係者にスケジュールされた呼出しの日時を通知することができ
るものである。会議呼出しに先立って、会議開催専門家は、会議関係者の一部ま
たは全部に情報（議事日程、販売額など）をファックスすることができる。４２
）待機中の音楽。それは、会議呼出しの開始前に関係者に音楽を提供することで
ある。４３）翻訳サービス。それは、国際的なアクセス性を提供するために、使
用者に対してオンラインでの言語通訳サービスを可能にするものである。４４）
会議記録。それは、会議呼出しをカセットテープに録音し、書面またはフロッピ
ーディスクに文書化して提供することを可能にするものである。４５）点呼呼出
し。それは、点呼呼出しを実施して、回線上に他に誰がいるか全関係者に分かる
ようにするものである。４６）会議モニタ・サービス。同サービスでは、使用者
リクエストによって、呼出しの間中、モニタと援助のために会議開催専門家が回
線上に待機することが可能である。「０」をダイヤルすることによって、議長に
対し、援助のために、もっとも近い場所にいる会議開催専門家が招聘されること
になる。確認トーンによって、議長は、専門家に対して招聘依頼がなされたこと
が分かる。４７）傾聴専門/同報通信モード・サービスによって全部または一部
の関係者は、他者が話している間、傾聴専門モードに入ることができる。４８）
ＶＩＰ向けの副会議開催サービスによって、選任された関係者は、呼出し中、非
公式に協議した後、主呼出しに復帰することができる。４９）秩序だった質問と
解答、並びに、割込みのないセッションを実施する質問と解答サービス。その間
、聴衆は傾聴専門モードに留まる。関係者に質問がある場合には、タッチトーン
・キーパッド経由で信号を発信して、それから１人ずつ、質問のための対話モー
ドに入ることができる。５０）ポーリング・サービスによって、即時オプション
・ポールの導入、または、関係者にタッチトーン・キーパッド経由で応答を依頼
する調査が可能となる。５１）会議即時再生サービスによって、スケジュールさ
れた指定しに会議が終了した後すぐ、会議呼出しを再生することができる。オプ
ションには、早送り、巻き戻し、および一時停止が含まれる。５２）カスタマー
参照コード・サービスによって、名前、番号、あるいはその両者の組み合わせに
よって記載された会議開催送り状の呼出し状況の識別が可能になる。５３）カス
タマーが各会議用にカスタマイズした挨拶を作ることを可能にする特化挨拶サー
ビス。関係者が会議に参加する際、それらの挨拶が、正しい会議に参加している
ことを保証し、または、会議に関する他の情報を提供する。５４）リアルタイム
の会議開催プロダクトにＮＧＩＮがリアルタイム・アクセスをすることができ、
オーディオ会議をすぐにセットアップすることのできるオン・デマンドの会議。
５５）ＮＧＩＮがサポートするその他の呼出し対話サービスは、以下に含まれる
が、それらに限定されるものではない。距離に基づく登録、地理に基づく登録、
パラメータ変化登録、定期登録、時計に基づく登録、無線およびＰＣＳシステム
の移動性およびハンドオフ能力のサポート、不侵害（ドウ・ノット・ディスター
ブ）性のサポート、高優先使用者に対する多レベル優先権および先買権のサポー
ト、個人向け緊急サービスがより高い優先アクセスを保てるようにする優先アク
セスおよびチャネル割り当てのサポート、音声プライバシーを提供する暗号化処
理のサポート、および、無線およびＰＣＳシステム用のショート・メッセージの
サポート。

【０２３８】 ここで、例示的なサービスの処理および利用シナリオについて、一連の図面、
図１８（ａ）〜図１８（ｉ）および概念的な機能図、図２４を参照しながら説明
する。本発明の好ましい実施形態によれば、図１８（ａ）〜図１８（ｉ）は、サ
ービスを実施する場合、たとえば資源複合体のネットワーク・スイッチで呼が受
け取られる場合に、ＮＧＩＮによって実施される基本的な機能ブロックについて
記述したものである。これらの機能的に構築されたブロックは、実行されるサー
ビスのタイプに関わらず実施可能であるという意味で総称的であって、具体的に
言えば、本明細書では１−８００／８８８フリーダイヤル・コール（「１８Ｃ」
）、１−８００コレクト・コールなどの状況で記述される。この機能的に構築さ
れたブロックが、記述のように様々な修正を加え、多くのイベント・サービス・
シナリオで実施可能であることを理解されよう。

【０２３９】 第１に、図１８（ａ）のステップ１００１に示されるように、受信呼はＮＧＳ
スイッチ・ファブリック１８０に着信する。ＮＧＳ １８０が呼を受け取ると、
ベアラ制御構成要素２１８（図３）は呼制御構成要素に、呼が受け取られたアク
セス回線、ならびにＡＮＩ、ダイヤルされた番号、および呼の処理に必要なその
他のデータを提供する。呼制御ＳＬＰ ５４５は、プログラム済み論理に従って
実行されたときの、呼に関する状態モデルを維持する。さらに状態モデルには、
図２４の方法で記述されるように、ＥＬＰ ５４０をインスタンス化するため、
および機能弁別器サービス（ＦＤ）５１０にサービス要求を送信するためのトリ
ガが含まれる。

【０２４０】 図１８（ａ）は、着信呼に対して機能弁別を実行するためのステップを記述し
たシーケンス図である。ステップ１０１０に示されるように、ＦＤの論理名がＮ
ＧＳ／ＮＮＯＳエージェント・オブジェクトからＮＮＯＳ名前変換（ＮＴ）関数
に送られる。このＩｎｉｔｉａｌ Ａｄｄｒｅｓｓ Ｍｅｓｓａｇｅメッセージ
には、名前と、被呼側８００＃、ＡＮＩ、回線ＩＤ、ネットワーク呼ＩＤ、発信
スイッチ・トランクなどの追加データを備えたデータ（封筒および手紙）の、両
方が含まれることが好ましい。ＥＬＰアドレスもこの情報と共に送信される。ス
テップ１０１２に示されるように、機能弁別器名を決定するために名前変換がＮ
Ｔによって実行される。実際のＳＬＰ名、すなわちＦＤ．ＳＬＰを取得するため
に、この名前がＤＭに送信される。このシナリオでは、各ＳＬＥＥに常時実行中
の機能弁別器（すなわち持続ＳＬＰ）があると想定されている。次いで、ステッ
プ１０１４に示されるように、データ管理がＦＤ ＳＬＰの実際の名前およびそ
の格納位置を名前変換器（ＮＴ）に送信し、次にステップ１０１６で名前変換器
が、その名前をＮＮＯＳ ＬＲＭ関数に送信して、ＦＤ ＳＬＰがインスタンス
化される場所を判定する。ＦＤがインスタンス化されない場合、ＮＮＯＳがこれ
をインスタンス化することを理解されたい。ステップ１０１８に示されるように
、ＬＲＭはＳＬＥＥを取得し、ＳＬＥＥのアドレスをＮＴに返す（ＳＬＥＥアド
レス）。次にステップ１０２０で、ＮＮＯＳ ＮＴが（ＮＧＳから送信された）
メッセージを、着信したすべての呼の発信情報を格納している機能弁別器ＳＬＰ
に送信する。次にステップ１０２５に示されるように、この機能の一部として、
ＦＤ ＳＬＰがＦＤデータベース（「ＤＢ」）ルックアップを実行し、それによ
って論理的意思決定が実行できる。

【０２４１】 次に、ＤＢルックアップを実行するためにＳＬＰによって呼び出されるＳＩＢ
Ｂについて、図１８（ｂ）を鑑みて総称的に説明する。機能弁別状況では、ステ
ップ１０３０に示されるように、ＤＢルックアップには、ＦＤ ＳＬＰに論理Ｆ
Ｄデータベース名をＮＮＯＳ ＮＴに送信させることが含まれるが、どんなＳＬ
Ｐオブジェクト・インスタンスでもデータベース・ルックアップを開始すること
ができる。ステップ１０３２で、ＮＴがＤＭに論理ＤＢ名を照会し、ステップ１
０３３で、ＤＭがデータベース名およびそれが格納されている位置のアドレスを
返す。データベースが遠隔ノードにある場合、ステップ１０３４ａに示されるよ
うに、ＮＮＯＳ ＮＲＳシステムへのノード選択要求が実行されることがある。
その結果、サービス・ノードでのサービスの可用性およびＳＬＥＥの状況に基づ
いて、ＮＲＳはどのノードにデータベースがあるかを判定し、ステップ１０３４
ｂに示されるように、論理名をＮＮＯＳ ＮＴに送る。さらにステップ１０３４
ｃに示されるように、ＮＮＯＳ ＮＴはＤＢアドレスを遠隔ノードのＮＮＯＳ
ＮＴインスタンスに提示する。

【０２４２】 ステップ１０３５に示されるように、ＮＮＯＳ ＮＴは、データベースがロー
カルで使用可能であるかどうか、および使用可能でない場合はどこで使用可能で
あるかを知るために、最終的に位置を選択する前にＬＲＭに照会することができ
る。ＬＲＭは、ステップ１０３６でＤＢのアドレスをＮＴに返し、次いでＮＴは
ステップ１０３７で、データベースの物理アドレスをＳＬＰ、たとえばＦＤ Ｓ
ＬＰに送る。

【０２４３】 あるいは、ステップ１０３４ｄ〜１０３４ｆに破線で示されるように、遠隔ノ
ードのデータベース位置の場合、そのノードにあるＮＴがそのＬＲＭを照会し、
アドレスを遠隔ＮＴに返し、物理アドレスをＳＬＰに返す。ＳＬＰは以前にＮＧ
Ｓ ＮＮＯＳエージェントから受け取ったデータを使用して、データ管理に照会
する。たとえば、機能弁別［図１８（ａ）］の場合、図１８（ｂ）のステップ１
０３８に示されるように、呼を処理するためのＳＬＰを見つけるために照会が実
行される。最終的にデータ応答は、ステップ１０３９に示されるように、発呼側
ＬＰまたはＳＬＰに返される。

【０２４４】 具体的に言えば、１８Ｃのサービス要求状況では、ＦＤ ＳＬＰがその機能弁
別テーブルを使用して、どのＳＬＰが受け取ったサービス要求を処理するのかを
識別する。たとえば、受け取ったメッセージが１８Ｃサービス要求である場合、
１８Ｃ ＳＬＰによって処理される。下記の表３は、様々な「フリーダイヤル」
、たとえば１−８００コール・サービスへのポインタを含む項目を有する、省略
ＦＤテーブルの一例である。 エントリ・ポート・テーブル Ａ００１００１” ＳＬＰポインタ ’Ｖｎｅｔ’ Ａ００１００２” ＦＧＤテーブルへのテーブル・ポインタ ＦＧＤテーブル １８００^* テーブル・ポインタ ８００テーブル １８８８^* テーブル・ポインタ ８００テーブル １９００^* テーブル・ポインタ ９００テーブル １^* ＳＬＰポインタ ’ローカル番号’ ８００テーブル １８００ｃｏｌｌｅｃｔＳＬＰ ’１−８００−ｃ’へのポインタ １８００８８８８０００ＳＬＰ ポインタ ’Ｏｐ サービス’ １８００^* ＳＬＰ ポインタ ’８００サービス’ １８８８^* ＳＬＰ ポインタ ’８００サービス’

【０２４５】 上記でＦＧＤは機能グループ弁別器である。具体的に言えば、ネットワーク内
で呼が発信された場所（スイッチボード）および受け取られた呼のタイプ（たと
えば１−８００）に基づいて、ＦＤは適切なＳＬＰ論理名を決定することになる
。たとえば、識別”００１００２”は、ＦＧＤテーブルでルックアップを必要と
する呼の受け取り（ＦＧＤテーブルへのポインタ）を示す。ＦＧＤテーブルは、
被呼側番号、たとえば８００^*に応じて他のテーブルへのポインタを維持するが
、ここで「^*」は区切り文字である。たとえばこの８００テーブルから、ステッ
プ１０４９に示されるように、ＦＤは要求されたＳＬＰ論理名へのポインタを取
得する。その後、このＳＬＰが呼び出され、サービス要求がＮＮＯＳに渡され、
要求された１８Ｃサービスに従って、ＣＬＰ ５４５、ＬＬＰＯ ５３０、およ
びＳＬＰ ５２０オブジェクトがインスタンス化される。

【０２４６】 好ましい実施形態では、ＮＧＩＮサービス作成構成要素が、ＦＤ ＳＬＰが使
用するデータベースを定義してある。これは、ＮＧＩＮ ＳＡ構成要素によって
、サービス・オーダから設置される。ＦＤ ＤＢ照会の結果、ＤＭは、本明細書
に記載の方法でオブジェクトをインスタンス化するために、少なくとも３つのＳ
ＬＰ名、ＬＬＰ、ＣＬＰ、ＳＬＰを含む照会の結果をＦＤに返信する。次に、ス
テップ１０２８ａ〜１０２８ｃに示されるように、発信回線ＬＰ、すなわちＬＬ
ＰＯ、ＳＬＰ、およびＣＬＰが、図１８（ｃ）に関するような呼サービス・イン
スタンスのために、それぞれ本明細書に記載の方法でインスタンス化される。

【０２４７】 図１８（ｃ）は、受け取ったサービス要求に関するＬＬＰＯをインスタンス化
するための、ステップ１０２８ａを記述したシーケンス図である。具体的に言え
ば、ステップ１０４０に示されるように、ＦＤ ＤＢ照会［１８（ｂ）、ステッ
プ１０３９］の結果を使用してＦＤ ＳＬＰがＬＬＰＯ論理名をＮＴに送信し、
次にステップ１０４１に示されるように、ＮＴがこれをたとえばローカルＤＭキ
ャッシュに含まれているインスタンス・テーブルに照会し、物理位置（オブジェ
クト参照）およびインスタンス化されたかまたは実行に使用可能なＬＬＰＯの実
際の名前を取得する。好ましいことに、呼が受け取られたベアラ制御回線に基づ
いてＬＬＯＰの論理名がＮＮＯＳ ＮＴに提供される。すなわち、この回線の識
別は、ベアラ制御構成要素によって識別されたＡＮＩまたはアクセス回線のいず
れかに基づいている。ＡＮＩは、呼を発信したオリジナルのアクセス回線を識別
するが、これはＮＧＳが呼を受け取ったアクセス回線と同じである場合と同じで
ない場合があり、すなわち受け取られた呼がローカル・ネットワーク上で発信さ
れたものであって、たとえば中継搬送波ネットワーク上にあるスイッチ１８０に
渡された可能性がある。したがって、コール・ウェイティングまたは呼割込みな
どの回線に関連付けられた機能を、ＡＮＩによって識別することができる。ステ
ップ１０４２および１０４３で示されるように、ＮＮＯＳ ＮＴはＬＬＰＯの論
理名をＬＬＰＯインスタンス化用の物理アドレスに変換する。ＬＬＰはその関連
付けられた回線のあるサイトでインスタンス化され、他の論理プログラム（ＳＬ
Ｐなど）は他のサイトでインスタンス化される場合があることを理解されたい。
次いでＮＴはＮＮＯＳ ＬＲＭを照会してＬＬＰＯがどこでインスタンス化され
るかを見つけ出し（ステップ１０４３）、ＬＲＭが、サービス制御サーバまたは
呼制御サーバにある可能性のあるＳＬＥＥアドレスを備えた実際のＬＬＰＯ（Ｓ
ＬＰ）名を返す（ステップ１０４４）。次に、ステップ１０４５に示されるよう
に、発呼者識別データはＮＮＯＳ ＮＴを介してインスタンス化されたＬＬＰＯ
インスタンスに送信され、ステップ１０４７で、ＬＬＰＯがそれ自体をスイッチ
にあるＮＧＳ ＮＮＯＳエージェントに登録する。いったんインスタンス化され
ると、ＬＬＰＯは回線に関連付けられた機能についてデータ管理に照会し（ステ
ップ１０４８）、発信回線の状態を維持して、コール・ウェイティングまたはオ
ーバフロー・ルーティングなどの機能が、発呼者（すなわちコール・ウェイティ
ング）またはネットワーク（すなわちオーバフロー・ルーティング）によって呼
び出されるときに、これらの任意の機能を呼び出す。ローカル・データベース・
アクセス照会は、図１８（ｂ）に記載されたステップに従って実行されるが、回
線情報ＤＢの物理アドレスは、ＬＬＰＯによる受取りに関して顧客発信回線情報
をルックアップするようにＤＭに要求する、ＬＬＰＯに送信される。

【０２４８】 図１８（ｄ）は、（図１８（ａ）のステップ１０２８ｂに示されたように）受
け取られたサービス要求に関するＳＬＰをインスタンス化するためのステップを
記述したシーケンス図である。好ましいことに、複数ＳＬＰへの要求が、要求さ
れた呼サービスに対応するＳＬＰ、ＣＬＰ、およびＬＬＰＯが同時にインスタン
ス化できるような単一の要求で実行されることがある。ＦＤ ＤＢ照会［図１８
（ａ）、ステップ１０２５］の結果を使用して、図１８（ｄ）のステップ１０５
０に示されるように、ＦＤ ＳＬＰがＳＬＰ論理名をＮＴに送信し、次にＮＴが
、たとえば、ステップ１０５１に示されるように実行するＳＬＰの物理位置（オ
ブジェクト参照）に関する名前変換用のローカルＤＭキャッシュについて、その
インスタンス・テーブルに照会する。ＤＭ（ローカル・キャッシュ）は、ステッ
プ１０５２に示されるように、ＳＬＰ（記憶域アドレス）のオブジェクト参照を
返信する。次いでＮＴは、ＳＬＰがローカルにインスタンス化されたかどうかを
見つけ出し、インスタンス化されていない場合は、ステップ１０５３に示される
ように、要求されたサービスのどのインスタンスを使用するかをＮＮＯＳ ＬＲ
Ｍに照会する。これに応答して、ＬＲＭはステップ１０５４で、ＳＬＥＥアドレ
スを備えた実際のＳＬＰ名を返す。ＮＮＯＳはこれに応答して、新しいＳＬＰサ
ービスをインスタンス化するためにサービス制御ＳＬＥＥ上で実行中のサービス
・マネージャ・オブジェクトに要求を送信するか、あるいは、サービス・スレッ
ド・マネージャが、要求されたサービスに呼を表す固有のトラッキング識別子を
持たせる新しいスレッドを割り当てるように要求する。好ましい実施形態では、
ＮＮＯＳは、ＮＧＳからオリジナルの着信サービス要求通知を受け取ったサービ
ス制御サーバからＳＬＰを選択することになるが、ＮＮＯＳは、サービス制御イ
ンスタンスのＮＮＯＳ ＬＲＭおよびＮＲＳリストならびにそれらの現在の状況
を実施することによって、どんなサービス制御構成要素内にあるＳＬＰでも選択
できることを理解されたい。図１８（ｄ）の次のステップでは、インスタンス化
されたＳＬＰプロセスがその物理アドレスをＮＮＯＳに登録し、ＮＮＯＳがこの
ＳＬＰをサービス要求に割り振ることが必要である。次いでステップ１０５５で
、ＮＮＯＳはサービス要求ハンドオフ・メッセージを新しいＳＬＰに渡し、それ
によってＳＬＰは、プログラム済みの論理に従って呼の処理を開始することがで
きる。ＳＬＰのインスタンス化プロセスと並行して、この呼に対して関連付けら
れたＣＬＰ（および任意の他のＳＬＰ）も同様にインスタンス化することが可能
であり、この呼のＥＬＰインスタンスが、呼のコンテキスト・データ・コレクシ
ョンに関して事前にインスタンス化されていることを理解されたい。最終的に、
図１８（ｄ）のステップ１０５７ａに示されるように、ＳＬＰはＣＬＰと通信し
てＳＬＰ、ＬＬＰ、およびＥＬＰのアドレスを提供し、ステップ１０５７ｂで、
ＳＬＰはＥＬＰと通信してＳＬＰ、ＬＬＰ、およびＣＬＰアドレスを提供する。
したがって、ＣＯＲＢＡを実施するＮＮＯＳを介して、ＬＬＰ、ＣＬＰ、ＳＬＰ
の間にインターフェースが確立される。

【０２４９】 ＥＬＰの以前のインスタンス化には、ＮＧＳ呼制御構成要素に、ＥＬＰの論理
名を含むＮＮＯＳへのメッセージを送信させるステップと、これに応答してサー
ビス・マネージャ・オブジェクト（図１０（ａ））にＳＬＥＥ内でＥＬＰをイン
スタンス化させるメッセージをＮＮＯＳに送信させ、そのＥＬＰのオブジェクト
参照を、その呼に関するＥＬＰインスタンスを生成する呼制御に戻させるステッ
プなどが必要である。ＮＧＳ呼制御構成要素には、ＳＬＥＥのＦＤに送信される
サービス要求メッセージ内にあるこのオブジェクト参照が含まれる。したがって
、任意のプロセスによって呼のために生成されたすべての認証済みイベント・デ
ータが、インスタンス化されたＥＬＰプロセスに書き込まれる。

【０２５０】 好ましいことに、ＬＬＰＯが顧客発信回線情報をルックアップするためにＤＭ
を開始する時点で、その呼に対してインスタンス化されたＳＬＰはサービス要求
を処理中である。記述される１８Ｃシナリオでは、１８Ｃ ＳＬＰが、たとえば
１８Ｃサービス・シナリオの状況での論理的終了（ＬＴＥＲＭ）およびスイッチ
／トランクを含むルーティング終了を決定しており、次のステップは、ＮＧＩＮ
内の終了ノード位置を決定し、発信呼の終了回線論理プログラムＬＬＰＴをイン
スタンス化することである。１８Ｃサービス・シナリオに関して、より詳細に説
明するように、［図１８（ｂ）の］ローカル・データベース・アクセス・シーケ
ンスが実施され、所与の最終ルーティング情報に基づいて、終了ＮＧＩＮノード
位置を決定する。終了ノードは、呼が受け取られた場所と同じノードにあるか、
または発信ノード以外の遠隔ノードにあってもよいことを理解されたい。終了ノ
ード位置がいったん受け取られると、終了ＬＬＰがインスタンス化され、同様に
終了回線プロファイル・ルックアップもインスタンス化される。

【０２５１】 図１８（ｅ）は、呼のルーティングの前に、遠隔ＮＧＩＮノードで終了ＬＬＰ
をインスタンス化するためのプロセスを示す図である。ステップ１０７０に示さ
れるように、ＣＬＰが終了ＬＬＰの終了ノード位置および論理名をＮＴに送信し
、それによってインスタンス化されることが必要である（終了ノード位置は、Ｄ
Ｍから返されたルーティング応答の一部である）。次いでＮＴは、ステップ１０
７１でＬＬＰ論理名をＤＭに送信し、ステップ１０７２で、実際のＬＬＰ名と格
納済み位置のアドレス（オブジェクト参照）とを返す。次いでＮＴがステップ１
０７３で、ＮＮＯＳ ＮＲＳ関数に、この呼が終了しているノードが活動中で動
作可能であるかどうかの判定を照会し、ＮＲＳがステップ１０７４で、終了ノー
ドの状況をＮＴに返す。ステップ１０７５では、ローカル・ノードのＮＴがＮＮ
ＯＳを介して、遠隔ノードのＮＮＯＳ ＮＴエージェントに終了ＬＬＰをインス
タンス化するように要求する。ステップ１０７６に示されるように、終了ノード
上にあるＮＴが、ＬＬＰがすでにこの終了回線に対してインスタンス化されてい
るかどうかの判定をＬＲＭに照会し、されていない場合は、ＬＬＰをインスタン
ス化する必要がある。終了ノードにあるＬＲＭは、ステップ１０７７で、終了回
線用のＬＬＰが実行中のＳＬＥＥアドレスをＮＴに返す。次いでステップ１０７
８で、終了ノードのＮＴが呼データを終了回線のＬＬＰに送信し、さらにステッ
プ１０７９に示されるように、終了回線用のＬＬＰを実行中であるＳＬＥＥのア
ドレスを、発信ノードのＮＴに送信する。ステップ１０８０で、発信ノードのＮ
Ｔが、終了回線用のＬＬＰを実行中であるＳＬＥＥアドレスをＣＬＰに送信し、
ステップ１０８１に示されるように、終了回線上の機能（あれば）を判定するた
めにローカル・データベース・ルックアップが実行される。具体的に言えば、終
了ＬＬＰが回線情報データベースの論理データベース名を、名前変換のためにＮ
Ｔに送信する。ＮＴは、ＤＭから実際の回線情報データベース名を要求し、この
実際の回線情報ＤＢ名およびその格納済み位置をＮＴに送信する。ＮＴは回線情
報ＤＢがローカルで使用可能であるかどうかを知るためにＬＲＭに照会し、ＬＲ
Ｍは物理ＤＢアドレスをＮＴに返信する。ＮＴは回線情報ＤＢの物理アドレスを
終了ＬＬＰに渡す。次いで終了ＬＬＰは、顧客終了回線情報をルックアップする
ための要求をＤＭに送信し、ＤＭは顧客回線情報をＬＬＰＴに返す。これでシス
テムは、以下で述べるような呼のルーティングを実行する準備が整ったことにな
る。

【０２５２】 図１８（ｆ）は、特定サービス、たとえば呼のルーティングが実行された後に
、呼の完了を実行するための手順を示すシーケンス図である。図１８（ｆ）のス
テップ１０８４に示されるように、ＬＬＰＯはＮＧＳ ＮＮＯＳエージェントか
ら呼完了通知を受け取り、ステップ１０８５で、ＬＬＰが呼完了通知をＣＬＰに
転送する。ステップ１０８６ａおよび１０８６ｂでは、ＣＬＰが呼完了通知をす
べての関連するＬＰＳ（たとえばＬＬＰＴ、ＥＬＰ）に転送し、ＣＬＰが終了す
る。最終的に、ＣＬＰから呼の完了が通知されると、ステップ１０８８で、ＥＬ
Ｐが呼の情報をＤＭに書き込む。

【０２５３】 次に、１−８００コール・サービス（１８Ｃ）のシナリオ例について、図１９
（ａ）に関して詳細に説明する。ＮＧＩＮによって実行される１８Ｃサービスは
、呼を正しい終了まで延長する前に、たとえば曜日およびパーセント（％）割振
りに基づいて、番号８００を変換可能にするものである。具体的に言えば、ステ
ップ７０２で示されるように、ＮＧＩＮはスイッチでインテリジェント要求を受
け取り、図１８（ａ）に関して述べたように機能弁別が実行され、図１８（ｃ）
および１８（ｄ）に関して述べたようにＳＬＰ、ＣＬＰ、およびＬＬＰのインス
タンス化が実行される。次いでステップ７０４で、ＬＬＰＯが発信回線に関連付
けられたコール・ウェイティング機能を決定した場合、ステップ７０６に示され
るように、ＬＬＰＯは、着信呼が検出されたかどうかをＬＬＰＯに知らせるため
の通知をＮＧＳ ＮＮＯＳエージェントに送信する。この通知は、たとえば発信
回線がアウトダイヤルを試行中である間は、着信呼を受け取っても話中信号を出
さないようにＮＧＳに知らせるものである。次に、ステップ７０７で、インスタ
ンス化された１８Ｃ ＳＬＰが、曜日およびパーセント（％）割振りに基づいて
顧客プロファイルを決定するために、データベースの照会を実行する。これには
、８００コール・ルーティング・データベースの論理名について、ＤＭキャッシ
ュに照会する必要があり、いったんデータベースが見つかると、たとえば、被呼
側番号８００、回線識別、発信スイッチ・トランク、およびＡＮＩに基づいて、
正しいルーティング終了のために顧客ルックアップを実行する。ＤＭは顧客プロ
ファイルを１８Ｃ ＳＬＰに返す。次いで、ステップ７０８に示されるように、
１８Ｃ ＳＬＰは、顧客プロファイルに従って日およびパーセント（％）割振り
を送信することによって、ＤＭに関する照会を構築する。次いでＤＭは、ＬＴＥ
ＲＭおよびスイッチ／トランクを含む最終的なルーティング情報を返す。

【０２５４】 次に、ステップ７０９に示されるように、ルーティング応答に指定された終了
に関する終了ノード位置を決定するために、データベース照会が実行される。Ｄ
Ｍが終了位置をＳＬＰに返した後、任意の呼コンテキスト・データが最終的にＤ
Ｍに格納するためにＥＬＰに書き込まれる。

【０２５５】 次に、ステップ７１０［図１９（ｂ）］で、１８Ｃ ＳＬＰがハンドオフ・コ
マンドでアウトダイヤル要求をルーティング情報と共にＣＬＰに送信し、１８Ｃ
ＳＬＰが終了する。ステップ７１２［図１９（ｂ）］で、終了ノードにある終
了ＬＬＰＴが図１８（ｅ）に関して記述した方法でインスタンス化される。次い
で、ステップ７１４に示されたように、ＣＬＰがハンドオフ・コマンドでアウト
ダイヤルをＬＬＰＯに送信し、これがＮＧＳ ＮＮＯＳエージェントに転送され
る。ＮＧＳが呼を終了ノードにルーティングし、ＥＬＰがアウトダイヤル・デー
タをＤＭに書き込む。最終的に、図１８（ｆ）に関して記述したように、呼の完
了がステップ７１６［図１９（ｂ）］で示されるように実行される。

【０２５６】 さらに高度な１８Ｃサービスの場合、１８Ｃ ＳＬＰには、発信回線上にコー
ル・ウェイティング機能を有する呼を処理するための機能が含まれる。例示的サ
ービス・シナリオでは、他の呼が受け取られたことを示す番号８００変換プロセ
ス中に、発信回線上で割込みが受け取られる。この着信呼は発呼者によって受け
入れられ、保留中のアウトダイヤルが続行される。さらに、発呼者は元の番号８
００アウトダイヤルに切り換え、その呼を完了する。

【０２５７】 図１９（ｃ）は、この進歩した１８Ｃサービスのシナリオを例示している。特
にＬＬＰＯは、通知をＮＧＳ ＮＮＯＳエージェントに伝達し、呼の中断が、図
１９（ａ）に関して、ステップ７０４で示しているようにいつから受信されてい
るかを通知した後、ＬＬＰＯが呼待機モードに入る。

【０２５８】 図１９（ｃ）のステップ７２０、７２１で示しているように、ＬＬＰＯは、発
信回線に新規の着信呼が受信されたことを知らせる呼待機の中断に応答して、Ｎ
ＧＳ ＮＮＯＳエージェントからの予想される着信呼の通知を待機する。呼が受
信されたとステップ７２０で判定されたとき、ＬＬＰＯは、ステップ７２２で示
しているようにＮＧＳ ＮＮＯＳエージェントに呼待機音を再生し、発信回線の
応答をリスンする。ステップ７２３、７２４で、ＮＧＳ ＮＮＯＳエージェント
は、応答をリスンし発呼者の応答をＬＬＰＯに転送する。ステップ７２３で発呼
者の応答が受信されるとき、以下の事柄がステップ７２５で実行される。１）Ｎ
ＧＳ ＮＮＯＳエージェントはその応答をＬＬＰＯに中継する。２）ＬＬＰＯは
、発呼者が着信呼を受領したことを示す呼受領通知をＮＧＳ ＮＮＯＳエージェ
ントに送る。３）ＮＧＳは発呼者と発呼側を結ぶ。このシナリオでは、着信呼は
、ＣＬＰ、ＬＬＰ、ＥＬＰをインスタン化プロセスを通してすでに確立している
ことが前提となっている。したがって、ステップ７２６で示しているように、Ｌ
ＬＰは、さらにＮＧＳ ＮＮＯＳエージェントに発信回線の他の応答をリスンす
るように命令し、ステップ７２８および７２９で、そのプロセスは、第２の呼が
終了したことを示す発呼者の応答の受信を待機する。

【０２５９】 その間、つまり図１９（ａ）および１９（ｂ）で述べているように、進歩した
１８Ｃ ＳＬＰは、処理をルーティング情報が与えられている終端ノードの場所
（例えば、発呼ノード上ではない）を判定することで続行し、ハンドオフ・コマ
ンドを伴ったアウトダイヤル要求をＣＬＰに送り、それには、ルーティング情報
が含まれている。この時点で、進歩した１８Ｃ ＳＬＰインスタンスは終了する
。さらに、述べたようなやり方で、（終端回線と関連付けられた）ＬＬＰＴがイ
ンスタンス化され、ＣＬＰはアウトダイヤル・コマンドをＮＧＳに送り、その呼
がインスタンス化されたＬＬＰＴへルーティングされ、アウトダイヤル情報がＥ
ＬＰに書き込まれる。

【０２６０】 図１９（ｃ）に戻ると、発呼者の応答は、ステップ７２８で示しているように
発信回線で受信されていると仮定すると、元のアウトダイヤルにスイッチバック
することが必要とされる。すなわちステップ７３０で、ＮＧＳ ＮＮＯＳエージ
ェントは、その応答をＬＬＰＯに中継する。ＬＬＰＯは応答を解釈し、現在の呼
から開始時の元のアウトダイヤルへスイッチされる。ＬＬＰは、応答コマンドと
してＳｗｉｔｃｈ Ｃａｌｌ／Ｌｉｓｔｅｎ（呼のスイッチ／リスン）をＮＧＳ
ＮＮＯＳエージェントに送出し、元のアウトダイヤルへのスイッチバックが、
ステップ７３１で実行される。発信回線のＬＬＰは、呼を待機する呼が完了した
ことを示す呼完了通知を第２の呼のＣＬＰから受信するとする。最終的に、呼の
完了が実行される［図１８（ｆ）］。呼待機の中断について本明細書で述べてい
るプロセスは、呼待機の中断が発信回線で受信される時ならいつでも適用可能で
あることを理解すべきである。さらに、類似した原則は、終端回線で適用される
呼待機のシナリオにも適用される。

【０２６１】 進歩した１８Ｃのシナリオを構築する場合、呼をその終端に伝達する前に、他
のＳＬＰを、最初の発呼者へのメッセージの再生のために実行することができる
。図２０（ａ）は、カストマイズド・メッセージ・アナウンスおよび呼延長機能
を実装する、この進歩した１８Ｃサービスのシナリオを例示している。最初に、
１９（ａ）で述べた進歩した１８Ｃ ＳＬＰが、８００番の変換のためにインス
タンス化される。詳細には、ステップ７３２で示しているように、このことには
、スイッチでインテリジェント要求を受信すること、機能分別を行うこと、進歩
した１８Ｃ、ＳＬＰ、ＬＬＰ（およびＣＬＰ）オブジェクトのインスタンス化を
実行することが含まれる。インスタンス化した進歩した１８Ｃ ＳＬＰが、発信
回線と関連付けられた機能が何もないと判定したとすると、次いで、ルックアッ
プが正確なルーティングを決定するために実行される。このルーティング照会の
一部として、スイッチ７３３で示しているように、顧客プロフィールのルックア
ップが最初に行われ、次にステップ７３４で示しているように、日およびパーセ
ントの割当て照会が行われる。日およびパーセントの割当て照会の結果、ＤＭは
、呼の延長のためのルーティング命令、および進歩した１８Ｃ ＳＬＰへの残り
の呼を処理するための新しいＣｕｓｔｏｍｉｚｅｄ Ｍｅｓｓａｇｅ Ａｎｎｏ
ｕｎｃｅｍｅｎｔ ＳＬＰ（カストマイズド・メッセージ・アナウンス）（「Ｃ
ＭＡ ＳＬＰ」）名前を戻す。次いで、ステップ７３５で示しているように、終
端ノードの場所が判定され、あらゆる呼のコンテキスト・データを、この時点で
ＥＬＰに書く込むことができ、呼のコンテキストＤＭに実装される。

【０２６２】 次いで、ステップ７３６で示しているように、新しいＣｕｓｔｏｍｉｚｅｄ
Ｍｅｓｓａｇｅ Ａｎｎｏｕｎｃｅｍｅｎｔ ＳＬＰ（「ＣＭＡ ＳＬＰ」）が
インスタンス化される。このＣＭＡ ＳＬＰは、ＳＩＢＢを呼び出し、音声ファ
イルの再生および呼の延長を監督する。ＣＭＡ＿ＳＬＰのインスタンス化の結果
として、ＮＮＯＳ ＮＴは、呼識別データおよびＳＬＰアドレス・リスト（ＥＬ
Ｐ、ＣＬＰ、およびＬＬＰ）を新しいＣＭＡ ＳＬＰに送る。ついて、進歩した
１８Ｃは、この呼を終了し、ＣＭＡ ＳＬＰへハンドオフする。

【０２６３】 図２０（ｂ）は、ＣＭＡ ＳＬＰによって実装される方法を例示している。ス
テップ７４０で示しているように、ＣＭＡ＿ＳＬＰは、ＳＩＢＢを呼び出し、特
定の顧客音声ファイルを検索するためのＤＭデータベース照会を実行し、図１８
（ｇ）で述べたように発信回線でメッセージの再生を行う。

【０２６４】 次に、ステップ７４２で示しているように、ＣＭＡ ＳＬＰはＳＩＢＢを呼び
出し、より詳細には、図１８（ｈ）で述べているように、ＮＧＳに発呼者へのメ
ッセージ（検索された音声ファイル）を再生するように命令する。最終的には、
図２０（ｂ）のステップ７４４で示しているように、ＣＭＡ ＳＬＰは、アウト
ダイヤル・コマンドをＣＬＰに送り、それには、進歩した１８Ｃ ＳＬＰのルー
ティング応答で受信したルーティング命令も添付されている。

【０２６５】 最終的に、この例のシナリオでは、終端ＬＬＰが、ステップ７４５で示してい
るように、インスタンス化され、プロフィールのルックアップが実行され、終端
回線で使用可能な機能が判定され、アウトダイヤル・コマンドが、ステップ７４
６で示しているように完了し、アウトダイヤル・データが、ＥＬＰに書き戻され
る。最終的に、ステップ７４８で、その呼の完了が実行される。

【０２６６】 図１８（ｇ）は、リソース複合体を通しての再生のために、ＤＭから音声ファ
イルを検索するためのＳＩＢＢプロセスを例示する順序流れ図である。詳細には
、図１８（ｇ）による以下のステップを実装している。１）ＣＭＡ ＳＬＰが論
理名または音声ファイルをＮＴに名前の変換のために送る（ステップ７７０）。
このシナリオでは、総称の音声ファイル・メッセージを検索でき、しかし、顧客
プロフィール情報を利用して、１人の顧客専用の唯一の音声ファイル・メッセー
ジを検索することもできることが前提である。２）ＮＮＯＳ ＮＴは、実際の名
前のためのＤＭおよび音声ファイルの場所を照会する（ステップ７７２）。３）
ＤＭは、音声ファイル名、および格納されている場所のアドレスをＮＴに戻す（
ステップ７７４）。４）ＮＴは、ＬＲＭおよび／またはＮＲＳを音声ファイルを
含むデータベースの可用性のために照会し（ステップ７７６）、ＬＲＭは、音声
ファイルを含むアドレスの場所をＮＴに戻す（ステップ７７８）。最終的に、音
声ファイルの物理アドレスが、ステップ７７９で示しているように、ＮＴからＣ
ＭＡ ＳＬＰへ戻される。

【０２６７】 図１８（ｈ）は、発呼者へのメッセージの再生を開始するためのＳＩＢＢプロ
セスを例示する順序流れ図である。一例示のシナリオでは、ＳＩＢＢは以下のス
テップを実行する。１）Ｐｌａｙ Ｍｅｓｓａｇｅ（メッセージの再生）要求を
ＳＬＰからＣＬＰへ伝達し（ステップ７８０）、その要求を発信ＬＬＰＯに中継
する（ステップ７８１）。その要求で、回線識別表示、音声ファイル・アドレス
、および呼識別データが送られることを理解すべきである。複数のコマンドを、
１つのものとして連結および中継し、送れるようにすることが好ましい。２）Ｌ
ＬＰＯは、Ｐｌａｙ ＭｅｓｓａｇｅコマンドをＮＧＳ ＮＮＯＳエージェント
に中継する（ステップ７８２）。ＮＧＳは、適切なリソース、例えば、スイッチ
・ポートにはＩＶＲ機能があり、ＶＲＵポートにはなどと割り当て、Ｐｌａｙ
Ｍｅｓｓａｇｅコマンドを実行する。３）ＮＧＳ ＮＮＯＳエージェントは、Ｐ
ｌａｙ Ｍｓｇ Ｃｏｍｐｌｅｔｅ（再生メッセージ完了）コマンドをＬＬＰに
伝達し、それは後に、ＳＬＰへ中継されることになる（ステップ７８５）。４）
Ｐｌａｙ Ｍｓｇ Ｃｏｍｐｌｅｔｅの通知は、ＬＬＰからＣＬＰへ中継される
（ステップ７８６）。５）次いで、Ｐｌａｙ Ｍｓｇ Ｃｏｍｐｌｅｔｅの通知
は、ＣＬＰからＳＬＰへ中継される（ステップ７８８）。

【０２６８】 次に、コレクト・コール・オプションのある１−８００コレクト・コール（「
１８ＣＣ」）サービスを図２１（ａ）で、より詳細に述べることにする。この１
８ＣＣのシナリオは、コレクト・コールなどのオプションおよびコーリング・カ
ード・オプションのある１−８００コレクト・サービスを提供するための機能に
ついて述べる。この機能性を提供するために、このシナリオは、１８ＣＣ ＳＬ
Ｐを実装し、これはＬＩＤＢ Ｌｏｏｋｕｐ ＳＬＰまたはＳＩＢＢ（「ＬＩＤ
Ｂ＿ＳＬＰ」）をインスタンス化して、被呼回線が料金の請求が可能であること
を確認し、さらに有効な直接ダイヤルでの数字ＳＬＰまたはＳＩＢＢ（「ＤＤＤ
＿ＳＬＰ」）を実装し、発呼者によって入力されたＤＤＤが有効であることを確
認する。このシナリオで使用されるデータベースおよび音声ファイルはすべて、
ＮＧＩＮサービス創造環境（Ｓｅｒｖｉｃｅ Ｃｒｅａｔｉｏｎ Ｅｎｖｉｒｏ
ｎｍｅｎｔ）を使用して構築されることを前提としている。

【０２６９】 初めに、図２１（ａ）のステップ７４０で示しているように、ＮＧＩＮは、ス
イッチでインテリジェント要求を受信し、機能分別を行い、１８ＣＣ、ＳＬＰ、
ＬＬＰ（およびＣＬＰ）のインスタンス化を実行する。いずれの機能も発信回線
と関連付けらていないとすると、次いで、ステップ７５２で示しているように、
１８ＣＣ ＳＬＰは、サービス用の音声ファイルを検索する。次いで、ステップ
７５４で、１８ＣＣ ＳＬＰは、ＮＧＳに発信回線でのメッセージの再生および
数字の収集を指令し、これは先程の図１８（ｉ）で述べた通りである。

【０２７０】 図１８（ｉ）は、発信回線でメッセージの再生および数字の収集を行うための
ＳＩＢＢを実装する手順を例示する順序流れ図である。図１８（ｉ）のステップ
７９０で示しているように、１８ＣＣ ＳＬＰは、Ｐｌａｙ Ｍｅｓｓａｇｅ要
求をＣＬＰに送り、それはＬＬＰおよびＮＧＳ ＮＮＯＳエージェントに中継さ
れる。この要求で、回線識別表示、音声ファイル・アドレス、および呼識別が送
られる。送られるコマンドには、Ｐｌａｙ Ｔｏｎｅ（音声の再生）、Ｐｌａｙ
Ｇｒｅｅｔｉｎｇ ｗ／ｃｕｔｔｈｒｕ（短縮した挨拶の再生）、Ｃｏｌｌｅ
ｃｔ Ｄｕａｌ Ｔｏｎｅ Ｍｕｔｉ−Ｆｒｅｑｕｅｎｃｙ（「ＤＴＭＦ］）ｗ
／ａ ｔｉｍｅｏｕｔ（タイムアウトのあるＤＴＭＦの収集）を含めることがで
きる。これらのコマンドはＮＮＯＳによって単一のメッセージに連結され、中継
することができるを理解されたい。次いで、ステップ７９１で示しているように
、ＣＬＰは、１８ＣＣ ＳＬＰ要求を発信ＬＬＰに中継し、ステップ７９３で示
しているように、ＬＬＰＯは、Ｐｌａｙ ＭｓｇコマンドおよびＣｏｌｌｅｃｔ
Ｄｉｇｉｔｓ（数字の収集）コマンドをＮＧＳ ＮＮＯＳエージェントに中継
する。次いで、ＮＧＳは、適切なリソースを割り当て、コマンドを受信した順序
で実行する。すなわち、ステップ７９４で、ＮＧＳ ＮＮＯＳエージェントは、
収集されたＤＴＭＦの数字を、ＬＬＰへ送り、それは後に１８ＣＣ ＳＬＰへ中
継されることになり、ステップ７９６で、ＬＬＰＯは、ＤＴＭＦの数字をＣＬＰ
へ中継する。最終的に、ステップ７９８で、収集されたはＤＴＭＦの数字が、Ｃ
ＬＰから１８ＣＣ ＳＬＰへ中継され、そこでＤＴＭＦの数字は被呼側のＤＤＤ
を表現している。

【０２７１】 図２１（ａ）に戻ると、ＤＴＭＦを受信した後、次のステップは、入力したＤ
ＤＤの有効性確認を行うことで、そのためには、有効なＤＤＤ＿ＳＬＰを、本明
細書の図１８（ｄ）で述べたようなやり方でインスタンス化することが必要とさ
れ、詳細には、１８ＣＣ ＳＬＰまたはＳＩＢＢは、有効なＤＤＤ ＳＬＰを表
す論理名をＮＮＯＳ ＮＴに名前の変換のために送るということである。次いで
、ＮＴは、論理的に有効なＤＤＤ ＳＬＰ名をＤＭに送り、ＤＭは、有効な実際
のＤＤＤ ＳＬＰ名とオブジェクト参照（格納場所）を戻す。次いでＮＴは、Ｌ
ＲＮに照会し、有効なＤＤＤ ＳＬＰがすでにこのノードではインスタンス化さ
れているかどうかを確認する。そのようにされていない場合、ＳＬＰをインスタ
ンス化する。ＬＲＭは、ＳＬＥＥのアドレスを戻し、ＳＬＥＥでは、有効なＤＤ
Ｄ ＳＬＰがＮＴへインスタンス化され、ＮＴは、インスタンス化された有効な
ＤＤＤ ＳＬＰの物理アドレスを１８ＣＣ ＳＬＰに送る。

【０２７２】 図２１（ａ）に戻ると、ステップ７５６で、１８ＣＣ ＳＬＰは、照会を有効
なＤＤＤ ＳＬＰに中継し、ＤＤＤは、長さ、ＮＰＡ、およびＮＸＸに従って検
査される。有効なＤＤＤ ＳＬＰは、照会を実行し、その結果は１８ＣＣ ＳＬ
Ｐに戻される。説明のために、戻される照会結果は、有効なＤＤＤを示すものと
する。

【０２７３】 入力されたＤＤＤの検査の後、次のステップは、図２１（ａ）のステップ７５
７で示しているように、ＬＩＤＢ ＤＢ Ｌｏｏｋｕｐを、入力したＤＤＤで実
行し、その回線が料金の請求が可能であることを決定することである。このよう
にして、図１８（ｂ）に従って、ＬＩＤＢ Ｌｏｏｋｕｐをインスタンス化する
ための以下のステップが実行される。最初、１８ＣＣ ＳＬＰは、論理ＬＩＤＢ
ＳＬＰをＮＴに名前の変換のために送り、ＮＴは、すでにインスタンス化され
ている場合、ＬＩＤＢ ＳＬＰの物理アドレスを戻し、またはインスタンス化さ
れていない場合は、ＮＮＯＳ ＬＲＭおよびＮＲＳ機能を実装して、ＬＩＤＢ
ＳＬＰを動作させることができる最善のノードを、例えば場所およびノードの状
況に基づいて判定する。ＮＲＳが選択されたノードをＮＮＯＳ ＮＴに戻した後
、ローカル・ノードのＮＴは、リモート・ノードのＮＴに、ＬＩＤＢ ＳＬＰの
インスタンス化を要求する。したがって、リモート・ノードのＮＴは、ＬＲＮに
照会して、ＬＩＤＢ ＳＬＰがすでにこのノードでインスタンス化されているか
どうかを判定する。そうされていない場合、ＳＬＰをインスタンス化する。リモ
ート・ノードのＬＲＮは、照会データをＬＩＤＢ ＳＬＰに中継し、それには、
１８ＣＣ ＳＬＰの戻りアドレスが含まれている。ＬＩＤＢ ＳＬＰは、照会デ
ータを適切なフォーマットにフォーマットし、その照会をＬＩＤＢデータベース
へのゲートウェイに中継する。ＬＩＤＢ照会が実行され、その結果は１８ＣＣ
ＳＬＰに戻される。

【０２７４】 次いで、ステップ７５８で示しているように、以下のステップが実行され、Ｎ
ＧＳにネーム・プロンプト・メッセージを再生し、発呼者の名前を録音するよう
に指令される。詳細には、１８ＣＣ ＳＬＰは、Ｐｌａｙ Ｍｅｓｓａｇｅ要求
ＳＩＢＢを実装し、その要求は、回線識別表示、音声ファイル・アドレス、およ
び発呼者識別データを中継し、ＮＧＳに、発信回線で、Ｐｌａｙ Ｎａｍｅ Ｐ
ｒｏｍｐｔ（ネーム・プロンプトの再生）およびＲｅｃｏｒｄ Ｎａｍｅ（名前
の録音）を指令するための機能性を実装している。これらのＮＧＳコマンドは、
連結され１つのメッセージとして転送することができる。ＣＬＰは、１８ＣＣ
ＳＬＰ要求を発信ＬＬＰＯに中継し、次いで発信ＬＬＰＯは、それぞれのＰｌａ
ｙ ＭｅｓｓａｇｅコマンドおよびＲｅｃｏｒｄ ｍｅｓｓａｇｅコマンドをＮ
ＧＳ ＮＮＯＳエージェントに中継する。ＮＧＳは、適切なリソースを割り当て
、コマンドを受信した順序で実行する。

【０２７５】 次いで、ＮＧＳ ＮＮＯＳエージェントは、コマンド完了通知をＬＬＰＯに送
り、それは後に１８ＣＣ ＳＬＰへ中継されることになる。最終的に、コマンド
完了通知は、ＬＬＰからＣＬＰへ中継され、次いでそれは１８ＣＣ ＳＬＰに中
継される。

【０２７６】 次に、図２１（ｂ）のステップ７６０で、終端ノードの場所のルックアップが
実行され、ステップ７６２で、ＳＩＢＢが呼び出され、コマンドがＮＧＳに伝達
され、呼の保留、およびアウトダイヤルの実行が行われる。詳細には、以下のス
テップが実装される。１）１８ＣＣ ＳＬＰがＰｌａｃｅ Ｃａｌｌｅｒ ｏｎ
Ｈｏｌｄ（呼の保留）コマンドをＣＬＰに中継し、それはＮＧＳ ＮＮＯＳエ
ージェントに中継されることになる。保留状態に置かれる回線の識別子がコマン
ドに加えられる。２）ＣＬＰは、コマンドを発信ＬＬＰに中継する。３）発信Ｌ
ＬＰは、Ｐｌａｃｅ Ｃａｌｌｅｒ ｏｎ ＨｏｌｄコマンドをＮＧＳ ＮＮＯ
Ｓエージェントに中継し、ＮＧＳは、呼を保留状態にする。４）次いで、ＮＧＳ
ＮＮＯＳエージェントは、コマンド完了通知をＬＬＰＯに送り、それは後に１
８ＣＣ ＳＬＰへ中継されることになる。５）コマンド完了通知がＬＬＰＯから
ＣＬＰへ中継され、次いで、通知は１８ＣＣ ＳＬＰへ中継され、その通知は、
発呼者の呼が保留状態であることを示すものである。６）１８ＣＣ ＳＬＰは、
終端ノードの場所を含むＯｕｔｄｉａｌ ｗ／ Ａｎｓｗｅｒ Ｎｏｔｉｆｉｃ
ａｔｉｏｎ（応答通知のあるアウトダイヤル）コマンドをＣＬＰに中継し、それ
は、ＮＧＳ ＮＮＯＳエージェントに中継される。

【０２７７】 次のステップ７６４は、終端ノードの終端回線（ＬＬＰＴ）のためのＬＬＰを
インスタンス化し、その回線に関連付けれたプロフィールのルックアップを実行
し、顧客回線情報をＬＬＰに戻す。次いで、ステップ７６５で示しているように
、アウトダイヤルを実行し、応答通知の受信が実行される。詳細には、これらの
ステップは、１）ＣＬＰがアウトダイヤル・コマンドを発信ＬＬＰＯに中継する
ステップと、２）発信ＬＬＰＯは、ｏｕｔｄｉａｌ ｗ／ Ａｎｓｗｅｒ Ｎｏ
ｔｉｆｉｃａｔｉｏｎコマンドをＮＧＳ ＮＮＯＳエージェントに中継するステ
ップと、３）ＮＧＳがアウトダイヤルを行うステップと、４）ＥＬＰが、アウト
ダイヤル・データをデータ・マネージメントに書き込み、そしてフォーマットお
よび中継されるステップと、５）ＮＧＳ ＮＮＯＳエージェントが、応答通知を
発信回線のＬＬＰＯに送るステップと、６）ＬＬＰは、応答通知をＣＬＰに中継
し、次いで、その応答通知が１８ＣＣ ＳＬＰへ中継されるステップと、７）１
８ＣＣ ＳＬＰは、応答通知が、だれかがその電話に応答したことを表示してい
るか、あるいは、応答マシンまたは他のデバイスが応答したことを表示している
かを判定するステップとを含んでいる。

【０２７８】 次に、ステップ７６６で示しているように、コマンドによって、ＮＧＳは、終
端回線でさらに、料金の支払い受け入れに対する被呼側の応答を表すメッセージ
の再生、および発呼者からのＤＴＭＦ／音声の収集を開始する。このシナリオで
は、被呼側は料金を承諾したことを前提としている。そのステップに含まれるも
のは、１）１８ＣＣ ＳＬＰが「Ｐｌａｙ Ｍｅｓｓａｇｅ」要求をＣＬＰに送
り、それがＬＬＰＴおよびＮＧＳ ＮＮＯＳエージェントへ中継されるステップ
である。この要求で、回線識別表示、音声ファイル・アドレス、および呼識別デ
ータが送られる。送られるコマンドは、Ｐｌａｙ Ｃｏｌｌｅｃｔ Ｃａｌｌ
Ｍｅｓｓａｇｅ（コレクト・コール・メッセージの再生）、Ｐｌａｙｂａｃｋ
Ｒｅｃｏｒｄｅｄ Ｎａｍｅ（録音済みの名前の再生）、Ｐｌａｙ Ａｃｃｅｐ
ｔ Ｃｈａｒｇｅｓ Ｍｅｓｓａｇｅ（料金承諾メッセージの再生）、およびＲ
ｅｃｏｇｎｉｚｅ Ｖｏｉｃｅ／Ｃｏｌｌｅｃｔ ＤＴＭＦ ｗ／ａ ｔｉｍｅ
ｏｕｔ（タイムアウトのある音声の認識／ＤＴＭＦの収集）を含めることができ
、連結され１つのメッセージとして中継することができる。２）ＣＬＰが１８Ｃ
Ｃ ＳＬＰ要求を終端ＬＬＰに中継するステップである。３）ＬＬＰがＰｌａｙ
ＭｓｇコマンドをＮＧＳ ＮＮＯＳエージェントに中継し、それに応答して、
ＮＧＳが適切なリソースを割り当て、コマンドを受信した順序で実行するステッ
プである。４）ＮＧＳ ＮＮＯＳエージェントが収集されたＤＴＭＦの数字／認
識された音声をＬＬＰに送り、それは後に、１８Ｃ ＳＬＰへ中継されることに
なるステップである。５）収集されたＤＴＭＦの数字／音声はＬＬＰからＣＬＰ
へ中継され、次いでそれは１８ＣＣ ＳＬＰへ中継されるステップである。

【０２７９】 次に、図２１（ｂ）のステップ７６８で示しているように、ＮＧＳは、命令を
受け、発呼者の保留状態を解除し、発呼者と被呼側を結ぶ。これらのステップは
、１）発呼者の保留状態を解除するコマンドを、ＣＬＰに送り、それは後にＮＧ
Ｓ ＮＮＯＳエージェントへ中継されるステップと、２）その要求を発信回線の
ＬＬＰＯに中継するステップと、３）そのコマンドをＮＧＳ ＮＮＯＳエージェ
ントに中継するステップであって、そのコマンドで、結ぶべき回線が識別される
ステップと、４）ＮＧＳ ＮＮＯＳエージェントがコマンド完了通知をＬＬＰに
送り、それは後に、１８ＣＣ ＳＬＰ中継されるステップと、５）コマンド完了
通知が、ＬＬＰからＣＬＰへ中継され、次いでそれは１８ＣＣ ＳＬＰに中継さ
れ、その通知は、発呼者と被呼側が結ばれたことを示すステップとを含んでいる
。最終的に、ステップ７６９で示しているように、呼完了プロセスが実行される
。

【０２８０】 次に、コーリング・カード・オプションのある１−８００コレクト・コール（
１８ＣＣ）のシナリオを、より詳細に図２２（ａ）で述べる。この１８ＣＣのシ
ナリオは、コーリング・カード・オプションのある１−８００コレクト・サービ
スを提供するための能力について述べるものである。このシナリオでは、１８Ｃ
Ｃ ＳＬＰがインスタンス化され、サービスが提供される。このＳＬＰは、有効
なＤＤＤ ＳＬＰを呼び出し、発呼者によって入力されたＤＤＤが有効であるこ
とを確認する。

【０２８１】 初めに、図２２（ａ）のステップ８０２で示しているように、ＮＧＩＮは、ス
イッチでインテリジェント要求を受信し、機能分別を行い、１８ＣＣ、ＳＬＰ、
ＬＬＰ（およびＣＬＰ）のインスタンス化が実行され、それぞれのインターフェ
ースが確立される。この１８ＣＣのシナリオでは、インスタンス化された１８Ｃ
Ｃ ＳＬＰは、ＤＭデータベース照会を行い、発信回線と関連付けられた機能を
判定する。説明のために、いずれの機能も発信回線と関連付けらていないとする
。次いで、ステップ８０４で示しているように、１８ＣＣ ＳＬＰは、サービス
用の音声ファイルを検索する。次いでステップ８０６で、１８ＣＣ ＳＬＰは、
ＮＧＳに、発信回線でのメッセージの再生および数字の収集を指令する。図１８
（ｉ）ですでに述べたように、１８ＣＣ ＳＬＰは、ＳＩＢＢを実装して、発信
回線でメッセージを再生し、数字を収集し、その数字が、コーリング・カード・
オプションを表すのである。

【０２８２】 次いで、ステップ８０８で示しているように、ＮＧＳは、他の指令を受け、さ
らにメッセージを再生し、発呼者から実際のＢＯＣコーリング・カードの番号を
収集するのである。これらのステップは、回線識別表示、音声ファイル・アドレ
ス、および呼識別データを含むＰｌａｙ Ｍｅｓｓａｇｅ要求を、ＬＬＰおよび
ＮＧＳ ＮＮＯＳエージェントに転送するために、ＣＬＰに送るステップと、発
呼者をプロンプトしてＢＯＣカードのメッセージを入力するようにするＰｌａｙ
Ｇｒｅｅｔｉｎｇ ｗ／ｃｕｔｔｈｒｕコマンド、およびＣｏｌｌｅｃｔ Ｄ
ＴＭＦ ｗ／ａ ｔｉｍｅｏｕｔコマンドを含む連結したメッセージを送るステ
ップとを含んでいる。次いで、ＣＬＰは、１８ＣＣ ＳＬＰ要求を発信ＬＬＰに
中継し、次いでＬＬＰは、Ｐｌａｙ ＭｓｇコマンドおよびＣｏｌｌｅｃｔ Ｄ
ＴＭＦコマンドを、ＮＧＳ ＮＮＯＳエージェントへ中継する。ＮＧＳは、適切
なリソースを割り当て、コマンドを受信した順序で実行する。ＮＧＳ ＮＮＯＳ
エージェントは、収集されたＤＴＭＦの数字（発呼者によって入力されたＢＯＣ
カード番号を表す）をＬＬＰに送り、それは後に、１８ＣＣ ＳＬＰへ中継され
る。次いで、収集されたＤＴＭＦの数字は、ＬＬＰからＣＬＰへ中継され、次い
でそれは１８ＣＣ ＳＬＰに中継される。

【０２８３】 図１８（ｃ）で述べたようなやり方で、次のステップ８１０は、ＢＯＣカード
の有効性確認ＳＬＰまたはＳＩＢＢ（「ＢＯＣ＿ＣＣ＿ＳＬＰ」）をインスタン
ス化し、それは発呼者によって入力されたＢＯＣカードの番号の有効性確認を要
求する。ひとたびインスタンス化されると、ＢＯＣ ＣＣ ＳＬＰは、照会デー
タを適切なフォーマットにフォーマットし、その照会をＢＯＣカードのデータベ
ースのゲートウェイに中継する。ＢＯＣコーリング・カード照会が実行され、そ
の結果が１８ＣＣ ＳＬＰに戻される。このシナリオの場合、入力されたＢＯＣ
カード番号は有効であるとする。

【０２８４】 次に、ステップ８１２に示すように、ＮＧＳは、ＤＤＤを表すＤＴＭＦの数字
を受信者から回収するためにメッセージを再生するよう指令を受け、回収された
数字を転送し、図２２（ｂ）のステップ８１４に示すように、入力されたＤＤＤ
を確認する。ここに述べるように、図１８（ｈ）に関して、これはクエリを実行
して１８ＣＣ ＳＬＰにその結果を返す有効ＤＤＤ ＳＬＰの例示を必要とする
。この流れにおいて、入力されたＤＤＤは有効であることが仮定される。次に、
ステップ８１６に示すように、終端ノード位置検索が行われ、次に、発呼者を待
機させておき、１８ＣＣ ＳＬＰから前述した方法でアウトダイヤルを行うよう
にとの指令が続く。続いて、ステップ８１８に示すように、１８ＣＣ ＳＬＰか
らＣＬＰへのハンドオフを備えたアウトダイヤルが、終端ノード情報を含んで開
始される。１８ＣＣ ＳＬＰは、その後、切断される。

【０２８５】 次のステップである８２０は、終端ノードの終端回線（ＬＬＰＴ）のためのＬ
ＬＰを例示すること、回線に関連したプロファイルの検索を行うこと、および、
顧客回線情報をＬＬＰに返すことである。続いて、ステップ８２７において、ア
ウトダイヤルおよび応答通知の受信のための指令、および、さらなる指示が終端
回線のためのＮＧＳに転送される。

【０２８６】 最後に、図１８（ｆ）に関してここに述べる呼完了プロセスが、ステップ８２
４で行われる。ＣＬＰから呼完了の通知が出されると、ＥＬＰは、ＤＭに呼情報
を書き込み、終了する。

【０２８７】 ＮＧＩＮによって提供され、図２３（ａ）のフロー・チャートによって例証さ
れるさらなるサービスは、ここに述べた方法でＴＮＴ ＳＬＰを実行する増強音
声サービス返還転送サービスである。先ず、図２３（ａ）のステップ８５２に示
すように、ＮＧＩＮは、スイッチにおいて知的要求を受信し、機能分別を行い、
確立されたそれぞれのインターフェースを備えたＴＮＴ ＳＬＰ、ＬＬＰ（およ
びＣＬＰ）オブジェクトを例示する。続いて、ステップ８５４に示すように、Ｔ
ＮＴ ＳＬＰは、サービスのための音声ファイルを検索する。これは、実際の音
声ファイル・ライブラリーの物理的アドレスを検索するために、ＮＮＯＳを介し
たデータベース・クエリを行うことを課する。次に、ステップ８５６において、
ＮＧＳは、発信元の回線にメッセージを再生するよう指令を受ける。特に、この
ＴＮＴ ＳＬＰは、ＬＬＰおよびＮＧＳ ＮＮＯＳエージェントに転送するため
に、ＣＬＰへメッセージ再生要求を送る。この要求では、回線の識別、音声ファ
イル・アドレス、および、呼の識別が送られる。送られる指令には、挨拶の再生
、カットスルーを備えたメニュー・ルート再生、および、タイムアウトを備えた
ＤＴＭＦ回収が含まれており、一つのものとして連鎖して転送されてもよい。続
いて、ＣＬＰは、ＴＮＴ ＳＬＰ要求を，発信元のＬＬＰに転送し、このＬＬＰ
は、メッセージ再生指令と数字回収指令を、ＮＧＳ ＮＮＯＳエージェントに転
送する。このＮＧＳは、適切なリソースを割り当て、指令を受信された順に行う
。続いて、ＮＧＳ ＮＮＯＳエージェントは、回収されたＤＴＭＦの数字を、後
でＣＬＰを介してＴＮＴ ＳＬＰに転送するために、ＬＬＰに送る。このＥＶＳ
ＴＮＴの流れでは、ＤＴＭＦの数字は、発呼者により選択されたメニューの選
択肢を表す。ＴＮＴ ＳＬＰロジックは、ステップ８５７に示すように、アウト
ダイヤルを備えたメニューの選択肢を、第２の当事者Ｂに関連したルーティング
計画ＩＤに相関させる。

【０２８８】 続いて、ステップ８５８に示すように、ルーティング計画ＩＤを、発信ＴＮＴ
ＳＬＰに返される当事者Ｂの物理的終端アドレスに変換するために、ルーティ
ングＤＢ検索が行われる。加えて、ステップ８６０に示すように、終端ノード位
置を決定するために、データベース検索が行われる。このクエリの結果、ＤＭは
、終端位置をＴＮＴ ＳＬＰに返す。この流れにおいて、当事者Ｂのための終端
ノードは、発信元ノード以外のものである。

【０２８９】 続くステップ８６２において、当事者Ｂへのアウトダイヤルが行われる。つま
り、ＴＮＴ ＳＬＰは、終端ノード情報を含む応答通知指令を備えたアウトダイ
ヤルを、ＮＧＳ ＮＯＳエージェントに転送するためにＣＬＰに転送する。これ
は監督されたアウトダイヤルであるため、呼中であること、無応答、または、応
答の表示がＮＧＳから送り返されなければならない。ＴＮＴ ＳＬＰが動作した
ままであることが仮定される。次に、ステップ８６４において、ここに述べる方
法で、終端ノード上の終端回線（当事者Ｂ）のためのＬＬＰＴが例示され、この
回線に関したプロファイルの検索が行われる。

【０２９０】 プロセスは、図２３（ｂ）のステップ８６６に続き、ここで、アウトダイヤル
のための指令は、ＣＬＰからＬＬＰＯへ転送され、これは、アウトダイヤルを配
置するために、ＮＮＯＳを介してＮＧＳに転送される。この点において、ＥＬＰ
は、アウトダイヤル・データを、フォーマットと転送のためのデータ・マネジメ
ントに書き込んでもよい。当事者Ｂが呼に応答したと仮定すると、ＮＧＳ ＮＮ
ＯＳエージェントは、ＣＬＰを介してＴＮＴ ＳＬＰに転送されるＬＬＰＯに応
答通知を送る。したがって、ＴＮＴ ＳＬＰは、応答通知が、誰かが応答して、
それに応えて、発呼者との橋渡しを開始することの表示であることを決定する。

【０２９１】 図２３（ｂ）のステップ８６８に示すように、ＮＧＳは、当事者Ａを当事者Ｂ
に橋渡しし、両回線のＤＴＭＦ検出をリスンする。特に、ＴＮＴ ＳＬＰは、当
事者橋渡し／ＤＴＭＦリスン指令を、ＮＧＳ ＮＮＯＳエージェントに転送する
ために、ＣＬＰに転送する。この指令は、橋渡しされる回線の回線識別子を伴な
う。ＤＴＭＦリスン指令は、回線の電話が切れている状態の検出を含む。ＣＬＰ
は、当事者橋渡し／ＤＴＭＦリスン指令をＮＧＳ ＮＮＯＳエージェントに転送
する発信元のＬＬＰＯに、この指令を転送する。今度は、ＮＧＳ ＮＮＯＳエー
ジェントが、指令完了通知を、ＬＬＰＯおよびＣＬＰを介して、ＴＮＴ ＳＬＰ
へ送る。この通知は、当事者Ａと当事者Ｂが橋渡しされ、現在、会話できること
を示す。

【０２９２】 次のステップ８７０において、当事者Ｂによって入力され、転送コード、およ
び、当事者Ｃの事前に決定された一覧表選択を表すＤＴＭＦの数字が検出される
ことが仮定される。特に、このステップは、後で、ＣＬＰを介して、ＴＮＴ Ｓ
ＬＰへ転送するために、ＮＧＳ ＮＮＯＳエージェントに、回収されたＤＴＭＦ
の数字をＬＬＰに送ることを課する。続いて、ＴＮＴ ＳＬＰは、ＮＧＳ ＮＮ
ＯＳエージェントに転送するために、発呼者を待機させる／音楽再生指令をＣＬ
Ｐに転送する。この指令は、待機させられる回線（当事者Ａ）の回線識別子を伴
なう。ＣＬＰは、この指令を発信元ＬＬＰに転送し、今度は、ＮＧＳが発呼者Ａ
を待機させられるようにするために、このＬＬＰが、発呼者を待機させる／音楽
再生指令を、ＮＧＳ ＮＮＯＳエージェントに転送する。後で、ＣＬＰを介して
ＴＮＴ ＳＬＰに、発呼者Ａが待機させられたことを示す通知を転送するために
、ＮＧＳ ＮＯＳエージェントは指令完了通知をＬＬＰに転送する。当事者Ａを
待機させる行為は、ＡとＢとの間の橋渡しを壊し、当事者Ａの回線でのＤＴＭＦ
のリスンを取り消し、当事者Ａへの待機音楽の再生を開始することが仮定される
。

【０２９３】 続くステップ８７２において、当事者Ｂにより入力された入力済み一覧表選択
肢の検索が行われる。ＴＮＴ ＳＬＰは、呼先の変換のために、当事者Ｂにより
入力された一覧表の選択結果をＤＭに送る。このＤＭは、（当事者Ｃの）物理的
な切断アドレスをＴＮＴ ＳＬＰ、つまり、当事者Ｃの物理的な切断アドレスに
変換された一覧表の選択結果に返す。含まれるものは、ＴＮＴ ＳＬＰに返され
る物理的終端アドレスを決定するために、ＮＮＯＳを介した当事者Ｃのための終
端ノード位置を決定するステップである。この流れにおいて、当事者Ｃのための
終端ノードが、発信元のノードまたは当事者Ｂの終端ノード以外のものであるこ
とが仮定される。

【０２９４】 次に、図２３（ｂ）のステップ８７４に示すように、当事者Ｃに対するアウト
ダイヤルが行われる。特に、発信元ＬＬＰを介して、ＮＧＳ ＮＮＯＳエージェ
ントに転送し、ＮＧＳがアウトダイヤルをするために、ＴＮＴ ＳＬＰは、終端
ノード情報を含む、応答通知を備えたアウトダイヤル指令を、ＣＬＰに転送する
。これは監督されたアウトダイヤルであるため、呼中であること、無応答、また
は、応答の表示がＮＧＳから送り返される。加えて、ＥＬＰは、フォーマットと
転送のために、アウトダイヤル・データをデータ・マネジメントに書き込む。Ｎ
ＧＳ ＮＮＯＳエージェントは、発信元回線のＬＬＰに応答通知を送る。当事者
Ｃが呼に応答したと仮定すると、ＬＬＰは、ＣＬＰを介して、応答通知をＴＮＴ
ＳＬＰに転送する。ＴＮＴ ＳＬＰは、誰かが応答して、現在、発呼者への橋
渡しが作られたことを決定する。続いて、ステップ８７６において、当事者Ｃの
終端回線のためのＬＬＰＴが終端ノード上で例示され、その回線に関するプロフ
ァイルの検索が、ここで述べる方法で行われる。

【０２９５】 次のステップ８７８は、当事者Ｂと当事者Ｃを橋渡しして、当事者Ｃに関して
回線でＤＴＭＦ検出のためにリスンするようＮＧＳに指令を出す。特に、ＮＧＳ
ＮＮＯＳエージェントに転送するために、ＴＮＴ ＳＬＰは、当事者橋渡し／
ＤＴＭＦリスン指令をＣＬＰに転送する。この指令は、（当事者Ｂと当事者Ｃに
）橋渡しされる回線の回線識別子を伴なう。ＤＴＭＦリスン指令は、回線の切ら
れている状態の検出を含み、当事者Ｂの回線が既にＤＴＭＦリスンを開始したた
め、当事者Ｃにのみ適用する。続いて、ＣＬＰは、この指令を発信元のＬＬＰに
転送し、このＬＬＰは、この指令をＮＧＳ ＮＮＯＳエージェントに転送する。
当事者Ｂと当事者Ｃが橋渡しされたことを通知が示すＣＬＰを介してＴＮＴ Ｓ
ＬＰに転送するために、ＮＧＳ ＮＯＳエージェントは、指令完了通知をＬＬＰ
に送る。これらのステップが完了した後、当事者Ｂと当事者Ｃは、現在、会話し
ており、当事者Ａは待機しており、ＴＮＴ ＳＬＰはまだ動作している。

【０２９６】 ステップ８８０で示すように、当事者Ｂにより呼を切られたことが検出された
かどうかに関しての決定がなされる。もしされていなければ、このプロセスは呼
を切るという事象を待つ。もし呼を切ったことがステップ８８０における当事者
Ｂの回線で検出されたなら、図２３（ｃ）のステップ８８２に示すように、ＮＧ
Ｓは、当事者Ｂと当事者Ｃの間の橋渡しを壊すよう指令を受ける。特に、ＣＬＰ
を介してＴＮＴ ＳＬＰに転送するために、ＮＧＳ ＮＮＯＳエージェントは、
呼を切られたことの検出結果をＬＬＰに送る。ＴＮＴ ＳＬＰは、橋渡し破壊指
令を、ＣＬＰとＬＬＰＯを介してＮＧＳ ＮＮＯＳエージェントに転送する。こ
の指令には、影響を受ける（当事者Ｂ）回線の回線識別子を伴なう。ＣＬＰを介
してＴＮＴ ＳＬＰに転送し、当事者Ｂと当事者Ｃの間の橋渡しが壊されたこと
を示すために、ＮＧＳ ＮＮＯＳエージェントは、指令完了通知をＬＬＰに送る
。

【０２９７】 続いて、ステップ８８４に示すように、ＮＧＳは、発呼者Ａを待機から外し、
当事者Ａと当事者Ｃを一緒に橋渡しするよう指令を受ける。これらのステップが
完了したら、もし取り消しまたは返還が開始されれば、当事者Ａと当事者Ｃが会
話をしており、当事者Ｂは呼を切っており、ＴＮＴ ＳＬＰは、未だに動作して
いる。特に、ＮＧＳ ＮＮＯＳエージェントに転送するために、ＴＮＴ ＳＬＰ
は、発呼者を待機から外す／当事者間の橋渡しをする／ＤＴＭＦリスン指令をＣ
ＬＰに転送する。この指令は、影響を受ける回線の回線識別子を伴なう。ＤＴＭ
Ｆリスンが既に当事者Ｃの回線で開始されたため、ＤＴＭＦリスン指令は、当事
者Ａの回線に影響を及ぼすのみである。ＣＬＰは、ＬＬＰを介して、発呼者を待
機から外す／当事者間の橋渡しをする／ＤＴＭＦリスン指令をＮＧＳ ＮＮＯＳ
エージェントに転送する。ＮＧＳ ＮＮＯＳエージェントは、指令完了通知をＣ
ＬＰを介してＴＮＴ ＳＬＰに送り、この通知は、当事者Ａと当事者Ｃの間の橋
渡しが作られたことを示す。

【０２９８】 次に、ステップ８８６で示すように、当事者Ａが取り消しを開始したかどうか
に関する決定がなされる。もしなされなければ、このプロセスは、入力される取
り消しの数字コードを待つ。特に、当事者Ａによって入力された取り消し数字コ
ードを表すＤＴＭＦの数字は検出され、ＮＮＯＳを介してＴＮＴ ＳＬＰに転送
される。ステップ８８８に示すように、取り消しが検出された結果として、ＮＧ
Ｓは、当事者Ａと当事者Ｃの間の橋渡しを壊すよう指令を受ける。ＬＬＰＯを介
してＮＧＳ ＮＮＯＳエージェントに転送するために、ＴＮＴ ＳＬＰは、橋渡
しを壊す指令をＣＬＰに転送する。この指令は、影響を受ける当事者Ａと当事者
Ｃの回線の回線識別子を伴なう。当事者Ａと当事者Ｃの間の橋渡しが壊れたこと
を示す通知を、ＣＬＰを介して、ＴＮＴ ＳＬＰに転送するために、指令が完了
した時、ＮＧＳ ＮＮＯＳエージェントは、指令完了通知をＬＬＰＯに送る。当
事者Ａは、現在、ＴＮＴ ＳＬＰのメニュー・ルートに返される。

【０２９９】 最後に、ステップ８８９に示すように、ＮＧＳは、発信元回線にメッセージを
再生し、ここに述べる方法で数字を回収するよう指令を受ける。この要求におい
て、回線識別、音声ファイル・アドレス、および、呼識別が、カットスルーを備
えたメニュー・ルート再生、および、タイムアウトを備えたＤＴＭＦ回収などの
指令を含んで送られる。後で、ＬＬＰおよびＣＬＰを介して，ＴＮＴ ＳＬＰに
転送するために、ＮＧＳ ＮＮＯＳエージェントは、ここに述べる方法で、回収
されたＤＴＭＦの数字をＬＬＰに送る。ＤＴＭＦの数字は、発呼者によって選択
されたメニュー選択肢を表す。

【０３００】 ＥＶＳ ＴＮＴの流れはここで終了する。当事者Ａは、取り消しを開始し、現
在、メイン・メニューのメッセージを再生されている。この流れは、図２３（ａ
）のステップ８５６に戻り、そこでは、発呼者が、メニューを離れて、いかなる
選択肢も入力することができる。

【０３０１】 １８Ｃ、および、ここに述べる先端的コレクト・コール・サービスに加えて、
ＮＧＩＮは、以下の付加的なサービスを含み、それに限定されないサービスに対
応する。１）９００番サービス、つまり、９００番呼を受信すると、その９００
番サービス業者がその地域のものか全国的なものかをＮＧＩＮが決定し、もしそ
の地域のものであれば、呼はサービス業者のＣＰＥに回され、発呼者には特別の
料金が適用される。もしそのサービス業者が全国的なものであれば、呼は、今後
の呼の経路設定のために、そのサービス業者の長距離通信業者に回される。２）
私を見つけて／追ってサービス、つまり、特定の加入者にアドレスが割り当てら
れ、その加入者は、そのアドレスに関して呼先を変更してもよいサービス。この
ようにして、ＮＧＩＮは、受けた呼が所在地を移動する間も、加入者が呼を受信
することを可能にする。３）短縮サービス、つまり、加入者の短縮されたダイヤ
ル数字を、有効なＮＡＮＰ数字に変換し、それに従って呼を経路設定するサービ
ス。加入者は、ダイヤルする短縮番号の長さとダイヤルする短縮番号の総数を指
定することができる。加入者は、ＤＴＭＦトーンを介して、システムと対話する
ことにより、ダイヤルする短縮番号を変更してもよい。４）先端的待ち呼サービ
ス、つまり、電話がかけられた当事者に、特別なユーザ端末を介して、発呼者Ｉ
Ｄを渡すことにより、または、発呼者の名前を再生することにより、待ち呼機能
を拡張すること。５）先端的ファックス・サービス、つまり、例えば、ＴＯＤ／
ＤＯＷ選択肢を有する転送一覧表に従って、ファックスを転送すること。６）先
端的ボイス・メール・サービス、例えば、総合ファックス・メール・ボックス、
加入者が電話を取った時の、特別なトーンを介したボイス・メール・メッセージ
の表示、または、ポケット・ベル機能、あるアドレスもしくはアドレスの一覧表
へのメールの送信などの先端的機能を備えたボイス・メール・サービス。７）ど
こでも呼取得サービス、つまり、従来のポケット・ベル・サービスと呼を完了す
るためのネットワークを基礎とした機能とを組み合わせたもの。発信側の当事者
は、加入者を呼び出す選択肢が与えられ、（例えば、事前に割り当てられた番号
またはコードで）誰が電話をかけてきているのかを加入者に知らせるために、Ｄ
ＴＭＦ入力を介して、何らかの表示器に入力し、加入者が回線に接続されるのを
待つ。選択肢として、サービス・プラットフォームは、加入者のポケット・ベル
のスクリーン上の表示のために、発信側の当事者のかけてきた番号に沿って通過
させてもよい。８）ワン・ナンバー・サービス、つまり、全国の全てのサービス
区域に対して、ビジネス顧客のために単一の番号を提供するサービス。ユーザが
その番号をダイヤルし、発信側の当事者の発信位置に基づき、発呼者に最も近い
位置に、呼が経路設定される。９）シングル・ナンバー・サービス、つまり、私
を見つけて、および、私を追ってサービスの組み合わせ。１０）音声駆動ダイヤ
ル・サービス、つまり、加入者は、電話をかけるために、電話のパッド上で数字
をダイヤルする代わりに、単語や短文を話せばよいサービス。このサービスを可
能にするために、加入者は、音声ダイヤル一覧表を作成することと、以下を行う
ことが必要である。先ず、頻繁にかける番号の相手の名前を記録する。次に、記
録した名前をかける番号と関連付ける。最後に、音声ダイヤル一覧表をサービス
業者のデータベースに送る。これで、加入者は、音声ダイヤル一覧表にある名前
を言うことにより、電話をかけるために音声ダイヤル一覧表を使用することがで
きる。加入者が、いつでも番号一覧表の内容を変更できることは明らかである。
１１）音声駆動企業内電話帳サービス、つまり、セントレックス・サービスと同
時に動作する、企業の構内のどの局にも自動化されたアクセスを提供するための
機能。このシステムは、発呼者にアクセスすべき当事者の名前について指示し、
要求された当事者への呼を終了する。１２）音声駆動ネットワーク制御サービス
、つまり、＊機能コードをダイヤルすることにより、加入者が、システムに音声
指示を与えることにより、待ち呼などの特定の機能をオンにしたりオフにしたり
することができるサービス。１３）音声駆動プレミア・ダイヤル・サービス、つ
まり、商業顧客が彼らの会社の名前を音声ダイヤル一覧表に入れることを可能に
するサービス。例えば、ホテルのチェーンは、そのホテルの名前または所在地を
音声ダイヤル一覧表に入れることができる。発呼者がホテルの予約サービス係に
電話をかけると、発呼者は、ホテルの名前とホテルの所在地を話せばよい。その
応答として、呼は、指定されたホテルと特定された所在地へ回される。１４）在
宅Ｖネットワーク音声サービス、つまり、在宅で仕事をしている従業員に、その
家庭の電話に対するビジネス用番号を割り当てるサービス。したがって、従業員
がビジネス用の電話をかける時、従業員はＶネット番号に先だって、＊機能コー
ドをダイヤルすることにより、Ｖネット・サービスを利用することができる。こ
のネットワークは、顧客のＶネット・ダイヤル・プランにアクセスし、番号をＶ
ネット終端器に対して変換する。この呼は、Ｖネットのビジネス顧客に自動的に
課金される。かかってきた電話が受信された時、ビジネス呼のユーザに警報を出
すために、独特の呼び出し音を適用する。１５）発呼者明示サービス、つまり、
加入者への応答されなかった全ての呼をネットワーク内に保存するサービス。加
入者は、保存された全ての呼に目を通すことができる。かけた側の当事者の名前
は、必要に応じて、顧客に対して文字で表記される。１６）プリペイド・カード
・サービス、つまり、エンド・ユーザが、プリペイド電話カードを購入し、この
カードで長距離電話をかけることができるサービス。このサービスには、アクセ
ス番号が割り当てられている。発呼者は、システムに挨拶された後、カードのＩ
Ｄについて指示を受けることができる。事前に支払われた金額に等しいいかなる
単位も、カード上でまだ利用可能ならは、発呼者は、長距離電話をかけることが
許可される。単位は、会話が進む間に消耗し、単位が使い果たされた時、発呼者
は切断される。ユーザは、どの商業クレジット・カードでもこのカードの金額補
充をすることが選択できる。顧客サービスと交換手サービスも提供される。１７
）自動顧客名住所サービス、つまり、電話帳のいかなる番号に関しても、名前と
住所を調べるために、発呼者に特別のサービス・アクセス番号を与えるサービス
。このシステムは、電話帳の調べるべき番号について発呼者に指示し、その番号
に関する名前と住所を再生する。１８）自動コール・バック着信サービス、つま
り、加入者によって応答されない呼の記録を提供するサービス。加入者は、発呼
者側当事者の番号の一覧表に目を通し、ＤＴＭＦトーンを介して、ダイヤルする
番号をシステムに示すことにより、応答されないどの呼にもかけ返すことを決定
できる。この機能は、＊機能コードを介してアクセスできる。１９）呼転送話し
中／無応答サービス、つまり、話し中または無応答状態の呼を、電話帳の他の番
号またはボイス・メール・ボックスのいずれかに転送するサービス。加入者は、
転送番号のプランを変更できる。２０）待ち呼サービス、つまり、一つの会話の
進行中に、加入者に電話がかかってきたことを示すトーン表示を提供するサービ
ス。加入者は、フックを早く押して戻すことにより、呼を無視するか、受けるか
を選択できる。２１）発呼者名通知サービス、つまり、かかってきた電話が呼び
出し段階にある時、特別な端末器を使用して、加入者が、発信側当事者名／番号
を受け取れるサービス。呼が応答されない場合、発信側当事者名／番号は、その
後の利用のために端末器に保存される。２２）私を見つけてサービス、つまり、
端末器ではなく、加入者に電話番号を割り当てるサービス。加入者が、同僚、顧
客、および、家族にいつでもアクセスできるようにするため、単一の番号が、家
庭、事務所、携帯電話、ポケット・ベルなどの全ての現在の連絡番号を統合する
。加入者には、家庭、事務所、携帯電話、ポケット・ベル、ボイス・メール、ま
たは、ファックスの番号を含む私を見つけて一覧表が提供される。加入者に電話
があった時、私を見つけて機能は、私を見つけて一覧表に従って、呼を終端器に
差し向ける。私を見つけて一覧表に指定された終端器のいずれによっても呼が応
答されない場合、呼は、加入者のボイス・メール・ボックスに送られる。２３）
私を追ってサービス、つまり、私を見つけて機能の加入者が、私を見つけて番号
一覧表を、例えば、順序、番号、予定（ＴＯＤ、ＤＯＷ）などを変更するために
、操作できるようにしたサービス。２４）自動リコール機能対応、自動逆課金機
能、呼番号識別制限機能、待ちメッセージ通知機能、携帯電話アクセス探索機能
、好ましい言語、遠隔機能呼、三方向呼、ユーザ個別表示制御付き／なしのサー
ビスを放送する能力、電話帳サービス機能対応、コンピュータに基づいた訓練サ
ービス対応、オン・デマンド娯楽対応、ゲームおよびコンテスト、情報収集およ
び長期保存庫対応、マルチ・メディア・アーカイブ・アクセス対応、特別行事の
ペイ・パー・ビュー（従量料金制）対応、プログラミング・パッケージ対応、シ
ョッピング対応、対象を絞った広告、対象を絞った娯楽、対象を絞ったニュース
、オン・デマンドのビデオ映画、および、オンラインのビデオ・カムコーダ機能
。

【０３０２】 本発明のＩＤＮＡ/ＮＧＩＮシステムにおいて実施されるオペレータサービス
システムの好ましい実施形態が、ここに説明される。

【０３０３】 本発明によれば、オペレータはリソースであり、特定のサービス（例えば、１
〜８００コレクト）のための呼出しまたは特定の顧客（例えば、大きな商業銀行
）のための呼出しのような、オペレータが処理するように訓練される特定のタイ
プの呼出しを参照することがある特定の機能を割り当てられる。通常、オペレー
タは１つまたは複数の機能を割り当てられて、オペレータに割り当てられる各機
能は単一リソースとみなされる。さらに、オペレータは各機能に対してスキルレ
ベルを割り当てられることがある。例えば、スキルレベル「２」が、オペレータ
がそのサービスのための呼出しを処理するように十分に訓練されることを示すこ
とがあり、一方、スキルレベル「Ａ１」が、オペレータがある程度訓練されてそ
のサービスのためのバックアップとして使用されることを示すことがある。

【０３０４】 ＮＧＩＮオペレータサービスの方法およびアーキテクチャが、好ましくは２つ
のプロセスを並列に呼出すことによって、利用可能リソースを待ち行列の呼出し
に提供する。第１のプロセスにおいて、待ち行列が必要とするリソースのタイプ
によって呼出しが待ち行列に配置される。他のプロセスにおいて、利用可能リソ
ースは待ち行列の呼出しに提供される。

【０３０５】 図２５に示されるように、ＮＧＩＮシステム用のオペレータサービスシステム
アーキテクチャ１８００が、サービスノードで与えられるサービス制御局所実行
環境（ＡＳＬＥＥ＠）で実行するサービス論理プログラム（ＳＬＰ）として具体
化される。例外は、機能的にリソース複合体（スイッチネットワーク、ＮＧＳ）
の部分であるＳＬＥＥ ４５０で実行することがあるＬＬＰｓ ５３０、および
オペレータワークステーションＯＷＳ ５３７で実行するソフトウェアアプリケ
ーションであるオペレータＬＬＰｓ ５３６である。オペレータワークステーシ
ョンがＳＬＥＥを支援しない標準パソコンを備えることがあるが、ＯＷＳアプリ
ケーションプロセス５３７は、例えば、ＮＯＳを通して与えられるような、標準
メッセージを介して、オペレータＬＬＰ ５３６のような、ＮＧＩＮ ＳＬＥＥ
４５０プロセスとインタフェースする。オペレータセンターは、ＮＯＳ準拠で
ある必要がないことを理解されたい。例えば、コールセンターへの呼出し終了を
支援するＬＬＰに対するゲートウェイ変換を通しての標準電話技術インタフェー
スが、規定されることがある。

【０３０６】 オペレータサービス論理目的プログラムが、２つのグループ、１）待ち行列割
当てグループ、および２）機能割当てグループに分割される。図２５を参照して
説明されるように、待ち行列割当てグループは、オペレータをオペレータサービ
スに対する要求に割当てることに関連する待ち行列を処理し、リソースが所要オ
ペレータサービスを処理するのに利用可能かどうか、かついずれも利用不可能か
どうかを検索し、呼出しを待ち行列に割当てるプロセス（サブコンポーネント）
の論理グループを備える。より詳しく説明されるように、次のサブコンポーネン
トが待ち行列割当てコンポーネント１７００に含まれる。すなわち、利用可能機
能リスト（ＡＣＬ）１７０２、機能プロセス（ＡＣＰ＠）１７３０、サービスプ
ロセッサ（「ＱＡ＿ＳＰ」）１７１０、および呼出し待ち行列選択（「ＣＱＳ」
）１７１２である。多数の待ち行列割当てコンポーネントが設定されることがあ
り、サービスをベースとしていることを理解する必要がある。ここにより詳しく
説明されるように、機能割当てグループは、オペレータをリソースのセットに等
しいと定義するプロセスを備えて、どのリソース機能が必要なのか（ビジネスル
ールに基づいて）を確かめて、そのリソースが利用可能になる場合にそのリソー
スを必要とするために決定された待ち行列に所要機能を有する所望リソースアド
レスを配置する。

【０３０７】 好ましい実施形態において、次の待ち行列割当て（ＱＡ）グループプロセスの
１つまたは複数のインスタンスが、ＮＧＩＮネットワークの各サービスタイプに
対して与えられる。

【０３０８】 サービスプロセッササブコンポーネント１７１０（ＱＡ＿ＳＰ）はオブジェク
トインスタンスであり、これは、１）オペレータリソース要求をＳＬＰから受取
る。これらのリソースは所要オペレータ機能、例えば、１〜８００コレクトおよ
び英会話など、のリストを含む、２）利用可能機能リストサブコンポーネント１
７０２に照会して、呼出しを処理する規定機能を有するオペレータが利用可能か
どうかを調べる、３）オペレータリソースが呼出しを処理するのに利用可能かど
うかを示す利用可能機能リストサブコンポーネントから照会応答を受取り、オペ
レータリソースが利用可能である場合は、オペレータ端末の物理アドレスを要求
ＳＬＰに転送する。オペレータリソースが利用不可能である場合は、サービスプ
ロセッササブコンポーネントは、オペレータリソース要求を呼出し待ち行列選択
サブコンポーネント１７１２に転送して、呼出し待ち行列サブコンポーネントに
割当てる。例えば、図２５に示されるように、サービスプロセッササブコンポー
ネント１７１０はサービスに対する要求を特定のＳＬＰ、例えば、１８Ｃ ＳＬ
Ｐ ５２２から受取り、ＡＣＬ １７０２に照会して、オペレータリソースが呼
出しを受取るのに利用可能であるかどうかを求める。どのオペレータリソースも
利用不可能である場合は、それは要求を呼出し待ち行列選択オブジェクト１７１
２のインスタンスに渡して、呼出し待ち行列に割当てる。好ましくは、サービス
プロセッサ１７１０は、単一呼出し要求を処理する以上に能動的に走る永続オブ
ジェクトである。

【０３０９】 利用可能機能リスト（ＡＣＬ）プロセス１７０２は、好ましくはオブジェクト
プログラムとして具体化される、サービス処理が完全である場合にいつもインス
タンス生成されて破壊されない静的サブコンポーネントである。それは、利用可
能オペレータ機能および待ち行列割当てコンポーネント内のそれらの関連回線の
リストを維持するように機能する。利用可能機能リストサブコンポーネントは、
１）利用可能オペレータ、それらの機能、およびそれらの物理アドレスのリスト
を維持する、２）利用可能オペレータに関するサービスプロセッササブコンポー
ネント１７１０からの照会に応答する、３）利用可能オペレータリソース情報を
機能プロセスサブコンポーネント１７３０から受取る、そして４）オペレータが
余りにも長い間アイドル状態であったことを示すタイマーの満了時に、利用可能
オペレータリソースをサービス機能割当てサブコンポーネント１７２６に戻す。

【０３１０】 呼出し待ち行列選択インスタンスサブコンポーネント１７１２は、１）利用可
能なオペレータリソース情報をサービスプロセッササブコンポーネントから受取
る、２）呼出し待ち行列（ＣＱ）１７１５を選択して、オペレータサービスに対
する要求を処理する、３）どの呼出し待ち行列サブコンポーネントがオペレータ
リソース要求を受取るかを決定する、そして４）オペレータリソース要求情報を
選択された呼出し待ち行列サブコンポーネントに転送して、待ち行列に配置する
。好ましくは、呼出し待ち行列選択サブコンポーネントは、サービス処理が完全
である場合にいつもインスタンス生成されて破壊されない静的サブコンポーネン
トである。

【０３１１】 好ましい実施形態において、図２５に示されるように、呼出し待ち行列サブコ
ンポーネント１７２０は１つまたは複数の呼出し待ち行列１７１５を備えて、そ
の各々は、オペレータを待つ呼出しの待ち行列を維持し、サービスおよびオペレ
ータ機能に基づいて設定される論理プログラムである。好ましくは、呼出し待ち
行列１７１５は、サービス処理が完全である場合にいつもインスタンス生成され
て破壊されない静的サブコンポーネント１７１５である。特に、各呼出し待ち行
列インスタンスは、１）特定のオペレータ機能を待つ呼出しの多数の待ち行列を
維持する、２）呼出しを待ち行列に出し入れする役割を果たす、３）いったん呼
出しが待ち行列に配置されると、そのアドレスを要求ＳＬＰおよびその関連ＣＬ
Ｐに登録する、４）その呼出し待ち行列を待ち行列の呼出し数および平均保持時
間によって指定する、５）利用可能オペレータリソース指示を機能プロセスサブ
コンポーネントから受取る、６）いったん呼出しが待ち行列から取り出されると
、経路指定応答（利用可能なオペレータアドレスを含む）を要求ＳＬＰに転送す
る、そして７）現在待ち行列に在る発信者がハングアップした場合にはハングア
ップ通知をＣＬＰから受取り、ハングアップ通知をＣＬＰから受取ると、呼出し
を待ち行列から削除する。呼出し待ち行列インスタンスが待ち行列割当てグルー
プの１つ以上のインスタンスによってアクセスされることがあり、待ち行列割当
てグループの単一インスタンスが複数の呼出し待ち行列にアクセスできることを
理解する必要がある。例えば、１８Ｃサービス５２２の場合、１つの待ち行列割
当てグループ、しかし複数の呼出し待ち行列、例えば、サービスが提供される各
異なる言語に対して１つの呼出し待ち行列があることがある。これが呼出し経路
指定に対する基準である場合は、呼出し発信の様々な地理領域に対して複数の呼
出し待ち行列（単一サービスに対する）があることがある。

【０３１２】 機能プロセス（ＣＰ）１７３０はオブジェクトプログラムであり、これは、１
）利用可能オペレータリソース指示をサービス機能割当てサブコンポーネント１
７２６から受取る、２）呼出し待ち行列サブコンポーネントのどれかが規定され
た機能を有するオペレータリソースを要求しているかどうかを決定するために呼
出し待ち行列状況データ記憶装置１７１８を調べる、３）オペレータリソースが
呼出し待ち行列サブコンポーネントによって要求される場合は、利用可能オペレ
ータリソースを受取る呼出し待ち行列サブコンポーネントにオペレータリソース
指示を転送する、そして４）オペレータリソースが呼出し待ち行列サブコンポー
ネントによって要求されない場合は、オペレータリソース指示を利用可能機能リ
ストサブコンポーネントに転送する。機能プロセスサブコンポーネント１７３０
は、特定のオペレータリソースに対する必要に関して情報をサービス機能割当て
サブコンポーネント１７２６に追加して送る。好ましくは、機能プロセスサブコ
ンポーネント１７３０は、単一呼出し要求を処理する以上に能動的に走る永続オ
ブジェクトである。

【０３１３】 機能割当てグループに含まれる次のプロセスおよび機能コンポーネントが、オ
ペレータおよびオペレータの機能に関連する通信回線の状態を維持するＳＬＥＥ
内で実行する回線論理プログラムであるオペレータＬＬＰ ５３６，および現在
のシステム要求および処理ルールに基づいて利用可能リソースをいろいろなサー
ビスに割当てるサービス機能割当て（ＳＣＡ）プロセス１７２６を含む。好まし
くは、オペレータが接続する場合にプログラムがインスタンス生成されてオペレ
ータが切断するまで依然として実行している、オペレータ回線に対して１つのオ
ペレータ回線論理プログラムが有る。オペレータ回線が別の呼出しをとるのに利
用可能である場合に、それはサービス機能割当てサブコンポーネントを通知する
ように機能する。前述のように、ＯＷＳインスタンス５３７は、必ずしもＳＬＥ
Ｅで実行しないオペレータワークステーションアプリケーションであるが、ＳＬ
ＥＥで実行する関連オペレータＬＬＰとインタフェースする。

【０３１４】 サービス機能割当て処理１７２６は要求およびビジネスルールに基づいてオペ
レータ機能（リソース）を選択し、この機能を待ち行列割当てに提出する。特に
、サービス機能割当て１７２６は静的サブコンポーネントである。このサブコン
ポーネントは１）使用可能なオペレータを現在のシステム要求および処理規則に
基づいて各種サービスに割当て、２）現在のシステム要求およびオペレータの機
能を考慮して、どの待ち行列割当てが使用可能なオペレータリソースを受け取る
べきかを判断し、３）複数の待ち行列割当てコンポーネントをサポートし、４）
使用可能なオペレータリソース情報を使用可能機能リストのサブコンポーネント
１７０２から受け取って待ち行列割当てに再度割当て、５）オペレータが呼出し
に応えることができるオペレータ回線論理プログラムから通知を受ける。サービ
ス機能割当てサブコンポーネントは必ずインスタンス生成がなされ、サービス処
理が完了したとき破壊されないものであるのが好ましい。

【０３１５】 ＮＧＩＮサービス制御アーキテクチャに与えられているオペレータおよび呼出
しセンターシステム１８００の例は、図２５および２６（ａ）〜２６（ｇ）に関
して示されている。

【０３１６】 この例ではＳＬＰが、ここに示されているようにＮＧＩＮサービス制御システ
ムに従って実行すると仮定されている。表示例では、１−８００コレクトサービ
ス（１８Ｃ）５２２のＳＬＰが実行している。実行中、発呼者は、たとえば「０
」キーをたたいてオペレータに要求を出すことができる。１８Ｃ ＳＬＰ ５２
２はこれに応えて１８Ｃサービスのサービスプロセッサオブジェクト１７１０を
呼び出す。例を挙げると、１８Ｃ ＳＬＰ ５２２はＱＡ＿ＳＰ １７１０から
機能（１８Ｃオペレータ：英語を話す）を要求することができる。これは図２５
のステップ１８０１に示されている。さらに詳しく述べると、１８Ｃ ＳＬＰ
５２２はサービス処理を呼び出し、サービス処理にオペレータサービスが要求さ
れている呼出しの呼出し識別子を与える。これに応え、サービス処理１７１０は
ＡＣＬインスタンス１７０２に照会し、図２５のステップ１８０２に示されてい
るように、リソース（１８Ｃ機能を持つオペレータ、たとえば英語を話す）が使
用可能であるかどうかを判断する。すなわち、ＱＡ＿ＳＰは特定機能要求をＡＣ
Ｌに転送し、開放されていて前記要求を処理することができるオペレータが現在
ネットワーク内にいるかどうかを確認する。図２６（ａ）に示されているステッ
プ１８４１−１８４７は１８Ｃ ＱＡ検索を実行するステップ、特に１８Ｃ Ｓ
ＬＰが呼出しの発信人が要求したオペレータリソースを見つけるために実行でき
るステップについて述べている。図２６（ｂ）に描写されているステップ１８４
８では、１８Ｃ ＳＬＰはＱＡ１７００にリソース／機能（すなわちオペレータ
）を要求する。これに対し、ＱＡは終了処理を開始するように１８Ｃ ＳＬＰに
要求されている回線情報をオペレータ回線に戻す。１８Ｃ ＳＬＰからの最初の
照会にはＳＬＰのアドレスおよびそれに関連したＣＬＰが含まれている。

【０３１７】 ＱＡ＿ＡＣＬ位置検索を実行する具体例は図２６（ｃ）に示されているように
、処理ステップ１８４９−１８５７として図示されている。ＱＡ＿ＳＰ １７１
０は特定機能要求をＡＣＬ １７０２に転送し、開放されていて前記要求を処理
できるオペレータが現在ネットワーク内にあるかどうかを確認する。図２６（ｃ
）のステップ１８５７に示されてているように、要求されている機能が現在開放
されていないかどうかの確認がなされ、前記要求が呼出し待ち行列（ＣＱ）に置
かれる必要があることを示す。

【０３１８】 リソースが使用可能であれば、たとえば、要求されている機能が割り当てられ
ているＡＣＬリスト１７０２にオペレータがいれば、ＡＣＬインスタンス１７０
２はＱＡ＿ＳＰ １７１０に、図２５のステップ１８０３に示されているように
、要求機能が割り当てられているリソース（オペレータ）のライン識別子（ネッ
トワーク端末アドレス）を供給する。加えて、前記オペレータはＡＣＬから削除
される。次にサービスプロセッサ１７１０はこれを１８Ｃ ＳＬＰに渡し、ステ
ップ１８０４（図２５）に示されているように、１８Ｃ ＳＬＰ ５５２にこの
呼出しをリソースに送るよう命令する。

【０３１９】 ＡＣＬ １７０２は、リソースが使用不可であり、たとえば要求機能を持つオ
ペレータがないと判断した場合は、ＡＣＬ １７０２は図２５のステップ１８０
３で否定応答を戻す。サービスプロセッサ１７１０は次に図２５のステップ１８
０５に示されているように、呼出し識別子を呼出し待ち行列選択インスタンスに
送る。前記呼出し待ち行列選択インスタンスは次に図２５のステップ１８０６に
示されているように、呼出し識別子を選択し、これを適当な呼出し待ち行列１７
１５に配置する。

【０３２０】 図２６（ｄ）および２６（ｅ）はＱＡ＿ＳＰによって実行され、要求をＱＡ＿
ＣＱＳに送って呼出し待ち行列に呼出しをする手順を説明しているステップ１８
５８−１８６３（図２６（ｄ））、およびＱＡ＿ＳＰによって実行され、現在の
呼出しを呼出し待ち行列にする呼出し待ち行列（ＣＱ）場所検索処理を説明して
いるステップ１８６４ − １８７１ （図２６ （ｅ））に照らして呼出し待
ち行列選択（ＣＱＳ）位置検索を詳細に述べている。

【０３２１】 ただし、実際の呼出しはＮＧＳリソースまたはスイッチに物理的に保持され、
たとえば、前記呼出しは起因し、呼出し（呼出し識別子）がソフトウェア待ち行
列（呼出し待ち行列）に配置されたプレースホルダーに保持されることを理解さ
れたい。前記呼出し待ち行列は呼出し待ち行列選択論理プログラムの一部である
ビジネスルールに基づいて選択されるのが好ましい。このビジネスルールは呼出
し待ち行列を選択する場合、各種の判定基準を考慮して応用する。たとえば、呼
出し待ち行列は呼出し起点を基に分割されてもよい。この場合、呼出しは呼出し
が「隣接」（ネットワーク効率の点で）の呼出しセンターに指示する。他の判定
基準は現在の待ち行列レベル、待ち時間、呼出しセンタロード、呼出しセンタ優
先、時刻および曜日アルゴリズムなどを基準にできる。呼出しが呼出し待ち行列
インスタンス１７１５の待ち行列に入ると、その呼出しのＣＬＰ ５４５にメッ
セージを送り、呼出しが待ち行列に入ったことを示す。これについては図１５の
ステップ１８０７に示されている。さらに詳しく述べると、ＣＱ １７１５は発
呼者が電話を切り、機能要求がＣＱから消去される必要がある場合に備えてその
アドレスをＣＬＰ ５４５に登録する。さらに、ＣＱは、ステップ１８０８に示
されているように、そのアドレスを１８Ｃ ＳＬＰインスタンス５２２に登録し
、ステップ１８０９に示されているように呼出し状態待ち行列１７１８の状態情
報を更新する。呼出し状態待ち行列１７１８にＣＱの実行状態、たとえば、その
待ち行列がどれだけ深く満たされているか、平均保持時間がどのくらいか、また
、待ち行列がいつ空になるかを通知するのが好ましい。

【０３２２】 この時点では、１８Ｃ呼出しの処理に関する限り活動がないと理解されたい。
オペレータサービスシステムは要求された機能を持つオペレータリソースが使用
可能になったという通知を待っている。

【０３２３】 ＯＷＳインスタンス５３７が使用可能になった場合、関連したオペレータＬＬ
Ｐ５３６はこれを検出し、ＳＣＡインスタンス１７２６に通知する。上述のよう
に、ＳＣＡインスタンス１７２６は、使用可能なオペレータをサービスのために
ある待ち行列割当てに割り当てることを担当するインスタンスである。ＳＣＡと
オペレータＬＬＰｓはいずれの待ち行列割当てグループ１７００とも関係なく実
行し、複数の待ち行列割当てグループ１７００とのインターフェースをとる。オ
ペレータが１種類以上のサービスに、したがって１つ以上の待ち行列割当てに使
用可能であるため、ＳＣＡはビジネスルールを応用してどのサービスにオペレー
タを割り当てるべきかを判断する。ＳＣＡ １７２６で実行されたビジネスルー
ルはリソースがどのようにしてサービス（マップを待ち行列割当てグループにサ
ービスする）に割り当てるかを命令する。好ましい実施形態では、これらのルー
ルは使用可能なオペレータ機能、スキルレベル、契約内容、時刻／曜日アルゴリ
ズム、現在の呼出し待ち行列レベル、およびその他の判定基準数に基づくことが
できる。一例として、本発明のインテリジェントネットワークサービスプロバイ
ダおよび指定代理人、すなわちＭＣＩ／Ｗｏｒｌｄｃｏｍは顧客、たとえば商業
銀行Ａと契約を結ぶことができる。この契約書は主として１８Ｃ呼出しに割り当
てられた一定のオペレータ数が商業銀行Ａの呼出しのために準備されると記述し
ていうる。このように、オペレータが使用可能になったとき１８Ｃ呼出し待ち行
列に呼出しがない場合、そのオペレータは商業銀行Ａの呼出し待ち行列に割り当
てられる。

【０３２４】 さらに一般的に述べると、図３０（ａ）はサービス機能割当処理１７２６（図
２５）が実行したビジネスルールの応用例を明示している。この規則を実行し、
たとえばどのサービスを使用可能なオペレータリソースに与えるべきかを判断す
ることができる。たとえば、このオペレータリソースは次の機能を持つことがで
きる。このリソースは英語およびフランス語を理解することができる。このリソ
ースは１−８００コレクトサービススキルを持つことができ、または一般オペレ
ータサービスの権限が与えられ、およびそのリソースは北東に配置することがで
きる。

【０３２５】 ステップ１９２１では、呼出し待ちがあるかどうかについて判断される。呼出
し待ちがあれば、この呼出しをどのＱＡ呼出し待ち処理に送るべきかが判断され
る。

【０３２６】 ステップ１９２２に示されているように、これは新たに使用可能になったオペ
レータリソースが英語以外の言語を話す機能があるかどうかを判断する必要があ
る。オペレータリソースが英語以外の言語を話す機能を持つ場合は、ステップ１
９２４において、１−８００コレクトまたはオペレータサービスなどのサービス
スキルをそれぞれのＱＡ処理の呼出し待ち行列に要求している呼出し状態が判断
される。これは呼出し待ち行列状態処理１７１８（図２５）に照会することで実
行される。次に、ステップ１９２６では、オペレータリソースが英語以外の言語
能力、たとえばフランス語能力を持つオペレータを待っている呼出しの最も長い
保持時間を持つＱＡ処理に送られる。ステップ１９２２でオペレータリソースが
英語を話す能力だけを持つと判断した場合は、この処理はステップ１９２８へ進
み、そこで１−８００コレクトまたはオペレータサービスなどのオペレータサー
ビススキルの呼出し待ち行列状態が判断される。次に、ステップ１９３０に示さ
れているように、規則を実行し、予め決められた重みに従って呼出し重み待ち行
列負荷のバランスをとる。たとえば、１−８００コレクトサービスを待っている
呼出し待ち行列に入っている呼出しに割り当てるのに比べて、たとえば一般オペ
レータサービスを待っている呼出し待ち行列に配置されている呼出しに５％多い
オペレータリソースを割り当てるのが望ましい。次に、オペレータリソースを受
け取るＱＡ処理が決定すると、このリソースはそのＱＡ処理に送られる。ステッ
プ１９２１で待ち状態にある呼出しがないと判断された場合は、次にステップ１
９３４で、ラウンドロビンリソース割当てを実行し、オペレータリソースをＱＡ
処理に割り当ててそのスキルを使用可能なリソースの言語能力と一致させること
ができる。

【０３２７】 さらに図２５に関して言えば、ＳＣＡ １７２６は待ち行列割当てグループ１
７００の機能プロセス１７３０に照会し、ステップ１８１０に示されているよう
に、呼出し待ち行列レベルを判断する。図２６（ｆ）のステップ１８８１ −
１８８８まではＱＡ＿ＣＰ位置検索処理を詳細に述べている。ＳＣＡは特定割当
機能を持つオペレータが使用可能になった旨を機能プロセス（ＣＰ）に転送する
（ステップ１８８８、図２６（ｆ））。

【０３２８】 図２５に戻って参照すると、ＣＰ１７３０は次に呼出し待ち行列状態インスタ
ンス１７１８の媒介によって呼出し待ち行列１７１５に照会し、ステップ１８１
１に示されているように、いずれかの呼出しが使用可能になったばかりの機能を
要求しているかどうかを判断する。記述の通り、呼出し待ち行列インスタンス１
７１８は各呼出し待ち行列の現状がわかる。このように、たとえば、ＳＣＡ１７
２６はそのビジネスルールを適用する場合、判定基準として現在の呼出し待ち行
列レベルを利用することができる。使用可能なオペレータが２つまたはそれ以上
の割り当てられた機能を持つ場合、ＳＣＡはＳＣＡビジネスルールに命令された
順序でその機能に関連した各待ち行列割当ての機能プロセスに照会する。たとえ
ば、使用可能なオペレータが１８Ｃ呼出しおよび商業銀行Ａの呼出しの両方を処
理するように割り当てられていれば、ＳＣＡビジネスルールはＳＣＡに最初に１
８Ｃの機能プロセスに照会するよう命令することができる。１８Ｃの待ち行列に
呼出しが入っていない場合、ＳＣＡ１７２６はオペレータを商業銀行Ａの機能プ
ロセスに割り当てることができる。

【０３２９】 図２６（ｇ）は呼出し待ち行列状態を検索し、開放されたばかりのオペレータ
機能が現在呼出し待ち行列内で待っているかどうかを判断するために呼び出され
た処理ステップ１８８９−１８９７までを示している。説明のために、新たに使
用可能になったオペレータリソースに呼出し待ち行列の要求があると仮定してい
る。

【０３３０】 このビジネスルールを提供した後、ＳＣＡインスタンス１７２６はそのリソー
スの識別子をサービスの待ち行列割当ての機能プロセス１７３０へ送ることによ
り、使用可能なリソースをサービスに割り当てる。特に、ＣＱはその機能の物理
アドレスを受け取って呼出しに接続する。ＣＰ１７３０は次に、図２５のステッ
プ１８１２に示されているように、リソースを呼出し待ち行列に割り当てる。

【０３３１】 その呼出し待ち行列に呼出しがある場合、この呼出し待ち行列処理はメッセー
ジをＳＬＰに、この場合は１８Ｃ ＳＬＰ ５２２に送る。このメッセージはス
テップ１８０８を持つステップ１８１３およびこの２つの処理の影響を表すステ
ップ１８１３に示されているように、リソースを呼出しに割り当てる。これに応
え、１８Ｃ ＳＬＰはオペレータのネットワーク端末アドレスをＮＧＳに送るサ
ービス応答メッセージに含めることにより、呼出しをオペレータリソースに送る
。ＳＬＰがオペレータＬＬＰと通信し、オペレータのネットワーク端末アドレス
をさらにＳＬＰに送って名前トランザクションをすべて削除することができる。

【０３３２】 その直後、呼出しは呼出し待ち行列から落下し、ステップ１８１４に示されて
いるように、ＡＣＬが更新されてこのリソースが利用できないことを表示し、そ
れによって呼出しにオペレータから応答があるまで呼出しのリソースを確保する
。

【０３３３】 分散インテリジェントネットワークのオペレータサービスシステムの追加機能
として、オペレータ可用性のトリガー予測を挿入することができる。呼出しを処
理しているオペレータとして、そのオペレータはそれら（またはそのＯＷＳアプ
リケーション）はそれらがやがて、たとえば３０秒以内に使用可能になることを
理解する時点に達するのが普通である。トリガーポイントはメッセージをオペレ
ータＬＬＰ５３６に自動的に送るＯＷＳアプリケーション５３７に挿入して、ま
たはオペレータに選択され、オペレータＬＬＰに送られるメッセージになるマニ
ュアルオプションとして挿入されてよい。このメッセージはオペレータＬＬＰに
対し、ＳＣＡインスタンス１７２６にリソースの未決可用性を通知させる。ＳＣ
Ａは次にオペレータを呼出し待ち行列に割り当てる処理を開始する。このように
して、オペレータが実際に呼出し待ち行列の呼出しに割り当てられ、その呼出し
がオペレータに送られるまでには、オペレータは使用可能になっている。タイマ
（図示せず）をＳＣＡにセットすることで、呼出しがオペレータに到達し、オペ
レータが使用可能になるイベントをさらに正確に一致させることができる。

【０３３４】 本発明のＮＧＩＮ方法によれば、使用可能なリソースは呼出しに割り当てられ
る。使用可能なリソースは１つの呼出し待ち行列にだけ提供されて競合を防ぐ。
本発明の技法によってリソースを呼出し待ち行列に割り当てる含意は、呼出し待
ち行列とＳＣＡｓが待ち行列割当てグループインスタンスの一部ではないため、
複数のリソースが１つの呼出しだけを持つ１つの呼出し待ち行列に割り当てられ
ることは可能であることである。複数の割当が機能プロセスに必要な時間枠内に
行われ、呼出し待ち行列状態に照会、レポートすればこれが発生する。これが発
生すると、呼出し待ち行列に割り当てられた最初のリソースが呼出しを受け取る
。次のリソースは空の呼出し待ち行列に割り当てられる。この状況に適応させる
ために、ＡＣＬはさらにステップ１８１４のリソースに設定（５秒間）され、割
り当てられるタイマ機構を組み込むこともできる。この時機能プロセス１７３０
はＡＣＬ１７０２を更新してリソースが使用不能であることを示す。リソースが
呼出しに割り当てられる前にタイマが切れると、リソースは呼出し待ち行列から
削除され、ＡＣＬで使用可能になり、ＳＣＡにより再度割り当てられる。リソー
スが割り当てられた１つだけの機能を持つオペレータであれば、リソースは割当
先がないため、リソースはタイマが切れた後も呼出し待ち行列に留まることがで
きる。

【０３３５】 図３０（ｂ）は待ち行列割当機能サービス処理に関して、ビジネスルールの応
用を一般的に説明している。図３０（ｂ）に示されているように、最初のステッ
プ１９４０はオペレータリソースが使用可能になったことを判断する。この例で
は、オペレータリソースが１−８００コレクトＱＡ処理に割り当てられていると
仮定している。次に、ステップ１９４１では、呼出し待ち行列で１−８００コレ
クトサービスを待っている呼出しがあるかどうかが判断される。呼出し待ち行列
で待っている呼出しがあれば、ステップ１９４２において英語以外の言語を話す
能力を持つオペレータリソースを待っている呼出しがあるかどうかが判断される
。この種のオペレータリソースを待っている呼出しがある場合は、ステップ１８
４４でリソースが保持時間の最も長い呼出しに割り当てられる。ステップ１９４
２ですべての呼出しが英語を話すオペレータリソースを待っていると判断された
場合は、ステップ１９４６でリソースが保持時間の最も長い（たとえば３秒以上
）呼出しに割り当てられる。また、オペレータリソースはラウンドロビン方式で
他の呼出し待ち行列に割り当てることもできる。

【０３３６】 ステップ１９４１でオペレータサービスを待っている呼出しがないと判断され
た場合は、ステップ１９５０でオペレータリソースが図２５に示されているよう
に、ＱＡ使用可能機能リスト１７０２に割り当てられる。

【０３３７】 図２７（ａ）および２７（ｂ）はオペレータおよび呼出しセンタサービスを取
り入れているサービスノードの物理アーキテクチャの例を示している。特に、図
２７（ａ）は図１６に示されているＮＧＩＮサービスノード２０４内のオペレー
タサービスシステム１８００の１つの実施を示している。図２７（ａ）に示され
ているように、１つまたはそれ以上の個別オペレータワークステーション５３７
（ａ）から５３７（ｎ）はＬＡＮ１８３６を介して高速広域ネットワークＷＡＮ
５７に接続しているのが示されている。

【０３３８】 図２７（ｂ）に示されている代替実施形態では、オペレータおよびカスタマ呼
出しセンタサービスシステム１８００を外部インターフェースを介してＮＧＩＮ
システムアーキテクチャ内に組み込むことができる。本実施形態では、１つまた
はそれ以上のオペレータワークステーション５３７ａから５３７ｎまではＬＡＮ
１８３７を介してカスタマ呼出しセンタサーバー１８３０に接続され、これがコ
ンピュータ電話インターフェース装置１８３２を介してＮＧＩＮサービスノード
に供給されている高速データリンク５９とインターフェースで接続している。

【０３３９】 オペレータサービスおよびカスタマ呼出しセンタサービスはＴ１／ＦＧＤイン
ターフェースまたはＩＳＤＮインターフェースを介してＮＧＩＮシステムと接続
が可能であることを理解されたい。オペレータおよび呼出しセンタサービスの状
況のなかでは、サイト、たとえば２０４’で受信した特定機能のオペレータリソ
ースを要求するカスタマは要求された機能を持つオペレータリソースサービスに
簡単に割り当てることができることを理解されたい。なぜなら、ＮＧＩＮはたと
えば別のサイト４５ａに配置しているオペレータワークステーション５３７と呼
出しを受信したサイト間にプロセス間通信を提供するためである。

【０３４０】 オペレータ支援オプションを用いて１−８００コレクトサービスを提供するＮ
ＧＩＮの機能を説明するシナリオは図２８（ａ）を参照して説明されている。こ
のシナリオでは、１−８００コレクト（１８Ｃ）ＳＬＰを使用してサービスを提
供している。このＳＬＰはＬＩＤＢ検索ＳＬＰを呼び出して呼び出されたライン
に請求することができることを確認し、また、検証ＤＤＤ ＳＬＰが発呼者によ
って入力されたＤＤＤが有効であることを確認する。このシナリオに使用されて
いるすべてのデータベースおよびボイスファイルはサービス生成環境２２８を用
いて組み込まれていると仮定した。このシナリオでは、発信または着信ラインの
機能はない（呼出し待ち、呼出し転送）。さらに、このシナリオを述べる上で、
次のように仮定されている。１） すべての呼出しはＮＧＩＮサービスを要求す
る。２） ＮＧＩＮは発信および着信ライン機能が存在するかどうかを判断する
。３） ＮＧＩＮがサービス要求をＮＧＳから受け取る前に、ＮＧＳは呼出し文
脈データをデータ管理に書き込む場所を生成している。ＮＧＳはこれをスペース
の識別に使用する名前である「ネットワーク呼び出しＩＤ」に指定する。ここで
ＮＧＩＮは情報を書き込む。４） ＮＧＳはすべてのイベント情報を呼出し文脈
データに記録するイベント論理プログラム（ＥＬＰ）のインスタンスをも生成し
ている。５） ＮＯＳ連結性はＳＬＰｓとＤＭ間、ＤＭとＮＯＳ間およびＮＯＳ
とＳＬＰｓ間で通話するのに使用されている。６） ＳＩＢＢｓはＳＬＰｓとし
て同一ライブラリに共存し、そのためＳＬＰがＳＩＢＢの名前翻訳を要求する必
要がない。７） ＳＩＢＢｓの新バージョンは前バージョンと後方互換性がある
。８） サービス内で使用されている全ボイスファイルの位置と実名はそれらが
使用される時ではなく、サービスの最初に検索される。９） １−８００コレク
ト呼出しについては発信ラインの検索はなされない。すなわち、いかなる種類の
ラインからのいかなる発呼者も１−８００コレクト呼出しをすることができる。
１０） ＮＧＩＮインターフェースは正しいリソースを取得してＮＧＩＮから送
られた要求の処理を担当するＮＧＳ ＮＯＳエージェントを介する。１１） Ｎ
ＧＳに送られる命令はライン識別子を持ち、そのラインを命令に対応付けること
ができる。１２） ＳＬＰｓはサービス生成で設定し、ａ） 必ずインスタンス
を生成する、ｂ） 利用／タイムアウトに基づいて終了する、ｃ） 命令の結果
として終了することができる。１３） インスタンスが生成されたＳＬＰｓは使
用／時間を基にＳＬＥＥ資源管理プログラムによって管理される。このシナリオ
に記載のステップは簡単に拡張して他のコレクト呼出しおよびＢＯＣ（ベルオペ
レーティングカンパニー）名刺機能をサポートすることができることを理解され
たい。

【０３４１】 図２８（ａ）を参照すると、そこには図１８（ａ）に関連してここに述べらて
いるような、たとえば起呼加入者Ａにより呼び出された入電の識別機能を実行す
る第一ステップ１１６０が提供されている。これはＦＤ、発信ラインＬＬＰｓ、
１８Ｃ ＳＬＰおよびＣＬＰ（ステップ１０３４、図１８（ａ））を例示し、Ｌ
ＬＰＯ、ＣＬＰおよびＳＬＰ間の接続を確立し、１８Ｃ ＬＬＰを既述の要領で
ＮＧＳ ＮＯＳエージェントに登録する必要がある。たとえば、このステップは
ＦＤ名をＮＧＳ／ＮＯＳエージェントから名前翻訳（ＮＴ）に送り、そのメッセ
ージに呼び出された８００＃、ＡＮＩ、ラインＩＤ、ネットワーク呼び出しＩＤ
および発信スイッチトランクデータ（名前＝ＦＤ）を含めることができる。ＥＬ
Ｐアドレスもこの情報と一緒に送信される。次に名前翻訳はＮＴによって実行さ
れ、機能弁別器名を判断する。これはその名前をＤＭに送り、実際のＳＬＰ名（
名前＝ＦＤ．ＳＬＰ）を取得する。常時実行している（持続性ＳＬＰ）各ＳＬＥ
Ｅに機能弁別器があると仮定し、ＤＭ４００は保管場所を持つＦＤ ＳＬＰの実
名を名前翻訳（ＮＴ）に送る。ＮＴはその名前をＬＲＭに送り、それがＦＤ Ｓ
ＬＰがどこにインスタンス生成されたかを判断する。ＬＲＭはＳＬＥＥを拾い、
ＳＬＥＥのアドレスをＮＴに戻す。（ＳＬＥＥアドレス） ＮＴはそのメッセー
ジ（ＮＧＳから来たメッセージ）を機能弁別器に送る。このメッセージは最初に
入ったすべての情報を持つ。次にデータ照会はＮＧＳ ＮＯＳエージェントから
最初に受け取ったデータを使ってＤＭにされ、それによってＦＤ ＳＬＰにされ
、ＬＬＰ、ＣＬＰおよびＳＬＰを探す。他の実施形態ではそれらのオブジェクト
をＮＯＳ ＮＴを通じて探すのではなく、オブジェクトはデータビューを介して
簡単に使用できるようにされ、ＤＭＡＰＩを介してアクセスすることができるこ
とを理解してください。ＤＭは照会の結果を３つのＳＬＰ名、ＬＬＰ、ＣＬＰ、
ＳＬＰを持つＦＤに戻し、この照会の結果を用いて、ＦＤ ＳＬＰはＳＬＰ論理
名をＮＴに送って名前翻訳機能を実行し、ＳＬＰｓのそれぞれの物理位置を取得
して実行する。これは１つのメッセージまたは３つのメッセージを並列に実行し
てなされる。ＮＴはＬＲＭに照会し、ＬＲＭが必要に応じてＳＬＥＥに要求して
インスタンスを生成させると仮定し、３つのＳＬＰのインスタンスがどこに生成
されたかを突き止める（ＳＬＰｓは異なるＳＬＥＥで実行できる）。ＬＲＭはＳ
ＬＥＥアドレスを持つ実際のＳＬＰ名を戻す。

【０３４２】 インスタンス生成の後、ステップ１１６２に示されているように、ＮＴはＥＬ
Ｐ、ＬＬＰおよびＳＬＰのアドレスを含めすべてのデータをＣＬＰに送り、ＣＬ
ＰおよびＥＬＰのアドレスを含めすべてのデータをＬＬＰに送り、ＣＬＰおよび
ＥＬＰのアドレスを含めすべてのデータをＳＬＰに送り、確立されているＬＬＰ
、ＣＬＰ ＳＬＰ間を接続する。

【０３４３】 次に、ステップ１１６４に示されているように、１８Ｃ ＳＬＰはボイス／フ
ァイル名を検索してサービスする。次のステップでは、１８Ｃ ＳＬＰがサービ
スのためのボイスファイルを検索する必要がある。１８Ｃ ＳＬＰはボイスファ
イルライブラリの論理名をＮＴに送り、名前を翻訳してもらう。ＮＴはＤＭに実
名および１８Ｃサービスに関連するボイスファイルライブラリの位置を照会する
。この名前はライブラリレベルにあり、ライブラリはサービスで使用されると思
われるすべてのボイスファイルを含んでいる。ＤＭは実際のボイスファイルライ
ブラリ名およびその保管場所のアドレスを、ボイスファイルライブラリを含むデ
ータベースの使用可能性をＬＲＭに照会するＮＴに戻す。ＬＲＭはボイスファイ
ルライブラリを含むデータベースのアドレスをＮＴに戻す。ボイスファイルライ
ブラリの物理アドレスはＮＴから１８Ｃ ＳＬＰに戻される。

【０３４４】 次に、ステップ１１６６と１１６８に示されているように、ＮＧＳは発信ライ
ンに対してメッセージを再生するよう命令される。これは１８Ｃ ＳＬＰに再生
メッセージ要求をＣＬＰに送らせ、ＬＬＰおよびＮＧＳ ＮＯＳエージェントに
転送させることができるステップを含むことができる。この要求で、ライン識別
、ボイスファイルアドレスおよび呼出し識別が送られる。送られた命令は再生の
音色、カットスルー付き再生挨拶およびタイムアウト付きコレクトＤＴＭＦを含
むことができる。この３つの命令は連結され、１つになって転送される。とくに
、ＣＬＰはステップ１１７０に説明されているように、１８Ｃ ＳＬＰ要求を発
信ＬＬＰに転送し、ＬＬＰは再生メッセージ命令およびコレクトディジット命令
をＮＧＳ ＮＯＳエージェントに転送する。ＮＧＳは適切なリソースを割当て、
この命令を受け取った順番に実行する。ＮＧＳ ＮＯＳエージェントは収集した
ＤＴＭＦディジットを、ステップ１１７２に示されているように、その後ＣＬＰ
を介して１８Ｃ ＳＬＰに転送するためにＬＬＰに送る。ＤＴＭＦディジットは
オペレータオプションを、たとえば（０）が選択されたことを表すことを理解し
てください。

【０３４５】 次に、ステップ１１７５、図２８（ａ）、および図２６（ａ）〜２６（ｇ）に
関してここに詳細に示されているように、１８Ｃ ＳＬＰはリソース／機能（す
なわちオペレータ）を１８Ｃ＿ＱＡ ＳＬＰ ７００から要求し、ＱＡは１８Ｃ
ＳＬＰに終了処理を開始するように要求されたライン情報をオペレータ回線に
戻す。オペレータ着信を受け取った後、オペレータ端末ノード位置検索はオペレ
ータ回線アウトダイアル処理の一部として実行される。この処理は１８Ｃ ＳＬ
Ｐにオペレータ着信位置データベースの論理データベース名をＮＴに送らせて名
前の翻訳をしてもらい、ＮＴに実際のオペレータ着信位置ＤＢ名をＤＭから要求
させ、ＤＭに実際のオペレータ着信位置ＤＢ名およびその保管場所をＮＴに送ら
せ、ＬＲＭを参照して着信位置ＤＢがローカルで使用可能であるかどうかを突き
止め、物理ＤＢアドレスをＮＴに戻し、オペレータ着信位置ＤＢの物理アドレス
を１８Ｃ ＳＬＰに渡すといったステップを必要とする。１８Ｃ ＳＬＰは要求
をＤＭに送ってオペレータ着信位置（ノード）を調べ、ＤＭはこのオペレータ着
信位置を１８Ｃ ＳＬＰに戻す。たとえば、このシナリオでは、端末ノードは起
点ノード以外のものである。

【０３４６】 ここでステップ１１７６、図２８（ｂ）を参照し、１８Ｃ ＳＬＰは応答通知
付きアウトダイアル命令をＣＬＰに転送し、ＮＧＳ ＮＯＳエージェントに転送
する。このアウトダイアル命令は端末ノード情報を含む。これが監視されたアウ
トダイアルであるため、話中、応答なしまたは応答の指示はＮＧＳから送り返さ
れなければなれない。１８Ｃ ＳＬＰは実行し続ける。

【０３４７】 その後、次の２つの処理、すなわち、１） ステップ１１７８に示されている
ような、発呼者Ａとオペレータの間のボイスリンクを設定する処理、および２）
ステップ１１７９に示されているような、発呼者Ａとオペレータ間のデータリ
ンクを設定する処理、が同時に実行されるのが好ましい。

【０３４８】 ステップ１１７９のデータリンクの設定に関しては、起点ノードのオペレータ
回線のＬＬＰはインスタンス生成がなされ、このラインに対応づけられたプロフ
ァイルの検索がここに示されている要領で実行される。たとえば、ＣＬＰは起点
ノード位置およびオペレータＬＬＰの論理名をＮＴに送り、インスタンス生成が
行われるようにする。オペレータノードの位置はアウトダイアルに先立って検索
中に判断された。ＮＴはオペレータＬＬＰ論理名をデータ管理に送り、データ管
理が実際のＬＬＰ名とそれが保管されている場所のアドレスを戻す。ＮＴはリソ
ース管理（ＮＲＳ）システムに照会し、この呼出しが着信しているノードが存在
し、作動状態にあるかどうかを確認する。ＮＲＳは着信／オペレータノードの状
態をＮＴに戻す。ローカルノードのＮＴはリモートノードのＮＴにオペレータＬ
ＬＰのインスタンス生成を行うよう要求する。オペレータノードのＮＴはＬＲＭ
に照会し、ＬＬＰにすでにこのオペレータ回線用のインスタンス生成がなされて
いるかどうかを確認する。それがなされていない場合は、ＬＬＰのインスタンス
生成が行われる。オペレータノードのＬＲＭはオペレータ回線用のＬＬＰが実行
しているＳＬＥＥアドレスをＮＴに戻す。オペレータノードのＮＴは呼出しデー
タをオペレータ回線のＬＬＰに送る。端末ノードのＮＴは着信ライン用のＬＬＰ
を実行しているＳＬＥＥのアドレスを起点ノードのＮＴに送る。起点ノードのＮ
Ｔはオペレータ回線用のＬＬＰを実行しているＳＬＥＥのアドレスをＣＬＰに送
る。データベースの検索により、ＤＭもオペレータ回線情報をＬＬＰに戻す。こ
のシナリオでは、着信ライン（オペレータ）の機能はない。

【０３４９】 ステップ１１７８でのボイスリンクの設定に関しては、次のステップが実行さ
れる。そのステップにはアウトダイアル（起呼者Ａからオペレータへ）用の命令
、および応答通知の受領が含まれる。ＣＬＰはこのアウトダイアル命令を発信Ｌ
ＬＰに転送し、この発信ＬＬＰが応答通知付きアウトダイアル命令をＮＧＳ Ｎ
ＯＳエージェントに転送する。ＮＧＳはアウトダイアルを配置する。ＥＬＰはア
ウトダイアルデータをフォーマッティングおよび転送用のデータ管理に書き込む
。ＮＧＳ ＮＯＳエージェントは応答通知を発信ラインのＬＬＰに送り、このＬ
ＬＰがこの応答通知をＣＬＰに転送し、ＣＬＰがこの応答通知を１８Ｃ ＳＬＰ
に転送する。１８Ｃ ＳＬＰはこの応答通知がこの電話に留守番電話でなく、人
間が出た徴候であると判断する。これで発呼者に電話がつながる。

【０３５０】 図２８（ｂ）の次のステップ１１８０は、ＮＧＳに命令し、起呼者Ａをオペレ
ータにつなぎ、起呼者Ａが誰にアウトダイアルすべきかの情報を持つオペレータ
からの命令を待つ。このデータはオペレータＬＬＰを介して１８Ｃ ＳＬＰに送
られる。これらのステップが完了した後、起呼者Ａとオペレータは１８Ｃ ＳＬ
Ｐが実行している状態で会話をすることができる。特に、１８Ｃ ＳＰＬはブリ
ッジパーティー命令をＣＬＰに転送し、ＮＧＳ ＮＯＳエージェントに転送させ
る。さらに、この命令はブリッジがなされる（オペレータと起呼者Ａ）ラインの
ライン識別子である。ＣＬＰはこの命令を発信ＬＬＰに転送され、この発信ＬＬ
Ｐがこのブリッジパーティー命令をＮＧＳ ＮＯＳエージェントに転送する。こ
のＮＧＳ ＮＯＳエージェントは命令完了通知をＬＬＰに送り、さらに１８Ｃ
ＳＬＰに転送する。この命令完了通知はＬＬＰからＣＬＰに転送され、ＣＬＰが
この命令を１８Ｃ ＳＬＰに転送し、オペレータと起呼者Ｃがブリッジされてい
ることを示している。

【０３５１】 ステップ１１８２に示されているように、オペレータは次に命令をＬＬＰを介
し、起呼者Ａが当事者Ｃにアウトダイアルするのに必要な情報（たとえば、宛先
番号など）を含む１８Ｃ ＳＬＰに送る。

【０３５２】 ステップ１１８４は入力され、直接ダイアルディジット（ＤＤＤ）の妥当性検
索を実行し、入力されたＤＤＤに対してＬＩＤＢ ＤＢ検索を実行し、ライン（
当事者Ｃのライン）に請求可能かどうかを判断する。たとえば、これは１８Ｃ
ＳＬＰに論理ＬＩＤＢ ＳＬＰを名前翻訳するＮＴに送り、ＮＴに論理ＬＩＤＢ
ＳＬＰ名をＤＭに送り、ＮＲＳに照会し、場所とノード状態に基づいてＬＩＤ
Ｂ ＳＬＰを実行できる最良のノードを判断する。ＤＭＡＰＩを介し、ＳＬＰは
サービスまたはデータをＤＭローカルキャッシュから要求することができること
が理解できる。ＮＲＳは選択ノードをＮＴに戻し、ローカルノードのＮＴがリモ
ートノードのＮＴにＬＩＤＢ ＳＬＰのインスタンスを生成するよう要求する。
リモートノードのＮＴはさらにＬＲＭに照会し、ＬＩＤＢ ＳＬＰのインスタン
スがすでにこのノードに生成されているかどうかを判断する。生成されていない
場合は、これがＳＬＰにインスタンスを生成する。リモートノードのＬＲＭはさ
らに照会データをＬＩＤＢ ＳＬＰに転送する。この照会は１８Ｃ ＳＬＰの戻
りアドレスを含む。ＬＩＤＢは最初に照会データをフォーマットして適切なフォ
ーマットに応答し、この照会をＬＩＤＢデータベースのゲートウェイに転送する
。このＬＩＤＢ照会は実行され、その結果が１８Ｃ ＳＬＰに戻される。

【０３５３】 次に、ステップ１１８６で、被呼加入者Ｃの端末ノード検索が実行され、被呼
加入者Ａは待たされます。これは、たとえば、次のようなステップを必要とする
。１８Ｃ ＳＬＰが着信場所データベースの論理データベース名を名前翻訳のＮ
Ｔに送るのを可能にし、ＮＴが実際の着信場所ＤＢ名をＤＭから要求するのを可
能にし、ＤＭが実際の着信場所ＤＢ名およびその保管場所をＮＴに送るのを可能
にし、ＮＴにＬＲＭの照会を受け、着信場所ＤＢがローカルで使用可能であるか
どうかを調べ、使用可能であればＬＲＭに物理ＤＢアドレスをＮＴに送り戻し、
ＮＴに着信場所ＤＢの物理アドレスを１８Ｃ ＳＬＰに渡し、それによって１８
Ｃ ＳＬＰが要求をＤＭに送って発呼者が入力したＤＤＤの着信場所（ノード）
を調べ、端末ノードを１８Ｃ ＳＬＰに戻すことができるようにする。このシナ
リオでは、端末ノードは起点ノード以外のものである。

【０３５４】 被呼加入者Ａを待たせ、アウトダイアルを実行するには次のステップを必要と
する。１８Ｃ ＳＬＰに「発呼者を待たせる」命令をＣＬＰに転送させ、ＮＧＳ
ＮＯＳエージェントに転送させる。加えて、この命令は待たされるラインのラ
イン識別子である。ＣＬＰはこの命令を発信ＬＬＰに転送し、ＬＬＰが発呼者を
待たせる命令をＮＧＳ ＮＯＳエージェントに転送する。ＮＧＳは発呼者を待た
せる。その後、ＮＧＳ ＮＯＳエージェントは命令収集通知をＬＬＰに送り、そ
の後ＣＬＰを介して１８Ｃ ＳＬＰに転送する。これは１８Ｃ ＳＬＰに対し、
発呼者が待たされていることを知らせるものである。１８Ｃ ＳＬＰは応答通知
付きアウトダイアル命令をＣＬＰに転送し、ＮＧＳ ＮＯＳエージェントに転送
させる。このアウトダイアル命令は端末ノード情報を含む。

【０３５５】 ステップ１１８９でのデータリンクの設定は端末ノード上の着信ライン（当事
者Ｃ）のためのＬＬＰのインスタンス生成およびこのラインに関連するプロファ
イルの検索を含む。たとえば、これはＣＬＰが端末ノード位置および着信ＬＬＰ
の論理名をＮＴに送り、ＮＴがインスタンス生成できるようにすることを可能に
する必要がある。端末ノードの場所はアウトダイアル前の検索時に確認され、Ｎ
ＴにＬＬＰ論理名をデータ管理に送らせ、データ管理が実際のＬＬＰ名とそれが
保管されている場所のアドレスを戻し、ＮＴにＮＲＳを照会させ、この呼出しが
着信しているノードが存在し、動作状態にあるかどうかを判断し、ＮＲＳが端末
ノードの状態をＮＴに戻す。ローカルノードのＮＴはリモートノードのＮＴに着
信ＬＬＰのインスタンス生成を行うよう要求する。端末ノードのＮＴはＬＲＭに
照会し、ＬＬＰがこの着信ラインのインスタンス生成をすでに行ったかどうかを
確認する。行っていない場合は、これがＬＬＰのインスタンス生成を行う。端末
ノードのＬＲＭは着信ラインのＬＬＰが実行しているＳＬＥＥアドレスをＮＴに
戻し、端末ノードのＮＴは呼出しデータを着信ラインのＬＬＰに送る。端末ノー
ドのＮＴは着信ラインのＬＬＰを実行しているＳＬＥＥのアドレスを起点ノード
のＮＴに送る。起点ノードのＮＴは着信ラインのＬＬＰを実行しているＳＬＥＥ
のアドレスをＣＬＰに送る。

【０３５６】 プロファイル検索は着信ＬＬＰにライン情報データベースの論理データベース
名を名前翻訳のＮＴに送ってもらう必要がある。ＮＴは実際のライン情報ＤＢ名
を、実際のライン情報ＤＢ名とその保管場所をＮＴに送るＤＭから要求する。Ｎ
Ｔはライン情報ＤＢがローカルで使用可能であるかどうかをＬＲＭから判断する
。ＬＲＭは物理ＤＢアドレスをＮＴに送り返し、ＮＴはライン情報ＤＢの物理ア
ドレスを着信ＬＬＰに渡す。着信ＬＬＰは要求をＤＭに送り、顧客着信ライン情
報を調べる。ＤＭは顧客ライン情報をＬＬＰに戻す。このシナリオでは、着信ラ
インには機能がないと仮定している。

【０３５７】 ステップ１１８８でのボイスリンクの設定に関しては、ＣＬＰはアウトダイア
ル命令を発信ＬＬＰに転送し、発信ＬＬＰは応答通知付きアウトダイアル命令を
ＮＧＳ ＮＯＳエージェントに転送する。ＮＧＳはアウトダイアルをする。この
一部として、ＥＬＰはアウトダイアルデータをデータ管理に書き込み、フォーマ
ッティングと転送をしてもらう。ＮＧＳ ＮＯＳエージェントは応答通知を発信
ラインのＬＬＰに送り、このＬＬＰがこの応答通知をＣＬＰに転送し、ＣＬＰが
この応答通知を１８Ｃ ＳＬＰに転送する。１８Ｃ ＳＬＰは応答通知が留守番
電話ではなく、人間が電話に出た指示であると判断する。

【０３５８】 次いで、ステップ１１９０に示すように、ＮＧＳに、オペレータを通話者Ｃに
接続せよ、というコマンドを送る。この際、１８Ｃ ＳＬＰに“Bridge Parties
(通話者接続)”コマンドをＣＬＰへ、さらにＮＧＳ ＮＯＳエージェントへと転
送するというステップが必要である。コマンドと共に、接続される回線（オペレ
ータと通話者Ｃ）の回線特定装置も必要である。ＣＬＰはコマンドを発信ＬＬＰ
へと転送し、発信ＬＬＰは通話者接続コマンドをＮＧＳ ＮＯＳエージェントへ
と転送する。ＮＧＳ ＮＯＳエージェントはコマンド完了信号をＬＬＰへと送信
し、これは追って１８Ｃ ＳＬＰへと送信される。コマンド完了信号はＬＬＰか
らＣＬＰへと転送され、ＣＬＰは、オペレータと通話者Ｃとが接続されたことを
示す信号を１８Ｃ ＳＬＰへと転送する。

【０３５９】 これらのステップが完了すると、オペレータと通話者Ｃとは会話状態に、通話
者Ａは保留状態になり、１８Ｃ ＳＬＰは作動を続ける。通話者Ｃが通話者Ａか
らのコレクトコールを承諾するものと仮定すると、次のステップ１１９２ではＮ
ＧＳが通話者Ｃとオペレータとの接続を切断する必要がある。この過程は、例え
ば、ＣＬＰが発信ＬＬＰへとコマンドを転送し発信ＬＬＰが“Brake Bridge(接
続切断)”コマンドをＮＧＳ ＮＯＳエージェントへと転送する過程、追って１
８Ｃ ＳＬＰへと送信されるコマンド完了信号をＮＧＳ ＮＯＳエージェントが
ＬＬＰへと送信する過程、ＬＬＰからＣＬＰへとコマンド完了信号を転送し、通
話者Ｃとオペレータとの接続が切断されたことを示すコマンド完了信号をＣＬＰ
が１８Ｃ ＳＬＰへと転送する過程を含む。

【０３６０】 続くステップでＮＧＳは、発呼者（通話者Ａ）を保留状態とし、図２８ｂにお
けるステップ１１９４で示すように、発呼者（通話者Ａ）と被呼者（通話者Ｃ）
とを接続する。通話者Ａと通話者Ｃとの接続が完了した後、１８Ｃ ＳＬＰは停
止する。始めに、１８Ｃ ＳＬＰは、“Take Caller off Hold/Bridge Calls”
コマンドをＣＬＰへと転送し、これがＮＧＳ ＮＯＳエージェントへと転送され
る。ＣＬＰは、この要求を発信回線のＬＬＰへと転送し、ＬＬＰはこのコマンド
をＮＧＳ ＮＯＳエージェントへと転送する。このコマンドで接続されるべき回
線が特定される。ＮＧＳ ＮＯＳエージェントはコマンド完了信号をＬＬＰへと
送信し、これは追って１８Ｃ ＳＬＰへと転送される。このコマンドは、ＬＬＰ
からＣＬＰへと転送され、ＣＬＰは１８Ｃ ＳＬＰへと転送して通話者Ａと通話
者Ｃとの接続が完了したことを知らせる。

【０３６１】 続くステップでは、通話の完了１）ＬＬＰがスイッチにおいて通話完了信号を
ＮＧＳ ＮＯＳエージェントから受信し、ＬＬＰは通話完了信号をＣＬＰへと転
送し、ＣＬＰは通話完了信号を関係する全てのＳＬＰへと転送し、これによって
ＳＬＰが停止する。次いで、ＣＬＰが停止する。ＣＬＰから通話完了信号を受信
すると、ＥＬＰが通話情報（通話記録）をＤＭに記録し、停止する。すなわち、
ＥＬＰの停止前に、通話完了後に保持されるべきＥＬＰ通話詳細データ、例えば
請求及びその他の情報が、まず蓄積される。

【０３６２】 本発明のシステムはさらに、バーチャルネットワーク（“Vnet”）及びインテ
リジェントネットワークにおける非同期転送モード（“ATM”）通話サービスを
支援する。標準的なＡＴＭ技術によれば、図３１ａに示すような共用ＡＴＭネッ
トワーク１５１０が、発信元１５１５ａから来る５３バイト固定長パケットのビ
デオ画像、データ、音声を、宛先１５１５ｆへと、一連のＡＴＭスイッチ１５２
０ａ〜ｇ及び相互接続リンク１５１６，１５１７を介して転送、回送する。単一
ネットワーク上でマルチメディア信号を伝達可能であることにより、ＡＴＭはＢ
−ＩＳＤＮサービスに好適である。非同期転送モードプロトコールは接続優先で
あり、ＡＴＭ“通話”信号は、発信者から受信者へと配索されたバーチャル接続
を介して、セル（cell）として回送される。

【０３６３】 図３１ａに示すＡＴＭバーチャルプライベートネットワーク（VPN）体系１５
００は、顧客サイト１５１５ａ〜ｆと、ＡＴＭスイッチ１５２０ａ〜１５２０ｇ
を有する供給複合体（resource complexes）と、ＮＧＩＮサービスノードとを備
えている。サービスノードのうちの２つ２０４ａ，ｂは、ＡＴＭ通話を受信可能
なＮＧＳ供給複合体を有し、１または複数のＮＧＩＮサービス制御要素（例えば
、ＳＬＥＥを実行するサービス制御サーバー）が設けられている。特に、各サー
ビスノードにおけるＳＬＥＥは、例えば、ＳＬＰを実行しＡＴＭネットワークを
介してＶnet/ＶＰＮサービスを提供し、特に、ＡＴＭ共用ネットワーク機能を履
行する。ＳＬＥＥがＳＬＰを実行し、従来の回路スイッチネットワークを介して
Ｖnet/ＶＰＮサービスを提供することも理解されたい。

【０３６４】 好ましい実施形態において、ＮＧＩＮシステム１０００は、次のようなＡＴＭ
サービス及びバーチャルプライベートデータネットワークサービスを提供する。
１）発信元アドレススクリーニング：禁じられた宛先へ発呼者が発信するのを防
止すること、例えば、顧客がネットワーク外部へ発信することを防止しネットワ
ーク内部交信に限定すること、すなわち、特定の発信者が特定の宛先に発信する
ことを防止することにより、顧客のバーチャルプライベートネットワークのセキ
ュリティーを提供する。この種のスクリーニングでは、発信が完了する前に、例
えばＤＭキャッシュに設けられた宛先の許可または不許可リストと発信者との関
係がチェックされる。２）宛先アドレススクリーニング：契約者の発信通話が宛
先に配送されるのを防止することにより上記と類似のセキュリティーを提供する
。この機能は、この機能を使用する顧客をネットワーク内の特定の宛先に安全に
接続することによってプライベートネットワークの健全性を保護するために、発
信元スクリーニングと同様に用いられる。この種のスクリーニングでは、宛先が
許可または不許可のリストに分類され、通話が宛先に配送される前に、このリス
トがチェックされる。３）閉鎖型ユーザーグループ：この機能は、バーチャルプ
ライベートデータネットワークの顧客を限定するものである。閉鎖型ユーザーグ
ループ内から発信された通話は、同じく閉鎖型ユーザーグループ内の宛先のみに
接続される。

【０３６５】 さらに、ＮＧＩＮは、ＡＴＭコールセンターの機能を支援する。これには、次
のような機能が含まれるが、これらに限定されるわけではない。１）１日におけ
る指定時刻回送：１日におけるどの時刻に発信したかによって、“Setup”また
は“Add Party”信号において指定されたアドレス（E.164において、またはＡＴ
Ｍエンドシステムアドレスフォーマットとして）を、別のアドレスに変更する。
２）１週間における指定日回送：１週間におけるどの日に発信したかによって、
“Setup”または“Add Party”信号において指定されたアドレス（E.164におい
て、またはＡＴＭエンドシステムアドレスフォーマットとして）を、別のアドレ
スに変更する。３）パーセンテージ配分：“Setup”または“Add Party”信号に
おいて指定されたアドレスを、そのアドレスに行くように割り当てられた通話の
パーセンテージに応じて、別のアドレスに変更する。４）偶発対応回送プラン：
特定の宛先におけるコールセンターの人材の機能に大きな変化があった場合に、
使用する代替ＡＴＭ回送プランを顧客が指定できるようにする。例えば、顧客が
、指定時刻回送、指定日回送、パーセンテージ配分を行う通常の回送プランを３
つのコールセンターに対して使用しているとする。これらのコールセンターのう
ちの１つが偶発的に停止した場合、顧客はその状況に適した代替回送プランを指
定する。５）発信点依存回送：“Setup”または“Add Party”信号において指定
されたアドレスを、通話の発信点に応じて、別のアドレスに変更する。６）通話
保留：“Setup”または“Add Party”信号において指定されたアドレス（E.164
において、またはＡＴＭエンドシステムアドレスフォーマットとして）が現時点
で利用できない場合、ネットワークは、宛先が利用可能になるまで通話を保留し
たり、保留解除までの時間を限定したりする。宛先が利用可能になった場合、通
話が接続される。保留解除時間までに宛先が利用可能にならなかった場合、通話
は切断されるか、別の宛先へ転送される。７）ＡＡＬパラメータ設定に基づく回
送：“Setup”または“Add Party”信号は、ユーザー指定パラメータを許容する
。特定の種類の宛先を指定するために、これらのパラメータを使用することが可
能である。例えば、発呼者が、よく知られたビデオオペレータの番号に掛けた場
合、パラメータによって、例えばスペイン語を話すオペレータの必要性を認識さ
せることができる。

【０３６６】 加えて、ＮＧＩＮは、ＡＴＭ一番号サービス機能を支援する。これには、次の
機能が含まれる。１）追従サービス：特定の契約者に、あるアドレスが与えられ
た場合、契約者はそのアドレスに関係した宛先を変更するかもしれない。この機
能によれば、通話の場所が移動することにより契約者は通話を受けることができ
る。２）代替回送：宛先が利用可能でない場合、代替宛先を指定することができ
る。

【０３６７】 通話料金がチャージされるべき口座番号を特定するＡＴＭ適合パラメータの使
用、及びサービス種別に応じた契約管理を含む請求サービスも支援されている。
契約管理によって、契約者に対する契約種別が特定される。すなわち、契約者が
ＡＴＭネットワークプロバイダと契約した場合、契約者は、特定のサービス種別
に応じて支払いを行う。“Setup”または“Add Party”信号がある契約者から発
信された場合、その信号に関係するサービス種別パラメータがその契約者の契約
内容と比較される。請求サービスにはさらに、発信元アドレス照合が含まれる。
この機能は、“Setup”または“Add Party”信号において指定された発信元アド
レスが正しいかどうかの照合を行い、受信ポートでの使用を許可するものである
。この機能によって、被請求者が、実際に通話を行った者であるという保証が得
られる。

【０３６８】 以下、機能フローチャートである図３２ａ〜３２ｇを参照して、ＡＴＭ Ｖne
tサービス（“ATM/Vnet”）における処理と利用方法に関して説明する。始めに
、図３１ｂに示すように、まず、ATM/Vnet通話はＮＧＳスイッチ構造体であるＮ
ＧＳ１８０に到達する。ＮＧＳ１８０が通話を受信した場合、受信制御要素は、
通話を受信したアクセス回線を通じて通話制御信号を供給すると共に、Vnet #、
ＡＮＩ、回線ＩＤ、ネットワーク通話ＩＤ、発信元スイッチ幹線、及びその他通
話処理に必要なデータを供給する。ＮＧＳ通話制御は、プログラムされた論理に
従い、通話の状態モデルを維持する。加えて、状態モデルは、ＥＬＰ５４０を起
動し、図３１ｂに示すようにサービス要求をＦＤ５１０へと送るためのトリガー
を含む。ＥＬＰを起動するために、ＮＧＳ通話制御要素は、ここに記載したよう
なＥＬＰのための論理名を用いて、メッセージをＮＮＯＳへ送る。ＮＮＯＳはそ
れに応じて、サービス管理対象にメッセージを送ってＳＬＥＥ内でＥＬＰを起動
させ、ＥＬＰの対象リファレンスを通話制御へと戻す。ＮＧＳ通話制御要素は、
ＳＬＥＥ内のＦＤに送信された要求メッセージに含まれるこの対象レファレンス
を含む。こうして、全ての工程で通話のために生成されたイベント認証データは
、起動したＥＬＰ工程に書き込まれる。特に、サービス要求メッセージはＦＤの
ための論理名に送られ、この論理名は、ＮＮＯＳ ＮＴ要素によって、ＦＤ論理
プログラムのための物理的アドレスに変換される。ＦＤ論理プログラムは、通話
が受信されたのと同一のサービスノードで作動する。サービス要求メッセージに
は、Vnet #、ＡＮＩ、及びその他のデータが含まれる。

【０３６９】 次に、ＦＤは、それが有する特徴識別表を用いて、受信したサービス要求を処
理するべきＳＬＰを特定する。Vnetサービスを例に挙げれば、これはATM_Vnet_S
LPによって処理されることになる。以下に示す表は、種々の“Vnet”通話サービ
スへのポインタを含む入口を備えたＦＤ表の一部の例である。 入口ポート表 A001001" SLPポインタ 'ATM_Vnet' A001002" FGD表への表ポインタ ＦＧＤ表 Vnet1*表ポインタ Vnet1表 Vnet2*表ポインタ Vnet2表 Vnet3*表ポインタ Vnet3表 Vnet1表 'ATM_Vnet_SLP'へのVnet SLPポインタ ここで、ＦＧＤは特徴グループ識別装置（Feature Group Discriminator）を意
味する。特に、ネットワーク内のどこで（どのスイッチボードで）通話が発信さ
れたか、及び受信された通話のタイプに基づいて、ＦＤは、ここに記載の方法で
適切なＳＬＰ論理名を決定する。例えば、識別A001002"は、ＦＧＤ表における検
索を要求している（ＦＧＤ表へのポインタ）通話を受信したことを示している。
ＦＧＤ表は、掛けられた番号、例えばVnet*に応じて、ポインタを他の表に振り
向ける。ここで、'*'は区切り文字である。このVnet表から、例えば、ＦＤは、
要求されて呼び出されるべきＳＬＰ論理名へのポインタを取得する。サービス要
求は、要求されたATM/Vnetサービスに従って対象ＣＬＰ５４５、対象ＬＬＰＯ５
３０、及び対象ＳＬＰ５２０を起動するＮＮＯＳへと渡される。これらの対象を
起動するためには、例えば既述したようにローカルＳＬＥＥ負荷のような種々の
要因に基づいて最適な選択を行うＮＮＯＳ ＬＲＭ機能を利用することが必要で
ある点を理解されたい。例えば、ＬＬＰＯに関して言えば、ＬＬＰＯに対する論
理名が、通話を受信した受信制御回線に基づいてＮＮＯＳへと供給される。この
回線の特定は、ＡＮＩまたはＮＧＳ受信制御要素によって特定されたアクセス回
線によって行われる。ＡＮＩは、通話を発信したオリジナルアクセス回線を特定
する。この回線は、ＮＧＳが通話を受信したアクセス回線と同じである場合も、
異なる場合もある。すなわち、受信された通話は、例えば、ローカルネットワー
クで発信され、相互交換キャリアネットワーク上のスイッチ構造体に送られたも
のであるかもしれない。従って、通話待ちまたは通話中断といった回線に関係し
た特徴は、ＡＮＩによって特定される可能性がある。ＮＮＯＳは、ＬＬＰＯに対
する論理名をＬＬＰＯ起動のための物理的アドレスに変換する。他の論理プログ
ラム（例えばＳＬＰ）が他の場所で起動している際に、関連する回線が存在する
場所においてＬＬＰが起動される。起動すると、ＬＬＰＯは、回線に関連した状
況のためのデータ管理を要求し、発信回線の状態を維持し、通話待ち、またはオ
ーバーフロー回送のような状況が発呼者（すなわち通話待ち）またはネットワー
ク（すなわちオーバーフロー回送）において生じた際には、それら全ての状況を
取り込む。ATM/Vnetに関連して、ＬＬＰは、回線が特定のバンド幅でＡＴＭ通話
を処理できるかどうかを、ＤＭから要求する場合がある。

【０３７０】 ＮＯＳは、呼び出されるべき特定のサービス、例えばATM_Vnetを含む状況識別
要素からサービス要求移管要求を受信する。ＮＯＳは、要求が論理名を含むこと
を確認し、関連する表（図示せず）を参照して、そのサービス要求に利用可能な
ＳＬＰ処理が表に含まれているかどうかを確認する。ＮＯＳはまた、ＮＮＯＳ
ＬＲＭ機能を通じて要求のタイプを特定する。こうして、ＮＯＳは、要求Vnetが
起動していない場合、これを呼び出すために、サービス制御ＳＬＥＥ上で作動す
るサービス管理対象へと要求を送信する。好ましい実施形態では、ＮＮＯＳは、
ＮＧＳからオリジナルサービス要求信号を受信したサービス制御サーバーからＳ
ＬＰを選択する。しかしながら、ＮＮＯＳは、ＮＯＳ ＬＲＭ機能を利用するこ
とによって、いかなるサービス制御要素内のＳＬＰをも選択可能であることを理
解されたい。次いで、ＮＯＳは、選択されたＳＬＰが既に起動しているかどうか
を確認し、もし選択されたＳＬＰがまだ起動していなければ、スレッド（thread
）を起動するATM_Vnetサービスエージェント対象を含むＳＬＰ対象を起動するよ
うにＳＭに指令を出す。選択されたＳＬＰが既に起動している場合、スレッド管
理要素がＳＬＰ対象に新たな処理スレッドを割り当てる。次いで、起動したATM_
Vnet ＳＬＰは、その物理的アドレスをＮＯＳに登録し、ＮＯＳは、このＳＬＰ
をサービス要求に割り当てる。次に、ＮＯＳは、サービス要求移管メッセージを
、新たなATM/Vnet SLPに送る。サービス要求移管メッセージには、サービス要求
が発信された時刻、要求が発信されたスイッチのＩＤ、通話が発信されたポート
のＩＤ、通話が発信された端末装置のＩＤ、発呼者の番号、被呼者の番号といっ
た情報を含む関連の初期アドレスメッセージ（“IAM”）が含まれる。さらに、
ＩＡＭメッセージには、要求されたサービスのクラス、バンド幅、ＡＴＭのサー
ビス種別（ＱｏＳ）パラメータなどを含む要求されたＡＴＭセットアップパラメ
ータが含まれる。この情報は、ATM/Vnet通話が、ネットワークの状態、及び契約
者のユーザープロファイルに基づいて回送されるかどうか特定するために使用さ
れる。ＩＡＭメッセージの受信に加えて、ＮＮＯＳは、起動したＳＬＰ対象、Ｅ
ＬＰ対象、ＬＬＰＯ対象に対する対象リファレンスを含む全てのサービス関連デ
ータを起動したＣＬＰへと送る。ＣＬＰ、ＥＬＰに対する対象リファレンスは、
ＬＬＰＯ及び（ATM/Vnet）ＳＬＰにも送られ、こうしてＳＬＰ及びＬＬＰＯは、
ＣＬＰ及びＥＬＰと接続される。最後に、ステップ１５４に示すように、ATM/Vn
et SLPは、プログラム論理に従って通話を処理する。

【０３７１】 ATM/Vnet通話に関連して、ATM/Vnet SLP５２０は、適切な決定を行うために、
必要なデータを一または複数のATM/Vnetデータベース（図示せず）に要求してこ
れを取得することが望ましい。図３２ｃ〜３２ｇに示すように、ATM/Vnet SLP５
２０は、以下のステップを実行する。

【０３７２】 ATM_Vnet_SLPサービススレッド１６００が既に起動していると仮定した場合、
図３２ａにおける第１ステップ１６０２は、Vnetサービス要求イベントメッセー
ジがＦＤまたは直接ＮＧＳから受信されるまで待機する段階を示し、ステップ１
６０４は、受信した通話がVnet通話であるかどうかを決定する段階を示している
。説明したように、起動された（サービス要求イベント、サービス要求イベント
）クラスは、ＮＧＳからＮＧＩＮへと初期サービス要求を伝達する方法を含む。
好ましくは、SIBBWait.javaクラス（SIBB）が、ATM/Vnet通話を待つために、そ
して、サービス要求イベントから情報を抽出し、Vnet通話が受信された際に、Vn
et通話に関係した通話関連対象へ送るために呼び出される。好ましくは、通話関
連対象は、特定の通話に関係する情報を保存するハッシュ・テーブルアレイ内の
キーバリュー対を操作するために、設置方法、取得方法、除去方法を利用する。

【０３７３】 次に、ステップ１６０８に示すように、ATM/Nnet通話に関連したメッセージが
受信されると、SLP Vnetプロセスは、通話特定要素、例えばスレッドＩＤ及びＳ
ＬＰ対象レファレンスと共にモニタリリースイベントメッセージをＮＧＳに送る
。これは、SIBBSendMsg.java（SIBB）を呼び出し、メッセージを交信するために
ＳＬＰで使用することによって実現される。特に、モニタリリースイベントメッ
セージは、基本クラスのNGINイベントを拡張したパブリッククラスであり、ＮＧ
Ｓが解除信号を例えば通話発信者から受信した場合には、ＮＧＩＮに転送すべき
であることをＮＧＳに知らせる。

【０３７４】 次に、ステップ１６１２に示すように、Vnet発信ユーザーのＩＤ特定が行われ
る。この段階は、SIBBDBR.java（SIBB）呼び出し、電話番号に関連して発信ユー
ザーＩＤがないかどうかを確認するためのデータベース検索を行うことを含む。
電話番号に関連して発信ユーザーＩＤがない場合には、ステップ１６１３に示す
ように処理は停止し、発信ユーザーＩＤが発見されなかったことを示す適切なメ
ッセージがＮＧＳへと送られる。発信ユーザーＩＤが発見された場合には、宛先
ユーザーＩＤを特定するために、同様の工程が呼び出される。宛先ユーザーＩＤ
が発見されなかった場合には、宛先ユーザーＩＤが発見されなかったことがＮＧ
Ｓに伝えられ、ステップ１６１３に示すように、通話は停止される。

【０３７５】 目的先のユーザIDが見つかったら、つぎに図３２（ａ）にステップ１６１５で
示すように、発信源アドレス識別（“ＳＡＳ”）機能が実行される。特に、ATM Vnet SLPは、発信源アドレスを確認するとともに、ATMセットアップメッセージ
のパラメータがカスタマーの同意の範囲内にあることを確認するためにデータベ
ース照会を開始する。このため、発信源アドレス識別手順は、発呼メッセージの
ポートIDおよびターミナル装置のIDが固有のユーザIDと一致しているかどうかを
確認するブール表示器に戻されるよう、SIBBDBR.java法を介して呼び出される。
これは、使用権のない発呼者によってVnetネットワーク内でデータのやりとりが
なされるのを防止するためである。発信源アドレスの識別を与えるSIBBDBR.java
法の手法には以下のステップが備わっている。１）ATM Vnet SLPが発信源アドレ
スデータベース名をNNOS NTに要求する；２）NNOS NTが実際の発信源アドレスデ
ータベース名をDMに要求する；３）DMが実際の発信源アドレスデータベース名に
送られるとともに、それがNNOS NTのある場所に貯蔵される；４）NTは、発信源
アドレスデータベースが局所的に利用でき、かつNNOS LRMが物理的データベース
アドレスをNTに戻すかどうかを見つけるLRM機能を確認する；５）NNOS NTが発信
源アドレスデータベースの物理的アドレスをATM Vnet SLPに通す；６）ATM Vnet
SLPは、発信源アドレスが有効なものであり、かつセットアップメッセージにお
いて指定した帯域幅がカスタマの同意とあっているかどうかを決定するDMを確認
する。セットアップメッセージのパラメータ（たとえば帯域幅）は現在のネット
ワーク利用に対するカスタマーの同意に対して実証されているものと想定される
。最後に、DMはブールの応答をATM Vnet SLPに戻す。

【０３７６】 図３２（ａ）のステップ１６１７に示すように、間違いが戻された場合、すな
わちSASテストが失敗した場合、つぎにそのプロセスは終了される。ステップ１
６２０で示すように、これは有限メッセージ（Terminatイベント.java）を、分
解結合プロセスを開始するためSIBBSendMsg.javaを介してNGSに送ることを含ん
でいる。ステップ１６２２で示すように、この時点でこの呼び出しに関連する蓄
積された呼び出し文脈データがつぎの使用のために呼び出し文脈対象あるいはデ
ータベースに貯蔵され、かつそのプロセスは終了される。図３２（ａ）〜図３２
（ｆ）に示すように、ATM Vnet SLPプロセスの間の異なる時間において、呼び出
し文脈データが呼び出し文脈対象、たとえば上述したELPおよび／またはデータ
ベース構造に書きこまれ、これにより適切な呼び出し記録が“実行（cc）”呼び
出しで示すように維持されることに留意すべきである。ステップ１６２２で示す
ように、DM（データベース）に記憶機構を割り当てるとともに、呼び出しに対し
て蓄積された呼び出し文脈データをデータベースに書き込むため、SIBBDBInsert
.java（SIBB）が実行される。

【０３７７】 SASが成功しかつブール真値がステップ１６１７で決定されるよう戻されると
、つぎに図３２（ａ）のステップ１６１８で、ATM Vnet SLPは、発信ユーザIDが
呼び出しを呼び出した相手先に置くことができるかどうかを確認するため、閉ユ
ーザグループ識別（“CUGS”）手順を実行する。CUG識別を行う代わりにあるい
はCUG識別を行う前に、あて先が呼び出しの発信者に対して確実に終了している
ことを識別するため、あて先識別が実行され得ることに留意しなければならない
。

【０３７８】 図３２（ｂ）に示すように、CUGSプロセスはSIBBDBR.javaを実行することによ
ってDMCUGS識別データベース内のデータベース問いかけを実行する為の第１ステ
ップ１６２５を備えている。問いかけの結果として、発信者IDが、発信したグル
ープの一部であるあて先を呼び出すための許可証を有する発信グループの一部で
あることを示すのに、発信者IDブールの結果が戻される。したがってステップ１
６２８で、戻されたブール結果が、CUGSが成功することを真に示すものであるか
どうかについてなされる。このステップが成功せず、すなわちCUGSテストを失敗
した場合、つぎにプロセスは図３２（ｃ）に示すステップ１６２０に戻されて、
分解結合プロセスを開始するためSIBBSendMsg.javaを経由してNGSにメッセージ
を送るとともに、割り当てられたデータベース構造に蓄積された呼び出し文脈デ
ータを書き込む終了手順が実施される。

【０３７９】 CUGSが成功しかつ真がステップ１６２８に戻されると、図３２（ｂ）に示すス
テップ１６２９で、Vnet SLPは呼び出しがある現時点でのルーチンプランの選択
を得るためにYear Routing（TOY Routing）手順の時間を実行する。

【０３８０】 図３２（ｃ）に示すように、NOSサービスから現時点を得るために、TOY Routi
ngプロセスはSIBBGetTime.javaクラスを呼び出すことを含む現時点を得る第１ス
テップ１６３０を備えている。つぎに、ステップ１６３３で示すように、データ
ベースの問いかけは、あて先ユーザID、日の現時点および呼び出されたパーティ
の好ましいルーチンの選択を検索するために、SIBBDBR.javaクラスを呼び出すこ
とによって年値の時点、あるいはゼロ表示すなわちルーチン選択の表示を使用す
るTOY Routingデータベースで実行される。したがって、ステップ１６３５で、
戻された結果が呼び出していないパーティのTOY Routing選択を表示するゼロで
あるかどうかについて決定がなされる。ステップ１６３８に示すように、選択が
ある場合、つぎにルートプラント関連したルート選択が実行される。

【０３８１】 ATM呼び出しに対するATMの文脈において、番号書き換えの必要性が全くないこ
とに留意されたい。しかしながら、Vnet呼び出しの他のタイプのものに対して、
番号書き換えが必要なときには、ATM VnetプロセスはNNOSが対象参照をDMによっ
て与えられたVnet番号書き換えデータベースに戻すことを要求する。一度、SLP
がデータベースの場所を受け取ると、論理的あて先のVnet番号に関連した物理的
アドレスを探すためにデータベースの問いかけが実行され、かつDMが物理的アド
レスを戻す。よって、終端プロファイルは、あて先がATMおよび指定した帯域幅
を取り扱うことができるかどうかを決定するのに使用される。つぎに、Vnet番号
書き換えは、割り当てられた呼び出し文脈データベースをDM内に置くためELP事
例に書き換えることができる。

【０３８２】 図３２（ｃ）のステップ１６３５に戻って、ゼロが好ましくないTOY Routing
のルート選択を示す方に戻された場合、つぎにプロセスは図３２（ｃ）に示すス
テップ１６３７に進み、そこでATM Vnet SLPは、呼び出しが置かれている現時点
によるルーチンプランの選択を得るために日ルーチンの時間（“TODRouting”）
手順を実行する。

【０３８３】 図３２（ｄ）に示すように、TODRoutingプロセスは、あて先ユーザID、キーと
して週の現在の日および日の時間値を使用するとともに呼び出されたパーティの
好ましいルーチンの選択を検索するためSIBBDBR.javaクラスあるいはゼロ表示す
なわちルーチン選択の非表示を呼び出すTOD Routingデータベースでデータベー
ス問いかけを実行する第１のステップ１６４０を備える。したがってステップ１
６４３で、戻された結果が呼び出したパーティTODルーチンの選択を表示するゼ
ロであるかどうかについて決定がなされる。図３２（ｄ）のステップ１６４８に
示すように、選択（戻されたものがゼロでない）がある場合、つぎにルートプラ
ント関連と関連したTODルートの選択が実行される。

【０３８４】 ステップ１６４３でTODRoutingルートの選択が戻されないと決定された場合に
は、プロセスは図３２（ｄ）のステップ１６４９に進み、そこでATM Vnet SLPは
呼び出された番号に基づく呼び出しのルーチンを開始する。

【０３８５】 図３２（ｄ）のステップ１６４８およびステップ１６４９を参照されたい。一
度ルートの選択が確かめられると、ATM Vnet SLPは、ルーチンの選択に基づいて
送られるべき呼び出しを切り換える決定のためのプロセスを実行する。したがっ
て図３２（ｅ）に示すように、つぎのステップ１６５１ではキーとしてルーチン
の選択を使用しかつ切換IDの形態で呼び出されたパーティの好ましいルーチンプ
ランを検索するためSIBBDBR.javaクラスあるいはゼロ表示すなわち切換IDが見つ
からないことの表示を呼び出すルーチンプランデータベースでデータベース問い
かけを実行する。つぎにステップ１６５３で、戻された結果が見つけた切換IDを
表示するかどうかまた呼び出しが一定順路にしたがってなされ得るかどうかにつ
いて決定がなされる。もし、切換IDが見つからない場合には、プロセスは図３２
（ａ）のステップ１６２０に進み、分解結合プロセスを開始するためにSIBBSend
Msg.javaを経由してNGSにメッセージを送るとともに、蓄積された呼び出し文脈
データを呼び出し文脈対象および／またはデータベース構造に書き込む。

【０３８６】 ステップ１６５３で、切換IDが戻される場合、つぎにプロセスはステップ１６
５５に進み、アウトダイヤル経路、すなわち切換およびルーチンプランの選択に
関連したトランクIDを決定する。したがって図３２（ｅ）において、つぎのステ
ップ１６５５ではキーとして切換IDを使用しかつ切換から出ていくトランクを検
索するためSIBBDBR.javaクラスあるいはゼロ表示すなわちトランクが利用できな
いことの表示を呼び出すアウトダイヤル・プラン・データベースでデータベース
問いかけを実行する。つぎにステップ１６５８で、戻された結果が見つけた出て
いくトランクを表示するかどうかまた呼び出しが一定順路にしたがってなされ得
るかどうかについて決定がなされる。

【０３８７】 ステップ１６５８で、出ていくトランクが見つけられなかったものとして決定
された場合、プロセスは図３２（ａ）のステップ１６２０に進み、分解結合プロ
セスを開始するためにSIBBSendMsg.javaを経由してNGSにメッセージを送るとと
もに、蓄積された呼び出し文脈データを呼び出し文脈対象および／またはデータ
ベース構造に書き込む。

【０３８８】 ステップ１６５８で、トランクが戻された場合、すなわちアウトダイヤル経路
が見つかった場合、プロセスはつぎに図３２（ｆ）のステップ１６６０に進み、
そこでVnet SLPは呼び出しパーティのユーザのプロファイルを問い合わせる。

【０３８９】 図３２（ｆ）のステップ１６６０に示すように、ユーザ・プロファイル・デー
タベースにおけるデータベースの問いかけは、キーとして発信ユーザIDを使用す
るとともにユーザ・プロファイルの詳細を検索するためSIBBDBR.javaクラスを呼
び出して実行される。つぎにステップ１６６３では、最小呼び出し時間でユーザ
が十分利用可能なクレジットを持っているかどうかを決定する比較がなされる。
この比較を行うために、SIBBCompareInt.javaクラスが、ATM／Vnet呼び出しを確
立するため最低のコストでユーザのクレジットラインの詳細を比較するのに呼び
出される。つぎにステップ１６５５で、呼び出しを進めるのに十分なクレジット
がないものと決定された場合、プロセスは図３２（ｆ）のステップ１６２０に進
み、分解結合プロセスを開始するためにSIBBSendMsg.javaを経由してNGSにメッ
セージを送るとともに、蓄積された呼び出し文脈データを呼び出し文脈対象およ
び／またはデータベース構造に書き込む。

【０３９０】 ステップ１６６５にて、利用できるクレジットが充分にあると決定されたなら
ば、該プロセスはステップ１６７０に進む。このステップ１６７０では Vnet SL
P プロセスが、例えばスレッドｉｄ等のコール識別者 (call identifier) 及び
オブジェクト参照 (object reference) とともに、前記 NGS にモニタ・コネク
ト・イベントメッセージ (MonitorConnectEvent message) を送出する。これは
、メッセージの通信のための SLPs によって用いられる SIBBSendMsg.java (SIB
B) を介して送出される。特に、前記 Vnet SLP は、端末アドレスを含んだ関連
したコール論理プログラムに対するハンドオフコマンドを伴なったアウトダイア
ル要求を実行し、これにより前記 Vnet コールはその目的先に回送されるものと
なる。加えて、前記コール・モニタ・コネクト・イベントメッセージは、べーす
クラス NGINEvent につながるパブリッククラスであり、かつ前記 NGS に、コネ
クトメッセージを受けるのであれば NGIN にイベントを送らなければならないこ
とを伝えるのに用いられる。

【０３９１】 図３２（ｆ）のステップ１６７５に示すように、NGS が前記 Vnet コールが設
定されたとの指示を受けるまでは待ちプロセスが実行される。コネクト・イベン
トを待つために、前記 SIBBWait.Java クラス (SIBB) の新しいインスタンスが
このステップにて実行される。ステップ１６７５に示すように前記 Vnet コール
接続が確立されると、前記 NGS がコネクト・イベントメッセージを、戻された
オブジェクト参照及びスレッドＩＤによって識別された前記 ATM_Vnet SLP スレ
ッドインスタンスのために NGIN に戻す。前記コールへ関与したものはこの時点
で検証及び接続され、かつ、ステップ１６７７に示すように、前記 ATM_Vnet プ
ロセスがここでイベントのリリースを待つ。好ましくは、前記リリース・サービ
スは、このリリース・イベントを報告するのに用いられる。リリース・イベント
は、コールしたもの又はコールされたものが前記コールを終了したか、あるいは
ユーザ・クレジットが切れた場合に生ずることになろう。このリリース・イベン
トは、リリース・イベントが発生した時間を確定するための NNOS サービスに依
存しており、かつ、発生したイベントの原因を確定するとともにコール接続から
前記リリースイベントまでに経過した時間を確定する方法を実行する。この情報
はリリース・サービス・メッセージとともに戻される。

【０３９２】 ステップ１６７７にてリリース・サービス・メッセージが受領されると、該プ
ロセスは図３２（ｇ）のステップ１６８０に進む。ここでは、図３２（ｆ）のス
テップ１６６３にて確立された現存するユーザクレジット「ａ」から、前記リリ
ースメッセージから戻された前記経過時間に対応するコスト「ｂ」を差し引く操
作が実行される。これは、 SIBBSubtract.Java class (SIBB) に上記差し引き操
作を行うよう要求が出されることにより実行される。差し引きが行われると、ス
テップ１６８３においてユーザ・プロファイル・データの更新が実行され、ユー
ザのクレジットカードが、行われた Vnet コールに従った差し引き量に応じて更
新される。これは、SIBBDBR.java class (SIBB) に、キーとしてコールをしたユ
ーザのＩＤを用いてユーザ・プロファイル・データベース内に更新データをセッ
トするように要求を出すことにより実行される。次に、図３２（ｇ）のステップ
１６８５に示すように、該プロセスは、前記 SIBBDBInsert.java class への要
求により、前記 ATM_Vnet SLP を終了する前に、前記割り当てられたコールコン
テキストデータベースに、累算されたコールコンテキストをさらに書き込むこと
ができる。

【０３９３】 その後、前記ルーティング応答情報が前記 ELP 510 に送られ、例えば DM 内
に格納されたコールコンテキストデータ内に配置され、かつ、ハンドオフコマン
ドを伴なったアウトダイアル要求を、ルーティング情報を含む前記 CLP 545 に
送る。この一連の流れにおいて、前記終端ノードは離れたものであってもよく、
その場合には、その遠隔ノードにおける終端 LLP を立ち上げ、かつ、終端ライ
ン上の何らかの特徴を決定するためにプロファイル検索を行う。

【０３９４】 より詳細には、アウトダイアル／ハンドオフ処理が実行され、前記 LLPO への
ハンドオフコマンドとともに前記 CLP 545 にアウトダイアルを送るよう要求が
出される（開始ライン）。このアウトダイアルは、前記 Vnet コールを前記終端
ノードまで送るコールスイッチにおいて NNOS エージェントに転送される。その
後、この ELP プロセスによって DM に前記アウトダイアルコールコンテキスト
が書き込まれる。

【０３９５】 その後、コール制御によって指示が出される。この指示は、NGS スイッチがネ
ットワーク端末へのコールをセットアップしかつ遂行完了するようにとの指示を
含むものとすることができる。コールが完了すると（すなわち、両者の接続が切
断されると）、前記 LLP は、前記スイッチにおいて、前記 NNOS コンポーネン
トからコール完了通知を受信し、かつ該コール完了通知を前記 CLP に転送する
。この CLP はこのコール完了通知を関連する LLP 及び ELP に転送し、CLP 通
知によってトリガーされた際に停止される。この終了操作より前に、例えば請求
やその他の目的のためにコールの終了後に保持しておく必要のある前記 ELP コ
ールの詳細データをまず格納しておくこともできる。例えば、前記 ATM_Vnet サ
ービスの場合では、請求のために、前記 NGS スイッチが前記 ELP にパケットカ
ウントデータを書き込む。

【０３９６】 上述のことに加え、NGIN は、ATM/Vnet サービスに関する下記の機能要求をサ
ポートすることができる。すなわち、これに限定されるものではないが、１）国
内外のダイアルされた VNET 番号をスクリーンするための機能；２）ダイアルさ
れた VNET 番号数字を、国内外の DAL 及びダイレクト・ディスタンス・ダイア
リング (DDD) 端末をサポートするために、NGS スイッチが理解することのでき
る（アウトパルス数字）のようなフォーマットに変換する機能；３）国際 VNET
コールが、例えば、国の識別に３桁、そしてプライベートネットワーク番号を含
む７桁というように、所定のフォーマットを持てるようにする機能；４）開始者
から得られた端末アドレスを変更しかつ前記コールを替わりの端末に送る（コー
ル再送信／変更ルーティング）機能である。この変更端末は、 NANP DDD 番号、
Vnet 端末、移動電話番号、国際端末番号 IDDD、ACD 又は音声／ファックスメー
ルシステム等であってよく、また、必要であればどのような変更もコール者に明
瞭なものとすることができる。さらに、５）交換コードの使用を含む NXX 交換
ルーティング、及び、端末の転換を行う際の、通常地理的検索情報ではなくエリ
ア ID （顧客 NXX 交換ルーティングプラン id ）の提供；６） VNET コールが
前記コーポレート、ネットワーク、又はアクセス（開始スイッチ、キャリヤ）レ
ベル（レンジ特権スクリーリング）においてスクリーンされる機能；７）VNET
への遠隔アクセス、すなわち８００番、９００番、及び世界的規模のフリーホン
番号を意味する VNET への遠隔アクセスを与える機能、である。このような番号
がダイアルされると、 VNET ダイアルトーン、及び許容 VNET アドレスの内容、
さらにどのくらいの数字が追加されたかが与えられる。さらには、８）ルートデ
ータコールの利用可能性、すなわち、顧客が VNET サービスのために全てのデジ
タル・ルーティングをオーダーできる機能、である。（スイッチ５６経路を使用
する）デジタル・ルートインジケータはルート変換とともに前記スイッチに送ら
れる。さらに、９）ビジネスあるいは個人の何れの顧客に対してもプライベート
ダイアルプランをサポートする。現在では、VNET 顧客は、例えば４〜１２桁の
国内番号ダイアルプランと７〜１５桁の国際ダイアルフランといった独自のネッ
トワークダイアルプランを規定することができる。さらには、１０）例えば ADF
メッセージを介しての VNET カードの認証機能；１１） Vnet ワークを家で音
声サービスで行う機能、すなわち、家で働く使用人に対してその家の電話にビジ
ネス用番号を割り当てるといった機能である。彼ら使用人がビジネスで電話をか
ける際には、Vnet 番号の前に＊付きコードをダイアルすることによって Vnet
サービスを利用することができる。前記 NGIN Vnet SLP は、顧客の Vnet ダイ
アルプランにアクセスし、その番号を Vnet 端末に転送し、かつ Vnet ビジネス
顧客にそのコール分を自動的に課金する。電話がかかってきた場合には、区別さ
れる別の呼び出し音が鳴ってビジネスコールのユーザに注意を促す。またさらに
は、１２）VNET カードが効かないようにするとともに、ユーザーが VNET カー
ドを効かなくできるようにする機能、である。

【０３９７】 以上、好ましい実施形態のいくつかについて詳細に説明した。本発明の技術的
範囲は、クレームに記載した範囲内である限り上記例とは異なる実施形態からも
理解されるべきである。

【０３９８】 例えば、前記汎用コンピュータは、一形態の応用のためのに特別に製作された
ものではなく演算装置として理解される。前記汎用コンピュータは、本発明を実
施するのに必要な機能を有するものであればどのようなサイズのいかなる演算装
置であってもよい。

【０３９９】 追加例として、 "Java" プログラミング言語は、同様の特徴を有しかつ本発明
の実施にあたって同様の機能を発揮するものであればその他の同等のプログラミ
ング言語と置き換えてもよい。

【０４００】 本明細書中で用いた用語は、本発明をこれらの用語で示したもののみに限定す
るものではない。本明細書で用いた用語は同義語によって表されるもの及び／又
は同等のものと置き換えることができる。包含された用語は、本発明の技術的範
囲を考慮する際にその用語の範囲から出られないものと解釈されるべきではない
。さらに、本発明の種々の実施形態は、ハードウエア、ソフトウエア、又はマイ
クロ符号化されたファームウエアを利用すること、あるいはこれらの内部に組み
込むことが可能であることに留意されたい。

【０４０１】 以上、本発明を上記の実施形態と関連付けて説明したが、当業者には、本発明
の技術的範囲内で、多くの変化、変更、及び改良が可能であることが明らかであ
ろう。従って、クレームはかかる種々の変更及び改良をも包含すべく記載された
ものである。

【図面の簡単な説明】

【図１】 図１は、様々な交換アーキテクチャの論理的な代表例である。

【図２】 図２は、先行技術に従った典型的なインテリジェントネットワー
ク構成を採用する電気通信システムの図である。

【図３】 図３は、インテリジェント分配型ネットワークアーキテクチャを
採用する電気通信システムの図である。

【図４】 図４は、次世代インテリジェントネットワークのＳＡおよびＤＭ
コンポーネントを描写するブロック図である。

【図５】 図５（ａ）は、サービス管理コンポーネント５００の機能性を概
念的に図示する。図５（ｂ）は、サービス管理コンポーネント５００に物理的ア
ーキテクチャを図示する。図５（ｃ）は、ＩＤＮＡ／ＮＧＩＮシステム１００の
サービス管理コンポーネント５００の一般的な関数型アーキテクチャを図示する
。図５（ｄ）は、ＤＢＯＲを更新するために、ＳＡにより採用されるスキームを
図示する。図５（ｅ）は、データをＤＢＯＲからデータ管理コンポーネントに分
配するために、ＳＡにより採用されるスキームを図示する。図５（ｆ）は、デー
タ管理コンポーネント４００の関数型アーキテクチャを図示する。図５（ｇ）及
び５（ｈ）は、ＩＤＮＡ／ＮＧＩＮシステムのサービス作成及び配置段階を一般
的に描写するフロー図を図示する。図５（ｉ）は、ＮＧＩＮシステムのサービス
廃止／非活動化段階を描写するフロー図を図示する。

【図６】 図６は、本発明に従ってインテリジェント分配型ネットワークア
ーキテクチャを採用する電気通信システムの論理的及び機能的図である。

【図７】 図７は、本発明に従って、インテリジェント呼出しプロセッサ内
の機能的インターフェースの階層化を図示する図である。

【図８】 図８は、それによって仮想計算機が本発明に従ったサービス論理
実行環境をサポートする処理コンテキストのネスティングを図示するベン図であ
る。

【図９】 図９は、本発明に従って、インターフェース呼出しプロセッサ内
の管理オブジェクトのクラス階層構造を図示する図である。

【図１０】 図１０（ａ）は、サービス制御環境４３０の好適なアーキテク
チャを図示する。図１０（ｂ）は、ＮＯＳ ＮＴ及びＬＲＭの機能的サブコンポ
ーネントの関数型アーキテクチャを図示する。図１０（ｃ）は、インテリジェン
トネットワークのための資源管理システムのアーキテクチャを図示する。

【図１１】 図１１（ａ）は、ＳＬＥＥの起動プロセスを図示する。図１１
（ｂ）は、サービスマネージャーのプロセスを図示する。図１１（ｃ）は、ＳＬ
ＥＥクラスローダのプロセスを図示する。図１１（ｄ）及び１１（ｅ）は、サー
ビスエージェントの機能性を描写するフローチャートを図示する。図１１（ｆ）
は、スレッドマネージャーのプロセスを図示する。図１１（ｇ）は、サービスエ
ージェントの事後プロセスを図示する。

【図１２】 図１２（ａ）は、インテリジェントネットワークのための資源
管理システムのアーキテクチャを図示する。図１２（ｂ）は、ローカル資源管理
状態プロセッサの流れを図示する。図１２（ｃ）は、ノードキャッシュの状態デ
ータベースアーキテクチャを描写するより詳細な図である。

【図１３】 図１３は、ＳＬＰのインスタンス生成プロセスを描写するフロ
ー図である。

【図１４】 図１４（ａ）は、ＳＬＥＥのしきい値処理を描写するフロー図
である。図１４（ｂ）は、ＳＬＥＥの監視プロセスを描写するフロー図である。

【図１５】 図１５（ａ）及び１５（ｂ）は、３層になったインテリジェン
トネットワークの資源管理の機能性を描写する。

【図１６】 図１６は、例のＮＧＩＮサービスノードの物理的アーキテクチ
ャを図示する。

【図１７】 図１７は、ＮＧＩＮドメインの例の物理的アーキテクチャを図
示する。

【図１８】 図１８（ａ）は、例の機能選別インスタンスの一般的な機能性
を描写する。図１８（ｂ）は、サービス処理中に採用するオブジェクトインスタ
ンスが実行する一般的なローカル及びリモートデータベースアクセスの機能性を
描写する。図１８（ｃ）は、発信ノードで例のライン論理プログラムインスタン
スを生成するための一般的なプロセスを描写する。図１８（ｄ）は、サービス論
理プログラムインスタンスを生成するための一般的なプロセスを描写する。図１
８（ｅ）は、着信ノードで例のライン論理プログラムインスタンスを生成するた
めの一般的なプロセスを描写する。図１８（ｆ）は、呼出しに関するサービスの
実行を完了するための一般的なプロセスを描写する。図１８（ｇ）は、サービス
処理中に音声ファイルを検索するための一般的なプロセスを描写する。図１８（
ｈ）は、サービス処理中にネットワークスイッチで音声ファイルメッセージをプ
レイするための一般的なプロセスを描写する。図１８（ｉ）は、サービス処理中
にネットワークスイッチで音声ファイルメッセージをプレイし、入力したＤＴＭ
Ｆの桁を収集するための一般的なプロセスを描写する。

【図１９】 図１９（ａ）〜１９（ｅ）は、発信線で１−８００／８の番号
の変換を行い、呼び出して着信まで延長し、通話中着信機能を実現するための例
のＳＬＰプロセスを描写する。

【図２０】 図２０（ａ）及び２０（ｂ）は、呼出しを着信まで延長する前
に、１−８００／８ＸＸの番号の変換を行い、発信者へのメッセージ再生を行う
ための例のプロセスを描写する。

【図２１】 図２１（ａ）及び２１（ｂ）は、１−８００／８ＸＸのコレク
トコールサービスを行うための例のプロセスを描写する。

【図２２】 図２２（ａ）及び２２（ｂ）は、発信者がコーリングカードを
実現するとき、１−８００／８ＸＸのコレクトコールサービスを行うための例の
プロセスを描写する。

【図２３】 図２３（ａ）〜２３（ｃ）は、高度音声繰返しと転送呼出しサ
ービスを行うための例のプロセスを描写する。

【図２４】 図２４は、ＮＧＩＮが行うときの呼出し処理のシナリオを描写
する。

【図２５】 図２５は、ＮＧＩＮのシステムノードのためのオペレータ及び
コールセンターサービスのプロセスアーキテクチャを図示する。

【図２６】 図２６（ａ）〜２６（ｇ）は、ＮＧＩＮシステムでオペレータ
サービスシステム８００を実現するためのプロセスフローを描写する。

【図２７】 図２７（ａ）及び２７（ｂ）は、オペレータ及びカスタマコー
ルセンターサービスシステムを組込んだ例のＮＧＩＮサービスノード４５の物理
的アーキテクチャを図示する。

【図２８】 図２８（ａ）及び２８（ｂ）は、ＮＧＩＮに実現される例の１
−８００（コレクト）コールオペレータサービスプロセスを描写するフロー図で
ある。

【図２９】 図２９は、ＮＧＩＮがサービスするような呼出し処理のシナリ
オである。

【図３０】 図３０（ａ）及び３０（ｂ）は、オペレータ資源を待ち呼に割
当てるためのビジネス規則のアプリケーションを描写する。

【図３１】 図３１（ａ）は、発明のＮＧＩＮアーキテクチャがサポートす
るＡＴＭバーチャルプライベートネットワーク（ＶＰＮ）アーキテクチャの基本
コンポーネントを図示する。図３１（ｂ）は、ＮＧＩＮがサービスするようなＡ
ＴＭ／Ｖｎｅｔ呼出し処理のシナリオを図示する。

【図３２】 図３２（ａ）〜３２（ｇ）は、ＮＧＩＮで実現される基本的Ａ
ＴＭ／Ｖｎｅｔ呼出しサービスのプロセスを図示するフロー図を描写する。

【符号の説明】

１７０……インテリジェントネットワークアーキテクチャ １８０……資源複合体 ２０３……ノード ５００……中央管理装置

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ， ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，Ｋ Ｅ，ＬＳ，ＭＷ，ＳＤ，ＳＬ，ＳＺ，ＴＺ，ＵＧ，ＺＷ )，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ， ＴＪ，ＴＭ)，ＡＥ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ， ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，Ｃ Ｒ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＤＭ，ＥＥ，ＥＳ，ＦＩ ，ＧＢ，ＧＤ，ＧＥ，ＧＨ，ＧＭ，ＨＲ，ＨＵ，ＩＤ， ＩＬ，ＩＮ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，Ｋ Ｚ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＡ ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ， ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，Ｓ Ｋ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＴＺ，ＵＡ，ＵＧ ，ＵＺ，ＶＮ，ＹＵ，ＺＡ，ＺＷ (71)出願人 ウェンディ・ウォン アメリカ合衆国・テキサス・78287・ダラ ス・ケイプ・コーラル・ドライブ・4816 (71)出願人 ケニス・フィッシャー アメリカ合衆国・コロラド・80134・パー カー・ストーン・リッジ・テラス・10166 (71)出願人 サミ・サイド アメリカ合衆国・コロラド・80919・コロ ラド・スプリングス・ラグリー・コート・ 125 (71)出願人 アジェイ・デオ アメリカ合衆国・テキサス・75056・ルイ スヴィル・サー・トリスタン・レーン・ 2508 (72)発明者 アンドリュー・デュガン アメリカ合衆国・コロラド・80919・コロ ラド・スプリングス・テイバー・コート・ 2025 (72)発明者 アレン・ホルムズ アメリカ合衆国・コロラド・80919・コロ ラド・スプリングス・チャンブレイ・コー ト・5375 (72)発明者 テレンス・ロブ アメリカ合衆国・コロラド・80906・コロ ラド・スプリングス・チェイサム・ドライ ブ・223 (72)発明者 ウェンディ・ウォン アメリカ合衆国・テキサス・78287・ダラ ス・ケイプ・コーラル・ドライブ・4816 (72)発明者 ケニス・フィッシャー アメリカ合衆国・コロラド・80134・パー カー・ストーン・リッジ・テラス・10166 (72)発明者 サミ・サイド アメリカ合衆国・コロラド・80919・コロ ラド・スプリングス・ラグリー・コート・ 125 (72)発明者 アジェイ・デオ アメリカ合衆国・テキサス・75056・ルイ スヴィル・サー・トリスタン・レーン・ 2508 Ｆターム(参考） 5K024 AA02 AA11 AA21 AA31 AA41 AA71 BB07 CC03 CC09 DD01 EE01 EE06 FF04 GG01 GG03 GG12 5K026 AA03 BB02 CC02 CC07 CC08 DD03 EE01 FF02 FF03 FF04 5K051 AA01 AA03 AA05 AA09 AA10 BB01 BB02 CC02 CC04 DD04 DD07 EE01 EE02 FF01 HH13 HH15 KK01 KK05

Claims (60)

【特許請求の範囲】
1. 【請求項１】 遠距離通信サービスを提供する複数の相互連結されたノード
   を具備する遠距離通信ネットワークのためのインテリジェントサービスプラット
   フォームであって、 前記遠距離通信ネットワークは、サービス処理を要求する遠距離通信イベント
   を受信するネットワーク要素を有し、 前記サービスプラットフォームは、 ａ） 前記サービスを提供するために要求される独特のサービス処理機能と全
   ての関連データとを包むサービスオブジェクトを具備するサービスコンポーネン
   トの貯蔵場所を具備する管理システム を具備し、 前記管理システムは、前記サービスコンポーネントと関連データとを前記貯蔵
   場所から前記ネットワーク内の選択された１または２以上のサービスノードへ分
   配する分配メカニズムを具備し、 サービスノードは、 ｉ） １または２以上のサービス実行環境を具備し、 各サービス実行環境は、受信されたイベントに従ってサービスを実行するため
   に要求されるサービスコンポーネントを実行し、 サービスノードは、 ii） 前記管理システムからの前記サービスコンポーネントと全ての関連デ
   ータとを受信しかつ記憶し、かつ、受信されたイベントに応答して、前記サービ
   スコンポーネントと関連データとを前記サービス実行環境に対して利用可能にす
   るローカルデータ記憶および検索システム を具備し、 前記サービスプラットフォームは、 ｂ） サービスノードにおけるサービスコンポーネント間と前記遠距離通信ネ
   ットワーク内のサービスノード間とにおいて内部プロセス通信を提供し、かつ、
   サービスノードにおけるサービスコンポーネントの有効性を追跡するプラットフ
   ォーム非依存通信システム を具備し、 前記サービスプラットフォームは、前記イベントを受信した利用可能なネット
   ワーク要素を有するサービスノードにおいてサービスが実行されることを可能に
   する ことを特徴するインテリジェントサービスプラットフォーム。
2. 【請求項２】 前記管理システムは、 サービスノードにおいて実行されることができるサービスをユーザーが生成す
   ることを可能にするサービス生成プラットフォームから、前記サービスコンポー
   ネントを受信するインターフェースデバイス を更に具備し、 前記各サービスは、前記サービスを記憶しかつ維持しかつ実行するために要求
   されるサービスノード資源を定義する関連サービスプロフィール情報を有し、 前記管理システムは、 前記ネットワークの各サービスノードの物理資源容量を具備するコンフィグレ
   ーション基準を受信するインターフェースデバイス を更に具備し、 前記貯蔵場所は、 前記受信されたサービスコンポーネントと前記サービスノードコンフィグレー
   ション基準と前記サービスコンポーネントに関連するサービスプロフィール情報
   とを記憶するデータベースデバイス を具備し、 前記分配メカニズムは、前記サービスコンポーネントのコピーを、１または２
   以上のサービスノードへ、前記サービスプロフィール情報と前記サービスノード
   のコンフィグレーション基準とに従って分配する ことを特徴する請求項１記載のサービスプラットフォーム。
3. 【請求項３】 前記管理システムは、 前記サービスノードへ分配されたサービスコンポーネントの活性化と不活性化
   とを開始するトリガメカニズム を更に具備し、 サービスコンポーネントは、関連サービスに対する高い要求の期間はサービス
   ノードにおいて活性化され、前記サービスに対する低い要求の期間はサービスノ
   ードにおいて不活性化される ことを特徴する請求項２記載のサービスプラットフォーム。
4. 【請求項４】 前記サービスプロフィール情報は、 個々のサービスコンポーネントが前記サービスノードにおける実行のために活
   性化されるべきであるときを示す特定時間範囲表示と、 特定の時間範囲の間に前記サービスノードにおいて例示される前記サービスコ
   ンポーネントに関連する再使用可能なオブジェクトスレッドの最小数と最大数と
   を示す数範囲と を具備する ことを特徴する請求項３記載のサービスプラットフォーム。
5. 【請求項５】 前記関連データは、顧客特定データを具備し、 前記管理システムは、 前記顧客特定データを外部注文エントリシステムから受信するインターフェー
   スデバイス を更に具備し、 サービスプロフィールは、前記サービスコンポーネントを拡張する外部サービ
   ス生成エンティティから入力され、 インターフェースデバイスは、サービスノード容量を特定する環境供給システ
   ムから前記サービスノードコンフィグレーション基準を受信する ことを特徴する請求項４記載のサービスプラットフォーム。
6. 【請求項６】 前記サービス実行環境は、 オペレーティングシステムを有する１または２以上の計算システムと、 サービスコンポーネントと関連データとを記憶する関連ローカルメモリ記憶デ
   バイスと を具備する ことを特徴する請求項５記載のサービスプラットフォーム。
7. 【請求項７】 前記サービスコンポーネントは、 サービスノードにおける顧客特定サービスの供給のための顧客特定データ を更に具備し、 前記サービス管理システムは、 前記顧客特定データとサービスコンポーネントと関連サービスプロフィール情
   報と前記インターフェースデバイスからの前記サービスノードコンフィグレーシ
   ョン基準とを受信し、かつ、前記サービスコンポーネントに唯一の論理名を割り
   当て、かつ、前記サービスコンポーネントを、前記データベースデバイスでの記
   憶のために、該データベースデバイスに送る目録マネージャーデバイス を更に具備する ことを特徴する請求項６記載のサービスプラットフォーム。
8. 【請求項８】 前記トリガメカニズムは、サービスノードにおいて、前記顧
   客特定データとサービスコンポーネントと関連データとの活性化と不活性化と除
   去とを開始するための前記唯一の論理名を利用する ことを特徴する請求項７記載のサービスプラットフォーム。
9. 【請求項９】 前記ロケーション非依存通信システムは、 活性時に、サービスコンポーネントと関連データとを登録する登録デバイスを
   、前記サービスノードにおいて、 具備する ことを特徴する請求項８記載のサービスプラットフォーム。
10. 【請求項１０】 前記唯一の論理名は、個々のサービスコンポーネントのバ
    ージョン番号を具備し、 各サービスコンポーネントは、コンポーネントの多数のバージョンに対して、
    唯一のバージョン番号を受信する ことを特徴する請求項９記載のサービスプラットフォーム。
11. 【請求項１１】 前記データベースは、１または２以上のデータベースフォ
    ーマットを具備し、 前記サービス管理システムは、 前記データベースデバイス内に記憶されたサービスコンポーネント上でデータ
    ベース機能を実行するために要求を受信し、かつ、前記要求に関連するデータベ
    ース機能を実行するデータベースマネージャーデバイス を更に具備し、 前記データベースマネージャーデバイスは、要求されたデータベース機能の実
    行が可能になるように特定データベースタイプによって利用されるフォーマット
    に、要求されたデータベース機能を適応させるために、前記唯一の論理名を利用
    する ことを特徴する請求項７記載のサービスプラットフォーム。
12. 【請求項１２】 データベース機能は、 サービスプロセスコンポーネントを前記データベースデバイスに追加すること
    と、 サービスプロセスコンポーネントを前記データベースデバイスから削除するこ
    とと、 前記データベースデバイス内に具備されるサービスプロセスコンポーネントを
    変更することと のうちの１または２以上を具備する ことを特徴とする請求項１１記載のサービスプラットフォーム。
13. 【請求項１３】 前記分配メカニズムは、前記データベースから１または２
    以上のサービスノードにおけるローカルメモリ記憶デバイスへ、前記サービスプ
    ロフィールコンフィグレーション基準に従って、サービスコンポーネントを分配
    するための要求を生成し、 前記データベースマネージャーデバイスは、要求されたデータベース機能を、
    特定データベースタイプによって利用されるフォーマットに適応させるために、
    前記唯一の識別子を利用し、それによって、前記要求されたサービスコンポーネ
    ントの検索を可能にする ことを特徴する請求項１１記載のサービスプラットフォーム。
14. 【請求項１４】 前記サービス管理システムは、 前記データベースデバイス内に記憶されたサービスコンポーネントとサービス
    ノードにおける前記ローカルメモリ記憶デバイスに分配されたサービスコンポー
    ネントコピーとの間における不一致を自動的に識別する検査メカニズム を更に具備し、 前記検査メカニズムは、 不一致の判断時に、前記サービスノードの現在バージョンを伴って、該サービ
    スノードにおけるサービスコンポーネントコピーを更新する再同期装置 を具備する ことを特徴する請求項６記載のサービスプラットフォーム。
15. 【請求項１５】 前記サービス管理システムは、 全てのサービスコンポーネントとサービスノードプロフィール情報との受信と
    記憶と分配と検査とに関する全ての動作を記録する監視デバイス を更に具備し、 前記監視デバイスは、障害分析とサービス管理システムプロセスの報告とのた
    めに実行される ことを特徴する請求項１４記載のサービスプラットフォーム。
16. 【請求項１６】 前記ローカルデータ記憶および検索システムは、 前記分配されたサービスコンポーネントと関連データとを受信し、かつ、前記
    サービスコンポーネントと関連データとを前記ローカルメモリ記憶デバイスの第
    １メモリコンポーネント内に記憶するデータサーバーと、 サービスコンポーネントと関連データとを、前記第１コンポーネントから、前
    記ローカルメモリ記憶デバイスの第２メモリコンポーネントへ供給するキャッシ
    ュマネージャーデバイスと を具備し、 前記第２メモリコンポーネントは、 ノードにおけるサービスの実行の際に、現在実行中のサービスコンポーネント
    によって局所的にアクセス可能なメモリ を具備し、 前記ローカルデータ記憶および検索システムは、 ノードにおいて現在実行中のサービスの支援によって、前記第２コンポーネン
    トローカルメモリ記憶装置からデータを検索し、かつ、要求されたデータが前記
    第２コンポーネントにおいて利用不可能な場合、前記メモリ記憶装置の前記第１
    コンポーネントから、前記キャッシュマネージャーデバイスを介して、前記要求
    されたデータの検索を開始するクライアントインターフェースオブジェクト を具備する ことを特徴する請求項６記載のサービスプラットフォーム。
17. 【請求項１７】 前記キャッシュマネージャーデバイスは、サービス情報を
    前記ローカルメモリ記憶デバイスの前記第２コンポーネント内に記憶するための
    クライアントサイドローカルキャッシング方法を実行し、 前記キャッシュマネージャーデバイスは、前記第１メモリコンポーネントから
    データをキャッシングするときに、前記第２コンポーネントデバイス内のスペー
    スを動的に割り当てる ことを特徴する請求項１６記載のサービスプラットフォーム。
18. 【請求項１８】 サービスオブジェクトは、唯一の論理名によって、関連デ
    ータを要求し、 前記クライアントインターフェースオブジェクトは、要求されたデータが前記
    第２メモリコンポーネントまたは前記第１メモリコンポーネントのいずれから利
    用可能であるかを判断する ことを特徴する請求項１７記載のサービスプラットフォーム。
19. 【請求項１９】 前記キャッシュマネージャーデバイスは、前記第１メモリ
    コンポーネントから前記データサーバーの媒介物を通してデータを検索するため
    の照会サーバールーチンを実行する ことを特徴する請求項１８記載のサービスプラットフォーム。
20. 【請求項２０】 前記トリガメカニズムは、サービス活性化トリガを具備し
    、 前記データサーバーは、サービスを活性化するための前記サービス活性化トリ
    ガを受信し、かつ、前記ノードに分配された前記サービスの成功の活性化を示す
    成功表示か、または、前記ノードに分配された前記サービス情報の不成功の活性
    化を示す失敗表示を、活性化要求を伴う前記管理システムに応答する ことを特徴する請求項１９記載のサービスプラットフォーム。
21. 【請求項２１】 前記トリガメカニズムは、サービス不活性化トリガを具備
    し、 前記データサーバーは、サービスを不活性化するための前記サービス不活性化
    トリガを受信し、かつ、前記ノードに分配されたサービスの成功の不活性化を示
    す成功表示か、または、前記ノードに分配された前記サービス情報の不成功の不
    活性化を示す失敗表示を、不活性化要求を伴う前記管理サーバーに応答する ことを特徴する請求項１９記載のサービスプラットフォーム。
22. 【請求項２２】 前記プラットフォーム非依存通信システムは、 サービス実行環境に関連して、１または２以上の活性化されたサービスオブジ
    ェクトを計算システムにおいて例示しかつ実行する第１レベル処理デバイス を具備し、 前記第１レベルプロセッサは、サービス実行環境の資源容量に関するステータ
    ス情報を更に生成し、 前記プラットフォーム非依存通信システムは、 サービスノードに関連し、かつ、前記第１レベルプロセッサに通信可能にリン
    クされ、前記各第１レベルプロセッサからの前記ステータス情報を受信し、かつ
    、各ノードにおけるサービスの有効性を追跡する第２レベル処理デバイス を具備し、 前記第２レベルプロセッサは、前記１または２以上の計算システムのうちのど
    の計算システム内にて、要求されたサービスが実行されるべきかを、前記資源容
    量とサービスオブジェクト有効性とに基づいて判断する ことを特徴する請求項６記載のサービスプラットフォーム。
23. 【請求項２３】 前記インテリジェントネットワーク内の各サービスノード
    において前記各第２レベル処理デバイスと通信可能にリンクされており、前記イ
    ンテリジェントネットワーク内のノードにおけるサービスの実行の容量を追跡す
    る第３レベル処理デバイス を更に具備し、 前記容量は、サービス実行環境のリストと各ローカル実行環境上で実行するた
    めにプログラミングされたサービスのタイプとを具備する ことを特徴する請求項２２記載のサービスプラットフォーム。
24. 【請求項２４】 前記第１レベルプロセッサは、アラームステータス情報を
    生成し、 該アラームステータス情報は、サービス実行環境の使用のレベルを示し、かつ
    、現在実行中のサービスオブジェクトスレッドの数に基づく厳正のレベルに従っ
    て特徴付けられ、 前記第２レベルプロセッサは、前記アラームステータス情報を受信し、かつ、
    データ記憶デバイス内に前記アラームステータス情報を記憶しかつ更新する ことを特徴する請求項２３記載のサービスプラットフォーム。
25. 【請求項２５】 前記第３レベル処理デバイスにおいて追跡される前記容量
    は、 前記各サービスノードにおいて例示されるサービスオブジェクトを示すための
    アクティブサービスステータスと、 前記アラームステータス情報に基づいて、サービスノードにおいてサービスオ
    ブジェクト例示がこれ以上実行されないことを示す過負荷ステータスと を具備する ことを特徴する請求項２４記載のサービスプラットフォーム。
26. 【請求項２６】 前記第２レベル処理デバイスは、サービスノードにおいて
    提供されることができる各サービスに対するサービスコンフィグレーションファ
    イルを受信し、 各サービスファイルは、 各サービス実行環境において実行中のサービスオブジェクト例示の数と、 前記サービスオブジェクトを例示するときを示す時間情報と を示し、 前記第２レベルプロセッサは、前記コンフィグレーションファイルによって示
    される時間に、１または２以上の前記サービスオブジェクトを例示する ことを特徴する請求項２５記載のサービスプラットフォーム。
27. 【請求項２７】 前記サービスプロフィールは、サービスオブジェクト例示
    のための時間期間を示し、 前記システムプロセッサは、前記サービスプロフィールによって示される時間
    に、１または２以上の前記サービスオブジェクトの実行の終了を開始する ことを特徴する請求項２６記載のサービスプラットフォーム。
28. 【請求項２８】 前記プラットフォーム非依存通信システムは、前記サービ
    スに関連する唯一の論理名の形式で、個々のサービスに対する要求を受信し、 前記システムは、前記第１レベル処理デバイスに基づいて、サービスノードに
    おいて受信された要求サービスが前記サービス実行環境において現在アクティブ
    であるか否かを判断し、かつ、もし、現在アクティブであるならば、前記論理名
    をオブジェクトリファレンスへ変換し、 該オブジェクトリファレンスは、計算システムにおいて、要求されたサービス
    に関連するサービスオブジェクトスレッドを、前記第１レベルプロセッサが例示
    することができるようにするためのものである ことを特徴する請求項２７記載のサービスプラットフォーム。
29. 【請求項２９】 前記要求されたサービスオブジェクトが前記サービス実行
    環境において現在アクティブでないと判断されると、前記プラットフォーム非依
    存通信システムは、前記ノードにおいて他のサービス実行環境における前記要求
    されたサービスオブジェクトの有効性とステータスとを判断するために、前記第
    ２レベル処理デバイスとの通信を可能にし、かつ、そのサービスオブジェクトの
    有効性とステータスとに基づいて、前記他のサービス実行環境において、計算シ
    ステムにおけるサービスオブジェクトを例示する ことを特徴する請求項２８記載のサービスプラットフォーム。
30. 【請求項３０】 前記要求されたサービスオブジェクトが前記サービスノー
    ドにおいて例示されないと判断されると、前記プラットフォーム非依存通信シス
    テムは、前記ネットワークの他のサービスノードにおける前記要求されたサービ
    スオブジェクトの有効性を判断するために、前記第３のレベル処理デバイスとの
    通信を可能にする ことを特徴する請求項２９記載のサービスプラットフォーム。
31. 【請求項３１】 前記第１レベル処理デバイスは、 前記ローカルメモリ記憶デバイスから１または２以上のサービスオブジェクト
    をロードし、かつ、計算システム内での実行のための前記１または２以上のオブ
    ジェクトを例示する第１オブジェクトと、 個々のサービスに対応して、そのサービスに対して受信された各要求に対応す
    る各サービス実例に対して、１または２以上のサービススレッドを割り当てる第
    ２オブジェクトと を具備し、 各サービススレッド実例は、該サービススレッド実例に関連する唯一の識別子
    を有する ことを特徴する請求項２２記載のサービスプラットフォーム。
32. 【請求項３２】 前記プラットフォーム非依存通信システムは、 実行中のオブジェクト実例間においてメッセージとイベントとのリアルタイム
    通信を提供するメカニズム を具備し、 個々のサービスに対応する前記第２オブジェクトは、前記サービス実例間にお
    いてイベントとメッセージとを運び、 前記イベントとメッセージとは、受信されたメッセージとイベントとを適切な
    サービス実例にコーディネイトする前記唯一の識別子を具備する ことを特徴する請求項３１記載のサービスプラットフォーム。
33. 【請求項３３】 各サービススレッド実例に対して割り当てられ、サービス
    実行中に受信された前記サービス実例に関連するイベントを待ち行列に入れるイ
    ベント待ち行列メカニズム を更に具備し、 イベントは、前記イベントが実行されるべき順番を示す関連プライオリティを
    有し、 前記イベント待ち行列デバイスは、受信されたイベントの関連プライオリティ
    に従って該イベントの処理を可能にする ことを特徴する請求項３２記載のサービスプラットフォーム。
34. 【請求項３４】 前記第１レベル処理デバイスは、 前記各実行環境における計算システムにおいて実行中のサービスの実例に対応
    するアクティブサービスオブジェクトスレッドの登録場所と、 サービス論理名をオブジェクトリファレンスを伴ってマッピングするマッピン
    グデバイスと を具備し、 前記プラットフォーム非依存通信システムは、サービス実行環境において、要
    求されたサービスオブジェクトスレッド実例の例示を可能にするための前記オブ
    ジェクトリファレンスを利用する ことを特徴する請求項３１記載のサービスプラットフォーム。
35. 【請求項３５】 ネットワーク要素は、 遠距離通信サービス要求を呼イベントの形式で受信する開始スイッチプラット
    フォーム を具備し、 前記サービスオブジェクトは、 ａ） 前記インテリジェントネットワーク内のサービスノードにおいて実行中
    のオブジェクト実例間における通信を可能にするプラットフォーム非依存通信シ
    ステムと、 ｂ） 前記スイッチプラットフォームにおいて受信された呼イベントに対応す
    る呼開始情報を、前記スイッチに関連するサービスノードにおいて提供された実
    行環境において実行中の１または２以上のオブジェクト実例へ、前記プラットフ
    ォーム非依存通信システムを介して通信する前記開始スイッチに関連する実行環
    境において実行中のオペレーティングシステムエージェントオブジェクト実例と を具備し、 前記１または２以上のオブジェクト実例は、 ｉ） 前記開始スイッチに関連する通信線のステータスを維持する第１ライ
    ンオブジェクト実例と、 ii） 顧客に対するサービスを実行するための機能を包むサービスオブジェ
    クトと を具備し、 前記ローカルメモリ記憶デバイスは、前記サービスオブジェクトによってアク
    セス可能であり、前記要求されたサービスのサポートによって呼経路決定情報を
    検索し、かつ、呼経路決定プランに従う位置探索を終了し、 前記ローカルメモリ記憶デバイスは、前記検索された呼経路決定情報に基づく
    前記呼に対する終了スイッチロケーションアドレスを具備し、かつ、前記終了ス
    イッチに関連する通信線のステートを維持するための第２ラインオブジェクト実
    例の例示を開始し、 前記プラットフォーム非依存通信システムは、前記サービスオブジェクトと前
    記第１および第２のラインオブジェクト実例との間において、呼経路決定コマン
    ドを通信し、 前記第１および第２のラインオブジェクト実例は、前記開始スイッチと終了ス
    イッチとの間において確立中の前記接続の間における呼接続を確立する ことを特徴する請求項６記載のサービスプラットフォーム。
36. 【請求項３６】 呼の現在ステートを維持し、更に、前記サービスオブジェ
    クトと前記第１および第２のラインオブジェクト実例との間において、前記プラ
    ットフォーム非依存通信システムを介して通信を確立する呼オブジェクト実例 を更に具備する ことを特徴する請求項３５記載のサービスプラットフォーム。
37. 【請求項３７】 前記開始情報は、受信された呼を識別するための唯一の識
    別子を具備し、 前記呼オブジェクト実例は、前記唯一の識別子に基づいて、呼イベントに対し
    て実行されるサービスの実行を追跡する ことを特徴する請求項３６記載のサービスプラットフォーム。
38. 【請求項３８】 各オブジェクトスレッド実例に対するサービスオブジェク
    ト実行に関連する呼前後関係データを維持しかつ記憶するイベントロジックオブ
    ジェクト実例 を更に具備し、 前記呼前後関係データは、前記唯一の識別子によって識別される ことを特徴する請求項３７記載のサービスプラットフォーム。
39. 【請求項３９】 前記システムエージェントオブジェクト実例は、最初に、
    前記呼開始情報を、前記サービス実行環境において実行中の特徴識別オブジェク
    ト実例へ通信し、 前記特徴識別オブジェクト実例は、各々のサービスオブジェクトに関連する論
    理名を見つけるために、データベース記憶装置情報検索を実行し、 第１ラインオブジェクトと呼オブジェクトとは、前記受信されたサービス要求
    に関連するサービスを実行することができる ことを特徴する請求項３７記載のサービスプラットフォーム。
40. 【請求項４０】 前記プラットフォーム非依存オペレーティングシステムは
    、 オブジェクトの論理名を前記オブジェクトの実例を実行するためのアドレス位
    置に変換する名前変換機能 を提供する ことを特徴する請求項３７記載のサービスプラットフォーム。
41. 【請求項４１】 前記イベントロジックオブジェクトは、前記第１および第
    ２ラインオブジェクト実例と前記呼オブジェクトインスタントと前記サービスオ
    ブジェクト実例と前記スイッチプラットフォームとのうちの１または２以上から
    、サービス処理に関連する呼前後関係データを受信する ことを特徴する請求項３７記載のサービスプラットフォーム。
42. 【請求項４２】 前記イベントオブジェクトは、前記呼前後関係データを、
    将来の使用のためのデータベース記憶装置に送る ことを特徴する請求項４１記載のサービスプラットフォーム。
43. 【請求項４３】 前記第１および第２ラインオブジェクト実例の各々は、開
    始スイッチと終了スイッチとのそれぞれに関連する物理線に関して、顧客加入特
    徴を調べる ことを特徴する請求項３７記載のサービスプラットフォーム。
44. 【請求項４４】 オペレータサービスシステムを更に具備し、 該オペレータサービスシステムは、 オペレータ資源を要求する受信されたイベントを１または２以上のイベント待
    ち行列デバイスに論理的に割り当てる第１コンポーネント を具備し、 各イベント待ち行列デバイスは、オペレータ資源が利用可能でないときに、受
    信されたイベントに対する論理的な記憶装置を示し、 該オペレータサービスシステムは、 前記特定能力を有するネットワークオペレータ資源が利用可能になると、前記
    利用可能なオペレータ資源を、前記受信されたイベント呼を論理的に保持するイ
    ベント待ち行列デバイスに割り当てる第２コンポーネント を具備し、 前記オペレータ資源は、終了アドレスによって示され、 前記イベントは、終了アドレスにおける前記オペレータ資源へ送られる ことを特徴する請求項６記載のサービスプラットフォーム。
45. 【請求項４５】 前記第１コンポーネントは、 利用可能なオペレータ資源の論理的な終了アドレスを維持する利用可能容量リ
    ストと、 受信されたイベントから要求を受信するサービスプロセッサデバイスと を具備し、 各要求は、１または２以上のオペレータ資源容量を具備し、 前記サービスプロセッサデバイスは、要求された容量を有する要求されたオペ
    レータ資源が現在利用可能か否かを判断するために、前記利用可能容量リストを
    照会し、 前記サービスプロセッサデバイスは、要求されたオペレータ資源が現在利用可
    能でないときは、前記受信されたイベントをイベント待ち行列デバイスへ送る ことを特徴する請求項４４記載のサービスプラットフォーム。
46. 【請求項４６】 前記イベント待ち行列デバイスは、オペレータ資源の容量
    に従って構成され、 受信されたイベントは、要求された容量を有するオペレータ資源の表示に従っ
    て、イベント待ち行列デバイス内におかれる ことを特徴する請求項４５記載のサービスプラットフォーム。
47. 【請求項４７】 前記第１コンポーネントは、 受信されたイベントに対して資源が利用可能でないとき、前記サービスプロセ
    ッサから通知を受信し、かつ、利用可能なオペレータが要求を処理するために現
    在利用可能でないとき、オペレータサービスに対する要求を処理するために、イ
    ベント待ち行列デバイスを割り当てるイベント待ち行列選択デバイス を更に具備する ことを特徴する請求項４６記載のサービスプラットフォーム。
48. 【請求項４８】 前記イベント待ち行列デバイス内に論理的に記憶されたイ
    ベントの容量を照会し、かつ、要求された容量を有する利用可能なオペレータ資
    源を、イベント待ち行列デバイス内に論理的に記憶された受信イベントに割り当
    てる容量プロセッサ を更に具備する ことを特徴する請求項４５記載のサービスプラットフォーム。
49. 【請求項４９】 前記第２コンポーネントは、 利用可能なオペレータ資源を様々なサービスに割り当てるサービス容量割当デ
    バイス を具備し、 前記サービス容量割当デバイスは、現在のシステム要求と処理ルールとに基づ
    いて、どのイベント待ち行列デバイスが利用可能なオペレータ資源を受信できる
    か判断する ことを特徴する請求項４５記載のサービスプラットフォーム。
50. 【請求項５０】 前記サービス容量割当デバイスは、利用可能なオペレータ
    資源情報を前記利用可能容量リストから受信し、かつ、前記オペレータ資源を、
    割り当てられたイベント待ち行列デバイスに再割り当てする ことを特徴する請求項４９記載のサービスプラットフォーム。
51. 【請求項５１】 ネットワーク要素において受信された仮想ネットワーク（
    Ｖｎｅｔ）要求イベントに関するＶｎｅｔサービスを実行するシステム を更に具備し、 前記システムは、 サービス実行環境内で実行し、かつ、受信されかつ唯一のトランザクション識
    別子に関連する各Ｖｎｅｔ要求に対するＶｎｅｔサービスオブジェクトスレッド
    実例を例示することに責任を負うＶｎｅｔサービスエージェントオブジェクト を具備し、 前記プラットフォーム非依存通信システムは、各Ｖｎｅｔサービス要求に関す
    る情報を、前記Ｖｎｅｔサービスエージェントオブジェクト実例に移し、 前記情報は、前記要求に対するＶｎｅｔサービス要求開始者と行先番号とを示
    し、 前記Ｖｎｅｔサービスエージェントオブジェクト実例は、前記唯一の識別子に
    従って、前記情報を、実行中のＶｎｅｔサービススレッド実例へ送り、 前記システムは、 受信された各Ｖｎｅｔ呼に対する経路決定プランを、前記移された情報と前記
    Ｖｎｅｔサービススレッド実例によって決定される１または２以上のファクタと
    に基づいて決定するメカニズムと、 前記決定された経路決定プランに基づいて、前記Ｖｎｅｔ呼を、前記資源複合
    体から行先番号へ経路決定するメカニズムと を具備する ことを特徴する請求項６記載のサービスプラットフォーム。
52. 【請求項５２】 前記Ｖｎｅｔサービススレッド実例は、 Ｖｎｅｔ申込みに従って、前記Ｖｎｅｔサービスを要求するための権利を発呼
    者が与えられることを確認するために、ローカルデータベース情報検索を実行す
    るメカニズム を具備する ことを特徴する請求項５１記載のサービスプラットフォーム。
53. 【請求項５３】 前記情報は、ポートＩＤ番号とターミナルＩＤ番号とを具
    備し、 データベース情報検索を実行する前記メカニズムは、 発呼者が前記Ｖｎｅｔサービス要求を生成する権利を与えられていることを判
    断するために、前記ポートＩＤ番号とターミナルＩＤ番号とをキーとして利用す
    るデータベースを保護するソースアドレスを照会すること を具備し、 前記実行中のＶｎｅｔサービススレッドは、もし、前記発呼者が前記要求を実
    行する権利を与えられていないならば、前記Ｖｎｅｔサービス要求を終了する ことを特徴する請求項５１記載のサービスプラットフォーム。
54. 【請求項５４】 前記Ｖｎｅｔサービススレッド実例は、 前記被呼者がＶｎｅｔ申込みに従ってＶｎｅｔサービスコールを受信すること
    を確認するデータベース情報検索を実行し、かつ、もし、前記被呼者が前記呼を
    受信する権利を与えられていないならば、前記Ｖｎｅｔサービス要求を終了する
    メカニズム を具備する ことを特徴する請求項５１記載のサービスプラットフォーム。
55. 【請求項５５】 前記Ｖｎｅｔサービススレッド実例は、 前記発呼者がＶｎｅｔサービス申込みに従って前記被呼者に電話をかける権利
    を与えられているか否かを判断するために、閉ユーザーグループデータベース照
    会を実行するメカニズム を具備する ことを特徴する請求項５１記載のサービスプラットフォーム。
56. 【請求項５６】 前記Ｖｎｅｔサービススレッド実例は、受信されたＶｎｅ
    ｔサービス要求に対する現在時間を更に判断する ことを特徴する請求項５１記載のサービスプラットフォーム。
57. 【請求項５７】 前記１または２以上のファクタは、年の現在時間を具備し
    、 経路決定プランを実行する前記メカニズムは、前記受信された要求の年の時間
    に基づいて経路決定選択を発見するために、年データベース照会の時間を実行す
    ること を具備する ことを特徴する請求項５６記載のサービスプラットフォーム。
58. 【請求項５８】 前記１または２以上のファクタは、日の現在時間を具備し
    、 経路決定プランを実行する前記メカニズムは、前記受信された要求の日の時間
    に基づいて経路決定選択を発見するために、日データベース照会の時間を実行す
    ること を具備する ことを特徴する請求項５６記載のサービスプラットフォーム。
59. 【請求項５９】 経路決定プランを決定する前記メカニズムは、 前記経路決定選択に基づいて、前記資源複合体から前記行先番号への前記Ｖｎ
    ｅｔ呼の経路決定を可能にするスイッチを決定するために、データベース情報検
    索を実行するメカニズム を具備する ことを特徴する請求項５８記載のサービスプラットフォーム。
60. 【請求項６０】 経路決定プランを決定する前記メカニズムは、 前記経路決定選択に基づいて、前記資源複合体から前記行先番号への前記Ｖｎ
    ｅｔ呼の経路決定のためのアウトダイヤル経路を決定するために、データベース
    情報検索を実行するメカニズム を具備する ことを特徴する請求項５９記載のサービスプラットフォーム。