JPH11513214A

JPH11513214A - インテリジェント・ネットワークなどの電気通信システムにおける拡張機能インタラクションの管理

Info

Publication number: JPH11513214A
Application number: JP10503506A
Authority: JP
Inventors: リン，フゥーチゥュン，ジェー．; ピンヘイロ，ロバート，エー．
Original assignee: ベルコミュニケーションズリサーチ，インコーポレイテッド
Priority date: 1996-06-26
Filing date: 1997-06-25
Publication date: 1999-11-09
Also published as: EP0901729A4; CA2257939C; CA2257939A1; US5999610A; WO1997050232A1; EP0901729A1

Abstract

(57)【要約】サービス起始ノード（１０４）と複数の供用ノード（１０８，２０２，２０４）の間の通信を管理し、供用ノード（１０８，２０２，２０４）が特定トリガ（１１６）について同時にアクティブになることによりサービス起始ノードへの応答を生成する方法である。本方法は指導者として機能する供用ノードのサービス専門家によって供給されたサービス・インタラクション原理を取り込むことによってサービス分類を表わす各々のトリガについての制御オプションを決定するステップを含む。サービス・インタラクション原理は各トリガについて供用ノードの各々でサービス分類を実行する要件に基づく。本方法は制御オプションを参照して特定のトリガについてのサービス・ノードとサービス分類の各々の実行を制御して応答を生成するステップも含む。

Description

