JP2002528932A - インテリジェント・ネットワークにおけるリアルタイム呼処理サービスを提供する方法および装置 - Google Patents

Abstract

(57)【要約】 インテリジェント・ネットワークにおいてリアルタイム呼処理サービスを提供するシステムであって、該システムは、インテリジェント・ネットワークにおけるサービス・ノード（２０４）において実行するオブジェクト・インスタンス間の通信を可能にするプラットフォームに依存しない通信システムを含む。発信側スイッチと関連した実行環境において実行するオペレーティング・システム・エージェント・オブジェクト（２０４）インスタンスは、スイッチで受け取った呼イベントに対応する発呼情報を、ネットワーク内のサービス・ノード（２０４）において提供される実行環境で実行する１つまたは複数のオブジェクト・インスタンスに送り、このオブジェクト・インスタンスは、発呼と関連した通信線路の状態を維持する線オブジェクト・インスタンスと、顧客要求にしたがってサービスを実行するメソッドを実施するサービス・オブジェクトとを含む。

Description

【発明の詳細な説明】

【０００１】

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

本発明は、一般に、通信サービスを提供するためのインテリジェント・ネット
ワーク・システムに関し、具体的には、インテリジェント・ネットワーク全体に
分散した複数のサービス・ノードのそれぞれにおいてリアルタイムイベント処理
サービスを提供する新規なサービス制御システムに関する。

【０００２】

【従来の技術】

ネットワーク・サービスは、１つまたは複数の加入者との対話に応じて、デー
タや電話などの通信ネットワークおよびそれと関連するリソースによって実行さ
れる機能である。たとえば、加入者が特別の順番の数字をダイヤルすることによ
って、自動転送や音声メール・アクセスなどの電話ネットワーク常駐サービスを
起動することができる。セキュリティ、妥当性検査および認証により、その他の
ネットワーク・サービスをネットワーク所有者の支援に向けることができる。サ
ービスの追加や修正は、通信ネットワークの変更を必要とする。

【０００３】 最も慣例的な通信ネットワークは、相互接続されたスイッチと通信サービスか
ら構成される。そのようなスイッチは、スイッチメーカーが設計した独自のソフ
トウェアまたはファームウェアによって動作する一体になった処理装置または埋
め込まれた処理装置によって制御される。一般に、スイッチメーカーのソフトウ
ェアまたはファームウェアは、サービス処理、呼処理、設備処理およびネットワ
ーク管理の機能的なすべての側面をサポートしていなければならない。すなわち
、ネットワーク所有者が新しいサービスを実現したり既存のサービスを修正した
りしたいときは、様々なスイッチメーカーは、ネットワーク内のすべてのスイッ
チのソフトウェアを改訂しなければならない。

【０００４】 ネットワークは様々なメーカーによる様々なスイッチモデルを含むため、新し
いソフトウェアを慎重に開発し、試験し、展開することが必要になる。新しい改
訂ごとに各スイッチのコード・サイズが大きく複雑になってきているため、新し
いソフトウェアを開発し試験し展開するのに必要な時間は、より長く複雑になっ
てきている。したがって、このプロセスには、数年かかることがある。さらに、
この高い複雑さによって、スイッチのプロセッサに負担がかかり、スイッチの動
作不良の可能性が高まり、スイッチの修理と交換が必要になることがある。さら
に、複数のネットワーク所有者が共通の組のスイッチメーカーに依存するため、
競合を制限する望ましくない２つの状況が生じる。

【０００５】 第１に、メーカーのソフトウェア・リリースは、いくつかのネットワーク所有
者から要求された変更を組み込もうとすることがあり、したがって、ネットワー
ク所有者は、自分たちのサービスとそれらの競合から提供されるサービスとを真
に区別することができない。また、これにより、いくつかのネットワーク所有者
は、メーカーが新しいリリースに他のネットワーク所有者による要求を組み込む
まで待たされる。第２に、あるネットワーク所有者からの要求に応じた機能を組
み込んで新しいサービスを実現したスイッチのソフトウェア・リリースは、意図
せずに他のネットワーク所有者に利用可能になることがある。

【０００６】 このような問題は、加入者の移動性の高まり、トラヒックの種類と帯域幅の増
大、伝統的な番号付け方式の崩壊、サービスの高度化、および競争の高まりによ
り、過去５〜１０年の間に新しいネットワーク・サービスの需要が指数的に高ま
ってきたため許容できなくなってきた。したがって、新しいネットワーク・アー
キテクチャが、サービス・ロジックを作成し展開し実行するよりフレキシブルな
方法を取り入れる必要があることが広く認識されている。後で説明する本発明の
新規なアーキテクチャを十分に理解するために、図１を参照して、関連する従来
技術の以下の説明を提供する。

【０００７】 図１を参照し、本発明を含む様々なスイッチングアーキテクチャの論理表現を
示す。全体を２０で示した一体式スイッチは、サービス処理機能２２、呼処理機
能２４、設備処理機能２６およびスイッチ機構２８を含む。これらの機能２２、
２４、２６および２８はすべて、グループ３０で記号化したようにハードコード
され、混合され、画一化されている。さらに、機能２２、２４、２６および２８
は、スイッチメーカーによって設計され、メーカーにより異なる独自のプラット
フォーム上で動作する。その結果、これらの機能２２、２４、２６および２８は
、メーカーのサポートなしに修正できず、これが、サービスの開発と実装を遅延
させ、新しいサービスを市場に出すコストを高めている。したがって、新しい革
新的なサービス、呼処理、データ処理、信号処理およびネットワーク操作の開発
は、メーカー独自のスイッチハードウェアおよびソフトウェアに対するメーカー
の管理と、業界標準を確立し実現する本来の難しさとによる制限を受ける。

【０００８】 サービス処理機能２２は、一体式スイッチ２０内でコード化され、ローカルの
データ内容とダイアルされた番号に基づいたプロセスのローカル制御しか可能に
しない。このローカル情報は、コード化されたサービス機能を実行するハードコ
ードされたプロセス・エンジンによって解釈される。呼処理機能２４は、ハード
コードされ、発呼機能と着呼機能を提供する。このプロセスは、実際に、個々の
接続を確立して呼を完了させる。同様に、設備処理機能２６もハードコードされ
、呼に含まれる物理リソースに関連したすべてのデータ処理を実現する。スイッ
チ機構２８は、Northern Telecom社などのスイッチメーカーから提供される一体
式ソフトウェアを実行するスイッチおよびコンピュータのハードウェア構成要素
を表す。スイッチ機構２８は、接続を確立するために必要な物理的機構を提供し
、伝達装置（ＴＩとＤＳＯ）、スイッチイングマトリクス装置（ネットワーク平
面とその処理装置）、リンク層信号処理装置（ＳＳ７、ＭＴＰ、ＩＳＤ、ＬＡＰ
Ｄ）、および専用回路（コンファレンス・ポート、音声トーン検出器）を含むが
これらに限定されない。

【０００９】 前述の課題に取り組む試みにおいて、国際電気通信連合と欧州電気通信標準協
会は、ＩＴＵ−Ｔインテリジェント・ネットワーク規格（Intelligent Network
Standard）（「ＩＮ」）を承認した。同様に、Ｂｅｌｌｃｏｒｅは、高度インテ
リジェント・ネットワーク規格（Advanced Intelligent Network Standard）（
「ＡＩＮ」）を承認した。これらの２つの規格は、表現と発展の状態が異なるが
、ほとんど同じ目的および基本概念を有する。したがって、これらの規格は、サ
ービス処理機能２２がスイッチから分離された１つのネットワーク・アーキテク
チャと見なされる。

【００１０】 ＩＮおよびＡＩＮアーキテクチャを使用することによって、本質的に所与のタ
イプの呼において起動されるサービスに依存しない構成単位（Service Independ
ent Building Blocks）（「ＳＩＲＳ」）のテーブルである新しいサービス論理
プログラム（Service Logic Program）（「ＳＬＰ」）を作成し展開することに
よって新しいサービスを公開することがおそらく可能である。この手法により、
いくつかの特定のエレメント・タイプが、ＳＬＰと相互動作して、ネットワーク
加入者にサービスを提供する。その結果、新しいまたは可能性のあるサービスが
、既存のＳＩＢＢＳによって制限される。

【００１１】 全体が４０で示されたＩＮまたはＡＩＮアーキテクチャは、一体式スイッチ２
０の機能を、サービス制御ポイント（Service Control Point）（「ＳＣＰ」）
４２と、サービススイッチイングポイント（Service Switching Point）（「Ｓ
ＳＰ」）およびスイッチングシステム４４に論理的に分離する。ＳＣＰ４２は、
サービス処理機能２２を含むが、ＳＳＰおよびスイッチングシステム４４は、呼
処理機能２４、設備処理機能２６およびスイッチ機構２８を含む。このケースで
は、呼処理機能２４、設備処理機能２６およびスイッチ機構２８は、グループ４
６によって記号化されたようにハードコードされ、混合され、画一化されている
。

【００１２】 サービススイッチングポイント（「ＳＳＰ」）は、加入者の信号発信が、ダイ
アルされた番号だけに基づいた単純なものでない経路指定を必要とすることを認
識するためにスイッチにある機能モジュールである。ＳＳＰは、呼のさらなる操
作を中断し同時にリモートＳＣＰ４２に呼の適切な処理に関する問い合わせを行
い、本質的にいくつかのスイッチのデータベース・サーバとしてはたらく。この
処理の分割によって、特別なサービス呼を処理するための希であるが時間のかか
るタスクの負荷がスイッチから軽減される。さらに、この適度な集中化により、
ネットワーク全体のために働く容易に修正可能で負担の重い１つのレポジトリを
有することと、すべてのスイッチにあるレポジトリの完全なコピーを展開するこ
ととの平衡がとれる。

【００１３】 次に図２を参照すると、ＩＮまたはＡＩＮアーキテクチャを使用する通信シス
テムが示され、全体が５０で表される。ＩＳＤＮ端子５２、第１の電話５４、第
２の電話５６などの様々な顧客システムが、ＳＳＰおよびスイッチングシステム
４４に接続される。ＩＳＤＮ端子５２は信号線６０および伝送線６２によってＳ
ＳＰおよびスイッチングシステム４４に接続される。第１の電話５４は、伝送線
６４によってＳＳＰおよびスイッチングシステム４４に接続される。第２の電話
５６は、伝送線６８によってリモートスイッチングシステム６６に接続される。
また、リモートスイッチングシステム６６は、伝送線７０によってＳＳＰおよび
スイッチングシステム４４に接続される。

【００１４】 図１に関して前に説明したように、ＳＳＰ７０は、加入者の信号発信が、ダイ
アルされた番号にのみ基づいた単純なものではないルーチングを必要とすること
を認識するためにスイッチにある機能モジュールである。ＳＳＰ７０は、呼のさ
らなる処理を中断し、呼の適切な処理のための問い合わせ（query）を行う。こ
の問い合わせは、リモートＳＣＰ４２にＳＳ７メッセージの形で送られる。サー
ビス制御ポイント４２は、その場所にあるデータ・ベース内容を変更することに
より、多くの内在するスイッチを介して接続された加入者が使用できるネットワ
ーク機能を変更することができるためそのように名前を持つ。問い合わせは、信
号線７２を介して、そのようなエレメントの中で単にＳＳ７メッセージ用のルー
タである信号転送ポイント（Signal Transfer Point）（「ＳＴＰ」）７４に送
られ、次に信号線７６を介してＳＣＰ４２に送られる。

【００１５】 統合サービス管理システム（Integrated Service Management System）（「Ｉ
ＳＭＳ」）７８は、サービスを展開または変更したり加入者ごとのサービスへの
アクセスを管理したりする管理ツールとして構想されている。ＩＳＭＳ７８は、
主に、ＳＳＰ７０とＳＣＰ４２に記憶された演算ロジックとデータを変更するこ
とによって動作する。ＩＳＭＳ７８は、様々なユーザ・インタフェース８０およ
び８２を有する。このＩＳＭＳ７８は、操作線８４によってＳＣＰ４２に接続さ
れ、操作線８６によってＳＳＰおよびスイッチングシステム４４に接続され、操
作線９０によってインテリジェント周辺装置（Intelligent Peripheral）（「Ｉ
Ｐ」）８８に接続される。インテリジェント周辺装置８８は、音声応答システム
や音声認識システムなど、スイッチ上で利用できない機能をネットワークに追加
するために使用される装置である。ＩＰ８８は、信号線９２と伝送線９４によっ
てＳＳＰおよびスイッチングシステム４４に接続される。

【００１６】 次に図２を参照して、従来技術による呼の処理について説明する。顧客が受話
器を取ってダイヤルし始めたときに呼が行われる。会社ノスイッチモニターにあ
るＳＳＰ７０が、ダイヤリングを監視し、トリガ・シーケンスを認識する。ＳＳ
Ｐ７０は、サービス・ロジックを調べることができるまで呼のさらなる処理を中
断する。次に、ＳＳＰ７０は、標準的なＳＳ７メッセージを構成し、それをＳＴ
Ｐ７４を介してＳＣＰ４２に送る。ＳＣＰ４２は、メッセージを受け取ってデコ
ードし、ＳＬＰを起動する。ＳＬＩは、番号変換用のデータベース・ルックアッ
プなどの他の機能を作動させることができるＳＣＰを解釈する。ＳＣＰ４２は、
その呼の処理に関するＳＳ７メッセージをＳＳＰおよびスイッチングシステム４
４に返すか、あるいは適切なサービスを実行するためにネットワーク・エレメン
トにメッセージを送り出す。呼の終わりに、呼を切断するためにスイッチの間で
ＳＳ７メッセージが送られ、呼に関与する各スイッチが呼の詳細レコードを作成
する。呼の詳細レコードは、各呼ごとにオフラインで収集され、関連付けされ、
解決され、それにより市外通話の課金が導出され、呼の処理が完了する。

【００１７】 ＩＮおよびＡＩＮアーキテクチャは、予測可能なすべてのサービスをサポート
するために１組の標準機能を事前定義しようとする。そのような標準機能は、ス
イッチ内の様々な状態機械にすべてハードコードされる。残念ながら、新しい技
術または予想外のサービス要求と関連して生じる可能性のある新しい機能は、多
数のベンダ・プラットフォームに渡るネットワーク・ソフトウェアの広範囲なオ
ーバホールと試験なしには実現できない。さらに、新しい機能が、標準化された
呼出しモデル、プロトコルまたはインタフェースに対する変更を必要とする場合
は、その変更が業界標準グループによって承認されるまで、その機能を利用する
サービスの実現が遅れることがある。しかし、規格案が、ＩＮとＡＩＮがサポー
トする機能セットを拡大しようとしているにもかかわらず、装置の供給業者は、
コードの複雑さの驚異的な増大のために、そのような規格案を支持することを拒
絶してきた。

【００１８】 図２をさらに参照すると、ＩＮおよびＡＩＮアーキテクチャの他の制限は、ス
イッチ内で動作する呼処理機能と設備処理機能すなわちＳＳＰ７０を有すること
により生じる。その結果、これらの機能は、独自のソフトウェアを使用して各ス
イッチメーカーから提供されなければならない。したがって、ネットワーク所有
者は、新しい機能をサポートするためにメーカー・ソフトウェア・リリースにま
だ大きく依存している。問題をさらに複雑にするのは、ネットワーク所有者が、
統合された開発および試験環境において、ＳＳＰ７０モジュールを他のモジュー
ルと一緒に試験できないことである。さらに、スイッチメーカーの処理環境用の
ＳＳＰ７０が、ネットワーク所有者のサービス作成環境と互換性をもつという保
証はない。

【００１９】 このように複数のネットワーク所有者が共通の組のスイッチメーカーに依存す
ることにより、競合を制限する望ましくない２つの状況が生じる。第１に、メー
カーのソフトウェア・リリースは、いくつかのネットワーク所有者から要求され
た変更を組み込もうとすることがあり、それによりネットワーク所有者は、自分
たちのサービスを競合により提供されるサービスと真に区別することができない
。これにより、メーカーが新しいリリースに他のネットワーク所有者からの要求
を組み込むまで、いくつかのネットワーク所有者が待たされる。第２に、あるネ
ットワーク所有者から新しいサービスの実装を要求された機能を含むスイッチソ
フトウェア・リリースは、意図せずに他のネットワーク所有者に利用可能になる
ことがある。したがって、ＩＮおよびＡＩＮアーキテクチャの意図にもかかわら
ず、ネットワーク所有者が、ネットワーク・サービスの挙動を形づくる機能要素
を完全に制御したり利用したりできないため、ネットワーク所有者の新しいサー
ビスの作成、試験および展開はまだ妨げられる。

【００２０】 これらの問題を解決する１つの試みにおいて、全体が１５０（図１）として示
された個別スイッチインテリジェンスおよびスイッチ機構（Separate Switch In
telligence and Switch Fabric）（「ＳＳＩ／ＳＦ」）は、スイッチングシステ
ム４４からＳＳＰ７０を論理的に分離する。次にまた図１を参照すると、スイッ
チインテリジェンス１５２は、対応するハードコードされた状態機械エンジンに
よって個別の状態テーブルにおいてコード化され、円１５４と１５６で記号化さ
れた呼処理機能２４と設備処理機能２６を含む。スイッチ機構機能１５８とスイ
ッチインテリジェンス機能１５２との接続は、通信ネットワークによって拡張す
ることができ、その結果、スイッチ機構１５８とスイッチインテリジェンス１５
２は、物理的に一緒に配置されたり、同じプロセッサ内で実行されたり、さらに
１対１に対応する必要はない。その結果として、スイッチインテリジェンス１５
２は、すべてのスイッチに共通でサービスに固有でなくまたメーカーに固有でな
いな簡単な機能の整合性のあるインタフェースを提供する。

【００２１】 インテリジェント計算複合体（Intelligent Computing Complex）（「ＩＣＣ
」）１６０は、複数のスイッチインテリジェンス要素１５２と通信するサービス
処理機能２２および３０を含む。この手法は、ほとんどの基本機能がメーカー固
有のコードの領域の外に移動されるため、ネットワーク所有者に、フレキシブル
なサービス実装の利点を提供する。サービス・ロジックの作成、開発、試験およ
び実行のために、より統合された環境を提供することによって、さらなる改良を
実現することができる。

【００２２】 前に考察したように、現在のネットワークスイッチは、一体式で独自のハード
ウェアとソフトウェアに基づく。ネットワークスイッチは、数百万ドルのコスト
がかかることがあるが、そのような設備は、現在利用可能な計算技術の観点から
見たときに処理速度が比較的遅い。たとえば、そのようなスイッチは、６０ＭＨ
ｚのレンジで動作する縮小命令セット・コンピューティング（「ＲＩＳＣ」）に
基づき、一般にスイッチング網内の様々なプラットフォーム間で９．６ｋｂ／秒
の伝送速度をサポートするＸ．２５などのデータ通信プロトコルを使用して互い
に通信する。これは、２００ＭＨｚ以上で動作するプロセッサを含むパーソナル
・コンピュータと、１５０ｍｂ／秒ＦＤＤＩおよびＡＴＭインタフェースを提供
するハイエンド・コンピュータ・ワークステーションと比較してきわめて遅い。
したがって、ネットワーク所有者は、独自のハードウェアの代わりにハイエンド
・ワークステーションを使用できることが必要である。

【００２３】

【発明が解決しようとする課題】

本発明は、インテリジェント通信ネットワークの複数の分散サービス・ノード
のそれぞれと物理的に関連付けられたスイッチやルータなどのリソース複合体に
おいて受け取ったイベントおよびサービス要求をすべて処理するリアルタイムサ
ービスを提供するサービス制御システムを対象とする。

【００２４】

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

一般に、本発明のサービス制御コンポーネントは、サービス要求の処理におい
て、たとえばＡＴＭスイッチ、インターネット・ゲートウェイ、インテリジェン
ト周辺装置、他のスイッチまたはルータ・リソースなどのインテリジェント・ネ
ットワーク・リソース複合体に指示することができ、さらに、サービス要求を処
理するために必要なインテリジェンスを含む。詳細には、組み込まれたインテリ
ジェンスにより、サービス制御コンポーネントは他のインテリジェント・ネット
ワーク・コンポーネントと対話して他のロジックにアクセスするか、またはサー
ビス論理インスタンスを処理するのに必要な情報（サービスまたはユーザ・デー
タ）を獲得することができる。サービス制御は、リアルタイムサービス処理にお
いてリソース複合体およびローカル・データ管理システムと接続し対話し、イン
テリジェント・ネットワークが提供するサービスの試みを処理するのに必要な論
理および処理能力を保有する。サービス制御は、インテリジェント・ネットワー
クのサービス管理者とデータ管理コンポーネントによって管理、更新、管理され
る。インテリジェント・ネットワークは、呼を受け取る呼スイッチングプラット
フォームまたはリソース複合体に依存せずまたそれに対して透明なインテリジェ
ント呼処理サービスを提供し、呼イベントを処理するように容易に適合される。
したがって、高価なベンダ固有のハードウェア、オペレーティング・システムお
よびスイッチングプラットフォームへの依存がなくなる。分散インテリジェント
・ネットワークは、さらに、場所に依存しないイベント処理サービスの実行をサ
ポートし、モジュール式ソフトウェア論理プログラムを、アーキテクチャ内の実
質的にどこででも実行することができるようにし、そのような分散プロセス間の
場所に依存しない通信を実現し、したがって特別なサービス・ノードが不要にな
る。

【００２５】 より詳細には、本発明は、リソース複合体によってサービス制御コンポーネン
トにサービス要求が送られたときに開始される１つまたは複数のプロセスを制御
する。サービス制御は、他のコンポーネントと対話して、要求サービスを提供す
るのに必要な要求データにアクセスする。要求サービスの挙動シーケンスが完了
するかサービス・ユーザがサービスを使用するのをやめたとき、プロセスは完了
する。処理の終わりに、要求の代わりにサービス要求側にサービスを提供するこ
とに関わるすべてのリソースが開放される。各サービス要求は、サービス処理の
１つのインスタンス（スレッド）を開始し、それにより偶発性またはボトルネッ
クの少ない大量の並列処理が実現される。

【００２６】 各サービス・スレッドのインスタンスは、イベントと関連した所定の優先順位
に従って記憶し実行するための適切なサービス・スレッド待ち行列への特定の呼
インスタンスに関して、それ自体のイベント待ち行列を、受け取った非同期チャ
ネリング・イベントを提供するサービス制御によって維持することが好ましい。
サービス制御は、さらに、スイッチ／リソース複合体へのイベントの非同期チャ
ネリングを提供し、またはそれと一緒に他の実行サービス論理プログラムを提供
し、応答を待つときスレッド・インスタンスは遮られる。

