JP2014053682A - データ変換装置及びデータ変換プログラム - Google Patents

Abstract

【課題】管理ノードからのＳＯ要求データをＣＡのコマンド形式に変換することで、ＳＯインタフェースのカスタマイズ時間及び費用を軽減する。
【解決手段】本発明のデータ変換装置は、呼制御装置と、呼制御装置の受付データとコマンド形式の異なる要求データを与える管理装置との間に介在し、管理装置からの要求データを所定の内部データに変換し、呼制御装置に投入する１又は複数のコマンド条件が定義されているコマンド変換テーブルを決定し、コマンド変換テーブルの各コマンド条件に従い、内部データを参照して、呼制御装置のコマンド形式に必要なデータに変換し、コマンドを呼制御装置に与える。
【選択図】 図１

Description

本発明は、データ変換装置及びデータ変換プログラムに関し、例えば、コールエージェント（ＣＡ：Call Agent）を制御するためのサービスオーダ（ＳＯ）処理において、形式の異なるコマンドをＣＡ制御のためのコマンド形式に変換するデータ変換装置及びデータ変換プログラムに適用し得るものである。

例えば、インターネットプロトコル（ＩＰ）網上で提供する音声通信サービスを構成するノードにおいて、中核となるのが呼制御を行う呼制御サーバ（コールエージェント：ＣＡ）である。

ＣＡは、管理ノードによって制御されるが、音声通信サービスのプロビジョニングのためにＣＡを制御する管理ノードとして、ＣＡプロビジョニングサーバ（以下、ＣＡプロビサーバともいう）やＣＡプロビジョニング端末（以下、ＣＡプロビ端末）が代表的なものである。

また、ＳＯの履歴やＳＯによってＣＡに設定される加入者契約情報等は、ＤＢサーバがデータベースに蓄積する。

従来のＩＰ網上の音声通信サービスシステムは、図２に示すように、ＣＡ９１が、ＣＡプロビサーバ９３やＣＡプロビ端末等の管理ノードと直結されている。ＣＡプロビサーバ９３やＣＡプロビ端末９４は、ＣＡ９１に対してＳＯ処理を制御するためのコマンドを直接投入することで、ＣＡ９１との間でＳＯ通信を行っている（特許文献１参照。）
また、昨今のＩＰ網上の音声通信サービスシステムは、ＣＡの制御の効率化及びＣＡの制御情報の保持の効率化のため、図３に示すように、ＤＢサーバ９２を経由して、ＣＡプロビサーバ９３又はＣＡプロビ端末９４とＣＡ９１との間のＳＯ通信が行われている。

特開２００３−２５８９９５号公報

例えば、ＣＡは、ＩＰ網上での音声通信サービスの向上やトラフィックの増加等に対応するために、既存ＣＡから新規ＣＡへの置き換えが頻繁に行われる。

また、ＩＰ網を提供する通信事業者（いわゆるキャリア事業者）は、新規ＣＡの開発コスト削減のために、例えば装置間のインタフェースモジュール等については汎用製品から調達して新規ＣＡを開発している。

このとき、図４に示すように、ＣＡを新規のＣＡ９１に置き換えた場合、ＣＡ９１に置き換えに伴い、ＳＯ要求のコマンド形式も変更し得るため、新規管理ノード（ＣＡプロビサーバ９３及びＣＡプロビ端末９４）及び新規ＣＡ９１の双方のＳＯインタフェースと、ＤＢサーバ９２のＳＯインタフェースとのカスタマイズが必要となる。

上記のような、各ノードのＳＯインタフェースをカスタマイズするためには時間及び費用がかかってしまう。特に、既設システムを構成する全ての管理ノード側のＳＯインタフェースをカスタマイズするには膨大な費用を要してしまうことになり、その費用は、新規サービスの提供遅延やサービス料金の増加を招き、顧客へのサービス低下に繋がるおそれがある。

そのため、ＳＯインタフェースのカスタマイズに係る時間及び費用を軽減するために、管理ノード（管理装置）からの要求データを呼制御装置のコマンド形式に合わせて変換することができるデータ変換装置及びデータ変換プログラムが求められている。

かかる課題を解決するために、第１の本発明は、呼制御装置と、呼制御装置の受付データとコマンド形式の異なる要求データを与える管理装置との間に介在し、管理装置からの要求データのコマンド形式を変換して呼制御装置に与えるデータ変換装置であって、（１）管理装置からの要求データを所定の内部データに変換する内部データ変換手段と、（２）呼制御装置に投入する１又は複数のコマンド条件が定義されているコマンド変換テーブルを要求種別毎に記憶するコマンド変換テーブル記憶手段と、（３）内部データに含まれる要求種類に対応するコマンド変換テーブルを決定し、コマンド変換テーブルの各コマンド条件に従い、内部データを参照して、呼制御装置のコマンド形式に必要なデータに変換するコマンド変換手段と、（４）コマンド変換手段からのデータに基づくコマンドを呼制御装置に与えるコマンド処理手段とを備えることを特徴とするデータ変換装置である。

