JP2012048385A - 画像形成装置、プログラム状態判定方法、プログラム状態判定プログラム、及びプログラム状態判定システム - Google Patents

Abstract

【課題】複数のプログラムの状態の確認を簡便化させること。
【解決手段】複数の状態を有するプログラムをインストール可能な画像形成装置であって、一又は複数の前記プログラムの状態の組み合わせに対する条件を一以上記憶した条件記憶手段と、当該画像形成装置にインストールされている前記各プログラムの前記状態情報を取得する状態取得手段と、前記条件ごとに、前記状態取得手段によって取得された前記状態情報に基づいて充足の有無を判定し、判定結果を出力する状態判定手段とを有する。
【選択図】図５

Description

本発明は、画像形成装置、プログラム状態判定方法、プログラム状態判定プログラム、及びプログラム状態判定システムに関し、特に複数のプログラムの状態を判定する画像形成装置、プログラム状態判定方法、プログラム状態判定プログラム、及びプログラム状態判定システムに関する。

従来、その出荷後にアプリケーションプログラム（以下、単に「アプリケーション」という。）等をプラグインとして追加可能な画像形成装置が存在する。各アプリケーションの状態は、それぞれ他のアプリケーションから独立して遷移しうる。具体的には、アプリケーションごとに起動制御や停止制御等を行うことができる。起動されたアプリケーションは、起動状態となるが、起動状態において、アプリケーションの状態は更に詳細に分類されうる。同様に、停止されたアプリケーションは、停止状態となるが、停止状態において、アプリケーションの状態は更に分類されうる。

このように、複数の状態を有するアプリケーションが、一台の画像形成装置に複数インストールされている場合、当該画像形成装置におけるアプリケーションの状態の組み合わせは膨大なものとなりうる。

他方において、複数のアプリケーションが連携することにより一つのサービスが構築される場合がある。このようなサービスが有効であるためには、当該サービスを構築する全てのアプリケーションが画像形成装置にインストールされており、かつ、起動されている必要がある。

しかしながら、上記したように、各アプリケーションの状態は、独立して遷移しうる。したがって、或るアプリケーションが起動されていたとしても、当該アプリケーションと連携してサービスを構築する他のアプリケーションが起動されているという保証はない。そうすると、管理者等は、或るサービスが正常に稼働中であるか否かを確認するためには、当該サービスを構築する全てのアプリケーションの状態を一つずつ確認しなければならないことになる。その前提として、当該サービスを構築するアプリケーションがいずれであるかを知っていなければならない。

また、近年では、ネットワークを介して複数の画像形成装置が管理されるようになっている。この場合、管理者等は、複数台の画像形成装置に関して同様の作業を行わなければならない。

上記の作業負担は、アプリケーションの増加に応じて、また、管理対象となる画像形成装置の増加に応じて肥大化する。

本発明は、上記の点に鑑みてなされたものであって、複数のプログラムの状態の確認を簡便化させることのできる画像形成装置、プログラム状態判定方法、プログラム状態判定プログラム、及びプログラム状態判定システムの提供を目的とする。

そこで上記課題を解決するため、本発明は、複数の状態を有するプログラムをインストール可能な画像形成装置であって、一又は複数の前記プログラムの状態の組み合わせに対する条件を一以上記憶した条件記憶手段と、当該画像形成装置にインストールされている前記各プログラムの前記状態情報を取得する状態取得手段と、前記条件ごとに、前記状態取得手段によって取得された前記状態情報に基づいて充足の有無を判定し、判定結果を出力する状態判定手段とを有する。

このような画像形成装置では、複数のプログラムの状態の確認を簡便化させることができる。

本発明によれば、複数のプログラムの状態の確認を簡便化させることができる。

第一の実施の形態における機器管理システムの構成例を示す図である。 本発明の実施の形態における機器管理サーバのハードウェア構成例を示す図である。 本発明の実施の形態における画像形成装置のハードウェア構成例を示す図である。 本発明の実施の形態における画像形成装置のソフトウェア構成例を示す図である。 ＳＤＫアプリ及びＳＤＫプラットフォームの機能構成例を示す図である。 ＳＤＫアプリが有する状態の例を説明するための図である。 ＳＤＫアプリの状態遷移の一例を示す図である。 第一の実施の形態におけるセット条件の判定処理の処理手順の一例を説明するためのシーケンス図である。 第一の実施の形態におけるセット条件記憶部の構成例を示す図である。 セット条件のチェックフラグがｏｆｆにされた例を示す図である。 問い合わせリストの例を示す図である。 インストール済みアプリリストの例を示す図である。 問い合わせ結果リストの例を示す図である。 アプリ状態管理部の処理手順の一例を説明するためのフローチャートである。 共存できないＳＤＫアプリが共存していないことを確認するためのセット条件の例を示す図である。 排他的な関係にあるセット条件の例を示す図である。 第二の実施の形態における機器管理サーバの機能構成例を示す図である。 第二の実施の形態における画像形成装置へのセット条件の登録処理の処理手順の一例を説明するためのシーケンス図である。 第三の実施の形態における画像形成装置へのセット条件の登録処理の処理手順の一例を説明するためのシーケンス図である。 第三の実施の形態におけるセット条件統合記憶部の構成例を示す図である。 第四の実施の形態における機器管理サーバの機能構成例を示す図である。 第四の実施の形態における画像形成装置へのセット条件の登録処理の処理手順の一例を説明するためのシーケンス図である。 機器情報記憶部の構成例を示す図である。 アプリ状態管理部がＳＤＫプラットフォームの一部として実装される例を示す図である。

以下、図面に基づいて本発明の実施の形態を説明する。図１は、第一の実施の形態における機器管理システムの構成例を示す図である。同図の機器管理システム１において、一以上の画像形成装置１０、機器管理サーバ２０、及びユーザ端末３０等は、ＬＡＮ（Local Area Network）又はインターネット等のネットワーク４０（有線又は無線の別は問わない）を介して通信可能に接続されている。

画像形成装置１０は、印刷、スキャン、コピー、及びＦＡＸ送受信等の機能を一台の筐体によって実現する複合機である。但し、いずれか一つの機能を単体で有する機器が画像形成装置１０として用いられてもよい。画像形成装置１０には、機能拡張等を目的としてプログラム（後述されるＳＤＫアプリ１５２）のインストール又はアンインストール等が可能である。

機器管理サーバ２０は、ユーザ端末３０より転送される要求に応じ、画像形成装置１０を遠隔的に管理又は操作するコンピュータである。機器管理サーバ２０は、例えば、画像形成装置１０の状態や、画像形成装置１０にインストールされているプログラムの状態等を監視する。

ユーザ端末３０は、マウス及びキーボード等の入力手段、並びに液晶ディスプレイ等の表示手段等を備え、機器管理システム１のユーザインタフェースとして機能するコンピュータである。例えば、ユーザ端末３０は、機器管理サーバ２０に対する要求をユーザに入力させ、当該要求に応じて機器管理サーバ２０より返信される情報を表示する。

図２は、本発明の実施の形態における機器管理サーバのハードウェア構成例を示す図である。図２の機器管理サーバ２０は、それぞれバスBで相互に接続されているドライブ装置２００と、補助記憶装置２０２と、メモリ装置２０３と、ＣＰＵ２０４と、インタフェース装置２０５とを有する。

機器管理サーバ２０での処理を実現するプログラムは、ＣＤ−ＲＯＭ等の記録媒体２０１によって提供される。プログラムを記録した記録媒体２０１がドライブ装置２００にセットされると、プログラムが記録媒体２０１からドライブ装置２００を介して補助記憶装置２０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体２０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置２０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。

メモリ装置２０３は、プログラムの起動指示があった場合に、補助記憶装置２０２からプログラムを読み出して格納する。ＣＰＵ２０４は、メモリ装置２０３に格納されたプログラムに従って機器管理サーバ２０に係る機能を実行する。インタフェース装置２０５は、ネットワークに接続するためのインタフェースとして用いられる。

なお、機器管理サーバ２０が直接的にユーザによって操作されてもよい。その場合、機器管理サーバ２０は、入力手段及び表示手段等を備えていればよい。

図３は、本発明の実施の形態における画像形成装置のハードウェア構成例を示す図である。同図において、画像形成装置１０は、コントローラ１１、スキャナ１２、プリンタ１３、モデム１４、操作パネル１５、ネットワークインタフェース１６、及びＳＤカードスロット１７等のハードウェアを有する。

