特許 6385276 起動パターン管理

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】6385276

(24)【登録日】2018年8月17日

(45)【発行日】2018年9月5日

(54)【発明の名称】起動パターン管理

(51)【国際特許分類】

   G06F 9/445 20180101AFI20180827BHJP

【ＦＩ】

   G06F9/445

【請求項の数】10

【全頁数】37

(21)【出願番号】特願2014-529679(P2014-529679)

(86)(22)【出願日】2011年10月10日

(65)【公表番号】特表2014-526731(P2014-526731A)

(43)【公表日】2014年10月6日

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

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

(87)【国際公開日】20130314

【審査請求日】2014年9月24日

【審判番号】不服2017-227(P2017-227/J1)

【審判請求日】2017年1月6日

(31)【優先権主張番号】13/229,388

(32)【優先日】2011年9月9日

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

(73)【特許権者】

【識別番号】314015767

【氏名又は名称】マイクロソフト テクノロジー ライセンシング，エルエルシー

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100091214

【弁理士】

【氏名又は名称】大貫 進介

(72)【発明者】

【氏名】セイラー，デイヴィッド ジー．

(72)【発明者】

【氏名】シュリニヴァサン，カマラヴァサン

(72)【発明者】

【氏名】リッツ，アンドリュー ジェイ．

(72)【発明者】

【氏名】ガッタ，シュリニヴァス ラグー

(72)【発明者】

【氏名】エルトゥガイ，オスマン エヌ．

(72)【発明者】

【氏名】ガッデホスル，プールナナンダ アール．

(72)【発明者】

【氏名】アニプコ，ドミトリー エー．

【合議体】

【審判長】 高木 進

【審判官】 辻本 泰隆

【審判官】 山崎 慎一

(56)【参考文献】

【文献】 米国特許出願公開第２００８／０１６２６８２（ＵＳ，Ａ１）

【文献】 特開２０００−２３５４３３（ＪＰ，Ａ）

【文献】 特開２００７−１５８８７０（ＪＰ，Ａ）

【文献】 米国特許出願公開第２０１０／０３１２８９９（ＵＳ，Ａ１）

【文献】 特表２０１０−５２０６６８（ＪＰ，Ａ）

【文献】 特開２００６−１６４２５２（ＪＰ，Ａ）

【文献】 特開２００６−０３３０２６（ＪＰ，Ａ）

【文献】 吉川和成，“ｉＯＳ ４アプリ“真”手法 第２章 マルチタスクのしくみと実装ポイント”，ＳｏｆｔｗａｒｅＤｅｓｉｇｎ，日本，株式会社技術評論社，２０１０年１２月１８日，通巻３０８号（発刊２４２号），ｐｐ．４６−４７，ＩＳＳＮ ０９１６−６２９７

(58)【調査した分野】（Int.Cl.，ＤＢ名）

G06F9/445

(57)【特許請求の範囲】

【請求項1】

コンピューティングデバイスによって実現される方法であって、
前記コンピューティングデバイスは、起動パターン・マネージャ・モジュール、ネットワーク・デバイス・マネージャ・モジュール、およびキープ・アライブ・マネージャ・モジュール、を含み、
前記起動パターン・マネージャ・モジュールは、
前記コンピューティングデバイスのネットワーク・インターフェイス・デバイスによって受信されたネットワークトラフィックをモニタリングするステップと、
前記モニタリングされたネットワークトラフィック内のトラフィックパターンを認識するステップと、
前記認識されたトラフィックパターンに対応する前記コンピューティングデバイスのアプリケーションを識別するステップと、
前記識別するステップに応じて、前記識別されたアプリケーションの少なくとも一部を起動するステップと、を備え、
前記キープ・アライブ・マネージャ・モジュールは、
エンドポイントとサーバタイムアウト間隔、及び/又は、中継デバイスのネットワークタイムアウト間隔に基づいて、キープアライブ間隔を算出し、前記キープアライブ間隔を使用して、前記ネットワーク・インターフェイス・デバイスを起動し、前記コンピューティングデバイスの前記アプリケーションとネットワークとの間の通知チャネルを維持し、
前記ネットワーク・デバイス・マネージャ・モジュールは、
前記ネットワーク・インターフェイス・デバイスについて、電力モードを高電力モードまたは低電力モードにするように管理し、
前記ネットワーク・インターフェイス・デバイスが前記低電力モードである間、前記ネットワーク・インターフェイス・デバイスに、無線アクセスポイントとの接続およびインターネットプロトコル（ＩＰ）アドレスを維持させる、
ことを特徴とする方法。

【請求項2】

前記認識するステップは、
前記ネットワークトラフィックと、前記識別されたアプリケーションによって事前登録された前記トラフィックパターンとを比較することによって実行される、
請求項１に記載の方法。

【請求項3】

前記識別するステップは、
前記コンピューティングデバイスの複数のアプリケーションのいずれかを、前記トラフィックパターンに対して起動するかを判断するために、前記コンピューティングデバイスのネットワークスタックを検討することによって実行される、
請求項１に記載の方法。

【請求項4】

前記起動するステップは、
前記識別されたアプリケーションのネットワーク機能に対応する前記識別されたアプリケーションの前記一部を起動することを含み、
前記識別されたアプリケーションの前記ネットワーク機能に対応しない前記識別されたアプリケーションの他の部分を起動しない、
請求項１に記載の方法。

【請求項5】

前記他の部分は、
前記識別されたアプリケーションのユーザインターフェイスの生成と関係する、
請求項４に記載の方法。

【請求項6】

前記ネットワーク・インターフェイス・デバイスは、
仮想デバイスとして前記コンピューティングデバイスによって少なくとも部分的に実現される、
請求項１に記載の方法。

【請求項7】

前記モニタリングするステップ、前記認識するステップ、および、前記識別するステップは、
前記識別されたアプリケーションが一時停止状態にある間に実行される、
請求項１に記載の方法。

【請求項8】

前記識別されたアプリケーションは、
前記識別されたアプリケーションのユーザインターフェイスからのフォーカスの解除に応じて、前記一時停止状態に置かれる、
請求項７に記載の方法。

【請求項9】

前記フォーカスは、
前記ユーザインターフェイスの最小化、デスクトップ・ユーザ・インターフェイスの前景からの前記ユーザインターフェイスの除去、または、他のアプリケーションのユーザインターフェイスとの相互通信、を指示する入力の受信により解除される、
請求項８に記載の方法。

【請求項10】

前記モニタリングするステップ、前記認識するステップ、前記識別するステップ、および、前記起動するステップは、
前記コンピューティングデバイス上のオペレーティングシステムの実行を通じて行われる、
請求項１に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、起動パターンの管理に関する。

【背景技術】

【0002】

ユーザは、ネットワーク利用のために構成することが可能な、かつてないほど多くのさまざまなコンピューティングデバイスにアクセスする。例えば、ユーザは、デスクトップコンピュータ、携帯電話、およびタブレットコンピュータなどと相互通信して、有線もしくは無線ネットワークを介して相互通信することができる。

【発明の概要】

【発明が解決しようとする課題】

【0003】

しかしながら、このようなネットワークにアクセスするために使用された従来技術は、しばしば非効率的であり、したがって、電力、処理、およびネットワークリソースを含む、相当な量のリソースを消費する可能性があった。したがって、これらの従来技術では、デバイスのユーザが利用可能な機能に限界があった。

【課題を解決するための手段】

【0004】

起動パターン管理技術について説明する。１つまたは複数の実施態様において、コンピューティングデバイスのネットワーク・インターフェイス・デバイスによって受信されるネットワークトラフィックはモニタリングされ、トラフィックパターンは、モニタリングされたネットワークトラフィックにおいて認識される。コンピューティングデバイスのアプリケーションは、認識したトラフィックパターンに対応して識別され、この識別に応じて、識別されたアプリケーションの少なくとも一部が起動する。

【0005】

１つまたは複数の実施態様において、トラフィックパターンは、コンピューティングデバイスで実行するために構成されたアプリケーションに対応するよう登録される。アプリケーションが一時停止状態である間のネットワークトラフィックにおけるトラフィックパターンの認識に応じて、一時停止状態から動作状態へ、アプリケーションの少なくとも一部の遷移がトリガされる。

【0006】

１つまたは複数の実施態様において、１つまたは複数のコンピュータ読取り可能ストレージ媒体は、コンピューティングデバイスによる実行に応じて、コンピューティングデバイスのネットワーク・インターフェイス・デバイスを介して受信された着信パケットの識別に応答して、一時停止中のアプリケーションの少なくとも一部を起動するための技術をサポートするよう構成されたオペレーティングシステムを、コンピューティングデバイスに実施させる、コンピュータ読取り可能ストレージ媒体に格納された命令を備える。

【0007】

ネットワーク・インターフェイス・デバイスのオペレーティングシステム管理についてもまた説明する。１つまたは複数の実施態様において、オペレーティングシステムによって、コンピューティングデバイスの１つまたは複数のアプリケーションと関連したネットワークトラフィックが完了したことが判断される。その判断に応じて、ネットワーク・インターフェイス・デバイスを、オペレーティングシステムによって、ネットワーク・インターフェイス・デバイスの電力消費を抑えるためのモードに遷移させる。

【0008】

１つまたは複数の実施態様において、ネットワーク・インターフェイス・デバイスが高電力モードである場合、ネットワーク・インターフェイス・デバイスは、オペレーティングシステムによってコンピューティングデバイスの１つまたは複数のアプリケーションに対し利用可能になる。ネットワーク・インターフェイス・デバイスが低電力モードである場合、ネットワーク・インターフェイス・デバイスは、オペレーティングシステムによってコンピューティングデバイスの１つまたは複数のアプリケーションに対し利用不可能になる。

【0009】

１つまたは複数の実施態様において、１つまたは複数のコンピュータ読取り可能ストレージ媒体は、コンピューティングデバイスによる実行に応じてコンピューティングデバイスの１つまたは複数のアプリケーションによって、電力消費を抑えるためのモードにあるネットワーク・インターフェイス・デバイスへのアクセスを制限する技術をサポートするよう構成されたオペレーティングシステムをコンピューティングデバイスに実施させる、コンピュータ読取り可能ストレージ媒体に格納された命令を備え、ネットワーク・インターフェイス・デバイスは、プッシュ通知の受信に応答してそのモードから起動するよう構成される。

【0010】

キープアライブ管理（ｋｅｅｐ ａｌｉｖｅ ｍａｎａｇｅｍｅｎｔ）技術についても説明する。１つまたは複数の実施態様において、キープアライブ間隔は、コンピューティングデバイスのオペレーティングシステムによって算出される。キープアライブ間隔を使用して、コンピューティングデバイスの１つまたは複数のアプリケーションとネットワークとの間の、１つまたは複数の通知チャネルを維持する。

【0011】

１つまたは複数の実施態様において、ネットワークを介して各エンドポイントを有する通知チャネルを維持するよう指定された１つまたは複数のサーバタイムアウト間隔について、コンピューティングデバイスで実行可能な複数のアプリケーションのそれぞれに対して判断される。キープアライブ間隔は、複数のアプリケーションのそれぞれに対する１つまたは複数のサーバタイムアウト間隔から算出される。キープアライブ間隔を使用して、通知チャネルを維持するために指定されたネットワーク・インターフェイス・デバイスを起動する。

【0012】

１つまたは複数の実施態様において、１つまたは複数のコンピュータ読取り可能ストレージ媒体は、コンピューティングデバイスによる実行に応じて、ネットワークを介してコンピューティングデバイスで実行可能な複数のアプリケーションと１つまたは複数のエンドポイントのそれぞれとの間で通知チャネルを維持するために、キープアライブ間隔を使用するよう構成されたオペレーティングシステムをコンピューティングデバイスに実施させる、コンピュータ実行可能命令を備え、キープアライブ間隔は、ネットワークの１つまたは複数の中継デバイスの１つまたは複数のネットワークタイムアウト間隔と、１つまたは複数のアプリケーションがネットワークを介して通信する各エンドポイントの１つまたは複数のサーバタイムアウト間隔とに基づいて算出される。

【0013】

この発明の概要は、発明を実施するための形態において以下でさらに説明される、コンセプトの一部を簡素化して導入するものである。この発明の概要は、クレームに記載された対象の主要な特徴または重要な特徴を特定することを意図せず、クレームに記載された対象の範囲決定する際の補助として使用されることを意図するものでもない。

【0014】

添付図面を参照して、詳細な説明を説明する。図面において、参照番号の最も左側の桁により、参照番号が最初に現れる図面を識別する。説明および図面において、異なる例示で同じ参照番号を用いる場合、同様または同一の項目を示すことができる。

【図面の簡単な説明】

【0015】

【図1】ネットワーク・ブローカ・モジュールを使用して、コンピューティングデバイスの１つまたは複数のアプリケーションのネットワーク通信を管理するよう動作可能な例示的実施態様における環境の図である。

【図2】起動パターン・マネージャ・モジュールを使用する場合の、図１のネットワーク・ブローカ・モジュールをより詳細に示す例示的実施態様におけるシステムの図である。

【図3】トラフィックパターンの認識をアプリケーションの少なくとも一部を一時停止状態から動作状態に遷移するために使用する、例示的実施態様における手順を示すフロー図である。

【図4】トラフィックパターンの認識を使用してアプリケーションの少なくとも一部を起動する、例示的実施態様における他の手順を示すフロー図である。

【図5】ネットワーク・デバイス・マネージャ・モジュールを使用する場合の、図１のネットワーク・ブローカ・モジュールをより詳細に示す例示的実施態様におけるシステム図である。

【図6】ネットワーク・デバイス・マネージャ・モジュールの例示的動作を示す例示的実施態様における他のシステムの図である。

【図7】ネットワーク・インターフェイス・デバイスの沈黙遷移を示す例示的実施態様である。

【図8】ネットワーク・インターフェイス・デバイスの動作遷移を示す例示的実施態様である。

【図9】システムスリープ遷移を示す例示的実施態様である。

【図10】システム再開遷移を示す例示的実施態様である。

【図11】ネットワークトラフィックが完了し、ネットワーク・インターフェイス・デバイスがオペレーティングシステムによって低電力モードに遷移したことを判断する例示的実施態様における手順を示すフロー図である。