【００２７】 本発明によれば、サービス制御コンポーネントの主な役割は、スイッチングプ
ラットフォームやその他の外部リソースからイベントまたは要求を受け取って処
理し、受けた要求を処理するためにサービス論理プログラムを識別し起動し、デ
ータ管理記憶装置からネットワーク・オペレーティング・システム（ＮＯＳ）を
介して、またはデータ・ベース・アプリケーション・プログラム・インタフェー
ス（ＡＰＩ）を介して直接、サービスまたは加入者に関連するデータを要求し、
ＮＯＳを介してサービスまたは加入者に関連するデータをデータ管理コンポーネ
ントに更新し、優先順位を付けたイベントとメッセージをリソース複合体または
その他の論理プログラムに送ってユーザの対話を制御する機能を提供し、リソー
ス複合体から、たとえばＰＩＮ、選択したメニュー項目などに対応するデュアル
・トーン・マルチ・フリケンシ）ＤＴＭＦ数字などのユーザ入力を含むメッセー
ジ・セットを受け取り、同じサービス処理インスタンスに含まれるすべての関与
物の状況とデータを維持し、課金レコードを生成してそれをデータ管理コンポー
ネントの課金レコード生成機能に送ることを含む。

【００２８】 本発明を特徴づける新規性の様々な特徴は、添付し本開示の一部を構成する特
許請求の範囲に詳細に示される。本発明とその動作上の利点およびその使用によ
り達成される特定の目的をより良く理解するために、本発明の好ましい実施形態
を例示し説明した図面および説明を参照されたい。

【００２９】 本発明の以上その他の利点は、添付図面と共に以下の説明を参照することによ
ってより良く理解することができる。

【００３０】

【発明の実施の形態】

本発明は、本明細書においてインテリジェント分散ネットワーク・アーキテク
チャ（Intelligent Distributed Network Architecture）（「ＩＤＮＡ」）また
は次世代インテリジェント・ネットワーク （Next Generation Intelligent Ne
twork）（「ＮＧＩＮ」）と代わりに呼ばれる包括的インテリジェント・ネット
ワークの１つのコンポーネントである。本明細書で説明するように、ＮＧＩＮア
ーキテクチャは、たとえばスイッチ、ルータ、ＩＰ終端アドレスなどのリソース
複合体またはスイッチングプラットフォームにおいて受け取った任意のタイプの
呼にインテリジェント呼処理サービスを実行するように設計される。ＩＤＮＡ／
ＮＧＩＮは、複数の分散したサービス・ノードを含み、各ノードは、その特定の
サービス・ノードと物理的に関連付けられたスイッチまたはリソース複合体にお
いて呼を受け取った場合にその呼を処理するのに必要な呼処理機能を提供する実
行環境を提供する。ＮＧＩＮは、きわめてスケーラビリティの高いアーキテクチ
ャであり、独立したサービス論理プログラム（Service Logic Program）（「Ｓ
ＬＰ」）として実施される実行可能なサービス・オブジェクトと、１−８００電
話呼やファックス送信などのイベント・サービスを実行するための関連データと
を、サービス・ノードにおいてコスト効率の高い方法で確実に展開し維持するこ
とができるように設計される。ＣＯＲＢＡ準拠のオブジェクト・リクエスト・ブ
ローカー技術を利用することによって、インテリジェント・ネットワークは、イ
ベントまたは呼を受け取るイベントスイッチングプラットフォームまたはリソー
ス複合体から独立しそれに対して透明な場所とプラットフォームに依存しない呼
処理サービスの実行をサポートし、サービス実行プラットフォームに関係なしに
事実上ネットワーク上のどこでも高レベルの論理プログラムを実行することを可
能にする。さらに、システムは、そのような分散プロセス間で場所に依存しない
通信を提供する。

【００３１】 次に図１を参照すると、インテリジェント分散ネットワーク・アーキテクチャ
（Intelligent Distributed Network Architecture）（「ＩＤＮＡ」）は、一般
に、１７０として示される。本発明は、ＳＳＩ／ＳＦアーキテクチャ１５０のＩ
ＣＣ１６０とスイッチインテリジェンス１５２をインテリジェント呼処理装置（
「ＩＣＰ」）１７２に統合する。状態テーブルによって機能が定義されたＳＳＩ
／ＳＦアーキテクチャ４０のＩＮまたはＡＩＮと違い、ＩＣＰ１７２は、ブロッ
ク１７４、１７６および１７８によって記号化されたオブジェクト指向プラット
フォームにおける管理対象オブジェクトとして、サービス制御機能２２、呼処理
機能２４および設備処理機能２６を含む。ＩＣＰ１７２は、リソース複合体１８
０から論理的に分離される。

【００３２】 次に図３を参照して、本発明によるインテリジェント分散ネットワーク・アー
キテクチャを利用する通信システムが示され、全体が２００として示される。広
域ネットワーク（「ＷＡＮ」）２０２は、広い地理的領域の全体にわたってアプ
リケーションとデータの配布をサポートするシステムである。転送ネットワーク
は、光同期伝達網（Synchronous Optical NETwork）（「ＳＯＮＥＴ」）に基づ
いて、ＩＤＮＡノード２０４を接続し、それらのノード内のアプリケーションが
互いに通信できるようにする。

【００３３】 各ＩＤＮＡノード２０４は、インテリジェント呼処理装置（「ＩＣＰ」）１７
２とリソース複合体１８０を含む（図１）。図３は、リソース複合体Ａ（「ＲＣ
Ａ」）２０６とリソース複合体Ｂ（「ＲＣＢ」）２０８を有するＩＤＮＡノード
２０４を示す。ＩＣＰは、設備提供、課金、復旧などの既存の支援機能を提供す
る補助処理装置２１０に連結することができるが、それらの機能は、ネットワー
ク管理システム（「ＮＭＳ」）２１２によって提供される機能に吸収されてもよ
い。しかしながら、好ましい実施形態において、図４（ａ）と関連して本明細書
で説明するように、それらの支援機能は、データ管理（Data Management）（「
ＤＭ」）コンポーネント４００を有する集中型のサービス管理（Service Admini
stration）（「ＳＡ」）システム５００によって提供することができる。図３に
さらに詳細に示したように、ＩＣＰ１７２は、シグナリング２１６と伝達リンク
２１４を有する直接リンク２１４によって、他のＩＣＰ１７２、他のネットワー
ク（図示せず）、または他の装置（図示せず）に連結することができる。直接リ
ンクは、接続された装置の間の待ち時間をなくし、装置が自己の言語で通信する
ことを可能にする。ＩＣＰ１７２は、ＩＤＮＡノード２０４の「頭脳」であり、
ＩＤＮＡノード２０４の処理要件によって、１つの記憶装置を備えた１つの処理
装置から大規模コンピュータ・ネットワークにわたることができる汎用コンピュ
ータであることが好ましい。汎用コンピュータは、冗長処理、メモリ記憶および
接続を有する。

【００３４】 汎用コンピュータは、本明細書で使用されるとき、電話のスイッチング用に特
別に構成され設計された専用の装置と対照的な商用既製コンポーネントまたはそ
れにより組み立てることができるコンピュータのことを指す。呼ネットワーク内
の汎用コンピュータの統合は、多数の利点を提供する。

【００３５】 汎用コンピュータを使用することにより、ＩＣＰ１７２は、高い処理要求を満
たすために付加的なハードウェアで拡張する機能が与えられる。そのような付加
物は、処理能力、データ記憶および通信帯域幅を高める機能を含む。そのような
付加物は、呼ネットワーク内の各スイッチのメーカー固有のソフトウェアおよび
／またはハードウェアの変更を必要としない。したがって、スイッチング網内の
個々の装置を修正することなく新しいサービスとプロトコルを全般的なスケール
で実装しインストールすることができる。一体式スイッチ２０（図１）からイン
テリジェント呼処理装置１７２への変化は、本発明に、以上の利点と高い機能を
提供する。

【００３６】 より高い処理能力を必要とする用途の場合には、マルチプロセッシングによっ
て、より安価なプロセッサを使用して呼処理の価格／性能比を最適化することが
できる。他の用途では、より高い処理速度を有するミニコンピュータなどのより
高性能な装置を使用することが有利であったり必要であったりコスト効率が高か
ったりすることがある。

【００３７】 前に述べたように、ＩＣＰ１７２は、たとえばＵＮＩＸ（登録商標）またはＷ ｉｎｄｏｗｓ ＮＴ（登録商標）オペレーティング・システム上で動作する汎用 コンピュータのクラスタを含む。たとえば、１つのリソース複合体で最大１００ ，０００ポートをサポートする大きなアプリケーションでは、ＩＣＰ１７２は、 対称型マルチプロセッサ・クラスタにおいて３３３ＭＨｚで動作する１６個の３ ２ビット・プロセッサからなる。たとえば、プロセッサを、それぞれ４つのプロ セッサを備えた別個の４つのサーバに分割することができる。個々のプロセッサ は、システム・エリア・ネットワーク（System Area Network）（「ＳＡＮ」） やその他のクラスタ化技術によって接続される。プロセッサ・クラスタは、Redu ndant Array of Independent Disks（「ＲＡＩＤ」）モジュール式データ記憶装 置へのアクセスを共用することができる。共用される記憶装置は、モジュール式 ディスク装置を追加したり除去することによっって調整することができる。クラ スタ内のサーバは、ＲＣ１８０（図１）に対する冗長リンクを共用することが好 ましい。

【００３８】 図に示しパーソナル・コンピュータの「プラグ・アンド・プレイ」機能と同じ
ように、ＩＣＰソフトウェア・アーキテクチャは、（１）管理ソフトウェア、（
２）ＩＣＰアプリケーション、（３）計算ハードウェアおよびソフトウェア、（
４）リソース複合体コンポーネント、ならびに（５）サービス・アーキテクチャ
および処理の互換性を可能にするオープン処理モデルである。そのような汎用ア
ーキテクチャは、標準化により保守コストを削減し、量産効果によって得られる
利益を提供する。

【００３９】 したがって、本発明は、開発作業の分割とモジュール式ツールの使用を可能に
し、それによりサービスの開発と実装が高速化する。さらに、サービス管理の使
用と関連する側面は、固定されたメッセージング・プロトコルまたは所与のメー
カーから供給されるハードウェアとソフトウェアの特定の組合せにより受ける制
約と対照的に、必要な基準に基づくネットワーク・オペレータの制御の範囲内に
ある。

【００４０】 管理対象オブジェクトの使用により、本発明は、また、容量や使用量などの任
意数の要因に基づいて、ネットワークの全体にサービスと機能をフレキシブル（
「望む場所に」）かつ動的に（「実行中に」）分散させることができる。サービ
ス処理２２（図１）、呼出し処理２４（図１）および設備処理２６（図１）が同
種のプラットフォームで動作するため、性能が向上する。さらに、本発明は、以
前に利用できなかった呼サブエレメントの監視と処理を可能にする。本発明は、
また、機能とサービスを監視し、それらが旧式になったり使用しなくなったりし
たときにそれらを削除することができる。

【００４１】 リソース複合体（System Area Network）（「ＲＣ」）１８０（図１）は、伝
送、シグナリングおよび接続サービスを提供する物理装置またはリソースの集合
である。インテリジェント周辺装置８８を含むことができるＲＣ１８０は、ＩＮ
またはＡＩＮあるいはＳＳＩ／ＳＦアーキテクチャのスイッチ機構２８および１
５８（図１）と置き換わる。ＩＮまたはＡＩＮアーキテクチャと違って、ＲＣＡ
２０６などのリソース複合体の制御は低レベルである。さらに、ＲＣＡ２０６は
、複数のスイッチ機構１５８を含むことができる。スイッチ機構１５８や他の顧
客インタフェース（図示せず）は、標準的な電話接続によって複数の加入者およ
びスイッチング網に接続する。そのような顧客システムは、ＩＳＤＮ端末５２、
ファックス装置２２０、電話５４およびＰＢＸシステム２２２を含むことができ
る。ＩＣＰ１７２は、高速データ通信パイプ（最低１００ｍｂ／秒のイーサネッ
ト（登録商標）接続）２２４を介してＲＣ１８０（図１）、ＲＣＡ２０６および ＲＣＢ２０８と通信する。ＲＣ１８０、２０６および２０８は、プリンタと類比 することができ、ＩＣＰ１７２は、パーソナル・コンピュータに類比することが でき、ここでパーソナル・コンピュータは、ドライバを使用してプリンタを制御 する。ＩＤＮＡノード２０４内の「ドライバ」は、図５を参照して後で説明する リソース複合体プロキシ（Resource Complex Proxy）（「ＲＣＰ」）（図示せず ）である。これにより、メーカーは、ＩＤＮＡモデルを組み込むためにすべての ソフトウェアを書き換えることなく、このインタフェースを使用してＩＤＮＡ準 拠ノードを提供することができる。

【００４２】 さらに、リソース複合体１８０（図１）、ＲＣＡ２０６およびＲＣＢ２０８の
制御は、一般にＡＩＮまたはＩＮアーキテクチャによって提供されるものよりも
低いレベルにある。その結果、リソース複合体メーカーは、設備およびネットワ
ーク管理処理をサポートするために１つのインタフェースを提供するだけでよく
、特定の呼およびサービスの処理をネットワーク所有者に提供する必要がない。
低レベルのインタフェースが、より個別の操作に抽出される。インタフェースが
１つであるため、ネットワーク所有者は、価格と性能に関する決定に基づいて、
広い範囲のリソース複合体から選択することができる。インテリジェンスは、Ｒ
Ｃ１８０ではなくＩＣＰ１７２に追加され、ＲＣ１８０が変更から分離され、そ
の複雑さが減少する。ＲＣ１８０の役割が簡素化されるため、変更がより容易に
行なわれ、それにより、非同期転送モード（Asynchronous Transfer Mode）（「
ＡＴＭ」）などの代替のスイッチングおよび伝送技術への移行が容易になる。

【００４３】 インテリジェント周辺装置（Intelligent Peripheral）（「ＩＰ」）８８は、
実際の呼伝送経路に含まれる情報を処理しそれに基づいて動作する機能を備える
。ＩＰ８８は、一般に、ＲＣＢ２０８などの個別のリソース複合体の中にあり、
ＲＣＡ２０６と同じようにＩＣＰ１７２によって制御される。ＩＰは、ディジタ
ル信号処理（Digital Signal Processing）（「ＤＳＰ」）技術を使用してリア
ルタイムで呼伝送経路内のデータを処理する機能を提供することができる。

【００４４】 ネットワーク管理システム（Network Management System）（「ＮＭＤ」）２
１２は、ＩＤＮＡネットワーク２００内のハードウェアとサービスを監視し制御
するために使用される。提案されるＮＭＳ２１２の実施態様は、ＩＤＮＡネット
ワーク２００内のコンポーネントの管理を行う電気通信管理網（Telecommunicat
ions Management Network）（「ＴＭＮ」）準拠のフレームワークでよい。より
具体的には、ネットワーク管理システム２１２は、サービスの展開を制御し、そ
れらのサービスの健康を維持し、それらのサービスに関する情報を提供し、ＩＤ
ＮＡネットワーク２００のネットワーク・レベル管理機能を提供する。ＮＭＳ２
１２は、ＩＤＮＡノード２０４内のエージェント機能によりサービスおよびハー
ドウェアにアクセスしてそれを制御する。ＩＤＮＡノード２０４内のＩＣＰ−Ｎ
ＭＳエージェント（図示せず）は、ＮＭＳ２１２から出されたコマンドまたは要
求を実行する。ＮＭＳ２１２は、標準の操作リンク２２６によってＲＣＡ２０６
とＲＣＢ２０８を直接監視し制御する。

【００４５】 さらに図３に示したように、管理対象オブジェクト環境（Managed Object Cre
ation Environment）（「ＭＯＣＥ」）２２８は、ＩＤＮＡネットワーク２００
内で実行するサービスを作成するサブコンポーネントを含む。サービス設計者が
新しいサービスを作成するために使用するサービスに依存しない構成単位および
ＡＰＩ表現は、ＭＯＣＥの主要サブコンポーネントであるグラフィック・ユーザ
・インタフェース（「ＧＵＩ」）に埋め込まれる。ＭＯＣＥ２２８は、サービス
作成（Service Creation）（「ＳＣ」）環境とも呼ばれる１つのユーザ環境また
はプラットフォームのホストとして働くツールの統合された集まりである。これ
は、管理対象オブジェクトおよびサービス試験に含まれるサービス・ドキュメン
テーション、管理対象オブジェクトの定義、インタフェースの定義、プロトコル
の定義、データ入力の定義などのサービス作成のプロセス全体に必要とされる処
理の集まりである。管理対象オブジェクトは、ネットワーク上のすべてのノード
に適用することができるため、ネットワーク所有者は、ＭＯＣＥ２２８を使用し
て１度に１つのサービスを開発するだけでよい。これは、様々なスイッチメーカ
ーのそれぞれにそのメーカーのバージョンのサービスを開発させ、それによりサ
ービスを何度も開発しなけばならないネットワーク所有者と対照的である。

【００４６】 ＭＯＣＥ２２８とＮＭＳ２１２は、レポジトリ２３０を介して接続される。レ
ポジトリ２３０は、ＮＭＳ２１２によって配布されＩＤＮＡ／ＮＧＩＮノード２
０４内で使用される管理対象オブジェクトを含む。レポジトリ２３０は、また、
ＭＯＣＥ２２８とＮＭＳ２１２の間のバッファを提供するが、ＭＯＣＥ２２８は
、点線２３２で示された「生の」ネットワーク試験を実行するためにＮＭＳ２１
２に直接接続されてもよい。

【００４７】 図４（ａ）に示したような本発明の好ましい実施形態によれば、ＩＤＮＡ／Ｎ
ＧＩＮシステムは、追加された機能と共に、記憶（レポジトリ）２３０機能とＩ
ＤＮＡシステム１７０の汎用ネットワーク管理（ＮＭＳ）２１２機能の両方を提
供する集中されたサービス管理（Service Administration）（「ＳＡ」）コンポ
ーネント５００を含む。一般に、図４（ａ）に示したようなＳＡコンポーネント
５００は、ＩＤＮＡ／ＮＧＩＮシステムのすべてのサービスとデータのオフライ
ン記憶、命名、配布、活動化および除去をサポートし、さらに、ＩＤＮＡ／ＮＧ
ＩＮサービス・ノード内のサービス・オブジェクトによって使用されるデータの
実行時記憶、複製、同期および利用を可能にするデータ管理（「ＤＭ」）機能を
提供する。

【００４８】 より詳細には、図４（ｂ）に概念的に示したように、サービス管理コンポーネ
ント５００は、ＩＤＮＡサービス処理ノードによって使用されるすべてのサービ
スとサービス・データを管理、記憶、配布し、システムＩＤＮＡ／ＮＧＩＮに実
装されたハードウェア・コンポーネントとソフトウエア・コンポーネントの両方
を構成するために必要なすべての機能を実行するコンポーネントである。一般に
、図４（ｂ）において示したように、ＳＡコンポーネント５００の役割は、ＭＯ
ＣＥ（サービス作成）２２８からデータを受け取り、受注やその他のレガシ・シ
ステム２２９から顧客注文データ５０２を受け取り顧客の使用のためにＩＤＮＡ
／ＮＧＩＮシステムに供給し、たとえばサービス作成プロセス中に、たとえばＭ
ＯＣＥ／ＳＣＥユーザによる要求に応じて、データ、サービスに依存しない構成
単位（Service Independent Building Block）（「ＳＩＢＢ」）、サービス論理
プログラム（Service Logic Program）（「ＳＬＰ」）および他のサービス・ロ
ジック・コンポーネント５０３を、たとえばＭＯＣＥ２００に展開し、ＭＯＣＥ
２２８から、完成し試験済みのサービス・パッケージ、ＳＩＢＢ、ＳＬＰその他
のサービス・ロジックまたはデータ・コンポーネント５０６を受け取り、各サー
ビス・コンポーネントに独特な名前を提供し、本明細書において後でより詳細に
説明するように、データと各サービス・コンポーネント５０９をデータ管理機能
コンポーネント６００に配布することである。さらに、図４（ａ）に示したよう
に、サービス管理３００は、データ管理コンポーネント６００がそのデータをす
べての受け取るすべてのＩＤＮＡサービスとデータを含むグローバルなレコード
・データベース（Database of Record）（「ＤＢＯＲ」）を含むレポジトリ２３
０を維持する。

【００４９】 サービス管理のその他の役割は、データおよびサービス・コンポーネント５１
２を活動化させて、データ、ＳＩＢＢおよび管理対象オブジェクトまたはサービ
ス論理プログラムＳＬＰが、データ管理コンポーネント６００を介してノードに
利用可能になることを保証し、後で詳細に説明するように、データ、ＳＬＰおよ
びＳＩＢＢ５１５の名前を、登録のために、その論理名をネットワーク・オペレ
ーティング・システム（「ＮＯＳ］）コンポーネント７００に送ることによって
登録し、データおよびサービス・コンポーネント５１８を停止させ、データ管理
コンポーネント６００を介してＩＤＮＡ／ＮＧＩＮシステムからデータとサービ
ス５２１を取り除くことを含む。サービス管理は、さらに、命名プロセスによる
改訂の他に、それぞれのＳＩＢＢおよびサービスの状態（前試験済み、後試験済
み、展開済みなど）を維持することによってコンフィギュレーション管理機能を
実行する。これにより、そのサービスのすべてのコンポーネントを首尾良く試験
し構成できるまでサービスが展開されないことが保証される。