コントローラ１１は、ＣＰＵ１１１、ＲＡＭ１１２、ＲＯＭ１１３、ＨＤＤ１１４、及びＮＶＲＡＭ１１５等を有する。ＲＯＭ１１３には、各種のプログラムやプログラムによって利用されるデータ等が記録されている。ＲＡＭ１１２は、プログラムをロードするための記憶領域や、ロードされたプログラムのワーク領域等として用いられる。ＣＰＵ１１１は、ＲＡＭ１１２にロードされたプログラムを処理することにより、各種の機能を実現する。ＨＤＤ１１４には、プログラムやプログラムが利用する各種のデータ等が記録される。ＮＶＲＡＭ１１５には、各種の設定情報等が記録される。

スキャナ１２は、原稿より画像データを読み取るためのハードウェア（画像読取手段）である。プリンタ１３は、印刷データを印刷用紙に印刷するためのハードウェア（印刷手段）である。モデム１４は、電話回線に接続するためのハードウェアであり、ＦＡＸ通信による画像データの送受信を実行するために用いられる。操作パネル１５は、ユーザからの入力の受け付けを行うためのボタン等の入力手段や、液晶パネル等の表示手段等を備えたハードウェアである。ネットワークインタフェース１６は、ＬＡＮ等のネットワーク（有線又は無線の別は問わない。）に接続するためのハードウェアである。ＳＤカードスロット１７は、ＳＤカード８０に記録されたプログラムを読み取るために利用される。すなわち、画像形成装置１０では、ＲＯＭ１１３に記録されたプログラムだけでなく、ＳＤカード８０に記録されたプログラムもＲＡＭ１１２にロードされ、実行されうる。

図４は、本発明の実施の形態における画像形成装置のソフトウェア構成例を示す図である。同図において、画像形成装置１０は、標準アプリ１５１、ＳＤＫアプリ１５２、ＳＤＫプラットフォーム１５３、コントロールサービス１５４、及びＯＳ１５５等を有する。

標準アプリ１５１は、画像形成装置１０に標準的に（出荷時に予め）実装されているアプリケーションの集合である。同図では、スキャンアプリ１５１１、印刷アプリ１５１２、コピーアプリ１５１３、及びＦＡＸアプリ１５１４が例示されている。スキャンアプリ１５１１は、スキャンジョブを実行する。印刷アプリ１５１２は印刷ジョブを実行する。コピーアプリ１５１３は、コピージョブを実行する。ＦＡＸアプリ１５１４は、ＦＡＸの送信ジョブ又は受信ジョブを実行する。

コントロールサービス１５４は、各種のハードウェアリソース等を制御するための機能を上位アプリケーション等に対して提供したり、画像形成装置１０の基盤的な機能等を実行したりするソフトウェアモジュール群である。

ＳＤＫアプリ１５２は、画像形成装置１０の出荷後において、画像形成装置１０の機能拡張等を図るためのプラグインとして追加的にインストールされるアプリケーションプログラムである。したがって、ＳＤＫアプリ１５２の機能は、所定のものに限定されない。例えば、ＳＤＫアプリ１５２は、ＳＤカード８０から又はネットワークを介して画像形成装置１０にインストールされる。

ＳＤＫプラットフォーム１５３は、ＳＤＫアプリ１５２の実行環境を提供する。各ＳＤＫアプリ１５２は、ＳＤＫプラットフォーム１５３が提供するＡＰＩ（Application Program Interface）を利用して開発される。例えば、ＳＤＫプラットフォーム１５３は、スキャン機能を利用させるためのインタフェース、印刷機能を利用させるためのインタフェース、コピー機能を利用させるためのインタフェース等をＳＤＫアプリ１５２に提供する。なお、ＳＤＫプラットフォーム１５３のＡＰＩは公開されており、サードベンダ等によってもＳＤＫアプリ１５２は開発されうる。また、当該ＡＰＩは、異機種間において平滑化されている。したがって、ＳＤＫアプリ１５２に関して、機種に応じて異なる実装が行われる必要性は低い。

ＯＳ１５５は、いわゆるＯＳ（Operating System）である。画像形成装置１０上の各ソフトウェアは、ＯＳ１５５上においてプロセス又はスレッドとして動作する。

ＳＤＫアプリ１５２及びＳＤＫプラットフォーム１５３について、更に詳しく説明する。図５は、ＳＤＫアプリ及びＳＤＫプラットフォームの機能構成例を示す図である。

同図には、ＳＤＫアプリ１５２として、ＳＤＫアプリ１５２ａと、それ以外のＤＫアプリ１５２とが例示されている。ＳＤＫアプリ１５２ａは、本実施の形態においてアプリ状態管理部１５２ａとして機能するＳＤＫアプリ１５２である。以降では、他のＳＤＫアプリ１５２との混同を避けるため、ＳＤＫアプリ１５２ａを、「アプリ状態管理部１５２ａ」という。

アプリ状態管理部１５２ａは、自分（アプリ状態管理部１５２ａ）以外のＳＤＫアプリ１５２の状態の管理に利用される。同図において、アプリ状態管理部１５２ａは、通信制御部１６１、セット条件管理部１６２、セット条件判定部１６３、アプリ状態取得部１６４、及びセット条件記憶部１６５等を有する。

セット条件記憶部１６５は、例えば、ＮＶＲＡＭ１１５を用いて、一以上のセット条件を記憶する。セット条件とは、一又は複数ＳＤＫアプリ１５２の状態の組み合わせ（集合）に対する条件又は比較値をいう。セット条件を構成するＳＤＫアプリ１５２の組み合わせを「アプリセット」という。アプリセットを構成するＳＤＫアプリ１５２は、例えば、機能的な依存関係、又は流通単位に基づく関係等に基づいて任意に定められてよい。機能的な依存関係とは、例えば、或るＳＤＫアプリ１５２（例えば、「アプリＡ」という。）が、他の特定のＳＤＫアプリ１５２（例えば、「アプリＢ」という。）の機能を利用している関係をいう。流通単位に基づく関係とは、例えば、アプリＡとアプリＢとがパッケージングされて一つの商品として販売されている関係をいう。同一の流通単位を構成するＳＤＫアプリ１５２群の間には、基本的には機能的な依存関係が存在するケースが多いが、必ずしも機能的な依存関係が存在しなくてもよい。

セット条件管理部１６２は、セット条件記憶部１６５へのセット条件の記録（登録）や、セット条件記憶部１６５からのセット条件の取得及び加工等を行う。

アプリ状態取得部１６４は、各ＳＤＫアプリ１５２より、当該ＳＤＫアプリ１５２の状態を示す情報（状態情報）を取得する。すなわち、本実施の形態において、ＳＤＫアプリ１５２は、複数の状態を有し、所定のイベント（事象）の発生に応じて状態を変化（遷移）させる。

セット条件判定部１６３は、アプリ状態取得部１６４によって取得された状態情報に基づいて、セット条件記憶部１６５に記憶されている各セット条件の充足の有無（各セット条件が満たされているか否か）を判定する。

通信制御部１６１は、機器管理サーバ２０からのセット条件の判定要求を受信したり、セット条件判定部１６３による判定結果を機器管理サーバ２０に送信したりする。

アプリ状態管理部１５２ａ以外の各ＳＤＫアプリ１５２は、自アプリ状態通知部１７１、自アプリ状態保存部１７２、及び自アプリ状態記憶部１７３等を有する。

自アプリ状態通知部１７１は、例えば、ＲＡＭ１１２を用いて、当該ＳＤＫアプリ１５２の現在の状態を把握している。すなわち、自アプリ状態通知部１７１は、当該ＳＤＫアプリ１５２の現在の状態を示す状態情報をＲＡＭ１１２に記憶させている。自アプリ状態通知部１７１は、アプリ状態取得部１６４からの状態情報の取得要求応じ、ＲＡＭ１１２に記憶させている状態情報を応答する。

自アプリ状態保存部１７２は、当該ＳＤＫアプリ１５２が停止状態に移行する際に、自アプリ状態通知部１７１より状態情報を取得し、当該状態情報を自アプリ状態記憶部１７３に書き込む（保存する）。

自アプリ状態記憶部１７３は、例えば、ＮＶＲＡＭ１１５等を用いて状態情報を記憶する。すなわち、ＮＶＲＡＭ１１５中において、当該ＳＤＫアプリ１５２に関連付けられている記憶領域に当該ＳＤＫアプリ１５２の状態情報が記録される。

一方、ＳＤＫプラットフォーム１５３は、複合機クラスライブラリ１８１、仮想マシン１８２、ネイティブプログラムインタフェース１８３、及びアプリ管理部１８４等を有する。

