JPH06209373A - 交換サービス契約処理方法及びその装置 - Google Patents

Abstract

(57)【要約】 【目的】 交換サービス契約処理において、サービスの
名称とその内容を熟知するための手間を省き、サービス
と既存サービスとの同時契約の可否の判定を容易にす
る。 【構成】 交換サービス契約処理装置において、サービ
スを名称とそのサービスの内容を細部化した目的要素と
によって構成されるデータ構造とし、サービス内容をそ
の名称あるいは目的要素として入力を受け付ける入出力
処理部１と、入力された名称あるいは目的要素を目的要
素あるいは名称に変換する名称・目的要素変換部２と、
既契約のサービスの名称及び目的要素のデータを記憶し
ておく情報蓄積部５と、処理対象のサービスと情報蓄積
部の既契約のサービスとを論理比較して同時契約の可能
性を判定する論理比較部４とから構成する。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、電話等の通信回線の交
換機におけるサービス内容を確認したり、契約時等にお
いて他の契約のサービス内容との識別を行う交換サービ
ス契約処理方法及びその装置に関するものである。

【０００２】

【従来の技術】従来、電話等の通信回線の交換機におけ
るサービスに関して、サービスの提供者と利用者との間
において電話等の通信回線の交換機におけるサービスに
かかわる契約について処理を行う場合には、そのサービ
ス内容を確認したり、他に契約しているサービス内容と
識別する必要がある。

【０００３】一般に、その電話等の通信回線の交換機に
おけるサービスは、そのサービスが提供する機能をサー
ビスという名称によって総体的に表しており、サービス
内容の確認や他の契約のサービス内容との識別におい
て、サービスの内容を特定するために、そのサービスに
対応してそれぞれ名称を付し、その名称を指定してい
る。

【０００４】従来、このようなサービスの名称による指
定を行うには、サービスの内容を表記した表を参照する
ことによってその内容を確認するか、あるいはサービス
の内容をあらかじめ熟知しておく必要がある。また、サ
ービスの指定の際に、複数のサービスを不都合なく同時
に契約できるか否かの判定や、既に契約しているサービ
スと不都合なく契約できるか否かの判定を行う必要があ
り、従来このような場合には、契約を行おうとする個々
のサービスを基準サービスとし、その基準サービスと同
時に契約をしようとするその他のサービス、あるいは既
に契約しているサービスを比較サービスとして、これら
のサービスを図１２に示す標準サービスと比較サービス
の比較一覧表によって判定し、同時契約の可否を判定し
ている。

【０００５】なお、図１２において表中の○印は同時契
約が可能であることを示し、×印は同時契約が不可能で
あることを示し、△はサービスの起動条件等によって一
義的に決まらないことを示している。図１２において、
基準サービスを縦方向のａからｙで示し、比較サービス
を横方向のａからｙで示している。そして、例えば、こ
れから受けようとするサービスである基準サービスａに
対して、この基準サービスａと同時に契約をしようとす
るその他のサービス、あるいは既に契約しているサービ
スを比較サービスｂとした場合には、それらの交差点に
示した○印により同時契約が可能であることが判定され
る。また、基準サービスａに対して、比較サービスｃと
した場合には、それらの交差点に示した×印により同時
契約が不可能であることが判定される。

【０００６】

【発明が解決しようとする課題】しかしながら、前記従
来の交換サービス契約処理において以下のような問題点
を有している。 （１）サービス契約者が自身の所望するサービス内容を
サービスの名称として表さなければならず、サービスの
名称とその内容について十分理解していなければならな
いという問題点がある。 （２）さらに、交換機が提供するサービス内容が追加さ
れる場合、既存の多くのサービスとの同時契約の可否を
判定するための図１２に示される標準サービスと比較サ
ービスの比較一覧表の追加が必要となる。

【０００７】つまり、図１２において、追加のサービス
をｚで表すと、このサービスｚと既存のサービスａ〜ｙ
との各組合せにおいて、同時契約が可能か否かの評価を
あらかじめ行い、その結果を標準サービスと比較サービ
スの比較一覧表に記載しておく必要がある。したがっ
て、新規のサービス内容を、この標準サービスと比較サ
ービスの比較一覧表に追加するために、サービスの仕様
や交換機の処理手順及び端末の操作手順などについて、
追加するサービスと既存のサービスの各組合せについて
ひとつずつ検討しなければならず、多くの手間を必要と
するという問題点がある。

【０００８】本発明は、前記した従来の交換サービス契
約処理の問題点を解決し、交換サービス契約処理方法及
びその装置において、サービスの名称とその内容を熟知
するための手間を省き、さらに交換機の提供するサービ
スが追加された場合にこのサービスと既存サービスとの
同時契約の可否を検討する際の手間を少なくすることを
目的とする。

【０００９】

【課題を解決するための手段】そのために、本発明の交
換サービス契約処理方法において、サービスをそのサー
ビスを特定する名称とそのサービスの内容を細分化した
目的要素とによって構成されるデータ構造とし、処理対
象のサービス内容をその名称あるいは目的要素によって
特定して入力し、入力された処理対象の名称あるいは目
的要素を目的要素あるいは名称に変換して、処理対象の
サービスに関する名称及び目的要素の両方のデータを出
力し、処理対象のサービスに関する名称及び目的要素の
データと、既に契約しているサービスの名称及び目的要
素のデータとを論理比較することによって、既契約のサ
ービスと前記処理対象のサービスの同時契約の可能性を
判定するものである。また、交換機の提供するサービス
の契約処理方法において、サービスをサービスを特定す
る名称とそのサービスの内容を細分化した目的要素とに
よって構成されるデータ構造とし、処理対象のサービス
の目的要素を入力し、入力された処理対象のサービスの
目的要素を名称に変換し、処理対象のサービスの名称に
よってサービスを特定するものである。

