JP5882837B2 - 情報処理システム、画像形成装置、制御方法およびコンピュータプログラム - Google Patents

Description

本発明は、情報処理システム、画像形成装置、制御方法およびコンピュータプログラムに関する。

サーバコンピュータ側で各種処理を行う形態として、クラウドコンピューティングシステムやＳａａＳ（Software as a Service）という技術が提案されている。クラウドコンピューティングでは、多くのコンピューティング・リソースを利用し、データ変換やデータ処理を分散実行することで、多くのクライアントからの要求を同時に処理することが可能となる。また、クラウドコンピューティングの特徴を活用するため、サーバでの一連の処理を細かく規定されたタスクの連結で実現し、それらを同時並行で処理することで、多数のジョブをスケーラブルに処理するシステムが提案されている。以下では、このようなシステムをクラウドシステムと称する。

クラウドシステムにおいて、コンピュータリソースのスケーラビリティ向上や、クライアントからの要求のピーク時にシステムダウンを防ぐために、タスクの実行処理部が非同期でジョブに含まれるタスクを取得しジョブ処理を実行する形態がある（非特許文献１）。

タイトル : Windows Azure Queue キューストレージのプログラミング，URL : http://go.microsoft.com/?linkid=9734588 ，発行年月:２００８年１２月

タスクの実行処理部を、以下ではバックエンド部と記述する。バックエンド部において、タスクの実行処理中に異常が発生し、長時間ジョブ処理が完了しないような場合に、そのジョブ処理をもう一度実行するために、異常が発生したバックエンド部とは別のバックエンド部に実行させる、リトライの機能の機能が必要となる。タスクの実行処理の異常は、タスクを動作させているコンピュータにハードウェア故障が発生した場合や、タスクのソフトウェアバグなどによって発生する。クラウドシステムにおいて、一定時間ジョブが実行されたままになった場合に、別のバックエンド部でのリトライを実行する手法が提案されている。

しかし、従来のクラウドシステムでは、リトライの機能により他のバックエンド部に対して、ジョブ処理が委譲された場合に、以下のような課題がある。従来のクラウドシステムでは、ジョブ処理を実行中である異常が発生したバックエンド部は、他のバックエンド部にジョブ処理が委譲されたとしても、自分のジョブ処理を実行し続ける。したがって、異常が発生したバックエンド部は、実行中のジョブが終了するまでは次のジョブを処理することができない。その結果、システム全体としてコンピュータリソースを無駄に消費してしまう。

また、ジョブの内容が外部システムに影響を与える処理である場合に、既にジョブ処理を実行中であるバックエンド部と、新たにジョブ処理を委譲されたバックエンド部とが二重に外部システムに影響を与え、システムとしての不整合が生じる。例えば、外部のシステムにデータを保存するようなジョブや、外部のシステムにメッセージを送るようなジョブが、外部システムに影響を与える処理である。

本発明は、上述した課題の少なくとも一つを解決するためになされたものである。本発明は、非同期でジョブに含まれるタスクを取得しジョブ処理を実行するバックエンド部に異常が生じて他のバックエンド部にジョブ処理が委譲された場合に生じうるコンピュータリソースの浪費を防止し、スループットを向上するシステムの提供を目的とする。

本発明の一実施形態の情報処理装置は、ユーザからの要求に応じて発生した複数のタスクから構成されるジョブを管理するジョブ管理部と、処理待ち状態であれば前記ジョブ管理部からタスクを取得し特定のタスク処理を施す複数のバックエンド部と、を有する。前記ジョブ管理部は、さらに、前記ジョブに含まれる各々のタスクの、前記ジョブにおける処理順序を示す処理順情報を記憶する処理順情報記憶部と、前記各々のタスクの処理内容に対応する処理時間と、前記バックエンド部がタスク処理中であることを前記ジョブ管理部に通知する時間間隔である通知時間間隔とを含むタスク情報を記憶するタスク情報記憶部と、前記ジョブに含まれる複数のタスクのうち、現在最先の処理順序のタスクと、前記タスクの状態と、前記タスクを実行中の前記バックエンド部からタスク処理中であることの通知を受けた最終通知時刻に関する情報とを含むジョブ情報を記憶するジョブ情報記憶部とを有する。前記バックエンド部は、前記タスク処理中であることを定期的に前記ジョブ管理部に通知し、前記バックエンド部からタスク要求を受けた前記ジョブ管理部は、前記ジョブ情報記憶部に記憶されたジョブ情報に基づいて、前記タスク要求されたタスクと一致する現在最先の処理順序のタスクの状態が実行中であるかを判断し、前記タスク要求されたタスクと一致する現在最先の処理順序のタスクの状態が実行中である場合に、前記最終通知時刻から所定の時間を経過しているかを判断し、前記最終通知時刻から所定の時間を経過している場合に、タスク処理が完了しなかった前記バックエンド部に対して前記タスク処理を中止するよう命令し、かつ、前記タスク要求を行ったバックエンド部に対して前記実行中のタスク処理を代理で実行するように命令する。

本発明の情報処理システムによれば、非同期でジョブに含まれるタスクを取得してジョブ処理を実行するバックエンド部に異常が生じて他のバックエンド部にジョブ処理が委譲された場合に生じうるコンピュータリソースの無駄を防止することができる。また、本発明の情報処理システムによれば、一連のジョブ処理のスループットを向上させることが可能となる。

本実施形態の情報処理システムの全体構成を示す図である。 クライアント端末、スキャンサービスサーバ群、フローサービスサーバ群、タスクサーバを実現するサーバコンピュータのハードウェア構成図の例である。 クライアント端末と画像形成装置の構成例を示す図である。 スキャンサービスサーバ群の構成例を示す図である。 スキャンチケット作成画面の例を示す図である。 チケット一覧画面の一例を示す図である。 チケット管理ＤＢとテンプレート管理ＤＢの一例を示す図である。 タスクサーバの構成例を示す図である。 フローサービスサーバ群の構成例を示す図である。 ルート管理サービスサーバ群の構成例を示す図である。 ルート情報管理ＤＢの一例を示す図である。 タスク情報管理ＤＢの一例を示す図である。 ジョブ管理サービスサーバ群の構成例を示す図である。 ジョブ情報管理ＤＢの一例を示す図である。 本実施形態の情報処理システムの動作処理の例を説明するシーケンス図である。 タスク取得リクエストに対するフローサービスサーバ群の応答処理の例を説明するフローチャートである。 状態通知に対するフローサービスサーバ群の応答処理の例を説明するフローチャートである。 実施例２における、タスク取得リクエストに対するフローサービスサーバ群の応答処理の例を説明するフローチャートである。

（実施例１）
図１は、本実施形態の情報処理システムの全体構成を示す図である。本実施形態の情報処理システムは、クラウドシステムであって、クライアント端末１０６のユーザに画像処理サービスを提供する。

図１中の情報処理システムは、スキャンサービスサーバ群１０１、フローサービスサーバ群１０２、タスクサーバ１０３、１０４、クライアント端末１０６、画像形成装置１０７、クラウドサービスサーバ１０８を備える。図１に示す例では、タスクサーバは２台であるが、情報処理システムが備えるタスクサーバの数は、２台に限定されない。情報処理システムは、複数の任意数のタスクサーバを備えることができる。

スキャンサービスサーバ群１０１乃至タスクサーバ１０４は、ネットワーク１１０を介して通信可能に接続されている。クライアント端末１０６および画像形成装置１０７と、スキャンサービスサーバ群１０１乃至タスクサーバ１０４とは、ネットワーク１１１およびネットワーク１１０を介して通信可能に接続されている。また、クラウドサービスサーバ群１０８とスキャンサービスサーバ群１０１乃至タスクサーバ１０４とは、ネットワーク１１２およびネットワーク１１０を介して通信可能に接続されている。

タスクサーバ、クライアント端末１０６、画像形成装置１０７、クラウドサービスサーバ群１０８は、複数台設けられている。ネットワーク１１０乃至１１２は、例えば、インターネット等のＬＡＮ、ＷＡＮ、電話回線、専用デジタル回線、ＡＴＭやフレームリレー回線、ケーブルテレビ回線、データ放送用無線回線等である。ＬＡＮは、Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋの略称である。ＷＡＮは、Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋの略称である。ＡＴＭは、Ａｓｙｎｃｈｒｏｎｏｕｓ Ｔｒａｎｓｆｅｒ Ｍｏｄｅの略称である。

ネットワーク１１０乃至１１２が、上述したＬＡＮ乃至データ放送用無線回線の組み合わせにより実現される通信ネットワークであってもよい。すなわち、ネットワーク１１０乃至１１２は、データの送受信が可能であればよい。この例では、本実施形態の情報処理システムは、クラウドシステムであるので、ネットワーク１１０、１１２は、インターネット、ネットワーク１１１は、企業内ネットワークやサービスプロバイダーのネットワークである。

スキャンサービスサーバ群１０１、フローサービスサーバ群１０２、タスクサーバ１０３、１０４は、複数のサーバコンピュータ群を有する。これらサーバコンピュータ群がクラウドサービスサーバ群を構成しており、ユーザに対してクラウドサービスを提供する。