第２の本発明は、呼制御装置と、呼制御装置の受付データとコマンド形式の異なる要求データを与える管理装置との間に介在し、管理装置からの要求データのコマンド形式を変換して呼制御装置に与える装置のデータ変換プログラムであって、コンピュータを、（１）管理装置からの要求データを所定の内部データに変換する内部データ変換手段、（２）呼制御装置に投入する１又は複数のコマンド条件が定義されているコマンド変換テーブルを要求種別毎に記憶部に記憶する手段、（３）内部データに含まれる要求種類に対応するコマンド変換テーブルを決定し、コマンド変換テーブルの各コマンド条件に従い、内部データを参照して、呼制御装置のコマンド形式に必要なデータに変換するコマンド変換手段、（４）コマンド変換手段からのデータに基づくコマンドを呼制御装置に与えるコマンド処理手段として機能させることを特徴とするデータ変換プログラムである。

本発明によれば、管理装置からの要求データを呼制御装置のコマンド形式に合わせて変換することができる。

実施形態のＳＯ処理部の機能的な内部構成を示す内部構成図である。 従来のＩＰ網上の音声通信サービスシステムの構成を示す構成図である（その１）。 従来のＩＰ網上の音声通信サービスシステムの構成を示す構成図である（その２）。 従来のＩＰ網上の音声通信サービスシステムで、ＣＡを置き換えた場合に生じ得るＳＯインタフェース部のカスタマイズを説明する説明図である。 実施形態のサービスオーダ（ＳＯ）要求コマンド変換システムの構成を示す構成図である。 実施形態のＩＰ網上の音声通信サービスシステムで、ＣＡを置き換えた場合のＳＯインタフェース部のカスタマイズを説明する説明図である。 実施形態のＫＥＹ情報変換テーブルの構成例を示す構成図である。 実施形態のコマンド変換テーブルの構成例を示す構成図である。 実施形態のコマンドリストの構成例を示す構成図である。 実施形態のＫＥＹ変換テーブルの設定処理の動作を示すフローチャートである。 実施形態のＳＯ処理部におけるＫＥＹ変換テーブルの設定処理を説明する説明図である。 実施形態のＳＯ要求の分割処理の動作を示すフローチャートである。 実施形態のＳＯ処理部における分割処理を説明する説明図である。 実施形態の複数のＳＯ要求を集約する集約処理の動作を示すフローチャートである。 実施形態のＳＯ処理部における集約処理を説明する説明図である。

（Ａ）主たる実施形態
以下では、本発明のデータ変換装置及びデータ変換プログラムの実施形態を、図面を参照しながら詳細に説明する。

（Ａ−１）実施形態の構成
（Ａ−１−１）全体構成
図５は、この実施形態のサービスオーダ（ＳＯ）要求コマンド変換システムの構成を示す構成図である。

図５において、この実施形態のサービスオーダ要求コマンド変換システム１０は、コールエージェント（ＣＡ）１、ＤＢサーバ２、ＣＡプロビジョニングサーバ（ＣＡプロビサーバ）３−１、ＣＡプロビジョニング端末（ＣＡプロビ端末）３−２を有して構成される。

コールエージェント（ＣＡ）１は、音声通信システムに係る呼制御を行うものである。この実施形態では、コールエージェントを新規ＣＡ１に置き換える場合を想定して説明する。ＣＡ１は、ＳＯインタフェース部１１は新たにカスタマイズされたものであり、既存のＳＯ要求コマンドとコマンド形式が異なるものとする。

ＣＡプロビサーバ３−１及びＣＡプロビ端末３−２は、ＣＡ１を制御する管理ノードである。ＣＡプロビサーバ３−１及びＣＡプロビ端末３−２は、ＳＯ処理を行うＳＯインタフェース部３１を有している。なお、この実施形態では、ＣＡ１を新規のものに置き換えるが、ＣＡプロビサーバ３−１及びＣＡプロビ端末３−２側のシステムは、そのまま既存のものとして運用する場合を例示する。

ＣＡプロビサーバ３−１及びＣＡプロビ端末３−２が、ＣＡ１に対して投入するコマンドとしては、例えば、音声通信サービスの新規加入契約を行う加入者情報登録コマンド、加入者情報更新コマンド、加入者情報削除コマンド、一時撤去登録又は一時撤去登録解除コマンド、契約者の代表を登録する代表登録コマンド、代表変更コマンド、代表削除コマンド等がある。

また、ＣＡプロビサーバ３−１及びＣＡプロビ端末３−２は、音声通信に係る各種サービスのコマンドもＣＡ１に対して投入することができる。音声通信に係る各種サービスのコマンドとしては、例えば、転送サービスの登録・変更・解除や、番号通知サービスの登録・変更・解除等のコマンドがある。