【発明の詳細な説明】インテリジェント・ネットワークなどの電気通信システムにおける拡張機能インタラクションの管理関連出願への相互参照本出願は仮出願番号第６０／０２０，５５４号の通常の出願である。発明の分野本発明は電気通信ネットワークに関し、さらに詳しくは高度インテリジェント・ネットワーク（ＡＩＮ）などのインテリジェント・ネットワーク（ＩＮ）においてノード間の通信管理のための制御論理の生成及び使用の方法に関する。発明の背景ＡＩＮは米国において全ての近代的電話交換システムで使用されるネットワーク・アーキテクチャである。ＡＩＮは、全ての電気通信ネットワーク（たとえば、統合サービスデジタル網（ＩＳＤＮ）を含む公衆交換電話網（ＰＳＴＮ））、狭帯域、広帯域、パケット交換公衆データ網、移動体電話網に適用できる。図１は地域交換通信業者（ＬＥＣ）によって設定されたＡＩＮの略図を示す。ＡＩＮの構成要素としては、（ｉ）サービス交換ポイント（ＳＳＰ）などの交換システム１０４を含む中央局１０２、（ｉｉ）中間交換ノードとして機能する信号転送ポイント（ＳＴＰ）の多レベル階層から構成される信号ネットワーク１０６、（ｉｉｉ）集中データベースを含むサービス制御ポイント（ＳＣＰ）１０８が含まれる。中央局１０２の各々にはＳＳＰ１０４が設置される。ＡＩＮにおいて、ＳＳＰ１０４はＳＣＰ１０８によるＡＩＮ処理を要求することを認識できる交換機である。ＡＩＮによって提供されるサービスを例示するため、特殊な処理、たとえば無料通話（８００番サービス）などを要求する電話を顧客がかける場合を考える。発呼は交換システム１０４によって取り込まれ、交換システムは信号ネットワーク１０６経由でＳＣＰ１０８にある集中データベースへの問い合わせを発行する。次にデータベースは呼処理に必要な情報を取り出し”論理”８００番から”物理”ルーティング番号へ割り当てる番号変換を実行する。物理ルーティング情報が信号ネットワーク１０６経由で交換システム１０４に返されて発呼を完了できる。番号変換はＡＩＮで定義されている複数のいわゆるサービス分類の１つの一例である。ＳＣＰ１０８によってサービスされる各々のサービス分類はＳＳＰ１０４とＳＣＰ１０８の間の問い合わせ／応答トランザクションを取り扱う論理で構成される。図１には代表的に１０，０００から７０，０００回線規模の複数加入者線１１０も示してあり、これらは各中央局１０２に接続されている。加入者回線１１０各々は電話端末装置１１２の終端部分に接続される。電話端末装置１１２は電話機、ファクシミリ装置、コンピュータ、自動ダイアラを含む。中継回線１１４は中央局１０２を相互接続し発呼が完了した時点で局間通信を接続する音声経路である。トリガはＳＳＰ１０４がＡＩＮによる特別な処理を必要とする呼を識別するための処理である。ＳＳＰ１０４は一組の所定の条件が検出された場合にＳＳＰ１０４が発呼回線上のアクティビティに応じてトリガ１１６に遭遇するようにする適当なハードウェア及びソフトウェアを有する。トリガ１１６はＳＣＰ１０８に送信すべき問い合わせを生成する特定の加入者回線１１０に付属するイベントである。トリガ検出ポイント（ＴＤＰ）は、サービス論理が所与のイベントの通知を受信し後続の呼処理に影響する呼処理上のポイントである。トリガ１１６は回線に接続している電話端末装置がオフフックし、ダイアルをはじめるなどの時に特定の加入者回線１１０を識別するための情報を含む。トリガ１１６に遭遇すると、ＳＳＰ１０４は呼処理を一時保留する。各トリガ１１６はＳＳＰ１０４がＳＣＰ１０８へ発するデータ・パケットの形で問い合わせを生成してどのように呼処理するかの指示を尋ね、要求された呼処理情報を取得する。データ・パケットは第１に双方向データリンク１１８経由でＳＴＰ１０６へＮｏ７信号方式（ＳＳ７）プロトコルを使用して送信される。ＳＳ７は２つのポイント即ちＳＣＰ１０８とＳＴＰ１０６を接続する多数の物理リンク上に等しくデータ・パケットを分散する。ＳＴＰ１０６はＳＳＰ１０４及びＳＣＰ１０８などのネットワーク・ノード間でメッセージを伝送できる超大容量超高信頼性パケット交換機である。ＳＴＰ１０６は基本的にネットワーク上のトラフィックを監督するものであり、高速データリンク１２０経由で意図した宛先（即ちＳＣＰ）へデータ・パケットをルーティングする。ＳＣＰ１０８は適当な呼のルーティング情報を提供し特定の加入者を識別する各種の集中データベースを含むフォールトトレラント・トランザクション処理システムである。ＳＣＰ１０８はＳＳＰ１０４から受信した要求（即ちトリガ）に応答する。トリガ１１６はＳＣＰ１０８にデータベースへ問い合わせを行なわせて、この特定の呼についてある種の顧客発呼機能または拡張サービスを実施すべきかまたは従来のダイアルアップ電話サービスを呼に提供すべきか決定する。データベース問い合わせの結果はＳＴＰ１０６経由で高速データリンク１２０上の戻りパケットの形で返送され双方向データリンク１１８を通ってＳＳＰ１０４へ到着する。パケットの戻りはどのように呼処理を継続するかについてのＳＳＰ１０４への指示を含む。サードパーティのためのＬＥＣで運用されるＡＩＮのオープンアクセスはサードパーティ・サービス・プロバイダの能力と効率を活用してサードパーティが地域ＬＥＣ加入者に対して競合する電話関連サービスを提供できるようにする。ＡＩＮへのオープンアクセスを提供してサードパーティの能力及び効率を活用することに関連した従来技術のアプローチの代表が、１９９５年４月のＩＳＳ’ ９５第２巻に開示されたＷayne Ｈeinmiller、Ｒon Ｓchwartz、Ｍarianne Ｓta nkeによる”インテリジェント・ネットワークへの仲介アクセスの解決方法”と題する論文である。この論文は全てのサービス・プロバイダに属するＳＣＰからＩＮへのアクセスを許可し、仲介ポイント（ＭＰ）と標識されたネットワーク要素に駐在する仲介と呼ばれる新規のネットワーク機能セットを定義するサービス・アーキテクチャを提案した。こうして得られた論理的ネットワーク・アーキテクチャが図２に図示してある。このアーキテクチャで重要な属性は、サービス・プロバイダのＳＣＰ（各々１０８，２０２，２０４）とＳＳＰ１０４の相互接続ポイントであるＭＰ２００である。ＭＰ２００はＳＳＰ１０４と多数のＳＣＰ（ＳＣＰ１０８，ＳＣＰ２０２，ＳＣＰ２０４）の間に存在する。データリンク２０６はＭＰ２００をＳＳＰ１０４へ接続する。データリンク２０８，２１０，２１２はＭＰ２００をＳＣＰ１０８，２０２，２０４へ各々接続する。ＭＰはＳＳＰとＳＣＰの間のトランザクションに対して透過的であることを意図している。ＩＮのような分散呼処理環境でのいわゆる“拡張機能インタラクション（feat ure interactions）”は図２に図示したアーキテクチャで使用すると問題になる。フレーズ“拡張機能インタラクション”はたとえば拡張機能をサービスする複数のＳＣＰによる実行を行なわせる動作の成果を表わす。たとえば、１つのＳＣＰによってサービスされる拡張機能をＡで表わし、別のＳＣＰでサービスされる別の拡張機能をＢで表わした場合、（ｉ）Ａから先に順番に、（ｉｉ）Ｂから先に順番に、（ｉｉｉ）同時に、ＡとＢに問い合わせる場合に異なる結果が得られる。この問題に関して、論文では良い解決方法は破壊的な副作用を防止し、多数の独立したサービス・プロバイダをサポートし、ユーザのサービス要求全部を満足させながら実際の特定サービスの知識を備えない必要があることを述べているが、不可能ではなくとも非常に困難な仕事であると述べている。さらに、サービスを組み合わせる能力は、各ユーザの特定の要求に適合させるためにカスタマイズされる必要があり、そのようにする能力は競争に対してオープンでなければならず、またそのことは電話行政の唯一の権限ではない。前述の要因を考慮した後で、論文の著者らは拡張機能インタラクションへの普遍的一般的解決方法の必要性があることは可能ではなく、おそらくは望ましくもないであろうと結論している。サービス・プロバイダは拡張機能インタラクションがネットワーク外部に配置され、あらゆるサービス・プロバイダがユーザと一緒にユーザの要求に基づいた解決方法をカスタマイズできるようにすることを望んでいる。これ以外に、ユーザは、ユーザと相談して１つまたは２つ以上のサービス・プロバイダを選択し適当なインタラクションを考察する”サービス・ブローカ”と一緒に使用することができる。拡張機能インタラクションは高度な通信を必要とすることが多いので、著者は拡張機能インタラクションの影響を緩和するためサービス・プロバイダ間でＳＣＰからＳＣＰへの直接接続の必要性を予想している。ＳＣＰとＳＣＰ間の接続は、顧客に拡張機能インタラクションの改善を供給するのが有益であるとサービス・プロバイダが判定した場合に行なわれることになる。今日まで、ＬＥＣによって運用されるＡＩＮへのオープンアクセスを提供することを成し遂げることによるその他の業績の多くでは、所与の加入者（即ち、特定のトリガによって呼び出される１つまたは２つ以上のサービス分類に加入するＬＥＣ顧客）に対して、特定のトリガに遭遇することにより呼び出されるサービス分類全部が同じサービス・プロバイダ・システムにより提供されるべきであろうと仮定している。言い換えれば、単一のＳＣＰだけが所与の加入者回線でアクティブな特定のトリガへアクセスできる。ＳＣＰはＬＥＣまたはサードパーティが保有できる。所与の加入者回線でアクティブな特定のトリガへのアクセスが可能な単一のＳＣＰだけに固有の問題が存在する。たとえば、これは加入者が有するサービスの個数またはサービスの組み合わせを大幅に制限し、ＡＩＮをサードパーティに開放する本来の意図を減少させている。さらに、１つのサービス・プロバイダが所与の加入者でアクティブな特定のトリガを独占できるが、これは同じトリガを使用してその加入者に対するサービスを後で提供できる他のサービス・プロバイダが無いためである。即ち、サードパーティの能力及び効率を活用できるようにＡＩＮへのオープンアクセスを提供する必要が未だ存在している。さらに、上記で明示したように、従来技術の教示及び示唆は拡張機能インタラクション問題への普遍的一般的解決策が事実上不可能であることを示唆している。この従来技術の教示及び示唆により提供される教訓は本発明の主題による当該技術からの逸脱点として用いる。ＡＩＮにおいて、特にＳＳＰ−多数ＳＣＰ環境における拡張機能インタラクションにおいてノード間の通信管理のための制御論理を生成して使用する一般的方法論を作成しようとする既知の試みは存在していない。発明の要約従来技術のこれらの欠点や制約は、サービス起始ノードと複数の供用ノードの間の通信を管理する方法であって供用ノードが特定のトリガに対して同時にアクティブになることによってサービス起始ノードへの応答を生成する本発明によって解決される。本発明の方法は、指導者として機能する供用ノード・サービスの専門家によって供給されるサービス・インタラクション原理を取り込むことによってサービス分類を表わす各々のトリガについての制御オプションを決定するステップを含む。サービス・インタラクション原理はサービス分類の多くとも１つを各トリガについて供用ノードの各々で実行する条件に基づいている。本方法は又制御オプションを参照して応答を生成し特定のトリガについてサービス・ノードの各々とサービス分類の各々に対応する１つの実行を制御するステップも含む。本発明の構成及び動作は添付の図面と関連させて後述の好適実施例の詳細な説明の勘案からより良く理解されるであろう。図面の簡単な説明本発明の各種実施例が図面を参照して本明細書に記載図示される。図面において同じ項目は同じ参照番号で表わされる。図１は従来のＡＩＮのブロック図である。図２はＭＰと呼ばれる機能要素を含むＡＩＮの従来技術による論理ネットワーク・アーキテクチャのブロック図である。図３はサービスが同じＳＣＰに存在するトリガでの多数のサービスのための物理ネットワーク・アーキテクチャの実施例を示す。図４はサービスが多数ＳＣＰに分散しているトリガでの多数サービスのための物理ネットワーク・アーキテクチャの実施例を示す。図５は２つのＳＣＰが同時に問い合わせを受けた場合の通信の流れを示す。図６は二つのＳＣＰが順次問い合わせを受けた場合の通信の流れを示す。図７は本発明の好適実施例でアルゴリズムを定義するための共通論理テンプレートを示す。図８は本発明の方法の好適実施例の異なる構成要素の間の全体的関連性を示す。図９は先行関係Ａ＜Ｂのグラフ表現を示す。図１０は先行関係Ｘ＜Ａ＜ＹおよびＸ＜Ｂ＜Ｙのグラフ表現を示す。図１１は先行順序｛ＮＴ＜ＣＳ，ＣＳ＜Ｓ，ＮＴ＜Ｓ｝のグラフ表現を示す。図１２は先行順序｛ＮＴ＜ＣＳ，Ｓ＜ＣＳ，ＮＴ＜Ｓ｝のグラフ表現を示す。図１３は先行順序｛ＮＴ＜ＣＳ，Ｘ＜Ｓ＜Ｙ，Ｘ＜ＣＳ＜Ｙ｝のグラフ表現を示す。図１４は部分的順序ではないグラフを示す。図１５は加入者レコードの好適実施例を示す。図１６は本発明の好適実施例の制御論理を定義するための共通論理テンプレートを示す。詳細な説明本発明の主題は多数ＳＣＰ環境においてサービス・インタラクションによる相互運用性を主題としている。トリガに対する多数ＳＣＰ相互運用の複雑さの問題はＳＣＰの個数（２，または２以上）とサービスの性質（単一分類の拡張機能を含むかまたは多数分類の拡張機能を含むか）による。ＬＥＣおよび／またはその他のサービス・プロバイダが多数ＳＣＰ相互運用環境においてサービス・インタラクションを管理するための制御論理を生成できるようにする方法の各種好適実施例が明示される。第１の好適実施例の方法は（加入者あたり）単一トリガに対して同時にアクセスする２個だけのＳＣＰが存在しておりサービスは単一分類の拡張機能を含む場合に機能する。第２の好適実施例の方法は（加入者あたり）単一トリガに対して同時にアクセスする２個だけのＳＣＰが存在しておりサービスが複数分類の拡張機能を含む場合に機能する。第３の好適実施例の方法は２個または３個以上のＳＣＰがありサービスが単一分類の拡張機能を含む場合に機能する。本発明の詳細な説明を正しく理解するには、各種方法を実現できる物理ネットワーク・アーキテクチャの幾つかの好適実施例にまず焦点を当てるのが有益である。図３は、全部のサービス及び拡張機能インタラクション・マネージャ（ＦＩＭ）が同じＳＣＰに存在する一つのトリガでの多数サービスのための物理ネットワーク・アーキテクチャの好適実施例を示す。トリガ１１６がＳＳＰ１０４に発生すると、物理的にＳＣＰ１０８内に配置されているＦＩＭ３１４へ問い合わせの形で情報が送信される。ＦＩＭ３１４はＳＣＰ１０８に関連した多数のＡＩＮサービス３００，３０２，３０４の各々と相互作用する。データリンク３０６はＳＳＰ１０４からＳＣＰ１０８へ接続する。ＦＩＭ３１４は情報フロー３０８，３１０，３１２経由でＡＩＮサービス３００，３０２，３０４と通信する。図４はサービスが多数ＳＣＰに分散しているトリガについて多数サービスのための物理ネットワーク・アーキテクチャの好適実施例を示す。図３と同様に、ＳＳＰ１０４でトリガ１１６が発生すると、ＭＰ２００に存在するＦＩＭ３１４へ情報が送信される。物理的には情報がＭＰ２００に送信される。論理的にはＭＰ２００内部のＦＩＭ３１４で情報を処理しなければならない。ここで、ＭＰ２００はＳＳＰ１０４と多数のＳＣＰ（即ち、ＳＣＰ４００，ＳＣＰ４０２，ＳＣＰ４０４の各々）との間に配置される独立したネットワーク構成要素である。サービス４０６，４０８，４１０は異なるＳＣＰに分散させることができる。拡張機能インタラクションの管理のためにＭＰ２００を保有する論拠は、既存のＳサービス・プロバイダとＳＣＰに対するインパクトを最小限に押えることである―― ＳＳＰはＭＰの存在のためトリガに遭遇した場合に１つだけのＳＣＰと通信するように振舞うことができ、ＳＣＰはＳＳＰと通信するのと同じ方法でＭＰと相互作用できる。データリンク４１２から４２０はノード間の通信を可能にする。物理ネットワーク・アーキテクチャを図示した図３及び図４は単に各種方法で使用できるアーキテクチャの単なる図示であることは理解されるべきである。たとえば図４においてＭＰは独立したネットワーク構成要素とせずにＳＣＰの一部としたりまたはＳＳＰの一部であっても良いことは当業者には理解されよう。さらに、術語”仲介ポイント”（即ちＭＰ）は単に拡張機能インタラクション・マネージャをサポートするプラットフォームを表わすためだけに用いている。この術語の使用は何らかの他の種類の”仲介アクセス”が存在することを暗示してはいない。術語”ゲートウェイ”もこのプラットフォームを表わすために用いている。利用可能なトリガ本発明の方法の各実施例を発展させるためには、利用可能なトリガの説明が不可欠である。ＳＳＰは幾つかの種類のトリガを呼処理の幾つかのポイントでサポートしているがサービス分類を供給するには限られた個数のトリガしか利用できないため必要になる。多重加入トリガへの同時アクセスができるサードパーティ・サービスはこれらの分類の１つ（または二つ以上）に当てはまる。多重加入トリガは、特定トリガが加入者回線上で遭遇した場合に任意の加入者にサービスを提供する能力を幾つかのＳＣＰが有する場合に発生する。トリガ定義はベルコア社ＡＩＮ０．１一般条件（ＴＲ−ＮＷＴ−００１２８４）に適合する。トリガ１１６は加入者側（即ち加入者に基づく）または局側である。トリガ１１６が加入者側の場合、そのトリガ１１６に加入している設備または設備グループに発呼する呼またはこれに加入するディレクトリ番号／発呼形式（ＤＮ／ＣＴ）に終止する呼だけがそのトリガーに遭遇する。トリガが局側の場合、トリガ基準に適合する全ての呼がトリガに遭遇する。トリガ１１６は呼処理発呼中または呼処理終了中に発生することがある。呼処理発呼中には、以下のＴＤＰのいずれか１つでトリガ１１６が発生する：（ｉ）発呼試行――ＳＳＰ１０４が呼セットアップ要求（たとえばオフフック）を受信した後、（ｉｉ）情報収集――ＳＳＰ１０４が呼を処理するのに充分な情報を有した後、（ｉｉｉ）情報分析――ＳＳＰ１０４が受信した情報を分析した後、（ｉｖ）ネットワーク・ビジー――自動フレキシブル・ルーティング・テーブルに関連する全ての経路が利用できない場合。サードパーティ・サービス・プロバイダによって多重加入されている呼処理中に発呼するトリガは、（ａ）オフフック遅延（ＯＨＤ）、（ｂ）３／６／１０公衆局ダイアリング方式（３／６／１０ＰＯＤＰ）、（ｃ）公衆局ダイアリング方式拡張機能コード（ＰＯＤＰＦＣ）及び（ｄ）Ｎ１１を含む。（ａ）ＯＨＤトリガは受信情報がダイアリング方式を強行に違反する場合に検出されるべきではないことを除き、このトリガがＳＳＰが呼処理に充分な情報を受信した場合に検出される加入者トリガである。ＴＤＰは収集情報である。（ｂ）ＰＯＤＰＦＣトリガに関して、これは加入者トリガでＳＳＰは指定した垂直サービスコード（たとえば＊ＸＸ）がダイアルされた場合に呼のトリガを検出すべきである。ＰＯＤＰはＰＯＤＰＦＣトリガを発生させる垂直サービスコード（たとえば＊ＸＸ）を指定する。ＴＤＰは分析情報である。（ｃ）３／６／１０ＰＯＤＰトリガについて、ＳＳＰは適当な北米ナンバリング方式（ＮＡＮＰ）番号がダイアルされた場合にＰＯＤＰへアクセスする全ての呼について呼のトリガを検出すべきである。３／６／１０ＰＯＤＰトリガは局側であり、トリガ基準は３／６／１０桁パターンで指定される。３／６／１０桁トリガの例はＮＰＡコード、サービス・アクセス・コード（たとえば７００，８００，９００）、ＮＰＡ−ＮＸＸコード、サービス・アクセス・コードＮＸＸコード、ＮＰＡ−ＮＸＸ−ＸＸＸＸコードである。ＴＤＰは分析情報である。（ｄ）Ｎ１１トリガについて、ＳＳＰは指定したＮ１１番号をダイアルした時にＰＯＤＰへアクセスする全ての呼についてＮ１１トリガを検出すべきである。Ｎ１１トリガは局側であり、ＴＤＰは分析情報である。呼処理終了中に発生するトリガは終了試行（ＴＡＴ）（即ち、呼を交換器上のディレクトリ番号で終了すべきであるとＳＳＰが認識した場合）である。これは加入者トリガである終了トリガで、ＳＳＰ１０４は終了試行ＴＤＰに呼が達した場合にこのトリガを検出しＤＮ／ＣＴを終了すべきである。呼は以下の条件に適合するとトリガに遭遇する：（１）呼処理が適当なＴＤＰに達した、（２）トリガが局側またはトリガが加入者側で呼が加入設備から発しているか加入ＤＮ／ＣＴに終了している場合のいずれか、（３）トリガ基準に合致した、（４）トリガがアクティブ（即ち準備完了）。Ｉ．単一分類サービス――２つのＳＣＰフェーズ１――サービス分類第１のフェーズでは、多重加入トリガへの同時アクセスを有するサードパーティ・サービスの種類が幾つかのサービス分類に分類される。上記に列挙した利用可能なトリガに基づいてＳＣＰで提供され加入者が利用できるサービスの種類を５種類に分類することができる：（１）スクリーニング・サービス、（２）ルーティング・サービス、（３）呼ロギング・サービス、（４）データ表示サービス、（５）転送サービスである。さらに、ルーティング・サービスは番号変換サービスと通信業者選択サービスに分類される。ＳＣＰで提供される各サービスは１つまたは２つ以上のこうした分類を含む。ＳＣＰで提供されるサービスがこれらの拡張機能のうちの１つだけを含む場合、これを単一分類サービスと呼ぶ。サービスが１つ以上のこうしたサービスを含む場合には、多数分類サービスと呼ぶ（これはセクションＩＩの主題である）。スクリーニング・サービス：スクリーニング・サービスは発呼トリガまたは終了トリガのどちらかに基づいている。スクリーニング・サービスは着呼または発呼に帰属する幾つかの情報に基づいて発呼または着呼をスクリーニングするサービスである。呼をスクリーンに渡す場合、呼処理は継続できる。スクリーンに失敗した場合、呼は通知のためルーティングされるおよび／または切断される。たとえば、着呼のスクリーニングは発呼番号（即ち電話をかけた側の電話番号）に基づくもので、発呼のスクリーニングは着呼番号（即ち電話が架かって来た側の電話番号）に基づいている。スクリーニング・サービスはこれらの呼に追加桁を入力できる（たとえば個人識別番号（ＰＩＮ））必要がありはじめにスクリーンに失敗した呼は追加情報に基づくスクリーンに渡される。ＰＩＮは加入者が入力した英数字の組み合わせである。ルーティング・サービス：ルーティング・サービスは発呼トリガに基づく。ルーティング・サービスは発呼を別のＤＮまたは代わりの通信業者のどちらかへ引き渡すため転送する。番号変換サービス：番号変換サービスは発呼トリガに基づく。番号変換サービスは発呼を別のＤＮへ引き渡すため転送する。通信業者選択サービス：通信業者選択サービスは発呼トリガに基づく。通信業者選択サービスは発呼を別の通信業者へ引き渡すため転送する。呼ロギング・サービス：呼ロギング・サービスは発呼トリガまたは終了トリガのどちらかに基づく。呼ロギング・サービスはサービスの一部として指定できる基準に基づいて着呼または発呼の記録を保持する。基準は被呼側番号または発呼側番号並びに電話をかけた（受けた）時間をも含む。データ表示サービス：データ表示サービスは終了トリガに基づく。データ表示サービスは着呼について被呼側に情報を表示する。例としては、発呼者ＩＤ（即ち発呼側の電話番号を識別する）や発呼者名通知（発呼側の名前を識別する）が含まれる。転送サービス：転送サービスは終了トリガに基づく。転送サービスは着呼を別のＤＮまたは場所に転送する。無条件転送サービスだけが許容される（即ちビジーまたは応答なしに呼を転送できない）。前述したサードパーティ・サービスの分類は制御アルゴリズムを開発する目的でさらに見直す必要がある。発呼トリガに提供されるサービスと終了トリガに提供されるサービスを区別し、又局側のサービスと加入者側のサービス（即ち特定の加入者回線でアクティブなサービス）とも区別することを設定しなければならない。表１には制御アルゴリズムの開発で重要なサービス分類（トリガ及び許容される応答メッセージと合わせて）を列挙した。応答メッセージのカラムはＡＩＮ環境で代表的な応答メッセージを含みＳＣＰはＭＰからの問い合わせに応答してこれらを代表的に返すはずである。表１に掲載した以外の応答メッセージは例外として処理される。フェーズ２――アルゴリズム開発制御アルゴリズムを生成するための本発明による第１の方法の１つの好適実施例は３つのフェーズを含む：前述したサービス分類、アルゴリズム開発、提供前分析である。第１の方法では２つのＳＣＰだけが単一トリガに同時アクセスを許容される。第１のフェーズで定義したサービス分類を用いて、方法の第２のフェーズでは特定加入者回線でアクティブな単一トリガへ２つのＳＣＰによる同時アクセスがあり得る特定のサービス分類の幾つかの組み合わせについて制御アルゴリズムをどのように定義するかを記述する。これらのアルゴリズムは制御論理を実現し、特定のトリガに遭遇した場合にＳＳＰとこれらのＳＣＰの間のインタラクションを定義するのに必要である。これらのアルゴリズムは同時アクセスをサポートするために配備されなければならない管理能力の基本を形成する。第２フェーズの間に本方法を適用するのに必要な最小量の知識は特定トリガへの同時アクセスができる（何らかの加入者について）サービスの分類を知ることで構成される。これらのサービス分類がなにかによっては、このフェーズの間に指定されるアルゴリズムは関連トリガに遭遇した時点でサービスがどのように相互に動作するかについての追加の加入者独自の情報に依存することもまたはしないこともある。追加加入者情報が必要とされるこれらのアルゴリズムは加入者依存アルゴリズムと呼ばれる。加入者依存は関連トリガに遭遇した時にサービスがどのように動作すべきかについての加入者の予想の知識に左右されることを意味する。しかし、加入者独自の情報がこのフェーズの間に利用できないため、本方法は各種初期設定ルールで実現される加入者予想についての推定に基づく加入者依存アルゴリズムの生成が可能である。アルゴリズムはサービス・プロバイダが同時に問い合わせを受けるかどうか（順序に無関係）、または順次（順序に依存）問い合わせられるべきかの（最小限）決定を提供するのに必要な論理を実現する必要がある。順次問い合わせでは、問い合わせ順序の決定、各ＳＣＰ応答を受信後の仲介動作の決定が必要である。同時問い合わせでは、全ＳＣＰ応答を受信後にＳＳＰへの単一の応答の形成が必要とされる。図５と図６はＳＳＰと、例示の実施例について示した介在ＭＰと、ＳＣＰの間でそれぞれＳＣＰが同時に又順次問い合わせを受けた場合の通信のフローを示す。通信フローは矢印で標識してありイベント番号はイベントが発生する順番を表わす。さらに詳しくは、図５において、イベント１で、ＳＳＰ１０４がトリガ１１６に遭遇し、データリンク５０４上でＭＰ２００へメッセージを送信する。次にイベント２で、ＭＰはＳＣＰ５００及びＳＣＰ５０２へそれぞれデータリンク５０６及び５０８を使用して同時にメッセージを送信する。イベント３では、ＳＣＰ５００がデータリンク５０６を使用してＭＰ２００へ応答を返す。イベント４で、ＳＣＰ５０２はデータリンク５０８を使用してＭＰ２００へ応答を返す。最後に、イベント５で、ＭＰ２００がＳＳＰ１０４への応答を形成して返し、ＳＳＰ１０４が呼をルーティングする。ここで図６を参照すると、ＳＣＰが順次問い合わせを受けた場合の通信フローを示している。イベント１で、ＳＳＰ１０４はトリガ１１６に遭遇しデータリンク６０４経由でＭＰ２００へ問い合わせを送信する。ＭＰ２００は何らかの順番にしたがって一度に１つのＳＣＰに問い合わせを行ない、次のＳＣＰに問い合わせる前に応答を待つ。ＭＰ２００はデータリンク６０６経由でＳＣＰ６００へ送信するメッセージをイベント２で形成する。ＭＰ２００はイベント３でＳＣＰ６００からの応答を待機する。ＭＰ２００はイベント４でデータリンク６０８上の第２のＳＣＰ６０２に問い合わせを行ない、イベント５でＳＣＰ６０２からの応答を待機する。ＭＰ２００はイベント６で呼処理命令に関して返すべき応答を形成する。これ以外に、ＳＣＰ６００から受信した応答に基づいて、ＳＣＰ６０２には問い合わせずＳＳＰ１０４への応答を形成して返す。共通論理テンプレート本方法の第２フェーズの間に指定されたアルゴリズムは共通論理テンプレートに基づいている。この論理テンプレートは各アルゴリズムが内包する一般論理フローを実現する。テンプレートの論理フローにおいて、知識を必要とする（know ledge intensive）タスクとして識別されるポイントがある。複数加入トリガへの同時アクセスできるサービス分類の各々の組み合わせについて本方法はこれらの知識を必要とするタスクがどのように解決されるべきかを指定する。言い換えれば、１つのアルゴリズムを別のアルゴリズムから区別するのはこれらの知識を必要とするタスクの各々が解決される方法である。ここで図７を参照すると、プロバイダが（何らかの加入者の）特定トリガへの同時アクセスできる場合に多数ＳＣＰとの通信を制御するためのアルゴリズムを定義するための基本として供される共通論理テンプレートを図示してある。論理フローは制御アルゴリズムによって実行されるべきタスクに関して、タスク間の関連と合わせて図示してある。アルゴリズムは加入者のトリガへ同時アクセスするサービスの種類に特異的で、ＳＳＰで多重加入トリガに遭遇した場合にＭＰで実行される。論理テンプレートはランタイム時にアルゴリズムによって解決されなければならない各種タスクを指定する。こうしたタスクの幾つかは何らかのサービス特有または加入者特有の知識に依存しないという意味で一般的である。たとえば、テンプレートの決定ポイントの１つは数収集が必要かどうかによる。これを解決するには、ＲesourceＴype パラメータが１にセットされてＳＣＰからＳend_Ｔo_ Ｒesource メッセージを受信したかどうかを決定するアルゴリズムで充分であると仮定する。他のタスクは解決にサービス特有または加入者特有の何らかの情報を必要とする。これらの”知識を必要とする”タスクは図７において番号が付けてあり図面上太線で示してある。これらのタスクの解決には所与のトリガへの同時アクセスができる特定サービスに付いておよび／またはトリガに遭遇した時にサービスの全体的動作に付いての加入者の想定に付いての何らかの情報が必要である。太字で示されている図７の構成要素を参照すると、知識を必要とするタスクは次のように列挙される：１：同時または順次もしくは単一問い合わせの決定２：最初に問い合わせるＳＣＰの決定（順次問い合わせの場合）３：後続の動作の決定（順次問い合わせの場合）４：ＳＳＰへ応答を返す（順次問い合わせの場合）５：ＳＣＰＡからＳＣＰＢへ情報を渡す（順次問い合わせの場合）６：渡すべき情報を決定（順次問い合わせの場合）７：ＳＳＰへの応答の決定（同時問い合わせの場合）これらのタスクの各々については以下のサブセクションで詳細に説明する。タスク１：同時、順次、または単一問い合わせ、及びタスク２：最初のＳＣＰの決定ブロック７００で示してあるＭＰはＳＳＰからの問い合わせメッセージを受け取る。ＳＳＰからの問い合わせメッセージ受信時にＭＰは問い合わせメッセージを発しトリガに遭遇した特定加入者とそのトリガのために同時アクセスできるＳＣＰを識別すると仮定する。次に、決定ブロック７０２で、制御アルゴリズムはＳＣＰに同時、順次問い合せするか、または１つのＳＣＰだけに問い合わせるかを決定しなければならない。順次問い合わせは１つのサービスを呼び出す決定が直前に呼び出したサービスから返された結果に依存する場合、または１つのサービスが別のサービスによって生成された特定の情報に依存する場合に適当である。それ以外では、サービスを同時に問い合わせるのが適当である。さらに、サービスが相互に両立しない場合があり、その時は１つのサービスだけに問い合せする。（何らかの加入者の）特定トリガへ同時にアクセスできる２つのサービスでの問い合せの順序と初期設定ルールが表２に掲載してある。２つのサービスを任意にサービスＡ及びサービスＢと標識した。各々は表１に定義したサービス分類の１つに当てはまるものと仮定する。サービス分類の特定の各々の対について、表２の３列目に掲載した問い合せ順序はＳＣＰが順次問い合せされるべきか、またはＳＣＰが同時に問い合せできるか、または決定が加入者に依存するかを指定する。選択が加入者依存の場合、表２の４列目は追加の加入者情報がない場合の選択肢を指定する際に使用すべき初期設定ルールを提供する。この追加情報は第３フェーズである提供前分析の間に得られるもので、この間に加入者依存アルゴリズムが確認されるかまたはこの情報に基づいて更新される。決定ブロック７０２においてＳＣＰに順次または同時に問い合わせる決定は論理テンプレートのタスク１を満たす。処理ブロック７０４に配置されたタスク２（最初に問い合わせるべきＳＣＰの認識）も表２を参照して解決される。第１のＳＣＰの問い合わせと応答の受信は処理ブロック７０６で発生する。決定ブロック７０８で、数収集が必要かどうか決定する。必要とされる場合、処理ブロック７１０で、Ｓend_Ｔo_Ｒesource パラメータをＳＳＰに返す。次に、数の収集とＳＣＰへの返送がブロック７１２で行なわれる。応答は処理ブロック７１４でＳＣＰから受信する。タスク３：後続動作の決定（順次問い合わせ）幾つかのＳＣＰへの順次問い合わせを行なうべきことを制御アルゴリズムがタスク１で決定した場合、アルゴリズムはタスク３でＳＣＰから応答を受信した後で何を行なうべきか決定しなければならない。この時点で成し得る２つの選択肢がある：別のＳＣＰには問い合せしないがＳＳＰへすぐに応答メッセージを返す（処理ブロック７１８）か、または別のＳＣＰへ問い合せするか（ブロック７２０〜７２４）である。タスク４：ＳＳＰへ応答を返す（順次問い合わせ）図７の論理テンプレートに基づくアルゴリズムがタスク４に達した時点で、１つまたは２つ以上のＳＣＰから応答メッセージを受信しているが、タスク３で後続ＳＣＰは問い合わせるべきでないことが決定されている。タスク５：ＳＣＰＡからＳＣＰＢへ情報を渡すか？決定ブロック７１６において、別のＳＣＰへ問い合わせる決定を行なった場合、決定ブロック７２０でＳＣＰＡからＳＣＰＢへ情報を渡すかどうかを決定しなければならない。タスク６：渡すべき情報の決定情報が渡される場合には、処理ブロック７２２でＳＣＰＡからＳＣＰＢへ渡す情報を決定してから処理ブロック７２４に進み次のＳＣＰへ問い合わせを送信する必要がある。第１のＳＣＰから第２のＳＣＰへ渡される必要のある情報は、代表的には着信番号（ＣａｌｌｅｄＰａｒｔｙＩＤ）、発信番号（ＣａｌｌｉｎｇＰａｒｔｙＩＤ）、一次通信業者（ＰｒｉｍａｒｙＣａｒｒｉｅｒ）パラメータを含む。情報を渡さない場合には処理ブロック７２２をバイパスし、処理ブロック７２４で次のＳＣＰへの問い合わせ送信が行なわれる。この時点で、ブロック７０８から７１８が実行される。タスク７：ＳＳＰへの応答の決定（同時問い合わせ）アルゴリズムが制御論理テンプレートで処理ブロック７２６に遭遇する場合、ＳＣＰは同時に問い合わせられるべきであることが決定されている（タスク１の決定ブロック７０２で）。同時問い合わせは処理ブロック７２６でＳＣＰへ送信される。ＭＰはブロック７２８で複数応答を受信する。処理ブロック７３０で解決すべきタスタは２つのＳＣＰからの応答を組み合わせてＭＰからＳＳＰへの単一の応答メッセージを決定することである。応答はブロック７３２でＳＳＰへ返される。同時問い合わせは以下のサービスの組み合わせに適用できる：１．ＳＣＰＡとＳＣＰＢがどちらもルーティング・サービスを実行する２．ＳＣＰＡとＳＣＰＢがどちらも転送サービスを実行する３．少なくとも一方のＳＣＰがロギング・サービスを実行する４．ＳＣＰＡとＳＣＰＢがどちらもデータ表示サービスを実行する以下のセクションでは上記の組み合わせの各々についてＭＰからＳＳＰへの応答を決定するためのルールを説明する。２つのルーティング・サービス――各々のルーティング・サービスは以下のうちの１つを行なうものと仮定する：別のＤＮへ呼をルーティングする、別の通信業者へ呼を転送制御する、または呼をルーティングしない。表３に示したように６つの場合が考えられる：ケース１では、どちらのＳＣＰも呼を転送しないので、ＭＰはいずれかのＳＣＰから返されたＡnalyze_Ｒoute メッセージで伝送されるのと同じパラメータ値を用いてＳＳＰへＡnalyze_Ｒouteを返すことができる。ケース２では、ＭＰは別の通信業者へ呼をルーティングするＳＣＰから返されたＡnalyze_Ｒoute メッセージに含まれるパラメータ値を用いてＳＳＰへＡnal yze_Ｒouteを返す。ケース３では、呼を別のＤＮへ転送制御するＳＣＰから返されたＡnalyze_Ｒo ute メッセージに含まれる着信番号（ＣａｌｌｅｄＰａｒｔｙＩＤ）の値を用いてＳＳＰへＭＰがＡnalyze_Ｒouteを返す。ケース４では、ＭＰがＳＳＰへＡnalyze_Ｒouteを返す。しかし両方のＳＣＰが別の通信業者へ呼をルーティングしようと試みているため、呼はそれらのうちの一方だけにしかルーティングできない。代替通信業者を選択する基準は任意である。しかし、１つのオプションは一番新しい加入者からルーティング・サービスによって返されたＡnalyze_Ｒoute メッセージに含まれる適当なパラメータによって指定された通信業者へ呼を転送することである。ケース５では、別の通信業者へ呼をルーティングしようと試みているＳＣＰによって返された通信業者選択パラメータの値を用い、また別のＤＮへ呼を転送しようと試みているＳＣＰによって指定された着信番号（ＣａｌｌｅｄＰａｒｔｙＩＤ）の値を用いてＭＰがＳＳＰへＡnalyze_Ｒouteを返す。ケース６では、ＭＰがＳＳＰへＡnalyze_Ｒouteを返す。しかし、両方のＳＣＰが別のＤＮへ呼をルーティングしようと試みているので、呼はそれらのうちの１つにしか転送できない。新規着信番号（ＣａｌｌｅｄＰａｒｔｙＩＤ）の選択の基準は任意である。しかし、１つのオプションは一番新しい加入者からルーティング・サービスによって返されたＡnalyze_Ｒouteメッセージに含まれる着信番号（ＣａｌｌｅｄＰａｒｔｙＩＤ）パラメータへ呼をルーティングすることである。２つの転送サービス――２つの転送サービスがアクティブになっている加入者回線でＴermination_Ａttempt トリガに遭遇した場合、呼を転送しようと試みる転送サービスは着信番号（ＣａｌｌｅｄＰａｒｔｙＩＤ）に新しい値を有するＦorward_Ｃall をＭＰへ返し、呼を転送しようと試みていない転送サービスはＡuthorize_Ｔermination を返す。表４に示したように４つのケースが考えられる：ケース１では、両方のＳＣＰが呼を転送しようと試みないので、ＭＰはＳＳＰにＡuthorize_Ｔerminationを返す。ケース２では、適当なＳＣＰから返されたＦorward_Ｃallメッセージに含まれるパラメータ値を用いてＭＰがＳＳＰへＦorward_Ｃallを返す。ケース３では、両方のＳＣＰが呼を転送しようと試みているので、呼はそれらの一方によってだけ転送され得る。ＳＣＰから受信した２つのＦorward_Ｃallメッセージの一方だけに含まれる着信番号（ＣａｌｌｅｄＰａｒｔｙＩＤ）の値を用いてＭＰがＳＳＰへＦorward_Ｃallを返す。新規の着信番号（ＣａｌｌｅｄＰａｒｔｙＩＤ）を選択する基準は任意である。しかし、１つのオプションは一番新しい加入者からルーティング・サービスによって返された着信番号（ＣａｌｌｅｄＰａｒｔｙＩＤ）へ呼を転送することである。少なくとも一つのロギング・サービス――少なくとも一つのロギング・サービスが存在する場合、呼ロギング機能を実行しないサービスから受信した応答メッセージをＳＳＰへ返す。両方のＳＣＰがロギング・サービスを提供している場合、いずれか一方から受信した応答メッセージを返す。２つのデータ表示サービス――２つのデータ表示サービスが同時に問い合わせられた場合にＭＰからＳＳＰへの単一の応答メッセージを決定するルールを使用する。どのパラメータ値を返すか決定する際に使用する１つの考えられる基準は、２つのＳＣＰが同じパラメータにことなる値を返す場合に、最近加入したサービスを有するＳＣＰによって返された値を使用することである。フェーズ３――提供前分析単一分類のサービスを２つのＳＣＰが有する際の本方法の第３フェーズは提供前分析フェーズと呼ばれる。このフェーズは（何らかの特定の加入者について）ＭＰに制御アルゴリズムを実際に配備する前に行なわれるのが普通である。このフェーズは加入者依存アルゴリズムを更新して追加の加入者特有情報を考慮するのにだけ必要とされる。このフェーズの目的は加入者依存アルゴリズムに含まれる知識を必要とするタスクの幾つかを解決するのに必要とされる加入者特有の情報を入手することである。前述のように、加入者依存はサードパーティ・サービスのこの対の顧客である加入者が多数加入したトリガに遭遇した場合にどのようにサービスが一緒に機能することを想定しているかに大きく依存する。言い換えれば、加入者依存アルゴリズムは加入者の想定についての知識に依存して正しく機能する。いずれにしても、この知識が利用できない場合、第２フェーズでの本方法はサービスの対が機能することを加入者がどのように望んでいるかについての仮定を実現する初期設定ルールを提供する。しかしこれは実際に加入者が何を望むかであるかもしれないしまたそうではないかもしれない。結果的に、提供前分析は加入者依存アルゴリズムに推奨される。こうすることにより、制御論理の配置前に特定の加入者について初期設定ルールを確認するかまたは置き換えることができる。表２（問い合わせ選択ルール）はいつ初期設定ルールが必要になるかを表わしている。問い合わせ順序が加入者依存の場合、初期設定ルールは最も考えられる問い合わせ順序（即ち最も考えられる加入者の想定を反映する順序）を指定する。しかし、各々の加入者依存アルゴリズムについて、問い合わせ順序に対する（多くとも）他に１つだけ妥当な代替ルールが存在する。つまり、加入者依存アルゴリズムを変更して追加の加入者情報を反映させるのは問い合わせ順序について初期設定ルールまたは代替ルールのどちらかを選択するのと等価である。提供前分析の間、多重加入トリガでアクティブな特定のサードパーティ・サービスの対について、対応するアルゴリズムが表５を用いる加入者非依存か、または表６を用いる加入者依存かいなかを決定する。アルゴリズムが加入者依存であれば、アルゴリズムのこれ以上の変更は必要ない。アルゴリズムが加入者非依存であれば、サービスについての加入者の想定を取得して問い合わせ順序を決定するための初期設定ルールまたは代替ルールのどちらかの選択ができる。初期設定ルールが選択された場合、その加入者トリガについての制御論理の基盤として既存のアルゴリズムを使用する。代替ルールを選択した場合、問い合わせ順序が代替ルールに基づくようにアルゴリズムを変更する。サービスが相互にどのように機能すべきかについての加入者の想定を取得するため、加入者に質問を尋ねる。表７は加入者からこの情報を収集する助けになる質問のサンプル・リストである。ＩＩ．多数分類サービス−２つのＳＣＰフェーズ１――サービス分類本発明の方法の第２に図示した実施例はＳＣＰが多数分類のサービスを提供する場合を包含している。本方法の第１フェーズはサービス分類である。すでに開発したサービス分類手法が与えられているので、想定される１０個の多数分類サービスのセットについて記載する。これらのサービス分類は次のように定義できる：１．スクリーニング＋ロギング・サービス：これはスクリーニングに成功／失敗の呼のロギングもするスクリーニング・サービスである。２．ルーティング＋ロギング・サービス：これはルーティングされた呼のロギングを行なうルーティング・サービスである。３．スクリーニング＋ルーティング・サービス：このサービスはスクリーニング機能とルーティング機能の両方を実行する。この種のサービスでは３種類の結果が考えられる、即ち、呼が再ルーティングされ、着信番号（ＣａｌｌｅｄＰａｒｔｙＩＤ）および／または一次通信業者（ＰｒｉｍａｒｙＣａｒｒｉｅｒ）パラメータの値を変更してサービスがＡnalyze_Ｒouteを返したか、サービスによって呼ルーティングが変更されなかったか、呼が切断されたかである。呼ルーティングがサービスによって変更されない場合、サービスはＡnalyze_Ｒouteを返し、着信番号（ＣａｌｌｅｄＰａｒｔｙＩＤ）または一次通信業者（ＰｒｉｍａｒｙＣａｒｒｉｅｒ）パラメータ値には変化がない。呼が切断された場合、サービスはＤisconnect フラグをセットしてＳend_Ｔo_Ｒesource を返すか、またはＤisconnectを返す。この種のサービスで考えられる１つの解釈は、どのトリガにこれが提供されるかによって変化する。たとえば、サービスが加入者トリガたとえばＯＨＤなどに提供されてスクリーニングに失敗する場合、呼はルーティングされないが、接続完了することはできる（もともとダイアルした被呼番号へ）。つまり、サービスはＳＣＰへ送信されたＩnfo_Ｃollectedメッセージにもともと伝送されていた着信番号（ＣａｌｌｅｄＰａｒｔｙＩＤ）と一次通信業者（ＰｒｉｍａｒｙＣａｒｒｉｅｒ）パラメータを含むＡnalyze_ＲouteをＭＰへ返すことができる。一方で、スクリーニング＋ルーティング・サービスが局側トリガたとえば３／６／１０ＰＯＤＰに提供される場合、もともとダイアルした数は局側トリガがアクティブになっているＳＳＰへ呼をルーティングする。そのポイントで、ダイアル番号は意図した宛先へ呼を接続完了できるようにするため変換されなければならない。サービスのスクリーニング部分に失敗する場合、サービスのルーティング部分は実行されない。その場合、呼は接続できず、切断される。これが起こる場合、サービスは（Ｄisconnectパラメータをセットして）Ｓend_Ｔo_Ｒesource 、Ｄisconnect、またはＣontinueを返す。４．スクリーニング＋ルーティング＋ロギング・サービス：このサービスはスクリーニング＋ルーティング・サービスと同様に実行するが、何らかの指定された基準を満たす呼を全部ロギングする。５．スクリーニング＋データ表示サービス：このサービスはスクリーニングサービスと同様である。到着する呼がスクリーニングを成功する場合、呼は終了し、呼についての情報が表示される。到着する呼がスクリーニングに失敗した場合には排除される。６．スクリーニング＋転送サービス：このサービスはスクリーニング機能と転送機能の両方を実行する。この種のサービスによる結果は代表的には３種類考えられる：ａ）着呼は被呼側回線で通常に終了する。スクリーニング＋転送サービスはＡuthorize_Ｔerminationを返す。ｂ）着呼は被呼側に接続完了しないが、切断される。サービスはＳend_Ｔo_Ｒesource（ＤisconnectＦlagパラメータをセットして）またはＤisconnectのどちらかを返す。ｃ）着呼が転送される。サービスはＦorward_Ｃallを返す。７．ロギング＋データ表示サービス：このサービスは全ての着呼をロギングし、また呼についてのデータを表示する。８．ロギング＋転送サービス：このサービスは呼を転送し転送した呼もロギングする。９．スクリーニング＋ロギング＋データ表示サービス：このサービスはスクリーニング＋データ表示サービスと同様に実行し、着呼がロギングされる追加の機能を有する。１０．スクリーニング＋ロギング＋転送サービス：このサービスはスクリーニング＋転送サービスと同様に実行し、着呼が何らかの指定した基準にしたがってロギングされる追加機能も有する。フェーズ２――アルゴリズム開発本方法の第２のフェーズはアルゴリズムの開発である。図７の同じ論理テンプレートをこの代表的実施例に使用する。このセクションの残りの部分はこれらの多数分類サービスを処理するように前セクションで説明した知識を必要とするタスクがどのようにすれば拡張できるかの説明にまわす。タスク１：同時、順次、または単一問い合わせ、及びタスク２：第１のＳＣＰの決定多数分類サービスが加入者にアクセスできる場合にこれら２つの知識を必要とするタスクを解決するには、主サービス分類の概念を定義する。主サービス分類は問い合わせ順序を決定する場合に多数分類サービスの動作を支配する単一サービス分類である。すでに定義した多数分類サービスの主サービス分類を表８の２列目に示す主サービス分類の標記で、知識を必要とするタスク１と２での単一分類サービスについての方法に適用したのと同じルールを多数分類サービスの方法にも同様に適用できる。ＳＣＰの一方または両方が多数分類サービスを含む場合に問い合わせ順序を決定するには、第１に表８を用いて多数分類サービスの主サービス分類を決定する。次に表２を用いて適当な問い合わせ選択ルールを決定する。たとえば、スクリーニング・サービスとスクリーニング＋ルーティング・サービスで処理する場合、表２のスクリーニング対ルーティングルールを適用して２つのＳＣＰに順次問い合わせるべきであり、スクリーニング・サービスに先に問い合わせるべきであると決定する。この問い合わせ順序は、単一分類スクリーニング・サービス及びルーティング・サービスの場合と同様に、加入者依存である。タスク３：後続の動作を決定（順次問い合わせ）単一分類または複数分類どちらかのサービスがＳＣＰに配備されるとき、順次問い合わせがタスク１で決定されＳＣＰからの応答をＭＰで受信直後の場合に取るべき後続の動作をルールが指定する。タスク４：ＳＳＰへ応答を返す（順次問い合わせ）単一分類サービスの方法についてこのタスクの解決で得られた結果を用いて、単一分類または複数分類サービスがＳＣＰに常駐する時にＳＳＰへＭＰが返す応答メッセージをルールが指定する。タスク５：ＳＣＰＡからＳＣＰＢへ情報を渡すかサービスによって実行される機能が主サービス分類と等価であると仮定した場合に単一分類サービスについての一般的ルールが複数分類サービスへも適用される。タスク６：渡すべき情報の決定渡される必要のある情報は単一分類サービスのそれと正確に同じであり、即ち第１のＳＣＰから第２のＳＣＰへ着信番号（ＣａｌｌｅｄＰａｒｔｙＩＤ）、発信番号（ＣａｌｌｉｎｇＰａｒｔｙＩＤ）、一次通信業者（ＰｒｉｍａｒｙＣａｒｒｉｅｒ）パラメータを渡す。タスク７：ＳＳＰへの応答の決定（同時問い合わせ）単一分類サービスについて開発したルールは各々の複数分類サービスによって実行される機能が主分類と等価であると仮定した場合にも適用される。同時問い合わせは以下のサービスの組み合わせに適用できる。１．ＳＣＰＡとＳＣＰＢが両方ともルーティング機能を実行する２．ＳＣＰＡとＳＣＰＢが両方とも転送機能を実行する３．少なくとも一方のＳＣＰがロギング機能を実行する４．ＳＣＰＡとＳＣＰＢが両方ともデータ表示機能を実行する前述した単一サービス分類で適用されたのと同じ規則が適用される。フェーズ３――提供前分析本方法の第３のフェーズは提供前分析である。単一分類サービスでの方法で説明したのと同じ提供前分析を使用できる。前述した表７は単純に表８の主分類として各サービスを取り扱うことにより複数分類サービスに適用できる。単一分類サービスについての方法と複数分類サービスについての方法に関して最終的な注意点。ＭＰはＳＳＰからの問い合わせメッセージ受信時にある程度の量の処理を実行し、この処理結果が配備される制御アルゴリズムへの入力として利用できるものと仮定した。これらの結果は遭遇したトリガと受信した問い合わせメッセージの識別、遭遇したトリガに関係する加入者の識別、トリガに遭遇した時点で加入者にサービスを提供できるサービス・プロバイダの識別を含む。したがって、本方法はこの情報を決定するための手順を含まない。ＩＩＩ．単一分類サービスを有する複数ＳＣＰ本発明の方法の第３の例示的好適実施例は各々のＳＣＰが単一サービス分類をサポートする多数のＳＣＰを取り扱う。本方法はトリガに対する加入サービスのセットの制御論理を生成するために使用できる。この制御論理は、加入者各々が異なるサービスのセットを選択することがあるため、または同じサービスのセットだがサービスの動作に関して異なった想定をしていることから、加入者毎に用意される。本方法は４つのことがらを包含している制御論理のアイデアに基づいている。即ち（１）ＳＣＰに存在するサービス分類、（２）これらのサービスが協調動作すべき方法、（３）ＳＣＰが問い合わせを受ける方法、（４）所与の問い合わせ順位が所与のサービス動作を発生するように行なわれるべき処理タスクを指定する論理テンプレート、である。図８は本方法の異なる構成要素間の全体的関連性を示す。処理ブロック８０２の動作オプションと問い合わせオプションはトリガに遭遇した時に呼び出される処理ブロック８００に存在するサービス分類に依存する。これらの動作オプションと問い合わせオプションはＭＰへアクセス可能な加入者レコード８０４内部に実装される。トリガに遭遇しＳＳＰが問い合わせメッセージをＭＰへ送信した時、ＭＰは加入者レコード８０４を取り出してどのようにサービスが協調動作するか、又どのような方法でＳＣＰに問い合わせるべきかを決定する。この情報は論理テンプレート及び関連タスク・ルールと合わせて、サービスが希望どおりに動作するようにＭＰ、各種ＳＣＰ、ＳＳＰの間のインタラクションを指定するために必要とされる全てである（考えられる例外として所与の場合に追加の衝突解決基準がある）。論理実行エンジンと標識してある図８の処理ボックス８０６は論理テンプレートとタスク・ルールを実現し、加入者レコード８０４の情報と合わせて制御論理と呼ばれる。フェーズ１――トリガとサービス分類本方法の第１のフェーズは多重加入することのあるトリガと、これらのトリガへ同時にアクセスできるＳＣＰに存在するサービス分類を識別することである。前述した方法と同じトリガを使用できる。各ＳＣＰに存在するサービスはこれらのトリガによって呼び出されサービス分類の共通セットに属するものと仮定される。利用可能なトリガに基づいて、ＳＣＰで提供可能で加入者が利用できるサービスの種類が６種類に分類できる。すなわち、スクリーニング・サービス、番号変換サービス、通信業者選択サービス、呼ロギング・サービス、データ表示サービス、転送サービスである。サービス分類はすでに説明した。トリガとサービス分類には関連がある。表９はトリガの各々とそのトリガで呼び出されるサービスの対応する分類とを関連付けたものである。表にはトリガに遭遇したＴＤＰ、ＳＣＰが関連した問い合わせメッセージに応答して返すと予想されるメッセージも含まれている。表９に示したように、各サービス分類はトリガの幾つか（必ずしも全部ではない）に関連している。たとえば、番号変換サービスはＯＨＤ、ＰＯＤＰＦＣ、３／６／１０ＰＯＤＰ、Ｎ１１トリガだけに関連し、転送サービスはＴＡＴトリガにだけ関連する。＋Ｃontinue メッセージは情報分析ＴＤＰに関連するトリガでのみ有効なことに注意するフェーズ２――提供前分析提供前分析は本方法の核心を含み、制御論理を実際にＭＰに実装し得る前に実行されなければならない。提供前分析はトリガへ同時にアクセスできる同じセットのサービス分類に対して動作及び問い合わせオプションのセットをどのように生成するかを記述する（ＳＣＰあたり１つのサービス分類）。これらの動作及び問い合わせオプションが定義されると、選択メカニズムを用いて特定の動作及び問い合わせオプションの選択ができる。動作オプションを生成する方法提供前分析の第１のフェーズは動作オプションの生成である。同じトリガで動作する幾つかのサービス分類のセットについての制御論理を指定するためには、動作オプションを選択しなければならない。一般に、動作オプションはセットの各サービスの対の間の動作的関連によって定義される。動作オプションの複雑さはＳＣＰの個数が増加するにつれて一般に増大する。動作オプションは関連トリガに遭遇した時に加入者に分かるように異なるＳＣＰで動作するサービスの連係動作を表わす。たとえば、１つのＳＣＰで動作するスクリーニング・サービスは別のＳＣＰで動作する番号変換サービスによって生成されたＤＮに基づいて発呼をスクリーニングするか、これ以外ではダイアルした情報だけを用いてこをスクリーニングできる。スクリーニングを成功する呼は番号変換サービスによって生成された情報を用いて再ルーティングされる。任意のサービス分類のセットについて候補動作オプションを生成するための方法を以下に示す。候補動作オプションの生成動作オプションのセットの決定は幾つかのトリガへ同時アクセスできるであろうＳＣＰの個数を指定し、次に各ＳＣＰに存在するサービス分類を識別することから開始する。所与のセットのサービス分類について、サービス分類の考えられる全ての対を列挙する。こうした各対について、１つまたは２つ以上の動作関係を対の構成要素の間で定義する。各動作関係は２つのサービス分類が互いの動作に影響を与えるような１つの考えられる方法を表わす。一般に、サービス分類の各対の間で定義できる動作関係はサービス分類それ自体の定義に依存する。動作オプションは同じトリガによってサービスを一緒に呼び出した場合にサービスで観察される動作を表わす。したがって、動作オプションはセットを構成するサービス分類の各対について動作関係の特定のセットから構成される。所与のサービス分類のセットについて候補となる動作オプションはサービス分類の全ての対についての動作関係の全ての考えられる組み合わせを形成することによって構成される。候補動作オプションの総数は全ての対にわたる動作関係の考えられる組み合わせの総数に等しいことになる。たとえば、３つのＳＣＰと３つの異なるサービス分類Ａ，Ｂ，Ｃについて、ＡとＢの間には１種類の動作関係が考えられ、ＢとＣの間には２種類の動作関係が考えられ、ＡとＣの間には３種類の動作関係が考えられるとすると、１×２×３＝６種類の動作オプション候補が存在することになる。対の間の動作関係の決定トリガへ同時にアクセスできることなるＳＣＰに常駐するサービス分類の各対について、以下の動作関係を定義する：標記：意味Ａ→Ｂ：Ｂの動作はＡによって生成された情報に依存するＡ｜Ｂ：ＡとＢは独立して動作し互いの動作には影響し合わないＡ！Ｂ：Ａは呼を切断することでＢを無効にするＡ＃Ｂ：ＡはＢと相互に両立しない（即ち、ＡとＢは相互に排他的な方法で呼処理に影響を与えようとしている）同じトリガに共存できるサービス分類の各対について、表１０は考えられる動作関係を示す。候補となる動作オプションのセットが与えられると、幾つかはサービス分類の幾つかの対の間で循環動作依存のために両立しない動作を表わす。どの候補動作オプションが矛盾するかの識別は関連する問い合わせ順序の決定で検出される。 ”相互に両立しない”動作関係がサービス分類の対の間に存在することも考えられる。その場合、２つのサービスは呼処理に一緒に影響を与えることができない。相互に両立しないサービスが異なるＳＣＰに存在する場合、問い合わせ順序決定に進む前に衝突を解決することが示差される。実質的な結果は相互に両立しないサービスを含むＳＣＰの１つがこれ以上の考察から除外されることになる、即ちアクティブなＳＣＰの個数が１だけ減少し相互に両立しないサービスが新しいセットには存在しないようになる。これは衝突解決基準の議論の間にさらに説明する。動作オプションの例動作オプションを構成する方法が例を提供することで図示してある。本実施例では、３つのＳＣＰが次のようなサービス分類を含む例についての候補動作オプションを生成する：スクリーニング、番号変換、通信業者選択。第１に、このセットの３つのうちのサービス分類の全ての対となる組み合わせを生成し、各々の対に全ての考えられる動作関係を（上記の表から）関連付ける。結果が表１１に示してある。サービス分類の各々の対について動作関係の全ての組み合わせを作成すると、９種類の考えられる動作オプションがありこれを表１２に示す。大括弧内に動作関係の各々を列挙することにより各動作オプションを書き込む。たとえば、動作オプション４は｛ＮＴ→ＣＳ，Ｓ！ＮＴ，Ｓ！ＣＳ｝として書き込む。問い合わせオプションを生成する方法同一トリガについてアクティブなサービス分類の所与のセットで潜在的な動作オプションのセットをどのように生成するかはすでに説明した。これらは、サービス分類の各対の間での動作関係のため、全体的な結果がサービス間の相反する動作となる可能性があるため”潜在的な（potential）”動作オプションである。本方法の次のステップで、相反する動作を有するこれらの潜在的な動作オプションの識別と破棄を行なう。これを行なってしまうと、ＩＴは１つまたは２つ以上の問い合わせ順序が残りの”真の”動作オプションについて存在することを保証できる。相反する動作オプションを識別する方法は残りの動作オプションについての問い合わせオプションの生成にも直接つながることが分かる。提供前分析の次のフェーズは所与の動作オプションについて問い合わせオプションを生成することである。問い合わせオプションは各種ＳＣＰがどのように問い合わせられるかについての決定を参照する。問い合わせオプションは特定の動作オプションに関連する。各々の選択した動作オプションについて、１つ以上の問い合わせオプションが存在し得る。一般に、２つのＳＣＰが存在する場合、問い合わせオプションは２つの代替案に限定される：同時または順次問い合わせである。動作オプションと同様、問い合わせオプションはＳＣＰ数が増加する程複雑になる。たとえば、３つのＳＣＰ、Ｘ、Ｙ、Ｚがあり、選択した特定の動作オプションはＹでのサービスがＸでのサービスによって作成される情報に依存することを必要とすると仮定する。１つの問い合わせオプションとしてはＸに最初に問い合わせ、応答を待ってからＹとＺに同時に問い合わせる（Ｘの出力をＹだけに入力する）。別の問い合わせオプションとしてはＸとＺに同時に問い合わせてから、Ｘによって生成された情報を用いてＹに問い合わせる。さらに別の問い合わせオプションとしては順番に３つのＳＣＰ全部に問い合わせる：最初にＸ、次にＹ、最後にＺ。３つのオプション全てが同じ全体的なサービス動作を発生するが、オプション間の差はＭＰで問い合わせ及び応答を管理するのに必要とされる処理オーバヘッドの量に反映される。言い換えれば、所与の動作オプションとこれに関連した問い合わせオプションを合わせて制御論理を指定する。この処理の第１のステップは潜在的な動作オプションを作る各々の動作関係を１つまたは２つ以上の先行関係に変換することである。各々の先行関係は特定の順序を指定し、サービス分類の各対に関連する２つのＳＣＰが問い合わせを行ないサービス間の動作関係の対を維持できる。何らかの潜在的動作オプションが相互に両立しない動作関係を含む場合、この動作オプションを変更して相互に両立しないサービス分類の１つを排除するようにする。これは衝突解決基準フェーズの間に行なわれる。ここでは相互に両立しない衝突が解決される（たとえば一方だけを選択して問い合せし他方は無視することによって）まで問い合せオプションを生成できないものと仮定しておく。さらに、動作関係が独立している場合、対応する先行関係が存在しないが、これはＳＣＰがあらゆる順序で問い合せされ得るためである。したがって先行関係は残りの２つの動作関係について指定するだけで良い。これら２つの動作関係についての先行関係は表１３に定義する：先行関係Ａ＜Ｂは”ＡがＢに先行する”と解釈される。即ち、ＳＣＰＡはＳＣＰＢより先に問い合せを受ける。これが図９にグラフ的に示してある。ノード９００（Ａを含む）はノード９０２（Ｂを含む）へ単方向リンク９０４で接続されている。先行関係”Ｘ＜Ａ＜ＹおよびＸ＜Ｂ＜Ｙ”は”ＡとＢが同時に問い合せされる ”と解釈される。ダミー変数のＸとＹは呼処理のポイントを表わすと解釈できる。これが図１０に図示してある。ノード１０００（Ｘを含む）はノード１００２（Ａを含む）とノード１００４（Ｂを含む）へ各々単方向リンク１００６と１００８によって接続される。ノード１００２とノード１００４は各々がノード１０１０（Ｙを含む）へ単方向リンク１０１２と１０１４で各々接続する。上記の表１３に示したように、動作関係Ａ！Ｂについて２つの考えられる先行関係が存在する。直感的に分かるように、ＡがＢを無効にできる場合、Ａはスクリーニングサービスでなければならず、ＡがＢを２種類の方法で無効にできることを意味している。１つの方法として、Ａは最初に問い合せされる（Ａ＜Ｂ）。スクリーニングに失敗した場合、呼が終了するが、スクリーニングに成功した場合、Ｂが次に問い合せされる。これが先行関係Ａ＜Ｂで表わされる。これの変わりとして、ＡとＢを同時に問い合わせることができる（Ｘ＜Ａ＜ＹおよびＸ＜Ｂ＜Ｙ）。ＡとＢの両方から応答を受信してから、応答を比較しなければならない。Ａでのスクリーニング・サービスに失敗した場合、制御論理はＳＳＰへ”失敗 ”を返す。スクリーニングに成功した場合、Ｂから受信した応答は呼処理に影響し得る。したがって、ダミー変数Ｘは同時問い合わせの直前の制御論理でのポイントを表わし、一方でダミー変数Ｙは応答をＡとＢから受信した後の制御論理でのポイントを表わしている。これらの先行関係を各々の潜在的な動作オプションについて定義すると、潜在的な動作オプションはサービス分類間の先行関係として図的に表現することができる。先行関係を用いて動作オプションを表現する例先行関係を用いて動作オプションを表わす２つの例を以下に挙げる。一例として、（ＮＴ→Ｓ，ＣＳ→Ｓ，ＮＴ→ＣＳ）として表現される動作オプションを考える。これは先行順序｛ＮＴ→ＣＳ，ＣＳ＜Ｓ，ＮＴ＜Ｓ｝に対応するもので図１１に図示してある。ノード１１００（ＮＴを含む）はノード１１０２に配置されたＣＳへ単方向リンク１１０４経由で接続する。ノード１１００もノード１１０６（Ｓを含む）へ単方向リンク１１０８経由で接続する。ノード１１０２（ＣＳを含む）はノード１１０６（Ｓを含む）へも単方向リンク１１１０経由で接続する。さらに複雑な例では、番号変換（ＮＴ）、通信業者選択（ＣＳ）、スクリーニング（Ｓ）サービス分類が同一トリガでアクティブになっている。動作オプション｛ＮＴ→ＣＳ，Ｓ！ＣＳ，ＮＴ→Ｓ｝を考えてみる。つまり通信業者選択サービスの動作は番号変換サービスの動作に依存し、スクリーニングサービスはスクリーニングに失敗した場合に通信業者選択サービスを無効にできる（又通話を終了させる）。この動作オプションで定義された３つの動作関係に対応する先行関係はＮＴ＜ＣＳ；ＮＴ＜Ｓ；Ｓ＜ＣＳまたはＸ＜Ｓ＜ＹおよびＸ＜ＣＳ＜Ｙである。動作オプションＳ！ＣＳを表現するのに２つの方法があるため、２つの先行順序がこの特定の動作オプションを表現するために必要とされる：｛ＮＴ＜ＣＳ，Ｓ＜ＣＳ，ＮＴ＜Ｓ｝及び｛ＮＴ＜ＣＳ，ＮＴ＜Ｓ，Ｘ＜Ｓ＜Ｙ，Ｘ＜ＣＳ＜Ｙ｝である。これら２つの先行順序は図１２と図１３に図示できる。図１２を参照すると、ノード１２００（ＮＴを含む）はノード１２０２（ＣＳを含む）へ単方向リンク１２０４経由で接続する。ノード１２０６（Ｓを含む）はノード１２０２（ＣＳを含む）へ単方向リンク１２０８経由で接続する。ノード１２００（ＮＴを含む）はノード１２０６（Ｓを含む）へ単方向リンク１２１０経由で接続する。図１３を参照すると、ノード１３００（ＮＴを含む）はノード１３０２（Ｘを含む）へ単方向リンク１３０４経由で接続する。ノード１３０２（Ｘを含む）はノード１３０６（Ｓを含む）へ単方向リンク１３０８経由で接続しノード１３１０（ＣＳを含む）へもリンク１３１２経由で接続する。ノード１３０６と１３１０はノード１３１４（Ｙを含む）へリンク１３１６と１３１８で各々接続する。図１３において、ＮＴとＣＳの間の先行順序がＮＴ＜ＣＳでありＮＴとＸの間で先行順序が上記で定義されていないにもかかわらず、ＮＴは直接ＣＳに先行するのではなくＸに先行するように図示してある。これは、ダミー変数ＸをＳまたはＣＳどちらかへの”入口”として解釈すべきであり、ダミー変数ＹをＳまたはＣＳどちらかからの”出口”として解釈すべきであることが理由である。つまり、たとえば、他の何らかのサービスＺについて追加の先行関係Ｓ＜Ｚがある場合、矢印はＹからＺへ引かれることになり、ＳからＺへではない。先行関係を図示したら、次のステップは潜在的な動作オプションについての先行関係が部分的順序を形成するかどうか決定することである。部分的順序を形成する場合、潜在的動作オプションは有効（即ち矛盾がない）であるから１つまたは２つ以上の問い合わせオプションが存在する。部分的順序を形成しない場合、潜在的動作オプションは有効ではない。問い合わせオプションまたは制御論理は存在しないことになる。形式的表現によると、セットＳの部分的順序がセットのオブジェクト間の関連性であり、記号”＜（先行）”で標記でき、Ｓについてオブジェクトｘ、ｙ、ｚの次のような属性を満たす。ｘ＜ｙかつｙ＜ｚなら、ｘ＜ｚ（推移）ｘ＜ｙならｙ＼＜ｘ（非対称）ｘ＼＜ｘ（非反射）（記号＼＜は”先行しない”を意味する）しかし先行関係間の部分的順序が純粋にグラフィカルなアプローチによって存在し得るかどうか決定できる。それには、潜在的動作オプションを表わす先行関係に対応するグラフを観察し、方向性サイクル（即ち同じ方向の矢印で閉じたループ）が存在するかを調べる。方向性サイクルが見付かった場合、部分的順序は存在しない。方向性サイクルが存在しない場合、先行関係は部分的順序を形成する。部分的順序が存在する場合、潜在的動作オプションは矛盾を含まず、したがって１つまたは２つ以上の問い合わせオプションが見付けられる。部分的オプションが存在しない場合、潜在的動作オプションは無効である。たとえば、図１４は部分的順序ではないグラフである。本グラフにおいて、２つの方向性サイクルが存在する：ａからｂからｄからａ、及びａからｃからｄからａである。ノード１４００（ａを含む）はノード１４０２（ｂを含む）へ単方向リンク１４０４経由で接続し、又１４０６（ｃを含む）へ単方向リンク１４０８経由で接続する。両方のノード１４０２と１４０６は各々単方向リンク１４１２と１４１４経由でノード１４１０へ（ｄを含む）接続する。ノード１４１０も単方向リンク１４１６経由でノード１４００へ接続する。このルールを用いると、図１１に図示した潜在的動作オプションは部分的順序を形成するので、１つまたは２つ以上の問い合わせオプションを有する。同様に、図１２と図１３に図示した潜在的動作オプションもノードのどれにも方向性サイクルが存在しないことから、真の動作オプションである。この例では、動作関係Ｓ！ＣＳが２つの先行関係によって表現できるため、両方のグラフを方向性サイクルについて調べなければならない。次のステップはこの結果を用いて問い合わせオプションを実際に生成する。問い合わせオプションの生成動作オプションを方向性グラフの形で表現してみて方向性サイクルが見つからなかったら、問い合わせオプションの生成は簡単である。表１４を用いて次の手順にしたがって問い合わせオプションを生成する。１．各々の動作オプションに対応する方向性グラフを観察することから始めて先行のないノードを識別する。つまり、どのノードが（即ちサービス分類が）着信する矢印を有していないかを決定する。これらのサービス分類を”反復１”の下に列挙する。２．直前のステップで識別したこれらのノードに×印を付け、これらのノードから放射する矢印も全部×印を付ける。着信する矢印を有していないノードの新しいセットが出来上がる。３．先行のないノードの新しいセットを反復２として表に列挙することで手順を反復する。これらのノードとそこから放射する矢印にも×印を付ける。４．グラフの全ノードが排除されるまでこの手順を繰り返す。この手順が完了したら、表はノード全部を排除するのに必要とされるだけの反復でサービス分類のセットを含むだろう。反復１で識別したサービス分類に対応するＳＣＰ全部が同時に問い合せされる。これに続けて、反復２で識別されたサービス分類に対応するＳＣＰが同時に問い合せされ、以下同様に続く。たとえば、表１５には３つの反復例の後で埋めた表１４を示す。対応する問い合わせオプションはＡ＜（Ｂ，Ｃ，Ｄ）＜Ｅであり、ここで（Ｂ，Ｃ，Ｄ）はＳＣＰＢ，Ｃ，Ｄが同時に問い合わせられることを表わす。前述した方法について以下の考察を行なうことができる。 ――生成される問い合わせオプションの個数は各々の動作オプションについて生成した方向性グラフの個数に等しくなる。よって、たとえば、スクリーニング・サービスが存在し、スクリーニングが他のサービスの１つを無効にできる場合（Ｓ！Ｘ）、少なくとも２つの方向性グラフが生成されることになる。これはこの動作関係に対応する（上記で図示した）２つの先行順序が存在するためである。したがって、少なくとも２つの問い合わせオプションが存在する。 ――ダミー変数は動作関係Ｓ！Ｘ（即ちスクリーニングがサービスＸを無効にする）に対応する先行関係を表現するために必要とされるので、ダミー変数はこの手順を利用する場合にグラフの他の何らかのノードと見なされる。しかし、表１４が完成し、各々の反復についてサービス分類を列挙した後、ダミー変数は表のエントリに対応する問い合わせオプションを形成する際に単純に破棄される。 ――２つまたは３つ以上のＳＣＰが存在しこれらが含むサービスが何らかの動作オプションにしたがって全て（Ｘ｜Ｙ）である場合、先行関係は存在しない。この例に対応するグラフは各サービス分類について描かれた円からなり、それらの間には矢印が描かれない。前述した手順を適用すると、反復１に列挙したＳＣＰが発生する。これはこの例について対応する問い合わせオプションは全てのＳＣＰが同時に問い合せされる、たとえば（Ｘ，Ｙ，Ｚ）ということを意味する。 ――全てのサービス分類が独立していることを動作オプションが表わす場合、ＳＣＰは順次、たとえばＸ＜Ｙ＜Ｚ、Ｚ＜Ｙ＜Ｘなどのように問い合わせることができると記述することもできる。このような問い合わせオプションは、この方法の基盤となる仮定条件で同時問い合わせが可能な限り好ましいとしているため本方法では識別されない。好適実施例以下は２つの動作オプション（ＣＳ→Ｓ，ＮＴ→Ｓ，ＮＴ→ＣＳ）及び（ＮＴ →ＣＳ，Ｓ！ＣＳ，ＮＴ→Ｓ）について問い合わせオプションの生成を示す。図１１は第１の動作オプションに対応する先行関係を示す。前述の方法を適用すると、表１６が得られる。対応する問い合わせオプションはＮＴ＜ＣＳ＜Ｓである。動作オプション（ＮＴ→ＣＳ，Ｓ！ＣＳ，ＮＴ→Ｓ）について図１２と図１３に図示したように２つの先行関係が存在する。したがって、２つの問い合わせオプションを生成する。表１７は図１２に手順を適用することによって得られた表である。これに対応する問い合わせオプションはＮＴ＜Ｓ＜ＣＳである。表１８は図１３に手順を適用して得られる。ＸとＹはダミー変数なので、これらを破棄し、次の問い合わせオプションが形成される：ＮＴ＜（Ｓ，ＣＳ）問い合わせオプションの選択特定の動作オプションと問い合わせオプションが一緒に制御論理を暗示する一方で、所与の動作オプションには通常幾つかの問い合わせオプションが利用できる。何らかの方法を指定して最適な問い合わせオプションが選択できるようにする。問い合わせオプションは特定の制御論理を意味するので、選択メカニズムなしでは何らかの望ましいサービス動作のサポートのために１つの制御論理を別の制御論理から選択する合理的な基盤が存在しない。問い合わせオプションはＳＣＰ個数が増加する程複雑になるので、これは３つまたは４つ以上のＳＣＰではさらに重要になる。所与の動作オプションについて問い合わせオプションのセットを生成したら、問題は制御論理で使用する問い合わせオプションを選択することが問題になる。これを行なうためには、各々のオプションの全体的な良好さを反映する幾つかの基準のセットに基づいて各々の候補問い合わせオプションを順位付けする方法を開発する。候補問い合わせオプションのセットはこれらの順位に基づいて最良の物から最悪の物に順位付けできる。２つだけのＳＣＰが問い合わせを受ける場合での問い合わせオプションの選択は、詳細な順位付けメカニズムを必要としないが、問い合わせオプションは一般に２つだけ存在することから、もっと多数のＳＣＰではどの問い合わせオプションが最大の利益を提供するかは明らかにはならない。本明細書で議論する１つの考えられる評価方式は効率（Ｅ）、コスト（Ｃ）、性能（Ｐ）の基準に基づいている。スコアＳは問い合わせオプションに帰属するこれら３つのファクターの重み付け和に等しくなるように定義される。スコア＝Ｅ＊重み付け（Ｅ）ーＣ＊重み付け（Ｃ）＋Ｐ＊重み付け（Ｐ）高いスコアはより良い問い合わせオプションに対応し、低いスコアはより悪い問い合わせオプションに対応する。３つの評価ファクターＥ、Ｃ、Ｐは次のような属性を有する： ――Ｅは潜在的に不要な問い合わせの回数が少ないと高い。 ――Ｅは潜在的に不要な問い合わせの回数が多いと低い。 ――Ｃは各々の問い合わせオプションに関連する制御論理の複雑さが大きいと高い ――Ｃは各々の問い合わせオプションに関連する制御論理の複雑さが小さいと低い ――Ｐは応答時間が速いと高い ――Ｐは応答時間が遅いと低い記述子高い、低い、速い、小さいは非常に主観的な定義による。上記の定義Ｅで、何らかのＳＣＰへの潜在的に不必要な問い合わせとは、呼処理に対する何らかの影響を発生しないような問い合わせである。サービスＸのＳＣＰへの問い合わせは、 −スクリーニング・サービスを有するＳＣＰがＸを含む別のＳＣＰと同時に問い合わせられる場合、及び −スクリーニングとＸの間の動作関係がスクリーニングがＸを無効にするように作用するものである場合（Ｓ！Ｘ）には潜在的に不要であるということでさらに形式的に定義できる。Ｘへの問い合わせがなぜ潜在的に不要かの理由は、Ｘはスクリーニングに失敗した場合に呼処理に影響を有さないであることによる。Ｐは応答時間に関連する。応答時間をさらに評価する１つの方法は幾つの同時問い合わせが評価の下で問い合わせオプションに存在するかを決定することである。同時問い合わせは何時でも多数の順次問い合わせとして実行し得るものだった。しかし３つのＳＣＰの同時問い合わせが１ステップだけしかかからない一方で、３つのＳＣＰの順次問い合わせが３ステップかかることから、同時問い合わせは一般にこれに対応する順次問い合わせより高速である。Ｃファクターを定義するため、最初に所与の問い合わせオプションを次のような４ステップに分解する：１．ｎ個のＳＣＰに問い合わせる２．応答を待つ３．応答を処理する４．停止（ＳＳＰへ結果を返す）または（１）に進む所与の問い合わせオプションは１回または２回以上これらのステップを繰り返す。こうした各サイクルは何らかのコストを発生する。次に、問い合わせオプションのコストと各サイクルで遭遇した問い合わせの複雑さとを関連付ける。各サイクルで、実行される問い合わせは次のように分類できる（複雑さの減少する順に）：Ａ．スクリーニングが他のサービスの１つを無効にできる場合に（即ちＳ！Ｘ）スクリーニング・サービスと別のＳＣＰでの１つまたは２つ以上のサービス。Ｂ．第１のＳＣＰが第２のＳＣＰへ情報を渡さなければならない、または問い合せされた第１のＳＣＰでのサービスが次に問い合せされるＳＣＰでのサービスを無効にできるような順次問い合せ。Ｃ．他の同時問い合せ。Ｄ．他の順次問い合わせ。この定義を用いると、各問い合わせオプションについてのＣは次の２ステップ手順によって割り当てられる：１．下の表に示したように分割した複雑さに基づく正規化した値を各サイクルに割り当てる。２．問い合わせオプションにおいてサイクル全部に対して正規化した値を合計する前述した方法はここで表１９に示したように選択スコアを作るファクターの各々に値を割り当てることによって定量化できる。各ファクターに関連した動作に割り当てた値は任意である。しかし、重要な制約は、各ファクターに割り当てた値が合計で１になることである。これらの値は問い合わせオプションの全体的スコアを得るために適用できる。全体的スコアは次のように書くことができる：スコア＝[重み付け（Ｅ）Σ（効率値）]ー[重み付け（Ｃ）＊Σ（コスト値）] ＋[重み付け（Ｐ）＊Σ（性能値）] ここで加算は問い合わせオプションに含まれるサイクル全部にわたり、重み付け（Ｅ）＋重み付け（Ｃ）＋重み付け（Ｐ）＝１である。加入者レコード動作オプションと問い合わせオプションが生成されたら、これらをＭＰにアクセス可能な加入者レコード内に実装する。トリガに遭遇しＳＳＰがＭＰへメッセージを送信する時、ＭＰは加入者レコードを取り出してサービスが協調してどのように動作し、またどのような方法でＳＣＰに問い合わせるべきかを決定する。図１５は加入者レコードの実施例の１つを示す。ＭＰが加入者レコードを検索する場合、加入者ＩＤ１５００、トリガＩＤ１５０２（トリガを識別する）、及びトリガＩＤ１５０２に関連した２つのサービス分類、サービス分類Ａ１５０６とサービス分類Ｂ１５１０が見える。サービス分類Ａ１５０６はサービス・プロバイダＡ１５０４に関連し、サービス分類Ｂ１５１０はサービス・プロバイダＢ１５０８に関連する。動作オプション１５１２とこれに関連する問い合わせオプション１５１４も加入者レコードの一部となり論理テンプレートへの入力として用いられて制御論理を指定する。フェーズ３――制御論理次のフェーズは、複数加入トリガに遭遇した場合、ＳＳＰと幾つかのＳＣＰ（ＭＰ経由で）の間の通信管理のための制御論理を指定することを含む。制御論理は同時アクセスをサポートするためＭＰで配備される必要のある管理能力の基盤を形成する。特定トリガへの同時アクセスができるＳＣＰに存在するサービスの分類ならびに加入者レコードに見られるサービス動作を表わす動作オプション及び問い合わせオプションが与えられると、制御論理を生成できる。この制御論理は問い合わせを受けたＳＣＰから受信する情報にＭＰがどのように応答するか、および後続の呼処理についての単一応答メッセージでＭＰがＳＳＰへどのように応答すべきかを完全に決定する。各々の制御論理は制御論理によって実行される必要のあるタスクとこれらのタスク間の関連性を定義する共通論理テンプレートに基づく。図１６はＳＣＰが（何らかの加入者に対して）特定トリガへ同時にアクセスできる場合にＳＳＰと幾つかのＳＣＰの間の（ＭＰ経由で）通信管理のための制御論理を定義するための基盤として用いられる共通論理テンプレートを示す。この論理フローはＭＰで実行される必要のあるタスクに関して、タスク間の関連性と一緒に図示してある。制御論理は加入者レコードにある情報（即ち加入者のトリガへ同時アクセスできるサービス分類と希望するサービス動作及び問い合わせ順序）に特有なものになる。制御論理はＭＰがＳＳＰから、多重加入トリガに遭遇したことを表わす問い合わせメッセージを受信する時にＭＰで実行される。論理テンプレートに示してあるタスクの幾つかはサービス特有または加入者特有の知識に依存しないという意味で一般的である。たとえば、図示したタスクの１つは追加の数収集が必要かどうか決定しなければならない決定ポイントである。これを解決するには、ＲesourceＴype パラメータが１にセットしてあるＳend _Ｔo_Ｒesource メッセージをＳＣＰから受信したかどうかを単に調べるだけで充分であると仮定する。他のタスクは解決に追加の何らかの知識または情報を必要とする。これらの” 知識を必要とする”タスクは図１６に列挙してあり図面において太線で示してある。これらのタスクの解決は所与のトリガへ同時アクセスできる特定のサービスについての何らかの情報、および／またはトリガに遭遇した時に維持されるべきサービスの協調動作についての何らかの情報を必要とする。テンプレートでは、第１のステップが処理ブロック１６００でＳＳＰからの問い合わせを受信することを示している。これの後、処理ブロック１６０２で、動作オプションと問い合わせオプション（即ち１と示したタスク）の選択が行なわれる。処理ブロック１６０４では、次の問い合わせ動作を決定する必要がある。問い合わせ動作は論理フローのこのポイントで実行される必要のある問い合わせを表わす。これには２つの代替案がある、即ち、単一のＳＣＰに問い合わせるか、または幾つかのＳＣＰが同時に問い合わせを受けるかのどちらかである。図１６で太線で表わした構成要素を参照すると、知識を必要とするタスクは次のように列挙される：１．動作オプション、問い合わせオプションの選択２．数の収集と適当なＳＣＰへの返送３．追加ＳＣＰに問い合わせるかどうか４．次の問い合わせ動作に渡すべき情報の決定５．ＳＳＰへの応答の決定タスク１：動作オプション、問い合わせオプションの選択図１６を参照すると、処理ブロック１６００でＳＳＰからの問い合わせメッセージの受信時に、ＭＰは問い合わせメッセージを発した特定の加入者と、遭遇したトリガと、加入者レコードを使用してそのトリガへ同時アクセスできるサービス・プロバイダを識別する。加入者レコードは処理ブロック１６０２で適用可能な特定の動作オプション及び問い合わせオプションを認識する。テンプレートの次のステップは決定ブロック１６０４で、次の問い合わせ動作？と示してある。この点で、単一のＳＣＰに問い合わせを行ない処理ブロック１６０６で応答を受信するか、または処理ブロック１６０８に示したように幾つかのＳＣＰに同時問い合せするかのどちらかである。単一ＳＣＰに問い合わせるかまたは幾つかのＳＣＰに問い合わせるかの選択は加入者レコードにある問い合わせオプションで指定される。説明を平易にすると、各問い合わせオプションが１つまたは２つ以上の”サイクル”で構成される。各サイクルは時間的に１つの点で問い合わせを受けるＳＣＰを単純に指定している。たとえば、問い合わせオプションＷ＜Ｘでは、２サイクルがあるが、これはＷとＸが２つの別々の時間点で問い合わせを受けるためである。問い合わせオプションＷ＜（Ｘ，Ｙ）＜Ｚでは、２つのＳＣＰが同時に第２のサイクルで問い合せされるので３サイクルである。カレントのサイクルのＳＣＰは問い合せを受け、制御論理はＳＣＰ各々からの応答を待つ。応答を受信した後、論理フローの次のステップは決定ブロック１６１０”数収集が必要か？”である。問い合せを受ける１つまたは２つ以上のサービスは加入者から収集した追加の数の形でさらに情報の提供を受けるように要求できる。これはＳＣＰから受信した応答で示される。通常、こうした要求はスクリーニング・サービスによって行なわれるだけで、スクリーニング・サービスが最終的に”成功”または”失敗”どちらかを表わす応答を返すようにするため情報が必要である。タスク２：数の収集と適当なＳＣＰへの返送決定ブロック１６１０で数収集が要求された場合、論理フローはブロック１６１２から１６１６へ移動する。追加情報が必要な場合、制御論理はＲesourceＴy peパラメータを１にセットしてＳend_Ｔo_ＲesourceメッセージをＳＳＰへ返すと仮定し、通知を行って数を収集すべきことを表わす。カレントのサイクルで１つだけのＳＣＰに問い合わせる場合、またこのＳＣＰが追加情報を要求している場合には、ＭＰは最後に問い合わせたＳＣＰへ収集した数を返す。２つまたは３つ以上のＳＣＰがこのサイクルで同時に問い合せされ、１つ（または２つ以上）が追加情報を要求している場合、制御論理は情報を収集するようにＳＳＰに指示し、一方で同時に他のＳＣＰから受信した応答を記録する必要がある。収集した数がＭＰに返されると、制御論理は要求しているＳＣＰへ情報を送信するようにＭＰに指示する必要がある。処理ブロック１６１２において、Ｓend_Ｔo_Ｒesou rce はＳＳＰに返される。次に処理ブロック１６１４で、数の収集が行なわれ適当なＳＣＰへの返信が行なわれて、最終的に処理ブロック１６１６で応答を適当なＳＣＰから受信する。決定ブロック１６１０において数収集がこのサイクルで要求されない場合、論理フローは決定ブロック１６１８でタスク３（追加ＳＣＰに問い合わせるかどうか）へ移動する。タスク３：追加ＳＣＰに問い合わせるかどうか？カレントのサイクルで問い合せを受けたＳＣＰから受信した応答によっては、制御論理は何らかの追加のＳＣＰに問い合せしなければならないかどうかを決定する必要がある。これはタスク３（追加ＳＣＰに問い合わせるかどうか？）と標識した制御論理の決定ブロック１６１８で行なわれる。追加のＳＣＰに問い合せするかどうかを決定するのに必要な知識は問い合わせオプションとカレントのサイクルに依存する。ルールを適用して追加のＳＣＰに問い合せすべきかどうかを決定する。タスク４：次の問い合わせ動作に渡すべき情報の決定処理ブロック１６２４で次の問い合せ動作に情報を渡す必要があるかどうかの決定は動作オプション及び問い合わせオプションに依存する。これを行なってから、論理フローは処理ブロック１６０４に戻る。タスク５：ＳＳＰへの応答の決定このタスクに論理フローで遭遇した場合、これ以上のＳＣＰには問い合せせず、ＭＰは処理ブロック１６２０でＳＳＰへの応答を形成しなければならない。ＳＳＰへの応答メッセージの決定は遭遇したトリガが発呼トリガか終了トリガかに依存する。応答メッセージは発呼トリガと終了についてのルールを用いて決定できる。応答が決定されると、応答は処理ブロック１６２２でＳＳＰに返される。フェーズ４――衝突解決基準本方法でオプションのフェーズは衝突解決基準である。衝突解決基準は２つまたは３つ以上のＳＣＰが相互に衝突するサービスを含む（即ち相反する方法で呼処理に影響しようとする）場合に必要である。衝突は番号変換サービス、通信業者選択サービス、転送サービス、または（恐らく）データ表示サービスを含む２つまたは３つ以上のＳＣＰが同じトリガ遭遇で呼び出された場合に発生する。これらのサービスは各々が後続の呼処理に必要とされる同じ情報部分について（たとえば着信番号（ＣａｌｌｅｄＰａｒｔｙＩＤ））異なる値を返そうとするため衝突する。こうした値のうちの１つだけを呼処理のためにＳＳＰへ返すことができるので、両方のサービスがアクティブになった場合に発生する衝突を解決するための何らかの基準が必要である。選択された特定の基準は定義された問い合わせオプションに反映され、その問い合わせオプションに関連する制御論理にも影響する。一般に、１つの代表的なアプローチは特定トリガへ同時アクセスできるＳＣＰが全て相互に両立できるサービスを含むという概念に基づいている。しかし、サービス分類の幾つかの対の間の動作関係で、サービスに相互に両立しないことが示された場合、これら両者が同時に呼処理に影響することはできない。たとえば、同じトリガでアクティブになっている２つの番号変換サービスは相互に両立しないが、これは単一の着信番号（ＣａｌｌｅｄＰａｒｔｙＩＤ）だけが呼処理に影響できるためである。相互に両立しないサービスが同じトリガでアクティブな場合、本文書で説明した手順及び方法は問い合わせオプションを生成せず、したがって制御論理も生成しない。こうした衝突を解決するには、任意の加入者について何らかの特定トリガでアクティブなサービスを加入者レコードで識別する。これを念頭においておくと、相互に両立しないサービス分類を取り扱う方法は幾つか存在する。転送サービスとデータ表示サービスが両方とも同じトリガで利用できる場合、動作オプションはどれが呼に影響するか指定できる。他の状況では、衝突するＳＣＰのどれが問い合せを受けるべきかについて提供前分析の間に選択を行なうと仮定する。加入者レコードはこのＳＣＰだけを認識する。ＭＰがＳＳＰから問い合わせメッセージを受信して加入者レコードを調べトリガでアクティブになっているＳＣＰ（及びサービス分類）を識別した場合、それまでに選択されたものしか分からない。したがって制御論理はＳＣＰを選択するかまたは同時問い合せされたＳＣＰから返された衝突パラメータ値を解決するための追加処理を実行する必要がない。幾つかのデータ表示サービスが同じトリガでアクティブになっているＳＣＰに存在する場合には別の種類の衝突解決基準が必要である。その場合、データ表示サービスは同じパラメータに対して異なるサービスが異なる値を返す場合にだけ衝突状態になる。各々が異なる情報項目を表示のために返すことがあるのでこれらのＳＣＰ全部に問い合せる。データ表示サービスは呼処理に影響しないが、任意のパラメータに対して１つだけの値しか表示装置に表示できない。したがって、異なるデータ表示サービスによって同じパラメータに異なる値が割り当てられた場合、これらの値の間の衝突は制御論理で解決する必要がある。衝突解決基準が提供されない場合、制御論理は何らかの初期設置、たとえば衝突するパラメータに対しては何らの値も表示しないなどを想定しておく必要がある。ＩＶ．統一原理前述のセクションＩ，ＩＩ，ＩＩＩは各々、（Ｉ）２ＳＣＰシステムでＳＣＰあたり１つのサービス分類、（ＩＩ）２ＳＣＰシステムでＳＣＰあたり複数のサービス分類、（ＩＩＩ）２または３以上のＳＣＰシステムでＳＣＰあたり１つのサービス分類、について各々詳細に説明した。各々の場合、本方法の基本となるものはシステムが実際に運用システムに配備される前に完了される提供前分析である。そのフェーズにおいて、ＳＳＰ−ＳＣＰサービス提供及び拡張機能インタラクションの専門家が指導者として機能し、サービス専門家によって供給されたサービス・インタラクション原理を取り込むことによってサービス分類を表わす各トリガについての制御オプションを決定する。セクション（Ｉ）と（ＩＩ）で、システム指導者はセクション（ＩＩＩ）で提示しなかった追加ステップを完了している、即ちシステム初期設定値が顧客の決定に置き換えられている。セクション（ＩＩＩ）では、各々の顧客には利用可能な制御オプションからオプションが提供され、顧客は利用可能な制御オプションの中からサービスが実行された時に顧客の要望に見合うように選択する。後者の場合、選択された制御オプションはサービス・ノード即ちＳＣＰノードの各々の実行を制御し、制御オプションを参照して特定トリガについてサービス分類の対応する各々１つの実行を制御する。一般術語サービス起始ノード及び供用ノードをＳＳＰとＳＣＰまたはＳＣＰよりはむしろ問い合せ／応答トランザクションに使用できることが当業者には理解されよう。さらに、開示の幅を拡大するものとして、制御オプションは動作オプションと問い合わせオプションの両方を含む。本明細書で説明した本方法の各種代表的実施例は図示のために示してある特定の形態に制限されるものではなく、添付の請求の範囲だけによって制限される他の実施例を仮定することができることはさらに理解されるべきである。

