JP2011048716A - 画像処理システム、管理装置、画像処理装置、管理方法、プログラムおよび記録媒体 - Google Patents

Abstract

【課題】 ネットワーク上でワークフローに使用するリソースを更新すること。
【解決手段】 本発明の管理装置３２０は、フロー定義の内容変更に対応して、管理対象の画像処理装置３４０が保有するプラグインプログラムを記録するリモート環境データ３４２を取得する手段と、フロー定義に対応して管理対象の画像処理装置３４０に保有させるべきプラグインプログラムを記録するプラグイン環境データ３２４を生成する手段と、これらの差分を記録する差分データを生成する手段と、画像処理装置３４０のプラグインプログラムの実行基盤環境を記述する基盤環境データ３４４を取得する手段と、差分データおよび基盤環境データ３４４を読み込んで、プラグインプログラムの提供の適否および提供するバージョンを判断する手段と、判断する手段の判断に応じてプラグイン環境の構築を指示する設定データを画像処理装置に送信する手段とを含む。
【選択図】 図３

Description

本発明は、ネットワークを利用したワークフロー技術に関し、より詳細には、ネットワーク上でワークフローに使用するリソースを更新する画像処理システム、管理装置、画像処理装置、管理方法、プログラムおよび記録媒体に関する。

近年、企業や官公庁などにおいては、業務効率化を図るために、複合機などの画像処理装置と、パーソナル・コンピュータやサーバなどとをネットワークを介して連携させ、所定のワークフローに従った紙文書の電子化および配布を効率的に実現する文書配信システムが普及しつつある。

例えば、特開２００８−９７５８６号公報（特許文献１）は、フロー定義データに基づいて、スキャン画像データに対して一または複数の処理の実行を制御するフロー実行制御部と、処理を実行する際に、画面定義データを複合機に送信して、画面定義データに基づいて複合機に表示された書誌情報入力画面から入力された書誌情報を受信するリモート通信部とを備える配信サーバを開示する。特許文献１の配信サーバでは、受信した書誌情報とフロー定義データとが関連付けられ、書誌情報が関連付けられたフロー定義データに基づいて、スキャン画像データに対して画像変換やメール配信やフォルダ配信といった一または複数の処理の実行が制御される。そして、受信した書誌情報に応じた一連の文書配信フローが実現される。

上述のような文書配信システムでは、画像処理装置をそれぞれハードウェア機能が異なるネットワークノードとして認識した場合、ネットワークを介して予め設定された処理シーケンスに従ってこれらネットワークノードを機能させることにより、効率的な電子文書の配信フローが実現される。

上記システムの運用にあっては、特定のデータについて必要となる処理シーケンスは、ユーザやユーザグループに依存して、また業務プロセスの変更等に伴って修正されることが多い。処理シーケンスが修正されると、ネットワークノードが実行すべき処理が変更される場合も想定される。処理シーケンスの修正に対応して特定のネットワークノードが実行する処理を修正する必要がある場合、常時そのネットワークノードが当該処理を実行できるアプリケーション環境を保有しているとは限らない。

このような場合に、例えば特開２００７−２８１７８２号公報（特許文献２）は、画像処理装置に対するソフトウェア機能を拡張する目的で追加機能を提供するために、プラグインプログラムを画像形成装置に追加する技術を開示している。

上記特許文献２に開示される技術を利用することによって、画像処理装置などに対してプラグインプログラムを送付してソフトウェア機能を拡張することは可能である。一方、複合機などの画像処理装置は、本来的には画像を処理する役割が求められ、画像処理を実現するために最小限に必要とされている以上の記憶領域を確保しなければならない。このため、処理シーケンスの修正に対応して無制限にソフトウェア機能を拡張することは妥当ではない。

さらに、上述したネットワーク環境においては、プラットフォーム環境のバージョンが異なる画像処理装置が混在する場合があり、対応しないプラットフォーム環境のバージョンの画像処理装置に誤ってプラグインプログラムをインストールしてしまう可能性がある。さらに、メモリ容量等のハードウェア性能が異なる画像処理装置が混在するネットワーク環境では、ハードウェア資源を多く使用するプラグインプログラムを一括でインストールした場合、性能の低い画像処理装置でメモリ不足を引き起こしてしまい、アプリケーションが動作しなくなることも想定される。

したがって、処理シーケンスの変更、すなわちワークフロー定義の修正に対応し、プラグインプログラムの配布先の画像処理装置のプラットフォーム環境のバージョンやハードウェア資源に関する情報を含む実行基盤環境に応じて、インストールするプラグインプログラムのバージョンを変更したり、プラグインプログラムを配布するか否かを判断したりするというような、プラグインプログラムの配布処理を柔軟かつ動的に制御することができる技術の開発が望まれていた。さらに、ワークフロー定義の設定の更新を柔軟に行いながら、処理シーケンスを実行するためのハードウェア資源およびソフトウェア資源の省資源化を可能とする技術が必要とされていた。

本発明は、上記従来技術の問題点を鑑みてなされたものであり、本発明は、定義されるワークフローの修正に対応して、配布先のプラグインプログラムの実行基盤環境に応じて、柔軟かつ動的に、当該プラグインプログラム等の適切なリソースの配布処理を制御することができ、ひいてはワークフローの実行環境を効率的に構築することを可能とする画像処理システム、管理装置、画像処理装置、管理方法、プログラムおよび記録媒体を提供することを目的とする。

本発明は、上記課題を解決するために、ネットワークに接続される画像処理装置および管理装置を含む画像処理システムを提供する。本発明による画像処理システムにおける管理装置は、画像データに対して複数の処理を連続して実行するためのフロー定義の内容変更に対応して、管理対象の画像処理装置が保有するプラグインプログラムを記録するリモート環境データを生成するとともに、フロー定義に対応して管理対象の画像処理装置に保有させるべきプラグインプログラムを記録するプラグイン環境データを生成し、これらリモート環境データとプラグイン環境データとの差分を記録する差分データを生成する。

そして、管理装置は、管理対象の画像処理装置のプラグインプログラムの実行基盤環境を記述する基盤環境データを取得し、上述した差分データおよびこの基盤環境データを読み込んで、プラグインプログラムの提供の適否および提供するバージョンを判断し、この判断に応じてプラグイン環境の構築を指示する設定データを画像処理装置に送信する。一方、画像処理装置では、管理装置から受信した上記設定データに従って自身のプラグイン環境が更新される。

さらに本発明では、上述した基盤環境データは、管理対象の画像処理装置が備えるプラットフォーム環境のバージョン値を含むことができ、管理装置は、これを用いて、フロー定義に適合し、かつ管理対象の画像処理装置のプラットフォーム環境のバージョン値に適合するプラグインプログラムのバージョンを判断することができる。なお、画像処理装置側のバージョンに適合しなければ、フロー定義データの配布を中止する制御とすることができる。

