JPH11507490A - 国際電話番号を処理するシステムおよび方法 - Google Patents

Abstract

(57)【要約】 外国電話番号をその番号のアドレスの種類に従って解析する装置および方法。具体的には、方法は、電話ネットワークのインテリジェント・サービス・コントロール・ポイントで電話番号を解析する方法は電話番号のアドレスの種類を国内、国際、またはその他として判断するステップ（６１０）と、その電話番号のフィールドをアドレスの種類に従って抜き出すステップ（６１５）とを含む。

Description

【発明の詳細な説明】 国際電話番号を処理するシステムおよび方法 １．関連出願の相互参照 本出願は「国際電話番号を処理するシステムおよび方法(System and Method f or Processing International Telephone Numbers)」という発明の名称で１９９ ６年１月１１日に出願され、現在係属中である米国仮特許出願第６０／００９， ６４２号の関連出願であり、この米国出願を基礎にして優先権を主張したもので ある。 ２．技術分野 本発明はアドバンスド・インテリジェント・ネットワーク(Advanced Intellig ent Network)のコール処理の分野に関する。さらに具体的には、本発明は国際電 話番号を処理する方法およびシステムに関する。 ３．発明の背景 Ａ．ＥＴＳＩおよびＩＮＡＰ ヨーロッパ・テレコミュニーション標準協会(European Telecommunication St andards lnstitute - ＥＴＳＩ)はインテリジェント・ネットワーク・アプリケ ーション・プロトコル（Intelligent Network Application Protocl - ＩＮＡＰ ）を開発しており、これは現在ETSI Core INAPという名称で呼ばれている。この Core INAPは、インテリジェント・ネットワーク（Intelligent Network - ＩＮ ）サービスの展開をサポートするために必要とされるＩＮＡＰ仕様の基本的機能 を含んでいる。 Core INAPを北米電話システム用の従来の電話ルーチングおよび制御回路上で 実現するためには、変更が必要であり、標準機器には柔軟性の向上が要求されて いる。 Ｂ．電話番号コンポーネント 例えば、北米では、１０桁の電話番号の最初の３桁は、エリア・コード（ＮＰ Ａとも呼ばれる）またはサービス・コード（８００など）を指定しているのが通 常であり、次の３桁は交換局または中央局コード（ＮＮＸまたはＮＸＸとも呼ば れる）を表し、最後の４桁はNPA-NXX内の特定の回線を表している。 北米の外では、電話番号は長さおよびフォーマットが異なっていることがよく ある。このような電話番号は先頭の桁でエリアを指定することも可能になってい るが、これらの「エリア・コード」、または「シティ・コード」とも呼ばれてい るコードも、長さが異なっていることがよくある。また、電話番号パラメータの フォーマットと内容は変化し、異種のパラメータを表す用語がそうであるように 、異なったダイアリング・シナリオをもっている。混乱を避けるために、以下の 説明では、異なる電話番号コンポーネントを示すために以下の用語を用いている 。 「国内有効番号(National Significant Number)」という用語は、加入者のダ イアリング・エリア・コードとローカル加入者番号を含む完全にクリファイドさ れた加入者番号のことである。「ダイアリング・エリア・コード」は北米のＮＰ Ａがそうであるのと同じように、電話ネットワーク内の異なる地理的エリアを示 している。「ローカル加入者番号」は、コーラ（呼出し側）と同じダイアリング ・エリアにいる加入者にアクセスするためにダイアルされる番号である。 「国内ダイアリング・プレフィックス(Local Diaｌing Prefix)」という用語 は「トランク・プレフィックス(trunk prefix)」と呼ばれることがあり、国内長 距離コールをダイアルするために用いられている。国内ダイアリング・プレフィ ックスはアドレスの種類（Nature of Address - ＮＯＡ）の値が「加入者」値で あるときに存在する。「国内オペレータ選択コード(National Operator Selecti on Code)」という用語は「キャリア選択コード(Carrier Selection Code)」と呼 ばれることがあり、長距離キャリアを選択するために国内ダイアリング・プレフ ィックスと国内有効番号の前にダイアルされる桁のことである。「国際プレフィ ックス(International Prefix)」または「国際オペレータ選択コード(Internati on Operator Selection Code)」という用語は、国際キャリア を選択するために国内コードと国内有効番号の前にダイアルされる桁のことであ る。一部のネットワーク・オペレータでは、国際オペレータ選択コードは国際ダ イアリング・プレフィックスとしても使用されている。他にも、特殊な番号や雑 多な番号がある。その一例として、８００のようなサービスを提供するサービス ・コードがある。 上記に鑑みて、複数の異なる国からの電話番号を認識してその番号に応答する と共に、電話スイッチング機器が柔軟性をもって異なる電話番号のフォーマット に適応するようにする電話スイッチング・ネットワークが要望されている。 ４．発明の開示 以上のように、本発明は、外国電話番号をその番号のアドレスの種類に従って 解析する装置および方法を提供することを目的としている。具体的には、電話番 号を電話ネットワークのインテリジェント・スイッチで解析する方法は電話番号 のアドレスの種類を国内、国際、またはその他として判断し、電話番号のフィー ルドをアドレスの種類に従って抜き出すステップを含んでいる。 本発明による電話通信システムは電話コールをルーチング（経路選択）する複 数のスイッチと、電話コールをルーチングするためのデータを含む複数のデータ ベースと、複数のスイッチと複数のデータベースに結合されていて、スイッチに よる電話コールのルーチングをそのコールの電話番号に従って制御する複数のイ ンテリジェント・サービス・コントロール・ポイントとを備えている。各サービ ス・コントロール・ポイント（Service Control Point - ＳＣＰ）は電話番号の アドレスの種類を国内、国際、またはその他として判断する手段と、電話番号の フィールドをアドレスの種類に従って抜き出す手段とを含んでいる。 上述した概要説明と以下の詳細説明はどちらも、単なる例示であり、解説的な ものである。これらの説明は特許請求の範囲に記載されている本発明をさらに詳 しく解説している。 ５．図面の簡単な説明 本明細書と一体になり、その一部を構成している添付図面は本発明の一実施形 態を示しているが、これらの図面は明細書の説明と共に、本発明の目的、利点、 および原理を理解しやすくすることを目的としている。これらの図面において、 図１は本発明が組み込まれているアドバンスド・インテリジェント・ネットワ ークの主要コンポーネントを示す概要図である。 図２は図１のＡＩＮ内のエレメントに置かれていて、コール処理を担当するコ ール・コントロール・ファンクションを示す図である。 図３は本発明の好適実施形態における主要処理ステップを示すフローチャート である。 図４は図１に示す実施形態において解析される複数の電話コンポーネントを示 す図である。 図５は本発明の好適実施形態用にアプリケーションの作成で使用されるいくつ かのテーブルを示す図である。 図６は本発明による解析プロシージャのフローチャートである。 図７は本発明の第１エラー処理プロシージャのいくつかのステップを示すフロ ーチャートである。 図８は本発明の第２エラー処理プロシージャのいくつかのステップを示すフロ ー図である。 ６．発明を実施するための最良の形態 １．ベースライン・ネットワーク・コンポーネントとオペレーションの説明 本発明の好適実施形態は構成可能ナンバリング・プラン・フィーチャ(Configu rable Numbering Plan feature)であり、このフィーチャはアドバンスド・イン テリジェント・ネットワーク（ＡＩＮ）内のＩＳＣＰ（Intelligent Service Co ntrol Point：インテリジェント・サービス・コントロール・ポイント）がCoreI NAPネットワーク・オペレータのために多数の異なる電話ナンバリング・プラン を処理できるようにする機能を備えている。図１はＡＩＮ１００の基本コンポー ネントを示す概要図である。 ＡＩＮ１００はコール処理制御情報が、シグナリング・システム７ (Signaling System 7 - ＳＳ７)プロトコルを使用する共通チャネル・シグナリ ング・ネットワークを経由して電話ネットワーク内のエレメント間で受け渡され ることを可能にしている。この構成によると、ＳＳＰ１１０、１２０はコールを 完成または処理するために必要とされる情報に関してＩＳＣＰ１３０、１４０に クエリーすることが可能になっている。 ＩＳＣＰにクエリーするように装備されたスイッチはサービス・スイッチング ・ポイント（Service Switching Point - ＳＳＰ）機能、または同じ働きをする サービス・スイッチング機能(Service Switching Function - ＳＳＦ)を備えて いる。ＳＳＰはＡＩＮスイッチング・システム、すなわち、着信コールおよび送 信コールのトリガを検出すると、コールを処理するための情報を得るためにＩＳ ＣＰへのクエリーを生成するＡＩＮスウィッチング・システムである。ＩＳＣＰ １３０、１４０はサービス・コントロール機能(Service Control Function-ＳＣ Ｐ)の能力をもっている。これらはコール処理情報の集中レポジトリの働きをす るデータベース１５０、１６０をサポートし、外部コール処理指示を出す。シグ ナル・トランスファ・ポイント（Signal Transfer Point - ＳＴＰ）は図１に示 されていないが、これらはメッセージをＳＳＰとＩＳＣＰの間で転送するパケッ ト・スイッチである。 ＡＩＮ１００はコール処理情報をＩＳＣＰ１３０、１４０に集中化して複数の ＳＳＰがアクセスできるようにする。ＳＳＰ１１０、１３０は８００コールのよ うに、特殊な取り扱いを必要とするある種のコールであると認識すると、ＳＳＰ はＩＳＣＰ１３０、１４０を通して中央データベースへのクエリーを送出する。 これに対して、ＩＳＣＰ１３０、１４０の方は、無料電話番号（例えば、８００ または０１３０）を中継するといった、コール処理指示を中央データベース１５ ０、１６０から取り出し、取り出した情報をＳＳＰ１２０、１３０に戻してコー ルを完成させるか、あるいは他のコール処理の取り扱いを行う。 ESTI CORE INAP標準を取り入れることにより、本発明の好適実施形態によれば 、標準ＡＩＮアーキテクチャから得られる機能は、ＳＳＰが種々の追加条件に応 答してクエリーを出せるようにすることによって拡張されている。さらに、好適 実施形態によれば、標準の情報セットがＳＳＰ装備のＳＳＰとＩＳＣＰの間で 送信されるようにし、その結果、ＩＳＣＰが種々の条件に応答し、ＳＳＦのアク ションに対する制御を強化できるようにしている。 ＩＳＣＰ１３０、１４０は、ＳＰＡＣＥサービス作成環境１７０およびＭＳＡ Ｐ（Multi-Service Application Platform：多重サービス・アプリケーション・ プラットフォーム）クエリー処理環境と共に、グラフィカル・サービス定義言語 を使用してESTI Core INAPメッセージの情報内容を利用し、着信パラメータ値に 基づいて判断を行うようにしている。同じグラフィカル・サービス定義言語は、 ＳＳＰでコール処理を行うときのガイドとなる送出メッセージに渡されるパラメ ータの値も決定する。 本発明の好適実施形態では、ＭＳＡＰおよびＳＰＡＣＥをベースとするＣＰＲ （Call Processing Recored - コール処理レコード）を使用している。ＳＳＰ１ １０、１２０はコール処理情報を要求するトリガを、ＭＳＡＰおよびＳＰＡＣＥ ベースのＣＰＲが実行されているＩＳＣＰ１３０、１４０に送信することによっ てコールに応答する。ＭＳＡＰはある種のトリガ情報に対応するＳＰＡＣＥベー スの ＣＰＲを実行してコール処理指示をスイッチに送り返す。 ＩＳＣＰソフトウェア機能を使用すると、ＳＰＡＣＥサービス・クリエータは 電話番号コンポーネントを参照し、これらのコンポーネントに対応させたサービ ス・ロジックを開発することができる。ISCP MSAP機能を使用すると、サービス ・ロジックをベースとする電話番号コンポーネントをリアルタイムのコール処理 環境で実行させることができる。 しかし、現行ＩＳＣＰソフトウェアは３つの固定コンポーネント、つまり、Ｎ ＰＡ、ＮＸＸ、および回線番号をもつ１０桁電話番号を取り扱う。従来のＩＳＣ Ｐ機能を使用すると、ＩＳＣＰサブシステム、具体的には、ＳＰＡＣＥおよびデ ータとレポート・システム（Data and Reports System - ＤＲＳ）が電話番号表 示を行うことも可能になっている。 ＳＰＡＣＥシステムはＡＩＮサービス・ロジック・プログラムを表すコール処 理レコードの開発をサポートしている。ＳＰＡＣＥサービス作成環境では、サー ビス・ロジックをサービス・グラフ、すなわち、その「ノード」がサービス処理 指示を表しているサービス・グラフを通して指定する。これらのノードをどのよ うに接続するかにより、サービス処理のフローが決まる。 ＳＰＡＣＥ ＣＰＲはＳＳＰクエリーメッセージで開始されるサービス要求を 処理するための異なるエントリ・ポイントを表しているサービス・グラフ同士を 結合する。特定のエントリ・ポイント、つまり、サービス・グラフを選択する時 の基準は、ＳＳＰクエリーメッセージが発信された個所のＳＳＰトリガ検出ポイ ント（Trigger Detection Point - ＴＤＰ）とすることができる。 ETSI Core INAPの修正では、コール・モデル(Call Model)を通して構造をスイ ッチ・ベースのコール処理に接続する構造が付加されている。コール・モデルに は、状態遷移をイベントに基づいて記述しているところのコール状態とフローの シーケンスとが用意されている。コール・モデルはネットワーク・スイッチで実 行されるコール処理を抽象化したもので、コール処理をステップのシーケンスに 分割している。 ＴＤＰは必要な基準に合致したときＳＳＰがＩＳＣＰに対するクエリーをそこ から起動できる、コール処理内のポイントを表している。コール・モデルはポイ ント・イン・コール(Points-In-Call - ＰＩＣ)および検出ポイント(Detection Points - ＤＰ)と呼ばれるエンティティを定義している。ＰＩＣはコール状態と 、あるコールが到達したコール処理ステップを表している。ＤＰはＡＩＮサービ ス・ロジック処理を呼び出すこと、検知することが可能で、ＰＩＣの処理を表し ている。 ＳＳＰに実装されているコール・コントロール・ファンクション（Call Contr ol Function-ＣＣＦ）はコール処理をコントロールし、ネットワーク接続サービ スを提供する。ＣＣＦはコール処理期間のＡＩＮトリガリングおよびＡＩＮ機能 へのアクセスをサポートする。同じくＳＳＰに実装されているサービス・スイッ チング・ファククション(Service Switching Function - ＳＳＦ)はスイッチ上 のコール処理ソフトウェアとサービス・コントロール・ファンクションとの間の やりとり（インターラクション）をサポートする。 図２はコール処理を担当するＣＣＦエンティティ２００を示している。ＣＣＦ エンティティ２００はＡＩＮコール・モデルを実現したものを含んでいる。 ＡＩＮコール・モデルに定義されている検出ポイントの１つである、ＤＰ２１０ は一人または二人以上のＡＩＮカスタマーのためにＴＤＰとして使用可能にされ ている。コール処理がＤＰ２１０まで到達すると、ＣＣＦ２００はＴＤＰ要求（ ＴＤＰ−Ｒ）２１５をＳＳＰ内のＳＳＦエンティティ２２０に送信し、その後で コール処理を中止する。 ＳＳＦエンティティ２２０はトリガリング基準をチェックし、サービス・イン ターラクソンを解決し、ＩＳＣＰ内のＳＣＦ２００とのインタフェース・オペレ ーションを操作する。ＳＣＦ２００はＡＩＮサービス・ロジックを実行し、ＳＳ Ｆエンティティ２２０とのインタフェースを通してスイッチでのコール処理に影 響を与える。これは機能的にはＩＳＣＰ内のＭＳＡＰと大体同じである。 ＳＳＦエンティティ２２０はＣＣＦエンティティ２００からＴＤＲ−Ｒ２１５ を受信すると、ＳＳＦエンティティ２００はクエリーメッセージ２２５をＳＣＦ ２３０に送信し、そこでサービス・ロジックはそのメッセージを処理する。図２ に示すＳＣＦ２３０の応答メッセージはコール処理のための指示と、そのあとで 行われるコール処理イベント時に通知される要求を含んでいる。イベント・レポ ート要求は図２のＤＰ２００をイベント検出ポイント(Event Detection Point - ＥＤＰ)として準備状態にする。 初期クエリーメッセージに応答して送信されたＳＣＦエンティティ２３０の指 示はコール処理期間に実行される。その後のコール処理期間にＤＰ２４０が現れ たときは、イベント・レポート・メッセージ２４５がＳＣＦ２３０に送信され、 そのエンティティでサービス・ロジックを起動するが、そこからはコール処理の ための追加指示が出される場合もある。 ＴＣＡＰトランザクションをオープンするために ＳＳＰから送信される初期 メッセージは「クエリーメッセージ」とも、「ＳＳＰクエリーメッセージ」とも 呼ばれることがある。例えば、ＳＣＰエンティティ２３０がＡＩＮコールに介入 することを開始するためにＳＳＦエンティティ２２０から送信されるCore INAP の InitialDPオペレーションはクエリー（ＴＣ−開始）メッセージの中で送信さ れる。 ここで「応答」という用語は、以前に受信されたメッセージに応答して送信さ れる一切のメッセージのことを意味する。これはＴＣＡＰトランザクションの最 終メッセージのこともあれば、ＴＣ−終了メッセージのこともあれば、トランザ クション期間の中間メッセージである、ＴＣ−継続メッセージのこともある。 「メッセージ」という用語は、実際には、ＳＳＦまたはＳＣＦなどのＡＩＮエ レメントがそのパートナ上で呼び出しできるインタフェース・オペレーションの ことを意味する。「メッセージ」という用語が「オペレーション」という用語と 同じ意味で使用されているのは、Core INAP内に定義されているもののように、 インタフェース・オペレーションがインタフェース・パートナ間でやりとりされ るＴＣＡＰメッセージ内にパッケージされているためである。 ＴＣＡＰメッセージは複数のオペレーションの呼び出しを含むことができる。 ＴＣＡＰメッセージ内の各オペレーション要求は単一のＴＣＡＰコンポーネント 構造内にパッケージされている。例えば、ＡＩＮビリング（billing）情報をＳ ＳＰに伝える課金情報提供(Furnish Charging Information)オペレーションは、 コール・ルーチングに関係する別のオペレーションの呼び出しと一緒に単一のＴ ＣＡＰメッセージ内にパッケージすることができる。 ＳＰＡＣＥコール変数（Call Variab1e - ＣＶ）はＳＰＡＣＥサービス・グラ フ、つまり、ＣＰＲのコンテキストで定義されたサービス・ロジック・プログラ ム変数である。ＳＰＡＣＥコール変数には、「事前定義」コール変数、「ユーザ 定義」コール変数、および「環境」コール変数の３つのカテゴリがある。Core I NAPフィーチャ用のＳＰＡＣＥシステムにおける事前定義コール変数のセットに は、後述するメッセージとパラメータの詳細な説明の個所にリストされている、 すべてのCore INAPメッセージ・パラメータが含まれている。ユーザ定義コール 変数には、ＣＰＲまたはサービス・グラフ内で使用するためにサービス・クリエ ータによって定義された追加の変数が含まれる。環境コール変数は事前に定義さ れ、時刻（time of the day - ＴＯＤ）および曜日（day of the week - ＤＯＷ ）などの「ステート(state)」情報を含んでいる。 本発明の好適実施形態では、ジェネリック・データ駆動型(generic，data-dri ven)アプローチを採用している。Core INAPネットワーク・オペレータ固有デー タ・ファイルをもつ構成可能ナンバリング・プラン・フィーチャは、（１） コンポーネント別に分類された電話番号（ＴＮ）をスクリーンとレポートで表示 する機能、および（２）電話番号をＴＮコンポーネントに対応するアドレス可能 サブフィールドについて解析する機能を備えている。好適実施形態では、ＩＳＣ ＰソフトウェアはＩＴＵ(CCITT)標準に準拠するナンバリング・プランをサポー トしている。 ２．システム・オペレーションの概要 図３はCore INAPの関数（ファンクション）を処理する主要部分を示すフロー チャート３００である。ＩＳＣＰは着信メッセージをESTI Core INAPメッセージ として認識すると（ステップ３１０）、ＩＳＣＰはそのメッセージを該当のサー ビス・ロジックに転送する（ステップ３２０）。 次に、ＩＳＣＰはそのメッセージをあるサブシステム番号と一緒に、ＭＳＡＰ のESTI Core INAPメッセージ処理機能に転送する（ステップ３３０）。そのあと 、ＩＳＣＰは長いメッセージをサポートするメッセージ・セグメンテーション関 数を実行する（ステップ３４０）。このメッセージ・セグメンテーション関数は ＳＳ７ネットワークから受信したメッセージ・セグメントを組み立て直して、完 全なアプリケーション・メッセージにする。 ＩＳＣＰはＥ．１６４番号でアドレスされることも、シグナリング・ポイント ・コードでアドレスされるようにすることもできる。ＩＳＣＰは、メッセージ、 すなわち、そこへ転送されてきて、ＩＳＣＰのＥ．１６４番号が「被呼加入者ア ドレス・フィールド」にグローバル・タイトルとしてコーディングされているメ ッセージを受け取る。 ＩＳＣＰはメッセージの処理を終えると、リターン・メッセージを送信する（ ステップ３５０）。このリターン・メッセージの中で、ＩＳＣＰは着信起呼加入 者アドレスを出力メッセージ内の被呼加入者アドレスとして、着信被呼加入者ア ドレスを出力メッセージの起呼加入者アドレスとしてコーディングする。 ＩＳＣＰは、出力メッセージのグローバル・タイトルを変換し、グローバル・ タイトルをシグナリング・ポイント・コードにマッピングする機能も備えている 。このシグナリング・ポイント・コードは出力メッセージをルーチングすると き使用される。 ＭＳＡＰのサービス・キー分析アルゴリズムは、主に着信ETSI Core INAPメッ セージの中のいくつかのパラメータに基づいてETSI Core INAPメッセージを分析 する。これらのパラメータとしては、オペレーション・コード、サービス・キー 、起呼加入者番号、被呼加入者番号、イベント・タイプＢＣＳＭなどがある。Ｍ ＳＡＰはこれらのパラメータの値を着信メッセージから抜き出し、その値を判断 ロジックにマッピングして着信メッセージを処理することができる。 好適実施形態を動作させる上で重要な動作原理がいくつかある。第一は、ＴＮ をサブフィールドに分解する関数のような、ＴＮ処理関数は、国際オペレータ選 択コード／プレフィックスおよび国際番号、すなわち、サービス・ロジックに組 み込まれているか、あるいは着信ＡＩＮメッセージ内に存在する国際オペレータ 選択コード／プレフィックスおよび国際番号だけを解析する。第二は、ＮＯＡの ＳＳＰポピュレーション(population)ルールは、どのＮＯＡコーディング・ルー ルが選択されるかに関係なく同じであることである。 第三は、オペレータ選択コード（キャリア・コード）はCore INAPネットワー ク・オペレータ・ダイアリング・エリア・コードの１つと同じ値にできないこと である。これにより、ＩＳＣＰがオペレータ選択コードの存在を判断することが できる。第四は、サービス・コードはユニークであるので、他のどのプレフィッ クス（例えば、オペレータ選択コードまたはエリア・コード）とも同じになるこ とも、その一部になることもない。これはサービス・コードの存在を判断する上 で重要である。 第五は、サービス番号はオペレータ選択コードなしでダイアルされることであ る。第六は、構成可能ナンバリング・プラン機能を駆動するデータ・ファイルは 各ネットワーク・オペレータごとにＩＳＣＰプロジェクトによって作られ、その 後Core INAPネットワーク・オペレータのサイトに送付されることである。 第七は、オペレータ選択コードまたはエリア・コードまたは特殊プレフィック スはＩＳＣＰソフトウェアのインストール後に拡張できることである。Core INA Pネットワーク・オペレータはCore INAPサイトで正しいテーブル／データ・ファ イルに新規コードやプレフィックスを追加するとき正しいプロシージャに従 わなければならない。 第八は、ＩＳＣＰはローカル電話番号の加入者サブフィールドをさらに２つの 追加フィールド、つまり、交換コードと回線番号について解析できることである 。第九は、Core INAPアウトバウンド電話タイプ・パラメータについては、サー ビス・クリエータは各ケースごとに正しいＮＯＡフォーマットを選択し、そのＮ ＯＡの期待コーディング・ルールに従って正しい桁フォーマットをポピュレート (populate)しなければならないことである。 ３．電話番号の解析 ＩＳＣＰは電話番号をいくつかのコア・コンポーネントに分けて解析する。す べての電話番号データ・タイプ／パラメータは少なくとも３つのフィールドを含 んでいる。すなわち、ＮＯＡ、ナンバリング・プランおよびアドレス桁（つまり 、実際の電話番号）である。ＩＳＣＰが「アドレス桁」フィールド内の電話番号 をそのコンポーネントに分けて解析するときのルールはＮＯＡフィールドの値に よって決まる。 ＩＳＣＰ解析ルールはすべてのCore INAP電話番号データ・タイプ／パラメー タに適用される。ＩＳＣＰは図４に示す電話コンポーネント、つまり、（１）ダ イアリング・エリア・コード４１０、（２）ローカル加入者番号４２０、（３） 国内オペレータ選択コード４３０、（４）国際プレフィックスまたは国際オペレ ータ選択コード４４０、および（５）特殊番号／サービス・コード４５０を認識 し、解析する。図４に示すように、各コンポーネントは各電話番号ごとに存在し ない場合もあり得る。 Core INAPネットワーク特有データ・ファイルは次のようなコンポーネントを サポートしている。つまり、（１）ダイアリング・エリア・コード、（２）国内 オペレータ選択コード、（３）国際プレフィックスまたは国際オペレータ選択コ ード、および（４）特殊番号−サービス・コードである。ソフトウェアはこれら のデータ・ファイルにアクセスして、これらの電話コンポーネントに正確に一致 するものを見つける。しかし、本発明の好適実施形態では、国際プレフィックス ／国際オペレータ選択コードの後の国際番号は解析されない。 各Core INAPネットワーク・オペレータは図５に示す４つのＳＰＡＣＥテーブ ルをもち、そこには次のようなＴＮコンポーネントが収められている。（１）エ リア・コードのリスト５１０、（２）国内オペレータ選択コードのリスト５２０ 、（３）国際オペレータ選択コードのリスト５３０、および（４）特殊番号プレ フィックスとサービス・コードのリスト５４０である。ＭＳＡＰサービス・ロジ ック実行時とＳＰＡＣＥ電話番号表示時には、これらのテーブルが共用される。 Core INAPネットワーク・オペレータは、Core INAPコール実行時またはＳＰＡＣ ＥによるＴＮの表示時に汎用Core INAPライブラリ・ルーチンを呼び出すときに もこれらのテーブルを使用する。 ＩＮＡＰ電話番号解析ルーチンはCore INAP電話番号データ・タイプ構造を受 け取り、解析された種々のコンポーネントを戻す。このルーチンは解析の結果と して次のＴＮコンポーネントの１つまたは２つ以上を出力するが、どの電話番号 の場合も、これらのコンポーネントのすべてが存在するとはかぎらない。 ａ） ダイアリング・エリア・コード（長距離ダイアリング・プレフィック スを含んでいる）またはサービス・コード（ダイアリング・コードとサービス・ コードは相互に排他的であると想定する） ｂ） ローカル加入者番号 ｃ） 国内オペレータ選択コード ｄ） 国際プレフィックスまたは国際オペレータ選択コード ｅ） 国際番号の残余部分（国コード＋エリア・コード＋加入者桁を含んで いるが、国際プレフィックスまたは国際オペレータ選択コードは含まれない） ｆ） 国内有効番号（テーブルに一致するものが見つからないためエリア・ コードが解析できないとき使用される） ｇ） 全桁受信（構成可能ナンバリング・プラン・フィーチャの呼び出し前 の全桁を含んでいる） 国内有効番号は「発明の背景」で説明したように、オペレータ選択コードの後 の残余桁（エリア・コード＋加入者桁）を表している。全桁受信はSSPから受信 されたものと正確に同じ桁数を含んでいる。 ＩＳＣＰは図６に示す解析プロシージャ６００に従ってＴＮを解析する。いく つかの異なるCore INAP解析ルールはＮＯＡの値によって決まる。ＴＮを解析す る前にＩＳＣＰはすべての桁を「全桁」コンポーネントとして「解析ＴＮ構造」 内にセーブしておく。ＩＳＣＰは好ましくは、次のようなフィールドをもつ解析 ＴＮ構造内に種々のＴＮコンポーネント断片をストアしておく。つまり、エリア ・コード、ｓｖｃコード、ｏｐｓｅｌコード、ｓｕｂ ｎｂｒ、全桁、natsig n brである。 解析プロシージャ６００において、最初のステップでＮＯＡが分析される（ス テップ６０５）。ＮＯＡ＝加入者または未知またはオペレータ選択であれば、次 のステップで国際プレフィックスまたは国際オペレータ選択コードが検査される （ステップ６１０）。 国際プレフィックスまたは国際オペレータ選択コードのどちらかが存在してい れば（つまり、正確に一致するものが"IOpSel Code NOS"テーブルにあれば）（ ステップ６１０）、ＩＳＣＰはこれらのコードを解析し（ステップ６１５）、以 後の解析を中止する。国際プレフィックスまたは国際オペレータ選択コードが解 析されると、ＴＮフォーマットの残余部分は国コード＋エリア・コード＋加入者 桁であるものと期待される。従って、ＩＳＣＰは国際プレフィックス／オペレー タ選択コードだけを"Parsed TN Structure"にセーブしておき（ステップ６２０ ）、呼出し側ルーチンに戻る（ステップ６３０）。 国内オペレータ選択コードが存在していれば（正確に一致するものが"NOpSel Code NOS"テーブルにあれば）（ステップ６３２）、ＩＳＣＰ は国内オペレー タ選択コードを解析し（ステップ６３５）、その「国内オペレータ選択」コード を"Parsed TN Structure"にセーブしておく（ステップ６４０）。また、ＩＳＣ Ｐ解析はＴＮ桁の残余部分の（長距離プレフィックス＋エリア・コード）＋（加 入者桁）について解析することを続ける（ステップ６４５）。 エリア・コードが存在していれば（つまり、「ダイアリング・プレフィックス ＋エリア・コード」に一致するものが"Area Code NOS"テーブルに存在していれ ば）（ステップ６５０）、ＩＳＣＰは解析を中止する。この場合には、「ダイア リング・プレフィックス＋エリア・コード」コンポーネント値はサービス・ロジ ック内に「エリア・コード」ＴＮコンポーネント選択として使用可能になってい る（つまり、ダイアリング・プレフィックスは除かれていない）。残りの桁は加 入者番号桁になっている。そのあと、ＩＳＣＰは「エリア・コード」と「加入者 桁」を"Parsed TN Structure"にセーブしておき（ステップ６５５）、呼出し側 ルーチンに戻る（ステップ６３０）。長距離プレフィックスは各Core INAPネッ トワーク・オペレータについて固定値になっており、長距離コールのエリア・コ ードの先頭に付加される。また、Area Code NOSテーブルには、正しいダイアリ ング・プレフィックスが付加されたエリア・コードが入っている。 条件によっては、エラー処理プロシージャＡが必要になる場合がある。図７は これらのプロシージャを示している。「ダイアリング・プレフィックス＋エリア ・コード」を、例えば、ＩＳＣＰが一致するものをテーブルの中で見出せないた め解析できないときは、桁の残り部分（エリア・コード＋加入者桁）は「ダイア リング・プレフィックス」と一緒に「国内有効番号」ＴＮコンポーネントとして "Parsed TN Structure"にセーブされる（ステップ７１０）。その後、ＩＳＣＰ ソフトウェアは呼出し側ルーチンに戻る（ステップ７２０）。 オペレータ選択コードが存在していなければ、電話番号フォーマットは次のも のの１つになる。つまり、（１）長距離コールＴＮフォーマット、（２）特殊番 号／ＳＶＣコード番号、（３）加入者番号、または無効番号（エラー）である。 エラー処理ルーチンは各フォーマットごとに異なっている。 フォーマットが長距離コールＴＮであれば（ステップ７３０）、ＩＳＣＰソフ トウェアはエリア・コードが存在するかどうかを判断する（ステップ７３５）。 これは、好ましくは、「ダイアリング・プレフィックス＋エリア・コード｝が"A rea Code NOS"テーブル内のエントリに一致しているかどうかチェックすること によって行われる。そうであれば、ＩＳＣＰは番号を解析し（ステップ７４０） 、呼出し側ルーチンに戻る（ステップ７２０）。他方、エリア・コードが存在し ていなければ（ステップ７３５）、ＩＳＣＰは呼出し側ルーチンに戻るだけであ る（ステップ７２０）。 フォーマットが特殊番号であれば（ステップ７３０）、ＩＳＣＰソフトウェア は特殊番号が存在するかどうかを判断する（７４５）。これは、好ましくは、正 確に一致するものが"SVC Code NOS"テーブルにあるかどうかをチェックすること によって行われる。存在しなければ、ＩＳＣＰは呼出し側ルーチンに戻るだけで ある（ステップ７２０）。 ＩＳＣＰが一致するものを見つけると、ＩＳＣＰ ソフトウェアはＴＮを２つ のコンポーネント、つまり、「サービス・コード／特殊番号プレフィックス」と 「加入者桁」について解析する（ステップ７５０）。また、ＩＳＣＰは「サービ ス・コード／特殊番号プレフィックス」と「加入者桁・特殊番号」も"Parsed TN Structure"にセーブしておき（ステップ７５５）、そのあと、呼出し側ルーチ ンに戻る（ステップ７２０）。 フォーマットが加入者番号または無効番号であれば（ステップ７３０）、ＩＳ ＣＰソフトウェアは残余桁を「加入者桁」ＴＮコンポーネントとして"Parsed Co de Structure"にセーブしてから（ステップ７６０）、解析を中止し、呼出し側 ルーチンに戻る（ステップ７２０）。このようなことが起こるケースとしては、 次の２つがある。第１のケースは、フォーマットが正しい加入者桁を含んでいる 場合である。第２のケースは、番号が長距離番号またはサービス番号のつもりで いたが、"Area Code NOS"または"SVC Code NOS"テーブルに正しいテーブル・エ ントリがなかった場合である。 第２のケースでは、ユーザはサービス・ロジック内で「加入者番号」として正 しく解析できなかった桁にアクセスすることができる。また、ユーザは「全桁受 信」ＴＮコンポーネントとして ＳＳＰから受信したオリジナル桁にアクセスす ることもできる。 図６に戻って説明すると、ＮＯＡ＝国内であれば（ステップ６０５）、ＩＳＣ Ｐは受信した桁の先頭にダイアリング・プレフィックスを付加する（ステップ６ ６０）。プレフィックスを付加すると、一致するエントリをテーブルから見つけ ることが容易になるので、内部解析が容易化される。 国際プレフィックスまたは国際オペレータ選択コードが存在していれば（ステ ップ６６５） （これは、好ましくは、一致するものを図５に示す"IOpSel Code NOS"テーブル５３０から探すことにより判断される）、ＩＳＣＰ ソフト ウェアは解析を中止し、国際プレフィックス／オペレータ選択コードを"Parsed TN Structure"にセーブしておき（ステップ６７０）、そのあと呼出し側ルーチ ンに戻る（ステップ６３０）。 国際プレフィックスまたは国際オペレータ選択コードが存在しなければ、ＩＳ ＣＰは図８にプロシージャ８００として示されているエラー処理プロシージャＢ に進む。このプロシージャはＴＮフォーマットを次の１つとして識別することか ら開始する。つまり、（１）長距離コールＴＮフォーマット、（２）特殊番号／ ＳＶＣコード番号、または（３）無効番号である（ステップ８０５）。エラー処 理はＴＮフォーマットに従って行われる。 長距離コールＴＮフォーマットの場合は、最初の照会はエリア・コードが存在 するかどうかである（ステップ８１０）。この判断の好ましい方法では、「ダイ アリング・プレフィックス＋エリア・コード」に一致するエントリが図５に示す 。 "Area code NPO"テーブル５１０に存在するかどうかが問い合わされる。存在 すれば、ＩＳＣＰは番号を解析し（ステップ８２０）、呼出し側ルーチンに戻る （ステップ８３０）。この時点では、電話番号には、国固有である「ダイアリン グ・プレフィックス」がまだ付いている。エリア・コードが存在しなければ（ス テップ８１０）、ＩＳＣＰは呼出し側ルーチンに戻る（ステップ８３０）。 特殊番号フォーマットの場合は、最初のクエリーは特殊番号が存在するかどう かである（ステップ８４０）。好ましくは、ＩＳＣＰは正確に一致するものを図 ５に示す"SVC Code NOS"テーブル５４０から探し出す。なければ、ＩＳＣＰは呼 出し側ルーチンに戻る（ステップ８３０）。 ＩＳＣＰが特殊番号に正確に一致するものを見つけると、特殊番号を２つのコ ンポーネント、つまり、「サービス・コード特殊番号プレフィックス」と「加入 者桁」について解析する（ステップ８５０）。ＩＳＣＰソフトウェアは「サービ ス・コード／特殊番号プレフィックス」と「加入者桁／特殊番号」を"Parsed TN Structure"にセーブしておき（ステップ８６０）、そのあと呼出し側ルーチン に戻る（ステップ８３０）。 無効番号の場合は、ＩＳＣＰソフトウェアは残余桁を「加入者桁」ＴＮコンポ ーネントとして"Parsed TN Structure"にセーブしておき（ステップ８７０）、 呼出し側ルーチンに戻るだけである（ステップ８３０）。通常、番号が無効とさ れるのは、それが長距離番号またはサービス番号のつもりでいたが、"Area Code NOS"または"SVC Code NOS"テーブルに正しいテーブル・エントリがなかったた めである。 図６に戻って説明すると、ＮＯＡ＝国際であれば（ステップ６０５）、ＩＳＣ Ｐは桁を解析しない。期待される電話番号フォーマットは国コード＋エリア・コ ード＋加入者桁である。 好ましくは、ＩＳＣＰはＴＣＡＰの解析時にはＴＮコンポーネントを解析しな い。その代わりに、サービス・ロジックの実行時に種々の電話コンポーネントを 解析するが、これはサービス・ロジックが電話コンポーネントへのアクセスを必 要としないからである。 この処理の結果として、種々のＮＯＡ値には次のような桁コーディング・ルー ルが適用される。 １． ＮＯＡ＝加入者／未知／オペレータ選択ならば、期待されるフォーマ ットは次のいずれかである。 ａ） 国際プレフィックス／国際オペレータ選択コード（オプショ ン）＋国コード＋エリア・コード＋加入者桁 ｂ） 国内オペレータ選択コード（オプション）＋長距離プレフィ ックス＋エリア・コード＋加入者桁 ｃ） 特殊番号／サービス・コード＋加入者桁、または ｄ） 加入者桁 ２．ＮＯＡ＝国内ならば、期待されるフォーマットは次のいずれかである。 ａ） 国際プレフィックス／国際オペレータ選択コード（オプショ ン）＋国コード＋エリア・コード＋加入者桁 ｂ） 国内オペレータ選択コード（オプション）＋エリア・コード ＋加入者桁または ｃ） 特殊番号／サービス・コード＋加入者桁 ３．ＮＯＡ＝国際ならば、期待されるフォーマットは次のものである。 ａ） 国コード＋エリア・コード＋加入者桁 ４．ライブラリ・ルーチン 図６〜図８を参照して上述してきた解析を実行するために、ＩＳＣＰとＳＰＡ ＣＥはいくつかのライブラリ・ルーチンを使用する。Find Prefixルーチンは電 話番号と期待ＴＮコンポーネントＩＤを受け取り、"Parsed TN Structure"など の、TN Compnt ID"およびその他の解析ＴＮコンポーネントに指定されている正 しい電話番号に一致するエントリを戻す。ＩＳＣＰまたはＳＰＡＣＥは図５に示 す次のテーブルの１つをサーチして、一致するプレフィックスを見つける。つま り、 (1) TN Compnt ID＝Area Code Compnt IDのときはAREA CODE NOS 510 (2) TN Compnt ID＝NOp Sel Code Compnt IDときはNOPSEL CODE NOS 520 (3) TN Compnt ID＝IOpSel Compnt IDのときはIOPSEL CODE NOS 530または (4) TN Compnt ID＝SVC Code Compnt IDのときはSVC CODE NOS 540 MSAP INTERPRETERはこのルーチンをコールして、SPACE Core INAPノードを含 んでいるサービス・ロジックを実行する。このルーチンは図６ないし図８を参照 して上述した解析ルーチンをコールすることもできる。 ＳＰＡＣＥソフトウェアによってコールされたDisp INAP TNルーチンは電話番 号ストリングを受け取り、表示のためにＳＰＡＣＥが必要とするフォーマットを 戻す。ＴＮの表示を種々のコンポーネントに分けて解析するときのルールは図６ ないし図８を参照して上述したＴＮ解析ルールと同じである。このルーチンは、 加入者番号表示のための加入者番号コンポーネントを解析した後"Disp Subs Nbr "ルーチンをコールすることもできる。 Disp Subs Nbrルーチンは加入者番号コンポーネントを受け取り、加入者番号 を表示するときＳＰＡＣＥまたはＤＲＳソフトウェアが使用するフォーマットを 戻す。加入者番号が偶数の桁数からなる場合は、このソフトウェアは電話番号を ２桁グループで表示する。加入者番号が奇数の桁数からなる場合は、このソフト ウェアは左端の３桁を一ケ所にまとめ、残りの桁を２つのグループに分けて電話 番号を表示する。例えば、４桁の番号の場合は、表示は"348-32"のようになる。 ６桁の番号の場合は、表示は"93-68-29"のようになる。７桁の番号の場合は、表 示は"337-45-05"のようになる。８桁の番号の場合は、表示は"30-67-86-23"のよ うになる。 ServiceKey分析ルーチンは"CallingPartyNumber"または"CalledPartyNumber" をServiceKeyとして判断して、ユーザ定義のServiceKey基準に基づいて必要とす るレコードを見つけることができる。"CallingPartyNumber"または"CalledParty Number"がServiceKeyになったときは、ServiceKeyの値はCore INAP内の「アドレ ス桁」フィールドの値である。国内国際オペレーション選択コードのように、先 頭のプレフィックスがない電話パラメータの場合は、ServiceKeyの値を収めてい るコール変数は、"CallingPartyNumber"または"CalledPartyNumber"内の「アド レス桁」フィールドのプレフィクッスを除いた後ポピュレートされる。 ５．マニピュレータ ＳＰＡＣＥは、電話マニピュレータ(Teｌephone Manipulator)を通してアクセ スしてＴＮを伴う任意のTCAP INAP入力または判断ノード内の電話コンポーネン トを参照する機能を輸している。電話マニピュレータはCore INAP電話番号をサ ポートする。このサポートによると、ユーザは電話コール変数または定数から電 話コンポーネントを抜き出すこともできる。 北米ＴＮ用の現行マニピュレータ関数は次のような構文を使用している。つま り、telcomp(〈tel〉,〈component〉)であり、ここで〈tel〉の個所には電話コ ール変数または定数が入り、〈component〉は「プランＤ」、「番号の種類」、 「エリア・コード値」などの、電話コンポーネント値を表す整数値となる。Core INAPアプリケーションでは、マニピュレータは「ヨーロッパ・ナンバリング・ プラン」に関連する電話関数を備えているので、上述した電話コンポーネントへ のアクセスが可能になっている。 マニピュレータは期待コンポーネントを見つけることができないと、"NULL"nu mstring値を戻す。このようなことが起こるのは、（１）マニピュレータが呼び 出されたが、テーブルが見つからないとき、（２）一致するコンポーネント値が テーブルに見つからないとき、または（３）"CFN EQUIPPED"フラグがオフにされ たためその特定ＴＮコンポーネントでマニピュレータを呼び出しできないときで ある。この最後の条件は、Core INAP電話コンポーネント・マニピュレータ関数 を含んでいるSPACE CPRをアクチベートした後で"CFN EQUIPPED"フラグが"OFF"に 変更されたとき起こることがある。 ６．ＭＳＡＰおよびＳＰＡＣのオペレーション ＭＳＡＰは電話番号を、オペレータ選択コード、ダイアリング・エリア・コー ド、加入者番号などの、種々のコンポーネントに分けて解析することができる。 ＭＳＡＰインタプリータはＣＰＲ実行中に必要時にマニピュレータ関数を呼び出 す。 ＳＰＡＣＥは、電話番号を伴う任意のTCAP INAP入力ノード／判断ノード内の 次のような電話コンポーネントにアクセスし、参照することを可能にする。つま り、（１）ダイアリング・エリア・コードまたはサービス・コード（ダイアリン グ・エリア・コードとサービス・コードは相互に排他的であると想定する）、（ ２）（ａ）国内オペレータ選択コード、（ｂ）国際プレフィックスまたは国際オ ペレータ選択コード、および（ｃ）国際番号の残余部分（３つのコンポーネント （国コード＋エリア・コード＋加入者桁）を有し、国際プレフィックスまたは国 際オペレータ選択コードがない）を含む、ローカル加入者番号、（３）国内有 効番号（オペレータ選択コードの後の桁の残り部分（エリア・コード＋加入者桁 エリア・コードが解析不能のとき（つまり、一致するものがテーブルにないとき ）に使用される）、（４）受信の全桁（構成可能ナンバリング・プラン・フィー チャの呼び出し前の全桁を含んでいるーこのコンポーネントはＳＳＰから受信し たのと正確に同じ桁数を含んでいる）である。国内ダイアリング・プレフィック スについてはサービス・クリエータには使用できない。 ＳＰＡＣＥは電話番号全体を１つのブロックで入力する。各電話コンポーネン トはCore INAP電話タイプ・パラメータのＳＰＡＣＥノード・エディタ内では別 々に入力する必要はない。例えば、ダイアリング・エリア・コードは加入者番号 から別々に入力する必要がない。 ＩＳＣＰは電話番号タイプ・パラメータを任意のフォーマットで、しかも、サ ービス・ロジックがポピュレートする任意の桁と一緒に送信する。サービス・ク リエータは各ケースごとに正しいＮＯＡフォーマットを選択し、そのＮＯＡの期 待コーディング・ルールに従って正しい桁フォーマットをポピュレートする。 ＳＰＡＣＥはESTI Core INAPをサポートするように、次の５つの面で主要な変 更が行われている。第一は、ＳＰＡＣＥは４つの新規事前定義スタンドアロン・ テーブルが追加されたことである。つまり、AREA CODE NOS、NOPSEL CODE NOS、 IOPSEL CODE NOSおよびSVC CODE NOSである。第二は、ＳＰＡＣＥはCalledParty Numbers、CallingPartyNumbers、GenericNumbers、LocationNumbers、およびOri ginalCalledPartyNumbers内のエリア・コード、オペレータ選択コード、および サービス・コードの表示をサポートすることである。第三は、ＳＰＡＣＥはESTI Core INAPをサポートするために北米ナンバリング・プラン・サポートを置き換 えたことである。第四は、ＳＰＡＣＥは必要なコンポーネントによる電話番号の 解析をサポートするように新規のマニピュレータが追加されたことである。第五 は、ＳＰＡＣＥは加入者番号フォーマットをサポートするために新規のデータタ イプである、SubscriberNumberをサポートすることである。 構成可能ナンバリング・プランで使用されるスタンドアロン・テーブルには、 DIGITS(NumString)とDESCRIPTION(String)のフィールドがある。DIGITSフィール ドはキー・フィールドであり、DESCRIPTIONフィールドは非キー・フィールドで ある。 CalledPartyNumber、CallingPartyNumber、GenericNumber、LocationNumberお よびOriginalCalledPartyNumberはエリア・コード、オペレータ選択コード、お よびサービス・コードの表示をサポートする。これらの構造はCore INAPルーチ ンである、"Disp INAP TN()"をコールしてDIGITSフィールドの表示値をセットす る。 ＳＰＡＣＥは新規のデータタイプを使用してローカル加入者番号の表示をサポ ートする。加入者番号は、25-24-84-37-80のように、ペアになった加入者桁のグ ループをダッシュで区切ったフォーマットにされる。ＳＰＡＣＥはオペレータに よって入力されたSubscriberNumberにあるダッシュを無視し、ダッシュを該当の 場所に入れて番号を再表示する。 telcomp()マニピュレータはCore INAP電話複合タイプ(CalledPartyNumber、Ca lｌingPartyNumber、GenericNumber、LocationNumber、およびOriginalCalledPa rtyNumber)を受け付ける。ＭＳＡＰは新規のマニピュレータＩＤを使用するので Find Prefixルーチンは北米ナンバリング・プランからのもの(NPA-NXX-XXXX)で はなく、構成可能ナンバリング・プラン・コンポーネントを識別する。telcomp( )マニピュレータの第２アーギュメント（引数）は好ましくは、コンポーネント 名とする。 ＳＰＡＣＥが始動され、構成可能ナンバリング・プラン・テーブルのいずれか に不一致が見つかると、ＳＰＡＣＥはエラー・テキストと共にダイアログ・ボッ クスを生成することによって各不一致ごとに説得力のあるエラーを出す。しかし 、ＳＰＡＣＥは実行を続けるので、ユーザはその機会を利用してＳＰＡＣＥをロ ードし、不一致を除くように構成可能ナンバリング・プラン・テーブルを変更す ることができる。 テーブルに不一致が見つかるたびに、ＳＰＡＣＥはオリジナル定義を戻し、エ ラー・メッセージを表示した後、処理中の現行不一致エントリを無視する。しか し、構成可能ナンバリング・プラン・テーブルのいずれかをアクチベートさせる ためには、その前に、ユーザはすべての不一致を解決しておかなければならない 。 ＳＰＡＣＥの新規データタイプである、"SubscriberNumber"は構成可能ナンバ リング・プランをサポートする。SubscriberNumberは加入者番号ＴＮコンポーネ ントを収めているNumStringにすぎない。 TelComponentAsnノードはユーザが指定したコール変数に電話コール変数(例え ば、CalledPartyNumber)の桁コンポーネントを割り当てる。ユーザによって指定 されるコール変数はNumStringでなければならない。ＩＮのTelComponentノード とは異なり、Core INAPのTelComponentAsnノードでは、ユーザは複数の組み合わ せ（例えば、ＮＰＡ＋ＮＸＸ）ではなく、単一のコンポーネントだけを選択する ことができる。 電話ＩＮＡＰ入力ノードでは、ユーザは次のコンポーネントの１つについて判 断を行うことができる。つまり、（１）国際オペレータ選択コード、（２）国際 番号の残余部分、（３）国内オペレータ選択コード、（４）ダイアリング・エリ ア・コード、（５）加入者番号、および（６）全コンポーネントである。図９は Core INAPインバウンド電話パラメータ、そのデータタイプ、およびそれらが使 用されるオペレーションのテーブルを示す図である。 構成可能ナンバリング・プランをサポートする電話判断ノードには（１）Call edPartyNumberDed、（２）CallingPartyNumberDed、 （３）GenericNumberDed、および（５）OrigCalledPartyNumberDedの５つがある 。 ７．Core INAPルーチン Core INAPメッセージ・セット初期化ルーチンはいくつかのファンクション（ 関数）を提供する。つまり、（１）構成可能ナンバリング・プラン・テーブル・ タグ／値をサポートし、（２）Core INAPメッセージ・セット初期化ルーチン内 のTelecomponentマニピュレータ関数に対する関数ポインタを提供し、（３）Ｍ ＳＡＰが始動されが、テーブルが見つからないか、あるいは構成可能ナンバリン グ・プラン・テーブルのいずれかに不一致または正しくないエントリがあると、 エラー・メッセージを出し、アラームをログに記録し、初期化を中止す る。 Core INAPネットワーク・オペレータ固有の構成ファイルは次の情報を収めて いる。つまり、（１）INAP DIALING PREFIX、（２）AREACODETBL、（３）OPSELT BL、（４）IOPSEL TBL、および（５）SVC CODE TBLである。タグ値はネットワー ク・オペレータ間で異なる値にすることができる。ＩＳＣＰはテーブル名の一部 に正しい国サフィックスが付いている構成可能ナンバリング・プラン・テーブル を含んでいる。例えば、AREA CODE FIN またはAREA CODE TEL.SVC CODE FINまた はSVC CODE TEL,OPSEL CODE FINまたはOP SELECT TELである。 さらに、機能強化されたServiceKey分析ルーチンは構成可能ナンバリング・プ ラン・フィーチャがオンにされたか、オフにされたかを、構成可能ファイル"ism s cfg.dat"内の"CIN CFN EQUIPPED"フラグから判断する。現在は、ServiceKey分 析ルーチンはＴＣＡＰパーサによってデコードされたＴＣＡＰメッセージ・パラ メータからテーブル・ルックアップを実行して、ServiceKey基準のタイプを判断 し、サービス・キー値の値を判断している。ServiceKey一致基準に応じて、"Ser viceKey"、"CallingPartyNumber"、または"CalledPartyNumber"パラメータはSer viceKey値になる。 従来のServiceKey分析では、ＩＳＣＰはCallingPartyNumberまたはCalledPart yNumberの先頭にプレフィックスをもつＴＮを受信している。この分析では、Ｃ ＰＲキーに一致するものを見つけるデータベース・ルックアップに先立ってこの プレフィックスを取り除いてから、ServiceKey値、つまり、"CallingPartyNumbe r"または"CalledPartyNumber"に一致する名前をもつＣＰＲを探すようにしてい る。例えば、オペレーション選択コードをダイアルして行われる長距離コールは 、"CalledPartyNumber"パラメータの先頭に国内オペレータ選択コードが付加さ れている。"CalｌedPartyNumber"がServiceKey値になったときは、CalledPartyN umberパラメータの先頭の「オペレータ選択コード」プレフィックスを取り除い て、正しいＣＰＲ名が得られるようにしなければならない。 そのために、新規のServiceKey分析ルーチンには、"SVK Remove Prefix"ルー チンへの関数コールが追加され、電話番号に付加されたオペレータ選択コードを 取り除くようにしている。また、この分析ルーチンは、CallingPartyNumberまた はCalledPartyNumberがServiceKey値になったとき、どのプレフィックス（オペ レータ選択コード）も付いてない電話番号をCore INAP Service Keyコール変数 に入れる。このルーチンは構成可能ナンバリング・プラン・フィーチャがオンに されたときだけ起動される。 ８．メッセージおよびパラメータ 事前定義コール変数はユーザに用意されていないデータ・タイプを使用するこ とができる。これらの追加データ・タイプには、列挙（enumerated）型、構造お よびシーケンスがある。シーケンスは配列に似ているが、シーケンス内の各エレ メントは同じデータ・タイプである必要はないので必ずしも同種である必要はな い。Core INAPはユーザ定義構造、列挙（enumerations）またはシーケンスをサ ポートしていない。 ＩＳＣＰはこれらの着信ＩＮＡＰメッセージ・パラメータの各々の値を受け取 って、処理し、ＭＳＡＰはその値を抜き出し、ServiceKey分析のいくつかの着信 メッセージ・パラメータで選択されたサービス・ロジックに基づいて判断を行う 。これらは（１）サービス・キー、（２）被呼加入者番号、（３）起呼加入者番 号、（４）被呼加入者カテゴリ、（５）検出ＣＧ、（６）ロケーション番号、（ ７）オリジナル被呼加入者ＩＤ、（８）上位層互換性、（９）サービス・インタ ラクション・インジケータ、（１０）追加の起呼加入者番号、（１１）フォワー ド・コール・インジケータ、（１２）ベアラ機能、（１３）イベント・タイプＢ ＣＳＭ、（１４）リダイレクト加入者ＩＤ、（１５）リダイレクション情報、（ １６）カウンタの値（例えば、カウンタＩＤおよびカウンタ値）、（１７）フィ ルタリング基準（サービス・キーまたは被呼アドレス値＋サービス・キー＋起呼 アドレス値＋ロケーション番号）、および（１８）エクステンションがある。 ＳＰＡＣＥには、これらの着信メッセージ・パラメータを処理するためにＭＳ ＡＰで使用されるサービス・ロジックをグラフィカル・ユーザ・インタフェース でサポートする構造(constructs)が用意されている。好ましい構造とし ては、着信メッセージ・パラメータとそれに基づく判断ノードによってポピュレ ートされた事前定義コール変数がある。 ９．トランザクション・インジェクタ トランザクション・インジェクタ(Transaction Injector - ＴＩ)は上記に列 挙されているパラメータに基づいて次の２つのメッセージを生成する。すなわち 、（１）初期ＤＰオペレーション・メッセージと（２）RequestReportBCSMEvent メッセージである。 以下では、図２のメッセージ・オペレーションについて詳しく説明する。ＳＳ Ｆエンティティ２２０は、ＡＩＮコール処理期間に準備状態にある(aramed)トリ ガ検出ポイントを見つけると、初期ＤＰオペレーション・メッセージをＳＣＦエ ンティティ２３０に送信する。その後で、ＳＳＦエンティティ２２０はコールに 関する情報をＳＣＦエンティティ２３０に送信して、ＳＣＦエンティティ２３０ とコールとの間にコントロール関係を確立する。ＳＣＦエンティティ２３０は、 初期ＤＰメッセージに応答して送信するCore INAPメッセージを通してコール処 理に影響を及ぼすことができる。EventTypeBCSMパラメータは検出されたＤＰを 示している。 ＳＳＦエンティティ２２０はＩＮがサポートするサービスのコールのたびに一 度だけ初期ＤＰオペレーション・メッセージを送信するのが代表的である。ＳＳ Ｆエンティティ２２０はRequestReportBCSMEventメッセージを使用して、ＡＩＮ コールに関連する以後のイベントに関する情報を要求する。このようなケースで は、ＳＳＦ２２０はコールとのコンロール関係を維持することができる。 InitialDP オペレーション・メッセージは次のようなパラメータをサポートし ている。すなわち、サービス・キー、被呼加入者番号、起呼加入者番号、起呼加 人者カテゴリ、検出ＣＧ、ロケーション番号、オリジナル被呼加入者ＩＤ、上位 層互換性、サービス・インタラクション・インジケータ、追加起呼加入者番号、 フォワード・コール・インジケータ、ベアラ機能、イベント・タイプＢＣＳＭ、 リダイレクト加入者ＩＤ、リダイレクション情報、検出ｓＦ、ギャップ・イン ターバル（データ・タイプ：インターバル）である。 サービス・キー(ServiceKey)パラメータは唯一の必須パラメータであり、ＣＰ Ｒを選択してＩＳＣＰクエリー処理を制御するように起動されたＩＳＣＰサービ ス・キー分析プロセスへの唯一の入力にすることができる。サービス・キー・パ ラメータは厳格にユニーク・テーブルまたはデータベース・キーとなることを目 的とした整数である。サービス・キー分析で使用できる他のパラメータとしては 、EventTypeBCSMパラメータ、被呼加入者番号パラメータ、起呼加入者番号パラ メータおよび起呼加入者カテゴリがある。 EventTypeBCSMパラメータは着信InitialDPメッセージがどのＴＤＰから出され たものかを示している。異なるコール・モデル検出ポイントから出されたＳＳＰ クエリーメッセージはその全部または一部が一人のカストマによって加入されて いる異なるサービスに対応させることができる。そのようなケースでは、カスト マはサービス・レコードに関連する複数のサービス・ロジック・プログラムＳＬ Ｐをもつことができる。EventTypeBCSMパラメータはどのＳＬＰがＳＳＰクエリ ーメッセージに応答して実行されるかを示している。 被呼加入者番号(Called PartyNumber)パラメータと起呼加入者番号(Calling P artyNumber)パラメータはその名前が示すとおりである。 CallingPartyCategory（起呼加入者カテゴリ）パラメータはコールを出した端末 またはカスタマーのタイプも示している。検出ＣＧ(CG Encountered)パラメータ はコール・ギャッピングがＳＳＰでエンゲージされているかどうかを示している 。ロケーション番号(Location Number)パラメータは起加入者の地理的エリア・ アドレスを伝達する。オリジナル被呼加入者ＩＤ(Original Called Party ID)パ ラメータとリダイレクト加入者ＩＤ(Redirecting Party ID)パラメータは処理中 のコールが開始側SSFに到達する前に転送またはリダイレクトされたときＳＣＦ に送信される。リダイレクト情報(Redirecting Information)パラメータはコー ルがリダイレクトされた回数といったように、コール・リダイレクションに関係 する情報を伝達する。 上位層互換性(High Layer Compatibility)パラメータとベアラ機能(Bearer Ca pability)はＩＳＤＮサービスに関係する。フォワード・コール・インジケー タ(Forward Call Indicators)パラメータは複数のプロバイダ・ネットワークに スパンするコールに関する情報を伝達する。追加起呼加入者番号(Additional Ca lling Party Number)パラメータは、複数のネットワークにスパンするコールの アドレス情報を伝達するために使用される。 ＳＳＦはServiceFilteringResponseOperation(ＳＦＲＯ)メッセージを使用し て、以前に要求されたActivateServiceFiltering(ＡＳＦ)メッセージの中で指定 されたコール・カウンタの値をＳＣＦに送信する。これを行うとき、ＳＦＲＯメ ッセージはＡＳＦメッセージの中でＳＣＦによって指定されたフィルタリング基 準を繰り返す。 ＳＦＲＯメッセージは次のようなパラメータも収めている。すなわち、カウン タＩＤ、カウンタ値、サービス・キー、被呼加入者アドレス、起呼アドレス値、 およびロケーション番号である。カウンタ値パラメータはオリジナルＡＳＦメッ セージの結果として作成された各カウンタの増分カウントを収めている。カウン タと、オリジナルＡＳＦメッセージで指定された電話番号との間には１対１の対 応関係がある。各カウンタのサブパラメータ値はそれが関連づけられている電話 番号の最後の２桁に一致している。 フィルタリング基準パラメータはＡＳＦ要求の中で送信された同じパラメータ のプレイバックであり、サービス・フィルタリング要求をサービス・フィルタリ ング応答と関係づけるために使用できる。 送出される非会話型メッセージのパラメータとしては、（１）デスティネーシ ョン・ルーチング・アドレス、（２）警告パターン、（３）カットアンドペース ト、（４）オリジナル被呼加入者ＩＤ、（５）ルート・リスト、（６）サービス ・インタラクション・インジケータ、（７）起呼加入者番号、（８）起呼加入者 カテゴリ、（９）リダイレクト加入者ＩＤ、（１０）リダイレクション情報、（ １１）（被呼アドレス値、サービス・キー、ロケーション番号、およびギャップ オンサービス）を含むギャップ基準、（１２）ギャップ・インジケータ（持続時 間とギャップ・インターバル）、（１３）コントロール・タイプ、（１４）ギャ ップ処理（送信する情報とリリース原因）、（１５）ＳＣＩビリング特性、（１ ６）LegID、（１７）フィルタされたコール処理（ＳＣＦビリング特性、送 信する情報、In-BandInfo、メッセージＩＤ、繰り返し回数、持続時間、インタ ーバル、トーン、トーンＩＤ、トーン持続時間、および最大カウンタ数）、（１ ８）フィルタリング特性（インターバルとコールの数）、（１９）フィルタリン グ・タイムアウト（持続時間と停止時間）、（２０）フィルタリング基準（サー ビス・キー、アドレスとサービス・キー、被呼アドレス値、起呼アドレス値、お よびロケーション番号）、（２１）開始時間、（２２）ＦＣＩビリング課金特性 、（２３）タイマＩＤ、（２４）タイマ値、（２５）原因、および（２６）エク ステンションがある。 ＳＰＡＣＥには、上記の送出ＴＣＡＰメッセージ・パラメータを設定するため にＭＳＡＰが使用するサービス・ロジックをグラフィカル・ユーザ・インタフェ ースでサポートするための構造が用意されている。そのような構造には、送出メ ッセージ・パラメータをポピュレートするために使用されるＳＰＡＣＥ事前定義 コール変数およびそれらに値を割り当てる割り当てノードがある。 ＭＳＡＰは着信メッセージの処理中に検出されたサービス・ロジック構造に基 づいてメッセージを生成する。各メッセージはそのＴＣＡＰオペレーション・コ ード・パラメータによってユニークに特徴づけられる。 ＳＰＡＣＥにも、他の送出ＴＣＡＰメッセージを生成するためにＭＳＡＰによ って使用されるサービス・ロジックをグラフィカル・ユーザ・インタフェースで サポートする構造が用意されている。ＴＩはＴＩによって生成されたＩＳＣＰイ ンバウンド・メッセージに応答してＭＳＡＰから送信されたある種のメッセージ を受け付ける。 ＳＣＦはConnect Operationメッセージを使用してＳＳＦエンティティにコー ル・ルーチング情報を提供する。このメッセージは次の情報を収めている。すな わち、デスティネーション・ルーチング・アドレス（被呼加入者番号のシーケン ス）、警告パターン、カットアンドペースト、オリジナル被呼加入者ＩＤ、ルー ト・リスト、サービス・インタラクション・インジケータ、起呼加入者ＩＤ、起 呼加入者カテゴリ、リダイレクト加入者ＩＤ、リダイレクション情報である。 必須パラメータである、デスティネーション・ルーチング・アドレスはルーチ ング番号を収めている。このパラメータはＳＳＰがルーチング番号として使用で きる番号のリストを含むことも可能である。ルート・リスト・パラメータはスイ ッチに常駐する事前定義送出トランク・グループのリストを使用してコールを完 成するようにＳＳＦエンティティに指示することができる。カットアンドペース ト・パラメータは被呼加入者番号の中の桁をいくつ削除して、デスティネーショ ン・ルーチング・アドレス・パラメータの内容で置き換えるかを指定している。 コール・ギャップ(Call Gap)オペレーションはＳＣＦエンティティに過負荷状 態が起こったとき、ＳＳＦがＳＣＦに送信する初期クエリーメッセージの量を低 減化する。ＳＣＦは特定のサービスに関係するメッセージのような、ある種のメ ッセージの送出を制限するようにコール・ギャップ・オペレーションを限定する ことができる。このオペレーションは次のパラメータを収めている。すなわち、 被呼アドレス値、被呼アドレス値とサービス、ギャップオン・サービス、起呼ア ドレスとサービス、持続時間、ギャップ・インターバル、コントロール・タイプ 、送信する情報、およびリリース原因である。 ギャップ基準(Gap Criteria)パラメータはコール・ギャッピング・オペレーシ ョンを限定する。コール・ギャッピングは、特定のサービス、被呼番号または起 呼番号、またはサービスと被呼または起呼番号の組み合わせに基づくことができ る。ギャップ・インジケータ(Gap Indicators)パラメータはコール・ギャッピン グの持続時間と、ＳＳＦエンティティが初期クエリーをＳＣＦに送信できる頻度 、つまり、フィルタリング頻度とを設定する。コントロール・タイプ(Control T ype)パラメータはコール・ギャッピングが自動であるか、手動であるかを示して いる。ギャップ処理(Gap Treatment)パラメータはフィルタで除去されたＡＩＮ コールをどのように終了させるかを指定している。 被呼アドレスとサービス・パラメータおよび起呼アドレスとサービス・パラメ ータを使用すると、サービス・キーと被呼番号または起呼番号の両方に基づいて ＳＣＦにコール・ギャッピングを要求させることができる。 課金情報送信オペレーション(Send Charging Information Operation)メッセ ージはＳＣＦからのコール課金指示をＳＳＦエンティティに伝達する。このメッ セージはＡＩＮコールのビリング・レコードが非INスイッチに登録されてい るとき使用される。ＳＳＦエンティティはこのメッセージで伝達された情報を使 用して、ビリング・レコードを登録しようとしている交換局に課金指示を通知す る。 課金情報送信オペレーション・メッセージは２つのパラメータを収めている。 すなわち、ＳＣＩビリング課金特性とLegIDである。ＳＣＩビリング課金特性(Bi lling Charging Characteristics)パラメータはコール課金を制御する通知に関 する情報をＳＳＦエンティティに伝達する。種々の交換および相互交換施設は異 なる方法でコール課金情報を通知しているので、このパラメータは特定のネット ワーク・オペレータに特定している。LegIDパラメータは課金通知がコールの起 呼加入者側の交換局に送られるか、被呼加入者側の交換局に送られるかを示して いる。 ＳＣＦはオペレーション継続メッセージを使用して、基本的コール処理を続行 するようにＳＳＦエンティティに指示する。コールに関係するデータはＳＣＦか らＳＳＦエンティティに渡されない。ＳＳＦエンティティは最後の検出ポイント がトリガされたＰＩＣからコール処理を続行するだけである。継続オペレーショ ンにはパラメータはない。 InitiateCallAttemptオペレーションを使用すると、ＳＣＦはシングル被呼加 入者へのコール試みをＳＳＦエンティティを通して開始することができる。この オペレーションは、RequestReportBCSMEventオペレーションおよび継続オペレー ションと一緒にこの順序で１つのＴＣＡＰメッセージに入っている。InitiateCa llAttemptオペレーションを受信すると、ＳＳＦエンティティはＳＣＦ開始コー ルの処理を開始し、ＤＰＩでのコール処理を一時中止する。ＳＳＦエンティティ は最初に、Reque stReportBCSMEventオペレーションを処理してコールの後、続 イベント検出ポイントを使用可能にし、次に、継続オペレーションを処理してコ ール処理を再開させる。このオペレーションは次のパラメータを収めている。デ スティネーション・ルーチン・アドレス（被呼加入者番号のシーケンス）、警告 パターン、サービス・インタラクション・インジケータおよび起呼加入者番号で ある。 デスティネーション・ルーチング・アドレス(Destination Routing Address) パラメータはコールすべき番号を収めている。警告パターン(Alerting Pattern) パラメータは独特のリンギングを要求する。サービス・インタラクション・イン ジケータ(Service Interaction Indicators)パラメータはネットワーク・オペレ ータ固有である。起呼加入者番号パラメータはコールの起呼加入者番号を指定す るが、コールに適用可能な他のサービスに関連して使用できる。 ＡＳＦ(Activate Service Filtering)メッセージを使用すると、ＳＣＦは特定 の電話番号または特定の電話番号群へのコールを「フィルタリング」するように ＳＳＦエンティティに指示することができる。ここで言うコールの「フィルタリ ング」はトーンまたはアナウンスへのコールを中止することである。メッセージ ・パラメータに指定されたインターバル（経過時間またはコールの数）で、ＳＳ Ｆエンティティはフィルタにかけられた各番号との間のコールの数をＳＣＦに送 信する。 このメッセージの１つの使い方は電話投票(televoting)サービスである。例え ば、電話投票する番号をダイアルすると、その投票の受信を確認するメッセージ が生成され、ＳＳＦエンティティはカウンタをインクリメントする。そのあと、 ＳＳＦエンティティは電話番号の各々に関連するカウンタの値をServiceFilteri ngResponseメッセージで送信する。ＳＳＦエンティティはどのコールにおいても 、ＳＣＦの介入なしでコール・フィルタリングを実行する。 以下に示すパラメータはＡＳＦメッセージと共に呼び出すことができる。フィ ルタにかけられたコール処理（ｓＦビリング課金特性、送信する情報（インバン ド情報（メッセージＩＤ、繰り返し回数、持続時間、インターバル）、トーン（ トーンＩＤと持続時間））、最大カウンタ数、リリース原因）、フィルタリング 特性（インターバルまたはコールの数）、フィルタリング・タイムアウト（持続 時間、停止時間（日付と時刻））、フィルタリング基準（サービス・キー、アド レスとサービス（被呼アドレス値、サービス・キー、起呼アドレス値、ロケーシ ョン番号））、開始時間（日付と時刻）。 フィルタにかけられたコール処理(Filtered Call Treatment)パラメータは、 フィルタにかけられたコールをどのような方法でビリングして終了させるか（例 えば、トーンによってか、アナウンスによってか）を指定している。このパラ メータはどれだけのカウンタ、従ってどれだけの電話番号を特定のサービス・フ ィルタリング要求でカバーさせるかも指定している。サービス・フィルタリング 要求でカバーされた電話番号は次のように計算される。 CalledAddressValue ←CalledAddressValue＋(MaximumNumberOfCounters-1) この計算には２つの制約がある。第一は、被呼アドレス値サブパラメータの最 後の２桁は(100 - MaximumNumberOfCounters)より大であってはならないことで ある。第二は、MaximumNumberOfCountersサブパラメータがないと、カウンタ値 がＳＣＦに戻されないことである。 フィルタリング特性(Filtering Characteristics)パラメータはＳＳＦエンテ ィティからの応答の頻度を指定している。各応答は初期ＡＳＦメッセージで作成 されたカウントの各々の増分コール・カウントを収めている。フィルタリング・ タイムアウト(Filtering Time Out)パラメータはサービス・フィルタリングの要 求持続時間を示している。フィルタリング基準パラメータは電話番号、被呼番号 および、オプションとして、ＳＳＦエンティティでサービス・フィルタリングを トリガする電話番号を指定している。開始時間(Start Time)パラメータはＳＳＦ エンティティでサービス・フィルタリングを開始する日付と時刻を指定している 。 送信する情報(Information to Send)パラメータはコーラ側（起呼(celer)側） に送出されるアナウンスに関する情報を伝達するInband Infoサブパラメータと 、コール側に送出されるトーンに関する情報を伝達するtoneサブパラメータを含 んでいる。これらの２パラメータは相互に排他的である。 メッセージＩＤ(Message ID)パラメータはコール側に送出されるアナウンスに 関する情報も伝達する。このパラメータは単一のメッセージ（アナウンス）ＩＤ または複数のＩＤを指定することができる。さらに、このパラメータは「ブラン クに埋め込む(Fill in the blank)」オプションをサポートするメッセージＩＤ を指定することができる。 Core INAPはこのオペレーションのためにRESULTを定義している。RESULTには パラメータはない。これはＡＳＦメッセージが受け付けられて、実行されるとの ＳＳＦエンティティからの確認通知にすぎない。 ＳＣＦはFurnishChargingInformationメッセージを使用して、ＡＩＮコールの 課金に関係する情報をＳＳＦエンティティに提供する。このオペレーションはFu rnishChargingInformationメッセージ・コンポーネント内でＳＣＦからＳＳＦエ ンティティに送信されたビリング情報がネットワーク・オペレータ固有であると き使用される。 ＦＣＩビリング課金特性パラメータはFurnishChargingInformationメッセージ で送られる唯一のパラメータであり、コール課金情報を伝達する。ネットワーク ・オペレータはオペレータがＩＳＣＰに制御させたい側面から見たコール課金を 表すサブパラメータを含むようにこのパラメータを定義することができる。 ＳＣＦは ReleaseCallOperationメッセージを使用して、ＳＳＰでのコールの リリースを要求する。リリースするコールを特定するために、ＳＳＰはReleaseC allOperationを収めている、ＴＣＡＰメッセージのトランザクション部分の中の トランザクションＩＤを使用する。ＳＳＰはCauseパラメータを使用して、コー ルで加入者に対し特定のトーンを生成することができる。 DisconnectForwardConnectionオペレーションは支援側ＳＳＦエンティティま たはＳＲＦからコールを切り離すようにＳＳＦエンティティに指示する。ＳＣＦ は、支援側ＳＳＦエンティティまたはＳＲＦでのコーラとのやりとりの完了時 に、DisconnectForwardConnectionオペレーション要求を開始側ＳＳＦエンティ ティに送信する。ＳＣＦはこのオペレーション要求が送信された後、サービス・ ロジックの実行を続けることができる。 ＳＣＦはResetTimerオペレーションを使用して、ＳＳＦエンティティ内の特定 のタイマ、例えば、ＳＣＦ応答タイムアウト条件を検出するために使用されるタ イマの値をリセットする。新規のタイマ値はタイマ値(Timer Value)パラメータ によって、ResetTimerメッセージ内に指定することができる。タイマＩＤとタイ マ値パラメータはこのメッセージで送られる唯一のパラメータである。タイマＩ ＤパラメータはリセットすべきＳＳＦエンティティのタイマを指定する。デフォ ルト・タイマＩＤはＴ_SSFであり、これはＳＣＦからの応答とコーラとのやりと りの完了のために使用されるタイマである。 ＩＳＣＰとＳＳＰとの間の会話型やりとり（conversational interaction）は 、ＩＳＣＰが ＳＳＰからメッセージを受信し、ＩＳＣＰとＳＳＰが会話型やり とりに入るべきであると、サービス・ロジックを通して判断した後、受信したメ ッセージに応答してメッセージがＩＳＣＰからＳＳＰに送信されることにより開 始される。このやりとりは、ＩＳＣＰがメッセージをＳＳＰに送信し、なんらか の特定アクションを実行し、その結果を送り返すようにＳＳＰに要求することに よって行われる。会話はＳＳＰが報告情報を収めているメッセージをＩＳＣＰに 返送すると続行される。 送出される会話型メッセージのパラメータには、次のものがある。すなわち、 （１）リソース・アドレス（ＩＰルーチング・アドレス（被呼加入者番号））（ ２）送信する情報（インバンド情報、メッセージＩＤ、繰り返し回数、持続時間 、インターバル、トーン、トーンＩＤ、およびトーン持続時間）、（３）ＩＰか らの切離し禁止、（４）要求アナウンス完了、（５）収集情報（最小桁数、最大 桁数、応答終了桁、キャンセル桁、開始桁、第１桁タイムアウト、インタ桁タイ ムアウト、エラー処理、割込み可能アナウンス・インジケータ、音声情報、およ び音声バック）、（６）ＢＣＳＭイベント（イベント・タイプＢＣＳＭ、モニタ ・モード、LegID、Ｄｐ指定基準、桁数、およびアプリケーション・タイマ）、 （７）要求情報タイプ・リスト、（８）ａＣｈビリング課金特性、（９） ＳＣへ計算送信インジケータ、（１０）課金する加入者(Leg ID)、（１１）支援 側ＳＳＰＩＰルーチング・アドレス、（１２）課金イベント、および（１３）エ クステンションである。 ＭＳＡＰは上記に列挙した各送出ＴＣＡＰメッセージ・パラメータの値を、サ ービス・ロジックに基づいて設定する。ＳＰＡＣＥには、サービス・ロジックを グラフィカル・ユーザ・インタフェースでサポートするための構造が用意されて いる。ＳＰＡＣＥの構造は送出メッセージ・パラメータをポピュレートする事前 定義コール変数と、それらに値を割り当てる割当てノードとからなっている。 ＭＳＡＰは着信メッセージの処理中に検出されたサービス・ロジック構造に基 づいて、次の送出ＴＣＡＰメッセージの各々を生成する。これらのメッセージは 、そのＴＣＡＰオペレーション・コード・パラメータによってユニークに特徴づ けられている。ＴＩはＴＩによって生成されたＩＳＣＰインバウンド・メッセー ジに応答してＭＳＡＰから送信されたメッセージを受け付ける。ＳＰＡＣＥには 、ＭＳＡＰサービス・ロジックをグラフィカル・ユーザ・インタフェースでサポ ートして、メッセージを生成するための構造、好ましくは、ネットワーク・アク ション・ノードが用意されている。 ConnectToResourse オペレーションは、コーラとのやりとりのためにコールを ＳＲＦに接続するように開始側ＳＳＦエンティティまたは支援側ＳＳＦエンティ ティに指示する。このオペレーションはＳＲＦがＳＳＰ内に内蔵されているか、 あるいはＳＣＦがＳＲＦエンティティを経由してＳＲＦと通信する場合に使用で きる。このオペレーションはＳＣＦがＳＲＦと直接に通信する場合、つまり、Ｉ ＳＣＰとＩＰとの直接通信の場合は必須でない。このメッセージはリソース・ア ドレス・パラメータを使用する。 リソース・アドレス(Resource Address)パラメータは２つの選択可能データ・ タイプとすることができる。ＳＲＦがＳＳＰ内に内蔵されているときは、このパ ラメータはＮＵＬＬ値を入れておく必要がある。ＳＲＦがＩＰに実装され、ＳＣ ＦがＳＳＦエンティティを経由してＳＲＦと通信するときは、リソース・アドレ ス・パラメータはＩＰに割り当てられたネットワーク・アドレスを入れてお く必要がある。 ＳＣＦはPlayAnnouncementオペレーションを使用してアナウンスを送出するよ うにＳＲＦ（これはＳＳＦエンティティ内に内蔵されていても、スタンドアロン 型ネットワーク・アドレス可能エレメントであっても構わない）に要求すること ができる。このオペレーションは次のパラメータを収めている。すなわち、送信 する情報、ＩＰからの切離し禁止、および要求アナウンス完了である。 送信する情報(Information to Send)パラメータは送出されるアナウンスまた はトーンに関する情報をコーラに伝達する。ＩＰからの切離し禁止(Disconnect From IP Forbidden)パラメータはコーラとのやりとりの完了後自身をコールから 切り離すべきかどうかをＳＲＦに通知する。要求アナウンス完了(Request Annou ncement Complete)パラメータはコーラとのやりとりが完了したとき通知をＳＲ Ｆに要求する。この通知はSpecializedResourceReportメッセージの形で送信さ れる。 PromptAndCollectUseInformationオペレーションはアーギュメントと結果の両 方を含んでいる。ＳＣＦエンティティはこのオペレーションのアーギュメントを 起動タイプ(invoke type)のメッセージ・コンポーネントでＳＲＦに伝達し、Ｓ ＲＦはオペレーションの結果を結果タイプ(result type)のメッセージ・コンポ ーネントでＳＣＦに送信する。 呼び出しタイプのメッセージは次のパラメータを収めている。すなわち、収集 桁数（最小桁数、最大桁数、送出終了桁、キャンセル桁、開始桁、第１桁タイム アウト、インタ桁タイムアウト、エラー処理、割込み可能Ann Ind、音声情報、 音声バック）、ＩＰからの切離し禁止、送信する情報である。ＳＣＦはこのオペ レーションを使用して、追加情報を収集するためにコーラとのやりとりを要求す ることができる。このオペレーションに収められるコーラ・プロプティング情報 のフォーマットはPlayAnnouncementオペレーションにおけるアナウンス情報、つ まり、送信する情報パラメータのフォーマットと同じである。このオペレーショ ンは収集する桁数に関する情報も収めており、桁入力のプロセスを制御する桁を 識別する。この情報はCollected Infoパラメータで伝達される。 ＳＣＦはCancelオペレーションを使用して、以前に出されたコーラとのやりと り要求をキャンセルすることができる。ＳＣＦは目標とするオペレーション要求 のInvoke IDを使用して、どのオペレーションをキャンセルするかを指定する。 このオペレーションはシングル・トランザクションのコンテキストでＳＣＦによ って送信されたすべての未処理オペレーション要求をキャンセルするためにも使 用することができる。例えば、ＳＣＦは進行中の特定のAINコールの未処理イベ ント通知要求をキャンセルすることができる。ＳＣＦはこの後者の場合には、In voke IDパラメータを使用する。 情報収集(Collect Information)オペレーションは起呼加入者から追加のアド レス桁を収集する。ＳＳＦエンティティはRequestReport BCSMventオペレーショ ンと一緒に単一メッセージでこのオペレーションを受信する。 RequestReportBCSMvent オペレーションは複合メッセージの中ではCollectlnfor mationオペレーションの前に置かれる。ＳＳＦエンティティはこのメッセージを 受信すると、情報集検出ポイントを使用可能にし、コール処理をコールの情報収 集ポイントに移動する。そのあと、スイッチは起呼加入者から桁を収集し、それ らをEventReport BCSMEventメッセージでＩＳＣＰに送信する。このメッセージ は収集した桁をEventSpecificInformation SCSMパラメータに収めている。情報 収集オペレーションにはパラメータがない。 ＳＣＦはRequestReportBCSMEventオペレーションを使用して、進行中コールと の進行中の関係（on going relationship）を要求し、定義する。進行中の関係 はＳＣＦが関心をもつコール処理イベントをリストすることによって定義される 。後続のイベント報告メッセージはＥＤＰ要求またはＥＤＰ通知タイプ・メッセ ージのどちらかであり、これはコントロール関係が要求されたか、モニタ関係が 要求されたかによって決まる。このオペレーションに関係するパラメータは次の とおりである。すなわち、イベント・タイプＢＣＳＭ、モニタ・モード、LegID 、dPSpecificCriteria（桁数、アプリケーション・タイマ）である。 必須のBCSM EventsパラメータはBCSMEventパラメータのシーケンスとすること ができる。その結果、ＳＣＦは単一のRequestReport BCSMEventメッセージ・コ ンポーネントを使用して、いくつかのタイプのコール処理イベントに関連するイ ベント・レポートを送信するようにＳＳＦに指示することができる。イベン ト・タイプＢＣＳＭサブパラメータはレポートを要求しようとする事前定義コー ル処理イベントのリストから１つを指定する。 モニタ・モード(Monitor Mode)パラメータは進行中コールにアクティブ（コン トロール）に介入するか、パッシブ（モニタ）に介入するかを要求する。LegID パラメータはイベントを要求しようとするコール・レグ(call leg)を指定する。 dPSpecificCriteriaパラメータは特定の検出ポイントに関連するNumberOfDigits とApplicationTimer情報を収めている。NumberOfDigitsパラメータはCollect In formation DPに関連しており、起呼加入者からどれだけの桁数を収集するかをＳ ＳＦエンティティに指示する。ApplicationTimer情報はNo Answer DPに関連し、 起呼加入者コール・レグでの無返答タイムアウトの長さを制御する。 ＳＣＦはCallInformationRequestオペレーション・メッセージをＳＳＦエンテ ィティに送信し、ＳＳＦエンティティで処理中のAINコールに関係するコール情 報をセーブし、戻すように要求する。CallInformationRequestメッセージを使用 すると、ＳＣＦはコールの持続時間を含む、１つまたは２つ以上の事前定義コー ル変数の値をＳＳＦエンティティに要求することができる。このメッセージのパ ラメータの内容は要求情報タイプ・パラメータのリストである。 要求情報タイプ・リスト(Requested Information TypeList)パラメータはＳＳ Ｆンティティに要求したコール関係のデータを指定している。ＳＳＦエンティテ ィは好適実施形態では、５種類の情報を提供する。 ＳＣＦはApplyCharging オペレーションを使用してＡＩＮコール課金を制御す る。例えば、ＳＣＦはこのオペレーションを使用して、コールをどのように課金 するか、コールを誰に課金するか、およびＳＳＦエンティティに最終的コール課 金情報をＳＣＦに送信させるかどうかをＳＳＦエンティティに指示する。ApplyC harging オペレーションに関連するパラメータには、ａＣｈビリング課金特性、 ＳＣに計算送信インジケータ、および課金する加入者(Legld)がある。 ａＣｈビリング課金特性パラメータはコール課金方法およびコールの課金しき い値に関する情報を伝達する。しきい値はコール期間中に累積された継続時間ま たは課金単位で表すことができる。しきい値まで達するか、あるいはコールがク リアされると、ＳＳＦエンティティは、ＳＣＦが課金情報を受信することを望ん でいれば累積課金情報をＳＣＦに送信する。 ＩＳＣＰに計算送信インジケータ(Send Calculation to ISCP Indicator)はＳ ＣＦがコール課金情報を受信することを望んでいるかどうかを示している。課金 する加入者パラメータはコールの課金を起呼加入者にするか、被呼加入者にする かをＳＳＦエンティティに通知する。 ＳＣＦはEstablishTemporaryConnectionオペレーションを使用して、ＡＩＮコ ールを支援側ＳＳＦエンティティに、なんらかのコールとのやりとりが行われる 場合にはＳＲＦに接続するように開始側ＳＳＦエンティティに指示する。Establ ishTemporaryConnectionオペレーションは、ＡＩＮコールをスタンドアローン物 理エレメント（つまり、ＩＰ）内のＳＲＦに転送する場合に使用される。 支援側ＳＳＰＩＰルーチング・アドレス・パラメータは支援側ＳＳＰまたはＳ Ｐのアドレスを収めている。このパラメータはその後のAssistRequestInstrcuti onオペレーションで使用されるcorrelation IDも収めているが、これは correla tion IDパラメータが個別パラメータとして必須となっていないためである。 ActivityTestメッセージはパラメータをもっていないが、ＴＣＡＰダイアログ ・レベルのSSF-SCF関係が存在するかどうかを確かめる。ＳＣＦは期待ＳＳＦエ ンティティ応答に関連するタイムアウトが起こったときこのオペレーションを使 用する。この時点で、ＳＣＦはActivityTestオペレーションをＳＳＦエンティテ ィに送信して、タイムアウトに関連するトランザクションのステータスに関する 情報を要求する。トラザクションがまだアクティブであることをＳＳＦエンティ ティが示していれば、ＳＣＦは該当のタイマをリセットし、期待応答を待ち続け ることができる。ＳＳＦエンティティがActivityTestオペレーションに応答しな いか、あるいはTC-Abortメッセージを送信したときは、ＳＣＦはＳＳＦエンティ ティが使用可能でないか、あるいはトランザクションが失敗したことを知ること になる。 ＩＳＣＰは、ＳＳＦエンティティがコール課金情報の生成をＡＩＮコール のローカル交換スイッチで制御することを望んでいるときRequestNotificationC hargingEventオペレーション・メッセージをＳＳＦエンティティに送信する。Ｓ ＳＦエンティティはその後のコール課金イベントを検出したときEventNotificat ionChargingメッセージを使用してＳＣＦに通知する。ＩＳＣＰは通知メッセー ジの後にSendChargingInformationメッセージを続けて、コールのビリング・レ コードを登録しているＰＳＴＮスイッチにコール課金指示を送信するようにＳＳ Ｆエンティティに指示することができる。 RequestNotificationChargingEventオペレーションはChargingEventパラメータ を収めている。 着信会話型メッセージ（incoming conversational message）のパラメータに は、（１）桁応答、（２）イベント・タイプＢＣＳＭ、（３）イベント固有情報 ＢＣＳＭ（ルート選択、被呼加入者通話中固有情報、切離し固有情報、ｔ被呼加 入者通話中固有情報、ｔ切離し固有情報）、（４）LegID、（５）雑多コール情 報、（６）要求情報タイプ・リスト（要求情報値、コール試み経過時間値、コー ル停止時間値（日付と時刻）、コール接続経過時間値、および被呼アドレス値） 、（７）コール結果、（８）相関ＩＤ、（９）イベント・タイプ課金、（１０） イベント固有情報課金、および（１１）エクステンション、がある。 ＭＳＡＰはこれらの着信ＴＣＡＰメッセージ・パラメータの各々の値を抜き出 し、ＳＰＡＣＥには、これらの着信ＴＣＡＰメッセージ・パラメータを処理する ためにＭＳＡＰによって使用されるサービス・ロジックをグラフィカル・ユーザ ・インタフェースでサポートする構造が用意されている。この要求条件をサポー トする、好ましいＳＰＡＣＥ構造は、着信メッセージ・パラメータによってポピ ュレートされたＣＶと、これらに基づく判断ノードである。 ＭＳＡＰは、各々がそのＴＣＡＰオペレーション・コード・パラメータによっ てユニークに特徴づけられている、以下に示すメッセージを処理し、ＳＳＰはＩ ＳＣＰから送信されたメッセージに対する応答としてのみこれらのメッセージを 送信する。ＩＳＣＰはこれらのメッセージを、メッセージが戻される原因となっ たISCP-SSPメッセージが出される原因となったコールの内容と関係づける。ＭＳ ＡＰは着信メッセージに指定されているパラメータに基づいて判断を行う サービス・ロジックに処理コントロールを戻す。ＴＩは送出（ＩＳＣＰからの） 会話型トランザクションで請求されたユーザのデータ入力に基づいて、以下のメ ッセージを生成する。 PromptAndCollectUserInformation Return ResultメッセージはPrompt and Co llect User Informationオペレーションが要求した、ＳＳＰからの結果をＩＳＣ Ｐに戻す。唯一のパラメータである、桁数応答(DigitsResponse)パラメータはPr ompt and Collect User Informationオペレーションと同じパラメータ構造を繰 り返す。 ＳＲＦはＳＣＦがPlayAnnouncementオペレーションの完了通知を要求したとき SpecializedResourceReportオペレーション・メッセージをＳＣＦに送信する。 このメッセージに関連するパラメータはない。 ＳＳＦエンティティはEventReport BCSMオペレーション・メッセージをＳＣＦ に送信し、コール処理イベントが行われたことを報告する。報告されるコール処 理イベントのセットは、AIN CS-1コール・モデル内に定義されている検出ポイン トのセットと同じである。EventReportBCSMメッセージはＳＣＦからの以前の要 求に応答して、進行中コール処理情報を要求し、次のパラメータを収めている。 すなわち、イベント・タイプＢＣＳＭ、イベント固有情報ＢＣＳＭ（ルート選択 失敗固有情報、被呼加入者通話中固有情報、切離し固有情報、被呼加入者通話中 固有情報、切離し固有情報）、LegID、および雑多コール情報である。 このオペレーションの唯一のパラメータである、イベント・タイプＢＣＳＭは 報告されるコール処理イベントに関連するコール・モデル検出ポイントを示して いる。イベント固有情報ＢＣＳＭ(Event Specific Information BCSM)パラメー タは報告されるイベントのタイプに固有のコール関係情報を収めている。LegId パラメータはコール・レグ、つまり、報告されるイベントに関連する起呼または 被呼加入者コール・レグを示している。雑多コール情報(Misc Call Info)パラメ ータはイベント・レポート・メッセージのタイプが要求（ＳＣＦは後続コール処 理を制御する）か通知（ＳＣＦはモニタだけを行う）かを示している。このパラ メータの値はRequestReport ＢＣＳＭEventオペレーションにおけるモニタ・モ ード・パラメータの値によって決まる。 ＳＳＦエンティティはコール関係情報を収めているCallInformationReportオ ペレーションを、CallInformationRequestメッセージによって行われた、ＡＩＮ コール処理期間にＳＣＦによる以前の要求に応答してＳＣＦに送信する。CallIn formationReportオペレーション・メッセージは次のようなパラメータを収めて いる。すなわち、要求情報リスト（要求情報タイプ、要求情報値）、要求情報値 （コール試み経過時間値、コール停止時間値、被呼アドレス値、およびリリース 原因値）である。 要求情報リスト(Requested Information List)パラメータはコール情報要求オ ペレーションの結果を収めており、これは２つ以上の値を含むことが可能である 。被呼アドレス値(Called Address Value)サブパラメータはいずれかの番号変換 の前にＳＳＦによって受信されたオリジナル・アドレス桁数の値である。 ＳＳＦエンティティはコール課金しきい値まで達したとき、あるいはＳＣＦが ApplyChargingオペレーション要求を通して以前にこの情報を要求していれば、 コールがクリアされたとき、ApplyChargingReportオペレーション要求をＳＣＦ に送信する。この要求の唯一のパラメータは要求コール課金情報を収めているコ ール結果(Call Result)である。 支援側ＳＳＦエンティティまたはＳＲＦはコーラとのやりとりを行うためにコ ールを転送したＳＣＦにAssistRequestInstructionオペレーション要求を送信す る。送信側ＳＳＦエンティティまたはＳＲＦはこのオペレーションを使用して、 コール処理に関する別の指示を入手する。ＳＣＦはAssistRequestInstructionオ ペレーションに応答してConnectToResourceオペレーションを送信し、なんらか のコーラとのやりとり要求がやがて行われることを示すのが代表的である。この オペレーションの唯一の必須パラメータはcorrelation IDパラメータであり、Ｓ ＣＦはこのパラメータを使用してこのオペレーション要求をアクティブ・コール （トランザクション）コンテキストと突き合わせる。 ＳＳＦエンティティがアクティビティ・テスト・オペレーションを受信し、ト ランザクションがまだアクティブであると確認通知したいときは、Return Resul tをアクティビティ・テストに送信する。このメッセージにはパラメータは ない。 ＳＳＦエンティティはEventNotificationChargingオペレーション・メッセー ジをＳＣＦに送信して課金イベントをＳＣＦに通知し、RequestNotificationCha rgingEventメッセージでＳＣＦによって以前に要求されたコール課金情報をＳＣ Ｆに送信する。要求され、その後にＳＣＦに送信される情報はネットワーク・オ ペレータによって定義される。次のパラメータはEventNotificationChargingオ ペレーションのアーギュメントとしてサポートされている。すなわち、EventTyp eCharging、EventSpecificInformationCharging、およびLeg IDである。 ７．結論 本発明によれば、電話スイッチング・ネットワークが種々のフォーマットをも ち、複数の異なる国からの電話番号を認識し、応答できることを保証することに よって本発明の目的は達成される。この処理は番号のアドレスの種類に従って、 時には番号のフォーマットに従って進められる。 当業者ならば理解されるように、本発明の実現方法と構造は本発明の範囲また は精神を逸脱しない限り、種々の態様に改良し、変更することが可能である。ま た、本発明の明細書と実施形態から示唆されるように、種々の変更も可能である 。従って、明細書の説明は単なる例示であることはもちろんである。本発明の範 囲と精神は特許請求の範囲に明確化されている。

