JPH0765019A

JPH0765019A - データベースサービス方法およびそれを利用したサービス制御装置

Info

Publication number: JPH0765019A
Application number: JP5237384A
Authority: JP
Inventors: Kazumichi Yamamoto; 一道山本; Hiroaki Odawara; 宏明小田原; Shiro Tanabe; 史朗田辺
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 1993-08-30
Filing date: 1993-08-30
Publication date: 1995-03-10

Abstract

(57)【要約】【目的】インテリジェント・ネットワークを構成するサ
ービスコントロールポイント用データベースサーバにお
いて、問い合わせに対する応答時間を短縮することを目
的とする。【構成】呼制御を実行するタスク１０に対するデータベ
ースサービスを専門に行うデータベースサービスタスク
２を生成する。このタスク中にはバッファ１５，１６を
設ける。バッファ１５，１６には、問い合わせの対象と
なったレコードやアドレスを複写する。呼制御から同一
レコードへの問い合わせがあれば、これらのバッファを
利用して処理し、応答時間を短縮する。また、タスク２
は呼制御タスク１０が実行している通信サービスの内容
に従って問い合わせのフローを先取りし、可能ならば必
要なレコードを先読みし、バッファ１５，１６に複写し
ておくことにより、応答時間を短縮する。このように呼
制御タスクとデータベースサービスタスクとを１対１に
対応付ける。【効果】呼処理サーバからの問い合わせに対する応答時
間を短縮出来る。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、インテリジェント・ネ
ットワークのサービスコントロールポイントＳＣＰにお
けるデータベースサービス方法およびそれを利用したサ
ービス制御装置に関し、特に呼制御に関するデータベー
スサービスに用いて好適なデータベースサービス方法お
よびそれを利用したサービス制御装置に関する。

【０００２】

【従来の技術】インテリジェント・ネットワークとは、
「インテリジェントネットワークとネットワークオペレ
ーション」（コロナ社：秋山、他著）Ｐ．１６によれ
ば「情報伝達網から高度通信サービス機能やそれに関連
する通信網制御機能を階層的に分離し、これらを通信網
を集中的に制御する情報処理・データベースセンタに移
し、このセンタを中心にして高度な通信サービスを実現
するネットワーク」と定義されている。そのようなイン
テリジェント・ネットワークにおいて、情報処理・デー
タベースセンタとして機能するのが、サービスコントロ
ールポイント（以下、「ＳＣＰ」と略記する）である。
またＳＣＰの機能を提供する装置を本明細書中において
は、「サービス制御装置」と呼んでいる。

【０００３】ＳＣＰでは、高度通信サービスをリアルタ
イムで処理しなければならない。そのため、そのデータ
ベース機能には、高い処理能力、特に高速応答性が要求
される。同時に、マルチベンダ環境におけるデータベー
スの設計、維持、および拡張の容易性を実現するため
に、標準化技術を取り入れる必要がある。

【０００４】データベースに対する問い合わせとその応
答に関するメッセージ書式等は、ＣＣＩＴＴ（国際電信
電話諮問委員会）勧告書Ｑ. １２１４により規定されて
いる。

【０００５】このようなデータベースとして、従来から
リレーショナル・データベースを改良して用いることが
提案されている。例えば、情報処理学会第４５回（平成
４年後期）全国大会予稿集ｐ．４−８１「リアルタイム
ＳＱＬにおける更新処理の最適化手法」（赤間）によれ
ば、リアルタイムな高速処理が要求される通信サービス
のために、データベース（ＤＢ）をメモリ常駐するメモ
リＤＢ方式と、必要最小限の機能に絞り込んだリアルタ
イムＳＱＬ仕様により処理を高速化する方法が提案され
ている。

【０００６】ＳＣＰは、呼制御を行う呼処理サーバと、
データベースサービスを行うデータベースサーバとを含
んで構成される。呼処理サーバとデータベースサーバ間
では、上記勧告書に従った問い合わせメッセージと、そ
れに対する応答メッセージがやり取りされる。呼処理サ
ーバから１件の問い合わせメッセージを発行すると、デ
ータベースサーバの内部で動作するプログラムまたはタ
スクが、その問い合わせメッセージに対する応答を返す
ようになっている。

【０００７】

【発明が解決しようとする課題】従来のデータベースに
おける高速化は、基本的には、１件の問い合わせメッセ
ージに対する応答を高速化するという方向で改良が進ん
できている。

【０００８】一方、呼制御の手順は、通信サービス毎に
予め定義されているので、ある呼制御においてどの様な
問い合わせが、どの様な順序で行われるかを知ることは
可能である。また、課金情報の記録等のように、１つの
呼制御において複数回参照、更新されるデータがある。
このような、呼制御に特有な問い合わせの特徴を活用す
れば、応答性を高められる可能性がある。

【０００９】従来のデータベースにおいて１件の問い合
わせに対する応答を高速化することは重要であり、今後
もそのような高速化は図られていくであろう。しかし、
上述したような観点でさらに応答を高速化するアプロー
チは、従来、行われていない。１件の問い合わせ処理の
高速化による効果が限界に達した場合、それ以上に応答
性を高めるには、このような従来とは別の観点からの高
速化を考慮することが重要である。

【００１０】本発明の目的は、これらの呼制御からの問
い合わせの特徴を活用して応答性をさらに高めることに
ある。具体的には、呼制御のフローに対応したデータベ
ースサービスを行うこと、及び一度検索あるいは参照し
たデータレコードを有効に再利用することを目的とす
る。

【００１１】

【課題を解決するための手段】上記目的を達成するた
め、本発明は、呼処理サーバ内で実行されるある呼制御
からの要求により、データベースサーバ内で複数回のデ
ータベース処理が実行される際、該呼制御に対応したデ
ータベースサーバ内のタスク（以下、データベースサー
ビスタスクと呼ぶ）によって、該データベース処理の実
行及び管理を行なうようにする。また、呼制御がデータ
ベースサービスを要求する際、該呼制御を他の呼制御か
ら区別することが可能な識別符号を、その要求メッセー
ジに付加して、要求を行なうようにする。

【００１２】データベースサーバ内では、その識別符号
を利用して他のタスクから区別されるデータベースサー
ビスタスクにより、該データベース処理の実行及び管理
を行なう。

【００１３】データベースサービスタスクにおいて、デ
ータベースから検索して得るデータレコードの内容の全
部または一部、及び該データレコードのデータベース内
でのアドレスは、該タスク内に複写して保持する。

【００１４】データベースサービスタスクと前記識別符
号により対応付けられる呼制御が実現する通信サービス
内容に従って、該通信サービスを実行するために必要な
データレコードをデータベースから検索し、該データレ
コードの内容の全部または一部、及び該データレコード
のデータベース内でのアドレスを該タスク内に複写して
保持する。

【００１５】前記呼制御による（通信サービス実行上の
必要によって行われる）データベースサービス要求の発
行の有無に拘らず、対応するデータベースサービスタス
クが自動的に前記通信サービスを実行するために必要な
データレコードをデータベースから検索する。

【００１６】前記識別符号を付加しない従来のデータベ
ースサービス要求に対しても、データベースサービスを
行う。

【００１７】ある呼制御に対応したデータベースサービ
スタスクが終了するまでは、該タスクの占める記憶領域
を、ＯＳ（オペレーティングシステム）の仮想記憶機能
の作用により主記憶装置からディスク等の外部記憶装置
へ移動させないようにタスク管理を行う。

【００１８】

【作用】上記構成によれば、ある呼制御に１対１で対応
したデータベースサービスタスクによって、該呼制御に
関するデータベース処理の実行及び管理が行われること
となる。従って、その呼制御の処理フローに対応したデ
ータベースサービスを行える。呼制御タスクからの問い
合わせ命令に識別符号を付加することにより、呼制御と
データベースサービスタスクとの対応付けが容易にな
る。

【００１９】データベースを検索して得られるデータレ
コードやデータレコードへのアドレスをデータベースサ
ービスタスク内に複写して保持することにより、同一デ
ータレコードへの問い合わせが要求された場合に、高速
に応答出来る。

【００２０】また、呼制御の処理の流れに対応したデー
タベースサービスタスク内に検索したデータレコードな
どを複写しておけるため、呼制御の処理を先取りして必
要なデータレコードを予め取得しておくこともできる。
この場合にも、予め取得しておいたデータレコードに関
する問い合わせ要求時に高速に応答できる。

【００２１】さらに、前記識別符号を付加しない従来の
問い合わせ要求に対しても、データベースサービスを行
うことにより、本発明の方法に対応していない呼処理サ
ーバに対しても従来通りのデータベースサービスを行え
る。これにより、マルチベンダ環境においても本発明を
適用することが出来る。

【００２２】また、本発明の方法を適用する装置（デー
タベースサーバ）としては、仮想記憶機能を備えたマル
チタスク計算機が考えられるが、呼制御に対応したデー
タベースサービスタスクが終了するまでは、それに割り
当てられた記憶領域を主記憶装置からディスクなどの外
部記憶装置へ移動（スワップアウト）させないようにタ
スク管理を行なう。これにより、不要なオーバヘッドを
削減し、問い合わせ要求時に高速に応答できる。

【００２３】

【実施例】以下、図面を用いて本発明の実施例を説明す
る。

【００２４】１．構成の説明

【００２５】まず、本実施例におけるネットワークの構
成、ＳＣＰの構成、及びＳＣＰ内プログラムの構成につ
いて順に説明する。

【００２６】（１）ネットワークの構成図２は、本発明の一実施例に係るデータベースサービス
方法を適用したＳＣＰを備えた公衆電話網の構成例を示
す。この公衆電話網は、インテリジェント・ネットワー
ク（以下、「ＩＮ」と略記する）２１、複数の交換機２
２、及び端末群４４により、構成される。端末群４４
は、複数の端末２４からなる。以下、各装置の機能を説
明する。

【００２７】ＩＮ２１は、交換機２２のみのネットワー
クによる従来の通信網では実現できない高度通信サービ
スを実現する。すなわち、ＩＮ２１は、データベース処
理、通信処理、及び情報処理等の機能を有し、交換機２
２を制御する。高度通信サービスとは、例えば、フリー
ダイアル等のように一般ダイアル翻訳（東京は０３、大
阪０６という具合）ではどの加入者に接続するのか特定
できない場合の処理や、指定時間転送等の個人が登録す
るデータにアクセスする場合の処理等のサービスであ
る。

【００２８】交換機２２は、そこに接続されている端末
２４間の接続を行う。また、交換機２２は、ＩＮ２１に
アクセスを要するサービス呼を検出する機能を有する。
一般基本接続呼（ＩＮ２１へのアクセスを要しないサー
ビス呼）は、交換機２２内で閉じて処理が行われる。

【００２９】端末２４は、一般的には通常の電話機であ
る。ＩＮ２１による高度通信サービスにアクセスするた
めに、端末２４には、キーボードや表示装置等の装置が
付加されていてもよい。

【００３０】ＩＮ２１は、ＳＣＰ（サービスコントロー
ルポイント）２５と、サービス管理システム（以下、
「ＳＭＳ」と略記する）２６とから成る。ＳＣＰ２５
は、交換機２２を制御し、高度通信サービスの制御を行
なう。ＳＭＳ２６は、ネットワーク保守機能を提供す
る。すなわち、ＳＭＳ２６は、保守者によるサービスの
クリエーション、及びトラヒック・課金集計等のサポー
ト処理を行なう。また、ＳＭＳ２６は、ＳＣＰ２５のバ
ックアップシステムでもある。

【００３１】（２）ＳＣＰの構成ＳＣＰ２５は、呼処理サーバ２７、データベースサーバ
３１、通信サーバ３６、及びサーバ間通信網４３から成
る。

【００３２】呼処理サーバ２７は、サービス呼の制御を
行うものである。呼処理サーバ２７は、制御プロセッサ
（図面中では「ＣＰ」と略記）２８、主記憶装置（図面
中では「ＭＭ」と略記）２９、及びサーバ間通信網イン
ターフェース（図面中では「ＩＦ」と略記）３０により
構成される。

【００３３】データベースサーバ３１は、データベース
サービスを行うものである。データベースサーバ３１
は、制御プロセッサＣＰ３２、主記憶装置ＭＭ３３、デ
ィスク（図面中では「ＤＫ」と略記）３４、及びサーバ
間通信網インターフェースＩＦ３５により構成される。

【００３４】通信サーバ３６は、交換機２２及びＳＭＳ
２６との通信を制御するものである。通信サーバ３６
は、制御プロセッサＣＰ３７、主記憶装置ＭＭ３８、及
びインタフェース部３９，４０，４１，４２から構成さ
れる。このインターフェース部は、サーバ間通信網イン
ターフェースＩＦ３９、交換機２２とのＮｏ．７共通線
インターフェースＩＦ４０，４１、及びＳＭＳ２６との
パケット網インターフェースＩＦ４２を含む。

【００３５】サーバ間通信網４３は、呼処理サーバ２
７、データベースサーバ３１、及び通信サーバ３６を相
互に接続するように構成される。

