(57)【特許請求の範囲】
【請求項１】
ネットワークを介し、サーバーから携帯計算装置へデータを送信する時刻を提示するためのシステムであって、
複数の起動時刻をストアするための前記携帯計算装置上のメモリー領域であって、前記起動時刻が、複数のスケジュールに関連し、前記複数のスケジュールの起動が、前記携帯計算装置上の無線通信リソースを消費し、前記メモリー領域が更に、前記携帯計算装置上のプロセス遅延及びネットワークに関連する待ち時間を示すオフセットをストアするものと、
前記携帯計算装置上のプロセッサーと、を含み、該プロセッサーが、
前記携帯計算装置へデータを送信するための前記サーバーによって、リクエストされた時間間隔にアクセスし、
前記リクエストされた時間間隔に基づいて、前記ストアされている複数の起動時刻を検索し、前記複数の起動時刻のサブセットを識別し、
前記識別された前記複数の起動時刻のサブセットに基づいて、送信時刻を決定し、
前記メモリー領域にストアされている前記オフセットに基づいて、前記決定された送信時刻を調整し、
前記調整された送信時刻を発行するようにプログラムされており、前記サーバーが、前記調整され発行された送信時刻に基づいて前記携帯計算装置へ前記データを送信すること、を特徴とするシステム。
【請求項２】
前記決定された送信時刻が、現在時刻からのオフセットを含むことを特徴とする請求項１記載のシステム。
【請求項３】
前記プロセッサーが更に、前記携帯計算装置上で実行しているサーバーに関連するアプリケーションプログラムから前記時間間隔を受信するようにプログラムされていることを特徴とする請求項１記載のシステム。
【請求項４】
前記サーバーが、前記発行された起動時刻に前記携帯計算装置へ前記データを送信することを特徴とする請求項１記載のシステム。
【請求項５】
前記プロセッサーが更に、最大の実行可能性を有するスケジュールを識別することによって、前記サブセットの１つを選択するようにプログラムされていることを特徴とする請求項１記載のシステム。
【請求項６】
前記携帯計算装置が、複数の無線通信を含み、前記プロセッサーが、前記サーバーから前記時間間隔に関するリクエストを受信し、前記リクエストが、前記無線通信の１つを識別するようにプログラムされていることと、前記プロセッサーが、前記リクエストされた時間間隔及び前記識別された無線通信に基づいて、前記ストアされている複数の起動時刻を検索するようにプログラムされていることと、を特徴とする請求項１記載のシステム。
【請求項７】
更に、
前記リクエストされた時間間隔内で前記送信時刻を、前記無線通信リソースに対する既知の電力供給時間に基づいて決定する手段と、
前記送信時刻を、前記プロセス遅延及び前記待ち時間に基づいて調整する手段と、を含む請求項１記載のシステム。
【請求項８】
第１の計算装置によって実行される方法であって、前記方法が、
第１の計算装置にデータを送信するために第２の計算装置からリクエストされた時刻の値を受信するステップと、
複数のスケジュールに関連する複数の起動時刻を識別するステップであって、前記複数のスケジュールの起動が、前記第１の計算装置に関するリソースを消費するものと、
既に提案された１つ以上の送信時刻を識別するステップと、
前記リクエストされた時間値を、前記識別された複数の起動時刻及び前記既に提案された送信時刻と比較するステップと、
前記比較に基づいて送信時刻を決定するステップと、
前記決定された送信時刻を前記第２の計算装置へ提供するステップであって、前記第２の計算装置が、前記決定され提供された送信時刻に前記第１の計算装置へデータを送信するステップと、を含む方法。
【請求項９】
前記リクエストされた時刻の値を受信するステップが、最小の時刻の値及び最大の時刻の値を受信するステップを含むことを特徴とする請求項８記載の方法。
【請求項１０】
前記リクエストされた時刻の値を受信するステップが、前記第２の計算装置に関連するアプリケーションプログラムから前記リクエストされた時刻の値を受信するステップを含むことと、前記第１の計算装置が、前記アプリケーションプログラムの実行をホスティングし、更に、前記決定された送信時刻を第２の計算装置へ伝達するための前記アプリケーションプログラムへ提供するステップと、含むことを特徴とする請求項８記載の方法。
【請求項１１】
前記第２の計算装置が、複数の計算装置の１つであって、前記複数の計算装置それぞれが、それに関する優先順位を有していて、前記送信時刻を決定するステップが、前記第２の計算装置に関連する前記優先順位に基いて前記送信時刻を決定するステップを含むことを特徴とする請求項８記載の方法。
【請求項１２】
前記複数の起動時刻を識別するステップが、条件のないスケジュールに関連する複数の起動時刻を識別するステップを含むことを特徴とする請求項８記載の方法。
【請求項１３】
前記時刻の値が時間間隔を含むことと、前記送信時刻を決定するステップが、前記時間間隔内で送信時刻を決定するステップと、既に決定された前記送信時刻の１つ又は前記複数の起動時刻の１つに対応付けるステップと、を含むことを特徴とする請求項８記載の方法。
【請求項１４】
前記時刻の値が時間間隔を含むことと、前記送信時刻を決定するステップが、前記時間間隔内で送信時刻を決定するステップを含むことと、前記決定された送信時刻が、前記複数の起動時刻の１つよりも少し早期であることを特徴とする請求項８記載の方法。
【請求項１５】
更に、
リクエストされた時間間隔を受信するためのインターフェースコンポーネントであって、前記リクエストされた時間間隔が、第２の計算装置から前記第１の計算装置への予測されるデータ伝達に関連しているものと、
前記第１の計算装置の通信リソースに関連する複数の見込み電力供給時間を識別するためのキャッシュコンポーネントと、
前記インターフェースコンポーネントによって受信された前記時間間隔、及び前記キャッシュコンポーネントによって識別された前記複数の見込み電力供給時間の比較に基づいて、送信時刻を決定するための手引コンポーネントと、
前記手引コンポーネントによって決定された前記送信時刻を前記第２の計算装置へ提供するための公開コンポーネントであって、前記第２の計算装置が、前記提供された送信時刻に前記第１の計算装置へ前記データを送信するものと、を含む請求項８記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークで接続された計算システムに関し、具体的には、計算装置からデータを送信するシステムに関する。
【背景技術】
【０００２】
[0001]  携帯電話及び携帯情報端末（ＰＤＡ）のような携帯計算装置が、近年、ますます人気が増している。装置がより小さくなるにつれて、メモリー、ストレージ、帯域幅、バッテリー容量のようなリソースにおける制限が増えている。加えて、今日では、より多くのアプリケーションが、そのようなリソースを増大した水準で消費している。多くのアプリケーションは、例えば、頻繁な無線通信利用を必要とするサーバーとの同期などの再発性のタスクを実行する。携帯計算装置の無線通信は電源投入され、データの送信後、無線通信は、電源を落とすために数秒（例えば、２．５Ｇのネットワークで約３秒及び３Ｇのネットワークで約２０秒）かかる。無線通信のこの「テール」が、電力を消耗させ、携帯計算装置のバッテリー寿命を減らす。更に、無線通信をスピンアップして無線通信を停止する際、別の電力の非効率性が存在する。
【０００３】
[0002]  データのリアルタイムプッシュ又は更新を用いた接続アプリケーションは、携帯ユーザーによって広く採用されている。アプリケーションは、電子メール、個人情報管理、存在情報、及びその他のウェブアプリケーションを含んでいる。サーバーは、未調整の方法によってデータをプッシュし、携帯計算装置のバッテリー寿命を低下させてユーザーの体験に負の影響を及ぼしている。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
本発明の目的は、データの送信を調整し、計算装置の通信リソースを保護するためのシステムを提供することである。
【課題を解決するための手段】
【０００５】
[0003]  本発明の実施形態は、複数の第２の計算装置から、少なくとも１つの第１の計算装置に対するデータの送信を調整する。第２の計算装置のうち１つが、データ送信に関する時間間隔をリクエストする。第１の計算装置が、リクエストされた時間間隔を第１の計算装置に関連する通信リソースに対する複数の既知の電力供給時間と比較する。送信時刻が決定され、第２の計算装置へ提供される。データの送信を調整することが、第１の計算装置の通信リソースを保護する。実施形態の中には、決定された送信時刻が、プロセス遅延及びネットワーク待ち時間に対し調整されるものもある。
【０００６】
[0004]  この「課題を解決するための手段」は、「発明を実施するための形態」において更に後述される概念のいくつかを簡易化した形式で紹介するために提供される。この「課題を解決するための手段」は、請求対象項目の重要な機能も本質的な特徴も特定するように意図されておらず、請求対象項目の範囲を決定する際の支援として利用されることも意図されていない。
【図面の簡単な説明】
【０００７】
【図１】[0005]複数の第２の計算装置からデータを受信する第１の計算装置を示している例示的なブロック図である。
【図２】[0006]本発明の態様を実装するための、リソース及び計算機実行可能なコンポーネントに対する既知の電力供給時間をストアしている計算装置を示している例示的なブロック図である。
【図３】[0007]リクエストされた時間間隔を、再発性のスケジュールに関する起動時刻及び既に提示された送信時刻と比較し、サーバーに提示する送信時刻を決定することを示している例示的な流れ図である。
【図４】[0008]プロセス遅延及びネットワーク待ち時間に基づくデータ送信時刻の決定、及び決定された送信時刻の調整を示している例示的な流れ図である。
【図５】[0009]携帯計算装置に関連する通信リソースに対する既知の電力供給時間に基づくデータ送信時刻の決定を示している例示的な流れ図である。
【図６】[0010]２つのサーバーから携帯計算装置へのデータの送信に関するスケジューリングを示している例示的なシーケンスの図である。
【発明を実施するための形態】
【０００８】
[0011]対応する参照文字は、図面中、対応する部品を示している。
【０００９】
[0012]図面を参照すると、本発明の実施形態が、複数の第２の計算装置（１０４）から少なくとも１つの第１の計算装置（１０２）へのデータの送信を調整し、第１の計算装置（１０２）の通信リソースの消費を減らす。実施形態の中には、第１の計算装置（１０２）が、送信時刻（例えば、最適な送信時刻）に関する手引、提示、推奨、又は割当てを第２の計算装置（１０４）へ提供し、複数の第２の計算装置（１０４）が、同一の時刻か又はほぼ同じ時刻に、第１の計算装置（１０２）へデータを送信するものもある。第１の計算装置（１０２）が携帯計算装置（６０２）である例において、調整されたデータ送信が、１つ以上のセルラー方式無線通信に対する既知の電力供給時間（例えば、無線通信のスピンアップ）を活用し、携帯計算装置（６０２）のバッテリー寿命を保護する。しかしながら、別の例において、本発明の態様は、第１の計算装置（１０２）の任意のリソースを保護し、消費を抑え、寿命を伸ばすか又は最適化するように作動可能である。
【００１０】
[0013]実施形態の中には、携帯計算装置（６０２）が、既知のスケジュールデータを活用し、次にスケジュールされている無線通信時刻を識別し、ネットワーク待ち時間（２１４）に適応し、その後、この時刻を関心あるアプリケーション又はサーバーへ発行するものもある。例において、発行される時刻は、次にスケジュールされている無線通信時刻の少し前であって、サーバーの通信及び装置のスケジュール双方が、無線通信の同一のスピンアップを活用する。例えば、装置のスケジュールは、午前９時に起動する予定であって、発行される時刻は、午前８：５９：４５ａｍである。サーバー通信が、その後、８：５９：４５ａｍに生じる無線通信をもたらす。
【００１１】
[0014]「ファズ（fuzz）」又は許容範囲要因が、スケジュール（２０８）それぞれに関連する実施形態において、許容範囲要因は、第２の計算装置（１０４）に対し、第１の計算装置（１０２）と連絡するための時刻を対象に調整するためのより大きな時間窓を提供する。５０％の許容範囲要因を有する１０分間隔のスケジュールの例において、第２の計算装置（１０４）は、時間５分と時間１０分との間において第１の計算装置（１０２）といつでも連絡し、無線通信のスピンアップを活用する。許容範囲要因が、無線通信のスピンアップが活用される確率を大きくする。
【００１２】
[0015]再び図１を参照すると、例示的なブロック図は、Ｎが正の整数である、第２の計算装置＃１から第２計算装置＃Ｎのような複数の第２の計算装置（１０４）からデータを受信している第１の計算装置（１０２）を示している。第２の計算装置（１０４）は、例えば、インターネットのようなネットワーク（１０６）を介し第１の計算装置（１０２）と接続される。実施形態の中には、図３、図４、及び図５に例示されているような動作が、スケジューラー（１０８）、又はその他のコンポーネント、命令、又はロジックによって第１の計算装置（１０２）上で実行されるものもある。
【００１３】
[0016]第２の計算装置（１０４）は、第１の計算装置（１０２）へ周期的（例えば、定期的又は断続的）にデータを送信するためのサービスを実行する。実施形態の中には、第２の計算装置（１０４）が、コンテンツのリアルタイム更新（例えば、プッシュメール、カレンダー、連絡先、インスタントメッセージ、及びソーシャルネットワークデータ）を第１の計算装置（１０２）へ提供するものもある。第２の計算装置（１０４）が、ハートビート接続試験用パケットを送信又は受信し、第２の計算装置（１０４）と第１の計算装置（１０２）との関係をオープンに保つ。
【００１４】
[0017]第２の計算装置（１０４）は、第１の計算装置（１０２）へデータを送信するサーバー、プロキシーサーバー、エンタープライズサーバー、又はその他の任意の装置を含むがこれらに限定しない。更に、実施形態の中には、第１の計算装置（１０２）を参照し記載されている携帯計算装置（６０２）を含むものもあるが、本発明の態様は、第２の計算装置（１０４）と通信するラップトップコンピューター、ゲーム端末、携帯ナビゲーション装置、又はその他の任意の機器など、別の装置と作動可能である。加えると、本発明の実施形態は、携帯計算装置（６０２）へデータを送信するサーバーを参照し説明されているが、本発明の態様は、第１の計算装置（１０２）と第２の計算装置（１０４）との間のピアツーピア接続のような別の環境において作動可能である。
【００１５】
[0018]次の図２を参照すると、例示的なブロック図は、本発明の態様を実装するためのリソース及び計算機実行可能なコンポーネントに対する既知の電力供給時間をストアしている第１の計算装置（１０２）のような計算装置（２０２）を示している。計算装置（２０２）は、プロセッサー（２０４）及びメモリー領域（２０６）、又はその他の計算機可読媒体を含む。メモリー領域（２０６）は、Ｍが正の整数である、スケジュール＃１からスケジュール＃Ｍのような複数のスケジュール（２０８）をストアしている。スケジュール（２０８）が、計算装置（２０２）へデータを送信するための第２の計算装置（１０４）に関連付けられていて、それによって提供される。アプリケーションプログラムが、それぞれのスケジュール（２０８）を実行し、関連付けられている第２の計算装置（１０４）のような装置からデータを受信又は送信し、計算装置（２０２）上のセルラー方式無線通信のような通信インターフェースへの電源投入をもたらす。アプリケーションプログラムは、例えば、計算装置（２０２）によってホスティングされる。スケジュール（２０８）それぞれは、起動時刻（２１０）を有していて、スケジュール（２０８）それぞれは、少なくとも１つの第２の計算装置（１０４）に関連付けられている。実施形態の中には、スケジュール（２０８）が再発性の起動時刻（２１０）を有するものもある。
【００１６】
[0019]スケジュール（２０８）の実行が、起動時刻（２１０）にスケジュール（２０８）と関連する１つ以上の動作を実施又は実行することを含む。起動時刻（２１０）は、例えば、関連する第２の計算装置（１０４）が計算装置（２０２）へデータを送信する絶対時間又はオフセット時間を示している。データの送信は、計算装置（２０２）上の電力を消費するリソース（例えば、１つ以上のセルラー方式無線通信のような通信リソース又は無線通信リソース）を使用する。スケジュール（２０８）は、通信リソースが使用する、既知の将来の時間を示すと同時に、メモリー領域（２０６）は、代替として又は加えると、１つ以上の通信リソースに対する既知の電力供給時間を明示的にストアし得る。
【００１７】
[0020]実施形態の中には、メモリー領域（２０６）にストアされているスケジュール（２０８）が、条件付スケジュール（２０８）、条件のないスケジュール（２０８）、通信リソースを消費するスケジュール（２０８）、及び通信リソースを消費しないスケジュール（２０８）（又は最適化されたその他のリソース）を含むものもある。そのような実施形態において、計算装置（２０２）は、送信時刻を決定するとき、スケジュール（２０８）のサブセットをフィルタリング、検索、又は他に生成する。例えば、条件のないスケジ
ュール（２０８）は、条件付スケジュール（２０８）よりも実行される、より大きな機会（例えば、最良の実行見込み）を有していて、したがって、条件のないスケジュール（２０８）に関連する起動時刻（２１０）が送信時刻を決定するとき、条件付スケジュール（２０８）に関連する起動時刻（２１０）は、優先順位又は優先権が与えられる。
【００１８】
[0021]別の実施形態において、スケジュール（２０８）は、事前にソートされるか、事前にフィルタリングされるか、又は別の方法で分類される。メモリーは、例えば、送信時刻の決定を早めるための条件付のリソース消費、条件のないリソース消費、及び非リソース消費の別のグループのスケジュール（２０８）をストアし得る。
【００１９】
[0022]メモリー領域（２０６）は更に、プロセス遅延（２１２）及びネットワーク待ち時間（２１４）をストアする。プロセス遅延（２１２）は、計算装置（２０２）上のプロセス実行による遅延を示している。ネットワーク待ち時間（２１４）は、計算装置（２０２）へのネットワーク（１０６）のデータ転送による遅延を示している。実施形態の中には、プロセス遅延（２１２）及びネットワーク待ち時間（２１４）のどちらか一方又は双方が、オフセットとして表されるものもある。プロセス遅延（２１２）及びネットワーク待ち時間（２１４）は、計算装置（２０２）によって使用され、より正確な送信時刻を提供する。実施形態の中には、プロセス遅延（２１２）及びネットワーク待ち時間（２１４）が、計算装置（２０２）によって（例えば、プロセス処理又はネットワーク転送中の時間差を測定し）決定されるものもある。別の実施形態において、ネットワーク待ち時間（２１４）が、（例えば、計算装置（２０２）へデータを送信している装置によって）計算装置（２０２）へ提供される。
【００２０】
[0023]メモリー領域（２０６）は更に、既に提案された１つ以上の送信時刻（２１６）をストアしている。既に決定された送信時刻（２１６）は、計算装置（２０２）へデータを送信するための時刻の手引又は提案時刻を表している。既に決定された送信時刻（２１６）は、将来、発生する時刻を表している。現在の時刻が午後１２時３０分である例において、計算装置（２０２）は、第１のアプリケーションプログラムへの送信時刻、午後１２時４０分を決定し、提供する。図３を参照し、より詳細に後述されているように、第２のアプリケーションプログラムから送信時刻に関するリクエストを受信すると、計算装置（２０２）は、既に決定された送信時刻の午後１２時４０分を認識し、この時刻を、計算装置（２０２）上の通信リソースの利用を調整するための第２の計算装置（１０４）へ提供することを考慮し得る。
【００２１】
[0024]メモリー領域（２０６）は更に、インターフェースコンポーネント（２１８）、キャッシュコンポーネント（２２０）、手引コンポーネント（２２２）、及び発行コンポーネント（２２４）のような１つ以上の計算機実行可能コンポーネントをストアする。
これらコンポーネントの動作が、図５を参照し後述される。
【００２２】
[0025]次に図３を参照すると、例示的な流れ図は、リクエストされた時間間隔を、スケジュール（２０８）に関する起動時刻（２１０）及び既に提案された送信時刻（２１６）と比較し、サーバーへ提示する送信時刻を決定することを示している。（３０２）において、第１の計算装置（１０２）のような計算装置が、サーバー又は第２の計算装置（１０４）のような別の計算装置からリクエストされた時刻を受信する。実施形態の中には、時刻の値が、最小の時刻の値及び最大の時刻の値を指定している時間間隔又は範囲を含むものもある。時刻の値は、絶対時間（例えば、第１の計算装置（１０２）による受信時刻）又は現在時刻からのオフセットであり得る。時間間隔を指定する手段の例が付録Ａに示されている。
【００２３】
[0026]（３０４）において、リクエストされた時刻の値を受信すると、第１の計算装置
（１０２）が、スケジュール（２０８）に関連する１つ以上の次回の起動時刻（２１０）を識別する。例えば、第１の計算装置（１０２）が、通信リソース（又は最適化される別のリソース）を消費するスケジュール（２０８）に関連する起動時刻（２１０）を識別する。第１の計算装置（１０２）は、その後、条件の無いスケジュール（２０８）に関連するそれらの起動時刻（２１０）を識別する。そのようなスケジュール（２０８）が利用可能でない場合、第１の計算装置（１０２）は、条件付スケジュール（２０８）に関連するそれらの起動時刻（２１０）を識別する。
【００２４】
[0027]（３０４）においても、第１の計算装置（１０２）は、既に提案されている１つ以上の送信時刻（２１６）を識別する。第１の計算装置（１０２）は、例えば、メモリー領域（２０６）にストアされた既に提案されている送信時刻（２１６）にアクセスする。（３０６）において、リクエストされた時刻の値が、識別された起動時刻（２１０）及び既に提案された送信時刻（２１６）と比較される。（３０６）において第１の計算装置（１０２）が、比較に基づいて送信時刻を決定する。リクエストされた時刻の値が間隔である例において、決定される送信時刻は、間隔内の時刻を示している。代替として又は加えると、決定された送信時刻は、次回の起動時刻（２１０）の１つ又は既に提案された送信時刻（２１６）の１つに対応する時刻を示している。そのような実施形態において、通信リソースが電源投入されている間、複数のサーバーが通信リソースを使用しているため、通信リソースの利用が最適化される。
【００２５】
[0028]（３０８）において、決定された送信時刻がサーバーに提供される。サーバーは、提供された送信時刻に第１の計算装置（１０２）へデータを送信する。実施形態の中には、リクエストされた時刻の値が第１の計算装置（１０２）上で実行するけれどもサーバー関連するアプリケーションプログラムから受信されるものもある。そのような実施形態において、決定された送信時刻は、アプリケーションプログラムへ提供される。アプリケーションプログラムが、決定された送信時刻をサーバーへ伝達し、サーバーが、決定された送信時刻に第１の計算装置（１０２）へデータを送信する。
【００２６】
[0029]複数のサーバーが第１の計算装置（１０２）へデータを送信する実施形態において、それぞれのサーバーは、それと関連する優先順位を有している。第１の計算装置（１０２）は、送信時刻を決定したときに割り当てられる優先順位を使用する。例えば、通信リソースが特定の時間間隔を利用可能な場合、高い優先順位を有し、送信時刻をリクエストしているサーバーが、前に決定された特定の時間間隔内の送信時刻を受信する。低い優先順位を有するサーバーが、特定の時間間隔内に、後で決定される送信時刻を受信する。
【００２７】
[0030]次に図４を参照すると、例示的な流れ図が、データ送信時刻の決定と、プロセス遅延（２１２）及びネットワーク待ち時間（２１４）に基づく、決定された送信時刻の調整と、を示している。（４０２）において、サーバー又は別の第２の計算装置（１０４）によってリクエストされた時間間隔が（例えば第１の計算装置（１０２）によって）アクセスされる。リクエストされた時間間隔は時間範囲を示していて、その間、サーバーが第１の計算装置（１０２）へデータを送信することを所望している。（４０４）において、リクエストされた時間間隔内にある起動時刻（２１０）が（実施形態の中には既に決定された送信時刻（２１６）も）検索され、起動時刻（２１０）のサブセットを識別する。（４０６）において、送信時刻が識別された起動時刻（２１０）のサブセットに基づいて決定され、通信リソースの消費を調整する。（４０８）において、決定された送信時刻が、プロセス遅延（２１２）及び／又はネットワーク待ち時間（２１４）に対応しているオフセットに基づいて調整される。（４１０）において、決定された送信時刻がサーバーへ発行される。
【００２８】
[0031]送信時刻を決定するための例示的な命令又は動作が、付録Ｂに記載される。
【００２９】
[0032]次に図５を参照すると、例示的な流れ図が、携帯計算装置（６０２）に関連した通信リソースに対する既知の電力供給時間に基づくデータ送信時刻の決定を示している。図５の例において、インターフェースコンポーネント（２１８）、キャッシュコンポーネント（２２０）、手引コンポーネント（２２２）、又は発行コンポーネント（２２４）が、携帯計算装置（６０２）上で実行する。（５０２）において、インターフェースコンポーネント（２１８）が、リクエストされた時間間隔又は時刻の値を受信又はアクセスする。時間間隔が、予測されるサーバーから携帯計算装置（６０２）へのデータ送信に関連付けられる。（５０４）において、キャッシュコンポーネント（２２０）が、携帯計算装置（６０２）の通信リソースに関する１つ以上の見込みの電力供給時間を識別する。見込みの電力供給時間が、例えば、通信リソース又は既に決定された送信時刻（２１６）を消費している携帯計算装置（６０２）上で実行しているスケジュール（２０８）に関する次回の起動時刻（２１０）を示している。
【００３０】
[0033]（５０６）において、手引コンポーネント（２２２）は、インターフェースコンポーネント（２１８）によって受信されるリクエストされた時間間隔、及びキャッシュコンポーネント（２２０）によって識別された見込みの電力供給時間の比較に基づいて送信時刻を決定する。例えば手引コンポーネント（２２２）が、見込みの電力供給時間の１つに対応している時間間隔の始まりに送信時刻を設定する。実施形態の中には、インターフェースコンポーネント（２１８）によって受信されるリクエストが、予測されるデータ転送サイズを示しているペイロード値を含むものもある。そのような実施形態において、手引コンポーネント（２２２）は、受信されるペイロード値に基づいて、送信時刻を決定し、携帯計算装置（６０２）上の帯域幅を管理する（例えば通信リソースのスラッシングを回避する）。小さなペイロードを有するデータパケットが、例えば、最初に送信されるように優先順位付けされ、後に大きなペイロードを有するデータパケットが続く。代替として又はペイロードサイズに加えて、いくつかのインターフェースを横断するペイロードは、優先順位を与えられ、優先順の降順に送信する。
【００３１】
[0034]（５０８）において、公開コンポーネント（２２４）が、手引コンポーネント（２２２）によって決定された送信時刻をサーバーへ提供する。サーバーは、提供された送信時刻に携帯計算装置（６０２）へデータを送信する。
【００３２】
[0035]実施形態の中には、携帯計算装置（６０２）が複数のセルラー方式無線通信を有するものもある。そのような実施形態において、インターフェースコンポーネント（２１８）によって受信されたリクエストは、セルラー方式無線通信のうち１つの識別を含む。別の実施形態において、携帯計算装置（６０２）が、セルラー方式無線通信の１つにリクエストを割り当てる。更に別の実施形態において、スケジュール（２０８）それぞれによって使用される、接続を維持している無線通信がトラッキングされる。識別されたセルラー方式無線通信が手引コンポーネント（２２２）によって使用される別の可変なものになり、送信時刻を決定する。そのような実施形態において、メモリー領域（２０６）にストアされている既に決定された送信時刻（２１６）それぞれは、関連するセルラー方式無線通信の識別を含んでいる。手引コンポーネント（２２２）は、送信時刻を決定するとき識別された同一のセルラー方式無線通信を有するスケジュール（２０８）を優先する。
【００３３】
[0036]次に、図６を参照すると、例示的なシーケンスの図が、２つのサーバーから携帯計算装置（６０２）へのデータ送信スケジュールを示している。携帯装置において実行している２つのアプリケーションプログラム（６０４）、（６０６）が、携帯計算装置（６０２）へのデータ送信に関する手引をリクエストする。スケジューラー（１０８）から手引を受信すると、アプリケーションプログラム（６０４）、（６０６）が、関連するサーバー（６１０）、（６１２）へ手引を提供する。サーバー（６１０）、（６１２）は、そ
の後、手引された時刻に携帯計算装置（６０２）へのデータ送信を試みる。
【００３４】
[0037]図６の例において、既知の電力供給時間（例えば、次回の起動時刻（２１０）又は既に決定されている送信時刻（２１６））のリストは、ＳｅｒｖｅｒＳｅｎｄＴｉｍｅｓのリストとして参照される。ＳｅｒｖｅｒＳｅｎｄＴｉｍｅｓのリストは、スケジューラー（１０８）又は別のサービスの起動中に生成され、スケジューラー（１０８）がプロセスを終了するとき、クリアされる。ＳｅｒｖｅｒＳｅｎｄＴｉｍｅｓのリストは、キャッシュとして処理されていて、キャッシュエントリーがリクエストされた時間間隔内に収まっている場合、キャッシュエントリーが別の送信時刻を決定するときの候補として考慮される。実施形態の中には、キャッシュが、＜ｋｅｙ，ｖａｌｕｅ＞＝＜ＳｅｒｖｅｒＳｅｎｄＴｉｍｅ，ｆｒｅｑｕｎｃｙ＞を用いたハッシュマップとして表されるものもある。＜ＳｅｒｖｅｒＳｅｎｄＴｉｍｅ，ｆｒｅｑｕｎｃｙ＞のマップが、ｋｅｙ（ＳｅｒｖｅｒＳｅｎｄＴｉｍｅ）に関してソートされる。そのような例において、マップは、終了時刻に最も近いＳｅｒｖｅｒＳｅｎｄＴｉｍｅの識別速度を増す。
【００３５】
[0038]実施形態の中には、それぞれのスケジュール（２０８）に対する起動時刻（２１０）が、起動時刻（２１０）によって（例えば昇順に）ソートされたキャッシュとしてストアされるものもある。キャッシュは、アクティブスケジュール（２０８）すべてに対する起動時刻（２１０）をストアしている。キャッシュは、サーバーから受信された送信データに対するリクエストそれぞれを用いて作成又は更新される。実施形態の中には、スケジューラー（１０８）が、単にこのキャッシュを提供又は発行していて、サーバーが適切な送信時刻を選択できるようにしているものもある。
【００３６】
[0039]図６の例において、リクエストされた時間間隔を受信すると、スケジューラー（１０８）は、キャッシュを介し繰り返し（例えば、現在時刻に満たない起動時刻（２１０）を有する）期限が切れたエントリーすべてを削除する。スケジューラー（１０８）は、スケジュール（２０８）を介し繰り返し、携帯計算装置（６０２）上の通信リソースを使用する、再発性のアクティブスケジュール（２０８）のサブセットを識別する。スケジュール（２０８）のサブセットのスケジュール（２０８）それぞれに対する次の起動時刻（２１０）が計算される。スケジューラー（１０８）は、このスケジュール（２０８）のサブセットから、サーバーによってリクエストされた時間間隔内に収まる起動時刻（２１０）を識別する。スケジューラー（１０８）は、高い実行確実性を有するスケジュール（２０８）に関連する起動時刻（２１０）に優先権を与える。例えば、実行に関し条件のないスケジュール（２０８）は高い実行確実性を有する。スケジューラー（１０８）は、識別されたスケジュール（２０８）のサブセットに基づいて起動時刻（２１０）のキャッシュを更新する。
【００３７】
[0040]スケジューラー（１０８）は、起動時刻（２１０）のキャッシュ及びＳｅｒｖｅｒＳｅｎｄＴｉｍｅｓのリストに基づいて送信時刻又は別の時刻の手引を決定する。起動時刻（２１０）の１つがリクエストされた時間間隔内に収まっている場合、起動時刻（２１０）がＳｅｒｖｅｒＳｅｎｄＴｉｍｅｓのリストに追加され、頻度が１に設定される。起動時刻（２１０）のキャッシュ内の起動時刻（２１０）を満たしているものが存在しない場合、スケジューラー（１０８）は、ＳｅｒｖｅｒＳｅｎｄＴｉｍｅｓのリストを走査する。ＳｅｒｖｅｒＳｅｎｄＴｉｍｅｓの１つがリクエストされた時間間隔内に収まっている場合、そのＳｅｒｖｅｒＳｅｎｄＴｉｍｅがリクエストされているサーバーへ提供され、リスト内のそのＳｅｒｖｅｒＳｅｎｄＴｉｍｅの頻度が増やされる。１つ以上のＳｅｒｖｅｒＳｅｎｄＴｉｍｅが間隔内に収まっている場合、最も大きな頻度を有するＳｅｒｖｅｒＳｅｎｄＴｉｍｅが選択される。ＳｅｒｖｅｒＳｅｎｄＴｉｍｅのどれもリクエストされた時間間隔内に収まらない場合、最も近いＳｅｒｖｅｒＳｅｎｄＴｉｍｅが、（例えば、定義された許容範囲又はデルタ領域に基づいて）選択される。送信時刻は、最も近
いＳｅｒｖｅｒＳｅｎｄＴｉｍｅの始まりに設定される。どんなＳｅｒｖｅｒＳｅｎｄＴｉｍｅも時間間隔内に収まっていない場合、リクエストされた時間間隔の終わりの時刻がＳｅｒｖｅｒＳｅｎｄＴｉｍｅに設定される。終了時刻が、その後、１の頻度（１）を用いてＳｅｒｖｅｒＳｅｎｄＴｉｍｅｓのリストへ入力される。
【００３８】
[0041]図６の例は、例示的な送信時刻の決定を例示しているが、別の選択方法が本発明の態様の範囲内にある。更に、選択方法が動的に変更され得る。
【００３９】
[0042]実施形態の中には、最小の時刻の値が現在時刻であって、最大の時刻の値が最大のハートビート間隔（例えば、携帯計算装置（６０２）とサーバーが、ずっと接続を維持しているためにデータを送信せずに作動し得る最長の期間）を表しているものもある。
【００４０】
[0043]（示されていない）実施形態において、サーバーは、１つ以上のサーバーからのデータを段階分けするプロキシーサーバーである。プロキシーサーバーは、携帯計算装置（６０２）にデータを送信する前にデータを段階分けする。プロキシーサーバーは、データパケット（又はサーバー）に割り当てられる優先順位を有する。優先権は、携帯計算装置（６０２）へのデータパケットを取得するための（例えば、パケットを遅延させる許容範囲に対する）緊急性を示している。プロキシーサーバーは、意志の観点から優先順位を定量化し、データを送信する前（例えば数分間）、待機する。携帯計算装置（６０２）において、アプリケーションは、データパケットを発信しているサーバーがデータの送信を遅延させる意志がある持続時間に等しい最小の時刻（例えば現在時刻）と、最大の時刻と、を提供する。携帯計算装置（６０２）のアプリケーションがサーバーへハートビート接続試験用パケットを送信したとき、それは、サーバーがデータを送信するために決定された送信時刻又は最も適した将来の手引を含んでいる。
【００４１】
[0044]ＳｅｒｖｅｒＳｅｎｄＴｉｍｅは、サーバーがデータを送信する開始時刻を示している。リソースがＳｅｒｖｅｒＳｅｎｄＴｉｍｅ後、ある持続時間（例えばセルラー方式無線通信のテール）が利用可能なことを知っている実施形態において、持続時間は、スケジューラー（１０８）によって考慮される。許容範囲又はデルタ領域は、例えば、既知のセルラー方式無線通信のテールに基づいて設定される。
例
[0045]例において、メールサーバーは、手引を要求し、最小時刻及び最大時刻として１２：００及び１２：２０を提供する。スケジューラー（１０８）は、１０分間隔の持続時間スケジュールを持った、１２：２０にアクティブ接続を有するアクティブスケジュールを有している。スケジューラー（１０８）が、アクティブスケジュールを識別し、ネットワーク待ち時間（２１４）及び／又はプロセス遅延（２１２）（例えば３０秒）を考慮した送信時刻に適応し、送信時刻１２：１９：３０を決定し、決定された送信時刻をサーバーへ提供する。
【００４２】
[0046]たった今の例の変形において、どんな起動時刻（２１０）もリクエストされた時間間隔内に収まらない。この例において、スケジューラー（１０８）が、決定された送信時刻（例えばＳｅｒｖｅｒＳｅｎｄＴｉｍｅ）として最大時刻１２：２０を設定する。
【００４３】
[0047]たった今の例を継続すると、別のサーバーが、最小の時刻及び最大の時刻として１２：１５及び１２：３０を提供する。ＳｅｒｖｅｒＳｅｎｄＴｉｍｅは、１２：２０に等しく、リクエストされた時間間隔内に収まっている。スケジューラー（１０８）は、ネットワーク待ち時間（２１４）に対し適応した後、決定された送信時刻として１２：１９：３０を提供する。
例示的動作環境
[0048]例であって限定されない計算機可読媒体は、計算機記憶媒体及び通信媒体を含む
。計算機記憶媒体は、計算機可読な命令、データ構造、プログラムモジュール、又はその他のデータなどの情報をストアする。通信媒体は、典型的に、計算機可読な命令、データ構造、プログラムモジュール、又はその他のデータを搬送波又はその他の伝送機構のような変調データ信号で具体化していて、任意の情報送信媒体を含んでいる。上記の組み合わせはどれも、計算機可読媒体の範囲内に含まれる。
【００４４】
[0049]例示的な計算システム環境に関し説明されているが、本発明の実施形態は別の多くの汎用若しくは専用計算システム環境又は構成を用いて作動する。本発明の態様をとともに使用するための知られている適切な計算システム、環境、及び／又は構成の例は、携帯計算装置、パーソナルコンピューター、サーバーコンピューター、携帯用若しくはラップトップ機器、マルチプロセッサーシステム、ゲーム端末、マイクロプロセッサーベースのシステム、セットトップボックス、プログラマブル家電、携帯電話、ネットワークＰＣ、ミニコンピューター、メインフレームコンピューター、上記システム又は機器などのうち任意のものを含む分散計算環境を含むがこれらに限定しない
[0050]本発明の実施形態は、１つ以上の計算機又はその他の機器によって実行されるプログラムモジュールなどのように計算機実行可能命令に関する一般的な文脈で記載されている。計算機が実行可能な命令は、１つ以上の計算機実行可能コンポーネント又はモジュールの中に統合化され得る。一般にプログラムモジュールは、特定のタスクを実行するか又は特定の抽象データタイプを実装しているルーチン、プログラム、オブジェクト、コンポーネント、及びデータ構造を含むがこれらに限定しない。本発明の態様は、そのようなコンポーネント又はモジュールの任意の数及び機構を用いて実装され得る。本発明の態様は、例えば、図面に例示され本明細書に記載された特定の計算機実行可能命令、特定のコンポーネント又はモジュールに制限されない。本発明の別の実施形態は、異なる計算機実行可能命令又は本明細書に例示され記載されたものよりも多いか若しくは少ない機能性を有するコンポーネントを含み得る。
【００４５】
[0051]本明細書に例示され記載された実施形態、及び本発明の態様の範囲内であるが本明細書に特に記載されていない実施形態が、リクエストされた時間間隔内の無線通信リソースに対する既知の電力供給時間に基づく送信時刻を決定するための例示的手段と、プロセス遅延（２１２）及び待ち時間に基づいて送信時刻を調整するための例示的手段と、を構成する。
【００４６】
[0052]本明細書に例示され記載された発明の実施形態において、命令の順番又は動作の性能は、特に記載していない限り本質的ではない。すなわち動作は、特に記載していない限り任意の順番で実行され、本発明の実施形態は、本明細書に開示されたものに付加的な動作又ははより少ない動作を含む。例えば、別の動作の前か、同時か、又は後に実行するか若しくは実施する特定の動作が、本発明の態様の範囲内にあることを想定されている。
【００４７】
[0053]本発明の態様のエレメント又はその実施形態を導入するとき、冠詞、「ａ」、「ａｎ」、「ｔｈｅ」、及び「ｓａｉｄ」は、１つ以上のエレメントが存在することを意味するように意図されている。用語「から成る（）」、「を含む（）」、「を有する（）」は、包括的であって、記載されたエレメント以外の付加的なエレメントが有り得ることを意味するように意図されている。
【００４８】
[0054]本発明の態様を詳細に説明したので、修正及び変型が添付した請求項に定義されているように本発明の態様の範囲から逸脱せずに可能であることが明らかであろう。上記の構造、製品、及び方法において様々な変更が本発明の態様の範囲から逸脱せずに実施され得るので上記説明に含まれていて添付図面に示されている事項すべてが、例示的であって、限定した意味でないものとして解釈されるように意図されている。
【００４９】
付録Ａ
[0055]以下に示されるアプリケーションプログラミングインターフェース（ＡＰＩ）は、アプリケーションプログラムが最小時刻及び最大時刻の間隔を提供することを可能にする。第１の計算装置上で実行するスケジューラーは、２つの間隔の間に収まる（例えばユニバーサルタイムコード形式の）手引を返却する。
ＡＰＩの署名は以下に示される。
//preconditions:-
//  startTime <= endTime 
//  CurrentTime <= endTime 
//postconditions:-
//  startTime <= serverSendTime and serverSendTime <= endTime 
HRESULT TaskSchedulerGetBestNetworkTimelnRange (_in const FILETIME * startTime, _in const FILETIME *endTime, _out FILETIME *serverSendTime); 
このＡＰＩは、ｓｔａｒｔＴｉｍｅとｅｎｄＴｉｍｅとの間の機器にデータを送信するサーバーのための手引が、時刻を取得する。
【００５０】
パラメーター
ｓｔａｒｔＴｉｍｅ
［ｉｎ］間隔の始まりの時間
ｅｎｄＴｉｍｅ
［ｉｎ］間隔の終わりの時間
ｓｅｒｖｅｒＳｅｎｄＴｉｍｅ
［ｏｕｔ］サーバーが機器へデータを送信する必要がある時刻の手引
返却値
Ｓ＿ＯＫ
成功した場合、返却される値
Ｅ＿ＩＮＶＡＬＩＤＡＲＧ
前提条件のどれかが失敗又は不正な引数の場合、返却される値
Ｅ＿ＦＡＩＬ
成功しなかった場合、返却される値
[0056]既にＴａｓｋＳｃｈｅｄｕｌｅｒＧｅｔＢｅｓｔＮｅｔｗｏｒｋＴｉｍｅｌｎＲａｎｇｅ（）によって返却される手引をキャンセルするための例示的なＡＰＩが以下に示される。このＡＰＩは、任意のリクエスト元によって使用され、手引を使用せずに終了する。ＡＰＩは、手引の時刻が発行されるとき、より高い重み付けがされるので、少なくとも本発明の態様の精度及び有効性を増大する。スケジューラーは、このＡＰＩ関数呼び出しを用いて、時刻の手引の値の利用を密接にトラッキングし、次に時刻の手引を与えるとき、スケジューラーによって内部で使用される発見的手法を改善する。以下の例において、既存の手引をキャンセルするためのＴａｓｋＳｃｈｅｄｕｌｅｒＣａｎｃｅｌＢｅｓｔＮｅｔｗｏｒｋＴｉｍｅを使用した呼び出し元（アカウント）は、手引を取得するためのＴａｓｋＳｃｈｅｄｕｌｅｒＧｅｔＢｅｓｔＮｅｔｗｏｒｋＴｉｍｅｌｎＲａｎｇｅを使用した同一の呼び出し元（アカウント）である。
HRESULT TaskSchedulerCancelBestNetworkTime (_in const FILETIME *serverSendTime);
パラメーター
ｓｅｒｖｅｒＳｅｎｄＴｉｍｅ
［ｉｎ］ＴａｓｋＳｃｈｅｄｕｌｅｒＧｅｔＢｅｓｔＮｅｔｗｏｒｋＴｉｍｅｌｎＲａｎｇｅによって、前に返却された時刻の手引
返却値
Ｓ＿ＯＫ
時刻の手引のリリースがトラッキングされている
Ｓ＿ＦＡＬＳＥ
時刻の手引が認識されない（値が「期限切れ」又はＴａｓｋＳｃｈｅｄｕｌｅｒＧｅｔＢｅｓｔＮｅｔｗｏｒｋＴｉｍｅｌｎＲａｎｇｅによって以前、返却されていない）
Ｅ＿＊
リクエスト処理中に遭遇するその他の失敗
付録Ｂ
[0057]送信時刻を決定するための例示的な命令又は動作が以下に示される。
【００５１】
[0058]ＳｅｒｖｅｒＳｅｎｄＴｉｍｅのリストは、サービスの起動中、生成され、サービスが終了されるとき、クリアされる。このリストはキャッシュとして扱われ、キャッシュエントリーが間隔の間に収まる場合、すべてのスケジュールを介し繰り返し、再度、ＳｅｒｖｅｒＳｅｎｄＴｉｍｅを計算する必要はなく、キャッシュエントリーは、ＳｅｒｖｅｒＳｅｎｄＴｉｍｅに関する候補であるとみなされ得る。キャッシュは、＜ｋｅｙ，ｖａｌｕｅ＞＝＜ＳｅｒｖｅｒＳｅｎｄＴｉｍｅ，ｍａｐＡｃｃｔＩｄｔｏＦｒｅｑ＞を有するハッシュマップ（ｈａｓｈｍａｐ）として内部で表され得、ここでｍａｐＡｃｃｔＩｄｔｏＦｒｅｑは、頻度に対する所有者アカウント識別子のハッシュマップであって、
ｍａｐ＜ＡＣＣＴＩＤ，  ＤＷＯＲＤ＞ｍａｐＡｃｃｔＩｄｔｏＦｒｅｑ；
として定義される。
＜ＳｅｒｖｅｒＳｅｎｄＴｉｍｅ，ｍａｐＡｃｃｔＩｄｔｏＦｒｅｑ＞のマップは、キー（ＳｅｒｖｅｒＳｅｎｄＴｉｍｅ）に関しソートされる。
ＮＲＴ（ｎｅｘｔｒｕｎｔｉｍｅ）に関しソートされた＜ＮＲＴ＞のリストも保持される。このリストは、ＡＰＩが呼び出されるときはいつも生成される。リストは、アクティブスケジュールすべてに関するＮＲＴをストアしている。
送信時刻を決定するための例示的なアルゴリズムが次に説明される。
【００５２】
１．キャッシュを介し繰り返し、期限が切れている（例えばＮＲＴ＜ＣｕｒｒｅｎｔＴｉｍｅ）エントリーすべてを削除する。
【００５３】
２．ｓｔａｒｔｔｉｍｅ＝＝ｅｎｄＴｉｍｅの場合、キャッシュ＜ＳｅｒｖｅｒＳｅｎｄＴｉｍｅ，ｍａｐＡｃｃｔＩｄｔｏＦｒｅｑ＞に値を追加し、存在しない場合、さもなければ、ＳｅｒｖｅｒＳｅｎｄＴｉｍｅが既にキャッシュに存在しているとき、ｎａｐＡｃｃｔｌｄｔｏＦｒｅｑに頻度を追加又は増加する。
【００５４】
３．ＳｈｒｉｎｋＦａｃｔｏｒがレジストリに定義されている場合、シュリンクファクターに基づいて間隔（ｓｔａｒｔｔｉｍｅ−ｅｎｄＴｉｍｅ）を短かくする。
Ｓｔａｒｔｔｉｍｅが、ｎｅｗＳｔａｒｔＴｉｍｅにプッシュされ、間隔（ｎｅｗＳｔａｒｔＴｉｍｅ−ｅｎｄＴｉｍｅ）となる。定義されていない場合、ｎｅｗＳｔａｒｔＴｉｍｅ＝ｓｔａｒｔｔｉｍｅである。
これは常に、終了時刻の近くで実行され、時刻の手引を生成する。
【００５５】
４．グループコレクションを介し繰り返す。
【００５６】
５．それぞれのグループのスケジュールすべてを通し繰り返す。
【００５７】
６．以下の条件を満たすスケジュールだけを考えられたい。
【００５８】
ａ）Ｒｅｃｕｒｒｅｎｃｅ！＝ＢＯＯＴＵＰ
ｂ）Ｎｅｔｗｏｒｋ  Ｃｏｎｎｅｃｔｉｖｉｔｙ＝ＴＲＵＥ（ネットワーク接続のないスケジュールは、それらが無線通信スピン低減の支援が可能か又は可能ではないので、ＳｅｎｄＳｅｒｖｅｒＴｉｍｅに関し考慮されない）
ｃ）ＩｓＣｅｌｌｕｌａｒＰｒｅｆｅｒｒｅｄ＝１の場合、ＣＥＬＬＵＬＡＲ＝ＯＮ
を有するスケジュールだけを考慮する。ＩｓＣｅｌｌｕｌａｒＰｒｅｆｅｒｒｅｄ＝０の場合、ＣＥＬＬＵＬＡＲの条件を考慮しない。
【００５９】
ｄ）Ａｃｔｉｖｅ＝ＴＲＵＥ
考慮されるスケジュールは、現在アクティブであるスケジュールを含んでいて、与えられたｎｅｗＳｔａｒｔＴｉｍｅ−ｅｎｄｔｉｍｅ及びＭａｘＲｕｎｃｏｕｎｔｓ条件が満たされ、将来もアクティブを維持する。
【００６０】
７．次に説明されるＳｅｒｖｅｒＳｅｎｄＴｉｍｅが、ステップ６において生成されたリストから作成される。
（例えば、ステップ６において作成された）リスト内で選択されたスケジュールそれぞれに対し、Ｎ番目のＲｕｎＴｉｍｅを計算する。Ｎ番目のランタイムは、
再発性の平均に関しては
NRT (N) = NRT (N-1) + CurrentlntervalDuration
再発性の間隔に関しては
NRT (N) = NRT (N-1)+ CurrentlntervalDuration
の式を使用し計算され、
ここでＮＲＴ（０）＝Ｇｒｏｕｐであって、次のランタイム時、アクティブスケジュールである。
【００６１】
以下、２つのカテゴリに属するスケジュールだけを考えられたい。
【００６２】
ａ）条件のないスケジュール及びグループ内のスケジュールのみ。
【００６３】
ｂ）条件のないスケジュール及びグループ内の条件を有していない別のスケジュールもすべて。
【００６４】
グループ内にある条件を有する少なくとも１つのスケジュールが存在する場合、そのグループは、ＳｅｒｖｅｒＳｅｎｄＴｉｍｅに関し考慮されない。
【００６５】
８．この結果、＜ＮＲＴ＞のリスト及びキャッシュ＜ＳｅｒｖｅｒＳｅｎｄＴｉｍｅｓ，ｍａｐＡｃｃｔＩｄｔｏＦｒｅｑ＞となる。
次に、間隔＜ｎｅｗＳｔａｒｔＴｉｍｅ，ｅｎｄＴｉｍｅ＞内において「最良」の時刻の手引が選択される。
ＩｓＰｒｅｆｅｒｒｅｄＣａｃｈｅを設定したレジストリに基づく少なくとも２つの順列があり得る。
【００６６】
ａ）ＩｓＰｒｅｆｅｒｒｅｄＣａｃｈｅ=１の場合、最初、キャッシュ＜ＳｅｒｖｅｒＳｅｎｄＴｉｍｅｓ，ｍａｐＡｃｃｔＩｄｔｏＦｒｅｑ＞内のＳｅｒｖｅｒＳｅｎｄＴｉｍｅを検索する。
【００６７】
１つのＳｅｒｖｅｒＳｅｎｄＴｉｍｅだけが見つかった場合、ステップ１０へ。
【００６８】
複数のＳｅｒｖｅｒＳｅｎｄＴｉｍｅ値が見つかった場合、最大の頻度を有するｓｅｒｖｅｒＳｅｎｄＴｉｍｅを検索し、ステップ１０へ。
【００６９】
同一の最大値を持つ２つ以上のＳｅｒｖｅｒＳｅｎｄＴｉｍｅを有する、複数のＳｅｒｖｅｒＳｅｎｄＴｉｍｅ値が見つかった場合、ＵｓｅＥｎｄｔｉｍｅのレジストリの値に基づいて１つを選択する。
【００７０】
ＵｓｅＥｎｄＴｉｍｅ＝１の場合、
間隔の終わりに近い値を選択する
ＵｓｅＥｎｄＴｉｍｅ＝１の場合、
間隔の始まりに近い値を選択する
その他の場合、キャッシュ内に見つからなかったとき、リスト＜ＮＲＴ＞を調査
ｂ）ＩｓＰｒｅｆｅｒｒｅｄＣａｃｈｅ＝０の場合、最初、リスト＜ＮＲＴ＞内のＳｅｒｖｅｒＳｅｎｄＴｉｍｅを検索。ＳｅｒｖｅｒＳｅｎｄＴｉｍｅが見つかった場合、ステップ１０へ。
【００７１】
複数のＮＲＴが見つかった場合、ＵｓｅＥｎｄＴｉｍｅのレジストリ値に基づいて１つを選択し、
ＵｓｅＥｎｄＴｉｍｅ＝１の場合、
間隔の終わりに近い値を選択
ＵｓｅＥｎｄＴｉｍｅ＝１の場合、
間隔の始まりに近い値を選択、
その他の場合、リスト＜ＮＲＴ＞内に見つからなかったとき、キャッシュ＜ＳｅｒｖｅｒＳｅｎｄＴｉｍｅ，ｍａｐＡｃｃｔＩｄＴｏＦｒｅｑ＞を調査。
【００７２】
９．ステップ８から、ＳｅｒｖｅｒＳｅｎｄＴｉｍｅが見つからなかった場合、
ＳｈｒｉｎｋＦａｃｔｏｒ＝０の場合、
デルタ領域を計算し、キャッシュ＜ＳｅｒｖｅｒＳｅｎｄＴｉｍｅ，ｍａｐＡｃｃｔＩｄｔｏＦｒｅｑ＞からデルタ領域内のＳｅｒｖｅｒＳｅｎｄＴｉｍｅを検索。
デルタ領域は、
Ｓｔａｒｔｔｉｍｅに対しＳｔａｒｔｔｉｍｅ−デルタとして考慮され得、
ＳｅｒｖｅｒＳｅｎｄＴｉｍｅがデルタ領域内においても見つからなかった場合、ＵｓｅｄＥｎｄＴｉｍｅのレジストリ値に基づいてＳｅｒｖｅｒＳｅｎｄＴｉｍｅを割り当てる
ＵｓｅＥｎｄＴｉｍｅ=１ の場合、
ＳｅｒｖｅｒＳｅｎｄＴｉｍｅ＝Ｅｎｄｔｉｍｅである
ＵｓｅｄＥｎｄＴｉｍｅ＝０の場合、
ＳｅｒｖｅｒＳｅｎｄＴｉｍｅ＝ＳｔａｒｔＴｉｍｅである
ＳｈｒｉｎｋＦａｃｔｏｒ＝１の場合、
この場合、ｓｔａｒｔｔｉｍｅが既に新しい値にプッシュされるので、デルタ領域はチェックされ得ない。
【００７３】
ＳｅｒｖｅｒＳｅｎｄＴｉｍｅをＥｎｄＴｉｍｅに割り当てる。
【００７４】
ＳｅｒｖｅｒＳｅｎｄＴｉｍｅ＝ＥｎｄＴｉｍｅである
１０．ステップ８から、ＳｅｒｖｅｒＳｅｎｄＴｉｍｅが見つかった場合、
ａ．ＮｅｔｗｏｒｋＬａｔｅｎｃｙＡｄｊｕｓｔｍｅｎｔ  ＳｅｒｖｅｒＳｅｎｄＴｉｍｅ＝ＳｅｒｖｅｒＳｅｎｄＴｉｍｅ−ＮｅｔｗｏｒｋＬａｔｅｎｃｙＡｄｊｕｓｔｍｅｎｔを用いて、ＳｅｒｖｅｒＳｅｎｄＴｉｍｅを調整する
新しいＳｅｒｖｅｒＳｅｎｄＴｉｍｅ＞ＳｔａｒｔＴｉｍｅかチェックする。（ＳｔａｒｔＴｉｍｅはＳｈｒｉｎｋＦａｃｔｏｒを適用しない）
そうでない場合、ＳｅｒｖｅｒｓｅｎｄＴｉｍｅ＝ＳｔａｒｔＴｉｍｅを割り当てる。（ＳｔａｒｔＴｉｍｅはＳｈｒｉｎｋＦａｃｔｏｒを適用しない）
１１．ここで、ＳｅｒｖｅｒＳｅｎｄＴｉｍｅが計算され、キャッシュ＜ＳｅｒｖｅｒＳｅｎｄＴｉｍｅｓ，ｍａｐＡｃｃｔＩｄｔｏＦｒｅｑ＞内のこのＳｅｒｖｅｒＳｅｎｄＴｉｍｅの値を検索する。
【００７５】
a．キャッシュ内に見つからなかった場合、この値を所有者のアカウント識別子及びfrequency＝１を用いて追加する。
【００７６】
ｂ．キャッシュ内に見つかった場合、アカウント識別子を検索する。アカウント識別子も存在する場合、頻度を増やす。アカウント識別子が存在しない場合、frequency=1を用いてアカウント識別子を追加する。
【００７７】
１２．ＴａｓｋＳｃｈｅｄｕｌｅｒＣａｎｃｅｌＢｅｓｔＮｅｔｗｏｒｋＴｉｍｅが、ある時刻の値を用いて呼び出された場合、それは、キャッシュ＜ＳｅｒｖｅｒＳｅｎｄＴｉｍｅｓ，ｍａｐＡｃｃｔｌｄｔｏＦｒｅｑ＞内のその値を検索する。値がキャッシュ内に見つかった場合、対応するｍａｐＡｃｃｔｌｄｔｏＦｒｅｑが、所有者のアカウント識別子を検索する。ある値がｍａｐＡｃｃｔｌｄｔｏＦｒｅｑにおいて見つかった場合、頻度が減らされる。ｆｒｅｑｕｅｎｃｙ＝０のとき、ｍａｐＡｃｃｔＩｄｔｏＦｒｅからエントリーを削除する。ｍａｐＡｃｃｔｌｄｔｏＦｒｅｑが空である場合も、キャッシュ＜ＳｅｒｖｅｒＳｅｎｄＴｉｍｅｓ，ｍａｐＡｃｃｔＩｄｔｏＦｒｅｑ＞からＳｅｒｖｅｒＳｅｎｄＴｉｍｅの値を削除する。
留意点：
１）ＮｅｔｗｏｒｋＬａｔｅｎｃｙＡｄｊｕｓｔｍｅｎｔは、ネットワーク待ち時間及びプロセス遅延を使用し決定される値である。これは、ネットワーク待ち時間を説明する構成可能なレジストリエントリーである。ＳｅｒｖｅｒＳｅｎｄＴｉｍｅが返却されるときはいつも、それはＮｅｔｗｏｒｋＬａｔｅｎｃｙＡｄｊｕｓｔｍｅｎｔによるオフセットである必要がある。
【００７８】
２）機器の絶対時間が変化した場合、キャッシュ＜ＳｅｒｖｅｒＳｅｎｄＴｉｍｅ，ｆｒｅｑｕｅｎｃｙ＞内の時刻の値は、時刻変更に基づいて調整される必要がある。これは、ｔｉｍｅｃｈａｎｇｅイベント通知を登録することによって実行され得る。
【００７９】
３）ＡＰＩが開始時刻／終了時刻を用いて非常に細かく呼び出されるとき、（例えば、間隔が１０年より遅い）シナリオが存在し得る。そのような場合、（例えば、間隔が現在時刻から２４時間以内である）境界チェックが、ＮＲＴ＜Ｎ＞を計算する代わりにＡＰＩにおいて実行される。
【００８０】
４）ＳｔａｒｔｔｉｍｅＰｒｅｆｅｒｒｅｄ／ＥｎｄｔｉｍｅＰｒｅｆｅｒｒｅｄを含むレジストリの値及びＦｒｅｑｕｅｎｃｙＰｒｅｆｅｒｒｅｄは、構成可能なレジストリエントリーである。選択アルゴリズムは、これらのレジストリの値に基づいて動的に変更され得る。
【符号の説明】
【００８１】
１０２  第１の計算装置
１０４  第２の計算装置
１０６  ネットワーク
１０８  スケジューラー
２０２  計算装置
２０４  プロセッサー
２０６  メモリー領域
２０８  スケジュール
２１０  起動時刻
２１２  プロセス遅延
２１４  ネットワーク待ち時間
２１６  送信時刻
２１８  インターフェースコンポーネント
２２０  キャッシュコンポーネント
２２２  手引コンポーネント
２２４  発行コンポーネント
６０２  携帯計算装置
６０４  アプリケーションプログラム
６０６  アプリケーションプログラム
６１０  サーバー
６１２  サーバー
【図１】
0005592380.tif 000002
【図２】
0005592380.tif 000003
【図３】
0005592380.tif 000004
【図４】
0005592380.tif 000005
【図５】
0005592380.tif 000006
【図６】
0005592380.tif 000007