JP7271310B2

JP7271310B2 - 画像形成装置、画像形成装置の制御方法およびプログラム

Info

Publication number: JP7271310B2
Application number: JP2019099474A
Authority: JP
Inventors: 剛井上
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2019-05-28
Filing date: 2019-05-28
Publication date: 2023-05-11
Anticipated expiration: 2039-05-28
Also published as: JP2020192730A; US20200379695A1; US11194528B2

Description

本発明は、クラウドプリントサービスに対応した画像形成装置、その制御方法およびプログラムに関する。

近年、インターネットを利用したプリントサービスが提供されており、クラウドプリントサービスと称されている。クラウドプリントサービスを提供するサーバには、予め、画像形成装置が登録される。登録された画像形成装置は、サーバに保存された印刷ジョブを、インターネットを介して取得して実行する（例えば下記特許文献１参照）。

クラウドプリントサービスを実現する通信プロトコルの標準規格としては、例えば、ＩＰＰ－ＩＮＦＲＡ（ＰＷＧ５１００．１８）が規定されている。ここで、ＩＰＰは、ＩｎｔｅｒｎｅｔＰｒｉｎｔｉｎｇＰｒｏｔｏｃｏｌの略である。また、ＩＮＦＲＡは、ＳｈａｒｅｄＩｎｆｒａｓｔｒｕｃｔｕｒｅＥｘｔｅｎｓｉｏｎｓを意味する。

ＩＰＰ－ＩＮＦＲＡでは、画像形成装置が、サーバ内にその画像形成装置宛の印刷ジョブが保存されているか否かを、定期的にあるいは何らかのイベントが発生した時に、確認する。サーバに印刷ジョブが保存されている場合、画像形成装置は、その印刷ジョブを取得して、印刷を実行する。

特開２０１２－１３３４８９

例えば現像器やドラムの故障などの不具合が発生したために、画像形成装置が印刷を実行できない場合がある。このような場合、画像形成装置は、サーバへ、印刷エラーの発生を通知する。そして、サーバから、ユーザ端末へ、この印刷エラーが通知される。

ところで、画像形成装置における印刷エラーが発生するタイミングと、イベントの取得処理が実行されるタイミングによっては、エラーの発生がサーバに通知される前にユーザ端末から印刷ジョブがサーバに投入される可能性がある。この場合、印刷ができない状況にもかかわらず、画像形成装置がイベントの取得処理を契機とした印刷ジョブを取得を実行してしまう可能性がある。これらの状況で、当該印刷ジョブを取得したとしても印刷は行えない。このような状況で印刷エラーが発生した場合、ユーザは、その印刷エラーが解除された後で、再度、クラウドプリントサービスへ印刷ジョブを投入しなければならない。このため、従来のクラウドプリントサービスでは、エラー発生時の、ユーザの操作負担が大きかった。

加えて、印刷ができない状態で印刷ジョブの取得が行われると、ネットワーク上の負荷をいたずらに増加させてしまう恐れがある。

本発明は、これらの課題の少なくとも１つを鑑みてなされたものである。本発明の１つの側面としては、画像形成装置上で所定のエラーが発生したことに応じて、外部へのジョブ取得に関する要求を行わないよう制御し、当該エラー発生時においてもユーザや管理者の意図しない印刷制御が行われることを抑制することを目的の１つとする。

上記課題を解決するために、本発明は、ネットワークを介してサーバから取得した印刷ジョブに基づいて印刷処理を行う画像形成装置であって、イベント確認要求を前記サーバへ送信することによりイベントの有無を確認するイベント確認手段と、前記印刷ジョブに関する前記イベントが有る場合に、ジョブ取得要求を前記サーバへ送信して、前記サーバから前記印刷ジョブを実行するための印刷ジョブデータを取得するデータ取得手段と、取得した前記印刷ジョブデータを用いて前記印刷処理を行う印刷手段と、を有し、前記画像形成装置において所定のエラーが発生したことに応じて、前記印刷ジョブに関する前記イベントが有る場合であっても、前記データ取得手段による前記ジョブ取得要求を行わないことを特徴とする。

本発明の１つの側面によれば画像形成装置上で所定のエラーが発生したことに応じて、外部へのジョブ取得に関する要求を行わないよう制御する。従って、エラー発生時においてもユーザや管理者の意図しない印刷制御が行われることを抑制することができる。例えば、ジョブ取得に関する要求が行われないためサーバは、サーバ上に保存された印刷ジョブデータを送信後に削除するという処理を行わない。したがって、例えば、ユーザには、再び同じ印刷ジョブをクラウドプリントサービスに投入する手間が発生しない。また例えば、サーバが印刷ジョブデータを送信しないので、通信帯域を無駄に使用することがない。

本発明の第１実施形態に係るシステムの全体構成を概略的に示す図である。第１実施形態に係る画像形成装置のハードウェア構成を概略的に示すブロック図である。第１実施形態に係る画像形成装置のソフトウェア構成を概略的に示すブロック図である。第１実施形態の画像形成装置における、正常時の印刷手順を示すシーケンス図である。第１実施形態に係るクラウドプリントサーバが表示する管理画面の遷移を示す概念図である。第１実施形態の画像形成装置における、異常時の印刷手順を示すシーケンス図である。第１実施形態の画像形成装置における、エラーの一覧を示す図である。第１実施形態の画像形成装置における、異常時の印刷設定画面を示す概念図である。第２実施形態の画像形成装置における印刷手順を示すシーケンス図である。第３実施形態の画像形成装置における、正常時の印刷手順を示すシーケンス図である。第３実施形態の画像形成装置における、異常時の印刷手順を示すシーケンス図である。第４実施形態の画像形成装置における、正常時の印刷手順を示すシーケンス図である。第５実施形態の画像形成装置における、操作画面の遷移を説明する概念図である。（Ａ）、（Ｂ）ともに、第５実施形態の画像形成装置における、印刷エラー発生時の操作画面を説明する概念図である。第５実施形態の画像形成装置における、通信手順を示すシーケンス図である。

以下、本発明を実施するための形態について、図面を用いて説明する。

（第１実施形態）
図１は、本実施形態に係るプリントシステムの全体構成を示す概念図である。

図１に示したように、本実施形態のプリントシステムは、画像形成装置１０１と、クラウドプリントサーバ１０２と、クライアント端末１０３と、インターネット１０４とを含む。

画像形成装置１０１は、印刷ジョブを実行することによって、所望の印刷を行う。但し、画像形成装置１０１は、例えばコピージョブ等、他の種類のジョブを実行できるデバイスであってもよい。画像形成装置１０１としては、例えば、デジタル複合機や、単体のプリンタ等を使用できる。

