JP4087941B2 - コンピュータと電話の統合システム - Google Patents
コンピュータと電話の統合システム Download PDFInfo
- Publication number
- JP4087941B2 JP4087941B2 JP05685298A JP5685298A JP4087941B2 JP 4087941 B2 JP4087941 B2 JP 4087941B2 JP 05685298 A JP05685298 A JP 05685298A JP 5685298 A JP5685298 A JP 5685298A JP 4087941 B2 JP4087941 B2 JP 4087941B2
- Authority
- JP
- Japan
- Prior art keywords
- switch engine
- service request
- call
- path
- connection
- 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.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M3/00—Automatic or semi-automatic exchanges
- H04M3/42—Systems providing special services or facilities to subscribers
- H04M3/42314—Systems providing special services or facilities to subscribers in private branch exchanges
- H04M3/42323—PBX's with CTI arrangements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M7/00—Arrangements for interconnection between switching centres
- H04M7/0012—Details of application programming interfaces [API] for telephone networks; Arrangements which combine a telephonic communication equipment and a computer, i.e. computer telephony integration [CPI] arrangements
- H04M7/0021—Details of Application Programming Interfaces
Landscapes
- Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Telephonic Communication Services (AREA)
- Exchange Systems With Centralized Control (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、コンピュータと電話の統合システムに関し、特に、電話交換サービス要求部が、サービス要求処理・呼情報通知手段を介して交換機能を有するスイッチエンジンに対して交換制御を要求し、該スイッチエンジンが呼処理を行うコンピュータと電話の統合システムに関する。
【０００２】
【従来の技術】
従来から、パーソナルコンピュータ等のコンピュータ上で、アプリケーションが、ＡＰＩ（Ａpplication Ｐrogrammatic Ｉnterface）プログラムを使用して、交換機能を有するスイッチエンジンに対して交換制御を要求し、このスイッチエンジンが電話交換の呼処理を行う呼接続制御方式が行われている。ＡＰＩの代表的なものとして、例えば、ＴＳＡＰＩ( Ｔelephony Ｓervice ＡpplicationＰrogrammatic Ｉnterface）が挙げられる。
【０００３】
このＴＳＡＰＩでは、図７のように電話交換における「呼」をモデル化している。電話交換における接続は、デバイス３３と交換機（図示せず）が接続（コネクション３１）され、その交換機とデバイス３４が接続（コネクション３２）され、さらに、交換機において二つの接続を結ぶことにより、呼が完成され、通話が可能となる。図７は、その通話可能時の状態をモデル化しているものである。一つのコール（呼）３０には二つのコネクション３１、３２を必要とするモデルである。つまり、二者接続が呼の基本（一つのコールには二つのコネクションの存在が必要である。）である。発呼のように、一方のデバイスしか関与しない状態を表現する場合は、ダミーのデバイス及びコネクションを必要とする。このモデルで呼制御を行うと、呼の情報がデバイス３３、３４とコール３０との関係を表すコネクション３１、３２（デバイスの識別子とコールの識別子の組み合わせで識別される）で管理される。ＴＳＡＰＩは、このモデルを使用して、呼制御及び呼の管理を行っている。
【０００４】
このモデルのコネクションについて、図８を用いて説明する。コネクションの状態は、Ｎull 状態、Ｃonnected状態、Ｉnitiated状態、Ａlerting 状態、Ｆail 状態、Ｈold 状態及びＱueued 状態を持つ。Ｎull 状態は、コールとデバイスが、物理的にも論理的にも結びついていない状態である。Ｃonncted 状態は、コールとデバイスが、物理的にも論理的にも結びついている状態である。Ｃonnected状態は、デバイスが発信した場合では、相手先への発信手続きが完了した状態であり、デバイスが着信した場合では、呼び出しに応答を返した状態である。Ｉnitiated状態は、交換機がユーザーへ発信に必要な手続きを促している状態である。Ａlerting 状態は、コールがデバイスを呼び出している状態で、次の三つのモードからなる。Ｒingingモード、Ｏfferedモード及びＥntering Ｄistribution モード。Ｒingingモードは、Ｏfferedデバイス（呼を転送するデバイス等）やＤistribution デバイス（代表電話のように呼を割り振るデバイス）を除いた通常のデバイスを呼び出しているモードである。Ｏfferedモードは、コールがＯfferedデバイスに着信して、着信したコールに対し、どこに呼を転送するか等の指示を待っているモードである。Ｅntering Ｄistribution モードは、コールがＤistribution デバイスに着信したモードである。Ｆail 状態は、何らかの理由でコネクションの正常な状態遷移に失敗した状態である。Ｈold 状態は、コールとデバイスとが論理的には結びついているが、物理的には結びついていない状態である。Ｑueued 状態は、何らかの状態変化やアクションが起こるまで待機している状態である。これらの状態は、図９の状態遷移を行う。
【０００５】
【発明が解決しようとする課題】
図７のコールモデルを、Ｈold 状態に関して、図２０（Ａ）を用いて説明する。デバイスＤ１とデバイスＤ２とは通話中で、デバイスＤ１とデバイスＤ３とは、Ｄ３が保留されている状態であるとする。この場合は、デバイスＤ１とデバイスＤ２とは、Ｃonnected状態であって、コールとデバイスが、物理的にも論理的にも結びついている状態である。一方、Ｄ３は、保留されている状態（呼が回線を補足しているが、デバイスＤ３の通話回路は、該回線から切り離されている状態）であるから、呼が存在しており、コールとデバイスとが論理的には結びついている。ところが、デバイスＤ３の通話回路は回線から切り離されているから、デバイスＤ１とデバイスＤ３とは物理的には切り離されており、これらデバイス間では通信できない状態である。この場合、保留されているデバイスＤ３は、物理的には切り離されているにも係わらず、呼が存在するためにデバイスＤ３単独では、コールモデル上存在できない。
【０００６】
従来の呼情報の管理では、Ｈold 状態にみられるように、呼とデバイスが結びつけられていて、デバイスのみを切り離して管理することができず、また、二者接続が基本単位で、一者だけ存在することがモデル上不可能なため、トランクの着信又は発信の制御のようなデバイス単位の制御をアプリケーション側の要求で行うことができないという問題があった。
【０００７】
そこで、本発明では、電話交換サービス要求部であるＣＴＩアプリケーションがスイッチエンジンの呼を制御する場合に、パス接続状態と独立して、デバイス単位の制御が可能とすることを目的とする。
【０００８】
【課題を解決するための手段】
請求項１に記載された発明は、交換制御を行うスイッチエンジン（例えば図１の３）と、該スイッチエンジンに接続するデバイス（例えば図１の４ないし９）と、前記スイッチエンジンに対して電話交換サービスを要求するサービス要求部（例えば図１の１）と、前記スイッチエンジンと前記サービス要求部とのインターフェース機能を有するサービス要求処理・呼情報通知手段とを有し、前記サービス要求処理・呼情報通知手段は、前記サービス要求部から前記スイッチエンジンへの交換サービスの要求の処理及び前記スイッチエンジンから前記サービス要求部への前記スイッチエンジンと前記デバイスに係る呼情報の通知を行い、前記呼情報は、前記デバイスの状態情報と、前記スイッチエンジンと前記デバイス間のパス接続情報の二種類であり、前記デバイスと前記スイッチエンジン間の接続が、他の前記デバイスと前記スイッチエンジン間のパスの接続がなくとも、単独で確立し、前記サービス要求部からのサービス要求に基づき、前記スイッチエンジンと接続が確立している前記デバイスを単位としてサービスを行うことを特徴とする。
【０００９】
請求項１記載の発明によれば、サービス要求処理・呼情報通知手段における呼情報の管理を、デバイス単位の制御を可能とするデバイスの状態情報と前記スイッチエンジンとデバイス間のパス接続情報の二つの情報により行うことにより、サービス要求部からの要求により、呼の制御する場合に、パス接続状態と独立してデバイス単位の制御を行うことができる。
また、請求項１記載の発明は、デバイス単位の制御の具体的な内容を規定している。つまり、デバイスを単位としてサービスが行えるということは、サービス要求処理・呼情報通知手段における呼情報の管理が、デバイス単位の制御を行うことができるということの結果である。その結果、デバイスとスイッチエンジン間の接続が、他の前記デバイスと前記スイッチエンジン間のパスの接続がなくとも単独で確立することが可能となり、前記スイッチエンジンと接続が確立している前記デバイスを単位としてサービスを行うことができるようになり、トーキー装置の駆動のような一方的な接続が可能となる。
【００１２】
請求項２に記載された発明は、請求項１記載のコンピュータと電話の統合システムにおいて、二つの前記デバイスから前記スイッチエンジンへ着信したとき、前記サービス要求部からのサービス要求に基づき、前記二つのデバイス間のパスを接続させることにより、前記スイッチエンジンへ着信してきた前記二つのデバイス間のパス接続を行うことを特徴とする。
【００１３】
請求項２記載の発明によれば、二つのデバイスから前記スイッチエンジンへ着信したとき、二つのデバイス間のパスを接続させることにより、両者の通話が可能となる。具体的には、例えば、一のデバイスをページング呼び出し者（患者）のデバイスとし、他のデバイスをページングにより呼び出された者（ナース又は医者）のデバイスとした場合、の両者の通話が可能となる。
【００１４】
請求項３に記載された発明は、請求項１記載のコンピュータと電話の統合システムにおいて、前記デバイス（例えば図１の４）から前記スイッチエンジン（例えば図１の３）へ着信したとき、前記サービス要求部（例えば図１の１）からのサービス要求に基づき、前記スイッチエンジンから別のデバイス（例えば図１の５）へ発信して、二つのデバイス間のパスを接続させることにより、前記スイッチエンジンへ着信してきたデバイス（例えば図１の４）と前記スイッチエンジンから発信した前記デバイス（例えば図１の５）間のパス接続を行うことを特徴とする。
【００１５】
請求項３記載の発明は、本コンピュータと電話の統合システムの典型的な実施の形態を規定するもので、あるデバイス（例えば図１の４）が他のデバイス（例えば図１の５）に通話のためにダイヤルした場合である。つまり、あるデバイス（例えば図１の４）が他のデバイス（例えば図１の５）にダイヤルすると、その呼がスイッチエンジン（例えば図１の３）に着信する。次いで、スイッチエンジンが相手先の（他の）デバイス（例えば図１の５）へ発信して、相手先のデバイス（例えば図１の５）を呼び出す。相手先のデバイス（例えば図１の５）が応答すると、スイッチエンジンがこれら二つのデバイス間を接続させることにより、通話することができる。
【００１６】
請求項４に記載された発明は、請求項１記載のコンピュータと電話の統合システムにおいて、予め前記スイッチエンジン（例えば図１の３）から第一の前記デバイス（例えば図１の４）へ発信して、前記スイッチエンジンと前記第一のデバイス間の接続を確立させておいて、第二の前記デバイス（例えば図１の４ないし９）から前記スイッチエンジンへ着信したとき、前記サービス要求部（例えば図１の１）からのサービス要求に基づき、前記第一のデバイスと前記第二のデバイス間のパスの接続させることにより、前記第一のデバイスと前記第二のデバイス間のパスの接続を行うことを特徴とする。
【００１７】
請求項４記載の発明は、予めスイッチエンジンから第一のデバイスへ発信して、スイッチエンジンと第一のデバイス間の接続を確立させておいて、第二のデバイスからスイッチエンジンへ着信したとき、第一のデバイスと第二のデバイス間のパスを接続させることにより、両者の通話を可能とした。具体的には、例えば、第一のデバイスをガイダンス装置とし、第二のデバイスをガイダンスを聞く者とし、これにより、ガイダンスのサービスが可能となる。
【００１８】
請求項５に記載された発明は、請求項１記載のコンピュータと電話の統合システムにおいて、前記サービス要求部（例えば図１の１）からのサービス要求に基づき、前記スイッチエンジン（例えば図１の３）から二つの前記デバイス（例えば図１の４と５）へ別々に発信して、二つの前記デバイス間のパスの接続を行うことを特徴とする。
【００１９】
請求項５記載の発明によれば、スイッチエンジンから二つのデバイスへ別々に発信して、二つのデバイス間のパスを接続させることにより、両者の通話を可能とした。具体的には、例えば、在宅勤務の社員が、自宅の電話とお客の電話との通話に、これを利用することにより、課金を会社負担とすることができる。請求項６に記載された発明は、請求項１記載のコンピュータと電話の統合システムにおいて、予め第一の前記デバイス（例えば図１の４）と前記スイッチエンジン（例えば図１の３）間の接続を確立させておいて、前記サービス要求部（例えば図１の１）からのサービス要求に基づき、一度に複数の前記デバイス（例えば図１の５ないし９）へ発信させて、該デバイスが応答すると、前記第一のデバイスと応答した前記デバイス間のパスを接続させることにより、同報サービスを行うことを特徴とする。
【００２０】
請求項６記載の発明によれば、予め同報通信する端末である第一のデバイスとスイッチエンジン間の接続を確立させておいて、一度に、同報通信を受ける複数のデバイスへ発信させ、デバイスが応答すると、その応答したデバイスに第一のデバイスからの同報情報を通知する同報サービスが可能となる。請求項７に記載された発明は、請求項１記載のコンピュータと電話の統合システムにおいて、三つ以上の前記デバイス（例えば図１の４ないし９）と前記スイッチエンジン間の接続が確立され、そのうちの第一のデバイス（例えば図１の４）と第二のデバイス（例えば図１の５）間にパスが接続されているとき、前記サービス要求部からのサービス要求に基づき、前記第一のデバイスと第二のデバイス間のパスの解放を行い、該パスが解放された前記第１のデバイス又は前記第二のデバイスと前記スイッチエンジンと接続が確立されている前記第一のデバイス又は前記第二のデバイス以外の第三の前記デバイス（例えば図１の６）間のパスを接続させることにより、パス接続の切り替えを行うことを特徴とする。
【００２１】
請求項７記載の発明によれば、三つ以上のデバイスとスイッチエンジン間の接続が確立され、そのうちの第一のデバイスと第二のデバイス間にパスが接続されているとき、第一のデバイスと第二のデバイス間のパスの解放を行い、該パスが解放された一方のデバイスと第三のデバイス間のパスを接続させることにより、パス接続の切り替えを行うことが可能となる。これにより、通話しない相手を待たせておくことにより、自由に通話相手を切り替えて通話することが可能となる。
【００２２】
請求項８に記載された発明は、請求項１記載のコンピュータと電話の統合システムにおいて、前記サービス要求部（例えば図１の１）からのサービス要求に基づき、会議を行う第一の前記デバイス（例えば図１の４）へ発信して接続し、該会議に参加する第二の前記デバイス（例えば図１の５ないし９）から前記スイッチエンジンへ着信、又は、前記スイッチエンジンから前記会議に参加する第二の前記デバイスへ発信して、前記第二のデバイスと前記スイッチエンジンとを接続し、更に前記第一のデバイスと前記第二のデバイス間のパスを接続することにより会議を行うことを特徴とする。
【００２３】
請求項８記載の発明によれば、会議を行う第一のデバイスへ発信して接続し、この会議に参加する第二のデバイスからスイッチエンジンへ着信、又は、スイッチエンジンからこの会議に参加する第二のデバイスへ発信して、会議に参加するデバイスと前記スイッチエンジンとを接続し、更に前記第一のデバイスと前記第二のデバイス間のパスを接続することにより会議を行うことが可能となる。
【００２４】
請求項９に記載された発明は、交換制御を行うスイッチエンジンと前記スイッチエンジンに対して電話交換サービスを要求するサービス要求部とのインターフェース機能を有するサービス要求処理・呼情報通知手段におけるサービス要求処理・呼情報通知プログラムを記録したコンピュータ読取可能な記録媒体であって、コンピュータを、交換制御を行うスイッチエンジンに対して電話交換サービスを要求する、サービス要求部からの要求を処理する手段と、前記スイッチエンジンに接続されたデバイスの状態情報と、前記スイッチエンジンと前記デバイス間のパス接続情報の二種類の呼情報を前記サービス要求部に通知させる手段として機能させ、前記デバイスと前記スイッチエンジン間の接続が、他の前記デバイスと前記スイッチエンジン間のパスの接続がなくとも、単独で確立し、前記サービス要求部からのサービス要求に基づき、前記スイッチエンジンと接続が確立している前記デバイスを単位としてサービスを行うようにしたサービス要求処理・呼情報通知プログラムを格納した記録媒体である。
【００２５】
請求項９記載の発明によれば、サービス要求部からの要求を処理する手段と、前記スイッチエンジンに接続されたデバイスの状態情報と、前記スイッチエンジンと前記デバイス間のパス接続情報の二種類の呼情報を前記サービス要求部に通知する手段とを有するプログラムを格納した記録媒体をコンピュータ等に搭載することにより、交換機能をコンピュータ上等で実現することができる。
また、請求項９記載の発明によれば、サービス要求処理・呼情報通知手段における呼情報の管理を、デバイス単位の制御を可能とするデバイスの状態情報と前記スイッチエンジンとデバイス間のパス接続情報の二つの情報により行うことにより、サービス要求部からの要求により、呼の制御する場合に、パス接続状態と独立してデバイス単位の制御を行うことができる。
また、請求項９記載の発明によれば、デバイスとスイッチエンジン間の接続が、他の前記デバイスと前記スイッチエンジン間のパスの接続がなくとも単独で確立することが可能となり、前記スイッチエンジンと接続が確立している前記デバイスを単位としてサービスを行うことができるようになり、トーキー装置の駆動のような一方的な接続が可能となる。
【００２６】
請求項１０に記載された発明は、請求項９記載のプログラムを格納した記録媒体において、前記サービス要求部からの要求を処理する手段は、前記デバイスの発信手段と、前記スイッチエンジンと前記デバイス間の接続の解放手段と、二つの前記デバイス間のパスの接続手段と、二つの前記デバイス間のパスの解放手段と、を有することを特徴とする。
【００２７】
請求項１０記載の発明によれば、前記サービス要求部からの要求を処理する手段として、前記デバイスの発信手段と、前記スイッチエンジンと前記デバイス間の接続の解放手段と、二つの前記デバイス間のパスの接続手段と、二つの前記デバイス間のパスの解放手段の四つの手段により、サービス要求部からの要求を全て処理できるプログラムを格納した記録媒体を提供することができる。
【００２８】
請求項１１に記載された交換制御装置に関する発明は、交換制御を行うスイッチエンジンと、前記スイッチエンジンに対して電話交換サービスを要求するサービス要求部と、前記スイッチエンジンと前記サービス要求部とのインターフェース機能を有するサービス要求処理・呼情報通知手段とを有し、前記サービス要求処理・呼情報通知手段は、前記サービス要求部から前記スイッチエンジンに対する交換サービスの要求及び前記スイッチエンジンから前記サービス要求部に対する前記スイッチエンジンと前記スイッチエンジンに接続されたデバイスに係る呼情報の通知を行い、前記呼情報は、前記デバイスの状態情報と、前記スイッチエンジンと前記デバイス間のパス接続情報の二種類であることを特徴とする。
【００２９】
請求項１１記載の発明によれば、請求項１ないし８項記載のコンピュータと統合されたシステムに用いられる交換制御装置が実現できる。
【００３０】
【発明の実施の形態】
［基本構成図について］
次に、本発明の実施の形態について図面と共に説明する。図１は、本発明の基本構成図である。図中、スイッチエンジン３は、交換制御を行うもの（例えば、交換機、或いは交換機能を有するコンピュータのボード上に搭載されたマイクロプロセッサ等）である。コンピュータと電話の統合システムのための、コンピュータに搭載されたアプリケーション（以下、「ＣＴＩアプリケーション」という。 ＣＴＩ：Ｃomputer Ｔelephony Ｉntegration）であるサービス要求部１は、スイッチエンジン３に対して電話交換サービスを要求する。デバイス（４〜９）は、スイッチエンジン３に接続された内線電話端末・トランク等である。サービス要求処理・呼情報通知手段２は、サービス要求部（ＣＴＩアプリケーション）１からのサービスの要求をスイッチエンジン３に通知し、またスイッチエンジン３とデバイス（４〜９）間の呼情報をサービス要求部１へ通知する等を行う。サービス要求処理・呼情報通知手段２は、サービス要求部１とスイッチエンジン３間のインターフェースであって、交換サービスの要求及び呼情報の通知を行うためのＡＰＩである。呼の情報の管理は、サービス要求処理・呼情報通知手段（ＡＰＩ）が行い、その管理の元にスイッチエンジン３が呼情報をサービス要求部（ＣＴＩアプリケーション）に通知する。
【００３１】
この図１の構成図により、サービス要求部１は、スイッチエンジン３を制御して、任意の交換サービスを得ることができる。例えば、デバイス４から、デバイス（５〜９）への同報通信等を行わせることができる。
本発明では、サービス要求部１からの、サービスの要求に対して、デバイス単位の制御を実現するために、本発明の呼制御ＡＰＩは、呼情報を「デバイスの状態情報」と「そのパス接続情報」の二つに分割して管理する。
【００３２】
［本発明のコールモデルについて］
このため、本発明の呼制御ＡＰＩでは、ＣＴＩアプリケーションが呼の状態を制御するための管理リソースつまり呼情報として、単一デバイスの通信状態を管理するパーシャルコールＰＣと、二つのパーシャルコール間のパス接続を管理するコールブリッジＣＢの二つの情報とする。図２は、図７と同じく、二つのデバイスが通話状態のときのコールモデルである。パーシャルコールＰＣは、識別子として論理的には、パーシャルコールＩＤ、物理的には、デバイスＩＤが与えられる。
【００３３】
パーシャルコールＰＣは、デバイスから発信、あるいは、デバイスへ着信したときに生成され、デバイスのコネクション（接続）が切断されたときに消滅する。ＣＴＩアプリケーションがデバイスへの制御を行う場合には、パーシャルコールＰＣに対してサービスを要求して制御を行う。パーシャルコールＰＣは、コールブリッジＣＢなしでも単独で存在でき、パスの状態とは無関係に各デバイス（例えば電話端末）に対してサービスの要求を行うことができるので、デバイス単位の制御を可能とする。
【００３４】
また、コールブリッジＣＢは、二つのデバイス（例えば電話端末）間のパスが接続されたときに生成され、パスが解放されたときに消滅し、パーシャルコールには影響を与えない。従って、デバイス（例えば電話端末）単位の制御をＣＴＩアプリケーション側の要求で行うことができる。
なお、Ｈold 状態を説明する図２０の（Ｂ）は、図２のコールモデルによるもので、デバイスＤ３は、分離されており、実際のイメージに近いモデルである。
【００３５】
［パーシャルコールについて］
ここで、パーシャルコールについて図３を用いて説明する。パーシャルコールの状態は、Ｎull 状態、Ｃonnected状態、Ｉnitiated状態、Ａlerting 状態、Ｏriginated 状態及びＦailed 状態を持つ。Ｎull 状態は、デバイス（例えば電話端末）が空きの状態である。Ｃonnected状態は、デバイス（例えば電話端末）が発信した場合では、相手先（例えば電話端末）が応答した状態であり、デバイス（例えば電話端末）が着信した場合では、相手先（例えば電話端末）に応答を返した状態である。Ｉnitiated状態は、デバイス（例えば電話端末）から呼の要求が交換機に着信した状態である。Ａlerting 状態は、デバイス（例えば電話端末）発信時に、交換機が相手先（例えば電話端末）を呼び出している状態である。Ｏriginated 状態は、交換機がデバイス（例えば電話端末）に対して発信を要求した状態である。Ｆailed 状態は、何らかの理由でデバイス（例えば電話端末）の正常な状態遷移に失敗した状態である。これらの状態は、図５の状態遷移を行う。
【００３６】
［コールブリッジについて］
コールブリッジについて図４を用いて説明する。コールブリッジ状態は、Ｂridge Ｎull 状態及びＢridge 状態を持つ。Ｂridge Ｎull 状態は、二つのパーシャルコール間にパスの接続がない状態である。Ｂridge 状態は、二つのパーシャルコール間にパス接続されている状態である。これらの状態は、図６の状態遷移を行う。
【００３７】
［本発明の呼制御ＡＰＩについて］
本発明の呼制御ＡＰＩは、上記図２のコールモデルに基づくもので、コンピュータ上のＣＴＩアプリケーションが呼制御を行う機能として、▲１▼デバイス（例えば電話端末）への発信機能、▲２▼スイッチエンジンとデバイス（例えば電話端末）間の接続の解放機能、▲３▼二つのデバイス（例えば電話端末）間のパス接続機能、▲４▼二つのデバイス（例えば電話端末）間のパス接続の解放機能の四つの機能を持つ。
【００３８】
また、本発明の呼制御ＡＰＩの呼制御を行う機能のうち、▲１▼デバイス（例えば電話端末）への発信機能は、パーシャルコールの生成、▲２▼スイッチエンジンとデバイス（例えば電話端末）間の接続の解放機能は、パーシャルコールの消滅、▲３▼二つのデバイス（例えば電話端末）間のパス接続機能は、コールブリッジの生成、▲４▼パス接続の解放機能は、コールブリッジの消滅を行い、これらで、図２のコールモデルがとりうる形態の制御を全て網羅できるので、これらの四つの機能のみで多彩な交換サービスが実現可能である。
【００３９】
［第１の実施例について］
図１０は、本発明の第１の実施例の構成図である。図中のコンピュータ５８内には、スイッチエンジン５２とＣＴＩアプリケーション（図１のサービス要求部１に相当）５０が配置され、その間の通信は、本発明の呼制御ＡＰＩ（第１図のサービス要求処理・呼情報通知手段３に相当）５１を用いる。本実施例におけるスイッチエンジン５２は、コンピュータ５８に搭載する交換機の機能をもったボード、そのボードを制御するための交換プログラムからなり、また、ＡＰＩ５１は、ＣＴＩアプリケーション５０から受け取った交換サービスの要求の処理やＣＴＩアプリケーション５０へ呼情報の通知等を行うものである。また、電話端末５６（＃１）と電話端末５７（＃２）は公衆網５３等を通してスイッチエンジン５２のトランク５４、トランク５５へ接続される。
【００４０】
ＡＰＩ５１では、本発明の呼制御ＡＰＩで提供している四つの機能（デバイスへの発信、スイッチエンジンとデバイス間の接続の解放、二つのデバイス間のパスの接続、二つのデバイス間のパスの解放）を、図１１に示すようなＣＴＩアプリケーション５０からスイッチエンジン５２へのサービス要求とスイッチエンジン５２からＣＴＩアプリケーション５０へのサービス要求成功通知で実現する。
【００４１】
図１１（Ａ）は、ＣＴＩアプリケーション５０からのスイッチエンジン５２へ、「スイッチエンジンからデバイスへ発信のサービス」をメッセージeccMakeTrunkCallReq により要求し、「スイッチエンジンからデバイスへ発信」が行われると、スイッチエンジン５２からＣＴＩアプリケーション５０へのサービス要求成功通知であるメッセージECCMakeTtrunkCallRspがスイッチエンジン５２からＣＴＩアプリケーション５０に返される。その結果、サービス完了後は、コールモデルのパーシャルコールが生成され、サービス要求前のＮull 状態からＯriginated 状態に遷移する。
【００４２】
図１１（Ｂ）は、ＣＴＩアプリケーション５０からのスイッチエンジン５２へ、「スイッチエンジン−デバイス間の接続の解放のサービス」をメッセージeccClearTrunkConnectionReqにより要求し、これに対するスイッチエンジン５２からＣＴＩアプリケーション５０へのサービス要求成功通知であるメッセージECCClearTrunkConnectionRspをスイッチエンジン５２がＣＴＩアプリケーション５０に返すことにより、「スイッチエンジン−デバイス間の接続の解放」が行われる。その結果、サービス完了後は、コールモデルのパーシャルコールが消滅し、Ｎull 状態に遷移する。
【００４３】
図１１（Ｃ）は、ＣＴＩアプリケーション５０からのスイッチエンジン５２へ、「二つのデバイス間の接続要求のサービス」をメッセージeccCreateCallBridgeReqにより要求し、これに対するスイッチエンジン５２からＣＴＩＣＴＩアプリケーション５０へのサービス要求成功通知であるメッセージECCCreateCallBridgeRspをスイッチエンジン５２がＣＴＩアプリケーション５０に返すことにより、「二つのデバイス間の接続」が行われる。その結果、コールモデルのコールブリッジが生成され、サービス要求前のＢridge Ｎull 状態からＢridge 状態に遷移する。
【００４４】
図１１（Ｄ）は、ＣＴＩアプリケーション５０からのスイッチエンジン５２へ、「パス接続の解放要求のサービス」をメッセージeccClearCallBridgeReq により要求し、これに対するスイッチエンジン５２からＣＴＩアプリケーション５０へのサービス要求成功通知であるメッセージECCClearCallBridgeRsp をスイッチエンジン５２がＣＴＩアプリケーション５０に返すことにより、「パス接続の解放」が行われる。その結果、コールモデルのコールブリッジが消滅し、サービス要求前のＢridge 状態からＢridge Ｎull 状態に遷移する。
【００４５】
図１２は、ＡＰＩ５１の呼情報通知とそのときのコールモデルの推移の関係を示した図である。図１２（Ａ）は、「デバイスからスイッチエンジンへ着信したとき」で、スイッチエンジン５２からＣＴＩアプリケーション５０へメッセージECCIncomingCallEventを通知する。そのとき、コールモデルは、パーシャルコールが生成され、呼情報通知前のＮull 状態からＩnitiated状態に遷移する。
【００４６】
図１２（Ｂ）は、「スイッチエンジンからデバイスへ発信したとき」で、スイッチエンジン５２からＣＴＩアプリケーション５０へメッセージECCOutgoingCallEventを通知する。そのとき、コールモデルは、パーシャルコールが生成され、呼情報通知前のＮull 状態からＯriginated 状態に遷移する。
図１２（Ｃ）は、「デバイスを呼び出したとき」で、スイッチエンジン５２からＣＴＩアプリケーション５０へメッセージECCDeliveredEvent を通知する。そのとき、コールモデルは、Ｏriginated 状態からＡlerting 状態に遷移する。
【００４７】
図１２（Ｄ）は、「デバイスが応答したとき」で、スイッチエンジン５２からＣＴＩアプリケーション５０へメッセージECCEstablishedEvent を通知する。そのとき、コールモデルは、Ｃonnected状態に遷移する。
図１２（Ｅ）は、「スイッチエンジンとデバイス間の接続が失敗したとき」で、スイッチエンジン５２からＣＴＩアプリケーション５０へメッセージECCFailedEventを通知する。そのとき、コールモデルは、Ｆailed 状態に遷移する。
【００４８】
図１２（Ｆ）は、「スイッチエンジンとデバイス間の接続が解放されたとき」で、スイッチエンジン５２からＣＴＩアプリケーション５０へメッセージECCTrunkConnectionClearedEventを通知する。そのとき、コールモデルは、パーシャルコールが消滅しＮull 状態に遷移する。
図１２（Ｇ）は、「二つのデバイス間のパスが接続されたとき」で、スイッチエンジン５２からＣＴＩアプリケーション５０へメッセージECCCallBridgeConnectedEvent を通知する。そのとき、コールブリッジは、Ｂridge Ｎull 状態からＢridge 状態に遷移する。また、Ｉnitiated状態のパーシャルコールは、Ｃonnected状態に遷移する。
【００４９】
図１２（Ｈ）は、「二つのデバイス間のパスが解放されたとき」で、スイッチエンジン５２からＣＴＩアプリケーション５０へメッセージECCCallBridgeDisconnectedEventを通知する。そのとき、コールブリッジは、Ｂridge 状態からＢridge Ｎull 状態に遷移する。その結果、二つのパーシャルコールが残る。
図１３及び図１４は、請求項４のスイッチエンジン５２に着信してきてデバイスとスイッチエンジンから発信したデバイス間のパスの接続に対応する例で、電話端末５６（＃１）から電話端末５７（＃２）へ電話をかけたときの、ＣＴＩアプリケーション５０とスイッチエンジン５２間のメッセージシーケンスとコールモデルの変化を示したものである。このシーケンスは、▲１▼ＣＴＩアプリケーション５０とスイッチエンジン５２間のセッションの確立（交換サービスを行うための事前準備：事象と要求の１から６）▲２▼電話端末５６（＃１）からスイッチエンジン５２への着信（電話端末１からの発呼により交換機と電話端末１とが接続：事象と要求の７から８）▲３▼スイッチエンジン５２から電話端末５７（＃２）への発信（交換機と電話端末２との接続：事象と要求の９から１３）▲４▼二つのデバイス（電話端末５６（＃１）、電話端末５７（＃２））間のパスの接続（電話端末５６（＃１）及び電話端末５７（＃２）間の回線接続：事象と要求の１４から１６）の大きく４つに分かれる。
【００５０】
▲１▼ＣＴＩアプリケーション５０とスイッチエンジン５２間のセッションの確立
事象と要求の１のメッセージeccOpenSessionReq （ＡＰＩ（５１）で定義）で、ＣＴＩアプリケーション５０がスイッチエンジン５２へセッションの開始を要求する。事象と要求の２で、スイッチエンジン５２からその要求の成功の通知が返される。事象と要求の３から６は、ＣＴＩアプリケーション５０がメッセージeccMonitorTrunkReq（ＡＰＩ（５１）で定義）で各トランク毎にトランクのモニタを要求すると、スイッチエンジン５２がメッセージECCMonitorTrunkRspを返す。その結果、スイッチエンジン５２はモニタしているデバイスに変化が起きると、その事象をＣＴＩアプリケーション５０へ通知することとなる。
【００５１】
▲２▼電話端末５６（＃１）からスイッチエンジン５２への着信
事象と要求の７のユーザが電話端末５６（＃１）から電話端末５７（＃２）へ電話をかけ、スイッチエンジン５２へ呼が着信する迄である。事象と要求の８で、トランク１（５４）からスイッチエンジン５２に呼が着信すると、スイッチエンジン５２から、ＣＴＩアプリケーションへ、メッセージECCIncomingCallEventが通知（付加情報として、パーシャルコールＰＣ１がＩnitiated状態であることをも通知）される。コールモデルでは、パーシャルコール１（ＰＣ１）が生成されＩnitiated状態になる。
【００５２】
▲３▼スイッチエンジン５２から電話端末５７（＃２）への発信
事象と要求の９のメッセージeccMakeTrunkCallReq （付加情報として、電話端末＃２の電話番号）で、ＣＴＩアプリケーション５０がスイッチエンジン５２へ、スイッチエンジン５２が電話端末５７（＃２）に対して”電話端末５７（＃２）が発信するよう”要求（トランク接続の要求）する。ＣＴＩアプリケーション５０が、事象と要求の１０で、そのトランク接続要求の成功通知を受ける。更に事象と要求の１１で、スイッチエンジン５２がトランク２（５５）を介して電話端末５７（＃２）へ発信すると、スイッチエンジン５２はメッセージECCOutgoing Event （付加情報としてパーシャルコールＰＣ２が、Ｏriginated 状態であること）をＣＴＩアプリケーション５０に通知する。このとき、コールモデルでは、パーシャルコール＃２（ＰＣ２）が生成されて、Ｏriginated 状態になる。ＣＴＩアプリケーション５０が、事象と要求の１２「電話端末５７（＃２）を呼び出し中」及び事象と要求の１３「電話端末５７（＃２）が応答」の通知を受けるとコールモデルのパーシャルコールＰＣ２の状態は、Ａlerting 状態及びＣonnected状態へ遷移する。
【００５３】
▲４▼二つのデバイス（電話端末＃１、電話端末＃２）間のパスの接続
ＣＴＩアプリケーション５０が、事象と要求の１４のメッセージeccCreateCallBridgeReq（付加情報としてパーシャルコールＰＣ１がＩnitiated状態であること及びパーシャルコールＰＣ２が、Ｃonnected状態であること）でパーシャルコールＰＣ１トランク５４（＃１））とパーシャルコールＰＣ２（トランク５５（＃２））間のパスの接続を要求する。ＣＴＩアプリケーション５０が、事象と要求の１５で該パスの接続の要求の成功通知及び事象と要求の１６でメッセージECCCallBridgeConnectedEvent （付加情報としてコールブリッジＣＢ１の生成）の通知でパーシャルコール１とパーシャルコール２の間でコールブリッジ１（ＣＢ１）が生成され、パーシャルコール１の状態がＣonnected状態へ遷移し、電話端末５６（＃１）と電話端末５７（＃２）の通話が可能となる。
【００５４】
［本発明のサービスの例について］
この実施例においては、一のデバイス５６からスイッチエンジン５２へ着信したとき、サービス要求部であるＣＴＩアプリケーション５０からのサービス要求に基づき、スイッチエンジン５２から通話相手のデバイス５７へ発信して、二つのデバイス間のパスを接続させることにより、電話端末５６と電話端末５７とで通話するサービスである。この例を含めて、本発明で可能なサービスを従来例と対比させて、図２１ないし図２６に示す。
【００５５】
▲１▼例１：デバイスとスイッチエンジンの接続のみが存在
▲２▼例２：ジョイントサービス、二つのデバイスから前記スイッチエンジンへ着信したとき、
・第一デバイスからスイッチエンジンへ着信
・第二のデバイスからスイッチエンジンへ着信
・二つのデバイス間のパス接続を行う
▲３▼例３：着信−発信（図２２）
前記第１の実施例のサービスである。典型的な二者間の通話である。
【００５６】
▲４▼例４：トーキー接続（ガイダンス）（図２２）
・スイッチエンジンから第一デバイスへ発信
・第二のデバイスからスイッチエンジンへ着信
・二つのデバイス間のパス接続を行う
▲５▼例５：スイッチエンジン側による接続−発信（図２３）
・スイッチエンジンから第一デバイスへ発信
・スイッチエンジンから第二のデバイスへ発信
・二つのデバイス間のパス接続を行う
▲６▼例６：同報サービス（図２４）
・予めデバイスとスイッチエンジン間の接続が確立
・スイッチエンジンから複数のデバイスへ発信
・二つのデバイス間のパス接続を行う
▲７▼例７：コールウエイティング（図２５）
・予めデバイスとスイッチエンジン間の接続が３つ以上確立して、そのうち二つがパス接続されている
・パスの接続の解放
・パスの解放された一方のデバイスと第三のデバイス間のパス接続を行う
▲８▼例８：会議（図２６）
・会議デバイスで３者会議中に、４者目の参加
・会議デバイスと４者目のデバイスのパスの接続
［本発明の第２の実施例について］
図１５は、本発明の第２の実施例の構成図である。本構成は、サーバ８１、交換機７２、トランク（６７ないし７１）、公衆網５３、Ａ氏宅７４の電話端末７６、Ｂ氏宅７５のパーソナルコンピュータ７７（インターネット８０の端末）及び電話端末７８、Ｂ氏のオフィスの電話７９及びインターネット８０から構成されている。
【００５７】
サーバ８１は、コンピュータで、スイッチエンジン６０、スイッチエンジン６０の入・出力端子６５及び６６、呼制御ＡＰＩであるＡＰＩ６１、通信サーバ６２（本発明のサービス要求部に相当する機能を有する。）、ＷＷＷのホームページ６４を制御する機能並びにデータベース６３を制御する機能を有する。
通信サーバ６２は、ＣＴＩlink７３を介して交換機７２との間で交換機情報の通信を行い、また、スイッチエンジン６０に対するサービス要求部としての機能を有する。データベース６３は、スイッチエンジン６０、通信サーバ６２及びＷＷＷホームページ６４にからアクセスされる。交換機７２とスイッチエンジン６０間の接続の形態は、スイッチエンジン６０のトランクが交換機７２の内線に接続される形（交換機７２からすると、スイッチエンジン６０は交換機７２の内線に接続された端末に相当する。）になる。通信サーバ６２とスイッチエンジン６０間の呼制御ＡＰＩは、実施例１と同じＡＰＩを用い、通信サーバ６２と交換機７２間の呼制御ＡＰＩは、従来のＴＳＡＰＩを用いる。
【００５８】
また、Ｂ氏は、在宅勤務しており、自宅の端末７７からインターネット８０を介して、サーバ８１のホームページ６４にアクセスすることができ、サーバ８１と交換機７２のＣＴＩlink７３は、ＬＡＮ（Ｌocal Ａrea Ｎetwork）で接続され、交換機７２から通信サーバ６２への情報の通知及び通信サーバ６２から交換機７２への接続要求の際に使用する。
【００５９】
次に、この構成の動作を説明する。図１６はセッション開始要求からＢ氏のオフィスの内線に着信した呼がスイッチエンジン６０へ転送されるようになるまでの通信サーバ６２とスイッチエンジン６０間のＡＰＩのメッセージシーケンスを示したものである。このシーケンスは、▲１▼通信サーバ６２とスイッチエンジン６０間のセッションの確立▲２▼トランクのモニタの開始▲３▼トランクの接続▲４▼トランクの解放の大きく４つに分かれる。
【００６０】
▲１▼通信サーバ６２とスイッチエンジン６０間のセッションの確立
先ず、通信サーバ６２が、スイッチエンジン６０に対してセッション開始要求であるメッセージeccOpenSessionReq １０１を行う。それを受けて、スイッチエンジン６０が、セッション開始要求成功を示すメッセージECCOpenSessionRsp １０２を通信サーバ６２に送信する。これにより、通信サーバ６２とスイッチエンジン６０間のセッションが確立する。
【００６１】
▲２▼トランクのモニタの開始
通信サーバ６２は、スイッチエンジン６０に対し、スイッチエンジン６０の回線番号3010、3020のそれぞれのトランクに相当する端子（６５、６６）に対してモニタの開始を要求するモニタ開始要求メッセージeccMonitorTrunkReq１０３を行う。スイッチエンジン６０が該モニタ開始要求を受信し、トランクの監視を始めると、スイッチエンジン６０は、通信サーバ６２に、モニタ開始要求成功を示すメッセージECCMonitorTrunkRsp１０４を送信する。
【００６２】
▲３▼トランクの接続
Ｂ氏は、自宅の端末７７からインターネット８０等を通して、サーバ８１のホームページ６４にアクセスする。このとき、Ｂ氏は、自分のログイン情報を（例えば、ＩＤ番号、暗証番）入力する。ホームページ６４は、アクセスを受けると入力されたログイン情報からデータベース６３を検索し、成功したら通信サーバ６２へＢ氏のアクセスがあったことを通知する。Ｂ氏のアクセスの通知を受けた通信サーバ６２は、Ｂ氏のオフィスの内線（電話番号：501 ）に着信した呼をスイッチエンジン６０と接続している内線（電話番号：2030）へ転送するようスイッチエンジン６０に要求する。そのために、先ず、通信サーバ６２は、Ｂ氏のオフィスの内線番号(501) をデータベース６３から検索し、メッセージeccMakeTrunkCallReq １０５で、「転送サービスの特番＋Ｂ氏のオフィスの内線番号（501 ）＋スイッチエンジン６０と交換機７２が接続している内線番号（2030）」で交換機７２がトランク発信するようにスイッチエンジン６０へ要求する。スイッチエンジン６０は、トランク接続要求が成功するとメッセージECCMakeTtrunkCallRsp１０６を通信サーバ６２に通知する。次いで、スイッチエンジン６０は、トランクが発信すると、メッセージECCOutgoing Event １０７を、ダイヤル数字の送出が完了すると、メッセージECCDigitsOutDialedEvent(ＡＰＩで定義）１０８を通信サーバ６２に通知する。
【００６３】
なお、メッセージECCOutgoing Event １０７通報時に初めて、発信トランクの番号3020が付加情報として通知される。この時点で交換機７２は、スイッチエンジン６０からの転送サービスの要求を受け付け、Ｂ氏の内線に着信した呼をスイッチエンジン６０と交換機７２が接続している内線へ転送する。
▲４▼トランクの解放
交換機７２が転送サービスの機能を受け付けたので、トランクを解放する。通信サーバ６２は、メッセージECCDigitsOutDialedEvent １０８まで受信すると、発信トランクに対して、メッセージeccClearTrunkConnectionReq１０９でトランクの解放を要求する。スイッチエンジン６０は、トランクの解放が成功すると、メッセージECCClearTrunkConnectionRsp１１０を、トランクが解放されると、メッセージECCTrunkConnectionClearedEvent１１１を通信サーバ６２に通知する。これにより、トランクの解放がなされる。
【００６４】
図１７にセッション開始要求からＡ氏とＢ氏との通話までに処理される通信サーバ６２とスイッチエンジン６０間のＡＰＩのシーケンスの例を示す。このシーケンスは、▲１▼通信サーバ６２とスイッチエンジン６０間のセッションの確立▲２▼トランクのモニタの開始▲３▼トランクの接続▲４▼ダイヤルトーンの検出▲５▼コールブリッジの生成の大きく５つに分かれる。
【００６５】
▲１▼通信サーバ６２とスイッチエンジン６０間のセッションの確立
通信サーバ６２が、スイッチエンジン６０に対してセッション開始要求であるメッセージeccOpenSessionReq １１２を行う。次いで、スイッチエンジン６０が、セッション開始要求成功を示すメッセージECCOpenSessionRsp １１１３を通信サーバ６２に送信する。これにより、通信サーバ６２とスイッチエンジン６０間のセッションが確立する。
【００６６】
▲２▼トランクのモニタの開始
通信サーバ６２は、スイッチエンジン６０に対し、スイッチエンジン６０の回線番号3010、3020のそれぞれのトランクに対してモニタの開始を要求する要求モニタ開始要求メッセージeccMonitorTrunkReq１１４を行う。スイッチエンジン６０が該モニタ開始要求を受信し、トランクの監視を始めると、スイッチエンジン６０は、通信サーバ６２に、モニタ開始要求成功を示すメッセージECCMonitorTrunkRsp１１５を送信する。
【００６７】
▲３▼トランクの接続
Ａ氏（電話番号：044-777-1111）は、Ｂ氏のオフィスの交換機７２の内線（電話番号：501 ）に電話をかける。Ｂ氏がオフィスで勤務しているときには、交換機７２は内線端末に着信させる。しかし、Ｂ氏が在宅勤務しているときには、交換機７２は、転送サービスを行う。つまり、交換機７２は、内線番号501 で着信するとスイッチエンジン６０と接続している回線（実施例では、図１５の交換機７２の内線番号2030のトランク）へ転送する。スイッチエンジン６０に呼が着信すると、スイッチエンジン６０は、通信サーバ６２へメッセージECCIncomingCallEvent１１６を通知する。通信サーバ６２は、メッセージECCIncomingCallEvent１１６を受信後、交換機７２からＣＴＩlinkを通して受信番号（電話番号：501 ）を受けると、データベースから、受信数字でＢ氏の自宅の電話番号（044-779-2222）を参照し、スイッチエンジン６０に対し、メッセージeccMakeTrunkCallReq １１７でＢ氏の自宅に電話するように要求する。スイッチエンジン６０は、トランク接続要求が成功すると、メッセージECCMakeTtrunkCallRsp１１８、トランク発信するとメッセージECCOutgoing Event １１９、ダイヤル数字の送出が完了するとメッセージECCDigitsOutDialedEvent １２０を通信サーバ６２に通知する。
【００６８】
▲４▼ダイヤルトーンの検出
通信サーバ６２は、メッセージECCDigitsOutDialedEvent １２０まで受信すると発信トランクに対してメッセージeccStartToneDetectionReq（ＡＰＩで定義）１２１でトーン検出開始要求を行う。スイッチエンジン６０は、トーン検出が成功すると、メッセージECCStartToneDetectionRsp（ＡＰＩで定義）１２２を通知し、また発信トランクの呼び出しを通知するメッセージECCDeliveredEvent １２３を通信サーバ６２へ送信する。このとき、サーバ８１のホームページ６４を制御している機能が、通信サーバ６２から着信の情報と発番号の情報を受け取り、ホームページ６４にアクセスしている通信サーバ６２に対し、ホームページ６４を通してＲingingと発番号の表示を行う。Ｂ氏は自宅の電話機でスイッチエンジンからの着信に応答した後でＡ氏と通話するかどうかをＤＴＭＦ（Ｄual Ｔone Ｍulti Ｆrequency）数字を送信することで決定する。実施例では、”１”を押すことによってＡ氏と通話することをスイッチエンジンに伝える。スイッチエンジンはＤＴＭＦ信号を検出すると、メッセージECCDTMFDigitsDetectedEvent（ＡＰＩで定義）１２４を付加情報と共に通信サーバ６２に通知する。
【００６９】
▲５▼コールブリッジの生成
通信サーバ６２は、メッセージECCDTMFDigitsDetectedEvent１２４で通知されたＤＴＭＦ数字が通話することを示す”１”なので、Ａ氏からの着信トランクとＢ氏への発信トランクを接続するためにメッセージeccCreateCallBridgeReq１２５を要求する。スイッチエンジンは、コールブリッジ開始要求に成功すると、メッセージECCCreateCallBridgeRsp１２６を通知し、コールブリッジが開始される（＝二つのトランクが接続される）とそれぞれのトランクに対してメッセージECCCallBridgeConnectedEvent １２７を通知する。発信トランクに対して、メッセージECCCallBridgeConnectedEvent １２７が通知されたときに、サーバのホームページ６４を制御している機能が、通信サーバ６２から二つのトランクの接続の情報を受け取り、ホームページ６４を通して接続したいという情報の表示を行う。また、メッセージECCCallBridgeConnectedEvent １２７が通知された時点で、Ａ氏とＢ氏の間の通話が可能となる。
【００７０】
［本発明の変形例について］
また、本発明の第２の実施例に示したサービスを行う場合には、図１５の構成図で示した構成にとらわれずに、別の構成でも実施可能である。例えば、図１８に示すようにスイッチエンジン９０が図１５の交換機の機能を完全に収容することにより、スイッチエンジン９０が交換機を挟まずに、直接Ａ氏やＢ氏の自宅の電話端末７６、７８、Ｂ氏のオフィスの内線端末７９等へ接続する形態である。この場合、スイッチエンジン９０は交換機が果たしていた機能を持ち、トランクだけでなく、内線の制御等も受け持つことになる。交換機能が全てスイッチエンジンに集約されるので、第２の実施例のようなＡ氏からＢ氏のオフィス内線に電話がかかってきたとき、図１５の構成では必要だったスイッチエンジンへの転送が、図１８の構成では必要ないため、図１６のシーケンスで示されるサービスは必要がなくなる。更に、別の構成として図１９に示すように、図１８の構成とは逆に、スイッチエンジンをサーバの外に出すという実施の形態もある。図１９では、スイッチエンジンとして交換機９８を使用しているが、スイッチエンジンは交換機９８に限らず、図１８に示したスイッチエンジンをサーバとは別のコンピュータに搭載したものでもよい。この場合、通信サーバ６２とスイッチエンジン間のＡＰＩの通信が、一つのコンピュータの内でなく、ＬＡＮ等のネットワークを使用したものになる。また、交換機の機能も図１８の構成と同様に一つに集約されているので、図１６のシーケンスで示されるサービスは必要がなくなる。
【００７１】
［実施例の効果］
以上述べたように、本発明によれば、
（１）サービス要求部であるＣＴＩアプリケーションがスイッチエンジンの呼を制御する場合に、パス接続状態と独立して、デバイス単位の制御が可能となる。
【００７２】
（２）サービス要求部であるＣＴＩアプリケーションが、呼制御ＡＰＩの次の四つの機能のみで、多彩な交換サービスが可能となる。
▲１▼デバイスへの発信機能、
▲２▼スイッチエンジンとデバイス間の接続の解放機能、
▲３▼二つのデバイス間のパス接続機能、
▲４▼二つのデバイス間のパス接続の解放機能
【００７３】
【発明の効果】
上述の如く本発明によれば、次に述べる種々の効果を実現することができる。
請求項１記載の発明によれば、サービス要求処理・呼情報通知手段における呼情報の管理を、デバイス単位の制御を可能とするデバイスの状態情報と前記スイッチエンジンとデバイス間のパス接続情報の二つの情報により行うことにより、サービス要求部からの要求に対して、スイッチエンジンは、デバイス単位の制御を行うことができる。
また、請求項１記載の発明によれば、デバイスとスイッチエンジン間の接続が、他の前記デバイスと前記スイッチエンジン間のパスの接続がなくとも単独で確立することが可能となり、前記スイッチエンジンと接続が確立している前記デバイスを単位としてサービスを行うことができるようになり、トーキー装置の駆動のような一方的な接続が可能となる。
【００７５】
請求項２記載の発明によれば、二つのデバイスから前記スイッチエンジンへ着信したとき、二つのデバイス間のパスを接続させることにより、両者の通話が可能となり、具体的には、例えば、一のデバイスをページングの呼び出し者（患者）のものとし、他のデバイスをページング呼び出しされた者（ナース又は医者）のものとした場合、両者の通話が可能となる。
【００７６】
請求項４記載の発明によれば、予めスイッチエンジンから第一のデバイスへ発信して、スイッチエンジンと第一のデバイス間の接続を確立させておいて、第二のデバイスからスイッチエンジンへ着信したとき、第一のデバイスと第二のデバイス間のパスを接続させることにより、両者の通話を可能とした。具体的には、例えば、第一のデバイスをガイダンス装置とし、第二のデバイスをガイダンスを聞く者とし、これにより、ガイダンスのサービスが可能となる。
【００７７】
請求項５記載の発明によれば、スイッチエンジンから二つのデバイスへ別々に発信して、二つのデバイス間のパスを接続させることにより、両者の通話を可能とした。具体的には、例えば、在宅勤務の社員が、自宅の電話とお客の電話との通話に、これを利用することにより、課金を会社負担とすることができる。請求項６記載の発明によれば、予め同報通信する端末である第一のデバイスとスイッチエンジン間の接続を確立させておいて、一度に、同報通信を受ける複数のデバイスへ発信させ、デバイスが応答すると、その応答したデバイスに第一のデバイスからの同報情報を通知する同報サービスが可能となる。
【００７８】
請求項７記載の発明によれば、三つ以上のデバイスとスイッチエンジン間の接続が確立され、そのうちの第一のデバイスと第二のデバイス間にパスが接続されているとき、第一のデバイスと第二のデバイス間のパスの解放を行い、該パスが解放された一方のデバイスと第三のデバイス間のパスを接続させることにより、パス接続の切り替えを行うことが可能となる。これにより、通話しない相手を待たせておくことにより、自由に通話相手を切り替えて通話することが可能となる。
【００７９】
請求項８記載の発明によれば、会議を行う第一のデバイスへ発信して接続し、この会議に参加する第二のデバイスからスイッチエンジンへ着信、又は、スイッチエンジンからこの会議に参加する第二のデバイスへ発信して、会議に参加するデバイスと前記スイッチエンジンとを接続し、更に前記第一のデバイスと前記第二のデバイス間のパスを接続することにより会議を行うことが可能となる。
【００８０】
請求項９記載の発明によれば、サービス要求部からの要求を処理する手段と、前記スイッチエンジンに接続されたデバイスの状態情報と、前記スイッチエンジンと前記デバイス間のパス接続情報の二種類の呼情報を前記サービス要求部に通知する手段とを有するプログラムを格納した記録媒体をコンピュータ等に搭載することにより、交換機能をコンピュータ上等で実現することができる。
【００８１】
請求項１０記載の発明によれば、前記サービス要求部からの要求を処理する手段として、前記デバイスの発信手段と、前記スイッチエンジンと前記デバイス間の接続の解放手段と、二つの前記デバイス間のパスの接続手段と、二つの前記デバイス間のパスの解放手段の四つの手段により、サービス要求部からの要求を全て処理できるプログラムを格納した記録媒体を提供することができる。
【００８２】
請求項１１記載の発明によれば、請求項１ないし８項記載のコンピュータと統合されたシステムに用いられる交換制御装置が実現できる。
【図面の簡単な説明】
【図１】本発明の基本構成図を説明するための図である。
【図２】本発明の呼制御ＡＰＩの２者接続のコールモデルを説明するための図である。
【図３】本発明の呼制御ＡＰＩのパーシャルコール状態を説明するための図である。
【図４】本発明の呼制御ＡＰＩのコールブリッジ状態を説明するための図である。
【図５】本発明の呼制御ＡＰＩのパーシャルコール状態遷移図である。
【図６】本発明の呼制御ＡＰＩのコールブリッジ状態遷移図である。
【図７】ＴＳＡＰＩのコールモデルを説明するための図である。
【図８】ＴＳＡＰＩのコネクション状態を説明するための図である。
【図９】ＴＳＡＰＩのコネクション状態遷移図である。
【図１０】本発明の第１の実施例の構成図である。
【図１１】ＡＰＩの要求とコールモデルの遷移の関係を説明するための図である。
【図１２】ＡＰＩの呼情報通知とコールモデルの遷移の関係を説明するための図である
【図１３】第１の実施例のＡＰＩによるＣＴＩアプリケーションとスイッチエンジン間のメッセージシーケンス（その１）である。
【図１４】第１の実施例のＡＰＩによるＣＴＩアプリケーションとスイッチエンジン間のメッセージシーケンス（その２）である。
【図１５】本発明の第２の実施例の構成を説明するための図である。
【図１６】第２の実施例のＡＰＩによる通信サーバとスイッチエンジン間のメッセージシーケンス（その１）である。
【図１７】第２の実施例のＡＰＩによる通信サーバとスイッチエンジン間のメッセージシーケンス（その２）である。
【図１８】本発明の第２の実施例の別の実現手段を説明するための図（その１）である。
【図１９】本発明の第２の実施例の別の実現手段を説明するための図（その２）である。
【図２０】Ｈold 状態を説明するための図である。
【図２１】本発明によるサービスの例（その１）
【図２２】本発明によるサービスの例（その２）
【図２３】本発明によるサービスの例（その３）
【図２４】本発明によるサービスの例（その４）
【図２５】本発明によるサービスの例（その５）
【図２６】本発明によるサービスの例（その６）
【符号の説明】
１ サービス要求部
２ サービス要求処理・呼情報通知手段
３ スイッチエンジン
４〜９ コネクタ、電話端末等のデバイス
１０、１１ パーシャルコール
１２ コールブリッジ
５０ ＣＴＩアプリケーション
５１、６１ ＡＰＩ
５２、６０、９０ スイッチエンジン
５４、５５ トランク
５６、５７ 電話端末
５８ コンピュータ
【発明の属する技術分野】
本発明は、コンピュータと電話の統合システムに関し、特に、電話交換サービス要求部が、サービス要求処理・呼情報通知手段を介して交換機能を有するスイッチエンジンに対して交換制御を要求し、該スイッチエンジンが呼処理を行うコンピュータと電話の統合システムに関する。
【０００２】
【従来の技術】
従来から、パーソナルコンピュータ等のコンピュータ上で、アプリケーションが、ＡＰＩ（Ａpplication Ｐrogrammatic Ｉnterface）プログラムを使用して、交換機能を有するスイッチエンジンに対して交換制御を要求し、このスイッチエンジンが電話交換の呼処理を行う呼接続制御方式が行われている。ＡＰＩの代表的なものとして、例えば、ＴＳＡＰＩ( Ｔelephony Ｓervice ＡpplicationＰrogrammatic Ｉnterface）が挙げられる。
【０００３】
このＴＳＡＰＩでは、図７のように電話交換における「呼」をモデル化している。電話交換における接続は、デバイス３３と交換機（図示せず）が接続（コネクション３１）され、その交換機とデバイス３４が接続（コネクション３２）され、さらに、交換機において二つの接続を結ぶことにより、呼が完成され、通話が可能となる。図７は、その通話可能時の状態をモデル化しているものである。一つのコール（呼）３０には二つのコネクション３１、３２を必要とするモデルである。つまり、二者接続が呼の基本（一つのコールには二つのコネクションの存在が必要である。）である。発呼のように、一方のデバイスしか関与しない状態を表現する場合は、ダミーのデバイス及びコネクションを必要とする。このモデルで呼制御を行うと、呼の情報がデバイス３３、３４とコール３０との関係を表すコネクション３１、３２（デバイスの識別子とコールの識別子の組み合わせで識別される）で管理される。ＴＳＡＰＩは、このモデルを使用して、呼制御及び呼の管理を行っている。
【０００４】
このモデルのコネクションについて、図８を用いて説明する。コネクションの状態は、Ｎull 状態、Ｃonnected状態、Ｉnitiated状態、Ａlerting 状態、Ｆail 状態、Ｈold 状態及びＱueued 状態を持つ。Ｎull 状態は、コールとデバイスが、物理的にも論理的にも結びついていない状態である。Ｃonncted 状態は、コールとデバイスが、物理的にも論理的にも結びついている状態である。Ｃonnected状態は、デバイスが発信した場合では、相手先への発信手続きが完了した状態であり、デバイスが着信した場合では、呼び出しに応答を返した状態である。Ｉnitiated状態は、交換機がユーザーへ発信に必要な手続きを促している状態である。Ａlerting 状態は、コールがデバイスを呼び出している状態で、次の三つのモードからなる。Ｒingingモード、Ｏfferedモード及びＥntering Ｄistribution モード。Ｒingingモードは、Ｏfferedデバイス（呼を転送するデバイス等）やＤistribution デバイス（代表電話のように呼を割り振るデバイス）を除いた通常のデバイスを呼び出しているモードである。Ｏfferedモードは、コールがＯfferedデバイスに着信して、着信したコールに対し、どこに呼を転送するか等の指示を待っているモードである。Ｅntering Ｄistribution モードは、コールがＤistribution デバイスに着信したモードである。Ｆail 状態は、何らかの理由でコネクションの正常な状態遷移に失敗した状態である。Ｈold 状態は、コールとデバイスとが論理的には結びついているが、物理的には結びついていない状態である。Ｑueued 状態は、何らかの状態変化やアクションが起こるまで待機している状態である。これらの状態は、図９の状態遷移を行う。
【０００５】
【発明が解決しようとする課題】
図７のコールモデルを、Ｈold 状態に関して、図２０（Ａ）を用いて説明する。デバイスＤ１とデバイスＤ２とは通話中で、デバイスＤ１とデバイスＤ３とは、Ｄ３が保留されている状態であるとする。この場合は、デバイスＤ１とデバイスＤ２とは、Ｃonnected状態であって、コールとデバイスが、物理的にも論理的にも結びついている状態である。一方、Ｄ３は、保留されている状態（呼が回線を補足しているが、デバイスＤ３の通話回路は、該回線から切り離されている状態）であるから、呼が存在しており、コールとデバイスとが論理的には結びついている。ところが、デバイスＤ３の通話回路は回線から切り離されているから、デバイスＤ１とデバイスＤ３とは物理的には切り離されており、これらデバイス間では通信できない状態である。この場合、保留されているデバイスＤ３は、物理的には切り離されているにも係わらず、呼が存在するためにデバイスＤ３単独では、コールモデル上存在できない。
【０００６】
従来の呼情報の管理では、Ｈold 状態にみられるように、呼とデバイスが結びつけられていて、デバイスのみを切り離して管理することができず、また、二者接続が基本単位で、一者だけ存在することがモデル上不可能なため、トランクの着信又は発信の制御のようなデバイス単位の制御をアプリケーション側の要求で行うことができないという問題があった。
【０００７】
そこで、本発明では、電話交換サービス要求部であるＣＴＩアプリケーションがスイッチエンジンの呼を制御する場合に、パス接続状態と独立して、デバイス単位の制御が可能とすることを目的とする。
【０００８】
【課題を解決するための手段】
請求項１に記載された発明は、交換制御を行うスイッチエンジン（例えば図１の３）と、該スイッチエンジンに接続するデバイス（例えば図１の４ないし９）と、前記スイッチエンジンに対して電話交換サービスを要求するサービス要求部（例えば図１の１）と、前記スイッチエンジンと前記サービス要求部とのインターフェース機能を有するサービス要求処理・呼情報通知手段とを有し、前記サービス要求処理・呼情報通知手段は、前記サービス要求部から前記スイッチエンジンへの交換サービスの要求の処理及び前記スイッチエンジンから前記サービス要求部への前記スイッチエンジンと前記デバイスに係る呼情報の通知を行い、前記呼情報は、前記デバイスの状態情報と、前記スイッチエンジンと前記デバイス間のパス接続情報の二種類であり、前記デバイスと前記スイッチエンジン間の接続が、他の前記デバイスと前記スイッチエンジン間のパスの接続がなくとも、単独で確立し、前記サービス要求部からのサービス要求に基づき、前記スイッチエンジンと接続が確立している前記デバイスを単位としてサービスを行うことを特徴とする。
【０００９】
請求項１記載の発明によれば、サービス要求処理・呼情報通知手段における呼情報の管理を、デバイス単位の制御を可能とするデバイスの状態情報と前記スイッチエンジンとデバイス間のパス接続情報の二つの情報により行うことにより、サービス要求部からの要求により、呼の制御する場合に、パス接続状態と独立してデバイス単位の制御を行うことができる。
また、請求項１記載の発明は、デバイス単位の制御の具体的な内容を規定している。つまり、デバイスを単位としてサービスが行えるということは、サービス要求処理・呼情報通知手段における呼情報の管理が、デバイス単位の制御を行うことができるということの結果である。その結果、デバイスとスイッチエンジン間の接続が、他の前記デバイスと前記スイッチエンジン間のパスの接続がなくとも単独で確立することが可能となり、前記スイッチエンジンと接続が確立している前記デバイスを単位としてサービスを行うことができるようになり、トーキー装置の駆動のような一方的な接続が可能となる。
【００１２】
請求項２に記載された発明は、請求項１記載のコンピュータと電話の統合システムにおいて、二つの前記デバイスから前記スイッチエンジンへ着信したとき、前記サービス要求部からのサービス要求に基づき、前記二つのデバイス間のパスを接続させることにより、前記スイッチエンジンへ着信してきた前記二つのデバイス間のパス接続を行うことを特徴とする。
【００１３】
請求項２記載の発明によれば、二つのデバイスから前記スイッチエンジンへ着信したとき、二つのデバイス間のパスを接続させることにより、両者の通話が可能となる。具体的には、例えば、一のデバイスをページング呼び出し者（患者）のデバイスとし、他のデバイスをページングにより呼び出された者（ナース又は医者）のデバイスとした場合、の両者の通話が可能となる。
【００１４】
請求項３に記載された発明は、請求項１記載のコンピュータと電話の統合システムにおいて、前記デバイス（例えば図１の４）から前記スイッチエンジン（例えば図１の３）へ着信したとき、前記サービス要求部（例えば図１の１）からのサービス要求に基づき、前記スイッチエンジンから別のデバイス（例えば図１の５）へ発信して、二つのデバイス間のパスを接続させることにより、前記スイッチエンジンへ着信してきたデバイス（例えば図１の４）と前記スイッチエンジンから発信した前記デバイス（例えば図１の５）間のパス接続を行うことを特徴とする。
【００１５】
請求項３記載の発明は、本コンピュータと電話の統合システムの典型的な実施の形態を規定するもので、あるデバイス（例えば図１の４）が他のデバイス（例えば図１の５）に通話のためにダイヤルした場合である。つまり、あるデバイス（例えば図１の４）が他のデバイス（例えば図１の５）にダイヤルすると、その呼がスイッチエンジン（例えば図１の３）に着信する。次いで、スイッチエンジンが相手先の（他の）デバイス（例えば図１の５）へ発信して、相手先のデバイス（例えば図１の５）を呼び出す。相手先のデバイス（例えば図１の５）が応答すると、スイッチエンジンがこれら二つのデバイス間を接続させることにより、通話することができる。
【００１６】
請求項４に記載された発明は、請求項１記載のコンピュータと電話の統合システムにおいて、予め前記スイッチエンジン（例えば図１の３）から第一の前記デバイス（例えば図１の４）へ発信して、前記スイッチエンジンと前記第一のデバイス間の接続を確立させておいて、第二の前記デバイス（例えば図１の４ないし９）から前記スイッチエンジンへ着信したとき、前記サービス要求部（例えば図１の１）からのサービス要求に基づき、前記第一のデバイスと前記第二のデバイス間のパスの接続させることにより、前記第一のデバイスと前記第二のデバイス間のパスの接続を行うことを特徴とする。
【００１７】
請求項４記載の発明は、予めスイッチエンジンから第一のデバイスへ発信して、スイッチエンジンと第一のデバイス間の接続を確立させておいて、第二のデバイスからスイッチエンジンへ着信したとき、第一のデバイスと第二のデバイス間のパスを接続させることにより、両者の通話を可能とした。具体的には、例えば、第一のデバイスをガイダンス装置とし、第二のデバイスをガイダンスを聞く者とし、これにより、ガイダンスのサービスが可能となる。
【００１８】
請求項５に記載された発明は、請求項１記載のコンピュータと電話の統合システムにおいて、前記サービス要求部（例えば図１の１）からのサービス要求に基づき、前記スイッチエンジン（例えば図１の３）から二つの前記デバイス（例えば図１の４と５）へ別々に発信して、二つの前記デバイス間のパスの接続を行うことを特徴とする。
【００１９】
請求項５記載の発明によれば、スイッチエンジンから二つのデバイスへ別々に発信して、二つのデバイス間のパスを接続させることにより、両者の通話を可能とした。具体的には、例えば、在宅勤務の社員が、自宅の電話とお客の電話との通話に、これを利用することにより、課金を会社負担とすることができる。請求項６に記載された発明は、請求項１記載のコンピュータと電話の統合システムにおいて、予め第一の前記デバイス（例えば図１の４）と前記スイッチエンジン（例えば図１の３）間の接続を確立させておいて、前記サービス要求部（例えば図１の１）からのサービス要求に基づき、一度に複数の前記デバイス（例えば図１の５ないし９）へ発信させて、該デバイスが応答すると、前記第一のデバイスと応答した前記デバイス間のパスを接続させることにより、同報サービスを行うことを特徴とする。
【００２０】
請求項６記載の発明によれば、予め同報通信する端末である第一のデバイスとスイッチエンジン間の接続を確立させておいて、一度に、同報通信を受ける複数のデバイスへ発信させ、デバイスが応答すると、その応答したデバイスに第一のデバイスからの同報情報を通知する同報サービスが可能となる。請求項７に記載された発明は、請求項１記載のコンピュータと電話の統合システムにおいて、三つ以上の前記デバイス（例えば図１の４ないし９）と前記スイッチエンジン間の接続が確立され、そのうちの第一のデバイス（例えば図１の４）と第二のデバイス（例えば図１の５）間にパスが接続されているとき、前記サービス要求部からのサービス要求に基づき、前記第一のデバイスと第二のデバイス間のパスの解放を行い、該パスが解放された前記第１のデバイス又は前記第二のデバイスと前記スイッチエンジンと接続が確立されている前記第一のデバイス又は前記第二のデバイス以外の第三の前記デバイス（例えば図１の６）間のパスを接続させることにより、パス接続の切り替えを行うことを特徴とする。
【００２１】
請求項７記載の発明によれば、三つ以上のデバイスとスイッチエンジン間の接続が確立され、そのうちの第一のデバイスと第二のデバイス間にパスが接続されているとき、第一のデバイスと第二のデバイス間のパスの解放を行い、該パスが解放された一方のデバイスと第三のデバイス間のパスを接続させることにより、パス接続の切り替えを行うことが可能となる。これにより、通話しない相手を待たせておくことにより、自由に通話相手を切り替えて通話することが可能となる。
【００２２】
請求項８に記載された発明は、請求項１記載のコンピュータと電話の統合システムにおいて、前記サービス要求部（例えば図１の１）からのサービス要求に基づき、会議を行う第一の前記デバイス（例えば図１の４）へ発信して接続し、該会議に参加する第二の前記デバイス（例えば図１の５ないし９）から前記スイッチエンジンへ着信、又は、前記スイッチエンジンから前記会議に参加する第二の前記デバイスへ発信して、前記第二のデバイスと前記スイッチエンジンとを接続し、更に前記第一のデバイスと前記第二のデバイス間のパスを接続することにより会議を行うことを特徴とする。
【００２３】
請求項８記載の発明によれば、会議を行う第一のデバイスへ発信して接続し、この会議に参加する第二のデバイスからスイッチエンジンへ着信、又は、スイッチエンジンからこの会議に参加する第二のデバイスへ発信して、会議に参加するデバイスと前記スイッチエンジンとを接続し、更に前記第一のデバイスと前記第二のデバイス間のパスを接続することにより会議を行うことが可能となる。
【００２４】
請求項９に記載された発明は、交換制御を行うスイッチエンジンと前記スイッチエンジンに対して電話交換サービスを要求するサービス要求部とのインターフェース機能を有するサービス要求処理・呼情報通知手段におけるサービス要求処理・呼情報通知プログラムを記録したコンピュータ読取可能な記録媒体であって、コンピュータを、交換制御を行うスイッチエンジンに対して電話交換サービスを要求する、サービス要求部からの要求を処理する手段と、前記スイッチエンジンに接続されたデバイスの状態情報と、前記スイッチエンジンと前記デバイス間のパス接続情報の二種類の呼情報を前記サービス要求部に通知させる手段として機能させ、前記デバイスと前記スイッチエンジン間の接続が、他の前記デバイスと前記スイッチエンジン間のパスの接続がなくとも、単独で確立し、前記サービス要求部からのサービス要求に基づき、前記スイッチエンジンと接続が確立している前記デバイスを単位としてサービスを行うようにしたサービス要求処理・呼情報通知プログラムを格納した記録媒体である。
【００２５】
請求項９記載の発明によれば、サービス要求部からの要求を処理する手段と、前記スイッチエンジンに接続されたデバイスの状態情報と、前記スイッチエンジンと前記デバイス間のパス接続情報の二種類の呼情報を前記サービス要求部に通知する手段とを有するプログラムを格納した記録媒体をコンピュータ等に搭載することにより、交換機能をコンピュータ上等で実現することができる。
また、請求項９記載の発明によれば、サービス要求処理・呼情報通知手段における呼情報の管理を、デバイス単位の制御を可能とするデバイスの状態情報と前記スイッチエンジンとデバイス間のパス接続情報の二つの情報により行うことにより、サービス要求部からの要求により、呼の制御する場合に、パス接続状態と独立してデバイス単位の制御を行うことができる。
また、請求項９記載の発明によれば、デバイスとスイッチエンジン間の接続が、他の前記デバイスと前記スイッチエンジン間のパスの接続がなくとも単独で確立することが可能となり、前記スイッチエンジンと接続が確立している前記デバイスを単位としてサービスを行うことができるようになり、トーキー装置の駆動のような一方的な接続が可能となる。
【００２６】
請求項１０に記載された発明は、請求項９記載のプログラムを格納した記録媒体において、前記サービス要求部からの要求を処理する手段は、前記デバイスの発信手段と、前記スイッチエンジンと前記デバイス間の接続の解放手段と、二つの前記デバイス間のパスの接続手段と、二つの前記デバイス間のパスの解放手段と、を有することを特徴とする。
【００２７】
請求項１０記載の発明によれば、前記サービス要求部からの要求を処理する手段として、前記デバイスの発信手段と、前記スイッチエンジンと前記デバイス間の接続の解放手段と、二つの前記デバイス間のパスの接続手段と、二つの前記デバイス間のパスの解放手段の四つの手段により、サービス要求部からの要求を全て処理できるプログラムを格納した記録媒体を提供することができる。
【００２８】
請求項１１に記載された交換制御装置に関する発明は、交換制御を行うスイッチエンジンと、前記スイッチエンジンに対して電話交換サービスを要求するサービス要求部と、前記スイッチエンジンと前記サービス要求部とのインターフェース機能を有するサービス要求処理・呼情報通知手段とを有し、前記サービス要求処理・呼情報通知手段は、前記サービス要求部から前記スイッチエンジンに対する交換サービスの要求及び前記スイッチエンジンから前記サービス要求部に対する前記スイッチエンジンと前記スイッチエンジンに接続されたデバイスに係る呼情報の通知を行い、前記呼情報は、前記デバイスの状態情報と、前記スイッチエンジンと前記デバイス間のパス接続情報の二種類であることを特徴とする。
【００２９】
請求項１１記載の発明によれば、請求項１ないし８項記載のコンピュータと統合されたシステムに用いられる交換制御装置が実現できる。
【００３０】
【発明の実施の形態】
［基本構成図について］
次に、本発明の実施の形態について図面と共に説明する。図１は、本発明の基本構成図である。図中、スイッチエンジン３は、交換制御を行うもの（例えば、交換機、或いは交換機能を有するコンピュータのボード上に搭載されたマイクロプロセッサ等）である。コンピュータと電話の統合システムのための、コンピュータに搭載されたアプリケーション（以下、「ＣＴＩアプリケーション」という。 ＣＴＩ：Ｃomputer Ｔelephony Ｉntegration）であるサービス要求部１は、スイッチエンジン３に対して電話交換サービスを要求する。デバイス（４〜９）は、スイッチエンジン３に接続された内線電話端末・トランク等である。サービス要求処理・呼情報通知手段２は、サービス要求部（ＣＴＩアプリケーション）１からのサービスの要求をスイッチエンジン３に通知し、またスイッチエンジン３とデバイス（４〜９）間の呼情報をサービス要求部１へ通知する等を行う。サービス要求処理・呼情報通知手段２は、サービス要求部１とスイッチエンジン３間のインターフェースであって、交換サービスの要求及び呼情報の通知を行うためのＡＰＩである。呼の情報の管理は、サービス要求処理・呼情報通知手段（ＡＰＩ）が行い、その管理の元にスイッチエンジン３が呼情報をサービス要求部（ＣＴＩアプリケーション）に通知する。
【００３１】
この図１の構成図により、サービス要求部１は、スイッチエンジン３を制御して、任意の交換サービスを得ることができる。例えば、デバイス４から、デバイス（５〜９）への同報通信等を行わせることができる。
本発明では、サービス要求部１からの、サービスの要求に対して、デバイス単位の制御を実現するために、本発明の呼制御ＡＰＩは、呼情報を「デバイスの状態情報」と「そのパス接続情報」の二つに分割して管理する。
【００３２】
［本発明のコールモデルについて］
このため、本発明の呼制御ＡＰＩでは、ＣＴＩアプリケーションが呼の状態を制御するための管理リソースつまり呼情報として、単一デバイスの通信状態を管理するパーシャルコールＰＣと、二つのパーシャルコール間のパス接続を管理するコールブリッジＣＢの二つの情報とする。図２は、図７と同じく、二つのデバイスが通話状態のときのコールモデルである。パーシャルコールＰＣは、識別子として論理的には、パーシャルコールＩＤ、物理的には、デバイスＩＤが与えられる。
【００３３】
パーシャルコールＰＣは、デバイスから発信、あるいは、デバイスへ着信したときに生成され、デバイスのコネクション（接続）が切断されたときに消滅する。ＣＴＩアプリケーションがデバイスへの制御を行う場合には、パーシャルコールＰＣに対してサービスを要求して制御を行う。パーシャルコールＰＣは、コールブリッジＣＢなしでも単独で存在でき、パスの状態とは無関係に各デバイス（例えば電話端末）に対してサービスの要求を行うことができるので、デバイス単位の制御を可能とする。
【００３４】
また、コールブリッジＣＢは、二つのデバイス（例えば電話端末）間のパスが接続されたときに生成され、パスが解放されたときに消滅し、パーシャルコールには影響を与えない。従って、デバイス（例えば電話端末）単位の制御をＣＴＩアプリケーション側の要求で行うことができる。
なお、Ｈold 状態を説明する図２０の（Ｂ）は、図２のコールモデルによるもので、デバイスＤ３は、分離されており、実際のイメージに近いモデルである。
【００３５】
［パーシャルコールについて］
ここで、パーシャルコールについて図３を用いて説明する。パーシャルコールの状態は、Ｎull 状態、Ｃonnected状態、Ｉnitiated状態、Ａlerting 状態、Ｏriginated 状態及びＦailed 状態を持つ。Ｎull 状態は、デバイス（例えば電話端末）が空きの状態である。Ｃonnected状態は、デバイス（例えば電話端末）が発信した場合では、相手先（例えば電話端末）が応答した状態であり、デバイス（例えば電話端末）が着信した場合では、相手先（例えば電話端末）に応答を返した状態である。Ｉnitiated状態は、デバイス（例えば電話端末）から呼の要求が交換機に着信した状態である。Ａlerting 状態は、デバイス（例えば電話端末）発信時に、交換機が相手先（例えば電話端末）を呼び出している状態である。Ｏriginated 状態は、交換機がデバイス（例えば電話端末）に対して発信を要求した状態である。Ｆailed 状態は、何らかの理由でデバイス（例えば電話端末）の正常な状態遷移に失敗した状態である。これらの状態は、図５の状態遷移を行う。
【００３６】
［コールブリッジについて］
コールブリッジについて図４を用いて説明する。コールブリッジ状態は、Ｂridge Ｎull 状態及びＢridge 状態を持つ。Ｂridge Ｎull 状態は、二つのパーシャルコール間にパスの接続がない状態である。Ｂridge 状態は、二つのパーシャルコール間にパス接続されている状態である。これらの状態は、図６の状態遷移を行う。
【００３７】
［本発明の呼制御ＡＰＩについて］
本発明の呼制御ＡＰＩは、上記図２のコールモデルに基づくもので、コンピュータ上のＣＴＩアプリケーションが呼制御を行う機能として、▲１▼デバイス（例えば電話端末）への発信機能、▲２▼スイッチエンジンとデバイス（例えば電話端末）間の接続の解放機能、▲３▼二つのデバイス（例えば電話端末）間のパス接続機能、▲４▼二つのデバイス（例えば電話端末）間のパス接続の解放機能の四つの機能を持つ。
【００３８】
また、本発明の呼制御ＡＰＩの呼制御を行う機能のうち、▲１▼デバイス（例えば電話端末）への発信機能は、パーシャルコールの生成、▲２▼スイッチエンジンとデバイス（例えば電話端末）間の接続の解放機能は、パーシャルコールの消滅、▲３▼二つのデバイス（例えば電話端末）間のパス接続機能は、コールブリッジの生成、▲４▼パス接続の解放機能は、コールブリッジの消滅を行い、これらで、図２のコールモデルがとりうる形態の制御を全て網羅できるので、これらの四つの機能のみで多彩な交換サービスが実現可能である。
【００３９】
［第１の実施例について］
図１０は、本発明の第１の実施例の構成図である。図中のコンピュータ５８内には、スイッチエンジン５２とＣＴＩアプリケーション（図１のサービス要求部１に相当）５０が配置され、その間の通信は、本発明の呼制御ＡＰＩ（第１図のサービス要求処理・呼情報通知手段３に相当）５１を用いる。本実施例におけるスイッチエンジン５２は、コンピュータ５８に搭載する交換機の機能をもったボード、そのボードを制御するための交換プログラムからなり、また、ＡＰＩ５１は、ＣＴＩアプリケーション５０から受け取った交換サービスの要求の処理やＣＴＩアプリケーション５０へ呼情報の通知等を行うものである。また、電話端末５６（＃１）と電話端末５７（＃２）は公衆網５３等を通してスイッチエンジン５２のトランク５４、トランク５５へ接続される。
【００４０】
ＡＰＩ５１では、本発明の呼制御ＡＰＩで提供している四つの機能（デバイスへの発信、スイッチエンジンとデバイス間の接続の解放、二つのデバイス間のパスの接続、二つのデバイス間のパスの解放）を、図１１に示すようなＣＴＩアプリケーション５０からスイッチエンジン５２へのサービス要求とスイッチエンジン５２からＣＴＩアプリケーション５０へのサービス要求成功通知で実現する。
【００４１】
図１１（Ａ）は、ＣＴＩアプリケーション５０からのスイッチエンジン５２へ、「スイッチエンジンからデバイスへ発信のサービス」をメッセージeccMakeTrunkCallReq により要求し、「スイッチエンジンからデバイスへ発信」が行われると、スイッチエンジン５２からＣＴＩアプリケーション５０へのサービス要求成功通知であるメッセージECCMakeTtrunkCallRspがスイッチエンジン５２からＣＴＩアプリケーション５０に返される。その結果、サービス完了後は、コールモデルのパーシャルコールが生成され、サービス要求前のＮull 状態からＯriginated 状態に遷移する。
【００４２】
図１１（Ｂ）は、ＣＴＩアプリケーション５０からのスイッチエンジン５２へ、「スイッチエンジン−デバイス間の接続の解放のサービス」をメッセージeccClearTrunkConnectionReqにより要求し、これに対するスイッチエンジン５２からＣＴＩアプリケーション５０へのサービス要求成功通知であるメッセージECCClearTrunkConnectionRspをスイッチエンジン５２がＣＴＩアプリケーション５０に返すことにより、「スイッチエンジン−デバイス間の接続の解放」が行われる。その結果、サービス完了後は、コールモデルのパーシャルコールが消滅し、Ｎull 状態に遷移する。
【００４３】
図１１（Ｃ）は、ＣＴＩアプリケーション５０からのスイッチエンジン５２へ、「二つのデバイス間の接続要求のサービス」をメッセージeccCreateCallBridgeReqにより要求し、これに対するスイッチエンジン５２からＣＴＩＣＴＩアプリケーション５０へのサービス要求成功通知であるメッセージECCCreateCallBridgeRspをスイッチエンジン５２がＣＴＩアプリケーション５０に返すことにより、「二つのデバイス間の接続」が行われる。その結果、コールモデルのコールブリッジが生成され、サービス要求前のＢridge Ｎull 状態からＢridge 状態に遷移する。
【００４４】
図１１（Ｄ）は、ＣＴＩアプリケーション５０からのスイッチエンジン５２へ、「パス接続の解放要求のサービス」をメッセージeccClearCallBridgeReq により要求し、これに対するスイッチエンジン５２からＣＴＩアプリケーション５０へのサービス要求成功通知であるメッセージECCClearCallBridgeRsp をスイッチエンジン５２がＣＴＩアプリケーション５０に返すことにより、「パス接続の解放」が行われる。その結果、コールモデルのコールブリッジが消滅し、サービス要求前のＢridge 状態からＢridge Ｎull 状態に遷移する。
【００４５】
図１２は、ＡＰＩ５１の呼情報通知とそのときのコールモデルの推移の関係を示した図である。図１２（Ａ）は、「デバイスからスイッチエンジンへ着信したとき」で、スイッチエンジン５２からＣＴＩアプリケーション５０へメッセージECCIncomingCallEventを通知する。そのとき、コールモデルは、パーシャルコールが生成され、呼情報通知前のＮull 状態からＩnitiated状態に遷移する。
【００４６】
図１２（Ｂ）は、「スイッチエンジンからデバイスへ発信したとき」で、スイッチエンジン５２からＣＴＩアプリケーション５０へメッセージECCOutgoingCallEventを通知する。そのとき、コールモデルは、パーシャルコールが生成され、呼情報通知前のＮull 状態からＯriginated 状態に遷移する。
図１２（Ｃ）は、「デバイスを呼び出したとき」で、スイッチエンジン５２からＣＴＩアプリケーション５０へメッセージECCDeliveredEvent を通知する。そのとき、コールモデルは、Ｏriginated 状態からＡlerting 状態に遷移する。
【００４７】
図１２（Ｄ）は、「デバイスが応答したとき」で、スイッチエンジン５２からＣＴＩアプリケーション５０へメッセージECCEstablishedEvent を通知する。そのとき、コールモデルは、Ｃonnected状態に遷移する。
図１２（Ｅ）は、「スイッチエンジンとデバイス間の接続が失敗したとき」で、スイッチエンジン５２からＣＴＩアプリケーション５０へメッセージECCFailedEventを通知する。そのとき、コールモデルは、Ｆailed 状態に遷移する。
【００４８】
図１２（Ｆ）は、「スイッチエンジンとデバイス間の接続が解放されたとき」で、スイッチエンジン５２からＣＴＩアプリケーション５０へメッセージECCTrunkConnectionClearedEventを通知する。そのとき、コールモデルは、パーシャルコールが消滅しＮull 状態に遷移する。
図１２（Ｇ）は、「二つのデバイス間のパスが接続されたとき」で、スイッチエンジン５２からＣＴＩアプリケーション５０へメッセージECCCallBridgeConnectedEvent を通知する。そのとき、コールブリッジは、Ｂridge Ｎull 状態からＢridge 状態に遷移する。また、Ｉnitiated状態のパーシャルコールは、Ｃonnected状態に遷移する。
【００４９】
図１２（Ｈ）は、「二つのデバイス間のパスが解放されたとき」で、スイッチエンジン５２からＣＴＩアプリケーション５０へメッセージECCCallBridgeDisconnectedEventを通知する。そのとき、コールブリッジは、Ｂridge 状態からＢridge Ｎull 状態に遷移する。その結果、二つのパーシャルコールが残る。
図１３及び図１４は、請求項４のスイッチエンジン５２に着信してきてデバイスとスイッチエンジンから発信したデバイス間のパスの接続に対応する例で、電話端末５６（＃１）から電話端末５７（＃２）へ電話をかけたときの、ＣＴＩアプリケーション５０とスイッチエンジン５２間のメッセージシーケンスとコールモデルの変化を示したものである。このシーケンスは、▲１▼ＣＴＩアプリケーション５０とスイッチエンジン５２間のセッションの確立（交換サービスを行うための事前準備：事象と要求の１から６）▲２▼電話端末５６（＃１）からスイッチエンジン５２への着信（電話端末１からの発呼により交換機と電話端末１とが接続：事象と要求の７から８）▲３▼スイッチエンジン５２から電話端末５７（＃２）への発信（交換機と電話端末２との接続：事象と要求の９から１３）▲４▼二つのデバイス（電話端末５６（＃１）、電話端末５７（＃２））間のパスの接続（電話端末５６（＃１）及び電話端末５７（＃２）間の回線接続：事象と要求の１４から１６）の大きく４つに分かれる。
【００５０】
▲１▼ＣＴＩアプリケーション５０とスイッチエンジン５２間のセッションの確立
事象と要求の１のメッセージeccOpenSessionReq （ＡＰＩ（５１）で定義）で、ＣＴＩアプリケーション５０がスイッチエンジン５２へセッションの開始を要求する。事象と要求の２で、スイッチエンジン５２からその要求の成功の通知が返される。事象と要求の３から６は、ＣＴＩアプリケーション５０がメッセージeccMonitorTrunkReq（ＡＰＩ（５１）で定義）で各トランク毎にトランクのモニタを要求すると、スイッチエンジン５２がメッセージECCMonitorTrunkRspを返す。その結果、スイッチエンジン５２はモニタしているデバイスに変化が起きると、その事象をＣＴＩアプリケーション５０へ通知することとなる。
【００５１】
▲２▼電話端末５６（＃１）からスイッチエンジン５２への着信
事象と要求の７のユーザが電話端末５６（＃１）から電話端末５７（＃２）へ電話をかけ、スイッチエンジン５２へ呼が着信する迄である。事象と要求の８で、トランク１（５４）からスイッチエンジン５２に呼が着信すると、スイッチエンジン５２から、ＣＴＩアプリケーションへ、メッセージECCIncomingCallEventが通知（付加情報として、パーシャルコールＰＣ１がＩnitiated状態であることをも通知）される。コールモデルでは、パーシャルコール１（ＰＣ１）が生成されＩnitiated状態になる。
【００５２】
▲３▼スイッチエンジン５２から電話端末５７（＃２）への発信
事象と要求の９のメッセージeccMakeTrunkCallReq （付加情報として、電話端末＃２の電話番号）で、ＣＴＩアプリケーション５０がスイッチエンジン５２へ、スイッチエンジン５２が電話端末５７（＃２）に対して”電話端末５７（＃２）が発信するよう”要求（トランク接続の要求）する。ＣＴＩアプリケーション５０が、事象と要求の１０で、そのトランク接続要求の成功通知を受ける。更に事象と要求の１１で、スイッチエンジン５２がトランク２（５５）を介して電話端末５７（＃２）へ発信すると、スイッチエンジン５２はメッセージECCOutgoing Event （付加情報としてパーシャルコールＰＣ２が、Ｏriginated 状態であること）をＣＴＩアプリケーション５０に通知する。このとき、コールモデルでは、パーシャルコール＃２（ＰＣ２）が生成されて、Ｏriginated 状態になる。ＣＴＩアプリケーション５０が、事象と要求の１２「電話端末５７（＃２）を呼び出し中」及び事象と要求の１３「電話端末５７（＃２）が応答」の通知を受けるとコールモデルのパーシャルコールＰＣ２の状態は、Ａlerting 状態及びＣonnected状態へ遷移する。
【００５３】
▲４▼二つのデバイス（電話端末＃１、電話端末＃２）間のパスの接続
ＣＴＩアプリケーション５０が、事象と要求の１４のメッセージeccCreateCallBridgeReq（付加情報としてパーシャルコールＰＣ１がＩnitiated状態であること及びパーシャルコールＰＣ２が、Ｃonnected状態であること）でパーシャルコールＰＣ１トランク５４（＃１））とパーシャルコールＰＣ２（トランク５５（＃２））間のパスの接続を要求する。ＣＴＩアプリケーション５０が、事象と要求の１５で該パスの接続の要求の成功通知及び事象と要求の１６でメッセージECCCallBridgeConnectedEvent （付加情報としてコールブリッジＣＢ１の生成）の通知でパーシャルコール１とパーシャルコール２の間でコールブリッジ１（ＣＢ１）が生成され、パーシャルコール１の状態がＣonnected状態へ遷移し、電話端末５６（＃１）と電話端末５７（＃２）の通話が可能となる。
【００５４】
［本発明のサービスの例について］
この実施例においては、一のデバイス５６からスイッチエンジン５２へ着信したとき、サービス要求部であるＣＴＩアプリケーション５０からのサービス要求に基づき、スイッチエンジン５２から通話相手のデバイス５７へ発信して、二つのデバイス間のパスを接続させることにより、電話端末５６と電話端末５７とで通話するサービスである。この例を含めて、本発明で可能なサービスを従来例と対比させて、図２１ないし図２６に示す。
【００５５】
▲１▼例１：デバイスとスイッチエンジンの接続のみが存在
▲２▼例２：ジョイントサービス、二つのデバイスから前記スイッチエンジンへ着信したとき、
・第一デバイスからスイッチエンジンへ着信
・第二のデバイスからスイッチエンジンへ着信
・二つのデバイス間のパス接続を行う
▲３▼例３：着信−発信（図２２）
前記第１の実施例のサービスである。典型的な二者間の通話である。
【００５６】
▲４▼例４：トーキー接続（ガイダンス）（図２２）
・スイッチエンジンから第一デバイスへ発信
・第二のデバイスからスイッチエンジンへ着信
・二つのデバイス間のパス接続を行う
▲５▼例５：スイッチエンジン側による接続−発信（図２３）
・スイッチエンジンから第一デバイスへ発信
・スイッチエンジンから第二のデバイスへ発信
・二つのデバイス間のパス接続を行う
▲６▼例６：同報サービス（図２４）
・予めデバイスとスイッチエンジン間の接続が確立
・スイッチエンジンから複数のデバイスへ発信
・二つのデバイス間のパス接続を行う
▲７▼例７：コールウエイティング（図２５）
・予めデバイスとスイッチエンジン間の接続が３つ以上確立して、そのうち二つがパス接続されている
・パスの接続の解放
・パスの解放された一方のデバイスと第三のデバイス間のパス接続を行う
▲８▼例８：会議（図２６）
・会議デバイスで３者会議中に、４者目の参加
・会議デバイスと４者目のデバイスのパスの接続
［本発明の第２の実施例について］
図１５は、本発明の第２の実施例の構成図である。本構成は、サーバ８１、交換機７２、トランク（６７ないし７１）、公衆網５３、Ａ氏宅７４の電話端末７６、Ｂ氏宅７５のパーソナルコンピュータ７７（インターネット８０の端末）及び電話端末７８、Ｂ氏のオフィスの電話７９及びインターネット８０から構成されている。
【００５７】
サーバ８１は、コンピュータで、スイッチエンジン６０、スイッチエンジン６０の入・出力端子６５及び６６、呼制御ＡＰＩであるＡＰＩ６１、通信サーバ６２（本発明のサービス要求部に相当する機能を有する。）、ＷＷＷのホームページ６４を制御する機能並びにデータベース６３を制御する機能を有する。
通信サーバ６２は、ＣＴＩlink７３を介して交換機７２との間で交換機情報の通信を行い、また、スイッチエンジン６０に対するサービス要求部としての機能を有する。データベース６３は、スイッチエンジン６０、通信サーバ６２及びＷＷＷホームページ６４にからアクセスされる。交換機７２とスイッチエンジン６０間の接続の形態は、スイッチエンジン６０のトランクが交換機７２の内線に接続される形（交換機７２からすると、スイッチエンジン６０は交換機７２の内線に接続された端末に相当する。）になる。通信サーバ６２とスイッチエンジン６０間の呼制御ＡＰＩは、実施例１と同じＡＰＩを用い、通信サーバ６２と交換機７２間の呼制御ＡＰＩは、従来のＴＳＡＰＩを用いる。
【００５８】
また、Ｂ氏は、在宅勤務しており、自宅の端末７７からインターネット８０を介して、サーバ８１のホームページ６４にアクセスすることができ、サーバ８１と交換機７２のＣＴＩlink７３は、ＬＡＮ（Ｌocal Ａrea Ｎetwork）で接続され、交換機７２から通信サーバ６２への情報の通知及び通信サーバ６２から交換機７２への接続要求の際に使用する。
【００５９】
次に、この構成の動作を説明する。図１６はセッション開始要求からＢ氏のオフィスの内線に着信した呼がスイッチエンジン６０へ転送されるようになるまでの通信サーバ６２とスイッチエンジン６０間のＡＰＩのメッセージシーケンスを示したものである。このシーケンスは、▲１▼通信サーバ６２とスイッチエンジン６０間のセッションの確立▲２▼トランクのモニタの開始▲３▼トランクの接続▲４▼トランクの解放の大きく４つに分かれる。
【００６０】
▲１▼通信サーバ６２とスイッチエンジン６０間のセッションの確立
先ず、通信サーバ６２が、スイッチエンジン６０に対してセッション開始要求であるメッセージeccOpenSessionReq １０１を行う。それを受けて、スイッチエンジン６０が、セッション開始要求成功を示すメッセージECCOpenSessionRsp １０２を通信サーバ６２に送信する。これにより、通信サーバ６２とスイッチエンジン６０間のセッションが確立する。
【００６１】
▲２▼トランクのモニタの開始
通信サーバ６２は、スイッチエンジン６０に対し、スイッチエンジン６０の回線番号3010、3020のそれぞれのトランクに相当する端子（６５、６６）に対してモニタの開始を要求するモニタ開始要求メッセージeccMonitorTrunkReq１０３を行う。スイッチエンジン６０が該モニタ開始要求を受信し、トランクの監視を始めると、スイッチエンジン６０は、通信サーバ６２に、モニタ開始要求成功を示すメッセージECCMonitorTrunkRsp１０４を送信する。
【００６２】
▲３▼トランクの接続
Ｂ氏は、自宅の端末７７からインターネット８０等を通して、サーバ８１のホームページ６４にアクセスする。このとき、Ｂ氏は、自分のログイン情報を（例えば、ＩＤ番号、暗証番）入力する。ホームページ６４は、アクセスを受けると入力されたログイン情報からデータベース６３を検索し、成功したら通信サーバ６２へＢ氏のアクセスがあったことを通知する。Ｂ氏のアクセスの通知を受けた通信サーバ６２は、Ｂ氏のオフィスの内線（電話番号：501 ）に着信した呼をスイッチエンジン６０と接続している内線（電話番号：2030）へ転送するようスイッチエンジン６０に要求する。そのために、先ず、通信サーバ６２は、Ｂ氏のオフィスの内線番号(501) をデータベース６３から検索し、メッセージeccMakeTrunkCallReq １０５で、「転送サービスの特番＋Ｂ氏のオフィスの内線番号（501 ）＋スイッチエンジン６０と交換機７２が接続している内線番号（2030）」で交換機７２がトランク発信するようにスイッチエンジン６０へ要求する。スイッチエンジン６０は、トランク接続要求が成功するとメッセージECCMakeTtrunkCallRsp１０６を通信サーバ６２に通知する。次いで、スイッチエンジン６０は、トランクが発信すると、メッセージECCOutgoing Event １０７を、ダイヤル数字の送出が完了すると、メッセージECCDigitsOutDialedEvent(ＡＰＩで定義）１０８を通信サーバ６２に通知する。
【００６３】
なお、メッセージECCOutgoing Event １０７通報時に初めて、発信トランクの番号3020が付加情報として通知される。この時点で交換機７２は、スイッチエンジン６０からの転送サービスの要求を受け付け、Ｂ氏の内線に着信した呼をスイッチエンジン６０と交換機７２が接続している内線へ転送する。
▲４▼トランクの解放
交換機７２が転送サービスの機能を受け付けたので、トランクを解放する。通信サーバ６２は、メッセージECCDigitsOutDialedEvent １０８まで受信すると、発信トランクに対して、メッセージeccClearTrunkConnectionReq１０９でトランクの解放を要求する。スイッチエンジン６０は、トランクの解放が成功すると、メッセージECCClearTrunkConnectionRsp１１０を、トランクが解放されると、メッセージECCTrunkConnectionClearedEvent１１１を通信サーバ６２に通知する。これにより、トランクの解放がなされる。
【００６４】
図１７にセッション開始要求からＡ氏とＢ氏との通話までに処理される通信サーバ６２とスイッチエンジン６０間のＡＰＩのシーケンスの例を示す。このシーケンスは、▲１▼通信サーバ６２とスイッチエンジン６０間のセッションの確立▲２▼トランクのモニタの開始▲３▼トランクの接続▲４▼ダイヤルトーンの検出▲５▼コールブリッジの生成の大きく５つに分かれる。
【００６５】
▲１▼通信サーバ６２とスイッチエンジン６０間のセッションの確立
通信サーバ６２が、スイッチエンジン６０に対してセッション開始要求であるメッセージeccOpenSessionReq １１２を行う。次いで、スイッチエンジン６０が、セッション開始要求成功を示すメッセージECCOpenSessionRsp １１１３を通信サーバ６２に送信する。これにより、通信サーバ６２とスイッチエンジン６０間のセッションが確立する。
【００６６】
▲２▼トランクのモニタの開始
通信サーバ６２は、スイッチエンジン６０に対し、スイッチエンジン６０の回線番号3010、3020のそれぞれのトランクに対してモニタの開始を要求する要求モニタ開始要求メッセージeccMonitorTrunkReq１１４を行う。スイッチエンジン６０が該モニタ開始要求を受信し、トランクの監視を始めると、スイッチエンジン６０は、通信サーバ６２に、モニタ開始要求成功を示すメッセージECCMonitorTrunkRsp１１５を送信する。
【００６７】
▲３▼トランクの接続
Ａ氏（電話番号：044-777-1111）は、Ｂ氏のオフィスの交換機７２の内線（電話番号：501 ）に電話をかける。Ｂ氏がオフィスで勤務しているときには、交換機７２は内線端末に着信させる。しかし、Ｂ氏が在宅勤務しているときには、交換機７２は、転送サービスを行う。つまり、交換機７２は、内線番号501 で着信するとスイッチエンジン６０と接続している回線（実施例では、図１５の交換機７２の内線番号2030のトランク）へ転送する。スイッチエンジン６０に呼が着信すると、スイッチエンジン６０は、通信サーバ６２へメッセージECCIncomingCallEvent１１６を通知する。通信サーバ６２は、メッセージECCIncomingCallEvent１１６を受信後、交換機７２からＣＴＩlinkを通して受信番号（電話番号：501 ）を受けると、データベースから、受信数字でＢ氏の自宅の電話番号（044-779-2222）を参照し、スイッチエンジン６０に対し、メッセージeccMakeTrunkCallReq １１７でＢ氏の自宅に電話するように要求する。スイッチエンジン６０は、トランク接続要求が成功すると、メッセージECCMakeTtrunkCallRsp１１８、トランク発信するとメッセージECCOutgoing Event １１９、ダイヤル数字の送出が完了するとメッセージECCDigitsOutDialedEvent １２０を通信サーバ６２に通知する。
【００６８】
▲４▼ダイヤルトーンの検出
通信サーバ６２は、メッセージECCDigitsOutDialedEvent １２０まで受信すると発信トランクに対してメッセージeccStartToneDetectionReq（ＡＰＩで定義）１２１でトーン検出開始要求を行う。スイッチエンジン６０は、トーン検出が成功すると、メッセージECCStartToneDetectionRsp（ＡＰＩで定義）１２２を通知し、また発信トランクの呼び出しを通知するメッセージECCDeliveredEvent １２３を通信サーバ６２へ送信する。このとき、サーバ８１のホームページ６４を制御している機能が、通信サーバ６２から着信の情報と発番号の情報を受け取り、ホームページ６４にアクセスしている通信サーバ６２に対し、ホームページ６４を通してＲingingと発番号の表示を行う。Ｂ氏は自宅の電話機でスイッチエンジンからの着信に応答した後でＡ氏と通話するかどうかをＤＴＭＦ（Ｄual Ｔone Ｍulti Ｆrequency）数字を送信することで決定する。実施例では、”１”を押すことによってＡ氏と通話することをスイッチエンジンに伝える。スイッチエンジンはＤＴＭＦ信号を検出すると、メッセージECCDTMFDigitsDetectedEvent（ＡＰＩで定義）１２４を付加情報と共に通信サーバ６２に通知する。
【００６９】
▲５▼コールブリッジの生成
通信サーバ６２は、メッセージECCDTMFDigitsDetectedEvent１２４で通知されたＤＴＭＦ数字が通話することを示す”１”なので、Ａ氏からの着信トランクとＢ氏への発信トランクを接続するためにメッセージeccCreateCallBridgeReq１２５を要求する。スイッチエンジンは、コールブリッジ開始要求に成功すると、メッセージECCCreateCallBridgeRsp１２６を通知し、コールブリッジが開始される（＝二つのトランクが接続される）とそれぞれのトランクに対してメッセージECCCallBridgeConnectedEvent １２７を通知する。発信トランクに対して、メッセージECCCallBridgeConnectedEvent １２７が通知されたときに、サーバのホームページ６４を制御している機能が、通信サーバ６２から二つのトランクの接続の情報を受け取り、ホームページ６４を通して接続したいという情報の表示を行う。また、メッセージECCCallBridgeConnectedEvent １２７が通知された時点で、Ａ氏とＢ氏の間の通話が可能となる。
【００７０】
［本発明の変形例について］
また、本発明の第２の実施例に示したサービスを行う場合には、図１５の構成図で示した構成にとらわれずに、別の構成でも実施可能である。例えば、図１８に示すようにスイッチエンジン９０が図１５の交換機の機能を完全に収容することにより、スイッチエンジン９０が交換機を挟まずに、直接Ａ氏やＢ氏の自宅の電話端末７６、７８、Ｂ氏のオフィスの内線端末７９等へ接続する形態である。この場合、スイッチエンジン９０は交換機が果たしていた機能を持ち、トランクだけでなく、内線の制御等も受け持つことになる。交換機能が全てスイッチエンジンに集約されるので、第２の実施例のようなＡ氏からＢ氏のオフィス内線に電話がかかってきたとき、図１５の構成では必要だったスイッチエンジンへの転送が、図１８の構成では必要ないため、図１６のシーケンスで示されるサービスは必要がなくなる。更に、別の構成として図１９に示すように、図１８の構成とは逆に、スイッチエンジンをサーバの外に出すという実施の形態もある。図１９では、スイッチエンジンとして交換機９８を使用しているが、スイッチエンジンは交換機９８に限らず、図１８に示したスイッチエンジンをサーバとは別のコンピュータに搭載したものでもよい。この場合、通信サーバ６２とスイッチエンジン間のＡＰＩの通信が、一つのコンピュータの内でなく、ＬＡＮ等のネットワークを使用したものになる。また、交換機の機能も図１８の構成と同様に一つに集約されているので、図１６のシーケンスで示されるサービスは必要がなくなる。
【００７１】
［実施例の効果］
以上述べたように、本発明によれば、
（１）サービス要求部であるＣＴＩアプリケーションがスイッチエンジンの呼を制御する場合に、パス接続状態と独立して、デバイス単位の制御が可能となる。
【００７２】
（２）サービス要求部であるＣＴＩアプリケーションが、呼制御ＡＰＩの次の四つの機能のみで、多彩な交換サービスが可能となる。
▲１▼デバイスへの発信機能、
▲２▼スイッチエンジンとデバイス間の接続の解放機能、
▲３▼二つのデバイス間のパス接続機能、
▲４▼二つのデバイス間のパス接続の解放機能
【００７３】
【発明の効果】
上述の如く本発明によれば、次に述べる種々の効果を実現することができる。
請求項１記載の発明によれば、サービス要求処理・呼情報通知手段における呼情報の管理を、デバイス単位の制御を可能とするデバイスの状態情報と前記スイッチエンジンとデバイス間のパス接続情報の二つの情報により行うことにより、サービス要求部からの要求に対して、スイッチエンジンは、デバイス単位の制御を行うことができる。
また、請求項１記載の発明によれば、デバイスとスイッチエンジン間の接続が、他の前記デバイスと前記スイッチエンジン間のパスの接続がなくとも単独で確立することが可能となり、前記スイッチエンジンと接続が確立している前記デバイスを単位としてサービスを行うことができるようになり、トーキー装置の駆動のような一方的な接続が可能となる。
【００７５】
請求項２記載の発明によれば、二つのデバイスから前記スイッチエンジンへ着信したとき、二つのデバイス間のパスを接続させることにより、両者の通話が可能となり、具体的には、例えば、一のデバイスをページングの呼び出し者（患者）のものとし、他のデバイスをページング呼び出しされた者（ナース又は医者）のものとした場合、両者の通話が可能となる。
【００７６】
請求項４記載の発明によれば、予めスイッチエンジンから第一のデバイスへ発信して、スイッチエンジンと第一のデバイス間の接続を確立させておいて、第二のデバイスからスイッチエンジンへ着信したとき、第一のデバイスと第二のデバイス間のパスを接続させることにより、両者の通話を可能とした。具体的には、例えば、第一のデバイスをガイダンス装置とし、第二のデバイスをガイダンスを聞く者とし、これにより、ガイダンスのサービスが可能となる。
【００７７】
請求項５記載の発明によれば、スイッチエンジンから二つのデバイスへ別々に発信して、二つのデバイス間のパスを接続させることにより、両者の通話を可能とした。具体的には、例えば、在宅勤務の社員が、自宅の電話とお客の電話との通話に、これを利用することにより、課金を会社負担とすることができる。請求項６記載の発明によれば、予め同報通信する端末である第一のデバイスとスイッチエンジン間の接続を確立させておいて、一度に、同報通信を受ける複数のデバイスへ発信させ、デバイスが応答すると、その応答したデバイスに第一のデバイスからの同報情報を通知する同報サービスが可能となる。
【００７８】
請求項７記載の発明によれば、三つ以上のデバイスとスイッチエンジン間の接続が確立され、そのうちの第一のデバイスと第二のデバイス間にパスが接続されているとき、第一のデバイスと第二のデバイス間のパスの解放を行い、該パスが解放された一方のデバイスと第三のデバイス間のパスを接続させることにより、パス接続の切り替えを行うことが可能となる。これにより、通話しない相手を待たせておくことにより、自由に通話相手を切り替えて通話することが可能となる。
【００７９】
請求項８記載の発明によれば、会議を行う第一のデバイスへ発信して接続し、この会議に参加する第二のデバイスからスイッチエンジンへ着信、又は、スイッチエンジンからこの会議に参加する第二のデバイスへ発信して、会議に参加するデバイスと前記スイッチエンジンとを接続し、更に前記第一のデバイスと前記第二のデバイス間のパスを接続することにより会議を行うことが可能となる。
【００８０】
請求項９記載の発明によれば、サービス要求部からの要求を処理する手段と、前記スイッチエンジンに接続されたデバイスの状態情報と、前記スイッチエンジンと前記デバイス間のパス接続情報の二種類の呼情報を前記サービス要求部に通知する手段とを有するプログラムを格納した記録媒体をコンピュータ等に搭載することにより、交換機能をコンピュータ上等で実現することができる。
【００８１】
請求項１０記載の発明によれば、前記サービス要求部からの要求を処理する手段として、前記デバイスの発信手段と、前記スイッチエンジンと前記デバイス間の接続の解放手段と、二つの前記デバイス間のパスの接続手段と、二つの前記デバイス間のパスの解放手段の四つの手段により、サービス要求部からの要求を全て処理できるプログラムを格納した記録媒体を提供することができる。
【００８２】
請求項１１記載の発明によれば、請求項１ないし８項記載のコンピュータと統合されたシステムに用いられる交換制御装置が実現できる。
【図面の簡単な説明】
【図１】本発明の基本構成図を説明するための図である。
【図２】本発明の呼制御ＡＰＩの２者接続のコールモデルを説明するための図である。
【図３】本発明の呼制御ＡＰＩのパーシャルコール状態を説明するための図である。
【図４】本発明の呼制御ＡＰＩのコールブリッジ状態を説明するための図である。
【図５】本発明の呼制御ＡＰＩのパーシャルコール状態遷移図である。
【図６】本発明の呼制御ＡＰＩのコールブリッジ状態遷移図である。
【図７】ＴＳＡＰＩのコールモデルを説明するための図である。
【図８】ＴＳＡＰＩのコネクション状態を説明するための図である。
【図９】ＴＳＡＰＩのコネクション状態遷移図である。
【図１０】本発明の第１の実施例の構成図である。
【図１１】ＡＰＩの要求とコールモデルの遷移の関係を説明するための図である。
【図１２】ＡＰＩの呼情報通知とコールモデルの遷移の関係を説明するための図である
【図１３】第１の実施例のＡＰＩによるＣＴＩアプリケーションとスイッチエンジン間のメッセージシーケンス（その１）である。
【図１４】第１の実施例のＡＰＩによるＣＴＩアプリケーションとスイッチエンジン間のメッセージシーケンス（その２）である。
【図１５】本発明の第２の実施例の構成を説明するための図である。
【図１６】第２の実施例のＡＰＩによる通信サーバとスイッチエンジン間のメッセージシーケンス（その１）である。
【図１７】第２の実施例のＡＰＩによる通信サーバとスイッチエンジン間のメッセージシーケンス（その２）である。
【図１８】本発明の第２の実施例の別の実現手段を説明するための図（その１）である。
【図１９】本発明の第２の実施例の別の実現手段を説明するための図（その２）である。
【図２０】Ｈold 状態を説明するための図である。
【図２１】本発明によるサービスの例（その１）
【図２２】本発明によるサービスの例（その２）
【図２３】本発明によるサービスの例（その３）
【図２４】本発明によるサービスの例（その４）
【図２５】本発明によるサービスの例（その５）
【図２６】本発明によるサービスの例（その６）
【符号の説明】
１ サービス要求部
２ サービス要求処理・呼情報通知手段
３ スイッチエンジン
４〜９ コネクタ、電話端末等のデバイス
１０、１１ パーシャルコール
１２ コールブリッジ
５０ ＣＴＩアプリケーション
５１、６１ ＡＰＩ
５２、６０、９０ スイッチエンジン
５４、５５ トランク
５６、５７ 電話端末
５８ コンピュータ
Claims (11)
- 交換制御を行うスイッチエンジンと、
該スイッチエンジンに接続するデバイスと、
前記スイッチエンジンに対して電話交換サービスを要求するサービス要求部と、
前記スイッチエンジンと前記サービス要求部とのインターフェース機能を有するサービス要求処理・呼情報通知手段とを有し、
前記サービス要求処理・呼情報通知手段は、前記サービス要求部から前記スイッチエンジンへの交換サービスの要求の処理及び前記スイッチエンジンから前記サービス要求部への前記スイッチエンジンと前記デバイスに係る呼情報の通知を行い、
前記呼情報は、前記デバイスの状態情報と、前記スイッチエンジンと前記デバイス間のパス接続情報の二種類であり、
前記デバイスと前記スイッチエンジン間の接続が、他の前記デバイスと前記スイッチエンジン間のパスの接続がなくとも、単独で確立し、
前記サービス要求部からのサービス要求に基づき、前記スイッチエンジンと接続が確立している前記デバイスを単位としてサービスを行う
ことを特徴とするコンピュータと電話の統合システム。 - 二つの前記デバイスから前記スイッチエンジンへ着信したとき、
前記サービス要求部からのサービス要求に基づき、前記二つのデバイス間のパスを接続させることにより、前記スイッチエンジンへ着信してきた前記二つのデバイス間のパス接続を行うことを特徴とする請求項１記載のコンピュータと電話の統合システム。 - 前記デバイスから前記スイッチエンジンへ着信したとき、
前記サービス要求部からのサービス要求に基づき、前記スイッチエンジンから別のデバイスへ発信して、二つのデバイス間のパスを接続させることにより、前記スイッチエンジンへ着信してきたデバイスと前記スイッチエンジンから発信した前記デバイス間のパス接続を行うことを特徴とする請求項１記載のコンピュータと電話の統合システム。 - 予め前記スイッチエンジンから第一の前記デバイスへ発信して、前記スイッチエンジンと前記第一のデバイス間の接続を確立させておいて、第二の前記デバイスから前記スイッチエンジンへ着信したとき、
前記サービス要求部からのサービス要求に基づき、前記第一のデバイスと前記第二のデバイス間のパスの接続させることにより、前記第一のデバイスと前記第二のデバイス間のパスの接続を行うことを特徴とする請求項１記載のコンピュータと電話の統合システム。 - 前記サービス要求部からのサービス要求に基づき、前記スイッチエンジンから二つの前記デバイスへ別々に発信して、二つの前記デバイス間のパスの接続を行うことを特徴とする請求項１記載のコンピュータと電話の統合システム。
- 予め第一の前記デバイスと前記スイッチエンジン間の接続を確立させておいて、
前記サービス要求部からのサービス要求に基づき、一度に複数の前記デバイスへ発信させて、該デバイスが応答すると、前記第一のデバイスと応答した前記デバイス間のパスを接続させることにより、同報サービスを行うことを特徴とする請求項１記載のコンピュータと電話の統合システム。 - 三つ以上の前記デバイスと前記スイッチエンジン間の接続が確立され、そのうちの第一のデバイスと第二のデバイス間にパスが接続されているとき、
前記サービス要求部からのサービス要求に基づき、前記第一のデバイスと第二のデバイス間のパスの解放を行い、該パスが解放された前記第１のデバイス又は前記第二のデバイスと前記スイッチエンジンと接続が確立されている前記第一のデバイス又は前記第二のデバイス以外の第三の前記デバイス間のパスを接続させることにより、パス接続の切り替えを行うことを特徴とする請求項１記載のコンピュータと電話の統合システム。 - 前記サービス要求部からのサービス要求に基づき、会議を行う第一の前記デバイスへ発信して接続し、該会議に参加する第二の前記デバイスから前記スイッチエンジンへ着信、又は、前記スイッチエンジンから前記会議に参加する第二の前記デバイスへ発信して、前記第二のデバイスと前記スイッチエンジンとを接続し、更に前記第一のデバイスと前記第二のデバイス間のパスを接続することにより会議を行うことを特徴とする請求項１記載のコンピュータと電話の統合システム。
- 交換制御を行うスイッチエンジンと前記スイッチエンジンに対して電話交換サービスを要求するサービス要求部とのインターフェース機能を有するサービス要求処理・呼情報通知手段におけるサービス要求処理・呼情報通知プログラムを記録したコンピュータ読取可能な記録媒体であって、
コンピュータを、
交換制御を行うスイッチエンジンに対して電話交換サービスを要求する、サービス要求部からの要求を処理する手段と、
前記スイッチエンジンに接続されたデバイスの状態情報と、前記スイッチエンジンと前記デバイス間のパス接続情報の二種類の呼情報を前記サービス要求部に通知させる手段として機能させ、
前記デバイスと前記スイッチエンジン間の接続が、他の前記デバイスと前記スイッチエンジン間のパスの接続がなくとも、単独で確立し、
前記サービス要求部からのサービス要求に基づき、前記スイッチエンジンと接続が確立している前記デバイスを単位としてサービスを行う
ようにしたサービス要求処理・呼情報通知プログラムを格納した記録媒体。 - 前記サービス要求部からの要求を処理する手段は、
前記デバイスの発信手段と、
前記スイッチエンジンと前記デバイス間の接続の解放手段と、
二つの前記デバイス間のパスの接続手段と、
二つの前記デバイス間のパスの解放手段と、
を有することを特徴とする請求項９記載のサービス要求処理・呼情報通知プログラムを格納した記録媒体。 - 交換制御を行うスイッチエンジンと、
前記スイッチエンジンに対して電話交換サービスを要求するサービス要求部と、
前記スイッチエンジンと前記サービス要求部とのインターフェース機能を有するサービス要求処理・呼情報通知手段とを有し、
前記サービス要求処理・呼情報通知手段は、前記サービス要求部から前記スイッチエンジンに対する交換サービスの要求及び前記スイッチエンジンから前記サービス要求部に対する前記スイッチエンジンと前記スイッチエンジンに接続されたデバイスに係る呼情報の通知を行い、
前記呼情報は、前記デバイスの状態情報と、前記スイッチエンジンとデバイス間のパス接続情報の二種類であり、
前記デバイスと前記スイッチエンジン間の接続が、他の前記デバイスと前記スイッチエンジン間のパスの接続がなくとも、単独で確立し、
前記サービス要求部からのサービス要求に基づき、前記スイッチエンジンと接続が確立している前記デバイスを単位としてサービスを行う
ことを特徴とする交換制御装置。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP05685298A JP4087941B2 (ja) | 1998-03-09 | 1998-03-09 | コンピュータと電話の統合システム |
| US09/265,347 US6707899B2 (en) | 1998-03-09 | 1999-03-09 | Computer-telephone integrated system, switching control apparatus and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP05685298A JP4087941B2 (ja) | 1998-03-09 | 1998-03-09 | コンピュータと電話の統合システム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH11262039A JPH11262039A (ja) | 1999-09-24 |
| JP4087941B2 true JP4087941B2 (ja) | 2008-05-21 |
Family
ID=13038958
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP05685298A Expired - Fee Related JP4087941B2 (ja) | 1998-03-09 | 1998-03-09 | コンピュータと電話の統合システム |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US6707899B2 (ja) |
| JP (1) | JP4087941B2 (ja) |
Families Citing this family (48)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1514400B1 (en) | 2000-01-07 | 2018-02-21 | Mitel Communications Inc. | Customer communication service system |
| KR100359153B1 (ko) * | 2000-05-10 | 2002-10-31 | 주식회사 로커스 | 광역 번호 안내를 위한 서비스 제어 방법 및 장치 |
| DE10120072A1 (de) * | 2001-04-24 | 2002-11-07 | Siemens Ag | Vermittlungssystem und Verfahren zur Überwachung einer Gruppenrufnummer |
| US7133517B2 (en) * | 2001-06-04 | 2006-11-07 | Network Telco, Inc. | Interface to integrated switch control software |
| US8170197B2 (en) * | 2002-03-15 | 2012-05-01 | Intellisist, Inc. | System and method for providing automated call center post-call processing |
| US8068595B2 (en) | 2002-03-15 | 2011-11-29 | Intellisist, Inc. | System and method for providing a multi-modal communications infrastructure for automated call center operation |
| US7292689B2 (en) | 2002-03-15 | 2007-11-06 | Intellisist, Inc. | System and method for providing a message-based communications infrastructure for automated call center operation |
| EP1385343A1 (en) * | 2002-07-24 | 2004-01-28 | Koninklijke KPN N.V. | System and method for controlling a telecom network |
| EP3484135A1 (en) | 2008-04-02 | 2019-05-15 | Twilio Inc. | System and method for processing telephony sessions |
| US8837465B2 (en) | 2008-04-02 | 2014-09-16 | Twilio, Inc. | System and method for processing telephony sessions |
| EP2335402A4 (en) | 2008-10-01 | 2013-04-24 | Twilio Inc | TELEPHONY WEB EVENT SYSTEM AND METHOD |
| WO2010101935A1 (en) | 2009-03-02 | 2010-09-10 | Twilio Inc. | Method and system for a multitenancy telephone network |
| US9210275B2 (en) | 2009-10-07 | 2015-12-08 | Twilio, Inc. | System and method for running a multi-module telephony application |
| US20110145319A1 (en) * | 2009-12-15 | 2011-06-16 | Dolan Michael F | Group session management and admission control of multiple internet protocol flows |
| US20120208495A1 (en) | 2010-06-23 | 2012-08-16 | Twilio, Inc. | System and method for monitoring account usage on a platform |
| US9590849B2 (en) | 2010-06-23 | 2017-03-07 | Twilio, Inc. | System and method for managing a computing cluster |
| US8838707B2 (en) | 2010-06-25 | 2014-09-16 | Twilio, Inc. | System and method for enabling real-time eventing |
| US8649268B2 (en) | 2011-02-04 | 2014-02-11 | Twilio, Inc. | Method for processing telephony sessions of a network |
| US20140044123A1 (en) | 2011-05-23 | 2014-02-13 | Twilio, Inc. | System and method for real time communicating with a client application |
| US9648006B2 (en) | 2011-05-23 | 2017-05-09 | Twilio, Inc. | System and method for communicating with a client application |
| US9398622B2 (en) | 2011-05-23 | 2016-07-19 | Twilio, Inc. | System and method for connecting a communication to a client |
| US10182147B2 (en) | 2011-09-21 | 2019-01-15 | Twilio Inc. | System and method for determining and communicating presence information |
| US9495227B2 (en) | 2012-02-10 | 2016-11-15 | Twilio, Inc. | System and method for managing concurrent events |
| US9602586B2 (en) | 2012-05-09 | 2017-03-21 | Twilio, Inc. | System and method for managing media in a distributed communication network |
| US9247062B2 (en) | 2012-06-19 | 2016-01-26 | Twilio, Inc. | System and method for queuing a communication session |
| US8737962B2 (en) | 2012-07-24 | 2014-05-27 | Twilio, Inc. | Method and system for preventing illicit use of a telephony platform |
| US8948356B2 (en) | 2012-10-15 | 2015-02-03 | Twilio, Inc. | System and method for routing communications |
| US8938053B2 (en) | 2012-10-15 | 2015-01-20 | Twilio, Inc. | System and method for triggering on platform usage |
| US9282124B2 (en) | 2013-03-14 | 2016-03-08 | Twilio, Inc. | System and method for integrating session initiation protocol communication in a telecommunications platform |
| US9240966B2 (en) | 2013-06-19 | 2016-01-19 | Twilio, Inc. | System and method for transmitting and receiving media messages |
| US9225840B2 (en) | 2013-06-19 | 2015-12-29 | Twilio, Inc. | System and method for providing a communication endpoint information service |
| US9274858B2 (en) | 2013-09-17 | 2016-03-01 | Twilio, Inc. | System and method for tagging and tracking events of an application platform |
| US9137127B2 (en) | 2013-09-17 | 2015-09-15 | Twilio, Inc. | System and method for providing communication platform metadata |
| US9325624B2 (en) | 2013-11-12 | 2016-04-26 | Twilio, Inc. | System and method for enabling dynamic multi-modal communication |
| US9553799B2 (en) | 2013-11-12 | 2017-01-24 | Twilio, Inc. | System and method for client communication in a distributed telephony network |
| US9344573B2 (en) | 2014-03-14 | 2016-05-17 | Twilio, Inc. | System and method for a work distribution service |
| US9226217B2 (en) | 2014-04-17 | 2015-12-29 | Twilio, Inc. | System and method for enabling multi-modal communication |
| US9774687B2 (en) | 2014-07-07 | 2017-09-26 | Twilio, Inc. | System and method for managing media and signaling in a communication platform |
| US9516101B2 (en) | 2014-07-07 | 2016-12-06 | Twilio, Inc. | System and method for collecting feedback in a multi-tenant communication platform |
| US9246694B1 (en) * | 2014-07-07 | 2016-01-26 | Twilio, Inc. | System and method for managing conferencing in a distributed communication network |
| US9251371B2 (en) | 2014-07-07 | 2016-02-02 | Twilio, Inc. | Method and system for applying data retention policies in a computing platform |
| US9363301B2 (en) | 2014-10-21 | 2016-06-07 | Twilio, Inc. | System and method for providing a micro-services communication platform |
| US9477975B2 (en) | 2015-02-03 | 2016-10-25 | Twilio, Inc. | System and method for a media intelligence platform |
| US9948703B2 (en) | 2015-05-14 | 2018-04-17 | Twilio, Inc. | System and method for signaling through data storage |
| US10419891B2 (en) | 2015-05-14 | 2019-09-17 | Twilio, Inc. | System and method for communicating through multiple endpoints |
| US10659349B2 (en) | 2016-02-04 | 2020-05-19 | Twilio Inc. | Systems and methods for providing secure network exchanged for a multitenant virtual private cloud |
| US10686902B2 (en) | 2016-05-23 | 2020-06-16 | Twilio Inc. | System and method for a multi-channel notification service |
| US10063713B2 (en) | 2016-05-23 | 2018-08-28 | Twilio Inc. | System and method for programmatic device connectivity |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5655015A (en) * | 1994-02-18 | 1997-08-05 | Aurora Systems, Inc. | Computer-telephone integration system |
| US5655014A (en) * | 1994-02-18 | 1997-08-05 | Aurora Systems, Inc. | Switching device independent computer-telephone integration system |
| US5642410A (en) * | 1994-02-18 | 1997-06-24 | Aurora Systems, Inc. | Call processor for a computer telephone integration system |
| US5754636A (en) * | 1994-11-01 | 1998-05-19 | Answersoft, Inc. | Computer telephone system |
| US5649005A (en) * | 1995-07-07 | 1997-07-15 | Northern Telecom Limited | PC with telephony exchange function |
| US6094479A (en) * | 1997-05-06 | 2000-07-25 | Telefonaktiebolaget Lm Ericsson | Computer telephony integration gateway |
-
1998
- 1998-03-09 JP JP05685298A patent/JP4087941B2/ja not_active Expired - Fee Related
-
1999
- 1999-03-09 US US09/265,347 patent/US6707899B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US20020057777A1 (en) | 2002-05-16 |
| US6707899B2 (en) | 2004-03-16 |
| JPH11262039A (ja) | 1999-09-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4087941B2 (ja) | コンピュータと電話の統合システム | |
| US6801613B1 (en) | Associating call appearance with data associated with call | |
| EP1081932B1 (en) | Call-me conference call system | |
| JP4125806B2 (ja) | 通信ルーチング装置および方法 | |
| JP4485850B2 (ja) | 共用通信構想構成の実時間管理 | |
| US6363142B1 (en) | Network directed call pickup service | |
| CN101483699A (zh) | 呼叫中心处理用户呼叫的方法、系统及装置 | |
| JP3097114B2 (ja) | 通信システムにおけるサービス制御方式ならびに電話機およびファクシミリ装置 | |
| KR100587945B1 (ko) | 호 전환 서비스 제공 방법 및 시스템 | |
| KR100640289B1 (ko) | 통화 서비스를 제공 받기 위한 ｉｐ 단말기의 동작 방법및 그 ｉｐ 단말기 | |
| KR20030027466A (ko) | 인터넷 폰 서비스를 제공하는 사설교환시스템에서 호 전환장치 및 방법 | |
| JPH11205475A (ja) | 通話装置 | |
| JP2009147728A (ja) | 同一の回線から複数の発信先に対して同時に発信可能とした構内交換機 | |
| EP1611736A1 (en) | Arrangement served by operator to establish connections between users | |
| JPH09163416A (ja) | 構内交換機の内線通信管理システム | |
| EP1943825B1 (en) | System and method for managing the replacement of an existing subscriber call connection by a call waiting party | |
| JP2022131745A (ja) | 電話交換機及び電話交換システム | |
| JP3077162B2 (ja) | アクセスネットワーク | |
| JP2737258B2 (ja) | 加入者無線通信システムにおける着信転送方式 | |
| KR100611799B1 (ko) | 특수 기능을 제공하는 교환 시스템 및 그 제공 방법 | |
| KR19990020643A (ko) | 전전자 교환기의 내선 가입자 호 전환 서비스 방법 | |
| JPH07336441A (ja) | 交換ネットワーク | |
| KR20040045595A (ko) | 콜 센터 시스템 | |
| JPH0427258A (ja) | 発側制御着信接続方式 | |
| JPH11308348A (ja) | 操作者呼転送方式 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050224 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20070222 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070515 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070717 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20080219 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080222 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110228 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110228 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120229 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130228 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130228 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140228 Year of fee payment: 6 |
|
| LAPS | Cancellation because of no payment of annual fees |