複合機クラスライブラリ１８１は、ＳＤＫプラットフォーム１５３のＡＰＩを提供する、Ｊａｖａ（登録商標）のクラスライブラリである。当該ＡＰＩを介した要求は、必要に応じてコントロールサービス１５４に伝達される。コントロールサービス１５４による処理結果は、複合機クラスライブラリ１８１に返却される。複合機クラスライブラリ１８１は、当該処理結果を、上記ＡＰＩに即した形式に変換し、ＳＤＫアプリ１５２に返却する。

ネイティブプログラムインタフェース１８３は、複合機クラスライブラリ１８１からコントロールサービス１５４への要求の伝達等を、ＪＮＩ（Java（登録商標） Native Interface）の機構を用いて実現する。すなわち、コントロールサービス１５４は、ネイティブコードによって実装されているため、ネイティブプログラムインタフェース１８３が必要とされる。

仮想マシン１８２は、Ｊａｖａ（登録商標）のバイトコードによる命令の解釈及び実行を行う、いわゆるＪａｖａ（登録商標）仮想マシンである。各ＳＤＫアプリ１５２は、仮想マシン１８２によってスレッドとして起動される。

アプリ管理部１８４は、主としてＳＤＫアプリ１５２のライフサイクルを管理する。具体的には、アプリ管理部１８４は、ＳＤＫアプリ１５２をユーザに操作させるための管理画面を表示させる。アプリ管理部１８４は、当該管理画面を介した入力に応じ、ＳＤＫアプリ１５２のインストール、起動、停止、又はアンインストール等を実行する。アプリ管理部１８４は、また、画像形成装置１０にインストールされているＳＤＫアプリ１５２の一覧情報を、例えば、ＮＶＲＡＭ１１５を用いて管理する。

なお、ＪＳＤＫプラットフォーム１５３は、それ自身、画像形成装置１０にインストールされるアプリケーションの一種である。例えば、ＪＳＤＫプラットフォーム１５３は、ＳＤカード８０から又はネットワークを介して画像形成装置１０にインストールされる。なお、ＪＳＤＫプラットフォーム１５３は、ＳＤＫアプリ１５２とは異なり、コントロールサービス１５４上で一つのプロセスとして動作する。

続いて、本実施の形態におけるＳＤＫアプリ１５２が有する状態について説明する。図６は、ＳＤＫアプリが有する状態の例を説明するための図である。なお、図６において、各行の右端列に付与されている符号（ａ〜ｉ）は、以下の説明において、各状態に対して付与される符号である。

ＳＤＫアプリ１５２の状態は、まず、未インストール状態ｉとインストール済み状態とに大別される。未インストール状態ｉは、画像形成装置１０にインストールされていない状態をいう。インストール済み状態は、画像形成装置１０にインストールされている状態をいう。

インストール済み状態は、起動状態及び停止状態に大別される。起動状態は、ＳＤＫアプリ１５２がＲＡＭ１１２にロードされ、起動されている（例えば、スレッドとして起動されている）状態をいう。停止状態は、ＳＤＫアプリ１５２が停止している状態をいう。

起動状態のＳＤＫアプリ１５２は、活性化状態ａ、要設定状態ｂ、要機器再起動状態ｃ、又はエラー状態ｄのいずれかの状態にある。活性化状態ａは、ＳＤＫアプリが処理を正常に実行可能な状態をいう。要設定状態ｂは、インストール直後等、動作に必要な設定値が設定されていないため、起動されていても処理を正常に実行できない状態をいう。要機器再起動状態ｃとは、ＳＤＫアプリ１５２は起動されていて、画像形成装置１０の再起動が必要な状態をいう。例えば、ＳＤＫアプリ１５２の設定を変更した場合等において、設定をＳＤＫアプリ１５２の動作に反映するために画像形成装置１０の再起動が必要な場合がある。エラー状態ｄは、起動されているＳＤＫアプリ１５２が、何らかの異常により、正常に処理を実行できない状態をいう。なお、要設定状態ｂ又は要機器再起動状態ｃを有さないＳＤＫアプリ１５２が有ってもよい。

停止状態のＳＤＫアプリ１５２は、待機状態ｅ、要設定状態ｆ、要機器再起動状態ｇ、又はエラー状態ｈのいずれかの状態にある。待機状態ｅは、インストールされているＳＤＫアプリ１５２が起動していない状態をいう。要設定状態ｆは、ＳＤＫアプリ１５２が停止していて、動作に必要な設定値が設定されていない状態をいう。要機器再起動状態ｇは、ＳＤＫアプリ１５２が停止していて、画像形成装置１０の再起動が必要な状態をいう。エラー状態ｈは、ＳＤＫアプリ１５２が停止していて、エラーが発生している状態をいう。要設定状態ｆ又は要機器再起動状態ｇを有さないＳＤＫアプリ１５２が有ってもよい。

上記において説明した状態は、例えば、図７に示されるように遷移する。図７は、ＳＤＫアプリの状態遷移の一例を示す図である。

未インストール状態ｉのＳＤＫアプリ１５２が、自動起動の設定をＯＮとしてインストールされると、当該ＳＤＫアプリ１５２は、要設定状態ｂに遷移する。自動起動の設定とは、インストール後に自動的に起動するか（ＯＮ）否か（ＯＦＦ）に関する設定をいう。

要設定状態ｂのＳＤＫアプリ１５２が停止すると、当該ＳＤＫアプリ１５２は、要設定状態ｆに遷移する。この際、当該ＳＤＫアプリ１５２の自アプリ状態保存部１７２は、要設定状態ｆを示す状態情報を自アプリ状態記憶部１７３に記録する。要設定状態ｆのＳＤＫアプリ１５２が起動されると、当該ＳＤＫアプリ１５２は、要設定状態ｂに遷移する。この際、当該ＳＤＫアプリ１５２の自アプリ状態通知部１７１は、自アプリ状態記憶部１７３に記憶されている、要設定状態ｆを示す状態情報に基づいて、要設定状態ｂに遷移すべきことを判断し、要設定状態ｂを示す状態情報をＲＡＭ１１２に記録する。要設定状態ｂにおいて必要な設定値が設定されると、ＳＤＫアプリ１５２は、活性化状態ａに遷移する。

活性化状態ａのＳＤＫアプリ１５２が停止すると、当該ＳＤＫアプリ１５２は、待機状態ｅに遷移する。この際、当該ＳＤＫアプリ１５２の自アプリ状態保存部１７２は、待機状態ｅを示す状態情報を自アプリ状態記憶部１７３に記録する。待機状態ｅのＳＤＫアプリ１５２が起動されると、当該ＳＤＫアプリ１５２は、活性化状態ａに遷移する。

活性化状態ａにおいてエラーが発生すると、ＳＤＫアプリ１５２は、エラー状態ｄへ遷移する。エラー状態ｄのＳＤＫアプリ１５２が停止すると、当該ＳＤＫアプリ１５２は、エラー状態ｈに遷移する。この際、当該ＳＤＫアプリ１５２の自アプリ状態保存部１７２は、エラー状態ｈを示す状態情報を自アプリ状態記憶部１７３に記録する。エラー状態ｈのＳＤＫアプリ１５２が起動されると、当該ＳＤＫアプリ１５２は、エラー状態ｄに遷移する。エラー状態ｄにおいてエラーが解消されると、ＳＤＫアプリ１５２は、活性化状態ａに遷移する。

活性化状態ａにおいて設定値の変更が行われると、ＳＤＫアプリ１５２は、要機器再起動状態ｃへ遷移する。要機器再起動状態ｃのＳＤＫアプリ１５２が停止すると、当該ＳＤＫアプリ１５２は、要機器再起動状態ｇへ遷移する。この際、当該ＳＤＫアプリ１５２の自アプリ状態保存部１７２は、要機器再起動状態ｇを示す状態情報を自アプリ状態記憶部１７３に記録する。要機器再起動状態ｇのＳＤＫアプリ１５２が起動されると、当該ＳＤＫアプリ１５２は、要機器再起動状態ｃに遷移する。

一方、未インストール状態ｉのＳＤＫアプリ１５２が、自動起動の設定をＯＦＦとしてインストールされると、当該ＳＤＫアプリ１５２は、要設定状態ｆに遷移する。要設定状態ｆにおいて必要な設定値が設定されると、ＳＤＫアプリ１５２は、待機状態ｅに遷移する。

なお、図６及び図７に示される状態の種類及び状態の遷移は、一例である。したがって、異なる状態又は状態遷移が定義されてもよい。

