JPH1174970A - 電話呼処理方法及び装置 - Google Patents

Abstract

(57)【要約】 【課題】 不適切な着信交換機にルーティングされた電
話呼の処理方法の提供。 【解決手段】 被呼電話番号を取り扱わない着信電話会
社１０８の交換機宛の電話呼の処理方法において、発信
交換機１１７が、呼をルーティングするために交換機１
１７のデータベース１１８にアクセスし、得られたデー
タに基づき呼を着信電話会社１０８の交換機にルーティ
ングする。この呼の番号に対応する回線が見出されない
旨の解放メッセージを、発信交換機１１７が着信電話会
社１０８の交換機から受信し、複数の交換機が共有する
市内番号移植集中データベース１１５にアクセスして、
得た回答を交換機１１７のデータベース１１８のデータ
と比較し、両者が一致しない場合に、交換機１１７のデ
ータベース１１８を集中データベース１１５から得たデ
ータで更新する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は通信ネットワーク内
のデータにアクセスするための方法及び装置に関し、詳
しくは電気通信呼の設立に関してのデータへのアクセス
に関する。

【０００２】

【従来の技術】現代の通信ネットワークは、インテリジ
ェントネットワーク、すなわち、ルーティング（経路選
択及び選択経路を経由しての送信）についてのデータ又
は電気通信呼についてのその他の処理に関するデータ
を、複数の交換機システム又は交換装置（以下、交換
機）が共有するデータベースから引き出すネットワー
ク、の概念をますます用いるようになっている。このよ
うなインテリジェントネットワークの一例は、米国での
８００の３桁で始まる番号への電話呼（８００番コー
ル：被呼者課金呼）を搬送するのに用いられるネットワ
ークである。

【０００３】呼者に無料のこれらの呼は、被呼番号の位
置に直接に関係のない電話番号を用いることが特徴であ
る。これは、米国の普通の電話番号と対照的である。こ
の普通の電話番号とは、最初の３桁の区域コード（市外
局番）が、呼がルーティングされる宛先の区域に関する
情報を与え、次の３桁が局コードで、通常、その区域内
のどの中央局がその呼を受信すべきかに関する情報を与
え、最後の４桁番号でその局コード内の或る特定の被呼
顧客を識別するような構成からなる電話番号である。

【０００４】８００番台電話番号、すなわち最初の３桁
が８００である電話番号、はこれと異なり、次の３桁が
ＮＸＸ（Ｎは２から９までの間の数、Ｘは０から９まで
の間の数）、最後の４桁がＸＸＸＸで、地理的な意味は
ない。呼者が８００番台番号をダイヤルするような呼
（８００番台呼）を電話通信ネットワークが受信する
と、ネットワークはデータベースに問い合わせを行う。
データベースは、その８００番台番号を従来方式番号に
変換する。得られた従来方式番号を用いれば、後に従来
の方法で呼を宛先にルーティングすることが可能とな
る。

【０００５】単に従来方式番号を用いる代わりに８００
番台番号を用いることの利点は、呼者がその呼に課金さ
れないことが即座に保証されることである。これは、商
品の発注、航空券又はホテル宿泊の予約、等の業務の勧
誘に際しての主たる考慮要件のひとつである。

【０００６】ルーティング情報を定めるのにデータベー
スを用いる手法はまた、サービス提供会社の番号の可ポ
ート性（移植）、すなわち、たとえ顧客の呼が、異なる
交換機を用いる異なる電話会社によって取り扱われる場
合でも、その顧客が１つの電話番号を持ち続けられる能
力、に関して用いられている。この用途では、異なる電
話会社に属する異なる交換機が或る電話番号を取り扱う
事例においてその電話番号が属する局コードの局に呼を
ルーティングするのに先立ってデータベースがアクセス
される。

【０００７】従来技術の問題点は、呼のルーティングに
必要な情報を得るためにデータベースに問い合わせを行
うアクセス時間に現在約３００ｍｓを要することであ
る。このアクセス時間は電話呼の呼セットアップ時間に
直接追加され、呼の完了が遅くなる。

【０００８】呼セットアップ時間については、多くの区
域において有力且つ支配的な方式になってきている共通
線信号方式を用いることによって、データベース問い合
わせを要しない通常の状態で、呼セットアップ時間を１
秒の数分の１に削減することができている。これは、８
００番台呼（発呼者無料の呼）のような呼の場合に特に
重要である。その理由は、８００番台呼にはデータベー
ス問い合わせが必要であり、追加問い合わせ時間が呼セ
ットアップ時間に追加されることになるためである。

【０００９】この問題は、本出願の発明者による米国特
許出願番号０８／５３４５３４（１９９５年９月２７日
出願）に記載の手法によって軽減される。同米国出願に
おける開示内容は本出願の推奨実施例の理解に必要な背
景となるので、同開示内容を本明細書内に再現すること
する。本明細書の図１から図１８までの図面は同米国出
願の発明に関するものである。

【００１０】

【発明が解決しようとする課題】上記の米国出願の実
現、又は上記の問題の他の解法の実現、に際して生じる
問題点は、呼のルーティングに必要なデータをローカル
域内又は市内データベース（以下、ローカルデータベー
ス）が提供するように見えるがその呼が宛先にルーティ
ングされる際に、目的のディレクトリ番号（電話番号）
の記録が着信局にない場合に、その呼を満足に処理する
方法がないことである。

【００１１】

【課題を解決するための手段】上記米国出願によれば、
或る交換機内に含まれるローカルデータベースが、特定
の電話番号への呼を設立するために、遠隔のデータベー
ス問い合わせが必要かどうかについての情報を提供す
る。本発明の一実施例によれば、データベース問い合わ
せが必要かどうかを指示するデータは、問い合わせ側交
換機が直接又は間接に取り扱う被呼ディレクトリ番号あ
たり１ビットを用いてビットマップ内に維持される。

【００１２】上記米国出願によれば、もし遠隔のデータ
問い合わせが必要ないと定められた場合、その判断は次
の２つの要因のうちの１つに起因する。これらの要因
は、問い合わせの応答がデフォルト応答であること、又
は問い合わせの応答が問い合わせ側交換機のメモリに格
納されていること、という要因である。

【００１３】デフォルト応答の一例は、着信呼を取り扱
う電話会社の身元（アイデンティティ）を見出すために
データベース問い合わせが行われるという状況下で、そ
の電話会社の交換機を特定する応答である。

【００１４】本発明の一態様によれば、デフォルト属性
と、問い合わせ側交換機に保持されているデータ内のエ
ントリとの間の区別は、第２のビットマップで与えられ
る。第２のビットマップを用いることによって、問い合
わせ側交換機に保持されているデータのサーチが不要と
なるので有利である。

【００１５】上記米国出願の一実施例によれば、区域コ
ード（ＮＰＡ）に局コード（ＮＮＸ）を加えた番号では
被呼番号をどの交換機が取り扱うかを特定できないよう
な番号可ポート性環境において呼をルーティングするた
めにデータベースが用いられる。このような状況におい
ては、ローカル域内又はローカルサービス提供者域内
（以下、ローカル）の呼処理にはローカル汎用データベ
ースが用いられ、異なる地元区域間の呼（長距離呼又は
市外呼）の処理には全国データベースが用いられる。

【００１６】このような場合、特に初めに、大部分の電
話番号は、主たるローカル交換電話会社（米国のＡＴ＆
Ｔ社がそのローカル交換電話会社を分離したときに形成
された地方持株会社の１つのような）による取り扱いが
継続されることになり、したがって、主たる電話会社が
取り扱う被呼電話番号を特定する能力によって、既に、
大部分の呼についての呼セットアップ時間が削減される
ことになる。

【００１７】残りの呼の、大部分ではないにしてもそれ
らの呼の多くについての呼セットアップ時間は、デフォ
ルト属性以外の属性を必要とする最も頻繁に呼ばれる電
話番号についてのデータ、を格納するメモリを適度の大
きさにする（あまり大きくしない）ことによって削減さ
れる。

【００１８】上記米国出願によれば、集中データベース
が、格納されるデータの高信頼性格納場所として存続す
る。定期的にビットマップ内のデータがクリア（消去）
され、最も頻繁に呼ばれる番号についてのデータもクリ
アされるので、これらのデータは呼が発呼される際に集
中データベースにアクセスすることによって再度設定さ
れる。これにより個々の交換機のメモリが自動的に更新
されることになる。

【００１９】図１９〜図２３に関して述べる本発明によ
れば、上記の米国出願の実現又は上記の問題の他の解法
の実現に際して残る問題点は、次のような構成によって
解決される。

【００２０】その構成とは、もし或る交換機への呼の完
了が企図され且つその交換機が着信ディレクトリ番号の
記録を有しない場合に、その交換機が、その着信交換機
に向けてのルーティングを制御した交換機（制御側交換
機）に適切な信号メッセージを返し、それからその制御
した交換機が、ローカルデータベースを更新するため
に、汎用データベースに問い合わせを行い、その呼の完
了を再度企図する、という構成である。

