(57)【要約】【課題】  音声サービスを容易にするためのプロトコルを確立するやり方を提供すること。【解決手段】  本発明は、クライアントとサーバの間でメディア・チャネルおよびシグナリング・チャネルを確立することに関する。メディア・チャネルは、通信のために選択されたコーデックおよびプロトコルを使用する。メディア・チャネルおよびシグナリング・チャネルを介して、クライアント上のアプリケーションは、サーバ上の音声サービスを使用することができる。【選択図】  図６
2006121673.tif 000002
【特許請求の範囲】
【請求項１】
クライアントとサーバの間で通信する方法であって、
メディア・チャネルを確立すること、
シグナリング・チャネルを確立すること、および
前記メディア・チャネルおよび前記シグナリング・チャネルのうちの少なくとも１つを介して、前記クライアントと前記サーバの間で情報を交換すること
を備えることを特徴とする方法。
【請求項２】
前記メディア・チャネルの確立は、コーデックおよびプロトコルを確立することをさらに備えることを特徴とする請求項１に記載の方法。
【請求項３】
前記情報を交換することは、セッション開始プロトコル（ＳＩＰ）環境内で実施されることを特徴とする請求項１に記載の方法。
【請求項４】
前記情報を交換することは、ウェブ・サービス環境内で実施されることを特徴とする請求項１に記載の方法。
【請求項５】
前記メディア・チャネルの確立は、前記メディア・チャネル用に使用されるコーデックおよびプロトコルを提案することを含むことを特徴とする請求項１に記載の方法。
【請求項６】
前記メディア・チャネルの確立は、インターネット・プロトコル・アドレス、および前記インターネット・プロトコル・アドレスに関連するポートを宣言することを含むことを特徴とする請求項１に記載の方法。
【請求項７】
前記メディア・チャネルを確立するために使用される、少なくとも１つのコーデックおよび少なくとも１つのプロトコルのリストを提供することをさらに備えることを特徴とする請求項１に記載の方法。
【請求項８】
前記メディア・チャネルを確立するために前記リストを参照することをさらに備えることを特徴とする請求項７に記載の方法。
【請求項９】
前記情報を交換することは、前記メディア・チャネルを介して音声データを送信することを含むことを特徴とする請求項１に記載の方法。
【請求項１０】
音声サービスを提供するための命令を含むコンピュータ読取り可能媒体であって、前記命令は、
確立されたシグナリング・プロトコルに従って、シグナリング・チャネルを介してシグナリング情報を受信すること、
確立されたコーデックおよびプロトコルに従って、メディア・チャネルを介して音声情報を受信すること、および
前記シグナリング情報および前記音声情報を処理すること
を備えることを特徴とするコンピュータ読取り可能媒体。
【請求項１１】
前記命令は、前記音声情報に対して音声認識を実施することをさらに備えることを特徴とする請求項１０に記載のコンピュータ読取り可能媒体。
【請求項１２】
前記命令は、セッション開始プロトコル（ＳＩＰ）環境内でセッションを確立することをさらに備えることを特徴とする請求項１０に記載のコンピュータ読取り可能媒体。
【請求項１３】
前記シグナリング情報および前記音声情報の処理は、ウェブ・サービス環境内で実施されることを特徴とする請求項１０に記載のコンピュータ読取り可能媒体。
【請求項１４】
前記命令は、コンピュータ支援通信アプリケーション（ＣＳＴＡ）インターフェースを提供することをさらに備えることを特徴とする請求項１０に記載のコンピュータ読取り可能媒体。
【請求項１５】
前記命令は、単純オブジェクト・アクセス・プロトコル（ＳＯＡＰ）メッセージを解釈することをさらに備えることを特徴とする請求項１０に記載のコンピュータ読取り可能媒体。
【請求項１６】
前記命令は、前記音声情報を処理して、そこに含まれる意味論情報を識別することをさらに備えることを特徴とする請求項１０に記載のコンピュータ読取り可能媒体。
【請求項１７】
前記命令は、インターネット・プロトコル（ＩＰ）アドレスに関連する指定されたポートに情報を送信することをさらに備えることを特徴とする請求項１０に記載のコンピュータ読取り可能媒体。
【請求項１８】
前記命令は、単純オブジェクト・アクセス・プロトコル（ＳＯＡＰ）メッセージを送信することをさらに備えることを特徴とする請求項１０に記載のコンピュータ読取り可能媒体。
【請求項１９】
コンピュータ・ネットワーク上の情報を処理するための方法であって、
ＳＩＰ環境およびウェブ・サービス環境のうちの１つの環境内で、クライアントとサーバの間の関係を確立すること、
指定されたプロトコルに従って前記クライアントから前記サーバに、オーディオ・データまたはテキスト・データを含むデータを送信すること、
前記データがオーディオ・データである場合は、前記データをオーディオ・データからテキスト・データに、また前記データがテキスト・データである場合は、テキスト・データからオーディオ・データに変換すること、および
前記指定されたプロトコルに従って、変換された前記データを前記サーバから前記クライアントに送信すること
を備えることを特徴とする方法。
【請求項２０】
前記指定されたプロトコルは、ＣＳＴＡ（コンピュータ支援通信アプリケーション）に基づくことを特徴とする請求項１９に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータ・インタラクションを定義し、処理するための方法およびシステムに関する。詳細には、本発明は、通信システムなどのシステム内の装置間で通信プロトコルを確立するための方法およびシステムに関する。
【背景技術】
【０００２】
本出願は、２００４年１０月２２日に出願した米国仮特許出願第６０／６２１３０３号の優先権を主張するものである。同特許の内容全体は、参照により本明細書中に組み込まれる。
【０００３】
コンピュータ支援通信アプリケーション（ＣＳＴＡ：Computer Supported Telecommunication Application）は、グローバルな、企業向け通信のために広く採用されている標準スイート（standard suite）である。具体的には、ＣＳＴＡは、通信基盤のプログラマティックなアクセスおよび制御について指定する規格である。ソフトウェアは、単純な通話の開始および受信から、音声およびビデオを介した大規模なマルチ・サイト連携の管理にまで及ぶ幅広い種類の課題のために開発される可能性がある。
【０００４】
ＣＳＴＡは、複数のＥＣＭＡ／ＩＳＯ規格において標準化されている（非特許文献１参照）。ＣＳＴＡオブジェクト、サービスおよびイベントの中核の操作モデルおよび意味論は、ＥＣＭＡ−２６９に定義されている（非特許文献２参照）。こうしたＣＳＴＡの機能については、それが様々なプログラミング・プラットフォームに適用され得るように、抽象的な、プラットフォーム独立型の方法で定義されている。さらに、ＣＳＴＡは、標準化された複数のプログラミング、またはプロトコル構文、その中でも、ＣＳＴＡ−ＸＭＬとして一般に知られる、ＣＳＴＡに結合する拡張マークアップ言語（ＸＭＬ：extensible markup language）を定義するＥＣＭＡ−３２３（特許文献３参照）、およびＥＣＭＡ−３４８（非特許文献４参照）、ウェブ。サービス記述言語（ＷＳＤＬ：Web Service Description Language）結合を付随する。ＣＳＴＡ規格スイートの一部と見なされるこうした言語結合（language bindings）は、最大の相互運用性を保証し、ＣＴＭＡの機能を、伝送制御プロトコル（ＴＣＰ：Transmission Control Protocol）、セッション開始プロトコル（ＳＩＰ：Session Initiation Protocol）またはシンプル・オブジェクト・アクセス。プロトコル（ＳＯＡＰ：Simple Object Access Protocol）を含めた任意の標準トランスポート。プロトコルを介して、それぞれ異なるオペレーティング。システムを実行するコンピュータから、使用できるようにする。
【０００５】
ＣＳＴＡは近年、インタラクティブな音声サービスの領域において積極的に採用されてきた。この採用は、音声アプリケーション言語タグ（ＳＡＬＴ：Speech Application Language Tag）に基づく拡張音声サービスによって促進されてきた。このＳＡＬＴについては、ＳＡＬＴ１．０仕様（非特許文献５参照）においてさらに説明されている。
【０００６】
【非特許文献１】ECMA/ISO (ECMA International Rue du Rhone 114 CH-1204, Geneve, www.ecma-international.org)規格
【非特許文献２】ECMA-269, Services for Computer Supported Telecommunication Applications (CSTA) Phase III
【非特許文献３】ECMA-323, SMLP Protocol for Computer Supported Telecommunication Applications (CSTA) Phase III
【非特許文献４】ECMA-348, Web Service Description Language (WSDL) for CSTA
【非特許文献５】SALT 1.0仕様, www.saltforum.org
【非特許文献６】ECMA TR/87
【非特許文献７】SIP, "What is SIP Introduction", www.sipcenter.com, February 15, 2005.
【非特許文献８】TechOnLine, "Voice Processing" Bob Walder, NSS Group, www.techonline.com, May 8, 2002.
【非特許文献９】ComputerWeekly.com, "Technology: EAI Tools; Web Services: Speech Theraphy", Danny Bradbury, www.computerweekly.com, June 8, 2004.
【非特許文献１０】Wikipedia, "Session Initiation Protocol", en.wikipedia.org/wiki/Session_Initional_Protocol, Oct. 12, 2004/
【非特許文献１１】Microsoft, "An Introduction to Telephony Call Control with Microsoft Speech Server 2004", www.microsoft.com/speech/evaluation/whitepapers/TelelphoneCallContolDoc.com, Dan Kershaw, 2004.
【非特許文献１２】XMLMania.com, "Ecma International Enhances SIP and Speech Service Support in CSTA", www.xmlmania.co, Sept. 16, 2004.
【非特許文献１３】Alcatel Executive  Alcatel  Internetworking, "Computer Supported Telephone Applications (CSTA)", Alcatel Executive Briefing, May 2002, pp. 1-6.
【発明の開示】
【発明が解決しようとする課題】
【０００７】
ＳＡＬＴを使用することによって、コール・センタは、音声関連の様々な機能を含むようにさらに自動化されることが可能になる。しかし、呼制御および音声制御アプリケーションの違いによって、分散音声サービスを容易にする際の問題（difficulties）がもたらされる。
【０００８】
したがって、音声サービスを容易にするためのプロトコルを確立することが求められている。
【課題を解決するための手段】
【０００９】
本発明は、クライアントとサーバの間でメディア・チャネルおよびシグナリング・チャネルを確立することに関する。メディア・チャネルは、通信のために選択されたコーデックおよびプロトコルを使用する。メディア・チャネルおよびシグナリング・チャネルを介して、クライアント上のアプリケーションは、サーバ上の音声サービスを使用することができる。
【発明を実施するための最良の形態】
【００１０】
分散音声サービスのためのアーキテクチャ、およびそれを実装するための方法について述べる前に、そのアーキテクチャ内で機能することが可能なコンピューティング装置について一般的に述べることが有用である。次に図１を参照すると、データ管理装置（ＰＩＭ、ＰＤＡなど）の例示的な形が、３０に示されている。しかし、本発明は、以下で論じる他のコンピューティング装置、具体的には、入力ボタンなどのための限られた表面積を有するコンピューティング装置を使用して実施することもできることが企図されている。たとえば、電話および／またはデータ管理装置もまた、本発明の恩恵を受けることになる。こうした装置は、既存の携帯個人情報管理装置、および他の携帯電子装置と比べて向上した実用性を有し、またこうした装置の機能およびコンパクトなサイズによって、ユーザがこの装置を常に持ち歩くよう促される可能性が高くなる。したがって、本明細書で述べるアーキテクチャの範囲は、本明細書で図示する例示的なデータ管理すなわちＰＩＭ装置、電話またはコンピュータの開示によって限定されるものではない。
【００１１】
図１に、データ管理モバイル装置３０の例示的な形が示されている。モバイル装置３０は、筐体３２を含み、またスタイラス３３と併せて接触感知型の表示面画面を使用するディスプレイ３４を含むユーザ。インターフェースを有する。スタイラス３３を使用して、指定された座標でディスプレイ３４を押しまたはそれに接触して、フィールドを選択し、カーソルの開始点を選択的に移動し、またはジェスチャや手書きなど別の方法でコマンド情報を提供する。別法として、またはそれに加えて、１つまたは複数のボタン３５が、ナビゲーションのために装置３０上に含められことができる。さらに、回転ホイール、ローラなどの他の入力装置も提供することができる。しかし、本発明は、こうした形の入力機構に限定されるものではないことに留意されたい。たとえば、他の形の入力には、コンピュータ視覚などによる視覚入力が含まれ得る。
【００１２】
次に図２を参照すると、ブロック図が、モバイル装置３０を含む機能コンポーネントを示している。中央処理装置（ＣＰＵ：central processing unit）５０は、ソフトウェア制御機能を実装する。ＣＰＵ５０は、制御ソフトウェアに従って生成されたテキストおよびグラフィック・アイコンがディスプレイ３４上に表示されるように、ディスプレイ３４に結合される。スピーカ４３は、可聴出力を提供するために、一般にはデジタル・アナログ変換器５９を用いて、ＣＰＵ５０に結合され得る。ユーザによってモバイル装置３０内にダウンロードされまたは入力されるデータは、ＣＰＵ５０に双方向に結合された不揮発性の読出し／書込みランダム・アクセス・メモリ・ストア５４内に格納される。ランダム・アクセス・メモリ（ＲＡＭ：random access memory）５４は、ＣＰＵ５０によって実行される命令のための揮発性の記憶域、およびレジスタ値などの一時的なデータのための記憶域を提供する。構成オプションのための既定値、および他の変数は、読出し専用メモリ（ＲＯＭ：read-only memory）５８に格納される。ＲＯＭ５８は、モバイル３０の基本機能、および他のオペレーティング・システム・カーネル機能（ＲＡＭ５４内へのソフトウェア・コンポーネントのロードなど）を制御する装置のためのオペレーティング・システム・ソフトウェアを格納するために使用することもできる。
【００１３】
ＲＡＭ５４は、アプリケーション・プログラムを格納するために使用される、ＰＣ上のハードドライブの機能に類似のやり方で、コードのための記憶域としても働く。コードを格納するために不揮発性のメモリが使用されるが、別法として、それは、コードの実行のために使用されない揮発性メモリ内に格納されることもできることに留意されたい。
【００１４】
無線信号は、モバイル装置によって、ＣＰＵ５０に結合された無線トランシーバ５２を介して送受信することができる。コンピュータ（デスクトップ・コンピュータなど）から直接に、または所望であれば無線ネットワークからデータをダウンロードするために、任意選択の通信インターフェース６０を提供することもできる。したがって、インターフェース６０には、たとえば赤外線リンク、モデム、ネットワーク・カードなど、様々な形の通信装置を含めることができる。
【００１５】
モバイル装置３０は、マイク２９、アナログ・デジタル（Ａ／Ｄ：analog-to-digital）変換器３７、およびストア５４内に格納された任意選択の認識プログラム（音声、ＤＴＭＦ、手書き、ジェスチャまたはコンピュータ視覚）を含む。例を挙げると、装置３０のユーザからの可聴情報、命令またはコマンドに応答して、マイク２９は音声信号を提供し、この音声信号は、Ａ／Ｄ変換器３７によってデジタル化される。音声認識プログラムは、デジタル化された音声信号に対して正規化および／または特徴抽出機能を実施して、中間の音声認識結果を取得することができる。
【００１６】
無線トランシーバ５２または通信インターフェース６０を使用して、音声データは、以下で論じ、また図５のアーキテクチャ内に図示するリモート音声サーバ（speech server）２０４に送信される。次いで、認識結果は、モバイル装置３０上で（たとえば視覚的かつ／または可聴）レンダリングし、また最終的にはウェブ・サーバ２０２（図５）に送信するために、モバイル装置３０に返され、またウェブ・サーバ２０２およびモバイル装置３０は、クライアント／サーバの関係（relationship）で動作する。
【００１７】
他の形の入力のために、類似の処理が使用され得る。たとえば、手書き入力は、装置３０上で前処理の有無にかかわらずデジタル化することができる。音声データと同様に、この形の入力は、認識のために音声サーバ２０４に送信されることができ、その認識結果は、装置３０および／またはウェブ・サーバ２０２のうちの少なくとも１つに返される。同様に、ＤＴＭＦデータ、ジェスチャ・データおよび視覚データが、同じように処理されることが可能である。入力の形に応じて、装置３０（および以下で論じる他の形のクライアント）は、視覚入力に必要な、カメラなどの必要なハードウェアを含むことになる。
【００１８】
図３は、携帯電話８０の例示的な一実施形態の平面図である。電話８０は、ディスプレイ８２およびキーパッド８４を含む。一般に、図２のブロック図は、他の機能を実施するために必要な追加の回路が必要とされるけれども、図３の電話に適用される。たとえば、図２の実施形態には、電話として機能するのに必要なトランシーバが必要とされるが、しかし、こうした回路は、本発明に関係がない。
【００１９】
上述の携帯またはモバイル・コンピューティング装置に加えて、本発明は、一般的なデスクトップ・コンピュータなどの他の多くのコンピューティング装置で使用することができることも理解されたい。たとえば、本発明によって、身体能力が限られているユーザは、完全な英数字キーボードなどの他の従来型入力装置を操作するのが難しすぎる場合、コンピュータまたは他のコンピューティング装置にテキストをインプットすなわち入力することができる。
【００２０】
本発明は、複数の他の汎用または特定目的コンピューティング・システム、環境または構成で動作することもできる。本発明で使用するのに適す可能性がある周知のコンピューティング・システム、環境および／または構成の例には、それだけに限らないが、通常の電話（画面なし）、パーソナル・コンピュータ、サーバ・コンピュータ、ハンドヘルドまたはラップトップ装置、マルチ・プロセッサ・システム、マイクロ・プロセッサ・ベースのシステム、セットトップボックス、プログラマブルな家電、無線周波数識別（ＲＦＩＤ：radio frequency identification）装置、ネットワークＰＣ、ミニ・コンピュータ、メインフレーム・コンピュータ、上記システムまたは装置のいずれかを含む分散コンピューティング環境などが含まれる。
【００２１】
以下は、図４に示す汎用コンピュータ１２０についての簡潔な説明である。しかし、コンピュータ１２０もやはり、適切なコンピューティング環境の一例にすぎず、本発明の使用または機能に関する制限を示唆するものではない。コンピュータ１２０は、本明細書で示す構成要素のいずれか１つまたはその組合わせに関する依存関係または要件を有するものと解釈すべきでない。
【００２２】
本発明について、コンピュータによって実行されるプログラム・モジュールなどのコンピュータ実行可能命令の一般的なコンテクストで述べることができる。一般に、プログラム・モジュールは、特定のタスクを実施し、または特定の抽象データ・タイプを実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造体などを含む。本発明は、通信ネットワークを介してリンクされたリモート処理装置によってタスクが実施される分散コンピューティング環境内で実施することもできる。分散コンピューティング環境内では、プログラム・モジュールは、メモリ記憶装置を含めて、ローカルとリモートの両方のコンピュータ記憶媒体内に置くことができる。プログラムおよびモジュールによって実施されるタスクについて、図面を用いて以下に述べる。当業者は、任意の形のコンピュータ読取り可能媒体内に書き込まれ得るプロセッサ実行可能命令として、本説明および図面を実装することができる。
【００２３】
図４を参照して述べると、コンピュータ１２０の構成要素は、それだけに限らないが、処理装置１４０、システム・メモリ１５０、ならびにシステム・メモリを含めて様々なシステム構成要素を処理装置１４０に結合するシステム・バス１４１を含み得る。システム・バス１４１は、メモリ・バスまたはメモリ・コントローラ、周辺バス、および様々なバス構造のいずれかを使用したローカル・バスを含めて、複数タイプのバス構造のいずれかであり得る。限定するためではなく、例を挙げると、こうしたアーキテクチャには、業界標準アーキテクチャ（ＩＳＡ：Industry Standard Architecture）バス、ユニバーサル・シリアル・バス（ＵＳＢ：Universal Serial Bus）、マイクロ・チャネル・アーキテクチャ（ＭＣＡ：Micro Channel Architecture）バス、拡張ＩＳＡ（ＥＩＳＡ：Enhanced ISA）バス、ビデオ電子規格協会（ＶＥＳＡ：Video Electronics Standards Association）ローカル・バス、およびメザニン・バスとも呼ばれる周辺コンポーネント相互接続（ＰＣＩ：Peripheral Component Interconnect）バスを含めることができる。コンピュータ１２０は一般に、様々なコンピュータ読取り可能媒体を含む。コンピュータ読取り可能媒体は、コンピュータ１２０からアクセスすることができる任意の使用可能な媒体とすることができ、揮発性と不揮発性、取外し可能と取外し不可能の両方の媒体を含む。限定するためではなく、例を挙げると、コンピュータ読取り可能媒体は、コンピュータ記憶媒体および通信媒体を含むことができる。コンピュータ記憶媒体は、コンピュータ読取り可能命令、データ構造体、プログラム・モジュールまたは他のデータなどの情報を格納するための任意の方法または技術で実装された揮発性と不揮発性、取外し可能と取外し不可能の媒体を含む。コンピュータ記憶媒体には、それだけに限らないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュ・メモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ：digital versatile disk）または他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置または他の磁気記憶装置、あるいは所望の情報を格納するために使用することができ、またコンピュータ１２０によってアクセスすることができる他の任意の媒体が含まれる。
【００２４】
通信媒体は一般に、搬送波や他のトランスポート機構などの変調されたデータ信号内にコンピュータ読取り可能命令、データ構造体、プログラム・モジュール、または他のデータを実装し、また任意の情報送達媒体を含む。用語「変調されたデータ信号」は、信号内の情報を符号化するなどのやり方でその特性の１つまたは複数が設定されまたは変更された信号を意味する。限定するためではなく、例を挙げると、通信媒体には、有線ネットワークや直接有線接続などの有線媒体、ならびに音響、ＲＦ、赤外線などの無線媒体、および他の無線媒体が含まれる。上記内容のいずれかの組合せもまた、コンピュータ読取り可能媒体の範囲内に含まれるべきである。
【００２５】
システム・メモリ１５０は、読出し専用メモリ（ＲＯＭ）１５１やランダム・アクセス・メモリ（ＲＡＭ）１５２などの揮発性および／または不揮発性メモリの形のコンピュータ記憶媒体を含む。起動時などにコンピュータ１２０内の要素間で情報を転送するのに役立つ基本ルーチンを含む基本入出力システム（ＢＩＯＳ：basic input/output system）１５３は一般に、ＲＯＭ１５１に格納される。ＲＡＭ１５２は一般に、処理装置１４０からダイレクトにアクセス可能であり、かつ／またはそれによってオペレーション中のデータおよび／またはプログラム・モジュールを収容する。限定するためではなく、例示するために、図４に、オペレーティング・システム１５４、アプリケーション・プログラム１５５、他のプログラム・モジュール１５６およびプログラム・データ１５７を示す。
【００２６】
コンピュータ１２０は、他の取外し可能／取外し不可能、揮発性／不揮発性のコンピュータ記憶媒体をも含み得る。例示するためだけに、図４に、取外し不可能な不揮発性の磁気媒体から読み出しまたはそこに書き込むハードディスク・ドライブ１６１、取外し可能な不揮発性の磁気ディスク１７２から読み出しまたはそこに書き込む磁気ディスク・ドライブ１７１、およびＣＤ−ＲＯＭや他の光媒体などの取外し可能な不揮発性の光ディスク１７６から読み出しまたはそこに書き込む光ディスク・ドライブ１７５を示す。この例示的なオペレーティング環境内で使用され得る他の取外し可能／取外し不可能、揮発性／不揮発性のコンピュータ記憶媒体には、それだけに限らないが、磁気テープ・カセット、フラッシュ・メモリ・カード、デジタル多用途ディスク、デジタル・ビデオ・テープ、ソリッド・ステートＲＡＭ、ソリッド・ステートＲＯＭなどが含まれる。ハードディスク・ドライブ１６１は一般に、インターフェース１６０などの取外し不可能メモリ・インターフェースを介してシステム・バス１４１に接続され、磁気ディスク・ドライブ１７１および光ディスク・ドライブ１７５は一般に、インターフェース１７０などの取外し可能メモリ・インターフェースによってシステム・バス１４１に接続される。
【００２７】
上記で論じ、また図４に示したドライブおよびその関連のコンピュータ記憶媒体によって、コンピュータ読取り可能命令、データ構造体、プログラム・モジュール、およびコンピュータ１２０のための他のデータの記憶域がもたらされる。図４で、たとえば、ハードディスク・ドライブ１６１は、オペレーティング・システム１６４、アプリケーション・プログラム１６５、他のプログラム・モジュール１６６およびプログラム・データ１６７を格納するものとして示されている。これらの構成要素は、オペレーティング・システム１５４、アプリケーション・プログラム１５５、他のプログラム・モジュール１５６およびプログラム・データ１５７と同じでも、それとは異なっていてもよいことに留意されたい。少なくともそれらがそれぞれ異なるコピーであること示すために、オペレーティング・システム１６４、アプリケーション・プログラム１６５、他のプログラム・モジュール１６６およびプログラム・データ１６７に、ここではそれぞれ異なる番号が付与されている。
【００２８】
ユーザは、入力装置、たとえばキーボード１８２、マイク１８３、およびマウス、トラックボールまたはタッチパッドなどのポインティング装置１８１を介して、コンピュータ１２０にコマンドおよび情報を入力することができる。他の入力装置（図示せず）には、ジョイスティック、ゲームパッド、パラボラ・アンテナ、スキャナなどが含まれ得る。これらのおよび他の入力装置はしばしば、システム・バスに結合されたユーザ入力インターフェース１８０を介して処理装置１４０に接続されるが、パラレルポート、ゲームポートまたはユニバーサル・シリアル・バス（ＵＳＢ：universal serial bus）など、他のインターフェースおよびバス構造によって接続されることもできる。モニタ１８４、または他のタイプの表示装置もまた、ビデオ・インターフェース１８５などのインターフェースを介してシステム・バス１４１に接続される。モニタに加えて、コンピュータは、出力周辺インターフェース１８８を介して接続され得る、スピーカ１８７およびプリンタ１８６などの他の周辺出力装置をも含み得る。
【００２９】
コンピュータ１２０は、リモート・コンピュータ１９４などの１つまたは複数のリモート・コンピュータへの論理接続を使用して、ネットワーク化された環境内で動作することができる。リモート・コンピュータ１９４は、パーソナル・コンピュータ、ハンドヘルド装置、サーバ、ルータ、ネットワークＰＣ、ピア・デバイス、または他の一般的なネットワーク・ノードとすることができ、またコンピュータ１２０に関して上記で述べた要素の多くまたはすべてを一般に含む。図４に示す論理接続は、ローカル・エリア・ネットワーク（ＬＡＮ：local area network）１９１、および広域ネットワーク（ＷＡＮ：wide area network）１９３を含むが、他のネットワークを含むこともできる。こうしたネットワーキング環境は、オフィス、事業体規模のコンピュータ・ネットワーク、イントラネットおよびインターネットでは一般的である。
【００３０】
ＬＡＮネットワーキング環境内で使用される場合、コンピュータ１２０は、ネットワーク・インターフェースまたはアダプタ１９０を介してＬＡＮ１９１に接続される。ＷＡＮネットワーキング環境内で使用される場合、コンピュータ１２０は、モデム１９２、あるいはインターネットなどのＷＡＮ１９３を介して通信を確立するための他の手段を含む。内部にあることも、外部にあることもあるモデム１９２は、ユーザ入力インターフェース１８０または他の適切な機構を介してシステム・バス１４１に接続され得る。ネットワーク化された環境内では、コンピュータ１２０に関して示したプログラム・モジュールまたはその一部は、リモート・メモリ記憶装置内に格納され得る。限定するためではなく、例示するために、図４に、リモート・コンピュータ１９４内に常駐するリモート・アプリケーション・プログラム１９５を示す。図示するネットワーク接続は例示的なものであり、コンピュータ間の通信リンクを確立する他の手段が使用され得ることが理解されよう。
【００３１】
図５に、本発明で実施することが可能な分散音声サービスのための例示的なアーキテクチャ２００を示す。一般に、ウェブ・サーバ２０２内に格納された情報は、モバイル装置３０（ディスプレイスクリーン、入力の形式（form）に基づいて必要とされるマイク、カメラ、タッチ・パネルなどを含む他の形のコンピューティング装置をもここでは表している）を介して、または電話機８０を介してアクセスされることができ、電話機８０を介する場合、情報は、聞き取れるようなやり方で、またはキーの押下に応答して電話機８０によって生成された音を介して要求され、またウェブ・サーバ２０２からの情報は、聞き取れるやり方でだけユーザに提供される。
【００３２】
しかし、より重要には、アーキテクチャ２００は、情報が、音声認識を使用して装置３０から取得されようが、電話８０から取得されようが、単一の音声サーバ２０４がいずれの操作モードをもサポートし得るという点で統一されている。さらに、アーキテクチャ２００は、周知のマークアップ言語（たとえばＨＴＭＬ、ＸＨＴＭＬ、ｃＨＴＭＬ、ＸＭＬ、ＷＭＬなど）の拡張を使用して動作する。したがって、ウェブ・サーバ２０２内に格納された情報は、こうしたマークアップ言語内で見られる周知のＧＵＩメソッドを使用してアクセスされることもできる。周知のマークアップ言語の拡張を使用することによって、ウェブ・サーバ２０２上のオーサリングはより容易になり、また現存のレガシー・アプリケーションは、音声認識を含むように容易に修正されることもできる。
【００３３】
一般に装置３０は、ウェブ・サーバ２０２によって提供されるＨＴＭＬ＋スクリプトなどを実行する。音声認識が必要とされる場合、たとえば、上記で論じたように装置３０によって前処理されているデジタル化されたオーディオ信号、または音声特徴であり得る音声データは、音声認識時に使用する文法または言語モデルの指標（indication）を付加して音声サーバ２０４に提供される。音声サーバ２０４の実装は多くの形を取ることができ、本明細書ではそのうちの１つを図示しているが、しかし、一般に、認識器（recognizer）２１１を含む。認識の結果は、必要な場合、またはそうすることが適切な場合に、ローカルなレンダリングのために装置３０に提供される。認識器、また任意のグラフィカル・ユーザ・インターフェースが使用される場合には、それを用いて情報が編集されると、装置３０は、さらに処理するために、ＨＴＭＬスクリプトが必要であればさらにそれを受信するために、その情報をウェブ・サーバ２０２に送信する。
【００３４】
図５に示すように、装置３０、ウェブ・サーバ２０２、および音声サーバ２０４は一般に、ここではインターネットなどの広域ネットワークであるネットワーク２０５を介して接続されており、また別個にアクセス可能である。したがって、こうした装置のいずれもが互いに物理的に隣接して配置される必要はない。具体的には、ウェブ・サーバ２０２は、音声サーバ２０４を含む必要はない。このように、ウェブ・サーバ２０２上のオーサリングは、作者が複雑な音声サーバ２０４について知る必要なしに、意図する対象のアプリケーションに集中させることができる。正確には、音声サーバ２０４は、独立に設計され、ネットワーク２０５に接続され、それによって、ウェブ・サーバ２０２で必要とされるさらなる変更なしに更新され、改良されることができる。別の実施形態では、クライアント３０は、ウェブ・サーバ２０２を必要とせずに、音声サーバ２０４と直接に通信することができる。ウェブ・サーバ２０２、音声サーバ２０４およびクライアント３０は、実装するマシンの能力に応じて組み合わせられ得ることがさらに理解されよう。たとえば、クライアントは、パーソナル・コンピュータなどの汎用コンピュータを含む場合、音声サーバ２０４を含むことができる。同様に、所望であれば、ウェブ・サーバ２０２および音声サーバ２０４は、単一のマシン内に組み込むことができる。
【００３５】
電話８０を介したウェブ・サーバ２０２へのアクセスは、電話８０の有線または無線電話網（wired or wireless telephone network）２０８への接続を含み、この電話網２０８は、電話８０を第三者のゲートウェイ２１０に接続する。ゲートウェイ２１０は、電話８０を電話音声ブラウザ（telephony voice browser）２１２に接続する。電話音声ブラウザ２１２は、電話インターフェースを提供するメディア・サーバ２１４、および音声ブラウザ２１６を含む。装置３０と同様に、電話音声ブラウザ２１２は、ウェブ・サーバ２０２からＨＴＭＬスクリプトなどを受信する。しかし、より重要には、そのＨＴＭＬスクリプトは、装置３０に提供されるＨＴＭＬスクリプトに類似の形のものである。このように、ウェブ・サーバ２０２は、装置３０および電話８０を別個にサポートする必要はなく、また標準のＧＵＩクライアントを別個にサポートする必要さえない。正確には、共通のマークアップ言語が使用され得る。さらに、装置３０と同様に、電話８０によって送信される可聴信号からの音声認識は、ネットワーク２０５、またはたとえばＴＣＰ／ＩＰを使用した専用線２０７を介して、音声ブラウザ２１６から音声サーバ２０４に提供される。ウェブ・サーバ２０２、音声サーバ２０４および電話音声ブラウザ２１２は、図４に示す汎用のデスクトップ・コンピュータなどの任意の適切なコンピューティング環境内で実装することができる。
【００３６】
しかし、ＤＴＭＦ（Dial Tone Multi Frequency ）認識が使用される場合、この形の認識は、音声サーバ２０４ではなく、メディア・サーバ２１４で一般に実行されることに留意されたい。換言すると、ＤＴＭＦ文法は、メディア・サーバによって使用される。
【００３７】
上述の装置およびアーキテクチャ前提にして、本発明について、さらに、単純なクライアント／サーバに基づいて、説明する。図６に示すように、本発明は、メディア・サービス（音声認識、またはテキスト音声合成など）を提供するサーバ３０２、ならびにアプリケーション特有のコードを実行するクライアント３０４を含むシステム３００に関連する。サーバ３０２とクライアント３０４の間の通信は、サービス・モデルに基づき、そこでは、情報が、交換されたり、またはタグ付けされたり、あるいは、そうでない場合は、限定されないがＸＭＬ（拡張マークアップ言語）ドキュメント、などの特定部分を含んだりすることができる。サーバ３０２および／またはクライアント３０４は、他の情報に加えて、オーディオを収集し、送信することができる。ある実施形態では、サーバ３０２は、ワシントン州、レッドモンドのＭｉｃｒｏｓｏｆｔ  Ｃｏｒｐｏｒａｔｉｏｎ社によって開発されたＭｉｃｒｏｓｏｆｔ音声サーバを含むことができ、クライアント３０４は、それだけに限らないがデスクトップＰＣ、モバイル装置などを含めて、上記で論じたように、任意の数の形（form）を取ることができる。
【００３８】
この点で、サーバ３０２およびクライアント３０４はあるサービス・モデルに基づいて互いに通信するが、サーバ３０２とクライアント３０４の間の通信がサービス・モデル要求に従って実施される限り、宣言および／または手続きベースのアプリケーションを使用することができるので、本発明の態様を呼び出すアプリケーションは、サービス・モデルに基づいて排他的に記述される必要はないことに留意されたい。ある実施形態では、クライアント・アプリケーションは、図５で述べたＨＴＭＬベースアプリケーションの場合のようなブラウザを必要としないＣ＋＋、Ｊａｖａ（登録商標）、Ｃ＃または他の命令プログラミング言語（imperative programming languages）で構成することができる。
【００３９】
ＣＳＴＡ（Computer Supported Telecommunications Applications）（ＥＣＭＡ−２６９）第６版のある重要な側面は、音声アプリケーション言語タグ（ＳＡＬＴ）に基づく拡張音声サービスである。新しく追加された機能は、システム３００上に実装することができる自動音声認識（automatic speech recognition）、音声検証（speech verification）、話者識別（speaker identity）、話者検証（speaker verification）、およびテキスト音声合成（text-to-speech synthesis）を含む。こうした機能の一部またはすべては、自動化されたコール・センタ内に設けられる。本発明の態様は、ネットワーク・ベースの音声サービスを容易にするためのＣＳＴＡサービスのサブ・セットを提供する。具体的には、本発明の一部の態様は、ウェブ・サービス、ならびにＳＩＰ（セッション開始プロトコル）ベースのＶｏＩＰ（Voice-over Internet Protocol：ボイス・オーバ・インターネット・プロトコル）環境でそれぞれ分散音声サービスを容易にするために、ＥＣＭＡ−３４８およびｕａＣＳＴＡ（ＥＣＭＡ−ＴＲ／８７）（特許文献６）をどのように適用することが可能かについて示している。
【００４０】
コンピュータ支援通信アプリケーション（ＣＳＴＡ）のためのサービス、ＥＣＭＡ−２６９、ならびにそのＸＭＬおよびウェブ・サービスのプロトコルは、ＥＣＭＡ−３２３およびＥＣＭＡ−３４８によってそれぞれ定義されている。ＥＣＭＡ−ＴＲ／８７（ｕａＣＳＴＡ）は最近、ＶｏＩＰ環境内でＥＣＭＡ−３２３を使用するための１組のＳＩＰ規約ついてさらに記載している。すべてのこうしたプロトコルは原則として、ＣＳＴＡの全セットに対処し、したがって、具体的には、音声サービスに適用することができる。ＥＣＭＡ−２６９の第６版では、ＣＳＴＡの音声サービス部分が、ＳＡＬＴから派生した技術に基づいて拡大されている。既存の音声サービスに加えて、新しい追加は、自動音声認識、音声検証、話者識別、話者検証およびテキスト音声合成などを含めて、コール・センタ自動化およびモバイル・アプリケーションにとって必須の重要な機能を含む。
【００４１】
呼制御と音声シナリオの密接に統合されたＣＳＴＡ実装がアプリケーション開発者にとっては望ましいが、呼制御ベンダと音声ベンダの間のコア・コンピテンシー（competencies）は、必ずしも同じでない。現在の展開（deployment）では、また予測可能な将来においては、ＣＳＴＡアプリケーション開発者は、これらの領域のその各ニーズを満たすために複数のベンダを関与させる必要があり得る。幸いに、ＥＣＭＡ−２６９に示されているＣＳＴＡモデリング概念は、単一のアプリケーションが複数のＣＳＴＡサービス・プロバイダからサービスを引き出すことを可能にする。したがって、それは、ＣＳＴＡアプリケーションがＣＳＴＡの２つの実装、呼制御のための１つ、および音声サービスのためのもう一方を同時に使用する有効なシナリオである。
【００４２】
音声サービスのためのＣＳＴＡプロファイルは、呼制御の領域ほどには洗練されてこなかった。本発明の態様は、音声サービスを提供するためのＣＳＴＡプロファイルを、ＸＭＬを使用したプラットフォーム独立型の方法で説明する。ＣＳＴＡプロファイルは、不可知論的な性質のトランスポートであるが、エンド・ツー・エンドの相互運用性、すなわち小規模なＣＳＴＡの使用に基づくＳＩＰ環境と、ＥＣＭＡ−３４８に基づくウェブ・サービス・ベースの環境とをよりよく促進するために、音声サービス・プロファイルの２つの共通のアプリケーションが本明細書で例示される。
【００４３】
本明細書で述べる説明はて、クライアント−サーバ・ベースの音声処理を容易にするためにＣＳＴＡ音声サービスのサブ・セットがどのように含められ得るかについての例を提供する。以下のＥＣＭＡ規格の全体を本明細書中で参考として援用する（ＥＣＭＡ−２６９（非特許文献２）、ＥＣＭＡ−３２３（非特許文献３）、ＥＣＭＡ−３４８（非特許文献４）参照）。さらに、本出願は、ｕａＣＳＴＡ提案を使用したＳＩＰベースのＶｏＩＰ環境でＣＳＴＡ音声サービスがどのように実装され得るかについて述べる。ｕａＣＳＴＡについての参照として、ＥＣＭＡ  ＴＲ／８７（非特許文献６）が使用されるべきである。同規格のコピーを本明細書中で参考として援用する。
【００４４】
本明細書で述べるクライアント−サーバ・ベースの音声処理は、応答／要求サイクルにおいて非対称のメディア・タイプに対処することができる。たとえば、音声認識サービスを提供する際に、クライアントは、サーバにオーディオ・データを送信する。サーバは、オーディオ・データをテキスト・データに変換し、変換されたデータをクライアントに送信する。音声合成の場合、クライアントはテキスト・データを送信し、サーバは、変換されたオーディオ・データで応答する。送信されるデータは、ＣＳＴＡに基づくものなどの指定されたプロトコルに従って送信することができる。結果として、ＳＩＰおよびウェブ・サービス環境は、テキスト−オーディオまたはオーディオ−テキストのオーディオ・イン・オーディオ（audio-in-audio）対話を含むように拡張されることになる。
【００４５】
ＥＣＭＡ  ＴＲ／８７は、図６に示すように、「シグナリング・チャネル」３０８トランスポートを確立する。シグナリング・チャネル３０８は、それが呼制御に関するときに、それぞれが何をすべきかについての情報を交換するために、サーバ３０２およびクライアント３０４によって使用される。サーバ３０２が電話交換機（telephone switch）を含む場合、シグナリング・チャネル３０８の使用で十分である。しかし、サーバ３０２が音声サーバであり、またクライアント３０４が音声サービスを求めている場合、サーバ３０２は、音声情報を送受信する場所をも知らなければならない。たとえば、サーバ３０２は、音声認識情報をどこで取得し、また合成された音声をどこに送信するかを知らなければならない。
【００４６】
したがって、シグナリング・チャネル３０８を確立することに加えて、「メディア・チャネル」プロトコル３１０も確立されなければならない。たとえば、メディア・チャネル３１０は、クライアント３０４によって収集された音声データ（オーディオ・データ）をサーバ３０２に移送するために使用される。同様に、テキスト音声操作（text-to-speech operation）では、クライアント３０４はシグナリング・チャネル３０８を介してテキスト・データを送信することができ、一方、合成された音声データは、メディア・チャネル３１０を介してクライアント３０４からサーバ３０２に提供される。
【００４７】
図５のアーキテクチャに関して、シグナリング・チャネル３０８およびメディア・チャネル３１０は、音声サーバ２０４への任意の通信のためにも確立される。しかし、ウェブ・アプリケーション・サーバ２０２の使用は任意選択であり、またそのアプリケーションは、図５に示すクライアント３０上に常駐し得ることに留意されたい。
【００４８】
本発明のある態様は、メディア・チャネル３１０を実装するためにどんなステップが取られるかについてである。ある例示的な実施形態で、ＳＩＰ環境におけるＣＳＴＡのためのメディア・チャネル３１０の確立について論じる。さらなる例示的な実施形態では、ウェブ・サービス・ベースの環境においてＣＳＴＡのためのメディア・チャネル３１０を実装するためにどんなステップが取られるかについて論じる。
【００４９】
意味論情報（semantic information）が、たとえば、リスナ・リソースによって返される結果、すなわち音声認識を備えたサーバ３０２によって返される結果のためにＸＭＬスキーマを指定することができる音声アプリケーション記述言語（ＳＡＤＬ：Speech Application Description Language）を使用することによって、サーバ３０２とクライアント３０４の間で転送することができることは、価値がないことである。
【００５０】
ＳＩＰ環境内のチャネルの確立
ＳＩＰは、サーバ３０２とクライアント３０４が小さい情報を頻繁に交換する状態の、「おしゃべり（chatty）」的なものとなるように設計されたプロトコルである。ＳＩＰ環境では、メディア・チャネル３１０の確立は、セッション記述プロトコル（ＳＤＰ：Session Description Protocol）を用いて達成される。図７に、この課題を達成するための例示的な方法４００が示されている。
【００５１】
ステップ４０２で、クライアント３０４は、ＳＩＰ−Ｉｎｖｉｔｅを使用して、サーバ３０２とのセッションを開始する。また使用されるべきＩＰ（Internet Protocol：インターネット・プロトコル）アドレス、およびオーディオ用に使用されるべきＩＰアドレス上のポートを宣言するＳＤＰ記述が送信される。さらに、ステップ４０４で、ＳＤＰ記述によって、メディア・ストリーム用に使用される符号化のコーデック・タイプ、および伝送制御プロトコル（ＴＣＰ）やリアルタイム伝送プロトコル（ＲＴＰ：real-time transport protocol）などの通信プロトコルを通知することになる。
【００５２】
サーバによって受信されると、ステップ４０６で、サーバは、クライアント３０４によって示されたＳＤＰ記述を受け入れられるかどうか決定することができる。そのプロトコルおよびそのコーデックが受け入れられる場合、サーバ３０２は、ＳＩＰ−ＯＫ（SIP-okay）、ならびにそのＩＰアドレスおよびオーディオ・ポートをリストするそれ自体のＳＤＰ記述で応答する。次いで、方法４００はステップ４０８に進み、シグナリング・チャネルが確立される。
【００５３】
別法では、サーバ３０２は、提案されたコーデックまたはプロトコルをサポートしない場合、どのコーデックおよび／またはプロトコルが使用されるかについて、クライアント３０４との交渉を開始することができる。換言すると、サーバ３０２は、別のコーデックおよび／またはプロトコルを提案する逆提案によって、クライアント３０４の初期ＳＤＰ記述に応答する。提案を行う前に、方法４００は、ステップ４１０に進み、認識（recognition）を継続すべきかについて決定が行われる。たとえば、指定された数の逆提案が提案されると、ステップ４１２で、通信は、停止する。ステップ４１４でクライアント３０４とサーバ３０２の間で追加の逆提案を、合意に到達するまで、または合意に達しないことが明らかになるまで、行うことができる。
【００５４】
ＳＩＰ／ＳＤＰは、ボイスオーバＩＰ上でオーディオ・チャネルを確立するために使用される、インターネット技術特別調査委員会（ＩＥＴＦ：Internet Engineering Task Force）によって承認された規格である。しかしながら、ＳＩＰ／ＳＤＰは、ＣＳＴＡを実装するシグナリング・チャネルを確立するための方法について記述していない。ステップ４０８で、シグナリング・チャネル３０８が、ＥＣＭＡ−ＴＲ／８７に従って確立される。シグナリング・チャネルの確立後、アプリケーションの関連付けが完了したと見なされる。結果として、システム３００内で、分散音声サービスを実装することができる。
【００５５】
ウェブ・サービス環境内のチャネルの確立
上述したＳＩＰの「おしゃべり」的な性質とは対称的に、ウェブ・サービスは、サーバ３０２とクライアント３０４の間で、必要とされる対話の交換がより少なくて済むように、「まとまった（chunky）」通信向けに設計され、またしばしば最適化されている。結果として、ＳＩＰ内での複数の対話やりとり（dialog turn）で交渉される特性は、通常、ウェブ・サービス用の公開ディレクトリ内で公開されたサービス記述によって、記述されたり、見つけ出されたり、またはウェブ・サービス・メタデータの交換において動的に取得されたりする。ウェブ・サービス環境は、ＵＤＤＩ（Uniform Description Discovery Integration）標準プロトコルを含む。ウェブ・サービス・プロバイダは関連情報を公開し、この関連情報を、アプリケーション開発者が発見し、取得し、それによって、アプリケーション開発者がアプリケーション内でウェブ・サービスを動的に統合することを可能にする適切なサービス・プロバイダを選択することができる。たとえば、ＥＣＭＡ−３４８は、ＣＳＴＡ機能を提供するウェブ・サービスが、標準のウェブ・サービス・プロトコルを使用して、一貫した形で記述され、発見され、統合され得るように、ＣＳＴＡのためのウェブ・サービス記述言語（ＷＳＤＬ：Web Service Description Language）を指定する。メディア・チャネルの確立は、ＥＣＭＡ−３４８の拡張である。
【００５６】
図８に、ウェブ・サービス環境内でチャネルを確立するための例示的な方法４２０を示す。本発明では、ステップ４２２で、ウェブ・サービス・プロバイダは、サービス・メタデータとして、ウェブ・サービスによってサポートされるすべてのコーデックおよびプロトコルをリストする。ステップ４２４で、アプリケーション開発者は、ウェブ・サービス・ディレクトリ・プロバイダを使用して、それが使用し得るコーデックおよびプロバイダをどのウェブ・サービスが有しているかを取得しまたは発見する。このステップは、それが必要とする所望のコーデックおよびプロトコルを見つけるために提供された、各ウェブ・サービスのメタデータを探索することによって実施することができる。そのディレクトリは、それぞれのウェブ・サービスのＵＲＬ（universal resource locator：ユニバーサル・リソース・ロケータ）アドレスを提供する。次いで、クライアント３０４は、サーバ３０２と通信するために、ウェブ・サービスとの接続を行い、所望のコーデックおよびプロトコルでアプリケーションを使用する。接続が行われた後に、メディア・チャネル３１０およびそのシグナリング・チャネル３０８が一度に確立される。
【００５７】
ウェブ・サービス環境下での本発明は、ＷＳＤＬのメディア記述拡張を用いる１回の交換で、すべてのレベル（アプリケーションおよびトランスポート）を通した接続を確立する方法に向けられる。ある実施形態では、本発明は、ＥＣＭＡ−３４８と併せて適用することができ、このＥＣＭＡ−３４８は、ＣＳＴＡ、およびその基礎となるシグナリング・トランスポート・プロトコルを確立する機構を既に含んでいる。ＥＣＭＡ−３４８にメディア・コーディングおよびトランスポート・プロトコル拡張を追加することによって、ＣＳＴＡは、シグナリング・チャネルおよびメディア・チャネルを単一のステップで確立するように強化される。
【００５８】
別の実施形態では、メディア記述は、ＣＳＴＡアプリケーション関連付けの前のステップとして、サービス・アドレッシング、またはＷＳ−アドレッシング・プロトコルの拡張性を用いて伝達される。ＷＳ−アドレッシング（ＷＳＡ：WS-addressing）は、ウェブ・サービスのエンド・ポイントおよびメッセージをアドレッシングするためのトランスポート・ニュートラルの機構を提供する仕様である。ＣＳＴＡスイッチング機能とＣＳＴＡアプリケーションの両方は、ウェブ・サービスのエンド・ポイントである。ＷＳ−アドレッシングは、エンド・ポイント参照と呼ばれる新しい仕様を取り入れ、これは、ＷＳＤＬ内の  <wsdl:service>  および  <wsdl:port>  要素によって適切にカバーされていないサービスの動的な使用をサポートする。
【００５９】
ＷＳ−アドレッシングは、エンド・ポイント参照を表すためのＸＭＬドキュメント・タイプ（wsa:EndpointReferenceType）を定義する。ＸＭＬ要素、  wsa:EndpointReferenceもまた、そのタイプを有するように指定される。その両方は、ＸＭＬ名前空間  http://schemas.xmlsoap.org/ws/2004/03/addressing  内に常駐する。
【００６０】
ＷＳＡエンド・ポイント参照型は、以下を含むことができる。  
［アドレス］：エンド・ポイントを識別するＵＲＩ（ユニフォーム・リソース識別子）。  
［参照プロパティ］：<xs:any/>(0..unbounded)、特定のプロパティ、伝達される各エンティティまたはリソースのうちの１つ。  ［選択ポート・タイプ］：QName(0..1)、エンド・ポイントについてＷＳＤＬ内で定義される１次ポート・タイプの名前。  ［サービスおよびポート］：（QName, NCName(0..1))(0..1)、エンド・ポイントに対応する、ＷＳＤＬ内で定義されるサービスおよびポート。
［ポリシー］：エンド・ポイントの振舞い、要件および機能について記述する任意選択のＷＳ−ポリシー要素。
【００６１】
ＳＩＰの場合と同様に、ＣＳＴＡ音声サービスのために、オーディオ・チャネルの確立が必要である。オーディオ・チャネルを、ＳＤＰを介してＳＩＰで交渉することができるので、ＷＳＡエンド・ポイント参照は、音声サービス・プロバイダがメディア・ポイントを宣言するために、使用することができる。メディア・トランスポート・プロトコルおよび符号化機構は、音声サービスを容易にするために指定される必要がある重要アイテムに含まれる。こうしたアイテムは、参照プロパティとして宣言される。
【００６２】
堅牢性（robustness）を高めるために、ウェブ・サービス環境内のメディア・チャネルは、サーバ（ＣＳＴＡ音声リソース・プロバイダ）からクライアント（ＣＳＴＡアプリケーション）へのリースで、時間の経過により期限が切れるリースとしてモデル化される。サーバは、リース・マネージャを指定することもでき、その場合、クライアントがリースを取り消しまたは更新することができる。
【００６３】
ＸＭＬスキーマによる、ＣＳＴＡメディア・エンド・ポイント参照タイプは、１つまたは複数のＷＳＡエンド・ポイント参照を含む。たとえば、ポート６０６０でリアルタイム伝送プロトコル（ＲＴＰ）上のＧ．７１１プロトコルを使用するＣＳＴＡ音声サービス・プロバイダは、以下のようにメディア・ポイントを記述することができる。
【００６４】
【表１】
2006121673.tif 000003
【００６５】
ＣＳＴＡメディア・エンド・ポイント参照プロパティは、コーデック宣言、サブスクリプション識別子、および任意選択のリース満了宣言を含む。メディア・チャネルがシグナリング・チャネルと一緒に確立されるｕａＣＳＴＡの場合と同様に、上記のメディア・エンド・ポイント参照は、ウェブ・サービス環境下のＣＳＴＡアプリケーション関連付けプロセスが完了したと見なされる前に含められなければならない。
【００６６】
ＷＳプロトコルの拡張性を利用して、音声セッションは、  <wsa:Action>  を使用して確立することができる。メディア・エンド・ポイント参照は、それ自体、ＣＳＴＡウェブ・サービス・プロバイダのエンド・ポイント参照内の参照プロパティであることができる。単純オブジェクト・アクセス・プロトコル（ＳＯＡＰ）メッセージは、以下で示すように、  <wsa:To>  の直後にメディア・エンド・ポイント参照を付けることによって構成される。
【００６７】
【表２】
2006121673.tif 000004
【００６８】
ウェブ・サービスは、ＷＳ−ポリシーおよびＷＳＤＬなどのメタデータによって記述される。ＷＳ−ポリシーはサービスの一般的な機能、要件および特性について記述し、ＷＳＤＬは、抽象的なメッセージ操作、ならびにウェブ・サービスに到達するための具体的なネットワーク・プロトコルおよびアドレスについて記述する。ウェブ・サービス・メタデータ交換、ＷＳ−ＭＥＸまたはＷＳＸは、メタデータの取出しをブートストラップする仕様である。クライアントは、エンド・ポイントにＷＳ−ＭＥＸ要求を送信して、そのメタデータを取得することができる。ＳＯＡＰを使用した要求についての標準的な概要（normative outline）は、以下の通りである。
【００６９】
【表３】
2006121673.tif 000005
【００７０】
ＳＯＡＰヘッダに示すように、ＷＳ−ＭＥＸは、ＷＳ−アドレッシングを使用して、メタデータを取出すための要求を指定する。目標とされるサービスは、  <wsa:To>  内のＵＲＩとして指定され、また応答エンド・ポイントは、  <wsa:ReplyTo>  の内容のＷＳ−アドレッシング・エンド・ポイント参照を使用して指定される。取り出されるメタデータの型は、ＳＯＡＰ本体の  <wsx:GetMetadata>  の内容に指定される。
【００７１】
エンド・ポイントは、  GetMetadata  要求を受け入れる場合、  GetMetadata  応答メッセージで応答しなければならない。ＳＯＡＰ内の応答についての規範的な概要は、以下の通りである。
【００７２】
【表４】
2006121673.tif 000006
【００７３】
【表５】
2006121673.tif 000007
【００７４】
メタデータは、ＳＯＡＰ本体内で伝達され、  <wsx: Metadata>  要素の内容としてインライン（inline）で、あるいはＷＳ−アドレッシング・エンド・ポイント参照、または単純にＵＲＩを使用した参照によって、返されることが可能である。
【００７５】
上記ＳＯＡＰメッセージは、以下のように、ＷＳＤＬ結合を含むことができる。
【００７６】
【表６】
2006121673.tif 000008
【００７７】
ＣＳＴＡメディア記述は、ＣＳＴＡアプリケーションが音声サービス・プロバイダから取得しなければならないあるタイプのメタデータである。ＷＳ−ＭＥＸが、ここでは特に適している。以下は、メディア・エンド・ポイント参照を取り出すためのＳＯＡＰメッセージの一例である。
【００７８】
【表７】
2006121673.tif 000009
【００７９】
【表８】
2006121673.tif 000010
【００８０】
この例は、ＣＳＴＡ音声サービス・プロバイダ、  server,acme.org  にメディア・エンド・ポイント参照を要求する、  client.example.com  に位置するクライアント・アプリケーションを示している。特定の方言（dialect）が指定されているので、サーバは、所望のタイプのメタデータにだけ応答しなければならない。ＳＯＡＰ応答メッセージは、以下の通りである。
【００８１】
【表９】
2006121673.tif 000011
【００８２】
【表１０】
2006121673.tif 000012
【００８３】
音声アプリケーション記述は、音声サービスが提供し得る別のタイプのメタデータである。  <wsx: Dialect>  を介して  <wsa:GetMetadata>  にその各ＵＲＩを取り込むことによって、複数のメタデータ・タイプを同時に取得することができる。以下は、メディア・エンド・ポイント参照と音声アプリケーション参照の両方を取得するためのＳＯＡＰ本体（SOAP body）の一例である。
【００８４】
【表１１】
2006121673.tif 000013
【００８５】
【表１２】
2006121673.tif 000014
【００８６】
ウェブ・サービスは、一方向の要求応答モデルで開始するが、イベントが他のサービスまたはアプリケーションで発生するときに、メッセージを受信することをしばしば望む。ウェブ・サービス・イベンティング（eventing）  すなわちＷＳ−イベンティング（ＷＳＥ：Web Service Eventing）は、イベント通知を容易にするための仕様である。ＷＳ−イベンティングは、あるウェブ・サービスが別のサービスまたはアプリケーションの代理でどのようにイベントにサブ・スクライブすることができるかについて定義し、またアプリケーションがメッセージ送達のやり方を指定できるようにする。それは、様々なイベンティング・トポロジをサポートし、イベント・ソースと最終的なイベント・シンクが切り離されることを可能にする。こうしたプロパティは、コール・センタからモバイル・コンピューティングに渡る広範囲のＣＳＴＡアプリケーションに適している。ＣＳＴＡ音声サービスが機能するにはイベント通知が必要なので、ＷＳ−イベンティングの使用が提供される。
【００８７】
本発明について、特定の実施形態を参照して述べたが、本発明の精神および範囲から逸脱せずに、形および詳細の変更が行われ得ることが当業者には理解されよう。
【図面の簡単な説明】
【００８８】
【図１】本発明で使用するための例示的なコンピューティング装置を示す図である。
【図２】本発明で使用するための例示的なコンピューティング装置を示す図である。
【図３】本発明で使用するための例示的なコンピューティング装置を示す図である。
【図４】本発明で使用するための例示的なコンピューティング装置を示す図である。
【図５】分散音声サービスのための例示的なアーキテクチャを示す図である。
【図６】分散音声サービスを実装するための例示的なシステムを示す図である。
【図７】ＳＩＰ環境内でチャネルを確立するための例示的な方法を示す図である。
【図８】ウェブ・サービス環境内でチャネルを確立するための例示的な方法を示す図である。
【符号の説明】
【００８９】
２９  マイク
３０  データ管理装置（ＰＩＭ、ＰＤＡなど）の例示的な形  （クライアント）
３２  筐体
３３  スタイラス
３４  ディスプレイ
３５  ボタン
３６  キーパッド
３７  Ａ／Ｄ
４３  スピーカ
５０  
５２  無線トランシーバ
５４  ＲＡＭ
５８  ＲＯＭ
５９  Ｄ／Ａ
５４  ＲＡＭメモリ
６０  通信インターフェース
８０  電話機
８２  ディスプレイ
８４  キーパッド
１４０  処理装置
１５０  システム・メモリ（ＲＯＭ）
１５４  オペレーティング・システム
１５５  アプリケーション・プログラム
１５６  他のプログラム・モジュール
１５７  プログラム・データ
１６０  取外し不可能な不揮発性メモリ・インターフェース
１６４  オペレーティング・システム
１６５  アプリケーション・プログラム
１６６  他のプログラム・モジュール
１６７  プログラム・データ
１７０  取外し可能な不揮発性メモリ・インターフェース
１８０  ユーザ入力インターフェース
１８１  ポインティング装置
１８２  キーボード
１８３  マイク
１８４  モニタ
１８５  ビデオ・インターフェース
１８６  プリンタ
１８７  スピーカ
１８８  出力周辺インターフェース
１９０  ネットワーク・インターフェース
１９１  ローカル・エリア・ネットワーク
１９２  モデム
１９３  広域ネットワーク
１９４  リモート・コンピュータ
１９５  リモート・アプリケーション・プログラム
２０２  ウェブ・サーバ
２０４  音声サーバ
２０５  インターネット
２１０  第三者ＶＯＩＰゲートウェイ
２１２  電話音声ブラウザ
２１４  メディア・サーバ
２１６  音声ブラウザ
３００  システム
３０２  サーバ
３０４  クライアント
３１０  メディア・チャネル
３０８  シグナリング・チャネル
【図１】
2006121673.tif 000015
【図２】
2006121673.tif 000016
【図３】
2006121673.tif 000017
【図４】
2006121673.tif 000018
【図５】
2006121673.tif 000019
【図６】
2006121673.tif 000020
【図７】
2006121673.tif 000021
【図８】
2006121673.tif 000022