【図12】低電力モードの間、ネットワーク・インターフェイス・デバイスをアプリケーション利用に対し使用不可能にさせる例示的実施態様における手順を示すフロー図である。

【図13】キープ・アライブ・マネージャ・モジュールを使用する場合の、図１のネットワーク・ブローカ・モジュールをより詳細に示す例示的実施態様におけるシステムの図である。

【図14】図１３のキープアライブ間隔を算出および調整する例示的実施態様を示す例示的実施態様におけるシステムの図である。

【図15】キープアライブ間隔を算出して、１つまたは複数の通知チャネルを維持するために使用する例示的実施態様における手順である。

【図16】キープアライブ間隔を算出して、アプリケーションからキープアライブ通信をバッチ処理する例示的実施態様における手順である。

【図17】図１のネットワーク接続ブローカの実施例を示すシステムである。

【図18】図１のネットワーク接続ブローカの実施例を示すシステムである。

【図19】図１を参照して説明するようなコンピューティングデバイスを含む例示的システムである。

【図20】本明細書で説明する技術の実施形態を実現するための図１、図２、図５から図１０、図１３、図１４、および図１７から図１９を参照して説明するような任意の種類のコンピューティングデバイスとして実現することが可能である例示的デバイスのさまざまな構成要素である。

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

【0016】

ネットワーク接続されたアプリケーションは、典型的に、「最新の状態」であるために、長期接続を維持する能力を必要とする。しかしながら、従来技術では、このことは、可到達性を保証するために接続されたネットワーク・インターフェイス・デバイス（例えば、ネットワーク・インターフェイス・カード）を維持することを犠牲にしている可能性があり、コンピューティングデバイスのリソース使用に悪影響を及ぼす可能性がある。例えば、従来技術は、コンピューティングデバイスのアプリケーションおよびサービスが、ネットワーク・インターフェイス・デバイスに自由にアクセスすることを可能にする。したがって、オペレーティングシステムは、典型的に、ネットワーク・インターフェイス・デバイスがアプリケーションによって使用されている場合、任意の時点で起動しなかった。このことは、アイドル状態が検出されるまで、デバイスが低電力モードに移行するのを妨害する可能性があり、３０秒かかる可能性があるため、電源装置、例えば、バッテリ寿命に重大な影響を及ぼす可能性がある。

【0017】

それに応じて、本明細書で説明する技術では、ネットワーク・ブローカ・モジュールと呼ばれるオペレーティング・システム・コンポーネントを使用して、コンピューティングデバイスのネットワーク・インターフェイス・デバイスの使用を調整することができる。例えば、ネットワーク・インターフェイス・デバイスは、起動パターン・マネージャ・モジュールを使用して、コンピューティングデバイスのどのアプリケーションを、必要であれば、ネットワークトラフィックの受信に応じて起動させるかを判断することができる。起動パターン・マネージャ・モジュールは、例えば、事前登録パターンがネットワークトラフィックに存在するかどうかを検出し、そうである場合、対応するアプリケーションを起動することができる。このようにして、起動パターン・マネージャ・モジュールは、ネットワーク接続を活用するアプリケーションが一時停止状態にありながらも、「常にオンラインで、常に接続状態にある（ａｌｗａｙｓ ｏｎ／ａｌｗａｙｓ ｃｏｎｎｅｃｔｅｄ）」ユーザ体験を提供することができる。起動パターン・マネージャ・モジュールのさらなる説明は、図２から図４に関連して見ることができる。

【0018】

他の例において、ネットワーク・ブローカ・モジュールは、ネットワーク・デバイス・マネージャ・モジュールの機能を組み込むことができる。ネットワーク・デバイス・マネージャ・モジュールを使用して、例えば、コールバックをモニタリングすることによって、コンピューティングデバイスのアプリケーションと関係するネットワークトラフィックが完了したとモジュールが判断した場合、ネットワーク・インターフェイス・デバイスを低電力モードにすることができる。したがって、オペレーティングシステムのネットワーク・デバイス・マネージャ・モジュール１２６は、ネットワーク・インターフェイス・デバイスとアプリケーションとの間の中継ぎとして位置付けることができる。中継ぎとして、オペレーティングシステムは、ネットワーキング活動の情報を有することができ、したがって、ネットワーク・インターフェイス・デバイスが低電力モード、例えば、ネットワーク沈黙モード（ｑｕｉｅｔ ｍｏｄｅ）に入ることができるかどうかを、確定的に識別することができる。ネットワーク・デバイス・マネージャ・モジュールのさらなる説明は、図５から図１２に関連して見ることができる。

【0019】

さらなる例において、ネットワーク・ブローカ・モジュールは、キープ・アライブ・マネージャ・モジュールの機能を組み込むことができる。キープ・アライブ・マネージャ・モジュールを使用して、アプリケーションが一時停止状態にある間、ネットワーク接続（例えば、通知チャネル）を「キープアライブする」ことができるため、アプリケーションと関連したリソースの使用を少なくすることができる。さらに、キープ・アライブ・マネージャ・モジュールを使用して、ネットワーク・インターフェイス・デバイスを低電力モードにすることができ、ネットワーク接続を維持するために「起動する」ことができるため、ネットワーク・インターフェイス・デバイス自体と関連したリソースの使用を少なくすることができる。キープアライブ間隔を動的に判断するなどの、さまざまな他の機能もまた、キープ・アライブ・モジュールによって組み込むことができ、これらのさらなる説明は、図１３から図１８に関して見ることができる。

【0020】

以下の説明において、本明細書で説明する技術を使用することができる例示的環境について、最初に説明する。次いで、例示セクションを使用して、起動パターン・マネージャ・モジュール、ネットワーク・デバイス・マネージャ・モジュール、およびキープ・アライブ・マネージャ・モジュールの例示的機能を説明する。次いで、上記したセクションから機能を組み込むことができる実施例について説明する。本明細書で説明する技術は、例示的環境における性能に限定されず、例示的環境は、例示的技術の実行に限定されないことは、容易に理解されるであろう。

【0021】

例示的環境
図１は、本明細書で説明するネットワークブローカ技術を使用するよう動作可能である例示的実施態様における環境１００の図である。図示した環境１００は、処理システム１０４（例えば、１つまたは複数のプロセッサ、機能ブロック）、メモリ１０６、電源１０８、表示デバイス１１０、および、ネットワーク１１４を介してネットワーク接続（例えば、通知チャネル）を提供するよう構成された１つまたは複数のネットワーク・インターフェイス・デバイス１１２を備えるコンピューティングデバイス１０２を含む。以下の説明において、示される構成要素は、１つまたは複数の構成要素を表すことができ、したがって、単一または複数の形態の構成要素、例えば、単一のネットワーク・インターフェイス・デバイス１１２および複数のネットワーク・インターフェイス・デバイス１１２などを区別なく参照することができる。

【0022】

コンピューティングデバイス１０２は、さまざまな方法で構成することができる。例えば、コンピューティングデバイス１０２は、デスクトップコンピュータ、モバイルステーション、エンターテインメント機器、表示デバイスに通信可能に結合されたセット・トップ・ボックス、無線電話、およびゲーム機などの、ネットワーク１１４上で通信することが可能なコンピュータとして構成してもよい。したがって、コンピューティングデバイス１０２は、相当なメモリならびにプロセッサリソースを有するフル・リソース・デバイス（例えば、パーソナルコンピュータ、ゲーム機）から、限られたメモリ及び/又はプロセッシングリソースを有する低リソースデバイス（例えば、従来型のセット・トップ・ボックス、携帯型ゲーム機）にまで及ぶことができる。さらに、単一のコンピューティングデバイス１０２が示されるが、コンピューティングデバイス１０２は、処理を実行するためにビジネスで使用される複数のサーバ（例えば、サーバファーム）、遠隔制御ならびにセット・トップ・ボックスの組み合わせ、および画像取得デバイスならびにゲーム機などの、複数の異なるデバイスで表すことができる。

【0023】

ネットワーク１１４は、インターネットとして図示されているが、ネットワークは、多種多様な構成を想定することができる。例えば、ネットワーク１１４は、広域ネットワーク（ＷＡＮ）、構内ネットワーク（ＬＡＮ）、またはイントラネットを含むことができるため、ネットワーク・インターフェイス・デバイス１１２は、有線接続を介して、これらのネットワークにアクセスするよう構成することができる。ネットワーク１１４は、また、無線広域ネットワーク（ＷＷＡＮ）、無線構内ネットワーク（ＷＬＡＮ）、およびセルラネットワーク（例えば、３Ｇ、４Ｇ、ＬＴＥネットワーク）などの無線技術を介してアクセスするよう構成することができる。ネットワーク・インターフェイス・デバイス１１２は、物理的デバイスとしても、仮想プライベートネットワークおよびトンネリングなどをサポートするために使用されるような仮想ネットワークデバイスとしても表すことができる。したがって、単一のネットワーク１１４を示すが、ネットワーク１１４は、複数のネットワークを表すことができる。

【0024】

コンピューティングデバイス１０２は、さらに、オペレーティングシステム１１６を含むものとして図示される。オペレーティングシステム１１６は、コンピューティングデバイス１０２で実行可能なアプリケーション１１８、１２０に、コンピューティングデバイス１０２の基礎となる機能を抽出するよう構成される。例えば、オペレーティングシステム１１６は、コンピューティングデバイス１０２の処理システム１０４、メモリ１０６、電源１０８（例えば、バッテリまたは有線接続）、及び/又は表示デバイス１１０機能を抽出することができ、アプリケーション１１８、１２０は、この基礎となる機能を実行する「方法」を知ることなく書くことができる。アプリケーション１１８、１２０は、例えば、表示デバイス１１２によって表現および表示されるデータを、この表現をどのように実行することができるかを理解することなく、オペレーティングシステム１１６に提供することができる。

【0025】

同様に、オペレーティングシステム１１６は、また、ネットワーク・ブローカ・モジュール１２２の使用により、アプリケーション１１８、１２０へのネットワーク接続機能を抽出することができる。ネットワーク・ブローカ・モジュール１２２はアプリケーション１１８、１２０によるネットワーク・インターフェイス・デバイス１１２の使用およびネットワーク・インターフェイス・デバイス１１２自身の動作を管理するための機能を表す。

【0026】

すでに述べたように、ネットワーク・ブローカ・モジュール１２２は、さまざまな異なる機能を組み込み、この管理を行うことができる。例えば、ネットワーク・ブローカ・モジュール１１２は、特定のトラフィックパターンを識別すると、アプリケーション１１８、１２０の１つまたは複数を起動するよう構成された、起動パターン・マネージャ・モジュール１２４を組み込むことができる。例えば、特定のトラフィックパターンは、アプリケーションによって予め登録することができるので、パターンが認識されると、起動パターン・マネージャ・モジュール１２４は、アプリケーション１１８、１２０のそれぞれを含む、コンピューティングデバイス１０２全体を起動させた従来技術とは対照的に、アプリケーション１１８、１２０の対応する１つを起動することができる。起動パターン・マネージャ・モジュール１２４のさらなる説明は、図２から図４に関連して見ることができる。

【0027】

ネットワーク・ブローカ・モジュール１２２は、また、ネットワーク・デバイス・マネージャ・モジュール１２６を含むものとして図示される。上記のように、このモジュールは、ネットワーク・インターフェイス・デバイス１１２の動作、およびコンピューティングデバイス１０２のアプリケーション１１８、１２０に対するネットワーク・インターフェイス・デバイス１１２の可用性を管理するための機能を表す。これには、アプリケーション１１８、１２０と関連するネットワークトラフィックが完了したとネットワーク・デバイス・マネージャ・モジュール１２６が判断した場合、電力消費を抑えるためのモードにネットワーク・インターフェイス・デバイス１１２を入れることを含むことができる。

【0028】

さらに、ネットワーク・デバイス・マネージャ・モジュール１２６は、このモードにある間、ネットワーク・インターフェイス・デバイス１１２を、アプリケーション１１８、１２０に対して利用不可能にすることができ、アプリケーション１１８、１２０は、ネットワーク・インターフェイス・デバイス１１２を必要以上に起動することがない。このようにして、ネットワーク・デバイス・マネージャ・モジュール１２６は、アプリケーション１１８、１２０からネットワーク・インターフェイス・デバイスに「ブラックホール（”ｂｌａｃｋ ｈｏｌｅ”）」通信する可能性がある。ネットワーク・デバイス・マネージャ・モジュール１２６についてのさらなる説明は、図５から図１２に関連して開始する以下の説明における対応するセクションに関連して見ることができる。

【0029】

ネットワーク・ブローカ・モジュール１２２はさらに、キープ・アライブ・マネージャ・モジュール１２８を含むものとして図示される。キープ・アライブ・マネージャ・モジュール１２８は、一時停止状態にあるアプリケーション１１８、１２０に対してさえも、ネットワーク接続を維持するために使用することができる機能を表す。例えば、キープ・アライブ・マネージャ・モジュール１２８は、ネットワークサービスの１つまたは複数のサーバと通信して、ネットワーク１１４上で、サービスとコンピューティングデバイス１０２との間でネットワーク接続をアクティブにし続けることができる。キープ・アライブ・マネージャ・モジュール１２８は、また、この動作を行うべき間隔を動的に判断するための機能を含むことができ、したがって、さらに、コンピューティングデバイス１０２のリソースを節約することができる。キープ・アライブ・マネージャ・モジュール１２８についてのさらなる説明は、図１３から図１８に関連して開始する以下の説明における対応するセクションに関連して見ることができる。

【0030】

ネットワーク・ブローカ・モジュール１２２ならびに対応する起動パターン・マネージャ・モジュール１２４、ネットワーク・デバイス・マネージャ・モジュール１２６、およびキープ・アライブ・マネージャ・モジュール１２８が、オペレーティングシステム１１６の一部として図示されるが、この機能は、さまざまな異なる構成要素によって実現することが可能であることは、容易に理解されるであろう。そのような構成要素の例には、スタンドアロンアプリケーション、およびサードパーティ製プラグインなどがある。

【0031】

