図面 (/)

技術 通信装置、通信方法、及びプログラム

出願人 キヤノン株式会社
発明者 北川寛
出願日 2017年10月25日 (1年9ヶ月経過) 出願番号 2017-206332
公開日 2019年5月23日 (2ヶ月経過) 公開番号 2019-079333
状態 未査定
技術分野 計算機・データ通信 付属装置、全体制御 計算機間の情報転送 ファクシミリ一般
主要キーワード 未取得状態 通信回復 ポート番 多機能プリンタ装置 受信結果情報 制御転送 USBデバイスドライバ 処理分担
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2019年5月23日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (12)

課題

情報処理装置画像処理装置USB接続された環境において、情報処理装置からの通信途中終了した場合でも、画像処理装置側の処理を終了する方法を提供することである。

解決手段

HTTP通信モジュールは画像処理装置との通信を一意に特定するための情報を生成し、画像処理装置との間で送受信を行う。受信した情報が送信した情報と異なる場合、画像処理装置の状態を初期状態に戻すためのコマンドを生成し、送信する。

概要

背景

情報処理装置Webサーバ、またはWebサーバ機能を搭載した周辺装置との間で通信を行う際の方式として、Hyper Text Transfer Protocol(以降、HTTP)が知られている。一般にHTTPはネットワーク回線を介した通信時に利用されることが多いプロトコルであるが、Universal Serial Bus(以降、USB)を介した通信にも利用することが可能である。その代表的な例として、HTTPを拡張したInternet Printing Protocol(以降、IPP)を、USBを介して送受信を行うIPP over USBという規格が知られている。また、このIPP over USBを利用した情報処理装置と画像処理装置との間の通信において、情報処理装置上で動作する複数のソフトウェアと画像処理装置との間の通信を管理する技術も知られている(特許文献1)。

概要

情報処理装置と画像処理装置がUSB接続された環境において、情報処理装置からの通信が途中終了した場合でも、画像処理装置側の処理を終了する方法を提供することである。HTTP通信モジュールは画像処理装置との通信を一意に特定するための情報を生成し、画像処理装置との間で送受信を行う。受信した情報が送信した情報と異なる場合、画像処理装置の状態を初期状態に戻すためのコマンドを生成し、送信する。

目的

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

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

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

請求項2

前記第1の情報は、前記通信装置と前記通信相手の装置の間で用いられる通信のプロトコルに従って指定されるセッションIDであることを特徴とする請求項1に記載の通信装置。

請求項3

前記第1の情報は、前記通信装置で実行されるアプリケーションによって生成されるセッションIDを示すパラメータであることを特徴とする請求項1に記載の通信装置。

請求項4

前記通信相手の装置との通信を開始する前に、該通信を行うアプリケーションとは異なる他のアプリケーションが前記通信相手の装置の所有権を有しているかどうかを調べ、前記他のアプリケーションが所有権を有しているなら、該他のアプリケーションに該所有権を放棄させる解放手段をさらに有することを特徴とする請求項1乃至3のいずれか1項に記載の通信装置。

請求項5

正常な通信が実行される場合、前記通信相手の装置は、前記通信装置から送信された前記第1の情報を前記第2の情報として前記応答を送信することを特徴とする請求項1乃至4のいずれか1項に記載の通信装置。

請求項6

前記通信相手の装置が前記所定の処理を実行できる状態とは、初期状態であることを特徴とする請求項1乃至5のいずれか1項に記載の通信装置。

請求項7

前記指示手段による指示に基づいて前記通信相手の装置は応答の情報を破棄することにより初期状態に戻ることを特徴とする請求項1乃至6のいずれか1項に記載の通信装置。

請求項8

前記通信相手の装置とはUSBにより接続され、前記通信相手の装置とはHTTP通信を行うことを特徴とする請求項1乃至7のいずれか1項に記載の通信装置。

請求項9

