特表 2017-535880 モジュール間通信用のシステム及び方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】特表2017-535880(P2017-535880A)

(43)【公表日】2017年11月30日

(54)【発明の名称】モジュール間通信用のシステム及び方法

(51)【国際特許分類】

   G06F 9/54 20060101AFI20171102BHJP

【ＦＩ】

   G06F9/46 480A

【審査請求】未請求

【予備審査請求】未請求

【全頁数】20

(21)【出願番号】特願2017-526491(P2017-526491)

(86)(22)【出願日】2015年11月18日

(85)【翻訳文提出日】2017年6月27日

(86)【国際出願番号】US2015061362

(87)【国際公開番号】WO2016081613

(87)【国際公開日】20160526

(31)【優先権主張番号】62/081,255

(32)【優先日】2014年11月18日

(33)【優先権主張国】US

(81)【指定国】 AP(BW,GH,GM,KE,LR,LS,MW,MZ,NA,RW,SD,SL,ST,SZ,TZ,UG,ZM,ZW),EA(AM,AZ,BY,KG,KZ,RU,TJ,TM),EP(AL,AT,BE,BG,CH,CY,CZ,DE,DK,EE,ES,FI,FR,GB,GR,HR,HU,IE,IS,IT,LT,LU,LV,MC,MK,MT,NL,NO,PL,PT,RO,RS,SE,SI,SK,SM,TR),OA(BF,BJ,CF,CG,CI,CM,GA,GN,GQ,GW,KM,ML,MR,NE,SN,TD,TG),AE,AG,AL,AM,AO,AT,AU,AZ,BA,BB,BG,BH,BN,BR,BW,BY,BZ,CA,CH,CL,CN,CO,CR,CU,CZ,DE,DK,DM,DO,DZ,EC,EE,EG,ES,FI,GB,GD,GE,GH,GM,GT,HN,HR,HU,ID,IL,IN,IR,IS,JP,KE,KG,KN,KP,KR,KZ,LA,LC,LK,LR,LS,LU,LY,MA,MD,ME,MG,MK,MN,MW,MX,MY,MZ,NA,NG,NI,NO,NZ,OM,PA,PE,PG,PH,PL,PT,QA,RO,RS,RU,RW,SA,SC,SD,SE,SG,SK,SL,SM,ST,SV,SY,TH,TJ,TM,TN,TR,TT,TZ,UA,UG,US

(71)【出願人】

【識別番号】516081504

【氏名又は名称】タクチュアル ラブズ シーオー．

(74)【代理人】

【識別番号】100082072

【弁理士】

【氏名又は名称】清原 義博

(72)【発明者】

【氏名】コスタ，リカルド ホルヘ ホタ

(72)【発明者】

【氏名】ギフォード，マイルズ

(72)【発明者】

【氏名】ロドリゲス デ アラウジョ，ブルーノ

(72)【発明者】

【氏名】フォーラインズ，クリフトン

(57)【要約】

入力イベントデータのソースと、コンピューティング装置における入力イベントを待つ１以上のユーザーアプリケーションプロセスとの間で減少したレイテンシとの通信を可能にするように、オペレーティングシステムにおいて実行する、モジュールを利用するための装置及び方法が、開示される。モジュールは、入力イベントデータのソースからの入力イベントデータのフレームが読み取られる用意ができているという通知を受信する。それに応じて、モジュールは、名前付パイプなどの通信チャネルから入力イベントデータのフレームを読み取り、バッファに、又は専用の処理装置のメモリに入力イベントデータのフレームをロードし、ユーザーアプリケーションプロセスへの通知を生成し、それにより、ユーザーアプリケーションプロセスにバッファから入力イベントデータのフレームを読み取らせる。
【選択図】図２

【特許請求の範囲】

【請求項1】

入力イベントデータのソースと、コンピューティング装置における入力イベントを待つ１以上のユーザーアプリケーションプロセスとの間で減少したレイテンシとの通信を可能にするように、オペレーティングシステムにおいて実行する、モジュールを利用するフレームベースの方法であって、該方法は、
オペレーティングシステムにおいて実行するモジュールにより入力イベントを待つユーザーアプリケーションプロセスを登録する工程であって、それによりユーザーアプリケーションプロセスをモジュールから通知の標的であると識別する、工程；
モジュールにおいて、入力イベントデータのソースからの入力イベントデータのフレームが読み取られる用意ができているという通知を受信する工程；
通信チャネルから入力イベントデータのフレームを読み取るためにモジュールを使用する工程；
バッファに入力イベントデータのフレームをロードするためにモジュールを使用する工程；及び
モジュールにおいて、ユーザーアプリケーションプロセスへの通知を生成する工程であって、それによりユーザーアプリケーションプロセスにバッファから入力イベントデータのフレームを読み取らせる、工程
を含む、方法。

【請求項2】

入力イベントデータのソースはセンサドライバを含む、ことを特徴とする請求項１に記載の方法。

【請求項3】

入力イベントデータのソースは内部ジェネレータを含む、ことを特徴とする請求項１に記載の方法。

【請求項4】

ユーザーアプリケーションプロセスは、処理のために専用の処理装置に入力イベントデータのフレームの少なくとも一部を送信する、ことを特徴とする請求項１に記載の方法。

【請求項5】

専用の処理装置はグラフィック処理装置を含む、ことを特徴とする請求項４に記載の方法。

【請求項6】

オペレーティングシステムにおいて実行するモジュールは、オペレーティングシステムのユーザーランド部分において実行するモジュールである、ことを特徴とする請求項１に記載の方法。

【請求項7】

オペレーティングシステムにおいて実行するモジュールは、オペレーティングシステムのカーネル部分において実行するモジュールである、ことを特徴とする請求項１に記載の方法。

【請求項8】

バッファに入力イベントデータのフレームをロードするためにモジュールを使用する工程は、既知の場所にあるラムベースのファイルに入力イベントデータのフレームを保存する工程を含む、ことを特徴とする請求項１に記載の方法。

【請求項9】

バッファに入力イベントデータのフレームをロードするためにモジュールを使用する工程は、ヘッダー及び本体を含むデータ構造の部分として入力イベントデータのフレームを保存する工程を含む、ことを特徴とする請求項１に記載の方法。

【請求項10】

本体は、入力イベントのＸ位置、入力イベントのＹ位置、及び、入力イベントデータが関連する入力イベントを識別する固有の識別子を含む、ことを特徴とする請求項９に記載の方法。

【請求項11】

本体は、タッチサイズ、絶対的ｖｓ相対的なポジショニング、タッチのパスの速度、タッチのパスの曲率、圧力、タッチの形状、タッチのサイズ、タッチの回転、タッチのソース、及びタッチのアジマスから成る群から選択される、少なくとも１つのデータ型を含む、ことを特徴とする請求項９に記載の方法。