【手続補正書】特許法第１８４条の８第１項【提出日】１９９８年３月２６日【補正内容】請求の範囲１．サービス交換ポイント（ＳＳＰ）によって生成された問い合せを処理して前記ＳＳＰを運用するための応答を作成するための方法であって、前記ＳＳＰはサービス分類のセットを実行するように協調して構成された複数のサービス制御ポイント（ＳＣＰ）によって供用され、前記ＳＣＰは各トリガについて同時にアクティブになり、前記問い合せは前記セットを呼び出す特定加入者によって行なわれた特定のトリガに応答して発生する方法において、特定加入者に関連する制御論理を運用して前記ＳＣＰの各々とサービス分類の各々対応する１つの実行を制御して応答を生成するステップを備え、前記制御論理はサービス・インタラクション原理を取り込むことによって前記サービス分類を表わす制御オプションを決定し、前記サービス・インタラクション原理は各トリガについて前記ＳＣＰの各々における前記サービス分類の多くとも１つの実行要件に基づくものであるステップと、前記加入者の各々について選択された実行可能な制御論理で前記制御オプションを記憶するステップと、を備える処理によって作成されることを特徴とする方法。２．サービス起始ノードと２つの供用ノードの間の通信を管理するための方法であって、前記供用ノードは特定トリガについて同時にアクティブになることによって前記サービス起始ノードへの応答を生成する方法において、サービス・インタラクション原理を取り込むことによってサービス分類を表わす各々のトリガについての制御オプションを決定し、前記サービス・インタラクション原理は各トリガについて前記供用ノードの各々で１つまたは２つ以上の前記サービス分類を実行する要件に基づくものであるステップと、各トリガについて前記制御オプションの１つを選択するステップと、前記制御オプションを参照して前記特定のトリガについて前記サービス・ノードの各々と各々に対応する前記サービス分類の１つの実行を制御して前記応答を生成するステップと、を備えることを特徴とする方法。３．サービス交換ポイント（ＳＳＰ）と２つのサービス制御ポイント（ＳＣＰ）の間の通信を管理するための方法であって、前記ＳＣＰは特定トリガに対して同時にアクティブになることで前記ＳＳＰへの応答を生成する方法において、サービス・インタラクション原理を取り込むことにより前記サービス分類を表わす制御オプションを決定し、前記サービス・インタラクション原理は各トリガについて前記ＳＣＰの各々で１つまたは２つ以上のサービス分類を実行する条件に基づくものであるステップと、各トリガについて前記制御オプションの１つを選択するステップと、前記制御オプションを参照して前記特定のトリガについて前記サービス・ノードの各々と各々に対応する前記サービス分類の１つの実行を制御して前記応答を生成するステップと、を備えることを特徴とする方法。４．前記制御ステップは（ａ）前記特定加入者について前記ＳＣＰの同時問い合せが要求される場合にはステップ（ｂ）に続き、それ以外ではステップ（ｄ）に進むステップと、（ｂ）前記ＳＣＰの各々に同時問い合せして前記ＳＣＰからの応答を受信するステップと、（ｃ）前記ＳＣＰに問い合わせることによって得られた前記応答から前記ＳＳＰについての前記応答を決定して前記応答を返すステップと、（ｄ）問い合わせるべき最初の前記ＳＣＰの１つを決定し、前記最初のＳＣＰに問い合わせて最初の応答を受信するステップと、（ｅ）前記ＳＣＰのうちの第２のＳＣＰに問い合わせるべき場合、ステップ（ｆ）に進み、それ以外では前記最初の応答に基づいて前記応答を返すステップと、（ｆ）必要に応じて前記最初のＳＣＰから前記第２のＳＣＰへ情報を渡し、前記ＳＣＰのうちの第２のＳＣＰに問い合わせ、第２の応答を受信し、前記最初の応答と前記第２の応答に基づいて前記応答を返すステップと、を備えることを特徴とする請求項３に記載の方法。５．サービス起始ノードと複数の供用ノードの間の通信を管理するためのシステムであって、前記供用ノードは特定トリガについて同時にアクティブになることによって前記サービス起始ノードへの応答を生成するようにしたシステムにおいて、サービス・インタラクション原理を取り込むことによってサービス分類を表わす各々のトリガについての制御オプションを決定し、前記サービス・インタラクション原理は各トリガについて前記供用ノードの各々で多くとも１つの前記サービス分類を実行する要件に基づくようにするための手段と、前記決定するための手段に応答して前記制御オプションを参照して前記特定のトリガについて前記サービス・ノードの各々と各々に対応する前記サービス分類の１つの実行を制御して前記応答を生成するための制御手段と、を備えたことを特徴とするシステム。６．サービス起始ノードと２つの供用ノードの間の通信を管理するためのシステムであって、前記供用ノードは特定トリガについて同時にアクティブになることによって前記サービス起始ノードへの応答を生成するようにしたシステムにおいて、サービス・インタラクション原理を取り込むことによってサービス分類を表わす各々のトリガについての制御オプションを決定し、前記サービス・インタラクション原理は各トリガについて前記供用ノードの各々で１つまたは２つ以上の前記サービス分類を実行する要件に基づくようにするための手段と、前記決定するための手段に応答して、各トリガについて前記制御オプションの１つを選択するための選択手段と、前記選択するための手段に応答して、前記制御オプションを参照して前記特定のトリガについて前記サービス・ノードの各々と各々に対応する前記サービス分類の１つの実行を制御して前記応答を生成するための選択手段と、を備えたことを特徴とするシステム。【手続補正書】【提出日】１９９９年２月１０日【補正内容】（１）明細書３９頁第７行〜第９行の「これを行なってしまうと、ＩＴは１つまたは２つ以上の問い合わせ順序が残りの”真の”動作オプションについて存在することを保証できる。」を、「これを行なってしまうと、１つまたは２つ以上の問い合わせ順序が残りの”真の”動作オプションについて存在することを保証できる。」と補正する。（２）図７を別紙のとおり補正する。【図７】

