JPH0746242A - 呼処理システムおよび該呼処理システムにおけるインタラクション方法ならびにプロセッサ - Google Patents

Abstract

(57)【要約】 【目的】 呼処理動作と管理動作の両方のために、機能
インタラクションの決定においていっそう柔軟な呼処理
システムを提供する。 【構成】 通信中の所定の各トリガポイントで、要求さ
れた個々の機能の起動動作を実行する。この起動動作で
用いるためにネットワークメモリに記憶されたデータを
アクセスする。機能をカスタマイズ可能にするためにデ
ータはテーブルおよびビットマップの形式でメモリに配
置されている。次に、起動に応じて要求された個々の機
能を実行する。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、通信ネットワークのた
めの呼処理システムに関する。より詳細には、本発明
は、基本呼ソフトウェアと、呼処理動作を実現する機能
ソフトウェアとの間の機能インタラクションを決定する
一般的な方法論を利用する呼処理システムに関する。

【０００２】

【従来の技術】最新の通信ネットワークは、階層化され
たネットワーク構造を利用しており、これは物理的なエ
レメントないしハードウェア（”リソース”とも称す
る）と、個々のネットワークオペレーションを実行する
ソフトウェアに分かれる。呼処理のつまり加入者の接続
のネットワークオペレーションには、基本呼ソフトウェ
ア（これは加入者を相互に接続する動作を管理する）
と、呼機能ソフトウェア（これは機能サービスオペレー
ションを管理する）が含まれる。たとえば機能サービス
には、呼待機（ＣＷ）、呼転送（ＣＦ）、受付監視ない
し作業員緊急優先（ＡＥＯ）、ドゥーノットディスター
ブ（ＤＮＤ）、３ウェイ呼び出し等が含まれる。

【０００３】コンピュータベースの交換システムの導入
以来、加入者に提供される機能サービスの数は著しく増
加した。このことによりネットワークソフトウェアを設
計するにあたって、呼処理動作の機能関連の考察事項が
促進されるようになった。このような考察事項には、加
入者による交換機ベースの新たな機能要求に対する開発
上の速やかな応答、加入者に対していっそう多種多様で
あり特定化された機能、さらには種々異なるネットワー
ク会社ロケーションにおける機能ソフトウェアの開発が
含まれる。たとえば最近導入されたインテリジェントネ
ットワーク（”ＩＮ）の形式のようなネットワークの、
最新の呼ソフトウェアは、基本呼ソフトウェアと呼機能
ソフトウェアを分離することにより機能関連の考察事項
を取り扱っている。このように分離したことにより、高
速な機能導入が可能になると同時に、基本呼の安定性が
得られる。

【０００４】しかし加入者機能サービスの増加により、
基本呼ソフトウェアと、呼び出し中に機能を実施するた
めの呼機能ソフトウェアとの間の（”機能インタラクシ
ョン”として知られる）インタラクションの数までもい
っそう増加した。既存の交換システムの場合、これらの
機能インタラクションは通常、基本呼ソフトウェアのい
たるところに埋め込まれた特別の機能インタラクション
チェックにより行われている。このことにより、すべて
の機能は同じ交換システム内に配置されるために機能セ
ットがコンスタントに増加するにもかかわらず、インタ
ラクションを決定することができる。しかしこのように
固定的にコーディングされたソフトウェア（これは顧客
特有である）を基本呼ソフトウェアとともに用いること
の結果として、導入された新たな機能の各々によりアッ
プグレードさせることは、特有のソフトウェアよりはむ
しろ交換システムソフトウェア全体に要求される。しか
も、ＩＮ形式のネットワークでは機能インタラクション
をこのような手法によって解決することはできない。こ
の種のネットワークの場合、機能は、加入者および交換
システムから地理的に離れた位置に物理的に存在してお
り、したがって新たに導入された各ＩＮ機能により新た
な交換ソフトウェアが必要とされる。

【０００５】加入者機能の増加により、（システムおよ
び加入者ライン特性を規定する）管理ソフトウェアと
（呼機能の特性を規定する）呼機能ソフトウェアを有す
るネットワークの管理動作においても、同じような問題
が生じる。とりわけ現在では、個々の加入者ラインに対
し機能を割り当てるか変更するための、管理ソフトウェ
アと呼機能ソフトウェアの間におけるインタラクション
の数が著しく多い。呼処理動作による場合のように、こ
れらの機能インタラクションは現在、管理ソフトウェア
により固定的にコーディングされたソフトウェアを用い
ることにより行われており、このため上述の制限と同様
な制限を有する。

【０００６】したがって、呼処理動作と管理動作の両方
のために、機能インタラクションの決定においていっそ
う柔軟な呼処理システムが必要とされている。

【０００７】

【発明の構成および利点】本発明により以下のステップ
を有する方法が提供される。すなわち、ａ）オペレーテ
ィングプログラム実行中の所定の時点において、個々の
サブルーチンプログラムを起動するために呼処理システ
ムのメモリに記憶されたデータを用いた動作を実行する
ステップを有しており、前記の起動動作は起動すべきサ
ブプログラムの形式に依存せず、ｂ）前記の実行ステッ
プの起動動作のためにメモリに記憶されたデータをアク
セスするステップを有しており、前記データは、個々の
サブルーチンプログラムとオペレーティングプログラム
とのインタラクションをカスタマイズできるように、論
理テーブルおよびビットマップのフォーマットでメモリ
に配置されており、ｃ）前記プログラムの起動に応じて
個々のサブプログラムを実行するステップを有する。こ
の方法は、サブルーチンプログラムに関するデータによ
り決定された順序で、所定の時点に起動可能な複数個の
サブルーチンプログラムの各々に対し、ステップａ、
ｂ、ｃを反復する付加的なステップを有することもでき
る。

【０００８】起動動作を実行するステップは、データテ
ーブルおよびデータビットマップのエントリを用いたビ
ットマップ論理演算およびビットマップ検索動作を実行
するような、データテーブルとデータビットマップのエ
ントリを用いたデータ演算を実行するステップを有する
ことができる。さらに付加的に、個々のサブルーチンプ
ログラムを実行するステップは、個々のサブルーチンプ
ログラムを実行するほかに、オペレーティングプログラ
ムによるタスクを実行するステップを有することもでき
る。

【０００９】さらに、起動動作を実行するステップは、
所定の時点で複数個のサブルーチンプログラムの起動順
位を決定するステップを有することができ、前記のデー
タは、サブルーチンプログラム間のインタラクションお
よび起動優先度を規定し、他方、個々のサブルーチンプ
ログラムを実行するステップは、起動順序で個々のサブ
ルーチンプログラムの各々を実行するステップを有する
ことができる。

【００１０】有利には本発明により、機能インタラクシ
ョンを支援するいっそう柔軟性のある方法が提供され
る。この機能インタラクションは既存のシステムでは、
基本呼ソフトウェアに影響を及ぼすものであり、管理可
能なデータテーブル（これはビットマップを含む）とテ
ーブル駆動アルゴリズムを用いて、新たな各機能の付加
または変更によりソフトウェアのアップグレードが必要
とされる。機能データおおび加入者特有のチェックを供
給するテーブルフォーマットにより、この種のデータを
所望のようにカスタマイズすることができ、さらに容易
に手動または自動的に検査することができ、機能インタ
ラクションの完全性が保証される。また、テーブル駆動
機能インタラクションにより、基本呼ソフトウェアと呼
機能ソフトウェアとの間の明確な分離を支援でき、この
結果、新たな機能の付加および変更によっても、ソフト
ウェアのアップグレードというよりはむしろ管理上の入
力が必要とされるだけである。しかもこのアルゴリズム
は機能に依存しないので、基本呼ソフトウェアのために
一般的なソフトウェアコードを開発することができる。
したがって基本呼ソフトウェアは、基本呼動作を制御し
すべての加入者に共通の一般的なテーブル駆動アルゴリ
ズムを実行するように開発することができ、他方、機能
ソフトウェアは、個々の加入者の要求にかなうように別
個に開発することができる。

【００１１】有利には本発明により、インタラクション
仕様ドキュメントを用いることにより目下行われている
よりもいっそう一律に機能インタラクションを規定する
正確なルールセットも提供される。さらに付加的に本発
明により、機能インタラクションが１個所に集中され
る。しかも本発明はＩＮと両立性があり、現在および今
後のＩＮ規格に対して利用可能な基礎を提供する。

【００１２】また本発明は、機能”プラガビリティ（pl
uggability）”を支援しソフトウェアに及ぼす機能の作
用を局所化するために機能的に十分に分割されている呼
処理設計を行うことにより、現在ではそれぞれ異なるベ
ンダーからのエレメントにより構成されていることの多
いネットワークの管理を支援する。さらに本発明によ
り、ネットワーク交換機外でカスタマイズされた機能開
発を許容し、局所化された変形が許容されると同時に分
割されたソフトウェアの量を最大にできるようにするた
めに、加入者の構内におけるネットワーク設備機器から
制御できる”ビルディンブブロック（building bloc
k）”方式の可能な呼処理設計が行われる。

【００１３】

【実施例の説明】図１には、本発明の呼処理システム１
０のブロック図と、これにより第１加入者Ａと第２加入
者Ｂ間で形成された呼経路が示されている。交換ネット
ワーク１１は、それに接続された種々異なる形式の加入
者を有している。図面にはそれらの実例が示されてお
り、（たとえば構内交換素子１２を利用する）加入者Ａ
と、加入者Ｂとを有する。なお、加入者Ａ、Ｂをそれぞ
れ種々異なる加入者形式のうちの１つとすることがで
き、それらには非同期伝送モード環境にある加入者が含
まれ、これは非同期伝送モード／同期伝送モード（ＡＴ
Ｍ／ＳＴＭ）インターフェース１３を使用するネットワ
ークと接続されている。さらに言及しておくと、加入者
Ａ、Ｂを（同じ形式のまたは別の形式の、たとえば集中
制御ＴＤＭシステム、分散制御ＴＤＭシステム、パケッ
ト交換システム等の）異なる２つの交換ネットワーク１
１と接続することができ、それらの間（つまり２つ加入
者Ａ、Ｂの間）のトランクラインによりそれぞれ他方と
接続されている。さらに交換ネットワーク１１は、それ
に接続された呼プロセッサ２０を有しており、このプロ
セッサは呼処理ソフトウェアを作動し、したがってシス
テム１０のために組み合わせられたハードウェア素子を
含む呼処理動作を制御する。択一的にこの呼プロセッサ
２０を、交換ネットワーク１１に集積された素子として
構成してもよい。

