(57)【特許請求の範囲】
【請求項１】
ローカル番号集中データベースを有する通信ネットワークにおいて、被呼電話番号を取り扱わない着信交換機に宛てられた電話呼を処理する電話呼処理方法であって、
前記電話呼をルーティングする交換機内のデータベースにアクセスするステップと、
前記交換機内の前記データベースから与えられたデータに基づいて前記電話呼をルーティングするステップと、
前記着信交換機が前記被呼電話番号を取り扱わないとの検知に応動して、前記電話呼に対する解放メッセージを生成するステップとを含み、前記解放メッセージは、前記解放メッセージを送信する交換機内で前記電話呼の電話番号に対応する回線が見出されないことを指示する原因コードを有するものであり、前記方法はさらに、
前記解放メッセージの受信に応動して、複数の交換機が共有する前記ローカル番号集中データベースから受信された応答を、前記交換機内の前記データベースのデータと比較するステップと、
前記応答と前記データベースのデータとが一致しないときには、前記ローカル番号集中データベースから受信されたデータに基づいて前記電話呼をルーティングし、且つ前記交換機内の前記データベースを前記ローカル番号集中データベースから受信されたデータで更新するステップと、
からなることを特徴とする電話呼処理方法。
【請求項２】
前記方法が更に、
前記通信ネットワークを介した前記着信交換機への前記電話呼のルーティングを選択する番号であるルーティング番号を前記交換機内の前記データベースが与えるステップからなることを特徴とする請求項１の方法。
【請求項３】
前記電話呼に対する解放メッセージを生成するステップが、前記ルーティング番号に対応する着信交換機によって実行されることを特徴とする請求項２の方法。
【請求項４】
前記解放メッセージを生成するステップが、前記電話呼が解放された理由を知らせる原因コードを有する解放メッセージを生成するステップからなることを特徴とする請求項３の方法。
【請求項５】
前記交換機内の前記データベースは、前記通信ネットワークを介した前記着信交換機への前記電話呼のルーティングを選択する番号であるルーティング番号を与えないが、電話ネットワークは、前記電話呼のルーティングについて前記被呼電話番号を用いることを特徴とする請求項１の方法。
【請求項６】
前記方法が、
前記被呼電話番号の局コードに対応する着信交換機が、その着信交換機が前記被呼電話番号を取り扱わないことを定めるステップと、
前記着信交換機が、前記被呼電話番号についてポート済指示子がセットされているかどうかを点検するステップと、
もし前記ポート済指示子がセットされている場合に、前記解放メッセージを送信するステップと、
からなることを特徴とする請求項５の方法。
【請求項７】
通信ネットワークの交換機において、被呼電話番号について正しくないデータを問い合わせ側交換機が有するかどうかを検出する番号データ状態検出方法であって、
企図された着信交換機への着信呼についての、前記被呼電話番号からなるメッセージの受信に応動して、前記企図された着信交換機が前記被呼電話番号を取り扱うかどうかを点検するステップと、
前記企図された着信交換機が前記被呼電話番号を取り扱わないときには、前記被呼電話番号についてポート済指示子がセットされているかどうかを点検するステップと、
前記ポート済指示子がセットされているときには、確認できる原因コードからなる解放メッセージを送信するステップと、
からなることを特徴とする番号データ状態検出方法。
【請求項８】
ローカル番号集中データベースを有する通信ネットワークにおいて、被呼電話番号を取り扱わない着信交換機に宛てられた電話呼を処理する電話呼処理方法であって、
前記電話呼をルーティングする交換機内のデータベースにアクセスするステップと、
前記交換機内の前記データベースから与えられたデータに基づいて前記電話呼をルーティングするステップと、
前記電話呼のルーティングと同時に、前記電話番号を用いて複数の交換機が共有する前記ローカル番号集中データベースに問い合わせるステップと、
前記電話呼についての解放メッセージであってその解放メッセージを送信する交換機内で前記電話呼の電話番号に対応する回線が見出されないことを指示する原因コードを有する解放メッセージの受信に応動して、前記複数の交換機が共有する前記ローカル番号集中データベースから受信された応答を、前記交換機内の前記データベースのデータと比較するステップと、
前記応答と前記データベースのデータとが一致しないときには、前記ローカル番号集中データベースから受信されたデータに基づいて前記電話呼をルーティングし、且つ前記交換機内の前記データベースを前記ローカル番号集中データベースから受信されたデータで更新するステップと、
からなることを特徴とする電話呼処理方法。
【請求項９】
ローカル番号集中データベースを有する通信ネットワークにおいて、被呼電話番号を取り扱わない着信交換機に宛てられた発信交換機からの電話呼を処理する電話呼処理装置であって、
前記装置が、
前記発信交換機内のプロセッサ手段からなり、
前記プロセッサ手段が、
前記交換機のためのローカルデータベースと、
プログラムとからなり、
前記プロセッサ手段は、前記プログラムの制御下で作動して、
前記ローカルデータベースから与えられたたデータに基づいて前記電話呼をルーティングする動作と、
前記電話呼についての解放メッセージであってその解放メッセージを送信する交換機内で前記電話呼の電話番号に対応する回線が見出されないことを指示する原因コードを有する解放メッセージの受信に応動して、前記電話番号を用いて、複数の交換機が共有する前記ローカル番号集中データベースに問い合わせる動作と、
前記ローカル番号集中データベースから受信された応答を、前記交換機内の前記データベースのデータと比較する動作と、
前記応答と前記データベースのデータとが一致しないときには、前記ローカル番号集中データベースから受信されたデータに基づいて前記電話呼をルーティングし、且つ前記交換機内の前記データベースを前記ローカル番号集中データベースから受信されたデータで更新する動作と、
を行うことを特徴とする電話呼処理装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は通信ネットワーク内のデータにアクセスするための方法及び装置に関し、詳しくは電気通信呼の設立に関してのデータへのアクセスに関する。
【０００２】
【従来の技術】
現代の通信ネットワークは、インテリジェントネットワーク、すなわち、ルーティング（経路選択及び選択経路を経由しての送信）についてのデータ又は電気通信呼についてのその他の処理に関するデータを、複数の交換機システム又は交換装置（以下、交換機）が共有するデータベースから引き出すネットワーク、の概念をますます用いるようになっている。このようなインテリジェントネットワークの一例は、米国での８００の３桁で始まる番号への電話呼（８００番コール：被呼者課金呼）を搬送するのに用いられるネットワークである。
【０００３】
呼者に無料のこれらの呼は、被呼番号の位置に直接に関係のない電話番号を用いることが特徴である。これは、米国の普通の電話番号と対照的である。この普通の電話番号とは、最初の３桁の区域コード（市外局番）が、呼がルーティングされる宛先の区域に関する情報を与え、次の３桁が局コードで、通常、その区域内のどの中央局がその呼を受信すべきかに関する情報を与え、最後の４桁番号でその局コード内の或る特定の被呼顧客を識別するような構成からなる電話番号である。
【０００４】
８００番台電話番号、すなわち最初の３桁が８００である電話番号、はこれと異なり、次の３桁がＮＸＸ（Ｎは２から９までの間の数、Ｘは０から９までの間の数）、最後の４桁がＸＸＸＸで、地理的な意味はない。呼者が８００番台番号をダイヤルするような呼（８００番台呼）を電話通信ネットワークが受信すると、ネットワークはデータベースに問い合わせを行う。データベースは、その８００番台番号を従来方式番号に変換する。得られた従来方式番号を用いれば、後に従来の方法で呼を宛先にルーティングすることが可能となる。
【０００５】
単に従来方式番号を用いる代わりに８００番台番号を用いることの利点は、呼者がその呼に課金されないことが即座に保証されることである。これは、商品の発注、航空券又はホテル宿泊の予約、等の業務の勧誘に際しての主たる考慮要件のひとつである。
【０００６】
ルーティング情報を定めるのにデータベースを用いる手法はまた、サービス提供会社の番号の可ポート性（移植）、すなわち、たとえ顧客の呼が、異なる交換機を用いる異なる電話会社によって取り扱われる場合でも、その顧客が１つの電話番号を持ち続けられる能力、に関して用いられている。この用途では、異なる電話会社に属する異なる交換機が或る電話番号を取り扱う事例においてその電話番号が属する局コードの局に呼をルーティングするのに先立ってデータベースがアクセスされる。
【０００７】
従来技術の問題点は、呼のルーティングに必要な情報を得るためにデータベースに問い合わせを行うアクセス時間に現在約３００ｍｓを要することである。このアクセス時間は電話呼の呼セットアップ時間に直接追加され、呼の完了が遅くなる。
【０００８】
呼セットアップ時間については、多くの区域において有力且つ支配的な方式になってきている共通線信号方式を用いることによって、データベース問い合わせを要しない通常の状態で、呼セットアップ時間を１秒の数分の１に削減することができている。これは、８００番台呼（発呼者無料の呼）のような呼の場合に特に重要である。その理由は、８００番台呼にはデータベース問い合わせが必要であり、追加問い合わせ時間が呼セットアップ時間に追加されることになるためである。
【０００９】
この問題は、本出願の発明者による米国特許出願番号０８／５３４５３４（１９９５年９月２７日出願）に記載の手法によって軽減される。同米国出願における開示内容は本出願の推奨実施例の理解に必要な背景となるので、同開示内容を本明細書内に再現することする。本明細書の図１から図１８までの図面は同米国出願の発明に関するものである。
【００１０】
【発明が解決しようとする課題】
上記の米国出願の実現、又は上記の問題の他の解法の実現、に際して生じる問題点は、呼のルーティングに必要なデータをローカル域内又は市内データベース（以下、ローカルデータベース）が提供するように見えるがその呼が宛先にルーティングされる際に、目的のディレクトリ番号（電話番号）の記録が着信局にない場合に、その呼を満足に処理する方法がないことである。
【００１１】
【課題を解決するための手段】
上記米国出願によれば、或る交換機内に含まれるローカルデータベースが、特定の電話番号への呼を設立するために、遠隔のデータベース問い合わせが必要かどうかについての情報を提供する。本発明の一実施例によれば、データベース問い合わせが必要かどうかを指示するデータは、問い合わせ側交換機が直接又は間接に取り扱う被呼ディレクトリ番号あたり１ビットを用いてビットマップ内に維持される。
【００１２】
上記米国出願によれば、もし遠隔のデータ問い合わせが必要ないと定められた場合、その判断は次の２つの要因のうちの１つに起因する。これらの要因は、問い合わせの応答がデフォルト応答であること、又は問い合わせの応答が問い合わせ側交換機のメモリに格納されていること、という要因である。
【００１３】
デフォルト応答の一例は、着信呼を取り扱う電話会社の身元（アイデンティティ）を見出すためにデータベース問い合わせが行われるという状況下で、その電話会社の交換機を特定する応答である。
【００１４】
本発明の一態様によれば、デフォルト属性と、問い合わせ側交換機に保持されているデータ内のエントリとの間の区別は、第２のビットマップで与えられる。第２のビットマップを用いることによって、問い合わせ側交換機に保持されているデータのサーチが不要となるので有利である。
【００１５】
上記米国出願の一実施例によれば、区域コード（ＮＰＡ）に局コード（ＮＮＸ）を加えた番号では被呼番号をどの交換機が取り扱うかを特定できないような番号可ポート性環境において呼をルーティングするためにデータベースが用いられる。このような状況においては、ローカル域内又はローカルサービス提供者域内（以下、ローカル）の呼処理にはローカル汎用データベースが用いられ、異なる地元区域間の呼（長距離呼又は市外呼）の処理には全国データベースが用いられる。
【００１６】
このような場合、特に初めに、大部分の電話番号は、主たるローカル交換電話会社（米国のＡＴ＆Ｔ社がそのローカル交換電話会社を分離したときに形成された地方持株会社の１つのような）による取り扱いが継続されることになり、したがって、主たる電話会社が取り扱う被呼電話番号を特定する能力によって、既に、大部分の呼についての呼セットアップ時間が削減されることになる。
【００１７】
残りの呼の、大部分ではないにしてもそれらの呼の多くについての呼セットアップ時間は、デフォルト属性以外の属性を必要とする最も頻繁に呼ばれる電話番号についてのデータ、を格納するメモリを適度の大きさにする（あまり大きくしない）ことによって削減される。
【００１８】
上記米国出願によれば、集中データベースが、格納されるデータの高信頼性格納場所として存続する。定期的にビットマップ内のデータがクリア（消去）され、最も頻繁に呼ばれる番号についてのデータもクリアされるので、これらのデータは呼が発呼される際に集中データベースにアクセスすることによって再度設定される。これにより個々の交換機のメモリが自動的に更新されることになる。
【００１９】
図１９〜図２３に関して述べる本発明によれば、上記の米国出願の実現又は上記の問題の他の解法の実現に際して残る問題点は、次のような構成によって解決される。
【００２０】
その構成とは、もし或る交換機への呼の完了が企図され且つその交換機が着信ディレクトリ番号の記録を有しない場合に、その交換機が、その着信交換機に向けてのルーティングを制御した交換機（制御側交換機）に適切な信号メッセージを返し、それからその制御した交換機が、ローカルデータベースを更新するために、汎用データベースに問い合わせを行い、その呼の完了を再度企図する、という構成である。
【００２１】
この構成は、当初に呼を正しくない着信交換機にルーティングした交換機のローカルデータベースを自動的に更新させ、その呼を完了させるという利点を有する。不適切に取り扱われる呼の数についての目標値を電話会社が非常に低く設定しているため、呼の保存は重要な利点である。更に、ローカルデータベースを自動化することによって、例年のの特別検査の必要性を回避できる。
【００２２】
【発明の実施の形態】
図１に、交換機３を示す。交換機３はメモリ１７を有するプロセッサ１０からなり、呼の処理（例えば、受信された電話番号によって特定される、呼の着信を取り扱う交換機を特定するような処理）に要する専門データをその交換機自体のメモリ１７が内蔵していない場合に汎用データベース４にアクセスする。具体的な番号可ポート性の例についての呼処理の詳細に関しては後に他の図面を参照して説明する。
【００２３】
図面２に、本発明者による上記米国出願発明（以下、前発明）の実施に関連するプロセッサのメモリ内容を示す。プロセッサ１０は、プログラム１８から制御されて後に示す流れ図の動作を行う。このメモリは、各々が被呼番号あたり１ビットを有するようなビットマップ１（遠隔データベースビットマップ）及び２（デフォルトビットマップ）からなる。被呼番号に向けての呼のルーティングは交換機３が定める。
【００２４】
加えて、メモリ１７は、対応する指示子（インディケータ）２４、・・・ ２５、２６をそれぞれ有する複数のエントリ２１、・・・ ２２、２３からなるテーブル２０を有する。ビットマップについてのポインタ３０がエントリのうちの１個とそれに対応する指示子とをポイントし、別のエントリをテーブルに挿入すべきときに既存のエントリ１個を除去するのを助けるために用いられる。
【００２５】
この動作は、もし汎用データベース４がアクセスされ、その結果がデフォルト属性以外である場合に生じる。このような状況において、比較的頻繁に使用されていなかったテーブル２０内のエントリ１個がクリアすなわち除去され、このエントリに対応するビットマップ指示子が、「この着信ディレクトリ番号についてのデータがこの交換機にはもはや格納されていない」ことを指示するように変更される。それから、新たに得られたエントリが、エントリの除去によって空いたテーブル２０内の箇所に挿入、配置される。
【００２６】
周知のデータ構造であるＡＶＬツリー（木）構造を用いることによって、テーブル２０内のどの箇所にどのエントリを配置することも、又このようなエントリに比較的迅速にアクセスすることも可能となる（ＡＶＬツリー構造は、文献（例えばD.F.Stubbs et al.;Data Structures with Abstruct Data Types and Pascal, Brooks Cole Publishing Company, 1985, pages 225-234）に述べられている）。新エントリ挿入の詳細については図４を参照して下に述べる。
【００２７】
図３にテーブル２０の２つの状態を示す。この場合、交換機３が呼について少なくとも２個の局コード、すなわち２２２及び２７５、に向けてのルーティングを行うものと仮定する。図３の上半部分において、エントリ２１、２２、及び２３は、電話番号２２２−２３３３が電話会社１によって取り扱われること、電話番号２７５−２４５７が電話会社２によって取り扱われること、及び電話番号２７５−１９３０が電話会社１によって取り扱われることをそれぞれ指示している。
【００２８】
この場合、交換機３が取り扱う全ての電話番号が同じ区域コード（市外局番）に属するものと仮定する。明らかに、もし交換機３が市外交換機の場合には全１０桁番号を要することになる。それから図３の下半部分は、エントリ２３がクリアされ、電話会社２によって取り扱われる電話番号２２２−１２３３についてのデータがエントリ２３にあったデータと置き換えられたことを示す。
【００２９】
図４に、テーブル２０にエントリを挿入するプロセスを示す。ポインタ３０は、前にテーブル２０にエントリが最後に挿入された箇所の次の箇所をポイントしている。テーブル２０へのエントリ挿入要求が受信される（動作ブロック３１）。点検ブロック３２において、「指示子ポイント済」マークがあるかどうかが定められる。もし付けられている場合、その子がクリアされ（動作ブロック３３）、ポインタが進められる（動作ブロック３４）。
【００３０】
もし点検ブロック３２の結果として、「指示子ポイント済」マークがない場合には、現エントリがクリアされ、そのエントリについてのビットマップが、現エントリに対応する番号についてのデータはデータベースにアクセスして得る必要がある旨を指示するように更新される。そして、点検ブロック３２の最後の反復点検において見出されたマークされていない指示子に対応する箇所に、新エントリが挿入される。
【００３１】
ポインタが進められ（動作ブロック３６）、どの特定のエントリでも迅速に見いだせるようにテーブル内でエントリをリンクするためのＡＶＬデータが、更新される（動作ブロック３７）。ビットマップ１及び２は、図６及び図７に関連して後に述べるように更新する必要がある。
【００３２】
図５に、単にテーブル２０内の全てのエントリをクリアし且つテーブル内の全ての指示子をクリアすることによって、テーブル２０の内容が定期的にリフレッシュされることを示す。テーブル内のエントリのクリア処理（クリア）は、ＡＶＬツリーデータをクリアすることによって、且つ交換機３からルーティングされた電話番号のどれについてもローカルデータベースには今、何もデータがないことを指示するようにビットマップ１及び２を更新することによって行われる。
【００３３】
「定期的に」とは、例えば毎夜、深夜０時又は午前２時を意味し、その後はどの電話番号でも最初には遠隔の汎用データベース４（以下、遠隔データベース、とも称する）へのアクセスを要する。
【００３４】
そして、呼が到来するにつれて、データが、或る特定の電話番号がデフォルト値を有すること、すなわちこの場合、その番号がその主たる電話会社によって取り扱われること、を指示し、又はテーブル２０が或る特定の電話番号についてのデータを有することを指示するように、テーブル２０のビットマップ１及び２に配置される。
【００３５】
テーブル２０がクリアされると同時に、両方のビットマップがクリアされる。これは、交換機３からルーティングされる各番号に対する次の呼について、遠隔データベースに問い合わせが行われることを意味する。テーブル２０からデータをクリアするには、ＡＶＬツリーデータをクリアして、サーチでエントリが見出されないようにする。ＡＶＬツリーデータのクリア処理は、データをテーブル２０に入れる次の企図が成功するような仕方で行われる。
【００３６】
図６及び図７に、交換機又は遠隔データベース内のデータにアクセスする別の手順を示す。図６は、交換機内にビットマップが１個（ビットマップ１）だけ格納されている場合を示す。この場合、ビットは求めるデータがその交換機に格納されている（ビット＝１）か、又は遠隔データベースへのアクセスが必要かを指示する。点検ブロック５０において、データが求められている電話番号に対応するビットマップの状態を点検する。
【００３７】
もしこのビットが１の場合、求めるデータはその交換機のメモリ内にある。そして点検ブロック５１において、そのデータについて交換機メモリのサーチが行われる。もしデータが見出されない場合、デフォルト属性が用いられる（動作ブロック５２）。
【００３８】
もしデータが見出された場合には、交換機メモリから与えられたデータが用いられ、そのデータに対するテーブル２０内の指示子がマーク付けされる（動作ブロック５３）。指示子をマーク付けすることによって、テーブルのこのエントリが、直ちに図４の手順において交換機メモリから削除される候補ではないことが保証される。
【００３９】
点検ブロック５０での点検の結果、ビットが０である場合には、遠隔データベースがアクセスされ（動作ブロック５４）、遠隔データベースによって記述されるデータが用いられる（動作ブロック５５）。問い合わせが行われた電話番号についてのビットマップが、この番号にデフォルト属性が適用される旨、又は適切なデータが交換機メモリ内に格納されている旨を指示できるように、マーク付けされる（動作ブロック５６）。
【００４０】
点検ブロック５７において、見出されたデータがデフォルト属性かどうかが定められる。もしそうである場合、これ以上の処理動作は不要である。もしそうでない場合には、遠隔データベースにおいて見出されたデータが交換機メモリ内に格納される（動作ブロック５８）。そして、このエントリが直ちに除去候補ではないことを保証するために、このエントリについての指示子が１の値をマーク付けされる。
【００４１】
図７に、２個のビットマップが用いられる場合を示す。２個のビットマップを用いることの利点は、データ要求がなされた電話番号に連関するデータがデフォルト属性か（その場合データエントリは格納されていない）どうかを定めるためにテーブル２０又は同等物をサーチするのに要する時間を節減できることである。又、不利な点は、第２のビットマップの格納にかかるコストである。
【００４２】
データアクセスが必要な場合、デフォルト属性ビットマップ（ビットマップ２）が点検される（動作ブロック６０）。もしこの点検の結果がビット＝１である場合、デフォルト属性が用いられる（動作ブロック６１）。図７の構成の利点は、最も頻繁に用いられるデータ例、すなわちデフォルト属性、を非常に迅速に見出すことができることである。
【００４３】
もし点検ブロック６０の点検の結果、データが求められている電話番号に対応するビットが０である場合には、図２のビットマップ１に対応する第２のビットマップが点検され（点検ブロック６２）、求められるデータを交換機メモリ内に見出すことになるか、又は遠隔データベース内に見出すことになるかが定められる。もしビット値が０の場合、遠隔データベースがアクセスされ（動作ブロック６３）、遠隔データベースによって記述されるデータが用いられる（動作ブロック６４）。
【００４４】
それから点検ブロック６５において、遠隔データベースから見出されたデータがデフォルト属性かどうかが定められる。もしそうではない場合、データは交換機メモリに入れられ、データエントリに対する指示子が１に設定される（動作ブロック６６）。
【００４５】
もし遠隔データベースが返したデータがデフォルト属性であり、遠隔データベースがデフォルト属性を返す代わりに単にデータが見出されない旨のメッセージを返し且つそのメッセージをデフォルト属性を表すものとして交換機３が解釈するようなことが可能である場合には、この電話番号についてデフォルト属性ビットマップ（ビットマップ２）がマーク付けされ（動作ブロック６７）、そのデフォルト属性が用いられる。
【００４６】
もし点検ブロック６２の点検が、ビットが１であること、すなわちデータが交換機メモリにおいて見出されるべきことを示す場合には、このデータを見出すために交換機メモリがアクセスされる（動作ブロック６８）。交換機メモリによって与えられたデータが用いられ、このエントリが直ちに除去候補ではないことを保証するために、このエントリについての指示子がマーク付けされる（動作ブロック６９）。
【００４７】
１個のデフォルト属性ビットマップの代わりに共通属性ビットマップを用いる第３の可能性が考えられ、この場合にはデフォルト属性ビットマップだけが用いられ、テーブル２０に格納されているようなデータは交換機内には保持されていない。この場合、遠隔データベースによってデフォルト属性がまだ確認されていない全ての電話番号について、交換機が遠隔データベースにアクセスする。
【００４８】
代わりに又は図７に関して述べた事例について、いくつかの共通属性（頻繁に用いられる属性）に対応するいくつかのビットマップを用いることも可能である（これら共通属性は、この場合、求められるデータのいくつかの最共通事例ということになる）。番号可ポート性への適用例においては、これは、主たる電話会社及びいくつかの最も頻繁に用いられる代わりの電話会社についてのことになる。
【００４９】
図８は、デフォルト属性ビットマップだけを用いる場合の流れ図である。デフォルト属性ビットマップが、データの求められている電話番号を用いてアクセスされ、点検される（点検ブロック７０）。もし点検ブロック７０での点検の結果、ビットマップに値１が見出された場合、デフォルト属性が用いられる（動作ブロック７１）。もし点検ブロック７０での点検の結果、ビットマップの値が０であった場合には、データベースがアクセスされる（動作ブロック７２）。
【００５０】
点検ブロック７３においてデータベースへのアクセス結果が点検され、それがデフォルト属性かどうかが定められる。もしデフォルト属性でない場合、データベースから得られたデータが用いられる（動作ブロック７４）。もしデフォルト属性である場合には、デフォルト属性ビットマップがマップ付けされ（動作ブロック７５）、そのデフォルト属性が用いられる（動作ブロック７６）。
【００５１】
図９においては、単一のデフォルト属性ビットマップではなく、複数の共通属性ビットマップがある場合について考える。点検ブロック８０において、共通属性ビットマップの各々がてされ、これらのビットマップのどれかにおいて、電話番号に対応するビットが１かどうかが定められる。もし１である場合、１であることが見出されたビットマップの共通属性が用いられる（動作ブロック８１）。もし全てが値０である場合には、データベースがアクセスされる（動作ブロック８２）。
【００５２】
それから点検ブロック８３において、データベースにおいて見出された結果が共通属性のうちの１つであるかどうかが定められる。もしそうでない場合、データベースから得られたデータが用いられる（動作ブロック８４）。もし結果が共通属性のうちの１つである場合には、見出された共通属性に対応する共通属性ビットマップがマーク付けされ（動作ブロック８５）、見出された共通属性がデータとして用いられる（動作ブロック８６）。
【００５３】
図８及び図９において述べた両方の事例について、データベースの完全性を維持するためには、デフォルト属性ビットマップ（図８）又は共通属性ビットマップの全て（図９）をクリアして、呼がなされる際にこれらのビットマップにデータを再入力しさえすればよい。
【００５４】
図１０〜図１８は、図１〜図９に関して述べた本発明者による前発明の原理をその推奨実施例として適用できるような具体的なシステム構成を示す。本発明の原理が、図１２、図１３、図１４、及び図１５の動作ブロック３０９、４０１、５０５、および６０３の実施に用いられる。
【００５５】
或る電話番号について代替電話会社が指定されているときには、非常に頻繁に用いられる推奨及び代替電話会社の組み合わせに対して或るデフォルト属性を留保する必要があると定められた場合でなければ、テーブル２０又は遠隔データベース内のエントリが必要であり、多数のデフォルト属性ビットマップが用いられる。
【００５６】
図１０は、電話顧客、ローカルサービス提供会社（すなわち、ローカル交換電話会社）、及び市外（遠距離）電話会社間の関係を示すブロック図である。個別顧客１０１〜１０５が電話トラヒックを発信側で開始し又は着信側で終端する。これらの顧客のうちのの或る者（例えば顧客１０１及び１０４）は、特に信頼性あるサービスを得るために２つの電話会社に接続されている。ローカル交換電話会社１０６〜１１０（簡単に、ローカル電話会社）は、顧客と、市外交換電話会社１１１〜１１３（簡単に、市外電話会社）とに接続されている。
【００５７】
各ローカル電話会社は、１個以上の交換機１１７と、ローカル汎用データベース（ＬＵＤＢ）１１８（又は簡単に、ローカルデータベース）と、課金記録システムとを有する。代わりに、１個のローカルデータベースをいくつかの又は全てのローカル電話会社で共有してもよい。交換機は従来の方法で電話接続を設立するためのもので、図１０に示すリンクで相互接続されている。ローカルデータベース１１８は、そのローカル電話会社が取り扱う区域の電話番号についてのデータだけ格納していればよい。
【００５８】
或る特定の区域を取り扱うローカル電話会社は各々、その区域の全ての電話番号に関するデータをそのデータベースに格納している。したがって、広い意味で、各データベースは同じデータを内蔵する。或る特定の区域及び或る特定の電話会社のためのデータベースが、その区域を取り扱うその電話会社の各交換機からデータリンクを通してアクセスされる。
【００５９】
図１０では各ローカル電話会社について別個のデータベースを配置しているが、これらのデータベースは、複数のこれらローカル電話会社間で共有するようにもできる。このことは、データベースがデータリンクを用いてアクセスされるので、特に当然のことといえる。
【００６０】
ローカル電話会社は、１個以上の交換機１１４をそれぞれ有する市外電話会社１１１、１１２、...１１３ に接続され、全国汎用データベース（ＮＵＤＢ）１１５（又は簡単に、全国データベース）と課金記録システム１１６とにアクセスする。全国データベースはもちろんローカルデータベースよりもはるかに大きいが、ローカルデータベースに関して前に述べたことは、全国データベースにも当てはまる。
【００６１】
この全国データベースは、データベースのデータを使用する交換機からデータリンクを介してアクセスされるので、全国データベースの形態としては、集中型又は分散型のどちらも可能であり、複数の市外電話会社間で共有することもできる。
【００６２】
図１１は、ローカルデータベース及び全国データベースの更新のための構成を示す。サービス集中管理システム２０１が更新メッセージを個別ローカル電話会社・ローカル番号ポートサービス管理システム２０２に送信し、個別ローカル電話会社・ローカル番号ポートサービス管理システム２０２がこれら更新メッセージをローカル電話会社２０４の各々が有するローカルデータベース２０３に送信する。
【００６３】
同様に、サービス集中管理システム２０１が更新メッセージを市外電話会社・ローカル番号ポートサービス管理システム２１０に送信しこれら更新メッセージは各々、市外電話会社２１２の全国データベース２１１を更新するために用いられる。
【００６４】
ローカルアクセス提供会社（ローカル電話会社）は更新情報をサービス集中管理システム２０１に提供する必要がある。顧客がサービス提供会社（ローカル電話会社）を変更する場合についての更新については、顧客の新しい（変更後の）ローカル電話会社が担当する。顧客が電話会社を変更する際は、データベースが更新されるまでの短期（数日）間、当初（変更前）のローカル電話会社が呼を回送する必要がある。
【００６５】
図１２は、この種の構成についてのルーティング手順の流れ図である。ローカル電話会社の交換機（又は簡単に、ローカル交換機）が呼を受信する（動作ブロック３０１）。ローカル交換機が、この呼がローカル呼、市外呼のいずれであるかについて解釈する（点検ブロック３０３）。
【００６６】
もし地理的番号（位置）の可ポート性がこの呼の受信区域において実現される場合、点検ブロック３０３の点検を成功させるために、ローカルデータベースが、推奨される着信ローカル電話会社、及び着信側顧客を取り扱う交換機を返し、これを、この呼がローカル呼か市外呼かを定めるための発信交換機の特定に関連して用いることができる。
【００６７】
又もしローカルデータベースが着信側顧客についてのデータを内蔵しないことが認識された場合、呼は市外呼である。このことは、例えば、着信側顧客の区域コードから定めることができるし、又もし地理的番号（位置）ポートが被呼番号の局コードからは実現されなかった場合にもそのように定めることができる。
【００６８】
もし点検ブロック３０３の結果、これが市外呼であると定められた場合、呼は規定された市外電話会社へ、又はもし顧客が適切なコード番号をダイヤルして市外電話会社を指定する場合にはその、ダイヤル指定された市外電話会社にルーティングされる（動作ブロック３０５）。その市外電話会社が、発信側顧客の自動番号識別ＩＤ（ＡＮＩ）とダイヤルされた番号（又は簡単に、ダイヤル番号）とを受信する（動作ブロック３０７）。
【００６９】
それから市外電話会社が全国データベースにアクセスして、着信電話会社（及び、もしあれば代替会社）及び着信交換機（及び、もし指定があればその指定代替交換機）を定める（動作ブロック３０９）。そして、市外電話会社が呼を、推奨着信電話会社のために作動する出口（着信）交換機にルーティングし、着信電話会社ＩＤ及び着信端局ＩＤを送信する（動作ブロック３１１）。
【００７０】
点検ブロック３１３において、推奨着信電話会社が利用可能かどうかが定められる。もし利用可能な場合、呼はその推奨着信電話会社を経て被呼顧客に着信して完了となる（動作ブロック３１５）。もし点検ブロック３１３の結果が否定的でその推奨電話会社が利用可能でない場合には、点検ブロック３１７において、代替電話会社が指定されているかどうかが定められる。
【００７１】
もし代替電話会社が指定されている場合、点検ブロック３１９において、その代替電話会社が利用可能かどうかが定められる。もし利用可能な場合、呼はその代替電話会社にルーティングされ被呼顧客に着信して完了となる（動作ブロック３２１）。もし利用可能でない場合には、呼は阻止され、阻止された呼に対する処理が行われる（動作ブロック３２３）。同様に、もし点検ブロック３１７の結果が否定的で代替電話会社が指定されていなかった場合にも、呼は阻止される（動作ブロック３２３）。
【００７２】
もし呼がローカル呼か市外呼かを定める点検ブロック３０３の結果、呼がローカル呼の場合には、図１３の動作ブロック４０１に進む。動作ブロック４０１において、ローカル電話会社の交換機が、ローカルデータベースに問い合わせを行い、推奨電話会社及び交換機（並びに、もし指定がある場合には代替電話会社及び交換機）を定める。点検ブロック４０３において、推奨電話会社が利用可能かどうかが定められる。
【００７３】
もし推奨電話会社が利用可能な場合、呼はその推奨着信電話会社にルーティングされ、推奨着信電話会社ＩＤ及び着信端局ＩＤが着信電話会社に送信される（動作ブロック４０５）。もしその推奨電話会社が利用可能でない場合には、点検ブロック４０７において、代替電話会社が指定されているかどうかが定められる。もし代替電話会社が指定されている場合、点検ブロック４０９において、その代替電話会社が利用可能かどうかが定められる。
【００７４】
もし利用可能な場合、呼はその代替電話会社にルーティングされ被呼顧客に着信して完了となる（動作ブロック４１１）。もし点検ブロック４０９の結果が否定的でその推奨電話会社が利用可能でない場合には、呼は阻止され、阻止された呼に対する処理が行われる（動作ブロック４１３）。
【００７５】
図１４は、市外呼の課金の際の動作を示す流れ図である。市外電話会社が、発信側顧客の自動番号識別ＩＤ（簡単に、自動番号ＩＤ）とダイヤル番号とを受信する（動作ブロック５０１）。市外電話会社が、入トランク（入り接続中継線装置）ＩＤを発信電話会社ＩＤに変換して、発信電話会社を定める（動作ブロック５０３）。代わりに、発信電話会社からの信号情報によって発信電話会社を特定することもできる。
【００７６】
それから市外電話会社が、全国データベースに問い合わせを行い、被呼番号に対する着信電話会社及び交換機を特定する（動作ブロック５０５）。そして市外電話会社が、自動番号ＩＤ、被呼番号、発信及び着信ローカル電話会社ＩＤ、発信及び着信交換機ＩＤ、市外電話会社ＩＤ（いくつかの電話会社に対する課金記録が１個のプロセッサによって処理される場合）、並びにその呼についての経過時間からなる呼詳細記録を作成する（動作ブロック５０７）。
【００７７】
図１５は、ローカル呼についての課金の手順である。ローカル電話会社が、発信側顧客の自動番号ＩＤ（ＡＮＩ）とダイヤル番号とを受信する（動作ブロック６０１）。それからローカル電話会社が、ローカルデータベースに問い合わせを行い、ダイヤル番号に基づき、着信電話会社及び交換機を特定する（動作ブロック６０３）。そしてローカル電話会社が、自動番号ＩＤ、ダイヤル番号、着信ローカル電話会社ＩＤ、及び着信交換機ＩＤからなる呼詳細記録を作成する（動作ブロック６０５）。
【００７８】
代替着信電話会社が用いられる場合には、呼詳細記録の項目中の推奨電話会社及び交換機の代わりに、代替電話会社及び交換機が入れられる。
【００７９】
図１６は、市外呼において本発明の構成の柔軟性を示す事例を説明するブロック図である。顧客７０１が異なるローカル電話会社３社、すなわちローカル交換電話会社７１１、競合アクセス提供会社７１３、及びケーブルＴＶ提供会社７１５、へのアクセスを有する。
【００８０】
市外呼が選択された市外電話会社の入口交換機７３１（発信側）に到来すると、呼は市外電話会社の出口交換機７３３（着信側）にルーティングされ、入口交換機又は出口交換機のいずれかが全国汎用データベース７４１に問い合わせを行い、被呼顧客を取り扱う電話会社及び電話局についての情報を得る。
【００８１】
前記全国汎用データベース７４１に問い合わせる際、市外電話会社交換機は被呼者番号（３桁区域番号（ＮＰＡ）−３桁局コード（ＮＸＸ）−４桁個別番号（ＸＸＸＸ））をデータベースに供給し、その応答として、被呼顧客を取り扱う電話会社及び電話会社の端局のＩＤを受け取る。データベースへの問い合わせは、選択された市外電話会社の中間交換機から行うこともできる。これは、例えば特殊な市外電話会社交換機が扱う特殊な種類の呼の場合に生じる例である。
【００８２】
いずれにしても出口交換機は、問い合わせを行った交換機から、又は出口交換機が問い合わせを行う場合には直接にデータベースから、推奨電話会社のＩＤ及びこれら電話会社の各々についての端局のＩＤを知らされる。そして呼が着信側顧客に、この場合はケーブルＴＶ提供会社７２５を経てルーティングされる。
【００８３】
ここで注記したいことは、着信側領域にも、ケーブルＴＶ提供会社のほかにローカル交換電話会社７２１及び競合アクセス提供会社７２３があり、したがって、被呼顧客において呼を完了する仕方に代替事例が存在し得ることである。呼を実際に処理した電話会社に収入があるようにするために、関与した発信電話会社、着信電話会社、及び市外電話会社のＩＤが、呼詳細記録に明確に表記される。又或る特定の電話会社１社が取り扱った場合にはその電話会社が記録を作成するので、その電話会社の関与は自明である。
【００８４】
図１７は、ローカル呼において本発明の構成の柔軟性を示す事例を説明するブロック図である。顧客８０１が異なるローカル電話会社３社、すなわちローカル交換電話会社８１１、競合アクセス提供会社８１３、及びケーブルＴＶ提供会社８１５、へのアクセスを有する。
【００８５】
この顧客が或る特定の呼について競合アクセス提供会社８１３を利用することを選択すると仮定する。ローカル呼が競合アクセス提供会社８１３の交換機に到来すると、競合アクセス提供会社８１３のその交換機が、ダイヤル番号（３桁区域番号−３桁局コード（ＮＸＸ）−４桁個別番号（ＸＸＸＸ））に関連してローカル汎用データベース８４１にアクセスし、その応答として、被呼顧客を取り扱うローカル電話会社及びそのローカル電話会社の端局のＩＤを受け取る。
【００８６】
それから競合アクセス提供会社８１３がその呼を、推奨電話会社を経てルーティングする（この推奨電話会社は、ローカル交換電話会社８１１又はケーブルＴＶ提供会社８１５かもしれない）。ここで注記したいのは、被呼顧客８０３が電話会社３社の全てにアクセスを有するような図示の特定例において、もし推奨着信電話会社を経てのアクセスが阻止された場合には、呼が非推奨電話会社を経てルーティングされることがあり得るということである。
【００８７】
呼を実際に処理した電話会社に収入があるようにするために、関与した発信電話会社、着信電話会社、及び市外電話会社のＩＤが、呼詳細記録に明確に表記される。又或る特定の電話会社１社が取り扱った場合にはその電話会社が記録を作成するので、その電話会社の関与は自明である。
【００８８】
本実施例においては市外電話会社が全国データベースにアクセスするが、代わりに、発信電話会社が全国データベースにアクセスし、着信電話会社のＩＤ及び交換機のＩＤを市外電話会社に回送するように構成することもできる。
【００８９】
ローカル取扱者援助付きの呼の場合、ローカル電話会社が、その呼がローカル取扱者扱いの呼であることを定め、その呼をローカル取扱者援助システムに送る。ローカル取扱者援助システムは、呼者のローカル電話会社ネットワークの一部を構成することも、別のローカルネットワークに存在することもある（ローカル取扱者援助システムは多数のローカルネットワークを取り扱うことができる）。入トランク情報又は信号によって、発信ローカル電話会社が取扱者システムに識別特定される。
【００９０】
取扱者システムが、要求された取扱者サービスを行い、それからローカル汎用データベースに問い合わせて着信電話会社及び着信交換機を知る。取扱者システムが呼を着信電話会社にルーティングし、着信電話会社及び着信交換機のＩＤを送る。そして取扱者システムが、発信及び着信両方の電話会社及び交換機のＩＤを含む呼詳細記録を作成する。
【００９１】
市外取扱者扱いの呼の場合、ローカル電話会社が、その呼が市外取扱者扱いの呼であることを定め、その呼を加入指定又はダイヤルされた市外電話会社取扱者援助システムに送る。入トランク情報又は信号によって、発信ローカル電話会社が取扱者援助システムに識別特定される。取扱者システムが、要求された取扱者サービスを行い、呼を市外入口交換機にルーティングする。これから先のルーティングは、市外入口交換機が全国汎用データベースに問い合わせる等、普通の市外呼の場合と同じである。
【００９２】
市外呼のルーティングが成功すると、着信電話会社及び交換機のＩＤが逆方向に取扱者援助システムに戻され呼詳細記録に含められる。ローカル番号ポート手法の実現に必須なことは、ネットワーク宛先とポートされたダイヤル番号とを連関させる能力である。この情報（位置ルーティング番号と称する）は、被呼者を取り扱う特定の交換機、、すなわち呼のルーティング先を指示するために必要となる。位置ルーティング番号は明らかにローカル番号ポートデータベースにおける重要な要素である。
【００９３】
位置ルーティング番号は、加入者回線の終端となる交換機ごとに選択する必要がある。ローカル番号ポート手法、特に位置ルーティング番号の採用は全てのネットワークにおける呼処理に大きなインパクトを与えることになるが、位置ルーティング番号の形式を適切に選択することによって本手法に必要なネットワークの変更を最小限にすることができる。
【００９４】
具体的には、位置ルーティング番号を採用した場合でも、現行のネットワーク・ルーティング方法を継続使用できること、現存信号プロトコルを使用できること、及び新しい技術規格を必要としないこと、が望ましい。
【００９５】
位置ルーティング番号を用いる場合、いくつかの形式が考えられる。例えば、簡単な５桁数字コードでも１００，０００個までの端局に個別のＩＤを与えることが可能である。代わりに、例えば端局が位置する国地域を指示するルーティング情報を含めるようにコードを設計することもできるし、又ローカルサービス提供会社のＩＤを含めるようにも設計可能である。
【００９６】
しかし、これらの提案はどれも、上記要望事項のうち最も重要な要件である、全てのネットワーク交換機で現行のルーティング・アルゴリズムを持ち続ける必要性、を満足させることができない。
【００９７】
今日、（米国の場合）ルーティングは北米番号方式（ＮＡＮＰ）の番号、特にその最初の６桁、すなわち（３桁区域コード）−（３桁局コードＸＸＸ）、に含まれる地理的情報に基づいている。このことから、（３桁区域コード）−（３桁局コード）以外の形式において位置ルーティング番号を使用すると、新しいコードに基づくルーティングを開発する必要を生じさせることになる。
【００９８】
したがって、位置ルーティング番号は、端局を特定するのに今日用いられている番号方式の形式、すなわち（３桁区域コード）−（３桁局コード）を維持することが適切のようにみえる。
【００９９】
本発明者の原理によれば、加入者回線の終端となる交換機ごとに、（３桁区域コード）−（３桁局コード）の形式で、個別の位置ルーティング番号が割り当てられる。位置ルーティング番号は、コード管理者によって割り当てられる。このコード管理者は、おそらくローカル番号管理担当の管理者と同じ管理者である。
【０１００】
現に１個以上の（３桁区域コード）−（３桁局コード）番号に連関する現存の端局は、現にその端局に割り当てられている（３桁区域コード）−（３桁局コード）番号のうちの１個を位置ルーティング番号として選択使用とするだろう。新たに交換機を設立するローカルサービス提供会社は当然、管理者に位置ルーティング番号を要求して受け取ることになる。位置ルーティング番号は、位置ルーティング番号によって特定される交換機が取り扱う顧客の（３桁区域コード）−（３桁局コード）を含む必要がない。
【０１０１】
ルーティングが複雑になるのを避けるためには、或る端局に割り当てられる位置ルーティング番号が他の端局に割り当てられている（３桁区域コード）−（３桁局コード）ではないことが重要である。
【０１０２】
例えば、大きな端局で、その局が取り扱う顧客を特定するのに現に４個の（３桁区域コード）−（３桁局コード）番号を用いている場合を考える。これら４個の（３桁区域コード）−（３桁局コード）番号のうちの１個がその端局の位置ルーティング番号として選択されたとすると、他の端局の位置ルーティング番号は、この現存する端局に割り当てられている他の３個の（３桁区域コード）−（３桁局コード）番号から選択してはならない。
【０１０３】
この制約によって、ポートされたダイヤル番号についての位置ルーティング番号に基づくルーティングと、ポートされなかった番号についての、ダイヤル番号に基づくルーティングと、を区別するために、別個のルーティングテーブル又は領域を設定する必要がなくなる。そしてむしろ、今日現存するままのルーティングテーブルを用いて呼を完了させることになる。
【０１０４】
最後に、サービス提供会社名、共通位置言語ＩＤコード、複数経路、垂直水平グラフ座標軸、等のような、位置ルーティング番号に連関する情報が、ローカル交換ルーティングガイドに付加されるものと仮定する。
【０１０５】
位置ルーティング番号の選択及び使用において同じく重要なことは、適切な呼完了に要する必要アドレス情報を送信するのに用いられる現存の信号送信方法との両立性である。この情報を着信交換機に直接に、又は中間局若しくは中継局に与えるには、信号送信メッセージが必要である。信号送信路に沿って位置ルーティング番号とダイヤル番号（ＤＮ）との両方を送ることが必要となる。
【０１０６】
位置ルーティング番号は、呼のルーティングに明らかに必要であり、ダイヤル番号は、被呼者に割り当てられたループに接続するために取り扱い端局が必要とする。以下に、現存の信号送信方法を用いてこの情報を送る場合の手法を述べる。
【０１０７】
一般に、信号送信情報は、ＳＳ７プロトコルを用いて専用の共通線信号方式ネットワーク上を搬送される。呼のセットアップは、呼に関する特定の情報をそれぞれ有するいくつかのパラメータからなるアドレス信号を用いて行われる。この信号送信手法を用いることにより、単に現存のパラメータの用法を修正するだけで番号ポート環境において呼を完了させることができる。
【０１０８】
これらパラメータの用法修正には、業界の合意を要するが、ＳＳ７プロトコルのメッセージ内で全く新しい信号送信パラメータの用法を設定し実現するというはるかに複雑且つ時間を消耗する作業を伴うことはない。
【０１０９】
具体的には、ＳＳ７アドレス信号パラメータで、用法修正に関与するものは、被呼者番号（ＣｄＰＮ）パラメータ及び総称アドレスパラメータ（ＧＡＰ）である。今日、非特別呼については、被呼者番号パラメータにはダイヤル番号が配置され、呼のルーティングはこの番号を用いて行われる（非特別呼とは、例えばダイヤル番号をルーティングに直接に使用できない８００番台呼とは対照的に、ダイヤル電話番号がルーティングに使用される呼をいう）。
【０１１０】
総称アドレスパラメータは、ユーザから与えられた番号を搬送するように指定されたオプションのパラメータであって、現在は、わずか数例に用いられているだけである。送られた呼が処理され、位置ルーティング番号がローカル番号ポートデータベースから応答として受信された場合に、その位置ルーティング番号をアドレス信号の被呼者番号パラメータに配置することが提案され、更に、ダイヤル番号を総称アドレスパラメータに入れて送信することが提案される。
【０１１１】
被呼者番号パラメータの内容（位置ルーティング番号）は必要に応じて呼のルーティングに用いられる。情報が（３桁区域コード）−（３桁局コード）の形式に収められているので、ルーティングは変更を要さずに進展することになる。
【０１１２】
着信端局において、位置ルーティング番号の６桁の形式が、交換機によって特定され、ポートされた番号への着信で完了することになる呼が指示される。この位置ルーティング番号をＩＤとして、交換機が、当初にダイヤルされ被呼者を特定するのに必要な番号を、総称アドレスパラメータ内でサーチするようにポイントされる。
【０１１３】
図１８は、位置ルーティング番号の使用に関する本発明者の上記前発明の動作を説明するブロック図である。電話機９０１、９０２、９０３が端局９１１、９１２、９１３にそれぞれ接続されている。端局９１１、９１２は同じローカル地域にあり、端局９１３は、市外電話会社９２０、９２１を相互接続する中継回線を介して端局９１１、９１２に接続されている。
【０１１４】
アクセス中継局９１５、９１６が市外電話会社へのアクセスと、端局とローカル汎用データベース９５１及び全国汎用データベース９５２として示すデータベースとの相互接続とに用いられる。各端局について、それぞれの局が有する局コードの集合（セット）を図中に示す。位置ルーティング番号としても用いられる特定の局コードを括弧内に示す。
【０１１５】
図示の特定例において、電話番号４１５−８８７−１２３４を有する電話端末（電話機９０２）が、位置ルーティング番号４１５−２６７を有する端局９１２に接続されている。端局９１１は、局コード４１５−８８７内の電話番号を有する大量の電話機を取り扱う。
【０１１６】
電話機９０１が、電話番号４１５−８８７−１２３４を有する電話機９０２に対して発呼すると、ローカル汎用データベース９５１のテーブル９３０が点検されて、位置ルーティング番号４１５−２６７によって特定される端局（すなわち端局９１２）が電話番号４１５−８８７−１２３４を取り扱う旨を指示するエントリ９３１が見出される。
【０１１７】
もし電話番号４１５−８８７−１２３４に対するエントリが見出されなかった場合、呼は局コード４１５−８８７を用いて端局９１１にルーティングされていたであろう。
【０１１８】
もし電話機９０１が、電話番号２０１−３３４−９８７６を有する電話機９０３に対して発呼した場合、この呼は,「ローカルアクセス搬送区域間の呼」（市外呼）として識別されて市外電話会社にルーティングされ、市外電話会社は、着信電話番号を取り扱う交換機のＩＤを見出すために全国汎用データベースにアクセスする。この交換機を取り扱う電話会社を介してルーティングするためには、この交換機を特定する必要があるためである。
【０１１９】
全国汎用データベース９５２は電話番号２０１−３３４−９８７６についてのエントリ９４２をテーブル９４０に有し、そのエントリが、着信端局の位置ルーティング番号は２０１−７８９であることを指示する。もしエントリが見出されなかった場合には、呼は局コード２０１−３３４を用いて、局コード２０１−３３４の大量のトラヒックを取り扱う端局９１４にルーティングされていたであろう。
【０１２０】
注記したいのは、データベースが、或る特定の局コードの大量の番号を取り扱うローカル交換機が取り扱っていない番号についてのデータだけを格納すればよいことである。このような交換機から別の交換機に取り扱いが移った顧客の番号についてのデータだけを格納すればよい。
【０１２１】
図１８に関しての市外呼を更に詳細に検討する。
１．ローカルアクセス搬送区域間の呼（又は簡単に、市外呼）が米国カリフォルニア州のエンドユーザから、米国ニュージャージー州の被呼者宛に発呼される。ダイヤルされた番号（ダイヤル番号）は（２０１）３３４−９８７６である。
２．呼は発信端局によって市外呼として認識され、規定された市外電話会社に送られる。
【０１２２】
３．市外電話会社は、ダイヤル番号を特定する点検をそのネットワーク内の発信交換機又は着信交換機いずれでも行うことができるが、この点検が発信側の市外交換機で行われると仮定する。具体的には、ダイヤル番号の最初の６桁（２０１−３３４）が解析され、ポートされた可能性ある番号として特定される。
【０１２３】
４．ダイヤル番号（２０１）３３４−９８７６を用いて、適切な全国汎用データベースに対してデータベース問い合わせが行われる。
５．番号がポートされているので、全国汎用データベースからの応答には、位置ルーティング番号（２０１−７８９）が含まれる。
６．呼が位置ルーティング番号に基づいてルーティングされ、発信側の市外交換機がＳＳ７アドレス信号を作成する。
【０１２４】
７．被呼者番号パラメータに位置ルーティング番号（２０１−７８９）が配置され、ダイヤル番号（２０１）３３４−９８７６が総称アドレスパラメータに挿入される。
８．着信側の市外交換機が、位置ルーティング番号に基づいて呼をルーティングし、指定された端局への信号送信メッセージを生成する。
【０１２５】
９．もし着信端局がＳＳ７及びローカル番号ポート手法に対する対応能力を有する（すなわち修正された信号送信メッセージを認識する能力を有する）場合：
端局が被呼者番号パラメータを点検し、６桁形式を認識し、呼をローカル番号ポート呼として識別し；
端局が総称アドレスパラメータ内の情報（ダイヤル番号）を用いて、呼を適切な加入者ループにルーティングする。
【０１２６】
１０．もし着信端局がローカル番号ポート手法に対する対応能力を有しない場合、（ｎ−１）番目の交換機（すなわち信号送信メッセージを送信する交換機）が、ダイヤル番号が被呼者番号パラメータに含まれるように信号送信メッセージを作成する必要がある。
１１．同様に、もし端局がＳＳ７に対応しない場合、ダイヤル番号は帯域内（ＭＦ）信号送信手法を用いて送られることになる。
【０１２７】
１２．もしダイヤル番号がポートされていなかった場合、呼は通常の手法でルーティングされ、信号送信メッセージは通常の手法で生成され：
ダイヤル番号は、被呼者番号パラメータに配置され；
総称アドレスパラメータは用いられず；
呼は、被呼者番号パラメータに含まれるダイヤル番号に基づいてルーティングされる。
【０１２８】
事例によっては１個の端局交換機が、異なる顧客集合を有する１社以上の電話会社を取り扱い、これらの顧客集合が、異なる電話会社によって取り扱われる異なる電話番号集合に連関するという場合がある。このような状況下では、異なる電話会社の呼について、異なる中継回線グループが用いられことがあり得る。
【０１２９】
したがって、これら中継回線グループを見出すために、ローカル汎用データベース９５１及び全国汎用データベース９５２における変換を、中継回線グループのうちの特定されたもの又はルーティング・インデックスで増強する必要がある。図５に示すように、このような電話会社をルーティングについて特定し、課金記録に入れることが必要である。
【０１３０】
図１９〜図２３に本発明を示す。図１９は、呼の終結を要する状態に対して交換機が用いるメッセージである、解放メッセージの略図である。この場合、解放メッセージは、位置ルーティング番号の形式で又は電話番号で着信交換機を指定するアドレス信号に応動して、間違って選択された着信交換機によって返される。返されたメッセージは、メッセージ種類フィールド１９０１に指示されるような解放メッセージで、その値は「解放」 である。
【０１３１】
その呼を特定できるように、呼をその着信交換機にルーティングした交換機によって結局、回線番号（１９０３）が記述される。最後に、重要な、原因コード（１９０５）が記述される。この原因コードは、呼の着信交換機を特定するために当初にデータベースに問い合わせた交換機（問い合わせ交換機）に、呼が解放された理由を知らせるために解放メッセージに含めるコードである。
【０１３２】
図２０は、従来技術からのもので、取り扱いを予定された着信交換機が、その着信交換機に言及した位置ルーティング番号と、ローカル番号ポート問い合わせが行われた旨の指示と、その着信交換機が対応する回線を持たないディレクトリ番号と共に呼を受信した場合に、その着信交換機が取る動作を記述したものである。動作ブロック２００１は、問い合わせがなされた状態を表す。
【０１３３】
これに応動して、その着信交換機が、空きコード告知を与えずに呼を解放し、米国規格協会（ＡＮＳＩ）規格に規定される原因コード２６号を含む解放メッセージを返す（動作ブロック２００３）。
【０１３４】
図２１は、取り扱いを予定された着信交換機が、ローカル番号ポート問い合わせが行われた旨の指示はあるが位置ルーティング番号がない状態で、その着信交換機が対応する回線を持たないディレクトリ番号と共に呼を受信した場合（動作ブロック２１０１）に、その着信交換機が取る動作を示す。この状態は、空きコードを意味することもあり得るし、又そのディレクトリ番号に対する回線が別の交換機へポートされている状態を意味することもあり得る。
【０１３５】
点検ブロック２１０３において、そのディレクトリ番号についてポート済状態を示すポート済指示子がセットされている（図２３参照）かどうかが点検される。もしセットされていない場合、通常の空きコード処理が呼に対して行われる（動作ブロック２１０５）。
【０１３６】
もしポート済指示子がセットされている場合には、取り扱いを予定された着信交換機が、ＡＮＳＩ規格に規定される原因コード２６号を含む解放メッセージを生成するか、又はもしそれが業界（多分ＡＮＳＩ）に受け入れられない場合は新しい原因コードを生成する。原因コード２６号は、この場合の状態である「ローカル番号ポートデータベースによって与えられたデータに誤りがある」ことを表すから、受け入れられるべきである。
【０１３７】
図２２は、呼を図２０又は図２１の着信交換機にルーティングさせた交換機が行う動作を表す流れ図である。この交換機が、ＡＮＳＩ原因コード２６号又は図２１（動作ブロック２１０７）に関連して述べた新しい原因コードを含む解放メッセージを受信する（動作ブロック２２０１）。
【０１３８】
解放メッセージを受けてこの問い合わせ交換機がこの呼のディレクトリ番号を用いてローカル番号ポートデータベースに問い合わせし（動作ブロック２２０３）、データベースから回答を受信し（動作ブロック２２０５）、回答をこの交換機内のローカルデータベースの内容と比較する（動作ブロック２２０７）。点検ブロック２２０９において、ローカル番号ポートデータベースからの回答がローカルデータベースに格納されている情報に一致するかどうかを定める。
【０１３９】
もし一致しない場合、ローカルデータベースが更新され（動作ブロック２２１１）、更新された情報を用いて呼が再ルーティングされる（動作ブロック２２１３）。もし点検ブロック２２０９において一致がみられた場合には、システム内に純粋なデータベース・エラーがあるようにみえるので、この状態を述べる呼不規則状態（異常状態）報告が生成される（動作ブロック２２２１）。そして呼が解放される。
【０１４０】
図２３は、点検ブロック２１０３（図２１）で用いられるポート済指示子のマーク付け手順を示す。交換機が、或るディレクトリ番号に対する回線が別の交換機にポートされていることを示すメッセージを受信する（動作ブロック２３０１）。そのメッセージの受信に応動してその交換機が、そのディレクトリ番号についてポート済指示子をマーク付けする（動作ブロック２３０３）。この指示子は、もしそのディレクトリ番号がその後不活動状態になった場合にはリセットされる。
【０１４１】
別の実施例においては、点検ブロック５１（図６）が実行されるのと同時に、遠隔データベースに問い合わせがなされる。早期問い合わせにより、呼が、不適切な着信交換機にすぐにルーティングされて動作ブロック２２０３の問い合わせの必要が生じる場合に要する時間を節減できる。その結果、もしローカルデータベースが正しい場合には不必要な大量の問い合わせをすることにはなるが、ローカルデータベースが正しくない場合には、呼セットアップ時間を短縮できる。
【０１４２】
以上の説明は、本発明の一実施例に関するもので、この技術分野の当業者であれば、本発明の種々の変形例を考え得るが、それらはいずれも本発明の技術的範囲に包含される。
【０１４３】
【発明の効果】
以上述べたごとく本発明によれば、ローカル及び／又は市外の複数の電話会社及び／又は電話利用サービス提供会社等の関与する電話呼において、呼をルーティングされた着信局交換機に被呼番号のデータがないという不具合が発生した際にその旨を、ルーティングした側の交換機に返し、そのルーティングした交換機が、広範囲データベースに問い合わせしてローカルデータベースを更新するとともに、その呼の完了を再企図するようにした。
【０１４４】
これにより、当初に呼を正しくない着信交換機にルーティングした交換機のローカルデータベースを自動的に更新させ、その呼も完了させることができる利点が得られるので、電話通信システムの運用効率の向上が図れる。従来技術では、上記不具合時にその呼を満足に処理する方法がなかった。
【図面の簡単な説明】
【図１】本発明の実施に用いられる、複数の交換機が共有するデータベースに接続された交換機を示すブロック図である。
【図２】上記交換機のメモリに格納されるデータ及びプログラムのメモリレイアウトの説明図である。
【図３】上記交換機のメモリに格納されるデータ及びプログラムのメモリレイアウトの説明図である。
【図４】上記交換機のプロセッサが実行する方法の流れ図である。
【図５】上記交換機のプロセッサが実行する方法の流れ図である。
【図６】上記交換機のプロセッサが実行する方法の流れ図である。
【図７】上記交換機のプロセッサが実行する方法の流れ図である。
【図８】上記交換機のプロセッサが実行する方法の流れ図である。
【図９】上記交換機のプロセッサが実行する方法の流れ図である。
【図１０】或る特定の実施例のブロック図である。
【図１１】或る特定の実施例のブロック図である。
【図１２】図１０及び図１１の実施例の流れ図である。
【図１３】図１０及び図１１の実施例の流れ図である。
【図１４】図１０及び図１１の実施例の流れ図である。
【図１５】図１０及び図１１の実施例の流れ図である。
【図１６】実施例を説明する別のブロック図である。
【図１７】実施例を説明する別のブロック図である。
【図１８】実施例を説明する別のブロック図である。
【図１９】本発明の実施方法の流れ図である。
【図２０】本発明の実施方法の流れ図である。
【図２１】本発明の実施方法の流れ図である。
【図２２】本発明の実施方法の流れ図である。
【図２３】本発明の実施方法の流れ図である。
【符号の説明】
１、２  ビットマップ
３  交換機システム（交換機）
４  汎用データベース
１０  プロセッサ
１５  ＣＰＵ
１７  メモリ
１８  プログラム
２０  テーブル
２１、２２、２３  エントリ
２４、２５、２６  指示子
３０  ポインタ
１０１〜１０５  個別顧客
１０６〜１１０、２０４  ローカル（市内）交換電話会社
１１１〜１１３、２１２  市外交換電話会社
１１４、１１７  交換機
１１５、２１１  全国汎用データベース（ＮＵＤＢ）
１１６、１１９  課金記録システム
１１８、２０３  ローカル汎用データベース（ＬＵＤＢ）
２０１  サービス集中管理システム
２０２  個別ローカル電話会社・ローカル（市内）番号ポートサービス管理システム
２１０  市外電話会社・ローカル（市内）番号ポートサービス管理システム
７０１、７０３、８０１、８０３  顧客
７１１、７２１、８１１  ローカル（市内）交換電話会社
７１３、７２３、８１３  競合アクセス提供会社
７１５、７２５、８１５  ケーブルＴＶ提供会社
７３１  入口交換機（発信側）
７３３  出口交換機（着信側）
７４１  全国汎用データベース
８４１  ローカル汎用データベース
９０１、９０２、９０３  電話機
９１１、９１２、９１３  端局
９１５、９１６  アクセス中継局
９２０、９２１  市外電話会社
９３０、９４０  テーブル
９３１、９３２、９４２  エントリ
９５１  ローカル（市内）汎用データベース
９５２  全国汎用データベース
１９０１  メッセージ種類フィールド
１９０３  回線番号
１９０５  原因コード
【図１】
0003983886.tif 000002
【図２】
0003983886.tif 000003
【図３】
0003983886.tif 000004
【図４】
0003983886.tif 000005
【図５】
0003983886.tif 000006
【図６】
0003983886.tif 000007
【図７】
0003983886.tif 000008
【図８】
0003983886.tif 000009
【図９】
0003983886.tif 000010
【図１０】
0003983886.tif 000011
【図１１】
0003983886.tif 000012
【図１２】
0003983886.tif 000013
【図１３】
0003983886.tif 000014
【図１４】
0003983886.tif 000015
【図１５】
0003983886.tif 000016
【図１６】
0003983886.tif 000017
【図１７】
0003983886.tif 000018
【図１８】
0003983886.tif 000019
【図１９】
0003983886.tif 000020
【図２０】
0003983886.tif 000021
【図２１】
0003983886.tif 000022
【図２２】
0003983886.tif 000023
【図２３】
0003983886.tif 000024