JP2002516652A - 通信および情報処理ネットワークのサービスに対し汎用的に互換性のあるソフトウェア・システム - Google Patents

Abstract

(57)【要約】 機能相互動作を制御し、通信ネットワークの異なるサービス機能、リソース、端末間で互換性を保証する方法を提供する。リソース装置と端末は、要求またはイベントを発生するとき、インタフェース・エージェント・モジュールを介して、互換性メッセージ・バスをアクセスする。例えば、メッセージ・バスは任意の長さのイーサネットであってもよく、すべての装置にアクセス可能である。また、リソース装置と端末は、ＰＢＸまたは交換オフィスのコンピューティング・プラットフォーム中の、または交換機またはＰＢＸから分離した一般的なコンピューティング・プラットフォーム中の１以上の互換性コントローラにアクセス可能である。要求とイベントを処理する一時的な互換性制御モジュールは、データベースに記憶された処理ルールを検索することによって構成され、制御された方法で、呼び出されたサービス機能の供給を保証する。

Description

【発明の詳細な説明】 発明の名称 通信および情報処理ネットワークのサービスに対し汎用的に互換性のあるソフ トウェア・システム 発明の分野 本発明は、一般的には、通信ネットワークサービスの供給に関する。特に、エ ンド・ユーザ・サービスのようなネットワーク・サブシステム間に互換性を持た せるソフトウェア・システムに関する。さらに詳細には、任意の特定のサブシス テム、サービスまたは装置の性質から独立した汎用システム・アーキテクチャお よび方法に関する。さらに詳細な好ましいアプリケーションでは、互換システム は、スタンドアロン・ネットワーク・サービスの間でリアルタイムでの相互動作 を可能にし、音声メール、電話帳アシスタンス、対話式音声応答およびインター ネット・サービスのような機能間でリンクを供給するソフトウェア・パッケージ のファミリを含む。このアプリケーションは電気通信サービスのためであるが、 汎用システムは相互動作スタンドアロン情報処理サービスであってもよい。この アプリケーションは、安定したリアルタイムの性能が要求され、サービス間での 相互動作は明示された文脈依存による仲裁を必要とするところに、独自の価値が ある。 従来技術 現在のシステム環境、例えば、電話では、スタンドアロン・サービスは、十分 な機能を提供するように設計されている。これらのスタンドアロンのサービスは 、呼び出されて使用され、およびサービスを実行するために呼び出されてもよい 。しかしながら、スタンドアロン装置は、他のスタンドアロン装置と通信する方 法を持たない。このように、装置とサービスは統合されていないし、概して、互 いに通信しない（つまり、データまたは資源を共有しない）。統合されないとき は、特別に、特定の問題について特定の解決を行うプログラマが統合し、自社独 自の システムの１つのベンダ・クラスタを販売する装置の製造業者に通常に供給され る。 １９９５年４月４日に発行されたブレナン（Ｂｒｅｎｎａｎ）の米国特許５， ４０４，３９６「機能相互動作マネジャ」は、電話システムにおいて知られてい る特定の問題を「機能相互動作」として記述している。電気通信交換ネットワー ク内で提供された利用可能な機能の数が増えるにつて、機能間で可能な（制御で きない）相互動作は非常に重要になり、加入者に対しては、ネットワーク内の故 障と潜在的な混乱の原因となる。このため、機能マネジャは、機能の異なる側面 が調和して働くような方法で、各機能の機能を管理する交換システム内に供給さ れる。機能マネジャは、発生する各イベントを監視し、そのイベントに対し呼出 しおよび／または制御を要求する機能を実行するソフトウェア・ブロックの機能 論理にそのイベントを送る。しかしながら、１以上の機能が同じイベントを要求 すると、状況はより複雑になり、他の機能が加入者に用いられると、ある機能に 対するアクセスは、一時中断し、および／または優先される。解決策として、ネ ットワーク内の電気通信交換プラットフォームとそのプラットフォームを用いて いて加入者に呼機能を供給する機能論理との間に、相互動作マネジャ（ＦＩＭ） を挿入することが挙げられる。制御は、交換システム内でのイベントの検出と機 能論理による電気通信サービスの実行との間のインタフェース内に挿入され、加 入者に提供される複数機能のうちの種々の機能の相互動作を管理する。このシス テムは、ネットワーク内でイベントを評価し、各機能を他の機能から隔離し、相 互動作マネジャのみを介して、それらを関連づける。 情報処理の分野において、１９９６年６月６日にＷＯ９６／１７２９６の番号 で公開された国際出願ＰＣＴ／ＵＳ９５／１５４３２、「クライアント・サーバ 環境におけるメッセージ駆動プロセッサを実行する方法および装置」は、以下の ように要約される。 メッセージ駆動プロセッサは、大きなクライアント・サーバ・システム中のク ライアントとバックエンド・ホストまたはサーバ間のミドルウエアとして動作し 、ネットワークによるサポートを要求する現在のセッション数を減らし、共通の クライアント・ユーザ・インタフェースが、バックエンドシステムと異なるよう にする。ビジネス機能のサポートに関するクライアントからの高度な要求は、メ ッセージ駆動プロセッサによって、バックエンド・サーバへの複数の要求を含む 作業の流れに翻訳される。作業の流れに起因する情報とバックエンド・サーバか ら検索された情報は、要求したクライアントに対する単一の応答メッセージに統 合されてもよい。 発明の概要 電話における問題は、前提違反が相互動作の説明不可能な機能の主な原因であ るということである。これらの相互動作は、典型的には、知らないで既存の技術 の前提に違反する新しい機能やネットワーク性能が導入されたときに発生する。 通常の応答は、環境の新たな変化に対処する現存の（「遺産」と呼ばれる）サー ビスの定義と実行を複雑にする。この結果、システムは、将来の変化に対して、 試験がより困難になり、より柔軟性がなくなる。 一例として、通話中着信サービスを考えてみる。通話中着信の基本的概念は、 新たな呼が到着したことをユーザに知らせ、その呼に応答するためのメカニズム をユーザに供給することである。実際、サービス論理は、いつ警告が発せられる のか（いつ、呼が「安定している」のか、つまり、いつ、呼の処理が進んでいな いのか）、どんな種類の警告が発せられるのか（特に「ビープ音」）、どのくら いの数の呼が「待ち」状態にあるのか、また、呼に応答する方法（例えば、フッ ク・フラッシュ）に対する制限についての多くの前提を有する。これらの制約は 、ＰＯＴＳ（従来の電話サービス）に関連するが、ＩＳＤＮを有するシステム、 複雑化した端末、または、より多くの有能なブリッジに対しては関係がない。ユ ーザが、異なる目的のために同じ信号（同じＤＴＭＦ信号のような）を用いる他 のサービスを持つとしたら、この制約は問題を引き起こすことになる。このよう な制約は、サービス定義の一部であってはならないし、実行のために符号化され る ベきでない。そのかわり、ネットワーク資源とサービス論理間の相互動作（すな わち、通信のためにより広く、より知的な性能）をより豊富にすることによって 、これらは取り扱われるべきである。本発明で提案するアーキテクチャは、これ らのより知的な相互動作をサポートする。 前提違反から発生する相互動作のタイプを理解する上で、役割という概念も役 立つ。現在の電気通信システムにおいては、種々のエンティティによって、多く の役割が行われている。ユーザは、所有者、加入者、請求金額支払い者、被呼側 、呼調整者、その他の役割を果たしている。サービスは、通話中の処理機能、呼 終端ブロック、呼の再送信、および通常の呼処理をデフォルト動作に置き換える 他の多くの役割を果たす。これらのエンティティが果たす種々の役割の分離が進 んでいないことは、現在のシステムにおけるＦＩの重要なソースとなる。役割の 混同は、以下のようである。 ・ 例えば、サービスが、電話機の所有者がサービス・ユーザであるという前 提をハードコード化するとき、請求が間違った相手に行くことがある。 ・ システムは適切に呼の宛先を決定できないため、呼は、意に反して、また不 適切に遮断され、または間違った相手に送られることがある。 役割の混同は、部分的にシグナリングのあいまいさを引き起こす。これは、サ ービス論理は、しばしば、１つのサービスは、特定の信号または機能のユーザだ けであると前提していることがあるためである。たとえば、これは、顕著な呼サ ービスに対し特定の警告パターンを論理にするようなものである。例えば、サー ビス論理は、他のサービスはフック・フラッシュを用いないと前提する場合であ る。サービスは、ときには、「通話中」に関連する観念だけが、スイッチによっ て報告されるイベントである（加入者はビジーである）と前提し、一組のサービ スが論理ハントグループを作る可能性を無視するため、「通話中」は、そのグル ープのすべての端末が使用中であるという意味になる。 解決策の一般的な特徴 電話ネットワークのような大きなシステムのコンポーネントを小さい分離サブ システムに分離する適切な理由はたくさんある。主な理由は、システムが理解し やすくなり、修正しやすくなるということである。ＦＩに関しては、他の理由が 重要になってくる。電気通信システムを構成エンティティに分割することによっ て、サービスの設計者やシステム・ユーザに利用可能な一組の特性や構内を決定 する。もし構内が適切に選択されれば、設計者やユーザが、サービスの混同、不 明瞭、およびその結果、ＦＩ制御の不可能を回避するために必要な区別を表現で きる。 制御不可能なＦＩの原因や理由、電気通信機能の詳細や広帯域サービス要求に 対して以前行われた作業は、電気通信システム内の特定の区画化、または分離を 示し、多くの場合のＦＩを減少させるか、または除去する。特に、以下の分離が ある。 ・ 端末からのユーザの分離 ・ 接続からの呼の分離 ・ サービスからのユーザ・セッションの分離 ・ ネットワーク／リソースの管理からのサービスおよびユーザ・セッション の分離 上記の分離は、電気通信システムで発生しうる相互動作を減少する重要な機会 を表わす。 上にリストされた特定の分離に加えて、電気通信アーキテクチャにおける分離 化は、（ビジー警告のような）特性とこれらの特性の物理的な表示（例えば、特 定の信号）との区別を暗示している。また、分離化は、システムを、それぞれが ある役割を割り当てられているコンポーネントに分離することを暗示している。 提案されたアーキテクチャは、以下の論理機能のサポートによって下記のよう に分離される。 すなわち、 ・ ユーザのプロファイルと好みを強化するプログラム、 ・ 端末、スイッチ、ブリッジ、対話式音声（またはビデオ）応答装置などの リソースを制御するプログラム、 ・ サービスの基本論理を実行するプログラムである。 この分離化は、エージェント・ベースのアーキテクチャ中で、各タイプのエン ティティ（ユーザ、リソース、およびサービス）を表わすソフトウェア・エージ ェントを使用することによって達成され、必要な互換性を供給する。このアーキ テクチャの意図するところは、アーキテクチャに直接統合された前提の数を大幅 に減少させることである。それによって、新たなサービスは既存のサービス（「 遺産」と呼ばれる）と共に適切に動作できる可能性が増す。 アーキテクチャにおいて、基本的なエンティティは下記の通りである。 ・ リソース（端末装置、ネットワーク装置、音声回路、ブリッジ、シグナリ ング・チャネル、信号およびデータベース）、 ・ ユーザ（発呼者、被呼側、請求者、サービス・プロバイダ、装置の所有者 を含む）、 ・ サービス（論理機能自体）、 ・ ユーザ、リソースおよびサービス間で送られる信号 互換性によって、呼センタ、顧客データベース、音声メール・システムおよび データベースのようなサービスは、セッション情報を共有し、協動してセッショ ン・イベント（呼の発信元またはユーザ・データ入力）に応答できるようになる 。また、互換性は、マルチサイト電気通信を簡素化して、音声メール・サーバや ネットワーク・データベースのようなリソースが、首尾一貫してより効率よく用 いられるようになる。 今日、このレベルの統合が行われるケースはほとんどない。さらに典型的には 、 個々の音声またはデータ電気通信サービスは、独立して機能システム上に供給さ れる。例えば、ある製造業者の製品によって音声メールが供給され、別の業者に よって自動発呼分配（ＡＣＤ）た供給され、さらに別の製品によって対話式音声 応答（ＩＶＲ）が供給されてもよい。顧客データまたは会社の電話帳は、通常、 これらの製品から分離したデータベース上に保存される。企業または運搬業者が 提供したい各サービスに関しては、１以上の専用システムを購買しなければなら ない。また、各システムが「プログラム可能性」をある程度供給することもでき るが、限定された場合以外はほとんど共に動作することはない。スタンドアロン 電気通信サービスまたはデータベース間でいくらかのリンケージを供給するシス テムはいくつかあるが、これらは、通常、特定の業者の製品、またはＡＣＤシス テムのような特定の製品に限定される。 この統合を行うために、互換性は、スタンドアロン・システムを目的物の集合 として取り扱う。これらは、その後、ソフトウェア・バスに「プラグ接続」され る。これは、スタンドアロン・コンピュータとプリンタが、物理的通信ＬＡＮに プラグ接続できるのとほぼ同じである。一度、スタンドアロン・システムが共に プラグ接続されると、互換性はそれらの相互動作を容易にする。スタンドアロン ・プラットフォームはどの業者の製品でもよい。 全体的に、互換性の価値は、「キラー・アプリケーション」にはなく、新たな ネットワーク機能と製品と同様に、遺産（すなわち、既存の）サービスと性能と を互いに統合して経費を節減する能力にある。これは、電気通信環境において処 理する一方、スタンドアロン・サービス・プラットフォームの所有者に、サービ スをカスタマイズさせて、特定のマーケットの必要性に適合するようにさせる。 本発明の方法は、通信、情報処理および同様のネットワークのサービス間に互 換性を与えるために供給され、以下のステップを含む。 （ａ） ソフトウェア・エージェント・モジュール（ＳＡＭ）を各サービス・リ ソース装置（ＳＲＤ）に割り当てて、上記のＳＲＤをソフトウェア・メッセー ジ・バス（ＳＭＢ）にインタフェースさせる。 （ｂ） ネットワーク参加者によって初期化された各サービス・セッションのた めに、一時的なソフトウェア互換性制御（ＣＣ）を生成する。 （ｃ） 上記のＣＣモジュールを少なくとも２つのサブモジュールに区分する。 その１つは、ネットワーク参加者からの要求を送信するためのＲＨである。他の １つは、ＳＡＭを介して、選択されたＳＲＤをアクセスするためのイベントを発 生させ、上記のＲＨによって生成されたイベントを取り扱うためのＥＨである。 ここで、ネットワーク参加者とは、プロキシまたはエージェントによって表さ れる任意のサービス、リソース、またはエンティティを意味する。 図面の簡単な説明 本発明の好ましい実施の形態は、以下の図面によって説明される。 図１は、インテリジェント電話ネットワーク内の好ましい互換性制御の分布を 示す概略図である。 図２は、図１に示された互換性制御の機能ブロックを表わす高レベルブロック 図である。 図３は、図２に示された互換性制御のエージェント・ベースのアーキテクチャ を示す図である。 図４は、所定のサービス・リソース装置に対する要求に続く相互動作のフロー を示す高レベルのフローチャートである。 図５は、図４の相互動作からイベントが生成されたときの処理のフローを示す 高レベルのフローチャートである。 図６は、個人的なエージェント・メタ・サービスの特定の例に対するＣＣエー ジェントとプロキシ間の相互動作のフローを示す図である。 発明の実施の形態 図１は、本発明の互換性システムが動作する全体的なネットワーク環境を示し ている。図示された電話ネットワークは、ＰＢＸ、ＡＣＤなどのスイッチング・ オフィス（ＳＯ）１０中にあるノーザンテレコムのＤＭＳ^TMまたはルーセント＃ ５ＥＳＳスイッチのような接続を行う手段を含む。メッセージ互換性バス１１は 、互換性コントローラ（ＣＣ）１２によってアクセスされる。互換性コントロー ラ（ＣＣ）１２Ａモジュールは、ＳＯ１０のコンピューティング・プラットフォ ーム内にあり、メッセージを、互換性（Ｃ）モジュール１２Ｂ、１２Ｃ、１２Ｄ 、１２Ｅ、１２Ｆ、１２Ｇと交換する。これらのモジュールは、それぞれ、電話 システムのサービス制御ポイントＳＣＰ１３、および一般的コンピューティング ・プラットフォーム１４（これは、他の互換性コントローラをサポートしてもよ い）、対話式音声応答ＩＶＲシステム１５、音声メール・システム１６、Ｅメー ル・メッセージ交換システム１７、または音声認識システム１８のような他のリ ソース中に、そのうちの一部だけが存在していてもよい。これらは、単に一例で あり、リソースや他のもの（図示せず）が存在してもよい。もし、相互動作の互 換性が互換性制御モジュールを介して存在していなければ、これらのリソースと システム（すなわち、機能）は非制御的に相互作用してもよい。また、ＳＰＣ１ ３は、電話システムの性質によって、存在してもしなくてもよい。一般的に、イ ンテリジェント・ネットワーク（ＩＮ）でそれは存在するが、もし、ＳＯ１０が 単にＰＢＸまたはＡＣＤであるなら、存在しなくてもよい。 図２は、互換性制御のソフトウェア・システム・コンポーネントをさらに詳細 に示している。ＣＣ１２Ａ（１２Ｃのような一般的なコンピューティング・プラ ットフォームにも存在しうる）の必須サブシステムは、要求ハンドラ（ＲＨ）２ ０とイベント・ハンドラ（ＥＨ）２１である。ソフトウェア・エージェントまた はプロキシ（Ａ／Ｐ）１〜Ｊは、例えば、ＣＣサブモジュール１２Ｄから１２Ｇ に対応し、インタフェース・リソース装置（ＲＤ）１〜Ｊは、それぞれ、Ｃバス １１を介して、システムの残りに対応する。また、データベース（ＤＢ）２２は 、Ｃバス１１を介して、処理器２３を介してアクセス可能になる。 図３は、互換性システムの実行時間環境を示している。一般的には、実行時間 環境はセッション用のソフトウェアの実行をサポートしている。これは、種々の サポート機能（ロケータ、アドレス決定器など）へのアクセスを含む。これらの 機能はセッションによって用いられるが、セッションのために作られた特定の例 の部分ではない。例えば、実行時間環境は動作システムとＯＲＢ（対象要求ブロ ーカ）を含み、いくつかのデータベースと任意のソフトウェア機能は、実行中に 、セッションによって用いられる。実行時間環境以外のソフトウェアは、データ ベースまたはサポート機能の中で、情報を変更するために存在することがよくあ る。このように、互換性システムは、実行時間環境と実行時間環境をサポートす る環境とから作られる。実行時間環境は、コントローラ、エージェント、プロキ シとから成る。コントローラは、各ユーザがサービス・セッションをアクティブ にするために存在する。コントローラは、サービス・セッションの実行中に、イ ベントと要求を取り扱う。エージェントはシステム内の機能を表し、イベントま たは要求を介してコントローラと相互作用する。プロキシは、遺産装置を扱うエ ージェントの特別なタイプである。これらの装置は、互換性イベントを理解する ことができない。 エージェントは、互換性システム内で、いくつかの種類の機能またはサービス を示す。これらは２つの主な役割を果たす。サービスを行っているとき、エージ ェントは、サービスの、または、できればサービス全体の機能コンポーネントを 生成するために、いくつかの論理的な方法で、互換性コントローラのリソースお よびサービスを要求する。エージェントはコントローラに対して要求する。この コントローラは、できれば、要求したエージェントに、要求されたリソースまた は情報を戻す。制御がエージェントに戻されると、エージェントはサービス論理 を実行できる。リソースを表わしているときには、エージェントは、それらの機 能を表わしているイベントに応答することができる。このモードにおいて、エー ジェントは、他のエージェントの機能を用いて、要求されたタスクを完了するこ とは可能である。 プロキシは、翻訳問題のどれかを扱うエンティティ（特別なエージェント）で ある。この翻訳問題は、異なるハードウエアやソフトウェア・システムにリンク しようとするときに発生する。プロキシは、必要に応じて、サービスを伝達する ことによって、情報を１つの形態から他の形態へ翻訳する。プロキシの性質は、 本来構文的であり、また意味論的でもある。意味論的であるため、プロキシは、 含まれる各パーティに、記述に意味があることを確実に理解させることができる 。一方、プロキシは構成的であるため、プロキシは特定のメッセージのパラメー タを、確実に適切な順序にする。プロキシの２つの属性は、効率の良い通信が行 われるために必要である。プロキシは、通信を行う２つのシステム間のインタフ ェースとして作用する。プロキシとエージェント・インタフェースは、互換性コ ントローラ（１２Ａまたは１２Ｃ）に接続される。これは、コントローラが利用 可能な「システム呼」を実行するのが可能であると理解しているためである。こ れは、互換性システムもまた、どのようにそのパラメータに命令するかを知って いるという意味である。 最も基本的なレベルでは、互換性コントローラはイベント・ルータであり、要 求プロセッサである。複数のエージェントを管理することは、互換性コントロー ラの仕事である。このコントローラは、それが供給する各サービスによってルー ルが与えられ、これらのルールはコントローラの動作を支配する。サービスを生 み出すシステム設計者は、サービスの動作を支配する。基本的には、エージェン トは、コントローラを用いて、所定のイベントへの関心度を記録する。イベント が発生すると、コントローラは、前に関心を記録した任意のエージェントに、イ ベント情報を送る。コントローラはサービスがどのように働くかを知る必要はな いが、ただ、要求されたサービスをどこで探すか（これは「リソース・ハンドラ 」を介して行われてもよい）、およびどのメッセージが所定のサービスに関心が あるかをどのようにして知るかを知る必要がある。コントローラは呼処理中に各 「ユーザ」に対して呼び出される。このため、呼（音声メール検索のような）中 に１つのユーザしか存在しない場合には、１つのコントローラしか存在しない。 会議呼のような呼の中に複数のユーザがあり、ユーザが他のアクティブなサービ スをも有する場合には、これらは、それぞれ、それ自身のコントローラを構成す る。 コントローラ、例えば、１２Ａは、環境をサポートすることによって、ユーザ ／呼セッションの開始点において、処理器２３を介して開始される。このとき、 コントローラには、セッションのコースに対して、ＤＢ２２からのプロファイル がロードされる。このプロファイルはルールの形式で提供される。このプロファ イルは、コントローラが、イベントと要求とを扱えるようになるために必要な情 報である。 互換性コントローラは、コントローラの役割において特定のタスクを実行する サブモジュールから成り立つ。コントローラ１２Ａ（または１２Ｃ）の２つの主 なサブ・コンポーネントは、イベントを扱うために必要な処理を供給するイベン ト・ハンドラ（ＥＨ）２０と、コントローラに対する要求を扱うハンドラ（ＲＨ ）２１である。コントローラの主な機能の１つは、機能間で相互動作を扱うこと である。この主な機能の１つは、情報の流れを管理するために、イベント・ハン ドラ（供給されたルールを有する）を用いる方法で相互動作を扱う。これも、要 求ハンドラによって、ネットワーク内で機能を再使用できる。 ＥＨ１２は、ＣＣ１２Ａ内で、ＣＣ１２Ａに提供されたルールを用いて、どの エージェントまたはプロキシ（Ａ／Ｐ１からＡ／ＰＪ）がイベントを知らされる べきかを決定する。ルールは、静的（この場合、一度コントローラが生成される と、変更不可能）、または、動的（この場合、ルールを変えるまたは除去するこ とは可能）である。コントローラが生成された後で、動的なルールを追加したり 、変更または除去することは可能である。これらの新しいルールまたは変更は、 エージェントまたはプロキシのどちらかで表わされるサービスによって要求され る。新たなイベントを受け取るとき、ＥＨ１２は、どのエージェントまたはイベ ントに対してイベントが利用可能になるかを決定するために、イベントに供給さ れるルールとデータを用いる。これは、非常に柔軟性があり強固な装置を提供し 、システムを介して制御と情報の流れを提供する。これが用いられると、機能相 互動作管理メカニズムが実行され、複数のサービス（エージェントまたはプロキ シに よって表わされる）は、新しいサービスが付加されたときにも、既存のサービス を変更する必要なく、効率よく相互動作できるようになる。 ＲＨ２０はコントローラに対してなされた要求を取り扱う。ＲＨ２０は、要求 を完遂でき、またはコントローラ内の動的ルールを修正できるプロキシまたはエ ージェントのどちらかを発見するための要求が供給された情報を用いる。プロキ シまたはエージェントが発見されると、ＲＨ２０はイベントを生成して、エージ ェントまたはプロキシを呼び出すことができる。このイベントは、ＥＨ２１上に 送られ、特定のエージェントまたはプロキシに機能の実行をさせる前に、任意の 機能相互動作の詳細がＥＨ２１によって取り扱われるようにする。要求がコント ローラ内で動的なルールを修正する場合、ＲＨ２０はこれを試みる。適当な許可 があると仮定すると、コントローラ内のルールは、制御または情報の流れを変え るように変更することができる。このメカニズムは、コントローラの動作を要求 するエージェントまたはプロキシを、呼処理の残りの動作に影響を与えるように 変更する。 ＲＨ２０を有する重要な利点は、（所定の機能を要求する）エージェントまた はプロキシが、以下の先験的な知識を要求しないことである。 ・ どの機能が利用可能であるか； ・ どこに機能があるか； ・ どのように機能が実行されるか。 ＲＨ２０は、既存のサービスの呼出要求と同様、リソース機能を探す要求を取 り扱うことができる。これは、他のサービスを呼び出すサービスを可能にするだ けでなく、新しいサービスのためのネットワークで、既存の機能を再使用する能 力も可能にする。このため、簡単に、統合されたサービスをエンド・ユーザに提 供できる。 このように、ＣＣ１２Ａは、複数のサービスが相互動作するための基本的なメ カニズムを供給できる。これらのメカニズムは、多くのネットワーク要素上のサ ービスを組み合わせることが可能である。これらのメカニズムの基本は、それら がイベント駆動されていることである（ＥＨを使用することになる）。任意の相 互動作の振る舞いは、２つのソースからＣＣ１２Ａに与えられたルールによって 制御される。１つ目のソースはサービスであり、もう１つのソースは、ユーザ・ サービスの組を作るサービス統合器またはブローカである。 ルールを相互動作させるいくつかの機能は一般的であり、無効とされる他のル ールが存在しないところで用いられる。これらのルールは、イベントがサービス の１つによって「消費」されるまで、最近、アクティブになったサービスとその 後のサービスに、イベントを送ることを含む。 図３は、エージェント・ベースのアーキテクチャによる一般的な互換性システ ムを示している。このアーキテクチャは、エンド・ユーザのために電話サービス をサポートするために共動する１組のエージェントから成る。各エージェントは 、ネットワーク中で特定の役割を持ち、それに従って行動する。データとプロセ ッサ論理は各エージェントに付属し、エージェントがこれらの役割を果たせるよ うにする。 ３つのタイプのエージェント、すなわち、ユーザ・エージェント、リソース・ エージェント、およびサービス・エージェントは、アーキテクチャ中で供給され る。Ｆ１を最小化し制御するそれらの特性に沿って、各タイプのエージェントの 基本特性を、以下に説明する。 特定のエージェントに関する明示された割り当てによって、分離が行われるよ うにする。ユーザと端末との分離は、区別されたユーザと端末リソース・エージ ェントの生成を介して達成される。呼と接続の分離は、ユーザ・エージェントに よる呼の管理（すなわち、セッションを介して）と、分布ネットワーク・リソー スの能力を表わす接続リソース・エージェントによる接続とを介して達成される 。 また、ユーザ・セッション制御とサービス分離は、選択されたエージェントにお いて明示される。リソース・エージェントの識別は、サービスとセッション制御 からリソース管理を分離させる。種々のエージェントを接続する接着剤は、処理 モデルによって供給される。このモデルは、エージェント間でメッセージがどの ように通過するかを制御する。これには、エージェントを、所定のシーケンスで 、また、サービスの意図と加入者の欲求に一致する方法で、メッセージ上で確実 に動作させるメカニズムが含まれる。 ユーザ・エージェントの主要な責任の１つに、ユーザが含まれる任意の呼を管 理する、すなわち、ユーザの通信セッションを管理するということがある。ユー ザ間の通信がまず確立され、含まれるパーティのユーザ・エージェントによって 調整される。出力呼を確立するために、ユーザ・エージェントはまず、他のユー ザ・エージェントに、呼のような要求を伝達する。一度、ユーザ・エージェント が、呼が実行可能であるかどうかに同意し、呼完了のための宛先情報に同意すれ ば、発呼側のユーザ・エージェントは、接続リソース・エージェントに必要なベ アラ能力を調整するように要求する。このアプローチの結果、呼／接続分離と交 渉接続設定に到達する。接続設定から交渉位相を独立することによって、限定（ 例えば、スクリーニング）機能から発生しうる相互動作の決定を簡単にする。エ ージェント・アーキテクチャにおいては、ユーザ・エージェントは、知的でない メッセージ・センタであり、他のユーザ・エージェントおよびリソース・エージ ェントからメッセージを受け取り、それらのエージェントに送出する。このよう なメッセージに直接応答することはない。ユーザ・エージェントは処理モデルを 実行し、いつ種々のサービス・エージェントがメッセージを受け取るか、いつ応 答が他のエージェントに送られる用意ができるかを決定する。出力呼を確立する プロセスをさらに詳細に説明すると、ユーザ・エージェントは種々のイベントを 決定し、質問はサービス・エージェント（おそらく、ＰＯＴＳサービス・エージ ェント）に送られる。サービス・エージェントは、ユーザ・エージェントが他の ユーザ・エージェント、またはリソース・エージェント上に送るメッセージを作 る。 ユーザの好みやプロファイルは、申し込んだサービス、これらのサービスによ ってアクセスされた加入者依存データ、サービス・エージェントへのメッセージ およびイベントの発送に関するユーザ・エージェント・ルールの選択という形で 表される。ユーザ・エージェントは、これらの役割に関するイベントに応じるよ うに設計されているサービス・エージェントを用いて、請求側、被呼側、端末所 有者などの役割を果たす。ユーザ・エージェントは、他のユーザ・エージェント にとっては、クライアントでもあるしサーバでもあるため、他のユーザ・エージ ェントに要求を送り、また、他のユーザ・エージェントからの要求や通知に応答 する。ユーザ・エージェントは、サービス・エージェントに対しては、純粋にク ライアントである。一般的に、ユーザ・エージェントは、リソース・エージェン トにとってもクライアントであるが、リソース・エージェントは、ユーザ・エー ジェントによって要求されれば、ユーザ・エージェントにイベントの通知を非同 期で送る。 サービス・エージェントは、サービスの意図を実行するために必要な処埋を表 す。モデルの処理に関して、申し込まれた各サービス・エージェントは、いつサ ービス・エージェントがイベントに応答するかを示すユーザ・エージェントにル ールを供給する。サービス・エージェントは、ユーザ・エージェントから、他の ユーザ・エージェントに、または、リソース・エージェントに送られるべきメッ セージを作成するか、または修正することによってイベントに応答する。イベン トへの応答の一部として、サービス・エージェントは、新しい発送ルールをユー ザ・エージェントに与えてもよい。一般的に、サービス・エージェントは、関連 付けられた１組の機能の処理を具体化する。実際に機能をサービスにグループ化 すると、関連データがどのようにグループ化され、アクセスされるのか、すなわ ち、性能に影響を与えるが、エージェント・アーキテクチャの論理的な動作には 影響しない。サービス・エージェントが、ユーザ・エージェントからの１つの要 求に「あまり」応答しすぎないことが重要である。応答しすぎるということは、 他のサービス・エージェントを決定に参加させないで、スクリーニング、ブロッ キング、再送などの多くの役割をすぐに行うことに近い。性能と機能間の共同相 互動作はトレードオフの関係にある。 サービス・エージェントは、他のサービス・エージェントと直接に通信するこ とはない。一般的には、サービス・エージェントは、他のサービス・エージェン トの存在にさえ気づいていない。しかしながら、サービス・エージェントは、ユ ーザ・エージェントによって検出されるイベントを「作り」、その後、これらの イベントに興味を表示している他のサービス・エージェントに送られる。このよ うに、サービス・エージェント間では間接的な通信が行われる。 サービス・エージェントは、実行者が役割へハード・コーディングされる割り 当てを回避する必要がある。特に、特定の信号のハード・コーディングは避けな ければならない。信号は論理的名称（例えば、「１０代の発呼者への警告」、「 顕著なリンギング・パターン２」等ではない）で表されるべきである。サービス ・エージェントは、サービスの活性化、または新しい端末割り当てを含むイベン トに応答するように設計されなければならない。これらのイベントに応答して、 サービス・エージェントは、適切な信号について端末リソース・エージェントに 問い合わせるように、ユーザ・エージェントに依頼しなければならない。サービ ス・エージェントは、十分でない独自の信号が利用できるイベントを用意する必 要がある。また、サービス・エージェントは、人間のユーザに、どの信号が用い られるかを知らせるためのメカニズムを供給しなければならない。 ある特定のサービス・エージェントは、ユーザに登録された端末で、発呼また は終端する基本呼を管理するように設計されてるＰＯＴＳエージェントである。 ＰＯＴＳエージェントサービスについては後述する。ＰＯＴＳサービス・エージ ェントの発送ルールは、他のサービス・エージェントがＰＯＴＳエージェントの 代わりをするようにさせる。他のサービスとして表わされるＰＯＴＳを有するこ とによって、「特別なサービス」とＰＯＴＳを違うものとして扱う必要が出てく るというアーキテクチャ上の不利益を避ける。 リソース・エージェントは、リソースに含まれる機能を管理する役割を持つ。 リソース・エージェントは、いくつかの特定な機能がアクセスされるときに、利 用可能な機能、使用中の機能、特定のユーザまたは他のエージェントに予約され た機能、およびユーザ・エージェントは通知が必要かどうかを把握する。データ はリソースであり、一方、データ・ベース・リソース・エージェントは、他のエ ージェントまたはリソースの場所を位置決めするデータ、またはどのプロトコル がエージェントを利用するかについての情報を与えるデータを発見し管理する。 リソース・エージェントの２つの特別なケースは、終端端末を表わす端末リソー ス・エージェントと、接続を操作するネットワーク・リソースを表わす接続リソ ースとである。 端末リソース・エージェントは、端末（例えば、フォント、ＭＰＥＧデコーデ ィング、警告方法）とそれを使用する信号の性能を理解し、ネットワークやユー ザと通信する。端末リソース・エージェントは、例えば、共有の問題を解決する ために、あるイベントがいつ起こるのかが通知される特定のユーザ・エージェン トの名称またはアドレスを記憶してもよい。 接続リソース・エージェントは、ベアラ・チャネルの確立において、ネットワ ーク・プロバイダを表わす。複数のネットワーク・プロバイダにアクセスするユ ーザは、複数の接続リソース・エージェントと、直接通信してもよい）。このエ ージェントは、物理的に異なる位置の間に接続を確立するアルゴリズムを有して いる。この位置は、ユーザ・エージェントからの要求によってエージェントに識 別される。この要求は、ベアラ・チャネルが確立されるべき位置と会議ブリッジ のような要求された他の機能位置間の２つの物理的な位置の他に、許容できるコ スト、最小限のビット・レート、最適化ビット・レート、最大限の遅延などのよ うな所望の制約を含む。接続リソース・エージェントは、低レベル（エージェン ト・アーキテクチャの外側）プロトコルによって分散されたリソースの大きな組 を制御してもよい。エージェント・アーキテクチャがこのようなシグナリングに 対して自明であることは必須である一方、例えば、端末のネットワーク・ポート に対するメッセージは、エージェント間で他の動作を引き起こし、その端末のリ ソース・エージェントにまで報告されてもよい。 リソース・エージェントの重要な機能は、信号の不明瞭性を減少させることで ある。申込時間、またはサービスの設定時間において、サービス・エージェント は、特定の特性を満足させる信号を要求するリソース・エージェントにメッセー ジを送るようにユーザ・エージェントに依頼する。例えば、呼待機サービス・エ ージェントは、呼の進行中に適用可能な警告パターンを端末リソース・エージェ ントに依頼してもよい。端末リソース・エージェントは、独自の信号に応答して もよいし、または、利用可能な独自の信号はないことを指示してもよい。後者の 場合、適切な信号が、現在、どのように割り当てられているかについての照会に 応じるように準備される。サービス・エージェントは、もし信号が共有されてい るとしたら、どのようにされているか、またユーザにどのように通知されるかに ついて扱うことができる。 また、リソース・エージェントは、どのユーザ・エージェントがビジー・リソ ースを用いているのかを把握し、異なるユーザ・エージェントがビジーまたは予 約されたリソースを制御しようと試みる場合には、どのように応答するのか、ま たは、どのユーザ・エージェントに相談するのかについてルールを持っていても よい。 リソース・エージェントは、それらのリソースを用いるために、請求の認可を 求めてもよい。これらのリソースを使用するように要求するサービス・エージェ ントは、もし、請求額が発送ユーザ・エージェントによって支払わなければ、他 のパーティ（ユーザ・エージェントによって示される）から認可を得る必要があ ることもある。 図２，４，５，６は、互換性システムの処理の流れを示している。 特に図２に関し、発呼されたイベントに応じてＣＣモジュール１２Ａ（または １２Ｃ）中の「コントローラ」を構成するプロセスは下記のようである。 （１） エージェント／プロキシ（Ａ／Ｐ）１はイベントを呼び出す。これは 、互換性システムを介して、コントローラ・マネジャに送られる。このイベント に関するコントローラはないので、これはコントローラ・マネジャに送られる。 このイベントは、イベントを生成するために何が起こったかを説明するイベント ・データを含む。 （２） コントローラ・マネジャは、イベント・データを利用可能なコントロ ーラに供給する（これは、待機中のコントローラであってもよいし、またコント ローラを生成することもできる）。これは、コントローラに、初期化を開始させ る。 （３） コントローラはプロファイル・マネジャからプロファイルを要求する 。この要求は、プロファイル・マネジャが、適切なプロファイルを識別するため のイベント・データを含む。 （４） プロファイルはコントローラに返送される。このプロファイルは、Ｅ ＨおよびＲＨを構成する情報を含む。このプロファイルは、また、イベント取り 扱い論理を含む（これは、ＥＨがどのようにイベントを取り扱うにかについての ものである）。この論理は、いくつかの手段によって供給される。 （ａ） すべての論理は、プロファイルに含まれ、いつサービスが（エージ ェントを介して）活性化されるかに関する論理がプロファイルに供給されること を要求する。 （ｂ） 相互サービス論理だけは、プロファイル内で供給される。しかしな がら、この場合、プロファイルはサービスのリストを含む。コントローラは、そ のとき、サービスを表すエージェントから、（サービスに特定の）残りの論理を 検索する。 （５） コントローラ・マネジャは、イベントをコントローラのＥＨに送る（あ る意味で、コントローラ・マネジャは、適切なコントローラを初期化し、このコ ントローラが扱う必要のある第１のイベントに送る）。ＥＨは、イベント取り扱 い論理を用いて、このイベントに何が起こるかを決定する（このプロセスは、プ ロセスを取り扱う標準のイベントのステップ１から成る）。要求 要求Ｒ１は、エージェントを介するＲＤ１またはＣバス１１を介してＣＣ１２ Ａに中継されるプロキシＡ／Ｐ１のような装置によって開始されてもよい。ＣＣ １２Ａ内で、ＲＨ２０は、これが発呼エージェント／プロキシに依存する合法的 な要求であるかどうか、また、ユーザはこのＣＣを表すかどうかを決定する。Ｒ Ｈ２０は、適切なエージェントまたはプロキシを発見し、要求される初期情報を 提供する。ＲＨは、ある環境内でサポート機能を用いてもよい。この環境では、 ＲＨは、要求者の代わりに要求を実行できる適切なエージェントまたはプロキシ （例えば、Ａ／Ｐ２）を見つけるために存在する。ＲＨ２０は、ＥＨ２１に送ら れるイベントを生成し、Ａ／Ｐ２を呼び出す。これによって、もし必要であれば 、ＣＣの装置を相互動作させる機能が完全に呼び出されるようになる。この活性 化イベントは、Ａ／Ｐ２に送られ、初めに要求された特定の機能を活性化させる 。ルール ルールは、基本的に、論理の結果に依存する動作の前に評価される必要がある 論理のモジュールである。ルールは２つのソースに対するコントローラに供給さ れる。第１のソースは、関連のイベントを得るためのルールを、イベントが表す サービスまたは機能に供給するエージェント／プロキシである。第２のソースは 、エージェント／プロキシによって供給されるルール間を仲裁する付加のルール を供給する「サービス統合器」である。例えば、（サービスにアクセスするため に、特定の番号をダイヤルする）「個人アシスタント」のようなダイヤルアップ ・サービスは、任意の呼着信イベントに関心がある。この場合、個人アシスタン ト・サービスを表すエージェントまたはプロキシは、下記のようなルールを提供 する。 イベント： 呼着信 論理： 真の（「どれか」を意味する） 動作： イベントをエージェント／プロキシに送るイベント （ａ） Ａ／Ｐ１は、ＣＣに送られるイベントを生成する。ＣＣにおいて、Ｅ Ｈ２１はイベントを扱う。 （ｂ） ＥＨ２１はルールを用いる。このルールは、どのエージェントまたは プロキシが、イベントを受信するかを決定するためのサービスとサービス・ブロ ーカによって供給される（これを無効にする他のルールがなければ、最新の活性 化サービスのデフォルト・ルールが用いられる）。 （ｃ） イベントに送られるエージェントが、イベントを「消費」すれば、こ の時点で、プロセスは終わる。しかしながら、エージェントまたはプロキシは、 イベントを修正してもよいし、イベントを変更しなくてもよい。イベントが変更 されない場合には、イベントはＣＣに返送される。 （ｄ） このプロセスは（ａ）から成続き、ＣＣ内のルールは、どのエージェ ントまたはプロキシが、次のイベントを提供されるか決定する。 （ｅ） エージェントまたはプロキシは、再度、同じイベントを修正するか、 または再主張し、このプロセスは継続する。 特に図６は、個人的なエージェント、メタ・サービス・アプリケーション中で 、２つのサービス、音声メールとこれに続く更新を用いて、互換性のあるシステ ムを実行する例を示している、。 （１） 呼が呼制御機能に到着するとき、呼制御プロキシは（互換性システム 内で呼制御機能を表す）、イベントを生成し、呼の到着を示す。 （２） コントローラ・ルールは、呼の到着は個人的なエージェント上を通過 すべきであることを示す。 （３） その機能を実行するために、個人的なエージェントは、ユーザからＰ ＩＮを集めるように要求される。これによって、個人的なエージェントは、指示 要求を送り、ＰＩＮをユーザから集める。 （４） コントローラは、個人的ユーザからの要求を実行できる「指示および 収集プロキシ」を発見することができる。 （５） 指示および収集プロキシは、指示および集合プロキシ機能を呼び出し （プロキシは、機能を供給するために用いられる実際のプロトコルの詳細を隠す ので、これは、インタフェースを介して行われる）、その結果をコントローラに 戻す。 （６） コントローラは、その結果を、個人的なエージェント中の最初の要求 者に戻す。 （７） サービスを続けるために、個人的なエージェントは、ユーザに対して 示されるべきメニューに、どのサービスが活性化されるべきか（音声メール、ま たは、ＦＭＵのどちらか）を決定するように要求する。個人的なエージェントは 、再度、コントローラに、指示および収集機能を捜すように要求する。 （８） コントローラは、再度、要求に答えられる指示および収集プロキシを 捜す。 （９） 指示および収集プロキシは、リソースと相互動作する。このリソース は、指示および収集の能力を提供し、その結果をコントローラに返送する。 （１０） コントローラは、再度、その結果を、個人的エージェントに返送す る。 （１１） もしユーザが音声メールを要求したら、個人的エージェントはサー ビスの活性化を（サービスの名前で）要求する。 （１２） コントローラは、（音声メール・プロキシ中で）要求されたサービ スを捜し、プロキシを呼び出す。 （１３） サービスが完了すると、コントローラは、サービスが音声メール・ プロキシから開放された旨の通知を受ける。 （１４） サービス開放イベントは、コントローラがこのデフォルト行為を無 効にするルールを有しないので、最後に活性化されたサービス（この場合は、個 人的エージェント）に送られる。 （１５） サービスを続けるために、個人的なエージェントは、ユーザに対し て示されるべきメニューに、どのサービスが活性化されるべきか（音声メール、 または、ＦＭＵのどちらか）を決定するように要求する。個人的なエージェント は、再度、コントローラに、指示および収集機能を捜すように要求する。 （１６） コントローラは、再度、要求に答えられる指示および収集プロキシ を捜す。 （１７） 指示および収集プロキシは、リソースと相互動作する。このリソー スは、指示および収集の能力を提供し、その結果をコントローラに返送する。 （１８） コントローラは、再度、その結果を個人的エージェントに返送し、 ユーザの応答に依存して、個人的エージェントは、コントローラにサービス（以 前のような音声メール、または、フォローミー更新サービスのような他のサービ ス）を活性化するように要求できる。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，Ｌ Ｕ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＣＡ，ＪＰ (72)発明者 ディーンズ・ゴードン・マシュー カナダ国，ケイ２ビー ８エイ６，オンタ リオ，オタワ，リンカーン ハイツ ロー ド 150

