JP6960302B2 - 通信装置、通信方法、及びプログラム - Google Patents

Description

本発明は通信装置が通信相手の装置との通信を管理する技術に関し、特に、例えば、互いがＵＳＢ接続されＨＴＴＰ通信を行う通信装置、通信方法、及びプログラムに関する。

情報処理装置とＷｅｂサーバ、またはＷｅｂサーバ機能を搭載した周辺装置との間で通信を行う際の方式として、Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（以降、ＨＴＴＰ）が知られている。一般にＨＴＴＰはネットワーク回線を介した通信時に利用されることが多いプロトコルであるが、Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ（以降、ＵＳＢ）を介した通信にも利用することが可能である。その代表的な例として、ＨＴＴＰを拡張したＩｎｔｅｒｎｅｔ Ｐｒｉｎｔｉｎｇ Ｐｒｏｔｏｃｏｌ（以降、ＩＰＰ）を、ＵＳＢを介して送受信を行うＩＰＰ ｏｖｅｒ ＵＳＢという規格が知られている。また、このＩＰＰ ｏｖｅｒ ＵＳＢを利用した情報処理装置と画像処理装置との間の通信において、情報処理装置上で動作する複数のソフトウェアと画像処理装置との間の通信を管理する技術も知られている（特許文献１）。

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

しかしながら以上説明したネットワーク環境では、情報処理装置（ＵＳＢホスト、ＨＴＴＰクライアント）がレスポンス情報を取得しないまま処理を終了すると、画像処理装置（ＵＳＢデバイス、ＨＴＴＰサーバ）はそのレスポンス情報を保持したままとなる。その結果、次に情報処理装置からリクエストを受けた際、不適当なレスポンス情報を返却してしまう可能性がある。

また、決められた順番で情報を送受することによって成立する処理がある場合、その途中で情報処理装置が通信を行わずに処理を終えてしまうと、画像処理装置が他の処理を実行できなくなってしまう可能性がある。

なお、ＵＳＢ通信にはＴＣＰのセションのような概念がないことから、ＵＳＢデバイス側で処理を打ち切る判断ができない。

本発明は上記従来例に鑑みてなされたもので、通信相手となる装置からの通信が途中終了した場合でもその装置の処理を終了させることが可能な通信装置、通信方法、及びプログラムを提供することを目的とする。

上記目的を達成するために本発明の通信装置は次のような構成からなる。

即ち、通信相手の装置との通信を確立して通信を行う通信装置であって、前記通信相手の装置に所定の処理を実行させる場合、前記通信相手の装置との通信を一意に特定するための第１の情報を生成し、該第１の情報を前記通信相手の装置に送信する生成手段と、前記通信相手の装置からの応答を受信し、前記応答に含まれる第２の情報と前記第１の情報が一致するかどうかを判断する判断手段と、前記第１の情報と前記第２の情報とが一致しない場合には、前記所定の処理を実行できる状態で前記通信相手の装置を動作させるための指示を前記通信相手の装置に送信する指示手段とを有することを特徴とする。

また本発明を別の側面から見れば、コンピュータに上記構成の通信装置の各手段として機能させるためのプログラムを備える。

さらに本発明を別の側面から見れば、通信相手の装置との通信を確立して通信を行う通信方法であって、前記通信相手の装置に所定の処理を実行させる場合、前記通信相手の装置との通信を一意に特定するための第１の情報を生成し、該第１の情報を前記通信相手の装置に送信する生成工程と、前記通信相手の装置からの応答を受信し、前記応答に含まれる第２の情報と前記第１の情報が一致するかどうかを判断する判断工程と、前記第１の情報と前記第２の情報とが一致しない場合には、前記所定の処理を実行できる状態で前記通信相手の装置を動作させるための指示を前記通信相手の装置に送信する指示工程とを有することを特徴とする通信方法を備える。

本発明によれば、通信が途中終了した場合でも、適切な処理を通信相手の装置に実行させることが可能となるという効果がある。

印刷システムを示すブロック図である。 管理アプリケーションと印刷アプリケーションの概要を示す図である。 情報処理装置と画像処理装置の間のＨＴＴＰ通信を示す概念図である。 情報処理装置と画像処理装置との間で送受信されるＨＴＴＰパケットのシーケンスを示す図である。 情報処理装置からのリクエストに応じて画像処理装置がエンドポイントに書き出した情報が取得されずに残る一例を示す図である。 ＨＴＴＰ通信モジュールのデータ送受信処理を示すフローチャートである。 ＨＴＴＰパケット送受信のシーケンスの例を示す図である。 管理アプリケーションの処理を示すフローチャートである。 ＨＴＴＰパケット送受信のシーケンスの例を示す図である。 所有権解放処理を示すフローチャートである。 アプリケーションの処理を示すフローチャートである。

以下添付図面を参照して本発明の好適な実施例について、さらに具体的かつ詳細に説明する。なお、既に説明した部分には同一符号を付し重複説明を省略する。

なお、この明細書において、「記録」（「プリント」「印刷」という場合もある）とは、文字、図形等有意の情報を形成する場合のみならず、有意無意を問わない。また人間が視覚で知覚し得るように顕在化したものであるか否かを問わず、広く記録媒体上に画像、模様、パターン等を形成する、または媒体の加工を行う場合も表すものとする。

また、「記録媒体」（「シート」という場合もある）とは、一般的な記録装置で用いられる紙のみならず、広く、布、プラスチック・フィルム、金属板、ガラス、セラミックス、木材、皮革等、インクを受容可能なものも表すものとする。

さらに、「インク」（「液体」と言う場合もある）とは、上記「記録（プリント）」の定義と同様広く解釈されるべきものである。従って、記録媒体上に付与されることによって、画像、模様、パターン等の形成または記録媒体の加工、或いはインクの処理（例えば記録媒体に付与されるインク中の色剤の凝固または不溶化）に供され得る液体を表すものとする。

