JPH10506513A - ポータブル電話番号サービスを提供するためのシステムおよび方法 - Google Patents

Abstract

(57)【要約】 アドバンスト・インテリジェント・テレフォン・ネットワーク・システムにおいて、交換ポイントは、ダイアルされた「５００」番号に対する応答において、サービス・コントロール・ポイント（ＳＣＰ）に対するクエリをトリガするようプログラムされている。ＳＣＰは、外部データベース・ストア・サービス・プロバイダ情報のデータ・リクエストを実行し、ダイアルされた「５００」番号に対応するサービス・プロバイダ識別若しくはルーティング番号を取得する。ＳＣＰはその後、交換インストラクションをサービス・システム・ポイントへトランスミットし、コールを適切な宛先番号へルートする。

Description

【発明の詳細な説明】 ポータブル電話番号サービスを提供するためのシステムおよび方法 関連出願へのクロス・リファレンス 本願は、以下の出願に関連する。 合衆国特許出願第07/934,240号"System and Method for Creating，Transferr ing，and Monitoring services in a Telecommunication System"（テレコミュ ニケーション・システムにおいてサービスを作成し、転送し、およびモニタする ためのシステムおよび方法）Zaher A．Nazifほかにより１９９２年８月２５日に 出願、合衆国特許出願第07/972,529号"System and Method for Creating，Trans ferring，and Monitoring services in a Telecommunication System"(テレコミ ュニケーション・システムにおいてサービスを作成し、トランスファし、および モニタするためのシステムおよび方法)Zaher A．Nazifほかにより１９９２年１ １月６日に出願（以下「５２９出願」という）、合衆国特許出願第07/972,817号 "A Method of Creating a Telecommunication Service Specification"（テレコ ミュニケーション・サービスの仕様を作成するための方法）K．K．Man ほかによ り１９９２年１１月６日に出願（以下「８１７出願」という）、および、合衆国 特許出願第08/334,120号"A Network-Based Telephone System Providing Coordi nated Voice and Data Delivery"（同調された音声およびデータ・デリバリを提 供するネットワーク・ベースの電話システム）Hollenbachほかにより１９９４年 １１月４日に出願（以下「１２０出願」という）。 これらの出願の内容を基礎とし、参照により本明細書に含まれる。 発明の背景 本発明は、一般的にはテレコミュニケーション・サービスの分野に関し、特 に、テレコミュニケーション・ネットワーク内で提供される電話サービスに関す る。 関連特許出願は、加入者(subscriber)の必要に応じて調整(tailor)されたカス タマイズされたテレコミュニケーション・サービスを作成および実行するための システムおよび方法について説明する。関連特許出願のシステムは、カスタマイ ズされた電話サービスを作成するためのサービス作成環境、および、電話サービ スを実行するためのサービス実行環境を含む。サービス作成環境は、グラフィカ ル・ユーザ・インターフェースを含み、これによってオペレータは「ノード」、 「デシジョン・ボックス」および「ブランチ」を使用して所望のサービスの表示 されたグラフィカル表現を構築することができるようになる。各ノードは、サー ビスの実行のための高レベルのインストラクションを表現する。サービスの表示 されたグラフィカル表現は、バイナリ表現へトランスレートされ、コール・プロ セッシング・レコード（call processing record：ＣＰＲ）としてストアされる 。ＣＰＲは作成環境から実行環境へトランスミットされるが、そこでは、これら はコール処理動作の間に実行され、コール処理インストラクションを電話交換の クエリ（query）に対して返す。 関連特許出願に記載されたカスタマイズされた電話サービスを作成し実行する ためのシステムおよび方法は、アドバンスト・インテリジェント・テレフォン・ ネットワーク（Advanced Intelligent Telephone Network：ＡＩＮ）において実 装されるものとして説明されている。図１Ａ、ＡＩＮの一般的な概要を図示する 。 ＡＩＮは、システム・サービス・ポイント（System Service Point：ＳＳＰ） １０および２０、シグナル・トランスファ・ポイント(Signal Transfer Point： ＳＴＰ)３０、サービス・コントロール・ポイント(Service Control Point：Ｓ ＣＰ)４０、サービス・マネージメント・システム(System Management Systems ：ＳＭＳ)５０、およびデータ・アンド・レポート・システム(Data and Reports System：ＤＲＳ)６０を備えていてもよい。ＳＳＰは、また、セルラ・モビリテ ィ・サービス・コントローラ(Cellular Mobility Service Controller：ＭＳＣ) １５とリンクされ、例えばモバイル・セルラ電話(mobile cellular telephone)１７との通信を提供することもできる。ＳＭＳ５０は、サ ポート・インターフェースを提供するが、これを通じてカスタマ・データおよび サービス・ロジックの追加および管理ができる。ＤＲＳ６０は、さらに、様々な 構成要素によって生成されたネットワーク・データを提供する。 ＳＳＰは、プログラム可能な電話局交換システム(central office switching system)であり、これは加入者電話５からの電話のコールを受信する。各ＳＳＰ は、カスタマ電話コール信号からの様々な「トリガ」を認識して、ＳＣＰに対す るクエリをトリガに基いて生成する。ＳＳＰは、コール（call：呼）がＡＩＮタ イプ・コールであることを示す複数の異なるトリガを認識するようにプログラム されていてもよい。例えば、トリガは、特定のコールされた番号に関係付けられ ていてもよく、さらに、番号のエリア・コードに関係付けられていてもよく、あ るいは、特定のサービス・アクセス・コード(service access code：ＳＡＣ)、 例えば「５００」などに関係付けられていてもよい。 ＳＳＰは、ローカル・エリアＳＴＰ３０とコモン・チャンネル・シグナリング (Common-Channel-Signalling：ＣＣＳ)を介して通信する。ＣＣＳネットワーク ６４は、カスタマの音声信号をトランスミットするために使用されるチャンネル とは分離されたデータ通信チャンネルを使用する。ＳＴＰ３０は、ＳＣＰ４０と 、ＣＣＳパケット交換ネットワーク(packet switched network)６８を介してリ ンクされる。ＣＣＳネットワークは、コールの継続している間のために回線を割 り当てるのではなく、パケット内のデータを交換する。ＳＴＰ３０は、パケット 交換機能を提供する。ＳＴＰ３０からＳＣＰ４０へのダイレクト・リンク(direc t link)が図１Ａに示されているが、さらに階層的なレベルのネットワーク化さ れたＳＴＰが提供されることが多い。 一度クエリがＳＣＰへ発せられると、ＳＣＰの中にあるＣＰＲが、ＳＳＰによ って受信される電話コールが特定のカスタマに処理されるときにとるべき方法を 定義する。ＳＣＰの中にあるマルチ・サービス・アプリケーション・プラットフ ォーム(Multi Services Application Platform：ＭＳＡＰ)（図示せず）は、コ ールに対応付けられた「キー」に基いて適切なＣＰＲにアクセスする。ＭＳＡＰ は、ＣＰＲのノードを処理して対応するコールを発行し、インストラク ションをＳＳＰへ戻すように処理する。ＳＳＰは、その後、カスタマ・コールを これらのコマンドに対するレスポンスにおいて処理する。 図１Ｂに示す通り、ＣＣＳネットワーク接続８５を経由してＳＴＰに接続され たホーム・ロケーション・レジスタ（Home Location Register：ＨＬＲ）８０を 追加することにより、ＳＣＰ４０とＨＬＲ８０との間の通信を提供することがで きる。ＨＬＲは、モバイル・カスタマ・ロケーション情報を、当業界で公知とな っているやりかたで管理する。 ＳＣＰはコマンドを、ＨＬＲへＳＴＰを介して、標準ＩＳ−４１プロトコルを 使用することによって、発行してもよい。ＩＳ−４１プロトコルは、セルラ・テ レコミュニケーション業界によって開発されたもので、セル対セルおよびシステ ム・ワイドな通信を管理する。ＭＳＣ１５は、また、ＳＳＰ２０へ音声電話トラ ンク(trunk)を介して接続され、および、ＳＳＰ２０は同様にＳＳＰ１０に接続 される。もちろん、図１Ａに示されたＳＳＰおよびＭＳＣの方も、電話ネットワ ーク内のほかのＳＳＰおよびＭＳＣに接続されている。 図１Ｂでさらに示す通り、回線識別データベース(Line Identification Datab ase：ＬＩＤＢ)７０は、当業界で公知のものであるが、ＳＴＰへデータ・リンク ７５を介して接続されている。この接続により、ＳＣＰ４０とＬＩＤＢ７０との 間の通信が提供される。 関連特許出願は、また、ＭＳＡＰがＬＩＤＢからのデータに、ＣＰＲで実施さ れる「GetData」リクエストを使用してアクセスする方法も開示する。ＭＳＡＰ は、ＬＩＤＢ７０を通じてアクセスできる外部データベース内にストアされた情 報に対する、トランスペアレントなリアルタイムのアクセスを有する。GetData リクエストはソース独立(source-independent)である。つまり、情報に対するリ クエストは情報のソースがわからなくとも行うことができる。 上記の電話ネットワークは、ある一定の地域(region)のカスタマに対する電話 サービスを提供してもよく、ネットワーク自身は、ほかの同様な電話ネットワー クに接続されている。図２は、どのように地域のネットワークが相互接続されて いるのかの概要を提供する。 ＳＣＰ１００，１１０、および１２０は、州(state)もしくは地域の (regional)ＳＣＰを表現してもよい。言いかえれば、ＳＴＰ１３０の各々は、あ る州や地域のカスタマに対する通信を提供してもよい。これは注意すべきである が、図２のＳＴＰによって示される通り、図１Ａに描かれたＳＴＰ３０は、実際 には複数のＳＴＰのより大きなネットワークを構成してもよい。したがって、図 １ＡのＳＴＰ３０は、実際には図２に示したＳＴＰ１３０および１４０を備えて もよい。 これは公知であるが、電話ネットワークは標準化された電話番号フォーマット に応答する。標準電話番号は、「２０２」などのエリア・コード、「５５５」な どの局番(exchange)、「１２１２」などのローカル番号を含む。別々の地域は、 異なるエリア・コードによって指定される。 加入者があるエリア・コードによってカバーされる地域から別のところへ場所 を移動するときに、その加入者に接触しようとしているコーラ（呼出者：caller ）は、必ず異なるエリア・コードおよび電話番号を使用しなければならない。こ のように、電話番号が変わったことを追跡してアナウンスすることは、明らかに 不便であり、また問題がある。地理的な場所や電話サービス・プロバイダによっ て変わらない、単一の番号を取得することによって得られる利点は確かにある。 しかし、この利点を提供するための努力の過程において、各社は「５００」番サ ービスとして知られるものを開発してきた。 既存のシステムおよび近年の提案においては、ＳＡＣ５００は、地理に依存し ない電話サービスに対する使用とは別にされている。５００ＳＡＣは、適切にプ ログラムされたＳＳＰをトリガしてＳＣＰへクエリを出す。クエリは、例えば、 ダイアルされた５００番の局番を含む。ＭＳＡＰは、ローカルに、特定の局番に 対応するサービス・プロバイダをリストするルックアップ・テーブルをストアし ている。ＣＰＲは、ＭＳＡＰによって実行されるが、この際には、このルックア ップ・テーブルを使用し、これによって、どのサービス・プロバイダがダイアル された局番に対応付けられているかを調べて決める。ＭＳＡＰは、クエリに応答 するが、これは、ＳＳＰにコールを識別されたサービス・プロバイダへルート(r oute)するよう指示を出すことによって行う。サービス・プロバイダは、その後 、さらに番号トランスレーションを実行してコールをその最終的な宛先 (destination)へルートしてもよい。この種のサービスは、一般的には「加入者 トランスレーション」として知られている。 しかし、上記したトランスレーション・システムは、「特定の」サービス・プ ロバイダ若しくはＳＣＰの中にある情報に依存する、ということに注意しておく ことは重要である。その結果、このようなシステムは、明らかな不利益を被って しまい、サービスを確立若しくは終了する場合には特にそうである。 例えば、現在、ある加入者に対するベーシック５００番サービスを確立するに は、所望のサービス地域内の各ＳＣＰの上のルックアップ・テーブル・データベ ースの変更が必要となる。加入者がサービス・プロバイダを変更して、しかも同 じ５００番を維持したいと考える場合には、関連するＳＣＰのすべてを変更して 、特定の５００番を新しいプロバイダが使用できるようにするために解放しなけ ればならない。新しいプロバイダがサービスを開始することができるのはこの時 点だけである。このとき、さらに、適当なＳＣＰを変更して新しいルーティング 判断基準(routing criteria)を反映するようにする。それでもその後で、変更さ れたＳＣＰはまだ、あるサービス・プロバイダに対するコールを方向付けするこ とができるだけで、これはその後でさらに、コールが意図する宛先に到達するま でに、番号トランスレーションを実行しなければならない。 言いかえれば、今日の５００番の提案では、システムが機能するために、５０ ０番を特定のサービス・プロバイダに割り当てなければならない。したがって、 例えば、局番「５２５」を伴う５００番は、AT&T社に割り当てられることになる が、ＡＴ＆Ｔ社はその局番に対応付けられた1 万の利用できる電話番号に対する サービスを提供している。１万を超える電話番号が必要な場合は、ＡＴ＆Ｔはほ かの５００番の局番を獲得しなければならない。その結果、サービス・プロバイ ダおよび５００番を、独立に選択することはできない。これはサービスの作成お よび終了に含まれる問題を単純に説明したものであるが、現在および最近提案さ れたシステムの全般的な複雑さと不利な点の少なくともいくつかを説明するのに 役立つ。 発明の説明 したがって、本発明は、５００番電話サービスを提供するための新しいシステ ムおよび方法であって、従来技術の制限および不利な点による１つ以上の問題を 大いに除くものへ向けられたものである。 本発明は、すばやく効率のよく、サービスを確立する方法を提供する。 また、本発明は、新しいシステムおよび方法を提供するが、これによって簡単 で効率のよくサービスをあるサービス・プロバイダから別のところへトランスフ ァできるようになる。さらに、本発明は、この新しいシステムおよび方法におい て完全なポータビリティを提供し、これによって５００番とサービス・プロバイ ダの選択を分離することができるようになる。 本発明のこのほかの機能および利点は、以下の詳細な説明において説明するが 、その一部はこの詳細な説明から自明であり、あるいは本発明の実施(practice) から学ぶことができる。本発明の目的およびそのほかの利点は、記載された詳細 な説明、およびそれに続く請求の範囲のほか、添付された図面の中において特に 指摘された実施例や組み合わせで実現され、達成されるであろう。 これらおよびその他の利点を達成するために、および本発明の目的に従って、 ここに具体化され広く説明されている通り、本発明は電話交換ネットワークを制 御する方法を提供するが、このネットワークは、データをストアするストレージ ・デバイスに接続されたコントロール・プロセッサ、発信元交換システム(origi nating switching system)、宛先交換システム(destination switching sustem) 、グローバル・タイトル・トランスレーション(Global Title Translation)アド レスにあるロケーション・レジスタ、および、発信元および宛先交換システムと 通信することができる複数の電話を含み、各電話は対応付けられた電話番号を有 し、コールされた電話番号をコールし、前記方法は、コントロール・プロセッサ によって実行される、発信元交換システムからコールされた番号を含む交換クエ リを受信するステップと、ストレージ・デバイスへコールされた番号を含むデー タ・クエリを送信するステップと、ストレージ・デバイスから、少なくとも宛先 交換システムの識別(identification)、ロケーション・レジ スタのグローバル・タイトル・トランスレーション・アドレス、あるいはコール された番号に対応付けられたルーティング番号を含むデータ・レスポンスを受信 するステップと、および、発信元交換システムへ宛先交換システムの識別あるい はコールされた番号に対応付けられたルーティング番号を含むスイッチング・レ スポンスを送信するステップとを備える。 前述した一般的な説明および以下の詳細な説明のいずれも、典型的な説明のた めのものであり、クレームされる発明のさらなる説明を提供する意図のものであ ることを理解すべきである。 図面の簡単な説明 添付する図面は、明細書に組み込まれその一部を構成するが、本発明の現在の 好ましい実施形態を図示するものであり、上記した一般的な説明および以下に示 す好ましい実装の詳細な説明を伴い、本発明の原理を説明するのに役立つ。図面 においては、 図１Ａは、アドバンスト・インテリジェント・テレフォン・ネットワーク（Ａ ＩＮ）ブロック図である。 図１Ｂは、ＨＬＲおよびＬＩＤＢと接続されているＡＩＮのブロック図である 。 図２は、ＡＩＮの拡大されたブロック図である。 図３は、本発明の1 実施形態を図示するＡＩＮのブロック図である。 図４は、本発明の実施形態に従ってＡＩＮにおけるデータ・フローを図示する ブロック図である。 図５から図９は、本発明の好ましい実施形態のメイン処理フローを実装するコ ール・プロセッシング・レコードのコンピュータ画面プリントアウトである。 図１０から図１２は、本発明の好ましい実施形態のサブプロセッシング・ルー チンを実装するコール・プロセッシング・レコードのコンピュータ画面プリント アウトである。 本発明を遂行するための最適実施形態 添付した図面に図示された本発明の好ましい実装の構築および操作の詳細につ いてこれから参照する。本発明の好ましい実装の以下の説明は、本発明の説明の ためだけのものである。本発明はこれらの実装に限定されない。ほかの実装によ って実現してもよい。 図３は、本発明の好ましい実装を図示する。ネットワークにおいては、ＳＳＰ ３００および３０５は、ＳＴＰ３３０と、ＣＣＳリンク３０２および３０８を経 由して、それぞれ通信する。同様にＣＣＳ通信リンク３１２および３１８はＳＳ Ｐ３１０および３１５をそれぞれＳＴＰ３３５へ接続する。セルラＭＳＣ３２０ および３２５もまた、ＳＳＰ３００および３１５に、それぞれ、ネットワーク・ リンク３２２および３２８を通じて、リンクされる。 次にＳＴＰ３３０および３３５は、それぞれリンク３３２および３３８によっ て、ＳＴＰ３４０とネットワークされている。ＳＴＰ３４０は、ＳＣＰ３５０と リンク３４２経由で、ＨＬＲ３６０とＩＳ−４１リンク３５２経由で、およびＬ ＩＤＢ３７０とリンク３６２経由で通信する。 ＳＳＰとＳＣＰとの間をトランスミットされるメッセージは、トランザクショ ン・ケーパビリティーズ・アプリケーションズ・プロトコル(Transaction Capab ilities Applications Protocol、ＴＣＡＰ)に従ってフォーマットされる。ＴＣ ＡＰは、さまざまなクエリおよびレスポンス・メッセージに対する標準化された フォーマットを提供する。各クエリもしくはレスポンス・メッセージは、その特 定のコールに関連する情報の複数の項目(piece)を含むデータ・フィールドを含 む。イニシャルＴＣＡＰクエリ・メッセージのレスポンス・フォーマットはプラ イマリ・キャリアＩＤコード（ＣＩＣ）、代替(alternate)ＣＩＣ、ルーティン グ番号、および、宛先番号などのルーティング情報を含んでもよい。 ＴＣＡＰメッセージ・プロトコルを利用するクエリをトリガするためには、Ｓ ＳＰは、あるコールされた番号をＡＩＮタイプのコールとして認識するようプロ グラムされていなければならない。本発明にしたがって、図３におけるＳＳＰ ３０５は、好ましくは５００番をＡＩＮタイプのコールとして認識するようプロ グラムされている。このようなダイアルされた５００番に対するレスポンスにお いて（これによってコール宛先タイプ・トリガ、若しくは、３／６／１０桁(dig it)トリガとして知られるものが起きる）、電話局ＳＳＰ３０５はＳＣＰ３５０ とＳＴＰ３３０および３４０経由で通信するようになる。この通信は、ＳＣＰ３ ５０およびＳＳＰ３０５へ送信されたクエリの形式をとるが、これはコール処理 をサスペンドさせるためである。ＴＣＡＰフォーマット・クエリは、ダイアルす る番号および５００番を含む。 このクエリという基礎の上で、ＳＣＰ３５０の上にあるＭＳＡＰは、５００番 クエリに応答するための適切なＣＰＲをイニシエートする。そのＣＰＲに含まれ るものにGetData リクエストがあるが、これは、好ましくは関連特許出願におい て開示されている通り、ＳＣＰ内のＭＳＡＰ内のGetData インターフェース(Get Data Interface：ＧＤＩ)よって処理される。ＧＤＩを通じてダイアルされた５ ００番に関連する情報に対するリクエストがＬＩＤＢ３７０へ送信される。 サービス・プロバイダおよびルーティング情報のためにＬＩＤＢへアクセスす ることの利点は、ＬＩＤＢは新しい情報に更新することが簡単に容易にできるこ とにあるが、これはローカルにＳＣＰ上にストアされたデータと対照的であり、 および、これらの更新を提供するためにＬＩＤＢに対する比較的広いアクセスが 得られることも利点である。ある５００番に対するサービス・プロバイダ情報は 、個々のＳＣＰを更新しなくとも変更することができる。したがって、サービス ・プロバイダ識別およびルーティング情報は、ＳＣＰのネットワークから削除さ れ、ネットワーク内でセントラル化されるが、これによってユニフォームな、独 立したネットワークの操作ができるようになる。 ＬＩＤＢ３７０から取り出された(retrieve)されたデータは、とりわけ、ダイ アルされた５００番に対応付けられたサービス・プロバイダの識別、グローバル ・タイトル・トランスレーション(Global Title Translation:GTT)、ＨＬＲ３６ ０のアドレス、もしくは、その加入者のルーティング番号を含んでもよい。 受信されたデータに基いて、ＳＣＰはその後に、ＴＣＡＰレスポンス・メッセ ージを作成してもよい。ＴＣＡＰレスポンス・メッセージは、たとえば、ダイア ルされた５００番に対応付けられたルーティング番号を含んでもよい。メッセー ジは、発信元ＳＳＰ３０５へ、ＳＴＰ３４０および３３０を通じて戻すように送 信される。ＳＳＰ３０５は、このルーティング・データを使用してコールを適切 な宛先ＳＳＰおよび対応付けられた加入者へルートするが、ここでは当業界で公 知の技術を用いる。ダイアルされた５００番は、コール・コンテキストの中に保 持しておくこともできるが、これによって、サービス・プロバイダのネットワー ク内でＳＳＰが終了したときに追加的なＡＩＮトリガ処理ができるようになる。 この追加的なトリガ処理によって、サービス・プロバイダは、サービス・アプリ ケーションを分離する機会が得られるようになる。５００番コールがセルラ加入 者を発信元とする場合は、ＭＳＣはコールを対応付けられたＳＳＰに対してハン ド・オフするが、ＳＳＰは以上で説明したトリガ処理の操作を実行する。 本発明の別の実施形態においては、コールが、図3 に示すＭＳＣ３２５におけ る加入者などのセルラ加入者に対して送ることを意図するものであるときには、 ＳＣＰ３５０は適切なＨＬＲのＩＳ−４１フォーマット・クエリを実行して、加 入者の場所を調べて決定しなければならない。したがって、このようなコールに 対するＬＩＤＢに対するGetData リクエストはＨＬＲのＧＴＴアドレスを返し、 ＧＴＴアドレスにあるＨＬＲクエリは、ＭＳＡＰによって実行される。図４は、 この操作を示す。 図４に示す通り、電話５からの５００番コールは、ＳＳＰ４００からＳＣＰ４ １０へのクエリをトリガする結果となる。ＭＳＡＰ４１５は、ＳＣＰ４１０の上 にあるが、ＬＩＤＢ（図示せず）のリクエストを起動(invoke)し、ダイアルされ た５００番の局番を、たとえばＨＬＲに対するＧＴＴアドレスとマッチするよう なＣＰＲを実装している。データは、ＨＬＲとの通信のために、ＩＳ−４１など の好ましいなサービス・プロバイダ・プロトコルを含んでもよい。 その後ＳＣＰ４１０は、ＨＬＲ４２０へダイアルされた番号を含むロケーショ ン・リクエスト４２５を、指定されたプロトコルの下で送信する。さらに図４で 示す通り、ＨＬＲ４２０は、ダイアルされた５００番に対応付けられたサービ ス・プロバイダに対応するルーティング番号レスポンス４３０を伴うロケーショ ン・リクエストに応答する。今度は、ＳＣＰ４１０がスイッチング・インストラ クション４３５を、ＳＳＰ４００、送信するが、これはＨＬＲ４２０によって識 別されたルーティング番号を含む。最後に、ＳＳＰ４００はコールを、受信され たルーティング番号に従ってサービス・プロバイダ４４０へルートする。 本発明の５００番サービスを実装するＣＰＲの例は、図５の説明から始める。 関連特許および出願は、ＣＰＲの作成、実行、および実装の詳細について説明す る。図５から図１２は、以下に説明する通り、完全なＣＰＲの特定の部分のコン ピュータ画面プリントアウトである。 ノード５００は、説明したＣＰＲのスタートを示し、ＡＩＮトリガの３、６、 もしくは１０桁の数字によって起動される。イニシャル処理デシジョン５０１は 、ダイアルされた５００番が正しい数の桁、望ましくは１０桁を含むか否かを調 べて決定する。ダイアルされた番号が１０桁を含まない場合は、処理は図6 のノ ード５０２および５０３通じて終了されるが、これらの処理は、エラー・コード を割り当て、かつ、エラー対応(error treatment)をそれぞれ実行する。図５を 再度参照すると、正しい桁数が受信された場合には、デシジョン・ノード５０４ は、ポータビリティ機能--- これによって外の情報がＬＩＤＢ内でアクセスでき るようになる--- がアクティベート(activate)されているか否かを調べて決定す る。本発明に従うポータビリティがアクティベートされていない場合は、処理は 図６のデシジョン・ノード５０５０へ進むが、これはＭＳＡＰ内でローカル・ル ックアップ・テーブル内のサービス・プロバイダ情報の場所を調べる。このよう な情報が存在しない場合は、処理はノード５０７および５０８を通じて進むが、 これらはそれぞれエラー・コードを割り当て、および、エラー対応を実行するロ ーカル・サービス・プロバイダ情報が存在する場合は、処理はジャンプ・ノード ５０６へ進み、その後、ノード５２１へ向けられ、以下に説明するように続く。 しかし、ポータビリティが本発明に従ってアクティベートされている場合は、 ＬＩＤＢに対するGetData タイプＴＣＡＰリクエストが図５のノード５０９で実 行される。上記した通り、ＬＩＤＢには少なくともサービス・プロバイダＩＤ、 おそらくはロケーション・レジスタに対するＧＴＴアドレス、および、ＣＩＣル ーティング番号を含むが、すべてダイアルされた５００番に対応付けられたもの である。 エラーがGetData タイプＴＣＡＰリクエストに起因する場合には、デシジョン ・ノード５１０がエラーを検出し、処理は図６のノード５１１を通じてノード５ １２および５１３へ向けられる。ノード５１２および５１３は、それぞれエラー ・コードを割り当て、および、エラー対応を実行する。 GetData タイプＴＣＡＰリクエストが成功した場合は、図５のデシジョン・ノ ード５１４によって示されるが、処理はデシジョン・ノード５１５へ進み、これ はダイアルされた５００番に対応するサービス・プロバイダＩＤがリクエストさ れた情報において識別されているか否かを調べて決定する。サービス・プロバイ ダがまったく識別されていない場合は、処理はデシジョン・ノード５１６へ進み 、ノード５１７および５１８が、それぞれ、エラー・コードを割り当て、および 、エラー対応を実行する。 しかし、正常(normal)な処理の間は、サービス・プロバイダが識別されること になり、処理は「それ以外」ブランチ５１９を通じてデシジョン・ノード５２０ へ流れる。デシジョン・ノード５２０は、「ローカル・オーバーライト」が必要 とされるか否かを調べて決定する。これはサービス・プロバイダ間のビジネス契 約に依存するが、特定のサービス・プロバイダはプライベートなトランク(trunk )グループを使用するよう契約してもよい。ローカル・オーバーライトは、ＬＩ ＤＢ上にストアされ、かつGetData タイプＴＣＡＰリクエストにおいて取り出さ れたされたデータにかかわらず、プライベート・トランク・グループを使用する か否かを指定する。ローカル・オーバーライトが必要とされない場合は、処理は 図６のジャンプ・ノード５２５から直接図７のデシジョン・ノード５５０へジャ ンプするが、これについては以下に説明する。 ローカル・オーバーライトが必要とされる場合は、そのデータは、データ図５ よび図７に示されるノード５２１から５２４を通じて説明される。ノード５２１ は適切なチャージ・パーティＩＤをＡＩＮタイプＴＣＡＰメッセージ・フィール ド内にセットする。ノード５２２は、その後、適切な課金番号(charge number) をＡＩＮタイプＴＣＡＰメッセージの別のフィールドにセットする。ノード５２ ３は、ビリング情報(billing information)をＡＩＮタイプＴＣＡＰメッセージ ・フィールド内に完成する。最後に、ノード５２４は、ローカル・オーバーライ ト情報--- たとえば、ポータビリティ下でのローカル・オーバーライトのための トランク・グループＩＤや、非ポータビリティ・サービス下でのルーティング番 号を提供するトランスレーション・テーブルなど--- が存在するか否かを調べて 決定する。 図７内のデシジョン・ノード５２６は、その後、GetData タイプＴＣＡＰリク エストを通じて取り出すされたデータがローカル・サービス・プロバイダを識別 しているか否かを調べて決定する。ローカル・サービス・プロバイダが示されて いる場合は、処理は「はい」ブランチ５２７を通じてデシジョン・ノード５２８ へ進む。デシジョン・ノード５２８は、ローカル情報がトランスレーション・テ ーブルではなく、トランク・グループを識別しているか否かを調べて決定する。 トランク・グループが識別され、５００番トランスレーションが現在のＩＳＣＰ によって実行できることが示されている場合には、処理は図８に示すノード５２ ９へ進むが、ここではこのタイプのコール・ハンドリングを示す適切なビリング 情報がＡＩＮタイプＴＣＡＰメッセージ内にセットされる。ノード５３０は、ダ イアルされた５００番をＡＩＮタイプＴＣＡＰフィールド内にセットする。ノー ド５３１から５３３は、それぞれ、ＡＩＮタイプＴＣＡＰメッセージの適切なフ ィールド内に、第１、第２、第３の代替トランクＩＤをセットする。最後に、An alyzeRoute AINタイプＴＣＡＰメッセージがノード５３４において送出される。 これはサービス・プロバイダ間のビジネス契約に依存するが、ダイアルされた番 号もしくはリクエストされたデータから得られたトランスレートされた番号は、 指定されたトランク・グループを通じてアウトパルス(outpulse)されてもよい。 ローカル情報がルーティング番号を提供するトランスレーション・テーブルを 構成する場合は、処理はノード５２８からノード５３５へ進み、上記した加入者 トランスレーション・フィーチャ(Subscriber Translation Feature)を開始する 。ノード５３５は、ダイアルされた５００番に対してトランスレートされた ルーティング番号の場所を調べる。その番号トランスレーション・ルックアップ においてエラーが発生しない場合は、処理はノード５３６へ進むが、これは適切 なビリング情報をＡＩＮタイプＴＣＡＰメッセージ内にセットして特定のコーリ ング・プロシージャが起動されたことを示す。ノード５３７はルーティング番号 を適切なＡＩＮタイプ・フィールドに割り当て、ノード５３８はダイアルされた ５００番を同様のＡＩＮタイプＴＣＡＰメッセージ・フィールドに割り当てる。 ノード５３９は、ローカル・アクセス・テレホン・エリア(Local Access Teleph one Area：ＬＡＴＡ)情報をイントラＬＡＴＡコール・チェッキングの目的のた めのコール変数に割り当てる。ＬＡＴＡ情報は、コールが長距離キャリアに対し てハンドオフしなければならないか否か、もしくは、ローカル・システムがコー ルをルートすることになるか否か、を決定する。イントラＬＡＴＡコールはロー カル・コールである。その後、ノード５４０は、図９に示されたＣＰＲを起動し て、ダイアルされた５００番コールがイントラＬＡＴＡコールであるか否か、お よび、ローカル・システムによって処理できるか否かを調べて決定する。 図９を参照すると、エントリ・ノード９００に続いて、ノード９１０はエリア ・コードおよびルーティング番号の局番を以降のテーブル検索用のコール変数に 割り当てる。同様に、ノード９２０はルーティング番号のエリア・コードをコー ル変数に割り当てる。ノード９３０は、ローカル・ルックアップ・テーブルから のＬＡＴＡ情報のルックアップを実行するが、この際に第１のコール変数を使用 する。ＬＡＴＡ情報が決定された場合は、デシジョン・ノード９４０は処理をデ シジョン・ノード９５０ルートするが、これはコールがイントラＬＡＴＡコール か否かを調べて決定する。そうである場合には、処理はノード９６０へ進むが、 これはコール変数ＣＩＣ１に「ＬＥＣ」という値を割り当てるが、これはコール がイントラＬＡＴＡコールであることを示すものである。処理は、その後、マー ジ・ノード９７０の起動処理(invokation)を通じて図７に示すＣＰＲに戻る。 しかし、ノード９５０においてコールが長距離コールであると決定さえた場合 には、処理はジャンプ・ノード９８０から直接マージ・ノード９７０へジャンプ する。したがって、コール変数ＣＩＣ１は値「ＬＥＣ」が割り当てられていない ことに注意してほしい。 ＬＡＴＡ情報がノード９１０において割り当てられたエリア・コードおよび局 番コール変数を使用しても見つからない場合は、処理はノード９４０からノード ９８４へ流れるが、ここではＬＡＴＡ情報の場所をテーブルから調べ、この際に ノード９２０でセットされたエリア・コード・コール変数を使用する。ＬＡＴＡ 情報が見つかった場合は、デシジョン・ノード９８８は処理をジャンプ・ノード ９９２へ向けるが、こちらはといえば、処理を上記したノード９５０へ向ける。 ＬＡＴＡ情報が見つからない場合は、デシジョン・ノード９８８は処理をジャン プ・ノード９９６を通じて直接マージ・ノード９７０へ向ける。 もう一度図８を参照すると、処理はノード５４１へ戻るが、ここではコール変 数ＣＩＣ１が値「ＬＥＣ」に割り当てられているか否かを調べて決定する。そう である場合は、処理はノード５４２を通じてノード５４３へ進み、ここでは「Ｌ ＥＣ」をＡＩＮタイプＴＣＡＰメッセージ・フィールドに割り当ててコールがＳ ＳＰによってローカル・コールとして処理されるべきであることを示す。その後 、ノード５５４はコールをルートするためにAnalyzeRouteメッセージをＳＳＰへ 送出する。コール変数ＣＩＣ１が値「ＬＥＣ」に割り当てられていない場合は、 処理はノード５４５を通じてノード５４６へ流れるが、ここでは処理を図１０の ＣＰＲにトランスファする。 図１０のＣＰＲはＣＩＣコードをＡＩＮタイプＴＣＡＰプライマリ、オルタネ イト、および、第２オルタネイト・キャリア・フィールドにセットする。ノード １０００を通じてＣＰＲに入った後は、処理はノード１０１０へ進みここではプ ライマリ・キャリア情報をＣＩＣ１でセットする。ノード１０２０はＣＩＣ２コ ードが正しいフォーマットであるか否かを調べて決定する。そうである場合は、 ノード１０３０はオルタネイト・キャリア情報をＣＩＣ１でセットする。今度は ノード１０４０であるが、ここではＣＩＣ３コードが正しいフォーマットである か否かを調べて決定する。正しいフォーマットであることがわかった場合は、ノ ード１０５０は第２オルタネイト・キャリア情報をＣＩＣ１コードでセットし、 AnalyzeRoute AINタイプＴＣＡＰメッセージがノード１０６０を経由して 送出される。ＣＩＣ２もしくはＣＩＣ３コードが正しくないフォーマットの場合 には、ジャンプ・ノード１０７０もしくは１０８０が処理を直接ノード１０６０ へチャンネルする。 図８を再度参照すると、ダイアルされた５００番に対するトランスレートされ たルーティング番号がローカル情報内で提供されるトランスレーション・テーブ ル内にない場合は、処理はノード５３５からノード５４７および５４８に流れ、 これらはそれぞれ適切なエラー・コードをセットしおよびエラー対応を実行する 。 ＳＣＰが上記したローカル処理を実行できない場合は、処理はデシジョン・ノ ード５２６からノード５４９を通じてノード５５０へ流れる。ノード５５０は、 特定のサービス・プロバイダに対する指定されたルーティング番号がすでにセッ トされているか否か調べて決定する。そうである場合は、処理はノード５５１へ 進むがここでは適切なビリング情報がＡＩＮタイプＴＣＡＰフィールドにセット され、コール処理ルートがとられたことを示す。それから処理はジャンプ・ノー ド５５２からノード５３７へ進み、コールは上記したように処理される。 サービス・プロバイダ・ルーティング番号が指定されていない場合は、処理は ノード５５０からノード５５３へ流れるが、ここではＣＩＣコードがセットされ ているか否かを調べて決定する。ＣＩＣコードがセットされている場合は、処理 はノード５５４へ流れるが、ここではビリング情報がＡＩＮタイプＴＣＡＰメッ セージ内にセットされ、コール処理パスがとられたことを示す。ノード５５５は ダイアルされた５００をＡＩＮタイプＴＣＡＰメッセージ・フィールド内にセッ トする。最後に、ノード５５６処理を図１０に示すＣＰＲにトランスファする。 図１０のＣＰＲは上記したように処理を続けるが、究極的にはAnalyzeRoute AIN タイプＴＣＡＰメッセージを送出する。 ＣＩＣコードがセットされていない場合は、処理はノード５５３からノード５ ５７へ流れるが、ここではロケーション・レジスタＧＴＴアドレスが存在するか 否かを調べて決定する。アドレスが検出された場合は、処理はノード５５８へ流 れるがここでは適切なビリング情報がセットされ、処理パスがとられたことを 示す。ノード５５９は、それから、処理を図11に示すＣＰＲにトランスファして アドレスされたロケーション・レジスタへのロケーション・リクエストを実行す る。 ノード１１００のＣＰＲに入った後で、ノード１１０５はＧＴＴアドレスをロ ケーション・リクエスト・メッセージに割り当てる。ノード１１１０はモービル 交換センター（Mobil Switching Center：ＭＳＣ）ＩＤをメッセージに割り当て 、ノード１１１５はあるＩＳＣＰタイプを示す値を割り当てる。最後に、ノード １１２０および１１２５がビリング・タイプおよびビリングＩＤ情報を、それぞ れ、ロケーション・リクエスト・メッセージに割り当てる。ノード１１３０は、 実際にはＩＳ−４１タイプＴＣＡＰメッセージに送出するが、これは例えばロケ ーション・リクエスト・メッセージである。レスポンスを受信すると、処理はサ スペンド状態(suspension)からノード１１３５へレジューム(resume)して、ノー ド１１４０はロケーション・レジスタがロケーション・リクエスト・メッセージ を引き受けている(honor)か否かを調べて決定する。 リクエストが引き受けられていた場合は、処理はノード１１４５を通じてノー ド１１５０へ流れるが、ここではリターンされたルーティング番号が正しい長さ であるか否かを調べて決定する。リターンされたルーティング番号が正しい長さ である場合は、図１２に示されるノード１１５５がルーティング番号を内部コー ル変数に将来の処理のために割り当てる。ノード１１６０は処理を図８に示すＣ ＰＲに戻す。処理は、それから、ジャンプ・ノード５６０からノード５４０へジ ャンプして上記したように続く。 図１２を再度参照すると、ロケーション・レジスタがロケーション・リクエス ト・メッセージを引き受けることができなかった場合、もしくは、リターンされ たルーティング番号が間違った長さである場合には、ノード１１６５からノード １１７５、もしくは、ノード１１８０からノード１１８５がエラー・コードを割 り当てて、エラー対応を実行する。最後に、図８を再度参照すると、ロケーショ ン・レジスタのＧＴＴドレスが存在しない場合は、ノード５６１および５６２が それぞれエラー・コードをセットしおよびエラー対応を実行する。 ここでは、本発明の好ましい実装および方法と考えられるものを上に記して説 明したが、これは当業者によってさまざまな変更がされてもよく、本発明の真の 範囲を逸脱せずにこれらの要素を均等なものに置換することができる。さらに、 特定の要素、テクニック、あるいは実装を本発明が教えるところに適合させるた めに、本発明の中心となる範囲を逸脱せずに、さまざまな変更をおこなってもよ い。したがって、この発明はここで開示した特定の実施形態もしくは方法に限定 されるものではなく、本発明は後に記載する請求の範囲の範囲内にふくまれるす べての実施態様を含むものであることを意図している。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 バラッズ，マーガレット，キャサリン アメリカ合衆国 08807 ニュージャージ ー州 ブリッジウォーター サニー スロ ープ ロード 1903 (72)発明者 カストロヴィンチ，ローラ，レイ，テッド マン アメリカ合衆国 08867 ニュージャージ ー州 ピッツタウン ルーラル ルート ２ ボックス 71イー (72)発明者 セブルカ，キャスリーン，ディケンズ アメリカ合衆国 07882 ニュージャージ ー州 ワシントン キャンドルウッド ド ライブ 16 (72)発明者 チェン，イェア−チェイアン，エリック アメリカ合衆国 08837 ニュージャージ ー州 エディソン ボドナリック ロード 24 (72)発明者 クリスタル，ニール，ノーマン アメリカ合衆国 11210 ニューヨーク州 ブルックリン イースト 21エスティー ストリート 1468 (72)発明者 ゲイロード，ケリー，ジーン アメリカ合衆国 07882 ニュージャージ ー州 ワシントン マクドナルド ストリ ート 67 (72)発明者 ハートレイ，ジョージ，ホワイト アメリカ合衆国 08876 ニュージャージ ー州 サマーヴィル ワイルドフラワー レーン 242

