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

Abstract

(57)【要約】 英国の公共電話ネットワーク（１）などの通信ネットワークにおいて使われるネットワーク間コール会計システムにより、コールレコードは、価格付けされ請求される前に、コールに関して請求されるべきネットワークオベレーターに応じ分類可能となる。エキスパートシステムを含むデータアナライザ（７）が、確認できないコールレコードに対して提供される。データアナライザ（７）は、ディフォルト、あるいは修正データを加えることができ、又は、更新基準情報を待つ中断処理へ無効データを出力することができる。修正不可能データは、管理のためＳＵＭＰへ出力できる。価格付け、請求エンジンは、請求可能エンティティる。修正不可能データは、管理のためＳＵＭＰへ出力される。価格付け、請求関連情報の理由で無効となったデータに対応するデータ分析手段を更に含む。

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）企業システム８ 図７及び図８において、カンパニーボックス（あるいはシステム）８は、Hewl ett-Packard社のミニコンピュータ７０、ＵＮＩＸオペレーティングシステムを 走作する”エメラルド ８９０／４００”ORACLEリレーショナルデータベース管理システム（ＲＤＭＳ） 、そしてジェームズ・マーチンアソシエッツのＩＥＦケースソフトウェアを使い 書き込まれたカスタムアプリケーションより構成される。 カンマニーボックス８内では、全てのコールレコードが複雑な価格付け、請求 基準表に応じ価格付けされ、ORACLE要約表がインクレメントされる。基準表には 交換機設置データ、ルーティング基準データ、会計契約、価格付け請求データ、 他種々の例外が表される。価格付け、請求基準表は、ＢＴ国家請求データベース （ＮＣＤＢ）及びオペレータ間卸売り価格付け合意から作り出される。 ミニコンピュータの極めて多量の処理タスクを支援するため、Hewlett-Packar d社のＵＮＩＸワークステーション８０、例えば”７３５”、がタスク処理用の 共同プロセッサとして取り付けられる。カンパニーボックスが処理できるコール レコード数を増加するためミニコンピュータ７０にこのようなサークステーショ ンを実際無限数接続できるが、ＢＴＰＳＴＮにおいて必要最小限は現在１２程度 である。前記のように、１９９５年までには６，０００万コールレコード／日に 処理数が増加しており、本発明のデータ方式が必要となるであろう。方法として は、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社のＵＮＩＸサークステーションであり、例えばM anxテレコム等のＢＴと他のオペレータ間で結ばれる単一相互接続合意下で生成 される要約データベース表とコールレコードのみ取り扱う。クライアントボック ス１０はORACLE ＲＤＭ、更にビジネスオブジェクトソフトウェアを走作させる 。各クライアントボックス１０からの情報により、ＢＴは、ＢＴネットワークを 別のネットワークオペレータが使う場合でもそのオペレータに対して請求可能と なるばかりでなく、別ののネットワークオペレータから入って来る請求に対して もその確認が可能となる。各クライアントボックス１０は光学ディスク４１の尋 問もできるが、クライアントボックス１０と関連した相互接続合意下のコールレ コードに関してのみである。クライアントボックスが自分のコールレコードに関 して直接カンパニーボックス８に尋問することは不可能であり、ＢＴと他のオペ レータ間における他の合意に関してのものではなおさら不可能である。要約表の 分析が可能になるようクライアントボックス１０にはパソコンが接続される。 ４．図９及び図１０．コールレコードとデータフォーマット ４（i）コールレコード 英国テレコムタイプ６コールレコードは、請求対象顧客を 主な目的として生成される。コールレコードには、日時、時間、伝送距離等を基 に正確に呼に対して価格を付けるため十分な情報を含有していなければならない 。各タイプ６のコールレコードは、以下を含むことができる： ○請求されるレコード長 ○レコード使用 ○レコードタイプ ○コールタイプ及びコールの有効性 ○クリアリングの原因 ○時間不連続フラグ（コール中のＧＭＴから、又はＧＭＴへ、ＢＳＴから、又 はＢＳＴへの変更） ○コーリングラインＩＤ（ＣＬＩ） ○ルートグループタイプ ○サンンプリング分類 ○ルートグループ ○ノード点コード（ＮＰＣ）：ＰＯＩ交換機生成レコード用のユニークな識別 子 ○リンキングフィールド（一度の請求帯以上のコール両立時に使われる） ○コーリングパーティ分類（商業、住宅、有料電話） ○請求帯 ○アドレス日時完全 ○応答日時 ○コーリングパーティの日時クリア ○着呼パーティの日時クリア ○着呼番号フィールド コールレコードは、全システムＸ交換機上の歳入分配会計（ＲＡＡ）ファシリ ティにより捕獲される。前記のように、ステップ２２０において、コールレコー ドは共にＡＰＤＵ内にグループ化され、ＡＰＤＵは更にファイルにグループイ化 され、各ファイルのサイズは最大１Ｍバイトまでとなっている。システムＸＰＯ Ｉ内のこのようなグループ化処理において、個別コールレコードのどのような部 も破壊するものはない。コールレコードは全て簡単な二値フォーマットである。 図９において、各交換機ファイル４０には可変長のＡＰＤＵ５１が多数含まれ る。各ＡＰＤＵ５１には、また可変長の請求レコードが多数含まれる。しかし、 以下の事項は固定となっている： ○交換機ファイルの最大サイズは１Mバイト ○ＡＰＤＵの最大サイズは５１２バイト ○請求レコードの最大サイズは７０バイト ＤＤＣヘッダとトレーラＡＰＤＵは、ＡＰＤＵタイプがヘッダＡＰＤＵの場合 ２４１、トレーラＡＰＤＵの場合２４５である以外は同一である。 ヘッダ及びトレーラＡＰＤＵにおいて以下の情報が有効となる。 ＡＰＤＵ長：ヘッダ／トレーラＡＰＤＵの長さ ＡＰＤＵタイプ：ヘッダには２４１、トレーラには２４５ ユニークなファイル識別子：以下に記すＤＲＩＮＤＥＸを参照 目的地ＮＮＩ：ＩＮＣＡストリーマのＮＮＩ アプリケーショングループ：ＩＮＣＡデータのアプリケーショングループ＝１ ４ シーケンス番号：テープ／カートリッジのシーケンス番号 出力ファイルシーケンス番号：ＤＤＣシーケンス番号 受け取られたタイムスタンプＤＤＣデータ：ＤＤＣが受け取ったデータ及びタ イムデータ パートファイルインジケータ：ファイルがパートファイルかどうか示す 例外インジケータ：ファイルのどこが悪いかを示す 読み出しカウント：このファイルが読み出された回数 ファイルサイズ：このファイルのバイト数内のサイズ 非選択ＡＰＤＵのカウント：間違ったＡＰＤＵタイプのＡＰＤＵ数 選択ＡＰＤＵタイプ：ＩＮＣＡデータタイプのＡＰＤＵタイプ ＡＰＤＵカウント：このファイル内のＡＰＤＵ数 最初のシーケンス番号：開始ＡＰＤＵシーケンス番号 最後のシーケンス番号：終了ＡＰＤＵシーケンス番号 読み出しカウントは、ファイルがストリーマ６によりＤＤＣからポーリングさ れた回数を表す。パートファイルインンジケータは、ＤＤＣ５による全ファイル の受け取りが成功したか、あるいは残された部分があるかどうかを示す。 例外インジケータは、二つの１バイトビットマスクフィールドであり、本転送 に関しＤＤＣ５によって検知されたどの ようなエラーでも示す。 上記全フィールドに対する有効値は、以下”企業システム８（あるいはボック ス”との関連で記述するコンピュータ支援ソフトウェアエンギニアリング（ＣＡ ＳＥ）アプリケーションソフトウェア内で確認される。 図１０において、ＡＰＤＵ構造５１が簡単に記述されているが、ここにはＡＰ ＤＵヘッダ５２、実際の関連請求レコード５３、更にＡＰＤＵトレーラ５４が含 まれる。 請求レコード５３のフォーマットは標準タイプが使用され、”Ｃ”構造が正確 にこのフォーマット内にマッピングされるようデザインできる。 データが交換機３からDC５にポーリングされた時、各データＡＰＤＵの頭にあ るデータのいくつかはＤＤＣ５により分解される。このデータは、ＤＤＣ５と交 換機３の代表であり、エンド処理システム用の供給データとしては不適格である 。 ファイルがＤＤＣ５により適切なディレクトリィ内に複写されると、ストリー マ６がＦＴＡＭを使い複写する時に有効となることが目的だが、ＤＲＩＮＤＥＸ と呼ばれるカタログファイル内に入力される。ＤＲＩＮＤＥＸファイル入力いは 以下のデータがふくまれる： i）次の事項を示す活動マーカ（１バイト） a）無活動入力 b）転送に有効なファイル c）現在使用中のファイル（例えばＦＴＡＭ転送において） d）転送が成功したファイル（まだ削除していない） ii）ＩＮＣＡファイル名フォーマット iii）次の事項を示す出力ルーティング a）ＦＴＡＭに有効なファイル b）磁気テープのみ iv）作成時間、関連交換機ＮＮＩ等の詳細を含むユニークなファイル識別子 v）ファイルバイトサイズ vi）ファイル内のＡＰＤＵ数 ii）において、ＩＮＣＡファイル名フォーマットは以下を含む： vii）ストリーマＮＮＩ viii）ＮＮＩとクラスタ交換機番号 ix）ＩＮＣＡデータのアプリケーショングループ x）交換機ファイルのＤＤＣファイルシーケンス番号 ４．（ii）交換機データ上へのデータ構造のマッピング ストリーマ６は、以下の原理を用い、カンパニーボックス８のモデル内で使用 されるデータをデータ構造内にマッピングする： ○ＡＰＤＵ長フィールドと請求レコード長フィールドが正しいと仮定される。 正しくない場合、ＡＰＤＵ、あるいは請求レコードのどちらかのレベルで確認処 理が失敗し、ファイルはデータアナライザ７に流される。 ○ヘッダＡＰＤＵ５２を見つけ出すため初期段階で入力データが走査される。 これは、２４１（ＨＥＸ：Ｆ１）のＡＰＤＵタイプにより判別される。次に、選 択されたＡＰＤＵタ イプフィールドが、これが間違いなくヘッダＡＰＤＵ５２であると確認するため ユニークファイル識別子に沿ってチェックされる。 ○ヘッダＡＰＤＵ５２が発見され、ヘッダＡＰＤＵデータ構造がマッピングさ れた後、ファイル内のＡＰＤＵは全てＡＰＤＵが従う１ワードレコード長のデー タ標準に従うと仮定される。 例： ／ＨＥＡＤＥＲ ＡＰＤＵ／ＲＬ／ＡＰＤＵ／ＲＬ／ＡＰＤＵ．．．／ＲＬ／ ＡＰＤＵ／ＲＬ／ＴＲＡＩＬＥＲ ＡＰＤＵ ここでＲＬはレコード長である。 ファイル構造がこの標準がから乖離する場合、ファイルは更なる分析のためデ ータアナライザ７に流される。このエラー状態は、乖離の直ちにＡＰＤＵの確認 処理内で検知される。 ○各ＡＰＤＵ内の構造は、図６の構造に従うと仮定される。この場合もこの構 造からのどのような乖離も、全データ構造マッピングの不一致の原因となり、フ ァイルが拒否され、データアナライザ７に流されることになる。 ○トレーラＡＰＤＵ５４の後いはデータは一個も存在しない。トレーラＡＰＤ Ｕ５４の後の出現するデータは、どれも皆失われる。 ５．図１１から図１９、及び図２２から図３０：ストリーマとデータアナライ ザ処理 ５（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）−ＤＤＣ終了。 図６において、ストリーマ６／データアナライザ７のソフトウェアアーキテク チャにはＩＥＦ外部活動ブロック（ＥＡＢ）６２が含まれている。ＥＡＢ６２は 、ＩＥＦ内での実施が不適切、あるいは不可能な場合使用される。例えば、ＥＡ Ｂ６２によって実行される機能は以下の通りである： ○”中断へのコールレコードを加える” このモジュールは、中断ファイルに送られる交換機ファイル用にコールレコー ドを含む連結リスト内で新しい入力コールレコードを作成する。 ○”集積にコールレコードを加える” 修正されたが再ストリーミングは不可能な交換機ファイル用コールレコードを 含む連結リスト内で、アーカイブディレクトリィに新しい入力コールレコードを 作成する。 ○”ネットワークオペレータレコードを加える” 新規のネットワークオペレータかどうかチェックし、そうであれば”ＮＥＴ w ork operator structure”の連結リスト内 に新しく入力する。すでに使われたネットワークオペレータ名であれば、そのネ ットワークオペレータ用のコールレコード連結リスト内に連結リスト入力を加え る。コールレコードが修正された場合、”ＮＥＴworkoperatorrecord”ＩＤとス トリーミングされたコールレコードシーケンス番号により”call record error log”を更新する。 ○”ＩＤＡルールへのコースレコード” 単一コールレコードをデータアナライザＡＲＴ ＩＭルールベースに渡す。コ ールレコードがＡＰＤＵシーケンス番号によって識別され、ＩＥＦによってコー ルレコードシーケンス番号が入って来る。次に、メモリにロードされたデータ構 造が、コールレコード、所有のＡＰＤＵ、交換機ファイルヘッダデータ用に捜査 される。このデータは、その後ルールベースに供給され確認される。見つけ出さ れたどのようなエラーでも、それぞれコールレコード記録行入力を生成する。ま た、コースレコードエラー記録レコード状態がルールベースによって更新される 。 ○”コミット” 現在のデータベースを全て変更する。 ○”ＤＤＣ処理を作成” 特定ＤＤＣをポーリングを司るＤＤＣ処理を作成する。子処理にＦＩＦＯ（フ ァイルイン／ファイルアウト）を作成／開き、このＦＩＦＯ内にＤＣ ＮＮＩ値 を書き込む。 ○”ＤＤＣからファイルを削除” ＦＴＡＭプロトコルを使いＤＤＣ上のディスクからファイ ルを削除する。 ○”データアナライザファイルを削除” ストリーマ／データアナライザディレクトリィからファイルを削除する。 ○”中断ファイルを削除” 中断ファイルディレクトリィからファイルを削除する。 ○”BINへのファイル” ＡＲＴ／ＩＭルールベース内へ読み込みできないファイルを二値ファイルダン プへ渡す。 ○”データアナライザルールへのファイル” 全ファイルをデータアナライザＡＲＴ ＩＭルールベースへ渡し、ルールベー スを初期化する。ルールベースの初期化には、旧データのクリア、ディフォルト 及びルーティング基準データの選択、とのデータによるデータベースのポピュレ ーティング等が含まれる。次に、データアナライザ二値ファイルが、メモリのデ ータ構造内にロードされる。このデータは、ルーレベースに供給され確認される 。見つけ出されたエラーはどれでも適切なルール記録行入力を生成する。コール レコードエラー記録は、ルートエラーパターン、最も近似のマッチング、ライフ ルートエラーリンクレコード等と共に、適切と思われる箇所においてルールベー スにより作成される。一旦確認された後は、ルールベースは確認状態をＩＥＦに 戻し、後の検索用に内部データを保持する。 ○”ＳＵＭＰへのファイル” ＡＲＴ ＩＭルールベースによって修正できないファイル をＳＵＭＰに渡す。 ○”ＦＴＡＭＨＬＣＯＰＹ” ＦＴＡＭプロトコルを利用し、ストリーマ６へＤＤＣユーザ名を使いＤＤＣＦ ＴＡＭアドレスからのＤＤＣファイル名、ＤＤＣパスワード、ＤＤＣ口座を複写 する。このルーティンは、ＩＥＦから直接に呼び出され、従ってＩＥＦスタイル 状態は返却しない。 ○”ＤＤＣ処理パラメータを得る” ”ＤＤＣ ＰＲＯＣＥＥ ＦＩＦＯ＜ＰＩＤ＞”と名付けられるＦＩＦＯをス トリーマ／ＴＭＰディレクトリィに作成、又は開く。”create file process” ルーティンによりＦＩＦＯ内に挿入されたデータであるＦＩＦＯからの上記変数 値を読み出す。 ○”交換機ファイルを得る” ＦＴＡＭプロトコルを利用し、ＤＤＣ上のディスクからストリーマ６上のディ スクは直接にファイルを複写する。次に、ファイルがストリーマ６上のメモリ内 に読み込まれ、元のレコードバックアップディレルトリィ内で新たに名を付けら れ、そこからアーカイブされる。このモジュールは、最初の請求レコード、最初 のＡＰＤＵ、ヘッダ、トレーラＡＰＤＵに対して初期ポインタを設置するため、 ”map data structure to file”を呼び出す。 ○”無効データアナライザＡＰＤＵ数を得る” ストリーマ確認処理で失敗したコールレコードの無効ＡＰＤＵ再処理数を返却 する。 ○”データアナライザファイルをマッピングする” 後続処理用にメモリ内にファイルを読み込む。 ○”処理活動中” 特定のＰＩＤが活動中かどうか判別し、それに応じてフラグを返却する。 ○”交換機ファイルヘッダを読み出す” ヘッダＹ及びトレーラＡＰＤＵへのポインタを使い、ヘッダからのフィールド 全て、更にトレーラからのＡＰＤＵタイプを構造内に返却する。 ○”データアナライザ交換機ファイルヘッダを読む出す” ヘッダ及びトレーラＡＰＤＵへのポインタを使い、データアナライザに送られ ているファイル用に、ヘッダからのフィールド全て、トレーラからのＡＰＤＵタ イプを構造内に返却する。 ○”最初のＤＲＩＮＤＥＸレコードを読み出す” ＦＴＡＭプロトコルを利用し、ＤＤＣから一時保存部にＤＲＩＮＤＥＸファイ ルを複写し、ファイルを開き、発呼者に最初のレコードを戻す。 ○”次のＡＰＤＵを読み出す” 現在のＡＰＤＵポインタ指示のＡＰＤＵ構造を返却し、次のＡＰＤＵに現在の ＡＰＤＵポインタを設置する。また、返却されたＡＰＤＵ内の最初の請求レコー ドに現在の請求レコードポインタを設置し、複写し、現在のＡＰＤＵ配列内にデ ータがバイト反転される。 ○”次のＤＲＩＮＤＥＸレコードを読み出す” ＤＤＣ上のＤＲＩＮＤＥＸファイルから次のレコードを読み出す。 ○”次のデータアナライザレコードを読み出す” ＡＲＴ ＩＭルールベースから次の請求レコード出力を返却する。成功すれば 、処理レコードがまず表れ、続いて中断ファイルに送るレコードが表れる。 ○”次の中断レコードを読み出す” 中断ファイルから次の請求レコード出力を返却する。 ○”次のレコードを読み出す” 現在の請求レコードポインタにより指示されている請求レコードを返却し、も ちこれが現在のＡＰＤＵ内で最後のレコードでない場合、ポインタを次の請求レ コードに設置する（これは、ＡＰＤＵ長と請求レコードの最低長を使い決定され る）。 ○”ネットワークオペレータファイル名の変更” カンパニーボックス８による処理準備が整った操作ディレクトリィ内の一時デ ィレクトリィに書き込まれたどのネットワークオペレータファイル名も変更する 。 ○”スリープ” 所定秒間スリープする。 ○”ファイルを流す” データアナライザ処理の準備が整ったデータアナラアイザにメモリ内のファイ ルをダンプする。 ○”ストリーミングファイルネットワークオペレータ” 最初のネットワークオペレータへのポインタを使い、該オ ペレータの確認され拡大されたレコード全てにアクセスする。次に、連結リスト からのレコードをnfs 一次ディレクトリィに書き込む。成功した場合、ファイル はnfs ディレクトリィ内でその名が変更される。NFS一次ディレクトリィ上にフ ァイルが再び開けられない場合、そのファイルはローカル一次ディレクトリィ上 に開かれ、これが成功したら、ローカルディレクトリィ内で名変更が行われる。 ○”ファィルRRBを流す” メモリ内のファイルを元のレコードバックアップディレクトリィへダンプする 。 ○”コンソールを書き込む” ネットワーク管理ワークステーションにメッセージを書き込む。 ○”中断ファイルへ書き込む” 交換機ファイル用中断コールレコードの連結リストからのレコードを中断ディ レクトリィに書き込む。 ○”アーカイブファイルに書き込む” 交換機ファイル用アーカイブコールレコードの連結リストからのレコードをア ーカイブディレクトリィに書き込む。 ６．図３１から図３５：エキスパートシステム：ＡＲＴＩＭ ６（i）概要 エキスパートシステムは、インフェアンス社提供のＡＲＴ ＩＭ知識ベースエキスパートスシテムツールキットのファシリティを利用する 。これは、知識／ルールベースプログラ ミングシステムで、知識階層内での柔軟な意思決定モデル、よって現実世界のモ デル作成が可能になり、更に問題解決のより発見的方法が提供される。ツールキ ットには、ＡＲＴ ＩＭ言語、統合エディタ、インタラクティブ開発環境、エン トユーザインタフェース開発用ツール、開発されたアプリケーションの走作時間 バージョンを展開する方法、外部データを賢明に解釈するファシリティ等が含ま れる。 データアナライザ７において、エキスパートシステムは、ルールベースとケー スベースの二つのサブシステムに分割される。一般に、ケースベースはルーティ ングベースエラーの処理に、ルールベースはディフォールティング算出可能エラ ーの処理に使われる。両方ともＡＲＴ ＩＭの機能性を利用する。 ルールベースは、ルール、機能及び方法を含むＡＲＴ ＩＭ手順言語を使う。 各エラーは、図式内で定義され、これら図式例がデータ構造上で使われる。デー タ内オブジェクト階層内の全ての図式は、ＡＲＴ ＩＭの”DEF-EXTERNAL FUN” ファシリティを使いＩＥＦ／ＡＲＴ ＩＭインタフェースを介しポピュレーティ ング（駐在）される。 ＡＲＴ ＩＭが使用するプログラムフロー制御機構は、通常のプログラミング 言語内で見られる逐次ステートメント毎のフローとは大変異なっている。図３１ ，３２において、エキスパートシステムは、その全ての内部データ、すなわち図 式と事実、をパターンネット３１００内に保持する。図３１に示すように、これ はそれぞれが内部データを表す（図式又 は事実）複数のパターン化された円によって表されている。このデータは、以下 の方法により設定できる： ○ＡＲＴ ＩＭ試験ケースファイルをロードする（通常は開発／ユニット試験 の状況で行われることが多い） ○外部ソースからのポピュレーティングにうよる（例えばORACLE又はＩＥＦ： 通常は生産／システム試験環境で行われることが多い） ○ＡＲＴ ＩＭから生成することによる（極めて柔軟な”作業記憶部”、例え ば確認試験失敗後のエラー図式の生成、として使われる）設定後、データはルー ル内所定の条件と直接比較される。ルールは、より伝統的なプログラミング言語 の”IF＜conditions＞THEN＜action＞”に似ている。ルール条件がデータ例と正 確に適合している場合、関連事項３１０５内で作動生成される。全てのデータ例 が全ルールに対してチェックされる。性能においては、パターンネット及びルー ル条件が、ＡＲＴ ＩＭ走作時間システム内の効率の良いパターンマッチングア ルゴリズムによって管理される。 サイクルの評価部の最後に、全てのルール作動が事項スタック上に順番に配置 される。このスタック上の最初のルール作動が発動される。作動表出の順番は、 重要点、すなわちルールの優先順位、が開発者によって設定されない場合、バラ バラとなりディフォルトとなる。 図３２において、事項３１０５の最上位ルール作動の発動後、ルールの作動に より実際にパターンネット内のデータが変更されており、そして次の評価サイク ルに続き事項スタッ ク上に表出するデータを変更する。 初期の発動を引き起こすデータ例（円で囲んだ例３１１０）は再評価されず、 よってデータ例内のデータが変化し、新しいパターンがルール条件に適合する場 合、ルール作動が生成されるが、連続したルーピングが避けられる。 ＡＲＴ ＩＭ走作は以下の時終了する： ○適合する条件、パターンが一つも見つからない。 ○全ての適合条件、パターンが既にルールを発動している。 上記を要約すると次の通りとなる： １）ルール作動は、データパターンをルール条件に適合させることにより生成 される。 ２）ルールは、優先順位を設定できるが、ディフォルトによりどのような順番 でも発動できる。 ３）全てのデータが並列に評価される。 ４）ルールの発動ごとに再評価が実行される。 ５）適合データ例の数により、走作中同じルールが何回でも発動できる。 ６）ルール条件は、パターンネット内の変化に敏感である。 ７）適合するルール条件、あるいはパターンネットデータが一つも見つからな い場合、あるいは全ての適合作動が既に発動されている場合、ＡＲＴ ＩＭは停 止する。 図３３において、図示のようにルールベースシステムは、オブジェクト階層を 基としている。各オブジェクト３３００は、ＡＲＴ法において定義され、オブジ ェクト３３００間の接続線は、上記オブジェクトからの遺産を表す。 交換機ファイル、ＡＰＤＵ、コールレコードはその構造に各データ項目ごとに スロットを含む。各スロットは、適切なディフォルトオジェクト内に対応するス ロットを有し、結果としてディフォルト値、又は算出可能値を有するのか、ある いは修正不可フィールドなのか宣言する。ルールベースは、ディフォルトシステ ムを使い、もし可能であればエラー訂正がどの形態でなけれなならないかチェッ クする。 上記にはデータ図式も含まれている。エラー図式に関しては、可能性のあるど のようなデータアナライザエラーでもその詳細が適切な図式内で記述される。各 エラー記述及びその例には、以下のそれぞれ用にスロットが含まれている。 エラー関連のオブジェクト、すなわち交換機ファイル。 エラー記述。 影響されるスロット。 エラー例用所定データオブジェクト。 修正値名。 エラー源。 結果として生成される修正値。 発動順番におけるルール位置。 修正前のスロット値。 ６（ii）ルールベース一般ルール ルールベース操作フローは、多数の一般ルールにより制御され、これらは以下の 機能を果たす： ○エラー発動毎に、そのエラー修正方法が起動され、修正値を生成し、その第 １番目が割り当てられる。 ○影響を受けるスロットがたったの一個である修正可能エラーに対して、影響 を受けるスロットを生成された修正値で更新し、変更時間スタンプがエラー例と 共に記憶される。 ○修正記述がエラータイプは中断可能と宣言する該エラーに対して、影響を受 けるデータ項目が中断ファイルに移動され、その移動時間スタンプがエラー例と 共に記憶される。 ○修正記述がエラータイプはＳＵＭＰ可能と宣言する該エラーに対して、影響 を受けるデータ項目がＳＵＭＰに移動され、そのファイルのサンピング時間スタ ンプがエラー例と共に記憶される。 ○ＡＰＤＵ、又は交換機ファイル上の各修正に対して、レコードがファイル構 造ルール記録上に作成される。 ○適切なエラー情報を有するコールレコード上の各修正に対して、ORACLEレコ ードがコールレコードエラー記録上に作成される。 修正可能エラー １）ディフォルト値は以下のフィールドに割当可能である ＡＰＤＵタイプ及びトレーラ 請求されたコールインジケータ 着呼パーティクリア ＰＢＸ添数 レコード使用 レコードタイプ ＤＤＣ時間スタンプ ヘッダＡＰＤＵタイプ データ転送種別 フォマットバージョン番号 ノード時間スタンプ 部分ファイルインジケータ 表サイズ トレーラＡＰＤＵタイプ 着呼パーティクリア アプリケーショングループ ２）以下のエラーが算出可能である： ＡＰＤＵ長；ＡＰＤＵの長さ。 ＡＰＤＵ数；ＡＰＤＵ列の長さ。 エンドＡＰＤＵシーケンス番号；開始シーケンス番号＋有効ＡＰＤＵ数。 開始ＡＰＤＵシーケンス番号；交換機ファイル内の最初のＡＰＤＵのシーケス 番号より得られる。 ダイアルされた数字；ダイアルされた数字列の長さ。 上記に関し、ＡＰＤＵのチェックサミングがエラーとなる等、エラーとなる例 外がある。このタイプのエラーは、ルールベース内で直ちにＳＵＭＰされる。Ａ ＰＤＵ列に関するいくつかのエラーは、結果として”１”から再度列化される完 全な範囲の列数を生成し、関連交換機ファイルが更新される。ダイアルされた数 字列の最後がＡとＦ間の文字でも良い。ここでの修正値は、ダイアルされた数字 列ー最後の数字である。 修正不可能エラー 修正不可能エラーが出た場合、前記にようにエラー中のデ ータ項目、すなわちコールレコード、がＳＵＭＰに渡され、該当するエラー記録 が更新される。修正できない領域、従って修正不可エラーを生成する領域は以下 の通りである： アドレス捕獲時間スタンプ アドレス完了時間スタンプ アドレス、あるいは応答時間スタンプのどちらか一方 発呼パーティクリア時間スタンプ 発呼ラインディレクトリィ番号 捕獲時間スタンプ ダイアルされた数字列（最後がＡとＦ間の文字の場合を除く） ６（iii）ケースベースシステム ルーティング基準ケースベースは、ルーティングパターン（ＴＵＮ、ルートグ ループ、ルート番号、ＮＮＴ、ノードポイントコード等）に、例えば請求可能ネ ットワークオペレータ名、活動中、終了ノード時間スタンプなど他の基準データ を加えたケースベースである。ケースベース基準データはルーティング基準図式 からポピュウレーティングされ、この図式は、データモデルのストリーマ基準デ ータ従属領域３６００内のデータからポピュレーティングされる（図３６参照） 。 図３４において、ケースベースシステムのオブジェクト階層は、図３３に示す ルールベースシステムの階層に”提案されたソルーション”、”可能性のあるソ クーション”、”ルーティング基準”の三種のオブジェクト種別３４００を加え たものと同様である。”提案されたソルーション”及び”可能性のあるソルーシ ョン”は、ルーティング基準エラーの判 別に続いてのみ作成され、主に他のデータ、すなわち最も適合性が近いエラー中 の着呼レコードとルーティング基準図式、へのポインタを含んでいる。”ルーテ ィング基準”図式は、ORACLEデータベース上のルーティング基準データから作成 される。 ルーティングケースベース、初期化に関しては、ルーティングケースベースは 、ルーティング記述図式からの走作開始にポピュレーティングされる。ケースは 、各ルーティング記述図式につき一個作成される。ルーティングケースベースは 、以下のパラメータにより設定される： ○最大３個のマッチング ○可能性ゼロの閾値以下のマッチングは、ほとんど可能性のないマッチングを 排除するためどのようなものでも無視される。 ○パターンマッチングではケースベース上の次のスロットのみ使われる： ＴＵＮ（例えば、電話ユニット番号）、ルートグループ、ノードポイントコード 、ルート番号、ＮＮＩ、方向 ○次の事項がパターンマッチングでは無視される： 活動中のノード時間スタンプ 終了したノード時間スタンプ テレコムネットワークオペレータの役割と名前 ○方向は、マッチングでは多少異なったものとして扱われる。これは最も重要 性の低いスロットで、全重量の固定重量上限５%が与えられる。他のスロット重 量は、全重量の残り ９５％を均等に割って与えられる。 パターンマッチングは、初期化パラメータの設定等、他のケースベース機能と 共に、ケースベースにメッセージを送ることによりアーカイブされる。パターン マッチングは、二つのステップで行われる、すなわち見つけ出されたマッチング 数を返却するケースベースに着呼コールレコード図式を送るステップと、返却さ れたケースに関連したルーティング基準図式のキーと共に各返却ケースのマッチ ング近似性を決定する検索・マッチング・スコアメッセージを送るステップであ る。 ケースベースは、コールパターンに関連したエラーコード確認に使われ、ノー ドポイントコード、見出せないルートグループ、無効ルート番号、あるいは無効 方向の場合以下のように使われる： ○各着呼レコードとルーティング基準ケースベース上のケース間で正確なマッ チングを見つけ出す。正確なマッチングがある場合、コールレコードは有効なル ーティングパターンを有し、上記エラーに関してこれ以上の確認は必要でない。 ○正確なマッチングがない場合、上記のように修正方法を適用するルールベー ス一般ルールを発動するエラー図式を生成する。 ○所定の修正方法により次のものを含む提案されたソルーション図式一個作成 する（図３４参照）： i）最大三種の可能性のあるソルーション図式で、それぞれが関連ルーティン グ基準図式へのポインタを有す。また、 可能性のあるソルーションは、マッチング位置（すなわち、次の近いもの等）と マッチング近似性測定値％を含む。 ii）エラー中の着呼レコードへのポインタ。 修正方法はエラー図式例の生成により発動される通常の修正方法とはことなる。 この方法が、機能（提案されたソルーション図式例とルーティング基準図式への キーを含む事実を強調するルーティングミスマッチ）と別のルール（ルーティン グミスマッチにより作成された事実の生成上で発動し、見つけ出された各ケース ベースマッチングに対する一つの可能性のあるソルーション図式を生成する最も 近似のマッチング生成）から成っているかだである。 ノード時間スタンプ確認に関しては、ケースベースは以下のように使われる： ○各着呼レコード図式とルーティング基準図式間で正確なマッチングを見つけ 出す。正確はマッチングがある場合、次に、ルールが、適合した着呼レコード図 式とルーティング基準図式上での時間スタンプの不一致（すなわち、捕獲時間ス タンプはノード活動中と終了時間の間に位置する）をチェックする。不一致が存 在しない場合、このエラーにかんしてはこれ以上の処理は必要ではない。 ○時間スタンプ不一致がある場合、上記のように修正方法を適用するルールベ ース一般ルールを発動するエラー図式が生成される。 ○所定の修正方法は、提案されたソルーション図式を一個作成し、ここには以 下が含まれる（図３４参照）： −それぞれが関連ルーティング基準図式へのポインタを含む可能性のあるソル ーション。また、可能性のあるソルーションには、マッチング位置（すなわち、 最も近いもの、次に、近いもの等）とマッチング近似性測定値％が含まれる。 −エラー中の着呼レコードへのポインタ。 ここでも修正方法は、エラー図式例の生成により発動される通常の修正方法とは 異なる。この方法が、機能（提案されたソルーション図式例とルーティング基準 図式へのキーを含む事実を強調するノード・時間スタンプの不一致）と別のルー ル（ルーティングミスマッチにより作成された事実の生成上に発動され、可能性 のあるソルーション図式の一例を生成する（generate node time discrepancies ）から成るからである。 ６（iv）ＡＲＴ ＩＭとORACLEインタフェース 図３５において、ＡＲＴ ＩＭルールベースの”平行”確認特徴を十分に活用 するため、ＡＲＴ ＩＭからORACLEデータベースへの直接アクセスが要求される 。４種の主要インタフェースが存在する： ○ルーティング基準データ３５００のポピュレーション ○ディファルトデータ３５０５のポピュレーション ○オーディットトレール形成のための修正データの出力 ○中断データ取扱３５１５の先駆けとしてのルーティング エラーパターンの出力ルーティング基準データのポピュレーションに関しては、 このインタフェース３５００は、ORACLE表内に物理的に保持される内部RT−IM図 式とルーティング基 準モデル内のデータからのケースベースのリフレッシュを含む： ○リフレッシュは、ＡＲＴ ＩＭ走作の初期化段階中に発動される。 ○既存の内部ＡＲＴ ＩＭルーティング基準図式は、そのケースベース入力と 共にクリアされる。 ○データは、二つの外部アクションブロック（file to IDA rules及びcall vc cord to IDA rules）の一部として使われるＰＲＯＣプログラム（EBA INITIALIS E IDA RUILEBASE）からのORACLE表から選ばれる。 ○内部ＡＲＴ ＩＭ図式は、ＰＲＯＣプログラムによりポピュレーティングさ れる。 ○ルーティング基準ケースベースは、ケースベース初期化処理の一部としての 機能（ＩＮＣＡ ＩＤＡ initialise ＣＡＳＥbase）により内部ルーティング基 準図式からポピュレーティングされる。 ディフォルトデータのポピュレーションに関しては： ○リフレッシュは、ＡＲＴ ＩＭ走作の初期化段階中に発動される。 ○既存の内部ＡＲＴ ＩＭディフォルト図式（df-call-record，df−APDU等） は、そのケースベース入力と共にクリアされる。 ○データは、二つの外部アクションブロック（file to IDA rules及びcall re cord to IDA rules）の一部として使われるＰＲＯＣプログラムからのORACLE表 から選ばれる。 ○内部ＡＲＴ ＩＭ図式は、ＰＲＯＣプログラムによりポピュレーティングさ れる。 エラー及び修正データの作成に関しては、修正可能なデータと関連のある入っ て来るデータの確認中にエラーが検知される場合、ルールベースにより加えられ る修正のオーディットトレールは維持する必要がある： ○エラー中の各ファイル構造に対して、FILE ERROR LOG表内に行入力を作成す る。これは、ストリーマ処理によって可能である。 ○エラー中の各コールレコードに対して、CALL RECORD ERROR LOG内に行入力 を作成する。これは、ストリーマ処理、あるいはＡＲＴ ＩＭによって可能であ る。 ○ファイル構造レベルで検知された各エラー及び修正に対して、ORRACLEデー タベース上の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）着呼レコードから、エラーパターンによりポピュレーティングされるROUT E ERROR PATTERN表内に行入力を挿入する。 v）FILE ROUTE ERROR LINK内に行入力を挿入する。 vi）前のケースベース処理からエラー中のルートパターンに最も近いと発見さ れたルーティング基準パターンによりポピュレーティングされたCLOSEST MACHES 表内に最大３個の行入力を挿入する。 ○ユーザ定義手順は、ORACLEへＳＱＬコマンドを渡すため使われる。 ○ＡＲＴ ＩＭルールは、内部図式上のスロットから挿入値をポピュレーティ ングする。 ７．図２０，図２１，図３７から図４３：データアナライザ７によるエキスパ ートシステムの利用 以下に記載のフロー図において、本明細書における初期のフロー図とは多少異 なったフォーマットが適用されている。すなわち、機能呼び出しが二重鉛直線の ボックスにより表され、単純なステートメントは一本の鉛直線のボックスによっ て表され、YES／NOの決定は簡単なダイアモンド形で表される。 データアナライザ７によるＡＲＴ ＩＭエキスパートシステムの利用は、フロ ー図で表すことができる。図１６，図１ ７，図２０において、ステップ１６０５で一旦コールレコードレベルで失敗が決 定されると、ステップ１７０２で次のコールレコード記録がファイルから選択さ れており、ステップ２０００で関連するコールレコードがエキスパートシステム に送られる。エキスパートシステムは、ステップ２００５，２０１０で正しいＡ ＰＤＵを発見し、次に、ステップ２０１５，２０２０でエラーとなったコールレ コードを発見する。 次に、エキスパートシステムは、コールレコードが正確に項目分類されている かチェックし（ステップ２０２５）、の例ではシステムＸ項目分類化に従ってお り、もしそうでない場合、ステップ２０３０でＩＥＦ状態を”ＳＵＭＰ”に設定 することによりコールレコードをＳＵＭＰに渡し、一方ステップ２０３５でコー ルレコードエラー記録を更新する。コールレコードが正しく項目分類される場合 、ステップ２０４０，２０４５，２０５０においてエキスパートシステムに”つ なぎ”、ステップ１７０４以降でその結果をデータアナライザ７により評価する 。 図１６，図２１において、ステップ１６０４でファイル、あるいはＡＰＤＵレ ベルで失敗があったと決定された場合、ステップ２１００でファイルがメモリに ロードされ、ファイルヘッダとＡＰＤＵがエキスパートシステムに送られる。ス テップ２１０５でエキスパートシステムデータベースが呼び出され、ステップ２ １１０で前の削除された走作からＡＰＤＵ図式を呼び出す。ステップ２１１５で の最初の試験走作は、ルーティング基準モデルのエキスパートシステムバージョ ン のリフレッシュが目的で、これにより直ちにエラーを訂正することができる。そ うでない場合、万が一例えば、関係するエラー用のディフォルトデータが前に見 失っていた場合のため、ステップ２１２０でエキスパートシステムのディフォル トデータがリフレッシュされる。このどちらかが成功すると、図１６に示すよう に、データアナライザ処理が再び開始され、エキスパートシステムのリフレッシ ュステップからの結果、ステップ１６１１でファイルはそのコールレコードの確 認に進むことができる。どちらも成功しない場合、コールレコードは個別に確認 されなければならない。これは以下のように行われる。 図３７において、図２１の機能ボックス２１２５が、すなわち”マップヘッダ とＡＰＤＵ図式”、ルーティング基準モデルとディフォルトデータのリフレッシ ュ後うま処理できなかったエラーファイルからのコールレコードに関して、エキ スパートシステム、ＡＲＴ ＩＭのローディング（ステップ３７００，３７２５ ，３７３５）と実行（ステップ３７３０，３７４０，３７４５，３７５０）を含 むよう拡大する。このローディング処理には、例えばステップ３７１５でストリ ーマ６からのデータ等、ＡＲＴデータベース（”外部キー”）上では存在しない データを得、エキスパートシステムのファイルアクセスを可能にする。各コール レコードの分析後、ＡＲＴは状態供給を行う（ステップ３７５５）、これにより コールレコードが修正されたか、中断すべきか、ＳＵＭＰすべきかが分かる。デ ータアナライザ処理（ＩＥＦ）は、ステッ プ３７６０でＳＵＭＰすべきコールレコード数のクンティングを行い、ステップ ３７６５でＡＲＴ ＩＭ内にフラッグを設置する。これによりステップ３７７０ でＡＲＴ ＩＭによるクリーンアップが発動され、各コールレコードと関連図式 のクリアリングを行いその確立が避けれれる。 図３８から図４３において、エキスパートシステムのファイルルールのアプリ ケーションもフロー図で表すことができ、以下の例が示されている、この場合の フロー図は自明である i）図３８；ＡＲＴファイルルール（交換機ファイルヘッダ） これは、次のものに適用できる− トレーラＡＰＤＵ フォーマットバージョン番号 ファイルタイプ ノード時間スタンプ ＤＤＣ／NMP時間スタンプ（NMPはネットワーク調停プロセッサを表す） データ転送種別 ノード群ＩＤ ストリーマＮＮＩ アプリケーショングループ 部分ファイルインジケータ ファイルバイトサイズ 表サイズ 選択されたＡＰＤＵタイプ ii）図３９；ＡＰＤＵの最初のシーケンス番号ルール iii）図４０；ＡＰＤＵの最後のシーケンス番号ルール iv）図４１；ＡＰＤＵのシーケンス番号カウントルール v）図４２；ＡＲＴＡＰＤＵルール これは、以下に適用できる− 再伝送インジケータ 連結フィールド vi）図４３；ＡＲＴコールレコードルール これは、以下に適用できる− レコードの使用 請求されたコールのインジケータ クリアリングの原因 ＰＢＸ添数 ＣＬＩ群ＩＤ ネットワーク回路 ネットワーク帯 回路ＩＤ 回路番号請求帯 呼サンプリング方法 サンプリングモード カウントリセットインジケータ Ｎの値（Ｎは、例えばコールレコードの試験中に数えられた数に関する） 着呼パーティクリア時間スタンプ ８．図３６，図４４：企業システム 図４において、ストリーマ６から企業システム８への出力は、請求可能エンテ ィティに従い分類され、前記のようにＡＲＴ ＩＭエキスパートシステムを内蔵 したデータアナライザを使い確認されたコールレコードより構成される。 企業システム８の主要な役割は、クライアントに対して請求できるよう、コー ルレコードの価格付けをし、価格付けされたレコードを出力することである。一 方、前記のように確認の役割も有し、よって請求可能エンティティ及び請求可能 エンティティと第１ネットワーク１間の関係に関連したデータが重要視される。 従って、企業システム８は、以下”ｃＩＤＡ”として示される企業システムデー タアナライザを内蔵するか、あるいはそれにアクセスするようになっている。 ｃＩＤＡアプリケーションは、前記ストリーマ６からのデータを確認するデー タアナライザ７と並んで配置することもできる。図４で、エラーコールレコード の修正ステップ４３０、修正されたコールレコードのバルキング４４０、修正不 可能レコードの調査４５０は全てｃＩＤＡアプリケーションにより実行できる。 大多数のエラーは、企業システム８が拾い上げたエラーのうち９０％程度にな り、以上状態の解読に関係するものであり、主に”時間ライン”（１２３）、” 緊急サービス”（９９９）と関係したものであるのは興味深い。残りエラーの殆 どは、基準データの不一致が原因である。従って、企業システム８で使うデータ アナライザの構築において、二つの主要な面が存在する、すなわち、大多数のエ ラー、解読異常とな るレコードに対処することと、訂正後ファイルを企業システム８に返却可能な基 盤を提供することである。 処理概要 適切な方法は、以下の通りである。エアー、そして警告ファイルが企業システ ム８からｃＩＤＡに送られ、そこで所定のディレクトリィにロードされる（各オ ペレータにつき一個）。一つのファイルでゼロ、あるいは多くのレコードを保持 できる。ｃＩＤＡが、手動オーバーライドの能力で同時に作動する全オペレータ 用に平行処理ファシリティを提供できることが望ましい。ｃＩＤＡ内外へのファ イル列を制御するため、記録保持される。 一旦エラーファイルが処理選択されると、ｃＩＤＡはファイルが空きでないと 仮定することにより各レコードを選択し、そのエラーを、修正可能、不可能のど ちらかに分類する。修正不可能レコードは、表に書き込まれ、報告され、後でア ーカイブの際データベースから取り除くことができる。修正可能と見なされるレ コードは、ルールの適用により自動的に修正できるか、あるいは修正前手動調整 を要する場合がある。 各レコードは、エラータイプにかかわらず、ORACLEデータベース表に挿入され 、全ての詳細がカンパニーボックス８から渡され、”状態”を表すためフラッグ が設置される。この状態は、上記に従い、以下から選択できる： 中断 修正不可能 ルール ユーザは、所定の間隔で作動されるビジネスオベジェクトを使い、現在保持さ れている全てのレコード、それらに与えられた割当状態を検分する能力を提供さ れる。オーディット記録は、例えば全ての”請求番号列”訂正に一カ月等、適当 な期間保持できる。 自動ルールの使用が必要でない場合もある。現在のエラーの９０％に及ぶ解読 異常が引き起こすエラーを訂正するこにより、エラー率が０．０１％のまで減少 することが分かっている。従って、生成されるエラーが単純な場合、自動ルール を採用するシステムは、過剰に複雑となる。 図４４において、本発明のデータ収集及び処理システムに関してのデータフロ ールートが示されている。この図において、ファイル、表等のデータ記憶は、鉛 直点線の水平に伸びる矩形によって表され、処理は、矩形を含むより大きなブロ ックによって表される。ＮＣＤＢ９等、システム全体にとり外部のエンティティ は、”ひし形”によって表される。 前記のように、元のコールデータがストリーマに入力され、そこでこの元のコ ールデータは変換され、確認され、必要であればデータアナライザが使用され、 コールレコードが処理され、その後確認され項目分類されたコールレコードがカ ンパニーボックスに出力される。カンパニーボックスは、第１にオペレータ指定 確認を実行し、第２に分類されたコールレコードを集める。この段階で、コール レコードは、例えば国家請求データベース（ＮＣＤＢ）９等からの請求情報を基 に価格付けされ、関連するクライアントシステム１０用に請求 報告書を作成するため要約の形態で出力される。他の出力には、光学ディスク７ １に記憶された拡大コールレコード、管理報告システム４４００の要約コールレ コード等が含まれる。 図４４に示すように、データアナライザからオーディティングスシテム”CARD VUV”４４０５への出力も存在する。本発明の実施例では、オーディティングに 関してて極めて詳細な情報が提供されるが、オーディティングシステムそれ自体 は、本発明の一部ではなく、下記で少し触れる意外ここでは詳細には記載されて いない。 ９．オーディットトレール 図３６において、企業システム８用のデータモデルは、企業システム８による 請求、価格付けに使うデータソースを明確に示している。データ量の最も多い” C&P基準データ”は、ＮＣＤＢ９より得られる。しかし、請求可能エンティティ とネットワークオペレータ１間での会計合意４５００により制限を受ける。多く の問題はネットワーク管理センタにより対処でき、図３６に示すデータモデルに おいて、”テレコムネットワークオペレータ役割”ボックス４５０５によりそこ への適当な視界が提供される。 図３６で使われるイニシャルは以下に示す意味である： ＣＢＭ：Charge Band Matrix ＣＢ：Charge Band ＮＮ：Network Node ＫＣＨ：Kingston Communications，Hull（ＢＴＰＳＴＮと相互接続されたＵ Ｋネットワーク内のオペレータ） ＴＥ：Telecom Eirann（上記同様） ＮＣＩＰ：National Charging Information package（ＮＣＤＢ上のデータへ のインタフェース） 本発明のシステムによる制限い応じた価格付け及び請求エンジンは知られてお り、従ってここでは請求、価格付けエンジンについては説明していない。図３６ のデータモデルは関係する全てのエンティティは示しているが、複雑になるのを 避けるため、全ての関係が示されているはけではない。しかし、全体的にみて、 企業システム８が扱うコールデータは、請求可能エンティティに応じ既に分類さ れている点が重要である。関連する報告書が現在のクライアントスステム１０に 割り当てできるよう、データのこの点は維持されなけっればならないことは明ら かである。これは、上記のように、例えば、請求可能エンティティに割り当てら れたディレクトリィを維持することにより可能である。 ９．オーディットトレール 上記のアレンジメントにより、洗練されたオーディットトレールが提供される 。相互接続点での交換機データはファイルされ、ＡＰＤＵ内に組み込まれる。ス トリーマシステム６は、ＦＴＡＭプロトコルを使いＤＤＣ５からデータをポーリ ングする。このデータはコールレコード内の二値データである。ストリーマシス テム６は、基準データ、ルーティング基準モデルを含むデータベースに対してデ ータを確認し、他のどのネットワークオペレータに請求するか評価を下す。また 、ストリーマシステム６は、オペレータと交換機情報を加え、 ＡＳＣＩＩに完全なコールレコードを書き込む。 オーディットトレースは次のように生じる。交換機において、コール例が０か ら９９９９までのファイル生成番号で番号を与えられる。ＤＤＣ５もまた、ファ イルレベルで０から９９９９９９までのシーケンス番号を加える。ファイル内で は、ＡＰＤＵが二値数で、０から１６３５３までのＡＰＤＵシーケンス番号を与 えられる。 すなわち、ファイル内には、レコード数、ＡＰＤＵの開始と終了番号、ＡＰＤ Ｕ数の記録が記憶されている。 シーケンス番号が交換機における各番号に加えられるため、順序通り処理され るとは限らないが、カンパニーボックス８が順次番号を受け取ることが保証され る。ストリーマシステム６は、実際には異なる交換機から同時に平行して処理を 行う。 データアナライザでは、”パターンネット”が使われ、それによりデータは有 効な内容に適合しない場合、ルールを”発動”し、アナライザは、関係するデー タ項目が価格、あるいはオーディットトレールに影響を与えない所においてのみ データ項目の修繕が行える。この場合の修繕は標準値に設定されている。従って 、データアナライザは、それがコールレコードを識別するため、コールレコード のシーケンス番号を変更はできない。もしコールレコードのシーケンス番号を変 更した場合、オーディットトレールは得られない。 前記のシステムは、本発明の本の一実施例にすぎない。ＰＳＴＮに関連したも ので、音声通信システムのコールレコー ドに対処する。更に、関連コールレコードの所定形態であるシステムＸタイプ６ は、ネットワーク間の相互接続点（ＰＯＩ）にて使用できる交換機のほんの一タ イプに関連する。 しかし、本発明の精神を脱することなく多くの変更は可能である。本発明の簡 単な拡大アプリケーション例として、コールレコードデータを使い請求情報を作 成することに加え、通信量情報も得られ処理することができる。例えば、目的地 の到達において効果的でないデータ、”無効化”、がＰＯＩでの交換機によりカ ウントでき、”バルク”された結果がデータ処理システムに入力できる。 更に重要な変更例としては、音声通信以外の通信におけるシステムの使用が上げ られ、また前記のように、レコードの膨大な量並びに関連ソースの複雑さから鑑 みると、本発明の実施例の利点はＰＳＴＮにおいてであるのは明らかだが、ＰＳ ＴＮは別に必須の要素ではない。

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