【００２１】この構成は、当初に呼を正しくない着信交
換機にルーティングした交換機のローカルデータベース
を自動的に更新させ、その呼を完了させるという利点を
有する。不適切に取り扱われる呼の数についての目標値
を電話会社が非常に低く設定しているため、呼の保存は
重要な利点である。更に、ローカルデータベースを自動
化することによって、例年のの特別検査の必要性を回避
できる。

【００２２】

【発明の実施の形態】図１に、交換機３を示す。交換機
３はメモリ１７を有するプロセッサ１０からなり、呼の
処理（例えば、受信された電話番号によって特定され
る、呼の着信を取り扱う交換機を特定するような処理）
に要する専門データをその交換機自体のメモリ１７が内
蔵していない場合に汎用データベース４にアクセスす
る。具体的な番号可ポート性の例についての呼処理の詳
細に関しては後に他の図面を参照して説明する。

【００２３】図面２に、本発明者による上記米国出願発
明（以下、前発明）の実施に関連するプロセッサのメモ
リ内容を示す。プロセッサ１０は、プログラム１８から
制御されて後に示す流れ図の動作を行う。このメモリ
は、各々が被呼番号あたり１ビットを有するようなビッ
トマップ１（遠隔データベースビットマップ）及び２
（デフォルトビットマップ）からなる。被呼番号に向け
ての呼のルーティングは交換機３が定める。

【００２４】加えて、メモリ１７は、対応する指示子
（インディケータ）２４、・・・ ２５、２６をそれぞれ有
する複数のエントリ２１、・・・ ２２、２３からなるテー
ブル２０を有する。ビットマップについてのポインタ３
０がエントリのうちの１個とそれに対応する指示子とを
ポイントし、別のエントリをテーブルに挿入すべきとき
に既存のエントリ１個を除去するのを助けるために用い
られる。

【００２５】この動作は、もし汎用データベース４がア
クセスされ、その結果がデフォルト属性以外である場合
に生じる。このような状況において、比較的頻繁に使用
されていなかったテーブル２０内のエントリ１個がクリ
アすなわち除去され、このエントリに対応するビットマ
ップ指示子が、「この着信ディレクトリ番号についての
データがこの交換機にはもはや格納されていない」こと
を指示するように変更される。それから、新たに得られ
たエントリが、エントリの除去によって空いたテーブル
２０内の箇所に挿入、配置される。

【００２６】周知のデータ構造であるＡＶＬツリー
（木）構造を用いることによって、テーブル２０内のど
の箇所にどのエントリを配置することも、又このような
エントリに比較的迅速にアクセスすることも可能となる
（ＡＶＬツリー構造は、文献（例えばD.F.Stubbs et a
l.;Data Structures with Abstruct Data Types and Pa
scal, Brooks Cole Publishing Company, 1985, pages
225-234）に述べられている）。新エントリ挿入の詳細
については図４を参照して下に述べる。

【００２７】図３にテーブル２０の２つの状態を示す。
この場合、交換機３が呼について少なくとも２個の局コ
ード、すなわち２２２及び２７５、に向けてのルーティ
ングを行うものと仮定する。図３の上半部分において、
エントリ２１、２２、及び２３は、電話番号２２２−２
３３３が電話会社１によって取り扱われること、電話番
号２７５−２４５７が電話会社２によって取り扱われる
こと、及び電話番号２７５−１９３０が電話会社１によ
って取り扱われることをそれぞれ指示している。

【００２８】この場合、交換機３が取り扱う全ての電話
番号が同じ区域コード（市外局番）に属するものと仮定
する。明らかに、もし交換機３が市外交換機の場合には
全１０桁番号を要することになる。それから図３の下半
部分は、エントリ２３がクリアされ、電話会社２によっ
て取り扱われる電話番号２２２−１２３３についてのデ
ータがエントリ２３にあったデータと置き換えられたこ
とを示す。

【００２９】図４に、テーブル２０にエントリを挿入す
るプロセスを示す。ポインタ３０は、前にテーブル２０
にエントリが最後に挿入された箇所の次の箇所をポイン
トしている。テーブル２０へのエントリ挿入要求が受信
される（動作ブロック３１）。点検ブロック３２におい
て、「指示子ポイント済」マークがあるかどうかが定め
られる。もし付けられている場合、その子がクリアされ
（動作ブロック３３）、ポインタが進められる（動作ブ
ロック３４）。

【００３０】もし点検ブロック３２の結果として、「指
示子ポイント済」マークがない場合には、現エントリが
クリアされ、そのエントリについてのビットマップが、
現エントリに対応する番号についてのデータはデータベ
ースにアクセスして得る必要がある旨を指示するように
更新される。そして、点検ブロック３２の最後の反復点
検において見出されたマークされていない指示子に対応
する箇所に、新エントリが挿入される。

【００３１】ポインタが進められ（動作ブロック３
６）、どの特定のエントリでも迅速に見いだせるように
テーブル内でエントリをリンクするためのＡＶＬデータ
が、更新される（動作ブロック３７）。ビットマップ１
及び２は、図６及び図７に関連して後に述べるように更
新する必要がある。

【００３２】図５に、単にテーブル２０内の全てのエン
トリをクリアし且つテーブル内の全ての指示子をクリア
することによって、テーブル２０の内容が定期的にリフ
レッシュされることを示す。テーブル内のエントリのク
リア処理（クリア）は、ＡＶＬツリーデータをクリアす
ることによって、且つ交換機３からルーティングされた
電話番号のどれについてもローカルデータベースには
今、何もデータがないことを指示するようにビットマッ
プ１及び２を更新することによって行われる。

【００３３】「定期的に」とは、例えば毎夜、深夜０時
又は午前２時を意味し、その後はどの電話番号でも最初
には遠隔の汎用データベース４（以下、遠隔データベー
ス、とも称する）へのアクセスを要する。

【００３４】そして、呼が到来するにつれて、データ
が、或る特定の電話番号がデフォルト値を有すること、
すなわちこの場合、その番号がその主たる電話会社によ
って取り扱われること、を指示し、又はテーブル２０が
或る特定の電話番号についてのデータを有することを指
示するように、テーブル２０のビットマップ１及び２に
配置される。

【００３５】テーブル２０がクリアされると同時に、両
方のビットマップがクリアされる。これは、交換機３か
らルーティングされる各番号に対する次の呼について、
遠隔データベースに問い合わせが行われることを意味す
る。テーブル２０からデータをクリアするには、ＡＶＬ
ツリーデータをクリアして、サーチでエントリが見出さ
れないようにする。ＡＶＬツリーデータのクリア処理
は、データをテーブル２０に入れる次の企図が成功する
ような仕方で行われる。

【００３６】図６及び図７に、交換機又は遠隔データベ
ース内のデータにアクセスする別の手順を示す。図６
は、交換機内にビットマップが１個（ビットマップ１）
だけ格納されている場合を示す。この場合、ビットは求
めるデータがその交換機に格納されている（ビット＝
１）か、又は遠隔データベースへのアクセスが必要かを
指示する。点検ブロック５０において、データが求めら
れている電話番号に対応するビットマップの状態を点検
する。

【００３７】もしこのビットが１の場合、求めるデータ
はその交換機のメモリ内にある。そして点検ブロック５
１において、そのデータについて交換機メモリのサーチ
が行われる。もしデータが見出されない場合、デフォル
ト属性が用いられる（動作ブロック５２）。

【００３８】もしデータが見出された場合には、交換機
メモリから与えられたデータが用いられ、そのデータに
対するテーブル２０内の指示子がマーク付けされる（動
作ブロック５３）。指示子をマーク付けすることによっ
て、テーブルのこのエントリが、直ちに図４の手順にお
いて交換機メモリから削除される候補ではないことが保
証される。

【００３９】点検ブロック５０での点検の結果、ビット
が０である場合には、遠隔データベースがアクセスされ
（動作ブロック５４）、遠隔データベースによって記述
されるデータが用いられる（動作ブロック５５）。問い
合わせが行われた電話番号についてのビットマップが、
この番号にデフォルト属性が適用される旨、又は適切な
データが交換機メモリ内に格納されている旨を指示でき
るように、マーク付けされる（動作ブロック５６）。

【００４０】点検ブロック５７において、見出されたデ
ータがデフォルト属性かどうかが定められる。もしそう
である場合、これ以上の処理動作は不要である。もしそ
うでない場合には、遠隔データベースにおいて見出され
たデータが交換機メモリ内に格納される（動作ブロック
５８）。そして、このエントリが直ちに除去候補ではな
いことを保証するために、このエントリについての指示
子が１の値をマーク付けされる。

【００４１】図７に、２個のビットマップが用いられる
場合を示す。２個のビットマップを用いることの利点
は、データ要求がなされた電話番号に連関するデータが
デフォルト属性か（その場合データエントリは格納され
ていない）どうかを定めるためにテーブル２０又は同等
物をサーチするのに要する時間を節減できることであ
る。又、不利な点は、第２のビットマップの格納にかか
るコストである。

