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

Abstract

【課題】 ワークフローの定義ファイルに記述された機能プロバイダ中のからユーザが意図しない機能プロバイダを含まないワークフローを実行する。【解決手段】異なる機能処理を行う機能プロバイダを記憶する記憶手段を備える情報処理装置において、前記ワークフロー定義ファイルに従い機能プロバイダを検索する場合、前記ワークフロー定義ファイルに記述された機能プロバイダの動作種別がユーザの指定により省略できる情報に設定されていると判断した場合で、かつ、当該機能プロバイダを記憶手段から検索できない場合、当該機能プロバイダを含まない機能プロバイダを用いてワークフローを実行することを特徴とする。【選択図】 図８

Description

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

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

特にある目的に応じて、特定の入力から出力を行うように作られた拡張ソフトは、アプリケーションソフトウェア（以降、アプリ）と呼ばれる。アプリは、画像形成装置が備えるファクシミリ、スキャナ、プリンタ等の機能を利用して、入力から出力までの一連の処理（以降、ワークフロー）を実現している。画像形成装置は、ユーザの目的に応じて複数のアプリをインストールできるように構成されている。従来技術には、複数の処理を組み合わせで行われる一連の処理を実行できる技術もあった（特許文献１）。

特開2014-134872号公報

従来技術では、ワークフローを実行するため、ワークフローの定義ファイルを用いて画像形成装置上の複数の機能を連結するよう構成されている。

つまり、ワークフローの定義ファイルに記載された複数の機能を単純に実行することが主眼だったため、決められた動作しかできなかった。このため、ユーザがワークフローのうち、所望の機能だけは、あえて実行させたくない場合に柔軟に対応できていなかった。
そのため、ワークフロー提供者は、別のワークフローの定義ファイルを作成するか、または、別ファイルとして編集する必要があった。そのため、ワークフロー提供者は、管理すべきワークフローが増えて操作が煩雑になり、ユーザ自身もワークフローの提供をうけるための時間が増大していた。

本発明は、上記の課題を解決するためになされたもので、本発明の目的は、ワークフローの定義ファイルに記述された機能プロバイダの中からユーザが意図しない機能プロバイダを含まないワークフローを実行できる仕組みを提供することである。

上記目的を達成する本発明の情報処理装置は以下に示す構成を備える。
情報処理装置であって、異なる機能処理を行う機能プロバイダを記憶する記憶手段と、作成されたワークフロー定義ファイルに従い実行する機能プロバイダを検索する検索手段と、前記検索手段が前記ワークフロー定義ファイルに従い機能プロバイダを検索する場合、前記ワークフロー定義ファイルに記述された機能プロバイダの動作種別がユーザの指定により省略できる情報に設定されているかどうかを判断する判断手段と、前記ワークフロー定義ファイルに記述された機能プロバイダの動作種別がユーザの指定により省略できる情報であると判断した場合で、かつ、前記検索手段が当該機能プロバイダを前記記憶手段から検索できない場合、当該機能プロバイダを含まない機能プロバイダを用いてワークフローを実行する実行手段と、を備えることを特徴とする。

本発明によれば、ワークフローの定義ファイルに記述された機能プロバイダ中のからユーザが意図しない機能プロバイダを含まないワークフローを実行できる。

画像処理システムのシステム構成の一例を示す図である。 ＭＦＰの構成を示すブロック図である。 サーバの構成を示すブロック図である。 ＭＦＰにおけるソフトウェア構成図の一例である。 ＭＦＰ上の一連の処理の流れを示した図である。 ワークフロー定義ファイルの具体的な記述例を示す図である。 機能プロバイダ情報テーブルの一例を示す図である。 情報処理装置の制御方法を説明するフローチャートである。 ＭＦＰにおけるソフトウェア構成図の一例を示す図である。 ＭＦＰ上の一連の処理の流れを示す図である。 情報処理装置の制御方法を説明するフローチャートである。 情報処理装置で表示するＵＩ画面の一例を示す図である。 情報処理装置で表示するＵＩ画面の一例を示す図である。 情報処理装置で表示するＵＩ画面の一例を示す図である。

次に本発明を実施するための最良の形態について図面を参照して説明する。
＜システム構成の説明＞
〔第1実施形態〕

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

図１において、ＭＦＰ101は、スキャナ、プリンタを有する画像形成装置である。加えて、装置上で動作する拡張ソフトを追加、実行させるためのソフトウェアプラットホームを持つ。サーバ102は、ＭＦＰ101と連携して各種処理を行うサーバである。例えば、ＭＦＰ101から画像データを受信するファイルサーバであったり、ＭＦＰ101から処理依頼を受けてＯＣＲ（光学文字認識）処理を実行するアプリケーションサーバであったりする。また、システムにおいて、サーバは一台とは限らず、目的に応じて複数のサーバが存在してもよい。

