JP3732507B2 - 通信ネットワーク用データ補正システム - Google Patents

Description

本発明は、マルチネットワーク通信におけるデータ収集及び処理で使用されるデータ補正システムに関する。
電話、データ伝送等の通信が単一ネットワーク内で起こる場合、これら通信関連のデータがログされ処理される。通常、公共の電話交換ネットワーク（ＰＳＴＮ）において、ネットワークオペレータが通話を開始した人に対し請求項目を生成できるよう通話時間に関連したデータが収集され、少なくとも日時、通話形態に関したデータが処理される。
近年、使用者が選べるサービス、形態等が大幅に拡大し、ＰＳＴＮのデータシステムも必然的に複雑の度合いを深めて来ている。例えば、０８００番の導入により、もはや請求を受けるのは通話を開始した人とは限らなくなって来た。ＰＳＴＮにおいて更に複雑な多くのサービスが実験中か、あるいは既に実用化されている。例えば、発呼人により所定番号に対して開始された呼がネットワークを介し自動的に異なる番号に転送される呼転送があり、この場合、差額を着信側が負わされる。
大幅な変換過程にある通信ネットワークの別の点は、多数のネットワークオペレータの存在である。過去、ＰＳＴＮは、国家基盤の一部として政府組織が主な運営機関であった。最近ＰＳＴＮの民営化及び規制緩和が益々進み、より多くのネットワークオペレータが有効となり、これらネットワークオペレータは、実用的な理由からネットワーク間接続を可能としなければならない。すなわち、ネットワークオペレータは、自分のネットワーク内、あるいは限られた数の独立しているが同様の運営機関を有する相互接続ネットワーク内での通信ばかりでなく、理論的には極めて多数の形態が異なる競合ネットワークでの通信も考慮し、広範なサービスの提供を心がけなければならない。
従って、オペレータのネットワーク外の通信だが、そのネットワーク内で終了、あるいは単にそのネットワークと交差する場合であっても、その通信との関連でデータを収集し処理することがより重要になっている。
呼が一カ所以上のオペレータネットワークを通過する場合、お互いの呼の伝送のためオペレータ間で価格合意、請求合意が必要となる。このような取り決めは、単に送り手が全てを保持するもの（ＳＫＡ）から複雑な価格付け方式まで幅広く設定可能である。
テレコミュニケーションでの別のネットワークオペレータ、あるいは運営機関間において、呼が開始されるネットワークに対して責任のある運営機関により呼データが収集されるのが確立された方法であった。該呼が第２のネットワークで終了する場合、第２のネットワーク関連の運営機関は、例えば会計目的等、第１のネットワークに責任のある運営機関により収集されたデータに依存する。しかし、テレコミュニケーション環境の変化は、政治的にも、技術的にも急激に進んでいる。競走が激化する中、ネットワーク運営機関にとり自分のネットワーク内での通信ばかりでなく、開始は別の場所だが自分のネットワークで終了、あるいは交差する通信にもより多く関心を払うようになることは当然である。自分のネットワーク内で起こる通信でも、それが競合オペレータあるいは運営機関に属する場合、少なくとも競合オペレータの会計をクロスチェック可能とすることが望ましい。
従来、ＰＳＴＮでの呼に関するデータ収集箇所は、通信をそのまま拾うため地域ネットワーク交換機であった。しかし、この従来の方法では、ネットワーク間通信に関して何らのデータ収集規定もしていない。ネットワークに入って来る呼に関するデータを収集するデータ収集箇所が存在したにせよ、このようなデータを詳細に処理することに要される施設は膨大である。例えば、英国においてブリティッシュテレコミュニケーション（ＢＴplc）により運営され、マン島及びセルネットセルラーネットワークを含む他のネットワーク運営団体からＰＳＴＮに入って来る呼は、１９９２年３月までの１２カ月間で１，５４０万呼／日と推定された。この数字は、１９９５年３月までの一年間で２，７００万呼／日程度にまで増加すると見込まれる。全ての呼通信を考慮した場合、ＢＴＰＳＴＮ内で起こるものも含め、１９９５年には６，０００万呼／日と予想されている。
極めて膨大なデータ量にもかかわらず、本発明によれば、主要テレコミュニケーションネットワーク、英国ＢＴＰＳＴＮに入って来る呼に関連したデータの収集及び処理工程をデザインすることは可能であることが分かっている、この工程により外部ネットワーク運営機関に適切に割り当てられるばかりでなく、項目別請求も可能とする会計情報を関連ネットワーク運営機関が生成できるよう十分詳細な出力を生成することが可能である。すなわち、会計情報は十分詳細に分類でき、前もって選定された基準を満たす限り、ブリティッシュテレコミュニケーションからの英国ＰＳＴＮ用国家請求システムにおいて現在有効な項目別請求の方法で個人別呼の識別さえ可能である。
本発明の第１のアスペクトによれば、第１通信ネットワークにおける通信に関するデータの収集及び処理工程が提供され、該ネットワークは少なくとも第２通信ネットワークに直接あるいは間接に接続された一箇所を含み、この接続点により第２ネットワーク内で起こる通信が該第１ネットワークに伝送され、交差あるいは終了することが可能であり、前記工程は以下のステップを含むことにより構成される：
i）前記接続箇所でのデータアクセス点におけるデータ収集、前記データは第２ネットワーク内で起こる通信に関してのもので、前記通信に関するルート情報、少なくとも一個のパラメータ測定、例えば時間より構成される；
ii）前記データをデータ処理システム内に転送；
iii）前記データの処理．
第１ネットワークと別のネットワーク間の接続においてデータを収集することにより、第１ネットワークと関連した運営機関が第１ネットワークに入って来る通信についての情報を直接に得ることができ、従って他のネットワークオペレータ、あるいは運営機関により提供されたデータのクロスチェックが可能となる。
本発明の第２のアスペクトによれば、別のネットワークとの接続点で収集されたＰＳＴＮデータを処理するためのデータ処理装置が提供され、前記装置は以下により構成される；
i）通信ネットワークからの通信に関するデータの入力用データ入力部、前記データは、少なくとも一個あるいは複数の分類特徴を含む；
ii）データ入力部で受けたデータの完全性及び十分性をチェックするための確認手段；
iii）確認手段により拒否されたデータを分析し、確認手段に修正又はディフォルトデータを提供するためのデータアナライザ；
iv）確認手段が出力した確認データを更新可能な基準情報に従い価格付けするための価格付け手段；
v）メモリ位置内に価格付け手段からの価格付け、確認データを出力するための出力手段、各メモリ位置は前記分類特徴の一つ以上に関連したデータ専用である。
価格付け手段は、汚染されたデータが潜在的に再フォーマットされ、あるいは補正され、従って通信の有効レコードとしてシステムに再入力されるようデータの確認もでき、データアナライザ、前記データアナライザ又は別のデータアナライザでもよい、にエラーデータを出力できるようにすることが望ましい。
また（あるいはこれに代わって）、この更なるデータ分析ステップを使い、別の形態のエラーに関しデータを分析してもよい。例えば、確認手段により見つけ出されたエラーデータに対して実行されるデータ分析は、主にフォーマット及びルーティング情報に関連してエラーとなり、一方、価格付け手段からのエラーデータは主に価格付け情報に関連してエラーとなる可能性がある。
本発明の第１、第２のアスペクトに記載したような工程及びデータ処理装置においての重要部は、そこで使われるデータアナライザである。
本発明の第３のアスペクトによれば、一カ所以上の他のネットワークに接続された通信ネットワークにおいて使用されるデータアナライザが提供され、前記データアナライザは、前記ネットワークに対して収集されたデータの入力部と、前記データは前記ネットワーク関連の確認手段により拒否され、データ内での無効の形態にアクセスする手段と、それに応じてデータを処理する手段より構成され、前記データ処理手段は、ディフォルト値を加える手段と、一時データ保存部内のファイルにデータを追加する手段を含み、データが追加された各ファイルは、特徴的エラーパターンを示し、一時データ保存部内の一つのファイルに加えられたデータは全て同じ方法、例えば前記エラーパターンに関しての更新基準情報により補正可能となっている。
分類特徴は、典型的に、共通の会計法人に請求可能な通信、例えば共通の各通信ネットワーク内で起こる通信に関連するデータを各メモリ位置がそれぞれ保持するようにしてもよい。
分類特徴は、上記データ処理工程の数種の段階の何れにおいても加えてよい。しかし、例えばＰＳＴＮにおいては、生成されるエラーデータの性格により、一般に確認手段関連のデータアナライザ（iii）と価格付け手段（iv）間において分類手段を設けることが望ましい。よって価格付け手段は既に分類されたデータに作用することになる。分類特徴がデータにより代表される通信に関連し請求される別の法人に関する場合、この場合も個別法人に関連する制約を加えることにおいて価格付けを潜在的に簡易化できるという利点を有している。
ＢＴＰＳＴＮ等のネットワークは、地域交換機及び幹線交換機の両方より構成され、交換機相互の呼伝送ばかりでなく地域の呼をエンドユーザへ送るものである。すなわち、請求、あるいは請求確認を可能とするのに必要なデータ収集及び処理は、極めて広範な変数に対処できるよう十分複雑でなければならない。このことは、幹線相互間のみの交換機伝送、あるいは地域のみの呼伝送を提供するネットワークとは対象的な状況である。
本発明の実施例に係るシステムを以下のような添付図面を参照して例示的に説明する。
図１は、テレコミュニケーションネットワークに入って来る呼のための会計システムを支援するよう呼情報により構成されるデータを収集及び処理する方式のアーキテクチャを示す概略図である；
図２，図３及び図４は図１に示す方式のフロー概略図である；
図５は、図１の方式のハードウェア及び通信装置を示す図である；
図６は、図１の方式におけるストリーマとデータアナライザ間で使われるソフトウェアアーキテクチャを示す図である；
図７は、図１の方式で使われる企業システムを提供するハードウェアのアーキテクチャを示す図である；
図８は、図７の企業システムで使われるバッチ配列処理アーキテクチャの略図である；
図９及び図１０は、図１の方式で使われる交換機からのデータポーリングに関連して、交換機ファイル及びアドバンスドプロトコルデータユニット（ＡＰＤＵ）を示す図である；
図１１から図２１は、図１による方式のストリーマとデータアナライザで使われるフローチャートである；
図２２は、図１での方式各要素間での相互処理を示す図である；
図２３から図３０は、法人のライフヒストリィ図であり、各法人内のレコードが入力されている状態を示し、この状態からどの動作によって他のどの状態に到達できるかを示す；
図３１及び図３２は、図１の方式で使われるエキスパートシステムにおいて事項の状態、パターンネット、続くデータの駐在、ルールの発行を示す図である；
図３３及び図３４は、図１の方式のデータアナライザで使われるルールベースシステム、ケースシステムのそれぞれのオブジェクトヒエラルキを示す図である；
図３５は、図１の方式内のデータアナライザ用エキスパートシステムとオラクル（ORACLE）インタフェースの構築に関するデザイン原理を示す図である；
図３６は、図１の方式で使われる企業システム用データモデルを示す図である；
図３７から図４３は、図１の方式で使われるデータアナライザの動作に関連したフローチャートである；そして
図４４は、図１の方式で使われる企業システムに関連してデータを強調したデータフローを示す図である。
次に、本発明の実施例を図面を基に説明するが、その中で”ＩＮＣＡ”，“ＩＤＡ”という語が時折使用されるが、これらはネットワーク間コール会計（全システムを指す）とＩＮＣＡデータアナライザをそれぞれ表している。後者は、エキスパートシステムを含みストリーマ６とインターフェースするデータアナライザ７を指すものである。
本発明の実施例の説明は以下の順序を基にしている：
１．図１：アーキテクチャのブロック図
２．図２，図３及び図４：処理概略フロー図
i）相互接続点及びＤＤＣ
ii）ストリーマ
iii）企業システム（あるいはボックス）
３．図１及び図５から図８：ハードウェア、通信とソフトウェアアーキテクチャ
i）ＰＯＩ及びＤＤＣ
ii）ストリーマとデータアナライザ
iii）企業システム
iv）クライアントボックス
４．図９及び１０：コールレコードとデータフォーマット
i）コールレコード
ii）交換機データ上へのデータ構造のマッピング
５．図１１から図１９及び図２２から図３０：ストリーマとデータアナライザ処理の更に詳細なフロー図
i）ストリーマ：ＤＤＣポーリング
ii）ストリーマ：ファイル処理
iii）ストリーマ：ＤＤＣ削除
iv）データアナライザ：処理
v）エンティティライフヒストリー
６．図３１から図３５：エキスパートシステム
i）概略
ii）ルールベース一般ルール
iii）ケースベース
iv）ORACLEインタフェース
７．図２０，２１及び図３７から図４３：データアナライザによるエキスパートシステムの使用
８．図３６及び図４４：企業システム、データ分析と価格付け及び請求
９．オーディットトレィル
１．図１：アーキテクチャブロック図
図１において、第１ネットワーク１において、例えばＢＴＰＳＴＮ、第２ネットワーク２内で開始されるか、あるいはそこから入って来る呼に関連したデータを収集するための方式が提供される。データは、前記第１ネットワークの交換機により提供される相互接続点（ＰＯＩ）３で収集され、ＰＳＴＮ内の約１０箇所の地域データ収集所（ＤＤＣ）５の一つにもたらされる。ここでは各着信呼のルート情報から構成されるデータが保持され、よって例えば呼の予定目的地、着信呼の伝送媒体、項目化データの識別が可能となり、結果各呼はイベントとして扱われ、さらに（望ましくは）単に第２ネットワークでの通過呼であったものでも開始されたネットワークに関して正確に説明されるようラインＩＤの呼出しが可能となる。
各地域データ収集箇所（ＤＤＣ）５は、主にルーティング基準モデルに対して、ファイル及びコールレコードの両レベルにおいてコールデータを拡大し、確認するストリーマシステム６によりポーリングされる。（ＢＴＰＳＴＮの地域データ収集所５は関連データを拾うが、その役割は、ネットワーク仲介プロセッサ等他の会計システム要素によっても同様に果たされる）。ストリーマ６により無効とされたデータは、知識ベースシステムを利用しその無効性を評価し、可能であれば問題を解決するためデータを修正するデータアナライザ７に転送される。このことは、無効データは一般に説明可能入力として失われてしまうためシステムの重要な要素である。一方、有効データは、関連した呼を受け取る第２ネットワーク２と関連したオペレータに従い流され、企業システム８に送られる。
ストリーマ６は以下の機能を果たす：
○本発明のデータシステムによる処理を待つファイル用に各ＤＤＣ５をポーリングする。
○ルーティング基準モデルに対しファイル及びそのコールレコードを確認する。
○コールレコードを拡大し、正しいテレコムネットワークオペレータに割り当て。
○ＩＤＡ７への無効データを拒否する。
○ＩＤＡ７から受け取った元のファイルを生レコードバックアップインタフェースディレクトリィに複写する。
○データが一旦インタフェースディレクトリィ上に確保されたらＤＤＣ５よりファイルを削除する。
○ルーティング基準モデルデータを入力するためユーザにユーザインタフェースを提供する。
○ストリーマを通して完全なオーディットトレィルを提供する。
○ユーザにストリーミングの動作とデータの完全性を監視する能力を提供する。
データアナライザ７は以下の機能を果たす：
○一個以上のエラーを含むファイル用にインタフェースディレルトリィをポーリングする。
○有効なコールレコードだがルーティング基準モデルに適合しない場合、その不正確なコールレコードを中断領域に保持する。
○ルーティング基準モデルの更新後データを流すことができるようユーザにインタフェースを提供する。
○不正確なフィールドにルール指定に応じディフォルトコールレコードを供給する。
○エラー閾値を越えていないため未だ流されていない何れの正確なデータも流す。
○補正されたデータは何れでも流す。
○コールレコードレベルにおいてＩＤＡ７を通し完全なオーディットトレィルを提供する。
企業システム８はまた、呼パラメータばかりでなく相互に接続された二つのネットワーク１，２のオペレータ間の関係からの要素を取り出すのはこの企業システムであるため、最近重要な役割を果たすようになっている。呼が会計手順に与える影響は、一部には関連オペレータ間での”サービスレベル合意”等の要素によって決定される。これらの要素がルックアップ表及び／又は国家請求データベース（ＮＣＤＢ）９を含む種々の情報を参照し実行されるのは企業システム８においてである。特に後者に関しては、例えば時間差請求レートも考慮される。
従って、企業システム８からの出力は、最終的には、接続点３から収集され、適用すべきオペレータ指定、時間差パラメータ等の関連パラメータを参照し処理された元の呼データを表し会計システムで使用される情報となる。この出力は、パソコンによりユーザにアクセスを与えるクライアント１０に提供される。
２．図２，図３及び図４：処理概要
図２，図３及び図４は、上記処理の概要を示すため、呼に応じての動作フロー図である。
２（i）相互接続点とＤＤＣ
図２は、着信呼に応じてＰＯＩ交換機３及びＤＤＣ５により実行される処理ステップを示す。これらのステップは全て知られたものであり、本発明において交換機３、ＤＤＣ５には何らの修正も加えていない。
図２において、関連ネットワーク１に入って来る、あるいは出て行く呼は、ステップ２００において、ＰＯＩ交換機３においてコールレコードを生成する。ステップ２１０では、交換機３が各呼に０−９９９９シリーズ内の”ファイル生成番号”を与える。ステップ２２０では、交換機３がコールレコードをアドバンストプロトコルデータユニット（ＡＰＤＵ）にグループ化し、ＡＰＤＵをファイルにグループ化する。
ステップ２３０では、ＤＤＣ５がＡＰＤＵフォーマット内の全コールレコードデータに対して交換機３をポーリングする。ステップ２３５では、ＤＤＣ５がヘッダＡＰＤＵ、トレーラＡＰＤＵの形態で制御データを加える。また、ステップ２４０において、ＤＤＣ５は各ファイルに０−９９９９９９の範囲内のファイル列番号を与え、ステップ２４５で各ＡＰＤＵに０−１６３５３の範囲内のＡＰＤＵ列番号を与える。この場合のＡＰＤＵは二値形式である。ステップ２５０では、ＤＤＣ５がファイルをディレクトリィ構造内に配置し、ストリーマ６はそこからポーリングによりファイルを拾うことができる。同時に、ステップ２６０において、ＤＲＩＩＮＤＥＸと呼ばれるカタログファイル内にファイル入力がなされる。このカタログファイルは、ストリーマ６によるポーリングに際して有効な全ファイルのリストを含んでいる。
２（ii）ストリーマ
図３において、ステップ３００でストリーマ６は定期的にＤＤＣディレクトリィ構造のポーリングを行い、コールレコードをＲＡＭ（ランダム・アクセス・メモリ）内に保存し、各ファイルは１Mバイトにロードされる。このポーリング処理は、最近のＤＲＩＩＮＤＥＸファイルを複写するステップを含んでいる。ステップ３１０では、実際にはステップ３００のＤＤＣポーリング処理内で実行できるが、データが二値からＡＳＣＩＩ（情報交換機用米国標準コード）形式に変換される。
ステップ３２０では、ストリーマ６がコールレコードの確認を実行する。呼が不完全、あるいは不正確で確認できない場合、ストリーマ６の次の処理ステップ、そして最後に請求計算処理に進む代わりに、不正確データアナライザ７での更なる分析を受けるインタフェースディレルトリィに転送される（ステップ３３０）。
他方、有効なデータの場合、ステップ３４０において識別処理を受ける。ここでは、コールレコード内のデータを使い、他のどのネットワークで呼が開始され、あるいはどこからＢＴＰＳＴＮに入って来たか、あるいは状況によってはどこで終了するのか判別される。請求用関連ネットワークオペレータを表すコードがコールレコードに加えられ、次に、ファイルがステップ３５０においてこのコードに従い分類され再構成される。従って、この時点でコールレコードはネットワークオペレータ、あるいはこれらの呼の費用を少なくとも最初の段階で負う他の関連エンティティに応じ分類することができる。
ステップ３６０，３７０において、ストリーマ６は新しく構成されたファイルを企業システム８に出力し、ＤＤＣ５上のＦＴＡＭファイル保存部からファイルデータを削除する。
データアナライザ７に関しては、確認不可能なデータは請求できないため重要な役割を担っている。データアナライザ７は、ステップ３８０において、ステップ３３０においてストリーマ６により入力されたエラーファイル用にインタフェースディレクトリィをポーリングする。次に、データアナライザ７は、エラーデータを元のシステム内に戻す三回の異なる機会を与えられる。
ステップ３８２では、データの修正が試みられる。可能であれば、修正データはインタフェースディレクトリィに返還され、そこからストリーマ６が拾い出す。ステップ３８４では、データアナライザ７がディフォルト値を修正不可データに加えることが可能か試みる。この方法では”修繕”不可能なデータ要素がいくつか存在する。なぜなら例えばオーディットトレールに影響を与えるからである。最後に、ステップ３８６では単にデータアナライザ７がデータとルーティング基準モデル（ＲＲＭ）間で不適合が存在するかチェックする。後者はルーティング情報を与えるデータベースであり、例えば呼の目的地を識別するためＤＤＣ５で使用される。ＲＲＭのコピーは通信ネットワーク内の異なる場所で保持され、一つのコピーがタイミングがずれて、あるいは不正確に更新される場合、データ内で不適合を生じてしまう。この場合、データアナライザ７がこれらのコールレコードを中断ファイル内に入力し（ステップ３８８）、それによりＲＲＭのチェック後ストリーマ６処理の戻される。
データアナライザ７が上記の何れの方法でもデータ処理ができない場合、ステップ３９０において”ＳＵＭＰ”に出力される。すなわち、このデータは実際上失われ、決して請求されることはない。しかし、長期的なシステムの変更、補正を行うためには、分析において有効である。
２（iii）企業システム
図４において、ストリーマ６により確認、処理されたファイルレベルのデータは、最初の段階、ステップ４００、がファイル列番号の確認である企業システム８に入力される。企業システム８はファイル列番号順にファイルを処理するが、ストリーマ６は異なる交換機３からのデータを並列に処理する。ファイル列番号が間違っている場合、企業システム８はそのファイルを無効とし、処理を停止する（ステップ４１０）。
ファイル列番号が受諾可能な場合、企業システム８はステップ４２０に進み、コールレコードを確認する、この時はストリーマ６のように主にＲＲＭに関してではなく、請求可能エンティティ、そして請求可能エンティティと例えばＢＴ等の第１ネットワークオペレータの関係に関連したデータにより強調点が置かれる。
請求可能エンンティティとＢＴ間ではサービスレベル合意（ＳＬＡ）を締結しており、コールレコードが現行ＳＬＡ下ではその請求可能エンティティに対して有効でないコースタイプを表すこともある。
３．図１，図５，図６，図７，図８：ハードウェア通信とソフトウェアアーキテクチャ
３（i）相互接続点３とＤＤＣ５
交換機３及びＤＤＣ５には既存のタイプを使用するため、ここでは説明を省略する。その動作を簡単に説明すれば以下のようになる。
図１と図２において、英国テレコミュニケーションplc （ＢＴ）が運営する英国ＰＳＴＮに入って来る、あるいは出て行く呼は、現在ではどのようなものでも相互接続点（ＰＯＩ）３としてのディジタル電話交換機を通過する。このような交換機は、本発明のデータ方式に関連するものは全て、現在ディジタル接点交換機ユニット（ＤＪＳＵ）、ディジタル地域交換機（ＤＬＥ）、あるいはディジタル主交換機ユニット等の形態のシステムＸ電話交換機である。
ＢＴネットワーク１に入って来る、あるいは出て行く電話呼はどれでも、図２のステップ２００が示すように、英国テレコムコールレコードタイプ６として知られる形態でＰＯＩ交換機３内にコールレコードを生成する。システムＸＰＯＩ交換機３は、ＡＰＤＵフォーマットの全コールレコードデータのためステップ２３０においてＤＤＣ５により毎日ポーリングが行われる。ポーリングは、高速ＢＴデータリンク間のファイル転送アクセス管理プロトコル（ＦＴＡＭ）を利用し実行される。ＤＤＣ５はＰＯＩからのコールレコードファイルを純粋に収集する役割を果たす。すなわち、ＤＤＣ内ではコールレコードの処理は全く実行されない。ＤＤＣはコールレコードのポーリング専用ではないが、データ収集、処理、転送等他のタスクを種々行う。
ストリーマシステム６がＤＤＣ５上のＦＴＡＭファイル記憶にアクセスするには、別が必要となる。これは、ネットワークノードＩＤ（ＮＮＩ）を関連エンドシステムとしてのストリーマ６に割り当てることにより行われる。ＮＮＩは次に、ＦＴＡＭファイル記憶へのアクセスのためパスワードと共にユーザ名として使用される。
３（ii）ストリーマ６とデータアナライザ７
図５において、ストリーマ６及びデータアナライザ７のハードウェアと通信を示す図は次のようになる。（図５で示す通信アーキテクチャは種々の環境で適合する多くの通信アーキテクチャのほんの一つを表している）。ストリーマ６は、主ストリーマシステム６上でエラーが起こると直に干渉して来る”ホット待機”ストリーマボックスバックアップ（ＳＢＢ）６ａを有しており、両方ともＵＮＩＸオペレーティングシステムを走作させるHewlett-Packard社のHP８５７Sミニコンピュータ上に設置することができる。ストリーマ６とＳＢＢ６ａは、ＬＡＮ（ローカル・エリア・ネットワーク）５１５に接続してもよい。
ＤＤＣ５（図示せず）からのストリーマ６（あるいはホット待機６ａ）によってポーリングされた生データは、光学ディスク記憶システム（図示せず）を使いバックアップされる。データは、ＢＴメガストリーム高速データリンク及びマルチプロトコルルーティングネットワーク（ＭＰＲＮ）５１０上のＦＴＡＭ（ファイル転送、アクセス、管理）を使いポーリングされる。ＭＰＲＮ５１０は、ＯＳＩ（オープンシステム相互接続）互換である。ストリーマ６とデータアナライザ７間では直接通信リンク５１５が存在し、”イーサネット”ブリッジ５０５がストリーマ６及びデータアナライザ７に対して、例えばＰＳＴＮ用にＢＴによって使用されるような、少なくともＷＡＮ（ワイド・エリア・ネットワーク）の一つへのアクセスを提供する。代わってＷＡＮ５１０は、一次ＢＴＰＳＴＮネットワーク管理データセンタに位置する企業システム８及びクライアンボックス１０へのアクセスを提供する。すなわち、ネットワーク管理データセンタは、例えば分析用に、そして初期並びに更新ルーティング基準データを入力するため、データの入出力が可能である。
図６において、データアナライザ７はHewlett-Packard社のHP９０００に設置してもよい。ストリーマ６及びデータアナライザ７用ソフトウェアは、以下の技術を利用する：
○バッチ処理用ＩＥＦ
○エキスパートシステム能力用ＡＲＴ／ＩＭ
○ＨＰ／ＵＸバージョン９．０
○レポート用ＰＣクライアントとしてのビジネスオブジェクト
○ORACLEバージョン６
−ＳＱＬＦＯＲＭＳ３
−ＳＱＬ*レポートライタ１．１
−ＰＬ／ＳＱＬバージョン１．０
−ＰＲＯ*Ｃ
−ＳＱＬ*ＮＥＴＴＣＰ／ＩＰバージョン１．２
これらは全て知られたものであり、直に手に入れることができる。例えば、”ＩＥＦ”はジェームズ・マーチン・アソシエーツの”情報エンジニアリングファシリティ”コンピュータ支援ソフトウェアエンジニアリング（ＣＡＳＥ）ソフトウェアであり、実行可能コードを生成するソフトウェアエンジニアリング工具である。データアナライザ処理は、物理的にデータアナライザ７プラットフォーム上で走作し、ＳＱＬ*ＮＥＴを使いストリーマ６プラットフォーム上のORACLEデータベース６０に接続する。ＳＱＬ*ＮＥＴＴＣＰ／ＩＰ（トランスポート制御プロトコル／インターネットプロトコル）はまた、ＭＰＲＮ５１０上、あるいは適当なＴＣＰ／ＩＰ搭載ネットワーク上のストリーマ６に位置するORACLEデータベース６０にアクセスするため、ストリーマ／データアナライザ・ビジネスオブジェクトORACLEユーザ６５により使うことができる。
ストリーマ６とデータアナライザ７はデータベースファシリティ６０を共有し、ユーザは、例えばストリーマ６による確認で使用される基準データをチェック、あるいは更新するため、アクセス要求してもよい。データベースファシリティ６５は、特にＤＤＣ５からのファイルが処理されルーティング基準モデルを含むファイルに対して制御を維持する。
ＰＲＯ*Ｃコードは、図６が示すように、ＩＥＦコード６１及び外部活動ブロック（ＥＡＢ）６２内にＩＥＦにより生成される。ストリーマ／データアナライザソフトウェアライブラリィ６３は一組の”Ｃ”及びＰＲＯ＊Ｃモジュールで、ＥＡＢ内から、あるいはＡＲＴ ＩＭ（情報管理用自動化推論ツール）６４から呼び出し可能である。ＡＲＴ ＩＭは私有のエキスパートシステムであり、アプリケーション開発ソフトウェアである。ＡＲＴ ＩＭの開発は、”スタジオ”、つまりエキスパートシステムへのモチーフインタフェース、内で行われる。一旦”スタジオ”内でユニット試験を受けたエキスパートシステムは、”スタジオ”内から”Ｃ”モジュールを生成することにより展開される。従って、例えばＯＳ／２ワークステーション上にＩＥＦコード６１を生成し、このコードを展開プラットフォーム上のＥＡＢ６２、ストリーマ／データアナライザドフトウェアライブラリィ６３、更にＡＲＴ ＩＭコードライブラリィ６４と連結することにより処理生成が可能である。
３（iii）企業システム８
図７及び図８において、カンパニーボックス（あるいはシステム）８は、Hewlett-Packard社のミニコンピュータ７０、ＵＮＩＸオペレーティングシステムを走作する”エメラルド８９０／４００”ORACLEリレーショナルデータベース管理システム（ＲＤＭＳ）、そしてジェームズ・マーチンアソシエッツのＩＥＦケースソフトウェアを使い書き込まれたカスタムアプリケーションより構成される。
カンパニーボックス８内では、全てのコールレコードが複雑な価格付け、請求基準表に応じ価格付けされ、ORACLE要約表がインクレメントされる。基準表には交換機設置データ、ルーティング基準データ、会計契約、価格付け請求データ、他種々の例外が表される。価格付け、請求基準表は、ＢＴ国家請求データベース（ＮＣＤＢ）及びオペレータ間卸売り価格付け合意から作り出される。
ミニコンピュータの極めて多量の処理タスクを支援するため、Hewlett-Packard社のＵＮＩＸワークステーション８０、例えば”７３５”、がタスク処理用の共同プロセッサとして取り付けられる。カンパニーボックスが処理できるコールレコード数を増加するためミニコンピュータ７０にこのようなワークステーションを実際無限数接続できるが、ＢＴＰＳＴＮにおいて必要最小限は現在１２程度である。前記のように、１９９５年までには６，０００万コールレコード／日に処理数が増加しており、本発明のデータ方式が必要となるであろう。方法としては、Hewlett-Packard社の”タスクブローカ”として知られる製品に依存し、これはバッチ配列上で走作するよう設置された本発明のデータシステムである。この目的のため、カスタムパラメータがタスクブローカ内に供給される必要があり、これらパラメータのうち適切な組をリストアップすると以下の通りである：
i）グローバルパラメータセッティング（オプション）
−どのクライアントがサーバにアクセスするか
−どの機械がタスクブローカを遠隔運営するか
−そのネットワークマスクを使うべきか
−許される最小・最大ＵＩＤ（ユーザＩＤ）
−ロギング冗長
−同時に処理されるタスクサブミッタルの最大数
−クライアントがサービスのため接触すべき機械リスト
ii）クライアントパラメータセッティング（オプション）
−各サービスのリスト、クライアントがサービスのため接触すべきサーバ
iii）種別パラメータセッティング
−各サービスも種別内に存在しなければならない、各機械が提供する各タイプのサービス用に種別を設置する
iv）サービス定義（各サービスに対し以下を指定しなければならない）
−種別
−類似性
−アーギュメント
注：類似性は０−１，０００間の数字で表せられ、ノードのサービス提供能力を示す。
タスクブローカは、どのワークステーションが名のり出てファイル処理を行うかに対し制御する順番システムである。企業システム８でタスクブローカを使うため、三種のプログラムと構成ファイルが存在する。構成ファイルは、どのワークステーションと通信可能か、ファイル処理にどのプログラムを呼び出すか、優先順位の付け方等、タスクブローカが企業システム環境で動作するのに必要なパラメータを設定する。上記で設定されたのは構成ファイルパラメータである。
三種の制御プログラムは概略次のように動作する。ファイルが企業システム８のエメラルドミニコンピュータに入って来た時、マスタプログラム”run-cp.sh”のファイルを処理するためタスクブローカを介し送り出し、ミニコンピュータ内の監視プログラム”cleanup-cp.sh”を作動させる。タスクブローカは、ファイルをワークステーションに割り当て、そこで第三のプログラム”cp.sh”に応じファイルが処理される。巧く行った場合、ファイルはミニコンピュータに戻され、そこで”cleanup-cp.sh”によりクライアントシステム１０の正しいディレクトリィに割り当てられる。”Cleanup_cp.sh”はまたワークステーションの監視も行う。ワークステーションによりあまりに長い遅延があった場合、明らかに問題があるためそのワークステーション上のタスクブローカを閉鎖する。最後に、”cleanup-cp.sh”はまた記録及びイベントロギングも制御する。
最後に、クライアントシステム１０への出力同様、カンパニーボックス８からの価格付けされたコールレコードは、個別の価格付けコールレコードが将来検索され、分析されるよう光学ディスクドライブ７１の配列に保存される。
３（iv）クライアントシステム（あるいはボックス）１０
相互接続呼の要約ORACLEデータベース表は、毎週カンンパニーボックス８からクライアントボックス１０にダウンロードされる。各クライアントボックス（ＣＢ）１０は、Hewlett-Packard社のＵＮＩＸワークステーションであり、例えばManxテレコム等のＢＴと他のオペレータ間で結ばれる単一相互接続合意下で生成される要約データベース表とコールレコードのみ取り扱う。クライアントボックス１０はORACLEＲＤＭ、更にビジネスオブジェクトソフトウェアを走作させる。各クライアントボックス１０からの情報により、ＢＴは、ＢＴネットワークを別のネットワークオペレータが使う場合でもそのオペレータに対して請求可能となるばかりでなく、別のネットワークオペレータから入って来る請求に対してもその確認が可能となる。各クライアントボックス１０は光学ディスク７１の尋問もできるが、クライアントボックス１０と関連した相互接続合意下のコールレコードに関してのみである。クライアントボックスが自分のコールレコードに関して直接カンパニーボックス８に尋問することは不可能であり、ＢＴと他のオペレータ間における他の合意に関してのものではなおさら不可能である。要約表の分析が可能になるようクライアントボックス１０にはパソコンが接続される。
４．図９及び図１０．コールレコードとデータフォーマット
４（i）コールレコード
英国テレコムタイプ６コールレコードは、請求対象顧客を主な目的として生成される。コールレコードには、日時、時間、伝送距離等を基に正確に呼に対して価格を付けるため十分な情報を含有していなければならない。各タイプ６のコールレコードは、以下を含むことができる：
○請求されるレコード長
○レコード使用
○レコードタイプ
○コールタイプ及びコールの有効性
○クリアリングの原因
○時間不連続フラグ（コール中のＧＭＴから、又はＧＭＴへ、ＢＳＴから、又はＢＳＴへの変更）
○コーリングラインＩＤ（ＣＬＩ）
○ルートグループタイプ
○サンンプリング分類
○ルートグループ
○ノード点コード（ＮＰＣ）：ＰＯＩ交換機生成レコード用のユニークな識別子
○リンキングフィールド（一度の請求帯以上のコール両立時に使われる）
○コーリングパーティ分類（商業、住宅、有料電話）
○請求帯
○アドレス日時完全
○応答日時
○コーリングパーティの日時クリア
○着呼パーティの日時クリア
○着呼番号フィールド
コールレコードは、全システムＸ交換機上の歳入分配会計（ＲＡＡ）ファシリティにより捕獲される。前記のように、ステップ２２０において、コールレコードは共にＡＰＤＵ内にグループ化され、ＡＰＤＵは更にファイルにグループイ化され、各ファイルのサイズは最大１Ｍバイトまでとなっている。システムＸＰＯＩ内のこのようなグループ化処理において、個別コールレコードのどのような部も破壊するものはない。コールレコードは全て簡単な二値フォーマットである。
図９において、各交換機ファイル４０には可変長のＡＰＤＵ５１が多数含まれる。各ＡＰＤＵ５１には、また可変長の請求レコードが多数含まれる。しかし、以下の事項は固定となっている：
○交換機ファイルの最大サイズは１Mバイト
○ＡＰＤＵの最大サイズは５１２バイト
○請求レコードの最大サイズは７０バイト
ＤＤＣヘッダとトレーラＡＰＤＵは、ＡＰＤＵタイプがヘッダＡＰＤＵの場合２４１、トレーラＡＰＤＵの場合２４５である以外は同一である。
ヘッダ及びトレーラＡＰＤＵにおいて以下の情報が有効となる。
ＡＰＤＵ長：ヘッダ／トレーラＡＰＤＵの長さ
ＡＰＤＵタイプ：ヘッダには２４１、トレーラには２４５
ユニークなファイル識別子：以下に記すＤＲＩＮＤＥＸを参照
目的地ＮＮＩ：ＩＮＣＡストリーマのＮＮＩ
アプリケーショングループ：ＩＮＣＡデータのアプリケーショングループ＝１４
シーケンス番号：テープ／カートリッジのシーケンス番号
出力ファイルシーケンス番号：ＤＤＣシーケンス番号
受け取られたタイムスタンプＤＤＣデータ：ＤＤＣが受け取ったデータ及びタイムデータ
パートファイルインジケータ：ファイルがパートファイルかどうか示す
例外インジケータ：ファイルのどこが悪いかを示す
読み出しカウント：このファイルが読み出された回数
ファイルサイズ：このファイルのバイト数内のサイズ
非選択ＡＰＤＵのカウント：間違ったＡＰＤＵタイプのＡＰＤＵ数
選択ＡＰＤＵタイプ：ＩＮＣＡデータタイプのＡＰＤＵタイプ
ＡＰＤＵカウント：このファイル内のＡＰＤＵ数
最初のシーケンス番号：開始ＡＰＤＵシーケンス番号
最後のシーケンス番号：終了ＡＰＤＵシーケンス番号
読み出しカウントは、ファイルがストリーマ６によりＤＤＣからポーリングされた回数を表す。パートファイルインンジケータは、ＤＤＣ５による全ファイルの受け取りが成功したか、あるいは残された部分があるかどうかを示す。
例外インジケータは、二つの１バイトビットマスクフィールドであり、本転送に関しＤＤＣ５によって検知されたどのようなエラーでも示す。
上記全フィールドに対する有効値は、以下”企業システム８（あるいはボックス”との関連で記述するコンピュータ支援ソフトウェアエンジニアリング（ＣＡＳＥ）アプリケーションソフトウェア内で確認される。
図１０において、ＡＰＤＵ構造５１が簡単に記述されているが、ここにはＡＰＤＵヘッダ５２、実際の関連請求レコード５３、更にＡＰＤＵトレーラ５４が含まれる。
請求レコード５３のフォーマットは標準タイプが使用され、”Ｃ”構造が正確にこのフォーマット内にマッピングされるようデザインできる。
データが交換機３からＤＤＣ５にポーリングされた時、各データＡＰＤＵの頭にあるデータのいくつかはＤＤＣ５により分解される。このデータは、ＤＤＣ５と交換機３の代表であり、エンド処理システム用の供給データとしては不適格である。
ファイルがＤＤＣ５により適切なディレクトリィ内に複写されると、ストリーマ６がＦＴＡＭを使い複写する時に有効となることが目的だが、ＤＲＩＮＤＥＸと呼ばれるカタログファイル内に入力される。ＤＲＩＮＤＥＸファイル入力いは以下のデータがふくまれる：
i）次の事項を示す活動マーカ（１バイト）
a）無活動入力
b）転送に有効なファイル
c）現在使用中のファイル（例えばＦＴＡＭ転送において）
d）転送が成功したファイル（まだ削除していない）
ii）ＩＮＣＡファイル名フォーマット
iii）次の事項を示す出力ルーティング
a）ＦＴＡＭに有効なファイル
b）磁気テープのみ
iv）作成時間、関連交換機ＮＮＩ等の詳細を含むユニークなファイル識別子
v）ファイルバイトサイズ
vi）ファイル内のＡＰＤＵ数
ii）において、ＩＮＣＡファイル名フォーマットは以下を含む：
vii）ストリーマＮＮＩ
viii）ＮＮＩとクラスタ交換機番号
ix）ＩＮＣＡデータのアプリケーショングループ
x）交換機ファイルのＤＤＣファイルシーケンス番号
４．（ii）交換機データ上へのデータ構造のマッピング
ストリーマ６は、以下の原理を用い、カンパニーボックス８のモデル内で使用されるデータをデータ構造内にマッピングする：
○ＡＰＤＵ長フィールドと請求レコード長フィールドが正しいと仮定される。正しくない場合、ＡＰＤＵ、あるいは請求レコードのどちらかのレベルで確認処理が失敗し、ファイルはデータアナライザ７に流される。
○ヘッダＡＰＤＵ５２を見つけ出すため初期段階で入力データが走査される。これは、２４１（ＨＥＸ：F１）のＡＰＤＵタイプにより判別される。次に、選択されたＡＰＤＵタイプフィールドが、これが間違いなくヘッダＡＰＤＵ５２であると確認するためユニークファイル識別子に沿ってチェックされる。
○ヘッダＡＰＤＵ５２が発見され、ヘッダＡＰＤＵデータ構造がマッピングされた後、ファイル内のＡＰＤＵは全てＡＰＤＵが従う１ワードレコード長のデータ標準に従うと仮定される。
例：
／ＨＥＡＤＥＲ ＡＰＤＵ／ＲＬ／ＡＰＤＵ／ＲＬ／ＡＰＤＵ．．．／ＲＬ／ＡＰＤＵ／ＲＬ／ＴＲＡＩＬＥＲ ＡＰＤＵ
ここでＲＬはレコード長である。
ファイル構造がこの標準がから乖離する場合、ファイルは更なる分析のためデータアナライザ７に流される。このエラー状態は、乖離のあと直ちにＡＰＤＵの確認処理内で検知される。
○各ＡＰＤＵ内の構造は、図６の構造に従うと仮定される。この場合もこの構造からのどのような乖離も、全データ構造マッピングの不一致の原因となり、ファイルが拒否され、データアナライザ７に流されることになる。
○トレーラＡＰＤＵ５４の後にはデータは一個も存在しない。トレーラＡＰＤＵ５４の後の出現するデータは、どれも皆失われる。
５．図１１から図１９、及び図２２から図３０：ストリーマとデータアナライザ処理
５（i）ストリーマ：ＤＤＣポーリング処理
ＤＤＣ５によりファイルが受け取られると、図２を参照の前記のように、これらファイルは確認され（チェックサムを使う）、ＡＰＤＵヘッダとトレーラ５２，５４内のファイルの最初と最後に加えられる。次に、これらのファイルはストリーマ６が使えるようディレクトリィ構造内に配置することにより、ストリーマ６によるポーリングに有効とされ、ＤＲＩＩＮＤＥＸファイルが更新される。このＤＲＩＮＤＥＸファイルにはストリーマ６によるポーリングに有効な全ファイルのリストが含まれ、ストリーマ６はこのリストを使い全ての新しいファイルをポーリングしたかどうか確認できる。
図１１において、ストリーマ６は、”全ＤＤＣを流す”処理に入ることにより多数ＤＤＣのポーリングの準備をする。ステップ７００では、ストリーマ６の”全ＤＤＣを流す”処理が、例えば所定の時間に発動される。ステップ７１０では、ストリーマ６がＤＤＣからのファイルを受け取るのに有効かどうかのチェックがなされる。ストリーマ６が有効な場合、ステップ７２０，７３０，７４０のサイクルに入る。ここでは、ＤＤＣ５のリストを走査し、各ＤＤＣ５のポーリングのため”ＤＤＣ”処理を作成する。リストの最後まで来たらこの処理は終了する（ステップ７５０）。
次に、各ＤＤＣ５に対して、ストリーマ６は”ＤＤＣ処理”を開始する。図１２において、ステップ８００，８０５で、この処理に関係したＤＤＣ５、あるいはストリーマ６のどちらか一方が閉鎖されているかどうかのチェックを開始し、ステップ８１０でＤＤＣポーリングが必要かどうかチェックされる。ＤＤＣ５のポーリングが不可能なある時間があり、ステップ８１５において非ポーリングウインドウが適応するかどうかチェックされる。適応しない場合、ステップ８２０でファイル処理用の空き処理スロットが見つけ出される。これらのチェックが全てクリアしたら、ストリーマ６はステップ８２５においてＤＤＣＤＲＩＮＤＥＸにアクセスし、ステップ８３０でリスト処理を開始し、ステップ８３５でファイルリストの処理を行う。これにより、ストリーマ６がＤＤＣ５から受け取った各交換機ファイルに全ての関連処理を施すことが確認される。ステップ８４０，８４５，８５０では、ストリーマ６がＤＤＣＤＲＩＮＤＥＸからのファイルそ走査し、自分の処理すべき交換機ファイルの記録を作成することによりファイル処理容量を提供し、ステップ８５５，８６０においてファイルリスト内のファイルを処理する。一旦ＤＤＣＤＲＩＮＤＥＸリストからの交換機ファイルが全て処理能力を割り当てられたら、”ＤＤＣ処理”は、ステップ８６５において次のポーリングが何時必要かの記録を更新し、ステップ８７０でスリープに戻る。
ＤＤＣ処理は、ＤＤＣ５あるいはストリーマ６が閉鎖されていた場合、ステップ８７５で停止されることは言うまでもない。更に、ステップ８７０でポーリングが必要でなく、ＤＤＣが非ポーリングウインドウ内にあり、あるいは有効な処理容量が存在しないときは何時でもスリープモードに存在し続ける。
ＤＤＣポーリングアーキテクチャ内の典型的イベントサイクル
以下の事項が仮定される：
ＤＤＣ ＰＯＬＬＩＮＧ ＭＰＨ＝１７
．．．ポーリングまで１時間数分を示す
ＤＤＣ ＰＯＬＬＩＮＧ ＩＮＴ ＨＲＳ＝１
．．．次のポーリングまで何時間待つかを示す
ＤＤＣ ＤＥＬＡＹ ＩＮ ＤＥＬＥＴＥ＝１２
．．．実際の削除要求前にファイルが削除予定された後どのくらいの間待つかを示す
前日の２３：３０にシステムは終了している。
時間表
００：１７ ＤＤＣ処理が目覚め、ＤＲＩＮＤＥＸファイル上に複写を行い、ストリーム６にデータを流すための処理を作成する。
００：３０ ＤＤＣ処理は、最大数の処理が作成されたか、あるいは有効なファイルの全てがダウンロードするためのファイル処理に提供されたかのどちらかの理由でファイルを流す処理作成を終了する。起床時間は００：３０＋ＤＤＣ ＰＯＬＬＩＮＧ ＩＮＴ ＨＲＳとして算出され、ＤＤＣ ＰＯＬＬＩＮＧ ＭＰＨまでの時間（数分）を設定する。
→次のポーリング時間＝００：３０＋１：００＝１：３０（ＭＰＨ設定）＝０１：１７
スリープまでの時間（数秒）を計算する＝ＴＯ ＳＥＣＯＮＤＳ（０１：１７−ＣＵＲＲＥＮＴ ＴＩＭＥ）
ＳＬＥＥＰ（ＳＥＣＯＮＤＳ ＴＯ ＳＬＥＥＰ）
．．．ファイル処理がデータのストリーミングを完了する。
０１：１７ ＤＤＣ処理が目覚める。
５（ii）ストリーマ：ファイル処理
図１３において、ＤＤＣ処理中にステップ８５５で作成されたファイル処理の動作は次のようになる。ステップ１３０２においてファイル処理は、ＤＤＣ処理から受け取ったファイルリストから作業を開始する。ステップ１３０３で、このファイルリストを走査し、リスト内の各交換機ファイルに対して、ステップ１３０５でファイル処理は交換機ファイル記録を読み出し、ステップ１３０６でコールレコードを確認し、ステップ１３０７でもし例えばストリーマ６が続いて閉鎖する場合に使えるようファイルを元のレコードバックアップに複写し、確認エラーがある場合、ステップ１３１０においてファイルをデータアナライザ７に転送し、あるいはステップ１３１２でカンパニーボックス８にそのファイルを流す。
ＤＤＣ５あるいはストリーマ６がステップ１３０４で閉鎖する場合、あるいは例えばＤＤＣ５との通信が失敗し、ステップ１３１３でファイル腐敗が深刻な場合、ステップ１３１３でファイル処理は停止する。交換機ファイル記録は、ストリーマ６との関係で交換機ファイルはどの段階まで到達したかを監視し、各ファイルに対し活動的なものから選択され、処理され削除された状態を伝送する。ここで、”活動的”とはストリーマ６による処理の実行中であることを表し、”処理された”とはストリーマ６による処理が終了していることを表し、”削除された”とはストリーマ６によるＤＤＣ５からの削除が終了していることを表している。
図１４において、コールレコードが確認されるステップ１３０６は次のように拡大できる。この時点で、ステップ１４０１，１４０２で、交換機ファイルがＤＤＣ５から複写され、ファイルヘッダ及び最初のＡＰＤＵヘッダ５２がステップ１４０３，１４０５で確認される。どちらかがエラーとなる場合、ステップ１４１２でファイルエラー記録が作成される。両方とも受け入れ可能な場合、ステップ１４０７，１４０８でコールレコードはそれぞれ確認され、ひとつがエラーの場合、ステップ１４０９でコールレコード記録が作成される。各ＡＰＤＵ５１に対して確認処理が繰り返される。この確認により全てが正しいとされたか、あるいはエラーが記録されたかにかかわらず、オーディットトレールがステップ１４２３で更新され、上記のようにファイル処理はステップ１３０７に進む。
図１５において、次に、ファイル処理中に確認されたファイルは、カンパニーボックス８に行く準備が整う。この段階で、ファイル構造は、個別のコールレコード５３が関連する請求可能エンティティに従い記憶できるよう分類される。コールレコード５３は、次に、種々の請求可能エンティティ用にステップ１５０３で物理ファイルに書き込まれる。
５（iii）ＤＤＣファイル削除処理
一旦ＤＤＣ５からストリーマ６へのファイルのダウンロードが成功し、データが拡大され、適切なカンパニーボックス８に流されたら、データファイルは、ＤＤＣ上のＦＴＡＭファイルストアから削除されなければならない。ストリーマ６は、ファイルがカンパニーボックス８（あるいはカンパニーボックス８への連結が閉鎖されている場合カンパニーボックス８用のローカル記憶部）上に確保されて数時間後、ＦＴＡＭ削除要求を使いそのファイルを削除する。データの確保とファイルの削除間の正確な時間差は、各ＤＤＣ毎に設定できる。
５（iv）データアナライザ：処理
図１６において、図１３に示すステップ１３０６でのファイル処理におけるコールレコード確認工程は、ステップ１４１２でファイルエラー記録を生成し、ステップ１４０９でコールレコードエラー記録を生成する。データアナライザ７は、”ＤＡ処理”と”中断ファイル処理”の二つの処理を作動させ、これらの処理はＨＰ９０００のブートアップ中に開始される。
ＤＡ処理は、ストリーマ６により送られたデータがデータアナライザ７による処理に有効かどうか継続して監視する。このデータは、流すことができない個別のコールレコードを含んでいたか、又はエラーがファイルレベルにあった等にかかわらず、初期の段階では常に元の交換機ファイルとして存在する。
ステップ１６０２においてデータアナライザ７にが閉鎖のフラグがない限り、ＤＡ処理は、ステップ１６０３でまず処理すべき最初のファイルエラー記録を拾い出し、ステップ１６０４でファイル／ＡＰＤＵレベルでのエラーなのか、あるいはコールレコードレベルでのエラーなのかチェクする。
図１６，図１７，図２０において、もしエラーがコールレコードレベルであった場合、ＤＡ処理は、ステップ１７０２でファイルに関して次のコールレコードエラー記録を拾い出し、ステップ２０００で関連コールレコードをＡＲＴ ＩＭルールベースに送り補正する。もしエラーがファイルレベルであった場合、全交換機ファイルがストリーマ６に拒否されたことになる。この場合、完全なファイルがステップ１６０６でメモリにロードされ、ステップ１６０７でファイルヘッダとＡＰＤＵ５１がＡＲＴ ＩＭに送られ補正される。
データアナライザ７による分析では数種の結果が表出される。修正可能データはＡＲＴ ＩＭに送られ、補正され、続いて確認されカンパニーボックス８に流される。ルーティングエラーがある場合、万が一システム内のどこかでルーティング情報レコードに問題があり、例えば更新が必要な場合、データは中断状態に置かれる。一旦ルーティング情報が補正されれば、結局コールデータの確認が可能となる。ファイル全体が読み出し不可能な場合、二値フォーマットのまま二値ファイルダンプに送られる。もしデータ、例えばファイルがＡＲＴ ＩＭによって修正不可能と判断され、中断を正当化するルーティングにエラーが関わりがない場合、保存される。このデータは決して請求されることはないが、自主補正される長期的、あるいは重要な問題を判別するための分析で使うことができ、それによって将来請求可能項目の消失が避けられる。
図１６において、ステップ１６０５，１６０７でのチェックに使用したＡＲＴ ＩＭを使い、主要ＤＡ処理は次に、修繕不可能としてＡＲＴ ＩＭから返却されたファイルを分類する。ステップ１６０８でこれらの読み出しさえ不可能な場合、二値ファイルダンプに転送される。これらのファイルは、１６進法、８進法、あるいはＡＳＣＩＩフォーマットなため潜在的に読み出し可能であり、後で分析する時使うことができる。代わって、ファイルはデータアナライザで読み出しできるが、それでもＡＲＴ ＩＭにより”修正不可能”のレッテルを張られることがある。これらは、ステップ１６０９において、”ＳＵＭＰ”データベースにロードされ、そこで再び、決して請求データを提供することはないが、問いただされ分析される。
ファイルがＡＲＴ ＩＭに送られ修正可能であった場合、ＡＲＴ ＩＭは、ステップ１６１０，１６１１で確認のため継続して各コールレコードを返却する。次に、ＤＡ処理は、まずステップ１６１２でルーティングエラーをチェックすることにより、そしてコールレコードエラーがある場合、ステップ１６１５でコールレコードエラー記録を作成することによりこれらのコールレコードを確認する。ステップ１６０３から１６０５，そしてステップ１７０１から１７０３においてこれらを拾い出し、ＡＲＴ ＩＭを通して返却する。コールレコードが受け入れ可能な場合、ステップ１６１６から１６１８を介しカンパニーボックス８に流される。
図１８において、ステップ１６１２，１７０４，又は１９０７でコールレコードル〜ティングエラーが検知される場合（以下参照）、これらのコールレコードは分類化され中断される。すなわち、ステップ１８０２において、既存のルーティングエラーパターンに適合する限りエラーは分析され、次に、ステップ１８０３で、同じルーティングエラーパターンを含む既存のパターンファイルにこのコールレコードが加えられる。これらのパターンファイルは中断状態で保持され、一次ＢＴＰＳＴＮネットワーク管理データセンタに通知される。次に、別の処理、つまり中断ファイル処理、がこれらのファイルを処理する。
中断ファイル処理は、潜在的に補正可能なエラーファイルの分類を”主流”のデータ処理から取り出せるため、データアナライザ７の重要な面である。これらのファイルは、システム内のどこかでルーティングデータが更新されなかったため、エラーとして拾い出されたにすぎない可能性がある。これらは潜在的に請求可能である。中断ファイル処理により、一次ネットワーク管理データセンタはシステム内のルーティングデータを更新する機会を与えられ、それでも前にエラーが発見されたファイルを捕獲できる。更に、既存のパターンファイル、特定ルートパターン用の”ルートパターン中断ファイル”、にコールレコードを追加し、単に選択したルートパターン中断ファイルを作動させることにより、もう一度確認操作を実行するためファイルが選択できる。
図１９において、処理が閉鎖されていない限り、ステップ１９０２で、例えばステップ１９０３でネットワーク管理データセンタにより修正された最も早いルーティングパターンを見つけ出すことにより開始される。次に、ステップ１９０４でそのデータパターンを含む次の中断ファイルを拾い出し、ステップ１９０５，１９０６でコールレコードの確認を試みる。言うまでもなく、コールレコードにはレーティングエラーが一個以上ある場合がある。この場合、中断ファイル処理は図１８のステップ１８０１に戻り、ルーティングエラーパターンファイル内にルーティングエラーを入力し、それによりコールレコードを再中断する。しかし、他にルーティングエラーが一つもない場合、図１５のステップ１５０１に戻り、中断ファイル処理はカンパニーボックス８へのコールレコードのストリーミングを試みる。このようにしてステップ１９１０で中断ファイル内のコールレコード全部を走査し、またステップ１９１１でその特定ルートパターンに関して中断されたファイル全てを走査する。
図２２は、ストリーマシステム６、カンパニーボックス８、データアナライザ７間の処理関係を示す。ストリーマ６の主要処理領域は、”ファイル処理”と呼ばれる所である。ここではファイル上の全ての確認、固有の操作が行われる。データアナライザ領域では、エキスパートシステムへデータを入力する”ＩＤＡファイル処理”が存在する。この処理は、ルートパターン中断ファイルにデータを追加することにより、ルートパターン中断ファイル及び”中断ファイル処理”を発動する重要な役割を果たす。主要ＩＤＡファイル処理外で中断ファイル処理は動作するために起こる大きなデータ残高を避けるのもこの処理である。興味深いもう一つの領域は、”サンプローダ”からの出力を受け取る”サンプデータベース”である。サンプデータベース内のデータは補正不可能だが、続くデータが再ストリーミイングされるようＩＤＡファイル処理でのルールが潜在的に変更できるよう尋問を受け、分析することは可能である。
図２２で、各処理が円で示され、ブロック、データファイル、記録等のカンパニーボックス８は自由平行線間で示され、保存データはデータベースの従来の記号で表されている。
図２２で、処理、保存データ、相互作用は符号（ａ）から（ｙ）で示され、詳細は以下の通りとなる、また矢印は関連転送方向を表す：
a）処理、転送されるＮＮＩ及びファイル名リスト
b）作成された交換機ファイル記録、状態＝Ａ
c）アクセスされたＤＲＩＮＤＥＸファイル
d）複写されたＦＴＡＭ交換機ファイル
e）削除されたＦＴＡＭ交換機ファイル
f）読み出された交換機ファイル、状態＝Ｐ
g）交換機ファイルの削除が成功した場合のDに設定された状態（上記（e）において）
h）読み出された交換機ファイル記録、状態＝A
i）更新された交換機ファイル記録、状態はPに設定
j）ファイルがエラーなため作成されたファイルエラー記録
k）コールレコードがエラーなため作成されたコールレコードエラー記録
l）ファイルがエラーの場合のデータアナライザディレクトリィに複写されたファイル
m）読み出されたファイルエラー記録
n）読み出されたコールレコードエラー記録
o）検索された元の（二値）データファイル
p）このルートパターン用ルートパターン中断ファイルに追加されたデータ
q）ルートエラーパターン内への入力
r）ＡＲＴ／ＩＭ作成の最も近似のマッチング
s）このデータは修正不可能であることをＡＲＴ／ＩＭが判別。
データはＳＵＭＰ内に配置され、更に分析、あるいは削除される。
t）問題修正不可能をユーザが判別。ファイルはＳＵＭＰ内に配置され、更に分析、あるいは削除される。
u）ファイル構造の解読不可の場合の二値ファイルダンプに放り出されたファイル
v）作成されたストリーミングファイル
w）中断ファイル処理が、準備が整ったルートエラーパターン上の状態により開始。問題が存続している場合、カウントフィールドが更新され、状態を中断に設定。
x）選定ソルーションが問題解決不可の場合の最も近似のマッチング
５（v）エンティティライフヒストリー
図２３から図３０において、エンティティライフヒストリー図は、エンティティ内のレコードが入っている状態を示し、その状態からどのような動作によって他にどのような状態に到達可能かを示す。各図において、状態は符号２３００により簡単に判別され、各状態の定義は以下の通りとなる：
図２３：ファイルエラー記録
READY−データアナライザ７によるファイルのストリーミング準備が整っている。
SUSPENSE−ファイル内の全ファイル、又は最も少ない一個のコールレコードのどちらかが中断領域に送られている。
BIN−データアナライザ７によるファイル読み出し不可であったため、BIN領域に送られている。
SUM-COMPLETE−データアナライザ７がファイルを流し、中断領域内のどのファイルコールレコードに対しても再ストリーミング又は保存が成功している。
図２４：コールレコードエラー記録
READY−データアナライザ７によるコールレコードのストリーミング準備が整っている。
SUSRENSE−コールレコードが中断領域に送られている。
SUMP−コールレコードがＳＵＭＰ領域に送られている。
ARCHIVED−コールレコードがゴミ領域に送られている（すなわち、集積されている）
COMPLETE−データアナライザ７によるコールレコードのストリーミングが成功している。
VAL FAILURE-ART-IMとIEF確認手順に違いがある。
図２５：ルートエラーパターン
UNSELECTED-ART-IMにより作成されデータアナライザユーザによる分析待ち、あるいは分析後再ストリーミングされたが失敗。
PENDING−分析のためデータアナライザユーザにより選択されている。
READY−データアナライザユーザが分析を完了し、再ストリーミングの準備が整っている。
CLOSED−再ストリーミング、あるいは集積が成功
図２６：最も近似のマチング
UNSELECTED（NULL）−ART-IMにより生成。
SELECTED−分析のためデータアナライザユーザにより選択されている。
図２７：ＳＵＭＰファイル記録
SUMP−ファイルのSUMP PROCESS準備が整っている。
PROCESSING−データアナライザユーザによるファイル検視準備が整っている。
ARCHIVED−ファイルが集積されている。
図２８：ファイルルートエラーリンク
SUSPENDED−ファイルが中断領域にある。
COMPLETE−中断領域からのファイルの再ストリーミングが成功。
図２９：交換機ファイル記録
A（CRIVE）−交換機ファイルがストリーマによって処理中。
P（ROCESSED）−交換機ファイルがストリーマによって処理されている。
D（ELECTED）−交換機ファイルがストリーマによって削除されている。
図３０：地域データ収集所
（全状態が、ＳＱＬ*フォームを介しストリーマ６ユーザによって変更される）
P（REBIS）−ＤＤＣプレビス。
L（IVE）−ＤＤＣ活動中。
C（EASED）−ＤＤＣ終了。
図６において、ストリーマ６／データアナライザ７のソフトウェアアーキテクチャにはＩＥＦ外部活動ブロック（ＥＡＢ）６２が含まれている。ＥＡＢ６２は、ＩＥＦ内での実施が不適切、あるいは不可能な場合使用される。例えば、ＥＡＢ６２によって実行される機能は以下の通りである：
○”中断へのコールレコードを加える”
このモジュールは、中断ファイルに送られる交換機ファイル用にコールレコードを含む連結リスト内で新しい入力コールレコードを作成する。
○”集積にコールレコードを加える”
修正されたが再ストリーミングは不可能な交換機ファイル用コールレコードを含む連結リスト内で、アーカイブディレクトリィに新しい入力コールレコードを作成する。
○”ネットワークオペレータレコードを加える”
新規のネットワークオペレータかどうかチェックし、そうであれば”ＮＥＴwork operator structure”の連結リスト内に新しく入力する。すでに使われたネットワークオペレータ名であれば、そのネットワークオペレータ用のコールレコード連結リスト内に連結リスト入力を加える。コールレコードが修正された場合、”ＮＥＴworkoperatorrecord”ＩＤとストリーミングされたコールレコードシーケンス番号により”call record error log”を更新する。
○”ＩＤＡルールへのコースレコード”
単一コールレコードをデータアナライザＡＲＴ ＩＭルールベースに渡す。コールレコードがＡＰＤＵシーケンス番号によって識別され、ＩＥＦによってコールレコードシーケンス番号が入って来る。次に、メモリにロードされたデータ構造が、コールレコード、所有のＡＰＤＵ、交換機ファイルヘッダデータ用に捜査される。このデータは、その後ルールベースに供給され確認される。見つけ出されたどのようなエラーでも、それぞれコールレコード記録行入力を生成する。また、コースレコードエラー記録レコード状態がルールベースによって更新される。
○”コミット”
現在のデータベースを全て変更する。
○”ＤＤＣ処理を作成”
特定ＤＤＣをポーリングすることを司るＤＤＣ処理を作成する。子処理にＦＩＦＯ（ファイルイン／ファイルアウト）を作成／聞き、このＦＩＦＯ内にＤＣ ＮＮＩ値を書き込む。
○”ＤＤＣからファイルを削除”
ＦＴＡＭプロトコルを使いＤＤＣ上のディスクからファイルを削除する。
○”データアナライザファイルを削除”
ストリーマ／データアナライザディレクトリィからファイルを削除する。
○”中断ファイルを削除”
中断ファイルディレクトリィからファイルを削除する。
○”BINへのファイル”
ＡＲＴ／ＩＭルールベース内へ読み込みできないファイルを二値ファイルダンプへ渡す。
○”データアナライザルールへのファイル”
全ファイルをデータアナライザＡＲＴ ＩＭルールベースへ渡し、ルールベースを初期化する。ルールベースの初期化には、旧データのクリア、ディフォルト及びルーティング基準データの選択、とのデータによるデータベースのポピュレーティング等が含まれる。次に、データアナライザ二値ファイルが、メモリのデータ構造内にロードされる。このデータは、ルールベースに供給され確認される。見つけ出されたエラーはどれでも適切なルール記録行入力を生成する。コールレコードエラー記録は、ルートエラーパターン、最も近似のマッチング、ライフルートエラーリンクレコード等と共に、適切と思われる箇所においてルールベースにより作成される。一旦確認された後は、ルールベースは確認状態をＩＥＦに戻し、後の検索用に内部データを保持する。
○”ＳＵＭＰへのファイル”
ＡＲＴ ＩＭルールベースによって修正できないファイルをＳＵＭＰに渡す。
○”ＦＴＡＭ ＨＬＣＯＰＹ”
ＦＴＡＭプロトコルを利用し、ストリーマ６へＤＤＣユーザ名を使いＤＤＣＦＴＡＭアドレスからのＤＤＣファイル名、ＤＤＣパスワード、ＤＤＣ口座を複写する。このルーティンは、ＩＥＦから直接に呼び出され、従ってＩＥＦスタイル状態は返却しない。
○”ＤＤＣ処理パラメータを得る”
”ＤＤＣ ＰＲＯＣＥＥ ＦＩＦＯ＜ＰＩＤ＞”と名付けられるＦＩＦＯをストリーマ／ＴＭＰディレクトリィに作成、又は開く。”create file process”ルーティンによりＦＩＦＯ内に挿入されたデータであるＦＩＦＯからの上記変数値を読む出す。
○”交換機ファイルを得る”
ＦＴＡＭプロトコルを利用し、ＤＤＣ上のディスクからストリーマ６上のディスクは直接にファイルを複写する。次に、ファイルがストリーマ６上のメモリ内に読み込まれ、元のレコードバックアップディレルトリィ内で新たに名を付けられ、そこからアーカイブされる。このモジュールは、最初の請求レコード、最初のＡＰＤＵ、ヘッダ、トレーラＡＰＤＵに対して初期ポインタを設置するため、”map data structure to file”を呼び出す。
○”無効データアナライザＡＰＤＵ数を得る”
ストリーマ確認処理で失敗したコールレコードの無効ＡＰＤＵ再処理数を返却する。
○”データアナライザファイルをマッピングする”
後続処理用にメモリ内にファイルを読み込む。
○”処理活動中”
特定のPＩＤが活動中かどうか判別し、それに応じてフラグを返却する。
○”交換機ファイルヘッダを読み出す”
ヘッダＹ及びトレーラＡＰＤＵへのポインタを使い、ヘッダからのフィールド全て、更にトレーラからのＡＰＤＵタイプを構造内に返却する。
○”データアナライザ交換機ファイルヘッダを読み出す”
ヘッダ及びトレーラＡＰＤＵへのポインタを使い、データアナライザに送られているファイル用に、ヘッダからのフィールド全て、トレーラからのＡＰＤＵタイプを構造内に返却する。
○”最初のＤＲＩＮＤＥＸレコードを読み出す”
ＦＴＡＭプロトコルを利用し、ＤＤＣから一時保存部にＤＲＩＮＤＥＸファイルを複写し、ファイルを開き、発呼者に最初のレコードを戻す。
○”次のＡＰＤＵを読み出す”
現在のＡＰＤＵポインタ指示のＡＰＤＵ構造を返却し、次のＡＰＤＵに現在のＡＰＤＵポインタを設置する。また、返却されたＡＰＤＵ内の最初の請求レコードに現在の請求レコードポインタを設置し、複写し、現在のＡＰＤＵ配列内にデータがバイト反転される。
○”次のＤＲＩＮＤＥＸレコードを読み出す”
ＤＤＣ上のＤＲＩＮＤＥＸファイルから次のレコードを読み出す。
○”次のデータアナライザレコードを読み出す”
ＡＲＴ ＩＭルールベースから次の請求レコード出力を返却する。成功すれば、処理レコードがまず表れ、続いて中断ファイルに送るレコードが表れる。
○”次の中断レコードを読み出す”
中断ファイルから次の請求レコード出力を返却する。
○”次のレコードを読み出す”
現在の請求レコードポインタにより指示されている請求レコードを返却し、もしこれが現在のＡＰＤＵ内で最後のレコードでない場合、ポインタを次の請求レコードに設置する（これは、ＡＰＤＵ長と請求レコードの最低長を使い決定される）。
○”ネットワークオペレータファイル名の変更”
カンパニーボックス８による処理準備が整った操作ディレクトリィ内の一時ディレクトリィに書き込まれたどのネットワークオペレータファイル名も変更する。
○”スリープ”
所定秒間スリープする。
○”ファイルを流す”
データアナライザ処理の準備が整ったデータアナラアイザにメモリ内のファイルをダンプする。
○”ストリーミングファイルネットワークオペレータ”
最初のネットワークオペレータへのポインタを使い、該オペレータの確認され拡大されたレコード全てにアクセスする。次に、連結リストからのレコードをnfs一次ディレクトリィに書き込む。成功した場合、ファイルはnfsディレクトリィ内でその名が変更される。NFS一次ディレクトリィ上にファイルが再び開けられない場合、そのファイルはローカル一次ディレクトリィ上に開かれ、これが成功したら、ローカルディレクトリィ内で名の変更が行われる。
○”ファイルRRBを流す”
メモリ内のファイルを元のレコードバックアップディレクトリィへダンプする。
○”コンソールを書き込む”
ネットワーク管理ワークステーションにメッセージを書き込む。
○”中断ファイルへ書き込む”
交換機ファイル用中断コールレコードの連結リストからのレコードを中断ディレクトリィに書き込む。
○”アーカイブファイルに書き込む”
交換機ファイル用アーカイブコールレコードの連結リストからのレコードをアーカイブディレクトリィに書き込む。
６．図３１から図３５：エキスパートシステム：ＡＲＴ ＩＭ
６（i）概要
エキスパートシステムは、インフェアンス社提供のＡＲＴ ＩＭ知識ベースエキスパートスシテムツールキットのファシリティを利用する。これは、知識／ルールベースプログラミングシステムで、知識階層内での柔軟な意思決定モデル、よって現実世界のモデル作成が可能になり、更に問題解決のより発見的方法が提供される。ツールキットには、ＡＲＴ ＩＭ言語、統合エディタ、インタラクティブ開発環境、エントユーザインタフェース開発用ツール、開発されたアプリケーションの走作時間バージョンを展開する方法、外部データを賢明に解釈するファシリティ等が含まれる。
データアナライザ７において、エキスパートシステムは、ルールベースとケースベースの二つのサブシステムに分割される。一般に、ケースベースはルーティングベースエラーの処理に、ルールベースはディフォールティング算出可能エラーの処理に使われる。両方ともＡＲＴ ＩＭの機能性を利用する。
ルールベースは、ルール、機能及び方法を含むＡＲＴ ＩＭ手順言語を使う。各エラーは、図式内で定義され、これら図式例がデータ構造上で使われる。データ内オブジェクト階層内の全ての図式は、ＡＲＴ ＩＭの”DEF-EXTERNAL FUN”ファシリティを使いＩＥＦ／ＡＲＴ ＩＭインタフェースを介しポピュレーティング（駐在）される。
ＡＲＴ ＩＭが使用するプログラムフロー制御機構は、通常のプログラミング言語内で見られる逐次ステートメント毎のフローとは大変異なっている。図３１，３２において、エキスパートシステムは、その全ての内部データ、すなわち図式と事実、をパターンネット３１００内に保持する。図３１に示すように、これはそれぞれが内部データを表す（図式又は事実）複数のパターン化された円によって表されている。このデータは、以下の方法により設定できる：
○ＡＲＴ ＩＭ試験ケースファイルをロードする（通常は開発／ユニット試験の状況で行われることが多い）
○外部ソースからのポピュレーティングにうよる（例えばORACLE又はＩＥＦ：通常は生産／システム試験環境で行われることが多い）
○ＡＲＴ ＩＭから生成することによる（極めて柔軟な”作業記憶部”、例えば確認試験失敗後のエラー図式の生成、として使われる）設定後、データはルール内所定の条件と直接比較される。ルールは、より伝統的なプログラミング言語の”IF<conditions>THEN<action>”に似ている。ルール条件がデータ例と正確に適合している場合、関連事項３１０５内で作動生成される。全てのデータ例が全ルールに対してチェックされる。性能においては、パターンネット及びルール条件が、ＡＲＴ ＩＭ走作時間システム内の効率の良いパターンマッチングアルゴリズムによって管理される。
サイクルの評価部の最後に、全てのルール作動が事項スタック上に順番に配置される。このスタック上の最初のルール作動が発動される。作動表出の順番は、重要点、すなわちルールの優先順位、が開発者によって設定されない場合、バラバラとなりディフォルトとなる。
図３２において、事項３１０５の最上位ルール作動の発動後、ルールの作動により実際にパターンネット内のデータが変更されており、そして次の評価サイクルに続き事項スタック上に表出するデータを変更する。
初期の発動を引き起こすデータ例（円で囲んだ例３１１０）は再評価されず、よってデータ例内のデータが変化し、新しいパターンがルール条件に適合する場合、ルール作動が生成されるが、連続したルーピングが避けられる。
ＡＲＴ ＩＭ走作は以下の時終了する：
○適合する条件、パターンが一つも見つからない。
○全ての適合条件、パターンが既にルールを発動している。
上記を要約すると次の通りとなる：
１）ルール作動は、データパターンをルール条件に適合させることにより生成される。
２）ルールは、優先順位を設定できるが、ディフォルトによりどのような順番でも発動できる。
３）全てのデータが並列に評価される。
４）ルールの発動ごとに再評価が実行される。
５）適合データ例の数により、走作中同じルールが何回でも発動できる。
６）ルール条件は、パターンネット内の変化に敏感である。
７）適合するルール条件、あるいはパターンネットデータが一つも見つからない場合、あるいは全ての適合作動が既に発動されている場合、ＡＲＴ ＩＭは停止する。
図３３において、図示のようにルールベースシステムは、オブジェクト階層を基としている。各オブジェクト３３００は、ＡＲＴ法において定義され、オブジェクト３３００間の接続線は、上記オブジェクトからの遺産を表す。
交換機ファイル、ＡＰＤＵ、コールレコードはその構造に各データ項目ごとにスロットを含む。各スロットは、適切なディフォルトオジェクト内に対応するスロットを有し、結果としてディフォルト値、又は算出可能値を有するのか、あるいは修正不可フィールドなのか宣言する。ルールベースは、ディフォルトシステムを使い、もし可能であればエラー訂正がどの形態でなけれなならないかチェックする。
上記にはデータ図式も含まれている。エラー図式に関しては、可能性のあるどのようなデータアナライザエラーでもその詳細が適切な図式内で記述される。各エラー記述及びその例には、以下のそれぞれ用にスロットが含まれている。
エラー関連のオブジェクト、すなわち交換機ファイル。
エラー記述。
影響されるスロット。
エラー例用所定データオブジェクト。
修正値名。
エラー源。
結果として生成される修正値。
発動順番におけるルール位置。
修正前のスロット値。
６（ii）ルールベース一般ルール
ルールベース操作フローは、多数の一般ルールにより制御され、これらは以下の機能を果たす：
○エラー発動毎に、そのエラー修正方法が起動され、修正値を生成し、その第１番目が割り当てられる。
○影響を受けるスロットがたったの一個である修正可能エラーに対して、影響を受けるスロットを生成された修正値で更新し、変更時間スタンプがエラー例と共に記憶される。
○修正記述がエラータイプは中断可能と宣言する該エラーに対して、影響を受けるデータ項目が中断ファイルに移動され、その移動時間スタンプがエラー例と共に記憶される。
○修正記述がエラータイプはＳＵＭＰ可能と宣言する該エラーに対して、影響を受けるデータ項目がＳＵＭＰに移動され、そのファイルのサンピング時間スタンプがエラー例と共に記憶される。
○ＡＰＤＵ、又は交換機ファイル上の各修正に対して、レコードがファイル構造ルール記録上に作成される。
○適切なエラー情報を有するコールレコード上の各修正に対して、ORACLEレコードがコールレコードエラー記録上に作成される。
修正可能エラー
１）ディフォルト値は以下のフィールドに割当可能である。
ＡＰＤＵタイプ及びトレーラ
請求されたコールインジケータ
着呼パーティクリア
ＰＢＸ添数
レコード使用
レコードタイプ
ＤＤＣ時間スタンプ
ヘッダＡＰＤＵタイプ
データ転送種別
フォマットバージョン番号
ノード時間スタンプ
部分ファイルインジケータ
表サイズ
トレーラＡＰＤＵタイプ
着呼パーティクリア
アプリケーショングループ
２）以下のエラーが算出可能である：
ＡＰＤＵ長;ＡＰＤＵの長さ。
ＡＰＤＵ数;ＡＰＤＵ列の長さ。
エンドＡＰＤＵシーケンス番号;開始シーケンス番号＋有効ＡＰＤＵ数。
開始ＡＰＤＵシーケンス番号;交換機ファイル内の最初のＡＰＤＵのシーケス番号より得られる。
ダイアルされた数字;ダイアルされた数字列の長さ。
上記に関し、ＡＰＤＵのチェックサミングがエラーとなる等、エラーとなる例外がある。このタイプのエラーは、ルールベース内で直ちにＳＵＭＰされる。ＡＰＤＵ列に関するいくつかのエラーは、結果として”１”から再度列化される完全な範囲の列数を生成し、関連交換機ファイルが更新される。ダイアルされた数字列の最後がAとF間の文字でも良い。ここでの修正値は、ダイアルされた数字列−最後の数字である。
修正不可能エラー
修正不可能エラーが出た場合、前記にようにエラー中のデータ項目、すなわちコールレコード、がＳＵＭＰに渡され、該当するエラー記録が更新される。修正できない領域、従って修正不可エラーを生成する領域は以下の通りである：
アドレス捕獲時間スタンプ
アドレス完了時間スタンプ
アドレス、あるいは応答時間スタンプのどちらか一方
発呼パーティクリア時間スタンプ
発呼ラインディレクトリィ番号
捕獲時間スタンプ
ダイアルされた数字列（最後がAとF間の文字の場合を除く）
６（iii）ケースベースシステム
ルーティング基準ケースベースは、ルーティングパターン（ＴＵＮ、ルートグループ、ルート番号、ＮＮＴ、ノードポイントコード等）に、例えば請求可能ネットワークオペレータ名、活動中、終了ノード時間スタンプなど他の基準データを加えたケースベースである。ケースベース基準データはルーティング基準図式からポピュウレーティングされ、この図式は、データモデルのストリーマ基準データ従属領域３６００内のデータからポピュレーティングされる（図３６参照）。
図３４において、ケースベースシステムのオブジェクト階層は、図３３に示すルールベースシステムの階層に”提案されたソルーション”、”可能性のあるソルーション”、”ルーティング基準”の三種のオブジェクト種別３４００を加えたものと同様である。”提案されたソルーション”及び”可能性のあるソルーション”は、ルーティング基準エラーの判別に続いてのみ作成され、主に他のデータ、すなわち最も適合性が近いエラー中の着呼レコードとルーティング基準図式、へのポインタを含んでいる。”ルーティング基準”図式は、ORACLEデータベース上のルーティング基準データから作成される。
ルーティングケースベース、初期化に関しては、ルーティングケースベースは、ルーティング記述図式からの走作開始にポピュレーティングされる。ケースは、各ルーティング記述図式につき一個作成される。ルーティングケースベースは、以下のパラメータにより設定される：
○最大３個のマッチング
○可能性ゼロの閾値以下のマッチングは、ほとんど可能性のないマッチングを排除するためどのようなものでも無視される。
○パターンマッチングではケースベース上の次のスロットのみ使われる：
ＴＵＮ（例えば、電話ユニット番号）、ルートグループ、ノードポイントコード、ルート番号、ＮＮＩ、方向
○次の事項がパターンマッチングでは無視される：
活動中のノード時間スタンプ
終了したノード時間スタンプ
テレコムネットワークオペレータの役割と名前
○方向は、マッチングでは多少異なったものとして扱われる。これは最も重要性の低いスロットで、全重量の固定重量上限５%が与えられる。他のスロット重量は、全重量の残り９５％を均等に割って与えられる。
パターンマッチングは、初期化パラメータの設定等、他のケースベース機能と共に、ケースベースにメッセージを送ることによりアーカイブされる。パターンマッチングは、二つのステップで行われる、すなわち見つけ出されたマッチング数を返却するケースベースに着呼コールレコード図式を送るステップと、返却されたケースに関連したルーティング基準図式のキーと共に各返却ケースのマッチング近似性を決定する検索・マッチング・スコアメッセージを送るステップである。
ケースベースは、コールパターンに関連したエラーコード確認に使われ、ノードポイントコード、見出せないルートグループ、無効ルート番号、あるいは無効方向の場合以下のように使われる：
○各着呼レコードとルーティング基準ケースベース上のケース間で正確なマッチングを見つけ出す。正確なマッチングがある場合、コールレコードは有効なルーティングパターンを有し、上記エラーに関してこれ以上の確認は必要でない。
○正確なマッチングがない場合、上記のように修正方法を適用するルールベース一般ルールを発動するエラー図式を生成する。
○所定の修正方法により次のものを含む提案されたソルーション図式一個作成する（図３４参照）：
i）最大三種の可能性のあるソルーション図式で、それぞれが関連ルーティング基準図式へのポインタを有す。また、可能性のあるソルーションは、マッチング位置（すなわち、次の近いもの等）とマッチング近似性測定値％を含む。
ii）エラー中の着呼レコードへのポインタ。
修正方法はエラー図式例の生成により発動される通常の修正方法とはことなる。この方法が、機能（提案されたソルーション図式例とルーティング基準図式へのキーを含む事実を強調するルーティングミスマッチ）と別のルール（ルーティングミスマッチにより作成された事実の生成上で発動し、見つけ出された各ケースベースマッチングに対する一つの可能性のあるソルーション図式を生成する最も近似のマッチング生成）から成っているからである。
ノード時間スタンプ確認に関しては、ケースベースは以下のように使われる：
○各着呼レコード図式とルーティング基準図式間で正確なマッチングを見つけ出す。正確はマッチングがある場合、次に、ルールが、適合した着呼レコード図式とルーティング基準図式上での時間スタンプの不一致（すなわち、捕獲時間スタンプはノード活動中と終了時間の間に位置する）をチェックする。不一致が存在しない場合、このエラーにかんしてはこれ以上の処理は必要ではない。
○時間スタンプ不一致がある場合、上記のように修正方法を適用するルールベース一般ルールを発動するエラー図式が生成される。
○所定の修正方法は、提案されたソルーション図式を一個作成し、ここには以下が含まれる（図３４参照）：
−それぞれが関連ルーティング基準図式へのポインタを含む可能性のあるソルーション。また、可能性のあるソルーションには、マッチング位置（すなわち、最も近いもの、次に、近いもの等）とマッチング近似性測定値％が含まれる。
−エラー中の着呼レコードへのポインタ。
ここでも修正方法は、エラー図式例の生成により発動される通常の修正方法とは異なる。この方法が、機能（提案されたソルーション図式例とルーティング基準図式へのキーを含む事実を強調するノード・時間スタンプの不一致）と別のルール（ルーティングミスマッチにより作成された事実の生成上に発動され、可能性のあるソルーション図式の一例を生成する（generate node time discrepancies）から成るからである。
６（iv）ＡＲＴ ＩＭとORACLEインタフェース
図３５において、ＡＲＴ ＩＭルールベースの”平行”確認特徴を十分に活用するため、ＡＲＴ ＩＭからORACLEデータベースへの直接アクセスが要求される。４種の主要インタフェースが存在する：
○ルーティング基準データ３５００のポピュレーション
○ディフォルトデータ３５０５のポピュレーション
○オーディットトレール形成のための修正データの出力
○中断データ取扱３５１５の先駆けとしてのルーティングエラーパターンの出力ルーティング基準データのポピュレーションに関しては、このインタフェース３５００は、ORACLE表内に物理的に保持される内部RT−IM図式とルーティング基準モデル内のデータからのケースベースのリフレッシュを含む：
○リフレッシュは、ＡＲＴ ＩＭ走作の初期化段階中に発動される。
○既存の内部ＡＲＴ ＩＭルーティング基準図式は、そのケースベース入力と共にクリアされる。
○データは、二つの外部アクションブロック（file to IDA rules及びcall record to IDA rules）の一部として使われるＰＲＯＣプログラム（EBA INITIALISE IDA RUILEBASE）からのORACLE表から選ばれる。
○内部ＡＲＴ ＩＭ図式は、ＰＲＯＣプログラムによりポピュレーティングされる。
○ルーティング基準ケースベースは、ケースベース初期化処理の一部としての機能（ＩＮＣＡ ＩＤＡ initialise ＣＡＳＥbase）により内部ルーティング基準図式からポピュレーティングされる。
ディフォルトデータのポピュレーションに関しては：
○リフレッシュは、ＡＲＴ ＩＭ走作の初期化段階中に発動される。
○既存の内部ＡＲＴ ＩＭディフォルト図式（df-call-record, df-APDU等）は、そのケースベース入力と共にクリアされる。
○データは、二つの外部アクションブロック（file to IDA rules及びcall record to IDA rules）の一部として使われるＰＲＯＣプログラムからのORACLE表から選ばれる。
○内部ＡＲＴ ＩＭ図式は、ＰＲＯＣプログラムによりポピュレーティングされる。
エラー及び修正データの作成に関しては、修正可能なデータと関連のある入って来るデータの確認中にエラーが検知される場合、ルールベースにより加えられる修正のオーディットトレールは維持する必要がある：
○エラー中の各ファイル構造に対して、FILE ERROR LOG表内に行入力を作成する。これは、ストリーマ処理によって可能である。
○エラー中の各コールレコードに対して、CALL RECORD ERROR LOG内に行入力を作成する。これは、ストリーマ処理、あるいはＡＲＴ ＩＭによって可能である。
○ファイル構造レベルで検知された各エラー及び修正に対して、ORACLEデータベース上のFILE STRUCTURE RULE LOG内に行入力が作成される。これは、全てのファイルレベルエラー検知及び修正が完了した時発動される一般ルールを使い、ルールベースによって行うのが最も効果的である。このルールは、エラーが検知され、修正が加えられる毎に発動し、発動された時、必要な挿入を行うユーザ定義の手順呼び出し、sql exec limitedを発動させる。
○ファイル構造レベルで検知された各エラーおよび修正に対して、ORACLEデータベース上のCALL RECORD RULE LOG内に行入力を作成する。これは、全てのコールレコードレベルのエラー検知及び修正が完了した時発動される一般ルールを使い、ルールベースによって行うのが最も効果的である。ここでも、エラーが検知され、修正される毎にルールが発動され、発動されたら、必要な挿入を行うユーザ定義の手順呼び出し、sql exec immed,を発動させる。
○ＡＲＴ ＩＭルールは、内部図式上のスロットから挿入値をポピュレーティングする。
ルーティングエラーパターン及び最も近いマッチングデータの作成に関しては、中断されているデータと関連する入って来るデータの確認中にエラーが発見された場合、着呼レコードエラーパターンの記録（ＴＵＮ、ＮＮＩ、ルートグループ番号、ルートグループ、方向を基にして）が、３個の最も近いマッチング（エラー中の着呼レコードに対してルーティング基準モデル上の最も近いパターンを基にして）と共に、後の中断ファイル処理用にORACLEデータベース上に記憶される必要がある。全ての確認／修正完了に続きパターンが記憶される。更に詳細すれば、以下の通りである：
○中断ファイルエラー生成毎に（同じコールレコード上に修正不可能なエラーは一つも生成されないと仮定しー修正不可能コールレコードは、move to ＳＵＭＰ一般ルールを使い排除される）、一般ルール（move to suspense file area）が発動される。このルールは、データベースからエラー中のパターンを選び、もしエラー中のパターンが存在する場合は、以下を実行する：
i）関連するパターン交換機ファイルと外部キーとでFILE ROUTE ERROR LINK内のどの入力もテストする。
ii）入力が存在する場合、これ以上の動作は必要でない。
iii）入力が存在しない場合、FILE ROUTE ERROR LINK内に行入力を挿入する。
エラー中のパターンが存在しない場合、以下を実行する：
iv）着呼レコードから、エラーパターンによりポピュレーティングされるROUTE ERROR PATTERN表内に行入力を挿入する。
v）FILE ROUTE ERROR LINK内に行入力を挿入する。
vi）前のケースベース処理からエラー中のルートパターンに最も近いと発見されたルーティング基準パターンによりポピュレーティングされたCLOSEST MATCHES表内に最大３個の行入力を挿入する。
○ユーザ定義手順は、ORACLEへＳＱＬコマンドを渡すため使われる。
○ＡＲＴ ＩＭルールは、内部図式上のスロットから挿入値をポピュレーティングする。
７．図２０，図２１，図３７から図４３：データアナライザ７によるエキスパートシステムの利用
以下に記載のフロー図において、本明細書における初期のフロー図とは多少異なったフォーマットが適用されている。すなわち、機能呼び出しが二重鉛直線のボックスにより表され、単純なステートメントは一本の鉛直線のボックスによって表され、YES／NOの決定は簡単なダイアモンド形で表される。
データアナライザ７によるＡＲＴ ＩＭエキスパートシステムの利用は、フロー図で表すことができる。図１６，図１７，図２０において、ステップ１６０５で一旦コールレコードレベルで失敗が決定されると、ステップ１７０２で次のコールレコード記録がファイルから選択されており、ステップ２０００で関連するコールレコードがエキスパートシステムに送られる。エキスパートシステムは、ステップ２００５，２０１０で正しいＡＰＤＵを発見し、次に、ステップ２０１５，２０２０でエラーとなったコールレコードを発見する。
次に、エキスパートシステムは、コールレコードが正確に項目分類されているかチェックし（ステップ２０２５）、この例ではシステムＸ項目分類化に従っており、もしそうでない場合、ステップ２０３０でＩＥＦ状態を”ＳＵＭＰ”に設定することによりコールレコードをＳＵＭＰに渡し、一方ステップ２０３５でコールレコードエラー記録を更新する。コールレコードが正しく項目分類される場合、ステップ２０４０，２０４５，２０５０においてエキスパートシステムに”つなぎ”、ステップ１７０４以降でその結果をデータアナライザ７により評価する。
図１６，図２１において、ステップ１６０４でファイル、あるいはＡＰＤＵレベルで失敗があったと決定された場合、ステップ２１００でファイルがメモリにロードされ、ファイルヘッダとＡＰＤＵがエキスパートシステムに送られる。ステップ２１０５でエキスパートシステムデータベースが呼び出され、ステップ２１１０で前の削除された走作からＡＰＤＵ図式を呼び出す。ステップ２１１５での最初の試験走作は、ルーティング基準モデルのエキスパートシステムバージョンのリフレッシュが目的で、これにより直ちにエラーを訂正することができる。そうでない場合、万が一例えば、関係するエラー用のディフォルトデータが前に見失っていた場合のため、ステップ２１２０でエキスパートシステムのディフォルトデータがリフレッシュされる。このどちらかが成功すると、図１６に示すように、データアナライザ処理が再び開始され、エキスパートシステムのリフレッシュステップからの結果、ステップ１６１１でファイルはそのコールレコードの確認に進むことができる。どちらも成功しない場合、コールレコードは個別に確認されなければならない。これは以下のように行われる。
図３７において、図２１の機能ボックス２１２５が、すなわち”マップヘッダとＡＰＤＵ図式”、ルーティング基準モデルとディフォルトデータのリフレッシュ後うまく処理できなかったエラーファイルからのコールレコードに関して、エキスパートシステム、ＡＲＴ ＩＭのローディング（ステップ３７００，３７２５，３７３５）と実行（ステップ３７３０，３７４０，３７４５，３７５０）を含むよう拡大する。このローディング処理には、例えばステップ３７１５でストリーマ６からのデータ等、ＡＲＴデータベース（”外部キー”）上では存在しないデータを得、エキスパートシステムのファイルアクセスを可能にする。各コールレコードの分析後、ＡＲＴは状態供給を行う（ステップ３７５５）、これによりコールレコードが修正されたか、中断すべきか、ＳＵＭＰすべきかが分かる。データアナライザ処理（ＩＥＦ）は、ステップ３７６０でＳＵＭＰすべきコールレコード数のクンティングを行い、ステップ３７６５でＡＲＴ ＩＭ内にフラッグを設置する。これによりステップ３７７０でＡＲＴ ＩＭによるクリーンアップが発動され、各コールレコードと関連図式のクリアリングを行いその確立が避けれれる。
図３８から図４３において、エキスパートシステムのファイルルールのアプリケーションもフロー図で表すことができ、以下の例が示されている、この場合のフロー図は自明である：
i）図３８;ＡＲＴファイルルール（交換機ファイルヘッダ）
これは、次のものに適用できる−
トレーラＡＰＤＵ
フォーマットバージョン番号
ファイルタイプ
ノード時間スタンプ
ＤＤＣ／NMP時間スタンプ（NMPはネットワーク調停プロセッサを表す）
データ転送種別
ノード群ＩＤ
ストリーマＮＮＩ
アプリケーショングループ
部分ファイルインジケータ
ファイルバイトサイズ
表サイズ
選択されたＡＰＤＵタイプ
ii）図３９；ＡＰＤＵの最初のシーケンス番号ルール
iii）図４０；ＡＰＤＵの最後のシーケンス番号ルール
iv）図４１；ＡＰＤＵのシーケンス番号カウントルール
v）図４２；ＡＲＴＡＰＤＵルール
これは、以下に適用できる−
再伝送インジケータ
連結フィールド
vi）図４３；ＡＲＴコールレコードルール
これは、以下に適用できる−
レコードの使用
請求されたコールのインジケータ
クリアリングの原因
ＰＢＸ添数
ＣＬＩ群ＩＤ
ネットワーク回路
ネットワーク帯
回路ＩＤ
回路番号請求帯
呼サンプリング方法
サンプリングモード
カウントリセットインジケータ
Ｎの値（Ｎは、例えばコールレコードの試験中に数えられた数に関する）
着呼パーティクリア時間スタンプ
８．図３６，図４４：企業システム
図４において、ストリーマ６から企業システム８への出力は、請求可能エンティティに従い分類され、前記のようにＡＲＴ ＩＭエキスパートシステムを内蔵したデータアナライザを使い確認されたコールレコードより構成される。
企業システム８の主要な役割は、クライアントに対して請求できるよう、コールレコードの価格付けをし、価格付けされたレコードを出力することである。一方、前記のように確認の役割も有し、よって請求可能エンティティ及び請求可能エンティティと第１ネットワーク１間の関係に関連したデータが重要視される。従って、企業システム８は、以下”ｃＩＤＡ”として示される企業システムデータアナライザを内蔵するか、あるいはそれにアクセスするようになっている。
ｃＩＤＡアプリケーションは、前記ストリーマ６からのデータを確認するデータアナライザ７と並んで配置することもできる。図４で、エラーコールレコードの修正ステップ４３０、修正されたコールレコードのバルキング４４０、修正不可能レコードの調査４５０は全てｃＩＤＡアプリケーションにより実行できる。
大多数のエラーは、企業システム８が拾い上げたエラーのうち９０％程度になり、以上状態の解読に関係するものであり、主に”時間ライン”（１２３）、”緊急サービス”（９９９）と関係したものであるのは興味深い。残りエラーの殆どは、基準データの不一致が原因である。従って、企業システム８で使うデータアナライザの構築において、二つの主要な面が存在する、すなわち、大多数のエラー、解読異常となるレコードに対処することと、訂正後ファィルを企業システム８に返却可能な基盤を提供することである。
処理概要
適切な方法は、以下の通りである。エラー、そして警告ファイルが企業システム８からｃＩＤＡに送られ、そこで所定のディレクトリィにロードされる（各オペレータにつき一個）。一つのファイルでゼロ、あるいは多くのレコードを保持できる。ｃＩＤＡが、手動オーバーライドの能力で同時に作動する全オペレータ用に平行処理ファシリティを提供できることが望ましい。ｃＩＤＡ内外へのファイル列を制御するため、記録保持される。
一旦エラーファイルが処理選択されると、ｃＩＤＡはファイルが空きでないと仮定することにより各レコードを選択し、そのエラーを、修正可能、不可能のどちらかに分類する。修正不可能レコードは、表に書き込まれ、報告され、後でアーカイブの際データベースから取り除くことができる。修正可能と見なされるレコードは、ルールの適用により自動的に修正できるか、あるいは修正前手動調整を要する場合がある。
各レコードは、エラータイプにかかわらず、ORACLEデータベース表に挿入され、全ての詳細がカンパニーボックス８から渡され、”状態”を表すためフラッグが設置される。この状態は、上記に従い、以下から選択できる：
中断
修正不可能
ルール
ユーザは、所定の間隔で作動されるビジネスオブジェクトを使い、現在保持されている全てのレコード、それらに与えられた割当状態を検分する能力を提供される。オーディット記録は、例えば全ての”請求番号列”訂正に一カ月等、適当な期間保持できる。
自動ルールの使用が必要でない場合もある。現在のエラーの９０％に及ぶ解読異常が引き起こすエラーを訂正するこにより、エラー率が０．０１％まで減少することが分かっている。従って、生成されるエラーが単純な場合、自動ルールを採用するシステムは、過剰に複雑となる。
図４４において、本発明のデータ収集及び処理システムに関してのデータフロールートが示されている。この図において、ファイル、表等のデータ記憶は、鉛直点線の水平に伸びる矩形によって表され、処理は、矩形を含むより大きなブロックによって表される。ＮＣＤＢ９等、システム全体にとり外部のエンティティは、”ひし形”によって表される。
前記のように、元のコールデータがストリーマに入力され、そこでこの元のコールデータは変換され、確認され、必要であればデータアナライザが使用され、コールレコードが処理され、その後確認され項目分類されたコールレコードがカンパニーボックスに出力される。カンパニーボックスは、第１にオペレータ指定確認を実行し、第２に分類されたコールレコードを集める。この段階で、コールレコードは、例えば国家請求データベース（ＮＣＤＢ）９等からの請求情報を基に価格付けされ、関連するクライアントシステム１０用に請求報告書を作成するため要約の形態で出力される。他の出力には、光学ディスク７１に記憶された拡大コールレコード、管理報告システム４４００の要約コールレコード等が含まれる。
図４４に示すように、データアナライザからオーディティングスシテム”CARDVU”４４０５への出力も存在する。本発明の実施例では、オーディティングに関してて極めて詳細な情報が提供されるが、オーディティングシステムそれ自体は、本発明の一部ではなく、下記で少し触れる意外ここでは詳細には記載されていない。
９．オーディットトレール
図３６において、企業システム８用のデータモデルは、企業システム８による請求、価格付けに使うデータソースを明確に示している。データ量の最も多い”C&P基準データ”は、ＮＣＤＢ９より得られる。しかし、請求可能エンティティとネットワークオペレータ１間での会計合意４５００により制限を受ける。多くの問題はネットワーク管理センタにより対処でき、図３６に示すデータモデルにおいて、”テレコムネットワークオペレータ役割”ボックス４５０５によりそこへの適当な視界が提供される。
図３６で使われるイニシャルは以下に示す意味である：
ＣＢＭ：Charge Band Matrix
ＣＢ：Charge Band
ＮＮ：Network Node
ＫＣＨ：Kingston Communications, Hull（ＢＴＰＳＴＮと相互接続されたＵＫネットワーク内のオペレータ）
ＴＥ：Telecom Eirann（上記同様）
ＮＣＩＰ：National Charging Information Package（ＮＣＤＢ上のデータへのインタフェース）
本発明のシステムによる制限に応じた価格付け及び請求エンジンは知られており、従ってここでは請求、価格付けエンジンについては説明していない。図３６のデータモデルは関係する全てのエンティティは示しているが、複雑になるのを避けるため、全ての関係が示されているはけではない。しかし、全体的にみて、企業システム８が扱うコールデータは、請求可能エンティティに応じ既に分類されている点が重要である。関連する報告書が現在のクライアントシステム１０に割り当てできるよう、データのこの点は維持されなけっればならないことは明らかである。これは、上記のように、例えば、請求可能エンティティに割り当てられたディレクトリィを維持することにより可能である。
９．オーディットトレール
上記のアレンジメントにより、洗練されたオーディットトレールが提供される。相互接続点での交換機データはファイルされ、ＡＰＤＵ内に組み込まれる。ストリーマシステム６は、ＦＴＡＭプロトコルを使いＤＤＣ５からデータをポーリングする。このデータはコールレコード内の二値データである。ストリーマシステム６は、基準データ、ルーティング基準モデルを含むデータベースに対してデータを確認し、他のどのネットワークオペレータに請求するか評価を下す。また、ストリーマシステム６は、オペレータと交換機情報を加え、ＡＳＣＩＩに完全なコールレコードを書き込む。
オーディットトレースは次のように生じる。交換機において、コール例が０から９９９９までのファイル生成番号で番号を与えられる。ＤＤＣ５もまた、ファイルレベルで０から９９９９９９までのシーケンス番号を加える。ファイル内では、ＡＰＤＵが二値数で、０から１６３５３までのＡＰＤＵシーケンス番号を与えられる。
すなわち、ファイル内には、レコード数、ＡＰＤＵの開始と終了番号、ＡＰＤＵ数の記録が記憶されている。
シーケンス番号が交換機における各番号に加えられるため、順序通り処理されるとは限らないが、カンパニーボックス８が順次番号を受け取ることが保証される。ストリーマシステム６は、実際には異なる交換機から同時に平行して処理を行う。
データアナライザでは、”パターンネット”が使われ、それによりデータは有効な内容に適合しない場合、ルールを”発動”し、アナライザは、関係するデータ項目が価格、あるいはオーディトトレールに影響を与えない所においてのみデータ項目の修繕が行える。この場合の修繕は標準値に設定されている。従って、データアナライザは、それがコールレコードを識別するため、コールレコードのシーケンス番号を変更はできない。もしコールレコードのシーケンス番号を変更した場合、オーディットトレールは得られない。
前記のシステムは、本発明の本の一実施例にすぎない。ＰＳＴＮに関連したもので、音声通信システムのコールレコードに対処する。更に、関連コールレコードの所定形態であるシステムＸタイプ６は、ネットワーク間の相互接続点（ＰＯＩ）にて使用できる交換機のほんの一タイプに関連する。
しかし、本発明の精神を脱することなく多くの変更は可能である。本発明の簡単な拡大アプリケーション例として、コールレコードデータを使い請求情報を作成することに加え、通信量情報も得られ処理することができる。例えば、目的地の到達において効果的でないデータ、”無効化”、がＰＯＩでの交換機によりカウントでき、”バルク”された結果がデータ処理システムに入力できる。
更に重要な変更例としては、音声通信以外の通信におけるシステムの使用が上げられ、また前記のように、レコードの膨大な量並びに関連ソースの複雑さから鑑みると、本発明の実施例の利点はＰＳＴＮにおいてであるのは明らかだが、ＰＳＴＮは別に必須の要素ではない。