一般に、本明細書で説明するいずれの機能も、ソフトウェア、ファームウェア、ハードウェア（例えば、固定ロジック回路）、またはそれらの実施態様の組み合わせを使用して実現することができる。本明細書で使用する「モジュール」、「機能」、および「ロジック」という用語は、一般に、ソフトウェア、ファームウェア、ハードウェア、またはそれらの組み合わせを意味する。ソフトウェア実施の場合、モジュール、機能、またはロジックは、プロセッサ（例えば、単一ＣＰＵまたは複数ＣＰＵ）で実行される場合、特定のタスクを実行するプログラムコードを意味する。プログラムコードは、１つまたは複数のコンピュータ読取り可能メモリデバイスに格納することができる。以下で説明するネットワークブローカ技術の特徴は、プラットフォーム独立型であり、本技術は、さまざまなプロセッサを有するさまざまな市販のコンピューティングプラットフォームで実現することができることを意味する。

【0032】

例えば、コンピューティングデバイス１０２は、また、コンピューティングデバイス１０２のハードウェアに、例えば、プロセッサ、および機能ブロックなどの動作を実行させる構成要素（例えば、ソフトウェア）を含むことができる。例えば、コンピューティングデバイス１０２は、コンピューティングデバイス、より詳しくは、コンピューティングデバイス１０２のハードウェアに動作を実行させる命令を保持するよう構成することができる、コンピュータ読取り可能媒体を含むことができる。したがって、命令は、動作を実行するようハードウェアを構成するために機能し、このようにして、機能を実行するようハードウェアの変形をもたらす。命令は、コンピュータ読取り可能媒体によって、さまざまな異なる構成品を通じて、コンピューティングデバイス１０２に提供することができる。

【0033】

コンピュータ読取り可能媒体のそのような構成の１つに、信号搬送媒体があり、したがって、命令（例えば、搬送波）を、コンピューティングデバイスのハードウェアに、ネットワークを介するなどして伝送するよう構成される。コンピュータ読取り可能媒体は、また、コンピュータ読取り可能ストレージ媒体として構成することができ、その場合、信号搬送媒体ではない。コンピュータ読取り可能ストレージ媒体の例には、ランダム・アクセス・メモリ（ＲＡＭ）、リード・オンリー・メモリ（ＲＯＭ）、光学ディスク、フラッシュメモリ、ハードディスクメモリ、および、磁気的、光学的ならびに他の技術を使用して、命令ならびに他のデータを格納可能な他のメモリデバイスがある。

【0034】

起動パターン・マネージャ・モジュール
図２は、図１のネットワーク・ブローカ・モジュール１２２の起動パターン・マネージャ・モジュール１２４の例示的動作を示す例示的実施態様におけるシステム２００の図である。すでに述べたように、従来技術には、アプリケーションが到達可能な実際に動作中のプロセスが含まれた。したがって、比較的長く動作しているネットワーク接続の使用を必要とするアプリケーションは、任意の時点でデータを送信および受信することができ、バッテリ寿命などの、コンピューティングデバイス１０２のリソースに直接影響を与える可能性があった。

【0035】

しかしながら、この例において、オペレーティングシステム１１６は、ネットワーク・ブローカ・モジュール１２２を使用して、「常にオンラインで、常に接続状態にある」ユーザ体験をサポートすることができる。この例において、体験は、ネットワーク通信で必要とされる特定のアプリケーションを起動するために使用することができる起動パターン・マネージャ・モジュール１２４の使用を通じてサポートされる。

【0036】

例えば、起動パターン・マネージャ・モジュール１２４は、特定のアプリケーション１１８、１２０が示すトラフィックパターン２０２を、アプリケーション１１８、１２０が登録することを可能にすることができる。例えば、アプリケーション１１８は、アプリケーション１２０に対して登録されたトラフィックパターンとは異なるトラフィックパターン２０２を登録することができる。それに応じて、起動パターン・マネージャ・モジュール１２４は、トラフィックパターン２０２に対してネットワークトラフィック２０４をモニタリングし、対応するアプリケーション１１８、１２０を起動することができる。

【0037】

例えば、アプリケーション開発者は、オペレーティングシステム１１６のネットワーク・ブローカ・モジュール１２２とのコントラクト（ｃｏｎｔｒａｃｔ）を、ある種のイベントおよびこれらのイベントのそれぞれに対して実行されるコールバックを指示するよう定めてもよい。その場合、ネットワーク・ブローカ・モジュール１２２は、そのトラフィックパターン２０２を登録したアプリケーション１１８、１２０の１つまたは複数に対応する、ネットワーク１１４を介してネットワーク・インターフェイス・デバイス１１２によって受信されたデータの特定パターンを「組み込む」ことができる。

【0038】

それに応じて、ネットワーク・ブローカ・モジュール１２２の起動パターン・マネージャ・モジュール１２４は、アプリケーション１１８に対するトラフィックパターンで記載した着信パケットの受信の際に、オペレーティングシステム１１６に割り込むことができる。さらに、オペレーティングシステム１１６は、登録したコールバック・エントリー・ポイントで、一時停止状態からアプリケーション１１８を起動し、パケットをアプリケーション１１８に示すことができる。このようにして、起動パターン・マネージャ・モジュール１２４は、事前承認された遠隔エンドポイントからの着信パケットについて、一時停止中のアプリケーションを作動させるための技術をサポートすることができる。さらに、このことは、物理的ネットワーク・インターフェイス・デバイス１１２が着信パケットのフィルタリングをサポートしない場合でさえも、オペレーティングシステム１１６が、あるパターンを組み込むことを可能にし、それにより、オペレーティングシステム１１５が入力パケットをフィルタリングすることを可能にする。

【0039】

アプリケーション１１８、１２０は、また、コンピューティングデバイス１０２のリソース使用の効率を向上するよう構成することができる。例えば、アプリケーション１１８は、別々に実行することができる異なる部分を形成するよう誘導することができる。アプリケーション１１８に対するこのことについて示した例は、アプリケーション１１８に対するユーザインターフェイスの生成で必要とされる機能などの、アプリケーション１１８の他の機能２０８とは別に、ネットワーク機能２０６の誘導を含む。

【0040】

したがって、上記の例に連続して、ネットワーク・ブローカ・モジュール１２２は、特定のトラフィックパターン２０２に一致するパケットを示し、アプリケーション１１８のユーザインターフェイスを生成する際に必要なアプリケーション１１８のコードをリハイドレート（ｒｅｈｙｄｒａｔｅ）することなく、アプリケーションコードの特定のコールバックを実行するなどの、アプリケーション１１８のネットワーク機能２０６を起動することができる。したがって、アプリケーション１１８は、データパケット、およびキープアライブを開始した遠隔エンドポイントなどに対してリソース効率の良い方法で、遠隔サーバからネットワークトラフィック２０４に応答するよう構成することができる。アプリケーション１１８のイベントハンドラの分離などの、アプリケーション１１８を誘導するさまざまな他の例もまた、想定される。

【0041】

起動パターン・マネージャ・モジュール１２４は、また、アプリケーション１１８、１２０に通信するためのデータを融合するための技術をサポートすることができ、さらに、トラフィックパターン２０２によって指示することができる。例えば、起動パターン・マネージャ・モジュール１２４は、ネットワーク・インターフェイス・デバイス１１２で、ネットワーク１１４を介して、さまざまな異なる通知チャネルを介して、データを受信することができる。このデータをアプリケーション１１８、１２０に「すぐに」通信する代わりに、起動パターン・マネージャ・モジュール１２４は、規定した間隔でアプリケーション１１８、１２０に通信するためのこのデータを融合してもよい。

【0042】

したがって、アプリケーション１１８、１２０を実行する際に使用されるコンピューティングデバイス１０２のリソースは、これらのリソースが使用されるとき、およびその方法をさらに節約するために共に使用することができる。例えば、アプリケーション１１８に対するデータを受信し、アプリケーション１１８を起動し、パケットをアプリケーション１１８に通信し、次いで、アプリケーション１２０に対して受信したパケットに対してこのことを繰り返す代わりに、これらのパケットはキャッシュされ、次いで、回送されてもよい。

【0043】

１つまたは複数の実施態様において、起動パターン・マネージャ・モジュール１２４は、また、ユーザログインについての情報を活用することができる。例えば、起動パターン・マネージャ・モジュール１２４は、コンピューティングデバイス１０２にアクティブにログインしたユーザに対するトラフィックパターン２０２を使用することができるが、他のユーザに対しては使用せず、最後にログインしたユーザに対するパターンなどを使用することができる。当然、アクティブであろうとなかろうと、ログインした各ユーザに対してパターンが使用される実施形態などの、他の実施態様もまた想定される。

【0044】

したがって、オペレーティングシステムは、コンピューティングデバイスのネットワーク・インターフェイス・デバイスを介して受信した着信パケットの識別に応じて、一時停止中のアプリケーションの少なくとも一部を起動するための技術をサポートするよう構成することができることを説明した。これらの技術についてのさらなる説明は、以下の手順および実施例に関連して見ることができる。

【0045】

トラフィックパターンの認識をアプリケーションの少なくとも一部を一時停止状態から動作状態に遷移するために使用する、例示的実施態様における手順３００を示す。本手順の態様は、ハードウェア、ファームウェア、ソフトウェア、またはそれらの組み合わせで実現することができる。本手順は、１つまたは複数のデバイスによって実行される動作を明示するブロックのセットとして示され、各ブロックによる動作を実行するために示される順序に必ずしも限定されない。以下の説明の部分では、図１の環境１００および図２のシステム２００を参照する。

【0046】

トラフィックパターンは、コンピューティングデバイスで実行するために構成されたアプリケーションに対応して登録される（ブロック３０２）。例えば、トラフィックパターン２０２は、起動パターン・マネージャ・モジュール１２４のＡＰＩとの相互通信などを通じて、アプリケーション１１８のインストール中に、アプリケーション１１８によって登録することができる。さらに、トラフィックパターン２０２を使用して、特定パケット、コールバックの識別、特定遠隔エンドポイントの識別などの、さまざまな異なる性質のネットワークトラフィック２０４について説明することができる。

【0047】

アプリケーションが一時停止状態である間のネットワークトラフィックにおけるトラフィックパターンの認識に応じて、アプリケーションの少なくとも一部は、一時停止状態から動作状態に遷移される（ブロック３０４）。アプリケーション１１８は、さまざまな異なるファクタのため、一時停止状態に置かれる可能性がある。例えば、オペレーティングシステム１１６は、フォーカスが他のアプリケーションに移った場合、アプリケーション１１８を一時停止状態に置くよう構成することができる。フォーカスは、アプリケーションのユーザインターフェイスを最小にすること、デスクトップ・ユーザ・インターフェイスにおける前景からのユーザインターフェイス（例えば、ウィンドウ）の移動、およびイマーシブ（ｉｍｍｅｒｓｉｖｅ）環境におけるアプリケーション１１８のユーザインターフェイスからの他への移動などによって移ることができる。したがって、オペレーティングシステム１１６は、ユーザ相互通信のために直接利用することができないアプリケーションの実行を一時停止することによって、コンピューティングデバイス１０２のリソースを節約することができる。

【0048】

すでに述べたように、起動パターン・マネージャ・モジュール１２４は、ネットワークトラフィック２０４からのトラフィックパターン２０２を認識し、アプリケーション１１８（例えば、ネットワーク機能２０６ではなく他の機能２０８）の少なくとも一部を動作状態に遷移し、識別されたネットワークトラフィック２０４を処理することができる。したがって、起動パターン・マネージャ・モジュール１２４は、ネットワークトラフィック２０４が関係する特定のアプリケーション１１８およびアプリケーション１１８の特定の部分でさえも遷移することができる。起動パターン・マネージャ・モジュール１２４の使用についての他の例は、以下の図に関連して見ることができる。

【0049】

図４は、トラフィックパターンの認識を使用してアプリケーションの少なくとも一部を起動する、例示的実施態様における手順４００を示す。本手順の態様は、ハードウェア、ファームウェア、ソフトウェア、またはそれらの組み合わせで実現することができる。本手順は、１つまたは複数のデバイスによって実行される動作を明示するブロックのセットとして示され、各ブロックによる動作を実行するために示される順序に必ずしも限定されない。以下の説明の部分では、図１の環境１００および図２のシステム２００を参照する。

【0050】

コンピューティングデバイスのネットワーク・インターフェイス・デバイスによって受信されたネットワークトラフィックは、モニタリングされる（ブロック４０２）。例えば、コンピューティングデバイス１０２は、ＶＰＮおよびトンネリングなどをサポートするための仮想デバイスとして実現される、物理的デバイスとして構成することができる、ネットワーク・インターフェイス・デバイス１１２でネットワークトラフィックを受信することができる。

【0051】

トラフィックパターンは、モニタリングされたネットワークトラフィックにおいて認識される（ブロック４０４）。上記のように、パケットおよび送信側エンティティなど、さまざまな異なるトラフィックパターンを認識することができる。このトラフィックパターンから、認識されたトラフィックパターンに対応するコンピューティングデバイスのアプリケーションが識別される（ブロック４０６）。例えば、１つまたは複数のアプリケーションは、起動パターン・マネージャ・モジュール１２４に事前登録され、特定のネットワークトラフィックを受信することができる。この識別に応じて、ネットワーク機能２０６およびアプリケーション１１８の全体など、識別されたアプリケーションの少なくとも一部が起動される（ブロック４０８）。起動パターン・マネージャ・モジュール１２４の例示的動作のさらなる説明は、実施例に関連して見ることができる。

【0052】

ネットワーク・デバイス・マネージャ・モジュール
図５は、図１のネットワーク・ブローカ・モジュール１２２のネットワーク・デバイス・マネージャ・モジュール１２６の例示的動作を示す例示的実施態様におけるシステム５００の図である。すでに述べたように、オペレーティングシステム１１６のネットワーク・ブローカ・モジュール１２２、したがって、ネットワーク・デバイス・マネージャ・モジュール１２６は、ネットワーク・インターフェイス・デバイス１１２とアプリケーション１１８、１２０との間の中継ぎとして位置付けることができる。中継ぎとして、オペレーティングシステム１１６は、ネットワーキング活動の情報を有することができ、したがって、ネットワーク・インターフェイス・デバイス１１２が低電力モード、例えば、ネットワーク沈黙モードに入ることができるかどうかを、確定的に識別することができる。

