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