JP6555966B2 - 情報処理装置、情報処理装置の制御方法、及びプログラム - Google Patents

Description

本発明は、情報処理装置、情報処理装置の制御方法、及びプログラムに関する。

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

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

特に、ある目的に応じて、特定の入力から出力までの処理を行うように作られた拡張ソフトは、アプリケーションソフトウェア（以降、アプリ）と呼ばれる。アプリは、画像形成装置が備えるファクシミリ、スキャナ、プリンタといった機能を利用することで入力から出力までの一連の処理（以降、ワークフロー）を実現している。画像形成装置は、ユーザの目的に応じて複数のアプリをインストールできるように構成されている。
このように、１つのアプリでワークフローを行うケースでは、ユーザが使用するグラフィカルユーザーインタフェース（ＧＵＩ）において基調とする色、ボタン等の形状、レイアウト、書体のような要素を含むデザインが統一されている。

また、入力、変換、出力をそれぞれ独立した拡張ソフトで構成し、これら拡張ソフトの組み合わせで一連の処理を行い、拡張ソフトとパラメータの組み合わせで課金を行うものもある（特許文献２参照）。

特許第４０３９４３９号公報 特開２０１４−１３４８７２号公報

しかし、複数の拡張ソフトの単機能を自由に組み合わせることによってワークフローを実現する場合、ワークフローの各工程を実行する各拡張ソフトは、拡張ソフト毎にＧＵＩのデザインを有する。そのため、ユーザからみるとワークフローの工程ごとのＧＵＩのデザインが統一されず、操作し辛い操作性の低いものとなる可能性があるとう問題があった。

本発明は、上記の問題点を解決するためになされたものである。本発明の目的は、ユーザインタフェースのデザインが統一されていない複数の拡張プログラムを組み合わせて一連の処理を実行する場合であっても、該一連の処理におけるユーザインタフェースのデザインを統一することが可能になる仕組みを提供することである。

本発明は、拡張プログラムにより機能を追加可能な情報処理装置であって、複数の工程からなる一連の処理を定義する定義ファイルに従って複数の拡張プログラムを組み合わせて一連の処理を実行する実行手段と、前記実行手段により前記一連の処理を実行する場合に、該一連の処理の各工程を実行する各拡張プログラムが共通で使用するユーザインタフェースのデザインを決定する決定手段と、を有し、前記定義ファイルは、前記デザインに関する情報を含み、前記決定手段は、前記定義ファイルに含まれるデザインに関する情報に基づいて前記デザインを決定することを特徴とする。

本発明によれば、ユーザインタフェースのデザインが統一されていない複数の拡張プログラムを組み合わせて一連の処理を実行する場合であっても、該一連の処理におけるユーザインタフェースのデザインを統一することができる。
この結果、ワークフローの工程ごとの操作画面等のデザインが統一されないことに起因する操作性の低下を防止し、使い勝手の良いユーザフレンドリーな拡張機能を組み合わせたワークフローの操作環境を提供することが可能となる。

本実施例のシステム構成図 本実施例のＭＦＰのハードウェア構成図 本実施例のサーバのハードウェア構成図 本実施例のＭＦＰのソフトウェア構成図 本発明の実施例の機能プロバイダ情報テーブル 本実施例のワークフロー定義ファイルの例 本実施例のワークフロー定義ファイルの他の例 本実施例のワークフロー実行処理を例示するシーケンス図 本実施例のワークフロー実行色を決定する処理を例示するフローチャート 本実施例のＷｅｂ ＯＣＲプロバイダのＯＣＲ実行処理を例示するフローチャート

以下、本発明を実施するための形態について図面を用いて説明する。
図１は、本発明の情報処理装置の一実施例を示す画像処理装置を適用可能なシステムの構成を例示する図である。

本実施例のシステムは、ＬＡＮ１１０を介して接続されるＭＦＰ１０１と、ＷＡＮ１２０を介して接続されるサーバ１０２から構成される。ＬＡＮ１１０上の装置とＷＡＮ１２０上の装置とは、お互いのネットワークを通して相互に通信可能である。なお、図１は、典型的なネットワーク構成の例であり、各装置がＬＡＮ１１０またはＷＡＮ１２０のどちらにあっても構わない。

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

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

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

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

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