【００１０】そして、この目的要素は、サービスによっ
て達成される目的の条件を表す目的条件と、サービスに
よって達成される目的の動作を表す目的動作とから構成
することができる。また、交換サービス契約処理装置に
おいて、サービスをそのサービスを特定する名称とその
サービスの内容を細分化した目的要素とによって構成さ
れるデータ構造とし、処理対象のサービス内容をその名
称あるいは目的要素によって受け付ける入出力処理部
と、入力された処理対象の名称あるいは目的要素を目的
要素あるいは名称に変換して、前記処理対象のサービス
に関する名称及び目的要素の両方のデータを出力する名
称・目的要素変換部と、既契約のサービスの名称及び目
的要素のデータを記憶しておく情報蓄積部と、処理対象
のサービスに関する名称及び目的要素のデータと、情報
蓄積部から得られるサービスの名称及び目的要素のデー
タとを論理比較することによって、処理対象のサービス
と既契約のサービスの同時契約の可能性を判定する論理
比較部とから構成するものであり、さらに名称・目的要
素変換部は、サービスの名称と目的要素の変換データを
持たせることができる。

【００１１】

【作用】本発明によれば、従来のようにサービスの特定
のためにサービス契約者自身の所望するサービスをサー
ビスの名称によって表す必要がなく、その目的要素の記
述によって特定することができる。したがって、サービ
スの名称とその内容を十分理解していない場合において
も、サービスの目的要素によってサービスを特定するこ
とができ、交換機のサービスの契約処理においてそのサ
ービスの目的要素によって交換サービス契約処理を実現
することができる。

【００１２】また、サービスの目的を細分化して記述す
るため細分化された各項目には普遍的な表現が選定で
き、それらの項目のうち、特定の項目間の競合条件を一
度確立すれば、従来のように交換機の提供するサービス
が追加されるたびに既存サービスのひとつひとつに対し
て競合するか否かの判定をする必要がなく、したがっ
て、サービス追加時の競合条件の検討の手間が少ない交
換サービス契約処理を実現することができる。

【００１３】

【実施例】以下、本発明の実施例について図面を参照し
ながら詳細に説明する。はじめに、図１によって本発明
の交換サービス契約処理方法及びその装置の概要につい
て説明する。図１は本発明の交換サービス契約処理方法
及びその装置のブロック図である。なお、図１の本発明
の交換サービス契約処理のブロック図は、交換サービス
契約処理のソフトウェア構造を説明するものである。

【００１４】図１において、１は入出力処理部、２は名
称・目的要素変換部、３は名称・目的要素変換データ
部、４は論理比較部、５は情報蓄積部、６は更新部、３
０は名称・目的要素変換テーブル、５０は既契約サービ
ス情報である。図１において、まず契約するサービスの
内容を特定するために、そのサービスに関する記述を入
出力処理部１に入力する。この記述形式として、サービ
スの名称とサービスの個々の内容を表す目的要素があ
る。この目的要素はサービスの内容を細分化したもので
あり、これについては後に詳細に説明する。

【００１５】このサービスに関する記述は名称・目的要
素変換部２において名称・目的要素変換データ部３内に
記憶されている名称・目的要素変換テーブル３０のデー
タ内容との参照を行うことにより、名称と目的要素との
間の交換が行われる。例えばサービスが名称で記述され
ている場合にはその名称に対応する目的要素に変換し、
またサービスが目的要素によって記述されている場合に
はその目的要素あるいはその組合せに対応する名称に変
換する。

【００１６】次に、論理比較部４において、名称・目的
要素変換部２において得られたサービスの名称、及びサ
ービスの目的要素は、情報蓄積部５の既契約サービス情
報５０に蓄積されている契約者ごとの既契約サービスの
名称、あるいはそのサービスの目的要素と論理比較され
る。この論理比較により、既契約サービスと契約要求の
あった新たなサービスとが同時契約可能か否かの判定が
行われる。

【００１７】同時契約が可能な場合には、更新部６によ
って情報蓄積部５に記憶されている既契約に関するサー
ビスの情報を更新する。次に、本発明の交換サービス契
約処理方法及びその装置についての説明に先立って、本
発明が取り扱うサービスの構造について説明する。本発
明においては、サービスという処理対象物を以下に説明
するデータ構造とすることによって演算器等による処理
を可能としている。

【００１８】図２は、本発明のサービスのデータ構造図
である。図２において、一つのサービスは幾つかの目的
要素に細分化され、それらの目的要素の連結によって表
される。この目的要素は、サービスの基本的な目的であ
り、目的条件と目的動作の二種類に分けられる。目的条
件は、その目的をどのような場合に達成したいかを表す
ものであり、目的動作は、その目的を達成するためにど
のようなことをするのかを表すものである。したがっ
て、サービスは一つの目的条件あるいは複数個の目的条
件群と、一つの目的動作あるいは複数個の目的動作の組
合せによって構成される。

【００１９】さらに、この目的条件は、なにを（なに
が）、いくつ、だれへ、だれから、いつ、どこへ、どこ
から、どうする（どうした）という項目に細分化され
る。そして、これらの項目（以下、目的項目という）を
それぞれＣＷｈａｔ、ＣＨｏｗＭａｎｙ、ＣＴｏＷｈｏ
ｍ、ＣＦｒｏｍＷｈｏｍ、ＣＷｈｅｎ、ＣＴｏＷｈｅｒ
ｅ、ＣＦｒｏｍＷｈｅｒｅ、ＣＨｏｗにより表現するこ
とにする。

【００２０】この目的項目はさらに項目に分解される。
この分解された項目は、既存のサービス及び将来出現す
るであろうと考えられるサービスを普及的に記述できる
ものが選定される。図３は、本発明の目的条件の目的項
目を表す表であり、例えばＣＷｈａｔの目的項目は一般
番号、特殊番号、内線番号、パーソナル番号、全国統一
番号、フッキング、呼、発信者、着信者、現在時刻、サ
ービス使用数等の最小単位の項目からなっている。