この例では、クライアント端末１０６のユーザからの要求に応じて、画像形成装置１０７がスキャン実行を行って画像データを生成し、生成した画像データをスキャンサービスサーバ群１０１に投入する。スキャンサービスサーバ群１０１は、当該画像データに対応するジョブをフローサービスサーバ群１０２に投入するジョブ投入部として機能する。この例では、ジョブは、複数のタスクから構成される。例えば、ユーザからの要求に従い発行されるジョブがスキャンジョブであった場合、スキャン画像に対し画像処理を行う工程と、画像処理が施されたスキャン画像を保存する工程とが実行されるケースが考えられる。本願発明は、夫々の工程をタスクという単位で区切ることで、１つのジョブを複数のタスクで構成する。この形態のメリットは、複数のタスクを組み合わせることで、多様なジョブ処理を行うことができるという点である。フローサービスサーバ群１０２は、投入されたジョブを管理する。すなわちフローサービスサーバ群１０２は、ユーザからの要求に応じて発生した複数のタスクから構成されるジョブを管理するジョブ管理部として機能する。

タスクサーバ１０３、１０４は、フローサービスサーバ群１０２が管理するジョブに含まれるタスクを非同期で取得要求する。フローサービスサーバ群１０２は、管理しているジョブに含まれる複数のタスクのうち、取得要求元のタスクサーバに対応するタスクであって、処理待ち状態のタスクを、取得要求元のタスクサーバに渡す。タスクを受け取ったタスクタスクサーバは、特定のジョブ処理を施す。タスクサーバは、例えば、処理対象の画像データに対して画像処理を行ったり、ファイル共有機能を提供する他のクラウドサービスサーバ群に対して、画像データを送信する処理を行う。すなわち、タスクサーバは、処理待ち状態であればフローサービスサーバ群１０２からタスクを取得し特定のタスク処理を施すバックエンド部として機能する。

なお、スキャンサービスサーバ群１０１乃至タスクサーバ１０４で構成されるクラウドサービスサーバ群とは異なる他のクラウドサービスサーバ群１０８がインターネット上に公開されており、これらも複数のサーバコンピュータ上にて実行されている。

クライアント端末１０６は、例えば、デスクトップパソコン、ノートパソコン、モバイルパソコン、ＰＤＡ（パーソナルデータアシスタント）等である。クライアント端末１０６が、プログラムの実行環境が内蔵された携帯電話であってもよい。クライアント端末１０６では、Ｗｅｂブラウザ（インターネットブラウザ、ＷＷＷブラウザ、ＷｏｒｌｄＷｉｄｅＷｅｂの利用に供するブラウザ）等のプログラムを実行する環境が内蔵されている。

本実施形態の制御方法は、図１に示す情報処理システムの制御方法である。また、本実施形態のコンピュータプログラムは、この制御方法をコンピュータに実行させる。

図２は、クライアント端末、スキャンサービスサーバ群、フローサービスサーバ群、タスクサーバを実現するサーバコンピュータのハードウェア構成図の例である。クライアント端末１０６、サーバコンピュータは、ＣＰＵ２０２、ＲＡＭ２０３、ＲＯＭ２０４、ＨＤＤ２０５を備える。ＣＰＵは、Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔの略称である。ＲＡＭは、Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙの略称である。ＲＯＭは、Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙの略称である。ＨＤＤは、Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅの略称である。また、クライアント端末１０６、サーバコンピュータは、ＮＩＣ２０９、キーボード２０７、ディスプレイ２０６、インタフェース２０８を備える。ＮＩＣは、Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄの略称である。

ＣＰＵ２０２は、装置全体の制御を行う。ＣＰＵ２０２は、ＨＤＤ２０５に格納されているアプリケーションプログラム、ＯＳ等を実行し、ＲＡＭ２０３にプログラムの実行に必要な情報、ファイル等を一時的に格納する制御を行う。ＯＳは、Ｏｐｅｒａｔｉｎｇ Ｓｕｓｔｅｍの略称である。ＲＯＭ２０４は、記憶手段であり、内部には、基本Ｉ／Ｏプログラム等の各種データを記憶する。ＲＡＭ２０３は、一時記憶手段であり、ＣＰＵ２０２の主メモリ、ワークエリア等として機能する。ＨＤＤ２０５は、外部記憶手段の一つであり、大容量メモリとして機能し、Ｗｅｂブラウザ等のアプリケーションプログラム、サービス群のプログラム、ＯＳ、関連プログラム等を格納している。

ディスプレイ２０６は、表示手段であり、キーボード２０７から入力したコマンド等を表示したりする。インタフェース２０８は、外部装置Ｉ／Ｆであり、プリンタ、ＵＳＢ機器、周辺機器を接続する。キーボード２０７は指示入力手段である。システムバス２０１は、装置内におけるデータの流れを司る。ＣＰＵ２０２乃至インタフェース２０８は、システムバス２０１に接続されている。インタフェースＮＩＣ２０９は、インタフェース２０８およびネットワーク１１０乃至１１２を介して、外部装置とのデータのやり取りを行う。なお、図２中に示す装置構成は一例であり、図２の構成例に限定されるものではない。例えば、データやプログラムの格納先は、その特徴に応じてＲＯＭ２０４、ＲＡＭ２０３、ＨＤＤ２０５のうちのいずれであってもよい。

図３は、クライアント端末と画像形成装置の構成例を示す図である。図３（Ａ）は、クライアント端末１０６の構成例を示す。クライアント端末１０６は、Ｗｅｂブラウザ３０１を備える。Ｗｅｂブラウザ３０１は、スキャンサービスサーバ群１０１（図１）が提供するＷｅｂアプリケーションへのリクエストの送信と、レスポンスの表示等を行う。クラウドサービスを利用するユーザは、クライアント端末１０６のＷｅｂブラウザ３０１を利用して、クラウドサービスを利用する。

図３（Ｂ）は、画像形成装置１０７の構成例を示す。この例では、画像形成装置１０７は、スキャン機能とプリント機能を併せ持つ装置である。なお、スキャンサービスを実現するためには、画像形成装置１０７が、プリント機能のない、スキャン専用装置であってもよい。

画像形成装置１０７は、画像処理ユニット４０１、印刷ユニット４０２、読み込みユニット４０３を備える。画像処理ユニット４０１は、画像処理を実行する。画像処理ユニット４０１は、例えば、印刷設定に応じたプリントデータを生成する。印刷ユニット４０２は、画像処理ユニット４０１によって生成されたプリントデータを媒体（例えば、紙媒体）に印刷出力する。読み込みユニット４０２は、例えば、不図示のスキャン装置を用いて、画像データを読み込む。

画像処理ユニット４０１は、ＣＰＵ４０４、直接記憶部４０５、間接記憶部４０６、ユーザインタフェース４０７、外部インタフェース４０８を備える。

ＣＰＵ４０４は、所定のプログラムを実行し、画像形成装置１０７の各種制御を指示する。ＣＰＵ４０４は、Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔの略称である。直接記憶部４０５は、ＣＰＵ４０４がプログラムを実行する際に使用するワークメモリである。ＣＰＵ４０４が実行するプログラムは、直接記憶部４０５にロードされる。なお、ＣＰＵ４０４は、マルチプロセッサでもよい。

直接記憶部４０５は、ＲＡＭにより実現される。間接記憶部４０６には、アプリケーションプログラムおよびプラットフォームプログラムを含む各種プログラムが記憶されている。ＣＰＵ４０４が、間接記憶部４０６に記憶されている各種プログラムの実行時に、この各種プログラムを直接記憶部４０５へ移動する。間接記憶部４０６は、ＳＳＤ（Solid State Drive）、または、ＨＤＤ(Hard Disc Drive) により実現される。

この例では、ユーザが独自に開発した新しいアプリケーションを画像形成装置１０７上で実行できるプラットフォームを実現するプラットフォームプログラムが、間接記憶部４０６に記憶されている。プラットフォームによれば、画像形成装置１０７の操作画面をカスタマイズすることも可能になる。

以下に、プラットフォームの実現方法について説明する。ＣＰＵ４０４は、間接記憶部４０６に記憶されたプラットフォームプログラムを直接記憶部４０５に移動する。移動が完了するとＣＰＵ４０４は、プラットフォームプログラム（例えば、Ｊａｖａ（登録商標））を実行することができる状態になる。この例では、ＣＰＵ４０４が、プラットフォームプログラムを実行することを、プラットフォームが起動すると称する。なお、プラットフォームは、画像形成装置１０７のファームウェア上で動作することになる。プラットフォームプログラムは、オブジェクト指向で記述されたアプリケーションプログラムを実行するための環境を提供する。

次に、プラットフォーム上でアプリケーションプログラムを実行する方法について詳細に説明する。この例では、プラットフォーム上には、スキャンした画像をクラウドサービスに送信するスキャンソフトウェアが動作している。スキャンソフトウェアは、ネットワークを介して接続されているスキャンサービスサーバ群１０１より、例えば、ＨＴＴＰ（Hyper Text Transfer Protocol）などの通信プロトコルによってスキャンチケットの一覧の受信を行う。スキャンチケットにはスキャンの為の設定や、その後の処理フローといった情報が記録されている。以降、スキャンソフトウェアを実行することで実現するソフトウェア部をスキャンソフトウェア部と呼ぶ。

ユーザは、スキャンソフトウェア部にて表示されたスキャンチケット一覧からスキャンチケットを選択し、原稿を読み込ませることでスキャンを完了できる。スキャンソフトウェア部は、ユーザが選択したスキャンチケットの情報とスキャンした画像データを合わせてスキャンサービスサーバ群１０１に送信する。このように、プラットフォームでアプリケーションプログラムを実行することによって、画像形成装置１０７の制御を実現することができる。