【請求項12】

ヘッダーはタイムスタンプを含む、ことを特徴とする請求項９に記載の方法。

【請求項13】

ヘッダーは、バイトで本体の長さを示すフィールドを含む、ことを特徴とする請求項９に記載の方法。

【請求項14】

アプリケーションプロセスは、
ヘッダーを読み取ること；
バイトでの本体の長さをヘッダーから抽出すること；及び
本体の抽出された長さに基づいて入力イベントデータのフレームを読みとること
により、バッファから入力イベントデータのフレームを読み取る、ことを特徴とする請求項１３に記載の方法。

【請求項15】

入力イベントを待つユーザーアプリケーションプロセスを登録する工程は、プロセス識別子を含む情報を登録する工程を含み、該プロセス識別子はユーザーアプリケーションプロセスを固有に識別する、ことを特徴とする請求項１に記載の方法。

【請求項16】

入力イベントを待つユーザーアプリケーションプロセスを登録する工程は、モジュールの予測された動作に関連したフラッグのビットマスクを含む情報を登録する工程を含む、ことを特徴とする請求項１に記載の方法。

【請求項17】

通信チャネルは名前付きパイプを含む、ことを特徴とする請求項１に記載の方法。

【請求項18】

通信チャネルはファイルを含む、ことを特徴とする請求項１に記載の方法。

【請求項19】

通信チャネルはメモリ位置を含む、ことを特徴とする請求項１に記載の方法。

【請求項20】

通信チャネルはソケットを含む、ことを特徴とする請求項１に記載の方法。

【請求項21】

入力イベントデータのソースと、コンピューティング装置における専用の処理装置において実行する入力イベントを待つプロセスとの間で減少したレイテンシとの通信を可能にするように、オペレーティングシステムにおいて実行する、モジュールを利用するフレームベースの方法であって、該方法は、
オペレーティングシステムにおいて実行するモジュールにより入力イベントを待つユーザーアプリケーションプロセスを登録する工程であって、それによりユーザーアプリケーションプロセスをモジュールから通知の標的であると識別する、工程；
モジュールにおいて、入力イベントデータのソースからの入力イベントデータのフレームが読み取られる用意ができているという通知を受信する工程；
通信チャネルから入力イベントデータのフレームを読み取るためにモジュールを使用する工程；
専用の処理装置に関連したメモリに入力イベントデータのフレームをロードするためにモジュールを使用する工程；及び
モジュールにおいて、ユーザーアプリケーションプロセスへの通知を生成する工程であって、それにより、ユーザーアプリケーションプロセスに専用の処理装置に関連したメモリから入力イベントデータのフレームを読み取らせる、工程
を含む、方法。

【請求項22】

専用の処理装置はグラフィック処理装置を含む、ことを特徴とする請求項２１に記載の方法。

【請求項23】

入力イベントデータのソースはセンサドライバを含む、ことを特徴とする請求項２１に記載の方法。

【請求項24】

入力イベントデータのソースは内部ジェネレータを含む、ことを特徴とする請求項２１に記載の方法。

【請求項25】

ユーザーアプリケーションプロセスは、処理のために専用の処理装置に入力イベントデータのフレームの少なくとも一部を送信する、ことを特徴とする請求項２１に記載の方法。

【請求項26】

専用の処理装置はグラフィック処理装置を含む、ことを特徴とする請求項２５に記載の方法。

【請求項27】

オペレーティングシステムにおいて実行するプロセスは、オペレーティングシステムのユーザーランド部分において実行するプロセスである、ことを特徴とする請求項２１に記載の方法。

【請求項28】

オペレーティングシステムにおいて実行するプロセスは、オペレーティングシステムのカーネル部分において実行するプロセスである、ことを特徴とする請求項２１に記載の方法。

【請求項29】

メモリに入力イベントデータのフレームをロードするためにモジュールを使用する工程は、既知の場所にあるラムベースのファイルに入力イベントデータのフレームを保存する工程を含む、ことを特徴とする請求項２１に記載の方法。

【請求項30】

メモリに入力イベントデータのフレームをロードするためにモジュールを使用する工程は、ヘッダー及び本体を含むデータ構造の部分として入力イベントデータのフレームを保存する工程を含む、ことを特徴とする請求項２１に記載の方法。

【請求項31】

本体は、入力イベントのＸ位置、入力イベントのＹ位置、及び、入力イベントデータが関連する入力イベントを識別する固有の識別子を含む、ことを特徴とする請求項３０に記載の方法。

【請求項32】

本体は、タッチサイズ、絶対的ｖｓ相対的なポジショニング、タッチのパスの速度、タッチのパスの曲率、圧力、タッチの形状、タッチのサイズ、タッチの回転、タッチのソース、及びタッチのアジマスから成る群から選択される、少なくとも１つのデータ型を含む、ことを特徴とする請求項３０に記載の方法。

【請求項33】

ヘッダーはタイムスタンプを含む、ことを特徴とする請求項３０に記載の方法。

【請求項34】

ヘッダーは、バイトで本体の長さを示すフィールドを含む、ことを特徴とする請求項３０に記載の方法。

【請求項35】

アプリケーションプロセスは、
ヘッダーを読み取ること；
バイトでの本体の長さをヘッダーから抽出すること；及び
本体の抽出された長さに基づいて入力イベントデータのフレームを読みとること
により、メモリから入力イベントデータのフレームを読み取る、ことを特徴とする請求項３０に記載の方法。

【請求項36】

入力イベントを待つユーザーアプリケーションプロセスを登録する工程は、プロセス識別子を含む情報を登録する工程を含み、該プロセス識別子はユーザーアプリケーションプロセスを固有に識別する、ことを特徴とする請求項２１に記載の方法。

【請求項37】

入力イベントを待つユーザーアプリケーションプロセスを登録する工程は、モジュールの予測された動作に関連したフラッグのビットマスクを含む情報を登録する工程を含む、ことを特徴とする請求項２１に記載の方法。

【請求項38】

通信チャネルは名前付きパイプを含む、ことを特徴とする請求項２１に記載の方法。

【請求項39】

通信チャネルはファイルを含む、ことを特徴とする請求項２１に記載の方法。

【請求項40】

通信チャネルはメモリ位置を含む、ことを特徴とする請求項２１に記載の方法。

【請求項41】

通信チャネルはソケットを含む、ことを特徴とする請求項２１に記載の方法。

【請求項42】

