JP5368837B2 - サーバ、サーバを含む情報処理システム、サーバの制御方法、及びプログラム - Google Patents

Description

本発明は、画像処理装置と連携して処理を行うサーバ、サーバを含む情報処理システム、サーバの制御方法、及びプログラムに関するものである。

近年、スキャナ、プリンタ、複写機、ファクシミリ等の機能を備えた複合機でもウェブ対応が進んできている。例えばウェブブラウザを搭載する複合機であって、その複合機の操作パネルからブラウザを操作してウェブサーバへアクセスし、サーバのフォルダや文書を参照したり印刷できる複合機も出現している。

またオフィスでは、ユーザの業務簡略化を目的として、複合機やウェブサーバで提供される種々のサービスを複数組み合わせた処理フローを定義できるネットワークシステムも提案されている。このようなシステムでは、複合機でスキャンやＦＡＸ受信等の操作で入力されたデータを、そのネットワークの複数の機器により処理できる。このような複数の機器による複数の処理を実行させると、いずれかの処理でエラーが発生するケースが考えられる。いま例えば、いくつかの処理が終了した後でエラーが発生した場合、最初から処理をやり直すと、それまでの処理が無駄になってユーザの利便性を損ねてしまう。そこでエラーが発生したジョブのデータを複合機に保存しておき、後でユーザの指示により、そのジョブを再開できるような機能が望まれる。例えば特許文献１の画像形成装置では、印刷ジョブの実行中にエラーが発生した時だけでなく、操作パネルから印刷のキャンセル指示が入力されると印刷途中のデータを複合機内で保存し、その印刷ジョブの再開をユーザが指示できるようになっている。

また特許文献２は、ジョブの実行途中でエラーが発生した場合に、中間生成データを再利用する前提で保存する際、そのデータに対する安全性を向上させるために電子署名を付与して複合機に保存するシステムを提案している。更に特許文献３には、複数のサービスが連携した処理を実現するシステムにおいて、処理を構成するサービスの実行時にサービスが実行不可となった場合、その実行不可のサービス及びそれ以降のサービスを連携して処理するシステムが提案されている。

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

従来の技術では、処理フローが再開されることを前提として中間生成データを保持し、「実行不可となったサービス」と「それ以降のサービス」の実行を可能にしている。しかし、エラーの原因となる問題が入力データにある場合には、中間生成データは再利用できず、通常は、再スキャンなど最初の入力操作からやり直す必要がある。しかし、紙（原稿）のスキャンは手間のかかる作業であり、エラーが発生する度にスキャンを実行するのは非効率である。

また、中間生成データの全てに問題があるわけではなく、一部のデータだけ差し替えれば問題ないような場合もある。この場合、保管されたデータを手動で差し替えて処理を再開する方法も考えられるが、差し替えデータと再利用データの特定や、処理の再開準備は手動で行わなくてはならず、複雑な操作を必要とし、ユーザが混乱する危険性が高い。

また更に、操作している複合機がその能力を保持していない場合もあり得る。例えば、一定以上の解像度をもつデータや、カラーデータが必要な処理がある場合、その処理条件に適合するデータを生成できる能力を保持しない複合機では、データを差し替えても処理を再開することができない。このように、処理フローの中でエラーが発生した場合、処理を再開する際に、単に中間生成データを利用した処理を再開するだけでは解決できない、もしくは利便性を損なうという問題がある。

本発明の目的は、これら従来技術の問題点を解決することにある。

本願発明の特徴は、サーバと画像処理装置とが連携して処理を行っているときにエラーが発生した場合、ユーザによる処理の再開を容易にできることにある。

また本願発明は、エラーの内容に応じて、その処理を再開するための条件を判断して、ユーザに対して適切な再開条件を提示することにより、ユーザが混乱することなく処理を再開できることにある。

上記目的を達成するために本発明の一態様に係るサーバは以下のような構成を備える。即ち、
画像処理装置と連携して処理を行うサーバであって、
前記画像処理装置にＵＩ情報を送信する送信手段と、
処理の途中でエラーが発生した場合に、当該エラーが発生した装置及び当該エラーの原因を取得する取得手段と、
前記エラーが発生した装置が前記画像処理装置であって、前記エラー発生の後の処理要求が当該画像処理装置から発行され、前記エラーの原因が前記画像処理装置で処理される原稿に起因するときは、前記画像処理装置が前記エラーの原因を解消していることを条件に、前記エラーが発生した原稿を差し替えるように処理の流れを定義する手段と、を備え、
前記送信手段は、前記画像処理装置からの処理要求が前記エラー発生の後の処理要求である場合は、前記取得手段により取得した前記エラーが発生した装置及び前記エラーの原因に基づいて定義された処理の実行を指示するためのＵＩ情報を前記画像処理装置に送信することを特徴とする。

本発明によれば、サーバと画像処理装置とが連携して処理を行っているときにエラーが発生した場合、ユーザによる処理の再開を容易にできる。

また本発明によれば、エラーの内容に応じて、その処理を再開するための条件を判断して、ユーザに対して適切な再開条件を提示することにより、ユーザが混乱することなく処理を再開できる。

本発明の実施形態に係る情報処理システムの構成図である。 実施形態に係るＰＣ及びサーバの構成を示すブロック図である。 実施形態に係る複合機のハードウェア構成を説明するブロック図である。 本実施形態に係る複合機のソフトウェア構成を示すブロック図である。 実施形態に係る情報処理システムの全体を制御する、サーバで動作するソフトウェアの構成図である。 実施形態に係る情報処理システムのフロー定義情報の一例を示す図である。 本実施形態に係る情報処理システムで利用するサービスの概念図である。 実施形態に係る情報処理システムで連携するサーバや複合機が提供できるサービス情報の一例を示す図である。 本実施形態に係る情報処理システムにおいて、各サービスから取得できる動作ログの一例を示す図である。 実施形態に係る情報処理システムの動作ログとして取得できる原因コードの一覧を示す図である。 本実施形態に係る情報処理システムにおいて、複合機から入力したデータを複合機とサーバが連携した処理フローを実行する際のフローチャートである。 ステップＳ３で複合機からのアクセス要求があったとき、前回エラーによって処理が終了している場合の処理を説明するフローチャートである。 ステップＳ２５で生成されたフローを単純再開する項目を含むＵＩ情報がステップＳ２６で配信された後、アクセス元の複合機或はＰＣでフロー再開ＵＩの表示・実行指示が行われた場合のフローチャートである。 本実施形態に係る複合機から入力したデータを複合機とサーバが連携した処理フローを実行する際のフローチャートである。 本実施形態に係る情報処理システムにアクセスした際に配信されるＵＩ情報の一例を示す図である。 本発明の実施形態に係る情報処理システムにおけるデータ差し替えフロー定義情報の一例を示す図である。

