JP5293462B2 - 電子機器、情報処理方法、及び情報処理プログラム - Google Patents

Description

本発明は、本発明は、電子機器、情報処理方法、及び情報処理プログラムに関し、特にプログラムを実行可能な電子機器、情報処理方法、及び情報処理プログラムに関する。

従来、特に組み込み機器等において動作するプログラムの障害解析（デバッグ等）の代表的な作業として、プログラムが出力するログの解析が行われている。すなわち、プログラムのソースコードには、プログラムが用いている変数の値や、プログラムが動作しているハードウェアの状態を示す情報等をログファイルに出力するための命令（例えば、Ｃ言語におけるｐｒｉｎｔｆ関数）が予め各所に埋め込まれている。障害が発生した際、斯かる命令（以下、「ログ出力命令」という。）に従って出力されたログファイルを解析することにより、障害の原因が推測又は特定される。

しかし、予め埋め込まれたログ出力命令に基づいて出力されるログファイル（最初に出力されるログファイル）では、詳細な解析を行うには情報として不十分な場合が多々ある。斯かる場合、最初に出力されるログファイルに基づいて、或る程度障害箇所が絞り込まれる。続いて、その障害箇所周辺について更に詳細なログを出力するように、プログラムのソースコードが修正され、コンパイル及びリンクが行われた上で、プログラムの置き換えが行われる。改めて出力されるログファイルによっても原因が特定できない場合は、更に、ソースコードにログ出力命令が埋め込まれ、上記作業が繰り返される。このように、ログに基づいて障害解析を行う場合、時として大変煩雑な作業が要求されていた。

そこで、従来、動作中のプログラムの任意の箇所（診断位置）に当該プログラムの診断用プログラムの処理を動的に（実行時に）割り込ませる技術が存在する。診断用プログラム内では、適用対象（割り込み対象）となるプログラムの変数の値等を参照することができる。診断用プログラムの処理の終了後は、適用対象となるプログラムについて診断用プログラムによって割り込まれた位置に処理が復帰する。斯かる技術によれば、適用対象となるプログラムのソースコードを修正することなく、診断用プログラムによって適用対象となるプログラムのログの出力、バグの修正、又は機能拡張等が可能となる。また、診断用プログラムの利用者は、診断用プログラムをネットワークを介して適用対象のプログラムが動作する機器等に送信し、ネットワークを介して診断用プログラムの実行制御等を行うことが可能である。斯かる遠隔操作が可能な点においても、利用者（障害解析担当者等）にとって斯かる診断用プログラムは非常に便利である。

しかしながら、上記のような診断用プログラムは、適用対象のプログラムがいかなる状態であるかに拘わらず適用可能であるため、適用のタイミングによって適用対象のプログラム自体の動作や、適用対象のプログラムによって制御される機器自体の動作が不安定になる可能性もある。例えば、機器においてジョブが実行されている最中に、当該ジョブの実行に関わるプログラムに対して、ジョブの実行中には不適切な処理を割り込ませる診断用プログラムが適用された場合、当該ジョブに関する処理は不安定なものとなる可能性がある。

一方、ジョブの実行中に適用されなければ意味のない診断用プログラムも存在する。例えば、適用対象のプログラムについてジョブの実行中におけるログを記録するような診断用プログラムである。

本発明は、上記の点に鑑みてなされたものであって、他のプログラムに動的に処理を割り込ませることのできるプログラムの適用を当該電子機器の状態に応じて適切に制御することのできる電子機器、情報処理方法、及び情報処理プログラムの提供を目的とする。

そこで上記課題を解決するため、本発明は、電子機器であって、当該電子機器の状態の変化を検知し、該状態を認識する状態管理手段と、他のプログラムに対して動的に処理を割り込ませることのできる追加プログラムの有効化要求の入力に応じ、当該追加プログラムを当該電子機器のプログラムに適用させる追加プログラム制御手段と、機器の状態に応じて前記追加プログラムの適用の可否を示す適用可否情報を記憶した適用可否記憶手段とを有し、前記追加プログラム制御手段は、前記有効化要求が入力されたときに前記状態管理手段が認識している当該電子機器の状態と前記適応可否情報とに基づいて、当該有効化要求に係る前記追加プログラムの適用の可否を判定する。

このような電子機器では、他のプログラムに動的に処理を割り込ませることのできるプログラムの適用を当該電子機器の状態に応じて適切に制御することができる。

本発明によれば、他のプログラムに動的に処理を割り込ませることのできるプログラムの適用を電子機器の状態に応じて適切に制御することができる。

本発明の実施の形態における機器管理システムの構成例を示す図である。 追加プログラムの概要を説明するための図である。 本発明の実施の形態における機器のハードウェア構成例を示す図である。 本発明の実施の形態における機器のソフトウェア構成例を示す図である。 本実施の形態の機器におけるコピージョブ実行時の処理手順を説明するためのシーケンス図である。 第一の実施の形態における追加プログラム制御部の処理手順を説明するためのフローチャートである。 第一の実施の形態におけるジョブ実行中適用可否管理テーブルの構成例を示す図である。 ジョブ実行中にＥＣＳを適用対象とする追加プログラムの有効化が要求された場合の第一の処理手順を説明するためのシーケンス図である。 ジョブ実行中にＥＣＳを適用対象とする追加プログラムの有効化が要求された場合の第二の処理手順を説明するためのシーケンス図である。 ジョブ実行中にＥＣＳを適用対象とする追加プログラムの有効化が要求された場合の第三の処理手順を説明するためのシーケンス図である。 オフライン状態への遷移処理の処理手順を説明するためのシーケンス図である。 オフライン状態の各モードを説明するための図である。 第二の実施の形態における追加プログラム制御部の処理手順を説明するためのフローチャートである。 第二の実施の形態におけるオフラインモード適用可否管理テーブルの構成例を示す図である。 第二の実施の形態におけるオフライン取得元適用可否管理テーブルの構成例を示す図である。 オフライン状態中に追加プログラムの有効化が要求された場合の第一の処理手順を説明するためのシーケンス図である。 オフライン状態中に追加プログラムの有効化が要求された場合の第二の処理手順を説明するためのシーケンス図である。 第三の実施の形態における機器の電力状態の状態遷移例を示す図である。 静音状態から通常電力状態への遷移時の処理手順を説明するためのシーケンス図である。 第四の実施の形態における追加プログラム制御部の処理手順を説明するためのフローチャートである。 第四の実施の形態における有効化条件管理テーブルの構成例を示す図である。 機器の状態変化に応じた追加プログラムの有効化処理の第一の処理手順を説明するためのシーケンス図である。 機器の状態変化に応じた追加プログラムの有効化処理の第二の処理手順を説明するためのシーケンス図である。

以下、図面に基づいて本発明の実施の形態を説明する。図１は、本発明の実施の形態における機器管理システムの構成例を示す図である。図１の機器管理システム１において、管理サーバ１０と、機器２０ａ、機器２０ｂ及び機器２０ｃ（以下、総称する場合「機器２０」という。）とは、ＬＡＮ（Local Area Network）又はインターネット等のネットワーク５０（有線又は無線の別は問わない。）を介して接続されている。

機器２０は、コピー、ファクシミリ、プリンタ、及びスキャナ等の複数の機能を一台の筐体において実現する画像形成装置（複合機）である。機器２０は、ＣＰＵやメモリを備え、メモリに記録されたプログラムに従ったＣＰＵによる制御に基づいて各種の機能を実現する。なお、本実施の形態では、機器２０が電子機器の一例に相当する。

管理サーバ１０は、機器２０において利用されるプログラムに対して適用される追加プログラムの管理及び当該追加プログラムの機器２０への転送等を行うコンピュータである。本実施の形態において、追加プログラムとは、適用対象とされるプログラムの任意の箇所において、当該追加プログラムに定義された処理を動的に割り込ませることのできるプログラムをいう。

図２は、追加プログラムの概要を説明するための図である。図２において、５０１は、追加プログラム５０５が適用されるプログラムにおける仮想メモリ上における命令の配列を示す。プログラム５０１は、追加プログラム５０１が適用される前（通常実行時）は、命令１、２、３の順で処理を実行する。５０１ａは、プログラム５０１に追加プログラム５０１が適用された状態を示す。ここでは、命令１と命令２との間に追加プログラム５０５の処理を割り込ませる例が示されている。この場合、命令２がテーブル５０２への分岐命令に置き換えられる。テーブル５０２には、初期化処理、前処理（変数のスタックへの退避等）、追加プログラム５０５の呼び出し処理、後処理（スタックに退避されていた変数等の取り出し等）の後に命令２が実行され、プログラム５０１の命令３に戻るような定義がされている。

