(57)【要約】【課題】入力モードバイアスを適用するための方法およびシステムを提供する。【解決手段】スキーマが電子ドキュメントの入力フィールドに適用される。スキーマは、入力フィールドに入力することができる受け入れ可能なストリングのセットを定義する文法に関連付けられる。テキストが入力フィールドに入力されたとき、スキーマが決定され、関連付けられた文法が決定される。次いで、文法が入力方式に送られる。文法に基づいて、入力方式は、何のテキストをユーザが入力しようと試みているかを決定することができる。文法を使用して、意味カテゴリを、ドキュメントに入力されたテキストに適用することもできる。テキストが入力された後、これが文法と比較される。入力されたテキストが文法のフォームに合致した場合、スキーマがテキストに、意味カテゴリとして適用される。【選択図】図３
2006276867.tif 000002
【特許請求の範囲】
【請求項１】
モードバイアスをアプリケーションの電子ドキュメントの入力フィールドに適用するためのコンピュータシステムであって、
前記アプリケーションと通信をする階層化ベースのスキーマレジストリと、
前記階層化ベースのスキーマレジストリと通信をする少なくとも１つの入力エンジンとを備え、前記階層化ベースのスキーマレジストリは、前記入力フィールドへの入力の階層的な解析に基づいたスキーマ名を前記アプリケーションから受け取り、前記スキーマ名に関連付けられた文法を見つけ、前記文法を前記入力エンジンに送り、前記モードバイアスを介して入力を制限するためのカテゴリの固定されたリストを除いた１つ以上のカスタムモードバイアス設定を、前記入力フィールドに対して定義することができることを特徴とするシステム。
【請求項２】
請求項１に記載のシステムであって、前記入力エンジンが音声認識エンジンであることを特徴とするシステム。
【請求項３】
請求項１に記載のシステムであって、前記入力エンジンが手書き認識エンジンであることを特徴とするシステム。
【請求項４】
請求項１に記載のシステムであって、前記入力エンジンが入力方式エディタ（ＩＭＥ）であることを特徴とするシステム。
【請求項５】
請求項１に記載のシステムであって、前記入力エンジンが携帯電話のキーパッドであることを特徴とするシステム。
【請求項６】
請求項１に記載のシステムであって、前記入力エンジンがジェスチャーベースの入力方式であることを特徴とするシステム。
【請求項７】
請求項１に記載のシステムであって、前記入力エンジンが手話認識エンジンであることを特徴とするシステム。
【請求項８】
請求項１に記載のシステムであって、前記入力エンジンは複数の入力エンジンからなり、前記階層化ベースのスキーマレジストリはスキーマデータベースおよび文法データベースに接続されたスキーマレジストリマネージャを備え、前記スキーマデータベースは複数のスキーマ名並びに前記複数のスキーマ名に関連付けられた文法への複数のポインタを備え、前記ポインタは複数の文法を備えた前記文法データベースをポイントし、前記スキーマデータベースおよび前記文法データベースは前記複数の入力エンジンによっては制御されないことによって、前記複数の入力エンジンによって使用される相異なる入力方法に渡って一貫して前記モードバイアスを適用する前記スキーマ名に関連付けられた前記文法の同一のバージョンを、各々の入力エンジンが受け取ることを保証されていることを特徴とするシステム。
【請求項９】
請求項１に記載のシステムであって、前記文法が文脈自由文法であることを特徴とするシステム。
【請求項１０】
請求項１に記載のシステムであって、前記文法が文脈依存文法であることを特徴とするシステム。
【請求項１１】
請求項１に記載のシステムであって、前記文法が正規表現であることを特徴とするシステム。
【請求項１２】
請求項１に記載のシステムであって、前記文法が統計的言語モデルであることを特徴とするシステム。
【請求項１３】
請求項１に記載のシステムであって、前記文法が、前記入力フィールドのための適切な入力を定義することを特徴とするシステム。
【請求項１４】
請求項１３に記載のシステムであって、前記文法が、前記入力フィールドのための適切な入力を、前記入力フィールドのための受け入れ可能な入力のリストを定義することによって、定義することを特徴とするシステム。
【請求項１５】
請求項１に記載のシステムであって、前記入力エンジンが前記文法を使用して、前記アプリケーションのユーザから入力を受け取ることを特徴とするシステム。
【請求項１６】
請求項１５に記載のシステムであって、前記入力エンジンがさらに前記文法を使用して、前記ユーザの入力を、前記入力フィールドにとって正しい入力に導くことを特徴とするシステム。
【請求項１７】
請求項１５に記載のシステムであって、前記入力エンジンが前記ユーザの前記入力を前記文法と比較して、前記入力が適切な入力に合致し、かつ適切な入力であるかどうかを決定することを特徴とするシステム。
【請求項１８】
請求項１７に記載のシステムであって、前記入力エンジンが、前記ユーザの前記入力が適切な入力に合致しないと決定した場合、前記入力エンジンが前記入力を拒否し、前記アプリケーションに、エラーメッセージを前記ユーザに表示させることを特徴とするシステム。
【請求項１９】
請求項１に記載のシステムであって、前記階層化ベースのスキーマレジストリが前記アプリケーションと、テキストサービスフレームワークを介して通信をすることを特徴とするシステム。
【請求項２０】
モードバイアスをアプリケーションの電子ドキュメントの入力フィールドに適用するためのコンピュータシステムであって、
前記アプリケーションと通信をする階層化ベースのスキーマレジストリであって、前記階層化ベースのスキーマレジストリは動的に１つ以上の文法を生成することと、
前記階層化ベースのスキーマレジストリと通信をする入力エンジンとを備え、
前記階層化ベースのスキーマレジストリはスキーマ名を前記アプリケーションから受け取り、前記スキーマ名に関連付けられた文法の識別子を見つけ、前記文法の前記識別子を前記入力エンジンに送り、前記階層化ベースのスキーマレジストリは、前記スキーマ名、前記識別子、どの文法を使用するかをさらに定義をする１つ以上の定義プロパティ、並びに前記スキーマ名および前記文法が意味カテゴリ認識に使用されるかどうかを示す意味カテゴリ設定を含むことを特徴とするシステム。
【請求項２１】
モードバイアスをアプリケーションプログラムモジュールの電子ドキュメントの入力フィールドに適用するためのコンピュータにより実施される方法であって、
挿入ポイントが前記入力フィールド内にあることを決定するステップと、
前記入力フィールドに付加されるモードバイアススキーマを決定するステップと、
前記入力フィールドと階層化ベースのスキーマレジストリとに基づいて１つ以上の文法を動的に生成するステップと、
前記モードバイアススキーマに関連付けられる文法を決定するステップと、
前記文法を入力エンジンに送るステップであって、前記入力エンジンが前記文法を使用して、前記入力フィールドのための入力を受け取ることと、を備え、
前記モードバイアスは、入力を制限するためのカテゴリの固定されたリストを除いた、前記入力フィールドに対して定義されたカスタムモードバイアスを含むことを特徴とする方法。
【請求項２２】
請求項２１に記載の方法であって、前記入力エンジンが前記文法を使用して、前記入力フィールドのための入力を受け取るステップが、テキストを前記挿入ポイントで受け取るステップと、前記受け取られたテキストが、前記文法によって定義された入力タイプと合致するかどうかを決定するステップと、合致する場合に、前記テキストを前記入力フィールドに表示するステップとを備えることを特徴とする方法。
【請求項２３】
請求項２２に記載の方法であって、
前記挿入ポイントで受け取られた前記テキストが、前記文法によって定義された前記入力タイプと合致しない場合に、エラーメッセージを表示するステップをさらに備えることを特徴とする方法。
【請求項２４】
請求項２１に記載の方法であって、前記モードバイアススキーマに関連付けられる文法を決定するステップが、
スキーマデータベースにおける前記モードバイアススキーマを相互参照して、前記モードバイアススキーマに関連付けられる前記文法を決定するステップを備えることを特徴とする方法。
【請求項２５】
請求項２４に記載の方法であって、前記文法を入力エンジンに送るステップが、前記文法を文法データベースから検索するステップと、前記文法を前記入力エンジンに送るステップとを備えることを特徴とする方法。
【請求項２６】
実行されたときに、請求項２５に記載の方法を実施するコンピュータ可読命令が格納されたコンピュータ可読媒体。
【請求項２７】
電子ドキュメントにおけるストリングの意味カテゴリを、モードバイアススキーマに基づいて決定するためのコンピュータにより実施される方法であって、
前記電子ドキュメントの中の入力ストリングを受信するステップと、
前記入力ストリングに基づいた１つ以上の文法を動的に生成するステップと、
モードバイアススキーマおよび関連付けられた文法を検索するステップであって、前記モードバイアススキーマは階層化ベースのスキーマレジストリと関連付けられていることと、
前記入力ストリングが、前記文法によって定義された前記入力の定義に準拠するかどうかを決定するステップと、
準拠する場合に、前記モードバイアススキーマを、前記ドキュメント内の前記入力ストリングに関連付けるステップと、
前記モードバイアススキーマを、前記入力ストリングと関連付けて意味カテゴリラベルとして保存するステップと、
前記意味カテゴリラベルに基づいて、前記意味カテゴリに関連付けられたアクションの選択を提供し、または、前記意味カテゴリに関連付けられたダウンロードＵＲＬおよびダウンロードアクションプラグインを使用するオプションを提供するステップと、
を備えることを特徴とする方法。
【請求項２８】
請求項２７に記載の方法であって、前記意味カテゴリラベルとの関連付けにおいて、複数のアクションを表示するステップをさらに備えることを特徴とする方法。
【請求項２９】
請求項２７に記載の方法であって、前記モードバイアススキーマおよび前記関連付けられた文法が、スキーマレジストリから検索されることを特徴とする方法。
【請求項３０】
請求項２７に記載の方法であって、前記モードバイアススキーマがＸＭＬスキーマを備えることを特徴とする方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は一般にソフトウェアプログラムモジュールに関し、より詳細には、文法を使用して入力モードバイアスを、フィールドを含む電子ドキュメントの部分に適用すること、および同じ文法を使用して意味カテゴリをドキュメントにおけるストリングに適用することに関する。
【背景技術】
【０００２】
コンピュータソフトウェアは、ほんの少し例を挙げれば、音声認識、手書き認識、東アジア入力方式エディタなど、多数の様々な入力方式から入力を受け取るために、ますます利用しやすくなりつつある。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかしながら、これらの確率的入力方式は時として、決して信頼できるものではないことがある。たとえば、音声認識ソフトウェアが、特定のフィールド内で必要とされる特定のタイプの入力に気づかない場合、ユーザが言おうとしていることが何であるかを理解することが困難となる可能性がある。たとえば、音声認識ソフトウェアが、必要とされる特定のタイプの入力に気づかないために、電話番号を入力することが困難となる可能性がある。
【０００４】
テキスト入力コントロールの作者がプロパティをフィールドに設定し、それによって入力方式エディタ（ＩＭＥ：ｉｎｐｕｔ  ｍｅｔｈｏｄ  ｅｄｉｔｏｒ）がビットを認識し、入力方式エディタが使用する言語モデルを調整するようにすることができるように、入力を制約する解決策が開発されてきた。フィールドの入力の制約、ドキュメントの一部またはすべての入力の制約などは、モードバイアス（ｍｏｄｅ  ｂｉａｓ）と呼ばれることがある。しかし、これらの解決策にはいくつかの欠点がある。これらの解決策は、ビットによって示される可能性のあるカテゴリの固定されたリストに制限される。したがって、入力を制約する方法の柔軟性のないハードコーディングされたリストがある。開発者は、カテゴリの固定リストから選択しなければならず、有用である可能性のある新しいモードバイアス設定を定義することはできない。
【０００５】
カテゴリの固定リストを使用する現在の解決策におけるもう１つの問題は、これらのカテゴリに対する応答が、異なる入力方式の間で一貫していないことである。ユーザは、同じ入力フィールドに対しては、異なる入力方式が類似の方法で反応することを期待する。しかし、従来技術の解決策では、入力方式に対して、テキスト入力コントロールの特定のカテゴリに対してそれら独自の応答を定義させる。たとえば、音声レコグナイザおよび手書きレコグナイザは、電話番号をまったく異なる方法によって処理する可能性がある。
【０００６】
したがって、開発者が、何の入力フォームが特定のフィールドについて受け入れ可能であるかを定義することを可能にすることにおいて柔軟性のある、モードバイアスを提供するための方法の必要性がある。さらに、異なる入力方式に渡って一貫性のあるモードバイアスを提供するための方法の必要性がある。
【課題を解決するための手段】
【０００７】
本発明は、入力モードバイアスを電子ドキュメントの入力フィールド（および他の領域）に適用するための方法およびシステムを提供することによって、上述の必要性を満たす。スキーマが電子ドキュメントの入力フィールドに適用され、スキーマは、入力フィールドに入力することができる受け入れ可能なストリングのセットを定義する文法に関連付けられる。テキストが入力フィールドに入力されたとき、スキーマが決定され、関連付けられた文法が決定される。次いで、文法が入力方式に送られる。文法に基づいて、入力方式は、何のテキストをユーザが入力しようと試みているかを決定することができる。文法を使用して、意味カテゴリを、ドキュメントに入力されたテキストに適用することもできる。テキストが入力された後、これが文法と比較される。入力されたテキストが文法のフォームに合致した場合、スキーマがテキストに意味カテゴリとして適用される。
【０００８】
典型的には、スキーマ名がスキーマデータベースに格納され、文法が文法データベースに格納される。スキーマ名を、ロケールおよび言語などの他のプロパティ、および関連付けられた文法へのポインタと共に格納することもできる。したがって、ユーザが挿入ポイントを、モードバイアスが適用された入力フィールドに配置したとき、適切な文法のルックアップのために、スキーマ名および他のプロパティがスキーマデータベースへ送られる。このスキーマ名（および他のプロパティ）に基づいて、文法（または文法へのポインタ）が入力方式に送られる。次いで、入力方式がこの文法を使用して、ユーザが何を入力フィールドに入力しようと試みているかを決定する。入力方式は、ユーザが、この文法に準拠していないテキストを入力しようと試みた場合、提案またはエラーメッセージを提供することもできる。
【０００９】
スキーマデータベースおよび文法データベースは入力方式のコントロールの外部にあるので、本発明は、入力方式がモードバイアスを異なる方法で処理する従来技術の問題を改善する。本発明を使用すると、各入力方式が同じ文法を受け取り、入力方式が音声認識エンジンであるか、手書き認識エンジンなどであるかにかかわらず、類似の方法でこれを処理するべきである。本発明はまた柔軟性をも持っている。これは、新しいスキーマおよび文法が、システムアドミニストレータによって定義され実装され得るので、組織内で必要とされる可能性のあるカスタムモードバイアスを提供することができるからである。モードバイアスの提供に加えて、文法を使用して、ドキュメントにおける意味カテゴリを認識することができる。
【００１０】
本発明が従来技術の欠点に関して向上させるものであり、上述の利点を実現することは、以下の例示的実施形態の詳細な説明、および、付属の図面および特許請求の範囲から明らかになるであろう。
【発明の効果】
【００１１】
本発明により、入力モードバイアスを適用するための方法およびシステムを提供することができる。
【発明を実施するための最良の形態】
【００１２】
本発明は、入力モードバイアスを適用するための方法およびシステムを対象とする。スキーマが電子ドキュメントの入力フィールドに適用される。スキーマは、入力フィールドに入力されるべき入力のタイプの名前である。一実施形態として、スキーマを電話番号スキーマにすることができる。スキーマに関連付けられるものは、入力フィールドに入力することができる受け入れ可能なストリングのセットを定義する文法である。たとえば、電話番号スキーマに関連付けられた文法は、入力を、フォーム（ＸＸＸ）ＸＸＸ−ＸＸＸＸであるものとして定義することができる。ただしＸは０〜９の数字を表す。
【００１３】
簡単に本発明の一実施形態を記載したが、本発明のための例示的オペレーティング環境を以下に記載する。
【００１４】
（例示的オペレーティング環境）
このとき図面を参照して、本発明の態様および例示的オペレーティング環境を記載し、図面においてはいくつかの図面全体で同様の数字が同様の要素を表す。
【００１５】
図１および以下の考察は、本発明を実施することができる適切なコンピューティング環境の、簡単で一般的な記載を提供することを意図するものである。本発明を一般に、パーソナルコンピュータと共にオペレーティングシステム上で動作するアプリケーションプログラムに関連して記載するが、本発明を、他のプログラムモジュールとの組み合わせにおいても実施できることは、当業者には理解されよう。一般に、プログラムモジュールには、ルーチン、プログラム、コンポーネント、データ構造などが含まれ、これらは特定のタスクを実行するか、あるいは特定の抽象データタイプを実施する。さらに、本発明を他のコンピュータシステム構成により実施できることは、当業者には理解されよう。これには、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサベースまたはプログラマブルな家庭用電化製品、ミニコンピュータ、メインフレームコンピュータなどが含まれる。本発明はまた、分散コンピューティング環境においても実施することができ、ここではタスクが、通信ネットワークを介してリンクされるリモート処理デバイスによって実行される。分散コンピューティング環境では、プログラムモジュールが、ローカルおよびリモート記憶デバイスに位置することができる。
【００１６】
図１を参照すると、本発明を実施するための例示的システムは従来のパーソナルコンピュータ２０を含み、これは、処理装置２１、システムメモリ２２およびシステムバス２３を含み、システムバス２３はシステムメモリを処理装置２１に結合する。システムメモリ２２は、読み取り専用メモリ（ＲＯＭ）２４およびランダムアクセスメモリ（ＲＡＭ）２５を含む。基本入出力システム２６（ＢＩＯＳ）は、起動中など、情報をパーソナルコンピュータ２０内の要素の間で転送するための助けとなる基本ルーチンを含み、ＲＯＭ２４に格納される。パーソナルコンピュータ２０はさらに、ハードディスクドライブ２７、たとえば取外し可能ディスク２９から読み取りあるいはこれに書き込むための磁気ディスクドライブ２８、および、たとえばＣＤ−ＲＯＭディスク３１を読み取るため、あるいは他の光媒体から読み取りあるいはこれに書き込むための光ディスクドライブ３０を含む。ハードディスクドライブ２７、磁気ディスクドライブ２８および光ディスクドライブ３０はシステムバス２３へ、それぞれハードディスクドライブインターフェイス３２、磁気ディスクドライブインターフェイス３３および光ドライブインターフェイス３４によって接続される。ドライブおよびそれらの関連付けられたコンピュータ可読媒体は、パーソナルコンピュータ２０のための不揮発性記憶装置を提供する。上のコンピュータ可読媒体の記載は、ハードディスク、取外し可能磁気ディスクおよびＣＤ−ＲＯＭディスクに言及するが、磁気カセット、フラッシュメモリカード、デジタルビデオディスク、ベルヌーイカートリッジなど、コンピュータによって可読である他のタイプの媒体も、例示的オペレーティング環境において使用できることを、当業者には理解されたい。
【００１７】
いくつかのプログラムモジュールをドライブおよびＲＡＭ２５に格納することができ、これにはオペレーティングシステム３５、１つまたは複数のアプリケーションプログラム３６、ワードプロセッサプログラムモジュール３７（または他のタイプのプログラムモジュール）、プログラムデータ３８および他のプログラムモジュール（図示せず）が含まれる。
【００１８】
ユーザが、コマンドおよび情報をパーソナルコンピュータ２０へ、キーボード４０、および、マウス４２などのポインティングデバイスを介して入力することができる。他の入力デバイス（図示せず）には、マイクロフォン、ジョイスティック、ゲームパッド、衛星放送受信アンテナ、スキャナ、スタイラスなどが含まれる可能性がある。これらおよび他の入力デバイスがしばしば処理装置２１へ、システムバスに結合されるシリアルポートインターフェイス４６を介して接続されるが、これを、ゲームポートまたはユニバーサルシリアルバス（ＵＳＢ）など、他のインターフェイスによって接続することができる。モニタ４７または他のタイプの表示デバイスもシステムバス２３へ、ビデオアダプタ４８などのインターフェイスを介して接続される。モニタに加えて、パーソナルコンピュータは通常、スピーカまたはプリンタなど、他の周辺出力デバイス（図示せず）を含む。
【００１９】
パーソナルコンピュータ２０は、ネットワーク環境において、リモートコンピュータ４９など、１つまたは複数のリモートコンピュータへの論理接続を使用して動作することができる。リモートコンピュータ４９は、サーバ、ルータ、ピアデバイス、または他の共通ネットワークノードにすることができ、通常は、パーソナルコンピュータ２０に関して記載した要素の多数またはすべてを含むが、記憶デバイス５０のみを図１に例示した。図１に示す論理接続は、ローカルエリアネットワーク（ＬＡＮ）５１および広域ネットワーク（ＷＡＮ）５２を含む。このようなネットワーキング環境は、オフィス、企業全体のコンピュータネットワーク、イントラネットおよびインターネットにおいて一般的である。
【００２０】
ＬＡＮネットワーキング環境において使用するとき、パーソナルコンピュータ２０がＬＡＮ５１へ、ネットワークインターフェイス５３を介して接続される。ＷＡＮネットワーキング環境において使用するとき、パーソナルコンピュータ２０が通常はモデム５４、または、インターネットなどのＷＡＮ５２を介して通信を確立するための他の手段を含む。モデム５４は、内部あるいは外部にすることができ、システムバス２３へ、シリアルポートインターフェイス４６を介して接続される。ネットワーク環境では、パーソナルコンピュータ２０に関して示したプログラムモジュール、またはその一部を、リモート記憶デバイスに格納することができる。図示のネットワーク接続は例示的なものであり、通信リンクをコンピュータの間で確立する他の方法を使用できることは理解されよう。
【００２１】
（入力モードバイアスの適用）
確率的入力方式は現在、以前よりもより頻繁に使用されている。かねてより、確率的入力メカニズムが東アジアにおいて、入力方式エディタ（ＩＭＥ）の形で使用されてきた。最近は、音声および手書き入力メカニズムがより一般的になってきている。ユーザが容易に、自分が選択するものを入力することができるタイピング（東アジアの外部）とは異なり、確率的入力方式はそれらの特性により、ユーザがより一般的な語およびフレーズを入力しようと試みていることを前提とする。通常、ユーザが一般的で普通の語およびフレーズを入力しようとしている時は、この前提がうまく機能する。しかし、これにより、あるタイプのより一般的でないテキストを入力することが困難となる可能性がある。これは特に、何の種類の情報が入力されるべきであるかについて課せられた制約があり、かつ入力メカニズムがこれらの制約を厳守しないフォームに、テキストを入力するときにフラストレーションを引き起こす可能性がある。たとえば、数字以外のものを、連絡先管理ソフトウェアにおける電話番号フィールドに入力することはほとんど意味を成さない。しかしながら、音声および手書きレコグナイザはめったにこの種類の制約を認識していない。一実施形態では、本発明は、入力コントロールのモードバイアスまたは入力フィールドをコントロールするためのメカニズムに伴うこの問題を解決する。
【００２２】
一実施形態では、本発明を使用して、入力コントロールに関連付けられたＸＭＬスキーマを定義することができる。スキーマを、文法に関連付けることができる。文法は、入力コントロールに対する適切な入力（たとえば、受け入れ可能なストリング）の定義である。一実施形態では、文法を文脈自由文法、統計的言語モデル、可能な入力のリストなどにすることができる。
【００２３】
文法を使用して、ユーザの入力を、ユーザが入力フィールドを適切に入力するように制約する。たとえば、入力コントロールは、＜ｓｃｈｅｍａｓ−ｍｉｃｒｏｓｏｆｔ−ｃｏｍ＃ｐａｒｔｎｕｍｂｅｒ＞をそのコントロールに付加する（ａｔｔａｃｈ）ことによって、部品番号を受け入れるということを指定することができる。スキーマｍｉｃｒｏｓｏｆｔ−ｃｏｍ＃ｐａｒｔｎｕｍｂｅｒを、この特定の種類の部品番号が０から９の数字とその後に続くａ〜ｚの文字を含むことを指定する文法に、関連付けることができる。上に記載した実施形態では、文法を使用して、ユーザの入力を部品番号のフォームに合致するように制約する。ユーザが部品番号以外のものを入力した場合、エラーメッセージまたは提案をユーザに提示することができる。
【００２４】
他の実施形態では、文法を、異なる入力方式によって使用して、ユーザの入力を正しく識別することができる。たとえば、音声認識エンジンのユーザは「ｆｏｕｒ（４）」と言う場合がある。本発明を使用すると、音声認識入力方式エディタは、ユーザが「ｆｏｕｒ」を意味したか、「ｆｏｒ」を意味したかを決定することができる。ユーザが、電話番号スキーマが付加されそして数字を受け入れる文法によって定義された入力フィールドに、テキストを入力中であった場合、ユーザは「ｆｏｕｒ」という語を意味した可能性が高い。したがって、音声認識入力方式エディタは、これが数字の「４」を入力フィールドに入力するべきであると認識する。
【００２５】
図２は、本発明の一実施形態による、モードバイアスを実施するためのアーキテクチャ５００を例示する。アプリケーション３７などのアプリケーションが、テキストサービスフレームワーク５０５に接続される。テキストサービスフレームにより、確率的入力ソースからの入力が可能となる。テキストサービスフレームワークは、アプリケーションプログラミングインターフェイス（ＡＰＩ）セットであり、これにより入力ソースはアプリケーションと通信することができる。テキストサービスフレームワークは、ＩＭＭ３２（ＷＩＮＤＯＷＳ（登録商標）オペレーティングシステム用の東アジア入力方式ＡＰＩ）およびＡＩＭＭ（アクティブ入力方式マネージャ）の後継である。テキストサービスフレームワークは、ＩＭＭ３２およびＡＩＭＭに勝る多数の利点を備える。これらは、文脈へのより幅広いアクセス、任意のプロパティをテキストに関連付ける能力などである。テキストサービスフレームワークが本発明の一実施形態において使用されるが、他の実施形態において、本発明は、アプリケーションを異なる入力方式に接続するための他のツールを含むことができることを理解されたい。
【００２６】
アプリケーション３７は任意選択的に意味カテゴリをサポートすることができる。これについては以下に説明する。音声認識エンジン５２５、手書き認識エンジン５３０、入力方式エディタ５３５および他の確率的入力メカニズム５４０（たとえば、手話認識）など、入力方式により、ユーザがテキストをアプリケーション３７のドキュメントに、テキストサービスフレームワーク５０５を介して入力することができる。ユーザの動きまたはジェスチャーに基づいて入力を決定するジェスチャーベースの認識エンジンなど、他の入力メカニズムを使用することができる。携帯電話または携帯情報端末（ＰＤＡ）のキーパッドなどの入力方式も使用することができる。
【００２７】
テキストサービスフレームワーク５０５および異なる入力方式は、スキーマレジストリに接続される。好ましい実施形態では、スキーマレジストリはスキーマレジストリマネージャ５１０を含み、これは文法データベース５１５およびスキーマデータベース５２０に接続される。
【００２８】
好ましい実施形態では、スキーマデータベースは、モードバイアスをコントロールするために使用された複数のＸＭＬスキーマを含む。ＸＭＬスキーマを使用することが好ましく、これは、それらが汎用的でありかつ柔軟性があり、すでに意味カテゴリ情報のために使用されているからである（意味カテゴリについては後に説明する）。本発明を拡張するために必要とされるように、新しいタイプのデータ（たとえば、標準化された構文に準拠する大規模な組織内の部品番号）に合わせて、ＸＭＬスキーマをカスタマイズすることもできる。新しいスキーマを、いくつかの入力について定義する必要があるが、意味カテゴリにおいて使用された標準スキーマを、本発明においてスキーマとして再利用することができる。
【００２９】
標準の幅広く適用可能な入力コントロールのタイプ（電話番号など）に対して、および、組織内において標準的なものである入力コントロールのタイプ（部品番号など）に対して、文法を再利用する能力を最大にする。このために、本発明の好ましい実施形態では、スキーマは文法を直接参照するか、あるいは、スキーマは特定の文法に関連付けられたスキーマレジストリを介して、文法へマップする。たとえば、スキーマ名を、スキーマデータベース５２０において、スキーマ名についての関連付けられた文法とともに参照することができる。文法自体を文法データベース５１５に格納することができる。この間接マッピング手法の１つの利点は、これにより追加的な抽象化（ａｂｓｔｒａｃｔｉｏｎ）が、たとえば、言語または地域に渡って可能となることである。たとえば、それぞれのユーザロケール用の異なる電話フォーマットに対する文法を構築する必要なしに、フィールドが電話番号を受け入れるということを指定することができる。スキーマレジストリマネージャ５１０は、スキーマデータベース５２０および文法データベース５１５をコントロールする。もちろん、他のアーキテクチャは当業者には明らかであろうし、これらを、本発明から逸脱することなく実施することができる。 
【００３０】
他の実施形態では、ＸＭＬスキーマは直接文法を符号化することができるが、これにより文法の共有がより困難となってしまう。たとえば、直接文法を符号化するために、ＸＭＬスキーマは文法をＸＭＬタグの形式で含むことができ、これは受け入れ可能な入力のリストまたはフォームを記述したものである（ｎｕｍｂｅｒｓ．ｘｍｌなど、文法ファイルをポイントするのではない）。
【００３１】
スキーマレジストリシステムを持つことは有益である。それにより、独立ソフトウェアベンダおよび高度のユーザが、容易に既存のスキーマを修正することができるからである。あるいは、これらベンダやユーザ自身のスキーマを定義し、入力方式によりアプリケーション内において、意味カテゴリ認識のために即座に、これらを使用することができるからである。すなわち、この新しいスキーマについて精通したアプリケーションまたは入力方式の次のバージョンを持っていることなく、即座に使用することができるからである。たとえば、組織内の開発者は、確率的入力方式の使用時に、あるタイプの入力を入力する場合に（例えば、その組織に固有の部品番号の入力時など）大変な苦労をしていることに気づくことがある。このとき、開発者は、部品番号を記述するための新しいスキーマ、およびこれらの部品番号を認識するための文法を作成することができる。次いで、開発者は、それらのアプリケーションおよびそれらのｗｅｂページにおけるフォームフィールドにこのスキーマを付加する（ａｔｔａｃｈ）することができる。エンドユーザも、自らがこの新しいスキーマにより作成したフォームにおけるフィールドに注釈を付けることによって、これを行うことができる。
【００３２】
スキーマレジストリは、以下の表１における最初の２列のような入力を含むことができる。３番目の列は、文法が何を行うように意味されているのかを説明している。いくつかの場合、ユーザのコンピュータ、エクスチェンジサーバなどのコンテンツに基づいて、文法を動的に構築することができる。したがって、本発明が、特定のパターンを厳守するように入力方式を制約する１つの方法は、入力方式が使用するべき文法を指定することである。すなわち、本発明は、入力方式が使用するべき正規表現（ｒｅｇｕｌａｒ  ｅｘｐｒｅｓｓｉｏｎ）、文脈自由文法（ＣＦＧ）または統計的言語モデルを指定する。表１は例示的なものでしかなく、本発明において使用することができるスキーマの数またはタイプを限定しないことを理解されたい。
【００３３】
【表１】
2006276867.tif 000003
【００３４】
したがって、一実施形態では、スキーマレジストリは、ＸＭＬスキーマ名（ネームスペースおよびタグを含む）、およびＸＭＬスキーマ名に関連付けられた文法を含む。スキーマレジストリは、どの文法を使用するべきであるかを決定するために必要である他の定義特性（ｐｒｏｐｅｒｔｉｅｓ）も含むことができる。言語設定およびロケール設定をスキーマレジストリにおいて使用して、さらにどの文法を使用するかを定義することができる。たとえば、アドレススキーマを、いくつかの異なる文法に関連付けることができる。入力方式に送られるべきである文法を、コンピュータ（またはオペレーティングシステム、アプリケーションなど）の言語およびロケールを見ること、および次いでデータベースルックアップをスキーマレジストリにおいて実行して、適切な文法を見つけることによって決定することができる。スキーマレジストリは、意味カテゴリ設定も含んで、特定のスキーマ名および文法が意味カテゴリ認識（以下にさらに説明する）のために使用されるべきであるかどうかを表示することもできる。
【００３５】
スキーマレジストリを階層的にすることができる。すなわち、いくつかの階層スキーマを、入力コントロールに関連付けることができる。たとえば、連絡先フォルダにおけるものなど、特定の名前の探索は、いくつかの場合に有用である。しかし、他の名前を除外することは、あまりにも極端で行き過ぎとなる場合もある。結果として、入力フィールドについては、連絡先フォルダ内の名前に偏った（ｂｉａｓｅｄ）入力を期待しているが、他の名前を入力することもできると言うのが最も良い説明だろう。スキーマを階層的に編成することにより、これに対処することができる。たとえば、Ｐｅｒｓｏｎｎａｍｅスキーマを、名前階層の最上部に置くことができ、連絡先スキーマおよび社内従業員スキーマを階層的にＰｅｒｓｏｎｎａｍｅスキーマの下に置くことができる。大規模な組織は、社内従業員スキーマを定義して、フォームフィールドへの従業員名の入力をより容易にすることができる。したがって、この実施形態においては、フィールドがＰｅｒｓｏｎｎａｍｅスキーマを要求するときは、連絡先スキーマおよび社内従業員スキーマを、他の人の名前を探索する前に探索することができる。言い換えれば、各スキーマが文法を入力方式に返すことができ、入力方式は最も特有のスキーマを選ぶことができ、あるいはそうでない場合はスキーマを結合することができるという点において、スキーマは階層的であると言うことができる。
【００３６】
ユーザは、ユーザのマシンが知っていないスキーマを求めたフォームに入力をしようと試みる場合もある。これらの場合では、本発明の一実施形態は、好ましいスキーマの順序付きのシーケンスを指定することができる。最適なスキーマが、それがレジストリにあった場合、あるいはちょうどよいときにそれをダウンロードすることができた場合は、その最適なスキーマが使用される。しかし、それが使用可能でなかった場合、入力方式が２番目に好ましいスキーマに戻るなどとすることができる。たとえば、ユーザが、Ｍｉｃｒｏｓｏｆｔ部品番号というタイプを要求するフォームに入力しようと試みることがあるが、ユーザはそのタイプのスキーマ（および／またはそのスキーマに関連付けられた文法）を自分のマシン上に有していない場合がある。その時に任意の入力を可能にするよりもはるかに良いのは、任意の入力とするのではなく、好ましい語に傾かせることができる文字および数字のシーケンスに戻ることである（大抵の音声エンジンの場合のように）。
【００３７】
本発明を実施するためのアーキテクチャを簡単に記載したが、本発明の一実施形態による、モードバイアスをテキストに適用するための方法６００を例示する流れ図を、図３を参照して記載する。方法６００は、テンプレート（またはフォーム）の作者またはアプリケーションの作成者がモードバイアスをテキストまたはフィールドの領域に付加した後、アプリケーションにおいて起こることを理解されたい。「ＶＩＳＵＡＬ  ＳＴＵＤＩＯ」アプリケーションなどのツールまたは別の類似のツールを将来において供給して、作者がこのようなモードバイアスを適用できるようにすることができる。
【００３８】
ステップ６０５で、挿入ポイント（ＩＰ）が、電子ドキュメントの、モードバイアスが付加された領域（ＸＭＬスキーマが付加されたものなど）に配置される。ステップ６１０で、ユーザが使用中である入力方式は、アプリケーション３７からオペレーティングシステムを介して、モードバイアス（スキーマ）のランク付きリスト（たとえば、最高のスキーマ＝Ｍｉｃｒｏｓｏｆｔ  ｅｍｐｌｏｙｅｅ、２番目に最高＝ｐｅｒｓｏｎ  ｎａｍｅ）を検索する。ステップ６１５で、入力方式（またはオペレーティングシステム）はスキーマレジストリを呼び出し、もっとも高くランク付けされたスキーマに関連付けられた文法を検索する。別法として、入力方式（またはオペレーティングシステム）がスキーマレジストリを呼び出し、挿入ポイント領域に関連付けられたスキーマのすべてに関連付けられた文法のすべてを検索する。
【００３９】
ステップ６２０で、ユーザは入力方式を使用してテキストを入力し、入力方式が、レジストリからのその文法を使用して、テキストを認識する。入力方式が文法を使用して何をユーザが入力中であるのかを決定しながら、テキストはアプリケーションに挿入される。スキーマまたは一連のスキーマもドキュメントに、テキストと共に挿入することができる。ドキュメントが保存されるとき、テキストも保存され、いくつかの場合では、そのテキストに適用されたスキーマも保存される。
【００４０】
アプリケーションによって管理されたドキュメントが、特定のフィールド（またはドキュメント内の領域）上に設定されたモードバイアスを有する場合、その情報が入力方式に搬送されることを、前述の記載から理解されたい。好ましい実施形態では、情報がアプリケーションから、テキストサービスフレームワークを介して搬送される。しかし、このモードバイアス情報を入力方式に搬送する他の方法を、本発明から逸脱することなく使用できることを理解されたい。情報を受け取った後、次いで、使用するために適切な文法を文法データベースにおいて識別するために、入力方式はスキーマレジストリマネージャとインターフェイスをとる。通常、モードバイアスをドキュメントにおいて適用するために使用されたＸＭＬタグに対する文法をスキーマレジストリマネージャが返すことを、入力方式は要求する。次いで、ユーザの入力を決定するのに使用するため、スキーマレジストリマネージャは、この文法（または、それへのポインタである可能性が高い）を入力方式へ渡す。
【００４１】
したがって、一実施形態では、本発明は、スキーマ（ＸＭＬタグ）を使用してモードバイアスを入力に適用するためのメカニズムを提供する。ユーザ入力中に使用するための文法を検索するために、確率的入力方式によって、スキーマタグが使用される。この文法は、あるフィールドに何を入力することができるかを定義する。たとえば、＜ｓｃｈｅｍａｓ−ｍｉｃｒｏｓｏｆｔ−ｃｏｍ＃ｐａｒｔｎｕｍｂｅｒ＞をコントロールに付加することによって、フォームが部品番号を受け入れることということを指定することができる。このスキーマを、この特定の種類の部品番号が０から９までの数字とその後に続くａ〜ｚの文字を含むことを指定する文法に関連付けることができる。この文法は、ユーザの入力を、その部品番号のフォームに合致するように制約する。入力方式は、その後、何をユーザが入力しようと試みているかを理解することができるようになり、ユーザが文法によって定義されたフォームに合致しない入力を入力しようと試みた場合、ヒント、例またはエラーメッセージを提供することができる。同じ文法を使用して、部品番号を認識し、＜ｓｃｈｅｍａｓ−ｍｉｃｒｏｓｏｆｔ−ｃｏｍ＃ｐａｒｔｎｕｍｂｅｒ＞意味カテゴリを、ユーザが編集する自由テキストに適用することもできる（これについては以下に説明する）。このスキーマ＜ｓｃｈｅｍａｓ−ｍｉｃｒｏｓｏｆｔ−ｃｏｍ＃ｐａｒｔｎｕｍｂｅｒ＞は、一つの実施形態でしかないことを理解されたい。スキーマを幅広く定義することができ、上の実施形態は、いかなる意味においてもスキーマを限定するように意味されるものではない。
【００４２】
本発明の一実施形態では、スキーマレジストリマネージャ自体が、文法を生成することを担うことができる。たとえば、スキーマは、文法を生成するためのコードをポイントすることができる。この実施形態は特に、会社の電子メールアドレスなど、動的なデータベースに依存する文法に対して有用である可能性がある。各ユーザのコンピュータを、電子メールアドレスへの改訂により更新しなければならないのではなく、アドミニストレータが、文法を生成するためのコードをポイントするようにスキーマを設定し、最新の電子メールアドレスを検索できるようにすることができる。
【００４３】
アプリケーションは、スキーマと共に、プロパティを提供することができる。プロパティを使用して、入力フィールドのための適切な入力を限定あるいはさらに定義することができる。たとえば、スキーマを電話番号にすることができ、そのプロパティは、（５５５）の市外局番で始まる電話番号でないというものである。スキーマレジストリマネージャは、このプロパティを解釈して文法を修正するか、あるいは、文法のどの選択が入力方式に送られるかを修正することができる。
【００４４】
上で、モードバイアスを入力フィールドに適用することに関して、ＸＭＬスキーマおよび文法の使用を説明した。ＸＭＬスキーマおよび文法が上述のように実施された後、これらを使用して意味カテゴリの認識を駆動することができ、これは、確率的入力方式によって入力中に使用されたのと同じ文法を、テキストが入力された後に使用して、意味カテゴリを識別することができるからである。
【００４５】
（文法を使用した意味カテゴリ認識）
意味カテゴリの認識のために、上でモードバイアスに関連して説明した文法のいくつかを使用することができる。好ましい実施形態では、意味カテゴリは、タイプラベル、ダウンロードＵＲＬ、およびドキュメントにおいて認識されたストリングに関連付けられたメタデータを含む。ストリングは、文字のシーケンスからなるデータ構造であり、通常は人が読むことができるテキストを表現する。ユーザがストリングをドキュメントに入力するとき、意味カテゴリが、このストリングに対してラベル付けされ得る。そして、この意味カテゴリに関連付けて、特定のアクションをユーザに提示することができる。たとえば、ユーザが本のタイトルをドキュメントに入力したとき、これに本としてラベルを付けることができる。そして、「本を購入する」など、あるアクションを、このラベリングに基づいてユーザに提示することができる。
【００４６】
文法を使用して意味カテゴリを認識することについての説明を続ける前に、意味カテゴリのより詳細な説明を以下に提供する。意味カテゴリはさらに、２０００年６月６日出願の「ＭＥＴＨＯＤ  ＡＮＤ  ＳＹＳＴＥＭ  ＦＯＲ  ＳＥＭＡＮＴＩＣＡＬＬＹ  ＬＡＢＥＬＩＮＧ  ＳＴＲＩＮＧＳ  ＡＮＤ  ＰＲＯＶＩＤＩＮＧ  ＡＣＴＩＯＮＳ  ＢＡＳＥＤ  ＯＮ  ＳＥＭＡＮＴＩＣＡＬＬＹ  ＬＡＢＥＬＥＤ  ＳＴＲＩＮＧＳ」という名称の米国特許出願第０９／５８８，４１１号において論じられており、これは本願の譲受人に譲渡され、参照により本明細書に組み込まれる。
【００４７】
意味カテゴリを実施するため、ストリングが認識され、タイプラベルにより注釈を付けられ、あるいはラベルが付けられる。ストリングがタイプラベルにより注釈を付けられた後、アプリケーションプログラムモジュールがタイプラベルおよび他のメタデータを使用して、ユーザにアクションの選択を提供することができる。ユーザのコンピュータが、このタイプラベルに関連付けられたアクションを有していなかった場合、ユーザに、このタイプラベル用のダウンロードユニフォームリソースロケータ（ＵＲＬ）およびダウンロードアクションプラグインを使用するためのオプションを提供することができる。
【００４８】
図４は、ドキュメントにおける意味カテゴリのラベリングに関連して使用するための、例示的アーキテクチャ２００を例示するブロック図である。このアーキテクチャは、プログラムモジュール３７（図１）など、アプリケーションプログラムモジュール２０５を含む。アプリケーションプログラムモジュール２０５は、レコグナイザダイナミックリンクライブラリ２１０（以下、レコグナイザＤＬＬ）およびアクションダイナミックリンクライブラリ２１５（以下、アクションＤＬＬ）と、ユーザが電子ドキュメントの作成、編集、閲覧などを行っているときに、通信することができる。レコグナイザＤＬＬ２１０は、いくつかのレコグナイザプラグイン２２０をコントロールする。アクションＤＬＬ２１５は、いくつかのアクションプラグイン２２５をコントロールする。アクションＤＬＬは、タイプ−アクションデータベース２３０もコントロールする。
【００４９】
レコグナイザＤＬＬ２１０は、アプリケーションプログラムモジュール２０５上で動作中の電子ドキュメントから個々のレコグナイザプラグイン２２０へ、ストリングを配布することを処理する。レコグナイザプラグイン２２０は、ワードプロセッシングドキュメント、表計算ドキュメント、ｗｅｂページなど、電子ドキュメントにおける特定のストリングを認識する。レコグナイザプラグイン２２０は、アプリケーションプログラムモジュール２０５と共にパッケージ化することができ、あるいはこれらをサードパーティによって、関心のある特定のストリングを認識するように記述することができる。典型的には、レコグナイザＤＬＬ２１０は、１つのパラグラフまたはセル値増分毎に、ストリングをレコグナイザプラグイン２２０へ渡す。好ましい実施形態では、アクションＤＬＬおよびレコグナイザＤＬＬが単一のＤＬＬに併合されることも理解されたい。
【００５０】
あるストリングを、意味情報を含むものとして認識することの一部として、レコグナイザプラグイン２２０は、どのストリングにラベルが付けられるべきであるか、およびどのようにそれらにラベルが付けられるかを決定する。これらの結果を様々なレコグナイザプラグイン２２０から受け取った後、レコグナイザＤＬＬ２１０は意味カテゴリをアプリケーションプログラムモジュールに送る。好ましい実施形態では、意味カテゴリは、認識されたストリング、タイプラベルおよびダウンロードＵＲＬを含む。意味カテゴリはまた、メタデータも含むことができる。レコグナイザプラグイン２２０はそれぞれ別々に動作し、レコグナイザＤＬＬ２１０は、異なるレコグナイザプラグインが異なる遅延を有して結果を返すことで生じる非同期性の処理を担う。
【００５１】
ストリングに、レコグナイザプラグイン２２０によってラベルが付けられ、そして意味カテゴリがアプリケーションプログラムモジュール２０５へ送られた後、アプリケーションプログラムモジュール２０５のユーザは、意味カテゴリのタイプラベルに関連付けられているアクションを実行することができるようになる。アクションＤＬＬ２１５は、アクションを実行するように動作されるアクションプラグイン２２５を管理する。レコグナイザプラグイン２２０と同様に、アクションプラグイン２２５は、アプリケーションプログラムモジュール２０５と共にパッケージ化することができ、あるいはサードパーティによって、サードパーティの関心のある特定のアクションを実行するように記述することができる。アクションプラグインは、ユーザに提示されるべき可能なアクションを、ストリングに関連付けられたタイプラベルに基づいて提供する。アクションＤＬＬ２１５は、何のタイプラベルを意味カテゴリが含むかを決定し、タイプ−アクションデータベース２３０におけるタイプラベルを、アクションのリストと共に相互参照して、何のアクションをユーザに提示するべきであるかを決定する。好ましい実施形態では、タイプ−アクションデータベースが使用されないことを理解されたい。その代わりに、アクションのリストが各タイプについて動的に生成され、これは、レジストリを見てどのアクションがインストールされているかを決定し、次いでアクションＤＬＬを照会してどのタイプをそれらが適用するかを決定することによって行われる。
【００５２】
ユーザがアクションを選択した後、アクションＤＬＬ２１５が適切なアクションプラグイン２２５を管理し、必要な情報をアクションプラグインとアプリケーションプログラムモジュール２０５の間で渡し、アクションプラグインが所望のアクションを実行できるようにする。通常、アプリケーションプログラムモジュールは、アクションＤＬＬにオートメーション要求を送り、ユーザが選択したアクションを呼び出す。
【００５３】
上述のように、認識されたストリング、タイプラベル、メタデータおよびダウンロードＵＲＬの組み合わせを、本明細書では意味カテゴリと称する。タイプラベルは意味情報ラベルである。意味カテゴリはメタデータも含むことができ、これらは意味カテゴリの隠しプロパティである。意味カテゴリの一実施形態は、定義を明らかにすることができる。ユーザが「Ｇｏｎｅ  Ｗｉｔｈ  ｔｈｅ  Ｗｉｎｄ（風と共に去りぬ）」というテキストを電子ドキュメントに入力すると仮定する。ストリング「Ｇｏｎｅ  Ｗｉｔｈ  ｔｈｅ  Ｗｉｎｄ」は、タイプラベル「Ｂｏｏｋ  Ｔｉｔｌｅ（本タイトル）」およびタイプラベル「Ｍｏｖｉｅ  Ｔｉｔｌｅ（映画タイトル）」の意味カテゴリとして識別することができる。加えて、ＩＳＢＮ番号などのメタデータを、レコグナイザプラグインによってアプリケーションプログラムモジュールへ、意味カテゴリの一部として返すことができる。ダウンロードＵＲＬに、タイプラベル「Ｂｏｏｋ  Ｔｉｔｌｅ」および「Ｍｏｖｉｅ  Ｔｉｔｌｅ」を提供することができ、これは、ユーザのマシンがこれらのタイプラベルのためのアクションプラグインを保存していない場合である。
【００５４】
たとえば、タイプラベル「Ｂｏｏｋ  Ｔｉｔｌｅ」のためのアクションを、オンライン小売業者からの「Ｂｕｙ  ｔｈｉｓ  Ｂｏｏｋ（この本を購入する）」にすることができる。ユーザが「Ｂｕｙ  ｔｈｉｓ  Ｂｏｏｋ」に対応するアクションプラグインＤＬＬ２２５を有していなかった場合、ダウンロードＵＲＬを使用して、ユーザのｗｅｂブラウザを、このアクションプラグインをダウンロードするために適切なｗｅｂサイトへナビゲートすることができる。本発明の他の実施では、多数のダウンロードＵＲＬを一つのタイプラベルに対して提供することができる。
【００５５】
例示的なアーキテクチャを説明してきたが、以下、ドキュメントの作成中にストリングに意味的なラベリングを行うための例示的な方法３００を、図４および図５を参照して説明する。
【００５６】
図５は、電子ドキュメントの作成中にストリングに意味的なラベリングを行うための方法３００を例示する流れ図である。これはコンピュータ実施プロセスであり、コンピュータによって、ユーザからの入力およびプログラムモジュールによって提供された命令に応答して実行されるものであることは、当業者には理解されよう。
【００５７】
図５を参照すると、方法３００は開始ステップ３０５で開始し、ユーザが電子ドキュメントをアプリケーションプログラムモジュール２０５において開いたとき、ステップ３１０へ進行する。好ましい実施形態では、電子ドキュメントがワードプロセッシングドキュメントまたは表計算ドキュメントである。しかし、方法３００はこれらの特定のタイプの電子ドキュメントのいずれにも限定されない。
【００５８】
ステップ３１０で、アプリケーションプログラムモジュール２０５が新しいストリングを受け取り、これは、ユーザが新しいパラグラフを電子ドキュメントに入力したか、あるいは先に入力されたパラグラフを編集したときなどである。次いで、方法３００はステップ３１５へ進行する。
【００５９】
ステップ３１５で、新しいストリングを含むパラグラフが、アプリケーションプログラムモジュール２０５からレコグナイザＤＬＬ２１０へ渡される。レコグナイザＤＬＬは、アプリケーションプログラムモジュールと通信し、レコグナイザプラグインによって実行される必要のあるジョブを管理し、レコグナイザプラグインから結果を受け取り、アプリケーションプログラムモジュールに意味カテゴリ情報を送る責任を担う。ブート時、レコグナイザＤＬＬはそのレコグナイザプラグインと通信して、何の言語をそれがサポートするか、何のタイプをそれが適用することができるかなどを決定する。好ましい実施形態では、ステップ３１５で、パラグラフがレコグナイザＤＬＬへ渡されることを理解されたい。しかし、代替的な実施形態では、文、表計算セルの内容、ドキュメントのセクション、ドキュメント全体などが、レコグナイザＤＬＬへ渡され得る。すなわち、本発明は、単にパラグラフをレコグナイザＤＬＬへ渡すことに限定されない。次いで、方法３００はステップ３２０へ続く。
【００６０】
なおステップ３１５を参照すると、アプリケーションプログラムモジュール２０５は通常、一度に１パラグラフをレコグナイザＤＬＬに送る。加えて、好ましい実施形態では、文法チェッカプログラムモジュールが、文法チェッカプログラムモジュールによって識別されたすべての意味カテゴリ（タイプラベルなし）をレコグナイザＤＬＬへ送る。これらの意味カテゴリ（タイプラベルなし）をレコグナイザＤＬＬへ渡すことは重要である。これは、そうすることによって各レコグナイザプラグインが、何かが、大文字で始まるストリングの間に機能語が散在しているものであるかどうかを決定する必要（いくつかの正規表現、すなわちＣａｐ  Ｃａｐ  Ｕｎｃ  Ｃａｐ、Ｃａｐ  Ｕｎｃ  Ｃａｐなどの記述が必要となるタスク）を省くからである。レコグナイザプラグインによって、文法チェッカプログラムモジュールがラベルをつけたストリングに、ラベルが適用された場合、その後、その文法チェッカラベルは除去される。
【００６１】
ステップ３２０で、アイドル時間中に、パラグラフ（および文法チェッカプログラムモジュールからの情報）がレコグナイザプラグインに渡される。次いで、この方法はステップ３２５へ続く。
【００６２】
好ましい実施形態では、レコグナイザＤＬＬ２１０がジョブ待ち行列を維持することを理解されたい。レコグナイザＤＬＬ２１０がパラグラフをレコグナイザプラグイン２２０へ送る前に、ユーザがパラグラフを編集した場合、編集されたパラグラフを含むジョブが削除され、レコグナイザプラグインに送られない。次いで、ステップ３１５で新しいジョブが、編集されたパラグラフがステップ３１０で受け取られた後、待ち行列に入る。このジョブ削除は、レコグナイザプラグインが不必要な作業を、編集されたパラグラフにおいて実行することを防止するために必要である。
【００６３】
ステップ３２５で、レコグナイザプラグインがパラグラフにおいて実行されて、キーワードが認識されるか、あるいは、レコグナイザプラグインによって定義された他のアクションが実行される。レコグナイザプラグインの実行の一部として、レコグナイザプラグインによって、パラグラフをセンテンスに分割することができる。しかし、各レコグナイザプラグインは、それ自体のセンテンス分割を担う。ステップ３２５でキーワードが発見された後、この方法はステップ３３０へ続く。
【００６４】
ステップ３３０で、各レコグナイザプラグインからの結果がレコグナイザＤＬＬによって受け取られる。次いで、この方法は判断ステップ３３５へ続く。
【００６５】
判断ステップ３３５で、そのパラグラフがレコグナイザＤＬＬへ送られた後に、レコグナイザプラグインによってレビューされたパラグラフが編集されたかどうかが決定される。そうであった場合、方法３００がステップ３１５へ戻り、レコグナイザＤＬＬによって、編集されたパラグラフがアプリケーションプログラムモジュールから受け取られる。そうでなかった場合、この方法はステップ３４０へ続く。
【００６６】
ステップ３４０で、レコグナイザＤＬＬによって、レコグナイザプラグインからの結果が意味カテゴリへコンパイルされ、意味カテゴリがアプリケーションプログラムモジュールへ送られる。ステップ３４５で、電子ドキュメントにおいて、アプリケーションプログラムモジュールは、ユーザへ意味カテゴリを表示する。次いで、方法３００はステップ３９９で終了する。
【００６７】
上の記載から、意味カテゴリを認識するためのアーキテクチャが、サードパーティによる、１つまたは複数の特定のタイプのストリングを識別するためのレコグナイザプラグインの開発を可能とすることを、理解されたい。レコグナイザプラグインはアプリケーションプログラムモジュールと通信し、ストリングをアプリケーションプログラムモジュールから受け取る。レコグナイザプラグインは認識アルゴリズムをストリングに適用し、認識されたストリングの識別をアプリケーションプログラムモジュールへ送り返すことができる。
【００６８】
ストリングに特定のタイプラベルによりラベルが付けられた後、ユーザは、そのタイプラベルに関係するアクションプラグインを実行することができるようになる。アクションプラグインはＣＯＭオブジェクトであることが好ましく、これらはアプリケーションプログラムモジュールとアクションＤＬＬの間の通信を介して実行される。アクションを実行するために必要なパラメータ（特定のタイプであるとしてラベルが付けられたストリングのＨＴＭＬ、現在の選択を表すストリングのＨＴＭＬ）が、アプリケーションプログラムモジュールからアクションＤＬＬへ渡され、これはアクションプラグインへ渡される。
【００６９】
意味カテゴリに関連付けられたアクションのセットを識別かつ実行するためのアーキテクチャも、提供することができる。このアーキテクチャは、特定のタイプラベルに適用されるアクション（たとえば、本のタイトルのためのアクションを「この本をｓｈｏｐ．Ｍｉｃｒｏｓｏｆｔ．ｃｏｍから購入する」にすることができる）を含み、これらのアクションを、ユーザがそのように望んだときに実行する。アクションは、入力されたストリングに適用された、ユーザにより起動された機能である。たとえば、名前を連絡先フォルダに追加することは、タイプラベル「Ｐｅｒｓｏｎ  ｎａｍｅ（人名）」について可能な１つのアクションである。
【００７０】
異なるアクションを異なるタイプラベルに割り当てることができ、これらのタイプラベル−アクションの割り当てを、タイプ−アクションデータベース２３０に格納することができる。以下の表２は、いくつかの可能なタイプラベル−アクションの組み合わせを例示する。
【００７１】
【表２】
2006276867.tif 000004
【００７２】
各タイプラベルに対して、タイプ−アクションデータベース２３０は、タイプラベルの作成者によって指定されたダウンロードＵＲＬを格納することができ、これらは、その意味カテゴリタイプのためのアクションプラグインまたはレコグナイザプラグインを有していないユーザがアクションプラグインおよび／またはレコグナイザプラグインを取得するために行くことができるところである。たとえば、タイプラベル「Ｂｏｏｋ  Ｔｉｔｌｅ」のためのダウンロードＵＲＬを、ｍｉｃｒｏｓｏｆｔ．ｃｏｍ／ｓｅｍａｎｔｉｃｃａｔｅｇｏｒｉｅｓ．ａｓｐにすることができる。このｗｅｂページに来た後、様々なアクションプラグインおよびレコグナイザプラグインのダウンロードをユーザに提供することができる。ユーザインターフェイスにおいてダウンロードＵＲＬへナビゲートするためのオプションもある可能性がある。意味カテゴリを有するドキュメントの受取り者が、容易にそれらの意味カテゴリに対するアクションプラグインを取得することができるようにするためである。
【００７３】
意味カテゴリを、タグ名の付いた一意のネームスペースとして保存することができる。ネームスペースはＸＭＬ構造であり、論理カテゴリに属するＸＭＬタグのグループを一意に識別するためのものである。したがって、あらゆる意味カテゴリが一意に、そのネームスペース（たとえば、「ｓｃｈｅｍａｓ−ｍｉｃｒｏｓｏｆｔ−ｃｏｍ：ｏｕｔｌｏｏｋ：ｃｏｎｔａｃｔ」）に加えてそのネームタグ（たとえば、「ｓｔｒｅｅｔｎａｍｅ」）によって識別される。
【００７４】
上述の方法３００は、意味カテゴリを識別するための１つの方法であるが、意味カテゴリを識別するための他のメカニズムもあり得る。１つのメカニズムは、ワードプロセッサプログラムモジュール３７に接続された文法チェッカプログラムモジュール（図示せず）である。別のメカニズムは、意味カテゴリを別の電子ドキュメントから受け取ることである。たとえば、意味カテゴリを含むテキストが、ある電子ドキュメントからコピーされ、ワードプロセッサプログラムモジュール３７の別の電子ドキュメントにペーストされたとき、意味カテゴリを識別する情報が保存され、コピーされたテキストと共にコピーされる。
【００７５】
ここで、図６を参照して、意味カテゴリ４００およびその関連付けられたドロップダウンメニュー４０５の表示の例示を説明する。図６は、意味カテゴリ４００、および、アプリケーションプログラムモジュール２０５によってユーザに表示されるようなドロップダウンメニュー４０５の例示であることを理解されたい。
【００７６】
意味カテゴリ４００に関連付けられたストリング４１０は、ストリング「Ｂｏｂ  Ｓｍｉｔｈ（ボブ・スミス）」である。図６のように、意味カテゴリ４００のストリング４１０を、ユーザに対して括弧４１５によって識別することができる。もちろん、着色、下線、アイコンなど、多数の他のデバイスを使用して、ユーザに対し、特定のストリングが意味カテゴリであることを表示することができる。
【００７７】
好ましい実施形態では、ユーザがカーソルをストリング４１０上に置くか、挿入ポイントをストリング４１０内に配置したとき、ドロップダウンメニュー４０５がユーザに表示される。ドロップダウンメニューは、意味カテゴリに関連付けられたアクションのリストを表示することができる。ドロップダウンメニューは、意味カテゴリストリングの上および左側に現れる場合がある。
【００７８】
通常、ドロップダウンメニューの一行目は、どのストリングが意味カテゴリストリングであるか（図６ではＢｏｂ  Ｓｍｉｔｈ）、および意味カテゴリが何のタイプであるか（図６ではＰｅｒｓｏｎ  ｎａｍｅ）を表示する。１行目の下にリストされたものは、この意味カテゴリタイプについて使用可能なアクション４２０であり、これらは「Ｓｅｎｄ  ｍａｉｌ  ｔｏ．．．（メールを送る）」、「Ｉｎｓｅｒｔ  Ａｄｄｒｅｓｓ（住所を挿入する）」および「Ｄｉｓｐｌａｙ  ｃｏｎｔａｃｔ  ｉｎｆｏｒｍａｔｉｏｎ．．．（連絡先情報を表示する）」などである。
【００７９】
ドロップダウンメニューにおける区切り線の下の最初の項目は、「Ｃｈｅｃｋ  ｆｏｒ  ｎｅｗ  ａｃｔｉｏｎｓ．．．（新しいアクションをチェックする）」４２５である。「Ｃｈｅｃｋ  ｆｏｒ  ｎｅｗ  ａｃｔｉｏｎｓ．．．」４２５は、ダウンロードＵＲＬがアプリケーションプログラムモジュールで使用可能である意味カテゴリのみについて現れる。選択された場合、「Ｃｈｅｃｋ  ｆｏｒ  ｎｅｗ  ａｃｔｉｏｎｓ．．．」４２５は、意味カテゴリダウンロードＵＲＬを使用して、ユーザのｗｅｂブラウザを、ストリングに適用された意味カテゴリタイプのためのホームページへナビゲートする。たとえば、新しいアクションが意味カテゴリタイプ「ｐｅｒｓｏｎ  ｎａｍｅ」について定義されていると仮定する。そうであった場合、「Ｃｈｅｃｋ  ｆｏｒ  ｎｅｗ  ａｃｔｉｏｎｓ．．．」４２５を選択した後、新しいアクションがユーザのコンピュータにダウンロードされる。「その意味カテゴリに対してダウンロードＵＲＬが使用不可能であった場合、Ｃｈｅｃｋ  ｆｏｒ  ｎｅｗ  ａｃｔｉｏｎｓ．．．」４２５はグレー表示される。
【００８０】
選択された場合、「Ｒｅｍｏｖｅ  ｔｈｉｓ  ｓｅｍａｎｔｉｃ  ｃａｔｅｇｏｒｙ（この意味カテゴリを削除する）」項目４３０は、意味カテゴリラベルをストリングから削除する。選択された場合、「Ｓｅｍａｎｔｉｃ  ｃａｔｅｇｏｒｉｅｓ（意味カテゴリ）」項目４３５はユーザを、自動訂正ダイアログの意味カテゴリタブへナビゲートする。
【００８１】
アプリケーションプログラムモジュールが要求をアクションＤＬＬへ送り、どのアクションが各意味カテゴリタイプと共に表示されるかを決定することを理解されたい。
【００８２】
上で図６を参照して記載したように、アプリケーションプログラムモジュールは、ドキュメント内ユーザインターフェイスを表示して意味カテゴリの場所を指示するためのオプションを含むことができる。このドキュメント内ユーザインターフェイスは、着色された指示を使用して、意味カテゴリの場所を指示することができ、これは図６における括弧４１５などである。ドキュメント内ユーザインターフェイスは、意味カテゴリのネスティングを表示することもできるようになる。たとえば、Ｍｉｃｈａｅｌ  Ｊｏｒｄａｎ（マイケル・ジョーダン）に、タイプラベル「Ｐｅｒｓｏｎ  Ｎａｍｅ」を有する意味カテゴリとしてラベルが付けられた場合、Ｍｉｃｈａｅｌは、タイプラベル「Ｆｉｒｓｔ  Ｎａｍｅ（名）」を有する意味カテゴリであり、Ｊｏｒｄａｎは、タイプラベル「Ｌａｓｔ  Ｎａｍｅ（姓）」を有する意味カテゴリであり、このドキュメントは、意味カテゴリを表示する括弧付きでこのようになることができる。
【００８３】
［［Ｍｉｃｈａｅｌ］［Ｊｏｒｄａｎ］］
もちろん、ドキュメント内ユーザインターフェイスを、いかなる種類の表示にすることもできる。たとえば、「ＥＸＣＥＬ」表計算アプリケーションプログラムでは、インターフェイスがセルの右下部分において三角形を含んで、１つまたは複数の意味カテゴリがそのセル中に存在していることを表示する。
【００８４】
上述のように、意味カテゴリは、レコグナイザプラグインによって返されたメタデータも含むことができる。たとえば、本のタイトルを認識するレコグナイザプラグインは、それが本のタイトルを認識したとき、メタデータとしてＩＳＤＮ本番号を返すことができる。次いで、このＩＳＤＮ本番号メタデータを使用して、アクションを提供することができる。メタデータを、アクションおよび探索について明確にするために使用することもできる。たとえば、レコグナイザＤＬＬが、名前を認識するために社内従業員データベースにリンクされると仮定する。レコグナイザＤＬＬが「Ｂｏｂ  Ｓｍｉｔｈ」を認識したとき、これは「ｅｍｐｌｏｙｅｅＩＤ＝１２３４５」をメタデータとして、バックグラウンドにおいて格納することができる。次いで、アクションが発生されたとき、問題となっているテキストには、従業員番号４５６７８のＢｏｂ  Ｓｍｉｔｈではなく、従業員番号１２３４５のＢｏｂ  Ｓｍｉｔｈを参照することが知らされる。また、メタデータにより、探索がドキュメントにおける実際のテキストとは無関係に実行できるようにすることも可能である。そのため、従業員データベースにおいて従業員１２３４５を探すことによって、そしてメタデータにおける探索を従業員番号１２３４５について実行して、それらにおいて「Ｂｏｂ  Ｓｍｉｔｈ」を有するドキュメントを発見することによって、「Ｒｏｂｅｒｔ  Ｓｍｉｔｈ（ロバート・スミス）」に関する探索を行うことができる。メタデータについての多数の他の機能もある。たとえば、ＤＨＴＭＬを挿入して、特殊なトリックをｗｅｂブラウザ内で実行できるようにすることができる。加えて、他のアクションによって使用されたデータを挿入することができ、これは、メールを送るアクションによって使用することができる誰かの電子メールアドレスなどであり、また、日付の正規化されたバージョンを格納して、容易に個人情報マネージャと対話することなどができる。
【００８５】
以上、意味カテゴリを詳細に説明してきたが、以下の記載では、意味カテゴリ認識を、文法およびＸＭＬスキーマを使用して提供することを中心とし、これらもモードバイアスを適用するために使用される。バイアスモードを上述のように適用することに加えて、アプリケーション３７（それが意味カテゴリをサポートすると仮定する）は、図４に記載したインフラストラクチャを介して、レコグナイザプラグインのセットへテキストを渡すことも行うことを理解されたい。１つまたは複数のレコグナイザプラグインを、文法データベース５１５およびスキーマデータベース５２０に接続することができる。これらのレコグナイザプラグインは文法データベースにおける文法を使用して、意味カテゴリを認識することができる。好ましい実施形態では、ある文法のみが意味カテゴリ認識のための使用のために指定され、指定された文法のリストはスキーマレジストリマネージャから得られる。文法を使用して意味カテゴリを認識することに関するより詳細な説明を、以下に提供する。
【００８６】
ここで、図７を参照して、本発明の一実施形態による、文法を使用した意味カテゴリ認識のための方法７００を例示する流れ図を説明する。ステップ７０５で、ユーザがアプリケーションを開始し、これはいくつかのレコグナイザプラグインをブートする。ステップ７１０で、１つまたは複数のレコグナイザプラグインがスキーマレジストリマネージャと通信し、意味カテゴリ認識のために使用するスキーマ／文法の対のセット一式を検索する。ステップ７１５で、ユーザは、ドキュメントにおいてモードバイアスがない場所に、あるテキストを入力する。ステップ７２０で、アイドル時間中に、テキストがレコグナイザプラグインへ渡される。ステップ７２５で、そのテキストがスキーマレジストリにおいて発見された文法に準拠する場合、レコグナイザプラグインはスキーマレジストリからのスキーマを、テキストへ適用する。ステップ７３０で、ドキュメントが保存されるとき、テキストは、そのテキストに適用されたスキーマと共に保存される。したがって、前述の記載から理解されるように、スキーマは、テキストにラベルを付けるために意味カテゴリとして使用されている。アクションプラグインがこのスキーマを使用して、その後、アクションを提供することができる。
【００８７】
したがって、上述のように、本発明によるモードバイアスの適用を、意味カテゴリの認識にも関係付けることができる。意味カテゴリの認識には、あるテキストが何のカテゴリにあるかを、それが入力された後に決定することが必要であるのに対し、モードバイアスの適用には、あらかじめ何のタイプのテキストが入力されるかを指定することが必要である。同じ規則または統計的モデル（文法）を使用して意味カテゴリを認識することができ、これは、テキストが規則のいずれかに合致するかどうかを決定することによって行われ、そして、モードバイアスの指定については、確率的入力方式により、それらの規則に準拠するように入力を制約することによって行われる。
【００８８】
したがって、本発明の一実施形態では、ユーザが電話番号を、電話番号モードバイアスが設定されているフィールドに入力した後、そのフィールドが電話番号を含むという事実が保持される。したがって、どのような人（そのデータタイプに直接関係のあるアクションのリストを要求するユーザなど）またはプロセス（たとえば、サーチエンジン）が後にドキュメントを見るかに関わらず、そのフィールドが電話番号であるというその事実は、それらに対して明らかとなる。さらに、ユーザが電話番号をドキュメントにおける任意の場所に、すなわち、モードバイアスのアプリオリな指定がなかった場所において入力した場合、電話番号にはそのようにレコグナイザプラグインによってラベルが付けられる。すなわち、本発明のモードバイアスメカニズムが適所にあった後、レコグナイザプラグインがスキーマレジストリにおける多数の項目を、入力のために使用される同じパターンを使用して識別することができる。しかし、すべての文法を必ずしも使用しなければならないのではない。これは、いくつかの文法は、特定のジャンルのテキストについてものだからである。たとえば、法律文テキストまたは医療的なテキスト、または判例法テキストと同じほど特殊であるものなどである。１つの特定のジャンルからのものとして現れるすべてのテキストへのラベリングには、ほとんど効果がない可能性がある。同様に、いくつかの文法はあまりにも一般的であるため、無用である。たとえば、数値などの汎用タイプは、十分な意味カテゴリアクションを容易にすることができない。
【００８９】
したがって、前述の説明から、同じ文法を使用してモードバイアスを適用することができ、また意味カテゴリを認識することもできることを理解されたい。この関係を利用することは、構築のためにより少ない文法を有するであろう開発者にとって、そして、意味カテゴリを介して、より良い入力およびより豊富な機能を受けるであろうユーザにとって、有利である。加えて、モードバイアスと意味カテゴリの間の関係は一貫性を最大とする。これは、何かに部品番号意味カテゴリとしてラベルが付けられた場合、フォームが部品番号を要求するときは、それを入力できるようにするべきであるからである。逆も同じである。
【００９０】
上述の説明から、ドキュメントまたはフォームの特定の領域への入力があるパターンに準拠するべきであると指定するための標準的な方法を有することが重要であり、これは、予想された入力が特定のタイプのものであるかあるいは特定のプロパティを有するからであることを、理解されたい。本発明は、ドキュメントまたはフォームの特定の領域への入力があるパターンに準拠するべきであると指定する方法を提供する。たとえば、電話番号を連絡先管理ソフトウェアの電話番号フィールドに入力するとき、ユーザはほぼ確かに、十分に形成された電話番号を入力し、いかなる入力方式を彼らが使用中であろうと、それを可能な限り容易にするべきである。電話番号の厳密なフォームは、ユーザの地域に応じて異なる可能性があるが、ユーザが世界中のどこにいようと、彼らが電話番号フィールドの中に自由なテキストを入力できると期待するようなことはない。
【００９１】
音声、手書きまたは東アジア入力方式エディタなどの入力方式以外のツールであっても、モードバイアスについて知っていることが必要であることを理解されたい。たとえば、スペリング、文法およびスタイルチェッカなどの校正ツールを、本発明のモードバイアスにある程度は適合できるようにするべきである。たとえば、非確率的入力方式（英語のタイピングなど）を使用して、テキストがモードバイアスを有するフォームに入力された場合、どのような校正ツールがそのテキストに関して動作していようと、モードバイアスによってそのテキストに課せられた制約を認識されているべきである。たとえば、名前を入力することができるフィールドにおいてスペルチェックをオフにすることは、当然のことである。あるいは、統計的言語モデルを使用するスペルチェッカは、テキストがその性質において医療関係のものであるのかあるいは法律文のものであるかということを知ることによって、より適切なモデルに交換することができる場合がある。
【００９２】
上述の説明から、本発明により、すべての入力方式が、それらによるモードバイアスの処理において標準化されることが可能であることを理解されたい。たとえば、電話番号入力に対しては、音声レコグナイザおよび手書きレコグナイザが同じ（または類似の）文法をスキーマレジストリマネージャから受け取る。次いで、音声レコグナイザおよび手書きレコグナイザは、電話番号入力を類似の方法によって処理できるようになり、入力方式の標準化が存在するようになる。本発明にはまた、従来技術よりも柔軟性がある。これは、新しいスキーマおよび文法をデータベースに追加することができ、しかも必要に応じて更新することができるからである。
【００９３】
上述の説明から、入力方式が文法を受け取った後、入力方式はこの文法を多数の異なる方法において使用できることが当業者には明らかになるであろうことを、理解されたい。たとえば、文脈自由文法の場合、入力方式は、ユーザが述べたこと（または、タイプあるいは手書きしたことなど）を文法の要素と付き合わせようと試みることができ、存在しなかった場合、入力を拒否することができる。もう１つの実施形態として、入力方式は、語、フレーズなどを明確にするための方法として、この文法を使用することができる（たとえば、文法が、「ｔｏ」ではなく「ｔｗｏ」という語を含む場合、この情報を使用して、ユーザが何を入力中であるかを認識することができる）。
【００９４】
上述の説明が本発明の好ましい実施形態にのみ関係すること、および、多数の変更を、本発明の精神および範囲から逸脱することなく、本明細書に記載された実施形態に行うことができることを理解されたい。
【図面の簡単な説明】
【００９５】
【図１】本発明のための例示的オペレーティング環境を提供するコンピュータのブロック図である。
【図２】本発明の一実施形態による、モードバイアスを実施するためのアーキテクチャを例示するブロック図である。
【図３】本発明の一実施形態による、モードバイアスをテキストに適用するための方法を例示する流れ図である。
【図４】意味カテゴリを実施するための例示的アーキテクチャを例示するブロック図である。
【図５】電子ドキュメントの作成中に、ストリングに意味的なラベリングを行うための方法を例示する流れ図である。
【図６】意味カテゴリおよびその関連付けられたドロップダウンメニューの表示の例示の図である。
【図７】本発明の一実施形態による、文法を使用した意味カテゴリ認識のための方法を例示する流れ図である。
【符号の説明】
【００９６】
２１  処理装置
２２  システムメモリ
２３  システムバス
２４  ＲＯＭ
２５  ＲＡＭ
２６  ＢＩＯＳ
３２  ハードディスクドライブインターフェイス
３３  磁気ディスクドライブインターフェイス
３４  光ディスクドライブインターフェイス
３５  オペレーティングシステム
３６  アプリケーションプログラムモジュール
３７  プログラムモジュール
３８  プログラムデータ
４０  キーボード
４２  マウス
４６  シリアルポートインターフェイス
４７  モニタ
４８  ビデオアダプタ
４９  リモートコンピュータ
５１  ローカルエリアネットワーク
５２  広域ネットワーク
５３  ネットワークインターフェイス
５４  モデム
２０５  アプリケーションプログラムモジュール
２１０  レコグナイザＤＬＬ
２１５  アクションＤＬＬ
２２０  レコグナイザプラグイン
２２５  アクションプラグイン
２３０  タイプ−アクションデータベース
５０５  テキストサービスフレームワーク
５１０  スキーマレジストリマネージャ
５１５  文法データベース
５２０  スキーマデータベース
５２５  音声認識エンジン
５３０  手書き認識エンジン
５３５  入力方式エディタ
５４０  他の入力メカニズム
【図１】
2006276867.tif 000005
【図２】
2006276867.tif 000006
【図３】
2006276867.tif 000007
【図４】
2006276867.tif 000008
【図５】
2006276867.tif 000009
【図６】
2006276867.tif 000010
【図７】
2006276867.tif 000011