JP2016213570A - 処理装置、処理方法、及びプログラム - Google Patents

Abstract

【課題】 端末装置から要求を受信した際に端末装置を応答がない状態で待機させるのを抑制する処理装置、処理方法、及びプログラムを提供する。【解決手段】 ＵＳＢ通信又はネットワーク通信を介して、所定の処理の実行を要求するＨＴＴＰ要求を受信する（Ｓ３０１）。前記受信手段が前記通信手段を介して所定の処理の要求を受信した場合、前記送信手段は、前記実行手段が所定の処理を実行する前にＨＴＴＰ応答の一部を送信する（Ｓ３０２、Ｓ３０３）。そして、受信したＨＴＴＰ要求に応じて所定の処理を実行し、実行手段が正常に実行を開始したか判定する（Ｓ３０４）。正常に実行を開始したと判定した場合、実行手段の処理の実行に基づくデータを含むＨＴＴＰ応答を送信し（Ｓ３０５）、正常に実行を開始できないと判定した場合、前記実行手段の処理の実行に基づくデータを含まないＨＴＴＰ応答を送信する（Ｓ３０６）。【選択図】 図６

Description

本発明は、複数の通信インターフェースを有する処理装置、処理方法、及びプログラムに関するものである。

近年、従来ＴＣＰ／ＩＰネットワークで利用されていた通信プロトコルをＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）通信で利用するための規格が策定されている。ＵＳＢ Ｐｒｉｎｔ Ｉｎｔｅｒｆａｃｅ Ｃｌａｓｓ ＩＰＰ Ｐｒｏｔｏｃｏｌ Ｓｐｅｃｉｆｉｃａｔｉｏｎ（以下、ＩＰＰ ＵＳＢ Ｓｐｅｃｉｆｉｃａｔｉｏｎとする）という規格である。ＩＰＰ ＵＳＢ Ｓｐｅｃｉｆｉｃａｔｉｏｎにより、ＨＴＭＬなどのコンテンツの送受信に用いられるＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）をＵＳＢ通信で利用することができる。また、プリンタとコンピュータの間で印刷データなどのやり取りを行うＩＰＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｉｎｔｉｎｇ Ｐｒｏｔｏｃｏｌ）もＵＳＢ通信で利用することができる。

具体的には、ＩＰＰ ＵＳＢ Ｓｐｅｃｉｆｉｃａｔｉｏｎには、ＵＳＢ Ｐｒｉｎｔ ＣｌａｓｓインターフェースのＢｕｌｋ Ｏｕｔ転送用ＥｎｄＰｏｉｎｔでＩＰＰコマンド要求を転送し、Ｂｕｌｋ Ｉｎ転送用ＥｎｄＰｏｉｎｔでＩＰＰコマンド応答を転送することが規定されている。また、本規格に規定されているのはＩＰＰだけでなく、ＨＴＴＰにおいても同様の方法でコマンド要求の受信とコマンド応答の送信をすることが規定されている。

ＩＰＰ ＵＳＢ Ｓｐｅｃｉｆｉｃａｔｉｏｎにより、基本的なＨＴＴＰによるデータ送受信は、ＴＣＰ／ＩＰネットワークやＵＳＢといった通信インターフェースの違いを意識しなくても同じような通信制御が可能となる。ＰＣやタブレット等の端末装置からのＨＴＴＰ要求を受信したＷｅｂサーバーや通信装置は、その要求に応じた処理を実行後、その処理結果であるＨＴＴＰ応答を端末装置に対して送信する。このときの端末装置と、Ｗｅｂサーバーや通信装置との間の通信は、ＴＣＰ／ＩＰネットワークでもＵＳＢでも同じ制御とすることが可能である。

特許文献１では、スキャンデータを送信する前に、画像処理装置のスキャンデータの分割送信に関する能力情報を応答し、スキャンデータを分割して端末装置に送信する。

特開２００９−４４２３２

しかしながら、特許文献１では、原稿の読み取りがすぐに開始できない場合や、読み取りを開始できたとしてもスキャンデータの最初の分割送信さえ行うことができない場合がある。このような場合、ＴＣＰ／ＩＰネットワーク通信およびＵＳＢ通信において、ＨＴＴＰ要求のデータを全て転送した後、要求元である端末装置は、要求先の画像形成装置の応答を待機する。しかしながら、画像処理装置が一時的にＨＴＴＰ要求を処理できずに長い時間経過しても応答ができない場合端末装置によっては、画像処理装置がエラー状態になったと判断されてしまい、要求を廃棄してしまう。また、端末装置によっては、電源がオフされるまで永続的に待機し、端末装置の処理を占有してしまうことがある。

本発明は上述した課題を解決するためになされたものであり、端末装置から要求を受信した際に端末装置を応答がない状態で待機させるのを抑制する処理装置、処理方法、及びプログラムを提供するものである。

本発明に係る処理装置は、外部装置とＨＴＴＰに従った通信をする通信手段と、前記通信手段を介して、所定の処理の実行を要求するＨＴＴＰ要求を受信する受信手段と、前記受信手段が受信したＨＴＴＰ要求に応じて所定の処理を実行する実行手段と、前記実行手段が正常に実行を開始したか判定する判定手段と、前記受信手段が受信した前記ＨＴＴＰ要求に応じて、前記実行手段の処理結果を応答するＨＴＴＰ応答を前記外部装置に送信する送信手段と、を有し、前記受信手段が前記通信手段を介して所定の処理の要求を受信した場合、前記送信手段は、前記実行手段が所定の処理の実行を完了する前にＨＴＴＰ応答の一部を送信し、前記判定手段が正常に実行を開始したと判定した場合、前記送信手段は前記実行手段の処理の実行に基づくデータを含むＨＴＴＰ応答を送信し、前記判定手段が正常に実行を開始できないと判定した場合、前記送信手段は前記実行手段の処理の実行に基づくデータを含まないＨＴＴＰ応答を送信する。

本発明によれば、端末装置から要求を受信した際に端末装置を応答がない状態で待機させるのを抑制することができる。これにより、例えば、所定の要求を一時的に処理できない場合や処理に失敗する場合、端末装置の負荷を軽減することができ、また、端末装置が処理装置はエラー状態である判定して正常終了しないことを抑制することができる。

