JP5608985B2 - 画像処理装置、情報処理装置、ユーザインタフェース提供方法、画像処理システムおよびプログラム - Google Patents

Description

本発明は、画像処理技術に関し、より詳細には、画像データに対して複数の機能を連携して実行するためのワークフローを提供することが可能な画像処理装置、情報処理装置、ユーザインタフェース提供方法、画像処理システムおよびプログラムに関する。

近年、複合機（以下、ＭＦＰとして参照する。）といった画像処理装置は、複写機能、画像形成機能、通信機能などの複数の機能を提供することが可能となっている。また、画像データに対しては、複合機および遠隔的に接続されたサーバが提供する複数の機能を連携させた一連の業務も可能となっている。画像に対して一連の業務を実行させようとする場合、ユーザは、ＭＦＰやサーバといった処理ノードで実行するべき機能を特定した後、実行させる機能のシーケンスを指定していわゆるワークフローを設定する。

上述したワークフローを実行させる技術はこれまで種々知られており、例えば、特開２００８−９７５８６号公報（特許文献１）には、フロー定義データを用意し、フロー定義データに基づいてスキャン画像データに対して処理を実行させる技術が開示されている。また、特開２００８−１７６５４１号公報（特許文献２）には、予め設定された電子文書のレイアウトを、電子文書に付加されたメタデータを使用して変更する技術が開示されている。さらに、特開２００８−３０５００４号公報（特許文献３）では、ソフトウェア部品を連携して実行させるアプリケーションの実行方法を開示する。

上述のように、画像データに対して特定の業務をシーケンシャルに実行させることが比較的容易にされてきている。さらに、近年のＭＦＰは、高級言語、例えばＪａｖａ（登録商標）、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔなどを実装し、ブラウザプログラムの実行により、各種処理を実行するためのユーザインタフェースが提供されている。また、ＭＦＰやサーバなどの処理ノードに対してPlug-inプログラムをインストールすることにより、画像データに対する処理機能を比較的容易に追加・修正することもできるようになっている。

さらに処理機能の高度化や、ユーザニーズの多様化に伴い、処理機能の追加・修正を行う場合もある。特定の情報処理機能が追加・修正される場合、当該処理機能へのインタフェースを提供するためのディスプレイ装置が表示するユーザインタフェース（以下、ＵＩとして参照する。）も修正される場合が多い。

上述した実行環境下で、ユーザが過去に設定した条件設定データが存在する場合に、ユーザインタフェースが異なると既設定の条件設定データが正しく読み取られず、ＵＩ上に表示されない場合も発生する。また、条件設定データが表示されない場合、既設定データの修正が困難となる他、設定しなければならない条件のうちどの条件が設定済みであり、設定済みでないかの判断についても不正確となる。さらに、条件設定データがまったく修正されていない場合にでも、都度ハードディスク装置などにアクセスして条件設定データを読み出すのでは、過去に利用した動作履歴を効果的に利用することができないという問題もある。

また、ワークフローを構成するＭＦＰやサーバのベンダ側でも、特定機能の追加、修正、バージョンアップ、またはユーザカスタマイズなどに際してＵＩを修正する必要がある場合、ＵＩの修正毎に、サービスマンによる設定変更やユーザによるワークフロー定義修正および条件再入力などが必要となる場合もあり、入力負担の増加、および条件設定データの再入力に伴う、不要データの蓄積などによるメモリ資源の浪費などが発生する場合もある。

すなわち、これまで、既存の画像処理装置や、画像処理装置を制御するための管理用の情報処理装置に定義された機能の設定条件をできるだけそのまま継承して、新たな機能を含むワークフローをより効率的に利用させる技術が必要とされていた。また、ＵＩをユーザ毎にカスタマイズしながら、効率的にワークフローを利用させる技術が必要とされていた。

本発明は、上述した従来技術の課題に鑑み、ワークフローの利用性を向上させるため、ワークフローの特定の機能を提供する処理ノードに表示させるＵＩを、ＵＩ構造定義と、条件設定データとに分離する。そして、ＵＩ構造定義が動的に条件設定データを読み込んで、ワークフローを実行するためにすでに設定した既存の条件設定データを新たなＵＩ構造定義に動的に取得させ、適正なＵＩ表示を提供する。

本発明のＵＩ構造定義取得手段は、ネットワークを介して構造化文書として前記ＵＩ構造定義を取得し、取得したＵＩ構造定義を記憶装置に格納する。また、条件設定データは、対応するＵＩ構造定義に関連付けられており、データ継承手段は、ＵＩ構造定義を読み込んで、現在のＵＩ構造定義の現在バージョン識別値と、直前に読み込んだＵＩ構造定義の前回バージョン識別値とを比較し、各バージョン識別値の一致・不一致の判断結果に応じて、記憶手段から前回使用し、ＸＭＬで記述された条件設定データを読み出し、ＤＯＭ(Document Object Model)を使用して条件設定データを階層データとし、現在バージョン識別値で指定されるＵＩ構造定義に対して読み出し順とは独立した条件設定データの設定を可能とする。

そして、本発明では、ＵＩ構造定義および条件設定データは、ユーザインタフェースを提供するため、独立した構造化文書として提供され、それぞれ画像データに対して実行するべき情報処理を実行させるために関連付けられている。画像処理装置は、画像データに対してシーケンスとして定義される情報処理の処理ノードを構成し、Plug-inプログラムが指定された情報処理を画像に対して実行する。ＵＩ構造定義は、Plug-inプログラムを実行するためのユーザインタフェースを提供している。

さらに、本発明では、ブラウザ処理手段は、ＵＩ構造定義の表示制御を行う表示制御手段を備え、ネットワークを介して送付されるＵＩ表示制御ファイルにより、前記ＵＩ構造定義が提供するＵＩパーツの可視性を制御しており、ＵＩ表示画面のカスタマイズをより効率的にさせている。

本発明は、ワークフローを直接実行する画像処理がワークフローを実行する際に画像処理装置として実装することもできる。また、本発明は、ワークフロー上の処理ノードを構成するＭＦＰに対してワークフロー定義や条件設定データを送付して、ワークフロー上の特定の処理をＭＦＰに実行させるためのサーバ装置またはパーソナルコンピュータといった情報処理装置として実装することができる。

ＵＩ表示を提供するべきPlug-inのベンダは、Plug-inの修正に伴うＵＩの修正がある場合にでも、処理ノードのカスタマイズされた条件設定や条件設定の追加・削除がある場合にでも、処理ノード側でのＵＩ表示の適正化や設定の適正化を考慮することなく、ＵＩの修正を柔軟に行うことができる。