Claims (3)

1. 通信ネットワークで使用されるデータアナライザであって、なお該ネットワークは１箇所以上の他ネットワークに接続されており、前記通信ネットワークは前記通信ネットワークに関連するデータを確認するための確認手段に結合されており、前記確認手段はデータが予め定められた確認基準に合致しない場合にデータを拒否するように調整されており、前記データアナライザは、
   拒否されたデータを受信する入力部と、
   前記データが拒否された理由を決定する手段と、複数の可能な理由のうちの１つの理由には、データが正しくない場合、またはデータが不完全な場合、またはデータに不適合がある場合を含み、そして
   再度の確認のためにデータを確定するため、決定された理由に対応して拒否されたデータを処理する処理手段とを具備し、前記処理手段は、
   決定する手段が拒否されたデータが正しくないと決定した場合に前記データに補正された値を適用する手段と、
   決定する手段が拒否されたデータが不完全であると決定した場合に前記データに予め定められた値を適用する手段と、そして
   １以上の既存のエラーパターンファイルに拒否されたデータを追加する手段を含む
   データアナライザ。
2. 前記処理手段は、この処理手段が拒否されたデータは削除可能であると決定した場合に、後続する管理分析のためのデータベースに前記データを送出する手段を更に含む請求項１記載のデータアナライザ。
3. 前記データが追加される１以上のファイルの各々は異なるエラーパターンと関連し、前記アナライザは、前記データのエラーパターンと前記１以上のファイルのエラーパターンとの適合に基づき、前記１以上のファイルの１つに前記データを加える手段をさらに含む請求項１又は２記載のデータアナライザ。

Images