ＤＢサーバ２は、ＳＯの履歴やＳＯによってＣＡ１に設定される加入者契約情報を蓄積するデータベース２２と、ＣＡプロビサーバ３−１及びＣＡプロビ端末３−２とＣＡ１との間のＳＯ要求コマンドのコマンド形式を変換するＳＯ処理部２１とを有するものである。

ここで、ＳＯ処理部２１は、ＣＡプロビサーバ３−１及びＣＡプロビ端末３−２とＣＡ１との間のＳＯインタフェース差分の吸収を行うものである。

ＤＢサーバ２がＳＯ処理部２１を備えることにより、ＣＡプロビサーバ３−１及びＣＡプロビ端末３−２とＣＡ１との間のＳＯインタフェース差分を吸収することができるので、新規ＣＡ１を置き換えに伴うＳＯインタフェース部のカスタマイズの対象をＤＢサーバ２のみとすることができる。

つまり、新規ＣＡ１の置き換えに伴うＳＯインタフェース部のカスタマイズの対象をＤＢサーバ２に集中させることができる。これにより、ＣＡプロビサーバ３−１及びＣＡプロビ端末３−２とＣＡ１とについて、ＳＯインタフェース部のカスタマイズを削減することができる。

従って、新規ＣＡ１を汎用品から調達可能となり、かつ、ＣＡ１の移行に伴うＳＯインタフェース部の変更作業が発生しなくなる。

また、既設のＣＡプロビサーバ３−１及びＣＡプロビ端末３−２は、既存のＳＯ要求コマンドでＣＡ１を制御することができる。さらに、既設のＣＡプロビサーバ３−１及びＣＡプロビ端末３−２のＳＯインタフェース部の変更作業も発生しなくなる。

よって、新規ＣＡ１の置き換えからサービス開始までにかかる時間と費用を削減することができる。また、図４（Ｂ）及び図６に示すように、最も簡単なノード構成を取る場合、カスタマイズ対象が従来の４ノードから１ノードとなるため、単純な試算によれば、カスタマイズの時間と費用を従来よりも１／４にすることができる。

（Ａ−１−２）ＳＯ処理部２１の内部構成
図１は、ＤＢサーバ２が備えるＳＯ処理部２１の機能的な内部構成を示す内部構成図である。

ＳＯ処理部２１は、例えば、ＣＰＵ、ＲＯＭ、ＲＡＭ、ＥＥＰＲＯＭ、入出力インタフェース部等の装置からなり、ＣＰＵがＲＯＭに格納されるコマンド変換プログラムを実行することにより、図１に示すＳＯ処理部２１のＤＢサーバ２の機能が実現される。また、ＤＢサーバ２にコマンド変換プログラムをインストールすることによっても、ＳＯ処理部２１は形成され、この場合でも機能的には図１で表すことができる。

ＳＯ処理部２１は、上述したように、ＣＡプロビサーバ３−１及びＣＡプロビ端末３−２からのＳＯ要求コマンドのコマンド形式を、ＣＡ１のＳＯ処理に対応可能なコマンド形式に変換し、変換後のＳＯ要求コマンドをＣＡ１に与えるものである。

図１に示すように、ＳＯ処理部２１は、データ取得部１１０、パラメータ編集処理部１２０、コマンド変換処理部１３０、コマンド処理部１４０を有する。

データ取得部１１０は、管理ノードであるＣＡプロビサーバ３−１又はＣＡプロビ端末３−２からＳＯ要求コマンドを取得し、取得したＳＯ要求コマンドデータをパラメータ編集処理部１２０に与えるものである。

パラメータ編集処理部１２０は、データ取得部１１０からのＳＯ要求コマンドデータのデータ形式の確認及びパラメータ許容条件の確認を行い、内部データ形式のデータに変換するものである。

コマンド変換処理部１３０は、パラメータ編集処理部１２０により変換された内部データを、後述するコマンド処理部１４０がＣＡ１に提供するコマンド形式に変換し、変換後のデータをコマンド処理部１４０に与えるものである。

図１に示すように、コマンド変換処理部１３０は、ＫＥＹ変換部１３１、ＫＥＹ情報変換テーブル１３２、コマンド変換部１３３、コマンド変換テーブル１３４、コマンドリスト生成部１３５、コマンドリスト１３６、コマンド生成補助情報生成部１３７、コマンド生成補助情報１３８を有する。

ＫＥＹ変換部１３１は、ＫＥＹ情報変換テーブル１３２を参照して、ＣＡプロビサーバ３−１及びＣＡプロビ端末３−２から受け取ったＳＯ要求コマンドデータに含まれるＫＥＹ情報を、システム内部で用いるＫＥＹ情報に変換するものである。