【００１４】呼処理システム１０は、ハードウェア素子
をソフトウェアと分離する階層化ネットワークアーキテ
クチャに従っている。この種のネットワーアーキテクチ
ャは、システムソフトウェアモデルの構成にしたがっ
て、各オペレーションのためのソフトウェアもそれぞれ
異なる機能レイヤに分割している。基本ソフトウェアモ
デルは、システムの物理素子と相互に作用し合うリソー
スソフトウェアレイヤ（最低レベル）と、ネットワーク
１１および加入者の性能または機能を実現するアプリケ
ーションソフトウェアレイヤ（最高レベル）と、多数の
システムオペレーションを論理的に駆動しオペレーショ
ンの実行手法に関する特殊な知識なくアプリケーション
ソフトウェアにリソースを利用させるサーバソフトウェ
アレイヤ（中間レベル）とを有する。たいては分散シス
テムである最新の通信ネットワークの動作を容易にする
ために、たとえば各レイヤ内でさらに複数個のレイヤに
分けるかまたはサブモデルを形成させるような、基本モ
デルの変形が行われることも多い。

【００１５】システム１０は、呼処理ソフトウェアのた
めの階層化モデルを実行する。呼処理ソフトウェアは、
高い方の論理関連レベルを低い方のハードウェア関連レ
ベルと分離し、さらにアプリケーションレベルで基本呼
ソフトウェアを呼機能ソフトウェアと分離する。上述の
ように、この種の階層化ソフトウェア構造により、（ロ
ケーション特有の変形、種々異なるハードウェア技術、
新しいハードウェア性能、ならびに顧客特有のカスタマ
イズのような）交換機能が増強され、他方、システム１
０に対する構造上の影響が最小化される。さらに上述の
ように、プロセッサ２０はシステム１０のための呼処理
ソフトウェアを作動する。択一的に、高い方の論理関連
レベルだけを作動するように、このプロセッサ２０を構
成してもよい。したがって加入者ベースの素子は低い方
のハードウェア関連レベルを取り扱う。２つの加入者
Ａ、Ｂがネットワーク１１と相互接続されている場合、
システム１０が、この種の制御と責務を既存の交換機プ
ロセッサと分担するプロセッサ２０を有するように構成
してもよい。このことのにより、ハードウェア素子はそ
れ自身のホストソフトウェアによってのみ制御され、プ
ロセッサ２０が所定の交換コンポーネントだけを制御す
るようにできる。

【００１６】図２には、プロセッサ２０により作動され
る呼処理ソフトウェアの構造の簡略化されたブロックが
示されており、図３にはその詳細なブロックが示されて
いる。基本呼ソフトウェアは、機能的に分離された複数
個のサブシステムを有しており、それらは各々特定の呼
処理作業を取り扱う。サブシステムはコネクティビティ
コントロール（ＳＬＳ）を含む。これは論理的および物
理的交換を行い、相互に作用し合うことなくシステムソ
フトウェアとハードウェアを変えられるように、高い方
のアプリケーションレイヤを低い方のリソースレイヤか
ら保護する。またサブシステムはリソースハンドラ（Ｒ
ＨＳ）を含み、これはシステム１０のリソースたとえば
プロトコルハンドラ、コード受信機、トーン発生器、チ
ャネル切換器等を管理する。さらにこのサブシステムに
はシグナリングシステム（ＥＳＩＳ）も含まれており、
これは２つの加入者Ａ、Ｂのそれぞれ異なるシグナリン
グスキーマの相互作用を処理する。またこのサブシステ
ムには、他のサブシステムから受信された情報からのビ
リングレコードのフォーマットを整えて記憶するビリン
グシステム（ＢＩＬＬＳ）と、他のサブシステムから受
信された統計的な情報を処理し記憶する統計システム
（ＳＴＡＴＳ）が含まれている。さらに、論理的呼制御
システム（ＥＣＰＳ）により一般的な呼制御性能が提供
され、これには呼経路指定、基本呼セットアップ／クリ
アダウン、機能インタラクション制御、機能処理、なら
びにＢＩＬＬＳおよびＳＴＡＴＳシステムへ通報するた
めの呼事象が含まれる。しかしＥＣＰＳシステムは物理
的な呼セットアップ／クリアダウンを開始するが処理は
せず、セットアップ／クリアダウンはその代りに別のサ
ブシステムにより処理される。なお、呼機能ソフトウェ
アは、アプリケーションレイヤにおいて基本呼ソフトウ
ェアと分離されていることを言及しておく。

【００１７】各サブシステムは、（”マネージャ”とし
て知られる）スタティックユニットと（”セグメント”
として知られる）状態遷移ユニットにより形成された１
つまたは複数個の状態／事象機構を有する。マネージャ
は、システム１０のために形成されたソフトウェアとデ
ータベース間のニュートラルインターフェースを提供
し、その際、セグメントのためのデータを供給する。こ
こで言及しておくと、データベースを、（図３に示され
ているように）基本呼ソフトウェアの統合されたエレメ
ントとして構成してもよいし、または基本呼ソフトウェ
アと相互に作用し合う別個のソフトウェアエンティティ
として構成してもよい。またこのデータベースを、（図
３に示されているように）複数個の別個のデータベース
として構成してもよいし、あるいはただ１つのデータベ
ースとして構成してもよい。セグメントは論理的呼制御
機能を実行し、これはたとえば占有／解除作業や機能特
有の動作を処理する。加入者を接続するための呼モデル
は、カスタマイズされたセグメントチェインまたはただ
１つの呼を扱う呼チェインを形成するために、種々異な
る状態／事象機構をいっしょに連鎖させることから成
る。呼特有の要求または加入者／ネットワーク機能に応
じて、セグメントが加えられるか、呼チェインから除か
れる。

【００１８】ＥＣＰＳシステムは、複数の形式のマネー
ジャおよびセグメントを用いる。アクセスマネージャ
（ＡＭ）はシステム１０（たとえばトランクまたはライ
ン）への物理的なアクセスの役割を果たし、これはシグ
ナリング形式には依存しない。ＡＭは、アクセスデータ
ベース読み／書き要求を処理し、アクセスに関連したビ
ジー／アイドル処理を行う。ユーザマネージャ（ＵＭ）
は、ディレクトリ番号（ＤＮ）のようなユーザ識別の役
割を果たす。ＵＭはＤＮデータベース読み／書き要求を
処理し、ユーザ識別に関連したビジー／アイドル処理を
行う。ネットワーク経路指定マネージャ（ＮＲＭ）はト
ランスレータを介して数字情報を評価し、適切な呼処理
を決定する。ＮＭＲは変換データベース読み／書き要求
を処理し、加入者のためにカスタマイズ可能な複数個の
トランスレータを制御することができる。なお、セグメ
ントと個々のデータベース間の接続は、実際のマネージ
ャではなく図３に示されている。

【００１９】図４にはＥＣＰＳシステムのセグメントの
ブロック図が示されている（なお図３にはセグメントの
接続に関する付加的な詳細が示されている−ＢＩＬＬＳ
およびＳＴＡＴＳサブシステムとの接続ならびに呼機能
ソフトウェアはオープンノードとして示されている）。
アクセストランザクションセグメント（ＡＴＳ）は、ア
クセスリソース（つまりライン／トランク性能）のため
のただ１つの信号要求を表わしている。この信号要求に
はたとえばただ１つのトランク、ただ１つの加入者Ｂ−
チャネル、または割り当てられた帯域幅が含まれてい
る。さらにＡＴＳはアクセス機能トリガも制御する。ユ
ーザトランザクションセグメント（ＵＴＳ）は、ユーザ
のリソース（たとえばＤＮまたは移動ユーザ）のための
ただ１つの要求を表わしている。呼の各加入者Ａ、Ｂ
は、組み合わせられたＡＴＳおよびＵＴＳ（および関連
したマネージャＡＭ、ＵＭ）を有する。アソシエータセ
グメント（ＡＳ）は加入者Ａ側／加入者Ｂ側の一対の呼
を結合し、呼セットアップ／クリアダウンを調整する。
ＡＴＳ、ＵＴＳまたはＡＳは、ユーザ機能トリガを制御
できる。この図面には示されていないけれども、機能セ
グメント（ＦＳ）は、アプリケーションレベルにおける
機能ソフトウェアからの個々の機能を表わし、加入者
Ａ、Ｂによりまたは交換ネットワーク１１により要求さ
れると、呼チェインとリンクされる。各ＦＳは機能特有
ロジックを有しており、機能特有ロジックが１つのソフ
トウェアユニットに集中するように、その特有の機能に
関連したデータへのアクセスを有する。

【００２０】図５には、加入者Ａおよび加入者Ｂの間
の、基本呼のための呼チェインのブロック図が示されて
おり、これは機能ソフトウェアを必要としない。セグメ
ントは、一方の呼端末から他方の呼端末へ送信された信
号が、優先順にセグメントを通過するように、呼チェイ
ンに沿って順序づけられている。このことにより、高い
方の優先順位のセグメントは、低い方の優先順位のセグ
メントよりも前に、信号を途中で捕捉する機会が、およ
び／またはそれに応動する機会が与えられる。基本呼
は、加入者Ｂを呼び出すために電話端末をオフフックし
た加入者Ａにより開始される。加入者Ａ側における加入
者ラインモジュールＳＬＭ（図示せず）は、端末オフフ
ックから占有ライン信号を検出し、シグナリング特有の
占有メッセージを呼プロセッサ２０へ送信する。基本呼
ソフトウェアの加入者Ａ側ＥＳＩＳは、このメッセージ
を一般的な占有メッセージへ変換し、ＥＣＰＳ ＡＴＳ
を呼び出し、メッセージをＡＴＳへ伝える。次にＡＴＳ
は、ＡＭにアクセス関連データを要求する（ただしマネ
ージャおよびデータベースはこの図には示されていな
い）。ＡＭはこのデータを加入者Ａ側のデータベースか
ら読み出し、アクセスに関連したビジー／アイドル処理
を行い、アクセス占有データをＡＴＳへ戻す。ＡＴＳは
アクセスデータを記憶し、ＵＴＳを呼び出し、占有メッ
セージをＵＴＳへ伝える。次に、ＵＴＳはＵＭにＤＮ関
連データを要求する。ＵＭはこのデータを加入者Ａ側デ
ータベースから読み出し、ＤＮビジー／アイドル処理を
行い、ＤＮデータをＵＴＳへ戻す。ＵＴＳはＡＳを呼び
出し、ＡＳは呼チェインを通して加入者Ａ側ＥＳＩＳへ
送信されたメッセージを介して数字を要求する。この時
点において、呼チエインは、加入者Ａ側ＥＳＩＳ−ＡＴ
Ｓ−ＵＴＳ−ＡＳにより構成されている。