実施形態１に係るプリンタのハードウェア構成を示すブロック図である。 実施形態１に係るプリンタのソフトウェア構成を示すブロック図である。 ＨＴＴＰ通信について説明する図である。 実施形態１に係るプリンタの操作表示部に表示する画面図である。 実施形態１に係るプリンタのスキャン実行要求を受信した際のフローチャートである。 実施形態１に係るプリンタのスキャンデータ取得要求を受信した際のフローチャートである。 実施形態２に係るプリンタのスキャンデータ取得要求を受信した際のフローチャートである。 実施形態３に係るプリンタのスキャン実行要求を受信した際のフローチャートである。 実施形態３に係るプリンタのスキャンデータ取得要求を受信した際のフローチャートである。

以下、添付図面を参照して、本発明の実施形態を説明する。なお、以下の実施形態で用いる装置の各構成要素の相対配置や装置形状等は、例示であり、これらに限定されるものではない。

（実施形態１）
図１は、通信システムを示す図である。図１に示すように、本実施形態に係る通信システムは、端末装置１００と、処理装置としてプリンタ２００と、を含む。本実施形態では、処理装置の一例として、画像読取機能及び印刷機能を備えるプリンタを例に挙げて説明を行うが、処理装置はこれに限定されるものではない。処理装置は、印刷機能のみを有するプリンタであってもよいし、さらにファクシミリ機能などの機能を備えているプリンタであってもよいし、複写機、プロッタであってもよい。また、処理装置は、画像読取機能のみを有するスキャナ装置であってもよい。処理装置は、ＵＳＢインターフェースを含む複数の通信インターフェースを有し、端末装置から所定の要求を受信するものであればよく、画像処理装置に限定されるものではない。

図１に示すプリンタは、ネットワーク通信及びＵＳＢ通信に対応したＭＦＰ（Ｍｕｌｔｉ Ｆｕｎｃｔｉｏｎ Ｐｒｉｎｔｅｒ）である。

プリンタ２００は、ＣＰＵ２０１と、ＲＯＭ２０２と、ＲＡＭ２０３と、読取部２０４と、印刷部２０５と、操作表示部２０６と、ネットワークコントローラ２０７と、ＵＳＢデバイスコントローラ２０８と、を有する。これらは、ＣＰＵバス２０９を介してそれぞれ接続されている。

ＣＰＵ２０１は、ＲＯＭ２０２に記憶されている制御のプログラム等に従って、装置全体（ＭＦＰ全体）の制御を行う。

ＲＡＭ２０３は、ＣＰＵ２０１等を動作させるために必要となるメモリ領域であり、ＲＯＭ２０２から読み出されたプログラムを実行する時のワークエリア、データ送受信時のバッファとして用いられる。また、ＲＯＭ２０２は、プリンタを動作させるためのプログラムを内蔵しているとともに、ＨＴＴＰに従って読取部２０４にスキャンを実行させるためのプログラムを格納する。

読取部２０４は、読取センサを有し、原稿台に置かれた紙やフィルム等の原稿を読み取って画像データを生成する。具体的には、読取部２０４は、読取センサがライン状に並べられた、所定の読み取り幅を持つスキャナヘッドを備えており、このスキャナヘッドを走査することにより、画像データ（スキャンデータ）を生成する。

印刷部２０５は、印刷ヘッドと各色のインクタンクを有し、印刷ヘッドを介してインクタンク内のインクを吐出することにより、印刷用紙などのシートに画像を印刷する。

操作表示部２０６は、ユーザが直接プリンタに各種指示を入力するための操作部であり、操作表示部２０６によりユーザはＭＦＰの各種機能の起動や各種設定を行うことができる。操作表示部２０６は、例えば、ＬＥＤ（発光ダイオード）やＬＣＤ（液晶ディスプレイ）などの表示部と、文字入力キー、カーソルキー、決定キー、取り消しキー等の操作キーとを有する。また、操作表示部２０６は、少なくとも一部が、表示部と操作機構が一体となったタッチパネルで構成されてもよい。

ネットワークコントローラ２０７は、有線ＬＡＮや無線ＬＡＮ等のネットワークとの通信制御を行う通信手段である。ネットワークコントローラ２０７は、有線ＬＡＮコネクタと、無線ＬＡＮモジュールと、を有する。ネットワークコントローラ２０７は、Ｅｔｈｅｒｎｅｔ（登録商標）等の有線ＬＡＮ又は無線ＬＡＮを介して他の機器と接続し、通信可能とする。

また、ＵＳＢデバイスコントローラ２０８は、ＵＳＢインターフェースの通信制御を行う通信手段であり、ＵＳＢ通信規格に従って、ＵＳＢ機器との接続および通信制御を行う。ＵＳＢデバイスコントローラ２０８は、ＵＳＢコネクタを有する。ＵＳＢデバイスコントローラ２０８は、ＵＳＢを介して他の機器と接続し、通信可能となる。

上述したように、本実施形態では、端末装置１００からのデータを受信するために複数のインターフェース（有線ＬＡＮコネクタと、無線ＬＡＮモジュールと、ＵＳＢコネクタ）を搭載する。プリンタ２００は、これらのインターフェースを介して、外部装置と接続可能であり、例えば、スキャンの実行要求やスキャンデータ取得要求等の各種要求を端末装置から受信することができる。プリンタ２００は、端末装置１００からのスキャン要求に応じて、読取部２０４によりスキャンを実行することができる。

さらに、本実施形態では、プリンタ２００は、図示しないが、ＮＦＣインターフェースをさらに有し、ＮＦＣ通信を行うことができる。また、プリンタ２００は、Ｂｌｕｅｔｏｏｔｈ（登録商標）インターフェースを有し、Ｂｌｕｅｔｏｏｔｈ（登録商標）通信を行うことができるようにしてもよい。また、プリンタ２００は、Ｂｌｕｅｔｏｏｔｈ（登録商標） Ｌｏｗ Ｅｎｅｒｇｙ（ＢＬＥ）インターフェースを有し、ＢＬＥ通信を行うことができるようにしてもよい。