＜印刷システムの概要（図１〜図３）＞
図１は情報処理装置と画像処理装置により構成される印刷システムの全体構成の概要を示すブロック図である。

図１に示されるように、この印刷システムは、情報処理装置１１０とこれにＵＳＢ接続された画像処理装置１２０とから構成される。情報処理装置１１０は、データ入力や動作指示に使用されるポインティングデバイスなどの入力装置１１７と、データ表示や状態の通知に使用されるＬＣＤディスプレイなどの出力装置１１８と接続している。具体的には、情報処理装置１１０は、入力インタフェース（Ｉ／Ｆ）１１１を介して入力装置１１７と、出力インタフェース（Ｉ／Ｆ）１１４を介して出力装置１１８と接続する。情報処理装置としての具体例としては、ＵＳＢインタフェースを備えたパーソナルコンピュータ（ＰＣ）、タブレット端末、スマートフォン、デジタルカメラなどがある。

また、情報処理装置１１０は、入力Ｉ／Ｆ１１１と出力Ｉ／Ｆ１１４の他に、ＣＰＵ１１２と、ＲＯＭ１１３と、外部記憶装置１１５と、ＲＡＭ１１６と、入出力インタフェース（Ｉ／Ｆ）１１９を有する。ＲＯＭ１１３は初期化プログラムを格納し、ハードディスク（ＨＤ）や半導体ディスク（ＳＳＤ）などの外部記憶装置１１５はＯＳ、アプリケーションやその他各種のデータを格納している。ＲＡＭ１１６は外部記憶装置１１５に格納されている各種プログラムをＣＰＵ１１２が実行するための作業領域として使用される。

画像処理装置１２０は、ＲＡＭ１２１、制御プログラムを格納するＲＯＭ１２２、プリンタエンジン１２３、制御プログラムを実行して装置全体の制御と通信制御と記録制御を実行するＣＰＵ１２４、入出力インタフェース（Ｉ／Ｆ）１２５から構成される。情報処理装置１１０と画像処理装置１２０はＵＳＢケーブル１３０により、夫々の入出力Ｉ／Ｆ１１９、１２５を介して接続される。ＲＡＭ１２１はＣＰＵ１２４が制御プログラムを実行する際の作業領域として、また、情報処理装置１１０から受信したデータの一時保存用バッファとしても利用される。

プリンタエンジン１２３はＲＡＭ１２１に保存された画像データに基づいて記録媒体に印刷を行う。プリンタエンジン１２３は電子写真方式に従うものでもインクジェット方式に従うものでも良い。また、画像処理装置の具体例としては、単機能プリンタ装置、スキャナ装置やさらにはファクシミリ装置を備えた多機能プリンタ装置（ＭＦＰ）などがある。

なお、以上説明した情報処理装置１１０と画像処理装置１２０との処理分担は、これによって限定されるものではなく、他の処理分担の形態でも良い。

以上の構成から分かるように、図１に示す印刷システムは具体的な情報処理装置と画像処理装置で構成されるが、両者がＵＳＢ接続されＵＳＢインタフェースを介して互いに通信するので、両者とも通信装置であるとも言える。

図２は情報処理装置が実行するソフトウェアを示すブロック図である。

情報処理装置１１０は、画像処理装置１２０と、ＵＳＢデバイスドライバ２０３とＨＴＴＰ通信モジュール２０２、２０５を介して通信を行う管理アプリケーション２０１と印刷アプリケーション２０４を実行する。

管理アプリケーション２０１は、画像処理装置１２０の状態情報の取得を要求するコマンドをＨＴＴＰ通信モジュール２０２に入力する。ＨＴＴＰ通信モジュール２０２は、受信したコマンドをさらにＨＴＴＰリクエストパケットに変換し、ＵＳＢデバイスドライバ２０３を介して画像処理装置１２０へと送信する。画像処理装置１２０は、ＵＳＢデバイスドライバ２０３が送信したＨＴＴＰリクエストパケットを受信後、受信に成功したか否かを示す情報をＨＴＴＰレスポンスパケットとして生成する。ＨＴＴＰ通信モジュール２０２はＵＳＢデバイスドライバ２０３を介してＨＴＴＰレスポンスパケットを取得する。その後、ＨＴＴＰ通信モジュール２０２は、ＨＴＴＰレスポンスパケットに含まれる受信結果情報を取り出し、その受信結果情報を管理アプリケーション２０１へ返却する。

続いて、管理アプリケーション２０１は、画像処理装置１２０の状態情報を取得するコマンドをＨＴＴＰ通信モジュール２０２に入力する。ＨＴＴＰ通信モジュール２０２は、受信したコマンドをＨＴＴＰリクエストパケットに変換し、ＵＳＢデバイスドライバ２０３を介して画像処理装置１２０へと送信する。画像処理装置１２０は、ＨＴＴＰリクエストパケットを受信後、自分自身の状態情報を含めたＨＴＴＰレスポンスパケットを生成する。ＨＴＴＰ通信モジュール２０２は、ＵＳＢデバイスドライバ２０３を介してＨＴＴＰレスポンスパケットを取得する。その後、ＨＴＴＰ通信モジュール２０２は、ＨＴＴＰレスポンスパケットに含まれる画像処理装置１２０の状態情報を管理アプリケーション２０１へ返却する。

また、印刷アプリケーション２０４は、ユーザが指定した入力データを画像処理装置１２０が解釈可能な印刷コマンドへと変換し、変換した印刷コマンドをＨＴＴＰ通信モジュール２０５に順次入力する。ＨＴＴＰ通信モジュール２０５は、受信した印刷コマンドをさらにＨＴＴＰリクエストパケットに変換し、画像処理装置１２０へと送信する。画像処理装置１２０は、ＨＴＴＰ通信モジュール２０５が送信したＨＴＴＰリクエストパケットを受信後、受信に成功したか否かを示す情報をＨＴＴＰレスポンスパケットとして生成する。ＨＴＴＰ通信モジュール２０５は、ＵＳＢデバイスドライバ２０３を介してＨＴＴＰレスポンスパケットを取得する。その後、ＨＴＴＰ通信モジュール２０５は、ＨＴＴＰレスポンスパケットに含まれる受信結果情報を取り出しし、その受信結果情報を印刷アプリケーション２０４へ返却する。

