JP6618280B2 - 画像形成装置、画像形成装置の制御方法、及び記憶媒体 - Google Patents

Description

本発明は、画像形成装置、画像形成装置の制御方法、及び記憶媒体に関する。

近年、オフィスに設置される画像形成装置には、画像形成装置の機能を拡張できるシステムが普及している。拡張する機能（以降、拡張機能）は、ソフトウェアプログラム（以降、拡張ソフト）によって実現され、工場出荷時だけでなく、設置後の運用段階でも追加することが可能である。この種のシステムとしては、キヤノン株式会社のＭＥＡＰ（登録商標）などがあげられる。

また、ユーザが選択した拡張ソフトを外部サーバからダウンロードし、インストールすることで、画像形成装置の機能の拡張を可能とする技術が知られている（特許文献１参照）。

特に、ある特定の目的のために作られた拡張ソフトは、アプリケーションソフトウェア（以降、アプリ）と呼ばれる。アプリは、画像形成装置が備えるファクシミリ、スキャナ、プリンタといった機能を利用することで目的の処理を実現している。画像形成装置は、ユーザの目的に応じて複数のアプリをインストールできるように構成されている。

特許第４０３９４３９号公報

従来技術では、アプリは目的の処理を実現するための手順をプログラムで規定している。アプリは、予めプログラムで規定した処理しか実行できないため、それ以外のことを実現しようとすれば、アプリのプログラムを修正するか、別のアプリを用意する必要があり、拡張機能の柔軟な運用ができなかった。
なお、このような問題は、画像形成装置に特有なものではなく、パーソナルコンピュータ等の他の情報処理装置にも共通なものである。

本発明は、上記の問題点を解決するためになされたものである。本発明の目的は、例えば画像形成装置等の情報処理装置に追加される拡張機能の柔軟な運用を可能にする仕組みを提供することである。

本発明は、画像形成装置であって、複数のプログラムをインストールするインストール手段と、前記複数のインストールされたプログラムのそれぞれについて、プログラムを一意に特定する識別情報とプログラムの機能タイプを示す機能タイプ情報とを含む情報を登録する登録手段と、複数の工程からなる一連の処理を定義するワークフロー定義ファイルに従って複数のプログラムを組み合わせて一連の処理を実行するワークフローの実行指示を受け付ける受付手段と、前記複数の工程を含む処理手順を定義し、前記工程ごとに、プログラムの識別情報またはプログラムの機能タイプのいずれかで指定されている、前記実行指示に対応するワークフロー定義ファイルを取得する取得手段と、前記ワークフロー定義ファイルにおいて、前記工程ごとに、プログラムの指定が、プログラムの識別情報と、プログラムの機能タイプのどちらでなされているかの判定をする判定手段と、前記判定において、プログラムの指定が、プログラムの識別情報で指定されていると判定された場合、前記登録されている情報に基づいて、前記インストールされている複数のプログラムから、指定されている識別情報のプログラムを検索し、前記判定において、プログラムの指定が、プログラムの機能タイプで指定されていると判定された場合、前記登録されている情報に基づいて、前記インストールされている複数のプログラムから、指定されている機能タイプのプログラムを検索する検索手段と、前記ワークフロー定義ファイルにおける複数の工程について、前記工程ごとに、前記検索の結果に基づいて決定したプログラムを順次実行する実行手段と、を有することを特徴とする。

本発明によれば、情報処理装置に追加される拡張機能の柔軟な運用を可能にすることができる。

本実施例の画像処理装置（ＭＦＰ）を適用可能なシステムの構成図 ＭＦＰのハードウェア構成図 サーバのハードウェア構成図 ＭＦＰのソフトウェア構成図 画像処理システムにおける処理のシーケンス図 ＭＦＰにおける機能プロバイダ情報テーブル更新処理のフローチャート 機能プロバイダ情報テーブルを例示する図 ＭＦＰにおける機能プロバイダ設定テーブル設定処理のフローチャート 機能プロバイダ設定テーブルを例示する図 ワークフロー定義ファイルを例示する図 ＭＦＰにおけるワークフロー実行処理のフローチャート ＭＦＰにおける機能プロバイダ検索処理のフローチャート 機能プロバイダインタフェース定義を例示する図

以下、本発明を実施するための形態について図面を用いて説明する。
図１は、本発明の情報処理装置の一実施例を示す画像処理装置を適用可能なシステムの構成を例示する図である。
本実施例のシステムは、ＬＡＮ１１０を介して接続されるＭＦＰ１０１と、ＷＡＮ１２０を介して接続されるサーバ１０２を有する。ＬＡＮ１１０上の装置とＷＡＮ１２０上の装置とは、お互いのネットワークを通して相互に通信可能である。なお、図１は、典型的なネットワーク構成の例であり、各装置がＬＡＮ１１０またはＷＡＮ１２０のどちらにあっても構わない。

ＭＦＰ１０１は、スキャナ、プリンタを有する画像形成装置（ＭＦＰ；Ｍｕｌｔｉｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）である。加えて、ＭＦＰ１０１は、装置上で動作する拡張ソフトを追加、実行させるためのソフトウェアプラットホームを持つ。ＭＦＰ１０１は、拡張ソフト（拡張プログラム）により機能の追加拡張が可能な情報処理装置である。

サーバ１０２は、ＭＦＰ１０１と連携して各種処理を行うサーバである。例えば、サーバ１０２は、ＭＦＰ１０１から画像データを受信するファイルサーバであったり、ＭＦＰ１０１から処理依頼を受けてＯＣＲ（光学文字認識）処理を実行するアプリケーションサーバであったりする。サーバ１０２は、一台とは限らず、目的に応じて複数のサーバが存在してもよい。

図２は、ＭＦＰ１０１の構成を例示するブロック図である。
ＣＰＵ２１１を含む制御部２１０は、ＭＦＰ１０１全体の動作を制御する。
ＣＰＵ２１１は、ＲＯＭ２１２やＨＤＤ２１４に記憶された制御プログラムを読み出して読取制御や送信制御などの各種制御処理を実行する。ＲＯＭ２１２は、各種のプログラムやデータを記憶する。ＲＡＭ２１３は、ＣＰＵ２１１の主メモリ、ワークエリア等の一時記憶領域として用いられる。ＨＤＤ２１４は、画像データやインストールされた拡張ソフトを含む各種プログラムを記憶するハードディスクドライブである。なお、ＨＤＤの代わりに又は併用してＳＳＤ（ソリッドステートドライブ）等の他の記憶装置を設けてもよい。

操作部Ｉ／Ｆ２１５は、操作部２１９と制御部２１０とを接続する。操作部２１９には、タッチパネル機能を有する液晶表示部やキーボードなどが備えられている。
プリンタＩ／Ｆ２１６は、プリンタ２２０と制御部２１０とを接続する。プリンタ２２０で印刷すべき画像データはプリンタＩ／Ｆ２１６を介して制御部２１０からプリンタ２２０に転送され、プリンタ２２０において記録媒体上に印刷される。
スキャナＩ／Ｆ２１７は、スキャナ２２１と制御部２１０とを接続する。スキャナ２２１は、原稿上の画像を読み取って画像データを生成し、スキャナＩ／Ｆ２１７を介して制御部２１０に入力する。

ネットワークＩ／Ｆ２１８は、制御部２１０（ＭＦＰ１０１）をＬＡＮ１１０に接続する。ネットワークＩ／Ｆ２１８は、ＬＡＮ１１０上またはＷＡＮ１２０上の他の装置との間で各種情報を送受信する。

図３は、サーバ１０２の構成を例示するブロック図である。
ＣＰＵ３１１を含む制御部３１０は、サーバ１０２全体の動作を制御する。ＣＰＵ３１１は、ＲＯＭ３１２やＨＤＤ３１４に記憶された制御プログラムを読み出して各種制御処理を実行する。ＲＯＭ３１２は、各種のプログラムやデータを記憶する。ＲＡＭ３１３は、ＣＰＵ３１１の主メモリ、ワークエリア等の一時記憶領域として用いられる。ＨＤＤ３１４は、各種のプログラムやデータを記憶する。なお、ＨＤＤの代わりに又は併用してＳＳＤ等の他の記憶装置を設けてもよい。

表示部Ｉ／Ｆ３１５は、表示部３１８と制御部３１０とを接続する。キーボードＩ／Ｆ３１６は、キーボード３１９やマウス等のポインティングデバイスと制御部３１０とを接続する。ＣＰＵ３１１は、キーボード３１９等を介したユーザからの指示を認識し、認識した指示に応じて表示部３１８に表示する画面を遷移させる。

ネットワークＩ／Ｆ３１７は、制御部３１０（サーバ１０２）をＷＡＮ１２０に接続する。ネットワークＩ／Ｆ３１７は、ＬＡＮ１１０上またはＷＡＮ１２０上の他の装置との間で各種情報を送受信する。