図２は、図１に示したＭＦＰ101の構成を示すブロック図である。
図２において、ＣＰＵ211を含む制御部210は、ＭＦＰ101全体の動作を制御する。ＣＰＵ211は、ＲＯＭ212やＨＤＤ214に記憶された制御プログラムを読み出して読取制御や送信制御などの各種制御処理を実行する。ＲＡＭ213は、ＣＰＵ211の主メモリ、ワークエリア等の一時記憶領域として用いられる。ＨＤＤ214は、画像データやインストールされた拡張ソフトを含む各種プログラムを記憶する。
操作部Ｉ／Ｆ215は、操作部219と制御部210とを接続する。操作部219には、タッチパネル機能を有する液晶表示部やキーボードなどが備えられている。

プリンタＩ／Ｆ216は、プリンタ220と制御部210とを接続する。プリンタ220で印刷すべき画像データはプリンタＩ／Ｆ216を介して制御部210からプリンタ220に転送され、プリンタ220において記録媒体上に印刷される。

スキャナＩ／Ｆ217は、スキャナ221と制御部210とを接続する。スキャナ221は、原稿上の画像を読み取って画像データを生成し、スキャナＩ／Ｆ217を介して制御部210に入力する。ネットワークＩ／Ｆ218は、制御部210（ＭＦＰ101）をＬＡＮ110に接続する。ネットワークＩ／Ｆ218は、ＬＡＮ110上またはＷＡＮ120上の他の装置との間で各種情報を送受信する。

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

表示部Ｉ／Ｆ315は、表示部318と制御部310とを接続する。キーボードＩ／Ｆ316は、キーボード319と制御部310とを接続する。ＣＰＵ311は、キーボード319を介したユーザからの指示を認識し、認識した指示に応じて表示部318に表示する画面を遷移させる。

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

図４は、図１に示したＭＦＰ101におけるソフトウェア構成図の一例である。
図４において、ＭＦＰ101のＨＤＤ214に記憶されているプログラム（ソフトウェア）を、ＣＰＵ211がＲＡＭ213に読み出し、解析、実行することで、図８に示すフローチャートの処理が実行される。

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

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

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

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

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

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

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

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

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

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

プレビュープロバイダ416は、画像表示機能を提供する機能プロバイダ（機能タイプ＝画像表示）である。ＦＴＰ送信プロバイダ415は、機能タイプが「画像表示」の機能プロバイダのために定義された機能プロバイダインターフェース（画像表示プロバイダインターフェース）を実現する。
各機能プロバイダは、ＭＦＰ101に同じ機能タイプを持つ機能プロバイダが他に存在しなくても、自身の機能タイプ用に定義された機能プロバイダインターフェースを実現する。
以上で説明した6つの機能プロバイダは一例であり、ＭＦＰ101には、拡張ソフトとして様々な機能プロバイダを追加・削除することが可能である。

機能プロバイダ管理部420は、ＭＦＰ101にインストールされている機能プロバイダを管理するソフトウェアである。機能プロバイダ管理部420は、機能プロバイダ登録部421、機能プロバイダ設定部422、機能プロバイダ検索部423、機能プロバイダ情報テーブル424、機能プロバイダ設定テーブル425、機能プロバイダインターフェース定義426を持っている。

機能プロバイダ登録部421は、拡張ソフト管理部410が管理する上述した各機能プロバイダからの依頼を受けて、機能プロバイダ情報テーブル424に、各機能プロバイダの機能タイプや設定可能な値などの情報を登録する。
機能プロバイダ設定部422は、ユーザからの依頼を受けて、機能プロバイダの優先順位やユーザ毎の使用可否といった機能プロバイダに関する設定を機能プロバイダ設定テーブル425に設定する。
機能プロバイダ検索部423は、後述するワークフロー処理部430から機能プロバイダの検索条件を受け取り、機能プロバイダ情報テーブル424と機能プロバイダ設定テーブル425の情報をもとに条件に一致する機能プロバイダを特定する。
なお、機能プロバイダ検索部423は、検索結果として機能プロバイダを１つに特定するため、検索条件に一致する機能プロバイダが複数存在した場合は、最も優先順位の高い機能プロバイダを検索結果とする。

機能プロバイダインターフェース定義426は、機能プロバイダインターフェースを定義している。
ワークフロー処理部430は、後述するワークフロー定義ファイル440に従って複数の機能プロバイダを組み合わせて一連の処理として実行する。本実施形態では、ワークフローとは、複数の機能プロバイダを組み合わせた一連の処理を指すものとする。

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

〔ワークフロー処理〕
図５は、図１に示したＭＦＰ101上の一連の処理の流れを示した図である。
図５において、ワークフロー処理部430は、ユーザからワークフローの実行指示を受け取る（S530）と、実行指示に対応するワークフロー定義ファイル440を読み込む（S531）。ここでは、ワークフロー定義ファイル440に「機能タイプがスキャンの機能プロバイダ」、「機能タイプがＯＣＲの機能プロバイダ」、「ＦＴＰ送信プロバイダ」を順に実行するように定義されているものとする。なお、本実施形態に示すワークフロー定義ファイル440は実行する機能プロバイダを機能タイプで指定することもできるし、機能プロバイダを一意に特定する形で指定することもできる。