本発明では、さらに、ＵＩ構造定義とともに、ＵＩ構造定義とは分離されたＵＩ表示制御ファイルを使用する。ＵＩ表示制御ファイルは、ＵＩ構造定義に定義されたＵＩパーツの表示・非表示を制御して、ＵＩ構造定義をユーザ毎に修正することなく、ユーザにカスタマイズされたＵＩ表示を提供することが可能となる。このため、ＵＩ構造定義により提供されるＵＩ表示のワークフローにおける利用性を向上させることができる。

ワークフローを提供する本実施形態の画像処理システム１００の機能ブロック図。 本実施形態のプログラム実行部１２２を処理ノード１２０の詳細な機能ブロック２００を示した図。 本実施形態で使用するワークフロー３００の階層構造および当該階層構造を定義するワークフロー制御データの実施形態を示した図。 本実施形態でＵＩを形成するために使用するＵＩ生成データのデータ構造を示した図 本実施形態のユーザインタフェース（ＵＩ）提供方法のフローチャートを示した図。 本実施形態で使用する条件設定データ４８０の実施形態を示した図。 本実施形態で使用するインタフェースが含むＤＯＭ機能を含むデータ継承部２２０の機能を提供するための疑似コードの実施形態を示した図。 本実施形態でＵＩ表示部２１０が表示するＵＩの実施形態を示した図。 図８に示した編集ボックスを提供するためのＵＩ構造定義９００の実施形態を示した図。 本発明により生成される、ＵＩ表示１０００の実施形態を示した図。 本実施形態において、ユーザ毎にＵＩ表示を制御する実施形態を、図１０に示したＵＩ表示１０００を例として説明した図。

以下、本発明を実施形態をもって説明するが、本発明は後述する実施形態に限定されるものではない。図１は、ワークフローを提供する本実施形態の画像処理システム１００の機能ブロック図である。図１に示した画像処理システム１００は、画像データに対してスキャン、画像フォーマット変換、画像圧縮、などの画像処理、ネットワーク送信、プリント出力、データストレージなどの各種の情報処理を、ユーザが設定したシーケンスで実行する。

図１に示した画像処理システム１００は、処理ノード１１０、処理ノード１２０を含んでいる。処理ノード１１０は、ローカルに設置されたＭＦＰなどの多機能機に相当する処理ノードであり、スキャン１１２、プリント１１４、ネットワーク通信１１６、データストレージ１１８などの機能を提供する。また、処理ノード１２０は、処理ノード１１０が取得した画像データなどを取得し、処理ノード１１０が実行した情報処理に後続するワークフロー上の処理を実行する処理ノードであり、ＭＦＰやサーバ装置などとして実装することができる。

処理ノード１２０は、処理対象の画像データに対して、追加のフォーマット変換、通信プロトコル変換などを実行し、ＭＦＰ１４０、互換ＭＦＰ１５０、パーソナルコンピュータ１６０（以下、ＰＣ１６０として参照する。）に対して、印刷データ、メール、またはデータベースへの画像データの登録などの処理を実行する。

処理ノード１２０と、ＭＦＰ１４０、互換ＭＦＰ１５０、ＰＣ１６０との間は、適切なインタフェース１３０を介して、バスライン、インターネット、またはローカルエリアネットワーク（ＬＡＮ）などで相互接続されており、データ転送先の装置が許容可能なプロトコルを使用して、処理ノード１２０の画像処理結果をそれぞれ転送先へと送信する。

また、本実施形態の画像処理システム１００は、処理ノード１１０と、処理ノード１２０とを、機能的に分離せず、スキャン１１２、プリント１１４、ネットワーク通信１１６、データストレージ１１８などの機能を一体として含む処理ノード１７０として実装することもできる。処理ノード１１０と、処理ノード１２０とを一体とし、処理ノード１７０として実装する場合、処理ノードは、サーバ機能を含むＭＦＰとされ、ネットワークを介して他のＭＦＰ１４０、互換ＭＦＰ１５０、ＰＣ１６０、また、当該実施形態では、Plug-inプログラムを介してワークフローの設定、処理ノードの管理などを行うためのサーバ装置（図示せず）などと相互通信を行う。処理ノード間のファイル送受信を行う場合、通信プロトコルとしては、ＴＣＰ／ＩＰ、ファイル転送プロトコルは、ＦＴＰ（Ｓ）、ＨＴＴＰ（Ｓ）を使用することができる。

処理ノード１２０は、処理ノード１１０と分離したＭＦＰまたはＭＦＰ管理用のサーバ装置やパーソナルコンピュータとして実装される場合、マイクロプロセッサ（ＭＰＵ）、ＲＡＭ、ＲＯＭ、ハードディスク装置（いずれも図示せず）を搭載した分散処理可能な情報処理装置として実装することができる。さらに、処理ノード１２０は、ＵＮＩＸ（登録商標）、ＬＩＮＵＸ（登録商標）、またはＷＩＮＤＯＷＳ（登録商標）２００Ｘサーバなどのオペレーティングシステム（ＯＳ）の制御下で、Ｊａｖａ（登録商標）、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ、Ｃ＋＋、Ｐｅｒｌ、Ｒｕｂｙ、Ｐｙｔｈｏｎなどのオブジェクト指向プログラミング言語で記述されたプログラムを実行する。

また、処理ノード１２０は、ブラウザプログラムを実装し、ウェブサーバとの間でＨＴＴＰ（Ｓ）を使用したファイル転送を実行する。ブラウザプログラムとしては、例えば、Ｍｏｚｉｌｌａ（登録商標）、Ｏｐｅｒａ（登録商標）、Ｆｉｒｅｆｏｘ（登録商標）、Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ（登録商標）など、ＨＴＭＬ、ＸＭＬなどの構造化文書を送受信し、ＵＩとして表示可能なプログラムを挙げることができる。

さらに処理ノード１２０は、プログラム実行部１２２と、機能管理部１２６と、ＯＳカーネル１２８といった機能部を含む。さらに、プログラム実行部１２２は、ＭＦＰクラス１２２ａと、ＭＦＰ互換性提供クラス１２２ｂと、ＰＣインタフェースクラス１２２ｃとを含んで構成されている。ＭＦＰクラス１２２ａは、処理ノード１２０がＭＦＰとして実装される場合のＭＦＰ機能をサポートする機能手段を提供する。また、ＭＦＰ互換性提供クラス１２２ｂは、ネットワークを介してワークフロー上に定義された他の処理ノードがＭＦＰの場合の機能互換性を提供する機能手段を提供する。また、ＰＣインタフェースクラス１２２ｃは、ワークフローを処理する他の処理ノードが、ＰＣの場合にＰＣに対応するようにデータ転送プロトコルなどを設定する機能手段を提供する。