以上のように、情報処理装置１１０と画像処理装置１２０とはＵＳＢ接続した形態でＨＴＴＰ通信を行い、情報処理装置１１０はＨＴＴＰクライアントとして、画像処理装置１２０はＨＴＴＰサーバとして動作する。従って、この印刷システムは、サーバクライアントシステムを構成しているとも言える。

なお、ＨＴＴＰ通信おいて、情報処理装置（ＨＴＴＰクライアント）からのリクエストを受信したＷｅｂサーバや画像処理装置（ＨＴＴＰサーバ）はレスポンス情報を生成し、これをＨＴＴＰクライアントに向けて送信する。仮に、画像処理装置からのレスポンス情報の送信が完了しなかったとしても、画像処理装置は複数回、送信処理を繰返した後、レスポンス情報を破棄するといった処理が可能である。また、ＴＣＰ層で情報処理装置と画像処理装置のＩＰアドレス、ポート番号をもとにセションを区別しているため、処理終了に伴うセションクローズによって画像処理装置が初期状態に戻ることができる。例えば、もし、レスポンス情報の送信が未完了のまま、情報処理装置側が処理を終了したとしても、そのレスポンス情報は破棄される。

一方、ＵＳＢによって接続された情報処理装置（ＵＳＢホスト）と画像処理装置（ＵＳＢデバイス）が通信を行う場合には、ＵＳＢデバイス側からＵＳＢホストに対して能動的に情報を送信することはできない。そのため、ＵＳＢを介して、ＨＴＴＰをベースとしたプロトコルを利用した通信を行うためには、情報処理装置（ＨＴＴＰクライアント）は、ＨＴＴＰリクエストを送信後に画像処理装置（ＨＴＴＰサーバ）が生成したレスポンス情報を取得する必要がある。

図３はＵＳＢデバイスドライバを利用した情報処理装置と画像処理装置との間の通信を説明する図である。

画像処理装置１２０がＵＳＢケーブル１３０によって情報処理装置１１０に接続されると、図３に示すように、ＵＳＢバス３０６上に、情報処理装置１１０とエンドポイント０（入出力）３０１との間に論理的な通信経路（パイプ）が生成される。その後、制御転送による通信を経て、画像処理装置１２０が情報処理装置１１０に認識される。その際、情報処理装置１１０と画像処理装置１２０が備えるエンドポイント（１〜ｎ）３０２〜３０５との間にもパイプが生成される。この場合、情報処理装置１１０はＵＳＢホストとして動作し、通信相手の装置となる画像処理装置１２０はＵＳＢデバイスとして動作する。

なお、情報処理装置１１０とエンドポイント０（入出力）３０１を除くエンドポイント３０２〜３０５との間に生成されたパイプを使った通信は、情報処理装置１１０から転送する「出力」と画像処理装置１２０から転送する「入力」のいずれか片方向である。

また、画像処理装置１２０から情報処理装置１１０に対して情報を転送する場合、ＵＳＢバス３０６を制御するのはホストである情報処理装置１１０であるため、画像処理装置１２０はＵＳＢバス３０６に情報を書き込むことができない。そこで、画像処理装置１２０から情報処理装置１１０に対する「入力」方向の転送では、情報は「入力」用エンドポイントに書き込まれ、情報処理装置１１０がエンドポイントに対して「入力」パケットを送信するまで保持される。

・ＨＴＴＰパケット送受信シーケンス（図４〜図５）
（１）正常処理
図４は情報処理装置と画像処理装置との間で正常にＨＴＴＰパケットが送受信される場合のシーケンスを示す図である。なお、情報処理装置１１０と画像処理装置１２０はＵＳＢケーブル１３０で接続されており、ＨＴＴＰパケットはＵＳＢバス３０６上でやりとりされるものとする。

ＨＴＴＰ通信モジュール２０２は、管理アプリケーション２０１から入力された能力情報取得コマンド（＜ＧｅｔＣａｐａｂｉｌｉｔｙＩｎｆｏ＞）に応じてＨＴＴＰリクエスト（ＨＴＴＰリクエストライン、ヘッダ、ボディ）を生成する。そして、ＨＴＴＰ通信モジュール２０２は、ＵＳＢデバイスドライバ２０３を介して、その生成されたＨＴＴＰリクエスト（Ｓ４０１）を画像処理装置１２０に送信する。なお、一度の通信でＨＴＴＰリクエストを送信し切れない場合は、数回に分けて送信を実行するものとする。また、ＵＳＢの転送モードにはバルク転送を用いている（Ｂｕｌｋ ｏｕｔ／Ｂｕｌｋ ｉｎ）。次に、ＨＴＴＰリクエストを受信した画像処理装置１２０は、受信に成功したことを示すステータスコード（２００）を含む情報をＨＴＴＰレスポンス（Ｓ４０２）として生成し、これをエンドポイント（入力）に書き出す。

