JP7021483B2 - 情報処理システム - Google Patents

Description

本発明は、情報処理システムに関する。

特許文献１には、先行するジョブが実行中であるために機器の設定変更が不可能な場合であっても、ユーザによる設定変更の要求を受け付け、設定変更が可能となった後、設定変更を実行する技術が開示されている。

特許文献２には、複数の操作手段から複数の操作設定を受け付けた場合に、それらの操作設定を行ったユーザが同一でなく、かつ、複数の操作設定が競合関係にある場合、後から受け付けた操作設定を拒否する技術が開示されている。

特許文献３には、複数の出力のような複数の出力の予約を同時に受け付け、利用可能な出力から順次実行する技術が開示されている。

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

情報処理システムが第１のジョブの要求を受けた後に第２のジョブの要求を受けた場合、それら複数のジョブを同時並行で実行しようとすると、リソース使用における競合が発生し正しい処理結果が得られない場合がある。

リソース使用における競合の発生を防止するために、複数ジョブを同時並行で実行することを禁じ、例えば第１のジョブが完了した後、第１のジョブより後に要求された第２のジョブを開始する方法がある。しかしながら、この方法による場合、第２のジョブが要求されてから完了するまでの時間は、第２のジョブの所要時間より、第２のジョブが要求された時点における第１のジョブの未処理部分の所要時間だけ長くなる。

本発明は、情報処理システムが第１のジョブの要求を受けた後に第２のジョブの要求を受けた場合、リソース使用における競合を避け、かつ、第２のジョブが要求されてから完了するまでの時間を、第２のジョブが要求された時点における第１のジョブの未処理部分の所要時間と第２のジョブの所要時間の合計値より短縮する手段を提供する。

本発明の請求項１に係る情報処理システムは、ジョブ単位で要求される処理を実行する処理部に対し要求された第１のジョブを構成する複数のタスクのうちいずれかのタスクが実行されている間に使用されていないリソースを用いて前記第１のジョブより後に前記処理部に対し要求された第２のジョブを構成する複数のタスクのうちいずれかのタスクの実行が可能であるか否かを判定し、前記第２のジョブを構成するいずれかのタスクの実行が可能であると判定した場合、当該タスクの実行を前記処理部に指示する指示部を備え、前記指示部は、前記第１のジョブを構成する複数のタスクのうちいずれかのタスクが実行されている間に使用されていないリソースを用いて前記第２のジョブを構成する複数のタスクのうちいずれかのタスクの実行が可能であり、かつ、当該タスクの実行により前記第１のジョブの完了時刻の遅延時間が許容範囲内であると判定した場合、当該タスクの実行を前記処理部に指示することを特徴とする。

本発明の請求項２に係る情報処理システムは、請求項１に記載の構成において、前記指示部は、前記第１のジョブの優先度に応じて異なる前記許容範囲を用いることを特徴とする。

本発明の請求項３に係る情報処理システムは、ジョブ単位で要求される処理を実行する処理部に対し要求された第１のジョブを構成する複数のタスクのうちいずれかのタスクが実行されている間に使用されていないリソースを用いて前記第１のジョブより後に前記処理部に対し要求された第２のジョブを構成する複数のタスクのうちいずれかのタスクの実行が可能であるか否かを判定し、前記第２のジョブを構成するいずれかのタスクの実行が可能であると判定した場合、当該タスクの実行を前記処理部に指示する指示部を備え、前記第１のジョブは実行中にユーザに対する操作の要求を伴い、前記指示部は、前記第１のジョブのいずれかのタスクが実行されている間に使用されていないリソースを用いて前記第２のジョブのいずれかのタスクの実行が可能であり、かつ、当該タスクの実行により前記ユーザに対する操作の要求時刻の遅延時間が許容範囲内であると判定した場合、当該タスクの実行を前記処理部に指示することを特徴とする。

本発明の請求項４に係る情報処理システムは、請求項３に記載の構成において、前記第１のジョブの実行に伴う前記ユーザに対する操作の要求時刻を前記ユーザに通知する通知部を備えることを特徴とする。

本発明の請求項５に係る情報処理システムは、ジョブ単位で要求される処理を実行する処理部に対し要求された第１のジョブを構成する複数のタスクのうちいずれかのタスクが実行されている間に使用されていないリソースを用いて前記第１のジョブより後に前記処理部に対し要求された第２のジョブを構成する複数のタスクのうちいずれかのタスクの実行が可能であるか否かを判定し、前記第２のジョブを構成するいずれかのタスクの実行が可能であると判定した場合、当該タスクの実行を前記処理部に指示する指示部を備え、前記第２のジョブは実行中にユーザに対する操作の要求を伴い、前記第２のジョブの実行に伴う前記ユーザに対する操作の要求時刻を前記ユーザに通知する通知部を備えることを特徴とする。

本発明の請求項６に係る情報処理システムは、ジョブ単位で要求される処理を実行する処理部に対し要求された第１のジョブを構成する複数のタスクのうちいずれかのタスクが実行されている間に使用されていないリソースを用いて前記第１のジョブより後に前記処理部に対し要求された第２のジョブを構成する複数のタスクのうちいずれかのタスクの実行が可能であるか否かを判定し、前記第２のジョブを構成するいずれかのタスクの実行が可能であると判定した場合、当該タスクの実行を前記処理部に指示する指示部を備え、前記指示部は、前記第１のジョブのいずれかのタスクが実行されている間に使用されているリソースが使用可能となった後に当該リソースを使用して前記第２のジョブのいずれかのタスクが実行された場合の当該タスクの完了時刻よりも、当該リソースを代替する代替リソースを使用して当該タスクが実行された場合の当該タスクの完了時刻が早い場合、前記代替リソースを使用した当該タスクの実行を前記処理部に指示することを特徴とする。

本発明の請求項７に係る情報処理システムは、請求項６に記載の構成において、前記指示部により前記代替リソースを使用したタスクの実行が前記処理部に指示される前に、前記第２のジョブを要求したユーザに対し前記代替リソースが使用されることを通知する通知部を備えることを特徴とする。

本発明の請求項８に係る情報処理システムは、ジョブ単位で要求される処理を実行する処理部に対し要求された第１のジョブを構成する複数のタスクのうちいずれかのタスクが実行されている間に使用されていないリソースを用いて前記第１のジョブより後に前記処理部に対し要求された第２のジョブを構成する複数のタスクのうちいずれかのタスクの実行が可能であるか否かを判定し、前記第２のジョブを構成するいずれかのタスクの実行が可能であると判定した場合、当該タスクの実行を前記処理部に指示する指示部を備え、前記指示部は、監視対象のイベントの発生をトリガに、前記第１のジョブのいずれかのタスクが実行されている間に使用されていないリソースを用いて前記第２のジョブのいずれかのタスクの実行が可能であるか否かを判定することを特徴とする。

請求項１～８に係る発明によれば、情報処理システムが第１のジョブの要求を受けた後に第２のジョブの要求を受けた場合、リソース使用における競合が避けられ、かつ、第２のジョブが要求されてから完了するまでの時間が、第２のジョブが要求された時点における第１のジョブの未処理部分の所要時間と第２のジョブの所要時間の合計値より短縮される。
請求項１に係る発明によれば、第２のジョブの完了時刻を早めるために、第１のジョブの完了時刻が許容範囲を超えて遅延することはない。
請求項２に係る発明によれば、第２のジョブの完了時刻を早めるために、第１のジョブの完了時刻が第１のジョブの優先度に応じた許容範囲を超えて遅延することはない。
請求項３に係る発明によれば、第２のジョブの完了時刻を早めるために、第１のジョブに伴うユーザに対する操作の要求時刻が許容範囲を超えて遅延することはない。
請求項４に係る発明によれば、第２のジョブの完了時刻を早めるために、第１のジョブに伴うユーザに対する操作の要求時刻が変化した場合、第１のジョブを要求したユーザは変化後の操作の要求時刻を知ることができる。
請求項５に係る発明によれば、第２のジョブを要求したユーザは操作の要求時刻を知ることができる。
請求項６に係る発明によれば、代替リソースを使用せずに第２のジョブが実行された場合と比較し、第２のジョブの完了時刻が早まる。
請求項７に係る発明によれば、第２のジョブを要求したユーザは、第２のジョブの実行に代替リソースが使用されることを知ることができる。
請求項８に係る発明によれば、監視対象のイベントが発生する毎に、第２のジョブの完了時刻が早められるか否かが判定される。