【００３６】（３）ＳＣＰ内プログラムの構成次に、本実施例の特徴であるＳＣＰ２５内のデータベー
スサーバ３１及び呼処理サーバ２７にあるプログラムの
構成について説明する。

【００３７】図１は、ＳＣＰ２５内のデータベースサー
バ３１及び呼処理サーバ２７のプログラムの構成を示
す。図１において、２９は呼処理サーバの主記憶装置
（ＭＭ）、３３はデータベースサーバの主記憶装置（Ｍ
Ｍ）を示し、各々図２における参照番号と同じ物を指
す。

【００３８】呼処理サーバの主記憶装置２９には、複数
の呼制御タスク１０，１１，１２，１３と、サーバ間通
信タスク１４がある。これらのタスクは、呼処理サーバ
２７の制御プロセッサ２８（図２参照）と協調して動作
している。なお、図面中では呼制御タスクを４個しか記
載していないが、その個数に特に制限はない。

【００３９】データベースサーバ３１の主記憶装置３３
には、複数のデータベースサービスタスク（以下、図面
中の記載と同様に「ＤＢＳＴ」と略記する）ＤＢＳＴ−
ａ２，ＤＢＳＴ−ｂ３，ＤＢＳＴ−ｃ４，ＤＢＳＴ−ｄ
５、無名ＤＢＳＴ８、フロントエンドタスク６、及びデ
ィスクコントロールプログラム７があり、これらはデー
タベースサーバの制御プロセッサ３２（図２参照）と協
調して動作している。なお、図面中ではＤＢＳＴを４
個、無名ＤＢＳＴを１個しか記載していないが、それら
の個数に特に制限はない。

【００４０】ここに、ＤＢＳＴ−ａ２、ＤＢＳＴ−ｂ
３、ＤＢＳＴ−ｃ４、及びＤＢＳＴ−ｄ５は、−ａ、−
ｂ、−ｃ、−ｄ等のようにそれぞれ識別名を持つ。これ
に対し、無名ＤＢＳＴ８は、これに該当する識別名を持
たないため、本実施例では無名ＤＢＳＴと名付けてい
る。この無名ＤＢＳＴ８の動作は、図３を用いて後に説
明するＤＢＳＴ５６と同等である。

【００４１】次に、これらのプログラムの処理の概要を
説明する。

【００４２】呼制御タスク１０，１１，１２，１３は、
呼処理サーバ２７内で呼毎に１つ起動され呼制御を行
う。ユーザの指定するサービスに基いて呼制御を実行す
るためには、そのサービスを実現する手順に関するデー
タ、ユーザに関するデータ（例えば課金データ）、及び
接続に必要なデータ（例えば電話番号データ）等を得る
必要がある。それらのデータを管理し、呼制御タスク１
０，１１，１２，１３からの要求に応じてデータを渡し
たり、受け取ったりするデータベース機能を果たすのが
データベースサーバ３１である。

【００４３】このデータベースサービスに注目すると、
呼処理サーバ２７とデータベースサーバ３１との関係
は、クライアント・サーバ・モデルにおけるクライアン
ト（前者）とサーバ（後者）の関係に相当する。

【００４４】呼制御タスク１０，１１，１２，１３のデ
ータベースサービス要求は、データベースサーバ３１内
で動作するＤＢＳＴ２，３，４，５，８に対する問い合
わせ命令の形で発行される。ＤＢＳＴ２，３，４，５，
８は呼制御タスクからの問い合わせ命令を解釈し、必要
なデータベース操作を行い、呼制御タスクへ応答を返
す。

【００４５】データベース操作は、ディスクコントロー
ルプログラム７に対して、ディスク制御を依頼しながら
行なう。呼処理サーバ２７とデータベースサーバ３１間
の、命令と応答のやり取りを司るのは、前者側ではサー
バ間通信タスク１４、後者側ではフロントエンドタスク
６である。

【００４６】呼処理サーバ２７もデータベースサーバ３
１も、複数のタスクが並列動作するマルチタスクで動作
するため、複数の問い合わせ命令と応答が交錯する状態
になり得る。サーバ間通信タスク１４とフロントエンド
タスク６は協調して動作し、ある問い合わせ命令を発行
した呼処理タスクに対する応答を正しく選択し返すこと
を保証するようにしている。

【００４７】次に、本実施例の特徴を挙げる。

【００４８】本実施例では、呼制御タスク１０，１１，
１２，１３の各々に１対１で対応するＤＢＳＴ２，３，
４，５を起動し、ある呼制御タスクに係る一連のデータ
ベースサービスを、対応する１つのＤＢＳＴで実行する
ところに特徴がある。

【００４９】また、呼制御タスクとＤＢＳＴとを対応さ
せるために、ある呼制御タスクを他の呼制御タスクから
区別することができる識別符号１７を用いて、データベ
ースサーバに対する問い合わせ命令発行の際にその識別
符号を付加し、それによりデータベースサーバ内の対応
するＤＢＳＴを他のＤＢＳＴから区別して管理すること
に特徴がある。

【００５０】さらに、ＤＢＳＴ内に、データベースから
読みだしたデータの写しを記憶する記憶領域としてデー
タバッファ１５を用意し、読みだしたデータのデータベ
ース上でのアドレスを記憶する記憶領域としてアドレス
バッファ１６を用意することに特徴がある。加えて、デ
ータベースサーバにおいて、識別符号を付加しない問い
合わせ命令に対しても、無名ＤＢＳＴ８によってデータ
ベースサービスを行うことに特徴がある。

【００５１】以上のような本実施例の特徴によって、呼
制御タスクに対応したＤＢＳＴにより、その呼制御に必
要な一連のデータベースサービスを一括して管理、実行
できる。言い替えれば、ある呼制御タスクに対して、そ
の呼制御タスクに専用のＤＢＳＴが生成され、生成され
たＤＢＳＴは、その呼制御タスクが終了する間際まで停
止あるいは消滅することはない。

【００５２】このため、データバッファを活用したり、
呼制御タスクが実行している通信サービスの内容に従っ
てその通信サービスの実行に必要なデータを予測して先
読みしたりして、データベースサービスの応答時間を短
縮することが出来る。さらに、識別符号を付加しない従
来の問い合わせ命令に対してもデータベースサービスを
提供できるので、従来の呼処理サーバと、本実施例によ
るデータベースサービス方法を採用したデータベースサ
ーバとを混在させてＳＣＰ２５（図２参照）を構成する
こともできる。

【００５３】ここで、図３を参照して、本発明を適用し
ない従来方法による場合のデータベースサーバのプログ
ラムの構成の概要を説明し、本実施例と対比する。

【００５４】図３は、従来のＳＣＰ内のデータベースサ
ーバ及び呼処理サーバのプログラム構成を示す。２９及
び３３は、各々、呼処理サーバの主記憶装置（ＭＭ）、
及びデータベースサーバの主記憶装置（ＭＭ）を示す。

【００５５】呼処理サーバの主記憶装置２９には、複数
の呼制御タスク５８と、サーバ間通信タスク１４があ
る。これらは、呼処理サーバの制御プロセッサと協調し
て動作している。ここで、サーバ間通信タスク１４は、
図１で説明したサーバ間通信タスク１４と同様のもので
ある。なお、呼制御タスクの個数に特に制限を設けな
い。ここまでの呼処理サーバ内の構成は、図１と同様で
ある。

【００５６】データベースサーバの主記憶装置３３に
は、複数のＤＢＳＴ５６と、サーバ間通信タスク５７、
ディスクコントロールプログラム７があり、データベー
スサーバの制御プロセッサと協調して動作している。こ
こで、ディスクコントロールプログラム７は、図１のデ
ィスクコントロールプログラム７と同様のものである。
なお、ＤＢＳＴの個数に特に制限を設けない。

【００５７】図３の従来例は本発明と異なり、呼制御タ
スク５８とＤＢＳＴ５６とは必ずしも１対１に対応して
いるとは限らない。元々、データベースサーバは、呼処
理サーバからの問い合わせ命令に応じてデータベース操
作を行い、相応の応答を返す処理を行う。

【００５８】あるＤＢＳＴ５６は、いずれかの呼制御タ
スク５８からの１つの問い合わせ命令１９のみを処理し
て応答２０を返信すれば十分であり、その後、例えば消
滅してしまっても構わない。また、例えばＤＢＳＴ５６
が、ある呼制御タスク５８に対して応答２０を返信した
後、全く別の呼制御タスクからの問い合わせ命令を受け
付けて処理を開始してもよい。

【００５９】言い替えれば、呼制御タスク５８とＤＢＳ
Ｔ５６とは、１件の問い合わせ命令の処理中には対応関
係が保証されるが、処理終了後はその対応関係が保持さ
れる保証はない。後に詳述するが、先に述べた図１の実
施例における無名ＤＢＳＴ８は、このＤＢＳＴ５６と同
等の動作を行う。

【００６０】呼制御タスク５８には、図１における識別
符号１７があっても良いが、無くても良い。なぜなら、
呼制御タスク５８とＤＢＳＴ５６との間の１件の問い合
わせ命令処理中の対応関係は、サーバ間通信プログラム
１４及び５７が保持するからである。また、ＤＢＳＴ５
６に、図１におけるデータバッファ１５、及びアドレス
バッファ１６のような記憶領域があっても良いが、無く
ても良い。なぜなら、１件の問い合わせ命令を処理して
しまえば、呼処理タスク５８とＤＢＳＴ５６の対応関係
は失われてしまうのであるから、バッファ１５，１６を
有効に活用することができないからである。

【００６１】２．方法の説明

【００６２】次に、本実施例の特徴であるデータベース
サーバ内のデータベースサービスタスク及び無名データ
ベースサービスタスク、並びにそれらの動作を支援する
フロントエンドタスク及びサーバ間通信タスクの詳細を
述べる。

【００６３】（１）データベースサービスタスク（ＤＢ
ＳＴ）まず、本実施例の特徴である呼制御タスクに対応したＤ
ＢＳＴ２，３，４，５の具体的な処理方法について述べ
る。

【００６４】図４に、ＤＢＳＴの構成を示す。図４にお
いて、３３はデータベースサーバの主記憶装置（ＭＭ）
であり、図２における参照番号と同じ物を指す。２はデ
ータベースサーバの主記憶装置３３内のＤＢＳＴ−ａで
あり、図１における参照番号と同じ物である。実際に
は、図１におけるＤＢＳＴ−ｂ３，ＤＢＳＴ−ｃ４，Ｄ
ＢＳＴ−ｄ５が示すように、複数のＤＢＳＴが主記憶装
置３３内に存在することが通常だが、ここでは１つのＤ
ＢＳＴ−ａ２を例に取り説明する。

【００６５】ＤＢＳＴ−ａ２は、データベースサービス
プログラム７１と、それにより操作されるデータ構造体
７２とから成る。７１は図５を用いて、７２は図６を用
いてこの後、各々説明する。なお、図１においてＤＢＳ
Ｔ−ａ２内に図示しているデータバッファ１５、及びア
ドレスバッファ１６はデータ構造体７２内に確保され
る。

【００６６】図５のフローチャートは、データベースサ
ービスプログラム７１の処理手順を示す。

【００６７】まず、後述するフロントエンドタスク６
（図１参照）によりＤＢＳＴ−ａ２が起動され、データ
ベースサービスプログラム７１が処理を開始する（ステ
ップ８１）。ステップ８２では、フロントエンドタスク
６からの問い合わせメッセージを受け取るため待機す
る。問い合わせメッセージの書式を、図２１に示す。図
２１から分かるように、問い合わせメッセージは、呼処
理タスクからの問い合わせ命令４０２（図１の参照番号
１９）を含む。

【００６８】フロントエンドタスク６から問い合わせメ
ッセージを受け取ったら、ステップ８３に進み、問い合
わせ命令を解釈する。ステップ８４では、問い合わせの
対象となるデータレコードが、データ構造体７２内にバ
ッファされているかどうかを判断し、その結果により処
理フローを分岐する。

【００６９】バッファされていない場合（ｎｏ）は、ス
テップ１０５に進む。ステップ１０５では、対象レコー
ドのディスクＤＫ３４（図２参照）上でのアドレスがデ
ータ構造体７２のバッファ内にあるかどうかを判断し、
あれば（ｙｅｓ）ステップ１０６へ、無ければ（ｎｏ）
ステップ８５へ進む。

【００７０】ステップ１０６では、問い合わせ命令が更
新トランザクションを含むか否かを判断し、含む（ｙｅ
ｓ）ならステップ９６へ、含まない（ｎｏ）ならステッ
プ１０７へ、処理フローを分岐する。

【００７１】ステップ１０７では、データ構造体７２内
のアドレスバッファから、問い合わせ対象のデータレコ
ードのディスクＤＫ３４上でのアドレスを読み出す。次
に、ステップ１０８では、ステップ１０７で得た問い合
わせ対象のデータレコードのアドレスを指定してデータ
ベースを検索あるいは参照するように、ディスクコント
ロールプログラム７にアクセス命令を発行する。次に、
ステップ９８へ進む。