以下、画像形成装置１０の処理手順について説明する。図８は、第一の実施の形態におけるセット条件の判定処理の処理手順の一例を説明するためのシーケンス図である。

ステップＳ１０１において、機器管理サーバ２０は、ユーザ端末３０からの要求の受信に応じ、セット条件の判定要求を画像形成装置１０に送信する。当該判定要求の送信先となる画像形成装置１０は、例えば、機器管理サーバ２０に予め識別情報（ＩＰアドレス等）が登録されている一以上の画像形成装置１０であってもよいし、ユーザ端末３０からの要求において指定されている一以上の画像形成装置１０であってもよい。

画像形成装置１０の通信制御部１６１は、当該判定要求を受信すると、当該判定要求をセット条件判定部１６３に入力する（Ｓ１０２）。セット条件判定部１６３は、当該判定要求の入力に応じ、問い合わせリストをセット条件管理部１６２に要求する（Ｓ１０３）。問い合わせリストとは、セット条件の充足の有無を判定するために、状態の問い合わせ対象とされる（状態を問い合わせる必要がある）ＳＤＫアプリ１５２のリスト（一覧）をいう。続いて、セット条件管理部１６２は、セット条件記憶部１６５を参照して、判定対象とすべきセット条件の有無を判定する（Ｓ１０４）。

図９は、第一の実施の形態におけるセット条件記憶部の構成例を示す図である。同図に示されるように、セット条件記憶部１６５は、セット条件ごとに、セット条件名、チェックフラグ、並びにプロダクトＩＤ及び状態の一以上の組み合わせを記憶している。

セット条件名は、セット条件の識別名である。チェックフラグは、セット条件の充足の有無の判定の要否を示すパラメータである。判定が必要なセット条件については「ｏｎ」が記録され、判定が不要なセット条件については「ｏｆｆ」が記録されている。

プロダクトＩＤは、セット条件を構成するＳＤＫアプリ１５２の識別情報である。状態は、プロダクトＩＤに係るＳＤＫアプリ１５２に関して、当該セット条件が満たされる場合の状態を示す状態情報である。一つのセット条件に、プロダクトＩＤと状態との組み合わせが一以上含まれている場合、各組み合わせの論理関係は、ＡＮＤ（論理積）として扱われる。但し、当該論理関係は、ＯＲ（論理和）として扱われてもよい。又は、各セット条件に当該論理関係を示すパラメータが付加されてもよい。なお、同図において、状態情報は、図６又は図７において各状態に付与された符号（ａ〜ｉ）によって示されている。

例えば、同図におけるセット条件Ａは、プロダクトＩＤが、ＡＡＡ、ＢＢＢ、ＣＣＣ、又はＤＤＤに係る各ＳＤＫアプリ１５２の状態が、活性化状態ａであることを充足条件とする。また、セット条件Ｂは、プロダクトＩＤが、ＡＡＡ又はＥＥＥに係るＳＤＫアプリ１５２の状態が、活性化状態ａであることを充足条件とする。

なお、同図では、チェックフラグが「ｏｎ」であるセット条件のみが示されているが、セット条件Ａ及びＢのチェックフラグが「ｏｆｆ」とされた場合、セット条件記憶部１６５は、例えば、図１０に示されるようになる。

図１０は、セット条件のチェックフラグがｏｆｆにされた例を示す図である。このように、チェックフラグの値を変化させることにより、ユーザの興味の対象に応じて、判定対象とするセット条件を限定することができる。例えば、動作状態を確認したいサービスに関するセット条件に限定して、充足の有無を判定させることができる。

ステップＳ１０４では、チェックフラグに基づいて、判定対象とすべきセット条件の有無が判定される。具体的には、チェックフラグが「ｏｎ」であるセット条件の有無が判定される。

チェックフラグが「ｏｎ」であるセット条件が有る場合、セット条件管理部１６２は、該当する全てのセット条件をセット条件記憶部１６５より取得する（Ｓ１０５）。続いて、セット条件管理部１６２は、取得されたセット条件に含まれているプロダクトＩＤの一覧を問い合わせリストとして生成する（Ｓ１０６）。この際、複数のセット条件に含まれている同一のプロダクトＩＤの重複は除去される。

図１１は、問い合わせリストの例を示す図である。同図では、図９のセット条件Ａ及びセット条件Ｂに基づいて生成される問い合わせリストが示されている。このように、問い合わせリストには、判定対象とされるセット条件の充足の有無を判定するために状態の問い合わせが必要な各ＳＤＫアプリ１５２のプロダクトＩＤが含まれる。

続いて、セット条件管理部１６２は、生成された問い合わせリストをセット条件判定部１６３に出力する（Ｓ１０７）。続いて、セット条件判定部１６３は、問い合わせリストを指定して、当該問い合わせリストに含まれている各ＳＤＫアプリ１５２の状態の問い合わせ結果（以下、「問い合わせ結果リスト」という。）の生成をアプリ状態取得部１６４に要求する（Ｓ１０８）。

続いて、アプリ状態取得部１６４は、画像形成装置１０にインストールされているＳＤＫアプリ１５２の一覧情報の取得をアプリ管理部１８４に要求する（Ｓ１０９）。アプリ管理部１８４は、インストール済みのＳＤＫアプリ１５２のプロダクトＩＤの一覧を例えば、ＮＶＲＡＭ１１５より取得し、取得されたプロダクトＩＤの一覧（以下、「インストール済みアプリリスト」という。）をアプリ状態取得部１６４に出力する（Ｓ１１０）。

図１２は、インストール済みアプリリストの例を示す図である。同図に示されるインストール済みアプリリストには、インストール済みのＳＤＫアプリ１５２ごとに、プロダクトＩＤと起動状態であるか停止状態であるかを示す情報とが含まれている。アプリ管理部１８４は、ＳＤＫアプリ１５２の起動又は停止制御を担う。したがって、アプリ管理部１８４は、各ＳＤＫアプリ１５２が、起動状態であるか停止状態であるかについては把握しているのである。但し、インストール済みアプリリストには、必ずしも起動状態であるか停止状態であるかを示す情報が含まれていなくてもよい。

続いて、アプリ状態取得部１６４は、問い合わせリストに含まれているＳＤＫアプリ１５２ごとに、状態の問い合わせ（状態情報の取得）を行う。具体的には、起動状態のＳＤＫアプリ１５２については、アプリ状態取得部１６４は、当該ＳＤＫアプリ１５２の自アプリ状態通知部１７１に対して、状態の問い合わせを行う（Ｓ１１１）。当該自アプリ状態通知部１７１は、問い合わせに応じ、当該ＳＤＫアプリ１５２の状態を示す状態情報をアプリ状態取得部１６４に出力する（Ｓ１１２）。また、停止状態のＳＤＫアプリ１５２については、アプリ状態取得部１６４は、当該ＳＤＫアプリ１５２の自アプリ状態記憶部１７３より、当該ＳＤＫ１５２の状態情報を取得する（Ｓ１１３、Ｓ１１４）。なお、問い合わせリストには含まれているが、画像形成装置１０にはインストールされていない（すなわち、インストール済みアプリリストに含まれていない）ＳＤＫアプリ１５２については、状態情報の問い合わせは行われない。この場合、当該ＳＤＫアプリ１５２の状態は、未インストール状態ｉと判定される。

問い合わせリストに含まれている全てのＳＤＫアプリ１５２に関して状態情報が取得されると、アプリ状態取得部１６４は、取得された状態情報に基づいて問い合わせ結果リストを生成する（Ｓ１１５）。

図１３は、問い合わせ結果リストの例を示す図である。同図に示されるように、問い合わせ結果リストは、図１１の問い合わせリストに含まれているＳＤＫアプリ１５２ごとに、当該ＳＤＫアプリ１５２の現在の状態を示す状態情報が付加されたものである。同図において、状態情報は、図６又は図７において各状態に付与された符号（ａ〜ｉ）によって示されている。

続いて、アプリ状態取得部１６４は、生成された問い合わせ結果リストをセット条件判定部１６３に出力する（Ｓ１１６）。続いて、セット条件判定部１６３は、チェックフラグが「ｏｎ」である各セット条件と問い合わせ結果リストとを照合することにより、セット条件ごとに充足の有無を判定する（Ｓ１１７）。