一実施例に係る情報処理システムの全体構成を示した図。 一実施例に係る情報処理装置のハードウェア構成を示した図。 一実施例に係る情報処理システムの機能構成を示した図。 一実施例に係るジョブテーブルのデータ構成を示した図。 一実施例に係る状態テーブルのデータ構成を示した図。 一実施例に係る使用リソーステーブルのデータ構成を示した図。 一実施例に係る処理計画テーブルのデータ構成を示した図。 一実施例に係る指示部が行う処理のフローを示した図。 一実施例に係る操作部が表示する通知画面を例示した図。 一実施例に係る処理計画生成部が処理計画を生成する手順を説明するための図。 一実施例に係る処理計画生成部が処理計画を生成する手順を説明するための図。 一実施例に係る処理計画生成部が処理計画を生成する手順を説明するための図。 一実施例に係る処理計画生成部が処理計画を生成する手順を説明するための図。 一変形例に係るジョブ優先度テーブルの内容を例示した図。 一変形例に係る処理計画生成部が処理計画を生成する手順を説明するための図。 一変形例に係る処理計画生成部が処理計画を生成する手順を説明するための図。 一変形例に係る操作部が表示する通知画面を例示した図。 一変形例に係る情報処理システムの全体構成を示した図。 一変形例に係る指示部が行う処理のフローを示した図。 一変形例に係る処理計画生成部が処理計画を生成する手順を説明するための図。 一変形例に係る操作部が表示する通知画面を例示した図。

［１］実施例
図１は実施例に係る情報処理システム１の全体構成を示した図である。情報処理システム１は情報処理装置１１と、ユーザが情報処理装置１１に対する処理の指示を与える操作を行うために用いる端末装置１２（１）～１２（ｎ）（ただし、ｎは任意の自然数）を備える。以下、端末装置１２（１）～１２（ｎ）を互いに区別しない場合、それらを「端末装置１２」という。情報処理装置１１と端末装置１２の各々は無線及び有線の少なくとも一方により互いに通信可能である。

情報処理装置１１は画像形成機能、画像読取機能、文字認識機能、メール送信機能及びＦＡＸ送受信機能を備える複合機である。端末装置１２はコンピュータであり、例えばデスクトップ型コンピュータ、ノートブック型コンピュータ、タブレット型コンピュータ等、それらの形態は様々に異なってよい。

図２は情報処理装置１１のハードウェア構成を示した図である。情報処理装置１１は、プログラム及び各種データを記憶するメモリ１０１と、メモリ１０１に記憶されているプログラムに従い各種データ処理を行うプロセッサ１０２と、ユーザに対し画像を表示するディスプレイ１０３と、ディスプレイ１０３と積層配置されユーザのタッチ操作を受け付けるタッチパネル１０４を備える。

情報処理装置１１は、さらに、紙等のシート状記録媒体に画像形成を行うプリンタユニット１０５と、紙等のシート状記録媒体に形成された画像を光学的に読み取るスキャナユニット１０６と、インターネットプロトコルに従いデータ通信を行う通信ユニット１０７と、電話回線を通じてデータ通信を行う通信ユニット１０８を備える。

図３は情報処理システム１の機能構成を示した図である。すなわち、情報処理装置１１のプロセッサ１０２がメモリ１０１に記憶されているプログラムに従う処理を実行することにより、図３に示される構成部を備える装置が実現される。また、端末装置１２の各々が備えるプロセッサがメモリに記憶されているプログラムに従う処理を実行することにより、図３に示される構成部を備える装置が実現される。

情報処理装置１１は、ユーザに操作を促す画像を表示するとともにユーザの操作を受け付ける操作部１３１（０）と、画像形成等の各種処理を実行する処理部１１１と、処理部１１１に対し処理の実行を指示する指示部１１２を備える。操作部１３１（０）はプロセッサ１０２の制御下で動作するディスプレイ１０３とタッチパネル１０４により実現される。

処理部１１１は、画像形成処理を行う画像形成部１１１１と、画像読取処理を行う画像読取部１１１２と、文字認識処理を行う文字認識部１１１３と、電子メールの送信処理を行うメール送信部１１１４と、ＦＡＸの送受信処理を行うＦＡＸ送受信部１１１５と、アプリケーションプログラムのインストール等のデータ更新処理を行うデータ更新部１１１６を備える。

画像形成部１１１１はプロセッサ１０２の制御下で動作するプリンタユニット１０５により実現される。画像読取部１１１２はプロセッサ１０２の制御下で動作するスキャナユニット１０６により実現される。文字認識部１１１３はプロセッサ１０２により実現される。メール送信部１１１４はプロセッサ１０２及びプロセッサ１０２の制御下で動作する通信ユニット１０８により実現される。ＦＡＸ送受信部１１１５はプロセッサ１０２及びプロセッサ１０２の制御下で動作する通信ユニット１０７により実現される。データ更新部１１１６はプロセッサ１０２により実現される。

指示部１１２は、各種データを記憶する記憶部１１２１と、操作部１３１（０）及び端末装置１２（１）～１２（ｎ）が備える操作部１３１（１）～１３１（ｎ）からユーザにより要求されたジョブの内容を示すデータであるジョブデータを取得するジョブデータ取得部１１２２と、処理部１１１から処理部１１１の状態を示すデータである状態データを取得する状態データ取得部１１２３を備える。以下、操作部１３１（０）及び端末装置１２（１）～１２（ｎ）が備える操作部１３１（１）～１３１（ｎ）を区別しない場合、それらを「操作部１３１」という。

本願において、「ジョブ」とは、ユーザにより要求される処理の単位を意味し、１又は複数の処理を含む。また、本願において「タスク」とは、ジョブを構成し、使用するリソースが各々定まる１又は複数の処理を意味する。また、本願において「リソース」とは、装置又は装置群が備える要素のうち情報処理に必要な要素を意味する。例えば、ＦＡＸ送信というジョブは、スキャナユニット１０６というリソースを使用する原稿読取というタスクと、通信ユニット１０８というリソースを使用するデータ転送というタスクにより構成される。また、以下の説明において、第１のジョブが要求された後に第２のジョブが要求された場合の第１のジョブを第２のジョブの「先着のジョブ」と呼び、第２のジョブを第１のジョブの「後着のジョブ」と呼ぶ。

指示部１１２は、さらに、記憶部１１２１に記憶されているデータに基づき監視対象のイベントの発生を検知するイベント検知部１１２４と、イベント検知部１１２４による監視対象のイベントの検知をトリガに記憶部１１２１に記憶されているデータに基づき処理部１１１が行う処理の計画（以下、「処理計画」という）を生成する処理計画生成部１１２５と、処理計画生成部１１２５により生成された処理計画に従い処理部１１１に対し処理の指示を示すデータである指示データを出力する指示データ出力部１１２６と、ジョブの要求元の操作部１３１（すなわち、要求元のユーザ）にジョブの推定される完了時刻等の通知を行う通知部１１２７を備える。

本願において、「イベント」とは、情報処理システムの動作又は状態の変化を意味する。

記憶部１１２１はプロセッサ１０２の制御下で動作するメモリ１０１により実現される。ジョブデータ取得部１１２２、状態データ取得部１１２３、イベント検知部１１２４、処理計画生成部１１２５及び指示データ出力部１１２６はプロセッサ１０２により実現される。通知部１１２７はプロセッサ１０２及びプロセッサ１０２の制御下で動作する通信ユニット１０７により実現される。

記憶部１１２１には、ジョブデータ取得部１１２２が操作部１３１から取得したジョブデータを格納するジョブテーブルと、状態データ取得部１１２３が処理部１１１から取得した状態データを格納する状態テーブルと、タスクの種別毎にタスクの実行において使用されるリソースを示すデータである使用リソースデータを格納する使用リソーステーブルと、処理計画生成部１１２５により生成された処理計画を示すデータである処理計画データを格納する処理計画テーブルが記憶されている。