すなわち、追加プログラムが適用される場合、適用対象とされたプログラムの実行ステップが予め指定された箇所（追加位置）に到達すると、追加プログラムの処理が実行される。当該追加プログラムの処理が終了すると、適用対象とされたプログラムに処理制御が復帰する。その後、適用対象とされたプログラムは、追加位置より処理を再開する。なお、追加プログラムには、適用対象のプログラムに割り込ませる処理の他、適用対象とするプログラム及び追加位置を識別するための情報が含まれている。

追加プログラムの中では、適用対象とされるプログラムの変数等を参照可能である。したがって、追加プログラムによって、適用対象とされるプログラムの任意の箇所における変数の値等を示すログ情報を出力させるための処理や、バグを修正するための処理や、新たな機能を実現するための処理等を適用対象とされるプログラムに割り込ませることができる。

斯かる追加プログラムによれば、適用対象とされるプログラムについて、ソースコードの修正、コンパイル及びリンク、更に、再インストール等を行うことなく（すなわち、動的に）、ログ情報の出力、バグの修正、又は機能強化等を図ることができる。

なお、本実施の形態において、追加プログラムを適用対象のプログラムに適用し、実行可能な状態とすること（図２に示される状態にすること）を追加プログラムの「有効化」という。すなわち、追加プログラムは、機器２０内に保存されているだけでは機能せず、有効化されることにより処理を割り込ませることができる。

機器２０の詳細について説明する。図３は、本発明の実施の形態における機器のハードウェア構成例を示す図である。同図において、機器２０は、コントローラ６０１、オペレーションパネル６０２、ファクシミリコントロールユニット（ＦＣＵ）６０３、スキャナ６０４、及びプロッタ６０５等より構成される。

コントローラ６０１は、ＣＰＵ６１１、ＡＳＩＣ６１２、ＮＢ６２１、ＳＢ６２２、ＭＥＭ−Ｐ６３１、ＭＥＭ−Ｃ６３２、ＨＤＤ（ハードディスクドライブ）６３３、メモリカードスロット６３４、ＮＩＣ（ネットワークインタフェースコントローラ）６４１、ＵＳＢデバイス６４２、ＩＥＥＥ１３９４デバイス６４３、セントロニクスデバイス６４４により構成される。

ＣＰＵ６１１は、種々の情報処理用のＩＣである。ＡＳＩＣ６１２は、種々の画像処理用のＩＣである。ＮＢ６２１は、コントローラ６０１のノースブリッジである。ＳＢ６２２は、コントローラ６０１のサウスブリッジである。ＭＥＭ−Ｐ６３１は、機器２０のシステムメモリである。ＭＥＭ−Ｃ６３２は、機器２０のローカルメモリである。ＨＤＤ６３３は、機器２０のストレージである。メモリカードスロット６３４は、メモリカード６３５をセットするためのスロットである。ＮＩＣ６４１は、ＭＡＣアドレスによるネットワーク通信用のコントローラである。ＵＳＢデバイス６４２は、ＵＳＢ規格の接続端子を提供するためのデバイスである。ＩＥＥＥ１３９４デバイス６４３は、ＩＥＥＥ１３９４規格の接続端子を提供するためのデバイスである。セントロニクスデバイス６４４は、セントロニクス仕様の接続端子を提供するためのデバイスである。オペレーションパネル６０２は、オペレータが機器２０に入力を行うためのハードウェア（操作部）であると共に、オペレータが機器２０から出力を得るためのハードウェア（表示部）である。スキャナ６０４は、原稿より画像データを読み取るハードウェアである。プロッタ６０５は、画像を印刷用紙に転写するハードウェアである。

図４は、本発明の実施の形態における機器のソフトウェア構成例を示す図である。
同図において、機器２０が有するプログラムは、アプリケーション１３１とプラットフォーム１３２とに大別される。これらのプログラムは、ＵＮＩＸ（登録商標）等のＯＳ（オペレーティングシステム）１５３によりプロセス単位で並列的に実行される。

アプリケーション１３１としては、コピー用のアプリケーションであるコピーアプリ１４１、プリンタ用のアプリケーションであるプリンタアプリ１４２、スキャナ用のアプリケーションであるスキャナアプリ１４３、ファクシミリ用のアプリケーションであるファクシミリアプリ１４４、ネットワークファイル用のアプリケーションであるネットワークファイルアプリ１４５が存在する。

アプリケーション１３１は、専用のＳＤＫ（ソフトウェア開発キット）を使用して開発することができる。ＳＤＫを使用して開発したアプリケーション１３１をＳＤＫアプリと呼ぶ。専用のＳＤＫとしては、Ｃ言語でアプリケーション１３１を開発するための「ＣＳＤＫ」や、Ｊａｖａ（登録商標）言語でアプリケーション１３１を開発するための「ＪＳＤＫ」が提供される。ＣＳＤＫを使用して開発したアプリケーション１３１を「ＣＳＤＫアプリ」と呼び、ＪＳＤＫを使用して開発したアプリケーション１３１を「ＪＳＤＫアプリ」と呼ぶ。図４の機器２０にも、ＣＳＤＫアプリ１４６と、ＪＳＤＫアプリ１４７が存在する。図４の機器２０にはさらに、Ｊａｖａ（登録商標）言語で記述されたＪＳＤＫアプリ１４７とＣ言語で記述された他のソフトウェアとの仲介を行うソフトウェアとして、ＪＳＤＫプラットフォーム１４８が存在する。すなわち、ＪＳＤＫプラットフォーム１４８は、コントロールサービス１５１等によって提供させる機能をＪＳＤＫアプリ１４７に提供するためのＡＰＩ（Application Program Interface）を備えたプラットフォームである。換言すれば、ＪＳＤＫプラットフォーム１４７は、複数のＪＳＤＫアプリ１４７に対して共通の機能を提供する手段である。

プラットフォーム１３２は、種々のコントロールサービス１５１、及びシステムリソースマネージャ（ＳＲＭ）１５２等を含む。コントロールサービス１５１には、ネットワークコントロールサービス（ＮＣＳ）１６１、ファクシミリコントロールサービス（ＦＣＳ）１６２、デリバリコントロールサービス（ＤＣＳ）１６３、エンジンコントロールサービス（ＥＣＳ）１６４、メモリコントロールサービス（ＭＣＳ）１６５、オペレーションパネルコントロールサービス（ＯＣＳ）１６６、サーティフィケーションコントロールサービス（ＣＣＳ）１６７、ユーザディレクトリコントロールサービス（ＵＣＳ）１６８、システムコントロールサービス（ＳＣＳ）１６９、及び追加プログラム制御部１７０等が含まれる。

ＮＣＳ１６１は、ネットワーク通信の仲介を行う。ＦＣＳ１６２は、ファクシミリのＡＰＩを提供する。ＤＣＳ１６３は、蓄積文書の配信処理に関する制御を行う。ＥＣＳ１６４は、スキャナ６０４やプロッタ６０５等を利用したジョブの制御を行う。アプリケーション１３１は、ＥＣＳ１６４を介してジョブを実行する。ＭＣＳ１６５は、メモリやハードディスクドライブに関する制御を行う。ＯＣＳ１６６は、オペレーションパネルに関する制御を行う。ＣＣＳ１６７は、認証処理や課金処理に関する制御を行う。ＵＣＳ１６８は、ユーザ情報の管理に関する制御を行う。ＳＣＳ１６９は、状態管理手段の一例であり、機器２０の状態の変化（遷移）を検知し、機器２０が当該状態であることを認識する。例えば、ＳＣＳ１６９には、機器２０自体の状態の変化や、各コントロールサービス１５１の状態の変化等のイベントが通知される。ＳＣＳ１６９は、通知されたイベントを、当該イベントの通知を必要としている他のプログラムモジュールに通知する。追加プログラム制御部１７０は、上述した追加プログラムの実行環境を実現するソフトウェアである。例えば、追加プログラム制御部１７０は、管理サーバ１０より転送される追加プログラムの受信、適用対象のプログラムへの適用（有効化）等を行う。