図３は、サーバ１０２のハードウェア構成を例示するブロック図である。
ＣＰＵ３１１を含む制御部３１０は、サーバ１０２全体の動作を制御する。ＣＰＵ３１１は、ＲＯＭ３１２やＨＤＤ３１４に記憶された制御プログラムを読み出して各種制御処理を実行する。ＲＯＭ３１２は、各種のプログラムやデータを記憶する。ＲＡＭ３１３は、ＣＰＵ３１１の主メモリ、ワークエリア等の一時記憶領域として用いられる。ＨＤＤ３１４は、各種のプログラムやデータを記憶するハードディスクドライブである。

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

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

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

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

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

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

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

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

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

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

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

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

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

各機能プロバイダは、ＭＦＰ１０１に同じ機能タイプを持つ機能プロバイダが他に存在しなくても、自身の機能タイプ用に定義された機能プロバイダインタフェースを実現する。

以上で説明した４１１〜４１５の５つの機能プロバイダは、ほんの一例であり、ＭＦＰ１０１には、拡張ソフトとして様々な機能プロバイダを追加・削除することが可能である。

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

機能プロバイダ登録部４２１は、各機能プロバイダからの依頼を受けて、機能プロバイダ情報テーブル４２３に、各機能プロバイダの機能タイプや設定可能な値などの情報を登録する。各機能プロバイダは、ＭＦＰ１０１にインストールされ実行状態になった時に機能プロバイダ登録部４２１に対して自身の登録を行う。

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

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

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

図５は、機能プロバイダ情報テーブル４２３の一例を示す図である。
図５に示すように、機能プロバイダ情報テーブル４２３は、機能プロバイダを一意に特定する機能プロバイダＩＤ、機能プロバイダの名称、機能タイプ、機能プロバイダインタフェース、デフォルトカラーなど、機能プロバイダに関する情報を保持する。
デフォルトカラーは、何も指示されない場合の機能プロバイダのＧＵＩデザインの色のテーマを指し示すものであり、"Ｇｒｅｅｎ"であれば、緑基調のＧＵＩ表示を行うことを示している。本実施例では、基調とする色について、"Ｇｒｅｅｎ"、"Ｂｌｕｅ"、"Ｇｒａｙ"などの表現で行っているが、ＲＧＢ値などで示されてもよい。

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

Ｗｏｒｋｆｌｏｗタグ６０１は、以下の記述がワークフローの定義であることを示している。Ｗｏｒｋｆｌｏｗタグ６０１の属性の「ｃｏｌｏｒ＝"Ｂｌｕｅ"」は、このワークフローを実行する際に青を基調としたデザインで実行することを示している。

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

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

Ａｃｔｉｏｎタグ６０５は、ＦＰタグ６０２の子要素であり、スキャンプロバイダの実行において「ｄｏＳｃａｎ」を２番目に呼び出す旨を定義している。Ａｃｔｉｏｎタグ６０５は、「ｄｏＳｃａｎ」を呼び出す際の設定であるＰａｒａｍｅｔｅｒタグや、「ｄｏＳｃａｎ」を実行した結果の出力を定義するＯｕｔｐｕｔタグを含む。

ＦＰ６０６タグは、ｎｏ属性とｔｙｐｅ属性で、２番目に実行する機能プロバイダがＯＣＲプロバイダであることを定義している。子要素はＦＰタグ６０２と同様の構成である。
ＦＰ６０７タグは、ｎｏ属性とｉｄ属性で、３番目に実行する機能プロバイダがＦＴＰ送信プロバイダであることを定義している。

なお、ＦＰタグでは、機能プロバイダを、ＦＰタグ６０２、６０６のようにｔｙｐｅ属性を使って機能タイプで指定することもできるし、ＦＰタグ６０７のようにｉｄ属性を使って一意に指定することもできる。

図７は、本実施例におけるワークフロー定義ファイルの具体的な記述の他の例を示す図である。
Ｗｏｒｋｆｌｏｗタグ７０１は、以下の記述がワークフローの定義であることを示している。図６に示したＷｏｒｋｆｌｏｗタグ６０１と異なり、タグの属性の「ｃｏｌｏｒ」は、このワークフローでは定義されていないことを示している。

