JP3703082B2 - 会話型バーチャル・マシンによる会話型コンピューティング - Google Patents

Description

【０００１】
本出願は、１９９８年１０月２日出願の米国仮特許出願第６０／１０２９５７号および１９９９年１月２７日出願の米国仮特許出願第６０／１１７５９５号に基づく。
【０００２】
【発明の属する技術分野】
本特許出願は、一般には会話型コンピューティングのシステムおよび方法に関する。より詳細には、本発明は、スタンドアロンＯＳ（オペレーティング・システム）として、または従来のＯＳまたはＲＴＯＳ（リアルタイム・オペレーティング・システム）上で稼動するプラットフォームまたはカーネルとして実施可能で、従来のプラットフォームおよびアプリケーションとの下位互換性を備えることも可能なＣＶＭ（会話型仮想計算機）を対象とする。本明細書に記載のＣＶＭは、会話型ＡＰＩ（アプリケーション・プログラム・インターフェース）、会話型プロトコル、および会話型ファウンデーション・クラスをアプリケーション開発者に開示し、対話およびコンテキスト、会話型エンジンおよびリソース、および異なる会話機能を有するプラットフォームおよび装置間の会話型プロトコル／通信の管理による会話型コンピューティングを実現するカーネル層を備え、汎用ＣＵＩ（会話型ユーザ・インターフェース）を提供する。
【０００３】
【従来の技術】
現在、最先端のアーキテクチャ、プラットフォーム、およびＯＳ（オペレーティング・システム）は基本的にＧＵＩ（グラフィカル・ユーザ・インターフェース）ベースであるかまたはＧＵＩカーネルを中核として構築されているため、ＰＣ（パーソナル・コンピュータ）およびワークステーションの分野では、ＧＵＩベースのＯＳが主流になっている。実際、ＵＩが主として音声とＤＴＭＦ（dual tone multifrequency）Ｉ／Ｏ（入出力）であるＩＶＲ（対話式音声応答）などの電話アプリケーションを除き、ほとんどの一般的な情報アクセスおよび管理アプリケーションは、ＧＵＩパラダイムを中心に構築されている。さらに、他の非ＧＵＩベースのＵＩは、メインフレームやきわめて専門的なシステムなどのより古いアーキテクチャと共に使用されている。一般に、ＧＵＩパラダイムでは、ユーザと機械との間のＵＩはグラフィックであり（たとえばマイクロソフトWindowsやUnix-X Windows）、各プロセスを別個のウィンドウとして表示することによってマルチタスク機能を実現し、それによって、各ウィンドウへの入力がキーボード、マウス、またはペンなどの他のポインティング・デバイスを介して行うことができる（ただし、プロセスによっては、ユーザと直接「対話／インターフェース」していないときには隠すこともできる）。
【０００４】
ＧＵＩは、時分割式メインフレームから個別計算機、およびサーバやバックエンド・サービスおよびアーキテクチャなどの他の階層へのパラダイム・シフトを喚起し、促した。ＧＵＩベースのＯＳは、情報へのアクセスと情報の管理のために従来のＰＣクライアント／サーバ・モデルで広く実施されてきた。アクセスされる情報は、装置上でローカルに、インターネットや専用イントラネットを介してリモートに、複数のパーソナル・コンピュータ、装置、およびサーバ上に置かれる場合がある。このような情報には、コンテンツ素材、トランザクション管理、および生産性向上ツールが含まれる。しかし、情報にアクセスし、管理するのに、従来のＰＣクライアント／サーバ・モデルから離れて、相互に接続され、ユーザがどこでも、いつでも、どの装置を介してでも情報にアクセスし、管理することができる、数十億のパーベイシブ・コンピューティング・クライアント（ＰｖＣクライアント）に向かう新しい傾向がある。しかも、この情報へのアクセスは、使用する装置やアプリケーションとは関係なく、情報とのインターフェースが同じである。この傾向は、装置の小型化やその機能と複雑さの飛躍的増大と同調している。それと同時に、電話が依然として情報にアクセスするための最も普及した通信装置であるため、電話を介した情報へのアクセスと管理の普及への同様の期待もさらに強くなっている。
【０００５】
しかし残念ながら、このような情報へのアクセスは、使用可能な装置やインターフェースによって制約されており、基礎となる論理は装置によって全く異なる。実際、この組込み分野における多様性と制約は、他の階層、すなわちデスクトップ、ワークステーション、バックエンド・サーバとは比較にならず、したがって、組込み分野はＵＩに重要な課題を提起している。さらに、ＰｖＣクライアントの複雑さの増大は、ますます制約が増えている入出力インターフェースと重なって、ＧＵＩの有効性を大幅に低下させる。実際、ＰｖＣクライアントは、ユーザが手や目を使わない対話を望むモバイル環境ではより頻繁に使用されている。いくつかの制約された機能を備えた組込み装置であっても、ＧＵＩは、超小型の表示装置には負担がかかりすぎ、乏しい電力とＣＰＵリソースを消費する。さらに、このようなＧＵＩは、制約のあるインターフェースと取り組むユーザをひるませ、使う気を失わせる。さらに、任意の装置を経由して任意の場所からいつでも情報にアクセスし情報を管理する遍在インターフェースについて最近明確化されたニーズはＧＵＩの限界を示している。
【０００６】
最近、コンピュータが使われるところでは至る所で、ボイス・コマンド・アンド・コントロール（ボイスＣ＆Ｃ）ＵＩが使われ始めている。実際、シュリンクラップ小売製品としての音声認識の最近の成功や、電話ＩＶＲ（対話型音声応答）インターフェースの一部としての導入の進行により、音声認識は今後重要なユーザ・インターフェース要素となることが明らかになっている。たとえば、電話会社、コール・センター、やＩＶＲは、音声インターフェースを実現して特定の作業を自動化し、オペレータの要件や運営コストを減らし、通話処理の迅速化を図っている。しかし現段階では、ＩＶＲアプリケーション開発者は、それぞれ独自のプロピライエタリ音声エンジンおよびＡＰＩ（アプリケーション・プログラム・インターフェース）を提供している。対話の開発は複雑なスクリプト記述と熟練したプログラマを必要とし、これらのプロピライエタリ・アプリケーションは、一般に、ベンダからベンダへと移植されない（すなわち、各アプリケーションは特定業務論理向けに丹念に作られ、設計される）。
【０００７】
さらに、ＧＵＩベースのＯＳ用の音声インターフェースは、口述筆記やコマンド・アンド・コントロール用の市販の連続音声認識アプリケーションを使用して実施されてきた。しかし、このような音声アプリケーションは、キーボードやマウスの代替となり、ユーザが対象を変えて新しいタスクを開始できるようにし、対象としているタスクに音声コマンドを与えることができるようにするという意味で、基本的にＧＵＩベースのＯＳの付加機能である。実際、このような音声インターフェースを提供している現在のベンダおよび技術開発業者はすべて、ＧＵＩメニューに焦点を合わせ、選択するためのキーボードまたはポインティング・デバイスを直接置き換えるために、音声またはＮＬＵ（自然言語理解）をコマンド行入力として組み込むことに依存している。このようなアプリケーションでは、音声は、ヒューマン／マシン対話の根本的変化の方向ではなく、新しい追加のＩ／Ｏモダリティとみなされている。
【０００８】
会話システムとしての音声、ＮＬＵ、またはその他の入出力インターフェースの実現は、オペレーティング・システムへの表面的な組込みに限られるべきではない。また、組込み装置間での遍在的ルック・アンド・フィールに限られるべきでもない。基礎となるオペレーティング・システムとコンピューティング機能の設計を根本的に変えるべきである。さらに、入出力媒体での柔軟性により、オペレーティング・システムの最も根本的変革には音声入出力を必要とせず、より一般的なキーボード、マウス、またはペン入力およびディスプレイ出力でも実現可能である。
【０００９】
【発明が解決しようとする課題】
したがって、既存のアプリケーションへの音声入出力または会話機能の付加、会話型アプリケーションの構築、従来のオペレーティング・システムへの「音声」の表面的な組込みをはるかに超える、汎用会話型ユーザ・インターフェースを介した複数のプラットフォーム、装置、およびアプリケーションにわたる会話型コンピューティングを提供するシステムがきわめて望ましい。
【００１０】
【課題を解決するための手段】
本発明は、汎用会話型ユーザ・インターフェース（ＣＵＩ）を介した会話型コンピューティングを提供する会話型コンピューティング・パラダイムに基づくシステムおよび方法を対象とする。この会話型コンピュータ・パラダイムは、システムがユーザ対話して、照会とその実行結果の遂行、一義化、または修正を行うことを規定する。これらは、コンテキスト、アプリケーション、履歴、およびユーザの選好とバイオメトリックに基づいて、照会、コンテキスト、および操作情報を抽出し、扱う。これらの中核原理は、音声使用可能入出力インターフェースを必要とせず、基礎となるコンピューティング・コアに深く浸透する。実際、本発明による会話型コンピューティング・パラダイムは、音声のない場合にも適用され、対話がたとえばキーボードを介して行われる場合であっても、対話および会話を中心に構築されたコンピューティングの本質を表す。ＶＴ１００やPalm Pilot画面などのダミー端末ディスプレイを介する場合でも、ユーザが、たとえば並列して稼動している複数のWindowsアプリケーションをシームレスに制御することができるようにするのが、会話型コンピューティング・パラダイムである。
【００１１】
本発明の一態様では、会話型パラダイムに基づく会話型コンピューティングを提供するシステムは、スタンドアロンＯＳ（オペレーティング・システム）として、または、従来のＯＳまたはＲＴＯＳ（リアルタイム・オペレーティング・システム）上で稼動するプラットフォームまたはカーネルとして実施され、従来のプラットフォームおよびアプリケーションとの下位互換性を備えることも可能なＣＶＭ（会話型仮想計算機）である。このＣＶＭは、会話型ＡＰＩ（アプリケーション・プログラム・インターフェース）、会話型プロトコル、および会話型ファウンデーション・クラスをアプリケーション開発者に開示し、対話およびコンテキスト、会話型エンジンおよびリソース、および異なる会話機能を有するプラットフォームおよび装置間での会話型プロトコル／通信を管理することにより、会話型コンピューティングを実施するカーネルを提供して、汎用ＣＵＩ（会話型ユーザ・インターフェース）を提供する。このＣＶＭカーネルは、登録された会話機能および要件に基づいてアプリケーションおよび装置間の対話を制御する中核層である。また、入出力モダリティとして音声を付加して会話型システム動作を実現するにとどまらない統一会話型ユーザ・インターフェースも提供する。ＣＶＭは、ディスコース、コンテキスト、混在主導権（mixed initiative requests）、抽象化の能力による会話に類似した方式でタスクを管理することができる。
【００１２】
本発明の一態様では、ＣＶＭは、音声認識、話者認識、テキスト−音声、自然言語理解、および自然対話生成エンジンを含む会話型サブシステム（ローカルと分散型のいずれともすることができる）を使用して、ユーザと機械との対話の理解と生成を行う。これらのサブシステムには、ＣＶＭを介してアクセスする。これらのエンジンは、会話型アプリケーションＡＰＩを介してアプリケーションに対して隠蔽される。ＣＶＭは、このようなエンジンを会話型エンジンＡＰＩを介して制御することができる。さらに、会話型ＡＰＩは会話型エンジンＡＰＩを含むことができる。典型的には、ＣＶＭはこれらのエンジンＡＰＩをアプリケーション開発者に直接開示する機能を含む。これは、会話アプリケーションＡＰＩに含まれた会話エンジンＡＰＩを有することによって、または会話アプリケーションＡＰＩのレベルでの類似の呼出しおよび機能をエミュレートすることによって行うことができる。
【００１３】
他の態様では、ＣＶＭカーネル層（またはＣＶＭコントローラ）が、対話を管理し、アクティブな対話、コンテキスト、およびアプリケーションを選択する、メタ情報マネージャと、リソース・マネージャと、コンテキストスタックと、グローバル履歴と、対話マネージャと、タスク・ディスパッチャとを含む。コンテキストスタックは、アクティブ化されたディスコースを使用する各アクティブ・プロセスのコンテキスト（完全照会引数および状態／モード、すなわちすでに導入済みの照会引数、任意の入出力イベント、およびアプリケーションによって生成されたイベント）を、入力理解に必要なデータ（たとえば、音声入力のためのアクティブＦＳＧ、トピック、語彙、または可能な照会）と共に蓄積する。ＣＶＭカーネルは、ローカルおよびネットワーク化された従来型および会話型のリソース上で生成される異なるタスクおよびプロセス間の調整を行う。ＣＶＭカーネル層は、これらのリソースを追跡し、入力を適切な会話サブシステムに送り、装置、状態、アプリケーション間の調停を行う。ＣＶＭカーネル層は、アクティブ会話および会話履歴に従った出力生成および優先順位付け、遅延戻り、ネットワーク・リソース間の委任、およびタスク委任および記憶の調整も行う。
【００１４】
本発明の他の態様では、ＣＶＭシステムは、オブジェクト、データ・ストリーム・ハンドル、ネットワーク、周辺装置、ハードウェア、ローカルおよびネットワーク化ファイル・システムなどの要素に関連付けられたメタ情報を介して高水準の抽象化および抽象カテゴリも備える。本発明の一態様による抽象メタ情報システムは、リソースの所有者／開発者またはリソースの過去の使用者／アプリケーションによって定義された複数のカテゴリを含む。このような要素には、抽象ショートカットおよび混在主導権要求を介してアクセスすることができる。接続時、またはオブジェクトまたはそのコンテキストに関連付けられた抽象カテゴリのリストを更新し、各リソースがその機能を登録する抽象化のテーブルのように機能する（ＤＮＳサーバまたはネーム空間マネージャと類似した）メタ情報サーバを介して、新規オブジェクトに関連付けられた新規カテゴリを自動的に作成するための登録プロトコルを備える。ダウンロードまたは転送されたオブジェクトは、同じプロトコルを使用してローカルで登録することができる。抽象メタ情報を使用して、ネットワークの要素のショートカット、自動抽出、または処理を行うことができる。
【００１５】
他の態様では、ＣＶＭは、（複数のドメインによる）複数のタスク、プロセス、およびディスコースにわたって記憶されたＮＬＵ、ＮＬＧ、コンテキスト、および混在主導権を有する機能を備える。会話型入力インターフェースを備え、それによって、マルチモード入力ストリームのセットがそれぞれＡＳＣＩＩコマンドまたは照会（すなわち、属性値ペアまたはｎタプルのリスト）に書き換えられる。各入力エンティティ（コマンド、ＮＬＵ照会フィールドまたは引数ユニット（分離された文字、語など）にタイム・マークが関連付けられ、複合入力ストリームに付加される。同じタイム・マークを持つ２つ以上のストリームは、各入力ストリームが前に寄与した時点に基づいて、または各アプリケーション／入力ストリームがコンテキスト履歴に基づいて受け取った優先順位に基づいて、優先順位付けされる。複合入力は、可能なＦＳＧおよび辞書と対照され、任意選択により、ユーザにフィードバックされる。各リソースは、それぞれの会話型機能を交換し、入力ストリームは該当する情報のみを交換するように調整される。
【００１６】
他の態様では、会話型出力ディスパッチおよびインターネット・プロトコルを備え、それによって複数のタスクの出力が、コンテキスト・スタックおよびタスク・ディスパッチャに基づいて単一チャネル出力に待ち行列化される。多重化されている場合であっても、各入力ストリームに割り当てられたリソースをリダイレクトまたは修正する機構を設ける。各リソースはその会話型機能を交換し、出力ストリームは、出力Voiceフォントの選択と会話プレゼンテーションの形式設定を含めて、該当する情報のみを交換するように調整される。
【００１７】
他の態様では、任意の使用可能なリソースを入力ストリームまたは出力ストリームとして使用できるようにするプログラミング／スクリプト言語を使用する。会話サブシステムを使用して、各入力はバイナリまたはＡＳＣＩＩ入力（属性値ペアまたはｎタプルのリスト）に変換され、これは組込みオブジェクトとしてプログラミング言語が直接することができる。呼出し、フラグ、およびタグが自動的に組み込まれ、オブジェクトとプロセスの間で、異なるオブジェクトと正しくインターフェースするのに必要な会話メタ情報を伝達する。実際、任意のモダリティの任意の入力が、関連付けられたコンテキストまたはコンテキスト・スタックに追加されるイベントとして対話マネージャによってＣＶＭカーネル層によって取り込まれる。たとえば、マウスのクリックまたはポインタ／スタイラスの指示アクションの後に、「I would like to open this（これを開きたい）」というコマンドが続くと、それは属性値ペアのセットCommand: Open, Object:Windows、または最後のマウス・クリックで選択されたタスクに一義化される。出力はアプリケーションまたはユーザの必要に応じて特に形式設定することができる。新しいプログラミング・ツールを使用してマルチモーダルディスコース処理を容易に構築することができるようになっている。さらに、このようなプログラミング言語およびスクリプトは、会話使用可能アプリケーションとＣＶＭ、およびＣＭＬ（会話マークアップ言語）の間での会話型ＡＰＩを含む。
【００１８】
他の態様では、それぞれのＡＳＣＩＩ／バイナリ・コンテンツに基づいて、またはそれぞれのＮＬＵ変換照会／属性値ｎタプルのリストに基づいて比較可能な、豊富な会話型照会を扱うように、会話論理ステートメント・ステータスおよび演算子を拡張する。このようなシステムをテストまたは修正する論理演算子を実現する。
【００１９】
他の態様では、複数の会話型装置またはアプリケーションが、会話認識のみするサイレント・パートナを含めて、それぞれの会話型機能を登録することができる会話型ネットワーク接続プロトコルを備える。
【００２０】
会話型プロトコルを備えて、複数のＣＶＭおよびサイレント・パートナとの会話を調整し、複数のＣＶＭ装置が会話型接続され、調整されると、単一のインターフェースを介して（たとえば単一のマイクロフォンを介して）それらを同時に制御することができるようになるようにする。互いを検出し、それぞれの識別情報を登録した後、各システムまたは装置はそれぞれの会話型機能に関する情報を交換し、データ転送を関連する情報のみに限定する。サイレント会話パートナも同様に振舞い、会話プロキシ・サーバを介して、またはＣＶＭの会話型クライアントとして対話することができる。複数のＣＶＭ間の調整には、複数の会話接続された装置／オブジェクトによって提示される調整された一様な会話型インターフェースを提供するために動的マスタ−スレーブ対話およびピア・ツー・ピア対話を行うこともできる。さらに、互いにピア・ツー・ピア式に対話する（全体的なネットワーク・トラフィックおよび対話フロー遅延を減らすように最適化または決定された）複数のローカル・マスタ他のトポロジも考慮することができる。オブジェクトの集合が、集中または分散コンテキスト・スタックを介してユーザに単一の調整されたインターフェースを提示することができる。
【００２１】
他の態様では、開発者がＣＶＭ用の会話認識アプリケーションの作成、シミュレート、デバッグを行うための開発ツールも設ける。この開発ツールは、ＡＰＩ呼出し、プロトコル・呼出し、これらのＡＰＩおよびプロトコルを使用したアプリケーションの直接実施、関連付けられたライブラリ、ＣＶＭが提供するサービスおよび動作を利用するアプリケーションのリンク機能を提供する。これらの開発ツールによって、Voiceフォントなど、複数のパーソナリティによる会話型インターフェースの構築が可能になり、それによってユーザは出力データを提供する音声のタイプを選択することができる。PostscriptやＡＦＬ（オーディオ・フォーマッティング言語）などの会話プレゼンテーションを構築する会話型形式設定言語を備える。これらのアプリケーションを実施するコードは、宣言型または手続き型とすることができる。これは、インタプリタ型またはコンパイラ型スクリプトおよびプログラムを、ライブラリ・リンク、会話型論理、エンジン呼出し、および会話型ファウンデーション・クラスと共に含む。会話型ファウンデーション・クラスは、モダリティまたはモダリティの組合せとは関係なく、どのような対話でも特徴付ける基本構成要素または会話ジェスチャである。
【００２２】
他の態様では、ローカルまたはリモート・ファイル、特に実行可能ファイルの作成者または変更者あるいはその両方に関するメタ情報を使用して会話型セキュリティを設け、無許可のアクセスを防止する。ＣＶＭは、制限されたリソースへの照会が行われるたびに、そのリソースに関連付けられたセキュリティ・メタ情報に基づいて、ユーザの自動認証を行う。この認証は、要求に対して直接または、照会の前に取得した有効期限切れになっていない情報に対して行われる。
【００２３】
他の態様では、ＣＶＭは、会話カスタマイズ機能を備える。リソースへの照会が行われると自動的にユーザが識別される。この認証は、要求に対して直接または、照会の前に取得した有効期限切れになっていない情報に対して行われる。各タスクまたはリソース・アクセスを、要求者の選好に合わせて個別にカスタマイズすることができる。タスクおよびコンテキストは、アクティブ・ユーザの順序に従って優先順位付けされ、ユーザ変更のたびに優先順位付けし直される。ユーザ識別の変更に基づいて、環境変数をオンザフライで修正することができ、環境全体をリセットする必要がない。曖昧性は、ユーザ識別を使用して各コンテキストまたはコンテキスト・スタックのレベルで解決される。
【００２４】
他の態様では、ファイルの名前、修正、またはＡＳＣＩＩコンテンツだけでなく、オペレーティング・システム、アプリケーション、またはユーザによって定義された抽象カテゴリや、オペレーティング・システムによってオンラインまたはオフラインで抽出されたトピック、またはオブジェクトにアクセスしたときに会話プロトコルを介して入手したトピックにも基づく、会話型探索機能を備える。さらに、アクティブ照会を完成させたり、または類似の照会／コンテキストを抽出するコンテキスト探索機能を備える。
【００２５】
他の態様では、リソース・マネージャ・レベルで、またはメタ情報、抽象化、会話型照会／混在主導権／修正に依存するアプリケーション会話型選択機能を備える。このような会話型選択機能により、基本選択の長いシーケンスが回避され、選択の自然なショートカットおよび修正が実現される。さらに、階層構造を備えたオブジェクトのスケルトンに直ちにアクセスし、提示する機構を備える。
【００２６】
他の態様では、ローカルおよびリモート・リソース、エージェントおよびユーザの利用履歴を使用して、要求の完成、手続きのガイド、情報の探索、および新規アプリケーションのアップグレード／インストールを行う、汎用調整会話型インターフェースを介した会話型ヘルプ、マニュアル、およびサポートを備える。さらに、ヘルプ情報にアクセスするＮＬＵ照会を使用して、または現行ユーザ（履歴）に関連付けられたメタ情報に基づいて、または欠落したり混在主導権を使用して修正されたりした引数に基づいて、ヘルプ情報にアクセスすることができる。各アプリケーションが備えるダイアログは、ユーザの選好または専門知識のレベルに合わせて調整される。
【００２７】
本発明によるＣＶＭが備えるその他の特徴としては、最小の学習曲線で済む単純で直観的で自然なインターフェース、音声の使用により生産性が大幅に向上する魅力的な会話型アプリケーション、新機能または使用法、自然照会を理解することができる高機能な機械／装置、ハンドフリーまたはアイフリー・モードで作業を効率的に行うことができる機能、会話型ユーザ入出力を捕捉し、必要に応じて置き換える魅力的なマルチモード高生産性ユーザ・インターフェース（ディスプレイなしかまたは小型ディスプレイ、キーボード、ペン、ポインティング・デバイスなし、リモート・コンピューティングなど）、アクセスのために使用する装置（ＰＣ、ＰＤＡ、電話など）とは独立し、トランザクション／サービス／アプリケーションとも独立した汎用ユーザ・インターフェース、１つの装置が複数の他の装置を制御することができるようにする複数の会話型装置間で調整されたインターフェース、既存のＯＳ、アプリケーション、装置、およびサービスとの下位互換性がある。
【００２８】
【発明の実施の形態】
本発明は、会話型システムおよびマルチ・モーダル・インターフェースのすべての態様を組み込む会話型コンピューティングのためのシステムおよび方法を対照とする。本明細書に記載の会話型コンピューティング・パラダイムによる会話型コンピューティングを実現する重要な構成要素は、ＣＶＭ（会話型仮想計算機）である。一実施形態では、このＣＶＭは、従来のＯＳまたはＲＴＯＳ上で稼動する会話型プラットフォームまたはカーネルである。ＣＶＭプラットフォームは、ＰｖＣ（パーベイシブ・コンピューティング）クライアントおよびサーバによって実施することもできる。一般に、ＣＶＭは、会話サブシステム（たとえば音声認識エンジン、テキスト−音声合成など）と会話型または従来型あるいはその両方のアプリケーションとの間での会話型ＡＰＩおよびプロトコルを実現する。また、ＣＶＭは、より限定されたインターフェースを備えた既存のアプリケーションとの下位互換性も備えることができる。後述するように、ＣＶＭは、会話型サービスおよび動作だけでなく、ＣＶＭ層または少なくとも会話認識機能を備えた複数のアプリケーションおよび装置との対話のための会話型プロトコルも提供する。
【００２９】
本明細書に記載の様々な要素およびプロトコル／ＡＰＩは、それぞれが実行する機能またはそれぞれが交換する情報に基づいて定義されることを理解されたい。それらの実際の編成または実施態様は様々とすることができ、たとえば同一または異なるエンティティによって実施され、より大きな構成要素の構成要素として、または独立してインスタンス化されたオブジェクト、またはそのようなオブジェクトまたはクラスのファミリとして実施することができる。
【００３０】
本発明による本明細書に記載の会話型コンピューティング・パラダイムに基づくＣＶＭ（またはオペレーティング・システム）により、コンピュータまたはその他の任意の対話型装置はユーザと会話することができる。さらにＣＶＭにより、ユーザは、機械にディスプレイやＧＵＩ機能がなく、キーボード、ペン、またはポインティング・デバイスがない場合でも関係なく、その機械上で複数のタスクを実行することができる。実際に、ユーザはこれらのタスクを会話と同様に管理することができ、１つのタスクまたは複数の同時タスクを終了させることができる。タスクを会話のように管理するために、本発明によるＣＶＭは、混在主導権、コンテキスト、および高レベルの抽象化に依存して様々な機能を実行する機能を備える。混在主導権により、ユーザはシステムとの対話を通して要求を自然に完成、変更または修正することができる。また混在主導権とは、ＣＶＭが、タスク全体を通じて、特に音声使用可能アプリケーションにおいて、ユーザを積極的に支援し（主導して支援し）、指示することを意味し、この場合、混在主導権機能はディスプレイのないシステムや限られたディスプレイ機能しかないシステムを補う自然な方法である。一般には、ＣＶＭは従来のインターフェースおよび入出力を置き換えるのではなく、それらを補うものである。これは、音声をマウス、キーボード、およびペンなどの他の入出力装置と併用する「マルチモダリティ」という概念である。装置の限界に特定のインターフェースの実現が含まれる場合、従来のインターフェースを置き換えることができる。さらに、その結果のインターフェースの装置、層、およびサービス間での遍在性と一様性も不可欠の特性である。ＣＶＭシステムは、大体において従来の入力媒体または出力媒体あるいはその両方と共に機能することができることを理解されたい。実際に、従来のキーボード入力および従来のモニタ・ディスプレイに接続されたポインティング・デバイスを備えたコンピュータは、本発明によるＣＶＭを利用することにより大きな利益を得ることができる。一例は、米国仮特許出願第６０／１２８０８１号に記載されている（これには、ＧＵＩモダリティと音声モダリティとが緊密に同期した真のマルチモーダル・アプリケーションを作成する方法が記載されている）。言い換えると、コンピュータに話しかけなくないユーザでも、ＣＶＭ使用可能機械との対話へのダイナミックで積極的な移行を認識することができる。
【００３１】
次に図１を参照すると、クライアント装置またはサーバで実施可能な本発明の一実施形態による会話型コンピューティング・システム（またはＣＶＭシステム）がブロック図に示されている。一般に、ＣＶＭは汎用調整マルチモーダル会話型ユーザ・インターフェース（ＣＵＩ）１０を備える。ＣＵＩの「マルチモーダリティ」態様とは、音声、キーボード、ペン、ポインティング・デバイス（マウス）、キーパッド、タッチ・スクリーンなどの様々な入出力リソースを、ＣＶＭプラットフォームと共に使用することができることを意味する。ＣＵＩ１０の「一様性」態様とは、ＣＶＭがデスクトップ・コンピュータ、ディスプレイ機能が制限されたＰＤＡ、ディスプレイを備えない電話と共に実施されているか否かを問わず、ＣＶＭシステムが同じＵＩをユーザに提供することを意味する。言い換えると、一様性とはＣＶＭシステムが、音声のみのものから、音声、マルチモーダルすなわち音声＋ＧＵＩ、さらにＧＵＩのみのものまでの範囲の機能を持つ装置のＵＩを適切に扱うことができることを意味する。したがって、汎用ＣＵＩは、アクセス・モーダリティに関係なく、すべてのユーザ対話に同じＵＩを提供する。
【００３２】
さらに、汎用ＣＵＩの概念は、調整ＣＵＩの概念にまで拡大する。具体的には、（コンピュータ層内または複数のコンピュータ層にわたる）複数の装置が同じＣＵＩを提供すると仮定すると、それらの装置を単一のディスコースすなわち調整インターフェースを介して管理することができる。すなわち、複数の装置が会話接続されている（すなわち互いに認識している）場合、それらを１つの装置の１つのインターフェース（たとえば単一のマイクロフォン）を介して同時に制御することができる。たとえば、汎用調整ＣＵＩを介して、会話接続された高度自動機能電話、ページャ、ＰＤＡ、ネットワーク・コンピュータ、およびＩＶＲ、車載コンピュータを音声による自動的に制御することができる。これらのＣＵＩ概念については、後で詳述する。
【００３３】
さらにＣＶＭシステムは、会話認識アプリケーション１１（すなわち会話プロトコルを「話す」アプリケーション）と従来型アプリケーション１２を含む複数のアプリケーションを含む。会話認識アプリケーション１１は、会話型アプリケーションＡＰＩ１３を介してＣＶＭコア層（またはカーネル）１４と共に動作するように特にプログラムされたアプリケーションである。一般に、ＣＶＭカーネル１４は、アプリケーションと装置間の対話をそれらの登録された会話型機能および要件に基づいて制御し、入出力モーダリティとして音声を追加して会話型システム動作を実現するだけにとどまらない統一された会話型ユーザ・インターフェースを提供する。ＣＶＭシステムは、従来のＯＳとＡＰＩ１５、および従来の装置ハードウェア１６上に構築することができ、サーバまたは任意のクライアント装置（ＰＣ、ＰＤＡ、ＰｖＣ）上に置くことができる。従来型アプリケーション１２は、ＣＶＭカーネル層１４によって管理される。ＣＶＭカーネル層１４はＯＳ ＡＰＩを介して従来型アプリケーションのＧＵＩメニューおよびコマンドと、基礎ＯＳコマンドとにアクセスする。ＣＶＭは、会話サブシステム１８（すなわち会話エンジン）および従来のＯＳ１５の従来型サブシステム（たとえばファイル・システムや従来のドライバ）を含む、すべての入出力発行を自動的に扱う。一般に、会話サブシステム１８は、適切なデータ・ファイル１７（たとえば、コンテキスト、有限状態文法、語彙、言語モデル、記号照会マップなど）を使用して、音声要求を照会に変換し、出力をおよび結果を発話メッセージに変換する機能を果たす。会話型アプリケーションＡＰＩ１３は、ＣＶＭ１４が照会をアプリケーション呼出しに変換し、逆に出力を音声に変換して、ユーザに提供する前に適切に記憶されるすべての情報を伝達する。
【００３４】
次に図２を参照すると、本発明の一実施形態による会話型コンピューティング・システム（またはＣＶＭ）の抽象プログラミング層が図示されている。ＣＶＭの抽象層は、会話認識アプリケーション２００と従来型アプリケーション２０１とを含む。上述のように、会話認識アプリケーション２００は、会話型アプリケーションＡＰＩ層２０３を介してＣＶＭカーネル層２０２と対話する。会話型アプリケーションＡＰＩ層２０３は、ＣＶＭカーネル２０２が備える様々な機能（後述する）を提供するための会話型プログラミング言語／スクリプトおよびライブラリ（会話型ファウンデーション・クラス）を含む。たとえば、会話型プログラミング言語／スクリプトは、アプリケーション開発者が会話認識アプリケーション２００をフック（または開発）することができるようにする会話型ＡＰＩを備える。また、会話型ＡＰＩ層２０３、会話型プロトコル２０４、および、開発者が会話機能をアプリケーションに組み込んで「会話認識型」にすることができるようにするシステム呼出しも備える。アプリケーション、ＡＰＩ呼出し、およびプロトコル呼出しを実現するコードには、ライブラリ・リンク、（後述する）会話型論理エンジン呼出し、および会話型ファウンデーション・クラスを備えるインタプリタ型およびコンパイラ型のスクリプトおよびプログラムが含まれる。
【００３５】
具体的には、会話型アプリケーションＡＰＩ層２０３は、複数の会話型ファウンデーション・クラス２０５（または基本対話構成要素）を含み、これは、本発明によるＣＵＩまたは会話認識アプリケーション２００を構築するために使用することができるライブラリ関数を介してアプリケーション開発者に提供される。会話型ファウンデーション・クラス２０５は、基本構成要素または会話ジェスチャ（T.V.Raman（ラーマン）が「Auditory User Interfaces, Toward The Speaking Computer」Kluwer Academic Publishers, Boston 1997で記載している）であり、任意の対話を、モダーリティまたはモダーリティの組合せ（手続き式または宣言式に実施可能である）とは独立して特徴づける。会話型ファウンデーション・クラス２０５は、ＣＵＩビルディング・ブロック、会話型プラットフォーム・ライブラリ、対話モジュールおよび構成要素、および対話スクリプトおよびビーンを含む。会話型ファウンデーション・クラス２０５は、ローカルで会話型オブジェクト２０６にコンパイルすることができる。具体的には、会話型ファウンデーション・オブジェクト２０６（または対話構成要素）は、Java( 登録商標 )やＣ＋＋などのプログラミング言語によって、これらのライブラリを呼び出すコード中の異なる個別のクラスを組み合わせることによって、会話型ファウンデーション・クラス２０５（ファウンデーション対話構成要素）からコンパイルされる。上述のように、コーディングはそのような基本対話構成要素を宣言型コードに組み込むこと、またはそれらを手続き型コードにリンクすることを含む。会話型ファウンデーション・クラス２０５をネストし、埋め込むことによって、特定の対話タスクまたはアプリケーションを実行する（再使用可能または再使用不能）会話型オブジェクト２０６を（宣言式またはコンパイル／インタプリテーションを介して）作成することができる。たとえば、会話型オブジェクト２０６は、ＣＭＬ（会話型マークアップ言語）のページなど（ネストしているか否かを問わず）、宣言式に実現することができ、会話型ブラウザ（またはビューワ）（２００ａ）によって処理またはロードされる。対話オブジェクトは、（会話型ブラウザを介して）ＣＭＬ（会話型マークアップ言語）ページによりロード可能なアプレットまたはオブジェクトと、ＣＶＭ上の手続き型オブジェクト（ＣＶＭ上で分散可能）、ＣＭＬ内のスクリプト・タグ、およびサーブレット構成要素を含む。
【００３６】
本発明により実施可能な会話型ジェスチャのいくつかの例は以下の通りである。会話型ジェスチャ・メッセージは、機械が情報メッセージをユーザに伝達するために使用する。ジェスチャ・メッセージは、一般には、表示文字列または音声プロンプトとして表される。メッセージのうちの発話される部分は、ＣＶＭ上で稼動する様々なアプリケーション／対話の現行状態に応じて変わることができる。「select from set（セットから選択）」という会話ジェスチャを使用して、個別の選択肢のセットから選択することをユーザに求める対話をカプセル化する。これは、プロンプト、デフォルト選択、および妥当な選択肢のセットをカプセル化する。「select from range」という会話型ジェスチャ・メッセージは、ユーザが連続した値の範囲から値を選択することができる対話をカプセル化する。このジェスチャは、有効な範囲、現行選択、および情報プロンプトをカプセル化する。さらに、入力制約がより複雑な場合（または場合によっては存在しない場合）に、会話ジェスチャ入力を使用してユーザ入力を入手する。このジェスチャは、ユーザ・プロンプト、要求されている情報項目（未定）に関するアプリケーション・レベルのセマンティクス、および場合によっては入力の有効性を検査するための述語をカプセル化する。上述のように、会話型ファウンデーション・クラスは、会話型ジェスチャの概念を含むが、これだけには限定されない（すなわち、基本動作およびサービスのレベルや、会話型タスクを実行するための規則にも及ぶ）。
【００３７】
後述するように、プログラミング・モデルは、会話型ＡＰＩを介したマスタ対話マネージャとエンジンとの接続を可能にする。ファウンデーション・クラスのデータ・ファイルはＣＶＭ上に存在する（組込みプラットフォームのためにロード可能）。オブジェクトのデータ・ファイルは、展開およびロード可能である。異なるオブジェクトが同時に対話マネージャとして機能する。いくつかの会話型ファウンデーション・クラスの例を以下に示す。
【００３８】
低水準対話の会話型ファウンデーション・クラス：
（該当する場合に使用可能なマルチモーダル機能）
（分散の場合ＣＶＭハンドルを含む）
1. Select_an_item_from_list（リストから項目を入手）
2. Field_filling_with_grammar（フィールドに文法を記入）
3. Acoustic_Enroll_speaker_（話者を音響登録）
4. Acoustic_Identify_speaker（話者を音響識別）
5. Acoustic_Verify_speaker（話者を音響識別）
6. Verify_utterance（発言を検証）
7. Add_to_list（リストに追加）
8. Enroll_utterance（発言を登録）
9. Get_input_from_NL（ＮＬから入力を入手）
10. Disambiguate（一義化）
など
【００３９】
低水準特殊化対話の会話型ファウンデーション・クラス
（該当する場合に使用可能なマルチモーダル機能）
（分散の場合ＣＶＭハンドルを含む）
1. Get_Yes/No（Yes/Noを入手）
2. Get_a_date（日付を入手）
3. Get_a_time（時刻を入手）
4. Get_a_natural_number（自然数を入手）
5. Get_a_currency（通貨を入手）
6. Get_a_telephone_number（米国または国際電話番号を入手。規則などを指定可能。）
7. Get_digitstring（数字ストリングを入手）
8. Get_alphanumeric（英数字を入手）
9. Get_spelling（スペルを入手）
10. Speech_biometrics_identify（発話バイオメトリックの識別）
11. Open_NL（ＮＬを開く）
12. Close_NL（ＮＬを閉じる）
13. Delete_NL（ＮＬを削除）
14. Save_NL（ＮＬを保存）
15. Select_NL（ＮＬを選択）
16. Mark_NL（ＮＬをマーク）
など
【００４０】
中水準対話の会話型ファウンデーション・クラス
（該当する場合に使用可能なマルチモーダル機能）
（分散の場合ＣＶＭハンドルを含む）
1. Form_filling（書式記入）
2. Request_confirmation（要求確認）
3. Identify_user by dialog（対話によりユーザを識別）
4. Enrol_user by dialog（対話によりユーザを登録）
5. Speech_biometorics_identify（音声バイオメトリクスを識別）
6. Verify_user by dialog（対話によるユーザの検証）
7. Correct_input（入力を修正）
8. Speech_biometrics_identify（音声バイオメトリクスを識別）
9. Speech_biometrics_verify（音声バイオメトリクスを検証）
10. Speech_biometrics_enrol（音声バイオメトリクスを登録）
11. Manage_table（テーブルの管理）
12. Fill_free_field（フリー・フィールドへの記入）
13. Listen_to TTS（ＴＴＳを聞く）
14. Listen_to_playback（再生を聞く）
15. Simulltaneous_form_filling（同時書式入力）
16. Simultaneous_classes_dialog（同時クラス対話）
17. Summarize_dialog（対話を要約）
など
【００４１】
高水準アプリケーション固有ファウンデーション・クラス
（該当する場合に使用可能なマルチモーダル機能）
（分散の場合ＣＶＭハンドルを含む）
1. Manage_bank_account（銀行口座の管理）
2. Manage_portfolio（有価証券の管理）
3. Request_travel_reservation（旅行予約の要求）
4. Manage_e-mail（電子メールの管理）
5. Manage_calender（カレンダーの管理）
6. Manage_addressbook/director（アドレス帳／電話帳の管理）
など
【００４２】
通信会話クラス
1. Get_list_of CVM_devices（ＣＶＭ装置のリストを入手）
2. Get_capability_of_CVM_device（ＣＶＭ装置の機能を入手）
3. Send_capability_to_CVM_device（ＣＶＭ装置に機能を送る）
4. Request_device_with_given_capability（所定の機能付き装置を要求）
5. Get_handle_from_CVM_device（ＣＶＭ装置からハンドルを入手）
6. Mark_as_Master_CVM（マスタＣＶＭとしてマーク）
7. Mark_as_active_CVM（アクティブＣＶＭとしてマーク）
8. Get_context（コンテキストを入手）
9. Send_context（コンテキストを送る）
10. Get_result（結果を入手）
11. Send_result（結果を送る）
12. Save_on_context（コンテキストを保存）
など
【００４３】
サービスおよび動作会話型ファウンデーション・クラス
（この場合も分散の場合はＣＶＭハンドル付きとすることができる）
1. Get_meta-information（メタ情報を入手）
2. Set_meta-information（メタ情報の設定）
3. Register_category（カテゴリを登録）
4. Get_list_of_categories（カテゴリのリストを入手）
5. Conversational_search（dialog or abstraction-based）（会話探索（対話ベースまたは抽象化ベース））
6. Conversational_selection（dialog or abstraction-based）（会話選択（対話ベースまたは抽象化ベース））
7. Accept_result（結果を受諾）
8. Reject_result（結果を拒否）
9. Arbitrate_result（結果を調停）
など
【００４４】
その他のサービス
（複数のクラスによる）
会話型セキュリティ
会話のカスタマイズ
会話型ヘルプ
会話優先順位付け
リソース管理
出力形式設定および提示
入出力抽象化
エンジン抽象化
など
【００４５】
規則
ファースト・ネームから名前を完全に入手する方法
電話番号の入手方法
住所の入手方法
照会のやり直し方法
照会の訂正方法
など
【００４６】
本明細書では、ＣＶＭが提供する開発環境をSPOKEN AGE（商標）と呼ぶ。Spoken Ageを使用して、開発者はＣＶＭ用の会話認識アプリケーションの作成、シミュレート、およびデバッグを行うことができる。ＡＰＩ呼出しの直接実施を提供するほか、複数のパーソナリテイによる高機能会話型インターフェース、ユーザが出力の音声のタイプを選択することができるVoiceフォント、およびPostcriptやＡＦＬ（オーディオ・フォーマッティング言語）のような会話型プレゼンテーションを作成する会話形式設定言語も提供する。
【００４７】
前述のように、会話型アプリケーションＡＰＩ層２０３は、汎用会話型入出力、会話型論理、および会話型メタ情報交換プロトコルを実現する会話型プログラミング言語およびスクリプトを含む。会話型プログラミング言語／スクリプトによって、任意の使用可能なリソースを入力ストリームまたは出力ストリームとして使用することができるようになる。以下で詳述するように、（ＣＶＭ２０２が会話エンジンＡＰＩ２０７を介してアクセスする）会話型エンジン２０８および会話型データ・ファイル２０９を使用して、各入力はバイナリまたはＡＳＣＩＩ入力に変換され、それをプログラミング言語によって組込みオブジェクトとして直接処理することができる。呼出し、フラグ、およびタグを自動的に組み込むことができ、異なるオブジェクトと正しくインターフェースするのに必要な会話型メタ情報をオブジェクトとプロセス間で送ることができる。さらに、アプリケーションまたはユーザの必要に応じて出力ストリームを特別に形式設定することができる。これらのプログラミング・ツールにより、マルチモーダル・ディスコース処理を容易に構築することができる。さらに、論理ストリーム状況および演算子を拡張して、ＡＳＣＩＩ／バイナリのコンテンツに基づき、またはそれらのＮＬＵ変換照会（従来型および会話型のサブシステムの入出力）またはＦＳＧベースの要求（この場合システムは限定されたコマンドを使用）に基づき比較可能な豊富な会話型照会を扱う。このようなシステムをテストまたは修正するための論理演算子が実現可能である。会話型論理値／演算子は拡張されて、真、偽、不完全、曖昧、ＡＳＣＩＩの視点での異／同、ＮＬＵの視点からの異／同、アクティブ照会フィールドの視点からの異／同、不明、非互換、および比較不能を含む。
【００４８】
さらに、会話型アプリケーションＡＰＩ層２０３は、基礎ＯＳの機能および動作の拡張機能を実現するコードも含む。このような拡張機能としては、たとえば、任意のオブジェクトに関連付けられた高水準の抽象化および抽象カテゴリ、抽象カテゴリの自己登録機構、記憶、要約、会話型探索、選択、リダイレクト、ユーザ・カスタマイズ、学習機能、ヘルプ、マルチユーザおよびセキュリティ機能、ファウンデーション・クラス・ライブラリなどがあり、それぞれについては後で詳述する。
【００４９】
図２に示す会話型コンピューティング・システムは、コア・エンジンである会話型エンジン２０８（たとえば音声認識、ＮＬ解析、ＮＬＵ、ＴＴＳ、および音声圧縮／圧縮解除の各エンジン）とそれらを使用するアプリケーションとの間のインターフェースをとる会話型エンジンＡＰＩ層２０７をさらに含む。エンジンＡＰＩ層２０７は、ローカルかリモートかを問わずコア・エンジンと通信するためのプロトコルも備える。入出力ＡＰＩ層２１０が、キーボード、マウス、タッチ・スクリーン、キーパッド（マルチモーダル会話型ＵＩを実現する）および音声入出力を取り込む音声サブシステム（音声入力／音声出力）などの従来の入出力リソース２１１とのインターフェースをとる。入出力ＡＰＩ層２１０は、装置抽象化、入出力抽象化、およびＵＩ抽象化を備える。入出力リソース２１１は、入出力ＡＰＩ層２１０を介してＣＶＭカーネル層２０２に登録される。
【００５０】
コアＣＶＭカーネル層２０２は、会話型アプリケーションおよび動作／サービスマネージャ層２１５、会話型対話マネージャ（アービトレータ）層２１９、会話型リソース・マネージャ層２２０、タスク／ディスパッチャ・マネージャ２２１，およびメタ情報マネージャ２２０など、ＣＶＭ層２０２の中核機能を実現するプログラミング層を含む。会話型アプリケーションおよび動作／サービスマネージャ層２１５は、従来型アプリケーション２０１および会話認識アプリケーション２００を管理する機能を含む。このような管理機能としては、たとえば、（ローカルおよびネットワーク分散の両方で）どのアプリケーションが登録されたか、アプリケーションの対話インターフェース（ある場合）は何か、各アプリケーションの状態の追跡などがある。さらに、会話型アプリケーションおよびサービス／動作マネージャ２１５は、ＣＶＭシステムが提供する特定のサービスまたは動作に関連付けられたすべてのタスクを開始する。会話型サービスおよび動作は、ユーザがアプリケーションおよび対話内に存在すると予想できる会話型ＵＩのすべての動作および機能と、アプリケーション開発者が（アプリケーションの開発によって実現しなくても）ＡＰＩを介してアクセス可能であると予想できる機能である。ＣＶＭカーネル２０２が提供する会話型サービスおよび動作の例としては、会話型カテゴリ化およびメタ情報、会話型オブジェクト、リソースおよびファイル管理、会話型探索、会話型選択、会話型カスタマイズ、会話型セキュリティ、会話型ヘルプ、会話型優先順位付け、会話型遅延処置／エージェント／記憶、会話型論理、会話型インターフェースおよび装置（それぞれについては本明細書で詳述する）。このようなサービスは、会話型アプリケーション層２０３を介してＡＰＩ呼出しにより提供される。会話型アプリケーションおよび動作／サービス・マネージャ２１５は、装置、アプリケーション、またはユーザ選好の機能と制約に合わせてＵＩを適合化するのに必要な様々な機能をすべて実行する役割を果たす。
【００５１】
会話型対話マネージャ２１９は、登録されているすべてのアプリケーションにわたって対話（ＧＵＩキーボード、ポインタ、マウス、ビデオ入力などの音声およびマルチモーダル入出力を含む会話型対話）を管理する機能を含む。具体的には、会話型対話マネージャ２１９は、ユーザがもっている情報、ユーザが提示する入力、ユーザ入力を扱うべきアプリケーションを判断する。
【００５２】
会話型リソース・マネージャ２２０は、登録されている会話型エンジン２０８（ローカルの会話型エンジン２０８またはネットワーク分散リソース）、各登録リソースの機能、および各登録リソースの状態を判断する。さらに、会話型リソース・マネージャ２２０は、ＣＰＵサイクルの割振りの優先順位または入出力の優先順位を付けて、それに続くアクティブ・アプリケーションとの対話を維持する（たとえば現行の入力または出力の認識または処理に従事しているエンジンが優先権を持つ）。同様に、分散アプリケーションの場合、アクティブな前景プロセスのためにネットワーク遅延を最小限にするように、使用するエンジンおよびネットワーク経路の経路指定と選択を行う。
【００５３】
タスク・ディスパッチ／マネージャ２２１は、ローカルおよびネットワーク化従来型および会話型リソース（後で詳述）上で（ユーザまたは計算機によって）生成された様々なタスクおよびプロセスのディスパッチと調整を行う。メタ情報マネージャ２２２は、メタ情報リポジトリ２１８を介して、システムに関連付けられたメタ情報を管理する。メタ情報マネージャ２２２およびリポジトリ２１８は、一般に会話型対話では既知であるものとみなされるが現行会話のレベルでは入手できないすべての情報を収集する。例としては、先験的知識、文化的、教育的前提事項および不変の情報、過去の要求、参照、ユーザに関する情報、アプリケーション、ニュースなどがある。これは、一般に、会話型履歴／コンテキストの長さ／存続期間を超えて保持され、存続する必要がある情報であり、会話にとって共通の知識であると予想され、したがって現在および過去の会話型対話中には決して定義されていない情報である。また、後述するように、コマンド、リソース、マクロなどへのショートカットも、メタ情報マネージャ２２２によって管理され、メタ情報リポジトリ２１８に格納される。さらに、メタ情報リポジトリ２１８は、ユーザ識別に基づくユーザ利用記録を含む。ＣＶＭシステムが提供する会話型ヘルプや支援などのサービスと、いくつかの対話プロンプト（概説、質問、フィードバックなど）は、メタ情報リポジトリ２１８に格納され、アプリケーションに関連付けられている、ユーザの利用履歴に基づいて調整することができる。ユーザが所与のアプリケーションと以前に対話したことがある場合、ユーザがそれについて熟知していると見なして説明を少なくすることができる。同様に、ユーザが多くの誤りを犯した場合、多数のエラーは、ユーザがアプリケーションまたは機能について不確かであるか、熟知していないか、理解していないか、または誤って理解しているためであると解釈されるため、説明をより詳しくすることができる。
【００５４】
対話マネージャ２１９によってコンテキスト・スタック２１７が管理される。コンテキスト・スタック２１７は、アプリケーションに関連付けられたすべての情報を含む。このような情報には、すべての変数、状態、入力、出力、および対話のコンテキストで行われたバックエンドに対する照会と、対話中に発生した外部イベントが含まれる。後で詳述するように、コンテキスト・スタックには、各アクティブ対話（または据置き対話−エージェント／記憶）に対応する編成／ソートされたコンテキストが関連付けられる。ＣＶＭシステムにはグローバル履歴２１６が含まれ、各アプリケーションのコンテキストを超えて記憶される情報を含む。グローバル履歴には、たとえば、すべてのアプリケーションに関連付けられた情報や会話型セッション中に行われた処置（すなわち現行セッション（または機械が起動されてからの）のユーザと機械との間の対話の履歴）が記憶される。
【００５５】
ＣＶＭカーネル層２０２は、（対話マネージャ２１９を迂回せずに）対話マネージャ２１９を介したバックエンド業務論理２１３へのアクセスを可能にするバックエンド抽象化層２２３をさらに含む。これにより、このようなアクセスをコンテキスト・スタック２１７およびグローバル履歴２１６に加えることができる。たとえば、バックエンド抽象化層２２３は、対話マネージャ２１９との間の入出力をデータベース照会に変換する。この層２２３は、標準化属性値ｎタプルをデータベース照会に変換し、そのような照会の結果をテーブルまたは属性値ｎタプルのセットに変換し戻して対話マネージャ２１９に返す。さらに、ユーザに提示される動作、ＵＩ、および対話を、ＣＶＭシステムを実行する装置の入出力機能およびエンジンの機能に基づいて適合化する会話トランスコード層２２４を備える。
【００５６】
ＣＶＭシステムは、ＯＳ２１２が提供する基礎システムサービスの一部として、通信スタック２１４（または通信エンジン）をさらに含む。ＣＶＭシステムは、通信スタックを使用して、会話型通信を行うように会話型通信サービスを拡張する会話型プロトコル２０４を介して情報を送る。通信スタック２１４は、会話型装置感の会話型通信交換を行うために、本発明の一実施形態により周知のＯＳＩ（開放型システム相互接続）プロトコル層と共に実現可能であることを理解されたい。当技術分野で周知のように、ＯＳＩは７層を含み、各層は、ネットワーク接続された装置のネットワーク分散会話型アプリケーション感の通信を行うためにそれぞれの機能を実行する。これらの層（その機能は周知である）は、アプリケーション層、プレゼンテーション層、セッション層、トランスポート層、ネットワーク層、データリンク層、および物理層である。アプリケーション層は、会話型プロトコル２０４を介した会話型通信を可能にするように拡張される。
【００５７】
会話型プロトコル２０４によって、一般に、リモート・アプリおよびリソースは、それらの会話型機能およびプロキシを登録することができる。具体的には、さらに図３を参照すると、会話型プロトコル２０４（またはメソッド）は、分散会話型プロトコル３００と、ディスカバリ、登録、および折衝プロトコル３０１と、音声送信プロトコル３０２とを含む。分散会話型プロトコル３００により、ネットワーク会話型アプリケーション２００、２００ａ、およびネットワーク接続装置（ローカル・クライアントおよびサーバなどのその他のネットワーク化装置）は、情報を交換してそれぞれの現行の会話状態、引数（データ・ファイル２０９）、およびコンテキストを互いに登録することができる。分散会話型プロトコル３００は、ネットワーク接続装置（たとえばクライアント／サーバ）間でローカルおよびネットワークの会話型エンジン２０８、２０８ａを共用することを可能にする。分散会話型プロトコル３００は、対話マネージャ（ＤＭ）プロトコル（後述）も含む。分散会話型プロトコルは、マスタ／スレーブ会話型ネットワーク、ピア会話型ネットワーク、サイレント・パートナを含む複数の装置およびアプリケーションが関与する会話を調整するための情報の交換を可能にする。分散会話型プロトコルを使用してネットワーク装置間で交換可能な情報には、データ・ファイル（引数）を指すポインタ、データ・ファイルおよびその他の会話型引数の転送（必要な場合）、入力イベント、出力イベント、および認識結果の通知、会話型エンジンＡＰＩ呼出しおよび結果、状態、コンテキスト変更、およびその他のシステム・イベントの通知、登録更新、登録のためのハンドシェーク、折衝更新、折衝のためのハンドシェーク、要求リソースが失われた場合のディスカバリ更新が含まれる。
【００５８】
さらに、分散会話型プロトコル３００によって、アプリケーションおよび装置は、アプレット、ActiveX構成要素、およびその他の実行可能コードなどの他の情報を交換することができるようにし、それによって、装置または関連付けられたアプリケーションが、たとえばマスタ／スレーブやピア・ツー・ピア会話型ネットワーク構成およびサイレント・パートナを含むネットワーク内の装置間での会話と調整することができるようにする。言い換えると、複数のＣＶＭまたは会話認識装置が会話接続され、調整される場合、単一のインターフェースを介して（すなわち単一のマイクロフォンを介して）それらを同時に制御することが可能になる。たとえば、音声によって、高度自動機能電話、ページャ、ＰＤＡ、ネットワーク・コンピュータ、ＩＶＲ、車載コンピュータを、固有の調整会話型インターフェースを介して自動的に制御することができる。サイレント・パートナを、他の会話型装置から会話型インターフェースを介して制御することができる。サイレント・パートナは、ＡＰＩ／プロトコルを介してネットワーク接続ＣＶＭと対話することができるような会話認識システムである。しかし、サイレント・パートナは、指定されている機能以外には、ユーザに対して入出力を提示しない。たとえば、室内のランプは、ＣＶＭによって検出可能であり、その会話状態（たとえばそのコマンドが何であるか、すなわち、ランプの点灯、消灯）を登録することができ、ＣＶＭから送られたコマンドを実行することができることによって、会話認識可能であると言える。この形態では、本明細書でＵＣＲＣ（汎用会話型リモート・コントロール）と呼ぶＣＶＭリモート・コントロールは、検出されたすべての会話認識器具によってサポートされているコマンドをダウンロードすることができる。その場合、ユーザはこれらのアプリケーションをＣＶＭリモート・コントロールと対話するだけで音声により制御することができる。
【００５９】
一実施形態では、分散会話型プロトコル３００は、ネットワークを介したアプリケーションおよび異なる会話型エンジン間での呼出しを実施するように、ＲＭＩ（リモート・メソッド呼出）またはＲＰＣ（リモート・プロシージャ呼出し）システム呼出しを介して実施される。当技術分野で周知のように、ＲＰＣは、１つのアプリケーションがネットワークを介して別のアプリケーションにサービスを要求することを可能にするプロトコルである。同様に、ＲＭＩは、分散ネットワーク内でオブジェクトどうしが対話することを可能にする方法である。ＲＭＩによって、要求と共に１つまたは複数のオブジェクトを受け渡しすることができる。
【００６０】
会話型プロトコル２０４は、会話型ディスカバリ（検出）、登録、および折衝の各プロトコル３０１（またはメソッド）をさらに含む。登録プロトコルは、装置間のデータ転送を該当情報に限定し、マスタ／スレーブまたはピア・ネットワークの折衝を行うように、各ネットワーク装置またはアプリケーションがそれぞれの会話型機能、状態／コンテキストに関する情報の交換と登録を行えるようにする。（会話認識のみの）サイレント会話型パートナも同様に動作し（すなわちそれぞれの機能などを登録し）、会話型プロキシ・サーバを介して、またはＣＶＭの会話型クライアントとして対話することができる（すなわち、サイレント・パートナはＣＶＭ装置への会話型登録を使用する）。
【００６１】
登録プロトコルにより交換可能な情報は、（１）機能と、定義および更新イベントを含むロード・メッセージ、（２）エンジン・リソース（所与の装置がＮＬＵ、ＤＭ、ＮＬＧ、ＴＴＳ、話者認識、音声認識圧縮、コーディング、記憶などを含むか否か）、（３）入出力機能、（４）ＣＰＵ、メモリ、およびロード機能、（５）データ・ファイル・タイプ（ドメイン固有、辞書、言語モデル、言語など）、（６）ネットワーク・アドレスおよび機能、（７）ユーザに関する情報（定義および更新イベント）、（８）装置、アプリケーション、または対話のためのユーザ選好、（９）カスタマイズ、（１０）ユーザの経験、（１１）ヘルプ、（１２）アプリケーション（およびアプリケーション状態）ごとの機能要件（定義および更新イベント）、（１３）ＣＵＩサービスおよび動作（ヘルプ・ファイル、カテゴリ、会話優先順位など）のためのメタ情報（典型的にはテーブルを指すポインタを介した定義および更新イベント）、（１４）プロトコル・ハンドシェーク、（１５）トポロジ折衝である。
【００６２】
登録は、ＴＣＰ／ＩＰ、ＴＣＰ／ＩＰ２９、Ｘ−１０、ＣＥＢｕｓなどの従来の通信プロトコルや装置間のソケット通信を使用して行うこともできる。装置は、分散会話型アーキテクチャを使用してそれに関連付けられた会話型エンジンおよびＣＶＭコントローラに、それぞれの会話型引数（たとえばアクティブ語彙、文法、言語モデル、解析および翻訳／タグ付けモデル、声紋、合成規則、ベースフォーム（句読規則）および音声フォント）を伝達する。この情報は、ファイルまたはストリームとしてＣＶＭコントローラおよび会話型エンジンに渡されるか、またはＵＲＬ（または前述のように装置間の情報交換レベルでの宣言または手続き、オブジェクトおよびＸＭＬ構造）により渡される。登録プロトコルを実施する一実施形態では、装置は、接続時に、フラグのセットまたは装置特性オブジェクトを交換することによって、事前準備されたプロトコルを使用して会話型機能に関する情報（たとえばＴＴＳ英語、任意のテキスト、音声認識、５００ワードおよびＦＳＧ文法、話者認識なしなど）を交換することができる。同様にアプリケーションはエンジン要件リストを交換できる。マスタ／スレーブ・ネットワーク構成では、マスタ対話マネージャはすべてのリストをコンパイルし、機能および必要なものを会話型機能と突き合わせる。さらに、装置またはアプリケーションのコンテキスト・スタック／履歴を指示、受け渡し、または指すことによって、コントローラがそのコンテキスト・スタックにアクセスし、追加することができるコンテキスト情報を送ることができる。装置は、そのマルチモーダル入出力およびＵＩ機能（画面あり／画面なし、音声入出力機能、キーボードなど）に関する情報も渡す。会話型引数によって、対話エンジンは、現在の状況およびコンテキストに基づいてＮＬＵエンジンによる新規照会の関連性を推定することができる。
【００６３】
会話型ディスカバリ・プロトコル３０１は、装置の自発的ネットワーク化会話型クライアント２３０、２３０ａが、ローカルまたはネットワークの会話認識システムを自動的に検出し、そのような会話認識システムを動的かつ自発的にネットワーク接続するために使用する。ディスカバリ・プロトコルを介して交換される情報には、（１）ハンドシェークのブロードキャスト要求または要求の聴取、（２）装置識別子の交換、（３）最初の登録のためのハンドル／ポインタの交換、（４）最初の折衝のためのハンドルの交換が含まれる。
【００６４】
さらに、折衝プロトコル３０１は、動的マスタ／スレーブおよびピア・ツー・ピア対話において複数のＣＶＭシステム間の適切な調整を実現するように、マスタ／スレーブまたはピア・ネットワーキング間の折衝を可能にする。具体的には、複数のＣＶＭ装置が登録時に、会話型登録機能に、たとえば、制御機能、それらの装置がアクセス可能な会話エンジン、それらの装置に登録済みでそれらの装置が制御するアプリケーションおよび装置に関する情報を加える。ＵＩ、入出力機能、およびアクティブ入出力に基づいて、１つのＣＶＭコントローラがマスタになり、他のＣＶＭコントローラがスレーブとして機能するが、これは新しい折衝が行われるまで登録アプリケーションであるという点でマスタと相対的には同等である。マスタとスレーブの役割は、アクティブ入出力モーダリティに基づいて、またはアクティブ・アプリケーションに基づいて動的に交換可能である。
【００６５】
音声送信プロトコル３０２（または会話型コーディング・プロトコル）は、音声送信クライアント３８、３８ａが他のネットワーク装置、システム、またはアプリケーションとの間で圧縮音声を処理のために送受信するために使用する。音声送信クライアント３８、３８ａは、ネットワークを介して送信された音声を処理するために、適合する圧縮ハードウェア２３５、２３５ａを使用して、圧縮、圧縮解除、再構築エンジン２３４、２３４ａと共に動作する。音声コーダ２３４、２３４ａは、圧縮音声の知覚的に受容可能または理解可能な再構築と、最適化された会話パフォーマンス（たとえば語誤り率）を実現する。音声は、それぞれのネットワーク装置上で、音響信号処理エンジン（音声サブシステム）２３２、２３２ａと適合する音声ハードウェア２３３，２３３ａを使用して取り込まれる（さらにフィーチャに変換される）。さらに、音声処理のために装置間で圧縮音声ファイル形式３０３を送受信することができる。具体的には、音声送信プロトコル３０３によって、装置は圧縮音声またはローカルの処理結果をネットワーク上の他の装置およびアプリケーションとの間で送受信することができる。前述のように、会話型エンジン２０８（図２）は、送信のために音声（または結果）を圧縮し、ローカル処理のためにネットワークを介して他の装置またはアプリケーションから入手した圧縮音声（または結果）を圧縮解除する、圧縮／圧縮解除エンジン２３４を含むことが好ましい。一実施形態では、送信側装置と受信側装置戸の間のハンドシェーク・プロセスの後に、（パケット方式の）データ・ストリームを受信側に送る。パケット・ヘッダによって、音声（結果）を符号化するために使用するコーディング方式とコーディング引数（サンプリング周波数、フィーチャ特性、ベクトル次元、フィーチャ変換／ファミリなど）を指定することが好ましい。さらに、誤り訂正情報（たとえば、直前のパケットが失われたり遅延した場合に差分デコーダを修正するための直前のパケットの最後のフィーチャ・ベクトル、または失われたパケットを復元（再送信）するための適切なメッセージング）も組み込むことができる。
【００６６】
図９、図１０、および図１１に示すように、会話型プロトコル２０４は、ネットワーク装置の対話マネージャ（ＤＭ）（ＤＭについては後述）間での情報交換のためのプロトコルをさらに含む。たとえば図９に示すように、分散アプリケーション（分散アプリケーション２００ａ）では、所与の機能をどの対話マネージャ（２１９または２１９ａ）が実行するかを判断するための情報を交換するために対話管理プロトコルを使用する。典型的には、異なる装置、ＣＶＭ、または異なるアプリケーションがそれ独自の対話マネージャ、コンテキスト・スタック２１７、２１７ａ、およびグローバル履歴２１８、２１８ａを有する。それらの異なる対話マネージャは、（分散プロトコル３００（図３）の一部である）対話マネージャＤＭプロトコルを介して、マスタ対話マネージャおよびスレーブまたは対等対話マネージャと、トポロジを折衝する。アクティブ・マスタ対話マネージャ（図９で対話マネージャ２１９として図示されている）は、それらの異なるマネージャへの入出力の流れを管理してアクティブ対話を決定し、照会を適切に実行し、コンテキストと履歴を更新する役割を果たす。たとえば、交換可能な情報は、（１）ＤＭアーキテクチャ登録（たとえば各ＤＭはローカルＤＭの集合とすることができる）、（２）関連付けられたメタ情報（ユーザ、装置、機能、アプリケーションの必要事項など）を指すポインタ、（３）ＤＭネットワーク・トポロジ（たとえばマスタ／スレーブ、ピア・ツー・ピア）の折衝、（４）該当する場合、すなわちマスタＤＭによって制御されるエンジンを使用する場合、データ・ファイル（会話型引数）、（５）エンジンへの転送やコンテキストへの追加のためのユーザ入力、ユーザへの出力など、入出力イベントの通知、（６）認識イベントの通知、（７）エンジンからマスタＤＭへの処理済み入力の転送、（８）マスタＤＭの責任の登録ＤＭへの転送、（９）ＤＭ処理結果イベント、（１０）ＤＭ例外、（１１）信頼結果および曖昧結果、提案フィードバックおよび出力、提案実行状態、提案アクション、提案コンテキスト変更、提案新規対話状態の転送、（１２）決定通知、コンテキスト更新、アクション更新、状態更新など、（１３）完了、失敗、または割り込まれたアクションの通知、（１４）コンテキスト変更の通知、（１５）アクションによるデータ・ファイル、コンテキスト、および状態の更新である。さらに、アクション、入出力イベント、バックエンド・アクセスは、従来のリソース・マネージャおよびタスク・ディスパッチャ・マネージャと共用される情報である。
【００６７】
図１０および図１１に、本発明による対話管理のシステムおよび方法を示す。具体的には、図１０には、様々な装置／アプリケーション（ｌ、ｋ、およびＮ）の複数の対話マネージャ（すなわち、マスタ・アービトレータと、スレーブ・対話マネージャｌ、ｋ、およびＮ）間の階層的対話を図示する。図１０には、典型的なマスタ／スレーブ・トポロジが示されている。前述のように、このトポロジは、ＤＭプロトコルを介して関連する情報を交換することによって形成される。一方、図１１には、主ルート（アービトレータ）対話マネージャのみが、１つまたは複数のアプリケーションまたは装置（ｌ、ｋ、Ｎ）のために対話マネージャ・タスクを行う他のマスタ／スレーブ構成が図示されている。この場合、マスタ対話マネージャ・アービトレータは、存在する唯一の対話マネージャであり、グローバル・コンテキストおよび履歴（場合によってはアプリケーション固有のコンテキストおよび履歴の分類を有する）を維持する。ＤＭプロトコルでは、各アプリケーションおよび装置と中核ルート対話マネージャとの間で属性値ｎタプルを交換する必要がある。
【００６８】
複数の装置／アプリケーションが関与する場合であっても、図１０に示すように実際の対話管理プロセスは単一の装置上の単一の対話マネージャによって逐次実行することができることを理解されたい。この２つの状況の相違は、ユーザが、所定のタスクのために特化されたエンティティごとに１つの会話をもって複数の会話を行う感じを持つのに対し、複数のタスクを行う１つのエンティティとの会話を行っている感じを持つことである。これらのトポロジのそれぞれは、ＤＭプロトコルを介して折衝するか、またはユーザ選好、アプリケーションによる選定、またはＣＶＭデフォルト設定値によって設定することができる。
【００６９】
次に図４を参照すると、本発明の一実施形態によるＣＶＭシステムの会話型カーネルの会話型システムおよびコア機能モジュールの詳細なアーキテクチャが図示されている。図４のシステムおよびそれに付随する説明は、実施例を示す例示のためのものであり、当業者なら本発明の主旨によるＣＶＭを実施する他の構成要素またはシステム・アーキテクチャを考えることができることを理解されたい。さらに、これらの要素のそれぞれをアプリケーション内または既存のオペレーティング・システム下のプラットフォームとしてスタンドアロン・モードで導入するか、またはこれらの異なる新規要素を中心に構築されたコア・カーネルを持つ真のＣＶＭで導入することができることを理解されたい。基礎オペレーティング・システムに対する会話型呼出しは、ＣＶＭによって取り込み、実施することができ、それによって移植性が可能になる。その場合、ＣＶＭは既存のプラットフォームのためのスタンドアロン・プラットフォームとして構成される。
【００７０】
図４を参照すると、本発明の一実施形態による会話型システム４００は、相対的に、会話型サブシステムの組合せと、ＣＶＭ４０１によって実行され、管理される会話型サブシステムとを含む。ＣＶＭ４０１は、タスク・ディスパッチャ／コントローラ４０２と、メタ情報マネージャ４０３と、対話コントローラ４０４（または上述の対話マネージャ）と、コンテキスト・スタック４０５と、会話型サブシステム・サービス・マネージャ４０６とを含む。本明細書では、「ＣＶＭコントローラ」という用語はタスク・ディスパッチャ／コントローラ４０２と対話コントローラ４０４とを集合的に指すものと理解されたい。一般に、ＣＶＭ４０１は会話型および会話型の入力ストリームを複数のアクションに伝え、格納された出力を会話型または従来型あるいはその両方の出力ストリームを介してユーザに対して出力する。
【００７１】
会話型システム４００は、たとえば音声認識システム４０８、話者認識システム４０９、リソース言語理解および自然言語解析システム４１０、テキスト−音声合成（ＴＴＳ）システム４１１などを含む複数の会話型リソース・サブシステム（エンジン）４０７をさらに含む。会話型リソース４０７はＮＬＧ（自然言語生成）エンジンや音声サブシステムなどの他のシステムを含むこともできることを理解されたい。前述のように、これらの会話型サブシステム４０７のそれぞれには、ＣＶＭ４０１に対するＡＰＩ呼出しを介してアクセスすることができる。ＣＶＭ４０１は、（会話型サブシステム・サービス・マネージャ４０６を介して）要求先の会話型サブシステム４０７を探し出し、その実行を促し、しかるべく結果を返す。これらの会話型サブシステム４０７は、ローカル、またはネットワークを介して分散させることができることと、（開発者がエンジン４０７の特定の動作を実施したい場合、エンジンＡＰＩは常にアプリケーションにとって使用可能であるが）すべての会話型サブシステム呼出しは、アプリケーションに対して隠蔽されることを理解されたい。
【００７２】
会話型サブシステム・サービス・マネージャ４０６は、ＣＶＭ４０１によって提供される（本明細書に記載の）すべてのサービス、ＵＩおよび動作を管理する。会話型サブシステム・サービス・マネージャ４１２は、基礎オペレーティング・システム（または、基礎ＯＳがない場合でも従来の入出力システム）によって提供されるすべてのサービスおよびＵＩを管理する。
【００７３】
ＣＶＭ４０１の中核は、対話コントローラ４０４の制御下で動作し、管理されるコンテキスト・スタック４０５である（コンテキスト・スタック４０５は前述のグローバル履歴及びメタ情報リポジトリに直接関係することを理解されたい）。一般に、コンテキスト・スタック４０５は、アクティブ化されたディスコース（すなわち所与のタスク／プロトコル／スレッドに関連付けられた会話型対話）を持つ各アクティブ・プロセスのコンテキスト（すなわち属性値ｎタプルの完全照会引数リスト、および状態／モード）を、入力の理解に必要と考えられる異なるエンジンのためのデータ・ファイル４１３（または少なくともそのような会話引数の識別子）（たとえば、エンジンがＦＳＧ、トピック、語彙、ＨＭＭ（隠れマルコフ・モデル）、声紋、言語モデル、音声入力のための考えられる照会などのそれぞれのタスクを実行するのに使用するファイルまたは引数）と共に蓄積する。言い換えると、「コンテキスト」という用語は、（アクティブと非アクティブとを問わず）各ディスコースの状態を指し、ディスコースの過去の履歴、その現行状態、特定の特性、および対応するタスクの照会引数（たとえば各アクティブ・タスク／プロセスの語彙ファイル、言語モデル、解析、タグ、声紋、ＴＴＳ規則、文法、ＮＬＵなど）を、入力理解に必要なデータと共に追跡する。分散ＣＶＭ（後述）では、（コンテキストおよびグローバル履歴に関して前述したように）コンテキスト・スタック（およびその他のＣＶＭ構成要素）はネットワーク・サービスに直接関連付けることができる（すなわちネットワークを介して分散される）ことを理解されたい。
【００７４】
具体的には、各新規タスク、プロセス、またはスレッドは、新しいスタック項目を作成し、ディスコースに関連付けられる。各アプリケーションは、複数のディスコース（たとえばアプリケーション管理ディスコースとアプリケーション・コンテンツ・ナビゲーション・ディスコース）と関連付けることができる。所与のディスコースに関連付けられた各コンテキストは、対応するプロセス／タスク／スレッドに対して行われた最新の要求および最新の出力を含む。所与のディスコースのコンテキストには、たとえば実際の照会をマップするアクティブな文法、語彙、および記号言語も関連付けられる。この場合も、最新の情報が履歴およびコンテキスト・スタックに格納される。過去の履歴、コンテキストおよびその他の情報は、メタ情報マネージャ４０３によって管理され、メタ情報の一部として記憶される。
【００７５】
対話コントローラ４０４は、（後述するようにタスク管理がタスク・ディスパッチャ／コントローラ４０２によって制御されて）ネットワーク装置からローカルまたはリモートで生成される各新規タスク／プロセス／スレッドのためにコンテキスト・スタック４０５内に新しいスタック項目を作成することによって、コンテキスト・スタック４０５を管理する。各アクティブ・アプリケーションに複数のディスコース（たとえばアプリケーション管理ディスコースとアプリケーション・コンテンツ・ナビゲーション・ディスコース）を関連付けることができる。前述のように、所与のディスコースに関連付けられた各コンテキストは、対応するプロセス／タスク／スレッドに対して行われた最新の要求と最新の出力とを含む。さらに、所与のディスコースのコンテキストには、たとえば実際の照会をマップするアクティブな文法、語彙、および記号言語（属性値ｎタプル）も関連付けられる。コンテキスト・スタック４０５は、機械状態スタックに関連付けられ、それによって、ユーザからの新規入力があると、対話コントローラ４０４は入力コンテキストが適切に設定されるまでコンテキスト・スタック４０５を走査する。これは、基本的に最新および過去のディスコースのうちからユーザと機械とのアクティブ・ディスコースを見つけて選択することになる。
【００７６】
タスク・ディスパッチャ／コントローラ４０２は、ローカルおよびネットワークかされた従来型および会話型のリソース上で（ユーザおよび機械によって）生成された異なるタスクおよびプロセスのディスパッチと調整を行う。タスク・ディスパッチャ／コントローラ４０２は、基本的にリソース割り振り機構であり、一般に（従来型タスクと会話型タスクとを問わず）タスクをディスパッチし、アクティブ化し、すべてのリソースの負荷と可用性を監視することによって各タスク、リソースなどの状況を制御し、様々なタスクを様々なリソースに適切に割当て、シフトさせる。このリソース割り振り機能では、各リソースの現行負荷と、各サービスおよびアプリケーションに必要なものとを判断し、それらを扱うことができるリソースにタスクをディスパッチすることによってシステム全体の負荷分散／管理を行い、全体的なシステム負荷および会話フローを最適化する。タスク・ディスパッチャ／コントローラ４０２は、（会話型タスク・マネージャ４１７を介して）会話型システム管理手続きと、（前述のディスカバリ、登録、折衝、および分散会話型プロトコルを介して）異なるリソースによって交換される情報とに依存する。タスク・ディスパッチャ／コントローラ４０２は、これらのリソースを追跡し、従来のサブシステム（たとえばＧＵＩ入出力およびシステム、ビデオ認識エンジンなど）および会話型サブシステム４０７を、コンテキスト・スタック４０５上の異なるタスク間で分配する。さらに、タスク・ディスパッチャ／コントローラ４０２は、基礎オペレーティング・システムのサービスを使用して、従来型タスク・マネージャ４１７のレベルでオペレーティング・システムによって制御可能な従来型タスクを制御する。この場合も、前述のように、従来のオペレーティング・システムは会話型タスク・ディスパッチャ／コントローラ４０２の指示によりタスク管理を行うことができる。
【００７７】
タスク・ディスパッチャ／コントローラ４０２は、従来型および会話型のサブシステム・サービス４１２、４０６から（アクティブ・コンテキストを選択する対話コントローラ４０４を介して）コンテキスト・スタック４０５に入力を供給し、異なるタスクの出力を異なるサブシステムに供給し、それらに優先順位を付ける。また、タスク・ディスパッチャ／コントローラ４０２は、コンテキスト・スタック４０５によりエージェント／デーモンの形の会話型支援および記憶タスクの挿入と管理も行う。タスク・ディスパッチャ／コントローラ４０２は、アクティブ会話および会話履歴、遅延戻り、ネットワーク・リソース間の委任、タスク委任、要約、および記憶（これらの機能については後述する）に従って、出力の生成と順位付けを調整する。
【００７８】
対話コントローラ４０４は、（タスク・ディスパッチャ・コントローラ４０２に登録されている）すべての従来型および会話型アプリケーションにわたって対話（対話型＝音声およびマルチモーダルすなわちＧＵＩ、キーボード、ポインタ、マウス、ビデオ入力など）を管理する。前述のように、アプリケーションは（ＡＰＩ呼出しまたは折衝プロトコルを介して）アプリケーションの状態、最新の入力をどのように解釈するか、およびそのような解釈の信頼度に関する情報を交換する。対話コントローラ４０４は、アクティブなコンテキストおよびアプリケーションの管理と判断を行う。また、対話コントローラ４０４は、対話コントローラ４０４がアクティブなアプリケーションを判断するのを支援するためにアプリケーションが情報を交換するための会話型プロトコルを管理したり、そのような判断ができない場合に曖昧性を解決するための小規模な対話をアクティブ化したりする。
【００７９】
図５に、対話マネージャ４０４の機能を図示する。図のように、異なるタスク（タスク１、タスクＮ）およびリソース（会話型サブシステムＡ〜Ｚ）がＣＶＭ４０１によって管理される。ＣＶＭ４０１は、（対話マネージャおよび会話型プロトコルに関して前述したように）どのアプリケーションがアクティブであるか、コンテキストをどのように変更すべきかを決定する。分散アプリケーションでは、この機能は前述の対話マネージャ・プロトコルによりメッセージを送ることによって実行される。対話マネージャ・プロトコルを使用してローカル並列アプリケーション間で情報を交換することを理解されたい。設計時に対話マネージャおよびエンジンにとって未知の複数の（ローカルまたはネットワーク化）対話／アプリケーションにわたる対話とコンテキストを管理する機能は、ジェネリックＮＬ処理と呼ばれるものであり、プラグ可能対話マネージャおよびＮＬアプリケーションである。
【００８０】
アプリケーションはＣＶＭ４０１に対して（前述のようにＣＶＭ ＡＰＩによって）直接、オペレーティング・システム（またはＪＶＭ（Java仮想計算機）などの基礎システム）に対して直接、またはMicrosoft Windowsなどのオペレーティング・システムに対して呼出しを行うことができることを理解されたい。ＣＶＭ４０１を介して呼出しが行われると、タスク・ディスパッチャ／コントローラ４０２を介して登録され、対話（マルチモーダルとすることができ、音声入力または出力がなくてもよい）は対話コントローラ４０４によって管理される。呼出しが完全に基礎オペレーティング・システムに対して行われる場合、対話コントローラ４０４はアプリケーションと間接的にのみ対話する。すなわち、従来の呼出しは従来型タスク・マネージャ４１７によって管理され、したがってタスク・ディスパッチャ／コントローラ４０２に渡されると、タスク・ディスパッチャは従来型タスク・マネージャ４１７と協調し、命令するため、タスク・ディスパッチャ／コントローラ４０２によって考慮される。タスク・マネージャ４１７は、そのアプリケーションを対話コントローラ４０４に登録し、タスク・ディスパッチャ／コントローラ４０２が認識している状況変更を更新する。従来型アプリケーションがＣ＆Ｃ（コマンド・アンド・コントロール）インターフェース（またはその他のタイプの音声インターフェース）によって管理される場合、アプリケーション対話は対話コントローラ４０４への登録により対話コントローラ４０４によって登録され、制御される。これらは特別な場合であることを理解されたい。しかし、一般に、下位互換性または非互換アプリケーションが問題ではない場合、対話コントローラ４０４は、コンテキスト・スタック４０５を介してすべてのアプリケーションの対話を制御し、コンテキストを管理する。ＣＶＭ４０１は、すべての従来型機能、サービス、および動作を再実施することができることを理解されたい。その場合、ＣＶＭ４０１は、従来型オペレーティング・システム上のプラットフォームとしては実行せず、それ自体でオペレーティング・システムとして機能し、すべての従来型呼出しを取り込む。
【００８１】
ＣＶＭ４０１は、ＣＶＭ４０１に関連付けられたファイル（またはレコードや名前空間などの装置に合わせて適合化されたその他の同様のエンティティ）、ディレクトリ、オブジェクト、およびアプリケーションなどの要素、その他のリソースまたはオブジェクト（ローカル、ネットワークなど）、およびユーザに関する情報（選好、セキュリティ上の習慣、バイオメトリクス、振舞いなど）を管理するメタ情報マネージャ４０３をさらに含む。メタ情報マネージャ４０３は、このような要素およびシステム・リソースを抽象カテゴリおよびメタ情報を介して高水準の従来型抽象化と関連付けることによって、これらの要素を管理する。たとえばオブジェクト表現は、各オブジェクトに関連付けられた内容主導のメタ情報（たとえばセキュリティ・フィーチャ（ユーザおよび作成者）、写真、描画、画像のような抽象概念とファイルとの関連付け）のように、高度な知識表現を含むように拡張される。これらの各要素は１つまたは複数のメタ情報カテゴリに関連付けられる。これらのカテゴリは、オペレーティング・システム、アプリケーション、またはユーザによって定義される。各ファイル、ディレクトリ・オブジェクト、およびアプリケーションは、カテゴリ定義および関連付けられた関数を指すことによって、またはこれらのクラスに登録することによって、定義されたカテゴリのうちの１つまたは複数のカテゴリに関連付けることができる。以下で詳述するように、抽象メタ情報を使用して、ファイル・システムまたはその他のオブジェクト、リソースまたはユーザの要素へのショートカットを設けたり、自動的に抽出し、処理することができる。
【００８２】
具体的には、メタ情報マネージャ４０３は、複数のカテゴリと共に抽象メタ情報およびプロトコルを使用してファイル・システムを管理する。これらのカテゴリは、リソースの所有者／開発者、またはリソースの過去の使用者／アプリケーションが定義することができる。ＣＶＭ４０１は、従来のファイル管理システムとは異なりアソシアティブ・メモリに依存し、ファイルに関する情報がオペレーティング・システムによって次の３つの主な形態で取り込まれるので有利である。すなわち、（１）ファイル名の拡張子、（２）ファイル名のヘッダ、および（３）ファイル内容のタイプ（バイナリかＡＳＣＩＩか）（ただし、本明細書に記載の抽象カテゴリ概念はこのような従来のファイルシステムを大幅に改良することができる）である。会話型システムでは、追加のレベルの抽象化を加えて、ファイルの内容または役割を特徴付けることができる。たとえば、各ファイルにファイルを特徴づける抽象クラスのセットを関連付けることができる（それに対して従来は、たとえばＧＩＦファイルにはデフォルトによりそのファイルを開いたり編集したりするソフトウェア・アプリケーションが関連付けられる）。さらに、複数のディレクトリ／ファイル・システム表示が、デフォルトによりこれらの拡張を表示情報に含めたり除外したりする。他のイメージ・タイプのファイルは、自動プロセスを利用するために、アプリケーションのレベルで、または好ましくはオペレーティング・システムのレベルで登録する必要がある。逆に、不正または曖昧なファイル拡張子によって、不正な自動化タスクが発生することが多い。一方、ヘッダによって、所与のファイルの内容および処理要件に関するより詳細な情報が伝えられる。しかし、現在、ＭＩＭＥヘッダのようなヘッダは、通常、アプリケーション、たとえば電子メール、またはプロトコルおよび言語、たとえばＨＴＴＰおよびＨＴＭＬのクラスのためにのみ作成される。
【００８３】
本発明によると、ファイルは抽象メタ情報と関連付けられる。これは、トピックまたはイメージ分類子などによって自動的に、またはアプリケーション、ユーザ、プラットフォームなどによって明示的に行うことができる。たとえば、イメージ、写真、映画、描画の概念によって、多様な抽象カテゴリを定義することができる。したがって、ファイルはこれらの異なる用語によって、ファイルの形式、拡張子、または用法とは独立して特徴付けることができる。さらに、ＣＶＭは、アプリケーション開発者（登録される）またはユーザ（カスタマイズまたは用法）が、複数のアプリケーションにわたるカテゴリを追加する機能も備える。
【００８４】
この抽象化は、ファイルだけでなくディレクトリ、オブジェクト、およびアプリケーションにも拡張可能であることを理解されたい。たとえば、リンク、マクロ、ショートカット、さらにはブックマークのような概念を特定の概念カテゴリと関連付けることができる。これらのカテゴリによって、たとえばすべての財務アプリケーションまたはすべての財務ファイルか、すべての描画アプリケーションまたはすべての画像ファイルかを表示することができる。
【００８５】
メタ情報マネージャ４０３は、ＣＶＭプラットフォーム上に設けられたオブジェクトまたは構築されたオブジェクトをカテゴリの二重リンクリストに関連付ける。同じ機能を実現する他の実施態様を使用することもできることを理解されたい。ＣＶＭプロットフォームは、定義されているすべてのカテゴリのリポジトリ・テーブルを含み、これはメタ情報マネージャ４０３によって管理される。カテゴリによってはユーザまたはアプリケーションに依存する場合がある。ＣＶＭプラットフォーム・システム呼出しを使用して、ユーザまたはアプリケーションは新規カテゴリを作成し、それらのカテゴリに新規オブジェクトを関連付けることができる。これは、特にファイル・システムの場合に言えることである。さらに、ＣＶＭプラットフォームによって、またはユーザ／アプリケーションによってシステム呼出しを介して動的に提供される情報、すなわち、作成日付、使用日付、使用者、時間、回数、オブジェクト作成者、オブジェクトのコンパイル者を、各オブジェクトに付加することができる。
【００８６】
オブジェクト、アプリケーション、ユーザ、またはプラットフォームによって提供される情報に基づいて、オブジェクトの内容に索引付けすることができる。これらの索引は、オブジェクトに関連付けられた動的情報の一部である。索引付けまたはトピック検出あるいはその両方は、可能なときにオンザフライで、またはバッチ・モードで行うことができる。
【００８７】
さらに、メタ情報を使用可能なリソースに関連付けることができるのと同様に、メタ情報、抽象化、および抽象カテゴリをディスパッチされた各タスクおよびプロセスに関連付けることができることを理解されたい。プロセスおよび負荷管理に加えて、これはきわめて明細なタスク選択を提供する。たとえば、１つの会話型要求で、ユーザは、タスクの出力を聴取するか、またはコンテキスト・スタックを探索してタスクのための入力（たとえばマイクロフォン）を再要求し、ウェーブ・ファイルまたはＡＳＣＩＩファイルに対して入力ストリームを付加するように指示することができる。同様に、たとえば、ユーザは、単一のリダイレクト要求を与えることによってファイル送信先のプリンタをリダイレクトすることができる。
【００８８】
ファイル・システムのレベルの抽象カテゴリの使用の概念は、好ましくは、ＣＶＭオペレーティング・システムによって使用可能またはアクセス可能などのようなオブジェクトまたはリソースあるいはその両方にも拡張されることを理解されたい。したがって、ネットワーク化アプリケーションおよび分散アプリケーションの場合、メタ情報マネージャ４０３は、リソースの所有者／開発者またはリソースの過去の使用者／アプリケーションによって定義された、非ローカルのオブジェクトまたはリソース（たとえばファイル・ディレクトリ、ディスク、オブジェクト、周辺装置、アプリケーションなど）に関連付けられた複数のメタ情報カテゴリを管理することができることを理解されたい。実際に、抽象カテゴリは、特定のリソースがローカル・リソースであるかネットワーク・リソースであるかに関係ないことと、リソースへのアクセスまたは接続を介してリソースを抽象カテゴリに登録したり、新しい抽象カテゴリを作成することもできることを理解されたい。具体的には、アクセス可能でまだアクセスされていない新規オブジェクトは、そのメタ情報を登録しなければならず、この登録プロセスは機械が接続するときにローカルで行うか、またはそれ自体、その内容、またはそのカテゴリを登録するＤＮＳ手法または名前空間マネージャに類似したサーバに対して行うことができる。このプロトコルは、（たとえばActiveX、Javascript、Javeアプレット、Vbscriptを介して）アプリケーションまたはオブジェクトを機械にダウンロードまたは転送する場合、ローカルでも使用され、それによってアプリケーションはその抽象カテゴリを自動的に登録アクティブ化することができる。リモート・システムとの接続時に、またはオブジェクトまたはその内容に関連付けられた抽象カテゴリのリストを更新する（ＤＮＳサーバまたは名前空間サーバに類似した）メタ情報サーバを介して、（上述のように）登録プロトコルを使用して、新しい非ローカルオブジェクトに関連付けられた新規カテゴリが自動的に作成される。この自己登録機構により、ネットワークからダウンロードされる新規オブジェクトまたはネットワークに転送されるオブジェクトは、同じプロトコルを使用してそのオブジェクトに関連付けられたメタ情報を伝達し、ローカルで登録することができる。二重リンクリストおよびリポジトリをプラットフォーム・リストに付加することができる。リソースが新規カテゴリを登録すると、新規カテゴリはそのリソースに関連付けられたものとして指される。リソースが破棄されると、対応するカテゴリは削除される。
【００８９】
ローカル・オブジェクトに関連付けられたメタ情報と同様に、抽象メタ情報を使用して、ネットワークの非ローカル要素へのショートカット、自動抽出または処理を行うことができる。これらのリソースは、アクティブ抽象カテゴリまたは登録リソース内に少なくともしばらくは記憶する必要がある。カテゴリ定義および関連付けられた関数を指すことによって、または適切なクラスに登録することによって、リモート・アクセス可能な各非ローカル・オブジェクトまたはリソースをこれらの異なるカテゴリに関連付けることができる。
【００９０】
たとえば、watson.ibm.comイントラネットに属するすべてのリソースとして「watson」リソース、または閲覧したすべての財務ホーム・ページを参照することが可能になる。現在、従来のブラウザ（またはビューワ）では、ページまたはファイルのＵＲＬを記憶し、その後、ユーザが手動で分類することはできる。本発明の手法の結果、ヘッダ形式またはＨＴＭＬ内（たとえば現行ＨＴＭＬ仕様で指定されているコメント・フィールド内または適切なメタ・タグ内、または追加の会話型プロトコル・ハンドシェークのため）に当初から含まれているその他のメタ情報に基づいて、抽象カテゴリが自動的に作成または登録されることになる。したがって、ブックマークは、アクセスまたは追加時に自動的にカテゴリ化される。
【００９１】
メタ情報マネージャ４０３およびリポジトリは、一般に、会話型対話では既知であるとみなされるが現行の会話のレベルでは入手できないすべての情報を収集する。例としては、先験的知識、文化的、教育的前提事項および不変の情報、過去の要求、参照、ユーザ、アプリに関する情報、ニュースなどがある。一般には、これは、会話履歴／コンテキストの長さ／存続期間を超えて保持され持続する必要がある情報であり、その会話にとって共通の知識であると予想され、したがって現在および過去の会話型対話中に定義されていない情報である。
【００９２】
データ・ストリーム処理の一様性は、メタ情報を介した抽象カテゴリ化を簡略にし、類似した抽象カテゴリ、ファイル、オブジェクト、アプリケーション、およびローカル・リソースまたはネットワーク・リソースとしてカテゴライズできるようにする重要な方法である。
【００９３】
入出力データ・ストリームを処理する際のＣＶＭ４０１のタスク・ディスパッチャ／コントローラ４０２、対話コントローラ４０４、およびコンテキスト・スタック４０５間の対話について、以下に詳述する。本発明は、（複数のドメインを持つ）複数のタスクにわたって記憶されたコンテキストおよび混在主導権によるＮＬＵインターフェースを提供することを理解されたい。具体的には、本発明は、複数のドメインを有する複数のアプリケーションにわたるＮＬＵ、ＮＬＧ、および混在主導権による自然な対話を設ける機能を提供する。なお、各アプリケーションはＣＶＭ４０１にアプリケーション自体の解析および変換引数を提供する。以下で詳述するように、ＮＬＵエンジン４１０は、照会に順次に（書式記入）または並列して（たとえば手続きスレッド、並列会話型オブジェクト／手続き、または並列書式）タグ付けすることができる。曖昧でない照会を生成して対話を完了した最初のタスクが実行され、他のアプリケーションによって解釈された対応する照会が記憶されて、認識された照会がユーザによって拒否された場合にアクティブ化する。
【００９４】
会話バイオメトリクスを使用してユーザに関するコンテキストおよびメタ情報を収集することができ、照会をユーザ選好のためにカスタマイズまたは適合化したり認証したりすることができるだけでなく、その情報を使用してより堅固な認識を行うことができることを理解されたい。したがって、ユーザを認識するためにどのような情報でも蓄積することができる。すなわち、照会の通常の言い表し方、言い表された照会のタイプ、コマンド頻度（頻繁に使用されたか頻繁には使用されていないか）、好まれたアプリケーション、時刻、または用法などである。会話バイオメトリクスは、米国特許第５８９７６１６号で開示されている方法を使用して構築することができる。
【００９５】
次に図６を参照すると、本発明の一実施形態による会話型入出力インターフェースが図示されている。図のように、本発明の一実施形態による会話型入力インターフェースは、自然インターフェースを含む、電話６００、キーボード６０１、ポインティング・デバイス６０２、手書き装置６０３を介したマルチモーダル入力、すなわちファイル／ストリーム／リソース、音声を処理することができる。これは、あらゆるモーダリティにわたるすべての入出力イベントを捉え、（コンテキスト・スタックに適切に記憶する）対話マネージャに転送することを意味する。音声クライアント（たとえば電話６００）からの発話入力は、音声認識プロセス６０４を受け、その他の入力（たとえばキーボード、マウス・クリックなど）はＮＬＵ処理６０５される。各入力は、属性獲得（４０１ａ）を受け、それによって入力から属性値ｎタプルが獲得される。要約プロセス４０１ｂを行い、それによって属性値ｎタプルがコンテキストに加えられる。次に、バックエンド・アプリケーション６０８の構文によって照会が完全、不完全、曖昧のいずれあるかを検証する。また、バックエンド・アクセスは、対話マネージャおよびコンテキスト・マネージャによって追跡される。場合によっては、いくつかの一義化機能（対話マネージャの機能）をバックエンドにロードすることによって、「インテリジェンス」の一部をバックエンドに分散することもできる。個別には、各入力ストリームは従来のように動作する。重要な会話型態様は、（入力照会の自然言語理解を実現するために）コマンドをＮＬＵで、または（自由な自然入力ではなく、文法および語彙の規則に従って制約された入力の場合）ＦＳＧモードで入力することができる入力手続きである。コマンドまたは照会は、欠落フィールドを満たすことによって、またはアクティブ・タスクのための不正なフィールドを訂正することによって、完全なものにしたり訂正することができる。したがって、ＣＶＭは、従来のＯＳでは満たされなかった、入力の曖昧性を生じさせる同時入力ストリームをマージする問題を導入する。たとえば、リダイレクトされた入力ストリームは言うまでもなく、入力はキーボード入力、手書き入力、音声入力を結合することができる。したがって、本発明は、曖昧性を解決する機構を備える。これは、前記で引用した米国特許出願第６０／１２８０８１号に記載されているようにして行うことができる。
【００９６】
本発明によると、この入力の問題は、複数のデコーダ、ＡＳＣＩＩ転記、または属性値ｎタプルの出力のマージとして扱われる。各入力ストリームを、ＡＳＣＩＩ転記に変換し、音声認識処理６０４を通した入力タイム・マークと合致させる。異なる入力ストリームが同じタスクに関連付けられている場合、それらの転記を以下のようにマージする。まず、コマンドと照会をタイム・マークに基づいてソートし、単一のデータ・ストリームに付加する。コマンド形式をＦＳＧ規則と照合し、文法規則を満たすように再ソートする。ＮＬＵ照会は必ずしも再ソートを必要としない。ＮＬＵの場合、ストリームごとに記号フィールドを満たし、次に最終入力ストリームのレベルで結合する。スペリングや英数字コードなどの引数は、順序付けの曖昧性を解決するのに文法規則やＮＬＵを利用しない。固有ストリームの作成にも同様にタイム・マークを使用する。しかし、入力は確認のためにユーザにフィードバックされ、場合によってはアプリケーションに依存する辞書またはＦＳＧ規則書を使用して事前フィルタリングされる。
【００９７】
ネットワーク・ベースの対話の場合、前述のように、各機械がネットワーク内の他の装置のタスク・ディスパッチャ／コントローラに登録し、その会話機能に関する情報を提供する。言い換えると、通常のデスクトップ機は、完全会話機能を登録するのに対し、電話は登録するか（高度自動機能電話）またはそのサーバにに画面、キーボード、ポインタのない装置として登録させ（通常電話）、ＰＤＡは、単一ウィンドウ装置などとして登録する。システム間では関連のある入力のみが交換される。
【００９８】
要約すると、この入力手続きは、マルチモード入力ストリームのセットを形成し、それぞれがＡＳＣＩＩコマンドまたは属性値ｎタプルのリストに転記される。各入力エンティティ（コマンド、ＮＬＵ照会フィールド、または引数ユニット（分離文字、語など））がタイム・マークに関連付けられ、結合された入力ストリームにそれに応じて付加される。２つ以上のストリームが全く同じタイム・マークを有する場合、それらは各入力ストリームが前に寄与した時間に基づいて優先順位が付けられる。結合された入力はＦＳＧおよび辞書と照合され、任意選択によりユーザにフィードバックされる。各リソースがそれぞれの会話機能を交換し、入力ストリームは関係のある情報のみを交換するように調整される。
【００９９】
会話出力のディスパッチおよびインターフェースについては、ＣＶＭ４０１は、ファイル／ストリーム／リソース、ディスプレイ（単一またはマルチウィンドウ、ＧＵＩ、カラー、画像、動画）、音声への出力を生成する。個別には、各出力ストリームは従来のように動作する。しかし、コンテキスト・スタック４０５およびタスク・ディスパッチャ／コントローラ４０２により、複数のプロセスの出力が同時に同じ出力ストリーム（たとえば同じテキスト・モード・ディスプレイまたは音声合成装置）上でぶつかる場合がある。また、１つのタスクの出力がいくつかの出力ストリーム間で多重化される場合がある。
【０１００】
各出力ストリームは従来のように動作する。あるいは、出力はタスクの出力と対話プロセス（たとえば指示された対話または混在主導権）の生成出力のいずれかの場合がある。異なるカテゴリの出力ストリームが存在する。たとえば、単一チャネル出力（たとえばダミー端末（ＶＴ１００またはPalm Pilotスクリーン）や音声のみの出力）では、当該リソースを使用するすべての出力メッセージが同じチャネルを使用する（または場合によっては同じチャネルを共用する））（たとえば、音声出力、固有ウィンドウ／画面、またはテキスト出力）。多重チャネル出力では、各タスクの出力ごとに別々のチャネルが存在する（たとえばWindows ＧＵＩ）。単一チャネルへの複数のタスクの出力ストリームは、コンテンツ・スタック４０５と、タスク・ディスパッチャ４０２によって割り当てられた優先順位とに基づいて待ち行列化される。単一チャネル出力がユーザに提供されると、イベントはアクティブになり、コンテキスト・スタックの最上位に置かれる。多重チャネル出力には優先順位は付けられず、非同期的に更新され、タスクを最上位には上げない。
【０１０１】
また、タスクによって割り当てられ、ユーザが修正可能な出力ハンドルに基づいて、各タスクからの出力を多重化し、複数の出力ストリームにすることもできることを理解されたい。ネットワーク・ベースの対話の場合、各機械は、ネットワーク内の他の接続装置のタスク・ディスパッチャ／コントローラに登録して会話機能に関する情報を提供する。たとえば、前述のように、通常のデスクトップ機は、完全会話機能を登録する。電話は登録するか（高度自動機能電話）、またはそのサーバが画面、キーボード、ペン、ポインタのない装置として登録し（通常電話）、ＰＤＡは、単一ウィンドウ装置（たとえばPlam Pilot）などとして登録する。システムの間では該当する出力だけが交換される。
【０１０２】
すべての出力、特に音声出力は、ユーザがカスタマイズし、プログラムすることができることを理解されたい。テキスト表示のためのフォントを選択することができるように、出力を発話する音声の選択を行うことができる。この場合は、Voiceフォントのことである。会話形式設定言語を使用して複雑な会話提示を作成することができる。要約すると、ＣＶＭ４０１は、多重化されている場合であっても、単一チャネル出力への複数タスクの出力をコンテキスト・スタック４０５とタスク・ディスパッチャ４０２に基づいて待ち行列化する機構と、各入力ストリームに割り当てられたリソースのリダイレクトまたは変更を行う機構とを備える。各リソースは、それぞれの会話機能を交換し、出力ストリームは、出力Voiceフォントの選択、ＧＵＩイベントを含む会話提示の形式設定、およびその他の音声コンテンツを含めて、関係する情報のみを交換するように調整される。
【０１０３】
次に、ＣＶＭ４０１による入出力処理について説明する。前述のように、ＣＶＭ４０１は様々な活動を整理しなければならない。たとえば、基本システム呼出しは、異なるサブシステムに関与する複数のアクションを生成する必要がある。このようなアクションには、タスクの実行、新規入力の聴取、出力／フィードバックの生成が含まれる。たとえば、タスク・ディスパッチャ／コントローラ４０２は、コンテキスト・スタック４０５に基づいて、対話コントローラ４０４に対する照会を操作しなければならない異なる統計的パーサを決定して、アクティブ・コンテキストを特定し、照会を完全なものにする。これらのアクションは、たとえば完成された照会を実行し、コンテキスト・スタック４０５を更新し、不完全または曖昧な照会／コマンドについてユーザにフィードバックを提供し、新規入力のデコードを可能にし、コンテキスト・スタック４０５を探索し、実行されたプロセスまたは実行されているプロセスの出力を返すように、適切に優先順位付けされなければならない。
【０１０４】
タスク・ディスパッチャ／コントローラ４０２は、各タスクまたは装置に、会話型引数を有する会話型エンジンを関連付ける。１つのアプリケーションまたは装置について１つのエンジンがある場合、各アプリケーションまたは装置のＮＬＵエンジンは、（前述のように）並列（手続きスレッド）または順次（書式記入）とすることができる。複数の装置／アプリケーションが同じエンジンを共用する場合、ＮＬＵエンジンは、手続きスレッドと並列である必要がある。新規照会の拒否または尤度は、会話型引数に基づいてアクティブ化されたタスクによって管理される。拒否された照会または可能性の低い照会があると、対話コントローラ４０４はコンテキスト・スタック４０５を調べて使用可能な次のコンテキストを探す。各アクション、完成した照会、会話型引数と、各戻り値／結果は、コンテキスト・スタック４０５に格納される。さらに、適切な場合、戻り値および結果によって過去のコンテキストがアクティブ化される。
【０１０５】
タスク・ディスパッチャ／コントローラ４０２は、各コマンド／プロセスを複数のアクションに分け、適切な優先順位で関連付けられたスレッド／プロセスを開始し、それらをコンテキスト・スタック４０５に関係づけ／挿入する。タスク・ディスパッチャ４０２は、各リソースを割り振り、生成された異なるアクションにそれらを分配し、リソースとの間でのハンドルおよびストリームを制御する。タスク・ディスパッチャ４０２は、モーダリティ（ポインタ、キーボード、ファイル、音声）に基づいて、ストリームを適切な会話型サブシステムまたは、転記／把握された音声入力を有する会話型サブシステムにリダイレクトする。これらのサブシステムの出力は、コンテキスト・スタック４０５を探索してアクティブ照会を取り出し、それを完成させる。他方、出力は各タスクの優先順位に基づいて待ち行列化され、出力リソースに順次ディスパッチされる。
【０１０６】
アクティブ化されたディスコースがあるか否かを問わず、各新規（アクティブ）タスク／プロセス／スレッドによって、コンテキスト・スタック４０５内に新規タスク項目が作成される。コンテキスト・スタックには機械状態スタックが関連付けられ、ユーザからの新規入力があった場合に、入力コンテキストを適切に確立することができるまでコンテキスト・スタック４０５を走査することができるようにする。この結果、基本的に、最新および過去のディスコースのうちからユーザと機械との間のアクティブ・ディスコースを見つけて選択し、場合によっては履歴に戻る。この選択プロセスについて、以下に詳述する。さらに、各タスクには混在主導権層が関連付けられる。この層は、従来のオペレーティング・システムにおけるコマンド行の用法情報の会話版と同等の単純なものにすることができる。対話コントローラ４０４は、まず、ユーザ・コマンド照会がコマンド照会の構文レベルで完全か曖昧かを調べる。不完全または曖昧と見なされるコマンドは、同様に優先度（注目しているアプリケーションが最上位）によって適切な会話型エンジン４０７に返され、会話型エンジン４０７は欠落情報または曖昧な情報の要求（プロンプト）を生成し、コンテキスト（要求した欠落フィールド）を更新する。また、単純に、要求はプロンプトをより良く定式化することができない場合（たとえばレガシー・アプリケーション）、不完全で曖昧である言うこともできる。
【０１０７】
一方、完全で曖昧さのないコマンドの場合は、特定の結果（出力またはアクション）が得られる。会話型システムのようにユーザによってリダイレクトされない場合は、これらの結果も同様に優先度によって適切な会話型エンジン４０７に返され、コンテキストが更新される。しかし、リダイレクトは、結果をリダイレクトするときに部分混在主導権通知を行うため、より高度になり得る。後で詳述するように、これはたとえば会話型アシスタントによって実施することができる。これは、従来のシステムで実現するときわめて複雑になり、恐らく特別に作成されたスクリプトに出力をリダイレクトすることが必要になるであろう。コマンドは、ＣＶＭプラットフォーム、アプリケーション、またはユーザ選好から供給される選好／設定値に基づいて、実行の前にユーザによる確認も必要とする場合がある。
【０１０８】
アクティブ・コンテキストの完了／探索は、コンテキストごとにスタックを走査して行われる。すなわち、新規照会または引数は、対話エンジンが需要可能な一致を入手するまでスタックを下方に走査することによって比較され、任意選択によりユーザから確認を得る。ＮＬＵ記号言語のレベルで発話と合致するコンテキストが見つかると直ちにそのコンテキストがアクティブになり、それに対応するプロセスがアクティブになる。アクティブ・コマンドが完了するまで、または新しいコマンドが与えられるまで、この選択されたコンテキストがアクティブとしてマークされ、コンテキスト・スタック４０５の最上位に置かれる。ユーザにメッセージが返されると、コンテキストは更新されて、アクティブ・コンテキストの下に、コンテキスト・スタック４０５の最上位に押し上げられる。アクティブ・コンテキストは更新されて、戻り値があることが通知される。これは、ＣＶＭセッション・ディスコースのレベルでも行うことができる。ＣＶＭセッション・ディスコースはスタック内に、または常にスタック以外にも置くことができ、アクティブ・コンテキストの直後に、スタックを走査する前に探索される。同時に完了したタスクは、ＣＶＭの優先順位（たとえばＦＩＦＯまたはＦＩＬＯ）に従ってアクティブ・コンテキストの下に配置されるコンテキストとなる。タスクを生成するのに十分に完成されたアクティブ・コンテキストは、スタック内で次のコンテキストまたは返されたすべてのコンテキストの下に押し下げられることになる。あるいは、アクティブ・ディスコースになることもある。これは、自動的に、またはユーザがコマンドを出したときに行うことができる。このスタック構造によって、複数のタスク、スレッド、またはプロセスとの曖昧性のない会話型対話を維持することができる。
【０１０９】
要求が完全な場合はそれが実行されるが、たとえば取消しができない場合には、ユーザによる確認を要求することがある。要求が不完全な場合、混在主導権を使用して、照会／コマンドの完成または修正を続ける。コマンド／要求が続けられる場合、ユーザがディスコースを拒否する自由をコンテキストに残しておく。これは、直前のスタック状況（およびプログラム状況）を復元し、スタックを下方に走査することになる。ユーザは、スタックの上方に戻って明示的に要求する必要がある。実行の前またはユーザへの実行の通知の前にユーザが入力を拒否する場合、またはただちに完了する場合、新規入力はアクティブ発話に付加され、スタックの最上位から探索を再開する。アクティブ・コンテキストが確立される前にユーザから提供されるその他の発話は、バッファに格納され、アクティブ発話（音声発話またはその他の入力モード）に付加されるものと見なされる。コンテキスト・スタックは、音声、キーボード、マウス、またはその他の入力またはコマンドおよびアプリケーション出力に応じて更新される。
【０１１０】
本発明によるＣＶＭ４０１が備える特に有用な機能は、「会話記憶」である。会話記憶は、遅延してユーザ、プラットフォーム、または特定のアプリケーションによって割り当てられたタスクおよびコンテキストに戻る機能である。一般に、ユーザによって出された命令／コマンドは、システムのバックグラウンドに明示的に送られる。このようなコマンドは、いくつかの特定のタスクまたは機能が割り当てられたデーモンまたはエージェントを開始する場合がある。これらは記憶を行うことができ、それによって、コマンドまたはイベントのＣＶＭ「タスク・ノート」が得られ、それを報告または実行し、ユーザが選択した特定の時点またはデフォルトによる特定の時点（たとえばセッションの終わり）にユーザに返される。したがって、出力またはバックグラウンド・タスクをリダイレクトして、その結果を後の時点で提示することができる。会話型エージェントが起動される。従来のバックグラウンド・タスクおよびエージェントとは異なり、リマインダ（覚え書き）または結果がユーザに返されると、記憶要求時点の会話コンテキストが復元される。記憶が行われた時点で、コンテキスト・スタック４０５のスナップショットがとられ、記憶されたタスクに関連付けられたメタ情報として記憶される。コンテキスト・スタック４０５は、記憶されたタスクがユーザと対話する時点で配列し直される。現行コンテキスト・スタックが記憶され、古いコンテキスト・スタックはスタックの上部に加えられ、その際、タスクの開始とその完了の間のコンテキストとダイアログの展開による中間変更に基づいて、ユーザまたはアプリケーション・プログラマによってプログラムされた更新、またはＣＶＭによって加えられる更新が行われる。前のコンテキストに戻ることによってユーザと記憶されたタスクとの対話が完了すると、前のコンテキスト・スタックがスタックの最上部に追加される。コンテキスト・スタックが追加されると、重複するものは、スタックの最下部で除去することができる。ユーザ、プラットフォーム、またはアプリケーションは、スタックの保管部分のみを保持するようにすることもできる。会話型アシスタントがこのようなタスクを行う。これらは、エージェントまたはデーモンが単独で実行するだけで実施することができ、出力を生成するときにのみユーザの再対話することができる。その出力は、タスクの優先度に従ってユーザに送られる。アクティブになると、ユーザはエージェントに関連付けられたタスクを容易に更新することができる。会話記憶は、言わばスタックの最下部に挿入されたタスクであり、セッションの終わりにスタックが空にされたときにのみ実行される。場合によっては、これらは所定の時点にスタック内のより高い位置に挿入したり、スタックの最上部に押し上げたりすることもできる。記憶機能は、過去のアクション、選好、および命令を記憶する機能を提供する。
【０１１１】
前述のように、記憶は、アクティブ・コンテキストのスナップショットを保管し、リマインダに関連付けられた会話を復元する。しかし、その時点でのユーザに対する会話とコンテキストを要約することができることも重要である。これを行うには、アプリケーションの開発者（またはユーザ選好、またはＣＶＭプラットフォームによる何らかの決定）は、記入されている場合に、要約してユーザに提示されるフィールド（すなわち属性項目）を提供することができる。これは、システムの各変数／属性に関連付けられたメタ情報に特別なフィールドとして格納される。アプリケーション開発者は一般には、実際の変数名や属性指定ではなく、（使用可能な抽象名によって）各フィールドをアドレスする方法を記述することができる。要約は、アプリケーション決定（アプリケーションの再アクティブ化）、またはユーザの照会、またはＣＶＭによる決定時にアクティブ化することができる。これは、アクティブ・プロセスを探索し、コンテキストを回復し、「照会に関連付けられた属性ｎタプルの埋込み状況」を要約する。要約タスクは、他のアプリケーションに類似したＣＶＭのサービスであり、それによってユーザは要約アプリケーションと対話してより詳細な情報を得たり、要約のために時間を遡ったりすることができる。これは、「go back to application X（アプリケーションＸに戻る）」または「you were telling me to do Y（あなたはＹを行うように指示しています）」と言う単純なものや、対話の履歴をより詳細に遡るきわめて複雑なものにすることができる。
【０１１２】
ＣＶＭ４０１が備える他の機能は、会話型リダイレクトである。たとえばＵｎｉｘプロセスの入出力をリダイレクトするのは容易なため、会話型リダイレクトも同じ機能を実行する。しかし、リダイレクトは、ストリームをリダイレクトしているときに部分混在主導権通知を行うことができるため、より高度なものとすることができる。会話型呼出しを使用すると、優先度によってプロセス結果とユーザへの通知との出力を区別することができる。
【０１１３】
この場合も、前述のように、メタ情報、抽象化、および抽象カテゴリをディスパッチされる各タスクおよびプロセスに関連付けることができ、これによってタスクの特定の選択を行う。たとえば、１つの会話型要求によって（またはキーボードのボタンの押下げ、マウスのクリック、キーを設けることによって）、ユーザは、タスクの出力を聴取したり、コンテキスト・スタックの下方のタスクのために入力（たとえばマイクロフォン）を再要求し、ウェーブ・ファイルまたはＡＳＣＩＩファイルに対して入力ストリームに付加するように指示することができる。同様に、ユーザは、単一のリダイレクト要求を出すことにより、ファイルの送信先のプリンタをリダイレクトすることができる。
【０１１４】
オプション／選好の設定、システムの負荷、またはシステムの機能に基づいて、タスク・ディスパッチャ／コントローラ４０２は、ネットワーク・プロセッサ上でタスクを実行したり、または、別のプロセッサが入力の理解のために使用可能になり、アクティブになって入力を理解することができるようになるまで、またはそのようなタスクを実行することができる装置がネットワーク上で使用可能になるまで、ある種のタスクを据置きにすることを決定することができる。典型的には、ローエンドのハンドヘルド装置上で据置きされた口述は、このモデルに従う。この場合も、サーバ側がアクティブになって転記を行うことが可能になるまで、タスクはタスク上で記憶され、セッションごとに記憶される。同様に、ローカル機とサーバ機との共用インターフェースを、タスク・ディスパッチャ／コントローラ４０２によって管理することができる。たとえば、会話型ネーム・ダイヤラー・アプリケーションを高度自動機能電話に付加することができる。頻繁に使用する名前をローカルで記憶し、認識する。他方、未知の名前や、一度も使ったことのない名前は、認識のためにより強力なネットワーク機に送り、更新された情報（ダイヤルする電話番号など）をダウンロードする。同様に、ローカルで記憶されているすべての情報は、定期的に同期化して電話番号情報を更新することができる。このローカルのプロセス対サーバ・ベースの認識は、タスク・ディスパッチャ４０２によって隠蔽される。ネットワーク共用タスクは、タスクが実行される機械とは関係なく、いくつかのディスコースとしてユーザによって管理される。これは、すべてのトランザクションのためのすべてのプラットフォームにわたるＣＶＭ ＡＰＩの有用性の一例である。これは、会話型プロトコルを使用したネットワーク装置間の会話型サービスの調整を行う方法およびシステムに類似している。さらに、クライアントとサーバの間の分散アーキテクチャおよび分散処理によって、会話型ネットワーキングの新たな要件が生じる。このような要件には、ネットワーク全体の会話型対話に関与する各ユーザの割当て対話を保証するための、トラフィック・フローと、ネットワーク全体に分散されたリソースの管理が含まれる。ここで要素を、ネットワークでの会話型対話のために使用することができる（たとえば対話フローを維持するためのサーバ負荷管理、タスク、特徴要件および機能要件、会話型引数の可用性（データ・ファイル）に基づくエンジン・サーバ選択、会話型プロトコル、再生のための再構築を可能にするピッチによるコーディング・プロトコルを提供する音声ＲｅｃｏＶＣ（認識互換ＶｏＣｏｄｅｒ））。
【０１１５】
タスク・ディスパッチャ／コントローラ４０２は、本明細書に記載の方式でＣＶＭが行う従来型および会話型サブシステムの共用を行わない従来のＯＳと比較して、画期的なディスパッチ動作を示すことを理解されたい。実際に、従来のシステムでは、テキスト入力は常にウィンドウ内で順次に行われ、ただ１つのタスクにしか関連付けられない。キーボードと固有ウィンドウ内に表示されるテキストによって複数の同時タスクを扱う機能は、本明細書に記載のような会話型ディスパッチの原理のほとんどを使用する必要がある。タスク・ディスパッチャは、対話フローを維持する問題に対処し、したがってネットワークおよびＣＰＵの負荷による遅延を最小限にする。タスク・ディスパッチャは、ＣＰＵサイクルと使用可能なネットワーク経路およびリソースに優先順位を付けて、対話の遅延が受容可能な程度まで最小化されるように保証する。エンジンがボトルネックになる場合、そのエンジンはより多くのＣＰＵサイクルを受け取る（その遅れが再吸収されるまで高い優先順位を受け取る）。この場合も、これは、従来のコンピューティングに関係することである。ネットワーク経路が低速になり過ぎた場合、別の経路または別のリソースを見つけて遅延を最小限にする。そうでない場合、応答に遅延が生じる可能性があることをユーザに警告する。アクティブ対話の対話フローはＣＶＭの優先事項である。接続されているすべてのユーザのアクティブ対話の対話フローおよび最小化された遅延は、ＣＶＭがネットワーク内のルータ・ゲートウェイおよびサーバ上で最適化する機能である。
【０１１６】
会話型ＣＶＭシステムが備える他の機能は、「会話型セキュリティ」であり、これによって、ローカルまたはリモートのファイル、特に実行可能ファイルの作成者／変更者に関するメタ情報を、セキュリティの目的に使用することができる。具体的には、音声ベースの会話システムでは、各コマンドが照会の定式化だけでなく、ユーザの認証のための十分な情報も伝えるため、テキスト独立話者検証を使用してユーザの識別と検証を行うことができる。このようにして、制限されたリソースに対する照会が行われるときには常に、そのリソースに関連付けられたセキュリティ・メタ情報に基づいて自動（および透過な）ユーザ認証を行うことができる。前述のように、ユーザ照会および履歴に関して収集されたすべての情報を使用して、ユーザの認識（ＩＤまたは検証）に寄与することができる。
【０１１７】
認証は、要求に対して直接、または照会の少し前に獲得した期限切れになっていない情報を使用して行うことができる。具体的には、ファイルまたはアプリケーションへのアクセスの認証を照会ごとに行うことができる。たとえば、ユーザが制限されたサービスを要求した場合、その特定のサービスにアクセスすることを事前に認証されているユーザのセットを基準にして要求を検証することができる。認証は、要求（たとえばファイル・アクセス、ディレクトリ・アクセス、アプリケーションのオープン、実行可能プログラム、接続、暗号化／暗号解除、デジタル認証／署名）に対して行われるオープン・セット話者識別によって行うことができる。類似のユーザに割り当てられた異なるパスワードまたはユーザＩＤを有するリソースに、明示的ログインやパスワード認証なしにシームレスにアクセスすることができる。いずれにしても、ユーザ対話によって、目立たないユーザ認証を連続的、透過的に行うことができる。
【０１１８】
音声入力がない場合でも会話型ＶＭが実施可能な概念によると、コンテキストのスタックは、ユーザの識別が最も最近に認証された識別として含む必要がある。さらに、各リソースは、認証されたユーザのリストと、いくつかのセキュリティ要件（たとえば非音声の場合は、最新の認証の有効期限）を含む必要がある。当然ながら、キーストリークまたはペン方式の認証も考えられるが、まったく必須ではない。
【０１１９】
各リソースは、それにアクセスを試みる各ユーザの識別をログ／キャッシングすることもできる。これらのログを暗号化し、後で、前にアクセスしたリソースへのアクセス要求を認証するのに使用することもできる。具体的には、オペレーティング・システムは、外部からのパスワード要求をインタセプトし、ユーザにとって透過なログを使用して要求を完全なものにすることができる。新しいリソースは、メタ情報を登録しているときにログイン要求を転送することができ、それによってログイン・プロセスさえもユーザに対してまったく透過になるようにすることができる。これは、単一サインオンまたはパスワード飛越しの概念の拡張である。
【０１２０】
ＣＶＭが備える他の機能は、「会話型カスタマイズ」であり、これによって各タスクまたはリソースへのアクセスを、ユーザ要求者の選好に合わせて個別にカスタマイズすることができる。たとえば、ＣＶＭのパーソナリティ／振舞い（たとえば合成音声−Voiceフォント）を、識別されたユーザの選好に合わせて自動的にカスタマイズすることができる。ユーザがＣＶＭ対話から明示的にログアウト（すなわちセッションを終了する）するまで、そのカスタマイズと選好が固定される。このようなシステムまたはアプリケーションはマルチユーザ式であるが、次のログインまで一度に一人のユーザに一回のみ適用される。
【０１２１】
会話型セキュリティに関して前述したように、リソースに対して照会が行われるときには常にユーザの自動識別を行うことができる。認証は、要求に対して直接、または照会の少し前に獲得した期限切れになっていない情報に対して行うことができる。タスクおよびコンテキストは、アクティブ・ユーザの順序に従って優先順位付けされ、ユーザ変更のたびに優先順位付けし直される。環境変数および選好は、環境全体をリセットする必要なしに、ユーザ識別の変更に基づいて「オンザフライ」で変更を加えることができる。曖昧性は、ユーザ識別を使用して各コンテキストまたはコンテキスト・スタックのレベルで解決することができる。分散型の場合、ユーザまたはサーバ変更に伴い、クライアントからサーバへのコンテキストのロードであるか、サーバ上で維持されているコンテキストの回復であるか、またはサーバ間でのコンテキストの転送であるかを問わずコンテキストを更新する必要がある。
【０１２２】
会話型ＶＭは、複数のユーザの選好およびアクティブ・コンテキストに合わせて動的に適応することができる。これによって、アクティブに稼動中に複数のユーザが可能になる。音声ベースのシステムでは、各コマンドを使用してテキストとは独立した話者識別を行うことができる。ユーザの変更は、新しいアクティブ・コンテキストの作成を自動的に暗黙に示し、新しいアクティブ・コンテキストが新しいユーザまたはアクティブ・アプリケーションによって明示的に破棄されない限りはそれによって直前のコンテキストはコンテキスト・スタックの下位に押し下げられる。ユーザ変更によって、アクティブ・ユーザに関連付けられたタスクが先に処理されるようにコンテキスト・スタックと共に優先順位が自動的に変更される。
【０１２３】
ユーザ識別は各ディスコースのコンテキスト内で関連付けることができるため、コマンドの曖昧性を直ちに透過的に解決することができる（母親からの電子メールは、ユーザとは関係なく正しく理解される）。コンテキスト・スタック４０５を走査するプロセスは、ディスコースの所有者、関連付けられたアプリケーション、または何らかのオプションによって破棄されない限り、同じユーザに対する関連付けられたディスコースによって強化されるので有利である。コンテキスト・スタックを走査する際のこの規則の例外は自動的に、ディスコースに複数ユーザのフラグが付けられることを意味する。会話型セキュリティについて前述したように、ユーザ識別は、ユーザによるユーザ識別の手動選択または入力などの代替手続きによって入手することができる。アクティブ・ユーザ識別の変更も、会話型セキュリティ・サブシステムに影響を与える。各リソースは、そのリソースにアクセスするユーザの識別を記録することができる。
【０１２４】
要約すると、会話型複数ユーザおよび会話型セキュリティに関しては、対話、カテゴリ、メタ情報、およびリソース・アクセスは、ユーザの識別とそれに関連付けられたメタ情報履歴に応じて変化することができることを理解されたい。逆に、照会について収集された会話型情報を使用してユーザを認識することができる。各オブジェクトに関連付けられたメタ情報は、各アクションまたはアクセスの前または後に参照および更新することができる。オブジェクトが作成、修正、または参照されると、ユーザに関する情報がそのメタ情報に加えられ、それによってメタ情報は各オブジェクトに関連付けられたセキュリティ・フィールドと選好フィールドを含むようになる。オブジェクトへのアクセスは、その内容、作成日付、アクセスおよび変更の履歴、およびその他のメタ情報に基づく。アクセスは、ユーザの識別だけでなく、日付、使用履歴、開かれたアプリケーションなどのような追加のメタ情報にも基づいて制御または構成される。言い換えると、画面表示、再生、または実行のためにファイルが開かれるということを条件として、ユーザにファイルへのアクセスを許可することができる。しかし、その人は、ファイルの内容を別のオブジェクトにコピーするためにファイルを開くアクセスは拒否される。さらに、メタ情報を消去不能な方式でオブジェクトにタグ付けすることができる。
【０１２５】
ＣＶＭが提供する他の機能は、「会話型探索」であり、これによって探索機能は、ファイルの名前、変更、またはＡＳＣＩＩコンテンツだけでなく、オペレーティング・システム、アプリケーション、またはユーザによって定義された抽象カテゴリや、オペレーティング・システムによってオンラインまたはオフラインで取り出し可能なトピック、オブジェクトにアクセスしたときにまたはプロトコルを介して入手したトピックに基づくことができる。さらに、コンテキスト探索機能を使用して、アクティブ照会を完成したり、類似した照会／コンテキストを取り出したりすることができる。
【０１２６】
具体的には、各リソースに関連付けられた抽象カテゴリに基づいてリソースを探索することができる。これらのカテゴリは、前述のようにメタ情報概念のコンテキストで定義するか、またはコンテキスト・アソシエーションに基づくことができる。前述のようにディレクトリ内のすべてのイメージの探索は比較的単純であるが、「類似イメージ」の探索は、コンテキスト・アソシエーション、すなわち、ディレクトリ内のすべてのイメージのうち、どのイメージが類似のコンテキストで使用されたか（たとえば現在のイメージの編集に使用されているアプリケーションと同様にカテゴライズされたリソースによるオープン、編集または組込み）に依存する。これは、各リソース／オブジェクト・アクセスのコンテキスト・ロギング／キャッシングによって行うことができる。カテゴリは、それ自体に関するメタ情報も含む。さらに、カテゴリまたはコンテキスト・カテゴリによる探索だけでなく、ユーザ・アクセスによる探索（従来のオペレーティング・システムのように、それを修正するユーザの識別のみによらない）も可能である。
【０１２７】
最終的に、語の部分、語、語トピック、またはコンテキストに基づいてＡＳＣＩＩ、音声、およびその他の転記可能媒体のセットを探索することができる。トピックは、トピック・テキストを識別する機能を含む。コンテキスト探索は、現行のアクティブ照会／コンテキストを完成させるアクティブ・コンテキストまたは候補として、テキスト中で類似のコンテキストを探索する機能を含む。たとえば、「火曜日」というキーワードまたは実際の日付を探索することによって、所定の火曜日を参照するファイルをすべて取り出すことができる。「明日」に言及している月曜日のカレンダ項目もこれらの項目を返すことになる。
【０１２８】
ファイルのトピック判断は、コンピュータを集中的に使用していないときにオフラインで行うことができる。新規ファイルまたは最近変更されたファイルのみを調べる必要がある。トピックは、各リソースに関連付けられたメタ情報に自動的に加えられる。コンテキスト情報は明らかに、常にきわめてＣＰＵを多用するタスクであり、ユーザの明示的な要求でのみ行われる。外部オブジェクトの場合、リソースにアクセスするとトピックを（前述のように）自動的に登録することができる。これは、ローカル機がオブジェクトでそれ自体の（それ自体に関するメタ情報によって定義された）内部抽象化を探索するのを妨げない。
【０１２９】
「会話型選択」の機能も備える。会話型選択機能は、基本選択の長いシーケンスを回避し、選択の自然ショートカットを設け、訂正を行うメタ情報、抽象化、会話型照会／混在主導権／訂正に依存することによって、リソース・マネージャ・レベルで、または任意のアプリケーション内で提供される。階層構造によってオブジェクトの骨組みに直ちにアクセスし、提示する様々な機構を備える。
【０１３０】
具体的には、会話型選択は本発明により、階層的探索（抽象化ベースの選択）と、複合照会機能（対話ベースの検索）との組み合わせを使用して、アクティブ・タスクまたはアプリケーション内から行うことができることを理解されたい。会話型選択は、従来の選択方法の大幅な改良を実現する。実際に、ＧＵＩ環境でも、メタ情報と抽象カテゴリの使用により、所与のアプリケーションまたは照会のための使用可能なリソースの表示が大幅に改良される。具体的には、（抽象化とショートカットを使用する）抽象化ベースの会話型選択では、個人は、（ＩＶＲにおける）音声照会がＤＴＭＦインターフェースを介したメニュー・ページを迂回するのと同様の方式で、メニューや階層選択を迂回することができる。これは、生産性向上の点で会話型インターフェースが備える大きな利点の１つである。また、（たとえばデスクトップ、ＰＤＡ、電話を介した）サービスへのアクセスに使用されるモーダリティとは関係なく、同じインターフェースを使用するという点で、インターフェースの一様性も示している。
【０１３１】
たとえば、ウェブ・ブラウシングのためにデータベースから情報を取り出し、ＨＴＭＬ形式の情報を、ＪＳＡＰＩおよび会話型拡張機能を使用して作成した会話型ヘッダと共に提供するバックエンド・サーバを考えてみる。会話型ブラウザ・モーダリティを介してサーバにアクセスする場合、ユーザは、ポイント指示または発話によって、情報を表示し、所望の情報を選択することができる。そのユーザが電話モーダリティを介してサーバにアクセスする場合、ユーザはＵＲＬとアンカーを含むナビゲーション・メニューを介して選択を行うことができる。これらのナビゲーション・メニューは、ウェブ・ページが会話型ＨＴＭＬを介してブラウザに送信するメタ情報から生成される。
【０１３２】
これらのいずれの場合も、ウェブ・ページまたはファイル・システム、あるいはその他のオブジェクトおよびリソースの階層構造を介した選択によってナビゲーションに使用されるメニューは、様々な補完的方式の１つで適切に提示することができる。たとえば、ネットワーク・オブジェクトの登録時に、メニューによってその構造に関するメタ情報を伝えることができる。さらに、システムは、構造体の構造（スケルトン）の各オブジェクトに関連付けるメタ情報をローカルで追跡することができる。さらに、システムは、ＣＰＵのオフピーク使用中にそのスケルトン情報を定期的に更新することができる。
【０１３３】
システムは、ローカルまたは外部リソースおよび階層オブジェクトを定期的にスパイダーすることができる。あるいは、特に対話構造では、各システムはアクセス可能なリソースに登録し、定期的に、またはアクセス時に、スケルトンメタ情報を更新することができる。さらに、メタ情報サーバは、スパイダリングを行って、メタ情報と共にスケルトン情報を提供することもできる。
【０１３４】
このメタ情報は、メニュー（ＴＴＳ）の提示方法、どのような語彙、ＦＳＧ、およびＮＬＵを使用する必要があるかなどを記述する。さらに、混在主導権およびＮＬＵを使用して選択を訂正することができ、従来のＯＳやＧＵＩベースの選択のように後戻りしたりまったく新しい選択を必要としない。
【０１３５】
したがって、会話型探索および選択に関しては、（ディレクトリを備えたファイル・システムのような）会話型構造だけでなく、プラットフォーム・アプリケーションまたはユーザによってオブジェクトに関連付けられたメタ情報、抽象カテゴリに基づき、関連付けられた動的情報にも基づいて、オブジェクトを探索し、選択することができる。さらに、探索照会は、自然な仕方で行うことができ、混在主導権を使用して絞ることができる。照会は、デコードされ、解析された後、ＮＬＵ技法を使用して照会の論理組合せ（記号照会）に変換される。会話型構造と、カテゴリおよび動的情報を探索し、記号照会と突き合わせることができる。混在主導権を使用して、探索結果に基づく照会の絞り込みと修正を行うことができる。合致するオブジェクトを１つ選び出したり受け入れたりすることができる。
【０１３６】
ＣＶＭによって提供されるその他の機能は、ヘルプ、マニュアル、およびサポートである。会話型インターフェースの最も魅力的な点の１つは、そのようなシステムを使用する際の学習曲線を平坦にすることができることである。実際、ＮＬＵおよび混在主導権は、ユーザに各アプリケーションの使用とシステムの制御を指導するのを支援する。しかし、さらに重要なのは、ユーザがタスクを行っている間にユーザにサポートを提供することができることである。
【０１３７】
会話型サポートは、ユーザからの要求時にヘルプとマニュアルを提供する。これは、アプリケーションのユーザ使用履歴と、同様にカテゴライズされた（メタ情報）カテゴリのユーザ使用履歴に依存する。ユーザの以前のアクションに基づいて、本発明のヘルプ機能について詳細に説明される（たとえば、ユーザがまだタスクを行っていない、ユーザが最近タスクを行っていない、またはユーザが当該タスクを行う際に常に失敗する場合）か、または単純なリマインダが示される（ユーザがそれに習熟している場合）。ユーザがタスクを行っている間、サポート・アシスタントが同時にアプリケーション・マニュアルを追跡する。脱落フィールド、曖昧な要求、一連の訂正および拒否されたコマンドが、アシスタントによって追跡され、混在主導権をヘルプ対話によって強化するために使用される。会話型ヘルプや支援などのサービスと、ＣＶＭシステムによって示されるいくつかの対話プロンプト（概説、質問、フィードバックなど）は、メタ情報リポジトリに格納されているユーザの使用履歴に基づいて調整され、アプリケーションに関連付けることができることを理解されたい。ユーザが前に所与のアプリケーションと対話していた場合、ユーザはそれに習熟しているとみなして説明を短くすることができる。同様に、ユーザが多くの誤りを犯す場合、繰り返される誤りはユーザがそのアプリケーションまたは機能について不確かであるか、習熟していないか、または理解していない／誤解していると解釈されるため、説明をより複雑にすることができる。
【０１３８】
混在主導権／使用サポートから、ＮＬＵ要求および混在主導権、トピック・ベースの探索、マルチモーダル・チュートリアルを介したマニュアルへの会話型アクセスまでにわたる、程度やモーダリティの異なるヘルプが提供される。これは、（たとえば、バックグラウンドでのアプリケーションの更新や再インストールのための）ローカルまたはリモート・エージェントを含む会話型技術サポートの形態を採ることができる。この場合も、ヘルプ・インターフェースの一様性と調整がきわめて重要である。
【０１３９】
ヘルプ情報には、ヘルプ情報にアクセスするためのＮＬＵ照会を使用して、または現行ユーザに関連付けられたメタ情報（履歴）に基づいて、および脱落引数または混在主導権を使用して変更された引数に基づいて、アクセスすることができることを理解されたい。各アプリケーションによって提供される対話は、ユーザの選好または専門知識のレベルに合わせて調整される。
【０１４０】
要約すると、ヘルプおよびサポートは、ローカルおよびリモートのリソース、ユーザの使用履歴、およびエージェントを使用して、要求を完成させ、手続きを手引きし、情報を探索し、新規アプリケーションのアップグレード／インストールを行う、汎用調整会話インターフェースを介して提供される。
【０１４１】
次に、上述のようなＣＶＭを実施するために使用するプログラミング言語／スクリプトについて、詳述する。このようなプログラミング／スクリプト言語により、使用可能な任意のリソースを入力または出力ストリームとして使用することができる。ＣＶＭプラットフォームの会話型サブシステムを使用して、各入力を、プログラミング言語が組込みオブジェクトとして直接処理することができるバイナリまたはＡＳＣＩＩ入力または属性値ｎタプル（または宣言型の同等バイトまたはＸＭＬ）に変換する。呼出し、フラグ、およびタグは自動的に組み込まれ、オブジェクトおよびプロセス間で、異なるオブジェクトと正しくインターフェースするのに必要な会話型メタ情報を伝達する。出力は、アプリケーションまたはユーザの必要に従って特別に形式設定することができる。これらの新しいプログラミング・ツールを使用して、マルチモーダル・ディスコース処理を容易に構築することができる。プログラミング／スクリプト言語は、ファイル・ハンドルやストリーム・ハンドルに類似したハンドルを、会話型システム・アーキテクチャ、すなわち、音声認識／話者認識／会話型システムにおいて提示される会話型サブシステムの入力または出力に与える。これらの入力ストリームは、実際にはシステム呼出しによって実施される、ライブラリ呼出しとして扱われる。ＣＶＭの観点からは、会話型ブラウザを、会話型アプリケーションとみなすか、またはその構成要素（たとえばＸＭＬパーサ）およびプラグインを会話型アプリケーションを含む会話型エンジンの一部と見なすことができることを理解されたい。
【０１４２】
マイクロフォンからの音声入力（たとえば標準音声入力）は、語、音のシーケンス、またはユーザ識別または照会（ＮＬＵが提供する記号言語表現）による関数呼出しの引数とすることができる。入力は、手書きによって、またはファイルなどからも供給することができる。各結果ストリームは、オブジェクト指向コンテキストにおける導出クラスと見なすことができる。
【０１４３】
プラットフォーム・スクリプトの場合、発話は、会話型サブシステム・サービスの１つによって処理され、スクリプトによって処理されてから、アクションを引き起こす。会話型コマンド・アンド・コントロール環境（たとえばViaVoiceのVoice Center）は、会話型スクリプトによって作成された比較的単純な会話型プラットフォームと見なすことができる。スクリプトを修正することによって、プラットフォームが修正される。実際には、Voice Centerは、従来のＣ／Ｃ＋＋コードによって作成され、これは入力ハンドと、コマンドの認識および実行をコード内に深く隠蔽する。コンテキスト、音声状況などをプラットフォーム内に設定して、環境変数や大域変数を更新することができる。この場合も、前述のように会話型オブジェクト／構成要素およびファウンデーション・クラスを手続き型または宣言型とすることができる。
【０１４４】
本発明の一態様による前述の入力プロセスは、音声またはその他の入力ストリームが、一般に文字入力または記号入力のために確保されたあらゆる種類の処理形態を採ることができる従来の入出力ストリームとして組み込まれるとみなす。ユーザ入力は、解析およびＮＬＵの後に、それぞれの転記、または記号言語へのマッピングによって表現することができる。さらに、出力もスクリプト／プログラミング言語によって完全に制御することができる。Voiceフォントを、メッセージに応じて選択、または設計、修正することができる。このような会話型プログラミング言語およびスクリプトの使用により、複合リダイレクトおよび会話プロセッサまたはマルチモーダル・ディスコース・プロセッサを構築することができる。これらは、たとえば従来のワード・プロセッサおよび描画／写真／ビデオ・エディタの自然マルチモーダル拡張版である。ＣＶＭを含むファウンデーション・クラスについては前述した。
【０１４５】
さらに、他のオブジェクトとストリームを交換する場合、ストリームのナビゲート、制御または合成のために、データ・ストリームを会話型メタ情報をシームレスに追加することが重要である。他のオブジェクトまたはサブシステムと通信する場合、これはシステム関数呼出しによりローカルで行われる。ネットワーク・オブジェクトは、ＨＴＴＰ／ＨＴＭＬ、ＴＣＰ／ＩＰのような他のリモート・プロトコルを介して、または多様な形態のソケット対話を介して通信する。これらのプロトコルは、この会話型メタ情報を交換することができるタグ、フラグ、およびセマフォによって補完される。
【０１４６】
このようなプログラミング言語は、新しいスクリプト言語の形態とすることができるまったく新しい会話型ツールであり、ＰＥＲＬおよびＫｓｈｅｌｌ、ＣおよびＣ＋＋、ＨＴＭＬ、Javascript、Basic、Javaなどの拡張版であり、Spoken ＰＥＲＬなどと呼ぶことができる。解釈（スクリプト／宣言型）またはコンパイル（手続き型）される会話型ファウンデーション・クラスおよび対話構成要素（手続き型または宣言型）のライブラリによってＣＶＭ上での実行を最適化するように、言語を最初から新たに構築することもできる。
【０１４７】
前述のように、プログラミング言語／スクリプトは、会話型アプリケーションとＣＶＭとの間の会話型ＡＰＩを含む。また、ＣＭＬ（会話型マークアップ言語）も含む。ここで、手続き型ＡＰＩおよびプロトコルとＣＭＬ（ＸＭＬおよびＨＴＴＰ）との区別、およびトランスポート・プロトコルの変形プロトコルについて述べておく必要がある。手続き型ＡＰＩは、ＣＶＭを会話認識アプリケーションに露出させる。手続き型ＡＰＩおよびプロトコルによって、ＣＶＭ、アプリケーション、および装置間での会話型情報の高速な交換を可能にし、コントローラによる各アプリケーションおよびコンテキスト切換必要手続き型インターフェースの状態の高速な判断を可能にする。一方、ＣＭＬは、提示素材／内容を会話型ブラウザに伝達する理想的な方法であり、ＸＭＬの目的と合致し、対話の開発に必要なプログラミング専門知識を少なくするという利点を有する。
【０１４８】
前掲の特許出願に記載されている会話型ブラウザタイプのインターフェースでは、ページ間でＸＭＬが交換されるが、ページ間および複数の同時タスク間でのコンテキストは、ＡＰＩ／プロトコルを介してブラウザによって管理される。この実施態様は、たとえば、純粋にソケット・ベース（ＴＣＰ／ＩＰ）、ＨＴＴＰＣｏｒｂａ／Java ＲＭＩベース、または（ＸＭＬを使用した）順次化オブジェクトの交換によるＨＴＴＰベースとすることができる。プロトコルは、ＸＭＬ（宣言型）と手続き型の通信がサポートされるように設計することが好ましい。
【０１４９】
会話型スクリプトによって開かれる可能性の中でも、会話型論理は恐らく最もめざましいものであろう。新しい会話型プログラミング言語のレベルでは、従来型および会話型のサブシステムに発行され、供給されるストリームに対する直接処理は、新しい論理ストリームおよび演算子を暗黙に示す。
【０１５０】
論理ストリームは、（１）真、（２）偽、（３）不完全、（４）曖昧、（５）ＡＳＣＩＩの視点での異／同、（６）ＮＬＵの視点からの異／同、（７）アクティブ照会フィールドの視点からの異／同、（８）不明、（９）非互換、（１０）比較不能を含む。会話型論理演算子を導入して、このようなステートメントのテストまたは修正を行うことができる。要約すると、ＡＳＣＩＩ／バイナリ内容に基づいて、またはＮＬＵ変換された照会（従来型および会話型サブシステムの入出力）に基づいて比較することができる豊富な会話型照会を扱うように、論理ステートメント状況および演算子を会拡張する。このようなシステムのテストまたは修正を行うように論理演算子を実現することができる。
【０１５１】
次に図７を参照すると、本発明の一態様による分散ＣＶＭのアーキテクチャが図示されている。この分散型システムの中核はＣＶＭ７０４（サーバ、ＰＣなどに置くことができる）であり、複数のアプリケーション７０６、装置７０８〜７１３、その他のＣＶＭアプリケーションまたは装置７０７、および会話型リソース７０５間の会話型アービトレータとして機能する。ＣＶＭ７０４は、このような装置およびアプリケーションにわたって調整された一様な会話型インターフェースを備え、それによって異なる会話型装置７０８〜７１３、リソース７０５、アプリケーション７０６が本発明の会話型プロトコルを介して接続することができる。複数の会話接続された装置／オブジェクトによって、調整インターフェースが提示される。オブジェクトの集合が、ＣＶＭ７０４の集中または分散コンテキスト・スタックを介してユーザに対して単一の調整インターフェースを提供する。会話型装置は、他の会話型装置から会話型インターフェースを介して制御可能なサイレント・パートナを含むことができる。登録段階で、これらは要求時にサポートされているコンテキストのリストを交換する。接続時に、これらのコンテキストが更新される。接続に応じて、コンテキストは集中化または装置間で分散される（すなわちネットワークが折衝される）。
【０１５２】
ユーザが装置の集合と対話するとき、対話は常に車内のＰＶＡ（パーソナル・ビークル・アシスタント）７１０、または音声ブラウザ７１３などの中央ユニットを介して行うことができる。タスク・ディスパッチャおよびコンテキスト・スタックは、すべての装置に関連付けられたコンテキストを蓄積し、各装置に対するコマンドを解析し、適切にディスパッチする。ユーザが装置の集合全体と対話する場合、装置は常にアクティブである（最後にアクティブにされたコンテキスト）。当該装置は、新規コマンドがそのコンテキスト・スタックに適合するか否かを調べる。適合しない場合は、アクティブになる隣の装置に渡す。このプロセスは、一致が見つかるまで繰り返され、場合によってはユーザによって確認され、または要求は最初の装置に戻される。その場合、ユーザにエラー・メッセージまたは混乱メッセージが返される。
【０１５３】
前述のように、ＣＶＭは、複数のディスコースを管理し、コンテキストを使用し、抽象化およびメタ情報を介してオブジェクトを参照し、タスク、抽象化、コンテキストの割当てと記憶を行い、ユーザの認識と認証を行い、ディスプレイ、ＧＵＩ、キーボード、またはポインティング・デバイスを使用するか否かを問わず、すべての対話を通して同じインターフェースを提示する機能を備えることによって、ユーザがシステムと対話できるようにする。同じ対話は、チャネルに無関係の機能を付加または省いて、電話、ウェブ、ＰＤＡ、デスクトップを介しても行われる。
【０１５４】
たとえば、ユーザはスプレッドシートの要素に関する情報にリモートからアクセスし、必要であれば修正すると同時に、自分のメールをチェックする。ユーザは、これらのすべてのタスクを（デスクトップの前にいるときに）従来の方式で行うことにするか、または、電子メールをタイプで仕上げながら、スプレッドシートの情報を目で見ないで音声で調べることができる。いずれの場合も、ユーザにとってインターフェースはシームレスに同じである。
【０１５５】
複数の装置が会話接続されている場合、それらの装置は、すべての装置を汎用ＣＵＩを介して制御することができるようにそれぞれのインターフェースを調整する。この概念を以下の例で示す。夜、自動車で帰宅途中であり、配偶者から新しい食料品店で何かを買ってくるように頼まれたのを思い出したとする。留守番電話でメッセージを見つけた後、音声認識ソフトウェアを使用してそれを急いでデスクトップのメモ帳に転記した。しかし、それをプリントするのもＰＤＡに転送するのも忘れた。しかし、デスクトップＰＣがＣＶＭを稼動させてれば問題はない。なぜなら、問題車内にＰＤＡ、会話型車載ＰＣ（ＰＶＡ、パーソナル・ビークル・アシスタント）と会話型高度自動機能電話を備えているためである。さらに、ＰＶＡが組込みＣＶＭを稼動させていると同時に、他の２つのアプリケーションが会話認識であるものとする。すなわち、ＰＶＡで稼動しているＣＶＭを介してそれらのアプリケーションを制御できるものとする。
【０１５６】
ＰＶＡに、電話を使用してＰＣにダイヤル接続するように指示することができる。接続が確立された後は、音声により認証され、前に作成した「食料品リスト」を音声により要求するだけでそのメモを見つけることができ、ファイル名やディレクトリを思い出したり、ディレクトリを閲覧してやっと適切なファイルを選択したりしなくても済む。ＰＣ ＣＶＭが要求する場合には、その選択を確認する必要がある。「これをＰＤＡと同期させなさい」という別の照会を出すことができる。すると、そのファイルが次の同期でＰＤＡに転送されるようにリンクされる。最後のコマンド「実行！」を出すと、ＰＣは手に負えず、ＰＶＡにその曖昧な照会を処理させる。ＰＶＡは、その希望を理解して、直前に会話に基づいてＰＤＡとＰＡＣを同期させる。確認後、同期化が行われ、食料品リストがＰＤＡに格納されて、後で使用できるようになる。
【０１５７】
次に、ＰＶＡにその店まで曲がり角ごとに案内するように指示する。現在位置が計算され、店の場所がローカルで、またはサーバから取り出され、最新の更新情報を考慮に入れて道程が計算される。随時、現在位置に関するナビゲーション情報、次にすべき事、目的地までの距離を要求することができ、異なる道程も要求することができる。
【０１５８】
時間に追われて、ＰＶＡに、店のドライブ・スルー・サーバにダイヤルするように指示する。これには、電話番号案内サービスＩＶＲとの中間会話が必要になる。現在のホーム・ページと同様に構築されたスモール・ビジネスまたは個人消費者ＩＶＲの概念の一例である、店のＩＶＲと、会話型インターフェースとの対話を介して接続した後、注文を出す。そのために、ＰＶＡに対して、食料品リストをゆっくりとブラウズして項目ごとに読み上げるように指示する。次に、ＩＶＲに対してその要求を言い直し、各注文が適切に取られるまで対話を続ける。
【０１５９】
店に到着するまでに、注文はできている。これで、家まで車を運転しながら静かに電子メールや、ニュース、株式市況を聞くことができる。必要であれば、自分のＰＣにダイヤルし、スプレッドシート情報を調べたり、修正したりすることができる。これは、デスクトップ機でメールを処理しながら音声で調べるのと同じ方法である。また、ＰＶＡまたはデスクトップ機でエージェントにタスクを割り当て、更新または後で思い出させるように要求することもできる。
【０１６０】
デスクトップ機、ＰＶＡ、ＣＶＭ認識高度自動機能電話、およびＰＤＡでＣＶＭを稼動させる場合、アプリケーション開発者はＣＶＭ ＡＰＩに接続するだけで済む。これには、以下のような、そのすべての会話機能と要件を登録することが含まれる。
１．アプリケーションを制御するためのアクティブ語彙、有限状態文法、言語モデル
２．ＮＬＵまたは少なくともコンテキスト状態リストがサポートされている場合、記号マッピング
３．特に出力のカテゴライズを可能にする関連付けられた該当メタ情報／カテゴリ
４．会話型入出力情報。入出力を直接制御するか、サイレント・パートナであるか、または会話型入出力プロバイダのクライアントであるか、および
５．ＣＶＭ機能／状態。ＣＶＭを稼動させているか、ＣＶＭクライアントであるか、マスタ、スレーブ、またはパートナＣＶＭであるか
【０１６１】
上述の例では、ＰＶＡはマスタＣＶＭであった。ＣＶＭを装備している場合、ＰＤＡおよび高度自動機能電話はスレーブＣＶＭ、または単にＣＶＭ認識機である。ＰＶＡがＰＣに会話接続する場合、ＰＶＡがマスタ、スレーブ、パートナのいずれとして機能するかを決定するのは、アプリケーション開発者である。ローカルで、または電話を介して接続する場合、装置はＡＰＩで伝えられた必要な情報を交換し、それによって装置間の調整を完全に定義する。この場合も、ＣＶＭは、会話型および従来型サブシステムを含めて、すべての入出力問題を自動的に処理する。またこの場合も、ＡＰＩはＣＶＭのためのすべての情報を伝え、照会をアプリケーション呼出しに変換し、逆に出力を音声に変換し、適切にソートしてからユーザに提供する。
【０１６２】
開発者は、開発ツールを使用して、会話型ＡＰＩおよびＣＶＭを中心にしたアプリケーションを容易に作成することができる。この開発環境（本明細書ではSpoken Age（スポークン・エイジ）と呼ぶ）によって、プログラマは、ＣＶＭのエミュレート、アプリケーションまたはネットワーク・プロトコルのデバッグ、および会話型ユーザ・インターフェースの迅速な開発を行うことができる。Spoken Ageは、ＣＵＩおよびＣＶＭ用アプリケーション開発機能を含む。また、所与のアプリケーションのためにエンジンのデータ・ファイル（会話型引数）を修正する環境も備える。具体的には、これは、ツールのレベルでSpoken Ageが、ＩＢＭのViaVoiceツールキットなどのＳＤＫツールキットのような、会話型エンジンのフロントエンドも含むことを意味する。これは、Spoken Ageが備えるツールキットとアルゴリズムによって、ユーザが所与のタスクのためにデータ・ファイルの再作成、適応化、または拡張を行うことができることを意味する。これには、データ収集規則に従ってアプリケーションのためにデータを収集することと、適切なスクリプトを実行してデータ・ファイルを生成し、パフォーマンスをテストすることが含まれる。これは、タスク、ドメイン、または音響環境専用のデータ・ファイルまたはデータ・ファイルの一部を（ＣＤ ＲＯＭまたはウェブ・サイトから）ダウンロードすることも含まれる。また、書式に記入し、新規アプリケーションの記述／データ例の提示を行うことによって、データ・ファイル・サービス・オフィスに行った照会にも続いて、データを更新することも含まれる。
【０１６３】
プラットフォーム上および特定のチャネル用にアプリケーションを開発した後は、プログラマはSpoken Ageによって、ＣＶＭをサポートする他のどのようなプラットフォームにでも移植することができる。プログラマは、ＣＶＭによって、その会話型機能を、新しいプラットフォームまたは装置による通信チャネルまたはＵＩの制約に合わせて自動的に適応させることもできる。また、Spoken Ageを使って書かれたJava、ＣＧＩ、およびＸＭＬ／ＨＴＭＬベースのウェブ・サイトを、電話または小型の組込み会話型ブラウザによってアクセスする限定された音声マークアップ言語を介してサービスを提供するＩＶＲに直ちに変換することができる。
【０１６４】
分散システムは、ＣＶＭと共に動作可能な魅力的な音声使用可能アプリケーションである会話型ブラウザ７１３をさらに含む。会話型ブラウザは、ＣＶＭ上で稼動することができ、ＣＭＬを解釈して会話型対話を作成すると同時に、ＣＭＬページを提示することができる。図７に示し、前掲のＩＢＭ整理番号ＹＯ９９８−３９２Ｐ特許出願で詳述しているように、会話型トランスコーダ・プロキシ・コードを介してレガシー・アプリケーション７００にアクセスし、ＨＴＭＬやＤＢ２のような従来の形式をＸＭＬにトランスコードすることができる。会話型ブラウザは、ＸＭＬ仕様に基づく音声マークアップ言語であるＣＭＬ（会話型マークアップ言語）を解釈する。これは、ＣＶＭ上で稼動する最も魅力的なアプリケーションの１とみなすことができる。会話型ブラウザは、それ自体のＣＶＭを持つスタンドアロン・アプリケーションとすることができる。ＣＭＬによって、初心アプリケーション開発者でも、会話型対話を迅速に開発することができる。ＨＴＭＬおよびワールド・ワイド・ウェブとの類似点をさらに続けて挙げると、ＣＭＬおよび会話型ブラウザは、レガシー企業アプリケーションおよびレガシー・データベースの周囲に会話型ユーザ・インターフェースを構築する簡素でシステマティックな方法を提供する。さらに、この機構をＣＶＭの上に構築した後は、これらのアプリケーション、サービス、およびトランザクションを会話に組み込むことができ、ユーザはそれを複数の（ローカルおよびネットワーク）アプリケーションおよび（ローカルおよびネットワーク）装置にわたって伝えることができる。また、ユーザが、会話型ブラウザを稼動させているＰＣまたはＩＶＲでレガシー・アプリケーション、会話型アプリケーションにアクセスするとき、またはサーバ側にある会話型アプリケーションにアクセスするときに、ユーザに同じユーザ・インターフェースも提供する。ＨＴＭＬ対話をＣＭＬに変換する会話型プロキシの使用により、同じページでＰＣまたは組込み装置上の従来型またはマルチモーダルのブラウザ、会話型ブラウザ、およびＩＶＲアプリケーションを駆動することができる。電話カードを備えたサーバ上の適切に設計されたホーム・ページは、パーソナルＩＶＲにもなる。特に、会話型プロキシを導入してＨＴＭＬページをＣＭＬページにトランスコードした場合にそうである。
【０１６５】
ＣＶＭはＡＰＩおよびＣＶＭを介して露出され、分散リソースはＡＰＩおよび手続き型プロトコルを介して最も効率的に対話するが、対話プロトコルをＨＴＴＰおよびＸＭＬ／ＨＴＭＬ交換を含めるように拡張することが重要である。実際、単一、または順次の会話型トランザクションには、ＨＴＴＰおよびＸＭＬ交換、または場合によっては順次化オブジェクトで十分な場合もある。最適プロトコルを選択し、ＸＭＬ交換を可能にするオプションによって、ごくわずかなプログラミング知識で対話の設計を簡略化することができる。一方、手続き呼出しにより、複数の同時会話アプリケーションを備えたきわめて効率的なローカルまたは分散実施態様を設けることができる。効率的な会話プラットフォーム機能は、ＡＰＩインターフェースを必要とする。複数の会話型アプリケーションにわたって効率的な対話マネージャは、異なるサブシステム、アプリケーション、および関係ＣＶＭエンティティ間での手続きオブジェクトの交換を必要とする。
【０１６６】
ＵＣＲＣ（Universal Conversational Remote Control（汎用会話リモート・コントロール））とも呼ぶ、図８に示すようなＵＣＡ（Universal Conversational Appliance（汎用会話機器））を使用する本発明のアプリケーションの例を以下に示す。このＵＣＡまたはＵＣＲＣは、会話型プロトコルの複数の態様を含むＣＶＭ装置の一例である。ＵＣＲＣは、自発ネットワーク機能を有する音声使用可能携帯型ＰＤＡである。このネットワーク機能は、ＲＦ、特別機能（たとえばブルートゥース、ホッピング・ネットワーク）またはＩＲとすることができる。家庭環境では、機器は会話認識となる（ただし一般にはサイレント・パートナである）。これは、異なる機器を検出し、必要な情報を交換して会話制御することを意味する。異なる機器が同様のネットワーク機能を有する。簡略化された場合には、これらは、Ｘ１０のような永続ネットワークを使用する「ホーム・ディレクタ」タイプのインターフェースによって直接制御される。この場合、ＵＣＡはホーム・ディレクタと直接対話する。
【０１６７】
ＵＣＲＣは、（前述のように）会話型プロトコル８０１を介してハンドシェーク（検出）要求を周期的に（きわめて頻繁に）ブロードキャストする。各機器（またはホーム・ディレクタ）は、このような要求を検出すると応答する。新たに検出された機器はそれ自体の識別情報を示す。ＵＣＲＣもそれ自体の識別情報を示す。その結果のハンドシェークによって、登録が行われる。登録には、機器の性質と名前の識別（およびその他のメタ情報）およびそれがサイレント・パートナであることが含まれ、次にこれによって折衝が行われる。
【０１６８】
この場合、折衝ではＵＣＲＣが会話を駆動することで直ちに合意する。新たに検出された機器は、その現在の状態と、その状態でサポートするコマンドとを交換する。限られた数のコマンドをサポートする場合、サポートする他の状態と、それらの他の状態に関連付けられたコマンドも送る。これは、前述の構造スケルトンの送信に相当する。状態の構造が複雑すぎる場合、この情報通知は状態が変わるたびに状態ごとに行われる。
【０１６９】
交換プロセスでは、アクティブ化時に戻りハンドル／イベントによるコマンドのリストを機器に返し、さらに、場合によっては必要なすべてのデータ・ファイル、すなわち語彙、基本フォーム、対話のためのプロンプト／音声フォント、文法、場合により解析、変換、タグ付け、記号言語、およびＮＬインターフェース用の言語生成規則も返す。あるいは、この情報は、会話型エンジン・タスクを実行する他のエンジン（たとえば音声認識タスクなどを実行するサーバなど）のアドレスを含むことができる。アクティブ化時およびユーザからの入力時に、ＵＣＲＣ ＣＶＭは関連付けられた機器を判断する。これは、異なる機器によって（ローカルまたはリモートで）サポートされるコマンドに従い、認識結果に基づいて行われる。
【０１７０】
決定すると、イベント／戻りハンドルがアクティブ化され、その関連付けられた機器でコマンドが実行される。その結果、状態が変化する。この新たな状態はＵＣＲＣに伝達される。ＵＣＲＣ上のコンテキストも更新される。コマンドは、スケルトンに基づいて、またはサポートされているコマンドの新たな交換に基づいて更新される。機器が一時的にネットワークから消える場合、この情報はコンテキストに格納される（機器が依然としてＵＣＲＣによって制御されている場合）。これは、時間（最後に検出されてからの経過時間）または場所（メタ情報）または（非アクティブ化される場合）メタ情報に基づいて行うことができる。再アクティブ化されると、情報のほとんどはコンテキストまたはメタ情報から再ロードされ、プロトコルは更新がないかのみ調べる。
【０１７１】
機器が制御リストから明示的に除去される場合、その装置から、またはＵＣＲＣからサインオフ要求が明示的に送られる。機器が従来方式で制御される場合（テレビジョンの従来のリモート・コントロール、または照明器具のスイッチなど）、ＵＣＲＣにイベントが返され、コンテキスト、データ・ファイル、および機器の状態の登録／折衝、あるいは単なる更新が行われる。
【０１７２】
ホーム・ディレクタを使用する場合、以下の２つのモデルを採ることができる点を除き、プロトコルはまったく同じであることに留意されたい。
１）１つアプリケーション、すなわちホーム・ディレクタのみが登録される。機器変更またはコマンドの結果、ホーム・ディレクタ全体の状態が変更される。
２）個々の機器すべてがＵＣＲＣに登録される。ホーム・ディレクタは、機器とＵＣＲＣとの間でプロトコルの送信とトランスコードを行うゲートウェイとしてのみ機能する。
【０１７３】
ホーム・ディレクタ・モデルについて考えてみると、ＵＣＲＣによって提供される機能を拡張することができる。自発的ネットワーキングではなく、通常のワイヤレスＬＡＮ（ホーム・ディレクタに接続されたベース局とのイーサネット、ＲＦ）とすることもできる。範囲外の場合には、ホーム・ディレクタ・ソリューションは、通常の電話（たとえばモデム・タイプの接続）によって呼出し可能であるという利点がある。そのような場合、すべてのプロトコルは、電話を介して交換することができる。したがって、新ＵＣＲＣ技法は、範囲内にあるときにローカルまたは自発ネットワーク機能を備え、範囲外にあるときにはベース局へのバイナリ接続機能を備えて常に勝ち得から制御されるセルラーホン／ＵＣＲＣである。
【０１７４】
あるいは、ＵＣＲＣ機能を重複させたり、ホーム・ディレクタ機に限定したりすることもできる。重複させる場合、機械が電話カードを介した音声ブラウズ機能またはローカル・ホームＩＶＲ機能を備える場合には、家庭用機器は、電話によって（Ｃおよびサーバ交換会話プロトコルを介したバイナリ接続の必要なしに）どこからでも制御することができる。ＵＣＲＣおよび会話プロトコルは、ホーム・ディレクタと機器との間にある。任意の通常電話を使用することができる。第２の事例では、家庭にあるときには機器の制御には通常、サーバも使用される。ＵＣＲＣは、携帯型入出力システムになる。すなわち、音声を取り込み、圧縮してホーム・ディレクタに送る（会話型コーディング）。出力も同様に、再生のためにＵＣＲＣに送られる。実際のＣＶＭ処理はすべて、ホーム・ディレクタ・サーバ上で行われることになる。
【０１７５】
次に図１２を参照すると、本明細書に記載の構成要素および機能を使用して構成可能な会話型ネットワーク・システムが図示されている。本発明による会話型コンピューティングは、異なる装置のネットワーク化という点で新しい要件を意味することを理解されたい。これは、すべてのプロトコル、負荷およびトラフィックの管理、ネットワーク・キャッシングおよび記憶における主要な考慮事項が、負荷またはトラフィックのバランスを保証することだけではなく、さらに、ネットワーク上で現在会話をしているユーザまたはネットワーク・リソースを使っているユーザのすべてのアクティブ対話の対話フローを最適化することであるということを意味する。言い換えると、会話型分散アーキテクチャによって、対話の遅延およびフロー、音声送信（会話型コーディング）の遅延、音声とＧＵＩ構成要素との同期化（実際、ＧＵＩ入力の結果として、イベントおよび、ＵＩの音声構成要素とＧＵＩ構成要素との同期化／協調動作が行われなければならない）、および基礎会話型プロトコル（折衝、対話マネージャ・プロトコルなど）の更新と交換を最適化するために、新たな追加の制約または考慮事項をが加えられる。このような面は、ローカルまたはネットワークあるいはその両方でのシームレスで透過的な処理が望まれる場合に重要な役割を演じる。サービス品質、帯域幅、最小遅延、最小パケット損失などは、依然としてＶｏＩＰの場合と同様に重要である。
【０１７６】
さらに、特定のタスクおよびドメインに必要なデータ・ファイルを適切なエンジンに適切に転送する問題がある。この場合も、ネットワーク上でのキャッシュまたは記憶と、特に精細なトラフィック管理および負荷管理を必要とする。やはり、送信側と受信側との間のトラフィックのフローのみが問題であるＶｏＩＰの場合でさえも存在しない概念である。さらに、スケルトン情報（すなわち対話論理）でさえも、ネットワーク内で適切に事前記憶、キャッシュ、または重複させることができ、効率が向上する。
【０１７７】
図１２に示すシステムでは、本発明によるクライアント装置１０００（ＣＶＭシステムまたは対話マネージャ機能を備える）は、ＰＳＴＮ１００２を介して接続することによってサービス・ネットワーク・プロバイダ・ネットワーク１００１と、ルータ１００４を介してインターネット／イントラネット１００３ネットワークの所望の情報にアクセスすることができる。ルータ１００４とインターネット／イントラネット・ネットワーク１００３は、会話型ネットワーク・サービス拡張機能および機構を提供する。これには、（前述の）分散会話プロトコル、ＲｅｃｏＶＣ（認識互換ＶｏＣｏｄｅｒ）による音声コーディング、アプリケーションおよびメタ情報（分散アプリケーション・プロトコル）、ディスカバリ、登録、折衝プロトコル、対話フローとトラフィック・バランスを維持するためのサーバ負荷管理、対話フローを維持するルーティング、タスク機能および能力要件と会話引数可用性（データ・ファイル）とに基づくエンジン・サーバ選択、会話引数（分散：記憶）、トラフィック／ルーティングおよびキャッシングが含まれる。
【０１７８】
図１２に示すような任意のネットワーク（インターネット、ブルートゥース、ワイヤレス・ネットワークなど）および会話型アプリケーション・サービスまたはコンテンツまたはトランザクション・プロバイダのイントラネットでは、ネットワークはコンテンツ・サーバとバックエンド・論理または業務論理サーバ、会話型エンジン・サーバ、ゲートウェイ、ルータ、プロキシ、およびＩＶＲ（たとえばサウンド・カードのような）およびサーバ・ブラウザを有し、これらのリソースの間で音声ファイルおよびデータ・ファイルが会話型ネットワーキング原理による最適化に従って、絶えず交換される。
【０１７９】
したがって、ＣＶＭ構成要素または会話型サービスは、これらすべてのエンティティ（サーバ、クライアント、ゲートウェイ、ルータなど）上に存在して、会話型ネットワーキング測定、送信、管理、および様々な機能の実行のためにメッセージを交換する必要がある。一般に、これらの機能は、ネットワーク内の負荷分散、トラフィック分散、記憶およびキャッシングなどを行うために、既存のプロトコルおよびシステム上で実行される。
【０１８０】
本明細書では例示の実施形態について添付図面を参照しながら説明したが、本システムおよび方法はこれらの厳密な実施形態には限定されず、当業者なら本発明の範囲および主旨から逸脱することなく、他の様々な変更および修正を加えることができることを理解されたい。このような変更および修正はすべて、特許請求の範囲に定義されている本発明の範囲内に含まれるものと意図される。
【図面の簡単な説明】
【図１】 本発明の一実施形態による会話型コンピューティング・システムを示すブロック図である。
【図２】 本発明の一実施形態による対話型コンピューティング・システムの抽象層を示す図である。
【図３】 本発明の一態様による会話型コンピューティング・システムで実施される会話型プロトコルを示すブロック図である。
【図４】 本発明の一実施形態による会話型コンピューティング・システムの構成要素を示すブロック図である。
【図５】 本発明の一態様によるタスク・ディスパッチ・プロセスを示す図である。
【図６】 本発明の一態様による会話型ユーザ・インターフェースおよび入出力プロセスの概要を示す図である。
【図７】 本発明の一態様による分散会話型コンピューティング・システムを示す図である。
【図８】 本発明の一実施形態による汎用会話型装置を示す図である。
【図９】 本発明の一態様による対話管理プロセスを示す図である。
【図１０】 本発明の他の態様による対話管理プロセスを示す図である。
【図１１】 本発明の他の態様による対話管理プロセスを示す図である。
【図１２】 本発明の対話型ネットワーキングを示す図である。