図４は、本実施例のＭＦＰ１０１におけるソフトウェア構成図である。図４に示す各部は、ＭＦＰ１０１のＨＤＤ２１４に記憶されているプログラム（ソフトウェア）を、ＣＰＵ２１１がＲＡＭ２１３に読み出し、解析、実行することで実現される機能部である。

拡張ソフト管理部４１０は、ＭＦＰ１０１上で拡張ソフトを動作させるためのソフトウェアプラットホームである。図４では、拡張ソフトとして４１１〜４１６の６つの機能プロバイダがＭＦＰ１０１にインストールされている。

機能プロバイダは、拡張ソフトの一種であるが、アプリ（アプリケーション）ではない。アプリは、単体で入力から出力までの一連の完結した処理を備えている。一方、単体の機能プロバイダは、入力なら入力、出力なら出力といった特定の機能に特化したものである。よって、機能プロバイダを用いて入力から出力までの一連の完結した処理を行うためには、複数の機能プロバイダを組み合わせる必要がある。

例えば、「スキャンしてプレビュー表示の後、送信する」という機能をユーザに提供する場合、アプリであれば「スキャン」、「プレビュー」及び「送信」の３つの機能をひとつのアプリで実現する。一方、機能プロバイダの場合、「スキャン機能を実現する機能プロバイダ」、「プレビュー機能を実現する機能プロバイダ」及び「送信機能を実現する機能プロバイダ」の３つの機能プロバイダが必要になる。さらに、それら３つの機能プロバイダを一連の処理として実行するためには、後述するワークフロー処理部４３０とワークフロー定義ファイル４４０が必要になる。

また、アプリは、ＭＦＰ１０１が元々備えている機能（例えばコピー機能やファクス送信機能）を呼び出すためのメニュー画面に、それらの機能と横並びで表示されるようにアプリ自身を登録する。アプリは、メニュー画面からユーザの指示によって呼び出される。一方、機能プロバイダはメニュー画面ではなく、後述する機能プロバイダ管理部４２０に、機能プロバイダ自身を登録する。機能プロバイダは、機能プロバイダ管理部４２０経由でワークフロー処理部４３０の指示によって呼び出される。

さらに、機能プロバイダは、後述する機能プロバイダ管理部４２０が規定するルール（以降、機能プロバイダインタフェース）を満たすようにプログラミングされている。機能プロバイダインタフェースは、ソフトウェア間のやり取りを行う際のルールを決めたソフトウェアインタフェースである。機能プロバイダインタフェースは、機能プロバイダが提供する機能の種類（以降、機能タイプ）ごとに定められている。機能プロバイダは、機能プロバイダインタフェースに基づいてワークフロー処理部４３０から呼び出される。

なお、１つの機能プロバイダは、目的に応じて、複数種類のインタフェースを持つ場合がある。例えば、スキャン機能を実現する機能プロバイダであれば、「スキャン設定画面の表示」の目的のためのインタフェースと、「スキャンジョブの実行」の目的のためのインタフェースといったように、目的別に複数種類のインタフェースを用意することができる。

また、複数種類の機能プロバイダを、ＭＦＰ１０１にインストールすることができる。異なる機能タイプの機能プロバイダを複数種類インストールしてもよいし、同じ機能タイプの機能プロバイダを複数種類インストールしてもよい。同じ機能タイプの機能プロバイダは、同じソフトウェアインタフェースを持つため、拡張ソフトは、同じ機能タイプの機能プロバイダであれば、同じようにソフトウェア間のやり取りを行うことができる。

標準スキャンプロバイダ４１１と簡単スキャンプロバイダ４１２は、ともにスキャン機能を提供する機能プロバイダ（機能タイプ＝スキャン）である。機能タイプが「スキャン」の機能プロバイダを総称してスキャンプロバイダと呼ぶ。スキャンプロバイダは、機能タイプが「スキャン」の機能プロバイダのために定義された機能プロバイダインタフェース（スキャンプロバイダインタフェース）を実現する。
標準スキャンプロバイダ４１１は、一般的なユーザ向けのスキャン設定画面を持つ。一方、簡単スキャンプロバイダ４１２は、ＭＦＰ１０１の操作に不慣れな初心者向けのスキャン設定画面を持つ。

組込ＯＣＲプロバイダ４１３とＷｅｂ ＯＣＲプロバイダ４１４は、ともにＯＣＲ機能を提供する機能プロバイダ（機能タイプ＝ＯＣＲ）である。機能タイプが「ＯＣＲ」の機能プロバイダを総称してＯＣＲプロバイダと呼ぶ。ＯＣＲプロバイダは、機能タイプが「ＯＣＲ」の機能プロバイダのために定義された機能プロバイダインタフェース（ＯＣＲプロバイダインタフェース）を実現する。組込ＯＣＲプロバイダ４１３は、ＭＦＰ１０１上で文字認識処理を行うことでＯＣＲ機能を提供する。一方、Ｗｅｂ ＯＣＲプロバイダ４１４は、外部のＷｅｂサーバ（例えばサーバ１０２）が提供する文字認識処理を呼び出すことでＯＣＲ機能を提供する。

ＦＴＰ送信プロバイダ４１５は、ＦＴＰ送信機能を提供する機能プロバイダ（機能タイプ＝ファイル送信）である。機能タイプが「ファイル送信」の機能プロバイダを総称してファイル送信プロバイダと呼ぶ。ＦＴＰ送信プロバイダは、機能タイプが「ファイル送信」の機能プロバイダのために定義された機能プロバイダインタフェース（ファイル送信プロバイダインタフェース）を実現する。

プレビュープロバイダ４１６は、画像表示機能を提供する機能プロバイダ（機能タイプ＝画像表示）である。機能タイプが「画像表示」の機能プロバイダを総称して画像表示プロバイダと呼ぶ。画像表示プロバイダは、機能タイプが「画像表示」の機能プロバイダのために定義された機能プロバイダインタフェース（画像表示プロバイダインタフェース）を実現する。

各機能プロバイダは、ＭＦＰ１０１に同じ機能タイプを持つ機能プロバイダが他に存在しなくても、自身の機能タイプ用に定義された機能プロバイダインタフェースを実現する。
以上で説明した４１１〜４１６の６つの機能プロバイダは、ほんの一例であり、ＭＦＰ１０１には、拡張ソフトとして様々な機能プロバイダを追加・削除することが可能である。

機能プロバイダ管理部４２０は、ＭＦＰ１０１にインストールされている機能プロバイダを管理するソフトウェアである。機能プロバイダ管理部４２０は、機能プロバイダ登録部４２１、機能プロバイダ設定部４２２、機能プロバイダ検索部４２３、機能プロバイダ情報テーブル４２４、機能プロバイダ設定テーブル４２５、機能プロバイダインタフェース定義４２６を持つ。

機能プロバイダ登録部４２１は、各機能プロバイダからの依頼を受けて、機能プロバイダ情報テーブル４２４に、各機能プロバイダの機能タイプや設定可能な値などの情報を登録する。また、機能プロバイダ設定部４２２は、ユーザからの依頼を受けて、機能プロバイダの優先順位やユーザ毎の使用可否といった機能プロバイダに関する設定を、機能プロバイダ設定テーブル４２５に設定する。なお、機能プロバイダ情報テーブル４２４の詳細は後述する図７に示す。また、機能プロバイダ設定テーブル４２５の詳細は、後述する図９に示す。

機能プロバイダ検索部４２３は、後述するワークフロー処理部４３０から機能プロバイダの検索条件を受け取り、機能プロバイダ情報テーブル４２４と機能プロバイダ設定テーブル４２５の情報を基に条件に一致する機能プロバイダを特定する。機能プロバイダ検索部４２３は、検索結果として機能プロバイダを一つに特定するため、検索条件に一致する機能プロバイダが複数存在した場合は、最も優先順位の高い機能プロバイダを検索結果とする。

機能プロバイダインタフェース定義４２６は、機能プロバイダインタフェースを定義している。なお、機能プロバイダインタフェース定義４２６の詳細は後述する図１３に示す。

ワークフロー処理部４３０は、後述するワークフロー定義ファイル４４０に従って、複数の機能プロバイダを組み合わせて複数の工程を一連の処理として実行する。本発明では、ワークフローとは、複数の機能プロバイダを組み合わせて実現される複数の工程からなる一連の処理を指すものとする。

ワークフロー定義ファイル４４０は、ワークフロー処理部４３０が呼び出す機能プロバイダの検索条件や、呼び出し順序、呼び出した機能プロバイダに適用する設定値など、機能プロバイダの呼び出しに関する情報を定義する。なお、図４ではワークフロー定義ファイルを例として１つ定義しているが、１つに限定するものではなく、ＭＦＰ１０１上に複数のワークフロー定義ファイルが存在してもよい。ワークフロー定義ファイル４４０の詳細は後述する図１０に示す。

図５は、本実施例におけるＭＦＰ１０１上の一連の処理の流れを示す図である。図中の各処理は、ＭＦＰ１０１のＨＤＤ２１４に記憶されているプログラム（ソフトウェア）を、ＣＰＵ２１１がＲＡＭ２１３に読み出し、解析、実行することにより実現される各機能部により実行される。