また本発明では、上述した基盤環境データは、管理対象の画像処理装置が備えるハードウェア資源の情報を含み、管理装置は、これを使用して、管理対象の画像処理装置のハードウェア資源の情報を参照し、プラグイン環境を構築するために必要な資源が確保されているか否かを判断することができる。また本発明では、判断に応じたプラグイン環境を構築するために必要なハードウェア資源量の合計値と、上記基盤環境データのハードウェア資源の情報とを比較することで、プラグインプログラムの提供の適否を判断することができる。

さらに本発明では、管理装置は、管理対象の画像処理装置に組み込まれたプラグインプログラムうちのフロー定義に不要なものを無効化して必要なハードウェア資源量の合計値を確保できるか否かを判断することにより、プラグインプログラムの提供の適否を判断することができる。また本発明では、管理装置は、上記設定データの送信と同時に、またはそれと前後して、適切なバージョンのプラグインプログラムをインストールするためのリソースをさらに送信することができる。また本発明では、上述した設定ファイルは、管理対象の画像処理装置に組み込まれたプラグインプログラムの有効化または無効化を指令する動作状態属性値を含むことができる。さらに、フロー定義に対応して管理対象の画像処理装置に保有させるべきプラグインプログラムを記録するプラグイン環境データは、ユーティリティノードに構築されたプラグイン環境から構成することができる。

さらにまた本発明では、ネットワークを介して画像処理装置に接続される管理装置が実行する方法、該管理装置上に上記各機能手段を実現する装置実行可能なプログラム、該プログラムを格納する装置可読な記録媒体が提供される。また本発明では、管理装置は、個別のサーバ装置として構成することができ、または画像処理装置と一体として構成することができる。

本発明によれば、画像処理装置側のプラグインプログラムの実行基盤環境に対応して、プラグインプログラムの提供の適否およびその適合するバージョンの判断がなされ、画像処理装置上に適切なプラグイン環境が構築されることとなる。したがって、画像処理システムを管理するユーザは、各画像処理装置のハードウェア資源やソフトウェア資源等の有無を含め実行基盤環境の相違を意識しなくても、一括に複数の画像処理装置に対してプラグイン環境の更新を行うことができ、ひいてはワークフローの実行環境を効率的に構築することが可能となる。

本実施形態のワークフローシステムを示す図 本実施形態のネットワークノードの機能ブロック図。 本実施形態のワークフローシステムにおけるネットワークノード間のデータフロー図。 本実施形態のユーティリティノードのプラグイン更新部が実行する処理のフローチャート。 本実施形態のユーティリティノードのプラグイン更新部が実行するリソース判断処理のフローチャート。 本実施形態のプラグイン環境ファイルおよびリモート環境ファイルのデータ構造を例示する図。 本実施形態の差分ファイルのデータ構造を例示する図。

以下、本発明の実施形態を説明するが、本発明の実施形態は、以下の実施形態に限定されるものではない。図１は、本実施形態のワークフローシステム１００を示す。ワークフローシステム１００は、パーソナルコンピュータ、ワークステーション、サーバ、画像処理装置などネットワークに接続可能な情報処理装置を含み、本実施形態の画像処理システムを構成する。以下、ネットワークに接続可能な情報処理装置のうち、ワークフローの処理を担当する情報処理装置をネットワークノードとして参照する。ネットワークノードは、ユーティリティノードと、ユーティリティノードの機能を有しない作業ノードとを含んでいる。

ユーティリティノードは、ワークフローの定義を設定し、ワークフローシステム１００におけるネットワークノードを管理する機能を有し、本実施形態の管理装置を構成する。また、ユーティリティノードは、インターネットやイントラネットなどを介してワークフロー定義を取得し、バージョン変更やワークフロー定義の追加などを行う。また、ユーティリティノードは、ワークフロー定義の修正に際して、不要となるプラグインプログラムが発生する場合、作業ノードに対して不要なプラグインプログラムのプラグイン識別値（以下、プラグインＩＤとして参照する。）を指定し、作業ノードに対してアンインストール処理などを指示する。

作業ノード１５０，１６０は、ユーティリティノード１１０からのワークフロー定義を受領し、受領したワークフロー定義に従った処理を実行する。また作業ノード１５０，１６０には、受領したワークフロー定義に対応し、処理のために必要なプラグインプログラム（以下、単にプラグインと参照する。）がインストールされている。図１に示す本実施形態のワークフローシステム１００は、ユーティリティノード１１０を、コンピュータ１２０または画像処理装置１３０として実装することができる。コンピュータ１２０は、パーソナルコンピュータ、ワークステーション、またはサーバといった汎用的なアプリケーションを実行できる情報処理装置から選択することができる。

画像処理装置１３０は、専ら画像処理を実行する機能を備えるほか、Ｊａｖａ（登録商標）、ブラウザプログラム、ファイル転送、メール機能、持続的ストレージ機能などを有し、ＨＴＭＬ、ＸＭＬなどの構造化文書パーザを備える、いわゆるＭＦＰ(Multi-Function Peripheral)として参照される上位機種として構成することができる。また、各ネットワークノードは、ＸＭＬ−ＡＴＯＭ、ＳＯＡＰなど、ＸＭＬなどを介してデータの共有化を行うことが可能とされていることが好ましい。

ユーティリティノード１１０は、ワークフローシステム１００において複数設置される必要はなく、ワークフローを担当する作業ノードの集合に対して最低１ノード設置するだけでよい。ただし、特定のワークフローシステム１００において機能冗長性を付与したり、機能を分離させて利用することが好ましい場合などには、特定のワークフローシステム１００内に複数ユーティリティノード１１０を設置し、各ユーティリティノード１１０それぞれに独立に管理すべき作業ノードの集合を設定することもできる。また、さらに他の実施形態では、単一のユーティリティノード１１０を用いて、複数の集合を独立して管理するよう構成してもよい。さらにユーティリティノード１１０を、画像処理装置１３０として実装する場合、ユーティリティノード１１０は、それ自身がワークフロー定義上の作業ノードとして機能することができる。

ユーティリティノード１１０は、ワークフロー定義をプロファイル１４０として、管理対象の作業ノード１５０，１６０に送付して、ワークフローでのノードとして機能させる。プロファイル１４０は、本実施形態では、ＸＭＬといった構造化文書で作成されている。また、プロファイル１４０は、複数の異なる作業項目、例えば、画像取得、メール配信、ファイルアップロード、フォルダ格納などの作業項目が階層ノードを構成し、プロジェクトとして参照される単位で、一連の処理シーケンスが規定される。各プロジェクトは、特定のユーザグループ毎にグループ単位でまとめて管理されることもある。

