(57)【特許請求の範囲】
【請求項１】
電話交換機の通話詳細記録をフォーマットする方法において、
未処理データを含むメッセージを受信する段階と、
前記メッセージから通話詳細記録に関連する情報を抽出する段階と、
前記通話詳細記録を勘定センターへ送る段階と、
前記メッセージの全てのフィールドヘッダとフィールドパラメータデータを含むマザーフォームを受信する段階と、
前記マザーフォームとブランクのユーザフォームとをグラフィックユーザインタフェースに表示する段階と、
前記グラフィックユーザインタフェースにおいて所望の順序で所望のフィールドヘッダとフィールドパラメータデータを前記マザーフォームから選択することによりユーザフォームを生成する段階と、
前記ユーザフォームを前記電話交換機へ送信する段階と、
を備えることを特徴とする方法。
【請求項２】
マザーフォームが各メッセージ形式ごとに形成される請求項１に記載の方法。
【請求項３】
前記マザーフォームのファイル名は、メッセージ番号、メッセージ形式識別子及びマザーフォームのバージョン番号を示す請求項１に記載の方法。
【請求項４】
前記マザーフォームのファイル名に基づいて前記ユーザフォームのファイル名が与えられ、前記ユーザフォームのファイル名は、メッセージ番号、メッセージ形式識別子及びユーザフォームのバージョン番号を示す請求項３に記載の方法。
【請求項５】
前記ユーザフォームのヘッダフィールドにおける状態データフィールドは、ユーザフォームが受動的（Ｐ）であるか能動的（Ａ）であるかを示し、そして前記抽出する段階で能動的なユーザフォームが使用される請求項３に記載の方法。
【請求項６】
前記マザーフォームは前記電話交換機の供給者によって供給され、一方、オペレータが前記ユーザフォームを生成する請求項１に記載の方法。
【請求項７】
前記電話交換機の供給者が、前記マザーフォームを供給し且つ前記ユーザフォームを生成する請求項１に記載の方法。
【請求項８】
前記ユーザフォームは、テスト下にあるユーザフォームを用いてテスト用のメッセージからテスト通話詳細記録に関連する情報を抽出することによってそのアクチベーション前にテストされ、
真の通話詳細記録からテスト通話詳細記録を区別する分離マークが、それらの記録が前記勘定センターへ送られる前に前記テスト通話詳細記録に含められ、
前記勘定センターは、テスト下にあるユーザフォームを用いて前記テスト通話詳細記録を処理する請求項５に記載の方法。
【請求項９】
前記受動的なユーザフォームのアクチベーションに応答して、前記電話交換機は、前記アクチベートされたユーザフォームを使用して前記メッセージからの情報の抽出を開始する請求項５に記載の方法。
【請求項１０】
前記勘定センターは、前記ユーザフォームを使用して、受け取った通話詳細記録のデータを解釈する請求項１に記載の方法。
【請求項１１】
前記受動的なユーザフォームのアクチベーションに応答して、前記勘定センターは、前記アクチベートされたユーザフォームを使用して、受け取った通話詳細記録の処理を開始する請求項１０に記載の方法。
【請求項１２】
テレコミュニケーションシステムにおいて、
未処理データを含むメッセージを受信し、受信した前記メッセージから通話詳細記録に関連する情報を抽出する幾つかの電話交換機と、
前記通話詳細記録を受信し、該通話詳細記録の後処理を実行して電話勘定書を生成する勘定センターと、
受信した前記メッセージのうちの少なくとも１つのメッセージの全てのフィールドヘッダとフィールドパラメータデータを含む少なくとも１つのマザーフォームと、
所望のフィールドヘッダとフィールドパラメータデータが前記マザーフォームからの選択に従って所望の順序で配置される少なくとも１つのユーザフォームと、
前記マザーフォームとブランクのユーザフォームを表示し、グラフィカルインタフェースにおいて所望の順序で所望のフィールドヘッダとそれらのパラメータデータを表示された前記マザーフォームから選択することによってユーザフォームを生成するユーザフォーム生成手段と、
電話交換機においてユーザフォームをアクチベートする手段と、
を備えることを特徴とするテレコミュニケーションシステム。
【請求項１３】
前記勘定センターは、前記通話詳細記録からデータを抽出する前記アクチベートされたユーザフォームを用いる請求項１２に記載のテレコミュニケーションシステム。
【請求項１４】
アクチベーションに対するオペレータの要求に応答して、ネットワークマネージメントは、前記電話交換機のユーザフォームのアクチベーションを実行する請求項１２に記載のテレコミュニケーションネットワーク。
【請求項１５】
前記マザーフォームは、前記電話交換機の供給者により作成され、ディスケットに記録されたファイルとしてオペレータに送付され、前記ユーザフォームは、前記マザーフォームに基づいて前記オペレータにより作成され、前記電話交換機の供給者及び勘定センターへ、ディスケットに記録されたファイルとして、或いは、ネットワークを経て、送付される請求項１２に記載のテレコミュニケーションシステム。
【請求項１６】
前記マザーフォーム及び前記ユーザフォームは、ＡＳＣＩＩコードを備えるファイルである請求項１２に記載のテレコミュニケーションシステム。
【請求項１７】
テレコミュニケーションシステムのための電話交換機において、該電話交換機は、
未処理データを含むメッセージを受信する手段と、
受信した前記メッセージから通話詳細記録に関連する情報を抽出する手段と、
を備え、
前記電話交換機は、少なくとも１つのユーザフォームを記憶する手段を備え、該ユーザフォームは、グラフィカルインタフェースに表示されたマザーフォームからの選択に従って所望のフィールドヘッダとフィールドパラメータデータを所望の順序で含んでおり、前記マザーフォームは、受信した前記メッセージのうちの少なくとも１つのメッセージの全てのフィールドヘッダとフィールドパラメータデータを含んでおり、
前記情報を抽出する手段は、前記少なくとも１つのユーザフォームの少なくとも１つを使用するよう構成されている、ことを特徴とする電話交換機。
【請求項１８】
テレコミュニケーションシステムのための勘定センターにおいて、該勘定センターは、
未処理データを含むメッセージから抽出された情報を含む通話詳細記録を受信する手段と、
受信した前記通話詳細記録の後処理を実行して電話勘定書を生成する手段と、
を備え、
前記勘定センターは、少なくとも１つのユーザフォームを記憶する手段を備え、該ユーザフォームは、グラフィカルインタフェースに表示されたマザーフォームからの選択に従って所望のフィールドヘッダとフィールドパラメータデータを所望の順序で含んでおり、前記マザーフォームは、未処理データを含む少なくとも１つのメッセージの全てのフィールドヘッダとフィールドパラメータデータを含んでおり、
前記電話勘定書を生成する手段は、前記少なくとも１つのユーザフォームの少なくとも１つを使用するよう構成されている、ことを特徴とする勘定センター。
【請求項１９】
テレコミュニケーションのためのネットワーク管理ユニットにおいて、該ネットワーク管理ユニットは、
未処理データを含むメッセージの全てのフィールドヘッダとフィールドパラメータデータを含む少なくとも１つのマザーフォームと、
前記マザーフォームからの選択に従って所望のフィールドヘッダとフィールドパラメータデータを所望の順序で含む少なくとも１つのユーザフォームと、
前記マザーフォームとブランクのユーザフォームとを表示し、グラフィカルインタフェースにおいて所望のフィールドヘッダとそれらのパラメータデータを所望の順序で表示された前記マザーフォームから選択することによってユーザフォームを生成するユーザフォーム生成手段と、を備えることを特徴とするネットワーク管理ユニット。
【請求項２０】
電話交換機に、及び／又は、通話詳細記録の後処理を実行する際に使用するために勘定センターに、ユーザフォームをアクチベートする手段を備える、請求項１９記載のユニット。
【請求項２１】
前記ネットワーク管理ユニットは、前記マザーフォームを表示し前記ユーザフォームを生成するプログラムを有したコンピュータである請求項１９又は２０に記載のユニット。
【請求項２２】
テレコミュニケーションシステムにおける通話詳細記録の処理を管理する方法において、
未処理データを含むあるメッセージの全てのフィールドヘッダとフィールドパラメータデータを含むマザーフォームを受信する段階と、
前記マザーフォームとブランクのユーザフォームとをグラフィックユーザインタフェースに表示する段階と、
所望のフィールドヘッダとフィールドパラメータデータを前記グラフィックユーザインタフェースにおいて所望の順序で前記マザーフォームから選択することによりユーザフォームを生成する段階と、
前記ユーザフォームを、電話交換機へ、及び／又は、通話詳細記録の後処理を実行する際に使用するために勘定センターへ送信する段階、を備えることを特徴とする方法。
【請求項２３】
電話交換機においてユーザフォームをアクチベートする段階を備える請求項２２記載の方法。
【請求項２４】
通話詳細記録の後処理を実行する際に使用するために勘定センターにおいてユーザフォームをアクチベートする段階を備える請求項２２又は２３記載の方法。
【発明の詳細な説明】
発明の分野
本発明は、構成されたデータ流から所望のデータを抽出することに係り、より詳細には、電話交換機により形成された通話詳細記録の連続流から所定のデータを抽出することに係る。
先行技術の説明
サービスの結果として行なわれる勘定処理は、サービス提供者とその顧客との間の契約で実施される。原理的には、分散型勘定及び集中型勘定の２種類の勘定がある。
分散型勘定では、顧客が、販売者により提供されるサービスを利用する時間ごとに販売者に支払を行う。この支払は、通常の金銭で行なわれるか、又は何らかの同等の支払手段で行なわれ、例えば、手紙の配達について支払をするときには郵便切手が使用される。分散型勘定に使用される支払手段の最近の例は、各「コイン」が、銀行のサーバで照合されねばならない暗号化された２進シーケンスで構成される電子マネーである。
集中型勘定では、サービスの利用が販売者又は第３者によって監視される。顧客は、１ヶ月に一度のように定期的に勘定請求される。この勘定は、手前の勘定期間中に収集された監視データに基づく。集中型勘定の例は、電気、電話及びクレジットカードの勘定である。集中型勘定は、３つの段階より成る。第１の段階は、当事者間でサービス及びそれに関連した勘定について契約を交わすことである。第２の段階は、サービスの利用を監視（又は測定）し、そして利用に関するデータをセーブすることである。第３の段階は、勘定書を作成し、そしてそれを顧客に送付することである。勘定書は、勘定システムにセーブされたデータに基づいて形成される。
電話ネットワークに使用される集中型勘定は、加入者とオペレータとの間の契約に基づく。契約の重要なポイントは、加入者が電話サービスへのアクセス権を得、即ちコールを出したり受けたりすることができ、そして提供されたサービスに対する補償として、オペレータにより送付される勘定書に特定された所定の料率に基づいて支払を行うというものである。勘定書は、通常、固定料金と使用料金の２種類の料金を含む。固定料金は、サービスが利用されたかどうかに関わりないものである。使用料金は、加入者がどれほど多数の通話を発信したかそしておそらく加入者がどれほど多数の通話を受信したかに基づく。使用料金を請求できるようにするために、オペレータは、発信及び受信した通話を監視しなければならない。このような監視は、接続をベースとするもので、ネットワークスイッチによって行なわれる。
図１は、公衆電話ネットワークの一部分を表わすことにより電話ネットワークに使用される既知の集中型勘定方法を示している。各通話が発信されるたびに、ローカル交換機ＬＥ（加入者のローカル交換機）は、通話の詳細データの収集を実行し、そしてＣＤＲ（通話詳細記録）をフォーマットする。この記録は、１回の通話について勘定を行うのに必要な全ての情報と、通話に関連した必要量の他の情報とを含む。通話詳細データの収集は、通話についての特定の詳細情報が、通話詳細の監視又は勘定に必要とされるときに、常に使用される。通話詳細記録の構造は、通話詳細データの収集が導入される前に、オペレーションコントロールコマンドにより決定される。この記録の構造は、ネットワーク管理により制御される全ての交換機要素において均一な構造として決定されねばならない。以下、通話詳細記録は、ＣＤＲとも称され、そして通話詳細記録をフォーマットするプログラムは、ＣＤＲジェネレータと称される。フォーマットされたＣＤＲは、後処理のためにＢＳ（勘定センター）へ送信される。
通話詳細記録をフォーマットするには、通話詳細記録をフォーマットするためのある基礎をオペレータが確立する必要がある。フォーマットは、例えば、加入者の全ての通話の通話詳細データ収集に基づくものでもよいし、又は通話の形式、即ち当該通話が通常の通話であるか、コール転送等のファシリティ通話であるか、無料通話であるか、ＩＮ通話（インテリジェントネットワーク通話）であるか、等々に基づいてもよい。固定ネットワークの用途では、約３０個の異なるフォーマット基礎が存在する。フォーマットされた通話詳細記録は、先ず、メモリにセーブされ、次いで、集中型勘定システムに送信され、そこで、例えば、時期テープやハードディスクのような大量記憶装置にセーブされる。
又、交換機と勘定システムとの間には、通話詳細データ収集記録を勘定システムのために「前処理」するという付加的な処理段階があってもよい。このような前処理は、例えば、料率クラスフィールドがあるフォーマットから別のフォーマットに変換されるようなフォーマット化である。前処理が行なわれるかどうかに関わりなく、通話詳細データ収集は、数百万の記録を含む膨大なデータブロックを形成し、これらは勘定システムの大量記憶装置にセーブされる。これらの記録は、勘定システムが処理を開始するところの生の情報を形成する。
従って、通話詳細データ収集記録の処理は、後で、通話詳細データ収集記録の発生とは個別のバッチ処理として行なわれる。実際には、勘定処理は、上記の例よりも著しく複雑であることに注意されたい。例えば、移動ステーションネットワークでは、通話の一部分を引き継ぐ各移動サービス交換センターが通話詳細データ収集記録を作成する。しかしながら、勘定の原理は、上述した通りである。
現在の固定ネットワーク電話システムにおけるＣＤＲフォーマットの処理を図２について以下に説明する。この図は、本発明の観点から重要な電話交換機の機能を示す。
通話詳細データ収集プロセスは、通話に関連した情報を主として通話制御器から個々のメッセージにおける生のデータ（未処理データ）として得る。通話詳細データ収集プロセスは、その情報を通話に指定された記録にセーブする。通話の終了時に又は一時的なデータ収集に関連して、データ収集プロセスは、通話記録全体を種々の形式のメッセージにおいて、通話詳細記録をセーブするプロセスへ送信する。このメッセージは、その内容の特性を指示する通話形式番号と、メッセージシーケンス番号とを有する。次々のメッセージの構造は常に同じであり、そしてその形式は、メッセージのどのフィールドを埋めねばならないかを決定する。埋められるべきフィールドの数がメッセージにおけるフィールドの数より少ない場合には、空きフィールドに充填コードが埋められる。従って、メッセージは、常に、全体的に送信される。
セーブプロセスは、個別フォーマットファイルにおいてメッセージ構造を読み取るように進み、そして受け取った生のデータ流から記録のフォーマット化を開始する。通話記録及びフォーマットファイルの構造は、通話詳細データ収集を記憶するためにプロセスのコードで一定に構成にされる。一定コード化が行なわれる理由は、通話記録におけるフィールドの場所がフォーマットファイルから見つからないからである。通話詳細データ収集をセーブするプロセスは、フォーマットファイルを次々に読み取り、そして受け取った通話記録から、ＣＤＲにそれを配置するためのフィールドをピックアップする。但し、これは、フォーマットファイルにおいてそのフィールドが取り上げられるべきものとして定義されている場合である。又、ＣＤＲにおいて個々のフィールドをコード化する仕方も、通話詳細データ収集をセーブするプロセスのコードで一定に確立される。
ある用途において、メッセージのあるフィールド、例えば、時間フィールドフォーマットに対して異なる処理を行うことが所望される場合には、アプリケーションスイッチの制御によりこれを行わねばならない。
通話詳細データ収集をセーブするプロセスは、ＣＤＲを完了すると、それをＲＡＭブロックに配置する。通常、１つのブロックは、５ないし１０個のＣＤＲを収容することができる。ブロックが完了すると、それが関連電話交換機のハードディスクにセーブされるか、又は交換機の外部のあるＩ／Ｏ装置、例えば、オペレーションコントロールセンターのハードディスクに送信される。又、受け取ったブロックを後処理プロセスへ直接送ることもできる。
オペレータは、ある加入者の通話でフォーマットされたＣＤＲを、オペレーションコントロールセンターのハードディスクにセーブされたブロックから出力することができる。これは、マン・マシン・ランゲッジ（ＭＭＬ）コマンドで行なわれる。このコマンドは、通話詳細データ収集のフォーマットファイルの構造と、サブファイルに対応するフィールドの名称とが一定コード化された読み取りプログラムをスタートさせる。読み取りは、ハードディスクのリングバッファから実行される。
フォーマットファイルにセーブされるフォーマットについても簡単に説明する。オペレータは、希望のフォーマットをＭＭＬコマンドで実行する。このコマンドは、先ず、オペレータに対し、メッセージに使用できる全てのフィールド又はサブフィールドをモニタディスプレイに平易な言語で出力する。その際に、オペレータは、形成されるべきフォーマットに配置することを希望するフィールドを選択する。使用可能なフィールドから、オペレータは、フィールドを取り上げるか又は除去できるが、フィールドの順序を変更することはできない。ユーザが選択を行うと、フォーマットが完了し、ディスプレイに出力されるか又は紙に印字される。出力は、フォーマットにどのフィールドが存在するかを平易な言語で指示する。
フォーマットは、例えば、次の通りである。
0003683593.tif 000002
従って、フィールドの名前は、通話加入者番号であり、そして数値１０は、ＣＤＲにおけるフィールド組合せの場所を表わす。
ＭＭＬファンクションは、通話詳細データ収集プロセスのフォーマットファイルに得られるフィールド（サブファイル）を読み取り、そしてそれを、ユーザが希望のフォーマットを形成するためのＭＭＬコマンドと、ユーザにより選択されたフォーマットをディスプレイ又は紙に出力するためのＭＭＬコマンドの両方に使用する。どのフィールドを選択できるかそしてその選択されたフィールドが通話詳細記録ＣＤＲに存在するかどうかは、フォーマットファイルによって示される。フォーマットファイルは、通話詳細記録ＣＤＲにおける最大フィールド数と同程度のサブファイルを含む。
フォーマットファイルのサブファイルの構造は、次の形式である。
0003683593.tif 000003
上記形式から明らかなように、これは、フィールド名を平易な言語で指示しない。このため、平易な言語でのフィールド名及びフォーマットファイルにおけるそれらの対応性は、ＭＭＬファンクションにおいて一定コード化される。コード化は、例えば、次の通りである。
0003683593.tif 000004
これは、CRPARAの名前でフォーマットファイルからの位置０に配置されたフィールド（このフィールドは、ここでは、FIELD_IN_RECORDと称される）が真であり、即ちフォーマットを形成するときにユーザがそれを選択する場合には、名前CALL TIMEが平易な言語で与えられることを意味する。
上述した通話詳細記録の現状のフォーマット化には幾つかの欠点がある。
第１に、通話詳細記録が電話交換機から後処理を実行する勘定センターへ送信されるときに、送信されるべきデータ流が大きなものとなる。とりわけ、それは、多量の空きフィールド即ち非表示フィールドを含む。生のデータ流が２進形態、１６進形態及びＡＳＣＩＩ形態のデータを含むときには、フォーマットされたＣＤＲも、異なる形態のデータを含むことになる。異なる形態のデータは、交換機から送信されるべきデータの量に追加される。
第２に、勘定センターが、新たなフィールドを追加するか又は現在使用中のフィールドを除去するために他の種類のＣＤＲを希望する場合には、それが困難であるだけでなく、何らかの変更を行うためにリスクが生じる。というのは、フォーマットファイルで行なわれる変更が正しく実行され、そして後処理場所の受信端即ち勘定センターがその変更されたＣＤＲデータ流を正しく解釈できることが無条件で確保されねばならないからである。
第３に、現状の構造体では、フォーマット又はフィールド名に関連した全てのファンクションにおける到来データ流並びにフォーマットファイルにおけるそれらの対応性がプログラムブロックにおいて一定コード化されるので、通話詳細データ収集セーブプロセス、データ収集プロセス、ＭＭＬプログラム、及びフォーマットに完全に新しいデータエレメントが所望されるときのＣＤＲの出力に関連したプログラムにおいて、必要な変更を常に行なわねばならない。プログラムの変更に加えて、フォーマットファイル構造も変更しなければならず、そして変更は、このファイルの変換プログラムにおいて行なわねばならない。第２及び第３の項目は、交換機が買主に納入される１年も前に買主がどのフォーマットを希望するかを交換機の供給者が知らねばならないという問題がある。従って、フォーマットがいったん作られると、それを変更することが困難であり且つ高価なものとなる。
本発明は、使用中に上述したような欠点で悩まされない方法に向けられる。従って、目的とするところは、既知の方法よりもフォーマットの変更がより動的で且つより信頼性の高い方法である。「進行中(on the move)」にフォーマットを変更できるべきであり、そして変更されたいかなるＣＤＲも処理するために後処理は一度に準備されねばならない。又、種々の目的で異なるＣＤＲを形成でき、従って、現在のＣＤＲより短いＣＤＲを実行できねばならない。
これらの目的は、独立請求項に記載した方法及びシステムにより達成される。
発明の要旨
本発明は、生のデータ流から所望のデータを抽出するために特殊なフォームを使用するという考え方をベースとする。フォームの数は多いが、各メッセージ形式に対して１つだけが能動的である。各フォームは、ＣＤＲをフォーマットするために生のデータ流から抽出しなければならない情報を厳密に定義する。あるフォームがアクチベートされると、フォーマットプロセスは、そのフォームにより決定されたデータをデータ流から抽出する。
このため、交換機の供給者は、生のデータ流として到着するフィールドの名前及びパラメータの全てを平易な言語（ＡＳＣＩＩフォーム）で示す特殊なマザーフォームをフォーマットする。従って、マザーフォームは、メッセージ構造を含むファイルである。各異なるメッセージは、それ自身のマザーフォームを有する。マザーフォームは、例えば、ディスケットにおいてユーザに供給される。ユーザは、所望のマザーフォームをディスプレイに示すグラフィックユーザインターフェイスを使用するプログラムを有している。これに加えて、ユーザフォームブランクを見ることができ、そしてユーザは、マウスを用いて、ユーザが選択するフィールドをマザーフォームからユーザフォームへドラグし、そこで、選択したフィールドをドロップする（ドラグ・アンド・ドロップする）だけで、希望のフィールドを選択することができる。このように、ユーザは、ＣＤＲに含ませることを希望するデータのみを含む自分自身のフォームを形成する。ユーザは、もし希望するならば、自分の好きなデータとなるようなフォームを決定することもできる。ユーザは、全てのデータを２進形態にすることもできる。ユーザは、自分のフォームを例えばディスケットにおいて交換機及び勘定（ビリング）センターへ送付することもできる。
ユーザのフォームが電話交換機に到着すると、それをいつでもアクチベートすることができる。フォームが能動的であるときに、フォーマットプロセスは、このフォームをフィルタのように使用し、そしてそのフォームに指示されたフィールドに対応するデータを生のデータ流から抽出し、従って、ＣＤＲをフォーマットする。ＣＤＲが完了すると、交換機は、それを勘定センターへ送り、勘定センターは、ユーザにより形成された同じフォームを使用して、その受け取ったＣＤＲに含まれたデータを解釈し、即ちフィールドを形成しそしてそのフィールドに属するデータをＣＤＲから転記する。従って、フィールドの名前は、交換機から勘定センターへ転送されない。
ユーザフォームをアクチベートする前に、そのフォームをテストすることができる。従って、交換機において、フォーマットプロセスは、フォームに定義されたＣＤＲを形成し、そしてそれを勘定センターへ送付する。勘定センターは、その部分について、ＣＤＲがテストされたＣＤＲであることが分かり、それに応じてＣＤＲを取り扱う。交換機及び勘定センターの両方においてユーザフォームが正しく機能することがテストで分かった後にのみ、それが能動的な使用状態に供される。
【図面の簡単な説明】
以下、添付図面を参照して本発明の好ましい実施形態を詳細に説明する。
図１は、勘定の原理を示す図である。
図２は、ＣＤＲのフォーマット化を示す図である。
図３は、本発明の実施の一部分を担うネットワーク要素を示す図である。
図４は、マザーフォームを示す図である。
図５は、ユーザフォームを示す図である。
図６は、ユーザフォームのフォーマット化を示す図である。
図７は、フォームを使用してＣＤＲをフォーマット化するところを示す図である。
好ましい実施形態の詳細な説明
図３は、加入者により交換機を経て行なわれる通話に関する加入者記録ＣＤＲを各々フォーマットする多数の電話交換機１、２…Ｎを備えたＰＳＴＮ又はＩＳＤＮネットワークのようなテレコミュニケーションネットワークを示す。参照番号４で示されたネットワークマネージメントシステムＮＭＳは、種々の交換機を制御することによりネットワーク管理に参加する。参照番号５で示された勘定センターＢＣは、異なる交換機から到着する通話詳細記録ＣＤＲを受け取り、それらを処理し、そして加入者に送付されるべき勘定書を作成する。個別のネットワーク管理が行なわれない場合には、交換機の制御及び構成は、リモートオペレーションを使用するのではなく、交換機自体において実行される。参照番号６は、本発明によりユーザフォームを形成するためにオペレータ／ユーザがマザーフォームを使用するところのプログラムを含む汎用コンピュータを示す。電話交換機の供給者は、自分の側で、マザーフォームを以下に述べるように形成する。
交換機の供給者は、当然、メッセージにおいて到達する生のデータ流の内容に関する厳密な情報を有している。メッセージの構造は、常に、同一であり、即ちメッセージのフィールド及びそれらのパラメータ（位置、長さ、形式、等）は、一定である。メッセージの形式は、メッセージを形成するときにどのフィールドが満たされるかを決定する。メッセージは常にその全体が送信され、従って、空いたままのフィールドに充填コードが満たされねばならない。従って、メッセージの形式は変化するが、メッセージ番号は同一のままである。メッセージ番号及びデータブロックの形式は、データ流において到達する。以下のテーブル１は、メッセージの内容を示す。
0003683593.tif 000005
メッセージは、「信号課金メッセージ」であり、その番号は０ｘ４５４３である。メッセージのデータ流は、異なる長さの次々のフィールドであり、例えば、位置０の第１フィールドはｓｅｑ＿ｎｕｍｂｅｒでありそしてその長さは１バイトであり、位置２の次のフィールドはｏｒｄｅｒ＿ｎｕｍｂｅｒでありそしてその長さはｎワードである。実際には、メッセージにフィールド名はなく、メッセージは、途切れなく且つ分離マークをもたない互いに前後のフィールドビットで構成される。しかしながら、各フィールドの位置は、フィールド位置及び長さが分かるときに明確に決定される。従って、例えば、第３フィールドのｃａｌｌ＿ｒｅｃｏｒｄ＿ｉｎｄ（位置３）の開始は、メッセージの開始からメッセージの２つの先行するフィールドのビット数、即ち１ワード及び１バイトだけ前方にジャンプすることにより見出される。この点から前方に、フィールドの長さで指示されたのと同数の第３フィールドのビットが流れに存在する。
交換機の供給者は、常に、ツールを有し、即ち位置及びフィールドデータとしてメッセージ構造を開放することのできるプログラムを有するので、このプログラム及び適当なウインドウズプログラムを使用してマザーフォームを形成することは容易である。ウインドウズプログラムは、所望のフォームのフォームヘッダ及びＣＤＲヘッダを有するフォームを形成するのに使用される。ヘッダは、平易な言語である。ヘッダの下に配置されるのは、フィールド名であり、ツールキットのようなフィールドデータが、メッセージからそれらを開放している。全てのフィールドは、マザーフォームに含まれる。しかしながら、フィールドの順序は、メッセージデータ流と同じである必要はない。ツールキットは、データ流においてメッセージフィールドとフィールドの内容との間のリンクとして機能する。
図４は、マザーフォームの形態を示す。このフォームの上部に見られるファイル名は、マザーフォームデータを含み、即ち一連の数字の最初の４桁４５４３は、フォームに関連したメッセージ番号を与え、そして次の３桁０００は、メッセージの形式を示す。文字Ｍは、フォームがマザーフォームであることを指示する。ピリオドの後の３桁は、マザーフォームのバージョン番号を示し、即ちメッセージが変更された場合には、当然、マザーフォームも変更され、従って、新たなバージョン番号をもつことになる。ファイル名に含まれたこのデータは、フォーム自体の部分ではなく、ウインドウズのプログラムによって表示される。
次の行のフォームヘッダは、メッセージ番号及び形式を指示する「フォーマット番号」、ここではＢＩＮであってフォームと共に形成されるＣＤＲのモードを指示する「出力モード」、及びフォーマットされるべきＣＤＲがどこにセーブされるかを指示する「出力デバイス」のフィールドを含む。記憶の場所は、例えば、ＶＤＳ即ち仮想ディスクシステムであるか又はＶＩＤＡＳＴであり、この場合には、数百のＣＤＲがディスクに収集され、次いで、クラスターとして勘定センターへ送信される。又、出力デバイスは、ＣＤＲがフォーマット化の直後に「ホットビリングシステム」に送信されることを決定してもよい。
次に、マザーフォームに基づいてフォーマットされるべきＣＤＲのヘッダ行に関連したデータが配置される。このデータは、ＣＤＲヘッダに関連し、「ヘッダフィールド名」、「形式」及び「ヘッダの長さ」のもとでグループ分けされる。従って、メッセージに存在しそしてツールキットで露呈される全てのヘッダフィールド及びそれらのデータはヘッダフィールド名の下に入る。この例では、記録長さｈｅａ＿ｒｅｃｏｒｄ＿ｌｅｎｇｔｈが第１のもので、その記録形式はＷ（ワード）でありそして長さは２ワードである。
これらの後に、メッセージ自体のＣＤＲのデータフィールドに関連したデータが入る。これは、「データフィールド名」、「形式」、「長さ」、「位置」及び「フォーマット」というヘッダのもとにグループ分けされる。メッセージに存在しそしてツールキットで露呈される全てのヘッダフィールド及びそれらのデータは、これらヘッダの下に入る。このフォームは、例えば、加入者Ａのフィールド、データ形式、長さ、位置（メッセージにおいて第２６番目のバイト）及びフォーマット（ＢＣＤコード化）を示す。このフォームの「フォーマット」欄において、フィールドの特徴が指示され、ＢＣＤは、２進コード化１０進を意味し、ＤＭはデータムである。これらの後に配置された数字は、フォーマット化プログラムに対する命令である。例えば、数字１は、２進コードデータをＢＣＤフォーマットに変換することを意味する。
従って、図４に示すマザーフォームは、各メッセージごとに形成される。ヘッダ及びデータフィールド並びにそれらのパラメータは、各フォームにおいて読み易い形態で且つ平易な言語で見ることができる。ワークステーションは、マザーフォーム上のフィールドから生のデータ流の正しい点へ至るリンクを形成することができる。
マザーフォームが電話交換機の供給者によってフォーマットされた後に、例えば、図３に示す電話交換機において、そのコピーがコンピュータからディスケットへ転送される。ディスケットのマザーフォームは、読み取り専用の形式であり、従って、いずれにせよ編集することはできない。これは、交換機の供給者がマザーフォームを作成してそれをオペレータに送付したときに、オペレータがマザーフォームを変更できないことを意味する。もちろん、供給者は変更することができる。
その後、ディスケットは、オペレータの勘定センター又はネットワークマネージメントユニットへ送られ、そして汎用コンピュータ、例えば、図３のコンピュータ６へ入れられる。このコンピュータは、ユーザフォームを形成するウインドウズベースのプログラムを有し、そのオペレーションについて以下に説明する。
図５に示すユーザフォームは、マザーフォームに非常に良く似たレイアウトを有する。従って、その上部のファイル名は、マザーフォームと同じデータを含み、即ち一連の数字の最初の４桁４５４３は、マザーフォーム、ひいては、ユーザフォームに関連したメッセージ番号を与え、そしてその次の３桁００３は、メッセージの形式を示す。文字Ｐは、フォームが受動的なフォームであることを示す。その意味については、以下で述べる。ピリオドの後の３桁は、ユーザフォームのバージョンを示し、即ちユーザは、いつでも新たなフォームを作成することができ、従って、新たなバージョン番号を有することができる。
次の行のフォームヘッダは、「フォーマット番号」、「出力モード」及び「出力デバイス」のフィールドを含み、このフォームでフォーマットされるべきＣＤＲがディスケットにセーブされることを示している。
これらに続いて、フォーマットされるべきＣＤＲの最初のヘッダ行に関連したデータ、即ち「ヘッダフィールド名」、「形式」及び「長さ」がある。ＣＤＲに含まれる適切なフィールドが、「データフィールド名」、「形式」、「長さ」、「位置」及び「フォーマット」の下に入れられる。
上記フォームヘッダ及びヘッダ行は、ユーザがプログラムを開始しそしてディスケットを読み取りステーションに押し込んだときにマザーフォームに基づいてユーザのコンピュータディスプレイに自動的に入れられる。フィールド名は、マザーフォームの場合と厳密に同じであり、変更もできないし、変更されてはならない。
図６は、ユーザがプログラムをスタートしそしてディスケットをワークステーションに押し込んだ後にユーザが見る表示を示す。この表示は、基本的なキーを伴う典型的なウインドウ表示である。その右側において、ディスケットは、全ての考えられるメッセージフィールドを含む図４のマザーフォームを与える。その左側は、図５のユーザフォームブランクである。ユーザは、希望するフィールドをマウスで選択しそしてそれらをユーザフォームへドラグして各フィールドヘッダの下にドロップするだけで、希望のフィールドをマザーフォームからピックアップする。従って、図示されたケースでは、ユーザは、マザーフォームのヘッダフィールドから最初の４つのフィールドを選択するが、データフィールドからは、加入者Ａのフィールドと、通話の開始時間及び終了時間を各々与えるフィールドのみを選択している。
ユーザは、ある場合には、フィールドのパラメータを選択することもできる。従って、例えば、図示された１６文字の加入者Ａフィールドの長さは、数字１６を数字８に置き換えることにより８文字に短縮することができる。
ユーザが希望のフォームを作成すると、それが、あるやり方又は別のやり方で図３の勘定センターのコンピュータ５及び交換機１へ転送されてセーブされる。フォームの上部のフィールド「顧客フォーム」は、受動的なフォームであることを意味する状態コードＰを含む。
セーブ動作はディスケットに行なわれ、ディスケットは、電話交換機のＯＭＵユニット（オペレーション＆メンテナンスユニット）及び勘定センターへ送付される。
又、セーブ動作は、ユーザフォームがファイル転送として転送されるか又はディスケットが図３のネットワークマネージメント４へ送付されるように行なわれてもよい。ユーザは、希望するときに、例えば、コンピュータ６の送信キーを押し、これにより、ネットワークマネージメントは、ユーザフォームを電話交換機及び勘定センターへ転送する。
ここで、ユーザフォームのテストを行うことができる。フォームが電話交換機及び勘定センターへ転送されると、そのとき進行中のＣＤＲのフォーマット化及び送信を妨げることなくテストが実行される。テストは、ネットワークマネージメントがテストされるべき受動的フォームの名前を与えそしてこのフォームがテストされることを交換機に通知するように行なわれる。次いで、ＭＭＬファンクションは、適切なメッセージ構造をもつテストデータ流を電話交換機に供給する。テストデータは、正しいメッセージの２進データに対応する２進ファイルであり、これは編集することができる。到来するテストデータ流から、フォーマットプロセスは、フォームに特定されたフィールドに対応するデータをピックアップし、そしてフォームに従ってＣＤＲをフォーマットする。ＣＤＲ自体の中で、フォーマットされたテストＣＤＲが勘定センターへ送信される。
テストＣＤＲは、それらが作成されたときに勘定センターへ送られるある長さのデータ待ち行列である。これは、交換機においてフォーマットプロセス中にテストデータ流から所望のデータが抽出されるフォームと全く同じユーザフォームをもつことができるので、インタープリターと同じフォームを使用することによりフィールド名を容易にフォーマットし、そしれそれらにデータ流からの厳密に正しいデータを付加することができる。その結果、勘定センターは、フォームに与えられたフィールド名と、その名前のもとにある正しい記録とをディスプレイに得ることができる。
勘定センターでテストＣＤＲと真のＣＤＲとを区別できるようにするために、テストフォームがＣＤＲにある分離子を形成し、これにより、勘定センターがテストＣＤＲの後処理を行なわないように構成される。もちろん、テストＣＤＲの後処理を行ってそれらの電話勘定書をフォーマットすることもできる。これは、テストフォームの正しいファンクションを最後まで確保できるという利点がある。テストＣＤＲにおける分離マークは、フォーマットされた電話勘定書がそれ以上送信されないように保証する。
テストにより全てが欠陥なく機能することが示されると、受動的状態（マークＰ）にあるフォームは、マークをＡ（能動的）に変更することにより受動的状態から能動的状態に変更される、つまり、アクチベートされる。このアクチベーションは、例えば、ウインドウズプログラムを用いて受動的フォームを停止しそして図６の「能動的フォーム」キーを押すことにより、ネットワークマネージメントで実行される。受動的から能動的への変更（アクチベ-ション）は、電話交換機において行なわれる。その際に、図２の通話詳細データ収集セーブプロセスは、直ちに、新たな能動的ユーザフォームを使用に供し、フォームのフィールドで指示された記録が存在するＣＤＲのフォーマットを開始する。フォーマットされたＣＤＲは、電話交換機によって勘定センターへ送信され、勘定センターは、同じフォームを使用して、データ流から正しい記録を抽出することができる。
電話交換機においてフォーマットされたＣＤＲに関して幾つかのチェックが行なわれる。第１に、記録からピックアップした通話終了時間と通話開始時間の差が通話の長さに等しくなるよう確保することにより最初のチェックを行うことができる。第２に、転送経路を経て電話交換機から勘定センターへ送信されるべきデータにＣＲＣチェック又は他の既知の転送保護が適用される。第３に、充分な長さの分離マークをフォームに追加して、フォーマットされたＣＤＲを互いに明確に区別できるようにする。
図７は、電話交換機におけるユーザフォームの使用を示す。受動的な状態にあるユーザフォームは、ＯＭＵにセーブされる。ファンクション７１において、ユーザは、希望するフォーム（１つ又は複数）を作成し、これらは、ディスケットに入れられて、電話交換機に送られるか、又は全ての交換機及び勘定センターに共通なネットワークマネージメントに送られる。ユーザは、テストを実行するためにＭＭＬコマンドが与えられることを要求する。
オペレータは、希望するＣＤＲを得るためにあるフォームを導入したいときに、プログラムの「能動的フォーム」キーを押し、これは、フォームをアクチベーションする要求をＭＭＬファンクションに与える。このコマンドは、ディレクトリーから希望のフォームをピックアップし、そしてそれを能動的にする（ファンクション７２）。同時に、勘定センターは、同じフォームを導入する。フォーマットプロセス７３は、所望のＣＤＲを作成し、これらは勘定センターへ送られる。
本発明によるフォームを使用すると、ＣＤＲを非常に柔軟に編集することができる。例えば、ＣＤＲに暗号コードのようなフィールドを追加することが所望されるときには、古いフォームを基本とみなし、それに暗号コードが追加される。ウインドウズのプログラムは、新たなフォーマット番号をもつフォームの新たなバージョンを発生する。新たなフォームは、電話交換機へ送信された後処理される。この時間中に、ＣＤＲには古いフォームが依存として満たされている。テストＣＤＲが送信されそして後処理の機能が勘定センターにおいて確保された後に、古いフォームが受動的にされると同時に新たなフォームがアクチベートされる。交換機は、暗号コードが存在しそして新たなフォーマット番号を保持するＣＤＲを直ちに形成する。かくて、フォーマットが進行中に交換される。
又、フォームの使用は、交換機の規格を引き上げる（これは交換機ソフトウェアの変更を意味する）ときに非常に便利である。従って、新たな規格に対応するように作成されて凍結されそして例えば４５４３０００Ｍ.１００をファイル名として有するマザーフォームが、コンピュータの新たなディレクトリーに取り込まれる。ここで、バージョン番号は、新たな１００番代に変更され、その第１の番号は１００である。次いで、新たな能動的なユーザフォームが同じディレクトリーにコピーされ、そして変換プログラムが実行されて、古いユーザフォームを、フィールドが新たな位置をもつ新たなメッセージに対応するように変換する。フィールド名は、サーチキーとして使用される。バージョンは、変換において、例えば、４５３４００３Ａ．００８→４５４３００３Ｐ．１０１のように変更され、そして同様に、フォーマット番号も、００３００８→００３１０１のように変化する。次いで、新たな受動的なフォームは、古い実行ソフトウェアを妨げることなく新たなソフトウェアのテストが行なわれる電話交換機のいわゆる試行側に送られると共に、後処理へと送られる。次いで、もしできれば、その試行側から新たなテストＣＤＲが送られ、そして後処理の機能が確保される。テストが完了すると、新たなフォームが試行側からアクチベートされ、そして切り換えが行なわれて、新たなフォームが使用されることになる。
個別のネットワークマネージメント及び勘定センターがネットワークに存在しない場合には、図３に参照番号７で示された個別の汎用コンピュータの助けによりユーザフォームが形成される。
本発明の機構は、フォーマットの変更を進行中に動的に行うことができ、そして後処理がその変更に直ちに同期されるという効果を有する。異なる要求に対して多数の異なるＣＤＲを形成することができ、従って、短いＣＤＲをフォーマットすることができる。テストＣＤＲを送信することにより正しい機能が確保される。フォームは、ＣＤＲのフォーマット化、転送及び解釈に関連した全てのデータを含む。ＣＤＲフォーマットは集中的に管理され、そして交換機の供給者及びオペレータの両方に同じグラフィックユーザインターフェイスが使用される。
【図１】
0003683593.tif 000006
【図２】
0003683593.tif 000007
【図３】
0003683593.tif 000008
【図４】
0003683593.tif 000009
【図５】
0003683593.tif 000010
【図６】
0003683593.tif 000011
【図７】
0003683593.tif 000012