クラウドプリントサーバ１０２は、ユーザにクラウドプリントサービスを提供するためのサーバである。このために、クラウドプリントサーバ１０２は、クライアント端末１０３から受け取った印刷ジョブデータを、画像形成装置１０１へ提供する。クラウドプリントサーバ１０２は、例えば１台または複数台のサーバコンピュータで構成できる。

クライアント端末１０３は、ユーザによって操作される、通信端末である。後述するように、ユーザは、クラウドプリントサービスを受けるために、このクライアント端末１０３からクラウドプリントサーバ１０２へ印刷ジョブデータを送信する。クライアント端末１０３としては、例えば、汎用のパーソナルコンピュータやスマートフォンなどを使用できる。

インターネット１０４は、クラウドプリントサーバ１０２を、画像形成装置１０１およびクライアント端末１０３へ通信接続する。インターネット１０４に代えて、ＬＡＮ（ＬｏｃａｌＡｒｅａＮｅｔｗｏｒｋ）等の、他の種類の通信網を使用してもよい。

＜印刷装置のハードウェア構成＞
図２は、画像形成装置１０１のハードウェア構成を概略的に示すブロック図である。

図２において、ＣＰＵ（ＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔ）２０１は、画像形成装置１０１全体の動作を制御するプロセッサである。

ＲＯＭ（ＲｅａｄＯｎｌｙＭｅｍｏｒｙ）２０２は、不揮発性メモリであり、画像処理装置１０１のブートプログラムなどが格納されている。

ＲＡＭ（ＲａｎｄｏｍＡｃｃｅｓｓＭｅｍｏｒｙ）２０３は、揮発性メモリである。このＲＡＭは、ＣＰＵ２１０が実行する演算処理のワークエリアとして用いられるとともに、ＲＯＭ２０２やＨＤＤ２０４に格納された各種制御プログラムを展開するための一時記憶領域としても用いられる。

ＨＤＤ（ＨａｒｄＤｉｓｋＤｒｉｖｅ）２０４は、ＲＡＭ２０３と比較して大容量な、不揮発性のハードディスクである。ＨＤＤ２０４には、画像処理装置１０１の制御用プログラムが格納されている。

加えて、ＯＳ（ＯｐｅｒａｔｉｎｇＳｙｓｔｅｍ）や制御用のアプリケーションプログラム等も、ＨＤＤ２０４に格納されている。画像処理装置１０１の起動時には、まず、ＣＰＵ１０１が、ＲＯＭ２０２に格納されているブートプログラムを実行する。このブートプログラムは、ＨＤＤ２０４に格納されているＯＳやアプリケーションプログラムを読み出して、ＲＡＭ２０３上に展開する。そして、ＣＰＵ２０１が、ＯＳやアプリケーションプログラムを実行することで、画像処理装置１０１の制御を行う。ＣＰＵ２０１は、アプリケーションプログラムの実行に用いるデータも、ＲＡＭ２０３上に格納して、読み書きを行う。

本実施形態では、後述するフローチャートに示す各処理を、１つのＣＰＵ２０１が実行するものとするが、他の態様であっても構わない。例えば、複数のＣＰＵやマイクロプロセッサ（ＭＰＵ）が協働して、後述するフローチャートに示す各処理を実行するにしてもよい。また、後述する処理の一部をＡＳＩＣ（ＡｐｐｌｉｃａｔｉｏｎＳｐｅｃｉｆｉｃＩｎｔｅｇｒａｔｅｄＣｉｒｃｕｉｔ）やＦＰＧＡ（Ｆｉｅｌｄ－ＰｒｏｇｒａｍｍａｂｌｅＧａｔｅＡｒｒａｙ）等のハードウェア回路を用いて実行しても良い。

操作部２０５は、タッチ操作可能なディスプレイである。

プリンタ２０６は、通信部２０７を介して外部から受信した印刷データをプリントするプリンタエンジンである。

通信部２０７は、画像処理装置１０１をインターネット１０４（あるいはオフィスのＬＡＮ等）に通信接続するための、ネットワークインタフェースである。

なお、ユーザ端末１０３およびクラウドプリントサーバ１０２にも、ＣＰＵ２０１、ＲＯＭ２０２、ＲＡＭ２０３、ＨＤＤ２０４と同様のハードウェア構成が備えられているが、説明を省略する。

＜ソフトウェア構成＞
図３は、画像形成装置１０１のソフトウェア構成を概略的に示すブロック図である。図３のソフトウェア構成は、ＲＯＭ２０２に記憶されたプログラムを、ＲＡＭ２０３に展開してＣＰＵ２０１が実行することにより、実現される。

ネットワーク送受信部３０１は、通信部２０７を介して外部端末から通信データを受信して、その通信データの種類を判別する。そして、その判別結果に応じて、外部端末へのリクエストや、応答データの送信処理などを行う。

制御部３０２は、操作部２０５のデータ入出力を制御するとともに、ネットワーク送受信部３０１、認証部３０３および印刷部３０４のデータ入出力や処理動作を制御する。

認証部３０３は、画像形成装置１０１のユーザ管理や、外部認証サービスのユーザ認証を行う。具体的には、認証部３０３は、操作部２０５から入力されたユーザアカウントやパスワードを、ＨＤＤ２０４に保存されているユーザ情報と照会して、認証の可否を決定する。加えて、認証部３０３は、画像形成装置１０１が外部クラウドプリントサービスへログインするための、認証処理を実行する。

印刷部３０４はネットワーク送受信部３０１から受信した印刷ジョブデータに対してレンダリングなどの画像処理を行い、プリンタ２０６で印刷させる制御を行う。

＜正常時の印刷シーケンス＞
次に、図４および図５を用いて、正常時（エラーが発生しなかったとき）の印刷シーケンスを説明する。図４は、正常時の印刷手順を示すシーケンス図である。また、図５は、クラウドプリントサーバ１０２の表示部（図示せず）が表示する管理画面の遷移を示す概念図である。

本実施形態では、予め、画像形成装置１０１をクラウドプリントサーバ１０２へ登録しておく必要があるが、この登録処理の説明は省略する。

登録完了後、画像形成装置１０１は、この画像形成装置１０１で実行すべきイベント（印刷ジョブなど）が発生しているかどうかを確認するために、クラウドプリントサーバ１０２へ、イベント確認要求を定期的に送信する（Ｓ４０１、Ｓ４０２）。イベント確認要求は、例えば、ＩＰＰのＧｅｔ－Ｎｏｔｉｆｉｃａｔｉｏｎオペレーションで実現できる。確認要求を送信する時間間隔は、画像形成装置１０１で設定してもよいし、クラウドプリントサーバ１０２が指定してもよい。