【００７２】ステップ９８で、ディスクコントロールプ
ログラム７からの応答を待つ。ディスクコントロールプ
ログラム７からの応答（すなわち、データベースの検索
参照結果）があったら、ステップ９９で、呼処理サーバ
に対して応答を返す。その内容は、例えばステップ１０
８で得たデータレコード等である。ステップ１００で
は、ステップ１０８でアクセスしたデータレコードを、
データ構造体７２内のデータバッファに必要に応じてコ
ピーする。

【００７３】次に、ステップ９３では、呼制御タスクで
行っている通信サービスの内容に従って、データの先読
み処理を行う。この処理は本実施例の特徴のひとつであ
り、図１２を用いて後に詳しく説明する。

【００７４】次に、ステップ９４では、処理している問
い合わせ命令が呼制御のいちばん最後の問い合わせであ
るかどうかを判断し、終了するならばステップ１０３で
終了処理を行ない、そうでなければステップ８２へ戻
り、プログラム全体を繰り返す。

【００７５】ステップ１０６で条件が成立した場合（ｙ
ｅｓ）、すなわち問い合わせ命令が更新トランザクショ
ンを含む場合は、ステップ９６へ進む。ステップ９６で
は、データ構造体７２内のアドレスバッファから、問い
合わせ対象のデータレコードのディスクＤＫ３４上での
アドレスを読み出す。次に、ステップ９７では、ステッ
プ９６で得た問い合わせ対象のデータレコードのアドレ
スを指定してデータベースを更新するように、ディスク
コントロールプログラム７にアクセス命令を発行する。

【００７６】そして、ステップ９８で、ディスクコント
ロールプログラム７からの応答を待つ。応答があった
ら、ステップ９９で、呼処理サーバに対して応答を返
す。その内容は、例えば更新トランザクションの完了を
示すデータである。ステップ１００では、ステップ９７
でアクセスしたデータレコードを、データ構造体７２内
のデータバッファに、必要に応じて、コピーする。次
に、通信サービスの内容に従ってデータの先読み処理を
行なうステップ９３に進む。以降の処理は既に説明し
た。

【００７７】ステップ１０５で条件が成立しなかった場
合（ｎｏ）、すなわち対象レコードのディスクＤＫ３４
上でのアドレスがバッファ内にない場合は、ステップ８
５へ進む。ステップ８５では、問い合わせ命令に従いデ
ィスクＤＫ３４内に格納されているデータベースを検索
アクセスするように、ディスクコントロールプログラム
７（図１参照）にアクセス命令を発行する。そして、ス
テップ８６で、ディスクコントロールプログラム７から
の応答を待つ。

【００７８】次に、ステップ８７では、問い合わせ命令
が更新トランザクションを含むか否かを判断し、含む
（ｙｅｓ）ならステップ８８へ、含まない（ｎｏ）なら
ステップ９０へ、処理フローを分岐する。

【００７９】更新トランザクションを含む問い合わせ命
令である場合は、ステップ８８で、ディスクコントロー
ルプログラム７に対して、データベースに更新アクセス
するようにアクセス命令を発行する。そして、ステップ
８９で、ディスクコントロールプログラム７からの応答
を待つ。

【００８０】次に、ステップ９０では、呼処理サーバに
対して応答を返す。その内容は、例えば、データベース
へのアクセスが参照トランザクションであった場合に
は、検索したデータレコードであるし、更新トランザク
ションであった場合には、その完了を示すデータであ
る。

【００８１】ステップ９１では、ステップ８５及びステ
ップ８８でアクセスしたデータレコードを、データ構造
体７２内のデータバッファに必要に応じてコピーする。
ステップ９２ではステップ９１と同様に、アクセスした
データレコードへのアドレスを、データ構造体７２内の
アドレスバッファに必要に応じてコピーする。ここで、
アクセスしたデータレコードへのアドレスとは、ディス
クＤＫ３４上でのデータレコードのアドレスである。

【００８２】ステップ９３では、通信サービスの内容に
従って、データの先読み処理を行なう。ステップ９４で
は、処理している問い合わせ命令が呼制御の一番最後の
問い合わせであるかどうかを判断する。呼制御の一番最
後の問い合わせであるかどうかは、問い合わせの内容に
よって判断できる。例えば、呼の終了時には、後述する
端末リソーステーブル（図１０参照）内のリソースレコ
ードのリソース使用数を１減算する問い合わせが実行さ
れるが、これをもって呼制御の一番最後の問い合わせと
認識すればよい。

【００８３】ステップ９４の判断結果によって、終了す
る場合（ｙｅｓ）にはステップ１０３へ、そうでない場
合（ｎｏ）にはステップ８２へ、それぞれ分岐する。ス
テップ１０３では、タスク終了メッセージをフロントエ
ンドタスクへ発行する。すると、ステップ１０４で、プ
ログラムが終了する。ステップ９４からステップ８２へ
分岐した場合には、プログラム全体が繰り返される。

【００８４】ステップ８４において、問い合わせの対象
となるデータレコードが、データ構造体７２内にバッフ
ァされている場合（ｙｅｓ）は、ステップ９５へ分岐す
る。ステップ９５では、問い合わせ命令が更新トランザ
クションを含むか否かを判断し、含む（ｙｅｓ）ならス
テップ９６へ、含まない（ｎｏ）ならステップ１０１
へ、処理フローを分岐する。

【００８５】問い合わせ命令が更新トランザクションを
含む場合は、ステップ９６で、データ構造体７２内のア
ドレスバッファから、問い合わせ対象のデータレコード
のディスクＤＫ３４上でのアドレスを読み出す。次に、
ステップ９７では、ステップ９６で得た問い合わせ対象
のデータレコードのアドレスを指定してデータベースを
更新するように、ディスクコントロールプログラム７に
アクセス命令を発行する。

【００８６】そして、ステップ９８で、ディスクコント
ロールプログラム７からの応答を待つ。ステップ９９で
は、呼処理サーバに対して応答を返す。その内容は、例
えば更新トランザクションの完了を示すデータである。
ステップ１００では、ステップ９７でアクセスしたデー
タレコードを、データ構造体７２内のデータバッファに
必要に応じてコピーする。ステップ９３では、通信サー
ビスの内容に従って、データの先読み処理を行なう。

【００８７】次に、ステップ９４では、処理している問
い合わせ命令が呼制御のいちばん最後の問い合わせであ
るかどうかを判断し、終了するならステップ１０３で終
了処理を行ない、そうでなければステップ８２へ戻り、
プログラム全体を繰り返す。

【００８８】ステップ９５において、問い合わせ命令が
更新トランザクションを含まない場合（ｎｏ）は、ステ
ップ１０１で、データ構造体７２内のデータバッファか
ら問い合わせ対象のデータレコードの内容を読み出す。
次に、ステップ１０２で、呼処理サーバに対して応答を
返す。その内容は、例えばステップ１０１で得たデータ
レコードである。

【００８９】ステップ９４では、処理している問い合わ
せ命令が呼制御のいちばん最後の問い合わせであるかど
うかを判断し、終了するならステップ１０３で終了処理
を行ない、そうでなければステップ８２へ戻り、プログ
ラム全体を繰り返す。

【００９０】次に、図６を参照して、データ構造体７２
について説明する。データ構造体７２は、呼識別符号領
域１１１、サービス番号領域１１２、先読み処理用テー
ブル１１３、及びバッファテーブル１１９から成る。

【００９１】呼識別符号領域１１１には、呼処理サーバ
２７（図２参照）内の呼制御タスク１０（図１参照）の
呼識別符号１７と同じ呼識別符号を格納する。サービス
番号領域１１２には、呼制御タスク１０が実行している
通信サービスの種類を表すサービス番号を格納する。

【００９２】呼制御タスク１０は、端末ユーザが要求す
る通信サービスの種類を判別し次第、データベースサー
バ３１からそのサービスを実現する手順に関するデータ
を得る必要がある。このため、サービス番号をキーとし
てサービス手順のデータベースを検索参照する問い合わ
せ命令を発行する。

【００９３】この問い合わせをきっかけとして、ＤＢＳ
Ｔ−ａ２がフロントエンドタスク６により生成される。
この際、呼処理サーバ２７からデータベースサーバ３１
へ発行される問い合わせメッセージ３９１（図２０参
照）に付加されてくる呼識別符号を呼識別符号領域１１
１に格納し、またサービス番号を抽出しサービス番号領
域１１２に格納する。

【００９４】先読み処理用テーブル１１３は、ＤＢＳＴ
−ａ２がデータの先読み処理を行なう場合に必要となる
（図５のステップ９３参照）。先読み処理において、先
読み処理用テーブル１１３がどのように用いられるか
は、図１２を用いて後述する。図６には、先読み処理用
テーブルの一例を示す。

【００９５】先読み処理用テーブル１１３には、先読み
を行なう基準となる条件の数、すでに満たした条件の
数、実行する先読み処理プログラムを指すプログラムポ
インタ、及び先読みしたかどうかのチェック等が格納さ
れる。その内容は、通信サービス毎に異なる。ＤＢＳＴ
−ａ２が、フロントエンドタスク６により生成される
際、該当する通信サービスの先読み処理用テーブルがコ
ピーされる。

【００９６】図７を参照して、先読み処理用テーブル１
１３の内容を詳しく説明する。このテーブル１１３を構
成する項目は、イベント番号１１４、条件数１１５、カ
ウント１１６、プログラムへのポインタ１１７、及び処
理済みチェック１１８である。

【００９７】データの行（１３１、１３２等）は、実行
可能な先読み処理の数だけ用意される。最後のデータの
行１３３には、テーブルの最後を示す特別な値、ここで
はｎｕｌｌを入れておく。イベント番号１１４は、先読
み処理を区別する番号である。条件数１１５は、先読み
を行なう基準となる条件の数である。カウント１１６
は、すでに満たした条件の数である。プログラムへのポ
インタ１１７は、実行する先読み処理プログラムを指す
プログラムポインタである。処理済みチェック１１８
は、その先読み処理がすでに行われたかどうかを示す値
である。

【００９８】再び図６を参照して、バッファテーブル１
１９について説明する。バッファテーブル１１９は、図
１におけるデータバッファ１５とアドレスバッファ１６
の集合したものである。バッファテーブル１１９には、
データベースへのアクセスを行った場合、得られたデー
タレコードや、そのディスク上でのアドレス等をコピー
して保持しておく。

【００９９】図５のステップ９１，９２，１００でバッ
ファテーブルを更新する処理が行われ、ステップ９６，
１０１では、バッファテーブルを参照する処理が行われ
る。これにより、バッファ済みのデータレコードであれ
ば、実際にディスク上のデータベースにアクセスする場
合よりも高速に処理を終えることが出来る。図６には、
バッファテーブルの一例を示す。

【０１００】バッファテーブル１１９には、バッファし
ているデータの種類、バッファしたかどうかのチェッ
ク、先読み処理を実行するのに必要なデータかどうかを
示す情報、及びバッファ領域などが格納される。その内
容は通信サービス毎に異なる。ＤＢＳＴ−ａ２が、フロ
ントエンドタスク６により生成される際、該当する通信
サービスのバッファテーブルがコピーされる。

【０１０１】図８を参照して、バッファテーブル１１９
の内容を詳しく説明する。図８では、説明し易いように
バッファの数は１行にしてある。テーブル１１９を構成
する項目は、バッファ番号１２０、種類１２１、バッフ
ァ済みチェック１２２、先読み参照数１２３、先読みイ
ベント番号１２４，１４０、バッファ領域１２５、及び
終端マーク１２６である。

【０１０２】バッファ番号１２０は、バッファ領域を区
別する番号である。種類１２１は、バッファ領域１２５
に格納するデータが、データベースのデータレコードそ
のものであるか、あるいはディスク上でのアドレスであ
るかを区別する値である。例えば、前者なら「Ｄ」、後
者なら「Ａ」と言う値である。バッファ済みチェック１
２２は、すでにバッファしたかどうかを示す値である。
先読み参照数１２３は、関係する先読みが何件あるかを
示す値である。これに示す値の数だけ、次に述べる先読
みイベント番号１２４，１４０が並ぶことになる。

【０１０３】先読みイベント番号１２４，１４０は、図
７におけるイベント番号１１４のいずれかを指す。バッ
ファ領域１２５には、バッファすべきデータレコードや
アドレスが格納される。終端マーク１２６には、バッフ
ァ領域１２５の終わりを示す特別な値、例えばｎｕｌｌ
が格納される。

【０１０４】図５のステップ９１，９２，１００でバッ
ファテーブル１１９を更新する際に行われる処理の概要
を説明する。

【０１０５】まず、バッファ領域１２５にデータレコー
ドが格納される。次に、先読み参照数１２３が例えば
「１」で、先読みイベント番号１２４が例えば「１」で
あれば、格納と同時に、先読み処理用テーブル１１３
（図７参照）のイベント番号１１４＝１（先読みイベン
ト番号１２４の内容）に相当する行１３１のカウント１
１６をインクリメント（１加算）する。また、バッファ
済みチェック１２２の値を、例えば「未」から「済」等
にして、バッファが完了したことを示すようにする。

【０１０６】以上、図４から図８を用いて、ＤＢＳＴ−
ａ２の概要を説明したが、次に具体的な例を用いて、デ
ータベースのデータをバッファしたり、先読みする処理
の様子を説明する。