【００２１】このシグナリング形式に基づき、ＥＳＩＳ
はダイアルトーンを決定し、コード受信機（図示せず）
が必要であるか、したがってＳＬＳを通知するか否かを
決定する。ＳＬＣは最適なリソースロケーションを決定
し、関連のＲＨＳにリソース割り当ておよび接続を要求
する。ＲＨＳは交換ネットワーク１１の個々のハードウ
ェアエレメントを通知し、これらのハードウェアの接続
を制御する。コード受信機は受信に応じて数字をＥＳＩ
Ｓへ直接送信する。これに応じてＥＳＩＳはＳＬＳにダ
イアルトーンの切断を要求し、数字を標準インターフェ
ースへ変換し、呼チェインを通してＡＳへ数字を送信す
る。なお、数字要求メッセージと数字の両方はＡＴＳと
ＵＴＳを透過的に通過することを言及しておく。次に、
ＡＳは数字をＮＲＭへ送信し、これはトランスレータ
（図示せず）および変換データベースを介して数字を伝
える。変換結果が決定されれれば、ＮＲＭはその結果を
ＡＳへ戻し、ＡＳは加入者Ｂ側ＵＴＳを呼び出す。

【００２２】ダイアリングの終了が検出されるとただち
に、加入者Ａ側ＥＳＩＳはＳＬＳへの命令によりコード
受信機を開放し、さらにＳＬＣは物理的リソースを切断
し休止させるためにＲＨＳへ通知する。加入者Ｂ側ＵＴ
ＳはＵＭ（および加入者Ｂ側のデータベース）にＤＮデ
ータを要求して検査し、ＡＴＳを呼び出す。ＡＴＳはＡ
Ｍ（および加入者Ｂ側のデータベース）にデータを要求
し、アクセスビジー／アイドル状態をビジーにする。次
にＡＴＳはＥＳＩＳを呼び出し、ＥＳＩＳは占有を加入
者Ｂ側のＳＬＭへ通報し、要求されたデータを供給す
る。次にＳＬＭは呼出音電流を加入者Ｂの電話端末へ供
給する。ＥＳＩＳは、ＳＬＳに呼出音の接続を要求し、
さらにＳＬＳは音源を割り当てるＲＨＳへ通報する。こ
こにおいてＳＬＳは、加入者Ａ側を介して音源を切り換
える。ＳＬＳは交換ネットワーク１１要求を決定し、Ｒ
ＨＳに交換リソース（たとえばチャネル）を要求する。
交換機リソースは割り当てられ、局部的にセットアップ
されるとただちに、ＳＬＳは交換接続を完了するのに必
要な命令を送信する。

【００２３】応答が発生すると、これは加入者Ｂ側のＳ
ＬＭにより検出され、このＳＬＭは呼出音電源を切断
し、接続メッセージをＥＳＩＳへ送信する。ＥＳＩＳは
呼出音の切断を要求し、接続メッセージを一般的なメッ
セージへ変換し、呼チェインを介してこれをＡＴＳへ伝
える。ＡＴＳは、応答が発生しメッセージが加入者Ａ側
へ転送されることを示す。この時点で２つの加入者Ａ、
Ｂ間において通話を行うことができる。

【００２４】図６には、加入者Ａと加入者Ｂの間で１つ
の機能を要求する呼のための呼チェインのブロック図が
示されている。この機能呼チェインの構造および動作は
上述の基本呼チェインに類似しており、さらに機能セグ
メントＦＳの導入および処理が加えられている。特有の
機能ロジックを要求する機能呼チェインは、基本呼セグ
メントとリンクされた呼機能ソフトウェアからの個々の
ＦＳを有する。１つの呼チェイン内の多種多様な機能を
行うこともできる。ＦＳと基本呼チェインとのリンク
は、基本呼ソフトウェアと加入者特有の呼機能ソフトウ
ェアとの間の機能インタラクションにより行われる。

【００２５】この呼処理システムにおいて、機能インタ
ラクションは、機能がアクティブであるか否かを決定す
るために基本呼ソフトウェアのいたるとろこに埋め込ま
れた機能チェックソフトウェアを用いることにより行わ
れる。これらの機能チェックは、基本呼チェイン内にお
いて、トリガポイントとして知られている明確に定めら
れた時点で実施される。トリガポイントにはたとえば、
呼発生（つまり発呼加入者Ａが端末を取り上げてオフフ
ックする）、呼発生試行許可（つまりオフフックの確認
チェック）、数字分析／変換、応答（被呼加入者Ｂが到
来した呼に応答）、占有されている加入者Ｂに対する
呼、中間呼トリガ（つまり発呼加入者Ａが瞬間的にフッ
クまたは一時中止の発生）。１つのシステムにおいてい
くつのトリガポイントを用いてもよいし規定してもよ
い。たとえばＵ．Ｓ．ＡＩＮ公開０．１（Advanced Int
elligent Network standard ）では、基本呼チェイン内
に約３０個のこの種のトリガポイントが規定されてい
る。図面に示されているように、機能呼動作中、機能チ
ェックによりトリガポイントにおけるアクティブな機能
が示される。これに応じて、呼機能ソフトウェアは基本
呼ソフトウェアおよびその他の機能と相互に作用し合
い、ＦＳは基本呼チェインと結合される。そして呼チェ
インは、機能ロジックを実行できるようになる。これと
は対照に、２つの加入者Ａ、Ｂ間のライン呼び出しのた
めの基本ラインには、基本呼ソフトウェアだけが要求さ
れる。したがって機能チェックによってもトリガポイン
トにおいてアクティブな機能は示されず、基本呼チェイ
ンは機能ロジックを実施しない。なお、機能チェック
は、各トリガポイントにおいて一時的に呼処理を中止す
る。さらにこの呼処理システムは１つの呼チェインのい
たるところで、呼出し中に機能をトリガすべきか否かに
ついての機能チェックを実施する。

【００２６】本発明の呼処理システムにおいて、プロセ
ッサ２０は、ＦＳのトリガおよび基本呼チェインとのイ
ンタラクションを決定するために、基本呼ソフトウェア
内の新規の機能インタラクションアルゴリズムを利用す
る。このアルゴリズムは各トリガポイントにおいて実行
され、システム１０のためのデータベースに記憶された
テーブルおよびビットマップフォーマット内に配置され
た機能データに基づいて動作する。１つの機能のトリガ
の決定に応じて、このアルゴリズムは呼機能ソフトウェ
アと基本呼ソフトウェアとのインタラクションを管理す
る。テーブルおよびビットマップフォーマットにより、
（図面に示されているように）行および列のための指標
番号またはその他の中立的な識別子を用いるようにして
中立的な手法で、呼機能およびサポートデータを識別し
認識することができる。したがって、機能インタラクシ
ョンアルゴリズムは機能に依存せず（埋め込まれた目下
の機能チェックソフトウェアとは異なる）ので、基本呼
ソフトウェアを支援しこのソフトウェアにより呼び出さ
れるときには常に使用可能である一般的なコードを、ア
ルゴリズムを実現するためにプロセッサ２０により利用
できる。さらに、データテーブルとビットマップの両方
は”管理可能である”、つまりカスタマイズ可能であ
り、したがって機能インタラクションも管理することが
できる。その結果、基本呼ソフトウェアに付加的な機能
インタラクションアルゴリズムコールを加えることによ
り、さらにデータテーブルとビットマップに必要なデー
タを加えることにより、呼チェインにおいて新たなトリ
ガポイントを簡単に定めることができる。同様に既存の
トリガポイントの変更も、基本呼ソフトウェアの個々の
部分とデータテーブルおよびビットマップのデータを変
更することにより行える。したがって既存の機能の変更
も新たな機能の導入も両方とも、呼処理ソフトウェア全
体を変えずに行うことができ、呼処理ソフトウェアを機
能インタラクションに依存せずに開発することができ
る。なお、用語”テーブル”はここでは論理的な意味で
用いられており実現手段の意味で用いているわけではな
い。

【００２７】図７には、機能インタラクションアルゴリ
ズムのフローチャートが示されている。このアルゴリズ
ムは、ａ）管理可能なデータテーブルおよびビットマッ
プに基づいて個々のトリガポイントにおいていずれの機
能がトリガ可能であるかを判定するステップと、ｂ）目
下アクティブである機能に基づいて個々のトリガポイン
トでトリガ可能な機能を阻止するステップと、ｃ）トリ
ガする機能が存在するかぎりアルゴリズムの実行を続け
（つまり個々のトリガポイントにおけるすべての付加的
な機能のためにアルゴリズムの実行を続け）、最も優先
度の高い機能をトリガし、新たにトリガされた機能に基
づき個々のトリガポイントにおいてさらにトリガ可能な
機能を阻止するステップから成る。第１のステップによ
り、特定のトリガポイントでトリガを要求する候補機能
が決定される。候補機能には、交換ネットワーク１１に
より与えられトリガポイントテーブルに記憶されている
機能と、加入者により申し込まれ加入者ビットマップに
記憶されている機能と、交換ネットワーク１１により与
えられ持続的な機能テーブルに記憶されている機能が含
まれる。さらに候補機能には、アクセスコード（たとえ
ば呼転送励起）を介して加入者により要求される機能を
含ませることができる。第２のステップにおいて、目下
のアクティブな機能によってブロックされていない場合
にのみ、機能のトリガを許可する。この第１および第２
のステップは、システム１０の最新のフォーマッティン
グにより形成された優先順位で許可された機能をトリガ
する。新たにトリガされた各機能はその他の機能を阻止
できるので、第３のステップで別の機能のトリガが発生
する前に、その固有の阻止特性が考慮される。第３のス
テップにより、ただ１つのトリガポイントにおいて多数
の機能をトリガすることが許可される。