【００４２】データアクセスが必要な場合、デフォルト
属性ビットマップ（ビットマップ２）が点検される（動
作ブロック６０）。もしこの点検の結果がビット＝１で
ある場合、デフォルト属性が用いられる（動作ブロック
６１）。図７の構成の利点は、最も頻繁に用いられるデ
ータ例、すなわちデフォルト属性、を非常に迅速に見出
すことができることである。

【００４３】もし点検ブロック６０の点検の結果、デー
タが求められている電話番号に対応するビットが０であ
る場合には、図２のビットマップ１に対応する第２のビ
ットマップが点検され（点検ブロック６２）、求められ
るデータを交換機メモリ内に見出すことになるか、又は
遠隔データベース内に見出すことになるかが定められ
る。もしビット値が０の場合、遠隔データベースがアク
セスされ（動作ブロック６３）、遠隔データベースによ
って記述されるデータが用いられる（動作ブロック６
４）。

【００４４】それから点検ブロック６５において、遠隔
データベースから見出されたデータがデフォルト属性か
どうかが定められる。もしそうではない場合、データは
交換機メモリに入れられ、データエントリに対する指示
子が１に設定される（動作ブロック６６）。

【００４５】もし遠隔データベースが返したデータがデ
フォルト属性であり、遠隔データベースがデフォルト属
性を返す代わりに単にデータが見出されない旨のメッセ
ージを返し且つそのメッセージをデフォルト属性を表す
ものとして交換機３が解釈するようなことが可能である
場合には、この電話番号についてデフォルト属性ビット
マップ（ビットマップ２）がマーク付けされ（動作ブロ
ック６７）、そのデフォルト属性が用いられる。

【００４６】もし点検ブロック６２の点検が、ビットが
１であること、すなわちデータが交換機メモリにおいて
見出されるべきことを示す場合には、このデータを見出
すために交換機メモリがアクセスされる（動作ブロック
６８）。交換機メモリによって与えられたデータが用い
られ、このエントリが直ちに除去候補ではないことを保
証するために、このエントリについての指示子がマーク
付けされる（動作ブロック６９）。

【００４７】１個のデフォルト属性ビットマップの代わ
りに共通属性ビットマップを用いる第３の可能性が考え
られ、この場合にはデフォルト属性ビットマップだけが
用いられ、テーブル２０に格納されているようなデータ
は交換機内には保持されていない。この場合、遠隔デー
タベースによってデフォルト属性がまだ確認されていな
い全ての電話番号について、交換機が遠隔データベース
にアクセスする。

【００４８】代わりに又は図７に関して述べた事例につ
いて、いくつかの共通属性（頻繁に用いられる属性）に
対応するいくつかのビットマップを用いることも可能で
ある（これら共通属性は、この場合、求められるデータ
のいくつかの最共通事例ということになる）。番号可ポ
ート性への適用例においては、これは、主たる電話会社
及びいくつかの最も頻繁に用いられる代わりの電話会社
についてのことになる。

【００４９】図８は、デフォルト属性ビットマップだけ
を用いる場合の流れ図である。デフォルト属性ビットマ
ップが、データの求められている電話番号を用いてアク
セスされ、点検される（点検ブロック７０）。もし点検
ブロック７０での点検の結果、ビットマップに値１が見
出された場合、デフォルト属性が用いられる（動作ブロ
ック７１）。もし点検ブロック７０での点検の結果、ビ
ットマップの値が０であった場合には、データベースが
アクセスされる（動作ブロック７２）。

【００５０】点検ブロック７３においてデータベースへ
のアクセス結果が点検され、それがデフォルト属性かど
うかが定められる。もしデフォルト属性でない場合、デ
ータベースから得られたデータが用いられる（動作ブロ
ック７４）。もしデフォルト属性である場合には、デフ
ォルト属性ビットマップがマップ付けされ（動作ブロッ
ク７５）、そのデフォルト属性が用いられる（動作ブロ
ック７６）。

【００５１】図９においては、単一のデフォルト属性ビ
ットマップではなく、複数の共通属性ビットマップがあ
る場合について考える。点検ブロック８０において、共
通属性ビットマップの各々がてされ、これらのビットマ
ップのどれかにおいて、電話番号に対応するビットが１
かどうかが定められる。もし１である場合、１であるこ
とが見出されたビットマップの共通属性が用いられる
（動作ブロック８１）。もし全てが値０である場合に
は、データベースがアクセスされる（動作ブロック８
２）。

【００５２】それから点検ブロック８３において、デー
タベースにおいて見出された結果が共通属性のうちの１
つであるかどうかが定められる。もしそうでない場合、
データベースから得られたデータが用いられる（動作ブ
ロック８４）。もし結果が共通属性のうちの１つである
場合には、見出された共通属性に対応する共通属性ビッ
トマップがマーク付けされ（動作ブロック８５）、見出
された共通属性がデータとして用いられる（動作ブロッ
ク８６）。

【００５３】図８及び図９において述べた両方の事例に
ついて、データベースの完全性を維持するためには、デ
フォルト属性ビットマップ（図８）又は共通属性ビット
マップの全て（図９）をクリアして、呼がなされる際に
これらのビットマップにデータを再入力しさえすればよ
い。

【００５４】図１０〜図１８は、図１〜図９に関して述
べた本発明者による前発明の原理をその推奨実施例とし
て適用できるような具体的なシステム構成を示す。本発
明の原理が、図１２、図１３、図１４、及び図１５の動
作ブロック３０９、４０１、５０５、および６０３の実
施に用いられる。

【００５５】或る電話番号について代替電話会社が指定
されているときには、非常に頻繁に用いられる推奨及び
代替電話会社の組み合わせに対して或るデフォルト属性
を留保する必要があると定められた場合でなければ、テ
ーブル２０又は遠隔データベース内のエントリが必要で
あり、多数のデフォルト属性ビットマップが用いられ
る。

【００５６】図１０は、電話顧客、ローカルサービス提
供会社（すなわち、ローカル交換電話会社）、及び市外
（遠距離）電話会社間の関係を示すブロック図である。
個別顧客１０１〜１０５が電話トラヒックを発信側で開
始し又は着信側で終端する。これらの顧客のうちのの或
る者（例えば顧客１０１及び１０４）は、特に信頼性あ
るサービスを得るために２つの電話会社に接続されてい
る。ローカル交換電話会社１０６〜１１０（簡単に、ロ
ーカル電話会社）は、顧客と、市外交換電話会社１１１
〜１１３（簡単に、市外電話会社）とに接続されてい
る。

【００５７】各ローカル電話会社は、１個以上の交換機
１１７と、ローカル汎用データベース（ＬＵＤＢ）１１
８（又は簡単に、ローカルデータベース）と、課金記録
システムとを有する。代わりに、１個のローカルデータ
ベースをいくつかの又は全てのローカル電話会社で共有
してもよい。交換機は従来の方法で電話接続を設立する
ためのもので、図１０に示すリンクで相互接続されてい
る。ローカルデータベース１１８は、そのローカル電話
会社が取り扱う区域の電話番号についてのデータだけ格
納していればよい。

【００５８】或る特定の区域を取り扱うローカル電話会
社は各々、その区域の全ての電話番号に関するデータを
そのデータベースに格納している。したがって、広い意
味で、各データベースは同じデータを内蔵する。或る特
定の区域及び或る特定の電話会社のためのデータベース
が、その区域を取り扱うその電話会社の各交換機からデ
ータリンクを通してアクセスされる。

【００５９】図１０では各ローカル電話会社について別
個のデータベースを配置しているが、これらのデータベ
ースは、複数のこれらローカル電話会社間で共有するよ
うにもできる。このことは、データベースがデータリン
クを用いてアクセスされるので、特に当然のことといえ
る。

【００６０】ローカル電話会社は、１個以上の交換機１
１４をそれぞれ有する市外電話会社１１１、１１
２、...１１３ に接続され、全国汎用データベース（Ｎ
ＵＤＢ）１１５（又は簡単に、全国データベース）と課
金記録システム１１６とにアクセスする。全国データベ
ースはもちろんローカルデータベースよりもはるかに大
きいが、ローカルデータベースに関して前に述べたこと
は、全国データベースにも当てはまる。

【００６１】この全国データベースは、データベースの
データを使用する交換機からデータリンクを介してアク
セスされるので、全国データベースの形態としては、集
中型又は分散型のどちらも可能であり、複数の市外電話
会社間で共有することもできる。

【００６２】図１１は、ローカルデータベース及び全国
データベースの更新のための構成を示す。サービス集中
管理システム２０１が更新メッセージを個別ローカル電
話会社・ローカル番号ポートサービス管理システム２０
２に送信し、個別ローカル電話会社・ローカル番号ポー
トサービス管理システム２０２がこれら更新メッセージ
をローカル電話会社２０４の各々が有するローカルデー
タベース２０３に送信する。

【００６３】同様に、サービス集中管理システム２０１
が更新メッセージを市外電話会社・ローカル番号ポート
サービス管理システム２１０に送信しこれら更新メッセ
ージは各々、市外電話会社２１２の全国データベース２
１１を更新するために用いられる。

