JP5874399B2 - 処理装置 - Google Patents

Description

この発明は、プロジェクタ、ファクシミリ装置、スキャナ、プリンタ、複写機及び複合機等の処理装置に関する。

近年のプロジェクタ、ファクシミリ装置、スキャナ、プリンタ、複写機及び複合機等の処理装置では、電力消費量の抑制を目的としてスタンバイ状態という省エネルギー状態（「省電力状態」ともいう）に移行する機能が設けられている。
従来、機能実行中にスタンバイ移行要求を受け付けた際に実行中のジョブが完了してからスタンバイに移行する旨を表示する処理装置（例えば、特許文献１参照）があった。

しかしながら、従来の処理装置では、スタンバイ移行の方法では移行中に機能利用の要求が来るとスタンバイ状態に移行することができず、スタンバイ状態に移行するまでに時間がかかってしまうという問題があった。
また、スタンバイ状態では不要なデバイスへの電力供給を止めることで消費電力を抑制しているため、何らかの機能の実行中にスタンバイに移行しようとすると不具合が発生してしまう可能性がある。
この発明は上記の点に鑑みてなされたものであり、何らかの機能の実行中に省電力状態に移行してしまうことによる故障の防止と、省電力状態に移行中には新規の要求を受け付けずに素早く省電力状態に移行できるようにすることを目的とする。

この発明は上記の目的を達成するため、入力手段によって入力された処理要求に対応する処理を実行する処理手段を備えた処理装置であって、その処理装置を省電力状態に移行させる制御と省電力状態から復帰させる制御をする電力制御手段と、その電力制御手段によってその処理装置を省電力状態に移行させる前に、上記処理手段に対して所定の動作抑制を要求し、上記電力制御手段によってその処理装置を省電力状態から復帰させた場合に上記処理手段に対して動作抑制の解除を要求する制御をする動作抑制制御手段とを有し、上記動作抑制制御手段が、上記処理手段に対して上記所定の動作抑制の要求前に受け付けた処理は終了し、上記所定の動作抑制の要求の後に受け付けた処理は中止する動作抑制を要求する手段を有する処理装置を提供する。

この発明による処理装置は、何らかの機能の実行中に省電力状態に移行してしまうことによる故障の防止と、省電力状態に移行中には新規の要求を受け付けずに素早く省電力状態に移行することができる。

図２に示したプロジェクタ１の内部の構成例を示すブロック図である。 この発明の一実施形態である投影システムの構成例を示す図である。 図１に示したプロジェクタ１の電力状態と各状態の時に受け付けられる要求の各内容について示したテーブルの一例の図である。 図１に示したプロジェクタ１が動作抑制をかけるときの処理を示すシーケンス図である。 図１に示した動作抑制制御部１４の動作抑制時の処理を示すフローチャート図である。 図１に示した動作抑制制御部１４から動作抑制要求を受けたモジュールの動作処理を示すフローチャート図である。 図１に示したプロジェクタ１が動作抑制を解除するときの処理を示すシーケンス図である。 図１に示した動作抑制制御部１４の動作抑制解除時の処理を示すフローチャート図である。 図１に示したプロジェクタ１の状態を表す遷移図である。 図１に示したプロジェクタ１の動作抑制対象のモジュールの状態を表す遷移図である。

図１に示したプロジェクタ１の動作抑制対象のモジュールが要求を受けた時の処理を示すフローチャート図である。 図１に示した動作抑制制御部１４が保持する動作抑制対象であるか否かについて示したテーブルの一例の図である。 図１に示したプロジェクタ１の動作抑制対象のモジュールが保持する動作抑制要求を受けた際に実行する処理内容について示したテーブルの一例の図である。 図１に示した動作抑制制御部１４が保持する動作抑制対象であるか否かと動作抑制の順番と動作抑制解除の順番について示したテーブルの一例の図である。 図１に示したプロジェクタ１が図１４のテーブルに基いて動作抑制をかけるときの処理を示すシーケンス図である。 図１に示した動作抑制制御部１４が保持する動作抑制対象であるか否かについてアクティブスタンバイと通常のスタンバイとで分けて保持する場合を示したテーブルの一例の図である。 図１の動作抑制対象のモジュールが保持するアクティブスタンバイと通常のスタンバイとで実行可否の機能について示したテーブルの一例の図である。 図１に示したプロジェクタ１がアクティブスタンバイ時に動作抑制をかけるときの処理を示すシーケンス図である。 図１に示したプロジェクタ１の動作抑制対象のモジュールが要求を受けた時の処理を示すフローチャート図である。 図１に示したプロジェクタ１の動作抑制対象のモジュールが要求を受け付けた際の他の処理例を示すフローチャート図である。

図１に示したプロジェクタ１の動作抑制対象のモジュールの持つ動作抑制中に各要求をどのように処理するかを示すテーブルの一例の図である。 図１に示したプロジェクタ１の動作抑制対象のモジュールにて動作抑制解除時に動作抑制中に受け付けた要求を全て実行する処理を示すフローチャート図である。 図１に示したプロジェクタ１の要求をキューに貯める際に同一の要求が来た場合には古い要求を取り除く処理を示すフローチャート図である。 この発明の他の実施形態である投影システムの構成例を示す図である。 図２４に示したアプリケーションコントローラ４５内の機能構成例を示すブロック図である。 図２４に示したＩ／Ｏコントローラ４６内の機能構成例を示すブロック図である。 図２５に示したＩ／Ｏジョブ管理部５９が保持するメッセージ種類につきキャンセル可能か否かを示す情報を登録したテーブルの一例を示す図である。 図２５に示したＩ／Ｏジョブ管理部５９が保持するジョブを管理するためのテーブルの一例を示す図である。 図２６に示した通信状態管理部６４が保持するスレッド状態管理テーブルの一例を示す図である。 図２４に示したプロジェクタ４０のジョブ生成までの処理例を示すシーケンス図である。

図２４に示したプロジェクタ４０のジョブ削除までの処理例を示すシーケンス図である。 図２４に示したプロジェクタ４０がキャンセルによってジョブ削除するまでの処理例を示すシーケンス図である。 図２５に示したＩ／Ｏ制御部５８とＩ／Ｏジョブ管理部５９における電源オフまでの処理を示すフローチャート図である。 図２６に示した通信制御部６３と通信状態管理部６４におけるキャンセル処理を示すフローチャート図である。 図２５に示したＩ／Ｏジョブ管理部５９が保持するジョブ状態におけるキャンセル可否を示すテーブルの一例の図である。 図２６に示した通信制御部６３が保持する通信スレッド用途と状態におけるキャンセル可否を示すテーブルの一例の図である。

以下、この発明を実施するための形態を図面に基づいて具体的に説明する。
図２は、この発明の一実施形態である投影システムの構成例を示す図である。
この投影システムは、処理装置の一例であるプロジェクタ１に、有線又は無線によるネットワーク３を介してパーソナルコンピュータ（ＰＣ）２を含む複数のＰＣが接続されており、プロジェクタ１とＰＣ２は互いにデータ通信可能である。なお、ＰＣ２の他のＰＣの図示を省略している。
プロジェクタ１は、映像投影装置（「画像投影装置」ともいう）であり、ＰＣ２から入力された投影データに基づく映像をスクリーン等の投影面に投影する。

ＰＣ２は、プロジェクタ１に映像データを送信する。
このように構成された投影システムは、ＰＣ２を含む複数のＰＣがプロジェクタ１を共有しており、プロジェクタ１に、ＰＣ２等の各ＰＣがそれぞれ保有する映像を投影させることができる。
なお、図２の投影システムの構成例は一例であり、さらに他の映像出力装置、又は外部ストレージを接続するようにすることもできる。
プロジェクタ１の内部で何らかの処理を実行している最中に、プロジェクタ１の電力状態をオン状態からスタンバイ状態に移行しようとした場合に、実行途中の処理があるままスタンバイに移行してしまうと、次回起動時に不具合が発生してしまう可能性がある。

上記スタンバイ状態とは、プロジェクタ１の内部の一部への給電を停止して電力消費を抑える省電力状態のことである。
このプロジェクタ１のスタンバイ状態には、「アクティブスタンバイ」と「通常のスタンバイ」の２種類がある。これらについては後に詳述する。
そこで、この実施形態のプロジェクタ１は、スタンバイ状態に移行する前に実行途中の処理がある状態でスタンバイに移行してしまうことを避けるために下記の動作抑制を行うことが特徴である。

（動作抑制）
１．スタンバイ移行の要求が来るより前に来ていた要求に対しては処理を終了させる。
２．スタンバイ移行の要求よりも後にきた要求は実行しない。
したがって、この実施形態のプロジェクタ１は、スタンバイ移行の際、外部からの要求を受け付けるモジュールに対して動作抑制をかけることにより、実行途中の処理がある状態でスタンバイに移行してしまうことを避けることができる。

このプロジェクタ１に対してユーザが要求を出すための方法として、プロジェクタ１に設けられた本体キー又はリモコン（いずれも図２では図示を省略）を用いたユーザ操作と、ネットワーク３経由でＰＣ２から操作する２つの方法がある。
以降の説明ではどちらから来た要求でも受け付けられる場合で説明していくが、どちらか一方しか無い場合であっても適用可能である。

次に、図１によってプロジェクタ１の内部の構成について説明する。
図１は、図２に示したプロジェクタ１の内部の構成例を示すブロック図である。
プロジェクタ１は、操作部４、制御部５、及び投影部６を備えている。
操作部４は、ユーザがプロジェクタ１に対して各種の操作情報を入力する部分であり、ユーザがプロジェクタ１に対して直接にスタンバイ要求も入力することができる。
投影部６は、ＰＣ２から送られる画像データ（「映像データ」ともいう）に基づく静止画、動画等の画像（「映像」ともいう）をスクリーン等の投影面に投影する。