入力イベントデータのソースと、コンピューティング装置における入力イベントを待つ１以上のユーザーアプリケーションプロセスとの間で減少したレイテンシとの通信を可能にするように、オペレーティングシステムにおいて実行する、モジュールを利用するフレームベースの方法であって、該方法は、
入力イベントデータのソースからの入力イベントデータのフレームが読み取られる用意ができているという表示をポーリングするためにモジュールを使用する工程；
名前付きパイプから入力イベントデータのフレームを読み取るためにモジュールを使用する工程；
バッファに入力イベントデータのフレームをロードするためにモジュールを使用する工程；及び
モジュールにおいて、ユーザーアプリケーションプロセスへの通知を生成する工程であって、それによりユーザーアプリケーションプロセスにバッファから入力イベントデータのフレームを読み取らせる、工程
を含む、方法。

【請求項43】

入力イベントデータのソースはセンサドライバを含む、ことを特徴とする請求項４２に記載の方法。

【請求項44】

入力イベントデータのソースは内部ジェネレータを含む、ことを特徴とする請求項４２に記載の方法。

【請求項45】

ユーザーアプリケーションプロセスは、処理のために専用の処理装置に入力イベントデータのフレームの少なくとも一部を送信する、ことを特徴とする請求項４２に記載の方法。

【請求項46】

専用の処理装置はグラフィック処理装置を含む、ことを特徴とする請求項４２に記載の方法。

【請求項47】

オペレーティングシステムにおいて実行するモジュールは、オペレーティングシステムのユーザーランド部分において実行するモジュールである、ことを特徴とする請求項４２に記載の方法。

【請求項48】

オペレーティングシステムにおいて実行するモジュールは、オペレーティングシステムのカーネル部分において実行するモジュールである、ことを特徴とする請求項４２に記載の方法。

【請求項49】

バッファに入力イベントデータのフレームをロードするためにモジュールを使用する工程は、既知の場所にあるラムベースのファイルに入力イベントデータのフレームを保存する工程を含む、ことを特徴とする請求項４２に記載の方法。

【請求項50】

バッファに入力イベントデータのフレームをロードするためにモジュールを使用する工程は、ヘッダー及び本体を含むデータ構造の部分として入力イベントデータのフレームを保存する工程を含む、ことを特徴とする請求項４２に記載の方法。

【請求項51】

本体は、入力イベントのＸ位置、入力イベントのＹ位置、及び、入力イベントデータが関連する入力イベントを識別する固有の識別子を含む、ことを特徴とする請求項５０に記載の方法。

【請求項52】

本体は、タッチサイズ、絶対的ｖｓ相対的なポジショニング、タッチのパスの速度、タッチのパスの曲率、圧力、タッチの形状、タッチのサイズ、タッチの回転、タッチのソース、及びタッチのアジマスから成る群から選択される、少なくとも１つのデータ型を含む、ことを特徴とする請求項５０に記載の方法。

【請求項53】

ヘッダーはタイムスタンプを含む、ことを特徴とする請求項５０に記載の方法。

【請求項54】

ヘッダーは、バイトで本体の長さを示すフィールドを含む、ことを特徴とする請求項５０に記載の方法。

【請求項55】

アプリケーションプロセスは、
ヘッダーを読み取ること；
バイトでの本体の長さをヘッダーから抽出すること；及び
本体の抽出された長さに基づいて入力イベントデータのフレームを読みとること
により、バッファから入力イベントデータのフレームを読み取る、ことを特徴とする請求項５４に記載の方法。

【請求項56】

通信チャネルは名前付きパイプを含む、ことを特徴とする請求項４２に記載の方法。

【請求項57】

通信チャネルはファイルを含む、ことを特徴とする請求項４２に記載の方法。

【請求項58】

通信チャネルはメモリ位置を含む、ことを特徴とする請求項４２に記載の方法。

【請求項59】

通信チャネルはソケットを含む、ことを特徴とする請求項４２に記載の方法。

【請求項60】

入力イベントデータのソースと、コンピューティング装置における専用の処理装置において実行する入力イベントを待つプロセスとの間で減少したレイテンシとの通信を可能にするように、オペレーティングシステムにおいて実行する、モジュールを利用するフレームベースの方法であって、該方法は、
入力イベントデータのソースからの入力イベントデータのフレームが読み取られる用意ができているという表示をポーリングするためにモジュールを使用する工程；
名前付きパイプから入力イベントデータのフレームを読み取るためにモジュールを使用する工程；
専用の処理装置に関連したメモリに入力イベントデータのフレームをロードするためにモジュールを使用する工程；及び
モジュールにおいて、ユーザーアプリケーションプロセスへの通知を生成する工程であって、それにより、ユーザーアプリケーションプロセスに専用の処理装置に関連したメモリから入力イベントデータのフレームを読み取らせる、工程
を含む、方法。

【請求項61】

入力イベントデータのソースはセンサドライバを含む、ことを特徴とする請求項６０に記載の方法。

【請求項62】

入力イベントデータのソースは内部ジェネレータを含む、ことを特徴とする請求項６０に記載の方法。

【請求項63】

ユーザーアプリケーションプロセスは、処理のために専用の処理装置に入力イベントデータのフレームの少なくとも一部を送信する、ことを特徴とする請求項６０に記載の方法。

【請求項64】

専用の処理装置はグラフィック処理装置を含む、ことを特徴とする請求項６０に記載の方法。

【請求項65】

オペレーティングシステムにおいて実行するモジュールは、オペレーティングシステムのユーザーランド部分において実行するモジュールである、ことを特徴とする請求項６０に記載の方法。

【請求項66】

オペレーティングシステムにおいて実行するモジュールは、オペレーティングシステムのカーネル部分において実行するモジュールである、ことを特徴とする請求項６０に記載の方法。

【請求項67】

メモリに入力イベントデータのフレームをロードするためにモジュールを使用する工程は、既知の場所にあるラムベースのファイルに入力イベントデータのフレームを保存する工程を含む、ことを特徴とする請求項６０に記載の方法。

【請求項68】

メモリに入力イベントデータのフレームをロードするためにモジュールを使用する工程は、ヘッダー及び本体を含むデータ構造の部分として入力イベントデータのフレームを保存する工程を含む、ことを特徴とする請求項６０に記載の方法。

【請求項69】

本体は、入力イベントのＸ位置、入力イベントのＹ位置、及び、入力イベントデータが関連する入力イベントを識別する固有の識別子を含む、ことを特徴とする請求項６８に記載の方法。

【請求項70】

本体は、タッチサイズ、絶対的ｖｓ相対的なポジショニング、タッチのパスの速度、タッチのパスの曲率、圧力、タッチの形状、タッチのサイズ、タッチの回転、タッチのソース、及びタッチのアジマスから成る群から選択される、少なくとも１つのデータ型を含む、ことを特徴とする請求項６８に記載の方法。

【請求項71】

ヘッダーはタイムスタンプを含む、ことを特徴とする請求項６８に記載の方法。

【請求項72】

ヘッダーは、バイトで本体の長さを示すフィールドを含む、ことを特徴とする請求項６８に記載の方法。

【請求項73】

