JPH09509026A - 補充サービス間における相互作用の取り扱い - Google Patents

Abstract

(57)【要約】 通信網において複数の基本機能及び複数の補助機能の使用を取り扱うシステムには、前記通信網において相互に通信することができる複数のユーザが含まれる。前記ユーザは、複数の基本サービス及び複数の補助サービスに加入するように許可されて、前記基本機能及び補助機能についての使用がそれぞれ可能にされる。前記システムは、複数の基本機能を含み、それぞれが１以上の前記補助機能を前記プラットフォームに結合させる複数の補助機能インターフェースを実現させるプラットフォームを含む。各補助機能は、前記補助機能が用いる必要性のある前記各インターフェースに対して１つとする１以上の補助機能結合モジュールからなる。前記補助機能結合モジュールは補助機能プレーンに配置されている。補助機能間の競合を検出して解決するために用いられる相互作用ロジックは、相互作用ロジック・プレーンに配置された複数の相互作用ロジック結合モジュールからなる。前記複数の補助機能及び補助機能インターフェースは前記相互作用ロジックに対して透過伝送性である。前記複数の相互作用ロジック結合モジュールは前記複数の補助機能に対して結合可能である。

Description

【発明の詳細な説明】 補充サービス間における相互作用の取り扱い 技術分野 概要的に、かつ第１の特徴によれば、本発明は、相互に呼出すと共に、基本機 能及び補助機能にそれぞれ関連した複数の基本サービス及び複数の補助機能を予 約することができる複数のユーザを含む、通信網における基本機能及び補助機能 の使用を取り扱うシステムに関する。プラットフォームは複数の基本機能を含み 、かつそれぞれがプラットフォームに対して１以上の補助機能を結合させるイン ターフェースを行う。各補助機能は、補助機能が使用したい１以上で、インター フェース当り一つのモジュールからなる。相互作用ロジックは補助機能間の競合 を検出して解決するために用いられる。 特に、かつ第２の特徴によれば、本発明は、一組の基本機能及び一組の補助機 能を含むように構築された通信システムに関する。各前記補助機能はこの基本機 能に対する付加を形成し、かつ変更を行うように一定の基本機能に接続可能であ る。基本機能は１以上のオープン・インターフェースを実行し、その機能はどの ような補助機能に対しても固有ではなく、かつ基本機能に影響させることなく、 新しい補助機能をシステムに付加させる形式により、前記複数の基本機能と前記 複数の補助機能との間の相互作用を許容する。特定の基本機能に同時に接続され て相互的な競合に至る２つの補助機能における各々の動きにより発生する問題を 解決させるために相互作用ロジックが用いられる。 通信網における商業的な製品は、通常、その型式の製品に本質的なものとみな してもよい一組の基本機能を有する。複数の基本機能は相互に異なる型式の製品 を区別するためと云ってもよい。例えば、電話はユーザに回線網における呼を確 立させる必要がある。ファックス装置は呼を受信できると共に、呼が生起するユ ーザからのメッセージを書き込むことができるものでなければならない。通常、 商業的な製品は、これらの基本機能の他に、同一型式の異なる製品を区別するい くつかの補助機能も提供している。一定の電話は、例えばユーザが最後に掛けた 番号を容易に掛けられるリダイアル呼出しボタンを有する。一定のファックス装 置は回線網のいずれかから、記録されたメッセージを受信することもあり得る。 以上で定義した接続には、ここで明確にする必要があると思われる一定の考え が存在し、そのいくつかは以上で述べられており、また以下でも更に述べる。こ れらの考えは、即ち、 −回線網オペレータ；これは物理的な通信網を稼働させる機構である。スウェ ーデンでは、テリア（Ｔｅｌｉａ）がその例である。 −システム製造者；これは回線網オペレータに対して通信網を作成し、かつ提 供する機構である。スウェーデンでは、これはテリアに対してのエリクソンであ る。オランダではダッチＰＴＴに対してのエリクソン及びＡＴ＆Ｔである。 −ユーザ；これは通信網においてサービスを利用できる者又は機構である。従 って、概念的なユーザは、サービス又はサービス・グループに関連されることな く、用いられることはない。ユーザは、しばしば加入者と同一である。 −サービス・プロバイダ；これは１又は数人のユーザにサービスを提供する者 又は機構である。今日、サービス・プロバイダは、予測し得る将来の範囲で残る と予測される条件において、回線網オペレータと通常同一である。 通信網における各ユーザは、これを主として他の複数ユーザと通信をするため に使用する。ユーザがこれら機能を回線網において使用すること、例えば呼を確 立することができるようにするために、ユーザは加入すること、例えば加入者が 複数の適用可能サービスに対する加入者となることが必要である。ユーザがシス テムの基本機能を利用したいのであれば、ユーザは正しい基本サービスに加入す る必要があり、またユーザがシステムの複数の補助機能を利用したいのであれば 、ユーザは正しい複数の補助サービスに加入する必要がある。 従って、特定のサービスは、加入によりユーザに提供される。そこで、ユーザ 、又はユーザに代わってサービスのプロバイダは、対応する機能を作動させるこ とができる。この機能はユーザに特定の措置を実行させる。呼の要求は、例えば 受話器を上げることにより活性化される。「呼の転送」は、活性化されたときに 、サービスが提供されるユーザを送出先とする複数の呼を他の送出先に転送する 機能である。 複数のサービスはユーザ毎を基本として提供されるので、活性化された機能は 、サービス合意の一部として、ユーザとサービス・プロバイダとの間の合意によ り決定されるものよりもシステムに大きな影響を与えてはならない。「待ち呼」 は、例えば話中アクセスに対する呼の待ち行列を許容する。サービスが提供され ると、「待ち呼」が複数の呼を待ち行列にすることができるアクセスは、ユーザ がプロバイダから借りるアクセスに制限される。従って、この機能は、アクセス 権を持つユーザによって「アクセスに対して活性化された」と呼ばれる。数人の ユーザが例えばＩＳＤＮにおいて可能とされるアクセス権を持っているときは、 このような呼のみが待ち行列にされ、これらの呼は活性化された「待ち呼」を有 するユーザに送出される。 ここで用いられる意味において、基本機能及び補助機能と共に以下で更に詳細 に説明される相互作用の考えは、当該技術分野における者に周知である。要する に、各基本機能及び補助機能は、通信システム内の複数のコンピュータにより実 行されるコードからなる。使用する場合には、実行された基本機能のコードにお けるジャンプ命令により、所望の補助サービスの活性化が実行される。 複数の基本機能及び複数の補助機能に関連し、かつこれらを説明する勧告は、 例えばＧＳＭシステムに見られる。参照文献として、例えば、異なるいくつかの 補助機能に対する「待ち呼」のような以上で用いた種類に関する勧告０２．０４ を参照することができる。 相互作用の問題に示し得る補助機能の説明に関連して、問題とする相互作用及 びその結果の説明も存在する。 更に、サービス・プロバイダに対してのみ適用可能な複数の補助機能も存在し 得る。即ち、このような複数の補助機能に対してアクセス権を有するユーザはい ない。サービス・プロバイダは、これらの補助機能が活性化されるまで、サービ スに対して加入する必要はない。例えば、回線網保守のために多くの補助機能は 、送信ルートに対して、送信ルート内に優先順位回線を導入する複数の補助機能 、又は一定の条件によりルートを自動的に阻止する複数の補助機能が活性化され る。更に、複数のユーザは、ユーザのグループ、例えばビジネス・グループを表 すユーザよりも、複数の送信ルートを賃貸することができる。この場合に、ユー ザは、 この送信ルートに関連するユーザによって補助機能を活性化できるようになる前 に、サービスに加入しなければならない。 利用可能なサービスが多ければ、それだけこれらサービスのプロバイダは「潜 在的な」ユーザにとって魅力的となる。従って、プロバイダにとって本質的なこ とは、対抗し得るサービス・セット、複数の基本サービスと共に複数の補助サー ビスを提供することができることである。新しい補助サービスを提供することは 、含まれている補助サービスの実現には基本機能のわずかな変更のみでよいとい うことのために、これを達成する最も早い方法であるとみなされている。従って 、大きく拡大された数の補助サービスが期待できる。即ち、これは、新しい補助 サービスの設置まで必要とすることから、短いサイクルの導入が必要である。原 則を提供して活性化することは極めて単純明解なことなので、これは、短い導入 サイクルを得るために障害となり得る補助サービス部分となる。従って、これら の補助サービスは、ソフトウェアとして最もよく実現される。 完全な通信システムを変更する度に、新しい補助サービスを導入することは、 余りに高価である。従って、システムにおいて最小限必要なことは、システムが モジュール構成であることが必要である。モジュール・システムは、確立された 他の補助機能に影響することなく、新しい補助機能の導入と、古い補助機能の除 去が可能である。各補助機能は別個のローディング・モジュールとして設置され る。 このモジュール構成はプラットフォームにより達成されてもよい。プラットフ ォームは基本機能を含む。これは更に１以上のインターフェースを実現する。各 インターフェースは、複数の補助機能と複数の補助機能との間の相互作用を許容 する基本機能に対して１以上の補助機能を結合させる。 補助機能は、補助機能が使用したい１以上の、各インターフェースについて一 つの結合モジュールからなるものでよい。結合モジュールは、結合に関連して、 同一インターフェースに結合されている他のモジュールに影響することなく、イ ンターフェースに結合される。 各インターフェースは、複数のオペレーション及び複数のトリガからなる。各 トリガは、実行したときに、基本機能の動きに特定の変更を行うオペレーション に対する呼出しである。これらの変更が出現すると、対応するトリガがインター フェースに結合されている補助サービスに送出される。次いで、各補助サービス は、プラットフォームに１以上のオペレーションを実行するように指令すること によってトリガに応答することができる。このプラットフォームは、補助サービ スの実行を計画すること、即ちどのような順序で複数の補助サービスがトリガを 受け取るべきかを判断することになる。 これは、プラットフォームと複数の補助サービスとの間において２方向の相互 作用に帰結する。 本発明において、インターフェースが開放されているということは、全てのサ ービスに対する総称であると共に、同一システムにおいて１以上のサービスによ り使用できるものでなければならないことを意味する。換言すれば、どのような 補助サービスに対しても固有となるオペレーション又はトリガは存在しない。プ ラットフォームそれ自体は、補助サービスに対して如何なる固有コードも含んで はならない。プラットフォームの将来のアップグレードは、以前のバージョンと 互換性のあるインターフェースを実現するものでなければならない。これらの特 性はプラットフォームと複数の補助機能との間にモジュール構成を確保する。複 数の補助機能は、プラットフォームに影響することなく設置し、設計し、かつア ップグレードすることが可能とされ、またプラットフォームは複数の補助機能に 影響することなく、アップグレードすることが可能とされる。 多くのユーザは少数の補助機能を活性化するに過ぎない。従って、プロセッサ の能力における大きなオーバーヘッドを避けるために、トリガの取り扱いを最適 化することが重要である。従って、例えば呼出し又はオペレータ手順において基 本機能をそれぞれ活性化するために、トリガはこの特定の活性化に適用可能な補 助機能によってのみ受け取られるべきである。これは、基本機能そのものを実行 中に、インターフェースに結合されている複数の補助機能を表す結合図を構築す ることにより達成され得る。そのときは、活性化される複数の補助機能のみが結 合され、かつ複数のトリガがこれらにのみ送出されることになる。例えば、ある 呼が補助機能を活性化する送信ルートを含むときは、この補助機能における適当 な結合モジュールが呼に結合される。ここで、補助機能は呼から複数のトリガを 受け取ることができる。この手順はしばしば「ダイナミック結合」と呼ばれる。 更なる最適化のときは、複数のトリガを結合された複数の補助機能のサブセット にのみに送出することができる。即ち、指示したものがこのトリガに関係する。 このような機構は「モニタリング」と呼ばれる。 ダイナミック結合は異常ではない。Ｃ＋＋では、ダイナミック結合を実行する ために「ダイナミック結合」に関する原理を使用することができる。ＰＬＥＸで は、信号がそれらの送出先をダイナミック・データとして搬送する（この機構は モジュール間で通信するために用いられる）。ＡＸＥ−１０では、ＰＬＥＸに含 まれるこの機能が「トラヒック結合」（＝活性な呼）を実行するために用いられ 、トラヒック結合ではこれらのモジュールを「イン・リンク」する又は「サイド ・リンク」となり得る。 当該技術分野における通常技術には、いくつかの問題がある。 前述のようにプラットフォームが実現されると、補助機能とプラットフォーム との間でモジュール構成が達成される。同一のプラットフォームを使用すると、 これらの相互的な動きに対する競合により、補助機能が不都合にも終了すること がある。２又はそれより多くの補助機能間における競合を解決できるようにする ときは、競合を解決するために、相互に作用するように競合により影響される補 助機能を設計することが知られている。従って、この構造による補助機能間には 、当然のモジュール構成が存在せず、競合が発生するのを防止する。例えば、「 話中の呼の転送」及び「待ち呼」と比較すべきである。「話中の呼の転送」は、 ユーザが話中のときに呼を転送することである。代わって、「待ち呼」は話中の ユーザに対する呼を待ち行列にすることである。２つの補助機能は一致するよう に相互作用するものでなければならない。例えば、両者は活性化されるが、しか し元の送出先が最初に応答するときは、他の送出先に対する呼出信号を停止し、 また他の送出先が最初に応答するときは、「待ち呼」待ち行列からその呼を削除 する。 システムにおける補助機能が余り多くない限り、補助機能そのものにおいて相 互作用を非常に簡単に実行することができる。増大し続ける既に設置した補助機 能をアップグレードしなければならないので、増大し続ける数の補助機能により 、 新しい各補助機能に対する総合的な導入サイクルは長くなる。これはシステムに 障害を導入する結果となり得る。この問題はしばしば「相互作用の問題」と呼ば れている。各解決は全ての補助機能間におけるモジュール構成を保証するもので なければならない。本発明は、補助機能において相互作用を固有に実行してはな らないということの実現から出発している。勿論、これを実行する方法は、それ が解決する以上の問題を発生させてはならない。 関連技術の説明 従来のアーキテクチャにおいて、補助機能間の競合を解決するソフトウェア形 式による協調機構は、論理的にプラットフォームの一部分であるが、しかし別個 のモジュールとして実現され、即ち、これを個別的にアップグレードすることが できる。協調モジュールは、補助機能から見ると、プラットフォームに属する。 協調を必要としない限り、協調モジュールは補助機能からプラットフォームへ指 令されたオペレーションを転送させ、かつ複数の補助機能のトリガをプラットフ ォームから１以上の補助機能に転送するだけとなる。更に、協調モジュールは必 要とするダイナミック結合も実行する。 協調モジュールは、補助機能がオペレーションを提供するときか、又はプラッ トフォームがトリガを送出するときの競合を検出する。競合を検出するロジック は、「検出ロジック」と呼ばれ、かつ下記の情報に対してアクセスを有する。即 ち、 −特定の活性化に結合された複数の補助機能。 −結合された複数の補助機能の前の複数のオペレーション。 −結合された複数の補助機能に前に送出された複数のトリガ。 −現在のオペレーション／トリガ。 −プラットフォームに記憶することができ、かつ協調モジュールによりアクセ スすることができる情報。例えば、「状態の呼出」。 次いで、協調モジュールは競合を避けるために協調操作を実行することができ る。これは、「解決ロジック」と呼ばれる。これらには下記が含まれる。 −トリガにより複数の補助機能の実行を再計画。 −一定の補助機能、又は一定のトリガから一定の補助機能への特定的なオペレ ーションの無視、置換又は実行。 このような従来の解決手法は、補助機能ロジックと相互作用ロジック、即ちこ の補助機能の検出ロジック＋解決ロジックとの間の関係を喪失するに至る。その 結果、データ又はコードに関連した補助機能は、プラットフォームに記憶された データ、例えばデータ・ベースを除き、協調モジュールにより直接アクセスする ことはできない。データ・ベースにおけるデータであっても確保することはでき ない。補助機能は実行中にこのデータをしばしばコピーし、次いでこのコピーを 更なる処理に使用する。この構造による他の結果は、補助機能に対してどのよう なフィードバックも存在しないということである。従って、補助機能は、これに よって指令したオペレーションを変更することなく実行されるか、又は監視され ているトリガを受け取っていないかについて知らない。この結果、この補助機能 は可能な限り簡単となるけれども、相互作用ロジックは当然更に複雑となる。関 連した複雑さは、 −補助機能の実行の大部分がプラットフォームに向かうオペレーションからな る。従って、補助機能についてかなり詳細な、多分、補助機能の可能とする全て の競合を解決するために実際に必要とするものより詳細な知識が要求される（要 約は不可能）。 −正しい判断のためにあるデータを必要とするときは、補助機能により指令さ れたオペレーションからこのデータを取り出す必要がある。このデータは、相互 作用ロジックにより要求されるまで記憶される必要がある。同様に、データにお ける変化はこれらの変化を次のオペレーションから抽出することにより監視され る必要がある。ここでも、データ及びその変化の監視に関する複雑さに加えて、 これには補助機能のオペレーションの内部形式についての詳細な知識が必要とさ れる。 −実行フローにおける異なる分岐が異なる型式の競合に至る恐れがあるときは 、検出ロジックにより補助機能の実行フローにおける全ての変化を注意深く監視 しなければならない。補助機能の実行状態は協調モジュールに保持されなければ ならない。判断ロジック及び反復ロジックを直接監視することはできないので、 必要な情報を得るために、オペレーション及びそれらのデータが解釈される必要 が ある。ここでも、これは補助機能の内部オペレーションについて詳細な知識を必 要とする。 −補助機能における実行フローは、あるオペレーションに対する特定の結果を 戻すこと、又は補助機能にトリガを送出することよりも、他の手段により影響さ れてはならない。これらの結果及びトリガは補助サービスに特定されるものでは ない。この結果、補助機能の動きに影響する可能性が最小となる。補助機能は、 競合が解決された後、前と異なる方法により継続することが要求されることがあ る。多分、これはあり得ない。その場合は更に、他の方法により補助機能をトリ ガすることによってこれを継続できるようになるまで、解決ロジックは、補助機 能の競合する機能ではなく、全体的に標準を取る必要がある。その間、補助機能 は阻止されていなければならない。 説明したいくつかの負の効果は、部分的に補償されてもよい。例えば、補助機 能はある情報、例えば許可を送出して補助機能における判断フローを表示させて もよい。補助機能は、何時この情報を適用すべきかについて気付かないので、こ れを常時送出しなければならない。これは、メモリ及びプロセッサの能力を無駄 に使用することになる。他の可能性は、簡単な相互作用を表すことのみによって 負の効果をなくすことである。このような相互作用はしばしば複数の補助機能に 割り付けられている優先順位により制御される。これらの優先順位は、複数の補 助機能の計画（低い優先順位の前に高い優先順位）を決定するものであり、さも なければ低い優先順位の補助機能の阻止に至る恐れがある。相互作用ロジックは テーブルにより極めて容易に制御することができるので、このアーキテクチャを 用いているシステムは、実際においてこれらの単純な相互作用の取り扱いにより 逆に成功する。その１例は「話中の呼の転送」と「待ち呼」との間で所望の相互 作用である。両者はトリガ「話中アクセス」に作用する。その場合に、「呼の転 送」は呼を他の送出先に転送し、一方「待ち呼」は呼が可能になるまでアクセス に対する呼を待ち行列にすることになる。この相互作用は「呼の転送」を阻止す ることからなるので、代わって呼が待ち行列にされる。 しかしながら、しばしば「よりインテリジェント」な解決法が選択される。例 えば「呼の転送」及び「待ち呼」の場合に、両者を実行するように判断し、かつ 呼にまず応答する側に基づいて相互作用を判断させることができる。これは、例 えば、他の送出先が応答するのであれば、「待ち呼」を削除する可能性が必要と なると思われる。他の可能性は、ある理由により、例えばユーザにトーンを送出 するのにリソースが利用できないため、又はユーザによる時間切れのために、「 待ち呼」が継続されないときに、呼を転送することである。ここでも、これは、 「呼の転送」を除き、また呼の現在状態が「呼の転送」と両立可能となるときに のみ、「話中」トリガを送出することが必要となる。 従って、補助機能の設計は簡単になるが、しかしその結果として、相互作用ロ ジックの設計が更に複雑になる。これは、非常に多くの補助機能が設置されてい ないときに許容し得た。通常、複数サービスの複数プロバイダは、相互作用に対 して厳しい要求をしておらず、従って大抵の相互作用は可能な限りの簡単さが確 保される。ユーザは、利用可能かつ潜在的な複数の補助機能により強い関心を示 すに従い、ますます高い補助機能、及びますます複雑な相互作用を要求する。 米国特許第５，１１５，４３２号は（高速）回線網を介する通信に適応された データ通信用のアーキテクチャを説明している。ここで、データ通信とは、例え ばファイル、音声又は映像データを意図したものである。このアーキテクチャは ２レベルからなる。ハイのレベルは並列に実行される独立した多数の「水平機能 」からなる。ローのレベルは回線網に向かう複数の基本機能からなる。全てのロ ー・レベル及び対応する処理は回線網に対するアクセスを制御する機能により実 行される。従って、水平機能間に依存性が存在するのであれば、これは意図する 機能により解決される。従って、アーキテクチャはこれらの「水平機能」を提供 することによりこのロー・レベルと異なるレベルを介して相互作用をさせる。 ＥＰ２２８，０５３号はリアル・タイムにより通信システムを制御する方法に 関する。補助機能を容易に変形し／プログラムしてもよく、また異なる補助機能 間の相互作用を簡単な方法により解決してもよいことを許容する構造が説明され ている。この解決は、その記載によれば、プログラムが「ノンプロシージャ言語 」による「スクリプト」により書かれており、かつ多数のトリプレットからなる 。その「スクリプト」間の相互作用は、ハイのレベルを有する「スクリプト」が ロー・レベル上の「スクリプト」をそのトリプレットがこれを示すときに実行す る ことを許容している。 米国特許第４，９２８，３０４号は電話交換機及びこれに接続された外部コン ピュータの形式による通信網用の電子交換システムを説明している。基準機能に 必要なプログラム・シーケンスは電話交換機におけるメモリ装置に記憶されてい る。加入者側でのみ利用可能なサービスを実行するプログラムは、外部コンピュ ータに記憶される。外部コンピュータを介して、コンピュータ・インターフェー スにより電話交換機の特殊機能を制御することが可能である。このアーキテクチ ャは、外部コンピュータのプログラムに変更を行うことにより、異なる補助機能 の変更を容易に実行し得ることを意味する。 要約 本発明の目的は、プラットフォームにおける補助機能の透過伝送性、及び補助 機能における相互作用の透過伝送性を認める新しい基本アーキテクチャを得るこ とにある。即ちここで、基本アーキテクチャとは、異なる型式のインターフェー スを識別するインターフェース・レベル、インターフェースを形成するために可 能とする原理、及びどのようにかつどの型式のソフトウェアによってこれらを使 用できるのかに基づくアーキテクチャを意味する。 本発明は、第１の特徴によれば、通信網において相互に通信することができ、 複数の基本サービス及び複数の補助サービスに対する加入が許可される複数のユ ーザを含み、それぞれ前記複数の補助サービス及び複数の補助機能の使用を可能 にさせる前記通信網における複数の基本機能及び複数の補助機能の使用を取り扱 うシステムを備える。前記システムはプラットフォームを含み、前記プラットフ ォームは前記基本機能を含み、かつそれぞれが前記プラットフォームに対して１ 以上の前記補助機能を結合させる複数の補助機能インターフェースを実現する。 各補助機能は、前記補助機能が使用する要求もあり得る各前記インターフェース について１つとする１以上の補助機能結合モジュールからなる。前記補助機能結 合モジュールは補助機能プレーンに配置される。複数の補助機能間における競合 を検出し、かつ解決するために用いられる相互作用ロジックは、相互作用ロジッ ク・プレーンに配置された複数の相互作用ロジック結合モジュールからなる。前 記複数の補助機能及び複数の補助機能インターフェースは前記相互作用ロジック に対して透過伝送性であり、前記複数の相互作用ロジック結合モジュールは前記 複数の補助機能に結合可能である。 本発明の第２の特徴によれば、導入により定義した種類の通信システムは、前 記相互作用ロジックが複数の相互作用モジュールを含むこと、各補助機能がその インターフェースの使用により前記補助機能と相互作用することを意図して、前 記補助機能に影響することなく、新しい相互作用モジュールを前記システムに付 加させる形式により、前記相互作用モジュール間の相互作用を許容する少なくと も一つのオープン・インターフェースを実現すること、及び前記オープン・イン ターフェースが前記補助機能間における競合を避ける形式により複数の補助機能 と相互作用する複数の相互作用モジュールに使用するためであることの改良によ って特徴付けられる。 前記相互作用ロジック・プレーンは、それぞれが特定の競合を解決することが できる多数の相互作用ハンドラ機能を含むものであってもよい。各相互作用ハン ドラ機能は各補助機能に対する少なくとも一つの結合モジュールからなり、その 補助機能インターフェースは前記相互作用ハンドラ機能により用いられる。他の 複数の補助機能との相互作用を取り扱うために必要とされる異なる複数の相互作 用ハンドラ機能において全て必要な結合モジュールと共に、新しい補助機能がシ ステムに導入される。相互に依存する同一の相互作用ハンドラ機能における結合 モジュールは、ローディング・モジュールを形成するものであってもよい。結合 モジュールを最早使用しない場合は、前記結合モジュールを含むローディング・ モジュールを取り外す。 更に、前記システムは補助機能により実現されるインターフェースを含むもの であってもよく、また複数のオペレーション及び複数のトリガの形式により、異 なる複数の補助機能において同一であるいくつかの総称部分を含む。 更に、相互作用ロジック・プレーンは、補助機能とプラットフォームとの間で 複数のインターフェースを使用することもでき、また複数の付属結合モジュール により検出プレーン及び解決プレーンに分割されてもよい。前記解決プレーンは 、いくつかの解決モジュールが同一の検出モジュールを使用できるように構築さ れてもよい。前記検出プレーンはトリガのみからなるインターフェースを実現で き るものであってもよい。前記解決プレーンは補助機能により実現されるインター フェースを直接使用するために前記検出プレーンを無視する複数のオペレーショ ンを含むものであってもよい。 更に、前記システムは、異なる複数のプレーンによく類似し、かつこれらによ り用いられる複数の総称機能用、かつ複数のインターフェースを取り扱うモジュ ールも備えてもよい。前記総称機能用のモジュールには、ダイナミック結合を取 り扱う複数の機能が含まれてもよい。前記総称機能用のモジュールには、複数の 補助機能の実行を計画する機能が含まれてもよく、プラットフォームの機能又は 補助機能により活性化されてもよい。前記総称機能用のモジュールは複数の補助 機能を実行するための一定の計画を変更する複数のオペレーションを受け取るよ うに適応され、また同一の補助機能における異なる複数の結合モジュール間で複 数プレーンにおける通信を取り扱う複数の機能と、プラットフォームにおける通 信を取り扱う複数の機能とを含む。 以上で述べた概念的な実現とは、以下、ソフトウェア接続において、一定の仕 様を満足させるために必要とするプログラムの設計を意味する。この仕様は、ソ フトウェアが明確な言語により実行し、かつ文書であると思われることが望まし いという、何が望ましいのかを定義する。ソフトウェア・コンテキストによりイ ンターフェースを実現することは、このインターフェースを実現するソフトウェ アが格納されていると仮定して、このインターフェースに他の複数のモジュール を結合できることを要求する全ソフトウェアの実現を意味する。通常、インター フェースにより一緒に結合されている複数のモジュールは、異なる複数の設計者 、更には異なる企業により設計されているということにより、通常、複数のイン ターフェースは個々に指定される。結合とは、あるインターフェースに結合され たモジュールがそのインターフェースにおいて定義されている複数のオペレーシ ョンを実行することができ、かつこれらが適用可能なときにそのインターフェー スにおいて定義されている複数のトリガを受け取ることを意味する。後者の場合 に、複数のインターフェースを実現するソフトウェアは、トリガが結合されてい る複数のモジュールに送出されることを確保するものでなければならない。 インターフェースは、言語なしに、モジュール構成の設計を支持するある方法 により実現されてもよい。即ち、各モジュールは個々に設計されてもよいが、し かしこれらのモジュールはソフトウェア部分の完全な実現を達成するために設計 後に相互作用することになる（また、これが設置中又は実行中に行われてもよい ）。最近の大抵の言語は既にモジュラー設計を提供している。しかし、大抵の言 語は、相互作用を提供する手段として、概念的な「オペレーション」（また、使 用する言語によっては、メソッド、メッセージなどと呼ばれてもいる）のみを実 現する。しかし、最近、トリガ（又はここでも使用する言語に従って「事象」若 しくは「検出点」）を実現するいくつかの言語が発生するに至った。これらは、 大抵、「ビジュアル」言語と呼ばれ、最もよく知られているのは、ＭＳ−Ｗｉｎ ｄｏｗｓ（エム・エス−ウィンドウズ）用の「Ｖｉｓｕａｌ Ｂａｓｉｃ（ビジ ュアル・ベーシック）」である。事実、これらは主として同一のことを意味して いるために、実際問題としてトリガを除き、命名処理を全く使用しないのがよい かも知れない。細かな一つの相違は、オープン・インターフェースにおいて、こ のインターフェースを実現するモジュールがいくつかのモジュールにトリガを送 出しなければならず、一方このインターフェースに結合されているモジュールの みがインターフェースを実現する複数のモジュールにトリガ（オペレーション） を送出することができることである。しかし、両者の場合において、一般的にあ るモジュールは他方に情報を送出すること、かつ他方のモジュールは適当な方法 によりこの情報に応答することができることを意味する。 第１の特徴により本発明の以上の定義を説明するために、更に、下記のことを 述べることができる。 ２つのモジュールを互いに結合する場合に、必要とすることは、複数のモジュ ールがトリガ及びインターフェースにおけるオペレーションに関連する情報を交 換できることがその全てである。全てのオペレーション及びトリガ（即ち、オペ レーション又はトリガの第１の命令）に対してメモリ・アドレスが存在する。オ ペレーションに対するメモリ・アドレスはインターフェースを実現するモジュー ルにより保持され、一方これらトリガに対するメモリ・アドレスは複数のインタ ーフェースに結合されている複数のモジュールにより保持され、これらは結合モ ジュールが異なれば異なり得る。ある結合モジュールが設置されると、データ・ ベース（そのインターフェースを実現するソフトウェアが既にインストールされ 、かつその情報がデータ・ベースに記憶されているものと仮定する）により結合 しようとするインターフェースのオペレーションに対するアドレスをフェッチし 、かつ受け取ったトリガに関連する情報をそのインターフェースを実現するモジ ュールへ送出する。これらはそれぞれの側のテーブルに記憶される。あるオペレ ーションが実行されると、モジュールは、正しいアドレスを見つけてジャンプす るためにそのオペレーションを実行してそのオペレーションに対するアドレスを 含むテーブルを参照する。トリガが特定の機能に送出されると、そのインターフ ェースを実現するモジュールは、その機能における正しいアドレスを見つけてジ ャンプするために、その機能のために備え、かつその機能におけるトリガに対す るアドレスを含むテーブルを逆に参照する。以上は、大抵、オペレーティング・ システムにより実行される。 複数のオペレーション及び複数のトリガは検知可能なコンテキストであり、例 えばオペレーションはある呼に対して有効であってもよい。これは、今日、プロ セッサが有するオペレーションの形式により、同一の命令を実行することができ る（従って同一のメモリ・アドレスを用いてもよい）ことを意味するけれども、 これらの命令は呼に特有のデータにより機能する。更に、これらのデータを見い 出すことができる基準（有力な例）は、オペレーションと共に送出される。逆も 同じく真である。更に、トリガの受け取り時に実行されるべき処置は、この例の 状態に従ってもよい。 図面の簡単な説明 さて、添付する図面を参照して本発明の実施例を以下詳細に説明しよう。 第１図は補助機能プレーン及び相互作用ロジック・プレーンを有する本発明に よるシステムのアーキテクチャの概要設計原理をブロック図の形式により示す。 第２図は同様に、第１図によるアーキテクチャにより、どのようにして補助機 能と相互作用プレーンとの間のインターフェースがいくつかの総称インターフェ ースを含めることができるかをブロック図の形式により示す。 第３図は２つの補助機能間の相互作用を流れ図の形式により示す。 第４図は総称機能用のモジュールをブロック図の形式により示す。 第５図は補助機能間の競合を解決する方法をブロック図及び流れ図により示す 。 実施例の詳細な説明 第１図には、プラットフォーム２における一組の基本機能及びプレーン６にお ける一組の補助機能４を含めるように構築された通信システムが示されている。 各補助機能４は、この基本機能に対する付加を形成し、かつ変形する特殊な基本 機能に接続可能である。この基本機能は、全補助機能に対する総称であって、か つ基本機能に影響することなく、新しい補助機能をシステムに付加することがで きるように基本機能と補助機能との間の相互作用を認容する１以上のオープン・ インターフェース８を実現する。プレーン１０に、特定の基本機能に同時に接続 されている２つの補助機能の各々の動きにより、互いに競合に至る問題を解決す る相互作用ロジックが配置されている。 同様に、各補助機能４は、相互作用ハンドラ１４との間の相互作用を許容し、 補助機能と相互作用ロジック１０に含まれる少なくとも一つの総称インターフェ ース１２を実現する。特に、以下に出てくるように、インターフェース１２は、 このインターフェースの使用により問題とする補助機能と相互作用することを意 図している新しい相互作用ハンドラを、補助機能に影響することなく、システム に付加するできる形式により、問題とする相互作用を実行することができるよう に設計されている。 インターフェース１２は、補助機能間の競合を避けるように、相互作用ハンド ラ１４により使用されて補助機能４と相互作用をする。 第１図に示すシステムは、相互に呼出し、かつ複数の基本サービスと、複数の 基本機能及び複数の補助機能にそれぞれ関連する複数の補助サービスとに加入す ることができる数人のユーザを含む通信網において、複数の基本機能及び複数の 補助機能の使用を取り扱うために用いられてもよい。 本発明の基本的な考えは、相互作用ロジック１０が使用できる総称インターフ ェースをプラットフォーム２と共に複数の補助機能４により実現することである 。２つのプレーン６及び１０は、それぞれ１以上のモジュール製品かるなる。 プラットフォーム２、及びプラットフォームと複数の補助機能との間の複数の オープン・インターフェース８が使用している複数の補助機能に対して透過伝送 性であるべきと同様に、複数の補助機能４、及び複数の補助機能と相互作用ロジ ックとの間の総称インターフェース１２は、使用している相互作用ロジックに対 して透過伝送性でなければならない。更に、相互作用ロジック・プレーン１０に おける結合モジュール１６は活性化された補助機能にダイナミックに結合される 必要がある。 各相互作用ハンドラ１４は特定の相互作用競合を解決することができ、相互作 用ハンドラにより使用されている各補助機能用に少なくとも一つの結合モジュー ル１６からなる。 新しい補助機能４は、導入されると、他の補助機能４との全ての相互作用を取 り扱うために必要とされる異なる相互作用ハンドラ１４において必要な全ての結 合モジュール１６と共に現れる。 ローディング・モジュールは、相互に依存する同一の相互作用ハンドラ１４に おける複数の結合モジュール１６からなる。 結合モジュール１６が、そのインターフェースを使用している補助機能が除去 されていることにより、又は相互作用ハンドラにおける他の結合モジュールによ り使用されていないことにより、最早使用されないときは、結合モジュールを含 むローディング・モジュールが除去される。 第２図を参照すると、相互作用ロジック・プレーン１０に関連して補助機能４ により形成されたインターフェース１２は、数個の総称部分１８、２０、２２、 即ち異なる複数の補助機能が同一の複数のオペレーション及び複数のトリガから なるものでもよい。補助機能はその特性を識別するために初期の段階で解析され る。次いで、各特性は総称インターフェースに関連される。例えば、通常、基本 サービスでは継続し得ると思われる一定の複数呼が継続するのを認められない補 助機能が存在する。従って、この補助機能は、呼が解放されるように基本サービ スの動きを変更する。呼の解放に至る全ての補助機能は、例えば総称インターフ ェース１８の「呼の解放」を支持しなければならない。このインターフェース１ ８は、呼を解放する複数の補助機能に印加される特定の複数トリガ及び複数オぺ レーションからなる。「解放されるべき呼」トリガ及び「解放保持」オペレーシ ョンは、例えばこの総称インターフェース１８の一部を形成する。 補助機能により形成されたインターフェースが補助機能のグループに対して同 一となるいくつかの総称部分を含み得るということは、全ての相互作用ハンドラ により使用できる更に多くの総称検出及び解決コードを許容することである。こ れは、更にいわゆるスクリプト・プログラミングも許容する。今日ではこの型式 のプログラミングが補助機能を設計するために開発されており、例えば、エリク ソンのＳＳＩ（サービス・スクリプト・インタープリータ）、（エリクソン・レ ビュー第６７号、１９９０を参照）を挙げることができる。補助機能は「ＳＩＢ 」（サービス独立ビルディング・ブロックス）とも呼ばれる複数の総称モジュー ルを相互に結合することにより作成される。これらＳＩＢ間の結合は、「スクリ プト」と呼ばれる。このスクリプトはインターフェースにダイナミックに結合さ れ、次いで解釈される。各ＳＩＢはハイ抽出レベルにより処理を実行し、かつこ の処理を実行するためにプラットフォーム補助機能インターフェースを使用する 。新しいＳＩＢはプラットフォームに影響することなく、設計されてもよい。本 発明によるアーキテクチャは、生産性を高めるこれらのツールを相互作用ロジッ ク・プレーン６に用いることを許容している。 第３図を参照すると、例えば、「待ち呼の適用」のときは、少数のＳＩＢを使 用することにより、相互作用：ブロック「話中の呼の転送」を作成することもで きる。要求されるＳＩＢは、前記スクリプトを結合する補助機能を阻止する「機 能阻止」２４であって、一方のＳＩＢ２６は一方の結合モジュールからの情報を 同一の相互作用ハンドラにおける他方へ送出し、一方のＳＩＢ２８はこの情報を 受信し、かつ一方のＳＩＢ３０はＳＩＢ２８は受信した情報を評価して判断をす る。これらのＳＩＢは相互に結合されて２つのスクリプトを形成する。即ち、一 方は「待ち呼」３２に結合され、また他方は「呼の転送」３４に結合されている 。 送出ＳＩＢ２６は「呼の転送」における受信ＳＩＢ２８に情報「機能適用」３ ６を送出し、ここで「機能」にはＳＩＢが結合される補助機能３２の名称が書き 込まれる。この場合に、「待ち呼」は有効である。この情報は「待ち呼」３２か らトリガ「機能適用」を受信した時に送出される。このトリガは総称インターフ ェースの一部を形成し、かつ基本機能の作動後、補助機能３２が最初に作動した いことを表示する。この情報は「呼の転送」３４で受信ＳＩＢ２８により受信さ れる。 送信ＳＩＢ２６と受信ＳＩＢ２８との間において必要とする同期（最初に実行 するスクリプトによっては情報をバッファリングする必要がある。）は、それぞ れ２つのＳＩＢ内で取り扱われる。これを受信すると、情報が評価ＳＩＢ３０に 供給され、評価ＳＩＢ３０は判断を実行できるように「呼の転送」特定テーブル を用いる（その基準は問題のスクリプトを作成したときにＳＩＢに記憶された。 ）。各可能判断は別個的な出力となる。この場合に、「呼の転送適用」３８は、 「機能阻止」２４が結合される出力に至る。このＳＩＢ２４は、問題のスクリプ トを結合する補助機能３４を阻止する。これを実行するために、総称トリガ３８ の「機能−適用」を管理し、その後に補助機能３４が作動しないことを通告する 総称オペレーション４０「機能−規制」を通告する。 「待ち呼適用」の代わりに、送信スクリプトは更なる総称情報、例えば「待ち 呼」が話中ユーザにトーンを送出することを意味する「トーン送出機能アクティ ブ」を送出してもよい。この場合に、「呼の転送」上のスクリプトは、トーンを 送出する補助機能を導入する度にアップグレードされてはならず、また同一相互 作用ハンドラにおいて「呼の転送」を阻止するに至ってはならない。 同様に、複数の補助機能に特有のＳＩＢが作成されてもよいけれども、より生 産の収益が大きければ更なる総称ＳＩＢを用いてもよい。 更に、相互作用ロジック・プレーン１０は、第１図には明確に示されていない が、補助機能４とプラットフォーム２との間でインターフェース８を用いること もできる。一般的に、「上位」のプレーンは「下位」の全てのプレーンに対する アクセスを有する。オペレーティング・システムはプラットフォームの下に配置 され、更に補助機能プレーン及び相互作用ロジック・プレーンに利用可能である 。 複数のプレーン、及びこれらが実現し、又は使用する複数のインターフェース の両者が同一原理に従うということのために、異なるプレーンによく類似した機 能が常に存在する。第１図及び第４図を参照すると、これらの機能は総称機能用 のモジュール４０に含まれてもよい。このモジュールにおける複数の機能は、プ レーン６及び１０の両者により、又は異なるインターフェース８及び１２を取り 扱うときに、用いられる。 ダイナミック結合を取り扱うために必要とする大抵の機能は、例えばこのモジ ュールの一部を形成する。プレーンと補助機能プレーンとの間のインターフェー ス８のときは、ダイナミック結合用を意図した結合モジュールは、含まれている 異なった作動プロファイル、例えばユーザ、アクセス、ルートにより判断される 。これらのプロファイルは、通常、一組の結合モジュールが検出されるまで、テ ーブル４２を解釈することにより解析され、これによってこれらのモジュールは ダイナミック結合される。一般的に、同一機能は、入力型式が異なるものを除き 、相互作用モジュールを結合する必要がある。新しいプロファイルが導入され、 かつ補助機能がトリガ「機能適用」を送出する前にこの機能をトリガすると、プ ラットフォームはこの機能をトリガする。 更に、スケジューラは総称機能用のモジュール４０において実現される。この 機能４４はプラットフォーム２又は補助機能から来るトリガによりトリガされる 。更に、これは、一定のオペレーションも受け入れ、これらオペレーションは計 画を変更することになる。 補助機能６及び相互作用ロジック・プレーン１０の両者は、同一の基本機能に おいて異なる結合モジュール間で通信、例えばＳＩＢを送信及び受信することを 必要とする。総称機能用のモジュール４０は、これを簡単にする、特に複数の結 合モジュールを接続する機能４６を含む。更に、基本機能のより別個的な活性化 は通信を必要とすることにもなるので、プラットフォーム２はこれを用いること もできる。会議呼は、オペレーティング・システムの観点から結合モジュールと してみなすことができる別個の、しかし関連した多数の呼からなる。 本発明によるアーキテクチャの効果は相互作用ロジック・プレーンにおける構 造に依存する。例えば相互作用ロジック・プレーンに構築することが補助機能プ レーンにおいて解決される多数の競合よりも相互作用モジュール間に更なる競合 に至るべきではないことは、望ましいことであろう。しかし、他の観点から見る と、このような構造を識別することは、選択が技術的な考慮によってのみ制限さ れるので、容易となる。例えば、補助機能プレーンでは、異なる補助機能におけ る構造が市場を考慮することにより高度に制御される。原理的には、各機能は別 個に販売され、従って他の機能から独立した市場価値を有する必要がある。 通常、相互作用ロジック・プレーンにおいて異なった構造は、複数の補助機能 、及び異なる型式のＳＩＢにより実現されなければならないインターフェースの 原理に至る。複数のインターフェースに対する原理は、総称インターフェースの 選択により制御される必要がある。 最初に、組合わせに基づいた解決について説明する。この構造では、各相互作 用ハンドラ１４が固有な一組の補助機能４を表しており、これら補助機能４の全 てが同一の呼に含まれているときは解決が必要である。相互作用ロジック・プレ ーン１０におけるモジュール構成は、２以上の競合モジュールを別個のものと置 換することにより得られる。補助機能Ａ及びＢを含む複数の呼のときは、例えば 、相互作用ハンドラ“Ａ−Ｂ”が相互作用を取り扱う。補助機能Ｃがこの結合さ れる必要があるときは、“Ａ−Ｂ”は“Ａ−Ｂ−Ｃ”により表される。Ａ、Ｂ又 はＣが除去されると直ちに、“Ａ−Ｂ−Ｃ”を除去することができるので、相互 作用ロジック・プレーンにおけるローディング・モジュールは完了相互作用ハン ドラと同様である。新しい補助機能が導入されれば、他のモジュールとの各組合 わせは新しい相互作用ハンドラを必要となる。「話中の呼の転送」及び「待ち呼 」による前述の例は、この構造に対応する。 「フレキシブル・サービス・プロファイル」と呼ぶ一つの可能性は、１ユーザ に基づいて補助機能間の競合の解決に向けられる。この考えは、いくつかの補助 機能を含む別個のサービス・スクリプトを作成することにある。全ての相互作用 は３つのスクリプトによりハードコードにされる。この考えはＩＮ（インテリジ ェント・ネットワーク）から来ており、定義として、ＩＮユーザは、その回線網 における他のユーザにサービス（ＩＮサービス）を提供するユーザである。ＳＩ Ｂはこの接続内で最初に使用された。新しいアーキテクチャを使用することによ り、相互作用ロジック・プレーンは実サービス・スクリプトを実施することがで きる。ユーザは一組の補助機能よりも一つの相互作用ハンドラを活性化すること ができる。このサービス・スクリプトは正しい補助機能の開始をトリガする。こ れは、補助機能における付加的なある程度のプログラミングを必要とする。この 他に、複数の補助機能及び必要とするＳＩＢにより実現されなければならないイ ンターフェースは、組合わせに基づく解決と同一である。 第５図には、この解決例が示されている。上からＳＩＢに入る矢印は、ＳＩＢ に対するパラメータを示し、このパラメータはスクリプトを作成したときにセッ トされる。ユーザ・プロファイル５０は活性化された「マイ・サービス（ＭｙＳ ｅｒｖｉｃｅ）」５２を有する。「マイ・サービス」は、ユーザに特有のデータ 、及び補助機能用の結合モジュールに対する基準を含め、このユーザ用にそれ自 身のプロファイルを有する。このプロファイルはユーザに結合されている。この 特定的なユーザが呼に対する送出先であることを活性化された基本機能が見いだ すと、入力としてプロファイルを参照して、総称機能用のモジュールにおけるシ ステムのダイナミック結合が呼出される。このプロファイルから活性化された補 助機能への結合をトレースし、ここから結合モジュールへの結合をトレースする 。次いで、右結合モジュールを呼に結合させる（矢印５４を参照）。 ユーザが話中に切り換わるまでは、「マイ・サービス」５２が呼を操作するこ とはない。従って、スクリプトに対する第１のタスクは「話中」トリガを監視す ることである。最適化として、ユーザ・プロファイルは、話中状態が現れるまで 「マイ・サービス」のダイナミック結合が実行されないように、構築されてもよ い。これは、ユーザ・プロファイルが呼において更に多くの回数により解析され ることを必要とする。矢印５６は、待機ＳＩＢ５８が矢印６０に従って消えるよ うに強制させる「話中」トリガの動きを示す。 ここで、「マイ・サービス」５２がどのように「待ち呼」と「呼の転送」との 間の競合を取り扱うかを判断する時間となる。この場合に、「マイ・サービス」 ５２は「呼の転送」ではなく、「待ち呼」６２を実行するように判断する。他の 実施例として、ユーザ用の「マイ・サービス」プロファイルに選択を記憶するこ ともできる。矢印６４は「待ち呼」６２のダイナミック結合及び「待ち呼」の実 行開始を表す。「マイ・サービス」は、「待ち呼」における右結合モジュールに 対する大域的な基準及びそれ自身の基準により、総称機能用のモジュール４０に おけるダイナミック結合機能４２を呼び出す。後者は、「待ち呼」の動きを監視 できるように、「マイ・サービス」５２を「待ち呼」６０に結合する必要がある ということのために、必要とされる。これは、スクリプトが新しいインターフェ ースを使用するので、「マイ・サービス」における別個の結合モジュールを必要 となり得る。 「待ち呼」を開始させた後、「待ち呼」６２及び「マイ・サービス」５２は並 行して実行する。矢印６６による措置は待機ＳＩＢ６８である次にＳＩＢに進む 。待機６８は「待ち呼」からのトリガ「結果」７０を待機する。この結果は、Ｏ Ｋ：首尾よく完了した「待ち呼」、又は「待ち呼」に誤りが発生した「ＯＫでな い」ことを示す。これが到達すると（矢印７２）、待機ＳＩＢ６８は各可能結果 に対して別個的な出力を選択する。結果がＯＫならば、スクリプトを完了する。 ノーのときは、その代わりに結合ＳＩＢ７４が矢印７６により「呼の転送」７８ を結合させる。結果が「ＯＫでない」のときに、最初に「マイ・サービス」は、 呼が「呼の転送」７８に対応し得る状態にあるか否かを調べる必要があるので、 このスクリプトは完了していないことに注意すべきである。 競合を避けるためにいくつかの異なる解決が可能である。この考えにより、含 まれている補助機能の同一組合わせに対して更に多くの解決を設計し、かつこれ らを異なるユーザに適用することができる。相互作用ロジック・プレーンに構築 することは、一人のユーザに対して同時的に活性化され得る複数の補助機能の組 合わせにより判断される。相互作用ハンドラは更に多くの代替を取り扱い、かつ ユーザ・データにより適用可能な代替を判断させてもよく、又はこれらを別個の 相互作用ハンドラにより取り扱ってもよい。 相互作用問題を処理する多くの考えが存在する。従って更に、このような各考 えには利点及び欠点が共に含まれていた。例えば組合わせに基づく解決は、特に 異なる相互作用ハンドラ間の競合のために、実行すべき多量の相互作用が必要と なってしまい、これを解決するために更なる相互作用が必要となる。「柔軟性の あるサービス・プロファイル」は一人のユーザのための相互作用についてのみ処 理する。従って、各呼において、少なくとも２つのユーザが含まれており、更に 複雑な補助機能は同一呼に多数のユーザを含む結果となり得る。活性された異な る補助機能、又は新しい特定の補助機能を必要とするこれらの相互作用に対する 異なる代替を有するユーザが多ければ、新しい補助機能を含むそれだけ多くの新 しい「パケット」を設計しなければならない。 「交渉」と呼ぶ他の考えのみが「柔軟性のあるサービス・プロファィル」にお いて欠落する部分の処理を行う：ユーザ間の相互作用のみが考慮に入れられる。 本発明は多数の利点を有する。 本発明によるシステムの一つの特性は、同一の原理及び必要性がプラットフォ ームと補助機能との間のインターフェース、及び補助機能と相互作用ロジックと の間のインターフェースの両者に有効である。両インターフェースに対する主要 な必要条件は、例えば、安定して、旧バージョンと逆方向に互換性がなければな らず、かつ正しい抽出レベルを有する。これは下記の結果を与える。即ち、 −補助機能と相互作用ロジックとの間のインターフェースは、プラットフォー ムと補助機能との間のインターフェースの既に存在する実施から、既に獲得した 経験及び獲得すべき経験の利点を利用する。後者のインターフェースを制御する 原理が正方向である限り、最初に述べたインターフェースは同様に正方向に展開 される。各アーキテクチャに絶対的に必要なことは、安定があり、かつ前のバー ジョンと逆方向に互換性のあるインターフェースに対して原理を定義し得ること である。そうでなければ、プラットフォームと補助機能との間のモジュール構成 は存在し得ず、それ自体が補助機能に対する導入サイクルを短くしようとするこ とになり得る。このために、このような原理をどのように定義するかに大きな注 意が向けられていた。 −目標を達成するために、インターフェースを実現する製品は明確な構造を有 する必要がある。従って、このようなインターフェースの実現は、補助機能の総 合的な品質の改良を意味する。 −仕様及びインターフェースの実現を簡単にするために新しいツール及び言語 が開発されている。いくつかの言語はオープン・インターフェース、例えばＰａ ｓｃａｌ、Ｃ＋＋に対する別個的な仕様を既に含んでいる。補助機能と相互作用 ロジックとの間のインターフェースは、この領域内における各仕様の利点を直ち に利用することができる。 −新しいツール及び言語は仕様及び補助機能の実現を簡単にするために、例え ば言語、ＳＩＢを明確にするために開発されている。これらの多くは、補助機能 によいオープン・インターフェースを使用することを仮定している。本発明によ り、要求される相互作用を実現するために同一のツール及び言語を使用してもよ い。従来のアーキテクチャは本質的に検出用のテーブル及び解決のための優先順 位調整に基づいている。これらは、これら新しい技術の利点を利用するものでは ない。 本発明によるアーキテクチャの他の特性は、補助機能データ及びコードの最適 な再使用である。 −補助機能の他の機能は、相互作用により直ちに影響される機能よりも、変更 される必要はなく、解決ロジックが補助機能の通常機能を実現する必要性は決し てないので、以後、設計において競合を見い出すことはほとんどない。これは相 互作用のより速い実行に至る。 −補助機能が協調モジュールに情報を積極的に送出しなければならない場合と なり得る「場合に」何も情報を記憶する必要がないので、メモリ及びプロセッサ 容量の最適使用が更に容易に達成される。相互作用構成要素のダイナミック結合 を取り扱う機能がより効果的であれば、それだけ得られる利点が大きい。この機 能は総称機能用のモジュールの一部を形成するので、補助機能又は相互作用ハン ドラに影響することなく、これを改良することができる。 本発明は、補助機能の設計を簡単にすることよりも、通常のアーキテクチャの ものと反対の効果を得ること、及びそこから来る付加的な複雑さを複数の相互作 が取り扱うようにさせることである。通常のアーキテクチャは、補助機能の設計 を簡単化することを目的とし、従って相互作用の設計を複雑化している。これは 、それぞれ新しい補助機能とともに連続的に増大する相互作用に対する代償であ る。従って、本発明はより予測可能及び安定なリードタイムが得られるばかりで なく、補助機能の合理的な量を既に有するシステムにおいてより短い平均リード タイムが得られる。

