JPH09510851A - パーソナル通信サービス用の分散サービス管理システムおよび方法 - Google Patents

Abstract

(57)【要約】 通信・サービスを提供する分散サービス管理システムは、複数の異なるサービス・プロバイダによって運用されている複数の個別サービス管理システム（２１０，３１０，４１０，５１０）を備えている。各サービス管理システムは自分のローカル・データベース（２１４，３１４，４１４，５１４）と、ローカルに実行されているアプリケーションがローカル・データベースと、遠隔地に置かれたサービス管理システムに所属するリモート・データベースとにアクセスすることを可能にするコンピュータ（２１２，３１２，４１２，５１２）内のインタフェース（ＩＤＴＭ）を備えている。インタフェースは複数の個別サービス管理システムを単一のマルチデータベース・トランザクション管理システムに統合化する働きをする。分散サービス管理システムは、一時的レンタル移動電話への呼転送といったように、複数のサービス・プロバイダが関係する特殊なパーソナル通信サービスを提供するために使用することができる。

Description

【発明の詳細な説明】 パーソナル通信サービス用の分散サービス管理システムおよび方法発明の分野 本発明はパーソナル通信サービス(personal communication services)の高速 配置(fast deployment)をサポートする分散サービス管理システム(distributed service management system)および方法に関する。特に、本発明は、各地を移動 するユーザ(nomadic user)が異なるパーソナル通信サービス・プロバイダ(provi ders)および電話会社間の相互運用性(interoperability)の問題なしにどこにい ても、いつでもパーソナル通信サービスに加入し、アクチベートし、使用するこ とを可能にしている。発明の背景 パーソナル通信サービスの重要な目標の１つは、ユーザがどこからどこにでも 、いつでも通信できるようにすることである。このようなパーソナル通信サービ スは、ローカルおよび長距離電話会社やセルラ(cellular)電話会社などを含む、 複数のサービス・プロバイダが関係するのが一般である。以下は、パーソナル通 信サービスの一例を示したものである。 あるパーソナル通信サービス・プロバイダ（例えば、セルラ電話会社）は、旅 行するユーザが無線携帯電話(wireless portable phone)をレンタル電話会社か ら（例えば、航空会社やカー・レンタル会社から）賃借することを可能にしてい る。セールス販売員(sales representative)はホーム・ロケーション（例えば、 ニュージャージー）から訪問先ロケーション（例えば、カリフォルニア）へ旅行 する。彼／彼女の上司および彼／彼女の自宅に連絡するためには、ユーザはカリ フォルニアに到着と同時に無線携帯電話を賃借する。このレンタル電話を使用し て、ユーザはそのパーソナル通信サービス・プロバイダから基本的な移動電話 (mobile phone)サービスの提供を受ける。以上のほかに、ユーザが望んでいる機 能として、次のものがある。 1) ユーザは彼／彼女の事務所または自宅宛の呼(call)が、彼／彼女が旅行中 であることをだれにも知られずにレンタル携帯電話へ自動的に転送されることを 望んでいる。 2) 重要でない着信呼(incoming call)(従って、それに伴う着信呼の料金負担 )を避けるために、ユーザはレンタル携帯電話に呼できる人の数を制限すること を望んでいる。 3) ユーザにとって重要なことは、レンタル電話の機能が瞬時にアクチベート されて、ユーザの訪問先ロケーションへの到着と同時に呼が即時に行なわれるよ うにすることである。 この種のパーソナル通信サービスは、複数のサービス・プロバイダが関係して いる。それは、(a)ホーム・ロケーションのローカル電話会社、(b)長距離電話会 社、(c)訪問先ロケーションにあるローカル電話会社、および(d)パーソナル通信 サービス・プロバイダ（例えば、セルラ電話会社）である。以下、これらを「サ ービス・プロバイダ(service provider)」と総称することにする。 複数のサービス・プロバイダが関係する、この種のパーソナル通信サービスを 可能にするためには、異なるサービス・プロバイダ間の相互運用性という問題を 解決しなければならない。この相互運用性の問題は２つのカテゴリに分類するこ とができる。(a)ロケーション・トラッキング(location tracking)とサービス管 理(service management)である。 ロケーション・トラッキングに関する相互運用性の問題は、移動電話産業で使 用しているシグナリング・プロトコル(signaling protocol)を採用することによ り取り組まれている。ロケーション・トラッキング機能は２つのロケーション・ レジスタ(location register)を使用して実現されている。これらのレジスタの 一方はユーザのホーム・ロケーションのローカル電話会社が保守しており、ホー ム・ロケーション・レジスタ(Home Location Register - ＨＬＲ)と呼ばれてい る。他方のレジスタは訪問先ロケーションのローカル電話会社が保守しており、 ビジティング・ロケーション・レジスタ(visiting location register - ＶＬＲ）と呼ばれている。ＨＬＲは、カストマ・プロフィール・データ(custome r profile data)とユーザのＶＬＲのロケーションをストアしている。カストマ ・プロフィール・データは、重要な情報、例えばユーザの名前／アドレス、優先 長距離キャリヤ(preferred long distance carrier)、サービス機能（例えば、 呼転送(call forwarding)と呼制限(call restriction)）、課金(billing)その他 管理目的の関連情報を含んでいる。ユーザが新しい訪問先ロケーションへ旅行す ると（例えば、ニュージャージーからカリフォルニアへ）、新しいＶＬＲがその 新しいロケーションで作成される。プロフィール・データの一部はＶＬＲにロー ドされ、訪問先ロケーションのサービス・プロバイダがその訪問ユーザのために サービス機能（例えば、呼制限）を実現できるようしている。ＨＬＲ内のＶＬＲ のロケーションは新しいＶＬＲロケーションに変更され、以前に訪問したロケー ションにおけるＶＬＲは削除される。新しいＶＬＲを作成し、プロフィール・デ ータをＶＬＲにロードし、ＨＬＲ内のユーザの訪問先ロケーションを更新するプ ロセスは、「自動ローマ登録(automatic roamerregistration)」と呼ばれている 。 サービス管理に関する相互運用性の問題は、ロケーション・トラッキングのそ れよりもはるかに複雑である。サービス管理(service management)とは、パーソ ナル通信サービスのユーザがどこにいても、いつでもサービス機能に加入し、変 更し、アクチベート(activate)することを可能にするために必要な機能が集まっ たものをいう。サービス管理機能の例としては、電話番号の管理、カストマ・プ ロフィール・データの管理、サービス・アクチベーション(activation)、セキュ リティ管理などがある。電話番号管理機能は、電話番号のユニーク性(uniquenes s)を保つ上で重要である。カストマ・プロフィール・データ管理機能は、カスト マ・プロフィール・データベースおよびそのデータベースを作成し、変更し、ま たは転送するためのユーザ・インタフェースを提供する。サービス・アクチベー ション機能はサービス機能を指定しているデータの一部をプロフィール・データ から抜き出し、そのデータを呼を処理する物理通信システムにロードする。また 、サービス・アクチベーション機能はサービス機能のアクチベーションとデアク チベーション(deactivation)の制御も行う。セキュリティ管理機能は サービスおよびサービス管理機能の不正な(unauthorized)使用を防止し、あるい はそれを検出する。 このタイプのサービス管理機能は、複数のサービス・プロバイダが関係するパ ーソナル通信サービスを提供するように実現されている必要がある。サービス管 理機能のこのような実現は、アプリケーション・ソフトウェアと、異なるサービ ス・プロバイダが所有し、運用している種々のデータベースとの間の相互作用が 必要であるのが一般的である。各地を移動するユーザがどのロケーションにいて も、どのサービス・プロバイダからのパーソナル通信サービスにも加入できるよ うにするアプリケーションについて考えてみる。このようなサービスの例として は、一時的に貸借した携帯電話への呼転送(call forwarding)がある。このアプ リケーションは、例えば、種々の異なるサービス・プロバイダが管理しているデ ータベースで以下に示すようなデータベース・アクセス・オペレーションを実行 する必要が起こる場合がある。 ・ クレジット・カード会社または電話会社が所有するクレジット・データベ ースをチェックして、ユーザがサービスに対する支払能力を有するかどうかを決 定する。 ・ ユーザのＨＬＲに入っているカストマ・プロフィール・データベースをチ ェックして、ユーザがＨＬＲに現在ストアされている訪問先ロケーションとは別 の場所に現在いるかどうかを決定する。 ・ ユーザによって指定された長距離電話会社のクレジットおよびネットワー ク・データベースをチェックして、ユーザが訪問先ロケーションで特定の長距離 キャリヤを利用できるかどうかを決定する。 ・ プロフィール・データを訪問先ロケーションのＶＬＲにロードし、必要な らばＨＬＲをＶＬＲのロケーションで更新する。 ・ プロフィール・データを呼処理システムにロードし、サービスをアクチベ ートする。 以上に鑑みて、本発明の目的は、複数のサービス・プロバイダのデータベース をアクセスすることによって上述したサービス管理機能を実現し、複数のサービ ス・プロバイダが関与するパーソナル通信サービスが迅速かつ高信頼にユーザに 利用できるようにする、サービス管理システムおよび方法を提供することである 。 本発明の別の目的は、上で明らかにされたサービス管理機能を実現するために 複数の個別サービス・プロバイダによって運用される複数の個別サービス管理シ ステムを備えている分散サービス管理システムを提供することである。 本発明の別の目的は、個別サービス管理システムを大幅に変更することなく、 個別サービス・プロバイダによって運用される複数の個別サービス管理システム から構築されている分散サービス管理システムを提供することである。 さらに、本発明の目的は、従来利用できなかった、新規のパーソナル通信サー ビスを提供するために使用できるサービス管理システムを提供することである。 詳しくは、本発明の目的は、機能強化されたパーソナル通信サービスを各地を 移動するユーザに一時ベース(temporary basis)で提供することであり、そのよ うなサービスの例としては、(a)ユーザのベース電話(base telephone)から移動 電話(mobile telephone)への呼転送および(b)移動電話への着信呼を制限するこ とがある。発明の概要 本発明は、異なるサービス・プロバイダによって運用される複数の個別サービ ス管理システムを備えている分散サービス管理システムに向けられている。サー ビス・プロバイダは、例えば、ローカル電話会社、長距離電話会社、およびセル ラ電話会社を含む。個別サービス管理システムはテレ通信・ネットワーク(telec ommunication network)によって相互に接続されている。ローカル・データベー スは各個別サービス管理システムに置かれている。このローカル・データベース は、例えば、カストマ・プロフィール・レコード（customer profile record-Ｃ ＰＲ）とクレジット・レコードを含んでいる。各個別サービス管理システムはロ ーカル・データベースを管理するデータベース管理システムを含んでいる。 各個別サービス管理システムは対話型分散トランザクション・モニタ（Intera ctive Distributed Transaction Monitor - ＩＤＴＭ）を有している。このＩＤ ＴＭは対話型の、メッセージ・ベースのインタフェースを提供し、このインタフ ェースは、アプリケーションが異なる個別サービス管理システムのローカル・デ ータベースにストアされたデータをアクセスすることを可能にしている。例示の アプリケーションは、ユーザが呼を一時的に貸借した携帯電話へ転送するサービ スに加入することを可能にしている。ＩＤＴＭはエージェント(agent)と呼ばれ る複数のプロセスを備えている。各ＩＤＴＭのエージェントは、ローカル・デー タベースをアクセスする必要のあるすべてのアプリケーション（発生源はローカ ルであるか、またはリモートである）の仲介者(intermediary)の役割を果たすこ とによってローカル・データベースをカプセル化(encapsulate)している。各個 別サービス管理システムに置かれたＩＤＴＭは、トランザクション・マネージャ (transaction manager)と通信・マネージャ(communication manager)も含んでい る。 ローカル・アプリケーションは、まず、ローカル・サービス管理システムに置 かれたトランザクション・マネージャに登録することによりローカルおよびリモ ート・データベースに接続される。あるトランザクションが登録要求を受信する と、そのトランザクションはエージェントを割り当てて、そのエージェントをア プリケーションに接続する。割り当てられたエージェントはコーディネータ(coo rdinator)と呼ばれる。コーディネータ・エージェントはアプリケーションのた めにローカル・データベースへのアクセスを実行する。アプリケーションは、リ モート・サービス管理システムに置かれたリモート・データベースへのアクセス を要求する場合がある。そのような場合には、コーディネータは、ローカル・ト ランザクション・マネージャがリモート・サービス管理システム側のトランザク ション・マネージャと通信するように要求し、リモート・エージェントをアプリ ケーションに割り当てて、アプリケーションがリモート・データベースをアクセ スできるようにする。 各ＩＤＴＭエージェントは次のような機能を実行する、いくつかのモジュール を備えている。すなわち、データベース・アクセス、持続的ストレージ (persistent storage)、並行処理制御(concurrenty control)、コミット・プロ トコル(commit control)、およびイベント検出(event detection)である。アプ リケーションは、読取り、書込み、コミットなどの、標準データベース・オペレ ーション(standard database operation)が発行される。これらのオペレーショ ンはＩＤＴＭ内のエージェントによって実行される。 ＩＤＴＭの使用は大きな利点がある。分散サービス管理システムに組み入れる ために各個別サービス管理システムにＩＤＴＭをインストールすることは、個別 サービス管理システムを大幅に変更しない。従って、分散サービス管理システム は既存の個別サービス管理システムから容易に構築することが可能である。ＩＤ ＴＭはアプリケーションとデータベースとの間の仲介役であるので、各個別サー ビス管理システムで使用されている特定のデータベース管理システムを変更しな くても、分散サービス管理システムを構築することが可能になっている。 本発明の分散サービス管理システムは複数のサービス・プロバイダのサービス 管理システムでデータベース・オペレーションを実行できるので、機能が強化さ れたパーソナル通信サービスをユーザに提供することができる。 訪問先ロケーションで携帯電話を貸借するユーザ（例えば、空港で携帯電話を 貸借するユーザの場合）に呼転送サービスを提供する場合を例にして説明する。 分散サービス管理システムは、複数のデータベース・アクセスを伴う次のような 機能を実行して、ユーザがこのサービスに加入できるようにする。 1) このサービスに関係するすべてのサービス・プロバイダのサービス管理シ ステムでクレジット・レコードをチェックし、ユーザがサービスに対して支払能 力があるかどうかを確かめる。 2) ユーザのホーム・ロケーション・レジスタ内のカストマ・プロフィールを チェックし、そこにストアされた訪問先ロケーションがユーザが実際に訪問して いる現ロケーションと異なっているかどうかを判断する。 3) ユーザが指定した長距離キャリヤのクレジットおよびネットワーク・デー タベースをチェックし、ユーザが訪問先ロケーションから特定の長距離キャリヤ を実際に利用できるかどうかを確かめる。 4) プロフィール・データを訪問先ロケーション側のビジティング・ロケー ション・レジスタにロードし、必要ならば、ホーム・ロケーション・レジスタを ビジティング・ロケーション・レジスタのロケーションで更新する。 5) プロフィール・データを特定の呼処理システム（例えば、サービス・コン トロール・ポイント(service control point)、セントラル・オフィス(central office)、またはスイッチ）にロードし、サービスをアクチベートする。例えば 、１つ以上のセントラル・オフィス・スイッチで行われる交換(switching)は、 ユーザのベース電話番号が発呼されたとき、その呼が別のロケーションにスイッ チされて、呼転送を実現するように変更するも可能である。 また、注意するべきであるのは、サービス管理機能は、ＩＤＴＭにより送信さ れたメッセージで通信する個別サービス管理システムで構成された分散サービス 管理システムを用いて実行されるということである。図面の簡単な説明 図１は、本発明の例示的実施の形態による複数の個別サービス管理システムを 備えた分散サービス管理システムを示す概略図である。 図２は、図１の分散サービス管理システムの個別サービス管理システムのうち の１つを実現するために使用されるハードウェアを示す概略図である。 図３は、図１の分散サービス管理システム内の各個別サービス管理システムで 使用されるＩＤＴＭを示す概略図である。 図４は、複数のサービス・プロバイダのネットワークを含み、本発明による分 散サービス管理システムを含んでいるシステムを示す図である。発明の詳細な説明 理解を容易にするために、本発明の詳細な説明は２つの部分に分かれている。 パートＡは、本発明による分散サービス管理システムのアーキテクチャを説明 し、そこで利用されているＩＤＴＭを詳しく説明している。パートＢは、プロト タイプ・サービス（つまり、一時的な携帯電話ユーザのためのパーソナル・サー ビス）が本発明の分散サービス管理システムを使用すると、どのように実現でき るかを説明している。 Ａ．分散サービス管理システムのプロセス 本発明の分散サービス管理システムのアーキテクチャ全体は図１に示されてい る。図１の分散サービス管理システム１０は異なるサービス・プロバイダによっ て運用されている複数の個別サービス管理システム１２−Ａ、１２−Ｂ、１２− Ｃ、１２−Ｄ、１２−Ｅ、１２−Ｆを備えている。例えば、サービス管理システ ム１２−Ａは第１ローカル電話会社によって運用され、サービス管理システム１ ２−Ｂは第２ローカル電話会社によって運用され、サービス管理システム１２− Ｃは長距離電話会社によって運用され、サービス管理システム１２−Ｄはセルラ 電話会社などの、パーソナル通信サービス・プロバイダによって運用されている 。他の２つの個別サービス管理システム１２−Ｅと１２−Ｆはサービス・コント ロール・ポイントに置かれている。サービス・コントロール・ポイント（servic e control point - ＳＣＰ）は、セントラル・オフィス・スイッチ群用の呼処理 機能を備えた物理通信システムである。 これらのサービス管理システムはトランスポート・ネットワーク１４によって 相互に接続されている。トランスポート・ネットワーク１４はデータおよびＳＱ Ｌ（標準問合せ言語(Standard Query Language)）メッセージ・トランスポート ・サービスを提供する。ネットワーク１４は有線ベースの電話や無線電話および その他の通信ネットワークにより提供される機能を利用する。 各個別サービス管理システム１２はローカル・データベース（図１には示され れていないが、図２を参照）をもち、そこには、例えば、カストマ・プロフィー ル・レコードとクレジット・レコードがストアされている。また、各個別サービ ス管理システムはそのデータベースを管理するデータベース管理システムももっ ている。 各個別サービス管理システム１２は対話型分散トランザクション・モニタ（In teractive Distributed Transaction Monitor - ＩＤＴＭ）１６をもっている(M ．Cochinwala、K.C．LeeおよびW．Mansfield，Jr.共著「分散トランザクション ・モニタ(A Distributed Transaction Monitor)」Third International Worksho p on Research Issues on Data Engineering:INTEROPERABILITY IN MULTIDATABA SE SYSTEMS，Vienna，Austria，April 18-20,1993を参照)。ＩＤＴＭ16は対話型 メッセージをベースとするインタフェースであり、このインタフェースを通して アプリケーションは複数の個別サービス管理システム１２に置かれているデータ ベースをアクセスすることができる。図示の例では、ＩＤＴＭ１６はＳＱＬを使 用するトランポート・ネットワーク１４を利用して通信している。 以下では、サービス管理システム１２の構造についてより詳しく説明する。図 ２は公衆交換電話ネットワーク(public switched telephone network)のうちロ ーカル電話ネットワークに所属する部分２０を示している。このネットワーク部 分２０は図１のトランスポート・ネットワーク１４の一部を構成している。ネッ トワーク部分２０はセントラル・オフィス２２を含んでいる。カストマ構内機器 （Customer Premises Equipment - ＣＰＥ）２６のユニットは加入者回線(subsc riber loop)２８によってセントラル・オフィス２２に接続されている。他の多 数のＣＰＥユニット（図示せず）は、他の加入者回線（例えば、２８′，２８″ ）によってセントラル・オフィス２２に接続されている。個別サービス管理シス テム１２は回線３０によってセントラル・オフィス２２に接続されている。ネッ トワーク部分２０はサービス・コントロール・ポイント（service control poin t - ＳＣＰ）２９も含んでいる。ＳＣＰ２９は回線３３によってセントラル・オ フィス２２に接続され、回線３５によって個別サービス管理システム１２に接続 されている。ＶＬＲとＨＬＲレジスタ３４はセントラル・オフィス２２に置かれ 、そこで維持管理されている。これとは別に、ＶＬＲとＨＬＲレジスタ３４′は サービス・コントロール・ポイント２９に置かれ、そこで維持管理されている。 なお、回線３０，３３および３５はトランスポート・ネットワーク１４の一部に なっていることに注意するべきである。 サービス管理システム１２はコンピュータ３２と記憶装置３６を備えている。 記憶装置３６はデータベースをストアしており、このデータベースには、カスト マ・プロフィール・レコード(customer profile record)と（ＣＰＲ）とクレジ ット・レコードが、電話番号管理といった他の機能に関する他のレコードと一緒 に収められている。コンピュータ３２は、記憶装置３６にストアされたデータベ ースを管理するデータベース管理システムを実行させている。また、コンピュー タ３２は、電話ネットワークにおけるサービスの提供を制御するアプリケーショ ン・ソフトウェア（例えば、呼転送を実現するようにデータベースを変更するア プリケーション・ソフトウェア）も実行させている。このアプリケーション・ソ フトウェアは、セントラル・オフィス２２を経由してコンピュータ３２と通信す るＣＰＥのユニット（例えば、ＣＰＥ２６）から要求することが可能になってい る。コンピュータ３２は電話番号管理も行っている。また、コンピュータ３２は ＨＬＲとＶＬＲ３４または３４′の管理に必要な情報も維持管理している。 以上のほかに、コンピュータ３２は、セントラル・オフィス２２内のスイッチ によって行われる交換といったように、ネットワーク内のある種のハードウェア ・エレメントを制御することによってサービス・アクチベーション(service act ivation)を実行する。例えば、呼転送オペレーションを実行するには、セントラ ル・オフィス２２内のスイッチを変更して、あるＣＰＥに常時スイッチされてい る呼が他のどこかにスイッチされるようにする必要がある。サービス・コントロ ール・ポイント２９もコンピュータ３２によって制御されている。 コンピュータ３２はＩＤＴＭも含んでいる（図１、図２および図３を参照）。 これは、図２のサービス管理システム１２が他のサービス・プロバイダ（長距離 キャリヤや他のローカル電話会社）に所属する他のサービス管理システムと通信 して本発明の分散サービス管理システムを構築することを可能にさせている。こ れは、コンピュータ３２に置かれたアプリケーションが他のサービス管理システ ムに置かれているデータベースにアクセスすることを可能にする。 以下、図３を参照してＩＤＴＭについてより詳しく説明する。具体的には、図 ３はＩＤＴＭ ＡおよびＩＤＴＭ Ｂと名づけた２つのＩＤＴＭを示している。 ＩＤＴＭ Ａはサイト１に置かれている第１サービス管理システム１２−Ａの一 部になっている。サイト１には、第１サービス管理システム１２−Ａを実装して いるコンピュータまたは他のデータ処理システムが置かれている。ＩＤＴＭ Ｂ はサイト２に置かれている第２サービス管理システム１２−Ｂの一部になってい る。サイト２には、第２サービス管理システム１２−Ｂを実装しているコンピュ ータまたは他のデータ処理システムが置かれている。サービス管理システム１２ −Ａはデータベース５３を管理するローカル・データベース管理システム５２を 含んでいる。サービス管理システム１２−Ｂはローカル・データベース５３′を 管理するローカル・データベース管理システム５２′を含んでいる。アプリケー ション５８はサービス管理システム１２−Ａで実行され、アプリケーション５８ ′はサービス管理システム１２−Ｂで実行されている。 各々のＩＤＴＭ（例えば、ＩＤＴＭ−ＡとＩＤＴＭ−Ｂ）は、複数の個別サー ビス管理システム（例えば、１２−Ａ，１２−Ｂ）に所属する複数のデータベー ス（例えば、５３，５３′）を本発明の分散サービス管理システムであるマルチ データベース・トランザクション管理システムに統合化している。 ＩＤＴＭ Ａはエージェント・プール(agent pool)５１を形成している複数の エージェント５０を備えている。エージェント(agent)とは、アプリケーション がローカル・デーベース内のデータをアクセスすることを可能にするソフトウェ ア・プロセスのことである。ＩＤＴＭ−Ａはトランザクション・マネージャ(tra nsaction manager)６０と通信マネージャ(communication manager)６２も備えて いる。ＩＤＴＭ−Ｂもエージェント・プール５１′を形成している複数のエージ ェント５０′を備えている。ＩＤＴＭ−Ｂもまた、トランザクション・マネージ ャ６０′と通信マネージャ６２′を備えている。これらのＩＤＴＭは通信マネー ジャ６２と６２′に接続されているトランスポート・ネットワーク１４を通して ＳＱＬを使用して通信する。 エージェント５０と５０′はローカル・データベース管理システム５２と５２ ′およびローカル・データベース５３と５３′をそれぞれカプセル化して、アプ リケーション５８，５８′とデータベース管理システムとの間の仲介役をしてい る（例えば、J．PonsおよびJ．Vilarem共著「混合並行処理制御：分散 データベース・システムの異種の取扱い(Mixed Concurency Control: Dealing w ith Heterogeneity in Distributed Database Systems)，Proc．of the Fourtee nth Conference on VLDB，Los Angeles，1988を参照）。そのために、ＩＤＴＭ が既に存在するサービス管理システムにインストールされるとき、既存のサービ ス管理システムはそのデータベース管理システムを含んでいるので、変更する必 要はない。 ＩＤＴＭのオペレーションを理解する上で役立つと思われるので、サイト１に 置かれているサービス管理システム１２−Ａのアプリケーション５８について考 えてみることにする。アプリケーション５８は、まずＩＤＴＭＡのローカル・ト ランザクション・マネージャ６０に登録することによってローカル・データベー スとリモート・データベース（例えば、５３，５３′）にアクセスする。ローカ ル・トランザクション・マネージャ６０はローカル・アプリケーション５８から 登録要求を受け取ると、ローカル・トランザクション・マネージャ６０はローカ ル・エージェント５０を割り当てて、そのエージェントをアプリケーション５８ に接続する。割り当てられたエージェント５０はコーディネータ・エージェント (coordinator agent)と呼ばれる。ローカル・アプリケーション５８はサイト２ に置かれたサービス管理システム１２−Ｂのデータベース５３′などのリモート ・データベースにアクセスする必要が起こることがある。その場合には、サイト １側のローカル・コーディネータ・エージェント５０は、サイト２側のリモート ・エージェント５０′を割り当てるようにローカル・トランザクション・マネー ジャ６０に要求する。リモート・エージェント５０′（参加エージェント(parti cipant agent)と呼ばれる）を割り当てるために、サイト１側のローカル・トラ ンザクション・マネージャ６０はローカル通信マネージャ６２、ネットワーク１ ４およびリモート通信マネージャ６２′（サイト２側の）を通してリモート参加 エージェント５０′を割り当てるトランザクション・マネージャ６０′と通信す る。そのあとで、アプリケーションはコーディネータ・エージェント５０と参加 エージェント５０′を通して、リモート・データベース５３′に対するオペレー ションを発行することができる。チャネルはネットワーク１４を使用して参加５ ０′エージェントとしてのコーディネータ・エージェント５０の 間でセットアップされる。 一般的には、異種のエージェントがトランザクション・マネージャによって異 種のアプリケーションに割り当てられる。例えば、あるアプリケーションがバッ チによる更新(batched updates)を望んでいれば、データベースに対する更新オ ペレーションを累積するそのアプリケーションにエージェントが割り当てられる ことになる。他方、あるアプリケーションが高速応答を要求していれば、高速応 答時間のために最適化されたエージェントがそのアプリケーションに割り当てら れることになる。データベース・アクセス・オペレーションを実行するエージェ ント５０，５０′は従来とまったく同じである。 各ＩＤＴＭエージェント５０，５０′は次のような機能を実行するいくつかの モジュールから構成されている。すなわち、データベース・アクセス、持続的ス トレージ、並行処理制御、コミット・プロトコル、およびイベント検出である。 アプリケーションはロッキング(locking)または証明(certification)手法を使用 して、グローバル・データの並行処理制御を行なうことができる。 ＩＤＴＭは、グローバル・データ・アクセス・インタフェースを単純化する関 数群を備えている。表１は、アプリケーションで使用できるインタフェース関数 のいくつかを示している。表１では、一般にデータベース管理システムに用意さ れていない関数であるか、またはパラメータがデータベース管理システムに用意 されているものと異なっているような関数だけを含んでいる。 アプリケーションはトリガ・ルール(trigger rule)管理インタフェースを使用 してイベント検出ルールをＩＤＴＭに挿入することができる（表１の下から２行 目を参照）。トリガ・ルールをＩＤＴＭに追加する"addtrigger"関数は次の４行 の疑似コード(pseudocode)で記述されている。 Addtrigger triggerName triggerContext EVEVT eventype relationName（ワイルドカード属性名のリスト）NULL PREDICATE（relationName 属性名 "attributeValue" のリスト）NULL ACTION actionHandler NULL "triggerName"はそれに関心をもつアプリケーションによって参照されるトリ ガの名前を指定している。"triggerContext"はトリガのセキュリティ・レベルま たはその他のアプリケーション・コンテキストなどの情報を収めている。 "actionHandler"はトリガリング・トランザクションがコミットする前に実行さ れる。ユニークなトリガＩＤは"addtrigger"オペレーションの後に返される。ト リガのEVENTとPREDICATEが真と評価されると、トリガ・ルールがファイヤされる 。トリガが追加されたあと、そのトリガの名前を知っている他のアプリケーショ ンは"addtotrigger"オペレーションを使用してトリガの通知リストに追加するこ とができる。"addtotrigger"オペレーションが実行されると、トリガがいつファ イヤされるかがアプリケーションに通知される。プロトタイプ・サービス 図４はパーソナル通信サービスがユーザに提供されるシステム１００を示して いる。代表的な例は、ユーザが訪問先ロケーションで携帯電話を一時的に賃借す る場合がある。このユーザは、彼／彼女の自宅の電話に送られてきた電話呼がレ ンタル携帯電話に自動的に転送されることを希望し、レンタル携帯電話での着信 呼を制限することを望んでいる。 図４のシステム１００は、４つのサービス・プロバイダによって維持されてい るネットワークを備えている。ネットワーク２００はユーザのホーム・ローカル 電話会社のネットワークである。図４に示すように、ネットワーク２００は複数 の加入者回線２０２，２０４を含み、これらの回線はＣＰＥユニット２０３，２ ０５をセントラル・オフィス２０８に接続している。図示の例では、ＣＰＥユニ ット２０３は上述したようにユーザの自宅電話である。また、回線２０９によっ てセントラル・オフィス２０８に接続されているものとして、ホーム・ローカル 電話会社によって運用されているサービス管理システム２１０がある。サービス 管理システム２１０はコンピュータ２１２と、カストマ・プロフィール・レコー ドとクレジット・レコードからなるデータベースをストアしている記憶装置２１ ４とを備えている。サービス管理システム２１０などのサービス管理システムの オペレーションは詳細に上述した通りである。ネットワーク２００はサービス・ コントロール・ポイント２２０も収容しており、これは回線２２２によってセン トラル・オフィス２０８に、回線２２４によってサービス管理システム ２１０に接続されている。 ホーム・ローカル電話会社のネットワーク２００は長距離キャリヤのネットワ ーク３００に接続されている。ネットワーク３００の一部は図４に示されている 。ネットワーク３００はセントラル・オフィス３０２，３０４，３０６を備えて いる。これらのセントラル・オフィスは長距離トランスポート・ネットワーク３ ０８で相互接続されている。 ローカル電話ネットワーク２００のセントラル・オフィス２０８は長距離電話 ネットワーク３００のセントラル・オフィス３０２に接続されている。長距離キ ャリヤのサービス管理システム３１０はセントラル・オフィス３０４に接続され ている。サービス管理システム３１０はコンピュータ３１２と記憶装置３１４を 備えている。 ネットワーク４００はローカル電話ネットワークでもある。ローカル電話ネッ トワーク４００はユーザの訪問先ローカル電話会社によって運用されている。ロ ーカル電話ネットワーク４００はセントラル・オフィス４０２を含んでいる。ロ ーカル電話ネットワーク４００のセントラル・オフィス４０２は長距離ネットワ ーク３００のセントラル・オフィス３０６に接続されている。端末４０４の形態 のＣＰＥユニットは加入者回線(subscriber loop)４０５によってセントラル・ オフィス４０２にも接続されている。サービス管理システム４１０はセントラル ・オフィス４０２にも接続されている。サービス管理システム４１０はコンピュ ータ４１２と記憶装置４１４を備えている。ネットワーク４００はサービス・コ ントロール・ポイント４００も備え、これは回線４２２によってセントラル・オ フィス４０２に、回線４２４によってサービス管理システム４１０に接続されて いる。 ネットワーク５００はパーソナル通信プロバイダ、この例では、セルラ電話会 社のネットワークである。セルラ電話ネットワーク５００はスイッチ５０２を含 んでいる。スイッチ５０２はローカル電話ネットワーク４００のセントラル・オ フィス４０２に接続されている。スイッチ５０２は携帯電話５０６などの複数の 携帯電話との間で信号を送受信する無線ポート５０４にも接続されている。スイ ッチ５０２には、コンピュータ５１２と記憶装置５１４を備えているサービス管 理システム５１０も接続されている。 したがって、図４のシステム１００は４つのサービス・プロデューサのネット ワークを含んでいる。これらはホーム・ローカル電話会社のローカル電話ネット ワーク２００、長距離電話会社の長距離ネットワーク３００、訪問先ローカル電 話会社のローカル電話ネットワーク４００、およびセルラ電話会社のセルラ電話 ネットワーク５００である。これらの４サービス・プロバイダの各々は自分のサ ービス管理システムをもっている。これらはホーム・ローカル電話会社のサービ ス管理システム２１０、長距離電話会社のサービス管理システム３１０、訪問先 ローカル距離電話会社のサービス管理システム４１０、およびセルラ電話会社の サービス管理システム５１０である。 個別サービス管理システムの各々はカストマ・プロフィール・レコード（ＣＰ Ｒ）とクレジット・レコード（ＣＲ）をストアしているローカル・データベース をもっている。ＣＰＲは名前、住所、オフィス電話、およびネットワーク３００ を運用するキャリヤなどの優先長距離キャリヤに関する情報を収めている。また 、着信呼や発信呼(outgoing call)制限などのサービスに関する情報も収めてい る。カストマ・クレジット・レコードは、例えば、歓迎しないユーザ(unaccepta ble users)に関する情報を収めている。個別サービス管理システムの各々はロー カル・データベースを管理するデータベース管理システムももっている。 本発明によれば、個別サービス管理システムは、分散サービス管理システムを 構成するように結合されている。これは、各個別サービス管理システムにＩＤＴ Ｍ（詳細は上述した通り）を用意することにより行われる。 上述したように、ＩＤＴＭは複数の個別サービス管理システムに所属する データベースを単一のマルチデータベース・トランザクション管理環境(multida tabase transaction management environment)に統合化する。各ＩＤＴＭは複数 のエージェントを備え、これらのエージェントはローカル・データベースをカプ セル化して、ローカル・データベースへのアクセスを試みるすべてのアプリケー ション（リモートまたはローカル）の仲介役の働きする。 以上のように、サービス管理システム２１０，３１０，４１０、および５１０ が一緒になって、本発明による分散サービス管理システムを形成している。この 分散サービス管理システムによると、複数のサービス・プロバイダにまたがって ユーザにサービスを提供することができる。 空港で携帯電話を賃借し、呼転送と着信呼制限サービスを必要としているユー ザの例に戻って説明することにする。これらのサービスは、本発明の分散サービ ス管理システムを使用すると、いく通りかの方法で実現することが可能である。 このサービスの実現は、図示的に、次のようなステップを使用する。 １．呼転送と呼制限サービスは、セルラ電話ネットワーク５００のサービス管 理システム５１０で実行されているアプリケーションによって実現されている。 このアプリケーションはどこからでも、例えば、セントラル・オフィス４０２と スイッチ５０２を経由してサービス管理システム５１０に接続された端末４０４ からアクチベートさせることも、システム１００を経由してサービス管理システ ム５１０に接続されたユーザのベース電話２０３からアクチベートさせることも 可能である。アプリケーションはローカルＩＤＴＭに置かれたトランザクション ・マネージャに登録し（図３参照）、ローカル・コーディネータ・エージェント がアプリケーションに割り当てられる。ローカル・コーディネータ・エージェン トはサービス管理システム５１０に置かれたローカル・データベースをアクセス し、ユーザに関するカストマ・プロフィール・レコードをデータベースに作成す る。コーディネータ・エージェントは着信呼制限情報と呼転送情報をこのレコー ドの中に挿入する。分散サービス管理システムを使用して、サービス管理システ ム５１０側のローカル・エージェントはこのレコードが他 のサービス・プロバイダのサービス管理システム４１０，３１０、および２１０ に挿入されるように手配する。上述したように、これは、これらの他のサービス 管理システムに置かれたＩＤＴＭを使用して、リモート参加エージェントを割り 当てることによって達成される。 ２．データベース挿入要求を受け取ると、サービス管理システム４１０，３１ ０および２１０の各々は挿入が受付け可能であるかどうかを、例えば、ユーザの クレジット・レコードをチェックすることによって判断する。挿入が受付け可能 であれば、ユーザのカストマ・プロフィール・レコードが各サービス管理システ ムのローカル・データベースに挿入される。逆に、挿入がどのサービス・プロバ イダにも受付け不能であれば、ユーザは希望のサービスに加入できないことにな る。 ３．カストマ・プロフィール・レコードを挿入すると、サービス管理システム ４１０は呼制限情報を含んでいるＶＬＲを作成する。このＶＬＲは、訪問先ロー カル電話ネットワークで呼制限とルーチング(routing)を実行するサービス・コ ントロール・ポイント４２０またはセントラル・オフィス４０２へ送信される。 ４．カストマ・プロフィール・レコードの挿入要求を受け取ると、長距離キャ リヤのサービス管理システム３１０はそれが訪問先ロケーションでカバレッジ(c overage)をもっているかどうかを判断し、そのデータベースで維持されているク レジット・レコードを使用してクレジット・チェックも実行する。カバレッジの エリアとクレジット・チェックが共に肯定的であれば、挿入要求は許可される。 ５．カストマ・プロフィール・レコード挿入要求を受け取ると、ホーム・ロー カル電話会社は、そのサービス管理システム２１０を通して、カストマ・クレジ ット・レコードをチェックし、呼転送情報とＶＲＬロケーションを含んでいるＨ ＬＲを作成し、そのＨＬＲを、ベース電話２０３をカバーするローカル・サービ ス・コントロール・ポイント（例えば、サービス・コントロール・ポイント２２ ０）またはセントラル・オフィス（例えば、セントラル・オフィス２０２）にダ ウンロードする。次に、呼転送サービス がアクチベートされるが、これは、セントラル・オフィス２０２が最初にベース 電話２０３へ送られてきた呼を、ネットワーク２００，３００、および４００を 通して移動電話５０６へルート(route)することにより行われる。呼をネーク２ ００，３００、および４００を経由して転送する手法はいくつかがあるが、これ については下述する。 ６．ユーザが貸借した携帯電話を返却したときは、分散サービス管理システム が利用されて、カストプロフィール・レコードをすべてのデータベースから除去 する。サービス管理５１０側のローカル・コーディネータ・エージェントはその カストマ・プロフィール・レコードをローカル・データベースから削除する。ま た、サービス管理システム５１０側のローカル・コーディネータ・エージェント は他のサービス管理システム４１０，３１０，２１０側の参加エージェントがこ のカストマ・プロフィール・レコードを削除するように手配する。削除されると 、ホーム・ローカル電話会社は呼転送サービスを非アクチベートし、呼転送を制 御しているサービス・コントロール・ポイントまたはセントラル・オフィスから ＨＬＲを削除する。サービス管理システム４１０はそのユーザのＶＬＲを削除す る。 呼転送オペレーションは以下に説明するように、いくつかの方法で行うことが できる。 ・ ユーザのベース電話へ最初に送られてきた呼は、ユーザの携帯電話に割り 当てられたユニーク番号へパーソナル・通信・プロバイダによって転送すること ができる。 ・ ユーザのベース電話へ最初に送られてきた呼は、パーソナル通信サービス ・プロバイダに割り当てられたグループ番号へ転送することができる。パーソナ ル通信・サービス・プロバイダは、ユーザによって与えられたベース番号（例え ば、ユーザの自宅番号やオフィス番号またはユーザによって与えられた他のベー ス番号）を、レンタル携帯電話に割り当てられた電話番号とリンクする記憶デバ イスのデータベースを維持している。着信呼が到着したとき、ベース電話番号は レンタル電話番号を検索するとき のキーの働きをする。レンタル電話番号が検索されると、着信呼はユーザへルー トされる。 ・ この方法は前記の方法と同じであるが、全国的グループ番号は１つだけで ある。呼はユーザのベース電話から全国的グループ番号へ転送される。ベース番 号を特定のパーソナル通信サービス・プロバイダのグループ番号またはレンタル 携帯電話の番号に対応づけている(map)集中型データベース(centralized databa se)が維持されている。着信呼が到着すると、テーブル・エントリはユーザのベ ース番号を使用してインデックスされる。そのあと、呼は検索されたエントリを もつ適切なサービス・プロバイダまたは電話へ転送される。呼が特定のサービス ・プロバイダのグループ番号へルートされるときは、別のテーブルがインデック スされて、呼が転送される先の電話の電話番号が得られる。 上記の方法はすべて、本発明の分散サービス管理システムを使用して、適切な 呼転送情報を適切なサービス・プロバイダのデータベースに挿入することによっ て実現することができる。 以上を要約すると、パーソナル通信サービスをユーザに供給することは、挿入 、レコード・チェッキング、削除オペレーションといった、複数のデータベース ・オペレーションからなる。これらのオペレーションは、本発明の分散サービス 管理システムおよび方法を使用すると、複数のサービス・プロバイダの複数のデ ータベースにまたがって行われる。 以上から理解されるように、ある種のトリガ・ルールが作成されて、呼を携帯 電話の一時的ユーザへ転送するといった、サービスを実現することが可能である 。例えば、ホーム・ローカル会社のサービス管理システムによってステップ５を 実行するには、次の疑似コードで表わされたトリガ・ルールを使用することが可 能である。 On insert to CPR，check credit before commit and create(HLR,load s ervice control point，activate call forwarding)after commit． （ＣＰＲへの挿入時に、コミットの前にクレジットをチェックし コミッ トの後で（ＨＬＲを作成し、サービス・コントロール・ポイントにロードし、呼 転送をアクチベートする））結論 分散サービス管理システムは、パーソナル通信サービスを複数のサービス・プ ロバイダにまたがって提供する。最後に、本発明の上述した実施の形態は単なる 例示である。種々態様の実施の形態および均等な構造は、請求の範囲から逸脱す ることなしに、この分野の精通者により変更できることは勿論である。