アプリケーションプロセスは、
ヘッダーを読み取ること；
バイトでの本体の長さをヘッダーから抽出すること；及び
本体の抽出された長さに基づいて入力イベントデータのフレームを読みとること
により、メモリから入力イベントデータのフレームを読み取る、ことを特徴とする請求項７２に記載の方法

【請求項74】

通信チャネルは名前付きパイプを含む、ことを特徴とする請求項６０に記載の方法。

【請求項75】

通信チャネルはファイルを含む、ことを特徴とする請求項６０に記載の方法。

【請求項76】

通信チャネルはメモリ位置を含む、ことを特徴とする請求項６０に記載の方法。

【請求項77】

通信チャネルはソケットを含む、ことを特徴とする請求項６０に記載の方法。

【請求項78】

低レイテンシのタッチセンス装置であって、該タッチセンス装置は：
タッチ表面に関して指又は物体の場所を感知し、電子装置への現在のユーザー入力を示すデータを作成することができるタッチセンサ；
プロセッサ
を含み、
該プロセッサは、
ｉ）オペレーティングシステムにおいて実行するモジュールにより入力イベントを待つユーザーアプリケーションプロセスを登録し、それによりユーザーアプリケーションプロセスをモジュールから通知の標的であると識別し；
ｉｉ）モジュールにおいて、入力イベントデータのソースからの入力イベントデータのフレームが読み取られる用意ができているという通知を受信し；
ｉｉｉ）名前付きパイプから入力イベントデータのフレームを読み取るためにモジュールを使用し；
ｉｖ）バッファに入力イベントデータのフレームをロードするためにモジュールを使用し；及び
ｖ）モジュールにおいて、ユーザーアプリケーションプロセスへの通知を生成し、それによりユーザーアプリケーションプロセスにバッファから入力イベントデータのフレームを読み取らせる
ように構成される、ことを特徴とする低レイテンシのタッチセンス装置。

【請求項79】

低レイテンシのタッチセンス装置であって、該タッチセンス装置は：
タッチ表面に関して指又は物体の場所を感知し、電子装置への現在のユーザー入力を示すデータを作成することができるタッチセンサ；
プロセッサ
を含み、
該プロセッサは、
ｉ）オペレーティングシステムにおいて実行するモジュールにより入力イベントを待つユーザーアプリケーションプロセスを登録し、それによりユーザーアプリケーションプロセスをモジュールから通知の標的であると識別し；
ｉｉ）モジュールにおいて、入力イベントデータのソースからの入力イベントデータのフレームが読み取られる用意ができているという通知を受信し；
ｉｉｉ）名前付きパイプから入力イベントデータのフレームを読み取るためにモジュールを使用し；
ｉｖ）専用の処理装置に関連したメモリに入力イベントデータのフレームをロードするためにモジュールを使用し；及び
ｖ）モジュールにおいて、ユーザーアプリケーションプロセスへの通知を生成し、それにより、ユーザーアプリケーションプロセスに専用の処理装置に関連したメモリから入力イベントデータのフレームを読み取らせる
ように構成される、ことを特徴とする低レイテンシのタッチセンス装置。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、モジュール間通信用のシステム及び方法に関するものである。

【図面の簡単な説明】

【0002】

本発明の目的、特徴、及び利点は、添付図面に示されるような、以下の好ましい実施形態から明らかとなり、図中、参照符号は様々な視点を通じて同じ部分を指すものとする。図面は、必ずしも正確な縮尺ではなく、その代わりに重点は、本発明の原理を概説することに置かれている。

【図1】既存の入力イベントスタック内にあり、且つタッチ処理装置（ＴＰＵ）を用いて改善されたスタック内にある、システムの構成要素間の相互作用を図示する、フロー図を示す。

【図2】カーネルタッチ処理装置（ＫＴＰＵ）の実装を図示するフロー図を示す。

【図3】ユーザーアプリケーションからのタッチ処理装置の利用を図示するフロー図を示す。

【発明を実施するための形態】

【0003】

ここで、本発明の好ましい実施形態に対する詳細な言及が行われ、その例は添付図面に示される。以下の記載及び図面は例示的なものであり、限定的なものとして解釈されるべきではない。多数の特定の詳細が、完全な理解をもたらすように記載される。しかし、特定の例において、記載を曖昧なものにすることを回避するために、周知又は従来の詳細は記載されない。本開示における実施形態に対する言及は、必ずしも同じ実施形態に対する言及ではなく、そのような言及は少なくとも１つを意味する。

【0004】

本開示の全体にわたり、用語「タッチ（ｔｏｕｃｈ）」、「タッチ（ｔｏｕｃｈｅｓ）」、「タッチイベント（ｔｏｕｃｈ ｅｖｅｎｔ）」、「入力イベント（ｉｎｐｕｔ ｅｖｅｎｔ）」、「接触（ｃｏｎｔａｃｔ）」、又は他の記述語は、入力イベント、又は、ユーザーの指、スタイラス、物体、又は身体部分がセンサにより検出される期間を説明するために使用され得る。幾つかの実施形態において、ユーザーが、センサ、又はセンサが埋め込まれる装置と物理的に接触した場合にのみ、このような検出が生じる。他の実施形態において、センサは、タッチ表面上の距離をホバリングしている、又はその他にタッチセンス装置から分離されている、「タッチ」又は「接触」の検出を可能にするように調整され得る。それ故、感知された物理的接触に対する依存を暗示する、このような記載における言語の使用は、記載された技術がそのような実施形態のみに適用され、実際には、本明細書に記載されるもののほぼ全て（全てではない）が、「タッチ」及び「ホバー」のセンサに等しく適用されることを意味すると、捉えられるべきではない。本明細書で使用されるように、句「タッチイベント」及び「入力イベント」、並びに単語「タッチ」は、名詞として使用される場合、近くのタッチ、及び近くのタッチイベント、又はセンサを使用して識別され得る他のジェスチャを含む。

【0005】

本明細書における「一実施形態（ａｎ ｅｍｂｏｄｉｍｅｎｔ）」又は「実施形態（ｔｈｅ ｅｍｂｏｄｉｍｅｎｔ）」に対する言及は、実施形態に関連して記載される特定の機能、構造、又は特徴が、本開示の少なくとも１つの実施形態に含まれることを意味している。本明細書の様々な場所にある句「一実施形態において」の出現は、必ずしも全てが同じ実施形態を指しておらず、他の実施形態に相容れない別個の又は代替的な実施形態でもない。更に、幾つかの実施形態により示されるが他の実施形態によっては示されない、様々な特徴が記載される。同様に、他の実施形態ではなく幾つかの実施形態の必要条件となり得る、様々な必要条件が記載される。

【0006】