プロファイル１４０は、例えば、画像取得→フォーマット変換→ファイルアップロードといった複数の処理作業を、プロジェクトの階層構造としてひとつのワークフローを定義付ける。作業ノード１５０，１６０は、プロファイル１４０内の所定のプロジェクトの階層構造を解釈しながら処理を実行し、また自己の担当するワークフロー上の役割を負担することができる。なお、本実施形態で、プロファイル１４０をＸＭＬとして構成する場合、各プロジェクトは、例えば＜Project＞、＜/Project＞などといったＸＭＬタグで指定されるノードとして記述され、各プロジェクトが利用するべき制御データが、＜Project＞、＜/Project＞タグの間に各種制御のためのデータタグなどにより記述される。この制御データは、上記作業項目で使用するプラグインプログラムのＩＤおよび必要なバージョン情報などを含む。

また、ユーティリティノード１１０は、作業ノード１５０，１６０が、送付するプロファイル１４０で指定される機能を提供するために必要十分のプラグインプログラム環境となるように各作業ノード１５０，１６０を管理している。

作業ノード１５０，１６０は、それぞれ独立してプロファイル１４０に定義されたワークフローを実行し、例えばファイルサーバとして機能する画像処理装置１８０やサーバ１９０へと取得したデータをアップロードする。フォルダ格納、メール配信、ファイルアップロードなどの機能は、それぞれ、ファイル共有機能、メールサーバを使用してＳＭＴＰプロトコルを利用するメール転送機能、ＦＴＰやＨＴＴＰプロトコル、その他、適宜セキュリティレベルに応じたプロトコルを利用するファイル転送機能を利用して実装することができる。

ワークフローシステム１００は、また、上述したプラグインプログラム環境を構築するための各プラグインのインストール用モジュールを配布するリソースサーバ１７０を含む。リソースサーバ１７０は、各プラグインのインストール用リソースを複数のバージョンについて保持および管理し、ユーティリティノード１１０からのインストール用リソースの取得要求を受け、所望のリソースを提供している。

本発明の要旨ではないが、ネットワークノードやユーティリティノードなどを構成するコンピュータおよび画像処理装置は、概ね同様のハードウェア構成を採用することができ、Ｐｅｎｔｉｕｍ（登録商標）、Xeon（登録商標）、Ｐｅｎｔｉｕｍ（登録商標）互換チップなど、ＣＩＳＣアーキテクチャのマイクロプロセッサ、または、ＰｏｗｅｒＰＣ（登録商標）などのＲＩＳＣアーキテクチャのマイクロプロセッサを、シングルコアまたはマルチコアの形態で実装することができる。

また、各ノードは、Ｗｉｎｄｏｗｓ（登録商標）２００Ｘ、ＵＮＩＸ（登録商標）、Ｌｉｎｕｘ（登録商標）などのオペレーティングシステム（ＯＳ）により制御されていて、Ｃ、Ｃ＋＋、Ｊａｖａ（登録商標）、ＪａｖａＳｃｒｉｐｔ（登録商標）、ＰＥＲＬ、ＲＵＢＹなどのプログラミング言語を使用して実装される、アプリケーションプログラムを実行し、ワークフローシステム１００上のネットワークノードとして機能するための機能手段として情報処理装置および画像処理装置を機能させている。各ノードは、またその処理の必要性に応じて、ＩｎｔｅｒｎｅｔＥｘｐｌｏｒｅｒ（登録商標）、Ｍｏｚｉｌｌａ（登録商標）、Ｏｐｅｒａ（登録商標）、ＦｉｒｅＦｏｘ（登録商標）などのブラウザ・ソフトウェアを実装することができる。

図２は、本実施形態のネットワークノードの機能ブロック２００を示す。図２に示すように、ネットワークノードは、入出力制御部２１０と、画像読み取り制御部２２０と、配信制御部２３０とを含んで構成されている。入出力制御部２１０は、ネットワークノードの実装形式に対応して、オペレーションパネル制御を行うことができる。また、ネットワークノードが、ブラウザプログラムなどを実装する場合、オペレーションパネルからのキー入力の他、ネットワークノードが備えるビデオモニタを介してブラウザプログラムが提供する制御用ウィンドウを表示させてもよい。

画像読み取り制御部２２０は、ネットワークノードが含むスキャナ、ソータなどのスキャナエンジンに指令を与え、画像処理機能を制御し、ネットワークノードに対して画像データ、テキストデータなどを取得させている。配信制御部２３０は、プロファイル１４０で指定されるワークフロー定義にしたがってネットワークノードが取得したデータを処理するためのプラグインを管理し、ワークフロー定義にしたがって各種のプラグインを呼び出して、データに対して処理を施し、またネットワークノードから、ローカルエリアネットワーク（ＬＡＮ）２７０を介してファイルサーバ、フォルダ、メールサーバなどの各種機能部２９０へと外部通信を行う。

上述した機能を提供するため、配信制御部２３０は、プラグイン管理部２４０と、外部通信処理部２６０とを含んで構成されている。プラグイン管理部２４０は、ユーティリティ機能部２８０が提供するインストール／アンインストールを指示する情報を取得し、プラグイン２５０のインストール、アンインストールを実行する。なお、インストール／アンインストールにより追加／削除される任意の機能をオプション機能と参照する。また、プラグイン管理部２４０は、組み込み済み（以下、ビルトイン機能と参照する）のプラグインについて、ユーティリティ機能部２８０から送付されるプラグインの有効化／無効化を指示する情報を取得し、これに従ってビルトイン機能のプラグインを有効化または無効化し、以後のプロジェクト実行を管理する。なお、無効化されたビルトイン機能のプラグインは、アンロードされ、また起動時にシステムにロードされなくなり、その機能のために確保されていたハードウェア資源が解放される。

外部通信処理部２６０は、ネットワークノードがプロファイルに記述されたプロジェクトをシーケンシャルに実行して生成されたデータをファイル共有、ファイルアップロード、メール送信といった適切なプロトコルを使用してネットワークノードの外部に送信する。なお、図２に示したユーティリティ機能部２８０は、ネットワークノードがユーティリティノードとして機能する場合には、配信制御部２３０の機能部として含まれる。また、図２に示したネットワークノードが作業ノードとして機能する場合には、ユーティリティノードとしてネットワークを介して接続される。

図３は、本実施形態のワークフローシステム１００におけるネットワークノード間のデータフロー３００を示す。図３では、ワークフローシステム１００を構成するユーティリティノード３２０に対してユーザＰＣ３１０からワークフローの各種設定を行うものとして説明する。ユーザＰＣ３１０は、ワークフローシステム１００の管理者が使用するパーソナル・コンピュータなどとすることができ、本実施形態では、ユーザＰＣ３１０は、プラグイン動作設定ツール３１２と、管理ツール３１４とを含んで構成される。

本実施形態では、ユーザＰＣ３１０については要旨としていないので概略的な説明のみに止めるが、プラグイン動作設定ツール３１２は、ユーザＰＣ３１０のデスクトップ画面上にグラフィカルユーザインタフェース（ＧＵＩ）を表示し、ユーティリティノード３２０等に既にインストールされているプラグインのうち、ビルトイン機能を提供するプラグイン、例えば、フォルダ配信、ファイルアップロード、メール配信などの主要プラグイン機能について、動作可能な状態（有効化）と、動作不可能な状態（無効化）との間で切り換えを行い、ビルトイン機能のプラグインについて、効率的な動作開始を可能としている。プラグイン動作設定ツール３１２は、例えばサービスマンにより、ビルトイン機能のライセンス管理を行うために使用することができる。

