JP2021149869A - 印刷システム、印刷装置、制御方法及びプログラム - Google Patents

Abstract

【課題】ジョブのキャンセル制御の利便性を高めることを目的の１つとする。【解決手段】印刷システムは、サーバ起因でキャンセル要求が発生するとジョブを一時停止状態に遷移する。印刷装置１０１は、サーバから当該印刷ジョブの印刷をキャンセルすべきことを示す情報を受信した場合、キャンセルを受け入れるべき状況か否かを印刷ジョブに対する処理の進捗状態に基づいて判定する。印刷装置１０１は、受け入れるべき状況でないと判定した場合、印刷ジョブの出力が完了したことを示す実行結果をサーバに対して通知し、サーバは、その通知に基づきジョブの実行結果を記録する。【選択図】図９

Description

本発明は、サーバを経由して印刷を行う印刷システムに関するものである。

これまでの印刷サービスでは、ユーザがＰＣ等のクライアント端末から印刷装置に直接印刷ジョブを送信することによって印刷を実現していた。一方、近年、インターネット上で提供されるクラウドサービスを利用したクラウドプリントサービスが提案されている。クラウトプリントサービスでは、クライアント端末などがクラウドプリントサービスに印刷要求（あるいは印刷ジョブ）を送信すると、その印刷要求に係る印刷ジョブが、あらかじめ登録された印刷装置により取得されて印刷が実行される。印刷装置は、クラウドプリントサービスから印刷装置に対して通知されるイベントに基づきクラウドプリントサービス上に、印刷すべきジョブがあることを検知する。

ここでクラウドプリントサービスから印刷装置へのイベント通知には主にＰｕｌｌ（プル）方式、Ｐｕｓｈ（プッシュ）方式の２つの方法がある。プル方式では、印刷装置がイベント取得要求をクラウドプリントサービスに送信すると、それに応じてイベント通知が応答される。この場合、イベント取得要求は、印刷装置から、所定のポーリング間隔で送信される。

一方、プッシュ方式では、印刷装置がクラウドプリントサービスとの接続を確立してイベント取得要求をいったん送信すると、クラウドプリントサービスは、その接続を通して、イベントが発生する都度、イベント通知を印刷装置に送信する。

また、サーバを経由して印刷する場合におけるジョブキャンセルを行う仕組みが特許文献１に記載されている。具体的には、特許文献１のサーバは、ユーザからジョブのキャンセル指示を受信した場合に、プリンタの起動時に確立している通知用のチャネルを用いてプリンタに当該キャンセル指示を送信し、印刷履歴としてジョブのキャンセルを記録する。一方、プリンタは、サーバから受信したキャンセル指示に応じて印刷処理をキャンセルし、印刷履歴としてジョブのキャンセルを記録する。

特開２０１８−１５１９８１号公報

前述したイベント通知はクラウドプリントサービスを提供するサーバ上で管理される印刷ジョブのステータスの変更をプリンタに通知する目的でも使用される。ここで、Ｐｕｌｌ方式でイベント通知を受信する場合に、特許文献１のキャンセル方法を採用すると、サーバから取得した印刷ジョブの実行中に、サーバサイドでジョブがキャンセルされ、キャンセルとして取り扱われることになる。この場合、印刷の進行状態と、要求のレスポンスとしてイベント通知を受信するタイミングによっては、印刷装置におけるジョブの実行が完了してしまっている場合もある。従って、実際のジョブの実行結果と、サーバ上で記憶される実行結果に不整合が発生する場合がある。更に、特許文献１のようにＰｕｓｈ方式でキャンセルイベントを受信する場合であっても、印刷装置における印刷の進行状態によっては、印刷の中止処理が間に合わず印刷処理が完了してしまう場合もある。従来のサーバ側でのジョブキャンセルを優先し、印刷装置にキャンセルを通知する構成では、印刷装置でロギングされる実行結果の履歴情報（実際の実行結果）と、サーバ上でロギングされる実行結果の履歴情報が異なってしまう場合がある。

本発明は上述の問題点の少なくとも１つを鑑みなされたものである。本発明の１つの側面としては、印刷ジョブの実行をキャンセルする指示をサーバから受信した際に、ジョブの進捗状況に基づき適切な実際の印刷ジョブの実行結果を当該サーバに通知できる仕組みを提供することを目的の１つとする。また、本発明の１つの側面としては、ジョブのキャンセル制御の利便性を高めることを目的の１つとする。

本発明の１つの側面としての印刷システムは、ユーザから入稿された印刷データを管理するサーバと、前記サーバにイベントの有無を定期的に問合せ、当該問い合わせに対する応答として前記サーバからイベント通知を取得して、前記イベント通知の内容に基づいて前記サーバが管理する印刷ジョブを取得して印刷処理を実行する印刷装置を含む印刷システムであって、前記サーバは、前記サーバが管理する印刷ジョブのキャンセルする要求を受信した場合であって、当該キャンセルが要求された印刷ジョブの実行状況を実行中で管理している場合に、当該キャンセルが要求された印刷ジョブの実行状態を一時停止状態に遷移するジョブ管理手段と、前記キャンセルが要求された印刷ジョブを実行中の印刷装置に当該印刷ジョブの印刷をキャンセルすべきことを示す情報を送信する送信手段と、前記管理手段が管理するジョブの実行状態が終了状態に遷移したことに従って、前記終了状態に遷移した印刷ジョブの実行結果を含む履歴情報を記憶する第１の記憶手段と、を有し、前記印刷装置は、前記取得した印刷ジョブの印刷処理が開始された後に、前記サーバから当該印刷ジョブの印刷をキャンセルすべきことを示す情報を受信した場合、キャンセルを受け入れるべき状況か否かを印刷ジョブに対する処理の進捗状態に基づいて判定する判定手段と、前記判定手段で前記キャンセルを受け入れるべき状況であると判定された場合、前記印刷処理の実行をキャンセル終了し、前記印刷ジョブに対する処理をキャンセルしたことを示す実行結果を前記サーバに対して通知し、前記判定手段で前記キャンセルを受け入れるべき状況でないと判定された場合、前記印刷ジョブの出力が完了したことを示す実行結果を前記サーバに対して通知する制御手段と、前記印刷ジョブの実行が終了した場合に、当該印刷ジョブの実行結果を含む履歴情報を記憶する第２の記憶手段と、を有し、前記サーバのジョブ管理手段は、前記印刷装置から通知された実行結果に基づいて、前記キャンセルが要求された印刷ジョブの実行状態を正常終了状態又は、キャンセル終了状態に遷移させる、ことを特徴とする。

本発明の１つの側面によれば、印刷ジョブの実行をキャンセルする指示をサーバから受信した際に、ジョブの進捗状況に基づき適切な実際の印刷ジョブの実行結果を当該サーバに通知できるようになる。従って、実際の印刷ジョブの実行結果を示す履歴情報を印刷装置と、サーバの両方に記憶できるようになる。

印刷システムの構成の一例である。 印刷装置１０１のハードウェア構成の一例である。 印刷装置１０１のソフトウェア構成の一例である。 クラウドプリントサービス（ＣＰＳ）への登録シーケンスの一例を説明する図である。 プル方式でイベント通知を受信するシーケンスの一例を説明する図である。 ジョブを受信するシーケンスの一例を説明する。 従来知られるキャンセル技術とプル方式の組み合わせた場合の課題の一例を説明するための図である。 第１の実施形態におけるジョブキャンセル処理のシーケンスの一例を説明する図である。 第１の実施形態におけるジョブキャンセル処理のシーケンスの一例を説明する図である。 ＣＰＳを提供するサーバ１０２上でのジョブ状態の管理を説明するための状態遷移図である。 第１の実施形態において印刷装置１０１が実行する制御の一例を示すフローチャートである。 印刷装置１０１の操作パネル２１１上に表示される画面の一例である。 第２の実施形態においてサーバ１０２が実行する制御の一例を示すフローチャートである。 第３の実施形態におけるジョブキャンセルの検知を早める処理シーケンスの一例を説明する図である。 第３の実施形態において印刷装置１０１が実行するフローチャートの一例である。 第４の実施形態におけるジョブキャンセルの検知を早める処理シーケンスの一例を説明する図である。 第５の実施形態において印刷装置１０１が実行するみなしジョブキャンセルのフローチャートの一例である。

以下、添付図面を参照して実施形態を詳しく説明する。尚、以下の実施形態は特許請求の範囲に係る発明を限定するものでない。実施形態には複数の特徴が記載されているが、これらの複数の特徴の全てが発明に必須のものとは限らず、また、複数の特徴は任意に組み合わせられてもよい。さらに、添付図面においては、同一若しくは同様の構成に同一の参照番号を付し、重複した説明は省略する。

＜第１の実施形態＞
まず、図１を用いて、本発明に係る印刷システムの構成を説明する。本実施形態に係る印刷システムは、印刷装置１０１、クライアント端末１０３、クラウドプリントサービス（以下、ＣＰＳとも呼ぶ）を提供するサーバ１０２を含む。また、以降の説明の簡略化のため、サーバ１０２が提供するクラウドプリントサービスを単にＣＰＳ１０２とも呼ぶものとする。

印刷装置１０１は、外部装置から受信した印刷ジョブに基づき紙などのシートに画像を印刷する印刷機能を有する。また、印刷装置１０１はサーバ１０２を経由して印刷ジョブを受信し、印刷を行うこともできる。クライアント端末１０３は、ＣＰＳ１０２に印刷ジョブを入稿するプリントクライアントを備えている。端末１０３は、ＣＰＳ１０２に印刷ジョブを入稿する。サーバ１０２に入稿されたジョブは、印刷装置１０１により取得され、印刷装置１０１により印刷される。

また、印刷装置１０１はセキュリティの観点で、ユーザのログインを前提とするユーザ認証管理を行うことができる。ユーザ認証管理がＯＮに設定された印刷装置はユーザがログインしていない場合、操作部にログイン画面を表示し、印刷装置が提供するコピーや送信等の各機能が利用できない状態となる。印刷装置１０１は、ログイン画面が表示された状態でユーザから受け付けたユーザ認証情報（ユーザクレデンシャルとも呼ぶ）に基づいてユーザのログインを許可するか否かを認証する。印刷装置１０１は、例えば、タッチパネルを介してＩＤとパスワードの入力を受け付けてユーザ認証情報を取得する。また印刷装置１０１は、ユーザが所有する社員証などを読み取って得られるカードＩＤやユーザＩＤをユーザ認証情報として取得する。