次に、アプリケーションプログラムの実行方法について説明する。起動したプラットフォームは、間接記憶部４０６に記憶されたアプリケーションプログラムを直接記憶部４０５に移動する。移動が完了すると、プラットフォームは、アプリケーションプログラムを実行することができる状態になる。そして、プラットフォームは、アプリケーションプログラムを実行する。このように、アプリケーションプログラムを実行することで提供できるプラットフォームの機能を、この例ではプラットフォームアプリケーションと呼ぶ。さらに、プラットフォームは、本実施形態で開示するフローチャートの各処理の一部を行うことが可能である。

ユーザインタフェース４０７は、ユーザからの処理依頼を受け付ける。ユーザインタフェース４０７は、例えば、キーボード、マウス等を通してユーザが入力した指示に応じた信号を受け付ける。外部インタフェース４０８は、外部装置からのデータ受信や外部装置へのデータ送信が可能である。上記外部装置は、例えば、外付けＨＤＤや外付けＵＳＢメモリ等の外付け記憶装置、またはネットワークを介して接続された別体のホストコンピュータや画像形成装置等の別体装置である。画像形成装置１０７は、ネットワーク１１０、１１１を介して、クライアント端末１０６、スキャンサービスサーバ群１０１と通信可能である。

次に、クラウドサービスを提供するスキャンサービスサーバ群１０１、タスクサーバ１０３、１０４の各サービスサーバ群に関して説明する。さらには、各サービスサーバ群の説明とともに、スキャン処理の流れを合わせて説明する。

図４は、スキャンサービスサーバ群の構成例を示す図である。スキャンサービスサーバ群１０１はクラウドサービスにおけるスキャン機能の提供を行うサービスサーバ群である。

スキャンサービスサーバ群１０１は、Ｗｅｂアプリケーション部５０１、チケット管理ＤＢ５０２、テンプレート管理ＤＢ５０３を備える。これら構成要素により各種処理が実行されることでスキャンサービスサーバ群１０１がユーザに提供される。

Ｗｅｂアプリケーション部５０１は、スキャン機能を提供するアプリケーションプログラムを提供する。Ｗｅｂアプリケーション部５０１は、チケット作成部５１１、チケット一覧部５１２、スキャン受信部５１３、外部Ｉ／Ｆ５１４、チケット管理部５１５、テンプレート管理部５１６を備える。チケット作成部５１１は、ユーザがスキャンチケットを作成するための一連の機能を実現する。スキャンチケットは、画像形成装置１０７で原稿をスキャンする際の設定や、その後の処理フローの定義、各処理フローで実施されるタスクの為のパラメータ等を含む定義情報である。

以下に、スキャンチケットの作成処理について説明する。クライアント端末１０６のＷｅｂブラウザ３０１が、ユーザ操作にしたがって、チケット作成画面リクエスト（この例では、スキャンチケット作成画面リクエスト）をスキャンサービスサーバ群１０１に対して行う。チケット作成部５１１が、チケット作成画面リクエストにしたがって、チケット作成画面（この例では、スキャンチケット作成画面）をクライアント端末１０６に提供する。クライアント端末１０６のＷｅｂブラウザ３０１が、スキャンチケット作成画面を表示する。

図５は、スキャンチケット作成画面の例を示す図である。スキャンチケット作成画面６０１には、テンプレート６０２乃至６０４が表示される。テンプレートは、画像処理（例えばスキャン処理）の設定を行うための定義情報である。例えば、テンプレート６０２は、スキャンして得られる画像データをクラウド１に送信する処理を定義している。テンプレート管理部５１６が、テンプレート管理ＤＢ５０３内に記憶されているテンプレートを管理している。

チケット作成部５１１は、テンプレートをテンプレート管理ＤＢ５０３から取得し、取得したテンプレートを含むスキャンチケット作成画面をＷｅｂブラウザ３０１に対して提供する。

ユーザが、スキャンチケット作成画面６０１上に表示されたテンプレートの中から、実行するテンプレートを選択すると、Ｗｅｂブラウザ３０１が、詳細設定画面６０５を表示する。詳細設定画面６０５は、詳細なチケット設定を行うための画面である。

図５に示す例では、同一画面内にテンプレートと詳細設定画面６０５とが表示されているが、Ｗｅｂブラウザ３０１が、詳細設定画面６０５を、テンプレートが表示されている画面とは異なる画面（別ウィンドウ）で開くようにしてもよい。ユーザは、詳細設定画面６０５上で、選択したテンプレートに応じたスキャンの設定を行うことができる。例えば、スキャン設定の例としては、図５中に示すように、サイズや、カラー、白黒といった色調、またスキャンデータのフォーマット等の設定がある。ユーザが、詳細な設定を行った後、チケット発行ボタン６０６を押下すると、Ｗｅｂブラウザ３０１からスキャンサービスサーバ群１０１に対して、スキャンチケット作成リクエストが発行される。スキャンチケット作成リクエストは、スキャンチケットの作成を求める要求であり、スキャンチケット作成画面上で行われたチケット設定の情報を含む。

チケット作成部５１１は、スキャンチケット作成リクエストに含まれるチケット設定の情報に基づいて、スキャンチケットを作成し、チケット管理部５１５に指示してスキャンチケットに関する情報（チケット情報）を保存させる。チケット管理部５１５は、チケット作成部５１１からの指示にしたがって、チケット管理ＤＢ５０２にチケット情報を保存する。

外部Ｉ／Ｆ５１４は、画像形成装置１０７上で動作するスキャンソフトウェア部との通信を行う。具体的には、外部Ｉ／Ｆ５１４は、スキャンソフトウェア部から、チケット一覧部５１２の機能や、スキャン受信部５１３の機能へのアクセスを受け付ける。チケット一覧部５１２は、画像形成装置１０７からの要求にしたがい、チケット管理部５１５に保存されているチケット情報に基づいて、チケットの一覧を生成して画像形成装置１０７に返す。画像形成装置１０７は、取得したチケット一覧をチケット一覧画面上に表示する。

図６は、チケット一覧画面の一例を示す図である。この例では、チケット一覧画面４０７上には、チケット９０１乃至９０６（この例ではスキャンチケット）が表示される。ユーザが、チケット一覧画面４０７上に表示されたスキャンチケットのいずれかを選択し、画像形成装置１０７に備え付けられたスキャン装置に紙を設置し、スキャンボタン９０７を押し下げすると、スキャン実行される。そして、画像形成装置１０７が、チケット一覧画面上で選択されたスキャンチケットと、スキャン実行により得られた画像データとをスキャンサービスサーバ群１０１に対して送信する。

スキャンサービスサーバ群１０１が備えるスキャン受信部５１３は、画像形成装置１０７からスキャンチケットと画像データとを受信する。そして、スキャン受信部５１３は、受信した画像データをフローサービスサーバ群１０２に投入する。

図７は、チケット管理ＤＢとテンプレート管理ＤＢの一例を示す図である。図７（Ａ）は、チケット管理ＤＢ５０２の一例を示す。チケット管理ＤＢ５０２が保存しているチケットの情報は、ユーザＩＤ７０１、チケットＩＤ７０２、ルートＩＤ７０３、パラメータ７０４といったデータ項目を有する。ユーザＩＤ７０１は、チケットを作成したユーザを一意に識別する識別情報である。チケットＩＤ７０２は、チケットを一意に識別する識別情報である。チケットＩＤ７０２は、図５に示すスキャンチケット作成画面上でチケット発行６０６が押下げられたときにチケット作成部５１１によって生成され、チケット管理ＤＢ５０２に保存される。

ルートＩＤ７０３は、ルート情報を一意に識別する識別情報である。ルート情報は、スキャンチケット作成画面６０１上で選択されたテンプレートに対応する処理（例えばスキャン処理）を示す情報である。具体的には、ルート情報は、テンプレートに対応する処理を実現するジョブに含まれる各々のタスクを連結させたルートの情報であって、そのジョブにおけるタスクの処理順序を示す処理順情報を含む。すなわち、ルート情報は、タスクの連結をルートという単位で定義するための情報である。

ユーザが、テンプレートを選択し、スキャンを実行した場合には、スキャンデータは、ルートＩＤ７０３に対応付けて定義されたタスクの順番で処理される。パラメータ７０４は、図５中に示す詳細設定画面６０５上で設定されたスキャンの設定情報である。

図７（Ｂ）は、テンプレート管理ＤＢの一例を示す図である。テンプレート管理ＤＢ５０３には、テンプレート情報が設定されている。テンプレート情報は、図１１を参照して後述するルート情報管理ＤＢ１３０１で管理されるルート情報と、チケット作成画面上に表示されるテンプレートとを紐づける情報である。テンプレート情報は、テンプレートＩＤ８０１、テンプレート名８０２、ルートＩＤ８０３といったデータ項目を有する。

テンプレートＩＤ８０１は、テンプレートを一意に識別する識別情報である。テンプレート名８０２は、テンプレートの名称である。テンプレート名は、図５中のチケット作成画面６０１上に表示される。ルートＩＤ８０３は、ルート情報管理ＤＢ１３０１が管理するルート情報に含まれるルートＩＤ１４０１（図１１）への外部キーである。

図８は、タスクサーバの構成例を示す図である。この例では、タスクサーバ１０３の構成を説明する。タスクサーバ１０４の構成は、タスクサーバ１０３の構成と同様である。タスクサーバ１０３は、画像データに対してＯＣＲ処理を行い、ＯＣＲ結果のテキストデータを画像データに埋め込む処理を行う。また、タスクサーバ１０４は、クラウドサービスサーバ群１０８の中のストレージ機能を提供する特定のサービスに対して、画像データをアップロードし保管する処理を行う。