【００５０】 図４（ｂ）にさらに詳しく示したように、サービス管理コンポーネント５００
は、さらに、ＳＡが受け取るコンフィグレーション情報にしたがってＩＤＮＡ／
ＮＧＩＮサービス・ノード２０４を構成し供給する機能を実行する。詳細には、
受け取ったコンフィグレーション情報に基づいて、ＳＡコンポーネント５００は
、各サービス・ノード２０４ｈにおける各コンポーネントの機能、どのサービス
とデータをどのノードに配布するか、サービス・ノードにあるどのサーバでサー
ビスを行うか、およびＩＤＮＡ／ＮＧＩＮノード・サーバと関連したローカル・
メモリ・レジデントにどのデータをキャッシュするかを決定する。詳細には、Ｓ
Ａは、各サービス・ノードに配置されたローカルＬＥＮキャッシュに記憶するた
めに、サービス・プロファイル（コンフィグレーション）ファイル５８０に含ま
れるコンフィグレーション規則を、ＮＯＳシステム７００のローカル（ノード）
リソース管理（「ＬＲＭ」）コンポーネント５７５に展開する。そのようなコン
フィグレーション・ファイル５８０は、ＩＤＮＡノードで実行するサービスを決
定する。ＬＥＮは、最初に、そのノードのローカル・キャッシュに記憶されたこ
のサービス・プロファイル・ファイル５８０を読み取り、サービス・プロファイ
ル・ファイル内の規則に従ってサービスを実行する特定のサービス層実行環境（
Service Layer Execution Environment）（「ＳＬＥＥ」）たとえば仮想機械を
決定し、ＳＬＥＥにおいて（永続的なオブジェクトとして）活動的に実行するか
または要求時のみインスタンス生成するサービスを決定する。

【００５１】 図４（ａ）を再び参照すると、ＮＧＩＮデータ管理コンポーネント６００は、
サービスのライフサイクルとサービスの利用機能力の両方において機能する。サ
ービス管理コンポーネントが、グルーバルなレコード・データ・ベース（レポジ
トリ）を維持す場合は、データ管理コンポーネント６００は、それぞれのＩＤＮ
Ａ／ＮＧＩＮサービス・ノードにローカル・データ記憶とデータ管理機能を提供
する。これは、サービス・プログラムおよびＳＩＢＢ、サービス用のデータ（顧
客プロファイル、電話番号など）、マルチメディア・ファイル（対話型音声応答
（Interactive Voice Response）（「ＩＶＲ」）用の音声ファイルなど）などを
含むすべてのタイプのデータを含む。具体的には、サービス・ノードのデータ管
理コンポーネント６００は、サービス管理によって指定されたようなローカルＮ
ＧＩＮサービスによって実行されるサービスに必要なすべてのデータを含むＳＡ
グローバルＤＢＯＲの抽出物を受け取る。このメカニズムは、図４（ｃ）と関連
して後でより詳細に説明する。

【００５２】 好ましい実施形態において、ＳＡコンポーネントのデータ管理コンポーネント
６００は、各ＩＤＮＡ／ＮＧＩＮサービス・ノードにローカル・データ記憶およ
び管理機能を提供する。詳細には、データ管理は、サービス管理から受け取った
データを１つまたは複数のデータ・ベースに記憶し、必要なデータをサービス制
御コンピュータ内のメモリ・レジデントまたは同じ場所に配置されたデータベー
ス・サーバ上にキャッシュすることによってサービス／データをサービス制御環
境に容易に使用可能にし、それにより、サービス／データを最小の待ち時間でサ
ービス制御サービスに提供することができる。より一般的には、データ管理コン
ポーネント６００は、サービス管理から受け取ったかサービス処理の結果受け取
ったかに関係なく、リアルタイム記憶、複製、同期、およびデータの利用を実行
する。そのようなＤＭ機能は、１）データ・レポジトリ機能、２）データ操作機
能、３）データ利用機能、および４）課金レコード生成機能としてさらに分類す
ることができる。

【００５３】 次に図５を参照して、本発明によるインテリジェント分散ネットワーク・アー
キテクチャ２００を使用する通信システムの論理機能図を説明する。ＩＣＰ１７
２は、管理対象オブジェクト基本クラス２４４から得られた様々な管理対象オブ
ジェクト２４６、２４８、２５０および２５２をホストとして処理するＩＣＰ−
ＮＭＳエージェント２４０とＳＬＥＥ２４２を含むように示される。

【００５４】 一般に、管理対象オブジェクトは、ソフトウェア機能を実装するメソッドであ
り、各管理対象オブジェクトは、管理対象オブジェクトの機能を実現するために
機能インタフェースと管理インタフェースの両方を提供する。管理インタフェー
スは、管理対象オブジェクト機能を利用することができる人と物へのアクセスを
制御する。本発明において、ＩＤＮＡ／ＮＧＩＮノード２０４によって実行され
るインフラストラクチャ・ソフトウェアを除くすべての電話用アプリケーション
・ソフトウェアは、管理対象オブジェクトと支援ライブラリとして展開される。
これは、ＩＤＮＡノード・ソフトウェアを制御し管理するための統一されたイン
タフェースと実装を提供する。

【００５５】 ノードによって処理される伝送トラヒックを接続し経路指定し終端するネット
ワーク・エレメントの集合は、集合的にリソース複合体（「ＲＣ」）と呼ばれる
。ＳＬＥＥ上で実行されるサービス処理アプリケーションは、ＲＣ１８０への制
御インタフェースとしてリソース・プロキシ（Resource Proxy）（「ＲＣＰ」）
２４４を使用する。ＲＣＰ２４４はデバイス・ドライバに連結され、ＳＬＥＥ内
のオブジェクトからの装置に依存しないコマンドをＲＣ１８０によって実行され
る設備固有のコマンドに適用することができる。ＲＣＰ２２４は、ＲＣＰ２４４
内の資産のベンダ間に共通の基本コマンドを実現するインタフェースとして説明
することができる。ＲＣＰ２４４は、図示したように、ＩＤＮＡノード２０４上
で動作する１つまたは複数の管理対象オブジェクトとして実現することができる
。代替として、この機能をＲＣ１８０の一部として提供することができる。ＮＭ
Ｓ２１２、レポジトリ２３０およびＭＯＣＥ２２８は、図３〜図５（ａ）の考察
でそれらの要素の説明と一致している。

【００５６】 操作リンク２２６がＮＭＳ２１２をＲＣ１８０に直接接続することに注意され
たい。これは、ネットワーク・ハードウェアの動作状況を監視する際のネットワ
ーク管理システムのより伝統的な役割に対応する。これは、ＩＤＮＡアーキテク
チャと独立に行うことができる（たとえば、周知のＴＭＮ手法を使用して）。さ
らに、ＲＣ１８０を他のリソース複合体２５４に接続することができる。また、
ＳＳ７などの信号２１６が呼処理環境に直接入ることができるようにＩＣＰ１７
２に入る直接信号リンク２１４が示される。ネットワーク周囲で信号を遮ること
によって、ＳＳ７メッセージは、ＲＣ１８０を通ることなくＩＣＥ１７２に直接
進むことができる。これにより、信号経路が短くなることによって待ち時間が減
少し頑強性が向上する。これに伴う伝送線２１８が、ＲＣ１８０に接続する。

【００５７】 図６は、ＩＣＰ１７２内の機能インタフェースの階層化を示す。ＭＯＣＥ２２
８は、管理対象オブジェクト・ソフトウェアとその従属物を生成するシステムで
ある。ＮＭＳ２１２は、ＩＣＰ−ＮＭＳエージェント２４０と呼ばれるＩＣＰ１
７２内に提供されるエージェント機能に接続することによってＩＣＰ１７２の実
行を制御する。ＮＭＳ２１２は、ＩＣＥ１７２上のローカル・オペレーティング
・システム（Local Operating System）（「ＬＯＳ」）２６０の動作を制御する
。ＮＭＳ２１２は、プロセスの開始と停止、プロセス・テーブルの内容およびプ
ロセスの状況の問い合わせ、オペレーティング・システム・パラメータの構成、
およびＩＣＰ１７２のホストとして働く汎用コンピュータ・システムのパフォー
マンスの監視を含むＩＣＥ１７２の動作を制御する。

【００５８】 ＮＭＳ２１２は、また、広域ネットワーク・オペレーティング・システム（Wi
de Area Network Operating System）（「ＷＡＮＯＳ」）２６２の動作を制御す
る。ＮＭＳ２１２は、ＷＡＮＯＳ支援プロセスの初期設定と動作およびＷＡＮＯ
Ｓライブラリの構成を、ＬＯＳ２６０のその制御ならびにＮＭＳ ＳＬＥＥ制御
によって提供される他のインタフェースを介して制御する。ＮＭＳ２１２は、Ｉ
ＣＥ１７２上で動作する１つまたは複数のＳＬＥＥ２４２のインスタンス生成と
動作を制御する。ＬＯＳ２６０は、汎用コンピュータを操作するための市販の既
製オペレーティング・システムである。ＷＡＮＯＳ２６２は、計算ノード間のシ
ームレスな通信を容易にする市販の既製ミドルウェア・ソフトウェア・パッケー
ジ（たとえば、オブジェクト・リクエスタ・ブローカー）である。ＳＬＥＥ２４
２は、サービス処理アーキテクチャを実現するソフトウェア・インスタンスであ
る管理対象オブジェクト２４４の実行のホストとして働く。ＳＬＥＥ２４２は、
ＩＣＰ−ＮＭＳエージェント２４０による管理対象オブジェクト２４４の実行を
制御する手段を実現する。したがって、ＳＬＥＥ２４２インスタンスは、管理対
象オブジェクト・ソフトウェアの展開と削除、管理対象インスタンスのインスタ
ンス化と抹消、管理対象オブジェクトの対話と協力の支援、固有ライブラリ（Na
tive Library）２６４に対するアクセスの管理、および必要な制御を実現する際
のＮＭＳ−ＩＣＰエージェント２４０との対話を可能にするソフトウェア・プロ
セスである。

【００５９】 固有ライブラリ２６４は、ＬＯＳ２６０またはＷＡＮＯＳ２６２と固有の汎用
コンピュータ実行（たとえば、コンパイル済みのＣライブラリ）のみに依存する
ようにコード化されたライブラリである。これらは、主に、ＳＬＥＥ２４２によ
って提供される固有の機能を補うために使用される。

【００６０】 ＳＬＥＥライブラリ２６６はＳＬＥＥ２４２において実行するためにコード化
されたライブラリである。それらは、ＳＬＥＥ２４２および固有ライブラリ２６
４によって提供される機能をアクセスすることができる。管理対象オブジェクト
２４４は、ＳＬＥＥ２４２によってロードして実行されるソフトウェアである。
それらは、ＳＬＥＥ２４２とＳＬＥＥライブラリ２６６（および恐らく在来のラ
イブラリ２６４）によって提供される機能を利用することができる。

【００６１】 ＩＣＰ−ＮＭＳエージェント２４０は、ＮＭＳ２１２にＩＣＥ１７２の操作を
制御する能力を提供する。ＩＣＰ−ＮＭＳエージェント２４０は、ＬＯＳ２６０
の動作と構成、ＷＡＮＯＳ２６２の動作と構成、およびＳＬＥＥ２４２のインス
タンス化と動作を制御する能力を実現する。提案されたサービス処理アーキテク
チャは、高抽象化層において動作する。しかしながら、ＳＬＥＥ２４２の斜視図
から、ＮＭＳ２１２の制御下で対話するオブジェクト層（ソフトウェア・インス
タンス）である管理対象オブジェクト層２４４と、管理対象オブジェクト２４２
またはＳＬＥＥ２４２自体の動作に補足機能を提供するソフトウェア層（ＳＬＥ
Ｅ２４２とＬＯＳ２６０のどちらかに固有）であるライブラリ層２６４または２
６６の２つの層しかないことが分かる。しかしながら、ある時点で、ＮＭＳ２１
２が、管理対象オブジェクト・インスタンスの正確な場所の制御を放棄する可能
性があることが予想される。たとえば、管理対象オブジェクト・インスタンスは
、要求に応じるような１つまたは複数のアルゴリズムまたはイベントに基づいて
、あるノードから別のノードに移動することができる。

【００６２】 集合的に、ＬＯＳおよびＷＡＮＯＳの機能は、図６に示したように、ＩＤＮＡ
／ＮＧＩＮシステム・コンポーネント間にプラットフォームに依存せず場所に依
存しない接続機能を提供する働きをするネットワーク・オペレーティング・シス
テムまたは「ＮＯＳ」として表すことができることを理解されたい。すなわち、
ＮＯＳは、他のＩＤＮＡ／ＮＧＩＮ機能コンポーネントとサブコンポーネント間
のプロセス・インタフェースと通信を提供する１組のネットワーク全体にわたる
サービスを含む。ＮＯＳによって提供されるサービスの間には、オブジェクト接
続性、論理名変換、プロセス間通信、ならびにローカルおよびシステム・ワイド
・リソース管理（「ＲＭ」）がある。たとえば、図４（ａ）に示したように、Ｎ
ＯＳコンポーネント７００は、ローカル（ＮＯＤＥ ＲＭ）およびシステム・ワ
イド・リソース管理（ＳＹＳ ＥＭ）機能を提供する。詳細には、ＮＯＳコンポ
ーネントは、サービスとデータを必要とするプロセスからサービスの場所をカプ
セル化し、したがってプロセスは、１つの論理名を呼び出すだけでよい。次に、
ＮＯＳコンポーネントは、サービスのどのインスタンスを使用するかを決定し、
そのインスタンスに接続性を提供する。ＮＯＳ７００は、部分的に、ＩＤＮＡ／
ＮＧＩＮの広く分散した性質と、ＩＤＮＡ／ＮＧＩＮのプラットフォーム独立性
の両方を使用可能にする。たとえば、前述の論理プログラムは、ＮＯＳコンポー
ネント７００を使用して他の論理プログラムを呼び出し、その結果同じサービス
・ノードまたはリモート・サービス・ノードの異なるＳＬＥＥ上で動作する他の
論理プログラムを呼び出して起動することができる。詳細には、ＳＡ５００によ
り、あるサービスだけを実行するようにサービス・ノードを指定することができ
る。たとえばカンファレンス・ブリッジの接続のような必要なサービスを実行で
きない関連サービス・ノード２０４を有するスイッチに呼が到着したとき、ＩＤ
ＮＡは、そのようなサービスを提供するように構成された別のノードに呼を送ら
なければならないことがある。ＩＤＮＡは、ＮＯＳコンポーネント７００を介し
て、別のリモート・サービス・ノードにある必要なサービスを呼び出し、呼処理
を実行し、元のノードにあるスイッチにサービス応答を提供することが好ましい
。

【００６３】 次に、図７を参照して、本発明によって管理されたオブジェクトのクラス階層
（ヒエラルキー）を説明する。アブストラクトベースクラス管理オブジェクト２
４４は共通の機能性および派生されたすべてのクラスがＳＬＥＥ２４２において
オブジェクトとして適切に支持され得ることを保証するためにバーチャル機能を
含んでいる。とくに、４つの異なったサブクラス、すなわち、サービス制御クラ
ス２５２、コール制御クラス２５０、支持体制御クラス２４８、オブジェクトリ
ソースプロキシクラス２４６が示されている。

【００６４】 サービス制御クラス２５２はすべてのサービス機能オブジェクト用のベースク
ラスである。セッションマネージャークラス２８０はセッション関連情報および
活動をカプセル化している。セッションはネットワーク機能の１またはそれ以上
のコールまたは他の呼びかけからなることもできる。セッションマネージャーク
ラス２８０は各セッションに対して唯一の識別子を設けている。コール処理が交
点方法で行われるならば、その場合に請求書作成（ビリング）情報が照合されね
ばならない。各コール用の唯一の識別子は、コスト的に高い照合処理を必要とす
るのに代わって、照合を容易にする。サービス処理において、プロトコルは連続
する抽象概念層によって包まれている。結局、プロトコルはセッションマネージ
ャーの割り当て／例示を正当化するように十分に抽象される（例えば、ＳＳ７に
おいて、ＩＡＭメッセージの受信はセッションマネージメントを有して正当化す
る）。

【００６５】 支持体能力クラス２８２は支持体上のサービスの品質を変化する。サービス制
御クラス２５２はコールのサービスの品質（“ＱｏＳ”）の変化を可能にするか
または同様に５６Ｋｂｉｔ／ｓからより高い割合への移動かつ次いで降下のごと
き、支持体能力を変化することができる。ＱｏＳは接続マネージャークラス３０
２にって管理される。例えば、ハーフレートサブクラス２８４はコールのＱｏＳ
を、通常の８Ｋｈｚのサンプルレートに代えて、４Ｋｈｚのサンプルレートに低
下させる。ステレオサブクラス２８６は左方チャンネルおよび右方チャンネルを
支持するために使用者にコールの２つの接続の形成を許容するかも知れない。

【００６６】 サービスアービトレーションクラス２８８はサービスの対立およびサービスの
相互作用の調停を集大成する。これは、サービス制御クラス２５２が、とくに開
始および終了サービスで対立し得るため必要とされる。多くの実用的な理由のた
めに、各サービス制御クラス２５２内にサービス制御クラス２５２の他の型との
対立を如何に解決するかの認識を符号化するのは望ましくない。代わりに、対立
が識別されるとき、対立するサービスおよびそれらの未決の要求に対する参照が
サービスアービトレーションクラス２８８に通される。サービスアービトレーシ
ョンクラス２８８は、その場合に、多分、局部的な背景、形状データ、および対
立するサービスに対す次の質問を考慮して、適切な行動コースを決定することが
できる。サービスアービトレーションクラス２８８を有することは、ハードコー
ド化または絶対の機構に対向されるような、明白な文書化および対立解決のアル
ゴリズムの符号化を許容する。そのうえ、サービスが更新されるかまたは追加さ
れるとき、現存するサービスは、単一のサービス内で多数の関係の変化を必要と
し得るあらゆる対立の変化を明らかにするように更新されなくてもよい。

【００６７】 特徴クラス２９０は電話による通信と連係する能力の標準セット（例えば、３
方向呼び出し、キャッチホン）を実行する。このような１つの能力は予定された
受信者に到達するために現存するコールを接続解除の発生を可能にするオーバラ
イド２９２にすることができる。他の共通の能力はコールブロック２９４を含む
ことができ、それにより開始申込みが開始についての１組の規準に基づいて拒絶
され得る。

【００６８】 サービス識別クラス２９６はコール処理の間中他のサービスを選択的に引き起
こしかつサービスそれ自体として下位に分類される。サービス識別クラス２９６
は柔軟な、背景感知サービス活動を備えかつサービスを活動させるときに決定す
るための各サービス内に固定したコードを有する必要を除去する。活動シーケン
スはサービスそれ自体から隔離されている。例えば、加入者Ａおよび加入者Ｂは
同一組の特徴にアクセスし得る。加入者Ａは特定の組の信号を使用して彼のサー
ビスの１またはそれ以上を選択的に呼び出すように選ぶ。加入者Ｂは彼のサービ
スを活動させるために異なる組の信号を使用するのが好ましい。加入者間の唯一
の差異は彼らが彼らのサービスを活動させる方法である。そこで、選択方法をサ
ービスそれ自体から仕切るのが望ましい。利用可能な２つの解決がある。加入者
ＡおよびＢのサービス選択方法が別個のサービス識別クラス２９６において符号
化され得るか、またはサービス識別クラス２９６が適切な情報を指示するために
加入者当たりの輪郭を使用することができる。これはそのサービスセットが解体
されるより多くの使用者に適用されるように導き出され得る。さらに、サービス
識別クラス２９６の使用は付与されたコールの背景または進展に基づいてサービ
スへのアクセスのマッピングを変更することを可能にする。このクラスの実行は
、多分種々の活動入力を使用して種々のサービスを多数のコール関係者に利用さ
せ得る。従来技術においては、すべてのスイッチ売り主が、この能力を阻止した
、柔軟性のないサービス選択スキームを供給した。

【００６９】 メディア独立サービスクラス２９８は、音声、フックス、ｅメールおよびその
他のを含んでいる種々のメディアの型に適用される、記憶および送信３００、放
送、方向変換、先取り（プリエンプション）、ＱｏＳおよび多者接続のごとき、
サービス制御クラス２５２の１型式である。サービス制御クラス２５２が各メデ
ィア型式に適用され得るように開発されるならば、その場合に、サービス制御ク
ラス２５２は再使用可能なサービス制御クラス２５２に押し進められ得る。サー
ビス制御クラス２５２がメディア依存機能およびメディア独立機能（すなわち、
サービスおよびセットメディア依存ラッパーＳＣ−メディア型式当たり１つ−を
実行するメディア独立機能ＳＣ）に押し進められるならば、メディア独立クラス
２９８から派生されるように、記憶および送信３００は幾つかのメディア型式の
メッセージまたはデータの流れを記憶するような包括的な能力かつ次いでそれを
幾つかのイベントに基づいてメディア型式に供給するような能力を備えている。
方向変換は特定された条件に基づいて１つの論理アドレスから他の論理アドレス
へ接続を移動するような能力を備えている。この概念はコール送信（全ての型式
）、ＡＣＤ／ＵＣＤ，ＷＡＴＳ（１〜８００サービス）、ファインドミー／フォ
ローミーおよび自動車電話等の基礎である。交渉されるかまたは他の方法で、先
取りは、キャッチホン、優先先取り等のごときサービスを含んでいる。ＱｏＳ変
調接続は、音声／フックス、流れているビデオおよびファイル転送のごときパケ
ットネットワークにわたってさらに他のサービスを実行する。多者接続は３方向
およびＮ方向ビデオ会議等を含んでいる。使用者が制御しかつ入力が電話のキー
を使用して主として実行されるけれども、音声認識が将来において使用者制御お
よび入力に使用されるように期待されている。

【００７０】 接続マネージャークラス３０２はコールに伴われる種々の支持体制御２４８の
接続をコーディネートおよび調停する責任を負っている。したがって、多数コー
ル中の参加者間の接続性を管理する複雑さは他のすべてのサービスから分離され
かつ取り除かれる。サービスおよびコール処理は接続から結合解除される。この
ことは１接続対多数の接続のように接続へのマッピングコールのパラダイムを破
壊する。今や、コール対コールのマッピングは多数対多数である。

【００７１】 アーキテクチャ内の接続マネージャークラス３０２は単独で（スタンドアロー
ン）作動するようにまたは対等者として協力するように設計されている。作動に
おいて、サービス制御クラス２５２はコールセグメントを追加、変更および除去
するような要求により接続マネージャークラス３０２を示している。接続マネー
ジャークラス３０２の義務はこれらの変化をなし遂げることである。留意するこ
とは、接続がそれら自体のリソースとしてまたはリソースの属性として検討され
得るので、接続マネージャークラス３０２は基本のリソース管理機能のプロキシ
または態様として実行され得る。

【００７２】 コール制御クラス２５０は電話による通信に共通して使用される基本的な有限
状態機のごとき必須のコール処理を実行し、かつコール処理がどのように行われ
るかを特定する。２つのクラスが開始（コールを配置）３０４および終了（コー
ルを受容）３０６の機能的仕切りに沿って導き出され得る。