ＳＲＭ１５２は、エンジンインタフェース１３４を介して、ハードウェア資源の管理を行う。具体的には、ＳＲＭ１５２は、コントロールサービス１５１からのハードウェア資源の利用要求を調停する。エンジンインタフェース１３４は、スキャナ６０４やプロッタ６０５やその他のハードウェア資源に対するインタフェースである。

また、アプリケーション１３１とプラットフォーム１３２の仲介を行うソフトウェアとして、仮想アプリケーションサービス（ＶＡＳ）１３５が存在する。ＶＡＳ１３５は、アプリケーション１３１をクライアントとするサーバプロセスとして動作すると共に、プラットフォーム１３２をサーバとするクライアントプロセスとして動作する。ＶＡＳ１３５は、アプリケーション１３１から見てプラットフォーム１３２のＡＰＩ１３３を隠蔽するラッピング機能を備え、プラットフォーム１３２のＡＰＩ１３３のバージョンアップに伴う変更を吸収する役割等を担う。

以下、機器２０の処理手順について説明する。第一の実施の形態では、機器２０におけるジョブの実行状態に応じた追加プログラムの取り扱いについて説明する。

まず、第一の実施の形態の前提として、機器２０においてジョブが実行される際の典型的な処理手順について説明する。図５は、本実施の形態の機器におけるコピージョブ実行時の処理手順を説明するためのシーケンス図である。

ユーザによって、コピー元の原稿が機器２０の所定の位置（ＡＤＦ（Auto Document Feeder）等）にセットされ、オペレーションパネル６０２におけるスタートキーが押下されると（Ｓ１０１）、コピーアプリ１４１は、ジョブオープンをＥＣＳ１６４に通知する（Ｓ１０２）。ＥＣＳ１６４は、コピーアプリ１４１によるジョブオープンをＳＣＳ１６９に通知する（Ｓ１０３）。ジョブオープンは、これからジョブを開始することの宣言である。ジョブオープンがＳＣＳ１６９に通知されることにより、ＳＣＳ１６９は、機器２０のジョブの実行状態が、アイドル状態（待機状態）からジョブ実行中状態に遷移したことを認識する。認識とは、例えば、ジョブの実行状態を識別する情報をメモリ（ＭＥＭ−Ｐ６３１）に記録することをいう。

続いて、コピーアプリ１４１は、ジョブエントリーをＥＣＳ１６４に要求する（Ｓ１０４）。当該要求は、コピージョブを実行対象としてジョブキューにエントリさせるための登録要求を意味する。また、当該要求には、コピージョブに対する設定情報（実行条件）、コピージョブが必要とするハードウェア資源（スキャナ６０４，プロッタ６０５等）を示す情報が指定される。ＥＣＳ１６４は、コピーアプリ１４１からのジョブエントリーの要求をＳＣＳ１６９に通知する（Ｓ１０５）。ＳＣＳ１６９は、当該ジョブエントリーの要求をＳＲＭ１５２に通知する（Ｓ１０６）。

ＳＲＭ１５２は、ジョブエントリーの要求に応じ、コピージョブが必要とするスキャナ６０４及びプロッタ６０５等の状態を確認し（Ｓ１０７、Ｓ１０８）、それぞれについて利用の可否をＳＣＳ１６９に通知する（Ｓ１０９、Ｓ１１０）。当該通知は、ＳＣＳ１６９及びＥＣＳ１６４を経てコピーアプリ１４１に伝達される（Ｓ１１１〜Ｓ１１４）。

スキャナ６０４及びプロッタ６０５の双方が利用可能である場合、コピーアプリ１４１は、コピージョブのスタート（開始）をＥＣＳ１６４に要求する（Ｓ１１５）。ＥＣＳ１６４は、コピージョブのスタートをＳＣＳ１６９に通知する（Ｓ１１６）。その後、ＥＣＳ１１６４によって、ＳＣＳ１６９及びＳＲＭ１５２等を介してスキャナ６０４及びプロッタ６０５が制御され、原稿のコピーが実行される（Ｓ１１７）。より詳しくは、スキャナ６０４より画像が読み取られ、当該画像に対して所定の画像処理が実行され、画像処理の結果として得られる画像がプロッタ６０５によって印刷用紙に転写（印刷）される。原稿が複数枚有るときは、複数枚についてコピーが実行される。

全ての原稿について処理が完了すると、ＥＣＳ１６４は、ジョブエンド（ジョブの終了）をコピーアプリ１４１及びＳＣＳ１６９に通知する（Ｓ１１８、Ｓ１１９）。ＳＣＳ１６９は、ジョブエンドをＳＲＭ１５２に通知する（Ｓ１２０）。

ジョブエンドの通知に応じ、コピーアプリ１４１は、ジョブクローズをＥＣＳ１６４に要求する（Ｓ１２１）。ＥＣＳ１６４は、コピーアプリ１４１によるジョブクローズをＳＣＳ１６９に通知する（Ｓ１２２）。ジョブクローズは、ジョブの終了の宣言を意味する。ジョブクローズがＳＣＳ１６９に通知されることにより、ＳＣＳ１６９は、機器２０におけるジョブの実行状態が、ジョブ実行中状態からアイドル状態（待機状態）に遷移したことを認識する。

続いて、図５において説明したように変化（遷移）する、機器２０におけるジョブの実行状態に応じた追加プログラム制御部１７０による追加プログラムの取り扱い（制御）について説明する。

図６は、第一の実施の形態における追加プログラム制御部の処理手順を説明するためのフローチャートである。

ステップＳ２０１において、追加プログラム制御部１７０は、管理サーバ１０より追加プログラムを受信し、受信された追加プログラムをメモリ（ＭＥＭ−Ｐ６３１）に記録する。なお、追加プログラムには、適用対象とされるプログラム（以下、「対象プログラム」という。）の識別情報（対象プログラムＩＤ）、及び追加プログラムの識別情報（追加プログラムＩＤ）等が添付又は記録されている。

続いて、追加プログラム制御部１７０は、有効化対象とする追加プログラムの追加プログラムＩＤが指定された追加プログラムの有効化要求を管理サーバ１０より受信する（Ｓ２０２）。なお、管理サーバ１０から機器２０（追加プログラム制御部１７０）への追加プログラムの転送、及び有効化要求の転送は、管理サーバ１０主導で行われる。すなわち、管理サーバ１０の操作者によって転送対象又は有効化対象とする追加プログラムが選択され、当該選択に応じて追加プログラムの転送又は有効化要求の転送が行われる。また、追加プログラムの転送と有効化要求の転送とは、必ずしもペアで行われる必要はない。予め追加プログラムの転送のみが実行され、その後の適当なタイミングにおいて既に転送済みの追加プログラムに対する有効化要求が転送されてもよい。

有効化要求に応じ、追加プログラム制御部１７０は、ＳＣＳ１６９よりジョブの実行状態を取得する（ＳＣＳ１６９にジョブの実行状態を問い合わせる）（Ｓ２０３）。図５において説明したように、ジョブの実行状態の遷移を検知し、現在のジョブの実行状態を認識しているのはＳＣＳ１６９だからである。

ジョブの実行状態がジョブ実行中でない場合（Ｓ２０４でＮＯ）、追加プログラム制御部１７０は、有効化要求において指定されている追加プログラムＩＤに対応する追加プログラム（ここでは、ステップＳ２０１において受信された追加プログラムであるとする。）を有効化する（Ｓ２０８）。これによって、当該追加プログラムは、対象プログラムに適用される。その結果、対象プログラムの処理内容は、当該追加プログラムの処理によって改変される。続いて、追加プログラム制御部１７０は、追加プログラムが正常に有効化されたことを示す応答を管理サーバ１０に送信する（Ｓ２０９）。

一方、ジョブの実行状態がジョブ実行中である場合（Ｓ２０４でＹＥＳ）、追加プログラム制御部１７０は、ジョブ実行中適用可否管理テーブルを参照して、追加プログラムの適用の可否を判定する（Ｓ２０５）。

図７は、第一の実施の形態におけるジョブ実行中適用可否管理テーブルの構成例を示す図である。同図に示されるように、ジョブ実行中適用可否管理テーブル１８１には、機器２０が有するプログラムのプログラムＩＤごとに、ジョブの実行状態がジョブ実行中である場合に追加プログラムを適用可能であるか否かが記録（登録）されている。図中「○」は適用可能であることを示し、「×」は適用不可能であることを示す。なお、ジョブ実行中可否管理テーブル１８１は、ＨＤＤ６３３等の不揮発性の記憶媒体に予め記録されている。