ワークフロー処理部430は、機能プロバイダ管理部420に対して「機能タイプがスキャンの機能プロバイダ」すなわちスキャンプロバイダを検索するよう指示する（S532）。ここで、S532における指示にはワークフロー定義ファイル440に定義された検索条件が含まれる。検索指示を受け取った機能プロバイダ管理部420は、機能プロバイダ情報テーブル424と機能プロバイダ設定テーブル425の情報をもとに検索条件に一致するスキャンプロバイダを検索する（S533）。ここで、機能プロバイダ管理部420は、検索条件に一致するスキャンプロバイダが複数存在した場合は、最も優先順位の高いスキャンプロバイダを検索結果とする。
その後、機能プロバイダ管理部420は、スキャンプロバイダの検索結果を、ワークフロー処理部430に通知する（S534）。検索結果を受け取ったワークフロー処理部430は、検索結果のスキャンプロバイダに対して、スキャン指示を行う（S535）。ここでワークフロー処理部430は、検索結果が標準スキャンプロバイダ411であるか、簡単スキャンプロバイダ412であるかを識別しない。どちらであってもスキャンプロバイダであることに変わりはなく、ワークフロー処理部430は個別の機能プロバイダを識別することなくスキャンプロバイダインターフェースに従ってスキャン指示を出すことができる。
ワークフロー処理部430からスキャン指示を受け取ったスキャンプロバイダ（図５では標準スキャンプロバイダ411）は、指示に従ってスキャンを実行する（S536）。

ワークフロー処理部430は、機能プロバイダ管理部420に対して「機能タイプがＯＣＲの機能プロバイダ」すなわちＯＣＲプロバイダを検索するよう指示する（S537）。ここで、ＯＣＲプロバイダを検索する指示にはワークフロー定義ファイル440に定義された検索条件が含まれる。検索指示を受け取った機能プロバイダ管理部420は、機能プロバイダ情報テーブル424と機能プロバイダ設定テーブル425の情報をもとに検索条件に一致するＯＣＲプロバイダを検索する（S538）。ここで、検索条件に一致するＯＣＲプロバイダが複数存在した場合は、機能プロバイダ管理部420は、最も優先順位の高いＯＣＲプロバイダを検索結果とする。
次に、機能プロバイダ管理部420は、ＯＣＲプロバイダの検索結果を、ワークフロー処理部430に通知する（S539）。検索結果を受け取ったワークフロー処理部430は、検索結果のＯＣＲプロバイダに対して、ＯＣＲ指示を行う（S540）。
ワークフロー処理部430からＯＣＲ指示を受け取ったＯＣＲプロバイダ（図５では組込ＯＣＲプロバイダ413）は、指示に従ってＯＣＲ処理を実行する（S541）。

ワークフロー処理部430は、機能プロバイダ管理部420に対してプレビュープロバイダ416を検索するよう指示する（S542）。機能プロバイダ管理部420は、プレビュープロバイダ416を検索する（S543）。機能プロバイダ管理部420は、プレビュープロバイダ416を検索結果として、ワークフロー処理部430に通知する（S544）。検索結果を受け取ったワークフロー処理部430は、検索結果のプレビュープロバイダ416に対して、プレビュー指示を行う（S545）。ワークフロー処理部430から送信指示を受け取ったプレビュープロバイダ416は、指示に従ってプレビュー処理を実行する（S546）。

次に、ワークフロー処理部430は、機能プロバイダ管理部420に対してＦＴＰ送信プロバイダ415を検索するよう指示する（S547）。機能プロバイダ管理部420は、ＦＴＰ送信プロバイダ415を検索する（S548）。機能プロバイダ管理部420は、ＦＴＰ送信プロバイダ415を検索結果として、ワークフロー処理部430に通知する（S549）。検索結果を受け取ったワークフロー処理部430は、検索結果のＦＴＰ送信プロバイダ415に対して、送信指示を行う（S550）。
ワークフロー処理部430から送信指示を受け取ったＦＴＰ送信プロバイダ415は、指示に従って送信処理を実行する（S551）。

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

図６において、Workflowタグ610は、以下の記述がワークフローの定義であることを示している。FPタグ620は、Workflowタグ610の子要素で、ワークフローで実行する機能プロバイダに関する情報を定義している。FPタグ620のno属性は、ワークフローにおける機能プロバイダの実行順を定義しており、「no="1"」は最初に実行する機能プロバイダであることを示している。FPタグ620のtype属性は、実行する機能プロバイダの機能タイプを定義しており、「type="SCAN"」はスキャンプロバイダであることを示している。

Conditionタグ621は、FPタグ620の子要素で、スキャンプロバイダの検索条件を子要素であるRequiredタグ622とOptionalタグ1023で定義している。Requiredタグ622は、検索するスキャンプロバイダの必須条件を定義しており、「FILE_FORMAT（ファイル形式）」の設定値として「ＰＤＦ」を設定可能なスキャンプロバイダが必須である旨を示している。Optionalタグ623は、検索するスキャンプロバイダのオプション条件を定義しており、「ORIGINAL_TYPE（原稿種類）」の設定値として「TEXT」を設定可能なスキャンプロバイダを優先的に使用する旨を示している。

ここで、必須条件とオプション条件の違いを説明する。機能プロバイダの検索処理において、必須条件は必ず満たすべき条件であり、必須条件を満たす機能プロバイダが存在しない場合、検索結果は「なし」となる。一方、オプション条件は、オプション条件を満たす機能プロバイダを優先的に使用する条件であり、オプション条件を満たす機能プロバイダが存在しない場合、オプション条件は検索条件から除外される。

