JPH08280047A - 通信システム - Google Patents

Abstract

(57)【要約】 【課題】 ソフトウェアを２重にし、ソフトウェアのア
クションを予測することにより新しい機能性を現存のリ
アルタイムシステムに付加する通信システムを提供す
る。 【解決手段】 通信システムにおいて、システムに組み
込まれた機能と外部機能間に不利益なインターアクショ
ンが増加しつつある。このようなインターアクション
は、第１および第２のソフトウェアサブシステムと、ハ
ードウェアサブシステムと、インターアクション管理体
とを有する通信システムにより防止することができる。
第１のソフトウェアサブシステムは「ライブ」コピーで
あるシステムソフトウェアのコピーを動作させ、ハード
ウェアサブシステムにコマンドを送る。第２のソフトウ
ェアシステムはシステムソフトウェアの複写コピーを動
作させ、インターアクション管理体にコマンドを送り、
その際両方のソフトウェアサブシステムはインターアク
ション管理体から事象を受信し、ソフトウェアによりシ
ステムの加入者に複数の機能が提供される。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ソフトウェアを２
重にし、ソフトウェアのアクションを予測することによ
り新しい機能性を現存のリアルタイムシステムに付加す
る通信システムに関するものである。

【０００２】

【従来の技術】多くの通信会社では、この１０年または
１５年の間に多大な投資が行われ、切り換え装置にかな
りのサービス機能が付加された。これらの装置およびそ
れに含まれるサービスについては、今後数年間に渡って
非常技術の情報ネットワーク（ＩＮ, Intelligent Netw
orks）およびコンピュータサポート通信アプリケーショ
ン（ＣＳＴＡ, Computer Supported Telecommunication
Applications）によるネットワーク内で提供されるサ
ービスとインターワークすることが要求される。しかし
これを困難とする実際的理由は数多く存在する。

【０００３】

【発明が解決しようとする課題】初期のソフトウェアの
多くは何年も前に書かれているため、最新のソフトウェ
アエンジニアリングおよびドキュメンテーション技術の
恩恵はなかった。この制限された情報では、新しいサー
ビスが可能な結合全てを簡単にテストすることなしに利
用可能となるに従って、この新しいサービスで正確なイ
ンターワークを確実とするのは困難となる。利用可能な
サービスが多くなるに従い、実行されなければならない
テストの数は指数的に増加し、テストの負担は急速に重
くなる。

【０００４】さらにはますます古くなるソフトウェアベ
ースのメンテナンスの問題があり、よって状況が非常に
短期間でアドレスされなければならない理由が明らかと
なる。

【０００５】非常技術は、公衆および私設ネットワーク
の結合のためにドライブを提供する公衆および私設シス
テムの両方に存在する。その際、主な制限の１つも公衆
および私設システムにより統合の限界にまで提供され
る。それらについては、ここで非常に基本的な用語を用
いて説明され、それにより続く提案の論拠を形成する。