Claims (1)

1. 【特許請求の範囲】 １．通信ネットワークで使用され、該ネットワークが１箇所以上の他ネットワ ークに接続されたデータアナライザにおいて、前記通信ネットワークに対して収 集され、前記ネットワークに関連する確認手段により拒否されたデータの入力部 と、前記データ内で起こる無効タイプを評定する手段と、それに応じデータを処 理する手段とを具備し、前記処理手段がディフォルト値を加える手段と、修正値 を加える手段と、一時データ保存部内のファイルにデータを追加する手段を含む データアナライザ。 ２．請求項１記載のデータアナライザにおいて、前記データ処理手段が、後続 する管理分析のためＳＵＭＰにデータを送出する手段を更に含むことを特徴とす るデータアナライザ。 ３．請求項１又は２記載のデータアナライザにおいて、データ処理手段が無効 となった理由に基づきデータ処理法を選択することを特徴とするデータアナライ ザ。 ４．請求項１，２又は３記載のデータアナライザにおいて、データを追加でき る各ファイルが各エラーパターンと関連し、ファイルに追加された全データが、 例えば無効と関連した所定の基準データを更新すること等により同様に補正され ることを特徴とするデータアナライザ。 ５．請求項１，２，３又は４記載のデータアナライザにおいて、価格付け、請 求手段と関連した確認手段により請求関連の不正確なデータを基に拒否されたデ ータを受け取る第２の入力部を有することを特徴とするデータアナライザ。 ６．請求項１から４の何れかに記載のデータアナライザにおいて、前記アナラ イザが復号異常を基に確認手段により拒否されたデータ用入力部を含むことを特 徴とするデータアナライザ。 ７．請求項１から６の何れか記載のデータアナライザにおいて、ルールベース 及びケースベースを含むエキスパートシステムより構成されることを特徴とする データアナライザ。 ８．請求項１から７の何れか記載のデータアナライザにおいて、該アナライザ が、一部は不正確なルーティングデータ等種々の理由の何れかにより無効とされ たデータを分析するためのエキスパートシステムを含む部、他方は前記種々の理 由に含まれない少なくても一つの理由により無効とされたデータを分析するため の部の二部構成であり、これらのうちの第一部が関連請求可能エンティティに従 い分類されたデータを受け取り、第二部が分類されていないデータを受け取るこ とを特徴とするデータアナライザ。