印刷装置１０１は、ユーザのログインが許可されると、印刷装置の操作部にメイン画面（メインメニューとも呼ぶ）を表示する。ユーザは操作部に表示されるメイン画面を介して印刷装置が備えるコピーや送信機能などの各機能が利用できるようになる。以降、本実施形態では、ユーザをログインさせて、印刷装置の操作部を介して印刷装置が備える各機能を利用できる状態に遷移することをローカルログインと呼ぶものとする。

なお、本実施形態では、印刷装置の一例として印刷機能に加えて原稿を読み取って得られた画像を外部に送信するスキャン機能等の複数の機能を有するＭＦＰ（Ｍｕｌｔｉ Ｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）を例示している。しかしながら、これに限定されるものではない。例えば、印刷機能のみを有する単機能のＳＦＰ（Ｓｉｎｇｌｅ Ｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）などであってもよい。また、本実施形態では、一例として紙などのシートへの印刷を例示しているがこれに限定されるものではなく、３次元形状データに基づき立体物を成型する３Ｄプリンタにも適用することができる。

各装置はネットワークにより通信可能に接続されている。ネットワークは例えばＬＡＮ、ＷＡＮなどの通信ネットワーク、公衆無線通信ネットワーク（例えば、ＬＴＥや５Ｇなど）、ＩＥＥＥ８０２．１１に準拠する無線ネットワークなどを組み合わせて構成されてもよい。すなわち、ネットワークはデータの送受信が可能であればよく、物理レイヤの通信方式はいずれの方式を採用してもよい。

＜印刷装置のハードウェア構成＞
続いて、図２を用いて印刷装置１０１のハードウェア構成を説明する。図２は、印刷装置１０１のハードウェア構成を示すブロック図である。

ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２０２を含む制御部２０１は、印刷装置１０１全体の動作を制御する。ＣＰＵ２０２は、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）２０４又はストレージであるＨＤＤ２０５に記憶された制御プログラムを読み出して、印刷制御や読取制御などの各種制御を行う。ＲＯＭ２０４は、ＣＰＵ２０２で実行可能な制御プログラムを格納する。ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）２０３は、ＣＰＵ２０２の主記憶メモリであり、ワークエリア又は各種制御プログラムを展開するための一時記憶領域として用いられる。ＨＤＤ２０５は、印刷データ、画像データ、各種プログラム、及び各種設定情報を記憶する。本実施形態ではストレージとしてＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）等の補助記憶装置を想定しているが、ＨＤＤの代わりにＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）などの不揮発性メモリを用いるようにしても良い。このように、ＣＰＵ２０２、ＲＯＭ２０４、ＲＡＭ２０３等のハードウェアは、いわゆるコンピュータを構成している。コンピュータとＩ／Ｆは内部バス２２０を介して通信可能に接続されている。

なお、本実施形態の印刷装置１０１では、１つのＣＰＵ２０２が１つのメモリ（ＲＡＭ２０３）を用いて後述するフローチャートに示す各処理を実行するものとするが、他の様態であっても構わない。例えば複数のプロセッサ、ＲＡＭ、ＲＯＭ、及びストレージを協働させて後述するフローチャートに示す各処理を実行することもできる。また、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）やＦＰＧＡ（Ｆｉｅｌｄ−Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）等のハードウェア回路を用いて一部の処理を実行するようにしてもよい。

スキャナインタフェース（Ｉ／Ｆ）２０８は、スキャナ２０９と制御部２０１を接続する。スキャナ２０９は原稿を読み取って、読取画像を生成する。なお、生成された読取画像はＨＤＤ２０５又はＲＡＭ２０３に格納されるものとする。スキャナ２０９によって生成された読取画像は通信装置に送信されたり、シート上への画像の印刷に用いられたりする。

プリンタＩ／Ｆ２０６は、プリンタ２０７と制御部２０１を接続する。クライアント端末やサーバ１０２から得られた印刷ジョブに基づき生成された印刷画像はプリンタＩ／Ｆ２０６を介して制御部２０１からプリンタ２０７に転送される。プリンタ２０７は制御部２０１を介して制御コマンド及び印刷画像を受信し、当該画像に基づいて給紙カセット（不図示）から給送されたシートに画像を印刷する。なお、プリンタ２０６の印刷方式は、電子写真方式であってもよいし、インクジェット方式であってもよい。また、熱転写方式などその他の印刷方式を適用することもできる。

操作パネルＩ／Ｆ２１０は、操作パネル２１１と制御部２０１を接続する。操作パネル２１１は、タッチパネル機能を有する液晶表示部や各種ハードキーを備える。操作パネル２１１は、ユーザに情報を表示する表示部やユーザの指示を受け付ける受付部として機能する。

また、制御部２０１は、ネットワークＩ／Ｆ２１２を介してＬＡＮ、ＷＡＮなどのネットワークに接続される。ネットワークＩ／Ｆ２１２は、インターネット上のクライアント端末１０３やサーバ１０２が提供するＣＰＳに情報を送信したり、インターネット上のクライアント端末１０３やＣＰＳから印刷ジョブや情報を受信したりする。

ＩＣカードリーダＩ／Ｆ２１３は制御部２０１とＩＣカードリーダ２１４を接続する。ＩＣカードリーダ２１４は、Ｆｅｌｉｃａ（登録商標）等の非接触無線を用いて社員証等のＩＣカードから所有者を特定するカードＩＤやユーザＩＤなどを取得する。ＩＣカードリーダ２１４を介して取得されたＩＤは、前述したログイン機能のためのユーザ認証情報として使用される。

クラウドプリントサービスを提供するサーバ１０２とクライアント端末１０３は、プロセッサ、メモリ、通信機能、ユーザインタフェースなど汎用コンピュータの構成を有する。当該構成は前述した印刷装置からプリンタ２０７、スキャナ２０９、ＩＣカードリーダ２１４のハードウェアと、当該ハードウェアと通信するためのＩ／Ｆを省いた構成と同様であるため、説明を省略する。なお。ＣＰＳを提供するサーバ１０２は、サーバ１０２は、複数のプロセッサ、ＲＡＭ、ＲＯＭ、及びストレージや、複数のコンピュータリソースを用いて後述するフローチャートに示す各処理を実行することができる。

＜印刷装置１０１のソフトウェア構成＞
図３は印刷装置１０１のソフトウェア構成を説明するための図である。なお、各機能部に対応する制御プログラムは図２で示したＨＤＤ２０５に記憶されており、ＣＰＵ２０２によってＲＡＭ２０３にロードされ実行される。

操作制御部３００は操作パネル２１１を制御する。操作パネル２１１上に画面を表示する制御や、ユーザからの指示入力を待ち受け、受け付けた指示内容を他の機能部に通知する。また、指示内容に応じて表示する画面を更新し、画面を操作パネル２１１に表示する。

クラウドプリントサービス登録制御部３０１はクライアント端末１０３から受信したクラウドプリントサービス登録要求を解析し、ＣＰＳ１０２に自身を登録したり、登録情報を管理したりする。

クラウドプリント印刷制御部３０２はネットワークＩ／Ｆ２１２を介してＣＰＳ１０２から受信した印刷データ(印刷ジョブ)を受信する。受信した印刷ジョブは制御部３０２により管理される。受信した印刷ジョブは、まず、印刷待ち状態のキューに投入される。続けて制御部３０２は、印刷のためのリソースであるプリンタ２０７が印刷を実行できる状態であると判断すると、キューに投入されたジョブを印刷中状態に遷移する。続けて、当該印刷ジョブに対応する印刷データと、レンダリングに必要な印刷設定を画像処理部３０６に送信する。画像処理部３０６は、印刷データと印刷設定に基づき印刷データを画像データにレンダリングする処理を行う。当該画像変換処理の一部はＡＳＩＣを用いることができる。印刷処理部３０７は、画像処理部３０６によってレンダリングされた画像データと、ジョブに含まれる設定などに基づきプリンタ２０７を制御する。具体的には、プリンタＩ／Ｆ２０６を介してプリンタ２０７に画像信号（印刷画像）と制御信号を送信する。プリンタ２０７は画像信号と制御信号に基づき、シートに画像を印刷する。

クラウドプリントイベント制御部３０８は印刷装置１０１とＣＰＳ１０２の間のイベント送信、イベント受信処理を制御する。

記憶部３０５は、印刷装置の設定情報や、ログイン認証に用いるユーザ管理情報を記憶するデータベースである。ユーザアカウント制御部３０３は記憶部３０５に記憶されたユーザアカウント情報を管理する。制御部３０３は、ユーザの追加、削除、編集等の機能を提供する。また、記憶部３０５は、印刷ジョブの実行結果を含む履歴情報も管理する。

認証制御部３０４はユーザアカウント制御部３０３が管理するユーザアカウント情報と、ユーザから受け付けた認証情報とを用いてユーザが印刷装置１０１を使用する権限を有しているか否かを認証する。

ログイン制御部３０９は認証制御部３０４や操作制御部３００と協働して、前述したログイン認証機能を提供する。ログイン制御部３０９は、印刷装置１０１に対するユーザのログイン状態を管理する。印刷装置にユーザがローカルログインしていない状態（即ち、ログアウト状態）の場合、操作制御部３００と協働して、パネル２１１にログイン画面を表示する。また、制御部３０９は、ログイン画面が表示された状態で、画面やＩＣカードリーダ２１４を介してユーザ認証情報を受信する。続けて、受信したユーザ認証情報を含む認証要求を認証制御部３０４に送信する。制御部３０９は、認証制御部３０４からユーザ認証に成功したことを示す応答を受信すると、当該認証制御部３０４やアカウント制御部３０３からユーザの情報を取得し、ユーザを印刷装置にログインさせる。制御部３０９が管理するログインしたユーザの情報は、各ソフトウェアモジュールから適宜参照される。例えば、操作制御部３００は、当該情報を参照して、ユーザに合わせてパーソナライズした画面（例えば、後述するジョブ履歴の画面）を表示する。