Actionタグ624は、FPタグ620の子要素であり、機能プロバイダの呼び出しについての情報を定義している。Actionタグのno属性とmethod属性は、FPタグで定義された機能プロバイダの中での実行順と呼び出すインターフェースを定義している。Actionタグ624は、スキャンプロバイダの実行において「showSettingUI」を1番目に呼び出す旨を定義している。
Parameterタグ625はActionタグ624の子要素であり、Actionタグ624で定義されているインターフェース（showSettingUI）を呼び出す際に渡す設定値を定めている。Actionタグ626は、FPタグ620の子要素であり、スキャンプロバイダの実行において「doScan」を2番目に呼び出す旨を定義している。Outputタグ627は、Actionタグ626の子要素であり、「doScan」を実行した結果の出力を定義している。
Outputタグ627は、type属性で出力形式が「Document」である旨を、id属性で出力データを一意に特定するＩＤが「foo」である旨を定義している。FPタグ630は、no属性とtype属性で、2番目に実行する機能プロバイダがＯＣＲプロバイダであることを定義している。Requiredタグ631は、ＯＣＲプロバイダの必須条件を定義しており、「ＬＡＮＧ（認識言語）」の設定値として「ＪＡ（日本語）」を設定可能なＯＣＲプロバイダが必須である旨を示している。

Actionタグ632は、FPタグ630の子要素であり、ＯＣＲプロバイダの実行において「doOCR」を1番目に呼び出す旨を定義している。Inputタグ633は、「doScan」の入力に関する定義で、「Document」形式のデータをＩＤが「foo」のデータから受け取ることを示している。ＩＤが「foo」のデータは、Outputタグ627で定義した「doScan」の出力データである。つまり、ＯＣＲプロバイダは、スキャンプロバイダのスキャンデータをDocument形式で受け取るということを定義している。Outputタグ634は、「doOCR」の出力に関する定義であり、type属性で出力形式が「String（文字列）」である旨と、id属性で出力データを一意に特定するＩＤが「bar」である旨を定義している。

ＦＰ640タグは、no属性とid属性で、4番目に実行する機能プロバイダがＦＴＰ送信プロバイダであることを定義している。FPタグは機能プロバイダを、FPタグ620、630のようにtype属性を使って機能タイプで指定することもできるし、FPタグ640のようにid属性を使って一意に指定することもできる。

Inputタグ641は、ＦＴＰ送信プロバイダの「doSend」呼び出しの入力に関する定義で、「Document」をＩＤが「foo」のデータ、つまり「doScan」の出力から受け取ることを示している。Inputタグ642も、同様にＦＴＰ送信プロバイダの「doScan」呼び出しの入力に関する定義で、「String」をＩＤが「bar」のデータ、つまり「doOCR」の出力から受け取ることを示している。

Inputタグ641は、ＦＴＰ送信プロバイダの「doSend」呼び出しの入力に関する定義で、「Document」をＩＤが「foo」のデータ、つまり「doScan」の出力から受け取ることを示している。Inputタグ642も、同様にＦＴＰ送信プロバイダの「doScan」呼び出しの入力に関する定義で、「String」をＩＤが「bar」のデータ、つまり「doOCR」の出力から受け取ることを示している。

ＦＰ650タグは、no属性とtype属性で、3番目に実行する機能プロバイダがプレビュープロバイダであることを定義している。FPタグは機能プロバイダを、FPタグ620、630のようにtype属性を使って機能タイプで指定することもできるし、FPタグ640のようにid属性を使って一意に指定することもできる。

さらに、exec_kind属性で、プレビュープロバイダの動作種別を定義している。本定義は、プレビュープロバイダが実行する時に、その実行を必須としないことを"off"と指定することで示している。本実施形態では、実行必須を指定する場合は、exec_kind属性を定義しない、もしくは、exec_kind属性を定義した上で指定するデータに空白（ブランク）を指定することで実現する。この例に限らず、属性を使って、実行する際の動作種別を、必須にするか、もしくは必須以外と指定できる方法は全て、本発明の技術的範囲に含まれる。

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

図８は、本実施形態を示す情報処理装置の制御方法を説明するフローチャートである。本例は、図５に示したシーケンス例におけるS530からS551の処理の詳細手順である。なお、各ステップは、ＭＦＰ101のＨＤＤ214に記憶されているプログラムを、ＣＰＵ211がＲＡＭ213に読み出し、解析、実行することで実現される。

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

次にワークフロー処理部430は、ワークフロー定義ファイル440からFPタグで定義された機能プロバイダの定義を実行順に1つ取り出す（S803）。ここで、実行順とは、FPタグのno属性に定義された数字の若い順を意味する。

次にワークフロー処理部430は、次に実行すべき機能プロバイダがあるかどうかを判断し、次に実行すべき機能プロバイダがあると判断した場合、処理をS805へ進める。
一方、ワークフロー処理部430は、次に実行すべき機能プロバイダがないと判断した場合（最後の機能プロバイダまで取得し終えたら）、ワークフローの実行を終了する（S804）。