以下、添付図面を参照して本発明の実施形態を詳しく説明する。尚、以下の実施形態は特許請求の範囲に係る本発明を限定するものでなく、また本実施形態で説明されている特徴の組み合わせの全てが本発明の解決手段に必須のものとは限らない。

図１は、本発明の実施形態に係る処理フロー実行システム（情報処理システム）の構成図である。このシステムは、例えば複合機３０から入力される画像データ（或は文書データ）に対して種々の処理をそれぞれ行う複数のサービスを連携処理できるシステムである。このサービスには、印刷、スキャン、ＦＡＸ送受信、コピー、メールの送受信、ストレージ（ファイリング）などが含まれる。

このシステムでは、互いにネットワーク４０を介して接続されたウェブアプリケーションを実行するウェブアプリケーションサーバ２０（以下、サーバ）と、ブラウザを介してアクセスするクライアントＰＣ（以下、ＰＣ）１０と、複合機３０とを有している。尚、ここではこれら機器しか示していないが、本発明は更に多くのスキャナ、プリンタ、ＰＣ等が含まれていても良いことはもちろんである。

尚、本実施形態に係る情報処理システムは、ＰＣ１０のユーザＡがＰＣ１０のブラウザを介してアクセスする構成、及び、複合機３０のユーザＢが複合機３０の操作パネルを介してアクセスする構成としている。しかし、図示しない専用のクライアントアプリケーションをこのＰＣ１０や複合機３０に配置し、ユーザＡ及びユーザＢがそれらを操作する構成であっても構わない。この場合、サーバ２０は、単なるアプリケーションサーバであってもよい。従って、本実施形態では、少なくともサーバ２０と画像処理装置（ＭＦＰ）３０とをネットワーク４０を介して接続し、サーバ２０と画像処理装置（複合機）３０或はＰＣ１０とが連携して処理を行う情報処理システムについて説明する。

図２は、本発明の実施形態に係るＰＣ１０及びサーバ２０のハードウェア構成を示すブロック図である。尚、このハードウェア構成は、一般的な情報処理装置のハードウェア構成に相当するものとし、本実施形態のクライアントＰＣ１０及びサーバ２０には一般的な情報処理装置のハードウェア構成を適用できる。

ＣＰＵ１００は、ＲＯＭ１０２のプログラム用ＲＯＭに記憶された、或いはハードディスク等の二次記憶部１０９からＲＡＭ１０１にロードされたＯＳやアプリケーション等のプログラムを実行する。ＲＯＭ１０２は更に、各種設定値などを記憶するデータＲＯＭを含んでいる。ここでＯＳとはコンピュータ上で稼動するオペレーティングシステムの略語である。後述する各フローチャートの処理は、このＲＡＭ１０１にロードされたプログラムの実行により実現できる。ＲＡＭ１０１は、ＣＰＵ１００の主メモリやワークエリア等として機能する。キーボードコントローラ１０３は、キーボード１０７や図示しないポインティングデバイスからの入力を制御する。ディスプレイコントローラ１０４は、表示部１０８への表示を制御する。ディスクコントローラ１０５は、各種データを記憶するハードディスク（ＨＤ）やフロッピー（登録商標）ディスク（ＦＤ）等の二次記憶部１０９へのデータアクセスを制御する。ＮＣ１０６はネットワーク４０に接続され、ネットワーク４０に接続された他の機器との通信制御処理を実行する。

図３は、本実施形態に係る複合機３０のハードウェア構成を説明するブロック図である。この図３で示されるハードウェア構成は、一般的な複合機のハードウェア構成に相当するものとし、本実施形態の複合機として適用できる。

ＣＰＵ３００は、この複合機３０全体の動作を制御し、スキャナ部３０８やプリンタ部３０２と接続してスキャンやプリント等の機能を実現する。またＣＰＵ３００は、ネットワーク４０を介して他の複合機やＰＣ等の外部機器と接続してデータの送受信を実現している。また公衆回線(PSTN)にも接続してＦＡＸ機能を実現している。それらの機能をユーザに提供するためのインターフェースとして操作部３０９と接続している。尚、操作部３０９がタッチパネルで構成されているとときは、操作部３０９と表示部３０１とは一体に構成される。メモリ３０４はＲＡＭ及びＲＯＭを含み、ＲＡＭはＣＰＵ３００が動作するためのシステムワークメモリとして使用される。大容量記憶部３０５は、ＯＳや各種アプリケーションを記憶しており、ここに記憶されているプログラムは実行時にメモリ３０４のＲＡＭにロードされ、ＣＰＵ３００の制御の下に実行される。ネットワークインターフェース３０６はネットワーク４０と接続し、このネットワーク４０に接続された他の複合機やＰＣ等の外部機器と情報の入出力を行う。このシステムは、ネットワーク通信プロトコルとしてＴＣＰ／ＩＰをサポートし、外部機器ともＴＣＰ／ＩＰ通信プロトコル上に従って通信を行うものとする。システムバス３０７は、ＣＰＵ３００と上述した各部とを接続している。

本実施形態の特徴である、ジョブの再開時にデータの編集等があることをユーザに通知する方法は、操作部３０９の表示部３０１にメッセージを表示することによって行われる。

図４は、本実施形態に係る複合機３０のソフトウェア構成を示すブロック図である。尚、これらソフトウェアは、図３の大容量記憶部３０５に格納されている。