＜ＣＰＳを用いた印刷処理＞
続けて、図４を用いてＣＰＳ１０２を用いた印刷処理を説明する。図４は、ＣＰＳ１０２にプリンタを登録して使用するシーケンスの一例を示している。なお、以降説明するシーケンスの各処理において、「印刷装置１０１は」なる記載は、印刷装置のＣＰＵ２０２が図３で示した制御モジュール又は図示省略の制御モジュールに対応するプログラムを実行することにより実現される処理を示しているものとする。また、「ＣＰＳ１０２」はＣＰＳ１０２を提供するサーバ１０２上のプロセッサがプログラムを実行することにより実現される処理を示しているものとする。なお、印刷処理、通信の送受信処理、表示処理などに代表される一部の処理はＣＰＵ２０２と図２で説明した各ハードウェア部が協働して実現されるものとする。

Ｓ４０１（シーケンス４０１）において、印刷装置１０１、ＣＰＳ１０２、クライアント端末１０３が協働して、ＣＰＳ１０２に対する印刷装置１０１の登録処理を行う。ユーザは、クライアント端末１０３から印刷装置１０１が提供するＷｅｂＵＩ経由でクラウドプリントの設定画面を閲覧する。印刷装置１０１は、当該画面を介してなされた登録要求を検知すると、クラウドプリントサービスに登録要求を送信する。登録要求を受信したＣＰＳ１０２は、印刷装置１０１を第１の種類のクラウドプリントサービスで利用可能なプリンタとして登録する。当該登録処理により、管理者等のユーザが所持するクラウドプリントサービスのアカウントと、プリンタＩＤの対応付けが行われる。また、プリンタからジョブを取得するために必要なアクセストークンやアクセス先ＵＲＬの発行処理などが行われる。登録処理で発行されたＣＰＳ１０２とのやり取り及びジョブ受信に必要となる情報は記憶部３０５に記憶される。

ＣＰＳ１０２に対する印刷装置１０１の登録が完了すると、ＣＰＳ１０２に対応するプリントクライアントがインストールされたクライアント端末からＣＰＳ１０２経由での印刷が行えるようになる。

続けて印刷制御についてＳ４０２以降で説明する。Ｓ４０２において、クライアント端末１０３は、ＣＰＳ１０２に登録されたクラウドプリンタを用いて印刷するユーザ操作を受け付けたことに従って印刷ジョブを生成する。続けて、生成した印刷ジョブをＣＰＳ１０２に入稿する。ＣＰＳ１０２に入稿される印刷ジョブには印刷データと、印刷設定（印刷属性）、ユーザ及びテナントを識別する情報が含まれている。印刷ジョブを受信したＣＰＳ１０２は、印刷ジョブは、サーバ１０２のジョブＤＢに保存する。なお、ジョブの保存先はサーバ１０２ではなくＳ３等のクラウドストレージであってもよい。

続けてＳ４０３において、印刷装置１０１は、ＣＰＳ１０２に対して定期的に新たなイベントが発生していないかイベントの有無について問い合わせを行う。問い合わせの結果、新たな印刷ジョブがあることを示すジョブイベント通知を受け取ると、当該通知を契機として、ＣＰＳ１０２から印刷ジョブの取得、及び印刷処理を行う（Ｓ４０４）。

続けて、Ｓ４０３、Ｓ４０４で説明したイベント問い合わせ処理と、印刷処理について図５及び図６を用いて説明する。

前述したように、印刷ジョブのイベント通知にはＰｕｌｌ方式、Ｐｕｓｈ方式の２つの方法があるが、本実施形態では、Ｐｕｌｌ方式を使用する場合を例に説明する。

図５はイベント通知（Ｐｕｌｌ方式）の処理シーケンスの一例を説明する図である。印刷装置１０１は、ＣＰＳ１０２にプリンタを特定する情報（クラウドプリンタＩＤ等）と、アクセストークンなどの認証に必要な情報を含むイベント取得要求を送信する（Ｓ５０１）。

ＣＰＳ１０２は、Ｓ５０１で送信された取得要求を受信すると印刷装置１０１にイベント種別を示す情報とポーリング間隔を含むイベント応答を送信する（Ｓ５０２）。ＣＰＳ１０２は、当該イベント種別を示す情報としてＣＰＳ１０２で発生したプリンタに通知すべきイベントを示す情報を格納する。具体的には、印刷装置１０１で印刷できる印刷ジョブがＣＰＳ１０２に入稿されたことを表すジョブ受信イベントがある。また、印刷装置１０１が受信済の印刷ジョブのキャンセルをリクエストされたことを示すジョブキャンセルイベントがある。ジョブキャンセルイベントにはキャンセル対象となるジョブを特定するための特定情報（例えばジョブＩＤ）が含まれている。

イベントが発生していない場合、Ｓ５０２のイベント応答には、イベントがないことを示す情報と、ポーリング間隔がセットされる。なお、イベントがないことを示す情報は省略することも可能である。イベント要求に含まれるポーリング間隔は、印刷装置１０１に対して次回の問い合わせ間隔を指示するための情報である。例えば、ＣＰＳ１０２から３０秒や１分などの間隔が指定される。Ｓ５０２の応答を受信した印刷装置１０１は、サーバから指定されたポーリング間隔に変更がある場合、ポーリング間隔の設定を変更する。

続けて、印刷装置１０１は、ポーリング間隔の設定に基づき前回問合せからポーリング間隔に対応する時間が経過したかどうかを判断する。経過したと判断すると、印刷装置１０１は、再度、ＣＰＳ１０２にイベント取得要求を送信する（Ｓ５０３）。当該要求を受信したＣＰＳ１０２は、イベント応答を送信する。以上説明下要求と応答は設定されたポーリング間隔で繰り返し行われる。ＣＰＳ１０２は、これらの繰り返し行われるやり取りの応答を活用して印刷装置１０１に対してＣＰＳ１０２で発生したイベントを通知する。

続けてジョブ受信のシーケンスについて図６を用いて説明する。図６は、図４及び５で説明したイベント通知の仕組みによって、印刷装置１０１がジョブ受信イベントを受信した場合に実行される処理の一例を示すシーケンス図である。

なお、本実施形態では、印刷装置１０１とクラウドプリントサービス１０２との間の印刷プロトコルとして、Ｉｎｔｅｒｎｅｔ Ｐｒｉｎｔｉｎｇ Ｐｒｏｔｏｃｏｌ（ＩＰＰ）を採用する場合を例に説明する。

ジョブ受信イベントを受信した印刷装置１０１は、クラウドプリントサービス１０２に対してＧｅｔ−Ｊｏｂｓリクエストを送信する（Ｓ６０１）。印刷装置１０１は、当該リクエストのｗｈｉｃｈ−ｊｏｂｓ属性に‘ｆｅｔｃｈａｂｌｅ’をセットする。この属性は、受信可能な印刷ジョブがあるかどうかを問い合わせるリクエストであることを示す情報である。

Ｓ６０１でＧｅｔ−Ｊｏｂｓリクエストを受信したＣＰＳ１０２は、印刷装置１０１が受信可能な印刷ジョブを管理しているかどうかを判断する。印刷装置１０１が受信可能な印刷ジョブを管理していると判断した場合、ＣＰＳ１０２は、印刷装置１０１に対して、ｊｏｂ−ｆｅｔｃｈａｂｌｅ属性にｊｏｂ−ｉｄをセットしたＳｕｃｃｅｓｓレスポンスを送信する（Ｓ６０２）。ｊｏｂ−ｉｄは印刷装置が取得して印刷すべきジョブを特定するための情報である。

Ｓ６０２で送信されたレスポンスを受信した印刷装置１０１は、ＣＰＳ１０２にＦｅｔｃｈ−Ｊｏｂリクエストを送信する（Ｓ６０３）。印刷装置１０１は、Ｆｅｔｃｈ−Ｊｏｂリクエストとの応答として、ジョブの印刷設定（書誌情報）を受信する。このとき、印刷装置１０１は、Ｆｅｃｈ−Ｊｏｂリクエストに対してＣＰＳ１０２から取得したい印刷ジョブのｊｏｂ−ｉｄをセットする。以降、Ｓ６０３ｄｅセットしたｊｏｂ−ｉｄを取得対象のｊｏｂ−ｉｄとも呼ぶ。

Ｓ６０３で送信されたＦｅｔｃｈ−Ｊｏｂリクエストを受信したＣＰＳ１０２は、印刷装置１０１に対して、Ｓｕｃｃｅｓｓレスポンスを送信する（Ｓ６０４）。このとき、ｊｏｂ−ｔｅｍｐｌａｔｅ属性に印刷ジョブの印刷設定をセットする。

続けて、印刷設定を含むＳｕｃｃｅｓｓレスポンスを受信した印刷装置１０１は、当該印刷設定の形式が正常であるか判断する。正常である場合、印刷装置１０１の印刷制御部３０２は、印刷処理を内部的に管理するためのジョブを生成する。当該ジョブには、受信した印刷設定がセットされる。

Ｓ６０４で送信されたレスポンスを受信した印刷装置１０１は、クラウドプリントサービス１０２にＡｃｋｎｏｗｌｅｄｇｅ−Ｊｏｂリクエストを送信する（Ｓ６０５）。このとき、ｊｏｂ−ｉｄ属性に取得対象のｊｏｂ−ｉｄをセットする。このリクエストはジョブを受け入れたことをＣＰＳ１０２に対して通知するためのリクエストである。なお、正常でないと判断した場合、印刷装置１０１は、このリクエストにエラーを示す情報を送信し、以降のドキュメントの受信処理を中止する。

Ａｃｋｎｏｗｌｅｄｇｅ−Ｊｏｂリクエストを受信したＣＰＳ１０２は印刷装置１０１に対してＳｕｃｃｅｓｓレスポンスを送信する（Ｓ６０６）。