ＫＥＹ情報変換テーブル１３２は、ＣＡプロビサーバ３−１及びＣＡプロビ端末３−２からのＳＯ要求コマンドデータに含まれるＫＥＹ情報と、システム内部で用いられるＫＥＹ情報とを対応付けたテーブルである。

図７は、この実施形態のＫＥＹ情報変換テーブル１３２の構成例を示す構成図である。図７に示すように、管理ノード側のＫＥＹ情報とシステム内部のＫＥＹ情報とが１対１で対応付けられている。

ここで、ＫＥＹ情報は、加入者を一意に識別するユーザ識別情報（例えば、ユーザＩＤ等）である。例えば、ＣＡプロビサーバ３−１及びＣＡプロビ端末３−２からのＳＯ要求コマンドデータには、加入者を識別するユーザ識別情報がＫＥＹ情報として含まれる。ユーザ識別情報は、管理ノード側のシステムに従って定義されるものであり、例えば、契約者名、契約者番号、端末情報、端末番号等が該当する。

これに対して、システム内部で用いられるＫＥＹ情報は、例えば、電話番号とする。

つまり、管理ノード側のシステムで使用されるユーザ識別情報としてのＫＥＹ情報を、システム内部では全て電話番号に変換することができる。

例えば、ＤＢサーバ２が管理ノード側のシステムとして複数のシステムと接続しているとする。そして、あるシステムはユーザ識別情報として契約者名を定義しており、他のシステムはユーザ識別情報として契約者番号を定義しているものとする。このような場合でも、ＫＥＹ情報変換部１３１は、ユーザ識別情報を全て電話番号に変換することができる。

ここで、システム内部で用いるＫＥＹ情報を電話番号としたのは、この実施形態では音声通信サービスを例示するものであり、契約者（ユーザ）は電話番号が割り当てられているため、管理ノード側のシステム種類に拘らず、一意にユーザを識別できるからである。

コマンド変換部１３３は、ＣＡプロビサーバ３−１及びＣＡプロビ端末３−２から指定されるコマンド変換テーブル１３４を参照して、パラメータ編集処理部１２０により変換された内部データ形式のデータを、ＣＡ１に提供するコマンドに変換するものである。

コマンド変換テーブル１３４は、コマンド処理部１４０がＣＡ１に提供するコマンドに変換するための変換テーブルである。

図８は、この実施形態のコマンド変換テーブル１３４の構成例を示す構成図である。

図８に示すように、コマンド変換テーブル１３４は、例えば「テーブルＡ」、「テーブルＢ」等のように、テーブル識別情報としてのテーブル名が付与されている。また、それぞれのコマンド変換テーブル１３４は、指定された機能をＣＡ１に指令するための１又は複数のコマンド名と、そのコマンドに必要なパラメータとが定義されている。

例えば、ＣＡプロビサーバ３−１及びＣＡプロビ端末３−２が、ＳＯ要求コマンドで「テーブルＡ」を指定した場合、テーブルＡに対応する機能をＣＡ１に要求するために、「コマンドＡ」、「コマンドＢ」、…で指令することが必要であり、例えば「コマンドＡ」を生成するには「パラメータａ，…」の必要データが必要である。これにより、コマンド変換部１３３は、コマンド変換テーブル１３４を参照して、それぞれのコマンドを生成するための必要データを用いて、１個ずつコマンドを生成して、指定されたテーブル名のコマンドを生成する。

コマンドリスト生成部１３５は、コマンド処理部１４０を起動させるコマンドリスト１３６を生成するものである。つまり、コマンドリスト生成部１３５は、コマンド処理部１４０に投入するコマンドリストを生成するものである。コマンドリスト生成部１３５は、コマンド変換部１３３により変換されたコマンドをリスト化する。

コマンドリスト１３６は、コマンドリスト生成部１３５により生成されるものである。

図９は、この実施形態のコマンドリスト１３６の構成例を示す構成図である。図９のコマンドリスト１３６は、例えば、図８の「テーブルＡ」のテーブル変換テーブル１３４により変換されたものである。図９のコマンドリスト１３６は、「テーブルＡ」で定義される「コマンドＡ」、「コマンドＢ」、…のコマンドがリストされる。

コマンド生成補助情報生成部１３７は、ＣＡプロビサーバ３−１及びＣＡプロビ端末３−２からの１個のＳＯ要求コマンドでは情報不足であり、コマンド処理部１４０がＣＡ１に提供するコマンドを生成できないため、それまでに取得したデータをコマンド生成補助情報１３８として退避するものである。

例えば、既存システムの管理ノードが既存のコールエージェントに対して転送サービスを要求する場合、既存の管理ノード側は３個のＳＯ要求コマンドを投入していたとする。これに対して、新規ＣＡ１は、従来の３個のＳＯ要求コマンドに含まれる必要データを包含して１個のＳＯ要求コマンドで受け付けるものであるとする。

この場合、コマンド変換処理部１３０は、既存の１個のＳＯ要求コマンドを取得しても、必要データが足りず、コマンド生成ができない。