図４はジョブテーブルのデータ構成を示した図である。ジョブテーブルはジョブの各々に応じたジョブデータを含むデータレコードの集まりである。ジョブテーブルに含まれるデータレコードには、ジョブデータにより要求されたジョブを識別するジョブ番号と、ジョブデータの受領時刻と、ジョブデータの要求元の操作部１３１を識別する要求元識別情報とを示すデータが含まれる。また、ジョブテーブルに含まれるジョブデータには、要求されたジョブの種別を示すジョブ種別と、ジョブの処理対象のデータ量（例えば、インストールするプログラムのデータ量、読み取る原稿の枚数等）と、ジョブを構成する１又は複数のタスク（タスク１、タスク２、・・・）の各々の種別とを示すデータが含まれる。

図５は状態テーブルのデータ構成を示した図である。状態テーブルは情報処理装置１１が備える複数のリソースの各々に応じた状態データの集まりである。状態データには、リソースを識別するリソース名と、リソースの現在の状態とを示すデータが含まれる。

図６は使用リソーステーブルのデータ構成を示した図である。使用リソーステーブルはタスクの種別の各々に応じた使用リソースデータの集まりである。使用リソースデータには、タスクの種別を示すタスク種別と、タスクの実行において使用されるリソース及び当該リソースの使用が排他的であるか否かを示すデータと、タスクの実行中にユーザに対する操作を要求するか否かを示すとともにユーザに対する操作を要求する場合はタスクにおける操作の要求のタイミングを示すデータとが含まれる。

図７は処理計画テーブルのデータ構成を示した図である。処理計画テーブルは情報処理装置１１が備えるリソースの各々に応じて設けられている。処理計画テーブルは、ジョブ番号とタスク番号の組み合わせにより特定されるタスクの各々に応じたデータレコードの集まりである。処理計画テーブルに含まれるデータレコードには、ジョブ番号と、タスク番号と、タスクの実行の開始が予定されている時刻（以下、「予定開始時刻」という）と、実際にタスクの実行が開始された時刻（以下、「開始時刻」という）と、推定されるタスクの実行に要する時間（以下、「推定所要時間」という）と、タスクの実行が完了した時刻（以下、「完了時刻」という）とを示すデータが含まれる。

図３に示されるように、端末装置１２（１）～１２（ｎ）は操作部１３１（１）～１３１（ｎ）を備える。操作部１３１（１）～１３１（ｎ）は、ユーザに操作を促す画像を表示するとともにユーザの操作を受け付ける。操作部１３１（１）～１３１（ｎ）は、例えば端末装置１２がデスクトップ型コンピュータやノートブック型コンピュータであればプロセッサとプロセッサの制御下で動作するディスプレイ及びキーボード等の入力装置により実現され、端末装置１２がタブレット型コンピュータであればプロセッサとプロセッサの制御下で動作するディスプレイ及びタッチパッドにより実現される。

図８は指示部１１２が行う処理のフローを示した図である。情報処理装置１１が起動した後、いずれかの操作部１３１に対し、ユーザが処理部１１１により行われる何らかの処理を要求するための操作を行うと、操作の行われた操作部１３１から指示部１１２に対し要求された処理の内容を示すジョブデータが送信される。操作部１３１から送信されたジョブデータはジョブデータ取得部１１２２により取得され、ジョブテーブル（図４）に格納される。

また、処理部１１１は、画像形成部１１１１等の状態が変化すると、変化後の状態を示す状態データを指示部１１２に引き渡す。処理部１１１から引き渡された状態データは状態データ取得部１１２３により取得され、状態テーブル（図５）に格納される。

イベント検知部１１２４は記憶部１１２１に記憶されているジョブテーブル及び状態テーブルを監視し、これらのテーブルの更新（監視対象のイベントの一例）を検知する。イベント検知部１１２４によりジョブテーブル又は状態テーブルの更新が検知されると（ステップＳ０１；Ｙｅｓ）、処理計画生成部１１２５はジョブテーブル、状態テーブル及び使用リソーステーブルに格納されているデータに基づき、処理部１１１の処理計画を生成し（ステップＳ０２）、生成した処理計画を示すように処理計画テーブル（図７）のデータを更新する（ステップＳ０３）。ステップＳ０２において処理計画生成部１１２５が処理計画を生成する手順については後述する。

イベント検知部１１２４は、ジョブテーブル及び状態テーブルに加え、記憶部１１２１に記憶されている処理計画テーブルも監視し、処理計画テーブルの更新を検知する。イベント検知部１１２４により処理計画テーブルの更新が検知されると、通知部１１２７は更新後の処理計画テーブルに格納されているデータが示す実行中又は未実行のジョブの各々に関し、当該ジョブの状態（実行中、未実行等）と、当該ジョブの更新後の完了時刻と、当該ジョブがユーザに対する操作を要求する場合、当該操作の要求時刻とを示す通知データを生成し、生成した通知データを当該ジョブの要求元の操作部１３１に送信する（ステップＳ０４）。その後、指示部１１２は処理をステップＳ０１に戻す。

操作部１３１は、指示部１１２から通知データを受信すると、受信した通知データが示すジョブの状態、完了時刻及びユーザに対する操作の要求時刻をユーザに通知する画面（以下、「通知画面」という）を表示する。図９は、通知画面を例示した図である。

続いて、ステップＳ０３において処理計画生成部１１２５が処理計画を生成する手順を、具体例を用いて説明する。図１０は処理計画生成部１１２５が処理計画を生成する手順を説明するための図である。図１０の横軸は時刻を示す。図１０（ａ）は、何も処理を行っていない状態の処理部１１１が、ジョブ番号が「１２３３」であるジョブ（以下、「ジョブ１２３３」のようにいう）を要求するジョブデータを時刻ｔ₁₁に取得し、当該ジョブデータの取得をトリガとして処理計画生成部１１２５がステップＳ０２において生成する処理計画を示す。

ジョブ１２３３の種別はアプリケーションインストールであり、タスク１「データダウンロード」、タスク２「インストール」、タスク３「アドレス帳更新」及びタスク４「再起動」で構成されている。処理計画生成部１１２５は、まず、これらのタスクの各々の所要時間を、タスクの種別とジョブの処理対象のデータ量に基づき推定する。

なお、処理計画生成部１１２５が処理計画を生成する時点でジョブの処理対象のデータ量が不明な場合、処理計画生成部１１２５はジョブに対し既定値として与えられているデータ量を用いてタスクの所要時間を推定する。例えば、原稿読取という種別のタスクの所要時間は、ユーザによってセットされる原稿の枚数によって増減するため、タスクの実行前に処理対象の枚数は不明である。この場合、処理計画生成部１１２５は原稿読取という種別のジョブに既定値として与えられる枚数（例えば、最大枚数として想定される１００枚）の原稿がセットされると仮定して所要時間を推定する。

処理計画生成部１１２５は、ジョブ１２３３のタスクの各々の所要時間を推定すると、続いて、図１０（ａ）に示すように、ジョブ１２３３の要求された時刻ｔ₁₁にタスク１を開始し、タスク１が完了する時刻ｔ₁₂にタスク２を開始し、タスク２が完了する時刻ｔ₁₃にタスク３を開始し、タスク４が完了する時刻ｔ₁₄にタスク５を開始し、時刻ｔ₁₅にジョブ１２３３の全てのタスクが完了する、という処理計画を生成する。

時刻ｔ₁₁から時刻ｔ₁₂までの期間（以下、「期間ｔ₁₁－ｔ₁₂」のようにいう）の長さは処理計画生成部１１２５が推定したタスク１の所要時間である。同様に、期間ｔ₁₂－ｔ₁₃の長さは処理計画生成部１１２５が推定したタスク２の所要時間であり、期間ｔ₁₃－ｔ₁₄の長さは処理計画生成部１１２５が推定したタスク３の所要時間であり、期間ｔ₁₄－ｔ₁₅の長さは処理計画生成部１１２５が推定したタスク４の所要時間である。

