JPH08508620A - 通信ネットワーク用データ処理システム - Google Patents

Abstract

(57)【要約】 英国における公衆加入電話網（１）のような通信ネットワークで使用するための網間通話会計処理システムは、料金設定および請求を行う前に、ネットワーク事業者に従って分類される通話記録を、通話に関して請求できるようにする。検査できない通話記録に対して、専門家システムを搭載するデータ・アナライザ（７）が提供される。データ・アナライザ（７）は、デフォルトの日付または修正日付を適用するか、更新済み参照情報を待機している中断されたプロセスに、無効データを出力することができる。修復不能データは、管理するために貯蔵？？に出力される。料金設定課金装置は、料金請求書作成可能事業体に従ってすでに分類されたデータを処理し、さらに、料金設定および課金に関係する情報のため、無効データを処理するデータ解析手段を搭載する。

Description

【発明の詳細な説明】 通信ネットワーク用データ処理システム 本発明は、マルチネットワーク通信でのデータ収集およびデータ処理のための データ・システムに関する。 電話またはデータ転送のような通信事例が、単独ネットワーク内で発生すると 、それらの通信事例に関係するデータのログおよび処理を行うのは周知である。 一般的に、公衆加入電話網（ＰＳＴＮ）においては、ネットワーク事業者が、呼 を開始した加入者宛の請求書上での項目を作成できるように、データが通話保留 時間に関して収集され、少なくとも一日の内の時刻および呼の種別を考慮して処 理される。 近年では、加入者が利用できるサービスおよび呼の種別の選択肢が大幅に増加 したのに従い、必然的にＰＳＴＮ用データ・システムもますます複雑になってき た。例えば、０８００番号の導入を受けて、請求書の発行相手は発呼加入者では なくなった。ＰＳＴＮ上では、最初の加入者により開始された呼が、ネットワー クにより自動的に選択された番号に転送され、コストの差額は被呼者によって負 担されるコール・フォワーディング・サービスのような、多くのさらに複雑なサ ービスがすでに試されるか、実用化されている。 大幅な変更の過程にある通信ネットワークの別の面は、既存ネットワーク事業 者の多様性である。過去においては、ＰＳＴＮは、国家のインフラストラクチャ の一部として、おも に政府組織により運営されていた。現在では、ますます、ＰＳＴＮの民営化およ び規制独占の緩和が進み、加入者が利用できるネットワーク事業者の数がさらに 増加し、これらのネットワーク事業者は、実践上の理由から、網間接続を提供し なければならない。つまり、ネットワーク事業者は、専用ネットワーク、または 独立しているが、類似した管理が布かれている限られた数の相互接続したネット ワークで生じる通信事例だけではなく、理論的には、さまざまな種類で、多岐に 渡るサービスを加入者に提供する、非常に多数の競合ネットワークで発生する通 信事例も考慮に入れなくてはならない。 したがって、事業者のネットワーク外で発生するが、事業者のネットワークの 中で終端するか、あるいは単に事業者のネットワークを横切る通信事例に関係し て、データの収集および処理を行うことがますます重要である。 呼が複数の事業者のネットワークを通過する場合、互いの呼の搬送に関する事 業者間の価格および課金の契約が効果を発揮する。このような取り決めは、単な る送信者がすべてを保管？（ＳＫＡ）取り決めから複雑な料金設定式までさまざ まである。 通話データは、呼が発生したネットワークの責任を持つ管理責任者により収集 されるというのが、電気通信における別個のネットワーク事業者または管理責任 者の間での確立された慣行であった。その場合、その呼が第２のネットワークで 終端した場合、第２のネットワークに関係する管理責任者は、例えば、会計処理 を行うために、第１のネットワークの責任 を持つ管理責任者により収集されるデータを信頼する。しかし、電気通信環境は 、技術的にだけではなく、急速に、かつ政治的にも変化を遂げている。さらに激 化した競合状態が到来し、独自のネットワークで生じるトラヒックのみならず、 それ以外の場所で発生するが、独自のネットワークを横切るか、あるいは独自の ネットワークで終端するトラヒックもモニタすることは、網管理責任者にとって ますます魅力的になっている。トラヒックがその中で生じるネットワークが競合 事業者または管理責任者に属している場合は、競合事業者のアカウントも相互チ ェックすることが少なくとも可能であることが望ましい。 市内交換機はトラヒックが生じるとそれをとらえるため、既知の取り決めでは 、ＰＳＴＮ内での通話に関するデータ収集点はネットワークの市内交換機であっ た。しかしながら、この取り決めは、網間トラヒックに関してデータ収集を行わ ない。たとえネットワークに着信する呼に関するデータを収集するためのデータ 収集点が存在しても、このようなデータを任意の詳細レベルまで処理するのに必 要となる物流の調達は威圧的である。例えば、アイル・オブ・マン（Ｉｓｌｅｏ ｆ Ｍａｎ）およびセルネット（Ｃｅｌｌｎｅｔ）・セルラー・ネットワークを 含む他の管理責任者から、英国電気通信会社（ＢＴ）により英国内で運営されて いるＰＳＴＮに着信する呼は、１９９２年３月までの１年間で、毎日、総計１， ５４０万通話にのぼった。この数字は、１９９５年３月までの１年で、毎日約２ ，７００万通話に到達すると予想されて いる。ＢＴ ＰＳＴＮ内で発生するものも含むすべての通話事例を考慮すると、 １９９５年の場合、毎日６，０００万通話事例が予想されている。 非常に大量なデータが関係しているのにも関わらず、本発明を作成する上で、 関連する網管理責任者が、外部網管理責任者に適切に割り当てられるだけではな く、項目別請求書作成もサポートする会計情報を生成できるほど詳細に出力を作 成できる英国ＰＳＴＮのような一流電気通信網に着信する呼に関係するデータの 収集および処理を行うためのプロセスを設計することが可能であることが分かっ た。つまり、会計情報は、呼が事前に選択した判断基準を満たしている限り、英 国電気通信会社による英国ＰＳＴＮ用国内料金請求書作成システムで現在利用で きる項目別料金請求書のような様式で、個々の通話を識別することも可能なほど 十分に詳細に分類することができる。 本発明の第１の面に従い、第１通信ネットワークでの通信事例に関するデータ の収集および処理用プロセスが提供され、その場合ネットワークは、直接的ある いは間接的な少なくとも１つの第２ネットワークへの接続点を備え、その接続点 を使って、前記第２ネットワークで発生する通信事例が、前記第１ネットワーク に送信され、前記第１ネットワークを横切るか、あるいは前記第１ネットワーク で終端するかのどちらかとなり、そのプロセスは、 ｉ）前記接続点にあるデータ・アクセス・ポイントでデータを収集するステップ であって、前記データが、前記第２のネ ットワークで発生する通信事例に関し、経路情報、および前記通信事例に関する 期間などの少なくとも１つのパラメータ測定値から構成されるステップと、 ｉｉ）前記データをデータ処理システムに送信するステップと、 ｉｉｉ）前記データを処理するステップと、 から構成される。 データを第１ネットワークと別のネットワークの間の接続点で収集することに より、第１ネットワークに関連する管理責任者は、第１ネットワークに着信する 通信事例についての情報を直接取得し、したがって他のネットワーク事業者また は管理責任者により提供されるデータを相互チェックできるようになる。 本発明の第２の面に従い、別のネットワークとの接続点にあるＰＳＴＮで収集 されるデータを処理するためのデータ処理装置が提供され、装置は、 ｉ）通信ネットワークから通信事例に関するデータを入力するためのデータ入力 であって、前記データが複数の分類特性の内の少なくとも１つを備えるデータ入 力と、 ｉｉ）データ入力で受け取られたデータの整合性および能力をチェックするため の検証手段と、 ｉｉｉ）検証手段により拒絶されたデータを解析し、修正されたデータまたはデ フォルト・データを検証手段に提出するためのデータ・アナライザと、 ｉｖ）更新可能参照情報に従い、検証手段により出力された 検証済みデータの料金設定を行うための料金設定手段と、 ｖ）料金が設定され、検証されたデータを、料金設定手段からメモリ位置に出力 するための出力手段であって、各メモリ位置が、１つまたは複数の前記分類特性 に関連するデータ専用である出力手段と、 を具備する。 また、破損したデータが再フォーマットされるか、再フォーマットされない場 合には訂正され、それ故、通信事例の有効なレコードとしてシステムに再入力で きるように、料金設定手段がデータを検証し、エラーが発生したデータを、前記 データ・アナライザであるか、あるいは別のアナライザであるデータ・アナライ ザに出力できるのが望ましい。 また（あるいは代わりに）、異なったタイプの障害に関してデータを解析する ために、このもう一つのデータ解析ステップが使用される可能性もある。例えば 、検証手段により位置が見つけられた、エラーが発生したデータで実行されるデ ータ解析では、おもにフォーマットおよび経路選択情報に関してエラーが発生す るが、料金設定手段からのエラーが発生したデータでは、おもに料金設定情報に 関してエラーが発生した。 分類特性は、通常、メモリ位置がそれぞれ共通の１つの計算エンティティに料 金請求書を作成可能で、各共通通信ネットワークで発生する通信事例に関連する データを保持できるようなものとなる。 分類特性は、前記のデータ処理装置の複数の段階の任意の １つで適用される。ただし、例えばＰＳＴＮ内では、通常、発生するエラーが発 生したデータの性質により、（ｉｉｉ）検証手段に対応するデータ・アナライザ と（ｉｖ）料金設定手段との間に、分類手段を提供することが望ましくなる。し たがって、料金設定手段は、すでに分類されたデータ上で動作する。分類特性が 、データにより表される通信事例に関して料金請求書の発行を受けるさまざまな 事業体に関係する場合は、この装置には、個々の事業体に関連する制約事項を適 用する場合に、料金設定手段を簡略化できる可能性があるという利点もある。 ＢＴ ＰＳＴＮのようなネットワークが市内局と市外局の両方から構成され、 交換機間通話送信だけではなく、市内通話のエンドユーザまでの送達も行うこと に注意する。つまり、料金請求書作成または料金請求書検証をサポートするのに 必要なデータ収集および処理は、きわめて広範囲に渡る変数を処理できるほど複 雑でなければならない。これは、ネットワークが市外局間送信だけ、あるいは市 内局送達だけを行う状況とは対照的である。 ここでは、本発明の実施例に従ったシステムを、付随図面を参照し、例だけを 使用して説明する。この場合、 図１は、電気通信網に着信する通話事例用の会計処理システムをサポートする ための、通話情報から構成されるデータの収集および処理を行うためのシステム のアーキテクチャを図式によって示す。 図２、３、および４は、図１に示されるシステムの概要フ ロー図である。 図５は、図１のシステム用のハードウェアと通信図を示す。 図６は、図１に従ったシステム内でストリーマとデータ・アナライザの間で使 用するためのソフトウェア・アーキテクチャを示す。 図７は、図１のシステムで使用するための企業システムを提供するハードウェ アのアーキテクチャを示す。 図８は、図７の企業システムで使用するためのバッチ・アレイ処理アーキテク チャの概要図である。 図９および１０は、図１のシステムで使用するための交換機からおよびデータ のポーリングに関係した、交換機ファイルおよび上級プロトコル・データ装置（ ＡＰＤＵ）フォーマットを示す。 図１１から２１は、図１に従うシステムのストリーマとデータ・アナライザで 使用するためのフロー図である。 図２２は、図１のシステムの要素間のプロセス相互作用を表す。 図２３から３０は事業体存続履歴図であり、各事業体の中のレコードのステー タスを示し、そのステータスからの操作により、それ以外のどのステータスに到 達できるかを示す。 図３１および３２は、図１のシステムと使用するための専門家システムにおい て、データ入力と規則違反の後のアジェンダの状態およびパターン・ネットの状 態を表す。 図３３および３４は、図１に従ったシステムのデータ・アナライザ内で使用す るために、ルール・ベース・システムと ケース・ベース・システムのそれぞれのオブジェクト階層を示す。 図３５は、図１に従ったシステム内でデータ・アナライザ用の専門家システム ／ＯＲＡＣＬＥインタフェースを構築する上で必要となる設計原則を示す。 図３６は、図１に従ったシステム内で利用するための企業システムのデータ・ モデルを示す。 図３７から４３は、図１のシステムで使用するためのデータ・アナライザの動 作に関連するフロー図を示す。 図４４は、図１に従ったシステムで使用するための企業システムに関連したデ ータを強調したデータ・フローを示す。 以下に示す説明および図の数カ所で用語「ＩＣＮＡ」と「ＩＤＡ」がときおり 使用されてきた。これらは、システム全体の記述である網間通話会計と、ＩＣＮ Ａデータ・アナライザの略である。後者は、専門家システムを具備し、ストリー マ６とインタフェースするデータ・アナライザ７に対する参照である。 以下の説明は、次のように構成されている。 １．図１：アーキテクチャのブロック図 ２．図２、３および４：プロセス概要のフロー図 ｉ）相互接続点とＤＤＣ（直接デジタル制御） ｉｉ）ストリーマ ｉｉｉ）企業システム（またはボックス） ３．図１および図５から８：ハードウェア、通信、およびソフトウェアのアーキ テクチャ ｉ）ＰＯＩ（相互接続点）およびＤＤＣ ｉｉ）ストリーマおよびデータ・アナライザ ｉｉｉ）企業システム ｉｖ）クライアント・ボックス ４．図９と１０：通話記録およびデータ・フォーマット ｉ）通話記録 ｉｉ）データ構造体の交換機データへのマッピング ５．図１１から１９、および図２２から３０：ストリーマおよびデータ・アナラ イザのプロセス用のより詳細なフロー図 ｉ）ストリーマ：ＤＤＣポーリング ｉｉ）ストリーマ：ファイル・プロセス ｉｉｉ）ストリーマ：ＤＤＣ削除 ｉｖ）データ・アナライザ：プロセス ｖ）事業体存続履歴 ６．図３１から３５：専門家システム ｉ）概要 ｉｉ）ルール・ベース汎用規則 ｉｉｉ）ケース・ベース ｉｖ）オラクル・インタフェース ７．図２０、２１および図３７から４３：データ・アナライザによる専門家シス テムの利用 ８．図３６および４４：企業システム、データ解析および料金設定と課金 ９．監査追跡？ １． 図１：アーキテクチャのブロック図 図１を参照すると、ＢＴ ＰＳＴＮのような第１ネットワーク１で、第２ネット ワーク２で発生するか、あるいは第２ネットワークから着信する呼に関して、デ ータを収集できるようにシステムが提供されている。データは、前記第１ネット ワーク１の交換機により提供される相互接続点（ＰＯＩ）３で収集され、ＰＳＴ Ｎ内の約１０台の地域データ・コレクタ（ＤＤＣ）の内の１台に運ばれる。これ らが、各着信呼の経路情報から構成されるデータを保持し、そのため呼の意図さ れた宛先、呼がそこから発信される通信事業者、各呼が１つのイベントとして処 理されるようにする項目別データ、および（できれば）第２ネットワーク２では 単に中継呼に過ぎなかった呼も、その発生元のネットワークに関して正確に計算 できるように発信番号アイデンティティなどの識別が可能となる。 各地域データ・コレクタ（ＤＤＣ）５は、ファイル・レベルと通話記録レベル の両方で、おもに経路選択参照モデルに比較して、通話データの拡張および検査 を行うストリーマ・システム６によりポールされる（ＢＴ ＰＳＴＮの地域デー タ・コレクタ５は関連データをとらえるが、その役割は、ネットワーク・メディ エーション・プロセッサのように周知の装置などの会計処理装置のその他の構成 要素システムによっても等しく提供される）。ストリーマ６により無効と分かっ たデータは、データ・アナライザ７に転送され、そこで知識ベースのシステムを 使用し、無効性が評価され、可能である 場合にはこの問題を解決しようとしてデータが修正される。一般的には、無効デ ータは会計処理可能な入力として失われてしまうため、これは、システムの重要 な構成要素である。検査済みデータは、関連する呼がそこから受信された第２ネ ットワークに関連する事業者に従って、同時にストリームされ、企業システム８ に引き渡される。 ストリーマ６は、以下に示す機能を備える。 ●本発明のデータ・システムによる処理を待機しているファイルに関して、各Ｄ ＤＣ５をポールする。 ●ファイルおよびその通話記録を経路選択参照モデルに比較して検査する。 ●通話記録を拡張し、正しい電気通信網事業者に割り振る。 ●ＩＤＡ７に対する無効データを拒絶する。 ●ＩＤＡ７から受信された未処理ファイルを未処理レコード・バックアップ・イ ンタフェース・ディレクトリにコピーする。 ●データがいったんインタフェース・ディレクトリで保全されたら、ファイルを ＤＤＣ５から削除する。 ●ユーザに、経路選択参照モデルを入力するためのユーザ・インタフェースを提 供する。 ●ストリーマを介して完全な監査追跡を提供する。 ●ユーザに、ストリーム動作の動作およびデータ整合性をモニタする能力を与え る。 データ・アナライザ７は、以下に示す機能を備える。 ●１つまたは複数のエラーがあるファイルを探してインタフ ェース・ディレクトリをポールする。 ●誤った通話記録が有効な通話記録であるが、経路選択参照モデルと一致しない 場合には、その通話記録を未決領域に保持する。 ●ユーザが、経路選択参照モデル更新後にデータを再ストリームできるように、 ユーザ・インタフェースを提供する。 ●ルール仕様に従って誤っているフィールドに、デフォルトの通話記録値を適用 する。 ●エラー・スレッショルドを超えたためまだストリームされていない正しいデー タをストリームする。 ●訂正済みデータをストリームする。 ●ＩＤＡ７を介して、通話記録レベルで完全な監査追跡を提供する。 また、通話パラメータからだけではなく、２つの相互接続されたネットワーク １、２の事業者間の関係性から得られる要因をインポートするのは企業システム であるため、企業システム８は現在では重大な役割を果たしている。呼が会計処 理手順に与える影響は、部分的には、関連事業者間の「サービス・レベル協約」 などの要因により決定される。検索テーブルまたは国内課金データベース（ＮＣ ＤＢ）９あるいはその両方を備えることがあるさまざまな情報源に参照すること により、これらの要因が利用されるのは企業システム８においてである。特に後 者に関しては、本書では、時間変化料金レートなども説明する。 このようにして、企業システム８からの出力は、最終的に は会計処理システムで利用するための情報であり、接続点３から収集した未処理 通話データを表し、適用されなければならない事業者に特殊なパラメータおよび 時間変化パラメータなどの関連パラメータに関して処理される。出力は、パーソ ナル・コンピュータを使ってユーザ・アクセスを行うクライアント・システム１ ０に提供される。 ２．図２、３および４：プロセス概要 図２、３および４を参照して、通話事例に対応して運用中の前記のプロセス概 要を説明するためにフロー図を使用することができる。 ２（ｉ）相互接続点およびＤＤＣ 図２は、ＰＯＩ交換機３により実行されるプロセス・ステップ、および着信呼 に応えてＤＤＣ５により実行されるプロセス・ステップを示す。これらのすべて のステップは既知であり、交換機３およびＤＤＣ５は、本発明のために修正され ていない。 図２を参照すると、関連ネットワーク１に着信する呼または関連ネットワーク １を発信する呼は、ステップ２００で、ＰＯＩ交換機３内に通話記録を作成する 。ステップ２１０で、交換機３は、すべての通話事例に０−９９９９シリーズの 「ファイル作成番号」を付与する。ステップ２２０では、交換機は通話記録を上 級プロトコル・データ装置（ＡＰＤＵ）にグループ化し、ＡＰＤＵをファイルに グループ化する。 ステップ２３０では、ＤＤＣ５が、ＡＰＤＵフォーマットのすべての通話記録 データを求めて交換機３をポールする。 ステップ２３５では、ＤＤＣ５が、ヘッダＡＰＤＵ形式および後書きＡＰＤＵ形 式の制御データを追加する。また、ＤＤＣ５は、ステップ２４０で、各ファイル に０−９９９９９９の範囲のファイル・シーケンス番号を付与し、ステップ２４ ５で、各ＡＰＤＵに０−１６３５３の範囲のＡＰＤＵシーケンス番号を付与する 。ＡＰＤＵはバイナリ・フォーマットである。ステップ２５０では、ＤＤＣ５は 、その中からストリーム６がポールすることによりファイルをとらえることがで きるディレクトリ構造の中にファイルを格納する。同時に、ステップ２６０では 、ＤＩＲＩＮＤＥＸと呼ぶカタログ・ファイルに入力が行われる。このカタログ ・ファイルには、ストリーマ６がポールするのに使用できるすべてのファイルの リストが入っている。 ２（ｉｉ） ストリーマ 図３を参照すると、ステップ３００で、ストリーマ６がＤＤＣディレクトリ構 造を定期的にポールし、通話記録をランダムアクセスメモリ（ＲＡＭ）に入力す る。各ファイルは１メガバイトにロードされる。このポーリング・プロセスには 、最新ＤＩＲＩＮＤＥＸファイルをコピーするステップが含まれる。実際にはス テップ３００でのＤＤＣポーリング・プロセスの一部であるステップ３１０で、 データがバイナリ・フォーマットからＡＳＣＩＩ（情報交換用米国標準符号）フ ォーマットに変換される。 ステップ３２０で、ストリーマ６は、通話記録の妥当性検査を実行する。通話 記録が不完全であったり誤っているため に、検証できない場合には、ストリーム６でのそれ以降の処理ステップに進み、 最終的に料金請求書作成プロセスに進む代わりに、通話記録は、誤ったデータ・ アナライザ７でさらに解析を受けるために、インタフェース・ディレクトリ（ス テップ３３０）に転送される。 ただし、ステップ３４０で、有効データは、呼の発信元となるか、ＢＴ ＰＳ ＴＮにその中から入ったか、あるいはある状況下ではその着信先となる他のネッ トワークを確証するために、通話記録内のデータが使用される識別プロセスまで 進行する。料金請求書作成のための関連ネットワーク事業者を表すコードが通話 記録に付加されてから、ファイルが、ステップ３５０で、そのコードに従い分類 、再構成される。このため、この時点での通話記録は、ネットワーク事業者また は少なくとも最初の事例でそれらの通話の費用を負担するそれ以外の関連事業体 に従い、分類することができる。 ステップ３６０および３７０では、ストリーマ６は新規に構成されたファイル を企業システム８に出力し、ＤＤＣ５上のＦＴＡＭ（ファイル転送・アクセスお よび管理）ファイル記憶装置からファイル・データを削除する。 データ・アナライザ７を参照すると、検査不可能なデータの料金請求書は作成 できないため、これは重要な役割を果たす。ステップ３８０でのデータ・アナラ イザ７は、ステップ３３０でストリーマ６により入力された、エラーが発生した ファイルに関して、インタフェース・ディレクトリをポールする。そうすると、 データ・アナライザ７は、エラーが発生 したデータをシステムの中に戻す３つの別の機会を得る。 ステップ３８２で、データ・アナライザは、データの修復を期待している。デ ータ・アナライザがデータを修復できる場合には、修復されたデータはインタフ ェース・ディレクトリに戻され、ストリーマ６はそこからデータをとらえる。ス テップ３８４では、データ・アナライザ７は、修復不能データにデフォルト値を 適用するのを期待している。監査追跡に影響を及ぼすなどのため、データ要素に よってはこのようにして「パッチ」することはできないものがある。最後に、ス テップ３８６では、データ・アナライザ７が、データと経路選択参照モデル（Ｒ ＲＭ）の間の単なる不一致があるかどうかをチェックする。後者は、経路選択情 報を与えるデータベースで、呼の宛先などを識別するためにＤＤＣ５で使用され る。ＲＲＭのコピーは、通信ネットワークのさまざまな場所で保持され、あるコ ピーが時間切れで、あるいは誤って更新されると、データ内の不一致を生じさせ る。データ・アナライザ７は、これが当てはまると思われる場合には、それらの 通話記録を、ＲＲＭチェック後に通話記録をストリーマ６のプロセスに戻すこと ができるようにする中断ファイルに入力（ステップ３８８）する。 データ・アナライザ７が前記の方法のいずれでもデータを処理できない場合に は、データ・アナライザは、ステップ３９０で「データ貯蔵庫？」にデータを出 力する。つまり、データは実質上失われ、決してその料金請求書が作成されるこ とはないという意味である。ただし、長期にシステムの変更 や訂正を行えるようになるため、これは解析には有効である。 ２（ｉｉｉ） 企業システム 図４を参照すると、ストリーマ６により検査され、処理されたファイル・レベ ルでのデータは、企業システム８に入力され、そこでの最初のステップ、ステッ プ４００はファイル・シーケンス番号の妥当性検査である。企業システム８は、 ファイル・シーケンス番号順にファイルを処理するが、ストリーマ６は別の交換 機３からのデータを平行して処理した。ファイル・シーケンス番号が正しくない 場合、企業システムはファイルを無効とし、その処理を停止する（ステップ４１ ０）。 ファイル・シーケンス番号が有効な場合は、企業システム８はステップ４２０ に移動し、通話記録を検査する。この場合、検査は、おもにＲＲＭの観点からの ストリーマ６に関してではなく、料金請求書作成可能事業体および料金請求書作 成可能事業体と、例えばＢＴのような第１ネットワーク１の事業者との関係の方 をより重視する。それに対して料金請求書を作成することができる事業体および ＢＴが、サービス・レベル協約（ＳＬＡ）を結び、通話記録は、現在のＳＬＡの 元でその料金請求書作成可能事業体に使用できない呼の種別を示す場合がある。 企業システム８は、それを無効性としてとらえ、ステップ４３０で、エラー状態 の通話記録を修復しようとする。通話記録を修正できる場合は、通話記録は、ス テップ４４０で大容量化するために送られ、企業システム８に再入力される。通 話記録を修正できない場合には、通話記 録はステップ４５０で解析のために記憶される。 一方、有効な通話記録は、企業システム料金設定装置に、個々の通話記録が、 ＮＣＤＢ９、関連する料金請求書作成可能事業体とＢＴの間のＳＬＡ、およびそ れ以外の関連情報に従って料金設定されるステップ４６０に転送される。その後 で、料金設定が行われた通話記録は、ステップ４７０で、関連する料金請求書作 成可能事業体に対して請求するために要約データベースにロードされ、通話記録 は記憶のため光ディスクに出力される（ステップ４８０）。 クライアント・ボックス１０は、毎週、要約データベースからダウンロードさ れた情報を受け取る。各クライアント・ボックス１０は、１つの料金請求書作成 可能事業体専用であり、「専用の」通話記録だけを取得する目的で、光ディスク 記憶装置にアクセスする場合にも使用できる。 ３．図１、５、６、７および８：ハードウェア、通信およびソフトウェアのアー キテクチャ ３（ｉ） 相互接続点３およびＤＯＣ５ 交換機３およびＤＤＣ５は既知のタイプであるため、本明細書では詳細に説明 しない。簡略すると、これらは以下のように動作する。 図１および２を参照すると、英国電気通信会社（ＢＴ）により運営される英国 のＰＳＴＮに着信するかあるいは発信する呼は、現在、相互接続点（ＰＯＩ）３ としてのデジタル電話交換機を通過する。本発明のデータ・システムに関連する このような交換機のすべては、現在、デジタル接合交換設備 （ＤＪＳＵ）、デジタル市内文換機（ＤＬＥ）、またはデジタル・メイン交換設 備（ＤＭＳＵ）のシステムＸ電話交換機である。 ＢＴネットワーク１に着信する呼あるいは発信する呼のすべては、図２のステ ップ２００に示されるように、英国電気通信通話記録種別６として知られるフォ ーマットでＰＯＩ交換機３内で通話記録を作成する。システムＸ ＰＯＩ交換機 ３は、毎日、ＡＰＤＵフォーマットのすべての通話記録データに関して、ステッ プ２３０で、ＤＤＣによりポールされる。ポーリングは、高速ＢＴデータ・リン ク中でファイル転送・アクセスおよび管理（ＦＴＡＭ）プロトコルを使って発生 する。ＤＤＣは、純粋に、ＰＯＩからの通話記録ファイルのコレクタとして動作 する。つまり、通話記録の処理は、ＤＤＣ内では行われない。ＤＤＣは、通話記 録ポーリング専用ではないが、多岐に渡るそれ以外のデータの収集、処理、およ び転送のタスクを実行する。 ストリーマ・システム６が、ＤＤＣ上のＦＴＡＭファイル記憶装置にアクセス するためには、識別を行う必要がある。これは、関連するエンドシステムとして ストリーマ６に対してネットワーク・ノード・アイデンティティ（ＮＮＩ）を割 り当てることにより実行される。それから、ＮＮＩは、パスワードとともに、Ｆ ＴＡＭファイル記憶装置にアクセスを得るためのユーザ名として使用される。 ３（ｉｉ） ストリーマ６およびデータ・アナライザ７ 図５を参照すると、ストリーマ６およびデータ・アナライ ザ７のハードウェアおよび通信の図は、以下のようになる（図５に示される通信 アーキテクチャは、さまざまな環境で適当である任意の数の通信アーキテクチャ の内の１つを表してるに過ぎないことを理解すべきである）。ストリーマ６には 、メイン・ストリーマ・システム６上で障害が発生するとすぐに割り込む「ホッ ト・スタンバイ」ストリーマ・ボックス・バックアップ（ＳＢＢ）６ａを備える 。この両方ともを、ＵＮＩＸオペレーティング・システムを実行するヒューレッ ト・パッカード社のＨＰ８５７Ｓミニコンピュータ上に設置することが可能であ る。ストリーマ６およびＳＢＢ６ａが、ローカルエリアネットワーク（ＬＡＮ） １５に接続される場合がある。 ストリーマ６（またはホット・スタンバイ６ａ）によりポールされるＤＤＣ５ （図５では図示されていない）からの未処理データは、光ディスク記憶装置シス テム（図示されていない）を使ってバックアップされる。データは、ＢＴメガス トリーム高速データリンクおよびマルチプロトコル経路選択ネットワーク（ＭＰ ＲＮ）５１０上でＦＴＡＭ（ファイル転送・アクセスおよび管理）を使ってポー ルされる。ＭＰＲＮ５１０は、ＯＳＩ（開放型システム間相互接続）に準拠する 。ストリーマ６およびデータ・アナライザ７の間には直接通信リンク５１５があ り、「イーサネット」ブリッジ５０５が、ＰＳＴＮ用にＢＴが使用するＷＡＮな どの、少なくとも１つのワイドエリアネットワーク（ＷＡＮ）５１０へのアクセ スを、ストリーマ６およびデータ・アナライザ７に提供する。 ＷＡＮ５１０は、主要ＢＴ ＰＳＴＮ網管理データ・センタに配置されている。 つまり、網管理データ・センタは、解析のため、および初期経路選択参照データ および更新済み経路選択参照データを入力するために、データの入出力を行うこ とができる。 図６を参照すると、データ・アナライザが、ヒューレット・パッカードＨＰ９ ０００上に具備されることがある。ストリーマ６およびデータ・アナライザ７の ソフトウェアは、以下に挙げる技術を活用する。 ●バッチ処理用のＩＥＦ ●専門家システム機能用ＡＲＴ／ＩＭ ●ＨＰ／ＵＸバージョン９．０ ●レポート用のＰＣクライアントとしてのビジネス・オブジェクト ●オラクル・バージョン６ −ＳＱＬＦＯＲＭＳ ３ −ＳＱＬ＊レポート・ライタ１．１ −ＰＬ／ＳＱＬバージョン１．０ −ＰＲＯ＊Ｃ −ＳＱＬ＊ＮＥＴ ＴＣＰ／ＩＰバージョン１．２ これらのすべては既知であり、公に利用できる。例えば、「ＩＥＦ」は、ジェ ームズ・マーチン・アソシエート（James Martin Associates）の「情報工学機 能」コンピュータ援用ソフトウェア工学（ＣＡＳＥ）ソフトウェアのことで、実 行可能コードを作成するソフトウェア工学ツールである。デー タ・アナライザ・プロセスは、データ・アナライザ７のプラットホーム上で物理 的に動作し、ストリーマ６のプラットホーム上でオラクル・データベース６０に 接続するためにＳＱＬ＊ＮＥＴを使用する。ＳＱＬ＊ＮＥＴ ＴＣＰ／ＩＰ（ト ランスポート・コントロール・プロトコル／インターネット・プロトコル）は、 ＭＰＲＮ５１０でのストリーマ６上、または適当なＴＣＰ／ＩＰ伝達網に位置す るオラクル・データベース６０にアクセスするために、ストリーマ／データ・ア ナライザ・ビジネス・オブジェクト・オラクル・ユーザ６５によっても使用可能 である。 ストリーマ６およびデータ・アナライザ７は、データベース機構６０を共有し 、ユーザが、ストリーマ６による妥当性検査で使用される参照データのチェック または更新などのために、アクセスを必要とする可能性がある。とりわけ、デー タベース機構６０は、ＤＤＣ５からのファイルが処理される制御を維持し、経路 選択参照モデルのバージョンを格納する。 ＰＲＯ＊Ｃコードは、図６に示されるように、ＩＥＦにより、ＩＥＦコード６ １および外部動作ブロック（ＥＡＢ）６２に作成される。ストリーマ／データ・ アナライザ・ソフトウェア・ライブラリ６３は、「Ｃ」モジュールおよびＰＲＯ ＊Ｃモジュールのセットであり、ＥＡＢ６２内から、あるいはＡＲＴ−ＩＭ（情 報管理用自動化理論ツール：アート）６４から呼び出すことができる。ＡＲＴ− ＩＭは、独占的な専門家システムであり、アプリケーション開発ソフトウェアで ある。ＡＲＴ−ＩＭの開発は、専門家システムへのモチーフ ・インタフェースである「スタジオ」の中で実行される。専門家システムの単体 テストが「スタジオ」内で実行されると、専門家システムは、「スタジオ」内か ら「Ｃ」モジュールを生成することにより配置される。したがって、例えば、Ｏ Ｓ／２ワークステーションでＩＥＦコード６１を作成し、そのコードをＥＡＢ６ ２、ストリーマ／データ・アナライザ・ソフトウェア・ライブラリ６３、および 配置プラットホーム上のＡＲＴ−ＩＭコード・ライブラリ６４にリンクさせるこ とにより、プロセスを作成することができる。 ３（ｉｉｉ） 企業システム８ 図７および８を参照すると、企業ボックス（またはシステム）８は、ＵＮＩＸ オペレーティング・システムを実行するヒューレット・パッカード社のミニコン ピュータ７０である「エメラルド８９０／４００（Emerald 890/400）」、ＯＲ ＡＣＬＥリレーショナル・データベース管理システム（ＲＤＭＳ）、およびジェ ームズ・マーチン・アソシエートのＩＥＦ ＣＡＳＥソフトウェアを使って作成 されるカスタム・アプリケーションから構成される。 企業ボックス８の中では、すべての通話記録は、複雑な料金設定参照テーブル および課金参照テーブルに従い料金設定され、ＯＲＡＣＬＥ要約テーブルが増分 される。参照テーブルは、交換機セットアップ・データ、経路選択参照データ、 会計処理協約、料金設定および課金データ、ならびにさまざまな例外クラスを提 供する。料金設定参照テーブルおよび課 金参照テーブルは、ＢＴの国内課金データベース（ＮＣＤＢ）および事業者間無 差別料金設定協約から得られる。 非常に大量の処理タスクが関係するミニコンピュータを補助するために、「７ ３５」などのヒューレット・パッカード社のＵＮＩＸワークステーション８０が 、処理タスクを獲得しようとするコプロセッサとして接続される。事実上無制限 な数のこのようなワークステーションは、企業ボックスが処理できる通話記録の 数を増加するために接続されるが、ＢＴ ＰＳＴＮの妥当な最少数は、現在のと ころ１２である。前述のように、本発明のデータ・システムは、１９９５年まで に一日あたり６，０００万の通話記録の処理を要求されることになる可能性があ る。装置は、ヒューレット・パッカード社の「タスク・ブローカ」８１という製 品に頼っており、本発明のデータ・システムは、バッチ・アレイ上で動作するた めにセットアップされている。これを行うためには、カスタム・パラメータをタ スク・ブローカに送信する必要があり、これらのパラメータの適切なセットを以 下にリストする。 ｉ）グローバル・パラメータ設定値（省略可能） −そのクライアントがサーバにアクセスすることができる −そのマシンが遠隔でタスク・ブローカを管理することができる −そのネットワーク・マスクが使用される −許容最少および最大ＵＩＤ（ユーザ・アイデンティティ） −ログ冗長性 −平行処理されるタスク提出の最大数 −クライアントがサービスのために接触する必要があるリスト・マシン ｉｉ）クライアント・パラメータ設定値（省略可能） −各サービス、クライアントがサービスのために接触する必要があるサーバ用の リスト ｉｉｉ）クラス・パラメータ設定値 −すべてのサービスはクラス内になくてはならない。それぞれのマシンが提供す るサービスのタイプごとにクラスをセットアップする。 ｉｖ）サービス定義（すべてのサービス用、以下を指定しなければならない） −クラス −アフィニティ −引数 アフィニティとは０−１，０００の間の数であり、どの程度うまくノードがサ ービスを提供できるかを示すことに注意する。 タスク・ブローカは、どのワークステーションがファイルを獲得しようとし、 ファイルを処理するのかを制御する待ち合わせシステムである。企業システム８ でタスク・ブローカを使用するためには、３つのプログラムおよび１つの構成フ ァイルが必要である。構成ファイルは、タスク・ブローカがどのワークステーシ ョンと通信できるのか、ファイルを処理するためにどのプログラムを呼び出すの か、および優先順位の設定方法を含め、それが企業システム環境で動作するのに 必要とするパラメータをセットアップする。前記に記述されているのが構成ファ イルのパラメータである。 ３つの制御プログラムは（要約すると）、以下のように動作する。ファイルが 企業システム８のエメラルド・ミニコンピュータに入ってくると、管理プログラ ム”ｒｕｎ＿ｃｐ．ｓｈ”がタスク・ブローカを経由して処理できるようにそれ を送り、モニタリング・プログラム”ｃｌｅａｎｕｐ＿ｃｐ．ｓｈ”をミニコン ピユータ内で開始する。タスク・ブローカは、第３のプログラム”ｃｐ．ｓｈ” に従ってファイルを処理するワークステーションにファイルを割り当てる。円滑 に事が運べば、ファイルは、ミニコンピュータに戻り、そこで”ｃｌｅａｎｕｐ ＿ｃｐ．ｓｈ”がファイルをクライアント・システム１０の正しいディレクトリ に割り当てる。また、”ｃｌｅａｎｕｐ＿ｃｐ．ｓｈ”は、ワークステーション もモニタする。ワークステーションによる処理で長すぎる遅延がある場合は、明 らかに問題が発生しているので、それはそのワークステーション上でタスク・ブ ローカをシャットダウンする。最後に、”ｃｌｅａｎｕｐ＿ｃｐ．ｓｈ”は、レ コードおよびイベント・ロギングも制御する。 最後に、クライアント・システム１０に対する出力だけではなく、企業ボック ス８からの料金設定済みの通話記録が、個々の料金設定済み通話記録が将来検索 および解析できるように、光ディスク・ドライブのアレイに保存される。 ３（ｉｖ） クライアント・システム（またはボックス）１ ０ 相互接続呼の要約ＯＲＡＣＬＥデータベース・テーブルは、毎週、企業ボック ス８からクライアント・ボックス１０にダウンロードされる。各クライアント・ ボックス（ＣＬＢ）１０は、ヒューレット・パッカード社のＵＮＩＸワークステ ーションであり、ＢＴと、マンクス・テレコム（Manx Telecom）のような別の事 業者間の単独の相互接続協約の元で作成される要約データベース・テーブルおよ び通話記録だけを処理する。クライアント・ボックス１０は、ＯＲＡＣＬＥ Ｒ ＤＭＳおよびビジネス・オブジェクト・ソフトウェアを実行する。各クライアン ト・ボックス１０からの情報を使用すると、ＢＴは、別のネットワーク事業者に 対して、そのＢＴのネットワークの使用に関して料金請求書を作成できるだけで はなく、別のネットワーク事業者からＢＴへ送られてくる請求書を検証すること もできる。また、各クライアント・ボックス１０は、光ディスク４１を調査する が、クライアント・ボックス１０に対応する相互接続協約の元での通話記録に対 してのみ行う。クライアント・ボックスは、ＢＴとその他の事業者の間の他の協 約に関する通話記録はおろか、それ自体の通話記録に関して直接企業ボックス８ を調べることもできない。パーソナル・コンピュータは、クライアント・ボック ス１０に接続され、要約テーブルの解析を可能にする。 ４．図９および１０：通話記録およびデータ・フォーマット ４（ｉ） 通話記録 英国電気通信会社の種別６の通話記録は、顧客に料金請求 書を作成・発行することを主要な目的として作成される。通話記録には、日付、 時刻、期間、移動距離、およびそれ以外の要因に基づいて、通話を正確に料金設 定するのに十分な情報が含まれなければならない。種別６の各通話記録には、以 下が含まれる。 ●料金請求書作成記録の長さ ●レコードの使用 ●レコード種別 ●通話種別および通話効果 ●クリア原因 ●時間断絶フラグ（通話中のＢＳＴから／へのＧＭＴに対する／からの変更） ●発信番号アイデンティティ（ＣＬＩ） ●経路グループ・タイプ ●サンプリング・カテゴリ ●経路グループ ●ノード・ポイント・コード（ＮＰＣ）：レコードを作成するＰＯＩ交換機の一 意の識別子 ●リンク・フィールド（呼が複数の時間料金バンドにまたがる場合に使用される ） ●発呼者カテゴリ（企業、住宅、公衆電話） ●料金バンド ●完了したアドレスの日付と時刻 ●応答の日付と時刻 ●発呼者クリアの日付と時刻 ●被呼者クリアの日付と時刻 ●かけられた番号のフィールド 通話記録は、システムＸ交換機のすべてで、通話会計処理サブシステム（ＣＡ Ｓ）収益分配会計処理（ＲＡＡ）機能により捕捉される。前述したように、ステ ップ２２０で、通話記録はＡＰＤＵにグループ化され、ＡＰＤＵはさらにファイ ルにグループ化され、それぞれのファイルは最高１メガバイトの大きさである。 システムＸのＰＯＩ交換機内のこのグループ化プロセスでは、個々の通話記録の いかなる部分も破損するものはない。すべての通話記録は、単純なバイナリ・フ ォーマットである。 図９を参照すると、各交換機ファイル４０には、可変長である多くのＡＰＤＵ ５１が備えられる。各ＡＰＤＵ５１はには、やはり可変長の多くの料金請求書作 成レコードが格納される。ただし、以下に示すものは、固定している。 ●交換機ファイル最大サイズ１メガバイト ●ＡＰＤＵ最大サイズ５１２バイト ●料金請求書作成レコード最大サイズ７０バイト ＤＤＣヘッダおよび後書きＡＰＤＵは、ヘッダＡＰＤＵの場合２４１であり、 後書きＡＰＤＵの場合２４５であるＡＰＤＵタイプは別にして、同一である。 以下に示す情報は、ヘッダおよび後書きＡＰＤＵで利用できる。 ＡＰＤＵ長．．．．．．．ヘッダ／後書きＡＰＤＵの長さ ＡＰＤＵタイプ．．．．．ヘッダの場合２４１、後書きの場 合２４５ 一意なファイル識別子．．以下の、関係するＤＩＲＩＮＤＥＸを参照する。 宛先ＮＮＩ．．．．．．．ＩＮＣＡストリーマのＮＮＩ アプリケーション・グループ．．ＩＮＣＡデータのアプリケーション・グループ ＝１４ 入力テープ／カートリッジ・ シーケンス番号．．．．テープ／カートリッジのシーケンス番号 出力ファイル・シーケンス番号：ＤＤＣシーケンス番号 タイム・スタンプＤＤＣ受信データ．．ＤＤＣにより受け取られる日付と時刻の データ パートファイル・インジケータ．．ファイルがパート・ファイルであるかどうか を示す。 例外インジケータ．．何がファイルで故障しているのかを示す。 読み取りカウント．．このファイルが読み取られる回数 ファイル・サイズ．．このファイルのバイト単位のサイズ 未選択ＡＰＤＵのカウント．．誤ったＡＰＤＵタイプの数 選択ＡＰＤＵタイプ．．．．．ＩＮＣＡデータ型のＡＰＤＵタイプ ＡＰＤＵカウント．．．．．．このファイル内のＡＰＤＵの数 最初のシーケンス番号．．．．ＡＰＤＵシーケンス番号を開始する。 最後のシーケンス番号．．．．ＡＰＤＵシーケンス番号を終了する。 読み取りカウントは、このファイルが、ストリーマ６によりＤＤＣからポール された回数を表す。パートファイル・インジケータは、ファイル全体が無事にＤ ＤＣ５から受け取られたのか、あるいはファイルの部分が失われていないのかを 示す。 例外インジケータは、この転送に関係してＤＤＣ５により検出されたあらゆる エラーを示す２個の１バイト・ビットマスク・フィールドである。 前記フィールドのすべての有効値は、「企業システム（ボックス）」ＤＤＣ５ により適切なディレクトリにコピーされる８を参照して下記に説明するコンピュ ータ演算ソフトウェア工学（ＣＡＳＥ）と「企業システム（またはボックス）８ 」内で検査されるであろう。 図１０を参照すると、ＡＰＤＵ構造５１の簡略な説明には、ＡＰＤＵ５２、関 係する実際の料金請求書作成レコード５３、およびＡＰＤＵ後書き５４が含まれ る。 料金請求書作成レコード５３のフォーマットは標準型で、「Ｃ」構造は、その フォーマットにマップするように設計できる。 データが交換機３からＤＤＣ５にポールされると、各データＡＰＤＵの先頭に あるデータのある部分が、ＤＤＣ５により取り除かれる。このデータは、ＤＤＣ ５および交換機３を表し、エンド処理システム用データ送りとして適当ではない 。 ＦＴＡＭを使用してコピーするためのストリーマ６で利用できるように、ファ イルが、ＤＤＣ５により適切なディレクトリの中にコピーされると、ＤＩＲＩＮ ＤＥＸというカタログ・ファイル内でそれに対する入力が行われる。ＤＩＲＩＮ ＤＥＸファイル・エントリは、以下のデータを持つ。 ｉ）以下を示す活動マーカ（１バイト） ａ）非活動状態のエントリ ｂ）転送に使用できるファイル ｃ）現在使用中のファイル（例えば、ＦＴＡＭ転送での） ｄ）無事に転送され（まだ削除されていない）たファイル ｉｉ）ＩＮＣＡファイル名フォーマット ｉｉｉ）以下を示す出力経路選択 ａ）ＦＴＡＭに利用可能なファイル ｂ）磁気テーブル専用 ｉｖ）作成時、および関連交換機ＮＮＩなどの詳細を含む一意のファイル識別子 ｖ）バイト単位のファイル・サイズ ｖｉ）ファイル内でのＡＰＤＵの数 ｉｉ）ＩＮＣＡファイル名フォーマットを参照すると、これには、以下のもの が含まれる。 ｖｉｉ）ストリーマＮＮＩ ｖｉｉｉ）ＮＮＩおよび交換機のクラスタ数 ｉｘ）ＩＮＣＡデータのアプリケーション・グループ ｘ）交換機ファイルのＤＤＣファイル・シーケンス番号 ４（ｉｉ） データ構造体を交換機データにマッピング ストリーマ６は、以下の原則を使って、企業ボックス８のモデルで使用するた めのデータ構造にデータをマップする。 ●ＡＰＤＵ長フィールドおよび料金請求書作成レコード長フィールドが正しいと 仮定する。これらが正しくない場合には、妥当性検査は、ＡＰＤＵレベルあるい は料金請求書作成レコード・レベルのどちらかで失敗し、ファイルはデータ・ア ナライザ７にストリームされる。 ●入力データは、最初は、ヘッダＡＰＤＵ５２を見つけるためにスキャンされる 。これは、２４１というＡＰＤＵタイプ（１６進数Ｆ１）により識別される。そ れから、選択されたＡＰＤＵタイプ・フィールドが、一意なファイル識別子とと もにチェックされ、これが本当にヘッダＡＰＤＵ５２であることを確かめる。 ●ヘッダＡＰＤＵ５２が発見され、ヘッダＡＰＤＵデータ構造体がマップされた 後では、ファイル内のすべてのＡＰＤＵは、／ＨＥＡＤＥＲ＿ＡＰＤＵＲＬ／Ａ ＰＤＵ／ＲＬ／ＡＰＤＵ．．．ＲＬ／ＡＰＤＵ／ＲＬ／ＴＲＡＩＬＥＲ＿ＡＰＤ ＵなどのＡＰＤＵが後に続く１ワードのレコード長のデータ標準に従うと仮定さ れる。この場合ＲＬはレコード長である。 ●ファイルの構造がこの標準から外れている場合は、ファイルはさらに解析を行 うためにデータ・アナライザ７にストリームされる。このエラー条件は、外れた 直後にＡＰＤＵの妥当性検査で検出される。 ●各ＡＰＤＵ内では、構造は図６の構造に従うと仮定される。再び、この構造か ら外れることにより、データ構造マッピン グ全体が調整不良になり、ファイルの拒絶や、データ・アナライザ７へストリー ムにつながる。 ●後書きＡＰＤＵ５４の後ろにはデータはないと仮定される。後書きＡＰＤＵ５ ４の後に表示されるデータは失われるであろう。 ５． 図１１から１９および図２２から３０：ストリーマおよびデータ・アナラ イザ・プロセス ５（ｉ） ストリーマ：ＤＤＣポーリング・プロセス ファイルは、ＤＤＣ５により受け取られると、（チェックサム処理を使用して ）検査され、図２に関して前述したように、特別の情報が、ＡＰＤＵヘッダおよ び後書き５２、５４のファイルの始めと終わりに追加される。それから、これら のファイルは、ストリーマ６により使用されるディレクトリ構造の中に格納し、 ＤＩＲＩＮＤＥＸファイルを更新することにより、ストリーマ６によるポーリン グで使用できるようになる。このＤＩＲＩＮＤＥＸファイルには、ストリーマ６ によるポーリングに使用できるすべてのリストのファイルが記憶され、ストリー マ６は、そのリストを使用して、それが新規ファイルのすべてをポールしたこと を確認する。 図１１を参照すると、ストリーマ６は、「全ＤＤＣストリーム」プロセスに入 ることにより、複数のＤＤＣ５をポールする用意をする。ステップ７００で、ス トリーマ６の「全ＤＤＣストリーム」プロセスが、指定時などにトリガされる。 ステップ７１０では、このプロセスは、ストリーマ６がＤＤＣ５からファイルを 受け取るのに使用できるかどうかのチェ ックを実行する。ストリーマ６が使用できる場合は、このプロセスは、ステップ ７２０、７３０および７４０のサイクルに入り、ＤＤＣ５のリストを通して実行 し、ポーリングの対象となるＤＤＣ５ごとに「ＤＤＣプロセス」を作成する。リ ストの最後で、このプロセスは終了する（ステップ７５０）。 今度は、各ＤＤＣ５に対して、ストリーマ６は、「ＤＤＣプロセス」を実行す る。図１２を参照すると、ステップ８００、８０５で、ＤＤＣプロセスは、その プロセスに関係するＤＤＣ５またはストリーマ５のどちらかがシャットダウンさ れているかどうかという点についてのチェック、およびステップ８１０での、Ｄ ＤＣポーリングが期限になっているかどうかについてのチェックから開始する。 ＤＤＣ５をポールすることができない一定の期間があり、ステップ８１５は、非 ポール・ウィンドウが適用するかどうかについてのチェックを実行する。適用し ない場合には、ステップ８２０がファイルの処理を行うために空きプロセス・ス ロットを探す。これらのチェックのすべてがクリアになると、ストリーマ６はス テップ８２５でＤＤＣ ＤＩＲＩＮＤＥＸにアクセスし、ステップ８３０でプロ セス・リストを、ステップ８３５でファイル・リストを起動し、これによりスト リーマ６がすべての関連プロセスをＤＤＣ５から受け取られた交換機ファイルの それぞれに適用することが確認される。ステップ８４０、８４５、および８５０ では、ストリーマ６が、ＤＤＣ ＤＩＲＩＮＤＥＸからのファイルを実行し、処 理対象の交換機ファイルの専用のログを作成し、ステップ８５５および８６０で ファイル・リスト中のファイルを処理するためのファイル処理容量を実現する。 ＤＤＣ ＤＩＲＩＮＤＥＸリストのすべての交換機ファイルが、処理容量を割り 当てられた場合、「ＤＤＣプロセス」が、ステップ８６５で時間ポールが期限と なる時点についてのそのレコードを更新し、ステップ８７０で休眠に戻る。 ＤＤＣ５またはストリーマ６がシャットダウンした場合には、ＤＤＣプロセス は、言うまでもなく、ステップ８７５で停止され、ステップ８７０で休眠モード のままとなり、ポールが期限になっていない場合は常に、ＤＤＣは非ポール・ウ ィンドウにいるか、利用できる処理容量がない。 ｄｄｃポーリング・アーキテクチャ内での典型的なイベント・サイクル 以下を想定する。 ＤＤＣ＿ＰＯＬＬＩＮＧ＿ＭＰＨ＝１７・・・ポールを行う時間を経過した分数 である。 ＤＤＣ＿ＰＯＬＬＩＮＧ＿ＩＮＴ＿ＨＲＳ＝１・・・次のポールまでどの程度待 機するのかを時間数単位で示している。 ＤＤＣ＿ＤＥＬＡＹ＿ＩＮ＿ＤＥＬＥＴＥ＝１２・・・実際の削除要求発生前に 、ファイルが削除に関してマークされてから、どの程度待機するかを示す。 システムは、前日の時間スケジュールで２３：３０にブートされた。 ００：１７ ＤＤＣプロセスが目を覚まし？、ＤＩＲＩＮ ＤＥＸファイルでコピーし、データをストリーマ６にストリームするためのプロ セスを作成する。 ００：３０ ＤＤＣプロセスは、最大数のプロセスが作成されたか、あるいは使 用できるファイルのすべてが、ダウンロードするファイル・プロセスに渡された ため、ファイルをストリームするプロセスの作成を終了する。目覚まし時間は、 ００：３０＋ＤＤＣ＿ＰＯＬＬＩＮＧ＿ＩＮＴ＿ＨＲＳとして計算され、分数を ＤＤＣ＿ＰＯＬＬＩＮＧ＿ＭＰＨにセットする。 ＝＞次のポーリング時間＝００：３０＋１：００＝１：３０（ＳＥＴ ＭＰＨ） ＝０１：１７ 休眠する秒数を計算する＝ＴＯ＿ＳＥＣＯＮＤＳ（０１：１７−ＣＵＲＲＥＮＴ ＿ＴＩＭＥ） 休眠（ｓｅｃｏｎｄｓ＿ｔｏ＿ｓｌｅｅｐ） ．．．ファイル・プロセスはデータのストリームを完了する。 ０１：１７ ＤＤＣプロセスが目を覚ます。 ５（ｉｉ） ストリーマ：ファイル・プロセス 図１３を参照すると、ＤＤＣプロセス中のステップ８５５で作成されるファイ ル・プロセスの動作は、以下のとおりである。ファイル・プロセスは、ステップ １３０２でＤＤＣプロセスから受け取られたファイル・リストから作業する。ス テップ１３０３でファイル・リストを実行し、ファイル・プロセスは、リストさ れている交換機ファイルごとに、ステップ１３０５で交換機ファイル・ログを読 み取り、ステップ１３０６で通話レコードを検査し、ステップ１３０７で、スト リーマ６がそれ以降ダウンした場合に使用するために未処理レコードのバックア ップにファイルをコピーし、ステップ１３１０で妥当性検査失敗があった場合に はファイルをデータ・アナライザ７に転送するか、ステップ１３１２でファイル を企業ボックス８にストリームする。 ＤＤＣ５またはストリーマ６がステップ１３０４でシャットダウンされる場合 、あるいはＤＤＣ５との通信が失敗したためにステップ１３１１でひどく破損し ている場合は、ファイル・プロセスはステップ１３１３で停止する。交換機ファ イル・ログは、交換機ファイルがストリーマ６に関してどの段階に到達したのか をモニタし、それぞれのファイルにアクティブ、処理済み、および削除済みの中 から選択されたステータスを付ける。この場合、「アクティブ」は、ファイルが ストリーマ６により処理中であることを示し、「処理済み」はファイルがストリ ーマ６により処理されたことを示し、「削除済み」は、ファイルがストリーマ６ によりＤＤＣ５から削除されたことを示している。 図１４を参照すると、通話記録が検査されるステップ１３０６を、以下に示す ように拡張することができる。この時点では、交換機ファイルは、ステップ１４ ０１および１４０２でＤＤＣ５からコピーされ、ファイル・ヘッダおよび第１Ａ ＰＤＵヘッダ５２がステップ１４０３、１４０５で検査される。どちらかが正常 に終了しないと、ファイル・エラー・ログがステップ１４１２で作成される。両 方とも正常に終了した場合には、通話記録はそれぞれステップ１４０７、１４０ ８で検査され、一方が正常に終了しない場合は、通話記録エラー・ログがステッ プ１４０９で作成される。妥当性検査がすべてが正しいことを示しても、あるい はエラーがログされたとしても、監査追跡はステップ１４１３で更新され、ファ イル・プロセスは前記のようにステップ１３０７に移動する。 図１５を参照すると、ファイル・プロセス中に検査されたファイルが、ここで 企業ボックス８に移動する用意ができている。この段階で、個々の通話記録５３ を、それらが関連する料金請求書作成可能事業体に従って分類できるように、フ ァイル構造が分類される。通話記録５３は、ステップ１５０３で、異なった料金 請求書作成可能事業体に関して物理ファイルに書き込まれる。 ５（ｉｉｉ） ＤＤＣファイル削除プロセス データ・ファイルがＤＤＣ５からストリーマ６に無事にダウンロードされ、デ ータが拡張され、適切な企業ボックス８にストリームされると、データ・ファイ ルは、ＤＤＣ上のＦＴＡＭファイル記憶装置から削除されなければならない。ス トリーマ６は、ファイルが、企業ボックス（または企業ボックス８へのリンクが ダウンしてしまった場合にはローカル記憶装置）上で保全されてからかなりの時 間が過ぎてから、ＦＴＡＭ削除要求を使ってファイルを削除する。データ保全と ファイル削除の間の正確な時間は、ＤＤＣ単位で設定することができる。 （ｉｖ） データ・アナライザ：プロセス 図１６を参照すると、ＦＩＬＥ ＰＲ ＯＣＥＳＳで通話記録を検査するステップ、つまり図１３のステップ１３０６は 、ステップ１４１２でファイル・エラー・ログを、ステップ１４０９で通話記録 エラー・ログを作成する。データ・アナライザ７は、ＨＰ９０００のブートアッ プ・シーケンス中に起動される”ＤＸ ＰＲＯＣＥＳＳ”と”ＳＵＳＰＥＮＳＥ ＦＩＬＥ ＰＲＯＣＥＳＳ”という２つのプロセスを実行する。 ＤＡ ＰＲＯＣＥＳＳは、ストリーマ６により送信されたデータが、データ・ アナライザ７による処理さに利用できるかどうかを連続してモニタする。このデ ータは、データがストリームできなかった個々の通話記録を記憶するのか、ある いはファイル・レベルでの障害だったのかに関係なく、常に、元の交換機ファイ ルとして存在するであろう。 データ・アナライザ７が、ステップ１６０２でシャットダウンとしてフラグが 付けられていない限り、ＤＡ ＰＲＯＣＥＳＳは、ステップ１６０３で最初に処 理対象のもっとも古いファイル・エラー・ログを選択し、ステップ１６０４でそ れがファイル／ＡＰＤＵレベルの障害であったのか、あるいは通話記録レベルの 障害であったのかをチェックする。 図１６、１７および２０を参照すると、障害が通話記録レベルであった場合、 ＤＡ ＰＲＯＣＥＳＳは、ステップ１７０２で、ファイルに関して次の通話記録 エラー・ログを選択し、ステップ２０００で訂正のために関連通話記録をＡＲＴ ＩＭルール・ベースに送る。障害がファイル・レベルであった場合には、交換 機ファイル全体がストリーマ６により拒 絶された。この場合、完全なファイルが、ステップ１６０６でメモリにロードさ れ、ファイル・ヘッダおよびＡＰＤＵ５１が、ステップ１６０７で訂正のために ＡＲＴ ＩＭに送信される。 データ・アナライザ７により実行される解析には複数の結果がある。修正可能 データは、訂正のためにＡＲＴ ＩＭに送られ、それ以降検査され、企業ボック ス８にストリームできる。経路選択エラーが関係すると、システム内のどこかに ある経路選択情報が、更新を必要とするために問題がある場合は、記録データは 未決状態にされる。経路選択情報の訂正後に、通話データを検査することも可能 である。ファイル全体を読み取ることができない場合には、ファイルは、バイナ リ・フォーマットのままでバイナリ・ファイル・ダンプに送らなければならない 。ファイルなどのデータが、ＡＲＴ ＩＭにより修復不能であると判断され、エ ラーが経路選択に関係し、未決が正当化される場合には、それをアーカイブに入 れることができる。データの料金請求書は決して作成されないが、解析で使用さ れ、データはそれ自体を訂正可能であるため、将来、料金請求書作成可能項目を 失うことを回避できるようにする長期または重大な問題点を識別する。 図１６に戻ると、３５でＡＲＴ ＩＭを使用し、ステップ１６０５と１６０７ でチェックを実行したメインのＤＡ ＰＲＯＣＥＳＳは、次に、修復不能として ＡＲＴ ＩＭから戻されたファイルを分類する。ステップ１６０８でそれでもフ ァイルを読み取ることができない場合には、ファイルは、バ イナリ・ファイル・ダンプに転送される。これらのファイルは、１６進数、８進 数またはＡＳＣＩＩのフォーマットであり、後の時点で解析に使用される可能性 があるため、読み取られる可能性がある。代わりに、ファイルはデータ・アナラ イザにより読み取られる可能性はあるが、依然としてＡＲＴ ＩＭｎｉより「修 復不能」と評価される。これらのファイルは、ステップ１６０９で、「貯蔵庫」 データベースにロードされ、ファイルはここでも決して料金請求書作成可能デー タは提供しないが、照会および解析は可能である。 ファイルがＡＲＴ ＩＭに送られ、修復可能であった場合、ＡＲＴ ＩＭはス テップ１６１０と１６１１で、各通話記録を順次戻す。その後で、ＤＡ ＰＲＯ ＣＥＳＳは、ステップ１６１２で経路選択障害がないかどうかチェックし、通話 記録障害が存在する場合には、ステップ１６１５で通話記録エラー・ログを作成 することにより、これらの通話記録を初めて検査する。これらの通話記録は、ス テップ１６０３から１６０５およびステップ１７０１から１７０３で、ＡＲＴ ＩＭを通して選択され再実行される。通話記録が許容できるものであれば、ステ ップ１６１６から１６１８を介して、企業ボックス８にストリームされる。 ステップ１６１２、１７０４または１９０７で検出された（以下参照）通話記 録経路選択障害があった図１８を参照すると、通話記録はカテゴリに分類され、 中断される。つまり、障害は解析され、それがステップ１８０２で既存の経路選 択エラー・パターンに照合されてから、通話記録が、ステップ １８０３で同じ経路選択エラー・パターンを示すすべての通話記録を記憶する既 存のパターン・ファイルに追加される。これらのパターン・ファイルは未決状態 で保持され、主要ＢＴ ＰＳＴＮ網管理者およびデータ・センタは通知される。 それからは、別個のプロセスである、ＳＵＳＰＥＮＳＥ ＦＩＬＥ ＰＲＯＣＥ ＳＳがこれらのファイルを処理する。 ＳＵＳＰＥＮＳＥ ＦＩＬＥ ＰＲＯＣＥＳＳは、データ処理の「主流」外で 訂正できる可能性があるエラーが発生したファイルのカテゴリとなるため、デー タ・アナライザ７の重要な点である。システム内のどこかにある経路選択データ は更新されていないために、これらのファイルはエラーが発生したとして選択さ れただけである。これらの料金請求書は作成可能であるかもしれない。ＳＵＳＰ ＥＮＳＥ ＦＩＬＥ ＰＲＯＣＥＳＳを使用して、主要な網管理データ・センタ は、システム内の経路選択データを更新しつつ、以前にエラーが発生したと判断 されたファイルも捕捉する機会を得る。さらに、特定の経路パターンの既存パタ ーン・ファイル「経路パターン中断ファイル」に通話記録を付加すると、ファイ ルは、選択された経路パターン中断ファイルを実行するだけで、ファイルを妥当 性検査の再試行に選択することができる。 図１９を参照すると、ステップ１９０２でプロセスがシャットダウンされてい ない限り、ステップ１９０３で網管理データ・センタなどによりもっとも古い経 路選択パターンを見つけ出すと、ＳＵＳＰＥＮＳＥ ＦＩＬＥ ＰＲＯＣＥＳＳ が開始する。それからこのプロセスは、ステップ１９０４で その経路選択パターンを記憶する次の中断ファイルを選択し、ステップ１９０５ と１９０６で通話記録を検査しようとする。言うまでもなく通話記録に複数の経 路選択エラーが存在する場合がある。これが当てはまる場合には、ＳＵＳＰＥＮ ＳＥ ＦＩＬＥ ＰＲＯＣＥＳＳは、図１８のステップ１８０１に戻り、経路選 択エラー・パターン・ファイルに経路選択エラー・エントリを作成し、それで通 話記録を再中断する。しかし、他に経路選択障害が存在しない場合には、ＳＵＳ ＰＥＮＳＥ ＦＩＬＥ ＰＲＯＣＥＳＳは、図１５のステップ１５０１に戻るこ とにより、通話記録を企業ボックス８にストリーム使用とする。ＰＲＯＣＥＳＳ は、ステップ１９１０でこのようにして中断ファイルの通話記録のすべて、およ びステップ１９１１で、その特定の経路パターンに関して中断されたすべてのフ ァイルを実行する。 図２２を参照すると、これは、ストリーマ・システム６、企業ボックス８、お よびデータ・アナライザ７の間のプロセス相互作用を示す。ストリーマ６のメイ ン・プロセス領域は、”ＦＩＬＥＰＲＯＣＥＳＳ”と呼ばれる領域である。この 領域が、すべての検査およびファイル上の固有の動作を実行する。データ・アナ ライザ領域では、データを専門家システムに入力する”ＩＤＡ ＦＩＬＥＰＲＯ ＣＥＳＳ”が存在する。重要な点は、このプロセスが、データを経路パターン中 断ファイルに付加することにより、経路パターン中断ファイルおよび”ＳＵＳＰ ＥＮＳＥ ＦＩＬＥＰＲＯＣＥＳＳ”をトリガするという点である。ＳＵＳＰＥ ＮＳＥ ＦＩＬＥＰＲＯ ＣＥＳＳはメインＩＤＡ ＦＩＬＥＰＲＯＣＥＳＳの外で動作するため、これに よりデータ蓄積の大きなバックログを回避する。もう一つの重要な領域が、出力 を”ＳＵＭＰＬＯＡＤＥＲ”から受け取る”ＳＵＭＰＤＡＴＡＢＡＳＥ”である 。ＳＵＭＰＤＡＴＡＢＡＳＥ内のデータは訂正できないが、このデータは、ＩＤ Ａ ＦＩＬＥＰＲＯＣＥＳでのルールが変更できる可能性があるため、それ以降 のデータを再ストリームできるように、照会および解析することができる。 図２２では、プロセスは丸で囲んで示されており、企業ボックス８はブロック として、データ・ファイル、ログ、およびリンクは、両端とも開いた平行線の間 に図示され、アーカイブに入れられたデータは、従来のデータベース用の記号で 表記されている。 プロセス、記憶されたデータ、図２２で（ａ）から（ｙ）と参照される相互作 用は、以下に示すようにリストされ、矢頭は関連する転送方向を示している。 ａ）ＮＮＩおよび処理、転送対象のファイル名のリスト ｂ）作成された交換機ファイル・ログ、ＳＴＡＴＵＳ＝Ａ ｃ）アクセスされたＤＩＲＩＮＤＥＸファイル ｄ）コピーされたＦＴＡＭ交換機ファイル ｅ）削除されたＦＴＡＭ交換機ファイル ｆ）ＳＴＡＴＵＳ＝Ｐの場合の読み取られた交換機ファイル ｇ）交換機ファイルが（前記（ｅ）で）無事に削除された場合にＤに設定される ＳＴＡＴＵＳ ｈ）ＳＴＡＴＵＳ＝Ａの場合に読み取られる交換機ファイル ・ログ ｉ）更新された交換機ファイル・ログ・データ。ＳＴＡＴＵＳはＰに設定。 ｊ）ファイルがエラー状態にあるため、ファイル・エラー・ログが作成された。 ｋ）通話記録がエラー状態にあるため、通話記録エラー・ログが作成された。 ｌ）ファイルがエラー状態にある場合は、ファイルはデータ・アナライザ・ディ レクトリにコピーされる。 ｍ）読み取られたファイル・エラー・ログ ｎ）読み取られた通話記録ログ ｏ）検索された未処理（バイナリ）データ・ファイル ｐ）この経路パターンに関して経路パターン中断ファイルに付加されたデータ ｑ）経路エラー・パターンで行われた入力 ｒ）ＡＲＴ／ＩＭにより作成されたもっとも近い一致 ｓ）ＡＲＴ／ＩＭは、このデータを修復できないと確認した。 データは、さらに解析するため、あるいは削除するためにＳＵＭＰに格納される 。 ｔ）ユーザは、問題が修復できないことを確認した。ファイルは、さらに解析す るため、あるいは削除するために、貯蔵庫に格納される。 ｕ）ファイル構造が理解できないものである場合、ファイルはバイナリ・ファイ ル・ダンプに入れられる。 ｖ）ストリームされたファイルが作成される。 ｗ）準備完了に設定された経路エラー・パターンのステータスにより、ＳＵＳＰ ＥＮＤ ＦＩＬＥ ＰＲＯＣＥＳＳが起動される。問題が繰り返し発生する場合 には、カウント・フィールドを更新し、ステータスをＳＵＳＰＥＮＤＥＤに設定 する。 ｘ）選択した解決策が問題を修復できない場合、もっとも近い一致が更新される 。 ｙ）ストリームされたファイルが作成される。 ５（ｖ） 事業体存続履歴 図２３から３０を参照すると、事業体存続履歴図は、その事業体内のレコード がそのステータスにあること、およびその状態から他の状態がその動作により到 達できるステータスを示すことができる。これらの図のそれぞれで、ステータス は、単に、参照数値２３００により識別され、ステータスの定義は以下に示す。 図２３：ファイル・エラー・ログ ＲＥＡＤＹ（準備完了）−ファイルがデータ・アナライザ７によりストリームさ れる準備が完了している。 ＳＵＳＰＥＮＳＥ（未決）−ファイル全体、あるいはファイル内の少なくとも１ つの通話記録が未決領域に送られた。 ＢＩＮ（ビン）−ファイルは、データ・アナライザによって読み取ることができ ず、ビン領域に送られた。 ＳＵＭＰ（貯蔵庫）−ファイル全体が貯蔵庫領域に送られた。 ＣＯＭＰＬＥＴＥ（完了）−データ・アナライザ７がフ ァイルをストリームし、未決領域にあるファイル通話記録のどれかが無事に再ス トリームされるか、あるいはアーカイブに入れられる。 図２４：通話記録エラー・ログ ＲＥＡＤＹ−通話記録がデータ・アナライザ７によりストリームされる準備が完 了している。 ＳＵＳＰＥＮＳＥ−通話記録が未決領域に送られた。 ＳＵＭＰ−通話記録が貯蔵庫領域に送られた。 ＡＲＣＨＩＶＥＤ（アーカイプ）−通話記録がトラッシュ領域（つまり、ＡＲＣ ＨＩＶＥＤ）に送られた。 ＣＯＭＰＥＴＥ−データ・アナライザ７が通話記録を無事にストリームした。 ＶＡＬ ＦＡＩＬＵＲＥ−ＡＲＴ−ＩＭおよびＩＥＦ妥当性検査プロシージャに 相違がある。 図２５：経路エラー・パターン ＵＮＳＥＬＥＣＴＥＤ（未選択）−ＡＲＴ−ＩＭにより作成され、データ・アナ ライザ・ユーザにより解析されるのを待機するか、あるいは解析後に再ストリー ムされるが、失敗した。 ＰＥＮＤＩＮＧ（ペンディング）−データ・アナライザ・ユーザにより解析のた めに選択された。 ＲＥＡＤＹ−データ・アナライザ・ユーザが解析を終了し、再ストリームの準備 完了している。 ＣＬＯＳＥＤ（クローズ）−無事に再ストリームしたか、ＡＲＣＨＩＶＥＤ。 図２６：もっとも近い一致 ＵＮＳＥＬＥＣＴＥＤ（ＯＲ ＮＵＬＬ）−ＡＲＴ−ＩＭにより作成される。 ＳＥＬＥＣＴＥＤ（選択）−データ・アナライザ・ユーザにより、解析のために 選択された。 図２７：貯蔵庫ファイル・ログ ＳＵＭＰ（貯蔵庫）−ファイルはＳＵＭＰ＿ＰＲＯＣＥＳＳの準備完了している 。 ＰＲＯＣＥＳＳＩＮＧ（処理）−ファイルが、データ・アナライザ・ユーザによ り表示される準備が完了している。 ＡＲＣＨＩＶＥＤ−ファイルがアーカイブに入れられた。 図２８：ファイル経路エラー・リンク ＳＵＳＰＥＮＤＥＤ−ファイルが未決領域にある。 ＣＯＭＰＬＥＴＥ−ファイルが、未決領域から無事に再ストリームされた。 図２９：交換機ファイル・ログ Ａ（ＣＴＩＶＥ）（アクティブ）−交換機ファイルが、ストリーマにより処理さ れているところである。 Ｐ（ＲＯＣＥＳＳＥＤ）（処理済み）−交換機ファイルがストリーマにより処理 された。 Ｄ（ＥＬＥＴＥＤ）（削除済み）−換機ファイルがストリーマにより削除された 。 図３０：地域データ・コレクタ （すべてのステータスは、ＳＱＬ＊Ｆｏｒｍｓを介してストリーマ６のユーザに より変更される。） Ｐ（ＲＥＢＩＳ）−ＤＤＣがｐｒｅｂｉｓ？である。 Ｌ（ＩＶＥ）（ライブ）−ＤＤＣがライブである。 Ｃ（ＥＡＳＥＤ）（終了）−ＤＤＣが終了した。 図６を参照すると、ストリーマ６／データ・アナライザ７・ソフトウェア・ア ーキテクチャが、ＩＥＦ外部動作ブロック（ＥＡＢ）６２を具備することが分か るであろう。ＥＡＢ６２は、ＩＥＦ内で実行するのが不適切または不可能な場合 に使用される。例えば、ＥＡＢ６２を使って以下の機能が、実行される。 ●「通話記録を未決に追加」 このモジュールは、未決ファイルに送らなければならない交換機ファイルの通 話記録が入ったリンク済みリスト内で、通話記録の新規エントリを作成する。 ●「通話記録をアーカイブに追加」 修復されたが、アーカイブ・ディレクトリに再ストリームできない交換機ファ イルの通話記録が入ったリンク済みリスト内で、通話記録の新規エントリを作成 する。 ●「ネットワーク事業者レコードを追加」 これが新規のネットワーク事業者であるかどうかをチェックし、新規のネット ワーク事業者である場合には、”ｎｅｔｗｏｒｋ＿ｏｐｅｒａｔｏｒ＿ｓｔｒｕ ｃｔｕｒｅ”のリンク済みのリスト内に新規エントリを作成する。これがすでに 使用されているネットワーク事業者名である場合には、リンク済みのリスト・エ ントリをそのネットワーク事業者の通話記録のリンク済みのリストに追加する。 通話記録に修復が適 用された場合、それは、「ネットワーク事業者レコード」で”ｃａｌｌ＿ｒｅｃ ｏｒｄ＿ｅｒｒｏｒ＿ｌｏｇ”アイデンティティおよびストリームされた通話記 録のシーケンス番号を更新する。 ●「ＩＤＡルールに従った通話記録」 １つの通話記録をデータ・アナライザＡＲＴ−ＩＭルール・ベースに渡す。通 話記録は、ＩＥＦにより渡されるＡＰＤＵシーケンス番号および通話記録シーケ ンス番号により識別される。それから、通話記録および所有しているＡＰＤＵ、 ならびいファイル・ヘッダ・データがないかどうか、メモリ内にロードされるデ ータ構造が探索される。その後で、このデータがルール・ベースに送られ、検査 される。検出されるあらゆるエラーのそれぞれが、通話記録ルール・ログ行エン トリを作成する。通話記録エラー・ログ・レコード・ステータスも、ルール・ベ ースにより更新される。 ●「コミット」 すべての現在のデータベース変更をコミットする。 ●「ＤＤＣプロセスの作成」 特定のＤＤＣのポーリングを担当するＤＤＣプロセスの発生を作成する。これ は、子プロセスにファイフォ（ファイル・イン／ファイル・アウト）を作成／オ ープンし、ファイフォの中にＤＤＣ ＮＮＩの値を書き込む。 ●「ファイル・プロセスの作成」 ファイル名のアレイで渡されるファイル名をストリームするというタスクを実 行するプロセスを作成する。 ●「ＤＤＣからファイルを削除」 ＦＴＡＭプロトコルを使って、ＤＤＣ上のディスクからファイルを削除する。 ●「データ・アナライザ・ファイルの削除」 ファイルをストリーマ／データ・アナライザ・ディレクトリから削除する。 ●「未決ファイルの削除」 未決ファイル・ディレクトリからファイルを削除する。 ●「ファイルをビンへ」 ＡＲＴ／ＩＭルール・ベースの中に読み込む個とができないファイルをバイナ リ・ファイル・ダンプに引き渡す。 ●「ファイルをデータ・アナライザ・ルールへ」 ファイル全体をデータ・アナライザＡＲＴ−ＩＭルール・ベースを引き渡し、 ルール・ベースを初期化する。ルール・ベースの初期化には、旧データのクリア 、デフォルト・データおよび経路選択参照データの選択、およびルール・ベース のそのデータによる実装が必要になる。データ・アナライザ・バイナリ・ファイ ルは、それからメモリ内のデータ構造の中にロードされる。このデータは、それ から、ルール・ベースに送られ、検査される。検出されるすべてのエラーが、そ れぞれ適切なルール・ログ行エントリを作成する。通話記録エラー・ログは、経 路エラー・パターン、もっとも近い一致、およびファイル経路エラー・リンク・ レコードとともに、該当する場合は、ルール・ベースにより作成される。ルール ・ベースは、いったん検査されると、ＩＥＦに妥当性検査ステ ータスを返し、その内部データを後で検索するために保持する。 ●「ファイルを貯蔵庫へ」 ＡＲＴ−ＩＭルール・ベースで修正できないファイルを貯蔵庫に引き渡す。 ●「ＦＴＡＭ ＨＬＣＯＰＹ」 ＦＴＡＭプロトコルを使って、ストリーマ６に、ＤＤＣユーザ名を使うＤＤＣ ＦＲＡＭアドレスからのＤＤＣファイル名、ＤＤＣパスワード、およびＤＤＣ アカウントをコピーする。ストリーマ６のユーザ名、パスワード、アカウントお よびＦＴＡＭアドレスは、必要に応じて、ＮＵＬＬにデフォルト設定される。こ のルーチンは、ＩＥＦから直接呼び出されないため、ＩＥＦスタイル・ステータ スを戻さない。 ●「ＤＤＣプロセス・パラメータの取得」 ”データデータＣ＿ｐｒｏｃｅｓｓ＿ｆｉｆｏ＜ＰＩＤ＞と名前が指定される ストリーマ／ＴＭＰディレクトリ内にファイフォを作成またはオープンする。こ れが、ファイフォからＤＤＣ ＮＮＩの値を読み取り、データは、”ｃｒｅａｔ ｅ＿ｆｉｌｅ＿ｐｒｏｃｅｓｓ”ルーチンによりファイフォの中に挿入された。 ●「ファイル・プロセス・パラメータの取得」 ”ｆｉｌｅ＿ｐｒｏｃｅｓｓ＿ｆｉｆｏ＿＜ ＰＩＤ ＞”と名前が指定され るストリーマ／ＴＭＰディレクトリ内にファイフォを作成またはオープンする。 これが、ファイフォから前記の変数の値を読み取り、データは、”ｃｒｅａｔｅ ＿ｆｉｌｅ＿ｐｒｏｃｅｓ”ルーチンによりファイフォの中に挿入された。 ●「交換機ファイルの取得」 ＦＴＡＭプロトコルを使って、ＤＤＣ上のディスクから、ストリーマ６上のデ ィスクに直接ファイルを作成する。それからファイルは、ストリーマ６上のメモ リの中に読み込まれ、そのアーカイブ元となる未処理レコードバックアップ・デ ィレクトリの中にリネームされて入れられる。このモジュールは、第１料金請求 書作成レコード、第ＩＡＰＤＵ、およびヘッダと後書きＡＰＤＵに対する初期ポ インタをセットアップするために、”ｍａｐ＿ｄａｔａ＿ｓｔｒｕｃｔｕｅ＿ｔ ｏ＿ｆｉｌｅ”を呼び出す。 ●「無効データ・アナライザＡＰＤＵ番号の取得」 ストリーマ妥当性検査プロセスを失敗した通話記録の無効ＡＰＤＵ再処理のカ ウントを戻す。 ●「データ・アナライザ・ファイルのマップ」 ファイルをそれ以降処理するためにメモリに読み込む。 ●「プロセス・アクティブ」 特定のＰＩＤがアクティブで、それに従ってフラグを返すかどうかを設定する 。 ●「交換機ファイル・ヘッダの読み取り」 ヘッダおよび後書きＡＰＤＵに対するポインタを使用し、構造内で、ヘッダか らのフィールドのすべておよび後書きからのＡＰＤＵタイプを戻す。 ●「データ・アナライザ交換機ファイル・ヘッダの読み取り」 ヘッダおよび後書きＡＰＤＵに対するポインタを使用し、構造内で、データ・ アナライザに送られたファイルの、ヘッダからのフィールドのすべての後書きか らのＡＰＤＵタイプを戻す。 ●「第ＩＤＩＲＩＮＤＥＸレコードの読み取り」 ＦＴＡＭプロトコルを使用して、ＤＤＣから一時記憶装置にＤＩＲＩＮＤＥＸ ファイルをコピーし、ファイルをオープンし、第１レコードを発呼者に戻す。 ●「次のＡＰＤＵの読み取り」 現在のＡＰＤＵポインタにより指されるＡＰＤＵ構造を戻し、現在のＡＰＤＵ ポインタを次のＡＰＤＵにセットする。また、現在の料金請求書作成レコードポ インタを、戻されるＡＰＤＵ内の第１料金請求書作成レコードにセットし、デー タを現在のＡＰＤＵアレイの中にコピーし、バイト反転する。 ●「次のＤＩＲＩＮＤＥＸレコードの読み取り」 ＤＤＣ上のＤＩＲＩＮＤＥＸファイルから次のレコードを読み取る。 ●「次のデータ・アナライザレコードの読み取り」 ＡＲＴ−ＩＭルール・ベースから出力される次の料金請求書作成レコードを戻 す。無事に処理されたレコードは最初に表示され、後に、未決ファイルに送られ る必要があるレコードが後に続く。 ●「次の未決レコードの読み取り」 未決ファイルから出力される次の料金請求書作成レコードを戻す。 ●「次のレコードの読み取り」 現在の料金請求書作成レコード・ポインタにより現在指される料金請求書作成 レコードを戻し、このレコードが現在のＡＰＤＵで最後でない場合には、ポイン タを次の料金請求書作成レコードにセットする（これは、ＡＰＤＵ長お料金請求 書作成レコードの最少長を使って判断される）。 ●「ネットワーク事業者ファイルのリネーム」 企業ボックス８により処理される準備が完了している運用ディレクトリ内の一 時ディレクトリに書き込まれたネットワーク事業者ファイルをリネームする。 ●「休眠」 指定秒数の間休眠する。 ●「ファイルのストリーム」 メモリ内のファイルを、データ・アナライザ処理の準備ができているデータ・ アナライザにダンプする。 ●「ファイル・ネットワーク事業者のストリーム」 その事業者の検査され、拡張されたレコードのすべてに到達するために、第１ ネットワーク事業者に対するポインタを使用する。それから、リンク済みリスト からのレコードをｎｆｓ＿ｔｅｍｐｏｒａｒｙディレクトリの中に書き込もうと する。正常に終了した場合には、ファイルはリネームされ、ｎｆｓ＿ｄｉｒｅｃ ｔｒｙに入れられる。ファイルがｎｆｓ一時ディレクトリ上で再オープンできな い場合には、ファイルはローカル一時ディレクトリにオープンされ、正常に書込 みが終了した時点で、ファイルはローカル・ディレクトリの 中にリネームされて入れられる。 ●「ファイルＲＲＢのストリーム」 メモリ内のファイルを未処理レコードバックアップ・ディレクトリにダンプす る。 ●「コンソールの書込み」 メモリをネットワーク管理ワークステーションに書き込む。 ●「中断ファイルへの書込み」 交換機ファイルの中断された通話記録のリンクされたリストから、レコードを 中断ディレクトリの中に書き込む。 ●「アーカイブ・ファイルへの書込み」 交換機ファイルのアーカイブ通話記録のリンク済みリストから、レコードをア ーカイブ・ディレクトリの中に書き込む。 ６． 図３１から３５：専門家システム：ＡＲＴ−ＩＭ ５（ｉ） 概要 専門家システムは、インタフェース社（Interface Corporation）が販売する ＡＲＴ−ＩＭ知識ベースの専門家システム・ツール・キットの機能を使用する。 これは、知識／ルール・ベースのプログラミング・システムで、問題解決のより 実践的な方法を提供するだけではなく、知識階層内での意志決定、したがって実 際の世界のモデリングを可能にする。ツール・キットには、統合型エディタ、対 話型開発環境、エンドユーザ・インタフェースの開発用ツール、開発されたアプ リケーションの実行時バージョンの展開方法、ならびに外部データを理性に解釈 するための機能だけではなく、ＡＲＴ−ＩＭ言語が備えられる。 データ・アナライザ７では、専門家システムは、ルール・ベースとケース・ベ ースの２種類のサブシステムに分割される。一般的には、ケース・ベースは、経 路選択ベースのエラーの処理に使用され、ルール・ベースはデフォルトの設定お 計算可能なエラーに使用される。その両方が、ＡＲＴ−ＩＭ機能を利用する。 ルール・ベースは、ルール、機能、および方法を含むＡＲＴ−ＩＭ手順言語を 使用する。各エラーはスキーマ内で定義され、これらのスキーマのインスタンス がデータ構造で使用される。イン・データ・オブジェクト階層内のすべてのスキ ーマは、ＩＥＦ／ＡＲＭ−ＩＭインタフェースを介して、ＡＲＴ−ＩＭの”ＤＥ Ｆ−ＥＸＴＥＲＮＡＬ ＦＵＮ”機能を使用して入力される。 ＡＲＴ−ＩＭによって使用されるプログラム・フロー制御のメカニズムは、通 常、プログラミング言語で見られるように、連続するステートメント単位フロー とは非常に異なる。図３１および３２を参照すると、専門家システムは、スキー マおよび事実であるその内部データのすべてを、パターン・ネット３１００内に 保持する。これは、複数のパターン化された丸により図３１で表され、そのそれ ぞれが１個の内部データ（スキーマまたは事実）を表す。このデータは、 ●ＡＲＴ−ＩＭテスト・ケース・ファイルのロード（開発／単体テストのコンテ キストでより通常実行される） ●外部ソース（オラクルまたはＩＥＦ。生産／システム・テスト環境でさらに一 般的）からの実装による。 ●（妥当性検査テストの失敗後のエラー・スキーマの作成などの、非常に柔軟性 がある「作業用記憶装置」として使用される）ＡＲＴ−ＩＭルールからの作成に よる。 データは、いったんセットアップされると、直接、ルールで指定される条件と 比較される。ルールは、より伝統的なプログラミング言語の”ＩＦ＜ 条件 ＞ ＴＨＥＮ＜ 動作 ＞”に似ている。ルールの条件がデータのインスタンスと正 確に一致すると、関連するアジェンダ３１０５内で起動が作成される。すべての インスタンスが、すべてのルールと比較してチェックされる。パターン・ネット およびルールの条件は、性能という点からＡＲＴ−ＩＭ実行時システム内で効率 的なパターン照合アルゴリズムにより管理される。 サイクルの評価部分の最後で、すべてのルール起動が、アジェンダ・スタック 上に順番に入れられる。スタック上の第１ルール起動が発効する？。起動の表示 順序は、ルールの優先順位である突極性が開発者により設定されていない限り、 ランダムをデフォルトとする。 図３２を参照すると、アジェンダ３１０５でのいちばん上のルール起動を発効 した後に、ルールの動作が、実際にパターン・ネット内のデータを変更し、パタ ーン・ネットが代わりに次の評価サイクルの後のアジェンダ・スタック上に表示 されるものを変更する。 初期の発効（丸で囲んだインスタンス３１１０）を引き起こすデータ・インス タンスが再評価されず、それによって、データ・インスタンス内のデータが変化 し、新しいパターン がルール条件と一致すると、ルール起動が作成されるが、継続ループが回避され ることに注記する。 ＡＲＴ−ＩＭ実行は、以下の場合に終了する。 ●照合条件およびパターンが検出されなかった。 ●すべての照合条件およびパターンがすでにルールを発効した。 前記は、以下のように要約できる。 １）ルール起動は、データ・パターンをルール条件と照合することにより作成さ れる。 ２）優先順位を設定することは可能であるが、ルールは、デフォルト設定により 、任意の順序で発効できる。 ３）すべてのデータが平行して評価される。 ４）再評価は、ルールが発効するたびに発生する。 ５）照合データ・インスタンスの回数に応じて、同じルールが実行中何回でも発 効できる。 ６）ルール条件は、パターン・ネット内の変更に敏感である。 ７）ＡＲＴ−ＩＭは、照合ルール条件やパターン・ネット・データが検出されな い場合、あるいはすべての一致した起動がすでに発効した場合に停止する。 図３３を参照すると、ルール・ベース・システムは、図示されるように、オブ ジェクト階層に基づいている。オブジェクト３３００のそれぞれが、ＡＲＴスキ ーマ内で定義され、オブジェクト３３００間の接続線が、前記オブジェクトから の継承を描写する。 交換機ファイル、ＡＰＤＵ、および通話記録は、その構造 の中に各データ項目のスロットを持つ。各スロットには、終結式にデフォルト値 が設定されているのか、計算可能値が設定されているのか、あるいはそれが修正 不能フィールドであるのかを宣言するために、該当するデフォルト・オブジェク ト内に対応するスロットを持つ。ルール・ベースは、デフォルト・システムを使 用して、可能な場合には、エラー訂正が取らなければならない形式をチェックす る。 前記が、データ・スキーマを説明している。エラー・スキーマに関し、すべて の可能なデータ・アナライザ・エラーは、その詳細が適切なスキーマの中に記述 されている。各エラー記述およびそのインスタンスは、以下のそれぞれのスロッ トを持つ。 エラーが関係し、交換機ファイルであるオブジェクト。 エラー記述 影響を受けるスロット エラー・インスタンスの特殊データ・オブジェクト 修復値の名前 エラーのソース 終結式の修復値 発効順のルール位置 適用されている修復前のスロットの値 ６（ｉｉ） ルール・ベース一般ルール ルール・ベースの運用フローは、多くの一般ルールにより制御されており、こ れらは、以下の機能を実行する。 ●エラー・トリガが発生するたびに、そのエラーの修復方法 が発効され、修復値およびその割り当てられた発効順を作成する。 ●影響が及ぼされたスロットが１つしかない修正可能エラーの場合、影響を受け たスロットは、作成された修復値で更新され、変更のタイム・スタンプはエラー のインスタンスとともに記憶される。 ●修正記述がエラー・タイプを中断可能と宣言するエラーの各インスタンスの場 合、影響を受けるデータ項目は未決ファイルに移動され、移動のタイム・スタン プがエラーのインスタンスとともに記憶される。 ●修復記述が、エラー・タイプが貯蔵可能であることを宣言するエラーの各イン スタンスの場合、影響を受けるデータ項目は貯蔵庫に移動され、ファイルの貯蔵 庫のタイム・スタンプは、エラーのインスタンスとともに記憶される。 ●ＡＰＤＵまたは交換機ファイルでの修復のたびに、ファイル構造ルール・ログ に関するレコードが作成される。 ●オラクルのレコードが、適切なエラー情報で通話記録を修復するたびに、通話 記録エラー・ログに関して作成される。 修復可能エラー １）デフォルト値は、以下のフィールドに割り当てることができる。 ＡＰＤＵタイプおよび後書き 料金請求書が作成された呼インジケータ 被呼者クリア ＰＢＸ接尾語 レコードの使用 レコード・タイプ ＤＤＣタイム・スタンプ ヘッダＡＰＤＵタイプ データ転送のクラス フォーマット・バージョン番号 ノード・タイム・スタンプ パーツ・ファイル・インジケータ テーブル・サイズ 後書きＡＰＤＵタイプ 被呼者クリア アプリケーション・グループ ２）以下のエラーは、計算可能である。 ＡＰＤＵ長：ＡＰＤＵの長さ ＡＰＤＵカウント：ＡＰＤＵシーケンスの長さ 終了ＡＰＤＵシーケンス番号：開始シーケンス番号に有効ＡＰＤＵの数を加算し たもの 開始ＡＰＤＵシーケンス番号：交換機ファイルの第ＩＡＰＤＵのシーケンス番号 から得られる。 ダイヤル数字カウント：ダイヤル数字文字列の長さ 前記に関しては、ＡＰＤＵ用チェックサムがエラーを示す場合などのエラーの 例外がある。この種のエラーは、ルール・ベース内でただちに貯蔵庫に入れられ る。ＡＰＤＵシーケンスに関するいくつかのエラーの結果、シーケンス番号の完 全な範囲が「１」から再度配列され、関係する交換機ファイ ルが更新されることになる。ダイヤル数字文字列の最後の数字がＡとＦの間の文 字になる可能性がある。この場合の修復値は、ダイヤル数字文字列から最後の数 字を差し引いた値である。 修復不能エラー 修復不能エラーが発生すると、エラーを起こしたデータ項目、つまり通話記録 は、前述されるように、貯蔵庫に引き渡され、該当するエラー・ログが更新され る。修正不能であるため、修正不能エラーを作成する領域は、以下の通りである 。 アドレス捕捉タイム・スタンプ アドレス完了タイム・スタンプ アドレス・タイム・スタンプまたは応答タイプ・スタンプ 発呼者クリア・タイム・スタンプ 発信番号ディレクトリ番号 捕捉タイム・スタンプ ダイヤル数字文字列（最後の数字がＡとＦの間である場合を除く） ６（ｉｉｉ） ケース・ベース・システム 経路選択参照ケース・ベースは、料金請求書作成可能ネット事業者名、ライブ ・ノード・タイム・スタンプおよび終了ノード・タイム・スタンプなどの他の参 照データが加えられた経路選択パターン（つまり、ＴＵＮ、経路グループ、経路 番号、ＮＮＩ、ノード・ポイント・コード）のケース・ベースである。ケース・ ベース参照データは経路選択参照スキーマから実装され、このスキーマは、代わ りにデータ・モデル のストリーマ参照データ・サブジェクト領域３６００内に記憶されるデータから 実装される（図３６を参照）。 図３４を参照すると、ケース・ベース・システム用オブジェクト階層は、図３ ３に示されるルール・ベース・システムの階層に類似し、「提案された解決策」 、「可能性がある解決策」および「経路選択参照」という３つのオブジェクト・ クラス３４００が追加されている。経路選択参照エラーの識別に続いて、「提案 された解決策」および「可能性のある解決策」だけが作成され、他のデータ、つ まりエラーが発生した通話記録およびもっとも近い一致である経路選択参照スキ ーマに対するポインタを含むことに注意する。「経路選択参照」スキーマは、オ ラクル・データベース上の経路選択参照データから作成される。 経路選択ケース・ベースに関して、および初期化時に、経路選択ケース・ベー スは、経路選択記述スキーマからの実行の開始時点で実装される。経路選択記述 スキーマごとにケースが作成される。経路選択ケース・ベースは、以下のパラメ ータが設定されて、セットアップされる。 ●３つの一致の最大値 ●ゼロ確率のスレッショルド値以下のあらゆる一致は、きわめて起こりそうにな い一致を取り除くために無視される。 ●ケース・ベースの次に示すスロットだけがパターン照合に使用される。 ＴＵＮ（電話装置番号）、経路グループ、ノード・ポイント・コード、経路番 号、ＮＮＩ、および方向 ●以下は、パターン照合のために無視される。 ライブ・ノード・タイム・スタンプ 終了ノード・タイム・スタンプ 電気通信事業者の役割と名前 ●方向は、照合のためにやや違うものとして処理される。方向は、もっとも重要 性が低い照合スロットで、全体的な重みの５％という固定重み上限が指定される 。それ以外のスロットの重みは、全体的な重みの残りの９５％の間で均等に分割 される。 初期化パラメータの設定などのそれ以外のケース・ベース機能だけではなく、 パターン照合も、メッセージをケース・ベースに送ることにより達成される。パ ターン照合は２つのステップで実行され、これらのステップとは、着信呼のレコ ード・スキーマを、検出された一致の数を返すケース・ベースに送信することと 、返されたケースと関連する経路選択参照スキーマのキーとともに、返されるケ ースのそれぞれに関して一致の近さを判断する検索−照合−スコア・メッセージ を送ることである。 ケース・ベースは、以下に示すように、ノード・ポイント・コードまたは未検 出経路グループ、無効経路番号、または無効方向などの呼のパターンに関するエ ラー・コード妥当性検査に使用される。 ●各着信呼のレコードと経路選択参照ケース・ベース上のケースの間の正確な一 致を見つけようとする。正確な一致がある場合には、通話記録は有効な経路選択 パターンを備え、前 記エラーに関してさらに妥当性検査は必要とされない。 ●正確な一致が検出されない場合には、エラー・スキーマが作成され、前記のよ うにルール・ベース一般規則をトリガし、修復方法を適用する。 ●特殊修復方法は、（図３４を参照する場合） ｉ）それぞれが関連経路設定参照スキーマに対するポインタを含む最高３つの可 能性のある解決策スキーマ。可能性のある解決策スキーマには、一致位置（つま り、もっとも近い、次に近いなど）、および一致の近さの％基準も含む。 ｉｉ）エラー状態にある着信通話記録に対するポインタを含む１つの提案される 解決策スキーマを作成するであろう。 修復方法が、エラー・スキーマ・インスタンスの作成により呼び出される通常 の修復方法とは異なることに注意する必要がある。これは、修復方法が、関数（ 経路選択の不一致で、提案された解決策スキーマ・インスタンスおよび経路選択 スキーマに対するキーを含む事実を表明する）と、別のルール（作成−もっとも 近い−一致で、経路選択不一致により作成される事実の生成でトリガし、検出さ れるケース・ベース一致ごとに可能性がある解決策スキーマの１つのインスタン スを作成する）から構成されるためである。 ノード・タイム・スタンプ妥当性検査が関係する場合は、ケース・ベースは、 以下のように使用される。 ●各着信通話記録スキーマと経路選択参照スキーマの間の正確な一致を検出しよ うとする試み。正確な一致がある場合は、ルールは、着信通話記録スキーマと経 路選択参照スキーマの 照合でタイム・スタンプの相違がないかチェックする（つまり、捕捉タイム・ス タンプは、ノード・ライブ時間とノード終了時間の間に該当しなければならない ）。相違が存在しない場合は、さらに、このエラーと関連する処理が発生する。 ●タイム・スタンプの相違が検出されると、エラー・スキーマが作成され、前述 のように、ルール・ベース一般規則をトリガし、修復方法に適用する。 ●特殊修理法は、（図３４を参照） −１つの可能性のある解決策スキーマで、そのそれぞれが関連する経路選択参照 スキーマに対するポインタを含む。可能性のある解決策スキーマには、一致位置 （つまり、もっとも近い、次に近いなど）および一致の近さの％基準も含む。 −エラー状態の着信通話記録スキーマに対するポインタを含む１つの提案された 解決策スキーマを作成するであろう。 修理法が、やはり、エラー・スキーマ・インスタンスの作成で呼び出される通 常の修理方法とは異なることに注意する必要がある。これは、それが関数（ノー ド−タイム・スタンプ不一致であり、提案された解決策スキーマ・インスタンス と経路選択参照スキーマへのキーを含む事実を表明する）と別のルール（ｇｅｎ ｅｒａｔｅ＿ｎｏｄｅ＿ｔｉｍｅ＿ｄｉｓｃｒｅｐａｎｃｉｅｓであり、経路選 択不一致により作成される事実の作成でトリガし、可能性のある解決策スキーマ の１つのインスタンスを作成する）から構成されるためである。 ６（ｉｖ） ＡＲＴ−ＩＭオラクル・インタフェース 図３５を参照すると、ＡＲＴ−ＩＭルール・ベースの「平行」妥当性検査機能 を完全に利用するには、ＡＴ−ＩＭからのＯＲＡＣＬＥデータベースへの直接ア クセスが必要となる。 以下に示す４つのメイン・インタフェースがある。 ●経路選択参照データ３５００の実装 ●デフォルト・データ３５０５の実装 ●監査追跡３５１０を形成するための修復データの出力 ●未決データ処理に対する前兆？としての経路選択エラー・パターンの出力３５ １５ 経路選択参照データの実装を検討すると、このインタフェース３５００は、内 部ＡＲＴ−ＩＭスキーマおよびケースベースの、ＯＲＡＣＬＥテーブル内に物理 的に保持される経路選択参照モデル内のデータからのリフレッシュを必要とする 。 ●リフレッシュは、ＡＲＴ−ＩＭ実行の初期化フェーズの間にトリガされる。 ●既存の内部ＡＲＴ−ＩＭ経路選択参照スキーマは、そのケース・ベース・エン トリとともにクリアされる。 ●データは、２つの外部動作ブロック（ｆｉｌｅ＿ｔｏ＿ｉｄａ＿ｒｕｌｅｓと ｃａｌｌ＿ｒｅｃｏｒｄ＿ｔｏ＿ｉｄａ＿ｒｕｌｅｓ）の一部として使用される ＰｒｏＣプログラム（ＥＡＢ＿ＩＮＩＴＩＡＬＩＺＥ＿ＩＤＡ＿ＲＵＬＥＢＡＳ Ｅ）のＯＲＡＣＬＥテーブルからＳＥＬＥＣＴされる。 ●内部ＡＲＴ−ＩＭスキーマは、ＰｒｏＣプログラムにより実装される。 ●経路選択参照ケースベースは、代わりに、ケースベース初 期化プロセスの一部として関数（ｉｎｃａ＿ｉｄａ＿ｉｎｉｔｉａｌｉｚｅ＿ｃ ａｓｅｂａｓｅ）により内部経路選択参照スキーマから実装される。 デフォルト・データの実装を検討すると、 ●リフレッシュは、ＡＲＴ−ＩＭ実行の初期化フェーズの間にトリガされる。 ●既存の内部ＡＲＴ−ＩＭデフォルト（ｄｆ−ｃａｌｌ−ｒｅｃｏｒｄ、ｄｆ− ａｐｄｕ、その他）スキーマは、そのケースベース・エントリとともにクリアさ れる。 ●データは、２つの外部動作ブロック（ｆｉｌｅ＿ｔ＿ｉｄａ＿ｒｕｌｅｓおよ びｃａｌｌ＿ｒｅｃｏｒｄ＿ｔｏ＿ｉｄａ＿ｒｕｌｅｓ）の一部として使用され るＰｒｏＣプログラムのＯＲＡＣＬＥテーブルからＳＥＬＥＣＴされる。 ●内部ＡＲＴ−ＩＭスキーマは、ＰｒｏＣプログラムにより実装される。 エラーおよび修復データの作成を検討すると、修復可能なデータと結び付いた エラーが着信データの妥当性検査の間に検出される場合、ルール・ベースにより 適用される修復の監査追跡を維持する必要がある。 ●エラー状態のすべてのファイル構造に対して、ＦＩＬＥＥＲＲＯＲ＿ＬＯＧテ ーブルの中に行エントリが作成される。これは、ストリーマ・プロセスにより実 行される。 ●エラー状態のすべてのファイル・レコードに対して、ＣＡＬＬ＿ＲＥＣＯＲＤ ＿ＥＲＲＯＲ＿ＬＯＧの中に行エントリが作成される。これは、ストリーマ・プ ロセスまたはＡＲＴ Ａ−ＩＭによって実行することができる。 ●検出されたあらゆるエラーおよびファイル構造レベルで適用された修復に対し て、ＯＲＡＣＬＥデータベース上の、ＦＩＬＥ＿ＳＴＲＵＣＴＵＲＥ＿ＲＵＬＥ ＿ＬＯＧで行エントリが作成される。これは、すべてのファイル・レベル・エラ ー検出および修復が完了した時点でトリガされる一般ルールを使って、ルール・ ベースでもっともよく実行される。ルールは、エラーが検出／修復が適用される たびに一度発効し、発効されると、必要な挿入を行うユーザ定義プロシージャ呼 び出しｓｑｌ＿ｅｘｅｃ＿ｌｉｍｉｔｅｄを呼び出す。 ●検出されるあらゆるエラーとファイル構造レベルで適用される修復に対して、 ＯＲＡＣＬＥデータベース上のＣＡＬＬ＿ＲＥＣＯＲＤ＿ＲＵＬＥ＿ＬＯＧで行 エントリが作成される。これは、すべての通話記録レベルのエラー検出と修正が 終了するとトリガされる一般ルールを使ってルール・ベースでもっともよく実行 される。ここでも、ルールは、エラーが検出／修復が適用されるたびに一度発効 し、発効すると、必要な挿入を行うユーザ定義プロシージャ呼び出しｓｑｌ＿ｅ ｘｅｃ＿ｉｍｍｅｄを呼び出す。 ●ＡＲＴ−ＩＭルールは、内部スキーマ上のスロットから挿入された値を実装す る。 経路選択エラー・パターンおよびもっとも近い一致データを参照する場合に、 中断されるデータに結び付いたエラーが着信データ妥当性検査中に検出されると 、（ＴＵＮ、ＮＮＩ、経路グループ番号、経路グループ、方向に基づく）着信呼 レ コード・エラー・パターンのレコードが、（経路選択参照モデルでのエラー状態 の着信通話記録に対してもっとも近いパターンに基づく）３つのもっとも近い一 致とともに、後で未決ファイル処理を行うためにＯＲＡＣＬＥデータベースに記 憶される必要がある。パターンは、すべての妥当性検査／修復処理の完了後に記 憶される。詳細には、 ●未決ファイル・エラーである生成されたエラーのそれぞれに対し（そして、同 じ通話記録上で修復不能エラーは生成されなかった、つまりこれらの修正不能通 話記録はｍｏｖｅ＿ｔｏ＿ｓｕｍｐ一般ルールを使って取り除いたと仮定すると ）、一般ルール（ｍｏｖｅ＿ｔｏ＿ｓｕｓｐｅｎｓｅ＿ｆｉｌｅ＿ａｒｅａ）が 発効される。ルールは、データベースからエラー状態のパターンを選択しようと し、エラー状態のパターンが存在する場合は： ｉ）関連パターン交換機ファイルおよび外来キーでＦＩＬＥ＿ＲＯＵＴＥ＿ＥＲ ＲＯＲ＿ＬＩＮＫでエントリがないかテストする。 ｉｉ）エントリが存在する場合には、さらに処置を講じる必要はない。 ｉｉｉ）エントリが存在しない場合は、ＦＩＬＥ＿ＲＯＵＴＥ＿ＥＲＲＯＲ＿Ｌ ＩＮＫに行エントリを挿入する。 エラー状態のパターンが存在しないと、 ｉｖ）着信通話記録からのエラー・パターン・データにより実装されるＲＯＵＴ Ｅ＿ＥＲＲＯＲ＿ＰＡＴＴＥＲＮテーブルに行エントリを挿入する。 ｖ）ＦＩＬＥ＿ＲＯＵＴＥ＿ＥＲＲＯＲ＿ＬＩＮＫの中に行エントリを挿入する 。 ｖｉ）過去のケースベース処理からエラー状態の経路パターンにもっとも近いと 判断される経路選択参照パターンにより実装されるＣＬＯＳＥＳＴ＿ＭＡＴＣＨ ＥＳテーブルの中に最高３つの行エントリを挿入する。 ●ユーザ定義プロシージャは、ＳＱＬコマンドをＯＲＡＣＬＥに渡すのに使われ る。 ●ＡＲＴ−ＩＭルールは、内部スキーマ上のスロットから挿入された値を実装す る。 ７．図２０、２１、３７から４３：データ・アナライザ７による専門家システム の使用 以下に参照するフロー図では、この仕様の前述のフロー図とはわずかに異なっ たフォーマットが適用されていることに注記する。つまり、関数呼び出しは、二 重縦線のボックスで表記され、単純ステートメントは、一重縦線のボックスで表 記され、イエス／ノーの決定は、単純なひし形により表記されている。 データ・アナライザ７によるＡＲＴ−ＩＭ専門家システムの使用は、フロー図 で表記することができる。図１６、１７および２０を参照すると、ステップ１６ ０５で、通話記録レベルでの障害が存在し、ステップ１７０２で次の通話記録エ ラー・ログがファイルから選択されたといったん判断されると、関連通話記録は 、ステップ２０００で専門家システムに送られる。専門家システムは、ステップ ２０５、２０１０で 正しいＡＰＤＵを見つけてから、ステップ２０１５、２０２０でエラーが発生し た通話記録を見つける。 それから、専門家システムは、通話記録が正しく項目別にされているかどうか をチェックし（ステップ２０２５）、システムＸの項目別記述に従ったこの例で は、もし正しく項目別にされていない場合には、ステップ２０３５で通話記録エ ラー・ログを更新しつつ、ステップ２０３０でＩＥＦステータスを「ＳＵＭＰ」 にセットすることにより、通話記録に貯蔵庫に入れるように指示する。通話記録 が正しく項目別にされている場合は、その通話記録は、ステップ２０４０、２０ ４５、２０５０で専門家システムを「通過」し、その結果は、ステップ１７０４ 以降でデータ・アナライザ７により評価される。 図１６および２１を参照すると、ステップ１６０４でファイルまたはＡＰＤＵ レベルで障害があると判断された可能性がある。その場合、ファイルはメモリに ロードされ、ステップ２１００でファイル・ヘッダとＡＰＤＵが専門家システム に送られる。専門家システム・データベースはステップ２１０５で呼び出され、 以前の実行のＡＰＤＵスキーマはステップ２１１０で削除される。最初に実行さ れたテストは、経路選択参照モデルの専門家システムバージョンをステップ２１ １５でリフレッシュすることで、その結果、明白なエラーはただちに訂正できる 。訂正されない場合、例えば、関係するエラーのデフォルト・データが見失われ ていると、専門家システム用のデフォルト・データがステップ２０２０でリフレ ッシュされる。これらのどちらかが正常に終了すると、データ・アナライザ・プ ロセスがそれ自体を再度表明し（図１６）、専門家システム・リフレッシュ・ス テップからの結果により、ファイルは、ステップ１６１１でその通話記録の妥当 性検査に入ることができる。両方とも正常に終了しなかった場合には、通話記録 自体が個別に検査されなければならない。 これは、以下に説明する。 図３７を参照すると、図２１の関数ボックス２１２５「ヘッダとＡＰＤＵスキ ーマのマップ」が拡張し、経路選択参照モデルおよびデフォルト・データのリフ レッシュの後に無事に処理できなかったエラーが発生したファイルの通話記録に 関して、専門家システムＡＲＴ−ＩＭのロード（ステップ３７００から３７２５ 、３７３５）および実行（ステップ３７３０、３７４０、３７４５、３７５０） が含まれる。このロード・プロセスは、ＡＲＴデータベース（「外来キー」）上 で入手できないデータ、例えば専門家システムがファイルにアクセスできるよう にするステップ３７１５でのストリーマ６からのデータの取得を含む。各通話記 録を解析すると、ＡＲＴは、通話記録が修復されている、あるいは中断するまた は貯蔵庫に入れる必要があることを示すステータスを設定する（ステップ３７５ ５）。データ・アナライザ・プロセス（ＩＥＦ）は、ステップ３７６０で貯蔵庫 に入れられる通話記録のカウントを保持し、各通話記録および関連スキーマをこ れらが単に蓄積するのを回避するためにクリアする目的でステップ３７７０での ＡＲＴ−ＩＭによるクリアをトリガする ステップ３７６５で、ＡＲＴ−ＩＭにフラグをセットする。 図３８から４３を参照すると、専門家システム・ファイル・ルールのアプリケ ーションは、フロー図でも表され、以下の例が示されている。フロー図は自明で ある。 ｉ）図３８：ＡＲＴファイル・ルール（交換機ファイル・ヘッダ） これは、以下に適用可能である。 後書きＡＰＤＵ フォーマット・バージョン番号 ファイル・タイプ ノード・タイム・スタンプ ＤＤＣ／ＮＭＰタイム・スタンプ（ＮＭＰは、ネットワーク・メディエーシ ョン・プロセッサの略である） データ転送のクラス ノード・クラス・アイデンティティ ストリーマＮＮＩ アプリケーション・グループ パーツ・ファイル・インジケータ ファイル・バイト・サイズ テーブル・サイズ 選択ＡＰＤＵタイプ ｉｉ）図３９：ＡＰＤＵ最初のシーケンス番号ルール ｉｉｉ）図４０：ＡＰＤＵ最後のシーケンス番号ルール ｉｖ）図４１：ＡＰＤＵシーケンス番号カウント・ルール ｖ）図４２：ＡＲＴ ＡＰＤＵルール これは、以下に適用可能である。 再送インジケータ リンク・フィールド ｖｉ）図４３：ＡＲＴ通話記録ルール これは、以下に適用可能である。 レコード使用 料金請求書が作成された呼インジケータ クリア原因 ＰＢＸ接尾語 ＣＬＩクラスタ・アイデンティティ ネットワーク回線 ネットワーク・バンド 回線アイデンティティ 回線番号料金バンド 呼サンプリング法 サンプリング・モード カウント・リセット・インジケータ Ｎの値（この場合、Ｎは、被呼者クリア・タイム・スタンプなどの通話記録 のテスト・セット実行中に行われたカウントに関係する） ８． 図３６および４４：企業システム 図４を参照すると、ストリーマ６から企業システム８への出力は、料金請求書 作成可能事業体に従って分類され、前述のように、ＡＲＴ−ＩＭ専門家システム を搭載したデータ・アナライザを使用して検査された通話記録から構成される。 企業システム８の主要な役割とは、通話記録の料金設定を行い、それらの料金 請求書がクライアントに作成できるように、料金設定済みレコードを出力するこ とである。しかし、企業システムは、前述のように妥当性検査の役割も果たし、 料金請求書作成可能事業体に関連するデータと料金請求書作成可能事業体と第１ ネットワーク１の事業者の間の関係性を重視している。したがって、企業システ ム８は、”ｃＩＤＡ”と以下で参照される企業システムのデータ・アナライザを 搭載またはアクセスする。 ｃＩＤＡアプリケーションは、前述のようにストリーマ６からのデータを検査 するデータ・アナライザ７に沿って常駐することができる。図４では、エラーが 生じた通話記録の修正のステップ４３０、修正済み通話記録の大容量化のステッ プ４４０、および修復不能通話記録の調査のステップ４５０のすべてが、ｃＩＤ Ａアプリケーションを使って実行される。 興味深いことに、企業システムによりとらえられるエラーの約９０％のエラー の過半数が、復号化の例外に関し、おもに、「１２３」および「緊急サービス」 （９９９）通話のような「時間回線」に関係することに注意する。エラーの残り の大半は、参照データの矛盾に帰することができる。したがって、企業システム ８と使用するためのデータ・アナライザの構築には２つの重要な点があり、これ は、エラーの過半数を占める復号化の例外を提供するレコードに取り組み、訂正 後にファイルを企業システム８に戻して表記する機能を持つインフラストラクチ ャを提供することである。 処理の概要 適当な管理は、以下の通りである。エラーおよび警告ファイルが企業ボックス ８からｃＩＤＡに送られ、そこで事業者ごとに１つ、特殊なディレクトリにロー ドされる。１つのファイルはゼロ個のレコードまたは多くのレコードを保持する ことができる。ｃＩＤＡが、すべての事業者用に、手動による無効機能を持つ同 時に実行する平行処理機能を備えることが望ましい。ｃＩＤＡの中への、あるい はｃＩＤＡの中からのファイルのシーケンスを制御するために、ログが維持され る。いったん任意のエラー・ファイルが処理のために選択されると、ｃＩＤＡは 、ファイルが空ではないと仮定して、代わりに各レコードを選択し、エラーを修 復可能と修復不能という２つのカテゴリの内の１つに評価する。修復不能レコー ドは、テーブルに書き込まれ、データベースで報告され、アーカイブに入れるた めに後でデータベースから削除される。レコードが修復可能であると見なされる 場合には、レコードは、ルールを適用することにより自動的に修復されるか、あ るいは修復前に手動による介入を必要とする場合がある。 エラー・タイプに関係なく、各レコードは、ＯＲＡＣＬＥデータベース・テー ブルに挿入され、すべての詳細は企業ボックス８から引き渡され、フラグが「状 態」を示すためにセットされる。「状態」とは、前記に従って、以下から選択さ れる。 未決 修復不能 ルール ビジネス・オブジェクトを使用するユーザは、定期的な間隔で実行し、現在保 持されているすべてのレコード、およびそれらに指定されている状態の割当を表 示する機能を備える。監査ログは、すべての「課金番号文字列」の修正のための １カ月のように、関連期間の間保持することができる。 自動ルールの使用も不必要であると判断されたことに注意する。現在のエラー の９０％を占める復号化の例外が原因のエラーを訂正すると、エラー率は０．０ １％まで減少することがわかった。したがって、エラー発生の単純さとは、自動 ルールを利用するシステムが過剰に複雑であることを意味している。 図４４を参照すると、本発明のデータ収集処理システムの回りのデータ・フロ ー経路が示されている。この図では、ファイルおよびテーブルのようなデータ記 憶装置は、縦の点線による水平に伸びる矩形で表記され、プロセスは、矩形を取 り入れるさらに大きなブロックにより表されている。ＮＤＣＢ９のようなシステ ム全体の外部にあるエンティティは、「ひし形」で表記される。 すでに前述したように、未処理通話データは、ストリーマに入れられ、ストリ ーマが未処理通話データを変換し、通話記録の検査と処理を行い、必要な限りデ ータ・アナライザを関与させ、検査された項目別の通話記録を企業ボックスに出 力する。企業ボックスは、最初は、事業者に特殊な妥当性検査を行い、第２に、 項目別通話記録を集計する。この段階で、 国内課金データベース（ＮＣＤＢ）などからの課金情報を使用して通話記録の料 金が設定され、関連クライアント・システム１０用の請求報告書を作成するため に要約された形式で出力される。それ以外の出力には、光ディスク７１に記憶さ れる拡張通話記録、および管理報告システム４４００用の要約通話記録が含まれ る。 図４４では、また、データ・アナライザから監査システム”ＣＡＲＤＶＵ”４ ４０５への出力があることが分かる。本発明の実施例は、監査目的のきわめて詳 細な情報を提供できるが、監査システム自体は本発明の一部ではなく、したがっ て、以下の「９．監査追跡」でのコメント以上に、本明細書に記述されていない 。 図３６を参照すると、企業システム８用のデータ・モデルは、明確に、企業シ ステム８による課金および料金設定で使用するためのデータ・ソースを示してい る。データの最大量「Ｃ＆Ｐ参照データ」のほとんどが、ＮＣＤＢ９から得られ る。ただし、料金請求書作成可能事業体とネットワーク１の事業者の間の会計処 理協約４５００により設定される制約事項が存在する。多くの問題点は、網管理 センタから処理され、図３６のデータ・モデルは、「電気通信ネットワーク事業 者の役割」ボックス４５０５を使ってそこで適切に見えるようになる。 図３６で使用される、以下に示す頭文字は、次のように拡張できる。 ＣＢＭ課金バンド・マトリックス ＣＢ 課金バンド ＮＮ ネットワーク・ノード ＫＣＨ キングストン通信、ハル（Kingston Communications，Hull）（ＢＴ ＰＳＴＮに相互接続されるネットワークのＵＫにある事業者） ＴＥ テレコム・エイラン（Telecom Eirann）（同上） 国内課金情報パッケージ（ＮＣＤＢ上のデータへのインタフェース） 本発明のシステムにより提供される制約事項の種類に準じる料金設定課金装置 は既知であるため、料金設定課金装置についての特別な記述は本明細書では行わ ない。実際、図３６のデータ・モデルは関係するすべての事業体を示しているが 、表記が複雑になりすぎるため、すべての関係が示されているわけではない。し かし、全般的には、企業システム８により処理される通話記録が、すでに料金請 求書作成可能事業体に従って分類されていることを頭に入れておかなければなら ない。データのこの面は、関連レポートが正しいクライアント・システム１０に 割り振られるように、明確に維持される必要がある。これは、前述のように、料 金請求書作成可能事業体に対して割り振られたディレクトリを維持することなど により達成できる。 ９．監査追跡 前述したような装置は、精密な監査追跡を実行することＧできる。相互接続点 での交換機からのデータはファイルに入り、ＡＰＤＵに実装される。ストリーマ ・システム６は、Ｆ ＴＡＭプロトコルを使ってＤＤＣ５から離れてデータをポールし、データはバイ ナリ形式で通話記録に記憶される。ストリーマ・システム６は、参照データを記 憶するデータベースである、経路選択参照モデルに比較してデータを検査し、他 のどのネットワーク事業者に料金請求書を作成する必要があるのかを評価する。 ストリーマ・システムは、事業者と交換機の情報を追加して、ＡＳＣＩＩ形式で 完全な通話記録を書き込む。監査追跡は、以下に示すように起動する。交換機で 、通話事例が、０−９９９９を循環するファイル作成番号で番号付けされる。ま た、ＤＤＣ５が、ファイル・レベルで、０−００００を循環するシーケンス番号 を追加する。ファイル内で、ＡＰＤＵは、バイナリで０−１６３５３を循環する ＡＰＤＵシーケンス番号で配列される。 つまり、１つのファイル内の数多くのレコード、ＡＰＤＵ開始および終了番号 、ならびにＡＰＤＵの数から成る１つのレコードが記憶されている。 シーケンス番号が交換機の各番号に追加されるため、番号は必ずしも順番に処 理されないが、企業ボックス８が番号を順番に受け取ることが確実となる。スト リーマ・システム６は、実際には、さまざまな交換機から同時に平行して処理す る。 「パターン・ネット」が使用されるデータ・アナライザでは、データが有効な 内容に適合しない場合にはどのデータがルールを「発効する」かという手段によ り、アナライザが、 関係するデータ項目が料金や監査追跡に影響を及ぼさない場合にだけ、データ項 目をパッチすることができる。したがって、データ・アナライザは、通話記録シ ーケンス番号が通話記録を識別するため、それを変更することはできない。万一 通話記録シーケンス番号が変更された場合には、監査追跡は行われないだろう。 前述したシステムは、述べられているように、本発明の唯一の特殊実施例であ る。これは、ＰＳＴＮに関し、前述のように、音声通信システムで通話記録を処 理する。さらに、関係する通話記録の特殊な形式であるシステムＸ６型は、ネッ ト間の相互接続点（ＰＯＩ）で使用される１つの種類の交換機にしか関係しない 。 ただし、本発明の精神から逸脱することなく、多くの変更が加えられることも ある。本発明の応用の単純な拡張例では、料金請求書情報を作成するために通話 記録データを使用するだけではなく、 トラヒック解析情報もとらえ、処理でき る。例えば、宛先に到達する上で効果的ではない呼を、ＰＯＩにある交換機によ りカウントし「大容量化」した結果を、データ処理システムに入力することがで きる。 ただし、さらに重要な変更には、音声通信以外の通信のシステムの使用が含ま れ、音声通信を除外しても、すでに前述したように、レコードの完全な量と関係 するソースの複雑さという点から本発明の実施例の優位点は明らかに重要である が、ＰＳＴＮの関与は明らかに必須ではない。