端末装置１００としては、例えば、ＰＣやタブレット等の情報処理装置が挙げられる。端末装置１００は、プリンタ２００に対して、プリンタ２００が有する各種機能の実行を要求することにより、プリンタ２００にスキャンを実行させることができる。例えば、端末装置１００は、スキャン要求を送信する際には、まず、スキャンの実行要求を送信し、プリンタ２００からのスキャン実行要求に対する応答に応じて、スキャンデータの実行要求を送信する。

図２は、プリンタ２００のＲＯＭ２０２に記憶されたプログラムのモジュール構成を示す図である。プログラムは、プリンタ２００のオペレーションシステム（ＯＳ）４０１、ミドルウェア層４０２、アプリケーション層４０３に分類される。

ミドルウェア層４０２は、ＯＳ４０１とアプリケーション層４０３のモジュール群の間に介在して、通信制御を行う。ミドルウェア層４０２には、ＵＳＢドライバ４０４、ＵＳＢモジュール４０５、ＬＡＮドライバ４０６、ＴＣＰ／ＩＰモジュール４０７が含まれる。ＬＡＮドライバ４０６とＴＣＰ／ＩＰモジュール４０７は、ネットワークコントローラ２０７を制御してＴＣＰ／ＩＰの通信を行う。ＵＳＢドライバ４０４とＵＳＢモジュール４０５は、ＵＳＢデバイスコントローラ２０８を制御してＵＳＢの通信を行う。

アプリケーション層４０３には、ＨＴＴＰモジュール４０８、ＩＰＰモジュール４０９、ＷＳＤモジュール４１０、スキャンモジュール４１１が含まれる。プリンタ２００のＩＰアドレス等を含むネットワークの設定は、操作表示部２０６からだけではなく、端末装置１００からも実行することができる。端末装置１００から実行する場合は、端末装置１００のＷｅｂブラウザを起動してネットワーク経由でプリンタ２００へアクセスすることで実行する。ＨＴＴＰモジュール４０８は、設定用のＷｅｂサーバーとしての管理と、ＷＳＤ（Ｗｅｂ Ｓｅｒｖｉｃｅ ｆｏｒ Ｄｅｖｉｃｅｓ）、ＩＰＰ、その他のＨＴＴＰを利用するプロトコルで規定されたＨＴＴＰ通信の目的で使用する。スキャンモジュール４１１は、ＵＳＢ通信又はネットワーク通信により受信したデータをＨＴＴＰモジュール４０８、ＩＰＰモジュール４０９、又はＷＳＤモジュール４１０で解析する。そして、解析した結果、受信したデータがスキャン要求と判定するとスキャン実行を制御する。さらに、スキャンモジュール４１１は、スキャンの実行により生成されたスキャンデータを、ＨＴＴＰモジュール４０８がアクセスできるようにする。これにより、端末装置１００から受信したスキャンデータの取得要求に対してＨＴＴＰモジュール４０８がスキャンデータを送信できるように制御する。

ここで、図３を用いて、プリンタ２００に搭載されているＨＴＴＰ通信の概略について説明する。

図３（ａ）は、外部装置から送信されるＨＴＴＰ要求の構成を示す図である。図３（ａ）に示すように、ＨＴＴＰ要求は、リクエスト行、ヘッダー部、空白行、ボディ部を含む。リクエスト行は、ＨＴＴＰ要求の処理方法を示すメソッド領域（図中「ＰＯＳＴ」）と、処理を行うＵＲＬを示すリクエストパス領域（図中「／ｒｅｑｕｅｓｔ／ｕｒｌ」）と、ＨＴＴＰバージョン（図中の「ＨＴＴＰ／１．１」）とを含む。ヘッダー部は、送信元を示す情報（図中「Ｈｏｓｔ」）、通信経路を維持するか否かを示す情報（図中「Ｃｏｎｎｅｃｔｉｏｎ」）を有する。また、ヘッダー部は、ボディ部のデータ長を示す情報（図中「Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ」）、ボディ部のデータ形式を示す情報（図中「Ｃｏｎｔｅｎｔ−ｔｙｐｅ」）などのボディ部に関する情報を記載する領域を有する。空白行は、ヘッダー部とボディ部の境界を示す。ボディ部は、ＨＴＴＰ要求の処理内容を指定するために使用され、ＨＴＴＰ要求によってはボディ部が必要なケースと不要なケースがある。

図３（ｂ）は、プリンタ２００から外部装置へ送信されるＨＴＴＰ応答の構成を示す図である。図３（ｂ）に示すように、ＨＴＴＰ応答は、ステータス行、ヘッダー部、空白行、ボディ部を含む。ステータス行は、ＨＴＴＰバージョン（図中の「ＨＴＴＰ／１．１」）、要求受け付け結果を示すステータスコード（図中「２００ ＯＫ」）を含む。ヘッダー部は、ＨＴＴＰ要求と同様であり、ボディ部に関する情報等を含む領域である。ボディ部は、ＨＴＴＰ要求を受け付けた処理結果として応答するデータがある場合にそのデータを格納する領域である。