図８に示すように、タスクサーバ１０３は、タスク取得部１０１１、データ取得部１０１２、データ保存部１０１３、タスクステータス通知部１０１４、タスク処理部１０１５を備える。タスク取得部１０１１は、定期的にフローサービスサーバ群１０２に問い合わせを行い、タスクサーバ１０３にて処理可能なタスクを取得する。データ取得部１０１２は、タスク取得部１０１１が取得したタスクの情報に基づいて、フローサービスサーバ群１０２から、処理すべき画像データを取得する。タスク処理部１０１５は、データ取得部１０１２が取得した画像データに対して各種処理を行う。また、タスク処理部１０１５は、タスク処理部１０１５による処理結果をデータ保存部１０１３に渡す。データ保存部１０１３は、タスク処理部１０１５から受け取った処理結果をフローサービスサーバ群１０３に保存する。タスクステータス通知部１０１４は、定期的にフローサービスサーバ群１０２に状態通知を行う。状態通知は、タスクサーバがタスク処理中であることを知らせる通知である。

図９は、フローサービスサーバ群の構成例を示す図である。フローサービスサーバ群１０２は、ルート管理、ジョブ管理、一時ファイル管理を行うサービスサーバ群である。フローサービスサーバ群１０２は、ルート管理サービスサーバ群１２０１、ジョブ管理サービスサーバ群１２０２、一時ファイル管理サービスサーバ群１２０３を備える。ルート管理サービスサーバ群１２０１は、ルート情報を管理する。ジョブ管理サービスサーバ群１２０２は、ルート情報に基づいて、ジョブの処理を管理する。

一時ファイル管理サービスサーバ群１２０３は、ジョブ投入時のデータや各タスクの処理結果データの保存を管理する。具体的には、一時ファイル管理サービスサーバ群１２０３は、スキャンサービスサーバ群１０１やタスクサーバ（１０３、１０４）からの要求に応じて、ファイルを格納し、その格納先のパスを管理する。スキャンサービスサーバ群１０１は、タスクサーバからファイル取得要求があった場合には、保存したファイルのバイナリデータをタスクサーバに返却する。また、一時ファイル管理サービスサーバ群１２０３は、タスクサーバやジョブ管理サービスサーバ群１２０２からファイル削除の要求があった場合には、保存したファイルを削除する。一時ファイル管理サービスサーバ群１２０３の機能を利用することによって、スキャンサービスサーバ群１０１やタスクサーバは、ファイルの格納先のパスやファイルサーバの状態を気にすることなく、ファイルの保存、取得、削除を行うことができる。

図１０は、ルート管理サービスサーバ群の構成例を示す図である。ルート管理サービスサーバ群１２０１は、ルート情報管理ＤＢ１３０１、タスク情報管理ＤＢ１３０２、外部Ｉ／Ｆ１３０３を備える。ルート情報管理ＤＢ部１３０１は、ルート情報を保持する。タスク情報管理ＤＢ１３０２は、タスクに関する情報（タスク情報）を保持している。この例では、タスクは、ジョブに含まれる処理単位を示す。外部Ｉ／Ｆ１３０３は、ルート管理サービスサーバ群１２０１への問い合わせに用いられるＩ／Ｆである。ジョブ管理サービスサーバ群１２０２等は、外部Ｉ／Ｆ１３０３を介して、ルート情報管理ＤＢ１３０１やタスク情報管理ＤＢ１３０２を参照する。

図１１は、ルート情報管理ＤＢの一例を示す図である。ルート情報は、ルートＩＤ１４０１、シーケンス番号１４０２、タスクＩＤ１４０３といったデータ項目を有する。ルートＩＤは、ルートを一意に識別する識別情報である。タスクＩＤ１４０３は、各々のルートを構成するタスク、つまり、ユーザによって選択されたテンプレートに対応する処理を実現するジョブに含まれるタスクを一意に識別する識別情報である。

シーケンス番号１４０２は、タスクが、そのタスクが含まれるルートにおいて、何番目に実行されるタスクであるかを示す番号である。言い換えると、シーケンス番号１４０２は、ルートに対応するジョブに含まれる各々のタスクが、ジョブ内で何番目に実行されるタスクであるかを示す処理順情報である。したがって、ルート情報管理ＤＢ１３０１は、処理順情報を含むルート情報を記憶する処理順情報記憶部として機能する。

図１１を参照すると、例えば、ルートＩＤが００２であるルートは、シーケンス番号が小さい順に、Ｔａｓｋ１、Ｔａｓｋ３、Ｔａｓｋ５、Ｔａｓｋ７を含んでいる。したがって、このルートに対応するジョブに含まれるタスクのうち、最先に実行されるタスクは、Ｔａｓｋ１であり、２番目に実行されるタスクは、Ｔａｓｋ３である。また、３番目に実行されるタスクは、Ｔａｓｋ５であり、４番目に実行されるタスクは、Ｔａｓｋ７である。

図１２は、タスク情報管理ＤＢの一例を示す図である。タスク情報管理ＤＢ１３０２は、タスク情報を記憶するタスク情報記憶部である。タスク情報は、タスクＩＤ１５０１、タスク名１５０２、中止時間１５０３、状態通知時間１５０４、最大処理時間（実測）１５０５、最大処理時間（予想）１５０６といったデータ項目を有する。

タスクＩＤ１５０１は、タスクを一意に識別する識別情報である。タスク名１５０２は、タスクの名称である。中止時間１５０３は、その時間以内にタスク処理が完了しない場合に、ジョブ管理サービスサーバ群１２０２が、タスク処理を実行中のタスクサーバ（１０３、１０４）から他のタスクサーバにジョブを委譲する時間である。

タスクを実行中のタスクサーバが、所定の時間以内つまりこのタスクに対応する中止時間１５０３に設定された時間以内にタスク処理が完了しない場合、ジョブ管理サービスサーバ群１２０２は、このタスクを実行中のタスクサーバに異常が発生したと判断する。そして、ジョブ管理サービスサーバ群１２０２は、以下の処理を実行する。まず、ジョブ管理サービスサーバ群１２０２は、このタスクを他のタスクサーバに渡す。具体的には、ジョブ管理サービスサーバ群１２０２は、実行中のタスク処理と同じタスク処理が可能なタスクサーバに対してタスク処理を代理で実行するように命令（代理実行命令を発行）する。また、ジョブ管理サービスサーバ群１２０２は、所定のタイミングで、異常が発生したタスクサーバに対して、タスク処理を中止するよう命令する（中止命令を発行する）。これにより、他のタスクサーバにジョブ処理が委譲される。

タスクサーバには、ハードウェア故障やソフトウェアバグが発生したり、ネットワーク切断などにより通信できなくなったりなど、様々な異常が発生する。さらに、例えば、画像処理や外部クラウドへの保存処理など、処理対象のデータが巨大な場合にも、タスクサーバは長時間実行状態となる。このような場合も、異常が発生したと判断される。

本実施形態では、ジョブ管理サービスサーバ群１２０２は、異常が発生したタスクサーバから受け取る状態通知に応じた応答処理を通じて、タスクの処理を中止させる命令を発行する。この応答処理については、図１７を参照して後述する。もちろん、ジョブ管理サービスサーバ群１２０２が、他のタスクサーバにタスクを渡すのと同時に、異常が発生したタスクサーバに対してタスクの処理を中止させる命令を発行するようにしてもよい。

状態通知時間１５０４は、ジョブ管理サービスサーバ群１２０２が、タスクサーバに対して状態通知させる時間（通知時間間隔）である。最大処理時間（実測）、最大処理時間（予想）は、各々のタスクの処理内容に対応する処理時間である。最大処理時間（実測）１５０５は、タスクサーバによる当該タスクの処理時間の実測値のうちの最大値である。例えば、ジョブ管理サービスサーバ群１２０２は、最大処理時間（実測）１５０５に基づいて、中止時間１５０３を決定して設定する。ジョブ管理サービスサーバ群１２０２が、最大処理時間（実測）１５０５の値そのものを中止時間１５０３として設定してもよい。また、ジョブ管理サービスサーバ群１２０２は、最大処理時間（実測）１５０５に予め決められた猶予時間を足し合わせたものを中止時間１５０３として設定するようにしてもよい。なお、中止時間１５０３の決定方法としては、上記のものに限定されない。

最大処理時間（予想）１５０６は、タスクの処理時間のうち、予想される最大処理時間である。この例では、タスクサーバ１０３は、画像データに対する処理を行う。したがって、ジョブ管理サービスサーバ群１２０２は、一時ファイル管サービスサーバ群１２０３が管理できる最大サイズの画像データに対する処理時間を予め計測しておき、この計測結果に基づいて、最大処理時間（予想）１５０６を算出して設定する。また、この例では、タスクサーバ１０４は、画像データをアップロードし保管する処理を行う。したがって、ジョブ管理サービスサーバ群１２０２は、クラウドサービスサーバ群１０８がアップロードを許容する最大のサイズの画像データをアップロードするために要する時間から、最大処理時間（予想）１５０６を算出することができる。なお、ジョブ管理サービスサーバ群１２０２は、最大処理時間（予想）１５０６を、クラウドサービスサーバ群１０８のアップロードタイムアウト値から算出してもよい。最大処理時間（予想）１５０６の算出方法としては、上記のものに限定されない。