【手続補正書】特許法第１８４条の８ 【提出日】１９９５年３月２２日 【補正内容】 に政府組織により運営されていた。現在では、ますます、ＰＳＴＮの民営化およ び規制独占の緩和が進み、加入者が利用できるネットワーク事業者の数がさらに 増加し、これらのネットワーク事業者は、実践上の理由から、網間接続を提供し なければならない。つまり、ネットワーク事業者は、専用ネットワーク、または 独立しているが、類似した管理が布かれている限られた数の相互接続したネット ワークで生じる通信事例だけではなく、理論的には、さまざまな種類で、多岐に 渡るサービスを加入者に提供する、非常に多数の競合ネットワークで発生する通 信事例も考慮に入れなくてはならない。 したがって、事業者のネットワーク外で発生するが、事業者のネットワークの 中で終端するか、あるいは単に事業者のネットワークを横切る通信事例に関係し て、データの収集および処理を行うことがますます重要である。 文献"Access Charge and Revenue Architecture"、ＡＴ＆Ｔテクニカルジャー ナル第６６巻第３号、１９８７年５月、米国ニューヨーク、７３〜８１頁におい ては、８０年代での局所および長距離キャリアの分離（権利喪失）後のＵＳ型Ｐ ＳＴＮ内における内部交換キャリアによる使用に対して、アクセスチャージおよ び収益を予測するデータシステムが開示されている。 呼が複数の事業者のネットワークを通過する場合、互いの呼の搬送に関する事 業者間の価格および課金の契約が効果を発揮する。このような取り決めは、単な る送信者がすべてを保管？（ＳＫＡ）取り決めから複雑な料金設定式までさまざ まである。 通話データは、呼が発生したネットワークの責任を持つ管理責任者により収集 されるというのが、電気通信における別個のネットワーク事業者または管理責任 者の間での確立された慣行であった。その場合、その呼が第２のネットワークで 終端した場合、第２のネットワークに関係する管理責任者は、例えば、会計処理 を行うために、第１のネットワークの責任 を持つ管理責任者により収集されるテータを信頼する。なお、富士通株式会社に よる英国特許出願ＧＢ２２５４２２４号には、インテリジェントネットワーク技 術に基づく対外国際電話における二重請求を回避するシステムが記載されている 。 しかしながら、電気通信環境は、技術的にだけではなく、急速に、かつ政治的 にも変化を遂げている。さらに激化した競合状態が到来し、独自のネットワーク で生じるトラヒックのみならず、それ以外の場所で発生するが、独自のネットワ ークを横切るか、あるいは独自のネットワークで終端するトラヒックもモニタす ることは、網管理責任者にとってますます魅力的になっている。トラヒックがそ の中で生じるネットワークが競合事業者または管理責任者に属している場合は、 競合事業者のアカウントも相互チェックすることが少なくとも可能であることが 望ましい。 市内交換機はトラヒックが生じるとそれをとらえるため、既知の取り決めでは 、ＰＳＴＮ内での通話に関するデータ収集点はネットワークの市内交換機であっ た。しかしながら、この取り決めは、網間トラヒックに関してデータ収集を行わ ない。たとえネットワークに着信する呼に関するデータを収集するためのデータ 収集点が存在しても、このようなデータを任意の詳細レベルまで処理するのに必 要となる物流の調達は威圧的である。例えば、アイル・オブ・マン（Ｉｓｌｅｏ ｆ Ｍａｎ）およびセルネット（Ｃｅｌｌｎｅｔ）・セルラー・ネットワークを 含む他の管理責任者から、英国電気通信会社（ＢＴ）により英国内で運営されて いるＰＳＴＮに着 信する呼は、１９９２年３月までの１年間で、毎日、総計１，５４０万通話にの ぼった。この数字は、１９９５年３月までの１年で、毎日約２，７００万通話に 到達すると予想されて ットワークで発生する通信事例に関し、経路情報、および前記通信事例に関する 期間などの少なくとも１つの請求書送付が可能なパラメータ測定値から構成され るステップと、 ｉｉ）前記データをテータ処理システムに送信するステップと、 ｉｉｉ）請求情報を生成するための前記データを処理するステップと、 から構成される。 データを第１ネットワークと別のネットワークの間の接続点で収集することに より、第１ネットワークに関連する管理責任者は、第１ネットワークに着信する 通信事例についての情報を直接取得し、したがって他のネットワーク事業者また は管理責任者により提供されるデータを相互チェックできるようになる。 本発明の第２の面に従い、別のネットワークとの接続点にあるＰＳＴＮで収集 されるデータを処理するためのデータ処理装置が提供され、装置は、 ｉ）通信ネットワークから通信事例に関するデータを入力するためのデータ入力 であって、前記データが複数の分類特性の内の少なくとも１つを備えるデータ入 力と、 ｉｉ）データ入力で受け取られたデータの整合性および能力をチェックするため の検証手段と、 ｉｉｉ）検証手段により拒絶されたデータを解析し、修正されたデータまたはデ フォルト・データを検証手段に提出するためのデータ・アナライザと、 ｉｖ）更新可能参照情報に従い、検証手段により出力された １つで適用される。ただし、例えばＰＳＴＮ内では、通常、発生するエラーが発 生したデータの性質により、（ｉｉｉ）検証手段に対応するデータ・アナライザ と（ｉｖ）料金設定手段との間に、分類手段を提供することが望ましくなる。し たがって、料金設定手段は、すでに分類されたデータ上で動作する。分類特性が 、データにより表される通信事例に関して料金請求書の発行を受けるさまざまな 事業体に関係する場合は、この装置には、個々の事業体に関連する制約事項を適 用する場合に、料金設定手段を簡略化できる可能性があるという利点もある。 ＢＴ ＰＳＴＮのようなネットワークが市内局と市外局の両方から構成され、 交換機間通話送信だけではなく、市内通話のエンドユーザまでの送達も行うこと に注意する。つまり、料金請求書作成または料金請求書検証をサポートするのに 必要なデータ収集および処理は、きわめて広範囲に渡る変数を処理できるほど複 雑でなければならない。これは、ネットワークが市外局間送信だけ、あるいは市 内局送達だけを行う状況とは対照的である。 第３の本願発明では、多重化された更なるネットワークからの通信事例を受信 するように接続された第１通信ネットワークにおいて使用するためのデータ収集 ・処理装置が用意される。この装置は以下の構成を持つ： ａ）前記更なるネットワークの１つに現れた第１ネットワークへの通信事例を 登録する登録手段と； ｂ）前記通信事例の登録をフォーマットする手段、ここで 前記登録は前記更なるネットワークの１つを特定するデータおよび通信事例に伴 う持続期間などのパラメータ値を含んでいる、と； ｃ）前記登録を検証する検証手段と； ｄ）価格・請求データを検証された登録に付与し、価格付けされ請求され検証 された登録の分類整理されたアレイを提供する価格付け・請求手段、ここで前記 アレイは前記更なるネットワークの識別子にしたがって分類整理される、と； ｅ）前記検証手段によりリジェクトされた登録を分析する分析手段。この分析 手段は、リジェクトされた登録をリジェクトの原因に応じて少なくとも３つの方 法のうちの１つにより処理するように構成されている。これら３つの方法は、検 証されなかった登録内の値を最も適切な値にセットするか、検証されなかった登 録内の値をデフォルト値にセットするか、若しくは検証されなかった登録をアー カイブまたはダンプする。第１の方法または第２の方法のいずれかで処理された 登録は、検証された登録として、直接的あるいは間接的に、前記価格付け・請求 手段に転送される。 第４の本顆発明では、複数のネットワークに関係する通信登録を収集し処理す る場合に使用するために、データ収集・処理システムが用意される。このシステ ムは、前記複数ネットワークの１つと前記複数ネットワークの少なくとも他の１ つとの間の接続点に生じる通信登録を受信するために少なくとも１つの入力を持 っている。この登録は、通信事例が生じたネットワーク、あるいは前記第１ネッ トワークに参加した ネットワークの検証に、用いられる。この登録はまた、通信事例に伴う期間など の、請求送付が可能なパラメータ測定値の検証にも用いられる。このようなシス テムはさらに、次の構成を備えている。すなわち、このシステムは、登録に関す るフォーマット・手順指令情報を検証する検証手段と；この検証手段でリジェク トされたエラー登録を分析するデータ分析手段、この分析手段は前記エラー登録 をカテゴリ分類する能力を持ち、エラー登録の少なくとも１カテゴリにデフォル ト値を適用する、と；前記ネットワークの検証にしたがって、検証された登録お よびデフォルト値が適用された登録を記憶する記憶手段と；分類整理された登録 を受け、そこに含まれる情報に基づいて、検証されたネットワークに関係する請 求実体に対して使用する請求情報を発生する価格手段とを、備えている。 ここでは、本発明の実施例に従ったシステムを、付随図面を参照し、例だけを 使用して説明する。この場合、 図１は、電気通信網に着信する通話事例用の会計処理システムをサポートする ための、通話情報から構成されるデータの取集および処理を行うためのシステム のアーキテクチャを図式によって示す。 図２、３、および４は、図１に示されるシステムの概要フ 関係するデータ項目が料金や監査追跡に影響を及ぼさない場合にだけ、データ項 目をパッチすることができる。したがって、データ・アナライザは、通話記録シ ーケンス番号が通話記録を識別するため、それを変更することはできない。万一 通話記録シーケンス番号が変更された場合には、監査追跡は行われないだろう。 前述したシステムは、述べられているように、本発明の唯一の特殊実施例であ る。これは、ＰＳＴＮに関し、前述のように、音声通信システムで通話記録を処 理する。さらに、関係する通話記録の特殊な形式であるシステムＸ６型は、ネッ ト間の相互接続点（ＰＯＩ）で使用される１つの種類の交換機にしか関係しない 。 本発明の応用の単純な拡張例では、料金請求書情報を作成するために通話記録 データを使用するだけではなく、トラヒック解析情報もとらえ、処理できる。例 えば、宛先に到達する上で効果的ではない呼を、ＰＯＩにある交換機によりカウ ントし「大容量化」した結果を、データ処理システムに入力することができる。 ただし、さらに重要な変更には、音声通信以外の通信のシステムの使用が含ま れ、音声通信を除外しても、すでに前述したように、レコードの完全な量と関係 するソースの複雑さという点から本発明の実施例の優位点は明らかに重要である が、ＰＳＴＮの関与は明らかに必須ではない。 請求の範囲 １．第１通信ネットワークでデータを収集、処理するためのプロセスであって、 データは、通信事例に関し、その場合、ネットワークが第２通信ネットワークへ の少なくとも１つの接続点を具備し、プロセスが ｉ）前記接続点でのデータ・アクセスでデータを収集するステップであって、前 記データが前記第１ネットワーク以外の発信ネットワークで発生する通信事例に 関し、発信ネットワークおよび前記通信事例に関する期間などの請求の影響を受 け易い少なくとも１つのパラメータ測定値を識別する経路情報を具備するステッ プと、 ｉｉ）前記データをデータ処理システムに転送するステップと、 ｉｉｉ）前記データを処理し、請求情報を発生するステップと、 を具備するプロセス。 ２．請求項１に記載されるプロセスであって、前記第１ネットワークが公衆加入 電話網を構成するプロセス。 ３．請求項１または２のどちらか１つに記載されるプロセスであって、前記デー タ処理ステップが、前記発信ネットワークのアイデンティティに従った前記デー タのストリームから構成されるプロセス。 ４．前記請求項のいずれかに記載されるプロセスであって、第１ネットワークが 市内局と市外局の両方を具備する通信ネ ットワークを構成し、データ処理システムが料金設定および課金データを、発信 ネットワークを識別する経路情報に従ってデータベースから相互関係付けること を含むプロセス。 ５．請求項３及び４に記載されるプロセスであって、前記相関関係付けが、デー タのストリームの後に実行されるプロセス。 ６．前記請求項のいずれかに記載されるプロセスであって、前記データ処理シス テムがデータ・アナライザを具備し、前記データ処理ステップが、無効データの 解析が後に続くデータの検査を含み、解析が、もしかするとデフォルト値に設定 できるデータを識別し、そのデータをデフォルト値に設定し、それを有効データ として処理するステップを含むプロセス。 ７．通信ネットワークで収集されるデータの処理を目的とするが、ネットワーク の外で発生する通話事例に関するデータ処理装置であって、装置が、 ｉ）前記データを入力するためのデータ入力であって、前記データが複数の分類 特性の内の少なくとも１つを備えるデータ入力と、 ｉｉ）データ入力で受け取られるデータをチェックするための検証手段と、 ｉｉｉ）検証手段により拒絶されるデータを解析し、それを修正済みデータまた はデフォルト・データで置換するためのデータ・アナライザと、 ｉｖ）検証手段またはデータ・アナライザにより出力されるデータを、更新可能 な参照情報に従って料金設定するための 料金設定手段と、 ｖ）料金設定手段から料金設定済みデータをメモリ位置に出力するための出力手 段であって、各メモリ位置が前記分類特性の１つまたは複数に関連するデータに 専用の出力手段と、 を具備するデータ処理装置。 ８．前記請求項７に記載されるデータ処理装置であって、各分類特性が、前記通 信ネットワークの外の別のネットワークを識別し、別のネットワークで関連付け られた通信が発生するデータ処理装置。 ９．前記請求項７または８の内のいずれか１つに記載される装置であって、前記 通信ネットワークがパブリックスイッチド電話ネツトワーク（public switched telephone network）である装置。 １０．請求項７、８、または９の内の１つに記載される装置であって、前記デー タ・アナライザが、中断されたデータ記憶装置内に、それ以降の処理のために、 修正またはデフォルトに設定できないデータを記憶するための手段を具備する装 置。 １１．複数の別のネットワークに接続され、複数の別のネットワークから通信事 例を受け取る第１通信ネットワークで使用するためのデータ収集処理装置であっ て、 ａ）前記別のネットワークの内の１つで生じた第１ネットワークに着信する通信 事例を登録するための登録手段と、 ｂ）前記通信事例のレコードをフォーマットするための手段であって、レコード が別のネットワークの内の前記１つを識 別するデータおよび通信事例と関連する期間などのパラメータ知から構成される フォーマット手段と、 ｃ）前記レコードを検査するための検査手段と、 ｄ）料金設定および課金データを検査されたレコードと結び付け、料金設定済み の課金され、検査されたレコードの分類されたアレイを提供するための料金設定 および課金手段であって、アレイが別のネットワークのアイデンティティに従っ て分類される料金設定および課金手段と、 ｅ）検査手段により拒絶されるレコードを解析するための解析手段であって、解 析手段が、拒絶の理由に従って少なくとも３つの方法の内の１つで拒絶されたレ コードを処理するように構成され、前記３つの方法が、検査されていないレコー ドの値を最適値に設定することか、又は検査されていないレコード値をデフォル ト値に設定することか、又は検査されていないレコード値をアーカイブに入れる か、ダンプすることとであり、第１の方法又は第２の方法のどちらかで処理され たレコードが、直接的、あるいは間接的に、検査済みレコードとして料金設定お よび課金手段に送信されるデータ収集処理装置。 １２．請求項１１記載の装置であって、前記第１ネットワークの交換機は、通信 事例を受信するように構成され、データコレクタが前記通信事例のレコードを前 記登録手段として記録するよう構成され、前記レコードに取り込まれる経路選択 情報が別のネットワークの内の前記１つを識別するデータを提供し、検証手段が 経路選択参照データ・モデルにアクセス し、レコードの検査で使用される基準の内の１つが経路選択情報と経路選択参照 データ・モデルの間の相互関係の程度をレコード検査での評価基準の１つとして 使用するように構成される装置。 １３．請求項１１または１２のいずれか１つに記載される装置であって、前記解 析手段が更に第４の方法で、拒絶されたレコードを交互に処理し、前記第４の方 法が検査されていないレコードに関するデータを、後でアクセスおよび解析が可 能な中断されたデータ記憶装置内のファイルに付加する方法であることを特徴と する装置。 １４．請求項１３に記載される装置であって、中断されたデータ記憶装置内の各 ファイルが、同じエラー・パターンを有する検査されないレコード専用に使用さ れる装置。 １５．請求項１２から１４のいずれか１つに記載される装置であって、料金設定 および課金手段が、検査手段を備えるか、検査手段にアクセスし、最初のデータ が装置で検査されてから破損したデータの再処理を可能とするために、検査され ていないレコードを解析手段に出力できるように構成される装置。 １６．複数のネットワークに関連する通信レコードを収集、処理する際に使用す るデータ収集処理システムであって、前記装置が、前記複数のネットワークの第 １ネットワークと前記複数のネットワークの少なくとも１つのそれ以外のネット ワークの間の接続点で作成される通信レコード用の少なくとも１つの入力を具備 し、前記レコードが、関連通信事例がそ の中で生じるか、それがその中から前記第１ネットワークに入ったネットワーク を識別し、請求の影響を受け易いパラメータ測定値を提供し、前記システムはさ らに、レコードのフォーマットおよび経路選択情報という点を検査するため検査 手段、および前記検査手段により拒絶されるエラーが発生したレコードを解析す るための、前記エラーが発生したレコードを分類し、デフォルト値をエラーが発 生したレコードの少なくとも１つのカテゴリに適用する機能を持つデータ解析手 段、前記ネットワーク識別に従って検査され、デフォルト設定されたレコードを 分類するためのデータ分類手段、および分類されたレコードを受け取り、識別さ れたネットワークに関連する料金請求書作成事業体で使用するための料金請求書 情報をその分類されたレコードに基づいて作成する料金設定手段を具備する装置 。