【０１０７】以下、図９から図１１により例として用い
るデータベース内のテーブルを、図１２から図１４によ
り先読み処理の手順を説明する。具体的な通信サービス
を例にとり、その処理の流れに沿って説明する。ここで
は、公衆網を用いた内線接続サービスを考えるものとす
る。内線接続サービスとは、ある企業例えばＡ社の第１
支店の（公衆網に直結した）電話（端末）からＡ社で規
定した内線番号をかけるだけで、遠隔地にある第２支店
の電話（端末）につなぐことを可能にするサービスであ
る。

【０１０８】まず、図９及び図１０を参照して、ＳＣＰ
２５（図２参照）で端末２４を管理するための基本的な
データベースである端末リソースレコードについて説明
する。端末リソースレコードは、１台の端末に付き１件
づつ登録されるレコードであり、端末に関する各種の情
報が格納されている。

【０１０９】図９に、端末リソースレコードの書式を示
す。物理番号１５１は、端末の電話番号のことである。
物理番号１５１によって１台の端末を特定できる。使用
可否１５２は、この端末が使用可能かどうかを示す。す
なわち、現在、この端末に対して電話接続をしてもいい
かどうかを示す。リソース使用数１５３は、端末の現在
の使用状況を示す。端末が使用されていないときは、例
えば「０」で、使用中は例えば「１」である。

【０１１０】属性１５４は、端末の属性を示す。本実施
例では、個人契約か団体契約か、団体契約なら団体名を
示すこととする。許可されたサービス数１５５は、端末
から利用することの出来る通信サービスが何種類登録さ
れているかを示す。具体的には、次に述べる許可された
サービス番号１５６，１５７の数を示す。許可されたサ
ービス番号１５６，１５７は、端末から利用できる通信
サービスを、その番号で示す。課金記録１５８は、端末
に課せられた電話料金を示す。

【０１１１】図１０に、端末リソースレコードをテーブ
ルにした端末リソーステーブル１７１の例を示す。以下
の説明で用いる、発呼側端末のリソースレコード１７９
と、着呼側端末のリソースレコード１８０とを、例示し
てある。

【０１１２】発呼側端末のリソースレコード１７９に
は、物理番号１５１の値として端末の電話番号（１２−
３４５６）、使用可否１５２の値として使用可能を示す
値（可）、リソース使用数１５３の値として現在は使用
中でないことを示す値（０）、属性１５４としてＡ社の
団体契約であることを示す値（Ａ社）、許可されたサー
ビス数１５５として設定された値（１）、許可されたサ
ービス番号１５６としてここで説明する内線接続サービ
スを表す値（１）、及び課金記録１５８として現在まで
の課金値（￥１０００）が、それぞれ設定されている。

【０１１３】着呼側端末のリソースレコード１８０に
は、物理番号１５１の値として端末の電話番号（１２−
７８９０）、使用可否１５２の値として使用可能を示す
値（可）、リソース使用数１５３の値として現在は使用
中でないことを示す値（０）、属性１５４としてＡ社の
団体契約であることを示す値（Ａ社）、許可されたサー
ビス数１５５として設定された値（１）、許可されたサ
ービス番号１５６としてここで説明する内線接続サービ
スを表す値（１）、及び課金記録１５８として現在まで
の課金値（￥２０００）が、それぞれ設定されている。

【０１１４】ここで説明しようとしている公衆網を用い
た内線接続サービスでは、内線番号を物理番号に変換す
るためのデータベースが必要である。図１１に、例とし
て用いる番号変換テーブル１９１を示す。

【０１１５】番号変換テーブル１９１は、内線番号１９
２と物理番号１９３との２つの項目からなる。図１１で
は、発呼側番号変換レコード１９４と、着呼側番号変換
レコード１９５とを例示してある。ある内線番号をキー
としてこの番号変換テーブル１９１を検索すれば、着呼
側（通話相手）の物理番号を得ることができる。

【０１１６】次に、図１２から図１４のフローチャート
を参照して、データベースのデータをバッファしたり、
先読みする処理の様子を説明する。事例として、Ａ社の
第１支店の電話端末（物理番号＝１２−３４５６）か
ら、第２支店の電話端末（物理番号＝１２−７８９０）
へ、上述の内線接続サービスによりＡ社規定の内線番号
で電話接続することを考える。

【０１１７】まず、発呼側電話端末（物理番号＝１２−
３４５６）からのダイヤル発信により、呼処理サーバ２
７（図２参照）内で呼制御タスク１０（図１）が起動さ
れる。呼制御タスク１０は、これから実行すべき通信サ
ービス手順等に関する情報を得るため、データベースサ
ーバ３１に対して問い合わせ命令を発行する。これによ
り、データベースサーバ３１内でＤＢＳＴ−ａ２（図
１）が起動され、ＤＢＳＴ−ａ２は通信サービス手順等
の情報を呼制御タスク１０へ返す。

【０１１８】ＤＢＳＴ−ａ２は、図５に示すデータベー
スサービスプログラムの処理を開始し、発呼側端末のリ
ソースレコード１７９を参照する問い合わせ命令を呼制
御タスク１０から受け取り、命令解釈する（ステップ８
２，８３）。始めは、問い合わせの対象となるデータレ
コードはバッファされておらず、対象レコードのアドレ
スもバッファされていないから、ステップ８４，１０５
を介して、ステップ８５に進み、受け取った問い合わせ
命令をデータベース上の端末リソーステーブル１７１
（図１０）から、物理番号をキーとして検索する（ステ
ップ８５）。

【０１１９】得られた発呼側端末のリソースレコード１
７９は、ステップ９０で、呼処理サーバに応答される。
また、このリソースレコード１７９は、図６のデータ構
造体７２内のバッファテーブル１１９のバッファ１３４
のバッファ領域１２５にコピーされる。同時に、バッフ
ァ済みチェック１２２に、バッファしたことを示す値、
例えば「済」を設定する。バッファ１３４では、先読み
参照数１２３が「１」なので、先読みイベント番号１２
４（＝１）を参照し、先読み処理用テーブル１１３（図
７）のイベント番号１１４が「１」と等しい行１３１の
カウント１１６をインクリメントする（以上、ステップ
９１）。

【０１２０】また、発呼側端末のリソースレコード１７
９のディスク３４上でのアドレスは、同じくバッファ１
３５のバッファ領域１２５にコピーし、バッファ済みチ
ェック１２２に「済」を設定する（ステップ９２）。

【０１２１】次に、ステップ９３で先読み処理を行う。
先読み処理については、図１２を参照して説明する。

【０１２２】先読み処理２０１は、ステップ２０２で開
始され、図６のデータ構造体７２の先読み処理用テーブ
ル１１３を１行づつ処理し、ステップ２０６で終了す
る。ステップ２０３では、先読み処理用テーブル１１３
を最後まで処理したかどうかを判断する。イベント番号
１１４の項の値がｎｕｌｌなら、ステップ２０６へ分岐
し終了する。そうでなければ、ステップ２０４に分岐す
る。

【０１２３】ステップ２０４では、カウント１１６の値
が条件数１１５の値より大きいか等しく、かつ、処理済
みチェック１１８の値が「未」であれば、ステップ２０
５へ分岐する。そうでなければステップ２０３へ分岐
し、先読み処理用テーブル１１３の次の行の処理を始め
る。ステップ２０５では、プログラムへのポインタ１１
７が指すプログラムを実行する。ここでは、プログラム
ａが指定されている。

【０１２４】図１３により、プログラムａの処理を説明
する。ステップ２１２で、処理が始まる。ステップ２１
３では、バッファテーブル１１９（図６参照）のバッフ
ァ１３４のバッファ領域１２５から、既にコピーされて
いる発呼側リソースレコードの属性フィールドを参照し
（図１０の発呼側端末のリソースレコード１７９参
照）、Ａ社の内線接続を行えばよいことを知る。

【０１２５】ステップ２１４では、Ａ社の内線番号変換
のためにディスク上の番号変換テーブル１９１へのアド
レスを得るため、検索処理を行なう。ステップ２１５で
は、ステップ２１４で得た番号変換テーブル１９１への
アドレスを、バッファテーブル１１９のバッファ１３６
のバッファ領域１２５にコピーする。

【０１２６】ステップ２１６でプログラムａは終了する
から、図１２の先読み処理２０１のステップ２０５が完
了する。

【０１２７】再び図１２を参照して、ステップ２０５の
後、ステップ２０３へ分岐し、先読み処理用テーブル１
１３の次の行の処理を始める。先読み処理用テーブル１
１３の次の行１３２は、未だステップ２０４の条件を満
たしておらず、またその次の行１３３は最後の行なの
で、この先読み処理は、ステップ２０６へ分岐し終了す
る。よって、図５のステップ９３も終了し、次の処理へ
進んでいく。

【０１２８】そのあと呼制御が進むと、ダイヤルされた
内線番号（例えば、１２３４）を着呼側端末（通話相
手）の物理番号に変換するための問い合わせ命令が、呼
制御タスク１０から発行される。これを受けて、データ
ベースサービスプログラム７１のステップ８３からの処
理が再び始まる。

【０１２９】番号変換のためには番号変換テーブル１９
１（図１１参照）を検索、参照するが、同テーブル１９
１へのディスク上のアドレスは、データ構造体７２のバ
ッファテーブル１１９のバッファ１３６のバッファ領域
１２５に、予めコピーしてある。

【０１３０】このため、ステップ８４、ステップ１０
５、ステップ１０６を経て、処理はステップ１０７に分
岐する。そして、予めコピーしてあるアドレスを指定し
て、ステップ１０８でデータベースを参照アクセスす
る。ここでは、ダイヤルされた内線番号をキーとして番
号変換テーブル１９１を検索し、内線番号１２３４に対
応する物理番号１２−７８９０を得る。

【０１３１】この結果を呼制御タスクに応答する（ステ
ップ９９）。また、この結果を、データ構造体７２のバ
ッファテーブル１１９のバッファ１３７のバッファ領域
１２５にコピーする。同時に、バッファ済みチェック１
２２に「済」を設定する。また、バッファ１３７では、
先読み参照数１２３が「１」なので、先読みイベント番
号１２４（＝２）を参照し、先読み処理用テーブル１１
３のイベント番号１１４が「２」と等しい行１３１のカ
ウント１１６をインクリメントする（以上、ステップ１
００）。

【０１３２】次に、ステップ９３で先読み処理を行う。
先読み処理について、図１２を用いて説明する。

【０１３３】先読み処理用テーブル１１３のイベント番
号１１４＝１の行１３１は、ステップ２０３及びステッ
プ２０４の条件が成立しない。そこで、次の行１３２が
処理にかかる。ステップ２０３を経て、ステップ２０４
の条件が成立するので、ステップ２０５へ分岐する。

【０１３４】ステップ２０５では、行１３２のプログラ
ムへのポインタ１１７が指すプログラムを実行する。こ
こでは、プログラムｂが指定されている。

【０１３５】図１４により、プログラムｂ２２１の処理
を説明する。プログラムｂの処理の概要は、着呼側端末
（通話相手）の物理番号をキーにして着呼側端末のリソ
ースレコードを得ることである。

【０１３６】ステップ２２２で処理が始まる。まず、ス
テップ２２３では、着呼側端末が自ＳＣＰ２５で管理し
ているものかどうかを判断する。ここでは、発呼側端末
も着呼側端末も、同一のＳＣＰ２５で管理しているもの
とする。ステップ２２４では、バッファテーブル１１９
のバッファ１３７のバッファ領域１２５から着呼側端末
物理番号を得て、これをキーとしてディスク上の端末リ
ソーステーブル１７１（図１０参照）を検索し、着呼側
端末のリソースレコード１８０を得る。

【０１３７】ステップ２２５では、着呼側端末のリソー
スレコード１８０をバッファテーブル１１９のバッファ
１３８のバッファ領域１２５にコピーする。ステップ２
２６では、ディスク上の着呼側端末のリソースレコード
１８０へのアドレスを、バッファテーブル１１９のバッ
ファ１３９のバッファ領域１２５に、コピーする。

【０１３８】ステップ２２７でプログラムｂは終了する
から、図１２の先読み処理２０１のステップ２０５が完
了する。

【０１３９】再び図１２を参照して、先読み処理用テー
ブル１１３の次の行１３３は最後の行であるから、この
先読み処理２０１は、ステップ２０６へ分岐し終了す
る。よって、図５のステップ９３も終了し、次の処理へ
進んでいく。

【０１４０】このあと呼制御が進むと、発呼側端末ある
いは着呼側端末のリソースレコードを参照または更新す
る問い合わせ命令が、呼制御タスク１０からＤＢＳＴ−
ａ２へ発行されるが、これらは既にデータ構造体７２の
バッファテーブル１１９内にコピーされている。したが
って、ディスク上のデータベースへアクセスする場合よ
りも高速に応答を返すことが出来る。なかでも、番号変
換テーブルへのアドレス、及び着呼側端末のリソースレ
コードについては、呼制御タスク１０から問い合わせ命
令が発行される前に、既に先読みされてバッファにコピ
ーされている点が特徴である。なお、プログラムａ、プ
ログラムｂ等の実際に先読み処理を行なうプログラム
は、各通信サービスに固有な専用処理プログラムであ
る。