次に、印刷装置１０１は、ＣＰＳ１０２にＦｅｔｃｈ−Ｄｏｃｕｍｅｎｔリクエストを送信する（Ｓ６０７）。このとき、ｊｏｂ−ｉｄ属性に取得対象のｊｏｂ−ｉｄがセットされる。このリクエストは、印刷データの要求である。

Ｓ６０７で送信されるリクエストを受信したクラウドプリントサービス１０２は印刷装置１０１にＳｕｃｃｅｓｓレスポンスとともに印刷データを送信する（Ｓ６０８）。以降、ＣＰＳ１０２から印刷装置１０１に対して取得対象のｊｏｂ−ｉｄに対応する印刷データが送信される。

Ｓ６０８で送信された印刷データを正常に受信できた印刷装置１０１は、ＣＰＳ１０２にＡｃｋｎｏｗｌｅｄｇｅ−Ｄｏｃｕｍｅｎｔリクエストを送信する（Ｓ６０９）。なお、受信に対し何らかのエラーが発生した場合、印刷装置１０１は、当該リクエストにエラーを示す情報をセットし、以降の印刷処理を中止する。

続けて、Ｓ６０９で送信されたＡｃｋｎｏｗｌｅｄｇｅ−Ｄｏｃｕｍｅｎｔリクエストを受信したＣＰＳ１０２は、印刷装置１０１にＳｕｃｃｅｓｓレスポンスを送信する（Ｓ６１０）。

取得対象のｊｏｂ−ｉｄに対応する印刷データを受信した印刷装置１０１の印刷制御部３０２は、生成したジョブと当該印刷データを対応付ける。このジョブは、印刷キューに投入され、キューに投入された順序に基づき順次印刷される。印刷処理は制御部３０２、処理部３０６、３０７、及びプリンタ２０７が協働して実現する。

続けて、印刷装置１０１は、前記ジョブの処理状態をＵｐｄａｔｅ−Ｊｏｂ−Ｓｔａｔｕｓリクエストを用いて、ＣＰＳ１０２に送信する（Ｓ６１１）。当該リクエストはジョブの実行状態（例えば、ジョブのステータス（印刷待ちなのか、実行中なのか等）や何ページまでの印刷が完了したかなどの進捗状況）をＣＰＳ１０２に通知するためのリクエストである。

Ｓ６１１で送信されたＵｐｄａｔｅ−Ｊｏｂ−Ｓｔａｔｕｓリクエストを受信したＣＰＳ１０２は、印刷装置１０１に、Ｓｕｃｃｅｓｓレスポンスを送信する（Ｓ６１２）。

以降Ｕｐｄａｔｅ−Ｊｏｂ−Ｓｔａｔｕｓのやり取りを繰り返しながら印刷処理が進んでいく。印刷処理が正常に完了すると、印刷装置１０１は、Ｕｐｄａｔｅ−Ｊｏｂ−Ｓｔａｔｕｓにより、ジョブの実行が完了したことをＣＰＳ１０２に通知する。更に、印刷装置１０１は、実行結果として成功を示す情報と、ジョブの書誌情報（例えば、ページ数、部数、実行時刻、文書名（ファイル名）、投入したユーザ名）を対応付けた履歴情報を保存する。図４−６で説明した処理により、Ｐｕｌｌ方式の印刷を行うことができる。

＜課題の説明＞
続けて、図７を用いてＣＰＳ１０２やクライアント端末１０３のプリントクライアントからジョブをキャンセルする操作がなされた場合に発生しうる問題点について説明する。

図７は、特許文献１に記載されているような従来知られるキャンセル技術とＰｕｌｌ方式でジョブキャンセルのイベントを受け付ける技術を組み合わせた場合の課題の一例を説明するためのシーケンス図である。図７のシーケンスは図６でジョブの実行が開始された後に、ＣＰＳ側からジョブキャンセルのイベントが通知される場合の処理を示している。

ここでは、印刷対象のジョブが合計１１ページの印刷で、１０ページ目の印刷が完了した後にＣＰＳ１０２でジョブキャンセルの指示がなされた場合を例示している。また、ジョブ状態は、各装置で管理される印刷ジョブの状態と、その状態遷移を説明する図である。

まず、印刷装置１０１は、Ｕｐｄａｔｅ−Ｊｏｂ−Ｓｔａｔｕｓリクエストでジョブが実行中であること、及び１０ページ目まで印刷が完了したことを示すジョブステータスを通知する（Ｓ７１１）。具体的には、Ｓ７１１に図示している「ｊｏｂ−ｓｔａｔｅ：ｐｒｏｃｅｓｓｉｎｇ、ｊｏｂ−ｐａｇｅｓ−ｃｏｍｐｌｅｔｅｄ：１０」を含むリクエストを送信する。これは、ジョブが印刷処理中であり、１０ページ目の出力が完了したことを示している。当該リクエストを受信したＣＰＳ１０２は、Ｓｕｃｃｅｓｓレスポンスを送信する（Ｓ７１２）。当該通知に基づき、ＣＰＳ１０２は、クラウド上の印刷状態を管理するためのジョブの状態を処理中である「ｐｒｏｃｅｓｓｉｎｇ」状態で保持し続ける。

続けて、Ｓ７２１において、ＣＰＳ１０２は、クライアント端末のプリントクライアント又はＣＰＳ１０２がクライアント端末に提供するＷｅｂＵＩからジョブのキャンセル要求を受け付けたことを検知する。続けて、要求を受け付けたタイミングでサーバ上のジョブの状態を「Ｃａｎｃｅｌｌｅｄ」状態に遷移させる。ここで、「Ｃａｎｃｅｌｌｅｄ」状態に状態遷移したジョブはＩＰＰではすでに実行終了したジョブとして取り扱われる。しかしながら、Ｐｕｌｌ方式を採用する場合、所定のポーリング間隔（前述した３０秒や１分）でジョブキャンセルのイベントを通知することとなる。従って、このタイミングではキャンセルが通知されない場合がある。

従って、印刷装置１０１ではジョブは正常実行中の状態で進む。次ページである１１ページ目の印刷が完了すると印刷装置１０１は、ＣＰＳ１０２に対して１１ページ目を印刷したことを示すジョブステータスを通知する（Ｓ７１３）。

Ｓ７１３で送信されたリクエストを受信した、ＣＰＳ１０２はＵｐｄａｔｅ−Ｊｏｂ−Ｓｔａｔｕｓリクエストで指定されたジョブの状態更新を試みる。しかしながら、当該ジョブはＳ７２１で説明したキャンセル処理に起因して、既に最終状態に達している。

従って、印刷装置１０１に対して、更新が行えなかったこととその要因を補足する説明の文字列を含むＥｒｒｏｒレスポンスを送信する（Ｓ７１４）。当該エラーは、ジョブステータスリクエストに失敗したことを示すエラーであるため、この時点では、印刷装置１０１は、印刷ジョブの印刷処理を継続することになる。従って、１１ページ目の印刷が完了すると、印刷装置１０１上は、印刷ジョブの実行を正常完了する（Ｓ７２２）。その結果、印刷装置１０１上で管理される印刷ジョブのジョブ状態は「ｃｏｍｐｌｅｔｅｄ」状態になる。

続けて、印刷装置１０１はＣＰＳ１０２に対してＵｐｄａｔｅ−Ｊｏｂ−Ｓｔａｔｕｓリクエストを用いてジョブ状態が実行中から正常完了に遷移したことを通知する。具体的には、ｊｏｂ−ｓｔａｔｅ：ｃｏｍｐｌｅｔｅｄといった属性を含むリクエストを送信する。この属性はジョブが完了したことを示している。

当該リクエストを受信したＣＰＳ１０２は、クラウド上のジョブ状態は既に最終状態であるＣａｎｃｅｌｌｅｄ状態であるため、ＣＰＳ１０２はジョブ状態の更新に失敗する。その結果として、印刷装置１０１に、再度Ｅｒｒｏｒレスポンスを送信する（Ｓ７１６）。

また、印刷装置１０１は、ジョブの実行処理と並列して、前回問合せからポーリング間隔に対応する時間が経過したかどうかを判断する処理を行っている。経過したと判断すると、印刷装置１０１は、ＣＰＳ１０２に対して図５で説明したイベント取得要求を送信する（Ｓ７１７）。Ｓ７１７で送信された取得要求を受信したＣＰＳ１０２は、印刷装置１０１に対してジョブをキャンセルするイベント種別を示す情報を含むイベント通知を送信する（Ｓ７１８）。しかしながら、このタイミングでは、ジョブの実行が完遂されているため、ジョブ状態やジョブ履歴を変更することができない。また、ジョブ履歴を変更するにしても実際に正常終了したものをキャンセルに更新するのは、事実に反する結果となるため、望ましくない。

このように、印刷の進行状態と、要求のレスポンスとしてイベント通知を受信するタイミングによっては、印刷装置におけるジョブの実行が完了しまうケースが発生しうる。この場合、実際のジョブの実行結果と、サーバ上で記憶される実行結果に不整合が発生する場合がある。なお、Ｐｕｓｈ方式で通知を行う場合においても、印刷装置における印刷の進行状態によっては、印刷の中止処理が間に合わず印刷処理が完了してしまう場合もある。即ち、従来のサーバ側でのジョブキャンセルを優先し、印刷装置にキャンセルを通知する構成では、印刷装置でロギングされる履歴情報（実際の実行結果）と、ＣＰＳ１０２でロギングされる履歴情報が異なってしまうといった問題がある。

本実施形態では、これらの問題の少なくとも１つを鑑み、キャンセル要求が発行されたタイミングでは、クラウド上で即座にジョブをキャンセルするのではなく、停止状態として取扱う機能を提供する。更に、印刷ジョブの実行をキャンセルする指示をＣＰＳ１０２から受信した際に、ジョブの進捗状況に基づき適切な実際の印刷ジョブの実行結果をＣＰＳ１０２に通知でき、適切にジョブの実行履歴を更新できる仕組みを提供する。

以下具体的に説明する。図８、図９は本実施形態を適用したジョブキャンセルのシーケンスの一例を説明する図である。