例えば、図９に示されるセット条件と、図１３に示される問い合わせ結果リストに基づいて判定が行われる場合、セット条件Ａは、満たされていないと判定される。プロダクトＩＤがＢＢＢ、ＣＣＣ、又はＤＤＤに係るＳＤＫアプリ１５２に関して、問い合わせ結果リストに含まれている状態情報が、セット条件Ａに合致しないからである。一方、セット条件Ｂは、満たされていると判定される。プロダクトＩＤがＡＡＡ又はＥＥＥの双方のＳＤＫアプリ１５２に関して、問い合わせ結果リストに含まれている状態情報が、セット条件Ｂに合致しているからである。

続いて、セット条件判定部１６３は、判定対象とされたセット条件ごとに、充足の有無を示す判定結果を通信制御部１６１に出力する（Ｓ１１８）。当該判定結果には、より詳細な情報が付加されてもよい。例えば、セット条件が満たされなかった理由となるＳＤＫアプリ１５２ごとに、状態情報が含まれていてもよい。または、セット条件を構成するＳＤＫアプリ１５２ごとに、現在の状態がセット条件に指定された状態に合致しているか否かを示す情報が含まれていてもよい。

続いて、通信制御部１６１は、当該判定結果を、ステップＳ１０１におけるセット条件の判定結果に対する応答として返信する（Ｓ１１９）。なお、当該判定結果を受信した機器管理サーバ２０は、例えば、当該判定結果を含む画面をユーザ端末３０に表示させる。当該画面は、例えば、Ｗｅｂページであってもよい。または、機器管理サーバ２０は、当該判定結果を含む電子メールをユーザ端末３０に送信してもよい。

ユーザは、ユーザ端末３０において表示される判定結果を参照して、各セット条件が満たされているか否かを確認することができる。

なお、図８において、アプリ状態管理部１５２ａによって実行される処理は、機器管理サーバ２０からのセット条件の判定要求に応じて開始される例を説明した。但し、アプリ状態管理部１５２ａによる処理は、機器管理サーバ２０からの要求以外のタイミングによって開始されてもよい。例えば、画像形成装置１０が起動されたときに開始されてもよいし、所定の間隔で周期的に開始されてもよい。この場合、アプリ状態管理部１５２ａによる判定結果は、いわゆるＰＵＳＨ型の通信形態によって、機器管理サーバ２０に送信されてもよい。機器管理サーバ２０は、当該判定結果をユーザ端末３０に転送する。そうすることにより、ユーザは、刻々と変化しうるセット条件の充足状態を、リアルタイムで観察することができる。

続いて、図８においてアプリ状態管理部１５２ａが実行する処理内容について、フローチャートを用いて詳細に説明する。

図１４は、アプリ状態管理部の処理手順の一例を説明するためのフローチャートである。同図において、括弧内のステップ番号は、図８において対応するステップのステップ番号を示す。

ステップＳ２０１において、セット条件判定部１６３は、問い合わせリストをセット条件管理部１６２に要求する。続いて、セット条件管理部１６２は、セット条件記憶部１６５に記録されている各セット条件のチェックフラグに基づいて、判定対象とすべきセット条件の有無を判定する（Ｓ２０２）。

チェックフラグが「ｏｎ」であるセット条件が有る場合（Ｓ２０２でＹｅｓ）、セット条件管理部１６２は、該当する全てのセット条件に含まれているプロダクトＩＤの一覧を問い合わせリストとして生成する（Ｓ２０３）。続いて、アプリ状態取得部１６４は、インストール済みアプリリストをアプリ管理部１８４より取得する（Ｓ２０４）。

続いて、アプリ状態取得部１６４は、問い合わせリストより、未処理の一つのプロダクトＩＤ（ＳＤＫアプリ１５２）を取得する（Ｓ２０５）。「未処理の」とは、ステップＳ２０６以降が実行されていないことをいう。該当するプロダクトＩＤが取得された場合（Ｓ２０６でＹｅｓ）、アプリ状態取得部１６４は、当該プロダクトＩＤに係るＳＤＫアプリ１５２（以下、「カレントアプリ」という。）がインストール済みか否かを判定する（Ｓ２０７）。具体的には、カレントアプリのプロダクトＩＤがインストール済みリストに含まれているか否かが判定される。

当該プロダクトＩＤがインストール済みリストに含まれている場合（Ｓ２０７でＹｅｓ）、アプリ状態取得部１６４は、カレントアプリが起動状態であるか否かを判定する（Ｓ２０８）。例えば、インストール済みアプリリストが図１２に示されるように、起動状態であるか否かを示す情報を含む場合、ステップＳ２０８の判定は、インストール済みアプリリストを参照することにより行われればよい。又は、アプリ状態取得部１６４は、カレントアプリに対して状態情報の取得要求を試みて、取得要求が正常に行えるか否かに応じて、カレントアプリが起動状態であるか否かを判定してもよい。

カレントアプリが起動状態である場合（Ｓ２０８でＹｅｓ）、アプリ状態取得部１６４は、カレントアプリの自アプリ状態通知部１７１に対して状態の問い合わせを行うことにより、状態情報を取得する（Ｓ２０９）。なお、インストール済みアプリリストに起動状態であることが示されているにも拘わらず、状態情報の問い合わせに対する応答が無い場合、アプリ状態取得部１６４は、カレントアプリはエラー状態ｄであると判定する。又は、アプリ状態取得部１６４は、直ちにエラー状態ｄであると判定せずに、一定期間後に問い合わせを繰り返してもよい。この場合、繰り返し回数又は問い合わせを繰り返す期間に制限（上限値）を設けておけばよい。

一方、カレントアプリが起動状態でない場合（Ｓ２０８でＮｏ）、アプリ状態取得部１６４は、カレントアプリの自アプリ状態記憶部１７３より、カレントアプリの状態情報を取得する（Ｓ２１０）。このように、自アプリ状態記憶部１７３に状態情報が保存されることにより、起動されていないＳＤＫアプリ１５２の状態情報が取得されうる。

続いて、アプリ状態取得部１６４は、カレントアプリに係るプロダクトＩＤ及び状態情報を問い合わせ結果リストに記録（追加）する（Ｓ２１１）。なお、ステップＳ２０７において、カレントアプリがインストール済みでないと判定された場合（Ｓ２０７でＮｏ）、未インストール状態ｉを示す情報がアプリの状態情報として記録される。

問い合わせリストに含まれている全てのＳＤＫアプリ１５２に関してステップＳ２０５以降の実行が完了すると（Ｓ２０６でＮｏ）、セット条件判定部１６３は、チェックフラグが「ｏｎ」である各セット条件と問い合わせ結果リストとを照合することにより、セット条件ごとに充足の有無を判定する（Ｓ２１２）。一方、チェックフラグが「ｏｆｆ」であるセット条件が有る場合（Ｓ２０２でＮｏ）、判定結果によって、判定対象が無いことを示す判定結果が生成される。続いて、通信制御部１６１は、セット条件判定部１６３による判定結果を出力（送信）する（Ｓ２１３）。

なお、セット条件の内容は、確認したい状態に応じて任意に設定可能である。例えば、図１５は、共存できないＳＤＫアプリが共存していないことを確認するためのセット条件の例を示す図である。共存とは、同じ画像形成装置１０にインストールされていることをいう。

同図に示されるセット条件Ｃは、プロダクトＩＤがＡＡＡ、ＢＢＢ、又はＣＣＣに係るＳＤＫアプリ１５２が活性化状態ａであり、プロダクトＩＤがＤＤＤに係るＳＤＫアプリ１５２が未インストール状態ｉである場合に満たされるセット条件である。したがって、セット条件Ｃの充足の有無によって、プロダクトＩＤがＡＡＡ、ＢＢＢ、又はＣＣＣに係るＳＤＫアプリ１５２と、プロダクトＩＤがＤＤＤに係るＳＤＫアプリ１５２との共存の有無を確認することができる。すなわち、セット条件Ｃが満たされている場合、当該共存は発生していないことが分かる。一方、セット条件Ｃが満たされていない場合、当該共存が発生している可能性が推測される。但し、ＳＤＫアプリ１５２の状態が未インストール状態ｉであっても、他のＳＤＫアプリ１５２の状態によってセット条件Ｃが満たされない場合もある。したがって、セット条件Ｃで確認したいことをより確実に確認できるように、各ＳＤＫアプリ１５２に対して、条件（比較値）としての状態を複数指定可能としてもよい。具体的には、セット条件Ｃに関しては、プロダクトＩＤが、ＡＡＡ、ＢＢＢ、又はＣＣＣのＳＤＫアプリ１５２に関して、未インストール状態ｉ以外の全ての状態が指定されてもよい。この場合、ＳＤＫアプリ１５２ごとに、複数指定されているいずれかの状態に合致すれば、当該ＳＤＫアプリ１５２の状態は、セット条件に指定された状態情報に合致することとすればよい。