本実施形態では、クラウドプリントサーバ１０２の管理画面（図５参照）を、クライアント端末１０３のＷｅｂブラウザで閲覧できることとする。したがって、ユーザは、クライアント端末１０３の閲覧画面で、クラウドプリントサーバ１０２に登録されている、画像形成装置１０１のプリンタの状態やジョブの状況を確認できる。印刷ジョブデータを受信する前の状態で、クラウドプリントサーバ１０２は、管理画面６０１を表示する。この管理画面６０１には、ジョブ状況として「なし」が表示される。また、画像形成装置１０１が正常に動作しており且つ印刷中でない場合、プリンタ状態として「Ｉｄｌｅ」が表示される。

ユーザは、クライアント端末１０３を操作して印刷ジョブデータを選択し、クラウドプリントサーバ１０２へ送信する（Ｓ４０３）。

クラウドプリントサーバ１０２は、印刷ジョブデータを受信すると、その印刷ジョブデータを自身のストレージに保存する（Ｓ４０４）とともに、ジョブ状況を更新する（Ｓ４０５）。その結果、クラウドプリントサーバ１０２の管理画面には、印刷待ち状態であることを示すジョブ状況画面６０２が表示される。

その後、画像形成装置１０１が、イベント確認要求を送信すると（Ｓ４０６）、クラウドプリントサーバ１０２は、印刷ジョブデータが保存されているか否かを確認する。ここでは、上述のＳ４０３でクライアント端末１０３から印刷ジョブが投入されているため、クラウドプリントサーバ１０２は、「イベント有り」を示すイベント確認応答を、画像形成装置１０１へ送信する（Ｓ４０７）。このイベント確認応答は、例えばＩＰＰでは、Ｊｏｂ－Ｆｅｔｃｈａｂｌｅのイベントである。

この確認応答を受信すると、画像形成装置１０１は、クラウドプリントサーバ１０２へジョブ情報取得要求を送信する（Ｓ４０８）。この要求は、例えばＩＰＰでは、Ｇｅｔ－Ｊｏｂｓオペレーションが該当する。

その後、画像形成装置１０１は、クラウドプリントサーバ１０２に対して、実際のジョブ取得要求を行う（Ｓ４０９）。この要求は、例えばＩＰＰでは、Ｆｅｔｃｈ－Ｊｏｂオペレーションである。

ジョブ取得要求を受信すると、クラウドプリントサーバ１０２は、ジョブ状況を「印刷中」に更新する（Ｓ４１０）。その結果、クラウドプリントサーバ１０２の管理画面には、印刷中であることを示すジョブ状況画面６０３が表示される。

その後、クラウドプリントサーバ１０２は、画像形成装置１０１へ、Ｓ４０４で保存した印刷ジョブデータを送信する（Ｓ４１１）。

そして、印刷ジョブデータの送信が完了したら、クラウドプリントサーバ１０２は、自身のストレージから印刷ジョブデータを消去する（Ｓ４１２）。

画像形成装置１０１は、印刷ジョブデータを受信すると、印刷処理を実施する（Ｓ４１３）。そして、印刷処理が正常に完了したら、画像形成装置１０１は、クラウドプリントサーバ１０２へ、印刷ジョブの完了を通知するジョブ状況更新情報を送信する（Ｓ４１４）。

クラウドプリントサーバ１０２は、印刷ジョブ完了通知を受信すると、ジョブ状況を「完了」へ更新する（Ｓ４１５）。その結果、クラウドプリントサーバ１０２の管理画面には、印刷完了を示すジョブ管理画面６０４が表示される。

＜エラー発生時の印刷シーケンス＞
次に、図５および図６を用いて、異常時（エラーが発生した時）の印刷シーケンスを説明する。図６は、異常時の印刷手順を示すシーケンス図である。

図６において、エラーが発生する前の手順は、図４（正常時）と同様である。すなわち、画像形成装置１０１は、イベント確認要求を、定期的に、クラウドプリントサーバ１０２へ送信する（Ｓ７０１）。クラウドプリントサーバ１０２は、クライアント端末１０３から印刷ジョブデータを受信すると（Ｓ７０２）、その印刷ジョブデータを、自身のストレージに保存する（Ｓ７０３）とともに、ジョブ状況を更新する（Ｓ７０４）。その結果、クラウドプリントサーバ１０２の管理画面は、画面６０１から画面６０２へ遷移する。

ここで、印刷エラー（本実施形態では現像器の故障とする）が、画像形成装置１０１に発生したとする（Ｓ７０５）。

画像形成装置１０１は、エラーの発生を検出すると、プリンタ状態を更新する通知を、クラウドプリントサーバ１０２へ送信する（Ｓ７０６）。この通知は、例えばＩＰＰでは、Ｕｐｄａｔｅ－ｏｕｔｐｕｔ－Ｄｅｖｉｃｅ－Ａｔｔｒｉｂｕｔｅオペレーションなどを用いて行うことができる。

この更新通知を受信すると、クラウドプリントサーバ１０２は、内部に保存するプリンタ状態を、「エラー発生中」に変更する（Ｓ７０７）。その結果、クラウドプリントサーバ１０２の管理画面には、エラー発生中であることを示すジョブ状況画面６０５が、表示される。

加えて、画像形成装置１０１は、エラー処理を行うことにより、クラウドプリントサーバ１０２へのイベント確認要求の送信を停止する（Ｓ７０８）。その結果、画像形成装置１０１は、クラウドプリントサーバ１０２への、ジョブ情報の要求（Ｓ４０８参照）や、ジョブ取得の要求（Ｓ４０９参照）も、行わない。

このため、エラー発生時は、画像形成装置１０１が印刷ジョブデータを取得して実行することは無く、したがって、現像器等がエラー停止することも無い。加えて、クラウドプリントサーバ１０２は、インターネット１０４へ印刷ジョブデータを送信しないので、通信帯域を無駄に使用することが無い（Ｓ４１１参照）。更には、印刷ジョブデータが送信されないことにより、クラウドプリントサーバ１０２が、保存した印刷ジョブデータを消去することも無いので、ユーザの操作負担が低減される（Ｓ４１２参照）。

その後、専門修理員等による修理等がなされ、画像形成装置１０１のエラー状態が解除される（Ｓ７０９）。これにより、画像形成装置１０１は、プリンタ状態を更新する通知を送信することにより、クラウドプリントサーバ１０２へ、プリンタ状態が正常になったことを通知する（Ｓ７１０）。