ＦＰ７０２タグは、ｎｏ属性とｉｄ属性で、１番目に実行する機能プロバイダが簡単スキャンプロバイダであることを定義している。以降のその他タグの説明は、図６と同様であるため省略する。

図８は、本実施例におけるＭＦＰ１０１上のワークフロー実行処理の一連の処理の流れを示すシーケンス図である。図８及び後述する図９、図１０の各処理は、ＭＦＰ１０１のＲＯＭ２１２又はＨＤＤ２１４に記憶されているプログラム（ソフトウェア）を、ＣＰＵ２１１が必要に応じてＲＡＭ２１３に読み出し、解析、実行することにより実現される各機能により実行される。

Ｓ８０１において、ユーザからのワークフロー実行指示を、ワークフロー処理部４３０が受け取る。該ワークフロー実行指示を受け取ると、ワークフロー処理部４３０は、Ｓ８０２の処理を実行する。
Ｓ８０２において、ワークフロー処理部４３０は、上記Ｓ８０１で受け取った実行指示に対応するワークフロー定義ファイル４４０を読み込む。

次に、Ｓ８０３において、ワークフロー処理部４３０は、機能プロバイダ管理部４２０に対して、ワークフロー定義ファイル４４０に記載されている機能プロバイダの検索を指示する。ワークフロー定義ファイル４４０には、「機能タイプがスキャンの機能プロバイダ」、「機能タイプがＯＣＲの機能プロバイダ」および「機能プロバイダＩＤがＳＥＮＤ＿ＦＴＰの機能プロバイダ」が記載されているため、その３つの検索条件を指定して検索を指示する。上記検索の指示に応じて、機能プロバイダ管理部４２０は、Ｓ８０４の処理を実行する。

Ｓ８０４において、機能プロバイダ管理部４２０は、機能プロバイダ情報テーブル４２３をもとに検索条件に一致する機能プロバイダを抽出する。検索条件に一致するスキャンプロバイダが複数存在した場合は、最も優先順位の高いスキャンプロバイダを検索結果とする。本例では、検索により、標準スキャンプロバイダ４１１、Ｗｅｂ ＯＣＲプロバイダ４１４そしてＦＴＰ送信プロバイダ４１５が抽出されるものとする。

次に、Ｓ８０５において、機能プロバイダ管理部４２０は、機能プロバイダの検索結果をワークフロー処理部４３０に通知する。
次に、Ｓ８０６において、上記Ｓ８０５で通知された検索結果を受け取ったワークフロー処理部４３０は、機能プロバイダの情報を基にワークフロー実行色を決定する。ワークフロー実行色とは、そのワークフローを実行する際にどのような色を基調にしたデザインでＧＵＩを表示するかを示す情報（ユーザインタフェースに関するデザインの情報）であり、ワークフローの各工程を実行する各拡張プログラムに共通で指定されるものである。

図９は、図８のＳ８０６における、ワークフロー処理部４３０が行うワークフロー実行色を決定する処理のフローチャートである。
Ｓ９０１において、ワークフロー処理部４３０は、ワークフロー定義ファイルを解析して、ワークフロー実行色が指定されているかどうかを判断する。ワークフロー定義ファイル４４０の例であれば、タグ６０１のｃｏｌｏｒ属性に「ｃｏｌｏｒ＝"Ｂｌｕｅ"」の定義があるため、ワークフロー実行色が指定されていると判断する。ワークフロー定義ファイル４４１の例であれば、タグ７０１のｃｏｌｏｒ属性の定義がないため、ワークフロー実行色が指定されていないと判断する。

そして、上記Ｓ９０１において、ワークフロー実行色が指定されていると判定した場合(Ｓ９０１でＹｅｓの場合)、ワークフロー処理部４３０は、Ｓ９０２に処理を進める。
Ｓ９０２において、ワークフロー処理部４３０は、ワークフロー定義ファイルに指定されているワークフロー実行色をそのままワークフロー実行色として決定し、本フローチャートの処理を終了する。

一方、上記Ｓ９０１において、ワークフロー実行色が指定されていないと判定した場合(Ｓ９０１でＮｏの場合)、ワークフロー処理部４３０は、Ｓ９０３に処理を進める。
Ｓ９０３において、ワークフロー処理部４３０は、ワークフローで実行するために検索された各機能プロバイダのデフォルトカラーを機能プロバイダ情報テーブル４２３から取得する。
次に、Ｓ９０４において、ワークフロー処理部４３０は、所定のアルゴリズムに基づいて、上記Ｓ９０３で取得した各機能プロバイダのデフォルトカラーからワークフロー実行色を決定し、本フローチャートの処理を終了する。