【００２１】その他のＣＨｏｗＭａｎｙ、ＣＴｏＷｈｏ
ｍ、ＣＦｒｏｍＷｈｏｍ、ＣＷｈｅｎ、ＣＴｏＷｈｅｒ
ｅ、ＣＦｒｏｍＷｈｅｒｅ、ＣＨｏｗの目的項目につい
ても、図３に示される最小単位の項目からなる。つま
り、これらの最小単位の項目によって目的項目が構成さ
れ、さらにこの目的項目により目的条件が構成されてい
る。

【００２２】また、目的動作は、なにを（なにが）、い
くつ、だれから、いつ、どこへ、どうする（どうした）
という項目に細分化される。そして、これらの項目（以
下、目的項目という）をそれぞれＡＷｈａｔ、ＡＨｏｗ
Ｍａｎｙ、ＡＴｏＷｈｏｍ、ＡＷｈｅｎ、ＡＴｏＷｈｅ
ｒｅ、ＡＨｏｗにより表現することにする。この目的項
目についても、前記目的条件の目的項目と同様にさらに
最小単位の項目に分解される。この項目として、既存の
サービス及び将来出現するであろうと考えられるサービ
スを普及的に記述できるものが選定される。

【００２３】図４は、本発明の目的条件の目的項目を表
す表であり、例えばＡＷｈａｔの目的項目は発信者、着
信者、呼、通話料、情報料、呼情報、通信情報、付加情
報、ガイダンス、呼出音、会議、サービスパラメータ等
の項目からなっている。その他のＡＨｏｗＭａｎｙ、Ａ
ＴｏＷｈｏｍ、、ＡＷｈｅｎ、ＡＴｏＷｈｅｒｅ、ＡＨ
ｏｗの目的項目についても、図４に示される最小単位の
項目からなる。

【００２４】つまり、これらの最小単位の項目によって
目的項目が構成され、さらにこの目的項目により目的動
作が構成されている。本発明においては、サービスを前
記のようなデータ構造によって構成し、このデータ構造
を以下に示すようなサービス記述方法の文法によって記
述する。このデータ構造とサービス記述方法の文法によ
り、サービス内容の確認や、契約時等における他の契約
のサービス内容との識別を行う論理演算処理を可能とし
ている。

【００２５】次に、サービスを記述する記述方法の文法
について説明する。この記述方法の文法は、サービスの
内容を前記したデータ構造にしたがって生成する生成規
則を定めるものであり、一般にバッカス記法（ＢＮＦ）
と呼ばれる記法に基づいている。本発明においては、例
えば、＜＞は非終端記号であることを示しており、その
囲む部分がさらに生成規則を適用することによってさら
に細かく分解することができることを意味している。ま
た、この＜＞で囲まれていない部分は終端記号であるこ
とを示しており、これ以上細分化されない最終的な表現
であることを意味している。｛｝はその囲む部分が０回
以上繰り返せることを、［］はその囲む部分が省略可能
であることを、｜はその前後の記号のうちいずれかを選
択することを、＋は各要素を連結することを、●及び、
は各要素間の区切りを、：：＝は定義をそれぞれ表して
いる。

【００２６】なお¬は否定を表しており、””はその囲
む部分が終端記号であるが｛や［などのメタ記号と同一
の記号を用いている場合に混同を避けるために用いてい
る。前記の記法によれば、前記図２に示すサービスのデ
ータ構造は以下のように表記することができる。例え
ば、サービスについては、 ＜サービス＞：：＝＜目的要素＞｛＋＜目的要素＞｝ …（１） によって定義される。これは、処理対象のサービスが一
つの目的要素あるいは複数の目的要素の連結によって構
成されることを意味している。

【００２７】そして、この目的要素は、 ＜目的要素＞：：＝＜目的条件＞｛＋＜目的条件＞｝●＜目的動作＞｛＋＜目的 動作＞｝ …（２） によって定義される。これは、目的要素が一つの目的条
件あるいは複数の目的条件の連結したものと、一つの目
的動作あるいは複数の目的動作の連結したものとによっ
て構成されることを意味している。

【００２８】この内、目的条件は、 ＜目的条件＞：：＝（＜ＣＷｈａｔ＞、［＜ＣＨｏｗＭａｎｙ＞］、［＜ＣＴｏ Ｗｈｏｍ＞］、［＜ＣＦｒｏｍＷｈｏｍ＞］、［＜ＣＷｈｅ ｎ＞］、［＜ＣＴｏＷｈｅｒｅ＞］、［＜ＣＦｒｏｍＷｈｅ ｒｅ＞］、［¬］＜ＣＨｏｗ＞） …（３） によって定義される。また、目的動作は、 ＜目的動作＞：：＝”［”＜ＡＷｈａｔ＞、［＜ＡＨｏｗＭａｎｙ＞］、［＜Ａ ＴｏＷｈｏｍ＞］、［＜ＡＷｈｅｎ＞］、［＜ＡＴｏＷｈｅ ｒｅ＞］、［¬］＜ＡＨｏｗ＞”］” …（４） によって定義される。