【００７３】 支持体制御クラス２４８はリソース複合体１８０へのかつそれからの特定の信
号およびイベントを、リソースプロキシ２４６を経由して、コール制御オブジェ
クト２５０によって理解され得る共通の信号およびイベントに適合させるのに向
けられている。このクラスから導き出されたオブジェクトの１つの予想される役
割は、加入者ライン番号、サービスのクラス、アクセスの型式等のごとき、コー
ルの開始端についての情報を集めることにある。サブクラスが信号送信と連係す
る回路またはチャンネルの数を基礎にして分化され得る。これらはＩＳＤＮ一次
インターフェイス３１０中の２３支持体チャンネル当たり単一信号送信チャンネ
ルに適用されるような、チャンネル関連クラス３０８、単一回路を制御するのに
ダイヤルするのに使用するアナログ電話３１４によって類型化されるようなチャ
ンネル単一クラス３１２、および支持体チャンネルから完全に分離されたＳＳ７
信号送信３１８によって示される、チャンネル共通クラス３１６を含むことがで
きる。

【００７４】 リソースプロキシクラス２４６は支持体ネットワーク中のリアルワールドスイ
ッチおよび他の要素に対する実施環境をインターフェイスするのに向けられる。
このレベルで実行されかつすべての派生クラスによって受け継がれる内部状態の
例はインサービス対アウトオブサービスおよび自由対使用中である。意図された
派生クラスは電話３２０（標準２５００セットに対する標準プロキシ）、音声応
答ユニット（“ＶＲＵｓ”）３２２（音声応答ユニットに対する標準プロキシ）
、ＩＭＴトランク接続３２４（デジタルトランク（Ｔ１／Ｅ１）回路に対する標
準プロキシ）、およびリソース複合体１８０中の特殊な型のリソースに対応する
、モデム接続３２６（デジタルモデムに対する標準プロキシ）である。サービス
制御構成要素が到来するサービス要求に役立つかも知れない好適な方法を、次に
、図１０をさらに参照して説明する。図１０はサービス制御サーバー、例えば、
汎用コンピュータ４４０の作動システム４３５内で実施しているＳＬＥＥ用途４
５０，４５０’を有するサービス制御環境４３０の他の実施形態をとくに示して
いる。

【００７５】 図８に示されるように、ＳＬＥＥ４５０はコール処理サービスおよび他の支持
サービスを行うのに実行される少なくとも５つの型の論理プログラム（オブジェ
クト）を実施するように設計されたジャバ（商標）「バーチャルマシン」である
。すなわち、１）特徴識別論理プログラム（“ＦＤ”）５１０。これは、まず切
り換えプラットホームからサービス要求を受信し、幾つかの利用可能な規準に基
づいてコールを行うべきそのサービスを決定し、かつ次いでコールを処理するた
めの他の適切なサービス論理プログラムを呼び出すサービス制御クラス／サービ
ス識別クラス２９６（図７）の機能的なサブコンポーネントである。２）サービ
ス論理プログラム（“ＳＬＦ”）オブジェクト５２０。これは、受信されたサー
ビス要求またはイベント用のサービス処理を行うサービス制御クラス２５２（図
７）の機能的サブコンポーネントである。３）ライン論理プログラム（“ＬＬＰ
”）５３０。これは、ネットワークアクセスラインの現行の状態を維持するコー
ル制御クラス２５０（図７）の機能的なサブコンポーネントである。４）イベン
ト論理プログラム（“ＥＬＰ”）オブジェクト５４０。これは、すべての他の論
理プログラムがそれにイベントを書き込むサービス制御／セッションマネージャ
ーマクラス２６０（図７）の機能的なサブコンポーネントである。５）コール論
理プログラム（“ＣＬＰ”）オブジェクト５４５。これは、コールの処理に伴わ
れる他のすべての論理プログラム用の接続点を設けることによってコール全体の
状態を維持するサービス制御／接続マネージャークラス３０２（図７）の機能的
サブコンポーネントてある。これらの論理プログラムの各々は、説明されるよう
に、一時的に例示されるかまたは継続することができる、好ましくは、ジャバ（
商標）プログラミング言語に書かれたソフトウエア「オブジェクト」として具体
化されている。ＩＤＮＡ／ＮＧＩＮサービス制御アーキテクチャは、これらのオ
ブジェクトがＭＯＣＥ／ＳＣＥに一度だけ書き込まれ、かつネットワーク中の何
処でもあらゆる型のコンピュータおよびあらゆる型の作動装置についてＳＬＥＥ
に展開され得るように設計されている。

【００７６】 より大きな特徴により、ＦＤ５１０は、まず、例えば、スイッチがサービスが
ＩＤＮＡ／ＮＧＩＮによって処理されることを識別するとき切り換えるリソース
複合体からのサービス要求を受信し；２）サービス要求と関連付けられる情報を
分析し；そして３）ＳＬＰがサービス要求を処理することができることを決定す
る静的サブコンポーネントである。好ましくは、ＦＤは、コールされた番号、コ
ールしている番号、開始スイッチＩＤ、開始しているトランクグループ、開始し
ているライン情報、およびネットワークコールＩＤを含むが、それらに限定され
ないリソース複合体から供給されたデータを受信するためのシステムタスクまた
は例示されたオブジェクトであってもよい。ＮＯＳによって、ＦＤ５１０はコー
ルを処理するために適切なＳＬＰ、ＣＬＰおよび開始しているＬＬＰの例示を始
める。好ましくは、ＦＤ５１０は、特定のコールまたはイベントに結合されてい
ない、継続するオブジェクトでありかつサービス制御ＳＬＥＥ４５０において何
時でも能動的に運転している。実施される分析の複雑さ、およびＦＤに対する要
求の量に依存して、負荷を分割しかつリアルタイム効率を保証するためにサービ
ス制御ＳＬＥＥ４５０中で能動的に運転しているＦＤの１またはそれ以上の段階
が存在してもよい。例えば、一方のＦＤは受信されたＳＳ７メッセージデータを
分析するのに使用されることができる一方、他方のＦＤはＡＴＭメッセージデー
タを分析するのに使用され得る。

【００７７】 ライン論理プログラム（ＬＬＰ）５３０は、１）ネットワークアクセスポイン
ト、接続またはラインの現行の状態を維持し；２）物理的なポイント、接続また
はラインと連係する特徴に関してデータマネジメントに質問し；そして３）コー
ル遮断、キャッチホン、コール送信、およびコール位置要求としてのオーバーフ
ロールーチングのごときそれらの特徴を適用する機能的なサブコンポーネントで
ある。コールを開始するラインと連係するＬＬＰ、以下で“ＬＬＰＯ”および点
接続、またはコールが終了するラインと連係するＬＬＰ、以下で、“ＬＬＰＴ”
がある。いったんライン論理プログラム段階（インスタント）が例示されるなら
ば、それ自体をスイッチ構造に記録する。説明されるように、ライン論理プログ
ラム５３０はすべてのイベントデータをサービス処理の同一段階のＥＬＰサブコ
ンポーネントに送信する。

【００７８】 動的サブコンポーネントはサービス処理の種々の段階に応じて動的に構成され
かつサービス処理の段階が完了するとき破壊されるそれらのコンポーネントであ
り、そしてイベント論理プログラム（ＥＬＰ）；コール論理プログラム（ＣＬＰ
）；およびサービス論理プログラム（ＳＬＰ）を含んでいる。

【００７９】 イベント論理プログラム（ＥＬＰ）５４０はサービス処理の間中発生されかつ
サービスの実施の間中発生するすべてのイベントデータを記録するリアルタイム
イベントデータを保持するのに使用される機能的サブコンポーネントである。好
ましくは、イベント論理プログラムは、イベントが最初に受信されるときスイッ
チでのコール制御処理によって例示される。スイッチがサービス要求をＮＧＩＮ
に送信するとき、その要求はイベントデータがそのコールに結合されたこの論理
プログラムに送信され得るようにＥＬＰのアドレスに沿って通過する。イベント
論理プログラムはサービス処理の同一段階中のすべてのサブコンポーネント、す
なわち、コールに関連するＣＬＰ，ＬＬＰｓ，およびＳＬＰにアクセス可能であ
る。各サービス処理コンポーネントかサービスの実行においてそのコールを処理
するので、予め確立された規則にしたがって、ＮＯＳによって、ＥＬＰにイベン
トデータを書き込む。コールが完了されると、ＥＬＰ中のイベントデータはデー
タ記憶装置またはログに書き込まれ、このデータ記憶装置またはログから、イベ
ントデータが次いでビリング記録にコンパイルされかつビリング、通話量／使用
報告、および他のバックオフィス機能用の下流のシステムに送られる。とくに、
ＥＬＰは、１）特定のコールによって発生されたネットワークイベントを集め；
２）イベントを適切なコールヒストリー記録、例えば、コール詳細記録（“ＣＤ
Ｒｓ”）、ビリングデータ記録（“ＢＤＲｓ”）、スイッチイベント記録等にフ
ォーマット化し；３）確認し、許可しかつ下流のシステム、例えば顧客請求書作
成への将来の伝送のために、例えば、データマネジメントに情報を記憶する機能
を実施する。理解されるべきことは、イベントがＥＬＰに書き込まれるのを決定
する規則はサービス発生において確立される。イベントデータはフロードマネジ
メントおよびネットワークシステムによって追加的にアクセス可能である。

【００８０】 コール論理プログラム（ＣＬＰ）５４５はサービス処理に伴われる各ＳＬＰの
状態を維持し、かつすべてのサービス（ＬＰ’ｓ）の間のプロセスインターフェ
イスを設ける機能的なサブコンポーネントである。１実施形態において、ＣＬＰ
はイベントサービス要求がコールに関してまず受信されるときＦＤによって例示
されるか、またはスイッチに置かれたコール制御コンポーネントによって例示さ
れ得る。代替的に、ＣＬＰ５４５はＳＬＰにプログラムされたトリガーポイント
に応じて、サービス処理の間中幾つかの点においてＳＬＰ５１０によって例示さ
れることができ；この方法において、ＣＬＰの例示はサービスに対して固有であ
ってもよい。コール論理プログラムは例示の時間においてサービス処理の同一の
段階内ですべてのサブコンポーネント、すなわち、ＳＬＰａ，ＬＬＰｓおよびＥ
ＬＰのアドレスを受信する。ＣＬＰは、次いで、そのコールに関してＳＬＰ（ｓ
），ＬＬＰＯ，ＬＬＰＴ、およびＥＬＰを関連付けそしてサービス処理の同一の
段階内でこれらのサブコンポーネントのすべてによってアクセス可能である。コ
ールが完了されると、ＣＬＰは論理プログラムの分解プロセスを開始するコール
完了のサービス処理の同一段階内でサブコンポーネントのすべてに通報する。

【００８１】 サービス論理プログラム（ＳＬＰ）５２０はサービスを実施するのに必要とさ
れる論理を供給する動的サブコンポーネントである。ＳＬＰはコールよりむしろ
サービスに結合され、そしてコールに関する、サービス、およびそれに含まれる
特徴を実行する。ＳＬＰがサービスに適用され得る特徴は、例えば、コールルー
チンアルゴリズムおよびＩＶＲサービスを含んでいる。ＳＬＰは頻繁に使用され
るサービスの継続するオブジェクトにし得るか、またはＦＤによって要求されか
つ例えば頻繁に使用されるサービスに関して、コール完了時中止されるとき例示
されてもよい。一定のＳＬＰが何時でも、或る時、または要求時のみ能動である
かどうかは、図１１に示されるようなそのサービスに関するサービス管理によっ
て発生される形状ファイル５８０によって決定される。好ましくは、ＳＬＰはサ
ービス処理の同一段階内でＣＬＰおよびＥＬＰにアクセスする。

【００８２】 すべてのＳＬＰが特定のコールサービスに関連付けられずかつ幾つかのＳＬＰ
は、他のＳＬＰによって必要とされかつそれによって呼び出されるタスクに利用
可能である。したがって、例えば、８００サービス用のＳＬＰはコールルーチン
中継用のそのタスクを完了するためにライン情報データベース質問用ＳＬＰを引
き出す必要があるかも知れない。また、ＳＬＰは他のＳＬＰへのコール用コール
処理の制御を通すことができる。好ましくは、サービス処理の単一段階の時には
１つの制御ＳＬＰのみが実施しているべきである。ＳＬＰによって行われるサー
ビスタスクの部分として発生されるあらゆるイベントデータは差蛇巣処理の同一
の段階内でＥＬＰコンポーネント５４０に送られる。

【００８３】 ＳＬＰは、これが実施すべき作動システムのすべての情報を含まないため作動
システムにおいて直接実施されることはできない。そのうえ、ＳＬＰがフォーマ
ットおよび内容を変更することなく種々の作動システムにおいて実施される必要
があるならば、ＳＬＰと作動システムとの間のＮＯＳミドルウエアが作動システ
ムを横切るＳＬＰの一致を維持するために設けられる。

【００８４】 図８にさらに示されるように、支持および作動機能に関するＳＬＥＥ４５０内
で実施する他のプロセスは、ＳＬＥＥにおいて運転するサービスを負荷し、活性
化し、消勢しかつ除去し、そしてさらに、そのＳＬＥＥ内で運転する他のすべて
のサービスを監視し、かつＮＯＳへ状態および利用データを報告する責任がある
サービスマネージャー（“ＳＭ”）オブジェクト５５４；ＮＯＳサービスとイン
ターフェイスするのに使用されかつＮＯＳサービスを呼び出すのにＳＬＥＥ内で
運転するすべてのサービスによって使用されるＮＯＳクラスライブラリー、すな
わち、ＮＯＳへのゲートウエーであるＮＯＳクライアントプロセス５５８；すべ
てのＳＬＥＥリソースを結合することなく同時に実施するためにＮＧＩＮサービ
スに必要とされる機能性を備えるスレッドマネージャー（“ＴＭ”）５５７；お
よび図４（ｃ）を参照して本書で説明されるようなＤＭ４００の局部メモリ４１
５およびメモリマネージャーコンポーネントとインターフェイスするのに使用さ
れるデータマネジメントＡＰＩ（“ＤＭＡＰＩ”）４１０を含んでいる。

【００８５】 図８に示されるようなＳＬＥＥに負荷されたさらに他のサービス段階はサービ
スエージェント（“Ｓａｇ”）段階５５９および本書においてさらに詳細に説明
されるような、サービスノードにおいてサービス活動に利用される段階５５９と
連係するスレッドマネージャー段階５５７を含んでいる。

【００８６】 図１２（ａ）はＳＬＥＥプロセスに主流入点を設ける（ＳＬＥＥ．ジャバ）プ
ロセスステップを示している。図１２（ａ）に示されるように、ステップ６０２
は、ＤＭシステムが利用可能であり、ＮＯＳクライアントプロセス５５８および
ＮＯＳサービスとインターフェイスするのに使用されかつＮＯＳサービスを呼び
出すためにＳＬＥＥ内で運転しているすべてのサービスによって使用されるＮＯ
Ｓクラスライブラリーを設けるＮＯＳマスタープロセスを含んでいるＮＯＳサイ
トロケータ（位置決め）システムが論理的な名称およびオブジェクト参照登録を
受信するのに利用可能であり、そしてサービス制御サーバー作動システム、例え
ば、ウィンドーズＮＴ，ＵＮＩＸ，ＰＣ等が、例えば、メイン（）またはフォー
ク（）のごときブートストラップコールを認識することによりＳＬＥＥプロセス
を開始することかできると考えられる。理解されるべきことは、ＮＯＳマスター
コンポーネント５６０（図８）はコンピュータの作動システム、ＮＯＳクライア
ントプロセス５５６および他のシステムコンポーネント５７１と直接インターフ
ェイスするということである。好ましくは、各ＳＬＥＥ上でＮＯＳクライアント
オブジェクト５５８とインターフェイスしかつＮＯＳサービスを供給するための
すべてのＮＯＳクラスライブラリーを含んでいるネットワークまたは局部ノード
上に置かれたＮＯＳマスタープロセス５６０が存在している。次に、ステップ６
０４において、サービス制御形状ファイルは形状オブジェクトを形成するような
ファイルを記述しそしてステップ６０６で示されるようなキーバリュー対を含ん
でいるハッシュテーブルを含むことも可能である。ＳＬＥＥは２つのパラメータ
、すなわち、名称および形状ファイルほ受容する。名称パラメータはＳＬＥＥの
この段階を識別するためのＮＯＳロケータサービスによって使用される、すなわ
ち、ＮＧＩＮロケータサービス（ステップ６１２）によりそれ自体を登録するた
めにＳＬＥＥによって使用される独特のＮＧＩＮ名称ストリングであり、そして
形状ファイルはそのサイトロケータを見つけるためにロケータサービスによって
使用される。例えば、このテーブルはＳＬＥＥ形状特性を見いだすのに使用され
得る。ＮＯＳがＣＯＲＢＡを実行するとき、ベースＣＯＲＢＡ機能性は次にステ
ップ６０８において初期化される。次に、ステップ６１０において、ＳＬＥＥク
ラスローダークラスが例示されかつＮＯＳロケータプロキシサービスがステップ
６１２で示されるようにＳＬＥＥ内で例示される。次に、ステップ６１５におい
て示されるように、サービスマネージャー（ＳＭ）クラスがクラスローダークラ
スを経由して負荷され、例示されかつ局部ＮＯＳと結合される、すなわち、ＳＭ
オブジェクトは局部プロキシＮＯＳロケータサービスオブジェクトにより登録さ
れる。理解されるべきことは、局部ロケータサービスはＮＧＩＮ領域において他
のロケータサービスへのサービスマネージャー登録に伝搬するということである
。図１２（ｂ）を参照して説明されるように、サービスマネージャーオブジェク
トがロケータサービスにより登録された後、ＳＬＥＥへの／それからのサービス
を負荷し、付勢し、消勢しかつ除去することができる。最後に、ステップ６１８
において示されるように、プロセスイベントループが実施され、このループはＳ
ＬＥＥ運転を保持しかつＮＯＳイベントが本書でより詳細に説明されるようにサ
ービスマネージャー（“ＳＭ”）およびサービスエージェント（“Ｓａｇ”）オ
ブジェクトを通って到来するようにＳＬＥＥにＮＯＳイベントを処理させ得るＳ
ＬＥＥスレッドである。

【００８７】 図１２（ｂ）は、図１２（ａ）、ステップ６１５を参照して上記で議論された
ように例示されるサービスマネージャーオブジェクト段階５５４によって実施さ
れる（サービスマネージャーＩｍｐｌ．ジャバ）プロセスステップを示している
。好ましくは、ＳＭオブジェクトはＮＯＳのためにサービスマネジメント演算を
行うためのＯＲＢインターフェイスを実行する。プロセスはＳＬＥＥ内のサービ
ス、例えば、（負荷）、（運転）、（スタート）および（停止）方法を負荷し、
付勢し、消勢し、運転しかつ終了するようにＳＭ段階なよって取られるステップ
を示している。ＮＯＳによってＳＭオブジェクト段階に通されたパラメータは所
望されるサービスの論理基準およびＮＯＳがＮＧＩＮ局部リソースマネージャー
（ＬＲＭ）サイトロケータによりサービスを登録すべきかどうかまたはサービス
がＮＯＳによりそれ自体登録する責任があるかどうかを示しているブールフラッ
グを含んでいる。ステップ６２０に示されるように、サービスを負荷する要求が
まず受信され、そしてステップ６２２でプロキシネーミングサービスが処理され
る。次いで、ステップ６２４で、登録されたサービス、例えば、１〜８００コレ
クト（“１８Ｃ”）がすでに負荷されているかどうか、すなわち要求されたサー
ビスを具体化しているオブジェクトが例示されているかどうかについて判断がな
される。要求されたサービスに関するオブジェクトがすでに例示されているなら
ば、その場合に、ＮＯＳはステップ６２６で物理的オブジェクト段階を配置する
ためにそのサービスのオブジェクト基準に戻りそしてプロセスはステップ６３２
に戻る。要求されたサービス用のサービスオブジェクト、例えば、１８Ｃがすで
に例示されていないならば、その場合に、クラスローダークラスは、他のＳＬＰ
ｓおよびＳＩＢＢｓを含んでいる、要求されたサービスが依存するすべてのクラ
スを負荷するために帰納的負荷を実行するステップ６２５において例示される。
帰納的負荷は、例えば、局部メモリからの局部形状ファイルに言及することによ
り可能である。とくに、クラスローダーがＪＶＭにこれらのすべての依存するク
ラスにおいて帰納的に負荷するかどうかを示すフラッグが通される。第１の段階
においてサービス用のクラスを負荷するとき、理解されることは、全般的なサー
ビスエージェントクラスがそれがまだ負荷されてないならば負荷され得るという
ことである。次いで、ステップ６２５でクラスをすべて負荷した後、ブールレジ
スタフラッグが、サービスがそれ自体局部ＮＯＳネーミングサービス（プロキシ
）により登録しなければならないかどうかを判断するためにステップ６２５でチ
ェックされる。ブールレジスタフラッグが、例えば、正確に、設定されたならば
、その場合に、サービスは、ステップ６３０で示されるように、ＮＯＳネーミン
グサービスを登録するような責任を有している。そうでなければ、プロセスはＳ
Ａｇクラスが例示されているステップ６３２に継続し、そしてサービスエージェ
ントオブジェクト段階５５８（図１１）と特定のサービスの間で、すなわち、Ｓ
ＬＰオブジェクトにおいてサービスエージェント段階に通すことにより、連係が
なされる。次いで、ステップ６３５において、新たなＳＬＥＥスレッドが、記載
されるような方法において、作られそしてＳＬＥＥスレッドがサービスエージェ
ントを運転するように引き起こされる、すなわちＳＬＥＥスレッドをサービスエ
ージェントと連係する。最後に、ＳＭプロセスが励起されかつプロセスはＳＬＥ
Ｅ．ジャバプロセスに戻る。ＳＭに設けられた方法を経由して、それはそのＳＬ
ＥＥ内で運転している他のすべてのサービスを監視し、かつＮＯＳへ状況および
利用データを報告する責任がある。

