(57)【要約】  開示されるシステムおよび方法は、一般的にタッチセンシティブデバイスに対するユーザー入力の分野に関し、特に、ユーザー入力システム、および直近の入力イベントとそのような入力を反映するレンダリングされたフレームの表示との間のレイテンシを減少させることができる方法に関する。一実施形態において、タッチセンシティブデバイスにおいて、入力タッチイベントと、入力タッチイベントを反映するフレームの表示との間のレイテンシを縮小する方法であって、該方法は、次のフレームリフレッシュの時間を推定する工程と、オペレーティングシステムから、入力タッチイベントを反映するタッチデータを受信する工程と、入力タッチイベントに関するアプリケーションを判定する工程と、アプリケーションが、受信したタッチデータを処理およびレンダリングするのにかかる時間を推定する工程と、アプリケーションへのタッチデータの送信が、少なくとも部分的に、アプリケーションがタッチデータを処理およびレンダリングするのにかかる推定時間と、次のフレームリフレッシュの推定時間とに基づいて、次のフレームリフレッシュの時間前にアプリケーションがタッチデータを処理しレンダリングすることを可能にする時間を判定する工程と、判定された時間の直前にタッチデータをアプリケーションに提供する工程と、を含む。【選択図】図６
2019505045.tif 000002
【特許請求の範囲】
【請求項１】
入力タッチイベントに対して感受的なタッチセンシングシステムに動作可能に接続されたオペレーティングシステムと、ディスプレイシステムとを有するタッチセンシティブデバイスにおいて、入力タッチイベントと、入力タッチイベントを反映するフレームの表示との間のレイテンシを縮小する方法であって、該ディスプレイシステムはリフレッシュレートでフレームを表示し、該方法は：
次のフレームリフレッシュの時間を推定する工程と；
オペレーティングシステムから、入力タッチイベントを反映するタッチデータを受信する工程と；
入力タッチイベントに関するアプリケーションを判定する工程と；
アプリケーションが、受信したタッチデータを処理およびレンダリングするのにかかる時間を推定する工程と；
アプリケーションへのタッチデータの送信が、少なくとも部分的に、アプリケーションがタッチデータを処理およびレンダリングするのにかかる推定時間と、次のフレームリフレッシュの推定時間とに基づいて、次のフレームリフレッシュの時間の前にアプリケーションがタッチデータを処理しレンダリングすることが可能となる時間を判定する工程と；
判定された時間の直前にタッチデータをアプリケーションに提供する工程と；
を含むことを特徴とする方法。
【請求項２】
入力タッチイベントに対して感受的なタッチセンシングシステムに動作可能に接続されたオペレーティングシステムと、ディスプレイシステムとを有するタッチセンシティブデバイスにおいて、最新の入力タッチイベントと、入力タッチイベントを反映するフレームの表示との間のレイテンシを縮小する方法であって、該ディスプレイシステムはリフレッシュレートでフレームを表示し、該方法は：
次のフレームリフレッシュの時間を推定する工程と；
オペレーティングシステムから、第１のアプリケーションに関する複数の入力タッチイベントを反映したタッチデータを受信する工程と；
アプリケーションが、受信したタッチデータ中の複数の入力タッチイベントを処理およびレンダリングするのにかかる時間を推定する工程と；
アプリケーションへのタッチデータの送信が、少なくとも部分的に、アプリケーションがタッチデータを処理およびレンダリングするのにかかる推定時間と、次のフレームリフレッシュの推定時間とに基づいて、次のフレームリフレッシュの時間前にアプリケーションがタッチデータを処理しレンダリングすることを可能にする時間を判定する工程と；
判定された時間の直前にタッチデータをアプリケーションに提供する工程と；
を含むことを特徴とする方法。
【発明の詳細な説明】
【技術分野】
【０００１】
＜関連出願への相互参照＞
本出願は２０１６年２月２日に出願された米国仮特許出願第６２／２９０，３４７号の非仮出願であり、その優先権を主張し、その出願の全体の開示は、参照によって本明細書に組み込まれる。本出願は、２０１５年１１月１８日に出願された米国特許出願第１４／９４５，０８３号の一部継続出願であり、その優先権を主張し、その出願の全体の開示は、参照によって本明細書に組み込まれ、米国特許出願第１４／９４５，０８３号自体は２０１４年１１月１８日に出願された米国特許出願第６２／０８１，２６１号の非仮出願であり、その優先権を主張する。本出願は著作権保護の対象となるものを含んでいる。著作権の所有者はそれが特許商標庁のファイルまたは記録に現われるため特許情報開示者による複製には反対しないが、そうでない場合には著作権をすべて留保する。
【０００２】
開示されたシステムおよび方法は、一般的にタッチセンシティブデバイスに対するユーザー入力の分野に関し、特に、直近の入力イベントとそのような入力を反映するレンダリングされたフレームの表示との間のレイテンシを縮小することができる、ユーザー入力のシステムおよび方法に関する。
【図面の簡単な説明】
【０００３】
本発明の前述および他の目的、特徴、ならびに利点は、添付の図面で例示されるような以下のより特定の好適な実施形態の説明から明白になり、図面中、参照文字が図面全体にわたって同一の部分を指す。図面は同一縮尺である必要はなく、その代わりに本発明の例示されている原則が強調されている。
【図１】従来のダブルバッファリングソリューションを例示するダイヤグラムを示す。
【図２】レンダリングの従来の方法を例示するダイヤグラムを示す。
【図３】レンダリングの従来の方法を例示するダイヤグラムを示す。
【図４】より速くレンダリングし、スクリーンをより速くリフレッシュすることによりラグを縮小するためのソリューションの実施形態を例示するダイヤグラムを示す。
【図５】より速くレンダリングし、スクリーンをより速くリフレッシュすることによりラグを縮小するためのソリューションの実施形態を例示するダイヤグラムを示す。
【図６】本明細書に開示されるシステム、およびＧＵＩのレンダリングの時間を測定するシステムを提供する方法の実施形態を例示するダイヤグラムを示す。
【発明を実施するための形態】
【０００４】
ここで、本発明の好ましい実施形態が詳細に言及され、その例は添付の図面中で例示される。以下の記載及び図面は例示的なものであり、限定的なものとして解釈されるべきではない。多数の特定の詳細が、完全な理解をもたらすように記載される。しかし、特定の例において、記載を曖昧なものにすることを回避するために、周知又は従来の詳細は記載されない。本開示における１以上の実施形態に対する言及は、必ずしも同じ実施形態に対する言及ではなく、そのような言及は少なくとも１つを意味する。
【０００５】
本明細書における「一実施形態」または「実施形態」に対する言及は、実施形態に関連して記載される特定の機能、構造、または特徴が、本開示の少なくとも１つの実施形態に含まれることを意味している。本明細書の様々な場所にある句「一実施形態」の出現は、必ずしも全てが同じ実施形態を指しておらず、他の実施形態に相容れない別個の又は代替的な実施形態でもない。さらに、いくつかの実施形態により示されるが他の実施形態によっては示されない、様々な特徴が記載される。同様に、他の実施形態ではなく、いくつかの実施形態の必要条件となりうる様々な必要条件が記載される。
【０００６】
本発明は、レイテンシを最小化するために、入力検知、レンダリング、および表示の時間を測定するための方法およびデバイスのブロック図および操作上の例示を参照して下記に述べられる。ブロック図または操作上の例示の各ブロック、およびブロック図または操作上の例示のブロックの組み合せが、アナログまたはデジタルのハードウェアおよびコンピュータプログラム命令によって実施されうることを理解されたい。これらのコンピュータプログラム命令は、コンピュータ可読媒体に記憶され、かつ汎用コンピュータのプロセッサ、専用コンピュータ、ＡＳＩＣ、または他のプログラム可能データ処理装置に提供されることもあり、これにより、コンピュータのプロセッサ又は他のプログラム可能データ処理装置によって実行される命令が、ブロック図または操作ブロック（複数可）で指定された機能／動作を実施する。いくつかの代替的な実施において、ブロック内で留意される機能／動作は、操作上の例示において留意される順序とは異なる順序で生じることもある。例えば、連続して示される２つのブロックは実際に、関与する機能／動作に応じて、ほぼ同時に実行されるか、または時に逆の順序で実行されてもよい。
【０００７】
対話型デバイスは、知覚入力、処理およびレンダリングタスク、ならびに出力表示を含む複数の部分の構成物と見なすことができる。知覚入力（例えば：指タッチ）を視覚的な応答に変換するために必要とされるパイプラインは、即時ではなく；情報を処理するために必要な時間や、表示の場合はディスプレイがそのスクリーン全体またはその一部を再描画するために使用する周波数などの多数の理由で、各動作によってレイテンシがもたらされる。それゆえ、これらの動作が平行に行われても、可能な場合、そのシステムの動作は最も遅い動作にしかならない。例えば、ディスプレイは６０Ｈｚごとに一度しかリフレッシュできず、これは、それ以外の全ての動作が次のリフレッシュサイクルの前よりも速い（または利用可能である）場合、そのシステムのディスプレイが新しい情報の表示を準備するのを待たなければならないことを意味する。
【０００８】
本発明は、レイテンシ（すなわち、システムに対するユーザーの入力と、その入力に対するシステムのグラフィカルな応答との間の時間）を縮小することを目的とする。インプットキャプチャを同期して、ディスプレイリフレッシュにより処理することにより、直近の入力情報が表示されることを可能にすることも目的である。一般に、入力情報はできるだけ早く処理され、しばしば、次のリフレッシュサイクルを待たされる。これは単独で待機期間をもたらし、全体的なシステムレイテンシに反映される。本明細書で開示される方法の実施形態に従って、そのシステムは、いつが次のリフレッシュとなるか、かつレンダリングのためにジャスト・イン・タイムで、最新のイベントを提供することを考慮する。
【０００９】
一実施形態において、ディスプレイをリフレッシュする時間、および入力センサをサンプリングしタッチポイントを算出するために必要とされる時間は既知である。したがって、入力検知は、リフレッシュが始まりそうな時に終了するように遅延される。一実施形態において、レンダリングは最後の瞬間になって開始され、結果として、レンダリングが完了して出力は次のディスプレイリフレッシュができるようになる。このジャスト・イン・タイムのレンダリングは、直近の入力イベントを利用可能であり；したがって、結果としてもたらされる表示は、最低量のレイテンシでグラフィックスを含むだろう。
【００１０】
他の実施形態では、リフレッシュする時間または入力センサをサンプリングする時間は先験的には知られておらず、測定が必要となる。測定はキーとなるタイムスタンプに基づいて実行され、これにより、時間的な順序付けおよび順序制御を確かなものできる。測定することによって、入力サンプル速度およびディスプレイリフレッシュ速度が既知となり、レイテンシを最小化するために、上に概説されるようにグラフィックスのレンダリングの時間を測定することができる。
【００１１】
別の実施形態において、そのような測定値は、外部の測定設備およびユーザー入力を使用して検知される（あるいは定数として規定される）。
【００１２】
別の実施形態において、これらの測定は、システムの作業負荷に従って異なり、正確ではないが、表示のための待機時間を縮小するための単なる試みである。出力をレンダリングするために必要とされる時間は、出力の複雑性と競合するシステムアクティビティに応じる（より多くの複素出力は一般的にはレンダリングするためにより多くの時間を必要とし、ＣＰＵまたはＧＰＵにおける競合するアクティビティはレンダリングを遅くする可能性がある、など）。本実施形態において、システムは：出力複雑性のモデルと；キーとなるシステムコンポーネントにおける競合するアクティビティの情報と；前フレームをレンダリングするために必要とされる時間と；過去に類似の出力をレンダリングするために必要とした時間と；のいくつかの組み合わせに基づいてレンダリング時間を推定する。
【００１３】
別の実施形態において、システムは、ディスプレイがその垂直リフレッシュを完了し、適切なバッファがレンダリング可能であるとすぐにその出力をレンダリングする。レンダリングが完了した後、および次の垂直リフレッシュまで、そのシステムは、入力センサによる付加的な入力イベントサンプルに基づいてこのレンダリングを更新する。例えば、システムはＧＵＩのビューをレンダリングすることもあり、次にレンダリングが表示される必要がある時間までに、付加的な入力イベントに基づいてそのビューを転換する。
【００１４】
図１は、従来のダブルバッファリングソリューションを示す。そのようなソリューションでは、表示は、表示およびレンダリングするために使用される２つのバッファ間を「フリップ」または「スワップ」する（Ａ＆Ｂ）。バッファＡが可視であるとき、デバイスはバッファＢへとレンダリングする。予め決められたレートで、そのシステムは、現在Ｂが可視であり、Ａがレンダリングされうるようにバッファをフリップ／スワップする。バッファがオフスクリーンであるときは、クリアされてレンダリングされる。
【００１５】
図２および３はレンダリングの従来の方法を示す。ＧＵＩは直近の入力データおよびアプリケーション状態を使用してレンダリングされる。ＧＵＩがレンダリングされるときと、ＧＵＩが最終的にスクリーンに表示されたときのアプリケーション状態（入力を含む）の間に差がある場合、レイテンシ（ラグ）が生じる。図３において、Ａをレンダリングするラグは、Ａのレンダリングの開始と、スクリーン上でＡのレンダリングの結果を表示する垂直リフレッシュとの間の時間として示される。
【００１６】
図４および５は、より速くレンダリングし、スクリーンをより速くリフレッシュすることによりラグを縮小するためのソリューションの実施形態を示す。例えば、それらのシステム中に、より速いＧＰＵまたは他のそのような改良を含ませることもあり、より速いリフレッシュレート（６０Ｈｚではなくむしろ１００Ｈｚ）でそれらの表示を実行することもある。このようにして、レンダリングされたグラフィックスは両方ともより速く作成され、かつユーザーに対してより速くオンスクリーンで表示し、したがってレンダリングの開始とユーザーに対するＧＵＩの表示との間の時間が縮小される。スクリーンの垂直リフレッシュ間に、バッファをクリアして、ＧＵＩをレンダリングする時間が存在する限り、このアプローチでは、より有能なレンダリングエンジンおよびより速くより高価なディスプレイを使用することで、ラグはさらに縮小されるだろう。
【００１７】
図６は、開示されたシステムおよび方法の実施形態を示し、ここで、ＧＵＩのレンダリングは、できるだけ垂直リフレッシュの近くで終了するように時間を測定される。このようにして、レンダリングは、レンダリングされた画像を生成するために、ユーザーからの直近の利用可能な入力および直近の利用可能なアプリケーション状態を使用することができ、したがってラグを縮小する。
【００１８】
一実施形態において、システムと方法は、タッチサンプリングレートでタッチデータを生成することができるタッチセンシングシステムと、リフレッシュレートでフレームを表示するディスプレイシステムとを有するタッチセンシティブデバイスにおいて、タッチデータの取得と関連付けられたレンダリングタスクの処理との間のレイテンシを減少させるために提供される。そのシステムは、（ａ）タッチセンシングシステムからタッチデータをサンプリングするための時間、（ｂ）サンプリングされたタッチデータからのタッチイベントデータを算出するための時間、および（ｃ）フレームバッファにフレームをレンダリングするための時間の少なくとも１つを推定する。システムは、（ａ）タッチセンシングシステムからのタッチデータをサンプリングする、（ｂ）サンプリングされたタッチデータからのタッチイベントデータを算出する、および（ｃ）その推定値に少なくとも部分的に基づいて、フレームバッファにフレームをレンダリングする、ための時間Ｔｃを判定する。システムは、ディスプレイシステムがフレームバッファからリフレッシュされる時点Ｔｒを判定する。サンプリング開始時刻は、ＴｒとＴｃに少なくとも部分的に基づいて算出される。タッチセンシングシステムのサンプリングは、サンプリング開始時刻にサンプリングされたタッチデータを得るように始められる。タッチイベントデータは、サンプリングされたタッチデータから算出され、タッチイベントデータを反映するフレーム、は時間Ｔｒより前にフレームバッファにレンダリングされる。その後、ディスプレイはフレームバッファからリフレッシュされる。
【００１９】
一実施形態において、システムは、サンプリングされたタッチデータからタッチイベントデータを算出し、フレームをフレームバッファにレンダリングするために必要とされる時間Ｔｃと、ディスプレイシステムがフレームバッファからリフレッシュされる時点Ｔｒとを判定する。そのタッチセンシングシステムは、サンプリングされたタッチデータを作成するためにサンプリングされる。タッチイベントデータはサンプリングされたタッチデータから算出され、そしてこの算出工程の始まりは、少なくとも（Ｔｒ−Ｔｃ）と同じくらい早い時点で生じるように遅延される。フレームは時点Ｔｒよりも前にフレームバッファにレンダリングされ、その後ディスプレイシステムはフレームバッファからリフレッシュされる。
【００２０】
一実施形態において、（ａ）タッチサンプリングレートでタッチデータを生成し、サンプリング同期を有することができるタッチセンシングシステムと、（ｂ）リフレッシュ同期を有する、リフレッシュレートでフレームを表示するディスプレイシステムと、を有するタッチセンシティブデバイスにおいて、タッチデータの取得と、関連付けられたレンダリングタスクの処理との間のレイテンシを減少させるための方法が提供される。タッチセンサー出力のサンプリングはサンプリング同期上で開始され、サンプリングされた出力はあるサンプリングレートでサンプリングバッファに格納される。複数の表示バッファの１つに対するフレームレンダリングはリフレッシュ同期上で開始され、レンダリングされたフレームに対応する表示画像はリフレッシュ同期で表示される。サンプリングバッファ中の出力を収集するための推定時間に相当する時間Ｔｃは判定され、収集された出力からのタッチイベントデータを算出するための推定時間に相当する時間Ｔｍは判定され、かつタッチイベントデータに相当するフレームをレンダリングするための推定時間に相当する時間Ｔｒは判定される。開始時刻はリフレッシュ同期、Ｔｃ、Ｔｍ、およびＴｒ、に基づいて算出され、かつサンプリングバッファ中の出力の収集は開始時刻で開始される。その後、タッチイベントデータは収集された出力から算出され、そしてタッチイベントデータに相当するフレームがレンダリングされる。
【００２１】
一実施形態において、スワップバッファ持続時間は、アプリケーションによってレンダリングされた画像がディスプレイによって示される準備ができる時間を推定するために使用されてもよい。一実施形態において、画像アベイラビリティ（ｉｍａｇｅ ａｖａｉｌａｂｉｌｉｔｙ）を推定するための代替的なストラテジーが使用されることがあり；例えば、限定されないが、画像アベイラビリティを推定するための代替的なストラテジーは、フレームバッファのバッファに基づく抽象的概念（例えばキュー、デュアルバッファ、トリプルバッファ（または任意のマルチバッファストラテジー）、スタック、ハッシュ、ヒープ、連結リスト、双方向リスト等）をモニタリングすることを含むこともある。一実施形態において、アプリケーションは、例えばレンダリングの開始とレンダリングの終了を示すことによって、レンダリングを実行するために必要とされる時間を特定することを可能にするＡＰＩを提供することができる。一実施形態において、ランダムな時間が、レンダリングの期間の推定値として選択されることもある。
【００２２】
一実施形態において、入力サンプリングおよび／または出力処理の推定値は、スケジューリングを調節するために使用され；したがって、例えば、システム内の様々なプロセスによって得られた時間はモニタリングされることがあり、かつ入力サンプリングおよび／または出力処理のスケジューリングは、その時間を補正するために調節されることもある。一実施形態において、複数の重複するスケジュールが存在することもあり、レンダリングを実行するために得られる特定の時間を考慮して、複数の候補の出力が生成され、正しい１つが選択されるか、そうでなければ入力を処理する。一実施形態において、以下のうち１つ以上のものがモニタリングされることがある：サンプリング時間、（オペレーティングシステム、ＵＩフレームワーク、アプリケーション、または他のプロセスの１つ以上の）算出時間、レンダリング、ハードウェアが所定の入力をレンダリングするのに必要な時間、およびアプリケーションに入力を送るのに必要な時間。一実施形態において、例えば、入出力処理のためのオペレーティングシステムによって得られる時間は、モニタリングされ、スケジューラに供給されうる。
【００２３】
一実施形態において、システムのレイテンシは、入力の処理、およびスクリーンにおけるそのエフェクトの表示をスケジューリングすることによって改善される。このようなことは、例えば、オペレーティングシステムがネイティブモードで利用され、レンダリング時にインサーションのためのアクセスが提供されない場合に望ましいこともある。処理工程の所定の持続時間の間に、その処理が、特定の入力の後、またはディスプレイの特定のリフレッシュの前に（あるいは、入力または表示に関して、繰り返される予め決められた又は継続的に調節されるスケジュールで）行われるようにスケジューリングすることにより、レイテンシの改善は達成されることもある。一実施形態において、出力および／または入力イベントはスキップされることもある。一実施形態において、いくつかの入力フレームからの入力イベントは、アプリケーションに送られるスケジューリングプロセスによってまとめられる。
【００２４】
論じられているように、スケジューリングは、アプリケーションのビューのレンダリングが行われるべき時間を判定するように実行される。一実施形態において、直近の入力が、処理されて、その結果がスクリーンに示されるものであることを確実とするために、アプリケーションに対する入力の送信がいつ実施されるか、およびどのサンプリングされた入力が含まれるべきであるかのスケジューリングを考慮する。一実施形態では、入力のスケジューリングは実施される。一実施形態では、出力のスケジューリングは実施される。一実施形態では、その両方が実施される。したがって、一実施形では、オペレーティングシステムは、アプリケーションへのイベントデータの送達を統合しスケジューリングするプロセスへイベントデータ（例えばタッチイベントデータ）を転送する。一実施形では、そのプロセスは、（類似のサンプリングレートで実行されこともあるし、されないこともある）複数のセンサからのイベントを含む、複数のイベントから統合されることもある。一実施形では、アプリケーションへの送信をスケジューリングすることは、統合されたイベントのための入力処理および出力処理の時間に基づきうる。一実施形では、統合されたイベントがフレームバッファの切り替えまでの残りの利用可能時間を超えると判定される場合、イベントの送信は次のフレームバッファの切り換え前の時点（例えば次のフレームバッファの切り換えの直前）まで延期されることもあるが、それでもなお、送信されたときの直近の情報を含むだろう。一実施形では、統合されたイベントがフレームバッファの切り換えまでの残りの利用可能時間を超えると判定される場合、統合されたイベントの１つ以上はスキップされることがあり、このように、入力はフレームバッファの切り換えにおける表示を可能にするために間引かれる。
【００２５】
一実施形では、複数の入力サンプルの同時の（またはほぼ同時の）処理が実施されることがある。そのような処理は、スケジューリングプロセスからの入力サンプリングの非干渉化を可能にする。したがって、一実施形では、入力の複数のサンプルが得られる。入力がアプリケーション状態を修正するために処理される時間が来たとき、その直近のイベントはその状態を更新するためにアプリケーションに送信される。一実施形態において、出力フレーム間のその状態を複数回更新するアプリケーションによって時間を縮小するために、そのアプリケーションは、更新（およびレンダリング）を実施することが適切なときに限り、入力を知らされることもある。このストラテジーは、直近のイベントをレンダリングすることによってのみレイテンシを縮小するのに効果的である間、スキップされたイベントは必要とされるまたは所望の情報を含むことが可能である。したがって、一実施形では、入力イベントはキューイングされ（そうでなければまとめられ／グループ化され）、グループとしてアプリケーションへ送られ（そうでなければ同時に、またはほぼ同時に処理され）、したがって、アプリケーションがその状態を更新する回数が減少する。入力イベントのそのような送信は、生じている更新の数を減少させ、特定の出力の方法／プロセスのための正しい時間において、入力イベントが伝達される尤度を増加させる。さらに、したがって、アプリケーションは、このキューイングの利点をなしで受信されるものと同じ（または大部分が同じ）入力を受信することもある。
【００２６】
本開示の全体にわたり、用語「タッチ（ｔｏｕｃｈ）」、「タッチ（ｔｏｕｃｈｅｓ）」、または他の記述語は、ユーザーの指、スタイラス、物体、又は身体部分がセンサにより検出される事象又は期間について記載するために使用されてもよい。いくつか実施形態では、ユーザーが、センサ、又はセンサが埋め込まれる装置と物理的に接触した場合にのみ、このような検出が生じる。他の実施形態では、センサは、タッチ表面上のある距離をホバリングしている「タッチ」、そうでなければタッチセンス装置から離れている「タッチ」の検出を可能にするように調整されうる。したがって、感知された物理接触への依存を示す本説明内の言葉の使用は、記載された技術がそれらの実施形態にのみしか適用されないことを意味するように解釈するべきではなく；実際に、本明細書に記載されるものの全てではないが、ほぼ全ては「タッチ」および「ホバリング」センサに等しく適用されるだろう。本明細書において使用されるように、フレーズ「タッチイベント」、および名詞として使用されたときの単語「タッチ」は、ニアタッチ（ｎｅａｒ ｔｏｕｃｈ）、ニアタッチイベント（ｎｅａｒ ｔｏｕｃｈ ｅｖｅｎｔ）、またはセンサを使用して特定することができる他のいかなるジェスチャも含む。
【００２７】
少なくともいくつかの開示された態様は、ソフトウェア中で少なくとも部分的に具体化することができる。すなわち、技術は、メモリ、などのＲＯＭ、揮発性ＲＡＭ、不揮発性メモリ、キャッシュまたはリモートストレージデバイスに含まれていた命令のシーケンスを実行して、マイクロプロセッサーなどのそのプロセッサに応じて専用または汎用コンピュータシステム、または他のデータ処理システム中で実行されることがある。
【００２８】
実施形態を実行するために実行されるルーチンは、オペレーティングシステム、ファームウェア、ＲＯＭ、ミドルウェア、サービス配信プラットフォーム、ＳＤＫ（ソフトウェア開発キット）コンポーネント、ウェブサービス、または他の特定のアプリケーション、コンポーネント、プログラム、オブジェクト、モジュール、もしくは「コンピュータプログラム」と呼ばれる命令のシーケンスの一部として、実行されてもよい。これらのルーチンに対する呼び出しインターフェースは、ＡＰＩ（アプリケーションプログラミングインタフェース）としてソフトウェア開発コミュニティーに公開することができる。コンピュータプログラムは、典型的には、コンピュータ内の様々なメモリおよび記憶デバイス中に、様々な時間において１つ以上の命令のセットを含み、そのセットは、コンピュータ内の１つ以上のプロセッサによって読み取られ実行されたとき、コンピュータに様々な態様に関する要素を実行するのに必要な操作を実施させる。
【００２９】
機械可読媒体は、データ処理システムによって実行されたときにシステムに様々な方法を実施させるソフトウェアおよびデータを記憶するために用いることができる。実行可能なソフトウェアおよびデータは、例えば、ＲＯＭ、揮発性ＲＡＭ、不揮発性メモリ、および／またはキャッシュを含む様々な場所に記憶されてもよい。このソフトウェアおよび／またはデータの部分は、これらの記憶デバイスのいずれか１つに記憶されてもよい。さらに、データおよび命令は集中型サーバまたはピアツーピア・ネットワークから取得することができる。データおよび命令の異なる部分は、様々な通信セッションまたは同じ通信セッション中に、様々な時間で、様々な集中型サーバおよび／またはピアツーピア・ネットワークから取得することができる。そのデータおよび命令の全体は、アプリケーションを実行する前に取得することができる。代替的に、そのデータおよび命令の部分は、実行に必要なとき、ジャスト・イン・タイムで動的に取得することができる。したがって、データおよび命令が、時間の特定の段階において、そのまま機械可読媒体上に存在することは要求されない。
【００３０】
コンピュータ可読媒体の例は、限定されないが、揮発性および非揮発性メモリ装置、リードオンリーメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、フラッシュメモリ装置、フロッピーディスクおよび他のリムーバブルディスク、磁気ディスク記憶媒体、光記録媒体（例えばコンパクトディスクリードオンリーメモリ（ＣＤ ＲＯＭ）、デジタル多用途ディスク（ＤＶＤ）等）などの、記録可能なタイプの媒体および非記録可能なタイプの媒体を含む。
【００３１】
一般的に、機械可読媒体は、マシン（例えばコンピュータ、ネットワークデバイス、携帯情報端末、製造ツール（ｍａｎｕｆａｃｔｕｒｉｎｇ ｔｏｏｌ）、１つ以上のプロセッサのセットを備える任意のデバイス等）によってアクセス可能な形状で情報を提供する（例えば、記憶する）任意のメカニズムを含む。
【００３２】
実施形態では、ハードワイヤード回路は、その技術を実行するソフトウェア命令と組み合わせて用いられてもよい。したがって、その技術は、ハードウェア回路およびソフトウェアの任意の特定の組み合わせも、データ処理システムによって実行される命令のための任意の特定のソースも限定することはない。
【００３３】
上記の実施形態および選択物は本発明の例示となる。この特許のために、すべての組み合わせまたは実施形態を概説するまたは定義することは必要ではなく、それを意図してもいない。本発明者は、当業者が本発明の少なくとも１つの実施形態を実施することを可能にするために十分な情報を開示してきた。上記の記載および図面は、本発明の単なる例示であり、以下の請求項に定義されるような本発明の範囲から逸脱することなく、構成要素、構造、および手順を変更することが可能である。例えば、特定の順序で上記されたおよび／または以下の請求項中に記載された要素および／または工程は、本発明から逸脱することなく異なる順序で実施されてもよい。したがって、本発明はその実施形態に関連して具体的に示され記載されているが、形態および詳細の様々な変更は本発明の精神および範囲から逸脱することなくここでなされてもよいことが当業者によって理解される。
【図１】
2019505045.tif 000003
【図２】
2019505045.tif 000004
【図３】
2019505045.tif 000005
【図４】
2019505045.tif 000006
【図５】
2019505045.tif 000007
【図６】
2019505045.tif 000008
【国際調査報告】
2019505045.tif 000009
2019505045.tif 000010