【００２９】さらに、目的条件を細分化している各目的
項目であるＣＷｈａｔ、ＣＨｏｗＭａｎｙ、ＣＴｏＷｈ
ｏｍ、、ＣＷｈｅｎ、ＣＴｏＷｈｅｒｅ、ＣＨｏｗは、
それぞれ以下のように定義される。 ＜ＣＷｈａｔ＞：：＝一般番号｜特殊番号｜内線番号｜パーソナル番号｜全国統 一番号｜フッキング｜呼｜発信者｜着信者｜現在時刻｜サ ービス使用数 …（５） ＜ＣＨｏｗＭａｎｙ＞：：＝任意個｜０個｜１個｜２個｜指定個｜複数個 …（６） ＜ＣＴｏＷｈｏｍ＞：：＝誰へでも｜指定電番へ｜指定グループへ｜指定者へ｜ 指定グループ以外へ｜指定者以外へ …（７） ＜ＣＦｒｏｍＷｈｏｍ＞：：＝誰からでも｜指定電番から｜指定グループから｜ 指定者から｜指定グループ以外から｜指定者以外 から …（８） ＜ＣＷｈｅｎ＞：：＝いつでも｜指定時刻｜指定時間｜指定曜日｜指定日｜通話 中｜不在時｜移動中 …（９） ＜ＣＴｏＷｈｅｒｅ＞：：＝どこへでも｜指定地域へ …（１０） ＜ＣＦｒｏｍＷｈｅｒｅ＞：：＝どこからでも｜指定地域から …（１１） ＜ＣＨｏｗ＞：：＝ダイヤルする｜入力する｜発信する｜着信する｜呼び出す｜ 応答する｜開始する｜終了する｜保留する｜超える｜下回る｜合致する …（１２） また、目的動作を細分化している各目的項目であるＡＷ
ｈａｔ、ＡＨｏｗＭａｎｙ、ＡＴｏＷｈｏｍ、ＡＷｈｅ
ｎ、ＡＴｏＷｈｅｒｅ、ＡＨｏｗは、それぞれ以下のよ
う定義される。 ＜ＡＷｈａｔ＞：：＝発信者｜着信者｜呼｜通話料｜情報料｜呼情報｜通信情報 ｜付加情報｜ガイダンス｜呼出音｜会議｜サービスパラメータ …（１３） ＜ＡＨｏｗＭａｎｙ＞：：＝０個｜１個｜２個｜指定個｜指定割合｜全て …（１４） ＜ＡＴｏＷｈｏｍ＞：：＝指定電番へ｜指定順の電番へ｜指定グループへ｜指定 者へ｜指定グループ外へ｜サービス契約者へ｜発信者 へ …（１５） ＜ＡＷｈｅｎ＞：：＝指定時刻｜指定時間｜終話時 …（１６） ＜ＡＴｏＷｈｅｒｅ＞：：＝指定地域へ｜移動先へ …（１７） ＜ＡＨｏｗ＞：：＝接続する｜転送する｜変換する｜変更する｜表示する｜蓄積 する｜予約する｜課金する｜計数する｜報告する｜分配する｜ 待ち合わせる｜規制する｜認証する｜送出する｜記憶する｜保 留する｜徴収する …（１８） 前記のサービスを記述する記述方法によれば、例えばサ
ービスを受けている端末に着信があった場合、無条件に
指定された電話番号に転送する着信転送サービスは、次
のように表される。 着信転送：：＝（呼、、指定電番へ、誰からでも、いつでも、どこからでも、着 信する）●［呼、、指定電番へ、、、転送する］…（１９） また、サービスを受けている端末に指定時間帯に着信が
あった場合、指定された電話番号に転送する時間指定着
信転送サービスは、次のように表される。 時間指定着信転送：：＝（呼、、指定電番へ、誰からでも、指定時間、、どこか らでも、着信する）●［呼、、指定電番へ、、、転送す る］ …（２０） 本発明の交換サービス契約処理方法及びその装置におい
ては、前記の記述方法に対応して演算の論理を組むこと
によって、以後の処理を行うことができる。

【００３０】次に、本発明の交換サービス契約処理の処
理手順について前記図１及び図５の本発明の交換サービ
ス契約処理のフローチャート、図６の本発明のサービス
名称・目的要素変換データを表す表、図７及び図８の本
発明の交換サービス契約処理のブロック図における流れ
図、図９の本発明のサービス競合判定処理のフローチャ
ート、図１０の本発明の目的条件パターン表、及び図１
１の本発明の目的動作パターン表を用いて説明する。

【００３１】本発明の交換サービス契約処理の処理手順
は、図１に示すように処理対象である契約しようとする
サービスを入力する部分と、この入力に対するサービス
の名称と目的要素を得る部分と、このサービスの名称と
目的要素に基づいて他のサービス契約との論理的関係を
比較し判定する部分と、この論理比較部の結果に基づい
てサービス契約の情報を更新する部分に大別される。

【００３２】以下、図５の本発明の交換サービス契約処
理のフローチャートの各ステップにしたがって説明す
る。 ステップＳ１：図１の入出力処理部１に対して契約しよ
うとするサービスを入力する。この場合、例えばサービ
ス契約用の端末（図示していない）からサービス契約の
要求が入力されると、入出力処理部１で受け付けを行
う。

【００３３】その際、所望のサービスの名称を知らない
場合、あるいは不明確な場合には目的要素によってサー
ビスを記述し、一方サービス内容を十分に理解しその名
称を認識している場合にはサービスの名称もしくは目的
要素によってサービスを記述する。 ステップＳ２：次に、図１の名称・目的要素変換部２に
おいて、サービスの記述形式の判定を行う。

【００３４】この判定において、入出力処理部１から入
力されるサービスが名称である場合にはステップＳ３に
進み、入出力処理部１から入力されるサービスが目的要
素である場合にはステップＳ４に進む。 ステップＳ３：サービスが名称によって入力された場合
に、この名称を対応する目的要素に変換して、名称と目
的要素の両方のデータを得る。このステップにおいて、
サービスの特定において名称の他に目的要素のデータを
得ているのは、この以後のステップでの他の契約サービ
スとの論理的関係の比較、判定を目的要素によって行う
からである。