次にワークフロー処理部430は、FPタグ0およびFPタグの子要素であるFPタグのexec_kind属性から動作種別の定義を取得する（S805）。次に、ワークフロー処理部430は、S805で取得した、動作種別の定義が機能プロバイダの実行が「必須」以外かを判断する処理を行う（S806）。

本実施形態では、ワークフロー処理部430は、ワークフロー定義ファイル440で、標準スキャンプロバイダ411のFPタグ620、組込OCRプロバイダ413のFPタグ630、プレビュープロバイダ416のFPタグ650、ＦＴＰ送信プロバイダ415のFPタグ640に記載される可能性のあるexec_kind属性の記載内容を判断する。本実施形態の場合、ワークフロー処理部430は、図６に示したように、プレビュープロバイダ416のFPタグ650のみ、実行を必須としないことを示す、exec_kind属性に「off」という記載があるため、処理をS807に進める。一方、S806でワークフロー処理部430が動作種別の指定が必須であると判断した場合、その他の標準スキャンプロバイダ411、組込OCRプロバイダ413、ＦＴＰ送信プロバイダ415の場合、処理をS816に進める。

S807では、ワークフロー処理部430は、機能プロバイダの検索条件を取得し、機能プロバイダ検索部423に機能プロバイダの検索を指示する。なお、機能プロバイダ検索部423が行う本処理のフローは、本発明とは関連が薄いので説明の詳細を割愛する。

次に、ワークフロー処理部430は機能プロバイダ検索部423から検索結果を受け取り、検索条件に一致する機能プロバイダがあるかどうかを判断する（S808）。ここで、ワークフロー処理部430は、検索結果に一致する機能プロバイダがあると判断した場合、処理をS809へ進める。
一方、S808でワークフロー処理部430が検索に一致する機能プロバイダがないと判断した場合、S810で、ワークフロー処理部430は、機能プロバイダに含まれるActionタグの取得する処理を省略して、処理をS803に進むめる。本実施形態の場合、図９のソフトウェア構成の例で、プレビュープロバイダ416がＭＦＰ101にインストールされてない場合で、かつ正常に検索されなかったケースが該当する。

次に、ワークフロー処理部430はワークフロー定義ファイル440から処理対象となっているFPタグの子要素であるActionタグを実行順に１つ取り出す（S809）。ここで実行順とは、Actionタグのno要素に定義された数字の若い順を意味する。

S811で、ワークフロー処理部430は、次に処理すべきActionタグがあるかどうかを判断する。ここで、ワークフロー処理部430は、次に処理すべきActionタグがあると判断した場合、処理をS812へ進め、次に処理すべきActionタグがないと判断した場合（最後のActionタグまで取得し終えたら）。処理をS803へ戻す。

S812で、ワークフロー処理部430は、Actionタグの定義に従って、S811の検索結果として取得した機能プロバイダを呼び出す。その際、ワークフロー処理部430は、Actionタグの子要素としてParameterタグまたはInputタグが定義されていれば、その定義に従って、機能プロバイダに入力を与える。
例えば、Inputタグ633はＯＣＲプロバイダの「doOCR」呼び出しの入力に関する定義で、「Document」をＩＤが「foo」のデータから受け取ることを示している。ＩＤが「foo」のデータは、Outputタグ627で定義したスキャンプロバイダの「doScan」の出力データである。ゆえに、ワークフロー処理部430は、自身が保持している「doScan」の出力データを、「doOCR」の呼び出し時に入力データとして与える。その後、ワークフロー処理部430は、処理をS813へ進める。

S813では、ワークフロー処理部430は呼び出した機能プロバイダの実行完了を待ち受ける（S813）。機能プロバイダの実行が完了したら、ワークフロー処理部430は機能プロバイダの出力を、別の機能プロバイダの入力として使用できるようＨＤＤ214またはＲＡＭ213に保存して（S815）、処理をS809へ戻す。
例えば、Outputタグ627はスキャンプロバイダの「doScan」呼び出しの出力に関する定義で、「doScan」の出力である「Document」データを、ＩＤを「foo」として保存する。機能プロバイダの出力を保存したら、ワークフロー処理部430は次の機能プロバイダの定義を取得するために、S809へ処理を進める。
一方、S813で、ワークフロー処理部430は呼び出した機能プロバイダの実行完了を待ち受ける際、S814で、ワークフロー処理部430から呼び出された機能プロバイダは、指示に従って処理を実行して、処理をS815へ進める。
一方、S806で、S806でワークフロー処理部430が動作種別の指定が必須であると判断した場合、処理をS816へ進める」。
そして、ワークフロー処理部430は、機能プロバイダの検索条件を取得し、機能プロバイダ検索部423に機能プロバイダの検索を指示する（S816）。
なお、機能プロバイダ検索部423が行う本処理のフローは、本発明とは関連が薄いので説明の詳細を割愛する。