または、図６若しくは図７より明らかなように、ＳＤＫアプリ１５２の状態には包含関係又は階層関係が存在しうる。例えば、インストール状態には、起動状態及び停止状態が含まれる。また、起動状態及び停止状態のそれぞれは、複数の状態を含む。このような階層関係において、任意の階層における状態を、セット条件において指定可能としてもよい。例えば、セット条件Ｃの場合、プロダクトＩＤがＡＡＡ、ＢＢＢ、又はＣＣＣのＳＤＫアプリ１５２に関して、インストール状態を示す状態情報が指定されてもよい。この場合、プロダクトＩＤがＡＡＡ、ＢＢＢ、又はＣＣＣに係るＳＤＫアプリ１５２が、インストール状態に含まれるいずれかの状態であり、ＤＤＤに係るＳＤＫアプリ１５２が、未インストール状態ｉであれば、セット条件Ｃは満たされると判定されればよい。

また、各セット条件は、それぞれ独立している。したがって、排他的な関係にある（相互に矛盾する）セット条件が設定され、同時に判定対象とされてもよい。

図１６は、排他的な関係にあるセット条件の例を示す図である。同図において、セット条件Ｄは、プロダクトＩＤがＢＢＢに係るＳＤＫアプリ１５２に関して、活性化状態ａであることを条件としている。一方、セット条件Ｅは、プロダクトＩＤがＢＢＢに係るＳＤＫアプリ１５２に関して、待機状態ｅであることを条件としている。ここで、活性化状態ａと待機状態ｅとは、排他的な関係にある状態である。したがって、セット条件Ｄとセット条件Ｅとは、同時に満たされることはない。しかし、このように排他的な関係にあるセット条件が同時に判定対象とされてもよい。排他的な関係にあるセット条件のうちのいずれが満たされているのかを、ユーザが確認したい場合も想定されうるからである。

また、セット条件の内容は、必ずしも肯定的な状態（望ましい状態）を示すものでなくてもよい。例えば、否定的な状態（望ましくない状態）を示すセット条件を設定しておき、当該セット条件の充足の有無を確認することで、望ましくない状態が発生していることが確認されてもよい。

上述したように、第一の実施の形態によれば、セット条件記憶部１６５にセット条件が登録され、複数のＳＤＫアプリ１５２の状態が各セット条件に合致するか否かによって、複数のＳＤＫアプリ１５２の状態が判定される。したがって、ＳＤＫアプリ１５２の状態の組み合わせに関して、確認したいものを予めセット条件記憶部１６５に登録しておくことにより、当該組み合わせが満たされているか否かを容易に確認することができる。

例えば、複数のＳＤＫアプリ１５２の連携によって構築されるサービスが有効であるか否かを確認したい場合は、当該サービスを構築する全てのＳＤＫアプリ１５２が活性化状態ａであることを示すセット条件を登録しておけばよい。

但し、セット条件の用途は、斯かるサービスの有効性の判定に限定されない。ユーザが確認したい状態を示す任意のセット条件が自由に登録されてよい。

次に、各画像形成装置１０に対してセット条件を簡便に設定する実施形態として、第二の実施の形態を説明する。第二の実施の形態では、第一の実施の形態と異なる点について説明する。したがって、特に言及しない点ついては、第一の実施の形態と同様でよい。

図１７は、第二の実施の形態における機器管理サーバの機能構成例を示す図である。同図において、機器管理サーバ２０は、セット条件統合記憶部２１及びセット条件提供部２２等を有する。これら各部は、機器管理サーバ２０にインストールされたプログラムが、機器管理サーバ２０のＣＰＵ２０４に実行させる処理により実現される。

セット条件統合記憶部２１は、機器管理サーバ２０の補助記憶装置２０２を用いて、複数の画像形成装置１０に設定されるべきセット条件を統合的に（例えば、一元的に）記憶する。セット条件統合記憶部２１の構造は、画像形成装置１０のセット条件記憶部１６５（例えば、図９参照）と同様でよい。但し、画像形成装置１０のセット条件記憶部１６５の記憶内容は、当該画像形成装置１０に関係するセット条件に限定されうるのに対し、セット条件統合記憶部２１の記憶内容は、複数の画像形成装置１０に関係するセット条件を含みうる点が異なる。

セット条件提供部２２は、セット条件統合記憶部２１に記憶されているセット条件を、画像形成装置１０に提供する。セット条件の提供に際し、セット条件提供部２２は、セット条件の提供先の画像形成装置１０において有効なセット条件に提供対象を限定する。

以下、第二の実施の形態の処理手順について説明する。図１８は、第二の実施の形態における画像形成装置へのセット条件の登録処理の処理手順の一例を説明するためのシーケンス図である。なお、第二の実施の形態では、同図の処理が実行される前において、画像形成装置１０のセット条件記憶部１６５にセット条件は登録されていなくてもよい。

所定のタイミングにおいて、セット条件管理部１６２は、セット条件記憶部１６５の更新処理を開始する（Ｓ３０１）。所定のタイミングとしては、画像形成装置１０の起動後であってもよいし、定期的なものであってもよい。又は、図８のステップＳ１０３において、セット条件判定部１６３より問い合わせリストを要求された後であって、ステップＳ１０４の前にステップＳ３０１が実行されてもよい。

続いて、セット条件管理部１６２は、セット条件の取得要求を、機器管理サーバ２０のセット条件提供部２２に送信する（Ｓ３０２）。当該取得要求には、当該画像形成装置１０にインストールされているＳＤＫアプリ１５２のプロダクトＩＤの一覧情報が指定される。当該一覧情報は、セット条件管理部１６２が、アプリ管理部１８４より取得すればよい。

当該取得要求に応じ、セット条件提供部２２は、取得要求元の画像形成装置１０へ提供対象とするセット条件をセット条件統合記憶部２１より検索（取得）する（Ｓ３０３）。提供対象とされるセット条件は、取得要求元の画像系生成装置１０において有効なセット条件に限定される。取得要求元の画像形成装置１０おいて有効なセット条件とは、当該セット条件の充足の有無を判定するために状態の問い合わせ先とされるＳＤＫアプリ１５２が、取得要求に指定されたプロダクトＩＤに係るＳＤＫアプリ１５２の範囲に限定されるセット条件をいう。すなわち、画像形成装置１０においてインストールされていないＳＤＫアプリ１５２に関する状態を構成要素とするセット条件は、基本的に当該画像形成装置１０において合致することは無く、実質的に無効なセット条件だからである。但し、未インストール状態ｉを状態に対する条件（比較値）として含むセット条件については、当該未インストール状態ｉの対象とされているＳＤＫアプリ１５２が、取得要求元の画像形成装置１０にインストールされていなくても、提供対象となりうる。

具体的には、ステップＳ３０３における取得要求に、プロダクトＩＤとしてＡＡＡ及びＢＢＢが含まれている場合において、図９に示されるセット条件Ａ及びセット条件Ｂがセット条件統合記憶部２１に記録されている場合、セット条件Ｂは、提供対象となるが、セット条件Ａは提供対象とはならない。一方、当該取得要求に、プロダクトＩＤとしてＡＡＡ、ＢＢＢ、及びＣＣＣが含まれている場合において、図１５に示されるセット条件Ｃがセット条件統合記憶部２１に記録されている場合、セット条件Ｃは、提供対象となる。セット条件Ｃでは、プロダクトＩＤがＤＤＤであるＳＤＫアプリ１５２も構成要素とされおり、当該ＳＤＫアプリ１５２は、取得要求元の画像形成装置１０にインストールされていない。しかし、当該ＳＤＫアプリ１５２に対する状態の条件は、未インストール状態ｉであるからである。

該当するセット条件が一以上検索された場合（Ｓ３０４）、セット条件提供部２２は、当該セット条件を、取得要求元の画像形成装置１０のセット条件管理部１６２に返信する（Ｓ３０５）。続いて、セット条件管理部１６２は、返信されたセット条件を、当該画像形成装置１０のセット条件記憶部１６５に登録（記録）する（Ｓ３０５）。同一のセット条件名を有するセット条件が既にセット条件記憶部１６５に登録されていた場合、当該セット条件は、上書き（更新）される。

一方、該当するセット条件が検索されなかった場合、画像形成装置１０のセット条件記憶部１６５へのセット条件の登録は実行されない。