【００３５】この名称から目的要素への変換は、図１の
名称・目的要素変換データ部３中の名称・目的要素変換
テーブル３０を、前記名称をキーワードとしてサーチ
し、対応する目的要素を検索することによって行われ
る。この名称・目的要素変換テーブル３０は、例えば図
６の本発明のサービス名称・目的要素変換データを表す
表に示されるように構成しておくことができ、名称の欄
をサーチして対応する目的要素を知ることができる。

【００３６】この変換処理を装置上において実現するに
は、通常のメモリの応用技術によって行うことができ、
メモリのデータ構成に応じて種々のものが可能である。
例えば、名称・目的要素変換テーブル３０の名称をアド
レスとしてそのアドレスの内容を出力することによって
行うことができる。この名称から目的要素への変換につ
いて、図７の本発明の交換サービス契約処理のブロック
図における流れ図によって説明する。

【００３７】図７において、名称から目的要素への変換
及びその出力は破線によって表されている。入出力処理
部１に入力されたサービスが名称Ａであるとすると、そ
の名称Ａは名称・目的要素変換部２を介して出力される
とともに、名称・目的要素変換データ部３に入力され
る。名称・目的要素変換データ部３では、名称・目的要
素変換テーブル３０をサーチして入力された名称Ａに対
応する目的要素ａ…ｍ…ｕを検索し、再び名称・目的要
素変換部２を介してその目的要素ａ…ｍ…ｕを出力す
る。したがって、名称・目的要素変換部２からは名称Ａ
と目的要素ａ…ｍ…ｕの両方のデータが出力されること
になる。

【００３８】この名称Ａと目的要素ａ…ｍ…ｕの両方の
データは、そのまま出力することにより名称Ａに対する
目的要素の内容ａ…ｍ…ｕの確認を行うことができる。
また、名称Ａと目的要素ａ…ｍ…ｕの両方のデータは、
論理比較部４において、情報蓄積部５に記憶されている
既契約サービス情報５０との論理的比較が行われ、入力
されたサービスが既に契約済のものであるかあるいは同
時契約が可能か否か等の判定が行われる。

【００３９】ステップＳ４：サービスが目的要素によっ
て入力された場合に、この目的要素を対応する名称に変
換して、名称と目的要素の両方のデータを得る。このス
テップにおいて、サービスの特定において目的要素の他
に名称のデータを得ているのは、この以後のステップで
の既に契約済のサービスであるか否かの論理的な比較、
判定を名称によって行うからである。

【００４０】この目的要素から名称への変換は、図１の
名称・目的要素変換データ部３中の名称・目的要素変換
テーブル３０を、前記目的要素をキーワードとしてサー
チし、対応する名称を検索することによって行われる。
この名称・目的要素変換テーブル３０は、前記図６の本
発明のサービス名称・目的要素変換データを表す表に示
されるように構成しておくことができ、この表において
目的要素の欄をサーチし、対応する名称を知ることがで
きる。

【００４１】なお、この目的要素から名称への変換にお
いては、入力された目的要素に対して候補となる名称が
複数個存在する場合がある。そこで、この複数個の名称
の中から所望のサービスを特定するために、名称・目的
要素変換部２は入出力処理部１に対して必要とする目的
要素の項目を指示したり、候補の名称を提示する等の処
理を行い、サービスの名称を特定するのに十分な目的要
素の項目が追加して入力される。

【００４２】これらの変換処理を装置上において実現す
るには、前記と同様に通常のメモリの応用技術によって
行うことができ、メモリのデータ構成に応じて種々のも
のが可能である。例えば、名称・目的要素変換テーブル
３０の名称を複数のアドレスによって設定しておき、そ
のアドレスを目的要素とすることによって行うことがで
きる。

【００４３】この目的要素から名称への変換について、
図８の本発明の交換サービス契約処理のブロック図にお
ける流れ図によって説明する。図８において、目的要素
から名称への変換及びその出力の流れは破線によって表
されている。入出力処理部１に入力されたサービスが目
的条件ａであるとすると、その目的条件ａは名称・目的
要素変換部２を介して出力されるとともに、名称・目的
要素変換データ部３に入力される。

【００４４】名称・目的要素変換データ部３では、名称
・目的要素変換テーブル３０をサーチして入力された目
的要素ａが存在する名称Ａ…等を検索する。入力された
目的要素ａによって一つの名称が特定されるときには、
その名称Ａを出力する。一方、入力された目的要素ａの
みでは一つの名称が特定されないときには、その複数個
の候補である名称Ａ…の中から一つを特定するために必
要な目的要素を入出力処理部１に対して要求する。この
要求に応じて入出力処理部１から目的動作ｕを入力する
と、再び名称・目的要素変換データ部３において検索が
行われ、名称Ａが出力される。

【００４５】したがって、名称・目的要素変換部２から
は名称Ａと目的要素ａ…ｍ…ｕの両方のデータが出力さ
れることになる。この名称Ａと目的要素ａ…ｍ…ｕの両
方のデータの出力によって、前記図７と同様に名称Ａに
対応する目的要素の内容ａ…ｍ…ｕの確認を行うことが
できる。また、名称Ａと目的要素ａ…ｍ…ｕの両方のデ
ータは、論理比較部４において、情報蓄積部５に記憶さ
れている既契約サービス情報との論理的比較が行われ、
入力されたサービスが既に契約済のものであるかあるい
は同時契約が可能か否か等の判定が行われる。

【００４６】したがって、この段階では、前記ステップ
Ｓ３及びステップＳ４によって、サービスの名称Ａと目
的要素ａ…ｍ…ｕの両方のデータが得られている。この
データを用いて、はじめにステップＳ５及びステップＳ
６によって入力されたサービスが既に契約済のサービス
か否かの判定を行い、次にステップＳ５及びステップＳ
７によって入力されたサービスが既に契約済のサービス
の目的要素と競合するか否かの判定を行う。