前記通信装置は、パーソナルコンピュータタブレット端末スマートフォンデジタルカメラを含む情報処理装置であり、前記通信相手の装置は、前記情報処理装置によって生成された画像データに基づいて記録媒体に画像を印刷する単機能プリンタ多機能プリンタを含む画像処理装置であることを特徴とする請求項1乃至8のいずれか1項に記載の通信装置。

請求項10

コンピュータに請求項1乃至9のいずれか1項に記載の通信装置の各手段として機能させるためのプログラム

請求項11

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

技術分野

0001

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

背景技術

0002

情報処理装置Webサーバ、またはWebサーバ機能を搭載した周辺装置との間で通信を行う際の方式として、Hyper Text Transfer Protocol(以降、HTTP)が知られている。一般にHTTPはネットワーク回線を介した通信時に利用されることが多いプロトコルであるが、Universal Serial Bus(以降、USB)を介した通信にも利用することが可能である。その代表的な例として、HTTPを拡張したInternet Printing Protocol(以降、IPP)を、USBを介して送受信を行うIPP over USBという規格が知られている。また、このIPP over USBを利用した情報処理装置と画像処理装置との間の通信において、情報処理装置上で動作する複数のソフトウェアと画像処理装置との間の通信を管理する技術も知られている(特許文献1)。

先行技術

0003

特開2014−089675号公報

発明が解決しようとする課題

0004

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

0005

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

0006

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

0007

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

課題を解決するための手段

0008

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

0009

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

0010

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

0011

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

発明の効果

0012

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

図面の簡単な説明

0013

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

実施例

0014

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

0015

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

0016

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

0017

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

0018

<印刷システムの概要(図1図3)>
図1は情報処理装置と画像処理装置により構成される印刷システムの全体構成の概要を示すブロック図である。

0019

図1に示されるように、この印刷システムは、情報処理装置110とこれにUSB接続された画像処理装置120とから構成される。情報処理装置110は、データ入力動作指示に使用されるポインティングデバイスなどの入力装置117と、データ表示や状態の通知に使用されるLCDディスプレイなどの出力装置118と接続している。具体的には、情報処理装置110は、入力インタフェース(I/F)111を介して入力装置117と、出力インタフェース(I/F)114を介して出力装置118と接続する。情報処理装置としての具体例としては、USBインタフェースを備えたパーソナルコンピュータ(PC)、タブレット端末スマートフォンデジタルカメラなどがある。

0020

また、情報処理装置110は、入力I/F111と出力I/F114の他に、CPU112と、ROM113と、外部記憶装置115と、RAM116と、入出力インタフェース(I/F)119を有する。ROM113は初期化プログラムを格納し、ハードディスク(HD)や半導体ディスクSSD)などの外部記憶装置115はOS、アプリケーションやその他各種のデータを格納している。RAM116は外部記憶装置115に格納されている各種プログラムをCPU112が実行するための作業領域として使用される。

0021

画像処理装置120は、RAM121、制御プログラムを格納するROM122、プリンタエンジン123、制御プログラムを実行して装置全体の制御と通信制御記録制御を実行するCPU124、入出力インタフェース(I/F)125から構成される。情報処理装置110と画像処理装置120はUSBケーブル130により、夫々の入出力I/F119、125を介して接続される。RAM121はCPU124が制御プログラムを実行する際の作業領域として、また、情報処理装置110から受信したデータの一時保存用バッファとしても利用される。

0022

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

0023

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

0024

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

0025

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

0026

情報処理装置110は、画像処理装置120と、USBデバイスドライバ203とHTTP通信モジュール202、205を介して通信を行う管理アプリケーション201と印刷アプリケーション204を実行する。

0027

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

0028

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

0029

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

0030

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

0031

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

0032

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

0033

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

0034