Claims (1)

1. 【特許請求の範囲】 １． 通信、情報処理および同様のネットワーク中の異なるサービス間に互換性 を供給する方法において： （ａ） ソフトウェア・エージェント・モジュール（ＳＡＭ）を各サービス・リ ソース装置（ＳＲＤ）に割り当てて、上記のＳＲＤをソフトウェア・メッセージ ・バス（ＳＭＢ）にインタフェースさせ； （ｂ） ネットワーク参加者によって初期化された各サービス・セッションのた めに、一時的なソフトウェア互換性制御（ＣＣ）を生成し； （ｃ） 上記のＣＣモジュールを少なくとも２つのサブモジュールに区分し、そ の１つは、ネットワーク参加者からの要求を送信するためのＲＨであり、他の１ つは、ＳＡＭを介して、選択されたＳＲＤをアクセスするためのイベントを発生 させ、上記のＲＨによって生成されたイベントを取り扱うためのＥＨであること を特徴とする互換性供給方法。 ２． 請求項１記載の互換性供給方法において： 一時的なソフトウェア互換性制御モジュールを生成するステップは、所定の処 理ルールに従って、前記の要求とイベントを処理することによって、前記のＣＣ モジュールが、前記の少なくとも２つのサブモジュール中で、要求とイベントを 取り扱うステップを含むことを特徴とする互換性供給方法。 ３． 請求項２記載の互換性供給方法において： 互換性データベース（ＣＤＢ）中に、前記の所定の処理ルールを記億するステ ップをさらに含むことを特徴とする互換性供給方法。 ４． 請求項３記載の互換性供給方法において： ステップ（ｂ）でＣＣモジュールが生成されるたびに、前記のＣＤＢから、前 記の所定の処理ルールのサブセットを検索するステップをさらに含むことを特徴 とする互換性供給方法。 ５． 請求項１記載の互換性供給方法において： 関連するＳＡＭを介して、ＳＲＤが前記のＳＭＢ上で初期のイベント・メッセ ージを発生するたびに、前記のステップ（ｂ）は処理されることを特徴とする互 換性供給方法。 ６． 請求項４記載の互換性供給方法において： 関連するＳＡＭを介して、ＳＲＤが前記のＳＭＢ上で初期のイベント・メッセ ージを発生するたびに、前記のステップ（ｂ）は処理されることを特徴とする互 換性供給方法。 ７． 請求項６記載の互換性供給方法において： 前記のステップ（ａ）は、ＳＡＭを、前記の通信ネットワークの各ユーザに割 り当てるステップをさらに含むことを特徴とする互換性供給方法。 ８． 請求項６記載の互換性供給方法において： 前記のステップ（ａ）は、ＳＡＭを、前記の通信ネットワークの各端末に割り 当てるステップをさらに含むことを特徴とする互換性供給方法。