(57)【特許請求の範囲】
【請求項１】
インターネットプロトコル音声応答システムであって、
チップリング電話システムと共に使用するように構成された通信サーバと、
前記通信サーバをチップリング電話ネットワークに機能的に接続するための手段と、
前記通信サーバをインターネットプロトコルコンピュータネットワークに機能的に接続するための手段と、
第１の信号フォーマットから成るチップリング電話システムイベントと、第２の信号フォーマットから成るインターネットプロトコル電話コマンドの間を変換するための手段であって、前記通信サーバを前記インターネットプロトコルコンピュータネットワークへ動作的に接続するよう処理する手段と、
前記チップリングネットワーク上に設定された通信チャネルのための、前記通信サーバ上で使用可能な複数のチャネルのうちの少なくともいくつかを、前記インターネットプロトコルコンピュータネットワーク上に設定されたバーチャル通信チャネルへ割り振るための手段と、
チップリング電話ネットワークとを備え、前記通信サーバ上で使用可能なチャネルを割り振るための手段は、前記インターネットプロトコルコンピュータネットワーク上で設定されたバーチャル通信チャネルと、前記チップリング電話ネットワーク上で設定された物理チャネルとの間で前記チャネルを割り振るよう動作し、前記通信サーバ上で使用可能な第１のチャネルは前記インターネットプロトコルコンピュータネットワーク上に設定されたバーチャルチャネルに割り当てられ、および前記通信サーバ上で使用可能な第２のチャネルは前記チップリングネットワーク上で設定されたチャネルに割り当てられるようになっているインターネットプロトコル音声応答システム。
【請求項２】
前記インターネットプロトコルコンピュータネットワークはインターネットである請求項１に記載のシステム。
【請求項３】
前記チップリング電話ネットワークは公衆交換電話網である請求項１に記載のシステム。
【請求項４】
前記チップリング電話ネットワークは機内交換である請求項１に記載のシステム。
【請求項５】
チップリング電話サーバをパケットに基づいた通信ネットワークにインタフェースするための方法であって、
チップリング電話サーバとコンピュータネットワークの間のインタフェースで第１の信号を受信するステップであって、該第１の信号がデータのパケットおよびソフトウェアイベントの第１のものから成る第１の信号フォーマットにあるステップと、
前記第１の信号を第２の信号フォーマットに変換するステップであって、該第２の信号フォーマットがデータのパケットおよびソフトウェアイベントの第２のものから成るものであるステップと、
ａ）  前記コンピュータネットワークが前記第１の信号のソースである時に、ソフトウェアイベントとしてフォーマット化された前記第１の信号を前記チップリング電話サーバに提供するステップ、および
ｂ）  前記チップリング電話サーバが前記第１の信号のソースである時に、データのパケットとしてフォーマット化された前記第１の信号を前記コンピュータネットワークに提供するステップ、のうちの少なくとも１つを遂行するステップと、
前記チップリング電話サーバ上で使用可能なチャネルを、前記パケットに基いた通信ネットワークに割り当てるステップと、
前記チップリング電話サーバとチップリング電話ネットワークの間のインターフェースにて第２の信号を受信するステップとを含み、前記チップリング電話サーバ上で使用可能な第１のチャネルは前記パケットに基いた通信ネットワーク上で設定された第１のバーチャルチャネルに割り当てられ、および前記チップリング電話サーバ上で使用可能な第２のチャネルは前記チップリング電話ネットワーク上で設定された第２のチャネルに割り当てられるようになっている方法。
【請求項６】
前記サーバをチップリング電話ネットワークにインタフェースするステップと、
前記サーバ上で使用可能なチャネルを前記パケットに基づいたネットワーク上に設定されたバーチャルチャネルと、前記チップリング電話ネットワーク上に設定された物理チャネルとの間に割り振るステップとをさらに含む請求項５に記載の方法。
【請求項７】
前記パケットに基づいたネットワークはインターネットである請求項５に記載の方法。
【請求項８】
前記チップリング電話ネットワークは公衆交換電話網である請求項６に記載の方法。
【請求項９】
前記チップリング電話ネットワークは機内交換である請求項７に記載の方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は音声メッセージ送信サーバを含む電話通信サーバに関する。
【０００２】
【従来の技術】
電話通信業界は、従来のチップリングの、回線に基づいた電話システムと共に使用するために、音声応答サーバなどの種々のサーバを開発してきた。たとえば、加入者の電話が応答されなかった時に、発呼者に対してあらかじめ録音された挨拶を提供する音声メッセージ送信サーバは広く使用されている。典型的には、これらの音声メッセージ送信サーバを使用すると、発呼者がオーディオメッセージを記録して、後から加入者によって再生されることが可能になる。既存の音声メッセージ送信サーバはまた、オペレータへ接続する機能、または所定のセルラ電話またはページングシステムと共に加入者を呼び出す機能など、種々の追加の機能も提供する場合がある。他のタイプの音声応答サーバは自動化されたシステムを含み、発呼者と相互作用して情報を受信または配信する。音声メッセージ送信サーバを含むほとんどのこのような音声応答サーバは、発呼者側の電話と被呼者側の電話または音声応答サーバの間でデータを送信するための専用回線を使用する、従来の電話技法と共に使用するように構成されている。
【０００３】
可聴情報は、従来のアナログ電話回線またはディジタル電話回線に加えて、インターネットなどのコンピュータネットワーク上でも送信できる。一般に、コンピュータネットワークはデータをデータパケットに分割して、データを同時に多くの他の受信者に搬送できる通信チャネル上で、目的の受信者に送信する。インターネットプロトコル（ＩＰ）電話標準規格（たとえばＨ．３２３、Ｈ．２４５、およびＨ．２２５）などの標準規格に基づいてパケットで可聴データを送信することは、通信リンクのエンドポイント間で専用の物理回線を提供する必要性を除去し、したがって、従来の電話技法より効率がよい。したがって、インターネット電話タイプのシステムはますます普及してきている。
【０００４】
ベンダはインターネット電話タイプのシステムと共に使用するための通信サーバを提供するために、このようなシステムと互換性のあるサーバを開発してきた。しかし、このようなシステムは典型的には従来のチップリング電話システムとは互換性がない。さらに、インターネット電話システムと共に使用するために開発されたサーバは、典型的には、従来の電話システムのために以前に開発されたサーバのハードウェア構成要素およびソフトウェア構成要素を再使用できない。したがって、インターネット電話システムと共に使用するための通信サーバは限定された適用可能性を有し、開発するのに費用がかかる。
【０００５】
インターネット電話と共に使用するための従来の通信サーバでは、既存の回路に基づいた音声応答サーバをインターネット電話と共に使用するように構成することはできない。したがって、インターネット電話と共に使用するための通信サーバを提供するためにシステムが存在しても、ベンダはまったく新しいサーバを購入しなければならない。さらに、以前は通信サーバは、従来のチップリングの、回路に基づいた電話、およびインターネットに基づいた電話システムの両方と共に動作することはできなかった。
【０００６】
【発明が解決しようとする課題】
本発明は、先行技術のこれらの問題および他の問題、また欠点を解決することに関する。一般に、本発明によれば、通信サーバはコンピュータネットワークとインタフェースし、サーバがインターネット電話タイプの通信チャネルを使用して発呼された電話呼を処理することを可能にする。本発明によれば、通信サーバにソフトウェアモジュールが提供され、インターネットプロトコル標準規格を使用して表現されたデータイベントを、従来の回路に基づいた通信システム内の対応するイベントおよびこのようなイベントの表現にマッピングする。
【０００７】
特に、本発明はもともとチップリングの、回路に基づいた電話ネットワークと共に使用するために構成された通信サーバを使用する。本発明によれば、通信サーバにインタフェースが提供され、パケットに基づいたデータ通信プロトコルを使用してサーバをコンピュータネットワークに相互接続する。さらに、通信サーバにはポートインタフェースが提供され、サーバ上のポートをコンピュータネットワーク上で確立されたバーチャルチャネルに割り当てる。さらに、チップリングタイプの電話ネットワークにしたがって表現されたイベントと、パケットに基づいたコンピュータネットワークにしたがって送信されたコマンドとの間を変換するための機能を含むインターネットプロトコルプロセスモジュールも提供される。
【０００８】
本発明の一実施形態によれば、チップリングタイプの電話通信サーバと共に使用されるように構成された既存のサーバが変更され、パケットに基づいた、あるいはインターネットプロトコルのコンピュータネットワークを使用して送信された通信を処理することができる。特に、既存のチップリングサーバはサーバの既存のポートインタフェースライブラリを本発明によって開示されたポートインタフェースライブラリと置き換え、さらにインターネットプロトコル電話ソフトウェアおよびハードウェアを追加してサーバをインターネットプロトコルネットワークにインタフェースすることにによって変更できる。したがって、本発明を使用すると、処理されている特定の呼がチップリングでサーバに接続されているかまたはＩＰネットワークインタフェースで接続されているかにかかわらず、アプリケーションソフトウェアに一貫したインタフェースを提供するソフトウェアを提供することによって、既存のチップリングサーバのアプリケーションソフトウェアがＩＰプロトコル電話ネットワークと共に動作することが可能になる。さらに、本発明によれば、チップリングタイプの電話通信を処理するためのサーバの機能も保持できる。したがって、本発明はサービスプロバイダが既存のサーバを交換する必要なしにサービスの提供をアップグレードすることを可能にする。さらに、本発明はチップリングタイプの電話ネットワーク上を送信された通信、およびパケットに基づいたコンピュータネットワーク上を送信された通信を同時に処理することのできる通信サーバを提供する。
【０００９】
本発明のこれらの利点および機能、および他の利点および機能は、次の、本発明の例示的な実施形態の説明および図面からさらに明らかになろう。
【００１０】
【発明の実施の形態】
次に図１を参照すると、通信サーバ１００が図示され、通信サーバ１００を囲む例示的なシステムトポロジを含む。この構成は一般に、通信サーバ１００、コンピュータネットワーク１０２、および連続した回線によるに基づいた電話システム１０４を備える。
【００１１】
コンピュータネットワーク１０２は任意のローカルエリアネットワーク（ＬＡＮ）または広域ネットワーク（ＷＡＮ）であってもよい。たとえば、コンピュータネットワーク１０２は公共のインターネットまたは私設のイントラネットであってもよい。コンピュータネットワーク１０２は、定義されたプロトコルにしたがって構成されたデータパケットの使用によって特徴づけられ、通信をネットワーク１０２上で送達する。コンピュータネットワーク１０２はソフトホン、オーディオが使用可能なパーソナルコンピュータ１０６、またはインターネットプロトコル（ＩＰ）エンドポイントなど他のタイプのエンドポイントと相互接続される場合がある。したがって、コンピュータネットワーク１０２はソフトホン１０６と、第２のソフトホン（図１には図示せず）またはインターネットプロトコル電話標準規格にしたがった通信サーバ１００などの他のエンドポイントとの間で通信を送信するために使用することができる。
【００１２】
チップリングの連続した回線による電話ネットワーク１０４は、公衆交換電話網（ＰＳＴＮ）であってもよい。さらに、チップリング電話システム１０４は、機内交換（ＰＢＸ）であってもよい。ここに使用されたように、チップリング電話システム１０４はまた、ＴＩシステムなどのディジタル回路に基づいた通信システムを備える場合もある。したがって、チップリング電話システム１０４と通信サーバ１００の間のインタフェースは、切換式回路電話標準規格を使用している。チップリング電話システム１０４に相互接続されているのは、電話１０８または他の通信デバイスであってもよい。通信デバイス１０８は、よく知られた連続した回線による技法を使用して電話システム１０４を介して通信サーバ１００に相互接続できる電話であってもよい。しかし、電話１０８は通信システムの任意の組み合わせを介して通信サーバに相互接続できることを理解されたい。
【００１３】
通信サーバ１００は、Ｌｕｃｅｎｔ  Ｔｅｃｈｎｏｌｏｇｉｅｓ  Ｉｎｃ．のＩｎｔｕｉｔｙ  Ａｕｄｉｘ（商標）メッセージ送信システム、ＩｎｔｕｉｔｙＡｎｙＰａｔｈ（商標）メッセージ送信システム、またはＣｏｎｖｅｒｓａｎｔ（商標）音声応答システムなどの音声応答サーバおよびメッセージ送信サーバを含む任意の電話通信サーバであってもよい。一般に、通信サーバ１００は格納されたプログラムで制御される装置であり、記憶域１１２に格納された制御プログラムを実行するためのプロセッサ１１０を有する。記憶域１１２は任意のコンピュータ可読記憶媒体であってもよい。通信サーバ１００はまたネットワークインタフェース１１４を含み、通信サーバ１００をコンピュータネットワーク１０２に相互接続する。通信サーバ１００はまたチップリング電話ポート１１６を備え、通信サーバ１００をチップリング電話ネットワーク１０４に相互接続してもよい。
【００１４】
記憶域１１２はデータベース１１８を含んで管理情報を格納する場合がある。たとえば、通信サーバ１００がメッセージ送信サーバである場合、データベース１１８はメッセージ送信サービスの各加入者にメッセージメールボックスを提供し、加入者の挨拶および加入者のパスワードなど関連する情報を格納する場合がある。記憶域１１２はまた、種々のソフトウェアモジュールを含む場合がある。たとえば、記憶域１１２は一般に音声応答アプリケーションソフトウェアモジュール１２０を含み、通信サーバ１００と、サーバ１００で通信を確立するユーザとの相互作用を制御する。たとえば、通信サーバ１００がメッセージ送信サーバである場合、アプリケーションソフトウェア１２０は、加入者、および呼がサーバ１００にリダイレクトされた加入者に接触しようとする者にインタフェースを提供する場合がある。さらに、アプリケーションソフトウェア１２０は加入者の挨拶を再生したり、発呼者のメッセージを記録したりするために必要なプログラミングを含むか、または、このようなサーバ１００に関連づけられた機能を豊富に含んだセットを提供する場合がある。一般に、アプリケーションソフトウェア１２０は既定のコマンドのセットを使用して他のソフトフェアモジュール（以下に説明する）と通信するように構成されている。この既定のコマンドのセットは、標準ＵＮＩＸオペレーティングシステムＩＰＣメッセージ待ち行列タイププロセス間メッセージなどの、任意のタイプのプロセス間メッセージであってもよい。
【００１５】
記憶域１１２はまた、ポートインタフェースライブラリ１２２、チップリングデバイスドライバ１２４、インターネットプロトコル（ＩＰ）インタフェースプロセス１２６、ＩＰ電話スタック１２８、およびＴＣＰ／ＩＰスタック１３０も含む。ポートインタフェースライブラリ１２２は、ポートマップ１３２およびイベント待ち行列１３４を含む場合がある。一般に、ポートマップ１３２は音声応答アプリケーションソフトウェア１２０上で使用可能なポートを、チップリング電話システム１０４上で送信された通信を処理するポート、およびコンピュータネットワーク１０２上で送信される通信を処理するポートにマッピングする。ポートマップ１３２内のポートをチップリング電話システム１０４またはコンピュータネットワーク１０２に割り振ることは、サーバ１００のアドミニストレータによって決定される場合もあり、デマンドに応じてダイナミックに実行される場合もある。イベント待ち行列１３４は、チップリングデバイスドライバ１２４またはＩＰインタフェースプロセスモジュール１２６から受信された非対照的なベントのためのバッファとして機能する。
【００１６】
チップリングデバイスドライバ１２４は、チップリングインタフェースハードウェア１１６を制御するために必要なプログラミングコマンドを含む。チップリングデバイスドライバ１２４は、既定のコマンドのセットによってフォーマット化されたポートインタフェースライブラリ１２２から受信されたイベントに応答して、これらのイベントにしたがってチップリングインタフェースハードウェア１１６を制御する。チップリングインタフェースハードウェアはまた、ポートインタフェースライブラリ１２２から渡されたデータをフォーマット化し、チップリング電話システム１０４上で送信する。さらに、チップリングデバイスドライバ１２４はチップリング電話システム１０４からデータおよびイベントを受信し、そのデータおよびイベントを既定のコマンドのセットにしたがってフォーマット化し、フォーマット化されたデータおよびイベントをポートインタフェースライブラリ１２２に渡すように動作する。したがって、チップリングデバイスドライバ１２４はチップリングハードウェア１１６を制御するように機能することと、チップリングデバイスドライバ１２６とポートインタフェースライブラリ１２２の間を通過するコマンドおよびデータは、既定のコマンドのセットの規則にしたがってフォーマット化されることが理解されるであろう。
【００１７】
ＩＰインタフェースプロセス１２６は一般に、ポートインタフェースライブラリ１２２と、ネットワークインタフェース１１４に関連づけられたＩＰ電話スタック１２８との間を変換するためのインタフェースおよび変換モジュールとして機能する。したがって、ＩＰインタフェースプロセス１２６は、ＩＰ電話スタック１２８によって要求されたように、アプリケーションソフトウェア１２０の既定のコマンドのセットを使用してアプリケーションソフトウェア１２０と通信し、データのパケットを使用してＩＰ電話スタック１２８と通信する。ネットワークインタフェース１１４はコンピュータネットワーク１０２とＴＣＰ／ＩＰスタック１３０の間の物理インタフェースとして機能する。ＴＣＰ／ＩＰスタック１３０で受信されたデータパケットは、ＩＰ電話スタック１２８に渡される。ＩＰ電話スタック１２８は、インターネットを含むコンピュータネットワーク上で音声、ファックスおよびデータ通信を送信するための、国際通信連合によって確立されたＨ．３２３標準規格、Ｈ．２４５標準規格、およびＨ．２２５標準規格など任意のプロトコルであってもよい。ＩＰ電話スタック１２８はついで、依然としてパケットの形態であるデータをＩＰインタフェースプロセス１２６に提供する。
【００１８】
一般に、コンピュータネットワーク１０２上を送信される通信ストリームは専用の物理回線には割り当てられない。そのかわりに、各ストリームに関連づけられたデータはパケット内に置かれ、共有通信チャネル上を送信される。コンピュータネットワーク１０２環境内に専用回線がないため、個別の通信ストリームはバーチャルポートに割り当てられなければならない。したがって、バーチャルポートマップ１３６はインターネットプロトコルインタフェースプロセス１２６の一部として含まれ、ＩＰインタフェースプロセスモジュール１２６が特定の通信ストリームを、ポートインタフェースライブラリ１２２と通信している特定のポートに宛てる（attribute）ことを可能にする。上記の説明から、コンピュータネットワーク１０２上を送信され、ＩＰインタフェースプロセスモジュール１２６によって処理される通信が、データパケットタイプのフォーマットであることが理解されよう。
【００１９】
次に図２を参照すると、本発明の例示的な実施形態によるポートマップ１３２の内容が図示されている。ポートマップ１３２は一般に音声応答アプリケーションソフトウェア１２０と共に使用可能な各ポートに関連づけられた、通信チャネル２０２のタイプに関する情報を含む。図２に示された例では、ポート番号０および１は両方ともインターネットプロトコル通信に関連づけられている。したがって、ポート０および１に関連して音声応答アプリケーションソフトウェア１２０から発生したデータおよびイベントは、ポートインタフェースライブラリ１２２によってＩＰインタフェースプロセスモジュール１２６に転送されることになる。ポート番号ｎ−１およびｎは、図２に示された例の中ではチップリング電話システム１０４と関連づけられている。したがって、ポートｎ−１およびｎに関連して音声応答アプリケーションソフトウェア１２０から発生したイベントおよびデータは、ポートインタフェースライブラリ１２２によってチップリングデバイスドライバ１２４に転送され、チップリング電話システム１０４上を送信されることになる。ＩＰインタフェースプロセスモジュール１２６によってコンピュータネットワーク１０２から受信されたコマンドおよびデータは適切なポート番号と関連づけられ、音声応答アプリケーションソフトウェア１２０によって使用される既定のコマンドのセットに変換され、他のソフトウェアモジュールと通信してから、ポートインタフェースライブラリ１２２に渡される。チップリングデバイスドライバ１２４によってチップリング電話ネットワーク１０４から受信されたコマンドおよびデータはまた、フォーマット化されてから音声応答アプリケーションソフトウェア１２０上の適切なポートに渡される。
【００２０】
本発明の一実施形態による、通信サーバ１００の動作が次の種々の例に関して説明される。次に図３を参照すると、電話呼に答えるサーバ１００の動作のフローチャートが示されている。まず、チップリングハードウェア１１６のポートｎにおいて受信された着信呼に応答するサーバ１００の動作の例（ステップ３０２）を説明する。ついで、ネットワークインタフェース１１４で受信された着信呼に応答するサーバ１００の動作を説明する。たとえばステップ３０４でポートｎなどのチップリングポート上で呼が受信されると、チップリングデバイスドライバ１２４はポートｎにおいてリンギング回路を検出する。ステップ３０６でデバイスドライバ１２４はリンギング回路に応答してＮＥＷ＿ＣＡＬＬ（ポートｎ）イベントを作成し、これはステップ３０８でポートインタフェースライブラリ１２２のイベント待ち行列１３４の中に置かれる。ステップ３１０で新しい呼イベントが、アプリケーションソフトウェア１２０によって開始されたＧＥＴ＿ＥＶＥＮＴ（）関数コールを介して音声応答アプリケーションソフトウェア１２０によって受信される。ステップ３１２でアプリケーションソフトウェア１２０は新しい呼イベントに応答して、ＯＦＦ＿ＨＯＯＫ（ポートｎ）コマンドをポートインタフェースライブラリ１２２に発行し、ポートｎをオフフックにする。ステップ３１４では、ポートインタフェースライブラリ１２２はポートマップ１３２を参照して、ポートｎに関連づけられたインタフェースのタイプを決定する。この例では、ポートｎはチップリングポートであり、したがってポートインタフェースライブラリ１２２はＯＦＦ＿ＨＯＯＫ（ポートｎ）コマンドをチップリングデバイスドライバ１２４に向けてポートｎ（ステップ３１６）をオフフックにする。ステップ３１８では、チップリングデバイスドライバ１２４はポートｎオフフックをとり、ポートｎに関して電話システム１０４エンドポイント（たとえば電話１０８）と、チップリングハードウェア１１６のデバイスドライバとの間に物理回線を確立する。アプリケーションソフトウェア１２０はついで、ステップ３２０において、挨拶を再生する、発呼側が加入者メールボックスにメッセージを記録できるようにするなど、通常の呼応答シナリオを開始することができる。
【００２１】
次に引き続き図３を参照し、インターネットプロトコルエンドポイント１０６から受信された接続要求に応答するサーバ１００の一実施形態の動作を説明する。ステップ３２２で、呼接続要求はネットワークインタフェース１１４においてデータのパケットとして受信される。呼接続要求はインターネットプロトコル電話スタック１２８へのＴＣＰ／ＩＰスタック１３０に渡され、ついで、インターネットプロトコルインタフェースプロセス１２６に送達される（ステップ３２４）。ステップ３２６で、ＩＰインタフェースプロセス１２６はデータパケットを呼接続要求として認識し、着信呼を使用可能なバーチャルポートに割り当て、バーチャルポートマップ１３６を更新して割り当てられたポートがビジー状態であることを示す。たとえばポート０が使用可能な場合は、ＩＰインタフェースプロセス１２６は呼をポート０に割り当て、ポート０をバーチャルポートマップ１３６内でビジーとしてマークすることができる。ステップ３２８では、ＩＰインタフェースプロセス１２６はＮＥＷ＿ＣＡＬＬ（ポート０）イベントを作成し、ステップ３３０で新しい呼イベントをポートインタフェースライブラリ１２２のイベント待ち行列１３４の中に置く。ステップ３１０でアプリケーションソフトウェア１２０はＧＥＴ＿ＥＶＥＮＴ（）関数コールを介して新しい呼イベントを検索する。ついでステップ３１２で、アプリケーションソフトウェア１２０はＯＦＦ＿ＨＯＯＫ（ポート０）コマンドを発行してポート０をオフフックにする。ステップ３１４でポートインタフェースライブラリ１２２がポート０をオフフックにするコマンドを受信すると、ポートインタフェースライブラリ１２２はポートマップ１３２を参照して、ポート０がチップリングであるかまたはＩＰ電話タイプのポートであるか決定する。この例では、ポート０はＩＰ電話ポートであるので、したがって、ステップ３３２で、ポートインタフェースライブラリ１２２はＯＦＦ＿ＨＯＯＫ（ポート０）コマンドをインターネットプロトコルインタフェースプロセス１２６に向けて、ポート０をオフフックにする。ステップ３３４で、ＩＰインタフェースプロセス１２６がオフフックコマンドを受信すると、呼受領メッセージをインターネットプロトコルエンドポイント１０６に送信する。またステップ３３４でインターネットプロトコルインターフェイス１２６はついで、ＩＰエンドポイント１０６と接続情報を交換し（すなわち、ハンドシェーク手順を完了し）、論理チャネルおよび遠隔転送プロトコル（ＲＴＰ）セッションを確立する。
【００２２】
図３に関して論じられた例から、本発明のサーバ１００はＰＳＴＮ１０４またはコンピュータネットワーク１０２のどちらの上で確立された接続でも処理できることが理解されるであろう。さらに、音声応答アプリケーションソフトウェア１２０は、使用される通信チャネルがＰＳＴＮ１０４またはコンピュータネットワーク１０２のいずれであっても同じであることも理解されよう。
【００２３】
図４を参照すると、確立された電話呼から切断するサーバ１００の動作のフローチャートが示されている。まず、ＰＳＴＮ１０４上でサーバ１００に接続された遠隔発呼者によって開始された切断イベントに応答するサーバ１００の動作を説明する。ステップ４０２で、遠隔発呼者は電話１０８を切ることによって切断を開始する。ステップ４０４では、チップリングドライバ１２４はポートｎにおいて切断信号を検出する。チップリングドライバ１２４は切断信号に応答して、ＤＩＳＣＯＮＮＥＣＴ（ポートｎ）イベントをポートインタフェースライブラリ１２２のイベント待ち行列１３４の中に置く（ステップ４０６）。ついでステップ４０８で、ＤＩＳＣＯＮＮＥＣＴ（ポートｎ）イベントはアプリケーションソフトウェア１２０によって開始されたＧＥＴ＿ＥＶＥＮＴ（）関数コールを介してアプリケーションソフトウェア１２０に渡される。ステップ４１０で、アプリケーションソフトウェア１２０はＤＩＳＣＯＮＮＥＣＴ（ポートｎ）イベントに応答してトランザクションを終了し、ＯＮ＿ＨＯＯＫ（ポートｎ）コマンドをポートインタフェースライブラリ１２２に送信する。ステップ４１２では、ライブラリ１２２はポートマップ１３２を参照して、ＯＮ＿ＨＯＯＫ（ポートｎ）コマンドをルーティングする方法を決定する。ここで、ポートｎはチップリングポートと関連づけられているので、ステップ４１４でライブラリ１２２はＯＮ＿ＨＯＯＫ（ポートｎ）コマンドをチップリングデバイスドライバ１２４に送信する。ステップ４１６でチップリングデバイスドライバ１２４はＯＮ＿ＨＯＯＫ（ポートｎ）コマンドに応答して、ポートｎをオンフックにして、切断動作を終了する。
【００２４】
次に続いて図４を参照し、コンピュータネットワーク１０２上でサーバ１００と通信する遠隔発呼者から受信された切断イベントに応答するシステム１００の動作を説明する。ステップ４１８では、インターネットプロトコルエンドポイント１０６で遠隔発呼者が電話を切る。遠隔発呼者は、たとえば、パーソナルコンピュータまたは他のデバイスに関連づけられた通信プログラムのグラフィカルユーザインタフェースによって提供されるボタンをクリックすることによって、エンドポイント１０６の「電話を切る」ことができることが理解されよう。ステップ４２０では、ポート０に関して切断イベントを含むデータパケットがネットワークインタフェース１１４で受信され、ＩＰインタフェースプロセス１２６に渡される。ステップ４２２では、ＩＰインタフェースプロセス１２６は受信されたデータのパケットを読み取り、これに応答してＤＩＳＣＯＮＮＥＣＴ（ポート０）イベントをフォーマット化し、そのイベントをイベント待ち行列１３４に置く。ステップ４０８で音声応答アプリケーションソフトウェア１２０は、ＤＩＳＣＯＮＮＥＣＴ（ポート０）イベントをＧＥＴ＿ＥＶＥＮＴ（）関数コールを介してイベント待ち行列１３４から検索する。ステップ４１０でアプリケーションソフトウェア１２０はＤＩＳＣＯＮＮＥＣＴ（ポート０）イベントに応答して、ポート０に関するトランザクションを終了し、ＯＮ＿ＨＯＯＫ（ポート０）コマンドをポートインタフェースライブラリ１２２に送信する。ついでステップ４１２で、ライブラリはポートマップを参照して、イベントの正しい受信者を決定する。ポート０がコンピュータネットワーク１０２上で確立された通信チャネルに関連づけられているので、ステップ４２４でＯＮ＿ＨＯＯＫ（ポート０）コマンドはＩＰインタフェースプロセス１２６に送信される。ステップ４２６で、ＩＰインタフェースプロセス１２６はＯＮ＿ＨＯＯＫ（ポート０）コマンドに応答して、切断の確認を遠隔エンドポイント１０６に送信し、遠隔転送プロセス（ＲＴＰ）接続を切断し、バーチャルポートマップ１３６を変更してポート０が使用可能であることを示して、切断シーケンスを完了する。
【００２５】
遠隔電話１０８またはＩＰエンドポイント１０６において発呼者からの「電話を切る」信号によって開始された切断イベントに対するサーバ１００の応答の説明から、中心となる音声応答アプリケーションソフトウェア１２０の機能に関するプロセスステップは、通信チャネルに関係なく同じであることが理解されるであろう。したがって、本発明のサーバ１００を使用すると、既存の音声応答アプリケーションソフトウェア１２０は、ＰＳＴＮ１０４上で発生する通信、またはインターネットなどのコンピュータネットワーク１０２上で送信された通信のいずれとでも共に使用できる。
【００２６】
次に図５を参照し、本発明の一実施形態によるタッチトーンイベントの受信に応答するサーバ１００の動作を説明する。ステップ５０２では、サーバ１００はチップリングハードウェア１１６のポートｎでデュアルトーン複数周波数（ＤＴＭＦ）信号を検出する。ステップ５０４で、デバイスドライバ１２４はＴＯＵＣＨ＿ＴＯＮＥ（ポートｎ、値ｘ）イベントをフォーマット化する。ここでは値ｘは電話１０８のキーパッドで押されたキーに関連する（たとえば、１、２、３、４、５、６、７、８、９、０、＊または＃）。ついでステップ５０６で、デバイスドライバ１１６はＴＯＵＣＨ＿ＴＯＮＥ（ポートｎ、値ｘ）イベントを、ポートインタフェースライブラリ１２２のイベント待ち行列１３４の中に置く。ステップ５０８では、アプリケーションソフトウェア１２０は、イベント待ち行列１３４に行われたＧＥＴ＿ＥＶＥＮＴ（）関数コールを介して、ＴＯＵＣＨ＿ＴＯＮＥ（ポートｎ、値ｘ）イベントを検索する。ついでステップ５１０で、アプリケーションソフトウェア１２０は値ｘの受信に応答して指示されたアクションを実行する。たとえば、アプリケーションソフトウェア１２０は、０のタッチトーン値を受信し、発呼者をオペレータへ接続する場合がある。
【００２７】
タッチトーンがコンピュータネットワーク１０２を介してサーバ１００に接続された発呼者によって入力されると、タッチトーンイベントはネットワークインタフェース１１４でデータパケットとして受信される（ステップ５１２）。ステップ５１４でタッチトーンイベントデータパケットは、ネットワークインタフェース１１４で受信される任意の他のタイプのデータパケットと同じように、ＴＣＰ／ＩＰスタック１３０、ＩＰ電話スタック１２８に渡され、最終的にＩＰインタフェースプロセス１２６に渡される。またステップ５１４では、ＩＰインタフェースプロセス１２６はデータパケットをたとえばポート０におけるタッチトーンイベントとして認識する。当業者であれば、タッチトーンイベントは、帯域内信号（たとえばＲＴＰオーディオストリーム内に埋め込まれたＤＴＭＦトーンデータ）または帯域外信号（たとえばＨ．２４５プロトコルユーザ入力表示メッセージ）を使用して、ＩＰインタフェースプロセス１２６に通信される場合があることが理解されるであろう。ステップ５１６では、ＩＰインタフェースプロセス１２６はＴＯＵＣＨ＿ＴＯＮＥ（ポート０、値ｘ）イベントを作成する。ステップ５１８で、ＩＰインタフェースプロセス１２６はＴＯＵＣＨ＿ＴＯＮＥ（ポート０、値ｘ）イベントをイベント待ち行列１２４に置く。ついでステップ５０８で、アプリケーションソフトウェア１２０はＧＥＴ＿ＥＶＥＮＴ（）関数コールを介してＴＯＵＣＨ＿ＴＯＮＥ（ポート０、値ｘ）イベントを検索する。ついでステップ５１０で、アプリケーションソフトウェアは受信された値ｘに応答してアクションを実行することができる。
【００２８】
図５に関して与えられた例から、イベントが関連づけられているポートの番号から離れて、またサーバ１００がイベントまたはコマンドを受信した通信チャネルがなんであってもそれにかかわらず、ＴＯＵＣＨ＿ＴＯＮＥ（ポート＃、値ｘ）イベントはアプリケーションソフトウェア１２０には同じに見えることが理解されるであろう。したがって、アプリケーションソフトウェア１２０はコンピュータネットワーク１０２と共に動作するために変更する必要はない。必要なのは、サーバ１００にポートマップ１３２、ＩＰインタフェースプロセス１２６、および関連づけられたインターネットプロトコルデバイスドライバおよびハードウェアを提供することだけである。
【００２９】
次に図６を参照すると、オーディオ信号を遠隔の発呼者に再生するサーバ１００の動作が示されている。まずステップ６０２で、アプリケーションソフトウェア１２０はデータベース１１８上に格納されたオーディオファイルを開き、そのファイル内に含まれているオーディオデータをメモリバッファ内に置く。ついでステップ６０４で、アプリケーションソフトウェア１２０はＰＬＡＹ（ポート＃、バッファアドレス、バイトの数）コマンドをライブラリ１２２に送信する。これらのステップは再生コマンドが関連づけられたポートがチップリングかまたはＩＰ電話ポートのいずれであってもそれにかかわらず、アプリケーションソフトウェア１２０によって受け取られる。実際、ポートタイプはアプリケーションソフトウェア１２０にとって透過的である。ステップ６０６では、ライブラリ１２２はポートマップ１３２を参照して、再生コマンドの正しいルーティングを決定する。たとえば、再生コマンドがポートｎに関連づけられており、ポートｎがバーチャルポートマップ１３２によって物理チップリングポートに割り当てられている場合は、再生コマンドはチップリングデバイスドライバ１２４にルーティングされることになる（ステップ６０８）。ステップ６１０で、チップリングデバイスドライバ１２４は再生コマンドの一部として指定されたバッファアドレスにおいて、オーディオデータをチップリングハードウェア１１６に関連づけられたメモリ内に読み込む。チップリングハードウェア１１６はついで、オーディオデータをチップリングデバイスドライバ１２４に送信し、オーディオデータは可聴信号として、ＰＳＴＮ１０４上で確立された物理チップリング回路上で遠隔の発呼者に送信される（ステップ６１２）。ステップ６１４では、指定されたバッファアドレスにおいて含まれるすべてのデータを再生した後、チップリングデバイスドライバ１２４はＰＬＡＹ＿ＣＯＭＰＬＥＴＥ（ポートｎ）イベントをイベント待ち行列１３４内に置く。ステップ６１６では、アプリケーションソフトウェア１２０はＧＥＴ＿ＥＶＥＮＴ（）関数コールを介してＰＬＡＹ＿ＣＯＭＰＬＥＴＥ（ポートｎ）イベントを検索し、次の再生要求をライブラリ１２２に送信するか、または再生シーケンスを終了する。
【００３０】
アプリケーションソフトウェア１２０がオーディオメッセージの再生を開始するためにとるステップは、メッセージがコンピュータネットワーク１０２上で送信される場合と同じである。したがってステップ６０２では、アプリケーションソフトウェア１２０はオーディオファイルを開き、オーディオデータをそのファイルからメモリバッファの中に置く。ステップ６０４では、アプリケーションソフトウェアは再生コマンドをライブラリ１２２に送信する。再生コマンドはここでＩＰ電話ポートを参照する。ここでたとえば、コマンドはＰＬＡＹ（ポート０、バッファアドレス、バイトの数）である。ステップ６０６で、ライブラリ１２２はポートマップ１３２を参照して、再生イベントの正しい受信者を決定する。ここで、ポート０はＩＰ電話ポートであり、したがってライブラリはステップ６１８でＰＬＡＹ（ポート０、バッファアドレス、バイトの数）コマンドをＩＰインタフェースプロセス１２６に送信する。ＩＰインタフェースプロセス１２６はオーディオデータをメモリバッファから検索し、そのデータをデータパケットに置き、遠隔ＩＰエンドポイント１０６に送信する（ステップ６２０）。ステップ６２２では、オーディオデータを含むデータパケットが、ＲＴＰ／ＲＴＣＰ標準規格通信プロトコルを使用してＩＰエンドポイント１０６に送信され、ここでデータは組み立てなおされ、可聴信号として発呼者に再生される。すべてのデータパケットがＩＰエンドポイント１０６に送信されると、ＩＰインタフェースプロセス１２６はＰＬＡＹ＿ＣＯＭＰＬＥＴＥ（ポート０）イベントを発行し、そのイベントをイベント待ち行列１３４に置く（ステップ６２４）。ついでステップ６１６で、アプリケーションソフトウェア１２０はＧＥＴ＿ＥＶＥＮＴ（）関数コールを介してＰＬＡＹ＿ＣＯＭＰＬＥＴＥ（ポート０）イベントを検索し、次の再生要求を送信するか、再生シーケンスを終了する。
【００３１】
次に図７を参照すると、本発明の一実施形態による、発呼者からのオーディオ信号を記録するコマンドに応答するサーバ１００の動作が示されている。ステップ７０２では、アプリケーションソフトウェア１２０はメモリバッファを割り振り、オーディオデータを受信する。ついでステップ７０４で、アプリケーションソフトウェア１２０はＲＥＣＯＲＤ（ポート＃、バッファアドレス、バイトの数）コマンドをライブラリ１２２に送信する。オーディオデータがチップリングから記録されるかＩＰ電話ポートから記録されるかにかかわらず、これらのステップはアプリケーションソフトウェアによって行われる。ステップ７０６でライブラリ１２２はポートマップ１３２を参照して、記録イベントがルーティングされるべき場所を決定する。たとえば、記録コマンドがポートｎと関連づけられており、ポートｎはバーチャルポートマップ１３２によって物理チップリングポートに割り当てられている場合、記録コマンドはチップリングデバイスドライバ１２４にルーティングされる（ステップ７０８）。チップリングデバイスドライバ１２４はついで、バッファが一杯になるまで、またはアプリケーションソフトウェア１２０がチップリングデバイスドライバに記録を停止するように命令するまで、チップリングハードウェア１１６から着信するオーディオストリームを、割り振られたメモリバッファ内に格納する（ステップ７１０）。ステップ７１２で、記録プロセスが終わるとチップリングデバイスドライバ１２４はＲＥＣＯＲＤ＿ＣＯＭＰＬＥＴＥ（ポートｎ、＃バイト）イベントをイベント待ち行列１３４に戻す。アプリケーションソフトウェア１２０はついで、ＧＥＴ＿ＥＶＥＮＴ（）関数コールを介してＲＥＣＯＲＤ＿ＣＯＭＰＬＥＴＥ（ポートｎ、＃バイト）イベントを検索し、データベース１１８内にオーディオデータを格納する（ステップ７１４）。
【００３２】
アプリケーションソフトウェア１２０が着信オーディオデータを記録するために取るステップは、オーディオデータがネットワークインタフェース１１４において受信された場合と同じである。したがって、ステップ７０２で、アプリケーションソフトウェア１２０はメモリバッファを割り振り、オーディオデータを受信する。ステップ７０４では、アプリケーションソフトウェア１２０はＲＥＣＯＲＤ（ポート０、バッファアドレス、＃バイト）コマンド（たとえば、ポート０がＩＰ電話ポートに割り振られている場合）をライブラリ１２２に送信する。ついでステップ７０６で、ライブラリ１２２はポートマップ１３２を参照して、コマンドがルーティングされるべき場所を決定する。この例では、ポート０はＩＰ電話ポートであるので、コマンドはインタフェースプロセス１２６に向けられる（ステップ７１６）。ＩＰインタフェースプロセス１２６は、バッファが一杯になるかまたはＩＰインタフェースプロセス１２６がデータの記録を停止するように命令するまで、割り振られたメモリバッファ内に着信オーディオストリームを格納する（ステップ７１８）。ＩＰインタフェースプロセス１２６は次に、ＲＥＣＯＲＤ＿ＣＯＭＰＬＥＴＥ（ポート０、＃バイト）イベントをイベント待ち行列に戻す（ステップ７２０）。ステップ７１４でアプリケーションソフトウェア１２０は、ＧＥＴ＿ＥＶＥＮＴ（）関数コールを介してＲＥＣＯＲＤ＿ＣＯＭＰＬＥＴＥ（ポート０、＃バイト）イベントを検索し、オーディオデータをデータベース１１８内に格納する。
【００３３】
図７に関して上に与えられた例から、アプリケーションソフトウェア１２０によって行われた動作は、サーバ１００によってオーディオデータがＰＳＴＮ１０４から受信されたか、コンピュータネットワーク１０２から受信されたかにかかわらず、同じであることが理解されるであろう。唯一の違いは、格納されたオーディオデータに関連づけられたポート番号である。したがって、本発明によるサーバ１００は、インターネットなどのコンピュータネットワーク１０２上で送信された通信と共に、既存のアプリケーションソフトウェア１２０を使用することができる。
【００３４】
もちろん、上記の本発明の方法および装置に種々の変形を試みることができる。たとえば、通信サーバ１００はチップリング電話システム１０４に接続される必要はない。かかる変形も本発明の精神および範囲から離れることなく行うことができ、本発明に伴う利点を減じることがなく、かかる変形も添付の請求の範囲によってカバーされることが意図されている。
【００３５】
本発明の上記の説明は例示と説明の目的で与えられたものである。さらに、この説明は本発明をここに開示された形に限定することを意図するものではない。したがって、当該技術分野の技能と知識の範囲内で、上記の教示にしたがった変形および変更も本発明の範囲の中にある。上記に説明された実施形態はさらに、本発明を実施するにあたって現在知られている最良のモードを説明することが意図されており、当業者が、かかる実施形態または別の実施形態で、本発明の特定の用途または使用によって要求される種々の変更を伴って本発明を使用することを可能にするものである。添付の請求の範囲は、先行技術によって許可される範囲内で代替の実施形態を含むように解釈されることが意図されている。
【図面の簡単な説明】
【図１】本発明の実施形態による通信サーバおよび周囲のシステムのトポロジのブロック図である。
【図２】本発明の例示的な実施形態によるポートマップの内容を示す図である。
【図３】本発明の一実施形態による、着信呼に応答するサーバの動作を示すフローチャートである。
【図４】本発明の一実施形態による、遠隔エンドポイントからの切断信号に応答するサーバの動作を示すフローチャートである。
【図５】本発明の一実施形態による、タッチトーンイベントの受信に応答するサーバの動作を示すフローチャートである。
【図６】本発明の一実施形態による、可聴信号を発呼者に再生する（再生イベント）サーバの動作を示すフローチャートである。
【図７】本発明の一実施形態による、発呼者からの可聴信号を記録する（記録イベント）サーバの動作を示すフローチャートである。
【符号の説明】
１００  通信サーバ
１０２  コンピュータネットワーク
１０４  チャップリング電話システム
１０６  ソフトホン
１０８  電話
１１０  プロセッサ
１１２  記憶域
１１４  ネットワークインタフェース
１１６  チップリングハードウェア
１１８  データベース
１２０  音声応答アプリケーションソフトウェア
１２２  ポートインタフェースライブラリ
１２４  チップリングデバイスドライバ
１２６  インターネットプロトコル（ＩＰ）インタフェースプロセス
１２８  ＩＰ電話スタック
１３０  ＴＣＰ／ＩＰスタック
１３２  ポートマップ
１３４  イベント待ち行列
１３６  バーチャルポートマップ
２０２  通信チャネル
【図１】
0004142265.tif 000002
【図２】
0004142265.tif 000003
【図３】
0004142265.tif 000004
【図４】
0004142265.tif 000005
【図５】
0004142265.tif 000006
【図６】
0004142265.tif 000007
【図７】
0004142265.tif 000008