標準スキャンプロバイダ４１１は、自身の起動時に機能プロバイダ管理部４２０に対して、自身を機能プロバイダとして登録するよう指示する（Ｓ５０１）。この指示には、登録に必要な情報が含まれている。
この登録指示を受け取った機能プロバイダ管理部４２０は、指示に含まれる機能プロバイダの登録情報を機能プロバイダ情報テーブル４２４に格納する（Ｓ５０２）。

機能プロバイダ４１２〜４１６も、標準スキャンプロバイダ４１１と同様に、自身の起動時に機能プロバイダ管理部４２０に対して、自身を機能プロバイダとして登録するよう指示する（Ｓ５０３、Ｓ５０５、Ｓ５０７、Ｓ５０９、Ｓ５１１）。
これらの登録指示を受け取った機能プロバイダ管理部４２０は、指示に含まれる機能プロバイダの登録情報を機能プロバイダ情報テーブル４２４に格納する（Ｓ５０４、Ｓ５０６、Ｓ５０８、Ｓ５１０、Ｓ５１２）。

次に、機能プロバイダ管理部４２０は、ユーザから機能プロバイダの設定指示を受け取る（Ｓ５２０）と、該指示内容を機能プロバイダ設定テーブル４２５に反映して機能プロバイダ設定テーブル４２５を更新する（Ｓ５２１）。

次に、ワークフロー処理部４３０は、ユーザからワークフローの実行指示を受け取る（Ｓ５３０）と、該実行指示に対応するワークフロー定義ファイル４４０を読み込む（Ｓ５３１）。ここでは、ワークフロー定義ファイル４４０に「機能タイプがスキャンの機能プロバイダ」、「機能タイプがＯＣＲの機能プロバイダ」、「ＦＴＰ送信プロバイダ」を順に実行するように定義されているものとする。ワークフロー定義ファイルでは、実行する機能プロバイダを機能タイプで指定することもできるし、機能プロバイダを一意に特定する形で指定することもできる。

ワークフロー処理部４３０は、機能プロバイダ管理部４２０に対して「機能タイプがスキャンの機能プロバイダ」すなわちスキャンプロバイダを検索するよう指示する（Ｓ５３２）。指示にはワークフロー定義ファイル４４０に定義された検索条件が含まれる。検索指示を受け取った機能プロバイダ管理部４２０は、機能プロバイダ情報テーブル４２４と機能プロバイダ設定テーブル４２５の情報を基に、検索条件に一致するスキャンプロバイダを抽出する（Ｓ５３３）。検索条件に一致するスキャンプロバイダが複数存在した場合には、機能プロバイダ管理部４２０は、最も優先順位の高いスキャンプロバイダを検索結果とする。機能プロバイダ管理部４２０は、スキャンプロバイダの検索結果を、ワークフロー処理部４３０に通知する（Ｓ５３４）。

この検索結果を受け取ったワークフロー処理部４３０は、検索結果のスキャンプロバイダに対して、スキャン指示を行う（Ｓ５３５）。ここでワークフロー処理部４３０は、検索結果が標準スキャンプロバイダ４１１であるか、簡単スキャンプロバイダ４１２であるかを識別しない。どちらであってもスキャンプロバイダであることに変わりはなく、ワークフロー処理部４３０は個別の機能プロバイダを識別することなくスキャンプロバイダインタフェースに従ってスキャン指示を出すことができる。
ワークフロー処理部４３０からスキャン指示を受け取ったスキャンプロバイダ（図５では標準スキャンプロバイダ４１１）は、指示に従ってスキャンを実行する（Ｓ５３６）。

次に、ワークフロー処理部４３０は、機能プロバイダ管理部４２０に対して「機能タイプがＯＣＲの機能プロバイダ」すなわちＯＣＲプロバイダを検索するよう指示する（Ｓ５３７）。この指示にはワークフロー定義ファイル４４０に定義された検索条件が含まれる。検索指示を受け取った機能プロバイダ管理部４２０は、機能プロバイダ情報テーブル４２４と機能プロバイダ設定テーブル４２５の情報を基に、検索条件に一致するＯＣＲプロバイダを抽出する（Ｓ５３８）。検索条件に一致するＯＣＲプロバイダが複数存在した場合は、最も優先順位の高いＯＣＲプロバイダを検索結果とする。機能プロバイダ管理部４２０は、ＯＣＲプロバイダの検索結果を、ワークフロー処理部４３０に通知する（Ｓ５３９）。

検索結果を受け取ったワークフロー処理部４３０は、検索結果のＯＣＲプロバイダに対して、ＯＣＲ指示を行う（Ｓ５４０）。
ワークフロー処理部４３０からＯＣＲ指示を受け取ったＯＣＲプロバイダ（図５では組込ＯＣＲプロバイダ４１３）は、指示に従ってＯＣＲ処理を実行する（Ｓ５４１）。

次に、ワークフロー処理部４３０は、機能プロバイダ管理部４２０に対してＦＴＰ送信プロバイダ４１５を検索するよう指示する（Ｓ５４２）。機能プロバイダ管理部４２０は、ＦＴＰ送信プロバイダ４１５を検索結果として、ワークフロー処理部４３０に通知する（Ｓ５４３）。

検索結果を受け取ったワークフロー処理部４３０は、検索結果のＦＴＰ送信プロバイダ４１５に対して、送信指示を行う（Ｓ５４５）。
ワークフロー処理部４３０から送信指示を受け取ったＦＴＰ送信プロバイダ４１５は、指示に従って送信処理を実行する（Ｓ５４６）。

図６は、図５のＳ５０１〜Ｓ５１２における個々の機能プロバイダの起動時の処理を説明するためのフローチャートである。このフローチャートの処理は、ＭＦＰ１０１のＨＤＤ２１４に記憶されているプログラムを、ＣＰＵ２１１がＲＡＭ２１３に読み出し、解析、実行することで実現される。

まず、拡張ソフト管理部４１０が、ＭＦＰ１０１の起動またはユーザの指示といったトリガーをうけて、機能プロバイダを起動させる（Ｓ６０１）。
該起動した機能プロバイダ（例えば、図４の４１１〜４１６）は、自身の機能プロバイダとしての情報（機能タイプや設定可能な値などの情報）を、機能プロバイダ登録部４２１に通知して、自身を機能プロバイダとして登録するよう指示する（Ｓ６０２）。

機能プロバイダ登録部４２１は、機能プロバイダから登録指示を受信する（Ｓ６０３）と、機能プロバイダ情報テーブル４２４に受信した情報を格納し、機能プロバイダ情報テーブル４２４を更新する（Ｓ６０４）。

図７は、機能プロバイダ情報テーブル４２４の一例を示す図である。
図７に示すように、機能プロバイダ情報テーブル４２４は、機能プロバイダを一意に特定する機能プロバイダＩＤ、機能プロバイダの名称、機能タイプ、機能プロバイダインタフェース、機能プロバイダに設定可能な値など、機能プロバイダに関する情報を保持する。

図８は、図５のＳ５２０〜Ｓ５２１の処理を説明するためのフローチャートである。このフローチャートの処理は、ＭＦＰ１０１のＨＤＤ２１４に記憶されているプログラムを、ＣＰＵ２１１がＲＡＭ２１３に読み出し、解析、実行することで実現される。

機能プロバイダ設定部４２２は、ユーザから機能プロバイダの設定指示を受け取る（Ｓ８０１）と、指示内容を機能プロバイダ設定テーブル４２５に反映する（Ｓ８０２）。

図９は、機能プロバイダ設定テーブル４２５の一例を示す図である。なお、機能プロバイダ設定テーブル４２５は、図９（ａ）、図９（ｂ）、図９（ｃ）の３つのテーブルを持つ。

図９（ａ）は、ＭＦＰ１０１を使用する全ユーザに共通に適用される機能プロバイダの設定（共通設定テーブル）である。共通設定テーブルは、機能プロバイダの使用条件となる設定を保持するものであり、機能タイプごとに、優先順位と、使用禁止の機能プロバイダ指定を保持する。なお、優先順位には、優先順位の高い順に機能プロバイダＩＤが記載される。例えば、機能タイプ「ＳＣＡＮ」について、「ＮＯＲＭＡＬ＿ＳＣＡＮ」、「ＥＡＳＹ＿ＳＣＡＮ」の順に優先順位が高くなる設定がされている。なお、使用禁止の欄に、機能プロバイダの指定があった場合には、該指定された機能プロバイダが使用禁止であることを示す。

図９（ｂ）は、ユーザのロールごとに適用される機能プロバイダの設定（ロール設定テーブル）である。ロール設定テーブルは、ロールごとに、機能タイプごとの、優先順位と、使用禁止の機能プロバイダ指定を保持する。例えば、ロール「Ｇｕｅｓｔ Ｕｓｅｒｓ」のユーザに対しては、機能タイプ「ＯＣＲ」について、「ＯＣＲ＿ＷＥＢ」が使用禁止に指定されている。