管理ツール３１４は、ユーティリティノード３２０に対し同期化を指令するツールである。この同期化により、プロファイルが作業ノード３４０に配布され、かつ、ワークフロー定義に対して必要十分なプラグインプログラム環境が作業ノード３４０上に構築される。なお、本実施形態では、予め、プロファイル内のワークフロー定義の内容変更に対応してユーティリティノード３２０上にプラグインプログラム環境が構築され、同期化により、管理対象である作業ノード３４０上にユーティリティノード３２０と概ね同一なプラグインプログラム環境が構築されるものとして説明する。

しかしながら、管理対象の作業ノード３４０上に配布するプロファイルに応じた適切なプラグインプログラム環境が構築できる限り、このような同期化処理に特に限定されるものではない。他の実施形態では、ユーティリティノード３２０に構築されているプラグインプログラム環境にかかわらず、管理対象の作業ノード３４０に配布するプロファイルの定義内容から必要なプラグインプログラムを抽出および特定し、作業ノード３４０側に適切なプラグインプログラム環境が構築されるように個別に環境構築を指令してもよい。なお、本実施形態において、プラグインプログラム環境（以下、プラグイン環境という。）とは、ビルトイン機能のプラグインの有効化／無効化およびインストール済みオプション機能のプラグインを含むアプリケーション環境をいう。

ワークフローシステム１００の管理者は、プロファイルのワークフロー定義内容を変更する場合、その変更を作業ノード３４０に反映するために、ユーザＰＣ３１０から管理ツール３１４を起動して、プロファイルを更新するとともに更新するべきワークフロー定義を実行するために必要十分なプラグイン環境に設定するように、プロファイル更新通知をユーティリティノード３２０に発行する。このプロファイル更新通知は、プロファイルを記述するデータ、並びにプロファイルおよびプラグイン環境の同期化の指令を含む。

ユーティリティノード３２０は、ユーティリティ機能部の一部として、プラグイン更新処理を実行するためのプラグイン更新部３２２と、プラグインインストーラ３３０とを含んで構成されている。ワークフローシステム１００の管理者は、ワークフロー定義を変更する場合、予めプラグインインストーラ３３０により必要なプラグインプログラム用リソース３２８をダウンロードしてインストールし、またユーザＰＣ３１０からプラグイン動作設定ツール３１２を起動して、必要なビルトイン機能のプラグインを有効化しておく。

なお、プラグインインストーラ３３０は、異なるプラットフォーム環境等に対応するために、例えば外部接続されたリソースサーバ１７０から複数バージョンのプラグインインストール用リソース３２８ａ，ｂを予めダウンロードしておくことができる。あるいは、予め複数のバージョンをＣＤーＲＯＭ、ＳＤカード、ＤＶＤＲＯＭ、フラッシュメモリ等の記憶メディアを介してインストールしておくことができる。なお、プラグインインストール用リソース３２８のバージョンは、対応するプラットフォーム環境のバージョン、プラグイン自体の機能の改定、プラグイン機能の制限などに対応して、同一のプラグインＩＤが付されるプラグインに対して準備されるものである。

ユーティリティノード３２０は、ユーザＰＣ３１０からのプロファイル環境更新通知を受領すると、プラグインの同期的な更新を行うために、作業ノード３４０から、その作業ノード３４０上に構築されているプラグイン環境を記録するリモート環境ファイル３４２を取得する。また、ユーティリティノード３２０は、自己の最新のプラグイン環境を取得してプラグイン環境ファイル３２４を生成する。このプラグイン環境ファイル３２４は、上述したように、当該作業ノード３４０において構築されているべきプラグイン環境を記録するものである。ユーティリティノード３２０は、その後、自己の最新のプラグイン環境と、リモート環境ファイルとを比較し、（１）リモート環境ファイルで存在するが自己のプラグイン環境には存在しないプラグイン、（２）自己のプラグイン環境には存在するが、リモート環境ファイルには存在しないプラグイン、および（３）ビルトイン機能のプラグインの動作設定の変更の有無を判断する。

なお、プラグイン更新部３２２は、各ファイルを作業ノードから取得したり、送付したりする場合に、例えばＸＭＬ−ＡＴＯＭといったプロトコルを使用して、ＧＥＴ、ＰＯＳＴなどのファイル転送コマンドを取得手段および送付手段として利用することができる。

上記（２）に該当するプラグインが存在する場合、ユーティリティノード３２０は、まず作業ノード３４０に適合するインストール用リソースのバージョンを特定するために、作業ノード３４０から実行基盤環境ファイル３４４を取得する。本実施形態の実行基盤環境ファイル３４４は、作業ノード３４０のプラットフォーム環境のバージョン値およびメモリ容量を含む、作業ノードが自身管理する機器情報である。しかしながら、実行基盤環境ファイル３４４に含まれる情報は、プラグインの実行動作の前提として作業ノードが備えるべきハードウェア資源およびソフトウェア資源に関する如何なる情報を含むことができる。他の実施形態では、実行基盤環境ファイル３４４は、上述したプラットフォームのバージョン値およびメモリ容量の他、ハードディスク容量等の他のハードウェア資源の情報、ファクシミリ送信アプリ等のアプリケーション機能の有無等を含むことができる。

ユーティリティノード３２０は、実行基盤環境ファイル３４４の記述に対応して、適合するプラグインのバージョンを特定し、そのインストール用リソースを準備し、作業ノードにインストールすべきプラグインのプラグインＩＤおよびインストールの指示が書き込まれたＸＭＬファイルとしてプラグイン設定ファイル３２６を作成する。またユーティリティノード３２０は、実行基盤環境ファイル３４４の記述から、必要十分なプラグイン環境を作業ノード上に構築できないと判断される場合には、当該作業ノードのプラグイン環境の更新処理およびプロファイル更新処理を中止する。

また、上記（１）に該当するプラグインが存在する場合には、作業ノード３４０に対してその不要なプラグインのプラグインＩＤを含むアンインストールの指示をプラグイン設定ファイル３２６に書き込む。一方、上記（３）の判断でビルトイン機能の動作設定更新が指令されている場合には、ビルトイン機能の動作属性値を指定の動作設定へ書き換える指示をプラグイン設定ファイル３２６に書き込む。なお、動作属性値は、本実施形態では、有効化（valid）または無効化（invalid）で指定することができる。