例えば、ＨＴＴＰを利用して、端末装置１００からスキャンの実行を指示する場合は、次のような手順で行われる。端末装置１００は、原稿のスキャン実行を指示するスキャン実行要求コマンドをボディ部に含めたＨＴＴＰ要求をプリンタ２００に送信する（図３（ａ）参照）。プリンタ２００は、スキャン実行を要求するためのＨＴＴＰ要求を受信すると、そのＨＴＴＰ応答でスキャン要求を受け付けた旨を端末装置１００に送信する（図３（ｂ）参照）。そして、端末装置１００は、プリンタ２００からのＨＴＴＰ応答を受信すると、プリンタ２００が生成したスキャンデータを取得するためのＨＴＴＰ要求（ＧＥＴ要求）を送信する。プリンタ２００は、ＧＥＴ要求を受信すると、スキャンの実行により生成したデータを含むＨＴＴＰ応答を端末装置１００に送信する。端末装置１００は、そのＨＴＴＰ応答でプリンタ２００が生成したデータを取得する。本実施形態では、プリンタ２００がスキャン実行要求コマンドを含むＨＴＴＰ要求を受信すると、スキャンの読取動作を開始する前に、ＨＴＴＰ応答のヘッダー部を、ＨＴＴＰ要求先に送信する（応答する）。そして、スキャンの読取動作の実行後にＨＴＴＰのデータ部を、ＨＴＴＰ要求先に送信する（応答する）。これにより、プリンタ２００と端末装置１００がＵＳＢ通信している際に物理的なＵＳＢ通信の切断があった場合、端末装置１００はプリンタ２００のアプリケーションがエラー状態であると判定することを抑制でき、適切に処理を終了することができる。例えば、プリンタ２００がスキャン読取動作を実行してからＨＴＴＰ応答をする場合、所定時間（例えば、数十秒）経過するまで応答ができない。また、例えば、プリンタ２００が回復処理終了後にＨＴＴＰ応答をする場合、所定時間（例えば、数分）経過するまで応答ができない。このとき、端末装置１００がＨＴＴＰ応答を受け取る前に、その間にＵＳＢがプリンタ２００から抜かれる、プリンタ２００及び端末装置１００のうち少なくともいずれか一方がハードオフする等のように物理的にＵＳＢ通信が切断されてしまうことがある。このように、ＨＴＴＰ要求に対してＨＴＴＰ応答を受け取る前にＵＳＢ通信が切断されると、端末装置１００において、プリンタ２００のアプリケーションがエラー状態であると判断されてしまい、ジョブがキャンセルできないことがある。これに対し、本実施形態では、ＨＴＴＰヘッダー部を含むＨＴＴＰ要求を応答することにより、ＵＳＢ通信の切断があっても、プリンタがエラー状態であると判断されず、ジョブを正常にキャンセルすることができる。

また、スキャン読取動作よりも前に、プリントヘッドの回復動作が実行される場合は、回復動作が実行されるよりも前にＨＴＴＰのヘッダー部を含むＨＴＴＰ要求を応答するようにしてもよい。

本実施形態では、ＵＳＢ通信を介してスキャン実行要求コマンドを含むＨＴＴＰ要求を受信した場合、上述した通り、スキャンの読取動作を開始する前に、ＨＴＴＰ応答のヘッダー部を、ＨＴＴＰ要求先に送信する（応答する）。一方、ネットワークを介してスキャン実行要求コマンドを含むＨＴＴＰ要求を受信した場合、スキャンの読取動作を実行した後に、ヘッダー部及びボディ部を含むＨＴＴＰ応答を、ＨＴＴＰ要求先に送信する（応答する）。

なお、図３では、プリンタ２００に搭載されているＨＴＴＰ通信の概略について説明したが、本実施形態は、ＨＴＴＰに従った通信であればよく、ＩＰＰを用いた通信であってもよいし、ＷＳＤプロトコルを用いた通信であっても同様である。

図４は、図１で示した本実施形態に係るＭＦＰの操作表示部２０６にスキャン実行時に表示される表示画面を模式的に示した図である。図４（ａ）は、プリンタ２００が電源オンし、印刷やスキャン等の動作をしていない状態（アイドル状態）を示すホーム画面である。ホーム画面では、キー操作やタッチパネル操作により、コピー機能、スキャン機能、インターネット通信を利用したクラウド機能の各機能のメニュー表示、各種設定、機能の実行が可能である。図４（ｂ）は、プリンタ２００が各種機能を実行できない場合に表示する画面である。各種機能が実行できない場合としては、ＵＳＢやネットワーク接続された端末装置からスキャンの実行要求があった場合に読取処理をすぐに実行できない場合が挙げられる。読取処理を一時的に実行できない場合としては、特定の処理の実行中である場合が挙げられる。具体的には、読み取りセンサの補正処理中のようにスキャン処理の準備中である場合が挙げられる。また、印刷ヘッドの乾燥を防ぐためのキャッピング処理、インク吸引処理等の回復処理中や、印刷処理中のようにプリンタ２００において振動が発生する処理中である場合が挙げられる。図４（ｃ）は、プリンタ２００がスキャン実行中に表示する表示画面である。スキャン終了後は再び図４（ａ）の画面に戻る。

図５は、本発明の実施形態に係るプリンタ２００のスキャンの実行要求を受信した際の処理の流れを示したフローチャートである。このフローチャートは、ＣＰＵ２０１が、ＲＯＭ２０２に格納されている制御プログラムをＲＡＭ２０３にロードし、それを実行することにより行われる。

まず、ネットワーク通信又はＵＳＢ通信を介して、プリンタ２００に接続されている端末装置からスキャンの実行要求を受信する（Ｓ５０１）。スキャンの実行要求には、原稿の読み取りサイズや解像度等の情報が含まれている。プリンタは、スキャンの実行要求の内容に従って原稿台等に置かれた用紙や写真のスキャンを実行する（Ｓ５０２）。スキャン実行を開始したらＨＴＴＰ応答でステータスコードを送信し（Ｓ５０３）、ＨＴＴＰ応答でヘッダー部を送信し（Ｓ５０４）、ＨＴＴＰ応答でボディ部（Ｓ５０５）を送信する。このように、ＨＴＴＰ応答で、ステータス部、ヘッダー部、ボディ部を順次送信する。

プリンタ２００がスキャン要求を受け付けることができる場合、ＨＴＴＰ応答のステータスコードとして、例えば、「２００ ＯＫ」を送信する。なお、スキャン要求を受け付けることができる場合に送信するステータスコードは、これに限定されるものではなく、「２０１ Ｃｒｅａｔｅｄ」でもよく、正常に要求を受け付けたことを示す２００番台の応答のいずれであってもよい。一方、プリンタ２００がスキャン要求を受け付けることができない場合は、ステータスコードで「５００ Ｉｎｔｅｒｎａｌ Ｓｅｒｖｅｒ Ｅｒｒｏｒ」を応答する。なお、スキャン要求を受け付けることができない場合に送信するステータスコードはこれに限定されるものではない。

また、ボディ部としては、スキャン実行を開始したことを示す情報を含んでいればよく、例えば、ジョブＩＤの情報、スキャン実行で生成するスキャンデータのＵＲＬなどで示す所在等を含めるようにしてもよい。

操作表示部２０６にはスキャン実行する前には図４（ａ）の画面が表示され、スキャン要求を受け付けた場合は、図４（ｂ）の画面が表示され、スキャン実行中は図４（ｃ）の画面が表示される。