最大処理時間（予想）１５０６を、中止時間１５０３を決定する要素として用いるようにしてもよい。例えば、最大処理時間（予想）１５０６の値そのものを中止時間１５０３としてもよいし、最大処理時間（予想）１５０６に予め決められた猶予時間を足し合わせたものを中止時間１５０３としてもよい。前述したように、ジョブ管理サービスサーバ群１２０２は、タスク情報管理ＤＢ１３０２に設定された中止時間に基づいて、タスク処理を実行中のタスクサーバから他のタスクサーバにジョブを委譲することを決定する。すなわち、ジョブ管理サービスサーバ群１２０２は、前述した中止命令、代理実行命令を発行するタイミングを、タスクの処理内容に対応するタスクの処理時間に応じて変化させる。

図１３は、ジョブ管理サービスサーバ群の構成例を示す図である。ジョブ管理サービスサーバ群１２０２は、タスクサーバ（１０３、１０４）からのタスク要求（タスク取得リクエスト）に応じて、タスクを渡す。タスク取得リクエストは、タスクの取得を求める要求である。処理待ち状態のタスクサーバは、所定のポーリング時間毎に、タスク取得リクエストを送信する。また、ジョブ管理サービスサーバ群１２０２は、各タスクの状態を管理する。

ジョブ管理サービスサーバ群１２０２は、外部Ｉ／Ｆ１６０１、ジョブ情報管理ＤＢ１６０２、ジョブ追加部１６０３、ジョブ情報取得部１６０４、ジョブ情報更新部１６０５、ジョブ状態通知部１６０６を備える。

外部Ｉ／Ｆ１６０１は、タスクサーバおよび画像形成装置１０７との間の通信インタフェースである。外部Ｉ／Ｆ１６０１を通じて、ジョブ管理サービスサーバ群１２０２の各機能へのアクセスが行われる。ジョブ情報管理ＤＢ１６０２には、ジョブ情報が記憶される。ジョブ情報は、ジョブに含まれる複数のタスクのうち、現在最先の処理順序のタスクと、そのタスクの状態と、そのタスクを実行中のタスクサーバからタスク処理中であることの通知を受けた最終通知時刻に関する情報とを含む。

ジョブ追加部１６０３は、スキャンサービスサーバ群１０１によって投入されるジョブに関するジョブ情報を、ジョブ情報管理ＤＢ１６０２に記憶する。ジョブ情報取得部１６０４は、タスクサーバからのタスク取得リクエストに応じて、リクエスト元のタスクサーバが処理対象とするタスクに対応するジョブ情報をジョブ情報管理ＤＢ部１６０２から、取得し、タスクサーバに渡す。このジョブ情報をタスクサーバに渡すことを、本明細書では「タスクを渡す」と記述している。

ジョブ情報更新部１６０５は、タスクサーバからのジョブ情報更新リクエストに応じて、ジョブ情報管理ＤＢ１６０２内のジョブ情報を更新する。ジョブ情報更新リクエストは、ジョブ情報の更新を求める要求である。ジョブ状態通知部１６０６は、タスクサーバから状態通知を受け付ける。タスクサーバは、自身に対応する状態通知時間毎に状態通知を行う。

図１４は、ジョブ情報管理ＤＢの一例を示す図である。ジョブ情報管理ＤＢ１６０２は、ジョブ情報を記憶するジョブ情報記憶部である。ジョブ情報は、ジョブＩＤ１７０１、ルートＩＤ１７０２、ファイルグループＩＤ１７０３、カレントタスクＩＤ１７０４、ステータス１７０５といったデータ項目を有する。また、このジョブ情報は、最終更新時刻１７０６、パラメータ１７０７、タイムスタンプ１７０８、最終状態通知時刻１７０９といったデータ項目を有する。

ジョブＩＤ１７０１は、ジョブ情報を一意に識別する識別情報である。ルートＩＤ１７０２は、ルートを一意に識別する識別情報である。ルートＩＤ１７０２には、図５のチケット作成画面６０１上で選択されたテンプレートに対応するルートのルートＩＤが設定される。

ファイルグループＩＤ１７０３は、ジョブに含まれる画像データに関するファイルグループを一意に識別する識別情報である。カレントタスクＩＤ１７０４は、当該ジョブに含まれるタスクのうち、現在最先の処理順序のタスクであるカレントタスクを一意に識別する識別情報である。ジョブ管理サービスサーバ群１２０２のジョブ情報取得部１６０４は、カレントタスクＩＤ１７０４に設定されたタスクＩＤが、タスク取得リクエスト元のタスクサーバに割り当てられたタスクＩＤと合致するレコード（一行分のデータ）を特定する。そして、ジョブ情報取得部１６０４は、特定したレコードに対応するカレントタスクを、タスクサーバに渡す。

ジョブ情報更新部１６０５は、タスクの処理が完了した場合には、そのタスクに対応するレコードに含まれるルートＩＤを特定する。ジョブ情報更新部１６０５は、ルート情報管理ＤＢ１３０１を参照して、上記特定したルートＩＤに対応するタスクのうち、処理が完了したタスクの次に処理対象となるタスクを決定する。そして、ジョブ情報更新部１６０５は、ジョブ情報管理ＤＢ１６０２の上記レコードに対応するカレントタスクＩＤを上記決定したタスクのタスクＩＤに更新する。

ステータス１７０５は、当該タスクの状態である。具体的には、ステータス１７０５には、処理待ち状態を示す「０」、実行中状態を示す「１」、またはエラー発生を示す「２」が設定される。ジョブ情報更新部１６０５は、タスクの処理が完了した場合には、ステータス１７０５を０に更新する。

ジョブ情報取得部１６０４がタスクサーバに渡すタスクを選択する際には、ステータスが１であるレコードを選択する。これにより、複数のタスクサーバが同一のタスクを処理するといった事態を防ぐことができる。タスクサーバにタスクが渡されると、ジョブステータス変更部１６０５が、ステータス１７０５を０から１に変更する。

最終更新時刻１７０６は、ジョブ情報の最終更新時刻である。タスクのステータスが更新された時や、タスクサーバにタスクが渡された時に、最終更新時刻１７０６が現在時刻に更新される。ジョブ情報取得部１６０４は、タスク取得リクエスト元のタスクサーバに割り当てられたタスクＩＤがカレントタスクＩＤと等しいレコードが複数存在している場合、最終更新時刻１７０６が最も古いレコードを選択し、選択したレコードに対応するタスクを渡す。これにより、全てのジョブを平均的に処理することが可能となる。

パラメータ１７０７には、詳細設定画面６０５（図５）を用いて設定された設定情報や、タスクサーバが他のタスクサーバに渡す設定情報が設定される。タイムスタンプ１７０８は、ジョブ情報が更新される度に自動的に更新される固有情報である。例えば、タスク処理中のタスクが他のタスクサーバに委譲される度に、タイムスタンプ１７０８が更新される。

タスクサーバとジョブ情報更新部１６０５およびジョブ状態通知部１６０６との間の通信の際に、タイムスタンプの受け渡しを行うことで、他のタスクサーバにジョブが委譲されていないことを保証できる。最終状態通知時刻１７０９は、タスク処理を実行中のタスクサーバから状態通知を受けた最終時刻である。ジョブ情報取得部１６０４は、最終状態通知時刻１７０９から中止時間１５０３経過した場合に、他のタスクサーバへジョブを委譲する。

図１５は、本実施形態の情報処理システムの動作処理の例を説明するシーケンス図である。まず、クライアント端末１０６が備えるＷｅｂブラウザ３０１が、スキャンサービスサービスサーバ群１０１に対して、スキャンチケット作成画面リクエストを送信する（ステップＳ１１０１）。続いて、スキャンサービスサービスサーバ群１０１が備えるチケット作成部５１１は、スキャンチケット作成画面リクエストにしたがって、スキャンチケット作成画面を生成し、Ｗｅｂブラウザ３０１にレスポンスとして返す（ステップＳ１１０２）。具体的には、チケット作成部５１１は、テンプレート管理部５１６から、テンプレート管理ＤＢ５０３に登録されているスキャンチケットのテンプレートを取得する。そして、チケット作成部５１１は、取得したテンプレートに含まれるテンプレート名を含むスキャンチケット作成画面を作成し、Ｗｅｂブラウザ３０１に対して送信する。Ｗｅｂブラウザは、受信したスキャンチケット作成画面を表示する（図５）。

次に、スキャンチケット作成画面上でのユーザの操作にしたがって、Ｗｅｂブラウザ１０６が、スキャンサービスサーバ群１０１に対して、スキャンチケット作成リクエストを送信する（ステップＳ１１０３）。スキャンサービスサーバ群１０１が備えるチケット作成部５１１が、スキャンチケット作成リクエストにしたがってスキャンチケットを作成する。また、チケット管理部５１５が、作成されたスキャンチケットをチケット管理ＤＢ５０２に保存し、Ｗｅｂブラウザ３０１に対してレスポンスを返す。

次に、画像形成装置１０７のスキャンソフトウェア部が、外部Ｉ／Ｆ５１４を介し、チケット一覧部５１２に対して、チケット一覧取得リクエストを送信する（ステップＳ１１０５）。チケット一覧取得リクエストは、チケットの一覧の送信を求める要求である。チケット一覧部５１２は、チケット一覧取得リクエストにしたがって、チケットの一覧を生成してＷｅｂブラウザ３０１に返す（ステップＳ１１０６）。Ｗｅｂブラウザ３０１は、返されたチケット一覧をチケット一覧画面（図６）上に表示する。