ＨＴＴＰレスポンス（Ｓ４０２）は、ＨＴＴＰ通信モジュール２０２が、ＵＳＢデバイスドライバ２０３を介して取得する。続いて、ＨＴＴＰ通信モジュール２０２は、画像処理装置１２０に送信したＨＴＴＰリクエスト（Ｓ４０１）に含まれる能力情報取得コマンドのレスポンスを取得するためのＨＴＴＰリクエスト（Ｓ４０３）を画像処理装置１２０に送信する。これに応じて、画像処理装置１２０はＨＴＴＰリクエストの受信成功を示すステータスコード（２００）、能力情報を返却するためのコマンド（＜ＧｅｔＣａｐａｂｉｌｉｔｙＩｎｆｏＲｅｓｐｏｎｓｅ＞）を含むＨＴＴＰレスポンス（Ｓ４０４）を生成する。そして、これをエンドポイント（入力）に書き出す。ＨＴＴＰ通信モジュール２０２は、ＵＳＢデバイスドライバ２０３を介して、ＨＴＴＰレスポンス（Ｓ４０４）を取得し、能力情報を取り出して管理アプリケーション２０１に送信する。

その後、ＨＴＴＰ通信モジュール２０２は、通信の終了を示すＨＴＴＰリクエスト（Ｓ４０５）を画像処理装置１２０に送信する。このリクエストを受信した画像処理装置１２０は、このリクエストの受信に成功したことを示すＨＴＴＰレスポンス（Ｓ４０６）を生成し、エンドポイント（入力）に書き出す。最後に、ＨＴＴＰ通信モジュール２０２がＨＴＴＰレスポンス（Ｓ４０６）を取得することで、一連の通信が終了となる。

（２）途中終了
図５は何らかの理由により管理アプリケーションもしくはＨＴＴＰ通信モジュールの処理が途中終了し、画像処理装置がエンドポイント（入力）に書出した情報が取得されずに残る場合のシーケンス例を示す図である。処理途中終了の理由には、管理アプリケーション又はＨＴＴＰ通信モジュールに処理の不備（レスポンス情報取得処理の未実行）や、アクセスバイオレーション等による管理アプリケーション又はＨＴＴＰ通信モジュールの強制終了などがある。

なお、図５において、ＨＴＴＰリクエストとＨＴＴＰレスポンス（Ｓ５０１〜Ｓ５０４）は、図４におけるＨＴＴＰリクエストとＨＴＴＰレスポンス（Ｓ４０１〜Ｓ４０４）に相当するため説明は省略する。

図５によれば、ＨＴＴＰ通信モジュール２０２は、管理アプリケーション２０１から入力された状態情報取得コマンド（＜ＧｅｔＳｔａｔｕｓＩｎｆｏ＞）に応じたＨＴＴＰリクエスト（Ｓ５０５）を生成する。そして、これをＵＳＢデバイスドライバ２０３を介して、画像処理装置１２０に送信する。

これを受信した画像処理装置１２０は、ＨＴＴＰリクエストの受信成功を示すステータスコード（２００）、状態情報を返却するためのコマンド（＜ＧｅｔＳｔａｔｕｓＩｎｆｏＲｅｓｐｏｎｓｅ＞）を含むＨＴＴＰレスポンスを生成する。そして、これをエンドポイント（入力）に書き出す。

ここで、図５に示すように、管理アプリケーション２０１またはＨＴＴＰ通信モジュール２０２がこの情報の取得処理を行わなかった場合、エンドポイント（入力）に書き出されたＨＴＴＰレスポンス情報は取得されずに残ってしまう。その結果、その後に、例えば、印刷アプリケーション２０４がエンドポイント（入力）の情報取得を試みると、期待とは異なるＨＴＴＰレスポンス情報が返却される可能性がある。

以上の説明から分かるように、情報処理装置と画像処理装置がＵＳＢ接続された環境で互いにＨＴＴＰ通信を行う場合、情報処理装置はＵＳＢホスト、ＨＴＴＰクライアントとして、画像処理装置はＵＳＢデバイス、ＨＴＴＰサーバとして動作する。

次に、以上説明した構成の印刷システムにおいて、図５に示すようなＨＴＴＰ通信が途中終了した場合における対処方法についていくつかの実施形態について説明する。

＜実施形態１（図６〜図７）＞
図６はＨＴＴＰ通信モジュールにおける通信制御処理を示すフローチャートである。

また、図７は、図６で説明する処理を行った際の、情報処理装置１１０と画像処理装置１２０との間の通信シーケンスを示す図である。

図６によれば、ＨＴＴＰ通信モジュール２０２が通信制御処理を開始すると、ステップＳ６０１では、ＨＴＴＰ通信モジュール２０２が管理アプリケーション２０１から入力された情報取得コマンドを受信する。続いて、ステップＳ６０２では、ＨＴＴＰ通信モジュール２０２が画像処理装置１２０との通信を一意に特定するための情報（以降、セッションＩＤ）を生成する。一意性を持つ情報としては、ＧＵＩＤ（Ｇｌｏｂａｌ Ｕｎｉｑｕｅ Ｉｄｅｎｔｉｆｉｅｒ）を使う方法が知られている。

次に、ステップＳ６０３では、ＨＴＴＰ通信モジュール２０２がステップＳ６０１で受付けた情報取得コマンドおよびステップＳ６０２で生成したセッションＩＤを含むＨＴＴＰリクエスト情報を生成する。さらに、ステップＳ６０４では、ＨＴＴＰ通信モジュール２０２がＵＳＢデバイスドライバ２０３を介して、ＨＴＴＰリクエスト情報を画像処理装置１２０に送信する。なお、ここでは、セッションＩＤをやりとりするためにＨＴＴＰの拡張ヘッダ（Ｘ−ＨＴＴＰ−Ｓｅｓｓｉｏｎ）を定義している（図７のＳ７０１）。