【手続補正書】 【提出日】１９９８年１０月１４日 【補正内容】 請求の範囲 １． ナンバリング・プランがコンフリクトする可能性のある国際電話番号を電 話ネットワークのインテリジェント・スイッチで解析する方法であって、 電話番号のアドレスの種類を国内、国際、またはその他として判断するステッ プと、 電話番号のフィールドをアドレスの種類に従って抜き出すステップと、 アドレスの種類がその他であれば電話番号をさらに処理するステップと、 国際プレフィックスが認識可能であれば、国際プレフィックスを解析し、国際 プレフィックスおよび電話番号の残余部分をセーブしておくステップと、 国際プレフィックスが認識可能でないが、電話番号が国内オペレータ選択コー ドを含んでいれば、解析を続けるステップと、 国際プレフィックスが認識可能でないが、電話番号が認識可能な国内オペレー タ選択コードを含んでいなければ、エラー処理プロシージャを実行するステップ と を含むことを特徴とする方法。 ２． ナンバリング・プランがコンフリクトする可能性のあるネットワーク間で 国際電話コールの接続を確立するための電話通信システムであって、 電話コールをルーチングする複数のスイッチと、 電話コールをルーチングするための処理レコードを収めている複数のデータベ ースであって、前記処理コードがＭＳＡＰおよびＳＰＡＣＥベースのコール処理 レコードを含む複数のデータベースと、 前記複数のスイッチおよび前記複数のデータベースに結合されていて、スイッ チによる電話コールのルーチングを該電話コールの電話番号に従って制御する複 数のインテリジェント・サービス・コントロール・ポイントと を有し、各々の前記サービス・コントロール・ポイントは、 電話番号のアドレスの種類を国内、国際、またはその他として判断する手段 と、 電話番号をストアし、電話番号をナンバリング・プランとアドレス桁フィール ドとに分離する手段と、 電話番号から前記フィールドを抜き出し、アドレスの種類に基づいて電話番号 を解析する手段と、 電話番号についての解析されたコンポーネントをセーブする手段と を含むことを特徴とする電話通信システム。