上記Ｓ９０４で、ワークフロー実行色を決定するアルゴリズムとしては、例えば、各機能プロバイダのデフォルト色の中で数が多いものを選択するものとするアルゴリズムとする。具体的例を挙げて説明すると、ワークフロー定義ファイル４４１を実行する際に、簡単スキャンプロバイダ４１２、組込ＯＣＲ機能プロバイダ４１３、ＦＴＰ送信プロバイダ４１５が抽出されたとする。その場合、それぞれのデフォルトカラーである"Ｂｌｕｅ"、"Ｇｒａｙ"、"Ｇｒａｙ"の中で、一番多い"Ｇｒａｙ"を選択する。他にも、最初や最後に実行する機能プロバイダのデフォルト色を用いるアルゴリズムでもよい。また、本ワークフローの直前に実行されていた処理で使用されたワークフロー実行色を用いるアルゴリズムでもよい。また、複数アルゴリズムを用意しておき、どのアルゴリズムを用いるかをワークフロー定義ファイルに記載するような構成でもよい。また、ワークフロー処理部４３０の設定としてユーザ毎にアルゴリズムを予め設定させておき、ログインユーザに設定されているワークフロー実行色を用いるアルゴリズムでもよい。また、ワークフロー実行時に、ユーザに対してデザインの選択肢を提示して、ユーザに選択させる構成であってもよい。ワークフローで実行される各機能プロバイダのＧＵＩデザイン（本実施例では色）を統一するワークフロー実行色を選択する構成であればどのようなアルゴリズムを用いてもよい。

なお、本実施例では、上記Ｓ９０１において、ワークフロー実行色が指定されていないと判定した場合に、上述のようなアルゴリズムにより、ワークフロー実行色を決定する構成について説明した。しかし、上記Ｓ９０１の処理をスキップし、上述のようなアルゴリズムにより、ワークフロー実行色を決定するように構成してもよい。

以上が、ワークフロー処理部４３０が行うワークフロー実行色を決定する処理である。この決定処理がワークフロー実行時に行われるため、実行するワークフロー毎にデザインを変更することが可能となる。
なお、本実施例では、ワークフロー処理部４３０がワークフローの各工程を実行する機能プロバイダのユーザインタフェースのデザインを決定する構成について説明した。しかし、本発明はこれに限定されるものではなく、ワークフローの各工程を実行する各機能プロバイダのユーザインタフェースのデザインを統一可能な構成であればよい。例えば、ワークフローの各工程を実行する各機能プロバイダが直前に実行された機能プロバイダで使用されたデザインを取得し、該取得したデザインで自身のユーザインタフェースを表示するように構成してもよい。

以下、図８の説明に戻る。
上記Ｓ８０６の処理の後、Ｓ８０７において、ワークフロー処理部４３０は、検索結果の標準スキャンプロバイダ４１１に対して、スキャン指示を行う。この指示を行う際、ワークフロー処理部４３０は、実行時の情報として、上記Ｓ８０６において決定したワークフロー実行色を標準スキャンプロバイダ４１１に渡す。

Ｓ８０８において、ワークフロー処理部４３０からスキャン指示を受け取った標準スキャンプロバイダ４１１は、指示に従ってスキャンを実行する。この際、標準スキャンプロバイダ４１１は、実行する際に表示するＧＵＩについて、上記Ｓ８０７で指定されたワークフロー実行色（即ちＳ８０６で決定されたもの）を基調にした色でＧＵＩ表示を行う。なお、標準スキャンプロバイダ４１１は、予め基調で指定できる色に対応して、各ＧＵＩパーツをどのような色で表示するかを内部にテーブルとして保持しており、そのテーブルに応じて表示を行う。