【００６４】ローカルアクセス提供会社（ローカル電話
会社）は更新情報をサービス集中管理システム２０１に
提供する必要がある。顧客がサービス提供会社（ローカ
ル電話会社）を変更する場合についての更新について
は、顧客の新しい（変更後の）ローカル電話会社が担当
する。顧客が電話会社を変更する際は、データベースが
更新されるまでの短期（数日）間、当初（変更前）のロ
ーカル電話会社が呼を回送する必要がある。

【００６５】図１２は、この種の構成についてのルーテ
ィング手順の流れ図である。ローカル電話会社の交換機
（又は簡単に、ローカル交換機）が呼を受信する（動作
ブロック３０１）。ローカル交換機が、この呼がローカ
ル呼、市外呼のいずれであるかについて解釈する（点検
ブロック３０３）。

【００６６】もし地理的番号（位置）の可ポート性がこ
の呼の受信区域において実現される場合、点検ブロック
３０３の点検を成功させるために、ローカルデータベー
スが、推奨される着信ローカル電話会社、及び着信側顧
客を取り扱う交換機を返し、これを、この呼がローカル
呼か市外呼かを定めるための発信交換機の特定に関連し
て用いることができる。

【００６７】又もしローカルデータベースが着信側顧客
についてのデータを内蔵しないことが認識された場合、
呼は市外呼である。このことは、例えば、着信側顧客の
区域コードから定めることができるし、又もし地理的番
号（位置）ポートが被呼番号の局コードからは実現され
なかった場合にもそのように定めることができる。

【００６８】もし点検ブロック３０３の結果、これが市
外呼であると定められた場合、呼は規定された市外電話
会社へ、又はもし顧客が適切なコード番号をダイヤルし
て市外電話会社を指定する場合にはその、ダイヤル指定
された市外電話会社にルーティングされる（動作ブロッ
ク３０５）。その市外電話会社が、発信側顧客の自動番
号識別ＩＤ（ＡＮＩ）とダイヤルされた番号（又は簡単
に、ダイヤル番号）とを受信する（動作ブロック３０
７）。

【００６９】それから市外電話会社が全国データベース
にアクセスして、着信電話会社（及び、もしあれば代替
会社）及び着信交換機（及び、もし指定があればその指
定代替交換機）を定める（動作ブロック３０９）。そし
て、市外電話会社が呼を、推奨着信電話会社のために作
動する出口（着信）交換機にルーティングし、着信電話
会社ＩＤ及び着信端局ＩＤを送信する（動作ブロック３
１１）。

【００７０】点検ブロック３１３において、推奨着信電
話会社が利用可能かどうかが定められる。もし利用可能
な場合、呼はその推奨着信電話会社を経て被呼顧客に着
信して完了となる（動作ブロック３１５）。もし点検ブ
ロック３１３の結果が否定的でその推奨電話会社が利用
可能でない場合には、点検ブロック３１７において、代
替電話会社が指定されているかどうかが定められる。

【００７１】もし代替電話会社が指定されている場合、
点検ブロック３１９において、その代替電話会社が利用
可能かどうかが定められる。もし利用可能な場合、呼は
その代替電話会社にルーティングされ被呼顧客に着信し
て完了となる（動作ブロック３２１）。もし利用可能で
ない場合には、呼は阻止され、阻止された呼に対する処
理が行われる（動作ブロック３２３）。同様に、もし点
検ブロック３１７の結果が否定的で代替電話会社が指定
されていなかった場合にも、呼は阻止される（動作ブロ
ック３２３）。

【００７２】もし呼がローカル呼か市外呼かを定める点
検ブロック３０３の結果、呼がローカル呼の場合には、
図１３の動作ブロック４０１に進む。動作ブロック４０
１において、ローカル電話会社の交換機が、ローカルデ
ータベースに問い合わせを行い、推奨電話会社及び交換
機（並びに、もし指定がある場合には代替電話会社及び
交換機）を定める。点検ブロック４０３において、推奨
電話会社が利用可能かどうかが定められる。

【００７３】もし推奨電話会社が利用可能な場合、呼は
その推奨着信電話会社にルーティングされ、推奨着信電
話会社ＩＤ及び着信端局ＩＤが着信電話会社に送信され
る（動作ブロック４０５）。もしその推奨電話会社が利
用可能でない場合には、点検ブロック４０７において、
代替電話会社が指定されているかどうかが定められる。
もし代替電話会社が指定されている場合、点検ブロック
４０９において、その代替電話会社が利用可能かどうか
が定められる。

【００７４】もし利用可能な場合、呼はその代替電話会
社にルーティングされ被呼顧客に着信して完了となる
（動作ブロック４１１）。もし点検ブロック４０９の結
果が否定的でその推奨電話会社が利用可能でない場合に
は、呼は阻止され、阻止された呼に対する処理が行われ
る（動作ブロック４１３）。

【００７５】図１４は、市外呼の課金の際の動作を示す
流れ図である。市外電話会社が、発信側顧客の自動番号
識別ＩＤ（簡単に、自動番号ＩＤ）とダイヤル番号とを
受信する（動作ブロック５０１）。市外電話会社が、入
トランク（入り接続中継線装置）ＩＤを発信電話会社Ｉ
Ｄに変換して、発信電話会社を定める（動作ブロック５
０３）。代わりに、発信電話会社からの信号情報によっ
て発信電話会社を特定することもできる。

【００７６】それから市外電話会社が、全国データベー
スに問い合わせを行い、被呼番号に対する着信電話会社
及び交換機を特定する（動作ブロック５０５）。そして
市外電話会社が、自動番号ＩＤ、被呼番号、発信及び着
信ローカル電話会社ＩＤ、発信及び着信交換機ＩＤ、市
外電話会社ＩＤ（いくつかの電話会社に対する課金記録
が１個のプロセッサによって処理される場合）、並びに
その呼についての経過時間からなる呼詳細記録を作成す
る（動作ブロック５０７）。

【００７７】図１５は、ローカル呼についての課金の手
順である。ローカル電話会社が、発信側顧客の自動番号
ＩＤ（ＡＮＩ）とダイヤル番号とを受信する（動作ブロ
ック６０１）。それからローカル電話会社が、ローカル
データベースに問い合わせを行い、ダイヤル番号に基づ
き、着信電話会社及び交換機を特定する（動作ブロック
６０３）。そしてローカル電話会社が、自動番号ＩＤ、
ダイヤル番号、着信ローカル電話会社ＩＤ、及び着信交
換機ＩＤからなる呼詳細記録を作成する（動作ブロック
６０５）。

【００７８】代替着信電話会社が用いられる場合には、
呼詳細記録の項目中の推奨電話会社及び交換機の代わり
に、代替電話会社及び交換機が入れられる。

【００７９】図１６は、市外呼において本発明の構成の
柔軟性を示す事例を説明するブロック図である。顧客７
０１が異なるローカル電話会社３社、すなわちローカル
交換電話会社７１１、競合アクセス提供会社７１３、及
びケーブルＴＶ提供会社７１５、へのアクセスを有す
る。

【００８０】市外呼が選択された市外電話会社の入口交
換機７３１（発信側）に到来すると、呼は市外電話会社
の出口交換機７３３（着信側）にルーティングされ、入
口交換機又は出口交換機のいずれかが全国汎用データベ
ース７４１に問い合わせを行い、被呼顧客を取り扱う電
話会社及び電話局についての情報を得る。

【００８１】前記全国汎用データベース７４１に問い合
わせる際、市外電話会社交換機は被呼者番号（３桁区域
番号（ＮＰＡ）−３桁局コード（ＮＸＸ）−４桁個別番
号（ＸＸＸＸ））をデータベースに供給し、その応答と
して、被呼顧客を取り扱う電話会社及び電話会社の端局
のＩＤを受け取る。データベースへの問い合わせは、選
択された市外電話会社の中間交換機から行うこともでき
る。これは、例えば特殊な市外電話会社交換機が扱う特
殊な種類の呼の場合に生じる例である。

【００８２】いずれにしても出口交換機は、問い合わせ
を行った交換機から、又は出口交換機が問い合わせを行
う場合には直接にデータベースから、推奨電話会社のＩ
Ｄ及びこれら電話会社の各々についての端局のＩＤを知
らされる。そして呼が着信側顧客に、この場合はケーブ
ルＴＶ提供会社７２５を経てルーティングされる。

【００８３】ここで注記したいことは、着信側領域に
も、ケーブルＴＶ提供会社のほかにローカル交換電話会
社７２１及び競合アクセス提供会社７２３があり、した
がって、被呼顧客において呼を完了する仕方に代替事例
が存在し得ることである。呼を実際に処理した電話会社
に収入があるようにするために、関与した発信電話会
社、着信電話会社、及び市外電話会社のＩＤが、呼詳細
記録に明確に表記される。又或る特定の電話会社１社が
取り扱った場合にはその電話会社が記録を作成するの
で、その電話会社の関与は自明である。