【００２８】データテーブルは機能インタラクションカ
テゴリーとトリガポイントを表わしている。呼処理シス
テム１０は、すべての形式の呼処理機能インタラクショ
ンを規定するために、機能カテゴリーの小さい集合を用
いる。たとえば第１のカテゴリーは阻止インタラクショ
ンを有することができ、この場合、アクティブな機能は
他の機能が励起されるのを阻止する。たとえば９１１呼
び出し中、呼待機サービス機能は禁止される（つまり呼
待機音は発生されない）か、またはそのフラッシュは認
識されない。第２のカテゴリーは優先インタラクション
を有することができ、この場合、第１の機能は励起時、
第２の機能の励起よりも優先され、たとえば受付監視キ
ャンプオンは呼待機終了変数よりも優先される。機能イ
ンタラクションの第３のカテゴリーは、特有の機能ソフ
トウェアを要求するインタラクションを有することがで
き、この場合このインタラクションを処理するために、
機能特有のソフトウェアまたはＩＮサービスロジックプ
ログラム（ＳＬＰ）が要求される。このカテゴリーの実
例は、マルチパーティコールがアクティブであるときに
受付監視強制割込みが拒否されたことを受付監視コンソ
ールディスプレイにおいて表示することができる。な
お、最初の２つのインタラクションカテゴリーは、機能
インタラクションアルゴリズムにより実行されるべきで
あり、したがってテーブル表示が必要とされる。それと
いうのは各々は基本呼処理に影響を与えるからである。
これとは対照に、第３のインタラクションカテゴリーは
基本呼処理に影響を与えない。それというのはこのカテ
ゴリーは、顧客特有の機能ソフトウェアまたはＩＮ Ｓ
ＬＰにおいて、最良に配置されているロジックを規定し
ているからであり、したがってアルゴリズムにより実行
されず、テーブル表示は必要とされない。

【００２９】図８には、阻止および優先インタラクショ
ンカテゴリーの各々のための管理可能な第１のデータテ
ーブルの基本レイアウトが示されている。この図面に示
されているように、このテーブルの水平軸（ないし行）
と垂直軸（ないし列）の両方は、優先度により順序づけ
られた機能を表わしている。システム１０において利用
可能な機能の優先度は通常、システム１０のパラメータ
の最新のフォーマッティング中に形成されるがいつでも
変更できる。機能優先度は、第１および第２の機能の両
方がいっしょにトリガされたときにいずれの機能を優先
するのかの判定により得られる。多くの事例の場合、機
能は相互に作用し合わないので、機能順位は重要ではな
い（たとえば３ウェイコーリングおよびスピードコーリ
ング）。阻止インタラクションテーブルにおいてテーブ
ルエントリは、水平方向の個々の機能が目下アクティブ
であるときに垂直方向の機能を阻止するか否かの判定に
より配置される。優先インタラクションテーブルにおい
てテーブルエントリは、水平方向の個々の機能が新たに
励起されたときに垂直方向の機能を阻止するか否かの判
定により配置される。

【００３０】図９には、トリガポイントを表わす管理可
能な第２のテーブルの基本レイアウトが示されている。
トリガポイントテーブルは各トリガポイントごとに、特
有の機能がトリガされるときにチェックおよび動作を行
うことを要求する機能を規定する。このテーブルの垂直
軸は内部トリガポイントアイデンティティ（たとえばト
リガポイント１＝オフフック事象、トリガポイント２＝
フックフラッシュ等）を表わしているのに対し、水平軸
は機能を表わしている。機能は上述のように優先度によ
り順序づけられている。テーブルエントリは、機能がト
リガポイントにおいてチェックを要求しているか否か、
およびトリガされたときにその機能により動作が要求さ
れている否かの判定により配置されている。なお、すべ
てのテーブルエントリ（および後述のビットマップエン
トリ）は、それらは通常、システム１０のパラメータの
最新のフォーマッティング中に形成されるにしても、い
つでも変更できる。

【００３１】機能がトリガされるとただちに、テーブル
により要求される動作が機能インタラクションアルゴリ
ズムにより管理される。この種の動作の実例には以下の
ことが含まれる。すなわち、 ａ）機能ソフトウェア実行：特有の機能ソフトウェアが
実行される。

【００３２】ｂ）アクティブな機能阻止テーブルエント
リ適用：トリガされた機能はその阻止属性をマスタビッ
トマップに適用し、トリガポイントにおいて選択的な機
能がトリガされないように阻止する。

【００３３】ｃ）機能対象に信号を送信：目下の信号
（たとえばフックフラッシュ）は事前に呼び出された機
能ソフトウェアへ送信される。

【００３４】ｄ）加入者トリガポイント修正：これによ
り機能が後のトリガポイントを修正するのが許可され、
その際に機能を励起または停止する。これは、加入者Ａ
側の機能が加入者Ｂ側のトリガポイントをトリガし変更
した場合に発生し得る（たとえばダイアル呼待機であり
ここにおいて発呼加入者Ａは一時的に呼待機を被呼加入
者Ｂのトリガポイントに加える。

【００３５】ｅ）他の対象へメッセージを送信：予め定
められたメッセージが他の対象へ送信される。たとえば
ＤＴＭＦ妨害により、妨害の記録および／または保守表
示のために送信されるメッセージが要求される。

【００３６】ｆ）データ出力：メッセージがディスプレ
イスクリーンへ送信される。

【００３７】さらに別の動作を規定して加えてもよく、
あるいは既存の動作をいつでも変更できる。なお多くの
事例の場合、動作によっても機能ソフトウェアが呼び出
されたり相互作用し合うことはなく、むしろ一般的な動
作は基本呼ソフトウェアにより実行される。また、いく
つかの動作により基本呼ソフトウェアが増強される。そ
れというのはいくつかの機能は単に、呼機能ソフトウェ
アの必要のない動作により実現し得るからである。

【００３８】データビットマップは加入者／ネットワー
クの性能を表わす。図１０には、機能インタラクション
アルゴリズムにより使用される管理可能なデータビット
マップの基本レイアウトが示されている。データビット
マップは１×Ｎ個のサイズを有しており、この場合、上
述のデータテーブルの１つの行と同様に、Ｎは（上述の
ようにして形成された）優先順に機能番号を表わしてい
る。データビットマップは、特定の呼に対する目下の機
能状態を保持する過渡的なビットマップである。データ
ビットマップは一般的に、呼の開始時点で初期設定さ
れ、機能状態が変化すると更新される。第１のビットマ
ップつまり加入者機能ビットマップは、加入者が自身の
ラインに割り当てた機能を表わす。この加入者機能ビッ
トマップは、固定的な加入者データに基づき呼の開始時
点で配置され、ひとたび個々の加入者データベースから
読み出されると変化しない。第２のデータビットマップ
つまり持続的機能ビットマップは、トリガされると他の
関連のトリガポイントを励起する永続的な機能を表わし
ている。一般に、持続的機能は発呼加入者Ａにより要求
され、ひとたび要求されれば、呼が終了したときに、た
とえば呼待機（ＣＷ）、受付監視緊急優先（ＡＥＯ）等
のときに、呼チェインの被呼加入者Ｂ側においてトリガ
される。第２のトリガポイントは持続的機能トリガと称
する。なお、持続的機能ビットマップは、関連の機能が
アクセスされたときだけ初期設定されて使用される。

【００３９】機能インタラクションアルゴリズムによ
り、このアルゴリズムステップを実施するために、デー
タテーブルおよびデータビットマップのエントリにおけ
る２つの形式のデータ演算が実行される。まず最初にこ
のアルゴリズムは、ＡＮＤ、ＯＲおよびＸＯＲ（すなわ
ち排他ＯＲ）を含むビットマップ論理演算を実行する。
これらの演算はテーブルの行とビットマップとの間で可
能である。それというのはこのテーブルとビットマップ
は、優先順の機能を表わす１つの共通の次元を有してい
るからである。ビットマップ論理演算の結果、新たなビ
ットマップが生じ、（図中シンボル”Ｙ”の付された）
各”セット”ビットは、演算条件をパスした機能を表わ
す。論理演算の後、残存している”セット”ビットが識
別され、トリガされる機能に関連付けられる。これを達
成するために、このアルゴリズムはビットマップサーチ
動作を行って、”セット”ビットのためのビットマップ
をサーチし、それらの相対的なビット位置を識別する。
機能は優先度にしたがって順序づけられているので、最
上位ビットから最下位ビットへのアルゴリズムによるサ
ーチを行った結果、優先度にしたがって順序づけられた
識別が行われる。

【００４０】図１１〜図１９には、機能インタラクショ
ンアルゴリズムの動作の一例として、データテーブル、
データビットマップ、ならびに受付監視緊急優先（ＡＥ
Ｏ）、ドゥーノットディスターブ（ＤＮＤ）、呼転送
（ＣＦ）および呼待機（ＣＷ）の機能間のインタラクシ
ョンのためのアルゴリズムにより用いられる論理演算が
示されている。ＡＥＯ機能により、受付監視は目下呼に
より占有されている被呼加入者Ｂに対して呼び出しを行
うことができ、通常は呼を終了させる加入者機能よりも
優先される。このＡＥＯ機能は過渡的な機能であって、
これはまず、作業員がＡＥＯアクセスコードをダイアル
すると、呼チェインの発呼加入者Ａ側においてトリガさ
れ、次に、加入者Ｂ側における呼終了に基づきトリガさ
れ、この時点でこの機能は所定の申し込まれた機能より
も優先される。図面には、２番目のトリガ条件に関する
アルゴリズム動作だけが示されている。

【００４１】この実例における初期条件は、呼により占
有されておりＤＮＤ、ＣＦおよびＣＷを申し込む加入者
Ｂである。また、ＡＥＯは、呼チェインの加入者Ｂ側に
おける”加入者ビジー”トリガポイントで過渡的なトリ
ガ条件を有するようにフォーマットされている。この動
作の場合、操作員は加入者Ｂの番号とＡＥＯアクセスコ
ードをダイアルする。図１１には、呼チェインの加入者
Ａ側（つまり受付監視側）が示されており、これは基本
呼チェインと同様であり、さらに、ＡＥＯアクセスコー
ドのダイアリングにより生じる第１のトリガ条件が加え
られている。ＡＥＯアクセスコードは、機能を規定し特
定のトリガポイントを要求するメッセージとして基本呼
ソフトウェアへ伝送される。基本呼ソフトウェアの機能
インタラクションアルゴリズムは指定されたトリガポイ
ントにおいて実行され、トリガを決定するために（図示
されていない）機能インタラクションデータに基づき動
作する。この決定によりアルゴリズムは、ＡＥＯ機能セ
グメントを呼チェインとリンクさせる。なお、セグメン
トの動作および呼チェインのマネージャは、機能トリガ
によっても影響を受けない。

【００４２】図１２には、呼チェインの加入者Ｂ側
と、”加入者ビジー”トリガポイントにおける過渡的な
トリガ条件が示されている。この呼チェインは基本呼チ
ェインと同様であり、さらに、アルゴリズムによる最初
のトリガ決定により生じる過渡的なトリガ条件（つまり
ＡＥＯ ＦＳ）が加えられている。このトリガポイント
において、基本呼ソフトウェアは再び、ＡＥＯ機能のト
リガおよびインタラクションを処理するために、機能イ
ンタラクションアルゴリズムを利用する。