【００８８】 ＳＭプロセスに関して、（ＳＬＥＥクラスローダー．ジャバ）の引用が図１２
（ｃ）を考慮してより詳細に説明される。とくに、ＳＬＥＥクラスローダークラ
スはＪＶＭのクラスローダークラスの特殊化されたクラスでありかつそれを拡張
している。それはネットワークにわたって負荷されるようなクラスを許容するこ
とによりシステムクラスローダーの行動を拡張している。したがって、図１２（
ｃ）の第１のステップ６８６として、クラスローダーが、まず、クラスがすでに
負荷されかつ定義されている場合に見るようにＳＬＥＥの段階と連係されたその
局部メモリをチェックする。クラスがすでに負荷されたならば、その場合に、プ
ロセスは戻る。クラスが負荷されてないならば、その場合に、ステップ６８８に
おいて、メッセージがＮＯＳを経由してクラスが負荷するのに利用可能であるな
らば局部データ記憶（ＤＭ）をチェックするために送られる。例えば、ＳＬＥＥ
クラスローダーはＪＤＢＣデータベース接続性を使用して関連のデータベースか
らクラスを検索することができるが、しかしながら、理解されることは、ＪＤＢ
ＣＡＰＩを支持するあらゆる関連のデータベースからクラスを検索することがで
きるということである。サービスクラスが局部データ記憶に見いだされないなら
ば、その場合に、ＳＬＥＥクラスローダーはステップ６８９において局部ファイ
ルシステムをチェックする。クラスがデータ記憶、または局部ファイルシステム
に見いだされるならば、クラスは、ステップ６９０において示されるように、フ
ェッチされる。次いで、ステップ６９４において、定義されたクラス方法がＪＶ
Ｍ実施環境に利用可能であるそのクラスを作るように引き起こされる。とくに、
（定義されたクラス）方法はそのサービスを行うために特定されたクラスの各々
を帰納的に通り抜けかつクラスＣｌａｓｓの段階にバイトのアレイを変換する。
この新たに定義されたクラスは次いでクラスＣｌａｓｓにおいて新たな段階方法
を使用して作られ得る。この機能性はＳＬＥＥを負荷させかつ新たなサービスを
例示しかつまだ全般的に残っている。好ましくは、ステップ６９５に示されるよ
うに、方法はクラスが負荷される次回にメモリヒットがあるように局部メモリを
ポピュレートするように求められる。

【００８９】 好適な実施形態において、これらの例示されたオブジェクトの各々は、一般に
以下のストリング、すなわち、 ．．．サイトレベル、ＳＬＥＥ番号、ＳＬＰ名称．．． によって一般的に例示される、ネーミング取り決めにしたがって、ＮＯＳロケー
タサービス、すなわち、ＬＲＭ５７７によりそれら自体登録する。この場合に、
サイトレベルはＮＧＩＮサービス制御サーバー４４０の物理的位置に関する情報
；ＳＬＥＥ番号はそのオブジェクトが例示された特定のＳＬＥＥ、例えば、ＳＬ
ＥＥ＃１；およびＳＬＰ名称はサービスの局部的名称、例えば、特徴弁別器＃１
である。ストリングは値同様に、「バージョン番号」を含むことができる。登録
名称はＮＧＩＮ領域において他のロケータサイトに伝搬され；これによりそれは
登録プロセスおよびＮＯＳリソースマネジメント機能性（記載されるような）で
ありそれによりＮＯＳコンポーネントが知られそれらのプロセスは、それらが展
開される場合に、かつサービスが容易に利用可能である場合に展開される。

【００９０】 クラスローダーによって作られたオブジェクトの方法およびコンストラクター
は他のクラスを参照することができる。参照されるクラスを決定するために、ジ
ャババーチャルマシンがクラスを最初に作ったクラスローダーのロードクラス方
法を呼び出す。ジャババーチャルマシンがクラスが存在するかどうかおよびそれ
がそのスーパークラスを知るために存在するかどうかを判断するためにのみ必要
であるならば、「「決定（リゾルブ）」フラッグが不完全に設定される。しかし
ながら、クラスの段階が作られているかまたはその方法のいずれかが作られてい
るならば、クラスは、また、決定されねばならない。この場合に、決定フラッグ
は正確に設定され、そして決定クラス方法が呼び出される。この機能性はサービ
スによって参照されるクラス／ＳＩＢＢｓ／ジャバビーンズがまたＳＬＥＥクラ
スローダーによって決定されることを保証する。

【００９１】 図１２（ｄ）は例示時のサービスエージェントクラスプロセス流れを示してい
る。ステップ６３９に示されるように、第１ステップはサービスエージェントと
連係しかつ図１１にＴＭオブジェクト段階５５７として描かれているスレッドマ
ネージャー（“ＴＭ”）オブジェクトの例示を含んでいる。記載されたように、
スレッドマネージャーオブジェクトはサービス要求毎に新たなＳＬＥＥスレッド
を作るように機能しているスレッドファクトリーのごとく行動するように例示さ
れ得る（スレッドマネージャー）クラスに、または高いスレッド発生潜在能力を
備えたマシンで運転するとき所望されるスレッドウエアハウスに基礎を置いてい
る。次いで、ステップ６４０において、サービスと連係するＳＡがその（運転）
クラス方法を経由してプロセスイベントループに入り、そしてサービスと連係す
るコールイベントを受信するのに今や備えている。

【００９２】 図１２（ｅ）を参照すると、その（開始）、（継続）および（終了）クラス方
法を経由してＮＧＩＮサービスにゲートウエーを設けるサービスエージェントの
詳細が示されている。ＳＬＥＥ内の各々のサービスはサービス段階（コール段階
）を管理しかつサービス段階にイベントを急送する責任があるクラスに基礎を置
いている関連のサービスエージェントオブジェクトを有している。図１２（ｅ）
に示されるように、ＳＡｇオブジェクトがサービスマネージャー（負荷）方法に
よって例示されかつ運転している後、ＳＡｇの（開始）方法はサービスが受信さ
れることを要求している新たなコール毎に引き起こされる。とくに、図１２（ｅ
）に示されるように、ステップ６４１において、ティッド（ｔｉｄ）、オリッド
（ｏｒｉｄ）コール識別子パラメータおよび例えば、ネクストジェネレーション
スイッチ（“ＮＧＳ”）として本書で言及されるＩＤＮＡ／ＮＧＩＮからのイニ
シャルアドレスメッセージ（“ＩＡＭ”）によって設けられるような、そのコー
ル用のサービス処理に関連付けられるイベント情報を含んでいるメッセージの流
れが最初にＳＡｇ開始方法に通される。次いで、ステップ６４３において、メッ
セージ流れは、例えば、そのサービス段階に関連付けられる重要な情報を抜き出
すように（デコード）方法を引き起こすことにより復号される。加えて、コール
背景データを管理するのに使用されるコール背景オブジェクト段階が抜き出され
たメッセージ情報を受信するように作られる。ステップ６４５に示されるように
、開始方法において、新たなスレッドが、図１２（ｇ）を参照して本書で記載さ
れるように、スレッドマネージャー段階の割り当て方法を引き起こすことにより
そのコールに割り当てられるか、または、スレッドはその差ー美委用の幾つかの
スレッドが時間を超えて例示されるならばスレッドのプールから引き出される。
他の方法で、ＳＡｇ（連続）方法が引き起こされるならば、そのコール用に割り
当てられたスレッドに対応するオブジェクト基準は戻される。

【００９３】 よりとくに、スレッドマネージャーオブジェクトは、好ましくは、セッション
ｉｄｓに基礎を置いたスレッドを管理するスレッドマネージャーに基礎が置かれ
ている。２つの方法、（割り当て）および（解放）が、それぞれ、スレッドを割
り当ておよび解放するために設けられる。割り当ておよび解放の両方はスレッド
識別に使用され得るキーとして独特の識別子を期待している。独特の識別子はコ
ールを受信したＮＧＳスイッチによって設定される処理ＩＤ（“Ｔｉｄ”）、お
よびコールオリジネーターを識別するオブジェクト基準ＩＤ（“Ｏｒｉｄ”）を
含んでおりかつコール段階を識別するのに使用される。図１２（ｆ）はスレッド
マネージャークラスの（割り当て）方法の作動の詳細を示している。図１２（ｆ
）に示されるように、ステップ６６０において、コール処理を独特に識別するた
めのＴｉｄおよびＯｒｉｄ識別子はプロセスに通されかつ独特のキーが識別子に
基礎を置いて発生される。次いで、ステップ６６２において、質問が、例えば、
キーバリュー対のハッシュテーブル（寄せ集め表）をチェックすることにより、
キーがすでに存在しているスレッドを識別するかどうかについてなされる。キー
がサービススレッドがコールに対してすでに割り当てられたことを意味して認め
られるならば、その場合に、ステップ６６４において、スレッドマネージャーは
ハッシュテーブルを考慮に入れた後ＳＬＥＥスレッド段階（スレッドオブジェク
ト）に復帰する。他の方法で、ステップ６６３において、例示されたサービスス
レッドの数に一致するカウンタが増分され、そしてシステム負荷を監視するよう
な努力において、ステップ６６５で、そのサービスのスレッド段階の最大値が超
過したかどうかについて決定がなされる。そのサービス用のスレッド段階の最大
値が、例えば、サービス形状ファイルに見いだされる最大サービス段階とのカウ
ンタ値との比較時、超過されたならば、その場合に、ステップ６６７において、
メッセージが、例えば、同一のサイトで実施するか、または他のサービスノード
位置で例示された他のＳＬＥＥにおいて利用し得るサービス用の他の段階を求め
ることができるようにＮＯＳに放出され、そしてプロセスは戻る。ＳＬＥＥスレ
ッド例示プロセスに関して、図１２（ｇ）を参照して本書で記載されるように、
その優先イベントキューの初期化である。そのサービス用のスレッド段階の最大
値が超過されないならば、その場合に、ステップ６６８において、そのサービス
用のスレッド段階のしきい値が超過したかどうかについて判断がなされる。その
サービス用のスレッド段階のしきい値が超過されたならば、その場合に、警告が
サービスしきい値が達成されたＮＯＳ局部リソースマネジメント機能に発せられ
る。最後に、ステップ６７０において、ステップ６６８での出力に関係なく、要
求されたサービス用の新たなＳＬＥＥスレッドが割り当てられ、優先イベントキ
ューがその要求されたサービスに関して例示されそしてスレッドがそのサービス
用のＳＡｇ段階に戻されている制御により開始される。

【００９４】 図１２（ｅ）に示されたようなサービスエージェント（開始）方法機能性に戻
って、スレッドマネージャーがサービス段階用のスレッドを割り当てた後、スレ
ッドに関連するオブジェクト変数がステップ６４６で初期化され、そして要求さ
れたサービスの新たなオブジェクト段階が（クローン）方法を引き起こすことに
より例示される。次いで、ステップ６４８において、新たなクローン化されたＳ
ＬＰ段階が新たに割り当てられたスレッドに設定される。次いで、ステップ６５
０において、そのコール段階と連係することが必要とされるイベント情報、例え
ば、入力メッセージ流れから抜き出されたすべてのＩＡＭ情報が存在するかどう
かについて判断がなされる。新たにクローン化されたＳＬＰと連係されるイベン
ト情報があるならば、その場合に、ステップ６５２で示されるようにスレッド上
に押し出される。スレッド上に押し出されるようなイベント情報が存在するかど
うかはともかく、そのＳＬＰに新たに割り当てられたスレッドが開始され、ＳＡ
（連続）方法によって処理されるサービス関連のイベント情報の非同期到達を待
っている。述べられたように、そのコールに割り当てられたＳＬＥＥスレッドは
処理の間中受信されたすべてのサービス関連のイベント情報を保持するために優
先イベントキューを維持している。サービス処理に関連のすべてのイベントは関
連の優先権を有しかつスレッドはその優先権、すなわち、そのサービスイベント
キューにおけるその位置にしたがってイベント情報の処理を管理する。最後に、
ステップ６５４において、スレッドイベントループがそのコール段階に関して開
始される。

【００９５】 理解されるべきことは、ＳＡ（連続）方法が実質上図１２（ｅ）に示された（
開始）方法と同一であるということであり、その差異は、図１２（ｅ）を参照し
て上記で議論されたように、そのコール段階に関してすでに例示されたサービス
プロセススレッドとのリアルタイムサービス関連のイベントを運ぶのに向けられ
る。したがって、サービスエージェント連続方法はコール段階のイベントおよび
識別パラメータを受信し、受信されたイベント用のＴｉｄ，Ｏｒｉｄパラメータ
と連係されたサービススレッドを再び割り当て、そしてスレッドのイベント優先
キューへイベントを押し出す。理解されるべきことは、ＳＡｇおよびＳＭクラス
の両方がＮＯＳへのＩＤＬインターフェイスからなっているということである。
サービス（ＳＬｓ）はこのようなインターフェイスを持たないが、しかしながら
、そのＳＡｇインターフェイスを会してシステムと広く連通することができる。
リアルタイムサービス処理の間中、ＳＬＥＥ４５０は以下を、すなわち１）サー
ビス処理の間中ＳＬＰおよびＳＩＢＢでの指示を解釈し；２）ＳＬＰの指定され
た段階へ到来するイベントを供給し；３）追跡フラッグが設定されるならば、追
跡データを発生し；４）ＳＬＰ，ＳＩＢＢ、およびＳＬＥＥレベルでオンされた
追跡を許容しかつ追跡データを特定された出力に送り；５）ＳＬＥＥ使用データ
を発生しかつ運転時間使用データを特定された出力に送り；６）遠隔通信マネジ
メントネットワーク（ＴＭＮ）インターフェイス用の例外的なデータを発生し；
７）ＴＭＮインターフェイス用のパフォーマンスデータを発生し；８）ＳＬＰま
たは実用プログラムの新たな段階を加えるためのメッセージ／要求を受信しかつ
このような新たなＳＬＰまたは実用プログラムをサービス処理を中断および劣化
することなく加え；そして９）負荷分割用の多重サービス制御段階によって同一
のサービスを支持することを実行することができる。

【００９６】 サービス段階が処理を終了したとき、サービスの終了、またはサービスと連通
して他のプロセスを開始する。いずれの場合においても、ＳＡｇ（終了）方法が
呼び出され、これはそのコールと連係したスレッド段階を終了するように機能す
る。これは、スレッドマネージャー（解放）方法を引き起こし、コール段階を独
特に識別するＴｉｄおよびＯｒｉｄ識別子に通し、イベントをスレッドイベント
キュー上に押し出し、そしてコールを解放し、すなわちスレッド段階を終了しお
よび／またはスレッド段階をスレッドプールに配置することによりなし遂げられ
る。

【００９７】 好ましくは、ＳＬＥＥスレッドクラス段階はすべてのＳＬＥＥリソースを結合
することなく同時に実施するようなＩＤＮＡ／ＮＧＩＮに必要とされる機能性を
備え、そして協働リソース分割を容易にする。とくに、サービスの１段階とＳＬ
ＥＥスレッドの１段階を連係するＳＬＥＥによりＳＬＥＥスレッドとサービス段
階との間に１対１のマッピングが存在する、すなわち、サービスによって取り扱
われる各コールに関して、コールと連係するＳＬＥＥスレッドの１つの段階があ
る。ＳＬＥＥスレッドは、また、処理ｉｄ（ｔｉｄ）、オブジェクト基準ｉｄ（
ｏｒｉｄ）、オブジェクト基準、例えば対等者およびエージェントの両方、ＳＬ
Ｐ、およびＳＬＰと連係する優先イベントキューを収納することによりサービス
用のデータウエアハウスのように作用する。とくに、ＳＬＥＥスレッドは、２つ
のキーインターフェイス、すなわち、サービスエージェントがＳＬＥＥスレッド
上にイベントを押し出すのを可能にするためのプッシュコンシューマー；および
サービスがそれらの関連のスレッドからイベントを引っ張ることを可能にするプ
ルサプライヤーを実行することによってサービス（ＳＬＰ）とサービスエージェ
ントとの間のイベントチャンネルのように作用する。記載されるように、各ＳＬ
ＥＥスレッドは、記載された方法において、ＮＧＩＮイベントを待ち行列に入れ
るための優先イベントキューの段階を有している。

【００９８】 好ましくは、（優先イベントキュー）クラスはサービス（ＳＬＰ）と連係する
イベント（ＮＧＩＮイベントの派生クラス）を待ち行列に入れるプラットホーム
独立クラスである。図１２（ｆ）の、ステップ６６７，６７０を参照して示され
たように、各ＳＬＥＥスレッドオブジェクトはイベントのハッシュテーブルから
なることも可能である優先イベントキューの段階を例示している。イベントは下
降順位において待ち行列に入れられることができ、イベント優先性はＮＧＩＮイ
ベントにおいて定義されておりかついずれにしても１０から１の範囲にあり、１
０は、例えば、最高の優先である。したがって、各スレッドは処理に利用可能／
利用し得ないイベントの数を追跡することかでき、かくして完全なサービス処理
一致を可能にしている。

【００９９】 図１２（ｇ）は、ステップ６７５に示されるように、スレッドによって受信さ
れているイベントの優先性、および優先イベントキューへのイベントの供給を確
認するために論理をカプセル化する（ポストイベント）方法を示している。図１
２（ｇ）に示されるように、これは、ステップ６７８で処理されるような優先キ
ュー上で次のキューの優先性と押し出されたイベントの優先性を比較し、押し出
されたイベントがステップ６８０で処理（もしあるならば）されるようなキュー
における次のイベントの優先性より大きい場合に判断し、そしてステップ６８２
ａで示されるように処理されるべき次のイベントとしてそれを設定するようにキ
ューの頂部に押し出されたイベントを配置するか、または、キューを通してルー
プにしかつステップ６８２ｂで示されるように、イベントがその優先性にしたが
って記憶されるべきであるキューの位置を決定することによって実質上なし遂げ
られる。次いで、ステップ６８４において、ＳＬＥＥスレッドば、システムから
処理時間が割り当てられるとき最高の優先性の次のイベントを処理する。

【０１００】 より詳細には、プルサプライヤーインターフェイスは、イベントデータが利用
し得るかまたは例外が生起されるまで遮断しかつイベントデータを顧客に戻す「
プル」作業、または、遮断しない「トライプル」作業を引き起こすことによりサ
プライヤーからデータを要求するような顧客のための作業を支持するためにＳＬ
ＥＥスレッドによって実行される。すなわち、イベントデータが利用可能である
ならば、イベントデータを戻しかつハズイベント（ｈａｓＥｖｅｎｔ）パラメー
タを正確に設定し；イベントデータが利用不能であるならば、ハズイベントパラ
メータを不完全に設定しかつゼロに等しい値が戻される。したがって、ＳＬＥＥ
スレッドはイベントサプライヤーとして作用しかつサービス（ＳＬＰ）は顧客の
役割を引き受ける。サービス（ＳＬＰ）はＳＬＥＥスレッドからイベントデータ
をフェッチするためにＳＬＥＥスレッドプルまたはトライプルを使用する。サー
ビスはイベントデータなしに継続できないならばプル作業を使用し、そうでなけ
れば、トライプル作業を使用する。

【０１０１】 プッシュコンシューマーインターフェイスはＳＬＥＥスレッドによって実行さ
れかつスレッドへのプッシュ作業を引き起こしかつイベントデータをそのスレッ
ド優先イベントキューにパラメータとして通すことにより顧客へイベントデータ
を通信するためのサプライヤー用作業を支持する全般的なプッシュコンシューマ
ーインターフェイスである。したがって、ＳＬＥＥスレッドはイベント顧客とし
て作用しかつサービスエージェントはサプライヤーの役割を引き受けている。サ
ービスエージェントはイベントデータをＳＬＥＥスレッドへ通信するためにＳＬ
ＥＥスレッドプッシュ作業を使用している。「キル（ｋｉｌｌ）」サービスイベ
ントは最高の優先性からなることができる。イベントの優先性は怠われてもよい
か、または、新たに作られたイベントクラスが設計されるとき、サービス作成に
おいて確立されてもよい。

【０１０２】 記載されたように、特定のサービス用のサービスエージェント段階は、そのコ
ールのために作られたサービススレッド段階への／それからのサービス処理の過
程中に受信されかつ発生されたすべてのイベント伝える。例えば、ノードにおい
てスイッチによって発生された最初のイベントは（サービスリクエストイベント
）からなることができ、このクラスはＩＤＮＡ／ＮＧＩＮサービス制御へ最初の
サービス要求をかつとくに、サービス要求が始められる時間；要求がそれから開
始されるスイッチＩＤ；コールが引き起こされるポートＩＤ；コールが引き起こ
される端末設備ＩＤ；呼び出している者の番号；呼び出された者の番号等のごと
き関連の初期コール背景情報を運ぶ責任がある。ＮＧＩＮイベントを拡張してい
る（コネクトイベント）サブクラスは接続が発生する時間；呼び出している番号
が接続されるステーション番号を報告し；およびＡＴＭ−ＶＮＥＴサービスの背
景において、到来すバーチャルパスＩＤおよび出て行くバーチャルパスＩＤｓを
報告することができる。ＮＧＩＮイベントを拡張している（解放イベント）サブ
クラスは解放イベントを報告することが可能である。例えば、ＡＴＭ−ＶＮＥＴ
サービスの背景において、解放は、呼び出しているまたは呼び出された者がコー
ルを終了するとき、または使用者クレジットが切れているとき発生され得る。こ
のようなクラスは、解放イベントが発生される時間；解放イベントを発生する原
因および呼び出しているおよび呼び出された者から解放イベントが発生される時
間への所要時間を決定するためのＳＩＢＢＳを実行することができる。これに関
して、ＮＧＩＮイベントを拡張している（終了イベント）サブクラスがＮＧＩＮ
からＮＧＳへ終了メッセージを帆走するのに使用されてもよい。このメッセージ
を受信時、スイッチは分解接続プロセスを開始し得る。（モニタ解放イベント）
サブクラスはＮＧＩＮイベントを拡張しかつ解放指示の受信時ＮＧＩＮに解放指
示を送るようにＮＧＳに向いているＮＧＳへのメッセージを送るのに使用される
。ＮＧＳがモニタ解放メッセージを受信するとき、（ユニノーティファイイベン
ト）サブクラスがオリジネーター（呼び出し者）への通知を送って引き起こされ
得る。（モニタ接続イベント）サブクラスはＮＧＩＮイベントを拡張しそして接
続メッセージが受信されるときＮＧＩＮへイベントを送るためにＮＧＩＮからＮ
ＧＳへメッセージを送るのに使用されるサブクラスである。

【０１０３】 記載されたように、リアルタイムサービス処理の文脈において、データマネジ
メントデータ検索および更新機能はサービス処理の間中ＤＭによって記憶された
データにアクセスするような能力を包含している。

