(57)【要約】  【課題】  ユーザ入力とそれに関連するＧＵＩの変化との間のタイム・ラグを短縮する方法を提供する。  【解決手段】  グラフィカル・ユーザ・インタフェース（ＧＵＩ）を有するアプリケーション・プログラムを動作させる方法は、（i）ＧＵＩに対する次のユーザ入力を予測するステップと、（ｉｉ）次のユーザ入力の受信までの間に、予測したユーザ入力が必要とするＧＵＩ機能を提供するＧＵＩコードの準備部分を実行するステップと、（ｉｉｉ）次のユーザ入力を受信するステップと、（iｖ）次のユーザ入力が予測したユーザ入力に対応する場合にのみ、ＧＵＩコードの活動化部分を処理して必要なＧＵＩ機能を完了させるステップと、を含む。【選択図】  図３1
2007516480.tif 000002
【特許請求の範囲】
【請求項１】
グラフィカル・ユーザ・インタフェース（ＧＵＩ）を有するアプリケーション・プログラムを動作させる方法であって、
ＧＵＩに対する次のユーザ入力を予測するステップと、
次のユーザ入力の受信までの間に、予測したユーザ入力が必要とするＧＵＩ機能を提供するＧＵＩコードの準備部分を実行するステップと、
予測したユーザ入力が実際の次のユーザ入力に対応するか否かを判定し、肯定的な判定の場合に、ＧＵＩコードの活動化部分を処理して必要なＧＵＩ機能を完了させるステップと、
を含む、方法。
【請求項２】
ＧＵＩに対するユーザ入力の履歴を維持するステップを更に含み、特定のＧＵＩ状態における次のユーザ入力を予測するステップが、該特定のＧＵＩ状態における前のユーザ入力履歴の分析に基づいている、請求項１に記載の方法。
【請求項３】
各ＧＵＩ状態におけるＧＵＩに対するユーザ入力の履歴を維持するステップを更に含み、特定のＧＵＩ状態における次のユーザ入力を予測するステップが、維持された履歴またはＧＵＩに対する最近のユーザ入力レコードのどちらに基づいて予測を行うかを判定するステップを含む、請求項１に記載の方法。
【請求項４】
予測ステップが、起こり得るユーザ入力シーケンスを予測することを含み、実行ステップが、予測したシーケンスのユーザ入力の各々についてＧＵＩコードの準備部分を実行することを含む、請求項１または２に記載の方法。
【請求項５】
予測ステップが、複数の起こり得る代替ユーザ入力を予測することを含み、実行ステップが、代替ユーザ入力の各々についてＧＵＩコードの準備部分を実行することを含む、請求項１または２に記載の方法。
【請求項６】
データ処理装置であって、
前記装置が提供するグラフィカル・ユーザ・インタフェース（ＧＵＩ）に対する次のユーザ入力を予測するための手段と、
次のユーザ入力の受信までの間に、予測したユーザ入力が必要とするＧＵＩ機能を提供するＧＵＩコードの準備部分を実行するための手段と、
次の受信したユーザ入力が予測した次のユーザ入力に対応するか否かを判定し、肯定的な判定の場合に、ＧＵＩコードの活動化部分を処理して必要なＧＵＩ機能を完了させるための手段と、
を含む、データ処理装置。
【請求項７】
コンピュータ上で実行された場合に請求項１から５のいずれかに記載の全てのステップを実行するように構成されたプログラム・コード手段を含むコンピュータ・プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、グラフィカル・ユーザ・インタフェースの動作に関する。
【背景技術】
【０００２】
コンピュータ・システム上でのアプリケーション・ソフトウェアの効率的な動作は、多くの場合、グラフィカル・ユーザ・インタフェースを提供するプログラム・コード（以下「ＧＵＩコード」）の動作効率に大きく依存する。多くのアプリケーション・ソフトウェアの動作では、コンピュータ・ユーザがＧＵＩを介して入力を与えるまでＧＵＩはアイドルであるようになっている。ＧＵＩコードは、ＧＵＩの変化を要求するユーザ入力に応答して、かかる変化を実行する。ＧＵＩコードがこの変化を実行するために要する処理時間は、ユーザが要求するアクションに依存する。例えば、ワード処理アプリケーションでは、テキスト入力中にユーザが英数字キーを押下することは、ＧＵＩの変化をもたらすために最小限の処理パワーしか必要としない。一方、ファイル・メニューを表示するオプションを選択すると、ＧＵＩコードは、ポップアップ・メニューを表示するためにＧＵＩリソースを割り当て、メニュー内に全エントリを置き、次いでメニューを表示しなければならない。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
このタイプの動作および他のもっと複雑なＧＵＩ動作では、結果として、ユーザ入力とユーザに提示するＧＵＩの変化との間に、認知できるほど大きいタイム・ラグを生じることがある。かかるタイム・ラグを短縮することが望まれる。
【課題を解決するための手段】
【０００４】
従って、本発明の第１の態様では、グラフィカル・ユーザ・インタフェース（ＧＵＩ）を有するアプリケーション・プログラムを動作させる方法が提供される。この方法は、ＧＵＩに対する次のユーザ入力を予測するステップと、次のユーザ入力の受信までの間に、予測したユーザ入力が必要とするＧＵＩ機能を提供するＧＵＩコードの準備部分を実行するステップと、予測したユーザ入力が実際の次のユーザ入力に対応するか否かを判定し、肯定的な判定の場合に、ＧＵＩコードの活動化部分を処理して必要なＧＵＩ機能を完了させるステップと、を含む。
【０００５】
各ＧＵＩ機能ごとのＧＵＩコードは、準備ブロックおよび活動化ブロックに論理的に分かれている。準備ブロックが含むコードは、実行された場合、ユーザ・データに思わぬ結果を与えることはなく、またそれが実行されたことの目に見える（すなわちＧＵＩにおいて可視的である）手がかりを有しない。活動化ブロックが含むコードは、実行された場合、ＧＵＩに可視的な変化を行うことを含めて、必要なＧＵＩ機能を完了させるために必要なステップを全て実行する。
【０００６】
従って、本発明により、可能性がある次のユーザ入力に関して予測を行い、その予測ユーザ入力に関連したＧＵＩコードの準備ブロックを実行する。次のユーザ入力が予測どおりである場合、ユーザが感じ取れるほどのＧＵＩ変化の遅延は、準備ブロックの実行に伴う時間だけ短縮する。
【０００７】
予測は、多数の異なる方法で実行可能である。１つの技法は、ＧＵＩの異なる状態におけるユーザ入力のレコードを維持することを含む。次いで、特定の状態における最も一般的な次のユーザ入力に基づいて予測を行う。例えば、ＧＵＩの「ファイル・メニュー」上で、利用可能オプションのうち少数がこれまでユーザによって選択されており、あるものが他のものよりも頻繁に選択されている場合、予測は、この頻繁に選択されたオプションに関連したユーザ入力を選択することを含む。従って、この技法は、長期間のユーザ入力統計に基づいているものと考えることができる。以下の記述では、この技法を「足跡」と称する。
【０００８】
別の技法は、短期間の統計に基づくものであり、上述の技法と共に用いることができる。この短期間予測法は、待たれているユーザ入力の直前のユーザ入力の分析に、よりいっそう基づいたものである。このため、例えば、ユーザがワード処理文書のトップに移動したい場合、ユーザは、何度も上向き矢印を押すことによってこれを達成することができる。この上向き矢印のユーザ入力シーケンスのある時点で、短期間統計に基づいた予測は、次の入力が上向き矢印であると予測する。これに対して、長期間統計に基づく予測では、次のユーザ入力は、上向き矢印キーの押下以外の何か、例えばスペース・バーの押下であると予測されるかもしれない。従って、この短期間技法では、長期間技法よりも正確な予測を行うことができる場合がある。以下の説明では、短期間技法を「臭跡」と称する。
【０００９】
添付図面を参照して、一例として、本発明の実施形態を、以下で詳細に説明する。
【発明を実施するための最良の形態】
【００１０】
図１は、本発明を実施するために適したコンピュータ・システム１０の概略図である。システム１０は、処理機能２０、メモリ３０、およびディスプレイ４０を含む。メモリは、揮発性ストレージ（例えばＲＡＭ）および不揮発性ストレージ（例えばディスク・ストレージ・デバイス）から成る。オペレーティング・システム５０およびアプリケーション６０、７０ソフトウェアは、通常、不揮発性ストレージに格納され、必要に応じて揮発性ストレージに転送されて、処理機能によって実行される。通常のパーソナル・コンピュータでは、オペレーティング・システムは、Ｗｉｎｄｏｗｓ（Ｒ）ＸＰまたは同様の、Ｌｉｎｕｘ（Ｒ）、ＭａｃＯＳ（Ｒ）、または他の適切なソフトウェアとすることができる。通常のパーソナル・コンピュータ・システム上のアプリケーション・ソフトウェアは、ほとんど必ず、例えばＭｉｃｒｏｓｏｆｔ（Ｒ）Ｗｏｒｄのようなワード処理ソフトウェアを含む。
【００１１】
アプリケーション・ソフトウェア６０は、グラフィカル・ユーザ・インタフェース（ＧＵＩ）コード６４を含み、これは、オペレーティング・システム・コードと対話して、ソフトウェア・ユーザにＧＵＩ機能を提供する。例えば、ワード処理パッケージの場合、ユーザが、マウスを動かして左のマウス・ボタンをクリックすることによってアプリケーション・ツールバーから「ファイル」オプションを選択すると、これらのユーザ・アクションは、オペレーティング・システムによって検出されて解釈される。オペレーティング・システム・コードは、ワード処理ソフトウェア内でＧＵＩコードが提供する機能を呼び出して、ファイル・メニューを生成し、コンピュータ・ディスプレイ上に表示させる。ＧＵＩコードを実行してメニューを表示させると、結果として、ユーザがマウス・ボタンをクリックした時刻と、メニュー・オプションが表示される時刻との間に遅延が生じる。この単純な例では、時間遅延は小さく、ユーザには感じられない場合がある。しかしながら、より複雑な他のＧＵＩ機能は、実行するのにもっと長い時間がかかり、ユーザは、ＧＵＩを介したアプリケーションとの対話の継続を待つ間、遅延によって不便を感じるかもしれない。
【００１２】
好適な実施形態に従って、この遅延を短縮するために、可能性の高い次のユーザ入力に関して予測を行い、必要なＧＵＩ機能を与えるＧＵＩコードの部分を予め処理する。予測が正しい場合、ＧＵＩコードの更に別の部分を実行し、ＧＵＩ機能を完了させる。予測は、ＧＵＩコード６４と対話する予測コード６２によって実行する。また、予測コードは、予測を行う際に用いるユーザ入力イベント・レコードの維持および更新を行う。これらのレコードは、コンピュータ・システム１０内の不揮発性ストレージ３０に好都合に格納することができる。
【００１３】
記載する実施形態の動作の理解に役立てるため、コンピュータ・プログラムが提供するＧＵＩを一連の状態として考えると便利である。図２は、一連のＧＵＩ状態を示し、更に、マウスの移動、キーの押下、メニュー・アイテムのクリック等、ある状態から別の状態への遷移を生じさせるユーザ入力を示す。メニューの表示等の機能を実行するＧＵＩコードのブロックは、あるＧＵＩ状態への遷移に関連付けられている。
【００１４】
好適な実施形態によれば、これらのＧＵＩ機能の各々は２つのコード・ブロックに分けられる。すなわち、準備ブロックおよび活動化ブロックである。図１は、複数のＧＵＩ機能１、２、・・・、Ｎを示し、各々が準備ブロックおよび活動化ブロックすなわちＰ１、Ａ１；Ｐ２、Ａ２；・・・ＰＮ、ＡＮを有する。機能の実行は、準備ブロックを実行し、その後で活動化ブロックを実行することを伴う。この実施形態によると、準備ブロック・コードの実行は、ユーザ・データに思わぬ結果をもたらすことはなく、それが実行されたという目に見える手がかりはない。例えば、「「ファイル」メニューを表示」の準備ブロックでは、ＧＵＩリソースが、ポップアップ・メニューを表示するために割り当てられ、全エントリをメニューに置くことができる。しかしながら、メニューは表示されない。活動化ブロックでは、その状態に移行することに伴うアクションは、ユーザ・データの変更およびＧＵＩの目に見える変化を含めて、全て実行される。「「ファイル」メニューを表示」の活動化ブロックでは、準備ブロックで作成したポップアップ・メニューを表示する。
【００１５】
図３のフローチャートに、このプロセスを示す。「開始」１００では、ＧＵＩは、前回のユーザ開始ＧＵＩ機能を完了していると考えることができる。ステップ１１０では、次のユーザ入力に関する予測を行う。上述したように、この予測は複数のステップの実行を伴い、その詳細は図４および６を参照して以下で説明する。いったん予測を行うと、予測したユーザ・イベントに関連した準備ブロックを実行し、その結果を不揮発性メモリに格納する。ステップ１３０において、次のユーザ入力を受信したことに応答して（これは、準備コードの実行が完了または未完了の場合に起こり得る）、ステップ１４０において、図５および６に説明するプロセスに従って、実際のユーザ・イベントに関連したカウンタを更新する。その詳細も以下で説明する。ステップ１５０では、実際のユーザ入力が予測ユーザ入力に対応するか否かを判定する。対応しない場合、準備コードの実行結果を処分する。例えば、メモリ・リソースを解放する。次いで、ステップ１６５において、実際のイベントのための準備および活動化コード・ブロックを実行して、関連するＧＵＩ機能を完了する。
【００１６】
実際のユーザ入力が予測入力と同じである場合、ステップ１７０において、必要なＧＵＩ機能のための活動化コード・ブロックを実行し、ステップ１８０において、ＧＵＩ機能を完了する。次いで、プロセスは通常、ステップ１１０に戻って、次のユーザ入力を予測する。しかしながら、最後のユーザ入力の結果としてアプリケーションが閉じると、プロセスは１９０において終了する。
【００１７】
このように、アプリケーション・プログラムとのユーザ対話時に、可能性が高い次のユーザ入力を予測する。いったんこの予測が行われると、処理機能のアイドル時間を用いて、予測ユーザ入力に関連したＧＵＩコードの準備ブロックを実行する。ユーザが次の入力を供給し、それが予測どおりである場合には、活動化ブロックを実行しさえすればよい。準備ブロックを実行するために「ｎ」ミリ秒かかり、活動化ブロックを実行するために「ｎ」ミリ秒かかるならば、ユーザの観点からすれば、このアクションにかかる時間は、以前かかったものの半分になっている。
【００１８】
ここで、図４を参照して、例示的な予測技法の詳細を説明する。ユーザが行う入力を予測するために、特定の遷移を実行する可能性を求める必要がある。好適な実施形態では、これは、「足跡」および「臭跡」と呼ばれる技法を用いて達成される。これらの技法は、用いられている特定のソフトウェア・アプリケーションに応じて、独立して使用可能であり、または好都合に組み合わせて用いることも可能である。
【００１９】
「足跡」は、各遷移において整数カウンタを有することによって機能する。以下の説明では、足跡カウンタを全体的にＣFと示し、各ユーザ・イベントごとにＣF（イベント）と示す。遷移が行われるたびに、実際のユーザ入力に関連したカウンタＣFが１ずつ増分する。アプリケーションを用いるにつれて、しだいに、パスを通った足跡の数に基づいて、あるパターンが現れる。このため、足跡カウンタに基づいた予測は、特定のアプリケーションとのユーザ対話の長期間に渡る履歴に基づいている。
【００２０】
「臭跡」は、足跡と同様であるが、短期間の統計である。以下の説明では、臭跡カウンタを全体的にＣSと示し、各ユーザ・ベントごとにＣS（イベント）と示す。一般的には、この技法の有用性は、以下の例を参照して理解することができる。ユーザがワード処理文書にテキスト・データを入力し、各キーストロークがイベントである例を取り上げると、足跡では、最も可能性の高い次のユーザ入力はスペースバーの押下であろうと示唆される。かかる予測に基づいたプリエンプティブ処理は、一般に効率的であることがわかる。しかしながら、足跡に基づいた予測では改善できない恐れがあるという状況を想像することができる。例えば、ユーザが何度も上向きの矢印を押して文書のトップにスクロールしようとしている状況を取り上げる。以前の例と同様に、足跡レコードでは、最も行われる可能性の高い次のユーザ入力は、スペースバーの押下であると示される。上向きの矢印キーを押すたびに上向きの矢印の押下に関連したカウンタが１ずつ増えるとしても、文書のトップに達した際にも、スペースバーにあるほど多くの足跡が上向き矢印にはないという場合がある。このため、各予測は不正確で、ユーザには何の利益もない。
【００２１】
この可能性に対処するため、「臭跡」技法を提供する。臭跡は、ユーザ・イベントが発生するたびにその値が増えるという点で足跡に似ているが、臭跡は時間が経つと消散する（値は周期的に減分する）。弱い臭跡は強い足跡よりも強力であると考えられ、このため、ユーザが臭跡のあるパスを追っていく確率は、足跡でいっぱいのパスを追うよりも高いという可能性がある。このため、上向きの矢印を押すたびに、そのパスに沿った臭跡が増えて、ユーザはスペースバーではなく上向き矢印を再び押すという予測になり得る。いったんユーザが上向き矢印の押下を終えると、臭跡はゆっくりと減じ、最も押下される可能性の高いキーはスペースバーになる。臭跡対足跡の相対的な重要性の決定は、特定のアプリケーションに適合させる必要がある。
【００２２】
ここで、図４および６を参照して、臭跡および足跡に基づいた予測技法（図３のステップ１１０）の具体的な実施形態を説明する。予測は、ステップ１１０ａで開始する。ステップ１１０ｂにおいて、ＣSの最高値について判定を行う。２つの可能なユーザ・イベントＡおよびＢを示す図６に与えた例では、状態２００に示すＣSの最高値はイベントＡに関連付けられている。図４のステップ１１０ｃにおいて、この値をＣSの閾値と比較する。この例では、この閾値は値４に設定されている。ＣS（Ａ）が４よりも小さいので、ステップ１１０ｄにおいて、最高値ＣFを有するイベント、すなわち状態２００におけるイベントＢに基づいて、予測を行う。プロセスは、ステップ１１０ｆで終了する。しかしながら、ＣSが閾値以上である場合（例えば図６の状態２１０）、ＣSの最大値を有するイベントに基づいて予測を行う。
【００２３】
このように、予測は、臭跡および足跡カウンタの値に基づいている。各イベントごとのＣSおよびＣF値は、図５に記載した方法に従って更新する。図６は、特定の例においてどのように値が変化するかをいっそう詳細に示す。図５の方法は、ステップ１４０ａで開始する。ユーザ入力を受信すると、実際のイベントに対するＣFの値を増分する。ステップ１４０ｃにおいて、前回の予測がＣSの値に基づいたか否かを判定する。そうでない場合（予測がＣFに基づいた場合）、ステップ１４０ｄにおいて、実際のユーザ・イベントが予測イベントに対応したかに関して判定を行う。対応していない場合、実際のイベントのためのＣSを増分し、プロセスはステップ１４０ｊにおいて終了する。しかしながら、ＣFに基づいた予測イベントが実際のイベントと同一である場合、ゼロより大きい全てのＣS値を減分し、プロセスはステップ１４０ｊにおいて終了する。ステップ１４０ｃにおいて、前回の予測がＣSに基づいたと判定されると、ステップ１４０ｇにおいて、実際のユーザ・イベントが予測イベントに対応したか否かを判定する。イエスの場合、実際のイベントのためのＣSを増分し、プロセスは１４０ｊで終了する。そうでない場合、予測イベントのためのＣSを減分し、実際のイベントのためのＣSを増分する。
【００２４】
この方式の利点は、図６に示す例を参照すると認められるであろう。図６では、各ボックスがＧＵＩ状態を示す。各ボックスに含まれるのは、２つのユーザ・イベントＡおよびＢのための臭跡および足跡カウンタの値である。むろん、実際のアプリケーションでは、各ＧＵＩ状態にはもっと多くの可能なユーザ入力があり得ること、および、それらはある状態から次の状態に変化し得ることは、認められよう。
【００２５】
「開始」状態２００において、カウンタ値は図示のとおりである。図４に示したステップに従って、次のユーザ入力はＢであるという、足跡に基づいた予測を行う。しかしながら、この例では、次のユーザ入力は、実際にはＡである。このため、図５に示した方法に従って、ＣF（Ａ）およびＣS（Ａ）を双方とも増分する。イベントＢのためのカウンタは不変である。これを状態２１０に示す。
【００２６】
再び図４に従って予測を行う。この場合、ＣS（Ａ）は閾値４以上であり、従って、次のユーザ・イベントはＡであるという、臭跡に基づいた予測を行う。この例では、次のユーザ・イベントは、実際にＡである。このため、図５に示した方法によって、ＣF（Ａ）およびＣS（Ａ）を双方とも増分する。イベントＢのためのカウンタは不変である。これを状態２２０に示す。
【００２７】
再び図４に従って予測を行う。この場合、ＣS（Ａ）は閾値４よりも大きく、従って、次のユーザ・イベントはＡであるという、臭跡に基づく予測を行う。この例では、次のユーザ・イベントは、実際にはＢである。このため、図５に示した方法によれば、ＣF（Ｂ）およびＣS（Ｂ）を双方とも増分し、ＣS（Ａ）を減分する。これを状態２３０に示す。
【００２８】
再び図４に従って予測を行う。この場合、ＣS（Ａ）は閾値４に等しく、従って、次のユーザ・イベントはＡであるという、臭跡に基づく予測を行う。この例では、次のユーザ・イベントは、実際にはＢである。このため、図５に示した方法によれば、ＣF（Ｂ）およびＣS（Ｂ）を双方とも増分し、ＣS（Ａ）を減分する。このため、イベントＡに関連した臭跡は減分し、イベントＢに関連した臭跡を増分する。これを状態２４０に示す。
【００２９】
再び図４に従って予測を行う。この場合、ＣS（Ａ）は閾値４よりも小さく、従って、次のユーザ・イベントはＢであるという、足跡に基づく予測を行う。この例では、次のユーザ・イベントは、実際にＢである。このため、図５に示した方法によれば、ＣF（Ｂ）を増分し、ＣS（Ａ）およびＣS（Ｂ）を双方とも減分する。このように、予測が長期間の統計に基づいたので、イベントＡおよびＢに関連した臭跡を減分する。これを状態２５０に示す。
【００３０】
代替的な実施形態を考えることができる。予測を行う場合、当然、いくつかのパスを調べた方がよいということが起こり得る（例えば、予測方法が、いくつかの可能なイベントのためのＣF値が極めて類似しているという判定を出す場合がある）。処理機能の能力が充分である場合、それらの機能の各々についての準備コードを実行することができる。遷移が最終的にわかると、悪い予測の準備が保持するいかなるリソースも解放することによって、悪い予測を良好にすることができる。例えば、ユーザがファイル・メニューをクリックするという予想が行われたが、実際にはクリックしなかった場合、割り当てたＧＵＩメニュー・リソースを解放することができる。
【００３１】
更に、多くの予備処理サイクルがある場合、予測技法は、可能なユーザ・イベント・シーケンスの予測を含むことができる。例えば、ユーザが「ファイル」メニューをクリックした場合、ユーザは続けて「印刷」、次いで「ＯＫ」をクリックするという予測を行うことができる。この場合、最初の予測を確認する前に、双方のイベントの準備ブロックを実行することができる。この場合も、先に述べたように、悪い予測をクリーンにする必要があろう。
【００３２】
予測技法において用いる状態およびイベントの細分度は、アプリケーションごとに、および、ユーザの要求に応じて、変動する。例えば、ボタンおよびメニュー・アイテムのクリックが唯一のユーザ・イベントであるという粗い細分度を用いることができる。または、マウスのカーソルを北に動かす等のユーザ・イベントを用いて、ユーザがメニュー・バーに向かっていることを予想するという、いっそう細かい細分度を用いることも可能である。
【図面の簡単な説明】
【００３３】
【図１】本発明を実施することができるデータ処理装置を示す。
【図２】例示的なＧＵＩ状態間の遷移を示す図である。
【図３】本発明の好適な実施形態による方法に含まれるステップを示すフロー図である。
【図４】本発明の実施形態の予測技法に含まれるステップを示すフロー図である。
【図５】本発明の実施形態によるユーザ入力レコードの更新に含まれるステップを示すフロー図である。
【図６】本発明の実施形態による足跡および臭跡カウンタ更新の概略図である。1
【図１】
2007516480.tif 000003
【図２】
2007516480.tif 000004
【図３】
2007516480.tif 000005
【図４】
2007516480.tif 000006
【図５】
2007516480.tif 000007
【図６】
2007516480.tif 000008
【国際調査報告】
2007516480.tif 000009
2007516480.tif 000010