【００４３】図１３には、第１のステップ中にアルゴリ
ズムにより行われる論理演算が示されている。この第１
のステップは、トリガポイントテーブル、加入者ビット
マップおよび過渡的機能ビットマップに基づいて、この
ポイントでどの機能をトリガできるかを判定する。まず
はじめに、このアルゴリズムは、（図１９に示され
た）”加入者ビジー”トリガポイントのためのトリガポ
イントテーブルと（図１７に示された）被呼加入者Ｂの
ための加入者ビットマップの個々の行エントリを検索す
る。なお、このテーブルおよびビットマップの（”Ｙ”
として示された）セットビットは、相応の機能が利用可
能であることを示している。次に、このアルゴリズム
は、２つのデータセットにおいてＡＮＤ演算を実施す
る。図示されていないが中間ビットマップの結果はＮＹ
ＹＹである。これは、ネットワーク１１により与えられ
た機能と発呼加入者Ｂにより申し込まれた機能に共通の
機能を表わしている。なお、図１６には、この実施例で
は呼プロセッサ２０内で形成され、データテーブルおよ
びデータビットマップにより用いられる機能優先度が示
されている。次に、このアルゴリズムは、ＡＥＯ機能の
ための過渡的機能ビットマップを検索し、中間ビットマ
ップ結果とのＯＲ演算を実施する。第１のステップの論
理演算後に生じたビットマップは、”加入者ビジー”ト
リガポイントでトリガできる機能を表わしている。この
実施例の場合、生じたビットマップのセットビットは、
各機能（つまりＡＥＯ、ＤＮＤ、ＣＦ、ＣＷ）がトリガ
可能であることを表わしている。なおＤＮＤ、ＣＷおよ
びＣＦは被呼加入者Ｂにより、たとえば端末のフックフ
ラッシュによってトリガできる。また、ほとんどの呼
は、候補機能を決定するためにすべてのデータビットマ
ップをチェックする必要はない。つまり必要とされるチ
ェックは、過渡的な機能がアクティブであるか否か、ま
たはいずれのトリガポイントで使用されているかに基づ
いてなされるだけである。

【００４４】図１４には、第２のステップ中にアルゴリ
ズムにより実施される論理演算が示されている。この第
２のステップは、目下アクティブな機能に基づいて、ト
リガ可能である機能たとえばＡＥＯ機能を阻止する。こ
のアルゴリズムは、（図１８に示された）トリガされた
機能の阻止テーブルを検索し、アクティブな各機能に対
して、第１のステップで生じたビットマップと、アクテ
ィブな機能に対する阻止テーブルの行との間でＡＮＤ演
算を実施する。この実施例の場合、アルゴリズムは演算
を実施しない。それというのは初期条件のとおり被呼加
入者Ｂのライン上には目下アクティブな機能を存在しな
いからである。したがって第１のステップにより生じた
ビットマップは変化しない。しかしここで言及しておく
と、トリガされた機能阻止テーブルに示されていること
は、目下アクティブとなり得るであろういかなる機能に
よっても、つまりＤＮＤ、ＣＷ、ＣＦによっても、いか
なる場合であってもＡＥＯ機能は阻止されないことであ
る（たとえばＣＦがアクティブであったなら、第１のス
テップにより生じたビットマップＹＹＹＹと阻止テーブ
ルのＣＦの行ＹＹＮＮとの間のＡＮＤ演算により、結果
としてビットマップＹＹＮＮが生じ、これはＡＥＯが阻
止されないことを表わしている）。第２のステップの論
理演算後に生じたビットマップは、加入者ビジートリガ
ポイントにおいてトリガでき阻止されない機能を表わし
ている。

【００４５】図１５には、トリガされるべきいかなる付
加的な機能のためのトリガポイントでも実行を継続する
ために、第３のステップ中にアルゴリズムにより実行さ
れる論理演算が示されている。このアルゴリズムはまず
はじめに、第２のステップにより生じたビットマップの
最上位セットビットを決定するために、ビットマップサ
ーチを遂行する。この実施例の場合、第１のビットつま
りＡＥＯは、最上位セットビットである。なお、結果と
してセットされることないサーチは、つまりセットビッ
トの生じないサーチは、このトリガポイントにおいてト
リガされる別の機能が存在しないことを表わす。次にこ
のアルゴリズムは、最高優先度の機能つまり最上位セッ
トビットにより表わされるＡＥＯ機能のトリガを行う。
これを達成するためにこのアルゴリズムは、（図１９に
示された）ＡＥＯ機能のためのトリガポイントテーブル
の行エントリを検索して、要求された機能開始動作を実
施する。この実施例の場合、ＡＥＯのための機能開始動
作はアクション１であって、これはこのアルゴリズムが
被呼加入者Ｂに対する終了を制御するＡＥＯ機能ソフト
ウェアをトリガするためのものあることを意味する。な
お、開始動作はシステム１０における最新のフォーマッ
ティング中に行われ、前述のように結果として機能の呼
び出しが生じなくてもよい。

【００４６】次にこのアルゴリズムは、新たにトリガさ
れた機能（つまりＡＥＯ）に基づいてトリガし得る機能
（つまりＤＮＤ、ＣＦ、ＣＷ）の阻止を行う。このアル
ゴリズムは、（図１８に示された）トリガされた機能阻
止テーブルからのトリガされた機能（つまりＡＥＯ）の
行エントリを検索し、第２のステップから生じたビット
マップとのＡＮＤ演算を実施する。新たに生じたビット
マップは、このトリガポイントで依然としてトリガ可能
である機能を表わす。この実施例の場合、新たに生じた
ビットマップはセットビットを有していない。したがっ
てＡＥＯ機能は他のすべての機能がトリガしないように
阻止しており、いかなる他の機能のトリガも要求されな
い。新たに生じたビットマップがセットビットを有して
いるのであればこのアルゴリズムは、トリガされるべき
いかなる機能も残らなくなるまで（つまり生じたビット
マップ中にセットビットがなくなるまで）優先順に他の
機能をトリガする第３のステップの反復を行う。

【００４７】すべての機能のトリガの決定に応じて、ア
ルゴリズムはＡＥＯ ＦＳ（および多数の機能をトリガ
する場合にはこのトリガポイントでトリガ可能な機能の
ＦＳのすべて）を呼チェインとリンクさせる。その結
果、呼チェインは、次のトリガポイント（この場合には
アルゴリズムがもう１度実施される）または呼終了まで
その動作を継続する。

【００４８】機能インタラクションアルゴリズムおよび
データテーブルならびにビットマップにより、基本ソフ
トウェアに影響を及ぼすことなく呼チェインにおいて機
能インタラクションを管理するプロセッサ２０のための
管理可能な手法が提供される。ＩＮ形式のネットワーク
は同じ目的を有しているが、サービス制御ポイント（Ｓ
ＣＰ）において交換機外に配置することのできる別の要
求を有する。交換機ベースの機能とＳＣＰベースの機能
との間のインタラクションは、やはり上述の機能インタ
ラクションアルゴリズムを用いてアドレス指定できる。

【００４９】これを達成するために、ＳＣＰは全体とし
て、未知のまま残されている個々のＳＣＰ機能とともに
システム１０の機能優先リストに加えられる。ＳＣＰ
は、その機能が交換機ベースの機能とどのように相互に
作用し合うかに依存して、１つまたは複数個の場所に加
えることができる。ＳＣＰ自体は、２つのＳＣＰ間のイ
ンタラクションを決定する。そして関連するＳＣＰデー
タは、関連するトリガポイントおよび機能阻止要求を表
わす機能インタラクションテーブルの各々に加えられ
る。これは、交換機ベースの新たなソフトウェアを必要
としない管理ステップである。関連のＳＣＰデータ中に
は（トリガポイントテーブルに加えられた）新たなアク
ションが含まれ、これは、たとえば実行されるべきＳＣ
Ｐ機能を要求するトリガポイントにおいてＳＣＰへ送信
されるべきメッセージを送る。したがって機能インタラ
クションアルゴリズムを用いることにより、交換機ベー
スの機能とＳＣＰ機能は、一方よりも高い優先度の与え
られた他方の機能を強要することなく、互いに柔軟に作
用し合うことができる。

【００５０】（システムおよび加入者ライン特性を規定
する）ネットワークの管理動作は呼処理と類似してお
り、適切に定められたポイントにおいてやはり管理ソフ
トウェアが機能ソフトウェアと相互に作用し合う。一般
的に、１つのトリガポイントしか要求されず、これは加
入者ライン特性が変えられたか付加されたときに発生す
る。このトリガポイントにおいて、割り当てられるべき
機能と割り当てられたすべての加入者機能がいっしょに
許可されているかを照合するためにデータをチェックす
る必要がある。

【００５１】呼処理システムと同様に、管理システム
は、割り当てられるべき機能のトリガおよびソフトウェ
アとのインタラクションを決定するために、管理ソフト
ウェア内の機能インタラクションアルゴリズムを利用で
きる。このアルゴリズムはトリガポイントで実行され、
システムのためのデータベースに記憶されたテーブルお
よびビットマップフォーマット内に配置された機能イン
タラクションデータに応じて動作する。そして機能トリ
ガの決定に応じて、このアルゴリズムは機能ソフトウェ
アと管理ソフトウェアとのインタラクションを指示す
る。

【００５２】図２０には、システム１０の管理ソフトウ
ェアにより用いられる機能インタラクションアルゴリズ
ムのフローチャートが示されている。このアルゴリズム
は以下のステップを有する。すなわち、 ａ）割り当てられた加入者機能に基づき阻止された機能
を決定する。

【００５３】ｂ）割り当てられるべき新たな機能が阻止
されているか否かをチェックする（もし阻止されていれ
ば割り当て要求を拒否する）。

【００５４】ｃ）いずれの機能がラインに割り当てられ
た他の機能をまず最初に要求したかを決定する。

【００５５】ｄ）割り当てられるべき新たな機能が阻止
されているか否かをチェックする（もし阻止されていれ
ば割り当て要求を拒否する）。

【００５６】第１および第２のステップは、すでに１つ
のラインに割り当てられている機能のためにいずれの機
能がブロックされているか否かを決定する。これらのス
テップは、たとえばすでに９１１に割り当てられている
ラインに呼待機を割り当てるような要求を阻止する。第
３および第４のステップは、いずれの機能がラインに割
り当てられている他の機能をまずはじめに要求するかを
決定する。たとえばこれらのステップは、メークビジー
機能がラインに割り当てられる前に呼転送禁止メークビ
ジーを割り当てるような要求を阻止する。