【0053】

例えば、ネットワーク・デバイス・マネージャ・モジュール１２６を使用して、例えば、コールバックをモニタリングすること、および最後のコールバックが完了したときを判断することによって、コンピューティングデバイスのアプリケーションを含むネットワークトラフィック５０２が完了したとモジュールが判断した場合、ネットワーク・インターフェイス・デバイス１１２を低電力モードにすることができる。したがって、ネットワークトラフィック５０２は、この例において、アプリケーション１１８、１２０からの出力トラフィックを含む。

【0054】

それに応じて、ネットワーク・デバイス・マネージャ・モジュール１２６は、ネットワーク・インターフェイス・デバイス１１２を、高電力モード５０４から低電力モード５０6６に遷移させることができる。その名前が意味するように、これらのモードは、そのモードにある間、ネットワーク・インターフェイス・デバイス１１２によって消費される電力量によって区別される。一例において、高電力モード５０４は、ネットワーク・インターフェイス・デバイス１１２によるデータの伝送および受信を可能にするよう構成される。この実施例において、低電力モード５０６は、ネットワーク・インターフェイス・デバイス１１２の伝送機能を一時的に動作不能にすることで電力消費を抑えるよう構成される。したがって、アウトバウンド動作が抑制され、したがって、単に起動パターンが組み込まれるために、システムに影響する可能性のあるトラフィックが起動パターンと一致するか、またはシステムがキープアライブ動作などのアウトバウンド（ｏｕｔｂｏｕｎｄ）動作を開始するための時間を算出する場合のパケットに限定されることを意味する。さまざまな他の例もまた、想定される。

【0055】

このようにして、ネットワーク・デバイス・マネージャ・モジュール１２６は、ネットワーク・インターフェイス・デバイス１１２の使用がアウトバウンドトラフィックのためにもはや要求されなくなる場合を先に判断することができ、それに応じて、３０秒程度の非動作期間の検出に左右される従来技術とは対照的に対応することができる。したがって、中継ぎとしてのオペレーティングシステム１１６を位置付けることによってもたらされるネットワークトラフィック５０２の情報を使用して、コンピューティングデバイス１０２のリソースを節約することができる。

【0056】

ネットワーク・デバイス・マネージャ・モジュール１２６は、また、所望の期間、ネットワーク・インターフェイス・デバイス１１２に対して低電力モード５０６を保ち、及び/又は維持するための技術をサポートすることができる。すでに述べたように、従来技術は、アプリケーション１１８、１２０の、ネットワーク・インターフェイス・デバイス１１２への自由なアクセスを可能にし、その結果、コンピューティングデバイス１０２のリソースについて悪影響を及ぼす可能性があった。それに応じて、アプリケーション１１８、１２０とネットワーク・インターフェイス・デバイス１１２との間の中継ぎとして、ネットワーク・デバイス・マネージャ・モジュール１２６を位置付けることは、高電力および低電力モード５０４、５０６を管理するために使用することができる。

【0057】

例えば、ネットワーク・デバイス・マネージャ・モジュール１２６は、「ブラックホール化」技術をサポートし、アプリケーション１１８、１２０によるネットワーク・インターフェイス・デバイス１１２への、低電力モード５０６にある間のアクセスを制限することができる。これは、ネットワーク・インターフェイス・デバイス１１２を利用不可能にする、アプリケーション１１８、１２０からネットワーク・インターフェイス・デバイス１１２へのパケットの通信をブロックする、低電力モード５０６の間にアプリケーション１１８、１２０にエラーコードを戻す、およびドロップされたパケットイベントを知らせるなどの、さまざまな方法で実行することができる。したがって、ネットワーク・デバイス・マネージャ・モジュール１２６は、低電力モード５０６から高電力モード５０４にネットワーク・インターフェイス・デバイス１１２を起動するためのアプリケーション１１８、１２０の能力を制限することができ、それにより、コンピューティングデバイス１０２のリソースを節約することができる。

【0058】

ネットワーク・デバイス・マネージャ・モジュール１２６は、また、複数の異なるネットワーク・インターフェイス・デバイス１１２の使用を、ネットワーク・インターフェイス・デバイス１１２のいずれが所定の時点でアクセスされることを可能にするかを管理することによって、管理するための技術をサポートすることができる。例えば、コンピューティングデバイス１０２は、モバイル通信デバイス（例えば、無線電話）として構成することができ、Ｗｉ−Ｆｉおよびセルラ（例えば、３Ｇ、４Ｇ、ＬＴＥ）ネットワーク上で通信するよう構成されたネットワーク・インターフェイス・デバイス１１２を含むことができる。

【0059】

Ｗｉ−Ｆｉに対するネットワーク・インターフェイス・デバイス１１２が高電力モードにある例において、ネットワーク・デバイス・マネージャ・モジュール１２６は、セルラネットワークに対するネットワーク・インターフェイス・デバイス１１２を、低電力モードにすることができる。さらに、セルラネットワークと相互通信しようとするアプリケーションを、代わりに、Ｗｉ−Ｆｉネットワークに経路付けても良い。このようにして、ネットワーク接続マネージャモジュール１２６は、アプリケーション１１８、１２０が、「不適切な」ネットワーク・インターフェイス・デバイス１１２と通信することを防ぐことができ、それにより、デバイスを起動することなく、コンピューティングデバイス１０２のリソースを節約することができる。

【0060】

ネットワーク・デバイス・マネージャ・モジュール１２６は、また、低電力モードにある間、接続を維持するよう構成することができる。例えば、アプリケーション１１８、１２０及び/又はオペレーティングシステム１１６のサービスは、アクセスポイントとの接続を維持するために、レイヤ２接続を維持することを要求することができる。これには、アクセスポイントと通信するために、規定された間隔で、低電力モード５０６から周期的に起動することを含むことができる。同じように、レイヤ３接続もまた、同様の技術を使用して維持され、サーバが規定された間隔でアドレスをリフレッシュするよう構成された場合などに対して、ＨＴＴＰサーバと通信することによってＩＰアドレスを維持することができる。ネットワーク接続の維持についてのさらなる説明は、以下の説明における「キープアライブ」セクションで見ることができる。

【0061】

図６は、ネットワーク・デバイス・マネージャ・モジュール１２６の例示的動作を示す例示的実施態様における他のシステム６００の図である。このシステム６００は、オペレーティングシステム１１６がネットワーク・インターフェイス・デバイス１１２の管理を補助するために使用することができるアーキテクチャの実施例である。

【0062】

ネットワーク・デバイス・マネージャ・モジュール１２６は、この例においては、ｎｄｉｓ．ｓｙｓ６０２に存在するロジックコンポーネントとして実現することができ、ネットワーク・インターフェイス・デバイス１１２に対する電力モードの制御を担う。ネットワーク・デバイス・マネージャ・モジュール１２６は、アダプタ毎のＮＩＤ動作状態（例えば、ＮＩＣ動作状態）を明らかにして、ネットワーク・インターフェイス・デバイス１１２上のきめ細やかな電力制御をサポートするよう構成することができる。

【0063】

ＮＩＤ動作状態は、基準カウンタを使用して実現することができる。カウンタが０に達すると、ネットワーク・デバイス・マネージャ・モジュール１２６は、ネットワーク・インターフェイス・デバイス１１２を、低電力状態に遷移させることができる。カウンタが、０から１にインクリメントされると、ＮＤＩＳ６０２は、ネットワーク・インターフェイス・デバイス１１２を高電力状態、すなわち、「作動（”ｗｏｒｋｉｎｇ”）」電力状態に移すことができる。

【0064】

図示したように、オペレーティングシステム１１６のコンポーネントを使用して、例えば、プライベートＩＯＣＴＬをＮＤＩＳ６０２に送信することによって、さまざまな目的のために、基準カウンタをインクリメント及び/又はデクリメントすることができる。１つまたは複数の実施態様において、電力依存コーディネータ（ＰＤＣ、ｐｏｗｅｒ ｄｅｐｅｎｄｅｎｃｙ ｃｏｏｒｄｉｎａｔｏｒ）６０６と通信するＷＣＭ６０４は、「長い」時間、例えば、ネットワーク動作期間の全期間、ＮＩＤ動作基準を保持することを可能にする単独コンポーネントである。他のコンポーネントのそれぞれは、単一動作、例えば、ＩＰアドレス更新の期間、ＮＩＤ動作基準をとることが可能とされる。

【0065】

ＷＣＭ６０４は、ＰＤＣ６０６によって生成されたネットワーク沈黙入口／出口イベントをリッスンし、インターフェイス選択ロジックに従って、ＮＩＣ動作状態にそれらを変換するよう構成することができる。ＷＣＭ６０４は、ＮＤＩＳ６０２がネットワーク・インターフェイス・デバイス１１２の電源を切ることを防ぐように、アダプタ到達の際に基準をとることができる。

【0066】

ＷＷＡＮ６０８は、ＮＩＣ動作基準を使用して、媒体特定機能、例えば、位置センササービスにより要求される位置走査機能の選択を可能にすることができる。ＷＬＡＮ６１０は、ＮＩＣ動作基準を使用して、ＩＨＶ提供サービスによって制御されたベンダ特定機能などの、媒体特定動作を選択することができる。ＤＨＣＰ６１２クライアントを使用して、ネットワーク沈黙モード中に、ＩＰアドレスを更新することができ、したがって、この動作中、ＮＩＤ動作基準を保持し、ネットワーク・インターフェイス・デバイス１１２の可用性を保証することができる。ＴＣＰ／ＩＰ６１４は、ＮＩＤ動作基準カウンタを使用して、この動作中に、Ｄ０においてネットワーク・インターフェイス・デバイス１１２を保持し、ネットワーク沈黙モード中に、ＩＰｖ６ステートレスアドレス自動設定６１６をリフレッシュすることができる。ＮＤＩＳ６０２は、アダプタ初期化中、および各ネットワーク・インターフェイス・デバイス１１２が起動信号を生成した際に、一時的（例えば、３秒）ＮＩＣ動作基準を使用することができる。したがって、タイムアウト期限切れによってネットワーク・インターフェイス・デバイス１１２の使用を他のいずれのコンポーネントも要求しない場合、ネットワーク・デバイス・マネージャ・モジュール１２６は、ネットワーク・インターフェイス・デバイス１１２を低電力状態に遷移することができる。

【0067】

図７は、ネットワーク・インターフェイス・デバイスの沈黙遷移を示す例示的実施態様７００である。実施態様７００は、図６のＮＤＩＳ６０２および電力マネージャ７０２ならびにミニポート／バス７０４を備える。ＮＤＩＳ６０２は、ＮＩＤ動作基準カウンタが０になると、この電力遷移動作を実行する。ＮＩＤ沈黙遷移の間、ＮＤＩＳ６０２は、ネットワーク・インターフェイス・デバイス１１２を、電力マネージャ７０２に対してアイドル状態であると報告する可能性があり、デバイスに対してＤｘＩＲＰを要求する前に、確認を待つ。

【0068】

図８は、ネットワーク・インターフェイス・デバイスの動作遷移を示す例示的実施態様８００である。実施態様８００は、図６のＮＤＩＳ６０２および図７の電力マネージャ７０２ならびにミニポート／バス７０４を備える。図示した例において、ＮＤＩＳ６０２は、ＮＩＤ動作基準カウンタが０から１になると、電力遷移動作を実行する。ＮＤＩＳ６０２は、電力マネージャ７０２からデバイス動作状態を要求し、「電力要求コールバック」を待つことができる。このコールバックから、ＮＤＩＳ６０２は、デバイスに対してＤ０ＩＲＰを要求する。Ｄ０ＩＲＰ完了時に、ＮＤＩＳ６０２は、更新電力状態をミニポート／バス７０４ドライバに通信する前に、「動作状態コールバック」を待つ。

【0069】

図９は、システムスリープ遷移を示す例示的実施態様９００である。実施態様９００も、また、図６のＮＤＩＳ６０２および図７の電力マネージャ７０２ならびにミニポート／バス７０４を備える。システムスリープ遷移の間、ＮＤＩＳ６０２は、デバイスに対し、電力マネージャ７０２により、電力フレームワーク管理を一時停止し、ＤｘＩＲＰを要求する前に確認を待つ。

【0070】

図１０は、システム再開遷移を示す例示的実施態様１０００である。実施態様９００も、また、図６のＮＤＩＳ６０２および図７の電力マネージャ７０２ならびにミニポート／バス７０４を備える。システム再開遷移の間、ＮＤＩＳ６０２は、ネットワーク・インターフェイス・デバイス１１２に対し、Ｄ０ＩＲＰを要求し、電力フレームワーク動作を、Ｄ０ＩＲＰ完了時に、電力マネージャ７０２によって再開させる。

【0071】

図１１は、ネットワークトラフィックが完了し、ネットワーク・インターフェイス・デバイスがオペレーティングシステムによって低電力モードに遷移したと判断する、例示的実施態様における手順１１００を示す。本手順の態様は、ハードウェア、ファームウェア、ソフトウェア、またはそれらの組み合わせで実現することができる。本手順は、１つまたは複数のデバイスによって実行される動作を明示するブロックのセットとして示され、各ブロックによる動作を実行するために示される順序に必ずしも限定されない。以下の説明の部分において、図１の環境および図５から図１０のシステムならびに例示的実施態様を参照する。

【0072】

オペレーティングシステムによって、コンピューティングデバイスの１つまたは複数のアプリケーションと関連するネットワークトラフィックが完了したと判断される（ブロック１１０２）。この判断は、さまざまな方法で行うことができる。例えば、ネットワーク・デバイス・マネージャ・モジュール１２６は、アプリケーション１１８、１２０およびネットワーク・インターフェイス・デバイス１１２に関係するアウトバウンドおよびインバウンドトラフィックをモニタすることができる。したがって、ネットワーク・デバイス・マネージャ・モジュール１２６は、回答が要求に対していつもたらされたか、例えば、コールバックがいつ完了したかを判断することができる。このようにして、ネットワーク・デバイス・マネージャ・モジュール１２６は、各動作が、所定の「アイドル」期間を待つことなく、いつ完了したかを判断することができる。