画像処理装置120がUSBケーブル130によって情報処理装置110に接続されると、図3に示すように、USBバス306上に、情報処理装置110とエンドポイント0(入出力)301との間に論理的な通信経路パイプ)が生成される。その後、制御転送による通信を経て、画像処理装置120が情報処理装置110に認識される。その際、情報処理装置110と画像処理装置120が備えるエンドポイント(1〜n)302〜305との間にもパイプが生成される。この場合、情報処理装置110はUSBホストとして動作し、通信相手の装置となる画像処理装置120はUSBデバイスとして動作する。

0035

なお、情報処理装置110とエンドポイント0(入出力)301を除くエンドポイント302〜305との間に生成されたパイプを使った通信は、情報処理装置110から転送する「出力」と画像処理装置120から転送する「入力」のいずれか片方向である。

0036

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

0037

・HTTPパケット送受信シーケンス図4図5
(1)正常処理
図4は情報処理装置と画像処理装置との間で正常にHTTPパケットが送受信される場合のシーケンスを示す図である。なお、情報処理装置110と画像処理装置120はUSBケーブル130で接続されており、HTTPパケットはUSBバス306上でやりとりされるものとする。

0038

HTTP通信モジュール202は、管理アプリケーション201から入力された能力情報取得コマンド(<GetCapabilityInfo>)に応じてHTTPリクエスト(HTTPリクエストラインヘッダ、ボディ)を生成する。そして、HTTP通信モジュール202は、USBデバイスドライバ203を介して、その生成されたHTTPリクエスト(S401)を画像処理装置120に送信する。なお、一度の通信でHTTPリクエストを送信し切れない場合は、数回に分けて送信を実行するものとする。また、USBの転送モードにはバルク転送を用いている(Bulk out/Bulk in)。次に、HTTPリクエストを受信した画像処理装置120は、受信に成功したことを示すステータスコード(200)を含む情報をHTTPレスポンス(S402)として生成し、これをエンドポイント(入力)に書き出す

0039

HTTPレスポンス(S402)は、HTTP通信モジュール202が、USBデバイスドライバ203を介して取得する。続いて、HTTP通信モジュール202は、画像処理装置120に送信したHTTPリクエスト(S401)に含まれる能力情報取得コマンドのレスポンスを取得するためのHTTPリクエスト(S403)を画像処理装置120に送信する。これに応じて、画像処理装置120はHTTPリクエストの受信成功を示すステータスコード(200)、能力情報を返却するためのコマンド(<GetCapabilityInfoResponse>)を含むHTTPレスポンス(S404)を生成する。そして、これをエンドポイント(入力)に書き出す。HTTP通信モジュール202は、USBデバイスドライバ203を介して、HTTPレスポンス(S404)を取得し、能力情報を取り出して管理アプリケーション201に送信する。

0040

その後、HTTP通信モジュール202は、通信の終了を示すHTTPリクエスト(S405)を画像処理装置120に送信する。このリクエストを受信した画像処理装置120は、このリクエストの受信に成功したことを示すHTTPレスポンス(S406)を生成し、エンドポイント(入力)に書き出す。最後に、HTTP通信モジュール202がHTTPレスポンス(S406)を取得することで、一連の通信が終了となる。

0041

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

0042

なお、図5において、HTTPリクエストとHTTPレスポンス(S501〜S504)は、図4におけるHTTPリクエストとHTTPレスポンス(S401〜S404)に相当するため説明は省略する。

0043

図5によれば、HTTP通信モジュール202は、管理アプリケーション201から入力された状態情報取得コマンド(<GetStatusInfo>)に応じたHTTPリクエスト(S505)を生成する。そして、これをUSBデバイスドライバ203を介して、画像処理装置120に送信する。

0044

これを受信した画像処理装置120は、HTTPリクエストの受信成功を示すステータスコード(200)、状態情報を返却するためのコマンド(<GetStatusInfoResponse>)を含むHTTPレスポンスを生成する。そして、これをエンドポイント(入力)に書き出す。

