(57)【要約】【解決手段】モバイル動作環境において実行されるモバイルアプリケーションの安全で効率的な通信を提供することが、本明細書で述べられる。例として、プライマリアプリケーションは、プライマリアプリケーションのユニークな識別子と、応答要求に署名し及び／または認証するためのランダムな番号とを含むハンドシェイクをイニシエイト出来る。レシピエントアプリケーションは、ユニークな識別子を認証されたプライマリアプリケーションのリストに照会し、プライマリアプリケーションを確認出来る。もし確認されれば、レシピエントは、プライマリアプリケーションにより送信されたデータ要求に署名し及び／または認証出来る第２のランダムな番号とランダムな番号と共に応答する。ある形態によれば、ランダムな番号はハッシュ及び／または切り捨てられることで、その番号の低パワー暗号化が提供される。更に、ラウンドトリップポリシーが実現される。【選択図】図１
2010511965.tif 000002
【特許請求の範囲】
【請求項１】
モバイル動作環境におけるアプリケーション間のデータ通信を提供する方法であって、
プライマリモバイルアプリケーションのユニークな識別子と、ハンドシェイクのために生成されたランダムな番号とを含む、モバイルアプリケーションとの前記ハンドシェイクをイニシエイトすることと、
前記ハンドシェイクに対する、少なくとも第２の番号を含む応答を、受信し確認することと、
もし前記ハンドシェイクに対する前記応答が確認されれば、前記第２の番号または前記第２の番号のバージョン（version）を含むデータイベントを、モバイルアプリケーションに対して送信することと、
前記モバイルアプリケーションからデータイベントの応答が受信されるまで、前記プライマリアプリケーションの実行を禁止することと
を備え、前記データイベントの応答は、少なくとも前記第２の番号または前記第２の番号のバージョンを含む、方法。
【請求項２】
もし前記データイベントの応答が前記モバイルアプリケーションから受信されなければ、前記データイベントを再送信すること、を更に備える請求項１の方法。
【請求項３】
前記データイベントの応答が受信されるまで、設定可能な回数のデータイベントの再送信を実行すること、を更に備える請求項１の方法。
【請求項４】
前記モバイルアプリケーションと前記プライマリモバイルアプリケーションとの間のインターフェースにおけるパケットロスの頻度または可能性を判断して、データイベントの再送信の前記設定可能な回数を決定すること、を更に備える請求項３の方法。
【請求項５】
もし、前記設定可能な回数のデータイベントの再送信の後、前記データイベントの応答が受信されなければ、前記ハンドシェイクを再度イニシエイトすること、を更に備える請求項３の方法。
【請求項６】
もし、前記ハンドシェイクに対する応答、または前記データイベントの応答が、しきい期間内に前記モバイルアプリケーションから受信されなければ、前記ハンドシェイクを再度イニシエイトすること、を更に備える請求項１の方法。
【請求項７】
前記ランダムな番号を変換するため、または前記第２の番号のバージョンを生成するために、ハッシュ関数を使用すること、
前記ランダムな番号または前記第２の番号を切り捨てて（truncate）、アプリケーションのインターフェースが別の方法で調整された場合よりも大きい番号の送信を可能とすること、
前記第２の番号をインクリメントして、前記第２の番号のバージョンを生成すること、または
前記第２の番号を暗号化して、前記第２の番号のバージョンを生成すること、
の少なくともいずれかを更に備える、請求項１の方法。
【請求項８】
もし前記第１の番号が前記ランダムな番号として確認されなければ、ハンドシェイクの終了（termination）をイニシエイトすること、を更に備える請求項１の方法。
【請求項９】
単一のモバイル機器を用いて、前記モバイルアプリケーションと前記プライマリモバイルアプリケーションとを通信可能に結合し、実行すること、を更に備える請求項１の方法。
【請求項１０】
前記プライマリモバイルアプリケーションを保持し実行する第１の機器と、前記モバイルアプリケーションを保持し実行し、前記第１の機器から離隔して位置する第２の機器とを用いること、を更に備え、
前記第１及び第２の機器は、有線または無線ネットワーク、またはその両方により、通信可能に結合されている、請求項１の方法。
【請求項１１】
前記ハンドシェイクをイニシエイトすることと、前記ハンドシェイクに対する前記応答を受信することとの間に要する時間から、予測される応答時間を算出することと、
もし前記予測される応答時間内に前記データイベントの応答が受信されなければ、
引き続くハンドシェイクがイニシエイトされ確認されるまで、前記モバイルアプリケーションとの通信を終了すること、または前記データイベントを再送信すること、との少なくともいずれか一方と、
を更に備える請求項１の方法。
【請求項１２】
モバイル動作環境におけるアプリケーション間のデータ通信を提供する装置であって、
ランダムな番号と、プライマリアプリケーションのユニークなＩＤとを含む、レシピエントアプリケーションとのハンドシェイクを、イニシエイトするように構成された、安全セッションモジュールと、
前記ハンドシェイクに対する、少なくとも第２の番号を含む応答を、受信し確認するように構成された、確認モジュールと、
もし前記ハンドシェイクに対する前記応答が確認されれば、前記第２の番号または前記第２の番号のバージョン（version）を含むデータイベントを、前記レシピエントアプリケーションに対して送信するように構成された通信モジュールと、
前記モバイルアプリケーションからデータイベントの応答が受信されるまで、前記プライマリアプリケーションの実行を禁止するように構成された、送信管理モジュールと
を備え、前記データイベントの応答は、少なくとも前記第２の番号または前記第２の番号のバージョンを含む、装置。
【請求項１３】
前記通信モジュールは、もし前記データイベントの応答が前記レシピエントアプリケーションから受信されなければ、前記データイベントを再送信する、請求項１２の装置。
【請求項１４】
前記プライマリアプリケーションと前記レシピエントアプリケーションとの間のパケットロスの頻度または可能性を判断し、前記判断されたパケットロスに基づいて、受信確認されていないデータイベントの再送信の回数を決定するように構成された、通信信頼性モジュールを更に備える、請求項１２の装置。
【請求項１５】
前記安全セッションモジュールは、もし、前記回数の再送信の後、前記データイベントの応答が受信されなければ、前記ハンドシェイクを再度イニシエイトする、請求項１４の装置。
【請求項１６】
もし少なくとも、前記ハンドシェイクに対する応答、または前記データイベントの応答が、しきい期間内に前記モバイルアプリケーションから受信されず、またはハンドシェイクリフレッシュ時間が満了し、またはハンドシェイクイニシエーションコマンドが機器ユーザインターフェースから受信されれば、
前記安全セッションモジュールは、前記ハンドシェイクを再度イニシエイトする、請求項１２の装置。
【請求項１７】
少なくとも、前記ランダムな番号をハッシュし、切り捨て（truncate）、またはインクリメントし、またはそれらを組み合わせ、または
前記第２の番号をハッシュし、切り捨て、またはインクリメントし、またはそれらを組み合わせて、前記第２の番号の前記バージョンを生成する
ように構成されたハッシュモジュールを更に備える、請求項１２の装置。
【請求項１８】
もし少なくとも、前記第１の番号が前記ランダムな番号として確認されず、または所定の回数の前記ハンドシェイクに対してハンドシェイクの応答が受信されず、または通信セッションが完了されれば、
前記安全セッションモジュールは、ハンドシェイクの終了（termination）をイニシエイトするように構成される、請求項１２の装置。
【請求項１９】
単一のモバイル機器が、前記モバイルアプリケーションと前記プライマリモバイルアプリケーションとを通信可能に結合し、実行する、請求項１２の装置。
【請求項２０】
有線または無線ネットワークを介して通信可能に結合され、少なくともいずれか一方がモバイル機器である、第１及び第２の遠隔処理機器が、それぞれ前記レシピエントアプリケーション及び前記プライマリアプリケーションを実行する、請求項１２の装置。
【請求項２１】
前記ハンドシェイクをイニシエイトすることと、受信することとの間の時間に、少なくとも部分的に基づいて、前記プライマリアプリケーションと前記レシピエントアプリケーションとの間において予測される応答時間を算出するように構成された、タイミング要素を更に備え、
前記通信モジュールは、もし前記予測される応答時間内に前記データイベントの応答が受信されなければ、前記データイベントを再送信する、請求項１２の装置。
【請求項２２】
前記プライマリアプリケーションにおいて、前記プライマリアプリケーションの他の動作に割り込むことなく、ハンドシェイクの応答またはデータイベントの応答を受信してバッファすることを可能とするように構成された、処理バッファを更に備える、請求項１２の装置。
【請求項２３】
モバイル動作環境におけるアプリケーション間のデータ通信を提供する少なくとも１つのプロセッサであって、
プライマリモバイルアプリケーションのユニークな識別子と、ハンドシェイクのために生成されたランダムな番号と、を含む、モバイルアプリケーションとのハンドシェイクを、イニシエイトする、第１のモジュールと、
前記ハンドシェイクに対する、少なくとも第２の番号を含む応答を、受信し確認する、第２のモジュールと、
もし前記ハンドシェイクに対する前記応答が確認されれば、前記第２の番号または前記第２の番号のバージョン（version）を含むデータイベントを、前記モバイルアプリケーションに対して送信する第３のモジュールと、
少なくとも前記第２の番号の前記インクリメントを含むデータイベントの応答が受信されるまで、前記プライマリモバイルアプリケーションの実行を禁止する、第４のモジュールと
を備えるプロセッサ。
【請求項２４】
モバイル動作環境におけるアプリケーション間のデータ通信を提供する装置であって、
プライマリモバイルアプリケーションのユニークな識別子と、ハンドシェイクのために生成されたランダムな番号と、を含む、モバイルアプリケーションとのハンドシェイクを、イニシエイトする手段と、
前記ハンドシェイクに対する、少なくとも第２の番号を含む応答を、受信し確認する手段と、
もし前記ハンドシェイクに対する前記応答が確認されれば、前記第２の番号または前記第２の番号のバージョン（version）を含むデータイベントを、前記モバイルアプリケーションに対して送信する手段と、
少なくとも前記第２の番号の前記インクリメントを含むデータイベントの応答が受信されるまで、前記プライマリモバイルアプリケーションの実行を禁止する手段と
を備える装置。
【請求項２５】
モバイル環境アプリケーションのためのデータ通信セキュリティを提供する命令を保持するコンピュータ読み取り可能媒体を備えたコンピュータプログラム製品であって、前記コンピュータ読み取り可能媒体は、
コンピュータに対して、プライマリモバイルアプリケーションのユニークな識別子と、ハンドシェイクのために生成されたランダムな番号と、を含む、モバイルアプリケーションとのハンドシェイクを、イニシエイトさせるように構成された、第１命令セットと、
コンピュータに対して、前記ハンドシェイクに対する、少なくとも第２の番号を含む応答を、受信し確認させるように構成された、第２命令セットと、
コンピュータに対して、もし前記ハンドシェイクに対する前記応答が確認されれば、前記第２の番号または前記第２の番号のバージョン（version）を含むデータイベントを、前記モバイルアプリケーションに対して送信させるように構成された、第３命令セットと、
コンピュータに対して、少なくとも前記第２の番号または前記第２の番号のバージョンを含むデータイベントの応答が受信されるまで、前記プライマリモバイルアプリケーションの実行を禁止させるように構成された、第４命令セットと
を備えるコンピュータプログラム製品。
【請求項２６】
モバイル動作環境におけるアプリケーション間のデータ通信を提供する方法であって、
プライマリアプリケーションのユニークなＩＤ、または前記プライマリアプリケーションによって生成されたランダムな番号を含む、ハンドシェイクの要求を、前記プライマリアプリケーションから受信することと、
信頼されたプライマリアプリケーションの識別子のリストに対して、前記ユニークなＩＤを照会することと、
もし、前記ユニークなＩＤが、信頼されたプライマリアプリケーションの識別子の前記リストのＩＤに一致すれば、ハンドシェイクの応答を前記プライマリアプリケーションに送信することと、
データイベントの要求を受信することと、
前記データイベントの要求に対して、更なるデータイベントの要求の受信または処理の前に、応答することと
を備えた方法。
【請求項２７】
レシピエントアプリケーションから発せられた通信を特定するために生成された第２のランダムな番号、または前記ランダムな番号、またはその両方を、前記ハンドシェイクの応答に含めること、を更に備える請求項２６の方法。
【請求項２８】
前記データイベントにつき、データバッファを割り当てることと、
前記データイベント内に含まれるデータを、前記データバッファにコピーすることと、
現在のプロセスを完了させるための予測時間に、少なくとも部分的に基づいて、処理タイマをセットすることと、
前記処理タイマが満了するまで、前記データイベント内に含まれる前記データの処理を停止することと
を更に備える請求項２７の方法。
【請求項２９】
前記データイベントの要求内の、前記第２のランダムな番号のインクリメントを受信すること、を更に備える請求項２７の方法。
【請求項３０】
前記第２のランダムな番号のインクリメント、または前記レシピエントアプリケーションのアプリケーションＩＤ、またはその両方を、前記データイベントの要求の応答内に含めること、を更に備える請求項２７の方法。
【請求項３１】
前記データイベントの要求に応答するデータと共に、前記ランダムな番号のインクリメントを、前記データイベントの要求の応答内に含めること、を更に備える請求項２６の方法。
【請求項３２】
もし、前記データイベントの要求が前記第２のランダムな番号の現在のインクリメントを含んでいなければ、信頼されたユニークなＩＤを有する引き続くハンドシェイクのイベントが受信されるまで、前記データイベントの要求及び引き続くデータイベントの要求を無視すること、を更に備える請求項２６の方法。
【請求項３３】
新たなランダムな番号と、前記ユニークなＩＤまたは第２のユニークなＩＤを含む、ハンドシェイクの再イニシエーションメッセージを受信することと、
前記新たなランダムな番号を、一時的なバッファに保持することと、
前記ユニークなＩＤまたは前記第２のユニークなＩＤが、信頼されたプライマリアプリケーションの識別子のリストのＩＤと一致するかを確認することと、
もし前記ユニークなＩＤまたは前記第２のユニークなＩＤが確認されれば、前記ランダムな番号を前記新たなランダムな番号で置き換えることと、もし前記ユニークなＩＤまたは前記第２のユニークなＩＤが確認されなければ、前記新たなランダムな番号を前記一時的なバッファから削除することと、のいずれかと
を更に備える請求項２６の方法。
【請求項３４】
レシピエントデータイベントの要求を、前記プライマリアプリケーションに送信することと、
少なくとも、前記レシピエントデータイベントの要求に対する応答が受信されるまで、第２のレシピエントデータイベントの要求の送信を遅延させることと
を更に備える請求項２６の方法。
【請求項３５】
前記ランダムな番号のインクリメント、または前記プライマリアプリケーションの前記ユニークなＩＤ、またはその両方を含む応答を、前記プライマリアプリケーションから受信すること、を更に備える請求項３４の方法。
【請求項３６】
前記レシピエントデータイベントの要求に対する応答が受信されない限り、前記レシピエントデータイベントの要求を、設定可能な回数だけ再送信すること、または
もし、設定可能な回数の要求の送信の後、前記レシピエントデータイベントの要求に対する応答が受信されなければ、少なくとも信頼されたプライマリアプリケーションのクラスＩＤを有する、引き続くハンドシェイクが受信されるまで、前記レシピエントデータイベントの要求の送信を停止することと
の少なくとも１つを更に備える、請求項３４の方法。
【請求項３７】
モバイル動作環境におけるアプリケーション間のデータ通信を提供する装置であって、
プライマリアプリケーションのユニークなＩＤ、または前記プライマリアプリケーションによって生成されたランダムな番号を含む、ハンドシェイクの要求を、前記プライマリアプリケーションから受信するように構成された、安全モジュールと、
信頼されたプライマリアプリケーションの識別子のリストに対して、前記ユニークなＩＤを確認する照会モジュールと、
もし、前記ユニークなＩＤが、信頼されたプライマリアプリケーションの識別子の前記リストのＩＤに一致すれば、ハンドシェイクの応答を前記プライマリアプリケーションに送信するように構成され、またデータイベントの要求を受信するように構成された、インターフェースモジュールと、
前記インターフェースモジュールに対して、更なるデータイベントの要求の受信の前に
前記データイベントの要求に応答するよう求めるように構成された管理モジュールと
を備えた装置。
【請求項３８】
前記ハンドシェイクの応答は、レシピエントアプリケーションに応答する通信を特定するために生成された第２のランダムな番号、または前記ランダムな番号、またはその両方を、有する請求項３７の装置。
【請求項３９】
前記管理モジュールは、
前記データイベントにつき、データバッファを割り当てることと、
前記データイベント内に含まれるデータを、前記データバッファにコピーすることと、
現在のプロセスを完了させるための予測時間に、少なくとも部分的に基づいて、処理タイマをセットすることと、
レシピエントアプリケーションに対して、前記処理タイマが満了するまで、前記データイベント内に含まれる前記データの処理をさせないことと
の少なくとも１つを行うように更に構成されている、請求項３８の装置。
【請求項４０】
前記データイベントの要求は、少なくとも前記ランダムな番号のインクリメントを含む、請求項３８の装置。
【請求項４１】
前記管理モジュールは、前記第２のランダムな番号のインクリメント、または前記レシピエントアプリケーションのアプリケーションＩＤ、またはその両方を含む、前記データイベントの要求に対する応答を許可する、請求項３８の装置。
【請求項４２】
前記管理モジュールは、前記インターフェースモジュールに対して、前記プライマリアプリケーションによる実行のための命令、またはデータの要求、またはその両方と共に、前記ランダムな番号のインクリメントを含む、データイベントの要求の送信を許可する、請求項３７の装置。
【請求項４３】
前記管理モジュールは、もし、前記データイベントの要求が前記第２のランダムな番号の現在のインクリメントを含んでいなければ、信頼されたユニークなＩＤを有する引き続くハンドシェイクのイベントが受信されるまで、前記データイベントの要求及び引き続くデータイベントの要求を無視する、請求項３７の装置。
【請求項４４】
前記管理モジュールは、新たなランダムな番号と、前記ユニークなＩＤまたは第２のユニークなＩＤを含む、ハンドシェイクの再イニシエーションメッセージを受信することと、
前記新たなランダムな番号を、一時的なバッファに保持することと、
前記ユニークなＩＤまたは前記第２のユニークなＩＤが、信頼されたプライマリアプリケーションの識別子のリストのＩＤと一致するかを確認することと、
もし前記ユニークなＩＤまたは前記第２のユニークなＩＤが確認されれば、前記ランダムな番号を前記新たなランダムな番号で置き換えることと、もし前記ユニークなＩＤまたは前記第２のユニークなＩＤが確認されなければ、前記新たなランダムな番号を前記一時的なバッファから削除することと、のいずれかと
の少なくとも１つを行うように更に構成されている、請求項３７の装置。
【請求項４５】
前記インターフェースモジュールは、レシピエントデータイベントの要求を、前記プライマリアプリケーションに送信し、
前記管理モジュールは、少なくとも、前記レシピエントデータイベントの要求に対する応答が前記インターフェースで受信されるまで、第２のレシピエントデータイベントの要求の送信を遅延させる、請求項３７の装置。
【請求項４６】
前記インターフェースモジュールで受信された、前記レシピエントデータイベントの要求に対する要求は、前記ランダムな番号のインクリメント、または前記プライマリアプリケーションの前記ユニークなＩＤ、またはその両方を含む、請求項４５の装置。
【請求項４７】
前記インターフェースモジュールは、前記レシピエントデータイベントの要求に対する応答が受信されない限り、前記レシピエントデータイベントの要求を、設定可能な回数だけ再送信すること、または
前記管理モジュールは、前記インターフェースに対して、もし、設定可能な回数の要求の送信の後、前記レシピエントデータイベントの要求に対する応答が受信されなければ、確認されたプライマリアプリケーションのクラスＩＤを有する、引き続くハンドシェイクが受信されるまで、前記レシピエントデータイベントの要求の送信させないこと、
の少なくとも１つを更に備える、請求項４６の装置。
【請求項４８】
モバイル動作環境におけるアプリケーション間のデータ通信を提供する少なくとも１つのプロセッサであって、
プライマリアプリケーションのユニークなＩＤ、または前記プライマリアプリケーションによって生成されたランダムな番号を含む、ハンドシェイクの要求を、前記プライマリアプリケーションから受信する第１のモジュールと、
信頼されたプライマリアプリケーションの識別子のリストに対して、前記ユニークなＩＤを照会する第２のモジュールと、
もし、前記ユニークなＩＤが、信頼されたプライマリアプリケーションの識別子の前記リストのＩＤに一致すれば、ハンドシェイクの応答を前記プライマリアプリケーションに送信する第３のモジュールと、
データイベントの要求を受信する第４のモジュールと、
更なるデータイベントの要求の受信の前に、前記データイベントの要求に応答する第５のモジュールと
を備えたプロセッサ。
【請求項４９】
モバイル動作環境におけるアプリケーション間のデータ通信を提供する装置であって、
プライマリアプリケーションのユニークなＩＤ、または前記プライマリアプリケーションによって生成されたランダムな番号を含む、ハンドシェイクの要求を、前記プライマリアプリケーションから受信する手段と、
信頼されたプライマリアプリケーションの識別子のリストに対して、前記ユニークなＩＤを照会する手段と、
もし、前記ユニークなＩＤが、信頼されたプライマリアプリケーションの識別子の前記リストのＩＤに一致すれば、ハンドシェイクの応答を前記プライマリアプリケーションに送信する手段と、
データイベントの要求を受信する手段と、
前記データイベントの要求がイニシエイトされるまで、更なるデータイベントの要求の受信を遅延させる手段と
を備えたプロセッサ。
【請求項５０】
モバイル動作環境におけるアプリケーション間のデータ通信を提供する命令を保持するコンピュータ読み取り可能媒体を備えたコンピュータプログラム製品であって、前記コンピュータ読み取り可能媒体は、
コンピュータに対して、プライマリアプリケーションのユニークなＩＤ、または前記プライマリアプリケーションによって生成されたランダムな番号を含む、ハンドシェイクの要求を、前記プライマリアプリケーションから受信させるように構成された、第１命令セットと、
コンピュータに対して、信頼されたプライマリアプリケーションの識別子のリストに対して、前記ユニークなＩＤを照会させるように構成された、第２命令セットと、
コンピュータに対して、もし、前記ユニークなＩＤが、信頼されたプライマリアプリケーションの識別子の前記リストのＩＤに一致すれば、ハンドシェイクの応答を前記プライマリアプリケーションに送信させるように構成された、第３命令セットと、
コンピュータに対して、データイベントの要求を受信させるように構成された、第４命令セットと、
コンピュータに対して、更なるデータイベントの要求を受信する前に、前記データイベントの要求に対して応答させるように構成された、第５命令セットと
を備えたプロセッサ。
【発明の詳細な説明】
【米国特許法第１１９条の優先権の主張】
【０００１】
この特許出願は、本願の譲受人に譲受され、そして参照により本願に明示的に組み込まれる、２００６年１２月５日に出願され“METHOD AND APPARATUS FOR ESTABLISHING A TRUSTED COMMUNICATION BETWEEN TWO APPLICATIONS ON A SINGLE PLATFORM”と表題された米国仮出願番号６０／８６８，７０１、及び、２００７年３月１４日に出願され“METHOD AND APPARATUS FOR INTER APPLICATIONS COMMUNICATION”と表題された米国仮出願番号６０／８９４，８９７に基づく優先権を主張する。
【技術分野】
【０００２】
下記の説明は、全般的にモバイル機器のアプリケーション及び無線通信に監視、より具体的には、１つまたはそれ以上のモバイルプラットフォーム上で動作するモバイルアプリケーション間における、安全（secure）なデータ交換を提供することに関する。
【背景技術】
【０００３】
近年、様々な進歩が、移動体通信技術及び移動体通信機器において起きている。その進歩の一面は、例えばそのような機器へのカメラやビデオ録画技術の一体化や、モバイル通信へのｅメールやショートメッセージサービスの組み込みなど、ソフトウェア及び／またはハードウェアアプリケーションに関係している。これらのアプリケーションは、既によくある通信機器（例えば携帯電話）に、増強されたフレキシビリティ、処理能力、通信機能等を付加してきた。その結果、そのような機器は、消費者市場においてよりポピュラーとなり、非常に多くの消費者にそのような機器の購入意欲を高め、または新たなアプリケーションまたは技術を含む機器へのアップグレードの動機付けとなってきた。
【０００４】
更に、種々のタイプの悪意のあるソフトウェア（破壊工作ソフト（malware））が、概して電子通信の妨げとなっている。ある破壊工作ソフトは、比較的無害であり、単にユーザの行動をモニタして、新たな製品の開発や、それらの製品を消費者にアピールするための販売戦略とコマーシャルの作成に役立たせる。モニタしているプログラムは、通常、動作環境や記録されているデータにダメージを与えることは無いが、これらをもとに、電子機器の処理リソースを消費し得る。しかし、ある破壊工作ソフトは積極的に、機器の動作環境を破壊し、データを改竄し、パスワードやユーザ情報を盗む等、行うことがある。それらは種々のメカニズムによって動作可能であるが、それらは一般的に、それら自身を機器上の真正のプログラムに書き込むか、またはそのようなプログラムに見えるようにそれら自身を隠すか等、行う。悪意のあるソフトウェアの影響によって、電子動作環境における通信を安全にするための種々のメカニズムが生まれてきた。モバイル機器も、なりすましプログラムや、他の破壊工作ソフトによる損害の例外では無く、一般的に保護通信の地益を得る。モバイルであっても。
【発明の概要】
【０００５】
下記は、１つまたはそれ以上の実施形態の単純化されたサマリを開示し、それはそのような実施形態の基本的な理解を提供するためである。このサマリは、全ての熟慮された実施形態の広範囲に及ぶ概観では無く、また全ての実施形態の主要なまたは重要な意味を持つ要素を特定するものでも無いし、いくつかまたは全ての実施形態の範囲の外延を示すものでも無い。その唯一の目的は、後に与えられるより詳細な説明の前置きとしての簡単化された形態における、１つまたはそれ以上の実施形態の、いくつかの考え方を提供することである。
【０００６】
主題となる開示は、モバイル動作環境において実行されるモバイルアプリケーションのための、安全で効率的な通信を提供する。例として、プライマリモバイルアプリケーションは、プライマリモバイルアプリケーションから受信した応答通信（responsive communication）を認証し及び／または署名するためのランダムな番号と、プライマリアプリケーションの識別子とを含むハンドシェイクをイニシエイト出来る。レシピエントアプリケーションは、ユニークな識別子を、認証されたプライマリアプリケーションのリストに照会し、プライマリアプリケーションを確認出来る。もしユニークな識別子が確認されれば、レシピエントアプリケーションは、レシピエントアプリケーションに送られる引き続く通信に署名及び／または認証するために使用され得る第２のランダムな番号及びランダムな番号と共にハンドシェイクに応答する。上記に加えて、プライマリアプリケーションとレシピエントアプリケーションは、対応する応答または要求がそれぞれ受信または送信されるまで、要求及び／または応答を遅延させることが出来る。
【０００７】
主題となる開示の更なる側面によれば、イニシエイトしているまたはレシピエントアプリケーションを特定するために生成されるランダムな番号は、次の通信のためにインクリメントされ得る。応答は、確認される応答についてのランダムな番号の適切なインクリメントを含むだろう。その結果、主題となる開示は、ラウンドトリップ通信を提供し、各ラウンドトリップはランダムな番号のインクリメントによって特定され、また各ラウンドトリップは引き続くラウンドトリップがイニシエイトされる前に完了する。
【０００８】
更に別の側面によれば、ランダムな番号は、この番号を隠し、認証されていないアプリケーションに対する更なるセキュリティを提供するため、ハッシュ及び／または切り捨てられることが出来る。更に、ハッシュ関数は、他の暗号化／復号化メカニズムに比べて非常に処理が少ないため、主題となる開示は、一般的な技術に比べて比較的低電力消費の効率的な方法において、モバイルアプリケーション間の安全なデータ転送を提供する。更に別の側面によれば、モバイルアプリケーションは、モバイルネットワーク、伝送制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）、及び他の同種のものによって接続された、隔てられた携帯電話等の遠隔動作機器、または１つの携帯電話のような単一で動作する機器上で、実行されることが出来る。
【０００９】
他の側面によれば、モバイル動作環境におけるアプリケーション間のデータ通信を提供する方法が開示される。この方法は、プライマリモバイルアプリケーションのユニークな識別子と、ハンドシェイクのために生成されたランダムな番号とを含む、モバイルアプリケーションとのハンドシェイクをイニシエイトすることと、ハンドシェイクに対する、第１の番号と第２の番号を含む応答を、受信することとを含み、第２の番号はモバイルアプリケーションによってランダムに生成される。この方法は更に、第１の番号がハンドシェイクのために生成されたランダムな番号であることを確認することと、もし第１の番号がランダムな番号として確認されれば、第２の番号のインクリメントを含むデータイベントをモバイルアプリケーションに送信することとを含む。更に方法はまた、第２のデータイベントの送信の前に、モバイルアプリケーションからの、少なくとも第２の番号のインクリメントを含むデータイベントの応答を待つことを含むことが出来る。
【００１０】
更なる側面によれば、モバイル動作環境におけるアプリケーション間のデータ通信を提供する装置が開示される。この装置は、レシピエントアプリケーションとのハンドシェイクをイニシエイトするように構成された安全セッションモジュールを含むことが出来、このハンドシェイクは、ランダムな番号と、プライマリアプリケーションのユニークなＩＤとを含む。更に装置は、ハンドシェイクに対する、応答番号と第２の番号とを含む応答を受信し、応答番号が前記ランダムな番号または第２のランダムな番号のインクリメントであるかを判断するように構成された確認モジュールを含むことが出来る。更にこの装置は、もし応答番号がランダムな番号または第２のランダムな番号のインクリメントとして確認されれば、第２のランダムな番号のインクリメントを含むデータイベントを、レシピエントアプリケーションに対して送信するように構成された通信モジュールを含むことが出来る。更に装置はまた、少なくとも第２の番号のインクリメントを含むデータイベントの応答がレシピエントアプリケーションから受信されれば、第２のデータイベントの送信を通信モジュールに対して可能にする、通信管理モジュールを含むことが出来る。
【００１１】
更に別の側面によれば、モバイル動作環境におけるアプリケーション間のデータ通信を提供する少なくとも１つのプロセッサが開示される。プロセッサは、プライマリモバイルアプリケーションのユニークな識別子と、ハンドシェイクのために生成されたランダムな番号と、を含む、モバイルアプリケーションとのハンドシェイクを、イニシエイトする、第１のモジュールと、第１の番号と第２の番号とを含む、ハンドシェイクに対する応答を受信する第２のモジュールとを含むことが出来、第２の番号は、モバイルアプリケーションによってランダムに生成される。更にプロセッサは、第１の番号が、ハンドシェイクのために生成されたランダムな番号であるかを確認する第３のモジュールと、もし第１の番号がランダムな番号と確認されれば、第２の番号のインクリメントを含む、モバイルアプリケーションのデータイベントを送信する第４のモジュールとを含むことが出来る。上記に加えてプロセッサは、第２のデータイベントの送信が可能とされる前に、少なくとも第２の番号のインクリメントを含む、モバイルアプリケーションからのデータイベントの応答を待つ第５のモジュールを含むことが出来る。
【００１２】
更に別の側面に従って、モバイル動作環境におけるアプリケーション間のデータ通信を提供する装置が述べられる。この装置は、プライマリモバイルアプリケーションのユニークな識別子と、ハンドシェイクのために生成されたランダムな番号とを含む、モバイルアプリケーションとのハンドシェイクをイニシエイトする手段と、第１の番号と第２の番号とを含む、ハンドシェイクに対する応答を受信する手段とを含むことが出来、第２の番号は、モバイルアプリケーションによってランダムに生成される。更に、装置はまた、第１の番号が、ハンドシェイクのために生成されたランダムな番号であるかを確認する手段と、もし第１の番号がランダムな番号として確認されれば、第２の番号のインクリメントを含むデータイベントを、モバイルアプリケーションへ送信する手段とを含むことが出来る。更に装置は、少なくとも第２の番号のインクリメントを含むデータイベントの応答をモバイルアプリケーションから受信するまで、送信される第２のデータイベントを遅延させる手段とを含むことが出来る。
【００１３】
少なくとも１つの側面によれば、モバイル環境アプリケーションのためのデータ通信セキュリティを提供する命令を保持するコンピュータ読み取り可能媒体を含むコンピュータプログラム製品が開示される。このコンピュータ読み取り可能媒体は、コンピュータに対して、プライマリモバイルアプリケーションのユニークな識別子と、ハンドシェイクのために生成されたランダムな番号とを含む、モバイルアプリケーションとのハンドシェイクをイニシエイトさせるように構成された第１の命令セットを含むことが出来る。更に、コンピュータ読み取り可能媒体は、コンピュータに対して、第１の番号と第２の番号とを含む、ハンドシェイクに対する応答を受信させるように構成された第２の命令セットを含むことが出来、第２の番号は、モバイルアプリケーションによってランダムに生成される。更に、コンピュータ読み取り可能媒体は、コンピュータに対して、もし第１の番号がランダムな番号として確認されれば、第２の番号のインクリメントを含むデータイベントをモバイルアプリケーションに送信させるように構成された第３の命令セットを含むことが出来る。上記に加えて、コンピュータ読み取り可能媒体はまた、コンピュータに対して、第２のデータイベントが送信可能とされる前に、少なくとも第２の番号のインクリメントを含む、モバイルアプリケーションからのデータイベントの応答を待たせるように構成された第４の命令セットを含むことが出来る。
【００１４】
１つまたはそれ以上の側面によれば、モバイル動作環境におけるアプリケーション間のデータ通信を提供する方法が述べられる。この方法は、プライマリアプリケーションのユニークなＩＤまたはプライマリアプリケーションによって生成されたランダムな番号を含む、プライマリアプリケーションからのハンドシェイクを受信することと、ユニークなＩＤを、信頼されたプライマリアプリケーションの識別子のリストに対して照会することとを含むことが出来る。更に方法は、もしユニークなＩＤが、信頼されたプライマリアプリケーションの識別子のリストのＩＤと一致すれば、プライマリアプリケーションにハンドシェイクの応答を送信することと、データイベントの要求を受信することとを含むことが出来る。更に方法は、更なるデータイベントの要求を受信する前に、データイベントの要求に対して応答することを更に含むことが出来る。
【００１５】
更なる側面によれば、モバイル動作環境におけるアプリケーション間のデータ通信を提供する装置が開示される。この装置は、プライマリアプリケーションのユニークなＩＤまたはプライマリアプリケーションによって生成されたランダムな番号を含む、プライマリアプリケーションからのハンドシェイクの要求を受信するように構成されたセキュリティモジュールを含むことが出来る。更に装置は、ユニークなＩＤを、信頼されたプライマリアプリケーションの識別子のリストに対して確認するように構成された照会モジュールと、もしユニークなＩＤが、信頼されたプライマリアプリケーションの識別子のリストのＩＤに一致すれば、プライマリアプリケーションにハンドシェイクの応答を送信するように構成され、またデータイベントの要求を受信するように構成されたインターフェースモジュールとを含むことが出来る。上記に加えて、装置はまた、更なるデータイベントの要求を受信する前に、データイベント要求への応答するための接続を求めるように構成された管理モジュールを含むことが出来る。
【００１６】
更に別の側面によれば、モバイル動作環境におけるアプリケーション間のデータ通信を提供する、少なくとも１つのプロセッサが述べられる。このプロセッサは、プライマリアプリケーションのユニークなＩＤまたはプライマリアプリケーションにより生成されたランダムな番号を含む、プライマリアプリケーションからのハンドシェイクの要求を受信する第１のモジュールと、信頼されたプライマリアプリケーションの識別子のリストに対してユニークなｉＤを照会する第２のモジュールとを含む。更にこのプロセッサは、もしユニークなＩＤが、信頼されたプライマリアプリケーションの識別子のリストに一致すれば、プライマリアプリケーションにハンドシェイクの応答を送信する第３のモジュールと、データイベントの要求を受信する第４のモジュールとを含むことが出来る。更にプロセッサは、更なるデータイベントの要求を受信する前に、データイベントの要求に対して応答する第５のモジュールを含むことが出来る。
【００１７】
１つまたはそれ以上の更なる側面によれば、モバイル動作環境におけるアプリケーション間のデータ通信を提供する装置。この装置は、プライマリアプリケーションのユニークなＩＤまたはプライマリアプリケーションにより生成されたランダムな番号を含む、プライマリアプリケーションからのハンドシェイクの要求を受信する手段と、信頼されたプライマリアプリケーションの識別子のリストに対してユニークなｉＤを照会する手段とを含む。更にこの装置は、もしユニークなＩＤが、信頼されたプライマリアプリケーションの識別子のリストに一致すれば、プライマリアプリケーションにハンドシェイクの応答を送信する手段と、データイベントの要求を受信する手段とを含むことが出来る。更に装置は、データイベントの要求を受信するまで、更なるデータイベントの要求の受信を遅延させる手段を含むことが出来る。
【００１８】
更なる側面によれば、モバイル動作環境におけるアプリケーション間のデータ通信を提供するための命令を含むコンピュータ読み取り可能媒体を含む、コンピュータプログラム製品が述べられる。より具体的には、コンピュータ読み取り可能媒体は、コンピュータに対して、プライマリアプリケーションのユニークなＩＤまたはプライマリアプリケーションにより生成されたランダムな番号を含む、プライマリアプリケーションからのハンドシェイクの要求を受信させるように構成された、第１の命令セットを含むことが出来る。コンピュータ読み取り可能媒体はまた、コンピュータに対して、信頼されたプライマリアプリケーションの識別子のリストに対してユニークなｉＤを照会させるように構成された第２命令セットと、コンピュータに対して、もしユニークなＩＤが、信頼されたプライマリアプリケーションの識別子のリストのＩＤに一致すれば、プライマリアプリケーションにハンドシェイクの応答を送信させるように構成された第３命令セットとを含むことが出来る。更にコンピュータ読み取り可能な媒体はまた、コンピュータに対して、データイベントの要求を受信させるように構成された第４命令セットと、コンピュータに対して、更なるデータイベントの要求を受信する前に、データイベントの要求に対して応答させるように構成された第５命令セットとを含むことが出来る。
【００１９】
上記及び関連する目的の達成のため、１つまたはそれ以上の側面は、後に特許請求の範囲において十分に述べられ、また特に指摘される特徴を備える。下記の説明と、添付図面は、１つまたはそれ以上の側面の、ある特定の例示的な側面の詳細を説明する。しかしながらこれらの側面は、種々の側面の原理が使用される様々な方法のうちのほんの数例を示すに過ぎず、説明された側面は、そのような側面の全てと、それらに等価なものを含むことを意図している。
【図面の簡単な説明】
【００２０】
【図１】図１は、モバイルアプリケーション間における安全で低電力の通信を提供出来る、見本となるシステムのブロック図を例示する。
【図２】図２は、モバイル動作環境で実行されるアプリケーション間の安全な通信を先導（initiate）出来る、見本となるシステムのブロック図を示す。
【図３】図３は、モバイル動作環境において実行されるアプリケーション間での安全な通信に対して応答出来る、見本となるシステムのブロック図を示す。
【図４】アプリケーション間における安全で低電力の通信を提供でき、モバイルアプリケーションを実行出来る、見本となるモバイル機器を例示する。
【図５】図５は、ある側面に従った遠隔の機器（remote device）上で動作するモバイルアプリケーションのための安全な通信を提供する、見本となるネットワークを示す。
【図６】図６は、別の側面に従ったモバイルアプリケーションのための、安全な遠隔通信を容易にするための、見本となる基地局を例示する。
【図７】図７は、モバイル動作環境におけるモバイルアプリケーション間での安全な通信を先導するための、見本となる手順を例示する。
【図８】図８は、一側面に従ったラウンドトリップ通信を完了するために、データイベントを再送信する、見本となる手順を例示する。
【図９】図９は、モバイルアプリケーション間での安全な通信における、ラウンドトリップ通信をインクリメント（increment）する手順例を示す。
【図１０】図１０は、モバイル動作環境におけるモバイルアプリケーション間での安全な通信に応答する手順例を例示する。
【図１１】図１１は、イニシャル（initial）の要求とラウンドトリップ通信が完了するまで、引き続く要求をバッファリングする手順例を示す。
【図１２】図１２は、モバイルアプリケーション間での安全な通信における、再度イニシエイト（re-initiated）されたハンドシェイクを受信する手順例を例示する。
【図１３】図１３は、ハンドシェイクを終了する手順例を例示する。
【図１４】図１４は、モバイル動作環境における安全な通信をイニシエイトするためのシステムの、見本となるブロック図を例示する。
【図１５】図１５は、モバイル動作環境における安全な通信を受信するためのシステムの、見本となるブロック図を例示する。
【発明を実施するための形態】
【００２１】
種々の側面が、これより図面を参照して説明される。図面において、同様の参照符号が、全図にわたって同様の要素を指すために使用される。下記の説明において、例示の目的で、多数の具体的な詳細が、１つまたはそれ以上の側面の詳細な理解を提供するために、説明される。しかしながら、そのような側面は、これらの具体的な詳細を必要とせずに実行可能であることは、明らかであり得る。別の場合には、１つまたはそれ以上の側面の説明を助けるために、よく知られた構造及び機器はブロック図で示される。
【００２２】
主題となる開示は、モバイル環境におけるアプリケーション間の、安全で効率的で、そして処理の少ない通信を提供する。電子通信を保護するための種々の一般的なメカニズムが存在する。しかし、そのような一般的なメカニズムは通常、複雑で処理の集中する暗号化及び復号化アルゴリズムを使用する。そのようなメカニズムは、その演算処理の要求から、比較的大きな電力を消費する。しかしながらモバイル動作環境は、バッテリ電力に依存するため、低消費電力が有効である。いくつかのアプリケーションは、モバイル環境における低消費電力のための改良がなされているが、そのような改良は、通信を保護する点においては全く十分ではなかった。１つの理由は、システム処理及びメモリ技術における進歩及び予期された進歩によるものである。例えば、そのような進歩は、多くのアプリケーション研究者に、プロセッササイズ、並列処理、及びメモリサイズ等、予期される進歩に従って、通信プロトコルを改良して消費電力の削減することをやめさせる。
【００２３】
また開示は、ラウンドトリップコンセプト（round-trip concept）を使用するアプリケーション間の通信である。より具体的には、アプリケーションは、引き続く要求／応答の開始及び／または処理の前に、完了すべき並行する（concurrent）要求または応答を待つことが出来る。ラウンドトリップ通信は、同期環境において特に効率的であることが出来る。伝送制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）のような、共通の一般的な通信は通常、ターゲットとなるアプリケーションからの応答を待つ前に、データパケットの列を送信する。更に、保護されたＴＣＰ／ＩＰ通信では、受信データの復号化及び／または把握は、しばしば送信における全データパケットの受信に依存する。もし１つのデータパケットをロストした場合、送信されたデータの大半は使用不可となり得る。代わりに、主題となる開示は、もしデータまたはセキュリティ識別子が、イニシエイトしているまたはレシピエント（initiating and recipient）アプリケーションによってロストされた場合に、要求及び／または応答の再送信を規定する。そのようなシステムは、他のメッセージの受け渡し及び／または共有メモリ環境と同様にインターネットや最も私的なイントラネットにおいても使用される、広範囲にわたって成功したＴＣＰ／ＩＰアーキテクチャと、劇的に異なっている。その結果、本明細書で述べられるラウンドトリップ及び再送信アーキテクチャは、それらの成功と大衆化のために、本明細書で説明された効率化、同期、及び低電力の安全なデータ交換から研究を遠ざけた一般的な通信アーキテクチャとは異なり、相容れないものである。
【００２４】
上記に加えて、開示は、別のアプリケーションによって提供される通信を特定及び／または認証するための、特定のアプリケーションによって生成された、ランダムな番号（random numbers）を使用する、アプリケーション間通信アーキテクチャである。例えば、イニシエイトしているモバイルアプリケーションはランダムな番号を生成して、そのランダムな番号をレシピエントアプリケーションに与えることが出来る。イニシエイトしているモバイルアプリケーションへの続く応答は、通信がレシピエントから来たものであること、及びなりすましプログラムまたはその他の破壊工作ソフトで無いことを確認するために、特定のラウンドトリップを特定する、ランダムな番号をインクリメントしたものまたはこのランダムな番号を含むだろう。更なる側面によれば、このランダムな番号は、集中的及び大消費電力の暗号化／復号化アルゴリズムを必要とせずにこのランダムな番号を分かりにくくするために、計算が集中的でないハッシュ関数（例えば、SHA-1、SHA-224、SHA-256、SHA-386、SHA-512、SHA-2、メッセージダイジェストアルゴリズム［ＭＤ５］、等）を用いて暗号化されることが出来る。更に、ハッシュされたランダムな番号は、イニシエイトしているまたはレシピエントアプリケーション間の特定の通信インターフェースによって求められるように切り捨てられることが出来る。このように開示は、モバイル環境に有益な、安全なアプリケーション間通信を提供するメカニズムである。
【００２５】
種々の側面が、以下に述べられる。本明細書における教示は非常に多くの様々な形態で実施されることが出来、また本明細書に開示された特定の構造及び／または関数は単なる例示に過ぎないことが明らかであるべきである。本明細書の教示に基づいて当業者は、本明細書に開示された側面が、他の側面から独立して実施可能であること、またこれらの側面の２つまたはそれ以上を、様々な方法で組み合わせることが可能であることを理解すべきである。例えば、本明細書で説明された幾つかの側面を用いて装置が実装され、及び／または方法が実行されることが出来る。更に、本明細書で説明された側面の１つまたはそれ以上、またはそれ以外のものに、他の構造及び／または機能を用いて、装置が実装され、及び／または方法が実行されることが出来る。一例として、本明細書で述べられた多くの方法、機器、システム、及び装置が、少なくとも１つの携帯機器上で動作し、そのようなアプリケーション間での安全な通信を確立する１つまたはそれ以上のアプリケーションと関連して説明される。当業者は、同様の技術がその他の通信環境にも更に適用出来ることを理解すべきである。
【００２６】
本開示で使用される際、用語「要素」、「システム」、及び同種の用語は、ハードウェア、ソフトウェア、実行中のソフトウェア、ファームウェア、ミドルウェア、マイクロコード、及び／またはこれらのあらゆる組み合わせのいずれかの、コンピュータに関連したエンティティを指すことを目的としている。例えば、要素は、これに限定されるものでは無いが、プロセッサ上で動作している処理、プロセッサ、オブジェクト、実行ファイル、実行スレッド、プログラム、及び／またはコンピュータであるかもしれない。１つまたはそれ以上の要素は、実行プロセス及び／または実行スレッド内に存在しても良いし、要素は１つのコンピュータ上にとどまっていても良いし、及び／または２つ以上のコンピュータ間に分布していても良い。またこれらの要素は、そこに記録された種々のデータ構造を有する種々のコンピュータ読み取り可能な媒体から実行できる。この要素は、例えば、１つまたはそれ以上のデータパケット（例えば、ローカルシステム、分散システムにおいて、及び／または信号を経て別の要素とのインターネットのようなネットワークを横断して、別の要素と互いに情報をやりとりするある要素からのデータ）を有する信号に従って、ローカル及び／またはリモートプロセスを経て、通信し得る。更に、当業者には明らかなように、本明細書で説明されたシステムの要素は、それに関して説明された種々の側面、目的、効果等を得ることを容易にするために、追加の要素によって再構成、及び／または補足されても良く、そして要素は、任意の図面で説明された構成そのものに限定されるものでは無い。
【００２７】
更に、本明細書に開示された実施形態に関連して述べられた種々の一例としてのロジック、論理ブロック、モジュール、及び回路は、ここで述べられた機能を実行するように設計された汎用用途プロセッサ、デジタルシグナルプロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイシグナル（ＦＰＧＡ）、またはその他のプログラマブル論理デバイス、ディスクリートゲートまたはトランジスタロジック、ディスクリートハードウェア部品、またはこれらの適切な組み合わせによって、実装または実行されるだろう。汎用用途プロセッサは、マイクロプロセッサであっても良いが、代わりにプロセッサは一般のプロセッサ、コントローラ、マイクロコントローラ、またはステートマシンであっても良い。プロセッサはまた、例えば、ＤＳＰとマイクロプロセッサの組み合わせ、複数のマイクロプロセッサ、ＤＳＰコアと接続された一つ以上のマイクロプロセッサ、または他のそのような構成の、コンピューティングデバイスの組み合わせして実装されても良い。更に、少なくとも１つのプロセッサは、本明細書で説明されたステップ及び／または動作の１つまたはそれ以上を実行するように動作可能な１つまたはそれ以上のモジュールを備えることが出来る。
【００２８】
更に、種々の側面が、モバイル通信機器（すなわち、例えばモバイル機器）と関連して本明細書で説明される。モバイル通信機器はまた、システム、加入者ユニット、加入者局、移動局、モバイル、モバイル機器、移動体機器、マルチモード機器、リモート局、リモート端末、アクセス端末、ユーザ端末、ユーザエージェント、ユーザ機器、またはユーザ装置等と呼ばれることがある。加入者局は、携帯電話、コードレス電話、Session Initiation Protocol（ＳＩＰ）電話、無線ローカルループ（ＷＬＬ）局、携帯情報端末（ＰＤＡ）、無線接続能力を有する携帯型機器、または無線モデムまたは処理デバイスとの無線通信を手助けする同様のメカニズムに接続されたその他の処理デバイスであっても良い。
【００２９】
更に、本明細書で説明された種々の側面または特長は、標準的なプログラミング及び／または工学の技術を用いた方法、装置、または製品として実装され得る。更に、本明細書に開示された側面に関連して述べられた方法またはアルゴリズムのステップ及び／または動作は、ハードウェア、プロセッサによって実行されたソフトウェアモジュール、またはこの２つの組み合わせによって直接的に実施されることが出来る。更に、いくつかの側面では、方法またはアルゴリズムのステップ及び／または動作は、コンピュータプログラム製品に組み込まれることが出来る、機器読み取り可能な媒体及び／またはコンピュータ読み取り可能な媒体上のコード及び／または命令の少なくとも１つまたは幾つかの組み合わせとして存在し得る。更に、本明細書で使用される用語「製品」は、なんらかのコンピュータ読み取り可能な機器、担体、媒体からアクセス可能なコンピュータプログラムを包含することを意図する。例えば、コンピュータ読み取り可能な媒体は、これらに限定されるものでは無いが、磁気記録媒体（例えばハードディスク、フロッピー（登録商標）ディスク、磁気帯…）、光ディスク（コンパクトディスク（ＣＤ）、ディジタルバーサタイルディスク（ＤＶＤ））、スマートカード、及びフラッシュメモリデバイス（例えばカード、スティック、キードライブ（key drive））を含むことができる。更に、本明細書で説明された種々の記録媒体は、情報を記録するための、１つまたはそれ以上の機器及び／またはその他の機器読み出し可能な媒体を意味することが出来る。用語「機器読み出し可能な媒体」は、無線チャネル、及び命令及び／またはデータを保持、収容、及び／または搬送可能な他の種々の媒体を含むことができるが、これらに限定されるものでは無い。
【００３０】
更に、用語「典型的」は、例（example）、事例（instance）、例証（illustration）であることを意味するために、本明細書では用いられる。「典型的」として本明細書で説明された側面または図案は、他の側面や図案よりも好ましいまたは有利であるとして必ずしも解釈されるものでは無い。むしろ、典型的なる用語の使用は、具体的な方法の考え方を提示することを目的としている。この出願で使用する際、用語「または」は、排他的な「また」よりもむしろ、包括的な「または」を意味する。すなわち、別に特定されない限り、または文脈から明らかでない限り、「ＸはＡまたはＢを使用する」は、当然に包括的な置換を意味することを目的としている。すなわち、もし、ＸがＡを使用する；ＸがＢを使用する、またはＸはＡとＢの両方を使用する場合、先の例の下で、「ＸはＡまたはＢを使用する」が満足される。更に、この出願及び添付の請求項における単数での表現は、別に特定されない限り、または単数の形態であることが導かれる文脈から明らかで無い限り、全般的に「１つまたはそれ以上」との意味に解釈されるべきである。
【００３１】
本明細書で使用する際に、用語「推測する（infer）」、または「推測（inference）」なる用語は概して、イベント及び／またはデータを介して取り込む際の観察結果のセットから、システム、環境、及び／またはユーザの状況につき、論理的に考えること（reasoning）または推測すること（inferring）のプロセスを指す。推測は、特定の状況（context）または動作を特定するために実施されることが出来、または例えば状態に対する確率分布を生成することが出来る。推測は、確率論的、すなわち、データ及びイベントの考慮に基づく、対象の状態に対する確率分布の演算であり得る。推測はまた、イベント及び／またはデータのセットから、高レベルのイベントを組み立てるために使用される技術を指すことも出来る。そのような推測の結果は、観測されたイベント及び／または記憶されたイベントデータ、イベントが時間的に近接して密接に相関するか否か、及びイベントとデータが１つかそれとも複数のイベント及びデータソースから来たか、からの、新たなイベントまたは動作の構築に帰する。
【００３２】
図１を参照して、モバイル動作環境１０６における１つまたはそれ以上のモバイルアプリケーションのための安全な通信を提供する、例となるシステム１００のブロック図が示されている。システム１００は、他のアプリケーション１０４とのハンドシェイクセッションをイニシエイト（initiate）するために指定されたプライマリアプリケーション（primary application）１０２を含むことが出来る。プライマリアプリケーション１０２は、モバイルオペレーティングシステム１０６上で動作するよう構成された適切なアプリケーションであり得る。プライマリアプリケーション１０２の例は、診断集合（diagnostic gathering）アプリケーション（例えば、quality of service ［ＱｏＳ］アプリケーション）、通信アプリケーション（例えば、無線アプリケーションプロトコル［ＷＡＰ］等のような、ｅメール、インスタントメッセージ［ＩＭ］、ショートメッセージサービス［ＳＭＳ］、音声通話セットアップ及び／または維持、voice over Internet Protocol［ＶｏＩＰ］セットアップ及び／または維持、着信音ダウンロードまたは再生アプリケーション、ウェブブラウザアプリケーション）、またはこれらの組み合わせなどを含み得る。モバイル動作環境は、モバイルアプリケーションの記憶及び実行、並びにそのようなアプリケーション間のデータ転送に適した環境であることが出来、例えば、以下で説明されるbinary runtime environment for wireless（ＢＲＥＷ（登録商標））等である。
【００３３】
プライマリアプリケーション１０２は、少なくとも１つの別のアプリケーション１０４との、安全な通信セッションを確立するハンドシェイクをイニシエイトすることが出来る。主題となる開示の大半は、２つのアプリケーション間における単一の通信を含むが、アプリケーション１０２は、多数の他のアプリケーション１０４との多数の安全な通信セッションを同時に維持することも出来る。このハンドシェイクは、プライマリアプリケーション１０２と、レシピエント（recipient）アプリケーション１０４との間の、信頼された“チャネル”を生成するために行われることが出来る。その結果、任意のデータ（例えばバイナリなど）が、例えばデータや命令などのアドレスポインタを用いて、信頼されたチャネル上で、プライマリアプリケーションとレシピエントアプリケーションとの間で交換されることが出来る。
【００３４】
ハンドシェイクは、少なくともプライマリアプリケーション１０２のユニーク（unique）な識別子、またはハンドシェイクのために生成されたランダムな番号、またはその両方を含むハンドシェイク要求を送ることによって、プライマリアプリケーション１０２によってイニシエイトされることが出来る。ユニークな識別子は、プライマリアプリケーションに関連付けられたアプリケーションＩＤであり、プライマリアプリケーションが信頼されるべきものかを確認するためにレシピエントアプリケーションによって使用されることが出来る。一般的に、オペレーティングシステム１０６は、オペレーティングシステム１０６上で実行するように設計されたアプリケーションにかなうある基準を求めることが出来る。１つのそのような要求は、信頼されたプライマリアプリケーションのユニークな識別子のリストを組み込むことであり得る。そのようなリストを有するレシピエントアプリケーション１０４は、受信したハンドシェイク要求が、要求をすることを承認されたアプリケーションによって送信されたかを確認して良い。レシピエント１０４はその後、そのようなアプリケーションを信頼し、通信を交わして良い。
【００３５】
プライマリアプリケーションのユニークな識別子に加えて、ハンドシェイク要求はまた、ハンドシェイクのために生成されたランダムな番号（例えば３２ビット、６４ビットなど）を含むことが出来る。このランダムな番号は、対象となるレシピエントアプリケーションに送信されることが出来、またレシピエントアプリケーション１０４によってプライマリアプリケーション１０４に送信される応答に組み込まれることが出来る。その結果、このランダムな番号（または、例えば以下で議論されるその予測可能な変形）を含む応答が、対象となるレシピエントから発していると特定されることが出来る。更なる側面によれば、このランダムな番号は、特定のハッシュ関数（SHA-1、SHA-2等）を用いてハッシュ（hashed）され、及び／または特定のインターフェース１０６上での送信のために切り捨てられる（truncated）ことが出来る。ハッシュされたランダムな番号は、更に一層、復号化が困難となり、なりすまし攻撃からの十分な保護を提供する。切り捨ては、異なるサイズ数をサポートする通信インターフェース１０６、及び／または種々のプロトコルを使用する、ランダムな番号を送信するために使用されることが出来る。例えば、ハンドシェイクセッションを特定する生成されたランダムな番号が３２ビットであった場合、そしてレシピエントアプリケーション１０４の通信インターフェースが１６ビットデータ伝送のみを可能とする場合、３２ビットのランダムな番号は、ハッシュされ、そして送信のために１６ビットデータに切り捨てられることが出来る。その後レシピエントは、ランダムな番号をハッシュして及び／または切り捨てて、通信の送信側がハンドシェイクのイニシエータ（initiator）であるかを確認するために、それを受信したハッシュされ及び／または切り捨てられた番号と比較することが出来る。
【００３６】
レシピエントアプリケーション１０４は、ハンドシェイク要求を受信することが出来、そして送信側１０２が信頼されたプライマリアプリケーションであるかを確認することが出来る。より具体的には、ユニークな識別子がハンドシェイク要求から取り出され、プライマリアプリケーション識別子のリストと比較されることが出来る。もし、取り出された識別子がリスト上の識別子と一致すれば、ハンドシェイク応答が送信側１０２に送信されることが出来、送信側１０２とレシピエント１０４との間に安全なチャネルが確立される。もし、取り出された識別子がリスト上の識別子と一致しなければ、このハンドシェイクと、引き続く通信は、確認されたハンドシェイクが受信されるまで、無視されることが出来る。
【００３７】
更に、レシピエントアプリケーション１０４は、ハンドシェイク要求内に含まれるランダムな番号を取り出し、記録することが出来る。具体的な例として、このランダムな番号を悪意のあるプログラムが取り出すこと、及びレシピエントアプリケーション１０４になりすますことをより困難にするため、このランダムな番号は、一時的なメモリ（図示せず）に記録されることが出来る。ハンドシェイク要求内に含まれるユニークな識別子が確認されると、上記議論したように、レシピエントアプリケーション１０４は、このランダムな番号を含むハンドシェイク応答を送信することが出来る。特に、ランダムな番号を含むことで、レシピエントアプリケーション１０４は、自身をプライマリアプリケーション１０２に開示することが出来る。ある側面によれば、上記議論されたように、レシピエントアプリケーション１０４自身へのなりすまし（例えば、生成され、従ってこのランダムな番号を信頼するように構成されたプライマリアプリケーション１０２に対して）をより困難にし、及び／またはハッシュされた番号が特定の通信インターフェース１０６とより互換性を持つように、レシピエントアプリケーション１０４はランダムな番号をハッシュし、及び／または切り捨てることが出来る。
【００３８】
更に、レシピエントアプリケーション１０４はまた、第２のランダムな番号（second random number）を生成して、ハンドシェイク要求に含めることが出来る。この第２のランダムな番号は、レシピエントアプリケーション１０４との引き続く通信において、プライマリアプリケーション１０２によって、それ自身を開示するために使用されることが出来る。プライマリアプリケーション１０２による引き続く通信は、上記議論されたように、第２のランダムな番号のインテグリティ（integrity）を保護するために、第２のランダムな番号をハッシュ及び／または切り捨てることが出来る。
【００３９】
更なる側面によれば、レシピエントアプリケーション１０４から引き続きハンドシェイク応答を受信することで、プライマリアプリケーション１０２は、レシピエントアプリケーション１０４にデータイベントを送信することが出来る。このデータイベントは、例えばモバイル環境に適したデータ構造またはデータを含むことが出来、データの要求を組み込むことが出来、または命令の実行を要求することが出来（例えば、診断情報の集中、設定パラメータの組み込み等）、またはそれらの組み合わせなどでありうる。この要求は、要求自身内にデータを含むことが出来、または共有メモリ内のデータを特定するアドレスポインタを使用することなどが出来る。データ／命令に加えて、データイベントは、データイベントの送信側がプライマリアプリケーション１０２であることを確認し、及び／または認証するために、レシピエントアプリケーションによって生成された第２のランダムな番号（例えば、ここで第２のランダムな番号はハッシュされ、及び／または切り捨てられている）を組み込むことが出来る。
【００４０】
ある側面によれば、プライマリアプリケーション１０２は、並行する（concurrent）データイベントの応答が受信されるまで、更なる命令やデータ要求などを含む更なるデータイベント（例えば、並行するデータイベントとは区別される）の送信を控えることが出来る。特定の応答を待つことにより、通信ラウンドトリップの概念が生成される。ラウンドトリップは、２方向の通信を含む。例えば、ラウンドトリップは、レシピエントによる応答だけでなく、プライマリアプリケーションによる要求を求める。逆もまた同じである。ラウンドトリップの概念はまた、予期された期間に受信されなかったデータの再送信を可能にする。例えば、ハンドシェイクの要求及びハンドシェイクの応答に関して測定された、プライマリアプリケーション１０２とレシピエントアプリケーション１０４との間におけるデータインターフェース１０６上の通信遅延が、良くされた応答タイマを確立するために使用されることが出来る。データ要求やハンドシェイクが送信されると、アプリケーション１０２、１０４は、送信への応答の予想時間を示す、予測応答タイマをセットすることが出来る。もし、この応答の予想時間内に応答が受信されなければ、状況に応じて、閾変化時間（例えば、応答の予想時間の何割か、または複数倍）と共に、レシピエントアプリケーション１０４は反応無しとみなされることが出来る。
【００４１】
上述の個々の実施形態のように、ランダムな番号は、各ラウンドトリップ通信につきインクリメント（increment）されることが出来る。例えば、もしプライマリアプリケーションが第２のランダムな番号を含むハンドシェイクの応答を受信すると、引き続くデータイベント要求（例えば診断情報の要求）は、一度だけインクリメントすることが出来（例えば、第１のラウンドトリップ通信を特定する）、データイベント要求に従って、インクリメントされた（ハッシュ及び／または切り捨てられた）ランダムな番号を送信することが出来る。レシピエントアプリケーション１０４は、ランダムな番号をインクリメントすること（及び、例えば必要に応じてそれをハッシュし切り捨てること）、及びその結果と、データイベント内に含まれるランダムな番号とを比較すること、によっても、データイベントの送信側を確認することが出来る。従って、システム１００は、ラウンドトリップを確認するメカニズムと同様に、安全で且つラウンドトリップの通信を規定する。代わりに、または更に、もしランダムな番号の比較が一致しなければ、受信した通信は無視されることが出来る。もしランダムな番号の比較が受信した通信の所定の及び／または設定可能な番号（例えば３）につき一致しなければ、ハンドシェイクがプライマリアプリケーション１０２とレシピエントアプリケーション１０４との間で再度イニシエイト（re-initiate）されて、アプリケーション１０２、１０４間で安全なチャネルが再度確立される（re-establishing）まで、引き続く要求／応答は無視されることが出来る。
【００４２】
もし、（例えば、応答期間内において、または応答期間プラス閾値内において）要求に対する応答が受信されなければ、アプリケーション１０２、１０４は、要求を再度イニシエイト出来る。ラウンドトリップの要求（requirement）のため、アプリケーション１０２、１０４は、少なくとも応答無し（non-responsive）のアプリケーション１０２、１０４につき、他に未解決の要求が存在しないことを仮定出来る。もし再度のイニシエイトされた要求（re-initiated request）に対して応答が受信されれば、データは処理され、通信は適切として継続されることが出来る。もし、応答が受信されなければ、アプリケーション１０２、１０４は、少なくとも要求の１つに対する応答が受信されるまで、所定の及び／または設定可能な数の（プライマリアプリケーション１０２とレシピエントアプリケーション１０４との間のデータインターフェース１０６における、予想されたまたは定められたパケットロス（packet loss）によって規定された）要求を再度イニシエイトすることが出来る。更に、所定の及び／または設定可能な数の、再度イニシエイトされた要求の後、応答が受信されなければ、アプリケーション１０２、１０４は、要求の送信を停止して単純に応答を待つか、またはアプリケーション１０２、１０４がプライマリアプリケーション１０２であれば、ハンドシェイクの再度のイニシエイトが、レシピエントアプリケーション１０４がまだ使用可能であるか否かを判定するために送信されることが出来る。その結果、多くの一般的なデータ送信メカニズムと異なり、ロストした要求及び／またはランダムな番号は、ロストしたパケットを把握するために求められる更なるデータパケットの再送信を行う必要無く（安全なＴＣＰ／ＩＰ環境におけるパケットロスと共に示されるように）、再送信及び／または再要求されることが出来る。従って、主題となる開示は、パケットをロスする環境において、受信されなかったそのような応答の単一の要求の再送信を許可することで、効率的なデータの再送信を提供する。
【００４３】
更に別の側面によれば、システム１００は、モバイルオペレーティングシステム１０６上で実行するアプリケーション間でのハンドシェイクの再度のイニシエイトを規定することが出来る。例えば、もしデータイベント要求の設定可能な数が、応答を引き出さない場合には、プライマリアプリケーション１０２はハンドシェイクを再度イニシエイト出来る。このハンドシェイクは少なくとも、ハンドシェイクセッションのために生成されたランダムな番号（または、新たなハンドシェイクセッションを生成するための新たなランダムな番号）と同様に、プライマリアプリケーション１０２のユニークな識別子を含むことが出来る。そのような方法において、もしレシピエントアプリケーション１０４がプライマリアプリケーションによって生成されたランダムな番号を失った場合、通信は再度確立されることが出来る。ある実施形態によれば、ハンドシェイクは、設定可能な及び／または所定の回数だけ、再度イニシエイトされることが出来る。そのような回数は、インターフェース１０６において定められた及び／または予想されるパケットロス、破壊工作ソフトによる干渉の可能性、またはそれらの組み合わせなどに基づくことが出来る。
【００４４】
上記に加えて、しきい時間内にレシピエントアプリケーション１０４からデータを受信出来なければ、プライマリアプリケーション１０２は、ハンドシェイクを再度イニシエイト出来る。代わりに、または更に、ハンドシェイクが最初にイニシエイトされた後のデフォルトの期間、またはこのデフォルトの期間のインテグラル（integral、例えば、１時間、２時間、３時間、など）の間、再度イニシエイトされることが出来る。更に別の側面によれば、ハンドシェイクの「開始」コマンドが機器のユーザインターフェースから受信されると（例えば、ユーザが診断を行う、及び／またはハンドシェイクをイニシエイトするユーザインターフェース［ＵＩ］の「ヘルプ」機能を実行するなど）、ハンドシェイクは再度イニシエイトされることが出来る。一般的に、ハンドシェイクの再度のイニシエイトは、設定可能な回数に制限されることが出来る。よって、もし３回のハンドシェイクの再イニシエイトが応答無しに送信されれば、例えばハンドシェイクのユーザのイニシエイトに従って、例えばハンドシェイクは単純に終了し、及び／または継続されない。よって、もしセッションのために与えられたランダムな番号がロストされた等の場合であっても、アプリケーション間の通信は再確立され及び／または継続されることが出来る。
【００４５】
システム１００はアプリケーション１０２、１０４間の通信のための、適切なデータインターフェース１０６及びまたはモバイルオペレーティングシステム１０６を使用出来ることが理解されるべきである。一実施形態によれば、ＢＲＥＷオペレーティングシステムは、オペレーティングシステム／データインターフェース１０６を備えることが出来る。より具体的には、ＢＲＥＷは、Qualcomm社、San Diego, Californiaによって開発されたBinary Runtime Environment for Wirelessソフトウェアを指す。例えば、無線演算機器上のアプリケーションの実行を制御するように動作する、他のランタイム環境も使用できる。オペレーティングシステム／データインターフェース１０６上は、機器の処理エンジン（図示せず）によって処理されるモジュールの、常駐バージョンや、遠隔アクセス可能なバージョンを与える、ソフトウェアの拡張（software extension）のクラスを含むことが出来る。これらのソフトウェアのクラスの拡張は、そのような機器上で処理するサブシステムと通信し、データの読み出し及び命令を有効にすることが出来る。例えば、ソフトウェアの拡張は、それを起動するアプリケーション１０２を代表して、コマンドを送信することが出来る。モジュールは、サブシステムの応答を、データインターフェース１０６を越えてレシピエントアプリケーション１０４に転送することが出来る。無線機器上の各常駐アプリケーション（resident application）１０２、１０４またはモジュールは、
他のアプリケーション１０２、１０４またはモジュールに独立したサブシステムと通信するために、新たなソフトウェアの拡張のインスタンス（instance）を生成することが出来る。
【００４６】
図２は、モバイル動作環境において実行されるアプリケーション間の安全な通信をイニシエイト出来る、見本となるシステム２００のブロック図を示す。システム２００は、１つまたはそれ以上の他のレシピエントアプリケーション（例えば、後の図３参照）とのハンドシェイクセッションを確立するように構成されたイニシエーションモジュール（initiation module）２０２を含むことが出来る。イニシエーションモジュール２０２は、通信の送信側を特定し及び／または認証するために、１つまたはそれ以上の、ハッシュされ及び／または切り捨てられたランダムな番号を使用することが出来る。更にイニシエーションモジュール２０２は、データイベントのラウンドトリップ送信及び受信を使用して通信出来、これにより、データをロストし、及び／または識別子をロストした場合において、各イベントについての再送信を可能とする。その結果、一般的なアーキテクチャに比べて、効率的で低電力で安全な通信アーキテクチャが提供される。
【００４７】
イニシエーションアプリケーション（initiation application）２０２は、レシピエントアプリケーション（図示せず）とのハンドシェイクを少なくともイニシエイトするように構成された安全セッションモジュール（secure session module）２０４を含むことが出来、このハンドシェイクは、ランダムな番号と、イニシエーションアプリケーション２０２のユニークなＩＤを含む。このランダムな番号は、レシピエントアプリケーションによってイニシエイトされる引き続く通信を確認するために使用できる。本明細書で説明したように、ランダムな番号は、安全な通信のために、なりすまし等の攻撃をより困難にするため、（例えば、イニシエーションアプリケーション２０２に結合されたハッシュモジュール（hashing module）２１６によって）ハッシュされ及び／または切り捨てられることが出来る。更なる実施形態によれば、もしハンドシェイクの応答が受信されなければ、あるいはもしデータイベントの応答を受信することなく、多くのデータイベント要求が送られる場合に、安全セッションモジュール２０４は、ハンドシェイクを再度イニシエイト出来る。ハンドシェイクの再度のイニシエーションは、このセッションに関連するランダムな番号をレシピエントアプリケーションに再度提供する点（例えば、もしレシピエントアプリケーションがランダムな番号をロストし、結果として受信したイベントに応答及び／または確認できなかった場合に）を除いては、安全なセッションの再確立を容易に出来る。
【００４８】
更なる実施形態によれば、この安全セッションモジュール２０４は、様々な状況において、ハンドシェイクをイニシエイト出来る。まず、もししきい期間内にレシピエントアプリケーションからデータを受信しなかった場合である。このようなハンドシェイクは、通信をリフレッシュし、例えばイニシエイトしているアプリケーション２０２にまだ結合されているかを判断するためのものであり得る。更にハンドシェイクは、（上で議論されたように）リフレッシュ回数が満了すれば、再度イニシエイトされることが出来る。代わりにまたは更に、もしコマンドが機器ユーザインターフェースから受信されれば（例えば、もしユーザが、ハンドシェイクがイニシエイトされることを要求すれば）、ハンドシェイクは再度イニシエイトされることが出来る。
【００４９】
更に別の実施形態によれば、安全セッションモジュール２０２は、ハンドシェイクの終了（termination）をイニシエイト出来る。例えば、もし、通信において受信されたランダムな番号が、イニシエイトしているアプリケーション２０２によって生成されたランダムな番号、またはそのインクリメントであると、正しく確認されなかった場合（例えば、安全な通信を脅かそうとする、認証されていない存在の可能性を示している場合）には、ハンドシェイクの終了が起こり得る。更に、もし、所定の数のハンドシェイクの要求がイニシエイトされた後に、ハンドシェイクの応答が受信出来なければ、ハンドシェイクの終了がイニシエイトされることが出来る。そのような結果は、例えばレシピエントアプリケーションが、イニシエイトしているアプリケーションに通信可能に結合されていないことを示すことが出来る。別の例として、もしイニシエイトしているアプリケーションが、通信セッションが完了したと判断すれば、終了（termination）が送信されることが出来る。
【００５０】
また、イニシエーションアプリケーション２０２内には、確認モジュール２０６が含まれる。確認モジュール２０６は、安全セッションモジュール２０４によってイニシエイトされたハンドシェイクへの応答を受信するように構成されることが出来る。そのような応答は、応答の番号と、第２のランダムな番号とを含むことが出来る。確認モジュール２０６は、通信がレシピエントアプリケーションによって送信されたかを判断するために、この応答の番号を取り出し、それをランダムな番号と比較することが出来る。より詳しくは、確認モジュール２０６は、ランダムな番号を適切にハッシュ及び／切り捨てて、その結果を応答の番号と比較することが出来る。もし結果が一致すれば、応答の番号はランダムな番号として確認されることが出来る。
【００５１】
上記に加えて、イニシエーションアプリケーション２０２はまた、もし確認モジュール２０６が応答の番号とランダムな番号とを一致させた場合に（すなわち、例えば、あるラウンドトリップセッションを特定する、適切なランダムな番号のインクリメントである場合に）データイベント要求を送信するように構成された、通信モジュール２０８を含むことが出来る。更に通信モジュール２０８は、もしデータイベントへの応答をレシピエントアプリケーションから受信しなかった場合に、データイベントを再送信出来る。ある側面では、このデータイベントの要求は、第２のランダムな番号のインクリメントを含むことが出来る。更に、このインクリメントは、ハンドシェイク及びハンドシェイクの応答に引き続く特定のラウンドトリップ通信に関連づけられることが出来る（例えば最初のインクリメントは最初のラウンドトリップデータイベントについてのものであり、第２のインクリメントは第２のラウンドトリップデータイベントについてのものであり、その他同様である）。このインクリメントは、認証されていない相手方から通信を更に保護するために使用されることが出来る。例えば、もし認証されていないプログラムが、ランダムな番号または第２のランダムな番号へのアクセスを引き起こす場合、もしこのランダムな番号の正しいインクリメントが、そのようなデータイベントと共に含まれていなければ、そのような番号を含むデータイベントは、イニシエイトしているアプリケーション２０２によってやはり拒絶されるだろう。認証されていないプログラムは、ハンドシェイク以来、ほとんどモニタされていないであろうから、並行するラウンドトリップのインスタンスを解読できそうになく、またイニシエーションアプリケーション２０２の信頼を得ることも出来ないだろう。
【００５２】
イニシエーションアプリケーション２０２はまた、少なくとも第２の番号のインクリメントを含むレシピエントアプリケーションからデータイベントの応答を受信した場合に、第２のデータイベントを送信する通信モジュールをイネーブルにするように構成された通信管理モジュール２１０を含むことが出来る。言い換えれば、管理モジュール２０２は、本明細書で議論されたラウンドトリップ通信ポリシー（policy）を実施するため、データイベントの応答が受信されるまで、通信モジュールが更なるデータイベントの送信をしないようにすることが出来る。従って、ロスとしたランダムな番号及び／またはデータイベントの要求は、モバイル動作環境のための信頼できる通信を容易にするため、イニシエーションアプリケーション２０２によってイニシエイトされることが出来る。
【００５３】
更なる側面によれば、システム２００は、イニシエーションアプリケーション２０２とインターフェースを取ることの出来る通信信頼性モジュール２１８を含むことが出来る。通信信頼性モジュール２１８は、パケットロスの頻度及び／またはイニシエーションアプリケーション２０２によって使用される通信インターフェース（例えば、上記図１におけるオペレーティング環境／データインターフェース１０６）についての可能性を判断するように構成されることが出来る。このパケットロスの判断は、応答が受信されなかった場合に、データイベントの再送信及び／またはハンドシェイクの再送信イベントの適切な回数を判断するために、イニシエーションアプリケーション２０２によって使用されることが出来る。より詳しくは、アプリケーション２０２は、適切な再送信を判断する際に、パケットロスの可能性を考慮し、もしパケットロスが大きければ、比較的高い回数の再送信が決定されることが出来る。もしパケットロスが小さければ、比較的低い回数の再送信が決定されることが出来る。
【００５４】
上記に加えて、システム２００は、プライマリ及びレシピエントアプリケーション間の予想時間を計算するように構成された、タイミング要素２１２を含むことが出来る。この予想時間は、例えば安全セッションモジュール２０４によってイニシエイトされたハンドシェイクへの応答を受信するために必要な時間を、少なくとも部分的には、基礎とすることが出来る。更に、もしデータイベントまたは引き続くハンドシェイクの応答が、予想された応答時間（例えば、この応答時間の分数または倍数のように、しきい期間によって任意で変形される）内に受信されなければ、この通信モジュール２０８または安全セッションモジュール２０４は、データイベントまたはハンドシェイクをそれぞれ再送信出来る。
【００５５】
更に別の側面によれば、システム２００は、安全な通信上で到来する応答及び／または要求をバッファするために、イニシエーションアプリケーション２０２をイネーブルにする処理バッファを含むことが出来る。その結果、アプリケーション２０２によって並行して実施される動作は、応答／要求を処理するために割り込まれずに済む。代わりに、応答／要求内のデータは、処理バッファにコピーされ、その後の期間に扱われることが出来る。従って、並列処理要求の受信にもかかわらず、同期処理がシステム２００によって導かれることが出来る。
【００５６】
図３は、モバイル動作環境において実行されるアプリケーション間の安全な通信に応答出来る、見本となるシステム３００のブロック図を例示する。システム３００は、少なくともハンドシェイクを受信し、送信側のアプリケーションのＩＤを取り出して確認し、そして送信側のアプリケーションが信頼されたプライマリアプリケーションであればハンドシェイクの応答をイニシエイトすることが出来る、レシピエントアプリケーション３０２を含む。従ってシステム３００は、モバイル動作環境における安全な通信を行うことが出来る。
【００５７】
レシピエントアプリケーション３０２は、プライマリアプリケーション（図示せず、但し上記図２の２０２参照）からのハンドシェイクの要求を受信するように構成された、少なくともセキュリティモジュール３０４を含むことが出来る。このハンドシェイクの要求は、プライマリアプリケーションによって生成されたランダムな番号及び／またはプライマリアプリケーションのユニークなＩＤを含むことが出来る。更にレシピエントアプリケーション３０２は、プライマリアプリケーションのユニークなＩＤを確認するように構成された参照モジュール３０６を含むことが出来る。例えば、この参照モジュールは、ユニークなＩＤを、信頼されたプライマリアプリケーションの識別子３１２のリストと比較することが出来る。そのようなリスト３１２は、レシピエントアプリケーション３０２が信頼すべきで、それからのハンドシェイクを受け入れるべきアプリケーションに関連付けられた全てのユニークなＩＤを含むことが出来る。よって、プライマリアプリケーションのユニークなＩＤは、リスト３１２を参照することによって、検証されることが出来る。
【００５８】
レシピエントアプリケーション３０２はまた、上記議論されたように、もしユニークなＩＤが参照モジュール３０６によって確認された場合に、プライマリアプリケーションにハンドシェイクの応答を送信するように構成されたインターフェースモジュール３０８を含むことが出来る。ある実施形態に寄れば、このハンドシェイクの応答は、レシピエントアプリケーション３０２によって送信された応答及び／または要求に応答して通信を確認するために、レシピエントアプリケーション３０２によって生成された第２のランダムな番号、及び／またはランダムな番号、または、ハッシュ及び切り捨てられたそのような番号（例えば、本明細書で説明されたように、ハッシュモジュール３１４によって生成される）を含むことが出来る。更に、インターフェースモジュール３０８は、データイベントの要求（例えばデータ、命令の動作、等）を受信、それへ応答、及びそれをイニシエイトするように構成されることが出来る。データイベントの要求は、例えば、少なくとも、ランダムな番号のインクリメントを含むことが出来、このインクリメントは、ラウンドトリップ通信を確認（identify）し、ランダムな番号は、セキュリティモジュール３０４によって受信されたハンドシェイクに関する通信を確認する。同様に、インターフェースモジュール３０８（及び、例えばレシピエントアプリケーション３０２）によってイニシエイトされたデータイベントの要求に関する応答は、少なくともランダムな番号のインクリメント（例えば、データイベントの要求に含まれる）、及び／またはプライマリアプリケーションのユニークなＩＤを含むことが出来る。代わりに、または更に、このデータイベントの応答は、レシピエントアプリケーションによって要求されたデータ、または命令の結果、またはそれらの組み合わせなどを含むことが出来る。
【００５９】
更なる側面によれば、レシピエントアプリケーション３０２はまた、更なるデータイベントの要求を受信する前に、先に受信したデータイベントの要求に応答するようインターフェースモジュール３０８に要求するように構成された管理モジュール３１０を含むことが出来る。従って、管理モジュール３１０は、本明細書で説明されたように、レシピエントアプリケーション３０２とプライマリアプリケーションとの間のラウンドトリップ通信のポリシーを執行することが出来る。更に、管理モジュール３１０は、インターフェースモジュール３０８がデータイベントの要求に応答することを許可し、そのような応答と共に、第２のランダムな番号のインクリメント及び／またはレシピエントアプリケーション３０２のアプリケーションＩＤを含むことが出来る。この応答は、イニシエイトしているアプリケーションについての適切なラウンドトリップを確認し、更にアプリケーションＩＤを経てアプリケーション３０２の情報を提供出来る。代わりに、管理モジュール３１０は、インターフェースモジュール３０８に、プライマリアプリケーションによって実行される命令及び／またはデータについての要求と同時に、ランダムな番号のインクリメントを含むデータイベントの要求の送信を許可出来る。
【００６０】
１つまたはそれ以上の他の側面によれば、管理モジュール３１０は、レシピエントアプリケーション３０２において並列するプロセスの割り込みを避けるため、到来する命令のバッファリングを容易にすることが出来る。より具体的には、管理モジュール３０２は、データイベントの要求に含まれる命令に適切なデータバッファ３１６を割り当て、データ要求内に含まれるデータをこのデータバッファ３１６にコピー出来る。更に管理モジュール３１０は、現在のプロセスを完了するために必要な見積もり時間を少なくとも部分的に基礎にした処理タイマ（process timer）をセットすることが出来る。上記加えて、管理モジュール３１０はまた、レシピエントアプリケーション３０２を、処理タイマが満了するまで、データイベント内に含まれるデータを処理させないようにすることが出来る。よって管理モジュール３１０は、レシピエントアプリケーション３０２についての命令の同期実行を容易に出来る。
【００６１】
ある実施形態によれば管理モジュール３１０は、インターフェースモジュール３０８に対して、１つまたはそれ以上のデータイベントの要求を無視するよう命令出来る。例えば、もしランダムな番号またはそのインクリメントが、適切なラウンドトリップ通信に一致しなければ、通信のインテグリティは疑わしいかもしれない。その結果、管理モジュール３１０は、そのような通信に応答が与えられる前にイニシエイトされ、確認可能な信頼されたユニークなＩＤを有する、新たなハンドシェイクを求めることが出来る。
【００６２】
更なる実施形態によれば、管理モジュール３１０は更に、例えば新たなランダムな番号と、ユニークなＩＤまたは第２のユニークなＩＤとを含む、ハンドシェイクの再イニシエーションメッセージ（re-initiation message）を受信するよう構成されている。管理モジュール３１０は、ユニークなＩＤ／第２のユニークなＩＤが確認されるまで、この新たなランダムな番号を、一時的なバッファ３１６に記憶出来る。もし、このＩＤが信頼されたアプリケーションと確認されれば、ハンドシェイクは承認され、この新たなランダムな番号は、プライマリアプリケーションによって送信された以前のランダムな番号を置き換えることが出来る。もしＩＤが確認されなければ、ハンドシェイクは承認されず、新たなランダムな番号は一時的なバッファ３１６から削除されることが出来る。従って、管理モジュール３１０は、確認された以前のハンドシェイクのパラメータを失うことなく、新たにイニシエイトされたハンドシェイクを処理出来る。
【００６３】
更なる側面によれば、もしインターフェースモジュール３０８によって送信されたデータイベントの要求への応答が受信されなければ、インターフェースモジュール３０８は、設定可能な回数（例えば、判定されたパケットロス等に依存する）だけ、この要求を再送信出来る。もし所定の回数だけ要求を再送信した後も応答が受信されなければ、管理モジュールは、その後に続くハンドシェイクが受け入れられるまで（例えば、それが確認課可能なプライマリアプリケーションのクラスＩＤを含む）、インターフェースモジュール３０８が更なる要求を送信することを抑制出来る。従って、管理モジュール３１０はまた、モバイル動作環境におけるアプリケーションにつき、より効率的で更に信頼出来るデータ交換を容易にするために、応答のないプライマリアプリケーション（non-responding primary application）から応答を導こうとする試みにおいて消費される処理リソースを制限出来る。
【００６４】
図４は、モバイルアプリケーションを実行出来、アプリケーション間における安全で低電力の通信を提供出来る、例となるモバイル機器４００を例示する。より具体的には、モバイル機器４００は、モバイルアプリケーション４１４、４１６間の通信を容易にする共通のプラットフォーム（platform）４０８、４１０、４１２を提供出来、及び／または第２のアプリケーション（second application）４１４、４１６を含む遠隔機器（図示せず、しかし下記する図５参照）と無線により相互に接続する第１のアプリケーション４１４、４１６のためのプラットフォームを提供出来、介在する無線ネットワーク、コアモバイルネットワーク、及び／またはＩＰネットワーク等が、遠隔機器４００、５０４ａ、５０４ｂ間の通信インターフェースを提供する。従ってシステム４００は、単一の機器４００、または遠隔のネットワーク接続された機器４００、５０４ａ、５０４ｂの処理及び通信アーキテクチャ（例えばプロセッサ４０８、メモリ４１０、通信ポリシー４２、及び適切なバス構造）によって、結合されたモバイルアプリケーション間の安全な通信を提供出来る。
【００６５】
モバイル機器４００は、信号（例えば、モバイル機器に対してデータの移転、ハンドシェイク、ハンドシェイクの応答、データイベント、データイベントの応答、ハンドシェイクの終了、など）を受信する少なくとも１つのアンテナ４０２（例えば通信受信機、または入力インターフェースを備えたそのような受信機の集合）、及び受信信号につき一般的な処理（例えばフィルタ、増幅、ダウンコンバートなど）を実行する受信機４０４を含む。より具体的には、アンテナ４０２は、本明細書で説明したように、データイベントの要求、ハンドシェイクへの応答、及び同種のもの（例えば、モバイル機器４００において実行される少なくとも１つのアプリケーションによって生成されたランダムな番号、対応するアプリケーションによって生成されたランダムな番号、データイベントへの応答、などを含む）を受信出来る。
【００６６】
アンテナ４０２及び受信機４０４はまた、受信したシンボルを復調し、評価のためにそれをプロセッサ４０８に提供出来る変調器４０６に結合され得る。プロセッサ４０８は、アンテナ９０２またはモバイル機器のユーザ入力インターフェース（図示せず）によって受信された情報を解析し、及び／または送信機４２０による送信のための情報を生成出来る。更にプロセッサ４０８は、モバイル機器４００の１つまたはそれ以上の要素４０６、４１２、４１４、４１６、４１８を制御し、及び／または参照することが出来る。更にプロセッサ４０８は、本明細書で述べられたように、モバイルアプリケーションのためのアプリケーション間の安全なデータ転送を提供する、１つまたはそれ以上のモジュール、アプリケーション、またはそれと同様のものを実行出来る。
【００６７】
モバイル機器４００は、動作可能なようにプロセッサ４０８に結合され、送信されまた受信される等のデータを保持出来るメモリ４１０を更に含むことが出来る。メモリ４１０は、モバイル機器４００上にある、及び／または遠隔インターフェースを通じて分布（下記に述べる図５参照）された、モバイルアプリケーション４１４、４１６間における安全な通信を導くための通信ポリシー４１２に関連する情報を保持出来る。より具体的には、本明細書で述べられたような、ラウンドトリップ通信の実施、未承認の通信の再送信、ハンドシェイクのイニシエイト及び再イニシエイト、または同種のもののルールと同様に、確認とセキュリティの目的のための、ランダムな番号の生成、インクリメント、ハッシュ及び／または切り捨て、並びにそのような番号の対象となるアプリケーション４１４、４１６への送信のルールが、この通信ポリシー４１２内に含まれることが出来る。更に、メモリ４１０は、本明細書で述べたように、更なるアプリケーション４１６及び／またはハンドシェイクの要求を受信し、プライマリアプリケーション４１４が信頼されたアプリケーション（例えば、上記図３において示されたいくつかまたは全てのモジュールを含む）であるかを確認するように構成された第２のアプリケーション４１６と共に、少なくともハンドシェイクの要求（例えば、上記図２において示されたいくつかまたは全てのモジュールを含む）をイニシエイトするように構成された、プライマリアプリケーション４１４を含むことが出来る。
【００６８】
本明細書で説明されたデータ保持（例えばメモリ１４０８）は、揮発性メモリまたは不揮発性メモリであって良いことが理解されるだろう。例示の目的で且つこれに限定するものでないが、不揮発性メモリは、読み出し専用メモリ（ＲＯＭ）、書き込み可能なＲＯＭ（ＰＲＯＭ）、電気的に書き込み可能なＲＯＭ（ＥＰＲＯＭ）、電気的に消去可能なＰＲＯＭ（ＥＥＰＲＯＭ）、またはフラッシュメモリを含むことが出来る。揮発性メモリは、外部キャッシュメモリとして動作するランダムアクセスメモリ（ＲＡＭ）を含むことが出来る。例示の目的で且つこれに限定するものでないが、揮発性メモリは、シンクロナスＲＡＭ（ＳＲＡＭ）、ダイナミックＲＡＭ（ＤＲＡＭ）、シンクロナスＤＲＡＭ（ＳＤＲＡＭ）、ダブルデータレートＳＤＲＡＭ（ＤＤＲ ＳＤＲＡＭ）、エンハンスドＳＤＲＡＭ（ＥＳＤＲＡＭ）、Synchlink ＤＲＡＭ（ＳＬＤＲＡＭ）、及びダイレクトラムバス（direct Rambus（登録商標））ＤＲＡＭ（ＤＲＲＡＭ）のような多くの形態で利用可能である。主題となるシステム及び方法のメモリ１４０８は、これに限定されないが、これらの及びその他の適切なタイプのメモリを含むことを意図している。
【００６９】
モバイル機器４００は更に、変調器４１８、及び（例えばプロセッサ４０８及び変調器４１８によって）生成された信号を、例えば基地局、アクセスポイント、別のアクセス端末、リモートエージェント（remote agent）等に送信する送信機４２０を備えている。プロセッサ４０８とは分離して図示されているが、プライマリアプリケーション４１４及び／または第２のアプリケーション４１６は、プロセッサ４０８または複数のプロセッサ（図示せず）の一部であっても良いことが理解される。
【００７０】
図５は、ある側面に従った遠隔機器５０４ａ、５０４ｂ上で動作するモバイルアプリケーション（図示せず、しかし上記図４の４１４、４１６参照）のための安全な通信を提供する、見本となるネットワーク５００を図示している。システム５００は、互いに及び／または１つまたはそれ以上のモバイル機器５０４ａ、５０４ｂに無線通信信号を受信、送信、再送等する、１つまたはそれ以上のセクタにおいて、１つまたはそれ以上の基地局５０２を備えることが出来る。図示するように、各基地局５０２は、５０６ａ、５０６ｂ、５０６ｃ、及び５０６ｄとラベルされ、３つの地理的な領域として示された、ある特定の地理的領域について、通信可能範囲を提供出来る。各基地局５０２は、当業者に理解されるように、それぞれが、信号の送受信に関連付けられた複数の要素（例えば図６に示されるように、プロセッサ、変調器、マルチプレクサ、復調器、デマルチプレクサ、アンテナ、等）を順々に交代に備えることが出来る、送信機チェイン（transmitter chain）及び受信機チェイン（receiver chain）を備えることが出来る。モバイル機器５０４は、例えば携帯電話、スマートフォン、ノート型パソコン、携帯型通信機器、携帯型コンピュータデバイス、衛星ラジオ、全地球測位システム、ＰＤＡ、及び／または無線ネットワーク５００上で通信するその他の適切な機器であり得る。システム５００は、遠隔機器（例えば、下記図６に示されるようなモバイル機器５０４ａ、５０４ｂ、またはネットワーク５００上の動作要素）上で動作するモバイルアプリケーション間の安全な通信を容易にするため、本明細書で説明された種々の側面と共に使用されることが出来る。
【００７１】
１つまたはそれ以上のある側面によれば、基地局５０２は一般的に、モバイル機器５０４ａ、５０４ｂと通信する固定局（fixed station）であり、またアクセスポイント、ノードＢ、またはその他の専門用語で呼ばれ得る。モバイル機器５０４ａ、５０４ｂは一般的に、システム５００全体において分散しており、５０４ａ、５０４ｂそれぞれは、は固定式、移動体、または準移動体（例えばラップトップ）の機器である。モバイル機器は、いつの時点においても、基地局５０２と通信していないか、１つまたは複数の基地局５０２と、ダウンリンク（基地局５０２から機器５０４ａ、５０４ｂへ送信されたデータ）及びアップリンク（機器５０４ａ、５０４ｂから基地局５０２へ送信されたデータ）で通信している。集権的アーキテクチャとして、システムコントローラ（例えば無線ネットワークコントローラ［ＲＮＣ］、または同様のもの、図示せず）は、基地局５０２に結合されることが出来、また通信、プロトコル、診断集合、または基地局５０２に関連付けられた同様の動作の調整及び制御を提供出来る。分散的なアーキテクチャでは、必要に応じて基地局５０２は互いに通信し合うことが出来る。
【００７２】
図６は、別の側面に従ったモバイルアプリケーションのための、安全な遠隔通信（remote communication）において助けとなる、及び／または加わる基地局６０２を含む、例となるシステム６００を例示する。システム６００は、複数の受信アンテナ６０６を介して１つまたはそれ以上のモバイル機器６０４から信号を受信する受信機６１０と、送信アンテナ６０８を介して１つまたはそれ以上のモバイル機器６０４に送信する送信機６２２を有する基地局６０２（例えばアクセスポイント等）を含む。受信機６１０は、受信アンテナ６０６から情報を受信することができ、そして更に受信しなかったまたは判読できなかったデータパケットに関するフィードバックデータを受信する信号受信部（図示せず）を備えることができる。更に受信機６１０は、受信した情報を復調する復調器６１２と動作可能に関連付けられる。プロセッサ６１４は、復調器６１２から与えられる復調されたシンボルを解析することが出来る。プロセッサ６１４は更に、本明細書で説明された安全な遠隔通信において助けとなり、及び／または加わるアプリケーション６１８を保持することが出来るメモリ６１６に結合される。
【００７３】
例えば、アプリケーション６１８は、ハンドシェイクをイニシエイトし、データイベント（例えば、診断情報、データ解析、等に関連する）の要求をモバイル機器６０４上で動作するレシピエントアプリケーションに送信するように構成されたプライマリアプリケーションであって良い（例えば、アプリケーション６１８は、安全なモバイルアプリケーションのハンドシェイクのイニシエイト及び安全な通信への参加にあたって、上記した図２に示したモジュールのいくつかまたは全てを組み込むことが出来る）。あるいは、アプリケーション６１８は、ハンドシェイクの要求を受信し、本明細書で説明したようにイニシエイトしているプライマリアプリケーションを認証出来る第２のアプリケーションであっても良い（例えばアプリケーション６１８は、ハンドシェイクの受信及び応答、並びに安全な通信への参加にあたって、上記した図３に示したモジュールのいくつかまたは全てを組み込むことが出来る）。アプリケーション６１８は更に、アプリケーション６１８をモバイル機器６０４上の対応するアプリケーションに対してアプリケーション６１８を確認するためのランダムな番号（逆もまた同様）、またはある特定のラウンドトリップ通信を特定するためのそのようなランダムな番号のインクリメント生成または／及び確認するためのルールを含むことが出来る。更に、このルールは、本明細書で述べられたような、未承認の通信の再送信、ハンドシェイクの要求及び／または応答の再イニシエイト、及びハンドシェイクの終了についてのポリシーを確認出来る。従って、アプリケーション６１８は、モバイル機器６０４上にある１つまたはそれ以上のアプリケーション、及び／または本明細書で説明された機能及び種々の動作の実施に関するその他の適切なアクティビティとの、安全なモバイル通信に加わることが出来る。
【００７４】
本明細書で述べられた実施形態は、ハードウェア、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、またはこれらの組み合わせで実現可能であることが理解されるだろう。ハードウェア実装では、処理ユニットは、１つまたはそれ以上の特定用途向け集積回路（ＡＳＩＣ）、デジタルシグナルプロセッサ（ＤＳＰ）、デジタル信号処理デバイス（ＤＳＰＤ）、プログラマブルロジックデバイス（ＰＬＤ）、フィールドプログラマブルゲートアレイシグナル（ＦＰＧＡ）、プロセッサ、コントローラ、マイクロコントローラ、マイクロプロセッサ、本明細書で説明された機能を実現するために設計された他の電子ユニット、またはこれらの組み合わせで実現され得る。
【００７５】
実施形態がソフトウェア、ファームウェア、ミドルウェア、またはマイクロコード、プログラムコード、またはコードセグメントで実装される場合、これらは記憶要素のような機器読み出し可能な媒体に保持され得る。コードセグメントは、手順、機能、サブプログラム、プログラム、ルーチン、サブルーチン、モジュール、ソフトウェアパッケージ、クラス、または命令、データ構造、またはプログラムステートメントの組み合わせを表し得る。コードセグメントは、情報、データ、アーギュメント、パラメータ、またはメモリコンテンツを渡す、及び／または受信することにより、別のコードセグメントまたはハードウェア回路と結合され得る。情報、アーギュメント、パラメータ、データ等は、メモリ共有、メッセージパッシング（message passing）、トークンパッシング（token passing）、ネットワーク送信などを含む適切な手段を用いることで、パスされ、フォワードされ、または送信されることができる。
【００７６】
ソフトウェア実装においては、本明細書で説明された方法は、本明細書で説明された機能を実行するモジュール（手順、機能、及び同種のもの）で実装され得る。ソフトウェアコードは、メモリユニットに保持され、プロセッサで実行され得る。メモリユニットは、プロセッサ内に実装されることができ、または当技術分野で周知の種々の手段を介してプロセッサと通信可能に接続されることができる場合に、プロセッサの外部で実装され得る。
【００７７】
図７乃至１２を参照して、少なくとも部分的にでもモバイル動作環境で動作するアプリケーションのための安全な通信を提供することに関する手順が示される。説明の簡略化の目的で、手順は一連の動作として説明されるが、手順はこの動作順に限定されるものでは無いことが理解され、認識されるだろう。例えば、１つまたはそれ以上の側面に従って、いくつかの動作は、本明細書で示され述べられたものとは別の動作と同時に、及び／または異なる順序で行われることが出来る。更に、手順は代わりに、状態図に示すように、一連の関連付けられた状態またはイベントとして示されることも出来ることを、当業者は理解し、認識するだろう。更に、１つまたはそれ以上の側面に従った手順を実施するために、例示された全ての動作が、必ずしも要求されるわけでは無い。
【００７８】
図７を参照して、モバイル動作環境におけるモバイルアプリケーション間の安全な通信をイニシエイトするための例となる手順７００が示される。方法７００は７０２において、ハンドシェイクのために生成されたランダムな番号と、プライマリモバイルアプリケーションのユニークな識別子とを含むモバイルアプリケーションとのハンドシェイクをイニシエイト出来る。このプライマリアプリケーションは、メッセージパッシング（message passing）アーキテクチャ、または共有メモリ、またはそれらの適切な組み合わせ、または同様のデータ転送プラットフォームを用いて、モバイルオペレーティングシステム（例えばＢＲＥＷ動作など）を介して、モバイルアプリケーションと通信するように構成されることが出来る。ハンドシェイクにおいて確認されるこのユニークな識別子は、プライマリアプリケーションが信頼されたアプリケーションであると特定するために使用されることが出来る。他方、ランダムな番号は、モバイルアプリケーションによって、それ自身をプライマリアプリケーションに特定するために使用されることが出来る。従って、このランダムな番号（及び／または、例えばその適切なインクリメント）を含む、プライマリアプリケーションにおいて受信された通信は、モバイルアプリケーションに関連付けられることが出来る。前述から当然のように、もしプライマリアプリケーションで受信した通信がランダムな番号（及び／または、例えばその適切なインクリメント）を含まなければ、この通信はハンドシェイクに関連付けられないとみなされ、よって安全では無い。
【００７９】
７０４において方法７００は、ハンドシェイクの応答を受信出来る。特に、このハンドシェイクの応答は、モバイルアプリケーションによって生成された第２のランダムな番号と第１の番号とを含むことが出来る。より具体的な例として、プライマリアプリケーションは、モバイルアプリケーションに送信されたデータイベントにおける第２のランダムな番号（及び／または、例えばその適切なインクリメント）を含むことが出来る。この第２のランダムな番号は、プライマリアプリケーションを、モバイルアプリケーションとの安全なハンドシェイクセッションをイニシエイトした安全なアプリケーションと確認／承認出来る。
【００８０】
７０６において方法７００は、参照番号７０４においてハンドシェイクの応答と共に受信した第１の番号が、ランダムな番号またはその適切なインクリメントであるかを確認出来る。例えば、第１の番号は、それらが等価であるかを確認するために、ランダムな番号と比較されることが出来る。あるいは、もし第１の番号がランダムな番号のハッシュ（例えばSHA-1、SHA-2など）及び／または切り捨てられたもの（例えば３２ビットから１６ビットなど）であれば、ランダムな番号はハッシュされ、切り捨てられ、そして第１の番号と比較されることが出来る。もし、第１の番号とランダムな番号（または、例えばそのハッシュ及び／または切り捨てられたもの）とが一致すれば、プライマリアプリケーションはハンドシェイクの応答を、モバイルアプリケーションから発せられたと認証し、このハンドシェイクに関連透けられた引き続くデータイベント要求のための第２のランダムな番号を記憶することが出来る。もし第１の番号とランダムな番号とが一致しなければ、第２の番号は破棄されることが出来る。
【００８１】
７０８において方法７００は、データイベントをモバイルアプリケーションに送信出来る。このデータイベントは、プライマリアプリケーションを特定／認証するために、第２のランダムな番号またはそのインクリメント（例えば、プライマリアプリケーションを、モバイルアプリケーション及び／またはハンドシェイクセッションのあるラウンドトリップ通信と同一に扱うため）を含むことが出来る。更に、このデータイベントは、モバイルアプリケーションから更なるデータを要求し、実行されまた応答において与えられた結果である命令を要求するなどが可能なデータのブロック（及び、例えばこのデータのブロックのサイズを特定するアドレスポインタ、共有メモリにおけるこのデータのブロックの位置を特定するアドレスポインタなど）を含むことが出来る。従って、方法７００によって説明された安全な通信は、安全な環境において他のアプリケーションを制御／構成し、及び／またはデータを得るために使用されることが出来る。
【００８２】
７１０において、ハンドシェイクセッションに関連付けられ、参照符号７０２においてイニシエイトされ、ランダムな番号及び／またはそのインクリメントに関連付けられた第２のデータイベントは、データイベントに対する応答が受信されるまで遅延されることが出来る。従って、方法７００は、１つまたはそれ以上のモバイルアプリケーション間のラウンドトリップ通信を実施出来る。より具体的には、ラウンドトリップ通信は、１つまたはそれ以上のイニシエイトされたイベントと、そのようなイベントに対する受信された応答とを含むことが出来、それぞれのイベント／応答のペアは、ラウンドトリップ通信を特定するインクリメントされたランダムな番号を与えている。よって、モバイル動作環境のための、比較的低電力消費（例えば、数学的に集中的な暗号化／復号化スキームとは反対に、暗号化にハッシュ関数を使用することにより）の同期通信が提供され得る。
【００８３】
図８は、一側面に従った、ラウンドトリップ通信を完了するためのデータイベントの再送信についての、見本となる手順８００を例示する。方法８００は８０２において、２つのアプリケーション間（少なくとも１つはモバイルアプリケーションである）での安全な通信のハンドシェイクを確立出来る。このハンドシェイクとその応答は、引き続くデータ要求のイニシエータを特定するための、少なくとも１つの生成されたランダムな番号を含むことができる。更に、このランダムな番号は、モバイル処理電力を削減するために、その切り捨て及び／またはハッシュ関数を用いて、符号化されることができる。従って、方法８００は、効率的で安全な、アプリケーション間のデータ転送を提供できる。
【００８４】
更なる側面によれば、方法８００はまた、そのようなアプリケーション間の転送信頼性を向上できる。例えば８０４において方法８００は、データイベントを送信できる。このデータイベントは、レシピエントモバイルアプリケーションに、イニシエイトしているモバイルアプリケーションを特定するランダムな番号（または、例えばその適切なインクリメント）を含むことができる。更に、データイベントは、レシピエントアプリケーションについての動作（データの転送、診断動作、分析など）の要求を含むことができる。８０６において、判断は、データイベントに対する応答が受信されたかによってなされる。具体的には、この判断は、決定された及び／または予測されたラウンドトリップ応答時間（例えば、ハンドシェイクセッションの期間に測定される）、及び任意的にそのような応答時間の分数及び／または倍数、に少なくとも部分的に基づく応答タイマを使用できる。具体例として、もしこの応答が、ある応答タイマの満了前に受信できなければ、方法８００は、参照符号８０８に進む。もしデータイベントに対する応答が、応答タイマの満了前に受信されれば、方法８００は８１０に進み、ハンドシェイク通信を継続できる。
【００８５】
参照符号８０８において方法８００は、データイベントを、少なくともデータイベントの応答を受信するまで、設定可能な回数（例えば、アプリケーション間のデータパケットロスの、確定した及び／または予測される可能性に関連する）だけ、再送信出来る。８１２において方法８００は、データイベントの応答が、要求の複数回（設定可能な回数）の再送信の結果として受信されたかによって、別の判断を行うことが出来る。もしデータイベントの応答が受信されれば、方法８００は８１０に進み、通信は継続される。もし適切な応答が受信されなければ、方法８００は参照符号８１４に進み得る。
【００８６】
８１４において方法８００は、少なくともハンドシェイクの応答を受信するまで、設定可能なある回数だけ、ハンドシェイクを再度イニシエイトできる。一例として、もしレシピエントアプリケーションが、ハンドシェイクセッションを特定するランダムな番号をロストした場合には、このレシピエントアプリケーションは、参照符号８０４、８０８において送信されたデータイベントを認証することが出来ないかもしれない。従って、本明細書で述べたように、レシピエントアプリケーションは、そのような要求を無視出来うる。参照符号８１４においてハンドシェイクをイニシエイトすることにより、このランダムな番号または新たなランダムな番号は、プライマリアプリケーションのユニークな識別子と共に、レシピエントアプリケーションに再度与えられ得る。その結果、それぞれハンドシェイクはリフレッシュされ、または改めて開始されることが出来る。
【００８７】
参照符号８１６において方法８００は、ハンドシェイクに対する応答が受信されたかを判断できる。もしそうなら、方法８００は８１０に進み、通信は継続される（例えば、データイベントまたは引き続くデータイベントが再送信／送信される）。もしそうでないなら、方法８００は８１８に進み、ハンドシェイクの終了が送信され得る。８１８において、レシピエントアプリケーションはもはや送信側のアプリケーション通信可能に結合されておらず、またはレシピエントは、悪意のあるプログラムによって危うくされ、または通信ポリシーが改竄された等とみなされる。ハンドシェイクの終了には、ランダムな番号、プライマリ及び／またはレシピエントアプリケーションのＩＤ、通信に含まれたデータなどの、ハンドシェイクに関連する全てのデータを消去すること、が含まれうる。上記したように、方法８００は、更なるデータの要求の前に、ロストした／承認されないデータの要求を再送信することによって、信頼できる同期通信を提供出来る。よって、
送信におけるエラーは直ちに訂正され、冗長な再送信（例えば、安全なＴＣＰＩＰ通信にあるように）を回避できる。
【００８８】
図９は、モバイルアプリケーション間での安全な通信における、ラウンドトリップ通信をインクリメントするための手順９００の例を示す。９０２において方法９００は、少なくともランダムな番号を含むハンドシェイクイニシエーションを送信できる。このランダムな番号は、レシピエントアプリケーションにより、通信をそのようなレシピエントから発せられた（originating）と安全に特定するために、使用されることが出来る（例えば、なぜならこのランダムな番号は、レシピエントアプリケーションにのみ送信されたから）。このハンドシェイクは更に、本明細書で述べられたように、イニシエイトしているアプリケーションのユニークなＩＤを含み得る。
【００８９】
９０４において、ハンドシェイクに対する応答が受信されることが出来る。９０６において、この応答がランダムな番号、またはその適切なバージョン（例えば、ハッシュされ及び／または切り捨てられたバージョン）を含むかによって、判断がなされ得る。もしそうでないなら、方法９００は９１０に進み、ハンドシェイクの終了が送信され、任意的に、このランダムな番号、受信した番号、送信されたデータ、及びその種のものを含む、ハンドシェイクセッションに関連した全てのデータが削除され得る。もし、参照符号９０４において受信した応答内に適切な番号が含まれていれば、方法９００は９０８に進み、受信されたランダムな番号はインクリメントされ、レシピエントアプリケーションに送信されたデータイベント内に組み込まれ得る。このインクリメントされたランダムな番号は、本明細書で述べたように、並行するラウンドトリップ通信セッションを特定できる。
【００９０】
９１２において、もし受信されていれば、データイベントに対する応答が、ランダムな番号の適切なインクリメントを含むかによって、判断がなされる。もしそうでなければ、方法９００は９１０に進み、ハンドシェイクの終了がイニシエイトされ得る。より詳細には、もし不適切なインクリメントが受信されていれば、データイベントの応答は認証されていないアプリケーションから送信されている（例えば、ランダムな番号は改竄された）とみなされ、またはレシピエントアプリケーションの安全な通信ポリシーが改竄されているなどとみなされることが出来る。もし、参照符号９１２において、ランダムな番号の適切なインクリメントが受信されていれば、方法９００は９１４に進み、ランダムな番号の更なるインクリメントが、引き続くデータイベントに含まれる。９１６において、もし受信されていれば、引き続くデータイベントの応答が、ランダムな番号の更なる適切なインクリメントを含むかにより、別の判断がなされ得る。もしそうなら、方法９００は９１８に進み、方法９００及び／または本明細書の別の部分で述べた通りに、通信は継続される。９１６においてもし適切なインクリメントが判断されなければ、方法９００は９１０に進み、上記したハンドシェイクの終了がイニシエイトされ得る。上記のように、方法９００は、モバイルアプリケーション間での安全な通信への適切なデータイベントラウンドトリップと同様に、ハンドシェイクセッションを特定する、インクリメントされたランダムな番号のラウンドバイラウンド（round-by round）解析を提供出来る。
【００９１】
図１０は、モバイル動作環境におけるモバイルアプリケーション間の安全な通信に応答するための、見本となる手順１０００を例示する。１００２において、ハンドシェイクの要求が受信され得る。このハンドシェイクの要求は、本明細書で述べたように、イニシエイトしているアプリケーションのユニークな識別子、及び／またはハンドシェイクのランダムな番号を含み得る。１００４において、もし受信されれば、ユニークな識別子が、信頼されたプライマリアプリケーションＩＤのリストに対して照会され得る。もし、受信したユニークなＩＤとの間での一致が見られれば、方法９００は１００６に進むことが出来る。そうでなければ、方法９００は終了することが出来る（図示せず）。１００６において、ユニークなＩＤが信頼されたアプリケーションのリストに対して確認されれば、ハンドシェイクに対する応答が送信されることが出来る。１００８において、データイベントの要求が受信され得る。このデータイベントの要求は、例えば、ハンドシェイクセッション（例えば、このようなセッションは、参照符号１００２で受信されたハンドシェイク要求と、参照符号１００６で送信されたハンドシェイク応答によって確立される）に関連付けられた、次にやってくる通信を特定するための、ハンドシェイクの応答に含まれる第２のランダムな番号を含むことが出来る。１０１０において、更なるデータイベントの受信は、少なくともデータイベントの要求が応答されるまで、遅延されることが出来る（例えば、データイベントに対する応答は、更なるデータイベントの要求の受信の前に送信される）。従って、方法１０００は、イニシエイトしている及びレシピエントアプリケーションによって生成されたランダムな番号を組み込むことで、安全な通信のために、ラウンドトリップ通信のポリシーを課すことが出来る。更に、そのような番号は、低い処理の要求の電力コストにより更なるセキュリティを提供するために、ハッシュされ、切り捨てられることが出来る。従って、方法１０００は、モバイル動作環境に特に有益な、安全なアプリケーション間通信に応答し、また加わるためのメカニズムを提供する。
【００９２】
図１１は、最初の要求とラウンドトリップ通信が、安全なアプリケーション間データ転送を完了するまで、引き続くデータイベントの要求をバッファリングする、一例となる手順１１００を示す。１１０２において、安全なモバイルアプリケーションのハンドシェイクが、本明細書で述べたように確立されることが出来る。１１０４において、データイベントの要求が、受信されることが出来る。更に、１１０６において、データバッファが、データイベントの要求内に含まれ、及び／またはそれによって特定されるデータを保持するために、割り当てられ得る。例えば、そのような要求は、命令、設定パラメータ、解析されるデータ、行われるモバイル通信の診断（例えば、ＱｏＳ機能）等を含むことが出来る。１１０８において、参照符号１１０４で受信されたデータイベントの要求内に含まれるデータは、参照符号１１０６で割り当てられたデータバッファ内にコピーされることが出来る。１１１０において、処理タイマがセットされることが出来る。例えば、処理タイマは、レシピエントアプリケーションにおいて実行される並行処理を完了するのに予測される時間を示し得る。処理時間は、並列処理が完了するまで、データイベントの要求で受信されたデータの処理を遅延させることが出来る。１１１２において方法１１００は、少なくとも処理タイマが満了するまで、データイベントの要求内で受信したデータの処理（及び、例えば受信すること、受信は処理を含む）をやめることが出来る。従って、現在の命令が処理（及び、例えば受信した、受信は処理を含む）される前に、それより前のアプリケーションによって受信された命令は完了し、応答されることが出来る。方法１１００は、先のプロセスが完了され得るまで、引き続く命令や要求などをバッファリングすることで、同期環境におけるラウンドトリップ通信を容易にするメカニズムを提供する。
【００９３】
図１２は、モバイルアプリケーション間の安全な通信において再度イニシエイトされたハンドシェイクを受信する、一例となる手順１２００を例示する。１２０２において、通信の関係者を特定する（及び、例えば引き続くラウンドトリップ通信を特定出来る）少なくとも１つのランダムな番号を含む、安全なモバイルアプリケーションのハンドシェイクが、本明細書で述べたように、確立されることが出来る。更に、このハンドシェイクはまた、プライマリアプリケーションのユニークなＩＤを含むことが出来、それは、そのようなアプリケーションを信頼されたエンティティとして確認出来る。１２０４において、新たなランダムな番号及びユニークなＩＤまたは新たなユニークなＩＤを含むハンドシェイクの再イニシエーションが、受信され得る。１２０６において、新たなランダムな番号が確認されるまで、この新たなランダムな番号は、一時的なバッファに保持されることが出来る。そのような確認は、ハンドシェイクの再イニシエーションを受信したアプリケーションによって、または新たなランダムな番号を含む、正常に送信されたデータについての受信応答（ＡＣＫ）を受信することによって認められたデータを受信することを含むことが出来る。従って、ハンドシェイクの再イニシエーションを受信したアプリケーションは、悪意のあるソースからの正規なデータ、または悪意のあるソース及び／または認証されていないソースからの認証されていないデータをフィルタすることを試みることが出来る。
【００９４】
１２０８において、本明細書で述べられたように、新たなユニークなＩＤが確認されることが出来る。例えば、この新たなユニークなＩＤは、信頼されたプライマリアプリケーションのユニークなＩＤのリストに関するリファレンスであり得る。もし一致が見られなければ、この新たなユニークなＩＤは、認証されていないアプリケーションに関連付けられているとみなされ得る。１２１０において、上記したように、新たなＩＤが確認されたかにつき判断がなされる。もし確認されなければ、方法１２００は１２１４に進み、新たなランダムな番号は削除され、ハンドシェイクの応答は送信されない。もし新たなユニークなＩＤが確認されれば、方法１２００は１２１２に進み、ランダムな番号は、アプリケーション間の引き続く通信を特定するために新たなランダムな番号に置き換えられ得る。説明したように、方法１２００は、新たなランダムな番号及びユニークなＩＤを保持する前に、ハンドシェイクが確認され、これにより先のランダムな番号及び／またはユニークなＩＤが解放（release）され及び／または消去されるメカニズムを提供する。その結果、ランダムな番号を虚偽のランダムな番号に置き換えることにより安全な通信への侵入を試みるなりすまし攻撃を、抑制することが出来る。
【００９５】
図１３は、主題となる開示の側面に従った、ハンドシェイクを終了するための例となる手順１３００のフローチャートを与える。１３０２において、方法１３００は、少なくとも第１のランダムな番号及び／またはイニシエイトしているアプリケーションのユニークなＩＤを含む、安全なモバイルアプリケーションのハンドシェイクを確立出来る。この第１のランダムな番号は、イニシエイトしているアプリケーションによって受信されたハンドシェイクＡＣＫが、ハンドシェイクのターゲットからのものであることを確認出来る。更に、このユニークなＩＤは、このターゲットに対し、イニシエイトしているアプリケーションにはそのようなターゲットに対してハンドシェイクを送信する権限を与えられていることを、示すことが出来る。
【００９６】
１３０４において、少なくとも第１のランダムな番号及び／または第２のランダムな番号を含むハンドシェイクＡＣＫが受信されることが出来る。この第１のランダムな番号は、それが送られた際と同様の形態、または暗号化された形態、またはハッシュされた形態等で受信されることが出来る。受信した第１の番号（またはその適切なハッシュまたは暗号化されたバージョン）と第１のランダムな番号との比較により、ＡＣＫが正規であることを確認出来る。もしＡＣＫが正規でなければ、ハンドシェイクの再イニシエーションが送信され、及び／または本明細書で述べたように通信は終了され得る。
【００９７】
１３０６において、少なくともユニークなＩＤと第２のランダムな番号のバージョンとを含む終了（termination）イベントがイニシエイトされ得る。このバージョンは、例えば第２のランダムな番号のインクリメントであり得る。このバージョンは、そのような番号のハッシュまたは暗号化された形態などであっても良い。１３０８において、終了イベントのＡＣＫについての往復時間（return trip time）を規定するために、ＡＣＫタイマがセットされ得る。このＡＣＫタイマは、例えば安全なモバイルアプリケーションのハンドシェイク及びハンドシェイクＡＣＫに関連付けられたラウンドトリップ時間に基づくことが出来る。１３１０において、終了（termination）ＡＣＫが受信される。この終了ＡＣＫは、少なくとも第２のランダムな番号またはその適切なバージョン、またはターゲットアプリケーションのアプリケーションＩＤ、またはその両方を含み得る。
【００９８】
１３１２において、ＡＣＫタイマが満足されたにより判断がなされる。具体的には、ＡＣＫタイマによりセットされた期間内に、終了ＡＣＫが受信されたか否かである。もしそうでなければ、方法１３００は１３１４に進み、ハンドシェイクは終了（exit）し、そして例えば参照符号１３０２において説明されたように行われたような正常なハンドシェイクまで、更なる通信は無視される。ハンドシェイクの終了は、ハンドシェイクについてのデータイベントの送信をやめること、ハンドシェイクの下で生成された全てのランダムな番号をゼロにすること、及び／またはハンドシェイクにおいて含まれるアプリケーションに付随する固有のデータを解放（release）すること、を含むことが出来る。
【００９９】
もし、参照符号１３１２においてこのタイマが満足されれば、方法１３００は１３１６に進み、終了イベント（termination event）は継続する。１３１８において、参照符号１３１０において終了ＡＣＫと共に受信された第２のランダムな番号のバージョンが正しく繰り返されたか、インクリメントされたか、ハッシュまたは暗号化されたか、またはそれらの適切な組み合わせによって、判断がなされる。もし、終了ＡＣＫと共に受信された第２のランダムな番号が適切であれば、方法１３００は１３２０に進み、ＡＣＫタイマはキャンセルされ、ハンドシェイクの終了が完了する。ハンドシェイクの終了の完了は、ハンドシェイクのために生成された番号を消去すること、及びハンドシェイクにおいて含まれるアプリケーションに付随するデータを解放すること、を含むことが出来る。もし、参照符号１３１８において第２のランダムな番号が適切でないと判断されれば、方法１３００は代わりに１３２２に進み、参照符号１３１４で説明されたように、ハンドシェイクは終了（exit）することが出来る。
【０１００】
図１４及び１５は、請求された構成要件の詳細な側面に従った、見本となるシステム１４００、１４００のブロック図を与える。具体的には、システム１４００は、モバイル動作環境における安全なアプリケーション間通信をイニシエイトし加わることを提供出来る。例えばシステム１４００は、ハンドシェイクをイニシエイトするモジュール１４０２を含み得る。具体的には、モジュール１４０２は、プライマリモバイルアプリケーションのユニークな識別子と、ハンドシェイクのために生成されたランダムな番号とを含むハンドシェイクを、モバイルアプリケーションとの間でイニシエイトすることが出来る。更にシステム１４００は、応答を受信するモジュール１４０４を含むことが出来る。モジュール１４０４は、具体的にはモジュール１４０２によってイニシエイトされたハンドシェイクに対する応答を受信出来、この応答は第１の番号と第２の番号とを含む。第２の番号は、例えばモバイルアプリケーション（決定されたハンドシェイクのターゲット）によってランダムに生成されることが出来、そしてプライマリアプリケーションからこのモバイルアプリケーションに送信された要求に署名する及び／または要求を認証するために使用されることが出来る。
【０１０１】
上記に加えシステム１４００は、データを確認するモジュール１４０６を含むことが出来る。モジュール１４０６は、ハンドシェイクの応答の一部として受信した第１の番号が、ハンドシェイクのために生成されたランダムな番号（または、例えばそのハッシュ及び／または切り捨てられたバージョン、またはそのインクリメント、またはその両方）であるかを確認出来る。更に、データイベントを送信するモジュール１４０８が含まれる。モジュール１４０８は、もしモジュール１４０６によって第１の番号がランダムな番号と確認されれば、第２のランダムな番号（例えばモバイルアプリケーションによって生成される）を含むモバイルアプリケーションにデータイベントを送信し、イニシエイト出来る。更にシステム１４００はまた、第２のデータイベントを遅延させるモジュール１４１０を含むことが出来る。モジュール１４１０は、少なくとも第２のランダムな番号のインクリメントを含む、少なくともデータイベントの応答がモバイルアプリケーションから受信されるまで、システム１４００による第２のデータイベントの処理及び／または送信を遅延させることが出来る。その結果、システム１４００は、アプリケーション間のデータ要求を確認し及び／または認証するためにランダムに生成された番号を少なくとも組み込む、安全な通信環境における、ラウンドトリップ同期通信ポリシーを実行出来る。
【０１０２】
上記に加えてシステム１５００は、ハンドシェイクの要求を受信するモジュール１５０２を含むことが出来る。詳しくは、モジュール１５０２は、少なくともプライマリアプリケーションのユニークなＩＤ、またはプライマリアプリケーションによって生成されたランダムな番号、またはその両方を含むハンドシェイクの要求を、プライマリアプリケーションから受信出来る。更にシステム１５００は、信頼されたプライマリアプリケーション識別子のリストに対し、もしそうなら、受信したユニークなＩＤを照会出来る、ＩＤを照会するモジュール１５０４を含むことが出来る。そのような照会は、信頼されたアプリケーションを、認証されていない、または信頼されていないアプリケーションと区別するために使用されることが出来る。更にシステム１５００は、ハンドシェイクの応答を送信するモジュール１５０６を含むことが出来る。モジュール１５０６は、モジュール１５０４によって判断されるように、もしユニークなＩＤが、信頼されたプライマリアプリケーションのリストのユニークなＩＤと一致すれば、プライマリアプリケーションにハンドシェイクの応答を送信出来る。上記に加えてシステム１５００はまた、データイベントの要求を受信するモジュール１５０８と、そのような要求の受信（例えば受信は、本明細書で述べられたように、処理タイマをセットすること及び／またはバッファリングすることの他に、受信したデータについてのある種のデータ処理を含むことが出来る）を遅延させるモジュールとを含むことが出来る。より具体的には、モジュール１５１０は、更なるデータの要求を、データイベントの要求に対する応答がシステム１５００によってイニシエイトされるまで、遅延させることが出来る。従って、ラウンドトリップポリシーが実施されることができ、またこれにより、モバイルアプリケーション間でのデータ転送におけるハンドシェイクイベントの再イニシエーション及び／またはロストした要求の再送信を可能とする。その結果、（データはロストされていないか、または１つまたはそれ以上のパケットロスによりデータが使い物にならない）パケットロス環境における同期通信において、効率的なデータ転送アーキテクチャが提供されることが出来る。
【０１０３】
上記説明されたことは、１つまたはそれ以上の側面を含む。言うまでもなく、上記の側面を説明するための目的で、要素または手順の全ての考え得る組み合わせを説明することは可能では無く、しかし当業者は、種々の側面の、多くの更なる組み合わせ及び置換が可能であることを認識出来るだろう。従って、説明された側面は、添付の請求の範囲内に含まれる全てのそのような修正、変形、及び変化を包含することを意図している。更に、実施の形態または請求項のいずれかにおいて、用語「含む」が使用される限りでは、当該用語は、請求項における移行部の用語（transitional word）として使用される際の「備える（comprising）」の解釈のされ方と同様に包括的であることを意図している。
【図１】
2010511965.tif 000003
【図２】
2010511965.tif 000004
【図３】
2010511965.tif 000005
【図４】
2010511965.tif 000006
【図５】
2010511965.tif 000007
【図６】
2010511965.tif 000008
【図７】
2010511965.tif 000009
【図８】
2010511965.tif 000010
【図９】
2010511965.tif 000011
【図１０】
2010511965.tif 000012
【図１１】
2010511965.tif 000013
【図１２】
2010511965.tif 000014
【図１３】
2010511965.tif 000015
【図１４】
2010511965.tif 000016
【図１５】
2010511965.tif 000017
【国際調査報告】
2010511965.tif 000018
2010511965.tif 000019
2010511965.tif 000020