続いて、ステップＳ６０５では、ＨＴＴＰ通信モジュール２０２がＵＳＢデバイスドライバ２０３を介して、画像処理装置１２０からのレスポンス情報を取得する。このとき、画像処理装置１２０は、情報処理装置１１０から受取ったＨＴＴＰリクエストに含まれるセッションＩＤを識別し、ＨＴＴＰレスポンス情報に埋め込んで応答するものとする（図７のＳ７０２）。なお、未取得状態のＨＴＴＰレスポンスが画像処理装置１２０に残っている場合は、その未取得状態で残っているＨＴＴＰレスポンスのセッションＩＤを含むＨＴＴＰレスポンスが情報処理装置１１０に応答される。なお、その後の情報処理装置１１０と画像処理装置１２０との通信においてもＨＴＴＰの拡張ヘッダ（Ｘ−ＨＴＴＰ−Ｓｅｓｓｉｏｎ）を用いてセッションＩＤがやりとりされる（図７のＳ７０３〜Ｓ７０６）。
その後、ステップＳ６０６では、ＨＴＴＰ通信モジュール２０２は、取得したＨＴＴＰレスポンス情報に含まれるセッションＩＤを検出し、検出したセッションＩＤとステップＳ６０４で生成したセッションＩＤと比較する（Ｓ６０７）。

ステップＳ６０８では、ＨＴＴＰ通信モジュール２０２が、ステップＳ６０７における比較に基づいて、セッションＩＤが同一であるか否かを調べる。ここで、セッションＩＤが同一であると判定された場合、処理はステップＳ６０９に進む。そして、ステップＳ６０９では、ＨＴＴＰ通信モジュール２０２は、ステップＳ６０５で取得した画像処理装置１２０からのレスポンス情報を管理アプリケーション２０１に応答し、その後、処理を終了する。これに対して、セッションＩＤが同一でないと判定された場合、ＨＴＴＰ通信モジュール２０２における処理はステップＳ６１０に進む。

ステップＳ６１０では、ＨＴＴＰ通信モジュール２０２が画像処理装置１２０の状態を初期状態にするためのリセットコマンドを生成し、そのリセットコマンドをＵＳＢデバイスドライバ２０３を介して画像処理装置１２０に送信する。ＨＴＴＰ通信モジュール２０２は、リセットコマンドとしてＶｅｎｄｅｒ Ｒｅｑｕｅｓｔを定義し、データ送受信用のバルク転送（Ｂｕｌｋ）とは異なるＵＳＢのコントロール転送を用いて画像処理装置１２０に送信している（図７のＳ７０７）。一方、リセットコマンドを受信した画像処理装置１２０は、保持しているレスポンス情報を破棄し、初期状態に戻る。その後、ステップＳ６１２ではＨＴＴＰ通信モジュール２０２は、管理アプリケーション２０１に対して通信の失敗を通知し、処理を終了する。

ここで、一例を挙げて説明する。アプリケーションが画像処理装置に所定の処理を実行させる場合、ＨＴＴＰ通信モジュール２０２は、アプリケーションから入力データを受け付けてセッションＩＤ＝２のＨＴＴＰリクエストを生成する。そして、ＨＴＴＰ通信モジュール２０２は、ア所定の処理を画像処理装置に実行させるために、セッションＩＤ＝２を含むＨＴＴＰリクエストを画像処理装置１２０へ送信する。

一方、画像処理装置１２０は、未取得状態のセッションＩＤ＝１のＨＴＴＰレスポンスを保持している状態で、セッションＩＤ＝２のＨＴＴＰリクエストを受信する。この場合、画像処理装置１２０は、先頭で保持しているセッションＩＤ＝１のＨＴＴＰレスポンスを送信する。なお、この未取得状態のセッションＩＤ＝１のＨＴＴＰレスポンスを保持している状態は、画像処理装置１２０が上述した所定の処理を実行できない状態に相当する。

その結果、ＨＴＴＰ通信モジュール２０２は、ステップＳ６０２で生成したセッションＩＤ＝２と、ステップＳ６０６で検出されたセッションＩＤ＝１のＨＴＴＰレスポンスのＩＤが異なると判定し（Ｓ６０８）、ステップＳ６１１を実行する。ステップＳ６１１により、画像処理装置１２０は、初期状態に戻る。ここで、初期状態に戻す理由について説明する。例えば、画像処理装置１２０が、決められた順番で情報を送受することによって処理を実行する場合、その途中で情報処理装置が通信を行わずに処理を終えてしまうと、画像処理装置が他の処理（上述した所定の処理）を実行できなくなってしまう可能性がある。そのため、ステップＳ６１１にて画像処理装置１２０の状態を初期状態に戻すことで、画像処理装置１２０は、セッションＩＤ＝２のＨＴＴＰリクエストに基づく所定の処理を実行することが可能となる。そのため、上述したリセットコマンドは、新たに要求された所定の処理を実行できる状態で画像処理装置１２０を動作させるための指示と呼ぶこともできる。なお、初期状態は一例であり、上述した所定の処理を実行可能となる状態であれば構わない。また、所定の処理は、例えば、画像処理装置１２０が、リクエストに応じて自身の能力情報を送信する処理や、印刷処理であるが、他の処理であっても構わない。

従って以上説明した実施形態に従えば、情報処理装置と画像処理装置がＵＳＢ接続された環境において、情報処理装置からのＨＴＴＰ通信が途中終了した場合でも画像処理装置側の処理を終了させることができる。

なお、管理アプリケーション２０１がＨＴＴＰ通信モジュール２０２より通信の失敗を受信した場合、再度データの送受信を行ってもよい。この場合、ステップＳ６１０〜Ｓ６１１の処理によって画像処理装置１２０が初期状態に戻ることから、通信の成功が期待される。

また、この実施形態では、情報処理装置１１０と画像処理装置１２０が通信を行うごとにセッションＩＤを生成する例を示したが、アプリケーションと画像処理装置１２０との間の通信を一つの単位とし、その間、同じセッションＩＤを使用してもよい。

さらに、ステップＳ６０８において、セッションＩＤが同一でないと判定された場合、セッションＩＤが一致するまでステップＳ６０５〜Ｓ６０８の処理を繰り返してもよい。その場合、処理を繰り返す回数を予め決めておき、その間にセッションＩＤが一致しなかった場合、ステップＳ６１０に進むようにしてもよい。

