機器、省電力制御方法、省電力制御プログラム、及び記録媒体
【課題】プログラムの追加による省電力効果への影響を抑制すること。
【解決手段】プログラムをインストール可能な機器であって、省電力状態への移行開始時期より前に、前記プログラムに対する省電力状態への移行通知を行う事前通知手段と、前記移行開始時期に、前記プログラムに関して省電力状態への移行の可否を問い合わせる確認手段とを有し前記確認手段によって問い合わせが行われた前記プログラムに関して省電力状態への移行が可能である場合に、省電力状態へ移行する。
【解決手段】プログラムをインストール可能な機器であって、省電力状態への移行開始時期より前に、前記プログラムに対する省電力状態への移行通知を行う事前通知手段と、前記移行開始時期に、前記プログラムに関して省電力状態への移行の可否を問い合わせる確認手段とを有し前記確認手段によって問い合わせが行われた前記プログラムに関して省電力状態への移行が可能である場合に、省電力状態へ移行する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、機器、省電力制御方法、省電力制御プログラム、及び記録媒体に関する。
【背景技術】
【０００２】
従来、プリンタ、ファクシミリ、コピー機、又は複合機等の画像形成装置などのように、省電力化を図るため、例えば、無操作状態が所定時間継続すると省電力状態（省電力モード又は省エネモード等とも呼ばれる。）に移行する機器がある。例えば、斯かる画像形成装置の中には、省電力状態の移行時において、画像形成装置内において動作する各部（例えば、プログラム群等）に関して、省電力状態への移行の可否の確認が行われるものもある。すなわち、各部に関して省電力状態への移行が可能であることが確認された場合に限って省電力状態への移行が行われる。突然の省電力状態への移行による各部の動作不正や、各部の処理対象のデータの破壊等を防止するためである。
【０００３】
他方において、画像形成装置の中には、アプリケーションプログラムを実装するためのＡＰＩ（Application Program Interface）が公開され、その出荷後に、ユーザ所望のアプリケーションプログラムをインストールすることにより、機能拡張が可能とされているものもある。このような画像形成装置においては、ユーザの利用形態に応じて、多数のアプリケーションプログラムが動作する可能性がある。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、このような画像形成装置を一例とする機器において動作するアプリケーションプログラムが増加すると、省電力状態への移行時における確認対象が増加する。すなわち、インストールされた各アプリケーションプログラムに関しても、省電力状態への移行の可否の確認が行われる必要がある。斯かる確認対象の増加は、省電力状態への移行の可否の確認処理の長期化を招く。その結果、省電力状態への移行が遅れ、結果的に省電力効果が低下してしまう可能性がある。
【０００５】
本発明は、上記の点に鑑みてなされたものであって、プログラムの追加による省電力効果への影響を抑制することができる機器、省電力制御方法、省電力制御プログラム、及び記録媒体の提供を目的とする。
【課題を解決するための手段】
【０００６】
そこで上記課題を解決するため、本発明は、プログラムをインストール可能な機器であって、省電力状態への移行開始時期より前に、前記プログラムに対する省電力状態への移行通知を行う事前通知手段と、前記移行開始時期に、前記プログラムに関して省電力状態への移行の可否を問い合わせる確認手段とを有し前記確認手段によって問い合わせが行われた前記プログラムに関して省電力状態への移行が可能である場合に、省電力状態へ移行する。
【０００７】
このような機器では、プログラムの追加による省電力効果への影響を抑制することができる。
【発明の効果】
【０００８】
本発明によれば、プログラムの追加による省電力効果への影響を抑制することができる。
【図面の簡単な説明】
【０００９】
【図１】本発明の実施の形態における画像形成装置のハードウェア構成例を示す図である。
【図２】本発明の実施の形態における画像形成装置のソフトウェア構成例を示す図である。
【図３】本実施の形態の画像形成装置の省電力状態に関する状態遷移の一例を示す図である。
【図４】第一の実施の形態の処理手順を説明するためのシーケンス図である。
【図５】第二の実施の形態の処理手順を説明するためのシーケンス図である。
【図６】第三の実施の形態の処理手順を説明するためのシーケンス図である。
【図７】第四の実施の形態の処理手順を説明するためのシーケンス図である。
【図８】第五の実施の形態の処理手順を説明するためのシーケンス図である。
【発明を実施するための形態】
【００１０】
以下、図面に基づいて本発明の実施の形態を説明する。図１は、本発明の実施の形態における画像形成装置のハードウェア構成例を示す図である。同図において、画像形成装置１０は、コントローラ１１、スキャナ１２、プリンタ１３、モデム１４、操作パネル１５、ネットワークインタフェース１６、及びＳＤカードスロット１７等のハードウェアを有する。
【００１１】
コントローラ１１は、ＣＰＵ１１１、ＲＡＭ１１２、ＲＯＭ１１３、ＨＤＤ１１４、及びＮＶＲＡＭ１１５等を有する。ＲＯＭ１１３には、各種のプログラムやプログラムによって利用されるデータ等が記録されている。ＲＡＭ１１２は、プログラムをロードするための記憶領域や、ロードされたプログラムのワーク領域等として用いられる。ＣＰＵ１１１は、ＲＡＭ１１２にロードされたプログラムを処理することにより、各種の機能を実現する。ＨＤＤ１１４には、プログラムやプログラムが利用する各種のデータ等が記録される。ＮＶＲＡＭ１１５には、各種の設定情報等が記録される。
【００１２】
なお、本発明の実施の形態におけるＲＡＭ１１２、ＨＤＤ１１４、又はＮＶＲＡＭ１１５は、記憶部の一例である。
【００１３】
スキャナ１２は、原稿より画像データを読み取るためのハードウェア（画像読取手段）である。プリンタ１３は、印刷データを印刷用紙に印刷するためのハードウェア（印刷手段）である。モデム１４は、電話回線に接続するためのハードウェアであり、ＦＡＸ通信による画像データの送受信を実行するために用いられる。操作パネル１５は、ユーザからの入力の受け付けを行うためのボタン等の入力手段や、液晶パネル等の表示手段等を備えたハードウェアである。ネットワークインタフェース１６は、ＬＡＮ等のネットワーク（有線又は無線の別は問わない。）に接続するためのハードウェアである。ＳＤカードスロット１７は、ＳＤカード８０に記録されたプログラムを読み取るために利用される。すなわち、画像形成装置１０では、ＲＯＭ１１３に記録されたプログラムだけでなく、ＳＤカード８０に記録されたプログラムもＲＡＭ１１２にロードされ、実行されうる。
【００１４】
図２は、本発明の実施の形態における画像形成装置のソフトウェア構成例を示す図である。同図において、画像形成装置１０は、標準アプリ１５１、ＳＤＫアプリ１５２、ＳＤＫプラットフォーム１５３、コントロールサービス１５４、及びＯＳ１５５等を有する。
【００１５】
標準アプリ１５１は、画像形成装置１０に標準的に（出荷時に予め）実装されているアプリケーションの集合である。同図では、スキャンアプリ１５１１、印刷アプリ１５１２、コピーアプリ１５１３、及びＦＡＸアプリ１５１４が例示されている。スキャンアプリ１５１１は、スキャンジョブを実行する。印刷アプリ１５１２は印刷ジョブを実行する。コピーアプリ１５１３は、コピージョブを実行する。ＦＡＸアプリ１５１４は、ＦＡＸの送信ジョブ又は受信ジョブを実行する。
【００１６】
コントロールサービス１５４は、各種のハードウェアリソース等を制御するための機能を上位アプリケーション等に対して提供したり、画像形成装置１０の基盤的な機能等を実行したりするソフトウェアモジュール群である。同図において、コントロールサービス１５４は、移行制御部１６１、事前通知部１６２、及び移行可否確認部１６３等を有する。
【００１７】
移行制御部１６１は、省電力状態への移行を制御する。省電力状態とは、省電力モード又は省エネモード等とも呼ばれ、画像形成装置１０の消費電力が抑制された状態をいう。例えば、省電力状態では、操作パネル１５への電力の供給が停止又は抑制されたり、スキャナ１２及びプリンタ１３等のエンジン部への電力の供給が停止又は抑制されたりする。
【００１８】
事前通知部１６２は、省電力状態への移行開始時期より前に、画像形成装置１０において起動されているプログラム（例えば、標準アプリ１５１、ＳＤＫアプリ１５２、ＳＤＫプラットフォーム１５３等）に対して、省電力状態への移行の事前通知を行う。省電力状態への移行開始時期とは、画像形成装置１０の仕様により定められた時期である。例えば、無操作状態が所定時間経過した時期である。
【００１９】
移行可否確認部１６３は、省電力状態への移行開始時期において、画像形成装置１０において起動されているプログラムに関して、省電力状態への移行の可否を確認する。突然の省電力状態への移行による各プログラムの動作不正や、各プログラムの処理対象のデータの破壊等を回避するためである。
【００２０】
ＳＤＫアプリ１５２は、画像形成装置１０の出荷後において、画像形成装置１０の機能拡張等を図るためのプラグインとして追加的にインストールされるアプリケーションプログラムである。したがって、ＳＤＫアプリ１５２の機能は、所定のものに限定されない。例えば、ＳＤＫアプリ１５２は、ＳＤカード８０から又はネットワークを介して画像形成装置１０にインストールされる。
【００２１】
ＳＤＫプラットフォーム１５３は、ＳＤＫアプリ１５２の実行環境を提供する。各ＳＤＫアプリ１５２は、ＳＤＫプラットフォーム１５３が提供するＡＰＩ（Application Program Interface）を利用して開発される。例えば、ＳＤＫプラットフォーム１５３は、スキャン機能を利用させるためのインタフェース、印刷機能を利用させるためのインタフェース、コピー機能を利用させるためのインタフェース等をＳＤＫアプリ１５２に提供する。ＳＤＫプラットフォーム１５３のＡＰＩは公開されており、サードベンダ等によってもＳＤＫアプリ１５２は開発されうる。また、当該ＡＰＩは、異機種間において平滑化されている。したがって、ＳＤＫアプリ１５２に関して、機種に応じて異なる実装が行われる必要性は低い。
【００２２】
なお、本実施の形態では、便宜上、画像形成装置１０にインストール可能なプログラムとして、ＳＤＫアプリ１５２及びＳＤＫプラットフォーム１５３等が例示されているが、画像形成装置１０にインストール可能なプログラムは、ＳＤＫアプリ１５２及びＳＤＫプラットフォーム１５３等に限定されない。画像形成装置１０にインストール可能なプログラムには、画像形成装置１０に追加的にインストールされるプログラム全般が含まれうる。
【００２３】
ＯＳ１５５は、いわゆるＯＳ（Operating System）である。画像形成装置１０上の各ソフトウェアは、ＯＳ１５５上においてプロセス又はスレッドとして動作する。
【００２４】
続いて、画像形成装置１０の省電力状態について説明する。図３は、本実施の形態の画像形成装置の省電力状態に関する状態遷移の一例を示す図である。
【００２５】
同図において、通常状態ＳＴ１は、省電力化されていない状態（非省電力状態）である。したがって、ユーザは、画像形成装置１０の機能を即座に利用することができる。通常状態ＳＴ１において、電源キーが押下されたり、又は無操作状態が所定時間継続したりすると、画像形成装置１０は、静音状態ＳＴ２に移行（又は遷移）する。
【００２６】
静音状態ＳＴ２は、省電力状態の一形態である。例えば、静音状態ＳＴ２では、操作パネル１５への電力供給が停止又は抑制される。但し、静音状態ＳＴ２において、標準アプリ１５１、ＳＤＫアプリ１５２、及びＳＤＫプラットフォーム１５３は、起動されたままである。なお、電源キーとは、操作パネル１５に配置され、各状態の切り替えをユーザの任意によって可能とするためのハードキー（ボタン）である。
【００２７】
静音状態ＳＴ２において電源キーが押下されたり、ネットワークを介した印刷データの受信に応じて印刷ジョブが実行されたりすると、画像形成装置１０は、静音状態ＳＴ２から通常状態ＳＴ１へ復帰する。一方、静音状態ＳＴ２が所定時間（以下、「エンジンオフ状態充足時間」という。）継続すると、画像形成装置１０は、エンジンオフ状態ＳＴ３に移行（又は遷移）する。
【００２８】
エンジンオフ状態ＳＴ３は、省電力状態の一形態である。但し、静音状態ＳＴ２とエンジンオフ状態ＳＴ３とは、相互に省電力の程度（省電力効果）が異なる。すなわち、エンジンオフ状態ＳＴ３では、消費電力が更に抑制される（省電力効果が更に高い）。例えば、エンジンオフ状態ＳＴ３では、スキャナ１２及びプリンタ１３等のエンジン部に関しても電力の供給が停止又は抑制される。また、エンジンオフ状態ＳＴ３では、起動されていたＳＤＫアプリ１５２が停止される。
【００２９】
エンジンオフ状態ＳＴ３において、電源キーが押下されたり、圧板が開かれたり、又はＤＦ（Document Feeder）にスキャン又はコピー対象の原稿がセットされたりすると、画像形成装置１０は、通常状態ＳＴ１へ移行（又は遷移）する。
【００３０】
なお、図３に示される状態遷移は、一例である。したがって、他の状態遷移に関して、本実施の形態が適用されてもよい。
【００３１】
以下、画像形成装置１０の処理手順について説明する。図４は、第一の実施の形態の処理手順を説明するためのシーケンス図である。
【００３２】
例えば、通常状態ＳＴ１の画像形成装置１０において、移行制御部１６１は、無操作状態の所定期間の継続又は電源キーの押下を検知すると、ＳＤＫプラットフォーム１５３に対して静音状態ＳＴ２への移行の可否（又は許否。以下、「可否」で統一する。）を問い合わせる（Ｓ１０１）。当該問い合わせに応じ、ＳＤＫプラットフォーム１５３は、ＳＤＫプラットフォーム１５３上において起動中の各ＳＤＫアプリ１５２に対して、静音状態ＳＴ２への移行の可否を問い合わせる（Ｓ１０２）。なお、静音状態ＳＴ２への移行は、各ＳＤＫアプリ１５２に対する影響は小さいため、問い合わせに対する各ＳＤＫアプリ１５２からの応答は、即座に返信される。
【００３３】
続いて、ＳＤＫプラットフォーム１５３は、静音状態ＳＴ２への移行の可否を応答する（Ｓ１０３）。例えば、問い合わせ先の全てのＳＤＫアプリ１５２から移行が可能である（移行を許可する）旨の応答が返信された場合、ＳＤＫプラットフォーム１５３は、移行は可能であることを示す応答を返信する。一方、少なくとも一つのＳＤＫアプリ１５２より移行が不可能である（移行を拒否する）旨の応答が返信された場合、ＳＤＫプラットフォーム１５３は、移行は不可能であることを示す応答を返信する。
【００３４】
移行は可能であることを示す応答が返信された場合、移行制御部１６１は、静音状態ＳＴ２への移行確定をＳＤＫプラットフォーム１５３に通知する（Ｓ１０４）。ＳＤＫプラットフォーム１５３は、当該通知に応じ、静音状態ＳＴ２への移行確定を、起動中のＳＤＫアプリ１５２へ通知する（Ｓ１０５）。これによって、各ＳＤＫアプリ１５２は、静音状態ＳＴ２への移行が確定したことを認識する。すなわち、ステップＳ１０２における問い合わせはＳＤＫアプリ１５２ごとに行われるため、各ＳＤＫアプリ１５２は、他のＳＤＫアプリ１５２について移行の可否は知り得ない。したがって、移行は可能である旨を応答したＳＤＫアプリ１５２は、実際に静音状態ＳＴ２への移行が行われるのか否かを判断することができない。そこで、各ＳＤＫアプリ１５２に、静音状態ＳＴ２への移行確定が通知されるのである。
【００３５】
続いて、ＳＤＫプラットフォーム１５３は、移行確定の通知に対する応答を行う（Ｓ１０６）。当該応答に応じて、移行制御部１６１は、画像形成装置１０を静音状態ＳＴ２へ移行させる。
【００３６】
なお、ステップＳ１０３において移行は不可能であることを示す応答が返信された場合、移行制御部１６１は、静音状態ＳＴ２への移行の中止をＳＤＫプラットフォーム１５３に通知する。ＳＤＫプラットフォーム１５３は、起動中の各ＳＤＫアプリ１５２に対して、移行の中止を通知する。
【００３７】
静音状態ＳＴ２への移行後、エンジンオフ状態充足時間の所定時間前（例えば、１０秒前等）になると（すなわち、「エンジンオフ状態充足時間−所定時間」が経過すると）、事前通知部１６２は、エンジンオフ状態ＳＴ３への移行の事前通知をＳＤＫプラットフォーム１５３に送信する（Ｓ１０７）。
【００３８】
当該事前通知に応じ、ＳＤＫプラットフォーム１５３は、起動中の各ＳＤＫアプリ１５２に関して終了処理を開始する（Ｓ１０８）。例えば、ＳＤＫプラットフォーム１５３は、各ＳＤＫアプリ１５２に対して終了指示を入力する。各ＳＤＫアプリ１５２は、終了指示に応じて、終了化処理等を実行する。終了化処理の内容は、ＳＤＫアプリ１５２ごとに異なりうるが、例えば、メモリ等のリソースの解放や、ログの記録等が行われた後、ＳＤＫアプリ１５２のスレッドが終了する。したがって、ＳＤＫアプリ１５２によっては、終了化処理に数秒を要するものも有りうる。
【００３９】
その後、静音状態ＳＴ２へ移行してからエンジンオフ状態充足時間が経過すると（すなわち、事前通知から所定時間（例えば、１０秒等）が経過すると）、移行可否確認部１６３は、ＳＤＫプラットフォーム１５３に対してエンジンオフ状態ＳＴ３への移行の可否を問い合わせる（Ｓ１０９）。当該問い合わせに応じ、ＳＤＫプラットフォーム１５３は、事前通知に応じて開始した各ＳＤＫアプリ１５２の終了処理を完了させた後（各ＳＤＫアプリ１５２終了させた後）、エンジンオフ状態ＳＴ３への移行は可能であることを示す応答を返信する（Ｓ１１０）。移行制御部１６１は、当該応答に応じ、画像形成装置１０をエンジンオフ状態ＳＴ３へ移行させる。
【００４０】
上述したように、第一の実施の形態の画像形成装置１０では、エンジンオフ状態ＳＴ３への移行開始前（ステップＳ１０９の問い合わせ前）において、ＳＤＫプラットフォーム１５３に対して事前通知が行われる。したがって、ＳＤＫプラットフォーム１５３は、エンジンオフ状態ＳＴ３への移行開始前からＳＤＫアプリ１５２の終了処理を前倒し的に開始することができる。その結果、ステップＳ１０９の問い合わせに応じて行われるステップＳ１１０の応答の時期を早めることができる。すなわち、当該問い合わせ時に全てのＳＤＫアプリ１５２の終了処理が完了していれば、ステップＳ１１０の応答は直ちに行われる。また、当該問い合わせ時に一部のＳＤＫアプリ１５２について終了処理が完了していなくても、応答が返信されるまでの時間は、当該一部のＳＤＫアプリ１５２の終了処理の所要時間に短縮される。したがって、ステップＳ１０９の問い合わせに応じてＳＤＫアプリ１５２の終了処理を開始する場合に比べて、ステップＳ１１０の応答を早めることができる。その結果、ＳＤＫアプリ１５２の追加（又は増加）による、省電力効果の低下を抑制することができる。
【００４１】
次に、第二の実施の形態について説明する。第二の実施の形態では、第一の実施の形態と異なる点について説明する。したがって、特に言及されない点については、第一の実施の形態と同様でよい。
【００４２】
図５は、第二の実施の形態の処理手順を説明するためのシーケンス図である。図５中、図４と同一ステップには、同一符号を付し、その説明は省略する。なお、図５では、ステップＳ１０１〜Ｓ１０３に関して、便宜上、図示は省略されている。
【００４３】
第二の実施の形態では、エンジンオフ状態ＳＴ３への移行の可否の問い合わせ時（Ｓ１０９）において、少なくとも一部のＳＤＫアプリ１５２に関して終了処理が完了していない場合、ＳＤＫプラットフォーム１５３は、移行は不可能であること（移行を拒否すること）を示す応答を直ちに返信する（Ｓ１１０ａ）。
【００４４】
当該応答に応じ、移行制御部１６１は、エンジンオフ状態ＳＴ３への移行のキャンセル（中止）をＳＤＫプラットフォーム１５３に通知する（Ｓ１１１）。続いて、移行制御部１６１は、静音状態ＳＴ２への移行確定をＳＤＫプラットフォーム１５３に通知する（Ｓ１１２）。すなわち、エンジンオフ状態ＳＴ３への移行がキャンセルされたため、静音状態ＳＴ２の維持が通知される。当該通知に応じ、ＳＤＫプラットフォーム１５３は、まだ終了指示を入力していないＳＤＫアプリ１５２が有る場合は、終了指示の入力を中止し、当該ＳＤＫアプリ１５２に対して静音状態ＳＴ２への移行確定を通知する。なお、既に終了指示を入力したＳＤＫアプリ１５２（終了処理が完了したＳＤＫアプリ１５２も含む。）の再起動はこのタイミングでは行われない。当該ＳＤＫアプリ１５２の再起動は、例えば、通常状態ＳＴ１への復帰時に行われる。
【００４５】
続いて、ＳＤＫプラットフォーム１５３は、当該通知に対する応答を返信する（Ｓ１１３）。その後、静音状態ＳＴ２への移行確定の通知（Ｓ１１２）、又は当該通知に対する応答（Ｓ１１３）から所定時間が経過すると、事前通知部１６２は、エンジンオフ状態ＳＴ３への移行の事前通知をＳＤＫプラットフォーム１５３に再送信する（Ｓ１１４）。
【００４６】
当該事前通知に応じ、ＳＤＫプラットフォーム１５３は、ＳＤＫアプリ１５２の終了処理を再開する（Ｓ１１５）。すなわち、終了指示が入力されていないＳＤＫアプリ１５２に対して終了指示が入力される。但し、当該事前通知時において、全てのＳＤＫアプリ１５２の終了処理が完了していれば、ステップＳ１１５は実行されなくてよい。
【００４７】
ステップＳ１１４の事前通知から所定時間が経過すると、移行可否確認部１６３は、ＳＤＫプラットフォーム１５３に対してエンジンオフ状態ＳＴ３への移行の可否を問い合わせる（Ｓ１１６）。当該問い合わせ時において、全てのＳＤＫアプリ１５２に関して終了処理が完了していれば、ＳＤＫプラットフォーム１５３は、エンジンオフ状態ＳＴ３への移行は可能であることを示す応答を返信する（Ｓ１１７）。
【００４８】
上述したように、第二の実施の形態においても、第一の実施の形態と同様の効果を得ることができる。なお、エンジンオフ状態ＳＴ３への移行をキャンセル（Ｓ１１１）されてからエンジンオフ状態ＳＴ３への移行の可否の問い合わせ（Ｓ１１６）が再実行されるまでの時間は、起動していた全てのＳＤＫアプリ１５２の終了処理の所要時間に比べて短いのが望ましい。
【００４９】
次に、第三の実施の形態について説明する。第三の実施の形態では、第一又は第二の実施の形態と異なる点について説明する。したがって、特に言及されない点については、第一又は第二の実施の形態と同様でよい。
【００５０】
図６は、第三の実施の形態の処理手順を説明するためのシーケンス図である。図６中、図４と同一ステップには、同一符号を付し、その説明は省略する。なお、図６では、ステップＳ１０１〜Ｓ１０３に関して、便宜上、図示は省略されている。
【００５１】
第三の実施の形態では、事前通知（Ｓ１０７）後であって、エンジンオフ状態ＳＴ３への移行の可否の問い合わせ（Ｓ１０９）前に、例えば、電源キーの押下等、通常状態ＳＴ１への復帰要因が発生した場合を想定する。
【００５２】
当該復帰要因の発生に応じ、移行制御部１６１は、通常状態ＳＴ１への移行確定をＳＤＫプラットフォーム１５３に通知する（Ｓ１２１）。当該通知に応じ、ＳＤＫプラットフォーム１５３は、終了処理を行ったＳＤＫアプリ１５２に関して、起動処理を実行する（Ｓ１２２）。ＳＤＫプラットフォーム１５３は、当該起動処理が完了すると、応答を返信する（Ｓ１２３）。
【００５３】
このように、事前通知後であって、静音状態ＳＴ２の移行からエンジンオフ状態充足時間が経過する前に通常状態ＳＴ１への復帰が行われる場合であっても、前倒し的に終了されたＳＤＫアプリ１５２は、自動的に再起動される。したがって、ユーザが不便を感じる可能性を低下させることができる。
【００５４】
次に、第四の実施の形態について説明する。第四の実施の形態では、第二の実施の形態と異なる点について説明する。したがって、特に言及されない点については、第二の実施の形態と同様でよい。
【００５５】
図７は、第四の実施の形態の処理手順を説明するためのシーケンス図である。図７中、図５と同一ステップには、同一符号を付し、その説明は適宜省略する。
【００５６】
図７において、「他モジュール」は、標準アプリ１５１等、ＳＤＫプラットフォーム１５３及びＳＤＫアプリ１５２以外のプログラムモジュールをいう。なお、他の実施の形態において、他モジュールの存在は、便宜上省略されていただけであり、他モジュールに関しても、ＳＤＫプラットフォーム１５３と同様に、省電力状態の遷移に関する各種の通知は行われる。
【００５７】
図７では、ステップＳ１０８が、ステップＳ１０８ａに置き換わっている。ステップＳ１０８ａにおいて、ＳＤＫプラットフォーム１５３は、起動中の各ＳＤＫアプリ１５２に関して終了処理を開始する。この際、ＳＤＫプラットフォーム１５３は、省電力対応のＳＤＫアプリ１５２に関しては、終了ではなく、中断状態への移行指示を入力する。
【００５８】
省電力対応のＳＤＫアプリ１５２とは、エンジンオフ状態ＳＴ３においても終了が回避されるように実装されているＳＤＫアプリ１５２をいう。例えば、ＦＡＸの受信機能を有するＳＤＫアプリ１５２のように、エンジンオフ状態ＳＴ３において起動状態が維持される必要の有るＳＤＫアプリ１５２は、省電力対応のＳＤＫアプリ１５２として実装される。いずれのＳＤＫアプリ１５２が省電力対応であるか否かは、例えば、ＳＤＫアプリ１５２のインストール時において、ＳＤＫプラットフォーム１５３に対して設定される。
【００５９】
また、中断状態とは、省電力対応のＳＤＫアプリ１５２が有する状態であり、現在実行中の処理を区切りの良い箇所で中断させ、それ以降の処理を進行させない状態をいう。したがって、中断状態のＳＤＫアプリ１２のスレッドは終了しない。
【００６０】
また、図７では、ステップＳ１１０ａが、ステップＳ１１０ｂに置き換わっている。すなわち、図７では、エンジンオフ状態ＳＴ３への移行の可否の問い合わせ時（Ｓ１０９）において、全てのＳＤＫアプリ１５２に関して、終了処理又は中断状態への移行が完了していることとする。したがって、ステップＳ１１０ｂにおいて、ＳＤＫプラットフォーム１５３は、エンジンオフ状態ＳＴ３への移行は可能であることを示す応答を返信する。
【００６１】
続いて、移行可否確認部１６３は、他モジュールに対しても、エンジンオフ状態ＳＴ３への移行の可否を問い合わせる（Ｓ１０９−２）。ここでは、少なくとも一部の他モジュールが、エンジンオフ状態ＳＴ３へ移行できない状態であるとする。例えば、印刷アプリ１５１２が、印刷を実行中であったり、ＦＡＸアプリ１５１４が、ＦＡＸの送信又はＦＡＸの受信を実行中であったりする。そこで、当該一部の他モジュールは、移行は不可能であること（移行を拒否すること）を示す応答を返信する（Ｓ１１０−２）。
【００６２】
すなわち、第四の実施の形態では、ＳＤＫプラットフォーム１５３以外の他モジュールによって、エンジンオフ状態ＳＴ３への移行が拒否される点が、第二の実施の形態と異なる点の一つである。
【００６３】
いずれかの他モジュールから、移行は不可能であることを示す応答が返信されると、移行制御部１６１は、エンジンオフ状態ＳＴ３への移行のキャンセル（中止）を、ＳＤＫプラットフォーム１５３と、各他モジュールとに通知する（Ｓ１１１−１、Ｓ１１１−２）。
【００６４】
続いて、移行制御部１６１は、静音状態ＳＴ２への移行確定をＳＤＫプラットフォーム１５３に通知する（Ｓ１１２−１）。静音状態ＳＴ２への移行確定の通知に応じ、ＳＤＫプラットフォーム１５３は、ステップＳ１０８ａにおいて中断状態へ移行させた、省電力対応の各ＳＤＫアプリ１５２に関して、中断状態を解除する（Ｓ１１２−１１）。その結果、省電力対応の各ＳＤＫアプリ１５２は、通常の動作状態に復帰する。続いて、ＳＤＫプラットフォーム１５３は、静音状態ＳＴ２への移行確定の通知に対する応答を返信する（Ｓ１１３−１）。
【００６５】
移行制御部１６１は、また、静音状態ＳＴ２への移行確定を各他モジュールにも通知する（Ｓ１１２−２）。当該通知を受けた各他モジュールは、当該通知に対する応答を返信する（Ｓ１１３−２）。
【００６６】
その後、静音状態ＳＴ２への移行確定の通知（Ｓ１１２）、又は当該通知に対する応答（Ｓ１１３）から所定時間が経過すると、事前通知部１６２は、エンジンオフ状態ＳＴ３への移行の事前通知をＳＤＫプラットフォーム１５３に再送信する（Ｓ１１４）。
【００６７】
当該事前通知に応じ、ＳＤＫプラットフォーム１５３は、省電力対応の各ＳＤＫアプリ１５２に対して、中断状態への移行指示を入力する（Ｓ１１５ａ）。ここで、省電力対応でないＳＤＫアプリ１５２に関して、終了処理は実行されない。省電力対応でないＳＤＫアプリ１５２は、ステップＳ１０８ａにおいて、既に終了しているからである。
【００６８】
ステップＳ１１４の事前通知から所定時間が経過すると、移行可否確認部１６３は、ＳＤＫプラットフォーム１５３に対してエンジンオフ状態ＳＴ３への移行の可否を問い合わせる（Ｓ１１６−１）。当該問い合わせ時において、省エネ対応の全てのＳＤＫアプリ１５２に関して中断状態への移行が完了していれば、ＳＤＫプラットフォーム１５３は、エンジンオフ状態ＳＴ３への移行は可能であることを示す応答を返信する（Ｓ１１７−１）。
【００６９】
続いて、移行可否確認部１６３は、各他モジュールに対してエンジンオフ状態ＳＴ３への移行の可否を問い合わせる（Ｓ１１６−２）。各他モジュールは、エンジンオフ状態ＳＴ３への移行が可能であれば、エンジンオフ状態ＳＴ３への移行は可能であることを示す応答を返信する（Ｓ１１７−２）。
【００７０】
なお、ステップＳ１１６−１とステップＳ１１６−２との順番は、逆であってもよいし、並列的に実行されてもよい。
【００７１】
上述したように、第四の実施の形態においても、第二の実施の形態と同様の効果を得ることができる。
【００７２】
次に、第五の実施の形態について説明する。第五の実施の形態では、第三の実施の形態と異なる点について説明する。したがって、特に言及されない点については、第三の実施の形態と同様でよい。
【００７３】
図８は、第五の実施の形態の処理手順を説明するためのシーケンス図である。図８中、図６又は図７と同一ステップには、同一符号を付し、その説明は適宜省略する。
【００７４】
第五の実施の形態では、エンジンオフ状態ＳＴ３への事前通知（Ｓ１０７）から所定時間が経過する前に、画像形成装置１０がオフライン状態へ移行した場合について説明する。
【００７５】
オフライン状態とは、例えば、操作パネル１５に表示される管理者用の設定画面を介して、画像形成装置１０の動作に関するパラメータの値の設定変更等が行われる状態をいう。例えば、管理者用の設定画面の表示指示に応じて、画像形成装置１０はオフライン状態へ移行する。なお、オフライン状態は、図３において説明した、省電力状態に関する状態遷移とは別の観点における状態遷移に関する状態である。
【００７６】
オフライン状態では、上記のようなパラメータの値の設定変更が行われるため、オフライン状態中に、エンジンオフ状態ＳＴ３への移行が行われてしまうのは好ましくない。パラメータの値の設定変更は、ＨＤＤ１１４又はＮＶＲＡＭ１１５等への書き込み処理が発生するところ、エンジンオフ状態ＳＴ３においては、ＨＤＤ１１４又はＮＶＲＡＭ１１５等への電力の供給が停止され、当該書き込み処理を行えなくなってしまうからである。
【００７７】
そこで、画像形成装置１０がオフライン状態へ移行すると、移行制御部１６１は、エンジンオフ状態ＳＴ３への事前通知からの所定時間の経過を計測するためのタイマの進行を停止させる。続いて、移行制御部１６１は、静音状態ＳＴ２への移行確定をＳＤＫプラットフォーム１５３に通知する（Ｓ１２１ａ）。ここで、静音状態ＳＴ２への移行確定が通知されるのは、エンジンオフ状態ＳＴ３への移行は中止となったことをＳＤＫプラットフォーム１５３に通知し、ＳＤＫプラットフォーム１５３及びＳＤＫアプリ１５２の動作状態を、画像形成装置１０の省電力状態に則したものに変更させるためである。
【００７８】
すなわち、ＳＤＫプラットフォーム１５３及びＳＤＫアプリ１５２は、エンジンオフ状態ＳＴ３への移行の事前通知を受けて、エンジンオフ状態ＳＴ３に対応した動作状態へ移行している。仮に、静音状態ＳＴ２への移行確定が通知されなければ、ＳＤＫプラットフォーム１５３及びＳＤＫアプリ１５２は、画像形成装置１０は静音状態ＳＴ２であるにも拘わらず、エンジンオフ状態ＳＴ３に対応した動作状態を維持し、その機能を発揮することができないからである。
【００７９】
静音状態ＳＴ２への移行確定の通知に応じ、ＳＤＫプラットフォーム１５３は、ステップＳ１０８ａにおいて中断状態へ移行させた、省電力対応の各ＳＤＫアプリ１５２に関して、中断状態を解除する（Ｓ１２２ａ）。ＳＤＫプラットフォーム１５３は、中断状態の解除が完了すると、応答を返信する（Ｓ１２３）。
【００８０】
このように、事前通知後であって、静音状態ＳＴ２の移行からエンジンオフ状態充足時間が経過する前に、オフライン状態へ移行した場合であっても、前倒し的に中断状態とされた省電力対応のＳＤＫアプリ１５２の中断状態は、自動的に解除される。したがって、ユーザが不便を感じる可能性を低下させることができる。
【００８１】
なお、上記各実施の形態は、省電力状態を有する機器であれば、例えば、プロジェクタ、スマートフォン、携帯電話、又はデジタルカメラ等、画像形成装置１０以外の機器に適用可能である。
【００８２】
以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【符号の説明】
【００８３】
１０ 画像形成装置
１１ コントローラ
１２ スキャナ
１３ プリンタ
１４ モデム
１５ 操作パネル
１６ ネットワークインタフェース
１７ ＳＤカードスロット
８０ ＳＤカード
１１１ ＣＰＵ
１１２ ＲＡＭ
１１３ ＲＯＭ
１１４ ＨＤＤ
１１５ ＮＶＲＡＭ
１５１ 標準アプリ
１５２ ＳＤＫアプリ
１５３ ＳＤＫプラットフォーム
１５４ コントロールサービス
１５５ ＯＳ
１６１ 移行制御部
１６２ 事前通知部
１６３ 移行可否確認部
１５１１ スキャンアプリ
１５１２ 印刷アプリ
１５１３ コピーアプリ
１５１４ ＦＡＸアプリ
【先行技術文献】
【特許文献】
【００８４】
【特許文献１】特開２００７−１５２８２４号公報
【技術分野】
【０００１】
本発明は、機器、省電力制御方法、省電力制御プログラム、及び記録媒体に関する。
【背景技術】
【０００２】
従来、プリンタ、ファクシミリ、コピー機、又は複合機等の画像形成装置などのように、省電力化を図るため、例えば、無操作状態が所定時間継続すると省電力状態（省電力モード又は省エネモード等とも呼ばれる。）に移行する機器がある。例えば、斯かる画像形成装置の中には、省電力状態の移行時において、画像形成装置内において動作する各部（例えば、プログラム群等）に関して、省電力状態への移行の可否の確認が行われるものもある。すなわち、各部に関して省電力状態への移行が可能であることが確認された場合に限って省電力状態への移行が行われる。突然の省電力状態への移行による各部の動作不正や、各部の処理対象のデータの破壊等を防止するためである。
【０００３】
他方において、画像形成装置の中には、アプリケーションプログラムを実装するためのＡＰＩ（Application Program Interface）が公開され、その出荷後に、ユーザ所望のアプリケーションプログラムをインストールすることにより、機能拡張が可能とされているものもある。このような画像形成装置においては、ユーザの利用形態に応じて、多数のアプリケーションプログラムが動作する可能性がある。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、このような画像形成装置を一例とする機器において動作するアプリケーションプログラムが増加すると、省電力状態への移行時における確認対象が増加する。すなわち、インストールされた各アプリケーションプログラムに関しても、省電力状態への移行の可否の確認が行われる必要がある。斯かる確認対象の増加は、省電力状態への移行の可否の確認処理の長期化を招く。その結果、省電力状態への移行が遅れ、結果的に省電力効果が低下してしまう可能性がある。
【０００５】
本発明は、上記の点に鑑みてなされたものであって、プログラムの追加による省電力効果への影響を抑制することができる機器、省電力制御方法、省電力制御プログラム、及び記録媒体の提供を目的とする。
【課題を解決するための手段】
【０００６】
そこで上記課題を解決するため、本発明は、プログラムをインストール可能な機器であって、省電力状態への移行開始時期より前に、前記プログラムに対する省電力状態への移行通知を行う事前通知手段と、前記移行開始時期に、前記プログラムに関して省電力状態への移行の可否を問い合わせる確認手段とを有し前記確認手段によって問い合わせが行われた前記プログラムに関して省電力状態への移行が可能である場合に、省電力状態へ移行する。
【０００７】
このような機器では、プログラムの追加による省電力効果への影響を抑制することができる。
【発明の効果】
【０００８】
本発明によれば、プログラムの追加による省電力効果への影響を抑制することができる。
【図面の簡単な説明】
【０００９】
【図１】本発明の実施の形態における画像形成装置のハードウェア構成例を示す図である。
【図２】本発明の実施の形態における画像形成装置のソフトウェア構成例を示す図である。
【図３】本実施の形態の画像形成装置の省電力状態に関する状態遷移の一例を示す図である。
【図４】第一の実施の形態の処理手順を説明するためのシーケンス図である。
【図５】第二の実施の形態の処理手順を説明するためのシーケンス図である。
【図６】第三の実施の形態の処理手順を説明するためのシーケンス図である。
【図７】第四の実施の形態の処理手順を説明するためのシーケンス図である。
【図８】第五の実施の形態の処理手順を説明するためのシーケンス図である。
【発明を実施するための形態】
【００１０】
以下、図面に基づいて本発明の実施の形態を説明する。図１は、本発明の実施の形態における画像形成装置のハードウェア構成例を示す図である。同図において、画像形成装置１０は、コントローラ１１、スキャナ１２、プリンタ１３、モデム１４、操作パネル１５、ネットワークインタフェース１６、及びＳＤカードスロット１７等のハードウェアを有する。
【００１１】
コントローラ１１は、ＣＰＵ１１１、ＲＡＭ１１２、ＲＯＭ１１３、ＨＤＤ１１４、及びＮＶＲＡＭ１１５等を有する。ＲＯＭ１１３には、各種のプログラムやプログラムによって利用されるデータ等が記録されている。ＲＡＭ１１２は、プログラムをロードするための記憶領域や、ロードされたプログラムのワーク領域等として用いられる。ＣＰＵ１１１は、ＲＡＭ１１２にロードされたプログラムを処理することにより、各種の機能を実現する。ＨＤＤ１１４には、プログラムやプログラムが利用する各種のデータ等が記録される。ＮＶＲＡＭ１１５には、各種の設定情報等が記録される。
【００１２】
なお、本発明の実施の形態におけるＲＡＭ１１２、ＨＤＤ１１４、又はＮＶＲＡＭ１１５は、記憶部の一例である。
【００１３】
スキャナ１２は、原稿より画像データを読み取るためのハードウェア（画像読取手段）である。プリンタ１３は、印刷データを印刷用紙に印刷するためのハードウェア（印刷手段）である。モデム１４は、電話回線に接続するためのハードウェアであり、ＦＡＸ通信による画像データの送受信を実行するために用いられる。操作パネル１５は、ユーザからの入力の受け付けを行うためのボタン等の入力手段や、液晶パネル等の表示手段等を備えたハードウェアである。ネットワークインタフェース１６は、ＬＡＮ等のネットワーク（有線又は無線の別は問わない。）に接続するためのハードウェアである。ＳＤカードスロット１７は、ＳＤカード８０に記録されたプログラムを読み取るために利用される。すなわち、画像形成装置１０では、ＲＯＭ１１３に記録されたプログラムだけでなく、ＳＤカード８０に記録されたプログラムもＲＡＭ１１２にロードされ、実行されうる。
【００１４】
図２は、本発明の実施の形態における画像形成装置のソフトウェア構成例を示す図である。同図において、画像形成装置１０は、標準アプリ１５１、ＳＤＫアプリ１５２、ＳＤＫプラットフォーム１５３、コントロールサービス１５４、及びＯＳ１５５等を有する。
【００１５】
標準アプリ１５１は、画像形成装置１０に標準的に（出荷時に予め）実装されているアプリケーションの集合である。同図では、スキャンアプリ１５１１、印刷アプリ１５１２、コピーアプリ１５１３、及びＦＡＸアプリ１５１４が例示されている。スキャンアプリ１５１１は、スキャンジョブを実行する。印刷アプリ１５１２は印刷ジョブを実行する。コピーアプリ１５１３は、コピージョブを実行する。ＦＡＸアプリ１５１４は、ＦＡＸの送信ジョブ又は受信ジョブを実行する。
【００１６】
コントロールサービス１５４は、各種のハードウェアリソース等を制御するための機能を上位アプリケーション等に対して提供したり、画像形成装置１０の基盤的な機能等を実行したりするソフトウェアモジュール群である。同図において、コントロールサービス１５４は、移行制御部１６１、事前通知部１６２、及び移行可否確認部１６３等を有する。
【００１７】
移行制御部１６１は、省電力状態への移行を制御する。省電力状態とは、省電力モード又は省エネモード等とも呼ばれ、画像形成装置１０の消費電力が抑制された状態をいう。例えば、省電力状態では、操作パネル１５への電力の供給が停止又は抑制されたり、スキャナ１２及びプリンタ１３等のエンジン部への電力の供給が停止又は抑制されたりする。
【００１８】
事前通知部１６２は、省電力状態への移行開始時期より前に、画像形成装置１０において起動されているプログラム（例えば、標準アプリ１５１、ＳＤＫアプリ１５２、ＳＤＫプラットフォーム１５３等）に対して、省電力状態への移行の事前通知を行う。省電力状態への移行開始時期とは、画像形成装置１０の仕様により定められた時期である。例えば、無操作状態が所定時間経過した時期である。
【００１９】
移行可否確認部１６３は、省電力状態への移行開始時期において、画像形成装置１０において起動されているプログラムに関して、省電力状態への移行の可否を確認する。突然の省電力状態への移行による各プログラムの動作不正や、各プログラムの処理対象のデータの破壊等を回避するためである。
【００２０】
ＳＤＫアプリ１５２は、画像形成装置１０の出荷後において、画像形成装置１０の機能拡張等を図るためのプラグインとして追加的にインストールされるアプリケーションプログラムである。したがって、ＳＤＫアプリ１５２の機能は、所定のものに限定されない。例えば、ＳＤＫアプリ１５２は、ＳＤカード８０から又はネットワークを介して画像形成装置１０にインストールされる。
【００２１】
ＳＤＫプラットフォーム１５３は、ＳＤＫアプリ１５２の実行環境を提供する。各ＳＤＫアプリ１５２は、ＳＤＫプラットフォーム１５３が提供するＡＰＩ（Application Program Interface）を利用して開発される。例えば、ＳＤＫプラットフォーム１５３は、スキャン機能を利用させるためのインタフェース、印刷機能を利用させるためのインタフェース、コピー機能を利用させるためのインタフェース等をＳＤＫアプリ１５２に提供する。ＳＤＫプラットフォーム１５３のＡＰＩは公開されており、サードベンダ等によってもＳＤＫアプリ１５２は開発されうる。また、当該ＡＰＩは、異機種間において平滑化されている。したがって、ＳＤＫアプリ１５２に関して、機種に応じて異なる実装が行われる必要性は低い。
【００２２】
なお、本実施の形態では、便宜上、画像形成装置１０にインストール可能なプログラムとして、ＳＤＫアプリ１５２及びＳＤＫプラットフォーム１５３等が例示されているが、画像形成装置１０にインストール可能なプログラムは、ＳＤＫアプリ１５２及びＳＤＫプラットフォーム１５３等に限定されない。画像形成装置１０にインストール可能なプログラムには、画像形成装置１０に追加的にインストールされるプログラム全般が含まれうる。
【００２３】
ＯＳ１５５は、いわゆるＯＳ（Operating System）である。画像形成装置１０上の各ソフトウェアは、ＯＳ１５５上においてプロセス又はスレッドとして動作する。
【００２４】
続いて、画像形成装置１０の省電力状態について説明する。図３は、本実施の形態の画像形成装置の省電力状態に関する状態遷移の一例を示す図である。
【００２５】
同図において、通常状態ＳＴ１は、省電力化されていない状態（非省電力状態）である。したがって、ユーザは、画像形成装置１０の機能を即座に利用することができる。通常状態ＳＴ１において、電源キーが押下されたり、又は無操作状態が所定時間継続したりすると、画像形成装置１０は、静音状態ＳＴ２に移行（又は遷移）する。
【００２６】
静音状態ＳＴ２は、省電力状態の一形態である。例えば、静音状態ＳＴ２では、操作パネル１５への電力供給が停止又は抑制される。但し、静音状態ＳＴ２において、標準アプリ１５１、ＳＤＫアプリ１５２、及びＳＤＫプラットフォーム１５３は、起動されたままである。なお、電源キーとは、操作パネル１５に配置され、各状態の切り替えをユーザの任意によって可能とするためのハードキー（ボタン）である。
【００２７】
静音状態ＳＴ２において電源キーが押下されたり、ネットワークを介した印刷データの受信に応じて印刷ジョブが実行されたりすると、画像形成装置１０は、静音状態ＳＴ２から通常状態ＳＴ１へ復帰する。一方、静音状態ＳＴ２が所定時間（以下、「エンジンオフ状態充足時間」という。）継続すると、画像形成装置１０は、エンジンオフ状態ＳＴ３に移行（又は遷移）する。
【００２８】
エンジンオフ状態ＳＴ３は、省電力状態の一形態である。但し、静音状態ＳＴ２とエンジンオフ状態ＳＴ３とは、相互に省電力の程度（省電力効果）が異なる。すなわち、エンジンオフ状態ＳＴ３では、消費電力が更に抑制される（省電力効果が更に高い）。例えば、エンジンオフ状態ＳＴ３では、スキャナ１２及びプリンタ１３等のエンジン部に関しても電力の供給が停止又は抑制される。また、エンジンオフ状態ＳＴ３では、起動されていたＳＤＫアプリ１５２が停止される。
【００２９】
エンジンオフ状態ＳＴ３において、電源キーが押下されたり、圧板が開かれたり、又はＤＦ（Document Feeder）にスキャン又はコピー対象の原稿がセットされたりすると、画像形成装置１０は、通常状態ＳＴ１へ移行（又は遷移）する。
【００３０】
なお、図３に示される状態遷移は、一例である。したがって、他の状態遷移に関して、本実施の形態が適用されてもよい。
【００３１】
以下、画像形成装置１０の処理手順について説明する。図４は、第一の実施の形態の処理手順を説明するためのシーケンス図である。
【００３２】
例えば、通常状態ＳＴ１の画像形成装置１０において、移行制御部１６１は、無操作状態の所定期間の継続又は電源キーの押下を検知すると、ＳＤＫプラットフォーム１５３に対して静音状態ＳＴ２への移行の可否（又は許否。以下、「可否」で統一する。）を問い合わせる（Ｓ１０１）。当該問い合わせに応じ、ＳＤＫプラットフォーム１５３は、ＳＤＫプラットフォーム１５３上において起動中の各ＳＤＫアプリ１５２に対して、静音状態ＳＴ２への移行の可否を問い合わせる（Ｓ１０２）。なお、静音状態ＳＴ２への移行は、各ＳＤＫアプリ１５２に対する影響は小さいため、問い合わせに対する各ＳＤＫアプリ１５２からの応答は、即座に返信される。
【００３３】
続いて、ＳＤＫプラットフォーム１５３は、静音状態ＳＴ２への移行の可否を応答する（Ｓ１０３）。例えば、問い合わせ先の全てのＳＤＫアプリ１５２から移行が可能である（移行を許可する）旨の応答が返信された場合、ＳＤＫプラットフォーム１５３は、移行は可能であることを示す応答を返信する。一方、少なくとも一つのＳＤＫアプリ１５２より移行が不可能である（移行を拒否する）旨の応答が返信された場合、ＳＤＫプラットフォーム１５３は、移行は不可能であることを示す応答を返信する。
【００３４】
移行は可能であることを示す応答が返信された場合、移行制御部１６１は、静音状態ＳＴ２への移行確定をＳＤＫプラットフォーム１５３に通知する（Ｓ１０４）。ＳＤＫプラットフォーム１５３は、当該通知に応じ、静音状態ＳＴ２への移行確定を、起動中のＳＤＫアプリ１５２へ通知する（Ｓ１０５）。これによって、各ＳＤＫアプリ１５２は、静音状態ＳＴ２への移行が確定したことを認識する。すなわち、ステップＳ１０２における問い合わせはＳＤＫアプリ１５２ごとに行われるため、各ＳＤＫアプリ１５２は、他のＳＤＫアプリ１５２について移行の可否は知り得ない。したがって、移行は可能である旨を応答したＳＤＫアプリ１５２は、実際に静音状態ＳＴ２への移行が行われるのか否かを判断することができない。そこで、各ＳＤＫアプリ１５２に、静音状態ＳＴ２への移行確定が通知されるのである。
【００３５】
続いて、ＳＤＫプラットフォーム１５３は、移行確定の通知に対する応答を行う（Ｓ１０６）。当該応答に応じて、移行制御部１６１は、画像形成装置１０を静音状態ＳＴ２へ移行させる。
【００３６】
なお、ステップＳ１０３において移行は不可能であることを示す応答が返信された場合、移行制御部１６１は、静音状態ＳＴ２への移行の中止をＳＤＫプラットフォーム１５３に通知する。ＳＤＫプラットフォーム１５３は、起動中の各ＳＤＫアプリ１５２に対して、移行の中止を通知する。
【００３７】
静音状態ＳＴ２への移行後、エンジンオフ状態充足時間の所定時間前（例えば、１０秒前等）になると（すなわち、「エンジンオフ状態充足時間−所定時間」が経過すると）、事前通知部１６２は、エンジンオフ状態ＳＴ３への移行の事前通知をＳＤＫプラットフォーム１５３に送信する（Ｓ１０７）。
【００３８】
当該事前通知に応じ、ＳＤＫプラットフォーム１５３は、起動中の各ＳＤＫアプリ１５２に関して終了処理を開始する（Ｓ１０８）。例えば、ＳＤＫプラットフォーム１５３は、各ＳＤＫアプリ１５２に対して終了指示を入力する。各ＳＤＫアプリ１５２は、終了指示に応じて、終了化処理等を実行する。終了化処理の内容は、ＳＤＫアプリ１５２ごとに異なりうるが、例えば、メモリ等のリソースの解放や、ログの記録等が行われた後、ＳＤＫアプリ１５２のスレッドが終了する。したがって、ＳＤＫアプリ１５２によっては、終了化処理に数秒を要するものも有りうる。
【００３９】
その後、静音状態ＳＴ２へ移行してからエンジンオフ状態充足時間が経過すると（すなわち、事前通知から所定時間（例えば、１０秒等）が経過すると）、移行可否確認部１６３は、ＳＤＫプラットフォーム１５３に対してエンジンオフ状態ＳＴ３への移行の可否を問い合わせる（Ｓ１０９）。当該問い合わせに応じ、ＳＤＫプラットフォーム１５３は、事前通知に応じて開始した各ＳＤＫアプリ１５２の終了処理を完了させた後（各ＳＤＫアプリ１５２終了させた後）、エンジンオフ状態ＳＴ３への移行は可能であることを示す応答を返信する（Ｓ１１０）。移行制御部１６１は、当該応答に応じ、画像形成装置１０をエンジンオフ状態ＳＴ３へ移行させる。
【００４０】
上述したように、第一の実施の形態の画像形成装置１０では、エンジンオフ状態ＳＴ３への移行開始前（ステップＳ１０９の問い合わせ前）において、ＳＤＫプラットフォーム１５３に対して事前通知が行われる。したがって、ＳＤＫプラットフォーム１５３は、エンジンオフ状態ＳＴ３への移行開始前からＳＤＫアプリ１５２の終了処理を前倒し的に開始することができる。その結果、ステップＳ１０９の問い合わせに応じて行われるステップＳ１１０の応答の時期を早めることができる。すなわち、当該問い合わせ時に全てのＳＤＫアプリ１５２の終了処理が完了していれば、ステップＳ１１０の応答は直ちに行われる。また、当該問い合わせ時に一部のＳＤＫアプリ１５２について終了処理が完了していなくても、応答が返信されるまでの時間は、当該一部のＳＤＫアプリ１５２の終了処理の所要時間に短縮される。したがって、ステップＳ１０９の問い合わせに応じてＳＤＫアプリ１５２の終了処理を開始する場合に比べて、ステップＳ１１０の応答を早めることができる。その結果、ＳＤＫアプリ１５２の追加（又は増加）による、省電力効果の低下を抑制することができる。
【００４１】
次に、第二の実施の形態について説明する。第二の実施の形態では、第一の実施の形態と異なる点について説明する。したがって、特に言及されない点については、第一の実施の形態と同様でよい。
【００４２】
図５は、第二の実施の形態の処理手順を説明するためのシーケンス図である。図５中、図４と同一ステップには、同一符号を付し、その説明は省略する。なお、図５では、ステップＳ１０１〜Ｓ１０３に関して、便宜上、図示は省略されている。
【００４３】
第二の実施の形態では、エンジンオフ状態ＳＴ３への移行の可否の問い合わせ時（Ｓ１０９）において、少なくとも一部のＳＤＫアプリ１５２に関して終了処理が完了していない場合、ＳＤＫプラットフォーム１５３は、移行は不可能であること（移行を拒否すること）を示す応答を直ちに返信する（Ｓ１１０ａ）。
【００４４】
当該応答に応じ、移行制御部１６１は、エンジンオフ状態ＳＴ３への移行のキャンセル（中止）をＳＤＫプラットフォーム１５３に通知する（Ｓ１１１）。続いて、移行制御部１６１は、静音状態ＳＴ２への移行確定をＳＤＫプラットフォーム１５３に通知する（Ｓ１１２）。すなわち、エンジンオフ状態ＳＴ３への移行がキャンセルされたため、静音状態ＳＴ２の維持が通知される。当該通知に応じ、ＳＤＫプラットフォーム１５３は、まだ終了指示を入力していないＳＤＫアプリ１５２が有る場合は、終了指示の入力を中止し、当該ＳＤＫアプリ１５２に対して静音状態ＳＴ２への移行確定を通知する。なお、既に終了指示を入力したＳＤＫアプリ１５２（終了処理が完了したＳＤＫアプリ１５２も含む。）の再起動はこのタイミングでは行われない。当該ＳＤＫアプリ１５２の再起動は、例えば、通常状態ＳＴ１への復帰時に行われる。
【００４５】
続いて、ＳＤＫプラットフォーム１５３は、当該通知に対する応答を返信する（Ｓ１１３）。その後、静音状態ＳＴ２への移行確定の通知（Ｓ１１２）、又は当該通知に対する応答（Ｓ１１３）から所定時間が経過すると、事前通知部１６２は、エンジンオフ状態ＳＴ３への移行の事前通知をＳＤＫプラットフォーム１５３に再送信する（Ｓ１１４）。
【００４６】
当該事前通知に応じ、ＳＤＫプラットフォーム１５３は、ＳＤＫアプリ１５２の終了処理を再開する（Ｓ１１５）。すなわち、終了指示が入力されていないＳＤＫアプリ１５２に対して終了指示が入力される。但し、当該事前通知時において、全てのＳＤＫアプリ１５２の終了処理が完了していれば、ステップＳ１１５は実行されなくてよい。
【００４７】
ステップＳ１１４の事前通知から所定時間が経過すると、移行可否確認部１６３は、ＳＤＫプラットフォーム１５３に対してエンジンオフ状態ＳＴ３への移行の可否を問い合わせる（Ｓ１１６）。当該問い合わせ時において、全てのＳＤＫアプリ１５２に関して終了処理が完了していれば、ＳＤＫプラットフォーム１５３は、エンジンオフ状態ＳＴ３への移行は可能であることを示す応答を返信する（Ｓ１１７）。
【００４８】
上述したように、第二の実施の形態においても、第一の実施の形態と同様の効果を得ることができる。なお、エンジンオフ状態ＳＴ３への移行をキャンセル（Ｓ１１１）されてからエンジンオフ状態ＳＴ３への移行の可否の問い合わせ（Ｓ１１６）が再実行されるまでの時間は、起動していた全てのＳＤＫアプリ１５２の終了処理の所要時間に比べて短いのが望ましい。
【００４９】
次に、第三の実施の形態について説明する。第三の実施の形態では、第一又は第二の実施の形態と異なる点について説明する。したがって、特に言及されない点については、第一又は第二の実施の形態と同様でよい。
【００５０】
図６は、第三の実施の形態の処理手順を説明するためのシーケンス図である。図６中、図４と同一ステップには、同一符号を付し、その説明は省略する。なお、図６では、ステップＳ１０１〜Ｓ１０３に関して、便宜上、図示は省略されている。
【００５１】
第三の実施の形態では、事前通知（Ｓ１０７）後であって、エンジンオフ状態ＳＴ３への移行の可否の問い合わせ（Ｓ１０９）前に、例えば、電源キーの押下等、通常状態ＳＴ１への復帰要因が発生した場合を想定する。
【００５２】
当該復帰要因の発生に応じ、移行制御部１６１は、通常状態ＳＴ１への移行確定をＳＤＫプラットフォーム１５３に通知する（Ｓ１２１）。当該通知に応じ、ＳＤＫプラットフォーム１５３は、終了処理を行ったＳＤＫアプリ１５２に関して、起動処理を実行する（Ｓ１２２）。ＳＤＫプラットフォーム１５３は、当該起動処理が完了すると、応答を返信する（Ｓ１２３）。
【００５３】
このように、事前通知後であって、静音状態ＳＴ２の移行からエンジンオフ状態充足時間が経過する前に通常状態ＳＴ１への復帰が行われる場合であっても、前倒し的に終了されたＳＤＫアプリ１５２は、自動的に再起動される。したがって、ユーザが不便を感じる可能性を低下させることができる。
【００５４】
次に、第四の実施の形態について説明する。第四の実施の形態では、第二の実施の形態と異なる点について説明する。したがって、特に言及されない点については、第二の実施の形態と同様でよい。
【００５５】
図７は、第四の実施の形態の処理手順を説明するためのシーケンス図である。図７中、図５と同一ステップには、同一符号を付し、その説明は適宜省略する。
【００５６】
図７において、「他モジュール」は、標準アプリ１５１等、ＳＤＫプラットフォーム１５３及びＳＤＫアプリ１５２以外のプログラムモジュールをいう。なお、他の実施の形態において、他モジュールの存在は、便宜上省略されていただけであり、他モジュールに関しても、ＳＤＫプラットフォーム１５３と同様に、省電力状態の遷移に関する各種の通知は行われる。
【００５７】
図７では、ステップＳ１０８が、ステップＳ１０８ａに置き換わっている。ステップＳ１０８ａにおいて、ＳＤＫプラットフォーム１５３は、起動中の各ＳＤＫアプリ１５２に関して終了処理を開始する。この際、ＳＤＫプラットフォーム１５３は、省電力対応のＳＤＫアプリ１５２に関しては、終了ではなく、中断状態への移行指示を入力する。
【００５８】
省電力対応のＳＤＫアプリ１５２とは、エンジンオフ状態ＳＴ３においても終了が回避されるように実装されているＳＤＫアプリ１５２をいう。例えば、ＦＡＸの受信機能を有するＳＤＫアプリ１５２のように、エンジンオフ状態ＳＴ３において起動状態が維持される必要の有るＳＤＫアプリ１５２は、省電力対応のＳＤＫアプリ１５２として実装される。いずれのＳＤＫアプリ１５２が省電力対応であるか否かは、例えば、ＳＤＫアプリ１５２のインストール時において、ＳＤＫプラットフォーム１５３に対して設定される。
【００５９】
また、中断状態とは、省電力対応のＳＤＫアプリ１５２が有する状態であり、現在実行中の処理を区切りの良い箇所で中断させ、それ以降の処理を進行させない状態をいう。したがって、中断状態のＳＤＫアプリ１２のスレッドは終了しない。
【００６０】
また、図７では、ステップＳ１１０ａが、ステップＳ１１０ｂに置き換わっている。すなわち、図７では、エンジンオフ状態ＳＴ３への移行の可否の問い合わせ時（Ｓ１０９）において、全てのＳＤＫアプリ１５２に関して、終了処理又は中断状態への移行が完了していることとする。したがって、ステップＳ１１０ｂにおいて、ＳＤＫプラットフォーム１５３は、エンジンオフ状態ＳＴ３への移行は可能であることを示す応答を返信する。
【００６１】
続いて、移行可否確認部１６３は、他モジュールに対しても、エンジンオフ状態ＳＴ３への移行の可否を問い合わせる（Ｓ１０９−２）。ここでは、少なくとも一部の他モジュールが、エンジンオフ状態ＳＴ３へ移行できない状態であるとする。例えば、印刷アプリ１５１２が、印刷を実行中であったり、ＦＡＸアプリ１５１４が、ＦＡＸの送信又はＦＡＸの受信を実行中であったりする。そこで、当該一部の他モジュールは、移行は不可能であること（移行を拒否すること）を示す応答を返信する（Ｓ１１０−２）。
【００６２】
すなわち、第四の実施の形態では、ＳＤＫプラットフォーム１５３以外の他モジュールによって、エンジンオフ状態ＳＴ３への移行が拒否される点が、第二の実施の形態と異なる点の一つである。
【００６３】
いずれかの他モジュールから、移行は不可能であることを示す応答が返信されると、移行制御部１６１は、エンジンオフ状態ＳＴ３への移行のキャンセル（中止）を、ＳＤＫプラットフォーム１５３と、各他モジュールとに通知する（Ｓ１１１−１、Ｓ１１１−２）。
【００６４】
続いて、移行制御部１６１は、静音状態ＳＴ２への移行確定をＳＤＫプラットフォーム１５３に通知する（Ｓ１１２−１）。静音状態ＳＴ２への移行確定の通知に応じ、ＳＤＫプラットフォーム１５３は、ステップＳ１０８ａにおいて中断状態へ移行させた、省電力対応の各ＳＤＫアプリ１５２に関して、中断状態を解除する（Ｓ１１２−１１）。その結果、省電力対応の各ＳＤＫアプリ１５２は、通常の動作状態に復帰する。続いて、ＳＤＫプラットフォーム１５３は、静音状態ＳＴ２への移行確定の通知に対する応答を返信する（Ｓ１１３−１）。
【００６５】
移行制御部１６１は、また、静音状態ＳＴ２への移行確定を各他モジュールにも通知する（Ｓ１１２−２）。当該通知を受けた各他モジュールは、当該通知に対する応答を返信する（Ｓ１１３−２）。
【００６６】
その後、静音状態ＳＴ２への移行確定の通知（Ｓ１１２）、又は当該通知に対する応答（Ｓ１１３）から所定時間が経過すると、事前通知部１６２は、エンジンオフ状態ＳＴ３への移行の事前通知をＳＤＫプラットフォーム１５３に再送信する（Ｓ１１４）。
【００６７】
当該事前通知に応じ、ＳＤＫプラットフォーム１５３は、省電力対応の各ＳＤＫアプリ１５２に対して、中断状態への移行指示を入力する（Ｓ１１５ａ）。ここで、省電力対応でないＳＤＫアプリ１５２に関して、終了処理は実行されない。省電力対応でないＳＤＫアプリ１５２は、ステップＳ１０８ａにおいて、既に終了しているからである。
【００６８】
ステップＳ１１４の事前通知から所定時間が経過すると、移行可否確認部１６３は、ＳＤＫプラットフォーム１５３に対してエンジンオフ状態ＳＴ３への移行の可否を問い合わせる（Ｓ１１６−１）。当該問い合わせ時において、省エネ対応の全てのＳＤＫアプリ１５２に関して中断状態への移行が完了していれば、ＳＤＫプラットフォーム１５３は、エンジンオフ状態ＳＴ３への移行は可能であることを示す応答を返信する（Ｓ１１７−１）。
【００６９】
続いて、移行可否確認部１６３は、各他モジュールに対してエンジンオフ状態ＳＴ３への移行の可否を問い合わせる（Ｓ１１６−２）。各他モジュールは、エンジンオフ状態ＳＴ３への移行が可能であれば、エンジンオフ状態ＳＴ３への移行は可能であることを示す応答を返信する（Ｓ１１７−２）。
【００７０】
なお、ステップＳ１１６−１とステップＳ１１６−２との順番は、逆であってもよいし、並列的に実行されてもよい。
【００７１】
上述したように、第四の実施の形態においても、第二の実施の形態と同様の効果を得ることができる。
【００７２】
次に、第五の実施の形態について説明する。第五の実施の形態では、第三の実施の形態と異なる点について説明する。したがって、特に言及されない点については、第三の実施の形態と同様でよい。
【００７３】
図８は、第五の実施の形態の処理手順を説明するためのシーケンス図である。図８中、図６又は図７と同一ステップには、同一符号を付し、その説明は適宜省略する。
【００７４】
第五の実施の形態では、エンジンオフ状態ＳＴ３への事前通知（Ｓ１０７）から所定時間が経過する前に、画像形成装置１０がオフライン状態へ移行した場合について説明する。
【００７５】
オフライン状態とは、例えば、操作パネル１５に表示される管理者用の設定画面を介して、画像形成装置１０の動作に関するパラメータの値の設定変更等が行われる状態をいう。例えば、管理者用の設定画面の表示指示に応じて、画像形成装置１０はオフライン状態へ移行する。なお、オフライン状態は、図３において説明した、省電力状態に関する状態遷移とは別の観点における状態遷移に関する状態である。
【００７６】
オフライン状態では、上記のようなパラメータの値の設定変更が行われるため、オフライン状態中に、エンジンオフ状態ＳＴ３への移行が行われてしまうのは好ましくない。パラメータの値の設定変更は、ＨＤＤ１１４又はＮＶＲＡＭ１１５等への書き込み処理が発生するところ、エンジンオフ状態ＳＴ３においては、ＨＤＤ１１４又はＮＶＲＡＭ１１５等への電力の供給が停止され、当該書き込み処理を行えなくなってしまうからである。
【００７７】
そこで、画像形成装置１０がオフライン状態へ移行すると、移行制御部１６１は、エンジンオフ状態ＳＴ３への事前通知からの所定時間の経過を計測するためのタイマの進行を停止させる。続いて、移行制御部１６１は、静音状態ＳＴ２への移行確定をＳＤＫプラットフォーム１５３に通知する（Ｓ１２１ａ）。ここで、静音状態ＳＴ２への移行確定が通知されるのは、エンジンオフ状態ＳＴ３への移行は中止となったことをＳＤＫプラットフォーム１５３に通知し、ＳＤＫプラットフォーム１５３及びＳＤＫアプリ１５２の動作状態を、画像形成装置１０の省電力状態に則したものに変更させるためである。
【００７８】
すなわち、ＳＤＫプラットフォーム１５３及びＳＤＫアプリ１５２は、エンジンオフ状態ＳＴ３への移行の事前通知を受けて、エンジンオフ状態ＳＴ３に対応した動作状態へ移行している。仮に、静音状態ＳＴ２への移行確定が通知されなければ、ＳＤＫプラットフォーム１５３及びＳＤＫアプリ１５２は、画像形成装置１０は静音状態ＳＴ２であるにも拘わらず、エンジンオフ状態ＳＴ３に対応した動作状態を維持し、その機能を発揮することができないからである。
【００７９】
静音状態ＳＴ２への移行確定の通知に応じ、ＳＤＫプラットフォーム１５３は、ステップＳ１０８ａにおいて中断状態へ移行させた、省電力対応の各ＳＤＫアプリ１５２に関して、中断状態を解除する（Ｓ１２２ａ）。ＳＤＫプラットフォーム１５３は、中断状態の解除が完了すると、応答を返信する（Ｓ１２３）。
【００８０】
このように、事前通知後であって、静音状態ＳＴ２の移行からエンジンオフ状態充足時間が経過する前に、オフライン状態へ移行した場合であっても、前倒し的に中断状態とされた省電力対応のＳＤＫアプリ１５２の中断状態は、自動的に解除される。したがって、ユーザが不便を感じる可能性を低下させることができる。
【００８１】
なお、上記各実施の形態は、省電力状態を有する機器であれば、例えば、プロジェクタ、スマートフォン、携帯電話、又はデジタルカメラ等、画像形成装置１０以外の機器に適用可能である。
【００８２】
以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【符号の説明】
【００８３】
１０ 画像形成装置
１１ コントローラ
１２ スキャナ
１３ プリンタ
１４ モデム
１５ 操作パネル
１６ ネットワークインタフェース
１７ ＳＤカードスロット
８０ ＳＤカード
１１１ ＣＰＵ
１１２ ＲＡＭ
１１３ ＲＯＭ
１１４ ＨＤＤ
１１５ ＮＶＲＡＭ
１５１ 標準アプリ
１５２ ＳＤＫアプリ
１５３ ＳＤＫプラットフォーム
１５４ コントロールサービス
１５５ ＯＳ
１６１ 移行制御部
１６２ 事前通知部
１６３ 移行可否確認部
１５１１ スキャンアプリ
１５１２ 印刷アプリ
１５１３ コピーアプリ
１５１４ ＦＡＸアプリ
【先行技術文献】
【特許文献】
【００８４】
【特許文献１】特開２００７−１５２８２４号公報
【特許請求の範囲】
【請求項１】
プログラムをインストール可能な機器であって、
省電力状態への移行開始時期より前に、前記プログラムに対する省電力状態への移行通知を行う事前通知手段と、
前記移行開始時期に、前記プログラムに関して省電力状態への移行の可否を問い合わせる確認手段とを有し
前記確認手段によって問い合わせが行われた前記プログラムに関して省電力状態への移行が可能である場合に、省電力状態へ移行する機器。
【請求項２】
前記機器は、相互に省電力の程度の異なる第一の省電力状態と第二の省電力状態とを含む複数の省電力状態を有し、
前記事前通知手段は、前記第一の省電力状態への移行時から第一の所定時間経過後に、前記プログラムに対して省電力状態への移行を通知し、
前記確認手段は、前記第一の省電力状態への移行時から第二の所定時間経過後に前記プログラムに関して省電力状態への移行の可否を問い合わせる請求項１記載の機器。
【請求項３】
前記移行通知に応じ、前記プログラムの終了させる終了化手段を有する請求項１又は２記載の機器。
【請求項４】
プログラムをインストール可能な機器が、
省電力状態への移行開始時期より前に、前記プログラムに対する省電力状態への移行通知を行う事前通知手順と、
前記移行開始時期に、前記プログラムに関して省電力状態への移行の可否を問い合わせる確認手順とを実行し
前記確認手順において問い合わせが行われた前記プログラムに関して省電力状態への移行が可能である場合に、省電力状態へ移行する省電力制御方法。
【請求項５】
前記機器は、相互に省電力の程度の異なる第一の省電力状態と第二の省電力状態とを含む複数の省電力状態を有し、
前記事前通知手順は、前記第一の省電力状態への移行時から第一の所定時間経過後に、前記プログラムに対して省電力状態への移行を通知し、
前記確認手順は、前記第一の省電力状態への移行時から第二の所定時間経過後に前記プログラムに関して省電力状態への移行の可否を問い合わせる請求項４記載の省電力制御方法。
【請求項６】
前記移行通知に応じ、前記プログラムの終了させる終了化手順を前記機器が実行する請求項４又は５記載の省電力制御方法。
【請求項７】
プログラムをインストール可能な機器に、
省電力状態への移行開始時期より前に、前記プログラムに対する省電力状態への移行通知を行う事前通知手順と、
前記移行開始時期に、前記プログラムに関して省電力状態への移行の可否を問い合わせる確認手順とを実行させ
前記確認手順において問い合わせが行われた前記プログラムに関して省電力状態への移行が可能である場合に、省電力状態へ移行する省電力制御プログラム。
【請求項８】
前記機器は、相互に省電力の程度の異なる第一の省電力状態と第二の省電力状態とを含む複数の省電力状態を有し、
前記事前通知手順は、前記第一の省電力状態への移行時から第一の所定時間経過後に、前記プログラムに対して省電力状態への移行を通知し、
前記確認手順は、前記第一の省電力状態への移行時から第二の所定時間経過後に前記プログラムに関して省電力状態への移行の可否を問い合わせる請求項７記載の省電力制御プログラム。
【請求項９】
前記移行通知に応じ、前記プログラムの終了させる終了化手順を前記機器に実行させる請求項７又は８記載の省電力制御プログラム。
【請求項１０】
請求項７乃至９いずれか一項記載の省電力制御プログラムを記録したコンピュータ読み取り可能な記録媒体。
【請求項１】
プログラムをインストール可能な機器であって、
省電力状態への移行開始時期より前に、前記プログラムに対する省電力状態への移行通知を行う事前通知手段と、
前記移行開始時期に、前記プログラムに関して省電力状態への移行の可否を問い合わせる確認手段とを有し
前記確認手段によって問い合わせが行われた前記プログラムに関して省電力状態への移行が可能である場合に、省電力状態へ移行する機器。
【請求項２】
前記機器は、相互に省電力の程度の異なる第一の省電力状態と第二の省電力状態とを含む複数の省電力状態を有し、
前記事前通知手段は、前記第一の省電力状態への移行時から第一の所定時間経過後に、前記プログラムに対して省電力状態への移行を通知し、
前記確認手段は、前記第一の省電力状態への移行時から第二の所定時間経過後に前記プログラムに関して省電力状態への移行の可否を問い合わせる請求項１記載の機器。
【請求項３】
前記移行通知に応じ、前記プログラムの終了させる終了化手段を有する請求項１又は２記載の機器。
【請求項４】
プログラムをインストール可能な機器が、
省電力状態への移行開始時期より前に、前記プログラムに対する省電力状態への移行通知を行う事前通知手順と、
前記移行開始時期に、前記プログラムに関して省電力状態への移行の可否を問い合わせる確認手順とを実行し
前記確認手順において問い合わせが行われた前記プログラムに関して省電力状態への移行が可能である場合に、省電力状態へ移行する省電力制御方法。
【請求項５】
前記機器は、相互に省電力の程度の異なる第一の省電力状態と第二の省電力状態とを含む複数の省電力状態を有し、
前記事前通知手順は、前記第一の省電力状態への移行時から第一の所定時間経過後に、前記プログラムに対して省電力状態への移行を通知し、
前記確認手順は、前記第一の省電力状態への移行時から第二の所定時間経過後に前記プログラムに関して省電力状態への移行の可否を問い合わせる請求項４記載の省電力制御方法。
【請求項６】
前記移行通知に応じ、前記プログラムの終了させる終了化手順を前記機器が実行する請求項４又は５記載の省電力制御方法。
【請求項７】
プログラムをインストール可能な機器に、
省電力状態への移行開始時期より前に、前記プログラムに対する省電力状態への移行通知を行う事前通知手順と、
前記移行開始時期に、前記プログラムに関して省電力状態への移行の可否を問い合わせる確認手順とを実行させ
前記確認手順において問い合わせが行われた前記プログラムに関して省電力状態への移行が可能である場合に、省電力状態へ移行する省電力制御プログラム。
【請求項８】
前記機器は、相互に省電力の程度の異なる第一の省電力状態と第二の省電力状態とを含む複数の省電力状態を有し、
前記事前通知手順は、前記第一の省電力状態への移行時から第一の所定時間経過後に、前記プログラムに対して省電力状態への移行を通知し、
前記確認手順は、前記第一の省電力状態への移行時から第二の所定時間経過後に前記プログラムに関して省電力状態への移行の可否を問い合わせる請求項７記載の省電力制御プログラム。
【請求項９】
前記移行通知に応じ、前記プログラムの終了させる終了化手順を前記機器に実行させる請求項７又は８記載の省電力制御プログラム。
【請求項１０】
請求項７乃至９いずれか一項記載の省電力制御プログラムを記録したコンピュータ読み取り可能な記録媒体。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【公開番号】特開２０１２−１９０４３８（Ｐ２０１２−１９０４３８Ａ）
【公開日】平成２４年１０月４日（２０１２．１０．４）
【国際特許分類】
【出願番号】特願２０１１−２７９５０７（Ｐ２０１１−２７９５０７）
【出願日】平成２３年１２月２１日（２０１１．１２．２１）
【出願人】（０００００６７４７）株式会社リコー (37,907)
【Ｆターム（参考）】
【公開日】平成２４年１０月４日（２０１２．１０．４）
【国際特許分類】
【出願日】平成２３年１２月２１日（２０１１．１２．２１）
【出願人】（０００００６７４７）株式会社リコー (37,907)
【Ｆターム（参考）】
[ Back to top ]