【０１４１】（２）無名データベースサービスタスク次に、無名ＤＢＳＴ８（図１参照）について説明する。

【０１４２】無名ＤＢＳＴ８は、ＤＢＳＴ−ａ２と異な
りデータ構造体７２を持たない。すなわち、無名ＤＢＳ
Ｔ８は、無名データベースサービスプログラム２４１
（図１５）から成る。無名ＤＢＳＴ８は、呼識別符号１
７を付加しない問い合わせ命令を受け付けて処理し、応
答を返す。従来技術の欄で説明したように、図３におけ
るＤＢＳＴ５６も同様の動作を行なう。

【０１４３】その処理の概要は、呼処理サーバ２７から
フロントエンドタスク６を通して１件の問い合わせ命令
を受け取り、データベース処理を行ない、その結果を応
答として呼処理サーバ２７へ返すというものである。

【０１４４】無名ＤＢＳＴ８がＤＢＳＴ−ａ２と異なる
点は、以下の点である。まず、無名ＤＢＳＴ８は、問い
合わせ命令を発行する例えば呼制御タスク等とは、１件
の問い合わせ命令の処理中には対応関係があるものの、
その処理の終了後も対応関係が保持される保証はない。
また、無名ＤＢＳＴ８はデータ構造体７２を持たないた
め、無名ＤＢＳＴ８内にはバッファ領域がなく、先読み
処理などもしない。

【０１４５】図１５のフローチャートを参照して、無名
データベースサービスプログラム２４１の処理手順を説
明する。

【０１４６】無名ＤＢＳＴ８は、フロントエンドタスク
６により生成され、ステップ２４２から処理が始まる。
まず、ステップ２４３では、フロントエンドタスク６を
通して受け取った問い合わせ命令（図２１参照）を解釈
する。ステップ２４４では、受け取った問い合わせ命令
に従い、ディスクＤＫ３４（図２参照）内に格納されて
いるデータベースを検索アクセスするように、ディスク
コントロールプログラム７（図１参照）にアクセス命令
を発行する。そして、ステップ２４５で、ディスクコン
トロールプログラム７からの応答を待つ。

【０１４７】次に、ステップ２４６では、問い合わせ命
令が更新トランザクションを含むか否かを判断し、含む
（ｙｅｓ）ならステップ２４７へ、含まない（ｎｏ）な
らステップ２４９へ、処理フローを分岐する。ステップ
２４７では、データベースに更新アクセスするように、
ディスクコントロールプログラム７に対してアクセス命
令を発行する。ステップ２４８では、ディスクコントロ
ールプログラム７からの応答を待つ。

【０１４８】ステップ２４９で、データベース操作の結
果を呼処理サーバ側に返す。そして、ステップ２５０で
フロントエンドタスクに対して処理終了を報告し、ステ
ップ２５１で終了する。

【０１４９】（３）フロントエンドタスクフロントエンドタスク６（図１参照）は、データベース
サーバ３１内にあり、呼処理サーバ２７内のサーバ間通
信タスク１４と協調して、命令と応答のやりとりを制御
する。呼処理サーバ２７もデータベースサーバ３１も、
複数のタスクが並列動作するマルチタスクで動作するた
め、複数の問い合わせ命令と応答が交錯する状態になり
得る。フロントエンドタスク６は、ある問い合わせ命令
に対する応答を正しく選択し返すことを保証する。

【０１５０】また、フロントエンドタスク６は、ＤＢＳ
Ｔの生成や消去を含む管理を行なう。つまり、新しく生
成された呼制御タスク１０，１１，１２，１３からの呼
識別符号付きの問い合わせメッセージ３９１（図２０参
照）を受け取った場合は、新しくＤＢＳＴ−ａ２，ＤＢ
ＳＴ−ｂ３，ＤＢＳＴ−ｃ４，ＤＢＳＴ−ｄ５に記憶領
域を割り当てて生成する。

【０１５１】そして、呼制御タスク１０，１１，１２，
１３からの呼識別符号付きの問い合わせメッセージ３９
１を受け取り、対応するＤＢＳＴ−ａ２，ＤＢＳＴ−ｂ
３，ＤＢＳＴ−ｃ４，ＤＢＳＴ−ｄ５へ分配する。ＤＢ
ＳＴ−ａ２，ＤＢＳＴ−ｂ３，ＤＢＳＴ−ｃ４，ＤＢＳ
Ｔ−ｄ５が終了するまでの間、フロントエンドタスク６
は、これらの管理を行なう。また、ＤＢＳＴ−ａ２，Ｄ
ＢＳＴ−ｂ３，ＤＢＳＴ−ｃ４，ＤＢＳＴ−ｄ５が終了
したら、割り当てた記憶領域を解放するなどの処理を行
なう。

【０１５２】さらに、呼識別符号の付加されない問い合
わせメッセージ４０１（図２１参照）を受けた場合、フ
ロントエンドタスク６は、無名ＤＢＳＴ８に記憶領域を
割り当てて生成する。また、無名ＤＢＳＴ８の処理が終
了したら、記憶領域を解放する。

【０１５３】図１６に、以上のような処理を行なうフロ
ントエンドタスク６の構成を示す。図１６において、３
３はデータベースサーバの主記憶装置（ＭＭ）であり、
図２における参照番号と同じものを指す。６はフロント
エンドタスクであり、図１における参照番号と同じもの
を指す。

【０１５４】フロントエンドタスク６は、命令受付プロ
グラム３０１、応答返信プログラム３０２、ＤＢＳＴ管
理プログラム３０３、ポート番号管理テーブル３０４、
及びＤＢＳＴ番号管理テーブル３０５から成る。

【０１５５】ポート番号管理テーブル３０４は図１７を
用いて、ＤＢＳＴ番号管理テーブル３０５は図１８を用
いて説明する。命令受付プログラム３０１は、図１９を
用いて説明するが、呼処理サーバ２７からの問い合わせ
メッセージを受け取り、対応するＤＢＳＴに配信する処
理等を行なう。応答返信プログラム３０２は、図２２を
用いて説明するが、ＤＢＳＴからの応答を受け取り、呼
処理サーバへ返信する処理等を行なう。ＤＢＳＴ管理プ
ログラム３０３は、図２５を用いて説明するが、ＤＢＳ
Ｔの生成と消去に係わる処理を行なう。

【０１５６】まず、図１７を参照して、ポート番号管理
テーブル３０４の構成を説明する。ポート番号管理テー
ブル３０４は、主に、命令受付プログラム３０１、及び
応答返信プログラム３０２により操作、参照される。ポ
ート番号管理テーブル３０４は、ポート番号３２１、呼
識別符号３２２、及びＤＢＳＴ番号３２３の項目からな
るテーブルである。

【０１５７】ポート番号３２１とは、ここではサーバ間
通信の際に、要求とその応答とを１対１に対応付けする
ために用いる番号である。

【０１５８】呼識別符号３２２とは、呼識別符号１７
（図１参照）と同じ番号で、問い合わせメッセージ３９
１（図２０参照）の呼識別符号３９２として、データベ
ースサーバに渡される。問い合わせメッセージ３９１の
呼識別符号３９２とポート管理テーブル３０４の呼識別
符号３２２とを照合して、呼に対応したＤＢＳＴを検索
する。

【０１５９】ＤＢＳＴ番号３２３とは、データベースサ
ーバ内のＤＢＳＴに対して１対１に割り振られたタスク
の番号である。

【０１６０】例えば、行３２５によれば、呼識別符号３
２２が「ａ」である呼制御（呼制御タスク１０）に対応
するＤＢＳＴ（ＤＢＳＴ−ａ２）のＤＢＳＴ番号３２３
は「１」であり、タスク間通信のためにポート番号３２
１として「２」を使用していることが分かる。また、行
３２４によれば、ＤＢＳＴ番号３２３は「空」という値
であり、これにより、ポート番号３２１が「１」のポー
トは現在使用されていないことが分かる。また、行３２
８によれば、呼識別符号３２２の値が「ｎｏｎａｍｅ」
であり、これにより、ＤＢＳＴ番号３２３が「６」のタ
スクとして無名ＤＢＳＴ８が起動しており、ポート番号
３２１として「５」を使用していることが分かる。

【０１６１】次に、図１８を参照して、ＤＢＳＴ番号管
理テーブル３０５の構成を説明する。ＤＢＳＴ番号管理
テーブル３０５は、主に、ＤＢＳＴ管理プログラム３０
３により操作、参照される。ＤＢＳＴ番号管理テーブル
３０５は、ＤＢＳＴ番号３４１、タスクへのポインタ３
４２の項目からなるテーブルである。

【０１６２】ＤＢＳＴ番号３４１は、図１７のＤＢＳＴ
番号３２３と同じ値をとり、それぞれ１対１に対応して
いる。タスクへのポインタ３４３は、ＤＢＳＴへのポイ
ンタである。

【０１６３】例えば、行３４３によれば、ＤＢＳＴ番号
が１のタスクは、タスクへのポインタ３４２の値「ｐｏ
ｉｎｔｅｒｔｏａ」の指すタスクであることが分か
る。また、行３４４によれば、ＤＢＳＴ番号が２のタス
クは、タスクへのポインタ３４２の値「ｐｏｉｎｔｅｒ
ｔｏｎｏｎａｍｅ（１）」の指すタスクであること
が分かる。

【０１６４】次に、図１９のフローチャートを参照し
て、フロントエンドタスク６の命令受付プログラム３０
１の処理手順を説明する。

【０１６５】このプログラム３０１は、データベースサ
ーバが起動した直後から処理を開始（ステップ３６１）
している。まず、ステップ３６２では、呼処理サーバか
らの問い合わせメッセージの受け取りを待機している。

【０１６６】問い合わせメッセージは、図２０の書式３
９１あるいは図２１の書式４０１の書式を持つ。図２０
の書式３９１の問い合わせメッセージは、呼識別符号３
９２、及び問い合わせ命令３９３を含む。図２１の書式
４０１の問い合わせメッセージ４０１は、問い合わせ命
令４０２のみからなる。

【０１６７】ステップ３６３では、問い合わせメッセー
ジに呼識別符号が付いているか否かを判断する。これに
より、受け取った問い合わせメッセージの書式が、書式
３９１か書式４０１かを判断している。そして、書式３
９１のスタイルであればステップ３６４へ、書式４０１
のスタイルであればステップ３７４へ、処理フローを分
岐する。

【０１６８】問い合わせメッセージが図２０の書式３９
１のスタイルなら、ステップ３６４で、ポート番号管理
テーブル３０４を、呼識別符号３９２をキーとして、検
索する。該当する呼識別符号があれば、ステップ３６５
を経て、ステップ３６６へ分岐する。ステップ３６６で
は、呼処理サーバに対して検索したポート番号３２１の
値を返す。これは、後に説明するが、呼処理サーバのサ
ーバ間通信タスク１４（図１参照）で、問い合わせ命令
と応答を対応付けるために用いられる。

【０１６９】次に、ステップ３６７では、図２５を用い
て後に説明するＤＢＳＴ管理プログラム３０３へ依頼
し、検索したＤＢＳＴ番号のタスクへメッセージを送
り、ステップ３６３へ戻る。

【０１７０】ステップ３６４で、呼識別符号３９２をキ
ーとしてポート番号管理テーブル３０４を検索した結
果、該当する呼識別符号がなければ、ステップ３６５を
経て、ステップ３６８へ分岐する。

【０１７１】呼識別符号３９２が割り当てられていない
ということは、ＤＢＳＴを生成しなくてはならないとい
うことであるから、ステップ３６８では、ポート番号管
理テーブル３０４から、ＤＢＳＴ番号３２３が「空」で
ある行を検索する。ステップ３６９では、見つけた行の
呼識別符号３２２へ（問い合わせメッセージの）呼識別
符号３９２を設定する。そして、ステップ３７０では、
呼処理サーバへポート番号３２１の値を返す。

【０１７２】次に、ステップ３７１では、ＤＢＳＴ管理
プログラムへ問い合わせメッセージを送り、新たにＤＢ
ＳＴを生成するよう要求する。ステップ３７２では、要
求により生成されたＤＢＳＴの番号をＤＢＳＴ管理プロ
グラムから得る。ステップ３７３では、得たＤＢＳＴ番
号を、ポート番号管理テーブル３０４のＤＢＳＴ番号３
２３へ設定し、ステップ３６３へ戻る。

【０１７３】ステップ３６３で、問い合わせメッセージ
が図２１の書式４０１のスタイルであれば、ステップ３
７４へ処理フローを分岐する。問い合わせメッセージに
呼識別符号がないので、これは無名ＤＢＳＴ８（図１参
照）で処理すべき問い合わせであるということになる。

【０１７４】ステップ３７４では、ポート番号管理テー
ブル３０４から、ＤＢＳＴ番号３２３が「空」である行
を検索する。ステップ３７５では、見つけた行の呼識別
符号３２２に対し、無名ＤＢＳＴであることを意味する
値として、例えば「ｎｏｎａｍｅ」を設定する。次に、
ステップ３７０に進む。ステップ３７０以降の処理は既
に述べた。