そして、上記Ｓ８０８の標準スキャンプロバイダ４１１によるスキャン実行が終了すると、ワークフロー処理部４３０は、Ｓ８０９の処理を実行する。
Ｓ８０９において、ワークフロー処理部４３０は、検索結果のＷｅｂ ＯＣＲプロバイダ４１４に対して、ＯＣＲ指示を行う。上記Ｓ８０７の処理と同様にワークフロー処理部４３０は、この指示を行う際、実行時の情報として、上記Ｓ８０６において決定したワークフロー実行色をＷｅｂ ＯＣＲプロバイダ４１４に渡す。
Ｓ８１０において、ワークフロー処理部４３０からＯＣＲ指示を受け取ったＷｅｂ ＯＣＲプロバイダ４１４は、指示に従ってＯＣＲを実行する。

以下、Ｗｅｂブラウザ４５０を用いて処理を実行する機能プロバイダの処理の一例として、Ｗｅｂ ＯＣＲプロバイダ４１４のＯＣＲ処理を説明する。
図１０は、図８のＳ８１０におけるＷｅｂ ＯＣＲプロバイダ４１４のＯＣＲ処理を例示するフローチャートである。
Ｓ１００１において、Ｗｅｂ ＯＣＲプロバイダ４１４は、Ｗｅｂブラウザ４５０を起動する。

次に、Ｓ１００２において、Ｗｅｂ ＯＣＲプロバイダ４１４は、Ｗｅｂブラウザ４５０に対して、ＯＣＲを行うサーバ１０２上のＷｅｂアプリケーションを呼び出すためのＵＲＬを指定する。その結果、Ｗｅｂブラウザ４５０は、サーバ１０２からＷｅｂブラウザ４５０に表示するためのＨＴＭＬデータやスクリプトそして画像データから構成されるコンテンツを受け取る。このコンテンツは、ＯＣＲ処理中をユーザに示すためのコンテンツである。

次に、Ｓ１００３において、Ｗｅｂブラウザ４５０は、上記Ｓ１００２で受け取ったコンテンツをレンダリングし、スクリプトを実行して、コンテンツの表示を行う。
次に、Ｓ１００４において、Ｗｅｂ ＯＣＲプロバイダ４１４は、Ｗｅｂブラウザ４５０が表示しているコンテンツに対して、ワークフロー実行色を設定する処理を行う。具体的には、Ｗｅｂ ＯＣＲプロバイダ４１４は、Ｗｅｂブラウザに色を変更するためのスクリプトを実行させる。そのスクリプトは、コンテンツに含まれる色の設定を、上記図８のＳ８０９で実行時の情報としてワークフロー処理部４３０から渡されたワークフロー実行色で示される基調の色に変換する処理を含むものである。例えば、実行時の情報としてワークフロー処理部４３０から渡された基調の色が"Ｂｌｕｅ"であれば、もともとのコンテンツの色（デフォルトカラー）を輝度と色彩を変えずに、色相を"Ｂｌｕｅ"に近づける処理等である。このようにして、Ｗｅｂ ＯＣＲプロバイダ４１４のように、Ｗｅｂブラウザを利用して表示を行う機能プロバイダにおいても、実行時の色指定が可能である。なお、上記スクリプトは、例えばＪａｖａ（登録商標）Ｓｃｒｉｐｔである。また、ワークフロー実行色の設定については、この方法に限定されるものではなく、スタイルシートを適用するなどの方法でもよい。

次に、Ｓ１００５において、Ｗｅｂ ＯＣＲプロバイダ４１４は、Ｗｅｂブラウザ４５０を介して、ワークフロー処理部４３０から受け取るスキャン機能プロバイダが出力した画像を、サーバ１０２に送信する。サーバ１０２では受け取った画像に対してＯＣＲ処理を行い、ＯＣＲ結果をＷｅｂブラウザ４５０に応答する。

次に、Ｓ１００６において、Ｗｅｂブラウザ４５０がサーバ１０２からＯＣＲ結果を取得し、該Ｗｅｂブラウザ４５０が取得したＯＣＲ結果をＷｅｂ ＯＣＲプロバイダ４１４が取得し、ワークフロー処理部４３０に渡す。

以上がＷｅｂ ＯＣＲプロバイダ４１４のＯＣＲ処理である。ここでは、Ｗｅｂブラウザ４５０を用いて処理を実行する機能プロバイダの処理の一例として、Ｗｅｂ ＯＣＲプロバイダ４１４のＯＣＲ処理について説明したが、Ｗｅｂブラウザ４５０を用いて処理を実行するものであればＯＣＲ処理以外の処理（一例としてはファイルサーバへのデータ送信処理、画像処理、ソーシャルネットワークサービスへの投稿処理など）を実行する場合も同様にワークフロー実行処理を設定可能である。