そして、画像形成装置１０１は、イベント確認要求の、クラウドプリントサーバ１０２への定期的な送信を再開する処理を実行する（Ｓ７１１）。

一方、クラウドプリントサーバ１０２は、プリンタ状態更新通知（Ｓ７１０）を受信すると、プリンタ状態を「エラー発生中」から「Ｉｄｌｅ状態」へ更新する（Ｓ７１２）。その結果、クラウドプリントサーバ１０２の管理画面には、ジョブ状況画面６０２が表示される。

その後の印刷シーケンスは、図４（正常時）と同様である。

すなわち画像形成装置１０１がイベント確認要求を送信すると（Ｓ７１３）、クラウドプリントサーバ１０２はイベント確認応答を返送する（Ｓ７１４）。続いて、画像形成装置１０１が、ジョブ情報取得要求を送信し（Ｓ７１５）、さらに、ジョブ取得要求を送信する（Ｓ７１６）。

クラウドプリントサーバ１０２は、ジョブ取得要求を受信すると、ジョブ状況を「印刷中」に更新し（Ｓ７１７）、印刷中であることを示すジョブ状況画面６０を管理画面に表示する。さらに、クラウドプリントサーバ１０２は、画像形成装置１０１へ、Ｓ７０３で保存した印刷ジョブデータを送信する（Ｓ７１８）。

そして、印刷ジョブデータの送信が完了すると、クラウドプリントサーバ１０２は、自身のストレージから印刷ジョブデータを消去する（Ｓ７１９）。

画像形成装置１０１は、この印刷ジョブデータを受信すると、印刷処理を実施する（Ｓ７２０）。そして、印刷完了後、画像形成装置１０１は、クラウドプリントサーバ１０２へ、印刷ジョブの完了を通知するジョブ状況更新情報を送信する（Ｓ７２０）。

クラウドプリントサーバ１０２は、印刷ジョブ完了通知を受信すると、ジョブ状況を「完了」へ更新する（Ｓ７２２）。その結果、クラウドプリントサーバ１０２の管理画面には、印刷完了を示すジョブ状況画面６０４が表示される。

図７は、画像形成装置１０１のエラーの一覧を示す図である。

図７に示したように、画像形成装置１０１で発生するエラーは、「印刷処理の可否判断に影響しないエラー」と、「印刷処理の可否判断に影響するエラー」とに分類される。さらに、「印刷処理の可否判断に影響するエラー」は、「ユーザ作業によって復旧できるエラー」と、「専門修理員による復旧作業が必要なエラー」とに分類される。

「印刷処理の可否判断に影響しないエラー」とは、例えば、ファックスの故障やスキャナの故障等、印刷ジョブと関係しないエラーである。

「ユーザ作業によって復旧できるエラー」とは、ユーザが自分で復旧させることが可能な不具合である。例えば、記録用紙切れ、トナー切れ、紙詰まり等は、その場でユーザが記録用紙の補充、トナーカセットの交換、詰まった記録用紙の除去等の作業を行うことによって復旧させることができる。

「専門修理員による復旧作業が必要なエラー」とは、例えば現像器の故障やドラムの故障等である。これらの不具合は、専門の修理員に修理させる必要がある。このエラーは、一般的に、画像形成装置１０１の電源をＯＦＦにして、数時間から数日の作業時間が必要になる。

本実施形態は、現像器の故障等、「専門修理員による復旧作業が必要なエラー」が発生した場合に、特に好適である。但し、「印刷処理の可否判断に影響しないエラー」や、「ユーザ作業によって復旧できるエラー」が発生した場合にも、本実施形態を適用できる。

本実施形態において、「イベント確認要求処理の停止」（Ｓ７０８）を行うか否かを、ユーザがエラーの種類毎に設定できるように、画像処理装置１０１を構成する。

図８は、このような設定をユーザに行わせるための、画像形成装置１０１の画面の例を示す。図８に示した印刷設定画面を用いることにより、ユーザは、イベント確認要求処理を停止する対象となるエラーを、１または複数種類選択することができる。なお、「印刷処理の可否判断に影響しないエラー」が選択されると、「専門修理員による復旧作業が必要なエラー」及び「ユーザ作業によって復旧できるエラー」も自動的に選択されるよう構成される。また、「ユーザ作業によって復旧できるエラー」が選択されると、「専門修理員による復旧作業が必要なエラー」も自動的に選択されるよう構成される。この場合、「印刷処理の可否判断に影響しないエラー」はユーザにより任意に選択される。すなわち、ユーザは図８の画面を介してクラウドプリントサーバからの印刷ジョブの受信を停止するレベルを段階的に切り替えることができる。当該画面を介してなされた選択状態に基づく設定は画像形成装置１０１の動作設定としてＲＯＭ２０２又はＨＤＤ２０４に記憶される。例えば、「専門修理員による復旧作業が必要なエラー」のみが選択された場合は、第１の設定を示す情報が画像形成装置の動作設定として記憶される。「専門修理員による復旧作業が必要なエラー」及び「ユーザ作業によって復旧できるエラー」が選択された場合は、第２の設定を示す情報が動作設定として記憶される。すべての項目が選択された場合は、第３の設定を示す情報が動作設定として記憶される。

以上説明したように、本実施形態では、画像形成装置１０１内で所定のエラーが発生した場合に、この画像形成装置１０１によるイベント確認要求処理が停止される。このため、画像形成装置１０１は、印刷ジョブデータの取得を停止し、その結果、クラウドプリントサーバ１０２は、保存した印刷ジョブデータを削除しない。

したがって、本実施形態によれば、ユーザは、エラーが解除されたあとで、同じ印刷ジョブを再度クラウドプリントサーバ１０２へ投入する必要が無い。

加えて、エラー発生後は、クラウドプリントサーバ１０２がインターネット１０４へ印刷ジョブデータを送信しないので、通信帯域を無駄に使用することがなくなる。

（第２実施形態）
以下、本発明の第２実施形態を説明する。
本実施形態に係るシステムの全体構成や、画像形成装置のハードウエア構成およびソフトウエア構成は、上述の第１実施形態と同様であるため（図１～図３参照）、説明を省略する。

また、本実施形態のシステムにおける、正常時の印刷手順は、上述の第１実施形態と同様であるため（図４参照）、説明を省略する。

上述の第１実施形態では、画像形成装置１０１で所定のエラーが発生したときに、イベント確認要求処理を停止することとした（図６のＳ７０８参照）。これに対して、本実施形態では、画像形成装置１０１で所定のエラーが発生したときに、ジョブ取得要求処理を停止することで、印刷ジョブデータの取得を停止する。