ジョブ１２３３には先着のジョブがなく、先着のジョブとの間にリソース使用における競合は生じない。そのため、処理計画生成部１１２５はリソース使用における競合を解消するためのタスクの開始時刻の調整（後述）を行う必要がない。従って、処理計画生成部１１２５は図１０（ａ）に示される処理計画を示すように、処理計画テーブル（図７）のデータを更新する（ステップＳ０３）。

図１０（ｂ）は、処理部１１１が、図１０（ａ）の処理計画に従いジョブ１２３３を実行中の時刻ｔ₂₁に、新たなジョブ１２３４を要求するジョブデータを取得した場合に、当該ジョブデータの取得をトリガとして処理計画生成部１１２５がステップＳ０２において生成する仮の処理計画を示す。この仮の処理計画は、先着のジョブ１２３３と後着のジョブ１２３４との間のリソース使用における競合を考慮せずに生成された処理計画（以下、「競合調整前の処理計画」という）である。

ジョブ１２３４の種別はスキャンであり、タスク１「原稿読取」及びタスク２「データ転送」で構成される。競合調整前の処理計画に従う場合、処理部１１１は、ジョブ１２３４の要求された時刻ｔ₂₁にタスク１を開始し、タスク１が完了する時刻ｔ₂₂にタスク２を開始し、時刻ｔ₂₃にジョブ１２３４の全てのタスクが完了することになる。

期間ｔ₂₁－ｔ₂₂の長さは処理計画生成部１１２５が推定したジョブ１２３４のタスク１の所要時間であり、期間ｔ₂₂－ｔ₂₃の長さは処理計画生成部１１２５が推定したジョブ１２３４のタスク２の所要時間である。

続いて、処理計画生成部１１２５は使用リソーステーブル（図６）を参照し、先着のジョブ１２３３と後着のジョブ１２３４との間にリソース使用における競合の有無を判定し、競合があれば競合が解消されるように、後着のジョブ１２３４のタスクの開始時刻を後ろにずらす。

図１０（ｂ）の処理計画においては、ジョブ１２３３のタスク３「アドレス帳更新」が実行される期間ｔ₁₃－ｔ₁₄においてアドレスデータベースが使用不可となり、タスク４「再起動」が実行される期間ｔ₁₄－ｔ₁₅において全てのリソースが使用不可となる。

ジョブ１２３４のタスク１「原稿読取」はアドレスデータベースを使用しないため、ジョブ１２３３のタスク３「アドレス帳更新」が実行される期間ｔ₁₃－ｔ₁₄において実行可能である。ただし、ジョブ１２３３のタスク４「再起動」が実行される期間ｔ₁₄－ｔ₁₅においては、ジョブ１２３４のタスク１「原稿読取」は実行不可能である。従って、処理計画生成部１１２５は、ジョブ１２３４のタスク１「原稿読取」を速やかに開始した場合、このタスク１「原稿読取」が時刻ｔ₁₄までに完了するか否かを判定する。図１０（ｂ）の例の場合、ジョブ１２３４のタスク１「原稿読取」を速やかに開始した場合、このタスク１「原稿読取」は時刻ｔ₁₄までに完了する。従って、処理計画生成部１１２５はジョブ１２３４のタスク１「原稿読取」の開始時刻を後ろにずらすことなく維持する。

一方、ジョブ１２３４のタスク２「データ転送」はアドレスデータベースを使用するため、ジョブ１２３３のタスク３「アドレス帳更新」が実行される期間ｔ₁₃－ｔ₁₄において実行不可能である。さらに、ジョブ１２３４のタスク２「データ転送」は、ジョブ１２３３のタスク４「再起動」が実行される期間ｔ₁₄－ｔ₁₅においても実行不可能である。従って、処理計画生成部１１２５は、ジョブ１２３４のタスク２「データ転送」の開始時刻を、ジョブ１２３３のタスク４「再起動」が完了する時刻ｔ₁₅までずらす。これにより、先着のジョブ１２３３と後着のジョブ１２３４との間にリソース使用における競合が生じなくなる。

図１０（ｃ）は、処理計画生成部１１２５が、上記のように競合を解消するように後着のジョブ１２３４に含まれるタスク２「データ転送」の開始時刻を調整した後の処理計画（以下、「競合調整後の処理計画」という）を示した図である。図１０（ｃ）に示されるように、この場合、ジョブ１２３４の完了時刻は時刻ｔ₂₄となる。処理計画生成部１１２５は、上記のように生成した競合調整後の処理計画を示すように、処理計画テーブル（図７）のデータを更新する（ステップＳ０３）。

図１０（ｄ）は、従来技術に従い、タスク単位ではなくジョブ単位でリソース使用における競合を解消するように生成された処理計画を示した図である。ジョブ単位でリソース使用における競合を解消する場合、全てのリソースが使用不可となる再起動を伴う先着のジョブ１２３３が完了する時刻ｔ₁₅まで後着のジョブ１２３４は実行されない。すなわち、ジョブ１２３４の開始時刻はジョブ１２３３が完了する時刻ｔ₁₅までずらされる。そのため、ジョブ１２３４が完了する時刻は時刻ｔ₂₆となる。

図１０（ｄ）に示される処理計画に従う場合、後着のジョブ１２３４が要求されてから完了するまでの時間は、後着のジョブ１２３４が要求された時点における先着のジョブ１２３３の未処理部分の所要時間と後着のジョブ１２３４の所要時間の合計値となる。

図１０（ｃ）と図１０（ｄ）を比較すると明らかなように、本実施例に係る指示部１１２の処理計画生成部１１２５により生成される処理計画に従う場合、従来技術によって生成される処理計画に従う場合と比較し、時間Ｔ₁だけ後着のジョブ１２３４の完了時刻が早くなる。

図１１～図１３は、ステップＳ０２において処理計画生成部１１２５が処理計画を生成する手順を説明するための、図１０とは別の例を示した図である。

図１１は、時刻ｔ₁₁にジョブ０００１の要求があった後、時刻ｔ₂₁にジョブ０００２の要求があった場合に、処理計画生成部１１２５が生成する競合調整前の処理計画（図１１（ａ））と、競合調整後の処理計画（図１１（ｂ））を示した図である。

ジョブ０００２のタスク１はジョブ０００１のタスク２と同時に実行されるとリソース使用における競合を生じ、また、ジョブ０００２のタスク２はジョブ０００１のタスク３と同時に実行されるとリソース使用における競合を生じることが想定されている。

処理計画生成部１１２５は、図１１（ａ）に示される競合調整前の処理計画を生成した後、まず後着のジョブ０００２のタスク１に着目し、ジョブ０００２のタスク１と先着のジョブのタスクとの間でリソース使用における競合が生じるか否かを判定する。この場合、競合が生じるため、処理計画生成部１１２５はジョブ０００２のタスク１の開始時刻を、競合が解消する最も早い時刻である時刻ｔ₁₃にずらす。

続いて、処理計画生成部１１２５は後着のジョブ０００２のタスク２に着目し、ジョブ０００２のタスク２と先着のジョブのタスクとの間で生じているリソース使用における競合が生じるか否かを判定する。この場合、競合が生じるため、処理計画生成部１１２５はジョブ０００２のタスク２の開始時刻を、競合が解消する最も早い時刻である時刻ｔ₁₄にずらす。これにより、図１１（ｂ）に示される競合調整後の処理計画が生成される。

図１２は、処理部１１１が図１１（ｂ）に示される処理計画に従い処理を行っている状況下で、時刻ｔ₃₁にジョブ０００３の要求があった場合に、処理計画生成部１１２５が生成する競合調整前の処理計画（図１２（ａ））と、競合調整後の処理計画（図１２（ｂ））を示した図である。

ジョブ０００３のタスク１はジョブ０００１のタスク３と同時に実行されるとリソース使用における競合を生じ、また、ジョブ０００３のタスク２はジョブ０００２のタスク１と同時に実行されるとリソース使用における競合を生じることが想定されている。

処理計画生成部１１２５は、図１２（ａ）に示される競合調整前の処理計画を生成した後、まず後着のジョブ０００３のタスク１に着目し、ジョブ０００３のタスク１と先着のジョブのタスクとの間でリソース使用における競合が生じるか否かを判定する。この場合、競合は生じないため、処理計画生成部１１２５はジョブ０００３のタスク１の開始時刻を時刻ｔ₃₁から変更しない。