図６は、本発明の実施形態に係るプリンタ２００のスキャンデータの取得要求を受信した際の処理の流れを示したフローチャートである。また、図６に示すフローは前述の図５で示したフローを実施した後のフローであり、端末装置は、本フローの直前にプリンタからスキャン実行を開始した旨を受信している状態である。このフローチャートは、ＣＰＵ２０１が、ＲＯＭ２０２に格納されている制御プログラムをＲＡＭ２０３にロードし、それを実行することにより行われる。

まず、端末装置から処理の実行結果の取得要求を受信する（Ｓ３０１）。ここでは、端末装置からスキャンデータ取得要求を受信する。スキャンデータの取得要求には、端末装置が取得したいスキャンデータを示す情報が含まれており、ＨＴＴＰ要求のリクエスト行には、取得要求を示すＧＥＴ及び取得するスキャンデータのＵＲＬが含まれている。このＵＲＬは前述のスキャン要求の応答から得た情報となる。

次に、ＨＴＴＰ応答のステータスコードとして「２００ ＯＫ」を送信し（Ｓ３０２）、ＨＴＴＰ応答のヘッダー部を送信する（Ｓ３０３）。すなわち、正常にスキャンが開始できたか判定する前に、ＨＴＴＰ応答のステータスコード及びＨＴＴＰ応答のヘッダー部を送信する。端末装置１００は、ＨＴＴＰ応答のステータスコード及びヘッダー部の受信に基づいて、「スキャンデータの受信中」等のメッセージの表示と共に、データの受信の進捗状況を示すプログレスバーを表示する。

その後、正常にスキャンが開始できたか判定し（Ｓ３０４）、正常にスキャンが開始できたと判定された場合、ＨＴＴＰボディ部としてスキャンデータを送信して（Ｓ３０５）、処理を終了する。端末装置１００は、ＨＴＴＰ応答のボディ部の受信に基づいて、プログレスバーの進捗状況が進む。正常にスキャンが開始できなったと判定された場合、スキャンデータを含まないＨＴＴＰボディ部を送信して（Ｓ３０６）処理を終了する。このとき、端末装置１００は、ＨＴＴＰ応答のボディ部の受信に基づいて、プログレスバーの進捗が進むことなく、「スキャンデータの受信中」等のメッセージ及びプログレスバーの表示を終了する。正常にスキャンが開始できなったと判定された場合、ＨＴＴＰボディ部は、スキャンデータがないことを示す情報を含むものとしてもよい。

プリンタにおいてスキャンを実行する場合、電源オン直後や印刷直後に、例えば、読み取りセンサの補正処理のようにスキャンの準備処理動作や、印刷ヘッドに必要なインク吸引処理等の回復動作が行われることにより、スキャンを実行できない期間が存在する。プリンタ２００がスキャンの開始を待機している間に、端末装置に対して何も応答をしないと、端末装置１００はスキャンデータの取得要求を送信したにも関わらずプリンタが反応を示さないため、プリンタのエラーと判断されることがある。その際、端末装置１００は、ＵＳＢ通信の場合、該スキャン要求やスキャンデータ取得要求を、プリンタに送信しないまま破棄してしまう場合がある。また、応答が返ってくるまで端末装置１００の処理を占有し続ける（端末装置１００が待機し続ける）場合もある。従って、本実施形態では、スキャンデータが正常に開始できるか判定する前に、ＨＴＴＰ応答をヘッダー部まで送信する。これにより、プリンタがスキャンデータの取得要求を受け付けたことを端末装置に認識させることができ、スキャンデータの取得要求の破棄やスキャンデータ取得要求の応答待機による端末装置の処理の占有を抑制することができる。また、スキャンが正常に開始できなかったとしても、ＨＴＴＰ応答のボディ部でスキャンデータが何もないという情報を送信することにより、端末装置１００はプリンタ２００が要因でスキャンがキャンセルされたと判断することができる。したがって、スキャンデータが開始できるまで時間がかかる場合や、スキャンデータが正常に開始できない場合でも、端末装置がアプリケーションにエラーが発生したと判定することがない。また、通信が切断された場合、アプリケーションがエラーしたと判定して終了せずに、ジョブのエラー等のように正常に処理を終了させることができる。

（実施形態２）
実施形態１においては、スキャンデータ取得要求を受信した際にＵＳＢ通信及びネットワーク通信のいずれの場合も、スキャンを実行する前に、ＨＴＴＰ応答のステータスコード及びＨＴＴＰ応答のヘッダー部を送信した。これに対し、本実施形態では、スキャンデータ取得要求を受信した際のＨＴＴＰ応答の送信制御を通信インターフェースに応じて切り替える。また、実施形態１と同一のものには同一の符号を付す。具体的には、プリンタのハードウェア構成、プリンタのソフトウェア構成、操作表示部の表示画面、プリンタがスキャン要求を受信した際の処理の流れは同一であるため、説明を省略する。

図７は、本発明の実施形態に係るプリンタ２００のスキャンデータの取得要求を受信した際の処理の流れを示したフローチャートである。また、図６に示すフローは前述の図５で示したフローを実施した後のフローであり、端末装置は、本フローの直前にプリンタからスキャン実行を開始した旨を受信している状態である。このフローチャートは、ＣＰＵ２０１が、ＲＯＭ２０２に格納されている制御プログラムをＲＡＭ２０３にロードし、それを実行することにより行われる。

まず、端末装置からスキャンデータ取得要求を受信する（Ｓ６０１）。スキャンデータの取得要求には、端末装置が取得したいスキャンデータを示す情報が含まれており、ＨＴＴＰ要求のリクエスト行には、取得要求を示すＧＥＴ及び取得するスキャンデータのＵＲＬが含まれている。このＵＲＬは前述のスキャン要求の応答から得た情報となる。

次に、プリンタは、スキャンデータ取得要求がＵＳＢ通信で受信したのかを判定する（Ｓ６０２）。

Ｓ６０２でＵＳＢ通信ではない、すなわち、ネットワーク通信で受信したと判定された場合、正常にスキャンを開始できたかを判定する（Ｓ６０３）。

