(57)【要約】入力チャネルの限られたセットを持つデバイスにおけるデータの効率的なエントリのための装置、方法およびシステムが開示される。これらの装置、システムおよび方法は、入力の効率的なエントリを可能にするユーザインターフェイスを用いることができる。このインターフェイスは、それが使用されるデバイスおよびインターフェイスに関連する意味論的な意味に従って調整されることができる。データの効率的なエントリを助けるために、これらの装置、システムおよび方法は、ユーザ入力の多義性を解消、入力を正確に特定するための効率的な手法を提供、またはユーザ入力を予測する。これらの装置、システムおよび方法は、あるユーザの性癖に適合することもでき、頻繁に使用する入力のためにユーザ定義の略語および同義語を組み込んでもよい。
2007529069.tif 000002
【特許請求の範囲】
【請求項１】
最初の押下を検出するステップと、
解放を検出するステップと、
前記押下と解放との間の動作を検出するステップであって、１つ以上のゾーンのセットに入ることまたは前記セットから出ることを検出するステップをさらに含む、動作を検出するステップと、
前記最初の押下と、前記動作と、前記解放を離散的なメッセージに正規化するステップと
を包含する、データエントリ用のインターフェイスのための方法。
【請求項２】
前記ゾーンのセットは、インターキーゾーンのセットおよびキーゾーンのセットを含み、２つのキーゾーンが隣接することはなく、各キーゾーンは少なくとも１つのインターキーゾーンと隣接する、請求項１に記載の方法。
【請求項３】
前記ゾーンのセットは行のセットに配置されている、請求項２に記載の方法。
【請求項４】
前記行のセットは少なくとも１つの同心円の曲線を形成する、請求項３に記載の方法。
【請求項５】
前記行の各々は各端にキーゾーンを有し、前記行内のキーゾーンの間にインターキーゾーンがある、請求項３に記載の方法。
【請求項６】
前記インターキーゾーンの各々は、少なくとも２つの隣接する近接キーゾーンとオーバーラップする、請求項５に記載の方法。
【請求項７】
前記インターキーの各々の全部分は、前記少なくとも２つの隣接する近接キーゾーンに関連する、請求項６に記載の方法。
【請求項８】
前記関連は前記動作に基づく、請求項７に記載の方法。
【請求項９】
前記離散的なメッセージは位置および方向を含む、請求項１に記載の方法。
【請求項１０】
前記離散的なメッセージに意味論的な意味を関連付ける、請求項９に記載の方法。
【請求項１１】
前記最初の押下は第１のゾーンにあり、前記解放は第２のゾーンにある、請求項１０に記載の方法。
【請求項１２】
センサであって、
最初の押下を検出することと、
解放を検出することとと、
前記押下と解放との間の動作を検出することであって、１つ以上のゾーンのセットに入ることまたは前記セットから出ることを検出することをさらに含む、動作を検出することと
を実行するように動作可能なセンサと；
前記最初の押下と、前記動作と、前記解放を離散的なメッセージに正規化するように動作可能な論理と；
を備える、データエントリ用のインターフェイスのためのシステム。
【請求項１３】
前記ゾーンのセットはインターキーゾーンのセットおよびキーゾーンのセットを含み、２つのキーゾーンが隣接することはなく、各キーゾーンは少なくとも１つのインターキーゾーンと隣接する、請求項１２に記載のシステム。
【請求項１４】
前記ゾーンのセットは行のセットに配置されている、請求項１３に記載のシステム。
【請求項１５】
前記行のセットは少なくとも１つの同心円の曲線を形成する、請求項１４に記載のシステム。
【請求項１６】
前記行の各々は各端にキーゾーンを有し、前記行内のキーゾーンの間にインターキーゾーンがある、請求項１４に記載のシステム。
【請求項１７】
前記インターキーゾーンの各々は、少なくとも２つの隣接する近接キーゾーンとオーバーラップする、請求項１６に記載のシステム。
【請求項１８】
前記インターキーの各々の全部分は、前記少なくとも２つの隣接する近接キーゾーンに関連する、請求項１７に記載のシステム。
【請求項１９】
前記関連は前記動作に基づく、請求項１８に記載のシステム。
【請求項２０】
前記離散的なメッセージは位置および方向を含む、請求項１２に記載のシステム。
【請求項２１】
前記論理は前記離散的なメッセージに意味論的な意味を関連付けるように動作可能である、請求項２０に記載のシステム。
【請求項２２】
前記最初の押下は第１のゾーンにあり、前記解放は第２のゾーンにある、請求項２１に記載のシステム。
【請求項２３】
センサであって、
最初の押下を検出することと、
解放を検出することとと、
前記押下と解放との間の動作を検出することであって、前記センサによって実装された１つ以上のゾーンのセットに入ることまたは前記セットから出ることを検出することをさらに含む、動作を検出することと
を実行するように動作可能なセンサと；
前記ゾーンの各々と関連するコンテキストに基づいて、前記最初の押下と、前記動作と、前記解放を意味論的な意味に正規化するように動作可能な論理と；
を備える、データエントリ用のインターフェイスのためのシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
（関連出願）
本願は、Ｖａｎ  ｄｅｒ  Ｈｏｖｅｎによる、タイトルが「Ｍｅｔｈｏｄｓ  ａｎｄ  Ｓｙｓｔｅｍ  ｆｏｒ  Ｄｉｓａｍｂｉｇｕａｔｉｏｎ  ａｎｄ  Ｐｒｅｄｉｃｔｉｖｅ  Ｒｅｓｏｌｕｔｉｏｎ」の米国特許出願第１０／８００，２０３号（２００４年３月１２日出願）に関連する。本パラグラフにおいて引用する全ての出願は、参照により、完全に援用される。
【０００２】
（本発明の技術分野）
本発明は、データエントリに関し、より具体的には、デバイスへの効率的なデータのエントリのためのインターフェイスおよび論理に関する。
【背景技術】
【０００３】
コンピュータ時代の幕開けから、最も安定した継続的な傾向は、小型化へ向かうものである。この傾向は、産業の全面において明白に示されている。携帯電話、携帯情報端末（ＰＤＡ）、ポータブルコンピュータなどは、すべて驚異的な速度でサイズが小さくなっている。しかしながら、これらのデバイスは縮小するにつれて、逆により強力にもなってきた。この二分化には若干問題がある。ユーザに情報を伝達し、ユーザから情報を収集する必要性がデバイスの力と相応に増加する一方で、これらのディスプレイおよびデータエントリインターフェイスのために利用可能なスペースは、当然ながらデバイスとともに縮小しているのである。
【０００４】
データエントリおよびディスプレイという２つのサブシステムのそれぞれについて、各サブシステムが無効または無益にならない程度に可能なサイズ縮小には先天的な物理的制約がある。ユーザへの伝達における物理的制約は、データエントリ用のインターフェイスにおけるそれよりもはるかに大きい。これらの制約は、ハードウェア制約、生理的制約、および、ほとんどの場合において、データは視覚的にユーザへ伝達されなくてはならないという事実を含む場合がある。したがって、伝達およびデータエントリのために確保されているデバイスの設置面積のうち大部分は、ビジュアルディスプレイによって占められる場合がある。このビジュアルディスプレイにより、データエントリ用のインターフェイスのための余地はほとんど残らない。
【０００５】
この問題に対処するソリューションは、手書きソフトウェアを内蔵することによって考案されている。このソリューションを利用するために、ユーザはタッチディスプレイに書き込むことによってテキストを直接入力できる。その後手書きデータは、手書き認識ソフトウェアによってデジタルデータに変換される。このソリューションにより、１つのディスプレイでユーザへの情報伝達とユーザからのデータ受信の両方が可能になるが、手書き認識ソフトウェアの精度およびスピードは不十分であることが知られている。また、スタイラスによる印字および書き込みは、概してタイピングまたはキーベースの入力より遅く、両手の使用を必要とする。
【０００６】
したがって、データをエントリするための、小型かつ片手で操作できるインターフェイスを使用することは好都合である。そのようなキーボードにおける従来の試みは、キーの数が削減されたキーボードの発達をもたらした。図１は、デバイス用の従来技術の削減されたキーパッド１００を示す。キーパッド１００は、１０個の数字キー１１０〜１２８、アスタリスク（＊）キー１３０、およびシャープ（＃）キー１４０を有する標準的な電話キーパッドである。英語およびその他多数のアルファベット言語の場合、電話機の数字キーパッドはアルファベットキーパッドによってオーバーレイされており、各数字キー１１０〜１２８には３つの文字が関連する。例えば、２のキー１１４は文字ａ・ｂ・ｃと関連する。これらの削減されたキーデバイスの一部によって、ユーザは複数のキー押下を用いて文字または名前を入力することができる。
【０００７】
しかしながら、このソリューションにも問題がある。中国語および日本の漢字などその他のキャラクタベースの言語は、数字キーパッドでオーバーレイできる処理しやすい数の文字を有していない。さらなる問題は、各キー押下がキーストロークの配列において多義性を作成する複数のキャラクタを含む場合があることである。
【０００８】
多義性の問題に対するソリューションは、各文字を特定するためにユーザに１つ以上のキーストロークを入力させることであり、キーストロークは同時に（コーディング）または順に入力されることができる。しかしながら、これらのアプローチは多くのキーストロークを必要とし、したがって非効率的である。理想は、データエントリ方法は１文字につき１つのキーストロークを必要とすることであろう。
【０００９】
従来、受信したキーストロークの列を辞書の中の考えられる取り合わせと比較することにより語全体の多義性解消をするために、ワードレベルの多義性解消が使用されてきた。しかし、復号化の制約のため、ワードレベルの多義性解消が、１キャラクタにつき１つのキーストロークという効率を持つ拘束されないデータのエラーのない復号化を達成するわけではない。
【００１０】
したがって、様々なデータの効率的な片手エントリおよびが可能なインターフェイスのための装置、方法およびシステム、ならびに、キャラクタの多義性解決および入力の予測補完のための論理を使用することによって、データエントリに必要なストローク数を削減する能力が必要である。
【発明の開示】
【課題を解決するための手段】
【００１１】
入力チャネルの限られたセットを持つデバイスにおけるテキストの効率的な入力のための装置、方法およびシステムが開示される。これらの装置、システムおよび方法は、片手の親指によって操ることができるキーレイアウトを使用することにより、片手操作を可能にするユーザインターフェイスを用いることができる。このインターフェイスは、それが利用される特定のデバイスに合わせて調整されることができ、場合によっては複数のキャラクタを各キーまたはキーの一部と関連付けることができる。データの効率的なエントリを助けるために、これらの装置、システムおよび方法は、ユーザが入力したデータがいくつかの解釈を有し得る場合のユーザ入力の多義性を解消、入力を正確に特定するための効率的な手法を提供、またはユーザ入力を予測し、これらの予測をユーザに提示する。これらの装置、システムおよび方法は、あるユーザの性癖に適合することもでき、頻繁に使用する入力のために、略語、翻訳、および同義語を組み込んでもよい。
【００１２】
一実施形態において、最初の押下が検出され、解放が検出され、前記押下と解放との間の動作がゾーンのセットを利用して検出され、次いで、前記最初の押下と、前記動作と、前記解放は、離散的なメッセージに正規化される。
【００１３】
その他の実施形態において、前記ゾーンのセットはインターキーゾーンのセットおよびキーゾーンのセットを含み、各キーゾーンは少なくとも１つのインターキーゾーンと隣接する。
【００１４】
さらに他の実施形態において、前記ゾーンのセットは行のセットに配置されている。
【００１５】
さらに他の実施形態において、各行は各端にキーゾーンを有し、前記行内のキーゾーンの間にインターキーゾーンがある。
【００１６】
別の実施形態において、各インターキーゾーンは、少なくとも２つの隣接する近接キーゾーンとオーバーラップする。
【００１７】
さらに別の実施形態において、各インターキーの全部分は、前記少なくとも２つの隣接する近接キーゾーンに関連する。
【００１８】
いくつかの実施形態において、意味論的な意味は前記離散的なメッセージと関連付けられている。
【００１９】
以下の説明および付随する図面と併せて考察すれば、本発明のこれらの、またはその他の側面がよりよく理解されるであろう。以下の説明は、本発明の様々な実施形態およびその多くの具体的な詳細を示しているが、例示的なものであって限定的なものではない。本発明の範囲内で、多くの代用、修正、追加または再配置を行うことができ、本発明はそのような代用、変更、修正または再配置のすべてを含む。
【００２０】
本明細書に付随しその一部を形成する図面は、本発明のある側面を描写するために含まれるものである。本発明、ならびに本発明により提供されるシステムのコンポーネントおよび操作のより明確な印象を、例示的な、したがって限定的なものでない、図面中に示された実施形態により容易に表し、ここで同一の参照番号は同一のコンポーネントを指す。図面中に示される特徴は、必ずしも一定の縮尺ではないことに留意されたい。
【発明を実施するための最良の形態】
【００２１】
本発明ならびにその様々な特徴および好都合の詳細を、添付の図面に示され以下の説明において詳述されている限定的でない実施形態を参照して、より完全に説明する。公知の出発原料、処理技術、設備、コンポーネント、および設備についての説明は、本発明の詳細を不必要に不明瞭にしないよう、省略する。しかしながら、当業者であれば、本発明の好適な実施形態が開示されているが、詳細な説明および特定の例が限定目的ではなく例示目的のみで挙げられていることを理解するであろう。本開示を読了後、当業者には、発明概念の根底の範囲内で様々な代用、修正、追加、または再配置が明らかになるであろう。
【００２２】
本発明の例となる実施形態を参照すると、その例が添付の図面中に示されている。可能な限り、同一の参照番号は、図面全体を通して同一または同様の部分（要素）を言及するために使用する。
【００２３】
本明細書全体を通して使用される際の用語の理解を促進するため、いくつかの用語を定義または明確化する。
【００２４】
「キャラクタ」という用語は、いかなる記号をも意味することを目的としており、キャラクタは文字、発音区別符号、漢字の一部、当技術分野における書き込みおよび印字の意味合いを持つ任意の記号などであってよい。
【００２５】
「キー」という用語は、接触を含むユーザアクションに応答するインターフェイスのゾーンを意味することを目的としている。意味論的な意味はキーまたはキーの一部に関連している場合があり、この意味論的な意味は１つ以上のキャラクタまたは制御情報からなる場合がある。
【００２６】
「キーボード」という用語は、キーの系列を意味することを目的としている。
【００２７】
「予測」という用語は、記号の配列の補完を予測しようとする試みの結果を意味することを目的としている。この予測は、確率的、数学的、言語的、またはその他任意のものを含む、いかなるタイプのシステムに基づくものであってもよい。
【００２８】
「同義語」という用語は、使用モデルについて使用される場合、予測の考えられる代替を意味することを目的としている。これらの同義語は予測と関連していてもよく、予測に対応するデータ構造、または予測に対応する終端ノードに格納される場合がある。
【００２９】
「命題」という用語は、１つ以上のキャラクタの配列、またはこれらの配列のセットを意味することを目的としている。
【００３０】
「接頭辞」という用語は、ユーザ入力、多義性解消または予測などによって拡張されてもされなくてもよい１つ以上のキャラクタの配列を意味することを目的としている。
【００３１】
「候補」という用語は、１つ以上のキャラクタの配列および関連スコアを意味することを目的としている。このスコアは、確率的、数学的、言語的、またはその他任意のものを含む、いかなるモデルに基づくものであってもよい。
【００３２】
「アクティブゾーン」という用語は、ユーザからの入力を受信するために使用されるインターフェイスの一部に指定されたインターフェイスのゾーンを意味することを目的としている。
【００３３】
「ゾーン」という用語は、インターフェイスの領域またはセンサの範囲内を意味することを目的としている。
【００３４】
「多義的な」という用語は、何かがいくつかの考えられる意味を有することを意味することを目的としている。
【００３５】
「補完」という用語は、記号の最初のセット（通常、接頭辞と称する）と連結される際に記号の最終または中間配列を形成することができる記号のセットである。多くの状況において、補完は望ましい最終または中間配列を形成する高い確率を有するよう計算されている場合がある。
【００３６】
「メッセージを送信する」という表現は、伝送もしくは情報の交換または利用を意味することを目的としている。メッセージがどのようにして送信されるか、または任意の特定の実施形態においてメッセージの送信が必要であるか否かについてさえも、仮定はなされないことに留意することが重要である。
【００３７】
「配列」という用語は、順序の概念を持つ、限られた数の要素を意味することを目的としている。セットは空であっても、または１つだけ要素を含んでもよい。これは数学において一般に是認されている定義である。（ｅ１，…，ｅｎ）として表記する。
【００３８】
「セット」という用語は、順序の概念を持たない、限られた数の要素を意味することを目的としている。セットは空であっても、または１つだけ要素を含んでもよい。これは数学において一般に是認されている定義である。｛ｅ１，…，ｅｎ｝として表記する。
【００３９】
「タイプ」という用語は、値または分類の幅を意味することを目的としている。変数または値をタイピングすることは、それを列挙すること、もしくはあり得る値または分類を特定することである。タイプＴを持つ要素Ｅのタイピングは、「Ｅ：Ｔ」のように表記される。
【００４０】
「構造」という用語は、要素の順序セット（ｅ１，…，ｅｎ）を意味することを目的としている。各要素ｅｉは、タイプｔｉとともにタイプされてもよい。構造のタイプはしたがって配列（ｔ１，．．．，ｔｎ）である。
【００４１】
「フィールド」という用語は、構造の要素を意味することを目的としている。フィールドには名前をつけることができる。Ｐ（ｅ：ｔ）は、構造ｐがタイプｔのフィールドｅを有することを示唆する。ｐがタイプｐ（上記のように）である場合、ｐは要素ｐのフィールドを表す。
【００４２】
次に、入力チャネルの限られたセットを有するデバイスにおける効率的なテキスト入力のための装置、方法およびシステムに注意を向ける。これらの装置、システムおよび方法は、片手の親指で操ることが可能なキーレイアウトを使用することによって効率的な片手操作を可能にするユーザインターフェイスを用いることができる。このインターフェイスは、それが利用される特定のデバイスに合わせて調整されることができ、場合によっては複数のキャラクタを各キーまたはキーの一部と関連付けることができる。データの効率的なエントリを助けるために、これらの装置、システムおよび方法は、ユーザによって入力されたデータがいくつかの解釈を持ち得る場合、これらのキーからのユーザ入力の多義性を解消、入力を正確に特定するための効率的な手法を提供することができる。これらのシステムおよび方法は、ユーザ入力を予測し、これらの予測をユーザに提示することもできるため、ユーザはテキスト全体を手動で入力する代わりにそれらを選択することができる。これらの予測システムおよびシステムは、あるユーザの性癖に適合することもでき、頻繁に使用する入力のためにユーザ定義の略語および同義語を組み込んでもよい。
【００４３】
本発明の例示的な実施形態において、コンピュータで実行可能な命令は、アセンブリコードまたはコンパイルされたＣ＋＋の行、Ｊａｖａ（登録商標）、またはその他の言語コードであってよい。その他のアーキテクチャを使用してもよい。さらに、そのようなコードを持つコンピュータプログラムまたはそのソフトウェアコンポーネントは、１つ以上のコンピュータ内の１つ以上のコンピュータシステム可読媒体において具現化されてもよい。
【００４４】
続いて図２を見ると、開示される装置、方法およびシステムを実装および整理するためのアーキテクチャ２００の一実施形態が提示されている。本明細書を読了後、当業者は、本発明の実施形態にはその他多くのアーキテクチャが利用され得ることを理解するであろう。一実施形態において、これらのアーキテクチャは、主要センサ２１０、追加センサ２１２、キーストロークモジュール２２０、意味論モジュール２４０、コア論理２５０、言語モデル２６０、および使用法モデル２７０を含む。キーストロークモジュール２２０は、原理センサ２１０からデータを受信することができる。キーストロークモジュール２２０は、このデータを処理し結果を意味論モジュール２４０へ送信する。意味論モジュール２４０は、この結果をキーストロークモジュール２２０および任意の追加センサ２１２から取得する。意味論モジュール２４０はその後、使用コンテキスト２９０、テキスト要素２８０、メニュー要素２８２、および出力デバイス２８４を使用してこのデータを処理し、コア論理２９０によって使用するためにデータを構築することができる。コア論理２５０は、意味論モジュール２４０、言語モジュール２６０または使用法モデル２７０を使用して多義性を解消またはユーザ入力の予測補完をすることができる。コア論理２５０は、その結果を意味論モジュール２４０に提示することができる。意味論モジュールはその後、使用コンテキスト２９０、テキスト要素２８０、メニュー要素２８２および出力デバイス２８４の組み合わせを通じて結果を出力することができる。
【００４５】
概して、このアーキテクチャは、片手の親指で使用するために設計された構成を含む入力デバイスの多種多様な構成を可能にすることによって、デバイスにデータを入力するユーザ能力を高めるように設計される。実施形態は、入力の多義性を解決し、ユーザが曖昧なところなく正確な入力を特定するための効率的な手法を可能にし、さらなる手動入力を回避するために予測補完をユーザに提示することもできる。当業者であれば、本開示の読了後、このアーキテクチャは説明目的のみのために提示されたものであり、説明されているすべての機能性は、これより多いまたは少ないモジュールによって、通過するメッセージの有無、ソフトウェアにおいて、ハードウェアにおいて、などを含む多種多様な手法において具現化されることができることを認識するであろう。
【００４６】
特定の実施形態において、ユーザのアクションはセンサ２１０、２１２によってキャプチャされ、意味論モジュール２４０にレポートされる。いくつかの実施形態において、主要センサ２１０からの情報は意味論モジュール２４０へレポートされる前にキーストロークモジュール２２０によって処理される場合がある。意味論モジュール２４０は、ユーザにとって唯一のインターフェイスであってよく、すべての着信および発信メッセージを翻訳および書式設定することに関与していてもよい。意味論モジュール２４０の翻訳は、コンテキスト依存であってよく、またはシステムへの統合のためのパラメータ化を提供してもよい。コア論理２５０は、ユーザ入力の予測および多義性の解決を含む、意味論モジュール２４０とユーザとの間の対話を管理するための規則を含んでよい。
【００４７】
コア論理２５０は、ユーザ入力の多義性を解消するための言語モジュール２６０を含むデータ構造、およびユーザ入力を予測するためのユーザモデル２７０を使用することができる。テキスト要素２８０、メニュー要素２８２、およびその他任意の出力デバイス２８４は、その論理の結果またはシステムの状態を示すために、意味論モジュール２４０によって使用されることができる。テキスト要素２８０は、それによってユーザが記号の配列を挿入または入力できる、または現存する信号の配列を拡張できる、およびそれを通じて記号の配列を表示することができる、データエントリインターフェイスであってよい。
【００４８】
特定の一実施形態において、テキスト要素２８０は、ユーザが記号の配列を挿入または配列を拡張できるデバイスである。テキスト要素２８０は、考えられる接頭辞またはその他の入力テキストに情報を含むメッセージ（ＥｄｉｔＴｅｘｔ（テキスト編集））をシステムまたは意味論モジュール２４０へ送信することができる。テキスト要素２８０はその後、ＥｄｉｔＴｅｘｔ（テキスト編集）メッセージを受けて、意味論モジュール２４０から記号（Ｓ）の配列を含むＳｕｂｓｔｉｔｕｔｅＴｅｘｔ（サブタイトルテキスト）メッセージを受信する。テキスト要素２８０は、ユーザが信号の配列の入力を終了した際にＥｎｄＥｄｉｔ（編集終了）の補完を信号で伝えるＥｎｄＥｄｉｔ（編集終了）メッセージを受信することもできる。テキスト要素２８０がこのＳｕｂｓｔｉｔｕｔｅＴｅｘｔ（サブタイトルテキスト）メッセージを受信すると、テキスト要素２８０はそれに応じて応答することができる。前回ＥｄｉｔＴｅｘｔ（テキスト編集）が送信されてから最初に受信したＳｕｂｓｔｉｔｕｔｅＴｅｘｔ（サブタイトルテキスト）であり、前回のＥｄｉｔＴｅｘｔ（テキスト編集）が接頭辞を有する場合、テキスト要素２８０内の接頭辞に関連する信号の配列の代わりにＳｕｂｓｔｉｔｕｔｅＴｅｘｔ（サブタイトルテキスト）引数が用いられ、その後これがユーザに対して表示される。前回ＥｄｉｔＴｅｘｔ（テキスト編集）が送信されてから最初に受信したＳｕｂｓｔｉｔｕｔｅＴｅｘｔ（サブタイトルテキスト）であり、前回のＥｄｉｔＴｅｘｔ（テキスト編集）が接頭辞を有さない場合、テキスト要素２８０は単にユーザに対して表示された配列中にＳｕｂｓｔｉｔｕｔｅＴｅｘｔ（サブタイトルテキスト）引数を挿入することができるだけである。間にＥｎｄＥｄｉｔ（編集終了）のない、２つの連続するＳｕｂｓｔｉｔｕｔｅＴｅｘｔ（サブタイトルテキスト）メッセージの場合は、第２の引数によって第１のＳｕｂｓｔｉｔｕｔｅＴｅｘｔ（サブタイトルテキスト）メッセージのテキストを置換し、ユーザに対して情報を表示する。
【００４９】
メニュー要素２８２は、出力またはシステムの状態に応じて、ユーザに一組の選択肢またはオプションを提示することができる。メニュー要素２８２は、ある実施形態においてテキスト要素２８０と組み合わせてよい。メニュー要素２８２は、ユーザが選択するための、選択肢のリストまたは選択肢のツリーを表示することができる。メニュー要素２８２は、意味論モジュール２４０から引数を含むＳｅｔＭｅｎｕ（メニュー設定）メッセージを受信することができる。この引数は、メニューがリストである場合にはフラットリストであってよく、もしくは、ツリーメニューの場合には、ツリーにおける選択肢の場所または選択肢の入れ子リストに関する引数であってよい。選択肢は記号または定数の配列であってよい。ユーザが提示されたリストから選択肢を選択すると、ＳｅｌｅｃｔＩｔｅｍ（項目選択）メッセージを引数としての選択肢の値とともに意味論モジュール２４０へ送信することができる。
【００５０】
使用コンテキスト２９０は、センサ２１０、２１２のプロパティおよびレイアウトを制御し、あるイベントについてユーザに通知することができる。一実施形態において、使用コンテキスト２９０は、ＴｅｘｔＩｎｐｕｔＱｕｅｒｙ（テキスト入力クエリー）を使用して、ユーザとの対話のためにテキスト要素２８０またはメニュー要素２８２を準備することができる。テキスト要素２８０は、ＥｄｉｔＴｅｘｔ（テキスト編集）メッセージをＱｕｅｒｙＦｌａｇ（クエリーフラグ）とともに意味論モジュール２４０に放出することによって応答し、テキスト要素２８０は編集の準備が整っていることを示すことができる。
【００５１】
使用コンテキスト２９０は、編集が開始される際のＳｔａｒｔＥｄｉｔ（編集開始）メッセージ、または編集が停止される際のＥｄｉｔＳｔｏｐ（編集停止）メッセージの傍受を通じて、テキスト要素２８０においていつテキスト編集が実行されるかを知ることもできる。使用コンテキスト２９０は、原理センサ２１０の様々なプロパティを制御し、あるイベントについてユーザに通知することもできる。
【００５２】
これらのイベントは、通知のタイプについての情報を含み得るＵｓｅｒＮｏｔｉｆｙ（ユーザ通知）メッセージを通じて誘発される。システムは、各タイプの通知を引き受けるためにアクションを解釈することができる。この解釈は、意味論モジュール２４０によって行われることができる。
【００５３】
原理センサ２１０は、環境における変数のセットをモニターし、離散的なメッセージを通じて結果をキーストロークモジュール２２０へ送信することができる。また、原理センサ２１０は、ユーザのアクションを検出することができ、当該アクションは、原理センサ２１０の幅内にあるユーザ指定の特定領域、ユーザにより行われる動作の配列、およびユーザの動作中断からなることができる。これらのアクションは、通常、ユーザとセンサとの間の直接の物理的接触、スタイラス、ペンなどのツールを使用した間接的な接触、または、眼球運動、レーザーポインタなどの物理的接触を含まない方法を含む。当業者であれば、原理センサ２１０を実装するための多種多様なオプションが存在することを認識するであろう。これらのオプションの例としては、視線追跡システム、タッチスクリーン、ジョイスティック、グラフィカルユーザインターフェイス、電子的または機械的形態の従来型キーボードなどが挙げられる。同様に、これらのセンシングデバイスは、ハードウェア、ソフトウェア、またはこれら２つの組み合わせにおいて実装できる。本開示の読了後には、原理センサ２１０とともに多種多様なレイアウトを利用してデータエントリのためのインターフェイスを提供できることも明らかになるであろう。
【００５４】
アーキテクチャ２００のコンポーネントの対話を深く探求する前に、接触を検出できるタイプの原理センサ２１０用レイアウトの一例を、図３に提示する。原理センサ２１０内では、オーバーラップしていないゾーン３００〜３９０を定義することができる。これらのゾーン３００〜３９０は、ユーザとの対話を助けるように指定されたキーゾーン３００、３１０〜３９０であってよい。これらのキーゾーン３００、３１０〜３９０は各行がキーゾーン３００、３１０〜３９０のうち１つ以上を含む行３１２、３１４のうち１つ以上に沿って配置されてよく、行は順に同心円の曲線に配置されてよい。キーゾーン３００、３１０〜３９０の行３１２、３１４の外側にあるゾーンは、キー無しゾーン３０２である。キーゾーン３００、３１０〜３９０のそれぞれは、一意識別子であって、行内および行間におけるキーゾーン３００、３１０〜３９０の場所によりキーゾーン３００、３１０〜３９０の順序付けを表す一意識別子に関連する。
【００５５】
例えば、行３１２、３１４は、最も奥から開始して小さいほうから大きいほうへ番号付けをしてよい。図３に描写されている例では、行３１４は行番号１、一方、行３１２は行番号２ということになる。キーゾーン３００、３１０〜３９０は、それぞれの行内において順序付けされてもよい。図３では、キーゾーン３００、３１０〜３９０に左から右へ番号を割り当ててあり、したがってゾーン３００、３５０に１の番号、ゾーン３２０、３６０に２の番号などをつけてよい。これらの行およびゾーン順序付けを使用して、原理センサ２１０を使用して実装される各ゾーンに一意識別子をアセンブルしてよい。この例では、キーゾーン３００は（２，１）となり、キーゾーン３５０は（１，１）、キーゾーン３６０は（１，２）などとして識別されることができる。当業者には容易にわかるように、原理センサ２１０内でゾーン３００〜３９０のセットを独自に識別するために多くのスキームを利用することができ、これらのゾーン３００〜３９０は特定のセンサのサイズ、デバイス、ユーザまたはその他任意の基準に適していると思われる様々なトポロジーにおいて定義づけられることができる。
【００５６】
原理センサ２１０は、環境をモニターし、ポイントされたゾーンまたはユーザによって接触されている接触ゾーンを判定することができる。このポイントされたゾーンは、接触が行われた地点または位置からなってよく、または実際の接触位置を取り囲んでいる定義された領域からなってもよい。接触が行われている場合、原理センサ２１０は、ゾーン３００〜３９０がポイントされたゾーンにオーバーラップしているか否かを判定することができる。ポインタされたゾーンにオーバーラップするゾーン３００〜３９０のそれぞれについて、原理センサ２１０はキーストローク論理２２０にメッセージを送信する。各メッセージは、接触の開始（ＳｔａｒｔＣｏｎｔａｃｔ（接触開始））およびゾーン３００〜３９０にオーバーラップするための各一意識別子を識別するメッセージであってよい。ポイントされたゾーンが移動し、その他任意のゾーン３００〜３９０にオーバーラップし始めると、ゾーン３００〜３９０が当該ゾーン３００〜３９０の一意識別子とともに入力されたことを示すメッセージがキーストローク論理２２０に送信される。接触が停止すると、原理センサ２１０は接触が停止されたことを感知し、これをキーストロークモジュール２２０に示す（ＳｔｏｐＣｏｎｔａｃｔ（接触停止））。したがって、原理センサは、接触の開始、この接触の動作、および接触の解放を感知することができる。このタイプのメッセージは、上述したタイプのメッセージを使用して原理センサ２１０とキーストロークモジュール２２０との間で交換できる。すべてのタイプの接触を原理センサ２１０によって判定できるが、それらすべてに関するメッセージはキーストロークモジュール２２０へ移動できない、またはユーザの接触を評価するのに使用できないことにも留意すべきである。
【００５７】
ゾーン３００〜３９０は、ゾーン３００〜３９０のレイアウト、ユーザの指定、ゾーン３００〜３９０に関連する意味論的な意味などに応じて、アクティブまたは非アクティブとして設計されることができる。ゾーン３００〜３９０が非アクティブとして設計されている場合、原理センサ２１０は非アクティブゾーンと連絡している原理センサの領域をポイントされたゾーンと比較することができず、したがって、非アクティブゾーンの一意識別子を含むメッセージはキーストローク論理２２０へ送信されないことになる。同様に、比較が行われることはできても、非アクティブゾーンの一意識別子を含むメッセージはキーストローク論理２２０へ送信されないことになる。
【００５８】
キーストローク論理２２０は、接触開始／停止メッセージの組を原理センサ２１０から区別する役割を果たすことができる。キーストローク論理２２０は、接触が行われているキーゾーン３００、３１０〜３９０の行番号およびキーゾーン３００、３１０〜３９０の行内における番号を判定するために、原理センサ２１０から生成されたメッセージを取得し、これらのメッセージを解釈することができる。また、キーゾーン３００、３１０〜３９０は、ユーザの接触の動作またはユーザの解放地点に応じていくつかのモードで誘発されることができ、キーストローク論理は、キーゾーン３００、３１０〜３９０が誘発されたモードを判定することもできる。これらのモードはＫｅｙＣｅｎｔｅｒ（キー中央）、ＫｅｙＬｏｗｅｒ（キー下）、ＫｅｙＵｐｐｅｒ（キー上）、ＲｏｗＬｏｗｅｒ（行下）およびＲｏｗＵｐｐｅｒ（行上）で示すことができる。これらのメッセージは、ユーザによる接触が最初に開始された場所に関して、ユーザの解放地点と一致する場合がある。
【００５９】
一実施形態において、原理センサ２１０からのメッセージは以下のアルゴリズムに従って処理することができる。
【００６０】
ＳｔａｒｔＣｏｎｔａｃｔ（接触開始）位置がキー無しである場合、キーストロークモジュールはその他いかなるアクティビティも行わずに次のＳｔａｒｔＣｏｎｔａｃｔ（接触開始）メッセージを待つ。
【００６１】
２つの変数：Ｒｏｗ（行）およびＫｅｙ（キー）がある。それぞれが値：Ｕｐｐｅｒ（上）、Ｌｏｗｅｒ（下）およびＳａｍｅ（同）をとることができる。
【００６２】
各ＳｔａｒｔＣｏｎｔａｃｔ（接触開始）（ｋｒ１，ｎ１）について（ここでｒ１はキーが所属する行であり、ｎ１は行中にキー番号である）：
Ｒｏｗ（行）をＳａｍｅ（同）に、Ｋｅｙ（キー）をＳａｍｅ（同）にセットする
次に各ＥｎｔｅｒＺｏｎｅ（エンターゾーン）（ｋｒ２，ｎ２）について：
ｒ２＞ｒ１の場合、Ｒｏｗ（行）をＵｐｐｅｒ（上）にセットする
ｒ２＜ｒ１の場合、Ｒｏｗ（行）をＬｏｗｅｒ（下）にセットする
ｒ２＝ｒ１の場合：
Ｒｏｗ（行）をＳａｍｅ（同）にセットし、さらに
ｎ２＞ｎ１の場合、Ｋｅｙ（キー）をＵｐｐｅｒ（上）にセットする
ｎ２＜ｎ１の場合、Ｋｅｙ（キー）をＬｏｗｅｒ（下）にセットする
ｎ２＝ｎ１の場合、Ｋｅｙ（キー）をＳａｍｅ（同）にセットする
ＳｔｏｐＣｏｎｔａｃｔ（接触停止）について：
Ｒｏｗ（行）がＳａｍｅ（同）と等しい場合：
Ｋｅｙ（キー）がＳａｍｅ（同）と等しい場合、
Ｉｎｐｕｔ（入力）（ｒ１，ｎ１，ＫｅｙＣｅｎｔｅｒ（キー中央））を放出する
Ｋｅｙ（キー）がＬｏｗｅｒ（下）と等しい場合、
Ｉｎｐｕｔ（入力）（ｒ１，ｎ１，ＫｅｙＬｏｗｅｒ（キー下））を放出する
Ｋｅｙ（キー）がＵｐｐｅｒ（上）と等しい場合、Ｉｎｐｕｔ（入力）（ｒ１，ｎ１，ＫｅｙＵｐｐｅｒ（キー上））を放出する
Ｒｏｗ（行）がｌｏｗｅｒ（下）と等しい場合、Ｉｎｐｕｔ（入力）（ｒ１，ｎ１，ＲｏｗＬｏｗｅｒ（行下））を放出する
Ｒｏｗ（行）がｕｐｐｅｒ（上）と等しい場合、Ｉｎｐｕｔ（入力）（ｒ１，ｎ１，ＲｏｗＵｐｐｅｒ（行上））を放出する。
【００６３】
次に図４を見ると、原理センサ２１０の実施形態で使用するための別のレイアウトが描写されている。図３に関連して記載されているレイアウトは完全に適正であるが、多くのゾーン３００〜３９０が存在している場合、接触が２つのゾーンの境界に近づいた際のユーザ接触の位置を判定するのは困難な場合がある。この困難を改善するために、原理センサ２１０のレイアウト４００は、ラッチ機構を実装するためのインターキーゾーン４００〜４７０を含むことができる。インターキーゾーン４００〜４７０は、２つのキーゾーン３００、３１０〜３９０が隣接しないようにキーゾーン３００、３１０〜３９０とインターリーブされる場合がある。これらのインターキーゾーン４００〜７００は一意識別子を有してもよく、原理センサ２１０はインターキーゾーン４１０〜４７０において接触が行われた時を感知し、対応するメッセージをキーストローク論理２２０へ送信することができる。インターキーゾーン４００〜４７０が存在している場合、以下のアルゴリズムに従って原理センサ２１０からのメッセージを処理することができる。
【００６４】
行番号ｘはラベル：（ｋｘ，１，ｉｘ，１，ｋｘ，２，ｉｘ，２，．．．，ｉｘ，ｙ−１，ｋｘ，ｙ）を持つゾーンから構成されており、ここでｙは行番号ｘのキーの番号である。ＳｔａｒｔＣｏｎｔａｃｔ（接触開始）位置がキー無しまたはインターキーゾーンであった場合、キーストロークモジュールは、その他いかなるアクティビティも行わずに次のＳｔａｒｔＣｏｎｔａｃｔ（接触開始）メッセージを待つ。
【００６５】
各ＳｔａｒｔＣｏｎｔａｃｔ（接触開始）（ｋｒ１，ｎ１）について：
Ｒｏｗ（行）をＳａｍｅ（同）に、Ｋｅｙ（キー）をＳａｍｅ（同）にセットする
各ＥｎｔｅｒＺｏｎｅ（エンターゾーン）（ｉｒ２，ｎ２）について、
ｒ２＝ｒ１の場合、
ｎ２＜ｎ１−１の場合、Ｒｏｗ（行）をＳａｍｅ（同）に、Ｋｅｙ（キー）をＬｏｗｅｒ（下）にセットする
ｎ１＞ｎ１の場合、Ｒｏｗ（行）をＳａｍｅ（同）に、Ｋｅｙ（キー）Ｕｐｐｅｒ（上）にセットする
ｒ２＜ｒの場合、Ｒｏｗ（行）をＬｏｗｅｒ（下）にセットする
ｒ２＞ｒの場合、Ｒｏｗ（行）をＵｐｐｅｒ（上）にセットする
各ＳｔａｒｔＣｏｎｔａｃｔ（接触開始）（ｋｒ２，ｎ２）について、
ｒ２＝ｒ１の場合、
ｎ２＝ｎ１の場合、Ｒｏｗ（行）をＳａｍｅ（同）に、Ｋｅｙ（キー）をＳａｍｅ（同）にセットする
ｎ２＜ｎ１の場合、Ｒｏｗ（行）をＳａｍｅ（同）に、Ｋｅｙ（キー）をＬｏｗｅｒ（下）にセットする
ｎ２＞ｎ１の場合、Ｒｏｗ（行）をＳａｍｅ（同）に、Ｋｅｙ（キー）をＵｐｐｅｒ（上）にセットする
ｒ２＜ｒ１の場合、Ｒｏｗ（行）をＬｏｗｅｒ（下）にセットする
ｒ２＞ｒ１の場合、Ｒｏｗ（行）をＵｐｐｅｒ（上）にセットする
第１のＳｔｏｐＣｏｎｔａｃｔ（接触停止）について、
Ｒｏｗ（行）がＳａｍｅ（同）と等しい場合
Ｋｅｙ（キー）がＳａｍｅ（同）と等しい場合、Ｉｎｐｕｔ（入力）（ｒ１，ｎ１，ＫｅｙＣｅｎｔｅｒ（キー中央））を放出する
Ｋｅｙ（キー）がＬｏｗｅｒ（下）と等しい場合、Ｉｎｐｕｔ（入力）（ｒ１，ｎ１，ＫｅｙＬｏｗｅｒ（キー下））を放出する
Ｋｅｙ（キー）がＵｐｐｅｒ（上）と等しい場合、Ｉｎｐｕｔ（入力）（ｒ１，ｎ１，ＫｅｙＵｐｐｅｒ（キー上））を放出する
Ｒｏｗ（行）がＬｏｗｅｒ（下）と等しい場合、Ｉｎｐｕｔ（入力）（ｒ１，ｎ１，ＲｏｗＬｏｗｅｒ（行下））を放出する
Ｒｏｗ（行）がＵｐｐｅｒ（上）と等しい場合、Ｉｎｐｕｔ（入力）（ｒ１，ｎ１，ＲｏｗＵｐｐｅｒ（行上））を放出する。
【００６６】
当業者には、任意の２つのゾーンまたはゾーンのセット間のラッチ機構を実装するために、インターキーゾーンを用いることができることが容易に明らかになるであろう。例えば、インターキーゾーンは、行３１２、３１４間のラッチ機構を実装するために用いられる場合がある。
【００６７】
図５では、本発明の実施形態で使用するためのユーザインターフェイス５００の詳細なレイアウトが提示されている。ユーザインターフェイス５００は、原理センサ２１０および情報をユーザに対して表示するテキストウィンドウ５１０を含んでよい。原理センサ２１０はゾーン５２０〜５４２のセットを含んでよい。ゾーンの各セットは、記号のセットをユーザに提示することができる。ゾーン５２０〜５２８のセットの１つは英語のキャラクタに相当する場合があり、一方、その他のゾーン５３０〜５４２は、ユーザインターフェイス５００が利用されているシステムのコンテキストまたはアーキテクチャに応じたその他の機能に相当する場合がある。これらのその他の機能は、コマンド機能またはメニュー機能を含んでよい。
【００６８】
図６は、英語に関連するゾーン５２０〜５２８のセットをより具体的に描写している。ゾーン５２０〜５２８は、ユーザインターフェイス５００が利用されているデバイスを保持している手の親指でゾーン５２０〜５２８を作動させることができるように、曲線に並べられる場合がある。描写されている実施形態において、ゾーン５２０〜５２８は、右利きの人により効率的に作動できるよう配置されている。しかしながら、上述のように、キーのランドスケープは、左手による効率的な作動を可能にするフォーマットを含む任意の望ましいフォーマットに変更することができる。各ゾーン５２０〜５２８は、上部の対６１０、中央の対６２０、および下部の対６３０にグループ化された最大６対の文字を含む。ユーザはゾーン５２０〜５２８を作動させることができ、原理センサはこの作動を検出し、この動作に対応するメッセージをキーストローク論理２２０へ送り、キーストローク２２０では、これらのメッセージを順にＩｎｐｕｔ（入力）メッセージに翻訳する。その後、意味論論理２４０は、このＩｎｐｕｔ（入力）メッセージを適切な文字の対と関連づける。
【００６９】
例えば、中央の対６２０を選択するためにユーザは望ましい対を持つゾーンに接触し、解放することができる。下部の対６３０のいずれかを選択するためにユーザは望ましい対を持つゾーンに接触し、任意のゾーンを望ましい対の方向にスライドすることができ、上部の対６１０を選択するにはその逆が成り立つ。この例をさらに説明するために、対（ｓ，ｈ）の文字が望ましいとする。この選択は、望ましい対（ｓ，ｈ）を含むゾーン５２６に接触すること、および対（ｂ，ｊ）に達するまで動作をスライドさせることによって達成することができる。動作は、望ましい対（ｓ，ｈ）を含むゾーン５２６より下にある任意のゾーン５２０〜５２４において停止する場合があることに留意されたい。意味論論理２４０は、この動作を望ましい対（ｓ，ｈ）に分割することもできる。
【００７０】
意味論論理２４０は、キーストロークモジュール２２０または追加センサ２１２からメッセージを受信し、このメッセージを、メッセージが受信されたコンテキストに応じて記号のセットまたはコマンドのセットに翻訳することができる。特定の一実施形態において、意味論論理２４０は、キーストローク論理２２０からＩｎｐｕｔ（入力）メッセージを受信し、これをコンテキストに従って考えられる記号のセットに翻訳する。例えば、図６に関連して上述したようなユーザ作動は、文字の対（ｓ，ｈ）に分割されることができる。この分割は、その後コア論理２５０へ送られることができる。意味論論理２４０は、システムのコンテキストに従ってシステムの入力および出力を調節することに関与する場合もある。
【００７１】
さらに特定の実施形態において、意味論モジュール２４０は、入力メッセージの記号またはコマンドへの翻訳に関与する場合がある。この翻訳は、コンテキスト、つまり、ＳｅｍａｎｔｉｆｙＣｏｎｔｅｘｔ（意味論化コンテキスト）と称される場合がある意味論モジュールによって必要とされるコンテキストの一部に依存に依存してよい。意味論モジュール２４０は、コンテキスト（ＳｅｍａｎｔｉｆｙＣｏｎｔｅｘｔ（意味論化コンテキスト））に従って記号を表す入力メッセージに対して、記号のセットを含むＳｙｍｂｏｌＭｅｓｓａｇｅ（記号メッセージ）で応答することができる。
【００７２】
入力メッセージがコマンドを表す場合、コマンドの一意識別子を含むメッセージ（ＣｏｍｍａｎｄＭｅｓｓａｇｅ（コマンドメッセージ））が放出される。この一意識別子情報は、ＢａｃｋＳｐａｃｅＣｍｄ（バックスペースコマンド）、ＥｎｄＬｅｘｉｃｏｎＣｍｄ（辞書終了コマンド）、ＩｔｅｍＳｅｌｅｃｔｉｏｎＣｍｄ（項目選択コマンド）、ＮｅｘｔＣｈａｒＣｍｄ（次のキャラクタコマンド）およびＰｒｅｖＣｈａｒＣｍｄ（前のキャラクタコマンド）を含む、望ましいコマンドに対応する値をとることができる。入力メッセージがコンテキスト（ＳｅｍａｎｔｉｆｙＣｏｎｔｅｘｔ（意味論化コンテキスト））に関するものを表さない場合、いかなるアクションも行われない。
【００７３】
入力メッセージは、記号のセットを表示するためにＳｙｍｂｏｌＭｅｓｓａｇｅ（記号メッセージ）がＣｏｍｍａｎｄＭｅｓｓａｇｅ（コマンドメッセージ）よりも前に送出されることができるような場合、コマンドおよび記号のセットの両方を表すことができる。意味論モジュール２４０は、センサ２１０、２１２の構成に関与する場合もある。
【００７４】
いくつかの実施形態において、テキスト要素２８０、メニュー要素２８２、またはユーザコンテキスト２９０からのメッセージは以下のように扱われる。
【００７５】
ＳｅｌｅｃｔＩｔｅｍ（項目選択）は、コマンド識別子およびＳｅｌｅｃｔＩｔｅｍ（項目選択）の引数として、ＩｔｅｍＳｅｌｅｃｔｉｏｎＣｍｄ（項目選択コマンド）を持つＣｏｍｍａｎｄＭｅｓｓａｇｅ（コマンドメッセージ）の放出を誘発する。
【００７６】
前回のＥｎｄＥｄｉｔ（編集終了）メッセージが前回のＳｔａｒｔＥｄｉｔ（編集開始）よりも後であった場合、ＳｔａｒｔＥｄｉｔ（編集開始）の受信はＥｄｉｔＴｅｘｔ（テキスト編集）メッセージを誘発する。前回のＳｔａｒｔＥｄｉｔ（編集開始）が前回のＥｎｄＥｄｉｔ（編集終了）よりも後であった場合、ＥｎｄＥｄｉｔ（編集終了）の受信は、引数ＥｎｄＬｅｘｉｃｏｎＣｍｄ（辞書終了コマンド）を持つＣｏｍｍａｎｄＭｅｓｓａｇｅ（コマンドメッセージ）のコア論理２５０への放出を誘発する。
【００７７】
前回のＥｎｄＥｄｉｔ（編集終了）メッセージが前回のＳｔａｒｔＥｄｉｔ（編集開始）よりも後である場合に意味論モジュール２４０がＳｙｍｂｏｌＭｅｓｓａｇｅ（記号メッセージ）を送信する直前であれば、意味論モジュール２４０はＳｙｍｂｏｌＭｅｓｓａｇｅ（記号メッセージ）の送信を一時停止し、ユーザコンテキスト２９０へメッセージＴｅｘｔＩｎｐｕｔＱｕｅｒｙ（テキスト入力クエリー）を送信する。次に受信されたメッセージがＱｕｅｒｙＦｌａｇ（クエリーフラグ）に関連するＥｄｉｔＴｅｘｔ（テキスト編集）であった場合、意味論モジュール２４０はＥｄｉｔＴｅｘｔ（テキスト編集）メッセージをコア論理２５０へ転送し、一時停止していたＳｙｍｂｏｌＭｅｓｓａｇｅ（記号メッセージ）を送信する。
【００７８】
ＳｅｍａｎｔｉｆｙＣｏｎｔｅｘｔ（意味論コンテキスト）は、（アーキテクチャコンポーネントまたは外部のいずれかから）前回受信したメッセージおよび引数としての前のＳｅｍａｎｔｉｆｙＣｏｎｔｅｘｔ（意味論化コンテキスト）によって呼び出されたＣｏｎｔｅｘｔＧｅｎｅｒａｔｉｏｎ（コンテキスト生成）機能の付加的な結果であってよい。任意の２つのメッセージ間で、ＳｅｍａｎｔｉｆｙＣｏｎｔｅｘｔ（意味論化コンテキスト）は矛盾しない状態のままである。
【００７９】
次に、意味論モジュール２４０によって用いられるコア論理２５０についてであるが、図７ではコア論理２５０によって用いられる基本的な方法論を描写している。コア論理２５０は、必要に応じて、入力のセットを取得し（ブロック７１０）、処理規則を適用し（ブロック７２０）、出力を返す（ブロック７３０）ことができる。コア論理２５０は、入力のセットを取得する（ブロック７１０）ことができ、これらの入力は、コア論理２５０によって内部で生成されてよく、または原理センサ２１０を通じたユーザからのものであってもよい。入力は、意味論モジュール２４０からコア論理２５０によって受信（ブロック７１０）されることもできる。上述のように、ある状況において、意味論モジュール２４０は、自身が受信したメッセージおよび操作されているコンテキストに応じてメッセージのセットを生成することができる。意味論モジュール２４０は、これらのメッセージをコア論理２５０へ送ることができ、コア論理２５０はこれらのメッセージを順に入力のセットとして取得することができる（ブロック７１０）。いくつかの実施形態において、この入力は記号またはコマンドを表すメッセージであってよい。また、これらのメッセージは、接頭辞および接頭辞に関連する記号の配列を含んでよい。
【００８０】
コア論理２５０はこの入力のセットを取得し（ブロック７１０）それらを特定の規則のセットに従って処理する（ブロック７２０）ことができる。この処理は、命題の系統的論述を含むことができ、この系統的論述は、記号、語、キャラクタの任意配列、または任意の組み合わせであってよい。この命題は、入力の多義性解消、予測補完または予測、もしくはその２つのいくつかの組み合わせに関連する、またはこれらから派生したものであってよい。
【００８１】
入力のセットを処理する（ブロック７２０）ためにコア論理２５０が使用する規則は、言語モデル２６０および使用法モデル２８０を利用して候補または予測のセットを提供し、これらの候補または予測を評価して、うち１つ以上がユーザに対し提示され得る命題のセットを生成するように設計されることができる。一実施形態において、コア論理２５０は、入力を処理する（ブロック７２０）ためにスコアリングシステムを使用する。コア論理が入力を受信した際、入力が接頭辞を有さない場合は、スコアリングシステムによって１つ以上の命題が生成され、評価されることができる。しかしながら、接頭辞が存在している場合、配列は接頭辞に新たな入力を付加し、この配列に基づいて１つ以上の候補を生成および評価するよう試みることによって生成されることができる。候補が生成できない場合、または生成された候補がいくつかの閾値スコアを超えない場合、入力を特定するための方法が提供されることができ、そうでなければ、候補が評価され、予測が作成され、この評価に基づいて命題が形成されてユーザに対し提示されることができる。命題は、もとの入力の多義性解消を踏まえ、構築することもできる。
【００８２】
一部の実施形態において、コア論理２５０は、入力に基づいて候補を構築し、１つ以上の候補から予測を判定し、生成された候補および予測のセットからユーザに提示するための命題を構築することができる。
【００８３】
いくつかの実施形態において、コア論理２５０によって利用される規則およびアルゴリズムは、推測規則、一義的規則、および内的規則という３つのカテゴリに分類することができる。一義的規則および推測規則はコア論理２５０のメインドライバであってよく、一方、内的規則はコア論理２５０の背後で制御機能性としての役割を果たすことができ、推測および一義的規則のセットの使用、これら２つの規則セットの評価、またはこれらの規則のセットからの応答に関与する機能性を提供することができる。また、内的規則は、ユーザに示される接頭辞または命題の作成に関与する場合がある。
【００８４】
これらの内的規則は、望ましい機能性および規則が利用されているコンテキストに応じ、一義的規則および推測機能と連動して正常に機能することができる。これらの規則は、様々なコンテキストにおけるシステムの挙動を記述することができ、またユーザの希望または内的状況に基づいて利用されることができる。一義的規則は、ユーザまたは意味論モジュール２４０のいずれかから受信した入力が多義的である、もしくは適正な候補がない場合の挙動を記述することができる。一部の実施形態において、これらの一義的規則は、言語モデル２６０のみを用いる。推測規則は、適切な候補が見つかった場合の挙動を記述することができ、実施形態においては言語モデル２６０および使用法モデル２８０の両方を用いることができる。
【００８５】
特定の一実施形態において、コア論理モジュール２５０は意味論モジュール２４０からＣｏｍｍａｎｄＭｅｓｓａｇｅ（コマンドメッセージ）またはＳｙｍｂｏｌＭｅｓｓａｇｅ（記号メッセージ）を受信する。コア論理２５０は規則のセットに従ってそれらのメッセージに応答する。コア論理２５０の規則がユーザとの通信を示す場合、意味論モジュール２５０は、ユーザとのインターフェイスで使用される、対応するメッセージの配信に使用される。
【００８６】
この実施形態において、コア論理２５０の残りの規則は、１）システムが入力に関する適切な命題を有する場合のコア論理２５０挙動を記述する推測規則；２）入力が多義的である場合にシステムがどのように挙動するか、およびシステムが入力に関する適切でない命題をどのように推測できるかを記述する一義的規則；一義的規則における推測の評価に必要ないくつかの機能を含む内的規則、という３つの表題のもとに整理される。
【００８７】
これらの各規則について、以下でさらに説明する。
【００８８】
すべての規則に共通の変数：
ＣｕｒｒｅｎｔＲｕｎ（現在起動中）は、記号の配列である。
【００８９】
ＣｕｒｒｅｎｔＰｒｏｐｏｓｉｔｉｏｎＳｅｔ（現在の命題セット）は、データ構造に格納され得る命題のセットであり、以下のコードで表される：
ｔｙｐｅｄｅｆ  ｓｔｒｕｃｔ｛
Ｃｈａｒ＊  ｒｕｎ；
Ｉｎｔ  ｃｏｕｎｔ：｝  Ｐｒｏｐｏｓｉｔｉｏｎ；
ＩｎｐｕｔＳｅｑｓ（配列入力）は、記号セットの配列セットである
ＥｄｉｔｉｏｎＳｔａｔｅ（版状態）は、２つの値をとることができる：ＧｕｅｓｓｉｎｇＳｔａｔｅ（推測状態）およびＵｎａｍｂｉｇｕｏｕｓＳｔａｔｅ（一義的状態）
ＦｉｎａｌＳｅｑ（最終配列）は、記号の配列またはＵｎｄｅｆｉｎｅｄ（未定義）である
ＣｕｒｒｅｎｔＳｙｍ（現在の記号）は、整数である
ＥｄｉｔＴｅｘｔ（テキスト編集）メッセージを受信すると、コア論理２５０は以下で応答する：
ＳｔａｒｔＥｄｉｔ（編集開始）メッセージをテキスト要素へ送信する
ＥｄｉｔＴｅｘｔ（テキスト編集）接頭辞が空の場合、
ＣｕｒｒｅｎｔＰｒｏｐｏｓｉｔｉｏｎＳｅｔ（現在の命題セット）は空のセットに設定されている；
ＩｎｐｕｔＳｅｑｓ（配列入力）は空のセットに設定されている；
規則ＳｈｏｗＰｒｏｐｏｓｉｔｉｏｎｓ（命題を示す）が評価される；
そうでなければ
ＮｅｗＰｒｅｆｉｘ（新しい接頭辞）が引数ＥｄｉｔＴｅｘｔ（テキスト編集）接頭辞で評価される；
ＣｕｒｒｅｎｔＰｒｏｐｏｓｉｔｉｏｎＳｅｔ（現在の命題セット）が空の場合、
ＥｄｉｔｉｏｎＳｔａｔｅ（版状態）はＵｎａｍｂｉｇｕｏｕｓＳｔａｔｅ（一義的状態）に設定される；
ＩｎｉｔＵｎａｍｂｉｇｕｏｕｓ（一義的開始）が評価される；
そうでなければ
規則ＳｈｏｗＰｒｏｐｏｓｉｔｉｏｎｓ（命題を示す）が評価される；。
【００９０】
このアルゴリズムは、新たな入力のためにコア論理２５０の状態を初期化する。初期化は接頭辞がない場合には平易である。接頭辞が提供される場合、アルゴリズムは、言語モデル２６０を利用して接頭辞の補完可能である最長の部分ストリングのルックアップを試みるように設計される。言語モデル２６０は、そのような部分ストリングを含まず、アルゴリズムは一義的入力モードに切り替わる。
【００９１】
ｉ．Ｇｕｅｓｓｉｎｇ  Ｒｕｌｅｓ（推測規則）
推測規則が当てはまるのは以下の場合である。
ＥｄｉｔｉｏｎＳｔａｔｅ（版状態）＝ＧｕｅｓｓｉｎｇＳｔａｔｅ（推測状態）である。このセクションの規則が、一意定数Ａｄｄ（加算）を有する。コア論理２５０に到達する各タイプのメッセージのための規則がある：
ＳｙｍｂｏｌＭｅｓｓａｇｅ（記号メッセージ）は記号のリストとしてＳ＝（Ｓ１，．．．，Ｓｔ）とｔ≧１を有し、
ＩｎｐｕｔＳｅｑｓ（配列入力）をＩｎｐｕｔＳｅｑｓ（配列入力）と（Ｓ）の連結に設定する
ＣｕｒｒｅｎｔＲｕｎ（現在起動中）が空でない場合、新たなＰｒｅｆｉｘ（接頭辞）（ＣｕｒｒｅｎｔＲｕｎ（現在起動中））を評価し、ＣｕｒｒｅｎｔＲｕｎ（現在起動中）を空に設定する
ＣｕｒｒｅｎｔＰｒｏｐｏｓｉｔｉｏｎＳｅｔ（現在の命令セット）が空である場合、
ＥｄｉｔｉｏｎＳｔａｔｅ（版状態）はＵｎａｍｂｉｇｕｏｕｓＳｔａｔｅ（一義的状態）に設定されている；
ＩｎｉｔＵｎａｍｂｉｇｕｏｕｓ（一義的開始）が評価される；
そうでなければ
ＣｕｒｒｅｎｔＰｒｏｐｏｓｉｔｉｏｎＳｅｔ（現在の命令セット）が空である場合：
ＬはＮｏｄｅ｛Ｌ１，…，Ｌｎ｝タイプの非同一要素の最大セットであり、ここで｛１，．．．，ｎ｝の各ｉ部分は：
Ｌｉ．ｃ＝Ｓｊで、ｊ部分は｛１，．．．，ｔ｝である
ＩｓＩｎＳｕｂｔｒｅｅ（サブツリー内である）（Ｌｉ．ｌｏｃａｔｉｏｎ，累乗根）
Ｐは、各ｉ部分が｛１，．．，ｍ｝であるような命題（Ｐ１，．．．，Ｐｍ）の最小セットである：
Ｐｉ．ｒｕｎ＝（Ｌｉ．ｃ）であり、Ｐｉ．ｃｏｕｎｔ＝Ｌｉ．ｃｏｕｎｔである
ＰＦ＝ＦｉｌｔｅｒＰｒｏｐｏｓｉｔｉｏｎ（フィルタ命題）（Ｐ）
ＰＦが空である場合：
ＥｄｉｔｉｏｎＳｔａｔｅ（版状態）を、ＵｎａｍｂｉｇｕｏｕｓＳｔａｔｅ（一義的状態）に設定する
ＩｎｉｔＵｎａｍｂｉｇｕｏｕｓ（一義的開始）を評価する
そうでなければ：
ＣｕｒｒｅｎｔＰｒｏｐｏｓｉｔｉｏｎＳｅｔ（現在の命題セット）をＰＦに設定する
ＳｈｏｗＰｒｏｐｏｓｉｔｉｏｎｓ（命題を示す）を評価する
クリックによりＵｓｅｒＮｏｔｉｆｙ（ユーザ通知）メッセージを引数として放出する
そうでなければ：
ｃｕｒｒｅｎｔＰｒｏｐｏｓｉｏｎｔＳｅｔ（現在の命題セット）は｛ＣＰ１，．．．，ＣＰｍ｝に設定されている
ＴｅｍｐＬｏｃａｔｉｏｎＳｅｔ（一時位置セット）は非同一Ｎｏｄｅ（ノード）要素｛（Ｌ１，Ｘ１，Ｙ１，Ｃｏｕｎｔ１），…，（Ｌｎ，Ｘｎ，Ｙｎ，Ｃｏｕｎｔｎ）｝の最大セットであり、ここで｛１，．．，ｎ｝の各ｉ部分について：
Ｌｉ．ｃ＝Ｓｊで、ｊ部分は｛１，…，ｔ｝である
ＹｉはＣＰｊで、ｊは｛１，ｍ｝内である
ＸｉはＮｏｄｅ（ノード）（Ｎ１，．．．，Ｎｍ）の最長配列であり、ここで：
（Ｎ１．ｃ，…，Ｎｍ．ｃ）はＹｉ．ｒｕｎの空値でない接尾辞を形成する
ＩｓＩｎＳｕｂｔｒｅｅ（サブツリー内である）（Ｎ１，累乗根）
ＩｓＩｎＳｕｂｔｒｅｅ（サブツリー内である）（Ｌｉ，Ｎｍ）
Ｃｏｕｎｔｉ＝ＥｘｔｅｎｄＰｒｏｐｏｓｉｔｉｏｎ（拡張命題）（Ｌｉ，ＣＰｊ．ｃｏｕｎｔ）
ＰＦは命題（ＰＦＰ１，…，ＰＦＰｎ）の配列であり、ここで｛１，．．．，ｎ｝内の各ｉについて：
ＰＦＰｉ．ｒｕｎはＹｉ．ｒｕｎとＬｉ．ｃの連結に等しい
ＰＦ２＝ＦｉｌｔｅｒＰｒｏｐｏｓｉｔｉｏｎ（フィルタ命題）（ＰＦ）である
ＰＦ２が空の場合：
ＥｄｉｔｉｏｎＳｔａｔｅ（版状態）をＵｎａｍｂｉｇｕｏｕｓＳｔａｔｅ（一義的状態）に設定する
ＩｎｉｔＵｎａｍｂｉｇｕｏｕｓ（一義的開始）を評価する
そうでなければ
ＣｕｒｒｅｎｔＰｒｏｐｏｓｉｔｉｏｎＳｅｔ（現在の命題セット）はＰＦ２に設定されており、ここで｛１，．．．，ｎ｝内の各ｉについて：
ＳｈｏｗＰｒｏｐｏｓｉｔｉｏｎｓ（命題を示す）を評価する
クリックによりＵｓｅｒＮｏｔｉｆｙ（ユーザ通知）メッセージを引数として放出する
注記：ＳｙｍｂｏｌＭｅｓｓａｇｅ（記号メッセージ）に関するこれらの規則は、ユーザ入力を処理し、ユーザ入力が多義的であるか否かに関わらず、前回のＥｄｉｔＴｅｘｔ（テキスト編集）メッセージ以降に受信したすべての情報に基づいてユーザが入力したい記号配列がどれであるかを見つけようとすることができる。
【００９２】
ＣｏｍｍａｎｄＭｅｓｓａｇｅ（コマンドメッセージ）
メッセージに含まれるコマンド識別子に応じて、以下のアクションがとられる：
ＢａｃｋＳｐａｃｅＣｍｄ（バックスペースコマンド）
ＩｎｐｕｔＳｅｑｓ（配列入力）が空の配列である場合、
ＥｄｉｔＳｔｏｐ（編集停止）メッセージがＵｓｅＣｏｎｔｅｘｔ（使用コンテキスト）に送信される
そうでなければ
Ｒｅｐｌａｙ（リプレイ）は、入力配列（Ｓ１，．．．，Ｓｎ）をともなう配列（ＥｄｉｔＴｅｘｔ（テキスト編集）（），ＳｙｒｎｂｏｌＭｅｓｓａｇｅ（記号メッセージ）（Ｓ１），．．．，ＳｙｍｂｏｌＭｅｓｓａｇｅ（記号メッセージ）（Ｓｎ−２））である。
ＣｕｒｒｅｎｔＰｒｏｐｏｓｉｔｉｏｎＳｅｔ（現在の命題セット）およびＩｎｐｕｔＳｅｑｓ（配列入力）は、空のセットに設定される。ＣｏｒｅＬｏｇｉｃ（コア論理）は、ＳｙｍｂｏｌＭｅｓｓａｇｅ（記号メッセージ）の引数としてＲｅｐｌａｙ（リプレイ）の要素を自身にのみ相次いで送信し、その他のモジュールにメッセージを放出するのを防止する。最後にＳｙｍｂｏｌＭｅｓｓａｇｅ（記号メッセージ）（Ｓｎ−１）が送信される
注記：これらの規則は、前回の破棄されなかったＳｙｍｂｏｌＭｅｓｓａｇｅ（記号メッセージ）が発生する前にコア論理２５０を前の状態に戻すことができる。
【００９３】
ＥｎｄＬｅｘｉｃｏｎＣｍｄ（辞書終了コマンド）
ＣｕｒｒｅｎｔＲｕｎ（現在起動中）がＡｄｄ（加算）と等しい場合、
ＥｄｉｔｉｏｎＳｔａｔｅ（版状態）をＵｎａｍｂｉｇｕｏｕｓＳｔａｔｅ（一義的状態）に設定する
ＩｎｉｔＵｎａｍｂｉｇｕｏｕｓ（一義的開始）を評価する
そうでなければ
ＣｕｒｒｅｎｔＲｕｎ（現在起動中）が空であり、かつＣｕｒｒｅｎｔＰｒｏｐｏｓｉｔｉｏｎＳｅｔ（現在の命令セット）が（Ｐ，．．．）の形態をとる場合、ＣｕｒｒｅｎｔＲｕｎ（現在起動中）をＰ．ｒｕｎに設定する
ＳｕｂｓｔｉｔｕｔｅＴｅｘｔ（代用テキスト）を引数ＣｕｒｒｅｎｔＲｕｎ（現在起動中）とともに送信する
ＥｄｉｔＥｎｄ（編集終了）メッセージがユーザコンテキストおよび意味論モジュールへ送信される
引数としてのＣｕｒｒｅｎｔＲｕｎ（現在起動中）でＳｔｏｒｅＷｏｒｄ（語格納）規則を評価する
注記：ユーザがこのメニュー内で提案（Ａｄｄ（加算））を選択した場合、この規則はコア論理２５０規則を一義的モードに切り替え、そうでなければ、この規則は環境をクリーンアップして、ユーザによる前回のＳｔａｒｔＥｄｉｔ（編集開始）以降に作成された記号配列を考慮する。
【００９４】
ＩｔｅｍＳｅｌｅｃｔｉｏｎＣｍｄ（項目選択コマンド）
メニュー中でハイライトされた項目がコマンドＡｄｄ（加算）の場合：
ＣｕｒｒｅｎｔＲｕｎ（現在起動中）をＡｄｄ（加算）に設定する
ＣｕｒｒｅｎｔＰｒｏｐｏｓｉｔｉｏｎＳｅｔ（現在の命題セット）が（Ｐ．．．）である間に、ＳｕｂｓｔｉｔｕｔｅＴｅｘｔ（代用テキスト）を引数Ｐ．ｃとともに送信する
そうでなければ：
ＣｕｒｒｅｎｔＲｕｎ（現在起動中）をＰｒｏｐｏｓｉｔｉｏｎＳｅｌｅｃｔ（命題選択）の引数に設定する
ＳｕｂｓｔｉｔｕｔｅＴｅｘｔ（代用テキスト）メッセージをＣｕｒｒｅｎｔＲｕｎ（現在起動中）とともにテキストフィールドへ送信する
ＳｈｏｗＲｕｌｅｓ（規則を示す）を評価する
注記：ユーザは、ＴｅｘｔＥｌｅｍｅｎｔ（テキスト要素）内に表示させたい入力として、命題のうち１つを選択することができる。
【００９５】
Ｕｎａｍｂｉｇｕｏｕｓ  Ｒｕｌｅｓ（一義的規則）
Ｇｕｅｓｓｉｎｇ  ｒｕｌｅｓ（推測規則）のもとにインデックスを付けられた規則は、
ＥｄｉｔｉｏｎＳｔａｔｅ（版状態）＝ＵｎａｍｂｉｇｕｏｕｓＳｔａｔｅ（一義的状態）である場合に当てはまる。
【００９６】
ＩｎｉｔＵｎａｍｂｉｇｕｏｕｓ（一義的開始）
ＵｓｅｒＮｏｔｉｆｉｃａｔｉｏｎ（ユーザ通知）（エラー）を放出する
ＣｕｒｒｅｎｔＳｙｍ（現在の記号）を１に設定する
ＩｎｐｕｔＳｅｑｓ（配列入力）が形態（Ｓ１，…，Ｓｎ）を有する場合、ＦｉｎａｌＳｅｑ（最終配列）をｎ要素の配列に設定する
Ｕｎｄｅｆｉｎｅｄ（未定義）
ＳｈｏｗＵｎａｍｂｉｇｕｏｕｓ（一義的を示す）を評価する
ＳｔａｒｔＡｍｂｉｇｕｏｕｓＩｎｐｕｔ（多義的入力を開始する）をＳｅｍａｎｔｉｆｙ（意味論化）モジュールへ送信する。
【００９７】
ＳｙｍｂｏｌＭｅｓｓａｇｅ（信号メッセージ）は、
引数として配列Ｓを有する
ＩｎｐｕｔＳｅｑｓ（配列入力）は形態（Ｓ１，．．．，Ｓｎ）を有し、ＩｎｐｕｔＳｅｑｓ（配列入力）を配列（Ｓ１，．．．，Ｓｎ，Ｓ）に設定する
ＦｉｎａｌＳｅｑ（最終配列）は形態（Ｆｌ，．．．，Ｆｎ）を有し、ＦｉｎａｌＳｅｑ（最終配列）を配列（Ｆ１，…，Ｆｎ，Ｕｎｄｅｆｉｎｅｄ（未定義））に設定する
ＳｈｏｗＵｎａｍｂｉｇｕｏｕｓ（一義的を示す）を評価する。
【００９８】
ＣｏｎｍａｎｄＭｅｓｓａｇｅ（コマンドメッセージ）
ＢａｃｋＳｐａｃｅＣｍｄ（バックスペースコマンド）
ＩｎｐｕｔＳｅｑｓ（配列入力）が形態（Ｓ）である場合：
ＳｕｂｓｔｉｔｕｔｅＴｅｘｔ（代用テキスト）を引数として空の配列とともに送信する
ＥｄｉｔＥｎｄ（編集終了）メッセージをユーザコンテキストおよび意味論化モジュールへ送信する
そうでなければ：
ＩｎｐｕｔＳｅｑｓ（配列入力）が形態（Ｓ１，．．．，Ｓｎ）である場合、ＩｎｐｕｔＳｅｑｓ（配列入力）を（Ｓ１，．．．，Ｓｎ−１）に設定する
ＦｉｎａｌＳｅｑ（最終配列）が形態（Ｆ１，…，Ｆｎ）である場合、ＦｉｎａｌＳｅｑ（最終配列）を（Ｆ１，…，Ｆｎ−１）に設定する。
【００９９】
ＥｎｄｌｅｘｉｃｏｎＣｍｄ（辞書終了コマンド）
ＳｕｂｓｔｉｔｕｔｅＴｅｘｔ（代用テキスト）メッセージをＣｕｒｒｅｎｔＲｕｎ（現在起動中）とともにテキストフィールドへ送信する
ＥｄｉｔＥｎｄ（編集終了）メッセージがユーザコンテキストおよび意味論化モジュールへ送信される
引数としてのＣｕｒｒｅｎｔＲｕｎ（現在起動中）でＳｔｏｒｅＷｏｒｄ（語格納）規則を評価する。
【０１００】
ＩｔｅｍＳｅｌｅｃｔｉｏｎＣｍｄ（項目選択コマンド）は、
引数としてＡを有する
ＡがＤｏｎｅ（完了）と等しい場合、
ＳｕｂｓｔｉｔｕｔｅＴｅｘｔ（代用テキスト）メッセージをＣｕｒｒｅｎｔＲｕｎ（現在起動中）とともにテキストフィールドへ送信する
ＥｄｉｔＥｎｄ（編集終了）メッセージがユーザコンテキストおよび意味論化モジュールへ送信される
ＳｔｏｒｅＷｏｒｄ（語格納）規則を引数としてＣｕｒｒｅｎｔＲｕｎ（現在起動中）によって評価する
そうでなければ：
（Ｆ１，…，Ｆｃｕｒｒｅｎｔｓｙｍ−１，Ｆｃｕｒｒｅｎｔｓｙｍ，  Ｆｃｕｒｒｅｎｔｓｙｍ＋１，…，Ｆｎ）の形態をとるＦｉｎａｌ  Ｓｅｑ（最終配列）は（Ｆ１，…，Ｆｃｕｒｒｅｎｔｓｙｍ−１，Ａ，Ｆｃｕｒｒｅｎｔｓｙｍ＋１，…，Ｆｎ）に設定される
ＣｕｒｒｅｎｔＳｙｍ（現在の記号）をＣｕｒｒｅｎｔＳｙｍ（現在の記号）＋１に設定する
ＳｈｏｗＵｎａｍｂｉｇｕｏｕｓ（一義性を示す）を評価する。
【０１０１】
ＰｒｅｖＣｈａｒＣｍｄ（前のキャラクタコマンド）
ＣｕｒｒｅｎｔＳｙｍ（現在の記号）＝１の場合、ＵｓｅｒＮｏｔｉｆｙ（ユーザ通知）（エラー）を放出し、そうでなければＣｕｒｒｅｎｔＳｙｍ（現在の記号）＝ＣｕｒｒｅｎＳｙｍ（現在の記号）−ｌである。
【０１０２】
ＮｅｘｔＣｈａｒＣｍｄ（次のキャラクタコマンド）
ＣｕｒｒｅｎｔＳｙｍ（現在の記号）がＩｎｐｕｔＳｅｑ（配列入力）の長さと等しくない場合、ＵｓｅｒＮｏｔｉｆｙ（ユーザ通知）（エラー）を放出し、そうでなければ、ＣｕｒｒｅｎｔＳｙｍ（現在の記号）＝ＣｕｒｒｅｎＳｙｍ（現在の記号）＋１である。
【０１０３】
ｉｉｉ  Ｉｎｔｅｒｎａｌ  Ｒｕｌｅｓ（内的規則）
このセクションで説明する規則は、「Ｕｎａｍｂｉｇｕｏｕｓ  Ｒｕｌｅｓ」および「Ｇｕｅｓｓｉｎｇ  Ｒｕｌｅｓ（推測規則）」を評価する際に明示的に呼び出される。
【０１０４】
ＳｈｏｗＵｎａｍｂｉｇｒｕｏｕｓ（一義的を示す）
ＩｎｐｕｔＳｅｑ（配列入力）は（（Ｓ１，１，…，Ｓ１，Ｍ（１）），…，（Ｓｎ，１，…，Ｓｎ，Ｍ（ｎ）））の形態をとり、ここでＭ（ｘ）はＩｎｐｕｔＳｅｑ（配列入力）のｘｔｈ要素の長さを与える機能である。ＦｉｎａｌＳｅｑ（最終配列）は（Ｆ１，…，Ｆｎ）の形態をとり、ここで各ＦｉはＵｎｄｅｆｉｎｅｄ（未定義）または（Ｓｉ，１，…，Ｓｉ，Ｍ（ｉ））の要素の１つに等しい。Ｃは配列（Ｃ１，…，Ｃｎ）の１つであり、ここで｛１，．．．，ｎ｝内の各ｉについて：
Ｆｉ≠Ｕｎｄｅｆｉｎｅｄ（未定義）の場合Ｃｉ＝Ｆｉであり、そうでなければ、Ｃｉは（Ｓｉ，１，…，Ｓｉ，Ｍ（ｉ））内である
最大Ｑｕｏｔａｔｉｏｎｎは以下のようになる：
Ｃｉ＝Ｌ．ｃで、ＩｓｌｎＳｕｂｔｒｅｅ（サブツリー内である）（Ｌ，累乗根）であればＱｕｏｔａｔｉｏｎ１＝Ｌ．ｃｏｕｎｔ、そうでなければ、Ｑｕｏｔａｔｉｏｎｌ＝０である。
【０１０５】
｛２，…，ｎ｝内のｉはＱｕｏｔａｔｉｏｎｎ＝Ａｃｃｕｍｕｌａｔｅ（積算）（Ｑｕｏｔａｔｉｏｎｉ−１，Ｌ．ｃｏｕｎｔ）ここで、Ｌ＝ＮｏｄｅＦｒｏｍＰａｔｈ（パスからのノード）（Ｃｉ−ｊ，…，Ｃｉ）であり、最大Ｊを持つ
ＣｕｒｒｅｎｔＲｕｎ（現在起動中）をｃに設定する
ＭｅｎｕＳｅｔ（メニュー設定）メッセージを引数（Ｓｃｕｒｒｅｎｔｓｙｍ，１，…，Ｓｃｕｒｒｅｎｓｙｍ，Ｍ（１），  ，Ｄｏｎｅ（完了））とともに送信する。
【０１０６】
Ａｃｃｕｍｕｌａｔｅ（積算）およびＩｎｖａｒｉａｎｔ（不変条件）は、処理系依存方式で定義されることができ、当業者には本開示の読了後、これが明らかになるであろう。
【０１０７】
ＮｅｗＰｒｅｆｉｘ（新しい接頭辞）は、
引数としてｓ＝（Ｃ１…Ｃｒ）を有する
ＩｎｐｕｔＳｅｑｓ（配列入力）を配列（｛Ｃ１｝，…，｛Ｃｒ｝）に設定する
Ｐは、以下のような命題である：
ｐ．ｒｕｎ＝ｓ，ｐ．ｃｏｕｎｔ＝Ｉｎｖａｒｉａｎｔ（不当条件）
（Ｎ１，…，Ｎｍ）の最長配列
ここで：
［１，ｍ−１］内のｉを持つＩｓｌｎＳｕｂｔｒｅｅ（サブツリー内である）（Ｎｉ，Ｎｉ＋１）
Ｎｍ＝累乗根
［１，ｍ−１］内のｉを持つ各Ｎｉについて、Ｎｉ．ｃ＝Ｃｒ−ｍ＋ｉである
Ｐが存在する場合、
ＣｕｒｒｅｎＰｒｏｐｏｓｉｔｉｏｎＳｅｔ（現在の命令セット）をＦｉｌｔｅｒＰｒｏｐｏｓｉｔｉｏｎ（フィルタ命題）（｛Ｐ｝）に設定する
そうでなければ
ＣｕｒｒｅｎｔＰｒｏｐｏｓｉｔｉｏｎＳｅｔ（現在の命令セット）を空に設定する。
【０１０８】
ＳｈｏｗＰｒｏｐｏｓｉｔｉｏｎｓ（命題を示す）規則
ＣｕｒｒｅｎｔＰｒｏｐｏｓｉｔｉｏｎＳｅｔ（現在の命題セット）は、形態｛Ｐ１，．．．，Ｐｎ｝である
ＵＰは、｛１，．．．，ｎ｝内のｉについて以下のようになるセットである：
配列ＰｒｅｄＡ（（ＰｒＡ１，ＣＡ１，ＳｙｍＡ１），…，（ＰｒＡｍ，ＣＡｍ，ＳｙｍＡｍ））はＣｅｔＳｕｇｅｓｔｉｏｎｓ（サジェスチョンを取得）（Ｐｉ．ｒｕｎ）と等しい
配列ＰｒｅｄＢは、以下をともなう最小配列（（ＰｒＢ１，ＣＢ１，ＳｙｍＢ１），…，（ＰｒＢｋ，ＣＢｋ，ＳｙｍＢｋ））である：
｛１，…，ｋ−ｌ｝内の各ｊについて、ＣＢｊ≧ＣＢｊ＋１である
｛１，．．．，ｍ｝内の各ｊについて、Ｒｅｌｅｖａｎｔ（適切な）（ＰｒＡｊ）Ａｄｊｕｓｔ（調整）（（ＰｒＡｊ，ＣＡ，ＳｙｍＡｊ）がＰｒｅｄＢの一部である場合、
ＵはＧｅｔＵＮｏｄｅＦｒｏｍＰａｔｈ（パスからのＵノードを取得）（Ｐｉ．ｒｕｎ）と等しい
ＵがＵｎｋｎｏｗｎＰａｔｈ（未知のパス）と等しい場合、
（（Ｐｉ．ｒｕｎ，Ｐｉ．ｃ））はＵＰの一部である
そうでなければ
（Ａｄｊｕｓｔ（（Ｐｉ．ｒｕｎ，Ｐｉ．ｃ，Ｕ）），（ＰｒＢ１，ＣＢ１，ＳｙｍＢ１），…，（ＰｒＢｋ，ＣＢｋ，ＳｙｍＢ１））はＵＰの一部である
メニューがツリーを示すことができる場合は、ＳｅｔＭｅｎｕ（メニュー設定）メッセージを引数ＦｉｌｔｅｒＳｏｒｔＥｘｔｅｎｔｉｏｎｓ（フィルタソート拡張）（Ｕ）とともに送信する、そうでなければ：
Ｕは（（（ＤＳ，ＤＣ）（（ＰＳ，ＰＣ）（（ＳＳ，ＳＣ）．．．）．．，）．．．）の形態である
Ｕ２は、ＤＣ、ＰＣ、ＳＣとともにＵからソートされたすべての要素（ＤＳ，ＤＣ）、（ＰＳ，ＰＣ）および（ＳＳ，ＳＣ）からなる最小リストである
ＳｅｔＭｅｎｕ（メニュー設定）メッセージを引数Ｕ２とともに送信する
注記：これらの規則は、ユーザの入力用の多義性解消／予測のために現在評価されているすべての関連する命題を、当該ユーザに示すことができる。
【０１０９】
Ａｄｊｕｓｔ（調整）は処理系依存であり、予測の確率を多義性解消命題の確率と関連付けることができる。これにより、ユーザ入力は平均して確実に最小となる。
【０１１０】
ＥｘｔｅｎｄＰｒｏｐｏｓｉｔｉｏｎ（拡張命題）およびＦｉｌｔｅｒＰｒｏｐｏｓｉｔｉｏｎ（フィルタ命題）は、処理系依存であってよい機能である。Ｆｉｌｔｅｒ  Ｐｒｏｐｏｓｉｔｉｏｎ（フィルタ命題）は、ユーザに示されるサジェスチョンはどれであるべきかを判定する閾値のスコアリングレベルを調整することができる。閾値が高いと、ユーザに示されるサジェスチョンにおける不適切なものの数が低下する。
【０１１１】
ＳｔｏｒｅＷｏｒｄ（語格納）も処理系依存であり、キャラクタのセットのための保持場所であってよく、ＬａｎｇｕａｇｅＭｏｄｅｌ（言語モデル）およびＵｓａｇｅＭｏｄｅｌ（使用法モデル）構造に割り当てられるリソースの量を管理することができる。また、後の使用のための予測／多義性解消を向上させるために、ユーザの挙動に対するモデルの適応を制御することもできる。
【０１１２】
図８に移ると、コア論理２５０が言語モデル２６０を利用できる方法の一実施形態が描写されている。言語モデル２６０は、参照することでその全体が本書に組み込まれる、Ｊ．Ｇ．ＣｌｅａｒｙおよびＪ．Ｈ．による、「Ｄａｔａ  Ｃｏｍｐｒｅｓｓｉｏｎ  Ｕｓｉｎｇ  Ａｄａｐｔｉｖｅ  Ｃｏｄｉｎｇ  ａｎｄ  Ｐａｒｔｉａｌ  Ｓｔｒｉｎｇ  Ｍａｔｃｈｉｎｇ」と題されたＩＥＥＥ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ  ｊｏｕｒｎａｌ［Ｃｌｅａｒｙ１］の１９８４年４月発行Ｃｏｍ−３２巻４号に掲載の記事に描写されているモデルの拡張および改良であってよい。コア論理２５０は、言語モデル２６０を用いて接頭辞または入力を受信（ブロック８１０）し、候補のセットを構築（ブロック８２０）し、候補のセットを位置づける（ブロック８３０）ことができる。コア論理２５０は、接頭辞および入力を受信することができる。接頭辞は、空のセットを含む任意の長さのセットであってよく、入力は、意味論モジュール２４０に関して説明されているタイプのＩｎｐｕｔ（入力）メッセージであってよい。次いで候補のセットが接頭辞および入力に基づいて計算される（ブロック８２０）。接頭辞が空の場合、候補は入力のみに基づいて計算されることができる。しかしながら、接頭辞が空のセットでない場合、コア論理２５０は、接頭辞に関連するストリングのセットのルックアップを試み、接頭辞に基づいて候補を生成する（ブロック８２０）ことができる。
【０１１３】
いくつかの実施形態において、コア論理２５０は、言語モデル２６０を使用してこれらの候補を構築する（ブロック８２０）ことができ、それらは任意の長さの部分ストリングを格納するためのツリー構造および関連スコアを用いることができる。一実施形態において、コア論理２５０は、接頭辞に関連する言語モデル２６０における最長ストリングスを見つける。関連する実施形態において、コア論理２５０は言語モデル２６０を使用して候補のリストを生成することができ、このリストは、実装に応じてフラットリストであっても入れ子リストであってもよい。コア論理は言語モデル２６０において実装されたツリーの各ノードに関連するスコアに基づいて候補を関連づけるためにスコアを判定することができる。これらのスコアは同様に確率的モデルに基づいていてもよい。
【０１１４】
当業者には、スコアを計算するために使用され得る多種多様なアルゴリズム、およびスコア候補が容易に明らかになるであろう。例えば、ユーザが「ｔｅｓｔ」という語を入力したいとする。図６に記載されたレイアウトを使用して、ユーザは（ｔ，ｚ）という対を選択することができ、次いでコア論理２５０は、「ｔ」の確率および「ｚ」の確率を計算することができる。次に、ユーザは（ｅ，ｆ）という対を選択する。コア論理２５０は、言語モデルを使用して、前の候補のセット（ｔ，ｚ）に関連する各文字に続く文字「ｅ」および「ｆ」のスコアを計算し、最初の文字対（ｔ，ｚ）における各文字の確率を乗じることができる。このようにして、２つの文字の各配列の確率を計算することができる。
【０１１５】
特定の一実施形態において、このタイプの言語モデル２６０を格納するための構造、および入力を処理し可能性を計算するための関連論理は、以下のように実装されることができる。
【０１１６】
言語モデル２６０は、以下のように表されるＬａｎｇｕａｇｅＭｏｄｅｌ（言語モデル）のタイプの構造に含まれてよい：
Ｔｙｐｄｅｆ  ｓｔｒｕｃｔ｛
Ｃｈａｒ  ｃ；
Ｉｎｔ    ｃｏｕｎｔｅｒ；
ＮｏｄｅＳｔｒｕｃｔ＊  ｎｅｘｔ；
ＮｏｄｅＳｔｒｕｃｔ＊  ｓｕｂｔｒｅｅ；｝ＮｏｄｅＳｔｒｕｃｔ
Ｔｙｐｅｄｅｆ  ＮｏｄｅＳｔｒｕｃｔ＊  Ｎｏｄｅ；
Ｎｏｄｅ  ｒｏｏｔ；。
【０１１７】
Ｎｏｄｅ（ノード）構造は、実施形態において、構文を法とする［Ｃｌｅａｒｙ１］の構造であってよい。累乗根は、コア論理の言語モデル２６０へのエントリポイントであってよい。
【０１１８】
以下のプロパティおよびアルゴリズムは、言語モデル２６０をサポートする構造上で定義されることができる：
ＩｓｌｎＳｕｂｔｒｅｅ（サブツリー内である）（ノードＮ２，ノードＮ１）
Ｎ１．ｓｕｂｔｒｅｅが不当参照である場合、
ＩｓｌｎＳｕｂｔｒｅｅ（サブツリー内である）（Ｎ２，Ｎｌ）は偽である
そうでなければ
Ｎ２＝Ｎ１．ｓｕｂｔｒｅｅの場合、
ＩｓＩｎＳｕｂｔｒｅｅ（サブツリー内である）（Ｎ２，Ｎ１）は真である
そうでなければ
ＩｓＩｎＳｕｂｔｒｅｅ（サブツリー内である）（Ｎ２，Ｎ１）＝ＩｓＮｅｉｇｈｂｏｒ（ネイバーである）（Ｎ２，Ｎ１．ｓｕｂｔｒｅｅ）である
注記：このプロパティは、Ｎ２がＮ１の子である場合には真であり、その他の場合には偽である。
【０１１９】
ＩｓＮｅｉｇｈｂｏｒ（ネイバーである）（ノードＮ２，ノードＮ１）
Ｎ１．ｎｅｘｔがノードの不当参照である場合、ＩｓＮｅｉｇｈｂｏｒ（ネイバーである）（Ｎ２，Ｎ１）は偽である
そうでなければ
Ｎ２＝Ｎ１．ｎｅｘｔである場合、
ＩｓＮｅｉｇｈｂｏｒ（ネイバーである）（Ｎ２，Ｎ１）は真である
そうでなければ
ＩｓＮｅｉｇｈｂｏｒ（ネイバーである）（Ｎ２，Ｎ１）＝ＩｓＮｅｉｇｈｂｏｒ（ネイバーである）（Ｎ２，Ｎ１．ｎｅｘｔ）である
注記：このプロパティは、Ｎ２がＮ１と同一のツリーにある場合には真であり、その他の場合には偽である。
【０１２０】
ＮｏｄｅＦｒｏｍＰａｔｈ（パスからのノード）（（Ｓ１，…，Ｓｎ））
｛１，．．．，ｎ｝内の各ｉについて、Ｓｉは記号である
Ｎはノード（Ｎ１，．．，Ｎｎ）の配列であり、ここで：
｛１，．．，ｎ｝内の各ｉについて、Ｎｉ．ｃ＝Ｓｉである
｛１，．．，ｎ−１｝内の各ｉについて、ＩｓＩｎＳｕｂｔｒｅｅ（サブツリー内である）（Ｎｉ＋１，Ｎｉ）は真である
ＩｓｌｎＳｕｂｔｒｅｅ（サブツリー内である）（Ｎ１，累乗根）
Ｎが存在する場合、ＮｏｄｅＦｒｏｍＰａｔｈ（パスからのノード）（（Ｓ１，．．，Ｓｎ））は値をＮｎに設定し、そうでなければ、値をＵｎｋｎｏｗｎＰａｔｈ（未知のパス）に設定する。
【０１２１】
図９は、コア論理２５０が使用法モデル２８０を利用することができる方法の一実施形態を描写している。コア論理２５０は、使用法モデル２８０を用いて、ストリングのセットを受信（ブロック９１０）し、予測のセットを構築（ブロック９２０）し、予測のセットを位置づける（ブロック９３０）ことができる。コア論理２５０は、ストリングのセットからなり得る記号のセットを受信する（ブロック９１０）ことができ、これらのストリングは接頭辞であってもユーザからの入力であってもよい。いくつかの実施形態において、これらの記号は、言語モデル２６０を使用して、コア論理によってアセンブルされる、またはコア論理に返される候補のセットからコア論理２５０によって派生または抽出されることができる。
【０１２２】
このストリングのセットは、その後ストリングのセットからのセットに基づいて予測のセットを構築する（ブロック８２０）ために使用できる。使用法モデル２８０は、補完可能の統計的順序付けに基づいて、ストリングに対する一組の補完可能を判定することができる。
【０１２３】
一実施形態において、使用法モデル２８０は、キャラクタを含むツリーの各ノードとともにツリー構造を使用して語を表すことができる。語の終わりを指定できる各ノードは区分され、そのような終端ノードと関連するスコアであってよい。当業者には、スコアを割り当てるために使用され得る様々なスコアリングシステムが容易に明らかになるであろう。
【０１２４】
上記の例を踏まえて、ストリング「ｔｅ」が使用法モデル２８０によって受信されたとする。図１０は、使用法モデル２８０がストリングを補完するために使用し得るツリーの一代表を描写している。ストリング「ｔｅ」は、「ｔｅ」で始まる語１０００のツリーベースの表示にインデックスとして使用され、このツリー１０００は、これらのノードがストリング「ｔｅ」に補完可能を提供するという兆候を含み得る終端ノード１０１０、１０２０、１０３０、１０４０を有することができる。この兆候は、スコア関連の終端ノード１０１０、１０２０、１０３０、１０４０、またはいくつかの実施形態においてはブール値であってよい。このスコアは、同じストリングを補完し得る同じ深さのノードの数に基づいたものであってよい。このスコアは、同一の分岐内のいくつのノードがストリング用の補完でないかに基づいたものであってもよい。
【０１２５】
ノードに関連するスコアに基づいて、ノードは位置づけされる（ブロック８３０）ことができ、ツリー１０００から最高（または最低）位置づけを持つノードへのパス内の各ノードに関連するキャラクタの配列が返されることができる。図１０を参照すると、ノード１０２０が最高スコアを有する場合、「ｔｅｓｔｅｄ」というキャラクタの配列が返され得る。その他の実施形態において、サブツリーに続くパス内の終端ノードに関連するキャラクタの各配列は、関連する終端ノードのスコアとともに返されることができる。
【０１２６】
同様に、予測の同義語は、それらの関連スコアとともに返されることができる。例えば、図１０においてノード１０２０が最高スコアを有する場合、キャラクタの配列「ｔｅｓｔｅｄ」が返されることができる。また、１つ以上の同義語が返される場合もある。これらの同義語は、それらの関連スコアに基づいて判定でき、これらの関連スコアとともに、または無しで返されることができる。特定の予測に関連する同義語は、予測に対応する終端ノードに格納されることができる。例を踏まえ、予測「ｔｅｓｔｅｄ」に対応する終端ノード１０２０は、「ｔｅｓｔｅｒ」「ｔｅｓｔｅｓ」「ｔｅｓｌａ」などを含む様々な「ｔｅｓｔｅｄ」の同義語を格納することができる。これら「ｔｅｓｔｅｄ」の同義語は、予測「ｔｅｓｔｅｄ」に対応する記号の配列とともに返されることができる。特定の一実施形態において、このタイプの使用法モデル２８０を格納するための構造、および、入力を処理しスコアまたは確率を計算するための関連論理が以下のように実装され得る。
【０１２７】
Ｔｙｐｅｄｅｆ  ｅｎｕｍ  ｛ｔｒｕｅ，ｆａｌｓｅ｝Ｂｏｏｌｅａｎ；
Ｔｙｐｅｄｅｆ  ｓｔｒｕｃｔ｛
Ｃｈａｒ＊    ｓ；
Ｉｎｔ    ｃｏｕｎｔ；
｝ＳｙｍＬｉｓｔＮｏｄｅ
Ｔｙｐｅｄｅｆ  ｓｔｒｕｃｔ  ｛
Ｃｈａｒ    ｃ；
Ｕｎｏｄｅ［］    ｓｏｎｓ；
Ｂｏｏｌｅａｎ    ｔｅｒｍｉｎａｌ；
Ｉｎｔ    ｈｅａｄｓ；
Ｉｎｔ    ｃｏｕｎｔ；
ＳｙｍＬｉｓｔＮｏｄｅ［］  ｓｙｍ；
｝Ｕｎｏｄｅ
ｕＮｏｄｅ＊  Ｕｒｏｏｔ；。
【０１２８】
Ｕ累乗根は、コア論理２５０のための使用法モデル２８０へのエントリポイントであってよい。使用法モデル２８０について以下のプロパティが定義できる：
ＩｓＳｏｎ（子である）（Ｕ１：ＵＰノード，Ｕ２：ＵＰノード）は、
Ｕ１部分がＵ２の子であれば真、そうでなければ、ＩｓＳｏｎ（子である）（Ｕ１，Ｕ２）は偽である
注記：ＩｓＳｏｎ（子である）は、Ｕ１がＵ２の直接の子であるか否かを示す。
【０１２９】
ＧｅｔＵＮｏｄｅＦｒｏｍＰａｔｈ（パスからのＵノードを取得）（（Ｃ１，…，Ｃｎ））
配列（ＵＰ１，．．．，ＵＰＮ）：
ＩｓＳｏｎ（子である）（ＵＰ１，ＵＲｏｏｔ）は真である
｛１，．．，ｎ−ｌ｝内の各ｉについて、ＩｓＳｏｎ（子である）（ＵＰｉ＋１，ＵＰｉ）は真である
｛１，…，ｎ｝内の各ｉについて、ＵＰｉ．ｃ＝Ｃｉである
ＵＰｎが存在する場合、ＧｅｔＵＮｏｄｅＦｒｏｍＰａｔｈ（パスからのＵノード取得）（（Ｃ１，…，Ｃｎ））はＵＰｎの値をとり、そうでなければ、ＵｎｋｎｏｗｎＰａｔｈ（未知のパス）の値をとる
注記：ＧｅｔＵｐＦｒｏｍＰａｔｈ（パスからのＵｐを取得）は、それが存在する場合には、引数として与えられた配列に関連するＵｓａｇｅＭｏｄｅｌ（使用法モデル）内のＵノードを返し、そうでなければ、定数ＵｎｋｎｏｗｎＰａｔｈ（未知のパス）が返される。
【０１３０】
ＧｅｔＳｕｇｇｅｓｔｉｏｎｓ（サジェスチョンを取得）（Ｃ）
Ｃは記号の配列である
ＵＰはＧｅｔＵＰＦｒｏｍＰａｔｈ（パスからのＵＰを取得）（Ｃ）の結果である
ＵＳＰはＵＰノード（ＵＰＳ１，…，ＵＰＳｎ）の最小セットであり、ここで｛１，…，ｎ｝内の各ｉについて：
配列（Ｔ１，…，Ｔｑ）があり、ここで：
Ｔ１はＵＰと等しい
ＴｑはＵＰＳｉｑ＞ｌと等しい
｛１，…，ｑ−ｌ｝内の各ｊについて
ＩｓＳｏｎ（子である）（Ｔｊ＋１，Ｔｊ）
ＵＰＳｉ．終端は真である
Ｓは配列（（Ｓ１，Ｃｏｕｎｔ１，Ｓｙｍ１），…，（Ｓｎ，Ｃｏｕｎｔｎ，Ｓｙｍ１）であり、ここで｛１，…，ｎ｝内の各ｉについて：
ＵＰＳｘ＝ＧｅｔＵＰＦｒｏｍＰａｔｈ（パスからのＵＰ取得）（Ｓｉ）、ＵＰＳｘ．ｃｏｕｎｔ＝ＣｏｕｎｔｊおよびＳｙｍｊ＝ＵＰＳｘ．ｓｙｍである
ＧｅｔＳｕｇｅｓｔｉｏｎ（サジェスチョンを取得）（Ｃ）はＳの値をとる
注記：ＧｅｔＳｕｇｇｅｓｔｉｏｎｓ（サジェスチョンを取得）は、所定の接頭辞の語およびそれらの同義語を検索する。各語および同義語は、使用法モデル２８０におけるそれらの使用頻度を示すスコアに関連付けられている。
【０１３１】
再度図７を参照すると、コア論理はその後上述の入力の処理（ブロック７２０）に基づいて出力を構築する（ブロック７３０）ことができる。この出力はキャラクタの配列またはメニューオプションのセットを持つキャラクタの配列であってよい。その後この出力（ブロック７３０）はさらなる対話のためにユーザに対して提示されることができる。一実施形態において、コア論理２５０は、構築された出力（ブロック７３０）を命題としてユーザに提示するために、意味論モジュール２４０と対話することができる。
【０１３２】
記載されているテーブル、フィールド、またはステップのすべてが、必ずしも要求されることができないテーブル、フィールドまたはステップではなく、またさらなるテーブル、フィールドまたはステップを図示されているものに追加することができることに留意されたい。また、各アクティビティが記載されている順序は、必ずしもそれらが実行される順序ではない。本明細書の読了後、当業者は、任意の特定の目的にどのテーブル、フィールドおよび順序付けが最も適合するかを判定することができるであろう。
【０１３３】
上記の明細書において、特定の実施形態を参照して本発明が説明されている。しかしながら、当業者であれば、以下の特許請求の範囲において説明するような本発明の範囲を逸脱することなく、様々な修正および変更がなされ得ることを十分に理解するであろう。したがって、明細書および図は限定的意味ではなく例示的なものと考えられ、そのような修正はすべて本発明の範囲に含まれることが意図されている。
【０１３４】
特定の実施形態に関連して、利益、その他の利点、および問題のソリューションが説明されている。しかしながら、利益、その他の利点、問題のソリューション、および、任意の利益、利点、またはソリューションを発生させる、もしくはより顕著にすることができるいかなるコンポーネントも、特許請求の範囲のいずれかまたはすべての、重大な、必須の、または絶対不可欠な機能またはコンポーネントとして解釈されるべきではない。
【図面の簡単な説明】
【０１３５】
【図１】図１は、従来技術の削減されたキーパッドの説明を含む。
【図２】図２は、開示されているシステムおよび方法を実装するための１つの考えられるアーキテクチャの代表を含む。
【図３】図３は、原理センサを持つゾーンを用いるためのレイアウトの、一実施形態の代表例を含む。
【図４】図４は、原理センサを持つゾーンを用いるためのレイアウトの、実施形態の別の代表例を含む。
【図５】図５は、デバイス上にあるデータエントリ用のゾーンを用いるためのレイアウトの一実施形態を表す。
【図６】図６は、図５に描写されたゾーンの一部をさらに詳細に表す。
【図７】図７は、コア論理による入力処理のための一方法論を含む。
【図８】図８は、入力処理中にコア論理によって使用され得る候補を構築するための一方法論を含む。
【図９】図９は、コア論理によって使用され得る予測を構築するための一方法論を含む。
【図１０】図１０は、言語モデルを格納するためのデータ構造の実施形態の代表例を含む。
【図１】
2007529069.tif 000003
【図２】
2007529069.tif 000004
【図３】
2007529069.tif 000005
【図４】
2007529069.tif 000006
【図５】
2007529069.tif 000007
【図６】
2007529069.tif 000008
【図７】
2007529069.tif 000009
【図８】
2007529069.tif 000010
【図９】
2007529069.tif 000011
【図１０】
2007529069.tif 000012
【国際調査報告】
2007529069.tif 000013
2007529069.tif 000014
2007529069.tif 000015