そこで、コマンド生成補助情報生成部１３７は、必要な情報を取得するまで、それまでに獲得したデータをコマンド生成補助情報１３８として退避する。そして、その後に、コマンド変換処理部１３０が残りのＳＯ要求コマンドを取得し、必要データ投入されたときに、今回取得したＳＯ要求コマンドに含まれるデータと、コマンド生成補助情報１３８として退避されたデータとを用いて、コマンド生成を行う。

コマンド処理部１４０は、加入者データを操作する機能をコマンド形式でＣＡ１に提供するものである。コマンド処理部１４０は、コマンド処理部１４０は、各種サービス毎の競合条件の確認する競合条件確認部１４１、データベース２２に加入者契約情報等を設定するデータベース設定部１４２を備える。

なお、ＳＯ要求コマンドは、例えば、新規加入者登録、加入者更新、加入者削除、一時撤去登録／登録解除、代表登録、代表変更、代表削除、音声通信に係る各種サービスを用意することができる。

（Ａ−２）実施形態の動作
次に、この実施形態のサービスオーダ（ＳＯ）要求コマンド変換処理の動作を、図面を参照しながら詳細に説明する。

ＳＯ処理部２１は、ＣＡプロビサーバ３−１及びＣＡプロビ端末３−２とＣＡ１との間のＳＯインタフェース部の差分吸収処理として、以下の処理を行う。

（１）データベース２２上にＣＡプロビサーバ３−１及びＣＡプロビ端末３−２とＣＡ１との間のＫＥＹ情報差分を吸収するため、ＫＥＹ情報変換テーブル１３２の設定する処理。

（２）ＣＡプロビサーバ３−１及びＣＡプロビ端末３−２から１個のＳＯ要求を複数のＳＯ要求に分割してＣＡ１に要求する処理。

（３）ＣＡプロビサーバ３−１及びＣＡプロビ端末３−２からの複数のＳＯ要求を１個のＳＯ要求に集約して、ＣＡに要求する処理。このとき、ＳＯ処理部２１は、複数のＳＯ要求の投入順序の整合性を図る。

（Ａ−２−１）ＫＥＹ変換テーブル１３２の設定処理
図１０は、この実施形態のＫＥＹ変換テーブル１３２の設定処理の動作を示すフローチャートである。図１１は、ＳＯ処理部２１におけるＫＥＹ変換テーブル１３２の設定処理を説明する説明図である。

新規加入登録を行うときには、新たな契約者についてのＫＥＹ変換テーブル１３２の設定と、ＣＡ１への新規加入者登録コマンドの通知と、データベース２２への加入者契約情報（加入者データ）の登録等が必要となる。

そこで、以下では、新規加入者登録を行う際のＫＥＹ変換テーブル１３２の設定処理と併せて、ＣＡ１への新規加入者登録コマンドの通知と、データベース２２への加入者契約情報（加入者データ）の登録処理を説明する。

まず、新規加入者登録に関するＳＯ要求データが、ＣＡプロビサーバ３−１又はＣＡプロビ端末３−２からＳＯ処理部１２に与えられる。

ＳＯ処理部１２において、データ取得部１１０が新規加入者登録に関するＳＯ要求データを取得すると（Ｓ１０１）、パラメータ編集処理部１２０が、取得データの確認を行い、取得データを内部データ形式のデータに形式変換する（Ｓ１０２）。

例えば、図１１に示すように、データ取得部１１０が取得するデータ（受付データ）には、新規加入者登録についてのコマンド変換テーブルを指定する「テーブルＡ」、ＣＡプロビサーバ３−１又はＣＡプロビ端末３−２のシステム側で定義されているＫＥＹ情報としての「ユーザＩＤ＝ＡＡＡＡ」、契約者の「電話番号＝００１」、契約内容を示す「契約１＝１」、「契約２＝２」、…等が含まれている。

この場合、パラメータ編集処理部１２０は、図１１に示すように、取得したデータ（受付データ）に基づいて、所定の内部データを生成する。内部データは、様々な形式で定義することができる。図１１の例の場合、内部データは、「テーブル（コマンド変換テーブル）＝テーブルＡ」、「ユーザＩＤ＝ＡＡＡＡ」、「電話番号＝００１」等のように、それぞれの必要データ項目とデータとを対応付けている。

次に、コマンド変換処理部１３０は、パラメータ編集処理部１２０が生成した内部データを参照して、指定されているテーブル名のコマンド変換テーブル１３４を決定する（Ｓ１０３）。

そして、コマンド変換処理部１３０は、コマンド変換テーブル１３４の条件に従って、内部データを参照し（Ｓ１０４）、コマンド変換テーブル１３４の条件に応じたコマンドリスト１３６を生成する（Ｓ１０５）。

