JPH03214851A - インテリジェント・ネットワークにおけるデータベース管理方式 - Google Patents
インテリジェント・ネットワークにおけるデータベース管理方式Info
- Publication number
- JPH03214851A JPH03214851A JP2008415A JP841590A JPH03214851A JP H03214851 A JPH03214851 A JP H03214851A JP 2008415 A JP2008415 A JP 2008415A JP 841590 A JP841590 A JP 841590A JP H03214851 A JPH03214851 A JP H03214851A
- Authority
- JP
- Japan
- Prior art keywords
- processing
- service
- database
- request
- module
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q3/00—Selecting arrangements
- H04Q3/0016—Arrangements providing connection between exchanges
- H04Q3/0029—Provisions for intelligent networking
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q3/00—Selecting arrangements
- H04Q3/0016—Arrangements providing connection between exchanges
- H04Q3/0062—Provisions for network management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
- H04Q2213/13547—Indexing scheme relating to selecting arrangements in general and for multiplex systems subscriber, e.g. profile, database, database access
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Stored Programmes (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Telephonic Communication Services (AREA)
Abstract
(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。
め要約のデータは記録されません。
Description
【発明の詳細な説明】
〔概 要〕
インテリジェン1・・ネットワークにおけるデータベー
ス管理方弐に関し、 通信網において、データベースの構造を意識せずにサー
ビス・アプリケーション・プログラムを開発できるよう
にすることを目的とし、複数のサービス実行手段を有す
るインテリジェント・ネソトワークにおいて、発加入者
からのサービス要求メッセージに基づいてデータベース
処理依頼要求を出力する翻訳モジュールと、該翻訳モジ
ュールからのデータベース処理依頼要求に基づいて、デ
ータベースのアクセスと前記複数のサービス実行手段に
対するサービス処理依頼要求を行・うと共に、該サービ
ス実行手段からのデータベース処理依頼要求に基づいて
データベースへのアクセスを行うデータベース処理モジ
ュールと、前記サービス実行手段からの出力処理依頼要
求に基づいて通信網へのメッセージの出力を行う出力処
理モジュールとを有し、前記各モジュール間及び各モジ
ュールとサービス実行手段間のそれぞれの処理依軌要求
を、共通化したデータフォーマットに基づいて行うよう
に構成する。
ス管理方弐に関し、 通信網において、データベースの構造を意識せずにサー
ビス・アプリケーション・プログラムを開発できるよう
にすることを目的とし、複数のサービス実行手段を有す
るインテリジェント・ネソトワークにおいて、発加入者
からのサービス要求メッセージに基づいてデータベース
処理依頼要求を出力する翻訳モジュールと、該翻訳モジ
ュールからのデータベース処理依頼要求に基づいて、デ
ータベースのアクセスと前記複数のサービス実行手段に
対するサービス処理依頼要求を行・うと共に、該サービ
ス実行手段からのデータベース処理依頼要求に基づいて
データベースへのアクセスを行うデータベース処理モジ
ュールと、前記サービス実行手段からの出力処理依頼要
求に基づいて通信網へのメッセージの出力を行う出力処
理モジュールとを有し、前記各モジュール間及び各モジ
ュールとサービス実行手段間のそれぞれの処理依軌要求
を、共通化したデータフォーマットに基づいて行うよう
に構成する。
(産業上の利用分野〕
本発明は、インテリジェント・ネットワークにおけるデ
ータベース管理方式に関する。
ータベース管理方式に関する。
電話網などにおいては、着信課金、3者通話、電話会議
などの種々のサービスがユーザに提供されている。
などの種々のサービスがユーザに提供されている。
一IIQに、これらのサービスを実現するサービスアプ
リケーション・プログラムは、それらのサービスに使用
するデータベースと共に交換局内に設置されている。
リケーション・プログラムは、それらのサービスに使用
するデータベースと共に交換局内に設置されている。
最近、これらのサービス・アプリケーション・プログラ
ムを、交換処理と分離し網内の一点で集中管理すること
が考えられており、これを実現する通信網をインテリジ
ェント・ネットワークと呼んでいる。これは、従来、交
換局の交換機の機種に依存して作成さているサービス・
アプリケーション・プログラムを、交換機の機種に依存
せず交換網の運用者等が自由に作成できる機能を実現す
ることを目的としている。
ムを、交換処理と分離し網内の一点で集中管理すること
が考えられており、これを実現する通信網をインテリジ
ェント・ネットワークと呼んでいる。これは、従来、交
換局の交換機の機種に依存して作成さているサービス・
アプリケーション・プログラムを、交換機の機種に依存
せず交換網の運用者等が自由に作成できる機能を実現す
ることを目的としている。
第20図は、インテリジェント・ネットワークの構成の
一例を示す図である。
一例を示す図である。
S S P (Service Swit.ching
Point) i Iは、端末間の接続制御等を行う
交換機であり、各SSP11は信号網を介してS C
P (Service ControlPoinL)
1 2に接続されている。このSCP l 2内にサー
ビス処理を行うアプリケーション・プログラムとデータ
ベースとを集中させて、加入者からのサービス要求を処
理することをめざしている。
Point) i Iは、端末間の接続制御等を行う
交換機であり、各SSP11は信号網を介してS C
P (Service ControlPoinL)
1 2に接続されている。このSCP l 2内にサー
ビス処理を行うアプリケーション・プログラムとデータ
ベースとを集中させて、加入者からのサービス要求を処
理することをめざしている。
[発明が解決しようとする課題〕
しかしながら、現状ではデータベースの集中化が図られ
た程度で、交換網の運用者が新規のサービス・アプリケ
ーション・プログラムを自由に作成できるようにはなっ
ていない。その理由は、サービス・アプリケーショウ・
プログラムとデータベース管理機能が密に結合されてい
る為に、アプリケーション・プログラムの開発には、デ
ータベースの構造等を充分に熟知する必要があり、特殊
なノウハウと膨大な開発工数が必要になるからである。
た程度で、交換網の運用者が新規のサービス・アプリケ
ーション・プログラムを自由に作成できるようにはなっ
ていない。その理由は、サービス・アプリケーショウ・
プログラムとデータベース管理機能が密に結合されてい
る為に、アプリケーション・プログラムの開発には、デ
ータベースの構造等を充分に熟知する必要があり、特殊
なノウハウと膨大な開発工数が必要になるからである。
また、電話網等のユーザに提供している複数のサービス
は、全てが同時に起動できるわけではなく、それのサー
ビスの中には、何れかを優先させて起動するるサービス
、あるいは同時に起動できないサービス等がある。
は、全てが同時に起動できるわけではなく、それのサー
ビスの中には、何れかを優先させて起動するるサービス
、あるいは同時に起動できないサービス等がある。
そこで、同じ発加入者から複数のサービス要求があった
場合には、各サービス間の相互規制の有無をチェックす
る必要がある。
場合には、各サービス間の相互規制の有無をチェックす
る必要がある。
このチェックは、それぞれのアプリケーション・プログ
ラムの中で行われており、新規のアプリケーション・プ
ログラムを作成すると、既存のアプリケーション・プロ
グラムを変更する必要が生じる。これがプログラムの開
発効率を低下させる原因となっている。
ラムの中で行われており、新規のアプリケーション・プ
ログラムを作成すると、既存のアプリケーション・プロ
グラムを変更する必要が生じる。これがプログラムの開
発効率を低下させる原因となっている。
本発明は、通信網において、データベースの構造を意識
せずにサービス・アプリケーション・プログラムを開発
できるようにすることを目的とする。
せずにサービス・アプリケーション・プログラムを開発
できるようにすることを目的とする。
第1図は、本発明の原理説明図である。
複数のサービス実行千段5を有するインテリジェント・
ネ・冫トワークにおいて、 翻訳モジュール1は、発加入者からのサービス要求メッ
セージ2を解析し、そのサービス要求メッセージ2に基
づいてデータベース処理依頼要求3を作成する。
ネ・冫トワークにおいて、 翻訳モジュール1は、発加入者からのサービス要求メッ
セージ2を解析し、そのサービス要求メッセージ2に基
づいてデータベース処理依頼要求3を作成する。
データベース処理モジュール4は、翻訳モジュール1か
らのデータベース処理依頼要求3に基づいて、データベ
ース18のアクセスと複数のサービス実行千段5に対す
るサービス処理依顛要求6を行う。また、データベース
処理モジュール4は、サービス実行手段5からのデータ
ベース処理依頼要求3に基づいてデータベース18への
アクセスを行う。
らのデータベース処理依頼要求3に基づいて、データベ
ース18のアクセスと複数のサービス実行千段5に対す
るサービス処理依顛要求6を行う。また、データベース
処理モジュール4は、サービス実行手段5からのデータ
ベース処理依頼要求3に基づいてデータベース18への
アクセスを行う。
出力処理モジュール7は、サービス実行手段5からの出
力処理依軌要求8に基づいて通信網へのメッセージの出
力を行う。
力処理依軌要求8に基づいて通信網へのメッセージの出
力を行う。
上記各モジュー・ル間及び各モジュールとサービス実行
手段4間のそれぞれの処理依幀要求3、6、8は、共通
化したデータフォーマットに基づいて行っている。
手段4間のそれぞれの処理依幀要求3、6、8は、共通
化したデータフォーマットに基づいて行っている。
翻訳モジュール1は、例えば受信したサービス要求メッ
セージ2の各パラメータに、そのサービスに対応した処
理タグを付与してデータベース処理依鯨要求3を作成す
る。
セージ2の各パラメータに、そのサービスに対応した処
理タグを付与してデータベース処理依鯨要求3を作成す
る。
データベース処理モジュール4は、上記のデータベース
処理依頼要求3に基づいてデータベース18をアクセス
して所望の情報を入手する。そして、その得られた情報
と、サービス要求メッセージ2の各パラメータとからサ
ービス処理依軌要求6を作成する。
処理依頼要求3に基づいてデータベース18をアクセス
して所望の情報を入手する。そして、その得られた情報
と、サービス要求メッセージ2の各パラメータとからサ
ービス処理依軌要求6を作成する。
このサービス処理依顛要求6により指定されたサービス
実行手段5は、個々のサービス処理を実行し、実行結果
が通信網に出力すべきものであれば、出力処理依頼要求
8を作成して出力処理モジュール7に出力する。
実行手段5は、個々のサービス処理を実行し、実行結果
が通信網に出力すべきものであれば、出力処理依頼要求
8を作成して出力処理モジュール7に出力する。
また、サービス実行の結果、データベース18をアクセ
スする必要が生じた場合には、必要な処理内容に対応し
たデータベース処理依幀要求3を作成しデータベース処
理モジュール4に出力する。
スする必要が生じた場合には、必要な処理内容に対応し
たデータベース処理依幀要求3を作成しデータベース処
理モジュール4に出力する。
このように、通信網とサービス実行手段5間、又はデー
タベース18とサービス実行手段5間等に、翻訳モジュ
ールl、データベース処理モジュール4、及び出力処理
モジュール7を介在させ、それら各モジュールとサービ
ス実行手段5間の処理依顛要求を共通化したデータフォ
ーマットにより行うことにより、サービス実行手段5を
データベース18と分離した形で構成することができる
。
タベース18とサービス実行手段5間等に、翻訳モジュ
ールl、データベース処理モジュール4、及び出力処理
モジュール7を介在させ、それら各モジュールとサービ
ス実行手段5間の処理依顛要求を共通化したデータフォ
ーマットにより行うことにより、サービス実行手段5を
データベース18と分離した形で構成することができる
。
従って、例えばサービス実行手段に対応するサービス・
アプリケーション・プログラムを、データベース18の
構造を意識せずに開発することができ、プログラムの開
発効率をより高めることができる。
アプリケーション・プログラムを、データベース18の
構造を意識せずに開発することができ、プログラムの開
発効率をより高めることができる。
以下、本発明の実施例を図面を参照しながら説明する。
本実施例は、本発明に係るデータベース管理方式を実行
するS C P (Service Control
Point) 12に関するものである。
するS C P (Service Control
Point) 12に関するものである。
尚、インテリジェント・ネットワークの全体構成は特に
は図示していないが、例えば第20図に示したような構
成を有しており、SCP 1 2内にテータベースと、
各種サービス・アプリケーション・プログラムと、後述
するAPIP22とが設けられている。
は図示していないが、例えば第20図に示したような構
成を有しており、SCP 1 2内にテータベースと、
各種サービス・アプリケーション・プログラムと、後述
するAPIP22とが設けられている。
第2図は、SCP 1 2の主要部の構成図である。
同図において、翻訳チェック処理モジュール13は、S
S P (Service Switching P
oint) 1 1を介して与えられる発加入者からの
受信メッセージ(MSG)を解析するモジュールである
。このとき、同一発加入者から複数のサービス要求があ
った場合には、後述する相互規制マトリックステーブル
14を参照して、それらのサービスが同時に実行可能な
サービスか、あるいは何れかを一方のみが実行可能なサ
ービスか等を判断する。
S P (Service Switching P
oint) 1 1を介して与えられる発加入者からの
受信メッセージ(MSG)を解析するモジュールである
。このとき、同一発加入者から複数のサービス要求があ
った場合には、後述する相互規制マトリックステーブル
14を参照して、それらのサービスが同時に実行可能な
サービスか、あるいは何れかを一方のみが実行可能なサ
ービスか等を判断する。
また、翻訳チェック処理モジュール13は、実行すべき
サービスが決定したなら、サービス内容に対応した処理
タグを付与し、共通のデータフォーマットからなるDB
(データベース)処理依輔伝票15(後述する)を作成
しデータベース処理モージュル16に送る。
サービスが決定したなら、サービス内容に対応した処理
タグを付与し、共通のデータフォーマットからなるDB
(データベース)処理依輔伝票15(後述する)を作成
しデータベース処理モージュル16に送る。
データベース処理モジュール(以下、DB処理モジュー
ルと呼ぶ)16は、翻訳チェック処理モジュール13又
はアプリケーション・プログラム17(後述する)から
のDB処理依頼伝票15の処理タグに従って、対象とな
るデータベース18をアクセスしてデータの読み出し、
書き込み等を行う。また、DB処理モジュールl6は、
処理タグに従って処理したデータを基にAP処理依頼伝
票19(後述する)を作成する。
ルと呼ぶ)16は、翻訳チェック処理モジュール13又
はアプリケーション・プログラム17(後述する)から
のDB処理依頼伝票15の処理タグに従って、対象とな
るデータベース18をアクセスしてデータの読み出し、
書き込み等を行う。また、DB処理モジュールl6は、
処理タグに従って処理したデータを基にAP処理依頼伝
票19(後述する)を作成する。
アブリーケシゴン・プログラム17は、CUG(Clo
sed Laser Group)、3者通話、着信課
金などの各種のサービス処理を実行するものであり、個
別のサービス処理を実行した後、DB処理依頼伝票15
を作成してデータベース18の更新等を行う。また、処
理結果を基に出力処理依幀伝票20(後述する)を作成
して出力処理モジュール21に出力する。
sed Laser Group)、3者通話、着信課
金などの各種のサービス処理を実行するものであり、個
別のサービス処理を実行した後、DB処理依頼伝票15
を作成してデータベース18の更新等を行う。また、処
理結果を基に出力処理依幀伝票20(後述する)を作成
して出力処理モジュール21に出力する。
出力処理モジュール21は、出力処理依頼伝票20とし
て受け取ったデータを、信号網において規定されている
プロトコルに基づいて所定のデータフォーマットに変換
するモジュールである。
て受け取ったデータを、信号網において規定されている
プロトコルに基づいて所定のデータフォーマットに変換
するモジュールである。
上述した翻訳チェック処理モジュール13、DB処理モ
ジュール16、及び出力処理モージュル21の全体をま
とめてA P I P (Application I
nterface Platform) 2 2と呼
ぶ。
ジュール16、及び出力処理モージュル21の全体をま
とめてA P I P (Application I
nterface Platform) 2 2と呼
ぶ。
また、上記APIP22には、サービス追加時に各モジ
ュールの機能を拡張する為のコマンド等を入力する為の
マン・マシーン・インタフェース(MMI)23が接続
されている。
ュールの機能を拡張する為のコマンド等を入力する為の
マン・マシーン・インタフェース(MMI)23が接続
されている。
次に、以上のような構成の実施例の動作を説明する。
以下、加入者からCUG及び着信課金サービスの2つの
サービス要求があった場合について説明する。
サービス要求があった場合について説明する。
第3図は、翻訳チェック処理モジュール13における翻
訳チェック処理のフローチャートである。
訳チェック処理のフローチャートである。
先ず、発加入者からのメッセージ(MSG)を受信する
(第3図Sl)。
(第3図Sl)。
次に、受信メッセージの中からサービスキー(SVC
KEY)を抽出する(第3図32)。
KEY)を抽出する(第3図32)。
次に、抽出したサービスキーで相互規制マトリックステ
ーブル14(第4図)をサーチし(第3図33)、両サ
ービス間に相互規制条件が設定されているか否かを判別
する(第3図34)。
ーブル14(第4図)をサーチし(第3図33)、両サ
ービス間に相互規制条件が設定されているか否かを判別
する(第3図34)。
相互規制マトリックステーブルl4とは、第4図に示す
ように縦軸及び横軸に各サービス名A〜Fを記載し、そ
れら各サービス相互間の相互規制条件をマトリックス上
に定義したものである。
ように縦軸及び横軸に各サービス名A〜Fを記載し、そ
れら各サービス相互間の相互規制条件をマトリックス上
に定義したものである。
第4図において、例えばAサービスとBサービスとの交
点に記載されている「0」は、両サービス間に相互規制
が無いことを表しており、AサービスとEサービスの交
点に記載されている’PAJはAサービスを優先して実
行し、Eサービスは無視されることを表している。その
他、第4図に示すような種々の相互規制条件に従って、
各サービス間の相互規制条件が決められている。
点に記載されている「0」は、両サービス間に相互規制
が無いことを表しており、AサービスとEサービスの交
点に記載されている’PAJはAサービスを優先して実
行し、Eサービスは無視されることを表している。その
他、第4図に示すような種々の相互規制条件に従って、
各サービス間の相互規制条件が決められている。
第3図に戻り、要求のあったサービス間が同時に起動で
ないサービスであるときには、出力処理モジュール21
にその内容を通知し、発加入者へメッセージを出力させ
る(第3図35)。
ないサービスであるときには、出力処理モジュール21
にその内容を通知し、発加入者へメッセージを出力させ
る(第3図35)。
他方、両サービス間に相互規制条件が無いときには、両
サービスを起動させる(第3図36)。
サービスを起動させる(第3図36)。
そして、メッセージとして送られてきた、CUG及び着
信課金に関する受信パラメータ、サービスキー、発信番
号、インデックスコード(Index Code) 、
OA表示、着信番号等をメモリ(図示せず)セーブする
(第3図57)。
信課金に関する受信パラメータ、サービスキー、発信番
号、インデックスコード(Index Code) 、
OA表示、着信番号等をメモリ(図示せず)セーブする
(第3図57)。
さらに、サービスキーの内容に対応した処理タグを付与
し、COG関連及び着信課金関連DB処理依頼伝票15
を作成する(第3図SS)。
し、COG関連及び着信課金関連DB処理依頼伝票15
を作成する(第3図SS)。
本実施例では、各モジュール間及び各モジュールとアプ
リケーション・プログラム17間の処理依頼等を共通化
したデータフォーマットにより行っている。
リケーション・プログラム17間の処理依頼等を共通化
したデータフォーマットにより行っている。
そして、DB処理モジュール16に対して処理依顛を行
うものをDB処理依頼伝票15、アプリケーション・プ
ログラム17に対して処理依顛を行うものをAP処理依
顛伝票l9、出力処理モジュール2lに対して処理依顛
を行うものを出力処理依軌伝票20と呼んでいる。これ
らの処理依顛伝票は、SCP12内のメモリに記憶され
る。
うものをDB処理依頼伝票15、アプリケーション・プ
ログラム17に対して処理依顛を行うものをAP処理依
顛伝票l9、出力処理モジュール2lに対して処理依顛
を行うものを出力処理依軌伝票20と呼んでいる。これ
らの処理依顛伝票は、SCP12内のメモリに記憶され
る。
第5図は、CUGサービスに関するDB処理依頼伝票1
5の一例を示す図である。
5の一例を示す図である。
この場合、サービスキーがrcUc,であることから、
翻訳チェック処理モジュール13により、処理タグとし
てリレー変換が指定され、さらに第1パラメータ(IS
T PRA)としてサービスキー「CUG」が、第2パ
ラメータ(2ND) Lて発信番号が、第3パラメータ
(3RD) としてCUGインデックス・・・等が指
定されて、第5図に示すようなDB処理伝票15が作成
される。
翻訳チェック処理モジュール13により、処理タグとし
てリレー変換が指定され、さらに第1パラメータ(IS
T PRA)としてサービスキー「CUG」が、第2パ
ラメータ(2ND) Lて発信番号が、第3パラメータ
(3RD) としてCUGインデックス・・・等が指
定されて、第5図に示すようなDB処理伝票15が作成
される。
ここで、処理タグとは、実行すべき処理内容を指定する
情報であり、第6図に示すようにそれぞれのサービスの
機能に対応して定義されている。
情報であり、第6図に示すようにそれぞれのサービスの
機能に対応して定義されている。
第6図において、例えば情報Aから情報Bを求め、さら
に情報Bに対応する情報Cを求めるCUGのチェック処
理等の場合には、処理タグとしてリレー変換が指定され
る。また、情報Aと情報Bとの一致を調べるパスワード
のチェックなどの場合には、処理タグとしてチェックが
指定される.他のサービスに対しても、そのサービスが
果たす機能に従って、第6図に示す処理タグがそれぞれ
指定される. 第7図は、第3図59のDB処理の内容を説明するフロ
ーチャートである。
に情報Bに対応する情報Cを求めるCUGのチェック処
理等の場合には、処理タグとしてリレー変換が指定され
る。また、情報Aと情報Bとの一致を調べるパスワード
のチェックなどの場合には、処理タグとしてチェックが
指定される.他のサービスに対しても、そのサービスが
果たす機能に従って、第6図に示す処理タグがそれぞれ
指定される. 第7図は、第3図59のDB処理の内容を説明するフロ
ーチャートである。
以下、CUGサービスに関するDB処理について、第7
図のフローチャートを参照して説明する。
図のフローチャートを参照して説明する。
CUGサービスとは、登録された特定の加入者に対して
のみ行われるサービスである。個々の加大者には、個別
のインデックスコードが割当られており、そのインデッ
クッスコードに対応して決められているインタロックコ
ードが、着信先のCUGデータベースに登録されていれ
ば、サービスを受けることができる。
のみ行われるサービスである。個々の加大者には、個別
のインデックスコードが割当られており、そのインデッ
クッスコードに対応して決められているインタロックコ
ードが、着信先のCUGデータベースに登録されていれ
ば、サービスを受けることができる。
第7図において、翻訳チェック処理モジュールl3から
のDB処理依頼伝票を15受信する(第7図310)。
のDB処理依頼伝票を15受信する(第7図310)。
次に、そのDB処理依軽伝票15の処理タグから実行す
べき処理がリレー変換であることを認識する(第7図3
11)。
べき処理がリレー変換であることを認識する(第7図3
11)。
次に、DB処理依顛伝票15の第1パラメータのサービ
スキーから、アクセス先データベースがCUGデータベ
ースであることを認識する(第7図312)。
スキーから、アクセス先データベースがCUGデータベ
ースであることを認識する(第7図312)。
第8図(a) 〜(d)は、発側CUGデータベース(
Origination COG DB)及び着側CU
Gデータベース(Destination CLIG
DB)の一例を示す図である.以下第8図を参照しなが
らフローチャートの説明を行う。
Origination COG DB)及び着側CU
Gデータベース(Destination CLIG
DB)の一例を示す図である.以下第8図を参照しなが
らフローチャートの説明を行う。
次に、第2パラメータの発信番号で発側CUGデータベ
ース24を検索して対応するデータユニット(Data
Unit) 2 5 (第8図(a))を決定する(
第7図313)。
ース24を検索して対応するデータユニット(Data
Unit) 2 5 (第8図(a))を決定する(
第7図313)。
次に、そのデータユニット25の中で、第3パラメータ
のCUGインデックスコードに対応するインクロックコ
ードを抽出する(第7図314)。
のCUGインデックスコードに対応するインクロックコ
ードを抽出する(第7図314)。
次の第4パラメータが区切りを示すデリミッタであるの
で、抽出したインタロックコードをソースデータとして
登録する(第7図315)。
で、抽出したインタロックコードをソースデータとして
登録する(第7図315)。
次に、着信番号で着側CUGデータベース26を検索し
対応するデータユニット27(第8図(C))を決定す
る(第7図516)。
対応するデータユニット27(第8図(C))を決定す
る(第7図516)。
さらに、そのデータユニット27の中をソースデータ、
すなわちインタロックコードで検索し、対応する着側イ
ンデックスコードを求める(第7図317)。
すなわちインタロックコードで検索し、対応する着側イ
ンデックスコードを求める(第7図317)。
このようにして求めたインデックスコード(索出データ
)と、受信メッセージとからAP処理依輔伝票工9を作
成する(第7図318)。
)と、受信メッセージとからAP処理依輔伝票工9を作
成する(第7図318)。
例えば、DB処理依頼伝票が第5図に示すようなもので
あるとすると、第2パラメータの発信番号r71266
66 Jから、第8図(a)に示すデータユニット25
を決定する。次に、第3パラメータのインデックスコー
ドr090 jから、第8図(b)に示すように指定さ
れたユニット25内のインデックスコード「090」に
対応するインタロックコードrl2345 Jを求める
。
あるとすると、第2パラメータの発信番号r71266
66 Jから、第8図(a)に示すデータユニット25
を決定する。次に、第3パラメータのインデックスコー
ドr090 jから、第8図(b)に示すように指定さ
れたユニット25内のインデックスコード「090」に
対応するインタロックコードrl2345 Jを求める
。
次に、このインクロックコードがアクセス先に登録され
ているか否かを調べる為に、第5パラメータの着信番号
r7125555 Jから、第8図(C)に示すように
着側CUGデータベース26のデータユニット27を決
定する。さらに、第8図(d)に示すように、そのデー
タユニット27をインタロックコードrl2345 J
で検索し、対応する着側インデックスコード「010」
を求める。
ているか否かを調べる為に、第5パラメータの着信番号
r7125555 Jから、第8図(C)に示すように
着側CUGデータベース26のデータユニット27を決
定する。さらに、第8図(d)に示すように、そのデー
タユニット27をインタロックコードrl2345 J
で検索し、対応する着側インデックスコード「010」
を求める。
すなわち、上述した処理では、個々のユーザに割当られ
ているインデックスコードを、一旦発CUGデータベー
ス24内部に登録されているインタロックコードに変換
している。さらに、着信番号とそのインタロックコード
とから、着側CUGデータベース26にそのインクロッ
クコードが存在するかどうかにより、CUGユーザとし
て登録されているか否かをチェックしてる。
ているインデックスコードを、一旦発CUGデータベー
ス24内部に登録されているインタロックコードに変換
している。さらに、着信番号とそのインタロックコード
とから、着側CUGデータベース26にそのインクロッ
クコードが存在するかどうかにより、CUGユーザとし
て登録されているか否かをチェックしてる。
そして、最終的な着側インデックスコードが得られれば
、そのインデックスコードと受信メッセージとからAP
処理依顛伝票19を作成する。
、そのインデックスコードと受信メッセージとからAP
処理依顛伝票19を作成する。
第9図は、上述したDB処理により作成されるAP処理
依頌伝票l9の一例を示す図である。
依頌伝票l9の一例を示す図である。
同図に示すAP処理依頼伝票l9は、第5図のCUG関
連DB処理依頼伝票15に基づいて作成されたものであ
る. 第9図において、AP処理依顛伝票19の先頭には、実
行すべきアプリケーション・プログラム17を指定する
PROG.No. とじてrcUGjが記憶され、発信
番号、着信番号と共に、DB処理により求めたインタロ
ックコードr090 Jと、着側インデックスコードr
o10 Jとが記憶されている。
連DB処理依頼伝票15に基づいて作成されたものであ
る. 第9図において、AP処理依顛伝票19の先頭には、実
行すべきアプリケーション・プログラム17を指定する
PROG.No. とじてrcUGjが記憶され、発信
番号、着信番号と共に、DB処理により求めたインタロ
ックコードr090 Jと、着側インデックスコードr
o10 Jとが記憶されている。
次に、AP処理依軽伝票19を受信したときのアプリケ
ーションプログラム(AP)17側での処理内容を、第
10図のフローチャートを参照して説明する。
ーションプログラム(AP)17側での処理内容を、第
10図のフローチャートを参照して説明する。
以下の説明では、アブリケーシッン・プログラムl7と
出力処理モージュル21又はDB処理モジュール16と
の間のインタフェースに関する処理についてのみ説明す
る。
出力処理モージュル21又はDB処理モジュール16と
の間のインタフェースに関する処理についてのみ説明す
る。
先ず、AP処理依顛伝票19のPROG.No。
により措定されるアプリケーション・プログラムl7の
個別処理を実行する(第lO図S19)。
個別処理を実行する(第lO図S19)。
次に、この個別処理により得られたデータに基づいて出
力処理依鯨伝票20を作成する(第10図320)。
力処理依鯨伝票20を作成する(第10図320)。
第11図は、上記出力処理依鎖伝票20の一例を示す図
である。
である。
同図に示す出力処理依頼伝票20は、第9図のCUG関
連AP処理依軌伝票19に基づいて作成されたものであ
る。
連AP処理依軌伝票19に基づいて作成されたものであ
る。
第11図において、出力処理依軌伝票20の先頭には、
送信に関する処理依鎖であることを示す処理タグが付与
され、第1パラメータとして送信先の着信番号r712
5555 Jが、第2パラメータとして着側インデック
スコードroio J等が記憶されている。
送信に関する処理依鎖であることを示す処理タグが付与
され、第1パラメータとして送信先の着信番号r712
5555 Jが、第2パラメータとして着側インデック
スコードroio J等が記憶されている。
第10図に戻り、次にデータベース18の統計情報を更
新する必要があるか否かを判別する(第10図321)
。
新する必要があるか否かを判別する(第10図321)
。
統計情報を更新する必要のないときには、第10図の3
22又はS24に進み、作成した出力処理依頼伝票20
を出力処理モジュール21に出力し、又は個別のA.
P処理で作成されるDB処理依軌伝票15をDB処理モ
ジュール15に出力する。
22又はS24に進み、作成した出力処理依頼伝票20
を出力処理モジュール21に出力し、又は個別のA.
P処理で作成されるDB処理依軌伝票15をDB処理モ
ジュール15に出力する。
この322の出力処理は、出力処理モジュール21によ
り実行されるものであり、出力処理依頼伝票20の処理
タグから送信処理であることを認識し、さらにそれに続
く情報を信号網のブロ1・コルに従って所定のフォーマ
ットに変換して信号網に出力する。
り実行されるものであり、出力処理依頼伝票20の処理
タグから送信処理であることを認識し、さらにそれに続
く情報を信号網のブロ1・コルに従って所定のフォーマ
ットに変換して信号網に出力する。
他方、統計情報を更新する必要があるときには、統計情
報の更新の為のDB処理依輔伝票l5を作成する(第1
0図323)。そして、次の324に進み、作成したD
B処理依鯨伝票15をDB処理モジュール16に出力し
てDB処理を起動させる。
報の更新の為のDB処理依輔伝票l5を作成する(第1
0図323)。そして、次の324に進み、作成したD
B処理依鯨伝票15をDB処理モジュール16に出力し
てDB処理を起動させる。
第12図(a)、(b)は、C.UCデータベースニ対
するアクセス回数を、発信番号別、あるいはインクロッ
クコード別に集計するときのDB処理依頼伝票l5の一
例を示す図である。
するアクセス回数を、発信番号別、あるいはインクロッ
クコード別に集計するときのDB処理依頼伝票l5の一
例を示す図である。
この場合、第12図に示すように、それぞれのDB処理
依顛伝票15の先頭には、更新処理を指定する処理タグ
が付与され、第1パラメータのDB種別を示す情報とし
てrCUG統計」が、第4パラメータの演算内容を示す
情報として「加算」が、第5パラメータの演算単位を示
す情報として「1」等がそれぞれ記憶される。
依顛伝票15の先頭には、更新処理を指定する処理タグ
が付与され、第1パラメータのDB種別を示す情報とし
てrCUG統計」が、第4パラメータの演算内容を示す
情報として「加算」が、第5パラメータの演算単位を示
す情報として「1」等がそれぞれ記憶される。
第12図(a)、ら)示すDB処理依頼伝票15をDB
処理モジュール16が受け取った場合には、先ず、処理
タグ及びDB種別から、cHc統計データベースに関す
る統計情報の更新であることを認識する。
処理モジュール16が受け取った場合には、先ず、処理
タグ及びDB種別から、cHc統計データベースに関す
る統計情報の更新であることを認識する。
次いで、第13図に示すCUG統計情報が記憶されてい
るデータベースのヘッドテーブル30及び2次テーブル
31を、発信番号r7126666 J及びインクロッ
クコードにより検索し、対応するエリアのデータをそれ
ぞれ+1して統計情報(この場合アクセス回数)を更新
する。
るデータベースのヘッドテーブル30及び2次テーブル
31を、発信番号r7126666 J及びインクロッ
クコードにより検索し、対応するエリアのデータをそれ
ぞれ+1して統計情報(この場合アクセス回数)を更新
する。
以上のように、上記実施例ではデータベース18とアプ
リケーション・プログラム17との間にAPIP22を
設け、このAPIP22の各モジュール間、各モジュー
ルとデータベース18及びアプリケーション・プログラ
ム17間の処理依顧等を、共通化したデータフォーマッ
ト、例えば処理依鎖伝票の形式により行うようにした。
リケーション・プログラム17との間にAPIP22を
設け、このAPIP22の各モジュール間、各モジュー
ルとデータベース18及びアプリケーション・プログラ
ム17間の処理依顧等を、共通化したデータフォーマッ
ト、例えば処理依鎖伝票の形式により行うようにした。
従って、アブリーケション・プログラム17の開発を、
データベース18の構造を意識することなく行うことが
できる。これにより、プログラム開発が容易になり、交
換網の運用者等が独自にアプリケーション・プログラム
17を開発することが可能となる。
データベース18の構造を意識することなく行うことが
できる。これにより、プログラム開発が容易になり、交
換網の運用者等が独自にアプリケーション・プログラム
17を開発することが可能となる。
また、従来各アプリケーション・プログラム17内で行
われていたアプリケーション間の相互規制チェックを、
APIP22内部に設けた翻訳チェック処理モジュール
l3が行うようにしたので、新たなサービスを追加した
ときにも、既存のアプリケーション・プログラム17を
変更する必要がなく、プログラムの開発効率をより高め
ることができる。
われていたアプリケーション間の相互規制チェックを、
APIP22内部に設けた翻訳チェック処理モジュール
l3が行うようにしたので、新たなサービスを追加した
ときにも、既存のアプリケーション・プログラム17を
変更する必要がなく、プログラムの開発効率をより高め
ることができる。
次に、新たなサービスを追加する場合に、翻訳チェック
処理モジュールl3及びDB処理モジュール16等の機
能を拡張するときの手順について説明する。
処理モジュールl3及びDB処理モジュール16等の機
能を拡張するときの手順について説明する。
以下の説明では、CUGサービスが存在しない状態で、
新たにCUGサービスを追加する場合について述べる。
新たにCUGサービスを追加する場合について述べる。
先ず、翻訳チェック処理モジュール13の機能を拡張す
る場合の手順について、第14図のフローチャートを参
照して説明する。
る場合の手順について、第14図のフローチャートを参
照して説明する。
サービスを追加しようとする場合には、オペレータ(例
えば、交換網の運用者)は、マン・マシーン・インタフ
ェース(MMI)23のキーボード(図示せず)等を介
して新たなサービスキーを定義する(第14図525)
。
えば、交換網の運用者)は、マン・マシーン・インタフ
ェース(MMI)23のキーボード(図示せず)等を介
して新たなサービスキーを定義する(第14図525)
。
次に、相互規制マトリックステーブル14(第4図)を
MM I 2 3のディスプレ上に表示させて、そのマ
トリクッステーブルl4上に新たなサービスを登録し、
さらに各サービスキー間の相互規制条件を設定する(第
14図526)。また、このとき信号網から受信する受
信メッセージのパラメータを設定する。
MM I 2 3のディスプレ上に表示させて、そのマ
トリクッステーブルl4上に新たなサービスを登録し、
さらに各サービスキー間の相互規制条件を設定する(第
14図526)。また、このとき信号網から受信する受
信メッセージのパラメータを設定する。
次に、追加したサービスのDB処理依顛伝票15のファ
ーマットをディスプレイ上で作成し、さらに受信メッセ
ージの各パラメータと、DB処理依軌伝票15の各パラ
メータとの対応を定義する(第14図327)。
ーマットをディスプレイ上で作成し、さらに受信メッセ
ージの各パラメータと、DB処理依軌伝票15の各パラ
メータとの対応を定義する(第14図327)。
第15図は、受信メッセージ及びDB処理依鯨伝票15
のパラメータの対応関係の説明図である。
のパラメータの対応関係の説明図である。
例えば、第15図に示すように、受信メッセージのパラ
メータと、DB処理依軌伝票15のパラメータとをディ
スプレイ上に表示させ、それらの対応関係を定義するこ
とができる.この定義に基づいて、翻訳チェック処理モ
ジュール13は追加されたサービスのDB処理依顛伝票
15の作成を行う。
メータと、DB処理依軌伝票15のパラメータとをディ
スプレイ上に表示させ、それらの対応関係を定義するこ
とができる.この定義に基づいて、翻訳チェック処理モ
ジュール13は追加されたサービスのDB処理依顛伝票
15の作成を行う。
このように、新たなサービスを追加した場合にも、相互
規制マトリックテーブル14上において、他のサービス
との相互規制条件を設定するだけで良く、既存のアプリ
ケーション・プログラムを変更する必要がない。また、
相互規制条件の設定も非常に簡単になる。
規制マトリックテーブル14上において、他のサービス
との相互規制条件を設定するだけで良く、既存のアプリ
ケーション・プログラムを変更する必要がない。また、
相互規制条件の設定も非常に簡単になる。
次に、サービス追加時にDB処理モジュール16の機能
を拡張するときの手順を、第16図のフローチャートを
参照して説明する。
を拡張するときの手順を、第16図のフローチャートを
参照して説明する。
先ず、定義したCUGサービスに対応した発CUCデー
タベース2日及び着CUGデータベース29(第17図
)の最大サイズを定義する(第16図328)。また、
このとき発CUGデータベース28及び着CUGデータ
ベース29をどのコード(例えば、インデックスコード
又はインタロックコード)により検索するかを定義して
おく。
タベース2日及び着CUGデータベース29(第17図
)の最大サイズを定義する(第16図328)。また、
このとき発CUGデータベース28及び着CUGデータ
ベース29をどのコード(例えば、インデックスコード
又はインタロックコード)により検索するかを定義して
おく。
次に、それぞれのデータベースの構成を定義する(第1
6図S29)。
6図S29)。
このデータベースの構成の定義にあたっては、例えば、
次のような拡張コマンドにより新たなデータベースエリ
アを定義することができる。
次のような拡張コマンドにより新たなデータベースエリ
アを定義することができる。
ORG − CUG − DB;発番号; INDEX
(0.15);INTERLOCκ(16.31) 上記のコマンドは、発CUGデータベース28の構成を
定義するコマンドであり、32ビット長のデータエリア
のOビットから15ビットをインデックスコードのデー
タエリアとし、16ビットから31ビットをインターロ
ックコードのデータエリアとし、さらに個々の発加入者
のインデックスコード及びインターロックコードを、発
信番号順にデータベースに格納することを意味している
。
(0.15);INTERLOCκ(16.31) 上記のコマンドは、発CUGデータベース28の構成を
定義するコマンドであり、32ビット長のデータエリア
のOビットから15ビットをインデックスコードのデー
タエリアとし、16ビットから31ビットをインターロ
ックコードのデータエリアとし、さらに個々の発加入者
のインデックスコード及びインターロックコードを、発
信番号順にデータベースに格納することを意味している
。
同様な拡張コマンドにより着CUGデータベース29の
構成も定義することができる。
構成も定義することができる。
これにより、第17図に示すような発CUGデータベー
ス28エリアと、着CUGデータベース29エリアとが
確保される。
ス28エリアと、着CUGデータベース29エリアとが
確保される。
このように、コマンドレベルでデータベースエリアの確
保等を行うことができるので、サービスの追加時のAP
IP22内部の各モジュールの機能拡張を容易に行うこ
とができる。
保等を行うことができるので、サービスの追加時のAP
IP22内部の各モジュールの機能拡張を容易に行うこ
とができる。
第16図に戻り、次に、追加したサービスに対応するA
P処理依鯨伝票19のフォーマットを定義する(第18
図330)。
P処理依鯨伝票19のフォーマットを定義する(第18
図330)。
第18図は、受信メッセージ及びAP処理依軒伝票19
のパラメータの対応関係の説明図である。
のパラメータの対応関係の説明図である。
例えば、第18図に示すように受信メッセージとAP処
理依鎖伝票19の各パラメータを表示させ、両者をディ
スプレイ上で対応づけることにより、各パラメータ間の
関係を定義することができる。
理依鎖伝票19の各パラメータを表示させ、両者をディ
スプレイ上で対応づけることにより、各パラメータ間の
関係を定義することができる。
また、このときDB処理により求められるインタロック
コードと、着インデックスコードとは、それぞれ第4パ
ラメータのデータ、第6パラメータのデータとして定義
しておく。
コードと、着インデックスコードとは、それぞれ第4パ
ラメータのデータ、第6パラメータのデータとして定義
しておく。
さらに、新たに追加したCUGサービスのPROG.
No, (サービスキー)を起動管理テーブル(図示
せず)に登録しておく(第16図331)次に、CUG
サービスが起動された際に更新される統計情報のデータ
ベースエリアを定義する(第16図332)。
No, (サービスキー)を起動管理テーブル(図示
せず)に登録しておく(第16図331)次に、CUG
サービスが起動された際に更新される統計情報のデータ
ベースエリアを定義する(第16図332)。
S32の処理では、先ず、何に関する統計情報かを示す
項目と、そのエリアサイズを定義する。
項目と、そのエリアサイズを定義する。
これにより、第13図に示したように、そのデータベー
スの統計情報が、発番号とインターロックコードに関す
るものであることを示すヘッドテーブル30が定義され
る。
スの統計情報が、発番号とインターロックコードに関す
るものであることを示すヘッドテーブル30が定義され
る。
次に、2次テーブル31のエリアサイズ、すなわちそれ
ぞれの項目別の統計情報を記憶するエリアサイズと、イ
ンデックス項目とを定義する。
ぞれの項目別の統計情報を記憶するエリアサイズと、イ
ンデックス項目とを定義する。
以上により、発番号別及びインタロックコード別のアク
セス回数を記憶するCUG統計データベースエリアが定
義される。
セス回数を記憶するCUG統計データベースエリアが定
義される。
次に、出力処理モジュールの機能の拡張を行う。
第19図は、このとき定義される出力処理依頼伝票20
と信号網に出力するデータフォーマットとの対応関係の
説明図である。
と信号網に出力するデータフォーマットとの対応関係の
説明図である。
例えば、第19図に示すようにディスプレイ上で出力処
理依親伝票20のフォーマットと、信号網へ出力するデ
ータフォーマットとを作成し、両者の対応関係を定義す
ることがきる。
理依親伝票20のフォーマットと、信号網へ出力するデ
ータフォーマットとを作成し、両者の対応関係を定義す
ることがきる。
このように、MM I 2 3のディスプレイ上で相互
規制マトリックステーブルl4、各種の処理依軽伝票等
を定義することができるので、新たなサービスを追加す
る場合の変更を箇単に行うことができる。
規制マトリックステーブルl4、各種の処理依軽伝票等
を定義することができるので、新たなサービスを追加す
る場合の変更を箇単に行うことができる。
また、各モジュールの機能拡張をMM I 2 3がら
のコマンド入力により行うことができるので、サービス
追加に対して柔軟に対応することができる。
のコマンド入力により行うことができるので、サービス
追加に対して柔軟に対応することができる。
本発明によれば、データベースの構造を意識することな
くアプリケーション・プログラム等の開発を行うことが
できるので、交換網の運用者等が容易にプログラム開発
を行うことができる。
くアプリケーション・プログラム等の開発を行うことが
できるので、交換網の運用者等が容易にプログラム開発
を行うことができる。
また、各アプリーケションプログラム間の相互規制条件
をマトリックテーブルとして、共通のモジュール内に持
っているので、サービス追加時に既存のアプリケーショ
ンプログラムを変更する必要が無くなる。
をマトリックテーブルとして、共通のモジュール内に持
っているので、サービス追加時に既存のアプリケーショ
ンプログラムを変更する必要が無くなる。
第1図は、本発明の原理説明図、
第2図は、本発明の実施例の構成図、
第3図は、翻訳チェック処理のフローチャート、第4図
は、相互規制マトリックステーブルの説明図、 第5図は、CUG関連DB処理依頼伝票の一例を示す図
、 第6図は、処理タグの説明図、 第7図は、DB処理のフローチャート、第8図(a)
〜(d)は、CUG関連DB処理の説明図、第9図は、
CUG関連AP処理依鯨伝票の一例を示す図、 第10図は、AP側のインタフェース処理のフローチャ
ート、 第11図は、出力処理依鯨伝票の一例を示す図、第12
図(a)、(b)は、DB処理依頷伝票の一例を示す図
、 第13図は、CUG統計データベースの構成図、第14
図は、翻訳チェック処理モジュールの機能拡張時の手順
を示すフローチャート、第15図は、受信メッセージ及
びDB処理依鯨伝票のパラメータの対応関係の説明図、
第16図は、DB処理モジュールの機能拡張時の手順を
示すフローチャート、 第17図は、発CUGデータベース及び着CUGデータ
ベースの一例を示す図、 第18図は、受信メッセージ及びAP処理依鯨伝票のパ
ラメータの対応関係の説明図、第19図は、出力処理依
顛伝票と信号網に出力するデータフォーマットとの対応
関係の説明図、第20図は、インテリジェントネットワ
ークの構成の一例を示す図である。 l・・・翻訳モジュール、 2・・・サービス要求メッセージ、 3・・・データベース処理依鯨要求、 データベース処理モジュール、 サービス実行手段、 サービス処理依鯨要求、 出力処理モジュール、 出力処理依軌要求.
は、相互規制マトリックステーブルの説明図、 第5図は、CUG関連DB処理依頼伝票の一例を示す図
、 第6図は、処理タグの説明図、 第7図は、DB処理のフローチャート、第8図(a)
〜(d)は、CUG関連DB処理の説明図、第9図は、
CUG関連AP処理依鯨伝票の一例を示す図、 第10図は、AP側のインタフェース処理のフローチャ
ート、 第11図は、出力処理依鯨伝票の一例を示す図、第12
図(a)、(b)は、DB処理依頷伝票の一例を示す図
、 第13図は、CUG統計データベースの構成図、第14
図は、翻訳チェック処理モジュールの機能拡張時の手順
を示すフローチャート、第15図は、受信メッセージ及
びDB処理依鯨伝票のパラメータの対応関係の説明図、
第16図は、DB処理モジュールの機能拡張時の手順を
示すフローチャート、 第17図は、発CUGデータベース及び着CUGデータ
ベースの一例を示す図、 第18図は、受信メッセージ及びAP処理依鯨伝票のパ
ラメータの対応関係の説明図、第19図は、出力処理依
顛伝票と信号網に出力するデータフォーマットとの対応
関係の説明図、第20図は、インテリジェントネットワ
ークの構成の一例を示す図である。 l・・・翻訳モジュール、 2・・・サービス要求メッセージ、 3・・・データベース処理依鯨要求、 データベース処理モジュール、 サービス実行手段、 サービス処理依鯨要求、 出力処理モジュール、 出力処理依軌要求.
Claims (1)
- 【特許請求の範囲】 1)複数のサービス実行手段(5)を有するインテリジ
ェント・ネットワークにおいて、発加入者からのサービ
ス要求メッセージ(2)に基づいてデータベース処理依
頼要求(3)を出力する翻訳モジュール(1)と、 該翻訳モジュール(1)からのデータベース処理依頼要
求(3)に基づいて、データベース(18)のアクセス
と前記複数のサービス実行手段(5)に対するサービス
処理依頼要求(6)を行うと共に、該サービス実行手段
(5)からのデータベース処理依頼要求(3)に基づい
てデータベース(18)へのアクセスを行うデータベー
ス処理モジュール(4)と、 前記サービス実行手段(5)からの出力処理依頼要求(
8)に基づいて通信網へのメッセージの出力を行う出力
処理モジュール(7)とを有し、前記各モジュール間(
1、4、7)及び各モジュール(4、7)とサービス実
行手段(5)間のそれぞれの処理依頼要求(3、6、8
)を、共通化したデータフォーマットに基づいて行うこ
とを特徴とするインテリジェント・ネットワークにおけ
るデータベース管理方式。 2)前記翻訳モジュール(1)は、複数のサービス実行
手段(5)間の相互規制条件を定義した相互規制マトリ
ックステーブル(14)を有し、同一発加入者からの複
数のサービス要求に対し、該相互規制マトリックステー
ブル(14)を参照して、該複数のサービスの実行の可
否を判断することを特徴とする請求項1記載のインテリ
ジェント・ネットワークにおけるデータベース管理方式
。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2008415A JP2532148B2 (ja) | 1990-01-19 | 1990-01-19 | インテリジェント・ネットワ―クにおけるデ―タベ―ス管理方式 |
| US08/246,479 US5574904A (en) | 1990-01-19 | 1994-05-19 | Database management system in an intelligent network using a common request data format |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2008415A JP2532148B2 (ja) | 1990-01-19 | 1990-01-19 | インテリジェント・ネットワ―クにおけるデ―タベ―ス管理方式 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH03214851A true JPH03214851A (ja) | 1991-09-20 |
| JP2532148B2 JP2532148B2 (ja) | 1996-09-11 |
Family
ID=11692507
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2008415A Expired - Fee Related JP2532148B2 (ja) | 1990-01-19 | 1990-01-19 | インテリジェント・ネットワ―クにおけるデ―タベ―ス管理方式 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US5574904A (ja) |
| JP (1) | JP2532148B2 (ja) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH0646150A (ja) * | 1992-04-01 | 1994-02-18 | American Teleph & Telegr Co <Att> | 電話交換ネットワーク |
| KR100419096B1 (ko) * | 2001-09-07 | 2004-02-18 | 엘지전자 주식회사 | 지능망에서의 메시지 아이디 관리 방법 |
Families Citing this family (27)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5692171A (en) * | 1992-11-20 | 1997-11-25 | Bull S.A. | Method of extracting statistical profiles, and use of the statistics created by the method |
| US5544320A (en) * | 1993-01-08 | 1996-08-06 | Konrad; Allan M. | Remote information service access system based on a client-server-service model |
| US5835757A (en) * | 1994-03-30 | 1998-11-10 | Siemens Telecom Networks | Distributed database management system for servicing application requests in a telecommunications switching system |
| US5899998A (en) * | 1995-08-31 | 1999-05-04 | Medcard Systems, Inc. | Method and system for maintaining and updating computerized medical records |
| US5819250A (en) * | 1996-01-09 | 1998-10-06 | U S West, Inc. | Method and system for multimedia interaction with a database |
| US5884310A (en) * | 1996-06-14 | 1999-03-16 | Electronic Data Systems Corporation | Distributed data integration method and system |
| US5987520A (en) * | 1997-09-18 | 1999-11-16 | Ascend Communications, Inc. | Closed user group preprocessing decision for efficient call security validation |
| US6115746A (en) * | 1997-10-20 | 2000-09-05 | Iex Corporation | Distributed control of AIN and non-AIN switches and resources in an advanced intelligent network |
| US6088434A (en) * | 1997-10-29 | 2000-07-11 | Alcatel Usa Sourcing, L.P. | Method and system for communicating telecommunications provisioning information |
| US6226650B1 (en) | 1998-09-17 | 2001-05-01 | Synchrologic, Inc. | Database synchronization and organization system and method |
| US6269406B1 (en) | 1998-10-19 | 2001-07-31 | International Business Machines Corporation | User group synchronization to manage capabilities in heterogeneous networks |
| SE523204C2 (sv) * | 1998-12-01 | 2004-04-06 | Ericsson Telefon Ab L M | Arrangemang, kommunikationsnätverk och metod där en anordning hos klienter innefattandes en databas med information om resurser hos servrar, styr kommunikationen mellan klienter och servrar |
| SE521504C2 (sv) * | 1998-12-01 | 2003-11-04 | Ericsson Telefon Ab L M | Arrangemang och metod i ett nätverk där transaktioner skapar händelser som lagras i interservermeddelanden |
| US6909900B1 (en) | 1999-07-01 | 2005-06-21 | Gte Wireless Service Corporation | Wireless mobile call location and delivery for non-geographic numbers using a wireline SSP+SCP/wireless HLR interface |
| US6487412B1 (en) | 1999-07-01 | 2002-11-26 | Gte Wireless Service Corporation | Method and system for routing calls to wireless directory numbers in a network |
| US7039164B1 (en) * | 1999-10-14 | 2006-05-02 | Gte Wireless Service Corporation | Method and system for reporting events in telecommunication networks |
| US6922465B1 (en) | 1999-10-14 | 2005-07-26 | Gte Mobilnet Incorporated | Method and system for reporting events in telecommunication networks |
| US7054636B1 (en) | 2000-03-01 | 2006-05-30 | Gte Wireless Services Corporation | Method and system for communicating data from wireline terminals to mobile terminals |
| KR100364171B1 (ko) * | 2000-03-31 | 2002-12-11 | 주식회사데이콤 | 지능망시스템의 대용량 호 처리 장치 |
| US7849190B2 (en) * | 2001-02-23 | 2010-12-07 | Nokia Siemens Networks Oy | Internet protocol based service architecture |
| US6792431B2 (en) * | 2001-05-07 | 2004-09-14 | Anadarko Petroleum Corporation | Method, system, and product for data integration through a dynamic common model |
| US7499983B2 (en) * | 2002-05-06 | 2009-03-03 | Micron Technology, Inc. | Web dispatch service |
| US6876733B2 (en) * | 2002-12-03 | 2005-04-05 | International Business Machines Corporation | Generic service component for message formatting |
| US7304575B2 (en) * | 2005-06-01 | 2007-12-04 | Intel Corporation | Low cost power amplifier linearization in an RFID radio transmit chain |
| US8081593B2 (en) * | 2007-06-29 | 2011-12-20 | Alcatel Lucent | Mobile switching center with outgoing access closed user group interlock code |
| US8239632B2 (en) * | 2009-03-12 | 2012-08-07 | At&T Mobility Ii Llc | Data caching in consolidated network repository |
| US8990324B2 (en) | 2010-04-22 | 2015-03-24 | Bae Systems Information And Electronic Systems Integration Inc. | Distributing messages in multiple formats in tactical communications networks |
Family Cites Families (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4377859A (en) * | 1980-09-02 | 1983-03-22 | International Telephone And Telegraph Corporation | Time slot interchanger and control processor apparatus for use in a telephone switching network |
| US4479196A (en) * | 1982-11-15 | 1984-10-23 | At&T Bell Laboratories | Hyperedge entity-relationship data base systems |
| US4774655A (en) * | 1984-10-24 | 1988-09-27 | Telebase Systems, Inc. | System for retrieving information from a plurality of remote databases having at least two different languages |
| US4780821A (en) * | 1986-07-29 | 1988-10-25 | International Business Machines Corp. | Method for multiple programs management within a network having a server computer and a plurality of remote computers |
| US5058000A (en) * | 1987-06-30 | 1991-10-15 | Prime Computer, Inc. | System for accessing remote heterogeneous database including formatting retrieved data into applications program format |
| US4982325A (en) * | 1988-03-18 | 1991-01-01 | At&T Bell Laboratories | Applications processor module for interfacing to a database system |
| US4956769A (en) * | 1988-05-16 | 1990-09-11 | Sysmith, Inc. | Occurence and value based security system for computer databases |
| US5124909A (en) * | 1988-10-31 | 1992-06-23 | Hewlett-Packard Company | Software program for providing cooperative processing between personal computers and a host computer |
-
1990
- 1990-01-19 JP JP2008415A patent/JP2532148B2/ja not_active Expired - Fee Related
-
1994
- 1994-05-19 US US08/246,479 patent/US5574904A/en not_active Expired - Fee Related
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH0646150A (ja) * | 1992-04-01 | 1994-02-18 | American Teleph & Telegr Co <Att> | 電話交換ネットワーク |
| KR100419096B1 (ko) * | 2001-09-07 | 2004-02-18 | 엘지전자 주식회사 | 지능망에서의 메시지 아이디 관리 방법 |
Also Published As
| Publication number | Publication date |
|---|---|
| JP2532148B2 (ja) | 1996-09-11 |
| US5574904A (en) | 1996-11-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JPH03214851A (ja) | インテリジェント・ネットワークにおけるデータベース管理方式 | |
| JP3075486B2 (ja) | データベースネットワークの管理方法 | |
| US5533116A (en) | Network management system | |
| US5379383A (en) | Communication service control system in an intelligent network providing controllers for controlling different services | |
| US7693974B2 (en) | System and method for providing a graphical user interface to, for building, and/or for monitoring a telecommunication network | |
| WO1998032292A1 (en) | Graphical subscription manager intelligent network | |
| WO1999009723A2 (en) | Method for implementing programmable transaction capabilities application part (tcap) protocol | |
| US6487288B1 (en) | Intelligent network switching point and control point | |
| JP2001211258A (ja) | No.7関門局信号網の翻訳類型マッピング方法 | |
| CA2245156C (en) | Service logic portability based on interface definition of execution environment in an intelligent network | |
| US6411702B1 (en) | Intelligent network capable of executing a plurality of service control request messages in a single service control point | |
| US5894574A (en) | Apparatus and method for SIB-based global title translation services | |
| RU2155374C2 (ru) | Совместимое устройство сопряжения пользования | |
| US6370136B1 (en) | Dialing plan arrangement for expandable telecommunications system | |
| JPH0622028A (ja) | 通信ネットワーク内の管理方式 | |
| US6732362B1 (en) | Object-oriented exchange managing system and exchange resources installing method | |
| US6804339B1 (en) | Real-time object-oriented database for TAPI service providers | |
| US6151317A (en) | Control type or service independent building block | |
| CN101056314B (zh) | 智能网络系统、业务开发方法、实现业务与协议分离的方法 | |
| JP3018468B2 (ja) | ネットワーク管理システム | |
| CA2237743C (en) | Oa&m system | |
| JPH07239816A (ja) | エージェント・システム | |
| KR100194632B1 (ko) | Atm vc 교환기의 가입자 데이터 관리방법 | |
| KR930009858B1 (ko) | 전전자 교환기의 특수서비스 데이타 처리방법 | |
| KR930009856B1 (ko) | 전전자 교환기의 사설교환기 데이타 처리방법 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| LAPS | Cancellation because of no payment of annual fees |