0045

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

0046

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

0047

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

0048

<実施形態1(図6図7)>
図6はHTTP通信モジュールにおける通信制御処理を示すフローチャートである。

0049

また、図7は、図6で説明する処理を行った際の、情報処理装置110と画像処理装置120との間の通信シーケンスを示す図である。

0050

図6によれば、HTTP通信モジュール202が通信制御処理を開始すると、ステップS601では、HTTP通信モジュール202が管理アプリケーション201から入力された情報取得コマンドを受信する。続いて、ステップS602では、HTTP通信モジュール202が画像処理装置120との通信を一意に特定するための情報(以降、セッションID)を生成する。一意性を持つ情報としては、GUID(Global Unique Identifier)を使う方法が知られている。

0051

次に、ステップS603では、HTTP通信モジュール202がステップS601で受付けた情報取得コマンドおよびステップS602で生成したセッションIDを含むHTTPリクエスト情報を生成する。さらに、ステップS604では、HTTP通信モジュール202がUSBデバイスドライバ203を介して、HTTPリクエスト情報を画像処理装置120に送信する。なお、ここでは、セッションIDをやりとりするためにHTTPの拡張ヘッダ(X−HTTP−Session)を定義している(図7のS701)。

0052

続いて、ステップS605では、HTTP通信モジュール202がUSBデバイスドライバ203を介して、画像処理装置120からのレスポンス情報を取得する。このとき、画像処理装置120は、情報処理装置110から受取ったHTTPリクエストに含まれるセッションIDを識別し、HTTPレスポンス情報に埋め込んで応答するものとする(図7のS702)。なお、未取得状態のHTTPレスポンスが画像処理装置120に残っている場合は、その未取得状態で残っているHTTPレスポンスのセッションIDを含むHTTPレスポンスが情報処理装置110に応答される。なお、その後の情報処理装置110と画像処理装置120との通信においてもHTTPの拡張ヘッダ(X−HTTP−Session)を用いてセッションIDがやりとりされる(図7のS703〜S706)。
その後、ステップS606では、HTTP通信モジュール202は、取得したHTTPレスポンス情報に含まれるセッションIDを検出し、検出したセッションIDとステップS604で生成したセッションIDと比較する(S607)。

0053

ステップS608では、HTTP通信モジュール202が、ステップS607における比較に基づいて、セッションIDが同一であるか否かを調べる。ここで、セッションIDが同一であると判定された場合、処理はステップS609に進む。そして、ステップS609では、HTTP通信モジュール202は、ステップS605で取得した画像処理装置120からのレスポンス情報を管理アプリケーション201に応答し、その後、処理を終了する。これに対して、セッションIDが同一でないと判定された場合、HTTP通信モジュール202における処理はステップS610に進む。

0054

ステップS610では、HTTP通信モジュール202が画像処理装置120の状態を初期状態にするためのリセットコマンドを生成し、そのリセットコマンドをUSBデバイスドライバ203を介して画像処理装置120に送信する。HTTP通信モジュール202は、リセットコマンドとしてVender Requestを定義し、データ送受信用のバルク転送(Bulk)とは異なるUSBのコントロール転送を用いて画像処理装置120に送信している(図7のS707)。一方、リセットコマンドを受信した画像処理装置120は、保持しているレスポンス情報を破棄し、初期状態に戻る。その後、ステップS612ではHTTP通信モジュール202は、管理アプリケーション201に対して通信の失敗を通知し、処理を終了する。

0055

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

0056

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

0057

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

0058

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

0059

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

0060

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

0061

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

0062

ここで、一例を挙げて説明する。HTTP通信モジュール202は、アプリケーションからの入力データを受け付けてセッションID=2のHTTPリクエストを生成し、画像処理装置120へ送信する。

0063