【手続補正書】特許法第１８４条の８ 【提出日】１９９６年８月２９日 【補正内容】 請求の範囲 １．移動するユーザに一時的に通信サービスを提供する方法において、 カストマ構内機器のユニットを使用して、第１通信サービス・プロバイダによ って運用される第１ネットワーク内の第１サービス管理システムに置かれたアプ リケーションをアクチベートするステップと、 前記アプリケーションを前記第１サービス管理システムに置かれたトランザク ション・マネージャに登録するステップと、 前記トランザクション・マネージャによってローカル・エージェントを該アプ リケーションに割り当てるステップと、 前記ローカル・エージェントを使用して、前記第１サービス管理システムのロ ーカル・データベースにアクセスし、ユーザに関するカストマ・プロフィール・ レコードを生成するステップと、 前記カストマ・プロフィール・レコードの少なくとも一部を、第２通信サービ ス・プロバイダによって運用されている第２サービス管理システムのリモート・ データベースに挿入させる要求を該ローカル・エージェントによって生成するス テップと、 前記挿入要求が受付け可能であるかどうかを前記リモート・データベースで判 断するステップと、 該挿入要求が受付け可能であれば、呼プロフィール・レコードを使用して前記 サービス・プロバイダの１つによって運用されているネットワーク内の呼の処理 を変更するステップと を備えたことを特徴とする方法。 ２．請求項１に記載の方法において、 呼の処理を変更する前記ステップはユーザのベース電話へ送られてきた呼を別 の場所へ転送することを備えたことを特徴とする方法。 ３．請求項２に記載の方法において、 前記呼は携帯電話へ転送されることを特徴とする方法。 ４．請求項３に記載の方法において、 呼を携帯電話へ転送する前記ステップは、 （ａ）呼をグループ電話番号へ転送してテーブルをアクセスするためのステッ プと、 （ｂ）ユーザのベース電話番号でテーブルをアクセスしてユーザの一時的携帯 電話番号を得るためのステップと、 （ｃ）一時的携帯電話番号を使用して呼をユーザの携帯電話へ転送するステッ プと を備えたことを特徴とする方法。 ５．複数の別個の通信サービス・プロバイダを含む通信システムにおいて、該サ ービス・プロバイダの各々は通信ネットワークと、データベースと、トランザク ション・マネージャとをサービス管理システムに備え、第１通信サービス・プロ バイダ側で一時ベースの各地を移動するユーザの携帯電話への呼を、第２通信サ ービス・プロバイダ側で該ユーザのベース電話から転送する方法であって、該方 法は、 前記第２通信サービス・プロバイダの前記サービス管理システムに置かれた前 記アプリケーションをアクチベートするステップと、 該アプリケーションを該第２通信サービス・プロバイダの前記トランザクショ ン管理システムに登録するステップと、 該第２通信サービス・プロバイダの該トランザクション管理システムによって ローカル・エージェントを該アプリケーションに割り当てるステップと、 前記ローカル・エージェントを使用して、該第２通信サービス・プロバイダの 該サービス管理システムのローカル・データベースにアクセスし、該ユーザのカ ストマ・プロフィール・レコードを生成するステップと、 前記カストマ・プロフィール・レコードの少なくとも一部を前記第１通信サー ビス・プロバイダのサービス管理システムに置かれたリモート・データベースに 挿入させる要求を該ローカル・エージェントによって生成するステップと、 前記挿入要求が受付け可能であるかどうかを前記リモート・データベースで判 断するステップと、 前記挿入要求が受付け可能であれば、該第２通信サービス・プロバイダからの 呼プロフィール・レコードを使用して該第１通信サービス・プロバイダのネット ワーク内の呼の処理を変更するステップとを含むことを特徴とする方法。 ６．通信システムにおいて、請求項５に記載の方法の該第１通信サービス・プロ バイダの該ネットワーク内の呼の処理を変更する前記ステップは、 前記第１通信サービス・プロバイダ側のテーブルをグループ電話番号でアクセ スし、ユーザの一時的携帯電話番号を得るステップと、 一時的携帯電話番号を使用して呼をユーザの前記携帯電話へ転送するステップ と を備えたことを特徴とする方法。 ７．通信システムにおいて、請求項５に記載の方法の前記リモート・データベー スは複数のユーザのベース電話番号と、該ユーザによって一時的に使用されてい る携帯電話に割り当てられた電話番号との対応づけを収めており、前記第１通信 サービス・プロバイダの前記ネットワーク内の呼の処理を変更する前記ステップ は、 前記第２通信サービス・プロバイダ側で前記各地を移動するユーザのベース電 話番号を使用して前記リモート・データベースをアクセスし、前記第１通信サー ビス・プロバイダ側で該各地を移動するユーザの携帯電話の一時的電話番号を得 るステップを備えたことを特徴とする方法。 【図４】