【0073】

本判断に応じて、ネットワーク・インターフェイス・デバイスは、オペレーティングシステムによってネットワーク・インターフェイス・デバイスの電力消費を抑えるためのモードに遷移させる（ブロック１１０４）。前記例から続いて、ネットワーク・デバイス・マネージャ・モジュール１２６は、ネットワークトラフィック５０２が完了したと判断することができ、したがって、ネットワーク・インターフェイス・デバイス１１２を、電力消費を抑えるモード、例えば、低電力モード５０６にすることができる。

【0074】

ネットワーク・デバイス・マネージャ・モジュール１２６は、また、このモードと共に使用するためのさまざまな機能を提供することができる。例えば、ネットワーク・デバイス・マネージャ・モジュール１２６は、ネットワーク・インターフェイス・デバイス１１２に、オペレーティングシステムによって、電力消費を抑えるモードの間、無線アクセスポイントとの接続を維持させることができる（ブロック１１０６）。したがって、この例において、ネットワーク・インターフェイス・デバイス１１２は、すでに述べたように、レイヤ２接続を維持することができる。他の例において、ネットワーク・デバイス・マネージャ・モジュール１２６は、ネットワーク・インターフェイス・デバイス１１２に、オペレーティングシステムによって、電力消費を抑えるモードの間、インターネットプロトコル（ＩＰ）アドレスを維持させることができる（ブロック１１０８）。したがって、この例において、ネットワーク・インターフェイス・デバイス１１２は、ネットワーク・インターフェイス・デバイス１１２のＩＰアドレスをリフレッシュするために、レイヤ３接続を維持することができる。さまざまな他の例もまた、想定される。

【0075】

ネットワーク・インターフェイス・デバイスは、また、事前登録された通知の受信時に起動するよう構成することができる（ブロック１１１０）。例えば、ネットワーク・インターフェイス・デバイス１１２が低電力モード５０６にある場合でさえも、ネットワーク・インターフェイス・デバイス１１２は、通信、例えば、インバウンドパケットを受信するよう構成することができる。これらの通知は、事前登録することができ、特定の通知により、ネットワーク・インターフェイス・デバイス１１２をネットワーク沈黙モードから起動させ、通信を生じさせた特定のエンドポイントを指示するなど、オペレーティングシステム１１６と通信させる。実施例に関連して説明したように、データに格納された特定の４個のタプル（ｔｕｐｌｅ）パターンなどの、さまざまな他の種類の事前登録もまた想定される。

【0076】

図１２は、ネットワーク・インターフェイス・デバイスが、低電力モードの間、アプリケーションに利用不可能にされる、例示的実施態様における手順１２００を示す。本手順の態様は、ハードウェア、ファームウェア、ソフトウェア、またはそれらの組み合わせで実現することができる。本手順は、１つまたは複数のデバイスによって実行される動作を明示するブロックのセットとして示され、各ブロックによる動作を実行するために示される順序に必ずしも限定されない。以下の説明の部分において、図１の環境および図５から図１０のシステムならびに例示的実施態様を参照する。

【0077】

ネットワーク・インターフェイス・デバイスが高電力モードにある場合、オペレーティングシステムによって、ネットワーク・インターフェイス・デバイスが、コンピューティングデバイスの１つまたは複数のアプリケーションに対して利用可能になる（ブロック１２０２）。例えば、ネットワーク・デバイス・マネージャ・モジュール１１２は、データを送受信するために、ネットワーク１１４を使用して、通信のために利用できるように、ネットワークインターフェイス１１２を表示することができる。

【0078】

ネットワーク・インターフェイス・デバイスが低電力モードにある場合、オペレーティングシステムによって、ネットワーク・インターフェイス・デバイスが、コンピューティングデバイスの１つまたは複数のアプリケーションに利用不可能になる（ブロック１２０４）。例えば、ネットワーク・デバイス・マネージャ・モジュール１２６は、アプリケーション１１８、１２０によって必要とされるネットワークトラフィックが完了したという判断に応じるなどの場合に、ネットワーク沈黙モードを実行し、電力消費を抑えることができる。この沈黙モードは、定義された時間を有することができ、イベントに応じるなどにより、終了することができる。この利用不可能性は、アプリケーション１１８、１２０が、この時間の間、ネットワーク・インターフェイス・デバイス１１２を「起動する」ことができないよう、上記した「ブラックホール」技術の使用を含むことができる。

【0079】

ネットワーク・インターフェイス・デバイスが利用不可能である間、他のネットワーク・インターフェイス・デバイスが、１つまたは複数のアプリケーションに対して利用可能になる（ブロック１２０６）。すでに述べたように、コンピューティングデバイス１０２は、複数のネットワーク・インターフェイス・デバイスを備えることができる。それに応じて、ネットワーク・デバイス・マネージャ・モジュール１２６は、ただ１つのネットワーク・インターフェイス・デバイス１１２をインターネット接続のために利用可能にするなど、コンピューティングデバイスのリソースを節約するために、それらのデバイスを、高電力モードまたは低電力モードに置くよう管理することができる。

【0080】

例えば、ネットワーク・デバイス・マネージャ・モジュール１２６は、ルーティング技術を使用して、「不適切な」ネットワーク・インターフェイス・デバイス１１２の不要な起動を防ぐことができる。前記例に続いて、利用不可能にされたネットワーク・インターフェイス・デバイスを使用する通信のために指定された１つまたは複数のアプリケーションから受信したデータが、他のネットワーク・インターフェイス・デバイスに経路付けられる（ブロック１２０８）。例えば、これを用いて、Ｗｉ−Ｆｉデバイスなどの動作状態のネットワーク・インターフェイス・デバイスに自動的に経路付けられる非動作状態であるセルラ・ネットワーク・インターフェイス・デバイスを使用する通信に対し、アプリケーション１１８によって意図されたデータを経路付けることができる。

【0081】

したがって、オペレーティングシステムは、電力消費を抑えるモードにあるネットワーク・インターフェイス・デバイスに、コンピューティングデバイスの１つまたは複数のアプリケーションによるアクセスを制限する技術をサポートするよう構成することができる。さらに、ネットワーク・インターフェイス・デバイスは、特定のエンドポイントからのプッシュ通知などの通知の受信に応答して、そのモードから起動するよう構成される。ネットワーク接続の維持についてのさらなる説明は、以下のセクションに関連して見ることができる。

【0082】

キープ・アライブ・マネージャ・モジュール
図１３は、図１のネットワーク・ブローカ・モジュール１２２のキープ・アライブ・マネージャ・モジュール１２８の例示的動作を示す例示的実施態様におけるシステム１３００の図である。キープ・アライブ・マネージャ・モジュール１２８は、ネットワーク１１４上の通知チャネルを維持するためのネットワーク・ブローカ・モジュール１２２の機能を表す。例えば、キープ・アライブ・マネージャ・モジュール１２８を使用して、アプリケーション１１８、１２０と、エンドポイント１３０６、例えば、ネットワークサービスのサーバとの間の通知チャネル開口を保つために十分な、ネットワーク通信１３０４間の間隔を定義するキープアライブ間隔１３０２を算出することができる。したがって、キープアライブ間隔１３０２は、ネットワーク１１４を介して、例えば、１つまたは複数の通知チャネルを介して、通信の状態を維持するため、通信の周波数を描くよう算出することができる。

【0083】

ネットワーク・ブローカ・モジュール１１２は、さまざまな異なる通知チャネルを管理することができる。例えば、アプリケーション１１８は、電子メール通信をサポートするよう構成することができ、したがって、電子メール・サービス・エンドポイントと相互通信するよう構成することができる。アプリケーション１１８は、また、インスタントメッセージングをサポートするよう構成することができ、したがって、他のエンドポイント（例えば、インスタント・メッセージング・サービスのサーバ）と通信することができる。したがって、単一アプリケーション１１８で、複数の通知チャネルをサポートすることができる。さらに、アプリケーション１１８、１２０は、また、異なる通知チャネルを使用して、同じエンドポイントと通信することができる。したがって、キープ・アライブ・マネージャ・モジュール１２８は、ネットワーク１１４を介する通信を含む、さまざまな異なる通知チャネルを扱うことができる。

【0084】

さらに、キープ・アライブ・マネージャ・モジュール１２８は、さまざまな方法でキープアライブ間隔１３０２を算出することができる。そのような実施態様の１つにおいて、キープアライブ間隔１３０２は、アプリケーション１１８が、例えば、通知チャネルを介して通信するエンドポイント１３０６のサーバタイムアウト間隔に基づき、算出することができる。例えば、サーバタイムアウト間隔は、エンドポイント１３０６と相互通信するよう構成されたアプリケーションによって指定された既知のタイムアウトに基づき、キープ・アライブ・マネージャ・モジュール１２８によって決定することができる。

【0085】

例えば、アプリケーション１１８は、ソーシャル・ネットワーク・サービスなどの、特定のエンドポイントと相互通信するよう構成することができる。したがって、このアプリケーションは、タイムアウトのサーバタイムアウト間隔の「知識」でコード化することができ、アプリケーション１１８は、そのエンドポイントで通知チャネルを維持するよう構成することができ、例えば、通信が送信され、エンドポイント１３０６で状態を維持することができる。したがって、この例において、キープ・アライブ・マネージャ・モジュール１２８は、アプリケーション１１８自身からこの間隔を決定することができる。事前にエンドポイント１３０６のサーバタイムアウト間隔を決定するなど、他の例もまた想定され、（例えば、障害検出および再調整によって）コンピューティングデバイスとエンドポイント１３０６との間のモニタリングされた相互作用などに基づくことができる。

【0086】

他のそのような実施態様において、キープアライブ間隔１３０２は、ネットワーク１１４の中継デバイス１３０８を扱うため、ネットワークタイムアウト間隔を使用して算出することができる。例えば、ネットワーク・インターフェイス・デバイスとエンドポイント１３０６との間のネットワーク接続は、ネットワークアドレス変換デバイス、プロキシ、ファイヤウォール、および無線アクセスポイントなどの、さまざまな中継デバイス１３０８を含むことができる。ネットワークタイムアウト間隔は、さまざまな方法で、キープ・アライブ・マネージャ・モジュール１２８によって決定することができる。

【0087】

例えば、キープ・アライブ・マネージャ・モジュール１２８は、そのような決定に対して利用可能になるテストデバイスなどの、「既知の」もしくは「長く知られる（ｋｎｏｗｎ−ｔｏ−ｂｅ−ｌｏｎｇ）」サーバタイムアウト間隔を有するエンドポイントと、ネットワーク１１４および対応する中継デバイス１３０８を介して接続することができる。キープ・アライブ・マネージャ・モジュール１２８は、この既知のエンドポイントとの接続をモニタリングして、中継デバイス１３０８をいつ「タイムアウトさせるか」を判断することができ、したがって、中継デバイス１３０８のネットワークタイムアウト間隔を決定することができる。このネットワークタイムアウト間隔は、キープアライブ間隔１３０２を算出する際に使用するために、キープ・アライブ・マネージャ・モジュール１２８によって保存することができる。例えば、このネットワークタイムアウト間隔は、ネットワーク・インターフェイス・デバイス１１２がネットワーク１１４にアクセスする特定のネットワークに対して特有のものとして保存することができる。

【0088】

１つまたは複数の実施態様において、キープアライブ間隔１３０２は、エンドポイント１３０６のサーバタイムアウト間隔、中継デバイス１３０８のネットワークタイムアウト間隔、および両方の間隔に基づいて算出することができる。例えば、キープアライブ間隔１３０２は、キープ・アライブ・マネージャ・モジュール１２８によって算出され、通知チャネルを維持する際に、コンピューティングデバイス１０２のリソースを効率的に使用することができる。例えば、キープ・アライブ・マネージャ・モジュール１２８は、ネットワークタイムアウト間隔が１５秒であり、サーバタイムアウト間隔が２０秒であると決定することができる。したがって、キープ・アライブ・マネージャ・モジュール１２８は、１５秒間隔でネットワーク・インターフェイス・デバイス１１２を起動して、エンドポイント１３０６と通信することができるため、エンドポイント１３０６と中継デバイス１３０８とを動作状態に保つことができる。したがって、この例において、キープ・アライブ・マネージャ・モジュール１２８は、１５秒および２０秒間隔でネットワーク・インターフェイス・デバイス１１２を起動することを避けることができるが、どちらのデバイスも状態を維持することができる。

【0089】

したがって、単一ネットワークタイムアウト値を算出することができ、これらの値の最小値（例えば、ベースラインフロア）は、同時発生の「キープアライブ」がいつ送信されるかを描く融合時間を計算するために算出される。したがって、ネットワークタイムアウト間隔は、複数のサーバ接続に適用することができる。

【0090】

さらに、１つまたは複数の実施態様は、失われているネットワーク接続を扱うことができる。ネットワークは、不統一である可能性があり、接続は、時に消失する可能性がある。それが起こると、サーバへの永続接続が断たれる可能性がある。したがって、これらの実施態様は、ネットワークが再び利用可能になるときを自動的に検出する能力を使用することができる。例えば、Ｗｉ−Ｆｉネットワークで、「ネットワーク・リスト・オフロード」を介しておよびオペレーティングシステム自体を介してなどの効果的な方法で、このことは、ハードウェアまたはファームウェアで実行することができる。したがって、オペレーティングシステムは、アプリケーションのこのクラスに、コールバックルーチンを介して、ネットワークの存在を通知することができ、次いで、これらのアプリケーションは、接続、例えば、プッシュ通知サーバへの長期接続を再確立することができる。したがって、融合通知が実行され、複数の通信アプリケーションで通信を再確立することができ、ローカル・コンピューティング・リソースの使用を最適化するため、およびネットワーク・インターフェイス・デバイスのリソースの使用を最適化するために使用することができる。

【0091】