一方、画像処理装置120は、未取得状態のセッションID=1のHTTPレスポンスを保持している状態で、セッションID=2のHTTPリクエストを受信する。この場合、画像処理装置120は、セッションID=1のHTTPレスポンスとセッションID=2のHTTPレスポンスを保持する。そして、画像処理装置は、先頭で保持しているセッションID=1のHTTPレスポンスを送信する。

0064

その結果、HTTP通信モジュール202は、ステップS602で生成したセッションID=2と、ステップS606で検出されたセッションID=1のHTTPレスポンスのIDが異なると判定する(ステップS608)。そして、HTTP通信モジュール202は、再度、ステップS605〜S607を実行することで、画像処理装置からセッションID=2のHTTPレスポンスを受信する。

0065

その結果、HTTP通信モジュール202は、2回目のステップS605〜S608によりステップS602で生成したセッションID=2に一致するHTTPレスポンスを受信することができる。

0066

<実施形態2(図8図9)>
実施形態1では、HTTP通信モジュール202がセッションIDを生成し、拡張ヘッダにこの情報をセットしたHTTPリクエストを画像処理装置に送信する例を説明した。この実施形態では、アプリケーションがセッションIDを管理する例について説明する。

0067

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

0068

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

0069

次に、ステップS803では、管理アプリケーション201がステップS801で生成した入力データとステップS802で生成したセッションIDを、HTTP通信モジュール202を介して、画像処理装置120に送信する。ここでは、能力情報取得コマンド(<GetCapabilityInfo>)の中に、セッションIDを示すパラメータ(<s−id>)を用意し、ステップS802で生成したセッションIDをセットしている(図9のS901)。

0070

さらに、ステップS804では、管理アプリケーション201がHTTP通信モジュール202を介して、画像処理装置120から返却されたレスポンス情報を受信する。なお、画像処理装置120は、情報処理装置110から受け取った能力情報取得コマンドに含まれるセッションIDを識別する。そして、画像処理装置120は、識別したセッションIDを能力情報返却コマンド(<GetCapabilityInfoResponse>)に埋め込んで応答する(図9のS904)。なお、図9のS902とS903は図4のS402とS403はそれぞれ同じなので、その説明は省略する。

0071

その後、ステップS805において、管理アプリケーション201は、取得したレスポンス情報に含まれるセッションIDを検出し、検出したセッションIDとステップS802で生成したセッションIDを比較する(S806)。ステップS807では、管理アプリケーション201がその比較に基づいて、セッションIDが同一であるか否かを調べる。ここで、セッションIDが同一であると判定された場合、処理はステップS809に進む。これに対して、セッションIDが同一でないと判定された場合、処理はステップS808に進む。ステップS808では、管理アプリケーション201は、画像処理装置120の状態を初期状態にするためのリセットコマンドを生成し、これをHTTP通信モジュール202を介して画像処理装置120に送信する(図9のS907)。なお、図9のS905とS906は図4のS405とS406はそれぞれ同じなので、その説明は省略する。

0072

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

0073

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

0074

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

0075

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

0076

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

0077

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

0078

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

0079

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

0080

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

0081

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

0082

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

0083

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

0084

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

0085

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

0086

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

0087

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

0088

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

0089

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

0090

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

0091

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

0092

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

0093

続いて、ステップS1102では、管理アプリケーション201は、画像処理装置120に対する入力データを生成し、ステップS1103では、HTTP通信モジュール202を介して画像処理装置120に送信する。その後、ステップS1105では、画像処理装置120からのレスポンスデータを受信し、さらにステップS1106では、管理アプリケーション201が予定していたデータの送受信が全て完了したかどうかを調べる。

0094

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

0095

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

0096

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

0097

110情報処理装置、112 CPU、117入力装置、118出力装置、
119、125入出力インタフェース(I/F)、120画像処理装置、
123プリンタエンジン、124 CPU、130 USBケーブル

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

該当するデータがありません

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

該当するデータがありません

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