【０１０４】 好適な実施形態において、ある特定のサービス・ノードで、ＤＭは、サービス
処理中に、たとえばＮＯＳを介して、ＳＬＥＥ中の実行被管理オブジェクト・イ
ンスタンスからのデータ要求を受信する。データ管理（Data Management）は、
そのデータ要求を理解できない場合、要求元（たとえば被管理オブジェクト）に
特に通知する。このデータ要求がデータ・エンティティの検索に対するものであ
る場合、データ管理は、要求されたデータを要求元に（たとえばＮＯＳを介して
）返す。なお、単一のリポジトリ中、または複数のリポジトリにまたがってデー
タを操作および問い合わせるために必要なサポートはＤＭによって供給される。
さらに、データ管理は、複数のリポジトリにまたがる問合せの結果の収集または
対照をサポートする。ＤＭはデータ検索要求中にある要求されたエンティティの
名前の場所を特定できない場合、ＤＭはＮＯＳコンポーネントに通知する。また
、ＮＯＳコンポーネントは、データ・エンティティの検索中にデータベース障害
が発生した場合に通知される。さらに、データ管理は、要求元（サービス制御オ
ブジェクトを実行する）に、有効な名前から特定のデータ・エンティティを検索
できない旨を通知する。データ要求がデータ・エンティティの更新に対するもの
である場合、データ管理は、データ・エンティティを更新して、複製が要求され
るか否かを決定する。ＤＭは、データ要求中で指定されたデータ・エンティティ
を更新することができない場合、要求元に通知し、さらに、データ更新要求中に
おける要求されたエンティティの名前の場所を特定することができない場合、Ｎ
ＯＳに通知する。ＮＧＩＮ動作中において、ＤＭは、ＮＯＳに、データ・エンテ
ィティの更新時のデータベース障害について通知する。データ要求がデータ・エ
ンティティの削除に対するものであれば、ＤＭはそのデータ項目を削除し、他の
リポジトリ上でトランザクションの初期化が必要か否かを決定する。

【０１０５】 図４（ｃ）は、全体として、データ管理コンポーネント４００の機能アーキテ
クチャを図示している。データ管理コンポーネント４００は、リアルタイム呼処
理に対して呼び出しサービス・データがサービス・ノードで使用可能となるよう
にするサービス制御サーバ・コンポーネント４０５と；個別データベース・サー
バとして具現化されＳＡによって保持されるデータの被選択サブセットを格納お
よび分配するデータベース・コンポーネント４０７とを備える。特に、サービス
制御サーバ・コンポーネント４０５は、実際のデータ管理アプリケーションであ
るデータ管理（ＤＭ）クライアント４０９と；ＤＭアプリケーションとリンクさ
れＤＭアプリケーションがＳＡからデータを獲得するために使用するインタフェ
ースであるＤＭ ＡＰＩ４１０と；ローカル・キャッシュ・ストラテジにしたが
って、呼処理に対して使用可能なＤＢＯＲ抽出からのデータの一部または全てを
格納するために使用されるサービス制御サーバ上の共有メモリであるローカル・
キャッシュ４１５と、ローカル・キャッシュ・ストラテジをインプリメントする
ことによってローカル・キャッシュの状態を維持し、ＤＭサーバと通信を行って
ＤＢＯＲ抽出からデータを検索するキャッシュ・マネージャ４２０とを備える。
データベース・コンポーネント４０７は、当該ノードでのサービス実行時に被管
理オブジェクト・インスタンスによって使用されるデータを有する１つ以上のデ
ータベースを含むＤＢＯＲ抽出４２７と；ＳＡが保持する情報の被選択サブセッ
トを管理するＤＢＯＲ抽出マネジャー４２６と；サービス・アドミニストレーシ
ョンから受け取ったデータをＤＢＯＲ抽出マネジャー４２６へ入力するＳＡクラ
イアント４２２と；ＳＡクライアント４２２とＳＡのデータ分散プロセスとの間
のプロセス・インタフェースであるＤＤＡＰＩ４２４と；ＤＢＯＲ抽出マネジャ
ー４２６からのデータ抽出を全般的に取り扱うデータ管理サーバ４２５とを備え
る。

【０１０６】 ここで、データ管理動作について、図４（ｃ）および図８に関してさらに詳細
に説明する。ＳＬＥＥ内において、数種類の機能は、被管理オブジェクト（ＳＩ
ＢＢ、ＳＬＰなど）およびＮＯＳに限らず、データ管理４００からのデータを必
要とする場合がある。そのそれぞれを、サービス制御ＳＬＥＥ中で実行するＤＭ
クライアントとして図４（ｃ）に図示する。ＤＭ ＡＰＩ４１２はデータ管理と
のインタフェース接続のために全ＤＭクライアントに対して共通メッセージ・セ
ットを供給するため、ＤＭクライアント４１０は、ＤＭ ＡＰＩ４１２を使用し
てデータに対する要求を行う。また、ＤＭ ＡＰＩ４１２はデータが必要とされ
る特定の場所をＤＭクライアントからカプセル化するが、これは、このデータが
ローカル・キャッシュ４１５中またはＤＢＯＲ抽出４２７中のみに格納される場
合があるからである。ＤＭクライアント４１０は、論理名によってデータを要求
し、ＤＭ ＡＰＩ４１２は、そのデータがローカル・キャッシュから検索可能か
、またはＤＢＯＲ抽出からＤＭサーバを介してデータを要求する必要があるかを
決定する。ローカル・キャッシュ４１５は、制御サーバ４０５中に供給される各
ＳＬＥＥ上に動作する各プロセスに対して使用可能となっている共有キャッシュ
であること、すなわち、たとえば１−８００プロセス・キャッシュ、ルーティン
グ・マネジャー・キャッシュなどの異なる適用に対して１つ以上のローカル・キ
ャッシュが備えられており、各供給キャッシュがそれ自体の各キャッシュ・マネ
ジャーを有するｋとが好ましい。

【０１０７】 ＤＭクライアント４１０がデータを要求すると、まず、ＤＭ ＡＰＩはローカ
ル・キャッシュ４１５を調査して、要求されたデータがそこに格納されているか
否かを確認する。要求されたデータがローカル・キャッシュ４１５中に格納され
ている場合、ＤＭ ＡＰＩはその要求されたデータを検索して、ハッシング・キ
ーおよびアルゴリズムまたは索引順次アクセス方式など、標準データ検索技術を
使用して、それをＤＭクライアント４１０に供給する。

【０１０８】 要求されたデータがローカル・キャッシュ４１５に格納されていない場合、関
連キャッシュ・マネジャー４２０は、ＤＢＯＲ抽出４２７からＤＭサーバ４２５
を介して、データを検索する。特に、ＤＭ ＡＰＩ４１２は、キャッシュ・マネ
ジャー４２０に、特定のデータを必要とすることを通知し、キャッシュ・マネジ
ャーは、要求をＤＭサーバ４２５に送信することによって応答する。その後、Ｄ
Ｍサーバ４２５は、データベース・アクセスのためにＤＢＯＲ抽出マネジャー４
２６を使用して、要求されたデータをＤＢＯＲ抽出から検索する。ＤＭサーバ４
２５は、要求されたデータをキャッシュ・マネジャー４２０に返送し、キャッシ
ュ・マネジャーはデータをＤＭ ＡＰＩ４１２を介してＤＭクライアント６１０
に供給する。また、キャッシュ・マネジャーは、要求されたデータをローカル・
キャッシュ４１５に書き込むが、これはサービス要求とそれらが動作しているコ
ンピュータの機能、つまりメモリ容量との両方に依存するローカル・キャッシュ
・ストラテジに依存する。これらの使用は、サービス・アドミニストレーション
によって生成されるサービス・プロファイルおよびコンピュータ・プロファイル
から獲得される。ＩＤＮＡ／ＮＧＩＮのＤＭ４００のためのデータキャッシュ・
マネジャー・コンポーネントは、「クライアント側キャッシュ」ストラテジを、
各サービス・ノードで使用することが好ましい。

【０１０９】 では、ＩＤＮＡ／ＮＧＩＮネットワーク・オペレーティング・システム（ＮＯ
Ｓ）コンポーネント７００について、図８〜１０を参照して、より詳細に説明す
る。上述のように、ＮＯＳ機能は、ＩＳＮＡ／ＮＧＩＮシステム１７０に対する
プロセス間通信機能と、オブジェクト・コネクティビティ機能と、ローカルおよ
びネットワーク全体リソース管理機能とを備える。全てのＮＧＩＮプロセスは、
広範囲に分散するアーキテクチャ中のさまざまなハードウェアおよびオペレーテ
ィング・システム・プラットフォーム上で実行するため、ＮＯＳは全プロセス間
でプラットフォーム独立型通信および場所独立型通信を実現する。特に、ＮＯＳ
はいくつかの機能サブ・コンポーネントを備え、サービス制御、サービス・アド
ミニストレーション、およびデータ管理との間のインタフェースを含む、全ＮＧ
ＩＮプロセス間のインタフェースを提供する。また、ＮＯＳは、スイッチ呼制御
とサービス制御との間のインターフェースであり（図５）、同一ＳＬＥＥ上で動
作する２つ以上のプロセスが互いに通信可能なようにする。

【０１１０】 図８〜１０に示すように、ＮＯＳ機能サブ・コンポーネントは、１）データ・
オブジェクトおよびサービス・オブジェクトに対する論理名を、要求されたオブ
ジェクトが動作しているコンピュータ（ネットワーク・アドレスとして）とメモ
リ・アドレスとの両方を識別する物理的アドレスに分解する名前変換（ＮＴ）プ
ロセス５７０と；２）ＳＬＥＥとサービス・ノードとで実行しているリソース・
ステータスを追跡および維持するローカル・リソース管理（「ＬＲＭ」）プロセ
ス５７５、５７７と；３）ＮＧＩＮネットワーク全体における全サービス・ノー
ド・リソースのステータスを維持し、プロセス間通信を提供するグローバル・ネ
ットワーク・リソース・ステータス（「ＮＲＳ」）プロセス５９０と；４）共通
オブジェクト要求ブローカー・アーキテクチャ（ＣＯＲＢＡ）対応ＯＲＢによっ
て提供されるものなどのオブジェクト・コネクティビティを提供して異なるコン
ピュータ・プラットフォーム、ＡＰＩメッセージ・セットおよびインターネット
・プロトコル（ＩＰ）通信にまたがるオブジェクト間の通信を特定のリアルタイ
ム呼処理動作上件を満足する以上の方法で、可能とする１組のサービスとを含む
。たとえば、典型的な１−８００番号「コレクト・コール」イベントを処理する
典型的な応答時間は、約５０〜１００ｍｓｅｃでなければならない。

【０１１１】 ここで説明するように、ＮＯＳコンポーネント７００は、たとえばＯｒｂｉｘ
（登録商標）が提供しＭＡ、ケンブリッジ、およびアイルランド、ダブリンのＩ
ＯＮＡが開発したオブジェクト・コネクティビティに対して、ＣＯＲＢＡ対応Ｏ
ＲＢを使用してインプリメントすることが可能である。ＯＲＢは、物理的アドレ
スへの論理名の対応付けを可能とする名前サービスを提供することによって、異
なるコンピュータ・プラットフォームにまたがるオブジェクト間の通信を提供す
る。

【０１１２】 システム・ブート時、ＳＬＥＥ４５０は起動され、その環境内において、ＮＯ
Ｓクライアント・コンポーネント５５８およびサービス・マネジャー・プロセス
・コンポーネント５５４とのインスタンスを起動する。ＳＭ ＳＬＰ５５４は、
即時にインスタンス化されるサービスの論理名を含むコンフィギュレーション・
ファイル５８０から、他のコンポーネントに対する論理名を検索する。その後、
その論理名をＯＲＢ名前サービスに供給し、ＯＲＢ名前サービスは、その論理名
を物理アドレスに対応づける。ＯＲＢはこの時点からサービス・オブジェクト・
コネクティビティを保持する。また、ＯＲＢサービスは、他のサービスの登録に
対しても使用される。ＳＬＥＥ上で開始された各サービスは、自分自身をＮＯＳ
に登録し、それらの登録によって、ＯＲＢは論理名に対する物理アドレスを識別
する。

【０１１３】 対話型オブジェクト間でのプラットフォーム独立型通信をインプリメントする
ために、インタフェースが定義されるが、これはインタフェース定義言語（「Ｉ
ＤＬ」）によって可能である。ＣＯＲＢＡはＩＤＬを現在サポートしているが、
リアルタイム呼処理に対する動作上件が満足される限り、リモート・メソッド呼
び出し（ＲＭＩ）プロトコルなどの他のオブジェクト指向通信技術がインプリメ
ントされることも可能である。特に、ＮＧＩＮコンポーネントのそれぞれに対す
るインタフェースがその作成時に定義され、それらを、図９に図示されるような
、ローカルＬＲＭ５７５と関連づけられた永続型データ・ストアまたはライブラ
リ（不図示）中に格納することによって、動作時に使用可能となる。サービスは
このライブラリに問合せを行うことが可能とされ、新規のオブジェクト・インタ
フェースについて学習する。ＮＯＳクライアント・プロセス５５８およびＮＯＳ
マスタ５６０（図８）は、ＮＯＳサービスとのインタフェース接続のために使用
され以下で詳述されるＮＯＳ ＮＴおよびＬＲＭサービスを呼び出すために当該
ＳＬＥＥ内で動作する全サービスによって使用されるＮＯＳクラス・ライブラリ
である。

【０１１４】 ここで図９を参照すると、１つ以上のＳＬＥＥ４５０および４５０’を実行す
るコンピュータ上に常駐するＮＯＳ機能サブ・コンポーネント５７０とＬＲＭ機
能サブ・コンポーネント５７６との機能アーキテクチャが、各ＳＬＥＥと関連づ
けられたＮＴおよびＬＲＭサブ・コンポーネントとともに図示されている。図９
は、特に、それぞれが各ＳＬＥＥコンポーネント４５０および４５０と各ＮＴ機
能サブ・コンポーネント５７０および５７０’および各ＬＲＭ機能サブ・コンポ
ーネント５７５および５７５’とを含む各ＮＯＳコンポーネント７００および７
００’とをインプリメントする少なくとも２つのコンピューティング・システム
４４０および４４０’を有する単一ＮＧＩＮサービス・ノードまたは「サイト」
４５の例を図示する。個別のコンピュータ上で実行する単一のＳＬＥＥが図示さ
れているが、２つ以上のＳＬＥＥが単一サイトにおいて同一コンピュータ上で動
作できる。各ＳＬＥＥ４５０、４５０’上で動作しているのは、Ｓ１，・・・Ｓ
４とされる複数のオブジェクトまたはプロセスで、ＳＬＰ、ＬＬＰ、ＣＬＰ、Ｅ
ＬＰ、永続的に動作しているＦＤ論理プログラムおよびＮＯＳクライアント・オ
ブジェクト５５８、または他のプロセスの場合がある。

【０１１５】 ここで説明するように、各ＮＯＳ ＮＴ機能サブ・コンポーネント５７０およ
び５７０’は、使用されるデータ・オブジェクトまたはサービス・オブジェクト
の正しいバーションを識別するプロセスを含み、特に、他のプロセス上でプロセ
スが呼び出すことを可能とし、呼び出されたプロセスの異なるバーションおよび
インスタンス全体において変化しないままの単一の共通論理名を使用することに
よる。したがって、ＮＯＳ ＮＴコンポーネント５７０は、プロセスからのイン
スタンスのオブジェクト参照、バージョニング、物理的場所をカプセル化する。

【０１１６】 ここで説明されるように、各サービス・ノードにあるＮＯＳ７００の各ローカ
ル・リソース・マネジャー（「ＬＲＭ」）コンポーネント５７５、５７５’は、
サービス・プロファイル（コンフィギュレーション）ファイル５８０中に含まれ
るコンフィギュレーション・ルールにしたがって、ノードのどのＳＬＥＥ上でど
のサービスを実行するかを決定する。サービス・プロファイル（コンフィギュレ
ーション）ファイル５８０は、ＳＡから配置されローカルＬＲＭキャッシュ中に
格納されるサービス・プロファイルのコンテンツを含んでもよい。ＬＲＭは、ま
ず、当該ノードにあるローカル・キャッシュ中に格納されるこのサービス・プロ
ファイル・ファイル５８０を読み込み、サービス・プロファイル・ファイル中の
ルールにしたがって、どの特定のＳＬＥＥ上でサービスを実行するか、および、
ＳＬＥＥ中でどのサービスをアクティブに（永続オブジェクトとして）動作させ
るかまたは要求に応じてのみインスタンス化されるかを決定する。

【０１１７】 好適な実施形態において、ＬＲＭ５７５は、各サービス制御リソースの安定度
および状態を追跡することによって、サービス実行の動作時間コンフィギュレー
ションおよび最適化を可能とする。特に、各ＬＲＭ機能サブ・コンポーネントは
、当該ＳＬＥＥ上で動作するようにプログラミングされた全サービスのリストと
、どのサービス・プロセス（オブジェクト参照）がＳＬＥＥ上でアクティブに動
作しているかと、所定の閾値にしたがって当該ノードでのＳＬＥＥの現在の負荷
状態（処理容量）とを保持する。

【０１１８】 さらに詳細に記せば、ＳＬＥＥ（サーバ）ＬＲＭコンポーネント５７５は、シ
ステム中の各オブジェクト（論理プログラム）に対応するオブジェクト参照のロ
ーカル・キャッシュに内蔵された１組のライブラリで、そのオブジェクト参照は
、ＩＰアドレスおよびポート番号など、サーバに関する情報を含み、通信を可能
とする。新規のオブジェクトがシステム内で使用可能となると、それらはＮＯＳ
に登録される。すなわち、オブジェクト参照はそれらのために作成され、データ
管理によってローカル・キャッシュに登録される。

【０１１９】 そのサービス・プロファイル（コンフィギュレーション）ファイル５８０に問
合せを行って、どのサービスが即座にインスタンス化されるのかを決定した後、
ＮＯＳ ＬＲＭコンポーネント５７５は、サービス・アクティブ化要求を、ＮＯ
Ｓ ＮＴ５７０からＳＬＥＥにあるアクティブ・サービス・マネジャー・オブジ
ェクト５５４へ、同様にＳＬＥＥ中で実行しているＮＯＳクライアント・インス
タンス５５８を介して送信する。ＳＭオブジェクト５５４は、ＳＬＥＥサービス
の制御を可能とするＡＰＩオブジェクトである。たとえば、非アクティブ・サー
ビスに対する要求が受信された場合に新規のサービスをインスタンス化する機能
を提供する。すなわち、インスタンス化されるときにオブジェクトにプロセス・
スレッドを割り当てることが可能で、サービスはＬＲＭ５７５を介してＮＯＳに
自分自身を登録する。サービスが、その論理名を使用して別のサービスによって
呼び出されると、ＬＲＭはコンフィギュレーション・ファイル中のルールを使用
して、どのインスタンスが呼び出されるかを、その論理名をアクティブ・インス
タンスの物理アドレスに対応づけるためにＯＲＢ名前サービスを使用することに
よって決定する。

【０１２０】 図９に図示するように、ＮＧＩＮサイトまたはサービス・ノード４５と関連づ
けられているのは、個別コンピュータ４４０’’上、またはコンピュータ４４０
またはコンピュータ４４０’などの共有コンピュータ上のＮＯＳコンポーネント
７００’’上で動作するサイトＬＲＭ５７７である。サイトＬＲＭ５７７は、１
）各ＳＬＥＥ上で動作する全プロセスの現在の負荷の関数である、各ＳＬＥＥで
のサービスの使用可能性を追跡し；さらに２）各個別ＳＬＥＥ ＬＲＭ５７５の
アクティブに更新されるコピーであるリソース・ステータス・リストを、各リソ
ースに対するＳＬＥＥ識別子とともに維持するように機能する。サイトＬＲＭサ
ブ・コンポーネント５７７は、複数の評価基準のいずれかに基づいて要求される
サービスのどのインスタンスが使用されるべきかを決定する。複数の評価基準は
、それに限定されるものではないが、１）呼び出しているサービス・インスタン
スと呼び出されているサービス・インスタンスとの近似度（ＳＬＥＥが同一か否
か、サイトが同一か否か）；２）呼び出されたサービスによって必要とされるデ
ータ管理データと呼び出されたサービス・インスタンスとの近似度；および３）
現在のシステムおよびプロセス負荷とを含む。

【０１２１】 一例として、図９に図示されるように、プロセス（たとえばＳＬＥＥ１中のＳ
１）はＳＬＰ、Ｓ４をインスタンス化して特定のプロセス（たとえばＶｎｅｔ
サービス）を実行する必要があるときは、常に、ＮＯＳはまずサービス（すなわ
ちそのオブジェクト参照）がローカル・キャッシュ（たとえばＳＬＥＥ１中）で
使用可能であるか否かに関する決定を行う。ローカルＬＲＭ５７５が要求された
オブジェクト参照を有さない場合、ＮＯＳはサイト・レベルＬＲＭ５７７を探し
て、要求されたサービスに対応する当該オブジェクト参照に場所を決定する。た
とえば、図９に示すように、当該オブジェクトはＳＬＥＥ２で発見可能であり、
発見されると、ＳＬＥＥがそれを行うための容量を有していれば、すなわちその
使用閾値にまで到達していなければ、当該オブジェクトのインスタンスをインス
タンス化することによって当該サービスを使用可能とする。

【０１２２】 さらに図１０に図示するように、各ＳＬＥＥに対する各ＬＲＭ５７７および各
サイトに対するＬＲＭ５７７に加えて、ＮＯＳコンポーネント７００は、さらに
、ネットワーク全体リソース管理機能を実行するプロセスであるネットワーク・
リソース・ステータス（「ＮＲＳ」）サブ・コンポーネント５９０を含む。特に
、ＮＲＳは、ネットワーク中の各サイトＬＲＭ（たとえば図１０の各サイト４４
０ａ〜４４０ｃに対応するサイトＬＲＭ５７７ａ〜５７７ｃ）によって保持され
るデータのサブセットを含む。ＮＲＳ５９０は、１）ＳＬＥＥのリスト；２）ど
の種類のサービスが各ＳＬＥＥ上で動作するようにプログラミングされているか
；および３）どのサービスが各ＳＬＥＥ上でアクティブに動作しているかを、す
なわちパーセント・ベースでのＳＬＥＥの現在の負荷を含む。このＮＲＳサブ・
コンポーネント５９０は、サイトＬＲＭ５７７ａ〜５７７ｃが満足できない要求
に対する別のレベルの伝播をＮＯＳに与える論理的一括化機能である。さらに、
ＮＲＳサブ・コンポーネント５９０は、各ＳＬＥＥ４５０に対するバイナリ・イ
ンジケータを含み、ＳＬＥＥが上向きか下向きか、およびサービス使用閾値は当
該ＳＬＥＥによって到達されたかを示す。その「上向き」または「下向き」イン
ジケータおよび使用閾値アプリケーションは、ＳＬＥＥが他のサービスからのサ
ービス要求を受けるために使用可能かを決定するために使用され、これらのイン
ジケータおよび閾値の適用があるとすれば、ＮＲＳサブ・コンポーネントは、Ｓ
ＬＥＥが使用可能であるか否かのバイナリ・インジケータを単純に提供できる。
一例として、被要求ＳＬＰオブジェクトがＳＬＥＥ中にあるが、そのＳＬＥＥが
要求されたプロセスをインスタンス化する容量がない場合、当該ＳＬＥＥに対す
る使用閾値が到達され、当該サービスに対するさらなる要求を処理できない旨を
、サイトＬＲＭ５７７に対して通知を送信する。また、この情報は、ＮＲＳコン
ポーネント５９０に伝播する（図１０）。