ＵＩ制御マネージャ５０１は、表示部３０１及び操作部３０９を制御するソフトウェアで、ユーザの指示を下層のモジュールに伝えたり、下層からの情報を表示部３０１及び操作部３０９を含むＵＩに表示する。ネットワーク制御マネージャ５０２は、ネットワーク４０からの指示や情報を受け取ったり、ＣＰＵ３００からの指示や情報をネットワーク４０に送信する。５０３〜５０５は、ＵＩ制御マネージャ５０１やネットワーク制御マネージャ５０２からの指示を受け、ジョブマネージャ５０８にジョブを実行させるためのジョブファイルを作成してジョブマネージャ５０８に送信するアプリケーションである。５０３はコピー処理を行うコピーアプリケーション、５０４はファクシミリの送受信を行うＦＡＸアプリケーション、そして５０５は原稿を読み取るスキャンアプリケーションである。ジョブアプリケーション５０６は、予め保存されたジョブファイルをＵＩ制御マネージャ５０１からの指示によりジョブマネージャ５０８に実行させる。

共通インターフェース５０７は、ジョブマネージャ５０８の機器依存部分を吸収するための共通インターフェースである。ジョブマネージャ５０８は、共通インターフェース５０７から受け取ったジョブ情報を整理し、下層の機器に密着した制御マネージャに伝達する。このジョブマネージャ５０８は、ローカルコピーであればスキャンマネージャ５０９とプリントマネージャ５１０を起動する。またＬＩＰＳやポストスクリプト等のＰＤＬプリントでは、ＰＤＬマネージャ５１２とファイルマネージャ５１３とプリントマネージャ５１０を起動する。このようにジョブマネージャ５０８は、ジョブに応じて各制御マネージャの起動、同期、終了等の処理も行う。またジョブアプリケーション５０６より送られた複数の処理が組み合わせられたジョブも、このジョブマネージャ５０８で処理される。またジョブ実行時のエラー処理の制御やジョブの動作ログの記録も、このジョブマネージャ５０８によって行われる。ファイルマネージャ５１３は、ジョブで使用される画像データやジョブファイルを大容量記憶部３０５に保存したり、そこから取り出す処理を行っている。また大容量記憶部３０５に保存されたデータをネットワーク４０へ送信する処理等も、このジョブマネージャ５０８で制御される。

図５は、本発明の実施形態に係る情報処理システムの全体を制御する、サーバ２０で動作するソフトウェアの構成図である。このソフトウェアは、サーバ２０の二次記憶部１０９に記憶されているプログラムで、適宜サーバ２０のＲＡＭ１０１にロードされサーバ２０のＣＰＵ１００の制御の下に実行される。

メイン制御部６００は、本発明の実施形態に係る情報処理システムの全体を制御し、後述する各部に対する指示、管理を行う。データ送受信部６０１は、ＰＣ１０或は複合機３０でユーザがブラウザを介して出した命令を受け取り、またメイン制御部６００より指示された結果をＰＣ１０或は複合機３０に返答する。またメイン制御部６００よりの指示によっては複合機３０への命令を送信する。セッション記憶部６０２は、ＰＣ１０或は複合機３０において、ユーザがブラウザを介してこの情報処理システムにアクセスすると、同一ユーザからのアクセスであることを示すためのセッション情報を生成する。更に、ユーザが、この情報処理システムへのアクセスをやめる（ログアウト）か、もしくは自動タイムアウト等でセッションが切れるまでの間、繰り返し使用する各種情報をセッション情報と関連付けて保持する。ウェブＵＩ生成部６０３は、メイン制御部６００より指示を受けて、状況に応じたウェブＵＩ情報（HTML）を生成する。ここで、ウェブＵＩ生成部６０３が生成するウェブＵＩ情報は、ＨＴＭＬだけに限定するものではなく、JavaScript等のスクリプト言語で構成されても良い。

ユーザ情報操作部６０４は、メイン制御部６００からの指示に従って、ユーザ情報記憶部６０５に保存されている、この情報処理システムにアクセス可能なユーザ、及びユーザ属性の抽出、編集等の操作を行う。ここでユーザ情報の管理は、この情報処理システム独自の管理ではなく、ユーザ情報記憶部６０５の役割を、既知のActive Directory，LDAPなどが担うものとして、ユーザ情報操作部６０４が連携して行っても構わない。フロー定義操作部６０６はフロー定義の作成や編集を行い、フロー定義／状態格納部６０７へのフロー定義情報の格納や削除も行う。尚、フロー定義情報とは、複合機３０で提供されるサービスとサーバ２０で提供されるサービスのいくつかを一連の流れで順次実行するように定義する情報である。

図６は、本発明の実施形態に係る情報処理システムにおけるフロー定義情報の一例を示す図である。尚、この図６の説明は後述する。

このように本実施形態に係るフロー定義情報は、例えば図６に示すような形式で、サーバ２０から各サービスをから呼び出すためのインターフェース情報と、サービスの呼び出し順序、各サービス間でやり取りされるデータ等の情報を含む。尚、ここでいうサービスとは、外部からの要求に応じてデータに関する利用可能な機能をいう。例えば、コピー、プリント、スキャン、ＦＡＸ転送、メール送信、データベースやファイルシステムといったレポジトリへの保存、ＯＣＲ処理、黒点除去等のノイズ除去処理などが該当し、特に限定されるものではない。

フロー制御部６０８は、メイン制御部６００からの指示と、指定されたフロー定義情報に従って順次サービスを実行するフローの実行制御を行う。フロー制御部６０８は、フローを開始する際、最初にその実行フローを識別するために一意なシーケンスＩＤを発行し、サービスを実行する際には実行指示とともに必ずこのシーケンスＩＤをサービスへ渡す。シーケンスＩＤは一意に識別できればその形態は問わないが、他のシステムとも競合する可能性が極めて少ないＧＵＩＤ等を使用するのが一般的である。またフロー制御部６０８は、サービスの実行状況の監視及び管理も行う。例えば、現在実行中のフロー定義情報がどれであるか、またそのフロー定義情報の中のどのサービスを現在実行中なのか、そのサービスはいつ開始したのかというような情報をフロー定義／状態格納部６０７に格納及び管理する。

更に、処理フローの途中でエラーが発生した場合には、フロー制御部６０８がエラー発生時の情報（対象のフロー定義情報、シーケンスＩＤ、処理ユーザ情報、エラーが発生したサービスの情報、エラー発生時刻）をフロー定義／状態格納部６０７に格納する。