＜キャンセルに成功する場合の例＞
まず、図８を用いてキャンセルに成功する場合のシーケンスを説明する。ここでは、ＣＰＳから取得して処理中の印刷ジョブが５０ページであり、所定のポーリング間隔(３０秒や１分)後にイベントの有無を問い合わせてもキャンセルが間に合う場合を想定している。Ｓ８１１〜Ｓ８１２は図７のＳ７１１〜７１２と同様のジョブステータスの更新リクエストと応答である。また、図７の説明と同様のタイミングでユーザ操作によるジョブキャンセルの要求が行われたものとして説明する。

ＣＰＳ１０２は、ジョブのキャンセル操作を受け付けた場合に、一時停止状態に遷移する（Ｓ８２１）。従って、クラウドプリントサービス１０２上で管理されるジョブの実行状態（ジョブ状態）はＩＰＰの規格においてジョブの一時停止を意味する「ｐｒｏｃｅｓｓｉｎｇ−ｓｔｏｐｐｅｄ」状態に遷移することになる。また、ＣＰＳ１０２は、ジョブ状態に遷移した理由を示す情報であるｊｏｂ−ｓｔａｔｅ−ｒｅａｓｏｎｓに「ｃａｎｃｅｌｅｄ−ｂｙ−ｕｓｅｒ」をセットする。

印刷装置１０１は次ページ（１１ページ）目の印刷が完了すると、１１ページ目の印刷が完了したことを示すリクエストを送信する。ＣＰＳ１０２は、停止状態のジョブの進捗状態を更新するとともに、当該リクエストの応答として、Ｓｕｃｃｅｓｓレスポンスを送信する。以降、ポーリングによるイベント取得が発生するまでは、印刷装置１０１における印刷処理とジョブステータスの更新が正常に実行される。

次に、印刷装置１０１は、前回問合せからポーリング間隔に対応する時間が経過したと判断すると、ＣＰＳ１０２に対して図５で説明したイベント取得要求を送信する（Ｓ８１３）。ここで、ＣＰＳ１０２は、実行中の印刷ジョブの状態を、一時停止且つ、ユーザキャンセルによって一時停止しているといったジョブ状態でジョブを管理している。このジョブ状態を踏まえ、ＣＰＳ１０２は、印刷装置１０１に対してジョブをキャンセルすることを要求するイベントを送信する（Ｓ８１４）。

Ｓ８１４で送信されたキャンセルを示すイベント通知を受信した印刷装置１０１は、キャンセルを受け入れるべき状況か否かを判断する。ここでは、ジョブが正常実行中であるため、キャンセルを受け入れるべきであると判断し、ジョブの実行をキャンセルする。更に、印刷装置１０１は、ジョブの実行に失敗した実行結果と共にジョブの書誌情報を対応付けた履歴情報を記憶部３０５に格納する（Ｓ８２２）。当該履歴はジョブ実行履歴の表示に用いられたり、顧客の情報管理サーバに送信されたりする。

続けて、印刷装置１０１は、ＣＰＵ２０２に対して、Ｕｐｄａｔｅ−Ｊｏｂ−Ｓｔａｔｕｓリクエストを用いて、ジョブをキャンセルしたことを示すジョブステータスを通知する（Ｓ８１５）。このジョブステータスには、キャンセルに達するまでに何ページ印刷されたかなどのステータスも含まれているものとする。

当該リクエストを受信したＣＰＳ１０２は、クラウド上で管理するジョブ状態を「Ｃａｎｃｅｌｌｅｄ」状態に遷移する。続けて、当該終了状態に達したジョブの履歴情報を記憶する（Ｓ８２３）。この場合、ＣＰＳ１０２の記憶領域には、ジョブの実行に失敗した実行結果と共に、ジョブの書誌情報を対応付けた履歴情報が記憶される。書誌情報にはキャンセルに達するまでに印刷された枚数やキャンセル理由などがセットされる。最後に、ＣＰＳ１０２は、印刷装置１０１に対してジョブ状態の更新に成功したことを示すレスポンスを応答する（Ｓ８１６）。

この処理により、キャンセル時までに実際に出力された印刷物の枚数を正確に更新することができる。

＜キャンセルに失敗する場合の例＞
続けて、キャンセルに失敗する場合の例について図９を用いて説明する。図９においては印刷ジョブの総ページ数が１１ページであり、キャンセル通知を受け付ける前に印刷が完了するケースを想定している。

Ｓ９１１〜Ｓ９１２のジョブステータスのアップデートは図７のＳ７１１〜Ｓ７１２と同様である。またＳ９２１のＣＰＳ１０２がジョブ状態を一時停止状態に変更する制御や、その後も印刷処理が継続するといった処理の流れは、図８と同様のため説明を省略する。

１１ページ目の印刷が完了すると、印刷装置１０１は、自身が管理する実行中の印刷ジョブの状態を完了状態に遷移する（Ｓ９２２）。続けて、ジョブ状態を正常終了に変更する要求をＣＰＳ１０２に通知する（Ｓ９３１）。当該通知を受信したＣＰＳ１０２は、Ｓｕｃｃｅｓｓレスポンスを応答する（Ｓ９３２）。一方で、ＣＰＳ１０２はキャンセル待ち状態でジョブを一時停止しており、キャンセル要求の結果を受け取っていない。従って、ＣＰＳ１０２は、ジョブの状態を一時停止状態でキープする。

以降、Ｓ９１３〜９１４の処理でＳ８１３〜Ｓ８１４と同様のキャンセル要求を示すイベントが送信される。キャンセル要求を示すイベントを受信した印刷装置１０１は、キャンセルを受け入れるべき状況か判断する。ここでは、印刷装置１０１は、印刷が正常終了していることを鑑み、キャンセル要求を受け入れないと判断する（Ｓ９２３）。続けて、印刷装置１０１は、ＣＰＳ１０２に対してジョブが正常終了したことを示すジョブステータスを通知する（Ｓ９１５）。このステータスには、キャンセルの要求は受け入れられたが、印刷が正常終了したことを示す情報がセットされる。当該情報は一例であり、キャンセル要求が間に合わなかったことをＣＰＳ１０２に通知できる情報であればよい。

Ｓ９１５で送信されたジョブステータスの更新リクエストを受信したＣＰＳ１０２は、ジョブ状態を「ｃｏｍｐｌｅｔｅｄ」状態に遷移させる。続けて、当該ジョブの実行結果と書誌情報を対応付けた履歴情報を保存する（Ｓ９２４）。この履歴にはキャンセルが試行されたが、間に合わなかったことを示す情報が含まれるものとする。最後に、ＣＰＳ１０２は、印刷装置１０１に対して更新が成功したことを示すレスポンスを送信する（Ｓ９１６）。

なお、本実施形態では、Ｓ９３２の処理シーケンスにて、成功を返し、ジョブ状態を一時停止状態でキープする場合を想定している。しかしながら、下記のように制御することもできる。ＣＰＳ１０２は、Ｓ９３１で送信されたジョブ完了の通知をもって、ジョブ状態を「ｃｏｍｐｌｅｔｅｄ」に変更するようにしてもよい。この場合、ＣＰＳ１０２は、次回のイベント通知で送信する予定であったジョブキャンセルのイベント種別を含む要求を破棄する。また、ＣＰＳ１０２は、ユーザによるキャンセル要求により一時停止しているジョブが、正常終了である「ｃｏｍｐｌｅｔｅｄ」状態に遷移するといった条件を満たす場合にその旨を履歴情報に記憶する。例えば、キャンセルが試行されたが、間に合わなかったことを示す情報をジョブの履歴情報にセットする。

図１０は、ＣＰＳ１０２が管理するジョブの実行状態とその遷移を説明する状態遷移図の一例である。ステートＳ１は、実行中を示している。ＣＰＳ１０２は、ジョブの管理状態がＳ１の状態で、ＣＰＳが提供するＷｅｂＵＩ又はクライアントからのジョブキャンセル要求を受信すると対応するジョブの管理状態をＳ２に遷移させる。Ｓ２は前述した一時停止状態を示している。また、ＣＰＳ１０２は、Ｓ１の管理状態でジョブ完了を示す通知を受信すると、対応するジョブの管理状態をＳ４に遷移させる。Ｓ４は、前述した正常完了状態を示している。最後にＣＰＳ１０２は、ジョブの管理状態がＳ２の状態で、印刷装置からステータスをキャンセルに更新するリクエストを受信すると、状態をＳ３のキャンセル状態に遷移させ、ステータスを正常終了に更新するリクエストを受信すると、状態をＳ４に遷移する。

続けて、印刷装置１０１が実行する具体的な制御について図１１のフローチャートを用いて説明する。図１１のフローチャートに示す各動作（ステップ）は、ＣＰＵ２０２がＲＯＭ２０４又はＨＤＤ２０５に記憶された各制御モジュールを実現するためのプログラムをＲＡＭ２０３に読み出し、実行することにより実現される。なお、各動作を引き起こす主体となる制御モジュールを明確に示す場合においては、図３に例示した制御モジュールの名称を主体として各動作を記載するものとする。

ステップＳ１１０１において、ＣＰＵ２０２は、前回問合せからポーリング間隔に対応する時間が経過し、イベント問合せのタイミングに達したと判断すると、処理をＳ１１０２に進める。一方、ＣＰＵ２０２は、イベント問合せのタイミングに達していないと判断すると、処理をＳ１１１４に進める。

まず、ポーリングによるイベント取得について説明する。Ｓ１１０２において、ＣＰＵ２０２はサーバ１０２（ＣＰＳ１０２）にイベント取得要求を送信する。続けて当該取得要求の応答としてイベント通知を受信する。続けて、ＣＰＵ２０２は、Ｓ１１０３において、ＣＰＵ２０２は、イベント通知がジョブ受信イベントであるか否かを判断する。ジョブ受信イベントである場合、処理をＳ１１０４に進め、ジョブ受信イベントでない場合、処理をＳ１１０６に進む。

Ｓ１１０４において、ＣＰＵ２０２は、ネットワークＩ／Ｆ２１２及びプリンタ２０７と協働してジョブ受信イベントをトリガーとした印刷ジョブの受信処理並びに印刷処理を実行する。ジョブの受信処理は、図６で説明した通信シーケンスに則り実行されるものとする。ジョブを受信すると、印刷制御部３０２は、印刷状態を内部で管理するためのジョブを生成し、印刷の進捗を管理する。なお、Ｓ１１０４で説明した印刷ジョブの実行や、ジョブ状態の状態管理は、本フローチャートで説明する各処理と並列に実行されるものとする。