【０１７５】次に、図２２のフローチャートを参照し
て、フロントエンドタスク６の応答返信プログラム３０
２の処理手順を説明する。

【０１７６】応答返信プログラム３０２は、ＤＢＳＴか
らの応答メッセージを呼処理サーバへ返信する処理を行
なう。このプログラム３０２は、データベースサーバが
起動した直後から処理を開始（ステップ４１１）してい
る。まず、ステップ４１２では、ＤＢＳＴからの応答メ
ッセージの受け付けを待機している。

【０１７７】図２３に、受け付けるべき応答メッセージ
４３１の書式を示す。応答メッセージ４３１は、ＤＢＳ
Ｔ番号４３２と、応答４３３とからなる。

【０１７８】ステップ４１３では、応答メッセージが、
ＤＢＳＴの終了を表すＤＢＳＴ終了メッセージ５１１な
らば（ｙｅｓ）ステップ４１７へ、そうでなければ（ｎ
ｏ）ステップ４１４へ、処理フローを分岐する。

【０１７９】図２９は、ＤＢＳＴ終了メッセージ５１１
を示す。ＤＢＳＴ終了メッセージ５１１は、ＤＢＳＴ終
了報告５１２と、ＤＢＳＴ番号５１３とからなる。

【０１８０】ステップ４１７では、ポート番号管理テー
ブル３０４から、ＤＢＳＴ終了メッセージ５１１のＤＢ
ＳＴ番号５１３に該当するＤＢＳＴ番号３２３の行をみ
つけ、その行のＤＢＳＴ番号３２３及び呼識別符号３２
２に、使用されていないことを表す値として「空」を設
定し、ポート番号を解放する。その後、ステップ４１２
へ進む。

【０１８１】ステップ４１３で、応答メッセージがＤＢ
ＳＴ終了メッセージ５１１でないなら、ステップ４１４
に進む。ステップ４１４では、応答メッセージ４３１の
ＤＢＳＴ番号４３２をキーとしてポート番号管理テーブ
ル３０４を検索する。そして、ステップ４１５で、該当
するポート番号３２１の値を取得する。

【０１８２】さらに、ステップ４１６では、応答メッセ
ージ４３１の応答４３３（図２３）に、ステップ４１５
で取得したポート番号３２１の値を付加し、図２４に示
す応答メッセージ４４１の書式に変換して、呼処理サー
バへ返信する。

【０１８３】図２４において、応答メッセージ４４１
は、ステップ４１５で取得したポート番号の値を持つポ
ート番号４４２と、応答メッセージ４３１の応答４３３
のコピーである応答４４３とから成る。

【０１８４】次に、図２５のフローチャートを参照し
て、フロントエンドタスク６のＤＢＳＴ管理プログラム
３０３の処理手順を説明する。

【０１８５】ＤＢＳＴ管理プログラム３０３は、ＤＢＳ
Ｔの生成、及び消滅などの管理を行なう。このプログラ
ム３０３は、データベースサーバが起動した直後から処
理を開始（ステップ４５１）している。まず、ステップ
４５２では、命令受付プログラムからＤＢＳＴの生成要
求があったかどうかを監視し、あれば（ｙｅｓ）ステッ
プ４６０へ、なければ（ｎｏ）ステップ４５３へ、それ
ぞれ分岐する。ＤＢＳＴの生成要求は、命令受付プログ
ラム３０１のステップ３７１（図１９参照）で発行され
る。

【０１８６】図２６と図２７に、発行されるＤＢＳＴ生
成要求メッセージを示す。図２６のＤＢＳＴ生成要求メ
ッセージ４８１は、呼識別符号が付加されたスタイルで
あり、ＤＢＳＴ生成命令４８２、呼識別符号４８３、及
び問い合わせ命令４８４を含む。図２７のＤＢＳＴ生成
要求メッセージ４９１は、呼識別符号が付加されないス
タイルであり、ＤＢＳＴ生成命令４９２、及び問い合わ
せ命令４９３を含む。ＤＢＳＴ生成要求メッセージ４９
１により生成されるのは、無名ＤＢＳＴ８（図１、図１
５参照）である。

【０１８７】命令受付プログラム３０１からＤＢＳＴの
生成要求があれば、ステップ４５２から、ステップ４６
０へ分岐する。ステップ４６０では、ＤＢＳＴ生成要求
メッセージが、図２６の参照番号４８１のスタイルであ
ればステップ４６２へ、図２７の参照番号４９１のスタ
イルであればステップ４６１へ、処理フローを分岐す
る。

【０１８８】ステップ４６２では、生成すべきＤＢＳＴ
のタイプを、問い合わせ命令４８４に含まれる通信サー
ビス番号から決定し、ＤＢＳＴを生成する。これは、例
えば発呼者が図５及び図６で例に取り上げた「内線接続
サービス」を要求しているとすれば、これに対応したデ
ータ構造体７２を適用してＤＢＳＴを生成するというこ
とである。ＤＢＳＴを生成するということは、主記憶装
置ＭＭ３３の記憶領域を割り当てることも意味する。

【０１８９】ＤＢＳＴ生成要求メッセージが図２７の参
照番号４９１のスタイルであれば、ステップ４６１へ分
岐する。ステップ４６１では、無名ＤＢＳＴ８を生成す
る。

【０１９０】ステップ４６２、またはステップ４６１か
ら、ステップ４６３へ進む。ステップ４６３では、ＤＢ
ＳＴ生成時に割り当てた記憶領域のスワップアウト禁止
を、ＯＳ（オペレーティングシステム）に要求する。本
実施例では、仮想記憶をサポートしたＯＳを仮定してい
る。

【０１９１】次に、ステップ４６４では、生成したＤＢ
ＳＴへのポインタを、ＤＢＳＴ管理テーブル３０５（図
１８参照）のタスクへのポインタ３４２が「空」の行、
例えば行３４９にセットする。ステップ４６５では、ス
テップ４６４で割り当てたＤＢＳＴ番号３４１の値（例
えば、７）を命令受付プログラムへ返す。これは、命令
受付プログラム３０１のステップ３７２（図１９参照）
で受け取られる。ステップ４６６では、生成したＤＢＳ
Ｔに問い合わせ命令４８４（図２６）、または問い合わ
せ命令４９３（図２７）の内容を渡し、ステップ４５２
へ戻る。

【０１９２】ステップ４５２で条件が成立しない（ｎ
ｏ）場合、すなわち命令受付プログラムからのＤＢＳＴ
の生成要求でない場合は、ステップ４５３へ進む。ステ
ップ４５３では、命令受付プログラム３０１から、メッ
セージ配信要求があったかどうかを監視する。

【０１９３】図２８に、配信要求メッセージ５０１を示
す。配信要求メッセージ５０１は、配信命令５０２、Ｄ
ＢＳＴ番号５０３、及び問い合わせ命令５０４から成
る。

【０１９４】ステップ４５３で配信要求メッセージ５０
１があれば（ｙｅｓ）、ステップ４５８へ分岐する。ス
テップ４５８では、ＤＢＳＴ管理テーブル３０５をＤＢ
ＳＴ番号５０３をキーとして検索する。ステップ４５９
では、ステップ４５８で該当したポインタの示すＤＢＳ
Ｔへ、問い合わせ命令５０４の内容を渡し、ステップ４
５２へ戻る。

【０１９５】ステップ４５３で条件が成立しない（ｎ
ｏ）場合、すなわち配信要求メッセージ５０１でない場
合は、ステップ４５４へ進む。ステップ４５４では、い
ずれかのＤＢＳＴから、終了メッセージが発行されたか
どうかを監視する。

【０１９６】図２９に、ＤＢＳＴ終了メッセージ５１１
を示す。ＤＢＳＴ終了メッセージ５１１は、ＤＢＳＴ終
了報告５１２、及びＤＢＳＴ番号５１３からなる。この
ＤＢＳＴ終了メッセージ５１１は、データベースサービ
スプログラム７１のステップ１０３（図５参照）、また
は無名データベースサービスプログラム２４１のステッ
プ２５０（図１５参照）で発行される。

【０１９７】ステップ４５４でＤＢＳＴ終了メッセージ
５１１が発行されていなければ（ｎｏ）、ステップ４５
２へ戻る。発行されていれば（ｙｅｓ）、ステップ４５
５へ進む。ステップ４５５では、ＤＢＳＴ終了メッセー
ジ５１１のＤＢＳＴ番号５１３が示すＤＢＳＴに割り当
ててあった記憶領域の解放をＯＳに要求する。ステップ
４５６では、ＤＢＳＴ番号管理テーブル３０５のＤＢＳ
Ｔ番号５１３の値に該当する行のタスクへのポインタ３
４２を「空」にして、解放する。そして、ステップ４５
７では、応答返信プログラム３０２へタスク終了メッセ
ージを発行し、ステップ４５２へ戻る。タスク終了メッ
セージは、応答返信プログラム３０２のステップ４１２
で受け付けられ、同ステップ４１７の処理が行われる。

【０１９８】（４）サーバ間通信タスクサーバ間通信タスク１４（図１参照）は、呼処理サーバ
２７内にある。サーバ間通信タスク１４は、データベー
スサーバ３１のフロントエンドタスク６と協調して、命
令と応答のやりとりを制御し、ある問い合わせ命令に対
する応答を正しく選択し返すことを保証する。

【０１９９】図３０は、呼処理サーバのサーバ間通信タ
スク１４の構成を示す。サーバ間通信タスク１４は、呼
処理サーバ２７の主記憶装置ＭＭ２９内にあり、ポート
管理プログラム５２１、及びポート番号管理テーブル５
２２から構成される。

【０２００】図３１は、ポート番号管理テーブル５２２
の構成を示す。ポート番号管理テーブル５２２は、タス
ク番号５３１及びポート番号５３２の項目からなるテー
ブルである。タスク番号５３１は、呼制御タスクに１対
１で与えられる番号である。ポート番号５３２は、デー
タベースサーバ３１との通信を管理するための番号であ
り、データベースサーバ側と同一の値をとり、１対１に
対応している。

【０２０１】図３２のフローチャートを参照して、ポー
ト管理プログラム５２１の処理手順を説明する。

【０２０２】このプログラム５２１は、呼処理サーバが
起動された直後から処理を開始（ステップ５５１）して
いる。まず、ステップ５５２では、データベースサーバ
３１から応答メッセージを受け取ったかどうかを監視す
る。応答メッセージ４４１は、図２４に示した。応答メ
ッセージ４４１を受け取ったら、ステップ５６１へ分岐
する。

【０２０３】ステップ５６１では、受信した応答メッセ
ージ４４１からポート番号４４２を取得する。ステップ
５６２では、ポート番号管理テーブル５２２をポート番
号４４２の値をキーにして検索し、該当するタスク番号
５３１の値を得る。ステップ５６３では、タスク番号５
３１の値の示すタスクへ応答４４３を渡す。ステップ５
６３の後、ステップ５５２に戻る。

【０２０４】ステップ５５２で条件が成立しない場合
（ｎｏ）、すなわちデータベースサーバ３１から応答メ
ッセージを受け取っていない場合は、ステップ５５３に
進む。ステップ５５３では、呼制御タスクからの問い合
わせメッセージを受け取ったかどうかで処理フローを分
岐する。問い合わせメッセージが呼制御タスクからのも
のであれば（ｙｅｓ）、ステップ５５８へ、そのほかの
（呼制御タスクからでない）問い合わせメッセージなら
ば（ｎｏ）、ステップ５５４へ、分岐する。

【０２０５】ここで、呼制御タスクからの問い合わせメ
ッセージ５９１は、図３４に示すように、タスク番号５
９２、呼識別符号５９３、及び問い合わせ命令５３４か
ら成る。また、そのほかの（呼制御タスクからでない）
問い合わせメッセージ５８１は、図３３に示すように、
タスク番号５８２、及び問い合わせ命令５８３から成
る。

【０２０６】ステップ５５８では、問い合わせメッセー
ジ５９１の呼識別符号５９３の値を取得する。また、ス
テップ５５９では、問い合わせメッセージ５９１のタス
ク番号５９２を取得する。ステップ５６０では、データ
ベースサーバに対して、呼識別符号を付加した問い合わ
せメッセージ３９１を発行する。問い合わせメッセージ
３９１は、図２０に示した。

【０２０７】ステップ５５３で条件が成立しなかった場
合（ｎｏ）、すなわち呼制御タスクからの問い合わせメ
ッセージでない場合は、ステップ５５４へ進む。ステッ
プ５５４では、（呼制御タスクからでない）問い合わせ
メッセージ５８１からタスク番号５８２を取得する。次
に、ステップ５５５では、データベースサーバに対し
て、問い合わせメッセージ４０１を発行する。問い合わ
せメッセージ４０１は、図２１に示した。