【００８４】図１７は、ローカル呼において本発明の構
成の柔軟性を示す事例を説明するブロック図である。顧
客８０１が異なるローカル電話会社３社、すなわちロー
カル交換電話会社８１１、競合アクセス提供会社８１
３、及びケーブルＴＶ提供会社８１５、へのアクセスを
有する。

【００８５】この顧客が或る特定の呼について競合アク
セス提供会社８１３を利用することを選択すると仮定す
る。ローカル呼が競合アクセス提供会社８１３の交換機
に到来すると、競合アクセス提供会社８１３のその交換
機が、ダイヤル番号（３桁区域番号−３桁局コード（Ｎ
ＸＸ）−４桁個別番号（ＸＸＸＸ））に関連してローカ
ル汎用データベース８４１にアクセスし、その応答とし
て、被呼顧客を取り扱うローカル電話会社及びそのロー
カル電話会社の端局のＩＤを受け取る。

【００８６】それから競合アクセス提供会社８１３がそ
の呼を、推奨電話会社を経てルーティングする（この推
奨電話会社は、ローカル交換電話会社８１１又はケーブ
ルＴＶ提供会社８１５かもしれない）。ここで注記した
いのは、被呼顧客８０３が電話会社３社の全てにアクセ
スを有するような図示の特定例において、もし推奨着信
電話会社を経てのアクセスが阻止された場合には、呼が
非推奨電話会社を経てルーティングされることがあり得
るということである。

【００８７】呼を実際に処理した電話会社に収入がある
ようにするために、関与した発信電話会社、着信電話会
社、及び市外電話会社のＩＤが、呼詳細記録に明確に表
記される。又或る特定の電話会社１社が取り扱った場合
にはその電話会社が記録を作成するので、その電話会社
の関与は自明である。

【００８８】本実施例においては市外電話会社が全国デ
ータベースにアクセスするが、代わりに、発信電話会社
が全国データベースにアクセスし、着信電話会社のＩＤ
及び交換機のＩＤを市外電話会社に回送するように構成
することもできる。

【００８９】ローカル取扱者援助付きの呼の場合、ロー
カル電話会社が、その呼がローカル取扱者扱いの呼であ
ることを定め、その呼をローカル取扱者援助システムに
送る。ローカル取扱者援助システムは、呼者のローカル
電話会社ネットワークの一部を構成することも、別のロ
ーカルネットワークに存在することもある（ローカル取
扱者援助システムは多数のローカルネットワークを取り
扱うことができる）。入トランク情報又は信号によっ
て、発信ローカル電話会社が取扱者システムに識別特定
される。

【００９０】取扱者システムが、要求された取扱者サー
ビスを行い、それからローカル汎用データベースに問い
合わせて着信電話会社及び着信交換機を知る。取扱者シ
ステムが呼を着信電話会社にルーティングし、着信電話
会社及び着信交換機のＩＤを送る。そして取扱者システ
ムが、発信及び着信両方の電話会社及び交換機のＩＤを
含む呼詳細記録を作成する。

【００９１】市外取扱者扱いの呼の場合、ローカル電話
会社が、その呼が市外取扱者扱いの呼であることを定
め、その呼を加入指定又はダイヤルされた市外電話会社
取扱者援助システムに送る。入トランク情報又は信号に
よって、発信ローカル電話会社が取扱者援助システムに
識別特定される。取扱者システムが、要求された取扱者
サービスを行い、呼を市外入口交換機にルーティングす
る。これから先のルーティングは、市外入口交換機が全
国汎用データベースに問い合わせる等、普通の市外呼の
場合と同じである。

【００９２】市外呼のルーティングが成功すると、着信
電話会社及び交換機のＩＤが逆方向に取扱者援助システ
ムに戻され呼詳細記録に含められる。ローカル番号ポー
ト手法の実現に必須なことは、ネットワーク宛先とポー
トされたダイヤル番号とを連関させる能力である。この
情報（位置ルーティング番号と称する）は、被呼者を取
り扱う特定の交換機、、すなわち呼のルーティング先を
指示するために必要となる。位置ルーティング番号は明
らかにローカル番号ポートデータベースにおける重要な
要素である。

【００９３】位置ルーティング番号は、加入者回線の終
端となる交換機ごとに選択する必要がある。ローカル番
号ポート手法、特に位置ルーティング番号の採用は全て
のネットワークにおける呼処理に大きなインパクトを与
えることになるが、位置ルーティング番号の形式を適切
に選択することによって本手法に必要なネットワークの
変更を最小限にすることができる。

【００９４】具体的には、位置ルーティング番号を採用
した場合でも、現行のネットワーク・ルーティング方法
を継続使用できること、現存信号プロトコルを使用でき
ること、及び新しい技術規格を必要としないこと、が望
ましい。

【００９５】位置ルーティング番号を用いる場合、いく
つかの形式が考えられる。例えば、簡単な５桁数字コー
ドでも１００，０００個までの端局に個別のＩＤを与え
ることが可能である。代わりに、例えば端局が位置する
国地域を指示するルーティング情報を含めるようにコー
ドを設計することもできるし、又ローカルサービス提供
会社のＩＤを含めるようにも設計可能である。

【００９６】しかし、これらの提案はどれも、上記要望
事項のうち最も重要な要件である、全てのネットワーク
交換機で現行のルーティング・アルゴリズムを持ち続け
る必要性、を満足させることができない。

【００９７】今日、（米国の場合）ルーティングは北米
番号方式（ＮＡＮＰ）の番号、特にその最初の６桁、す
なわち（３桁区域コード）−（３桁局コードＸＸＸ）、
に含まれる地理的情報に基づいている。このことから、
（３桁区域コード）−（３桁局コード）以外の形式にお
いて位置ルーティング番号を使用すると、新しいコード
に基づくルーティングを開発する必要を生じさせること
になる。

【００９８】したがって、位置ルーティング番号は、端
局を特定するのに今日用いられている番号方式の形式、
すなわち（３桁区域コード）−（３桁局コード）を維持
することが適切のようにみえる。

【００９９】本発明者の原理によれば、加入者回線の終
端となる交換機ごとに、（３桁区域コード）−（３桁局
コード）の形式で、個別の位置ルーティング番号が割り
当てられる。位置ルーティング番号は、コード管理者に
よって割り当てられる。このコード管理者は、おそらく
ローカル番号管理担当の管理者と同じ管理者である。

【０１００】現に１個以上の（３桁区域コード）−（３
桁局コード）番号に連関する現存の端局は、現にその端
局に割り当てられている（３桁区域コード）−（３桁局
コード）番号のうちの１個を位置ルーティング番号とし
て選択使用とするだろう。新たに交換機を設立するロー
カルサービス提供会社は当然、管理者に位置ルーティン
グ番号を要求して受け取ることになる。位置ルーティン
グ番号は、位置ルーティング番号によって特定される交
換機が取り扱う顧客の（３桁区域コード）−（３桁局コ
ード）を含む必要がない。

【０１０１】ルーティングが複雑になるのを避けるため
には、或る端局に割り当てられる位置ルーティング番号
が他の端局に割り当てられている（３桁区域コード）−
（３桁局コード）ではないことが重要である。

【０１０２】例えば、大きな端局で、その局が取り扱う
顧客を特定するのに現に４個の（３桁区域コード）−
（３桁局コード）番号を用いている場合を考える。これ
ら４個の（３桁区域コード）−（３桁局コード）番号の
うちの１個がその端局の位置ルーティング番号として選
択されたとすると、他の端局の位置ルーティング番号
は、この現存する端局に割り当てられている他の３個の
（３桁区域コード）−（３桁局コード）番号から選択し
てはならない。

【０１０３】この制約によって、ポートされたダイヤル
番号についての位置ルーティング番号に基づくルーティ
ングと、ポートされなかった番号についての、ダイヤル
番号に基づくルーティングと、を区別するために、別個
のルーティングテーブル又は領域を設定する必要がなく
なる。そしてむしろ、今日現存するままのルーティング
テーブルを用いて呼を完了させることになる。

【０１０４】最後に、サービス提供会社名、共通位置言
語ＩＤコード、複数経路、垂直水平グラフ座標軸、等の
ような、位置ルーティング番号に連関する情報が、ロー
カル交換ルーティングガイドに付加されるものと仮定す
る。

【０１０５】位置ルーティング番号の選択及び使用にお
いて同じく重要なことは、適切な呼完了に要する必要ア
ドレス情報を送信するのに用いられる現存の信号送信方
法との両立性である。この情報を着信交換機に直接に、
又は中間局若しくは中継局に与えるには、信号送信メッ
セージが必要である。信号送信路に沿って位置ルーティ
ング番号とダイヤル番号（ＤＮ）との両方を送ることが
必要となる。

【０１０６】位置ルーティング番号は、呼のルーティン
グに明らかに必要であり、ダイヤル番号は、被呼者に割
り当てられたループに接続するために取り扱い端局が必
要とする。以下に、現存の信号送信方法を用いてこの情
報を送る場合の手法を述べる。

