(57)【要約】【課題】  クライアント装置がスリープ状態に移行した後に、クライアント装置が管理サーバーからの指示を受信することが可能となる仕組みを提供することを目的とする。【解決手段】  本発明は、管理サーバーからの指示を受信するために前記管理サーバーと通信を行うクライアント装置は、一定時間、前記クライアント装置がユーザー操作を受け付けなかったことにより、前記クライアント装置の電源がスリープ状態に移行される。前記クライアント装置の電源がスリープ状態へ移行された後、ユーザー操作を受け付けることなく一時的に通常状態に移行され、前記管理サーバーとの通信の後、前記クライアント装置の電源が通常状態からスリープ状態に移行されることを特徴とする。【選択図】  図１０
2019040413.tif 000002
【特許請求の範囲】
【請求項１】
クライアント装置への指示を管理する管理サーバーからの指示を受信するために、前記管理サーバーと通信を行う通信手段と、
前記クライアント装置の電源を、通常状態からスリープ状態に、または、スリープ状態から通常状態に移行させる移行手段と、を有し、
前記移行手段は、一定時間、前記クライアント装置がユーザー操作を受け付けなかったことにより、前記クライアント装置の電源を通常状態からスリープ状態に移行させるクライアント装置において、
前記通信手段は、ユーザー操作を受け付けたことにより前記クライアント装置の電源がスリープ状態から通常状態に移行した場合に、前記クライアント装置からの要求なしに前記管理サーバーからの指示を受信することが可能な第１の通信方式によって前記管理サーバーと通信を行い、
前記移行手段は、前記クライアント装置の電源が通常状態からスリープ状態へ移行された後、ユーザー操作を受け付けることなく前記クライアント装置の電源をスリープ状態から一時的に通常状態に移行させ、
前記通信手段は、前記クライアント装置の電源が一時的に通常状態である際に、前記管理サーバーと通信を行い、
前記移行手段は、前記クライアント装置の電源が一時的に通常状態である際に行われた前記通信手段による通信の後、前記クライアント装置の電源を通常状態からスリープ状態に移行させることを特徴とするクライアント装置。
【請求項２】
前記通信手段は、前記クライアント装置の電源が一時的に通常状態である際に、前記第１の通信方式とは異なる第２の通信方式によって前記管理サーバーとの通信を行い、前記管理サーバーに対して前記管理サーバーで管理される指示を要求することを特徴とする請求項１に記載のクライアント装置。
【請求項３】
前記通信手段は、前記第１の通信方式によって通信を行う際に、前記第２の通信方式による通信とは異なり、前記クライアント装置と前記管理サーバーとの間に前記クライアント装置からの要求なしに前記管理サーバーからの指示を受信するためのセッションを確立することを特徴とする請求項２に記載のクライアント装置。
【請求項４】
前記管理サーバーからの指示に基づく処理を実行する実行手段を更に有し、
前記移行手段は、前記クライアント装置の電源がスリープ状態から一時的に通常状態に移行された際に行われた前記通信手段による通信によって前記管理サーバーからの指示を受信した場合、前記実行手段による前記指示に基づく処理が完了した後、前記一定時間、待機することなく、前記クライアント装置の電源を通常状態からスリープ状態に移行させることを特徴とする請求項１乃至３のいずれか１項に記載のクライアント装置。
【請求項５】
前記管理サーバーは、前記クライアント装置の状態情報を管理しており、
前記クライアント装置への指示を前記管理サーバーに対して登録するアプリケーションサーバーおよび前記クライアント装置はいずれも、前記管理サーバーが管理する前記クライアント装置の状態情報を変更および参照することを特徴とする請求項１乃至４のいずれか１項に記載のクライアント装置。
【請求項６】
前記移行手段は、所定時間おきに、前記クライアント装置の電源をスリープ状態から一時的に通常状態に移行させることを特徴とする請求項１乃至５のいずれか１項に記載のクライアント装置。
【請求項７】
前記移行手段は、
スケジュールにより前記クライアント装置の電源が通常状態からスリープ状態に移行された場合、第１の所定時間おきに、前記クライアント装置の電源をスリープ状態から一時的に通常状態に移行させ、
一定時間、ユーザー操作を受け付けなかったことにより前記クライアント装置の電源が通常状態からスリープ状態に移行された場合、第２の所定時間おきに、前記クライアント装置の電源をスリープ状態から一時的に通常状態に移行させ、
前記第１の所定時間は、前記第２の所定時間よりも長いことを特徴とする請求項６に記載のクライアント装置。
【請求項８】
前記移行手段は、スケジュールによって前記クライアント装置の電源が通常状態からスリープ状態に移行された場合、所定時刻に、前記クライアント装置の電源をスリープ状態から一時的に通常状態に移行させることを特徴とする請求項１乃至５のいずれか１項に記載のクライアント装置。
【請求項９】
前記指示に基づく処理の実行履歴を管理する管理手段を更に有し、
前記所定時刻は、前記管理される実行履歴に基づき決定されることを特徴とする請求項８に記載のクライアント装置。
【請求項１０】
前記実行手段は、ユーザー操作を受け付けたことにより前記クライアント装置の電源がスリープ状態から通常状態に移行された際に行われた前記通信手段による通信によって前記管理サーバーからの指示を受信した場合、前記受け付けたユーザー操作に対応する処理が完了した後に、前記受信した指示に基づく処理を実行することを特徴とする請求項４乃至９のいずれか１項に記載のクライアント装置。
【請求項１１】
前記実行手段は、ユーザー操作を受け付けたことによって前記クライアント装置の電源がスリープ状態から通常状態に移行された際に行われた前記通信手段による通信によって前記管理サーバーからの指示を受信した場合であって、
前記受信した指示に基づく処理が前記ユーザー操作に基づく処理を妨げる処理である際に、前記ユーザー操作に基づく処理を優先して実行し、
前記受信した指示に基づく処理が前記ユーザー操作に基づく処理を妨げる処理でない際に、前記ユーザー操作に基づく処理と前記受信した指示に基づく処理とを並行して実行することを特徴とする請求項１０に記載のクライアント装置。
【請求項１２】
クライアント装置への指示を管理する管理サーバーからの指示を受信するために、前記管理サーバーと通信を行う通信手段と、
前記クライアント装置の電源を、通常状態からスリープ状態に、または、スリープ状態から通常状態に移行させる移行手段と、を有し、
一定時間、前記クライアント装置がユーザー操作を受け付けなかったことにより、前記クライアント装置の電源が通常状態からスリープ状態に移行するクライアント装置の制御方法において、
ユーザー操作を受け付けたことにより前記クライアント装置の電源がスリープ状態から通常状態に移行した場合に、前記クライアント装置からの要求なしに前記管理サーバーからの指示を受信することが可能な通信方式によって前記管理サーバーと通信を行い、
前記クライアント装置の電源が通常状態からスリープ状態へ移行した後、ユーザー操作を受け付けることなく前記クライアント装置の電源をスリープ状態から一時的に通常状態に移行させ、
前記クライアント装置の電源が一時的に通常状態である際に、前記管理サーバーと通信を行い、
前記クライアント装置の電源が一時的に通常状態である際に行われた前記通信の後、前記クライアント装置の電源を通常状態からスリープ状態に移行させることを特徴とする制御方法。
【請求項１３】
請求項１乃至１１のいずれか１項に記載の手段としてコンピューターを機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、管理サーバーから指示を受信することが可能であるクライアント装置、制御方法、およびプログラムに関する。
【背景技術】
【０００２】
近年、インターネットに家電製品や自動車などのオブジェクトをクライアントとして接続する「Ｉｎｔｅｒｎｅｔ  ｏｆ  Ｔｈｉｎｇｓ」（以降、ＩｏＴと称する）を実現するシステムが多く利用されるようになってきている。
【０００３】
また、画像形成装置の多機能化が進み、Ｍｕｌｔｉ  Ｆｕｎｃｔｉｏｎ  Ｐｒｉｎｔｅｒ（以降、ＭＦＰと称する）と呼ばれる複合機もＩｏＴクライアントとして対応することが可能となった。ＩｏＴでは、膨大な数のＩｏＴクライアントがシステムに接続されることを想定している。ＩｏＴシステムはＩｏＴクライアントからの膨大な量の情報を収集、分析することでＩｏＴクライアントおよびそれを利用するユーザーに対して付加価値を提供する。例えば、複合機が接続されるＩｏＴシステムとしてのデバイス管理サービスは、ユーザーの利用状況をリアルタイムに監視することで、トナーカートリッジや印刷用紙等の消耗品の交換タイミングを正確に予測することが可能となる。さらに、一定期間印刷し続けることで劣化する印刷品質の調整（以降、キャリブレーションと称する）の実行をデバイスに指示したりすることが可能となる。
【０００４】
例えばＡｍａｚｏｎ  Ｗｅｂ  Ｓｅｒｖｉｃｅ（以降、ＡＷＳと称する）が提供するサービスであるＡＷＳ  ＩｏＴにはＤｅｖｉｃｅ  ＳｈａｄｏｗというサービスとＩｏＴクライアントとの間で、クライアントの状態をリアルタイムに共有する機能がある。この機能を利用することでサービスはクライアントの状態をリアルタイムに監視することができ、それらクライアントから収集した情報を分析し、クライアントに対し必要な指示を配信することが可能となる。
【０００５】
ＩｏＴシステムにおいてはＩｏＴクライアントがサービスに常時接続されていることを前提としている。一方、複合機が一定時間未使用である場合や、夜間や営業時間外等のあらかじめ使用されないことが見込まれる時間帯に休眠状態にする機能が、複合機には備わっている。この機能をスリープモードと呼ぶ。これにより、複合機は消費電力の削減を実現としている。スリープモード中の複合機は、インターネット接続が切断されているため、サービスから配信された指示を受信および実行することができない。
【０００６】
特許文献１はＩｏＴシステムについてではないが、シャットダウン処理後に定期アップデートが設定されている場合には、情報処理装置では、スリープ状態に移行する前に、アップデートのための復帰時刻にアラームを設定しておくことが記載されている。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２０１４−０２１６７８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
上述したＩｏＴシステムは、システム内にあるクライアント装置への指示やクライアント装置の状態情報を管理する管理サーバーとクライアント装置とがインターネットを介して相互にリアルタイムに通信を行うことが特徴である。スリープ状態であるクライアント装置は、管理サーバーとのセッションは切断されており通信ができないため、システムからの指示を受信することができない。
【０００９】
上述した特許文献１では、スリープ状態に移行した後に実行する処理についての指示を、スリープ状態に移行する前に情報処理装置が外部サーバーから受信している。したがって、情報処理装置がスタンバイ状態中にサービスから受信した指示については、スリープ状態に移行しても実行することができるが、スリープモードに移行した後にサービスから配信された指示を受信することができない。
【００１０】
上記課題を鑑みて本発明は、クライアント装置がスリープ状態に移行した後に、ユーザー操作を受け付けることなく一時的に通常状態に移行させて、クライアント装置が管理サーバーからの指示を受信することが可能となる仕組みを提供することを目的とする。
【課題を解決するための手段】
【００１１】
上記課題を解決するために、本発明は、クライアント装置への指示を管理する管理サーバーからの指示を受信するために、前記管理サーバーと通信を行う通信手段と、前記クライアント装置の電源を、通常状態からスリープ状態に、または、スリープ状態から通常状態に移行させる移行手段と、を有し、前記移行手段は、一定時間、前記クライアント装置がユーザー操作を受け付けなかったことにより、前記クライアント装置の電源を通常状態からスリープ状態に移行させるクライアント装置において、前記通信手段は、ユーザー操作を受け付けたことにより前記クライアント装置の電源がスリープ状態から通常状態に移行された場合に、前記クライアント装置からの要求なしに前記管理サーバーからの指示を受信することが可能な通信方式によって前記管理サーバーと通信を行い、前記移行手段は、前記クライアント装置の電源が通常状態からスリープ状態へ移行された後、ユーザー操作を受け付けることなく前記クライアント装置の電源をスリープ状態から一時的に通常状態に移行させ、前記通信手段は、前記クライアント装置の電源が一時的に通常状態である際に、前記管理サーバーと通信を行い、前記移行手段は、前記クライアント装置の電源が一時的に通常状態である際に行われた前記通信手段による通信の後、前記クライアント装置の電源を通常状態からスリープ状態に移行させることを特徴とする。
【発明の効果】
【００１２】
本発明により、クライアント装置がスリープ状態に移行した後に、ユーザー操作を受け付けることなく一時的に通常状態に移行させて、クライアント装置が管理サーバーからの指示を受信することが可能となる。
【図面の簡単な説明】
【００１３】
【図１】システム全体例を示す図
【図２】ハードウェア構成例を示す図
【図３】ソフトウェア構成例を示す図
【図４】状態変更指示メッセージの一例を示す図
【図５】クライアント装置１０１のスリープ移行時の処理の示すフローチャート
【図６】クライアント装置１０１がスリープ移行時に状態管理サーバー１０２に送信する状態メッセージの一例を示す図
【図７】クライアント装置１０１のスリープ復帰時の処理を示すフローチャート
【図８】状態管理サーバー１０２を介した出版購読モデルに基づく状態変更指示メッセージ送受信の処理を示すシーケンス
【図９】状態変更指示メッセージの確認タイマーを設定するクライアント装置１０１がスリープ移行時の処理を示すフローチャート
【図１０】状態変更指示メッセージ確認タイマーが設定されている際のクライアント装置１０１スリープ復帰時の処理を示すフローチャート
【図１１】状態変更指示メッセージ確認タイマーに基づき復帰したクライアント装置１０１の状態変更指示メッセージを確認する処理を示すフローチャート
【図１２】スリープ移行の理由に基づき状態変更指示メッセージの確認タイマーを設定するクライアント装置１０１がスリープ移行時の処理を示すフローチャート
【図１３】スリープ復帰の理由に基づきクライアント装置１０１が状態変更指示メッセージの反映タイミングを制御する処理を示すフローチャート
【図１４】状態変更指示メッセージの内容にライアント装置１０１が状態変更指示メッセージの反映タイミングを制御する処理を示すフローチャート
【図１５】図１４においてクライアント装置１０１が受信する状態変更指示メッセージの例を示す図
【図１６】図１４においてクライアント装置１０１に表示される状態変更指示反映確認ダイアログの例を示す図
【図１７】状態変更指示の実行履歴に基づき状態変更指示メッセージの確認タイマーを設定するクライアント装置１０１がスリープ移行時の処理を示すフローチャート
【発明を実施するための形態】
【００１４】
以下、本発明を実施するための形態について図面を用いて説明する。
【００１５】
（実施例１）
図１は、本実施例に係るシステムの全体構成例を示す図である。
【００１６】
ネットワーク１００は、クライアント装置１０１、状態管理サーバー１０２、アプリケーションサーバー１０３を接続するネットワークである。ネットワーク１００は、各構成要素間の通信を行うための基盤であり、Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ（以降、ＷＡＮと称する）あるいはＬｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ  （以降、ＬＡＮと称する）であってもかまわない。
【００１７】
クライアント装置１０１は、ネットワーク１００を介して状態管理サーバー１０２、アプリケーションサーバー１０３と相互に接続する。本実施例において、クライアント装置はＭＦＰ（Ｍｕｌｔｉ  Ｆｕｎｃｔｉｏｎ  Ｐｒｉｎｔｅｒ）を例に説明するが、ネットワーク１００を介した通信機能を有し、装置の使用状況に応じてスリープモードに状態遷移する装置であればＭＦＰ以外でもよい。スリープモードとは、クライアント装置の消費電力を削減するために一部の機能以外が使用不可となり、かつ、クライアント装置がネットワークに接続されていないスリープ状態を指す。これに対して、スタンバイモードとは、クライアント装置がネットワークに接続されていて、かつ、ユーザーがクライアント装置を使用可能である通常状態を指す。また、図１ではネットワーク１００に接続されるクライアント装置１０１を１台図示しているが、クライアント装置１０１は複数台でもよい。つまり、１台以上のクライアント装置１０１がネットワーク１００を介して状態管理サーバー１０２および状態管理サーバー１０２に接続した構成をとることができる。
【００１８】
状態管理サーバー１０２は、クライアント装置１０１の状態を管理するサーバーである。クライアント装置１０１は、自身の状態に変化があった場合に状態管理サーバー１０２にその値を送信する。またアプリケーションサーバー１０３は状態管理サーバー１０２を介してクライアント装置１０１の状態を監視し、状態の変化に応じた指示を状態管理サーバー１０２に送信する。状態管理サーバー１０２はアプリケーションサーバー１０３からの指示をクライアント装置１０１に送信する。
【００１９】
アプリケーションサーバー１０３は、状態管理サーバー１０２を介してクライアント装置１０１の状態を監視し、状態の変化に応じてクライアント装置１０１へ指示を生成するサーバーである。
【００２０】
図２は、情報処理装置のハードウェア構成例を示す図である。なお、本実施例における情報処理装置は、クライアント装置１０１およびデータセンター上のサーバーコンピューターである。状態管理サーバー１０２およびアプリケーションサーバー１０３はそれぞれ、サーバーコンピューター上で構築される仮想マシンによってその機能が実現される。ここで、仮想マシンとは、仮想化技術によって、サーバーを物理的な構成にとらわれずに論理的な単位で分割し、それぞれが独立したオペレーティングシステムをもって動作する論理的なコンピューターである。
【００２１】
ＣＰＵ２０１は、ＲＯＭ２０３のプログラム用ＲＯＭに記憶された、あるいはハードディスク等の外部メモリ２１１からＲＡＭ２０２にロードされたオペレーティングシステム（以下、ＯＳと略す）やアプリケーション等のプログラムを実行する。また、ＣＰＵ２０１は、システムバス２０４に接続される各ブロックを制御する。後述する各シーケンスの処理は、このプログラムの実行により実現できる。
【００２２】
ＲＡＭ２０２は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。操作部Ｉ／Ｆ２０５は、操作部２０９からの入力を制御する。ＣＲＴＣ２０６は、ＣＲＴディスプレイの表示を制御するＣＲＴコントローラーである。
【００２３】
ＤＫＣ２０７は、各種データを記憶するハードディスク等の外部メモリ２１１におけるデータアクセスを制御するディスクコントローラーである。ＮＣ２０８は、ネットワーク１００を介して接続されたサーバーコンピューターや他の機器との通信制御処理を実行するネットワークコントローラーである。
【００２４】
なお、後述のフローチャートなどの処理については、特に断りのない限り、ハード上の主体はＣＰＵ２０１であり、ソフトウェア上の主体は外部メモリ２１１にインストールされたアプリケーションプログラムである。
【００２５】
図３は、システムを構成する各要素のソフトウェアモジュール構成を示す図である。これらのソフトウェアモジュールは各構成要素の外部メモリ２１１に格納され、ＣＰＵ２０１によって実行される。
【００２６】
まず、クライアント装置１０１には、クライアント装置稼働管理モジュール３１０と、状態管理サーバー連携モジュール３２０と、クライアント装置管理モジュール３３０と、が含まれる。
【００２７】
クライアント装置稼働管理モジュール３１０（以降、モジュール３１０と称する）は、クライアント装置１０１の稼働状況を管理して、クライアント装置１０１の通常状態からスリープ状態への移行を制御するモジュールである。モジュール３１０は、クライアント装置のスリープ状態から通常状態への移行（復帰）も制御する。モジュール３１０は、制御部３１１、タイマー管理部３１２、およびタイマー実行部３１３を有する。
【００２８】
制御部３１１は、モジュール３１０の全体を制御し、ソフトウェアモジュールの各構成要素に対する指示や各構成要素の管理を行う。タイマー管理部３１２は、クライアント装置１０１のスリープモードへの移行およびスリープモードからの復帰を行うための条件となるタイマー情報を管理する。タイマー管理部３１２が管理するタイマー情報の一例を、表１のタイマー情報テーブルで示す。
【００２９】
【表１】
2019040413.tif 000003
【００３０】
ＩＤカラムは、モジュール３１０において一意にタイマー情報を識別するための識別子を格納するカラムである。
【００３１】
動作種別カラムは、モジュール３１０においてタイマーを実行する際の動作種別を識別するための情報を格納するカラムである。例えば、カラムの値が「無使用」「スケジュール移行」の場合には、レコードが、クライアント装置１０１がスリープモードへ移行する際のタイマー情報であることを示す。また、カラムの値が「スケジュール復帰」の場合は、レコードが、クライアント装置１０１がスリープモードから復帰する際のタイマー情報であることを示す。
【００３２】
条件カラムは、モジュール３１０において動作種別カラムの値に対応するタイマー実行の条件値を格納するカラムである。動作種別カラムの値が「無使用」であるレコードの場合、条件カラムにはクライアント装置１０１が継続して無使用状態であったときにスリープモードに移行するまでの時間を指定する値が格納される。例えば表１に示すＩＤカラムの値が「１」のレコードの場合には、クライアント装置１０１が４時間無使用状態を継続するとスリープモードに移行することを意味する。また、動作種別カラムの値が「スケジュール移行」のレコードの場合、条件カラムにはクライアント装置１０１が定期的にスリープモードに移行する日時を指定する値が格納される。例えば表１に示すＩＤカラムの値が「２」のレコードの場合には、クライアント装置１０１は毎日２１時にスリープモードに移行することを意味する。また、動作種別カラムの値が「スケジュール復帰」のレコードの場合、条件カラムにはクライアント装置１０１が定期的にスリープモードから復帰する日時を指定する値が格納される。例えば表１に示すＩＤカラムの値が「３」のレコードの場合には、クライアント装置１０１は毎日８時にスリープモードから復帰することを意味する。
【００３３】
次に、タイマー実行部３１３は、タイマー管理部３１２のタイマー情報テーブル（表１）に登録されたタイマー情報に従ってクライアント装置１０１をスリープモードに移行あるいはスリープモードからの復帰を行う。なお、モジュール３１０はクライアント装置１０１がスリープモードに移行した後も稼働し続けるモジュールである。
【００３４】
また、状態管理サーバー連携モジュール３２０（以降、モジュール３２０と称する）は、クライアント装置１０１の状態情報を状態管理サーバー１０２に送信する。さらに、モジュール３２０は、状態管理サーバー１０２を介してアプリケーションサーバー１０３が生成した状態変更指示を受信する。モジュール３２０は、通信部３２１、メッセージ生成部３２２、メッセージ解析部３２３、タイマー管理部３２４、および履歴管理部３２５を有する。
【００３５】
通信部３２１は、ＮＣ２０８を介してネットワーク１００で接続される状態管理サーバー１０２と通信を行う。
【００３６】
メッセージ生成部３２２は、クライアント装置管理モジュール３３０から取得したクライアント装置状態情報を用いてクライアント状態メッセージを生成する。生成されたクライアント状態メッセージは、通信部３２１を介して状態管理サーバー１０２に送信される。
【００３７】
メッセージ解析部３２３は、通信部３２１を介して状態管理サーバー１０２から受信した状態変更指示メッセージの解析を行い、対応するクライアント装置管理モジュール３３０に送信する。なお、クライアント装置管理モジュール３３０は複数あるものとする。
【００３８】
タイマー管理部３２４は、クライアント装置１０１がスリープモードである間に状態管理サーバー１０２に状態変更指示メッセージの更新確認を実行する間隔を管理する。タイマー管理部３２４が管理するメッセージ確認間隔の一例を、表２のメッセージ確認間隔テーブルで示す。
【００３９】
【表２】
2019040413.tif 000004
【００４０】
ＩＤカラムは、モジュール３２０において一意にメッセージ確認間隔を識別するための識別子を格納するカラムである。
【００４１】
確認間隔カラムは、モジュール３２０が状態管理サーバー１０２に状態変更指示メッセージの更新確認を行う際の実行間隔の値を格納するカラムである。表２では、クライアント装置１０１がスリープモードである間は、タイマー管理部３２４が１５分おきに状態変更指示メッセージの更新確認を実行する例を示している。
【００４２】
次に、履歴管理部３２５は、メッセージ解析部３２３によって解析された状態変更指示メッセージに基づく処理を、対応するクライアント装置管理モジュール３３０が実行した場合の実行履歴を管理する。履歴管理部３２５が管理する状態変更指示メッセージ実行履歴の一例を、表３の実行履歴テーブルで示す。
【００４３】
【表３】
2019040413.tif 000005
【００４４】
ＩＤカラムはモジュール３２０において、一意に実行履歴を識別するための識別子を格納するカラムである。
【００４５】
アプリケーション名カラムはモジュール３２０において、メッセージ解析部３２３が状態管理サーバー１０２から受信した状態変更指示メッセージの生成元であるアプリケーションサーバー名を格納するカラムである。
【００４６】
日時情報カラムは、状態変更指示メッセージの実行結果としてのクライアント状態メッセージをメッセージ生成部３２２が状態管理サーバー１０２に送信した日時情報を格納するカラムである。状態変更指示メッセージはメッセージ解析部３２３によって解析されて、対応するクライアント装置管理モジュール３３０がそのメッセージに基づく処理を実行する。
【００４７】
また、クライアント装置管理モジュール３３０（以降、モジュール３３０と称する）は、メッセージ解析部３２３が受信した状態変更指示メッセージのクライアント装置１０１への反映を行うモジュールである。モジュール３３０は複数あってもよい。状態変更指示メッセージは、アプリケーションサーバー１０３によって生成され、状態管理サーバー１０２を介してメッセージ解析部３２３に送信される。モジュール３３０は、制御部３３１、クライアント管理部３３２、メッセージ解析部３３３、およびメッセージ実行部３３４を有する。
【００４８】
制御部３３１は、モジュール３３０の全体を制御し、ソフトウェアモジュールの各構成要素に対する指示や各構成要素の管理を行う。クライアント管理部３３２は、クライアント装置１０１の各種状態値、設定値を管理する。メッセージ解析部３３３は、通信部３２１から受信した状態変更指示メッセージの詳細な解析を行い、メッセージ実行部３３４で実行する処理を確定する。
【００４９】
メッセージ実行部３３４は、メッセージ解析部３３３で解析した内容に従いクライアント装置１０１で該当するモジュールの設定変更や状態変更を行う。また、メッセージ実行部３３４は、処理が完了するとクライアント管理部３３２で管理する各種状態値、設定値を更新する。
【００５０】
状態管理サーバー１０２は、状態管理サーバーモジュール３４０（以降、モジュール３４０と称する）を持つ。モジュール３４０は、クライアント装置１０１の状態を管理し、クライアント装置１０１の状態に変更があれば連携するアプリケーションサーバー１０３にその変更を通知する。また、モジュール３４０は、アプリケーションサーバー１０３からクライアント装置１０１に対する状態変更指示メッセージを受信し、クライアント装置１０１にそのメッセージを通知することでクライアント装置１０１に状態の変更を指示する。モジュール３４０は、通信部３４１、クライアント管理部３４２、クライアントデータベース３４３、接続管理部３４４、接続管理データベース３４５、権限管理データベース３４６、およびメッセージ生成部３４７を有する。
【００５１】
通信部３４１は、ＮＣ２０８を介して、ネットワーク１００で接続されるクライアント装置１０１およびアプリケーションサーバー１０３との通信を行う。
【００５２】
クライアント管理部３４２は、状態管理サーバー１０２に接続されるクライアント装置１０１の状態情報を管理する。クライアント装置１０１の状態情報はクライアントデータベース３４３に格納される。クライアントデータベース３４３に格納され、クライアント管理部３４２で管理されるクライアント装置の状態情報の一例を、表４のクライアント装置状態情報テーブルで示す。
【００５３】
【表４】
2019040413.tif 000006
【００５４】
状態情報ＩＤカラムは、モジュール３４０に接続されるクライアント装置１０１を一意に識別するための識別子を管理するカラムである。
【００５５】
状態情報名カラムは、モジュール３４０に接続されるクライアント装置１０１の名称を管理するカラムである。
【００５６】
状態情報カラムは、モジュール３４０に接続するクライアント装置１０１の状態情報を管理するカラムである。状態情報カラムで管理されるクライアント装置１０１の状態情報に一例を図４に示す。
【００５７】
図４は、状態管理サーバー１０２が管理するクライアント装置１０１の状態情報の一例を示した図である。
【００５８】
図４（ａ）に示す状態情報ファイル４００は、クライアント装置１０１の状態情報を状態管理サーバー１０２が管理するためのファイルであり、状態管理サーバー１０２が管理するクライアント装置１０１と対応付けて存在する。状態情報ファイル４００は、状態情報部４０１、指示部４０２、状態部４０３、バージョン４０４、およびタイムスタンプ４０５を有する。本実施例において、状態情報ファイル４００のフォーマットをＪａｖａＳｃｒｉｐｔ（登録商標）  Ｏｂｊｅｃｔ  Ｎｏｔａｔｉｏｎ形式（以降、ＪＳＯＮ形式と称する）で記載しているが、そのフォーマットを限定するものではない。
【００５９】
状態情報部４０１は、アプリケーションサーバー１０３からの指示を示す指示部４０２とクライアント装置１０１の現在の状態を示す状態部４０３とを含む。指示部４０２は、アプリケーションサーバー１０３からの指示内容が格納される。クライアント装置１０１がアプリケーションサーバー１０３からの指示による変更後の状態の値が格納される。なお、指示部４０２の値が空の場合は、アプリケーションサーバー１０３からの指示がないことを示す。状態部４０３は、クライアント装置１０１の現在の状態の値が格納される。
【００６０】
バージョン４０４は、状態情報ファイル４００のバージョンを示し、クライアント装置１０１およびアプリケーションサーバー１０３によって状態情報ファイル４００が更新されるたびに値が変更される。タイムスタンプ４０５は、状態情報ファイル４００がクライアント装置１０１およびアプリケーションサーバー１０３によって更新された際にタイムスタンプ情報が格納される。なお、図４（ｂ）および図４（ｃ）の説明については後述する。
【００６１】
図３の説明に戻る。接続管理部３４４は、ネットワーク１００を介して状態管理サーバー１０２と接続されるクライアント装置１０１およびアプリケーションサーバー１０３の接続情報を管理する。状態管理サーバー１０２に現在接続されているクライアント装置１０１およびアプリケーションサーバー１０３の接続情報は接続管理データベース３４５に格納される。接続管理データベース３４５に格納されて接続管理部３４４で管理される状態管理サーバー１０２の接続情報の一例を、表５の接続情報テーブルで示す。
【００６２】
【表５】
2019040413.tif 000007
【００６３】
接続ＩＤカラムは、状態管理サーバー１０２に現在接続されているクライアント装置１０１またはアプリケーションサーバー１０３を一意に識別するための識別子を格納するカラムである。
【００６４】
接続クライアント名カラムは、状態管理サーバー１０２に現在接続されているクライアント装置１０１またはアプリケーションサーバー１０３の名称を格納するカラムである。
【００６５】
出版状態情報名カラムは、更新可能な状態情報名を格納するカラムである。
【００６６】
購読状態情報名カラムは、参照可能な状態情報名を格納するカラムである。
【００６７】
次に、状態管理サーバー１０２に接続されたクライアント装置１０１およびアプリケーションサーバー１０３がアクセス可能なクライアント装置１０１の状態情報に関する権限情報は権限管理データベース３４６に格納される。権限管理データベース３４６に格納されて接続管理部３４４で管理される状態情報への権限情報の一例を、表６の権限情報テーブルで示す。
【００６８】
【表６】
2019040413.tif 000008
【００６９】
接続クライアント名カラムは、状態管理サーバー１０２が権限情報を管理するクライアント装置１０１およびアプリケーションサーバー１０３の名称を格納するカラムである。本実施例においては、接続クライアント名カラムの値が「ｍｆｐ１」または「ｍｆｐ２」であるレコードが、クライアント装置１０１の権限情報である。また、本実施例においては、接続クライアント名カラムの値が「ａｐｐＳｅｒｖｅｒ１」または「ａｐｐＳｅｒｖｅｒ２」であるレコードが、アプリケーションサーバー１０３の権限情報である。
【００７０】
状態情報ＩＤカラムは、接続クライアント名カラムの値に該当するクライアント装置１０１あるいはアプリケーションサーバー１０３がアクセス可能な状態情報を一意に識別するための識別子を格納するカラムである。
【００７１】
状態情報名カラムは、接続クライアント名カラムの値で示すクライアント装置１０１またはアプリケーションサーバー１０３がアクセス可能な状態情報を示す。状態情報名カラムには、どのクライアント装置の状態情報であるかを示すクライアント装置名が格納される。
【００７２】
権限カラムは、状態情報ＩＤカラムの値に該当するクライアント装置状態情報テーブル（表４）の状態情報ファイルに対するアクセス権限に対応する値を格納するカラムである。本実施例においては値が「Ｐｕｂｌｉｓｈ」の場合には、状態情報ファイルの更新権限を有することを意味し、「Ｓｕｂｓｃｒｉｂｅ」の場合には、状態情報ファイルの参照権限を有することを意味する。権限情報テーブルに示す例としては、クライアント装置１０１に対応する「ｍｆｐ１」、「ｍｆｐ２」はそれぞれ、自身の状態情報ファイルの更新および参照権限を有する。また、アプリケーションサーバー１０３に対応する「ａｐｐＳｅｒｖｅｒ１」は「ｍｆｐ１」、「ｍｆｐ２」それぞれの状態情報ファイルの更新および参照権限を有する。一方、アプリケーションサーバー１０３に対応する「ａｐｐＳｅｒｖｅｒ２」は「ｍｆｐ１」の状態情報ファイルの参照権限のみを有することを意味する
メッセージ生成部３４７は、アプリケーションサーバー１０３から受信した状態変更指示に基づき状態変更指示メッセージを生成する。生成された状態変更指示メッセージは、通信部３４１を介して該当するクライアント装置１０１に送信される。
【００７３】
また、アプリケーションサーバー１０３は、アプリケーションサーバーモジュール３５０（以降、モジュール３５０と称する）を持つ。モジュール３５０は、クライアント装置１０１から受信する情報に応じて、クライアント装置１０１の状態変更の必要が有ると判断した場合には、状態管理サーバー１０２を介してクライアント装置１０１の状態変更指示を送信する。モジュール３５０は、通信部３５１、およびメッセージ生成部３５２を封する。なお、アプリケーションサーバー１０３がクライアント装置１０１から受信する情報とその情報を用いて実行する処理ついては、特にその詳細な内容を限定するものではないため、説明を省略する。
【００７４】
通信部３５１は、ＮＣ２０８を介してネットワーク１００で接続されるクライアント装置１０１および状態管理サーバー１０２と通信を行う。
【００７５】
メッセージ生成部３５２は、クライアント装置１０１から受信した情報に応じて状態変更指示メッセージを生成する。生成された状態変更指示メッセージは、通信部３５１を介して状態管理サーバー１０２に送信される。
【００７６】
クライアント装置１０１がスリープモードに移行してから、スリープモードから復帰するまでの一連の処理を図５、６、７に示す。
【００７７】
クライアント装置１０１は、一定時間ユーザーによって利用されないことが見込まれる場合に、省電力のために所定の条件によってスリープモードに移行する機能を有する。クライアント装置１０１がスリープモードに移行する条件は２つある。
【００７８】
一つは、夜間や営業時間外などといった一日のうちの決まった時間帯でユーザーがクライアント装置１０１を利用しないことがあらかじめ把握できている場合である。この場合は、クライアント装置１０１にスリープモードへの移行および復帰の時間帯をスケジュール設定し、クライアント装置１０１はスケジューされた時刻に従って状態を変える。
【００７９】
もう一つは、日中や営業時間内などといった一日のうちクライアント装置１０１がユーザーによっていつ利用されるか予測できない時間帯に、一定時間ユーザーによって利用されない場合である。この場合には、クライアント装置１０１を利用するユーザーがいなくても起動し続ける無駄を回避するために、クライアント装置１０１に対して、一定時間無使用の状態が継続した場合にはスリープモードに移行するよう無使用継続時間を設定する。クライアント装置１０１は、ユーザーからの仕様要求を監視し、設定された時間だけ継続してユーザーからの処理要求を受け付けなかった場合に、スリープモードに移行する。スリープモードに移行したクライアント装置１０１は操作部２０９を介してユーザーからの処理要求を受け付けた場合、スリープモードから復帰する。
【００８０】
図５はクライアント装置１０１がスリープモードに移行する基本的な処理を示したフローチャートである。本処理はクライアント装置１０１のモジュール３１０において実行される。なお、図５で示すフローチャートの各ステップの処理は、クライアント装置１０１のＣＰＵ２０１が、ＲＯＭ２０３や外部メモリ２１１に記録されたプログラムを読み出して実行することにより実現される。
【００８１】
Ｓ５０１において、制御部３１１はタイマー管理部３１２のタイマー情報テーブル（表１）の動作種別カラムの値が「無使用」であるレコードの条件カラムの値で示される時間を取得する。
【００８２】
Ｓ５０２において、制御部３１１はタイマー管理部３１２のタイマー情報テーブル（表１）の動作種別カラムの値が「スケジュール移行」のレコードの条件カラムの値を取得する。
【００８３】
Ｓ５０３において、制御部３１１は現在時刻と、Ｓ５０２で取得した条件カラムに格納されたスケジュール移行時刻とを比較する。現在時刻がスケジュール移行時刻よりも前だった場合には、Ｓ５０４に進む。現在時刻がスケジュール移行時刻と一致、または進んでいた場合にはＳ５０６に進む。
【００８４】
Ｓ５０４において、制御部３１１はＳ５０１で取得した一定時間の間、クライアント装置１０１が未使用状態にあるかどうかを確認する。クライアント装置が未使用状態にある時間が「無使用」のレコードの条件カラムに格納される一定時間を経過していない場合にはＳ５０５に進む。クライアント装置が未使用状態にある時間が一定時間を経過していた場合には、Ｓ５０６に進む。
【００８５】
Ｓ５０５において、制御部３１１はユーザーからの操作を待ち受け、再度Ｓ５０３の処理を実行する。
【００８６】
Ｓ５０６において、メッセージ生成部３２２は、クライアント装置１０１がスリープモードに移行する旨を記したクライアント状態メッセージ６００を生成し、通信部３２１を介して状態管理サーバー１０２に送信する。状態管理サーバー１０２のクライアント管理部３４２は、クライアント装置状態情報テーブルで管理する状態情報のうち該当する状態情報ファイルを、受信したスリープ移行時のクライアント状態メッセージ６００で更新する。
【００８７】
ここで、図６（ａ）は、クライアント装置１０１がスリープモードに移行する際に、クライアント装置１０１から状態管理サーバー１０２に送信されるクライアント状態メッセージの一例を示した図である。
【００８８】
スリープ移行時のクライアント状態メッセージ６００の各構成要素は状態情報ファイル４００と同様のため説明を省略し、スリープモードに移行する際の差分のみ説明する。状態部６０１は、クライアント装置１０１がスリープモードに移行する際の電源状態を示す情報である。
【００８９】
図６（ｂ）は、クライアント装置１０１がスリープモードから復帰する際に、クライアント装置１０１から状態管理サーバー１０２に送信されるクライアント状態メッセージの一例を示した図である。
【００９０】
スリープ復帰時のクライアント状態メッセージ６１０の各構成要素は状態情報ファイル４００と同様のため説明を省略し、スリープモードに移行する際の差分のみ説明する。状態部６１１は、クライアント装置１０１がスリープモードに復帰する際の電源状態を示す情報である。
【００９１】
図５の説明に戻る。Ｓ５０７において、制御部３１１はタイマー実行部３１３を介して、クライアント装置１０１をスリープモードに移行させる。
【００９２】
図７は、クライアント装置１０１がスリープモードから復帰する基本的な処理を示したフローチャートである。本処理はクライアント装置１０１のモジュール３１０において実行される。
【００９３】
Ｓ７０１において、制御部３１１は、タイマー管理部３１２のタイマー情報テーブル（表１）の動作種別カラムの値が「スケジュール復帰」のレコードの条件カラムの値を取得する。
【００９４】
Ｓ７０２において、制御部３１１は現在時刻とＳ５０２で取得した動作種別カラムの値が「スケジュール復帰」のレコードの条件カラムに格納されるスケジュール復帰時刻とを比較する。現在時刻がスケジュー復帰時刻よりも前だった場合には、Ｓ７０３に進む。現在時刻がスケジュール復帰時刻と一致、または進んでいた場合にはＳ７０４に進む。
【００９５】
Ｓ７０３において、制御部３１１はユーザーからの操作要求を受け付けたかどうかを判断する。ユーザーからの操作要求を受け付けた場合にはＳ７０４に進む。ユーザーからの操作要求を受け付けなかった場合には、再度Ｓ７０２の処理を実行する。
【００９６】
Ｓ７０４において、メッセージ生成部３２２はクライアント装置１０１がスリープモードに復帰する旨を記したクライアント状態メッセージ６１０を生成し、通信部３２１を介して状態管理サーバー１０２に送信する。状態管理サーバー１０２のクライアント管理部３４２は、クライアント装置状態情報テーブルで管理する状態情報のうち該当する状態情報ファイルを、受信したクライアント状態メッセージ６１０で更新する。
【００９７】
図８は、クライアント装置１０１およびアプリケーションサーバー１０３が状態管理サーバー１０２で管理される状態情報の更新通知を受信する一連の処理を示したシーケンス図である。
【００９８】
クライアント装置１０１は、自身のハードウェア設定やソフトウェア設定などの状態情報が変更された場合、状態管理サーバー１０２に変更された状態情報を送信する。状態管理サーバー１０２は、クライアント装置１０１から状態情報を受信するとクライアント装置１０１に関連するアプリケーションサーバー１０３にその情報を転送する。
【００９９】
また、アプリケーションサーバー１０３が自身と関連するクライアント装置１０１のハードウェア設定やソフトウェア設定を変更する場合、あるいは何等かの処理を実行させたい場合には、状態管理サーバー１０２に状態情報を送信する。状態管理サーバー１０２は、アプリケーションサーバー１０３から状態情報を受信するとアプリケーションサーバー１０３に関連するクライアント装置１０１にその情報を転送する。
【０１００】
従来の通信方式の場合は、クライアント装置１０１とアプリケーションサーバー１０３とが直接接続されることで、実現されていた。しかし、そのような場合アプリケーションサーバー１０３が関連する全てのクライアント装置１０１との通信を管理する必要があった。状態管理サーバー１０２を介した図８に示す出版購読方式の通信方式（ＭＱＴＴ）を採用することで、アプリケーションサーバー１０３がクライアント装置１０１を管理する負荷を追うことなく、双方向に情報の送受信を行うことが可能となる。ここで、ＭＱＴＴは、Ｍｅｓｓａｇｅ  Ｑｕｅｕｅ  Ｔｅｌｅｍｅｔｒｙ  Ｔｒａｎｓｐｏｒｔの略称である。つまり、クライアント装置１０１からの要求なしに、状態管理サーバー１０２からクライアント装置１０１への指示が可能となる。
【０１０１】
Ｓ８０１において、クライアント装置１０１は状態管理サーバー１０２に対して状態情報への接続要求を送信する。さらにＳ８０１で、アプリケーションサーバー１０３も状態管理サーバー１０２に対して状態情報への接続要求を送信する。状態管理サーバー１０２の接続管理部３４４は、接続要求を受信すると接続管理データベース３４５の接続情報テーブル（表５）に、接続要求を送信したクライアント名としてクライアント装置１０１およびアプリケーションサーバー１０３を登録する。
【０１０２】
Ｓ８０２において、クライアント装置１０１は状態管理サーバー１０２に対して状態情報への出版購読要求を送信する。さらにＳ８０２で、アプリケーションサーバー１０３も状態管理サーバー１０２に対して状態情報への出版購読要求を送信する。ここで、出版購読要求の一例を、表７の出版購読要求レコードに示す。
【０１０３】
【表７】
2019040413.tif 000009
【０１０４】
要求元クライアント名カラムは、出版購読要求を送信するクライアント装置１０１あるいはアプリケーションサーバー１０３の名称が格納される。
【０１０５】
出版状態情報カラムには、参照する状態情報名が格納される。
【０１０６】
購読状態情報カラムには、更新する状態情報名が格納される。
【０１０７】
接続管理部３４４は出版購読要求を受信すると、出版購読要求テーブル（表７）の要求元クライアント名カラムの値と、権限情報テーブル（表６）の接続クライアント名カラムの値とが一致するレコードを権限情報テーブルから取得する。次に、接続管理部３４４は、取得した権限情報レコードの状態情報名カラムの値および権限カラムの値を取得して、出版購読要求レコードの出版状態情報カラムの値と購読状態情報カラムの値とを比較する。それにより、接続管理部３４４は、要求元クライアントが出版購読要求に対応する権限を有しているか否かを確認する。権限を有している場合には、接続情報テーブル（表５）の接続クライアント名カラムと出版購読要求レコード（表７）の要求元クライアント名カラムとの値が一致する接続情報テーブルのレコードを特定する。特定されたレコードの出版状態情報名カラムおよび購読状態情報名カラムのそれぞれに、出版購読要求レコードの出版状態情報カラムの値および購読状態情報カラムの値を格納する。
【０１０８】
Ｓ８０３において、クライアント装置１０１は、状態情報が変化すると状態管理サーバー１０２に対しクライアント状態メッセージを送信する。
【０１０９】
Ｓ８０４において、状態管理サーバー１０２のクライアント管理部３４２は、通信部３４１を介してクライアント装置１０１からクライアント状態メッセージを受信する。クライアント管理部３４２は、クライアント装置状態情報テーブル（表４）の状態情報名がクライアント装置１０１と一致する表４のレコードの状態情報カラムに格納された状態情報ファイルを、受信したクライアント状態メッセージで更新する。
【０１１０】
Ｓ８０５において、状態管理サーバー１０２の接続管理部３４４は、Ｓ８０４で更新されたクライアント装置状態情報レコードの状態情報名カラムの値と接続情報テーブル（表５）の購読状態情報カラムとの値とが一致するレコードを検索する。そして、該当したレコードの接続クライアント名カラムの値に対応するアプリケーションサーバー１０３に対して、メッセージ生成部３４７が、通信部３４１を介して状態情報更新メッセージを送信する。以上の一連の処理によってアプリケーションサーバー１０３は状態管理サーバー１０２を介してクライアント装置１０１の状態更新をリアルタイムに監視することが可能となる。
【０１１１】
なお、図８に示した一連の処理はクライアント装置１０１の状態の変更を、状態管理サーバー１０２を介してリアルタイムにアプリケーションサーバー１０３に対して通知することを説明しているが、その逆も同様である。つまり、アプリケーションサーバー１０３の指示によって、状態管理サーバー１０２の状態情報が更新された場合も同様である。クライアント装置１０１に対して、ネットワーク１００を介して、その更新内容に基づく指示がリアルタイムに通知される。
【０１１２】
図８に示した一連の処理によって、状態管理サーバー１０２を介することでアプリケーションサーバー１０３はクライアント装置１０１の状態をリアルタイムに参照および更新することが可能となる。しかしながら、図５から図７に示すようにクライアント装置１０１は、適宜スリープモードに移行することがあり得る。クライアント装置１０１がスリープモードに移行すると、クライアント装置１０１と状態管理サーバー１０２との間のセッションが解除される。具体的には接続情報テーブル（表５）から該当するクライアント装置１０１のレコードが削除される。この状態の場合、アプリケーションサーバー１０３が状態管理サーバー１０２に対してクライアント状態メッセージを送信したとしても、クライアント装置１０１は、ネットワーク１００から遮断されているため、状態の変更に関する通知を受信できない。つまり、クライアント装置１０１がスリープモードから復帰して、状態管理サーバー１０２に接続要求を送信することでセッションが確立されるまでの間は、クライアント装置１０１と状態管理サーバー１０２との間のセッションが解除された状態となる。
【０１１３】
そのため、図９から図１１を用いて、クライアント装置１０１がスリープモードに移行していた場合でもアプリケーションサーバー１０３からのクライアント状態メッセージを適切に受信するための方法を示す。
【０１１４】
図９は、クライアント装置１０１が、Ｓ８０２において状態管理サーバー１０２に接続した後にスリープモードに移行する際の一連の処理を示したフローチャートである。
【０１１５】
Ｓ９０１からＳ９０５までは図５に示したＳ５０１からＳ５０５の処理と同様のため説明を省略する。
【０１１６】
Ｓ９０６において、タイマー管理部３２４は、メッセージ確認間隔テーブル（表２）からメッセージ確認間隔レコードを取得する。そして、タイマー管理部３２４はタイマー管理部３１２を介して、タイマー情報テーブルにスリープモード時のメッセージ確認タイマー情報を登録する。Ｓ９０６においてメッセージ確認タイマー情報を登録したタイマー情報テーブルの一例を、表８のタイマー情報テーブルで示す。
【０１１７】
【表８】
2019040413.tif 000010
【０１１８】
表１との違いとして表８では、ＩＤが「４」、動作種別が「スリープモード」、条件が「１５分」のレコードが追加された。そのレコードにおいて、動作種別カラムに「スリープモード」、条件カラムにＳ９０６で取得したメッセージ確認間隔レコードの実行間隔カラムの値が格納される。本実施例では、メッセージ確認の実行間隔を「１５分」として説明するが、メッセージ確認の実行間隔はこの例に限らない。
【０１１９】
Ｓ９０７からＳ９０８までは図５に示したＳ５０６からＳ５０７の処理と同様のため説明を省略する。
【０１２０】
図１０は、クライアント装置１０１が、スリープモードに移行した後、状態管理サーバー１０２に対してアプリケーションサーバー１０３による指示の有無を確認するためにスリープモードから復帰する一連の流れを示したフローチャートである。
【０１２１】
Ｓ１００１は図７に示したＳ７０１の処理と同様のため説明を省略する。
【０１２２】
Ｓ１００２において、タイマー管理部３１２は、タイマー情報テーブル（表８）の動作種別カラムの値が「スリープモード」のレコードの条件カラムの値をメッセージ確認タイマー値として取得する。
【０１２３】
Ｓ１００３からＳ１００４までは図７に示したＳ７０２からＳ７０３の処理と同様のため説明を省略する。
【０１２４】
Ｓ１００５において、制御部３１１は現在時刻がスリープモードに移行してからＳ１００２で取得したメッセージ確認タイマー以上に経過しているかを確認する。経過している場合にはＳ１００７に、経過していなかった場合には再度Ｓ１００６を実行する。なお、Ｓ１００５の処理は、次回以降は前回Ｓ１００５の処理を実行してからメッセージ確認タイマーの値以上に現在時刻が経過しているか否かを確認する。
【０１２５】
Ｓ１００６は図７に示したＳ７０４の処理と同様のため説明を省略する。Ｓ１００６により、クライアント装置１０１は、状態管理サーバー１０２とのセッションを確立し、Ｓ１００７とは異なる通信方式により状態管理サーバー１０２からの指示を受信可能となる。
【０１２６】
Ｓ１００７において、制御部３１１は状態管理サーバー１０２にアプリケーションサーバー１０３からの指示が登録されているかを確認するためにスリープモードから一時復帰する。なお、Ｓ１００７の処理の詳細は図１１を用いて説明する。
【０１２７】
図１１は、クライアント装置１０１がＳ１００７において、一時的にスリープモードから復帰して状態管理サーバー１０２にアプリケーションサーバー１０３からの指示が登録されているかを確認する一連の処理を示したフローチャートである。
【０１２８】
Ｓ１１０１において、モジュール３２０は通信部３２１を介してモジュール３４０にアプリケーションサーバー１０３からの状態変更指示の有無を問い合わせる。モジュール３４０は、モジュール３２０からの問い合わせを受信するとクライアント装置状態情報テーブル（表４）から、問い合わせを受信したクライアント装置１０１とクライアント装置名カラムの値とが一致するクライアント装置状態情報レコードを取得する。次にモジュール３４０は、状態情報カラムに格納される状態情報ファイルを取得する。図４（ｂ）に示す状態変更指示メッセージ４１０は、クライアント装置１０１に送信されるメッセージの例である。指示部４１１には、キャリブレーションの実行指示が記載されている。その他の主な構成要素は状態情報ファイル４００と同様のため説明を省略する。アプリケーションサーバー１０３からの状態変更指示がある場合には指示部４１１のように指示の内容が挿入される。そして、クライアント管理部３４２はアプリケーションサーバー１０３からクライアント装置１０１に対する実行指示があると判断して、クライアント装置１０１に状態変更指示メッセージ４１０として送信する。
【０１２９】
クライアント管理部３４２は指示部４１１に値が格納されていなかった場合はアプリケーションサーバー１０３からの状態変更指示なしと判断して、Ｓ１１０５に進む。
【０１３０】
Ｓ１１０２において、クライアント装置１０１のメッセージ解析部３２３は通信部３２１を介して状態変更指示メッセージ４１０を受信する。Ｓ１１０２では、クライアント装置１０１が状態管理サーバー１０２に対して要求することで、指示を受信することが可能となる通信方式（ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ））が利用される。ここでは、一時的にスリープ状態から通常状態に移行しているため、クライアント装置と状態管理サーバーとの間でセッションを確立しないものとする。
【０１３１】
Ｓ１１０３において、メッセージ解析部３２３はＳ１１０２において受信した状態変更指示メッセージ４１０の指示部４１１を参照し、モジュール３３０の制御部３３１に送信する。そして、モジュール３３０は指示部４１１の内容に従ってクライアント装置１０１の状態および設定を変更しクライアント管理部３３２を更新する。
【０１３２】
Ｓ１１０４において、メッセージ生成部３２２はＳ１１０３で変更したクライアント装置１０１の状態および設定値で状態部４０３を更新する。さらに、メッセージ生成部３２２は、クライアント装置１０１がスリープモードに移行する旨を記したクライアント状態メッセージ４２０を生成し、通信部３２１を介して状態管理サーバー１０２に送信する。
【０１３３】
図４（ｃ）に示すクライアント状態メッセージ４２０は、クライアント装置１０１から状態管理サーバー１０２に送信されるファイルである。４２１には、特に指示が記載されていない。４２２には、キャリブレーションが実行されたことが記載されている。４２３には、スリープモードに入ったことが記載されている。
【０１３４】
状態管理サーバー１０２のクライアント管理部３４２は、クライアント装置状態情報テーブル（表４）で管理する状態情報のうち該当する状態情報ファイルを、受信したスリープ移行時のクライアント状態メッセージ６００（図６（ａ））で更新する。
【０１３５】
Ｓ１１０５において、タイマー管理部３２４はＳ１００２で取得したメッセージ確認タイマー値を、タイマー管理部３１２を介してタイマー情報テーブル（表８）にスリープモード時のメッセージ確認タイマー情報を登録する。
【０１３６】
Ｓ１１０６において、制御部３１１はクライアント装置１０１をスリープモードに再び移行する。ここでは、図５で示した処理とは異なり、一定時間の間、ユーザー操作を受け付けることを待機することなく、クライアント装置１０１はスリープモードへ移行する。
【０１３７】
図１０から図１１に示した一連の処理によって、クライアント装置１０１は、スリープモードに移行した後に、一時的にスリープモードから復帰するようにした。一時的にスリープモードから復帰した際に状態管理サーバー１０２からの指示に基づく処理を完了した後、クライアント装置はスリープモードに移行する。これにより、状態管理サーバー１０２に対してアプリケーションサーバー１０３による指示が登録されたとしても、なるべく早くアプリケーションサーバー１０３の指示をクライアント装置１０１に反映することが可能となる。なお図１０から図１１に示す一連の処理は、クライアント装置１０１がＳ１００６において、スリープモードから復帰するまで繰り返される。
【０１３８】
（実施例２）
アプリケーションサーバー１０３が状態管理サーバー１０２に登録した状態変更指示は、登録され次第該当するクライアント装置１０１に反映されるのが好ましい。実施例１においてはクライアント装置１０１がスリープモードに移行して、状態管理サーバー１０２との接続が解除される状況でもできるだけ早く反映させる方法を示した。しかしながら、クライアント装置１０１がスリープモードに移行する条件によっては必ずしも状態管理サーバー１０２に登録した状態変更指示の反映を即時行わなければならないわけではない。例えば、クライアント装置１０１がスケジュール設定によってスリープモードへ移行する際、その設定によってはスリープモード中にクライアント装置１０１を利用するユーザーが見込まれない場合がある。そのような場合は、スリープモードから復帰して再びクライアント装置１０１が利用可能になるまでのどこかのタイミングで状態変更指示を反映すればよい。また例えば、クライアント装置１０１が一定時間未使用状態を理由にスリープモードへ移行する際、いつユーザーがクライアント装置１０１を操作するか分からない。そのような場合は、クライアント装置１０１のユーザーに影響が出てしまうため、できるだけ早く状態変更指示を反映する必要がある。
【０１３９】
本実施例においては、クライアント装置１０１がスリープモードに移行する条件によって、状態管理サーバー１０２に登録された状態変更指示を確認するタイミングを適切に制御する方法を示す。
【０１４０】
図１２は、クライアント装置１０１が、状態管理サーバー１０２にＳ８０１に示す接続要求を送信した後にスリープモードに移行する際、スリープモードに移行する条件によって、メッセージ確認タイマーの一連の処理を示したフローチャートである。
【０１４１】
Ｓ１２０１からＳ１２０２までは図５に示したＳ５０１からＳ５０２までの処理と同様のため説明を省略する。
【０１４２】
Ｓ１２０３において、制御部３１１は現在時刻とＳ１２０２で取得した動作種別カラムの値が「スケジュール移行」のレコードの条件カラムに格納されたスケジュール移行時刻とを比較する。現在時刻がスケジュール移行時間よりも前だった場合には、Ｓ１２０４に進む。現在時刻がスケジュール移行時刻と一致、もしくは進んでいた場合にはＳ１２０６に進む。
【０１４３】
Ｓ１２０４において、制御部３１１はＳ１２０１で取得した動作種別カラムの値が「無使用」のレコードの条件カラムに格納された時間の間に、クライアント装置１０１が未使用状態にあるかどうかを確認する。クライアント装置が未使用状態にある時間が「無使用」のレコードの条件カラムに格納された時間未満である場合にはＳ１２０５に進む。クライアント装置が未使用状態にある時間が「無使用」のレコードの条件カラムに格納された時間以上継続していた場合には、Ｓ１２０７に進む。
【０１４４】
Ｓ１２０５において、制御部３１１はユーザーからの操作を待ち受け、再度Ｓ１２０３の処理を実行する。
【０１４５】
Ｓ１２０６および、Ｓ１２０７において、タイマー管理部３２４は、条件別メッセージ確認間隔テーブルから条件別メッセージ確認間隔レコードを取得する。本実施例において、タイマー管理部３２４が管理する条件別メッセージ確認間隔の一例を、表９の条件別メッセージ確認間隔テーブルに示す。
【０１４６】
【表９】
2019040413.tif 000011
【０１４７】
ＩＤカラムはモジュール３２０において、一意にメッセージ確認間隔を識別するための識別子を格納するカラムである。
【０１４８】
スリープ種別カラムは、クライアント装置１０１がスリープモードに移行する際の条件を識別するための情報を格納するカラムである。クライアント装置１０１が一定時間ユーザー操作を受け付けなかったことを理由にスリープモードに移行する場合は「無使用」が該当する。一方、タイマー実行部３１３によってあらかじめ定められたスケジュールに従ってスリープモードに移行した場合には「スケジュール」が該当する。クライアント装置１０１は、実行間隔カラムに格納される所定時間おきに、スリープ状態から復帰して状態管理サーバー１０２と通信する。ここで、「スケジュール」の場合の実行間隔の時間は、「無使用」の実行間隔の時間よりも長い。「スケジュール」の場合、スリープモードからの復帰予定時刻までの間、ユーザーによりクライアント装置が使用される可能性が低いため、更新確認を行う頻度を少なくしている。なお、「スケジュール」の場合、実行間隔の時間ではなく、実行時刻として所定時刻が管理されていても良い。
【０１４９】
実行間隔カラムは、モジュール３２０が状態管理サーバー１０２に状態変更指示メッセージの更新確認を行う際の実行間隔の値を格納するカラムである。
【０１５０】
Ｓ１２０６において、タイマー管理部３２４はスケジュールに従ってクライアント装置１０１がスリープモードに移行すると判断する。タイマー管理部３２４は、条件別メッセージ確認間隔テーブルのスリープ種別カラムの値が「スケジュール」と一致するレコードを取得する。そして、タイマー管理部３２４は取得したレコードの実行間隔カラムの値をタイマー情報テーブルにスリープモード時のメッセージ確認タイマー情報として登録する。
【０１５１】
Ｓ１２０７において、タイマー管理部３２４は未使用時刻の経過に従ってクライアント装置１０１がスリープモードに移行すると判断する。タイマー管理部３２４は、条件別メッセージ確認間隔テーブルのスリープ種別カラムの値が「無使用」と一致するレコードを取得する。そして、タイマー管理部３２４は取得したレコードの実行間隔カラムの値をタイマー情報テーブルにスリープモード時のメッセージ確認タイマー情報として登録する。
【０１５２】
Ｓ１２０８からＳ１２０９までは図９に示したＳ９０７からＳ９０８の処理と同様のため説明を省略する。
【０１５３】
図１２に示した一連の処理によって、クライアント装置１０１がスリープモードに移行する条件によって、状態管理サーバー１０２に登録された状態変更指示を確認するタイミングを適切に制御することができる。
【０１５４】
（実施例３）
アプリケーションサーバー１０３が状態管理サーバー１０２に登録する状態変更指示の内容によっては、反映中はクライアント装置１０１が使用不可能になる場合がある。例えば指示の反映前後によって、ユーザー操作の結果が変わるために、反映中は意図的にクライアント装置１０１がユーザー操作実行を受け付けないようにする場合がある。また、クライアント装置１０１が指示反映の後処理としてクライアント装置１０１自身の再起動を行う場合なども考えられる。
【０１５５】
クライアント装置１０１が実施例１、２に示す方法で状態管理サーバー１０２に状態変更指示の有無を確認する際、ユーザー操作によってスリープモードから復帰した場合には復帰直後にユーザー操作の実行を行うことが想定される。復帰直後にクライアント装置１０１が上述したようなクライアント装置１０１が使用不可となる状態変更指示を反映させてしまうと、クライアント装置はユーザー操作を受け付けることができず、ユーザーはその間待機しなければならない。
【０１５６】
本実施例においては、ユーザー操作の利便性を維持しつつ、クライアント装置１０１による状態変更指示の反映を制御する方法を示す。
【０１５７】
図１３は、クライアント装置１０１が、Ｓ１００６においてスリープモードから復帰する際、その復帰する理由によって状態変更指示の反映タイミングを制御する一連の処理を示したフローチャートである。
【０１５８】
Ｓ１３０１において、モジュール３２０は通信部３２１を介してモジュール３４０にアプリケーションサーバー１０３からの状態変更指示の有無を問い合わせる。モジュール３４０は、モジュール３２０からの問い合わせを受信するとクライアント装置状態情報テーブルから、問い合わせを受信したクライアント装置１０１とクライアント装置名カラムの値とが一致するクライアント装置状態情報レコードを取得する。次にモジュール３４０は、状態情報カラムに格納される状態情報ファイルを取得する。アプリケーションサーバー１０３からの状態変更指示がある場合には指示部４１１のように指示の内容が挿入される。そして、クライアント管理部３４２はアプリケーションサーバー１０３からクライアント装置１０１に対する実行指示があると判断して、クライアント装置１０１に状態変更指示メッセージ４１０として送信する。クライアント管理部３４２は指示部４１１に値が格納されていなかった場合はアプリケーションサーバー１０３からの状態変更指示なしと判断して、Ｓ１３０５に進む。
【０１５９】
Ｓ１３０２において、クライアント装置１０１のメッセージ解析部３２３は通信部３２１を介して状態変更指示メッセージ４１０を受信する。
【０１６０】
Ｓ１３０３において、制御部３１１はクライアント装置１０１がスリープモードから復帰した理由を確認する。具体的には、制御部３１１はＳ１００３、Ｓ１１０４の処理結果からスリープモードから復帰した理由を確認する。クライアント装置１０１がＳ１００４における処理でユーザーから操作要求を受け付けたと判断された場合にはＳ１３０３に進む。また、クライアント装置１０１がＳ１００３における処理でユーザーから操作要求を受け付けたと判断された場合にはＳ１３０５に進む。
【０１６１】
Ｓ１３０４において、制御部３１１はユーザーからの操作を待ち受け、ユーザーからの操作が終了したタイミングでＳ１３０５に進む。ユーザー操作を受け付けたことによってスリープモードから復帰した場合は、Ｓ１３０４でのユーザー操作が終了した後に、Ｓ１３０５で、受信した指示に基づく処理が実行されることとなる。
【０１６２】
Ｓ１３０５において、メッセージ解析部３２３はＳ１３０２において受信した状態変更指示メッセージ４１０の指示部４１１を参照し、モジュール３３０の制御部３３１に送信する。そして、モジュール３３０は指示部４１１の内容に従ってクライアント装置１０１の状態および設定を変更しクライアント管理部３３２を更新する。
【０１６３】
Ｓ１３０６において、メッセージ生成部３２２はＳ１３０５で変更したクライアント装置１０１の状態および設定値で状態部４０３を更新する。さらに、メッセージ生成部３２２は、クライアント装置１０１がスリープモードに移行する旨を記したクライアント状態メッセージ４２０を生成し、通信部３２１を介して状態管理サーバー１０２に送信する。状態管理サーバー１０２のクライアント管理部３４２は、クライアント装置状態情報テーブルで管理する状態情報のうち該当する状態情報ファイルを、受信したスリープ移行時のクライアント状態メッセージ６００で更新する。
【０１６４】
図１３のフローチャートに示した一連の処理により、クライアント装置１０１がスリープモードからの直後に状態変更指示を処理するタイミングを、ユーザー操作の有無で制御することが可能となる。これにより、ユーザーがクライアント装置１０１をスリープモードから復帰させた場合に、状態変更指示が実行されてユーザーが本来行う操作が実行不可となる状況を抑制することができる。
【０１６５】
一方で、状態変更指示の内容によっては、ユーザー操作の実行を妨げることなく並行して実行可能な場合もある。その場合にはクライアント装置１０１として、ユーザー操作の実行を必ずしも優先する必要はない。
【０１６６】
図１４は、クライアント装置１０１が図１３に示した一連の処理において、状態変更指示の内容とスリープモードから復帰する理由の両方を加味して状態変更指示の反映タイミングを制御する一連の処理を示したフローチャートである。
【０１６７】
Ｓ１４０１からＳ１４０３までは図１３に示したＳ１３０１からＳ１３０３までの処理と同様のため説明を省略する。
【０１６８】
Ｓ１４０４において、メッセージ解析部３３３は通信部３２１を介してメッセージ解析部３２３からＳ１４０２で取得した状態変更指示メッセージを解析する。そして、メッセージ解析部３３３が、状態変更指示メッセージの内容をクライアント装置１０１にメッセージ実行部３３４が実行するとクライアント装置１０１が一時的にユーザー操作不可能な状態になってしまうと判断した場合には、Ｓ１４０５に進む。そうでない場合には、Ｓ１４０８に進む。
【０１６９】
図１５は、Ｓ１４０２で取得した状態変更指示メッセージの一例を示した図である。
【０１７０】
図１５（ａ）で示す状態変更指示メッセージ１５００はＳ１４０４においてメッセージ解析部３３３が、メッセージ実行部３３４が実行するとクライアント装置１０１がユーザー操作不可能な状態になると判断するメッセージの一例である。以降、状態変更指示メッセージ１５００をメッセージ１５００と称する。
【０１７１】
メッセージ１５００には、クライアント装置補正指示１５０１（以降、指示１５０１と称する。）が記載されている。指示１５０１には指示実行時の優先度情報１５０２とユーザー影響情報１５０３含まれている。
【０１７２】
優先度情報１５０２は、指示１５０１の実行優先度を示す項目である。例えば、優先度情報１５０２の値が「ｎｅｅｄ」の場合、その指示はユーザー操作に優先して実行されるべき指示であることを示す。
【０１７３】
ユーザー影響情報１５０３は、指示１５０１実行時のユーザーへの影響度を示す項目である。例えば、ユーザー影響情報１５０３の値が「ｎｏｔａｖａｉｌａｂｌｅ」の場合、メッセージ実行部３３４が指示１５０１を実行すると、その間クライアント装置１０１が操作不可になることを示す。
【０１７４】
図１５（ｂ）で示す状態変更指示メッセージ１５１０はＳ１４０４においてメッセージ解析部３３３が、メッセージ実行部３３４が実行してもクライアント装置１０１がユーザー操作可能な状態になると判断するメッセージの一例である。以降、状態変更指示メッセージ１５１０をメッセージ１５１０と称する。
【０１７５】
メッセージ１５１０には、クライアント装置時刻修正指示１５１１（以降、指示１５１１と称する。）が記載されている。指示１５１１には指示実行時の優先度情報１５１２とユーザー影響情報１５１３含まれている。
【０１７６】
優先度情報１５１２は、指示１５１１の実行優先度を示す項目である。例えば、優先度情報１５０２の値が「ｎｏｒｍａｌ」の場合、その指示は必ずしも優先して実行されなくてもよい指示であることを示す。
【０１７７】
ユーザー影響情報１５１３は、指示１５１１実行時のユーザーへの影響度を示す項目である。例えば、ユーザー影響情報１５１３の値が「ａｖａｉｌａｂｌｅ」の場合、メッセージ実行部３３４が指示１５１１を実行すると、その間もクライアント装置１０１が操作可能であることを示す。
【０１７８】
Ｓ１４０５において、メッセージ解析部３３３はさらに状態変更指示メッセージの内容を解析する。そして、メッセージ解析部３３３が、状態変更指示メッセージがユーザー操作よりも優先されるべきと判断した場合には、Ｓ１４０６に進む。具体的には、優先度方法１５０２の値が「ｎｅｅｄ」だった場合が、これに該当する。
【０１７９】
また、メッセージ解析部３３３が、状態変更指示メッセージがユーザー操作よりも優先されなかった判断した場合には、Ｓ１４０７に進む。具体的には、優先度方法１５０２の値が「ｎｏｒｍａｌ」だった場合が、これに該当する。
【０１８０】
Ｓ１４０６において、制御部３３１はＣＲＴ２１０を介してユーザーに対して指示実行確認ダイアログ１６００（以降、ダイアログ１６００と称する。）を表示して指示の実行を優先するか、ユーザー操作の実行を優先するかをユーザーに問い合わせる。
【０１８１】
図１６は、Ｓ１４０６においてＣＲＴ２１０に表示されるダイアログ１６００の一例を示した図である。
【０１８２】
ダイアログ１６００は、指示実行確認メッセージ表示ラベル１６０１、指示実行ボタン１６０２、操作実行ボタン１６０３から構成される。
【０１８３】
指示実行確認メッセージ表示ラベル１６０１には、ユーザーに対してクライアント装置１０１が実行すべき状態変更指示メッセージを受信している旨のメッセージを表示するラベルである。
【０１８４】
指示実行ボタン１６０２が押下されると、クライアント装置１０１は、ユーザーが自身の操作よりも指示の反映を優先することを許可したと判断して、Ｓ１４０８に進む。
【０１８５】
操作実行ボタン１６０３が押下されると、クライアント装置１０１は、指示の反映よりもユーザー操作が優先されたものと判断して、Ｓ１４０７に進み、ユーザー操作が完了するまで待機する。
【０１８６】
Ｓ１４０８において、メッセージ解析部３２３はＳ１４０２において受信した状態変更指示メッセージ１５００の指示部１５０１を参照し、モジュール３３０の制御部３３１に送信する。そして、モジュール３３０は指示部４１１の内容に従ってクライアント装置１０１の状態および設定を変更しクライアント管理部３３２を更新する。
【０１８７】
Ｓ１４０９において、メッセージ生成部３２２はＳ４０８で変更したクライアント装置１０１の状態および設定値で状態部４０３を更新する。さらに、メッセージ生成部３２２は、クライアント装置１０１がスリープモードに移行する旨を記したクライアント状態メッセージ４２０を生成し、通信部３２１を介して状態管理サーバー１０２に送信する。状態管理サーバー１０２のクライアント管理部３４２は、クライアント装置状態情報テーブルで管理する状態情報のうち該当する状態情報ファイルを、受信したスリープ移行時クライアント状態メッセージ６００で更新する。
【０１８８】
図１４から図１６に示した一連の処理により、状態変更指示の内容によって、ユーザー操作と状態変更指示の実行と優先されるべき処理を適切に実行することが可能となる。
【０１８９】
（実施例４）
実施例１から実施例３まででは、クライアント装置１０１がスリープモードに移行してネットワーク接続が切断される状況においても適宜スリープモードから復帰することで状態変更指示を適切に受信および反映する方法について示した。
【０１９０】
図８に示した一連の処理によって、クライアント装置１０１とアプリケーションサーバー１０３は状態管理サーバー１０２を介して、相互かつリアルタイムにデータのやり取りが可能となる。そのため、クライアント装置１０１の使われ方が様々であってもアプリケーションサーバー１０３は柔軟に必要なタイミングでクライアント装置１０１に対して状態変更指示を送信することができる。
【０１９１】
一方、クライアント装置１０１の使われ方に規則性がある場合、それに応じたアプリケーションサーバー１０３の状態変更指示の送信タイミングもまた規則性を帯びる場合がある。そのような場合には、クライアント装置１０１がスリープモードに移行した後、定期的に状態管理サーバー１０２に状態変更指示の有無を確認したとしても無駄な処理となる割合が多い。
【０１９２】
本実施例においては、クライアント装置１０１がスリープモードに移行後、状態管理サーバー１０２に状態変更指示の有無を確認する間隔をアプリケーションサーバー１０３からの状態変更指示の受信履歴に基づき決定して、状態変更指示を受信する方法を示す。
【０１９３】
図１７は、クライアント装置１０１がスリープモードに移行する際のメッセージ確認タイマーを決定する際に、過去に受信した状態変更指示メッセージの履歴に基づきスリープモードから復帰すべき時刻を予測して決定する処理例を示したフローチャートである。
【０１９４】
Ｓ１７０１からＳ１７０２までは図９に示したＳ９０１からＳ９０２までの処理と同様のため説明を省略する。
【０１９５】
Ｓ１７０３において、制御部３１１は現在時刻とＳ１７０２で取得した動作種別カラムの値が「スケジュール移行」のレコードの条件カラムに格納されたスケジュール移行時刻とを比較する。現在時刻がスケジュール移行時刻よりも前だった場合には、Ｓ１７０４に進む。現在時刻がスケジュール移行時刻と一致、もしくは進んでいた場合にはＳ１７０６に進む。
【０１９６】
Ｓ１７０４において、制御部３１１はＳ１７０１で取得した動作種別カラムの値が「無使用」のレコードの条件カラムに格納された時間、クライアント装置１０１が未使用状態にあるかどうかを確認する。クライアント装置が未使用状態にある時間が「無使用」のレコードの条件カラムに格納された時間未満である場合にはＳ１７０５に進む。クライアント装置が未使用状態にある時間が「無使用」のレコードの条件カラムに格納された時間以上継続していた場合には、Ｓ１７０８に進む。
【０１９７】
Ｓ１７０５において、制御部３１１はユーザーからの操作を待ち受け、再度Ｓ１７０３の処理を実行する。
【０１９８】
Ｓ１７０６およびＳ１７０８において、制御部３１１は、履歴管理部３２５が管理する実行履歴テーブルに登録されている状態変更指示メッセージ実行履歴レコードの内容を確認する。制御部３１１は、アプリケーション名カラムが同一の状態変更指示メッセージ実行履歴レコードの日時情報カラムの値を取得し、過去アプリケーション名カラムの値に対応するアプリケーションサーバー１０３からの状態変更指示を処理した時間帯を集計する。表３に登録されているレコードを例にすると、キャリブレーションサービスを提供するアプリケーションサーバー１０３からの指示の実行履歴が毎日２１時台に集中している。この場合、制御部３１１はスリープモードから復帰してアプリケーションサーバー１０３からの実行指示を受信する所定時刻を毎日２１時と予測する。そして、Ｓ１７１０において、タイマー管理部３２４はタイマー情報テーブルに動作種別カラムに「スリープモード」、条件カラムに「毎日、２１時」の値を格納したタイマー情報レコードを登録する。制御部３１１が実行指示を予測するだけの情報が実行履歴テーブルに存在せず、予測できない場合にはＳ１７０７に進む。
【０１９９】
Ｓ１７０７において、タイマー管理部３２４はスケジュールに従ってクライアント装置１０１がスリープモードに移行すると判断する。タイマー管理部３２４は、条件別メッセージ確認間隔テーブルのスリープ種別カラムの値が「スケジュール」と一致するレコードを取得する。そして、タイマー管理部３２４は取得したレコードの実行間隔カラムの値をタイマー情報テーブルにスリープモード時のメッセージ確認タイマー情報として登録する。
【０２００】
Ｓ１７０９において、タイマー管理部３２４は未使用時刻の経過に従ってクライアント装置１０１がスリープモードに移行すると判断する。タイマー管理部３２４は、条件別メッセージ確認間隔テーブルのスリープ種別カラムの値が「無使用」と一致するレコードを取得する。そして、タイマー管理部３２４は取得したレコードの実行間隔カラムの値をタイマー情報テーブルにスリープモード時のメッセージ確認タイマー情報として登録する。Ｓ１７１１からＳ１７１２までは図９に示したＳ９０７からＳ９０８の処理と同様のため説明を省略する。
【０２０１】
図１７に示した一連の処理によって、クライアント装置１０１がスリープモードに移行する際、過去の指示実行履歴から予測できるタイミングで状態変更指示を確認するためのタイマーを制御することができる。
【０２０２】
（他の実施例）
本発明は、上述した実施形態を適宜組み合わせることにより構成された装置あるいはシステムやその方法も含まれるものとする。
【０２０３】
ここで、本発明は、上述した実施形態の機能を実現する１つ以上のソフトウェア（プログラム）を実行する主体となる装置あるいはシステムである。また、その装置あるいはシステムで実行される上述した実施形態を実現するための方法も本発明の１つである。また、そのプログラムは、ネットワークまたは各種記憶媒体を介してシステムあるいは装置に供給され、そのシステムあるいは装置の１つ以上のコンピューター（ＣＰＵやＭＰＵ等）によりそのプログラムが読み出され、実行される。つまり、本発明の１つとして、さらにそのプログラム自体、あるいは当該プログラムを格納したコンピューターにより読み取り可能な各種記憶媒体も含むものとする。また、上述した実施形態の機能を実現する回路（例えば、ＡＳＩＣ）によっても、本発明は実現可能である。
【符号の説明】
【０２０４】
１０１  クライアント装置
２０１  ＣＰＵ
３１１  制御部
３２１  通信部
【図１】
2019040413.tif 000012
【図２】
2019040413.tif 000013
【図３】
2019040413.tif 000014
【図４】
2019040413.tif 000015
【図５】
2019040413.tif 000016
【図６】
2019040413.tif 000017
【図７】
2019040413.tif 000018
【図８】
2019040413.tif 000019
【図９】
2019040413.tif 000020
【図１０】
2019040413.tif 000021
【図１１】
2019040413.tif 000022
【図１２】
2019040413.tif 000023
【図１３】
2019040413.tif 000024
【図１４】
2019040413.tif 000025
【図１５】
2019040413.tif 000026
【図１６】
2019040413.tif 000027
【図１７】
2019040413.tif 000028