図９（ｃ）は、ユーザごとに適用される機能プロバイダの設定（ユーザ設定テーブル）である。ユーザ設定テーブルは、ユーザごとに、機能タイプごとの、優先順位と、使用禁止の機能プロバイダ指定を保持する。例えば、ユーザ「ｔａｎａｋａ」に対しては、機能タイプ「ＳＣＡＮ」について、「ＥＡＳＹ＿ＳＣＡＮ」、「ＮＯＲＭＡＬ＿ＳＣＡＮ」の順に優先順位が高くなる設定がされている。

図１３は、本実施例における機能プロバイダインタフェース定義を例示する図である。本実施例では、機能プロバイダインタフェースは、プログラムのソースコード形式で表現されているが、これに限定されるものではなく、他の形式であってもよい。

図１３において、１３０１はスキャンプロバイダインタフェースの定義で、「ｓｈｏｗＳｅｔｔｉｎｇＵＩ」、「ｄｏＳｃａｎ」、「ｄｏＳｃａｎＷｉｔｈＳｅｔｔｉｎｇＵＩ」という３つのインタフェースを定義している。スキャンプロバイダは、１３０１で定義している３つのインタフェースを必ず備えている。

「ｓｈｏｗＳｅｔｔｉｎｇＵＩ」は、スキャン設定画面を表示するためのインタフェースで、Ｐａｒａｍｅｔｅｒを受け取り、結果をｂｏｏｌｅａｎ（真偽値）で返す。ユーザがスキャン設定を確定すると「ｔｒｕｅ（真）」を返し、ユーザがスキャン設定をキャンセルすると「ｆａｌｓｅ（偽）」を返す。Ｐａｒａｍｅｔｅｒは、インタフェースを呼び出す際の設定値で、ワークフロー定義ファイル４４０で定義される。

「ｄｏＳｃａｎ」はスキャン実行のためのインタフェースで、Ｐａｒａｍｅｔｅｒを受け取り、結果をＤｏｃｕｍｅｎｔというデータ形式で返す。「ｄｏＳｃａｎ」は、「ｓｈｏｗＳｅｔｔｉｎｇＵＩ」でユーザが設定した値またはＰａｒａｍｅｔｅｒで指定された設定値でスキャンを実行する。
「ｄｏＳｃａｎＷｉｔｈＳｅｔｔｉｎｇＵＩ」は、スキャン設定画面を表示後、ユーザが設定画面で確定した値でスキャンを実行する。

同様に、１３０２はＯＣＲプロバイダインタフェースの定義、１３０３はファイル送信プロバイダインタフェースの定義、１３０４はプレビュープロバイダインタフェースの定義である。このように、機能プロバイダインタフェース定義では、各機能プロバイダが備えるインタフェース（名称、入力、出力）を定義している。

図１０は、本実施例におけるワークフロー定義ファイルの具体的な記述例を示す図である。本実施例では、ワークフロー定義ファイルは、ＸＭＬ形式のファイルとして表現されているが、ＸＭＬ形式に限定されるものではなく、他の形式のファイルであってもよい。

Ｗｏｒｋｆｌｏｗタグ１０１０は、以下の記述がワークフローの定義であることを示している。
ＦＰ１０２０タグは、Ｗｏｒｋｆｌｏｗタグ１０１０の子要素で、ワークフローで実行する機能プロバイダに関する情報を定義している。ＦＰタグ１０２０のｎｏ属性は、ワークフローにおける機能プロバイダの実行順を定義しており、「ｎｏ＝"１"」は最初に実行する機能プロバイダであることを示している。ＦＰタグ１０２０のｔｙｐｅ属性は、実行する機能プロバイダの機能タイプを定義しており、「ｔｙｐｅ＝"ＳＣＡＮ"」はスキャンプロバイダであることを示している。

Ｃｏｎｄｉｔｉｏｎタグ１０２１は、ＦＰタグ１０２０の子要素で、スキャンプロバイダの検索条件を、子要素であるＲｅｑｕｉｒｅｄタグ１０２２と、Ｏｐｔｉｏｎａｌタグ１０２３で定義している。
Ｒｅｑｕｉｒｅｄタグ１０２２は、検索するスキャンプロバイダの「必須条件」を定義しており、「ＦＩＬＥ＿ＦＯＲＭＡＴ（ファイル形式）」の設定値として「ＰＤＦ」を設定可能なスキャンプロバイダが必須である旨を示している。
Ｏｐｔｉｏｎａｌタグ１０２３は、検索するスキャンプロバイダの「オプション条件」を定義しており、「ＯＲＩＧＩＮＡＬ＿ＴＹＰＥ（原稿種類）」の設定値として「ＴＥＸＴ」を設定可能なスキャンプロバイダを優先的に使用する旨を示している。

ここで「必須条件」と「オプション条件」の違いを説明する。
機能プロバイダの検索処理において、必須条件は、必ず満たすべき条件であり、必須条件を満たす機能プロバイダが存在しない場合、検索結果は「なし」となる。一方、オプション条件は、オプション条件を満たす機能プロバイダを優先的に使用する条件であり、オプション条件を満たす機能プロバイダが存在しない場合、オプション条件は検索条件から除外される。このように、ワークフロー定義ファイル４４０では、ワークフローを構成する各工程を実行する機能プロバイダが備えるべき機能の条件として、必須条件とオプション条件のいずれか又は双方を指定可能である。

Ａｃｔｉｏｎタグ１０２４は、ＦＰタグ１０２０の子要素であり、機能プロバイダの呼び出しについての情報を定義している。Ａｃｔｉｏｎタグのｎｏ属性と、ｍｅｔｈｏｄ属性は、ＦＰタグで定義された機能プロバイダの中での実行順と呼び出すインタフェースを定義している。Ａｃｔｉｏｎタグ１０２４は、スキャンプロバイダの実行において「ｓｈｏｗＳｅｔｔｉｎｇＵＩ」を１番目に呼び出す旨を定義している。
Ｐａｒａｍｅｔｅｒタグ１０２５は、Ａｃｔｉｏｎタグ１０２４の子要素であり、Ａｃｔｉｏｎタグ１０２４で定義されているインタフェース（ｓｈｏｗＳｅｔｔｉｎｇＵＩ）を呼び出す際に渡す設定値を定めている。

Ａｃｔｉｏｎタグ１０２６は、ＦＰタグ１０２０の子要素であり、スキャンプロバイダの実行において「ｄｏＳｃａｎ」を２番目に呼び出す旨を定義している。
Ｏｕｔｐｕｔタグ１０２７は、Ａｃｔｉｏｎタグ１０２６の子要素であり、「ｄｏＳｃａｎ」を実行した結果の出力を定義している。Ｏｕｔｐｕｔタグ１０２７は、ｔｙｐｅ属性で出力形式が「Ｄｏｃｕｍｅｎｔ」である旨を、ｉｄ属性で出力データを一意に特定するＩＤが「ｆｏｏ」である旨を定義している。

ＦＰ１０３０タグは、ｎｏ属性とｔｙｐｅ属性で、２番目に実行する機能プロバイダがＯＣＲプロバイダであることを定義している。Ｒｅｑｕｉｒｅｄタグ１０３１は、ＯＣＲプロバイダの必須条件を定義しており、「ＬＡＮＧ（認識言語）」の設定値として「ＪＡ（日本語）」を設定可能なＯＣＲプロバイダが必須である旨を示している。

Ａｃｔｉｏｎタグ１０３２は、ＦＰタグ１０３０の子要素であり、ＯＣＲプロバイダの実行において「ｄｏＯＣＲ」を１番目に呼び出す旨を定義している。
Ｉｎｐｕｔタグ１０３３は、「ｄｏＳｃａｎ」の入力に関する定義で、「Ｄｏｃｕｍｅｎｔ」形式のデータをＩＤが「ｆｏｏ」のデータから受け取ることを示している。ＩＤが「ｆｏｏ」のデータは、Ｏｕｔｐｕｔタグ１０２７で定義した「ｄｏＳｃａｎ」の出力データである。つまり、ＯＣＲプロバイダは、スキャンプロバイダのスキャンデータをＤｏｃｕｍｅｎｔ形式で受け取るということを定義している。
Ｏｕｔｐｕｔタグ１０３４は、「ｄｏＯＣＲ」の出力に関する定義であり、ｔｙｐｅ属性で出力形式が「Ｓｔｒｉｎｇ（文字列）」である旨と、ｉｄ属性で出力データを一意に特定するＩＤが「ｂａｒ」である旨を定義している。