したがって、追加プログラム制御部１７０は、追加プログラムに添付されている対象プログラムＩＤをジョブ実行中適用可否管理テーブル１８１に当てはめることにより、追加プログラムの適用の可否を判定する。判定の結果、適用可能である場合（Ｓ２０６でＹＥＳ）、上述したステップＳ２０８が実行される。適用不可能である場合（Ｓ２０６でＮＯ）、追加プログラム制御部１７０は、一定時間待機して、ステップＳ２０３以降を繰り返す。したがって、この場合、ジョブ実行中状態からアイドル状態への遷移に応じて追加プログラムの有効化（Ｓ２０８）が実行される。

図６の処理手順を、より具体的なケースに当てはめて説明する。図８は、ジョブ実行中にＥＣＳを適用対象とする追加プログラムの有効化が要求された場合の第一の処理手順を説明するためのシーケンス図である。図８中、図６と同一ステップには同一ステップ番号を付している。

ステップＳ２０２において、追加プログラム制御部１７０は、ＥＣＳ１６９のプログラムＩＤを対象プログラムＩＤとする追加プログラムの有効化要求を管理サーバ１０より受信する。なお、図８では、追加プログラムの受信ステップについては省略されている。この点は、以降のシーケンス図及びフローチャートにおいても同様である。

続いて、追加プログラム制御部１７０は、ジョブの実行状態をＳＣＳ１６９に問い合わせる（Ｓ２０３−１）。当該問い合わせに応じ、ＳＣＳ１６９は、ジョブ実行中であることを示す応答を返信する（Ｓ２０３−２）。そこで、追加プログラム制御部１７０は、ジョブ実行中におけるＥＣＳ１６９に対する追加プログラムの適用の可否をジョブ実行中適用可否管理テーブル１８１を参照して判定する（Ｓ２０５）。図７より、ジョブ実行中におけるＥＣＳ１６９に対する追加プログラムの適用は不可能と判定される。したがって、追加プログラム制御部１７０は、ステップＳ２０３以降を繰り返す（リトライする）。その後、リトライされたＳＣＳ１６９に対するジョブ状態の問い合わせに対して（Ｓ２０３−ｎ１）、ジョブ実行中ではない（アイドル状態である）ことを示す応答が返信されると（Ｓ２０３−ｎ２）、追加プログラム制御部１７０は、ＥＣＳ１６９に対する追加プログラムを有効化する（Ｓ２０８）。続いて、追加プログラム制御部１７０は、追加プログラムが正常に有効化されたことを示す応答を管理サーバ１０に送信する（Ｓ２０９）。

続いて、図８の変形例について説明する。図９は、ジョブ実行中にＥＣＳを適用対象とする追加プログラムの有効化が要求された場合の第二の処理手順を説明するためのシーケンス図である。図９中、図８と同一ステップには同一ステップ番号を付し、その説明は省略する。

図９では、ステップＳ２０５において適用が不可能であると判定された場合のリトライの制御が管理サーバ１０によって行われる点が図８と異なる。すなわち、ステップＳ２０５において適用が不可能であると判定されると、追加プログラム制御部１７０は、有効化は不可能（ＮＧ）であることを示す応答を管理サーバ１０に送信する（Ｓ２１１）。そこで、管理サーバ１０は、一定時間待機後、ＥＣＳ１６９に対する追加プログラムの有効化要求を再送信する。再送信された有効化要求の受信時においてジョブ実行中だった場合、追加プログラム制御部１７０は、有効化は不可能（ＮＧ）であることを示す応答を管理サーバ１０に再び送信する。

再送信されたＥＣＳ１６９に対する追加プログラムの有効化要求がジョブ実行中でないときに受信されると（Ｓ２０２−ｎ）、ステップＳ２０８以降が実行され、追加プログラムが有効化される。

続いて、図８及び図９の変形例について説明する。図１０は、ジョブ実行中にＥＣＳを適用対象とする追加プログラムの有効化が要求された場合の第三の処理手順を説明するためのシーケンス図である。図１０中、図８又は図９と同一ステップには、同一ステップ番号を付し、その説明は適宜省略する。

図１０では、ジョブの実行状態の遷移が、追加プログラム制御部１７０が問い合わせなくてもＳＣＳ１６９から追加プログラム制御部１７０に通知される点が、図８及び図９と異なる。

ＳＣＳ１６９は、ジョブの実行状態についてジョブ実行中への遷移を検知すると、追加プログラム制御部１７０に対してジョブ実行中への遷移を通知する（Ｓ２２１）。当該通知に応じ、追加プログラム制御部１７０は、現在はジョブ実行中であることを認識する。

したがって、その後、管理サーバ１０よりＥＣＳ１６９に対する追加プログラムの有効化要求が受信されると、追加プログラム制御部１７０は、ジョブ実行中適用可否管理テーブル１８１に基づいて追加プログラムの適用の可否を判定する（Ｓ２０５）。適用が不可能であると判定され場合、追加プログラム制御部１７０は、ジョブ実行中が解除されるまで待機する。

続いて、ジョブが完了したことを検知したＳＣＳ１６９より、ジョブの実行状態についてアイドル状態への遷移が通知されると（Ｓ２２２）、追加プログラム制御部１７０は、追加プログラムを有効化する（Ｓ２０８）。

なお、図１０のような形態の場合、追加プログラム制御部１７０は、自らがプロセスとして起動される際（通常は機器２０の起動時）に、自らの識別情報をジョブ状態の変更の通知先としてＳＣＳ１６９に登録しておけばよい。ＳＣＳ１６９は、登録された識別情報に基づいてステップＳ２２１及びＳ２２２の通知を行えばよい。そうすることにより、ＳＣＳ１６９の振る舞いを動的なものとすることができる。

上述したように、第一の実施の形態によれば、ジョブ実行中適用可否管理テーブル１８１に基づいて、ジョブ実行中における追加プログラムの適用（有効化）を適切に制御することができる。したがって、例えば、ジョブ実行中に適用されると不都合な対象プログラムに対する追加プログラムの適用を回避することができる。

次に、第二の実施の形態について説明する。第二の実施の形態では、ジョブの実行状態とは異なった観点（異なったカテゴリ）における機器２０の状態であるオフライン状態に応じた追加プログラムの取り扱いについて説明する。

一般的に「オフライン」とは、ネットワークに接続されていないことをいうが、本実施の形態におけるオフライン状態の「オフライン」は、一般的な用語における「オフライン」とは意味が異なる。本実施の形態において、オフライン状態とは、機器２０内の或るプログラム又は機能の都合により他のプログラム又は機能の実行が制限される状態をいう。ここで、或るプログラム等の都合とは、当該或るプログラムがユーザによる指示に応じて複数のプログラムの動作に影響を与えるようなパラメータの設定を行う場合や、当該設定を有効とするために機器２０全体の再起動若しくは一部のプロセス群の再起動を行う場合等が相当する。すなわち、オフライン状態における「オフライン」とは、各プログラム等が有効に機能しないことを意味する。なお、オフライン状態に相対する通常の状態をオンライン状態という。

まず、第二の実施の形態の前提として、機器２０がオフライン状態へ遷移する際の処理手順を説明する。図１１は、オフライン状態への遷移処理の処理手順を説明するためのシーケンス図である。同図において、アプリ１３１Ａは、オフライン状態への遷移の原因となるプログラムである。アプリ１３１Ｂは、オフライン状態への遷移の影響を受けるプログラム又はプログラム群である。

アプリ１３１Ａは、パラメータの設定指示等、オフライン状態への遷移が必要となる処理の実行指示の入力をオペレーションパネル６０２又はネットワーク等を介して受け付けると、ＳＣＳ１６９に対してオフライン要求（オフライン状態への遷移要求）を入力する（Ｓ３０１）。ＳＣＳ１６９は、オフライン要求に応じ、アプリ１３１Ｂにオフライン状態への遷移の可否を問い合わせる（Ｓ３０２）。なお、ここで問い合わせ対象とされるアプリ１３１Ｂは、予め（例えば、アプリ１３１Ｂの起動時）に、オフライン状態の影響を受けるプログラムとて自らの識別情報がＳＣＳ１６９に登録されているものである。アプリ１３１Ｂは、自らの状態に応じてＳＣＳ１６９に対する応答を行う（Ｓ３０３）。例えば、アプリ１３１Ｂが中断できない処理の実行中である場合、アプリ１３１Ｂは、オフライン状態への遷移は不可能であることを示す応答をする。一方、アプリ１３１Ｂの実行中の処理が中断可能である場合又はアプリ１３１Ｂが処理を実行中で無い場合、アプリ１３１Ｂは、オフライン状態への遷移は可能であることを示す応答をする。