以下、図８の説明に戻る。
Ｓ８１１において、ワークフロー処理部４３０は、検索結果のＦＴＰ送信プロバイダ４１５に対して、スキャン画像とＯＣＲ結果のＦＴＰ送信指示を行う。上記Ｓ８０７の処理と同様にワークフロー処理部４３０は、この指示を行う際、実行時の情報として、上記Ｓ８０６において決定したワークフロー実行色をＦＴＰ送信プロバイダ４１５に渡す。

Ｓ８１２において、ワークフロー処理部４３０からＦＴＰ送信指示を受け取ったＦＴＰ送信プロバイダ４１５は、指示に従ってＦＴＰ送信を実行する。この際、ＦＴＰ送信プロバイダ４１５は、実行する際に表示するＧＵＩについて、上記Ｓ８１１で指定されたワークフロー実行色（即ちＳ８０６で決定されたもの）を基調にした色でＧＵＩ表示を行う。

以上のような手順により、複数の機能プロバイダを組み合わせて一連の処理として実行する場合に、該一連の処理の中で実行される各機能プロバイダのＧＵＩデザインをワークフロー定義にしたがって決定することにより、ワークフロー内でのＧＵＩデザインの統一が可能になる。また、ワークフロー定義が異なれば、図９のフローチャートに従って、ワークフローの実行色が異なるため、ワークフロー毎にデザインを変更することが可能となる。

なお、本実施例では、基調とする色についてワークフローを通してＧＵＩのデザインを合わせる例について説明したが、デザイン（表示形態）を合わせるという点において、他のデザイン要素でもよい。例えば、ＧＵＩで使用される部品（ボタンやテキストボックス等）の形状（例えば、丸角、影付き等）、部品のレイアウト、使用される文字フォントの書体や言語等であってもよい。また、それぞれのデザイン要素を組み合わせてＧＵＩデザインテーマとして表現し、これをワークフローで実行される各機能プロバイダで統一するように構成してもよい。

また、本実施例では、ワークフローを構成するものとして、ワークフロー処理部が、機能プロバイダを呼び出す構成で説明したが、拡張ソフトであるアプリケーション（アプリ）がワークフロー処理部の役割を行い、他の拡張ソフトを呼び出す構成であってもよい。例えば、任意のアプリが処理を行う際に、処理の途中で他のアプリや機能プロバイダを呼び出す際に、処理毎にデザインの定義を保持していて、呼び出す際にそのデザインの指定を呼び出される側の拡張ソフトに渡すように構成してもよい。

さらに、複数のアプリを組み合わせて一連の処理を行う場合に、各アプリのＧＵＩデザインを、上記機能プロバイダの場合と同様に統一するように構成してもよい。

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

以上、本発明によれば、ワークフローの定義と拡張ソフトの組合せにより、ワークフロー実行時のユーザインタフェースのデザインを動的に決定することにより、ユーザインタフェースのデザインが統一されていない複数の拡張プログラムを組み合わせて一連の処理を実行する場合であっても、該一連の処理におけるユーザインタフェースのデザインを統一することができる。
この結果、ワークフローの工程ごとの操作画面等のデザインが統一されないことに起因する操作性の低下を防止し、使い勝手の良いユーザフレンドリーな拡張機能を組み合わせたワークフローの操作環境を提供することが可能となる。

なお、ワークフロー定義に、ＧＵＩのデザインを統一しない旨の情報が含まれている場合には、ワークフロー処理部４３０等は、該ワークフローの各処理を実行する各機能プロバイダのＧＵＩのデザインをデフォルトのデザインとするように制御する構成としてもよい。

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

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

１０１ ＭＦＰ
１０２ サーバ
４１０ 拡張ソフト管理部
４２０ 機能プロバイダ管理部
４３０ ワークフロー処理部
４４０，４４１ ワークフロー定義ファイル
４５０ Ｗｅｂブラウザ

Claims (15)