【００５７】管理機能インタラクションアルゴリズム
は、データテーブル、データビットマップおよびデータ
演算を利用し、これらは上述の呼処理アルゴリズムによ
り使用されたものと同様のものであり、それらを同じよ
うにして利用する。たとえば管理機能インタラクション
アルゴリズムは、管理可能な２つのテーブル、阻止化管
理テーブル、および相互包括管理テーブルを利用する。
これらのテーブルの基本レイアウトは（上述の）図８に
示されている。ここにおいてテーブルの両方の水平軸
（または行）および垂直軸（または列）は優先度により
順序づけられた機能を表わしている。呼処理インタラク
ションの場合のように、システム１０内で利用可能な機
能の優先度は通常、システム１０のパラメータの最新の
フォーマッティング中に形成されるが、これはいつでも
変更できる。これに加えて、機能優先度は、第１の機能
と第２の機能の両方がいっしょにトリガされた場合に、
いずれの機能を優先させるかを決定することにより得ら
れる。多くの場合、機能は相互に作用し合わないので、
機能順位は重要ではない。

【００５８】（割り当てられた機能のための）阻止化管
理テーブルの場合、テーブルエントリは、個々の水平方
向の機能がすでにラインに割り当てられているときに垂
直方向の機能が加入者ラインに割り当てられないように
阻止されるか否かの判定により配置される。相互包括管
理テーブルの場合、テーブルエントリは、個々の水平方
向の機能がラインに割り当てられてしまう前に垂直方向
の機能をまずはじめに加入者ラインに割り当ている必要
があるか否かの判定により配置される。

【００５９】管理機能インタラクションアルゴリズム
も、図１０に示した既述のような基本レイアウトを有す
るデータビットマップを用いる。このデータビットマッ
プは、（上述の）加入者機能ビットマップと機能可能ビ
ットマップを有する。機能可能ビットマップは、システ
ム１０に利用でき、すべてがセットビットを有するよう
に初期設定される、つまりすべてのビットが’Ｙ’にセ
ットされる機能を表わす。結局、管理機能インタラクシ
ョンアルゴリズムもアルゴリズムステップを実施するた
めに、データテーブルとデータビットマップのエントリ
においてデータ演算を行う（つまりビットマップ論理演
算およびビットマップ検索を行う）。

【００６０】図２１〜図２７には、この管理ソフトウェ
アにより用いられる機能インタラクションアルゴリズム
の動作、データテーブル、データビットマップおよびデ
ータ演算の実例が示されている。この管理ソフトウェア
の動作中、加入者ライン特性が変更されるように要求さ
れると、たとえば新しい機能がこのラインに付加される
（または割り当てられる）ように要求されると、アルゴ
リズムのステップが実施される。このトリガポイントに
おいてこのアルゴリズムは第１のステップとして、加入
者機能ビットマップ、阻止化管理テーブルおよび機能可
能ビットマップを検索する。図面に示された実例の場
合、このトリガポイントにおいて（つまり管理ソフトウ
ェア実行中の要求ポイントにおいて）、呼転送禁止メー
クビジー（ＣＦＩＭＢ）機能が加入者ラインに割り当て
られるように要求される。

【００６１】図２１には、システム１０により与えられ
た呼機能の優先順位が示されており、図２２には、機能
可能ビットマップにおける（優先番号により示された）
呼機能の順序づけられた配置が示されている。図２３に
は加入者機能ビットマップが示されており、このビット
マップは、加入者ラインがすでに呼転送変数（ＣＦＶ）
機能に割り当てられていることを表わしている。さらに
図２４には、呼機能のための阻止化管理テーブルが示さ
れている。加入者機能ビットマップ中で割り当てられた
各機能に対し（図示された実例ではＣＦＶに対しての
み）、残された２つのデータセットにおいて、つまり割
り当てられた機能に対する阻止化管理テーブルと機能可
能ビットマップの個々の行エントリにおいて、このアル
ゴリズムはＡＮＤ演算を実施する。これにより得られた
ビットマップの’Ｎ’にセットされたビットは、ライン
上ですでに割り当てられている機能のために加入者ライ
ンにおいて許可されない機能を表わしている。図２５に
は、この実例に関するＡＮＤ演算とこれにより生じたビ
ットマップが示されている。

【００６２】第２のステップ中、このアルゴリズムは、
割り当てられるべき新たな機能のビット位置に関して第
１のステップにより得られたビットマップを検査する。
新たな機能のビット位置が’Ｎ’にセットされているな
らば、この機能は許可されず、この機能をラインに割り
当ていることはできない。このような場合、管理ソフト
ウェアはこのラインに新たな機能を割り当てようとする
要求を拒否し、アルゴリズムの実行を中止する。新たな
機能のビット位置が’Ｙ’にセットされているならば、
この機能は許可されるものであり、このラインに割り当
てることができる。したがってアルゴリズムはその実行
を続ける。

【００６３】図示された実例の場合、アルゴリズムは、
ＣＦＩＭＢ呼機能を表わすビット位置７を検査する。こ
のビット位置は’Ｙ’にセットされており、これはこの
機能は他の呼機能によっても阻止されず、したがって許
可されるものでありラインに割り当て可能である。その
結果、管理ソフトウェアは、この時点においてラインに
ＣＦＩＭＢ呼機能を割り当てようとする要求を受け付
け、アルゴリズムの実行を続ける。

【００６４】第３のステップ中、アルゴリズムは、加入
者機能ビットマップと、管理相互包括テーブルの新たな
機能に対する個々の行エントリを検索する。図２６に
は、呼機能のための相互包括管理テーブルが示されてい
る。アルゴリズムはまずはじめに、２つのデータセット
においてＡＮＤ演算を実行し、次に、ＡＮＤ演算により
得られたビットマップと相互包括管理テーブルの同じ行
において排他ＯＲ（ＸＯＲ）演算を実行する。図２７に
は、この実例に関するＡＮＤ演算、ＸＯＲ演算、および
これにより生じたビットマップが示されている。

【００６５】第４のステップ中、アルゴリズムは、第３
のステップにより得られたビットマップをセットビット
に関して検査する。得られたビットマップがいくつかの
セットビットを有しているならば、新たな機能をライン
に割り当てることはできない。なぜならばセットビット
で示されたこれらの機能は要求されているけれども利用
不可能であり、あるいは他のラインに対して目下割り当
てられているからである。したがって管理ソフトウェア
は、このラインに対してこの新たな機能を割り当てよう
とする要求を拒否し、次のトリガポイントまで通常の手
法でその動作を続ける。得られたビットマップがセット
ビットを有してないならば（つまりセットが存在しなけ
れば）、このラインに対して新たな機能を割り当てるこ
とができる。したがってアルゴリズムは、個々の機能ソ
フトウェアと管理ソフトウェアとのリンクを指示し、そ
してこの管理ソフトウェアは、次のトリガ事象まで通常
の手法でその動作を続ける。

【００６６】図示された実施例の場合、このアルゴリズ
ムは、第３のステップにより得られたビットマップを検
査し、メークビジーキー（ＭＢＫ）呼機能を表わすビッ
ト位置８がセットビットがセットビットを有しているこ
とを（つまり’Ｙ’にセットされていることを）見つけ
る。このため新たな機能ＣＦＩＭＢをラインに割り当て
ることはできない。なぜならばセットビットで表わされ
たＭＢＫ機能は要求されているが利用不可能であり、あ
るいは別のラインに目下割り当てられているからであ
る。その結果、管理ソフトウェアは、このラインにＣＦ
ＩＭＢ呼機能を割り当てようとする要求を拒否し、次の
トリガポイントまでその動作を続ける。なお、この管理
ソフトウェアは通常、ラインに対し新たな機能を割り当
てるための要求のすべての拒否および受諾をシステムに
完全に通報するように構成されている。

【００６７】トリガポイントにおいてラインに割り当て
るべく要求される新たな機能が複数存在する場合、個々
のステップで受諾された要求に対してはアルゴリズムの
動作を続け、個々のステップで拒否された要求に対して
はその動作を中止するように、各ステップにおいて機能
要求の各々を検査するようにアルゴリズムを構成するこ
とができる。また、これに対する代案として、新たな機
能要求のすべてが検査されるまで、先行の新たな機能要
求が拒否されようと最終的に受諾されようと、その動作
全体を繰り返すようにアルゴリズムを構成することがで
きる。

【００６８】既述の実施形態は、本発明の基本原理を例
示しただけである。本発明の枠ないし趣旨を逸脱するこ
となく、当業者はこれに対して種々の変形を行うことが
できる。たとえば、アルゴリズムは無制限の個数の機能
を処理することができ、さらにデータテーブルおよびビ
ットマップはいかなるサイズのものであってもよい。ま
た、ここで言及したようにいくつかの機能はアルゴリズ
ムを介して実施される必要はないのであるが、アルゴリ
ズムはいかなる形式の機能を処理することもできる。

【００６９】また、アルゴリズムおよびデータテーブル
ならびにビットマップは、機能がどのように相互に作用
し合うかを規定する標準の形式（アメリカ合衆国標準規
格のためのＬＳＳＧＲおよび世界市場標準規格のための
ＣＣＩＴＴ）に限定されるものではない。また、アルゴ
リズムおよびデータテーブルならびにビットマップはい
かなる呼処理モデルにも適用でき、それらは物理的な交
換システムの形式に依存しない。

【００７０】

【発明の効果】本発明により、呼処理動作と管理動作の
両方のための機能インタラクションの決定においていっ
そう柔軟な呼処理システムが提供される。

【図面の簡単な説明】

【図１】本発明の呼処理システムのブロック図であり、
２つの加入者Ａ、Ｂ間の呼経路が形成されている。

【図２】図１のシステムのプロセッサにより作動される
呼処理ソフトウェアの構造を示すブロック図である。

【図３】図１のシステムのプロセッサにより作動される
呼処理ソフトウェアの構造を図３よりも詳細に示すブロ
ック図である。

【図４】図１のシステムのプロセッサにより作動される
基本呼ソフトウェアの呼制御システムのブロック図であ
る。

【図５】機能ソフトウェアを要求しない基本呼のための
セグメントチェインのブロック図である。

【図６】１つの機能を供給する呼のためのセグメントチ
ェインのブロック図である。

【図７】プロセッサの機能インタラクションソフトウェ
アにより用いられる機能インタラクションアルゴリズム
のフローチャートである。

【図８】機能インタラクションの阻止および優先のため
の、プロセッサの機能インタラクションソフトウェアに
より用いられる第１の管理可能なテーブルの基本レイア
ウト図である。