次に、チケット一覧画面上でのユーザの操作にしたがって、画像形成装置１０７のスキャンソフトウェア部が、スキャン処理を実行して画像データを取得する（ステップＳ１１０７）。そして、スキャンソフトウェア部が、上記スキャン処理によって取得した画像データと、チケット一覧画面上でのユーザの操作により選択されたスキャンチケットとをスキャンサービスサーバ群１０１のスキャン受信部５１３に送信する（ステップＳ１１０８）

次に、スキャン受信部５１３が、受信した画像データをフローサービスサーバ群１０２に投入する（ステップＳ１１０９）。フローサービスサーバ群１０２が画像データを正しく受信できた場合には、フローサービスサーバ群１０２は、スキャンサービスサーバ群１０１に対して、受信した画像データに対応するファイルグループを応答する（ステップＳ１１０）。続いて、スキャンサービスサーバ群１０１のスキャン受信部５１３が、フローサービスサーバ群１０２に対して、ファイルグループＩＤとスキャンチケットとを送信する。これにより、フローサービスサーバ群１０２にジョブが投入される（Ｓ１１１１）。

次に、フローサービスサーバ群１０２がタスクサーバからのタスク取得リクエストに応じてタスクを渡す処理について説明する。各々のタスクサーバ（１０３，１０４）のタスク取得部１０１１が、定期的にフローサービスサーバ群１０２に問い合わせ（タスク取得リクエスト）を行う。そして、タスク取得部１０１１が、タスクサーバにて処理可能なタスクを取得する（ステップＳ１１１２、Ｓ１１１３、Ｓ１１２０、Ｓ１１２１）。フローサービスサーバ群１０２によるタスクサーバに対する応答処理については、図１６を参照して後述する。

タスクサーバのデータ取得部１０１２が、タスク取得部１０１１によって取得したタスクに対応する、処理すべき画像データをフローサービスサーバ群１０２から取得する（ステップＳ１１１４、Ｓ１１１５、Ｓ１１２２、Ｓ１１２３）。タスクサーバのタスク処理部１０１５が、フローサービスサーバ群１０２から取得した画像データに対して各種処理（タスク処理）を実行する（ステップＳ１１１６、Ｓ１１２４）。

また、タスクサーバのタスクステータス通知部１０１４は、定期的にフローサービスサーバ群１０２に状態通知を行う（ステップＳ１１１７、Ｓ１１２５）。フローサービスサーバ群１０２による、各タスクサーバからの状態通知に対する応答処理については、図１７を参照して後述する。

図１５に示す例では、タスクサーバ１０３のタスク処理部１０１５は、ステップＳ１１１６におけるタスク処理の結果を、データ保存部１０１３を介してフローサービスサーバ群１０３に保存する（ステップＳ１１１８）。また、タスクサーバ１０４のタスク処理部１０１５は、ステップＳ１１２４におけるタスク処理の結果を、クラウドサービスサーバ群１０８にデータ送信する（ステップＳ１１２６）。

また、タスクサーバ（１０３、１０４）のタスクステータス通知部１０１４は、一連のタスク処理の終了結果をフローサービスサーバ群１０３に通知する（ステップＳ１１１９、Ｓ１１２７）。

図１６は、タスク取得リクエストに対するフローサービスサーバ群の応答処理の例を説明するフローチャートである。まず、ジョブ管理サービスサーバ群１２０２のジョブ情報取得部１６０４が、タスクサーバからタスク取得リクエストを受信する（ステップＳ２２０１）。タスク取得リクエストにはタスク取得リクエスト元のタスクサーバに割り当てられたタスクＩＤが含まれている。

次に、ジョブ情報取得部１６０４が、ジョブ情報管理ＤＢ１６０２を参照して、ジョブ情報を取得する（ステップＳ２２０２）。続いて、ジョブ情報取得部１６０４が、ジョブ情報管理ＤＢ１６０２を参照して、実行すべきジョブがあるかを判断する（ステップＳ２２０３）。具体的には、ジョブ情報取得部１６０４は、ジョブ情報管理ＤＢ１６０２に、ステータスが処理待ち「０」で、かつカレントタスクＩＤがタスク取得リクエストに含まれているタスクＩＤと等しいレコードがあるかを判断する。ステータスが処理待ち「０」で、かつカレントタスクＩＤがタスク取得リクエストに含まれているタスクＩＤと等しいレコードがある場合、ジョブ情報取得部１６０４は、実行すべきジョブがあると判断する。そして、ジョブ情報取得部１６０４が、ステップＳ２２０４において、当該レコードに含まれるカレントタスクＩＤに対応するタスクを、タスク取得リクエスト元のタスクサーバに渡す（ジョブを送信する）。

ステータスが処理待ち「０」で、かつカレントタスクＩＤがタスク取得リクエストに含まれているタスクＩＤと等しいレコードがない場合、ジョブ情報取得部１６０４は、実行すべきジョブがないと判断する。そして、処理がステップＳ２２０５に進む。

ステップＳ２２０５において、ジョブ情報取得部１６０４が、中止時間１５０３以上経過して実行中であるタスクがあるかを判断する（ステップＳ２２０５）。以下に、ステップＳ２２０５の判断処理について具体的に説明する。まず、ジョブ情報管理ＤＢ１６０２のエントリのうち、カレントタスクＩＤがタスク取得リクエスト元に対応するタスクＩＤと等しいエントリがある場合、ジョブ情報取得部１６０４が、以下の処理を実行する。ジョブ情報取得部１６０４は、ジョブ情報管理ＤＢ１６０２を参照して、このタスクＩＤに対応するエントリのうち、ステータスが実行中「１」であるエントリに含まれる最終状態通知時刻を取得する。ステータスが実行中「１」であることは、このエントリに対応するタスクが、タスク取得リクエスト元のタスクサーバとは異なるタスクサーバが実行中であることを意味する。

また、ジョブ情報取得部１６０４は、タスク情報管理ＤＢを参照して、このタスクＩＤに対応する中止時間を取得する。そして、ジョブ情報取得部１６０４が、取得した最終状態通知時刻から取得した中止時間以上経過しているかを判断する。取得した最終状態通知時刻から取得した中止時間以上経過している場合、中止時間以上経過して実行中であるタスクがあると判断して、ステップＳ２２０４に進む。そして、ステップＳ２２０４において、ジョブ情報取得部１６０４は、当該中止時間以上経過して実行中であるタスクを、代理実行命令とともに、タスク取得リクエスト元のタスクサーバに渡す（ジョブを送信する）。

タスク取得リクエスト元のタスクサーバは、受け取ったタスクのタスク処理を実行する。また、ジョブ情報取得部１６０４は、所定のタイミングで、当該中止時間以上経過して実行中であるタスクの処理を実行中のタスクサーバに対して、このタスクの処理を中止する命令を発行する。これにより、タスク処理を実行中のタスクサーバから、他のタスクサーバへ処理を委譲することができる。

取得した最終状態通知時刻から取得した中止時間以上経過してない場合、中止時間以上経過して実行中であるタスクがないと判断して、ステップＳ２２０６に進む。また、ジョブ情報管理ＤＢ１６０２のエントリのうち、カレントタスクＩＤがタスク取得リクエスト元に対応するタスクＩＤと等しいエントリがない場合も、ジョブ情報取得部１６０４が、中止時間１５０３以上経過して実行中であるタスクがないと判断する。そして、処理がステップＳ２２０６に進む。

ステップＳ２２０６において、ジョブ情報取得部１６０４は、タスク取得リクエスト元のタスクサーバに対して、このタスクサーバが実行すべきタスクがないことを示す情報である“ｎｕｌｌ”を送信する（ステップＳ２２０５）。“ｎｕｌｌ”を受信したタスクサーバは、一定時間後に再度タスク取得リクエストを行う。

図１６を参照して説明した処理から、ジョブ管理サービスサーバ群１２０２は、ジョブ情報に基づいて、タスク要求に対応するタスクと一致する現在最先の処理順序のタスクの状態が実行中であるかを判断する。当該タスクの状態が実行中である場合（Ｓ２２０３でＮＯ）に、ジョブ管理サービスサーバ群１２０２は、最終状態通知時刻から所定の時間を経過しているかを判断する（Ｓ２２０５）。そして、最終状態通知時刻から所定の時間を経過している場合（Ｓ２２０５でＹＥＳ）に、ジョブ管理サービスサーバ群１２０２は、タスク要求元のタスクサーバに対して実行中のタスクの処理を代理で実行するように命令する（Ｓ２２０４）。

図１７は、状態通知に対するフローサービスサーバ群の応答処理の例を説明するフローチャートである。この応答処理においては、ジョブ管理サービスサーバ群１２０２が、タスクの処理を実行中のタスクサーバから状態通知を受信した場合に、既に他のタスクサーバが同じタスクの処理を実行中であれば、状態通知の送信元のタスクサーバのタスクの処理を中止させる。

まず、ジョブ管理サービスサーバ群１２０２のジョブ状態通知部１６０６が、タスクサーバから状態通知を受信する（ステップＳ２３０１）。この状態通知には、状態通知の送信元のタスクサーバのタスクＩＤと、このタスクサーバが処理中のタスクに対応するジョブＩＤと、タイムスタンプとが含まれている。