1. 拡張プログラムにより機能を追加可能な情報処理装置であって、
   複数の工程からなる一連の処理を定義する定義ファイルに従って複数の拡張プログラムを組み合わせて一連の処理を実行する実行手段と、
   前記実行手段により前記一連の処理を実行する場合に、該一連の処理の各工程を実行する各拡張プログラムが共通で使用するユーザインタフェースのデザインを決定する決定手段と、を有し、
   前記定義ファイルは、前記デザインに関する情報を含み、
   前記決定手段は、前記定義ファイルに含まれるデザインに関する情報に基づいて前記デザインを決定することを特徴とする情報処理装置。
2. 前記決定手段は、所定のアルゴリズムに基づいて前記デザインを決定することを特徴とする請求項１に記載の情報処理装置。
3. 前記決定手段は、前記定義ファイルに前記デザインに関する情報が含まれていない場合に、所定のアルゴリズムに基づいて前記デザインを決定することを特徴とする請求項１に記載の情報処理装置。
4. 前記アルゴリズムは、前記一連の処理の各工程を実行する各拡張プログラムが有するデフォルトのデザインに基づいて前記デザインを決定するアルゴリズムであることを特徴とする請求項２又は３に記載の情報処理装置。
5. 前記アルゴリズムは、前記一連の処理の各工程を実行する各拡張プログラムが有するデフォルトのデザインの中で最も多いデザインに、前記デザインを決定するアルゴリズムであることを特徴とする請求項４に記載の情報処理装置。
6. 前記アルゴリズムは、前記一連の処理の各工程において最初又は最後に実行する拡張プログラムが有するデフォルトのデザインに、前記デザインを決定するアルゴリズムであることを特徴とする請求項４に記載の情報処理装置。
7. 前記デフォルトのデザインを含む拡張プログラムの情報を登録する登録手段を有し、
   前記決定手段は、前記登録手段から前記一連の処理の各工程を実行する各拡張プログラムが有するデフォルトのデザインを取得することを特徴とする請求項４乃至６のいずれか１項に記載の情報処理装置。
8. 前記アルゴリズムは、ユーザごとの設定に基づいて前記デザインを決定するアルゴリズムであることを特徴とする請求項２又は３に記載の情報処理装置。
9. 前記アルゴリズムは、当該一連の処理の直前に実行された一連の処理で使用されたデザインに、前記デザインを決定するアルゴリズムであることを特徴とする請求項２又は３に記載の情報処理装置。
10. 拡張プログラムにより機能を追加可能な情報処理装置であって、
    複数の工程からなる一連の処理を定義する定義ファイルに従って複数の拡張プログラムを組み合わせて一連の処理を実行する実行手段を有し、
    前記拡張プログラムは、直前の拡張プログラムで使用されたユーザインタフェースのデザインを使用して処理を実行することを特徴とする情報処理装置。
11. 前記拡張プログラムがウェブブラウザを用いて処理を行う拡張プログラムである場合、該拡張プログラムは、Ｗｅｂブラウザが表示するコンテンツのデザインを、前記決定手段で決定されたデザインに、変更する処理を行うことを特徴とする請求項１乃至９のいずれか１項の記載の情報処理装置。
12. 前記デザインは、ユーザインタフェースにおいて基調とする色、使用される部品の形状、部品のレイアウト、使用される書体、使用される言語の少なくともいずれかを含むことを特徴とする請求項１乃至１１のいずれか１項に記載の情報処理装置。
13. 前記情報処理装置は、画像形成装置であることを特徴とする請求項１乃至１２のいずれか１項に記載の情報処理装置。
14. 拡張プログラムにより機能を追加可能な情報処理装置の制御方法であって、
    複数の工程からなる一連の処理を定義する定義ファイルに従って複数の拡張プログラムを組み合わせて一連の処理を実行する実行ステップと、
    前記実行ステップにより前記一連の処理を実行する場合に、該一連の処理の各工程を実行する各拡張プログラムが共通で使用するユーザインタフェースのデザインを決定する決定ステップと、を有し、
    前記定義ファイルは、前記デザインに関する情報を含み、
    前記決定ステップにおいて、前記定義ファイルに含まれるデザインに関する情報に基づいて前記デザインを決定することを特徴とする情報処理装置の制御方法。
15. コンピュータを、請求項１乃至１３のいずれか１項に記載の手段として機能させるためのプログラム。

Images