制御部５は、ＣＰＵ，ＲＯＭ及びＲＡＭ等からなるマイクロコンピュータによって実現され、電力制御部１１、ユーザ操作受付部１２、ネットワーク通信部１３、動作抑制制御部１４、機能実行部１５〜１７の各機能部を備え、その各部は互いにシステムバス１８によって接続されている。
なお、この実施形態では、機能実行部１５〜１７の３つの機能部の例を示したが、さらに多くの機能部を備えても後述の処理を実施することができる。

システムバス１８は、電力制御部１１、ユーザ操作受付部１２、ネットワーク通信部１３、動作抑制制御部１４、機能実行部１５〜１７の各部間を接続し、その各部間のデータ通信を可能にする経路である。
電力制御部１１は、プロジェクタ１の電力源（図示を省略）から給電される電力を制御して電力状態の切り替えを行うモジュールである。この電力状態には、通常状態、スタンバイ状態等の複数種類の状態があり、それについては後に詳述する。
この電力制御部１１は、プロジェクタ１を省電力状態に移行させる制御と省電力状態から復帰させる制御をする電力制御手段の機能を果たす。

ユーザ操作受付部１２は、ユーザがプロジェクタ１を直接操作して送ってきた要求を受け付けるモジュールである。ここで受け付けたユーザからの要求に対する処理は機能実行部１５〜１７にて行う。
ネットワーク通信部１３は、ＰＣ２からネットワーク３経由で送られて来た要求を受け付けるモジュールである。ここで受けた要求に対する処理もユーザ操作受付部１２で受けた要求と同様に機能実行部１５〜１７にて実行される。

前述のユーザ操作受付部１２とネットワーク通信部１３は、処理要求を入力する複数の入力手段の機能を果たす。
また、ユーザ操作受付部１２とネットワーク通信部１３は、動作抑制制御部１４から動作抑制の要求を受けた場合、その動作抑制の要求前に受け付けた処理を全て終了してから、動作抑制制御部１４に動作抑制の応答を送る手段と、動作抑制制御部１４から上述の所定の動作抑制の要求を受け付けた後の動作抑制状態においても予め指定された処理の要求を受け付ける手段の機能も果たす。

さらに、ユーザ操作受付部１２とネットワーク通信部１３は、動作抑制制御部１４から上述の所定の動作抑制の要求を受け付けた後の動作抑制状態でも処理の要求を受け付け、その受け付けた処理の要求を蓄積し、動作抑制制御部１４から動作抑制の解除の要求を受けたとき、その蓄積された処理の要求に対応する処理を実行する手段と、前述の動作抑制状態のときに受け付けた処理の要求について、同一の処理要求を重複して蓄積しないように制御する手段の機能も果たす。

動作抑制制御部１４は、電力制御部１１からの動作抑制の要求を受けて動作抑制をかける必要のあるモジュールに対して動作抑制を要求するモジュールである。動作抑制を要求した全てのモジュールから動作抑制の完了の応答が返ってきたら、電力制御部１１に対して動作抑制が完了したので電力状態変更が可能であることを応答する。

この動作抑制制御部１４は、電力制御部１１によってプロジェクタ１を省電力状態に移行させる前に、ユーザ操作受付部１２，ネットワーク通信部１３及び機能実行部１５〜１７に対して所定の動作抑制を要求し、電力制御部１１によってプロジェクタ１を省電力状態から復帰させた場合にユーザ操作受付部１２，ネットワーク通信部１３及び機能実行部１５〜１７に対して動作抑制の解除を要求する制御をする動作抑制制御手段の機能を果たす。

また、動作抑制制御部１４は、ユーザ操作受付部１２，ネットワーク通信部１３及び機能実行部１５〜１７に対して所定の動作抑制の要求前に受け付けた処理は終了し、所定の動作抑制の要求の後に受け付けた処理は中止する動作抑制を要求する手段と、ユーザ操作受付部１２，ネットワーク通信部１３及び機能実行部１５〜１７に対して、予め記憶した順番で所定の動作抑制を要求する手段と、ユーザ操作受付部１２，ネットワーク通信部１３及び機能実行部１５〜１７に対して、予め記憶した順番で所定の動作抑制の解除を要求する手段と、予め指定されたユーザ操作受付部１２，ネットワーク通信部１３又は機能実行部１５〜１７に対して、所定の動作抑制を要求する手段の各機能も果たす。

機能実行部１５〜１７は、ユーザ操作やネットワーク３経由でプロジェクタ１に入ってきた要求に対する処理を実行するためのモジュール群である。
この機能実行部１５〜１７は、入力手段によって入力された処理要求に対応する処理を実行する複数の処理手段の機能を果たす。

次に、図３によってプロジェクタ１における電力状態と各状態の時に受け付けられる要求の各内容について説明する。
図３は、図１に示したプロジェクタ１の電力状態と各状態の時に受け付けられる要求の各内容について示したテーブルの一例の図である。
図３に示したテーブルは、例えば、図１の動作抑制制御部１４が記憶しており、プロジェクタ１の電力状態と各状態の時に受け付けられる要求の対応関係を示している。
電力状態「オン（ＯＮ）」というのは、プロジェクタ１の内部の全部に給電がされてプロジェクタ１が通常に動作している状態のことを表し、プロジェクタ１の全ての箇所に通電しているため、プロジェクタ１に入ってくる全ての要求を受け付ける事が可能である。

また、電力状態「スタンバイ」というのは、プロジェクタ１の内部の一部の給電を停止した状態である。このスタンバイ状態は、機能実行部１５〜１７、投影部６への給電を遮断した省電力状態である。一方、電力制御部１１には通電している状態である。また、機能実行部１５〜１７には通電していないため、電源オンの要求以外は受け付けることができない。そこで、電源オンの要求を受け付けるためにユーザ操作受付部１２又はネットワーク通信部１３の両方もしくはいずれか一方には通電している。
電力状態「オフ（ＯＦＦ）」というのはプロジェクタ１の主電源が入っていない（コンセントが刺さっていない）状態のことである。この電力状態ではプロジェクタ１のどこにも通電していないためいずれの要求も受け付けることができない。

この実施形態のプロジェクタ１では、電力状態が「オン」から「スタンバイ」に移行するときの動作抑制の実施および「スタンバイ」から「オン」に移行するときの動作抑制の解除の方法について説明する。
また、上記の３種類の電力状態以外に「アクティブスタンバイ」と呼ばれるような電力状態がある。
この電力状態ではスタンバイ状態よりも多くのデバイスに通電しているため、電源オン要求以外にもいくつかの要求に対して処理を行うことが可能である。

次に、図４によってプロジェクタ１が動作抑制をかけるときの処理について説明する。
図４は、図１に示したプロジェクタ１が動作抑制をかけるときの処理を示すシーケンス図である。図４中では、ステップを「Ｓ」と記載する。
この処理では、図１の機能実行部１５と１６の各モジュールに対して動作抑制をかける場合について説明する。
図１のユーザ操作受付部１２は、ユーザからのスタンバイ移行の要求を受けると、電力制御部１１に対してスタンバイ移行要求を送る（図４のＳ１）。

また、図４では図示を省略するが、図２のＰＣ２がネットワーク３を経由してプロジェクタ１へスタンバイ移行要求を出した場合、ネットワーク通信部１３から電力制御部１１にスタンバイ移行要求を送る。
次に、電力制御部１１は、動作抑制制御部１４に対してスタンバイ移行のための動作抑制要求を送る（Ｓ２）。
動作抑制制御部１４は、動作抑制の必要なモジュールに対して動作抑制要求を送る。ここでは、機能実行部１５と１６にそれぞれ動作抑制要求を送る（Ｓ３）。その動作抑制要求を受けた機能実行部１５と１６の動きは後述する。

一方、動作抑制要求を受け取った機能実行部１５と１６はそれぞれ自モジュールの動作抑制が完了すると、動作抑制制御部１４へ動作抑制が完了したことを示す動作抑制完了を送る（Ｓ４，Ｓ５）。
そして、動作抑制制御部１４は、機能実行部１５と１６からそれぞれ動作抑制完了の応答を受け取ると、電力制御部１１に対して動作抑制完了の応答を送る（Ｓ６）。本応答を受けた電力制御部１１は電力状態をスタンバイに移行するための処理を実行する。

次に、図５によって図１の動作抑制制御部１４の動作抑制時の処理について説明する。
図５は、図１に示した動作抑制制御部１４の動作抑制時の処理を示すフローチャート図である。この処理は、プロジェクタ１の電源オン状態のときに実行される。
ステップ（図中「Ｓ」で示す）１１で、電力制御部１１から動作抑制要求を受けるとステップ１２へ進む。
ステップ１２で、動作抑制の対象となる全てのモジュールに対して動作抑制要求を送り、ステップ１３へ進む。この場合の全てのモジュールは、機能実行部１５と１６である。
ステップ１３で、動作抑制要求を送った全てのモジュールからの動作抑制完了の応答を待ち、ステップ１４へ進む。

ステップ１４で、動作抑制要求を送ったモジュールから動作抑制完了の応答を受けると、ステップ１５へ進む。
ステップ１５で、全ての動作抑制対象のモジュールからの応答を受けたか否かを判断し、全てのモジュールから応答を受けていない場合（Ｎの場合）は動作抑制完了の応答待ちの処理（Ｓ１３）に戻り、全てのモジュールから応答を受けた場合（Ｙの場合）はステップ１６へ進む。
ステップ１６で、電力制御部１１に対して動作抑制完了の応答を送り、この処理を終了する。