次に、ジョブ情報取得部１６０４が、ジョブ情報管理ＤＢ１６０２を参照する（ステップＳ２３０２）。そして、ジョブ情報取得部１６０４が、状態通知の送信元（通知元）のタスクサーバが処理中のタスクが、既に他のタスクサーバによって実行されているか、すなわち、他のタスクサーバにジョブが委譲されているかを判断する（ステップＳ２３０３）。具体的には、ジョブ情報取得部１６０４は、状態通知に含まれるタスクＩＤ、ジョブＩＤ、タイムスタンプの組に対応するジョブ情報が存在するかを判断する。ここで、他のタスクサーバにジョブが委譲されている場合には、タイムスタンプが更新されている。したがって、状態通知に含まれるタスクＩＤ、ジョブＩＤ、タイムスタンプの組に対応するジョブ情報が存在しない場合、ジョブ情報取得部１６０４は、当該タスクが既に他のタスクサーバによって実行されていると判断し、処理がステップＳ２３０４に進む。

ステップＳ２３０４において、ジョブ情報取得部１６０４が、状態通知の送信元のタスクサーバに対して、“ｎｕｌｌ”を送信する。この例では、当該“ｎｕｌｌ”の送信は、タスクの処理を中止させる命令の発行である。“ｎｕｌｌ”を受信すなわちタスクの処理を中止させる命令を受信したタスクサーバは、この命令にしたがって、タスクの処理を中止する。これにより、このタスクサーバが、次に実行すべきタスクの問い合わせを再開することができる。これにより、タスクサーバが、無駄な処理を実行することでコンピュータリソースを無駄に消費したり、二重に処理を行って外部システムに対して不整合を発生させることを防止することができる。

状態通知に含まれるタスクＩＤ、ジョブＩＤ、タイムスタンプの組に対応するジョブ情報が存在する場合、ジョブ情報取得部１６０４は、タスクが他のタスクサーバによって実行されていないと判断し、処理がステップＳ２３０５に進む。そして、ジョブ情報更新部１６０５が、タイムスタンプを更新して、更新後のタイムスタンプを状態通知の送信元のタスクサーバに対して送信する（ステップＳ２３０５）。

以上説明したように、実施例１では、ジョブが委譲された場合に、実行中のタスクの処理を適切に中止させることができる。これにより、タスクがコンピュータリソースを無駄に消費せず、一連のジョブ処理におけるスループットを拡大し、外部システムへの不整合を発生させないシステムを実現することができる。

（実施例２）
タスクサーバ（１０３、１０４）が、ジョブ管理サービスサーバ群１２０２に対して、一定間隔でタスク取得リクエストを送信すると、タスク取得リクエストの送信回数が多くなった場合、ネットワーク帯域が浪費されてしまう。一方、タスク取得リクエストの送信回数を少なくすると、ジョブ実行までの待ち時間が増加してしまい、システムのスループットが低下してしまう。したがって、タスク取得リクエストの送信間隔の最適化が必要となる。また、タスクサーバからの状態通知の送信も、ネットワークリソースの浪費の原因となるので、状態通知の送信もできる限り減らすのが望ましい。そこで、実施例２では、タスクサーバによるタスク取得リクエストの送信間隔と、状態通知の間隔とを最適化する。

図１８は、実施例２における、タスク取得リクエストに対するフローサービスサーバ群の応答処理の例を説明するフローチャートである。ステップＳ２４０１、Ｓ２４０２、Ｓ２４０３、Ｓ２４０４は、それぞれ、図１６のステップＳ２２０１、Ｓ２２０２，Ｓ２２０３、Ｓ２２０５と同様である。

ステップＳ２４０９において、ジョブ情報取得部１６０４が、タスク取得リクエスト元のタスクサーバに割り当てられたタスクＩＤに対応するタスク情報を取得する。そして、ジョブ情報取得部１６０４が、タスク取得リクエスト元のタスクサーバに対して、実行すべきタスクと、上記ステップＳ２４０９において取得されたタスク情報に含まれる状態通知時間とを送信する（ステップＳ２４１０）。ジョブ情報取得部１６０４から状態通知時間を受信したタスクサーバは、この状態通知時間の時間間隔で、次の状態通知を行う。ここで、図１２を参照すると、タスクサーバが受信する状態通知時間は、タスクの内容および最大処理時間に応じて変化する。したがって、この状態通知時間を受信したタスクサーバは、状態通知を行う時間間隔をタスクの処理時間に応じて変化させることになる。

図１２に示すタスク情報管理ＤＢ１３０２に保存されたタスク情報のうち、タスクＩＤがそれぞれ“Ｔａｓｋ１”、“Ｔａｓｋ２”であるタスク１、タスク２を例にとって説明する。ジョブ管理サービスサーバ群１２０２は、タスクサーバからの状態通知が一定時間無かった場合、タスクサーバに異常が発生したと判断して、別のタスクサーバにジョブを委譲する。ここで、タスク１は、ＰＤＦをＰＤＬに変換する画像処理を行うタスクであるため、最大処理時間（予想）が６００秒と比較的長くなっている。これは、画像処理は処理の品質やパラメータによっては非常に時間を要する場合があるからである。また、タスク２は、外部クラウド（本実施例ではクラウド１）にデータを保存するタスクである。

一般的に、クラウドへの接続には、タイムアウト時間が設定されている。例えば、クラウド１の場合は３０秒がタイムアウトである。したがって、タスク２の最大処理時間（予想）は３０秒に設定されている。例えば、状態通知時間を全てのタスクサーバについて３０秒程度に固定にした場合、タスク２については、状態通知時間として適切であるが、タスク１については、状態通知時間として短かすぎる。タスク１は、最大で６００秒程度を要するタスクであるため、２０回程度も無駄な通信を発生させることになるからである。

また、例えば、状態通知時間を全てのタスクサーバについて６００秒程度に固定にした場合、タスク１については状態通知時間として適切であるが、タスク２については状態通知時間として長すぎる。タスク２は３０秒程度で終了するタスクであるため、異常が発生した場合はより早くジョブ管理サービスサーバ群１２０２が検知するべきだからである。本実施例では、タスクの内容に応じて最適な状態通知時間をジョブ管理サービスサーバ群１２０２から指定する。したがって、状態通知回数を低減することができる。その結果、ジョブ管理サービスサーバ群のネットワークリソース、コンピュータリソースの浪費を抑えることができる。

図１８に戻って、ステップＳ２４０４の判断処理で、ジョブ情報取得部１６０４が、中止時間１５０３以上経過して実行中であるタスクがないと判断した場合は、処理がステップＳ２４０５に進む。

次に、ジョブ情報取得部１６０４が、ジョブ情報管理ＤＢ１６０２から、実行中のジョブ情報すなわち対応するステータスが「１」に設定されているジョブ情報を取得する。ジョブ情報取得部１６０４は、取得したジョブ情報に含まれるカレントタスクＩＤが示す、現在最先の処理順序のタスク、つまり実行中のタスクを特定する。また、ジョブ情報取得部１６０４が、取得したジョブ情報に含まれるルートＩＤに対応するルート情報を取得する（ステップＳ２４０５）。取得したルート情報に含まれるタスクＩＤとシーケンス番号とに基づいて、各々のタスクＩＤに対応するタスクの、当該ルートにおける処理順序を確認する（ステップＳ２４０５）。

次に、ジョブ情報取得部１６０４が、ステップＳ２４０５における確認結果に基づいて、タスク取得リクエスト元のタスクサーバが実行すべきタスクの前の処理順序であるタスクが処理中であるかを判断する（ステップＳ２４０６）。すなわち、ジョブ情報取得部１６０４は、現在最先の処理順序のタスクとタスク要求されたタスクとの処理順序関係を判断してタスク要求されたタスクのタスク処理より前のタスク処理の進捗状況を決定する。

この例では、現在実行中のタスクの次の処理順序であるタスクのタスクＩＤが、タスク取得リクエスト元のタスクサーバのタスクＩＤと一致する場合、ジョブ情報取得部１６０４が、以下の処理を実行する。ジョブ情報取得部１６０４は、そのタスクサーバが実行すべきタスクの前の処理順序であるタスクが処理中である、すなわちジョブ情報取得部１６０４は、タスク取得リクエスト元のタスクサーバが、近い将来タスク処理を実行すべきタスクサーバであると判断する。そして、ジョブ情報取得部１６０４は、タスク取得リクエスト元のタスクサーバに対して、ポーリング時間すなわちタスク取得リクエストの送信間隔として、時間ａを送信する（ステップＳ２４０７）。ポーリング時間ａを受信したタスクサーバは、ポーリング時間ａを経過した時に、ジョブ管理サービスサーバ群１２０２に対して再度タスク取得リクエストを送信する。

ここで、ポーリング時間ａは、ポーリング時間ａは、ジョブ管理サービスサーバ群１２０２のネットワークＩ／Ｏ制限や、ＣＰＵ、メモリなどに基づいて、ジョブ管理サービスサーバ群１２０２が許容できる最も短い時間に予め設定されている。

また、この例では、現在実行中のタスクの次の処理順序であるタスクのタスクＩＤが、タスク取得リクエスト元のタスクサーバのタスクＩＤと一致しない場合、ジョブ情報取得部１６０４が、以下の処理を実行する。ジョブ情報取得部１６０４は、そのタスクサーバが実行すべきタスクの前の処理順序であるタスクが処理中である、すなわち、タスク取得リクエスト元のタスクサーバが行うタスク処理の順番は遅いと判断する。そして、ジョブ情報取得部１６０４は、タスク取得リクエスト元のタスクサーバに対して、ポーリング時間ａより長い時間（例えば、２倍の時間）であるポーリング時間ｂを送信する（ステップＳ２４０８）。