アプリ１３１Ｂからの応答が、オフライン状態への遷移が可能であることを示す場合、ＳＣＳ１６９は、オフライン要求元のアプリ１３１Ａと、オフライン状態への遷移の通知先として予め登録されている追加プログラム制御部１７０及びアプリ１３１Ｂにオフライン確定通知を入力する（Ｓ３０４〜Ｓ３０６）。オフライン確定通知には、オフライン状態への遷移の原因となったプログラム（アプリ１３１Ａ）のプログラムＩＤも含まれる。

これにより、機器２０はオフライン状態へ遷移したことになる。なお、オフライン確定通知を受けた各プログラムの振る舞い（すなわち、オフライン状態における各プログラムの振る舞い）は、各プログラムの実装に依存する。

また、オフライン状態の解除（オンライン状態への復帰）は、オフラインの原因となったアプリＡ１３１からのオンライン要求に応じ、図１１と同様の処理手順が実行されることにより実現される。すなわち、アプリＡ１３１は、パラメータの設定やリブート等の完了後にＳＣＳ１６９に対しオンライン要求を入力する。

ところで、上記において単にオフライン状態と呼んでいた状態には複数の種類（オフラインモード）が存在する（オフライン状態は、複数のモードに細分化される）。図１２は、オフライン状態の各モードを説明するための図である。

同図は、オンライン状態とオフライン状態との状態遷移が示されている。オンライン状態において「オフライ取得」が行われると、機器２０はオフライン状態へ遷移する。ここで、「オフライン取得」の主体は、オフライン要求を行ったプログラムである。すなわち、本実施の形態において、図１１におけるアプリ１３１Ａが機器２０をオフライン状態へ遷移させることを、「アプリ１３１Ａがオフラインを取得する」と表現する。

図１２において、オフライン状態には、ＳＰモード、ＵＰモード、リモート要求、システムリブート、ＮＣＳリブート等のモード（オフラインモード）が存在する。

ＳＰモードは、サービスマン（機器２０のメーカーの保守作業者）によって利用される設定画面が表示中である状態をいう。ＵＰモードは、エンドユーザによって利用される初期設定画面が表示中である状態をいう。リモート要求は、ネットワークを介して設定情報（パラメータ）の更新が行われている状態をいう。システムリブートは、機器２０自体の再起動が行われる状態をいう。ＮＣＳリブートは、ＮＣＳ１６１のプロセスの再起動が行われる状態をいう。

したがって、図１１において、アプリ１３１Ａは、オフライン状態のモードを指定してＳＣＳ１６９にオフライン要求を行う。オフライン状態への遷移の可否の問い合わせを受けたアプリ１３１Ｂは、当該モードのオフライン状態への遷移の可否を判定し、その判定結果をＳＣＳ１６９に応答する。また、オフライン確定通知をうけた各プログラムは、当該モードに応じた振る舞いを行う。

続いて、以上のようなオフライン状態に応じた追加プログラム制御部１７０による追加プログラムの取り扱いについて説明する。

図１３は、第二の実施の形態における追加プログラム制御部の処理手順を説明するためのフローチャートである。

ステップＳ４０１において、追加プログラム制御部１７０は、有効化対象とする追加プログラムの追加プログラムＩＤが指定された追加プログラムの有効化要求を管理サーバ１０より受信する。有効化要求に応じ、オフライン状態でない場合（Ｓ４０２でＮＯ）、追加プログラム制御部１７０は、有効化要求において指定されている追加プログラムＩＤに対応する追加プログラムを有効化する（Ｓ４０８）。続いて、追加プログラム制御部１７０は、追加プログラムが正常に有効化されたことを示す応答を管理サーバ１０に送信する（Ｓ４０９）。なお、オフライン状態であるか否かは、ＳＣＳ１６９からオフライン確定通知を受けているか否かによって判定可能である。

オフライン状態である場合（Ｓ４０２でＹＥＳ）、追加プログラム制御部１７０は、オフラインモード適用可否管理テーブルを参照して、追加プログラムの適用の可否を判定する（Ｓ４０３）。

図１４は、第二の実施の形態におけるオフラインモード適用可否管理テーブルの構成例を示す図である。同図に示されるように、オフラインモード適用可否管理テーブル１８２には、機器２０において対象プログラムとなりうるプログラムのプログラムＩＤごとに、かつ、オフラインモードごとに追加プログラムを適用可能であるか否かが記録（登録）されている。図中「○」は適用可能であることを示し、「×」は適用不可能であることを示す。なお、オフラインモード可否管理テーブル１８２は、ＨＤＤ６３３等の不揮発性の記憶媒体に予め記録されている。

したがって、追加プログラム制御部１７０は、追加プログラムに添付されている対象プログラムＩＤと現在のオフラインモードをオフラインモード可否管理テーブル１８２に当てはめることにより、追加プログラムの適用の可否を判定する。判定の結果、適用可能である場合（Ｓ４０４でＹＥＳ）、追加プログラム制御部１７０は、オフライン取得元適用可否管理テーブルを参照して、追加プログラムの適用の可否を判定する（Ｓ４０５）。

図１５は、第二の実施の形態におけるオフライン取得元適用可否管理テーブルの構成例を示す図である。同図に示されるように、オフライン取得元適用可否管理テーブル１８３には、機器２０において対象プログラムとなりうるプログラムのプログラムＩＤごとに、かつ、オフライン取得元（オフラインを取得したプログラム）のプログラムＩＤごとに追加プログラムを適用可能であるか否かが記録（登録）されている。図中「○」は適用可能であることを示し、「×」は適用不可能であることを示す。なお、オフライン取得元可否管理テーブル１８３は、ＨＤＤ６３３等の不揮発性の記憶媒体に予め記録されている。

したがって、追加プログラム制御部１７０は、追加プログラムに添付されている対象プログラムＩＤとオフラインモードの取得元のプログラムＩＤとをオフライン取得元適用可否管理テーブル１８３に当てはめることにより、追加プログラムの適用の可否を判定する。判定の結果、適用可能である場合（Ｓ４０６でＹＥＳ）、上述したステップＳ４０８及びＳ４０９が実行される。

一方、ステップＳ４０３又はＳ４０５の判定において適用不可能であると判定された場合（Ｓ４０４でＮＯ、又はＳ４０６でＮＯ）追加プログラム制御部１７０は、追加プログラムの有効化の失敗を示す応答を管理サーバ１０に返信する（Ｓ４０７）。なお、第一の実施の形態では、ジョブ実行中からアイドル状態へ遷移するまで待機したのに対し、第二の実施の形態では、オフライン状態が解除されるまで待機は行わないのは、オフライン状態の特性による。すなわち、オフライン状態は、ユーザによって各種のパラメータの設定が行われていたり、リブート等が行われていたりする状態である。ユーザによる設定作業については、その終了時期が予測できず、長期間に及ぶ可能性がある。したがって、オフライン状態の解除まで追加プログラムの有効化を待機するのは適切ではないからである。また、リブートが行われる場合は、管理サーバ１０とのセッションが切断されてしまい、その後の管理サーバ１０とのやりとりの継続が困難だからである。

図１３の処理手順を、より具体的なケースに当てはめて説明する。図１６は、オフライン状態中に追加プログラムの有効化が要求された場合の第一の処理手順を説明するためのシーケンス図である。図１６中、図１１又は図１３と同一ステップには同一ステップ番号を付している。図１６では、アプリ１３１Ａに対してＯＣＳ１６６を当てはめ、アプリ１３１Ｂに対してＥＣＳ１６４を当てはめている。したがって、図１６では、ＯＣＳ１６６がオフラインを取得し、オフライン状態となっている。