特定の実施形態では、特に限定されるものではないが、ＭＦＰクラス１２２ａ、ＭＦＰ互換性クラス１２２ｂ、ＰＣインタフェースクラス１２２ｃは、それぞれＪａｖａ（登録商標）仮想機械(Virtual Machine:VM)として実装することができる。機能管理部１２６は、認証部１２６ａ、ネットワーク処理部１２６ｂ、リモート管理部１２６ｃ、起動管理部１２６ｄなどを含んで構成されており、ユーザ認証、ネットワークトランザクション、遠隔アップデート、処理ノード１２０の全体の動作管理などの機能を提供する。ＯＳカーネル１２８は、ＯＳが直接管理するプログラムを管理し、Plug-inプログラムなどによる機能拡張などを可能としている。

また、プログラム実行部１２２は、他の実施形態では、ＭＦＰとは分離したサーバ装置またはパーソナルコンピュータといった情報処理装置に機能的に分離して実装することもできる。プログラム実行部１２２をＭＦＰとは分離して構成する場合、例えば、図１のＰＣ１６０に当該機能を分散させることができる。説明する他の実施形態では、ＰＣ１６０は、マイクロプロセッサ、ＲＡＭ、ＲＯＭ、ハードディスク装置などを搭載し、Ｗｉｎｄｏｗｓ（登録商標）シリーズのＯＳ、ＵＮＩＸ（登録商標）、ＬＩＮＵＸ（登録商標）などのＯＳの制御下で、Ｊａｖａ（登録商標）、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔなどのオブジェクト指向プログラミングを実行する。

ＰＣ１６０がＪａｖａ（登録商標）などのプログラムを実行する場合、ＰＣ１６０は、ＪＶＭ(Java（登録商標）Virtual Machine)を実装し、バイトコードを使用してプログラミングを実行する。さらに、ＰＣ１６０は、Ｍｏｚｉｌｌａ（登録商標）、Ｏｐｅｒａ（登録商標）、Ｆｉｒｅｆｏｘ（登録商標）、Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ（登録商標）などのブラウザプログラムを実装し、ブラウザを介したワークフロー設定を可能とする。

図２は、本実施形態の処理ノード１２０のプログラム実行部１２２に実装される詳細な機能ブロック２００を示す。なお、図２に示した機能ブロック２００は、ＭＰＵが、本実施形態のプログラムを読み込んで、ＲＡＭに実行形式のファイルを展開することで、ＭＰＵが実行形式のプログラムを実行することにより、処理ノード１２０上の機能手段として提供されている。図２に示すように、処理ノード１２０は、ＵＩ表示部２１０と、ブラウザ処理部２２０と、ワークフロー管理部２３０とを含んでいる。ＵＩ表示部２１０は、処理ノード１２０の実装形式に応じて、操作パネルまたはＬＣＤやＰＤなどのディスプレイ装置とすることができる。

ブラウザ処理部２２０は、プラウザプログラムの実行により処理ノード１２０上に実現される機能手段である。また、ブラウザ処理部は、より詳細には、パーザ２２２および表示制御部２２４を含んでいる。パーザは、ＨＴＭＬ、ＸＨＴＭＬ、ＸＭＬなどの構造化文書を読み込んで、構造化文書のタグにより指定された処理を実行するためにインタフェースを提供し、本実施形態の好適な態様では、ＤＯＭ(Document Object Model)機能やＳＡＸ(Simple API for XML)を含み、名前空間を使用してタグの解釈を行う、ＸＭＬパーザとして実装することができる。

また、表示制御部２２４は、本実施形態では、使用する構造化文書に適合する表示制御機能を提供し、例えば、ＣＳＳ(Cascading Style Sheet)やＸＳＬＴ(eXtensible Stylesheet Language Transformation)などの機能を提供する。

さらに、処理ノード１２０は、ＵＩ構造定義取得部２３２と、データ継承部２３４とを含んでいる。ＵＩ構造定義取得部２３２は、ネットワーク２６０などから配布されたＵＩ構造定義を受領して、記憶装置２５０などに格納する処理を実行する。また、他の実施形態では、ＵＩ構造定義は、ＵＩ表示部２１０に表示されたＵＩ構造定義のためのＵＩ表示画面からインタラクティブに生成することもできる。いずれの場合にでも取得したＵＩ構造定義は、記憶装置２５０に格納され、以後、ＵＩ表示部２１０に対してＵＩ構造定義に従ってPlug-inプログラムを制御するための設定画面を表示させる。

データ継承部２３４は、ＨＴＭＬ、ＸＨＴＭＬ、ＸＭＬなどの構造化文書として受領したＵＩ構造定義およびPlug-inプログラムの実行を制御するための条件設定データなどを含むＵＩ表示画面を、ＵＩ表示部２１０に表示するため、表示制御を実行する。本実施形態のデータ継承部２３４は、表示するべきＵＩが、直前に表示する際に使用したＵＩ構造定義のバージョンと、現在表示させるべきＵＩ構造定義のバージョンとが同一か否かを判断し、この判断に対応して条件設定データに対して異なる読み出し処理を実行する。

ワークフロー管理部２３０は、ワークフロー制御データに記述された機能定義および当該機能を制御するための条件設定データを記憶装置２５０などの適切な記憶空間から取得し、画像データ取得、フォーマット変換、プリント出力、データ転送、ファイル格納などのワークフローに定義されたシーケンスの情報処理機能を呼び出し、当該処理を実行するように処理実行部２４０に通知する。処理実行部２４０は、通知された情報処理機能を行うためのPlug-inプログラムを呼び出し、ワークフロー上で定義された処理を実行し、割り当てられた処理がなくなるまで、ワークフロー管理部２３０との間で通信を行い、処理ノード１２０が実行するべき処理を完了させる。処理実行部２４０は、自己に割り当てられた処理のうち、最終シーケンスの処理が完了した後、ワークフロー制御データに設定された処理を実行させるため、処理結果を、バスやネットワーク２６０を介して送出し、処理ノード１２０のワークフロー上での処理を終了する。

なお、記憶装置２５０は、ハードディスク装置、ＲＡＭ、バッファメモリ、ＥＥＰＲＯＭなどを含んで構成された処理ノード１２０の記憶空間であり、記憶装置２５０には、少なくともワークフロー制御データの他、ＵＩを形成するためのＵＩ構造定義、Plug-inがその処理を実行するための条件設定データなどを格納する。プログラム実行部１２２は、ワークフローのシーケンスを実行するに際し、ワークフローの設定条件および実行するPlug-inプログラムが使用するＵＩ定義データを呼び出して、ブラウザ処理部２２０を介して条件を設定し、またＵＩ表示部２１０へのＵＩ画面を表示させている。