例えば、図１１に示すように、内部データでは、「テーブル＝テーブルＡ」であるから、コマンド変換処理部１３０は、「テーブルＡ」のコマンド変換テーブルを決定し、「テーブルＡ」を用いて、コマンド処理部１４０が投入するコマンドのコマンドリスト１３６を生成する。

この場合、新規加入者登録のコマンド変換を示す「テーブルＡ」には、コマンドＡ、コマンドＢ、…を要し、例えば、コマンドＡの生成に必要なパラメータが記載されている。

そのため、コマンド変換処理部１３０は、内部データを参照して、コマンドＡを生成するための必要データを内部データから取得し、コマンドＡの必要データをコマンドリスト１３６に設定する。このような処理を、「テーブルＡ」に記載の他の全てのコマンド（例えばコマンドＢ等）についても行い、コマンドリスト１３６を生成する。

次に、コマンド変換処理部１３０は、例えば、内部データからＫＥＹ情報としての「ユーザＩＤ＝ＡＡＡＡ」と「電話番号＝００１」を取得し、「ＡＡＡＡ」と「００１」とを対応付けてＫＥＹ変換テーブル１３２の設定を行う（Ｓ１０６）。

さらに、コマンド変換処理部１３０は、コマンドリスト１３６を参照して、コマンドリスト１３６に設定されているコマンドに必要なデータを、先頭から１コマンドずつ順番にコマンド処理部１４０に与えて起動させる（Ｓ１０７）。

これにより、コマンド処理部１４０は起動し、コマンド変換処理部１３０からのデータに基づいてＣＡ１に提供するコマンド形式のコマンドを生成して、ＣＡ１に対してコマンドを投入する。

また、コマンド処理部１４０は、コマンド変換処理部１３０からのデータに基づいて加入者契約情報を生成して、データベース２２に登録する（Ｓ１０８）。

（Ａ−２−２）１個のＳＯ要求を複数のＳＯ要求コマンドにする分割処理
図１２は、この実施形態のＳＯ要求の分割処理の動作を示すフローチャートである。図１３は、ＳＯ処理部２１における分割処理を説明する説明図である。

ここでは、例えば、加入者契約情報の内容を更新する場合を例示する。

まず、加入者情報更新に関するＳＯ要求データが、ＣＡプロビサーバ３−１又はＣＡプロビ端末３−２からＳＯ処理部１２に与えられる。

ＳＯ処理部１２において、データ取得部１１０が加入者情報更新に関するＳＯ要求データを取得すると（Ｓ２０１）、パラメータ編集処理部１２０が、取得データの確認を行い、取得データを内部データ形式のデータに形式変換する（Ｓ２０２）。

例えば、図１３に示すように、データ取得部１１０が取得するデータ（受付データ）には、加入者情報更新についてのコマンド変換テーブルを指定する「テーブルＢ」、ＣＡプロビサーバ３−１又はＣＡプロビ端末３−２のシステム側で定義されているＫＥＹ情報としての「ユーザＩＤ＝ＡＡＡＡ」、契約者の「電話番号＝００１」、契約内容を示す「契約１＝０」、…等が含まれている。

ここでは、例えば、図１１で登録した加入者契約情報について、「契約１＝１」の内容を「契約１＝０」、…等の加入者情報の更新を想定して説明する。

次に、コマンド変換処理部１３０は、パラメータ編集処理部１２０が生成した内部データを参照して、指定されているテーブル名のコマンド変換テーブル１３４を決定する（Ｓ２０３）。例えば、図１３の内部データは「テーブル＝テーブルＢ」であるから、コマンド変換処理部１３０は、「テーブルＢ」のコマンド変換テーブルを決定する。

次に、コマンド変換処理部１３０は、コマンド変換テーブル１３４の条件に従って内部データを参照し（Ｓ２０４）、ＫＹＥ情報を取得する。

コマンド変換処理部１３０は、ＫＹＥ情報変換テーブル１３２を参照して、ＫＥＹ情報に対応する電話番号を取得し（Ｓ２０５）、コマンド変換テーブル１３４の条件に応じたコマンドリスト１３６を生成する（Ｓ２０６）。

例えば、図１３の内部データを参照して「ユーザＩＤ＝ＡＡＡＡ」であるから、コマンド変換処理部１３０は、ＫＥＹ情報変換テーブル１３２を参照して、「ユーザＩＤ＝ＡＡＡＡ」に対応する「電話番号＝００１」を取得する。さらに、コマンド変換処理部１３０は、内部データを参照して、例えばコマンドＣの必要データを内部データから取得して、コマンドリスト１３６に設定する。

次に、コマンド変換処理部１３０は、コマンドリスト１３６を参照して、コマンドリスト１３６に設定されているコマンドに必要なデータを、先頭から１コマンドずつ順番にコマンド処理部１４０に与えて起動させる（Ｓ２０７）。

これにより、コマンド処理部１４０は起動し、コマンド変換処理部１３０からのデータに基づいてＣＡ１に提供するコマンド形式のコマンドを生成して、ＣＡ１に対してコマンドを投入する。