【０１２３】 図８を参照すると、ＮＧＩＮシステムは、監視機構５９５をインプリメントし
て、メモリ容量、データベース容量、被要求オブジェクトに対するキューの長さ
、キューでの時間量、およびシステム中の各ＳＬＥＥに対する他のリソース／負
荷パラメータを監視する。これらの要素は、これらの要素の１つ以上に基づくＳ
ＬＥＥの使用閾値に関する決定を行うＮＯＳ７００に対して使用可能となる。固
定閾値に加えて、複数の閾値がヒステリシスのために使用可能である。

【０１２４】 では、ＮＯＳ７００が場所独立型処理およびプラットフォーム独立型処理を提
供可能としＮＧＩＮの全体的な処理機能を最適化するＮＴ、ＬＲＭおよびＮＲＳ
を含みＮＯＳによって実行されるリソース管理機能の説明上の例は、図１１（ａ
）〜図１１（ｂ）を参照してさらに詳細に説明される。図１１（ａ）および図１
１（ｂ）を参照して説明されるＬＲＭプロセス・フロー８０１において、サービ
ス制御サーバ１上のＳＬＥＥ１上で実行するサービスＳ１は、工程８０２で示す
ように、サービスＳ２を呼び出す必要がある。サービスＳ１は、スイッチ構造呼
制御からイベント・サービス制御要求を受信したＦＤまたはサービス論理プログ
ラムであり、たとえば呼処理を完了するために、別のＳＬＰ、Ｓ２を呼び出す必
要がある。

【０１２５】 特に、図１１（ａ）を参照すると、サービスＳ１は、ＳＬＰ Ｓ２に対する論
理名を使用してＮＯＳ７００へ要求を発行する。サービス・オブジェクトに対す
るＳＬＰ要求が受信されると、ＮＯＳ名前変換機能５７０ａは、工程８０４に示
されるように実行され、ＮＯＳは被要求サービスがローカル・サービス制御サー
バ１上でアクティブに動作することを認識している、すなわち、被要求サービス
の論理名と関連づけられたオブジェクト参照を有するかを決定する。ローカル・
サーバ・キャッシュ中に格納されるデータは、以下のＮＯＳネーミング・データ
・フィールドを含むことが好ましい。１）典型的に、サービスを説明する論理名
であり機能ディスクリミネータ・データが指す名前であるＳＬＰ論理サービス名
；２）たとえばサービスが動作する当該バージョンを要求する特定の顧客または
ノードなどに対して、必要とされる場合のある特定のサービスのバージョンを説
明する任意のバージョン番号；３）配置（すなわち、ＳＡがノードにワーク・パ
ッケージを配置したがサービスはアクティブ化されていない場合）、アクティブ
（すなわちサービスが現在アクティブであることを示す）、またはフォールバッ
ク（たとえば高速の反転を実現するために、サービス・オブジェクトの前のバー
ジョンにもどることが所望された場合）を含むステータス：４）オブジェクト・
インスタンスの物理的場所を識別するＩＰアドレス、ポート、およびその他の情
報を含むことが可能なオブジェクト名または参照；５）稼動日時および休止日時
；６）たとえばオブジェクトが使用可能でない、またはアクティブ化不可である
場合のエラー・プロセス・オブジェクト名；および７）フォールバック・ステー
タスにあるときに実行されるフォールバック・オブジェクト名。ローカル・サー
バＮＯＳネーミング・プロセスは、ＬＲＭステータス・プロセッサ（不図示）に
よって提供されるサービスを利用する。ＬＲＭステータス・プロセッサは、ロー
カル・サーバ・キャッシュ・ステータス・データベースを、サービス制御サーバ
中の特定のＳＬＥＥ中で動作している現在アクティブなサービスに関してのみ更
新する。したがって、ローカル・サーバＮＯＳ名前変換機能は、まず、ローカル
に実行されることが可能である。ＮＯＳがまず名前要求を得ると、論理名を探し
てオブジェクト名（またはオブジェクト参照）を獲得する。ＮＯＳは、論理名か
らオブジェクト名を獲得して、ノードＬＲＭプロセスは、工程８０６で示すよう
に、１つ以上のビジネス・ルールに基づいて処理される、被要求オブジェクトの
最良のインスタンスを決定する。

【０１２６】 工程８０４において、論理名が認識され、オブジェクト参照が使用可能である
場合、処理は、工程８０６のＬＲＭ機能に進み、使用閾値など、特定の評価基準
にしたがって、ＳＬＥＥ１上で動作するＳ２のアクティブ（「使用可能」）なイ
ンスタンスを決定する。アクティブなインスタンスがまったく発見されない場合
、ＬＲＭはＳ２がＳＬＥＥ１上でプログラミングされているか、それにもかかわ
らずインスタンス化されていないかを確認するために調査可能である。そうであ
る場合、ＳＬＥＥ１が十分な使用可能容量があれば、ＮＯＳ７００は、ＳＬＥＥ
上のＳ２のインスタンスをインスタンス化することを決定可能である。上述のよ
うに、サーバ・レベルのＬＲＭは、サーバでアクティブなものを意識し、インス
タンス化されたものを意識するのみである。オブジェクトが現在アクティブで、
ローカル・サーバ・レベルでインスタンス化される場合、このサービスのための
新規のスレッドをインスタンス化するオブジェクト参照がＳＬＰ要求に返される
。ＮＯＳは新規のサービス・スレッドのインスタンス化を開始し、返されたオブ
ジェクト参照に基づいて要求されたサービスを実行し、まだインスタンス化され
ていない場合、オブジェクト参照を返す。

【０１２７】 工程８０４において、ＳＬＥＥ１が十分な使用可能容量を有していない場合、
またはＳ２がＳＬＥＥ１上での動作のために使用可能でない場合、工程８１０に
おいて、ＳＬＥＥ１上のＬＲＭは、サイトＬＲＭ５７７ａにサービス要求を送信
する（図１０）。サイトＬＲＭは、同様のビジネス・ルールを適用し、当該サイ
トの別のＳＬＥＥ上で、Ｓ２のインスタンスがアクティブであるか、またはイン
スタンス化するべきかを決定する。したがって、工程８１０において、ノードＮ
ＯＳ名変換機能はインプリメントされ、要求された論理名が当該ノードで使用可
能であるか、すばわち当該ノードで同一または異なるローカル・サービス制御サ
ーバで別のＳＬＥＥが要求されたサービスの論理名と関連づけられたオブジェク
ト参照を保持するか否かを決定する。工程８１０において、その論理サービス名
が認識される場合、ＮＴサブ・コンポーネント５７０は、ＮＯＳ ＬＲＭ５７５
に問合せを行い、Ｓ２のどのインスタンスを使用するかを決定する。その後、工
程８１４において、ノードＬＲＭはノード・キャッシュ・ステータス・データベ
ース（不図示）に対してビジネス・ルールを適用し、アクティブであれば、要求
されたサービスに対する所望のオブジェクト参照を検索しそのアドレスを呼び出
ししているＳＬＰに返す（図１１（ａ）工程８０２）。サービスが現在インスタ
ンス化されていない、または特定のＳＬＥＥ上の要求されたサービスが処理負荷
または課せられている他の制約に起因してインスタンス化されないことを決定し
た場合、工程８１８において、割り当ておよびローディング処理が実行される。
これは、ノード・キャッシュ・ステータスデータベースを調査し、たとえばサー
ビス近似度、データ近似度、閾値、現在の処理負荷などに関する該当ビジネスル
ールをインプリメントすることによって行われ、サービス・オブジェクトがイン
スタンス化可能であることを決定した場合にＳＬＥＥ中で要求されたサービスを
インスタンス化し、そのアドレスを呼び出しているＳＬＰに返す。なお、ＳＬＥ
Ｅ毎のインスタンス化に対して１つより多いサービスが使用可能である場合、ど
のサービス・スレッドがインスタンス化されるかを決定するには、ラウンド・ロ
ビン方式が実行可能である。

【０１２８】 図１１（ａ）に戻って参照すると、工程８１０において、現在のノードが要求
された論理名を認識しない場合、すなわちノード・キャッシュが要求されたサー
ビスの論理名と関連づけられたオブジェクト参照を有さない、または適用された
ビジネス・ルールに起因して、ノードでオブジェクトをインスタンス化できない
場合、工程８２２において、グローバル・ネットワーク・リソース・ステータス
（ＮＲＳ）プロセス５９０に対して問合せが行われ、知的ネットワーク１７０全
体におけるＳＬＥＥの現在のステータスを調査し、Ｓ２に対するサービス要求を
処理可能であるＳＬＥＥを決定する。この前に、工程８２０において示すように
、調査が行われ、オブジェクト参照を発見するためにネットワーク・リソース管
理に対して問合せが行われた回数を表す索引番号が所定の限界（たとえば３回）
を超過したか否かを決定する。この閾値が超過された場合、プロセスは終了し、
アドミニストレータはサービス・オブジェクトが発見不可であることと、工程８
２１に示すように、エラー状態が存在することとを通知される。ＮＲＳ問合せ閾
値が超過されていない場合、工程８２２に示すように、ＮＲＳプロセス５９０は
、ネットワーク中のどのサービス・ノードが要求されたサービスを実行可能であ
るかを決定する。知的ネットワーク中のノードを決定後、プロセスは図１１（ｂ
）の工程８２４に続き、ノードＮＯＳ名前変換機能５７０ｂは、要求されたサー
ビスの論理名と関連づけられたオブジェクト参照を獲得するためにインプリメン
トされる。工程８２４において、当該ノードでその論理サービス名が認識されな
い場合、工程８２９において、ＮＲＳ問合索引番号はインクリメントされ、プロ
セスは、図１１（ａ）の工程８２０に戻って進み、索引番号閾値が超過しエラー
状態が存在するかを調査する。図１１（ａ）工程８２０において、ＮＲＳ問合せ
索引が所定の閾値を超過していない場合、工程８２２において、ＮＲＳプロセス
５９０に対して再度問合せが行われ、別のサービス・ノードにある使用可能サー
ビスの新規の場所を発見する。

【０１２９】 ステップ８２４において論理ネームが認識されると、そこで処理はステップ８
２６へと続き、受容可能な処理負荷に従って要求されたオブジェクトリファレン
スに関連するアドレスを決定する。このアドレスは、そこで図１１（ａ）のステ
ップ８０２に示すように要求したＳＬＰに対し送り返される。ステップ８２６に
おいて、そのサービスがそれまでインスタンス生成（アクティブ）されていない
場合は、処理はステップ８２８へ進み、そのノードにおけるノードキャッシュ状
態データベース７６８をチェックし、ビジネス規則を実行し、サービスオブジェ
クトがインスタンス生成に利用できると判定された箇所のＳＬＥＥにおける要求
サービスをインスタンス生成することにより、割当と負荷処理とを可能にする。
続いて、インスタンス生成されたオブジェクトＳＬＰのアドレスがステップ８２
４において要求クライアントへ送り返される。

【０１３０】 アクティブなインスタンスＳ２が選択されると、そのＳ２インスタンス生成用
のオブジェクトリファレンスがＳＬＥＥ１上のＮＴへ送り返される（ステップ８
０２）。そして、ＮＴは論理ネームＳ２を選択されたインスタンスＳ２用オブジ
ェクト識別子へと効率的に変換し、そのＳ２用オブジェクト識別子をＳ１とＳ２
との間の相互処理通信に用いる。オブジェクト識別子は、ＩＰアドレスと、ポー
トと、オブジェクトインスタンスの物理位置を特定する他の情報とを含む。オブ
ジェクトリファレンスが決定されたならば、そこでＮＯＳはＣＯＲＢＡ準拠ＯＲ
Ｂ及び、ＵＤＰ／ＩＰのようなプロトコルを除くデータ通信接続を実行すること
により、二つのサービス間でのオブジェクト連結性をもたらす。同じＳＬＥＥ上
で稼働中であろうと或いは数千マイル彼方の別のサイトの他のＳＬＥＥ上で稼働
中であろうと、呼出しを受けたサービス位置は電話サービスにとっては完全に明
らかである。かくして、呼出しを必要とするＳＬＰが遠隔サイトのＳＬＥＥ上で
インスタンス生成されると、この呼出しはこれを受信したスイッチ上に依然とし
て保持される。好ましくは、オブジェクトリファレンスが一度でもアクセスされ
た場合、例えばＮＲＳレベルを経由する他のサイトでは、ＮＢＳがサービス管理
プログラムを介してオブジェクトリファレンスが将来のリファレンス用に要求サ
イトにてキャッシュされ聴取されることを保証するとよい。かくして、現在の例
では、このサービスが再び必要とされるときに、サイトＬＲＭのテーブル探索を
起動することによる一連のテーブル探索を低減するため、サービスＳ２用のオブ
ジェクトリファレンスは、場所の如何によらず、その後にＳＬＥＥ１のＬＲＭ５
７５のローカルキャッシュ内にキャッシュされる。ＳＬＥＥにおいてサービスオ
ブジェクトリファレンスが供給される仕方が様々であることは、当業者には明白
なことである。例えば、ＮＯＳデータ模写機構は、サイトＬＲＭ５７７における
全てのオブジェクトリファレンスをそのサイトにおいて各ＳＬＥＥ用に個別ＬＲ
Ｍに模写するよう設けられる。

【０１３１】 １−８００番呼出し（「１８Ｃ」）のコンテキストでは、１８Ｃ呼出し処理と
サービス利用シナリオを、図１３（ａ）乃至１３（ｃ）のフローチャート及び図
１８の概略機能線図を参照し、例示目的に以下に説明する。最初に、ステップ９
２０に示すように、呼出しは先ずＮＧＳスイッチ機構７５に届く。ＮＧＳが呼出
しを受けると、ベアラ制御要素（図５）が、呼出しを受けたアクセス回線に対し
、ＡＮＩやダイヤル番号や呼出し処理に必要な他のデータ同様、呼出し制御要素
を供給する。呼出し制御要素は、プログラムされたロジックに従って実行される
のに伴い、呼出しのための状態モデルを維持する。状態モデルにはさらに、ＥＬ
Ｐ５４０をインスタンス生成して図１８に示すＦＤ５１０に対しサービス要求を
送信するトリガが含まれる。ＥＬＰをインスタンス生成するため、ＮＧＳ呼出し
制御要素９０は、図１３（ａ）のステップ９２３に示したように、ＥＬＰ用の論
理ネームを用いて、ＮＯＳへのメッセージをアドレス指定する。ＮＯＳはこれに
応答し、サービス管理プログラムオブジェクト（図８）に対しメッセージを送信
し、ＳＬＥＥ内でＥＬＰをインスタンス生成し、ステップ９２６に表したように
、そのＥＬＰ向けのオブジェクトリファレンスを呼出し制御機構へと返送する。
ＮＧＳ呼出し制御要素は、ステップ９２９に示す如くＳＬＥＥ内のＦＤに対し送
信されるサービス要求メッセージ内に、オブジェクトリファレンスを含む。かく
して、どんな処理によっても呼出しに対し生成された全ての適格事象データが、
インスタンス生成されたＥＬＰプロセスへ書き込まれる。特に、サービス要求メ
ッセージはＦＤ用論理ネームに対しアドレス指定され、呼出しを受信したのと同
じサービスノードにおいて、稼働中のＦＤロジックプログラムのための物理アド
レスへＮＯＳ・ＮＴ要素により変換される。サービス要求メッセージには、ダイ
ヤルされた番号とＡＮＩと他のデータとが含まれる。

【０１３２】 次に、ステップ９３１に示すように、ＦＤは機能識別テーブルを用い、どのＳ
ＬＰが受信サービス要求を処理しようとしているかを識別する。例えば、受信メ
ッセージが１８Ｃサービス要求である場合、１８Ｃ・ＳＬＰにより処理すべきと
なる。下記のテーブル３は、例えば１−８００番といった様々な無料電話サービ
スへのポインタを含む見出しを有する略記ＦＤテーブルの一例である。 エントリーポートテーブル 「００１００１」 ＳＬＰポインタ 「Ｖネット」 「００１００１」 ＦＧＤテーブルへのテーブルポインタ ＦＧＤテーブル １８００★テーブルポインタ ８００ テーブル １８８８★テーブルポインタ ８００ テーブル １９００★テーブルポインタ ９００ テーブル １★ＳＬＰポインタ「市内局番」 ８００テーブル 「１−８００−Ｃ」への１８００コレクトＳＬＰポインタ １８００８８８８０００ＳＬＰポインタ「８００サービス」 １８００★ ＳＬＰポインタ「８００サービス」 １８８８★ ＳＬＰポインタ「８００サービス」 ここで、ＦＧＤは機能グループ識別子である。

【０１３３】 特に、回線網（交換台）内で呼出しが発生した箇所及び受信された呼出し種別
（例えば、１−８００番）に基づき、ＦＤは適当なＳＬＰ論理ネームを決定する
。例えば、識別番号「００１００２」は、ＦＧＤテーブル（ＦＧＤテーブルへの
ポインタ）内のテーブル探索を要求する呼出しの領収書を示す。ＦＧＤテーブル
の方は、呼出し番号例えば８００★に基づき、他のテーブルへのポインタを維持
する。ただし、「★」は区切り文字である。この８００テーブルからは、例えば
、ＦＤは要求されたＳＬＰ論理ネームへのポインタを入手する。その結果、この
ＳＬＰが呼出され、サービス要求がＮＯＳに渡され、ＮＯＳが要求のあった１８
Ｃサービスに従ってＣＬＰ５４５，ＬＬＰＯ５３０及びＳＬＰ５２０のオブジェ
クトをインスタンス生成する。例えば、ＬＬＰＯについては、ＬＬＰＯ用の論理
ネームが呼出しを受信したベアラ制御回線に基づいてＮＯＳへ供給される。この
回線の識別は、ベアラ制御要素８０により識別されたＡＮＩもしくはアクセス回
線のいずれかに基づくものである。ＡＮＩは呼出しを発した原アクセス回線を識
別するが、それはＮＧＳが呼出しを受けたアクセス回線と同じだったり異なった
りもする。すなわち、受信された呼出しが、例えばローカルネットワーク上で発
生したもので、互換キャリアネットワーク上のスイッチ７５を通過したものであ
ることがある。それ故、呼出し待機すなわちお話中といった回線関連機能は、Ａ
ＮＩによって識別することができる。ＮＯＳは、ＬＬＰＯのインスタンス生成用
にＬＬＰＯ用の論理ネームを物理アドレスへ変換する。他の論理プログラム（Ｓ
ＬＰ等）は他のサイトにおいてインスタンス生成されるが、一方でＬＬＰをその
関連回線の在るサイトにおいてインスタンス生成することもできる。ＬＬＰはＳ
ＬＥＥにおいてインスタンス生成されるが、ＳＬＥＥはサービス制御サーバもし
くは呼出し制御サーバ上にある。インスタンス生成がなされると、回線関連機能
用のデータ管理機構に照会し、発生回線の状態を維持し、呼出し待機やオーバフ
ローによる経路指定などのあらゆる機能を、これらの機能が呼出し元（例えば、
呼出し待機中）や回線網（オーバフローによる経路指定中）によって呼出された
ときに、呼出す。

【０１３４】 図１３（ａ）のステップ９３４を参照するに、ＮＯＳは例えば１８Ｃといった
呼出される特定のサービスを表す論理ネームを含む機能識別子からサービス要求
の引き渡し要求を受信する。ＮＯＳは、その要求がインスタンステーブル（図示
せず）内の論理ネームならびに表を含むことを確認し、このサービス要求に応え
る可能ないかなるＳＬＰプロセスを有するか否かを判定する。ＮＯＳはまた、ス
テップ９３７に示すように、要求された種別のどのインスタンスを使用すべきか
をＮＯＳ・ＬＲＭ機能を通じて確認する。そして、ステップ９４１に示すように
、ＮＯＳはサービス制御ＳＬＥＥ上で稼働中のサービス管理プログラムオブジェ
クトに対し要求を送信し、要求された１８Ｃ・ＳＬＰサービスを呼出す。好まし
い実施形態では、ＮＯＳはＮＧＳから入来する原サービス要求通告を受信したサ
ービス制御サーバからのＳＬＰを選択するが、ＮＯＳ・ＬＲＭの実行を通じかつ
サービス制御インスタンスのリスト及びそれらの現在の状態とに基づいて、ＮＯ
Ｓがあらゆるサービス制御要素内のＳＬＰを選択し得ることが分かる。ステップ
９４３に示すように、ＮＯＳは選択されたＳＬＰが既にインスタンス生成された
か否か、そして選択されたＳＬＰが未だインスタンス生成されていないかどうか
を判定し、ステップ９４６に示すように、ＳＬＰオブジェクトをインスタンス生
成するようＳＭに指示する。さもなくば、選択されたＳＬＰが既にインスタンス
生成されている場合は、スレッド管理プログラムが、ステップ９４５に示すよう
に、ＳＬＰオブジェクトに対し新規の処理スレッドを割り当てる。

【０１３５】 図１３（ｂ）の次のステップ９４９は、インスタンス生成されたＳＬＰ処理が
その物理アドレスをＮＯＳに登録することと、ＮＯＳがそのＳＬＰをサービス要
求に割り当てることを要求する。そして、ＮＯＳは、ステップ９５１に示すよう
に、新規のＳＬＰに対しサービス要求引き渡しメッセージを渡す。それと並行し
て、ＮＯＳはインスタンス生成されＣＬＰに対し、インスタンス生成されたＳＬ
Ｐ，ＥＬＰ及びＬＬＰＯのオブジェクト用のオブジェクトリファレンスを含む全
データを送信する。ＣＬＰとＥＬＰ向けのオブジェクトリファレンスはまたＬＬ
ＰＯとＳＬＰへと供給され、これによりＬＬＰＯとＳＬＰはＣＬＰ及びＥＬＰと
のインターフェースをとることができるようになる。最後に、ステップ９５４に
示すように、ここでＳＬＰはプログラムされたロジックに従って呼出し処理を開
始する。