なお、ＰＣ１６０が画像処理装置１２２を管理するサーバ装置やパーソナルコンピュータなどの情報処理装置として分離して実装される他の実施形態では、ＰＣ１６０は、ネットワーク２６０にアクセスするためのネットワークインタフェースカード（ＮＩＣ）などのネットワーク通信手段を含んでいて、ネットワーク２６０を介してデータ転送可能とされている。ＰＣ１６０は、ワークフロー定義データや条件設定データなどを、ＸＭＬなどの構造化文書として作成し、ネットワーク２６０を介して処理ノード１２０に対してＸＭＬベースで送付し、処理ノード１２０に対しワークフロー上で定義された処理を実行させている。

当該他の実施形態の場合、処理ノード１２０は、ＰＣ１６０からワークフロー定義データ、条件設定データおよびＵＩ構造定義などを構造化文書として受領し、受領した構造化文書を例えばＸＭＬパーザやＤＯＭなどを使用して読み出して設定する。その後処理ノード１２０は、ワークフロー定義に設定された処理を設定した条件設定データにしたがって実行する。処理ノード１２０は、自機で条件設定をカスタム化する必要がない場合には、操作パネルなどのＵＩ表示部２１０を起動させることなく条件設定データを設定の記述順序や配置に関わらずに設定し、担当するべき処理を実行する。処理ノード１２０が分担するべき処理が完了した後、処理済みデータを、ワークフロー定義にしたがって、印刷出力したり、他の処理ノードへ転送したりといった後続処理を実行する。

図３は、本実施形態で使用するワークフロー３００の階層構造および当該階層構造を定義するワークフロー制御データの実施形態を示す。ワークフロー３００は、本実施形態では、ワークフロー３００を定義するべき適切な装置、例えば、ＰＣ１６０のデスクトップ画面や処理ノードを構成するＭＦＰのＵＩ表示装置などから、ユーザがインタラクティブに設定する。なお、ワークフローの設定のユーザインタフェースについては、特許文献１を参照することができる。

図３には、また、ワークフロー３００の階層構造の、２分木構造３１０も並列的に示されている。ワークフロー３００は、階層構造としては、画像データの生成処理を実行するＭＦＰをルートノードとして表現することができる。なお、画像データがすでに電子化され、データベースなどに登録されている実施形態の場合には、ＭＦＰに加え、ＰＣ１６０などがルートノードとしての機能を提供することができる。

図３に示した実施形態では、ルートノードに相当するＭＦＰまたはＰＣには、能力や設置位置などに対応してプロファイルが割り当てられていて、ワークフロー上の処理ノードを構成する。また、ルートノードは、子ノードとして例えば、出力機能が共通する毎に複数のワークフローグループが設定されている。例えば、ワークフローのグループＧｒ１は、「Scan to Mail」、Ｇｒ２は、「Scan to Folder」、Ｇｒ３は、「Scan to Print」などとして登録されており、ワークフローの実行依頼を容易にするために、ＭＦＰまたはＰＣのＵＩ表示部２１０に個別的にＵＩボタンなどとして表示させることができる。

さらに特定のグループは、複数の孫ノードとして、各グループでユーザカスタマイズされたプロジェクトＰｊ１、Ｐｊ２、Ｐｊ３、・・・から構成される。各プロジェクトＰｊ１〜Ｐｊ３は、例えば、ユーザ毎、宛先毎、機能設定が共通するジョブ毎の単位で独立して登録され、それぞれがユーザカスタマイズされた条件設定を伴っている。また、特定のプロジェクトは、例えば、Ｆｎ１＝６００ｄｐｉでの画像読み取り→Ｆｎ２＝ＰＤＦ変換→Ｆｎ３＝特定メールアドレスへのメール転送といった、個別的な条件設定データを伴う個別ジョブとされている。

木構造３１０は、処理ノードにおける実装形式では、構造化文書、より詳細には、ＸＭＬ文書３２０で記述され、処理ノードのワークフロー制御データとして使用される。ＸＭＬ文書３２０は、ワークフローのシーケンス毎に、処理を担当するプログラムであるPlug-inの指定、Plug-inが利用する設定条件３３０、３４０、３５０、３６０などが記述されている。本実施形態のＸＭＬ文書３２０は、ワークフローを構成するプロジェクトの機能を実行する処理ノードは、処理するべき機能に関係するＸＭＬ文書を参照して、Pulug-inを設定し、その設定条件を読み出して処理を開始し、さらに後続する機能に処理を渡す。なお、成就付した通り、機能は、単独の処理ノードで完結させることもできるが、複数の処理ノード間での分散処理で完結させてもよい。

また、図３に示すＸＭＬ文書３２０は、取得した画像データを、ＰＤＦフォーマットに変換した後、電子メールおよびフォルダに格納するシーケンスを構成する、フィルタ機能３２２、フォルダ格納機能３２４、メール送信機能３２６を設定するデータが記述されている。なお、単独に処理ノードでワークフローを完結させる場合の他、分散処理を行う目的でワークフローを作成したＰＣ１６０や、処理ノード１２０から、ワークフローを構成する他の処理ノードに配布してもよい。

図４は、本実施形態でＵＩを形成するために使用するＵＩ生成ファイルのデータ構造を示す。本実施形態では、ＵＩ表示部２１０に表示させるためのデータ構造体に対し、データ構造体を固有に識別するためのＵＩ識別値を割り当てる。ＵＩ識別値は、例えば、ＵＩが関連するメール、フォルダ格納、ファックス通信などの機能を特定する機能識別値と、ＵＩ構造定義のバージョンを指定するバージョン識別値とを含む構造とされている。より具体的には、電子メール用のＵＩを提供するためのバージョン０１のＵＩには、「SCREEN_mail_01」、バージョン０ＮのＵＩ構造定義には、「SCREEN_mail_0N」といった固有のＵＩ識別値が割り当てられる。

また、本実施形態のＵＩ生成ファイルは、ＵＩ構造定義と、当該ＵＩ構造定義が利用する条件設定データ４３０とに分離されている。ＵＩ構造定義は、本実施形態では、ＵＩ表示を行うためのＵＩパーツを記述したファイルである。また、条件設定データとは、ＵＩパーツを介してインタラクティブに設定された、または以後に設定されるべきデータ値を意味する。より具体的には、例えば、ＩＤ＝SCREEN_mail_01のＵＩ生成データ４１０は、図４に示すようにＵＩ構造定義４２０と、条件設定データ４３０とから生成される。

ＵＩ構造定義４２０は、本実施形態では、ＸＭＬ、ＨＴＭＬ、ＸＨＴＭＬまたはＨＴＭＬを含むＸＭＬおよび適宜ＣＳＳやＸＳＬＴなどを含ませた構造とされている。また、条件設定データ４３０は、ＸＭＬ、ＸＨＴＭＬなどの構造化文書で作成されていて、ＵＩ構造定義４２０とは別のデータ構造体として構成され、Plug-inプログラムを実行するべき処理ノードに配布される。ＵＩ構造定義と、条件設定データとは、それぞれ表示するべきＵＩのカテゴリ毎に相互関連付けされている。たとえば、ＵＩ構造定義ＩＤ＝SCREEN_mail_01は、条件設定データとして、同一に参照識別値「mail」を含む、「mail_setting_information」を参照するように関連付けられる。