上述したように、第二の実施の形態によれば、機器管理サーバ２０のセット条件統合記憶部２１に記憶されているセット条件が、自動的に各画像形成装置１０にダウンロードされ、セット条件統合記憶部２１に登録される。したがって、管理者等は、機器管理サーバ２０のセット条件統合記憶部２１に一元的にセット条件を登録しておけばよく、画像形成装置１０ごとにセット条件の登録作業を行う必要はない。また、ダウンロードされるセット条件は、ダウンロード先の画像形成装置１０におけるＳＤＫアプリ１５２のインストール状況に応じて限定される。したがって、各画像形成装置１０において、不要な記セット条件による記憶領域の消費を抑制することができる。

続いて、第二の実施の形態の変形例として第三の実施の形態を説明する。第三の実施の形態では、第二の実施の形態と異なる点について説明する。したがって、特に言及しない点ついては、第二の実施の形態と同様でよい。

図１９は、第三の実施の形態における画像形成装置へのセット条件の登録処理の処理手順の一例を説明するためのシーケンス図である。

図１９のステップＳ４０１〜Ｓ４０５の処理の流れは、図１８のステップＳ３０１〜Ｓ３０５と同様である。但し、ステップＳ４０２及びＳ４０３における処理内容に関して、ステップＳ３０２及びＳ３０３と異なる部分がある。

すなわち、ステップＳ４０２において、セット条件管理部１６２は、セット条件の取得要求に、当該画像形成装置１０にインストールされているＳＤＫアプリ１５２のプロダクトＩＤの一覧情報の他に、当該画像形成装置１０の機種名（機種情報）を指定する。

当該取得要求に応じ、セット条件提供部２２は、当該取得要求に応じ、取得要求元の画像形成装置１０へ提供対象とするセット条件をセット条件統合記憶部２１より検索（取得）する（Ｓ４０３）。

図２０は、第三の実施の形態におけるセット条件統合記憶部の構成例を示す図である。同図のセット条件統合記憶部２１では、各セット条件は機種名に関連付けられている。すなわち、各セット条件が有効な機種名が予め設定されている。

各ＳＤＫアプリ１５２がインストール可能な画像形成装置１０は、機種に依存する場合がある。ＳＤＫプラットフォーム１５３のＡＰＩは機種に対して平滑化されているものの、或る機種に特有の機能（特に、特別なハードウェアが必要とされる機能）を利用するＳＤＫアプリ１５２に関しては、当該機能を備えた機種でなければ有効に機能しない。第三の実施の形態では、ＳＤＫアプリ１５２と画像形成装置１０の機種との斯かる依存関係に鑑みて、セット条件が有効な範囲は、機種によって制限されうると考え、セット条件が機種名に関連付けられている。なお、同一の機種名に対して複数のセット条件が関連付けられていてもよい。同図においても、機種名「ＲＲＲ５０００」に対して、セット条件Ｆ及びセット条件Ｇが関連付けられている。また、同一のセット条件が複数の機種名に関連付けられていてもよい。

ステップＳ４０３では、取得要求に指定されている機種名に関連付けられているセット条件の範囲内で、第二の実施の形態と同様の処理内容によって、提供対象とされるセット条件が検索される。

ステップＳ４０４以降は、図１８のステップＳ３０４以降と同様でよい。

上述したように、第三の実施の形態によれば、第二の実施の形態と同様の効果を得ることができる。また、セット条件統合記憶部２１において、各セット条件は、機種名に関連付けられて登録されている。したがって、例えば、第二の実施の形態では提供対象とされうるセット条件であっても、機種に応じて提供対象から除外することができる。その結果、各画像形成装置１０により適したセット条件を登録することができる。

続いて、第二の実施の形態の変形例として第四の実施の形態を説明する。第四の実施の形態では、第二の実施の形態と異なる点について説明する。したがって、特に言及しない点ついては、第二の実施の形態と同様でよい。

図２１は、第四の実施の形態における機器管理サーバの機能構成例を示す図である。図２１中、図１７と同一部分には同一符号を付し、その説明は省略する。図２１において、機器管理サーバ２０は、機器情報記憶部２３を更に有する。機器情報記憶部２３は、例えば、機器管理サーバ２０の補助記憶装置２０２を用いて、画像形成装置１０ごとに当該画像形成装置１０にインストールされているＳＤＫアプリ１５２の一覧情報を記憶する。

図２２は、第四の実施の形態における画像形成装置へのセット条件の登録処理の処理手順の一例を説明するためのシーケンス図である。

ステップＳ５０１の処理内容は、図１８のステップＳ３０１と同じでよい。続いて、セット条件管理部１６２は、セット条件の取得要求を、機器管理サーバ２０のセット条件提供部２２に送信する（Ｓ５０２）。当該取得要求には、当該画像形成装置１０の機体ごとの識別情報（以下、「機器ＩＤ」という。）が指定される。

続いて、セット条件提供部２２は、当該取得要求に指定された機器ＩＤに基づいて、取得要求元の画像形成装置１０にインストールされているＳＤＫアプリ１５２の一覧情報を機器情報記憶部２３より取得する（Ｓ５０３、Ｓ５０４）。

図２３は、機器情報記憶部の構成例を示す図である。同図に示されるように、機器情報記憶部２３には、機器ＩＤごとに、当該機器ＩＤに係る画像形成装置１０にインストールされているＳＤＫアプリ１５２のプロダクトＩＤの一覧が記憶されている。なお、機器情報サーバ２０は、例えば、定期的に各画像形成装置１０に対してインストール済みのＳＤＫアプリ１５２の一覧情報を問い合わせ、当該問い合わせに対する応答として取得されるプロダクトＩＤの一覧を機器情報記憶部２３に記録すればよい。

したがって、ステップＳ５０４では、取得要求元の画像形成装置１０にインストールされているＳＤＫアプリ１５２のプロダクトＩＤの一覧が取得される。

ステップＳ５０５以降は、図１８におけるステップ３０３以降と同様でよい。すなわち、ステップＳ５０５におけるセット条件の検索には、ステップＳ５０４において取得されたプロダクトＩＤの一覧が用いられる。

上述したように、第四の実施の形態によれば、第二の実施の形態と同様の効果を得ることができる。また、画像形成装置１０から機器管理サーバ２０へのセット条件の取得要求には、プロダクトＩＤの一覧を含める必要はないため、通信負荷を低減させることができる。

なお、図２２の処理は、画像形成装置１０に対してＳＤＫアプリ１５２がインストールされたとき、又は画像形成装置１０からＳＤＫアプリ１５２がアインインストールされたときに実行されてもよい。この場合、ステップＳ５０２では、機器ＩＤと共に、インストール又はアンインストールされたＳＤＫアプリ１５２のプロダクトＩＤが指定される。セット条件提供部２２は、機器ＩＤと共に指定されたプロダクトＩＤがインストールされたＳＤＫアプリ１５２のものである場合、当該プロダクトＩＤを当該機器ＩＤに関連付けて機器情報記憶部２３に記録する。また、セット条件提供部２２は、機器ＩＤと共に指定されたプロダクトＩＤがアンインストールされたＳＤＫアプリ１５２のものである場合、当該プロダクトＩＤを、当該機器ＩＤに関連付けられて機器情報記憶部２３に記録されているプロダクトＩＤの中から削除する。その後、ステップＳ５０３以降が実行されればよい。

このような処理により、各画像形成装置１０におけるＳＤＫアプリ１５２の構成の変化を効率的に機器管理サーバ２０に通知することができる。また、機器管理サーバ２０における機器情報記憶部２３の記憶内容と、各画像形成装置１０におけるＳＤＫアプリ１５２の構成とを同期させることができる。したがって、画像形成装置１０におけるＳＤＫアプリ１５２の現在の構成に対応したセット条件が、画像形成装置１０に登録される可能性を高めることができる。

更に、第四の実施の形態に、第三の実施の形態が組み合わされてもよい。すなわち、機器管理サーバ２０のセット条件統合記憶部２１が、図２０に示されるように構成されてもよい。この場合、ステップＳ５０２のセット条件の取得要求には、機器ＩＤに加え、機種名が指定されればよい。ステップＳ５０５以降は、図１９のステップＳ４０３以降と同様の処理が実行されればよい。

なお、第二から第四の実施の形態では、画像形成装置１０にとって有効なセット条件の抽出が機器管理サーバ２０において実行される例について説明した。但し、斯かる抽出は、画像形成装置１０において行われてもよい。この場合、機器管理サーバ２０は、セット条件統合記憶部２１に記録されている全てのセット条件を画像形成装置１０に転送すればよい。画像形成装置１０のセット条件管理部１６２は、第二から第四の実施の形態において機器管理部サーバ２０のセット条件提供部２２が行った処理と同様の処理を実行して、受信されたセット条件の中から当該画像形成装置１０にとって有効なセット条件を抽出し、セット条件記憶部１６５に記録すればよい。