続いて、処理計画生成部１１２５は後着のジョブ０００３のタスク２に着目し、ジョブ０００３のタスク２と先着のジョブのタスクとの間でリソース使用における競合が生じるか否かを判定する。この場合、競合が生じるため、処理計画生成部１１２５はジョブ０００３のタスク２の開始時刻を、競合が解消する最も早い時刻である時刻ｔ₂₄にずらす。これにより、図１２（ｂ）に示される競合調整後の処理計画が生成される。

図１３は、処理部１１１が図１２（ｂ）に示される処理計画に従い処理を行っている状況下で、時刻ｔ₄₁にジョブ０００４の要求があった場合に、処理計画生成部１１２５が生成する競合調整前の処理計画（図１３（ａ））と、競合調整後の処理計画（図１３（ｂ））を示した図である。

ジョブ０００４のタスク１はジョブ０００１のタスク２と同時に実行されるとリソース使用における競合を生じ、また、ジョブ０００４のタスク２はジョブ０００２のタスク２又はジョブ０００３のタスク１と同時に実行されるとリソース使用における競合を生じることが想定されている。

処理計画生成部１１２５は、図１３（ａ）に示される競合調整前の処理計画を生成した後、まず後着のジョブ０００４のタスク１に着目し、ジョブ０００４のタスク１と先着のジョブのタスクとの間でリソース使用における競合が生じるか否かを判定する。この場合、競合が生じるため、処理計画生成部１１２５はジョブ０００４のタスク１の開始時刻を、競合が解消する最も早い時刻である時刻ｔ₁₃にずらす。

続いて、処理計画生成部１１２５は後着のジョブ０００４のタスク２に着目し、ジョブ０００４のタスク２と先着のジョブのタスクとの間でリソース使用における競合が生じるか否かを判定する。この場合、競合が生じるため、処理計画生成部１１２５はジョブ０００４のタスク２の開始時刻を、競合が解消する最も早い時刻である時刻ｔ₂₄にずらす。これにより、図１３（ｂ）に示される競合調整後の処理計画が生成される。

上記のように、処理計画生成部１１２５は新たなジョブの要求があれば、競合調整前の処理計画を生成した後、後着のジョブのタスク１に着目し、着目したタスクと先着のいずれかのジョブのタスクとの間でリソース使用における競合が生じるか否かを判定する。そして、競合が生じないと判定した場合、処理計画生成部１１２５は着目しているタスクの開始時刻を変更しない。一方、競合が生じると判定した場合、処理計画生成部１１２５は着目しているタスクの開始時刻を、競合が解消する最も早い時刻にずらす。

処理計画生成部１１２５は、続いて、後着のジョブのタスク２、タスク３、・・・と順次、着目するタスクを変更し、タスク１に関し上述した競合の有無の判定及び開始時刻の変更と同様の処理を、着目したタスクに関し行う。そして、処理計画生成部１１２５が後着のジョブの最後のタスクに関し競合の有無の判定及び開始時刻の変更を完了した際に生成されている処理計画が競合調整後の処理計画となる。

上述した情報処理システム１が備える指示部１１２は、ジョブ単位で要求される処理を実行する処理部１１１に対し異なるタイミングで要求された２つのジョブのうち先着のジョブを構成する複数のタスクのうちいずれかのタスクが実行されている間に使用されていないリソースを用いて、当該２つのジョブのうち後着のジョブを構成する複数のタスクのうちいずれかのタスクの実行が可能であるか否かを判定する。そして、指示部１１２は、後着のジョブを構成するいずれかのタスクの実行が可能であると判定した場合、当該タスクの実行を処理部１１１に指示する。

上記のような構成を備える情報処理システム１によれば、情報処理システム１が複数のジョブの要求を受けた場合、リソース使用における競合が避けられ、かつ、後着のジョブが要求されてから完了するまでの時間が、後着のジョブが要求された時点における先着のジョブの未処理部分の所要時間と後着のジョブの所要時間の合計値より短縮される。

また、上述した情報処理システム１が備える通知部１１２７は、後着のジョブが実行中にユーザに対する操作の要求を伴う場合、当該操作の要求時刻をユーザに通知する。従って、後着のジョブを要求したユーザは操作の要求時刻を知ることができる。

また、上述した情報処理システム１が備える指示部１１２は、監視対象のイベントの発生をトリガに、先着のジョブのいずれかのタスクが実行されている間に使用されていないリソースを用いて後着のジョブのいずれかのタスクの実行が可能であるか否かを判定する。従って、監視対象のイベントが発生する毎に、後着のジョブの完了時刻が早められるか否かが判定される。

［２］変形例
上述した実施例は本発明の実施の一例に過ぎず、以下のように変形されてもよい。また、実施例及び各変形例は、必要に応じて組み合わせて実施されてもよい。

［２－１］第１変形例
上述した実施例においては、先着のジョブの完了時刻が、後着のジョブの実行によって遅延することはない。本発明はこの点において限定されず、後着のジョブの実行によって先着のジョブの完了時刻が遅延することが許容されてもよい。後着のジョブの実行によって先着のジョブの完了時刻が遅延することを許容するように上述した実施例を変形した第１変形例を以下に説明する。

第１変形例に係る記憶部１１２１には、ジョブの優先度と、優先度に応じた遅延時間の許容範囲を示すデータを格納するテーブル（以下、「ジョブ優先度テーブル」という）が記憶されている。

図１４はジョブ優先度テーブルの内容を例示した図である。例えば、図１４に示されるジョブ優先度テーブルの第１行に格納されているデータは、ジョブ種別が「プリントアウト」であるジョブは優先度が高く、遅延時間の許容範囲が所要時間の０倍であることを示している。この場合、ジョブ種別が「プリントアウト」であるジョブの完了時刻が後着のジョブの実行により遅延することは一切許容されない。

また、例えば、図１４に示されるジョブ優先度テーブルの第４行に格納されているデータは、ジョブ種別が「ＦＡＸ送信」であるジョブは優先度が中程度であり、遅延時間の許容範囲が所要時間の０．５倍であることを示している。この場合、ジョブ種別が「ＦＡＸ送信」であるジョブの完了時刻が後着のジョブの実行によって遅延する場合であっても、その遅延時間がこのジョブの本来の所要時間の０．５倍以下であれば、後着のジョブの実行が許容される。

図１５は第１変形例に係る処理計画生成部１１２５が処理計画を生成する手順を説明するための図である。図１５（ａ）は、時刻ｔ₁₁にジョブ０００１の要求があった後、時刻ｔ₂₁にジョブ０００２の要求があった場合に、処理計画生成部１１２５が生成する競合調整前の処理計画を示している。ジョブ０００２のタスク１はジョブ０００１のタスク２と同時に実行されるとリソース使用における競合を生じることが想定されている。また、ジョブ０００１の所要時間は時間Ｔ₂である。

処理計画生成部１１２５は、後着のジョブ０００２のタスク１に着目し、ジョブ０００２のタスク１を時刻ｔ₂₁に開始可能か否かを判定する。この場合、時刻ｔ₂₁において先着のジョブ０００１のタスク２は開始されていないため、処理計画生成部１１２５はジョブ０００２のタスク１を時刻ｔ₂₁に開始可能と判定する。

続いて、処理計画生成部１１２５は、ジョブ０００２のタスク１を時刻ｔ₂₁に開始した場合、先着のジョブ０００１のタスクのうち、ジョブ０００２のタスク１との間でリソース使用における競合を生じるタスクを特定する。この場合、ジョブ０００１のタスク２が競合を生じるタスクとして特定される。

続いて、処理計画生成部１１２５は、上記のように特定した先着のジョブ０００１のタスク２の開始時刻を、競合が解消する最も早い時刻である時刻ｔ₂₂にずらす。図１５（ｂ）は、ジョブ０００１のタスク２の開始時刻が時刻ｔ₂₂にずらされた状態の処理計画を示している。この場合、ジョブ０００１の完了時刻の遅延時間は時間Ｔ₃となる。