Ｓ１１０５において、ＣＰＵ２０２は、Ｓ１１０４で取得した印刷ジョブの実行が完了したか否かを判断する。具体的には、印刷制御部３０２が管理するジョブ状態が完了状態に遷移した場合にジョブ実行が完了したと判断する。ジョブ状態が完了状態に遷移した場合、処理をＳ１１１３に進め、ジョブ状態が完了状態に遷移していない場合は、処理をＳ１１０６に進める。

Ｓ１１１３において、ＣＰＵ２０２は、実行結果として成功を示す情報と、ジョブの書誌情報（例えば、ページ数、部数、実行時刻、文書名、投入したユーザ名）を対応付けた履歴情報を記憶部３０５に格納する。更に、ＣＰＵ２０２は、サーバ１０２（ＣＰＳ１０２）に対して当該印刷が完了したジョブのジョブ状態をＣｏｍｐｌｅｔｅｄに変更する要求を送信する。ＣＰＳ１０２は、当該要求に基づいてクラウド上で管理するジョブ状態を正常完了を示すＣｏｍｐｌｅｔｅｄ状態に変更する。履歴の格納処理が完了すると、ＣＰＵ２０２は、処理をＳ１１０６に進める。

Ｓ１１０６において、ＣＰＵ２０２は、イベント通知にジョブ状態の変更イベントが含まれているか否かを判断する。なお、ここでは、変更イベントとしてキャンセル要求が送られるものとして説明する。その他の変更イベント（例えば、一時停止状態に変更）の制御は紙面の都合で省略するが、当該変更イベントにあったジョブ状態の遷移を行えばよい。ＣＰＵ２０２は、ジョブをキャンセルする要求を含む変更イベントが含まれている場合、処理をＳ１１０７に進め、ジョブをキャンセルする要求を含む変更イベントが含まれていない場合、処理をＳ１１０１に進める。

Ｓ１１０７において、印刷制御部３０２は、キャンセルが要求された印刷ジョブが印刷待ち状態で待機している印刷ジョブであるか否かを判断する。具体的には、印刷制御部３０２は、キャンセルする要求に含まれるジョブ特定情報（例えば、ｊｏｂ−ｉｄ）に基づき印刷装置１０１上で管理するジョブを特定し、当該ジョブの状態を取得する。当該ジョブの状態が印刷待ち状態であれば、処理をＳ１１０９に進め、印刷待ち状態でなければ、処理をＳ１１０８に進める。続けて、Ｓ１１０８において、印刷制御部３０２は、キャンセルが要求された印刷ジョブがプリンタ２０７で印刷実行中のジョブであるか否かを判断する。印刷実行中のジョブである場合、処理をＳ１１０９に進め、印刷実行中のジョブでない場合、処理をＳ１１１２に進める。例えばキャンセルが要求された印刷ジョブが既に正常完了している場合、Ｓ１１１２の処理に進むこととなる。

Ｓ１１０９において、印刷制御部３０２は、画像処理部３０６、印刷処理部３０７、及びプリンタ２０７と協働して当該キャンセルが要求されたジョブの中止処理を開始する。なお、Ｓ１１０９で開始された中止処理が完了すると、ＣＰＵ２０２は、当該中止処理の結果と当該ジョブの書誌情報を対応付けた履歴情報を記憶部３０５に格納する。

続けてＳ１１１０において、ＣＰＵ２０２は、ジョブの進捗状態に基づき、キャンセル処理が間に合うかどうかを判断する。キャンセル処理が間に合い、実際の印刷を開始する前にキャンセルが行える場合、及び、印刷の実行中に途中キャンセル（中止）が行える場合、処理をＳ１１１１に進める。一方、キャンセル処理が間に合わず、ジョブで意図される成果物が正しく出力完了すべきと判断した場合、処理をＳ１１１２に進める。例えば、ＣＰＵ２０２は、最終ページに対する画像形成並びに定着処理などが完了しており、当該印字物を排出する最終処理を行うだけでジョブを完遂できる場合、出力完了すべきと判断する。なお、Ｓ１１１０の判断処理に代えて、中止処理の結果が確定するまで待ち、中止結果に基づき、中止が間に合ったかどうかを判断するようにしてもよい。

Ｓ１１１１において、ＣＰＵ２０２は、サーバ１０２（ＣＰＳ１０２）に対してＵｐｄａｔｅ−Ｊｏｂ−Ｓｔａｔｕｓリクエストを用いて当該キャンセルが要求されたジョブの状態をキャンセル状態（Ｃａｎｃｅｌｌｅｄ）に変更する通知を送信する。この通知には、最終的に印刷されたページ数など、ジョブがエラー完了に達した時の印刷実績なども含まれる。当該通知を受信したＣＰＳ１０２は、ジョブの状態を中止状態に変更し、そのジョブの実行結果を示す履歴情報を格納する。

Ｓ１１１２において、ＣＰＵ２０２は、サーバ１０２（ＣＰＳ１０２）に対してＵｐｄａｔｅ−Ｊｏｂ−Ｓｔａｔｕｓリクエストを用いて当該キャンセルが要求されたジョブの状態を正常完了に更新する要求を行う。この要求には、図９のＳ９３３で説明した、キャンセルが間に合わなかったことを示す情報が含まれるものとする。ＣＰＳ１０２は、当該要求に基づきジョブを正常状態に遷移させ、当該ジョブの履歴情報を記憶する。

続けて、Ｓ１１１４において、ログイン制御部３０９は、ユーザのローカルログインのイベント又は、ローカルログインしているユーザのログアウトのイベントが発生したかどうかを判断する。ログイン又はログアウトのイベントが発生した場合、処理をＳ１１１５に進め、ログイン又はログアウトのイベントが発生していない場合、処理をＳ１１１６に進める。

Ｓ１１１５において、ログイン制御部３０９は、認証制御部３０４、操作制御部３００、パネル２１１と協働してユーザのローカルログイン処理又はログアウト処理を実行する。ログイン処理を行った場合、ユーザに対応する画面（例えば、機能を選択するメインメニュー画面）が表示される。ログアウト処理を行った場合、ログインイベントを待ち受けるログイン画面が表示される。

Ｓ１１１６において、ＣＰＵ２０２は、ジョブ履歴を参照するユーザ操作を受け付けたか否かを判断する。パネル２１１を介してジョブ履歴を参照するユーザ操作を受け付けた場合、処理をＳ１１１７に進め、パネル２１１を介してジョブ履歴を参照するユーザ操作を受け付けていない場合、処理をＳ１１１８に進める。

Ｓ１１１７において、操作制御部３００は、パネル２１１と協働してジョブ履歴を確認する画面を表示する。Ｓ１１１７で表示される画面について図１２を用いて説明する。図１２（Ａ）、（Ｂ）は、印刷装置１０１のパネル２１１に表示される画面の一例である。

図１２（Ａ）は、Ｓ１１１５の処理で「ＵｓｅｒＡ」がログインした状態で、ジョブ履歴を参照するユーザ操作を受け付けた場合に表示される画面を例示している。領域１２０１はジョブの履歴情報のリストを表示する表示領域である。

当該画面においては、印刷装置１０１にローカルログイン中のユーザのジョブ履歴は、ジョブ名称を確認できるよう表示し、その他のユーザのジョブ履歴情報については、セキュリティの観点でジョブ名称を確認できないようマスクをかけた状態で表示する。また、詳細キー１２０２は、ジョブの詳細情報（印刷ページ数等）を確認する場合に使用するキーである。ＣＰＵ２０２は、セキュリティの観点でその他のユーザが実行したジョブの詳細情報は確認できないよう画面を表示制御する。例えば、その他のユーザのジョブがリストから選択された場合、キー１２０２をグレーアウト状態に遷移する。

一方、図１２（Ｂ）はユーザがログアウトしているログアウト状態で、ジョブ履歴を参照するユーザ操作を受け付けた場合に表示される画面を例示している。この場合、領域１２１１に示すようにすべてのジョブ名を確認できないように表示する。また、ＣＰＵ２０２は、詳細キー１２１２もグレーアウト状態で表示し、詳細情報を確認できないように表示制御を行う。なお、管理者権限を有するユーザがログインしている場合は、前ユーザのジョブ名や詳細情報を確認できる画面を表示するようにしてもよい。即ち、ユーザがログインしている状態と、ログインしていない状態とでジョブ履歴の表示形式を異ならせることができる。

図１１の説明に戻る。Ｓ１１１８において、ＣＰＵ２０２はシャットダウンのイベントが発生したかどうかを判断する。シャットダウンのイベントが発生した場合、印刷装置１０１は、シャットダウン処理を実行して、印刷装置１０１の電源を切る。シャットダウンのイベントが発生していない場合、Ｓ１１０１の処理に戻り、更なるイベントやユーザ操作を待ち受ける。

以上説明した第１の実施形態によれば、印刷ジョブの実行をキャンセルする指示をサーバから受信した際に、ジョブの進捗状況に基づき適切な実際の印刷ジョブの実行結果を当該サーバに通知できるようになる。また、サーバ上では当該通知に従ってジョブの状態が適切に更新され、実際の印刷ジョブの実行結果を履歴情報として保存できるようになる。従って、サーバ１０２と印刷装置１０１の両方で履歴情報を正しく管理できるようになる。

＜第２の実施形態＞
第２の実施形態では、第１の実施形態で説明した各種制御に加えて、ジョブの受信・実行中にイベント通知のポーリング間隔を意図的に短くする制御を行う仕組みについて説明する。なお、システム構成、ハードウェア構成、ソフトウェア構成は第１の実施形態と同様である。

図１３に示すフローチャートの各処理は、ＣＰＳ１０２のサービスを提供する実リソースとしてのサーバ１０２のプロセッサがプログラムを実行することにより実現される。図１３では、ＣＰＳ１０２で実行されるイベント通知とキャンセルに関わるジョブ状態管理に関する制御を抜粋して説明する。