斯かる状態において、追加プログラム制御部１７０が、ＯＣＳ１６６のプログラムＩＤを対象プログラムＩＤとする追加プログラムの有効化要求を管理サーバ１０より受信したとする（Ｓ４０１）。有効化要求に応じ、追加プログラム制御部１７０は、追加プログラムの適用の可否を判定する（Ｓ４０３、Ｓ４０５）。ここでは、少なくとも、オフライン取得元適用可否テーブル１８３を用いた判定によって、適用は不可能であると判定される。すなわち、図１５のオフライン取得元適用可否テーブル１８３において、オフライン取得元がＯＣＳ１６６である場合に対象プログラムがＯＣＳ１６６である追加プログラムの適用は「×」とされているからである。したがって、追加プログラム制御部１７０は、追加プログラムの有効化の失敗を示す応答を管理サーバ１０に返信する（Ｓ４０７）。

また、図１７は、オフライン状態中に追加プログラムの有効化が要求された場合の第二の処理手順を説明するためのシーケンス図である。図１７中、図１６と同一ステップには同一ステップ番号を付し、その説明は省略する。

図１７では、ステップＳ４０１の有効化要求に含まれている対象プログラムＩＤが、ＥＣＳ１６４のプログラムＩＤである点が図１６と異なる。したがって、オフラインモードがシステムリブートでなければ（図１４参照）、追加プログラムの適用は可能であると判定される。すなわち、図１５のオフライン取得元適用可否テーブル１８３において、オフライン取得元がＯＣＳ１６６である場合に対象プログラムがＥＣＳ１６４である追加プログラムの適用は「○」とされているからである。したがって、この場合、追加プログラム制御部１７０は、追加プログラムを有効化する（Ｓ４０８）。すなわち、当該追加プログラムはＥＣＳ１６４に適用される。続いて、追加プログラム制御部１７０は、追加プログラムが正常に有効化されたことを示す応答を管理サーバ１０に送信する（Ｓ４０９）。

上述したように、第二の実施の形態によれば、オフライン適用可否管理テーブル１８２及びオフライン取得元適用可否管理テーブル１８３に基づいて、オフライン状態における追加プログラムの適用（有効化）を適切に制御することができる。したがって、例えば、オフライン状態において適用されると不都合な対象プログラムに対する追加プログラムの適用を回避することができる。

次に、第三の実施の形態について説明する。第三の実施の形態では、第一の実施の形態又は第二の実施の形態における機器２０の状態と異なるカテゴリにおける機器２０の状態である、電力状態（電力の供給状態）に応じた追加プログラムの取り扱いについて説明する。

図１８は、第三の実施の形態における機器の電力状態の状態遷移例を示す図である。同図には、機器２０の電力状態として、通常電力状態、予熱状態、低電力状態、静音状態、及びエンジンＯＦＦ状態等が例示されている。通常電力状態は、いわゆる通常の電力状態であり、各種のジョブを即座に実行可能な状態である。通常電力状態において、オペレーションパネル６０２の予熱キーが押下された場合、又は所定時間の無操作状態が継続した場合、機器２０の電力状態は、予熱状態へ遷移する。予熱状態は、通常電力状態よりも消費電力が抑制された状態である。例えば、予熱状態では、プリンタ６０５の定着ユニットの温度が下げられる。予熱状態が無操作のまま所定時間継続した場合、機器２０の電力状態は低電力状態→静音状態といったように徐々に消費電力が少ない状態へ遷移する。静音状態では、例えば、定着ユニットへの電源の供給が停止される。但し、ＨＤＤ６３３へのアクセスは可能である。また、通常電力状態において電源キーが押下された場合も静音状態への遷移が発生する。電源キーは、電源スイッチとは異なる。電源スイッチは、機器２０の電源をＯＮ／ＯＦＦするためのスイッチである。電源キーは、機器２０の電力状態について通常電力状態と静音状態との切り替えを行うためのキー（ボタン）である。静音状態が無操作のまま所定時間継続した場合、機器２０の電力状態はエンジンＯＦＦ状態へと遷移する。エンジンＯＦＦ状態では、消費電力が最小とされる。このような、電力状態の遷移についても、ＳＣＳ１６９に通知される。したがって、ＳＣＳ１６９は、常に現在の電力状態がどの状態であるのかを把握（認識）している。

なお、通常電力状態以外の状態において、キー操作等の入力が行われた場合、機器２０の電力状態は通常電力状態へと遷移する。

例えば、図１９は、静音状態から通常電力状態への遷移時の処理手順を説明するためのシーケンス図である。同図において、アプリ１３１Ｃは、電力状態の遷移の通知先として予めＳＣＳ１６９に登録されているプログラム又はプログラム群である。

例えば、静音状態において、ネットワークを介して接続されているＰＣ（Personal Computer）からの印刷要求が受信されると、プリンタアプリ１４２は、ジョブオープンをＳＣＳ１６９に通知する（Ｓ５０１）。なお、図５において説明した通り、ジョブオープンは、ＥＣＳ１６４を介してＳＣＳ１６９に通知されるが、図１９では便宜上、ＥＣＳ１６４の介在については省略されている。

ジョブオープンの通知に応じ、ＳＣＳ１６９は、機器２０の電力状態を静音状態から通常状態へ遷移させる必要があることを判断する。そこで、ＳＣＳ１６９は、電力状態の遷移時の問い合わせ先として予めＳＣＳ１６９に登録されている追加プログラム制御部１７０及びアプリ１３１Ｃに静音状態から通常電力状態への変更（遷移）の可否を問い合わせる（Ｓ５０２、Ｓ５０３）。問い合わせを受けた追加プログラム制御部１７０及びアプリ１３１Ｃは、それぞれの状態に応じてＳＣＳ１６９に対する応答を行う（Ｓ５０４、Ｓ５０５）。

問い合わせ先からの全ての応答が、通常電力状態への遷移が可能であることを示す場合、ＳＣＳ１６９の制御に基づいて、機器２０の電力状態が物理的に通常電力状態となる。

続いて、ＳＣＳ１６９は、電力状態の遷移の通知先として予めＳＣＳ１６９に登録されている、プリンタアプリ１４２、追加プログラム制御部１７０、及びアプリＣ１３１Ｃに通常電力状態へ遷移したこと示す電力状態確定通知を入力する（Ｓ５０６〜Ｓ５０８）。

なお、図１９は、静音状態から通常電力状態への遷移について説明したが、電力状態に関する他の遷移もついても同様の処理手順が実行される。したがって追加プログラム制御部１７０は、ステップＳ５０７の通知により、現在の電力状態を常に把握することができる。

斯かる電力状態の遷移に応じた追加プログラムの取り扱いについては、第二の実施の形態と同様でよい。すなわち、第三の実施の形態における追加プログラム制御部１７０は、図１３と同様の処理手順を実行すればよい。この場合、オフラインモード適用可否テーブル１８２の代わりに電力状態適用可否テーブルを利用すればよい。電力状態適用可否テーブルの列方向は、オフラインモードの代わりに電力状態とすればよい。したがって、電力状態適用可否テーブルによれば、電力状態ごとに各対象プログラムに対する追加プログラムの適用の可否を判定することができる。

一方、オフライン取得元テーブル１８３に対応するテーブルは、必ずしも必要ではない。したがって、第三の実施の形態では、図１３中、ステップＳ４０５及びＳ４０６に対応するステップは省略されてもよい。

上述したように、第三の実施の形態によれば、電力状態適用可否管理テーブルに基づいて、各電力状態における追加プログラムの適用（有効化）を適切に制御することができる。したがって、例えば、静音状態において適用されても意味の無い対象プログラムに対する追加プログラムの適用を回避することができる。

次に、第四の実施の形態について説明する。第一から第三の実施の形態の追加プログラム制御部１７０は、管理サーバ１０からの追加プログラムの有効化要求の受信に応じて追加プログラムの有効化の可否（適用の可否）を判定するというものであった。一方、第四の実施の形態の追加プログラム制御部１７０は、機器２０の状態の変化を検知に応じて当該状態に適合した追加プログラムを自動的又は能動的に有効化する。なお、第四の実施の形態における機器２０の「状態」としては、ジョブの実行状態、オフライン状態、及び電力状態の全てが対象となりうる。

図２０は、第四の実施の形態における追加プログラム制御部の処理手順を説明するためのフローチャートである。

追加プログラム制御部１７０は、機器２０の状態の変化を検知すると、有効化条件管理テーブルに未処理の追加プログラムが残っている否かを判定し、残っていれば、未処理の追加プログラムのうちの一つを処理対象とする（Ｓ６０１）。ここで、状態の変化の検知は、オフライン状態であれば、図１１のステップＳ３０５における、ＳＣＳ１６９からのオフライン確定通知に基づいて行われる。また、電力状態の変化であれば、図１９のステップＳ５０７の通知における、ＳＣＳ１６９からの電力状態確定通知に基づいて行われる。また、ジョブの実行状態については、追加プログラム制御部１７０がＳＣＳ１６９に対してジョブの実行状態に関するポーリングを行ってもよいし、図１０のケースであれば、ステップＳ２２１におけるＳＣＳ１６９からの通知に基づいて検知されてもよい。