ウェブアプリケーションサービス部６０９、データ一時保管領域６１０、動作ログ格納部６１１は、サーバ２０から提供される「サービス」を構成するコンポーネントであるが、これらのコンポーネントはサービスとして外部サーバに存在してもよい。その場合にはメイン制御部６００の指示は、データ送受信部６０１を経由して、その外部サーバに送信される。ウェブアプリケーションサービス部６０９は、実行サービスの処理の実体であり、サービスの実行にあたって生成したデータは、データ一時保管領域６１０へ保存され、内部動作のログは、動作ログ格納部６１１へ保存される。動作ログ収集・解析部６１２は、メイン制御部６００からの指示に従って、特定のシーケンスＩＤで特定された動作ログを、指定されたサービスから収集し、エラー状況の解析（発生原因、中間生成物の確認など）を行う。サービス情報確認部６１３は、複合機３０やサーバ２０に対してその能力の問い合わせを行い、提供されるサービスの詳細を確認する。取得できるサービス情報は、例えば図８（詳細は後述）のような形態で、ホスト名や提供しているサービスの一覧、各サービスのインターフェース、各サービスの入出力条件などを含む。

次に図６を参照して、本実施形態に係る情報処理システムのフロー定義情報の一例を説明する。

サーバ２０から呼び出すサービスを＜Service＞タグで定義しており、その属性としてサービス呼び出し順序（order属性）や呼び出しプロトコル（protocol属性）が指定されている。また、サービスを呼び出す際にやり取りされるデータは、＜input＞タグと＜output＞タグとで規定されている。図６では１番目から４番目の順序で呼び出されるサービスが７０１〜７０４で定義されている。

例えば、７０１は、１番目に呼び出されるサービスの定義を示している。このサービスは、プロトコルがウェブ「Service(protocol="WS")」であり、複合機３０（＜location type="MFP"／＞）で提供されているスキャンサービス（＜name ="SCAN"／＞）である。図６の例では、複合機３０のサービス（location type="MFP"）と、３番目と４番目で規定されたサーバ２０で提供されるサービス（location type="Server"）とが混在している。しかし、必ずしも混在させて定義する必要はなく、サーバ２０のサービスだけを列挙した定義があってもよい。

１番目のサービスの入力パラメータ（＜input＞タグ）７０５で、Ａ４サイズ、解像度自動(auto)が指定されている。また出力パラメータ（＜output＞タグ）７０６で、指定のファイルパスに結果を保存するように定義されている。因みに、＜output＞タグで、「scan*.tiff」と記述されているが、これは複数ファイルある場合は、＊に序数が入って、「scan1.tiff，scan2.tiff，...」というようにファイル名が出力されることを意図している。

基本的にこれらのフロー定義情報は、フロー定義／状態格納部６０７に格納されたものを取り出してそのまま利用される。しかし、＜output＞タグ等の一部の情報に関しては、フロー実行時にフロー制御部６０８が動的に変更してフローを実行するものもある。動的に変更されたフロー定義情報も、フローの実行状態情報としてフロー制御部６０８がフロー定義／状態格納部６０７へ保存する。

尚、図６において、２番目に呼び出されるサービスは、複合機３０による黒点除去処理である。また、３番目に呼び出されるサービスは、サーバ２０による、黒点除去処理の後の「scan*.tiff」に対する文字認識処理と、その結果をテキスト文書（ocr*.txt）にする処理である。そして、４番目に呼び出されるサービスは、サーバ２０による文字認識の結果である文書（ocr*.txt）をフォルダ１（Folder1）に格納する処理である。

上述したように、この情報処理システムで連携して利用するサービスは、外部からの要求に応じて実行されるデータの処理に関するもので、特に限定されるものではない。しかし、この情報処理システムで統合管理するために、そのインターフェースを規定するのが通常である。本実施形態においては、サービスインターフェースを図７（Ａ）（Ｂ）に示すような形で規定する。

図７（Ａ）（Ｂ）は、本実施形態に係る情報処理システムで利用するサービスの概念図である。

図７（Ａ）において、サービス８００は、フロー制御部６０８からの実行指示とともに指定されるシーケンスＩＤ８１０を受けて処理を実行し、戻り値（成功／失敗）８１１をフロー制御部６０８に返す。サービス８００は、基本的には入力データ８０１を出力データ８０２へ変換するものである（但し、入力データか出力データのどちらかがない場合もある）。複数のデータが入力データ８０１として指定される場合もあるが、逆に出力データ８０２として複数データが出力されることもある。そして、途中のデータでエラーが発生しても基本的には全ての入力データに対して処理を完了してから戻り値８１１を返すものとする。従って、戻り値８１１は、個々の入力データに対する結果ではなく、サービスとしての結果であり、通常は一つでも処理できないデータがあった場合には「失敗(false)」という戻り値を返す。

またサービス８００は、その実行にあたって個々のデータ処理に対してその結果を動作ログ８１２として残す。

更に図７（Ｂ）に示すように、サービス８００は、動作ログ収集・解析部６１２からログ取得要求とともに渡されるシーケンスＩＤ８２１を受け取って、対象とする動作ログ８２２を返答するインターフェースも備える。この対象動作ログ８２２を返すインターフェースは、サービスごとに持たなくても、複合機全体もしくはサーバ全体として一つ備えていればよい。

図８は、本発明の実施形態に係る情報処理システムで連携するサーバ２０や複合機３０が提供できるサービス情報の一例を示す図である。

この例では、ホスト名が「MFP_Name」である複合機（＜Host name="MFP_Name"／＞）に関する能力を記載している。印刷（PRINT）、黒点除去（RemovingBlackSpot）、スキャン（SCAN）というサービス９０１を外部に公開している。

また、各サービスの能力も記載されており、スキャンサービスにおいて、９０２は，用紙サイズ（＜input name="size"＞）がＡ４，Ａ３，Ｂ５のいずれかであることを記述している。９０３は、解像度（＜input name="resolution"＞）が、「自動（auto）」もしくは５０〜１２００ｄｐｉの範囲を規定している。９０４はカラーモードが「カラー」及び「白黒」が指定可能なことを示している。