処理計画生成部１１２５はジョブ優先度テーブル（図１４）を参照し、ジョブ０００１の種別に応じた遅延時間の許容範囲を特定する。例えば、ジョブ０００１の種別が「プリントアウト」であれば、ジョブ０００１の遅延時間の許容範囲は所要時間Ｔ₂の０倍、すなわち、遅延は許容されない。従って、処理計画生成部１１２５は図１５（ｂ）に示される処理計画を破棄し、後着のジョブ０００２のタスク１の開始時刻を、競合が解消する最も早い時刻である時刻ｔ₁₃にずらす。図１５（ｃ）は、ジョブ０００２のタスク１の開始時刻が時刻ｔ₁₃にずらされた状態の処理計画を示している。この場合、図１５（ｃ）に示される処理計画が、競合調整後の処理計画となる。

一方、例えば、ジョブ０００１の種別が「ＦＡＸ送信」であれば、ジョブ０００１の遅延時間の許容範囲は所要時間Ｔ₂の０．５倍となる。処理計画生成部１１２５は、図１５（ｂ）に示される処理計画に従う場合、ジョブ０００１の完了時刻の遅延時間Ｔ₃が、ジョブ０００１の所要時間Ｔ₂の０．５倍以下であるか否かを判定する。この場合、遅延時間Ｔ₃は所要時間Ｔ₂の０．５倍以下であるため、処理計画生成部１１２５は図１５（ｂ）に示される処理計画を、競合調整後の処理計画として採用する。

上述した第１変形例に係る情報処理システム１が備える指示部１１２は、先着のジョブを構成する複数のタスクのうちいずれかのタスクが実行されている間に使用されていないリソースを用いて後着のジョブを構成する複数のタスクのうちいずれかのタスクの実行が可能であり、かつ、当該タスクの実行により先着のジョブの完了時刻の遅延時間が許容範囲内であると判定した場合、当該タスクの実行を処理部１１１に指示する。従って、後着のジョブの完了時刻を早めるために、先着のジョブの完了時刻が許容範囲を超えて遅延することはない。

また、上述した第１変形例に係る情報処理システム１が備える指示部１１２は、先着のジョブの優先度に応じて異なる許容範囲を用いる。従って、後着のジョブの完了時刻を早めるために、先着のジョブの完了時刻が先着のジョブの優先度に応じた許容範囲を超えて遅延することはない。

［２－２］第２変形例
上述した第１変形例においては、先着のジョブの完了時刻の遅延時間が許容範囲内であるか否かによって、先着のジョブの実行中における後着のジョブの実行の可否が決定される。第２変形例においては、先着のジョブが実行中にユーザに対する操作の要求を伴う場合、当該操作の要求時刻の遅延時間が許容範囲内であるか否かによって、先着のジョブの実行中における後着のジョブの実行の可否が決定される。

図１６は第２変形例に係る処理計画生成部１１２５が処理計画を生成する手順を説明するための図である。図１６（ａ）は、時刻ｔ₁₁にジョブ０００１の要求があった後、時刻ｔ₂₁にジョブ０００２の要求があった場合に、処理計画生成部１１２５が生成する競合調整前の処理計画を示している。ジョブ０００２のタスク１はジョブ０００１のタスク２と同時に実行されるとリソース使用における競合を生じることが想定されている。また、ジョブ０００１のタスク２の完了時刻には、ユーザに対する操作（例えば、追加原稿の有無確認のための操作）の要求が行われることが想定されている。

処理計画生成部１１２５は、後着のジョブ０００２のタスク１に着目し、ジョブ０００２のタスク１を時刻ｔ₂₁に開始可能か否かを判定する。この場合、時刻ｔ₂₁において先着のジョブ０００１のタスク２は開始されていないため、処理計画生成部１１２５はジョブ０００２のタスク１を時刻ｔ₂₁に開始可能と判定する。

続いて、処理計画生成部１１２５は、ジョブ０００２のタスク１を時刻ｔ₂₁に開始した場合、先着のジョブ０００１のタスクのうち、ジョブ０００２のタスク１との間でリソース使用における競合を生じるタスクを特定する。この場合、ジョブ０００１のタスク２が競合を生じるタスクとして特定される。

続いて、処理計画生成部１１２５は、上記のように特定した先着のジョブ０００１のタスク２の開始時刻を、競合が解消する最も早い時刻である時刻ｔ₂₂にずらす。図１６（ｂ）は、ジョブ０００１のタスク２の開始時刻が時刻ｔ₂₂にずらされた状態の処理計画を示している。この場合、ジョブ０００１のタスク２の完了時刻は時刻ｔ₁₃から時刻ｔ₁₅へずれる。従って、図１６（ｂ）に示される処理計画に従う場合、ジョブ０００１の実行に伴うユーザに対する操作の要求時刻の遅延時間は時間Ｔ₄となる。

処理計画生成部１１２５は、操作の要求時刻の遅延時間Ｔ₄が、予め定められた許容範囲内（例えば、３０秒以下）であるか否かを判定する。遅延時間Ｔ₄が許容範囲外であれば、処理計画生成部１１２５は図１６（ｂ）に示される処理計画を破棄し、後着のジョブ０００２のタスク１の開始時刻を、競合が解消する最も早い時刻である時刻ｔ₁₃にずらす。図１６（ｃ）は、ジョブ０００２のタスク１の開始時刻が時刻ｔ₁₃にずらされた状態の処理計画を示している。この場合、図１６（ｃ）に示される処理計画が、競合調整後の処理計画となる。

一方、遅延時間Ｔ₄が許容範囲内であれば、処理計画生成部１１２５は、図１６（ｂ）に示される処理計画を、競合調整後の処理計画として採用する。

図１６（ｂ）に示される処理計画が競合調整後の処理計画として採用された場合、先着のジョブを要求したユーザに対し操作の要求が行われる時刻が変更されることになる。従って、ユーザに対しその旨が通知されることが望ましい。図１７は第２変形例において、先着のジョブを要求したユーザに対する操作の要求時刻が変更された場合に、当該ユーザが用いる操作部１３１に表示される通知画面を例示した図である。

上述した第２変形例に係る情報処理システム１が備える指示部１１２は、先着のジョブのいずれかのタスクが実行されている間に使用されていないリソースを用いて後着のジョブのいずれかのタスクの実行が可能であり、かつ、当該タスクの実行により先着のジョブに伴うユーザに対する操作の要求時刻の遅延時間が許容範囲内であると判定した場合、当該タスクの実行を処理部１１１に指示する。従って、後着のジョブの完了時刻を早めるために、先着のジョブに伴うユーザに対する操作の要求時刻が許容範囲を超えて遅延することはない。

また、上述した第２変形例に係る情報処理システム１が備える通知部１１２７は、先着のジョブの実行に伴うユーザに対する操作の要求時刻を当該ユーザに通知する。従って、後着のジョブの完了時刻を早めるために、先着のジョブに伴うユーザに対する操作の要求時刻が変化した場合、先着のジョブを要求したユーザは変化後の操作の要求時刻を知ることができる。

［２－３］第３変形例
第３変形例においては、先着のジョブのタスクとの間で生じるリソースの利用における競合を解消するために、後着のジョブのタスクの開始時刻が後ろにずらされる場合、当該リソースを代替する代替リソースが使用可能であり、代替リソースを用いることによって後着のジョブのタスクの完了時刻が早まるならば、代替リソースが使用される。

図１８は第３変形例に係る情報処理システム２の全体構成を示した図である。情報処理システム２は、情報処理システム１が備える情報処理装置１１と端末装置１２（１）～１２（ｎ）に加え、情報処理装置１１と同様の構成を備える情報処理装置２１（１）～２１（ｍ）（ただし、ｍは任意の自然数）を備える。以下、情報処理装置２１（１）～２１（ｍ）を互いに区別しない場合、それらを「情報処理装置２１」という。情報処理装置１１と情報処理装置２１の各々は無線及び有線の少なくとも一方により互いに通信可能である。

図１９は第３変形例に係る指示部１１２が行う処理のフローを示した図である。また、図２０は第３変形例に係る処理計画生成部１１２５が処理計画を生成する手順を説明するための図である。