次に、図６によって図１の動作抑制制御部１４から動作抑制要求を受けたモジュールの動作処理について説明する。
この処理では、動作抑制要求を受けたモジュールを機能実行部１５と１６にした場合を説明する。
図６は、図１に示した動作抑制制御部１４から動作抑制要求を受けたモジュールの動作処理を示すフローチャート図である。
機能実行部１５と１６は、それぞれステップ２１〜２９の処理を実行する。
ステップ（図中「Ｓ」で示す）２１で、動作抑制制御部１４からの動作抑制要求を受け取ると、ステップ２２へ進む。

ステップ２２で、以降の新規の要求を受け付けないように状態を変化させ、ステップ２３へ進む。
ステップ２３で、処理実行中の要求があるか否かを判断し、ある場合（Ｙの場合）はステップ２４へ進み、ない場合（Ｎの場合）はステップ２７へ進む。
ステップ２４で、実行中の処理を完了させるか否かを判断し、完了させる場合（Ｙの場合）はステップ２５へ進み、完了させない場合（Ｎの場合）はステップ２８へ進む。
ステップ２５で、実行中の処理を完了させて、ステップ２６へ進む。
一方、ステップ２８で、実行中の処理を中止して、ステップ２６へ進む。

上記ステップ２４の処理では、実行中の処理が時間のかかる処理である場合か否かを判断するものであり、時間がかからない処理の場合はステップ２５で処理を完了させ、時間がかかる処理の場合はステップ２８で要求をキャンセルするなどをして処理を中止する。
ステップ２６で、動作抑制要求を受け取る前に受け取った全ての要求が完了しているか否かを判断し、完了している場合（Ｙの場合）はステップ２７へ進み、完了していない場合（Ｎの場合）はステップ２９へ進む。
ステップ２７で、動作抑制制御部１４に対して動作抑制完了の応答を送り、処理を終了する。

ステップ２９で、次の要求を実行し、ステップ２４の処理へ戻る。
上記ステップ２６の処理では、動作抑制要求を受け付ける前に自モジュールが受け取った要求を全て実行したかどうかを判断し、まだ未処理の要求が残っている場合は完了／中止した要求の次に来た要求の処理を実行する（ステップ２９）。また、残っていない場合はステップ２７へ進む。

次に、図７によってプロジェクタ１が動作抑制を解除するときの処理について説明する。
図７は、図１に示したプロジェクタ１が動作抑制を解除するときの処理を示すシーケンス図である。図７中では、ステップを「Ｓ」と記載する。
この処理では、機能実行部１５と１６が動作抑制中の動作抑制解除について説明する。
図１のユーザ操作受付部１２は、ユーザからの電源オン（ＯＮ）要求を受けると、電力制御部１１に対して電源オン要求を送る（Ｓ３１）。

また、図７では図示を省略するが、図２のＰＣ２がネットワーク３を経由してプロジェクタ１へ電源オン要求を出した場合、ネットワーク通信部１３から電力制御部１１に電源オン要求を送る。
次に、電力制御部１１は、電力状態をオンに移行するための処理が完了した後に、動作抑制制御部１４に対して動作抑制解除要求を送る（Ｓ３２）。
動作抑制制御部１４は、動作抑制をかけている全てのモジュールに対して動作抑制解除要求を送る（Ｓ３３）。ここでは、機能実行部１５と１６にそれぞれ送る。

一方、動作抑制制御部１４から動作抑制解除要求を受けた機能実行部１５と１６は、それぞれ自モジュールの状態を遷移させて、動作抑制の解除を完了すると、動作抑制制御部１４へ動作抑制解除完了を送る（Ｓ３４，Ｓ３５）。機能実行部１５と１６の各モジュールの状態については後述する。
そして、動作抑制制御部１４は、機能実行部１５と１６からそれぞれ動作抑制解除完了の応答を受け取ると、電力制御部１１に対して動作抑制解除完了の応答を送る（Ｓ３６）。

次に、図８によって図１の動作抑制制御部１４の動作抑制解除時の処理について説明する。
図８は、図１に示した動作抑制制御部１４の動作抑制解除時の処理を示すフローチャート図である。この処理では、機能実行部１５と１６が動作抑制中の動作抑制解除について説明する。この処理は、プロジェクタ１の電源オン状態のときに実行される。
ステップ（図中「Ｓ」で示す）４１で、電力制御部１１から動作抑制解除要求を受けると、ステップ４２へ進む。

ステップ４２で、動作抑制解除対象の全てのモジュールに動作抑制解除要求を送り、ステップ４３へ進む。この場合の全てのモジュールは、機能実行部１５と１６である。
ステップ４３で、動作抑制解除要求を送った全てのモジュールからの動作抑制解除完了の応答を待ち、ステップ４４へ進む。
ステップ４４で、動作抑制解除要求を送ったモジュールから動作抑制解除完了の応答を受けると、ステップ４５へ進む。

ステップ４５で、全ての動作抑制解除対象のモジュールからの応答を受けたか否かを判断し、全てのモジュールから応答を受けた場合（Ｙの場合）はステップ４６へ進み、全てのモジュールから応答を受けていない場合（Ｎの場合）はステップ４３の処理へ戻る。
ステップ４６で、電力制御部１１に対して動作抑制解除完了の応答を送り、この処理を終了する。

次に、図９によってプロジェクタ１の状態について説明する。
図９は、図１に示したプロジェクタ１の状態を表す遷移図である。
動作抑制制御部１４は、プロジェクタ１の状態について、図９に示す２０〜２３の各状態に変化したことの情報を保持する。
動作抑制制御部１４は、電源オンの時に、プロジェクタ１は２０で示す通常の状態とし、電力制御部１１から動作抑制要求を受けると、プロジェクタ１の状態を２１で示す動作抑制移行中の状態に変化させる。

さらに、全ての動作抑制対象のモジュール（例えば、機能実行部１５と１６）からの動作抑制完了の応答を受けると、プロジェクタ１の状態を２２で示す動作抑制中の状態に変化させる。
次に、動作抑制制御部１４は、プロジェクタ１が動作抑制中の時に、電力制御部１１から動作抑制解除要求を受けると、プロジェクタ１の状態を２３で示す動作抑制解除中の状態に変化させる。
そして、全ての動作抑制解除対象のモジュール（例えば、機能実行部１５と１６）からの動作抑制解除完了の応答を受けると、プロジェクタ１の状態を２０で示す通常の状態に変化させる。

次に、図１０によってプロジェクタ１の動作抑制対象のモジュールの状態について説明する。
図１０は、図１に示したプロジェクタ１の動作抑制対象のモジュールの状態を表す遷移図である。
ここでは、例えば、動作抑制対象のモジュールが機能実行部１５と１６の場合を説明する。

機能実行部１５と１６は、自モジュールの状態について、図１０に示す３０，３１の各状態に変化したことの情報を保持する。
電源オンの状態で通常に動いている場合は３０で示すオンの状態を保持し、動作抑制制御部１４からスタンバイ移行時の動作抑制要求を受けると、３１で示すスタンバイ中の状態に変化させる。また、スタンバイ中の状態のときに動作抑制制御部１４から動作抑制解除要求を受けると、３０で示すオンの状態に戻す。

次に、動作抑制対象のモジュールが処理要求を受けた時の処理について説明する。
図１１は、図１に示したプロジェクタ１の動作抑制対象のモジュールが要求を受けた時の処理を示すフローチャート図である。この処理では、動作抑制対象のモジュールが機能実行部１５と１６の場合を説明する。
機能実行部１５と１６は、ステップ（図中「Ｓ」で示す）５１で、処理要求を受けると、ステップ５２で、オン状態であるか否かを判断し、オン状態の場合（Ｙの場合）はステップ５３へ進み、オン状態でない場合（Ｎの場合）はこの処理を終了する。

ステップ５３で、要求を受けた処理を実行し、この処理を終了する。
ステップ５２の処理では、自モジュールの状態がオン状態、すなわち「通常」である場合は要求に対する処理を実行する（ステップ５３）。オン状態ではない場合、すなわち「動作抑制中」の場合は何もせず処理を終了する。

次に、図１２によって図１の動作抑制制御部１４が保持する動作抑制対象であるか否かについて示したテーブルについて説明する。
ここでは、機能実行部１５〜１７の動作抑制対象であるか否かについて説明する。
図１２は、図１に示した動作抑制制御部１４が保持する動作抑制対象であるか否かについて示したテーブルの一例の図である。
動作抑制制御部１４は、図１２に示すテーブルを予め記憶して保持することにより、そのテーブルを参照して機能実行部１５〜１７の各モジュールが動作抑制対象であるか否かを識別することができる。

図１２のテーブルには、機能実行部１５と１６は動作抑制対象であることを示す「イエス」の情報と、機能実行部１７は動作抑制対象ではないことを示す「ノー」の情報がそれぞれ記録されている。
これにより、動作抑制制御部１４は、動作抑制対象である全てのモジュールに対して動作抑制要求を送ることができる。

次に、図１３によって図１の動作抑制対象のモジュールが保持する動作抑制要求を受けた際に実行する処理内容について示したテーブルについて説明する。
図１３は、図１に示したプロジェクタ１の動作抑制対象のモジュールが保持する動作抑制要求を受けた際に実行する処理内容について示したテーブルの一例の図である。
ここでは、例えば、機能実行部１５が保持するテーブルを説明する。

機能実行部１５は、図１３に示したテーブルを予め記憶して保持することにより、自モジュールに対して動作抑制要求を受けたとき、図１３のテーブルを参照し、機能Ａ、機能Ｃ又は機能Ｄを実行している場合はその実行中の機能を完了して、その後の要求を動作抑制を解除するまで実行しないように動作抑制する。
また、自モジュールに対して動作抑制要求を受けたとき、図１３のテーブルを参照し、機能Ｂを実行している場合はその実行中の機能Ｂを中止して、その後の要求を動作抑制を解除するまで実行しないように動作抑制する。