【００４７】ステップＳ５：図１の論理比較部４に情報
蓄積部５から既契約サービス情報を読み込む。この既契
約サービス情報には、既に契約されているサービスの名
称と目的要素が記憶されている。 ステップＳ６：入出力処理部１から入力されたサービス
の名称と、前記ステップＳ５により情報蓄積部５から入
力された既契約サービス情報のサービスの名称を論理比
較する。

【００４８】この論理比較は、図１の論理比較部４にお
いて行われるが、ソフトウェアによって論理回路を構成
して実現することができる。また、ハードウェアよって
論理を構成することによって実現することも可能であ
る。入力されたサービスが既契約サービスでない場合に
はステップＳ８に進み、図１の既契約サービス情報５０
の更新を行う。

【００４９】一方、入力されたサービスが既契約サービ
スである場合にはステップＳ７に進み、その入力された
サービスが既契約サービスに対応する目的要素と競合す
るか否かの判定を行う。 ステップＳ７：このステップにおけるサービス競合判定
処理について、図１０の本発明の目的条件パターンを表
す表、及び図１１の本発明の目的動作パターンを表す表
を参照しながら図９の本発明のサービス競合判定処理の
フローチャートにしたがって説明する。

【００５０】ステップＳ１１：以下のステップＳ１２か
らステップＳ１４において、入出力処理部１から入力さ
れる新しい契約サービスの全目的要素について、既契約
サービスの全目的要素との論理比較を新しい契約サービ
スごとに行う。以下のステップにおいては、目的条件と
目的動作の二つの目的要素の内、はじめに目的条件につ
いて競合判定処理を行い、次に目的動作について競合判
定処理を行う。なお、以下新しい契約サービスの目的要
素を基準目的要素という。

【００５１】ステップＳ１２：はじめに、目的条件につ
いて競合判定処理を行う。ここで、競合とは二つの同一
の目的要素の項目の内容が同時に起こった場合に、論理
的に不都合が生じることを意味している。例えば、ＣＨ
ｏｗの目的要素ににおいて、一方が開始するのに対して
他方が終了するという項目の場合に、この二つの動作が
同時に起こると動作が不能あるいは不安定となる。した
がって、この目的要素間には競合があることになる。

【００５２】基準目的要素の目的条件（以下、基準目的
条件という）と既に契約しているサービスの目的条件と
の間に競合があるか否かの判定は、まず基準目的条件に
競合の可能性がある基準目的条件パターンが含まれるか
否かについて、図１０の（ａ）で示される基準目的条件
パターン表のパターンと合致するパターンがあるか照合
し、さらに図１０の（ｂ）で示される競合基準目的条件
パターン表のパターンと合致するパターンがあるか照合
する。

【００５３】この基準目的条件パターン表及び競合基準
目的条件パターン表は、あらかじめ論理比較部４あるい
は情報蓄積部５に記憶しておくことができるものであ
り、サービスの目的条件に対して競合の可能性のあるパ
ターンをあらかじめ検討して設定しておくものである。
そして、この照合に際しては、図１０の（ａ）の基準目
的条件パターン表中で“−”で記述されている以外の目
的項目のみを比較することによって行われる。

【００５４】基準目的条件パターン表のパターンと合致
しない場合は、目的条件に競合するパターンはなくＮｏ
と判定されて、次にステップＳ１４に進み、次に目的動
作に競合するパターンがあるか否かの判定を行う。一
方、基準目的条件パターン表のパターンと合致する場合
には、さらにそのパターンに対応する図１０の（ｂ）の
競合目的条件パターン表において、既に契約しているサ
ービスの目的条件と合致するパターンがあるかを照合す
る。

【００５５】ここで、図１０の（ｂ）の競合目的条件パ
ターン表は、既に契約しているサービスの目的条件を表
記したものであり、前記図１０の（ａ）の基準目的条件
パターン表に対応して設けられている。そして、この図
１０の（ｂ）の競合目的条件パターン表と図１０の
（ａ）の基準目的条件パターン表との対応は、図１０の
（ａ）の基準目的条件パターン表に設けられたポインタ
の記載されたアドレスによって行われ、このアドレスは
図１０の（ｂ）の競合目的条件パターン表の先頭アドレ
スを示している。

【００５６】したがって、図１０の（ａ）の基準目的条
件パターン表のパターンと合致する場合は、その基準目
的条件パターン表のポインタの示すアドレスによって対
応する図１０の（ｂ）の競合目的条件パターン表の先頭
アドレスを呼び出し、その競合目的条件パターン表のパ
ターンと合致するパターンがあるかを照合する。この図
１０の（ｂ）の競合目的条件パターン表のパターンと合
致しない場合には、目的条件に競合するパターンはない
と判定され、ステップＳ１４に進む。

【００５７】一方、図１０の（ｂ）の競合目的条件パタ
ーン表のパターンと合致する場合には、目的条件に競合
するパターンがあって競合の可能性があると判定され、
次のステップＳ１３においてその競合が契約者の指定す
る時間帯などのパラメータによって回避できるかを判定
する。 ステップＳ１３：この指定パラメータ範囲による競合の
回避は、例えば、図１０の（ａ）において基準目的条件
が“呼、、…、指定時間、着信する”のパターンと合致
するパターンを含む場合、この基準目的条件のパターン
に継続している図１０の（ｂ）の競合目的条件パターン
表において、既に契約しているサービスの競合目的条件
に“呼、、…、いつでも、着信する”なるパターンがあ
る場合、あるいは“呼、、…指定時間、着信する”なる
パターンでその指定時間に重なりがある場合には競合の
可能性があることになる。しかしながら、前記と同じ
“呼、、…指定時間、着信する”なるパターンであって
も、基準目的条件と既に契約しているサービスの目的条
件の“指定時間”において時間帯がずれていて、時間的
な重なりがなければ競合は回避可能となる。