ポーリング時間ａを受信したタスクサーバは、ポーリング時間ｂを経過した時に、ジョブ管理サービスサーバ群１２０２に対して再度タスク取得リクエストを送信する。すなわち、ジョブ情報取得部１６０４は、タスク要求されたタスクのタスク処理より前のタスク処理の進捗状況に応じて、ポーリング時間を変更し、変更したポーリング時間をタスク要求元のタスクサーバに通知する。タスクサーバは、通知されたポーリング時間経過後に、次のタスク取得リクエストを行う。つまり、タスクサーバ側からみると、タスクサーバは、タスク取得リクエストを送信する時間間隔を、自身が実行するタスク処理より前のタスク処理の進捗状況に応じて変化させる。

なお、この例では、ステップＳ２４０６における判断処理は、必ずしもタスク取得リクエスト元が実行すべきタスクの１つ前のタスクが実行中であるかを基準に行っているが、ステップＳ２４０６における判断処理の基準は、この基準に限定されない。例えば、２つ前、３つ前のタスクが実行中であるか否かを判断基準にしてもよい。

本実施例によれば、タスク取得リクエスト元のタスクサーバに対して、タスク処理の進捗状況に応じた最適なポーリング時間で次のタスク取得リクエストを行わせることができる。また、本実施例によれば、タスクサーバに、タスクの処理内容に応じた最適な時間間隔で次の状態通知を行われることができる。したがって、ネットワークリソースの浪費を抑えつつ、ジョブ実行のスループットを向上させることができる。

（その他の実施例）
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。この場合、そのプログラム、及び該プログラムを記憶した記憶媒体は本発明を構成することになる。

１０１ スキャンサービスサーバ群
１０２ フローサービスサーバ群
１０３，１０４ タスクサーバ
１０６ クライアント端末
１０７ 画像形成装置

Claims (11)

1. ユーザからの要求に応じて発生した複数のタスクから構成されるジョブを管理するジョブ管理部と、
   処理待ち状態であれば前記ジョブ管理部からタスクを取得し特定のタスク処理を施す複数のバックエンド部と、を有し、
   前記ジョブ管理部は、さらに、
   前記ジョブに含まれる各々のタスクの、前記ジョブにおける処理順序を示す処理順情報を記憶する処理順情報記憶部と、
   前記各々のタスクの処理内容に対応する処理時間と、前記バックエンド部がタスク処理中であることを前記ジョブ管理部に通知する時間間隔である通知時間間隔とを含むタスク情報を記憶するタスク情報記憶部と、
   前記ジョブに含まれる複数のタスクのうち、現在最先の処理順序のタスクと、前記タスクの状態と、前記タスクを実行中の前記バックエンド部からタスク処理中であることの通知を受けた最終通知時刻に関する情報とを含むジョブ情報を記憶するジョブ情報記憶部とを有しており、
   前記バックエンド部は、前記タスク処理中であることを定期的に前記ジョブ管理部に通知し、
   前記バックエンド部からタスク要求を受けた前記ジョブ管理部は、
   前記ジョブ情報記憶部に記憶されたジョブ情報に基づいて、前記タスク要求されたタスクと一致する現在最先の処理順序のタスクの状態が実行中であるかを判断し、
   前記タスク要求されたタスクと一致する現在最先の処理順序のタスクの状態が実行中である場合に、前記最終通知時刻から所定の時間を経過しているかを判断し、
   前記最終通知時刻から所定の時間を経過している場合に、タスク処理が完了しなかった前記バックエンド部に対して前記タスク処理を中止するよう命令し、かつ、前記タスク要求を行ったバックエンド部に対して前記実行中のタスク処理を代理で実行するように命令する
   ことを特徴とする情報処理システム。
2. 前記ジョブ管理部は、前記タスク処理を中止する命令、前記タスク処理を代理で実行する命令を発行するタイミングを、タスクの処理内容に対応するタスクの処理時間に応じて変化させる
   ことを特徴とする請求項１に記載の情報処理システム。
3. 前記処理待ち状態のバックエンド部は、
   前記ジョブ管理部に対し、タスクがあるか否かを一定間隔で問い合わせるタスク要求を行い、前記タスク要求を行う時間間隔を、前記タスクのタスク処理より前のタスク処理の進捗状況に応じて変化させる
   ことを特徴とする請求項１または請求項２に記載の情報処理システム。
4. 前記バックエンド部は、前記タスク処理中であることを前記ジョブ管理部に通知する時間間隔を、タスクの処理時間に応じて変化させる
   ことを特徴とする請求項１乃至３のいずれか１項に記載の情報処理システム。
5. 前記ジョブ管理部は、前記タスク情報記憶部に記憶された前記タスク情報に基づいて、前記タスク処理を施すバックエンド部に渡すタスクの処理内容に対応する前記通知時間間隔を決定して前記バックエンド部に対して送信し、
   前記通知時間間隔を前記ジョブ管理部から受け取ったバックエンド部は、受け取った通知時間間隔で前記タスク処理中であることを前記ジョブ管理部に通知する
   ことを特徴とする請求項１乃至４のいずれか１項に記載の情報処理システム。
6. 前記バックエンド部から前記タスク要求を受けた前記ジョブ管理部は、
   前記タスク要求されたタスクと一致する現在最先の処理順序のタスクの状態が実行中であり、かつ前記最終通知時刻から所定の時間を経過していないと判断した場合に、前記処理順情報記憶部に記憶された処理順情報に基づいて、前記ジョブ情報記憶部に記憶されたジョブ情報に含まれる現在最先の処理順序のタスクと前記タスク要求されたタスクとの処理順序関係を判断して前記タスク要求されたタスクのタスク処理より前のタスク処理の進捗状況を決定し、
   前記決定した進捗状況に応じて、前記バックエンド部がタスク要求を行う時間間隔を変更して前記バックエンド部に通知する
   ことを特徴とする請求項１乃至５のいずれか１項に記載の情報処理システム。
7. 前記ジョブ情報記憶部に記憶された前記ジョブ情報が、前記ジョブ情報に含まれるタスクのタスク処理が代理で実行される度に更新される固有情報を有しており、
   前記バックエンド部から前記ジョブ管理部へのタスク処理中であることの通知が、タスク処理中のタスクを示す情報と前記固有情報とを有しており、
   前記ジョブ管理部は、
   前記バックエンド部からタスク処理中であることを通知された場合に、前記ジョブ情報記憶部に記憶された前記ジョブ情報に、前記通知が有する前記タスクを示す情報および前記固有情報が含まれるかを判断し、
   前記ジョブ情報記憶部に記憶された前記ジョブ情報に、前記通知が有する前記タスクを示す情報および前記固有情報が含まれない場合に、前記通知を行ったバックエンド部とは異なる他のバックエンド部が前記タスクのタスク処理を実行中であると判断して、前記通知を行ったバックエンド部に対してタスク処理を中止するよう命令する
   ことを特徴とする請求項１乃至６のいずれか１項に記載の情報処理システム。
8. 前記ユーザからの要求に応じて、複数のタスクから構成されるジョブを生成して前記ジョブ管理部に対して投入するジョブ投入部をさらに有する
   ことを特徴とする請求項１乃至７のいずれか１項に記載の情報処理システム。
9. 請求項１乃至８のいずれか１項に記載のジョブ管理部が管理するジョブに対応する画像データを生成する画像形成装置。
10. ユーザからの要求に応じて発生した複数のタスクから構成されるジョブを管理するジョブ管理部と、
    処理待ち状態であれば前記管理されているジョブに含まれるタスクを取得し特定のタスク処理を施すバックエンド部とを有する情報処理システムの制御方法であって、
    前記ジョブに含まれる各々のタスクの、前記ジョブにおける処理順序を示す処理順情報を記憶する処理順情報記憶工程と、
    前記各々のタスクの処理内容に対応する処理時間と、前記バックエンド部がタスク処理中であることを前記ジョブ管理部に通知する時間間隔である通知時間間隔とを含むタスク情報を記憶するタスク情報記憶工程と、
    前記ジョブに含まれる複数のタスクのうち、現在最先の処理順序のタスクと、前記タスクの状態と、前記タスクを実行中の前記バックエンド部からタスク処理中であることの通知を受けた最終通知時刻に関する情報とを含むジョブ情報を記憶するジョブ情報記憶工程と、
    前記バックエンド部が、前記タスク処理中であることを一定間隔で前記ジョブ管理部に通知する通知工程と、
    前記ジョブ情報記憶工程において記憶されたジョブ情報に基づいて、タスク要求されたタスクと一致する現在最先の処理順序のタスクの状態が実行中であるかを判断する判断工程と、
    前記タスク要求されたタスクと一致する現在最先の処理順序のタスクの状態が実行中である場合に、前記最終通知時刻から所定の時間を経過しているかを判断する判断工程と、
    前記最終通知時刻から所定の時間を経過している場合に、前記ジョブ管理部が、所定の時間以内にタスク処理が完了しなかった前記バックエンド部に対して前記タスク処理を中止するよう命令し、かつ、前記タスク要求を行ったバックエンド部に対して前記実行中のタスク処理を代理で実行するように命令する命令工程と、を有する
    ことを特徴とする情報処理システムの制御方法。
11. 請求項１０に記載の情報処理システムの制御方法をコンピュータに実行させることを特徴とするコンピュータプログラム。

Images