その後、ユーティリティノード３２０は、生成したプラグイン設定ファイル３２６と、必要に応じて対応するプラグインインストール用リソース３２８とを作業ノード３４０に送信する。またユーティリティノード３２０は、変更されたプロファイルを作業ノード３４０に配布し、プロファイルを更新させる。なお、プラグイン設定ファイル３２６は、本実施形態の設定データを構成し、送信先の作業ノードに対し、プラグインのインストール／アンインストール、有効化／無効化を指示するものである。プラグイン設定ファイル３２６は、種々のフォーマットで生成することができ、例えば、構築されるべきプラグイン環境の全体を記述したデータとしてもよいし、インストール／アンインストール、有効化／無効化により変更すべき内容を記述したデータとしてもよい。

以下、フローチャートおよびデータ構造を参照して、本実施形態のプロファイルおよびプラグイン環境の更新処理についてより詳細に説明する。図４は、本実施形態のユーティリティノード３２０のプラグイン更新部３２２が実行する処理のフローチャートを示す。図４の処理は、ステップＳ４００から開始し、ステップＳ４００で、ユーザＰＣ３１０の管理ツール３１４からのプロファイル更新通知を受領したか否かを判断する。

プロファイル更新通知を受領しない場合（ＮＯ）、ステップＳ４００に処理を戻し、プロファイル更新通知を待機する。一方、ステップＳ４００でプロファイル更新通知を受領した場合（ＹＥＳ）、ユーティリティノード３２０は、ステップＳ４０１で、作業ノード３４０が保有するプラグインの情報を記録したリモート環境ファイル３４２を取得する。なお、リモート環境ファイル３４２は、当該作業ノードから所定のフォーマットで取得してもよいし、作業ノードに問い合わせて収集した情報からユーティリティノード３２０側で所定のフォーマットで新規に生成してもよい。ステップＳ４０２では、ユーティリティノード３２０は、自身が保有するプラグイン環境の情報を取得し、プラグイン環境ファイル３２４を生成する。

図６は、本実施形態のプラグイン環境ファイルおよびリモート環境ファイルのデータ構造を例示する。プラグイン環境ファイル６００は、プロファイルに対応してユーティリティノード３２０が現在保有するプラグインを記録する。プラグイン環境ファイル６００には、各ビルトイン機能および各オプション機能のプラグインについて、作業ノード側に要求されるプラットフォーム環境のバージョン値（以下、要求バージョン値という。）が設定され、これが＜RequiredVersion＞、＜/RequiredVersion＞などといったＸＭＬタグで指定されるノードとして記述されている。このタグ内には、例えば、プラットフォーム１．２以上向けおよび２．０向けのプラグインがインストールされ、更新後のプロファイルが規定する処理が、双方のバージョンでサポートされる場合に、”1.2, 2.0”といったような、複数の要求バージョン値が設定されることもある。なお、プロファイルが要求するバージョン等の情報は、プロファイル内に記述され、適宜参照してプラグイン環境ファイル６００が生成される。

またプラグイン環境ファイル６００には、同様に、各プラグインについて、作業ノード側で当該プラグインが動作した場合に必要とされるメモリ量の指標値が設定され、これが＜RequiredMemory＞、＜/RequiredMemory＞などといったＸＭＬタグで指定されるノードとして記述されている。このタグ内の値は、例えば、作業ノード３４０側の実行基盤環境ファイル３４４に記述されるメモリ容量に換算可能なプラグインが消費するメモリ資源量を評価した評価値とすることができ、その他、実際に使用するメモリ量とすることしてもよい。また、プラグインのバージョンで評価値またはメモリ容量が異なる場合には、複数の値が設定されることもある。

リモート環境ファイル６１０は、作業ノード３４０が現在保有するプラグインを記録するものであり、プラグイン環境ファイル６００と同様の構成とされている。なお、リモート環境ファイル６１０には、要求バージョン値および評価値またはメモリ量は任意である。

再び図４を参照すると、ステップＳ４０３ではプラグイン環境ファイル３２４とリモート環境ファイル３４２とを、プラグインＩＤの一致・不一致、動作属性値の一致・不一致を比較し差分ファイルを生成する。差分ファイルには、相違したプラグインのプラグインＩＤと、追加（Ａｄｄ属性値）なのか不要（Ｄｅｌ属性値）なのかを示す差分属性値、または主要プラグインの動作属性値が相違する場合にはユーティリティノード３２０側の動作属性値がそれぞれ追加される。

図７は、本実施形態の差分ファイルのデータ構造を例示する。差分ファイル７００は、ユーティリティノード３２０で、プロファイル環境ファイルと、リモート環境ファイルとの差分情報を抽出して作成したＸＭＬファイルである。差分ファイルには、相違するプラグインのプラグインＩＤと、相違する動作属性値を記述した行と、差分属性とを記述した行とが含まれる。差分属性の値は、説明する実施形態ではタグ＜Ｄｉｆｆ＞で記述され、差分属性＝Ａｄｄは、更新処理の際に追加してインストールすべきことを意味する。作業ノードで不要となるプラグインが見出された場合タグ＜Ｄｉｆｆ＞には、差分属性＝Ｄｅｌが記述される。なお、差分ファイルの実装形式および登録するべき値などについては、特定の目的に応じて適宜設定することができる。

再び図４を参照すると、ステップＳ４０４では、作成した差分ファイル＝ｎｕｌｌであるか否かに対応し、差分ファイル＝ｎｕｌｌの場合（ＮＯ）、ステップＳ４００に処理を戻し、以後の更新通知の受領を待機する。ステップＳ４０４で差分ファイル≠ｎｕｌｌでプラグイン環境に差があると判断した場合（ＹＥＳ）、ステップＳ４０５以降のプラグイン環境更新処理を実行する。

ステップＳ４０５では、ユーティリティノード３２０は、差分ファイルに登録されるビルトイン機能のプラグインのプラグインＩＤを取得し、動作属性値を変更するべきか否かを判断する。ユーティリティノード３２０は、ステップＳ４０５で、動作属性値を変更すべきであると判断した場合（ＹＥＳ）、ステップＳ４０６で、修正すべき各ビルトイン機能のプラグインについて、変更後の動作属性をプラグイン設定ファイル３２６に設定し、ステップＳ４０７へ処理を進める。また、ステップＳ４０５で動作属性値を変更する必要がないと判断した場合（ＮＯ）、ステップＳ４０７へ処理を進める。

ステップＳ４０７でユーティリティノード３２０は、作業ノード３４０でオプションが機能過剰であるか否かを判断し、オプション機能過剰であると判断された場合（ＹＥＳ）、ステップＳ４０８で、機能過剰（Ｄｅｌ属性値）とされたプラグインをアンインストールするようプラグイン設定ファイル３２６を書き込み、ステップＳ４０９へ進める。一方、ステップＳ４０７で、プション機能が過剰ではないと判断した場合（ＮＯ）、ステップＳ４０９へ処理を直接進める。

ステップＳ４０９でユーティリティノード３２０は、作業ノード３４０でオプション機能が不足するか否かを判断し、オプション機能不足であると判断された場合（ＹＥＳ）、ステップＳ４１０で、作業ノード３４０から実行基盤環境ファイル３４４を取得し、ステップＳ４１１で、機能不足（Ａｄｄ属性値）とされたプラグインを作業ノード３４０にインストールする際に必要なバージョンのリソースを判断するためのリソース判断処理を呼び出す。