指示部１１２は、まず、上述した実施例におけるステップＳ０１～Ｓ０４と同様の処理を行う。ステップＳ０２において、処理計画生成部１１２５は、図２０（ａ）に示される競合調整前の処理計画を生成するものとする。ジョブ０００２のタスク２はジョブ０００１のタスク２と同時に実行されるとリソース使用における競合を生じることが想定されている。この場合、処理計画生成部１１２５はリソース使用における競合を解消するために、ジョブ０００２のタスク２の開始時刻を時刻ｔ₁₃にずらす。図２０（ｂ）はジョブ０００２のタスク２の開始時刻が時刻ｔ₁₃にずらされた状態の処理計画を示している。ステップＳ０３において、処理計画生成部１１２５は図２０（ｂ）の処理計画を示すように処理計画テーブルを更新する。その後、通知部１１２７はジョブ０００１及びジョブ０００２の要求元の操作部１３１に通知データを送信し、それらの操作部１３１には通知画面が表示される（ステップＳ０４）。

続いて、処理計画生成部１１２５は、ステップＳ０２において生成した処理計画において、先着のジョブとの間でリソース使用における競合を解消するために開始時刻が後ろにずらされた後着のジョブのタスクがあるか否かを判定する（ステップＳ０５）。開始時刻が後ろにずらされた後着のジョブのタスクがない場合（ステップＳ０５；Ｎｏ）、指示部１１２は処理をステップＳ０１に戻す。

一方、開始時刻が後ろにずらされた後着のジョブのタスクがある場合（ステップＳ０５；Ｙｅｓ）、指示部１１２は開始時刻が後ろにずらされた後着のジョブのタスク（該当するタスクが複数ある場合は、例えば開始時刻が最も早いタスク）の代行を依頼した場合に要する時間を問い合わせる照会データを生成し、生成した照会データを情報処理装置２１の各々に送信する（ステップＳ０６）。図２０の例の場合、指示部１１２は情報処理装置２１の各々に、ジョブ０００２のタスク２に関する照会データを送信する。

情報処理装置１１から照会データを受信した情報処理装置２１は、照会データに応じて、代行対象のタスクを実行可能であるか否かを判定し、実行可能である場合は代行対象のタスクの完了までに要する時間を示すデータを、照会データに対する応答データとして情報処理装置１１に送信する。

処理計画生成部１１２５は、ステップＳ０６において送信した照会データに対する応答データがいずれかの情報処理装置２１から受信されたか否かを判定する（ステップＳ０７）。いずれの情報処理装置２１からも応答データが受信されなかった場合（ステップＳ０７；Ｎｏ）、指示部１１２は処理をステップＳ０１に戻す。

一方、いずれかの情報処理装置２１から応答データが受信された場合（ステップＳ０７；Ｙｅｓ）、処理計画生成部１１２５は応答データが示す時間（応答データが複数ある場合はそれらの応答データが示す時間のうち最短のもの）で代行対象のタスクが実行された場合、図２０（ｂ）に示される現状の処理計画に従う場合と比較し、代行対象のタスクの完了時刻が早まるか否かを判定する（ステップＳ０８）。

代行対象のタスクの完了時刻が早まらない場合（ステップＳ０８；Ｎｏ）、指示部１１２は処理をステップＳ０１に戻す。一方、代行対象のタスクの完了時刻が早まる場合（ステップＳ０８；Ｙｅｓ）、処理計画生成部１１２５は応答データ（応答データが複数ある場合は最短の時間を示すもの）の送信元の情報処理装置２１にタスクの代行を依頼した場合の処理計画を生成する（ステップＳ０９）。図２０（ｃ）は、ステップＳ０９において処理計画生成部１１２５が生成する処理計画を例示している。

続いて、通知部１１２７は、代行対象のタスクを含むジョブの要求元の操作部１３１に、代替リソースが使用可能であることを通知するとともに代替リソースが使用された場合の影響を通知し、代替リソースの使用の可否を問い合わせる通知データを送信する（ステップＳ１０）。図２１は、ステップＳ１０において通知部１１２７から送信された通知データに従い操作部１３１が表示する通知画面を例示している。ユーザが通知画面において代替リソースの使用を許可又は禁止する操作を行うと、操作部１３１から情報処理装置１１にユーザの操作に応じた応答データが送信される。

処理計画生成部１１２５は、ステップＳ１０において操作部１３１に送信された通知データに対する応答データが代替リソースの使用の許可を示すか否かを判定する（ステップＳ１１）。応答データが代替リソースの使用の許可を示さない場合（ステップＳ１１；Ｎｏ）、指示部１１２は処理をステップＳ０１に戻す。一方、応答データが代替リソースの使用の許可を示す場合（ステップＳ１１；Ｙｅｓ）、指示部１１２はステップＳ０６において送信した照会データに対する応答データ（応答データが複数ある場合は最短の時間を示すもの）の送信元の情報処理装置２１に、タスクの代行を依頼するジョブデータを送信する（ステップＳ１２）。

続いて、処理計画生成部１１２５は、ステップＳ０９において生成した処理計画を示すように、処理計画テーブルを更新する（ステップＳ１３）。続いて、通知部１１２７は、ステップＳ１３において更新された処理計画テーブルが示すジョブの完了時刻等を通知する通知データを生成し、ジョブの要求元の操作部１３１に送信する（ステップＳ１４）。その後、指示部１１２は処理をステップＳ０１に戻す。

上述した第３変形例に係る情報処理システム２が備える指示部１１２は、先着のジョブのいずれかのタスクが実行されている間に使用されているリソースが使用可能となった後に当該リソースを使用して後着のジョブのいずれかのタスクが実行された場合の当該タスクの完了時刻よりも、当該リソースを代替する代替リソース（情報処理装置２１が備えるリソース）を使用して当該タスクが実行された場合の当該タスクの完了時刻が早い場合、代替リソースを使用した当該タスクの実行を処理部（情報処理装置２１の処理部）に指示する。従って、代替リソースを使用せずに後着のジョブが実行された場合と比較し、後着のジョブの完了時刻が早まる。

また、上述した第３変形例に係る情報処理システム２が備える通知部１１２７は、指示部１１２により代替リソースを使用したタスクの実行が処理部に指示される前に、後着のジョブを要求したユーザに対し代替リソースが使用されることを通知する。従って、後着のジョブを要求したユーザは、後着のジョブの実行に代替リソースが使用されることを知ることができる。

［２－４］その他の変形例
（１）処理部１１１が実行可能な処理の種別は上述した実施例に示したものに限られない。

（２）情報処理装置１１が備える構成部が、複数の装置に分散配置されてもよい。例えば、処理部１１１と指示部１１２が互いに通信可能な異なる装置に配置されてもよい。

（３）指示部１１２は、先着のジョブの実行中に、先着のジョブとの間で競合が生じないリソースを用いて後着のジョブのタスクの実行を処理部１１１に指示する限り、処理計画を生成しなくてもよい。

（４）上述した第３変形例においては、代替リソースが指示部１１２を備える情報処理装置１１とは異なる装置に配置されているものとしたが、情報処理装置１１が備える代替リソースが使用されてもよい。

（５）上述した第３変形例においては、代替リソースを備える情報処理装置２１が情報処理装置１１と同様の構成を備えるものとしたが、代替リソースを備える装置は情報処理装置１１と異なる構成であってもよい。例えば、情報処理装置１１と通信可能な記憶装置、画像形成装置、ＦＡＸ送受信装置、画像読取装置等が備えるリソースが、代替リソースとして用いられてもよい。

（６）イベント検知部１１２４が監視するイベントは、ジョブテーブル、状態テーブル及び処理計画テーブルの更新に限られない。例えば、一定時間の経過が監視対象のイベントであってもよい。

（７）第１変形例においては、先着のジョブの完了時刻の遅延時間に関する許容範囲として、ジョブの優先度に応じた一定倍数を所要時間に乗じた時間が用いられるものとした。先着のジョブの完了時刻の遅延時間に関する許容範囲の形態はこれに限られない。例えば、ジョブの優先度に関係なく所要時間に一定の倍数を乗じた時間が遅延時間の許容範囲として用いられてもよいし、固定時間長が遅延時間の許容範囲として用いられてもよい。