次に、図１４によって図１の動作抑制制御部１４が保持する動作抑制対象であるか否かと動作抑制の順番と動作抑制解除の順番について示したテーブルについて説明する。
ここでは、ユーザ操作受付部１２、ネットワーク通信部１３、機能実行部１５〜１７の動作抑制対象であるか否かと動作抑制の順番と動作抑制解除の順番について説明する。
図１４は、図１に示した動作抑制制御部１４が保持する動作抑制対象であるか否かと動作抑制の順番と動作抑制解除の順番について示したテーブルの一例の図である。
動作抑制をかけるモジュール間に依存があり、あるモジュールに動作抑制をかけた後でないと動作抑制をかけられないモジュールが存在することも考えられる。

そのような場合は、動作抑制制御部１４の持つ動作抑制対象の可否を表すテーブルに「動作抑制の順番」の情報を加えて持たせるようにする。
動作抑制制御部１４は、「動作抑制の順番」の値が同じモジュールに対しては同時に動作抑制要求を送信し、送信した全てのモジュールから動作抑制完了の応答が返ってきたら、次の順番のモジュールに対して動作抑制を要求するものとする。
例えば、動作抑制制御部１４は、図１４のテーブル内の動作抑制の順番によれば、まず、ユーザ操作受付部１２とネットワーク通信部１３に対しては同時に動作抑制要求を送信し、ユーザ操作受付部１２とネットワーク通信部１３から動作抑制完了の応答が返ってきたら、次の順番の機能実行部１５に対して動作抑制を要求する。

さらに、動作抑制の解除についても順番性を守る必要がある場合には、「動作抑制解除の順番」の情報も加えて持たせるようにする。
動作抑制制御部１４は、「動作抑制解除の順番」の値が同じモジュールに対しては同時に動作抑制解除の要求を送信し、送信した全てのモジュールから動作抑制解除完了の応答が返ってきたら、次の順番のモジュールに対して動作抑制解除を要求するものとする。

例えば、動作抑制制御部１４は、図１４のテーブル内の動作抑制解除の順番によれば、まず、機能実行部１５に対して動作抑制解除の要求を送信し、機能実行部１５から動作抑制解除完了の応答が返ってきたら、次の順番のネットワーク通信部１３に対して動作抑制解除の要求を送信し、ネットワーク通信部１３から動作抑制解除完了の応答が返ってきたら、次の順番のユーザ操作受付部１２に対して動作抑制解除の要求を送る。

次に、図１５によってプロジェクタ１が図１４のテーブルに基いて動作抑制をかけるときの処理について説明する。
図１５は、図１に示したプロジェクタ１が図１４のテーブルに基いて動作抑制をかけるときの処理を示すシーケンス図である。図１５中では、ステップを「Ｓ」と記載する。
この処理は、プロジェクタ１の電源オン状態のときに実行される。
図１のユーザ操作受付部１２は、ユーザからのスタンバイ移行の要求を受けると、電力制御部１１に対してスタンバイ移行要求を送る（図１５のＳ６１）。
また、図１５では図示を省略するが、図２のＰＣ２がネットワーク３を経由してプロジェクタ１へスタンバイ移行要求を出した場合、ネットワーク通信部１３から電力制御部１１にスタンバイ移行要求を送る。

次に、電力制御部１１は、動作抑制制御部１４に対してスタンバイ移行のための動作抑制要求を送る（Ｓ６２）。
動作抑制制御部１４は、図１４のテーブルを参照し、動作抑制の必要なモジュールに対して動作抑制要求を送る。ここでは、ユーザ操作受付部１２とネットワーク通信部１３と機能実行部１５にそれぞれ動作抑制要求を送るが、それぞれの動作抑制の順番に基いて、まず、ユーザ操作受付部１２とネットワーク通信部１３に同時に動作抑制要求を送る（Ｓ６３）。

一方、動作抑制要求を受け取ったユーザ操作受付部１２とネットワーク通信部１３はそれぞれ自モジュールの動作抑制が完了すると、動作抑制制御部１４へ動作抑制が完了したことを示す動作抑制完了を送る（Ｓ６４，Ｓ６５）。
そして、動作抑制制御部１４は、ユーザ操作受付部１２とネットワーク通信部１３からそれぞれ動作抑制完了の応答を受け取ると、次の動作抑制の順番に基いて、機能実行部１５に動作抑制要求を送る（Ｓ６６）。動作抑制要求を受け取った機能実行部１５は自モジュールの動作抑制が完了すると、動作抑制制御部１４へ動作抑制が完了したことを示す動作抑制完了を送る（Ｓ６７）。

動作抑制制御部１４は、機能実行部１５から動作抑制完了の応答を受け取ると、電力制御部１１に対して動作抑制完了の応答を送る（Ｓ６８）。
そして、本応答を受けた電力制御部１１は電力状態をスタンバイに移行するための処理を実行する。
このようにして、各モジュールについて動作抑制をかけるのに順番を守る必要がある場合に、順番性を守ることができるようになる。

次に、このプロジェクタ１の電力状態には、「アクティブスタンバイ」と「通常のスタンバイ」という２つのスタンバイ状態がある。
そこで、図１の動作抑制制御部１４が保持する動作抑制対象の可否について示したテーブルについて、「アクティブスタンバイ」と「通常のスタンバイ」とを分けて保持するようにすれば、動作抑制制御部１４は、動作抑制対象である全てのモジュールに対して動作抑制要求を送ることができる。

次に、図１６によって図１の動作抑制制御部１４が保持する動作抑制対象であるか否かについてアクティブスタンバイと通常のスタンバイとで分けて保持する場合のテーブルについて説明する。ここでは、機能実行部１５〜１７の動作抑制対象であるか否かについて説明する。
図１６は、図１に示した動作抑制制御部１４が保持する動作抑制対象であるか否かについてアクティブスタンバイと通常のスタンバイとで分けて保持する場合を示したテーブルの一例の図である。図１６には、通常のスタンバイについて「スタンバイ」と記載する。

動作抑制制御部１４は、図１６に示すテーブルを予め記憶して保持することにより、そのテーブルを参照して、アクティブスタンバイと通常のスタンバイとで機能実行部１５〜１７の各モジュールが動作抑制対象であるか否かを識別することができる。
図１６のテーブルには、アクティブスタンバイでは、機能実行部１５は動作抑制対象であることを示す「イエス」の情報が、機能実行部１６と１７は動作抑制対象ではないことを示す「ノー」の情報がそれぞれ記録されている。

また、通常のスタンバイでは、機能実行部１５と１６は動作抑制対象であることを示す「イエス」の情報が、機能実行部１７は動作抑制対象ではないことを示す「ノー」の情報がそれぞれ記録されている。
これにより、動作抑制制御部１４は、アクティブスタンバイでも通常のスタンバイでも、動作抑制対象である全てのモジュールに対して動作抑制要求を送ることができる。
そして、動作抑制制御部１４は、これらのどちらのスタンバイ状態に電力状態が移行しようとしているのかによってどのモジュールに対して動作抑制要求を送るか否かを変えることができる。

次に、図１７によって図１の動作抑制対象であるモジュールが保持するアクティブスタンバイと通常のスタンバイとで実行可否の機能について示したテーブルを説明する。
図１７は、図１の動作抑制対象のモジュールが保持するアクティブスタンバイと通常のスタンバイとで実行可否の機能について示したテーブルの一例の図である。図１７には、通常のスタンバイについて「スタンバイ」と記載する。

ここでは、例えば、機能実行部１５が保持するテーブルを説明する。
機能実行部１５は、図１７に示したテーブルを予め記憶して保持することにより、このテーブルを参照し、アクティブスタンバイのときは、機能Ａ及び機能Ｂの実行は可能であり、機能Ｃ及び機能Ｄの実行は不可であると判断することができる。
また、通常のスタンバイのときは、機能Ａ〜機能Ｄの実行は不可であると判断することができる。

次に、図１８によってプロジェクタ１がアクティブスタンバイ時に動作抑制をかけるときの処理について説明する。
図１８は、図１に示したプロジェクタ１がアクティブスタンバイ時に動作抑制をかけるときの処理を示すシーケンス図である。図１８中では、ステップを「Ｓ」と記載する。
この処理は、プロジェクタ１の電源オン状態のときに実行される。
この処理では、図１の機能実行部１５のモジュールに対して動作抑制をかける場合について説明する。
図１のユーザ操作受付部１２は、ユーザからのアクティブスタンバイ移行の要求を受けると、電力制御部１１に対してスタンバイ移行要求を送る（図１８のＳ７１）。

ユーザ操作受付部１２から電力制御部１１に対するスタンバイ移行要求にアクティブスタンバイと通常のスタンバイのどの電力状態に移行すればよいかの情報が付与されてくるので、その情報に基づいて判断する。
なお、ユーザ操作受付部１２から電力制御部１１に対する要求は、電力制御部１１にて設定値などを読むことによりどの電力状態に移行するかを判断しても良い。
また、図１８では図示を省略するが、図２のＰＣ２がネットワーク３を経由してプロジェクタ１へスタンバイ移行要求を出した場合、ネットワーク通信部１３から電力制御部１１にスタンバイ移行要求を送る。

次に、電力制御部１１は、動作抑制制御部１４に対してアクティブスタンバイ移行のための動作抑制要求を送る（Ｓ７２）。
動作抑制制御部１４は、図１６のテーブルを参照し、動作抑制の対象を判断する（Ｓ７３）。
そして、動作抑制の必要なモジュールに対して動作抑制要求を送る。ここでは、機能実行部１５に動作抑制要求を送る（Ｓ７４）。

