(57)【要約】【課題】サーバに蓄積されたジョブの状態を変更するAPIが失敗した場合に、同じジョブを繰り返し印刷することを防ぐ。【解決手段】ジョブのチケット、画像情報をダウンロードする API と、ジョブの状態を制御する APIの失敗情報を生成、保持し、失敗情報を基に処理するジョブを決定、処理方法を決定する。【選択図】  図4
2015027760.tif 000002
【特許請求の範囲】
【請求項１】
サーバ上に蓄積されたジョブ情報のリストを取得するジョブ情報リスト取得手順(S402,S413,S420)と、取得したジョブ情報リストの情報からジョブのチケット、画像情報をダウンロードするジョブ情報ダウンロード手順（S404）と、サーバ上のジョブ状態を設定するジョブ状態制御手順（S406,S409）とを有する画像形成装置（２００）において、
前記ジョブ状態制御手順が失敗した際に、失敗情報を生成、保持する失敗情報生成保持手順（S415,S416,S417）と、
前記失敗情報生成保持手順で生成した失敗情報によって、処理するジョブを決定するジョブ決定手順（S401,S411）と、
前記失敗情報生成保持手順で生成した失敗情報によって、処理するジョブの処理方法を決定する処理方法決定手順（S412）と、
を有することを特徴とする画像形成装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク上のサーバに蓄積された印刷ジョブをダウンロードし、印刷する画像形成装置に関する。
【背景技術】
【０００２】
ネットワーク上に蓄積された印刷ジョブを、画像形成装置がダウンロードし印刷するクラウドプリントサービスが知られている（特許文献１）。
【０００３】
クラウドプリントサービスでは、サービスを提供しているサーバが印刷ジョブを制御するためのAPIを公開し、画像形成装置がそれを利用することでクラウドプリントを実現している。API は最低限次の３つで構成されている。1つはサーバ上に蓄積されているジョブ情報のリストを取得するAPI(以降fetch と記す)。もう一つはジョブのチケット、画像情報をダウンロードするAPI(以降download と記す)。最後の一つはジョブの状態を制御する API(以降 contorl と記す)である。また、ジョブは最低限次の３つの状態を持つ。印刷待ちの状態（以降QUEUED と記す）, ダウンロード済み状態（以降IN_PROGRESS と記す）, 印刷済み状態（以降DONEと記す）。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開2002-108576号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
図3は、ネットワーク上に蓄積された印刷ジョブをダウンロードし、印刷を行う際のフローを示している。画像形成装置は印刷処理を行う際、まず S101 で fetch を実行し、サーバ上に蓄積されているジョブ情報のリストを取得し、S102に進む。S102では、取得したジョブリストから印刷待ち状態のジョブがあるかどうかを調べ、ある場合はS103に進む。ない場合は終了する。S103では、印刷待ち状態のジョブのチケット、画像情報をダウンロードし、S104 に進む。S104では、ダウンロードした情報を元に画像の印刷を行い、S105に進む。
【０００６】
S105では、サーバ上のジョブの状態を印刷済みの状態に設定するため control を実行する。このcontrol 実行で、ジョブ状態を印刷済みに設定することで、次の S102 の判定で印刷待ちのジョブがなくなり、印刷処理が終了する。このとき、S105のcontrol実行が失敗した場合、次回のS102の判定で、先ほど印刷したジョブの状態が印刷待ちのままであるため、同じジョブを印刷してしまうという課題がある。
【０００７】
本発明は上記問題を鑑みてなされたものであり、control API に失敗した際、同じジョブを複数回印刷することを避けることを目的とする。
【課題を解決するための手段】
【０００８】
上記目的を達成するために、本発明の画像形成装置は、
サーバ上に蓄積されたジョブ情報のリストを取得するジョブ情報リスト取得手順(S402,S413,S420)と、取得したジョブ情報リストの情報からジョブのチケット、画像情報をダウンロードするジョブ情報ダウンロード手順（S404）と、サーバ上のジョブ状態を設定するジョブ状態制御手順（S406,S409）とを有する画像形成装置（２００）において、
前記ジョブ状態制御手順が失敗した際に、失敗情報を生成、保持する失敗情報生成保持手順（S415,S416,S417）と、
前記失敗情報生成保持手順で生成した失敗情報によって、処理するジョブを決定するジョブ決定手順（S401,S411）と、
前記失敗情報生成保持手順で生成した失敗情報によって、処理するジョブの処理方法を決定する処理方法決定手順（S412）とを有する。
【発明の効果】
【０００９】
本発明によれば、control API に失敗した場合でも、同じジョブを複数回印刷することを避けることができるようになる。
【図面の簡単な説明】
【００１０】
【図１】本実施例における画像形成装置（ＭＦＰ）の利用環境を示す概略図である。
【図２】図１記載のＭＦＰ２００のハードウェア構成を示すブロック図である。
【図３】ネットワーク上のサーバからジョブをダウンロードし印刷する処理を示すフロー図である。
【図４】本実施例における、印刷処理を示すフロー図である。
【図５】本実施例における、失敗情報を示す。
【発明を実施するための形態】
【００１１】
以下、本発明を実施するための最良の形態について図面を用いて説明する。
【００１２】
図１は、本実施例における画像形成装置（ＭＦＰ）の利用環境を示す概略図である。クラウドプリントサーバー１００、ＭＦＰ２００、無線ネットワークルーター４００などが、クラウドネットワーク５００に接続されている。また、ＰＤＡ端末３００は、無線ネットワークルーター４００を介して、クラウドネットワーク５００に接続されている。
【００１３】
ＰＤＡ端末３００は、ユーザーによる印刷指示に応じて、予め定められたプロトコルによってクラウドプリントサーバー１００と通信し、印刷の要求を伝える。
【００１４】
クラウドプリントサーバー１００は、ＰＤＡ端末３００から印刷の要求を受けて、ＭＦＰ２００に対して印刷ジョブが届いたことを通知する。
【００１５】
ＭＦＰ２００は、クラウドプリントサーバー１００からの通知に従って、予め定められたプロトコルでクラウドプリントサーバー１００から印刷ジョブを受信し、印刷を実行する。なお、該プロトコルの概要については、後述する。
【００１６】
図２は、図１記載のＭＦＰ２００のハードウェア構成を示すブロック図である。図２において、ＭＦＰ２００は、ＣＰＵ２０１、ＲＯＭ２０２、ＲＡＭ２０３、ネットワークインタフェースカード（ＮＩＣ）２０４、外部入力コントローラ（ＰＡＮＥＬＣ）２０５、各種ボタン或いはタッチパネル（ＰＡＮＥＬ）２０６を備えている。また、ＭＦＰ２００は、ディスプレイコントローラ（ＤＩＳＰＣ）２０７、ディスプレイ（ＤＩＳＰＬＡＹ）２０８、ディスクコントローラ（ＤＫＣ）２０９、ハードディスク（ＨＤ）２１０を備える。ＭＦＰ２００は、さらに、プリンタ部（ＰＲＩＮＴＥＲ）２１１、スキャナ部（ＳＣＡＮＮＥＲ）２１２を備えている。
【００１７】
ＣＰＵ２０１は、システムバス（Ｓｙｓｔｅｍ ＢＵＳ）２１３に接続される各デバイスを総括的に制御すると共に、ＲＯＭ２０２或いは大規模記憶装置であるＨＤ２１０に記憶されたファームウェアモジュールを実行する。なお、ファームウェアモジュールは、少なくとも２つ以上のモジュールから構成され、ファームウェアモジュールの更新は、それぞれのモジュールごとに行うことが可能である。
【００１８】
また、ＣＰＵ２０１は、制御プログラムとしてのファームウェアモジュールに基づき後述の各フローチャートに示す処理を実行する。なお、ＨＤ２１０は、場合によっては画像の一時記憶場所としても使用されることがある。ＲＡＭ２０３は、ＣＰＵ２０１の主メモリ、ワークエリアとして機能する。
【００１９】
ＰＡＮＥＬＣ２０５は、ＭＦＰに装備されたＰＡＮＥＬ２０６からの指示入力を制御する。ＤＩＳＰＣ２０７は、ＤＩＳＰＬＡＹ２０８に対する描画を制御する。
【００２０】
ＮＩＣ２０４は、ＬＡＮ２１４を介して他のＭＦＰ、ファイルサーバ（不図示）と、双方向にデータのやり取りを行う。ＰＲＩＮＴＥＲ２１１は、電子写真方式で記録紙に画像形成を行う。ＳＣＡＮＮＥＲ２１２は、記録紙に印刷されている画像の読み取りを行う。ＳＣＡＮＮＥＲ２１２には、オプションとしてオートドキュメントフィーダ（不図示）が装着されており、複数枚の原稿を自動的に読み取ることができる。
【００２１】
図４は、本実施例のジョブのダウンロードと印刷処理の流れを示したフローチャートである。ジョブのダウンロードと印刷処理は、他のプログラムと共に図２記載のＨＤ２１０に記憶されていて、電源が供給されるとＲＡＭ２０３に展開される。サーバからのジョブ投入通知の受信、あるいはユーザによるジョブ有無の問い合わせ要求を受けると、MFP は図４のフローを開始する。まず、S401 において、WebAPI を失敗したジョブの失敗情報があるかどうか失敗情報キューを確認し、失敗したジョブがない場合はS402に進む。失敗したジョブがある場合はS411に進む。失敗情報キューは図5に示す情報を持つ。具体的には、ジョブを特定するためのジョブIDと、失敗の要因を示す情報を保持している。初期起動時は、このキューは空となる。
【００２２】
S402 ではfetch を行う。fetch でサーバに蓄積されたジョブ情報のリストを取得し、S403に進む。S403 では、取得したリストから印刷待ち状態のジョブがあるかどうかを確認する。印刷待ち状態のジョブがある場合、一番新しい印刷待ちのジョブを、処理中のジョブとしてセットしS404に進む。ない場合処理を終了する。S404では、処理中のジョブ情報をダウンロードするため download を実行し、S405に進む。
【００２３】
S405 では、download の実行結果を確認し、成功している場合は S406 に進む。失敗している場合は S413に進む。S406では、サーバ上のジョブの状態を、ダウンロードが終了したことを示すIN_PROGRESS に設定するために control を実行し、S407に進む。
【００２４】
S407 では、control の実行結果を確認し、成功している場合はS408に進む。失敗している場合はS416に進む。S408 では、ダウンロードしたジョブの印刷を行い、S409 に進む。S409 では、サーバ上のジョブの状態を、印刷が終了したことを示す DONE に設定するために control を実行し、S410 に進む。S410 では、controlが成功したかどうかを確認し、成功した場合S418 に進む。失敗した場合 S417 に進む。S411 では、失敗情報を失敗情報キューからpopして情報を取得し、処理中のジョブ情報としてセットする。また、失敗情報を保持している領域をクリアし、S412に進む。
【００２５】
S412では、取得した失敗情報から失敗要因を調べ、IN_PROGRESS 設定のcontrolで失敗したか、donwload で失敗した場合 S404に進み、DONE 設定の control で失敗した場合は S420 に進む。S413では、fetch を実行しサーバからジョブリストを取得し S414 に進む。S414では、取得したジョブリストに現在処理中のジョブが印刷待ち状態であるかを確認し、印刷待ち状態である場合終了し、印刷待ち状態でない場合 S403 に進む。
【００２６】
S415では、download に失敗したことを示す失敗情報を生成して失敗情報キューに追加し、処理を終了する。S416 では、IN_PROGRESS に設定するためのcontrol が失敗したことを示す失敗情報を生成して失敗情報キューに追加し、処理を終了する。S417では、DONE に設定するためのcontrol が失敗したことを示す情報を生成して失敗情報キューに追加し、処理を終了する。
【００２７】
S418では、失敗情報キューに残りがあるかどうかを確認し、ない場合は S402 に進む。ある場合はS419に進む。S419 では、失敗情報キューの先頭情報のpopし、保持されているジョブIDを処理ジョブとしてセットし、popした情報をクリアする。そして、S409に進む。
【００２８】
S420 では、fetch を行いサーバからジョブリストをダウンロードし、S421に進む。S421 では、取得したジョブリストに処理中のジョブよりも新しい印刷待ちジョブがあるかどうかを判断する。新しい印刷待ちジョブがある場合、そのジョブを印刷するためにS404に進み。ない場合は、再度 controlを実行するために S409に進む。
【００２９】
以上のように構成することによって、本実施例のＭＦＰ２００は、control が失敗した場合でも、同じジョブを何度も印刷することを防ぐことができる。
【符号の説明】
【００３０】
１００  ・・・  ＬＡＮ
２００  ・・・  ＭＦＰ
２０６  ・・・  ＰＡＮＥＬ
２０８  ・・・  ＤＩＳＰＬＡＹ
【図１】
2015027760.tif 000003
【図２】
2015027760.tif 000004
【図３】
2015027760.tif 000005
【図４】
2015027760.tif 000006
【図５】
2015027760.tif 000007