本実施形態で、Plug-inのベンダのPlug-inのバージョンアップなどに対応してＵＩ構造定義４２０が、ＵＩ構造定義４６０に修正されたものとする。修正に際しては、新規な機能の追加やレイアウト修正などに対応し、対応するＵＩパーツの配置や種類が修正される。この場合、ベンダは、処理ノードにおける処理のため、ＵＩ構造定義４６０を処理ノードに配布し、設定する必要がある。一方、処理ノードでは、ユーザにより処理条件がカスタマイズされた条件設定データが複数の個別的プロジェクトに対して設定されている。このため、ＵＩ構造定義の修正があった場合にでも、既設定の条件設定データの利用できるデータがあれば可能な限り利用して、最も好ましくは、追加修正された機能に関連するデータのみの設定入力だけでワークフローを利用させることが、ワークフローの有効利用およびメンテナンス性を向上させる観点では好ましいということができる。

このため、本実施形態では、ＵＩ構造定義と、条件設定データとを分離し、適切なインタフェースを介して、既存の条件設定データ４８０を、異なるＵＩ生成データ４５０のＵＩ構造定義４６０が利用する条件設定データ４７０として利用させる。条件設定データ４７０は、条件設定データ４３０と比較し、表示するＵＩ項目が共通する限り条件設定データ４８０内での記述順にかかわらず、データが共有される。

データの共有を可能とするため、本実施形態では、データ継承部２３４をインタフェースとして提供する。データ継承部２３４は、登録された条件設定データ４８０が含む共用可能データを、構造化文書中での記述順に関わらず、条件設定データ４７０に設定する。データ継承部２３４は、本実施形態で構造化文書を使用する点では、ＤＯＭ(Document Object Model)を使用し、条件設定データ４８０から、ＤＯＭを使用してデータを読み出し、ＵＩ生成データ４５０が使用する条件設定データ４７０として設定させるインタフェースとする形式を採用することが、ソフトウェア／ハードウェア資源の追加を最小化させる目的で好ましい。

上記の目的から、データ継承部２３４は、ブラウザ処理部２２０が解釈して実行できるスクリプト言語で記述することができ、例示的なスクリプト言語としては、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ、ＶＢＳｃｒｉｐｔ（登録商標）、その他行単位で解釈実行し、処理を実行可能なスクリプトを挙げることができ、特に限定されることはない。なお、ソフトウェア資源に充分な余裕がある場合には、Ｊａｖａ（登録商標）の実行コードでインタフェースを提供してもよい。

図５は、本実施形態のユーザインタフェース（ＵＩ）提供方法のフローチャートを示す。図５の処理は、ステップ５００で、処理ノードが、ユーザによるワークフローに関連するＵＩの表示指令を受領した時点で開始する。ステップＳ５０１で、ＵＩ表示部２１０で、特定のＵＩを指定するイベント発生を検出し、指定されたＵＩのＵＩ識別値を取得する。ステップＳ５０２では、直前に表示させたＵＩ識別値のバージョン識別値をログデータなどから取得して、起動するべきPlug-inに対応付けられた現在バージョン識別値と直前バージョン識別値を比較する。

ステップＳ５０２の比較でバージョン識別値が一致する場合（ｙｅｓ）、ステップＳ５０５で、条件設定データの読み込みを実行させ、ステップＳ５０６でＵＩを表示させた後、ステップＳ５０６で処理を終了させる。なお、ステップＳ５０５の条件設定データの読み込みは、ＵＩバージョンの変更がないことから、構造化文書として記述された条件設定データにアクセスすること無しに、直前にＵＩを表示するために利用した条件設定データをキャッシュしておき、キャッシュ内容にアクセスすることができる。また、他の実施形態では、ブラウザ処理部２２０がCookieを利用することができる場合、設定条件データを、Ｃｏｏｋｉｅから取得して利用することもできる。

一方、ステップＳ５０２で、前回表示を行ったときの前回バージョン識別値と、現在表示しようとするべき現在バージョン識別値とが一致していない場合、ステップＳ５０３で、新たに起動するべきＵＩが表示するべき条件設定データを継承するため、ブラウザ処理部２２０は、データ継承部２３４を呼び出し、データ継承処理を実行させ、現在バージョンのＵＩパーツに対応して、既存設定データの取得を可能とする。ステップＳ５０４では、新バージョンのＵＩを与えるＵＩ構造定義を使用して新バージョンのＵＩを表示させる。表示されたＵＩは、新バージョンのＵＩ構造定義の相違に依存することなく、既存の条件設定データを継承し、ＵＩバージョンの修正・変更にかかわらず、既存設定のデータを効果的に利用してワークフローの処理を継続させ、その後、ステップＳ５０６で処理を終了する。

図６は、本実施形態で使用する条件設定データ４８０の実施形態を示す。図６に示した条件設定データは、図３で示したワークフロー制御データ３００に対応する条件設定データを記述した実施形態である。先頭行から、ＸＭＬのバージョンとエンコーディングが指定され、第２行目には、参照されるべき、ＵＩのＵＩ機能を識別するための識別値を含むファイル名が記述されている。その後、＜ｓｍｔｐ＞、＜server_name＞、＜port＞、＜user＞、＜address＞などの設定条件タグにより、設定データが規定された構造とされている。これらのデータのうちのいくつかはベンダ側で予め設定するものもあるし、他のデータはユーザ設定により処理ノード固有の値が設定される。

図６で示した条件設定データは、電子メール送信を制御するためのデータであるが、本実施形態では、さらに、フォルダ送信、プリント、画像読み取りなどの各種機能の条件を設定するための構造化文書ファイルを実装させることができる。

図７は、本実施形態でインタフェースとして機能し、ＤＯＭ機能を含むデータ継承部２３４の機能を提供するための疑似コードの示す。図７の疑似コードは、まず、前回読み込んだＵＩ構造定義の前回バージョン識別値（prior_ver）と、現在表示するべきＵＩ構造定義の現在バージョン識別値(current_ver)とを比較し、一致する場合には、前回利用した条件設定データを順に読み取る関数“read_cache”を起動する。また、前回バージョン識別値（prior_ver）と、現在表示するべきＵＩ構造定義の現在バージョン識別値(current_ver)とが不一致の場合には、ＤＯＭを使用してＸＭＬで記述された条件設定データを読み出す関数である“inheritance()”を呼び出してデータ読み取りを実行する。図７には、関数inheritance()の読み取り処理コードも示す。図６に示した条件設定データを記述した構造化文書から、設定するべきデータ値を、設定条件タグの順に、該当するデータを登録するアドレス領域にバッファリング処理を実行する。