図２１は、第四の実施の形態における有効化条件管理テーブルの構成例を示す図である。同図において、有効化条件管理テーブル１９０には、追加プログラムごとに有効化の条件が記録（登録）されている。条件は、電力状態、オフライン状態、及びジョブの実行状態（ジョブ状態）によって指定される。同図の例では、追加プログラムＡ〜追加プログラムＤまでの４つの追加プログラムが登録されている。追加プログラムＡの有効化の条件は、電力状態がエンジンＯＦＦ状態であることである。追加プログラムＢの有効化の条件は、電力状態が静音状態であることである。追加プログラムＣの有効化の条件は、システムリブート状態であることである。追加プログラムＤの有効化の条件は、ジョブ実行中であることである。なお、二つ以上の状態の組み合わせによって条件が指定されてもよい。有効化条件管理テーブル１９０は、ＨＤＤ６３３等の不揮発性の記憶媒体に予め記録されている。

ステップＳ６０２が最初に実行される際には、追加プログラムＡが処理対象とされる。以下、処理対象とされた追加プログラムを「カレント追加プログラム」という
続いて、追加プログラム制御部１７０は、ステップＳ６０１において検知された状態が、カレント追加プログラムに対する有効化の条件に合致するか否かを判定する（Ｓ６０３）。検知された状態が有効化の条件に合致する場合、追加プログラム制御部１７０は、カレント追加プログラムが既に有効化されているか否かを判定する（Ｓ６０４）。追加プログラム制御部１７０は、追加プログラムを有効化する主体であるため、現在有効化されている追加プログラムの一覧を把握している（例えば、現在有効化されている追加プログラムの追加プログラムＩＤの一覧をメモリに記録している）。したがって、追加プログラム制御部１７０は、各追加プログラムが有効化されているか否かの判定が可能である。

カレント追加プログラムが有効化されていない場合（Ｓ６０４でＮＯ）、追加プログラム制御部１７０は、カレント追加プログラムを有効化する（Ｓ６０５）。カレント追加プログラムが既に有効化されている場合（Ｓ６０４でＹＥＳ）、追加プログラム制御部１７０は、カレント追加プログラムについては何もせずに、有効化条件管理テーブル１９０において次に登録されている追加プログラムをカレント追加プログラムとする。

一方、検知された状態がカレント追加プログラムの有効化の条件に合致しない場合（Ｓ６０３でＮＯ）、追加プログラム制御部１７０は、検知された状態が、カレント追加プログラムの有効化の条件に指定されている状態と同一カテゴリに属する状態であるか否かを判定する（Ｓ６０６）。例えば、追加プログラムＡであれば、検知された状態がエンジンＯＦＦ状態以外の電力状態であれば当該判定は肯定される。一方、検知された状態がオフライン状態又はジョブ状態に関するものであれば当該判定は否定される。

検知された状態が、カレント追加プログラムの有効化の条件に指定されている状態と同一カテゴリに属する場合（Ｓ６０６でＹＥＳ）、追加プログラム制御部１７０は、カレント追加プログラムが既に有効化されているか否かを判定する（Ｓ６０７）。有効化されている場合（Ｓ６０７でＹＥＳ）、追加プログラム制御部１７０は、カレント追加プログラムを無効化する（Ｓ６０８）。無効化とは、対象プログラムに対する追加プログラムの適用（すなわち、割り込み命令の挿入）を解除することをいう。無効化によって、対象プログラムの処理手順は本来のものに戻る。

一方、検知された状態が、カレント追加プログラムの有効化の条件に指定されている状態と同一カテゴリに属さない場合（Ｓ６０６でＮＯ）、又はカレント追加プログラムが有効化されていない場合（Ｓ６０７でＮＯ）、追加プログラム制御部１７０は、カレント追加プログラムについては何もせずに、有効化条件管理テーブル１９０において次に登録されている追加プログラムをカレント追加プログラムとする。

ステップＳ６０２以降が、有効化条件管理テーブル１７０に登録されている全ての追加プログラムについて完了したら図２０の処理は終了する。

図２０の処理手順を、より具体的なケースに当てはめて説明する。図２２は、機器の状態変化に応じた追加プログラムの有効化処理の第一の処理手順を説明するためのシーケンス図である。図２２中、図２０と同一ステップには同一ステップ番号を付している。

例えば、追加プログラム制御部１７０は、エンジンＯＦＦ状態に遷移したことを示す電力状態確定通知をＳＣＳ１６９より受信すると（Ｓ６０１−１）、図２１の有効化条件管理テーブル１９０に基づいて、追加プログラムＡを有効化する（Ｓ６０５−１）。

その後、追加プログラムＡが有効化された状態において、静音状態に遷移したことを示す電力状態確定通知がＳＣＳ１６９より受信されると（Ｓ６０１−２）、追加プログラム制御部１７０は、有効化条件管理テーブル１９０に基づいて、追加プログラムＡを無効化し（Ｓ６０８）、更に、追加プログラムＢを有効化する（Ｓ６０５−２）。

続いて、図２２の変形例について説明する。図２３は、機器の状態変化に応じた追加プログラムの有効化処理の第二の処理手順を説明するためのシーケンス図である。図２３中、図２２と同一ステップには同一ステップ番号を付している。また、図２３において、有効化条件管理テーブル１９０は、管理サーバ１０が有している。

例えば、追加プログラム制御部１７０は、エンジンＯＦＦ状態に遷移したことを示す電力状態確定通知をＳＣＳ１６９より受信すると（Ｓ６０１−１）、当該電力状態の遷移を管理サーバ１０に通知する（Ｓ７０１）。管理サーバ１０は、当該通知に応じて図２０に示される処理を実行し、追加プログラムＡの有効化要求を追加プログラム制御部１７０に送信する（Ｓ７０２）。追加プログラム制御部１７０は当該有効化要求に応じて追加プログラムＡを有効化する。なお、図中では省略されているが、有効化に成功した場合、追加プログラム制御部１７０は、追加プログラムＡの有効化に成功したことを管理サーバ１０に通知する。これによって、管理サーバ１０は、追加プログラムＡが有効化されていることを認識することができる。

その後、追加プログラムＡが有効化された状態において、静音状態に遷移したことを示す電力状態確定通知がＳＣＳ１６９より受信されると（Ｓ６０１−２）、追加プログラム制御部１７０は、当該電力状態の遷移を管理サーバ１０に通知する（Ｓ７０３）。管理サーバ１０は、当該通知に応じて図２０に示される処理を実行し、追加プログラムＡの無効化要求と、追加プログラムＢの有効化要求とを追加プログラム制御部１７０に送信する（Ｓ７０４、Ｓ７０５）。追加プログラム制御部１７０は、管理サーバ１０からの要求に応じ、追加プログラムＡを無効化し、追加プログラムＢを有効化する。

このように、有効化条件管理テーブル１９０は、管理サーバ１０が有していてもよい。この場合、図２０の処理は、管理サーバ１０が実行すればよい。

上述したように、第四の実施の形態によれば、有効化条件管理テーブル１９０に基づいて、機器２０の状態に応じて追加プログラムの有効化又は無効化を自動的に制御することができる。したがって、追加プログラムが適用されるタイミングを適切なものとすることができる。

なお、第四の実施の形態と第一から第三の実施の形態とを組み合わせてもよい。この場合、第四の実施の形態における処理によって有効化すべきと判定された追加プログラムの有効化の可否を、第一から第三の実施の形態における処理によって判定すればよい。また、第一から第四の実施の形態を任意に組み合わせて実施してもよい。

また、本実施の形態では画像形成装置を電子機器の一例としたが、本発明を適用可能な電子機器は画像形成装置に限定されない。例えば、各種のデジタル家電、携帯機器、又は汎用的なコンピュータ等に対しても本発明は有効に適用されうる。

以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

