画像処理装置
【課題】省エネ中に電源をＯＦＦしたデバイスを省エネ復帰後に問題なく使用することができるようにした画像処理装置を提供する。
【解決手段】各デバイスドライバの初期化時に、省エネ制御のモード毎に各デバイスドライバに設けられたコールバック関数を呼び出すパワーフック関数をパワーフックキューに登録する手段と、省エネ移行時に上記パワーフックキューに登録されたパワーフック関数を呼び出す手段と、省エネ復帰時に上記パワーフックキューに登録されたパワーフック関数を呼び出す手段とを備える。
【解決手段】各デバイスドライバの初期化時に、省エネ制御のモード毎に各デバイスドライバに設けられたコールバック関数を呼び出すパワーフック関数をパワーフックキューに登録する手段と、省エネ移行時に上記パワーフックキューに登録されたパワーフック関数を呼び出す手段と、省エネ復帰時に上記パワーフックキューに登録されたパワーフック関数を呼び出す手段とを備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、省エネ中に電源をＯＦＦしたデバイスを省エネ復帰後に問題なく使用することができるようにした画像処理装置に関する。
【背景技術】
【０００２】
ＭＦＰ（Multi Function Printer）等の画像処理装置では、省エネ（スリープ）時にはシステム情報をメモリに保持し（ＳＴＲ：Suspend to RAM）、省エネ復帰時にはメモリに保持されているシステム情報を呼び出して素早く復帰（Resume）する仕組みが取り入れられているものがある。
【０００３】
ところで、画像処理装置には、ＨＤＤ（Hard Disk Drive）、ビデオ（回路）、圧縮伸張器、回転器、合成器、ＭＡＣ（Media Access Control）、ＵＳＢ（Universal Serial Bus）、操作部、ＳＤ（Secure Digital）カード、パワーマネジメント（回路）、WatchDog等の各種のデバイスが装備されているが、省エネ時にはこれらのデバイスの電源がＯＦＦとされるため、そのまま省エネから復帰した場合には状態の不整合を起こし、正常に動作することができなくなる。
【０００４】
なお、出願人は出願時点までに本発明に関連する公開された先行技術文献を発見することができなかった。よって、先行技術文献情報を開示していない。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
本発明は上記の従来の問題点に鑑み提案されたものであり、その目的とするところは、省エネ中に電源をＯＦＦしたデバイスを省エネ復帰後に問題なく使用することができるようにした画像処理装置を提供することにある。
【課題を解決するための手段】
【０００６】
上記の課題を解決するため、本発明にあっては、
請求項１に記載されるように、各デバイスドライバの初期化時に、省エネ制御のモード毎に各デバイスドライバに設けられたコールバック関数を呼び出すパワーフック関数をパワーフックキューに登録する手段と、省エネ移行時に上記パワーフックキューに登録されたパワーフック関数を呼び出す手段と、省エネ復帰時に上記パワーフックキューに登録されたパワーフック関数を呼び出す手段とを備える画像処理装置を要旨としている。
【０００７】
また、請求項２に記載されるように、請求項１に記載の画像処理装置において、上記省エネ制御のモードは、省エネ移行の第１段階であるソフトサスペンド、省エネ移行の第２段階であるサスペンド、省エネ復帰の第１段階であるリジュウム、および、省エネ復帰の第２段階であるソフトリジュウムの４種類であるものとすることができる。
【０００８】
また、請求項３に記載されるように、請求項１または２のいずれか一項に記載の画像処理装置において、省エネ移行時および省エネ復帰時に各デバイスドライバへの他からの割り込みを禁止する期間を設けるようにすることができる。
【０００９】
また、請求項４に記載されるように、請求項１ないし３のいずれか一項に記載の画像処理装置において、上記パワーフックキューは優先度レベル毎に区分され、省エネ移行時および省エネ復帰時に優先度レベルの高い順に上記パワーフックキューに登録されたパワーフック関数を呼び出すようにすることができる。
【００１０】
また、請求項５に記載されるように、請求項１ないし４のいずれか一項に記載の画像処理装置において、上記各デバイスドライバの初期化時における上記パワーフックキューのパワーフック関数の登録は上記デバイスドライバの初期化の順に行い、省エネ移行時における上記パワーフックキューのパワーフック関数の呼び出しは登録順もしくは登録と逆順に行い、省エネ復帰時における上記パワーフックキューのパワーフック関数の呼び出しは登録と逆順もしくは登録順に行うようにすることができる。
【００１１】
また、請求項６〜１０に記載されるように、画像処理装置の省エネ制御方法として構成することができる。
【００１２】
また、請求項１１〜１５に記載されるように、画像処理装置の省エネ制御プログラムとして構成することができる。
【発明の効果】
【００１３】
本発明の画像処理装置にあっては、各デバイスドライバの初期化時に省エネ制御のモード毎に各デバイスドライバに設けられたコールバック関数を呼び出すパワーフック関数をパワーフックキューに登録し、省エネ移行時および省エネ復帰時にパワーフックキューに登録されたパワーフック関数を呼び出して不整合をなくす処理を適宜に行わせることができるため、省エネ中に電源をＯＦＦしたデバイスを省エネ復帰後に問題なく使用することができる。
【発明を実施するための最良の形態】
【００１４】
以下、本発明の好適な実施形態につき説明する。
【００１５】
図１は本発明の一実施形態にかかる画像処理装置１の構成例を示す図である。
【００１６】
図１において、画像処理装置１は、システム制御を行うＳＣＳ（System Control Service）２と、ＯＳ（Operating System）３内に設けられる、省エネ制御を行うＳＴＲドライバ４と、ＨＤＤ、ビデオ（回路）、圧縮伸張器、回転器、合成器、ＭＡＣ、ＵＳＢ、操作部、ＳＤカード、パワーマネジメント（回路）、WatchDog等の各種デバイスのデバイスドライバ５と、省エネ移行・復帰における各デバイスドライバ５の整合性確保のための処理を行うパワーフックシステム６とを備えている。また、パワーフックシステム６は主たる処理を行うパワーフック処理部７と、パワーフック関数を管理するパワーフックキュー８とを備えている。なお、画像処理装置１におけるその他の部分（エンジン、アプリケーション等）は図示を省略している。
【００１７】
図２は画像処理装置１のソフトウェア構成を示す図である。
【００１８】
図２において、この画像処理装置１は、白黒ラインプリンタ（B&W LP）３０１、カラーラインプリンタ（Color LP）３０２、その他ハードウェアリソース３０３などを有するとともに、ソフトウェア群３１０は、プラットホーム３２０およびアプリケーション３４０からなる。
【００１９】
プラットホーム３２０は、汎用ＯＳ３２１と、共通システムサービス３３０と、アプリサービス３２９とで形成される。なお、このプラットホーム３２０は、あらかじめ定義された関数によりアプリケーション３４０からの処理要求を受信可能とするアプリケーションプログラムインターフェースを有する。
【００２０】
汎用ＯＳ３２１は、ＵＮＩＸ（登録商標）などの汎用オペレーティングシステムであり、プラットホーム３２０並びにアプリケーション３４０の各ソフトウェアをそれぞれプロセスとして並列実行する。オープンソースのＵＮＩＸ（登録商標）を用いることにより、プログラムの安全性を確保できるとともに、ネットワーク対応可能となり、ソースコードの入手も容易となる。さらに、ＯＳ、ＴＣＰ／ＩＰのロイヤリティが不要であり、アウトソーシングも容易となる。
【００２１】
共通システムサービス３３０は、アプリケーション３４０に対して基本的な共通サービスを提供するものであり、アプリケーション３３０からの処理要求を解釈して、ハードウェア資源の獲得要求を発生させる下記に示すコントロールサービスと、一または複数のハードウェア資源の管理をおこない、コントロールサービスからの獲得要求を調停するシステムリソースマネージャー（ＳＲＭ（SystemResource Manager）３２３）とを有する。
【００２２】
このコントロールサービスは、複数のサービスモジュールにより形成され、具体的には、ＳＣＳ（System Control Service）３２２と、ＥＣＳ（Engine Control Service）３２４と、ＭＣＳ（Memory Control Service）３２５と、ＯＣＳ（Operation panel Control Service）３２６と、ＦＣＳ（FAX Control Service）３２７と、ＮＣＳ（Network Control Service）３２８とがある。
【００２３】
ＳＲＭ３２３は、ＳＣＳ３２２とともにシステムの制御およびリソースの管理をおこなうものであり、スキャナ部やプリンタ部などのエンジン、メモリ、ＨＤＤファイル、ホストＩ／Ｏ（セントロＩ／Ｆ、ネットワークＩ／Ｆ、ＩＥＥＥ１３９４Ｉ／Ｆ、ＲＳ２３２ＣＩ／Ｆなど）のハードウェア資源を利用する上位層からの要求にしたがって調停をおこない、実行制御する。
【００２４】
具体的には、このＳＲＭ３２３は、要求されたハードウェア資源が利用可能であるかどうか（他の要求により利用されていないかどうか）を判断し、利用可能であれば要求されたハードウェア資源が利用可能である旨を上位層に伝える。また、上位層からの要求に対してハードウェア資源の利用スケジューリングをおこない、要求内容（たとえば、プリンタエンジンによる紙搬送と作像動作、メモリ確保、ファイル生成など）を直接実施するようにしてもよい。
【００２５】
ＳＣＳ３２２は、（１）アプリ管理、（２）操作部制御、（３）システム画面表示（ジョブリスト画面、カウンタ表示画面など）、（４）ＬＥＤ表示、（５）リソース管理、（６）割り込みアプリ制御をおこなう。具体的には、（１）アプリ管理では、アプリの登録と、その情報を他のアプリに通知する処理をおこなう。登録されたアプリに対しては、システムの設定やアプリからの要求設定に応じてエンジン状態を通知する。また、登録済みのアプリに対しては、電力モード移行の問い合わせ、割り込みモードなど、システムの状態遷移のための可否問い合わせをおこなう。
【００２６】
また、（２）操作部制御では、アプリの操作部使用権の排他制御をおこなう。そして、操作部の使用権を持つアプリへ操作部ドライバ（ＯＣＳ）からのキー情報を排他的に通知する。このキー情報は、アプリ切替中などのシステムの状態遷移に応じて一時的に通知を停止するマスク制御をおこなう。
【００２７】
また、（３）システム画面表示では、操作部使用権を持つアプリからの要求内容に応じて、エンジン状態に対応する警告画面の表示をおこなう。これらのなかには、利用者制限画面などアプリの状態に応じて警告表示をオン／オフするものもある。エンジン状態以外では、ジョブの予約・実行状況を表示するためのジョブリスト画面、トータルカウンタ類を表示するためのカウンタ画面、ＣＳＳの通報中を示す画面の表示制御をおこなう。これらのシステム画面表示に関しては、アプリへ操作部使用権の解放を要求せず、アプリ画面を覆うシステム画面として描画をおこなう。
【００２８】
また、（４）ＬＥＤ表示では、警告ＬＥＤ、アプリキーなどのシステムＬＥＤの表示制御をおこなう。アプリ固有のＬＥＤについては、アプリが直接表示用ドライバを使用して制御する。
【００２９】
また、（５）リソース管理では、アプリ（ＥＣＳ）がジョブを実行するにあたって、排他しなければならないエンジンリソース（スキャナ、ステープルなど）の排他制御のためのサービスをおこない、（６）割り込みアプリ制御では、特定のアプリを優先動作せさるための制御・サービスをおこなう。
【００３０】
ＥＣＳ３２４は、白黒ラインプリンタ（B&W LP）３０１、カラーラインプリンタ（Color LP）３０２、その他ハードウェアリソース３０３などのエンジンを制御するものであり、画像読み込みと印刷動作、状態通知、ジャムリカバリなどをおこなう。
【００３１】
具体的には、アプリケーション３４０から受け取ったジョブモードの指定にしたがい、印刷要求をＳＲＭ３２３に順次発行していくことで、一連のコピー／スキャン／印刷動作を実現する。このＥＣＳ３２４が取り扱う対象のジョブは、画像入力デバイスにスキャナ（SCANNER）が指定されているか、または、画像出力デバイスにプロッタ（PLOTTER）が指定されているものとする。
【００３２】
たとえば、コピー動作の場合には「SCANNER → PLOTTER」と指定され、ファイル蓄積の場合には「SCANNER → MEMORY」と指定され、ファクシミリ送信の場合には「SCANNER → FAX＿IN」と指定される。また、蓄積ファイル印刷またはプリンタアプリ３１１からの印刷の場合には「MEMORY → PLOTTER」と指定され、ファクシミリ受信の場合には「FAX＿OUT → PLOTTER」と指定される。
【００３３】
なお、ジョブの定義はアプリケーションによって異なるが、ここでは利用者が取り扱う１セットの画像群に対する処理動作を１ジョブと定義する。たとえば、コピーのＡＤＦ（Automatic Document Feeder）モードの場合は、原稿台に置かれた１セットの原稿を読み取る動作が１ジョブとなり、圧板モードは最終原稿が確定するまでの読み取り動作が１ジョブとなる。また、コピーアプリ３１２の場合には、一束の原稿をコピーする動作が１ジョブとなり、ファックスアプリ３１３の場合には、１文書の送信動作または１文書の受信動作が１ジョブとなり、プリンタアプリの場合には、１文書の印刷動作が１ジョブとなる。
【００３４】
ＭＣＳ３２５は、メモリ制御をおこなうものであり、具体的には、画像メモリの取得および開放、ハードディスク装置（ＨＤＤ）の利用、画像データの圧縮および伸張などをおこなう。
【００３５】
ここで、ハードディスク装置に蓄積される画像データファイルとして必要な情報を管理するために必要な機能としては、（１）ファイルアクセス（生成／削除／オープン／クローズ）機能（排他処理を含む）、（２）ファイル名称／ＩＤ管理（ファイル／ユーザ）／パスワード管理／蓄積時刻管理／ページ数／データフォーマット（圧縮方式など）／アクセス制限／作成アプリ／印刷条件管理などの各種ファイル属性管理（物理的なページ単位の画像データのファイルとしての管理）、（３）ファイル単位およびページ単位での結合／挿入／切断機能、（４）ファイルソート機能（蓄積時刻順／ユーザＩＤ順など）、（５）全ファイル情報の通知（表示／検索用）、（６）リカバリ機能（破損ファイルのファイル／ページ破棄）、（７）ファイルの自動削除機能などがある。
【００３６】
また、ＲＡＭなどのメモリへ画像データを保持しアクセスするための機能としては、（１）アプリケーション３４０からのファイルおよびページ／バンド属性情報を取得する機能、（２）アプリケーション３４０からの画像データ領域の確保、解放、リード（Read）、ライト（Write）機能などがある。
【００３７】
ＯＣＳ３２６は、オペレータと本体制御間の情報伝達手段となる操作パネルを制御するモジュールであり、オペレータのキー操作イベントを本体制御に通知する処理、各アプリがＧＵＩを構築するためのライブラリ関数を提供する処理、構築されたＧＵＩ情報をアプリ別に管理する処理、操作パネル上への表示反映処理などをおこなう。
【００３８】
このＯＣＳ３２６は、（１）ＧＵＩ構築のためのライブラリの提供機能、（２）操作部ハードウェア資源管理機能、（３）ＶＲＡＭ描画／ＬＣＤ表示機能（ハードウェア表示、表示アプリ切替、表示言語切替、ウインドウ暗色表示、メッセージ／アイコンブリンク表示、メッセージの連結表示）、（４）ハードキー入力検出機能、（５）タッチパネルキー入力検出機能、（６）ＬＥＤ出力機能、（７）ブザー出力機能などを有する。
【００３９】
ＦＣＳ３２７は、システムコントローラの各アプリ層からＰＳＴＮ／ＩＳＤＮ網を使ったファクシミリ送受信、ＢＫＭ（バックアップＳＲＡＭ）で管理されている各種ファクシミリデータの登録／引用、ファクシミリ読み取り、ファクシミリ受信印刷、融合送受信をおこなうためのＡＰＩを提供するものである。
【００４０】
具体的には、このＦＣＳ３２７は、（１）アプリ層から送信依頼されたドキュメントをＰＳＴＮ／ＩＳＤＮ網を使ってファクシミリ受信機に送信をおこなう送信機能、（２）ＰＳＴＮ／ＩＳＤＮ網から受信したファクシミリ受信画面、各種レポート類を各アプリ層に転送、印刷をおこなう受信機能、（３）ファックスボードに記憶されている電話帳、グループ情報などのファクシミリ管理項目の引用や登録をおこなう電話帳引用・登録機能、（４）ファックスボードに搭載されているＢＫＭに記憶されている送受信結果履歴情報などを必要としているアプリに通知するファックスログ通知機能、（５）ファックスボードの状態変化があったときにＦＣＳに登録してあるアプリに変化のあったイベントを通知するイベント通知機能などを有する。
【００４１】
ＮＣＳ３２８は、ネットワークＩ／Ｏを必要とするアプリケーションに対して共通に利用できるサービスを提供するためのモジュール群であり、ネットワーク側から各プロトコルによって受信したデータを各アプリケーションに振り分けたり、アプリケーションからデータをネットワーク側に送信する際の仲介をおこなう。具体的には、ftpd、httpd、lpd、snmpd、telnetd、smtpdなどのサーバデーモンや、同プロトコルのクライアント機能などを有する。
【００４２】
アプリサービス３２９は、プラットホーム３２０を形成する共通サービスの一つであるが、上記共通システムサービス３３０を形成するＥＣＳ３２４、ＭＣＳ３２５、ＯＣＳ３２６、ＦＣＳ３２７、ＮＣＳ３２８、ＳＲＭ３２３およびＳＣＳ３２２とは異なり、アプリケーション３４０側に立ったサービスを提供するものである。
【００４３】
言い換えると、このアプリサービス３２９は、アプリケーション３４０と共通システムサービス３３０との間に介在し、両者の間の橋渡しを担う役割を果たしている。
【００４４】
具体的には、このアプリサービス３２９は、コピーアプリ３１２、ファックスアプリ３１３、スキャナアプリ３１４などが、本来おこなうべきジョブの生成やデータ通信の機能を一括して代行する。このため、コピーアプリ３１２、ファックスアプリ３１３、スキャナアプリ３１４などは、画面やキー操作を対象とすれば足りるので、アプリの開発効率が向上する。
【００４５】
アプリケーション３４０は、ページ記述言語（ＰＤＬ）、ＰＣＬおよびポストスクリプト（ＰＳ）を有するプリンタ用のアプリケーションであるプリンタアプリ３１１と、コピー用アプリケーションであるコピーアプリ３１２と、ファクシミリ用アプリケーションであるファックスアプリ３１３と、スキャナ用アプリケーションであるスキャナアプリ３１４と、ネットファイル用アプリケーションであるネットファイルアプリ３１５と、工程検査用アプリケーションである工程検査アプリ３１６とを有する。
【００４６】
各アプリケーション３１１〜３１６は、プラットホーム３２０上の各プロセスを利用して動作実行し得るため、画面制御およびキー操作制御などをおこなう画面表示制御プログラムがその主体となる。特に、アプリサービス３２９がプラットホーム３２０上に設けられているので、ジョブの生成やデータ通信の機能を設ける必要がない。なお、ＮＣＳ３２８により接続されたネットワークを介して新たなアプリケーションをネットワーク経由で搭載することもできる。また、各アプリケーションはアプリケーションごとに追加または削除することができる。
【００４７】
図３は画像処理装置１のハードウェア構成を示す図である。
【００４８】
図３において、画像処理装置１は、ＣＰＵ９０２、ＳＤＲＡＭ９０３、フラッシュメモリ９０４およびＨＤ９０５などをＡＳＩＣ９０１に接続したコントローラボード９００と、オペレーションパネル９１０と、ファックスコントロールユニット（ＦＣＵ）９２０と、ＵＳＢ９３０と、ＩＥＥＥ1394９４０と、プリンタ９５０とからなる。
【００４９】
そして、オペレーションパネル９１０はＡＳＩＣ９０１に直接接続され、ＦＣＵ９２０、ＵＳＢ９３０、ＩＥＥＥ1394９４０およびプリンタ９５０は、ＰＣＩバスを介してＡＳＩＣ９０１に接続されている。
【００５０】
図４は図３に示したＡＳＩＣ９０１の細部構成を示すブロック図である。
【００５１】
図４において、このＡＳＩＣ９０１は、ＣＰＵインターフェース（CPU I/F）、ＳＤＲＡＭインターフェース（SDRAM I/F）、ローカルバスインターフェース（Local BUS I/F）、ＰＣＩインターフェース（PCI I/F）、１２８４、ＭＡＣ（Media Access Controllor）、Ｉ／Ｏ、ＯＰＥインターフェース（OPE I/F）、ＨＤインターフェース（HD I/F）、Comp／de-comp、Rotateによって形成されている。
【００５２】
かかるハードウェア構成を採用することにより、デバイスの共有化による低コスト設計が可能となるとともに、アプリ間融合が容易となる。また、低速機から高速機までスケーラブルなアーキテクチャーとなり、各アプリで使用するハード／ソフトが共通化され、開発効率を向上させることができる。また、新規機能に対する対応が容易となる。
【００５３】
図５は省エネ移行および省エネ復帰の処理例を示すシーケンス図である。
【００５４】
図５において、各デバイスドライバ５は初期化時（機器起動時もしくはアタッチ時）にパワーフックシステム６のパワーフック処理部７に対してコールバック関数の登録を要求（powerhook_establish()のコール）する（ステップＳ１０１）。パワーフック処理部７はパワーフック関数をパワーフックキュー８に追加し（ステップＳ１０２）、登録が完了した旨がデバイスドライバ５まで返される（ステップＳ１０３、Ｓ１０４）。
【００５５】
図６はデバイスドライバ５の初期化によりパワーフック関数が登録されたパワーフックキュー８の例を示す図であり、ＯＳが初期化した順に、ＨＤＤ→ビデオ→圧縮伸張器→回転器→合成器→ＭＡＣ→ＵＳＢ→操作部→ＳＤカード→パワーマネジメント→WatchDogに対応するパワーフック関数が登録された状態を示している。
【００５６】
図７はパワーフック関数の例を示す図であり、ＳＤカードに対応するパワーフック関数の例を示している。パワーフック関数は、引数で指定されるモード（mode）に応じて所定のコールバック関数を呼び出すようになっており、図示の例では、モードがPWR_SOFTSUSPENDの場合にコールバック関数sdc_suspend(sdc)を呼び出し、モードがPWR_SOFTRESUMEの場合にコールバック関数sdc_resume(sdc)を呼び出すようになっている。
【００５７】
なお、デバイスドライバ５側のコールバック関数は、主に次のような処理を行う。
（１）各デバイスの制御レジスタの保存と復元（もしくは省エネ復帰時に制御レジスタの初期値設定のみ）を行なう。
（２）デバイスそのものに状態遷移がある場合、デバイスの制御（割り込み制御）を行なって使用可能な状態に移行させる。
【００５８】
図５に戻り、機器の待機時間が所定値を越えた等の要因によりＳＴＲイベントが発生すると（ステップＳ１０５）、ＳＣＳ２はＳＴＲドライバ４にＳＴＲ移行要求（sysarch(STR)をコール）する（ステップＳ１０６）。
【００５９】
ＳＴＲドライバ４はパワーフック処理部７に省エネ移行の第１段階であるソフトサスペンドを要求（powerhooks(PWR_SOFTSUSPED)をコール）し（ステップＳ１０７）、パワーフック処理部７はパワーフックキュー８にパワーフック関数の呼び出しを要求する（ステップＳ１０８）。
【００６０】
パワーフックキュー８はパワーフック関数を実行することで、各デバイスドライバ５に対しモードに応じたコールバック関数の呼び出しを行う（ステップＳ１０９）。各デバイスドライバ５ではコールバック関数に応じた処理を行い、処理完了をパワーフックキュー８に伝える（ステップＳ１１０）。
【００６１】
図８は省エネ移行時のソフトサスペンドのモードにおけるパワーフック関数の実行の例を示す図であり、パワーフックキュー８に登録された順に実行するようにしたものである。図８において網掛けを付したものはソフトサスペンドのモードに対応するコールバック関数がないものを示しており、網掛けを付していないデバイスドライバのみがコールバック関数に応じた処理を行う。なお、パワーフックキュー８に登録された順と逆順に実行するようにしてもよい。また、各デバイスドライバ５が完全に独立した動作をする場合には実行順序を考慮しなくてもよい。
【００６２】
図５に戻り、パワーフックキュー８は全てのデバイスドライバ５についての処理を完了すると、その旨をパワーフック処理部７に伝え（ステップＳ１１１）、パワーフック処理部７はその旨をＳＴＲドライバ４に伝える（ステップＳ１１２）。
【００６３】
次いで、ＳＴＲドライバ４は割り込み優先度を上げることで、各デバイスドライバ５への他からの割り込みを禁止する（ステップＳ１１３）。これは、デバイスそのものに状態遷移がある場合、そのようなデバイスに対応するデバイスドライバ５の処理を続く省エネ移行の第２段階であるサスペンドのモードにおいて行わせることとし、その間のコールバック関数によるデバイスの状態制御処理に支障を与えないようにするためである。なお、WatchDogは定期的にリフレッシュされないと呼び出し元に異常が発生したものとしてリブートを行うものであり、割り込み禁止状態になると誤って異常の発生と認識してしまうため、省エネ移行の第１段階であるソフトサスペンドのモードにおいて停止させるものとする。
【００６４】
次いで、ＳＴＲドライバ４はパワーフック処理部７に省エネ移行の第２段階であるサスペンドを要求（powerhooks(PWR_SUSPED)をコール）し（ステップＳ１１４）、パワーフック処理部７はパワーフックキュー８にパワーフック関数の呼び出しを要求する（ステップＳ１１５）。
【００６５】
パワーフックキュー８はパワーフック関数を実行することで、各デバイスドライバ５に対しモードに応じたコールバック関数の呼び出しを行う（ステップＳ１１６）。各デバイスドライバ５ではコールバック関数に応じた処理を行い、処理完了をパワーフックキュー８に伝える（ステップＳ１１７）。
【００６６】
図９は省エネ移行時のサスペンドのモードにおけるパワーフック関数の実行の例を示す図であり、パワーフックキュー８に登録された順に実行される。図９において網掛けを付したものはサスペンドのモードに対応するコールバック関数がないものを示しており、網掛けを付していないデバイスドライバのみがコールバック関数に応じた処理を行う。なお、パワーフックキュー８に登録された順と逆順に実行するようにしてもよい。また、各デバイスドライバ５が完全に独立した動作をする場合には実行順序を考慮しなくてもよい。
【００６７】
図５に戻り、パワーフックキュー８は全てのデバイスドライバ５についての処理を完了すると、その旨をパワーフック処理部７に伝え（ステップＳ１１８）、パワーフック処理部７はその旨をＳＴＲドライバ４に伝える（ステップＳ１１９）。
【００６８】
その後、ＳＴＲドライバ４はＳＴＲを実行し（ステップＳ１２０）、省エネ状態に入る（ステップＳ１２１）。
【００６９】
機器へのジョブの投入等により復帰要因が発生すると（ステップＳ１２２）、ＳＴＲドライバ４はＷａｋｅｕｐを実行する（ステップＳ１２３）。
【００７０】
次いで、ＳＴＲドライバ４はパワーフック処理部７に省エネ復帰の第１段階であるリジュウムを要求（powerhooks(PWR_RESUME)をコール）し（ステップＳ１２４）、パワーフック処理部７はパワーフックキュー８にパワーフック関数の呼び出しを要求する（ステップＳ１２５）。
【００７１】
パワーフックキュー８はパワーフック関数を実行することで、各デバイスドライバ５に対しモードに応じたコールバック関数の呼び出しを行う（ステップＳ１２６）。各デバイスドライバ５ではコールバック関数に応じた処理を行い、処理完了をパワーフックキュー８に伝える（ステップＳ１２７）。
【００７２】
図１０は省エネ移行時のリジュウムのモードにおけるパワーフック関数の実行の例を示す図であり、パワーフックキュー８に登録された順とは逆順に実行される。図１０において網掛けを付したものはリジュウムのモードに対応するコールバック関数がないものを示しており、網掛けを付していないデバイスドライバのみがコールバック関数に応じた処理を行う。なお、パワーフックキュー８に登録された順に実行するようにしてもよい。また、各デバイスドライバ５が完全に独立した動作をする場合には実行順序を考慮しなくてもよい。
【００７３】
図５に戻り、パワーフックキュー８は全てのデバイスドライバ５についての処理を完了すると、その旨をパワーフック処理部７に伝え（ステップＳ１２８）、パワーフック処理部７はその旨をＳＴＲドライバ４に伝える（ステップＳ１２９）。
【００７４】
次いで、ＳＴＲドライバ４は各デバイスドライバ５への他からの割り込み禁止を解除する（ステップＳ１３０）。
【００７５】
次いで、ＳＴＲドライバ４はパワーフック処理部７に省エネ復帰の第２段階であるソフトリジュウムを要求（powerhooks(PWR_SOFTRESUME)をコール）し（ステップＳ１３１）、パワーフック処理部７はパワーフックキュー８にパワーフック関数の呼び出しを要求する（ステップＳ１３２）。
【００７６】
パワーフックキュー８はパワーフック関数を実行することで、各デバイスドライバ５に対しモードに応じたコールバック関数の呼び出しを行う（ステップＳ１３３）。各デバイスドライバ５ではコールバック関数に応じた処理を行い、処理完了をパワーフックキュー８に伝える（ステップＳ１３４）。
【００７７】
図１１は省エネ移行時のソフトリジュウムのモードにおけるパワーフック関数の実行の例を示す図であり、パワーフックキュー８に登録された順とは逆順に実行される。図１１において網掛けを付したものはソフトリジュウムのモードに対応するコールバック関数がないものを示しており、網掛けを付していないデバイスドライバのみがコールバック関数に応じた処理を行う。なお、パワーフックキュー８に登録された順に実行するようにしてもよい。また、各デバイスドライバ５が完全に独立した動作をする場合には実行順序を考慮しなくてもよい。
【００７８】
図５に戻り、パワーフックキュー８は全てのデバイスドライバ５についての処理を完了すると、その旨をパワーフック処理部７に伝え（ステップＳ１３５）、パワーフック処理部７はその旨をＳＴＲドライバ４に伝える（ステップＳ１３６）。
【００７９】
ＳＴＲドライバ４はＳＣＳ２にＳＴＲ完了を伝え（ステップＳ１３７）、処理を終了する。
【００８０】
図１２は優先度レベル毎に区分されたパワーフックキュー８の例を示す図であり、最も優先度レベルの高い「０」から最も低い「３」までの４段階に分けた例を示している。例えば、「０」にはWatchdogタイマが登録され、「１」には主に画像処理装置として外部からの入力を受けるドライバが登録され、「２」にはその他のドライバが登録され、「３」には省エネの移行・復帰を行うドライバが登録される。なお、優先度レベルは各デバイスドライバ５からパワーフックシステム６にパワーフック関数の登録を要求する際に指定することで、対応する優先度レベルに順に登録される。
【００８１】
図１３は優先度レベル順にパワーフック関数を呼び出すプログラムの例を示す図であり、powerhooks(モード)をコールされたパワーフック処理部７の内部において実行されるプログラムの例である。図１３において、（ａ）はソフトサスペンドのモードにおける場合、（ｂ）はサスペンドのモードにおける場合、（ｃ）はリジュウムのモードにおける場合、（ｄ）はソフトリジュウムのモードにおける場合を示している。
【００８２】
以上、本発明の好適な実施の形態により本発明を説明した。ここでは特定の具体例を示して本発明を説明したが、特許請求の範囲に定義された本発明の広範な趣旨および範囲から逸脱することなく、これら具体例に様々な修正および変更を加えることができることは明らかである。すなわち、具体例の詳細および添付の図面により本発明が限定されるものと解釈してはならない。
【図面の簡単な説明】
【００８３】
【図１】本発明の一実施形態にかかる画像処理装置の構成例を示す図である。
【図２】画像処理装置のソフトウェア構成を示す図である。
【図３】画像処理装置のハードウェア構成を示す図である。
【図４】ＡＳＩＣの細部構成を示すブロック図である。
【図５】省エネ移行および省エネ復帰の処理例を示すシーケンス図である。
【図６】デバイスドライバの初期化によりパワーフック関数が登録されたパワーフックキューの例を示す図である。
【図７】パワーフック関数の例を示す図である。
【図８】省エネ移行時のソフトサスペンドのモードにおけるパワーフック関数の実行の例を示す図である。
【図９】省エネ移行時のサスペンドのモードにおけるパワーフック関数の実行の例を示す図である。
【図１０】省エネ移行時のリジュウムのモードにおけるパワーフック関数の実行の例を示す図である。
【図１１】省エネ移行時のソフトリジュウムのモードにおけるパワーフック関数の実行の例を示す図である。
【図１２】優先度レベル毎に区分されたパワーフックキューの例を示す図である。
【図１３】優先度レベル順にパワーフック関数を呼び出すプログラムの例を示す図である。
【符号の説明】
【００８４】
１ 画像処理装置
２ ＳＣＳ
３ ＯＳ
４ ＳＴＲドライバ
５ デバイスドライバ
６ パワーフックシステム
７ パワーフック処理部
８ パワーフックキュー
【技術分野】
【０００１】
本発明は、省エネ中に電源をＯＦＦしたデバイスを省エネ復帰後に問題なく使用することができるようにした画像処理装置に関する。
【背景技術】
【０００２】
ＭＦＰ（Multi Function Printer）等の画像処理装置では、省エネ（スリープ）時にはシステム情報をメモリに保持し（ＳＴＲ：Suspend to RAM）、省エネ復帰時にはメモリに保持されているシステム情報を呼び出して素早く復帰（Resume）する仕組みが取り入れられているものがある。
【０００３】
ところで、画像処理装置には、ＨＤＤ（Hard Disk Drive）、ビデオ（回路）、圧縮伸張器、回転器、合成器、ＭＡＣ（Media Access Control）、ＵＳＢ（Universal Serial Bus）、操作部、ＳＤ（Secure Digital）カード、パワーマネジメント（回路）、WatchDog等の各種のデバイスが装備されているが、省エネ時にはこれらのデバイスの電源がＯＦＦとされるため、そのまま省エネから復帰した場合には状態の不整合を起こし、正常に動作することができなくなる。
【０００４】
なお、出願人は出願時点までに本発明に関連する公開された先行技術文献を発見することができなかった。よって、先行技術文献情報を開示していない。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
本発明は上記の従来の問題点に鑑み提案されたものであり、その目的とするところは、省エネ中に電源をＯＦＦしたデバイスを省エネ復帰後に問題なく使用することができるようにした画像処理装置を提供することにある。
【課題を解決するための手段】
【０００６】
上記の課題を解決するため、本発明にあっては、
請求項１に記載されるように、各デバイスドライバの初期化時に、省エネ制御のモード毎に各デバイスドライバに設けられたコールバック関数を呼び出すパワーフック関数をパワーフックキューに登録する手段と、省エネ移行時に上記パワーフックキューに登録されたパワーフック関数を呼び出す手段と、省エネ復帰時に上記パワーフックキューに登録されたパワーフック関数を呼び出す手段とを備える画像処理装置を要旨としている。
【０００７】
また、請求項２に記載されるように、請求項１に記載の画像処理装置において、上記省エネ制御のモードは、省エネ移行の第１段階であるソフトサスペンド、省エネ移行の第２段階であるサスペンド、省エネ復帰の第１段階であるリジュウム、および、省エネ復帰の第２段階であるソフトリジュウムの４種類であるものとすることができる。
【０００８】
また、請求項３に記載されるように、請求項１または２のいずれか一項に記載の画像処理装置において、省エネ移行時および省エネ復帰時に各デバイスドライバへの他からの割り込みを禁止する期間を設けるようにすることができる。
【０００９】
また、請求項４に記載されるように、請求項１ないし３のいずれか一項に記載の画像処理装置において、上記パワーフックキューは優先度レベル毎に区分され、省エネ移行時および省エネ復帰時に優先度レベルの高い順に上記パワーフックキューに登録されたパワーフック関数を呼び出すようにすることができる。
【００１０】
また、請求項５に記載されるように、請求項１ないし４のいずれか一項に記載の画像処理装置において、上記各デバイスドライバの初期化時における上記パワーフックキューのパワーフック関数の登録は上記デバイスドライバの初期化の順に行い、省エネ移行時における上記パワーフックキューのパワーフック関数の呼び出しは登録順もしくは登録と逆順に行い、省エネ復帰時における上記パワーフックキューのパワーフック関数の呼び出しは登録と逆順もしくは登録順に行うようにすることができる。
【００１１】
また、請求項６〜１０に記載されるように、画像処理装置の省エネ制御方法として構成することができる。
【００１２】
また、請求項１１〜１５に記載されるように、画像処理装置の省エネ制御プログラムとして構成することができる。
【発明の効果】
【００１３】
本発明の画像処理装置にあっては、各デバイスドライバの初期化時に省エネ制御のモード毎に各デバイスドライバに設けられたコールバック関数を呼び出すパワーフック関数をパワーフックキューに登録し、省エネ移行時および省エネ復帰時にパワーフックキューに登録されたパワーフック関数を呼び出して不整合をなくす処理を適宜に行わせることができるため、省エネ中に電源をＯＦＦしたデバイスを省エネ復帰後に問題なく使用することができる。
【発明を実施するための最良の形態】
【００１４】
以下、本発明の好適な実施形態につき説明する。
【００１５】
図１は本発明の一実施形態にかかる画像処理装置１の構成例を示す図である。
【００１６】
図１において、画像処理装置１は、システム制御を行うＳＣＳ（System Control Service）２と、ＯＳ（Operating System）３内に設けられる、省エネ制御を行うＳＴＲドライバ４と、ＨＤＤ、ビデオ（回路）、圧縮伸張器、回転器、合成器、ＭＡＣ、ＵＳＢ、操作部、ＳＤカード、パワーマネジメント（回路）、WatchDog等の各種デバイスのデバイスドライバ５と、省エネ移行・復帰における各デバイスドライバ５の整合性確保のための処理を行うパワーフックシステム６とを備えている。また、パワーフックシステム６は主たる処理を行うパワーフック処理部７と、パワーフック関数を管理するパワーフックキュー８とを備えている。なお、画像処理装置１におけるその他の部分（エンジン、アプリケーション等）は図示を省略している。
【００１７】
図２は画像処理装置１のソフトウェア構成を示す図である。
【００１８】
図２において、この画像処理装置１は、白黒ラインプリンタ（B&W LP）３０１、カラーラインプリンタ（Color LP）３０２、その他ハードウェアリソース３０３などを有するとともに、ソフトウェア群３１０は、プラットホーム３２０およびアプリケーション３４０からなる。
【００１９】
プラットホーム３２０は、汎用ＯＳ３２１と、共通システムサービス３３０と、アプリサービス３２９とで形成される。なお、このプラットホーム３２０は、あらかじめ定義された関数によりアプリケーション３４０からの処理要求を受信可能とするアプリケーションプログラムインターフェースを有する。
【００２０】
汎用ＯＳ３２１は、ＵＮＩＸ（登録商標）などの汎用オペレーティングシステムであり、プラットホーム３２０並びにアプリケーション３４０の各ソフトウェアをそれぞれプロセスとして並列実行する。オープンソースのＵＮＩＸ（登録商標）を用いることにより、プログラムの安全性を確保できるとともに、ネットワーク対応可能となり、ソースコードの入手も容易となる。さらに、ＯＳ、ＴＣＰ／ＩＰのロイヤリティが不要であり、アウトソーシングも容易となる。
【００２１】
共通システムサービス３３０は、アプリケーション３４０に対して基本的な共通サービスを提供するものであり、アプリケーション３３０からの処理要求を解釈して、ハードウェア資源の獲得要求を発生させる下記に示すコントロールサービスと、一または複数のハードウェア資源の管理をおこない、コントロールサービスからの獲得要求を調停するシステムリソースマネージャー（ＳＲＭ（SystemResource Manager）３２３）とを有する。
【００２２】
このコントロールサービスは、複数のサービスモジュールにより形成され、具体的には、ＳＣＳ（System Control Service）３２２と、ＥＣＳ（Engine Control Service）３２４と、ＭＣＳ（Memory Control Service）３２５と、ＯＣＳ（Operation panel Control Service）３２６と、ＦＣＳ（FAX Control Service）３２７と、ＮＣＳ（Network Control Service）３２８とがある。
【００２３】
ＳＲＭ３２３は、ＳＣＳ３２２とともにシステムの制御およびリソースの管理をおこなうものであり、スキャナ部やプリンタ部などのエンジン、メモリ、ＨＤＤファイル、ホストＩ／Ｏ（セントロＩ／Ｆ、ネットワークＩ／Ｆ、ＩＥＥＥ１３９４Ｉ／Ｆ、ＲＳ２３２ＣＩ／Ｆなど）のハードウェア資源を利用する上位層からの要求にしたがって調停をおこない、実行制御する。
【００２４】
具体的には、このＳＲＭ３２３は、要求されたハードウェア資源が利用可能であるかどうか（他の要求により利用されていないかどうか）を判断し、利用可能であれば要求されたハードウェア資源が利用可能である旨を上位層に伝える。また、上位層からの要求に対してハードウェア資源の利用スケジューリングをおこない、要求内容（たとえば、プリンタエンジンによる紙搬送と作像動作、メモリ確保、ファイル生成など）を直接実施するようにしてもよい。
【００２５】
ＳＣＳ３２２は、（１）アプリ管理、（２）操作部制御、（３）システム画面表示（ジョブリスト画面、カウンタ表示画面など）、（４）ＬＥＤ表示、（５）リソース管理、（６）割り込みアプリ制御をおこなう。具体的には、（１）アプリ管理では、アプリの登録と、その情報を他のアプリに通知する処理をおこなう。登録されたアプリに対しては、システムの設定やアプリからの要求設定に応じてエンジン状態を通知する。また、登録済みのアプリに対しては、電力モード移行の問い合わせ、割り込みモードなど、システムの状態遷移のための可否問い合わせをおこなう。
【００２６】
また、（２）操作部制御では、アプリの操作部使用権の排他制御をおこなう。そして、操作部の使用権を持つアプリへ操作部ドライバ（ＯＣＳ）からのキー情報を排他的に通知する。このキー情報は、アプリ切替中などのシステムの状態遷移に応じて一時的に通知を停止するマスク制御をおこなう。
【００２７】
また、（３）システム画面表示では、操作部使用権を持つアプリからの要求内容に応じて、エンジン状態に対応する警告画面の表示をおこなう。これらのなかには、利用者制限画面などアプリの状態に応じて警告表示をオン／オフするものもある。エンジン状態以外では、ジョブの予約・実行状況を表示するためのジョブリスト画面、トータルカウンタ類を表示するためのカウンタ画面、ＣＳＳの通報中を示す画面の表示制御をおこなう。これらのシステム画面表示に関しては、アプリへ操作部使用権の解放を要求せず、アプリ画面を覆うシステム画面として描画をおこなう。
【００２８】
また、（４）ＬＥＤ表示では、警告ＬＥＤ、アプリキーなどのシステムＬＥＤの表示制御をおこなう。アプリ固有のＬＥＤについては、アプリが直接表示用ドライバを使用して制御する。
【００２９】
また、（５）リソース管理では、アプリ（ＥＣＳ）がジョブを実行するにあたって、排他しなければならないエンジンリソース（スキャナ、ステープルなど）の排他制御のためのサービスをおこない、（６）割り込みアプリ制御では、特定のアプリを優先動作せさるための制御・サービスをおこなう。
【００３０】
ＥＣＳ３２４は、白黒ラインプリンタ（B&W LP）３０１、カラーラインプリンタ（Color LP）３０２、その他ハードウェアリソース３０３などのエンジンを制御するものであり、画像読み込みと印刷動作、状態通知、ジャムリカバリなどをおこなう。
【００３１】
具体的には、アプリケーション３４０から受け取ったジョブモードの指定にしたがい、印刷要求をＳＲＭ３２３に順次発行していくことで、一連のコピー／スキャン／印刷動作を実現する。このＥＣＳ３２４が取り扱う対象のジョブは、画像入力デバイスにスキャナ（SCANNER）が指定されているか、または、画像出力デバイスにプロッタ（PLOTTER）が指定されているものとする。
【００３２】
たとえば、コピー動作の場合には「SCANNER → PLOTTER」と指定され、ファイル蓄積の場合には「SCANNER → MEMORY」と指定され、ファクシミリ送信の場合には「SCANNER → FAX＿IN」と指定される。また、蓄積ファイル印刷またはプリンタアプリ３１１からの印刷の場合には「MEMORY → PLOTTER」と指定され、ファクシミリ受信の場合には「FAX＿OUT → PLOTTER」と指定される。
【００３３】
なお、ジョブの定義はアプリケーションによって異なるが、ここでは利用者が取り扱う１セットの画像群に対する処理動作を１ジョブと定義する。たとえば、コピーのＡＤＦ（Automatic Document Feeder）モードの場合は、原稿台に置かれた１セットの原稿を読み取る動作が１ジョブとなり、圧板モードは最終原稿が確定するまでの読み取り動作が１ジョブとなる。また、コピーアプリ３１２の場合には、一束の原稿をコピーする動作が１ジョブとなり、ファックスアプリ３１３の場合には、１文書の送信動作または１文書の受信動作が１ジョブとなり、プリンタアプリの場合には、１文書の印刷動作が１ジョブとなる。
【００３４】
ＭＣＳ３２５は、メモリ制御をおこなうものであり、具体的には、画像メモリの取得および開放、ハードディスク装置（ＨＤＤ）の利用、画像データの圧縮および伸張などをおこなう。
【００３５】
ここで、ハードディスク装置に蓄積される画像データファイルとして必要な情報を管理するために必要な機能としては、（１）ファイルアクセス（生成／削除／オープン／クローズ）機能（排他処理を含む）、（２）ファイル名称／ＩＤ管理（ファイル／ユーザ）／パスワード管理／蓄積時刻管理／ページ数／データフォーマット（圧縮方式など）／アクセス制限／作成アプリ／印刷条件管理などの各種ファイル属性管理（物理的なページ単位の画像データのファイルとしての管理）、（３）ファイル単位およびページ単位での結合／挿入／切断機能、（４）ファイルソート機能（蓄積時刻順／ユーザＩＤ順など）、（５）全ファイル情報の通知（表示／検索用）、（６）リカバリ機能（破損ファイルのファイル／ページ破棄）、（７）ファイルの自動削除機能などがある。
【００３６】
また、ＲＡＭなどのメモリへ画像データを保持しアクセスするための機能としては、（１）アプリケーション３４０からのファイルおよびページ／バンド属性情報を取得する機能、（２）アプリケーション３４０からの画像データ領域の確保、解放、リード（Read）、ライト（Write）機能などがある。
【００３７】
ＯＣＳ３２６は、オペレータと本体制御間の情報伝達手段となる操作パネルを制御するモジュールであり、オペレータのキー操作イベントを本体制御に通知する処理、各アプリがＧＵＩを構築するためのライブラリ関数を提供する処理、構築されたＧＵＩ情報をアプリ別に管理する処理、操作パネル上への表示反映処理などをおこなう。
【００３８】
このＯＣＳ３２６は、（１）ＧＵＩ構築のためのライブラリの提供機能、（２）操作部ハードウェア資源管理機能、（３）ＶＲＡＭ描画／ＬＣＤ表示機能（ハードウェア表示、表示アプリ切替、表示言語切替、ウインドウ暗色表示、メッセージ／アイコンブリンク表示、メッセージの連結表示）、（４）ハードキー入力検出機能、（５）タッチパネルキー入力検出機能、（６）ＬＥＤ出力機能、（７）ブザー出力機能などを有する。
【００３９】
ＦＣＳ３２７は、システムコントローラの各アプリ層からＰＳＴＮ／ＩＳＤＮ網を使ったファクシミリ送受信、ＢＫＭ（バックアップＳＲＡＭ）で管理されている各種ファクシミリデータの登録／引用、ファクシミリ読み取り、ファクシミリ受信印刷、融合送受信をおこなうためのＡＰＩを提供するものである。
【００４０】
具体的には、このＦＣＳ３２７は、（１）アプリ層から送信依頼されたドキュメントをＰＳＴＮ／ＩＳＤＮ網を使ってファクシミリ受信機に送信をおこなう送信機能、（２）ＰＳＴＮ／ＩＳＤＮ網から受信したファクシミリ受信画面、各種レポート類を各アプリ層に転送、印刷をおこなう受信機能、（３）ファックスボードに記憶されている電話帳、グループ情報などのファクシミリ管理項目の引用や登録をおこなう電話帳引用・登録機能、（４）ファックスボードに搭載されているＢＫＭに記憶されている送受信結果履歴情報などを必要としているアプリに通知するファックスログ通知機能、（５）ファックスボードの状態変化があったときにＦＣＳに登録してあるアプリに変化のあったイベントを通知するイベント通知機能などを有する。
【００４１】
ＮＣＳ３２８は、ネットワークＩ／Ｏを必要とするアプリケーションに対して共通に利用できるサービスを提供するためのモジュール群であり、ネットワーク側から各プロトコルによって受信したデータを各アプリケーションに振り分けたり、アプリケーションからデータをネットワーク側に送信する際の仲介をおこなう。具体的には、ftpd、httpd、lpd、snmpd、telnetd、smtpdなどのサーバデーモンや、同プロトコルのクライアント機能などを有する。
【００４２】
アプリサービス３２９は、プラットホーム３２０を形成する共通サービスの一つであるが、上記共通システムサービス３３０を形成するＥＣＳ３２４、ＭＣＳ３２５、ＯＣＳ３２６、ＦＣＳ３２７、ＮＣＳ３２８、ＳＲＭ３２３およびＳＣＳ３２２とは異なり、アプリケーション３４０側に立ったサービスを提供するものである。
【００４３】
言い換えると、このアプリサービス３２９は、アプリケーション３４０と共通システムサービス３３０との間に介在し、両者の間の橋渡しを担う役割を果たしている。
【００４４】
具体的には、このアプリサービス３２９は、コピーアプリ３１２、ファックスアプリ３１３、スキャナアプリ３１４などが、本来おこなうべきジョブの生成やデータ通信の機能を一括して代行する。このため、コピーアプリ３１２、ファックスアプリ３１３、スキャナアプリ３１４などは、画面やキー操作を対象とすれば足りるので、アプリの開発効率が向上する。
【００４５】
アプリケーション３４０は、ページ記述言語（ＰＤＬ）、ＰＣＬおよびポストスクリプト（ＰＳ）を有するプリンタ用のアプリケーションであるプリンタアプリ３１１と、コピー用アプリケーションであるコピーアプリ３１２と、ファクシミリ用アプリケーションであるファックスアプリ３１３と、スキャナ用アプリケーションであるスキャナアプリ３１４と、ネットファイル用アプリケーションであるネットファイルアプリ３１５と、工程検査用アプリケーションである工程検査アプリ３１６とを有する。
【００４６】
各アプリケーション３１１〜３１６は、プラットホーム３２０上の各プロセスを利用して動作実行し得るため、画面制御およびキー操作制御などをおこなう画面表示制御プログラムがその主体となる。特に、アプリサービス３２９がプラットホーム３２０上に設けられているので、ジョブの生成やデータ通信の機能を設ける必要がない。なお、ＮＣＳ３２８により接続されたネットワークを介して新たなアプリケーションをネットワーク経由で搭載することもできる。また、各アプリケーションはアプリケーションごとに追加または削除することができる。
【００４７】
図３は画像処理装置１のハードウェア構成を示す図である。
【００４８】
図３において、画像処理装置１は、ＣＰＵ９０２、ＳＤＲＡＭ９０３、フラッシュメモリ９０４およびＨＤ９０５などをＡＳＩＣ９０１に接続したコントローラボード９００と、オペレーションパネル９１０と、ファックスコントロールユニット（ＦＣＵ）９２０と、ＵＳＢ９３０と、ＩＥＥＥ1394９４０と、プリンタ９５０とからなる。
【００４９】
そして、オペレーションパネル９１０はＡＳＩＣ９０１に直接接続され、ＦＣＵ９２０、ＵＳＢ９３０、ＩＥＥＥ1394９４０およびプリンタ９５０は、ＰＣＩバスを介してＡＳＩＣ９０１に接続されている。
【００５０】
図４は図３に示したＡＳＩＣ９０１の細部構成を示すブロック図である。
【００５１】
図４において、このＡＳＩＣ９０１は、ＣＰＵインターフェース（CPU I/F）、ＳＤＲＡＭインターフェース（SDRAM I/F）、ローカルバスインターフェース（Local BUS I/F）、ＰＣＩインターフェース（PCI I/F）、１２８４、ＭＡＣ（Media Access Controllor）、Ｉ／Ｏ、ＯＰＥインターフェース（OPE I/F）、ＨＤインターフェース（HD I/F）、Comp／de-comp、Rotateによって形成されている。
【００５２】
かかるハードウェア構成を採用することにより、デバイスの共有化による低コスト設計が可能となるとともに、アプリ間融合が容易となる。また、低速機から高速機までスケーラブルなアーキテクチャーとなり、各アプリで使用するハード／ソフトが共通化され、開発効率を向上させることができる。また、新規機能に対する対応が容易となる。
【００５３】
図５は省エネ移行および省エネ復帰の処理例を示すシーケンス図である。
【００５４】
図５において、各デバイスドライバ５は初期化時（機器起動時もしくはアタッチ時）にパワーフックシステム６のパワーフック処理部７に対してコールバック関数の登録を要求（powerhook_establish()のコール）する（ステップＳ１０１）。パワーフック処理部７はパワーフック関数をパワーフックキュー８に追加し（ステップＳ１０２）、登録が完了した旨がデバイスドライバ５まで返される（ステップＳ１０３、Ｓ１０４）。
【００５５】
図６はデバイスドライバ５の初期化によりパワーフック関数が登録されたパワーフックキュー８の例を示す図であり、ＯＳが初期化した順に、ＨＤＤ→ビデオ→圧縮伸張器→回転器→合成器→ＭＡＣ→ＵＳＢ→操作部→ＳＤカード→パワーマネジメント→WatchDogに対応するパワーフック関数が登録された状態を示している。
【００５６】
図７はパワーフック関数の例を示す図であり、ＳＤカードに対応するパワーフック関数の例を示している。パワーフック関数は、引数で指定されるモード（mode）に応じて所定のコールバック関数を呼び出すようになっており、図示の例では、モードがPWR_SOFTSUSPENDの場合にコールバック関数sdc_suspend(sdc)を呼び出し、モードがPWR_SOFTRESUMEの場合にコールバック関数sdc_resume(sdc)を呼び出すようになっている。
【００５７】
なお、デバイスドライバ５側のコールバック関数は、主に次のような処理を行う。
（１）各デバイスの制御レジスタの保存と復元（もしくは省エネ復帰時に制御レジスタの初期値設定のみ）を行なう。
（２）デバイスそのものに状態遷移がある場合、デバイスの制御（割り込み制御）を行なって使用可能な状態に移行させる。
【００５８】
図５に戻り、機器の待機時間が所定値を越えた等の要因によりＳＴＲイベントが発生すると（ステップＳ１０５）、ＳＣＳ２はＳＴＲドライバ４にＳＴＲ移行要求（sysarch(STR)をコール）する（ステップＳ１０６）。
【００５９】
ＳＴＲドライバ４はパワーフック処理部７に省エネ移行の第１段階であるソフトサスペンドを要求（powerhooks(PWR_SOFTSUSPED)をコール）し（ステップＳ１０７）、パワーフック処理部７はパワーフックキュー８にパワーフック関数の呼び出しを要求する（ステップＳ１０８）。
【００６０】
パワーフックキュー８はパワーフック関数を実行することで、各デバイスドライバ５に対しモードに応じたコールバック関数の呼び出しを行う（ステップＳ１０９）。各デバイスドライバ５ではコールバック関数に応じた処理を行い、処理完了をパワーフックキュー８に伝える（ステップＳ１１０）。
【００６１】
図８は省エネ移行時のソフトサスペンドのモードにおけるパワーフック関数の実行の例を示す図であり、パワーフックキュー８に登録された順に実行するようにしたものである。図８において網掛けを付したものはソフトサスペンドのモードに対応するコールバック関数がないものを示しており、網掛けを付していないデバイスドライバのみがコールバック関数に応じた処理を行う。なお、パワーフックキュー８に登録された順と逆順に実行するようにしてもよい。また、各デバイスドライバ５が完全に独立した動作をする場合には実行順序を考慮しなくてもよい。
【００６２】
図５に戻り、パワーフックキュー８は全てのデバイスドライバ５についての処理を完了すると、その旨をパワーフック処理部７に伝え（ステップＳ１１１）、パワーフック処理部７はその旨をＳＴＲドライバ４に伝える（ステップＳ１１２）。
【００６３】
次いで、ＳＴＲドライバ４は割り込み優先度を上げることで、各デバイスドライバ５への他からの割り込みを禁止する（ステップＳ１１３）。これは、デバイスそのものに状態遷移がある場合、そのようなデバイスに対応するデバイスドライバ５の処理を続く省エネ移行の第２段階であるサスペンドのモードにおいて行わせることとし、その間のコールバック関数によるデバイスの状態制御処理に支障を与えないようにするためである。なお、WatchDogは定期的にリフレッシュされないと呼び出し元に異常が発生したものとしてリブートを行うものであり、割り込み禁止状態になると誤って異常の発生と認識してしまうため、省エネ移行の第１段階であるソフトサスペンドのモードにおいて停止させるものとする。
【００６４】
次いで、ＳＴＲドライバ４はパワーフック処理部７に省エネ移行の第２段階であるサスペンドを要求（powerhooks(PWR_SUSPED)をコール）し（ステップＳ１１４）、パワーフック処理部７はパワーフックキュー８にパワーフック関数の呼び出しを要求する（ステップＳ１１５）。
【００６５】
パワーフックキュー８はパワーフック関数を実行することで、各デバイスドライバ５に対しモードに応じたコールバック関数の呼び出しを行う（ステップＳ１１６）。各デバイスドライバ５ではコールバック関数に応じた処理を行い、処理完了をパワーフックキュー８に伝える（ステップＳ１１７）。
【００６６】
図９は省エネ移行時のサスペンドのモードにおけるパワーフック関数の実行の例を示す図であり、パワーフックキュー８に登録された順に実行される。図９において網掛けを付したものはサスペンドのモードに対応するコールバック関数がないものを示しており、網掛けを付していないデバイスドライバのみがコールバック関数に応じた処理を行う。なお、パワーフックキュー８に登録された順と逆順に実行するようにしてもよい。また、各デバイスドライバ５が完全に独立した動作をする場合には実行順序を考慮しなくてもよい。
【００６７】
図５に戻り、パワーフックキュー８は全てのデバイスドライバ５についての処理を完了すると、その旨をパワーフック処理部７に伝え（ステップＳ１１８）、パワーフック処理部７はその旨をＳＴＲドライバ４に伝える（ステップＳ１１９）。
【００６８】
その後、ＳＴＲドライバ４はＳＴＲを実行し（ステップＳ１２０）、省エネ状態に入る（ステップＳ１２１）。
【００６９】
機器へのジョブの投入等により復帰要因が発生すると（ステップＳ１２２）、ＳＴＲドライバ４はＷａｋｅｕｐを実行する（ステップＳ１２３）。
【００７０】
次いで、ＳＴＲドライバ４はパワーフック処理部７に省エネ復帰の第１段階であるリジュウムを要求（powerhooks(PWR_RESUME)をコール）し（ステップＳ１２４）、パワーフック処理部７はパワーフックキュー８にパワーフック関数の呼び出しを要求する（ステップＳ１２５）。
【００７１】
パワーフックキュー８はパワーフック関数を実行することで、各デバイスドライバ５に対しモードに応じたコールバック関数の呼び出しを行う（ステップＳ１２６）。各デバイスドライバ５ではコールバック関数に応じた処理を行い、処理完了をパワーフックキュー８に伝える（ステップＳ１２７）。
【００７２】
図１０は省エネ移行時のリジュウムのモードにおけるパワーフック関数の実行の例を示す図であり、パワーフックキュー８に登録された順とは逆順に実行される。図１０において網掛けを付したものはリジュウムのモードに対応するコールバック関数がないものを示しており、網掛けを付していないデバイスドライバのみがコールバック関数に応じた処理を行う。なお、パワーフックキュー８に登録された順に実行するようにしてもよい。また、各デバイスドライバ５が完全に独立した動作をする場合には実行順序を考慮しなくてもよい。
【００７３】
図５に戻り、パワーフックキュー８は全てのデバイスドライバ５についての処理を完了すると、その旨をパワーフック処理部７に伝え（ステップＳ１２８）、パワーフック処理部７はその旨をＳＴＲドライバ４に伝える（ステップＳ１２９）。
【００７４】
次いで、ＳＴＲドライバ４は各デバイスドライバ５への他からの割り込み禁止を解除する（ステップＳ１３０）。
【００７５】
次いで、ＳＴＲドライバ４はパワーフック処理部７に省エネ復帰の第２段階であるソフトリジュウムを要求（powerhooks(PWR_SOFTRESUME)をコール）し（ステップＳ１３１）、パワーフック処理部７はパワーフックキュー８にパワーフック関数の呼び出しを要求する（ステップＳ１３２）。
【００７６】
パワーフックキュー８はパワーフック関数を実行することで、各デバイスドライバ５に対しモードに応じたコールバック関数の呼び出しを行う（ステップＳ１３３）。各デバイスドライバ５ではコールバック関数に応じた処理を行い、処理完了をパワーフックキュー８に伝える（ステップＳ１３４）。
【００７７】
図１１は省エネ移行時のソフトリジュウムのモードにおけるパワーフック関数の実行の例を示す図であり、パワーフックキュー８に登録された順とは逆順に実行される。図１１において網掛けを付したものはソフトリジュウムのモードに対応するコールバック関数がないものを示しており、網掛けを付していないデバイスドライバのみがコールバック関数に応じた処理を行う。なお、パワーフックキュー８に登録された順に実行するようにしてもよい。また、各デバイスドライバ５が完全に独立した動作をする場合には実行順序を考慮しなくてもよい。
【００７８】
図５に戻り、パワーフックキュー８は全てのデバイスドライバ５についての処理を完了すると、その旨をパワーフック処理部７に伝え（ステップＳ１３５）、パワーフック処理部７はその旨をＳＴＲドライバ４に伝える（ステップＳ１３６）。
【００７９】
ＳＴＲドライバ４はＳＣＳ２にＳＴＲ完了を伝え（ステップＳ１３７）、処理を終了する。
【００８０】
図１２は優先度レベル毎に区分されたパワーフックキュー８の例を示す図であり、最も優先度レベルの高い「０」から最も低い「３」までの４段階に分けた例を示している。例えば、「０」にはWatchdogタイマが登録され、「１」には主に画像処理装置として外部からの入力を受けるドライバが登録され、「２」にはその他のドライバが登録され、「３」には省エネの移行・復帰を行うドライバが登録される。なお、優先度レベルは各デバイスドライバ５からパワーフックシステム６にパワーフック関数の登録を要求する際に指定することで、対応する優先度レベルに順に登録される。
【００８１】
図１３は優先度レベル順にパワーフック関数を呼び出すプログラムの例を示す図であり、powerhooks(モード)をコールされたパワーフック処理部７の内部において実行されるプログラムの例である。図１３において、（ａ）はソフトサスペンドのモードにおける場合、（ｂ）はサスペンドのモードにおける場合、（ｃ）はリジュウムのモードにおける場合、（ｄ）はソフトリジュウムのモードにおける場合を示している。
【００８２】
以上、本発明の好適な実施の形態により本発明を説明した。ここでは特定の具体例を示して本発明を説明したが、特許請求の範囲に定義された本発明の広範な趣旨および範囲から逸脱することなく、これら具体例に様々な修正および変更を加えることができることは明らかである。すなわち、具体例の詳細および添付の図面により本発明が限定されるものと解釈してはならない。
【図面の簡単な説明】
【００８３】
【図１】本発明の一実施形態にかかる画像処理装置の構成例を示す図である。
【図２】画像処理装置のソフトウェア構成を示す図である。
【図３】画像処理装置のハードウェア構成を示す図である。
【図４】ＡＳＩＣの細部構成を示すブロック図である。
【図５】省エネ移行および省エネ復帰の処理例を示すシーケンス図である。
【図６】デバイスドライバの初期化によりパワーフック関数が登録されたパワーフックキューの例を示す図である。
【図７】パワーフック関数の例を示す図である。
【図８】省エネ移行時のソフトサスペンドのモードにおけるパワーフック関数の実行の例を示す図である。
【図９】省エネ移行時のサスペンドのモードにおけるパワーフック関数の実行の例を示す図である。
【図１０】省エネ移行時のリジュウムのモードにおけるパワーフック関数の実行の例を示す図である。
【図１１】省エネ移行時のソフトリジュウムのモードにおけるパワーフック関数の実行の例を示す図である。
【図１２】優先度レベル毎に区分されたパワーフックキューの例を示す図である。
【図１３】優先度レベル順にパワーフック関数を呼び出すプログラムの例を示す図である。
【符号の説明】
【００８４】
１ 画像処理装置
２ ＳＣＳ
３ ＯＳ
４ ＳＴＲドライバ
５ デバイスドライバ
６ パワーフックシステム
７ パワーフック処理部
８ パワーフックキュー
【特許請求の範囲】
【請求項１】
各デバイスドライバの初期化時に、省エネ制御のモード毎に各デバイスドライバに設けられたコールバック関数を呼び出すパワーフック関数をパワーフックキューに登録する手段と、
省エネ移行時に上記パワーフックキューに登録されたパワーフック関数を呼び出す手段と、
省エネ復帰時に上記パワーフックキューに登録されたパワーフック関数を呼び出す手段とを備えたことを特徴とする画像処理装置。
【請求項２】
請求項１に記載の画像処理装置において、
上記省エネ制御のモードは、省エネ移行の第１段階であるソフトサスペンド、省エネ移行の第２段階であるサスペンド、省エネ復帰の第１段階であるリジュウム、および、省エネ復帰の第２段階であるソフトリジュウムの４種類であることを特徴とする画像処理装置。
【請求項３】
請求項１または２のいずれか一項に記載の画像処理装置において、
省エネ移行時および省エネ復帰時に各デバイスドライバへの他からの割り込みを禁止する期間を設けたことを特徴とする画像処理装置。
【請求項４】
請求項１ないし３のいずれか一項に記載の画像処理装置において、
上記パワーフックキューは優先度レベル毎に区分され、
省エネ移行時および省エネ復帰時に優先度レベルの高い順に上記パワーフックキューに登録されたパワーフック関数を呼び出すことを特徴とする画像処理装置。
【請求項５】
請求項１ないし４のいずれか一項に記載の画像処理装置において、
上記各デバイスドライバの初期化時における上記パワーフックキューのパワーフック関数の登録は上記デバイスドライバの初期化の順に行い、
省エネ移行時における上記パワーフックキューのパワーフック関数の呼び出しは登録順もしくは登録と逆順に行い、
省エネ復帰時における上記パワーフックキューのパワーフック関数の呼び出しは登録と逆順もしくは登録順に行うことを特徴とする画像処理装置。
【請求項６】
各デバイスドライバの初期化時に、省エネ制御のモード毎に各デバイスドライバに設けられたコールバック関数を呼び出すパワーフック関数をパワーフックキューに登録する工程と、
省エネ移行時に上記パワーフックキューに登録されたパワーフック関数を呼び出す工程と、
省エネ復帰時に上記パワーフックキューに登録されたパワーフック関数を呼び出す工程とを備えたことを特徴とする画像処理装置の省エネ制御方法。
【請求項７】
請求項６に記載の画像処理装置の省エネ制御方法において、
上記省エネ制御のモードは、省エネ移行の第１段階であるソフトサスペンド、省エネ移行の第２段階であるサスペンド、省エネ復帰の第１段階であるリジュウム、および、省エネ復帰の第２段階であるソフトリジュウムの４種類であることを特徴とする画像処理装置の省エネ制御方法。
【請求項８】
請求項６または７のいずれか一項に記載の画像処理装置の省エネ制御方法において、
省エネ移行時および省エネ復帰時に各デバイスドライバへの他からの割り込みを禁止する期間を設けたことを特徴とする画像処理装置の省エネ制御方法。
【請求項９】
請求項６ないし８のいずれか一項に記載の画像処理装置の省エネ制御方法において、
上記パワーフックキューは優先度レベル毎に区分され、
省エネ移行時および省エネ復帰時に優先度レベルの高い順に上記パワーフックキューに登録されたパワーフック関数を呼び出すことを特徴とする画像処理装置の省エネ制御方法。
【請求項１０】
請求項６ないし９のいずれか一項に記載の画像処理装置の省エネ制御方法において、
上記各デバイスドライバの初期化時における上記パワーフックキューのパワーフック関数の登録は上記デバイスドライバの初期化の順に行い、
省エネ移行時における上記パワーフックキューのパワーフック関数の呼び出しは登録順もしくは登録と逆順に行い、
省エネ復帰時における上記パワーフックキューのパワーフック関数の呼び出しは登録と逆順もしくは登録順に行うことを特徴とする画像処理装置の省エネ制御方法。
【請求項１１】
コンピュータを、
各デバイスドライバの初期化時に、省エネ制御のモード毎に各デバイスドライバに設けられたコールバック関数を呼び出すパワーフック関数をパワーフックキューに登録する手段、
省エネ移行時に上記パワーフックキューに登録されたパワーフック関数を呼び出す手段、
省エネ復帰時に上記パワーフックキューに登録されたパワーフック関数を呼び出す手段、
として動作させることを特徴とする画像処理装置の省エネ制御プログラム。
【請求項１２】
請求項１１に記載の画像処理装置の省エネ制御プログラムにおいて、
上記省エネ制御のモードは、省エネ移行の第１段階であるソフトサスペンド、省エネ移行の第２段階であるサスペンド、省エネ復帰の第１段階であるリジュウム、および、省エネ復帰の第２段階であるソフトリジュウムの４種類であることを特徴とする画像処理装置の省エネ制御プログラム。
【請求項１３】
請求項１１または１２のいずれか一項に記載の画像処理装置の省エネ制御プログラムにおいて、
省エネ移行時および省エネ復帰時に各デバイスドライバへの他からの割り込みを禁止する期間を設けたことを特徴とする画像処理装置の省エネ制御プログラム。
【請求項１４】
請求項１１ないし１３のいずれか一項に記載の画像処理装置の省エネ制御プログラムにおいて、
上記パワーフックキューは優先度レベル毎に区分され、
省エネ移行時および省エネ復帰時に優先度レベルの高い順に上記パワーフックキューに登録されたパワーフック関数を呼び出すことを特徴とする画像処理装置の省エネ制御プログラム。
【請求項１５】
請求項１１ないし１４のいずれか一項に記載の画像処理装置の省エネ制御プログラムにおいて、
上記各デバイスドライバの初期化時における上記パワーフックキューのパワーフック関数の登録は上記デバイスドライバの初期化の順に行い、
省エネ移行時における上記パワーフックキューのパワーフック関数の呼び出しは登録順もしくは登録と逆順に行い、
省エネ復帰時における上記パワーフックキューのパワーフック関数の呼び出しは登録と逆順もしくは登録順に行うことを特徴とする画像処理装置の省エネ制御プログラム。
【請求項１】
各デバイスドライバの初期化時に、省エネ制御のモード毎に各デバイスドライバに設けられたコールバック関数を呼び出すパワーフック関数をパワーフックキューに登録する手段と、
省エネ移行時に上記パワーフックキューに登録されたパワーフック関数を呼び出す手段と、
省エネ復帰時に上記パワーフックキューに登録されたパワーフック関数を呼び出す手段とを備えたことを特徴とする画像処理装置。
【請求項２】
請求項１に記載の画像処理装置において、
上記省エネ制御のモードは、省エネ移行の第１段階であるソフトサスペンド、省エネ移行の第２段階であるサスペンド、省エネ復帰の第１段階であるリジュウム、および、省エネ復帰の第２段階であるソフトリジュウムの４種類であることを特徴とする画像処理装置。
【請求項３】
請求項１または２のいずれか一項に記載の画像処理装置において、
省エネ移行時および省エネ復帰時に各デバイスドライバへの他からの割り込みを禁止する期間を設けたことを特徴とする画像処理装置。
【請求項４】
請求項１ないし３のいずれか一項に記載の画像処理装置において、
上記パワーフックキューは優先度レベル毎に区分され、
省エネ移行時および省エネ復帰時に優先度レベルの高い順に上記パワーフックキューに登録されたパワーフック関数を呼び出すことを特徴とする画像処理装置。
【請求項５】
請求項１ないし４のいずれか一項に記載の画像処理装置において、
上記各デバイスドライバの初期化時における上記パワーフックキューのパワーフック関数の登録は上記デバイスドライバの初期化の順に行い、
省エネ移行時における上記パワーフックキューのパワーフック関数の呼び出しは登録順もしくは登録と逆順に行い、
省エネ復帰時における上記パワーフックキューのパワーフック関数の呼び出しは登録と逆順もしくは登録順に行うことを特徴とする画像処理装置。
【請求項６】
各デバイスドライバの初期化時に、省エネ制御のモード毎に各デバイスドライバに設けられたコールバック関数を呼び出すパワーフック関数をパワーフックキューに登録する工程と、
省エネ移行時に上記パワーフックキューに登録されたパワーフック関数を呼び出す工程と、
省エネ復帰時に上記パワーフックキューに登録されたパワーフック関数を呼び出す工程とを備えたことを特徴とする画像処理装置の省エネ制御方法。
【請求項７】
請求項６に記載の画像処理装置の省エネ制御方法において、
上記省エネ制御のモードは、省エネ移行の第１段階であるソフトサスペンド、省エネ移行の第２段階であるサスペンド、省エネ復帰の第１段階であるリジュウム、および、省エネ復帰の第２段階であるソフトリジュウムの４種類であることを特徴とする画像処理装置の省エネ制御方法。
【請求項８】
請求項６または７のいずれか一項に記載の画像処理装置の省エネ制御方法において、
省エネ移行時および省エネ復帰時に各デバイスドライバへの他からの割り込みを禁止する期間を設けたことを特徴とする画像処理装置の省エネ制御方法。
【請求項９】
請求項６ないし８のいずれか一項に記載の画像処理装置の省エネ制御方法において、
上記パワーフックキューは優先度レベル毎に区分され、
省エネ移行時および省エネ復帰時に優先度レベルの高い順に上記パワーフックキューに登録されたパワーフック関数を呼び出すことを特徴とする画像処理装置の省エネ制御方法。
【請求項１０】
請求項６ないし９のいずれか一項に記載の画像処理装置の省エネ制御方法において、
上記各デバイスドライバの初期化時における上記パワーフックキューのパワーフック関数の登録は上記デバイスドライバの初期化の順に行い、
省エネ移行時における上記パワーフックキューのパワーフック関数の呼び出しは登録順もしくは登録と逆順に行い、
省エネ復帰時における上記パワーフックキューのパワーフック関数の呼び出しは登録と逆順もしくは登録順に行うことを特徴とする画像処理装置の省エネ制御方法。
【請求項１１】
コンピュータを、
各デバイスドライバの初期化時に、省エネ制御のモード毎に各デバイスドライバに設けられたコールバック関数を呼び出すパワーフック関数をパワーフックキューに登録する手段、
省エネ移行時に上記パワーフックキューに登録されたパワーフック関数を呼び出す手段、
省エネ復帰時に上記パワーフックキューに登録されたパワーフック関数を呼び出す手段、
として動作させることを特徴とする画像処理装置の省エネ制御プログラム。
【請求項１２】
請求項１１に記載の画像処理装置の省エネ制御プログラムにおいて、
上記省エネ制御のモードは、省エネ移行の第１段階であるソフトサスペンド、省エネ移行の第２段階であるサスペンド、省エネ復帰の第１段階であるリジュウム、および、省エネ復帰の第２段階であるソフトリジュウムの４種類であることを特徴とする画像処理装置の省エネ制御プログラム。
【請求項１３】
請求項１１または１２のいずれか一項に記載の画像処理装置の省エネ制御プログラムにおいて、
省エネ移行時および省エネ復帰時に各デバイスドライバへの他からの割り込みを禁止する期間を設けたことを特徴とする画像処理装置の省エネ制御プログラム。
【請求項１４】
請求項１１ないし１３のいずれか一項に記載の画像処理装置の省エネ制御プログラムにおいて、
上記パワーフックキューは優先度レベル毎に区分され、
省エネ移行時および省エネ復帰時に優先度レベルの高い順に上記パワーフックキューに登録されたパワーフック関数を呼び出すことを特徴とする画像処理装置の省エネ制御プログラム。
【請求項１５】
請求項１１ないし１４のいずれか一項に記載の画像処理装置の省エネ制御プログラムにおいて、
上記各デバイスドライバの初期化時における上記パワーフックキューのパワーフック関数の登録は上記デバイスドライバの初期化の順に行い、
省エネ移行時における上記パワーフックキューのパワーフック関数の呼び出しは登録順もしくは登録と逆順に行い、
省エネ復帰時における上記パワーフックキューのパワーフック関数の呼び出しは登録と逆順もしくは登録順に行うことを特徴とする画像処理装置の省エネ制御プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【公開番号】特開２００７−３０６１４３（Ｐ２００７−３０６１４３Ａ）
【公開日】平成１９年１１月２２日（２００７．１１．２２）
【国際特許分類】
【出願番号】特願２００６−１３０５５２（Ｐ２００６−１３０５５２）
【出願日】平成１８年５月９日（２００６．５．９）
【出願人】（０００００６７４７）株式会社リコー (37,907)
【Ｆターム（参考）】
【公開日】平成１９年１１月２２日（２００７．１１．２２）
【国際特許分類】
【出願日】平成１８年５月９日（２００６．５．９）
【出願人】（０００００６７４７）株式会社リコー (37,907)
【Ｆターム（参考）】
[ Back to top ]