（８）第１変形例においては、後着のジョブの実行による先着のジョブの遅延を許容するか否かの判定は、先着のジョブの完了時刻に基づき行われるものとした。また、第２変形例においては、後着のジョブの実行による先着のジョブの遅延を許容するか否かの判定は、先着のジョブに伴うユーザに対する操作の要求時刻に基づき行われるものとした。後着のジョブの実行による先着のジョブの遅延を許容するか否かの判定の基準は、これらに限られない。

例えば、先着のジョブの完了時刻（第１変形例）及び先着のジョブに伴うユーザに対する操作の要求時刻（第２変形例）に限られず、先着のジョブの実行に伴いユーザに対し通知が行われる他の時刻に基づき、後着のジョブの実行による先着のジョブの遅延を許容するか否かの判定が行われてもよい。例えば、ジョブの進行中に紙切れ等のエラーが発生する可能性がある場合、そのようなエラーの通知がユーザに対し行われる可能性のある時刻（または、そのような通知が発生する可能性のある時期の開始時刻等）が許容範囲であるか否かに基づき、後着のジョブの実行による先着のジョブの遅延を許容するか否かの判定が行われてもよい。

また、後着のジョブの実行による先着のジョブの遅延を許容するか否かの判定の基準として、先着のジョブに関する時刻の変化量又は時間の増減量に代えて、もしくは加えて、後着のジョブに関する時刻の変化量又は時間の増減量が用いられてもよい。例えば、先着のジョブを遅延させた場合に後着のジョブの完了時刻の変化量（完了時刻までの待ち時間の減少量）が閾値以上である場合には、先着のジョブの遅延を許容し、後着のジョブを実行する、といった基準が用いられてもよい。

また、個別のジョブに関する時刻の変化量又は時間の増減量に代えて、複数のジョブに関する時刻の変化量又は時間の増減量が、後着のジョブの実行による先着のジョブの遅延を許容するか否かの判定の基準に用いられてもよい。例えば、先着のジョブのタスクを遅延させた場合に、後着の複数のジョブの完了時刻の変化量（完了時刻までの待ち時間の減少量）の合計値が閾値以上である場合には、先着のジョブの遅延を許容し、後着のジョブを実行する、といった基準が用いられてもよい。また、情報処理システムが備えるリソースの稼働率が閾値以上に増加する場合には、先着のジョブの遅延を許容し、後着のジョブを実行する、といった基準が用いられてもよい。

１…情報処理システム、２…情報処理システム、１１…情報処理装置、１２…端末装置、２１…情報処理装置、１０１…メモリ、１０２…プロセッサ、１０３…ディスプレイ、１０４…タッチパネル、１０５…プリンタユニット、１０６…スキャナユニット、１０７…通信ユニット、１０８…通信ユニット、１１１…処理部、１１２…指示部、１３１…操作部、１１１１…画像形成部、１１１２…画像読取部、１１１３…文字認識部、１１１４…メール送信部、１１１５…ＦＡＸ送受信部、１１１６…データ更新部、１１２１…記憶部、１１２２…ジョブデータ取得部、１１２３…状態データ取得部、１１２４…イベント検知部、１１２５…処理計画生成部、１１２６…指示データ出力部、１１２７…通知部。

Claims (8)

1. ジョブ単位で要求される処理を実行する処理部に対し要求された第１のジョブを構成する複数のタスクのうちいずれかのタスクが実行されている間に使用されていないリソースを用いて前記第１のジョブより後に前記処理部に対し要求された第２のジョブを構成する複数のタスクのうちいずれかのタスクの実行が可能であるか否かを判定し、前記第２のジョブを構成するいずれかのタスクの実行が可能であると判定した場合、当該タスクの実行を前記処理部に指示する指示部を備え、
   前記指示部は、前記第１のジョブを構成する複数のタスクのうちいずれかのタスクが実行されている間に使用されていないリソースを用いて前記第２のジョブを構成する複数のタスクのうちいずれかのタスクの実行が可能であり、かつ、当該タスクの実行により前記第１のジョブの完了時刻の遅延時間が許容範囲内であると判定した場合、当該タスクの実行を前記処理部に指示する
   情報処理システム。
2. 前記指示部は、前記第１のジョブの優先度に応じて異なる前記許容範囲を用いる
   請求項１に記載の情報処理システム。
3. ジョブ単位で要求される処理を実行する処理部に対し要求された第１のジョブを構成する複数のタスクのうちいずれかのタスクが実行されている間に使用されていないリソースを用いて前記第１のジョブより後に前記処理部に対し要求された第２のジョブを構成する複数のタスクのうちいずれかのタスクの実行が可能であるか否かを判定し、前記第２のジョブを構成するいずれかのタスクの実行が可能であると判定した場合、当該タスクの実行を前記処理部に指示する指示部を備え、
   前記第１のジョブは実行中にユーザに対する操作の要求を伴い、
   前記指示部は、前記第１のジョブのいずれかのタスクが実行されている間に使用されていないリソースを用いて前記第２のジョブのいずれかのタスクの実行が可能であり、かつ、当該タスクの実行により前記ユーザに対する操作の要求時刻の遅延時間が許容範囲内であると判定した場合、当該タスクの実行を前記処理部に指示する
   情報処理システム。
4. 前記第１のジョブの実行に伴う前記ユーザに対する操作の要求時刻を前記ユーザに通知する通知部を備える
   請求項３に記載の情報処理システム。
5. ジョブ単位で要求される処理を実行する処理部に対し要求された第１のジョブを構成する複数のタスクのうちいずれかのタスクが実行されている間に使用されていないリソースを用いて前記第１のジョブより後に前記処理部に対し要求された第２のジョブを構成する複数のタスクのうちいずれかのタスクの実行が可能であるか否かを判定し、前記第２のジョブを構成するいずれかのタスクの実行が可能であると判定した場合、当該タスクの実行を前記処理部に指示する指示部を備え、
   前記第２のジョブは実行中にユーザに対する操作の要求を伴い、
   前記第２のジョブの実行に伴う前記ユーザに対する操作の要求時刻を前記ユーザに通知する通知部を備える
   情報処理システム。
6. ジョブ単位で要求される処理を実行する処理部に対し要求された第１のジョブを構成する複数のタスクのうちいずれかのタスクが実行されている間に使用されていないリソースを用いて前記第１のジョブより後に前記処理部に対し要求された第２のジョブを構成する複数のタスクのうちいずれかのタスクの実行が可能であるか否かを判定し、前記第２のジョブを構成するいずれかのタスクの実行が可能であると判定した場合、当該タスクの実行を前記処理部に指示する指示部を備え、
   前記指示部は、前記第１のジョブのいずれかのタスクが実行されている間に使用されているリソースが使用可能となった後に当該リソースを使用して前記第２のジョブのいずれかのタスクが実行された場合の当該タスクの完了時刻よりも、当該リソースを代替する代替リソースを使用して当該タスクが実行された場合の当該タスクの完了時刻が早い場合、前記代替リソースを使用した当該タスクの実行を前記処理部に指示する
   情報処理システム。
7. 前記指示部により前記代替リソースを使用したタスクの実行が前記処理部に指示される前に、前記第２のジョブを要求したユーザに対し前記代替リソースが使用されることを通知する通知部を備える
   請求項６に記載の情報処理システム。
8. ジョブ単位で要求される処理を実行する処理部に対し要求された第１のジョブを構成する複数のタスクのうちいずれかのタスクが実行されている間に使用されていないリソースを用いて前記第１のジョブより後に前記処理部に対し要求された第２のジョブを構成する複数のタスクのうちいずれかのタスクの実行が可能であるか否かを判定し、前記第２のジョブを構成するいずれかのタスクの実行が可能であると判定した場合、当該タスクの実行を前記処理部に指示する指示部を備え、
   前記指示部は、監視対象のイベントの発生をトリガに、前記第１のジョブのいずれかのタスクが実行されている間に使用されていないリソースを用いて前記第２のジョブのいずれかのタスクの実行が可能であるか否かを判定する
   情報処理システム。

Images