１ 機器管理システム
１０ 管理サーバ
２０ 機器
１３１ アプリケーション
１３２ プラットフォーム
１３３ アプリケーションプログラムインタフェース
１３４ エンジンインタフェース
１３５ 仮想アプリケーションサービス
１４１ コピーアプリ
１４２ プリンタアプリ
１４３ スキャナアプリ
１４４ ファクシミリアプリ
１４５ ネットワークファイルアプリ
１４６ ＣＳＤＫアプリ
１４７ ＪＳＤＫアプリ
１４７ａ、１４７ｂ アプリ
１４８ ＪＳＤＫプラットフォーム
１５１ コントロールサービス
１５２ システムリソースマネージャ
１５３ ＯＳ
１６１ ネットワークコントロールサービス
１６２ ファクシミリコントロールサービス
１６３ デリバリコントロールサービス
１６４ エンジンコントロールサービス
１６５ メモリコントロールサービス
１６６ オペレーションパネルコントロールサービス
１６７ サーティフィケーションコントロールサービス
１６８ ユーザディレクトリコントロールサービス
１６９ システムコントロールサービス
１７０ 追加プログラム制御部
６０１ コントローラ
６０２ オペレーションパネル
６０３ ファクシミリコントロールユニット
６０４ スキャナ
６０５ プロッタ
６１１ ＣＰＵ
６１２ ＡＳＩＣ
６２１ ＮＢ
６２２ ＳＢ
６３１ ＭＥＭ−Ｐ
６３２ ＭＥＭ−Ｃ
６３３ ＨＤＤ
６３４ メモリカードスロット
６３５ メモリカード
６４１ ＮＩＣ
６４２ ＵＳＢデバイス
６４３ ＩＥＥＥ１３９４デバイス
６４４ セントロニクスデバイス

特開２００８−２６９１６３号公報

Claims (15)

1. 電子機器であって、
   当該電子機器の状態の変化を検知し、該状態を認識する状態管理手段と、
   他のプログラムに対して動的に処理を割り込ませることのできる追加プログラムの有効化要求の入力に応じ、当該追加プログラムを当該電子機器のプログラムに適用させる追加プログラム制御手段と、
   電子機器の状態に応じて前記追加プログラムの適用の可否を示す適用可否情報を記憶した適用可否記憶手段とを有し、
   前記追加プログラム制御手段は、前記有効化要求が入力されたときに前記状態管理手段が認識している当該電子機器の状態と前記適用可否情報とに基づいて、当該有効化要求に係る前記追加プログラムの適用の可否を判定する電子機器。
2. 前記追加プログラム制御手段は、前記追加プログラムに適用が不可能であると判定された場合は、当該電子機器の状態が当該追加プログラムの適用の可能な状態となるまで待機した後、当該追加プログラムを当該電子機器のプログラムに適用させる請求項１記載の電子機器。
3. 前記電子機器の状態は、ジョブの実行状態、当該電子機器のプログラムの処理の実行が制限される状態、又は当該電子機器の電力状態である請求項１又は２記載の電子機器。
4. 前記追加プログラムを有効化させる条件が当該電子機器の状態によって指定された有効化条件情報を記憶した有効化条件記憶手段を有し、
   前記追加プログラム制御手段は、前記状態管理手段による当該電子機器の状態の変化の検知に応じ、検知された状態において有効化すべき前記追加プログラムを前記有効化条件情報に基づいて判定し、判定された前記追加プログラムを当該電子機器のプログラムに適用させる請求項１乃至３いずれか一項記載の電子機器。
5. 前記追加プログラムを有効化させる条件が当該電子機器の状態によって指定された有効化条件情報を記憶した有効化条件記憶手段を有するコンピュータとネットワークを介して接続され、
   前記追加プログラム制御手段は、前記状態管理手段によって検知される当該電子機器の状態の変化を前記コンピュータに通知し、前記コンピュータによる、該状態の変化の通知と前記有効化条件記憶手段とに基づく判定結果を前記コンピュータより受信し、該判定結果に指定された前記追加プログラムを当該電子機器のプログラムに適用させる請求項１乃至３いずれか一項記載の電子機器。
6. 電子機器が実行する情報処理方法であって、
   当該電子機器の状態の変化を検知し、該状態を認識する状態管理手順と、
   他のプログラムに対して動的に処理を割り込ませることのできる追加プログラムの有効化要求の入力に応じ、当該追加プログラムを当該電子機器のプログラムに適用させる追加プログラム制御手順とを有し、
   前記追加プログラム制御手順は、前記有効化要求が入力されたときに前記状態管理手順において認識されている当該電子機器の状態と、電子機器の状態に応じて前記追加プログラムの適用の可否を示す適用可否情報を記憶した適用可否記憶手段とに基づいて、当該有効化要求に係る前記追加プログラムの適用の可否を判定する情報処理方法。
7. 前記追加プログラム制御手順は、前記追加プログラムに適用が不可能であると判定された場合は、当該電子機器の状態が当該追加プログラムの適用の可能な状態となるまで待機した後、当該追加プログラムを当該電子機器のプログラムに適用させる請求項６記載の情報処理方法。
8. 前記電子機器の状態は、ジョブの実行状態、当該電子機器のプログラムの処理の実行が制限される状態、又は当該電子機器の電力状態である請求項６又は７記載の情報処理方法。
9. 前記追加プログラム制御手順は、前記状態管理手順における当該電子機器の状態の変化の検知に応じ、検知された状態において有効化すべき前記追加プログラムを、前記追加プログラムを有効化させる条件が当該電子機器の状態によって指定された有効化条件情報を記憶した有効化条件記憶手段に基づいて判定し、判定された前記追加プログラムを当該電子機器のプログラムに適用させる請求項６乃至８いずれか一項記載の情報処理方法。
10. 当該電子機器は、前記追加プログラムを有効化させる条件が当該電子機器の状態によって指定された有効化条件情報を記憶した有効化条件記憶手段を有するコンピュータとネットワークを介して接続され、
    前記追加プログラム制御手順は、前記状態管理手順において検知される当該電子機器の状態の変化を前記コンピュータに通知し、前記コンピュータによる、該状態の変化の通知と前記有効化条件記憶手段とに基づく判定結果を前記コンピュータより受信し、該判定結果に指定された前記追加プログラムを当該電子機器のプログラムに適用させる請求項６乃至８いずれか一項記載の情報処理方法。
11. 電子機器に、
    当該電子機器の状態の変化を検知し、該状態を認識する状態管理手順と、
    他のプログラムに対して動的に処理を割り込ませることのできる追加プログラムの有効化要求の入力に応じ、当該追加プログラムを当該電子機器のプログラムに適用させる追加プログラム制御手順とを実行させ、
    前記追加プログラム制御手順は、前記有効化要求が入力されたときに前記状態管理手順において認識されている当該電子機器の状態と、電子機器の状態に応じて前記追加プログラムの適用の可否を示す適用可否情報を記憶した適用可否記憶手段とに基づいて、当該有効化要求に係る前記追加プログラムの適用の可否を判定する情報処理プログラム。
12. 前記追加プログラム制御手順は、前記追加プログラムに適用が不可能であると判定された場合は、当該電子機器の状態が当該追加プログラムの適用の可能な状態となるまで待機した後、当該追加プログラムを当該電子機器のプログラムに適用させる請求項１１記載の情報処理プログラム。
13. 前記電子機器の状態は、ジョブの実行状態、当該電子機器のプログラムの処理の実行が制限される状態、又は当該電子機器の電力状態である請求項１１又は１２記載の情報処理プログラム。
14. 前記追加プログラム制御手順は、前記状態管理手順における当該電子機器の状態の変化の検知に応じ、検知された状態において有効化すべき前記追加プログラムを、前記追加プログラムを有効化させる条件が当該電子機器の状態によって指定された有効化条件情報を記憶した有効化条件記憶手段に基づいて判定し、判定された前記追加プログラムを当該電子機器のプログラムに適用させる請求項１１乃至１３いずれか一項記載の情報処理プログラム。
15. 当該電子機器は、前記追加プログラムを有効化させる条件が当該電子機器の状態によって指定された有効化条件情報を記憶した有効化条件記憶手段を有するコンピュータとネットワークを介して接続され、
    前記追加プログラム制御手順は、前記状態管理手順において検知される当該電子機器の状態の変化を前記コンピュータに通知し、前記コンピュータによる、該状態の変化の通知と前記有効化条件記憶手段とに基づく判定結果を前記コンピュータより受信し、該判定結果に指定された前記追加プログラムを当該電子機器のプログラムに適用させる請求項１１乃至１３いずれか一項記載の情報処理プログラム。

Images