図９は、本実施形態に係るシステムにおける、異常時の印刷手順を示すシーケンス図である。

図９において、エラーが発生する前の手順は、上述の第１実施形態（図６参照）と同様である。すなわち、画像形成装置１０１は、イベント確認要求を、定期的に、クラウドプリントサーバ１０２へ送信する（Ｓ１００１）。そして、クライアント端末１０３から印刷ジョブデータを受信すると（Ｓ１００２）、クラウドプリントサーバ１０２は、その印刷ジョブデータを、自身のストレージに保存する（Ｓ１００３）とともに、ジョブ状況を更新する（Ｓ１００４）。

ここで、画像形成装置１０１に、印刷エラー（例えば現像器の故障）が発生したとする（Ｓ１００５）。画像形成装置１０１は、エラーの発生を検出すると、ジョブ取得要求の送信処理を停止する（Ｓ１００６）。

さらに、画像形成装置１０１は、エラーの発生を検出すると、プリンタ状態を更新する通知を、クラウドプリントサーバ１０２へ送信する（Ｓ１００７）。この更新通知を受信すると、クラウドプリントサーバ１０２は、内部に保存するプリンタ状態を、「エラー発生中」に変更する（Ｓ１００８）。

上述のように、本実施形態の画像形成装置１０１は、エラーの発生を検出した場合でも、クラウドプリントサーバ１０２へ、イベント確認要求を送信する処理を行う（Ｓ１００９）。クラウドプリントサーバ１０２は、イベント確認要求を受信すると、「イベント有り」を示すイベント確認応答を、画像形成装置１０１へ返送する（Ｓ１０１０）。

画像形成装置１０１は、このイベント確認応答を受信することで、印刷ジョブデータがクラウドプリントサーバ１０２に保存されていることを認識する。しかし、本実施形態では、ジョブ取得要求の送信処理が停止されているので、画像形成装置１０１は、ジョブ情報を要求する処理を行わない。したがって、印刷ジョブデータは、クラウドプリントサーバ１０２に保存されたままとなる。

その後も、画像形成装置１０１は、イベント確認要求を、定期的に送信し続ける（Ｓ１０１１、１０１２）。これに対して、本実施形態のクラウドプリントサーバ１０２は、一度「イベント有り」との応答をしたあとは、イベント確認応答を返送しない。

但し、クラウドプリントサーバ１０２は、画像形成装置１０１からイベント確認要求を受信する度に「イベント有り」とのイベント確認応答を返送することにしてもよい。また、「イベント有り」とのイベント確認応答を返送したあと、保存されたイベントに変更がない場合には、「イベント無し」とのイベント確認応答を返送することにしてもよい。すなわち、イベント確認応答が含む通知の内容は、クラウドプリントサーバ１０２の仕様に基づいて、任意に決定できる。

このように、本実施形態でも、第１実施形態同様、エラー発生時に、画像形成装置１０１が印刷ジョブデータを取得して実行することは無く、したがって、現像器等がエラー停止することも無い。加えて、クラウドプリントサーバ１０２は、インターネット１０４へ印刷ジョブデータを送信しないので、通信帯域を無駄に使用することが無い。更には、印刷ジョブデータが送信されないことにより、クラウドプリントサーバ１０２が、保存した印刷ジョブデータを消去することも無いので、ユーザの操作負担が低減される。

その後、専門修理員等による修理等がなされ、画像形成装置１０１のエラー状態が解除される（Ｓ１０１３）。

続いて、画像形成装置１０１が、プリンタ状態を更新する通知を送信することにより、クラウドプリントサーバ１０２へ、プリンタ状態が正常になったことを通知する（Ｓ１０１４）。そして、画像形成装置１０１は、ジョブ取得要求処理を再開する処理を実行する（Ｓ１０１５）。

クラウドプリントサーバ１０２は、プリンタ状態更新通知（Ｓ１０１４）を受信すると、プリンタ状態を「エラー発生中」から「Ｉｄｌｅ状態」へ更新する（Ｓ１０１６）。

画像形成装置１０１は、クラウドプリントサーバ１０２へジョブ情報要求を送信し（Ｓ１０１７）、さらに、ジョブ取得要求を送信する（Ｓ１０１８）。

このように、本実施形態では、画像形成装置１０１が、Ｓ１０１０で受信した「イベント有り」とのイベント確認応答を保存しておき、エラー解除（Ｓ１０１３）のあとで直ちにジョブ取得要求を送信することとした。但し、「イベント有り」とのイベント確認応答を受け取っているか否かに拘わらず、エラー解除後は必ずジョブ取得要求を送信することとしてもよい。

その後の印刷手順は、上述の第１実施形態の場合と同様である。すなわち、クラウドプリントサーバ１０２は、ジョブ取得要求を受信すると、ジョブ状況を「印刷中」に更新し（Ｓ１０１９）、さらに、Ｓ１００３で保存した印刷ジョブデータを、画像形成装置１０１へ送信する（Ｓ１０２０）。そして、印刷ジョブデータの送信が完了すると、クラウドプリントサーバ１０２は、自身のストレージから印刷ジョブデータを消去する（Ｓ１０２１）。

画像形成装置１０１は、印刷ジョブデータを受信すると、印刷処理を実施する（Ｓ１０２２）。そして、印刷完了後、画像形成装置１０１は、印刷ジョブの完了を通知するジョブ状況更新情報を、クラウドプリントサーバ１０２へ送信する（Ｓ１０２３）。

クラウドプリントサーバ１０２は、印刷ジョブ完了通知を受信すると、ジョブ状況を「完了」へ更新する（Ｓ１０２４）。

なお、本実施形態でも、クラウドプリントサーバ１０２は、ジョブ状況を更新するたびに管理画面の表示を更新するが、上述の第１実施形態の場合（図５参照）と同様であるので、説明を省略した。

以上説明したように、本実施形態では、画像形成装置１０１内で所定のエラーが発生した場合にジョブ取得要求処理が停止され、これにより、画像形成装置１０１よる印刷ジョブデータの取得が停止される。その結果、本実施形態によれば、クラウドプリントサーバ１０２が、保存した印刷ジョブデータを削除せず、したがって、ユーザは、エラーが解除されたあとで、同じ印刷ジョブを再度クラウドプリントサーバ１０２へ投入する必要が無い。

また、エラー発生後はクラウドプリントサーバ１０２がインターネット１０４へ印刷ジョブデータを送信しないので、通信帯域を無駄に使用することが無い。