───────────────────────────────────────────────────── 【要約の続き】 能に対して結合可能である。

Claims (1)

1. 【特許請求の範囲】 １．複数のユーザを含む通信網における複数の基本機能及び複数の補助機能の 使用を取り扱うシステムであって、前記複数のユーザが通信網を介して相互に通 信することができ、かつ複数の基本サービス及び複数の補助サービスに加入する ように許可されて、前記基本機能及び補助機能についての使用をそれぞれ可能に させる前記システムにおいて、 前記基本機能を含み、かつそれぞれが１以上の前記補助機能を前記プラットフ ォームに結合させる補助機能インターフェースを実現させるプラットフォームで あって、各補助機能は、前記補助機能が使用する必要性のある前記各インターフ ェースについて１つとする１以上の補助機能結合モジュールからなり、前記補助 機能結合モジュールは補助機能プレーンに配置されている前記プラットフォーム と、 前記補助機能間の競合を検出して解決するとと共に、相互作用ロジック・プレ ーンに配置された相互作用ロジック結合モジュールからなる相互作用ロジックで あって、前記補助機能と補助機能インターフェースが前記相互作用ロジックに対 して透過伝送性であり、かつ前記相互作用ロジック結合モジュールが前記補助機 能に結合可能な前記相互作用ロジックと を含むシステム。 ２．前記相互作用ロジック・プレーンは、それぞれが特定の競合を解決するこ とができる多数の相互作用ハンドラ機能を含む請求項１記載のシステム。 ３．各相互作用ハンドラ機能は各補助機能用の少なくとも一つの結合モジュー ルからなり、その補助機能インターフェースは前記相互作用ハンドラ機能により 用いられる請求項２記載のシステム。 ４．新しい補助機能は、他の補助機能との相互作用を取り扱うために必要とさ れる異なる相互作用ハンドラ機能における必要とする全ての結合モジュールと共 にシステムに導入される請求項３記載のシステム。 ５．相互に依存する同一の相互作用ハンドラ機能における結合モジュールは、 ローディング・モジュールを形成している請求項４記載のシステム。 ６．結合モジュールを最早使用しない場合は、前記結合モジュールが含まれて いる前記ローディング・モジュールを除去する請求項４記載のシステム。 ７．補助機能により実現され、かつオペレーションの形式によりいくつかの総 称部分、及び異なる補助機能において同一となる複数のトリガを含む請求項１な いし６のうちのいずれかに記載のシステム。 ８．前記相互作用ロジック・プレーンは更に複数の補助機能とプラットフォー ムとの間で複数のインターフェースを使用する前記いずれかの請求項記載のシス テム。 ９．前記相互作用ロジック・プレーンは複数の付属結合モジュールにより検出 プレーン及び解決プレーンに分割される請求項８記載のシステム。 １０．前記解決プレーンはいくつかの解決モジュールに同一の検出モジュール を用いられるように構築されている請求項８記載のシステム。 １１．前記検出プレーンは複数のトリガのみからなる複数のインターフェース を実現することができる請求項９又は１０記載のシステム。 １２．前記解決プレーンは、補助機能により実現されたインターフェースを直 接使用するために前記検出プレーンを無視する複数のオペレーションを含む請求 項１１記載のシステム。 １３．前記異なる複数のプレーンがよく類似し、かつこれらにより用いられる 総称機能用、かつ複数のインターフェースを取り扱うモジュールを備えている前 記請求項のいずれかに記載のシステム。 １４．ダイナミック結合を取り扱う複数の機能は、前記総称機能用のモジュー ルに含まれる請求項１３記載のシステム。 １５．複数の補助機能の実行を計画する機能は前記総称機能用のモジュールに 含まれる請求項１３又は１４記載のシステム。 １６．前記計画する機能はプラットフォームの機能又は補助機能により活性化 される請求項１５記載のシステム。 １７．前記総称機能用のモジュールは、複数の補助機能が実行する一定の計画 を変更するオペレーションを受け取るように適応されている請求項１３ないし１ ６記載のシステム。 １８．前記総称機能用のモジュールには、同一の補助機能にある異なる複数の 結合モジュール間の複数のプレーンにおける通信を取り扱う複数の機能を含む請 求項１３ないし１７記載のシステム。 １９．総称機能用の前記モジュールは前記プラットフォームにおける通信を取 り扱う複数の機能を含む請求項１３ないし１８のうちのいずれかに記載のシステ ム。 ２０．一組の基本機能及び一組の補助機能であって、前記各補助機能は該基本 機能に対する付加の形成、及び該基本機能の変更を行うように一定の基本機能に 接続可能であり、前記基本機能は１以上のインターフェースを実現し、その機能 性は補助機能に特有でなく、かつ前記基本機能に影響することなく、前記システ ムに付加されるべき新しい補助機能を許容する形式により、前記基本機能と前記 補助機能との間の相互作用を許容する前記一組の基本機能及び前記一組の補助機 能と、 相互に競合する特定の基本機能に同時に接続される２つの補助機能の各々の動 きから発生する問題を解決する相互作用ロジックと を含むように構築された通信システムにおいて、 前記相互作用ロジックは複数の相互作用モジュールを含み、 各補助機能は、そのインターフェースの使用により前記補助機能と相互作用す ることを意図して、新しい複数の相互作用モジュールを前記補助機能に影響する ことなく、前記システムに付加させる形式により、前記相互作用モジュール間の 相互作用を許容する少なくとも一つのオープン・インターフェースを実現し、前 記オープン・インターフェースは前記補助機能間の競合を避ける形式により補助 機能と相互作用するように前記複数の相互作用モジュールにより使用される通信 システム。 ２１．前記相互作用ロジック・プレーンは、それぞれが特定の競合を解決する ことができる多数の相互作用ハンドラ機能を含む請求項２０記載のシステム。 ２２．各相互作用ハンドラ機能は各補助機能用の少なくとも一つの結合モジュ ールからなり、前記補助機能インターフェースは相互作用ハンドラ機能により用 いられる請求項２１記載のシステム。 ２３．新しい補助機能は、他の複数の補助機能との相互作用を取り扱うために 必要とされる異なる相互作用ハンドラ機能において必要とする全ての結合モジュ ールと共に前記システムに導入される請求項２２記載のシステム。 ２４．相互に依存する同一の相互作用ハンドラ機能における複数の結合モジュ ールはローディング・モジュールを形成する請求項２３記載のシステム。 ２５．結合モジュールを最早使用しない場合は、前記結合モジュールが含まれ ている前記ローディング・モジュールを除去する請求項２４記載のシステム。 ２６．補助機能により実現され、かつオペレーションの形式によりいくつかの 総称部分、及び異なる複数の補助機能が同一となる複数のトリガを含む請求項２ ０ないし２５のうちのいずれかに記載のシステム。 ２７．前記相互作用ロジック・プレーンは更に複数の補助機能とプラットフォ ームとの間で複数のインターフェースを使用する前記いずれかの請求項記載のシ ステム。 ２８．前記相互作用ロジック・プレーンは複数の付属結合モジュールにより検 出プレーン及び解決プレーンに分割される請求項２７記載のシステム。 ２９．前記解決プレーンはいくつかの解決モジュールに同一の検出モジュール を使用できるように構築されている請求項２７記載のシステム。 ３０．前記検出プレーンは複数のトリガのみからなる複数のインターフェース を実現することができる請求項２８又は２９記載のシステム。 ３１．前記解決プレーンは、補助機能により実現されたインターフェースを直 接使用するために前記検出プレーンを無視する複数のオペレーションを含む請求 項３０記載のシステム。 ３２．前記異なる複数のプレーンがよく類似し、かつこれらにより用いられる 総称機能用、かつ複数のインターフェースを取り扱う総称機能用のモジュールを 備えている前記請求項のいずれかに記載のシステム。 ３３．ダイナミック結合を取り扱う複数の機能は、前記総称機能用のモジュー ルに含まれる請求項３２記載のシステム。 ３４．複数の補助機能の実行を計画する機能は、前記総称機能用のモジュール に含まれる請求項３２又は３３記載のシステム。 ３５．前記計画する機能はプラットフォームの機能又は補助機能により活性化 される請求項３４記載のシステム。 ３６．前記総称機能用のモジュールは、複数の補助機能を実行するある計画を 変更する複数のオペレーションを受け取るように適応されている請求項３２ない し３５記載のシステム。 ３７．前記総称機能用のモジュールは、同一の補助機能により異なる複数の結 合モジュール間の複数のプレーンにおける通信を取り扱う複数の機能を含む請求 項３２ないし３５記載のシステム。 ３８．総称機能用の前記モジュールは、前記プラットフォームにおける通信を 取り扱う複数の機能を含む請求項３２ないし３７のうちのいずれかに記載のシス テム。