───────────────────────────────────────────────────── フロントページの続き (31)優先権主張番号 ９３１７６１９．６ (32)優先日 1993年８月24日 (33)優先権主張国 イギリス（ＧＢ） (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，Ｍ Ｃ，ＮＬ，ＰＴ，ＳＥ)，ＡＵ，ＢＧ，ＢＲ，ＢＹ，Ｃ Ａ，ＣＮ，ＣＺ，ＦＩ，ＨＵ，ＪＰ，ＫＲ，ＫＺ，ＬＶ ，ＮＯ，ＮＺ，ＰＬ，ＲＯ，ＲＵ，ＳＩ，ＳＫ，ＵＡ， ＵＳ，ＵＺ，ＶＮ

Claims (1)

1. 【特許請求の範囲】 １．第１通信ネットワークでデータを収集、処理するためのプロセスであって、 データは、通信事例に関し、その場合、ネットワークが第２通信ネットワークへ の少なくとも１つの接続点を具備し、プロセスが ｉ）前記接続点でのデータ・アクセスでデータを収集するステップであって、前 記データが前記第１ネットワーク以外の発信ネットワークで発生する通信事例に 関し、発信ネットワークおよび前記通信事例に関する期間などの少なくとも１つ のパラメータ測定値を識別する経路情報を具備するステップと、 ｉｉ）前記データをデータ処理システムに転送するステップと、 ｉｉｉ）前記データを処理するステップと、 を具備するプロセス。 ２．請求項１に記載されるプロセスであって、前記第１ネットワークが公衆加入 電話網を構成するプロセス。 ３．請求項１または２のどちらか１つに記載されるプロセスであって、前記デー タ処理ステップが、前記発信ネットワークのアイデンティティに従った前記デー タのストリームから構成されるプロセス。 ４．前記請求項のいずれかに記載されるプロセスであって、第１ネットワークが 市内局と市外局の両方を具備する通信ネットワークを構成し、データ処理システ ムが料金設定および 課金データを、発信ネットワークを識別する経路情報に従ってデータベースから 相互関係付けることを含むプロセス。 ５．請求項４に記載されるプロセスであって、前記相関関係付けが、請求項３に 従ったデータのストリームの後に実行されるプロセス。 ６．前記請求項のいずれかに記載されるプロセスであって、前記データ処理シス テムがデータ・アナライザを具備し、前記データ処理が、無効データの解析が後 に続くデータの検査を含み、解析が、もしかするとデフォルト値に設定できるデ ータを識別し、そのデータをデフォルト値に設定し、それを有効データとして処 理するステップを含むプロセス。 ７．通信ネットワークで収集されるデータの処理を目的とするが、ネットワーク の外で発生する通話事例に関するデータ処理装置であって、装置が、 ｉ）前記データを入力するためのデータ入力であって、前記データが複数の分類 特性の内の少なくとも１つを備えるデータ入力と、 ｉｉ）データ入力で受け取られるデータをチェックするための検証手段と、 ｉｉｉ）検証手段により拒絶されるデータを解析し、それを修正済みデータまた はデフォルト・データで置換するためのデータ・アナライザと、 ｉｖ）検証手段またはデータ・アナライザにより出力されるデータを、更新可能 な参照情報に従って料金設定するための料金設定手段と、 ｖ）料金設定手段から料金設定済みデータをメモリ位置に出力するための出力手 段であって、各メモリ位置が前記分類特性の１つまたは複数に関連するデータに 専用の出力手段と、 を具備するデータ処理装置。 ８．前記請求項７に記載されるデータ処理装置であって、各分類特性が、前記通 信ネットワークの外の別のネットワークを識別し、別のネットワークで関連付け られた通信が発生するデータ処理装置。 ９．前記請求項７または８の内のいずれか１つに記載される装置であって、前記 通信ネットワークがＰＳＴＮである装置。 １０．請求項７、８、または９の内の１つに記載される装置であって、前記デー タ・アナライザが、中断されたデータ記憶装置内に、それ以降の処理のために、 修正またはデフォルトに設定できないデータを記憶するための手段を具備する装 置。 １１．請求項７から１０に記載されるデータ処理装置で使用されるデータ・アナ ライザ。 １２．複数の別のネットワークに接続され、複数の別のネットワークから通信事 例を受け取る第１通信ネットワークで使用するためのデータ収集処理装置であっ て、 ａ）前記別のネットワークの内の１つで生じた第１ネットワークに着信する通信 事例を登録するための登録手段と、 ｂ）前記通信事例のレコードをフォーマットするための手段であって、レコード が別のネットワークの内の前記１つを識別するデータおよび通信印す棚スと関連 する期間などのパラ メータ知から構成されるフォーマット手段と、 ｃ）前記レコードを検査するための検査手段と、 ｄ）料金設定および課金データを検査されたレコードと結び付け、料金設定済み の課金され、検査されたレコードの分類されたアレイを提供するための料金設定 および課金手段であって、アレイが別のネットワークのアイデンティティに従っ て分類される料金設定および課金手段と、 ｅ）検査手段により拒絶されるレコードを解析するための解析手段であって、解 析手段が、拒絶の理由に従って少なくとも３つの方法の内の１つで拒絶されたレ コードを処理し、前記３つの方法が、 ｉ）検査されていないレコード（ＮＶＲ）の値を最適値に設定することと、 ｉｉ）ＮＶＲの値をデフォルト値に設定することと、 ｉｉｉ）ＮＶＲをアーカイブに入れるか、ダンプすることと、であり、ｉ）また はｉｉ）のどちらかで処理されたレコードが、直接的、あるいは間接的に、検査 済みレコードとして料金設定および課金手段に送信されるデータ収集処理装置。 １３．請求項１２記載の装置であって、通信事例が前記第１ネットワークの交換 機により受け取られ、通信事例のレコードが前記登録手段としてデータ・コレク タに送信され、データが前記レコードに取り込まれる経路選択情報により提供さ れる別のネットワークの内の前記１つを識別し、検証手段が経路選択参照データ ・モデルいアクセスし、レコードの検査で使用される基準の内の１つが経路選択 情報と経路選択参照 データ・モデルの間の相互関係の程度である装置。 １４．請求項１２または１３のいずれか１つに記載される装置であって、解析手 段が少なくとも４つの方法の内の１つで拒絶されたレコードを処理し、４つの方 法が、請求項１２のｉ）からｉｉｉ）およびｉｖ）から構成され、ＮＶＲに関す るデータを、後でアクセスおよび解析が可能な中断されたデータ記憶装置内のフ ァイルに付加する装置。 １５．請求項１４に記載される装置であって、中断されたデータ記憶装置内の各 ファイルが、同じエラー・パターンが設定されるＮＶＲ専用である装置。 １６．請求項１２から１５のいずれか１つに記載される装置であって、料金設定 および課金手段が、検査手段を備えるか、検査手段にアクセスし、最初のデータ が装置で検査されてから破損したデータの再処理を可能とするために、検査され ていないレコードを解析手段に出力できる装置。 １７．複数のネットワークに関連する通信レコードを収集、処理する際に使用す るデータ収集処理システムであって、前記装置が、前記複数のネットワークの第 １ネットワークと前記複数のネットワークの少なくとも１つのそれ以外のネット ワークの間の接続点で作成される通信レコード用の少なくとも１つの入力を具備 し、前記レコードが、関連通信事例がその中で生じるか、それがその中から前記 第１ネットワークに入ったネットワークを識別し、装置が、さらに、レコードの フォーマットおよび経路選択情報という点を検査するため検査手段、および前記 検査手段により拒絶されるエラーが発生 したレコードを解析するための、前記エラーが発生したレコードを分類し、デフ ォルト値をエラーが発生したレコードの少なくとも１つのカテゴリに適用する機 能を持つデータ解析手段、前記ネットワーク識別に従って検査され、デフォルト 設定されたレコードを分類するためのデータ分類手段、および分類されたレコー ドを受け取り、識別されたネットワークに関連する料金請求書作成事業体で使用 するための料金請求書情報を作成するための料金設定手段を具備する装置。