加えて、本実施形態では、画像形成装置１０１は、エラー発生中もイベント確認要求を送信するので、印刷処理に関連しないイベントがクラウドプリントサーバ１０２内で発生した場合に、そのイベント発生を認識することができる。例えば、画像形成装置１０１は、エラー発生中に、クラウドプリントサーバ１０２の状態変化等を、イベント情報として取得することができる。

なお、画像形成装置１０１で発生するエラーを複数種類に分類して、所定のエラーが発生したときにのみ印刷ジョブの取得・実行を停止するよう設定できる点（図７、図８参照）は、上述の第１実施形態と同様である。

（第３実施形態）
以下、本発明の第３実施形態を説明する。

本実施形態は、ユーザが自己のジョブを管理できるよう構成したシステムに、本発明を適用した例である。

本実施形態に係るシステムの全体構成や、画像形成装置のハードウエア構成およびソフトウエア構成は、上述の第１実施形態とほぼ同様である（図１～図３参照）。

但し、本実施形態に係る画像形成装置１０１は、１または複数のユーザに係るユーザ情報（アカウントおよびパスワード）を、ＨＤＤ等のストレージに保存するように構成されている。そして、保存されたユーザ情報を、ユーザが操作部２０５（図２参照）へ直接入力したユーザ情報と照合することで、この画像形成装置１０１にログインできる。

以下に説明するように、本実施形態では、上述の第２実施形態と同様、画像形成装置１０１で所定のエラーが発生したときに、ジョブ取得要求処理を停止することで、印刷ジョブデータの取得を停止する。

図１０は、本実施形態に係るシステムにおける、正常時の印刷手順である。

ユーザは、クライアント端末１０３を操作して、印刷ジョブデータをクラウドプリントサーバ１０２へ送信する（Ｓ１１０１）。

クラウドプリントサーバ１０２は、この印刷ジョブデータを受信して、自身のストレージに保存するとともに（Ｓ１１０２）、ジョブ状況を更新する（Ｓ１１０３）。

その後、ユーザが、画像形成装置１０１の操作部２０５を操作して、この画像形成装置１０１にログインする（Ｓ１１０４）。

ログインが成功すると、画像形成装置１０１は、そのユーザに係るジョブが保存されているかどうかを確認するためのジョブ情報取得要求を、クラウドプリントサーバ１０２へ送信する（Ｓ１１０５）。特定ユーザのジョブだけを確認する方法としては、例えばＩＰＰの場合、Ｗｈｉｃｈ－Ｊｏｂｓ属性や、Ｒｅｑｕｅｓｔｉｎｇ－ｕｓｅｒ－ｎａｍｅ属性、Ｒｅｑｕｅｓｔｉｎｇ－ｕｓｅｒ－ｕｒｉ属性を用いた方法がある。

続いて、画像形成装置１０１は、クラウドプリントサーバ１０２へ、ジョブ情報取得要求を送信する（Ｓ１１０６）。

このジョブ情報取得要求を受信すると、クラウドプリントサーバ１０２は、ジョブ状況を「印刷中」に更新したのち（Ｓ１１０７）、そのユーザに係る印刷ジョブデータを画像形成装置１０１へ送信する（Ｓ１１０８）。そして、印刷ジョブデータの送信が完了したら、クラウドプリントサーバ１０２は、自身のストレージから、送信済みの印刷ジョブデータを消去する（Ｓ１１０９）。

画像形成装置１０１は、印刷ジョブデータを受信すると、印刷処理を実施する（Ｓ１１１０）。そして、印刷処理が正常に完了したら、画像形成装置１０１は、クラウドプリントサーバ１０２へ、印刷ジョブの完了を通知するジョブ状況更新情報を送信する（Ｓ１１１１）。

クラウドプリントサーバ１０２は、印刷ジョブ完了通知を受信すると、ジョブ状況を「完了」へ更新する（Ｓ１１１２）。

その後、ユーザがログアウトを行って、印刷処理が終了する（Ｓ１１１３）。

図１１は、本実施形態に係るシステムにおける、異常時の印刷手順である。

上記（図１０参照）と同様、ユーザがクライアント端末１０３からクラウドプリントサーバ１０２へ印刷ジョブデータを送信する（Ｓ１２０１）。クラウドプリントサーバ１０２は、この印刷ジョブデータを受信して、自身のストレージに保存する（Ｓ１２０２）。そして、クラウドプリントサーバ１０２は、ジョブ状況を更新する（Ｓ１２０３）。

ここで、画像形成装置１０１に、印刷エラー（例えば現像器の故障）が発生したとする（Ｓ１２０４）。画像形成装置１０１は、エラーの発生を検出すると、ジョブ取得要求の送信処理を停止する（Ｓ１２０５）。

画像形成装置１０１は、ジョブ取得要求処理の停止後は、ユーザが画像形成装置１０１へのログインとログアウトとを繰り返しても、クラウドプリントサーバ１０２へジョブ取得要求を送信しない（Ｓ１２０６～Ｓ１２０８）。

その後、専門修理員等による修理等がなされ、画像形成装置１０１のエラー状態が解除されると（Ｓ１２０９）、プリンタ状態を更新する通知が、画像形成装置１０１からクラウドプリントサーバ１０２へ送られる（Ｓ１２１０）。そして、画像形成装置１０１は、ジョブ取得要求処理を再開する処理を実行する（Ｓ１２１１）。

クラウドプリントサーバ１０２は、プリンタ状態更新通知（Ｓ１２１０）を受信すると、プリンタ状態を「エラー発生中」から「Ｉｄｌｅ状態」へ更新する（Ｓ１２１２）。

画像形成装置１０１は、クラウドプリントサーバ１０２へ、ジョブ情報要求を送信する（Ｓ１２１３）。

その後の手順は、正常時の印刷手順（図１０参照）のＳ１１０６と同様であるため、説明を省略する。

以上説明したように、本実施形態でも、上述の第２実施形態と同様、画像形成装置１０１内で所定のエラーが発生した場合にジョブ取得要求処理が停止され、これにより、画像形成装置１０１よる印刷ジョブデータの取得が停止する。その結果、本実施形態によれば、クラウドプリントサーバ１０２が、ログインユーザの印刷ジョブデータを削除せず、したがって、ログインユーザは、エラーが解除されたあとで、同じ印刷ジョブを再度クラウドプリントサーバ１０２へ投入する必要が無い。

また、第２実施形態と同様、エラー発生後はクラウドプリントサーバ１０２がインターネット１０４へ印刷ジョブデータを送信しないので、通信帯域を無駄に使用することがなくなる。