モジュール間通信用の方法及び装置のブロック図と作動図面を参照すると共に、本発明を以下に記載する。このブロック図又は作動図面の各ブロック、及びブロック図又は作動図面のブロックの組み合せが、アナログ又はデジタルのハードウェア及びコンピュータプログラム命令によって実施され得ることを理解されたい。このようなコンピュータプログラム命令は、コンピュータ可読媒体に保存され、且つ、汎用コンピュータ、専用コンピュータ、ＡＳＩＣ、又は他のプログラム可能なデータ処理装置のプロセッサに提供されてもよく、これにより、コンピュータ又は他のプログラム可能なデータ処理装置のプロセッサによって実行される命令が、ブロック図又は動作ブロックで指定された機能／動作を実行する。幾つかの代替的な実施において、ブロック内で説明される機能／動作は、動作図面の中で説明される順序とは異なる順序で生じ得る。例えば、連続して示される２つのブロックは実際に、関与する機能／動作に応じて、ほぼ同時に実行されるか、又は時に逆の順序で実行されてもよい。

【0007】

対話型装置は、ユーザー入力を検出するセンサと、入力を処理し、データ上で動作を行い、且つ視覚応答を生成する計算要素と、及びこのような計算の結果をユーザーに出力する出力装置とを含む、多くの部品で構成される。ユーザー入力（例えば、指がタッチスクリーンにタッチする）を表示された応答に変換するよう要求される動作のパイプラインは、即時のものではなく、パイプラインの各部品は、データ上で計算を行うのに必要とされる時間、正確な応答に必要とされる追加情報へのアクセスに必要とされる時間、１つのシステム要素から別の要素に情報を渡すのに必要とされる時間、装置上で行われる競争過程（ｃｏｍｐｅｔｉｎｇ ｐｒｏｃｅｓｓｅｓ）など、多くの理由のためにレイテンシを導入する。このパイプラインの任意の部品に対する改善は、装置の全体的なレイテンシを改善し得る。

【0008】

本発明の目的は、対話型装置がユーザー入力に対してより迅速に応答できるようにすることである。本発明において、我々は、対話型装置における後続の（ｉｎｃｏｍｉｎｇ）ユーザー入力をより迅速に扱うために、処理及び部品間の通信がどのように改善されるのかについて概説する。パイプラインのこのような部品の改善により、本発明は、非常に望ましい目的である、より反応の良い対話型装置を可能にする。

【0009】

本開示の焦点は、ハードウェア状態のキャプチャの要因であるプロセスと、オペレーティングシステムやユーザーアプリケーションなどへの情報のアップストリームの配布の要因であるプロセスとの間の通信である。このワークフローは多くの部分を包含しており、イベントの読み取りから、イベントの発生、プロセスへの通知、通知される対象となるプロセスの登録、共有メモリ（ファイル、ラム（ｒａｍ）、パイプなど）への情報の保存、通知されたプロセスによる共有メモリからのイベントの読み取り、プロセスの登録取り消し、及び他の構成要素を包含する。

【0010】

本発明の構成要素の１つは、カーネルタッチ処理装置（ＫＴＰＵ）である。一実施形態において、これは、入力イベント（例えば、タッチイベント）を生成するセンサドライバ、及びこのタッチデータを受信するために待機しているユーザーアプリケーションの両方と、相互に作用するモジュールである。ｅｖＤｅｖなどの他のモジュールは従来、この機能性の要因であったが、典型的にはテキストプロトコルにおけるイベントを構築する。ＫＴＰＵは、ヒトが読み取りできるものではなく、可能な限り早くイベントを「ストリーミングする」ように意図されている。ＫＴＰＵからイベントを受信するための可能な１つの手順は、モジュールにより入力イベント（例えば、タッチイベント）を予測するプロセスを登録し、且つ通信チャネル（名前付きパイプ、ファイル、メモリ、又はソケット）からイベントを読み取る、ユーザーランドアプリケーションを含んでいる。このアプリケーションは、ファイルからのイベントをポーリング（ｐｏｌｌ）し、且つ通知の受信後にイベントを読み取ることが出来る。

【0011】

＜イベントを受信する初期化処理＞
一実施形態において、ユーザープロセスは、初期化する場合、入力イベントが読み取られる用意ができていることを通知した後に何らかの処理を行うために、最初にシグナルハンドラーを登録する。ユーザープロセスは、それ自体をモジュールから通知のための標的であると識別するために何らかの方法を提供する必要がある。これを行うための多くの方法が存在する。一実施形態において、入力イベントの受信の対象であるユーザープロセスは、プロセスＩＤ（ＰＩＤ）を含有する構造、及び、イベントを受信する用意ができていることを示すフラッグを作成し、既知の場所においてファイルにこの構造を書き込む。他の実施形態において、ファイルは、単一のＰＩＤ構造（イベントを受信するシングルユーザープロセスを結果としてもたらす）、又は複数のＰＩＤ構造（イベントを受信する複数のプロセスを結果としてもたらし、潜在的にそれらの間で多重化される）を含有し得る。他の実施形態において、通信チャネル（例えば名前付きパイプ）は、既知の場所にはなく、プロセスとモジュールの間の初期の通信の結果として送り返される。

【0012】

イベントを受信する複数のプロセスの場合、本発明の実施形態は、イベントを受信するように登録するプロセスの情報を保存するためのキュー（ｑｕｅｕｅ）又は同様の集まりを含む。別の実施形態において、複数のプロセスが登録され得るが、プロセスがフォアグラウンドにおいて実行している、又はユーザーに着目している場合には、通知イベントしか受信しない。

【0013】

別の実施形態は、プロセスを通知するための通知（例えば、インタラプト、メッセージ、又は通知の役目を果たす他の電子信号）を利用し得る。この実施形態は、プロセス登録中に送信されているデータにおける、プロセスが受信することを予測している信号数を含んでいる。これは、信号処理がアプリケーションに特異的であり得るためユーザーの観点から有益な場合があり、多くの信号が既にアプリケーションにより扱われる場合もある。これはまた、プロセスに通知を送信しないようにするが、生成されているタッチイベントを消費するためにモジュールをポーリングしているアプリケーションが存在するカーネルを更に通知する登録を含むように、拡張され得る。

【0014】

一旦プロセスがイベントを受信するよう成功裡に登録されると、ＫＴＰＵがイベントを受信する場合は常に、信号は装置へと送信されねばならない。現在、イベントは一定時間で同じモジュールにおいて生成されているため、イベントのプロセスとの関連性は、情報を受信するために登録するユーザープロセスから生じる。一実施形態において、複数のプロセスが、イベント通知を受信するように割り当てられ得る。これは、別のプロセス（又はカーネルモジュール）において通知されるプロセスのために、各ピクセル又はタッチポイントと、所与の識別子との間の関連性を保存することにより、行われ得る。

【0015】