───────────────────────────────────────────────────── フロントページの続き (72)発明者 チェン，リー−ティン アメリカ合衆国 08816 ニュージャージ ー州 イースト ブランズウィック ライ ト コート ８ (72)発明者 コチンワラ，ムニール アメリカ合衆国 07920 ニュージャージ ー州 バスキング リッジ ブリオン ロ ード 14 (72)発明者 リウ，チェン−チャン アメリカ合衆国 07059 ニュージャージ ー州 ワレン オーバールック ドライブ ５ (72)発明者 ワイズ，トーマス，ロイド アメリカ合衆国 08854 ニュージャージ ー州 ピスカタウエイ オーバーブルック ロード 210

Claims (1)

1. 【特許請求の範囲】 １．通信サービスを提供する分散サービス管理システムにおいて、 複数の個別サービス管理システムと、 前記個別サービス管理システム間を相互に接続するネットワークとを備え、 該個別サービス管理システムの各々は、 記憶デバイスにストアされたローカル・データベースと、 個別サービス管理システムの異なるそれぞれに置かれたアプリケーショ ンがローカル・データベースをアクセスすることを可能にするインタフェースと を備えたことを特徴とする分散サービス管理システム。 ２．請求項１に記載の分散サービス管理システムにおいて、 前記個別サービス管理システムにおけるインタフェースは前記ネットワークを 通してメッセージを送信することによって通信することを特徴とするシステム。 ３．請求項１に記載の分散サービス管理システムにおいて、 前記個別サービス管理システムのうちの特定の１つに置かれたインタフェース は、 該特定のサービス管理システムに置かれたローカル・データベースをアクセス するエージェントのプールと、 エージェントを前記アプリケーションに割り当てるトランザクション・マネー ジャと を備えたことを特徴とするシステム。 ４．請求項３に記載の分散サービス管理システムにおいて、 アプリケーションは特定の個別サービス管理システムに置かれたアプリケーシ ョンであるか、または前記個別サービス管理システムのうちの別のアプリケーシ ョンであることを特徴とするシステム。 ５．請求項１に記載の分散サービス管理システムにおいて、 前記サービス管理システムの１つはローカル電話会社によって運用されている ことを特徴とするシステム。 ６．請求項１に記載の分散サービス管理システムにおいて、 前記１つのサービス管理システムは長距離会社によって運用されていることを 特徴とするシステム。 ７．請求項１に記載の分散サービス管理システムにおいて、 前記サービス管理システムの１つはセルラ電話会社によって運用されているこ とを特徴とするシステム。 ８．請求項１に記載の分散サービス管理システムにおいて、 該分散サービス管理システムはユーザに一時的に割り当てられた携帯電話に通 信サービスを提供することを特徴とするシステム。 ９．請求項８に記載の分散サービス管理システムにおいて、 前記サービスは、前記ユーザの指定の電話から前記携帯電話へ呼を転送するこ とを備えたことを特徴とするシステム。 １０．請求項８に記載のシステムにおいて、 前記サービスは着信呼を前記携帯電話に制限することを含むことを特徴とする システム。 １１．１つ以上の通信サービス・プロバイダの複数のデータベースを管理してユ ーザに通信サービスを提供するようにした分散サービス管理システムにおいて、 該分散サービス管理システムは、 複数の個別サービス管理システムを備え、 前記個別サービス管理システムの各々はローカル・データベースと、個別サー ビス管理システムで実行されているローカル・アプリケーションが他の個別サー ビス管理システムに置かれているローカル・データベースをアクセスすることを 可能にするインタフェースとを備えていて、前記通信サービスを提供するように したことを特徴とする分散サービス管理システム。 １２．請求項１１に記載の分散サービス管理システムにおいて、 前記サービス管理システムは１つ以上のローカル電話会社および長距離電話会 社によって運用されていることを特徴とするシステム。 １３．請求項１２に記載の分散サービス管理システムにおいて、 前記サービス管理システムの１つはセルラ電話会社によって運用されているこ とを特徴とするシステム。 １４．請求項１１に記載の分散サービス管理システムにおいて、 前記サービスはユーザによって一時的に使用されている移動電話に提供される サービスであることを特徴とするシステム。 １５．請求項１１に記載の分散サービス管理システムにおいて、 前記個別サービス管理システムのうちの特定の１つに置かれたインタフェース は、 該特定のサービス管理システムに置かれたローカル・データベースをアクセス するエージェントのプールと、 該特定のサービス管理システムで実行されているローカル・アプリケーション と、該個別サービス管理システムのうちの他のサービス管理システムで実行され ているリモート・アプリケーションとにエージェントを割り当てるトランザクシ ョン・マネージャと を備えたことを特徴とするシステム。 １６．１つ以上の通信サービス・プロバイダによって運用されている複数の個別 サービス管理システムを備えている分散サービス管理システムを使用して、通信 サービスを提供する方法において、該方法は、 前記複数の個別サービス管理システムで維持されているデータベースにアクセ スするステップを備え、該アクセスするステップは、 該個別サービス管理システムのうちの特定の１つに置かれたコーディネータ・ エージェントをアプリケーションに割り当てるステップと、 前記コーディネータ・エージェントを使用して前記特定のサービス管理システ ムに置かれたデータベースにアクセスするステップと、 該コーディネータ・エージェントの制御の下で、該個別サービス管理システム のうちの異なる１つへメッセージを送り、該異なる個別サービス管理システムに 置かれた特定のエージェントを前記アプリケーションに割り当てるようにしたス テップと、 前記特定のエージェントを使用して該異なる個別サービス管理システムに置か れたデータベースにアクセスするステップと を備えたことを特徴とする方法。 １７．請求項１６に記載の方法において、 前記アクセスされたデータベースの１つから前記ユーザに前記サービスを提供 するために前記サービス・プロバイダの１つによって運用されているネットワー ク内の呼処理システムへデータをロードするステップをさらに備えたことを特徴 とする方法。 １８．請求項１７に記載の方法において、 前記サービスは前記ユーザによって一時的に使用されている携帯電話に提供さ れるサービスであることを特徴とする方法。 １９．１つ以上の通信サービス・プロバイダが関係する通信サービスをユーザに 提供するために該１つ以上の通信サービス・プロバイダによって運用されている 複数のデータベースにアプリケーションがアクセスすることを可能にする分散 サービス管理システムにおいて、 複数の異なるサービス・プロバイダによって運用されている複数の個別サービ ス管理システムであって、該個別サービス管理システムはネットワークによって 相互に接続されているものとを備え、 前記個別サービス管理システムの各々は電気通信サービス・ユーザに関する情 報を含んでいるローカル・データベースと、複数のエージェントを備えているイ ンタフェースとを備え、前記エージェントはローカル・データベース上でデータ ベース・アクセス・オペレーションを実行して前記アプリケーションがローカル ・データベースにアクセスできるようにしたことを特徴とする分散サービス管理 システム。 ２０．請求項１９に記載の分散サービス管理システムにおいて、 個別サービス管理システムのうちの特定の１つに置かれたインタフェースは、 特定のアプリケーションが前記特定のサービス管理システムに置かれたデータベ ースにアクセスすることを可能にするコーディネータ・エージェントを備えてお り、 前記個別サービス管理システムのうちの異なる１つに置かれたインタフェース は、コーディネータ・エージェントの制御の下でアクチベートされて、特定のア プリケーションが前記異なるサービス管理システムに置かれたデータベースにア クセスすることを可能にする特定のエージェントを備えたことを特徴とするシス テム。 ２１．通信サービスの分散サービス管理方法において、 第１の通信サービス・プロバイダによって運用されているローカル個別サービ ス管理システム側でローカル・アプリケーションをローカル・エージェントに接 続するステップと、 前記エージェントを使用して、前記アプリケーションが前記ローカル・サービ ス管理システムのローカル・データベースにアクセスすることを可能にするステ ップであって、前記ローカル・データベースは前記第１サービス・プロバイダ のカストマに関する情報を含んでいるものと、 前記ローカル・エージェントから出された要求を第２の通信サービス・プロバ イダによって運用されているリモート個別サービス管理システムへネットワーク を通して送信するステップと、 前記要求に応答して、前記リモート・サービス管理システムに置かれたリモー ト・エージェントを該アプリケーションに割り当てるステップと、 前記リモート・エージェントを使用して、該アプリケーションが該リモート・ サービス管理システムに置かれたリモート・データベースにアクセスすることを 可能にするステップであって、前記リモート・データベースは前記第２サービス ・プロバイダのカストマに関する情報を含んでいるものと を備えたことを特徴とする方法。 ２２．請求項２１に記載の方法において、 前記リモート・データベースに入っている情報を前記第２サービス・プロバイ ダの呼処理システムへロードするステップをさらに備えたことを特徴とする方法 。 ２３．請求項２１に記載の方法において、 前記ローカル・データベースに入っている情報を前記第１サービス・プロバイ ダの呼処理システムへロードするステップをさらに備えたことを特徴とする方法 。 ２４．請求項２１に記載の方法において、 前記第１サービス・プロバイダはセルラ電話会社であり、かつ前記第２サービ ス・プロバイダはローカル電話会社であることを特徴とする方法。 ２５．請求項２１に記載の方法において、 第１サービス・プロバイダは第１ローカル電話会社であり、かつ第２サービス ・プロバイダは第２ローカル電話会社であることを特徴とする方法。 ２６．移動するユーザに一時的に通信サービスを提供する方法において、 カストマ構内機器のユニットを使用して、第１通信サービス・プロバイダによ って運用される第１ネットワーク内の第１サービス管理システムに置かれたアプ リケーションをアクチベートするステップと、 前記アプリケーションを前記第１サービス管理システムに置かれたトランザク ション・マネージャに登録するステップと、 前記トランザクション・マネージャによってローカル・エージェントを該アプ リケーションに割り当てるステップと、 前記ローカル・エージェントを使用して、前記第１サービス管理システムのロ ーカル・データベースにアクセスし、ユーザに関するカストマ・プロフィール・ レコードを生成するステップと、 前記カストマ・プロフィール・レコードの少なくとも一部を、第２通信サービ ス・プロバイダによって運用されている第２サービス管理システムのリモート・ データベースに挿入させる要求を該ローカル・エージェントによって生成するス テップと、 前記挿入要求が受付け可能であるかどうかを前記リモート・データベースで判 断するステップと、 該挿入要求が受付け可能であれば、呼プロフィール・レコードを使用して前記 サービス・プロバイダの１つによって運用されているネットワーク内の呼の処理 を変更するステップと を備えたことを特徴とする方法。 ２７．請求項２６に記載の方法において、 呼の処理を変更する前記ステップはユーザのベース電話へ送られてきた呼を別 の場所へ転送することを備えたことを特徴とする方法。 ２８．請求項２７に記載の方法において、 前記呼は携帯電話へ転送されることを特徴とする方法。 ２９．請求項２８に記載の方法において、 呼を携帯電話へ転送する前記ステップは、 （ａ）呼をグループ電話番号へ転送してテーブルをアクセスするためのステッ プと、 （ｂ）ユーザのベース電話番号でテーブルをアクセスしてユーザの一時的携帯 電話番号を得るためのステップと、 （ｃ）一時的携帯電話番号を使用して呼をユーザの携帯電話へ転送するステッ プと を備えたことを特徴とする方法。 ３０．所望の電気通信サービスをユーザに提供する方法において、 （ａ）ユーザのための所望のサービスに関する情報を含んでいるユーザ・レコ ードを作成するステップと、 （ｂ）ユーザ・レコードを複数の電気通信サービス・プロバイダによって維持 されている複数のデータベースに挿入するステップと、 （ｃ）情報を前記ユーザ・レコードから前記複数のサービス・プロバイダによ って維持されている呼処理システムにロードして、該複数のサービス・プロバイ ダによる呼の処理を変更して該ユーザのための前記サービスを提供するようにす るステップと を備えたことを特徴とする方法。 ３１．請求項３０に記載の方法において、 前記レコードを複数のデータベースに挿入する前記ステップは、 前記サービス・プロバイダのうちの第１のサービス・プロバイダによって運用 されている第１のサービス管理システムに置かれたアプリケーションをアクチベ ートして、第１サービス管理システムに置かれたコーディネータ・エージェント をアプリケーションに割り当てるステップと、 前記コーディネータ・エージェントを使用して、第１サービス管理システムに 置かれた第１データベースにアクセスして前記ユーザ・レコードを作成するス テップと、 前記第１エージェントの制御の下で、前記サービス・プロバイダのうちの他の サービス・プロバイダによって運用されている複数の他のサービス管理システム に置かれた複数の参加エージェントを前記アプリケーションに割り当てるステッ プと、 前記複数の他のエージェントを使用して、該レコードを複数の他のデータベー スに挿入するステップと を備えたことを特徴とする方法。 ３２．請求項３０に記載の方法において、 前記所望のサービスはユーザのベース電話から一時的に利用された携帯電話へ の呼転送であることを特徴とする方法。 ３３．携帯電話を一時的に利用している特定のユーザに呼転送サービスを提供す る方法において、該方法は、 記憶デバイスにストアされているデータベースをサービス・プロバイダによっ て維持しているステップであって、前記データベースは複数のユーザのベース電 話番号と、ユーザによって一時的に使用されている携帯電話に割り当てられた電 話番号との対応づけを含んでいるものと、 該データベースにアクセスして、前記特定ユーザのベース電話番号とユーザに よって一時的に使用されている携帯電話の特定の電話番号を該データベースに挿 入するステップと、 特定ユーザのベース電話番号に最初に送られてきた呼を前記サービス・プロバ イダのグループ電話番号へ転送して、該データベースをアクセスするようにした ステップと、 特定ユーザのベース電話番号をキーとして使用して該データベースにアクセス し、特定ユーザによって使用されている携帯電話の特定電話番号を得るようにし たステップと、 前記呼を前記ユーザによって使用されている前記携帯電話の前記特定電話番号 へ転送するステップと を備えたことを特徴とする方法。