【０１０７】一般に、信号送信情報は、ＳＳ７プロトコ
ルを用いて専用の共通線信号方式ネットワーク上を搬送
される。呼のセットアップは、呼に関する特定の情報を
それぞれ有するいくつかのパラメータからなるアドレス
信号を用いて行われる。この信号送信手法を用いること
により、単に現存のパラメータの用法を修正するだけで
番号ポート環境において呼を完了させることができる。

【０１０８】これらパラメータの用法修正には、業界の
合意を要するが、ＳＳ７プロトコルのメッセージ内で全
く新しい信号送信パラメータの用法を設定し実現すると
いうはるかに複雑且つ時間を消耗する作業を伴うことは
ない。

【０１０９】具体的には、ＳＳ７アドレス信号パラメー
タで、用法修正に関与するものは、被呼者番号（ＣｄＰ
Ｎ）パラメータ及び総称アドレスパラメータ（ＧＡＰ）
である。今日、非特別呼については、被呼者番号パラメ
ータにはダイヤル番号が配置され、呼のルーティングは
この番号を用いて行われる（非特別呼とは、例えばダイ
ヤル番号をルーティングに直接に使用できない８００番
台呼とは対照的に、ダイヤル電話番号がルーティングに
使用される呼をいう）。

【０１１０】総称アドレスパラメータは、ユーザから与
えられた番号を搬送するように指定されたオプションの
パラメータであって、現在は、わずか数例に用いられて
いるだけである。送られた呼が処理され、位置ルーティ
ング番号がローカル番号ポートデータベースから応答と
して受信された場合に、その位置ルーティング番号をア
ドレス信号の被呼者番号パラメータに配置することが提
案され、更に、ダイヤル番号を総称アドレスパラメータ
に入れて送信することが提案される。

【０１１１】被呼者番号パラメータの内容（位置ルーテ
ィング番号）は必要に応じて呼のルーティングに用いら
れる。情報が（３桁区域コード）−（３桁局コード）の
形式に収められているので、ルーティングは変更を要さ
ずに進展することになる。

【０１１２】着信端局において、位置ルーティング番号
の６桁の形式が、交換機によって特定され、ポートされ
た番号への着信で完了することになる呼が指示される。
この位置ルーティング番号をＩＤとして、交換機が、当
初にダイヤルされ被呼者を特定するのに必要な番号を、
総称アドレスパラメータ内でサーチするようにポイント
される。

【０１１３】図１８は、位置ルーティング番号の使用に
関する本発明者の上記前発明の動作を説明するブロック
図である。電話機９０１、９０２、９０３が端局９１
１、９１２、９１３にそれぞれ接続されている。端局９
１１、９１２は同じローカル地域にあり、端局９１３
は、市外電話会社９２０、９２１を相互接続する中継回
線を介して端局９１１、９１２に接続されている。

【０１１４】アクセス中継局９１５、９１６が市外電話
会社へのアクセスと、端局とローカル汎用データベース
９５１及び全国汎用データベース９５２として示すデー
タベースとの相互接続とに用いられる。各端局につい
て、それぞれの局が有する局コードの集合（セット）を
図中に示す。位置ルーティング番号としても用いられる
特定の局コードを括弧内に示す。

【０１１５】図示の特定例において、電話番号４１５−
８８７−１２３４を有する電話端末（電話機９０２）
が、位置ルーティング番号４１５−２６７を有する端局
９１２に接続されている。端局９１１は、局コード４１
５−８８７内の電話番号を有する大量の電話機を取り扱
う。

【０１１６】電話機９０１が、電話番号４１５−８８７
−１２３４を有する電話機９０２に対して発呼すると、
ローカル汎用データベース９５１のテーブル９３０が点
検されて、位置ルーティング番号４１５−２６７によっ
て特定される端局（すなわち端局９１２）が電話番号４
１５−８８７−１２３４を取り扱う旨を指示するエント
リ９３１が見出される。

【０１１７】もし電話番号４１５−８８７−１２３４に
対するエントリが見出されなかった場合、呼は局コード
４１５−８８７を用いて端局９１１にルーティングされ
ていたであろう。

【０１１８】もし電話機９０１が、電話番号２０１−３
３４−９８７６を有する電話機９０３に対して発呼した
場合、この呼は,「ローカルアクセス搬送区域間の呼」
（市外呼）として識別されて市外電話会社にルーティン
グされ、市外電話会社は、着信電話番号を取り扱う交換
機のＩＤを見出すために全国汎用データベースにアクセ
スする。この交換機を取り扱う電話会社を介してルーテ
ィングするためには、この交換機を特定する必要がある
ためである。

【０１１９】全国汎用データベース９５２は電話番号２
０１−３３４−９８７６についてのエントリ９４２をテ
ーブル９４０に有し、そのエントリが、着信端局の位置
ルーティング番号は２０１−７８９であることを指示す
る。もしエントリが見出されなかった場合には、呼は局
コード２０１−３３４を用いて、局コード２０１−３３
４の大量のトラヒックを取り扱う端局９１４にルーティ
ングされていたであろう。

【０１２０】注記したいのは、データベースが、或る特
定の局コードの大量の番号を取り扱うローカル交換機が
取り扱っていない番号についてのデータだけを格納すれ
ばよいことである。このような交換機から別の交換機に
取り扱いが移った顧客の番号についてのデータだけを格
納すればよい。

【０１２１】図１８に関しての市外呼を更に詳細に検討
する。 １．ローカルアクセス搬送区域間の呼（又は簡単に、市
外呼）が米国カリフォルニア州のエンドユーザから、米
国ニュージャージー州の被呼者宛に発呼される。ダイヤ
ルされた番号（ダイヤル番号）は（２０１）３３４−９
８７６である。 ２．呼は発信端局によって市外呼として認識され、規定
された市外電話会社に送られる。

【０１２２】３．市外電話会社は、ダイヤル番号を特定
する点検をそのネットワーク内の発信交換機又は着信交
換機いずれでも行うことができるが、この点検が発信側
の市外交換機で行われると仮定する。具体的には、ダイ
ヤル番号の最初の６桁（２０１−３３４）が解析され、
ポートされた可能性ある番号として特定される。

【０１２３】４．ダイヤル番号（２０１）３３４−９８
７６を用いて、適切な全国汎用データベースに対してデ
ータベース問い合わせが行われる。 ５．番号がポートされているので、全国汎用データベー
スからの応答には、位置ルーティング番号（２０１−７
８９）が含まれる。 ６．呼が位置ルーティング番号に基づいてルーティング
され、発信側の市外交換機がＳＳ７アドレス信号を作成
する。

【０１２４】７．被呼者番号パラメータに位置ルーティ
ング番号（２０１−７８９）が配置され、ダイヤル番号
（２０１）３３４−９８７６が総称アドレスパラメータ
に挿入される。 ８．着信側の市外交換機が、位置ルーティング番号に基
づいて呼をルーティングし、指定された端局への信号送
信メッセージを生成する。

【０１２５】９．もし着信端局がＳＳ７及びローカル番
号ポート手法に対する対応能力を有する（すなわち修正
された信号送信メッセージを認識する能力を有する）場
合：端局が被呼者番号パラメータを点検し、６桁形式を
認識し、呼をローカル番号ポート呼として識別し；端局
が総称アドレスパラメータ内の情報（ダイヤル番号）を
用いて、呼を適切な加入者ループにルーティングする。

【０１２６】１０．もし着信端局がローカル番号ポート
手法に対する対応能力を有しない場合、（ｎ−１）番目
の交換機（すなわち信号送信メッセージを送信する交換
機）が、ダイヤル番号が被呼者番号パラメータに含まれ
るように信号送信メッセージを作成する必要がある。 １１．同様に、もし端局がＳＳ７に対応しない場合、ダ
イヤル番号は帯域内（ＭＦ）信号送信手法を用いて送ら
れることになる。

【０１２７】１２．もしダイヤル番号がポートされてい
なかった場合、呼は通常の手法でルーティングされ、信
号送信メッセージは通常の手法で生成され：ダイヤル番
号は、被呼者番号パラメータに配置され；総称アドレス
パラメータは用いられず；呼は、被呼者番号パラメータ
に含まれるダイヤル番号に基づいてルーティングされ
る。

【０１２８】事例によっては１個の端局交換機が、異な
る顧客集合を有する１社以上の電話会社を取り扱い、こ
れらの顧客集合が、異なる電話会社によって取り扱われ
る異なる電話番号集合に連関するという場合がある。こ
のような状況下では、異なる電話会社の呼について、異
なる中継回線グループが用いられことがあり得る。

【０１２９】したがって、これら中継回線グループを見
出すために、ローカル汎用データベース９５１及び全国
汎用データベース９５２における変換を、中継回線グル
ープのうちの特定されたもの又はルーティング・インデ
ックスで増強する必要がある。図５に示すように、この
ような電話会社をルーティングについて特定し、課金記
録に入れることが必要である。