一実施形態において、通知の受信後、最近生成されたイベントに関係する情報は、ＲＡＭベースのファイル（例えばｄｅｂｕｇｆｓファイルなど）にある既知の場所に保存される。このプロセスは、ファイルに対してオープンファイルディスクリプタを有し、ファイルからヘッダーを読み取り、ヘッダーから読み取るためのデータの長さを抽出し、次いでファイルからイベントデータの本体を読み取ると、予想される。このことは全て、次のイベントが古いイベントの構築を回避するように生成される前に、行われてもよい。他の実施形態において、情報の解析は、当業者に既知の技術により実行され得る。

【0016】

＜データ構造のフォーマット及びファイルロケーション＞
イベントに必要な情報をカプセル化する任意のデータ構造は、潜在的に我々の発明に適合する。一実施形態において、イベントデータの構造は、ヘッダーと本体に分けられる。

【0017】

ヘッダーは、以下のフィールドから成り得る：
タイムスタンプ−イベントのフレームが生成されたシステム時間。タイムスタンプは、秒及びナノ秒のフィールドにおいてシステムのランタイムを保存し、その順は、カーネルにおいて与えられるｔｉｍｅｓｐｅｃ ｓｔｒｕｃｔの定義の中で指定される。
タイプ−その時点で送信されているフレームのタイプ。
長さ−バイトでのメッセージの長さ。

【0018】

イベントデータのメッセージの本体は、幾つかのタッチイベントの完全なフレームから成る。各タッチイベントは現時点で、増加するアドレスの順で、以下のフィールドから成る：
Ｘ−タッチイベントの符号付きｘ位置
Ｙ−タッチイベントの符号付きｙ位置
ＩＤ−どのタッチが（スロットを比較する）ものであるかを追跡するように含まれる数値のＩＤ

【0019】

他の実施形態は以下の情報を含み得る：
−タッチサイズ
−絶対的ｖｓ相対的なポジショニング
−タッチのパスの速度
−タッチのパスの曲率
−圧力（等）
−タッチの形状
−タッチのサイズ
−タッチの回転
−タッチのソース（例えば、「ユーザーＡ」、「ユーザーＢ」、「スタイラス＃１２８８５」、「ユーザーＣの左手」、「ユーザーＤの人差し指」など）
−タッチのアジマス

【0020】

一実施形態において、プロセス登録情報は、以下のフィールドを含有している：
−プロセスＩＤ（４Ｂ）−プログラムからデータを受信するように登録したプロセスのＰＩＤ
−フラッグ（４Ｂ）−モジュールの予測された動作に関するフラッグのビットマスク。フラッグは以下のパターンに従う：
ビット３１−１（ＭＳＢ）：未使用
ビット０（ＬＳＢ）：通知を可能にする
ビット０（ＬＳＢ）：通知を可能にする

【0021】

＜初期設定＞
一実施形態において、ユーザープロセスに送信される信号又は他の通知は、常にアプリケーションで定義され、それ故、この計画の必要性に適していなければならない値である、ＰＯＳＩＸ実時間信号の値「ＳＩＧＲＴＭＩＮ」を使用する。他の実施形態は異なる信号／通知を使用し得る。シグナルハンドラーの実装は現時点で、アプリケーションの開発者の責務であり、この開発者は、イベントファイルから新たなイベントフレームをデータが読み取る用意ができ、且つ読み取り始めることをアプリケーションロジックに通知する、短い機能を作成しなければならない。

【0022】

プロセスがファイルに所定の長さのデータを書き込む場合、その長さが登録情報の構造よりも長いと、書き込み動作は−ＥＩＯのエラーコードを送り返す。より短い長さのデータを書き込んだ結果、データは、現在の書き込み位置において環状バッファにコピーされることとなる。一旦データがバッファにコピーされると、バッファの更新された内容は、通知されるプロセスのデータを保存する可変カーネル（ｋｅｒｎｅｌ ｖａｒｉａｂｌｅ）にロードされる。登録データの書き込みはアトミック（ａｔｏｍｉｃ）であると仮定される。このファイル上で行なわれる全ての書き込みは、登録構造のサイズの倍数となることが予想される。そうでない場合には、構造におけるデータは誤って調整され、恐らく破損することになる。

【0023】

＜イベント生成及びモジュール通知＞
一旦ＫＴＰＵモジュールがソース（内部ジェネレータ又はセンサドライバのいずれか）からタッチイベントを通知されると、ＫＴＰＵモジュールは、環状バッファにイベントをロードし、十分な空きスペースがない場合にはバッファ中の最も古いイベントに上書きしなければならない。一旦イベントが環状バッファに書き込まれると、通知スレッドは、現在保存されているＩＤによりプロセスにＲＴＳＩＧＭＩＮの値を含むＰＯＳＩＸ信号を送信する。

【0024】

＜タッチイベントの読み取り＞
通知がアプリケーションに伝えられる場合、イベントはバッファの内部に保存されねばならない。ユーザーアプリケーションは、メモリ中のバッファを指し示す既知のファイルロケーションからヘッダーを読み取ることが予想される。

【0025】

一実施形態において、最初にバッファから読み取られるものは、固定された既知の長さであるイベントのヘッダーである。このヘッダーは、バッファにおいてヘッダーの直後に続く、本体の長さを含有している。これは、ヘッダーから得た長さのファイルに対する別の読み取りを介して、獲得され得る。各タッチイベントが固定されたサイズであるため、合計の長さは、そのサイズの数倍である。この実施形態において、作成者は一人で十分であることが仮定される。これは、モジュールを使用するユーザーアプリケーションにおいて良く秩序立った行動の必要性を作り出す。他の実施形態において、複数の作成者はマルチスレッドの安全な実装を必要とする。

【0026】

＜終了化（Ｄｅｉｎｉｔｉａｌｉｚａｔｉｏｎ）／登録解除＞
モジュールが適切に閉じることができることを確実にするために、一旦アプリケーションがこれ以上ファイルに対して読み取り又は書き込みを行わない場合、各ファイル操作を閉じることが重要な場合もある。プロセス登録ファイルにおいて可能なフラッグをリセットし、随意に、ファイルに含まれるＰＩＤを０にまでリセットすることも重要であり得る。これにより、次のプロセスの登録の用意をするために、イベントバッファが取り除かれるはずである。

【0027】

＜本発明のＧＰＵへの入力の変形（Ｉｎｐｕｔ−Ｔｏ−ＧＰＵ Ｖａｒｉａｔｉｏｎ）＞
別の実施形態において、イベントの消費の原因であるユーザープロセスは、専用の処理装置（例えばＧＰＵ）の内部に存在する。この実施形態において、データは、カーネル空間からＧＰＵメモリへと直接進む。他の実施形態において、情報は、最初にユーザー空間プロセスに伝えられ、次に専用の処理装置にのみ送信される。