一方、動作抑制要求を受け取った機能実行部１５は自モジュールの動作抑制が完了すると、動作抑制制御部１４へ動作抑制が完了したことを示す動作抑制完了を送る（Ｓ７５）。
そして、動作抑制制御部１４は、機能実行部１５から動作抑制完了の応答を受け取ると、電力制御部１１に対して動作抑制完了の応答を送る（Ｓ７６）。本応答を受けた電力制御部１１は電力状態をアクティブスタンバイに移行するための処理を実行する。

また、動作抑制要求を受けたモジュールはプロジェクタ１がどの電力状態にあるかを知ることができ、図１７のテーブルの情報を使って自モジュールがどの機能を実行できるのかを判断することができる。
この場合、機能実行部１５は、図１７のテーブルを参照し、アクティブスタンバイでは、機能Ａと機能Ｂが実行可能であり、機能Ｃと機能Ｄの実行が不可であることを判断できる。

次に、動作抑制対象のモジュールが処理要求を受けた時の処理について説明する。
図１９は、図１に示したプロジェクタ１の動作抑制対象のモジュールが要求を受けた時の処理を示すフローチャート図である。この処理では、動作抑制対象のモジュールが機能実行部１５と１６の場合を説明する。
この処理は、プロジェクタ１の電源オン状態のときに実行される。
機能実行部１５と１６は、ステップ（図中「Ｓ」で示す）８１で、処理要求を受けると、ステップ８２で、実行可能な要求であるか否かを判断し、実行可能な要求の場合（Ｙの場合）はステップ８３へ進み、実行可能な要求ではない場合（Ｎの場合）はこの処理を終了する。

ステップ８３では、要求された処理を実行し、この処理を終了する。
ステップ８２の処理では、現在の状態で自モジュールで実行可能な要求の場合は要求に対する処理を実行する（ステップ８３）。一方、現在の状態で自モジュールで実行不可の要求の場合は何もせず処理を終了する。

次に、図２０によって要求をキューに貯めることを追加した動作抑制対象のモジュールが要求を受け付けた際の処理について説明する。
図２０は、図１に示したプロジェクタ１の動作抑制対象のモジュールが要求を受け付けた際の他の処理例を示すフローチャート図である。
この処理は、プロジェクタ１の電源オン状態のときに実行される。
ここでは、例えば、図１の機能実行部１５の処理について説明する。

機能実行部１５は、図２０のステップ（図中「Ｓ」で示す）９１で、処理要求を受けると、ステップ９２で、受け付けた処理要求は現在の（自モジュールの）状態でどのような処理にすべきか否かを判断し、実行すると判断した場合はステップ９３へ進み、キューに貯めると判断した場合はステップ９４へ進み、無視すると判断した場合はこの処理を終了する。
ステップ９３では、要求を受けた処理を実行し、この処理を終了する。
ステップ９４では、処理要求をキューに貯めて、この処理を終了する。

動作抑制対象のモジュールが要求を受けたときに、前述していたように「実行する」か「無視する」の２種類の方法しかなかった場合、動作抑制中には実行することができないが、動作抑制が解除されたタイミングでは実行して欲しいような要求がある場合に要求元が再度要求を出さなくてはならない。
それを避けるために、図２０に示した処理では、動作抑制対象のモジュールは「要求をキューに貯めておく」ということを実施する。

なお、要求を貯めておくデータ構造としてここでは一般的なキューというものを用いて説明しているがどのデータ構造を使って実現しても問題ない。
また、動作抑制対象のモジュールが各要求をどのように処理すべきかの判断方法と動作抑制解除時のキューに貯まった要求を処理するフローについては後述する。

次に、動作抑制対象のモジュールでは動作抑制中に各要求に対して実行して良いか、キューに貯めておいて後で実行するか、無視するかの３通りの対応方法を取る。
どの機能に対する要求に対してどの対応方法を取るかは各モジュール毎にテーブル形式で保持するとよい。
図２１は、図１に示したプロジェクタ１の動作抑制対象のモジュールの持つ動作抑制中に各要求をどのように処理するかを示すテーブルの一例の図である。

ここでは、例えば、機能実行部１５の処理を説明する。
機能実行部１５は、図２１に示したテーブルを予め記憶して保持することにより、このテーブルを参照し、アクティブスタンバイのときは、機能Ａは実行し、機能Ｂ及び機能Ｃは要求をキューに貯め、機能Ｄは実行要求を無視して実行しない。
また、通常のスタンバイのときは、機能Ａ〜機能Ｄの実行要求を無視して実行しない。

次に、図２２によって動作抑制対象のモジュールにて動作抑制解除時に動作抑制中に受け付けた要求を全て実行する処理について説明する。
図２２は、図１に示したプロジェクタ１の動作抑制対象のモジュールにて動作抑制解除時に動作抑制中に受け付けた要求を全て実行する処理を示すフローチャート図である。
ここでは、例えば、機能実行部１５の処理を説明する。
この処理は、プロジェクタ１の電源オン状態のときに実行される。

機能実行部１５は、図２２のステップ（図中「Ｓ」で示す）１０１で、動作抑制解除要求を受けると、ステップ１０２で以降の要求を受け付けられるように（自モジュールの）状態を変化させ、ステップ１０３で、動作抑制解除完了の応答を送り、ステップ１０４で、動作抑制中にキューに貯めていた要求があるか否かを判断し、ある場合（Ｙの場合）はステップ１０５でキューに貯まっている要求を全て処理し、この処理を終了する。
一方、ステップ１０４の判断で、動作抑制中にキューに貯めていた要求がない場合（Ｎの場合）はこの処理を終了する。
このようにして、動作抑制制御部１４に対して応答を返した後でキューに貯まっていた処理を実行するので、処理要求を残さずに済む。

次に、図２３によって要求をキューに貯める際に同一の要求が来た場合には古い要求を取り除く処理について説明する。
図２３は、図１に示したプロジェクタ１の要求をキューに貯める際に同一の要求が来た場合には古い要求を取り除く処理を示すフローチャート図である。
ここでは、例えば、機能実行部１５の処理を説明する。
この処理は、プロジェクタ１の電源オン状態のときに実行され、図２０のステップ９４に変えて実行される。

図２３のステップ（図中「Ｓ」で示す）１１１で、キューの中に同一の要求があるか否かを判断し、ある場合（Ｙの場合）はステップ１１２で、キューに入っていた同一の要求を削除し、ステップ１１３で今回の要求をキューに貯めて、この処理を終了する。
一方、ステップ１１１の判断で、キューの中に同一の要求がない場合（Ｎの場合）はステップ１１３で、今回の要求をキューに貯めて、この処理を終了する。
このようにして、同一のキューを重複して貯めずに済む。

この実施形態のプロジェクタ１によれば、スタンバイ移行の要求を受けた際に、外部からの要求を受け付けるモジュールに対して動作抑制をかけて、新規で入ってきた要求を受け付けないようにするので、要求に対する処理の実行が完了していない状態でスタンバイに移行してしまうことを防ぐことができる。
また、スタンバイ移行が要求された後に要求された処理を実行せずに素早くスタンバイ状態に移行することができる。
さらに、スタンバイ移行要求よりも前に受けた要求に対する処理を実行してからスタンバイ状態に移行することができる。

また、依存関係のあるようなモジュール（例：図１のネットワーク通信部１３と機能実行部１５〜１７）に対して、利用する側のモジュールから先に動作抑制をかけることができる。
さらに、依存関係のあるようなモジュール（例：図１のネットワーク通信部１３と機能実行部１５〜１７）に対して、利用される側のモジュールから先に動作抑制を解除していくことができる。
また、必要最小限のモジュールに対してのみ動作抑制要求を出すことで素早く電力状態を移行することができる。

さらに、動作抑制中であっても実行できる機能がある場合に実行することができる。
また、動作抑制中に、動作抑制解除後にユーザから再度要求してもらう必要がなくなる。
さらに、動作抑制中に貯めている要求と同一の要求が来た場合に、後から来た要求のみを実行するようにすることで、無駄に同一の処理を２回実行してしまうことで、貯まっている処理を実行するのにかかる時間を短くすることができる。

次に、この発明の他の実施形態を説明する。
図２４は、この発明の他の実施形態である投影システムの構成例を示す図である。
この投影システムは、処理装置の一例であるプロジェクタ４０に、有線又は無線によるネットワーク４２を介してパーソナルコンピュータ（ＰＣ）４１を含む複数のＰＣが接続されており、プロジェクタ４０とＰＣ４１は互いにデータ通信可能である。なお、ＰＣ４１の他のＰＣの図示を省略している。
プロジェクタ４０は、映像投影装置（「画像投影装置」ともいう）であり、ＰＣ４１から入力された投影データに基づく映像をスクリーン等の投影面に投影する。

プロジェクタ４０は、操作部４３、投影部４４、アプリケーションコントローラ４５、及びインプットアウトプット（Ｉ／Ｏ）コントローラ４６を備えている。
操作部４３は、ハードキー、リモコン受光部などを備え、ユーザがプロジェクタ４０に対して各種の操作情報を入力する部分である。
投影部４４は、ＰＣ４１から送られる画像データ（「映像データ」ともいう）に基づく静止画、動画等の画像（「映像」ともいう）をスクリーン等の投影面に投影する。