本技術は、また、キープ・アライブ・マネージャ・モジュール１２８によって、アプリケーション１１８、１２０を扱うために使用することができる。例えば、キープ・アライブ・マネージャ・モジュール１２８は、アプリケーション１１８、１２０によって送信される通信をバッチ処理し、通知チャネルを維持するよう構成することができる。したがって、前述のように、キープアライブ間隔１３０２は、コンピューティングデバイス１０２のリソース、例えば、電源１０８を効果的に使用するよう構成することができる。

【0092】

例えば、キープ・アライブ・マネージャ・モジュール１２８は、アプリケーション１１８が、１０秒間隔で「キープアライブ」通信を開始するよう構成されること、およびアプリケーション１２０が、８秒間隔で「キープアライブ」通信を開始するよう構成されることを決定することができる。したがって、キープ・アライブ・マネージャ・モジュール１２８は、通信を行うために、アプリケーション１１８、１２０の両方に対して、８秒間隔で、ネットワーク・インターフェイス・デバイス１１２を起動することができる。このようにして、キープ・アライブ・マネージャ・モジュール１２８は、さまざまなエンドポイント１３０６への通知チャネルに対して「キープアライブ」を開始したアプリケーション１１８、１２０を融合し、電力および他のリソースを節約することができる。したがって、キープ・アライブ・マネージャ・モジュール１２８は、さまざまなファクタでキープアライブ間隔１３０２を基にすることができ、キープアライブ間隔１３０２を調整することもでき、さらに、その説明は、以下の図面に関連して見ることができる。

【0093】

図１４は、図１３のキープアライブ間隔を算出および調整する例示的実施態様を示す例示的実施態様におけるシステム１４００の図である。すでに述べたように、中間ネットワークデバイスによる通知チャネルの維持は、ネットワーク１１４にアクセスするアプリケーション１１８、１２０の問題とすることができる。従来技術は、状態を保護するために、パケットを送信／受信するための間隔を定義したハードコーディングされた値を必要とした。しかしながら、本明細書で説明する技術では、動的キープアライブ間隔が、例えば、所与の遠隔接続先へのテスト接続を使用して、コンピューティングデバイス１０２自体でのアプリケーション１１８、１２０の実行を通じて、および、ネットワークとサーバタイムアウト間隔の使用を通じてなどにより算出される。

【0094】

図１４のシステム１４００は、図１３のキープアライブ間隔１３０２を調整する一例を示す。この例において、初期に算出されたキープアライブ間隔は、Ｔ＝Ｔ（ｍａｘ）として、初期段階で設定される（ブロック１４０２）。次いで、基準ポイントは、現在のＴより低くなるよう試みられる（ブロック１４０４）。これは、Ｔ（ｍｉｎ）のＷ（ｍｉｎ）のポーリングを含むことができ、ここでのＷは、ポーリング間の再接続時間を表す（ブロック１４０６）。これは、また、ＴがＶずつインクリメントされ、Ｔ（ｍａｘ）でキャップ（ｃａｐ）された積極的チューニングを含むことができ（ブロック１４０８）、ここで、Ｖは、積極的チューニングのインクリメントを表す。システム１４００は、また、値がＶ／Ｙずつインクリメントされる微細チューニングを含むことができ、ここで、Ｙは、積極的インクリメントの１／Ｙを意味する。これらの値は、Ｔ−検出値およびＴ（ＬＫＧ）が絶対時間である定常状態を判断するために活用することができる。図において、Ｚは実行したリトライの数を表し、ネットワークエラーに対処するために設定することができ、Ｘは、成功したキープアライブ（ＫＡ）の数を表す。キープ・アライブ・マネージャ・モジュール１２８の動作についてのさらなる説明は、以下の手順に関連して見ることができる。

【0095】

図１５は、キープアライブ間隔を算出して、１つまたは複数の通知チャネルを維持するために使用する例示的実施態様における手順１５００である。本手順の態様は、ハードウェア、ファームウェア、ソフトウェア、またはそれらの組み合わせで実現することができる。本手順は、１つまたは複数のデバイスによって実行される動作を明示するブロックのセットとして示され、各ブロックによる動作を実行するために示される順序に必ずしも限定されない。以下の説明の部分において、図１の環境および図１３から図１４のシステムならびに例示的実施態様を参照する。

【0096】

キープアライブ間隔は、コンピューティングデバイスのオペレーティングシステムによって算出される（ブロック１５０２）。図１３および図１４に関して説明したように、キープアライブ間隔は、ネットワークタイムアウト間隔およびサーバタイムアウト間隔に基づく、および複数のアプリケーション１１８、１２０に対するキープアライブ通信スケジューリングに基づくなど、さまざまな方法で算出することができる。

【0097】

キープアライブ間隔を使用して、コンピューティングデバイスの１つまたは複数のアプリケーションとネットワークとの間の、１つまたは複数の通知チャネルを維持する（ブロック１５０４）。例えば、キープ・アライブ・マネージャ・モジュール１２８は、ネットワーク通信をモニタして、通知チャネルを介して、データを送信および受信することができる。１つまたは複数の通知チャネルが、ネットワーク通信１３０４と関係することなく、キープアライブ間隔に達した場合、キープ・アライブ・マネージャ・モジュール１２８は、各エンドポイント１３０６と通信することによって、チャネルを維持することができる。

【0098】

キープアライブ間隔は、また、オペレーティングシステムによる、キープアライブ間隔のモニタリングされた使用に基づき、調整することができる（ブロック１５０６）。例えば、キープ・アライブ・マネージャ・モジュール１２８は、通知チャネルが、ネットワークもしくはサービスタイムアウト間隔に達したために機能しなくなったと判断することができる。次いで、キープ・アライブ・マネージャ・モジュール１２８は、キープアライブ間隔１３０２を「少なく」調整し（例えば、間隔によって定義された時間量を減らす）、チャネルがタイムアウトする時間の観測された量より少ない時間量に調整することができる。当然、図１４に関連して説明したように、キープアライブ間隔１３０２を増やすなど、他の例もまた想定される。

【0099】

図１６は、キープアライブ間隔を算出して、アプリケーションからキープアライブ通信をバッチ処理する例示的実施態様における手順１６００である。本手順の態様は、ハードウェア、ファームウェア、ソフトウェア、またはそれらの組み合わせで実現することができる。本手順は、１つまたは複数のデバイスによって実行される動作を明示するブロックのセットとして示され、各ブロックによる動作を実行するために示される順序に必ずしも限定されない。以下の説明の部分において、図１の環境および図１３から図１４のシステムならびに例示的実施態様を参照する。

【0100】

ネットワークを介して各エンドポイントを有する通知チャネルを維持するよう指定された１つまたは複数のサーバタイムアウト間隔について、コンピューティングデバイスで実行可能な複数のアプリケーションのそれぞれに対して判断する（ブロック１６０２）。例えば、キープ・アライブ・マネージャ・モジュール１２８は、各エンドポイントを有する通知チャネルを維持するため、各アプリケーションによって使用されるサーバタイムアウト間隔を判断するために、アプリケーション１１８、１２０を試験することができる。

【0101】

キープアライブ間隔は、複数のアプリケーションのそれぞれに対する１つまたは複数のサーバタイムアウト間隔から算出される（ブロック１６０４）。図１３に関連して説明したように、キープ・アライブ・マネージャ・モジュール１２８は、さまざまなサーバタイムアウト間隔に対するリソース使用の効率に基づいて、キープアライブ間隔１３０２を決定することができる。次いで、キープアライブ間隔を使用して、通知チャネルを維持するために指定されたネットワーク・インターフェイス・デバイスを起動することができる（ブロック１６０６）。例えば、キープ・アライブ・マネージャ・モジュール１２８は、ネットワーク・インターフェイス・デバイス１１２が低電力モードにある間、ネットワーク通信１３０４が、通信チャネルのいずれに対しても発生しなかったと判断することができる。それに応じて、キープ・アライブ・マネージャ・モジュール１２８は、ネットワーク・インターフェイス・デバイス１１２を起動して、キープアライブ間隔１３０２で各エンドポイント１３０６と通信し、コンピューティングデバイス１０２のリソースを効率的に使用することができる。さまざまな他の例もまた、上記のように、および以下の実施例に関連してさらに説明するように、想定される。

【0102】

実施例
図１７および図１８は、図１のネットワーク接続ブローカ１２２の実施例を示すシステム１７００、１８００である。図１に関連してすでに述べたように、システム・オン・チップ型デバイスにおける「接続状態スタンバイ（ｃｏｎｎｅｃｔｅｄ ｓｔａｎｄｂｙ）」と呼ばれるシステム状態のサポートは、「常にオンラインで、常に接続状態にある」（ＡＯＡＣ）ユーザ体験を可能にするための機会を提供することができる。例えば、アプリケーションは、「インフォーカス」でない場合、例えば、前景にない場合、一時停止することができる。結果として、ネットワーク１１４およびネットワーク・インターフェイス・デバイス１１２は、「ネットワーク沈黙モード」（ｎｅｔｑｍ）に入る可能性がある。このモードでは、オペレーティングシステム１１６は、Ｌ２接続およびＬ３識別情報が維持されることを保証する間、デバイスからの発信パケットを防ぐことができる。コンポーネントからの指示は、沈黙モードを出るための電力依存コーディネータ（ＰＤＣ）と称された。ネットワーク１１４接続と関係するタスクの完了時に、ネットワーク・ブローカ・モジュール１２２は、ネットワーク・インターフェイス・デバイス１１２を、再び、ネットワーク沈黙モードにして、ＰＤＣが出口イベントを示すまで、この状態のままでいさせることができる。

【0103】

この設計を含むシステム１７００の概要が、図１７に示される。本図は、チャット・アプリケーション１７０２に対する接続および他のブックキーピングを扱うよう構成された、軽量チャットスタブ１７０４を含む、チャットアプリケーション（例えば、ネットワーク１１４を介してチャットするために構成されたもの）を示す。チャットアプリケーション１７０２は、また、比較的「重量のある」チャットＵＩ１７０６を備え、アプリケーション１７０２の一部は、チャットスタブ１７０４によって表される軽量接続スタブから分離される。これは、アプリケーション１７０２の機能を誘導するために使用することができるさまざまな技術の１つである。

【0104】

プロセス・ライフタイム・マネージャ１７０８は、また、アプリケーション１７０２のライフサイクルを管理するための機能を示すものとして図示される。言い換えると、アプリケーション１７０２が、ユーザフォーカスから離れてタスクを課されると（例えば、背景へ移動）、ＰＬＭ１７０８は、チャットＵＩ１７０６を終了し、メモリ内でチャットスタブ１７０４を一時停止することができる。

【0105】

システム１７００は、上記したように、関心イベントがアプリケーション１７０２に対して発生すると、チャットスタブ１７０４をリハイドレートするための機構を備える、カーネル・ブローカ・インフラストラクチャを活用することができる。このようにして、コンピューティングデバイスのリソースは節約することができ、例えば、コンピューティングデバイス１０２のＣＰＵは、沈黙モードに入り、入力メッセージが起動を誘引するまで、およびカーネルブローカが周期的動作のためにシステムを起動するまでなど、それまでこのモードに留まることができる。

【0106】

ネットワーク接続ブローカ（ＮＣＢ）１７１０（図１のネットワーク・ブローカ・モジュール１２２に対応してもよいし、しなくてもよい）は、起動パターンマネージャ１７１２およびキープ・アライブ・マネージャ１７１４として表される、さまざまな機能を使用することができる。起動パターンマネージャ（ＷＰＭ）１７１２は、アプリケーション１７０２が、ネットワークイベント時に「リハイドレート」する、例えば、特定パターンの検出時に起動することができることを保証するよう構成される。

【0107】

キープ・アライブ・マネージャ１７１４は、通知チャネルが、例えば、プッシュ通知の入力がクラウドサービスから到達できるよう、アプリケーション１７０２に対して維持されることを保証するよう構成される。例えば、アプリケーション１７０２は、作業アイテムを図１８のＢＩ１８０２に登録することができ、それにより、アプリケーション１７０２が、キープアライブ動作に関心があることをオペレーティングシステム１１６に知らせることができる。次いで、オペレーティングシステム１１６は、出力パケット動作が、事前定義された時間の間、例えば、数秒の間、許可されることを指示するため、コールバックを登録したアプリケーション１７０２を起動する、適切な融合キープアライブ間隔を判断することができる。ＢＩ１８０２は、ＣＰＵおよびメモリリソースの点から「サンドボックス」作業アイテムとすることができる。このことは、アプリケーション１７０２に、各エンドポイント（例えば、「クラウド内の」サービス）に、周期的な「キープアライブ」を実行させ、可到達性を維持することができる。このことは、また、「キープアライブ」の過多によるリソースの非効率的な使用に対して、アプリケーションの能力を限定するために使用することができる。

【0108】

オペレーティングシステムは、通知サービス（例えば、Ｗｉｎｄｏｗｓ（登録商標）通知サービス）と共に使用して、すでに述べたように、動的キープアライブ間隔を決定することができる。例えば、動的キープアライブ間隔は、４分間隔で保守的に開始し、接続がなお維持される値にインクリメントする間隔によって定義される時間量を倍にする「指数バックオフ」として実施することができる。通知サービスは、この目的のためにテスト接続を使用して、動的間隔を決定することができる。１つまたは複数の実施態様において、他の実施態様もまた想定されるが、キープ・アライブ・マネージャ１７１４は、接続スタンバイもしくはＡｃｔｉｖｅ／ＯＮになるアプリケーション状態もしくはシステムを区別しない。

【0109】

起動パターンマネージャ１７１２は、ネットワーク・インターフェイス・カード（ＮＩＣ）１７１６などの、ネットワーク・インターフェイス・デバイスに対する適切な起動パターンを組み込むための機能を表す。起動パターンマネージャ１７１２は、ＮＩＣ１７１６を、ネットワーク沈黙モードエントリー時に、「ウェイクオンＬＡＮ（“Ｗａｋｅ ｏｎ ＬＡＮ”）」モードに移行させることができる。例えば、ＮＩＣ１７１６は、起動パターンのセットに一致した場合、ＮＩＣ１７１６が着信パケットを受け入れ、送達するよう構成された、Ｄ３モードに遷移することができる。そうであれば、ＮＩＣ１７１６を、動作状態に遷移させることができる。起動パターンは、各起動可能接続に対する“＜ＳｒｃＡｄｄｒ，ＤｓｔＡｄｄｒ，ＳｒｃＰｏｒｔ，ＤｓｔＰｏｒｔ，ＴｒａｎｓｐｏｒｔＰｒｏｔｏｃｏｌ＞”などの、さまざまなソースから送達することができる。１つまたは複数の実施態様において、ＮＩＣ１７１６は、そのようなパケットのロスが、ＶｏＩＰなどの特徴をサポートするアプリケーションに対するリアルタイム応答に影響を及ぼす可能性があるため、（破棄／削除に対立して）プロトコルスタックに起動させる着信パケットを通過させる。