また、上記の各実施の形態では、アプリ状態管理部１５２ａが一つのＳＤＫアプリ１５２ａとして実装される例について説明した。このような実施形態は、既に市場に流通している画像形成装置１０を用いて本実施の形態を実施する際に特に有効である。アプリ状態管理部１５２ａとしてのＳＤＫアプリ１５２ａを斯かる画像形成装置１０にインストールすればよいからである。

すなわち、本実施の形態において、アプリ状態管理部１５２ａが一つのＳＤＫアプリ１５２ａとして構成される例を説明したのは、既に市場に流通している画像形成装置１０の利便性を考慮したためであり、技術的な制約に基づくものではない。したがって、アプリ状態管理部１５２ａは、例えば、ＳＤＫプラットフォーム１５３内に実装されてもよい。

図２４は、アプリ状態管理部がＳＤＫプラットフォームの一部として実装される例を示す図である。図２４中、図５と同一部分には同一符号を付し、その説明は省略する。

同図において、アプリ状態管理部１５２ａは、ＳＤＫプラットフォーム１５３に含まれている。このような構成では、アプリ状態管理部１５２ａとしてのＳＤＫアプリ１５２ａをインストールしなくとも、アプリ状態管理部１５２ａの機能を実現することができる。但し、既に市場に流通している画像形成装置１０に関しては、ＳＤＫプラットフォーム１５３のバージョンアップ等が必要とされる。

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

１ 機器管理システム
１０ 画像形成装置
１１ コントローラ
１２ スキャナ
１３ プリンタ
１４ モデム
１５ 操作パネル
１６ ネットワークインタフェース
１７ ＳＤカードスロット
２０ 機器管理サーバ
２１ セット条件統合記憶部
２２ セット条件提供部
２３ 機器情報記憶部
３０ ユーザ端末
４０ ネットワーク
８０ ＳＤカード
１１１ ＣＰＵ
１１２ ＲＡＭ
１１３ ＲＯＭ
１１４ ＨＤＤ
１１５ ＮＶＲＡＭ
１５１ 標準アプリ
１５２ ＳＤＫアプリ
１５２ａ アプリ状態管理部
１５３ ＳＤＫプラットフォーム
１５４ コントロールサービス
１５５ ＯＳ
１６１ 通信制御部
１６２ セット条件管理部
１６３ セット条件判定部
１６４ アプリ状態取得部
１６５ セット条件記憶部
１７１ 自アプリ状態通知部
１７２ 自アプリ状態保存部
１７３ 自アプリ状態記憶部
１８１ 複合機クラスライブラリ
１８２ 仮想マシン
１８３ ネイティブプログラムインタフェース
１８４ アプリ管理部
２００ ドライブ装置
２０１ 記録媒体
２０２ 補助記憶装置
２０３ メモリ装置
２０４ ＣＰＵ
２０５ インタフェース装置
１５１１ スキャンアプリ
１５１２ 印刷アプリ
１５１３ コピーアプリ
１５１４ ＦＡＸアプリ
Ｂ バス

特開２００４−３１２７１１号公報

Claims (13)

1. 複数の状態を有するプログラムをインストール可能な画像形成装置であって、
   一又は複数の前記プログラムの状態の組み合わせに対する条件を一以上記憶した条件記憶手段と、
   当該画像形成装置にインストールされている前記各プログラムの前記状態情報を取得する状態取得手段と、
   前記条件ごとに、前記状態取得手段によって取得された前記状態情報に基づいて充足の有無を判定し、判定結果を出力する状態判定手段とを有する画像形成装置。
2. 前記条件記憶手段は、前記条件ごとに充足の有無の判定対象とするか否かを示す情報を記憶し、
   前記状態判定手段は、該判定対象とされている前記条件について充足の有無を判定する請求項１記載の画像形成装置。
3. 前記状態取得手段は、前記プログラムより前記状態情報を取得する請求項１又は２記載の画像形成装置。
4. 前記状態取得手段は、起動されていない前記プログラムについては、当該プログラムに関連付けられている状態記憶手段より前記状態情報を取得する請求項３記載の画像形成装置。
5. 前記条件は、一つのプログラムに関して複数の状態を含みうる請求項１乃至４いずれか一項記載の画像形成装置。
6. 複数の状態を有するプログラムをインストール可能な画像形成装置が、
   当該画像形成装置にインストールされている前記各プログラムの状態情報を取得する状態取得手順と、
   条件記憶手段に記憶された、一又は複数の前記プログラムの状態の組み合わせに対する条件ごとに、前記状態取得手順において取得された前記状態情報に基づいて充足の有無を判定し、判定結果を出力する状態判定手順とを実行するプログラム状態判定方法。
7. 複数の状態を有するプログラムをインストール可能な画像形成装置に、
   当該画像形成装置にインストールされている前記各プログラムの状態情報を取得する状態取得手順と、
   条件記憶手段に記憶された、一又は複数の前記プログラムの状態の組み合わせに対する条件ごとに、前記状態取得手順において取得された前記状態情報に基づいて充足の有無を判定し、判定結果を出力する状態判定手順とを実行させるプログラム状態判定プログラム。
8. 複数の状態を有するプログラムをインストール可能な画像形成装置と、該画像形成装置とネットワークを介して通信可能な情報処理装置とを有するプログラム状態判定システムであって、
   前記情報処理装置は、
   一又は複数の前記プログラムの状態の組み合わせに対する条件を一以上記憶した条件統合記憶手段と、
   前記条件統合記憶手段に記憶された条件を前記画像形成装置に送信する条件提供手段とを有し、
   前記画像形成装置は、
   前記条件提供手段によって送信される前記条件を受信し、条件記憶手段に記録する条件管理手段と、
   当該画像形成装置にインストールされている前記各プログラムの前記状態情報を取得する状態取得手段と、
   前記条件記憶手段に記録されている前記条件ごとに、前記状態取得手段によって取得された前記状態情報に基づいて充足の有無を判定し、判定結果を出力する状態判定手段とを有するプログラム状態判定システム。
9. 前記条件管理手段は、当該画像形成装置にインストールされている前記プログラムの一覧情報を前記情報処理装置に送信し、
   前記条件提供手段は、前記一覧情報に基づいて前記画像形成装置に送信する前記条件を限定する請求項８記載のプログラム状態判定システム。
10. 前記条件統合記憶手段は、前記条件を前記画像形成装置の機種情報に関連付けて記憶し、
    前記条件管理手段は、当該画像形成装置にインストールされている前記プログラムの一覧情報及び当該画像形成装置の機種情報を前記情報処理装置に送信し、
    前記条件提供手段は、前記機種情報に関連付けられている前記条件の中で、前記一覧情報に基づいて前記画像形成装置に送信する前記条件を限定する請求項９記載のプログラム状態判定システム。
11. 前記情報処理装置は、
    前記画像形成装置にインストールされている前記プログラムの一覧情報を前記画像形成装置の識別情報に関連付けて記憶する機器情報記憶手段を有し、
    前記条件管理手段は、当該画像形成装置の識別情報を前記情報処理装置に送信し、
    前記条件提供手段は、受信された前記識別情報に関連付けられて前記機器情報記憶手段に記憶されている前記一覧情報に基づいて前記画像形成装置に送信する前記条件を限定する請求項８記載のプログラム状態判定システム。
12. 前記条件管理手段は、当該画像形成装置への前記プログラムのインストールに応じ、当該画像形成装置の識別情報と当該プログラムの識別情報とを前記情報処理装置に送信し、
    前記条件提供手段は、受信された前記画像形成装置の識別情報に関連付けられて前記機器情報記憶手段に記憶されている前記一覧情報に、前記インストールに係る前記プログラムの識別情報を追加する請求項１１記載のプログラム状態判定システム。
13. 前記条件管理手段は、当該画像形成装置からの前記プログラムのアンインストールに応じ、当該画像形成装置の識別情報と当該プログラムの識別情報とを前記情報処理装置に送信し、
    前記条件提供手段は、受信された前記画像形成装置の識別情報に関連付けられて前記機器情報記憶手段に記憶されている前記一覧情報より、前記アンインストールに係る前記プログラムの識別情報を削除する請求項１１又は１２記載のプログラム状態判定システム。

Images