【０１３６】 １８Ｃ呼出しのコンテキストでは、１８Ｃ・ＳＬＰ５２０は好ましくは、１８
Ｃ経路指定データベース（図示せず）から必要なデータを入手し、適切な決定を
下す。図１３（ｃ）に示すように、１８Ｃ・ＳＬＰ５２０は、以下のステップを
呼出す。すなわち、ステップ９６０において、ＮＯＳ・ＮＴ向けに１８Ｃ経路指
定データが必要とする論理ネームを送信し、ステップ９６２に示したように、１
８Ｃ経路指定データベースの論理ネームをＤＭに照会し、実際の１８Ｃ経路指定
ＤＢネームとその格納位置とをＤＭから受信し、ステップ９６４に示したように
、ＮＯＳ・ＬＲＭに対し要求を発して１８Ｃ経路指定データベースの局所的な利
用が可能であるかどうかを判断し、可能であれば、ステップ９６６に示したよう
に、１８Ｃデータベースの物理アドレスを１８ＣＳＬＰへ送り返し、ステップ９
６８に示したように、呼出された８００−何番と回線ＩＤと原スイッチ中継回線
とＡＮＩとを送信することにより、顧客プロファイルのテーブル探索についてデ
ータ管理機構へ照会を送信し、ステップ９７０及びステップ９７２に示すように
、経路指定応答で特定された終端の実際の終端位置（ノード）のテーブル探索を
ＤＭに対し要求し、ＤＭから実際の終端ノード位置を受信することにより、１８
Ｃ・ＳＬＰへ戻るスイッチ／中継回線を含む最終の経路指定情報をＤＭから受信
する。その後の処理は、例えばＤＭ内に格納された呼出しコンテキストデータ内
に配置するため、ＥＬＰ５１０に対する経路指定応答情報の送信を必然的に伴い
、経路指定情報を含むＣＬＰ５４５向けの引き渡しコマンドとともに発呼要求を
送信する。このシナリオでは終端ノードは遠隔地にあるが、この場合、遠隔ノー
ド上の終端ＬＬＰをインスタンス生成し、プロファイルのテーブル探索を実行し
て終端回線上のあらゆる機能を判定することが必要になる筈である。他のサービ
スの流れのシナリオでは、ＳＬＰは１以上の他のＳＬＰを呼出さばならないこと
もある。

【０１３７】 ＳＬＰが呼出しに対し回線網の終端を決定するか、或いはさもなくば例えばＤ
ＴＭＦディジット又は再生音声を検知するよう資源複合体に対する対応を決定す
ると、ステップ９５７に示すように、ＮＧＳ呼出し制御機構に対しサービス応答
メッセージを送信する。呼出し制御機構は、そこでステップ９５９に示すように
、ＮＧＳスイッチ７５’（図１４）に指示して回線網終端への呼出しを準備し完
了させることを含む指示を実行する。

【０１３８】 より詳細には、呼出しダイアルにおいてＮＯＳエージェントに対し進められる
ＬＬＰＯ（発生回線）への引き渡しコマンドを伴う発呼を送信し、そのことで呼
出しが終端ノードへ経路指定される。ＥＬＰプロセスは、そこで、発呼呼出しコ
ンテキストデータをＤＭへ書き込む。

【０１３９】 ステップ９５７へ戻ると、ＳＬＰが回線網終端用物理アドレスの呼出し制御へ
復帰すると、そこでＬＬＰＴプロセス５３１は呼出しが終端された回線について
インスタンス生成される。このことが、ＮＯＳをしてＬＬＰＴ用の論理ネームを
ＳＬＰにより与えられた回線網終端に関連付けることを可能にする。ただし、こ
の論理ネームは、ＳＬＰ（一実施形態）もしくはＦＤ（他の実施形態）へのサー
ビス要求内の呼出し制御のどちらかによって与えられるものである。ＮＯＳの方
は、終端回線が存在する箇所のサービスノードにおいてＳＬＥＥ内のＬＬＰＴを
インスタンス生成する。

【０１４０】 或いはまた、ステップ９５７において、ＳＬＰが１８Ｃ呼出しの処理例におけ
る例えばＩＶＲ機能といった特定資源に対する要求を代わりに送り返すこともあ
る。ＮＧＳは何れの資源、すなわちＩＶＲの可能性をもったスイッチポートとか
ＶＲＵポート等の何れを割り当てるべきかを決定し、資源用アドレスをＳＬＰに
対して送り返す。ＳＬＰはそこで、その資源に関連したＬＬＰＴ用のアドレスを
（データ管理機構への照会を介して）識別し、そのＬＬＰＴのインスタンス生成
を要求する。その呼出しは、そこでその資源へと経路指定され、恐らくＮＧＩＮ
に対する他のサービス要求とともに処理される。

【０１４１】 呼出しが完了すると（すなわち、両者の接続が切断されると）、ＬＬＰＴは各
スイッチ７５，７５’（図１４）におけるＮＯＳ要素から呼出し完了通告を受け
、呼出し完了通告をＣＬＰに向けて送り出す。ＣＬＰは、関連するＬＬＰＳ及び
ＥＬＰに対し呼出し完了通告を送り出し、ＣＬＰ通告によりトリガされるのに伴
って強制切断する。切断に先立ち、呼出し完了後に例えば請求と他の様々な目的
のための維持する必要のあるＥＬＰ呼出し詳細データが、先ず格納されることに
なる。

【０１４２】 上記のごとく、いくつかの好ましい実施形態を詳細に記述した。本発明の範囲
はまた、記述したものとは異なる実施形態であっても、特許請求の範囲にさえ含
まれる実施形態であれば包含することは理解さるべきである。

【０１４３】 例えば、汎用コンピュータは、一つの型の応用向けに特別に作られたものでな
いことが分かる。汎用コンピュータは、発明を実施するのに必要な機能を遂行で
きるいかなる大きさのどんな計算機であってもよい。

【０１４４】 追加例としては、「ジャバ」プログラミング言語は、発明の実施に必要な同様
の機能を有して同様の機能を遂行する他の等価なプログラミング言語でもって置
換可能である。

【０１４５】 ここにおけるこれらの用語の使用法は、他の用語と同様、発明をこれらの用語
だけに限定する意図をもつものではない。使用する用語は、同義語及び／又は等
価物を指す他のものと置換することもできる。包含する言葉は、発明の範囲に鑑
みて非網羅的に解釈さるべきである。本発明の様々な実施形態が、ハードウェア
やソフトウェア或いはマイクロコード化されたファームウェアを採用したり、そ
こに埋設したりできることも理解さるべきである。

【０１４６】 本発明は、上述の実施形態に関連して開示しかつ論じてきたが、当業者にとっ
ては、本発明の意図と範囲内において、多数の変更と変形と修正が可能であるこ
とは明白である。従って、それ故に、以下の特許請求の範囲は、そうした変形と
修正を包含させたものであることを意図したものである。

【図面の簡単な説明】

【図１】 様々なスイッチイングアーキテクチャの論理表現である。

【図２】 従来技術による典型的なインテリジェント・ネットワーク・コン
フィグレーションを使用する通信システムの図表である。

【図３】 インテリジェント分散ネットワーク・アーキテクチャを使用する
通信システムの図表である。

【図４】 （ａ）は、次世代インテリジェント・ネットワークのＳＡおよび
ＤＭコンポーネントを示すブロック図である。（ｂ）は、サービス管理コンポー
ネント３００の機能を概念的に示す。（ｃ）は、データ管理コンポーネント４０
０の機能アーキテクチャを示す。

【図５】 本発明によるインテリジェント分散ネットワーク・アーキテクチ
ャを使用する通信システムの論理機能図である。

【図６】 本発明によるインテリジェント呼処理装置内の機能インタフェー
スの積層化を示す図表である。

【図７】 本発明によるインテリジェント呼処理装置の管理対象オブジェク
トのクラス階層を示す図表であ。

【図８】 サービス制御環境４３０の好ましいアーキテクチャを示す。

【図９】 ＮＯＳ ＮＴおよびＬＲＭ機能サブコンポーネントの機能的アー
キテクチャを示す。

【図１０】 インテリジェント・ネットワークのリソース管理システムのア
ーキテクチャを示す。

【図１１】 （ａ）は、３層インテリジェント・ネットワーク・リソース管
理機能を示す。（ｂ）は、３層インテリジェント・ネットワーク・リソース管理
機能を示す。

【図１２】 （ａ）は、ＳＬＥＥ起動プロセスを示す。（ｂ）は、サービス
・マネージャ・プロセスを示す。（ｃ）は、ＳＬＥＥクラスローダ・プロセスを
示す。（ｄ）は、サービス・エージェント機能を示すフローチャートを示す。（
ｅ）は、サービス・エージェント機能を示すフローチャートを示す。（ｆ）は、
スレッド・マネージャ・プロセスを示す。（ｇ）は、サービス・エージェント・
ポストイベント・プロセスを示す。

【図１３】 （ａ）は、１−８００／８ｘｘ呼処理サービスを実行するプロ
セスフローの例を示す。（ｂ）は、１−８００／８ｘｘ呼処理サービスを実行す
るプロセスフローの例を示す。（ｃ）は、１−８００／８ｘｘ呼処理サービスを
実行するプロセスフローの例を示す。

【図１４】 ＩＤＮＡ／ＮＧＩＮによって処理される呼処理シナリオを示す
。

【符号の説明】

１７２ ＩＣＰ １８０ リソース複合体（ＲＣ） ２００ インテリジェント分散ネットワーク・アーキテクチャ ２０２ 広域ネットワーク（ＷＡＮ） ２０４ ＩＤＮＡノード ２１０ 補助処理装置 ２１２ ＮＭＳ ２１４ 直接リンク ２１６ 信号 ２１８ 伝送線 ２２４ 高速データ通信パイプ ２２６ 操作リンク ２２８ ＭＯＣＥ ２３０ レポジトリ ２４０ ＩＣＰ−ＮＭＳエージェント ２４２ ＳＬＥＥ ２４４ 管理対象オブジェクト ２４６ リソースプロキシクラス ２４８ 支持体制御クラス ２５０ コール制御クラス ２５２ サービス制御クラス ２５４ 他のリソース複合体

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ， ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，Ｋ Ｅ，ＬＳ，ＭＷ，ＳＤ，ＳＬ，ＳＺ，ＴＺ，ＵＧ，ＺＷ )，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ， ＴＪ，ＴＭ)，ＡＥ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ， ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，Ｃ Ｒ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＤＭ，ＥＥ，ＥＳ，ＦＩ ，ＧＢ，ＧＤ，ＧＥ，ＧＨ，ＧＭ，ＨＲ，ＨＵ，ＩＤ， ＩＬ，ＩＮ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，Ｋ Ｚ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＡ ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ， ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，Ｓ Ｋ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＴＺ，ＵＡ，ＵＧ ，ＵＺ，ＶＮ，ＹＵ，ＺＡ，ＺＷ (71)出願人 サミ・サイド アメリカ合衆国・コロラド・80919・コロ ラド・スプリングス・ラグリー・コート・ 125 (72)発明者 アジェイ・デオ アメリカ合衆国・テキサス・75056・ルイ スヴィル・サー・トリスタン・レーン・ 2508 (72)発明者 ウェンディ・ウォン アメリカ合衆国・テキサス・78287・ダラ ス・ケイプ・コーラル・ドライブ・4816 (72)発明者 ヘンリー・ワン アメリカ合衆国・コロラド・80919・コロ ラド・スプリングス・ガーデン・オブ・ ザ・ガッズ・ロード・2424 (72)発明者 サミ・サイド アメリカ合衆国・コロラド・80919・コロ ラド・スプリングス・ラグリー・コート・ 125 Ｆターム(参考） 5K024 AA01 AA71 5K026 CC07 FF02 FF03 GG01 5K030 GA08 GA15 HA08 HB17 HC02 HD05 HD06 5K051 BB01 BB02 CC01 CC02 DD01 EE01 EE02 FF01 HH04

Claims (16)

【特許請求の範囲】
1. 【請求項１】 それぞれ、メモリ記憶装置と、サービス・ノードに関連した
   ネットワーク・スイッチ素子における事象の受信に応答して、サービスを実施す
   るための実行環境を備えた、複数のサービス・ノードを有する通信ネットワーク
   に関するサービス制御システムであって、 各ノード毎に、各ノードにおけるサービス処理に関連したサービス・オブジェ
   クト資源のタイプ及び量を含むサービス・プロファイルを生成し、前記プロファ
   イルに基づいて、サービス・オブジェクト資源の前記タイプ及び量を前記ノード
   にダウンロードするためのサービス・アドミニストレータと、 前記１つ以上の実行環境における実行に備えて、サービス・オブジェクトのイ
   ンスタンス生成を行うためのインスタンス生成機構と、 サービス・ノードにおける実行環境資源を追跡して、前記ネットワークの各サ
   ービス・ノードにおいて利用可能なサービス・タイプのリストを保守し、各サー
   ビス・タイプの関連機能状況によって、要求されるサービスが、サービス・ノー
   ドにおけるインスタンス生成に利用可能であるか否かが表示されるようにするた
   めの資源管理装置と が含まれており、 前記機能状況によって、要求されるサービスが前記ネットワークにおけるイン
   スタンス生成に利用不可能であることが表示されると、前記資源管理装置は、新
   しいサービス・オブジェクトのインスタンス生成が必要であることを前記中央ア
   ドミニストレータに伝え、サービス・ノードにおける新しいサービスのダウンロ
   ード及び起動を実施させることを特徴とするシステム。
2. 【請求項２】 前記インスタンス生成機構に、 前記メモリ記憶システムから１つ以上のサービス・オブジェクトをロードし、
   前記実行環境内における実行に備えて、前記１つ以上のオブジェクトのインスタ
   ンス生成を行うための第１のオブジェクトと、 特定のサービスに対応し、そのサービスに関する各受信要求に対応する各サー
   ビス・インスタンスに１つ以上のサービス・スレッドを割り当て、各サービス・
   スレッド・インスタンスに、一意性の識別子が対応づけられるようにする第２の
   オブジェクトと が含まれることを特徴とする請求項１に記載のシステム。
3. 【請求項３】 さらに、実行中のオブジェクト・インスタンス間においてメ
   ッセージ及び事象の実時間伝達を行うためのネットワーク・オペレーティング・
   システムが含まれることと、特定のサービスに対応する前記第２のオブジェクト
   が、前記サービス・インスタンス間における事象及びメッセージのチャネリング
   を行うことと、前記事象及びメッセージに、受信メッセージ及び事象を適正なサ
   ービス・インスタンスに対応づけるための前記一意性識別子が含まれることを特
   徴とする請求項２に記載のシステム。
4. 【請求項４】 さらに、各サービス・スレッド・インスタンス毎に割り当て
   られた、サービス実行中に受信する前記サービス・インスタンスに対応づけられ
   た事象を待ち行列に入れるための事象待ち行列機構が含まれ、 事象には、前記事象を実施すべき順番を指示する関連優先順位があることと、
   前記事象待ち行列装置が、その関連優先順位に基づいて受信事象の処理を可能に
   することを特徴とする請求項３に記載のシステム。
5. 【請求項５】 さらに、前記サービス・ノードに関する初期サービス機能を
   実施する構成ファイルに従って、まず、前記メモリ記憶システムから１つ以上の
   サービス・オブジェクトをロードするクラス・ローダ・プロセスが含まれること
   と、前記クラス・ローダが、事前定義サービス機能戦略に従って、利用可能な前
   記第１のオブジェクト及び任意のサービス・オブジェクトのインスタンス生成を
   行う責務を負うことを特徴とする請求項３に記載のシステム。
6. 【請求項６】 特定のサービスに対応する前記第２のオブジェクトに、ある
   サービスに関連したスレッド・インスタンスの量と前記サービス・プロファイル
   において求められる所定のしきい値を比較し、前記実行環境において、新しいサ
   ービス・スレッド・インスタンスのインスタンス生成がもはや支援されない場合
   、前記資源管理装置に対する警告信号を発生するためのスレッド・マネージャ・
   インスタンスが含まれることを特徴とする請求項３に記載のシステム。
7. 【請求項７】 前記サービス・オブジェクト・インスタンス生成機構に、前
   記ネットワーク・オペレーティング・システムが含まれることと、前記資源管理
   装置が、さらに、各サービス・ノードにおける実行環境の処理能力を追跡し、そ
   の処理能力に基づいて、あるサービス・ノードにおける実行環境で、あるサービ
   スの実行が可能であるか否かを前記ネットワーク・オペレーティング・システム
   に表示することを特徴とする請求項６に記載のシステム。
8. 【請求項８】 前記資源管理装置が、さらに、ある実行環境において現在実
   行中のサービス・スレッド数が、前記所定のしきい値を超えると、前記ネットワ
   ーク・オペレーティング・システムにオーバロード状況表示を伝達し、前記実行
   環境におけるそれ以上のサービス・オブジェクトのインスタンス生成を阻止する
   ことを特徴とする請求項７に記載のシステム。
9. 【請求項９】 前記インスタンス生成機構に、 各前記実行環境に設けられた実行環境で実行されるサービスのインスタンスに
   対応するアクティブ・サービス・オブジェクト・スレッドのレジストリと、 オブジェクト参照を備えたサービス論理名をマッピングするためのマッピング
   装置と が含まれていることと、 前記ネットワーク・オペレーティング・システムが、前記オブジェクト参照を
   利用して、局所実行環境において要求されるサービス・オブジェクト・スレッド
   ・インスタンスのインスタンス生成を可能にすることを特徴とする請求項３に記
   載のシステム。
10. 【請求項１０】 各サービス・ノード毎に、メモリ記憶装置と、サービス・
    ノードに関連したネットワーク・スイッチ素子における事象の受信に応答して、
    サービスを実施するための実行環境が設けられた、通信ネットワークのサービス
    ・ノードにおいてサービスを提供するための方法であって、 各サービス・ノード毎に、各ノードにおけるサービス処理に関連したサービス
    ・オブジェクト資源のタイプ及び量を含むサービス・プロファイルを生成し、前
    記プロファイルに基づいて、サービス・オブジェクト資源の前記タイプ及び量を
    前記ノードにダウンロードするステップと、 前記１つ以上の実行環境における実行に備えて、サービス・オブジェクトのイ
    ンスタンス生成を行うステップと、 各サービス・ノードにおいて利用可能なサービス・タイプのリストを保守する
    ことによって、サービス・ノードにおける実行環境資源を追跡し、各サービス・
    タイプの関連機能状況によって、要求されるサービスが、サービス・ノードにお
    けるインスタンス生成に利用可能であるか否かが表示されるようにするステップ
    と が含まれており、 前記機能状況によって、要求されるサービスが前記ネットワークにおけるイン
    スタンス生成に利用不可能であることが表示されると、新しいサービス・オブジ
    ェクトのインスタンス生成が必要であることを中央アドミニストレータ装置に伝
    え、サービス・ノードにおける新しいサービス・オブジェクトのダウンロード及
    び起動を実施させることを特徴とする方法。
11. 【請求項１１】 前記インスタンス生成ステップに、 受信したサービス要求に従って、前記メモリ記憶システムから１つ以上のサー
    ビス・オブジェクトをロードし、前記実行環境内における実行に備えて、前記１
    つ以上のオブジェクトのインスタンス生成を行うための第１のオブジェクトを設
    けるステップと、 特定のサービスに対応し、そのサービスに関する各受信要求に対応する各サー
    ビス・インスタンスに１つ以上のサービス・スレッドを割り当て、各サービス・
    スレッド・インスタンスに、一意性の識別子が対応づけられるようにする第２の
    オブジェクトを設けるステップと が含まれることを特徴とする請求項１０に記載の方法。
12. 【請求項１２】 さらに、サービス処理を支援して、１つ以上の実行中のサ
    ービス・オブジェクト間において、サービス・オブジェクトの実行中に生成され
    るメッセージ及び事象を伝達するステップが含まれることと、前記事象及びメッ
    セージが、前記一意性識別子によって識別され、前記第２のオブジェクトを介し
    て実行中のサービス・インスタンスが補正されることを特徴とする請求項１１に
    記載の方法。
13. 【請求項１３】 さらに、サービス実行中に受信する、実行中のサービス・
    インスタンスに対応づけられた事象を待ち行列に入れるステップが含まれること
    と、前記事象には、前記事象を実施すべき順番を指示する関連優先順位があるこ
    とと、前記受信事象が、その対応する優先順位に基づいて処理されることを特徴
    とする請求項１２に記載の方法。
14. 【請求項１４】 さらに、前記サービス・ノードに関する初期サービス機能
    を提供する構成ファイルに従って、まず、前記メモリ記憶システムから１つ以上
    のサービス・オブジェクトをロードするステップが含まれることと、前記クラス
    ・ローダが、前記クラス・ローダが、事前定義サービス機能戦略に従って、利用
    可能な前記第１のオブジェクト及び任意のサービス・オブジェクトのインスタン
    ス生成を行う責務を負うことを特徴とする請求項１０に記載の方法。
15. 【請求項１５】 サービス・ノードにおける実行環境資源を追跡する前記ス
    テップに、 あるサービスに関連したスレッド・インスタンスの量と前記サービス・プロフ
    ァイルにおいて求められる所定のしきい値を比較するステップと、 前記実行環境において、新しいサービス・スレッド・インスタンスのインスタ
    ンス生成がもはや支援されない場合、資源管理装置に対する警告信号を発生する
    ステップと が含まれることを特徴とする請求項１１に記載の方法。
16. 【請求項１６】 前記インスタンス生成機構に、 各前記実行環境に設けられた実行環境で実行されるサービスのインスタンスに
    対応するアクティブ・サービス・オブジェクト・スレッドのレジストリを保守す
    るステップと、 オブジェクト参照を備えたサービス論理名をマッピングするステップと、 前記オブジェクト参照を利用して、局所実行環境において要求されるサービス
    ・オブジェクト・スレッド・インスタンスのインスタンス生成を可能にするステ
    ップと が含まれることを特徴とする請求項１０に記載の方法。