【０２０８】ステップ５５５及びステップ５６０から、
ステップ５５６へ進む。ステップ５５６では、データベ
ースサーバのフロントエンドタスク６から返されるポー
ト番号を受信する。これは、命令受付プログラム３０１
のステップ３６６，３７０（図１９参照）で発行され
る。ステップ５５７では、受信したポート番号の値をポ
ート番号管理テーブル５２２のポート番号５３２へ設定
し、ステップ５５２へ戻る。

【０２０９】３．呼制御の実行手順の説明

【０２１０】次に、図３５を用いて、１件のサービス呼
（ＩＮ２１へのアクセスを要する電話接続等）に関する
呼制御の実行手順を説明する。図３５は、呼制御タスク
の処理フローを中心に、ＤＢＳＴ及び通信サーバとの間
でやり取りされるメッセージの時間的な順序関係を示
す。サービス呼として、本実施例中で説明した「公衆網
を用いた内線接続サービス」を例にとる。

【０２１１】呼処理サーバ２７内の呼制御タスクが、ス
テップ６２５で動作を開始し、ステップ６２６で終了す
るとする。呼制御タスクからのメッセージ６０１を受け
たデータベースサーバ３１内でＤＢＳＴが起動され、処
理を開始する（ステップ６２７）。ＤＢＳＴは、ステッ
プ６２８で終了する。以下、呼制御タスクのフローに従
って、やり取りされるメッセージを順に説明する。

【０２１２】呼制御タスクが開始されると（ステップ６
２５）、当該呼制御を実行するために必要な通信サービ
ス手順を問い合わせるメッセージ６０１が、データベー
スサーバ３１に対して発行される。メッセージ６０１
は、フロントエンドタスク６（図１６参照）に受け取ら
れる。フロントエンドタスク６は、新たに記憶領域を割
り当ててＤＢＳＴ（図４参照）を生成する。新たに生成
されたＤＢＳＴは、メッセージ６０１に対して、通信サ
ービスの手順に関する情報を検索し、結果を応答メッセ
ージ６０２として返答する。

【０２１３】通信サービス手順が決まると、発呼側加入
者リソース（発呼側端末のリソースレコード１７９、図
１０参照）を参照する問い合わせメッセージ６０３が、
呼制御タスクからＤＢＳＴに対して発行される。ＤＢＳ
Ｔは、メッセージ６０３に対する処理結果を応答メッセ
ージ６０４として返答する。

【０２１４】次に、発呼側端末が現在使用中であること
を登録するために、発呼側端末のリソースレコード１７
９のリソース使用数１５３（図１０参照）をカウントア
ップする。そのカウントアップのメッセージ、すなわち
更新するための問い合わせメッセージ６０５を、ＤＢＳ
Ｔに対して発行する。ＤＢＳＴからは、メッセージ６０
５に対する処理結果を応答メッセージ６０６として返答
する。

【０２１５】次に、内線番号を物理番号に変換するため
の問い合わせメッセージ６０７が、発行される。ＤＢＳ
Ｔからは、メッセージ６０７に対する処理結果を応答メ
ッセージ６０８として返答する。

【０２１６】着信側の物理番号が決定すると、着呼側加
入者リソース（着呼側端末のリソースレコード１８０、
図１０参照）を参照する問い合わせメッセージ６０９
が、発行される。ＤＢＳＴは、メッセージ６０９に対す
る処理結果を応答メッセージ６１０として返答する。

【０２１７】次に、交換機に電話回線接続を指示するた
め、回線接続を要求するメッセージ６２１を通信サーバ
に対して発行する。通信サーバは、交換機に対して電話
回線接続を指示し、電話回線接続が完了すると回線接続
完了を示すメッセージ６２２を呼制御タスクに返す。

【０２１８】電話回線接続が完了すると、着呼側端末が
現在使用中であることを登録するために、着呼側端末の
リソースレコード１８０のリソース使用数１５３（図１
０参照）をカウントアップする。そのために、カウント
アップするための問い合わせメッセージ６１１をＤＢＳ
Ｔに対して発行する。ＤＢＳＴからは、メッセージ６１
１に対する処理結果を応答メッセージ６１２として返答
する。

【０２１９】電話回線接続が完了し、呼出中であった着
呼側端末が応答する（電話に出る）と、通話開始を示す
メッセージ６２３が、通信サーバから呼制御タスクに対
して返される。

【０２２０】通話中になると同時に課金を開始しなけれ
ばならないので、現在の課金値を参照するための問い合
わせメッセージ６１３をＤＢＳＴに対して発行する。Ｄ
ＢＳＴからは、メッセージ６１３に対する処理結果を応
答メッセージ６１４として返答する。

【０２２１】通話が終了すると、通話終了を示すメッセ
ージ６２４が通信サーバから呼制御タスクに対して返さ
れる。

【０２２２】すると、呼制御タスクは、その通話に関す
る課金値を計算し、発呼側端末のリソースレコードに登
録するための問い合わせメッセージ６１５をＤＢＳＴに
対して発行する。ＤＢＳＴからは、メッセージ６１５に
対する処理結果を応答メッセージ６１６として返答す
る。

【０２２３】通話が終了すると、発呼側端末の使用が終
了したこと（リソース解放）を登録するために、発呼側
端末のリソースレコード１７９のリソース使用数１５３
（図１０参照）をカウントダウンする。このために、更
新の問い合わせメッセージ６１７をＤＢＳＴに対して発
行する。ＤＢＳＴからは、メッセージ６１７に対する処
理結果を応答メッセージ６１８として返答する。

【０２２４】また、着呼側端末の使用も終了したこと
（リソース解放）を登録するために、着呼側端末のリソ
ースレコード１８０のリソース使用数１５３（図１０参
照）をカウントダウンする。このために、更新の問い合
わせメッセージ６１９をＤＢＳＴに対して発行する。Ｄ
ＢＳＴからは、メッセージ６１９に対する処理結果を応
答メッセージ６２０として返答する。

【０２２５】以上のように、「公衆網を用いた内線接続
サービス」における、呼処理サーバ内の呼制御タスクか
らデータベースサーバ内のＤＢＳＴに対する問い合わせ
は、データベースを参照するものが５回、更新するもの
が５回行なわれる。これら１０回の問い合わせのうち、
本発明を適用した場合、ＤＢＳＴ内のアドレスバッフ
ァ、データバッファが有効に使用され応答時間が短縮さ
れる問い合わせを以下に挙げる。

【０２２６】メッセージ６０５による更新処理では、対
象となるデータレコードが予めバッファされているの
で、データバッファが有効に使用される。メッセージ６
０７による参照処理では、予め先読み処理によりデータ
レコードへのアドレスがバッファされているので、アド
レスバッファが有効に使用される。メッセージ６０９に
よる参照処理では、予め先読み処理によりデータレコー
ドがバッファされているので、データバッファが有効に
使用される。

【０２２７】メッセージ６１１による更新処理では、予
めデータレコードがバッファされているので、データバ
ッファが有効に使用される。メッセージ６１３による参
照処理では、予めデータレコードがバッファされている
ので、データバッファが有効に使用される。メッセージ
６１５による更新処理では、予めデータレコードがバッ
ファされているので、データバッファが有効に使用され
る。

【０２２８】メッセージ６１７による更新処理では、予
めデータレコードがバッファされているので、データバ
ッファが有効に使用される。メッセージ６１９による更
新処理では、予めデータレコードがバッファされている
ので、データバッファが有効に使用される。

【０２２９】４．効果の説明

【０２３０】次に、上述した本実施例の効果を説明す
る。

【０２３１】本実施例では、データベースサーバの応答
時間短縮が主な目的である。データベースサーバの応答
時間は、ディスクアクセス時間に大きく左右される。問
い合わせ対象のデータレコードが主記憶装置内にバッフ
ァされている場合と、バッファされておらずディスクア
クセスが発生する場合とで、処理時間を比較する。

【０２３２】データベースサーバにおいて、主記憶装置
へのアクセスは多く見積もっても数μｓもあれば完了す
る。それに対し、１回のディスクへのアクセスは少なく
見積っても数ｍｓ以上はかかる。よって、バッファが有
効である場合と、ディスクアクセスが発生する場合とで
は、応答時間に、少なくとも千倍以上の差がある。そこ
で、本実施例では、問い合わせ処理、つまりトランザク
ション処理において発生するディスクアクセス回数を比
較し、これが少なければ問い合わせに対する応答時間短
縮に効果がある、とする。

【０２３３】バッファによるトランザクション処理にお
けるディスクアクセス回数の削減効果を、場合分けし
て、説明する。

【０２３４】まず、バッファが有効でない場合の参照ト
ランザクションでは、テーブル検索とレコード検索でデ
ィスクアクセスが２回発生するとする。同じく、更新ト
ランザクションでは、テーブル検索とデータ書き込み、
ロック処理等でディスクアクセスが３回発生するとす
る。

【０２３５】次に、データレコードへのアドレスのみが
バッファされている場合、参照トランザクションでは、
レコード検索でディスクアクセスが１回発生するとす
る。同じく、更新トランザクションでは、データ書き込
みとロック処理等でディスクアクセスが２回発生すると
する。

【０２３６】最後に、データレコードがバッファされて
いる場合、参照トランザクションでは、ディスクアクセ
スは発生しない。同じく更新トランザクションでは、デ
ータ書き込みとロック処理などでディスクアクセスが２
回発生するとする。

【０２３７】上述の図３５で具体例として説明した内線
接続サービスの呼制御が完了するまでに発行する一連の
問い合わせは、参照が５回、更新が５回である。本実施
例の方法を用いずにデータやアドレスのバッファを行な
わないとすると、この一連の問い合わせによって引き起
こされるディスクアクセス回数は、上記のディスクアク
セス回数の定義に従えば、２５回（３×５＋２×５）で
ある。これに対し、同じ例で本実施例の方法を適用した
場合は、同一レコードへの問い合わせや、先読み処理に
よりＤＢＳＴ内のデータバッファ、アドレスバッファが
有効となり、削減できるディスクアクセス回数は１０回
である。

【０２３８】このように、本実施例の内線接続サービス
という通信サービスの場合、一連の呼制御におけるディ
スクアクセス回数を４０％程度削減できる。従って、呼
制御に係わるデータベースサービスにおける応答時間削
減が可能である。

【０２３９】

【発明の効果】本発明によれば、ある呼制御に１対１で
対応したデータベースサービスタスクにより該呼制御に
関するデータベース処理の実行および管理を行うように
しているので、呼処理サーバからの問い合わせに対する
応答時間を短縮出来る。

【０２４０】また、データベースを検索して得られるデ
ータレコードやデータレコードへのアドレスをデータベ
ースサービスタスク内に複写して保持することにより、
同一データレコードへの問い合わせに対する応答時間を
短縮出来る。

【０２４１】さらに、呼制御の処理を先取りして必要な
データレコードを予め取得しておくこともできるため、
該データレコードへの問い合わせに対する応答時間を短
縮できる。

【０２４２】また、データベースサービスタスクが終了
するまでは該タスクをスワップアウトさせないようにタ
スク管理を行なうので、不要なオーバヘッドを削減し、
問い合わせに対する応答時間を短縮できる。

【０２４３】また、従来の問い合わせ要求に対してもデ
ータベースサービスを行えるので、マルチベンダ環境に
も対応できる。

【図面の簡単な説明】

【図１】本発明の一実施例に係るＳＣＰ内のソフトウエ
アの構成を示す図

【図２】本実施例のＳＣＰを備えたネットワークのハー
ドウエア構成を示す図

【図３】従来のデータベースサーバのソフトウエアの構
成を示す図

【図４】データベースサービスタスク（ＤＢＳＴ）の概
略構成図

【図５】ＤＢＳＴのデータベースサービスプログラムの
処理手順を示すフローチャート図

【図６】内線接続サービス専用のデータ構造体の構成を
示す図

【図７】データ構造体の先読み処理用テーブルの構成図

【図８】データ構造体のバッファテーブルの構成図

【図９】端末リソーステーブルのレコード書式を示す図

【図１０】ディスク内に格納されている端末リソーステ
ーブルの構成図

【図１１】ディスク内に格納されている番号変換テーブ
ルの構成図

【図１２】先読み処理の手順を示すフローチャート図

【図１３】先読み処理用専用プログラムａの処理手順を
示すフローチャート図

【図１４】先読み処理用専用プログラムｂの処理手順を
示すフローチャート図

【図１５】無名データベースサービスプログラムの処理
手順を示すフローチャート図

【図１６】フロントエンドタスクの概略構成図

【図１７】フロントエンドタスクのポート番号管理テー
ブルの構成図

【図１８】フロントエンドタスクのＤＢＳＴ番号管理テ
ーブルの構成図

【図１９】フロントエンドタスクの命令受付プログラム
の処理手順を示すフローチャート図

【図２０】呼処理タスクからフロントエンドタスクへの
問い合わせメッセージ書式を示す図

【図２１】フロントエンドタスクからＤＢＳＴへの問い
合わせメッセージ書式を示す図

【図２２】フロントエンドタスクの応答返信プログラム
の処理手順を示すフローチャート図

【図２３】ＤＢＳＴからフロントエンドタスクへの応答
メッセージの書式を示す図

【図２４】フロントエンドタスクからサーバ間通信タス
クへの応答メッセージの書式を示す図