ここで、一例を挙げて説明する。ＨＴＴＰ通信モジュール２０２は、アプリケーションからの入力データを受け付けてセッションＩＤ＝２のＨＴＴＰリクエストを生成し、画像処理装置１２０へ送信する。

一方、画像処理装置１２０は、未取得状態のセッションＩＤ＝１のＨＴＴＰレスポンスを保持している状態で、セッションＩＤ＝２のＨＴＴＰリクエストを受信する。この場合、画像処理装置１２０は、セッションＩＤ＝１のＨＴＴＰレスポンスとセッションＩＤ＝２のＨＴＴＰレスポンスを保持する。そして、画像処理装置は、先頭で保持しているセッションＩＤ＝１のＨＴＴＰレスポンスを送信する。

その結果、ＨＴＴＰ通信モジュール２０２は、ステップＳ６０２で生成したセッションＩＤ＝２と、ステップＳ６０６で検出されたセッションＩＤ＝１のＨＴＴＰレスポンスのＩＤが異なると判定する（ステップＳ６０８）。そして、ＨＴＴＰ通信モジュール２０２は、再度、ステップＳ６０５〜Ｓ６０７を実行することで、画像処理装置からセッションＩＤ＝２のＨＴＴＰレスポンスを受信する。

その結果、ＨＴＴＰ通信モジュール２０２は、２回目のステップＳ６０５〜Ｓ６０８によりステップＳ６０２で生成したセッションＩＤ＝２に一致するＨＴＴＰレスポンスを受信することができる。

＜実施形態２（図８〜図９）＞
実施形態１では、ＨＴＴＰ通信モジュール２０２がセッションＩＤを生成し、拡張ヘッダにこの情報をセットしたＨＴＴＰリクエストを画像処理装置に送信する例を説明した。この実施形態では、アプリケーションがセッションＩＤを管理する例について説明する。

図８はアプリケーションがセッションＩＤを管理する通信制御処理を示すフローチャートである。また、図９は、図８で説明する処理を行った際の、情報処理装置１１０と画像処理装置１２０との間の通信シーケンスを示す図である。なお、ここでは、管理アプリケーション２０１と画像処理装置１２０との間の通信を例にとって説明する。

管理アプリケーション２０１は通信制御処理を開始すると、ステップＳ８０１では、画像処理装置１２０に送信するための入力データを生成する。そして、ステップＳ８０２では、管理アプリケーション２０１が画像処理装置１２０との通信を一意に特定するための情報（以降、セッションＩＤ）を生成する。なお、ステップＳ８０１、Ｓ８０２の処理の順番は逆でもよい。

次に、ステップＳ８０３では、管理アプリケーション２０１がステップＳ８０１で生成した入力データとステップＳ８０２で生成したセッションＩＤを、ＨＴＴＰ通信モジュール２０２を介して、画像処理装置１２０に送信する。ここでは、能力情報取得コマンド（＜ＧｅｔＣａｐａｂｉｌｉｔｙＩｎｆｏ＞）の中に、セッションＩＤを示すパラメータ（＜ｓ−ｉｄ＞）を用意し、ステップＳ８０２で生成したセッションＩＤをセットしている（図９のＳ９０１）。

さらに、ステップＳ８０４では、管理アプリケーション２０１がＨＴＴＰ通信モジュール２０２を介して、画像処理装置１２０から返却されたレスポンス情報を受信する。なお、画像処理装置１２０は、情報処理装置１１０から受け取った能力情報取得コマンドに含まれるセッションＩＤを識別する。そして、画像処理装置１２０は、識別したセッションＩＤを能力情報返却コマンド（＜ＧｅｔＣａｐａｂｉｌｉｔｙＩｎｆｏＲｅｓｐｏｎｓｅ＞）に埋め込んで応答する（図９のＳ９０４）。なお、図９のＳ９０２とＳ９０３は図４のＳ４０２とＳ４０３はそれぞれ同じなので、その説明は省略する。

その後、ステップＳ８０５において、管理アプリケーション２０１は、取得したレスポンス情報に含まれるセッションＩＤを検出し、検出したセッションＩＤとステップＳ８０２で生成したセッションＩＤを比較する（Ｓ８０６）。ステップＳ８０７では、管理アプリケーション２０１がその比較に基づいて、セッションＩＤが同一であるか否かを調べる。ここで、セッションＩＤが同一であると判定された場合、処理はステップＳ８０９に進む。これに対して、セッションＩＤが同一でないと判定された場合、処理はステップＳ８０８に進む。ステップＳ８０８では、管理アプリケーション２０１は、画像処理装置１２０の状態を初期状態にするためのリセットコマンドを生成し、これをＨＴＴＰ通信モジュール２０２を介して画像処理装置１２０に送信する（図９のＳ９０７）。なお、図９のＳ９０５とＳ９０６は図４のＳ４０５とＳ４０６はそれぞれ同じなので、その説明は省略する。

なお、ステップＳ８０７において、セッションＩＤが同一でないと判定された場合、セッションＩＤが一致するまで、ステップＳ８０４〜Ｓ８０７の処理を繰り返してもよい。その場合、処理を繰り返す回数を予め決めておき、その間にセッションＩＤが一致しなかった場合、ステップＳ８０８に進むようにしてもよい。

その後、ステップＳ８０９では、管理アプリケーション２０１が予定していたデータの送受信が全て完了したかを調べる。ここで、データの送受信が完了していないと判定された場合、処理はステップＳ８０１に戻り、上記のデータの送受信処理を繰り返す。なお、その場合、セッションＩＤが既に生成済であれば、ステップＳ８０３の処理は実行せず、生成済のセッションＩＤを利用してもよい。これに対して、予定していたデータの送受信が全て完了したと判定された場合、処理を終了する。