アプリケーションコントローラ４５は、ＣＰＵ、ＲＯＭ及びＲＡＭ等のマイクロコンピュータを備え、Ｉ／Ｏコントローラ４６から受けたデータを加工して投影部４４に渡すためのデータに変換するなどのアプリケーション的処理を行う。
Ｉ／Ｏコントローラ４６は、同じくＣＰＵ、ＲＯＭ及びＲＡＭ等のマイクロコンピュータを備え、ネットワーク４２との入出力処理を行う。
このアプリケーションコントローラ４５とＩ／Ｏコントローラ４６は、それぞれ異なる処理チップで実現され、それぞれ協調処理を行う。
ＰＣ４１は、プロジェクタ４０に映像データを送信する。

図２５は、図２４に示したアプリケーションコントローラ４５内の機能構成例を示すブロック図である。
アプリケーションコントローラ４５は、マイクロコンピュータによって実現される機能部である、グラフィックドライバ部５０、操作制御部５１、ユーザインタフェース（ＵＩ）画面制御部５２、電力制御部５３、画像デコーダ部５４、画像ファイル取得部５５、画像ファイル受付部５６、設定制御部５７、Ｉ／Ｏ制御部５８、Ｉ／Ｏジョブ管理部５９、コントローラ間接続制御部６０を備えている。
グラフィックドライバ部５０は、投影部４４へ投影データを渡して投影させる。

操作制御部５１は、操作部４３からの入力を受け付ける。
ＵＩ画面制御部５２は、操作制御部５１からの入力に応じてＵＩ画面を生成して表示させる。
電力制御部５３は、ＵＩ操作に応じてアプリケーションコントローラ４５の電源オンと電源オフを制御する。すなわち、電力制御部５３は、アプリケーションコントローラ４５の電力状態を制御する。
画像デコーダ部５４は、画像データのデコードを行い、投影できるバイト列に変換する。

画像ファイル取得部５５は、ネットワーク４２に接続されたＰＣ４１又は図示を省略したサーバにアクセスして画像ファイルを取得する。
画像ファイル受付部５６は、ネットワーク４２に接続されたＰＣ４１などから送信されてきた画像ファイルを受け付ける。
設定制御部５７は、プロジェクタ４０における各種設定値の設定と取得を行う。
Ｉ／Ｏ制御部５８は、画像ファイル取得部５５、画像ファイル受付部５６から依頼を受け、コントローラ間接続制御部６０へメッセージを渡したり受け取ったりすることでＩ／Ｏコントローラ４６への要求と応答を行う。

また、Ｉ／Ｏ制御部５８は、電力制御部５３から電源オフを指示された際、Ｉ／Ｏジョブ管理部５９が管理するジョブについて処理完了を待機し、仕掛中のジョブが無くなった時点で電源オフに移行できるように制御する。
さらに、Ｉ／Ｏ制御部５８は、電力制御部５３から電源オフを指示された際、Ｉ／Ｏジョブ管理部５９が管理するジョブについてキャンセルを行い、仕掛中のジョブが無くなった時点で電源オフに移行できるように制御もする。

また、Ｉ／Ｏ制御部５８は、電力制御部５３から電源オフを指示された際、キャンセル可能なものはキャンセルを行い、そうでないものはキャンセルせず処理完了を待機し、仕掛中のジョブが無くなった時点で電源オフに移行できるようにする制御もする。
さらに、Ｉ／Ｏ制御部５８は、ネットワーク送受信に関する処理をキャンセル可能とし、それ以外をキャンセルせず処理完了を待機する制御もする。
また、Ｉ／Ｏ制御部５８は、ジョブのキャンセルを行う際に、ジョブ情報に保持されている通信スレッドの情報をＩ／Ｏコントローラ４６に送信する制御もする。

Ｉ／Ｏジョブ管理部５９は、Ｉ／Ｏ制御部５８が仕掛中のジョブ状態を記憶して管理する。
また、Ｉ／Ｏジョブ管理部５９はジョブの種類毎にキャンセルの可否も保持している。
さらに、Ｉ／Ｏジョブ管理部５９は、ジョブ情報として利用している通信スレッドの情報も保持している。
また、Ｉ／Ｏジョブ管理部５９は、ジョブの種類毎にキャンセル可能な状態の情報を保持し、キャンセルを行う際にその時点でのジョブの状態と照らし合わせてキャンセル可否を判定する処理も行う。
コントローラ間接続制御部６０は、Ｉ／Ｏコントローラ４６とのメッセージ等のデータ送受信をする。

図２６は、図２４に示したＩ／Ｏコントローラ４６内の機能構成例を示すブロック図である。
Ｉ／Ｏコントローラ４６は、マイクロコンピュータによって実現される機能部である、コントローラ間接続制御部６１、機能実行部６２、通信制御部６３、通信状態管理部６４、ネットワーク接続制御部６５を備えている。
コントローラ間接続制御部６１は、図２５のコントローラ間接続制御部６０との間でアプリケーションコントローラ４５とのメッセージ等のデータの送受信をする。

機能実行部６２は、複数の処理部を有し、それぞれアプリケーションコントローラ４５から渡されるメッセージに応じて実際の処理を行う。すなわち、アプリケーションコントローラ４５から依頼された処理を行う。
通信制御部６３は、ネットワーク接続制御部６５を用いてネットワーク４２へのアクセスを行い、ネットワーク接続制御部６５を介してネットワーク送受信を制御する。
また、通信制御部６３は、その送信された通信スレッドの通信を対象としてキャンセル処理の制御もする。

さらに、通信制御部６３は、ネットワーク処理のキャンセルを要求された際、キャンセル可能な場合はキャンセルを実行し、そうでない場合はキャンセルせずに処理終了を待機する制御もする。
通信状態管理部６４は、通信制御部６３が行っているネットワーク４２との通信状態の情報を記憶して管理する。
また、通信状態管理部６４は、ネットワーク通信に用いる通信スレッドの状態も記憶して管理している。その通信用に割り当てられているスレッドについては、各スレッドの通信状態がどのようになっているかを保持している。

さらに、通信状態管理部６４は、個別のネットワーク処理がキャンセル可能か否かの情報も保持し、通信スレッドの用途・状態毎にキャンセル可能か否かの情報を保持し、キャンセルを行う際にその時点での通信スレッドの用途・状態と照らし合わせてキャンセル可否を判定する処理も行う。
ネットワーク接続制御部６５は、図２４に示すプロジェクタ４０の外部のネットワーク４２との接続を制御する。

図２５の操作制御部５１と図２６のネットワーク接続制御部６５が、上述の入力手段の機能を果たす。
また、図２６の機能実行部６２が、上述の処理手段の機能を果たす。
さらに、図２５の電力制御部５３が、上述の電力制御手段の機能を果たす。
さらにまた、図２５のＩ／Ｏ制御部５８が、上述の動作抑制制御手段の機能を果たす。

次に、図２７によって図２５のＩ／Ｏジョブ管理部５９が記憶して保持するテーブルについて説明する。
図２７は、図２５に示したＩ／Ｏジョブ管理部５９が保持するメッセージ種類につきキャンセル可能か否かを示す情報を登録したテーブルの一例を示す図である。
Ｉ／Ｏジョブ管理部５９は、図２７に示したテーブルを予め記憶している。
このテーブルには、メッセージ種類毎のメッセージ内容とキャンセル可否を登録している。

メッセージ種類は、Ｉ／Ｏコントローラ４６におけるメッセージ種類を示す識別情報（ＩＤ）である。
また、メッセージ内容は、メッセージ種類毎にＩ／Ｏコントローラ４６で行われる処理内容を示す情報である。
さらに、キャンセル可否は、メッセージが途中で処理を中断できるか否かを示す情報である。
Ｉ／Ｏジョブ管理部５９は、このテーブルを参照することによって、ジョブが示すメッセージ種類毎にキャンセル可能か否かを判定することができる。

図２８は、図２５に示したＩ／Ｏジョブ管理部５９が保持するジョブを管理するためのテーブルの一例を示す図である。
Ｉ／Ｏジョブ管理部５９は、図２８に示したテーブルも予め記憶している。
このテーブルには、メッセージ種類毎のスレッドＩＤとジョブ状態とレシーバを登録している。
メッセージ種類は、Ｉ／Ｏコントローラ４６におけるメッセージ種類を示す識別情報（ＩＤ）である。

また、スレッドＩＤは、ジョブがＩ／Ｏコントローラ４６のどのスレッドで実行されているかを示す識別情報である。ジョブを開始する際及びキャンセルする際はこのスレッドＩＤを指定する必要がある。
さらに、ジョブ状態は、ジョブが現在何の状態にあるか、例えば、Ｉ／Ｏコントローラ４６に要求を送信中なのか、Ｉ／Ｏコントローラ４６からの応答待ちなのか、といった内容を示す情報である。
さらにまた、レシーバは、ジョブの入出力先の機能部を示す情報である。

図２８のテーブルでは、レシーバの候補として、図２５の設定制御部５７、画像ファイル取得部５５、及び画像ファイル受付部５６を登録している。
設定制御部５７、画像ファイル取得部５５、及び画像ファイル受付部５６は、Ｉ／Ｏ制御部５８を介してＩ／Ｏコントローラ４６とそれぞれやり取りを行うことでアプリケーションとしての処理を進めていく。

また、Ｉ／Ｏジョブ管理部５９は、キャンセル可能か否かを判定する際は、各ジョブのメッセージ種類を取り出し、図２７のテーブルのキャンセル可否の設定を参照してキャンセル可能か否かを判定し、キャンセル可能であればジョブのスレッドＩＤを指定してＩ／Ｏコントローラ４６にキャンセルを依頼する。

次に、図２９によって図２６の通信状態管理部６４が記憶して保持するスレッド状態管理テーブルについて説明する。
図２９は、図２６に示した通信状態管理部６４が保持するスレッド状態管理テーブルの一例を示す図である。
通信状態管理部６４は、図２９に示したテーブルを予め記憶している。
このテーブルには、スレッドＩＤ毎の用途と状態と利用者とを登録している。