Ｓ１３００において、サーバ１０２は、印刷装置１０１が印刷可能な印刷ジョブがＣＰＳ１０２に入稿されている状態でイベント通知の要求を受け付けたか否かを判断する。入稿されている状態でイベント通知の要求を受け付けた場合、処理をＳ１３０１に進める。入稿されていない状態でイベント通知の要求を受け付けた場合、図５で説明した、通常間隔でイベント通知のレスポンスを送信し、Ｓ１３０２に処理を進める。

Ｓ１３０１において、サーバ１０２は、ポーリング間隔を通常間隔より短い間隔に切り替えたイベント通知に対するレスポンスを送信する。当該レスポンスを受信したＣＰＳ１０２は、新たに通知された間隔で次回のイベント通知の要求を送信することになる。従って、ジョブの実行中はポーリングの間隔を短くすることができる。例えば、５秒間隔等を設定することができる。

Ｓ１３０２において、サーバ１０２はジョブをキャンセルするユーザ操作を受け付けた場合、処理をＳ１３０３に進め、受け付けていない場合、処理をＳ１３０４に進める。続けて、Ｓ１３０３において、サーバ１０２は、キャンセルが要求されたジョブの状態を図８、図１０で説明した一時停止状態に変更する。

Ｓ１３０４において、サーバ１０２は、印刷装置１０１からジョブを最終状態へ更新する要求を受信したか否かを判断する。受信した場合は、処理をＳ１３０５に進め、受信していない場合、図１１で説明した印刷装置上での印刷処理又はキャンセル処理の完了を待ち受ける。Ｓ１３０５において、サーバ１０２は、受信した実行結果に基づきジョブのステータスを最終状態に更新する。Ｓ１３０５において、サーバ１０２は、Ｓ１３０５の要求に対応するジョブの状態を最終状態に更新する。Ｓ１３０６において、サーバ１０２は、Ｓ１３０５で最終状態に更新したジョブの実行結果を示す履歴情報を記憶領域に格納する。

最後にＳ１３０７において、サーバ１０２は、ポーリング間隔を通常間隔に切り替える。
当該ポーリング間隔は、次回のイベント通知の要求を受信した場合に、当該要求のレスポンスとして、印刷装置に通知される。なお、ＣＰＳ１０２は、クラウド上で管理している印刷装置１０１用の印刷キューに印刷中及び印刷待ちの印刷ジョブが残っている場合、切り替えのタイミングを以下のように変形してもよい。例えば、印刷装置１０１用の印刷中及び印刷待ちのジョブが全て完了状態になったことに従ってＳ１３０７の処理を行うようにしてもよい。

以上説明した処理によりジョブの受信、実行中におけるポーリング間隔を短くすることができる。従って、履歴情報を正しく記憶しつつ、尚且つ、印刷装置１０１に対してキャンセル要求を迅速に伝えることができるようになる。

＜第３の実施形態＞
第３の実施形態では、第２の実施形態とは異なる通信制御でＣＰＳ１０２からのキャンセル要求を迅速に受信する仕組みについて説明する。なお、システム構成、ハードウェア構成、ソフトウェア構成は第１の実施形態と同様である。第３の実施形態では、印刷装置１０１側でイベントとは異なる問い合わせを行うことで、キャンセル要求があることを知る。図１４は第１の実施形態における図６に代わる通信制御のシーケンスである。第１の実施形態と同様の動作については適宜説明を省略する。

図６との差分は、ジョブ状況の更新など、印刷装置１０１がＣＰＳ１０２に対してジョブに関する情報を自発的に通知する際に、当該ジョブがキャンセルされていないかどうかを監視する制御シーケンスを追加している点である。図１４においては、説明のため、当該監視のためのシーケンス（Ｓ１４２１〜Ｓ１４３０）を太字で示している。

印刷装置１０１は印刷ジョブに対する各種リクエストを送信する前に、当該ジョブがキャンセルされていないか確認する目的で「ｇｅｔ−ｊｏｂ−ａｔｔｒｉｂｕｔｅｓリクエスト」をＣＰＳ１０２に対して送信する。これはジョブの属性情報を取得するリクエストである。当該リクエストには、ジョブステータスを更新すべき、又は次の操作（設定やデータのフェッチ操作）に進むべきジョブのｊｏｂ−ｉｄがセットされる（Ｓ１４２１）。
当該要求を受信したＣＰＳ１０２は、印刷装置１０１に対してジョブの属性情報を応答する（Ｓ１４２２）。当該属性情報には、クラウド上で管理されるジョブのステータス（状態）を示すＳｔａｔｕｓ Ｍｅｓｓａｇｅと、その状態に遷移した理由を示す情報が含まれているものとする。従って、印刷装置１０１は、これらのレスポンスに基づき、キャンセル要求が行われていることを迅速に確認することができる。これらの監視のためのシーケンスは、ジョブをフェッチするタイミング、設定を受信するタイミング、印刷データをフェッチするタイミング、ジョブステータス（印刷済み枚数等）を更新するタイミングで実行される。

具体的な制御方法について図１５を用いて説明する。図１５は、上述した監視を行うため、第１の実施形態の図１１のフローチャートに追加で組み込む制御を抜粋したフローチャートを示している。

図１１で説明した各種イベントや操作を待ち受ける操作を繰り返すＣＰＵ２０２は、図１１のＳ１１１８でＮｏと判定された場合に、更に、Ｓ１１１９〜Ｓ１１２１の監視処理を実行する。

Ｓ１１１９において、ＣＰＵ２０２は、サーバに通知すべきジョブ状況の更新が必要であるか否かを判断する。ジョブ状況の更新が必要と判定した場合、処理をＳ１１２０に進め、必要でないと判定すると処理を図１１のＳ１１０１に進める。

Ｓ１１２０において、ＣＰＵ２０２は、Ｓ１１１９でジョブ状況の更新が必要とされたジョブのｊｏｂ−ｉｄを指定したｇｅｔ−ｊｏｂ−ａｔｔｒｉｂｕｔｅｓメッセージを生成し、サーバ１０２（ＣＰＳ１０２）に対して当該ジョブの属性情報を要求する。

続けて、Ｓ１１２１において、ＣＰＵ２０２は、ＣＰＳ１０２から受信した応答に含まれるジョブステータスが一時停止状態を示しており、且つ、ユーザによりキャンセルされたことを示す情報が含まれているかどうかを判断する。ＣＰＵ２０２は、ジョブが一時停止状態且つユーザによるキャンセルを示す情報が含まれている場合、処理をＳ１１０７以降のキャンセル処理に進める。一方、ジョブの状態が一時停止状態ではない場合、処理をＳ１１０１に進める。

以上説明した制御により、ＣＰＳ１０２側からキャンセルが要求されていることを迅速に確認できるようになる。従って、履歴情報を正しく記憶しつつ、尚且つ、迅速なジョブキャンセル処理ができるようになる。

＜第４の実施形態＞
第１の実施形態では、ＣＰＳ１０２上でジョブを一時停止状態に遷移した後に、当該ジョブのステータス更新を正常に受け入れたことを示すＳｕｃｃｅｓｓ応答を行う場合を例示した。第４の実施形態では、当該Ｓｕｃｃｅｓｓｓ要求に、ステータスの不整合を通知する情報をセットし、キャンセル要求がなされたために一時停止状態になっていることを迅速に通知する仕組みについて説明する。

図１６は、第４の実施形態におけるジョブキャンセルのシーケンスを説明する図である。Ｓ１６１１〜Ｓ１６１２、Ｓ１６２１の制御は第１の実施形態のＳ８１１〜Ｓ８１２、Ｓ８２１で説明したジョブ実行中のキャンセル受付処理と同様であるため説明を省略する。

Ｓ１６１３において、印刷装置１０１は、ＣＰＳ１０２に対して１１ページ目の印刷が完了したことを示すジョブステータスの更新要求を送信する。当該要求を受け付けたＣＰＳ１０２は、当該更新要求に基づき停止ジョブの進捗状態を更新する。

ＣＰＳ１０２は更新要求に含まれるｊｏｂ＿ｉｄに基づき、キャンセル待ちで一時停止しているジョブに対してステータスの更新が要求されていると判断すると、条件付き（但し書き付き）のＳｕｃｃｅｓｓステータスを応答する（Ｓ１６１４）。具体的には、Ｓｕｃｃｅｓｓ応答に対してジョブの不整合が発生していることを示す情報がセットされる。この情報はステータスコードとして定義されてもよいし、自然言語による文字列などで記述されてもよい。また、キャンセル待ちのため一時停止していることを印刷装置に通知する情報が含まれていてもよい。

当該レスポンスを受信した印刷装置１０１は、当該レスポンスに含まれる但し書きを示す情報に基づきキャンセルを受け入れるべきかどうかを判断する（Ｓ１６２２）。当該判断処理は、第１の実施形態の図９、図１１で説明した判断処理と同様であるため、説明は省略する。印刷装置１０１は、ＣＰＳ１０２上のジョブ状態を、Ｓ１６２２の判断結果に基づく最終結果に更新する要求をＣＰＳ１０２に送信する（Ｓ１６１５）。当該要求を受信したＣＰＳ１０２は、ＣＰＳ１０２上で管理するジョブ状態を印刷装置から通知された最終結果に基づき更新する。また、当該ジョブに対応する履歴情報を記憶領域に格納する（Ｓ１６２３）。

以上説明した制御により、ＣＰＳ１０２側からキャンセルが要求されていることを迅速に確認できるようになる。従って、履歴情報を正しく記憶しつつ、尚且つ、迅速なジョブキャンセル処理ができるようになる。

＜第５の実施形態＞
第１乃至第４の実施形態では、ＣＰＳ１０２側でキャンセル要求が受け付けられた場合に、ジョブを一時停止する場合を例に説明した。第５の実施形態では、ＣＰＳ１０２側がクラウド上のジョブの即時キャンセルを採用しつつ、尚且つ、イベント通知にはＰｕｌｌ方式を採用するケースを想定している。即ち、図７のシーケンスで説明した、ＣＰＳ１０２でジョブの即時キャンセルを行う場合を想定している。