Claims (1)

1. 【特許請求の範囲】 １．データをストアするストレージ・デバイスに接続されたコントロール・プロ セッサ、発信元交換システム、宛先交換システム、グローバル・タイトル・トラ ンスレーション・アドレスにあるロケーション・レジスタ、および、発信元およ び宛先交換システムと通信する複数の電話を含む電話交換ネットワークにおいて 、各電話は対応する電話番号を有し、コールされた電話番号をコールするネット ワークを制御する方法であって、コントロール・プロセッサによって実行される 発信元交換システムからコールされた番号を含む交換クエリを受信するステッ プと、 ストレージ・デバイスへコールされた番号を含むデータ・クエリを送信するス テップと、 ストレージ・デバイスから、少なくともコールされた番号に対応付けられた宛 先交換システムの識別、ロケーション・レジスタのグローバル・タイトル・トラ ンスレーション・アドレス、あるいはルーティング番号を含むデータ・レスポン スを受信するステップと、 発信元交換システムへ、コールされた番号に対応付けられた宛先交換システム の識別もしくはルーティング番号を含む交換レスポンスを送信するステップと を備えることを特徴とする方法。 ２．請求項１の方法において、データ・レスポンスは、ロケーション・レジスタ のグローバル・タイトル・トランスレーション・アドレスであり、 グローバル・タイトル・トランスレーション・アドレスにあるロケーション・ レジスタへロケーション・リクエストを送信し、かつ、ロケーション・レジスタ からルーティング番号を含むロケーション・レスポンスを受信するサブステップ を含むことを特徴とする方法。 ３．請求項１の方法において、コールされた番号は５００番サービス・アクセ ス・コードを含むことを特徴とする方法。 ４．請求項２の方法において、交換クエリおよび交換レスポンスは第１の通信プ ロトコルに従って通信され、データ・クエリおよびデータ・レスポンスは第２の 通信プロトコルに従って通信され、および、ロケーション・リクエストおよびロ ケーション・レスポンスは第３の通信プロトコルに従って通信されることを特徴 とする方法。 ５．請求項４の方法において、コールされた番号は５００番エリア・コードを含 むことを特徴とする方法。 ６．請求項４の方法において、第１の通信プロトコルはＡＩＮタイプＴＣＡＰメ ッセージ・プロトコルであることを特徴とする方法。 ７．データをストアするストレージ・デバイスに接続されるコントロール・プロ セッサ、発信元交換システム、宛先交換システム、グローバル・タイトル・トラ ンスレーション・アドレスにあるロケーション・レジスタ、および、発信元およ び宛先交換システムと通信する複数の電話を含む電話交換ネットワークでおいて 、各電話はエリア・コード、交換、およびローカル番号を有する対応する電話番 号を有し、コールされた電話番号をコールするネットワークを制御する方法であ って、コントロール・プロセッサによって実行される 発信元交換システムからコールされた番号の交換およびローカル番号を含む交 換クエリを受信するステップと、 コールされた番号に対応付けられたロケーション・レジスタを、コールされた 番号をストレージ・デバイス内にストアされたデータと比較することにより識別 するステップと、 コールされた番号に対応付けられたロケーション・レジスタに、コールされた 番号の交換およびローカル番号を含むロケーション・リクエストを送信するステ ップと、 コールされた番号に対応付けられたロケーション・レジスタから、コールされ た番号に対応付けられたロケーション番号を含むルーティング・レスポンスを受 信するステップと、 発信元交換システムへ、コールされた番号に対応付けられたルーティング番号 を含むスイッチング・レスポンスを送信するステップと を備えることを特徴とする方法。 ８．請求項７の方法において、コールされた番号は５００番サービス・アクセス ・コードを含むことを特徴とする方法。 ９．請求項７の方法において、交換クエリおよび交換レスポンスは第１の通信プ ロトコルにしたがって通信され、および、ロケーション・リクエストおよびロケ ーション・レスポンスは第２の通信プロトコルにしたがって通信されることを特 徴とする方法。 １０．請求項９の方法において、コールされた番号は５００番サービス・アクセ ス・コードを含むことを特徴とする方法。 １１．請求項９の方法において、第２の通信プロトコルはＩＳ−４１タイプＴＣ ＡＰ通信プロトコルであることを特徴とする方法。 １２．データをストアするストレージ・デバイスに接続されるコントロール・プ ロセッサ、発信元交換システム、宛先交換システム、グローバル・タイトル・ト ランスレーション・アドレスにあるロケーション・レジスタ、および、発信元お よび宛先交換システムと通信する複数の電話を含む電話交換ネットワークにおい て、各電話は対応する電話番号を有し、コールされた電話番号をコールするネッ トワークを制御するシステムであって、 発信元交換システムから、コールされた番号を含む交換クエリを受信する手段 と、 ストレージ・デバイスへ、コールされた番号を含むデータ・クエリを送信する 手段と、 ストレージ・デバイスから、少なくともコールされた番号に対応付けられた宛 先交換システムの識別、ロケーション・レジスタのグローバル・タイトル・トラ ンスレーション・アドレス、あるいはルーティング番号を含むデータ・レスポン スを受信する手段と、 発信元交換システムへ、コールされた番号に対応付けられた宛先交換システム の識別もしくはルーティング番号を含む交換レスポンスを送信する手段と を備えることを特徴とするシステム。 １３．請求項１２のシステムにおいて、コールされた番号は５００番サービス・ アクセス・コードを含むことを特徴とする方法。