ＦＰ１０４０タグは、ｎｏ属性とｉｄ属性で、３番目に実行する機能プロバイダがＦＴＰ送信プロバイダであることを定義している。ＦＰタグは機能プロバイダを、ＦＰタグ１０２０、１０３０のようにｔｙｐｅ属性を使って機能タイプで指定することもできるし、ＦＰタグ１０４０のようにｉｄ属性を使って一意に指定することもできる。
Ｉｎｐｕｔタグ１０４１は、ＦＴＰ送信プロバイダの「ｄｏＳｅｎｄ」呼び出しの入力に関する定義で、「Ｄｏｃｕｍｅｎｔ」をＩＤが「ｆｏｏ」のデータ、つまり「ｄｏＳｃａｎ」の出力から受け取ることを示している。
Ｉｎｐｕｔタグ１０４２も、同様にＦＴＰ送信プロバイダの「ｄｏＳｃａｎ」呼び出しの入力に関する定義で、「Ｓｔｒｉｎｇ」をＩＤが「ｂａｒ」のデータ、つまり「ｄｏＯＣＲ」の出力から受け取ることを示している。

図１１は、図５のＳ５３０〜Ｓ５４６の処理を説明するためのフローチャートである。このフローチャートの処理は、ＭＦＰ１０１のＨＤＤ２１４に記憶されているプログラムを、ＣＰＵ２１１がＲＡＭ２１３に読み出し、解析、実行することで実現される。

まず、ワークフロー処理部４３０は、ユーザからワークフローの実行指示を受け取る（Ｓ１１０１）と、実行指示に対応するワークフロー定義ファイル４４０を読み込む（Ｓ１１０２）。

次に、ワークフロー処理部４３０は、ワークフロー定義ファイル４４０からＦＰタグで定義された機能プロバイダの定義を実行順に１つ取り出す（Ｓ１１０３）。ここで、実行順とは、ＦＰタグのｎｏ要素に定義された数字の若い順を意味する。

Ｓ１１０４において、ワークフロー処理部４３０は、次に実行すべき機能プロバイダの定義が存在するか否かを判定する。そして、次に実行すべき機能プロバイダの定義が存在すると判定した場合（Ｓ１１０４でＹＥＳの場合）、ワークフロー処理部４３０は、Ｓ１１０５へ処理を進める。

Ｓ１１０５では、ワークフロー処理部４３０は、ＦＰタグおよびＦＰタグの子要素であるＣｏｎｄｉｔｉｏｎタグから機能プロバイダの検索条件を取得し、機能プロバイダ検索部４２３に機能プロバイダの検索を指示する。機能プロバイダ検索部４２３が行う機能プロバイダの検索処理は、後述する図１２のフローチャートで詳細に説明する。

ワークフロー処理部４３０は、機能プロバイダ検索部４２３から検索結果を受け取ると、検索結果として検索条件に一致する機能プロバイダが取得できたかどうかを判定する（Ｓ１１０６）。そして、検索結果として検索条件に一致する機能プロバイダが取得できなかったと判定した場合（Ｓ１１０６でＮＯの場合）、ワークフロー処理部４３０は、エラーを通知して（Ｓ１１３１）、ワークフローの実行処理を終了する。

一方、検索結果として検索条件に一致する機能プロバイダが取得できたと判定した場合（Ｓ１１０６でＹＥＳの場合）、ワークフロー処理部４３０は、Ｓ１１０７に処理を進める。

Ｓ１１０７では、ワークフロー処理部４３０は、ワークフロー定義ファイル４４０から処理対象となっているＦＰタグの子要素であるＡｃｔｉｏｎタグを実行順に１つ取り出す（Ｓ１１０７）。ここで実行順とは、Ａｃｔｉｏｎタグのｎｏ要素に定義された数字の若い順を意味する。

次に、Ｓ１１０８において、ワークフロー処理部４３０は、次に処理すべきＡｃｔｉｏｎタグが存在するか否かを判定する。そして、次に処理すべきＡｃｔｉｏｎタグが存在すると判定した場合（Ｓ１１０８でＹＥＳの場合）、ワークフロー処理部４３０は、Ｓ１１０９へ処理を進める。

Ｓ１１０９では、ワークフロー処理部４３０は、Ａｃｔｉｏｎタグの定義に従って、上記Ｓ１１０５の検索結果として取得した機能プロバイダを呼び出す。その際、ワークフロー処理部４３０は、Ａｃｔｉｏｎタグの子要素としてＰａｒａｍｅｔｅｒタグまたはＩｎｐｕｔタグが定義されていれば、その定義に従って、機能プロバイダに入力を与える。例えば、Ｉｎｐｕｔタグ１０３３はＯＣＲプロバイダの「ｄｏＯＣＲ」呼び出しの入力に関する定義で、「Ｄｏｃｕｍｅｎｔ」をＩＤが「ｆｏｏ」のデータから受け取ることを示している。ＩＤが「ｆｏｏ」のデータは、Ｏｕｔｐｕｔタグ１０２７で定義したスキャンプロバイダの「ｄｏＳｃａｎ」の出力データである。ゆえに、ワークフロー処理部４３０は、自身が保持している「ｄｏＳｃａｎ」の出力データを、「ｄｏＯＣＲ」の呼び出し時に入力データとして与える。

ワークフロー処理部４３０から呼び出された機能プロバイダは、指示に従って処理を実行する（Ｓ１１２１）。
ワークフロー処理部４３０は、呼び出した機能プロバイダの実行完了を待ち受ける（Ｓ１１１０）。そして、機能プロバイダの実行が完了したら、ワークフロー処理部４３０は、機能プロバイダの出力を、別の機能プロバイダの入力として使用できるようＨＤＤ２１４またはＲＡＭ２１３に保存する（Ｓ１１１１）。例えば、Ｏｕｔｐｕｔタグ１０２７はスキャンプロバイダの「ｄｏＳｃａｎ」呼び出しの出力に関する定義で、「ｄｏＳｃａｎ」の出力である「Ｄｏｃｕｍｅｎｔ」データを、ＩＤを「ｆｏｏ」として保存する。機能プロバイダの出力を保存したら、ワークフロー処理部４３０は、次に処理すべきＡｃｔｉｏｎタグを取得するために、Ｓ１１０７へ処理を移行する。

また、上記S１１０８において、次に処理すべきＡｃｔｉｏｎタグが存在しないと判定した場合（Ｓ１１０８でＮＯの場合）、ワークフロー処理部４３０は、最後のＡｃｔｉｏｎタグまで取得し終えたと判断し、次の機能プロバイダの定義を取得するために、Ｓ１１０３へ移行する。

また、上記S１１０４において、次に実行すべき機能プロバイダの定義が存在しないと判定した場合（Ｓ１１０４でＮＯの場合）、ワークフロー処理部４３０は、最後の機能プロバイダまで実行し終えたと判断し、ワークフローの実行を終了する。

次に、図１２のフローチャートを用いて機能プロバイダ検索部４２３が行う機能プロバイダの検索処理の説明を行う。
図１２は、図１１のＳ１１０５から呼び出される処理を例示するフローチャートであり、図５のＳ５３３、Ｓ５３８、Ｓ５４３で行われる処理に対応する。このフローチャートの処理は、ＭＦＰ１０１のＨＤＤ２１４に記憶されているプログラムを、ＣＰＵ２１１がＲＡＭ２１３に読み出し、解析、実行することで実現される。

まず、機能プロバイダ検索部４２３は、ワークフロー処理部４３０から、機能プロバイダの検索指示を受け取る（Ｓ１２０１）。この検索指示には、ＦＰタグおよびＦＰタグの子要素であるＣｏｎｄｉｔｉｏｎタグに定義された機能プロバイダの検索条件が含まれる。

次に、機能プロバイダ検索部４２３は、ＦＰタグの属性として定義された機能プロバイダの指定方法をチェックする（Ｓ１２０２）。そして、機能プロバイダがＩＤで指定されていると判定した場合（Ｓ１２０２で「ＩＤで指定」の場合）、機能プロバイダ検索部４２３は、Ｓ１２３１へ処理を進める。

Ｓ１２３１では、機能プロバイダ検索部４２３は、機能プロバイダ情報テーブル４２４から指定されたＩＤをもつ（すなわち、「機能プロバイダＩＤ」列に指定されたＩＤが定義された）機能プロバイダを抽出し、検索結果候補とする。
次に、Ｓ１２３２において、機能プロバイダ検索部４２３は、抽出の結果をチェックする。この場合、機能プロバイダを一意に特定するＩＤでの指定であるため、検索結果候補は１件または０件となる。

そして、機能プロバイダ検索部４２３は、検索結果候補が存在しないと判定した場合（Ｓ１２３２でＮＯの場合）、検索条件に一致する機能プロバイダはない、という検索結果をワークフロー処理部４３０に返して（Ｓ１２５１）、本フローチャートの処理を終了する。

一方、機能プロバイダ検索部４２３は、検索結果候補が存在すると判定した場合（Ｓ１２３２でＹＥＳの場合）、Ｓ１２０５へ処理を進める。

また、上記Ｓ１２０２において、機能プロバイダが機能タイプで指定されていると判定した場合（Ｓ１２０２で「機能タイプで指定」の場合）、機能プロバイダ検索部４２３は、Ｓ１２０３へ処理を進める。