第５の実施形態では、このようなケースにおいて印刷装置１０１が通信のやりとりから読み取れる情報を活用して、イベント通知によるキャンセル通知を待つことなく、ジョブキャンセルすべき事象が発生したと見做す方法について説明する。なお、システム構成、ハードウェア構成、ソフトウェア構成は第１の実施形態と同様である。

印刷装置１０１が実行する具体的な制御について図１７のフローチャートを用いて説明する。図１７のフローチャートに示す各動作（ステップ）は、ＣＰＵ２０２がＲＯＭ２０４又はＨＤＤ２０５に記憶された各制御モジュールを実現するためのプログラムをＲＡＭ２０３に読み出し、実行することにより実現される。なお、各動作を引き起こす主体となる制御モジュールを明確に示す場合においては、図３に例示した制御モジュールの名称を主体として各動作を記載するものとする。図１７は、ＣＰＳ１０２に対してジョブ情報の更新を行ったレスポンスに基づきみなしキャンセル判断処理を実行するための制御を抜粋している。印刷装置１０１は、ＣＰＳ１０２からＵｐｄａｔｅ−Ｊｏｂ−Ｓｔａｔｕｓに対するレスポンスを受信することを契機に当該キャンセル判断処理を実行する。

Ｓ１７０１において、ＣＰＵ２０２は、Ｕｐｄａｔｅ−Ｊｏｂ−Ｓｔａｔｕｓのレスポンスに含まれるステータスコードが成功を示しているか否かを判断する。成功を示している場合、キャンセル処理を行うことなく、印刷処理及びジョブ状態の更新処理を継続する。成功を示していない場合（即ちステータスコードがエラーを示している場合）、処理をＳ１７０２に進める。続けてＳ１７０２において、ＣＰＵ２０２は、エラーの理由を示すｄａｔａｉｌｅｄ−ｓｔａｔｕｓ−ｍｅｓｓａｇｅ属性に「ｊｏｂ ｉｓ ｆｉｎｉｓｈｉｅｄ」なる文字列が含まれているかどうかを判断する。当該文字列が含まれている場合、処理をＳ１７０４に進め、含まれていない場合、処理をＳ１７０３に進める。この処理は、ＣＰＳが返すエラーの性質や詳細説明といった事象に基づき、キャンセルすべき事象が発生したと見做す処理である。

Ｓ１７０３において、ＣＰＵ２０２は、ジョブ実行エラーを示す情報をパネル２１１上に表示し、一連のキャンセル判定処理を終了する。一方、Ｓ１７０４において、ＣＰＵ２０２は、ジョブステータスの更新に失敗したジョブの実行をキャンセルし、一連の処理を終了する。

従って、サーバ上におけるジョブの即時キャンセルと、Ｐｕｌｌ方式によるイベントの通知を併用するケースにおいても、状況証拠に基づき迅速なジョブキャンセルを行えるようになる。本実施形態を適用すると、迅速にキャンセルが行えるため、印刷装置１０１とＣＰＳ１０２との間でジョブの実行結果に相違が発生することを抑制することができる。

＜その他の実施形態＞
本発明は、上述の各実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣやＦＰＧＡ）によっても実現可能である。

発明は上記実施形態に制限されるものではなく、発明の精神及び範囲から離脱することなく、様々な変更及び変形が可能である。従って、発明の範囲を公にするために請求項を添付する。

１０１ 印刷装置、１０２ サーバ、２０２ ＣＰＵ、

Claims (10)

1. ユーザから入稿された印刷データを管理するサーバと、前記サーバにイベントの有無を定期的に問合せ、当該問い合わせに対する応答として前記サーバからイベント通知を取得して、前記イベント通知の内容に基づいて前記サーバが管理する印刷ジョブを取得して印刷処理を実行する印刷装置を含む印刷システムであって、
   前記サーバは、前記サーバが管理する印刷ジョブのキャンセルする要求を受信した場合であって、当該キャンセルが要求された印刷ジョブの実行状況を実行中で管理している場合に、当該キャンセルが要求された印刷ジョブの実行状態を一時停止状態に遷移するジョブ管理手段と、
   前記キャンセルが要求された印刷ジョブを取得した印刷装置に対して当該印刷ジョブの印刷をキャンセルすべきことを示す情報を送信する送信手段と、
   前記管理手段が管理するジョブの実行状態が終了状態に遷移したことに従って、前記終了状態に遷移した印刷ジョブの実行結果を含む履歴情報を記憶する第１の記憶手段と、
   を有し、
   前記印刷装置は、
   前記取得した印刷ジョブの印刷処理が開始された後に、前記サーバから当該印刷ジョブの印刷をキャンセルすべきことを示す情報を受信した場合、キャンセルを受け入れるべき状況か否かを印刷ジョブに対する処理の進捗状態に基づいて判定する判定手段と、
   前記判定手段で前記キャンセルを受け入れるべき状況であると判定された場合、前記印刷処理の実行をキャンセル終了し、前記印刷ジョブに対する処理をキャンセルしたことを示す実行結果を前記サーバに対して通知し、前記判定手段で前記キャンセルを受け入れるべき状況でないと判定された場合、前記印刷ジョブの出力が完了したことを示す実行結果を前記サーバに対して通知する制御手段と、
   前記印刷ジョブの実行が終了した場合に、当該印刷ジョブの実行結果を含む履歴情報を記憶する第２の記憶手段と、
   を有し、
   前記サーバのジョブ管理手段は、前記印刷装置から通知された実行結果に基づいて、前記キャンセルが要求された印刷ジョブの実行状態を、正常終了を示す状態、又は、キャンセル終了を示す状態に遷移させる、
   ことを特徴とする印刷システム。
2. サーバにイベントの有無を定期的に問合せ、当該問い合わせに対する応答として前記サーバからイベント通知を取得して、前記イベント通知の内容に基づいて印刷ジョブを取得して実行する印刷装置であって、
   前記取得した印刷ジョブの印刷処理が開始された後に、前記サーバから当該印刷ジョブの印刷をキャンセルすべきことを示す情報を受信した場合、キャンセルを受け入れるべき状況か否かを印刷ジョブに対する処理の進捗状態に基づいて判定する判定手段と、
   前記判定手段によって前記キャンセルを行うべき状況であると判定された場合、前記印刷処理の実行をキャンセル終了して、前記印刷ジョブに対する処理をキャンセルしたことを示す実行結果を前記サーバに対して通知し、前記判定手段によって前記キャンセルを受け入れるべき状況でないと判定された場合、前記印刷ジョブの出力が完了したことを示す実行結果を前記サーバに対して通知する制御手段と、
   前記印刷ジョブの実行が終了した場合に、実行結果を記憶する記憶手段と、
   を有することを特徴とする印刷装置。
3. 前記判定手段は、前記印刷ジョブに対する処理の進捗状態が、印刷が正常完了したことを示す状態である場合、キャンセルを受け入れるべき状況でないと判定することを特徴とする請求項２に記載の印刷装置。
4. 前記制御手段は、前記判定手段によって前記キャンセルを行うべき状況であると判定された場合であっても、前記印刷処理の実行をキャンセル終了が間に合わず前記印刷ジョブの印刷が正常終了した場合、前記印刷ジョブの出力が完了したことを示す実行結果を前記サーバに対して通知することを特徴とする請求項２又は３に記載の印刷装置。
5. 前記サーバから取得した印刷処理の実行中に、ジョブ属性の取得要求を前記イベント通知の取得する間隔より短い間隔で前記サーバに対して要求する要求手段を更に有し、
   前記キャンセルすべきことを示す情報は、当該要求に対する応答として前記サーバから受信されることを特徴とする請求項２乃至４のいずれか１項に記載の印刷装置。
6. 前記印刷装置を利用するユーザを認証する認証手段と、
   前記認証手段で認証に成功したユーザを前記印刷装置にログインさせるログイン制御手段と、
   を有し、
   前記ログイン制御手段で前記印刷装置にユーザがログインした後に、所定のユーザ操作を受け付けたことに従って、前記記憶手段に記憶されたジョブの実行結果を示す画面を表示する表示制御手段を更に有することを特徴とする請求項１乃至３のいずれか１項に記載の印刷装置。
7. 前記画面には、前記ログインしたユーザの印刷ジョブについては、印刷対象のファイルを特定するジョブ名称と、実行結果を対応付けた表示形式で表示され、前記ログインしたユーザとは異なるユーザの印刷ジョブについては、実行結果を示す情報を含むが、前記印刷対象のファイルを特定するジョブ名称を含まない表示形式で表示されることを特徴とする請求項６に記載の印刷装置。
8. 前記表示制御手段が、前記印刷装置にユーザがログインしていない状態で、前記所定のユーザ操作を受け付けた場合、ジョブの実行結果を示す情報を含むが、前記印刷対象のファイルを特定するジョブ名称を含まない表示形式で前記画面を表示することを特徴とする請求項７に記載の印刷装置。
9. サーバにイベントの有無を定期的に問合せ、当該問い合わせに対する応答として前記サーバからイベント通知を取得して、前記イベント通知の内容に基づいて印刷ジョブを取得して実行する印刷装置の制御方法であって、
   前記取得した印刷ジョブの印刷処理が開始された後に、前記サーバから当該印刷ジョブの印刷をキャンセルすべきことを示す情報を受信した場合、キャンセルを受け入れるべき状況か否かを印刷ジョブに対する処理の進捗状態に基づいて判定する判定工程と、
   前記判定工程で前記キャンセルを行うべき状況であると判定された場合、前記印刷処理の実行をキャンセル終了して、前記印刷ジョブに対する処理をキャンセルしたことを示す実行結果を前記サーバに対して通知し、前記判定工程で前記キャンセルを受け入れるべき状況でないと判定された場合、前記印刷ジョブの出力が完了したことを示す実行結果を前記サーバに対して通知する制御工程と、
   前記印刷ジョブの実行が終了した場合に、実行結果を示す履歴情報を印刷装置の記憶領域に格納する格納工程と、
   を有することを特徴とする制御方法。
10. 請求項９に記載の印刷装置の制御方法をコンピュータに実行させるためのプログラム。

Images