正常にスキャンが開始できたと判定された場合、ＨＴＴＰ応答のステータスコードとして「２００ ＯＫ」を送信し（Ｓ６０４）、続いてＨＴＴＰ応答のヘッダー部を送信し（Ｓ６０５）、ＨＴＴＰ応答のボディ部としてスキャンデータを送信する（Ｓ６０６）。端末装置１００は、ＨＴＴＰ応答のステータスコード及びヘッダー部の受信に基づいて、「スキャンデータの受信中」等のメッセージの表示と共に、データの受信の進捗状況を示すプログレスバーを表示する。そして、スキャンデータの受信の進捗状況に応じてプログレスバーの進捗状況が進む。

Ｓ６０３において、正常にスキャンが開始できなかったと判定された場合はスキャンデータが存在しないのでＨＴＴＰ応答のステータスコードとして「４０４ Ｎｏｔ Ｆｏｕｎｄ」を送信し（Ｓ６０７）、ＨＴＴＰ応答のヘッダー部を送信する（Ｓ６０８）。このとき、端末装置１００は、ＨＴＴＰ応答のステータスコード及びヘッダー部の受信に基づいて、スキャンが開始できないことをユーザに通知する。本実施形態では、「スキャンが開始できませんでした」の表示を表示部に行う。なお、これに限定されず、音声や印刷等によりユーザに通知するようにしてもよい。そして、スキャンが正常に開始できなかったので、ＨＴＴＰ応答のボディ部としてデータなしであることを示す情報を送信する（Ｓ６０９）。

Ｓ６０２でＵＳＢ通信で受信したと判定された場合、正常にスキャンが開始できたか判定する前に、ＨＴＴＰ応答のステータスコードとして「２００ ＯＫ」を送信し（Ｓ６１０）、ＨＴＴＰ応答のヘッダー部を送信する（Ｓ６１１）。端末装置１００は、ＨＴＴＰ応答のステータスコード及びヘッダー部の受信に基づいて、「スキャンデータの受信中」等のメッセージの表示と共に、データの受信の進捗状況を示すプログレスバーを表示する。
その後、正常にスキャンが開始できたか判定し（Ｓ６１２）、正常にスキャンが開始できたと判定された場合、ＨＴＴＰボディ部としてスキャンデータを送信する（Ｓ６１３）。端末装置１００は、ＨＴＴＰ応答のボディ部の受信に基づいて、プログレスバーの進捗状況が進む。正常にスキャンが開始できなったと判定された場合、ＨＴＴＰボディ部としてデータなしであることを示す情報を送信する（Ｓ６１４）。このとき、端末装置１００は、ＨＴＴＰ応答のボディ部の受信に基づいて、プログレスバーの進捗が進むことなく、「スキャンデータの受信中」等のメッセージ及びプログレスバーの表示を終了する。 本実施形態では、実施形態１と同様に、スキャンデータが正常に送信できる状況であるか判定する前に、ＨＴＴＰ応答をヘッダー部まで送信する。これにより、プリンタがスキャンデータ取得要求を受け付けたと端末装置に認識させることができ、スキャンデータ取得要求の破棄やスキャンデータ取得要求の応答待機による端末装置の処理の占有を抑制することができる。また、スキャンが正常に開始できなかったとしても、ＨＴＴＰ応答のボディ部でスキャンデータが何もないという情報を送信することにより、端末装置はプリンタが要因でスキャンがキャンセルされたと判断可能となる。したがって、スキャンデータが開始できるまで時間がかかる場合も、スキャンデータが正常に開始できない場合でも正常な状態を保ったまま処理を終了させることができる。

一方、ネットワーク通信では、ＨＴＴＰ層において、プリンタからの応答がなかったとしても、端末装置はＴＣＰ／ＩＰ層のＦＩＮパケットを送信することでプリンタに要求を破棄したことを伝えることが可能である。そのため、端末装置とプリンタ間で通信経路と処理を占有させないことが可能である。

上述したように、本実施形態では、スキャンデータの取得要求を受信した際のＨＴＴＰ応答の送信制御を通信インターフェースに応じて切り替える。具体的には、本ネットワーク通信においては正常にスキャンが実行できたと判定してからＨＴＴＰ応答を送信する。これにより、例えば、ネットワーク通信の場合は、プリンタに回復動作やキャッピング動作等のエラーが発生した場合に、エラー発生を適切に端末装置に送信することができる。

（実施形態３）
実施形態２においては、スキャンデータ取得要求受信時のＨＴＴＰ応答の送信制御を通信インターフェースに応じて切り替えるようにした。これに対し、本実施形態では、スキャン実行要求を受信したタイミングではなく、スキャンデータ取得要求を受信したタイミングで、プリンタにスキャンを実行させる。なお、実施形態１と重複する説明は省略する。また、実施形態１と同一のものには同一の符号を付す。具体的には、プリンタのハードウェア構成、プリンタのソフトウェア構成、操作表示部の表示画面は同一であるため、説明を省略する。

図８は、本実施形形態に係るプリンタ２００のスキャンの実行要求を受信した際の処理の流れを示したフローチャートである。このフローチャートは、ＣＰＵ２０１が、ＲＯＭ２０２に格納されている制御プログラムをＲＡＭ２０３にロードし、それを実行することにより行われる。

まず、ネットワーク通信又はＵＳＢ通信を介して、プリンタ２００に接続されている端末装置からスキャンの実行要求を受信する（Ｓ７０１）。スキャンの実行要求には読み取りサイズや解像度等の情報が含まれている。

プリンタは、スキャンの実行要求を受け付ける（Ｓ７０２）。ただし、このとき、スキャンの実行を開始しない。次に、ＨＴＴＰ応答であるステータスコードを送信し（Ｓ７０３）、ＨＴＴＰ応答のヘッダー部を送信し（Ｓ７０４）、ＨＴＴＰ応答のボディ部を送信する（Ｓ７０５）。このように、ＨＴＴＰ応答で、ステータス部、ヘッダー部、ボディ部を順次送信する。ＨＴＴＰ応答のステータスコードには、実施形態１と同様、正常に要求を受け付けたことを示す２００番台の応答のいずれであってもよい。ＨＴＴＰ応答のボディ部としては、スキャン実行を開始したことを示す情報ではなく、スキャン受け付けを示すジョブ情報や後のスキャン実行で生成するスキャンデータのＵＲＬなどの所在等を予め含めるものとする。

