JPH10505984A - 融通性のある呼出し記録機構 - Google Patents

Abstract

(57)【要約】 本発明は、好ましくはソフトウェアによる、電気通信システムでの融通性ある呼出し記録機構のための方法およびシステムに係わり、半呼出し原理を用いて上記システムの既に存在している主動作ソフトウェアに影響を与えずに上記システムを新たなサービスおよびデータで拡張することができるようにするにあたって、実行セッション呼出し処理で、各実行されるセッションに関連したレコードにメモリポインタ（ＰＴＲ）によってデータを記憶し、上記ポインタがタグエレメント（ＴＡＧ）と更に結合されるようにし、このタグエレメントによって局部的に記憶されたデータが特異に識別されるようになり、セッションの期間の間、選択的に呼び出されて後続の処理のため外部のデータベースに記憶されることができるようにされる。

Description

【発明の詳細な説明】 融通性のある呼出し記録機構 技術分野 本発明は電気通信システムにおける記録機構に関し、より詳細には電気通信に 適用するためのトラフィック制御プロセスにおいて必要なデータを容易に記録可 能とするデータ構成に関する。 発明の背景 電気通信システムにおいて呼出しの処理の間に、多量のデータを処理しあるい は収集する必要がある。このような呼出し関連データは、どのような種類のサー ビスが特定の呼出しで使用されるか、周辺のネットワークと通信を行うためにど のプロトコルが使用されるか等に依存して呼出し間で大きく異なる。データは電 気通信システムの異なった種類のユーザにとって有用な情報を含んでいる。ある ネットワーク／サービス提供者は料金請求のレコードを作ることを希望するかも しれないし、他方他の提供者は別の種類の統計を作ることを希望するかもしれな い。この売り手が、どのデータをユーザが使用したいかに無関係なるように希望 し、なおも既に存在しているソフトウェアを変える必要がなく新たなデータを新 たなサービスと共に加えることができるようにすることを希望する際には、この 呼出し関連データレコードは新たな効果的態様で処理される必要がある。 呼出し関連データを処理するための多くの可能な解決法が存在する。１つの明 かな態様は情報を収集するために既成のデータベースを用いることであるが、こ れはすぐに容量の問題に生じさせてしまう。他の解決法は内容の宣言がなされる （例えば、パスカルでレコードを比較する）ような宣言的な解決法を選択するこ とである。パスカルレコードとしての宣言的解決法の欠点は、それが所望の融通 性を持たないことである。更に他の解決法は、必要な時に対象の間でデータを回 して送ることであるが、これはデータを重複させることになる。 現在の技術状態において、現代の電気通信システムで処理を行うための目的指 向ソフトウェア構成に関する幾つかの概念が見い出される。「Stucture de 処理するため、特に電気通信システムのための論理的構成のシステムを記載して いる。この構成はＣＣＩＴＴ規則Ｘ２００に従って対象間の実時間通信を特に簡 d'informations」と題するＥＰ−０ ５２４ ０７７ Ａ１は応用プログラムに 対してハードウェアおよびソフトウェアシステムの特徴を隠す構成を記載してい る。 ＥＰ−０ ４７０ ４１５ Ａ２は、共通のデータベースにおいて呼出し関連 情報に対するアクセスを電話システムの多数の応用プロセッサに供給する方法を 記載している。情報は、通信が持続している限り、データベースにレコードとし て一時的にタグが付けられて記録される。特に、情報はオペレータ制御の交換シ ステムで観察のためにディスプレイ端末で直接表示されるように送られる。 発明の概要 従って、電気通信システムにおいて、半呼出し原理（half-call principle） を用いてシステムの既に存在している動作ソフトウェアに影響を与えることなく 新たなサービスおよびデータで上記電気通信システムを拡張することができるよ うにする呼出し記録機構を創設する要請が存在する。 本発明による第１の目的は、呼出し処理を実行するセッションにおいて、各実 行されるセッションに関連するレコードにメモリポインタによってデータの局部 的一時記憶を行わせることであり、このポインタはタグエレメントと更に結合さ れ、そのタグエレメントにより、局部的に記憶されたデータは特異に識別され、 １つのセッションの期間の間、レコード観察対象機能によって選択的に呼び出さ れかつ後続処理のためにデータベースに記憶されることができるようにすること である。 本発明による第２の目的は、特定のセッションがそのセッションでそれぞれ対 象（object）およびデータのポインタならびにタグを記憶するためのセッション レコードおよびトランザクションレコードを用いることであり、それらレコード から、所望のデータ情報を記憶させるために用いられるタグエレメントが既知で ある場合に、全ての対象およびデータをそのセッション内に置くことが可能とな るようにすることである。 本発明による第３の目的は、呼出し処理において、セッション範囲と同様の構 成を有するトラフィックケース範囲が定められ、トラフィックケースレコードが ある呼出しの実行対象を記憶するために上記セッションから作られて参照され、 更にトラフィックケースレコードにおいては上記トラフィックケースに属するデ ータを記憶するトランザクションレコードが存在するようにすることである。 本発明による第４の目的は、実在する管理システムと干渉せずに局部データベ ースに記憶されるタグリストの簡単な変更でサービスが任意の時間で変えられる ことができるようにすることにある。 本発明による第５の目的は、１つのセッションで使用される各実行対象（obje ct）あるいはデータ対象（object）に特異に割当てられる整数によって、好まし くは２進語としてタグエレメントが実現されるようにすることである。 図面の簡単な説明 本発明は、その一層の目的および長所と共に、以下の記載を次の添付図面と共 に参照することによってより良く理解されるであろう。 第１図は、各トラフィックケースに対してそれぞれの開始呼出しＯＣ（それぞ れの最終呼出しＴＣを含んだ他のトラフィックケースと通信状態にある）を含ん でいる幾つかのトラフィックケースを取り扱うセッション制御器ＳＣを有する１ つのセッションを示す。 第２図は、本発明の方法およびシステム従って、実行対象への参照を記憶する セッションレコードとデータ対象に対する参照を記憶するトランザクションレコ ードを用いてセッション制御器ＳＣを示す。 第３図は、開始呼出しＯＣ内にトラフィックケース対象を記憶する、本発明の 方法およびシステムによる収集を示す。 第４図は１つのセッションにおいてデータフローを制御する対象を示す。 第５図は充填基準（charging basis）のためのデータが１つのセッションから 抽出される時の例を示す。 第６図は作られた被管理対象間の関係を単純な例で示す。 第７図は第６図の単純な例による完全な静的な図を示す。 第８図は呼出し処理の間でのトランザクションレコードにおける呼出しデータ 収集の簡単な流れ図である。 第９図は出力に含まれるデータの加工の簡単な流れ図である。 原理 本願の主題を効果的な態様で取り扱うことができるようにするために、最初に 、以下の記載全体にわたって有用な多数の技術的用語を定義することが実際的で あろう。 電話用の呼出し処理交換システムにおいてソフトウェアを構成化する普通の態 様は呼出しの制御を２つの半部、半呼出しＡ（Half-Call A）および半呼出しＢ （Half-Call B）に分割することである。半呼出しを制御するソフトウェアはセ ッション（Session）と呼ばれる処理において実行している。セッションは１つ あるいは幾つかのトラフィックケース（Traffic Cases）を同時に取り扱うこと ができる（例えば、多数の呼出しの状態で）。このトラフィックケースはセッシ ョンでの呼出しを取り扱う機能性とデータとを定める。１つの３当事者呼出しは セッションで２つのトラフィックケースによって取り扱われる（その１つが各呼 出し分枝に対応する）ことも留意すべき事項である。 簡略化のために、セッションは異った範囲で構成され、従ってセッション範囲 （Session Scope）およびトラフィックケース範囲（Traffic Case Scope）が導 入される。セッション範囲はベースフローセッション制御器（Baseflow Session Controller ）ＳＣによって制御される。セッション制御器の主たるタスクはア クセスプロトコルに対するコマンドインタープリタとして働き、これらコマンド （メッセージ）についてサービス分析を行うことである。この時に、これは、例 えば、新たなトラフィックケースを開始しかつ終了すること、アクセスプロトコ ルから正しいトラフィックケースへ情報を分配すること、新たなサービスを開始 すること等を含んでいる。 セッション内のあらゆるトラフィックケースは１つのベースフローによって制 御される。このようなベースフローは開始呼出し（Originatiog Call）ＯＣある いは最終呼出しＴＣ（Terminating Call）のいずれかであってもよい。このベー スフローの主たるタスクは基本的呼出しの取扱を行うことである。これは、例え ば、呼出しを設定／接続解除すること（半呼出し間での電気通信サービスプロト コル（Telecommunication Service Protocol）ＴＳＰの取扱を含む）、接続（例 えば、会話接続）の設定／接続解除を指令することおよびアドレス情報分析を指 令すること等を含んでいる。 種々の範囲およびこれらの中で動作する制御ロジックを支援するために、同様 のデータ構成である必要がある。従って、データはアプリケーションを構築でき 維持できるようにするためにある態様で構成されなければならない。これに対応 して、２つの異った形式の対象（本記載で、実行対象（Executing Object）およ びデータ対象（Date Object）として言及される）が存在する。 実行対象（executing object）はセッションで実行され、例えば制御対象、プ ロトコル対象、リソース対象等である。純粋なデータ対象は、例えばテレサービ スプロトコルメッセージから受信されたデータを含む。充填あるいは統計的な目 的のためのこの形式のデータの出力を行わせることもできなければならない。こ れら２つの形式の対象は異った意味を有しており、セッションの異ったレコード に記憶される。このようなレコードはセッションレコード（Session Record）と して言及され、セッション内の制御およびリソース対象の実例とされるプロトコ ル対象およびリソース対象に対するポインタを記憶するために使用される。セッ ションレコードに記憶される対象は全部のセッションにとって共通である。純粋 なデータ対象に対する参照を記憶するためトランザクションレコード（Transact ion Record ）が使用される。対象に対するポインタを記憶するセッションレコー ドと類似した態様で、トランザクションレコード（呼出しレコードとも呼ばれる ）はそのセッションあるいはそのセッションで実行するトラフィックケース内の 制御、プロトコルおよびリソース対象の実例とされる純粋なデータ対象に対する ポインタを記憶するために使用される。 セッションレコードのユーザ観察はセッションレコード観察（Session Record View ）と言及され、高い抽象レベルでのセッションレコードへのインターフェ ースをユーザに与える。同様に、トランザクションレコードのユーザ観察はトラ ンザクションレコード観察（Transactoion Record View）として言及され、高い 抽象レベルでのトランザクションレコードへのインターフェースをユーザに与え る。 最後に、トラフィックケースレコード（Traffic Case Record）もあり、これ はトラフィックケースに所属する対象に対するポインタが記憶されるようなレコ ードである。プロトコル対象およびリソース対象に対するポインタだけがこのレ コードに記憶される。純粋なデータ対象を記憶するため、トランザクションレコ ードが使用されなければならない。トラフィックケースレコードのユーザ観察は トラフィックケースレコード観察と言及され、高い抽象レベルでのセッションレ コードに対するインターフェースをユーザに与える。 好適実施例の詳細な説明 電気通信システムにおける呼出し記録機構のための種々の範囲および対応する 制御ロジックを支援するために、好ましいデータ構成を必要とする。データはア プリケーションを構築できかつそれを維持できるように構成されなければならな い。従って、セッションで状況の把握のために、それぞれ実行対象およびデータ 対象といった２つの異った形式の対象が導入される。上述のように既に定義した これら２つの用語は異った意味を有し、作られたセッションの異ったレコードに 記憶される。ある対象を集合状態で記憶する時に、記憶されるべき対象に対する ポインタを記憶することがただ１つの問題で、従って対象それ自体の重複化はこ のような段階では行われない。これは、また、このようなポインタ記憶に対して 、特定の対象のサイズを実際には知る必要がないということを意味する。 第１図は、セッション制御器ＳＣによって制御されるセッション範囲の一般化 した図である。セッション制御器はアクセスプロトコルＡＣＰに対してコマンド インタープリタとして働いており、これは加入者あるいはネットワークアクセス に対して使用される一般的な用語である。第１図から明らかなように、セッショ ンは１つあるいは幾つかのトラフィックケースを含んでおり、ここでは、この特 定のセッションは共にＯＣ（開始呼出し）形である２つのトラフィックケースを 含んでいる。形式ＯＣの２つのトラフィックケースのそれぞれは取扱電気通信サ ービスプロトコルＴＳＰを介した形式ＴＣ（最終呼出し）の他のトラフィックケ ースへのそれぞれのトラフィックケースによって設定される。 第２図に示されるように、セッション範囲にはセッションレコードＳＲがあり 、これは各実行対象、例えばいわゆるセッションエージェントに対するポインタ ＰＴＲを記憶するために使用される必要がある。セッションレコードは、他のポ インタによる、各セッションでのデータ構成のための基礎となる。全部のセッシ ョンのデータ対象はトランザクションレコードにおいてそれらそれぞれのポイン タＰＴＲによって見い出される。セッションレコードの各エントリーは特定の名 前あるいはキーＴＡＧを持っており、これにより特定のシステムオペレータがそ の特定の名前あるいはキーＴＡＧを知れば任意の対象をそのセッション範囲内に 置くことができるようになる。 第３図は、開始呼出し形式ＯＣを含んではいるが、最終呼出し形式ＴＣが対応 する構成を有しているようなトランザクションケース範囲の一般化した図である 。この範囲は、アプリケーションがセッションにおいて任意数の並列のトラフィ ックケースを実行する必要がある場合に導入されなければならない。従って、こ のトラフィックケース範囲の構成はセッション範囲のものと類似している。セッ ションの各トラフィックケースに対して、実行対象を記憶するためのトラフィッ クケースレコードが作られる。セッションレコードの場合と同様に、名前あるい はＴＡＧとポインタＰＴＲとが用いられる。トラフィックケースレコードはこれ に従ってセッションレコードから参照される。従って、トラフィックケースに属 するデータ対象を記憶するために、このトラフィックケースレベルでデータ対象 のためのテーブルを作るトランザクションレコードが使用される。 セッションあるいはトラフィックケースレコードのあらゆるユーザは自身の観 察対象を有し、それにより記憶された実行対象あるいはデータ対象がアクセス可 能となる。 第４図は開始呼出しＯＣを実行するセッションによるデータの流れをより詳細 に示す。このデータの流れは、あるデータがアクセスエージェントあるいは入力 エージェントによって受けられると開始する。この受信されたデータはＡＸＥ内 部表記状態に変換される。次いで、変換されたデータはトランザクションレコー ドＴＲに記憶される。データ対象はタグと共に記録される。このタグはこの特定 のデータ対象に対して予約される整数である。データ対象を必要とする他のユー ザ、例えばアプリケーション分析はタグによっておよびトランザクションレコー ド観察対象ＴＲ Ｖｉｅｗを使用することによってトランザクションレコードか らそれをフェッチすることができる。上記の例は、また、電気通信サービスプロ トコルＴＳＰを介してデータが出力エージェントにより他の半呼出しにいつ送ら れるかを示す。データはそれを識別するタグをデータの外に含んだパラメータで 送られる。 上述したように、データ対象はトランザクションレコード（トランザクション レコードの同意語も呼出しレコードである）に記憶される。トランザクションレ コードＴＲは、既に述べたように、観察対象により常にアクセスされる。観察対 象は、以下に更に詳細に記載されるように、ＴＲに対する高レベルインターフェ ースをユーザに与える。トランザクションレコードに記憶される各データ対象は ＴＡＧ（タグ）として言及される名前あるいはキーによって意味的に識別される 。ＴＡＧは、１つの特定のデータ対象に対して予約されている整数、例示の実施 例においては１６ビット語である。データ対象がタグと共に記憶されるようなト ランザクションレコードといったダイナミック記憶装置を用いることにより、極 めて融通性のある出力機構を支援することが可能となる。換言すれば、電気通信 システムの一般的な動作に影響を与えずに、任意の特定の時間期間で、後の分析 のためのユーザの要求に応じて任意の選択されたデータ対象を抽出することが極 めて容易になる。この結果、このような構成化した動作態様に従って動作するシ ステムに付加的なサービスを加えることが極めて容易になる。 エージェントがプロトコルＡＣＰでパラメータ「発呼者番号」を受けるものと 想定する。データはＡＸＥ内部表記状態に変換され、専用タグ“AppCallingPart yNumberTag”と共にＴＲに記憶される。呼出し当事者番号を必要とするＴＲの他 のユーザは、この時にＴＲを参照して、ＴＡＧ“AppCallingPartyNumberTag”と 共に記憶されたデータ対象を参照することができる。インターフェース、アプリ ケーションインターフェースプラットホームタグインターフェースＡＴＩはこの 機能によって使用されるタグの番号を含んでいる。また、ＡＴＩは、新たなタグ が予約された時に従うべき規則を含んでいる。 上述したように、ＴＲは観察対象により常にアクセスされる。この観察対象は ２つの主たるタスクを有している。第１のタスクはＴＲに向けてカストマイズし たインターフェースを与えることである。ＴＲの各ユーザはＴＲの内容に対して 専用化したインターフェースを持たなければならない。第２のタスクはＴＲに向 けて取扱対象として働くようにすることであり、この取扱によりＴＲは全ての取 扱が抹消されるまで取り除かれ得ないようにされる。 観察対象は、また、存在する他の２つの形式のレコード、セッションレコード およびトラフィックケースレコードの内容をアクセスするためにも使用される。 上述したように、観察対象の１つのタスクはあるレコードに向けて高い抽象レベ ルでのカストマイズされたインターフェースをユーザに与えることである。この カストマイズとは、インターフェースがアクセスされなければならない対象だけ に対するアクセスをユーザに与えることを意味し、これはレコードの全部の内容 の一部分であってもよい。 トランザクションレコードおよびトラフィックケースレコードに向ける観察対 象の第２の主たるタスクはそれらがある取扱を行うことである。レコードがある 取扱を持っている限り、それは抹消され得ない。レコードに向かっての最後の取 扱が取り除かれる時には、そのレコードおよび全てのその内容も局部的メモリ記 憶装置から取り除かれる。これは極めて便利な局部的メモリ記憶管理を与えるこ とが明かである。 既に述べた呼出し記録出力機構は後の処理のためトランザクションレコードの 内容の部分を出力するために使用される。セッションレコード、トラフィックケ ースレコードおよびトランザクションレコードの内容は特定のセッションの期間 の間でのみ存在し、セッションが終了すると消失することに留意すべきである。 出力機構はタグリストを含んだ多数の被管理対象の周りに作られる。電気通信シ ステムの動作にあって、例えば、種々の加入者に正しく料金請求を行うことがで きるように変化するデータを収集する必要がある。第５図はセッションで何が行 われるかの例である。制御対象「充填（charging）」は対象“Ｃｒｏ Ｔｙｐｅ ”を開いている。この特定のＣｒｏ Ｔｙｐｅ対象はデータベースからフェッチ されたタグリストを含み、これはトランザクションレコードから抽出されるべき データ対象を示す。Ｃｒｏ Ｔｙｐｅは、次いで、データベースに記憶されてい る タグリストによって識別されるデータ対象を構成するレポートをコンパイルする ように指令される。この時に、制御対象は特定のセッションの存在の間にデータ を収集するように指令するためにＣｒｏ Ｔｙｐｅインターフェースを用いる。 データはデータ域においてパックされてもよく、次いでこれは後続処理のノード に送られる。従って、増大させたサービスによる充填基準は、本発明による構成 を有する実在のシステムとの干渉が全く無く、タグリストの簡単な変更によりい つでも変化させられることができる。 この効果的な結果は、異ったセッションの内容が局部データとして定められて いるとしても、それがあたかも大域データを構成するように内容の所望の部分を 同時に使用させ得るようにされることである。局部および大域データ間の差は、 例えば、後者が、強制的に、他のユーザによってアクセスされることができるよ うに所定のメモリ位置に通常割り当てられなければならないことである。 図示された実施例において、ここに記載される融通性ある出力機構を効果的に するために３つの形式の被管理対象が使用される。それらはCroServiceTemplate 、CroType およびCroCustomerTemplate として表される。第１の被管理対象形式 すなわちCroServiceTemplateは、どのようなデータ対象が特定の基本的あるいは 補充的サービスのため抽出され得るかの指定のために使用される。 CroServiceTemplateは、特定のサービスのためのトランザクションレコードＴＲ からどのデータを抽出できるか（例えば、この場合「基本的呼出し（Basic Call ）」あるいは「３当事者呼出し(Three Party Call)」）を表す１つの属性、でき るならばＴＡＧを含んでいる。 第２の被管理対象形式はCroType であり、これはある出力形式の指定のために 使用される。CroType のあらゆる例がCroServiceTemplateの１つあるいはそれ以 上の例に接続される。これらのCroServiceTemplateにおけるデータの集合は特定 の相互形式のためにどのようなデータを出力するかを決定する。 第３の最後の管理対象形式はCroCustomerTemplate であり、これは特定の出力 形式、CroType の中からある特定の顧客に対してどのデータを抽出するかの情報 を保持する被管理対象である。 第６図は以下の条件を有する小さな例を示す。 −２つの顧客ＡおよびＢがある。 −２つのサービス、「基本的呼出し」および「３当事者呼出し」がある。 −２つのCroType 、すなわちCroType １およびCroType ２がある。 ２つのサービスが存在するために、以下の２つのCroServiceTemplateが必要で ある。 −タグ１、２、５および８を含んだCroServiceTemplateの基本的呼出し。 −タグ１、２、６および９を含んだCroServiceTemplateの３当事者呼出し。 これは、「基本的呼出し」に対してはタグ１、２、５および８を有するＴＲに 記憶されたデータを出力でき、他方サービス「３当事者呼出し」に対してはタグ １、２、６および９の下で記憶されたデータを出力できることを意味する。 次いで、両サービスに関連したデータを出力することができることを表すCroT ype １と基本的呼出しに関連したデータを出力することができることを表すCroT ype ２との２つの出力形式を定める。第６図には基本的構成と作られた被管理対 象間の関係とが図示されている。 １つのCroCustomerTemplate が、出力機構「呼出しレコード出力」ＣＲＯが全 ての顧客に対して全てのCroType の出力を行うことができるようにするために各 顧客およびCroType のために必要とされる。この結果この例は全部で４つのCroC ustomerTemplate となる。第７図はその結果の構成を示す。顧客Ａは相互形式１ から全ての可能なタグをまた相互形式２からタグ番号１および２を要求し、顧客 Ｂは全ての相互形式から８よりも下位の番号の全てのタグを要求する。次いで、 出力機構ＣＲＯが適切な分配を行うために必要な最終的な構成が与えられる。全 ての異った顧客がどのデータフィールドを全ての異った相互形式から必要とする かが特定される。 第４図のデータの流れの最後の部分はデータがいつ他の半呼出しに送られるべ きかを表す。半呼出しは電気通信サービスプロトコルＴＳＰにより通信を行う。 ＴＳＰは自己識別を行うパラメータを保持している。１つのパラメータは１つの データ対象を含んでおり、タグによって識別される。受信機はこのタグを見るこ とによってどのデータが受信されたかを決定することができる。ＴＳＰのパラメ ータを識別するために使用されるタグは記憶されるデータを識別するために使用 されるものと同じタグてある。 第８図は呼出し処理の間のトランザクションレコードにおける呼出しデータ収 集の簡単な流れ図の多数のステップを概略的に示す。このような処理はステップ １００で始まる。この処理の最初の実際のステップ１０１において、外部のプロ トコルでメッセージが受信される。それはシステム内の動的処理内でのプロトコ ルエージェントにおいて受けられる。次に、ステップ１０２で、データは外部表 記状態から内部表記状態に変換される。データ対象はこの処理内で作られる。 この時に、このデータ対象は受信データの内部表記状態を含んでいる。 第３のステップ１０３において、データ対象はトランザクションレコードに特 異なタグエレメントの下で記憶される。呼出し処理の間に、第４のステップ１０ ４で、トランザクションレコード観察対象を用いて、次いでこの特定のデータを 回復するための正しいポインタを得るためのタグエレメントを用いてトランザク ションレコードからデータがフェッチされる。 呼出しが終わるか、あるいは呼出しデータの出力が統計的あるいは充填的な目 的で望まれる時に、機能呼出しレコード出力が第５のステップ１０５で呼び出さ れる。この機能はどのデータを出力すべきかを見い出すためにデータベースをア クセスする。この結果、この機能はタグエレメントのリストを得る。望まれたデ ータはステップ１０４でＴＲから収集され、出力バッファに置かれる。次いで、 このバッファは外部の媒体に出力されてもよい。後に、データは、例えば料金請 求情報等を生じさせるために後続の処理を受けてもよい。 最後に、第９図には、３つのステップによって、出力に含まれるべきデータの 指定についての簡単な流れ図が示されている。手順はステップ２００で始まる。 ステップ２０１で、サービス提供者あるいはシステムを管理する他のオペレータ は異った呼出し形式に対してどのデータを出力すべきかを決定する。これらの種 種の出力形式は、第２のステップ２０２において、テンプレートにタグのリスト を埋めて出力することによって特定される。最後のステップ２０３において、こ れらのテンプレートは、例えば分離した端末および／またはキーボードによって タグのリストを入力することによってデータベースに記憶される。これら入力さ れたタグのリストは呼出し処理の間に後にアクセスされる。タグのリストのこの ような入力は、トラフィックケースを開始および終了し、アクセスプロトコルか ら正しいトラフィックケースへ情報を分配し、新たなサービスを開始させる等の 電気通信システムの一般的な呼出し処理とは干渉しないが、入力時にそれは後続 の処理のためどのデータがデータベースに記憶されるべきかを決定する。 請求の範囲によって定められる本発明の精神および範囲から逸脱することなく 種々の変更および変化が本発明に対してなされ得るということは当業者によって 理解されるであろう。