【００５８】したがって、指定パラメータ範囲の比較に
おいて競合が回避可能である場合には、サービスの競合
は無いと判定してステップＳ１４に進む。一方、指定パ
ラメータ範囲の比較においても競合が回避不可能である
場合には、サービス競合ありと判定され、図５のステッ
プＳ７の既契約サービスの対応する目的要素との競合が
あると判定されて、サービス契約は行われず終了する。

【００５９】したがって、目的条件に競合するパターン
がないか、あるいは競合するパターンがあっても指定パ
ラメータ範囲によって競合の回避が可能な場合には、さ
らに図９の次のステップＳ１４において目的動作に競合
するパターンがあるか否かの判定が行われる。 ステップＳ１４：前記ステップＳ１２及びステップＳ１
３によって、二つの目的要素の内の目的条件について競
合するパターンの判定が終了したので、次にもう一つの
目的動作について競合するパターンがあるか否かの判定
を行う。

【００６０】この目的動作において競合するパターンの
判定は、図１１の（ａ）の基準目的動作パターン表及び
図１１の（ａ）の競合目的動作パターン表を用いて、前
記目的条件の判定の場合と同様のパターンの照合により
行われる。基準目的要素の目的動作（以下、基準動作条
件という）と既に契約しているサービスの目的動作との
間に競合があるか否かの判定は、まず基準目的動作に競
合の可能性がある基準目的動作パターンが含まれるか否
かについて、図１１の（ａ）で示される基準目的動作パ
ターン表について照合し、さらに図１１の（ｂ）で示さ
れる競合基準目的動作パターン表と照合することにより
行われる。

【００６１】この基準目的動作パターン表及び競合目的
動作パターン表は、あらかじめ論理比較部４あるいは情
報蓄積部５に記憶しておくことができるものであり、入
力されたサービスの目的動作に対して競合の可能性のあ
るパターンをあらかじめ検討して設定しておくものであ
る。そして、この照合に際しては、図１１の（ａ）の基
準目的動作パターン表中で“−”で記述されている以外
の目的項目のみを比較することによって行われる。

【００６２】図１１の（ａ）の基準目的動作パターン表
のパターンと合致しない場合は、目的動作に競合するパ
ターンはなくＮｏと判定され、ステップＳ７においてサ
ービスの競合はないと判定され、次のステップＳ８に進
む。一方、基準目的動作パターン表のパターンと合致す
る場合は、さらにそのパターンに対応する図１１の
（ｂ）の競合目的動作パターン表において、既に契約し
ているサービスの目的動作と合致するパターンがあるか
を照合する。

【００６３】ここで、図１１の（ｂ）の競合目的動作パ
ターン表は、既に契約しているサービスの目的動作を表
記したものであり、前記図１１の（ａ）の基準目的動作
パターン表に対応して設けられている。そして、この図
１１の（ｂ）の競合目的動作パターン表と図１１の
（ａ）の基準目的動作パターン表との対応は、図１１の
（ａ）の基準目的動作パターン表に設けられたポインタ
に記載されたアドレスによって行われる。このアドレス
は図１１の（ｂ）の競合目的動作パターン表の先頭アド
レスを示している。

【００６４】したがって、基準目的動作パターン表のパ
ターンと合致する場合は、その基準目的動作パターン表
のポインタの示すアドレスによって対応する競合目的動
作パターン表の先頭アドレスを呼び出し、その競合目的
動作パターン表のパターンと合致するパターンがあるか
を照合する。この図１１の（ｂ）の競合目的動作パター
ン表のパターンと合致しない場合には、目的動作に競合
するパターンはないと判定され、図９の次のステップＳ
１４に進む。

【００６５】一方、図１０の（ｂ）の競合目的動作パタ
ーン表のパターンと合致する場合には、目的動作に競合
するパターンがあり競合の可能性があると判定され、図
５のステップＳ７において既契約サービスと対応する目
的要素と競合すると判定され、サービスの契約を行わ
ず、処理を終了する。そして、全ての基準目的要素と既
に契約しているサービスの全目的要素の間において、目
的条件上も目的動作上も競合がない場合、サービス競合
なしとして処理が終了する。

【００６６】前記ステップＳ７における競合判定は、図
１の論理比較部４において行われるが、ソフトウェアに
よって論理回路を構成して実現することができる。また
ハードウェアによって論理を構成してことも実現するこ
とも可能である。 ステップＳ８：前記ステップＳ６及びステップＳ７にお
いて、競合しないと判定された場合は更新部６によって
情報蓄積部５内の既契約サービス情報の更新が行われ、
サービス契約が完了する。

【００６７】次に、交換機の提供するサービスが追加さ
れた場合について説明する。交換機の提供するサービス
が追加された場合には、図６のサービス名称・目的要素
変換表に、そのサービス名称とそのサービスの目的要素
による記述を追加する。そして、装置上においてはこの
サービス名称・目的要素変換表の追加は、図１の名称・
目的要素交換データ部３の名称・目的要素変換テーブル
３０を更新することによって行われる。

【００６８】これによって、追加されたサービスに対応
した名称と目的要素の変換処理を行うことができる。ま
た、交換機の提供するサービスが追加された場合、その
サービスに対応する目的条件、目的動作が既に存在する
図１０の（ａ）の基準目的条件パターン表、、図１１の
（ａ）の基準目的動作パターン表のパターンに合致する
場合には、図１０の（ａ）の基準目的条件パターン表及
び（ｂ）の競合目的条件パターン表、図１１の（ａ）の
基準目的動作パターン表及び（ｂ）の競合目的条件パタ
ーン表は変更しない。