加えて、第２実施形態と同様、画像形成装置１０１は、エラー発生中もイベント確認要求を送信するので、印刷に関連しないイベントがクラウドプリントサーバ１０２内で発生した場合に、そのイベント発生を認識することができる。例えば、画像形成装置１０１は、エラー発生中に、クラウドプリントサーバ１０２の状態変化等を、イベント情報として取得することができる。

なお、画像形成装置１０１で発生するエラーを複数種類に分類して、所定のエラーが発生したときにのみ印刷ジョブの取得・実行を停止するよう設定できる点（図７、図８参照）は、上述の第１および第２実施形態と同様である。

（第４実施形態）
以下、本発明の第４実施形態を説明する。

本実施形態は、ユーザがログイン後に自己の印刷ジョブを選択して実行できるよう構成したシステムに、本発明を適用した例である。

図１２は、本実施形態に係るシステムにおける、正常時の印刷手順である。また、図１３は、画像形成装置１０１の操作部２０５が表示する画面の遷移を示す概念図である。

第３実施形態と同様、まず、クライアント端末１０３からクラウドプリントサーバ１０２へ印刷ジョブデータが送信され（Ｓ１３０１）、クラウドプリントサーバ１０２内で保存される（Ｓ１３０２）。さらに、クラウドプリントサーバ１０２は、ジョブ状況を更新する（Ｓ１３０３）。

その後、ユーザが、画像形成装置１０１のログイン画面１４００（図１３参照）を操作することにより、この画像形成装置１０１にログインする（Ｓ１３０４）。このログイン後、画像形成装置１０１は、画面をアプリケーション選択画面１４０１に切り替えた後、クラウドプリントサーバ１０２へ、そのユーザに対応するジョブ情報を要求する（Ｓ１３０５）。

クラウドプリントサーバ１０２は、このジョブ情報要求に応答して、画像形成装置１０１へ、ジョブ情報を送信する（Ｓ１３０６）。

画像形成装置１０１は、受け取ったジョブ情報に基づいて、そのユーザに対応する印刷ジョブ一覧を作成する。そして、ユーザが、アプリケーション選択画面１４０１で「クラウドプリント」を選択したときに、画面を印刷ジョブ一覧画面１４０２に切り替えて、作成した印刷ジョブ一覧を表示する（Ｓ１３０７）。なお、本実施形態では、ユーザによるログイン後直ちに画像形成装置１０１がジョブ一覧取得要求を送信することにしたが、ユーザがアプリケーション選択画面１４０１で「クラウドプリント」を選択したあとでジョブ一覧取得要求を送信することにしてもよい。

ユーザは、印刷ジョブ一覧画面１４０２を操作して、印刷したいジョブをジョブ一覧から選択する（Ｓ１３０８）。これにより、画像形成装置１０１は、選択された印刷ジョブのジョブデータを、クラウドプリントサーバ１０２へ要求する（Ｓ１３０９）。

このジョブ情報取得要求を受信すると、クラウドプリントサーバ１０２は、ジョブ状況を「印刷中」に更新したのち（Ｓ１３１０）、そのユーザに係る印刷ジョブデータを画像形成装置１０１へ送信する（Ｓ１３１１）。そして、印刷ジョブデータの送信が完了したら、クラウドプリントサーバ１０２は、自身のストレージから、送信済みの印刷ジョブデータを消去する（Ｓ１３１２）。

画像形成装置１０１は、印刷ジョブデータを受け取ると、印刷処理を開始（Ｓ１３１３）する。これと同時に、画像形成装置１０１は、画面１４０３に示したように、該当する印刷ジョブの「ジョブ状況」を「印刷中」に切り替える。

その後、印刷が終了すると、画像形成装置１０１は、画面１４０４に示したように、該当する印刷ジョブの「ジョブ状況」を「印刷完了」に切り替える。さらに、画像形成装置１０１は、クラウドプリントサーバ１０２へ、印刷ジョブの完了を通知するジョブ状況更新情報を送信する（Ｓ１３１４）。

クラウドプリントサーバ１０２は、印刷ジョブ完了通知を受信すると、ジョブ状況を「完了」へ更新する（Ｓ１３１５）。

次に、本実施形態で、画像形成装置１０１のエラーが発生した場合を説明する。

本実施形態では、エラーが発生した場合に、画像形成装置１０１に印刷ジョブを取得させるための操作を、ユーザが行えないようにする。

このために、本実施形態では、ユーザが、印刷ジョブ一覧画面１４０２で任意のジョブを選択したあとで「印刷開始」を選択したときに、印刷できない旨を表す画面１４０５を表示する。

他の例として、ユーザが、アプリケーション選択画面１４０１で「クラウドプリント」を選択して、印刷ジョブ一覧画面１４０６（図１４（Ａ）参照）が表示されたときに、「印刷開始」ボタン１４０６ａを選択できないようにしてもよい。このとき、例えば「印刷開始」ボタンの表示色をグレーにすること等で、「印刷開始」が選択できないことをユーザに認識させることができる。

さらに他の例として、ユーザが、アプリケーション選択画面１４０１で「クラウドプリント」を選択したときに、印刷ジョブ一覧画面１４０７（図１４（Ｂ）参照）のように、印刷ジョブを表示しないことにしてもよい。

このように、本実施形態では、画像形成装置１０１内で所定のエラーが発生した場合に、ユーザは、印刷ジョブを選択して印刷を開始させる操作を行うことができない。このため、本実施形態では、所定のエラーの発生時に、ジョブ取得要求処理が停止され、これにより、画像形成装置１０１よる印刷ジョブデータの取得が停止する。その結果、本実施形態によれば、クラウドプリントサーバ１０２が、ログインユーザの印刷ジョブデータを削除せず、したがって、ログインユーザは、エラーが解除されたあとで、同じ印刷ジョブを再度クラウドプリントサーバ１０２へ投入する必要が無い。

また、上述の各実施形態と同様、エラー発生後はクラウドプリントサーバ１０２がインターネット１０４へ印刷ジョブデータを送信しないので、通信帯域を無駄に使用することがなくなる。

なお、画像形成装置１０１で発生するエラーを複数種類に分類して、所定のエラーが発生したときにのみ印刷ジョブの取得・実行を停止するよう設定できる点（図７、図８参照）は、上述の各実施形態と同様である。

（第５実施形態）
以下、第５実施形態として、本発明のシステムにおける、印刷処理以外のオペレーションに関する手順について説明する。

画像形成装置１０１とクラウドプリントサーバ１０２とは、印刷ジョブに関する信号の送受信だけでなく、通信管理その他に必要な信号送受信も行っている。例えば画像形成装置１０１は、クラウドプリントサーバ１０２へ登録されると、このクラウドプリントサーバ１０２から、アクセストークンを取得する。