また、コマンド処理部１４０は、コマンド変換処理部１３０からのデータに基づいて加入者契約情報の更新を行い、データベース２２に登録する（Ｓ２０８）。

（Ａ−２−３）複数のＳＯ要求を１個のＳＯ要求コマンドにする集約処理
図１４は、この実施形態の複数のＳＯ要求を集約する集約処理の動作を示すフローチャートである。図１５は、ＳＯ処理部２１における集約処理を説明する説明図である。

ここでは、例えば、加入者契約情報の内容を更新する場合を例示する。

まず、加入者情報更新に関するＳＯ要求データが、ＣＡプロビサーバ３−１又はＣＡプロビ端末３−２からＳＯ処理部１２に与えられる。

ＳＯ処理部１２において、データ取得部１１０が加入者情報更新に関するＳＯ要求データを取得すると（Ｓ３０１）、パラメータ編集処理部１２０が、取得データの確認を行い、取得データを内部データ形式のデータに形式変換する（Ｓ３０２）。

次に、コマンド変換処理部１３０は、パラメータ編集処理部１２０が生成した内部データを参照して、指定されているテーブル名のコマンド変換テーブル１３４を決定する（Ｓ３０３）。

そして、コマンド変換処理部１３０は、決定したコマンド変換テーブル１３４を参照して、他のコマンド変換テーブル１３４による必要な情報の有無を検出する（Ｓ３０４）。

例えば、図１５において、最初に取得した受付データＤ１の内部データがＤ３であるとする。内部データＤ３には、「テーブル＝テーブルＤ」が記載されているので、コマンド変換処理部１３０は、「テーブルＤ」のコマンド変換テーブル１３４を決定する。

このとき、例えば、「テーブルＤ」に「テーブルＥ」の情報が必要である旨が記載されており、コマンド変換処理部１３０は、「テーブルＥ」の情報を取得すべきことを検出する。

コマンド変換処理部１３０は、コマンド変換テーブル１３４の条件に従って内部データを参照し（Ｓ３０５）、ＫＹＥ情報変換テーブル１３２を参照して、ＫＥＹ情報に対応する電話番号を取得する（Ｓ３０６）。

ここで、「テーブルＤ」には「テーブルＥ」の情報が必要であるが、更新要求のコマンド生成のために、必要な情報を不足している。そこで、コマンド変換処理部１３０は、「テーブルＤ」のコマンド変換に必要なデータをコマンド生成補助情報１３８としてデータ退避する（Ｓ３０７）。

そして、コマンド生成条件が不足している場合（Ｓ３０８）、処理をＳ３０１に戻し、次に、ＣＡプロビサーバ３−１及びＣＡプロビ端末３−２から受け付けるデータを取得する（Ｓ３０１）。

例えば、図１５では、受付データＤ２が次に受け付けたデータであり。受付データＤ２の内部データがＤ４とする。コマンド変換処理部１３０は、内部データＤ４を参照しながら、Ｓ３０２〜Ｓ３０７の処理を繰り返し行う。

Ｓ３０８においてコマンド生成条件を満たす情報を取得すると、コマンド変換処理部１３０は、コマンド生成補助情報１３８を参照して、コマンド生成補助情報１３８のデータを用いて、コマンドリスト１３６を生成する（Ｓ３０９）。

そして、コマンド変換処理部１３０は、コマンドリスト１３６を参照して、コマンドリスト１３６に設定されているコマンドに必要なデータを、先頭から１コマンドずつ順番にコマンド処理部１４０に与えて起動させる（Ｓ３１０）。

これにより、コマンド処理部１４０は起動し、コマンド変換処理部１３０からのデータに基づいてＣＡ１に提供するコマンド形式のコマンドを生成して、ＣＡ１に対してコマンドを投入する。

また、コマンド処理部１４０は、コマンド変換処理部１３０からのデータに基づいて加入者契約情報の更新を行い、データベース２２に登録する（Ｓ３１１）。

（Ａ−３）実施形態の効果
以上のように、この実施形態によれば、管理ノードとＣＡとの間に介在するＤＢサーバにＳＯ処理部を備えることで、管理ノード及びＣＡのＳＯインタフェース部をカスタマイズする必要性がなくなる。その結果、新規ＣＡの置き換えに伴うＳＯインタフェース部のカスタマイズに係る時間及び費用を軽減することができる。

（Ｂ）他の実施形態
上述した実施形態において、種々の変形実施形態を説明したが、本発明は、以下の変形実施形態にも適用することができる。

（Ｂ−１）上述した実施形態では、コールエージェントを新規ＣＡに置き換えた場合を例示して説明した。

しかし、ＣＡと、ＣＡを制御する管理ノードとのＳＯ処理に係るコマンドが異なり、ＣＡと管理ノードとの間にＳＯ処理部を備える場合であれば、本発明は広く適用することができる。