Claims (10)

1. 複数の入出力リソースから、ユーザが入出力を行うための会話型ユーザ・インターフェースと、
   前記会話型ユーザ・インターフェースによる入力に対して、グローバル履歴もしくはメタ情報と前記入力に関連するコンテキストを使用して対話を管理する対話マネージャ、前記コンテキストと前記グローバル履歴と前記メタ情報とに関連づけられたコンテキスト・スタック、および、タスクおよびプロセスのディスパッチと調整を行うタスク・ディスパッチャコントローラ、を備える会話型仮想計算機と、
   を備える複数のコンピュータがネットワークを介して接続されたコンピューティング・システムにおいて、
   前記複数のコンピュータのうち一のコンピュータの対話マネージャが、このコンピュータの会話型ユーザ・インターフェースから入力されたコンテキストに対応する使用可能なすべてのアプリケーションに関連する情報を含むグローバル履歴もしくは使用可能なリソースに関連するメタ情報があるかを判断し、このコンテキストに対応するグローバル履歴もしくはメタ情報が、このコンピュータのコンテキスト・スタックに記憶されていないと判断した場合には、前記対話マネージャが、前記一のコンピュータ以外の他のコンピュータの対話マネージャと通信を行い、前記他のコンピュータの前記グローバル履歴および前記メタ情報に含まれるユーザ利用履歴に基づいて前記コンテキストに対応する出力を調整し、前記一のコンピュータの会話型ユーザ・インターフェースが、この調整した出力を行うコンピューティング・システム。