以下、図５に示すフローチャートを参照しながらリソース判断処理の詳細について説明する。図５は、本実施形態のユーティリティノード３２０のプラグイン更新部３２２が実行するリソース判断処理のフローチャートを示す。図５の処理は、図４に示すステップＳ４１１の処理で呼び出されて、ステップＳ５００から開始し、ステップＳ５０１〜ステップＳ５０７のループに処理を進められる。ステップＳ５０１〜Ｓ５０７のループでは、機能不足とされたプラグインそれぞれについての判断処理が繰り返される。

ステップＳ５０２では、ユーティリティノード３２０は、最上位のプラットフォーム環境の要求バージョン値に判断対象を設定する。ここでは、ループで指定される機能不足のプラグインの＜RequiredVersion＞タグ内に複数の要求バージョン値が存在する場合には、最も順位の高いバージョン値が判断対象に設定される。ステップＳ５０３では、ユーティリティノード３２０は、作業ノード３４０から取得した実行基盤環境ファイル３４４中のプラットフォーム環境のバージョン値を参照し、現在判断対象である要求バージョン値と比較し、作業ノード３４０のプラットフォーム環境のバージョンが要求バージョン値以上であるか否かを判断する。

ステップＳ５０３で、要求バージョン値以上である判断した場合（ＹＥＳ）には、ユーティリティノード３２０は、ステップＳ５０６で、現在判断対象の要求バージョンに対応するインストール用リソースを準備し、ステップＳ５０７へ処理を進め、次の機能不足のプラグインについて行うべき処理に進める。

一方、ステップＳ５０３で、要求バージョン値未満であると判断した場合（ＮＯ）には、ユーティリティノード３２０は、ステップＳ５０４で、さらに下位の要求バージョン値が存在するか否かを判断する。＜RequiredVersion＞タグ内に複数の要求バージョン値が存在する場合には、下位の要求バージョン値がある可能性がある。ステップＳ５０４で、下位の要求バージョン値があると判断した場合（ＹＥＳ）、ユーティリティノード３２０は、ステップＳ５０５で、そのひとつ下位の要求バージョン値に判断対象を設定し、ステップＳ５０３へ処理を戻し、下位の要求バージョン値についての判断に進める。

一方、ステップＳ５０４で、下位の要求バージョンが存在しないと判定された場合（ＮＯ）には、ステップＳ５０１〜Ｓ５０７のループを抜け出し、ステップＳ５１２で、ユーティリティノード３２０は、判断結果を「更新条件不備」に設定し、ステップＳ５１３で、呼び出し元の図４に示す処理に戻す。これは、更新後のワークフロー定義に必要とされるプラグインを作業ノード３４０にインストールできないため、当該作業ノード３４０についてはプロファイルの更新しない方が適当であるためである。

ステップＳ５０１〜ステップＳ５０７のループにおける各機能不足のプラグインに対する処理が完了すると、ステップＳ５０８へ処理を進める。ステップＳ５０８では、ユーティリティノード３２０は、プラグイン環境ファイル３２４を参照し、有効とされているビルトイン機能および不足分を含むオプションのプラグイン機能の＜RequiredMemory＞タグ内に記載された評価値またはメモリ容量を合計値を算出し、実行基盤環境ファイル３４４に記述されたメモリ容量と比較し、機能不足のプラグインをインストールするに充分なメモリ容量が確保できるか否かを判断する。ステップＳ５０８で、充分なメモリ容量が確保できると判断した場合（ＹＥＳ）、ユーティリティノード３２０は、ステップＳ５１１で、機能不足とされたプラグインを決定したバージョンでインストールするよう設定ファイルを書き込み、判断結果を「更新条件完備」に設定し、ステップＳ５１３で、呼び出し元の図４に示す処理に戻す。

一方、ステップＳ５０８で、メモリ容量が確保できないと判断された場合（ＮＯ）、ユーティリティノード３２０は、ステップＳ５０９で、続いて、未使用のビルトイン機能のプラグインのアンロード（無効化）により、機能不足のプラグインのインストールに必要なメモリ容量が確保できるか否かを判断する。ここで、未使用のビルトイン機能のプラグインとは、プロファイル内のワークフロー定義上使用されない機能でありながら、有効化（Valid属性）されているビルトイン機能のプラグインである。ここでは、未使用のビルトイン機能のプラグインのメモリ容量または評価値を上記合計値から差し引き、その値と実行基盤環境ファイル３４４に記述されたメモリ容量と比較することにより、この調整により確保可能か否かを判断することができる。本実施形態では、未使用のビルトイン機能の無効化により調整する場合について説明するが、調整方法はこれに限定されるものではない。他の実施形態では、ステップＳ５０９に前後して、必要とされるメモリ容量が小さなより下位のバージョンまたはコンパクト版のバージョン等のインストール用リソースを変更して、機能不足のプラグインのインストールに必要なメモリ容量が確保できるか否かを判断することもできる。

ステップＳ５０９で、無効化によりメモリ容量が確保可能であると判断した場合（ＹＥＳ）、ユーティリティノード３２０は、ステップＳ５１０で、プラグイン設定ファイル３２６における未使用とされたビルトイン機能のプラグインをInvalid属性に上書きし、ステップＳ５１１で、機能不足のプラグインをインストールするよう設定ファイルを書き込み、判断結果を「更新条件完備」に設定し、ステップＳ５１３で、呼び出し元の図４に示す処理に戻す。一方、ステップＳ５０９で、無効化をしてもメモリ容量が確保できないと判断した場合（ＮＯ）には、ステップＳ５１２へ処理を分岐させ、ユーティリティノード３２０は、判断結果を「更新条件不備」に設定し、ステップＳ５１３で、呼び出し元の図４に示す処理に戻す。この場合も、当該作業ノード３４０についてはプロファイルの更新しない方が適当であるためである。

再び図４を参照すると、図５に示す処理から戻されると、ユーティリティノード３２０は、ステップＳ４１２で、判断結果が「更新条件完備」に設定されているか否かを判定する。ステップＳ４１２で、「更新条件完備」が設定され、不足のプラグインに対応するインストール用リソースが全て揃っている場合（ＹＥＳ）、ユーティリティノード３２０は、ステップＳ４１３で、プラグイン設定ファイル３２６と、必要に応じて準備されたプラグインインストール用リソース３２８とを作業ノード３４０に送信し、ステップＳ４００に処理を戻し、以後のプロファイル更新通知を待機する。