従って以上説明した実施形態に従えば、情報処理装置と画像処理装置がＵＳＢ接続された環境において、情報処理装置からのＨＴＴＰ通信が途中終了した場合でも、画像処理装置側の処理を終了させることができる。

＜実施形態３（図１０）＞
一般に、情報処理装置１１０上で動作するアプリケーションが複数あり、アプリケーションが画像処理装置１２０との通信を占有する必要がある場合、ミューテックスやセマフォといった仕組みを用いてアプリケーション間の処理を排他する方法が考えられる。

この実施形態では、その排他方法としてミューテックスを使用し、情報処理装置が実行するアプリケーションが画像処理装置と通信する前に、他のアプリケーションによる画像処理装置の所有権を解放する例について説明する。特に、この実施形態では、管理アプリケーション２０１と印刷アプリケーション２０４が同じ情報処理装置１１０上で動作している環境で、管理アプリケーション２０１が画像処理装置１２０を独占し、連続した複数回の通信を行うとする。この場合、まず、管理アプリケーション２０１と印刷アプリケーション２０４の間で共有するミューテックスオブジェクト名を定める。

そして、管理アプリケーション２０１は、実施形態１、２において、図６と図８をそれぞれ参照して説明した処理を実行する前に、このミューテックスオブジェクトの所有権の取得を試みる。そして、所有権の取得に成功したならば、図６又は図８を参照して説明した処理を実行する。

なお、印刷アプリケーション２０４が画像処理装置１２０と通信する場合も、同様にミューテックスオブジェクトの所有権を取得した後、通信を行うものとする。管理アプリケーション２０１がミューテックスオブジェクトを所有している間、印刷アプリケーション２０４はミューテックスオブジェクトの所有権を取得できないため、印刷アプリケーション２０４と画像処理装置１２０との間の通信は行われない。つまり、管理アプリケーション２０１は画像処理装置１２０との間の通信を独占することができる。

管理アプリケーション２０１は、所望の処理を全て終えた後にこのミューテックスオブジェクトの所有権を解放する。これにより、印刷アプリケーション２０４はミューテックスオブジェクトの所有権を取得可能になり、画像処理装置１２０との間の通信も可能になる。なお、一般的に、アプリケーションがミューテックスオブジェクトの所有権を解放せずに処理を終了した場合、この所有権は放棄されたとみなされる。その場合、その後、ミューテックスオブジェクトの所有権を取得したアプリケーションは、そのミューテックスオブジェクトが放棄されたものか否かを判定する。

なお、ミューテックスオブジェクトの所有権が放棄される場合には、アプリケーションに処理の不備（所有権の解放を行わない）がある場合や、アクセスバイオレーション等によってアプリケーションが強制終了する場合などが考えられる。そうした状況では、画像処理装置１２０は処理を完了できず、その後の他のアプリケーションとの通信に支障をきたす可能性がある。

図１０は通信回復のために所有権解放処理を示すフローチャートである。

ここでは、管理アプリケーション２０１がミューテックスオブジェクトの所有権を解放しないまま処理終了後、印刷アプリケーション２０４が画像処理装置１２０との間の通信を行う例について説明する。

印刷アプリケーション２０４は、画像処理装置１２０との通信を占有するための処理を開始すると、まず、ステップＳ１００１では管理アプリケーション２０１と共有するミューテックスオブジェクトの所有権の取得を試みる。

次に、ステップＳ１００２では、印刷アプリケーション２０４がミューテックスオブジェクトの所有権の取得に成功したか否かを調べる。ここで、所有権の取得に失敗したと判定された場合、処理を終了する。この場合、印刷アプリケーション２０４は、その後に再びミューテックスオブジェクトの所有権の取得を試みてもよい。これに対して、ミューテックスオブジェクトの所有権の取得に成功したと判定された場合、処理はステップＳ１００３に進み、印刷アプリケーション２０４は、そのミューテックスオブジェクトの所有権が放棄されたものかどうかを調べる。具体的には、印刷アプリケーション２０４は、ミューテックスオブジェクトに所有権が放棄されたことを示す情報が含まれていないかを判定することで所有権が放棄されたか否かを決定する。

ここで、ミューテックスオブジェクトの所有権が放棄されたものであると判定された場合、印刷アプリケーション２０４は画像処理装置１２０の状態を初期状態にするためのコマンドを生成し、画像処理装置１２０に送信する（Ｓ１００４）。これにより、管理アプリケーション２０１がミューテックスオブジェクトの所有権を解放せずに処理を終え、画像処理装置１２０の処理が未完了のままだったとしても、画像処理装置１２０の状態を初期状態に戻すことができる。その後、印刷アプリケーション２０４は、処理を終了する。実際には、図１０の後に図６（または図８）を参照して説明した処理が実行され、画像処理装置１２０との間の通信が行われる。

これに対して、ミューテックスオブジェクトの所有権を取得成功後に、ミューテックスオブジェクトの所有権が放棄されていないと判定された場合、処理はそのまま終了する。

従って以上説明した実施形態に従えば、他のアプリケーションが占有している画像処理装置の所有権を解放した後、実施形態１、２に従う通信制御を実行して、その画像処理装置との通信を実行することができる。

なお、所有権が取得できなかった場合にその理由を確認し、以前の所有権が放棄されたものであるかを判断してもよい。

また、この実施形態では、アプリケーションがミューテックスオブジェクトの所有権を取得して複数のアプリケーションと画像処理装置との間の通信を排他する例を説明したが、ＨＴＴＰ通信モジュールが同様の処理を行い、通信を排他してもよい。

＜実施形態４（図１１）＞
実施形態１〜３では、情報処理装置上で動作するアプリケーションが、画像処理装置と前に通信していたアプリケーションとの間の処理が未完了であることを検知または予測し、画像処理装置の処理を終了する方法について説明した。この実施形態では、このような検知または予測することなく、画像処理装置の処理を終了させる例について説明する。

