(57)【要約】  一般に、本開示は、クライアントが低電力状態にあるとき、クライアントプラットフォームとリモートリソースとの間の接続を維持することによって、クライアントプラットフォームにおけるエネルギーを節約するための方法及びシステムについて説明する。一例となる方法は、プラットフォームが低電力状態に遷移しているという通知を受信するステップと、プラットフォームが低電力状態にある間にリモートリソースとの接続を維持するよう構成される少なくとも１つのペイロードをプラットフォームから受信するステップと、少なくとも１つのペイロードを含むパケットを送信するステップと、アクノリッジメントを含むパケットを受信するステップとを有する。
2015505110.tif 000002
【特許請求の範囲】
【請求項１】
プラットフォームが低電力状態にある間、パケットを送受信するよう構成される通信回路と、
１以上のプロセッサにより実行されると、
前記プラットフォームが前記低電力状態に遷移しているという通知を受信するステップと、
前記プラットフォームが前記低電力状態にある間にリモートリソースとの接続を維持するよう構成される少なくとも１つのペイロードを前記プラットフォームから受信するステップと、
前記少なくとも１つのペイロードを含むパケットを送信するステップと、
アクノリッジメントを含むパケットを受信するステップと、
を実行させる命令を個別に又は組み合わせて格納した１以上の記憶媒体と、
を有するシステム。
【請求項２】
前記少なくとも１つのペイロードは、前記プラットフォームと前記リモートリソースとの間で確定されたキーに基づき暗号化される、請求項１記載のシステム。
【請求項３】
前記命令は、１以上のプロセッサにより実行されると、前記アクノリッジメントを含むパケットが受信されるまで、又は再送リミットに到達するまで、前記少なくとも１つのペイロードを含むパケットを再送するステップを更に実行させる、請求項１記載のシステム。
【請求項４】
前記命令は、１以上のプロセッサにより実行されると、前記再送リミットに到達したことに基づき、前記プラットフォームに前記低電力状態からアクティブ電力状態に遷移させるステップを更に実行させる、請求項３記載のシステム。
【請求項５】
前記少なくとも１つのペイロードは、複数のペイロードを有し、前記少なくとも１つのペイロードを含むパケットを送信するステップは、各パケットが前記複数のペイロードの１つを含むパケットを送信することを含む、請求項１記載のシステム。
【請求項６】
前記命令は、１以上のプロセッサにより実行されると、各パケットが前記複数のペイロードの１つを含む前記パケットの全てを送信したことに基づき、前記プラットフォームを前記低電力状態からアクティブ電力状態に遷移させるステップを更に実行させる、請求項５記載のシステム。
【請求項７】
前記命令は、１以上のプロセッサにより実行されると、前記リモートリソースから受信されたパケットに基づき、前記プラットフォームを前記低電力状態からアクティブ電力状態に遷移させるステップを更に実行させる、請求項１記載のシステム。
【請求項８】
１以上のプロセッサにより実行されると、
プラットフォームが低電力状態に遷移しているという通知を受信するステップと、
前記プラットフォームが前記低電力状態にある間にリモートリソースとの接続を維持するよう構成される少なくとも１つのペイロードを前記プラットフォームから受信するステップと、
前記少なくとも１つのペイロードを含むパケットを送信するステップと、
アクノリッジメントを含むパケットを受信するステップと、
を実行させる命令を個別に又は組み合わせて格納した１以上の記憶媒体を有するシステム。
【請求項９】
前記少なくとも１つのペイロードは、前記プラットフォームと前記リモートリソースとの間で確定されたキーに基づき暗号化される、請求項８記載のシステム。
【請求項１０】
前記命令は、１以上のプロセッサにより実行されると、前記アクノリッジメントを含むパケットが受信されるまで、又は再送リミットに到達するまで、前記少なくとも１つのペイロードを含むパケットを再送するステップを更に実行させる、請求項８記載のシステム。
【請求項１１】
前記命令は、１以上のプロセッサにより実行されると、前記再送リミットに到達したことに基づき、前記プラットフォームに前記低電力状態からアクティブ電力状態に遷移させるステップを更に実行させる、請求項１０記載のシステム。
【請求項１２】
前記少なくとも１つのペイロードは、複数のペイロードを有し、前記少なくとも１つのペイロードを含むパケットを送信するステップは、各パケットが前記複数のペイロードの１つを含むパケットを送信することを含む、請求項８記載のシステム。
【請求項１３】
前記命令は、１以上のプロセッサにより実行されると、各パケットが前記複数のペイロードの１つを含む前記パケットの全てを送信したことに基づき、前記プラットフォームを前記低電力状態からアクティブ電力状態に遷移させるステップを更に実行させる、請求項１２記載のシステム。
【請求項１４】
前記命令は、１以上のプロセッサにより実行されると、前記リモートリソースから受信されたパケットに基づき、前記プラットフォームを前記低電力状態からアクティブ電力状態に遷移させるステップを更に実行させる、請求項８記載のシステム。
【請求項１５】
プラットフォームが低電力状態に遷移しているという通知を受信するステップと、
前記プラットフォームが前記低電力状態にある間にリモートリソースとの接続を維持するよう構成される少なくとも１つのペイロードを前記プラットフォームから受信するステップと、
前記少なくとも１つのペイロードを含むパケットを送信するステップと、
アクノリッジメントを含むパケットを受信するステップと、
を有する方法。
【請求項１６】
前記アクノリッジメントを含むパケットが受信されるまで、又は再送リミットに到達するまで、前記少なくとも１つのペイロードを含むパケットを再送するステップを更に有する、請求項１５記載の方法。
【請求項１７】
前記再送リミットに到達したことに基づき、前記プラットフォームに前記低電力状態からアクティブ電力状態に遷移させるステップを更に有する、請求項１６記載の方法。
【請求項１８】
前記少なくとも１つのペイロードは、複数のペイロードを有し、前記少なくとも１つのペイロードを含むパケットを送信するステップは、各パケットが前記複数のペイロードの１つを含むパケットを送信することを含む、請求項１５記載の方法。
【請求項１９】
各パケットが前記複数のペイロードの１つを含む前記パケットの全てを送信したことに基づき、前記プラットフォームを前記低電力状態からアクティブ電力状態に遷移させるステップを更に有する、請求項１８記載の方法。
【請求項２０】
前記リモートリソースから受信されたパケットに基づき、前記プラットフォームを前記低電力状態からアクティブ電力状態に遷移させるステップを更に有する、請求項１５記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、参照することによりその開示の全てがここに援用される、２０１１年７月１日に出願された米国特許出願第１３／１７５，７５７号（整理番号Ｐ３７２１３）、これに関連する２０１１年７月１日に出願された米国特許出願第１３／１７５，７７８号（整理番号Ｐ３７２１４）及びこれに関連する２０１１年１２月３０日に出願された米国特許出願第１３／３４１，０６４号（整理番号Ｐ３７２１３Ｃ）に関連する。
【０００２】
本開示は、無線及び／又は有線通信に関し、より詳細にはクライアントプラットフォームが低電力状態にある間に提供されるエネルギー効率的な通信に関する。
【背景技術】
【０００３】
電力消費を低減するため（及びバッテリ寿命を延長するため）、ポータブル無線装置（限定することなく、ラップトップ、ネットブック、タブレットコンピュータなど）は、アクティブ電力状態（例えば、ＡＣＰＩ（Ａｄｖａｎｃｅｄ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ  ａｎｄ  Ｐｏｗｅｒ  Ｉｎｔｅｒｆａｃｅ）規格によるＳ０状態など）と低電力状態（スタンバイモード、）スリープモード、サスペンドモードなどとしても知られる）との間で切り替えを行うかもしれない。低電力状態（ＡＣＰＩ規格によるＳ３モードとしても知られる）にスイッチすると、電力消費は、プラットフォーム及びデバイスの全ての不要な部分に対する電力を低減及び／又は排除することによって低減される。多くの状況において、プラットフォーム又はエンドユーザに常時到達できるように、ポータブル無線装置上で実行される１以上のアプリケーション／サービスが接続及びプレゼンスを維持することが望ましい。
【０００４】
アプリケーションサーバとの接続及びプレゼンスを維持するための１つのアプローチは、プラットフォームがプレゼンスデータをアプリケーションサーバに送信し、及び／又は他の何れかのデータを受信できるように、プラットフォームをスタンバイモードからアクティブモードに定期的に遷移させることに関する。残念ながら、このアプローチは、プラットフォーム全体がスタンバイモードとアクティブモードとの間で切り替えられるとき、かなりのエネルギー量を必要とする。さらに、スタンバイモードとアクティブモードとの間の定期的な切り替えは、スタンバイからアクティブへの遷移の信頼性に対してネガティブな影響を有する可能性がある。Ｗａｋｅ  ｏｎ  Ｗｉｒｅｌｅｓｓ  ＬＡＮ（ＷｏＷＬＡＮ）などの技術は低電力消費を有する一方、ＷｏＷＬＡＮは、ローカルアクセスポイントとのデータリンク（Ｌ２リンクレイヤ）接続しか維持しない。また、ＷｏＷＬＡＮは、アプリケーションサーバとの接続及びプレゼンスを維持できない。
【図面の簡単な説明】
【０００５】
請求される主題の実施例の特徴及び効果は、以下の詳細な接続が進むに従って、同様の数字が同様のパーツを示す図面を参照して明らかになるであろう。
【図１】図１は、本開示によるクライアントプラットフォームとリモートアプリケーションサーバとの間の通信システムの一実施例を示す。
【図２】図２は、本開示によるクライアントプラットフォームの一実施例を示す。
【図３】図３は、本開示によるメモリに格納されるキープアライブメッセージのリストの一実施例を示す。
【図４】図４は、本開示によるキープアライブメッセージパケットの一実施例を示す。
【図５】図５は、各種状態により動作するホストシステムの平均的な電力消費を示す電力プロファイル図を示す。
【図６】図６は、本開示による処理のフローチャートの一実施例を示す。
【図７】図７は、各種スタックレイヤの一実施例を示す。
【図８】図８は、少なくとも１つの実施例による接続を維持するのに利用可能な一例となるメッセージ交換を示す。
【図９】図９は、少なくとも１つの実施例による接続を維持するための一例となる処理のフローチャートを示す。  以下の詳細な説明が例示的な実施例を参照して進めれるが、これの多数の多数の代替、改良及び変形が当業者に明らかになるであろう。従って、請求される主題は広くみなされ、添付した請求項に提供されるものによってのみ規定されることが意図される。
【発明を実施するための形態】
【０００６】
全体的に、本開示は、プラットフォーム及びアプリケーション／サービス（Ａｌｗａｙｓ−Ｏｎ−Ａｌｗａｙｓ−Ｃｏｎｎｅｃｔｅｄ（ＡＯＡＣ）アプリケーションなど）が、低電力状態にある及び留まる間、ネットワーク及びリモートアプリケーションサーバとの接続及びプレゼンスを維持することを可能にするエネルギー効率的な無線又は有線通信アプローチについて説明する。ここで説明される少なくとも１つの実施例では、ネットワーク及びリモートアプリケーションサーバとの接続及びプレゼンスを維持することを所望するＡＯＡＣアプリケーション／サービスが、電力消費を低減するため（例えば、バッテリ寿命を節約するためなど）、（アクティブ電力状態などから）低電力状態にプラットフォームが遷移する前、キープアライブメッセージのリストの構築を開始する。キープアライブメッセージ（各自のアプリケーション／サーバ専用プロトコル、シーケンスナンバー、タイミング情報及び／又はアプリケーション／サービスキー又はトークンを含むものであってもよい）は、プラットフォームが低電力状態に遷移した後、プラットフォームの通信装置（例えば、無線若しくは有線ＮＩＣ（Ｎｅｔｗｏｒｋ  Ｉｎｔｅｒｆａｃｅ  Ｃｉｒｃｕｉｔｒｙ）及び／又は一体化された無線／有線コントローラなど）により定期的に送信される。プラットフォームの通信装置が、プラットフォームが低電力状態にある間、キープアライブメッセージを発信することが可能であるとき、ネットワーク及び／又はリモートアプリケーションサーバとの接続及びプレゼンスは、エネルギー効率的に維持される。
【０００７】
ここで用いられる“アクティブ電力状態”という用語は、プラットフォームがワーキング又はフル動作状態で機能することを意味する。アクティブ電力状態の具体例は、ＡＣＰＩ（Ａｄｖａｎｃｅｄ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ  ａｎｄ  Ｐｏｗｅｒ  Ｉｎｔｅｒｆａｃｅ）規格により規定されるようなＳ０状態を含む。他の具体例は、限定することなく、フルオン電力状態を含む。ここで用いられる“低電力状態”という用語は、デバイスがオンに維持される必要があることを示さないデバイスへの電力がダウンされ、１以上のＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）が命令の実行を停止する（電力ダウンされるなど）低減された電力状態においてプラットフォームが機能することを意味する。低電力状態の具体例は、ＡＣＰＩ規格により規定されるようなＳ１，Ｓ２，Ｓ３及び／又はＳ４状態を含む。低電力状態の更なる具体例はまた、スタンバイモード、スリープモード、サスペンドモードなどとしても知られる。
【０００８】
一実施例では、プラットフォームが低電力状態にあるとき、ＮＩＣがメッセージ（パケットなど）を少なくとも１つのリモートアプリケーションサーバに送信することによって、プラットフォームにおいてエネルギーを節約している間、リモートリソース（少なくとも１つのリモートアプリケーションサーバなど）との接続が維持されてもよい。例えば、プラットフォームとリモートアプリケーションサーバとの双方にあるＡＯＡＣアプリケーション／サービスは、デバイス間の共有プライベートキーを確定するため、やりとり（キーの交換など）をしてもよい。共有プライベートキーは、プラットフォームが低電力状態にあるとき、ＮＩＣによる送信用のペイロードを暗号化する際に利用されてもよい。例えば、プラットフォーム上のＡＯＡＣアプリケーション／サービスは、暗号化されたペイロードを生成し、プラットフォームが低電力状態に遷移すると、ＮＩＣにアクセス可能なメモリに転送してもよい。リモートアプリケーションサーバ（ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）接続など）とのネットワーク接続の開始後、ＮＩＣは、設定されたインターバルにより“キープアライブ”パケットを送信するよう構成されてもよく、各パケットは暗号化されたペイロードを有する。その後、ペイロードがリモートアプリケーションサーバにより受理可能であると判断された場合、アクノリッジメントがＮＩＣにより受信されてもよい。アクノリッジメントパケットを受信すると、ＮＩＣは、次のペイロードを含むパケットを送信する。ペイロードの送信と、その後のアクノリッジメントの受信とは、メモリの全てのペイロードが送信されるまで続けられる。その後、ＮＩＣは、プラットフォームに通常のプラットフォーム動作に復帰し、ＡＯＡＣ処理のためのさらなるペイロードを生成するため、低電力状態からアクティブ電力状態に遷移させる。
【０００９】
同一の又は他の実施例では、ＮＩＣがプラットフォームに低電力状態からアクティブ電力状態に遷移させるよう構成される他の状況がまた存在してもよい。例えば、ＮＩＣは、リモートアプリケーションサーバからアクノリッジメントが受信されるまで、又は再送リミットに到達するまで、ペイロードを含むパケットを再送し続けてもよい。再送リミットに到達したＮＩＣは、ＡＯＡＣ処理による問題があることを示し、ＮＩＣは、当該問題を処理するためプラットフォームに低電力状態からアクティブ電力状態に遷移させる。リモートアプリケーションサーバはまた、プラットフォームに低電力状態からアクティブ電力状態に遷移させてもよい。例えば、リモートアプリケーションサーバは、プラットフォームに送信する情報を有しているとき、メッセージをＮＩＣに送信するよう構成されてもよい。情報が送信のため保留中であることを示すパケットをリモートアプリケーションサーバから受信すると、ＮＩＣは、当該情報を受信するため、低電力状態からアクティブ電力状態に遷移させるようにしてもよい。
【００１０】
図１を参照して、通信システム１００の一実施例が全体表示される。通信システム１００は、ネットワーク１０４を介し１以上のリモートアプリケーションサーバ１０６との無線及び／又は有線通信リンクを確立するよう構成される１以上のクライアントプラットフォーム１０２を有する。クライアントプラットフォーム１０２は、デスクトップ、ラップトップ及び／又はモバイル計算デバイスを含むものであってもよい。モバイル計算デバイスの具体例は、限定することなく、スマートフォン（限定することなく、ＢｌａｃｋｂｅｒｒｙＴＭスマートフォン、ｉＰｈｏｎｅＴＭスマートフォン、ＡｎｄｒｏｉｄＴＭスマートフォンなど）、タブレットコンピュータ（限定することなく、ｉＰａｄＴＭタブレットコンピュータ、ＰＣベースタブレットコンピュータ及び／又はＩｎｔｅｌＴＭ  Ｃｏｒｐｏｒａｔｉｏｎにより提供される現在の又は将来的なタブレットコンピュータなど）、及びウルトラモバイルパーソナルコンピュータを含む。
【００１１】
クライアントプラットフォーム１０２は、クライアントプラットフォーム１０２とリモートアプリケーションサーバ１０６との間の通信経路／リンクにおいて、１以上のネットワークアクセスポイント／ブリッジ１０８及び／又は他の通信デバイス１１０（ＮＡＴ（Ｎｅｔｗｏｒｋ  Ａｄｄｒｅｓｓ  Ｔｒａｎｓｌａｔｉｏｎ）デバイスなど）との通信リンクを確立するよう構成される。例えば、クライアントプラットフォーム１０２は、信号を利用してＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、ＷＬＡＮ（Ｗｉｒｅｌｅｓｓ  ＬＡＮ）、ＭＡＮ（Ｍｅｔｒｏｐｏｌｉｔａｎ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、ＷＭＡＮ（Ｗｉｒｅｌｅｓｓ  ＭＡＮ）、ＷＡＮ（Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、ＷＷＡＮ（Ｗｉｒｅｌｅｓｓ  ＷＡＮ）などの無線ネットワーク、既存の次世代ｍｍＷａｖｅ（２００８年１１月２８日のＮＧｍＳ−Ｄ０２／ｒ０）、ＷＧＡ（Ｗｉｒｅｌｅｓｓ  Ｇｉｇａｂｉｔ  Ａｌｌｉａｎｃｅ）、ＩＥＥＥ８０２．１１，８０２．１１ａ，８０２．１１ｂ，８０２．１１ｅ，８０２．１１ｇ，８０２．１１ｈ，８０２．１１ｉ，８０２．１１ｎ，８０２．１１ａｃ，８０２．１６，８０２．１６ｄ、８０２．１６ｅ，８０２．１１ａｈ規格、上記規格の将来のバージョン、派生及び／又はＬＴＥ（Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）により動作するデバイス及び／又はネットワーク、ＰＡＮ（Ｐｅｒｓｏｎａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、ＷＰＡＮ（Ｗｉｒｅｌｅｓｓ  ＰＡＮ）、上記のＷＬＡＮ、ＰＡＮ及び／又はＷＰＡＮネットワークの一部であるユニット及び／又はデバイス、一方向及び／又は双方向無線通信システム、セルラ無線電話通信システム、セルラ電話、無線電話、ＰＣＳ（Ｐｅｒｓｏｎａｌ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｓｙｓｔｅｍ）デバイス、無線通信デバイスを搭載したＰＤＡデバイス、ＭＩＭＯ（Ｍｕｌｔｉｐｌｅ  Ｉｎｐｕｔ  Ｍｕｌｔｉｐｌｅ  Ｏｕｔｐｕｔ）送受信機又はデバイス、ＳＩＭＯ（Ｓｉｎｇｌｅ  Ｉｎｐｕｔ  Ｍｕｌｔｉｐｌｅ  Ｏｕｔｐｕｔ）送受信機又はデバイス、ＭＩＳＯ（Ｍｕｌｔｉｐｌｅ  Ｉｎｐｕｔ  Ｓｉｎｇｌｅ  Ｏｕｔｐｕｔ）送受信機又はデバイス、ＭＲＣ（Ｍａｘｉｍｕｍ  Ｒａｔｉｏ  Ｃｏｍｂｉｎｉｎｇ）送受信機又はデバイス、“スマートアンテナ”技術又はマルチアンテナ技術を有する送受信機又はデバイスなどにおいて通信することが可能である。
【００１２】
ある実施例は、無線周波数（ＲＦ）、赤外線（ＩＲ）、周波数分割多重（ＦＤＭ）、直交ＦＤＭ（ＯＦＤＭ）、ＯＦＤＭＡ、時分割多重（ＴＤＭ）、時分割多重アクセス（ＴＤＭＡ）、Ｅｘｔｅｎｄｅｄ  ＴＤＭＡ（Ｅ−ＴＤＭＡ）、ＧＰＲＳ（Ｇｅｎｅｒａｌ  Ｐａｃｋｅｔ  Ｒａｄｉｏ  Ｓｅｒｖｉｃｅ）、Ｅｘｔｅｎｄｅｄ  ＧＰＲＳ、符号分割多重アクセス（ＣＤＭＡ）、ワイドバンドＣＤＭＡ（ＷＣＤＭＡ（登録商標））、ＣＤＭＡ２０００、マルチキャリア変調（ＭＤＭ）、離散マルチトーン（ＤＭＴ）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、Ｚｉｇｂｅｅ（登録商標）などの無線通信信号及び／又はシステムの１以上のタイプに関して利用されてもよい。実施例は、他の各種装置、デバイス、システム及び／又はネットワークにおいて利用されてもよい。
【００１３】
図２を参照して、本開示によるクライアントプラットフォーム２００の一実施例が全体表示される。クライアントプラットフォーム２００は、ホストシステム２０２及びＮＩＣ２２０を有する。ホストシステム２０２は、ホストプロセッサ２０４、チップセット回路２０６及びシステムメモリ２０８を有する。ホストプロセッサ２０４は、１以上のプロセッサコアを有し、システムソフトウェア２１０を実行するよう構成される。システムソフトウェア２１０は、例えば、オペレーティングシステムコード２１２（ＯＳカーネルコードなど）及び無線及び／又は有線ドライバコード２１４（限定することなく、ＬＡＮなど）などを含むものであってもよい。ＬＡＮドライバコード２１４は、以下で詳細に説明されるように、ＮＩＣ２２０の処理を少なくとも部分的に制御するよう構成される。システムメモリ２０８は、ＮＩＣ２２０により送信又は受信される１以上のデータパケットを格納するよう構成されるＩ／Ｏメモリバッファ２１６を有してもよい。チップセット回路２０６は、一般にプロセッサ２０４、ＮＩＣ２２０及びシステムメモリ２０８との間の通信を制御する“ノースブリッジ”回路（図示せず）を有してもよい。また、チップセット回路２０６は、ホストシステム２０２とＮＩＣ２２０との間のＩ／Ｏ通信を制御するための回路（図示せず）を有してもよい。
【００１４】
ＮＩＣ２２０は、送信パス２２１Ａ及び受信パス２２１Ｂに論理的及び／又は物理的に分割されてもよい。ＮＩＣ２２０は、一般にイーサネット（登録商標）ＭＡＣ（Ｍｅｄｉａ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ）回路２２２及び物理インタフェース（ＰＨＹ）回路２２４を有してもよい。ＭＡＣ回路２２２は、ネットワーク制御情報及び誤り検出ハッシュ値と共に、デスティネーションアドレス及びソースアドレスを含むフレーム又はパケットに送信対象のデータを構成するよう構成される送信ＭＡＣ回路２２２Ａを有する。ＭＡＣ回路２２２はまた、受信したフレームからデータを削除し、当該データをシステムメモリ２０８に配置するよう構成される受信ＭＡＣ回路２２２Ｂを有する。ＰＨＹ回路２２４は、データパケットを符号化するよう構成される符号化回路２４０Ａと、データパケットを復号化するよう構成される復号化回路２４０Ｂとを有する。符号化回路２４０Ａ及び復号化回路２４０Ｂはまとめて、アナログ・デジタル及びデジタル・アナログ変換、データの符号化及び復号化、アナログ寄生キャンセレーション（クロストークキャンセレーションなど）、及び受信データの復元を実行するよう構成されるプロセッサ（デジタル信号プロセッサなど）として実現されてもよい。ＰＨＹ回路２２４はまた、１以上のデータパケットを送信するよう構成される送信（Ｔｘ）回路２２６と、１以上のデータパケットを受信するよう構成される受信（Ｒｘ）回路２２８とを有してもよい。Ｒｘ回路２２８は、データ受信のタイミングを調整するよう構成される位相同期ループ回路（図示せずＰＬＬ）を有してもよい。ＰＨＹ回路２２４は、無線により及び／又はメディアに依存したインタフェース（例えば、カテゴリ６（Ｃａｔ６）イーサネット（登録商標）ケーブルなどを含む）によりデータを送受信するためのイーサネット（登録商標）通信リンク２３０を確立するよう構成されてもよい。
【００１５】
送信ＭＡＣ回路２２２Ａは、制御可能なクロック入力２４２及び制御可能な電力入力２４４を有する。クロック入力２４２は、一般にＭＡＣ回路２２２Ａのクロック処理を制御するクロック信号を有してもよい。電力入力２４４は、一般にＭＡＣ回路２２２Ａの１以上のコンポーネントに電力を供給するための電力供給信号を有してもよい。同様に、受信ＭＡＣ回路２２２Ｂは、制御可能なクロック入力２４６及び制御可能な電力入力２４８を有する。クロック入力２４６は、一般にＭＡＣ回路２２２Ｂのクロック処理を制御するクロック信号を有してもよい。電力入力２４８は、一般にＭＡＣ回路２２２Ｂの１以上のコンポーネントに電力を供給するための電力供給信号を有してもよい。符号化回路２４０Ａは、制御可能なクロック入力２５４及び制御可能な電力入力２５６を有し、復号化回路２４０Ｂは、制御可能なクロック入力２５８及び制御可能な電力入力２６０を有してもよい。送信回路２２６は、制御可能なクロック入力２６２及び制御可能な電力入力２６４を有してもよい。一実施例では、送信パス２２１Ａ及び受信パス２２１Ｂのクロック処理は、独立に制御されてもよい。また、一実施例では、送信パス２２１Ａ及び受信パス２２１Ｂの電力は、独立に制御されてもよい。
【００１６】
ＮＩＣ２２０は、１以上のアクセスポイント／ブリッジ（図２には図示されない、ホストシステム２０２と同様のホストシステムに関連付けされるスイッチ、ブリッジ、ルータ及び／又は他のＮＩＣを有してもよい）を介しリモートアプリケーションサーバ１０６とコマンド及びデータをやりとりするよう構成されてもよい。リモートアプリケーションサーバ１０６は、クライアントプラットフォーム２００上で実行されるＡＯＡＣアプリケーションを維持するため、無線又は有線通信プロトコルを利用してＮＩＣ２２０と通信するよう構成される何れかのデバイスを有してもよい。
【００１７】
他の電力状態がまた可能であるが、クライアントプラットフォーム２００は、アクティブ電力状態と低電力状態とにより少なくとも動作するよう構成される。アクティブ電力状態では、ホストシステム２０２及びＮＩＣ２２０は、一般にフル機能である。クライアントプラットフォーム２００が低電力状態で動作しているとき、電力はホストシステム２０２にスイッチオフされ、ＮＩＣ２２０のみが機能し続ける。
【００１８】
第１電力状態（アクティブ電力状態又はアクティブ電力状態とここに説明される低電力状態との間の中間的又はセカンダリ電力状態など）から低電力状態にスイッチする前、クライアントプラットフォーム２００は、ネットワーク及びアプリケーションサーバとの接続及びプレゼンスを維持することを所望するホストシステム２０２上で実行される１以上のＡＯＡＣアプリケーション／サービス２７０（メモリ２８に格納されるアプリケーション２７０など）のためのキープアライブメッセージ２７２のリスト又はセットの構築を開始するよう構成される。例えば、ＡＯＡＣアプリケーション／サービス２７０は、例えば、ファンクションキーの起動又は限定することなく、所定のタイムアウト期間などの他の何れかの手段などによって、クライアントプラットフォーム２００が低電力状態に遷移する直前にキープアライブメッセージ２７２の構築を開始してもよい。キープアライブメッセージ２７２は、リモートアプリケーションサーバとの接続及びプレゼンスを維持するよう構成される。例えば、キープアライブメッセージ２７２は、Ｌ２接続（ＷｏＷＬＡＮなどをサポートするため）を維持するよう構成されてもよい。オフロードされたプロトコルはまた、プラットフォームＬ３（ＩＰ）アドレス（アドレスレゾリューションプロトコル（ＡＲＰ）、ダイナミックホストコンフィギュレーションプロトコル（ＤＨＣＰ）リース及びインターネットコントロールメッセージプロトコル（ＩＣＭＰ）など）を維持するよう構成されてもよい。
【００１９】
各キープアライブメッセージ２７２の具体的なフォーマットは、クライアントプラットフォーム２００とリモートアプリケーションサーバとの間で通信するのに利用される送信プロトコルと共に、具体的なＡＯＡＣアプリケーションに依存する。例えば、キープアライブメッセージ２７２は、各自のＡＯＡＣアプリケーション／サービス専用プロトコルに基づき生成され、適切なシーケンシング情報及びタイミング（必要な場合）を含み、アプリケーション／サービスキー／トークン（必要な場合）によりセキュア化されてもよい。
【００２０】
キープアライブメッセージ２７２のセット（又は少なくともその一部）は、メモリ２７４に格納されてもよい。メモリ２７４は、クライアントプラットフォーム２００が低電力状態にあるとき（及び維持する）間、ＮＩＣ２２０によりアクセス可能なクライアントプラットフォーム２００の何れかに配置されてもよい。例えば、メモリ２７４は、ＮＩＣ２２０の一部であってもよいが、これは単なる一例であり、キープアライブメッセージ２７２を格納するメモリ２７４は、クライアントプラットフォーム２００の何れかに配置されてもよい。
【００２１】
クライアントプラットフォーム２００が低電力状態に遷移すると、ＮＩＣ２２０は、キープアライブメッセージ２７２を含む少なくとも１つのデータパケットをリモートアプリケーションサーバ１０６に定期的に送信するよう構成されてもよい。例えば、一実施例によると、送信ＭＡＣ回路２２２Ａは、ホストシステム２０２上で実行されるデバイスドライバからＡＯＡＣコマンドを受信するよう構成される。ＡＯＡＣコマンドに応答して、送信ＭＡＣ回路２２２Ａ及び少なくともＴｘ回路２２６は、キープアライブメッセージ２７２を含むデータパケットをリモートアプリケーションサーバ１０６に定期的に送信するよう構成される。キープアライブメッセージ２７２は、ＮＩＣ２２０に関連する１以上のクロック信号／入力２４２，２４６，２５４，２５８及び／又は２６２に基づき定期的に送信されてもよい。キープアライブメッセージ２７２がＮＩＣ２２０により送信される頻度は、複数のＡＯＡＣアプリケーション２７０のそれぞれについて同一又は異なるものであってもよい。さらに、ＮＩＣ２２０がキープアライブメッセージ２７０を送信する頻度は、一定又は経時的に可変であってもよい。
【００２２】
例えば、クライアントプラットフォーム２００上に複数のＡＯＡＣアプリケーション２７０があるとき、クライアントプラットフォーム２００（限定することなく、ＮＩＣ２２０など）は、リモートサーバとの接続及びプレゼンスを維持するため、各ＡＯＡＣアプリケーション２７０に対して要求される最小時間又は頻度（Ｔａｐｐ）を決定してもよい。クライアントプラットフォーム２００は、その後、各最小時間Ｔａｐｐを比較し、ＡＯＡＣアプリケーション２７０の全てのうち最小のＴａｐｐ（すなわち、Ｔｍｉｎ）を決定してもよい。ＮＩＣ２２０は、その後、Ｔｍｉｎに基づきＡＯＡＣアプリケーション２７０の全てについてキープアライブメッセージ２７２を送信してもよい。全てのＡＯＡＣアプリケーション２７０についてＴｍｉｎに基づきキープアライブメッセージ２７２を送信することは更に、低電力状態中のクライアントプラットフォーム２００の電力消費を低減する。特に、ＮＩＣ２２０は、一般に送信しないときよりもパケットの送信中により多くの電力を消費する。また、全てのＡＯＡＣアプリケーション２７０についてＴｍｉｎに基づきキープアライブメッセージ２７２を送信することは更に、ＮＩＣ２２０が単一の期間中に複数のキープアライブメッセージ２７２を送信することを可能にし、これにより、ＮＩＣ２２０がパケットを送信するのに費やす時間を最小限にすることによって、クライアントプラットフォーム２００の電力消費を低減する。
【００２３】
メモリ２７４の全てのキープアライブメッセージ２７２がＮＩＣ２２０により送信されると、ＮＩＣ２２０は、メモリ２７４において更なるキープアライブメッセージ２７２を生成するため、クライアントプラットフォーム２００を低電力状態からアクティブ電力状態（又は低電力状態とアクティブ電力状態との間の中間電力状態）に遷移するよう構成されてもよい。メモリ２７４が更なるキープアライブメッセージ２７２により補充されると、クライアントプラットフォーム２００は低電力状態に戻り、ＮＩＣ２２０は、ここで説明されるようなキープアライブメッセージ２７２を周期的に送信することを再開してもよい。
【００２４】
他の実施例によると、クライアントプラットフォーム２００は、低電力状態にある間、接続及びプレゼンスを維持するのに必要なストレージを低減してもよい。特に、クライアントプラットフォーム２００は、所定の期間においてセキュリティトークンのリストによりジェネラルキープアライブメッセージを生成するよう構成されてもよい。ジェネラルキープアライブメッセージとセキュリティトークンのリストとは、その後、クライアントプラットフォーム２００が低電力状態に遷移する前にＮＩＣ２２０に転送されてもよい。さらに、各キープアライブメッセージに関する情報（プレゼンス／接続を維持するため最小限必要とされる周期性、キープアライブメッセージのデスティネーションアドレスなど）がまた、ＮＩＣ２２０に転送されてもよい。低電力状態に遷移すると、ＮＩＣ２２０は、ジェネラルキープアライブメッセージとセキュリティトークンのリストとを復元し、当該リストとシーケンシング情報（デスティネーションアドレスと共に）とによって予め生成されたジェネラルキープアライブメッセージを更新してもよい。その後、ＮＩＣ２２０は、各種攻撃に対して自らを守るためにセキュアな方法によりネットワークとのアプリケーション／サービスプレゼンスを維持するため、キープアライブメッセージ２７２を適切な時間間隔により送信してもよい。従って、必要とされるストレージ量は、ジェネラルキープアライブメッセージとセキュリティトークンのリストとが完全に予め生成されたキープアライブメッセージ２７２のリストより一般的にはるかに小さいため、低減されてもよい。例えば、それぞれが２００バイトの１０個の完全に予め生成されたキープアライブメッセージの格納は２０００バイトのストレージを必要とする一方、生成される各メッセージについて２００バイトのジェネラルキープアライブメッセージとセキュリティトークンのリストとを使用することは、例えば、４００バイト未満しか必要としない。
【００２５】
クライアントプラットフォーム２００（ＮＩＣ２２０など）はまた、ＷｏＷＬＡＮのために規定されたものより広範なウェイクパターンをサポートするよう構成されてもよい。例えば、ＮＩＣ２２０は、例えば、１以上のリモートアプリケーションサーバ上で実行されるアプリケーション／サービスなどの特定のインターネットベースアプリケーションなどから、入力されたインターネットパケットを受信すると、クライアントプラットフォーム２００の全て又は一部をウェイクアップするよう構成されてもよい。ウェイクパターンの具体例は、限定することなく、ＴＣＰ（Ｔｒａｎｓｐｏｒｔ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）  ＳＹＮメッセージ、ＨＴＴＰ又はＨＴＴＰＳメッセージ又は何れかのアプリケーション固有メッセージを含むものであってもよい。
【００２６】
ＮＩＣ２２０はまた、リモートアプリケーションサーバ１０６から少なくとも１つのデータパケットを任意的に受信するよう構成されてもよい。一実施例では、アクティブデータ送信電力状態から低電力状態に遷移するため、ＮＩＣ２２０は、クロック入力２４２，２５４及び／又は２６２を制御するよう構成されてもよい。例えば、ＮＩＣ２２０は、クロック入力２４６及び／又は２５８を制御するよう構成され、クロック入力２４２，２５４，２６２，２４６及び／又は２５８は、対応する回路へのクロック信号をオフにするためゲート処理されてもよい（クロックゲート処理）。
【００２７】
図３において、複数のＡＯＡＣアプリケーション３０２（１）〜（ｎ）についてメモリ２７４に格納されている複数のキープアライブメッセージのリスト３００を示す一実施例が全体表示される。例えば、ＡＯＡＣアプリケーション３０２（１）〜（ｎ）は、インスタントメッセージング（ＩＭ）アプリケーション３０２（１）（限定することなく、Ｍｉｃｒｏｓｏｆｔ  Ｉｎｓｔａｎｔ  ＭｅｓｓａｇｉｎｇＴＭ、ＡＯＬ  Ｉｎｓｔａｎｔ  ＭｅｓｓｅｎｇｅｒＴＭ、Ｍｏｂｉｌｅ  Ｉｎｓｔａｎｔ  Ｍｅｓｓａｇｉｎｇ（ＭＩＭ）など）、ソーシャルネットワーキングアプリケーション３０２（２）（限定することなく、ＦａｃｅｂｏｏｋＴＭ、ＴｗｉｔｔｅｒＴＭ、ＭｙＳｐａｃｅＴＭなど）及び／又は他の何れかのＡＯＡＣアプリケーション３０２（ｎ）を含むものであってもよい。各ＡＯＡＣアプリケーション３０２（１）〜（ｎ）は、各自のアプリケーション／サービス専用プロトコル、シーケンスナンバー、タイミング情報及び／又はアプリケーション／サービスキー若しくはトークンに基づき、複数の関連するキープアライブメッセージ３０４（１）〜（ｎ），３０６（１）〜（ｎ）及び３０８（１）〜（ｎ）を含むものであってもよい。図４において、本開示によるキープアライブパケット４００の一実施例が全体表示される。例えば、キープアライブパケット４００は、ＴＣＰ／ＩＰベースプロトコルに互換的なヘッダ４０２及びペイロード４０４を有してもよい。ヘッダ４０２は、デスティネーション及びソースＭＡＣアドレスを含むものであってもよい。ペイロード４０４は、全体表示されるように、インターネットプロトコルヘッダセグメント４０６、ＴＣＰセグメント４０８及びＴＣＰペイロードセグメント４１０を含むものであってもよい。
【００２８】
図５を参照して、各種モード（モード５０２，５０４及び５０６など）におけるクライアントプラットフォームの平均電力消費（Ｗ）の一例を示すチャート５００が提供される。理解できるように、クライアントプラットフォーム及びＮＩＣ（図２のＮＩＣ２２０など）は、ＷｉＦｉアクティブ（５０２）によりアクティブ電力状態（ＳＯ  Ｉｄｌｅなど）で動作中に約３．２５Ｗを消費し、ＷｉＦｉ無効（５０４）による低電力状態（Ｓ３など）で動作中に約０．４Ｗを消費する。理解されるように、Ｓ３状態（５０４）はＷｉＦｉを無効にしており、ネットワーク接続及び／又はプレゼンスを維持することができない。Ｓ３状態（５０４）は、プラットフォームが完全にシャットダウンされることなく、ＮＩＣ２２０が消費しうる最小電力を表すと考えられる。他方、本開示のＡＯＡＣメソッドを利用する低電力状態（Ｓ３など）で動作するＮＩＣ２２０は、約０．５Ｗ（５０６）しか消費しない。また、本開示のＡＯＡＣモード（５０６）のＮＩＣ２２０は、ネットワーク接続及びプレゼンスを依然として維持しながら、Ｓ３モード（５０４）より大きな約０．１Ｗしか消費しない。
【００２９】
図６を参照して、リモートアプリケーションサーバとの接続及びプレゼンスを確立及び／又は維持するための処理のフローチャート６００を示す一実施例が提供される。例えば、クライアントプラットフォーム上で実行される１以上のＡＯＡＣアプリケーションは、リモートアプリケーションサーバに接続される（処理６０２）。クライアントプラットフォームは、第１電力状態（アクティブ電力状態など）で動作している。その後、クライアントプラットフォームは、第１電力状態から低電力状態に遷移するための通知を受信する（処理６０４）。当該通知は、ユーザにより生成されてもよく（例えば、ラップトップのふたを閉じる、又は低電力状態機能を起動するなど）、及び／又は自動的であってもよい（例えば、クライアントプラットフォームは、所定の非アクティブ期間後に低電力状態に自動的に遷移してもよい）。低電力状態に遷移する前、クライアントプラットフォームは、キープアライブメッセージの生成を開始する（処理６０６）。キープアライブメッセージは、低電力状態に遷移するための通知前又は通知後に生成されてもよい。ここで説明されるように、キープアライブメッセージ全体が生成されてもよいし（完全に予め生成されたキープアライブメッセージなど）、あるいはキープアライブメッセージの一部が生成されてもよい（ジェネラルキープアライブメッセージ及びセキュリティトークンのリストなど）。キープアライブメッセージ（又はその一部）は、クライアントプラットフォームが低電力状態にある間、ＮＩＣにアクセス可能なメモリに格納されてもよい（処理６０８）。任意的には、クライアントプラットフォームは、例えば、複数のＡＯＡＣアプリケーションがクライアントプラットフォーム上で実行されているときなど、キープアライブメッセージを送信するための頻度を決定する（処理６１０）。
【００３０】
その後、クライアントプラットフォームは、低電力状態に遷移する（処理６１２）。クライアントプラットフォームが低電力状態で動作すると、ＮＩＣは、キープアライブメッセージをリモートアプリケーションサーバに定期的に送信する（処理６１４）。ＮＩＣは、クライアントプラットフォームが低電力状態から遷移するまで、キープアライブメッセージを送信し続ける（例えば、ＮＩＣ又はユーザにより開始された遷移により受信されたパケットのためなど）。あるいは、ＮＩＣは、メモリに格納されているキープアライブメッセージの残数が最小閾値に達するまで、キープアライブメッセージを送信し続けてもよい。最小閾値に到達すると、クライアントプラットフォームは、低電力状態から第２電力状態に遷移する（処理６１６）。その後、クライアントプラットフォームは、追加的なキープアライブメッセージの生成を開始し、メモリに格納する（処理６１８）。第２電力状態は、クライアントプラットフォームが追加的なキープアライブメッセージを生成するのを可能にするのに十分な中間電力状態又はアクティブ電力状態であってもよい。最小閾値は、リモートアプリケーションサーバとの接続及びプレゼンスを依然として維持しながら、追加的なキープアライブメッセージを生成するのに十分な時間をクライアントプラットフォームに可能にするよう選択されてもよい。追加的なキープアライブメッセージが生成／格納された後、クライアントプラットフォームは、低電力状態に戻り（処理６１２）、ここで説明されるようなキープアライブメッセージの定期的な送信を再開する。
【００３１】
ここに説明されるように、図１のクライアントプラットフォーム１０２は、低電力状態にあるとき、適切なアドレス（アプリケーションサーバ１０６など）にキープアライブメッセージを定期的に送信することによって、ネットワーク１０４及び１以上のリモートアプリケーションサーバ１０６との接続及びプレゼンスを維持してもよい。ここで説明されるように、キープアライブメッセージは、各自のアプリケーション／サービス専用プロトコル、シーケンスナンバー、タイミング情報及び／又はアプリケーション／サービスキー若しくはトークンに基づき生成されてもよい。ここで説明されるプロトコル及び／又は規格に従って動作するため、キープアライブメッセージは、通信システムレイヤの一部を実現してもよい。図７は、ハイレベルにおけるキープアライブメッセージ７００とネットワークスタックの各種レイヤのそれの関連する頻度とを示す。例えば、本開示の少なくとも１つの実施例によるキープアライブメッセージ７００は、データ／リンクレイヤメッセージ（限定することなく、８０２．１１ＭＡＣレイヤ（すなわち、ＯＳＩデータ／リンクレイヤ２）など）と、アプリケーション／サービスレイヤメッセージ（限定することなく、ＯＳＩセッションレイヤ５、ＯＳＩプレゼンテーションレイヤ６及びＯＳＩアプリケーションレイヤ７など）を対象としてもよいが、本開示によるキープアライブメッセージはまた何れかレイヤにおけるメッセージに適用可能であることが理解されるべきである。
【００３２】
データ／リンクレイヤ２は、ネットワークエンティティ間でデータを転送し、物理レイヤにおいて発生するエラーを検出しておそらく訂正するための機能的及び手続的手段を提供する。セッションレイヤ５は、コンピュータ間のダイアログ（接続）を制御する。それは、ローカルアプリケーションとリモートアプリケーションとの間の接続を確立、管理及び終了する。それは、フルデュプレクス、ハーフデュプレクス又はシンプレクス処理を提供し、チェックポインティング、延期、終了及び再スタート手順を決定する。セッションレイヤは、クライアントプラットフォーム１０２が提供されたパラメータによって指定された手順を実行するためのリクエストメッセージを既知のリモートアプリケーションサーバ１０６に送信するリモート手続コールを利用するアプリケーション環境において明示的に通常は実現される。リモートアプリケーションサーバ１０６はレスポンスをクライアントプラットフォーム１０２に送信し、アプリケーションはそれのプロセスを継続する。プレゼンテーションレイヤ６は、プレゼンテーションサービスがエンティティ間のマッピングを提供する場合、上位レイヤエンティティが異なるシンタックス及びセマンティックを利用するアプリケーションレイヤエンティティ間でコンテクストを確定する。マッピングが利用可能である場合、プレゼンテーションサービスデータユニットは、セッションプロトコルデータユニットにカプセル化され、スタックにわたされる。プレゼンテーションレイヤ６は、アプリケーションフォーマットとネットワークフォーマットとの間で変換することによって、データ表現（暗号化など）からの独立性を提供する。アプリケーションレイヤ７は、通信コンポーネントを実現するソフトウェアアプリケーションとやりとりする。アプリケーションレイヤ７は、通信パートナーを特定し、リソース可用性を決定し、通信を同期することを含むものであってもよい。
【００３３】
ＮＩＣ２２０はまた、ＮＩＣ２２０とチップセット回路２０６との間のＩ／Ｏ通信を提供するためのＩ／Ｏリンク又はバス回路（図示せず）を有してもよい（このようなリンク又はバス回路は、上述したＰＣＩ−Ｅｘｐｒｅｓｓ通信プロトコルに準拠してもよい）。ＮＩＣはまた、ＭＡＣ回路２２０とＰＨＹ回路２２４との間のＩ／Ｏ通信を提供するよう構成されるＭＡＣ／ＰＨＹインタフェース回路（図示せず）を有してもよい（例えば、ＳＧＭＩＩ又はＸＡＵＩなどを含むものであってもよい）。
【００３４】
ＮＩＣ２２０に関連するメモリ２０８及び／又はメモリ２７４は、以下のタイプのメモリ、すなわち、半導体ファームウェアメモリ、プログラマブルメモリ、不揮発性メモリ、読み出し専用メモリ、電気的にプログラマブルなメモリ、ランダムアクセスメモリ、フラッシュメモリ、磁気ディスクメモリ及び／又は光ディスクメモリの１以上を有してもよい。さらに又はあるいは、ＮＩＣ２２０に関連するメモリ２０８及び／又はメモリ２７４は、他の及び／又は以降に開発されるタイプのコンピュータ可読メモリを有してもよい。ここに説明される方法の実施例は、当該方法を実行するようシステムをプログラムするための命令を有する記憶媒体に格納可能なコンピュータプログラムにより実現されてもよい。当該記憶媒体は、限定することなく、フロッピー（登録商標）ディスク、光ディスク、ＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ  Ｄｉｓｋ  Ｒｅａｄ−Ｏｎｌｙ  Ｍｅｍｏｒｙ）、ＣＤ−ＲＷ（Ｃｏｍｐａｃｔ  Ｄｉｓｋ  Ｒｅｗｒｉｔａｂｌｅ）、光磁気ディスクを含む何れかのタイプのディスク、ＲＯＭ、ダイナミック及びスタティックＲＡＭなどのＲＡＭ、ＥＰＲＯＭ（Ｅｒａｓａｂｌｅ  Ｐｒｏｇｒａｍｍａｂｌｅ  ＲＯＭ）、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ  ＥＰＲＯＭ）、フラッシュメモリなどの半導体デバイス、磁気若しくは光カード又は電子命令を格納するのに適した何れかのタイプの媒体を含むものであってもよい。他の実施例は、プログラマブル制御装置により実行されるソフトウェアモジュールとして実現されてもよい。
【００３５】
ここで説明される無線及び／又は有線通信プロトコル（限定することなく、イーサネット（登録商標）プロトコルなど）は、ＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）を用いて通信を許可することが可能である。無線及び／又は有線プロトコルは、２００２年３月に公開された“ＩＥＥＥ８０２．３規格”及び／又は当該規格の以降のバージョン（限定することなく、“ＩＥＥＥ８０２．１１規格”など）のタイトルによりＩＥＥＥ（Ｉｎｓｔｉｔｕｔｅ  ｏｆ  Ｅｌｅｃｔｒｉｃａｌ  ａｎｄ  Ｅｌｅｃｔｒｏｎｉｃｓ  Ｅｎｇｉｎｅｅｒｓ）により公開されたイーサネット（登録商標）規格に準拠又は互換的であってもよい。
【００３６】
ここで用いられる“ＰＨＹ”とは、１以上のデバイスとのインタフェースをとるのに用いられるオブジェクト及び／又は回路として定義され、当該オブジェクト及び／又は回路は、ここに提供される通信プロトコルの１以上により定義されてもよい。ＰＨＹは、適用可能な通信リンクとインタフェースをとるための送受信回路からなる物理的ＰＨＹを有する。ＰＨＹは、あるいは及び／又はさらに、他のバーチャルＰＨＹ又は物理的ＰＨＹとインタフェースをとるためのバーチャルＰＨＹを有してもよい。ＰＨＹ回路２２４は、上述したＩＥＥＥ８０２．３及び／又は８０２．１１通信プロトコル及び／又は以降に開発された通信プロトコルに準拠したＰＨＹ回路に準拠又は互換的であってもよい。
【００３７】
接続を維持するのに利用されるメッセージングの具体例
一実施例では、必須のサブシステムのみをアクティブ状態に維持し、その後、必要な際にプラットフォーム全体をフル活動させることによって、エネルギーがプラットフォーム動作中に節約されてもよい。例えば、ＡＯＡＣアプリケーションにより提供される機能が何れかの時点において情報を受信する能力に基づく一方、当該能力は、情報がコンスタントに受信されていることを意味するものでない。他方、入力される情報量は、少なく又は存在しないときもあるかもしれない（夜中、週末、休日など）。従って、エネルギー効率的にＡＯＡＣアプリケーションをサポートするのに重要になることは、情報プロバイダとの接続を維持することであり、この結果、情報が保留中である場合、プラットフォームにおける必要なシステムは当該情報を受信／処理するため起動される。当該接続を維持するため、メッセージ（パケットなど）が、クライアントプラットフォーム２００が低電力状態に遷移する際、ＮＩＣ２２０とリモートリソース（少なくとも１つのリモートアプリケーションサーバ１０６など）との間で交換されてもよい。当該メッセージは、リモートアプリケーションサーバ１０６上のＡＯＡＣアプリケーション／サービスとの接続を維持するため、“フロー”をアライブ状態に維持するトラフィックを生成する。メッセージトラフィックが停止するとき、ファイアウォール又はネットワークアドレス変換手段（ＮＡＴ）は、短いタイムアウト期間においてフローの状態のみを維持してもよい。フローに属する新たなパケットがタイムアウト期間内に検出されない場合、フロー状態は破棄される。その後、クライアントプラットフォーム２００は、サイクルをリセットし、リモートアプリケーションサーバ１０６との更なるインタラクションのための接続を再開することが要求されるであろう。
【００３８】
フローの破棄は、典型的には、リモートアプリケーションサーバ１０６との全ての接続を切断する。特に、リモートアプリケーションサーバ１０６がクライアントプラットフォーム２００に送信する情報を有していたとしても、リモートアプリケーションサーバ１０６が接続を開始することはできない。ファイアウォール又はＮＡＴの外部から開始される接続要求は、通常はブロックされるためである（例えば、ＤＯＳ（Ｄｅｎｉａｌ−Ｏｆ−Ｓｅｒｖｉｃｅ）攻撃を防ぐため）。従って、内部から外部に（例えば、クライアントプラットフォーム２００からリモートアプリケーションサーバ１０６になど）送信される“キープアライブ”メッセージの連続的なストリームは、当該フローとアプリケーション／サービスとの接続とを維持するのに役立つ。メッセージが送信される間隔は、アプリケーション（例えば、送信期間の具体例は、数十秒から数分までの範囲であってもよい）に依存して変化する。一実施例では、メッセージは、クライアントプラットフォーム２００が低電力状態に遷移した後にＮＩＣ２２０９により送信されるように、シンプルなものであってもよく、特別な手続及び／又は機能を実現する必要を回避するため既存の通信プロトコルに基づくものであるべきであり、また通信における整合性及び真正性を提供するためセキュアであるべきである（例えば、受信したメッセージのソースは、リモートアプリケーションサーバ１０６上のＤＯＳ攻撃及び／又はクライアントプラットフォーム２００に低電力状態からアクティブ状態に不要に遷移させることを回避するため検証可能であるべきであるべきである）。メッセージ送信は、ＮＩＣ２２０が処理できない状況が生じるまで継続されてもよい。例えば、ＮＩＣ２２０は、もはやメッセージを送信することができないか、問題が存在すると判断するか、又はリモートアプリケーションサーバ１０６がクライアントプラットフォーム２００のための情報を有していることを示すメッセージを受信した場合、クライアントプラットフォーム２００をアクティブ状態にさせるようにしてもよい。このように動作することによって、クライアントプラットフォーム２００は、必要な場合にのみフル活動し、クライアントプラットフォーム２００における電力消費が最小化されてもよい。
【００３９】
図８は、少なくとも１つの実施例による接続を維持するのに利用可能な一例となるメッセージ交換を示す。クライアントプラットフォーム２００’は、少なくともホストシステム２０２’及びＮＩＣ２２０’を有する。ホストシステム２０２’は、ＡＯＡＣアプリケーション／サービス２７０’が存在するシステムソフトウェア２１０’を有してもよい。ＮＩＣ２２０’は、ＭＡＣ回路２２０’及びメモリ２７４’を有する。クライアントプラットフォーム２００に関して図２に示されるものなどの更なる特徴がまた、クライアントプラットフォーム２００’に含まれてもよいが、簡単化のため図８から省略された。さらに、図８では、メモリ２７４’はＮＩＣ２２０’内に開示されているが、メモリ２７４’の配置は当該構成に限定されるものでない。開示される位置は、ホストシステム２０２’が低電力状態に入る場合であっても、メモリ２２０’がＮＩＣ２２０’にアクセス可能であることを単に表すためのものである。
【００４０】
図８において“１”とラベル付けされた双方向のインタラクションでは、ＡＯＡＣアプリケーション／サービス２７０’は、リモートアプリケーションサーバ１０６’上にあるＡＯＡＣアプリケーション／サービス８００とやりとりしてもよい。例えば、ＡＯＡＣアプリケーション／サービス２７０’は、ＡＯＡＣアプリケーション／サービス８００により登録されてもよい。登録は、例えば、ＡＯＡＣアプリケーション／サービス２７０’がクライアントプラットフォーム２００’に存在することをＡＯＡＣアプリケーション／サービス８００に警告し、ＡＯＡＣＶ処理に必要とされる何れかのコンフィギュレーション情報を更にやりとりすることなどを含むものであってもよい。一実施例では、コンフィギュレーション情報の交換は、クライアントプラットフォーム２００’及びリモートアプリケーションサーバ１０６の双方において共有プライベートキーを確定するため、キーの交換を含むものであってもよい。ＡＯＡＣアプリケーション／サービス２７０’は、共有プライベートキーを利用して、ペイロード系列（ペイロード１、ペイロード２、．．．、ペイロードｎなど）を暗号化してもよい。一実施例では、ペイロードは、図３に開示されるようなＡＯＡＣアプリケーション３０２（１）〜３０２（ｎ）からの情報を含むものであってもよい。さらに、暗号化はＡＯＡＣアプリケーション／サービス２７０’により生成されるペイロードシーケンスにおけるパケットの配置に基づくものであるため、同一又は類似の情報を含む暗号化されたペイロードは、同一でなくてもよい。
【００４１】
“２”に示されるように、暗号化されたペイロード１．．．ｎは、クライアントプラットフォーム２００’が低電力状態に遷移するとき、メモリ２７４’に転送されてもよい。例えば、クライアントプラットフォーム２００’が低電力状態に遷移していることを検出することは、ＡＯＡＣアプリケーション／サービス２７０’に暗号化されたペイロード１．．．ｎを、クライアントプラットフォーム２００’が低電力状態にある間にＮＩＣ２２０’が利用するファームウェアイメージにロードさせてもよい。ＮＩＣ２２０’は、その後、リモートアプリケーションサーバ１０６’との接続を維持するための処理を開始する。一実施例では、ＮＩＣ２２０’は、インターネットサーバのＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ（ｈｔｔｐ）ポート（ポート８０など）との新たなＴＣＰ接続を開始してもよい。ＴＣＰ接続の確立によると、“３方向ＴＣＰハンドシェイク”が、図８において“３”により示されるような接続を開始するため行われてもよい。例えば、クライアントプラットフォーム２００’は、ＳＹＮメッセージをリモートアプリケーションサーバ１０６’に送信することによって、アクティブオープンを実行してもよい。ＳＹＮメッセージは、セグメントシーケンスナンバーをランダム値（Ａなど）に設定する。リモートアプリケーションサーバ１０６’は、その後、ＳＹＮ−ＡＣＫメッセージによりリプライする。ＳＹＮ−ＡＣＫメッセージでは、アクノリッジメントナンバーは、受信したシーケンスナンバーより１だけ大きく設定され（Ａ＋１など）、サーバがパケットについて選択するシーケンスナンバーは、他のランダムナンバー（Ｂなど）に設定される。その後、クライアントプラットフォーム１００’は、ＡＣＫメッセージをサーバに送り返す。シーケンスナンバーは、受信したアクノリッジメント値（Ａ＋１）に設定され、アクノリッジメントナンバーは、受信したシーケンスナンバーより１だけ大きく設定される（Ｂ＋１）。その後、ＴＣＰ接続が確立される。既存のＴＣＰプロトコルを利用することによって、効果が実現される。特別な処理及び／又は機能は、ＴＣＰプロトコルがアプリケーションエリアにおいて広範なエコシステムのサポートを有し、ＡＯＡＣ機能の実現を異なるプラットフォーム間でより容易にするため、必要とされない。さらに、ＨＴＴＰ／ＴＣＰ接続が正当なインサイドアウト接続として認識されるため、ファイアウォール／ＮＡＴが当該接続をブロックする可能性は低い。
【００４２】
ＮＩＣ２２０’は、その後、図８において“４”により示されるように、“キープアライブ”パケットの送信を開始する。一実施例では、当該パケットは、ｈｔｔｐ  ＰＯＳＴメッセージとしてフォーマット化されてもよい。ｈｔｔｐ  ＰＯＳＴメッセージは、処理対象のデータ（ＨＴＭＬ形式などから）を特定されたリソース（リモートアプリケーションサーバ１０６’など）に送信するよう構成されてもよい。“４”において送信されたパケットのペイロードは、暗号化されたペイロード１である。パケットを受信した後、リモートアプリケーションサーバ８００（ＡＯＡＣアプリケーション／サービス８００におそらく関連して）は、パケットを解読する。パケットが正しいと判断された場合、ＡＣＫ（アクノリッジメント）パケットは、“５”に示されるように、ＮＩＣ２００’に送り返される。同様に、ペイロード２を含むパケットは、“６”に示されるように送信され、“７”において示されるように、アクノリッジメントが受信され、“８”に示されるように、ペイロードｎを含むパケットが送信され、“９”に示されるように、アクノリッジメントが受信される。
【００４３】
上述された一例となるメッセージ交換は、全ての送信されたパケットが受信成功したと仮定する。しかしながら、実際には、アクノリッジメントが受信されないインスタンスがあるかもしれない。例えば、クライアントプラットフォーム２００’は、ネットワークから退出してもよい（例えば、無線通信範囲外に移動した、配線接続から切断されたなどによりネットワーク接続を失う可能性がある）。一実施例では、ＮＩＣ２２０’は、１つのパケットのウィンドウを維持してもよい。１パケットのウィンドウは、完全なＴＣＰスタックオフロードがＴＣＰ輻輳ウィンドウのサイジング又はＴＣＰヘッダの任意的なフラグの何れかを処理するのに必要とされないという点で、ＮＩＣ２２０’がシンプルに動作することを可能にする。このように動作すると、ＮＩＣ２２０’は、パケットの受信がリモートアプリケーションサーバ１０６’によりアクノリッジされるまで、又は再送リミットが充たされるまで、暗号化されたペイロードを含むパケットを再送し続けてもよい。再送リミットは、単にパケットを送信するための所定の試行回数であってもよい。再送リミットを充たす場合、ＮＩＣ２２０’は、クライアントプラットフォーム２００’に低電力状態からアクティブ電力状態に遷移させる。クライアントプラットフォーム２００’を遷移させることは、図８の“１２”に示されるように、ＮＩＣ２２０’がホストシステム２０２によりモニタリングされたウェイクアップビットを設定し、ウェイクアップ信号をホストシステム２０２に送信することを含むものであってもよい。ウェイクすると、クライアントプラットフォーム２００’は当該状況を解決する。例えば、ネットワーク接続が失われた場合、クライアントプラットフォーム２００’は、ネットワーク１０４に再接続するまでＡＯＡＣ処理をサスペンドしてもよい。一実施例では、ＮＩＣ２２０’は、ＡＯＡＣ処理中に何れか予期しない状況があるときはいつでも、クライアントプラットフォーム２００’に低電力状態からアクティブ電力状態に遷移させるようにしてもよい。予期しない状況とは、限定することなく、リモートアプリケーションサーバ１０６’がパケットペイロードを解読できないこと、パケットのペイロードを受理できないこと（前のパケットが破棄されたため、パケットが順序通り到達しなかったためなど）、リモートアプリケーションサーバ１０６’とのアクティブなＴＣＰ接続が切断されたこと、高パケットトラフィックのための遅延などを含むものであってもよい。
【００４４】
ＮＩＣ２２０’はまた、プラットフォーム２００’に予期される状況に基づき低電力状態からアクティブ電力状態に遷移させてもよい。図８において、“１０”及び“１１”により２つのイベント例が示される。“１０”において、ウェイクアップメッセージが、リモートアプリケーションサーバ１０６’からＮＩＣ２２０’に送信される。例えば、リモートアプリケーションサーバ１０６’がクライアントプラットフォーム２００’においてＡＯＡＣアプリケーション（図３の３０２（１）〜３０２（ｎ）など）のための保留中の情報を有している場合、ウェイクアップメッセージが送信されてもよい。例えば、クライアントプラットフォーム２００’の電子メールアプリケーションに配信するためのリモートアプリケーションサーバ１０６’における保留中の電子メールが、ウェイクアップ信号を送信させてもよい。“１０”においてウェイクアップ信号を受信した後、ＮＩＣ２２０’は、“１２”において情報を受信するため（例えば、電子メールアプリケーションへの電子メールを受信するためなど）、クライアントプラットフォーム２００’に低電力状態からアクティブ電力状態に遷移させてもよい。また、ＮＩＣ２２０’は通常のＡＯＡＣ処理中にメモリ２７４’の全てのペイロードを送信成功することが可能であるかもしれない。図８の“１１”において、ＮＩＣ２２０’は、送信すべき更なるペイロードがないことを認識し、プラットフォーム２００’に更なるペイロードを生成／暗号化するため、“１２”において示されるように、低電力状態からアクティブ電力状態に遷移させてもよい。一実施例では、クライアントプラットフォーム２００’は、更なるペイロードを暗号化する際に利用するための新たな共有プライベートキーを生成するためリモートアプリケーションサーバ１０６’と再びやりとりし、新たなキーを用いて新たな暗号化されたペイロードを生成し、その後、低電力状態に戻るようにしてもよい。ＡＯＡＣ処理（例えば、暗号化されたペイロード送信など）が、その後に再開されてもよい。
【００４５】
図９は、少なくとも１つの実施例によるクライアントプラットフォームのＮＩＣの観点からの接続を維持するための一例となる処理のフローチャートを示す。処理９００において、クライアントプラットフォームが低電力状態に遷移中であるという通知が、ＮＩＣにおいて受信される。その後、ペイロードは、処理９０２においてクライアントプラットフォームからＮＩＣにおいて受信される。例えば、クライアントプラットフォームが低電力状態に入ろうとしていると判断すると、クライアントプラットフォームのＡＯＡＣアプリケーション／サービスは、ＮＩＣ（ＮＩＣのファームウェアなど）にアクセス可能なメモリにペイロードを書き込むようにしてもよい。一実施例では、受信したペイロードは暗号化されてもよい。処理９０４において、ＮＩＣは、リモートアプリケーションサーバとの新たなネットワーク接続（ＴＣＰ接続など）を開始してもよい。受信したペイロードの１つを含むパケットは、その後、処理９０６においてリモートアプリケーションサーバに送信される。その後、処理９０８において、パケットの受信がリモートアプリケーションサーバによりアクノリッジされたか判断される（例えば、送信したパケットに対応するアクノリッジメントを含むパケットが受信されたなど）。処理９０８において、アクノリッジメントが受信されたと判断された場合、処理９１０において、ＮＩＣが送信されたパケットに対するリトライリミットに到達したか、又はクライアントプラットフォームに低電力状態からアクティブ電力状態に遷移させるようＮＩＣを促す他のウェイクアップ状況が発生したか更なる判断が行われる。他のウェイクアップ状況とは、限定することなく、問題（予期しない動作など）がＮＩＣにより観察された、ウェイクアップパケットがリモートアプリケーションサーバからＮＩＣにおいて受信されたなどを含むものであってもよい。処理９１０において、リトライリミットに到達しておらず、クライアントプラットフォームを電力アップさせるようＮＩＣを促す他の状況が存在しないと判断された場合、処理９１２において、パケットが送信され、その後、処理９０８に戻ってアクノリッジメントを待機する。処理９１０において、リトライリミットに到達したか、又はウェイクアップ状況が存在すると判断された場合、処理９１６において、ＮＩＣは、クライアントプラットフォームに低電力状態からアクティブ電力状態に遷移させる。アクティブ電力状態において、クライアントプラットフォームは、存在する問題を処理するための手段を実行する。
【００４６】
処理９０８に戻って、送信したパケットに対応するアクノリッジメントが受信されたと判断された場合、処理９１４において、メモリの全てのペイロードが送信されたか、あるいは、クライアントプラットフォームに低電力状態からアクティブ電力状態に遷移させるようＮＩＣを促すウェイクアップ状況が発生したか判断される。ペイロードの必ずしも全てが送信されていない場合、処理９０６において、次のペイロード（暗号化されている場合、次の順番のペイロードなど）が送信される。処理９１４において、全てのペイロードが送信されたか、又はウェイクアップ状況が存在していると判断された場合、処理９１６において、ＮＩＣは、クライアントプラットフォームに低電力状態からアクティブ電力状態に遷移させる。アクティブ電力状態において、クライアントプラットフォームは、更なるペイロードを生成／暗号化するか、又は存在する何れかの問題を処理するための手段を実行する。
【００４７】
図６及び９は、いくつかの実施例による各種処理を示しているが、図６及び９に示される処理の必ずしも全てが他の実施例について必要であるとは限らないことが理解されるべきである。実際、本開示の他の実施例では、図６及び９に示される処理及びここに説明された他の処理は、何れかの図面に具体的に示されていないが、本開示に完全に整合する方法により組み合わせ可能である。従って、１つの図面に正確に示されていない特徴及び／又は処理に関する請求項は、本開示の範囲及び内容の範囲内とみなされる。
【００４８】
従って、本開示は、クライアントプラットフォームが低電力状態に遷移した後、クライアントプラットフォームとリモートリソース（少なくとも１つのリモートアプリケーションサーバなど）との間の接続を維持するための方法及びシステムを提供する。クライアントプラットフォームのＮＩＣは、クライアントプラットフォームが低電力状態に遷移中であるという通知と、暗号化されている可能性のある１以上のペイロードとを受信する。クライアントプラットフォームとリモートアプリケーションサーバとの間の接続を維持するため、ＮＩＣは、ペイロードを含むパケットを送信してもよい。リモートアプリケーションサーバからアクノリッジメントが受信されない場合、又はクライアントプラットフォームからの参加を必要とする他の状況が生じた場合、ＮＩＣは、クライアントプラットフォームに低電力状態からアクティブ電力状態に遷移させてもよい。そうでない場合、ＮＩＣは、残りのペイロードがなくなるまで、パケットを送信するか、又はアクノリッジメントを受信する。この場合、ＮＩＣは、クライアントプラットフォームに更なるペイロードを生成／暗号化するため、低電力状態からアクティブ電力状態に遷移させてもよい。
【００４９】
一態様によると、システムが提供される。当該システムは、パケットを送受信するよう構成される通信回路と、１以上の記憶媒体とを有する。さらに、１以上の記憶媒体は、１以上のプロセッサにより実行されると、前記プラットフォームが前記低電力状態に遷移しているという通知を受信するステップと、前記プラットフォームが前記低電力状態にある間にリモートリソースとの接続を維持するよう構成される少なくとも１つのペイロードを前記プラットフォームから受信するステップと、前記少なくとも１つのペイロードを含むパケットを送信するステップと、アクノリッジメントを含むパケットを受信するステップとを実行させる命令を個別に又は組み合わせて格納する。
【００５０】
上記システムは、リモートリソースがインターネットを介しアクセス可能な少なくとも１つのリモートアプリケーションサーバを有するよう更に構成されてもよい。
【００５１】
上記システムは、少なくとも１つのペイロードがプラットフォームとリモートリソースとの間で確定されたキーに基づき暗号化されるよう更に構成されてもよい。
【００５２】
上記システムは、１以上のプロセッサにより実行されると、少なくとも１つのペイロードを含むパケットを送信する前に、リモートリソースとのＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）接続を開始するステップを更に実行させる命令により更に構成されてもよい。
【００５３】
上記システムは、１以上のプロセッサにより実行されると、アクノリッジメントを含むパケットが受信されるまで、又は再送リミットに到達するまで、少なくとも１つのペイロードを含むパケットを再送するステップを更に実行させる命令により更に構成されてもよい。この構成例では、上記命令は、１以上のプロセッサにより実行されると、再送リミットに到達したことに基づき、プラットフォームを低電力状態からアクティブ電力状態に遷移させるステップを更に実行させる。
【００５４】
上記システムは、少なくとも１つのペイロードが複数のペイロードを有し、少なくとも１つのペイロードを含むパケットを送信するステップが、各パケットが複数のペイロードの１つを有するパケットを送信することを含むよう更に構成されてもよい。この構成例では、上記命令は、１以上のプロセッサにより実行されると、各パケットは複数のペイロードの１つを含むパケットの全てを送信したことに基づき、プラットフォームを低電力状態からアクティブ電力状態に遷移させるステップを更に実行させる。
【００５５】
上記システムは、１以上のプロセッサにより実行されると、リモートリソースから受信したパケットに基づき、プラットフォームを低電力状態からアクティブ電力状態に遷移させるステップを更に実行させる命令により更に構成されてもよい。この構成例では、上記システムは、リモートリソースから受信したパケットが、リモートリソースがプラットフォームのための保留中の情報を有していることを示すよう更に構成されてもよい。
【００５６】
他の態様によると、システムが提供される。本システムは、１以上のプロセッサにより実行されると、前記プラットフォームが前記低電力状態に遷移しているという通知を受信するステップと、前記プラットフォームが前記低電力状態にある間にリモートリソースとの接続を維持するよう構成される少なくとも１つのペイロードを前記プラットフォームから受信するステップと、前記少なくとも１つのペイロードを含むパケットを送信するステップと、アクノリッジメントを含むパケットを受信するステップとを実行させる命令を個別に又は組み合わせて格納した１以上の記憶媒体を有する。
【００５７】
上記システムは、リモートリソースがインターネットを介しアクセス可能な少なくとも１つのリモートアプリケーションサーバを有するよう更に構成されてもよい。
【００５８】
上記システムは、少なくとも１つのペイロードがプラットフォームとリモートリソースとの間で確定されたキーに基づき暗号化されるよう更に構成されてもよい。
【００５９】
上記システムは、１以上のプロセッサにより実行されると、少なくとも１つのペイロードを含むパケットを送信する前に、リモートリソースとのＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）接続を開始するステップを更に実行させる命令により更に構成されてもよい。
【００６０】
上記システムは、１以上のプロセッサにより実行されると、アクノリッジメントを含むパケットが受信されるまで、又は再送リミットに到達するまで、少なくとも１つのペイロードを含むパケットを再送するステップを更に実行させる命令により更に構成されてもよい。この構成例では、上記命令は、１以上のプロセッサにより実行されると、再送リミットに到達したことに基づき、プラットフォームを低電力状態からアクティブ電力状態に遷移させるステップを更に実行させる。
【００６１】
上記システムは、少なくとも１つのペイロードが複数のペイロードを有し、少なくとも１つのペイロードを含むパケットを送信するステップが、各パケットが複数のペイロードの１つを有するパケットを送信することを含むよう更に構成されてもよい。この構成例では、上記命令は、１以上のプロセッサにより実行されると、各パケットは複数のペイロードの１つを含むパケットの全てを送信したことに基づき、プラットフォームを低電力状態からアクティブ電力状態に遷移させるステップを更に実行させる。
【００６２】
上記システムは、１以上のプロセッサにより実行されると、リモートリソースから受信したパケットに基づき、プラットフォームを低電力状態からアクティブ電力状態に遷移させるステップを更に実行させる命令により更に構成されてもよい。この構成例では、上記システムは、リモートリソースから受信したパケットが、リモートリソースがプラットフォームのための保留中の情報を有していることを示すよう更に構成されてもよい。
【００６３】
他の態様によると、方法が提供される。本方法は、前記プラットフォームが前記低電力状態に遷移しているという通知を受信するステップと、前記プラットフォームが前記低電力状態にある間にリモートリソースとの接続を維持するよう構成される少なくとも１つのペイロードを前記プラットフォームから受信するステップと、前記少なくとも１つのペイロードを含むパケットを送信するステップと、アクノリッジメントを含むパケットを受信するステップとを有する。
【００６４】
上記方法は、リモートリソースがインターネットを介しアクセス可能な少なくとも１つのリモートアプリケーションサーバを有するよう更に構成されてもよい。
【００６５】
上記方法は、少なくとも１つのペイロードがプラットフォームとリモートリソースとの間で確定されたキーに基づき暗号化されるよう更に構成されてもよい。
【００６６】
上記方法は、少なくとも１つのペイロードを含むパケットを送信する前に、リモートリソースとのＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）接続を開始するステップを更に有してもよい。
【００６７】
上記方法は、アクノリッジメントを含むパケットが受信されるまで、又は再送リミットに到達するまで、少なくとも１つのペイロードを含むパケットを再送するステップを更に有してもよい。例えば、本方法は更に、再送リミットに到達したことに基づき、プラットフォームを低電力状態からアクティブ電力状態に遷移させるステップを更に有してもよい。
【００６８】
上記方法は、少なくとも１つのペイロードが複数のペイロードを有し、少なくとも１つのペイロードを含むパケットを送信するステップが、各パケットが複数のペイロードの１つを有するパケットを送信することを含むよう更に構成されてもよい。例えば、本方法は、各パケットは複数のペイロードの１つを含むパケットの全てを送信したことに基づき、プラットフォームを低電力状態からアクティブ電力状態に遷移させるステップを更に有してもよい。
【００６９】
上記方法は、リモートリソースから受信したパケットに基づき、プラットフォームを低電力状態からアクティブ電力状態に遷移させるステップを更に有してもよい。例えば、本方法は、リモートリソースから受信したパケットが、リモートリソースがプラットフォームのための保留中の情報を有していることを示すよう更に構成されてもよい。ここでの何れかの実施例で用いられる“回路”とは、例えば、配線回路、プログラマブル回路、状態マシーン回路及び／又はプログラマブル回路により実行される命令を格納するファームウェアなどを単独で又は何れかの組み合わせにより有してもよい。
【００７０】
ここで用いられた用語及び表現は、限定するものでなく説明のための用語として用いられ、当該用語及び表現の使用において、図示及び説明された特徴の何れか均等なもの（又はその一部）を排除する意図はなく、請求項の範囲内において各種改良が可能であることが認識される。従って、請求項はこのような全ての均等をカバーすることが意図される。
【図１】
2015505110.tif 000003
【図２】
2015505110.tif 000004
【図３】
2015505110.tif 000005
【図４】
2015505110.tif 000006
【図５】
2015505110.tif 000007
【図６】
2015505110.tif 000008
【図７】
2015505110.tif 000009
【図８】
2015505110.tif 000010
【図９】
2015505110.tif 000011
【国際調査報告】
2015505110.tif 000012
2015505110.tif 000013