Ｓ１２０３では、機能プロバイダ検索部４２３は、機能プロバイダ情報テーブル４２４から指定された機能タイプをもつ（すなわち、「機能タイプ」列に指定された機能タイプが定義された）機能プロバイダを抽出し、検索結果候補とする。

Ｓ１２０４において、機能プロバイダ検索部４２３は、上記Ｓ１２０３の抽出の結果をチェックする。なお、機能タイプでの指定であるため、同じ機能タイプを持つ機能プロバイダがＭＦＰ１０１に複数存在する場合、抽出される機能プロバイダも複数件になる。例えば、機能タイプを「ＳＣＡＮ」と指定した場合、検索結果候補は、機能プロバイダ情報テーブル４２４に機能タイプが「ＳＣＡＮ」と定義されている標準スキャンプロバイダ４１１と簡単スキャンプロバイダ４１２の２件となる。

そして、機能プロバイダ検索部４２３は、検索結果候補が存在しないと判定した場合（Ｓ１２０４でＮＯの場合）、検索結果候補を抽出できなかったと判断し、検索条件に一致する機能プロバイダはない、という検索結果をワークフロー処理部４３０に返して（Ｓ１２５１）、本フローチャートの処理を終了する。

一方、機能プロバイダ検索部４２３は、検索結果候補が存在すると判定した場合（Ｓ１２０４でＹＥＳの場合）、Ｓ１２０５へ処理を進める。

Ｓ１２０５では、機能プロバイダ検索部４２３は、検索条件として必須条件が指定されているかをチェックする。

そして、機能プロバイダ検索部４２３は、必須条件の指定がないと判定した場合（Ｓ１２０５でＮＯの場合）、Ｓ１２０８へ処理を進める。
一方、機能プロバイダ検索部４２３は、必須条件の指定があると判定した場合（Ｓ１２０５でＹＥＳの場合）、１２０６へ処理を進める。

Ｓ１２０６において、機能プロバイダ検索部４２３は、検索結果候補から必須条件を満たす機能プロバイダを絞り込んだ結果を新たな検索結果候補とする。必須条件を満たすかどうかは、機能プロバイダ情報テーブル４２４の「設定可能な値」列に、必須条件に指定された値が存在するかどうかで判別する。

次に、Ｓ１２０７において、機能プロバイダ検索部４２３は、絞り込んだ結果、検索結果候補が残っているかをチェックする。そして、機能プロバイダ検索部４２３は、検索結果候補が残っていないと判定した場合（Ｓ１２０７でＮＯの場合）、検索条件に一致する機能プロバイダはない、という検索結果をワークフロー処理部４３０に返して（Ｓ１２５１）、本フローチャートの処理を終了する。

一方、機能プロバイダ検索部４２３は、検索結果候補が残っていると判定した場合（Ｓ１２０７でＹＥＳの場合）、Ｓ１２０８へ処理を進める。

Ｓ１２０８では、機能プロバイダ検索部４２３は、検索条件としてオプション条件が指定されているかをチェックする。そして、オプション条件の指定がないと判定した場合（Ｓ１２０８でＮＯの場合）、機能プロバイダ検索部４２３は、Ｓ１２１２へ処理を進める。
一方、機能プロバイダ検索部４２３は、オプション条件の指定があると判定した場合（Ｓ１２０８でＹＥＳの場合）、Ｓ１２０９へ処理を進める。

Ｓ１２０９では、機能プロバイダ検索部４２３は、検索結果候補からオプション条件を満たす機能プロバイダを絞り込んだ結果を新たな検索結果候補とする。オプション条件を満たすかどうかは、機能プロバイダ情報テーブル４２４の「設定可能な値」列に、オプション条件に指定された値が存在するかどうかで判別する。

次に、Ｓ１２１０において、機能プロバイダ検索部４２３は、絞り込んだ結果、検索結果候補が残っているかをチェックする。そして、機能プロバイダ検索部４２３は、検索結果候補が残っていると判定した場合（Ｓ１２１０でＹＥＳの場合）、Ｓ１２１２へ処理を進める。

一方、検索結果候補が残っていないと判定した場合（Ｓ１２１０でＮＯの場合）、機能プロバイダ検索部４２３は、Ｓ１２１１に処理を進める。
Ｓ１２１１では、機能プロバイダ検索部４２３は、上記Ｓ１２０９の絞り込み結果を破棄し、検索結果候補を、上記Ｓ１２０９を処理する直前の内容に戻す（Ｓ１２１１）。つまり、オプション条件を絞り込み条件として使用しないということである。そして、Ｓ１２１２に処理を進める。

Ｓ１２１２では、機能プロバイダ検索部４２３は、検索結果候補から機能プロバイダ設定テーブル４２５の共通設定テーブルで使用禁止となっている機能プロバイダを除外する。

次に、Ｓ１２１３において、機能プロバイダ検索部４２３は、上記Ｓ１２１２の除外の結果、検索結果候補が残っているかをチェックする。そして、機能プロバイダ検索部４２３は、検索結果候補が残っていないと判定した場合（Ｓ１２１３でＮＯの場合）、検索条件に一致する機能プロバイダはない、という検索結果をワークフロー処理部４３０に返して（Ｓ１２５１）、本フローチャートの処理を終了する。

一方、検索結果候補が残っていると判定した場合（Ｓ１２１３でＹＥＳの場合）、機能プロバイダ検索部４２３は、Ｓ１２１４へ処理を進める。
Ｓ１２１４で、機能プロバイダ検索部４２３は、機能プロバイダ設定テーブル４２５の共通設定テーブルに設定されている機能タイプごとの優先順位に従って、検索結果候補に優先順位を付ける。

次に、機能プロバイダ検索部４２３は、ワークフローの実行を指示したユーザの属するロールに対する設定が、機能プロバイダ設定テーブル４２５のロール設定テーブルに存在するかをチェックする（Ｓ１２１５）。そして、ロールの設定がロール設定テーブルに存在しないと判定した場合（Ｓ１２１５でＮＯの場合）、機能プロバイダ検索部４２３は、Ｓ１２１９へ処理を進める。

一方、機能プロバイダ検索部４２３は、ロールの設定がロール設定テーブルに存在すると判定した場合（Ｓ１２１５でＹＥＳの場合）、Ｓ１２１６へ処理を進める。
Ｓ１２１６では、機能プロバイダ検索部４２３は、検索結果候補から機能プロバイダ設定テーブル４２５のロール設定テーブルで使用禁止となっている機能プロバイダを除外する。例えば、図９（ｂ）では「Ｇｕｅｓｔ Ｕｓｅｒｓ」ロールは「ＯＣＲ＿ＷＥＢ」が使用禁止に設定されているため、「Ｇｕｅｓｔ Ｕｓｅｒｓ」ロールに属するユーザの場合、ＯＣＲプロバイダの検索結果からＷｅｂ ＯＣＲプロバイダ４１４が除外される。すなわち、「Ｇｕｅｓｔ Ｕｓｅｒｓ」ロールに属するユーザは、ワークフローの実行において、Ｗｅｂ ＯＣＲプロバイダ４１４が使用できないということになる。

次に、Ｓ１２１７において、機能プロバイダ検索部４２３は、上記Ｓ１２１６での除外の結果、検索結果候補が残っているかをチェックする。そして、検索結果候補が残っていないと判定した場合（Ｓ１２１７でＮＯの場合）、機能プロバイダ検索部４２３は、検索条件に一致する機能プロバイダはない、という検索結果をワークフロー処理部４３０に返して（Ｓ１２５１）、本フローチャートの処理を終了する。

一方、機能プロバイダ検索部４２３は、検索結果候補が残っていると判定した場合（Ｓ１２１７でＹＥＳの場合）、Ｓ１２１８へ処理を進める。
Ｓ１２１８では、機能プロバイダ検索部４２３は、機能プロバイダ設定テーブル４２５のロール設定テーブルに設定されている機能タイプごとの優先順位に従って、上記Ｓ１２１４で付けられた検索結果候補の優先順位を更新する。

次に、機能プロバイダ検索部４２３は、ワークフローの実行を指示したユーザに対する設定が、機能プロバイダ設定テーブル４２５のユーザ設定テーブルに存在するかをチェックする（Ｓ１２１９）。そして、ユーザの設定がユーザ設定テーブルに存在しないと判定した場合（Ｓ１２１９でＮＯの場合）、機能プロバイダ検索部４２３は、Ｓ１２２３へ処理を進める。

一方、機能プロバイダ検索部４２３は、ユーザの設定がユーザ設定テーブルに存在すると判定した場合（Ｓ１２１９でＹＥＳの場合）、Ｓ１２２０へ処理を進める。
Ｓ１２２０では、機能プロバイダ検索部４２３は、検索結果候補から機能プロバイダ設定テーブル４２５のユーザ設定テーブルで使用禁止となっている機能プロバイダを除外する。