次に、ワークフロー処理部430は機能プロバイダ検索部423から検索結果を受け取り、検索条件に一致する機能プロバイダがあるかどうかを判断する（S817）。ここで、ワークフロー処理部430は、もし、検索結果に一致する機能プロバイダがあると判断した場合は、処理をS809へ進める。本実施形態では、図４のソフトウェア構成で、ワークフロー定義ファイル440に、標準スキャンプロバイダ411、組込OCRプロバイダ413、プレビュープロバイダ416、ＦＴＰ送信プロバイダ415がＭＦＰ101にすべてインストールされている。したがって、何れかの機能プロバイダが正常に検索された場合にこのステップを実行する。

一方、S817で検索結果に一致する機能プロバイダがないと判断した場合、処理をS818へ処理を進める。S818では、ワークフロー処理部430は、検索に一致する機能プロバイダがなければエラーを通知して、ワークフローの実行処理を終了する。

図９は、図１に示したＭＦＰ101におけるソフトウェア構成図の一例を示す図である。なお、基本的な構成は、図４と同様である。異なる点は、図４におけるプレビュープロバイダ416が図９のソフトウェア構成では、インストールされてないことを示している。

図１０は、ＭＦＰ101上の一連の処理の流れを示す図である。なお、基本的な構成は、図５と同様である。なお、図１０におけるS1030〜S1041は、図５に示したS530〜S541までは同じ処理である。
一方、本実施形態では、S1042で、ワークフロー処理部930は、プレビュープロバイダに関する動作種別（図６に示したexec_kind）を取得する。ここで、取得する種別であるexec_kindでは、プレビュープロバイダが必須とはしないユーザのために、任意であるoffを指定できる。
そこで、ワークフロー処理部930は、ＦＰ no=3でプレビュープロバイダを検索して、exec_kindがoffである。このため、S806、S807へ進んだ場合、図９に示すようにプレビュープロバイダがないと判断される。このため、機能プロバイダ管理部920より、図１０のS1045の通知でプレビュープロバイダがないと通知される。よって、ワークフロー処理部930は、S810でプレビュープロバイダの呼出を省略する（図１０に対応するS1046）。
なお、S1047〜S1051は、図５のS547〜S551と同様である。

以上、第１実施形態では、上記説明した手順により、ワークフロー内の機能プロバイダの実行種別を指定、および、その記載と機能プロバイダがインストールされているかという条件を判断する。これにより、情報処理装置において、実行必須でない機能プロバイダの実行を省略して実行する手段を提供することができる。

このように、ユーザは、情報処理装置に必要のない機能プロバイダをインストールしないことで、ワークフロー内に、機能の実行を望まない機能プロバイダの実行を省略しつつ、ワークフロー全体の正常実行を実現できるようなる。そのため、情報処理装置に必要のない機能プロバイダのインストール作業がなくなり、インストール時におけるユーザによる操作性の煩雑さを軽減できる。

〔第２実施形態〕
本実施形態では、第１実施形態における処理を実行させることをユーザが望んでいるかどうかを確認しながら、作業を行えるために、後述する図１２〜図１４に示すＵＩ画面を操作部219に表示する。以下、その実施形態を第１実施形態との差異を中心に説明する。
図１１は、本実施形態を示す情報処理装置の制御方法を説明するフローチャートである。本例は、図８に示した処理と比較して、一部が異なるフローである。差異の内容は、ユーザが、各機能プロバイダの動作種別を選択しながら実行できる点である。それ以外の、基本的なフローと処理は図８の各処理と同様であるため、差異がある処理にのみ説明を加える。なお、各ステップは、ＭＦＰ101のＨＤＤ214に記憶されているプログラムを、ＣＰＵ211がＲＡＭ213に読み出し、解析、実行することで実現される。なお、S1101〜S1108は、図８に示したS801〜S808と同一である。同様に、S1109〜S1115は、S809〜S815と同一である。

図１１に示すS1110では、ワークフロー処理部430は、検索に一致する機能プロバイダがない場合、機能プロバイダの実行処理を省略するかを、ユーザに選択表示させる。この際、ワークフロー処理部430は、画面（図１２に示す問い合わせ画面）1201を操作部219に表示する処理を行う。ワークフロー処理部930は、ユーザが機能プロバイダの実行を省略するように指示（ボタン1203の押下を受け付ける指示）を受け付けた場合は、処理をS1103に戻す。なお、図１２において、1204はOKボタンである。

また、S1117で、ワークフロー処理部930は、検索結果が取得できないであると判断した場合、処理をS1118へ進める。そして、ワークフロー処理部430は、検索に一致する機能プロバイダがなければエラーを通知する。この際、エラーとして処理を終了するか、エラーだが処理を続行するかをユーザに選択表示させるための画面（図１３に示すフロー処理継続判断を問い合わせる画面）1301を操作部219に表示する処理を行う。なお、1304はOKボタンである。

S1119で、ワークフロー処理部930は、図１３に示す画面において、ユーザがいずれのボタンを押下指示しているかどうかを判断する。ここで、ユーザがエラー終了するためのボタン1303を指示していると判断した場合、処理をS1120に進める。
一方、S1119で、ワークフロー処理部930は、ユーザが一時的に継続するためのボタン1302を指示していると判断した場合は、処理をS1109へ戻す。