図７に示した疑似コードの関数“inheritance()”は、行番号１５〜３８で規定されており、ＤＳＯ(Data Source Object)を呼び出し、以下ｗｈｉｌｅ構文が終了するまで、既存の条件設定データから、指定した行に定義された条件設定データを読み込んで、読み込んだ値をバッファリンする。なお、疑似コードにおいて設定する変数、Document.DocumentElement.childnodes.lengthは、条件設定データに記述されたタグで設定されている条件設定データの種類数を指定する値であり、ＤＯＭを使用して、予め取得しておくことができる。また他の実施形態で、条件設定データ数が予め規定されている場合には、設定定数として、機能毎に設定してもよい。

図６および図７を使用して、より具体的にデータ継承部２３４の処理を説明すると、例えば、疑似コードの２２行目では、smtp_data=Document.DocumentElement.childnodes(i)で、図６の条件設定データの値「SMTPS」を読み取り、変数smtp.innerText=SMTPSとして設定する。以下、順次、server_nameから最終の設定条件データまでの読み取りを実行する。一方、ＵＩ構造定義は、ＨＴＭＬ、ＸＭＬ、ＸＳＬＴおよび適宜ＣＳＳを使用して実装されていて、例えば＜smtp id＝“SMTPS”＞として、読み出した値を、ノード＜smtp＞の値として渡すことができる。以下、同様のコーディングにより、新たなＵＩ定義構造に使用するための条件設定データを設定して行くことができる。設定されたデータは、プログラム実行部１２２の管理する適切な記憶領域に格納され、以後、プログラム実行部１２２がＵＩインスタンスを生成する期間、保持される。

図８は、本実施形態でＵＩ表示部２１０が表示するＵＩの実施形態を示した図である。図８に示したＵＩ８００は、処理ノードにおいて電子メール機能の設定を行うために提供される。ＵＩ８００から設定されたホットスポットを操作するなどの操作により、ホットスポットに関連付けられた、現在表示している現在バージョンの編集ボックスのＵＩ構造定義が読み込まれる。編集ボックス８１０は、編集対象の値を入力するテキストボックス８２０およびボタン８３０などのＵＩパーツが配置されていて、ユーザによる、例えば送信元アドレスの追加、編集、削除などの処理を可能としている。

図９は、図８に示した編集ボックスを提供するためのＵＩ構造定義９００の実施形態を示す。ＵＩ構造定義９００には、第２行目でＵＩ構造定義の機能およびバージョンを指定するＵＩ識別値である“Mail_Screen_01”が記述されている。また、第３行目〜第５行目で当該ＵＩが、電子メール用のウィンドウの編集ボックスであることが記述されている。編集ボックス内でデフォルト設定された値は、前回起動時にプログラム実行部がキャッシュメモリまたは適切なバッファメモリなどの記録された“sender_address”の内容が読み出されて表示されている。ユーザは、図８に示した実施形態の編集ボックス８１０から修正する送信元アドレスを入力し、その値をユーザカスタマイズすることができる。

次回に編集ボックスを読み込んだ段階で、編集ボックス用のＵＩパーツの配置などが修正されている場合、異なるバージョン識別値が与えられる。この実施形態の場合、行毎に表示するべき条件設定データを静的に読み込む処理を実行すると、異なるデータが編集ボックス内に表示されてしまったり、まったく表示されない場合も発生し、既存データが無駄となり、また再度の入力のための労力や入力ミスも発生する。本実施形態では、データ読み取りインタフェースとしてデータ継承部２３４を構成し、既存の条件設定データからＤＯＭ構造を構成して現在表示するべきＵＩに設定するので、既存のデータを効率的に利用でき、またベンダ側で、機能の追加・修正に伴うＵＩ設計を効率化することができる。

図１０は、本発明にしたがい、生成される、ＵＩ表示１０００の実施形態を示す。図１０に示したＵＩ表示は、処理ノードの実装形式に応じて、ＭＦＰの操作パネルにＵＩ表示を提供することもできるし、処理ノードがＰＣ１６０の場合には、ＵＩ表示１０００を、ディスプレイ装置上にＭＦＰの操作パネルをエミュレーションして表示させることもできる。図１０示したＵＩ表示１０００には、ワークフローが含むメール送信機能の設定画面１０１０が例示的に示されている。設定画面１０１０には、メール送信を行う場合に使用するＳＭＴＰサーバの名称を入力する編集ボックス１０２０および標準的に使用する言語のエンコード情報を選択するためのセレクトボックス１０３０が表示されている。

ユーザは、処理ノードがＭＦＰの場合、操作パネルに表示された設定画面１０１０から、またＰＣ１６０の場合には、ディスプレイ装置にエミュレーション表示された設定画面から、編集ボックス１０２０にＳＭＴＰサーバ名を入力し、またセレクトボックス１０３０で使用する言語エンコード情報を、例えば、「ＵＴＦ−８」などとして設定する。設定後、図示しない「ＯＫ」ボタンを操作して、設定を条件設定データとして登録する。

登録された条件設定データは、説明する実施形態では、プログラム実行部１２２がデフォルトで読み込んだ条件設定データの対応するデータに上書きされ、ユーザによる設定条件データのカスタマイズを可能とする。なお、同一の条件設定データを修正するＵＩ構造定義が修正される場合、例えばワークフローを管理する管理サーバなどからＵＩ構造定義のみが送付される。ＵＩ構造定義の修正は、多くの場合、設定項目の追加や、レイアウト変更などを伴うが、静的な条件設定データ読み込みを行う場合、レイアウト変更に関連して、その配置が修正された処理ノードにすでに設定された条件設定データであっても有効に利用することができない。

本実施形態では、ＵＩ構造定義とともに、ＤＯＭを利用するデータ継承部を利用することによって、動的な条件設定データの読み込みを可能とすることで、処理ノードにおいて、既存の設定条件を効果的に利用しながらワークフローの設定を継承させることができる。一方、本実施形態のＵＩ提供方法は、ＵＩ構造定義と、条件設定データとを構造的に分離させているので、他のデータを修正することなくＵＩ構造定義をユーザ毎に動的にカスタマイズすることも可能となる。