2. 前記対話マネージャが、オペレーティング・システムの会話型カーネルと、この会話型カーネルと、ユーザからの入力とを仲介する会話型アプリケーション・プログラム・インターフェース（ＡＰＩ）とから実現される請求項１に記載のコンピューティング・システム。
3. 前記会話型アプリケーション・プログラム・インターフェースが、会話型ユーザ・インターフェースまたは会話認識アプリケーションを構築するために使用可能な会話型ファウンデーション・クラスまたは基本対話構成要素のライブラリ関数を含む請求項２に記載のコンピューティング・システム。
4. 前記会話型ユーザ・インターフェースが、ユーザからの入力を受ける汎用自然言語理解（ＮＬＵ）インターフェース又は、前記対話マネージャが調整した出力を行う自然言語生成（ＮＬＧ）インターフェースのうちのいずれか一方を含む請求項１に記載のコンピューティング・システム。
5. 前記対話型マネージャにより前記他のコンピュータのグローバル履歴もしくはメタ情報から、前記コンテキストに対応する出力を調整した後に、前記他のコンピュータのタスク・ディスパッチャコントローラが、前記調整した出力と前記コンテキストとを、前記他のコンピュータのコンテキスト・スタックに記憶させる請求項１に記載のコンピューティング・システム。
6. 前記ユーザからの入力に対して出力を判断するグローバル履歴もしくはメタ情報が、コンピュータのコンテキスト・スタックに記憶されていないと判断した場合に、前記対話マネージャが、前記一のコンピュータ以外の他のコンピュータの対話マネージャと通信を行う際に、前記対話マネージャは、会話型ディスカバリ・プロトコルを使用して、通信すべき他のコンピュータを決定して通信を行う請求項１に記載のコンピューティング・システム。
7. 前記タスク・ディスパッチャコントローラが、前記コンテキストに対応する出力に優先順位をつけてコンテキスト・スタックに供給することで、前記対話マネージャが、出力するときに、この優先順位に基づいて出力を決定する請求項１または請求項５に記載のコンピューティング・システム。
8. メタ情報としてセキュリティ情報を含み、前記対話マネージャが、前記メタ情報のセキュリティ情報を使用して、ユーザにファイルのアクセスを制限する請求項１に記載のコンピューティング・システム。
9. 前記対話マネージャは、ユーザ・コマンド照会が完全か曖昧かを判断し、不完全または曖昧である場合には、再度、ユーザに入力の内容を更新させる処理を行う請求項１に記載のコンピューティング・システム。
10. 前記対話マネージャは、ユーザ・コマンド照会が完全か曖昧かを判断し、完全で曖昧さのない場合にでも、ユーザ選好／設定値に基づいて、実行前にユーザに確認させる処理を行う請求項１に記載のコンピューティング・システム。

Images