スレッドＩＤは、ジョブがＩ／Ｏコントローラ４６のどのスレッドで実行されているかを示す識別情報である。ジョブを開始する際及びキャンセルする際はこのスレッドＩＤを指定する必要がある。
通信状態管理部６４は、このテーブルを参照することによってＩ／Ｏコントローラ４６で動いているスレッドを識別することができる。

次に、用途は、スレッドが何の通信を担当しているのかを示す情報である。
このテーブルでは、ＨＴＴＰサーバ機能とＨＴＴＰクライアント機能を担当するものとしての内容を登録している。
状態は、スレッドの通信処理状態を示す情報である。
利用者は、ジョブの入出力先の機能部を示す情報である。
そのスレッドが処理しているセッションは、図２８のテーブルに登録された図２５の画像ファイル取得部５５と画像ファイル受付部５６のどちらと行っているものかを示す。

なお、設定制御部５７はネットワーク通信を行わないため、ここには出現しない。
図２９のテーブルの内容は、アプリケーションコントローラ４５側に応答を返すときに用いる。
また、通信を開始する際は、スレッドを指定して通信処理を開始させる。
そして、通信状態管理部６４は、キャンセル実行の際は、アプリケーションコントローラ４５側からスレッドＩＤを指定してそのスレッドの処理を中断させる。

次に、図３０によってプロジェクタ４０のジョブ生成までの処理例について説明する。
図３０は、図２４に示したプロジェクタ４０のジョブ生成までの処理例を示すシーケンス図である。図３０中では、ステップを「Ｓ」と記載する。
この処理では、図２５の画像ファイル取得部５５がネットワーク４２の先の図示を省略したサーバに対して画像ファイルを取得するための要求を出すものとして説明する。
この処理は、プロジェクタ４０の電源オン状態のときに実行される。
図３０のステップ１２１で、画像ファイル取得部５５は、Ｉ／Ｏ制御部５８にネットワーク送信要求を送る。

次に、ステップ１２２で、Ｉ／Ｏ制御部５８はＩ／Ｏジョブ管理部５９に対して新しいジョブ生成を指示する。
また、ステップ１２３で、Ｉ／Ｏ制御部５８はコントローラ間接続制御部６０に対してネットワーク送信依頼のメッセージを送信する。
次に、ステップ１２４で、アプリケーションコントローラ４５側のコントローラ間接続制御部６０は、Ｉ／Ｏコントローラ４６側のコントローラ間接続制御部６１へメッセージを転送する。

ステップ１２５で、Ｉ／Ｏコントローラ４６側のコントローラ間接続制御部６１は、通信制御部６３にアプリケーションコントローラ４５側から受け取ったメッセージを送信する。
次に、ステップ１２６で、通信制御部６３は通信状態管理部６４に対して、利用する通信スレッドの通信状態を送信中状態に更新する。
そして、ステップ１２７で、通信制御部６３はネットワーク接続制御部６５にネットワーク送信を実行させる。

なお、図３０に示したシーケンス例では、ネットワーク通信を行うので、ステップ１２５において通信制御部６３にメッセージが渡されているが、メッセージの種類によっては図２６の機能実行部６２にメッセージが渡される。その場合、ステップ１２６，ステップ１２７は発生しない。

次に、図３１によってプロジェクタ４０のジョブ削除までの処理例について説明する。
図３１は、図２４に示したプロジェクタ４０のジョブ削除までの処理例を示すシーケンス図である。図３１中では、ステップを「Ｓ」と記載する。
この処理は、プロジェクタ４０の電源オン状態のときに実行される。
この処理では、図３０に示したシーケンスの処理の続きとして、図２５の画像ファイル取得部５５によるネットワーク送信の応答を返すケースを例として説明する。
図３１のステップ１３１で、ネットワーク接続制御部６５は、ネットワーク送信が完了したことを示すネットワーク送信の応答を通信制御部６３に返す。

次に、ステップ１３２で、通信制御部６３は通信状態管理部６４に対して通信状態を更新する。この場合、利用した通信スレッドの状態を送信完了（受信待ち）に更新する。
その後、ステップ１３３で、通信制御部６３はネットワーク送信の応答を、図３０の処理で受けたメッセージの応答として、コントローラ間接続制御部６１にメッセージ応答を送信する。
次に、ステップ１３４で、Ｉ／Ｏコントローラ４６側のコントローラ間接続制御部６１からアプリケーションコントローラ４５側のコントローラ間接続制御部６０へメッセージを転送する。

ステップ１３５で、コントローラ間接続制御部６０は、Ｉ／Ｏ制御部５８に対して受け取ったメッセージ応答を送信する。
すると、ステップ１３６で、Ｉ／Ｏ制御部５８はネットワーク送信が完了したのでＩ／Ｏジョブ管理部５９からジョブを削除する。
そして、ステップ１３７で、Ｉ／Ｏ制御部５８は画像ファイル取得部５５にネットワーク送信が完了したことを知らせる結果を送信する。

なお、図３０のシーケンスと同様に、図３１のシーケンス例ではネットワーク通信を行うので、ステップ１３１においてネットワーク接続制御部６５が応答を通信制御部６３に返すところから始まるが、図２６の機能実行部６２が処理を行っていた場合は機能実行部６２がコントローラ間接続制御部６１にメッセージ応答を渡すところ（ステップ１３３に相当）から始まる。その場合、ステップ１３１，ステップ１３２は発生しない。

次に、図３２によってプロジェクタ４０がキャンセルによってジョブ削除するまでの処理例について説明する。
図３２は、図２４に示したプロジェクタ４０がキャンセルによってジョブ削除するまでの処理例を示すシーケンス図である。図３２中では、ステップを「Ｓ」と記載する。
この処理は、プロジェクタ４０の電源オン状態のときに実行される。
この処理は、図３０のシーケンスの続きとして、図３１のシーケンスのように処理完了による終了ではなく、キャンセルを行った場合について説明する。

図３２のステップ１４１で、図２５のアプリケーションコントローラ４５側の画像ファイル取得部５５は、Ｉ／Ｏ制御部５８に依頼中のネットワーク送信のキャンセル要求を送る。
ステップ１４２で、Ｉ／Ｏ制御部５８はＩ／Ｏジョブ管理部５９にキャンセル要求されたジョブがあることを確認する。
ステップ１４３で、Ｉ／Ｏ制御部５８はコントローラ間接続制御部６０に対してキャンセル要求のメッセージを送る。

ステップ１４４で、アプリケーションコントローラ４５側のコントローラ間接続制御部６０から図２６のＩ／Ｏコントローラ４６側のコントローラ間接続制御部６１へメッセージを転送する。
ステップ１４５で、Ｉ／Ｏコントローラ４６側のコントローラ間接続制御部６１は通信制御部６３に対して受け取ったメッセージを送信する。
ステップ１４６で、通信制御部６３は通信状態管理部６４にキャンセル要求された通信の状態を確認する。

ステップ１４７で、通信制御部６３はネットワーク接続制御部６５に対して通信のキャンセルを指示する。
ステップ１４８で、通信制御部６３は通信状態管理部６４に対して通信状態を更新する。この場合、キャンセルした通信のスレッドの状態を待機中に更新する。
ステップ１４９で、通信制御部６３はステップ１４５の応答としてコントローラ間接続制御部６１にメッセージの応答を送信する。

ステップ１５０で、Ｉ／Ｏコントローラ４６側のコントローラ間接続制御部６１から図２５のアプリケーションコントローラ４５側のコントローラ間接続制御部６０へメッセージを転送する。
ステップ１５１で、コントローラ間接続制御部６０はＩ／Ｏ制御部５８に対して受け取ったメッセージ応答を送信する。
ステップ１５２で、Ｉ／Ｏ制御部５８はネットワーク送信がキャンセルされたのでＩ／Ｏジョブ管理部５９からジョブを削除する。
ステップ１５３で、Ｉ／Ｏ制御部５８は画像ファイル取得部５５にキャンセル結果を送信し、キャンセルが完了したことを知らせる。

次に、図３３によって図２５のＩ／Ｏ制御部５８とＩ／Ｏジョブ管理部５９における電源オフまでの処理について説明する。
図３３は、図２５に示したＩ／Ｏ制御部５８とＩ／Ｏジョブ管理部５９における電源オフまでの処理を示すフローチャート図である。
この処理は、プロジェクタ４０の電源オン状態のときに実行される。
ステップ（図中「Ｓ」で示す）１６１で、図２５の電力制御部５３から電源オフ移行の指示を受けると、ステップ１６２へ進む。上記電力制御部５３へは、操作部４３に対する電源スイッチ押下などの操作によって電源オフ移行が指示される。

ステップ１６２で、Ｉ／Ｏ制御部５８はＩ／Ｏジョブ管理部５９に指示してジョブがあるか否かを判断し、もしジョブがない場合（Ｎの場合）はステップ１６９で電源オフ（スタンバイ状態）に移行し、この処理を終了する。
ステップ１６２の判断でジョブがある場合（Ｙの場合）はステップ１６３へ進む。
ステップ１６３で、Ｉ／Ｏジョブ管理部５９にキャンセルか待機かを判定していない未判定のジョブがあるか否かを判断し、ある場合（Ｙの場合）はステップ１６４へ進み、ない場合（Ｎの場合）、すなわち全てのジョブについて判定を行った場合はステップ１６６へ進む。