送信されたプラグイン設定ファイル３２６を受信した作業ノード３４０は、当該プラグイン設定ファイル３２６に従い、ビルトイン機能のプラグインについては、設定された動作属性値に従いまずInvalid属性が設定されたプラグインを無効化し、不要とされたオプション機能のプラグインをアンインストールする。続いて、設定された動作属性値に従って、Valid属性のプラグインを有効化に設定し、受信したインストール用リソースを用いて機能不足とされたオプション機能のプラグインをインストールする。上記プラグインの無効化および有効化は、例えば作業ノード３４０において、システムにロードされるプラグインプログラムのパスが記述された設定ファイルを書き換えることにより行うことができる。

一方、ステップＳ４１２で「更新条件不備」に設定されている場合（ＮＯ）には、ユーティリティノード３２０は、ステップＳ４１４でその旨のエラーレポートを作成し、ステップＳ４００に処理を戻し、以後のプロファイル更新通知を待機する。この場合、ワークフローシステム１００の管理者は、エラーレポートを参照して、適宜個別に対応することとなる。

なお、上述までは、説明の便宜上、ひとつの作業ノードに対する処理について説明してきたが、ユーティリティノード３２０が管理対象とする作業ノードの数は、特に限定されるものではなく、この場合、各作業ノードについて図４および図５に示すステップＳ４０１、ステップＳ４０３〜Ｓ４１４の処理フロー（図５に示す処理フローを含む。）を適用すればよい。また、ひとつの作業ノードに対し複数のプロファイルが定義可能な場合には、各作業ノードについて、定義された複数のプロファイルで使用されるプラグインの和集合を算出し、そのプラグインの和集合に対応するプラグイン環境を作業ノードに構築するように上述した処理を変形することもできる。この場合、各作業ノードに対して、より柔軟にプロファイル管理およびプラグイン環境の構築を行うことが可能となる。

上記実施形態では、ワークフロー定義内容の変更に対応して、管理対象のネットワークノード側に機能不足のプラグインが発生した場合に、ユーティリティノード３２０は、当該ネットワークノード側のプラグイン実行基盤環境を把握した上で、適切なインストール用リソースを判断し、作業ノード側にインストールさせることができる。したがって、ワークフローシステム１００を管理するユーザは、各ネットワークノードのハードウェア資源やソフトウェア資源等の有無を含む実行基盤環境の相違を意識しないで、一括に複数のネットワークノードに対してプロファイル更新およびプラグイン環境の更新を行うことができ、ひいてはワークフローの実行環境を効率的に構築することが可能となる。

以上説明したように、本実施形態によれば、定義されるワークフローの修正・変更に対応して、配布先の作業ノードのプラグインプログラム実行基盤環境に応じて、柔軟かつ動的に、当該プラグインプログラム等の適切なリソースの配布処理を制御することができ、ひいてはワークフローの実行環境を効率的に構築することを可能とする画像処理システム、管理装置、画像処理装置、管理方法、プログラムおよび記録媒体を提供することができる。

さらに本実施形態によれば、異なるプラットフォームのバージョンの画像処理装置が混在するような運用環境であっても、適切なバージョンのプラグインプログラムが提供されることとなり、プラットフォーム環境が不統一な運用環境においても効率的にワークフローの実行環境を効率的に構築することが可能となる。さらに、誤ったバージョンのプラグインプログラムが提供される不具合が回避される。

また本実施形態によれば、それぞれハードウェア資源が相違する画像処理装置が混在するような運用環境であっても、ハードウェア資源に適合した配布処理が実現され、ハードウェア資源が不統一な運用環境においても、効率的にワークフローの実行環境を効率的に構築することが可能となり、メモリ不足などの不具合の発生を防止することが可能となる。また、ワークフロー定義に使用されていないような無駄なハードウェア資源が有効利用が可能となるため、画像処理装置を省資源化することができる。

また上記機能は、アセンブラ、Ｃ、Ｃ＋＋、Ｃ＃、Ｊａｖａ（登録商標）、などのレガシープログラミング言語やオブジェクト指向プログラミング言語などで記述されたコンピュータ実行可能なプログラムにより実現でき、ＲＯＭ、ＥＥＰＲＯＭ、ＥＰＲＯＭ、フラッシュメモリ、フレキシブルディスク、ＣＤ−ＲＯＭ、ＣＤ−ＲＷ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＤＶＤ−ＲＷ、ブルーレイディスク、ＳＤカード、ＭＯなど装置可読な記録媒体に格納して、あるいは電気通信回線を通じて頒布することができる。

これまで本発明の実施形態について説明してきたが、本発明の実施形態は上述した実施形態に限定されるものではなく、他の実施形態、追加、変更、削除など、当業者が想到することができる範囲内で変更することができ、いずれの態様においても本発明の作用・効果を奏する限り、本発明の範囲に含まれるものである。

１００…ワークフローシステム、１１０…ユーティリティノード、１２０…コンピュータ、１３０…画像処理装置、１４０…プロファイル、１５０，１６０…作業ノード、１７０…リソースサーバ、１８０…画像処理装置、１９０…サーバ、２００…機能ブロック、２１０…入出力制御部、２２０…画像読み取り制御部、２３０…配信制御部、２４０…プラグイン管理部、２５０…プラグイン、２６０…外部通信処理部、２７０…ＬＡＮ、２８０…ユーティリティ機能部、２９０…各種機能部、３００…データフロー、３１０…ユーザＰＣ、３１２…プラグイン動作設定ツール、３１４…管理ツール、３２０…ユーティリティノード、３２２…プラグイン更新部、３２４…プラグイン環境ファイル、３２６…プラグイン設定ファイル、３２８…プラグインインストール用リソース、３３０…プラグインインストーラ、３４０…作業ノード、３４２…リモート環境ファイル、３４４…実行基盤環境ファイル、６００…プラグイン環境ファイル、６１０…リモート環境ファイル、７００…差分ファイル

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

Claims (16)

1. ネットワークを介して接続される画像処理装置および管理装置を含む画像処理システムであって、前記管理装置は、
   画像データに対して複数の処理を連続して実行するためのフロー定義の内容変更に対応して、管理対象の画像処理装置が保有するプラグインプログラムを記録するリモート環境データを取得する手段と、
   前記フロー定義に対応して前記管理対象の画像処理装置に保有させるべきプラグインプログラムを記録するプラグイン環境データを生成する手段と、
   前記リモート環境データと前記プラグイン環境データとの差分を記録する差分データを生成する手段と、
   前記管理対象の画像処理装置のプラグインプログラムの実行基盤環境を記述する基盤環境データを取得する手段と、
   前記差分データおよび前記基盤環境データを読み込んで、プラグインプログラムの提供の適否および提供するバージョンを判断する手段と、
   前記判断する手段の判断に応じてプラグイン環境の構築を指示する設定データを前記画像処理装置に送信する手段と
   を含み、
   前記画像処理装置は、前記管理装置から受信した前記設定データに従って自身のプラグイン環境を更新する、
   画像処理システム。