【００６９】一方、そのサービスに対応する目的条件、
目的動作が既に存在する図１０の（ａ）の基準目的条件
パターン表、、図１１の（ａ）の基準目的動作パターン
表のパターンに合致しない場合には、図１０の（ａ）の
基準目的条件パターン表及び（ｂ）の競合目的条件パタ
ーン表、図１１の（ａ）の基準目的動作パターン表及び
（ｂ）の競合目的条件パターン表は変更する場合が生じ
る。

【００７０】なお、この交換機の提供するサービスの追
加については、サービスの機能そのものの追加とサービ
ス機能の組合せの追加の二種類があるが、何れの場合に
おいても、前記したように追加の処理を行うことがで
き、一たんこの追加処理を行ってしまえばその後はその
更新したデータによって交換サービス契約処理を行うこ
とができる。

【００７１】なお、本発明は上記実施例に限定されるも
のではなく、本発明の趣旨に基づいて種々変形すること
が可能であり、これらを本発明の範囲から排除するもの
ではない。

【００７２】

【発明の効果】以上、詳細に説明したように本発明によ
れば、サービス契約者自身の所望するサービスをその目
的の記述によって特定することができ、従来のようにサ
ービスの特定のためにサービスの名称を表す必要がな
い。したがってサービスの名称とその内容を十分理解し
ていない場合においても、サービスの目的要素によって
サービスを特定することができ、交換機のサービスの契
約においてそのサービスの目的要素によって交換サービ
ス契約処理を実現することができる。

【００７３】また、サービスの目的を細分化して記述す
るため細分化された各項目には普遍的な表現が選定で
き、それらの項目のうち、特定の項目間の競合条件を一
度確立すれば、従来のように交換機の提供するサービス
が追加されるたびに既存サービスのひとつひとつに対し
て競合するか否かの判定をする必要がなく、したがっ
て、サービス追加時の競合条件の検討の手間が少ない交
換サービス契約処理を実現することができる。

【図面の簡単な説明】

【図１】本発明の交換サービス契約処理方法及びその装
置のブロック図である。

【図２】本発明のサービスのデータ構造図である。

【図３】本発明の目的条件の目的項目を表す表である。

【図４】本発明の目的条件の目的項目を表す表である。

【図５】本発明の交換サービス契約処理のフローチャー
トである。

【図６】本発明のサービス名称・目的要素変換データを
表す表である。

【図７】本発明の交換サービス契約処理のブロック図に
おける流れ図である。

【図８】本発明の交換サービス契約処理のブロック図に
おける流れ図である。

【図９】本発明のサービス競合判定処理のフローチャー
トである。

【図１０】本発明の目的条件パターンを表す表である。

【図１１】本発明の目的動作パターンを表す表である。

【図１２】従来の標準サービスと比較サービスの比較一
覧表である。

【符号の説明】

１ 入出力処理部 ２ 名称・目的要素変換部 ３ 名称・目的要素変換データ部 ４ 論理比較部 ５ 情報蓄積部 ６ 更新部 ３０ 名称・目的要素変換テーブル ５０ 既契約サービス情報

Claims (5)

【特許請求の範囲】
1. 【請求項１】 交換機の提供するサービスの契約処理方
   法において、（ａ）前記サービスをサービスを特定する
   名称とそのサービスの内容を細分化した目的要素とによ
   って構成されるデータ構造とし、（ｂ）処理対象のサー
   ビスをその名称あるいは細分化した目的要素によって特
   定して入力し、（ｃ）前記入力された処理対象の名称あ
   るいは目的要素を目的要素あるいは名称に変換して、前
   記処理対象のサービスに関する名称及び目的要素の両方
   のデータを出力し、（ｄ）前記処理対象のサービスに関
   する名称及び目的要素のデータと、既に契約しているサ
   ービスの名称及び目的要素のデータとを論理比較するこ
   とによって、既契約のサービスと前記処理対象のサービ
   スの同時契約の可能性を判定することを特徴とする交換
   サービス契約処理方法。
2. 【請求項２】 交換機の提供するサービスの契約処理方
   法において、（ａ）前記サービスをサービスを特定する
   名称とそのサービスの内容を細分化した目的要素とによ
   って構成されるデータ構造とし、（ｂ）処理対象のサー
   ビスを細分化した目的要素を入力し、（ｃ）前記入力さ
   れた処理対象のサービスの目的要素を名称に変換し、
   （ｄ）前記処理対象のサービスの名称によってサービス
   を特定することを特徴とする交換サービス契約処理方
   法。
3. 【請求項３】 前記目的要素は、前記サービスによって
   達成される目的の条件を表す目的条件と、前記サービス
   によって達成される目的の動作を表す目的動作とからな
   る請求項１又は２記載の交換サービス契約処理方法。
4. 【請求項４】 交換サービス契約処理装置において、
   （ａ）前記サービスをサービスを特定する名称とそのサ
   ービスの内容を細分化した目的要素とによって構成され
   るデータ構造とし、（ｂ）処理対象のサービスをその名
   称あるいは細分化した目的要素として入力を受け付ける
   入出力処理部と、（ｃ）前記入力された処理対象の名称
   あるいは目的要素を目的要素あるいは名称に変換して、
   前記処理対象のサービスに関する名称及び目的要素の両
   方のデータを出力する名称・目的要素変換部と、（ｄ）
   既契約のサービスの名称及び目的要素のデータを記憶し
   ておく情報蓄積部と、（ｅ）前記処理対象のサービスに
   関する名称及び目的要素のデータと、前記情報蓄積部か
   ら得られるサービスの名称及び目的要素のデータとを論
   理比較することによって、前記処理対象のサービスと既
   契約のサービスの同時契約の可能性を判定する論理比較
   部とからなることを特徴とする交換サービス契約処理装
   置。
5. 【請求項５】 前記名称・目的要素変換部は、サービス
   の名称と目的要素の変換データを有している請求項４記
   載の交換サービス契約処理装置。