【0110】

ランタイムＡＰＩサーフェスもまた、オペレーティングシステム１１６によって提供されるキープアライブおよび遠隔起動機能を利用するよう構成された、アプリケーションに表示することができる。ライブラリを使用して、アプリケーションで、以下を含むさまざまな機能を実行することができる。
・通知チャネルの作成指示（例えば、ＢｅｇｉｎＳｅｔｕｐ）
・通知チャネルのセットアップ完了指示（例えば、ＥｎｄＳｅｔｕｐ）
・分単位で所望のキープアライブ間隔を設定（例えば、ＳｅｒｖｅｒＫｅｅｐＡｌｉｖｅＩｎｔｅｒｖａｌＴｉｍｅ）
・キープ・アライブ・イベントおよび遠隔起動イベントに対するＢａｃｋｇｒｏｕｎｄ Ｔａｓｋハンドラの登録
・キープアライブ間隔が十分ではなかったことをシステムに指示（例えば、ＤｅｃｒｅａｓｅＫｅｅｐＡｌｉｖｅＩｎｔｅｒｖａｌ）

【0111】

通知システムは、断続的に実行しているｉｎｂｏｘコンポーネントとして実現することができるので、キープ・アライブ・イベントに対し実行される起動アイテムコードを、アクティベーションプロキシ方法によってトリガすることができる。アクティベーションプロキシは、ランタイムライブラリの内部に隠すことができ、プライベートＡＰＩを通じてアクティベートすることができる。ＮＣＢサービスチェックを使用して、処理の保全性レベルをチェックすることができる。プロキシは、ＷＮＦイベントを作成し、ＷＮＦイベントメッセージに対するＷＮＦチャネルをリッスンする。通知サービスのためのバックグラウンド・タスク・ハンドラは、（ＢｉＳｉｇｎａｌＥｖｅｎｔを呼び出すＮＣＢサービス／ＴＣＰＩＰ．ｓｙｓの結果として）ＢＩがＷＮＦイベントメッセージを発行した場合、プロキシによって起動することができる。

【0112】

ランタイムＡＰＩライブラリは、ＬＲＰＣを使用して、ＩＰヘルパーサービス内でホストされたＮＣＢサブサービス（Ｎｃｂｓｖｃ．ｄｌｌ）と通信し、ＮＣＢにキープアライブ時間を提供し、キープアライブおよび起動イベントのためのイベントネームを受信することができる。次いで、ランタイムＡＰＩは、ブローカインフラストラクチャＡＰＩを呼び出し、アプリケーション提供のコールバックと、ブローカインフラストラクチャ提供のイベントとを関連付けることができる。

【0113】

図１８のシステム１８００は、オペレーティングシステム１１６の残りの部分に伝えるためにＮＣＢサービス１８０６によって使用される実際の通信インターフェイスを隔離するよう構成された、ＮＣＢレジスタ１８０４を備える。例えば、ランタイムＡＰＩによって使用されるＲＰＣは、ＮＣＢレジスタ内で隔離することができる。レジスタは、ＲＰＣサーバエンドポイントを開放し、アプリケーションをリッスンすることができる。アプリケーションは、このＲＰＣエンドポイントに接続するため、上記したランタイムライブラリを使用することができる。

【0114】

同様に、実際のＢＩ１８０２ＡＰＩアクセスは、図示したように、ＮＣＢレジスタ１８０４の内部に隠すことができる。これにより、キープ・アライブ・マネージャ１７１４を、アーキテクチャ変更から隔離することができる。ＮＣＢレジスタ１８０４は、ＢＩ１８０２ＡＰＩを呼び出し、「キープアライブ」および「起動」イベントを作成することができる。ＮＣＢレジスタ１８０４の他の部分は、ＷＰＭ１８０８と通信することに関係し得る。

【0115】

キープ・アライブ・プロバイダ・インターフェイス１８１０は、ＷＮＳを、キープ・アライブ間隔プロバイダとして登録することを可能にするよう構成され、ＬＲＰＣを使用して、ＷＮＳと通信することができる。ＷＮＳは、キープ・アライブ・プロバイダ・インターフェイス１８１０によって登録されたコールバックを使用して、キープアライブ間隔推定値を提供することができる。

【0116】

キープ・アライブ・プロバイダ・インターフェイス１８１０は、ＮＬＭキャッシュライブラリ１８１２内に、ネットワーク単位（ＮＬＭ ＩＤ）を基準として、推定値をキャッシュすることができる。ＮＬＭキャッシュは、キープ・アライブ・プロバイダ・インターフェイスとＤＡサイトマネージャとの間で共通とすることができるライブラリを通じてアクセスすることができる。

【0117】

キープ・アライブ・マネージャ１７１４は、キープ・アライブ・プロバイダからキープアライブ間隔推定値を要求するよう構成することができる。タイマ（融合させてもよい）は、“ＳｅｔＴｈｒｅａｄＰｏｏｌＴｉｍｅｒ”ＡＰＩを使用して作成することができる。時間は、Ｔ＿ＷＮＳおよびＴ＿ＡＰＰの最小値として設定することができる。アプリケーションによって要求されたキープアライブ間隔である。

【0118】

キープ・アライブ・タイマが切れた場合、キープ・アライブ・マネージャ１７１４は、ＮＣＢレジスタ１８０４を呼び出すことによって、キープ・アライブ・イベントを報知することができる。次いで、ＮＣＢレジスタ１８０４は、ＢＩ１８０２ＡＰＩを呼び出し、スケジュールされる作業アイテムをトリガすることができる。

【0119】

アプリケーションは、提供された間隔が非常に長かったというヒントをＮＣＢに提供することができる。このことは、アプリケーションＩＤおよび通知チャネルＩＤと共に使用され、上記したＮＬＭキャッシュライブラリ１８１２を使用して、ネットワーク単位を基準として、再びキャッシュに格納することができる。

【0120】

通知チャネルを識別するためのモデルは、処理（ループバックを除く）毎にそれぞれ確立されたＴＣＰ接続が、ＮＣＢによる通知チャネルとして扱われる間、処理全体のタイムスパンを表す“Ｓｔａｒｔ／Ｄｏｎｅ”モデルに基づくことができる。しかしながら、Ｓｔａｒｔ／Ｄｏｎｅタイムスパンは、１つの“ＮＣＣｏｎｔｅｘｔ”と一括して称される、そのスパンの間に生成される各接続に適用する、パラメータの単一セットを有する。典型的には、ＮＣＣｏｎｔｅｘｔとＴＣＰ接続との間の１対１の関係が発生することに留意されたい。しかしながら、Ｓｔａｒｔ／Ｄｏｎｅモデルは、この関係を保証しないため、この設計は、単一ＮＣＣｏｎｔｅｘｔスパンに対応する複数ＴＣＰ接続が存在することができるという仮定のもとで、動作することができる。このスパンは、処理ＩＤ、レジスタによって作成ならびに使用されるオペーク（ｏｐａｑｕｅ）ＮＣＣｏｎｔｅｘｔＩＤ（イベント報知中にＢＩに通される、したがって、ａｐｐにとって有意である）、オプションのオペーク通知チャネルＩＤ、およびオプションの遠隔起動ブローカイベントを含むタプルによって識別することができる。

【0121】

ＮＣＢレジスタ１８０４は、ＷＰＭに、Ｓｔａｒｔ（ＰＩＤ、ＮＣＣｏｎｔｅｘｔＩＤ、ＡｐｐＮＣＩＤ、ＢｒｏｋｅｒｅｄＥｖｅｎｔ）およびＤｏｎｅ（）（例えば、ＮＣＣｏｎｔｅｘｔを設定、および消去）を指示するよう構成することができる。ＮＣＢレジスタ１８０４は、また、実際のアプリケーション処理ＰＩＤが、Ｓｔａｒｔ／Ｄｏｎｅタイムスパン中に、完全な形で残る（例えば、リサイクルされない）ことを保証することができる。ＮＣＢレジスタ１８０４は、クライアント処理で参照するＲＰＣ ＡＰＩを使用することによって、これを達成することができる。

【0122】

ＮＣＢは、ＮＳＩ１８１４を介して、ＷＰＭ１８０８にＳｔａｒｔおよびＤｏｎｅを指示することができる。ＷＰＭは、この目的のために、（ポート予約ＮＳＩオブジェクトと同様とすることができる）ＩＮＥＴ ＮＳＩオブジェクトを示すことができる。ＮＣＢは、ＮＳＩセットコマンドを使用して、アクティブＮＣＣｏｎｔｅｘｔ（例えば、Ｓｔａｒｔ）を設定、およびアクティブＮＣＣｏｎｔｅｘｔ（例えば、Ｄｏｎｅ）を消去することができる。１つまたは複数の実施態様において、所与の時点で、所与の処理に対して、単一のアクティブＮＣＣｏｎｔｅｘｔがある。

【0123】

所与の処理によって確立されたＴＣＰ接続は、その処理に対して、（存在するならば）現在アクティブなＮＣＣｏｎｔｅｘｔを引き継ぐことができる。ＮＣＣｏｎｔｅｘｔが引き継がれると、引き継いでいるＴＣＰ接続にアタッチされたままにすることができる。ＮＣＢが（例えば、以前アクティブだったものを消去した後で）処理のために新しいアクティブなＮＣＣｏｎｔｅｘｔを設定すると、新しい接続が新しいＮＣＣｏｎｔｅｘｔを引き継ぐことができ、以前のＮＣＣｏｎｔｅｘｔを引き継いだ接続は、影響を受けないままにすることができる。（１つまたは複数のＴＣＰ接続によって）引き継がれたＮＣＣｏｎｔｅｘｔは、ＮＳＩ１８１４を使用することによっても、ＮＣＢサービス１８０６によって消去することができる。ＮＣＣｏｎｔｅｘｔが消去された場合、ＷＰＭ１８０８は、関連する遠隔起動ブレーカ・イベントを報知することを停止することができる（だが、組み込まれた起動パターンは、通信が切断されるまで、そのまま残る）。

【0124】

ＷＰＭ１８０８は、ＮＣＢサービス１８０６によって制御された、いくつかの処理毎の状態（例えば、アクティブな、引き継がれたＮＣＣｏｎｔｅｘｔ）の経過を追うことができるため、アプリケーション終了として状態（ＮＣＣｏｎｔｅｘｔ）を適切にクリーンアップするＮＣＢサービス１８０６に依存することがある。しかしながら、ＮＣＢサービス１８０６処理は、異常にクラッシュ／終了するかもしれない可能性がある。適切なクリーンアップを実行するために、ＷＰＭ１８０８は、ＴＣＰソケット（バインドおよび接続されない）を作成し、ＮＣＢ制御ソケットとしてマークするため、ソケットでプライベート・オプションを設定するＮＣＢによって、ＮＣＢサービス処理終了の指示を受信することができる。オブジェクトマネージャは、処理が終了すると、（ソケットを含む）ハンドルを適切に閉じるので、ソケット・ハンドル・クロージャは、ＴＣＰのエンドポイント・クローズ・ルーチンを起動させる。次いで、ＴＣＰは、ＮＣＢ制御ソケットを閉じる際に、ＮＣＣｏｎｔｅｘｔのそれぞれをクリーンアップすることができる。

【0125】

上記したように、（ｔｃｐｉｐ．ｓｙｓにおけるＴＣＰモジュールで実現することができる）起動パターン・マネージャ（ＷＰＭ）１８０８は、ＮＣＣｏｎｔｅｘｔの経過を追うよう構成することができる。ＴＣＰは、処理のテーブルおよびＮＣＢサービス１８０６によって設定された関連ＮＣＣｏｎｔｅｘｔを保つことができる。１つまたは複数の実施態様において、所与の処理に対して、１つまたは０の「アクティブな」ＮＣＣｏｎｔｅｘｔがあり、所与の処理に対して、１つまたは複数の「引き継がれた」ＮＣＣｏｎｔｅｘｔが存在することができる。ＴＣＰは、ＮＣＢサービスが実行されている単一システムアカウントが、ＮＣＣｏｎｔｅｘｔを設定／消去することができるよう構成することができる。

【0126】

１つまたは複数の実施態様において、ＮＣＣｏｎｔｅｘｔは、「アクティブ」であるための１つの基準カウント、および各引き継ぎ接続のための１つの基準カウントを有する。すなわち、ＮＣＣｏｎｔｅｘｔは、アクティブではなく、接続によって引き継がれてもいなかった場合、削除することができる。

【0127】

接続がＮＣＣｏｎｔｅｘｔを引き継いだ場合、ＷＰＭ１８０８は、ＮＩＣが起動パターンをサポートする場合、起動パターン組み込みのためのＮＳＩ１８１４方法を介して、ネットワーク・インターフェイス・デバイスまで、接続の４個のタプルから作られる起動パターンを組み込むことができる。ＷＰＭ１８０８は、起動パターンが、各アクティブＮＣＣｏｎｔｅｘｔに対する所与の接続に対して、良好に組み込まれなかったかどうかの経過を追うことができる。アクティブＮＣＣｏｎｔｅｘｔが、“Ｄｏｎｅ”コール中にＮＣＢサービスによって消去される前に、ＮＣＢサービス１８０６は、そのＮＣＣｏｎｔｅｘｔに対してＮＳＩｇｅｔを発行し、この起動パターン取り出し状態を照会し、その情報（例えば、システムが、そのＮＣＣｏｎｔｅｘｔと関連した接続に対する起動パターンの組み込みに失敗したかどうか）を、アプリケーションに戻すことができる。