【０１３０】図１９〜図２３に本発明を示す。図１９
は、呼の終結を要する状態に対して交換機が用いるメッ
セージである、解放メッセージの略図である。この場
合、解放メッセージは、位置ルーティング番号の形式で
又は電話番号で着信交換機を指定するアドレス信号に応
動して、間違って選択された着信交換機によって返され
る。返されたメッセージは、メッセージ種類フィールド
１９０１に指示されるような解放メッセージで、その値
は「解放」 である。

【０１３１】その呼を特定できるように、呼をその着信
交換機にルーティングした交換機によって結局、回線番
号（１９０３）が記述される。最後に、重要な、原因コ
ード（１９０５）が記述される。この原因コードは、呼
の着信交換機を特定するために当初にデータベースに問
い合わせた交換機（問い合わせ交換機）に、呼が解放さ
れた理由を知らせるために解放メッセージに含めるコー
ドである。

【０１３２】図２０は、従来技術からのもので、取り扱
いを予定された着信交換機が、その着信交換機に言及し
た位置ルーティング番号と、ローカル番号ポート問い合
わせが行われた旨の指示と、その着信交換機が対応する
回線を持たないディレクトリ番号と共に呼を受信した場
合に、その着信交換機が取る動作を記述したものであ
る。動作ブロック２００１は、問い合わせがなされた状
態を表す。

【０１３３】これに応動して、その着信交換機が、空き
コード告知を与えずに呼を解放し、米国規格協会（ＡＮ
ＳＩ）規格に規定される原因コード２６号を含む解放メ
ッセージを返す（動作ブロック２００３）。

【０１３４】図２１は、取り扱いを予定された着信交換
機が、ローカル番号ポート問い合わせが行われた旨の指
示はあるが位置ルーティング番号がない状態で、その着
信交換機が対応する回線を持たないディレクトリ番号と
共に呼を受信した場合（動作ブロック２１０１）に、そ
の着信交換機が取る動作を示す。この状態は、空きコー
ドを意味することもあり得るし、又そのディレクトリ番
号に対する回線が別の交換機へポートされている状態を
意味することもあり得る。

【０１３５】点検ブロック２１０３において、そのディ
レクトリ番号についてポート済状態を示すポート済指示
子がセットされている（図２３参照）かどうかが点検さ
れる。もしセットされていない場合、通常の空きコード
処理が呼に対して行われる（動作ブロック２１０５）。

【０１３６】もしポート済指示子がセットされている場
合には、取り扱いを予定された着信交換機が、ＡＮＳＩ
規格に規定される原因コード２６号を含む解放メッセー
ジを生成するか、又はもしそれが業界（多分ＡＮＳＩ）
に受け入れられない場合は新しい原因コードを生成す
る。原因コード２６号は、この場合の状態である「ロー
カル番号ポートデータベースによって与えられたデータ
に誤りがある」ことを表すから、受け入れられるべきで
ある。

【０１３７】図２２は、呼を図２０又は図２１の着信交
換機にルーティングさせた交換機が行う動作を表す流れ
図である。この交換機が、ＡＮＳＩ原因コード２６号又
は図２１（動作ブロック２１０７）に関連して述べた新
しい原因コードを含む解放メッセージを受信する（動作
ブロック２２０１）。

【０１３８】解放メッセージを受けてこの問い合わせ交
換機がこの呼のディレクトリ番号を用いてローカル番号
ポートデータベースに問い合わせし（動作ブロック２２
０３）、データベースから回答を受信し（動作ブロック
２２０５）、回答をこの交換機内のローカルデータベー
スの内容と比較する（動作ブロック２２０７）。点検ブ
ロック２２０９において、ローカル番号ポートデータベ
ースからの回答がローカルデータベースに格納されてい
る情報に一致するかどうかを定める。

【０１３９】もし一致しない場合、ローカルデータベー
スが更新され（動作ブロック２２１１）、更新された情
報を用いて呼が再ルーティングされる（動作ブロック２
２１３）。もし点検ブロック２２０９において一致がみ
られた場合には、システム内に純粋なデータベース・エ
ラーがあるようにみえるので、この状態を述べる呼不規
則状態（異常状態）報告が生成される（動作ブロック２
２２１）。そして呼が解放される。

【０１４０】図２３は、点検ブロック２１０３（図２
１）で用いられるポート済指示子のマーク付け手順を示
す。交換機が、或るディレクトリ番号に対する回線が別
の交換機にポートされていることを示すメッセージを受
信する（動作ブロック２３０１）。そのメッセージの受
信に応動してその交換機が、そのディレクトリ番号につ
いてポート済指示子をマーク付けする（動作ブロック２
３０３）。この指示子は、もしそのディレクトリ番号が
その後不活動状態になった場合にはリセットされる。

【０１４１】別の実施例においては、点検ブロック５１
（図６）が実行されるのと同時に、遠隔データベースに
問い合わせがなされる。早期問い合わせにより、呼が、
不適切な着信交換機にすぐにルーティングされて動作ブ
ロック２２０３の問い合わせの必要が生じる場合に要す
る時間を節減できる。その結果、もしローカルデータベ
ースが正しい場合には不必要な大量の問い合わせをする
ことにはなるが、ローカルデータベースが正しくない場
合には、呼セットアップ時間を短縮できる。

【０１４２】以上の説明は、本発明の一実施例に関する
もので、この技術分野の当業者であれば、本発明の種々
の変形例を考え得るが、それらはいずれも本発明の技術
的範囲に包含される。

【０１４３】

【発明の効果】以上述べたごとく本発明によれば、ロー
カル及び／又は市外の複数の電話会社及び／又は電話利
用サービス提供会社等の関与する電話呼において、呼を
ルーティングされた着信局交換機に被呼番号のデータが
ないという不具合が発生した際にその旨を、ルーティン
グした側の交換機に返し、そのルーティングした交換機
が、広範囲データベースに問い合わせしてローカルデー
タベースを更新するとともに、その呼の完了を再企図す
るようにした。

【０１４４】これにより、当初に呼を正しくない着信交
換機にルーティングした交換機のローカルデータベース
を自動的に更新させ、その呼も完了させることができる
利点が得られるので、電話通信システムの運用効率の向
上が図れる。従来技術では、上記不具合時にその呼を満
足に処理する方法がなかった。

【図面の簡単な説明】

【図１】本発明の実施に用いられる、複数の交換機が共
有するデータベースに接続された交換機を示すブロック
図である。

【図２】上記交換機のメモリに格納されるデータ及びプ
ログラムのメモリレイアウトの説明図である。

【図３】上記交換機のメモリに格納されるデータ及びプ
ログラムのメモリレイアウトの説明図である。

【図４】上記交換機のプロセッサが実行する方法の流れ
図である。

【図５】上記交換機のプロセッサが実行する方法の流れ
図である。

【図６】上記交換機のプロセッサが実行する方法の流れ
図である。

【図７】上記交換機のプロセッサが実行する方法の流れ
図である。

【図８】上記交換機のプロセッサが実行する方法の流れ
図である。

【図９】上記交換機のプロセッサが実行する方法の流れ
図である。

【図１０】或る特定の実施例のブロック図である。

【図１１】或る特定の実施例のブロック図である。

【図１２】図１０及び図１１の実施例の流れ図である。

【図１３】図１０及び図１１の実施例の流れ図である。

【図１４】図１０及び図１１の実施例の流れ図である。

【図１５】図１０及び図１１の実施例の流れ図である。

【図１６】実施例を説明する別のブロック図である。

【図１７】実施例を説明する別のブロック図である。

【図１８】実施例を説明する別のブロック図である。

【図１９】本発明の実施方法の流れ図である。

【図２０】本発明の実施方法の流れ図である。

【図２１】本発明の実施方法の流れ図である。

【図２２】本発明の実施方法の流れ図である。

【図２３】本発明の実施方法の流れ図である。

【符号の説明】

１、２ ビットマップ ３ 交換機システム（交換機） ４ 汎用データベース １０ プロセッサ １５ ＣＰＵ １７ メモリ １８ プログラム ２０ テーブル ２１、２２、２３ エントリ ２４、２５、２６ 指示子 ３０ ポインタ １０１〜１０５ 個別顧客 １０６〜１１０、２０４ ローカル（市内）交換電話会
社 １１１〜１１３、２１２ 市外交換電話会社 １１４、１１７ 交換機 １１５、２１１ 全国汎用データベース（ＮＵＤＢ） １１６、１１９ 課金記録システム １１８、２０３ ローカル汎用データベース（ＬＵＤ
Ｂ） ２０１ サービス集中管理システム ２０２ 個別ローカル電話会社・ローカル（市内）番号
ポートサービス管理システム ２１０ 市外電話会社・ローカル（市内）番号ポートサ
ービス管理システム ７０１、７０３、８０１、８０３ 顧客 ７１１、７２１、８１１ ローカル（市内）交換電話会
社 ７１３、７２３、８１３ 競合アクセス提供会社 ７１５、７２５、８１５ ケーブルＴＶ提供会社 ７３１ 入口交換機（発信側） ７３３ 出口交換機（着信側） ７４１ 全国汎用データベース ８４１ ローカル汎用データベース ９０１、９０２、９０３ 電話機 ９１１、９１２、９１３ 端局 ９１５、９１６ アクセス中継局 ９２０、９２１ 市外電話会社 ９３０、９４０ テーブル ９３１、９３２、９４２ エントリ ９５１ ローカル（市内）汎用データベース ９５２ 全国汎用データベース １９０１ メッセージ種類フィールド １９０３ 回線番号 １９０５ 原因コード