図９は、本発明の実施形態に係るプリンタのスキャンデータ取得要求を受信した際の処理の流れを示したフローチャートである。また、図９に示すフローは、図８で示したフローを実施した後のフローであり、端末装置は、本フローの直前にプリンタからスキャン要求を受け付けた旨を受信している状態である。このフローチャートは、ＣＰＵ２０１が、ＲＯＭ２０２に格納されている制御プログラムをＲＡＭ２０３にロードし、それを実行することにより行われる。

まず、端末装置からスキャンデータの取得要求（ＨＴＴＰ要求）を受信する（Ｓ８０１）。次に、プリンタは、スキャンデータの取得要求がＵＳＢ通信で受信したかを判定する（Ｓ８０２）。ＵＳＢ通信で受信してない、すなわち、ネットワーク通信で受信したと判定した場合は、すぐにスキャンを実行できるか判定をする（Ｓ８０３）。すぐにスキャン実行できると判定した場合はスキャンを実行する（Ｓ８０４）。一方、すぐにスキャンを実行できないと判定した場合は、スキャンの実行ができない要因が解消されるまで、スキャン実行を待ち（Ｓ８０５）、スキャンの実行ができない要因が解消されたと判定してからスキャンを実行する（Ｓ８０４）。

次に、Ｓ８０４のスキャンを実行した結果、正常にスキャンが開始できたか判定する（Ｓ８０６）。Ｓ８０６で正常にスキャンが開始できたと判定された場合はＨＴＴＰ応答のステータスコードとして「２００ ＯＫ」を送信し（Ｓ８０７）、ＨＴＴＰ応答のヘッダー部を送信する（Ｓ８０８）。そして、ＨＴＴＰ応答のボディ部としてスキャンデータを送信する（Ｓ８０９）。Ｓ８０６で正常にスキャンが開始できなかったと判定された場合はステータスコードとして「４０４ Ｎｏｔ Ｆｏｕｎｄ」を送信し（Ｓ８１０）、ＨＴＴＰ応答のヘッダー部を送信する（Ｓ８１１）。そして、ＨＴＴＰ応答のボディ部としてデータなしであることを示す情報を送信する（Ｓ８１２）。

Ｓ８０２でＵＳＢ通信で受信したと判定された場合、スキャンを実行する前にＨＴＴＰ応答のステータスコードとして「２００ ＯＫ」を送信し（Ｓ８１３）、ＨＴＴＰ応答のヘッダー部を送信する（Ｓ８１４）。その後、すぐにスキャンを実行できるか判定する（Ｓ８１５）。すぐにスキャンを実行できると判定した場合はスキャンを実行する（Ｓ８１６）。スキャンが一時的に実行できない場合は、スキャンの実行ができない要因が解消されるまでスキャン実行を待ち（Ｓ８１７）、スキャンの実行ができない要因が解消されたと判定してからスキャンを実行する（Ｓ８１６）。

次に、Ｓ８１６のスキャンを実行した結果、正常にスキャンが開始できたか判定する（Ｓ８１８）、正常にスキャンが開始できたと判定された場合、ＨＴＴＰ応答のボディ部としてスキャンデータを送信する（Ｓ８１９）。正常にスキャンが開始できなったと判定された場合、ＨＴＴＰ応答のボディ部としてデータなしであることを示す情報を送信する（Ｓ８２０）。本実施形態では、スキャン実行要求を受信した時点では、スキャンを受け付けたのみで実際にはスキャンは実行されない。ただし、プリンタの内部ではスキャン実行は予約された状態になっており、スキャン実行要求を受け付けた時点で他の端末装置からの印刷やスキャンは受け付けない状態とする。このような状態にすることにより、スキャンデータの取得要求を受信した際に、スキャンデータが送信されることを保障することができる。

さらに、本実施形態では、スキャンの実行のタイミングを遅らせることにより、端末装置からのスキャンデータの取得要求の送信が遅れた場合に、スキャナヘッドによるスキャンが止まってしまうのを抑制することができる。端末装置からのスキャンデータの取得要求の送信が遅れてスキャナヘッドによるスキャンが止まってしまう例としては、ＲＡＭ２０３のサイズが小さく、一回のスキャン実行で生成されるスキャンデータ全てを格納できないようなプリンタが挙げられる。このようなプリンタは、スキャン実行で次々に生成されるスキャンデータの断片をＲＡＭ２０３に格納する処理と同時に端末装置からのスキャンデータ取得要求でＲＡＭ２０３から格納されたスキャンデータの断片を順次端末装置に送信する。しかしながら、端末装置からのスキャンデータ取得要求が遅れると一時的にＲＡＭ２０３に空きが無くなってしまい、スキャナヘッドによる読み取りが中断されてしまうことがある。中断した後は、スキャンデータ取得要求の受信で徐々にＲＡＭ２０３に空きができ始めて、再び読み取りが開始できる。しかしながら、読み取りが一時的に停止してしまうと、生成されたスキャンデータは、一定の速度で読み取りを行った場合のスキャンデータと比較して、スキャンデータに基づく画像に画像ずれが生じる等のように得られる画質が低下してしまう。これに対し、本実施形態では、上述した通り、スキャナヘッドによるスキャンが止まってしまうのを抑制することができる。

上述したように、本実施形態では、スキャンデータの取得要求を受信した際のＨＴＴＰ応答の送信制御を通信インターフェースに応じて切り替える。具体的には、上述したように、ＵＳＢ通信でスキャン取得要求を受信した場合、スキャンを実行する前に、ＨＴＴＰ応答のヘッダー部まで送信する。これにより、端末装置とプリンタとの間でアプリケーションのエラーとして終了するのを抑制することができる。

（他の実施形態）
本発明は上述した実施形態に限定されるものではない。例えば、上述した実施形態では、スキャンの実行を開始する前にＨＴＴＰ応答の一部としてヘッダー部を送信するものとしたが、これに限定されず、スキャンの実行の開始の有無に関わらず、ＨＴＴＰ応答のヘッダー部を送信するものであればよい。すなわち、正常にスキャン等の処理を開始後にＨＴＴＰ応答のヘッダー部を送信してもよく、スキャンの実行の完了前に送信するものであればよい。