次に、Ｓ１２２１において、機能プロバイダ検索部４２３は、上記Ｓ１２２０での除外の結果、検索結果候補が残っているかをチェックする。そして、検索結果候補が残っていない場合と判定した場合（Ｓ１２２１でＮＯの場合）、機能プロバイダ検索部４２３は、検索条件に一致する機能プロバイダはない、という検索結果をワークフロー処理部４３０に返して（Ｓ１２５１）、本フローチャートの処理を終了する。

一方、機能プロバイダ検索部４２３は、検索結果候補が残っていると判定した場合（Ｓ１２２１でＹＥＳの場合）、Ｓ１２２２へ処理を進める。

Ｓ１２２２では、機能プロバイダ検索部４２３は、機能プロバイダ設定テーブル４２５のユーザ設定テーブルに設定されている機能タイプごとの優先順位に従って、検索結果候補の優先順位を更新する。例えば、図９（ａ）の例では、機能タイプ「ＳＣＡＮ」の優先順位は「ＮＯＲＭＡＬ＿ＳＣＡＮ，ＥＡＳＹ＿ＳＣＡＮ」と設定されているが、図９（ｃ）のユーザ「ｔａｎａｋａ」では「ＥＡＳＹ＿ＳＣＡＮ，ＮＯＲＭＡＬ＿ＳＣＡＮ」となっている。また、図９（ｂ）のロール設定テーブルでは機能タイプ「ＳＣＡＮ」の優先順位は設定されていない。そのため、ロール設定テーブルおよびユーザ設定テーブルに「ＳＣＡＮ」の優先順位が設定されていないユーザの場合、優先順位が「標準スキャンプロバイダ４１１、簡単スキャンプロバイダ４１２」の順になる。一方、ユーザ「ｔａｎａｋａ」の場合、優先順位は「簡単スキャンプロバイダ４１２、標準スキャンプロバイダ４１１」の順になる。そして、Ｓ１２２３に処理を進める。

Ｓ１２２３では、機能プロバイダ検索部４２３は、検索結果候補のうち、最も優先順位が高い機能プロバイダを、検索結果としてワークフロー処理部４３０に返して、本フローチャートの処理を終了する。

以上の実施例で説明した構成により、複数の機能プロバイダを組み合わせて複数の工程からなる一連の処理として実行するための機能、および、一連の処理のなかで使用する機能プロバイダを実行時に動的に決定するための機能を提供することができる。このような構成により、拡張プログラムとしての機能プロバイダを用いた拡張機能の柔軟な運用が可能になる。

例えば、「スキャンしてＯＣＲを実行後、送信する」という機能を実現するにあたって、使用するＯＣＲエンジンを切り替えたいというケースがある。ＭＦＰ１０１上のＯＣＲエンジンを利用していたが、より文字認識性能の良いＯＣＲエンジンに切り替えたい、といった要求が発生したと仮定する。ここでは、外部のＷｅｂサーバが提供するＯＣＲ機能を１ヶ月間お試し利用して、結果が良ければ継続利用、結果が悪ければＭＦＰ１０１上のＯＣＲ機能に戻すか、または、さらに別のＯＣＲ機能を試す、という措置を例に説明を行う。

アプリの場合、ＯＣＲエンジンを外部Ｗｅｂサーバのものを使用するように切り替えるためには、アプリのプログラムを作り直す必要がある。さらに、１ヶ月後のお試し利用の後、ＯＣＲ機能をＭＦＰ１０１のものに戻す場合は、お試し利用の前に使っていたアプリに戻す必要がある。もしくは、アプリのプログラムを作り直した際に、ＯＣＲエンジンを切り替えるための、スイッチを追加しておく必要がある。また、別のＯＣＲ機能を試すのであれば、さらにアプリのプログラムを修正する必要があり、手間であった。

また、本発明を適用しない一般的なワークフロー処理システムの場合、呼び出す処理はワークフロー定義ファイルでのみコントロールしている。そのため、ＯＣＲエンジンを使い分けるためには、ワークフロー処理プログラムを外部ＷｅｂサーバのＯＣＲ呼び出しに対応するように改修をしたうえで、複数のワークフロー定義ファイルを用意する必要がある。もともと「スキャンしてＭＦＰ１０１上のＯＣＲを実行後、送信する」というワークフロー定義ファイルが存在しているところに、「スキャンして外部ＷｅｂサーバのＯＣＲを実行後、送信する」というワークフロー定義ファイルを別途作成する。そのうえで、お試し利用する１ヶ月間と、その後の期間で使用するワークフロー定義ファイルを変更する必要があり、非常に手間であった。なお、ＯＣＲエンジンを切り替える複雑な定義ファイルを作成することも考えられるが、このような複雑な定義ファイルをエンドユーザ側で作成するのは非常に困難であった。

一方、本発明のワークフロー処理システムであれば、容易にＯＣＲエンジンの切り替えが可能になる。もともとワークフロー定義ファイルには処理内容として「スキャンプロバイダの実行」、「ＯＣＲプロバイダの実行」、「送信プロバイダの実行」のように機能タイプで処理が定義されている。ＯＣＲエンジンを切り替える場合、新しいＯＣＲエンジンに対応するＯＣＲプロバイダをＭＦＰ１０１に追加する。その後、機能プロバイダ設定テーブル４２５の共通設定テーブルで機能タイプがＯＣＲの優先順位を変更する。その場合、既存のＯＣＲプロバイダ、ワークフロー処理部４３０、ワークフロー定義ファイルは全く変更する必要はない。お試し期間後、ＭＦＰ１０１上のＯＣＲを使うように戻したければ、ＯＣＲの優先順位を変更するだけで元に戻すことができる。

次に、別の例として、「スキャンしてＯＣＲを実行後、送信する」という機能を実現するにあたって、ユーザによって使用するスキャン設定画面を切り替えたいというケースがある。例えば、ＭＦＰ１０１をほとんど使ったことのない初心者には簡易なスキャン設定画面を表示して、一般的なユーザには標準的なスキャン設定画面を表示したいという要求が発生したと仮定する。

アプリの場合、スキャン設定画面以外の機能がまったく同じであっても、簡易なスキャン設定画面を使用するアプリと、標準的なスキャン設定画面を使用するアプリの２つのアプリが必要になる。さらに、２つのアプリを作った場合、ユーザによってどちらのアプリを使用するかの使い分けが必要になり、手間であった。

また、本発明を適用しない一般的なワークフロー処理システムの場合、ユーザによって使用するスキャン設定画面を変えるためには、複数のワークフロー定義ファイルが必要になる。必要になるのは、簡易なスキャン設定画面を使用するワークフロー定義ファイルと、標準的なスキャン設定画面を使用するワークフロー定義ファイルの２つである。さらに、２つのワークフロー定義ファイルを作った場合、ユーザによってどちらのワークフロー定義ファイルを使用するかの使い分けが必要になり、手間であった。また、使用するスキャン設定画面を切り替える複雑な定義ファイルをエンドユーザ側で作成するのは非常に困難であった。

一方、本発明のワークフロー処理システムであれば、容易にユーザによって使用するスキャン設定画面の切り替えが可能になる。もともとワークフロー定義ファイルには処理内容として「スキャンプロバイダの実行」、「ＯＣＲプロバイダの実行」、「送信プロバイダの実行」のように機能タイプで処理が定義されている。スキャン設定画面を切り替えたいユーザは、機能プロバイダ設定テーブル４２５のユーザ設定テーブルの機能タイプがＳＣＡＮの優先順位を変更する。ユーザ設定テーブルにＳＣＡＮの優先順位が設定されていないユーザは、共通設定テーブルに定義されたＳＣＡＮの優先順位が使用される。

このように、ワークフロー定義ファイルにおいて一連の処理を機能プロバイダの機能タイプで指定し、実行時に機能プロバイダ管理部４２０によって使用する機能プロバイダを動的に決定する構成を設けることにより、拡張機能の柔軟な運用が可能になる。

なお、上記実施例では、本発明の情報処理装置としてＭＦＰを用いて説明したが、本発明を適用可能な装置はＭＦＰのような装置に限定されるものではなく、他の情報処理装置であってもよい。機能の種類ごとに定められたインタフェースを持つ拡張プログラムである機能プロバイダを追加可能であり、複数の機能プロバイダから提供される機能を組み合わせたワークフローを実行可能な装置であれば、本発明を適用可能である。例えば、テレビジョン等の家電や、カーナビゲーション装置などであっても、本発明を適用可能である。

なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されることは言うまでもない。
以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様をとることが可能である。具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
また、上記各実施例を組み合わせた構成も全て本発明に含まれるものである。

（その他の実施例）
本発明は、上述の実施例の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。
本発明は上記実施例に限定されるものではなく、本発明の趣旨に基づき種々の変形（各実施例の有機的な組合せを含む）が可能であり、それらを本発明の範囲から除外するものではない。即ち、上述した各実施例及びその変形例を組み合わせた構成も全て本発明に含まれるものである。

１０１ ＭＦＰ
４１０ 拡張ソフト管理部
４２０ 機能プロバイダ管理部
４３０ ワークフロー処理部
４４０ ワークフロー定義ファイル