ステップ１６４で、ジョブがキャンセル可能か否かを判断し、キャンセル可能ではない場合（Ｎの場合）はステップ１６３へ戻って次のジョブの判定に移る。
また、ステップ１６４の判断でキャンセル可能な場合（Ｙの場合）は、ステップ１６５でキャンセル要求を発行し、ステップ１６３へ戻って次のジョブの判定に移る。
一方、ステップ１６６では、各ジョブについてキャンセル完了したか、あるいは処理を最後まで完了したかのジョブの処理完了通知を受信し、ステップ１６７で、通知を受けたジョブをＩ／Ｏジョブ管理部５９から削除し、ステップ１６８へ進む。

ステップ１６８で、ジョブを全て削除したか否かを判断し、まだ削除していないジョブがある場合（Ｎの場合）はステップ１６６に戻り次のジョブの削除を行っていく。
また、ステップ１６８の判断でジョブを全て削除した場合（Ｙの場合）、全てのジョブ削除が完了し、Ｉ／Ｏジョブ管理部５９にジョブが無い状態になったら、ステップ１６９で電源オフに移行し、この処理を終了する。

次に、図３４によって図２６の通信制御部６３と通信状態管理部６４におけるキャンセル処理について説明する。
図３４は、図２６に示した通信制御部６３と通信状態管理部６４におけるキャンセル処理を示すフローチャート図である。
この処理は、プロジェクタ４０の電源オン状態のときに実行される。
ステップ（図中「Ｓ」で示す）１７１で、通信制御部６３はアプリケーションコントローラ４５側からキャンセル要求を受けると、通信状態管理部６４に指示を送りステップ１７２へ進む。

ステップ１７２で、通信状態管理部６４は、キャンセル要求に指定されているスレッドＩＤと一致するか否かを判断し、一致する場合（Ｙの場合）はステップ１７３へ進む。
また、ステップ１７２の判断でキャンセル要求に指定されているスレッドＩＤと一致しない場合（Ｎの場合）は、そのまま処理を終了する。

ステップ１７３で、通信状態管理部６４は、指定されたスレッドの通信処理がキャンセル可能か否かを判断し、キャンセルできない場合（Ｎの場合）は処理を終了する。このキャンセルせずに処理を終了する場合、その通信は処理完了まで継続する。もしくは通信状態をいくつかの段階に分け、キャンセル可能な状態になった後、再びキャンセル要求を受けてキャンセルするよう構成してもよい。
また、ステップ１７３の判断で指定されたスレッドの通信処理がキャンセルできる場合（Ｙの場合）は、ステップ１７４で、通信制御部６３が通信処理をキャンセルし、この処理を終了する。

次に、図２５のＩ／Ｏジョブ管理部５９が記憶して保持するジョブ状態におけるキャンセル可否を示すテーブルについて説明する。
図３５は、図２５に示したＩ／Ｏジョブ管理部５９が保持するジョブ状態におけるキャンセル可否を示すテーブルの一例の図である。
Ｉ／Ｏジョブ管理部５９は、図３５に示したテーブルを予め記憶している。
このテーブルには、メッセージ種類毎のジョブ状態とキャンセル可否の情報が登録されている。

メッセージ種類は、Ｉ／Ｏコントローラ４６におけるメッセージ種類を示す識別情報（ＩＤ）である。
ジョブ状態は、ジョブが現在何の状態にあるか、例えば、Ｉ／Ｏコントローラ４６に要求を送信中なのか、Ｉ／Ｏコントローラ４６からの応答待ちなのか、といった内容を示す情報である。
キャンセル可否は、ジョブがそのメッセージ種類・そのジョブ状態のときにキャンセルが可能か否かを示す情報である。
Ｉ／Ｏ制御部５８は、図３５のテーブルを参照し、メッセージ種類とジョブ状態に応じてジョブのキャンセル可否を判定する。

次に、図２６の通信制御部６３が記憶して保持する通信スレッド用途と状態におけるキャンセル可否を示すテーブルについて説明する。
図３６は、図２６に示した通信制御部６３が保持する通信スレッド用途と状態におけるキャンセル可否を示すテーブルの一例の図である。
通信制御部６３は、図３６に示したテーブルを予め記憶している。
このテーブルは、用途毎の状態とキャンセル可否の情報を登録している。
用途は、スレッドが何の通信を担当しているのかを示す情報である。

また、状態は、スレッドの通信処理状態を示す情報である。
キャンセル可否は、通信スレッドがその用途・その状態のときにキャンセルが可能か否かを示す情報である。
通信制御部６３は、図３６のテーブルを参照し、通信制御部６３がキャンセルを行う際には、通信スレッドの用途と状態に応じてキャンセル可否を判定する。

この実施形態のプロジェクタ４０によれば、電源オフを指示された際、仕掛前のジョブはキャンセルし、仕掛中のジョブが無くなった時点で電源オフに移行するので、電源オフ処理の安全性を向上させると共に、電源オフまでの時間を短縮することができる。
また、ネットワーク送受信に関するジョブをキャンセルすることにより、電源オフ処理の時間を短縮することができる。
さらに、ジョブの種類によって、そのジョブをキャンセルしない方が安全な場合、又はジョブをキャンセルしない方が時間短縮になる場合は、そのジョブをキャンセルせずに実行するので、電源オフ処理の安全性を向上させると共に、電源オフまでの時間を短縮することができる。

以上で実施形態の説明を終了するが、この発明において、各部の具体的な構成、処理の内容、データの形式等は、実施形態で説明したものに限るものではない。
また、上述の実施形態では、この発明をプロジェクタ１，４０に適用した例について説明した。
しかし、この発明は、電力状態をスタンバイ等の省電力状態に移行する機能を備えたものならば、ファクシミリ装置、スキャナ、プリンタ、複写機等の任意の処理装置に適用可能である。
また、以上説明してきた実施形態の構成は、相互に矛盾しない限り任意に組み合わせて実施可能であることは勿論である。

１，４０：プロジェクタ ２，４１：ＰＣ ３，４２：ネットワーク ４，４３：操作部 ５：制御部 ６，４４：投影部 １１：電力制御部 １２：ユーザ操作受付部 １３：ネットワーク通信部 １４：動作抑制制御部 １５〜１７：機能実行部 １８：システムバス ４５：アプリケーションコントローラ ４６：Ｉ／Ｏコントローラ ５０：グラフィックドライバ部 ５１：操作制御部 ５２：ＵＩ画面制御部 ５３：電力制御部 ５４：画像デコーダ部 ５５：画像ファイル取得部 ５６：画像ファイル受付部 ５７：設定制御部 ５８：Ｉ／Ｏ制御部 ５９：Ｉ／Ｏジョブ管理部 ６０，６１：コントローラ間接続制御部 ６２：機能実行部 ６３：通信制御部 ６４：通信状態管理部 ６５：ネットワーク接続制御部

特開２０００−２６１５１５号公報

Claims (9)

1. 入力手段によって入力された処理要求に対応する処理を実行する処理手段を備えた処理装置であって、
   該処理装置を省電力状態に移行させる制御と省電力状態から復帰させる制御をする電力制御手段と、
   該電力制御手段によって該処理装置を省電力状態に移行させる前に、前記処理手段に対して所定の動作抑制を要求し、前記電力制御手段によって該処理装置を省電力状態から復帰させた場合に前記処理手段に対して動作抑制の解除を要求する制御をする動作抑制制御手段とを有し、
   前記動作抑制制御手段は、前記処理手段に対して前記所定の動作抑制の要求前に受け付けた処理は終了し、前記所定の動作抑制の要求の後に受け付けた処理は中止する動作抑制を要求する手段を有することを特徴とする処理装置。
2. 前記処理手段は、前記動作抑制制御手段から動作抑制の要求を受けた場合、該動作抑制の要求前に受け付けた処理を全て終了してから、前記動作抑制制御手段に動作抑制の応答を送る手段をそれぞれ有することを特徴とする請求項１に記載の処理装置。
3. 前記処理手段を複数備え、
   前記動作抑制制御手段は、前記各処理手段に対して、予め記憶した順番で前記所定の動作抑制を要求する手段を有することを特徴とする請求項１又は２に記載の処理装置。
4. 前記処理手段を複数備え、
   前記動作抑制制御手段は、前記各処理手段に対して、予め記憶した順番で前記所定の動作抑制の解除を要求する手段を有することを特徴とする請求項１乃至３のいずれか一項に記載の処理装置。
5. 前記処理手段を複数備え、
   前記動作抑制制御手段は、予め指定された前記処理手段に対して、前記所定の動作抑制を要求する手段を有することを特徴とする請求項１乃至４のいずれか一項に記載の処理装置。
6. 前記処理手段は、前記動作抑制制御手段から前記所定の動作抑制の要求を受け付けた後の動作抑制状態においても予め指定された処理の要求を受け付ける手段を有することを特徴とする請求項１乃至５のいずれか一項に記載の処理装置。
7. 前記処理手段は、前記動作抑制制御手段から前記所定の動作抑制の要求を受け付けた後の動作抑制状態でも処理の要求を受け付け、該受け付けた処理の要求を蓄積し、前記動作抑制制御手段から動作抑制の解除の要求を受けたとき、前記蓄積された処理の要求に対応する処理を実行する手段を有することを特徴とする請求項１乃至５のいずれか一項に記載の処理装置。
8. 前記処理手段は、前記動作抑制状態のときに受け付けた処理の要求について、同一の処理要求を重複して蓄積しないように制御する手段をそれぞれ有することを特徴とする請求項７に記載の処理装置。
9. 前記処理手段は、前記動作抑制制御手段から動作抑制の要求を受けた場合、該動作抑制の要求前に受け付けた処理についてキャンセルの可否を判断し、キャンセル可能と判断した処理をキャンセルする手段をそれぞれ有することを特徴とする請求項１に記載の処理装置。

Images