このサービス情報は、この情報処理システムと連携する全てのサービス提供元から取得でき、この実施形態では，複合機だけでなくサービスを提供するウェブサーバからも取得可能とする。また図８に示すように、本実施形態においては、サーバ及び複合機単位でサービス情報を取得できるようなシステムを想定しているが、各サービスが個別に情報提供できるような仕組みであってもよい。

図９は、本実施形態に係る情報処理システムにおいて、各サービスから取得できる動作ログの一例を示す図である。この動作ログは、処理名、発生時刻、対象データ、シーケンスＩＤ、結果（成功或は失敗）、原因コード、詳細メッセージ等の情報を含んでいる。

この動作ログは、各サービスから動作ログを取得した時の形態であり、複合機、ウェブアプリケーションサーバでの格納形式は問わない。異なる形態で格納している場合は、動作ログの取り出し時にサービス側で図９に示すような動作ログのデータ形態に変換するものとする。

ここで図９の動作ログからは、シーケンスＩＤが「１０」の２ページ目（同一シーケンスＩＤで２番目に処理された）が文字認識（ＯＣＲ）処理でカラー画像を扱えないため失敗していることが記述されている（原因コードが「２」）。またシーケンスＩＤが「１１」の１ページ目が通信エラーで失敗していることが読み取れる（原因コードが「−１」）。尚、この原因コードについては、図１０を参照して説明する。

図１０は、本発明の実施形態に係る情報処理システムの動作ログとして取得できる原因コードの一例を示す図である。ここで列挙されているエラー原因を示す原因コードは、データの差し替え時に必要な条件を判定する目的で利用するので、複合機で入力する時に、パラメータを変更可能なパラメータ要因のみを列挙している。それ以外のエラー原因（ネットワークエラーやＩ／Ｏエラー等）の場合は、unknown（未知）エラーに分類されて扱われる。この図１０では原因コードとして、上から順に「カラーでない」「白黒でない」「サイズが大きすぎる」「サイズが小さすぎる」「解像度が高すぎる」「解像度が低すぎる」「ＰＤＦでない」「イメージでない」が記述されている。

以下、本発明の実施形態１に係る情報処理システムの各ステップにおける処理について、図１１〜図１４を参照して具体的に説明する。

図１１は、本実施形態に係る情報処理システムにおいて、複合機から入力したデータを複合機とサーバが連携した処理フローを実行する際のフローチャートである。尚、図１１において、複合機３０で実行される処理は、メモリ３０４に記憶されたプログラムに従ってＣＰＵ３００が処理を実行することにより実現される。また、サーバ２０により実行される処理は、ＲＡＭ１０１にロードされたプログラムに従ってＣＰＵ１００が処理を実行することにより実現される。これは以下に説明するフローチャートにおいても同様である。

まずステップＳ１で、複合機３０の操作部３０９を操作してユーザがログインを行い、サーバ２０にアクセスする。

これによりステップＳ２で、サーバ２０は、このアクセス要求（処理要求）を受け付け、このユーザが前回アクセスした際にエラー終了していないかどうかを、フロー制御部６０８がフロー定義／状態格納部６０７に格納してある情報を基に確認する。ここでもし、前回エラー終了していると判断した場合はステップＳ３に進み、エラー対応用のＵＩ情報を生成して複合機３０に配信する。この処理は図１２のフローチャート参照して詳しく後述する。

一方ステップＳ２で、前回エラー終了していないと判断した場合はステップＳ４に進み、ウェブＵＩ生成部６０３が、既に定義されているフロー定義情報を実行するための項目などを含むＵＩ情報を生成して複合機３０へ送信する。この定義されているフローを実行するための項目などを含むＵＩを表現する方法は、一つ一つの定義フローをボタンで表示し、それがユーザにより押下されることで実行されるようにしても良い。また或は、定義されているフローのリストと、そのリストで選択されたフローを実行するボタンを表示する等、様々な方法があるが、その方法に関しては特に限定しない。

また本実施形態では、ステップＳ１でなされる複合機３０からサーバ２０へのアクセス要求は、ＨＴＴＰ通信にて行われることを想定している。これによりサーバ２０は、そのアクセス要求時のＨＴＴＰヘッダに基づいて、アクセス元が複合機であるか、ＰＣ１０であるかを判別できる。尚、アクセス元が複合機３０ではない場合、複合機３０で提供されているサービスが最初に実行されるサービスとして定義されているフローを、そのＵＩに表示しないようにしてもよい。尚、このアクセス元の判断方法は、ＨＴＴＰヘッダ内のUser-Agent情報などを使用して判定するのが通常だが、特定のＩＰアドレス、もしくはサブネットアドレスの場合は複合機であると判断する等、その判断方法に関しては限定しない。

これにより複合機３０は、ステップＳ５で、その配信されたＵＩ情報を基に複合機３０の表示部３０１に表示する。これによりユーザＢは、そのＵＩで目的のフローを選択して実行するように指示する。こうしてユーザＢの指示に従って複合機３０は、このユーザＢの操作に対応するイベントをサーバ２０に通知する。

これによりサーバ２０は、ステップＳ６で、その通知されたイベントを受け取る。そしてフロー制御部６０８が、そのイベントに対応するフローの定義をフロー定義／状態格納部６０７から特定して読み込む。次にステップＳ７に進み、ステップＳ６で特定されたフロー定義情報の個々のサービスに対して、一つのフロー定義情報で規定された処理であることを示すＩＤであるシーケンスＩＤを発行する。これによりステップＳ８〜ステップＳ１０で、そのフロー定義情報に従ってサービスが実行される。即ち、ステップＳ９で、フロー制御部６０８は、フロー定義情報で規定されている個々のサービスに対して、シーケンスＩＤ及び入力データ、出力データを指定しながら実行指示を出力する。そしてステップＳ１０で、サービスの実行時のエラー確認を行い、ステップＳ１１で、全てのサービスを実行するまでステップＳ８〜ステップＳ１１を繰り返し実行する。即ち、フロー制御部６０８は、ステップＳ１１で、実行中のサービスが正常終了と判断した場合はステップＳ８に進み、実行中のフロー定義情報から次に実行すべきサービスを特定して、ステップＳ９からステップＳ１１の処理を繰り返す。