図１１は、本実施形態において、ユーザ毎にＵＩ表示を制御する実施形態を、図１０に示したＵＩ表示１０００を例として説明する。図１１に示したＵＩ構造定義１１１０には、ＵＩパーツとして、サーバ名編集パーツ１１３０と、言語エンコード指定パーツ１１２０が記述されている。さらに、ＵＩ構造定義１１１０には、ＣＳＳ(Cascading Style Sheet)を参照するためのＸＭＬ行が記述されていて、当該ＵＩ構造定義１１１０で提供されるＵＩパーツの表示制御を可能とする。ＵＩパーツの表示制御は、ＵＩ構造定義１１１０とは別に定義されるＵＩ表示制御ファイル１１５０により与えられ、処理ノードを管理するユーザに対してＵＩ表示を修正したい場合には、表示・非表示とする設定を変更するＵＩ表示制御ファイルを、例えば管理サーバやＰＣ１６０から特定のユーザサイトに配置された処理ノードに配布することで、ＵＩ構造定義１１１０が、ブラウザ処理部２２０に読み取られた場合に、ＵＩ表示制御ファイル１１５０に従って表示・非表示の制御ができる。

図１１に示す実施形態では、ＵＩ表示制御ファイル１１５０の参照は、“ｈｒｅｆ”属性としてファイル名をリンクしているが、参照の形式は特に限定されるものではなく、特定のＵＲＬまたはＵＲＩをリンクさせることもできるし、パス指定ついても絶対パス指定、相対パス指定も特定の実装形式に応じて適宜選択することができる。

図１１には、本実施形態で使用するＵＩ表示制御ファイル１１５０の実施形態も示す。ＵＩ表示制御ファイル１１５０は、例示的にＣＳＳを使用して記述しているが、そのバージョンは特に限定されることはなく、また、ＸＳＬＴを使用することもできる。図１１のＵＩ構造定義１１１０に対して、ＵＩ表示制御ファイル１１５０にしたがい、図１０に示した設定画面を表示させることで、設定画面１１６０が表示される。設定が件１１６０では、ＳＭＴＰサーバ名を入力するパーツ１１７０は表示されているが、本来矩形枠１１８０で示される領域に表示されるべき言語エンコード指定パーツは、非表示とされ、ユーザによる言語エンコード指定のカスタマイズを制限することを可能としている。なお、表示制御を行うパーツについては特に限定されるものではなく、ユーザのアクセス権原、アクセス特権、サービス契約内容、課金制限などに応じて、他のＵＩ構造定義に大幅な修正を加えることなく、ＵＩ表示をユーザに容易にカスタマイズすることが可能となる。

本実施形態の上記機能は、Ｃ＋＋、Ｊａｖａ（登録商標）、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ（登録商標）、Ｐｅｒｌ、Ｒｕｂｙ、Ｐｙｔｈｏｎなどのオブジェクト指向プログラミング言語などで記述された装置実行可能なプログラムにより実現でき、本実施形態のプログラムは、ハードディスク装置、ＣＤ−ＲＯＭ、ＭＯ、フレキシブルディスク、ＥＥＰＲＯＭ、ＥＰＲＯＭなどの装置可読な記録媒体に格納して頒布することができ、また他装置が実行可能な形式でネットワークを介して伝送することができる。

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

１００…画像処理システム、１１０、１２０、１７０…処理ノード、１２２…プログラム実行部、１２２ａ…ＭＦＰクラス、１２２ｂ…ＭＦＰ互換性クラス、１２２ｃ…ＰＣインタフェースクラス、１２６…管理機能部、１２８…ＯＳカーネル、１３０…インタフェース、１４０…ＭＦＰ、１５０…互換ＭＦＰ、１６０…ＰＣ、２００…機能ブロック（プログラム実行部）、２１０…ＵＩ表示部、２２０…ブラウザ処理部、２３０…ワークフロー管理部、２３２…ＵＩ構造定義取得部、２３４…データ継承部、２４０…処理実行部、２５０…記憶装置、２６０…ネットワーク

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

Claims (20)

1. ユーザインタフェースを表示するための表示装置を有する画像処理装置であって、
   ユーザインタフェースを生成するための条件設定データを記憶する記憶手段と、
   前回表示を行った時のユーザインタフェースのバージョン情報を記憶すると共に、指定されたユーザインタフェースのバージョン情報を取得する取得手段と、
   記憶されているユーザインタフェースのバージョン情報と、指定されたユーザインタフェースのバージョン情報とが一致しない場合に、ユーザインタフェースのバージョンに依存せず、かつ提供可能な機能ごとに割り当てられた共用可能なデータを記述した条件設定データをＵＩパーツごとに継承する継承手段と、
   継承した画像処理の条件を含むユーザインタフェースを前記表示装置に表示する表示手段と
   を含む画像処理装置。
2. 前記画像処理装置は、画像形成装置の機能を特定するための機能識別値と、ＵＩ構造定義のバージョンを識別するためのバージョン識別値とを含むＵＩ識別値のバージョン情報を取得する、請求項１に記載の画像処理装置。
3. 前記取得手段は、ネットワークを介して構造化文書としてＵＩ構造定義を取得し、取得した前記データを前記記憶手段に格納する、請求項１または２に記載の画像処理装置。
4. 前記条件設定データは、対応する前記ＵＩ構造定義に関連付けられており、前記継承手段は、前記ＵＩ構造定義を読み込み、現在のユーザインタフェースを生成するためのＵＩ構造定義の現在バージョン識別値と、直前に読み込んだＵＩ構造定義を指定する前回バージョン識別値とを比較し、各バージョン識別値が不一致の場合に、前記記憶手段から前回使用した条件設定データを読み出し、前記現在バージョン識別値で指定されるＵＩ構造定義に対して読み出し順とは独立して前記条件設定データを設定する、請求項２または３のいずれか１項に記載の画像処理装置。
5. 前記ＵＩ構造定義および前記条件設定データは、独立した構造化文書であり、それぞれ画像データに対して実行するべき情報処理のユーザインタフェースを提供するために関連付けられている、請求項２〜４のいずれか１項に記載の画像処理装置。
6. 前記画像処理装置は、前記画像データに対してシーケンスとして定義される前記情報処理の処理ノードである、請求項５に記載の画像処理装置。
7. 前記情報処理は、Plug-inプログラムにより実行され、ＵＩ構造定義は、前記Plug-inプログラムのためのユーザインタフェースを提供する、請求項６に記載の画像処理装置。
8. 前記表示手段は、ＵＩ構造定義の表示制御を行う表示制御手段を備え、ネットワークを介して送付されるＵＩ表示制御ファイルにより、前記ＵＩ構造定義が提供するＵＩパーツの可視性を制御する、請求項１〜７のいずれか１項に記載の画像処理装置。
9. 前記情報処理のシーケンスは、前記画像データのメール送信、ファイル格納、ファクシミリ送信、またはプリントするワークフローを構成しており、前記情報処理は、前記ワークフローを担当する前記処理ノードが実行する請求項６〜８のいずれか１項に記載の画像処理装置。
10. 画像処理装置が実行する処理を管理するユーザインタフェースを提供する前記画像処理装置と分離した情報処理装置であって、前記情報処理装置は、
    前記ユーザインタフェースの構造を定義するＵＩ構造定義を取得する取得手段と、
    前記ＵＩ構造定義を解釈してユーザインタフェースを表示する表示手段と、
    前記ＵＩ構造定義および前記ユーザインタフェースを介したデータ操作によりインタラクティブに設定され、前記ユーザインタフェースのバージョンに依存せず、かつ画像処理装置の機能ごとに割り当てられた条件設定データを格納する記憶手段と、
    前記条件設定データを構造化文書として前記画像処理装置に送付するネットワーク通信手段とを含み、
    前記情報処理装置は、前記画像処理装置に対して前記条件設定データを配布し、画像形成装置に対して前記条件設定データを順に読み込ませ、読み込んだ前記条件設定データを、継承手段により読み込みの順とは独立して前記ＵＩ構造定義により指定される条件設定データとしてＵＩパーツごとに設定させ、前記画像処理装置の処理実行手段に対し条件設定データを使用して画像データに対して少なくとも１の情報処理を実行させ、
    前記条件設定データは、対応する前記ＵＩ構造定義に関連付けられており、前記画像処理装置の前記継承手段は、前記ＵＩ構造定義を読み込み、現在のＵＩ構造定義の現在バージョン識別値と、直前に読み込んだＵＩ構造定義の前回バージョン識別値とを比較し、各バージョン識別値が不一致の場合には、前記現在バージョン識別値で指定される前記ＵＩ構造定義に対して読み出し順とは独立して前記条件設定データを設定することにより既存のＵＩ構造定義を継承させる、情報処理装置。