Claims (1)

1. 【特許請求の範囲】 １．半呼出し原理を用いて電話システムあるいは電気通信システムの既に存在 している主動作ソフトウェアに影響を与えずに上記システムを新たなサービスお よびデータで拡張することができるようにする、上記システムにおける呼出記録 機構のための方法であって、セッション呼出し処理の実行時に、データの局部的 な一時的記憶が各実行されるセッションに関連したレコード（ＳＲ、ＴＲ）にメ モリポインタ（ＰＴＲ）によって行われ、上記ポインタ（ＰＴＲ）はタグエレメ ント（ＴＡＧ）と更に結合され、このタグエレメントによって特定の所望される 局部的に記憶されたデータは特異に識別されるようになり、セッションの期間の 間、レコード観察対象機能によって選択的に呼び出され、引続いて後続の処理の ため外部のデータベースに記憶されることができるようにしたことを特徴とする 方法。 ２．請求の範囲第１項記載の方法において、上記特定のセッションはこのセッ ションにそれぞれ対象およびデータのポインタ（ＰＴＲ）ならびにタグ（ＴＡＧ ）を記憶するためのセッションレコード（ＳＲ）およびトランザクションレコー ド（ＴＲ）を使用し、それらレコードから、上記セッションの存在の間に、所望 のデータ情報を記憶させるようにするタグエレメント（ＴＡＧ）が既知である場 合に、上記セッション内の任意の対象あるいはデータを抽出できるようにしたこ とを特徴とする方法。 ３．請求の範囲第２項記載の方法において、呼出し処理で、セッション範囲と 類似する構成を有するトラフィックケース範囲が定められ、トラフィックケース レコードは上記セッションレコード（ＳＲ）から参照され、トラフィックケース レコードが呼出しの実行対象を記憶するように作られるようにしたことを特徴と する方法。 ４．請求の範囲第２項記載の方法において、上記トラフィックケースレコード に、トランザクションレコード（ＴＲ）は上記トラフィックケースに属するデー タを記憶するようにしたことを特徴とする方法。 ５．請求の範囲第４項記載の方法において、現存する動作管理システムに干渉 することなく局部データベースに記憶されるタグリストの簡単な変更によってサ ービスが変えられることができるようにしたことを特徴とする方法。 ６．請求の範囲第５項記載の方法において、上記タグエレメント（ＴＡＧ）は 、記憶されるべき各実行対象あるいはデータ対象に特異に割り当てられた整数、 好ましくは２進語によって実現されるようにしたことを特徴とする方法。 ７．半呼出し原理を用いて電話システムあるいは電気通信システムの既に存在 している主動作ソフトウェアに影響を与えずに上記システムを新たなサービスお よびデータで拡張することができるようにする、上記システムのための呼出し記 録機構であって、局部的かつ一時的に記憶されたセッション対象あるいはデータ が、実行する呼出し処理において各実行されるセッションに関連したレコードに メモリポインタ（ＰＴＲ）によって記録され、上記ポインタ（ＰＴＲ）はタグエ レメント（ＴＡＧ）と更に結合され、このタグエレメントによって特定の所望さ れる一時的にかつ局部的に記憶されたデータは特異に識別されるようになり、セ ッションの期間の間、レコード観察対象機能によって選択的に呼び出され、引続 いて後続の処理のため外部のデータベースに記憶されることができるようにした ことを特徴とする呼出し記録機構。 ８．請求の範囲第７項記載のシステムにおいて、上記特定のセッションはこの セッションにそれぞれ対象およびデータのポインタ（ＰＴＲ）ならびにタグ（Ｔ ＡＧ）を記憶するためのセッションレコード（ＳＲ）およびトランザクションレ コード（ＴＲ）を使用し、それらレコードから、上記セッションの存在の間に、 所望のデータ情報を記憶させるようにするタグエレメント（ＴＡＧ）が既知であ る場合に、上記セッション内の任意の対象あるいはデータを抽出できるようにし たことを特徴とするシステム。 ９．請求の範囲第８項記載のシステムにおいて、トラフィックケース範囲はセ ッション範囲と類似する構成を有し、トラフィックケースレコードは上記セッシ ョンレコードから参照され、上記トラフィックケースレコードが呼出しの実行対 象を記憶するように作られるようにしたことを特徴とするシステム。 10．請求の範囲第９項記載のシステムにおいて、上記トラフィックケースレコ ードに、トランザクションレコード（ＴＲ）は上記トラフィックケースに属する データを記憶するようにしたことを特徴とするシステム。 11．請求の範囲第１０項記載のシステムにおいて、現存する動作管理システム に干渉することなく局部データベースに記憶されるタグリストの簡単な変更によ ってサービスが変えられることができるようにしたことを特徴とするシステム。 12．請求の範囲第１１項記載のシステムにおいて、上記タグエレメント（ＴＡ Ｇ）は、記憶されるべき各実行対象あるいはデータ対象に特異に割り当てられた 整数、好ましくは２進語によって実現されるようにしたことを特徴とするシステ ム。