いまステップＳ１０で、フロー制御部６０８がエラーの発生を検知した場合はステップＳ１２に進み、前述したようにフロー制御部６０８はエラー状態情報をフロー定義／状態格納部６０７へ保存する。そしてウェブＵＩ生成部６０３は、その異常終了した旨のＵＩ情報を生成して複合機３０に配信する。これにより複合機３０では、ステップＳ１３で、その配信されたＵＩ情報を受け取って表示部３０１に表示してユーザに提示する。

またステップＳ１１で、全てのサービスを正常に終了するとステップＳ１４に進み、ウェブＵＩ生成部６０３は正常終了時のＵＩ情報を生成して複合機３０に配信する。これにより複合機３０は、ステップＳ１５で、そのＵＩ情報を基に表示部３０１に表示してユーザに提示する。

図１２は、図１１のステップＳ３で、複合機３０からのアクセス要求があったとき、前回エラーによって処理が終了（或は中断）している場合の処理を説明するフローチャートである。

先ずステップＳ２１で、フロー制御部６０８が、前回エラーが発生したサービス提供元が複合機３０か、サーバ２０であるかをフロー定義／状態格納部６０７に保存しているエラー状態情報に基づいて判定する。ステップＳ２１で、複合機３０であると判定した場合はステップＳ２２に進み、フロー制御部６０８は、今回アクセス要求を行っているアクセス元の複合機と、エラーが発生したサービスを提供していた複合機とが同一かどうかを判断する。この判定方法は特に限定しないが本実施形態では、エラー状態情報として保存されているエラー発生サービスの情報にサービス提供元の情報が含まれている。よって、アクセス要求時に送られてくるＨＴＴＰヘッダの内容（ＩＰアドレス等）との比較で判断することを想定している。ステップＳ２２で、同一複合機からのアクセスではないと判断した場合はステップＳ２３に進む。このときは、前回フローで生成した中間生成データが今回のアクセス元の複合機内とは別の複合機に格納されていることを意味している。このような状況の場合、
（Ｉ）ユーザに前回のエラー処理を再開する意図がない
（ＩＩ）何らかの都合で前回利用した複合機が使えない
等の理由が想定できる。従って、この場合はステップＳ２３に進み、その複合機に処理を再開するためのＵＩを表示するのではなく、図１１のステップＳ４と同様に、ウェブＵＩ生成部６０３が通常のフロー実行用のＵＩ情報を生成してステップＳ２６のＵＩ送信（配信）処理に進む。

一方、ステップＳ２１で、前回エラーが発生したサービスの提供元がサーバ２０であると判断されるか、或はステップＳ２２で、今回のアクセス元の複合機と前回エラー発生した複合機とが同一と判定した場合はステップＳ２４に進む。ステップＳ２４では、フロー制御部６０８が、エラーの原因が原稿に起因するものかどうかを判別する。この判別のために動作ログ収集・解析部６１２は、エラー発生元サービスに対して図７（Ｂ）に示したように、シーケンスＩＤを渡してログ取得要求を行い、シーケンスＩＤに対応した対象動作ログを取得する。動作ログを取得した動作ログ収集・解析部６１２は、動作ログに含まれる原因コードを調べる。その際、図１０に示したような原因コード一覧と比較して、unknownでなければ原稿が原因であると特定できるためステップＳ２７に進む。そうでなければステップＳ２４からステップＳ２５に進む。ステップＳ２５では、前回エラーが発生したサービスから処理を再開する項目を含むＵＩ情報をウェブＵＩ生成部６０３が生成する。そしてステップＳ２６に進んで、その処理を再開する項目を含むＵＩ情報を複合機３０に送信する。

ステップＳ２７では、フロー制御部６０８がアクセス要求時のＨＴＴＰヘッダ等を基に、アクセス元が複合機３０であるか、ＰＣ１０であるかを判定する。ここでアクセス要求元がＰＣ１０の場合は、代替原稿を読み込ませることができないためステップＳ２３に進み、通常の処理実行用のＵＩ情報を生成する。

一方、ステップＳ２７で、複合機であると判定した場合は、その能力を確認するためにステップＳ２８に進む。ステップＳ２８では、サービス情報確認部６１３が能力確認要求を出すことでアクセス元の複合機の能力を調べる。能力確認要求の結果として、サービス情報確認部６１３は、例えば図８に示すようなサービス情報を取得し、その情報の中から前回実行されたフロー定義情報の最初に実行されるサービスとその能力を特定する。

例えば、図９に示す動作ログによれば、２ページ目が白黒でなければならないことがわかる。一方、図６のフロー定義情報では、最初に実行するサービスは「スキャン（ＳＣＡＮ）」であり、図８のサービス情報では、この複合機３０のスキャンサービスは、白黒スキャンが可能なことがわかる。よってこの図８のサービス情報を提供する複合機３０は、原稿条件を満たせる（原因が解消されている）と判断できるため、ステップＳ２９へ進む。

具体的な原稿条件としては以下のような条件がある。
（Ａ）カラー／白黒それぞれのスキャンモードの有無
（Ｂ）スキャン可能な色数
（Ｃ）スキャン可能な解像度
（Ｄ）スキャン可能な原稿サイズ
（Ｅ）スキャンイメージの特定フォーマット（ＰＤＦなど）での出力可否
（Ｆ）その複合機がスキャン機能自体を有しているかどうか
また、上記（Ａ）〜（Ｆ）の複合条件の場合もある。