また、例えば、プリンタは、ＨＴＴＰを用いるＢｌｕｅｔｏｏｔｈ（登録商標）通信を介してスキャンの実行が指示される場合も同様に、スキャンの実行を開始する前に、ＨＴＴＰ応答のヘッダー部を返すようにすればよい。

また、上述した実施形態では、処理の実行要求として、スキャンの実行要求を例に挙げて説明したが、これに限定されるものではない。端末装置から受信する他の処理の実行要求としては、例えば、印刷処理の実行要求が挙げられる。

上述した実施形態は、以下の処理を実行することによっても実現される。すなわち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（ＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。また、プログラムは、１つのコンピュータで実行させても、複数のコンピュータを連動させて実行させるようにしてもよい。また、上記した処理の全てをソフトウェアで実現する必要はなく、処理の一部または全部をＡＳＩＣ等のハードウェアで実現するようにしてもよい。また、ＣＰＵも１つのＣＰＵで全ての処理を行うものに限らず、複数のＣＰＵが適宜連携をしながら処理を行うものとしてもよい。

２００ プリンタ
２０１ ＣＰＵ
２０２ ＲＯＭ
２０３ ＲＡＭ
２０４ 読取部
２０５ 印刷部
２０６ 操作表示部
２０７ ネットワークコントローラ
２０８ ＵＳＢデバイスコントローラ
２０９ ＣＰＵバス
４０１ ＯＳ
４０２ ミドルウェア
４０３ アプリケーション
４０４ ＵＳＢドライバ
４０５ ＵＳＢモジュール
４０６ ＬＡＮドライバ
４０７ ＴＣＰ／ＩＰモジュール
４０８ ＨＴＴＰモジュール
４０９ ＩＰＰモジュール
４１０ ＷＳＤモジュール
４１１ スキャンモジュール

Claims (10)

1. 外部装置とＨＴＴＰに従った通信をする通信手段と、
   前記通信手段を介して、所定の処理の実行を要求するＨＴＴＰ要求を受信する受信手段と、
   前記受信手段が受信したＨＴＴＰ要求に応じて所定の処理を実行する実行手段と、
   前記実行手段が正常に実行を開始したか判定する判定手段と、
   前記受信手段が受信した前記ＨＴＴＰ要求に応じて、前記実行手段の処理結果を応答するＨＴＴＰ応答を前記外部装置に送信する送信手段と、
   を有し、
   前記受信手段が前記通信手段を介して所定の処理の要求を受信した場合、前記送信手段は、前記実行手段が所定の処理の実行を完了する前にＨＴＴＰ応答の一部を送信し、
   前記判定手段が正常に実行を開始したと判定した場合、前記送信手段は前記実行手段の処理の実行に基づくデータを含むＨＴＴＰ応答を送信し、前記判定手段が正常に実行を開始できないと判定した場合、前記送信手段は前記実行手段の処理の実行に基づくデータを含まないＨＴＴＰ応答を送信することを特徴とする処理装置。
2. 前記受信手段が前記通信手段を介して所定の処理の要求を受信した場合、前記送信手段は、前記実行手段が所定の処理の実行を開始する前にＨＴＴＰ応答の一部を送信することを特徴とする請求項１に記載の処理装置。
3. 前記通信手段は、ＨＴＴＰに従った通信をする第一の通信手段と、ＨＴＴＰに従った通信をする第二の通信手段と、を有し、
   前記受信手段は、前記第一の通信手段又は前記第二の通信手段を介して、所定の処理の要求を受信し、
   前記受信手段が前記第一の通信手段を介して所定の処理の要求を受信した場合、前記送信手段は、前記判定手段が正常に実行を開始したと判定した場合にＨＴＴＰ応答を送信し、
   前記受信手段が前記第二の通信手段を介して所定の処理の要求を受信した場合、前記送信手段は、前記実行手段による所定の処理を実行する前にＨＴＴＰ応答の一部を送信することを特徴とする請求項２に記載の処理装置。
4. 前記受信手段は、前記所定の処理の要求として、所定の処理の実行要求及び前記所定の処理の実行結果の取得要求をそれぞれ受信し、
   前記送信手段は、前記所定の処理の実行要求に応じて第一のＨＴＴＰ応答を送信し、前記所定の処理の実行結果の取得要求に応じて第二のＨＴＴＰ応答を送信し、前記受信手段が前記第二の通信手段を介して前記所定の処理の実行結果の取得要求を受信した場合、前記実行手段が所定の処理を実行する前に前記第二のＨＴＴＰ応答の一部を送信することを特徴とする請求項３に記載の処理装置。
5. 前記第一の通信手段はネットワーク通信手段であり、前記第二の通信手段はＵＳＢ通信手段であることを特徴とする請求項１〜４のいずれか１項に記載の処理装置。
6. 原稿を読み取る読取部をさらに有し、
   前記所定の処理の要求は、スキャン要求を含み、
   前記所定の処理の要求がスキャン要求である場合、前記実行手段の処理の実行に基づくデータは、スキャンデータを含むことを特徴とする請求項１〜５のいずれか１項に記載の処理装置。
7. 前記ＨＴＴＰに従った通信は、ＷＳＤプロトコルを用いた通信であることを特徴とする請求項１〜６のいずれか１項に記載の処理装置。
8. 前記ＨＴＴＰに従った通信は、ＩＰＰを用いた通信であることを特徴とする請求項１〜７のいずれか１項に記載の処理装置。
9. 通信手段を介して、外部装置から所定の処理の実行を要求するＨＴＴＰ要求を受信する受信工程と、
   前記受信工程において前記通信手段を介して所定の処理の要求を受信した場合、前記所定の処理の実行を完了する前にＨＴＴＰ応答の一部を前記外部装置に送信する送信工程と、
   前記受信工程において受信したＨＴＴＰ要求に応じて所定の処理を実行する実行工程と、
   前記実行工程が正常に実行を開始したか判定する判定工程と、
   を有し、
   前記判定工程において正常に実行を開始したと判定した場合、前記所定の処理の実行に基づくデータを含むＨＴＴＰ応答を送信し、前記判定手段が正常に実行を開始できないと判定した場合、前記所定の処理の実行に基づくデータを含まないＨＴＴＰ応答を送信することを特徴とする処理方法。
10. 請求項１〜８に記載の処理装置の各手段としてコンピュータを機能させるプログラム。

Images