【0028】

図１は、既存のタッチイベントスタック内にあり、且つタッチ処理装置（ＴＰＵ）を用いて改善されたスタック内にある、構成要素間の相互作用の概要を示す。処理装置に対する他の方法は、例えば、「Ｈｙｂｒｉｄ Ｓｙｓｔｅｍｓ Ａｎｄ Ｍｅｔｈｏｄｓ Ｆｏｒ Ｌｏｗ−Ｌａｔｅｎｃｙ Ｕｓｅｒ Ｉｎｐｕｔ Ｐｒｏｃｅｓｓｉｎｇ Ａｎｄ Ｆｅｅｄｂａｃｋ」と題された２０１３年１０月４日出願の米国特許出願第１４／０４６，８１９号、「Ｌｏｗ−Ｌａｔｅｎｃｙ Ｔｏｕｃｈ Ｓｅｎｓｉｔｉｖｅ Ｄｅｖｉｃｅ」と題された２０１３年３月１５日出願の米国特許出願第１３／８４１，４３６号、「Ｆａｓｔ Ｍｕｌｔｉ−Ｔｏｕｃｈ Ｓｔｙｌｕｓ」と題された２０１３年３月１５日出願の米国仮特許出願第６１／７９８，９４８号、「Ｆａｓｔ Ｍｕｌｔｉ−Ｔｏｕｃｈ Ｓｅｎｓｏｒ Ｗｉｔｈ Ｕｓｅｒ−Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ Ｔｅｃｈｎｉｑｕｅｓ」と題された２０１３年３月１５日出願の米国仮特許出願第６１／７９９，０３５号、「Ｆａｓｔ Ｍｕｌｔｉ−Ｔｏｕｃｈ Ｎｏｉｓｅ Ｒｅｄｕｃｔｉｏｎ」と題された２０１３年３月１５日出願の米国仮特許出願第６１／７９８，８２８号、「Ａｃｔｉｖｅ Ｏｐｔｉｃａｌ Ｓｔｙｌｕｓ」と題された２０１３年３月１５日出願の米国仮特許出願第６１／７９８，７０８号、「Ｈｙｂｒｉｄ Ｓｙｓｔｅｍｓ Ａｎｄ Ｍｅｔｈｏｄｓ Ｆｏｒ Ｌｏｗ−Ｌａｔｅｎｃｙ Ｕｓｅｒ Ｉｎｐｕｔ Ｐｒｏｃｅｓｓｉｎｇ Ａｎｄ Ｆｅｅｄｂａｃｋ」と題された２０１３年１０月５日出願の米国仮特許出願第６１／７１０，２５６号、「Ｆａｓｔ Ｍｕｌｔｉ−Ｔｏｕｃｈ Ｐｏｓｔ Ｐｒｏｃｅｓｓｉｎｇ」と題された２０１３年７月１２日出願の米国仮特許出願第６１／８４５，８９２号、「Ｒｅｄｕｃｉｎｇ Ｃｏｎｔｒｏｌ Ｒｅｓｐｏｎｓｅ Ｌａｔｅｎｃｙ Ｗｉｔｈ Ｄｅｆｉｎｅｄ Ｃｒｏｓｓ−Ｃｏｎｔｒｏｌ Ｂｅｈａｖｉｏｒ」と題された２０１３年７月１２日出願の米国仮特許出願第６１／８４５，８７９号、「Ｓｙｓｔｅｍｓ Ａｎｄ Ｍｅｔｈｏｄｓ Ｆｏｒ Ｐｒｏｖｉｄｉｎｇ Ｒｅｓｐｏｎｓｅ Ｔｏ Ｕｓｅｒ Ｉｎｐｕｔ Ｕｓｉｎｇ Ｉｎｆｏｒｍａｔｉｏｎ Ａｂｏｕｔ Ｓｔａｔｅ Ｃｈａｎｇｅｓ Ａｎｄ Ｐｒｅｄｉｃｔｉｎｇ Ｆｕｔｕｒｅ Ｕｓｅｒ Ｉｎｐｕｔ」と題された２０１３年９月１８日出願の米国仮特許出願第６１／８７９，２４５号、「Ｓｙｓｔｅｍｓ Ａｎｄ Ｍｅｔｈｏｄｓ Ｆｏｒ Ｐｒｏｖｉｄｉｎｇ Ｒｅｓｐｏｎｓｅ Ｔｏ Ｕｓｅｒ Ｉｎｐｕｔ Ｕｓｉｎｇ Ｉｎｆｏｒｍａｔｉｏｎ Ａｂｏｕｔ Ｓｔａｔｅ Ｃｈａｎｇｅｓ Ａｎｄ Ｐｒｅｄｉｃｔｉｎｇ Ｆｕｔｕｒｅ Ｕｓｅｒ Ｉｎｐｕｔ」と題された２０１３年９月２１日出願の米国仮特許出願第６１／８８０，８８７号、「Ｈｙｂｒｉｄ Ｓｙｓｔｅｍｓ Ａｎｄ Ｍｅｔｈｏｄｓ Ｆｏｒ Ｌｏｗ−Ｌａｔｅｎｃｙ Ｕｓｅｒ Ｉｎｐｕｔ Ｐｒｏｃｅｓｓｉｎｇ Ａｎｄ Ｆｅｅｄｂａｃｋ」と題された２０１３年１０月４日出願の米国特許出願第１４／０４６，８２３号、「Ｆａｓｔ Ｍｕｌｔｉ−Ｔｏｕｃｈ Ｐｏｓｔ Ｐｒｏｃｅｓｓｉｎｇ」と題された２０１３年１１月１日出願の米国特許出願第１４／０６９，６０９号、及び「Ｔｏｕｃｈ Ａｎｄ Ｓｔｙｌｕｓ Ｌａｔｅｎｃｙ Ｔｅｓｔｉｎｇ Ａｐｐａｒａｔｕｓ」と題された２０１３年１０月７日出願の米国仮特許出願第６１／８８７，６１５号に記載されている。それらの出願の全体的な開示は、参照により本明細書に組み込まれる。

【0029】

図２は、カーネルタッチ処理装置（ＫＴＰＵ）の実装の概要を示す。

【0030】

図３は、ユーザーアプリケーションからのタッチ処理装置の利用を示す。

【0031】