一方、ステップＳ２８で、アクセス元の複合機が原稿条件を満たせないと判断した場合は、原稿データをこの複合機上で差し替えてもこのフロー定義情報を完了できる見込みはないため、ステップＳ２３に進み、通常の処理実行用のＵＩ情報を生成する。またステップＳ２８で、アクセス元の複合機が原稿条件を満たせると判断するとステップＳ２９に進み、フロー制御部６０８は、データ差し替え項目を含むＵＩ情報を生成してステップＳ２６に進む。ここでデータ差し替え項目を含むＵＩ情報とは、以下の（１）から（４）で示す情報を含む、もしくは関連付けられたものである。
（１）データ読み込みサービスに対して、前回エラーが発生したページデータの読み込みを指示（前回エラーが発生した原稿との連続性を保持するため）
（２）データ読み込みサービスに対して、エラー原因から想定される必要な追加原稿条件（カラー／白黒の切り替え、解像度の変更、原稿サイズの変更など）
（３）読み込んだデータに対して、対象フロー定義情報の前回エラーが発生したサービスまでのサービス実行定義（エラー発生までの正常データと、そのデータの取り扱いを決める）
（４）上記（３）で処理されたデータと、前回正常完了したデータに対して、前回実行されなかったサービス（エラーが発生したサービスより後のサービス）のサービス実行定義（未処理のままであるサービス実行定義）
このデータ差し替え項目を含むＵＩ情報に関連付けられた上記（１）から（４）の情報は、本実施形態では図１６に示すように元のフロー定義情報をベースとして、別の一つのフロー定義情報として表すことを想定している。しかし、それぞれ別々の情報として保持してそれらの関連性を保持してもよい。例えば、（１）から（３）に関しては一つのフロー定義情報として生成し、それと前回実行したフロー定義情報をエラーになったサービスorderの番号とともに（フロー定義／状態格納部６０７に）関連付けて保管してもよい。

こうしてフロー制御部６０８は、ステップＳ２３、ステップＳ２５、ステップＳ２９のいずれかで生成したＵＩ情報を、ステップＳ２６でアクセス元の複合機或はＰＣに配信する。

図１６は、本発明の実施形態に係る情報処理システムにおけるデータ差し替えフロー定義情報の一例を示す図である。ここでは例えば前述の図９のシーケンスＩＤ「１０」の２枚目の原稿で発生したエラー（原因コード「２」）の後、サーバ２０がエラー対応用のＵＩ情報を生成して複合機３０に配信する場合で説明する。

図１６と図６とを比較すると明らかなように、この場合は３番目と４番目のサーバ２０で提供されるサービスは変更されていない。

１７０１は、１番目に呼び出されるサービスの定義を示している。プロトコルがウェブ Service(protocol="WS")であり、複合機（＜location type="MFP"／＞）で提供されているスキャンサービス（＜name ="SCAN"／＞）である。図６では、入力パラメータ（＜input＞タグ）で、Ａ４サイズで、解像度自動(auto)が指定されていたの対して、図１６では、カラーモード（Color Mode）と白黒モード（Black & White）が設定されている。これは図９で、２枚目の原稿の読取時に「カラー画像が処理できない」との理由でエラーが発生しているためである。

また出力パラメータ（＜output＞タグ）１７０６で、ファイル名が２枚目の原稿を示す「scan2.tiff」と記述されている。これにり２番目のサービスの黒点除去では、対象ファイルが「scan2.tiff」に変更され、その結果であるファイルも「result2.tiff」に変更されている。

図１３は、図１２のステップＳ２５で生成されたフローを単純再開する項目を含むＵＩ情報がステップＳ２６で配信された後、アクセス元の複合機３０或はＰＣ１０でフロー再開ＵＩの表示・実行指示が行われた場合のフローチャートである。

まずステップＳ３１で、フローを単純再開する項目を含むＵＩ情報に従って、フロー再開ＵＩの表示及び実行指示の操作がアクセス元の端末（ＰＣ１０或は複合機３０）でユーザによって行われると、それに対応するイベントがサーバ２０へ通知される。

これによりサーバ２０は、ステップＳ３２で、その通知されたイベントを受け取り、フロー制御部６０８が、前回エラーになったフロー定義情報を読み込む。次にステップＳ３３に進み、フロー制御部６０８は、再処理用に新たにシーケンスＩＤを発行する。次にステップＳ３４に進み、フロー制御部６０８はフロー定義／状態格納部６０７に格納されている情報から、前回エラーになったサービスを特定する。そしてステップＳ３３で読み込んだフロー定義情報のうち、それ以前のサービス定義情報を読み飛ばしてそのサービスから実行されるようにする。以下、ステップＳ３５〜ステップＳ４２の処理は、前述の図１１のステップＳ８〜ステップＳ１５の処理と同様であるため、その説明を省略する。

図１４は、本実施形態に係る複合機から入力したデータを複合機とサーバが連携した処理フローを実行する際のフローチャートを示すものである。尚、この処理は、図１２のステップＳ２９で生成されたデータ差し替え項目を含むＵＩ情報がサーバ２０から複合機３０に送られ、複合機３０でデータ差し替え項目が入力された場合の処理を示している。即ち、ここでは、前回のエラーの原因がサーバ２０或は複合機３０における原稿条件で、今回のアクセス元である複合機（エラーが発生した複合機と同じ場合を含む）がその原稿条件を満足できる場合に相当している。

先ずステップＳ５１で、複合機３０の操作部３０９で、データ差し替え項目を含むＵＩ情報に基づいてユーザによる実行指示操作が行われると、それに対応するイベントがサーバ２０に通知される。

これによりサーバ２０はステップＳ５２で、その通知されたイベントを受け取り、フロー制御部６０８が、図１６で示すようなステップＳ２９で生成したデータ差し替え実行用のフロー定義情報を読み込む。次にステップＳ５３に進み、フロー制御部６０８は、再処理用に新たにシーケンスＩＤを発行する。以下、ステップＳ５４からステップＳ６１で、そのフロー定義情報に従って順序サービスを実行する。これらステップＳ５４からステップＳ６１の処理は、前述の図１１のステップＳ８〜ステップＳ１５と同様であるため、その説明を省略する。

図１５（Ａ）〜（Ｃ）は、本実施形態に係る情報処理システムにアクセスした際に、サーバ２０から複合機或はＰＣに配信されるＵＩ情報の一例を示す図である。

図１５（Ａ）は、図１１のステップＳ４で、サーバ２０で生成されて複合機３０に配信される、或は図１２のステップＳ２３で生成されてステップＳ２６で複合機３０或はＰＣ１０に配信される通常の処理実行ＵＩ例を示す。この例では、フロー１とフロー２の２つのフローが用意されており、それぞれＵＩ上で、各フローの実行する指示するボタン１６０１，１６０２が表示されている。これらボタンのいずれかが押下されてフローの実行が指示されると、図１１のステップＳ１からサーバ２０によるステップＳ２以降の処理が実行される。