11. 前記画像処理装置は、前記画像データに対してシーケンスとして定義される前記情報処理の処理ノードである、請求項１０に記載の情報処理装置。
12. 前記情報処理は、Plug-inプログラムにより実行され、前記ＵＩ構造定義は、前記Plug-inプログラムのためのユーザインタフェースを提供する、請求項１０または１１のいずれか１項に記載の情報処理装置。
13. ユーザインタフェースを表示する画像処理装置が実行するインタフェース提供方法であって、前記画像処理装置が、
    前記ユーザインタフェースの構造を定義するＵＩ構造定義を取得するステップと、
    前記ＵＩ構造定義および前記ユーザインタフェースを介したデータ操作によりインタラクティブに設定される画像処理のため、対応する前記ＵＩ構造定義に関連付けられ、前記ユーザインタフェースのバージョンに依存せず、かつ画像処理装置の機能ごとに割り当てられた条件設定データを記憶手段に格納するステップと、
    前記ＵＩ構造定義を読み込み、現在のＵＩ構造定義の現在バージョン識別値と、直前に読み込んだＵＩ構造定義の前回バージョン識別値とを比較するステップと、
    各バージョン識別値が不一致の場合に、前記記憶手段から前回使用した条件設定データを読み出し、前記現在バージョン識別値で指定される前記ＵＩ構造定義に対して読み出し順とは独立し前記条件設定データをＵＩパーツごとに設定するステップと、
    前記ＵＩ構造定義を解釈して読み込んだ前記条件設定データを表示するユーザインタフェースを表示させるステップと、
    設定された前記条件設定データを使用して画像データに対して少なくとも１の情報処理を実行させるステップと
    を実行する、ユーザインタフェース提供方法。
14. 前記ＵＩ構造定義を、ネットワークを介して構造化文書として取得し、前記記憶手段に格納する、請求項１３に記載のユーザインタフェース提供方法。
15. 前記画像処理装置は、前記画像データに対してシーケンスとして定義される前記情報処理の処理ノードであり、前記ＵＩ構造定義は、前記情報処理のためのPlug-inが前記ユーザインタフェースを提供するために利用する、請求項１３または１４に記載のユーザインタフェース提供方法。
16. 前記ユーザインタフェースを表示させるステップは、前記ネットワークを介して送付されるＵＩ表示制御ファイルにより、前記ＵＩ構造定義が提供するＵＩパーツの可視性を制御するステップを含む、請求項１３〜１５のいずれか１項に記載のユーザインタフェース提供方法。
17. 請求項１〜９のいずれか１項に記載の複数の画像処理装置と、
    前記複数の画像処理装置を相互接続するネットワークと
    を含み、前記画像データに対してシーケンスとして定義される複数の前記情報処理を前記画像処理装置のみで、または前記複数の画像処理装置間の分散処理により実行する、画像処理システム。
18. 画像処理装置がユーザインタフェースを表示するための装置実行可能なプログラムであって、前記プログラムは、前記画像処理装置を、
    前記ユーザインタフェースを表示するためのＵＩ表示手段、
    前記ユーザインタフェースの構造を定義するＵＩ構造定義を取得する取得手段、
    前記ＵＩ構造定義を解釈して前記ＵＩ表示手段にユーザインタフェースを表示するブラウザ処理手段、
    前記ＵＩ構造定義および前記ユーザインタフェースを介したデータ操作によりインタラクティブに設定され、前記ユーザインタフェースのバージョンに依存せず、かつ画像処理装置の機能ごとに割り当てられた条件設定データを格納する記憶手段、
    前記条件設定データを順に読み込み、読み込んだ前記条件設定データを、読み込みの順とは独立して前記ＵＩ構造定義の該当する条件設定データとしてＵＩパーツごとに設定する継承手段、
    前記継承手段により設定された条件設定データを使用して画像データに対して少なくとも１の情報処理を実行させる処理実行手段
    として機能させ、
    前記条件設定データは、対応する前記ＵＩ構造定義に関連付けられており、前記継承手段は、前記ＵＩ構造定義を読み込み、現在のＵＩ構造定義の現在バージョン識別値と、直前に読み込んだＵＩ構造定義の前回バージョン識別値とを比較し、各バージョン識別値が不一致の場合に、前記記憶手段から前回使用した条件設定データを読み出し、前記現在バージョン識別値で指定される前記ＵＩ構造定義に対して読み出し順とは独立して前記条件設定データを設定する、
    装置実行可能なプログラム。
19. 前記取得手段は、ネットワークを介して構造化文書として前記ＵＩ構造定義を取得し、取得した前記ＵＩ構造定義を前記記憶手段に格納する、請求項１８に記載のプログラム。
20. 前記ＵＩ構造定義および前記条件設定データは、独立した構造化文書であり、それぞれ前記画像データに対して実行するべき前記情報処理のユーザインタフェースを提供するために関連付けられており、前記情報処理は、Plug-inプログラムにより実行され、前記ＵＩ構造定義は、前記Plug-inプログラムのためのユーザインタフェースを提供する、請求項１８または１９に記載のプログラム。
    

Images