一実施形態において、入力イベントデータのソースと、コンピューティング装置における入力イベントを待つ１以上のユーザーアプリケーションプロセスとの間で減少したレイテンシとの通信を可能にするように、オペレーティングシステムにおいて実行する、モジュールを利用するフレームベースの装置及び方法が、提供される。入力イベントを待つユーザーアプリケーションプロセスは、オペレーティングシステムにおいて実行するモジュールにより登録され、それによりユーザーアプリケーションプロセスをモジュールから通知の標的であると識別する。モジュールは、入力イベントデータのソースからの入力イベントデータのフレームが読み取られる用意ができていることを示す通知を受信する。これを受けて、モジュールは、通信チャネルから入力イベントデータのフレームを読み取り、バッファに入力イベントデータのフレームをロードするためにモジュールを使用し、ユーザーアプリケーションプロセスへの通知を生成し、それにより、ユーザーアプリケーションプロセスにバッファから入力イベントデータのフレームを読み取らせる。

【0032】

別の実施形態において、入力イベントデータのソースと、コンピューティング装置における専用の処理装置において実行する入力イベントを待つプロセスとの間で減少したレイテンシとの通信を可能にするように、オペレーティングシステムにおいて実行する、モジュールを利用するフレームベースの装置及び方法が、提供される。入力イベントを待つユーザーアプリケーションプロセスは、オペレーティングシステムにおいて実行するモジュールにより登録され、それによりユーザーアプリケーションプロセスをモジュールから通知の標的であると識別する。モジュールは、入力イベントデータのソースからの入力イベントデータのフレームが読み取られる用意ができているという通知を受信する。これを受けて、モジュールは、通信チャネルから入力イベントデータのフレームを読み取り、専用の処理装置に関連するメモリに入力イベントデータのフレームをロードし、ユーザーアプリケーションプロセスへの通知を生成し、それにより、ユーザーアプリケーションプロセスに専用の処理装置に関連するメモリから入力イベントデータのフレームを読み取らせる。

【0033】

別の実施形態において、入力イベントデータのソースと、コンピューティング装置における専用の処理装置において実行する入力イベントを待つプロセスとの間で減少したレイテンシとの通信を可能にするように、オペレーティングシステムにおいて実行する、モジュールを利用するフレームベースの装置及び方法が、提供される。モジュールは、入力イベントデータのソースからの入力イベントデータのフレームが読み取られる用意ができている表示をポーリングする。このような表示を受信した後、モジュールは、名前付きパイプから入力イベントデータのフレームを読み取り、バッファに入力イベントデータのフレームをロードし、ユーザーアプリケーションプロセスへの通知を生成し、それにより、ユーザーアプリケーションプロセスにバッファから入力イベントデータのフレームを読み取らせる。

【0034】

本明細書に開示される少なくとも幾つかの態様は、ソフトウェア中に少なくとも部分的に埋め込まれ得る。即ち、この技術は、マイクロプロセッサなどのそのプロセッサに応じて、専用又は汎用コンピュータシステム、或いは他のデータ処理システムにおいて実行され得、ＲＯＭ、揮発性ＲＡＭ、不揮発性メモリ、キャッシュ、又は遠隔記憶装置などのメモリに包含される一連の命令の順序を実行する。

【0035】

実施形態を実施するために行われるルーチンは、オペレーティングシステム、ファームウェア、ＲＯＭ、ミドルウェア、サービス配信プラットホーム、ＳＤＫ（Ｓｏｆｔｗａｒｅ Ｄｅｖｅｌｏｐｍｅｎｔ Ｋｉｔ）コンポーネント、ウェブサービス、又は他の特定のアプリケーション、コンポーネント、プログラム、オブジェクト、モジュール、又は「コンピュータプログラム」と称される一連の命令の一部として、実施され得る。このようなルーチンへの呼び出しインターフェースは、ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）として、ソフトウェア開発コミュニティーにあらわにされ得る。コンピュータプログラムは典型的に、コンピュータ中の様々なメモリ及び記憶装置において様々な時間に設定されるとともに、コンピュータ中の１以上のプロセッサにより読み取られて実行された場合に、コンピュータに様々な態様を含む要素を実行するのに必要な動作を行なわせる、１以上の命令を含んでいる。

【0036】

データ処理システムにより実行される場合にシステムに様々な方法を実行させるソフトウェア及びデータを保存するために、機械可読媒体が使用され得る。実行可能なソフトウェア及びデータは、例えばＲＯＭ、揮発性ＲＡＭ、不揮発性メモリ、及び／又はキャッシュを含む、様々な場所に保存され得る。このソフトウェア及び／又はデータの部分は、このような記憶装置の何れか１つに保存されてもよい。更に、データ及び命令は、統括サーバー又はピアツーピアネットワークから獲得され得る。データ及び命令の異なる部分は、異なる時点で、及び異なる通信セッション或いは同じ通信セッションにおいて、異なる統括サーバー及び／又はピアツーピアネットワークから獲得され得る。データ及び命令は、アプリケーションの実行前に全体を獲得することができる。代替的に、データ及び命令の部分は、実行に必要とされる場合、時間通り動的に獲得され得る。故に、データ及び命令は、特定の例の時間において全体が機械可読媒体上にある必要はない。

【0037】

コンピュータ可読媒体の例は、限定されないがとりわけ、揮発性及び不揮発性のメモリ装置、読み取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、フラッシュメモリ装置、フロッピー、及び他のリムーバブルディスクなどの記録可能型及び非記録可能型の媒体、磁気ディスク記憶装媒体、光学記憶装置媒体（例えば、読み取り専用コンパクトディスク（ＣＤ ＲＯＭＳ）、デジタル多用途ディスク（ＤＶＤ）など）を含んでいる。

【0038】

通常、機械可読媒体は、機械（例えば、コンピュータ、ネットワークデバイス、携帯情報端末、製造ツール、１以上のプロセッサのセットを持つ任意の装置など）によりアクセス可能な形態で情報を提供する（例えば保存する）、任意の機構を含んでいる。

【0039】

様々な実施形態において、ハードワイヤード回路が、前記技術を実施するためにソフトウェア命令と組み合わせて使用されてもよい。故に、前記技術は、ハードウェア回路とソフトウェアの任意の特異的な組み合わせにも、データ処理システムにより実行された命令のための特定のソースにも限定されない。

【0040】

上述の実施形態及び嗜好性は、本発明の実例となる。この特許は、全ての起こり得る組み合わせ又は実施形態を概説又は定義する必要はなく、またそのようには意図されていない。本発明者は、当業者が本発明の少なくとも１つの実施形態を実施することを可能にするのに十分な情報を開示している。上述の記載及び図面は、本発明の単なる実例であり、構成要素、構造、及び手順の変更は、以下の請求項に定義されるように本発明の範囲から逸脱することなく可能である。例えば、特定の順で上記及び／又は以下の請求項に記載される要素及び／又は工程は、本発明から逸脱することなく異なる順で実行されてもよい。故に、本発明は、その実施形態への言及と共に明確に示され且つ記載される一方で、形式及び詳細の様々な変更は、本発明の精神と範囲から逸脱することなく、その中で行なわれ得ることが、当業者によって理解される。

【図1】

【図2】

【図3】

【国際調査報告】