図１５（Ｂ）は、図１２のステップＳ２５で生成されてステップＳ２６で配信されるフローを再開する項目を含むＵＩ例を示している。この場合は、サーバ２０によるエラーで、しかもエラーの原因が原稿条件ではないため、エラーの発生を示すメッセージ「エラーが発生」と、フローの再開を指示するための再開ボタン１６０３が表示されている。また図１５（Ｂ）のキャンセルボタン１６０４が押下されると、図１５（Ａ）のＵＩ画面へ遷移する。ここで再開ボタン１６０３が指示されると、サーバ２０による図１３のステップＳ３２以降の処理が起動される。

図１５（Ｃ）は、図１２のステップＳ２９で生成されてステップＳ２６で配信されるデータ差し替え実行項目を含むＵＩ例を示す。この場合は、エラーの発生場所が複合機３０或はサーバ２０における原稿条件であり、今回のアクセス元が複合機であるため、データの差し替えを行うかどうかを選択できるようにしている。よってこの例では、データ差し替えの実行を指示するデータ差し替えボタン１６０５が表示されている。またキャンセルボタン１６０６が押下されると、図１５（Ａ）に示すＵＩ画面へ遷移する。

図１５（Ｃ）では、図９のシーケンスＩＤ「１０」の２ページ目の原稿で「カラー画像が処理できません」というエラーが発生しているため、「２ページ目の原稿でエラーが発生」と表示されている。ここで「データ差し替え」ボタン１６０５が押されると、サーバ２０により図１４のステップＳ５２以降の処理が実行される。そして図１６のフロー定義情報に従って、複合機３０で読み取られる原稿のデータが、エラーが発生した２ページ目の原稿と差し替えられて処理される。

以上説明したように本実施形態によれば、情報処理システムにおいて、フローの実行時にエラーが発生するか、或は処理がキャンセルされた場合に、できるだけ原稿を読み直さずに効率良く、処理を再開できる。

またエラーの発生場所、発生原因、入力データに求められる条件及びアクセス元の保有する能力等に従って、適切な実行手段（ボタンなど）をユーザに提示できる。これにより、ユーザが混乱することなく処理を再開できるという効果が得られる。

更に、データを差し替える場合には、必要な条件を反映した実行手段を提示するため、ユーザは再開処理に必要な条件を調べることなく、ＵＩに従って処理を再開できるので、利便性を向上させることができるという効果がある。

（他の実施形態）
また、本発明の目的は、以下の処理を実行することによっても達成される。即ち、上述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）が記憶媒体に格納されたプログラムコードを読み出す処理である。

この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施の形態の機能を実現することになり、そのプログラムコード及び該プログラムコードを記憶した記憶媒体は本発明を構成することになる。

Claims (6)

1. 画像処理装置と連携して処理を行うサーバであって、
   前記画像処理装置にＵＩ情報を送信する送信手段と、
   処理の途中でエラーが発生した場合に、当該エラーが発生した装置及び当該エラーの原因を取得する取得手段と、
   前記エラーが発生した装置が前記画像処理装置であって、前記エラー発生の後の処理要求が当該画像処理装置から発行され、前記エラーの原因が前記画像処理装置で処理される原稿に起因するときは、前記画像処理装置が前記エラーの原因を解消していることを条件に、前記エラーが発生した原稿を差し替えるように処理の流れを定義する手段と、を備え、
   前記送信手段は、前記画像処理装置からの処理要求が前記エラー発生の後の処理要求である場合は、前記取得手段により取得した前記エラーが発生した装置及び前記エラーの原因に基づいて定義された処理の実行を指示するためのＵＩ情報を前記画像処理装置に送信することを特徴とするサーバ。
2. 前記エラーの原因が前記画像処理装置で処理される原稿に起因しないときは、前記エラーにより中断した処理を再開するように処理の流れを定義する手段を更に有することを特徴とする請求項１に記載のサーバ。
3. 前記エラーが発生した装置及び当該エラーの原因を対応付けて記憶する記憶手段を更に有することを特徴とする請求項１又は２に記載のサーバ。
4. サーバと画像処理装置が連携して処理を行う情報処理システムであって、
   前記サーバは、
   前記画像処理装置にＵＩ情報を送信する送信手段と、
   処理の途中でエラーが発生した場合に、当該エラーが発生した装置及び当該エラーの原因を取得する取得手段と、
   前記エラーが発生した装置が前記画像処理装置であって、前記エラー発生の後の処理要求が当該画像処理装置から発行され、前記エラーの原因が前記画像処理装置で処理される原稿に起因するときは、前記画像処理装置が前記エラーの原因を解消していることを条件に、前記エラーが発生した原稿を差し替えるように処理の流れを定義する手段と、を備え、
   前記送信手段は、前記画像処理装置からの処理要求が前記エラー発生の後の処理要求である場合は、前記取得手段により取得した前記エラーが発生した装置及び前記エラーの原因に基づいて定義された処理の実行を指示するためのＵＩ情報を前記画像処理装置に送信し、
   前記画像処理装置は、
   前記ＵＩ情報を基にユーザにより指示を入力させるための操作手段と、
   前記操作手段により入力されたユーザの指示に従って前記サーバに処理要求を発行する発行手段と、
   を有することを特徴とする情報処理システム。
5. 画像処理装置と連携して処理を行うサーバの制御方法であって、
   前記画像処理装置にＵＩ情報を送信する送信工程と、
   処理の途中でエラーが発生した場合に、当該エラーが発生した装置及び当該エラーの原因を取得する取得工程と、
   前記エラーが発生した装置が前記画像処理装置であって、前記エラー発生の後の処理要求が当該画像処理装置から発行され、前記エラーの原因が前記画像処理装置で処理される原稿に起因するときは、前記画像処理装置が前記エラーの原因を解消していることを条件に、前記エラーが発生した原稿を差し替えるように処理の流れを定義する工程と、を備え、
   前記送信工程では、前記画像処理装置からの処理要求が前記エラー発生の後の処理要求である場合は、前記取得工程で取得した前記エラーが発生した装置及び前記エラーの原因に基づいて定義された処理の実行を指示するためのＵＩ情報を前記画像処理装置に送信することを特徴とするサーバの制御方法。
6. 請求項５に記載のサーバの制御方法をコンピュータに実行させるためのプログラム。

Images