また、本実施形態では、S1120でワークフロー処理部930は、S1110で機能プロバイダの実行処理を省略する設定を次回のワークフロー時に利用させるためにこの設定を保存する処理を行う。具体的には、S1120で、ワークフロー処理部930は、ワークフロー定義ファイル440の情報を更新したうえで保存する際、図１４に示すフロー更新情報の保存に関するUI画面1401を操作部219に表示する処理を行う。ユーザは、UI画面1401において、ボタン1402、1403、OKボタン1404を指示することができる。

図１２〜図１４は、本実施形態を示す情報処理装置で表示するＵＩ画面の一例を示す図である。
図１２は、図１１に示したS1110を実行する際に表示されるＵＩ画面の例である。つまり、機能プロバイダの呼び出しを省略するか否かをユーザに選択させるための選択表示を行う。本画面1301は、ＣＰＵ211がＭＦＰ101のＨＤＤ214に記憶されているプログラムを、ＲＡＭ213に読み出して実行することにより、操作部219に画面1201を表示する。

ボタン1202は、ワークフロー定義ファイル440の実行の際に、機能プロバイダの実行を常に行うように指定するためのボタンである。ボタン1203は、ワークフロー定義ファイル440の実行の際に、機能プロバイダの実行をさせないように指定、つまり、実行を省略するように指定するためのボタンである。ボタン1204は、ボタン1202もしくは、ボタン1203の押下状態を一時的に保存するように指定するボタンである。

図１３は、図１１に示したS1118を実行する際に表示されるＵＩ画面の例である。つまり、処理継続もしくは、インストールエラーとして終了させるかをユーザから受付るためのＵＩ画面表示を行う。本画面は、ＣＰＵ211がＭＦＰ101のＨＤＤ214に記憶されているプログラムを、ＲＡＭ213に読み出して実行することにより、操作部219に画面1301を表示する。

図１３において、ボタン1302は、ワークフロー定義ファイル440の実行の際に、ワークフロー定義ファイル440の処理継続を指示させるボタンである。ボタン1303は、ワークフロー定義ファイル440の実行をエラーで終了させるように指示するボタンである。ボタン1304は、ボタン1302もしくは、ボタン1303の押下状態を即時に反映させるボタンである。つまり、ワークフロー処理部930は、ボタン1302が押下されていた場合は、実行を継続するが、実行を継続する状態を保存しない。また、ワークフロー処理部930は、ボタン1303が押下されていた場合は、ワークフロー定義ファイル440の実行をエラーで終了させる。

図１４は、図１１に示したS1310で生じたデータの保存をＭＦＰ101のＨＤＤ214に保管するか否かを選択するための処理で、S1319を実行する際に表示されるＵＩの例である。本画面は、ＣＰＵ211がＭＦＰ101のＨＤＤ214に記憶されているプログラムを、ＲＡＭ213に読み出して実行することにより、操作部219に画面1401を表示する。

図１４において、ボタン1402は、ワークフロー定義ファイル440に変更を反映するために変更情報を保存することを選択するボタンである。ボタン1403は、ワークフロー定義ファイル440に変更を反映しないために変更情報を保存しないことを選択する指示するボタンである。ＯＫボタン1404は、ボタン1402もしくは、ボタン1403の押下状態を即時に反映させるボタンである。

以上、第２実施形態において説明した手順により、ワークフローの実行中に機能プロバイダの動作種別の判断に際して、ユーザが選択表示をして機能プロバイダの動作を選択しながら、ワークフローの実行情報を選択指示する手段を提供できる。

それゆえ、ワークフローの実行時に、動作種別に応じて、機能プロバイダの動作を制御し、その情報を保存することで、ワークフローを編集するための操作性の煩雑さ（例えば、専用ツールを学習して、使いこなす等）を軽減することが出来る。

以下、第１実施形態、第２実施形態が適用される前提となる具体的な実施例（ビジネス例）を以下に説明する。
ビジネスでワークフローを利用して、ユーザが業務課題の解決を行う場合、大きく３つのワークフローと提供アプローチがあると想定している。
ケース１：「業種業務別ワークフロー」、アプローチ1：「既成品利用」
ケース２：「業種業務別ワークフロー」、アプローチ2：「カスタマイズ対応」
ケース３：「新規ワークフロー」、アプローチ3：「パターンオーダー対応」
各ケースとアプローチについて説明する。
〔第１実施例〕
ケース１：「業種業務別ワークフロー」、アプローチ１：「既成品利用」
まず、ケース１のユーザ想定は、できる限りコスト優先で済ませたいユーザである。ゆえに、「既成品」としての「業種業務別ワークフロー」をユーザに提供する「既成品利用」というアプローチを想定している。

〔第２実施例〕
次に、ケース２のユーザ想定は、業務課題の解決にある程度のコストをかけられるユーザに対するユーザである。ゆえにワークフロー提供者が一部コストをかけて、既成品としての、「業種業務別ワークフロー」をユーザに提供する「カスタマイズ対応」アプローチが想定される。

〔第３実施例〕
最後に、ケース３のユーザ想定は、高い品質を追求するためケース１，２以上のコストを許容できるユーザである。本ユーザ想定は、ユーザ１，２で所望の提供物ことを理解してもそれでもなお提供物を所望するユーザと指定している。ゆえにワークフロー提供者が新規にワークフローを作成するコストをかけて、よりユーザにフィットするワークフローを作る「パターンオーダー」アプローチが想定される。