【0128】

ブローカ遠隔起動イベントでＮＣＣｏｎｔｅｘｔを引き継いだ各ＴＣＰ接続に対し、ＴＣＰは、データ指示（例えば、アップコールまたは受信完了）が、入力データのため、その接続で、ＴＣＰによって作られた場合はいつでも、ブローカ遠隔起動イベントを報知することができる。ＴＣＰが遠隔起動イベントを報知すると、遠隔起動イベントがＮＣＢサービス１８０６によってリセットされるまで、そのＮＣＣｏｎｔｅｘｔでのさらなる報知を無効にする（例えば、取り除く）ことができる。ＮＣＢサービス１８０６は、アプリケーションの遠隔起動コールバックが、コールバックを呼び出したＮＣＢルーチンに制御を返すと、遠隔起動イベントをリセットする。

【0129】

ＮＬで扱うＳＩＯ＿ＡＤＤＲＥＳＳ＿ＬＩＳＴ＿ＳＯＲＴ ｉｏｃｔｌは、また、その処理に対するアクティブＮＣＣｏｎｔｅｘｔが存在する間、Ｉｏｃｔｌが処理によって発行されているかどうかを意識するよう変更することができ、そうである場合、ソートロジックは、トンネルインターフェイスより、ネイティブインターフェイス上のアドレスを選ぶことができる。

【0130】

ＷＰＭ１８０８は、また、ルータによってアドバタイズされたＩＰｖ６サブネット・プレフィックスを使用することによって形成されるＩＰｖ６アドレスに対する残りの有効なライフタイムを追跡するために、タイマを保つことができる。ルータ・アドバタイズメントが、起動可能低電力状態でＮＩＣによって失われた可能性のある場合、ＩＰｖ６プレフィックス・タイムアウトは、タイムアウト発生前に、明示的ルータ要請を介してリフレッシュすることができ、そうでなければ、Ｌ３識別情報は、場合によっては、確実には保護されない可能性がある。ＷＰＭ１８０８は、ＮＤＩＳ ＡＰＩを使用して、ＮＩＣが「留まる」（例えば、システム内の何かによって保持される任意のＮＩＣ動作基準を有さないため、Ｄ３に移らない）ことを保証するために、ルータ要請を実施することができる、ネットワーク・インターフェイスで「ＮＩＣ動作基準」を取得することができる。

【0131】

例示的システムおよびデバイス
図１９は、図１を参照して説明したようなコンピューティングデバイス１０２を含む例示的システム１９００を示す。例示的システム１９００は、パーソナルコンピュータ（ＰＣ）、テレビジョンデバイス、及び/又はモバイル・デバイスでアプリケーションを実行する場合、シームレスなユーザ体験のためのユビキタス環境を可能にする。サービスおよびアプリケーションは、アプリケーションを使用しながら、ビデオゲームをプレイしながら、およびビデオを見ながらなどの間に、あるデバイスから次のデバイスへ遷移する場合に、ユーザ体験を共通にするために、３つすべての環境で実質的に同様に動作する。

【0132】

例示的システム１９００において、複数のデバイスが、中央コンピューティングデバイスを通じて、相互接続される。中央コンピューティングデバイスは、複数のデバイスに対してローカルとすることができ、または、複数のデバイスから遠隔に設置することができる。一実施形態において、中央コンピューティングデバイスは、ネットワーク、インターネット、または他のデータ通信リンクを通じて複数のデバイスに接続された１つまたは複数のサーバコンピュータのクラウドとしてもよい。一実施形態において、この相互接続アーキテクチャは、複数のデバイス間で配信される機能が、複数のデバイスのユーザに共通でシームレスな体験を提供することを可能にする。複数のデバイスのそれぞれは、異なる物理的要件および能力を有することができ、中央コンピューティングデバイスは、プラットフォームを使用して、デバイスに適合して、さらにすべてのデバイスに共通する体験をデバイスに配信することを可能にする。一実施形態において、ターゲットデバイスのクラスが作成され、体験は、デバイスの汎用クラスに適合される。デバイスのクラスは、物理的特徴、使用の種類、またはデバイスの他の共通特性によって定義してもよい。

【0133】

さまざまな実施態様において、コンピューティングデバイス１０２は、コンピュータ１９０２、モバイル１９０４、およびテレビジョン１９０６などのさまざまな異なる構成を使用すると仮定することができる。これら構成のそれぞれは、一般に異なる構成および性能を有する可能性があるデバイスを備え、したがって、コンピューティングデバイス１０２は、異なるデバイス・クラスの１つまたは複数に従って構成することができる。例えば、コンピューティングデバイス１０２は、パーソナルコンピュータ、デスクトップコンピュータ、マルチスクリーンコンピュータ、ラップトップコンピュータ、およびネットブックなどを含むデバイスのコンピュータ１９０２クラスとして実現することができる。

【0134】

コンピューティングデバイス１０２は、また、携帯電話、ポータブル音楽プレイヤ、ポータブル・ゲーム・デバイス、タブレットコンピュータ、およびマルチスクリーンコンピュータなどのモバイル・デバイスを含むデバイスのモバイル１９０４クラスとして実現することができる。コンピューティングデバイス１０２は、また、カジュアルな視聴環境における一般的により大型なスクリーンを有するか、または接続されたデバイスを含むデバイスのテレビジョン１９０６クラスとして実現することができる。それらのデバイスは、テレビジョン、セット・トップ・ボックス、およびゲーム機などを含む。本明細書で説明される技術は、コンピューティングデバイス１０２のこれらのさまざまな構成によってサポートすることができ、本明細書で説明される技術の具体例に限定されない。これは、コンピューティングデバイス１０２上のネットワーク・ブローカ・モジュール１２２、起動パターン・マネージャ・モジュール１２４、ネットワーク・デバイス・マネージャ・モジュール１２６、およびキープ・アライブ・マネージャ・モジュール１２８を内蔵して使用することにより示される。この機能のすべてまたは一部は、また、以下に記載されるように、「クラウド上」に分散してもよい。

【0135】

クラウド１９０８は、コンテンツ・サービス１９１２のためのプラットフォーム１９１０を含む、及び/又はプラットフォーム１９１０を表す。プラットフォーム１９１０は、クラウド１９０８のハードウェア（例えば、サーバ）およびソフトウェア・リソースの基礎をなす機能を抽出する。コンテンツ・サービス１９１２は、コンピュータ・プロセッシングがコンピューティングデバイス１０２から離れたサーバで実行される間、使用することが可能であるアプリケーション及び/又はデータを含むことができる。コンテンツ・サービス１９１２は、インターネット上の、及び/又は、セルラもしくはＷｉ−Ｆｉネットワークなどの加入者ネットワークを通じてのサービスとして提供することができる。

【0136】

プラットフォーム１９１０は、コンピューティングデバイス１０２を他のコンピューティングデバイスと接続するためのリソースおよび機能を抽出することができる。プラットフォーム１９１０は、また、リソースのスケーリングを抽出して、プラットフォーム１９１０を介して実現されるコンテンツ・サービス１９１２に対して生じる要求に対応するスケールのレベルを提供するよう動作することができる。それに応じて、相互接続されたデバイスの実施形態において、本明細書で説明する機能に関する機能の実施態様は、システム１９００全体に分散してもよい。例えば、本機能は、コンピューティングデバイス１０２で、およびクラウド１９０８の機能を抽出するプラットフォーム１９１０を介して、部分的に実現することができる。

【0137】

図２０は、本明細書で説明する技術の実施形態を実現するための図１および図１９を参照して説明したような任意の種類のコンピューティングデバイスとして実現することが可能な例示的デバイス２０００のさまざまなコンポーネントを示す。デバイス２０００は、デバイス・データ２００４（例えば、受信データ、受信中のデータ、一斉送信のためにスケジュールされたデータ、データのデータ・パケットなど）の有線及び/又は無線通信を可能にする通信デバイス２００２を含む。デバイス・データ２００４または他のデバイス・コンテンツは、デバイス、デバイスに格納されたメディアコンテンツ、及び/又はデバイスのユーザと関連した情報の構成設定を含むことができる。デバイス２０００に格納されたメディアコンテンツは、任意の種類のオーディオ、ビデオ、及び/又は画像データを含むことができる。デバイス２０００は、ユーザ選択可能入力、メッセージ、音楽、テレビ・メディア・コンテンツ、録音されたビデオコンテンツ、および任意のコンテンツ及び/又はデータ・ソースから受信した任意の他の種類のオーディオ、ビデオ及び/又は画像データなどの、任意の種類のデータ、メディアコンテンツ、及び/又は入力を受信することが可能な１つまたは複数のデータ入力２００６を備える。

【0138】

デバイス２０００は、また、シリアル及び/又はパラレル・インターフェイス、無線インターフェイス、任意の種類のネットワークインターフェイス、モデムの任意の１つまたは複数として、および任意の他の種類の通信インターフェイスとして実現することが可能な通信インターフェイス２００８を含む。通信インターフェイス２００８は、デバイス２０００と、他の電子的デバイス、コンピューティングデバイス、ならびに通信デバイスが、デバイス２０００とデータを通信する通信ネットワークとの間の接続及び/又は通信リンクを提供する。

【0139】

デバイス２０００は、さまざまなコンピュータ実行可能命令を処理して、デバイス２０００の動作を制御し、さらに、本明細書で説明する技術の実施形態を実現する、１つまたは複数のプロセッサ２０１０（例えば、任意のマイクロプロセッサおよび制御器など）を含む。あるいは、またはさらに、デバイス２０００は、一般に２０１２で識別されるプロセッシング回路ならびに制御回路と関連して実現される、ハードウェア、ファームウェア、もしくは固定ロジック回路の任意の１つもしくは組み合わせを用いて実現することができる。図示しないが、デバイス２０００は、デバイス内のさまざまな構成要素と結合するシステム・バスまたはデータ転送システムを含むことができる。システムバスは、メモリバスもしくはメモリ制御器、周辺バス、ユニバーサル・シリアル・バス、及び/又は任意のさまざまなバス構造を使用するプロセッサバスもしくはローカルバスなどの、異なるバス構造の任意の１つもしくは組み合わせを含むことができる。

【0140】

デバイス２０００は、また、１つまたは複数のメモリ部品などの、コンピュータ読取り可能媒体２０１４を備え、その例には、ランダム・アクセス・メモリ（ＲＡＭ）、不揮発性メモリ（例えば、リード・オンリー・メモリ（ＲＯＭ）、フラッシュ・メモリ、ＥＰＲＯＭ、ＥＥＰＲＯＭなどの任意の１つまたは複数）、およびディスク・ストレージ・デバイスがある。ディスク・ストレージ・デバイスは、ハードディスク・ドライブ、記録可能及び/又は書き換え可能コンパクト・ディスク（ＣＤ）、および任意の種類のデジタル多用途ディスク（ＤＶＤ）などの、任意の種類の磁気もしくは光学ストレージ・デバイスとして実現することができる。デバイス２０００は、また、大容量ストレージ媒体デバイス２０１６を備えることができる。

【0141】

コンピュータ読取り可能媒体２０１４は、データ・ストレージ機構を提供して、デバイス・データ２００４、さまざまなデバイスアプリケーション２０１８、およびデバイス２０００の動作態様に関連した任意の他の種類の情報及び/又はデータを格納する。例えば、オペレーティングシステム２０２０は、コンピュータ読取り可能媒体２０１４でコンピュータ・アプリケーションとして保持され、プロセッサ２０１０で実行することができる。デバイス・アプリケーション２０１８は、デバイスマネージャ（例えば、制御アプリケーション、ソフトウェアアプリケーション、信号処理ならびに制御モジュール、特定のデバイスにネイティブであるコード、特定のデバイスに対するハードウェアアブストラクション層など）を含むことができる。デバイスアプリケーション２０１８は、また、任意のシステム構成要素またはモジュールを含み、本明細書で説明する技術の実施形態を実現する。この例において、デバイスアプリケーション２０１８は、ソフトウェアモジュール及び/又はコンピュータアプリケーションとして示した、インターフェイスアプリケーション２０２２ならびに入力／出力モジュール２０２４を含む。入力／出力モジュール２０２４は、タッチスクリーン、トラックパッド、カメラ、およびマイクロフォンなどの入力を取得するよう構成されたデバイスとのインターフェイスを提供するよう使用されるソフトウェアを表す。あるいは、またはさらに、インターフェイスアプリケーション２０２２および入力／出力モジュール２０２４は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組み合わせとして実現することができる。さらに、入力／出力モジュール２０２４は、ビジュアル入力およびオーディオ入力をそれぞれ取得するための別々のデバイスなどの、複数の入力デバイスをサポートするよう構成してもよい。

【0142】

デバイス２０００は、また、オーディオデータをオーディオシステム２０２８にもたらす、及び/又は、ビデオデータを表示システム２０３０にもたらす、オーディオ及び/又はビデオ入力−出力システム２０２６を備える。オーディオシステム２０２８及び/又は表示システム２０３０は、オーディオ、ビデオ、ならびに画像データを処理、表示、及び/又は、そうでなければ表現する任意のデバイスを含むことができる。ビデオ信号およびオーディオ信号は、ＲＦ（無線周波数）リンク、Ｓ−ビデオリンク、複合ビデオリンク、コンポーネント・ビデオ・リンク、ＤＶＩ（デジタル・ビデオ・インターフェイス）、アナログオーディオ接続、または他の同様の通信リンクを介して、オーディオデバイスに、及び/又は及び/又は表示デバイスに、デバイス２０００から通信することができる。一実施形態において、オーディオシステム２０２８及び/又は表示システム２０３０は、デバイス２０００に対する外部コンポーネントとして実現される。あるいは、オーディオシステム２０２８及び/又は表示システム２０３０は、例示的デバイス２０００の一体型コンポーネントとして実現される。

【0143】

結論
本発明は、構造的特徴及び/又は方法論的動作に特有の言語で説明してきたが、添付の特許請求の範囲で定義される本発明は、記載した特定の特徴または動作に必ずしも限定されないことを理解すべきである。むしろ、特定の特徴および行為は、特許請求する本発明を実現する例示的形態として開示される。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】