図１１は情報処理装置上で動作するアプリケーションの処理を示すフローチャートである。ここでは、管理アプリケーション２０１と画像処理装置１２０との間の通信を例にとって説明する。

管理アプリケーション２０１が処理を開始すると、ステップＳ１１０１では、画像処理装置１２０の状態を初期状態にするためのリセットコマンドを生成し、ＨＴＴＰ通信モジュール２０２を介して画像処理装置１２０に送信する。これにより、画像処理装置１２０が前に通信していたアプリケーションとの間の処理を完了していない場合にも、画像処理装置１２０の処理を終了することができる。

続いて、ステップＳ１１０２では、管理アプリケーション２０１は、画像処理装置１２０に対する入力データを生成し、ステップＳ１１０３では、ＨＴＴＰ通信モジュール２０２を介して画像処理装置１２０に送信する。その後、ステップＳ１１０５では、画像処理装置１２０からのレスポンスデータを受信し、さらにステップＳ１１０６では、管理アプリケーション２０１が予定していたデータの送受信が全て完了したかどうかを調べる。

ここで、データの送受信が未完了であると判定された場合、処理はステップＳ１１０２に戻り、データの送受信を繰り返す。これに対して、予定していたデータの送受信が全て完了したと判定された場合、処理を終了する。

従って以上説明した実施形態に従えば、情報処理装置上で動作するアプリケーションが、画像処理装置と前に通信していたアプリケーションとの間の処理が未完了であることを検知または予測せずとも、画像処理装置の処理を終了することができる。

なお、以上説明した実施形態における印刷システムでは情報処理装置と画像処理装置とをＵＳＢ接続した構成としたが本発明はこれによって限定されるものではない。セッションの開始と終了が明確でなく、画像処理装置側からの能動的な情報送信が行えないといった、ＵＳＢと同様の特徴をもつ通信プロトコルを使用した接続形態であってもよい。さらに、情報処理装置と画像処理装置との間の通信はＨＴＴＰ通信に限定されるものではなく、クライアントサーバシステムにおいてサーバ装置とクライアント装置との間でセションを確立して通信を行うことが可能な他のプロトコルでも良い。

１１０ 情報処理装置、１１２ ＣＰＵ、１１７ 入力装置、１１８ 出力装置、
１１９、１２５ 入出力インタフェース（Ｉ／Ｆ）、１２０ 画像処理装置、
１２３ プリンタエンジン、１２４ ＣＰＵ、１３０ ＵＳＢケーブル

Claims (11)

1. 通信相手の装置との通信を確立して通信を行う通信装置であって、
   前記通信相手の装置に所定の処理を実行させる場合、前記通信相手の装置との通信を一意に特定するための第１の情報を生成し、該第１の情報を前記通信相手の装置に送信する生成手段と、
   前記通信相手の装置からの応答を受信し、前記応答に含まれる第２の情報と前記第１の情報が一致するかどうかを判断する判断手段と、
   前記第１の情報と前記第２の情報とが一致しない場合には、前記所定の処理を実行できる状態で前記通信相手の装置を動作させるための指示を前記通信相手の装置に送信する指示手段とを有することを特徴とする通信装置。
2. 前記第１の情報は、前記通信装置と前記通信相手の装置の間で用いられる通信のプロトコルに従って指定されるセッションＩＤであることを特徴とする請求項１に記載の通信装置。
3. 前記第１の情報は、前記通信装置で実行されるアプリケーションによって生成されるセッションＩＤを示すパラメータであることを特徴とする請求項１に記載の通信装置。
4. 前記通信相手の装置との通信を開始する前に、該通信を行うアプリケーションとは異なる他のアプリケーションが前記通信相手の装置の所有権を有しているかどうかを調べ、前記他のアプリケーションが所有権を有しているなら、該他のアプリケーションに該所有権を放棄させる解放手段をさらに有することを特徴とする請求項１乃至３のいずれか１項に記載の通信装置。
5. 正常な通信が実行される場合、前記通信相手の装置は、前記通信装置から送信された前記第１の情報を前記第２の情報として前記応答を送信することを特徴とする請求項１乃至４のいずれか１項に記載の通信装置。
6. 前記通信相手の装置が前記所定の処理を実行できる状態とは、初期状態であることを特徴とする請求項１乃至５のいずれか１項に記載の通信装置。
7. 前記指示手段による指示に基づいて前記通信相手の装置は応答の情報を破棄することにより初期状態に戻ることを特徴とする請求項１乃至６のいずれか１項に記載の通信装置。
8. 前記通信相手の装置とはＵＳＢにより接続され、
   前記通信相手の装置とはＨＴＴＰ通信を行うことを特徴とする請求項１乃至７のいずれか１項に記載の通信装置。
9. 前記通信装置は、パーソナルコンピュータ、タブレット端末、スマートフォン、デジタルカメラを含む情報処理装置であり、
   前記通信相手の装置は、前記情報処理装置によって生成された画像データに基づいて記録媒体に画像を印刷する単機能プリンタや多機能プリンタを含む画像処理装置であることを特徴とする請求項１乃至８のいずれか１項に記載の通信装置。
10. コンピュータに請求項１乃至９のいずれか１項に記載の通信装置の各手段として機能させるためのプログラム。
11. 通信相手の装置との通信を確立して通信を行う通信方法であって、
    前記通信相手の装置に所定の処理を実行させる場合、前記通信相手の装置との通信を一意に特定するための第１の情報を生成し、該第１の情報を前記通信相手の装置に送信する生成工程と、
    前記通信相手の装置からの応答を受信し、前記応答に含まれる第２の情報と前記第１の情報が一致するかどうかを判断する判断工程と、
    前記第１の情報と前記第２の情報とが一致しない場合には、前記所定の処理を実行できる状態で前記通信相手の装置を動作させるための指示を前記通信相手の装置に送信する指示工程とを有することを特徴とする通信方法。

Images