(57)【要約】【課題】電子的通信ダイアログの動的プログラミングおよび実行を可能にするシステムおよび方法を提供すること。【解決手段】一態様では、構成可能なメッセージング・システムが提供される。システムは、コンピュータ化ダイアログ・セッションのインターフェース・オプションを記述するための構成ファイルを含んでおり、この構成ファイルは、インターフェース・アクティビティと、この構成ファイル内のインターフェース・オプション間の状態遷移とを指定する。状態コントローラは、ダイアログ・セッションを伴う通信アクティビティ中にインターフェース・オプションを実行する。また、構成ファイルは、ユーザまたはアプリケーションに情報を請求するためのプロンプト要素を記述することもできる。【選択図】図１
2006246444.tif 000002
【特許請求の範囲】
【請求項１】
構成可能なメッセージング・システムであって、
コンピュータ化ダイアログ・セッションのインターフェースの複数のオプションを記述するための構成ファイルであって、インターフェース・アクティビティ、および前記構成ファイル内の前記インターフェースの複数のオプション間の状態遷移を指定する構成ファイルと、
前記ダイアログ・セッションを伴う通信アクティビティ中に前記インターフェースの複数のオプションを実行する状態コントローラと
を備えることを特徴とするシステム。
【請求項２】
前記構成ファイルは、少なくとも１人のユーザまたは少なくとも１つのアプリケーションに情報を請求するためのプロンプト要素を記述することを特徴とする請求項１に記載のシステム。
【請求項３】
前記構成ファイルを実行し、前記状態コントローラと対話するためのメッセージ処理コンポーネントをさらに備えることを特徴とする請求項２に記載のシステム。
【請求項４】
音声入力（speech）またはＤＴＭＦ（dual tone multi frequency）入力を受け取るためのコンポーネントをさらに備えることを特徴とする請求項１に記載のシステム。
【請求項５】
前記構成ファイルおよび前記状態コントローラは、ユニファイド・メッセージング・アプリケーションに関連付けられていることを特徴とする請求項１に記載のシステム。
【請求項６】
前記構成ファイルは、前記ダイアログ・セッションを容易にするための１つまたは複数のアクティビティ要素、１つまたは複数のプロンプト要素、および１つまたは複数の遷移要素を備えることを特徴とする請求項１に記載のシステム。
【請求項７】
前記アクティビティ要素、前記プロンプト要素、および前記遷移要素は、前記ダイアログ・セッションを生成するためにグループとして形成されることを特徴とする請求項６に記載のシステム。
【請求項８】
前記ダイアログ・セッションを運用するために構成クラスおよびアクティビティ・クラスのうちの少なくとも１つを動作させるサービスをさらに備えることを特徴とする請求項１に記載のシステム。
【請求項９】
ユーザまたはアプリケーションとの対話を容易にするための、ゲートウェイ・コンポーネント、プロトコル・コンポーネント、音声エンジン、メール・ボックス・サーバ、およびディレクトリ・サーバのうちの少なくとも１つをさらに備えることを特徴とする請求項１に記載のシステム。
【請求項１０】
前記構成ファイルと協働して前記ダイアログ・セッションを可能にするためのグローバル構成ファイルをさらに備えることを特徴とする請求項１に記載のシステム。
【請求項１１】
前記ダイアログ・セッションをサポートするための少なくとも１つの音声オブジェクトをさらに備えることを特徴とする請求項１に記載のシステム。
【請求項１２】
前記音声オブジェクトは、音声データをデジタル化音声ファイルに格納することを特徴とする請求項１１に記載のシステム。
【請求項１３】
前記構成ファイルは、ＸＭＬ（Extensible Markup language）によってプログラムされることを特徴とする請求項１に記載のシステム。
【請求項１４】
メニュー動作、ボイス・メール記録アクティビティ、ボイス・メール読み取りアクティビティ、Ｅメール読み取りアクティビティ、カレンダ読み取りアクティビティ、およびコンタクト読み取りアクティビティを制御するための少なくとも１つの機能をさらに備えることを特徴とする請求項１に記載のシステム。
【請求項１５】
請求項１の複数の構成要素を実装するためのコンピュータ可読命令を格納していることを特徴とするコンピュータ可読媒体。
【請求項１６】
メッセージング・システムを構成するための方法であって、
ユーザ用のインターフェース・アクティビティを定義する構成ファイルを作成すること、
前記構成ファイル内で、少なくとも１つのアクティビティ、プロンプト、および遷移を定義すること、
前記構成ファイルを実行すること、および
前記構成ファイル内の命令に基づいて、前記ユーザ用のインターフェース・セッションを自動的に生成すること
を備えることを特徴とする方法。
【請求項１７】
前記構成ファイルを動作させるための構成クラスまたはアクティビティ・クラスを有するサービスを生成することをさらに備えることを特徴とする請求項１６に記載の方法。
【請求項１８】
多数の自然言語オプションを有する前記構成ファイルをプログラムすることをさらに備えることを特徴とする請求項１６に記載の方法。
【請求項１９】
前記インターフェース・セッションを運用するために無線プロトコルを使用することをさらに備えることを特徴とする請求項１６に記載の方法。
【請求項２０】
ユニファイド・メッセージング・サービスを提供するシステムであって、
ユーザまたはシステム用のインターフェース・オプションを定義する手段と、
前記インターフェース・オプションに従って、アクティビティ、プロンプト、または遷移を実行する手段と、
前記アクティビティ、プロンプト、または遷移の実行時にダイアログ・セッションを運用する手段と、
前記ダイアログ・セッションから得られるデータを格納する手段と
を備えることを特徴とするシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般にコンピュータ・システムに関し、より詳細には、本発明は、柔軟的かつ細分的かつ明示的な形で、メニューのアクティビティ、プロンプト、または遷移を指定する、ハード・コード式状態機械またはドキュメント・サーバの領域外にあるファイル宣言によって、メニュー駆動式通信アプリケーションの動的構成を容易にするシステムおよび方法に関する。
【背景技術】
【０００２】
通信技術は、情報時代の急速に変化する要請の最前線にある。ほんの数年前は、ファックス装置技術が、コンテンツを電子的に符号化し、メッセージを電話回線を介して配信することにより、郵便で情報を受け取る従来の方法を脅かしていた。この技術は、数百年の間、ビジネスが行われてきた方法に革命をもたらした。ファックス装置が広く普及するようになるのとほとんど同時に、電子メールすなわちＥメールと呼ばれる新しい技術が、以前はもっぱらファックス装置の領域であった多くのアプリケーションに広がり始めた。Ｅメール・アプリケーションが発展するにつれ、さらにインスタント・メッセージ・サービスなどさらに他の通信技術が進化し、より旧式の通信形態を脅かしている。Ｅメールおよびファックス装置などのテキスト駆動式技術と共に、音声通信も、固定接続から今日のますます普及し発展している無線技術へと変化してきている。
【０００３】
多くのユーザが利用可能な広範囲の通信オプションを管理するために、ユーザが利用可能な多くの通信オプションを扱うサービスを提供するユニファイド・メッセージング（ＵＭ）アプリケーションが登場し始めた。ユニファイド・メッセージングは、通常、音声、ファックス、Ｅメールなどの統合を意味しており、選択した任意の端末から、どこでも、いつでも、これらのメッセージのいずれにも、ユーザがアクセスすることを可能にする。ユニファイド・メッセージング・システムの１つの目標は、企業または他の団体内における時間およびコストの節約を実現するために、通信プロセスを簡略化し、高速化することである。
【０００４】
現代の通信システムの共通する１つの特徴は、ユーザは、通常、特定の通信の選り好み（preferences）にこれらのシステムを合わせるために、様々なスタイル・メニューから様々な構成オプションがユーザに与えられることである。したがって、ボイス・メール、ユニファイド・メッセージング、および他の音声自動応答装置（ＩＶＲ）アプリケーションは、典型的なメニュー駆動式のユーザ・インターフェースを有する。メニューは、例えば、電話上のエンド・ユーザに対してプレイ（再生）することができる１つまたは複数のプロンプトからなる。プロンプトの終了時に、ユーザは、アプリケーションを異なるメニューに変更させるＤＴＭＦ（デュアル・トーン・マルチ・フリーケンシー）入力で応答する。現在の技術における１つの問題は、様々なアプリケーション実装で、有限状態機械を使用して、これらのメニュー変更をマッピングしていることである。通常、これらの実装形態では、メニューの状態変更をハード・コーディングしており、そのため、メニューを拡張しカスタマイズするのが困難である。
【０００５】
ハード・コード式であるという性質およびメッセージ処理用の制御要素による負担を軽減するための１つの試みとして、ＶｏｉｃｅＸＭＬ（Voice Extensible Markup Language）などの技術が出現した。ＶｏｉｃｅＸＭＬのねらいは、Ｗｅｂ開発およびコンテンツ・デリバリにおける仕事のすべてを音声応答アプリケーションに向けさせ、そのようなアプリケーションの作成者を下位レベルのプログラミングおよびリソース管理から解放することである。ＶｏｉｃｅＸＭＬは、よく知られているクライアント・サーバ・パラダイムを用いて、音声サービスをデータ・サービスと統合することを可能にする。音声サービスは、ユーザと実装プラットフォームの間における一連の対話ダイアログと見なされる。このダイアログは、ドキュメント・サーバによって提供され、このドキュメント・サーバは、それぞれの実装プラットフォームの外部に存在することができる。ドキュメント・サーバは、サービス・ロジック全体を維持し、データベースおよびレガシー・システム動作を実行し、ダイアログを生成する。
【０００６】
ＶｏｉｃｅＸＭＬドキュメント（またはアプリケーションと呼ばれる１組の関連ドキュメント）は、会話の有限状態機械の形をとる。ユーザは常に、一時に１つの会話状態あるいはダイアログにある。各ダイアログは、遷移先となる次のダイアログを決定する。遷移は、使用する次のドキュメントおよびダイアログを定義するＵＲＩで指定される。ＵＲＩがドキュメントを参照しない場合、現ドキュメントが採用される。ＵＲＩがダイアログを参照しない場合、ドキュメントの第１ダイアログが採用される。ダイアログが後続ダイアログを指定しないとき、または会話を明示的に終了する要素を有する場合、実行は終了する。
【０００７】
【非特許文献１】AADIL MANSOOR. Telephony. http://project.uet.itgo.com/telephone.htm. Last accessed January 31, 2005. 13 page.
【非特許文献２】HARRY E.BLANCHARD, et al. Voice Messaging User Interface. http://www.hblanchard.com/pubs/Blanchard_Voce_Messaging.pdf#seach='user%20interface%20dtmf%20applications%20state%20machine. Last accessed January 31, 2005.
【非特許文献３】SCOTT MCGLASHAN, et al. Voce Extensible Markup Language (VoceXML)Version 2.0 W3C Working Draft, October 23, 2001. http://www.w3.org/TR/2001/WD-voicexml120-20011023/. Last accessed January 31, 2005.
【発明の開示】
【発明が解決しようとする課題】
【０００８】
状態遷移がＶｏｉｃｅＸＭＬでどのように処理されるかに関する１つの問題は、状態変更が、ドキュメント・サーバによって取り出され新しいドキュメントを指定できることに関するものである。したがって、通常、特定のユーザとのどのような対話でも、所与のダイアログ・セッションを完了するために、ドキュメント・サーバとの多数のトランザクションを必要とする。ユーザ数が増加するにつれて、それぞれのドキュメント・サーバにかかる負荷が手に余るようになる。そのため、その負荷を処理するためにより多くのサーバを追加するなどしてリソースをさらに拡張する必要が生じることがある。ドキュメント自体内における別の非効率な点は、あるドキュメントまたはダイアログから別のドキュメントまたはダイアログに適切に遷移するために必要とされるコードを記述する量に関するものである。
【課題を解決するための手段】
【０００９】
以下の記載は、本発明のいくつかの諸態様の基礎的な理解を提供するために、本発明の簡単な概要を示している。この概要は、本発明の網羅的な概観ではない。本発明の重要／重大な要素を識別すること、あるいは本発明の範囲を規定することを意図するものでもない。その唯一の目的は、後で提示するより詳しい説明の前置きとして、本発明のいくつかの概念を簡単な形で提示することである。
【００１０】
本発明は、様々なメッセージング・アプリケーション用のメニュー駆動式アクティビティを、柔軟的かつ効率的に、制御するシステムおよび方法に関する。一態様では、構成ファイルで、通信システムにおけるダイアログ・インターフェースのアクティビティ、プロンプト、および／または遷移を指定する。これらのアクティビティおよび遷移は、構成ファイル内で明示的に呼び出され、通信システムとのユーザ対話用のダイアログ・セッションを形成する。ダイアログ中の通信オプション（例えば、ボイス・メールを残すには「１」を選択し、終了するには「２」を選択する）をユーザに提供するそれぞれのプロンプトは、構成ファイル内で指定することができる。構成ファイルの範囲内でダイアログの状態および他の状態への遷移を制御することにより、ダイアログ状態をそれぞれのユーザごとに変更する際に外部サーバとの対話を多数利用しなくても、複数のユーザとの通信インターフェースを実現することができる。
【００１１】
この構成ファイルは、システム要件が時間の経過と共に変化したとき、管理者がダイアログ・メニューを容易に適用できるようにする便利で動的な機構を提供する。例えば、この構成ファイルは、ＸＭＬなどの言語でコーディングすることができ、この構成ファイルでは、所与のインターフェースに対する変更を、必要に応じてそのダイアログに新規または異なる状態遷移をもたらす新規または異なるアクティビティとして、指定することができる。具体的な一例では、あるダイアログは、英語で提供されるダイアログ対話用のオプションを有して、最初は英語で配信することができる。そのうちに、英語以外の言語を話すユーザ用の言語インターフェース・オプションを追加することが望ましくなるかもしれない。構成ファイルが適用可能かつプログラム可能であるので、こうした変更を実装するために、管理者は、新しい言語オプションを、構成ファイル内で、基となる通信システムを改変せずに容易に指定することができる。
【００１２】
上記およびそれに関連する目的を達成するために、本発明のいくつかの例示的な諸態様を、以下の説明および添付の図面に関連して本明細書に記載する。これらの諸態様は、本発明を実施できる様々な方法を示しており、それらすべてが、本発明によって包含されることが意図されている。本発明の他の利点および新規の特徴は、本発明の以下の詳細な説明を図面と併せて考察すれば明らかになるであろう。
【発明を実施するための最良の形態】
【００１３】
本発明は、電子的通信ダイアログの動的プログラミングおよび実行を可能にするシステムおよび方法に関する。一態様では、構成可能なメッセージング・システムが提供される。そのシステムは、コンピュータ化されたダイアログ・セッションのインターフェース・オプション（例えば、ユニファイド・メッセージング・アプリケーションと対話するための電子的オプション・メニュー）を記述するための構成ファイルを含んでいる。この構成ファイルは、インターフェース・アクティビティおよび構成ファイル内のインターフェース・オプション間の状態遷移を指定し、外部の通信サーバとの不要な対話を軽減する。状態コントローラは、そのインターフェース・オプションを、ダイアログ・セッションを伴う通信アクティビティ中に実行する。また、この構成ファイルは、所与のダイアログを柔軟かつ効率的に変更できるようにする情報をユーザまたはアプリケーションに請求するためのプロンプト要素も記述する。
【００１４】
本願では、用語「コンポーネント」、「ファイル」、「システム」、「オブジェクト」、「コントローラ」などは、コンピュータ関連エンティティを指すものであり、ハードウェア、ハードウェアとソフトウェアの組合せ、ソフトウェア、または実行中ソフトウェアのいずれかである。例えば、コンポーネントは、プロセッサ上で走るプロセス、プロセッサ、オブジェクト、実行可能プログラム、実行スレッド、プログラム、および／またはコンピュータでよいが、それだけに限定されない。例をあげると、あるサーバ上で走っているアプリケーションとそのサーバの両方がコンポーネントであってよい。１つまたは複数のコンポーネントがプロセスおよび／または実行スレッドの内部に常駐でき、１つのコンポーネントを１つのコンピュータ上に局在させることも、２つ以上のコンピュータ上に分散させることもできる。また、これらのコンポーネントは、様々なデータ構造を格納した、様々なコンピュータ読み取り可能メディアから実行することもできる。コンポーネントは、１つまたは複数のデータ・パケットを有する信号（例えば、ローカル・システムや分散システム内の、かつ／またはインターネットなどのネットワークを横切って他のシステムと対話する１つのコンポーネントからの、別のコンポーネントと対話し、信号によるデータ）に従うことなどにより、ローカルおよび／またはリモートのプロセスを介して通信することができる。
【００１５】
最初に図１を参照すると、本発明の一態様による構成可能なメッセージング・システム１００が示してある。システム１００は、様々な通信アプリケーションの処理を容易にするための、１人または複数のユーザ、および／または１つまたは複数の自動化アプリケーション１２０と対話するメッセージング・コンポーネント１１０を含んでいる。メッセージング・コンポーネント１１０は、ユニファイド・メッセージング・アプリケーション、ボイス・メール処理、実質的にあらゆるタイプの音声認識アプリケーションなど、様々なアプリケーションと関連付けることができる。通常、メッセージング・コンポーネント１１０との対話は、ＤＴＭＦ（デュアル・トーン・マルチ・フリーケンシー）入力で行うが、音声入力（speech）やテキスト入力など他のタイプの入力も、同様に動作可能である。
【００１６】
一般に、構成ファイル１３０は、ユーザまたはアプリケーション１２０とのインターフェース・ダイアログ・セッション１４０を駆動する命令グループまたはコマンド・グループを格納する。このような命令またはコマンドは、ダイアログ・セッション１４０に、例えばメニューの１つまたは複数のアイテムを生成させて処理させることができ、ユーザまたはアプリケーション１２０との対話を集合的に制御する。例えば、第１アイテムが、セッションを識別する挨拶（greeting）に関連し、第２アイテムがパスワード入力を求め、第３アイテムがボイス・メール・メッセージをメッセージ・コンポーネント１１０に関連付けられたファイルに記録するよう要求することができる。以下でより詳細に述べるように、構成ファイルは、アクティビティ、プロンプト、または遷移を指定することができ、ダイアログ・セッション１４０、ならびに最終的にメッセージング・コンポーネントがどのようにユーザまたはアプリケーション１２０と対話するかを管理する。
【００１７】
構成ファイル１３０で、通常は、例えば、ダイアログ・セッション１４０でどんなアクティビティが達成されるべきか、および所与のアクティビティが完了または中止した後、どの状態に遷移すべきかを指定する。それらの状態は状態コントローラ１５０によって管理され、これはメッセージ処理コンポーネント１６０（またはサービスなどのコンポーネント）に対して、システム１００で何らかのアクション（例えば、ボイス・メールの記録、メッセージの再生、ユーザ入力の検査など）を実行するよう指令する。構成ファイル１３０は、管理者が、メッセージング・コンポーネント１１０の機能性を様々な複数の通信アプリケーションに動的に適用させることを可能にする。これは、メッセージング・コンポーネント１１０の状態を協働して制御する、ＸＭＬ（Extensible Markup Language）またはその他のタイプの言語による、ダイアログの対話またはコマンドを指定することによって実現される。この場合、構成ファイル１３０内の命令により、状態コントローラ１５０からハード・コード式の状態実装が除去され、管理者が、変更を行った後に状態コントローラを修正しなくても、変更した状況に適合できるようになる。
【００１８】
他の状態への遷移が構成ファイル１３０内に含まれているので、システム１００の適切な状態またはアクションを決定するために他のコンピュータ／コンポーネントと対話するのを軽減しながら、所与のダイアログ・セッション１４０のダイアログ制御を細分的レベルで動的に指定する（例えば、遷移を、外部のドキュメントへではなく、構成ファイル内のグループとして指定する）ことができる。したがって、本発明により、これらの諸態様を状態コントローラ１５０中でハード・コーディングするのではなく、ＸＭＬファイル（またはその他のタイプのもの）中でダイアログ・セッション１４０用のメニューおよびその遷移を構成することが容易になる。この特徴により拡張性が高まり、メッセージ・コンポーネント１１０を変更せずに新しいメニューおよび遷移を追加できるようになる。また、構成ファイル１３０により、アプリケーション開発時間が短縮され、カスタマイズが可能になり、それにより、潜在的に管理者およびエンド・ユーザが、各自のニーズに合わせて新しいメニューを追加し、既存のメニュー遷移を変更することができるようになる。他の諸態様は、メッセージ・システム１００の基となるアプリケーション実装は変更しないまま、その１つの（または複数の）構成ファイル１３０を修正するだけで、他の言語（例えば、ドイツ語、フランス語、英語など）のプロンプト、メニュー、および遷移を追加する言語サポートを含んでいる。
【００１９】
次に図２を参照すると、本発明の一態様による例示的な構成ファイル２００が示してある。一般に、構成ファイル２００は、アクティビティ要素、プロンプト要素、および遷移要素を含んでおり、これらは、２１０で示されている１つまたは複数のダイアログ・コマンド・グループ（例えば、グループ１０１、１０２、１０３など）に分けられており、これらのグループにより、通信システムまたはメッセージング・システムと対話するためのユーザ・インターフェースまたはメニューの動作が指定される。例えば、ユニファイド・メッセージングの実施例におけるＴＵＩ（電話ユーザ・インターフェース）は、以下の付録Ａにサンプル１として示すＸＭＬ構成ファイルの形に記述される。「ｉｄ」属性をもつ要素は、アクティビティを記述する。例えば、メニュー、レコードなどが、アクティビティの例である。プロンプト要素は、エンド・ユーザに対してプレイされるプロンプトを表し、一方、遷移要素は、実行される次のアクティビティおよび遷移の前に行われるアクションを記述する。
【００２０】
一般に、ダイアログ・アプリケーションの可能な一実装形態は、構成ファイル２１０内でアクティビティにマッピングされている各状態を有する状態機械を含んでいる。状態遷移は、例えば、ＸＭＬで遷移要素にマッピングすることができる。アクション属性は、状態遷移の直前に実行されるアクションを表す。また、このモデルではサブ状態機械の遷移もサポートされる。例えば、Ｒｅｃｏｒｄ  Ｖｏｉｃｅｍａｉｌは、メニューおよびレコードを含む多くのサブ・アクティビティを有する親アクティビティとすることができる。以下で付録Ａとして複製されているサンプル１で示したこの例において、ユニファイド・メッセージング・アプリケーションがエンド・ユーザから呼出しを受け取ると、（メモリに事前ロードされている）その呼出しに関するＸＭＬ構成が使用され、その呼出しに対して、アクティビティ状態機械全体を実行することができる。構成のロードがこのように呼出しごとに細分的であるので、管理者およびエンド・ユーザが他の言語を拡張し、カスタマイズし、サポートするための非常に大きな柔軟性が得られる。
【００２１】
図３に移ると、本発明の一態様による例示的なユニファイド・メッセージング・システム３００が図示してある。この例では、システム３００は、ＰＢＸ３１０およびセッション開始プロトコル（ＳＩＰ）ゲートウェイ３２０のコンテクストで、ユニファイド・メッセージング・システム３００がどのように協働するかを示している。ゲートウェイ３２０は、呼３３０（有線または無線）を、ＳＩＰプロトコルを使用してＩＰネットワーク３４０を介しユニファイド・メッセージング・システム３００に経路指定することができる。これにより、ユニファイド・メッセージング・システム３００を、ＰＢＸと同一箇所に配置しなくて済むようになる。他のコンポーネントとしては、メッセージを保存するためのメール・ボックス・サーバ３５０、およびメッセージを管理するためのアクティブ・ディレクトリ３６０が含めることができる。図示したように、ユニファイド・メッセージング・システム３００は、着呼３３０を処理するための、音声合成（Text-to-Speech：ＴＴＳ）や音声認識（speech recognition）エンジン３７０などのコンポーネントを含むことができ、ＤＴＭＦ制御など他のタイプのコンポーネントを備えることもできる。以下により詳しく説明するように、構成ファイルをロードし実行して、呼３３０を生成するユーザ（またはアプリケーション）と対話するためのインターフェース・セッションを生成する、ユニファイド・メッセージング・サービスまたはサービス（図示せず）を提供することもできる。これには、システム３００の状態動作を管理する様々なオブジェクトおよびクラスの動作を含めることができる。
【００２２】
図４および５は、本発明の一態様による、呼を管理するための例示的なサービス方法を示す。説明を簡単にするために、この方法を、一連のまたはいくつかの動作として示し説明するが、いくつかの動作は、本発明によれば、本明細書で示し説明したのとは異なる順序でかつ／またはそれとは異なる他の動作と同時に行われるので、本発明は動作の順序によって制限されないことを理解し認識されたい。例えば、ある方法は、その代案として、状態図などで、一連の相互に関連した状態またはイベントとして提示することもできることが、当業者には理解され認識されよう。さらに、本発明による方法を実装するために、必ずしも図示した動作のすべてが必要でないこともある。
【００２３】
図４は、サービスの開始時に発呼者と対話するサービス用のコール・フロー４００を示す。４１０に進み、この処理で、グローバル構成ＸＭＬファイルおよびユニファイド・メッセージング構成ＸＭＬファイルを読み取り、次いでユニファイド・メッセージング構成クラスに値を設定する。４２０で、所与のマシンで利用可能なソフトウェア・トランク（software trunk）の数が決定され取り出される。それぞれのトランクは、所与の発呼者に関連付けられている。４３０で、４２０に記載された各トランクについて、以下の処理を実行することができ、４４０にそれを示してある。  
ａ．新しいスレッドを作成する。  
ｂ．新しいスレッド内でＶｏｉｃｅ  Ｏｂｊｅｃｔを作成し、そのオブジェクトを初期化する。  
ｃ．Ｏｎ  Ｉｎｃｏｍｉｎｇ  Ｃａｌｌイベント・ハンドラを登録する。  
ｄ．サービス・アプリケーションを実行して、それぞれの呼を処理する。一般に、この処理は、そのスレッドで待機する。これにより、そのスレッド上で呼を処理するためのアプリケーション・メッセージ・ループを開始し、イベント・コールバックが同じスレッド上で実行されることが容易になる。
【００２４】
図５は、着呼の処理時に発呼者と対話するサービス用のコール・フロー５００を示す。図５の５１０に進み、このサービスは、Ｖｏｉｃｅ  Ｏｂｊｅｃｔを作成したのと同じスレッド上で、（図４に関して上述した）開始時に登録されたＯｎ  Ｉｎｃｏｍｉｎｇ  Ｃａｌｌを呼び出す。５２０で、発呼者、被発呼者、および／または他のタイプの呼情報が取り出され、Ｖｏｉｃｅ  ＯｂｊｅｃｔのＣａｌｌ  Ｃｏｎｔｅｘｔが初期化される。５３０で、ユニファイド・メッセージング構成ファイルからの第１のＡｃｔｉｖｉｔｙ  Ｉｄが読み取られ、このプロセスは、そのＡｃｔｉｖｉｔｙ  ＩｄからＡｃｔｉｖｉｔｙを作成する。５４０で、Ａｃｔｉｖｉｔｙ．ＯｎＳｔａｒｔ関数が実行され、これは、上述のグローバル構成ファイルおよび／またはユニファイド・メッセージング構成ファイルのコンテンツに基づいて、発呼者とのダイアログの実行を開始する。ユニファイド・メッセージング構成ファイル内のアクティビティ構成に基づいて、ＯｎＳｔａｒｔ関数が、Ｖｏｉｃｅ  Ｏｂｊｅｃｔにおける関数の１つ（例えば、Ｐｌａｙ  Ｐｒｏｍｐｔ、Ｒｅｃｏｒｄ  Ｆｉｌｅなど）を非同期的に実行し、次いでそれぞれのスレッドを終了する。５５０で、Ｖｏｉｃｅ  Ｏｂｊｅｃｔタスクが完了した後、例えば、ＯｎＤｔｍｆIｎｐｕｔ／ＯｎＰｒｏｍｐｔＣｏｍｐｌｅｔｅ／ＯｎＲｅｃｏｒｄＣｏｍｐｌｅｔｅ／ＯｎＵｓｅｒＨａｎｇｕｐ／ＯｎＴｉｍｅｏｕｔなどの関数が呼び出される。このコールバックにより、ユニファイド・メッセージング構成ファイルに基づく新しいＡｃｔｉｖｉｔｙが作成される。この新しいＡｃｔｉｖｉｔｙがヌルであることが検出された場合は、５５０でその呼を切断することができ、そうでない場合は、そのプロセスは、５４０に戻って新しいアクティビティを実行することができることに留意されたい。
【００２５】
図６は、本発明の一態様による、呼を処理するための例示的なサービス・クラス６００を示す。この態様では、メッセージ・サービス・クラス６００は、着呼を処理すると共に、メッセージ・システムとのユーザまたはアプリケーションの対話用インターフェースを制御する、コンポーネントを初期化し、生成し、それとの対話を終了する責任を負う。サービス・クラス６００の諸側面には、呼をサービスするオブジェクトを初期化するための入力点６１０が含まれる。６２０で、サービス・クラスは開始点を含んでおり、それによって構成ファイルを読み取り、少なくとも部分的にそのファイルに基づくアクティビティを開始することができる。６３０で、メッセージ・クラス６００は、所与の発呼者またはトランクとのアクティビティを終了するシャットダウン・ロジックの呼出しなど、サービスの完了時に実行されるメソッドを使用する。以下のコードは、例示的なサービス・クラス６００を示す。
【００２６】
【表１】
2006246444.tif 000003
【００２７】
以下は、上記のサンプル２の和訳である。  
このクラスはサービスのためにスタート・アップとシャット・ダウン・コードを実装する。  
公開のクラスUMService：System.ServiceProcess.ServiceBase   
{  
///トップ・レベル・アクティビティ・コンフィギュレーション  
内部の静的なActivityConfigList umconfig = null；  
//<要約>  
/// services.mscによって呼び出されたUMのサービス用のコンストラクタ。  
///</要約>  
公開のUMService()；  
///<要約>  
/// サービスがサービスMSCからを起動したときの入口点  
///</要約>  
保護されたオーバーライド・ボイドのOnStart（string[] args）  
{  
1. グローバルな構成ファイルを読む。  
2. UMの構成ファイルを読み、umconfigオブジェクトを構築する。  
3. IncomingCallControlオブジェクトの作成  
4. IncomingCallControlによってコールバックとしてIncomingCallHandlerを登録する。  
5. IncomingCallControl.Startを呼び出す  
}  
///<要約>  
/// サービスがサービスMSCから停止したときの入口点  
///</要約>  
保護されたオーバーライド・ボイドOnStop()  
{  
1. IncomingCallControl.Shutdownを呼び出す  
}  
///<要約>  
/// コールをゲートウェイから受けたときの入口点  
///</要約>  
静的ボイドのIncomingCallHandler(VoiceObject voiceObject)  
{  
1. 初期のアクティビティを(構成に基づいて)作成する。  
2. イニシャルActivity.Startを呼び出す  
}  
}
【００２８】
図７は、本発明の一態様による、呼を処理するための例示的な構成クラス７００を示す。クラス７００を使用して、構成ファイルをメモリに格納することができる。このファイル内の各アクティビティは、例えば、再生すべきプロンプト、予想されるＤＴＭＦ、ＤＴＭＦ入力時にとるべきアクション、およびＤＴＭＦ入力時に進むべき次のアクティビティを含んでいる。Ｒｅａｄ  Ｖｏｉｃｅ  ｍａｉｌのようないくつかのアクティビティは、それ自体の１組のアクティビティを含んでいる。クラス７００は、Ａｃｔｉｖｉｔｙ  Ｃｏｎｆｉｇｕｒａｔｉｏｎクラスの継承階層を示す。
【００２９】
Ａｃｔｉｖｉｔｙ  Ｃｏｎｆｉｇは、アクティビティ構成の基本クラスである。これには、可能なイベント、ならびに特定のアクティビティのそのイベントの次のＡｃｔｉｖｉｔｙ用のハッシュ・テーブルが格納される。これは、構成ファイルに基づいている。以下のコード例は、例示的な構成クラス７００を示している。
【００３０】
【表２】
2006246444.tif 000004
【００３１】
【表３】
2006246444.tif 000005
【００３２】
以下は、上記のサンプル３の和訳である。  
///<要約>  
/// アクティビティ構成用のベース・クラス  
///</要約>  
内部の抽象型クラスActivityConfig  
{  
保護ストリング  activityId；  
/// このアクティビティ保護されたActivityConfigList peerActivitiesへのすべてのアクティビティ・ピア；  
/// DTMFとNextActivity間にマッピングを含む  
/// NextActivityはActivityConfigListへの参照である  
保護されたHashtable  activityDtmfMap；  
///<要約>  
// アクティビティidを得る  
///</要約>  
内部のストリングActivityId  
{  
{このactivityIdを戻す；｝を得る  
}  
///<要約>  
/// 次のアクティビティを、このアクティビティのDTMF電話番号に基づいて得る  
///</要約>  
内部のNextActivity GetNextActivityId(string tmfDigits)；  
///<要約>  
/// アクティビティconfigのためのコンストラクタ  
///</要約>  
内部のActivityConfig(ActivityConfigList config, string activityId)；  
// アクティビティのXMLを解析し、存在する場合にactivityDtmfMap、プロンプト、およびサブ・アクティビティなどのすべてのフィールドを取り込む  
// UmConfig.Parseから呼ばれる  
内部の抽象ボイドのLoad(XmlNode rootNode)；  
// このActivityConfigに対応するNewActivityオブジェクトを作成し、戻る  
内部の抽象のActivity CreateNewActivity()；  
///<要約>  
// アクティビティ・ノードをactivityDtmfMapに追加する機能。これはLoadで使用される。  
//</要約>  
私用のボイドAddActivityNode(XmlNode nodeCurrent)；  
}
【００３３】
以下は、例示的なユニファイド・メッセンジャー・サービスによって実装される様々なアクティビティ構成である。  
１．ＭｅｎｕＣｏｎｆｉｇ：これは、このアクティビティ用のＸＭＬに基づくプロンプトも格納している。  
２．ＲｅｃｏｒｄＶｍａｉｌＣｏｎｆｉｇ：これは、このＡｃｔｉｖｉｔｙにとってローカルなＡｃｔｉｖｉｔｙＣｏｎｆｉｇを含むＡｃｔｉｖｉｔｙＣｏｎｆｉｇＬｉｓｔへの参照も格納している。  
３．ＲｅａｄＶｍａｉｌＣｏｎｆｉｇ：これは、このＡｃｔｉｖｉｔｙにとってローカルなＡｃｔｉｖｉｔｙＣｏｎｆｉｇを含むＡｃｔｉｖｉｔｙＣｏｎｆｉｇＬｉｓｔへの参照も格納している。  
４．ＲｅａｄＥｍａｉｌＣｏｎｆｉｇ：これは、このＡｃｔｉｖｉｔｙにとってローカルなＡｃｔｉｖｉｔｙＣｏｎｆｉｇを含むＡｃｔｉｖｉｔｙＣｏｎｆｉｇＬｉｓｔへの参照も格納している。  
５．ＲｅａｄＣａｌｅｎｄａｒＣｏｎｆｉｇ：これは、このＡｃｔｉｖｉｔｙにとってローカルなＡｃｔｉｖｉｔｙＣｏｎｆｉｇを含むＡｃｔｉｖｉｔｙＣｏｎｆｉｇＬｉｓｔへの参照も格納している。  
６．ＲｅａｄＣｏｎｔａｃｔｓＣｏｎｆｉｇ：これは、このＡｃｔｉｖｉｔｙにとってローカルなＡｃｔｉｖｉｔｙＣｏｎｆｉｇを含むＡｃｔｉｖｉｔｙＣｏｎｆｉｇＬｉｓｔへの参照も格納している。
【００３４】
図８は、本発明の一態様による、呼を処理するための例示的なアクティビティ・クラス８００を示す。呼がユニファイド・メッセージング・サービスに入ってきたとき、それを状態機械で扱うことができ、この状態機械は、上述の構成ファイルに基づいて１つの状態から別の状態に移行する。この機械の状態は、再生すべきプロンプトまたはとるべきアクションを決定する音声フォームである。イベントは、エンド・ユーザからのＤＴＭＦまたは音声入力（speech）、あるいはメールの終了などの内部イベントとすることができる。
【００３５】
アクティビティ・クラス８００は、状態機械の１つの状態を実装している。これは、アクティビティの基本クラスである。
【００３６】
【表４】
2006246444.tif 000006
【００３７】
以下は、上記のサンプル４の和訳である
内部の抽象のクラス・アクティビティ  
{  
// アクション実行中に生成されるイベント  
保護されたストリングautoEvent；  
内部のActivity()；  
内部の抽象ボイドOnStart(VoiceObject voiceObject)；  
内部の抽象のボイドOnDtmfInput(VoiceObject voiceObject)；  
内部の抽象のボイドOnUserHangup(VoiceObject voiceObject)；  
内部の抽象のボイドOnPromptComplete(VoiceObject voiceObject)；  
内部の抽象のボイドOnRecordComplete(VoiceObject voiceObject)；  
内部の抽象のボイドOnTimeout(VoiceObject voiceObject)；  
保護されたボイドExecuteNextAction(string action, VoiceObject voiceObject)  
{  
1. それに渡されたアクションに基づいた適切なアクションを実行する。  
2. これは、アクション実行中に、autoEventを生成することができる。  
}  
}
【００３８】
以下は、このサービスによって実装される様々なアクティビティである。これらは、対応するＡｃｔｉｖｉｔｙ  Ｃｏｎｆｉｇクラスへの参照を有し、その参照をコンストラクタに渡すことができる。  
１．Ｍｅｎｕ  Ａｃｔｉｖｉｔｙ：プロンプトを再生し、およびユーザ入力（ＤＴＭＦまたは音声（speech））を待つために、使用される。これは、基本アクティビティである。  
２．ＲｅｃｏｒｄＶｍａｉｌ  Ａｃｔｉｖｉｔｙ：音声メッセージを記録するために必要とされる１組のアクティビティを維持する。  
３．ＲｅａｄＶｍａｉｌ  Ａｃｔｉｖｉｔｙ：ボイス・メールを読み取るために必要とされる１組のアクティビティを維持する。  
４．ＲｅａｄＥｍａｉｌ  Ａｃｔｉｖｉｔｙ：メールを読み取るために必要とされる１組のアクティビティを維持する。  
５．ＲｅａｄＣａｌｅｎｄａｒ  Ａｃｔｉｖｉｔｙ：カレンダを読み取るために必要とされる１組のアクティビティを維持する。  
６．ＲｅａｄＣｏｎｔａｃｔｓ  Ａｃｔｉｖｉｔｙ：コンタクトを読み取るために必要とされる１組のアクティビティを維持する。
【００３９】
図９を参照すると、本発明の様々な諸態様を実装するための例示的な環境９１０は、コンピュータ９１２を含んでいる。コンピュータ９１２は、処理ユニット９１４、システム・メモリ９１６、およびシステム・バス９１８を備える。システム・バス９１８は、それだけに限定されないが、システム・メモリ９１６を含むがシステム・コンポーネントを、処理ユニット９１４に結合する。処理ユニット９１４は、様々な利用可能なプロセッサのどれでもよい。処理ユニット９１４として、デュアル・マイクロ・プロセッサおよびその他のマイクロプロセッサ・アーキテクチャを使用することもできる。
【００４０】
システム・バス９１８は、利用可能な多種多様なバス・アーキテクチャを使用する、メモリ・バスまたはメモリ・コントローラ、周辺バスまたは外部バス、および／またはローカル・バスを含めた、いくつかのタイプのバス構造のどれでもよい。この利用可能なバス・アーキテクチャには、１１ビット・バス、ＩＳＡ（Industrial Standard Architecture）、ＭＣＡ（Micro-Channel Architecture）、ＥＩＳＡ（Extended ISA）、ＩＤＥ（Intelligent Drive Electronics）、ＶＬＢ（VESA Local Bus）、ＰＣＩ（Peripheral Component Interconnect）、ＵＳＢ（Universal Serial Bus）、ＡＧＰ（Advanced Graphics Port）、ＰＣＭＣＩＡ（Personal Computer Memory Card International Association bus）、およびＳＣＳＩ（Small Computer Systems Interface）が含まれるが、それだけには限定されない。
【００４１】
システム・メモリ９１６は、揮発メモリ９２０および非揮発メモリ９２２を含んでいる。基本入出力システム（ＢＩＯＳ）は、起動時などにコンピュータ９１２内の構成要素間で情報を転送する基本ルーチンを含んでおり、非揮発メモリ９２２に格納される。例をあげると、非揮発メモリ９２２には、読取り専用メモリ（ＲＯＭ）、ＰＲＯＭ（プログラマブルＲＯＭ）、ＥＰＲＯＭ（電気的プログラマブルＲＯＭ）、ＥＥＰＲＯＭ（電気的消去可能ＲＯＭ）、またはフラッシュ・メモリを含むことができるが、それだけに限定されない。揮発メモリ９２０には、外部キャッシュ・メモリとして動作するランダム・アクセス・メモリ（ＲＡＭ）が含まれ得る。例えば、ＲＡＭは、ＳＲＡＭ（同期ＲＡＭ）、ＤＲＡＭ（ダイナミックＲＡＭ）、ＳＤＲＡＭ（同期ＤＲＡＭ）、ＤＤＲ  ＳＤＲＡＭ（ダブル・データ・レートＳＤＲＡＭ）、ＥＳＤＲＡＭ（拡張ＳＤＲＡＭ）、ＳＬＤＲＡＭ（Ｓｙｎｃｈｌｉｎｋ  ＤＲＡＭ）、およびＤＲＲＡＭ（direct Rambus RAM）など多くの形で利用可能であるが、それだけに限定されない。
【００４２】
コンピュータ９１２は、取り外し可能／取り外し不能な、揮発性／非揮発性のコンピュータ記憶媒体も備える。図９は、例としてディスク記憶装置９２４を示している。ディスク記憶装置９２４には、磁気ディスク装置、フロッピー（登録商標）ディスク装置、テープ装置、Ｊａｚドライブ、Ｚｉｐドライブ、ＬＳ−１００ドライブ、フラッシュ・メモリ・カード、またはメモリー・スティックのような装置が含まれるが、それだけには限定されない。さらに、ディスク記憶装置９２４には、個別のまたは他の記憶媒体と組み合わせた記憶媒体を含むことができる。この記憶媒体には、ＣＤ−ＲＯＭ（コンパクトディスクＲＯＭ）装置、ＣＤ−Ｒ（CD recordable）ドライブ、ＣＤ−ＲＷ（CD rewritable）ドライブ、またはＤＶＤ−ＲＯＭ（digital versatile disk ROM）ドライブなどの光ディスク・ドライブが含まれるが、それだけには限定されない。ディスク記憶装置９２４をシステム・バス９１８に接続するのを容易にするために、インターフェース９２６など、取り外し可能または取り外し不能なインターフェースが通常は使用される。
【００４３】
図９は、ユーザと、適切な動作環境９１０で示されている基本コンピュータ・リソースとの間の仲介役として働くソフトウェアを示していることを理解されたい。そのようなソフトウェアには、オペレーティング・システム９２８が含まれる。オペレーティング・システム９２８は、ディスク記憶装置９２４に格納することができ、コンピュータ・システム９１２の資源を制御し割り当てるように動作する。システム・アプリケーション９３０は、システム・メモリ９１６またはディスク記憶装置９２４に格納されたプログラム・モジュール９３２およびプログラム・データ９３４によって、オペレーティング・システム９２８による資源管理を利用する。様々なオペレーティング・システムまたはオペレーティング・システムの組合せを用いて本発明を実施できることを理解されたい。
【００４４】
ユーザは、入力装置９３６によってコマンドまたは情報をコンピュータ９１２に入力する。入力装置９３６には、マウス、トラックボール、スタイラス、タッチパッドなどのポインティング装置、キーボード、マイク、ジョイスティック、ゲームパッド、衛星放送用パラボラ・アンテナ、スキャナ、ＴＶチューナ・カード、デジタル・カメラ、デジタル・ビデオ・カメラ、Ｗｅｂカメラなどが含まれるが、それだけには限定されない。これらその他の入力装置は、インターフェース・ポート９３８を経由しシステム・バス９１８を介して処理ユニット９１４に接続される。インターフェース・ポート９３８には、例えば、シリアル・ポート、パラレル・ポート、ゲームポート、およびＵＳＢ（universal serial bus）が含まれる。出力デバイス９４０は、入力装置９３６と同じタイプのポートをいくつか使用する。したがって、例えば、ＵＳＢポートを使用して、コンピュータ９１２に入力を提供し、コンピュータ９１２からの情報を他の出力デバイス９４０に出力することができる。出力装置９４０の中でもとりわけ、特別なアダプタの必要なモニタ、スピーカ、およびプリンタのようないくつかの出力デバイスがあることを示すために、出力アダプタ９４２が提供されている。出力アダプタ９４２には、例をあげると、出力デバイス９４０とシステム・バス９１８の間の接続手段を提供するビデオ・カードおよびサウンド・カードが含まれるが、それだけには限定されない。他の装置および／または装置システムは、リモート・コンピュータ９４４などの入力機能と出力機能の両方を提供することに留意されたい。
【００４５】
コンピュータ９１２は、リモート・コンピュータ９４４など１つまたは複数のリモート・コンピュータとの論理接続を使用するネットワーク化された環境で、動作することができる。リモート・コンピュータ９４４は、パーソナル・コンピュータ、サーバ、ルータ、ネットワークＰＣ、ワークステーション、マイクロ・プロセッサ・ベースの機器、ピア装置、またはその他の一般的なネットワーク・ノードなどとすることができ、通常は、コンピュータ９１２に関して述べた要素の多くまたはすべてが含まれる。簡潔のために、リモート・コンピュータ９４４と共に記憶装置９４６だけが示してある。リモート・コンピュータ９４４は、ネットワーク・インターフェース９４８を介して論理的にコンピュータ９１２に接続され、次に通信接続９５０を介して物理的に接続される。ネットワーク・インターフェース９４８には、ローカル・エリア・ネットワーク（ＬＡＮ）やワイド・エリア・ネットワーク（ＷＡＮ）などの通信ネットワークが含まれる。ＬＡＮ技術には、ＦＤＤＩ（Fiber Distributed Data Interface）、ＣＤＤＩ（Copper Distributed Data Interface）、イーサネット（登録商標）／ＩＥＥＥ８０２．３、トークン・リング／ＩＥＥＥ８０２．５などが含まれる。ＷＡＮ技術には、二地点間リンク、ＩＳＤＮ（Integrated Services Digital Networks）およびその変形のような回路交換ネットワーク、パケット交換ネットワーク、およびデジタル加入者線（ＤＳＬ）が含まれるが、それだけに限定されない。
【００４６】
通信接続９５０は、ネットワーク・インターフェース９４８をバス９１８に接続するのに使用されるハードウェア／ソフトウェアを指す。通信接続９５０は、分かりやすくするためにコンピュータ９１２の内部に示してあるが、コンピュータ９１２の外部であってもよい。ネットワーク・インターフェース９４８に接続するのに必要なハードウェア／ソフトウェアには、例示のためにすぎないが、通常の電話級モデム、ケーブル・モデム、およびＤＳＬモデムを含めたモデム、ＩＳＤＮアダプタ、およびイーサネット（登録商標）カードなどの内部技術および外部技術が含まれる。
【００４７】
図１０は、本発明が対話できるサンプル・コンピューティング環境１０００の概略ブロック図である。システム１００は、１つまたは複数のクライアント１０１０を含んでいる。クライアント１０１０は、ハードウェアおよび／またはソフトウェア（例えば、スレッド、プロセス、コンピューティング装置）とすることができる。また、システム１０００は、１つまたは複数のサーバ１０３０も含んでいる。また、サーバ１０３０は、ハードウェアおよび／またはソフトウェア（例えば、スレッド、プロセス、コンピューティング装置）とすることができる。サーバ１０３０は、例えば本発明を使用することによって変換を実行するスレッドを収容することができる。クライアント１０１０とサーバ１０３０の間における１つの可能な通信は、２つまたは複数のコンピュータ・プロセスの間で伝送されるように適合されたデータ・パケットの形とすることができる。システム１０００は、通信フレームワーク１０５０を含んでおり、それを使用して、クライアント１０１０とサーバ１０３０の間の通信を容易にすることができる。クライアント１０１０は、１つまたは複数のクライアント・データ記憶装置１０６０に動作可能に接続され、それをクライアント１０１０にとってローカルな情報を格納するために使用することができる。同様に、サーバ１０３０は、１つまたは複数のサーバ・データ記憶装置１０４０に接続され動作可能になっており、それをサーバ１０３０にとってローカルな情報を格納するために使用することができる。
【００４８】
以上の説明は、本発明のいくつかの例を含んでいる。本発明を説明するための構成要素または方法の、考え得るすべての組合せを説明することはもちろんできないが、本発明の多くのさらなる組合せおよび変更が可能であることが当業者には理解できよう。したがって、本発明は、特許請求の範囲の趣旨および範囲に含まれる、そのようなすべての改変、修正、および変形を包含するものである。さらに、用語「含む（includes）」が、詳細説明または特許請求の範囲のいずれかで使用される限り、かかる用語は、「備える（comprising）」が特許請求の範囲で移行語（transitional word）として使用されるときに解釈されるように、用語「備える」と同様に包含的なものである。
【００４９】
【表５】
2006246444.tif 000007
【００５０】
【表６】
2006246444.tif 000008
【００５１】
【表７】
2006246444.tif 000009
【００５２】
【表８】
2006246444.tif 000010
【図面の簡単な説明】
【００５３】
【図１】本発明の一態様による構成可能なメッセージング・システムを示す概略ブロック図である。
【図２】本発明の一態様による例示的な構成ファイルを示すブロック図である。
【図３】本発明の一態様による例示的なユニファイド・メッセージング・システムを示す図である。
【図４】本発明の一態様による呼出しアクティビティを管理する例示的なサービス・プロセスを示す流れ図である。
【図５】本発明の一態様による呼出しアクティビティを管理する例示的なサービス・プロセスを示す流れ図である。
【図６】本発明の一態様による呼出しを処理する例示的なサービス・クラスを示す図である。
【図７】本発明の一態様による呼出しを処理する例示的な構成クラスを示す図である。
【図８】本発明の一態様による呼出しを処理する例示的なアクティビティ・クラスを示す図である。
【図９】本発明の一態様による適切な動作環境を示す概略ブロック図である。
【図１０】本発明が対話することのできるサンプル・コンピューティング環境の概略ブロック図である。
【符号の説明】
【００５４】
１００    メッセージング・システム
１１０    メッセージング・コンポーネント
１２０    ユーザまたはアプリケーション
１３０    構成ファイル
１４０    インターフェース・ダイアログ・セッション
１５０    状態コントローラ
１６０    メッセージ処理
２００    構成ファイル
２１０    ダイアログ・コマンド・グループ
３００    ユニファイド・メッセージング・システム
３２０    ゲートウェイ
３３０    コール（呼）
３４０    ＩＰネットワーク
３５０    交換メール・ボックス・サーバ
３６０    アクティブ・ディレクトリ
３７０    ＴＴＳおよび音声認識エンジン
４００    サービスの開始時に発呼者と対話するサービス用のコール・フロー
５００    着呼の処理時に発呼者と対話するサービス用のコール・フロー
６００    メッセージ・サービス・クラス
６１０    入口
６２０    開始
６３０    停止
７００    呼を処理するための例示的な構成クラス
８００    呼を処理するための例示的なアクティビティ・クラス
９１０    例示的な環境
９１２    コンピュータ
９１４    処理ユニット
９１６    システム・メモリ
９２０    揮発
９２２    非揮発
９２４    ディスク記憶装置
９２６    インターフェース
９２８    オペレーティング・システム
９３０    アプリケーション
９３２    モジュール
９３４    データ
９３６    入力デバイス
９３８    インターフェース・ポート
９４０    出力デバイス
９４２    出力アダプタ
９４４    リモート・コンピュータ
９４６    記憶装置
９４８    ネットワーク・インターフェース
９５０    通信接続
１０００    サンプル・コンピューティング環境
１０１０    クライアント
１０３０    サーバ
１０４０    サーバ・データ記憶装置
１０５０    通信フレームワーク
１０６０    クライアント・データ記憶装置
【図１】
2006246444.tif 000011
【図２】
2006246444.tif 000012
【図３】
2006246444.tif 000013
【図４】
2006246444.tif 000014
【図５】
2006246444.tif 000015
【図６】
2006246444.tif 000016
【図７】
2006246444.tif 000017
【図８】
2006246444.tif 000018
【図９】
2006246444.tif 000019
【図１０】
2006246444.tif 000020