【図９】トリガポイントを表わす、プロセッサの機能イ
ンタラクションソフトウェアにより用いられる第２の管
理可能なテーブルの基本レイアウト図である。

【図１０】プロセッサの機能インタラクションソフトウ
ェアにより用いられるビットマップの基本レイアウト図
である。

【図１１】受付監視緊急優先（ＡＥＯ）、ドゥ−ノット
ディスターブ（ＤＮＤ）、呼転送（ＣＦ）および呼待機
（ＣＷ）の各機能間のインタラクションのための、図７
の機能インタラクションアルゴリズムの実例を示す図で
ある。

【図１２】受付監視緊急優先（ＡＥＯ）、ドゥ−ノット
ディスターブ（ＤＮＤ）、呼転送（ＣＦ）および呼待機
（ＣＷ）の各機能間のインタラクションのための、図７
の機能インタラクションアルゴリズムの実例を示す図で
ある。

【図１３】受付監視緊急優先（ＡＥＯ）、ドゥ−ノット
ディスターブ（ＤＮＤ）、呼転送（ＣＦ）および呼待機
（ＣＷ）の各機能間のインタラクションのための、図７
の機能インタラクションアルゴリズムの実例を示す図で
ある。

【図１４】受付監視緊急優先（ＡＥＯ）、ドゥ−ノット
ディスターブ（ＤＮＤ）、呼転送（ＣＦ）および呼待機
（ＣＷ）の各機能間のインタラクションのための、図７
の機能インタラクションアルゴリズムの実例を示す図で
ある。

【図１５】受付監視緊急優先（ＡＥＯ）、ドゥ−ノット
ディスターブ（ＤＮＤ）、呼転送（ＣＦ）および呼待機
（ＣＷ）の各機能間のインタラクションのための、図７
の機能インタラクションアルゴリズムの実例を示す図で
ある。

【図１６】受付監視緊急優先（ＡＥＯ）、ドゥ−ノット
ディスターブ（ＤＮＤ）、呼転送（ＣＦ）および呼待機
（ＣＷ）の各機能間のインタラクションのための、図７
の機能インタラクションアルゴリズムの実例を示す図で
ある。

【図１７】受付監視緊急優先（ＡＥＯ）、ドゥ−ノット
ディスターブ（ＤＮＤ）、呼転送（ＣＦ）および呼待機
（ＣＷ）の各機能間のインタラクションのための、図７
の機能インタラクションアルゴリズムの実例を示す図で
ある。

【図１８】受付監視緊急優先（ＡＥＯ）、ドゥ−ノット
ディスターブ（ＤＮＤ）、呼転送（ＣＦ）および呼待機
（ＣＷ）の各機能間のインタラクションのための、図７
の機能インタラクションアルゴリズムの実例を示す図で
ある。

【図１９】受付監視緊急優先（ＡＥＯ）、ドゥ−ノット
ディスターブ（ＤＮＤ）、呼転送（ＣＦ）および呼待機
（ＣＷ）の各機能間のインタラクションのための、図７
の機能インタラクションアルゴリズムの実例を示す図で
ある。

【図２０】システムの管理ソフトウェアにより用いられ
る機能インタラクションアルゴリズムのフローチャート
である。

【図２１】呼転送禁止メークビジー（ＣＦＩＭＢ）、メ
ークビジーキー（ＭＢＫ）および呼転送変数（ＣＦＶ）
の各機能間のインタラクションのための図２０の機能イ
ンタラクションアルゴリズムの実例を示す図である。

【図２２】呼転送禁止メークビジー（ＣＦＩＭＢ）、メ
ークビジーキー（ＭＢＫ）および呼転送変数（ＣＦＶ）
の各機能間のインタラクションのための図２０の機能イ
ンタラクションアルゴリズムの実例を示す図である。

【図２３】呼転送禁止メークビジー（ＣＦＩＭＢ）、メ
ークビジーキー（ＭＢＫ）および呼転送変数（ＣＦＶ）
の各機能間のインタラクションのための図２０の機能イ
ンタラクションアルゴリズムの実例を示す図である。

【図２４】呼転送禁止メークビジー（ＣＦＩＭＢ）、メ
ークビジーキー（ＭＢＫ）および呼転送変数（ＣＦＶ）
の各機能間のインタラクションのための図２０の機能イ
ンタラクションアルゴリズムの実例を示す図である。

【図２５】呼転送禁止メークビジー（ＣＦＩＭＢ）、メ
ークビジーキー（ＭＢＫ）および呼転送変数（ＣＦＶ）
の各機能間のインタラクションのための図２０の機能イ
ンタラクションアルゴリズムの実例を示す図である。

【図２６】呼転送禁止メークビジー（ＣＦＩＭＢ）、メ
ークビジーキー（ＭＢＫ）および呼転送変数（ＣＦＶ）
の各機能間のインタラクションのための図２０の機能イ
ンタラクションアルゴリズムの実例を示す図である。

【図２７】呼転送禁止メークビジー（ＣＦＩＭＢ）、メ
ークビジーキー（ＭＢＫ）および呼転送変数（ＣＦＶ）
の各機能間のインタラクションのための図２０の機能イ
ンタラクションアルゴリズムの実例を示す図である。

【符号の説明】

１１ 交換ネットワーク １２ 構内交換素子 １３ ＡＴＭ／ＳＴＭインターフェース ２０ 呼プロセッサ

Claims (38)

【特許請求の範囲】
1. 【請求項１】 メインオペレーティングプログラムから
   の夫々のサブルーチンプログラムコールリクエストに応
   じて、プロセッサにより少なくとも１つのサブルーチン
   プログラムをメインオペレーティングプログラムとイン
   タラクションする方法において、 ａ．プロセッサに関するデータをアクセスするステップ
   すなわち、個々のコールリクエスト、個々のコールリク
   エストの要求された各サブルーチンプログラム、および
   プロセッサのユーザによる要求に関するデータをアクセ
   スするステップを有しており、前記データは、プロセッ
   サと組み合わせられたメモリに記憶されており、該メモ
   リ中に管理可能なフォーマットで配置されており、 ｂ．前記プロセッサの、要求されたサブルーチンプログ
   ラムと要求されていないサブルーチンプログラムの間
   で、メインオペレーティングプログラムにより要求され
   た個々のサブルーチンプログラムの起動に対して競合処
   理するステップと、 ｃ．個々のコールリクエストと、前記の競合整理ステッ
   プの結果として起動された要求された個々のサブルーチ
   ンプログラムとに関する記憶されたデータにより示され
   たタスクを、メインオペレーティングプログラムにより
   実行するステップを有することを特徴とする、 サブルーチンプログラムとメインオペレーティングプロ
   グラムとのプロセッサによるインタラクション方法。
2. 【請求項２】 前記の実行ステップにおいて、起動され
   る要求された個々のサブルーチンプログラムの各々を、
   前記の競合整理ステップにより得られた優先順位で、メ
   インオペレーティングプログラムにより実行する、請求
   項１記載の方法。
3. 【請求項３】 前記のアクセスステップおよび競合整理
   ステップは、要求されたサブルーチンプログラムの形式
   に依存せずに実行される、請求項１記載の方法。
4. 【請求項４】 メモリに記憶され該メモリ中に管理可能
   なフォーマットで配置されているデータは、前記実行ス
   テップをカスタマイズできるようにカスタマイズ可能で
   ある、請求項１記載の方法。
5. 【請求項５】 少なくとも１つの要求されるサブルーチ
   ンプログラムは、所定の起動順序で配置された複数個の
   付加的なサブルーチンプログラムを有する、請求項１記
   載の方法。
6. 【請求項６】 少なくとも１つの要求されるサブルーチ
   ンプログラムは、当該方法の競合整理ステップよりも前
   に個々の付加的なサブルーチンプログラムの起動に関す
   る競合整理を受ける複数個の付加的なサブルーチンプロ
   グラムを有する、請求項１記載の方法。
7. 【請求項７】 オペレーティングプログラム実行中の所
   定の時点における、少なくとも１つのサブルーチンプロ
   グラムとオペレーティングプログラムとのインタラクシ
   ョンを呼処理システムにより判定する方法であって、両
   プログラムと、該プログラムおよび所定の時点に関する
   データは、システムのメモリに記憶されている形式の方
   法において、 ａ．前記メモリに記憶されたデータを用いて所定の時点
   で、個々のサブルーチンプログラムを起動する動作を実
   行するステップを有しており、該起動動作は、起動すべ
   きサブルーチンプログラムの形式に依存せず、 ｂ．前記の実行ステップの起動動作のために、前記メモ
   リに記憶されたデータをアクセスするステップを有して
   おり、該データは、個々のサブルーチンプログラムのイ
   ンタラクションをカスタマイズできるように、論理テー
   ブルおよびビットマップのフォーマットで前記メモリ中
   に配置されており、 ｃ．前記プログラムの起動に応じて、個々のサブルーチ
   ンプログラムを実行するステップを有していることを特
   徴とする、 サブルーチンプログラムとオペレーティングプログラム
   とのインタラクションを呼処理システムにより決定する
   方法。
8. 【請求項８】 前記の起動動作実行ステップにおいて、
   データテーブルとデータビットマップのエントリを用い
   てデータ演算を行う、請求項7記載の方法。
9. 【請求項９】 前記の起動動作実行ステップにおいて、
   データテーブルとデータビットマップのエントリを用い
   て、ビットマップ論理演算およびビットマップ検索動作
   を行う、請求項７記載の方法。
10. 【請求項１０】 個々のサブルーチンプログラムを実行
    する前記のステップにおいて、個々のサブルーチンプロ
    グラムの実行のほかに、オペレーティングプログラムに
    よりタスクを実行する、請求項７記載の方法。
11. 【請求項１１】 起動できる複数個のサブルーチンプロ
    グラムの各々に対し、所定の時点においてサブルーチン
    プログラムに関するデータにより決定された順序でステ
    ップａ、ｂおよびｃを反復するステップを有する、請求
    項７記載の方法。
12. 【請求項１２】 前記の起動動作実行ステップにおい
    て、所定の時点における複数個のサブルーチンプログラ
    ムの起動順序を決定し、前記のデータは、サブルーチン
    プログラム間のインタラクションおよび起動優先度を規
    定するものであり、さらに、個々のサブルーチンプログ
    ラムを実行する前記のステップにおいて、起動順序で個
    々のサブルーチンプログラムの各々を実行する、請求項
    ７記載の方法。