周知のように、アクセストークンには、有効期限がある。このため、画像形成装置１０１は、定期的に、クラウドプリントサーバ１０２との間で、アクセストークンを更新するための通信を行う必要がある。

図１５は、アクセストークンを更新する処理を示すシーケンス図である。

登録時には、まず、画像形成装置１０１が、クラウドプリントサーバ１０２へ、登録要求が送信される（Ｓ１５０１）。この登録要求に応答して、クラウドプリントサーバ１０２から、アクセストークンが送信される（Ｓ１５０２）。これにより、画像形成装置１０１は、このアクセストークンを取得する。

上述のように、アクセストークンには、有効期限が有るので、定期的に更新する必要がある。このため、画像形成装置１０１は、クラウドプリントサーバ１０２へ、定期的に、トークンの更新を要求する（Ｓ１５０３、Ｓ１５０４）。

ここで、印刷エラーが発生しても、アクセストークンの更新は、継続して実行できる。したがって、印刷エラーの発生（Ｓ１５０５）からその印刷エラーの解除（Ｓ１５０８）までの期間にも、画像形成装置１０１は、クラウドプリントサーバ１０２へ定期的にトークンの更新を要求する（Ｓ１５０６、Ｓ１５０７）。

そして、印刷エラーの解除後も、画像形成装置１０１は、引き続き、クラウドプリントサーバ１０２へ定期的にトークンの更新を要求する（Ｓ１５０９、Ｓ１５１０）。

このように、本発明では、画像形成装置１０１で印刷エラーが発生したときに、印刷処理に関連しないオペレーションについて、処理の続行を妨げることがない。

（その他の実施形態）
本発明は、上記各実施形態の機能を実現するソフトウェアを、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータがプログラムを読み出して実行する処理によっても、実現可能である。

１０１画像処理装置
１０２クラウドプリントサーバ
１０３ユーザ端末
１０４インターネット
２０１ＣＰＵ
２０２ＲＯＭ
２０３ＲＡＭ
２０４ＨＤＤ
２０５操作部
２０６プリンタ
２０７通信部
３０１ネットワーク送受信部
３０２制御部
３０３認証部
３０４印刷部

Claims

ネットワークを介してサーバから取得した印刷ジョブに基づいて印刷処理を行う画像形成装置であって、
イベント確認要求を前記サーバへ送信することによりイベントの有無を確認するイベント確認手段と、
前記印刷ジョブに関する前記イベントが有る場合に、ジョブ取得要求を前記サーバへ送信して、前記サーバから前記印刷ジョブを実行するための印刷ジョブデータを取得するデータ取得手段と、
取得した前記印刷ジョブデータを用いて前記印刷処理を行う印刷手段と、を有し、
前記画像形成装置において所定のエラーが発生したことに応じて、前記印刷ジョブに関する前記イベントが有る場合であっても、前記データ取得手段による前記ジョブ取得要求を行わないことを特徴とする画像形成装置。
前記画像形成装置において所定のエラーが発生したことに応じて、前記イベントが有る場合であっても、前記データ取得手段による前記ジョブ取得要求を行わないよう制限する制御手段を有する請求項１に記載の画像形成装置。
前記イベント確認手段は、前記イベント確認要求を所定の周期で繰り返し送信することを特徴とする請求項２に記載の画像形成装置。
前記制御手段は、前記所定のエラーが解消されたことに従って、前記制限を解除することを特徴とする請求項２又は３のいずれか１項に記載の画像形成装置。
前記画像形成装置において発生する複数の種類のエラーの中から、前記サーバによる前記印刷ジョブデータの送信を停止させる前記所定のエラーとして取り扱うエラーの種類を設定する設定手段をさらに備えることを特徴とする請求項２～４のいずれか１項に記載の画像形成装置。
前記設定手段では、印刷を継続できないエラーであり、且つ、サービスエンジニアによる修理を必要とする第１の種類のエラーを所定のエラーとして取り扱う第１の設定、前記第１の種類のエラーに加えて、印刷を継続できないエラーであり、且つ、ユーザによるメンテナンス作業によってエラー状態を解消できる第２の種類のエラーを所定のエラーとして取り扱う第２の設定をいずれかを設定できることを特徴とする請求項５に記載の画像形成装置。
操作者のログインを認証する認証手段をさらに備え、
前記イベント確認手段は、ログインした前記操作者に対応するイベントの有無のみを確認し、且つ、
前記データ取得手段は、前記ログインした操作者に対応する前記印刷ジョブデータのみを取得する
ことを特徴とする請求項２に記載の画像形成装置。
ジョブ情報要求を前記サーバへ送信して、前記ログインした操作者に対応する前記印刷ジョブの情報を前記サーバから取得する情報取得手段と、
取得した前記印刷ジョブの情報を表示し、実行する前記印刷ジョブを前記操作者に選択させる操作手段と
をさらに備えることを特徴とする請求項７に記載の画像形成装置。
前記データ取得手段は、前記実行する印刷ジョブが前記操作手段で選択されたあとで、選択された前記印刷ジョブに対応する前記印刷ジョブデータを前記サーバから取得するための前記ジョブ取得要求を送信するように構成され、且つ、
前記制御手段は、更に所定のエラーが発生した場合に、前記操作手段により前記印刷ジョブを選択する操作を受け付けないよう制御することで、前記ジョブ取得要求が行われないよう制御することを特徴とする請求項８に記載の画像形成装置。
前記所定のエラーとは異なるエラーであり前記印刷手段による前記印刷処理を停止させる原因とならないエラーが発生していることに応じては、前記制御手段による前記制限は行われないことを特徴とする請求項２～９のいずれか１項に記載の画像形成装置。
ネットワークを介してサーバから取得した印刷ジョブに基づいて印刷処理を行う画像形成装置の制御方法であって、
イベント確認要求を前記サーバへ送信することによりイベントの有無を確認するイベント確認工程と、
前記印刷ジョブに関する前記イベントが有る場合に、ジョブ取得要求を前記サーバへ送信して、前記サーバから前記印刷ジョブを実行するための印刷ジョブデータを取得するデータ取得工程と、
取得した前記印刷ジョブデータを用いて前記印刷処理を行う印刷工程と、を有し、
前記画像形成装置において所定のエラーが発生したことに応じて、前記印刷ジョブに関する前記イベントが有る場合であっても、前記ジョブ取得要求を行わないことを特徴とする画像形成装置の制御方法。
請求項１～１０のいずれか１項に記載の画像形成装置の各手段としてコンピュータを機能させるためのプログラム。