Claims (15)

1. 画像形成装置であって、
   複数のプログラムをインストールするインストール手段と、
   前記複数のインストールされたプログラムのそれぞれについて、プログラムを一意に特定する識別情報とプログラムの機能タイプを示す機能タイプ情報とを含む情報を登録する登録手段と、
   複数の工程からなる一連の処理を定義するワークフロー定義ファイルに従って複数のプログラムを組み合わせて一連の処理を実行するワークフローの実行指示を受け付ける受付手段と、
   前記複数の工程を含む処理手順を定義し、前記工程ごとに、プログラムの識別情報またはプログラムの機能タイプのいずれかで指定されている、前記実行指示に対応するワークフロー定義ファイルを取得する取得手段と、
   前記ワークフロー定義ファイルにおいて、前記工程ごとに、プログラムの指定が、プログラムの識別情報と、プログラムの機能タイプのどちらでなされているかの判定をする判定手段と、
   前記判定において、プログラムの指定が、プログラムの識別情報で指定されていると判定された場合、前記登録されている情報に基づいて、前記インストールされている複数のプログラムから、指定されている識別情報のプログラムを検索し、前記判定において、プログラムの指定が、プログラムの機能タイプで指定されていると判定された場合、前記登録されている情報に基づいて、前記インストールされている複数のプログラムから、指定されている機能タイプのプログラムを検索する検索手段と、
   前記ワークフロー定義ファイルにおける複数の工程について、前記工程ごとに、前記検索の結果に基づいて決定したプログラムを順次実行する実行手段と、
   を有することを特徴とする画像形成装置。
2. 前記取得手段で取得されるワークフロー定義ファイルにおいて、プログラムの指定がプログラムの機能タイプで指定されている工程においては、プログラムの機能の条件がさらに指定されている
   ことを特徴とする請求項１に記載の画像形成装置。
3. 前記プログラムの機能の条件は、必須条件であるか、オプション条件であるかの情報をさらに含む
   ことを特徴とする請求項２に記載の画像形成装置。
4. 前記検索手段は、前記登録されている情報と前記ワークフロー定義ファイルの前記必須条件であるプログラムの機能の条件に基づいて、前記インストールされている複数のプログラムから、指定されている機能タイプのプログラムを検索し、検索の結果、前記指定されている機能タイプのプログラムが存在する場合に、前記登録されている情報と前記ワークフロー定義ファイルの前記オプション条件であるプログラムの機能の条件に基づいて、前記検索した結果を絞り込む
   ことを特徴とする請求項３に記載の画像形成装置。
5. 前記登録手段は、前記工程を実行するプログラムの能力を示す能力情報をさらに登録し、
   前記処理手順が前記実行手段により実行される場合に、前記検索手段は、前記登録されたプログラムの能力情報にしたがって指定された機能の条件について、前記処理手順の複数の工程ごとに、前記機能タイプにより指定されたプログラムを動的に決定する
   ことを特徴とする請求項２乃至４の何れか１項に記載の画像形成装置。
6. 前記工程を実行するプログラムの優先順位を機能タイプごとに設定する設定手段をさらに有し、
   前記処理手順が前記実行手段により実行される場合に、前記検索手段は、前記設定手段により設定された前記工程を実行するプログラムの前記優先順位にしたがって、前記処理手順の複数の工程ごとに、前記機能タイプにより指定されたプログラムを動的に決定する
   ことを特徴とする請求項１乃至５の何れか１項に記載の画像形成装置。
7. 前記工程を実行するプログラムは、拡張プログラムである
   ことを特徴とする請求項１乃至６の何れか１項に記載の画像形成装置。
8. 画像形成装置の制御方法を実行させるためのプログラムを記憶したコンピュータで読み取り可能な記憶媒体であって、前記制御方法は、
   複数のプログラムをインストールするインストール・ステップと、
   前記複数のインストールされたプログラムのそれぞれについて、プログラムを一意に特定する識別情報とプログラムの機能タイプを示す機能タイプ情報とを含む情報を登録する登録ステップと、
   複数の工程からなる一連の処理を定義するワークフロー定義ファイルに従って複数のプログラムを組み合わせて一連の処理を実行するワークフローの実行指示を受け付ける受付ステップと、
   前記複数の工程を含む処理手順を定義し、前記工程ごとに、プログラムの識別情報またはプログラムの機能タイプのいずれかで指定されている、前記実行指示に対応するワークフロー定義ファイルを取得する取得ステップと、
   前記ワークフロー定義ファイルにおいて、前記工程ごとに、プログラムの指定が、プログラムの識別情報と、プログラムの機能タイプのどちらでなされているかの判定をする判定ステップと、
   前記判定において、プログラムの指定が、プログラムの識別情報で指定されていると判定された場合、前記登録されている情報に基づいて、前記インストールされている複数のプログラムから、指定されている識別情報のプログラムを検索し、前記判定において、プログラムの指定が、プログラムの機能タイプで指定されていると判定された場合、前記登録されている情報に基づいて、前記インストールされている複数のプログラムから、指定されている機能タイプのプログラムを検索する検索ステップと、
   前記ワークフロー定義ファイルにおける複数の工程について、前記工程ごとに、前記検索の結果に基づいて決定したプログラムを順次実行する実行ステップと、
   を有することを特徴とする記憶媒体。
9. 前記取得ステップで取得されるワークフロー定義ファイルにおいて、プログラムの指定がプログラムの機能タイプで指定されている工程においては、プログラムの機能の条件がさらに指定されている
   ことを特徴とする請求項８に記載の記憶媒体。
10. 前記プログラムの機能の条件は、必須条件であるか、オプション条件であるかの情報をさらに含む
    ことを特徴とする請求項９に記載の記憶媒体。
11. 前記検索ステップで、前記登録されている情報と前記ワークフロー定義ファイルの前記必須条件であるプログラムの機能の条件に基づいて、前記インストールされている複数のプログラムから、指定されている機能タイプのプログラムを検索し、検索の結果、前記指定されている機能タイプのプログラムが存在する場合に、前記登録されている情報と前記ワークフロー定義ファイルの前記オプション条件であるプログラムの機能の条件に基づいて、前記検索した結果を絞り込む
    ことを特徴とする請求項１０に記載の記憶媒体。
12. 前記登録ステップで、前記工程を実行するプログラムの能力を示す能力情報をさらに登録し、
    前記処理手順が前記実行ステップで実行される場合に、前記検索ステップで、前記登録されたプログラムの能力情報にしたがって指定された機能の条件について、前記処理手順の複数の工程ごとに、前記機能タイプにより指定されたプログラムを動的に決定する
    ことを特徴とする請求項９乃至１１の何れか１項に記載の記憶媒体。
13. 前記工程を実行するプログラムの優先順位を機能タイプごとに設定する設定ステップをさらに有し、
    前記処理手順が前記実行ステップで実行される場合に、前記検索ステップで、前記設定ステップで設定された前記工程を実行するプログラムの前記優先順位にしたがって、前記処理手順の複数の工程ごとに、前記機能タイプにより指定されたプログラムを動的に決定する
    ことを特徴とする請求項８乃至１２の何れか１項に記載の記憶媒体。
14. 前記工程を実行するプログラムは、拡張プログラムである
    ことを特徴とする請求項８乃至１３の何れか１項に記載の記憶媒体。
15. 画像形成装置の制御方法であって、
    複数のプログラムをインストールするインストール・ステップと、
    前記複数のインストールされたプログラムのそれぞれについて、プログラムを一意に特定する識別情報とプログラムの機能タイプを示す機能タイプ情報とを含む情報を登録する登録ステップと、
    複数の工程からなる一連の処理を定義するワークフロー定義ファイルに従って複数のプログラムを組み合わせて一連の処理を実行するワークフローの実行指示を受け付ける受付ステップと、
    前記複数の工程を含む処理手順を定義し、前記工程ごとに、プログラムの識別情報またはプログラムの機能タイプのいずれかで指定されている、前記実行指示に対応するワークフロー定義ファイルを取得する取得ステップと、
    前記ワークフロー定義ファイルにおいて、前記工程ごとに、プログラムの指定が、プログラムの識別情報と、プログラムの機能タイプのどちらでなされているかの判定をする判定ステップと、
    前記判定において、プログラムの指定が、プログラムの識別情報で指定されていると判定された場合、前記登録されている情報に基づいて、前記インストールされている複数のプログラムから、指定されている識別情報のプログラムを検索し、前記判定において、プログラムの指定が、プログラムの機能タイプで指定されていると判定された場合、前記登録されている情報に基づいて、前記インストールされている複数のプログラムから、指定されている機能タイプのプログラムを検索する検索ステップと、
    前記ワークフロー定義ファイルにおける複数の工程について、前記工程ごとに、前記検索の結果に基づいて決定したプログラムを順次実行する実行ステップと、
    を有することを特徴とする画像形成装置の制御方法。

Images