13. 【請求項１３】 基本呼プログラムを用いて加入者接続
    動作を管理する呼プロセッサと、基本呼プログラムおよ
    び機能サービスに関するデータを記憶するメモリを有す
    る呼処理システムの加入者間の呼接続のために、少なく
    とも１つの機能サービスを実施する方法において、 ａ．基本呼プログラム実行中、個々のトリガ時点におい
    ていずれの機能サービスがアクセス可能であるかを決定
    するステップと、 ｂ．目下アクセスされている機能サービスに基づいて、
    利用可能な所定の機能サービスが個々のトリガ時点にお
    いてアクセスされないように阻止するステップと、 ｃ．個々のトリガ時点において、システムの最新のフォ
    ーマッティング時に形成された機能サービスのための優
    先順位で、アクセス可能であり阻止されない個々の機能
    サービスの各々をアクセスするステップを有することを
    特徴とする、 機能サービスを実施する方法。
14. 【請求項１４】 前記のアクセスステップにおいて、個
    々のトリガ時点と、アクセス可能であり阻止されない個
    々の機能サービスの各々に関する記憶されたデータによ
    り管理される基本呼プログラムによる動作を、個々のト
    リガ時点で実行し、前記動作は機能サービスの優先順位
    と同じ優先順位で実行される、請求項１３記載の方法。
15. 【請求項１５】 前記のアクセスステップにおいて、ア
    クセス可能であり目下アクセスされている機能サービス
    により阻止されない個々の機能サービスの各々を、個々
    のトリガ時点で機能サービスのための優先順位でアクセ
    スし実行する、請求項１３記載の方法。
16. 【請求項１６】 前記のアクセスステップは、 i. 個々のトリガ時点でアクセス可能である、最高優先
    順位の機能サービスを決定するステップと、 ii. 個々のトリガ時点および最高優先順位の機能サービ
    スに関する記憶されたデータにより管理される基本呼プ
    ログラムによってタスクを実行するステップと、 iii.アクセス可能であり目下アクセスされている機能サ
    ービスによって阻止されない所定の機能サービスが、最
    高優先順位の機能サービスに関する記憶されたデータに
    基づき個々のトリガ時点でアクセスされないように阻止
    するステップと、 iv. 個々のトリガ時点でアクセス可能でありステップ i
    iiの結果として阻止されない機能サービスのうちの残り
    のサービスに対し、優先順位にしたがってステップ i
    、ii、iiiを反復するステップを有する、 請求項１３記載の方法。
17. 【請求項１７】 前記のタスク実行ステップにおいて、
    最高優先順位の機能サービスを基本呼プログラムにより
    アクセスし実行する、請求項１０記載の方法。
18. 【請求項１８】 各機能サービスは、システムの加入者
    間の呼接続のために個々の機能の動作を管理する機能コ
    ールソフトウェアを有する、請求項１３記載の方法。
19. 【請求項１９】 前記の決定ステップにおいて、システ
    ムにより提供され個々のシステム加入者により要求され
    る各機能サービスに関するデータをアクセスして演算を
    行い、前記データはカスタマイズ可能なフォーマットで
    配置されている、請求項１３記載の方法。
20. 【請求項２０】 前記の決定ステップにおいて、システ
    ムにより提供され個々のシステム加入者により要求され
    る各機能サービスに関するデータをアクセスして演算を
    行い、前記データは論理テーブルおよびビットマップの
    フォーマットで配置されている、請求項１３記載の方
    法。
21. 【請求項２１】 基本呼ソフトウェアの実行中、機能サ
    ービスを実施可能である少なくとも１つのトリガ時点を
    決定するステップを有する、請求項１３記載の方法。
22. 【請求項２２】 基本呼ソフトウェア実行中、基本呼プ
    ログラムにおける個々の機能サービスのための要求を指
    定し個々のデータをメモリへ導くことにより個々の機能
    サービスを実施可能である、少なくとも１つのトリガ時
    点を決定するステップを有する、請求項１３記載の方
    法。
23. 【請求項２３】 システム加入者接続動作を管理する基
    本呼ソフトウェアにより、呼機能動作を管理する呼機能
    ソフトウェアを呼処理システムにおいて実行する方法で
    あって、前記システムは、前記ソフトウェアを作動する
    プロセッサと、該ソフトウェアおよびこれに関連するデ
    ータを記憶するメモリを有する形式の、呼機能ソフトウ
    ェアを呼処理システムにおいて実行する方法において、 ａ．基本呼ソフトウェアによる機能要求に応じて、実行
    可能な個々の呼機能を決定するために第１のデータ演算
    を実行するステップと、 ｂ．目下実行中の呼機能ソフトウェアに基づいて、所定
    の個々の呼機能の実施を禁止するために第２のデータ演
    算を実行するステップと、 ｃ．最高優先順位の呼機能を決定するために、前記の第
    ２のデータ演算の結果のデータ検索を実行するステップ
    と、 ｄ．最高優先順位に決定された個々の呼機能のための呼
    機能ソフトウェアを実行するステップを有することを特
    徴とする、 呼機能ソフトウェアを呼処理システムにおいて実行する
    方法。
24. 【請求項２４】 ａ．最高優先順位に決定された個々の
    呼機能のための呼機能ソフトウェアの実行に基づいて、
    所定の個々の呼機能の実行を禁止するために、第３のデ
    ータ演算を実行するステップと、 ｂ．呼機能ソフトウェアの実行ステップを反復し、禁止
    されていない残りの各呼機能に対し、優先順位にしたが
    って第３のデータ演算を実行するステップを有する、請
    求項２３記載の方法。
25. 【請求項２５】 前記の第１のデータ演算を実行するス
    テップにおいて、個々の加入者により申し込まれる呼機
    能を規定するデータビットマップと、機能要求時に個々
    の呼機能の実行を規定するデータテーブルの行の間にお
    ける第１の共通のデータセットを決定する、請求項２３
    記載の方法。
26. 【請求項２６】 第１のデータ演算を実行する前記のス
    テップにおいて、個々の加入者により申し込まれる呼機
    能を規定するデータビットマップと、機能要求時に個々
    の呼機能の実行を規定するデータテーブルの行の間の第
    １の共通データセットを決定し、さらに、前記共通のデ
    ータセットと、実行に応じて他の呼機能を実行する呼機
    能を規定するデータビットマップとの間の完全なデータ
    セットを決定する、請求項２３記載の方法。
27. 【請求項２７】 第２のデータ演算を実行する前記のス
    テップにおいて、実行可能な個々の各呼機能に対し、実
    行可能な個々の呼機能を規定する前記の完全なデータセ
    ットと、目下実行中の呼機能ソフトウェアに基づいて個
    々の呼機能の阻止を規定するデータテーブルの行との間
    の第２の共通データセットを決定する、請求項２６記載
    の方法。
28. 【請求項２８】 データサーチを実行する前記のステッ
    プにおいて、前記の完全なデータセットと阻止データテ
    ーブルの行との間の第２の共通データセットのビットマ
    ップサーチを実行する、請求項２７記載の方法。
29. 【請求項２９】 呼機能ソフトウェアを実行する前記の
    ステップにおいて、最高優先順位の個々の呼機能に対
    し、機能要求時に個々の呼機能の実行を規定するデータ
    テーブルの行により定められた動作を実行する、請求項
    ２７記載の方法。
30. 【請求項３０】 第３のデータ演算を実行する前記のス
    テップにおいて、新たに実行された呼機能ソフトウェア
    に対し、実行可能な個々の呼機能を規定する完全なデー
    タセットと、新たに実行された呼機能に基づいて個々の
    呼機能の阻止を規定するデータテーブルの行との間の第
    ３の共通データセットを決定する、請求項２４記載の方
    法。
31. 【請求項３１】 前記の反復ステップにおいて、第３の
    共通データセットが未セットではないことを判定する、
    請求項３０記載の方法。
32. 【請求項３２】 プロセッサおよびメモリを有し、各加
    入者間の呼接続動作ならびに呼接続のための少なくとも
    １つの機能サービスの実施を管理する呼処理システムの
    ためのプロセッサにおいて、 ａ．システム加入者間の呼接続を形成する手段と、 ｂ．呼接続中の所定の時点で、少なくとも１つの機能サ
    ービスをトリガすべき機能サービス形式に依存しないよ
    うにトリガする手段と、 ｃ．メモリに記憶されており前記トリガ手段により使用
    するために管理可能なフォーマットで配置されている個
    々の機能サービスデータをアクセスする手段と、 ｄ．機能サービスのトリガに応じて、個々の機能サービ
    スと呼接続動作とのインタラクションを管理する手段が
    設けられていることを特徴とする、 呼処理システムのためのプロセッサ。
33. 【請求項３３】 前記トリガ手段は、 ａ．呼接続中の所定のトリガ時点でいずれの機能サービ
    スが実施可能であるかを判定する手段と、 ｂ．システムの最新のフォーマッティング時に形成され
    た優先順位で、使用可能であると決定された各機能サー
    ビスを実行する手段を有する、 請求項３２記載のプロセッサ。
34. 【請求項３４】 前記管理手段は、呼接続動作中に機能
    サービスを実行する手段を有する、請求項３２記載のプ
    ロセッサ。
35. 【請求項３５】 前記管理手段は、個々の機能サービス
    データにより管理されるプロセッサによるタスクを実行
    する手段を有する、請求項32記載の方法。
36. 【請求項３６】 複数個の加入者通信端末間の伝送線路
    を介した呼経路を形成する通信ネットワークのための呼
    処理システムにおいて、 ａ．個々の加入者間の呼経路接続を形成し作動させる手
    段と、 ｂ．個々の呼経路のための機能サービスを提供する手段
    と、 ｃ．ネットワーク、システム加入者および機能サービス
    に関するデータを記憶し、機能サービスをカスタマイズ
    できるようなフォーマットで前記データを配置するメモ
    リと、 ｄ．前記メモリに記憶されたデータに基づいて所定の機
    能サービスを提供するために機能サービス提供手段をト
    リガし、前記メモリに記憶されたデータに基づいて個々
    の機能サービスと個々の呼経路とのインタラクションを
    行う手段が設けられており、トリガおよびインタラクシ
    ョンのための前記手段は、提供される機能サービス形式
    に依存しないことを特徴とする、 通信ネットワークのための呼処理システム。
37. 【請求項３７】 前記の機能サービス提供手段は、当該
    呼処理システムから離れた位置から個々の呼経路のため
    のサービス機能を提供する手段を有する、請求項３６記
    載の呼処理システム。
38. 【請求項３８】 前記のトリガおよびインタラクション
    のための手段は、呼経路とのインタラクションにおいて
    個々の機能の順位を競合整理する手段を有する、請求項
    ３６記載の呼処理システム。