例えば、上述した実施形態では、ＣＡの置き換えの場合であるが、管理ノードの置き換えを行う場合にも本発明は適用することができる。この場合でも、ＳＯ処理部におけるコマンド変換テーブルを定義することができれば、同様の効果を奏する。

また例えば、ＣＡと管理ノードとの間でコマンド形式の異なる場合であれば、ＣＡと管理ノードとを同時に置き換える場合にも適用することができる。

さらに例えば、上述した実施形態では、ＤＢサーバにＳＯ処理部を備える場合を例示した。しかし、ＳＯ処理部はＤＢサーバに設けられることに限定されるものではなく、ＳＯ処理部として機能する装置をＣＡと管理ノードとの間に介在させることで実現することができる。

（Ｂ−２）上述した実施形態では、電話サービス（音声通信サービス）である場合を例示したが、他のサービスオーダ処理に係るシステムにおいても本発明を適用することができる。

１…ＣＡ（コールエージェント）、２…ＤＢサーバ、３−１…ＣＡプロビジョニングサーバ、３−２…ＣＡプロビジョニング端末、
２１…ＳＯ処理部、２２…データベース、
１１０…データ取得部、１２０…パラメータ編集処理部、
１３０…コマンド変換処理部、１３１…ＫＥＹ情報変換部、
１３２…ＫＥＹ情報変換テーブル、１３３…コマンド変換部、
１３４…コマンド変換テーブル、１３５…コマンドリスト生成部、
１３６…コマンドリスト、１３７…コマンド生成補助情報生成部、
１３８…コマンドリスト補助情報、１４０…コマンド処理部。

Claims (6)

1. 呼制御装置と、上記呼制御装置の受付データとコマンド形式の異なる要求データを与える管理装置との間に介在し、上記管理装置からの要求データのコマンド形式を変換して上記呼制御装置に与えるデータ変換装置であって、
   上記管理装置からの上記要求データを所定の内部データに変換する内部データ変換手段と、
   上記呼制御装置に投入する１又は複数のコマンド条件が定義されているコマンド変換テーブルを要求種別毎に記憶するコマンド変換テーブル記憶手段と、
   上記内部データに含まれる要求種類に対応する上記コマンド変換テーブルを決定し、上記コマンド変換テーブルの各コマンド条件に従い、上記内部データを参照して、上記呼制御装置のコマンド形式に必要なデータに変換するコマンド変換手段と、
   上記コマンド変換手段からのデータに基づくコマンドを上記呼制御装置に与えるコマンド処理手段と
   を備えることを特徴とするデータ変換装置。
2. 上記コマンド変換手段が、新規登録要求の際、上記内部データに含まれるユーザ識別情報と電話番号とを対応付けてキー情報変換テーブルを設定するものであることを特徴とする請求項１に記載のデータ変換装置。
3. 上記コマンド変換手段が、上記コマンド変換テーブルの各コマンド条件に従って、上記呼制御装置のコマンド形式に必要なデータをコマンドリストに設定していき、１又は複数のコマンドに必要なデータを有するコマンドリストを生成するコマンドリスト生成部を有し、
   上記コマンド変換手段が、上記コマンドリストに設定されている順序で上記コマンド処理手段を起動させるものである
   ことを特徴とする請求項１又は２に記載のデータ変換装置。
4. 上記コマンド変換手段が、上記管理装置から取得した上記要求データに基づく内部データに不足がある場合には、それまでに獲得したデータを退避し、その退避データと、その後に上記管理装置から取得した要求データに基づく内部データとを集約させたコマンドの必要データに変換するものであることを特徴とする請求項１〜３のいずれかに記載のデータ変換装置。
5. 上記コマンド処理手段が、上記コマンド変換手段からのデータを用いて加入者データのデータベースへの設定を行うものであることを特徴とする請求項１〜4のいずれかに記載のデータ変換装置。
6. 呼制御装置と、上記呼制御装置の受付データとコマンド形式の異なる要求データを与える管理装置との間に介在し、上記管理装置からの要求データのコマンド形式を変換して上記呼制御装置に与える装置のデータ変換プログラムであって、
   コンピュータを、
   上記管理装置からの上記要求データを所定の内部データに変換する内部データ変換手段、
   上記呼制御装置に投入する１又は複数のコマンド条件が定義されているコマンド変換テーブルを要求種別毎に記憶部に記憶する手段、
   上記内部データに含まれる要求種類に対応する上記コマンド変換テーブルを決定し、上記コマンド変換テーブルの各コマンド条件に従い、上記内部データを参照して、上記呼制御装置のコマンド形式に必要なデータに変換するコマンド変換手段、
   上記コマンド変換手段からのデータに基づくコマンドを上記呼制御装置に与えるコマンド処理手段
   として機能させることを特徴とするデータ変換プログラム。

Images