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

Description

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

Claims (5)

1. 第１通信ネットワークにおいてデータを収集しそして処理するための方法であって、前記データは通信事例に関するものであり、ここで前記第１通信ネットワークは１つまたはそれより多い第２通信ネットワークに対する少なくとも１つの接続部を有し、前記方法が、
   （ａ）前記少なくとも１つの接続部におけるデータ・アクセス・ポイントにおいてデータを収集するステップと、ここで前記データは前記第２通信ネットワークの１つである発信源ネットワークで発生する通信事例に関するものであり、前記データは前記発信源ネットワークを識別する経路情報、および前記通信事例に関する少なくとも１つのパラメータの値をさらに含み、
   （ｂ） 前記データをデータ処理システムに伝送するステップと、
   （ｃ） 料金請求情報を生成するため前記データを処理するために前記データ処理システムを使用するステップと、
   （ｄ） 前記料金請求情報を前記第２通信ネットワークの１つに配信するステップと、そして
   （ｅ） 前記第２通信ネットワークのそれぞれに関するそれぞれの料金請求情報を蓄積するステップとを具備し、ここで前記データ処理システムはデータ解析装置を含み、前記データを処理するために前記データ処理システムを使用するステップは無効データを解析するステップが後に続くデータを検査するステップを含み、前記解析するステップはデフォルト値に設定し得るデータを識別するステップを含み、かかるデータをデフォルト値に設定しそして有効なデータとしてデフォルト値に設定されたデータを処理する
   方法。
2. 前記処理するステップが、前記発信源ネットワークの操作者識別情報に従って前記データを分類するステップを含む請求項１記載の方法。
3. 前記第１通信ネットワークは、市内交換と市外交換の両方を有する通信ネットワークを含み、前記データ処理システムを使用するステップは前記発信源ネットワークを識別する経路情報に対応するデータベースからの料金設定および課金データを検索することを含む請求項１または２に記載の方法。
4. 第１通信ネットワークにおいてデータを収集しそして処理するためのシステムであって、前記データは通信事例に関するものであり、ここで前記第１通信ネットワークは１つまたはそれより多い第２通信ネットワークに対する少なくとも１つの接続部を有し、前記システムが、
   （ａ）各前記少なくとも１つの接続部におけるデータ・アクセス・ポイントにおいてデータを収集するためのデータ入力部と、ここで前記データは前記第２通信ネットワークの１つである発信源ネットワークで発生する通信事例に関するものであり、前記データは前記発信源ネットワークを識別する経路情報、および前記通信事例に関する少なくとも１つのパラメータの値をさらに含み、
   （ｂ） 前記データを受信しそして料金請求情報を生成するために前記データを処理するデータ処理システムと、ここで前記データ処理システムはデータ解析装置を含み、
   （ｃ） 前記第２通信ネットワークの１つに前記料金請求情報を配信する手段と、
   （ｄ） 前記第２通信ネットワークのそれぞれに関するそれぞれの料金請求情報を蓄積する手段とを具備し、ここで前記データ解析装置はデータを検査しそして無効データを解析するために配置され、前記データ解析装置はさらにデフォルト値に設定し得るデータを識別するためにそしてかかるデータをデフォルト値に設定するために配置され、有効なデータとしてデフォルト値に設定されたデータを処理するためのデータ処理手段が配置されているシステム。
5. 複数の他のネットワークに接続され複数の他のネットワークからの通信事例を受け取る第１通信ネットワークで使用するためのデータ収集および処理装置であって、この装置は、
   前記他のネットワークの内の１つにおいて生じ、第１通信ネットワークに着信する各通信事例を登録するための登録手段と、
   前記通信事例のレコードをフォーマットするための手段と、ここで前記レコードは前記他のネットワークの内の１つを識別するデータおよび通信事例に関連するパラメータ値を含み、
   前記レコードを検査するための検査手段と、
   料金設定データおよび課金データを検査されたレコードと結び付け、料金設定され、課金され、そして検査されたレコードに関する分類されたデータの集合を提供するための料金設定および課金手段と、ここで前記データの集合は他のネットワークの識別情報に従って分類され、
   検査手段により拒否されたレコードを解析するための解析手段と、ここで前記解析手段は拒否の理由に対応する少なくとも３つの方法の内の１つの方法により拒否されたレコードを処理するように構成され、第１の方法は認可されないレコードの値を最も近い一致値に設定するものであり、第２の方法は認可されないレコード値をデフォルト値に設定するものであり、そして第３の方法は認可されないレコード値をファイルに保管するかダンプするものであり、第１の方法又は第２の方法のいずれかにより処理されたレコードが、認可されたレコードとして直接的あるいは間接的に前記料金設定および課金手段に送信されるデータ収集処理装置。

Images