Claims (1)

1. 【特許請求の範囲】 １． 電話番号を電話ネットワークのインテリジェント・スイッチで解析する方 法であって、 電話番号のアドレスの種類を国内、国際、またはその他として判断するステッ プと、 電話番号のフィールドをアドレスの種類に従って抜き出すステップと、 アドレスの種類がその他であれば電話番号をさらに処理するステップと、 国際プレフィックスが認識可能であれば、国際プレフィックスを解析し、国際 プレフィックスおよび電話番号の残余部分をセーブしておくステップと、 国際プレフィックスが認識可能でないが、電話番号が国内オペレータ選択コー ドを含んでいれば、解析を続けるステップと、 国際プレフィックスが認識可能でないが、電話番号が認識可能な国内オペレー タ選択コードを含んでいなければ、エー処理プロシージャを実行するステップと を含むことを特徴とする方法。 ２． 電話通信システムであって、 電話コールをルーチングする複数のスイッチと、 電話コールをルーチングするためのデータを収めている複数のデータベースと 、 前記複数のスイッチおよび前記複数のデータベースに結合されていて、スイッ チによる電話コールのルーチングを該電話コールの電話番号に従って制御する複 数のインテリジェント・サービス・コントロール・ポイントと を有し、各々の前記サービス・コントロール・ポイントは、 電話番号のアドレスの種類を国内、国際、またはその他として判断する手段と 、 電話番号のフィールドをアドレスの種類に従って抜く出す手段と を含むことを特徴とする電話通信システム。