───────────────────────────────────────────────────── フロントページの続き (71)出願人 596077259 600 Ｍｏｕｎｔａｉｎ Ａｖｅｎｕｅ, Ｍｕｒｒａｙ Ｈｉｌｌ， Ｎｅｗ Ｊｅ ｒｓｅｙ 07974−0636Ｕ．Ｓ．Ａ.

Claims (16)

【特許請求の範囲】
1. 【請求項１】 ローカル番号集中データベースを有する
   通信ネットワークにおいて、被呼ディレクトリ番号を取
   り扱わない着信交換機に宛てられた電話呼を処理するた
   めの、電話呼処理方法であって、 前記電話呼をルーティングするために交換機内のデータ
   ベースにアクセスするステップと；前記交換機内の前記
   データベースから与えられたデータに基づいて前記電話
   呼をルーティングするステップと；前記電話呼について
   の解放メッセージであってその解放メッセージを送信す
   る交換機内で前記電話呼のディレクトリ番号に対応する
   回線が見出されないことを指示する原因コードを有する
   ような解放メッセージ、の受信に応動して、複数の交換
   機が共有する前記ローカル番号集中データベースから受
   信された応答を、前記交換機内の前記データベースのデ
   ータと比較するステップと；もし前記２個のデータ量が
   一致しない場合に、前記ローカル番号集中データベース
   から受信されたデータに基づいて前記電話呼をルーティ
   ングし且つ前記交換機内の前記データベースを前記ロー
   カル番号集中データベースから受信されたデータで更新
   するステップと；からなることを特徴とする電話呼処理
   方法。
2. 【請求項２】 前記方法が更に、 前記交換機内の前記データベースが前記電話呼のルーテ
   ィングについての位置ルーティング番号を与えるステッ
   プからなることを特徴とする請求項１の方法。
3. 【請求項３】 前記方法が更に、 前記位置ルーティング番号に対応する着信交換機が、前
   記着信交換機が前記被呼ディレクトリ番号を取り扱わな
   いとの決定に応動して前記解放メッセージを生成するス
   テップからなることを特徴とする請求項２の方法。
4. 【請求項４】 前記解放メッセージを生成するステップ
   が、解放メッセージを米国規格協会原因コード２６号で
   生成するステップからなることを特徴とする請求項３の
   方法。
5. 【請求項５】 前記電話呼の着信交換機が、前記解放メ
   ッセージを与えるが空きコード告知を与えないことを特
   徴とする請求項１の方法。
6. 【請求項６】 前記交換機内の前記データベースが、位
   置ルーティング番号を与えないが、前記電話呼のルーテ
   ィングについて前記被呼ディレクトリ番号を用いること
   を特徴とする請求項１の方法。
7. 【請求項７】 前記方法が、 前記被呼ディレクトリ番号の局コードに対応する着信交
   換機が、その着信交換機が前記被呼ディレクトリ番号を
   取り扱わないことを定めるステップと；前記着信交換機
   が、前記被呼ディレクトリ番号についてポート済指示子
   がセットされているかどうかを点検するステップと；も
   し前記ポート済指示子がセットされている場合に、前記
   解放メッセージを送信するステップと；からなることを
   特徴とする請求項６の方法。
8. 【請求項８】 前記解放メッセージが、米国規格協会原
   因コード２６号と同等の原因コードからなることを特徴
   とする請求項７の方法。
9. 【請求項９】 前記方法が更に、 もし前記ポート済指示子がセットされていない場合に、
   空きコード告知を返すステップからなることを特徴とす
   る請求項７の方法。
10. 【請求項１０】 前記方法が更に、 この交換機が現に取り扱っているディレクトリ番号につ
    いての取り扱いが別の交換機にポートされていることを
    指示するメッセージの受信に応動して、前記ディレクト
    リ番号についてポート済指示子をセットするステップか
    らなることを特徴とする請求項７の方法。
11. 【請求項１１】 もし前記解放メッセージを生成する交
    換機が前記電話呼についてのメッセージ内で位置ルーテ
    ィング番号を受信した場合に、前記解放メッセージが第
    １の原因コードを有し、もし前記解放メッセージを生成
    する交換機が前記電話呼についてのメッセージ内で位置
    ルーティング番号を受信しなかった場合に、前記解放メ
    ッセージが、前記第１の原因コードとは異なる第２の原
    因コードを有することを特徴とする請求項１の方法。
12. 【請求項１２】 前記方法が更に、 もし前記２個のデータ量が一致する場合に、呼不規則状
    態報告を生成するステップからなることを特徴とする請
    求項１の方法。
13. 【請求項１３】 通信ネットワークの交換機において、
    被呼ディレクトリ番号について正しくないデータを問い
    合わせ側交換機が有するかどうかを検出するための、番
    号データ状態検出方法であって、 企図された着信交換機への着信呼についての、前記被呼
    ディレクトリ番号からなるメッセージの受信に応動し
    て、前記企図された着信交換機が前記被呼ディレクトリ
    番号を取り扱うかどうかを点検するステップと；もし前
    記企図された着信交換機が前記被呼ディレクトリ番号を
    取り扱わない場合、前記被呼ディレクトリ番号について
    ポート済指示子がセットされているかどうかを点検する
    ステップと；もし前記ポート済指示子がセットされてい
    る場合に、米国規格協会原因コード２６号と同等の原因
    コードからなる解放メッセージを送信するステップと；
    からなることを特徴とする番号データ状態検出方法。
14. 【請求項１４】 もし前記メッセージが位置ルーティン
    グ番号を含んだとした場合の前記メッセージについての
    前記原因コードが、もし前記メッセージが位置ルーティ
    ング番号を含まなかったとした場合の前記メッセージに
    ついての前記原因コードと異なることを特徴とする請求
    項１３の方法。
15. 【請求項１５】 ローカル番号集中データベースを有す
    る通信ネットワークにおいて、被呼ディレクトリ番号を
    取り扱わない着信交換機に宛てられた電話呼を処理する
    ための、電話呼処理方法であって、 前記電話呼をルーティングするために交換機内のデータ
    ベースにアクセスするステップと；前記交換機内の前記
    データベースから与えられたデータに基づいて前記電話
    呼をルーティングするステップと；前記電話呼のルーテ
    ィングと同時に前記ディレクトリ番号を用いて、複数の
    交換機が共有する前記ローカル番号集中データベースに
    問い合わせるステップと；前記電話呼についての解放メ
    ッセージであってその解放メッセージを送信する交換機
    内で前記電話呼のディレクトリ番号に対応する回線が見
    出されないことを指示する原因コードを有するような解
    放メッセージの受信に応動して、前記複数の交換機が共
    有する前記ローカル番号集中データベースから受信され
    た応答を、前記交換機内の前記データベースのデータと
    比較するステップと；もし前記２個のデータ量が一致し
    ない場合に、前記ローカル番号集中データベースから受
    信されたデータに基づいて前記電話呼をルーティングし
    且つ前記交換機内の前記データベースを前記ローカル番
    号集中データベースから受信されたデータで更新するス
    テップと；からなることを特徴とする電話呼処理方法。
16. 【請求項１６】 ローカル番号集中データベースを有す
    る通信ネットワークにおいて、被呼ディレクトリ番号を
    取り扱わない着信交換機に宛てられた、発信交換機から
    の電話呼を処理するための、電話呼処理装置であって、 前記装置が、 前記発信交換機内のプロセッサ手段からなり、 前記プロセッサ手段が、 前記交換機のためのローカルデータベースと；プログラ
    ムと；からなり、 前記プロセッサ手段は、前記プログラムの制御下で作動
    して、 前記ローカルデータベースから与えられたたデータに基
    づいて前記電話呼をルーティングする動作と；前記電話
    呼についての解放メッセージであってその解放メッセー
    ジを送信する交換機内で前記電話呼のディレクトリ番号
    に対応する回線が見出されないことを指示する原因コー
    ドを有するような解放メッセージの受信に応動して、前
    記ディレクトリ番号を用いて、複数の交換機が共有する
    前記ローカル番号集中データベースに問い合わせる動作
    と；前記ローカル番号集中データベースから受信された
    応答を、前記交換機内の前記データベースのデータと比
    較する動作と；もし前記２個のデータ量が一致しない場
    合に、前記ローカル番号集中データベースから受信され
    たデータに基づいて前記電話呼をルーティングし且つ前
    記交換機内の前記データベースを前記ローカル番号集中
    データベースから受信されたデータで更新する動作とを
    行うことを特徴とする電話呼処理装置。