こうしたケース分類で、ワークフロー提供者が「業種業務別ワークフロー」を準備する際、その業務で平均的に必要であろう機能を事前に追加しておくことが重要である。なぜなら、「業種業務別ワークフロー」では、ケース１とケース２の多くのユーザの業務課題を少ないコストで対応できるようにするためである。
なお、本発明は、ケース２が「業種業務別ワークフロー」で、アプローチ２が「カスタマイズ対応」である場合におけるワークフロー利用の課題を解決することができる。

具体的には、現状の課題として、ユーザは、「業種業務別ワークフロー」の一部の機能を利用したくないが、全体のフローとしては正常実行するようにしたいケースがある。
その理由は、先も述べたが「業種業務別ワークフロー」、特定のユーザには不要な部品が含まれる可能性が多いためである。
しかし、この場合、ワークフロー提供者がその実現をするには、ワークフローの編集が必須となるため操作性が煩雑になるという課題があった。

なぜなら、ワークフロー定義ファイルに機能プロバイダが指定された場合、情報処理装置にインストールされたか否かでしか実行するか否かを切り替えることができない。そのため、常に全ての機能プロバイダを事前にインストールするか、または、ワークフロー提供者が、新たに別のワークフローを編集する必要があった。このため操作性が煩雑になる傾向があった。
これに対して、上述した第１実施形態および第２の実施形態に示す課題解決手段をユーザに提供することにより、ケース２に対して、ワークフロー提供者はよりユーザフレンドリなワークフローを実行でるソフトウエアをユーザに提供できる。

なお、第１実施形態、第２実施形態では、ワークフローを構成するものとして、ワークフロー処理部が、機能プロバイダを呼び出す構成で説明したが、拡張ソフトであるアプリがワークフロー処理部の役割を行い、他の拡張ソフトを呼び出す構成であってもよい。

本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステムまたは装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサがプログラムを読み出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えばＡＳＩＣ）によっても実現可能である。
更に、次の場合も含まれる。記憶媒体から読出されたプログラムコードが、コンピューターに挿入された機能拡張ボードやコンピューターに接続された機能拡張ユニットに備わるメモリに書き込まれている。そして、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって上述した実施形態の機能が実現される。

101 MFP
430 ワークフロー処理部
440 ワークフロー定義ファイル

Claims (7)

1. 情報処理装置であって、
   異なる機能処理を行う機能プロバイダを記憶する記憶手段と、
   作成されたワークフロー定義ファイルに従い実行する機能プロバイダを検索する検索手段と、
   前記検索手段が前記ワークフロー定義ファイルに従い機能プロバイダを検索する場合、前記ワークフロー定義ファイルに記述された機能プロバイダの動作種別がユーザの指定により省略できる情報に設定されているかどうかを判断する判断手段と、
   前記ワークフロー定義ファイルに記述された機能プロバイダの動作種別がユーザの指定により省略できる情報であると判断した場合で、かつ、前記検索手段が当該機能プロバイダを前記記憶手段から検索できない場合、当該機能プロバイダを含まない機能プロバイダを用いてワークフローを実行する実行手段と、
   を備えることを特徴とする情報処理装置。
2. 前記ワークフロー定義ファイルに記述された機能プロバイダの動作種別がユーザの指定により省略できる情報であると判断した場合、当該機能プロバイダを実行の可否をユーザから受け付ける第１の受付手段を備えることを特徴とする請求項１に記載の情報処理装置。
3. 前記検索手段が当該機能プロバイダを前記記憶手段から検索できない場合、機能プロバイダのインストールエラーを通知する通知手段を備える請求項１に記載の情報処理装置。
4. 前記通知手段が機能プロバイダのインストールエラーを通知した場合、ワークフローを継続して実行する指示を受け付ける第２の受付手段を備えることを特徴とする請求項１に記載の情報処理装置。
5. 前記検索手段が当該機能プロバイダを前記記憶手段から検索できない場合、読み込んだワークフロー定義ファイルを省略された機能プロバイダによるワークフロー定義ファイルに更新する更新手段を備えることを特徴とする請求項１に記載の情報処理装置。
6. 異なる機能処理を行う機能プロバイダを記憶する記憶手段を備える情報処理装置の制御方法であって、
   作成されたワークフロー定義ファイルに従い実行する機能プロバイダを検索する検索工程と、
   前記検索工程が前記ワークフロー定義ファイルに従い機能プロバイダを検索する場合、前記ワークフロー定義ファイルに記述された機能プロバイダの動作種別がユーザの指定により省略できる情報に設定されているかどうかを判断する判断工程と、
   前記ワークフロー定義ファイルに記述された機能プロバイダの動作種別がユーザの指定により省略できる情報であると判断した場合で、かつ、前記検索工程で当該機能プロバイダを前記記憶手段から検索できない場合、当該機能プロバイダを含まない機能プロバイダを用いてワークフローを実行する実行工程と、
   を備えることを特徴とする情報処理装置の制御方法。
7. 請求項６に記載の情報処理装置の制御方法をコンピュータに実行させることを特徴とするプログラム。

Images