2. 前記基盤環境データは、前記管理対象の画像処理装置が備えるプラットフォーム環境のバージョン値を含み、前記判断する手段は、前記フロー定義に適合し、かつ前記管理対象の画像処理装置の前記プラットフォーム環境のバージョン値に適合する前記プラグインプログラムのバージョンを判断する、請求項１に記載の画像処理システム。
3. 前記基盤環境データは、前記管理対象の画像処理装置が備えるハードウェア資源の情報を含み、前記判断する手段は、前記管理対象の画像処理装置の前記ハードウェア資源の情報を参照し、前記判断に応じたプラグイン環境を構築するために必要な資源が確保されているか否かを判断することにより、前記プラグインプログラムの提供の適否を判断する、請求項１または２に記載の画像処理システム。
4. 前記判断する手段は、前記判断に応じたプラグイン環境を構築するために必要なハードウェア資源量の合計値と、前記ハードウェア資源の情報とを比較して、前記プラグインプログラムの提供の適否を判断する、請求項３に記載の画像処理システム。
5. 前記判断する手段は、さらに、前記管理対象の画像処理装置に組み込まれたプラグインプログラムうちの前記フロー定義に不要なものを無効化して前記必要なハードウェア資源量の合計値を確保できるか否かを判断することにより、前記プラグインプログラムの提供の適否を判断する、請求項４に記載の画像処理システム。
6. 前記送信する手段は、判断されたバージョンのプラグインプログラムをインストールするためのリソースをさらに送信する、請求項１〜５のいずれか１項に記載の画像処理システム。
7. 前記設定データは、前記管理対象の画像処理装置に組み込まれたプラグインプログラムの有効化または無効化を指令する動作状態属性値を含む、請求項１〜６のいずれか１項に記載の画像処理システム。
8. ネットワークを介して画像処理装置と接続する管理装置であって、前記管理装置は、
   画像データに対して複数の処理を連続して実行するためのフロー定義の内容変更に対応して、管理対象の画像処理装置が保有するプラグインプログラムを記録するリモート環境データを取得する手段と、
   前記フロー定義に対応して前記管理対象の画像処理装置に保有させるべきプラグインプログラムを記録するプラグイン環境データを生成する手段と、
   前記リモート環境データと前記プラグイン環境データとの差分を記録する差分データを生成する手段と、
   前記管理対象の画像処理装置のプラグインプログラムの実行基盤環境を記述する基盤環境データを取得する手段と、
   前記差分データおよび前記基盤環境データを読み込んで、プラグインプログラムの提供の適否および提供するバージョンを判断する手段と、
   前記判断する手段の判断に応じてプラグイン環境の構築を指示する設定データを前記画像処理装置に送信する手段と
   を含む、管理装置。
9. 前記基盤環境データは、前記管理対象の画像処理装置が備えるプラットフォーム環境のバージョン値を含み、前記判断する手段は、前記フロー定義に適合し、かつ前記管理対象の画像処理装置の前記プラットフォーム環境のバージョンに適合する前記プラグインプログラムのバージョンを判断する、請求項８に記載の管理装置。
10. 前記基盤環境データは、前記管理対象の画像処理装置が備えるハードウェア資源の情報を含み、前記判断する手段は、前記管理対象の画像処理装置の前記ハードウェア資源の情報を参照し、前記判断に応じたプラグイン環境を構築するために必要な資源が確保されているか否かを判断することにより、前記プラグインプログラムの提供の適否を判断する、請求項８または９に記載の管理装置。
11. ネットワークを介して管理装置に接続される画像処理装置であって、前記画像処理装置は、
    前記管理装置の要求に応答して、当該画像処理装置が保有するプラグインプログラムを前記管理装置に通知する手段と、
    前記管理装置の要求に応答して、当該画像処理装置のプラグインプログラムの実行基盤環境を記述する基盤環境を通知する手段と、
    前記管理装置から受信する設定データに従って自身のプラグイン環境を更新する手段とを含み、
    前記設定データは、前記管理装置により、前記管理装置が把握するフロー定義に対応して当該画像処理装置に保有させるべきプラグインプログラムと、通知した当該画像処理装置が保有するプラグインプログラムとの差分を用いて、プラグインプログラムの提供の適否および提供するバージョンが判断され、該判断に応じたプラグイン環境の構築を指示するよう構成されている、画像処理装置。
12. ネットワークを介して画像処理装置と接続する管理装置が実行する方法であって、前記管理装置が、
    画像データに対して複数の処理を連続して実行するためのフロー定義の内容変更に対応して、管理対象の画像処理装置が保有するプラグインプログラムを記録するリモート環境データを取得するステップと、
    前記フロー定義に対応して前記管理対象の画像処理装置に保有させるべきプラグインプログラムを記録するプラグイン環境データを生成するステップと、
    前記リモート環境データと前記プラグイン環境データとの差分を記録する差分データを生成するステップと、
    前記管理対象の画像処理装置のプラグインプログラムの実行基盤環境を記述する基盤環境データを取得するステップと、
    前記差分データおよび前記基盤環境データを読み込んで、プラグインプログラムの提供の適否および提供するバージョンを判断するステップと、
    前記判断するステップの判断に応じてプラグイン環境の構築を指示する設定データを前記画像処理装置に送信するステップと
    を実行する、管理方法。
13. 前記基盤環境データが前記管理対象の画像処理装置が備えるプラットフォーム環境のバージョン値を含み、前記判断するステップは、前記フロー定義に適合し、かつ前記管理対象の画像処理装置の前記プラットフォーム環境のバージョンに適合する前記プラグインプログラムのバージョンを判断するサブステップを含む、請求項１２に記載の管理方法。
14. 前記基盤環境データが前記管理対象の画像処理装置が備えるハードウェア資源の情報を含み、前記判断するステップは、前記管理対象の画像処理装置の前記ハードウェア資源の情報を参照し、前記判断に応じたプラグイン環境を構築するために必要な資源が確保されているか否かを判断することにより、前記プラグインプログラムの提供の適否を判断するサブステップを含む、請求項１２または１３に記載の管理方法。
15. ネットワークを介して画像処理装置と接続する管理装置に、
    画像データに対して複数の処理を連続して実行するためのフロー定義の内容変更に対応して、管理対象の画像処理装置が保有するプラグインプログラムを記録するリモート環境データを取得する手段、
    前記フロー定義に対応して前記管理対象の画像処理装置に保有させるべきプラグインプログラムを記録するプラグイン環境データを生成する手段、
    前記リモート環境データと前記プラグイン環境データとの差分を記録する差分データを生成する手段、
    前記管理対象の画像処理装置のプラグインプログラムの実行基盤環境を記述する基盤環境データを取得する手段、
    前記差分データおよび前記基盤環境データを読み込んで、プラグインプログラムの提供の適否および提供するバージョンを判断する手段、および
    前記判断する手段の判断に応じてプラグイン環境の構築を指示する設定データを前記画像処理装置に送信する手段
    を実現するための装置実行可能なプログラム。
16. 請求項１５に記載の装置実行可能なプログラムを装置可読に格納する記録媒体。