【図２５】フロントエンドタスクのＤＢＳＴ管理プログ
ラムの処理手順を示すフローチャート図

【図２６】命令受付プログラムからＤＢＳＴ管理プログ
ラムへのＤＢＳＴ生成要求メッセージの書式（呼識別符
号付き）を示す図

【図２７】命令受付プログラムからＤＢＳＴ管理プログ
ラムへのＤＢＳＴ生成要求メッセージの書式を示す図

【図２８】命令受付プログラムからＤＢＳＴ管理プログ
ラムへの配信要求メッセージの書式を示す図

【図２９】ＤＢＳＴからＤＢＳＴ管理プログラムへのＤ
ＢＳＴ終了メッセージの書式を示す図

【図３０】呼処理サーバのサーバ間通信タスクの概略構
成図

【図３１】呼処理サーバのサーバ間通信タスクのポート
番号管理テーブルの構成図

【図３２】呼処理サーバのサーバ間通信タスクのポート
管理プログラムの処理手順を示すフローチャート図

【図３３】呼制御タスクからサーバ間通信タスクへの問
い合わせメッセージの書式を示す図

【図３４】呼制御タスクからサーバ間通信タスクへの問
い合わせメッセージ（呼識別符号付き）の書式を示す図

【図３５】呼制御タスクの処理フローとＤＢＳＴ及び通
信サーバとの間でやり取りされるメッセージの時間的な
順序関係を示す図

【符号の説明】

２〜５…データベースサービスタスク、１５…データバ
ッファ、１６…アドレスバッファ、６…フロントエンド
タスク、７…ディスクコントロールプログラム、８…無
名データベースサービスタスク、１０〜１３…呼制御タ
スク、１４…サーバ間通信タスク、１７…呼制御タスク
の識別符号、１８…識別符号信号、１９…問い合わせ命
令信号、２０…応答信号、７１…データベースサービス
プログラム、８１〜１０８…処理、７２…データ構造
体、１１３…先読み処理用テーブル、１１４〜１１８…
先読み処理用テーブルの項目、１３１〜１３３…先読み
処理用テーブルの行、１１９…バッファテーブル、１２
０〜１２６、１４０…バッファテーブルの項目、１３４
〜１３９…バッファテーブルの行、２０１…先読み処
理、２０２〜２０６…処理、２１１…先読み処理から実
行されるプログラムａ、２１２〜２１６…処理、２２１
…先読み処理から実行されるプログラムｂ、２２２〜２
２７…処理、２４１…無名データベースサービスプログ
ラム、２４２〜２５１…処理、３０１…命令受付プログ
ラム、３６１〜３７５…処理、３０２…応答返信プログ
ラム、４１１〜４１７…処理、３０３…データベースサ
ービスタスク管理プログラム、４５１〜４６６…処理、
３０４…ポート番号管理テーブル、３２１〜３２３…ポ
ート番号管理テーブルの項目、３２４〜３３１…ポート
番号管理テーブルの行、３０５…データベースサービス
タスク番号管理テーブル、３４１、３４２…データベー
スサービスタスク番号管理テーブルの行、３４３〜３４
９…データベースサービスタスク番号管理テーブルの
行、５２１…ポート管理プログラム、５５１〜５６３…
処理、５２２…ポート番号管理テーブル、５３１、５３
２…ポート番号管理テーブルの項目、５３３〜５３６…
ポート番号管理テーブルの行。

Claims

【特許請求の範囲】

【請求項１】他のデータ処理装置からデータベースサー
ビス機能を提供される第１のデータ処理装置と、該第１
のデータ処理装置に対しデータベースサービス機能を提
供する第２のデータ処理装置とを通信網で接続して成る
システムにおいて用いるデータベースサービス方法であ
って、上記第１のデータ処理装置内で実行される第１のタスク
と、該第１のタスクから発行されるデータベースサービ
ス要求を受けて上記第２のデータ処理装置内で実行され
る第２のタスクとを、該データベースサービス要求に付
加した識別符号を用いて対応させることを特徴とするデ
ータベースサービス方法。
【請求項２】他のデータ処理装置からデータベースサー
ビス機能を提供される第１のデータ処理装置と、該第１
のデータ処理装置に対しデータベースサービス機能を提
供する第２のデータ処理装置とを通信網で接続して成る
システムにおいて用いるデータベースサービス方法であ
って、上記第１のデータ処理装置内で実行される第１のタスク
から上記第２のデータ処理装置にデータベースサービス
を要求する際には、その第１のタスクを他のタスクから
区別する識別符号を付加してデータベースサービス要求
を行うステップと、該データベースサービス要求を受け取った上記第２のデ
ータ処理装置では、該データベースサービス要求に付加
されている識別符号に対応する第２のタスクが自データ
処理装置内に存在するか否かを判別するステップと、該識別符号に対応する第２のタスクが自データ処理装置
内に存在しない場合は、該識別符号に対応する第２のタ
スクを生成し、該第２のタスクでデータベースサービス
を実行するステップと、該識別符号に対応する第２のタスクが自データ処理装置
内に存在する場合は、その存在する第２のタスクでデー
タベースサービスを実行するステップとを備えたことを
特徴とするデータベースサービス方法。
【請求項３】呼制御を実行する呼処理サーバと、呼制御
に必要なデータを蓄積して参照や更新等のデータベース
サービス機能を提供するデータベースサーバとを含んで
構成されるサービスコントロールポイントにて用いるデ
ータベースサービス方法であって、上記呼処理サーバ内で実行される１つの呼制御からの要
求に応じて、上記データベースサーバ内で複数回のデー
タベース処理が実行される際、該呼制御に対応したタス
クによりそれらのデータベース処理の実行および管理を
行なうことを特徴とするデータベースサービス方法。
【請求項４】請求項３に記載のデータベースサービス方
法において、前記呼制御が前記データベースサーバに対
してデータベースサービスを要求する際には、該呼制御
を他の呼制御から区別することが可能な識別符号を付加
してデータベースサービスを要求することを特徴とする
データベースサービス方法。
【請求項５】呼制御を実行する呼処理サーバと、呼制御
に必要なデータを蓄積して参照や更新等のデータベース
サービス機能を提供するデータベースサーバとを含んで
構成されるサービスコントロールポイントにて用いるデ
ータベースサービス方法であって、上記呼処理サーバ内で実行される呼制御タスクから上記
データベースサーバにデータベースサービスを要求する
際には、その呼制御タスクを他の呼制御タスクから区別
することが可能な識別符号を付加してデータベースサー
ビス要求を行うステップと、該データベースサービス要求を受け取った上記データベ
ースサーバでは、該データベースサービス要求に付加さ
れている識別符号に対応するデータベースサービスタス
クが自データベースサーバ内に存在するか否かを判別す
るステップと、該識別符号に対応するデータベースサービスタスクが自
データベースサーバ内に存在しない場合は、該識別符号
に対応するデータベースサービスタスクを生成し、該デ
ータベースサービスタスクでデータベースサービスを実
行するステップと、該識別符号に対応するデータベースサービスタスクが自
データベースサーバ内に存在する場合は、その存在する
データベースサービスタスクでデータベースサービスを
実行するステップとを備えたことを特徴とするデータベ
ースサービス方法。
【請求項６】請求項５に記載のデータベースサービス方
法において、前記データベース処理の実行および管理を
行なうデータベースサービスタスクは、データベースか
ら検索して得るデータレコードの内容の全部または一部
を該データベースサービスタスク内に複写して保持する
ことを特徴とするデータベースサービス方法。
【請求項７】請求項５に記載のデータベースサービス方
法において、前記データベース処理の実行および管理を
行なうデータベースサービスタスクは、データベースか
ら検索して得るデータレコードのデータベース内でのア
ドレスを該データベースサービスタスク内に複写して保
持することを特徴とするデータベースサービス方法。
【請求項８】請求項５に記載のデータベースサービス方
法において、前記データベース処理の実行および管理を
行なうデータベースサービスタスクは、該データベース
サービスタスクと前記識別符号により対応付けられる呼
制御タスクが実現する通信サービス内容に従って、該通
信サービスを実行するために必要なデータレコードをデ
ータベースから検索し、該データレコードの内容の全部
または一部を該データベースサービスタスク内に複写し
て保持することを特徴とするデータベースサービス方
法。
【請求項９】請求項５に記載のデータベースサービス方
法において、前記データベース処理の実行および管理を
行なうデータベースサービスタスクは、該データベース
サービスタスクと前記識別符号により対応付けられる呼
制御タスクが実現する通信サービス内容に従って、該通
信サービスを実行するために必要なデータレコードをデ
ータベースから検索し、該データレコードのデータベー
ス内でのアドレスを該データベースサービスタスク内に
複写して保持することを特徴とするデータベースサービ
ス方法。
【請求項１０】請求項８または９に記載のデータベース
サービス方法において、前記呼制御タスクによる通信サ
ービス実行上の必要によって行われるデータベースサー
ビス要求の発行の有無に拘らず、対応する前記データベ
ースサービスタスクが自動的に前記通信サービスを実行
するために必要なデータレコードを予めデータベースか
ら検索することを特徴とするデータベースサービス方
法。
【請求項１１】請求項４から１０のいずれか１つに記載
のデータベースサービス方法において、前記識別符号を
付加しないデータベースサービス要求に対しても、デー
タベースサービスを行うことを特徴とするデータベース
サービス方法。
【請求項１２】請求項３から１１のいずれか１つに記載
のデータベースサービス方法において、前記呼処理サー
バ内のある呼制御に対応してデータベース処理の実行お
よび管理を行なうデータベースサーバ内のデータベース
サービスタスクが終了するまでは、該データベースサー
ビスタスクの占める記憶領域を仮想記憶装置の作用によ
り主記憶装置からディスク等の外部記憶装置へ移動させ
ないようにタスク管理を行うデータベースサービス方
法。
【請求項１３】呼制御を実行する呼処理サーバと、呼制
御に必要なデータを蓄積して参照や更新等のデータベー
スサービス機能を提供するデータベースサーバとを含む
サービス制御装置であって、上記呼処理サーバ内で実行される呼制御タスクから上記
データベースサーバにデータベースサービスを要求する
際に、その呼制御タスクを他の呼制御タスクから区別す
ることが可能な識別符号を付加してデータベースサービ
ス要求を行う手段と、該データベースサービス要求を受け取った上記データベ
ースサーバにて、該データベースサービス要求に付加さ
れている識別符号に対応するデータベースサービスタス
クが自データベースサーバ内に存在するか否かを判別す
る手段と、該識別符号に対応するデータベースサービスタスクが自
データベースサーバ内に存在しない場合は、該識別符号
に対応するデータベースサービスタスクを生成し、該デ
ータベースサービスタスクでデータベースサービスを実
行する手段と、該識別符号に対応するデータベースサービスタスクが自
データベースサーバ内に存在する場合は、その存在する
データベースサービスタスクでデータベースサービスを
実行する手段とを備えたことを特徴とするサービス制御
装置。
【請求項１４】請求項１３に記載のサービス制御装置に
おいて、さらに、前記データベースサーバは、データベ
ースから検索して得るデータレコードの内容の全部また
は一部をデータベースサービスタスク内に複写して保持
する手段を備えたことを特徴とするサービス制御装置。
【請求項１５】請求項１３に記載のサービス制御装置に
おいて、さらに、前記データベースサーバは、データベ
ースから検索して得るデータレコードのデータベース内
でのアドレスをデータベースサービスタスク内に複写し
て保持する手段を備えたことを特徴とするサービス制御
装置。
【請求項１６】請求項１３に記載のサービス制御装置に
おいて、さらに、前記データベースサーバは、データベ
ースサービスタスクと前記識別符号により対応付けられ
る呼制御タスクが実現する通信サービス内容に従って、
該通信サービスを実行するために必要なデータレコード
をデータベースから検索し、該データレコードの内容の
全部または一部を該データベースサービスタスク内に複
写して保持する手段を備えたことを特徴とするサービス
制御装置。
【請求項１７】請求項１３に記載のサービス制御装置に
おいて、さらに、前記データベースサーバは、データベ
ースサービスタスクと前記識別符号により対応付けられ
る呼制御タスクが実現する通信サービス内容に従って、
該通信サービスを実行するために必要なデータレコード
をデータベースから検索し、該データレコードのデータ
ベース内でのアドレスを該データベースサービスタスク
内に複写して保持する手段を備えたことを特徴とするサ
ービス制御装置。
【請求項１８】請求項１６または１７に記載のサービス
制御装置において、さらに、前記呼制御タスクによる通
信サービス実行上の必要によって行われるデータベース
サービス要求の発行の有無に拘らず、対応する前記デー
タベースサービスタスクが自動的に前記通信サービスを
実行するために必要なデータレコードを予めデータベー
スから検索する手段を備えたことを特徴とするサービス
制御装置。
【請求項１９】請求項１３から１８のいずれか１つに記
載のサービス制御装置において、さらに、前記識別符号
を付加しないデータベースサービス要求に対しても、デ
ータベースサービスを行う手段を備えたことを特徴とす
るサービス制御装置。