Claims

【特許請求の範囲】１．サービス交換ポイント（ＳＳＰ）によって生成された問い合せを処理して前記ＳＳＰを運用するための応答を作成するための方法であって、前記ＳＳＰはサービス分類のセットを実行するように協調して構成された複数のサービス制御ポイント（ＳＣＰ）によって供用され、前記ＳＣＰは各トリガについて同時にアクティブになり、前記問い合せは前記セットを呼び出す特定加入者によって行なわれた特定のトリガに応答して発生する方法において、指導者として機能するＳＣＰサービス専門家により供給されるサービス・インタラクション原理を取り込むことにより前記サービス分類を表わす制御オプションを決定し、前記サービス・インタラクション原理は各トリガについて前記ＳＣＰの各々での前記サービス分類の多くとも１つを実行する条件に基づくものであるステップと、前記加入者の各々について選択された実行可能な制御論理に前記制御オプションの１つを格納するステップと、前記特定加入者に関連した前記制御論理を運用して前記ＳＣＰの各々と前記サービス分類の各々に対応する１つの実行を制御することによって前記応答を生成するステップと、を備えることを特徴とする方法。２．サービス起始ノードと２つの供用ノードの間の通信を管理するための方法であって、前記供用ノードは特定トリガについて同時にアクティブになることによって前記サービス起始ノードへの応答を生成する方法において、指導者として機能する供用ノードのサービス専門家によって供給されたサービス・インタラクション原理を取り込むことによってサービス分類を表わす各々のトリガについての制御オプションを決定し、前記サービス・インタラクション原理は各トリガについて前記供用ノードの各々で１つまたは２つ以上の前記サービス分類を実行する要件に基づくものであるステップと、各トリガについて前記専門家によって前記制御オプションの１つを選択するステップと、前記制御オプションを参照して前記特定のトリガについて前記サービス・ノードの各々と各々に対応する前記サービス分類の１つの実行を制御して前記応答を生成するステップと、を備えることを特徴とする方法。３．サービス交換ポイント（ＳＳＰ）と２つのサービス制御ポイント（ＳＣＰ）の間の通信を管理するための方法であって、前記ＳＣＰは特定トリガに対して同時にアクティブになることで前記ＳＳＰへの応答を生成する方法において、指導者として機能するＳＣＰサービス専門家により供給されるサービス・インタラクション原理を取り込むことにより前記サービス分類を表わす制御オプションを決定し、前記サービス・インタラクション原理は各トリガについて前記ＳＣＰの各々で１つまたは２つ以上のサービス分類を実行する条件に基づくものであるステップと、各トリガについて前記専門家によって前記制御オプションの１つを選択するステップと、前記制御オプションを参照して前記特定のトリガについて前記ＳＣＰの各々と各々に対応する前記サービス分類の１つの実行を制御して前記応答を生成するステップと、を備えることを特徴とする方法。４．前記制御ステップは（ａ）前記特定加入者について前記ＳＣＰの同時問い合せが要求される場合にはステップ（ｂ）に続き、それ以外ではステップ（ｄ）に進むステップと、（ｂ）前記ＳＣＰの各々に同時問い合せして前記ＳＣＰからの応答を受信するステップと、（ｃ）前記ＳＣＰに問い合わせることによって得られた前記応答から前記ＳＳＰについての前記応答を決定して前記応答を返すステップと、（ｄ）問い合わせるべき最初の前記ＳＣＰの１つを決定し、前記最初のＳＣＰに問い合わせて最初の応答を受信するステップと、（ｅ）前記ＳＣＰのうちの第２のＳＣＰに問い合わせるべき場合、ステップ（ｆ）に進み、それ以外では前記最初の応答に基づいて前記応答を返すステップと、（ｆ）必要に応じて前記最初のＳＣＰから前記第２のＳＣＰへ情報を渡し、前記ＳＣＰのうちの第２のＳＣＰに問い合わせ、第２の応答を受信し、前記最初の応答と前記第２の応答に基づいて前記応答を返すステップと、を備えることを特徴とする請求項２０に記載の方法。５．サービス起始ノードと複数の供用ノードの間の通信を管理するためのシステムであって、前記供用ノードは特定トリガについて同時にアクティブになることによって前記サービス起始ノードへの応答を生成するようにしたシステムにおいて、指導者として機能する供用ノードのサービス専門家によって供給されたサービス・インタラクション原理を取り込むことによってサービス分類を表わす各々のトリガについての制御オプションを決定し、前記サービス・インタラクション原理は各トリガについて前記供用ノードの各々で多くとも１つの前記サービス分類を実行する要件に基づくようにするための手段と、前記決定するための手段に応答して前記制御オプションを参照して前記特定のトリガについて前記サービス・ノードの各々と各々に対応する前記サービス分類の１つの実行を制御して前記応答を生成するための制御手段と、を備えたことを特徴とするシステム。６．サービス起始ノードと２つの供用ノードの間の通信を管理するためのシステムであって、前記供用ノードは特定トリガについて同時にアクティブになることによって前記サービス起始ノードへの応答を生成するようにしたシステムにおいて、指導者として機能する供用ノードのサービス専門家によって供給されたサービス・インタラクション原理を取り込むことによってサービス分類を表わす各々のトリガについての制御オプションを決定し、前記サービス・インタラクション原理は各トリガについて前記供用ノードの各々で１つまたは２つ以上の前記サービス分類を実行する要件に基づくようにするための手段と、前記決定するための手段に応答して、各トリガについて前記専門家によって前記制御オプションの１つを選択するための選択手段と、前記選択するための手段に応答して、前記制御オプションを参照して前記特定のトリガについて前記サービス・ノードの各々と各々に対応する前記サービス分類の１つの実行を制御して前記応答を生成するための選択手段と、を備えたことを特徴とするシステム。