【０００６】情報ネットワーク（ＩＮ）は、私達を次世
紀に導くために国際的に採用された公衆ネットワーク構
成のための用語である「ＣＣＩＴＴ (国際通信電信諮問
委員会、International Consultative Committee for T
elecommunications and Telegraphy）、Ｑ.1200 シリー
ズ推奨（ＩＴＵ（国際電気通信連合、InternationalTel
ecommunications Union）として既知）参照」。基本コ
ール (Basic Call)（すなわち、１対１通話）の関係を
付加価値サービス（例えば、コール待ち (CallWaitin
g)、３者通話 (Three Party Calling)等）に変えるにあ
たり、機能を別々にしてネットワーク内で別々に提供
し、また基本コールと付加価値サービス間に限定インタ
ーフェースを提供することが可能であった。ＩＮ構成内
では、サービスはネットワーク内のサービス制御ポイン
トまたはＳＣＰ(Service Control Point) として知られ
る別々の物理的エンティティで提供され、これはサービ
ス切り換えポイントまたはＳＳＰ(Service Switching P
oint) 内に含まれるコールの処理に影響を与えた。これ
を図２に示す。

【０００７】上記のような個別提供により、以前と比べ
てネットワーク内での新しいサービスのより迅速な書き
込みおよび実行が可能となった。これは、ＩＮ構成が提
供する多くのキーがもたらす恩恵によるものであり、明
白なのは下記に示す通りである。 ・サービスからの基本コールの論理的分離は、サービス
により影響されるコールのみが考慮されることを意味す
る。これは、新しいサービスを利用しない他のコールシ
ナリオは、新しいものの導入にあたって再テストを受け
る必要がないことを意味する。これによりシステムテス
ト要求が減少するため、マーケットへの時間が明らかに
スピードアップされる。 ・基本コールおよびサービス間の限定インターフェース
は、他と比較して新しいサービスを実行するのに要する
プログラミングがかなり少ないことを意味する。さら
に、サービス命名のためのスタンダードツールを提供す
ることが可能である。また、マーケットへの時間がスピ
ードアップされる。

【０００８】コンピュータサポート通信アプリケーショ
ン（ＣＳＴＡ）は、ＩＮが公衆ネットワークにおいて提
供するのと同様な機能を備える私設環境内で利用される
プロトコルセットである「ＣＳＴＡ仕様、ＥＴＳＩ（欧
州通信標準機構、European Telecommunications Standa
rds Institute ）参照」。図３を参照。ここでもサービ
ス制御素子(Service Control Element) とコール制御素
子(Call Control Element)間の限定インターフェースを
使用して、コールの処理は通常発生するものから変更さ
れる。

【０００９】しかしＣＳＴＡの利用法は、ＩＮとは違う
傾向にある。ＩＮが追加のコール処理機能（すなわち、
キャンプオン (Camp-On)、３者通話等の新しいサービ
ス）を提供する一方で、ＣＳＴＡはテレダイアル (Tele
dialling) や自動コール分配(Automatic Call Distribu
tion) 等の付加価値サービスを提供するのに利用され
る。これは、私設システムが今や基本切り換え製品内で
何年も増補コール処理機能をもっていたからである。

【００１０】ＣＳＴＡはしばしば配列として考えられ、
これにより外部計算素子はＰＡＢＸシステムと一緒に作
用して増補コール処理機能を提供するが、その際一方が
もう一方から独立して作用することはできない。

【００１１】中心問題は、実施例により最も簡単に図示
される。電話機でコール転換使用中(Call Diversion on
Busy)が設定されたエクステンションユーザＡの場合を
考えてみる。これは通話中の場合に、新しくかかってき
たコールがＰＡＢＸにより別の応答ポイントＢに自動的
に転換されることを意味する。

【００１２】入力コールは、ユーザが通話中のために到
着しても転換される。コールはＢで鳴るが応答がないた
め、コールパーティはリングバック(Ring Back) 要求を
設定する。ここでの問題は、設定されるべきリングバッ
クはどのようなタイプのものか、ということである。公
衆ネットワークの視点からは（鳴っているのを見る）、
Ｂで次コール使用時リングバック(Ring Back When Next
Call Used) であるべきだが、実際は、コールが私設ネ
ットワーク内でコール転換使用中機能により元々の応答
ポイントから転換されたため、Ａでフリー時リングバッ
ク(Ring Back when Free) であるべきである。何の機能
を発動するかの正確な決定は、コールの経路に影響を与
えた他のサービスが何であるか分かっている場合に公衆
ネットワークによってのみ可能となる。

【００１３】インターアクションは上記よりももっと微
妙なことが多い。公衆ネットワーク内で発呼、ＰＡＢＸ
に提示され、ＣＳＴＡを介して増補機能を提供するコー
ルの場合を考えてみる。この論議の目的のため、提供さ
れる増補機能はグロッサリで説明されるコールセンタ
（ＣＣ, Call Centre）アプリケーションであると仮定
される。

【００１４】入力コールは、終端ＰＡＢＸに到着し、Ｃ
ＳＴＡ−ＣＣパッケージにより端末にルートされる。そ
の端末におけるエイジェントは、数ある理由の内の１つ
によりそのコールを取ることができないと想定する。そ
して、２、３回鳴らしたあと、コールパーティはＩＮに
より提供された機能を使用して、次使用時リングバック
要求を端末で設定したいと所望する。

【００１５】リングバックは、この特別な機会にコール
された特定のエイジェントではなく、ＣＣキューに配置
されることがより適切である。なぜなら、その場合コー
ルはＣＣグループ内のどのメンバーに対しても同等に送
信することができるからである。これは、ＣＳＴＡ−Ｃ
Ｃパッケージが要求の処理の仕方が分かるように、ＩＮ
の次使用時リングバックサービスについてよく認識して
いなければならないことを意味する。そうでなければ、
通常の省略次使用時リングバックアクションが取られ、
結果としてコールは特定のエイジェントに送られること
になる。

【００１６】全仕様がコール経路に沿って発生し得るサ
ービス全てに対して利用可能であるとすれば、上記のシ
ナリオはしっかりと合理的に適応される。これらのサー
ビス仕様については、仕様間のインターアクションが確
認され、決定が標準化されれば公表可能である。これは
現存の標準ボディ内で既に起こっていることと合理的に
同様で、故に問題は短期間の間に解決されるであろう。

【００１７】しかし、ＩＮおよびＣＳＴＡは両方とも表
面上設計された目的−１人または少人数のユーザのため
の注文システムの開発−のために利用されているため、
起こり得ることを考えてみる。ネットワーク内に存在す
るサービスの数が１，０００しかないとすれば、１つの
サービスの定義を変えるのに要するサービス提供者はた
った１人で、残りの９９９のサービススクリプトについ
てはチェック、および潜在的な変化を要する。これは何
故なら、初期の分析では、どのサービスも他の全てのサ
ービスと相互作用することが可能だからである。

【００１８】上記は仮説的状況ではない。この２、３年
の間にコンピュータシステム製造業者数人が、ＣＳＴＡ
機能に基づいた発議権を提唱した。大きなＰＡＢＸの殆
どはＣＳＴＡを支持するか、または今後２年の間に支持
するであろう。英国の公衆ネットワーク内で通産省（Ｄ
ＴＩ, Department of Trade and Industry）は、ＩＮを
独立した第３のサービス提供者に開放する可能性につい
てのコメントを要求した。これについては、今後５年間
の内に起こることが無理なく予期される。

【００１９】多数のサービスが多数の売手により提供さ
れる上記のシナリオでは、異種ネットワークの混合した
環境において２つのサービスが相互に接触するのはコー
ルが置かれたときが初めてである。両サービス間のイン
ターアクションの決定が必要とされるのはこのときであ
る。

【００２０】上記論議の示すことは、サービス間のイン
ターアクションの決定が長期の間に、動作時間、すなわ
ち切り換えシステムがアクティブに動作している間に決
定されなければならないということである。そして最終
目標は、平明な自動サービスインターワークを多数のネ
ットワークに渡ってサポートすることでなければならな
い。しかし大概のＰＡＢＸはその主なセールスポイント
を常に機能性としていたため、切り換えシステム内に組
み込まれた非常に多くのサービスを既にもっている。新
しいインターアクション決定技術を収容するためにこれ
らのサービス全てをリライトすることは不経済である。
そこで持ち上がる問題は、どのようにしたらこれらのい
わゆる伝来システムを収容できるか、ということであ
る。

【００２１】私設・公衆ネットワーク統合の要求を満た
すための発達能力をもって上記問題を提示することが、
フルインターアクション決定技術の開発に向けての第１
のステップである。

【００２２】

【課題を解決するための手段】本発明によれば、事象ジ
ェネレータと、各々のサブシステムが同数の機能を含む
複数のソフトウェアサブシステムと、インターアクショ
ン管理体と、外部機能モジュールとを有する通信システ
ムにおいて、全事象は前記インターアクション管理体を
介して前記事象ジェネレータからサブシステムにルート
され、前記複数のサブシステムのうち１つのみが前記事
象ジェネレータに対して直接応答でき、それ以外の前記
複数のサブシステムからの応答は前記インターアクショ
ン管理体へ送られる通信システムが提供される。

【００２３】

【発明の実施の形態】次に添付図面を参照しながら、実
施例に基づいて本発明を詳述する。

【００２４】ここでリアルタイムのコール処理伝来シス
テムの統合問題の解決法を提示するわけだが、その前
に、背景情報としてＰＡＢＸの構造またはその他のリア
ルタイム駆動のソフトウェアシステムについて少し説明
する。この背景材料は、提示される提案を考慮する場合
において不可欠である。

【００２５】ＰＡＢＸは、ハードウェア（基本的にはプ
ロセッサ）、コール切り換えサブシステムと様々なオプ
ションカード、およびハードウェアを駆動し、１つの切
り換え製品を他から大きく区別する機能を提供するソフ
トウェアからなる。製品が増補され、競合物に対してマ
ーケットでその区別を維持できるのは、このソフトウェ
アの開発および拡張によるものである。

【００２６】組み込まれたソフトウェアの機能は、さら
に２つのクラス−１つは基本コールをサポートし、もう
１つはベース上で動作する付加価値機能を実行する−に
分離することができる。付加的機能を提供するのはこれ
らの付加価値機能である。

【００２７】マーケット力の結果として、最新の自動式
構内交換（ＰＡＢＸ, Private Automatic Branch Excha
nges）は非常に多くの付加価値機能を提供し、そのため
それらを実行する大量のコードを有する。殆どの場合、
この付加的ソフトウェアはベースのソフトウェアとしっ
かりと統合されており、そこから独立分離することはで
きない。さらに、このコード内の機能間のインターアク
ションは、個別機能の実行が現存する他の機能により影
響を受けるようにシステム内にハードコード化された規
定により決定される。事実、１つの機能をシステムから
除去するのは、その機能と他の機能間に存在する微妙な
インターアクションにより困難である。

【００２８】図４で実施例として示されるような、前述
したハードウェアおよびソフトウェアのサブシステムか
らなる仮定的な一般の切り換えシステムを考えてみる。
これらのサブシステムは、デバイスドライバとして言及
され得るソフトウェアモジュールを介して通信する。

【００２９】事象は、ハードウェアからソフトウェアへ
と送られ、コマンドはハードウェアのアクションを制御
するためにソフトウェアから戻される。この段階におけ
る分析は、ハードウェア事象（すなわち、実際の物理的
世界で起きる事柄）とソフトウェア事象（すなわち、ソ
フトウェア環境の世界的空間内でモデル化される事象）
間に限定的境界および分離点を提供する。提案技術は、
この仮説的システムとの関連において論議される。

【００３０】１つの機能が特定されると、その機能と現
存する機能とのインターアクションが特定でき、それに
より図５で示すように、その機能が相互作用する他の全
ての機能の部分的なものが新しい機能のために仕様内で
生成される。

【００３１】現存機能から新しい機能へのメッセージ
は、新しいサービスが存在しないものとして他のサービ
スの継続が許可された場合にそれらがとるアクションと
して考えられ得る。新しい機能から他のサービスへのメ
ッセージは、新しい機能の必要条件を考慮した現存サー
ビスの様式を変更するための要求として考えられ得る。

【００３２】上記は、新しいサービスパッケージの仕様
のために欧州通信標準機構（ＥＴＳＩ, European Telec
ommunications Standards Institute）により採用され
た仕様の時間アプローチを表す「M. Crowther, J. Ells
berger, J. Kroon, L. Verhaard 、デジタル電話におけ
るサービスインターアクション (Service Interaction
in Digital Telephone) 、ＥＴＳＩにおける研究につい
ての論文、France, Sophia Antipolis, ＥＴＳＩ ＡＴ
Ｍプロジェクトチーム３７、November 27, 1992 参
照」。

【００３３】前述したように、将来的には増加する機能
コードがコアスイッチの外に配置され、コアスイッチは
スイッチが既に提供している組み込みのサービスと引き
続きインターワークしなければならない。現存の組み込
まれたソフトウェアの変更が制限され、また付加的機能
が組み込みのスイッチソフトウェア外で提供できること
が要求されたとすると、ＥＴＳＩのアプローチが現存製
品内に組み込まれるように動作時間導入を通して実行で
きるかを見ることは実際的な提案となる。

【００３４】上記を実現することは、次の２つの理由に
より非常に困難である。 ・現存の機能コードは、低レベルのデバイスドライバに
しっかりと結合される。これは、全ての外世界のハード
ウェア事象が現存機能に直接送られることを意味する。
この送信機能については、新しい機能を組み込むために
変更されなければならない。 ・機能は、外世界からの事象に対してのみ応答する（す
なわち、機能は非同期には動作しない）。この場合、そ
のようなシステムがどのように実行できるかを知るのは
とても困難である。結局、事象に対応した機能の効果が
どのようなものであるかを知ることは、機能のアクショ
ンが完了されるまでは不可能である。

【００３５】上記２つの拒絶のうちの１つ目は、ハード
ウェアから事象を取り出し、限定されたいくつかのトリ
ガーシステムを介してそれらを送る場所を決定する一般
的な事象送信システムを提供することにより克服でき
る。

【００３６】第２の拒絶は、ソフトウェアのコピーを多
数提供することにより克服できる。その際コピーの１つ
はマスターコピーとして動作し、物理的ハードウェアの
制御が許可される。これは、「ライブ」ソフトウェアサ
ブシステム(Live Software Sub-system)と言うことがで
きる。最も簡単な実行においては、たった１つの２重シ
ステムを用いることで、ソフトウェアの第２のコピーは
ハードウェアを制御しているかのような動作を示すが、
実際にはコマンドを送ってそれを新しく付加された機能
に戻す。この２つの概念については、機能モジュール(F
eature Module)の形態をとる１つの付加的機能がシステ
ムに導入されたシナリオ用に図６に示す。

【００３７】上記の場合事象は新しい機能に送られ、そ
れにより新しい機能は何のアクションを実行するかのオ
プションをもつ。従って、新しい機能はスイッチが実行
を所望するアクションについては全て重複可能で、機能
モジュール自体も関心事象を決定する責任をもつ。通常
の場合、事象は機能モジュールとは関わりがないため、
機能モジュールは事象をライブソフトウェアサブシステ
ムに直接送信して処理させる。しかし、機能モジュール
が潜在的に関心を示す事象が到着すると、この事象は図
６に示すように２重ソフトウェアサブシステム(Duplica
te Software Sub-system) （このシステムはライブソフ
トウェアサブシステムと同期に維持される）に送信され
る。すると、このシステムは実際のソフトウェアがする
のと全く同じ処理を実行し、ハードウェアを駆動するか
のようにその結果を機能モジュールに戻す。その後機能
モジュールは事象および２重システムのソフトウェアが
実行した結果に基づき、スイッチハードウェアにアクシ
ョンされるためにライブソフトウェアサブシステムに送
信すべき事象を決定することができる。

【００３８】明白な１つの開発は、事象制御および優先
決定ソフトウェアの多くを機能モジュールから別のモジ
ュールに移動させることである。これにより、別のモジ
ュールは総括的なインターアクション管理体(Interacti
on Manager) となる。

【００３９】その後機能インターアクションモジュール
は、多くの外部機能と切り換えシステム内で既に現存す
る組み込みの機能との間の仲裁の責任を負い、ここで切
り換えシステムは単にもう１つの機能または機能の集合
として理解される。外部機能管理モジュールの原則はCa
in「M. Cain, D. Gillespie 、Hugh Levei機能関係から
の効果的な動作時間機能管理データ構造の自動生成 (Au
tomatic Generation of Efficient Run-Time Feature M
anagement Data Structures from Hugh LeveiFeature R
elationships)、ＵＳ、通信ソフトウェアシステムにお
ける機能インターアクションの国際ワークショップ (In
ternational Workshop on Feature Interactions in Te
lecommunications Software Systems)、December 3-4,
1992 参照」に説明されている。

【００４０】インターアクション管理体がトリガーされ
る方法は多く存在し、それにより同じ事象に対して競合
するものが決定される。テーブルをベースとするアプロ
ーチは短期間では適切かもしれないが、将来的には非常
に制限的となる。組み込みのソフトウェア内では既に膨
大な量のトリガーコードが提供されているため、全ての
事象を２重ソフトウェアサブシステムに送信し、外部機
能がトリガーされる場合に例外を生成させることがより
適切である。これは、ＣＳＴＡ機能が組み込みソフトウ
ェア(Embedded Software) 内で既に規定されるときのＣ
ＳＴＡの例において適切である。

【００４１】ソフトウェアの付加的コピーは、コピーが
必要とされるときにスイッチを入れるキャッシュシステ
ムを利用することによりかなり簡単に得られる。する
と、同じ物理的メモリから読み出しを行う同じプロセッ
サが使用可能となり、ソフトウェアの２重コピー間の同
期問題を除去する。２重モードのとき（書き込みキャッ
シュがオンのとき）は、メモリへの書き込み全てが実際
はキャッシュへ送られ、固定的な影響はない。これは何
故なら、キャッシュについては固定メモリへのライトバ
ックを行わなくてもフラッシュできるからである。しか
し、インターアクション管理体が通常通りに事象を処理
することを決定すると、キャッシュは簡単にリリースさ
れてライトバックを許可されるため、付加的処理は全く
必要ない。

【００４２】ソフトウェアがＵＮＩＸ内で実施される
と、下記に示すようにＵＮＩＸフォークコール「W.R. S
tevens、ＵＮＩＸ環境における最新式プログラミング
(Advanced Programming in the UNIX Environment) 、
アジソン・ウェスリー専門計算シリーズ (Addison Wesl
ey Professional Computing Series) 1992, ISBN 0-201
-56317-7 参照」を利用して可能な２重ソフトウェアの
生成処理を実行することができる。採用されたアルゴリ
ズムは疑似コード形態で下記に示す。 Start Transaction （トランザクション開始）： Fork Child IF I am child THEN（チャイルドならば次へ）： BEGIN DO Perform Actions （アクション実行） UNTIL Commit Transaction OR Abort Transaction （トランザクション委任または放棄） SWITCH Commit Transaction ： Send Abort Message to Parent （ペアレントに放棄メッセージを送信） CONTINUE Abort Transaction ： Send Continue Message to Parent （ペアレントに継続メッセージを送信） EXIT ENDSWITCH END ELSE BEGIN Wait for Message from Child Process （チャイルド処理からのメッセージを待機） SWITCH Abort Message: EXIT Continue: CONTINUE ENDSWITCH END

【００４３】スタートトランザクションメッセージが受
信されると、機能はフォークコールを利用して自身のコ
ピーをつくる。すると、ペアレント処理が待機する。チ
ャイルド処理は、コミットまたはアボートトランザクシ
ョンメッセージを受信するまでコアスイッチ(Core Swit
ch) から各事象を取り出して処理する。チャイルド処理
はコミットメッセージを受信すると、それをペアレント
処理に送ってペアレント処理に死滅するように指示す
る。すると、チャイルド処理がペアレントとなる。

【００４４】メッセージがアボートの場合は、チャイル
ドが死滅し、ペアレントは何の介在メッセージも受信す
ることなく継続する。

【００４５】コミットの場合（通常のケース）、要求さ
れる付加的処理は初期フォークおよびペアレントへの信
号のみである。コピー・オン・ライトフォーク戦略をも
つ最新のオペレーティングシステムの場合、これは最小
限のオーバヘッドである。明らかにアボートのオーバヘ
ッドは、この時間にチャイルド処理が負った処理時間を
加算したものである。

【００４６】従って、殆どの場合付加的な処理要求がな
いため、上記技術の採用から合理的に予期されるパフォ
ーマンスヒットは最小である。いずれにしてもＣＳＴＡ
処理にトリガー処理が実行され、パフォーマンス含意を
もたない、または含意が最小であるハードウェアにより
原子動作が提供される。

【００４７】インターアクション管理体は、潜在的に１
つのコール内に含有可能な全ての機能モジュールに対し
て高速接続を要する別個のソフトウェアシステムとして
実行される。何故なら、そうでなければ切り換えシステ
ムの全パフォーマンスが犠牲となるからである。

【００４８】本発明は、通常現存のリアルタイムシステ
ム内で動作するソフトウェアを２重にし、またソフトウ
ェアコピーを用いて組み込みのソフトウェアが省略アク
ションの実行を許可されている場合にそのソフトウェア
のアクションを予測することにより新しい機能性を現存
のリアルタイムシステムに付加する技術の開発である。
よってインターアクション管理体として知られる外部エ
イジェントは、組み込まれたソフトウェアの競合する要
求および全ての外部機能要求を決定することになる。従
って、多数の機能が切り換えシステム外にある一般的な
ケースでは、システムトポロジイは図１に示すようにな
り得る。

【００４９】機能性のグレードアップを提供するために
現存の伝来ソフトウェアを変更しなけばならないという
通常の問題は、上記技術の利用により回避される。

【００５０】主切り換えコアが提供する機能の利用を継
続する一方で、コア外に存在し得る機能ソフトウェアを
開発する技術が提供された。

【００５１】上記アプローチにより、時間の経過ととも
にコアスイッチからより多くの機能を外部処理エイジェ
ントに移動させるグレードアップ経路が提供される。こ
のアプローチが、今リサーチ段階にあるネゴシエイショ
ンおよびリソース論争技術(Interaction Resolution Te
chniques) を含むインターアクション決定技術(Interac
tion Resolution Techniques) の利用を妨害することは
全くない。実際、このアプローチの採用により切り換え
製品はこれらの技術全てをほとんど利用することができ
る。

【００５２】グロッサリ 自動コール分配 (AUTOMATIC CALL DISTRIBUTION) 非常に多くの受信者またはエイジェントに対してコール
を分配するために広く利用されるシステムである。通常
のＡＣＤアプリケーションは、フライトブッキングまた
は照会サービスであり、ここでは独立した入力コールの
各々がフリー状態がもっとも長いエイジェントに対して
ルートされる。この方法により、各々のエイジェントが
受信するコール時間は殆ど同じになる。

【００５３】基本コール (BASIC CALL) 付加的サービスの利用のない、簡単で、直接ダイアルさ
れるパーティ・トゥ・パーティコールである。このタイ
プのコールはサービス切り換えポイント内で全処理が行
われ、その存在期間中サービス制御ポイントへの適用は
全くない。

【００５４】コールセンタ (CALL CENTRE) これは表面上はＡＣＤが動作しているかのようなアプリ
ケーションであり、デスクブッキング、クレジット照会
等、同様な状況において利用される。ＣＣとＡＣＤとの
相違は、コンピュータシステムが発呼者処理サイクル内
に統合されることにより、アプリケーションのデータ入
力・顧客情報画面が発呼者とともに移動することであ
る。

【００５５】コール処理動作内で上記の重要な変更を行
うことにより、発呼者が１つのコールの処理中に多数の
エイジェントに対して同じ情報を繰り返さなければなら
ないという問題が回避される。

【００５６】コール待機 (CALL WAITING) リング音により発呼者が紹介されるサービスで、既に他
のコールにより通話中の受信者は短いトーン音を受信す
ることにより別のコールがあることを知る。受信者は、
通話中のコールを継続してもよいし、かかっているコー
ルに応答してもよい。

【００５７】キャンプオン (CAMP-ON) リングバックの別名（後述）

【００５８】ＣＳＴＡ コンピュータサポート通信アプリケーション。ＰＡＢＸ
環境内のプロトコルセットで、これにより通常ミニコン
ピュータである外部処理素子は切り換えシステム内のコ
ール処理についての情報を得、それらのコール処理を選
択的に変更する。

【００５９】ＩＮ 情報ネットワーク。サービスを独立して開発できるよう
に、サービスを基本コールから分離する構造である。

【００６０】ＰＡＢＸ 自動式構内交換。私設ネットワーク（ＰＮ）を形成する
ために他の私設スイッチに接続可能な私設スイッチ。

【００６１】リングバック (RING BACKS) リングバックは、コールしようとしていたパーティへの
通話が許可されたときに、リングバックを設定したパー
ティがコールバックされるサービスである。フリー時リ
ングバックは末端のパーティが通話中のとき設定され、
発呼者は受信者が受話器を置いた時点でリングバックさ
れる。次コール利用時リングバックは末端のパーティの
応答がない場合に設定され、この場合、受信者が次のコ
ールを終了した時点で発呼者がリングバックされる。

【００６２】サービス制御ポイント（ＳＣＰ, SERVICE
CONTROL POINT） ＩＮ構成内で、サービススクリプトが動作するポイン
ト。これらのサービススクリプトは、サービス切り換え
ポイント（ＳＳＰ）とともに処理中のコールに影響を与
える。

【００６３】サービス切り換えポイント（ＳＳＰ, SERV
ICE SWITCHING POINT） ＩＮ構成内で、コールが切り換えられるポイント。ＳＳ
Ｐは基本コールの制御の全責任を負い、ＳＣＰにリクエ
ストを送信してサービスをサポートするための付加的指
示を行う。

【００６４】３者通話 (THREE PARTY CALL) １つのコールで同時に３人が通話できるサービス機能群
である。３者通話サービス機能のうちでもっとも一般的
なものはコール会議である。

【００６５】

【発明の効果】本発明によれば、通常現存のリアルタイ
ムシステム内で動作するソフトウェアを２重にし、また
ソフトウェアコピーを用いて組み込みのソフトウェアが
省略アクションの実行を許可されている場合にそのソフ
トウェアのアクションを予測することにより新しい機能
性を現存のリアルタイムシステムに付加する通信システ
ムが提供される。

【図面の簡単な説明】

【図１】本発明によるシステムトポロジイを示す図であ
る。

【図２】ＩＮ構成の概略図である。

【図３】ＣＳＴＡ構成の概略図である。

【図４】ハードウェアおよびソフトウェアサブシステム
を含む切り換えシステムの概略図である。

【図５】現存機能と付加された新しい機能間のインター
アクションを示す概略図である。

【図６】システムに付加的機能が加えられ、ライブおよ
び２重ソフトウェアサブシステムが利用されたときに関
係がどのようにモニタされるかを示す図である。

【図７】２重ソフトウェアサブシステムとの関連におけ
るインターアクション管理の利用を示す図である。

Claims (7)

【特許請求の範囲】
1. 【請求項１】 事象ジェネレータと、 各々のサブシステムが同数の機能を含む複数のソフトウ
   ェアサブシステムと、 インターアクション管理体と、 外部機能モジュールとを有する通信システムにおいて、 全事象は前記インターアクション管理体を介して前記事
   象ジェネレータからサブシステムにルートされ、 前記複数のサブシステムのうち１つのみが前記事象ジェ
   ネレータに対して直接応答でき、それ以外の前記複数の
   サブシステムからの応答は前記インターアクション管理
   体へ送られることを特徴とする通信システム。
2. 【請求項２】 前記インターアクション管理体は、事象
   を生成、消滅、または変更して前記複数のサブシステム
   に送信することを特徴とする請求項１記載の通信システ
   ム。
3. 【請求項３】 少なくとも外部機能モジュールをさらに
   １つ有し、 前記インターアクション管理体は、前記外部機能モジュ
   ール間および前記外部機能モジュールと前記ソフトウェ
   アサブシステム間の仲裁を提供することを特徴とする請
   求項１または２に記載の通信システム。
4. 【請求項４】 コンピュータサポート通信アプリケーシ
   ョン技術が用いられる請求項１から３のいずれか１項に
   記載の通信システム。
5. 【請求項５】 情報ネットワーク技術が用いられる請求
   項１から３のいずれか１項に記載の通信システム。
6. 【請求項６】 キャッシュシステムの利用により前記ソ
   フトウェアの２重コピーが実行される請求項１から５の
   いずれか１項に記載の通信システム。
7. 【請求項７】 前記ソフトウェアの前記２重コピーが実
   行される請求項１から５のいずれか１項に記載の通信シ
   ステム。