JP6075010B2 - 通信中継プログラム、及び、画像処理装置 - Google Patents

Description

通信を中継する技術に関する。

従来、画像処理装置にＷｅｂサーバ機能を備え、端末装置で実行されるＷｅｂブラウザに画像処理装置の設定画面などを表示する技術が開示されている（例えば特許文献１参照）。

また、画像処理装置と端末装置とをインターネットで接続し、インターネットを介して画像処理装置に画像を処理させるＩＰＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｉｎｔｉｎｇ Ｐｒｏｔｏｃｏｌ）と呼ばれる規格が知られている。
そして、画像処理装置と端末装置とがＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）によって接続されている環境において上述したＩＰＰによる通信を行うためのＩＰＰ ｏｖｅｒ ＵＳＢという規格のドラフト（２０１２年１０月３１日時点においてＶｅｒｓｉｏｎ １．０ Ｄｒａｆｔ ２０）が知られている。

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

ＩＰＰ ｏｖｅｒ ＵＳＢでは端末装置で通信中継プログラムが実行される。Ｗｅｂブラウザなどのクライアントアプリケーションは画像処理装置への処理要求を通信中継プログラムに送信し、通信中継プログラムはクライアントアプリケーションから受信した処理要求を画像処理装置に送信する。

この場合に、画像処理装置が通信中継プログラムから処理要求を受信している途中で何らかの事情によってクライアントアプリケーションと通信中継プログラムとの通信が途絶えてしまうと、クライアントアプリケーションから画像処理装置への処理要求が途中で途絶えてしまう。

しかしながら、画像処理装置はクライアントアプリケーションと通信中継プログラムとの通信が途絶えてしまっていることを認識することができない。このため、クライアントアプリケーションと通信中継プログラムとの通信が途中で途絶えてしまうと、画像処理装置において処理要求の受信待ち状態が長時間継続してしまうという問題がある。

本明細書では、画像処理装置とクライアントアプリケーションとの間で通信を中継する場合に、クライアントアプリケーションと通信中継プログラムとの間の通信が途中で途絶えてしまうことによって画像処理装置の受信待ち状態が長時間継続してしまうことを抑制する技術を開示する。

本明細書によって開示される通信中継プログラムは、画像処理装置と通信回線で接続されている情報処理装置で実行される通信中継プログラムであって、クライアントアプリケーションから処理要求を受信する第１の要求受信処理と、前記第１の要求受信処理による前記処理要求の受信中に、前記クライアントアプリケーションから通信の中止が通知されたか否かを判断する第１の中止判断処理と、前記第１の中止判断処理によって中止が通知されたと判断されることなく前記第１の要求受信処理による前記処理要求の受信が完了した場合は前記処理要求を前記画像処理装置に送信する一方、前記第１の中止判断処理によって中止が通知されたと判断された場合は前記処理要求を前記画像処理装置に送信しない第１の要求送信処理と、を前記情報処理装置に実行させる。

上記通信中継プログラムによると、クライアントアプリケーションからの処理要求の受信が完了した後でなければ画像処理装置への処理要求の送信を開始しないので、上記通信中継プログラムがクライアントアプリケーションから処理要求を受信している途中でクライアントアプリケーションから通信の中止が通知された場合は、画像処理装置への処理要求の送信が開始されない。
よって上記通信中継プログラムによると、画像処理装置とクライアントアプリケーションとの間で通信を中継する場合に、クライアントアプリケーションと通信中継プログラムとの間の通信が途中で途絶えてしまうことによって画像処理装置の受信待ち状態が長時間継続してしまうことを抑制することができる。

また、前記クライアントアプリケーションはマルチセッションによって通信するものであり、当該通信中継プログラムは、前記クライアントアプリケーションからセッションの確立を要求されると、その要求に応じて前記クライアントアプリケーションとの間に新たなセッションを確立する第１の確立処理と、前記第１の確立処理によって前記新たなセッションが確立されると、前記クライアントアプリケーションとの間に確立されている他のセッション以外のセッションによる通信が禁止されているか否かを判断する第１の禁止判断処理と、前記第１の禁止判断処理によって通信が禁止されていると判断された場合に、通信が解禁されるまで前記新たなセッションによる通信を待機する第１の待機処理と、前記第１の禁止判断処理によって通信が禁止されていないと判断された場合、又は、前記待機処理による待機が解除された場合に、前記新たなセッション以外のセッションによる通信を禁止する第１の排他処理と、前記新たなセッション以外のセッションによる通信を解禁する第１の解禁処理と、を前記情報処理装置に実行させ、前記第１の要求送信処理では、前記第１の排他処理によって前記新たなセッション以外のセッションによる通信を禁止した状態で、前記第１の要求受信処理により前記新たなセッションを介して受信した前記処理要求を前記画像処理装置に送信し、前記第１の解禁処理では、前記第１の中止判断処理によって中止が通知されたと判断されることなく前記第１の要求受信処理による前記処理要求の受信が完了した場合、及び、前記第１の中止判断処理によって中止が通知されたと判断された場合に、前記新たなセッション以外のセッションによる通信を解禁してもよい。

上記通信中継プログラムによると、いずれかのセッションを介して処理要求を中継している間は他のセッションによる通信を禁止するので、処理要求に対する応答が混乱してしまうことを抑制できる。また、中止が通知されたと判断された場合に、新たなセッション以外のセッションによる通信を解禁するので、通信が禁止されていたセッションを速やかに開始することができる。

本明細書によって開示される通信中継プログラムは、画像処理装置と通信回線で接続されている情報処理装置で実行される通信中継プログラムであって、クライアントアプリケーションから処理要求を受信する第２の要求受信処理と、前記第２の要求受信処理によって前記処理要求の受信が開始されると、当該処理要求の受信が完了するのを待つことなく前記画像処理装置への当該処理要求の送信を開始する第２の要求送信処理と、前記第２の要求受信処理による前記処理要求の受信中に、前記クライアントアプリケーションから通信の中止が通知されたか否かを判断する第２の中止判断処理と、前記第２の中止判断処理によって中止が通知されたと判断された場合に、前記画像処理装置に通信の中止を通知する第１の中止通知処理と、を前記情報処理装置に実行させる。

上記通信中継プログラムによると、クライアントアプリケーションから処理要求を受信している途中でクライアントアプリケーションから通信の中止が通知された場合は、画像処理装置に通信の中止を通知する。
よって上記通信中継プログラムによると、画像処理装置とクライアントアプリケーションとの間で通信を中継する場合に、クライアントアプリケーションと通信中継プログラムとの間の通信が途中で途絶えてしまうことによって画像処理装置の受信待ち状態が長時間継続してしまうことを抑制することができる。

また、前記クライアントアプリケーションはマルチセッションによって通信するものであり、当該通信中継プログラムは、前記クライアントアプリケーションからセッションの確立を要求されると、その要求に応じて前記クライアントアプリケーションとの間に新たなセッションを確立する第２の確立処理と、前記第２の確立処理によって前記新たなセッションが確立されると、前記クライアントアプリケーションとの間に確立されている他のセッション以外のセッションによる通信が禁止されているか否かを判断する第２の禁止判断処理と、前記第２の禁止判断処理によって通信が禁止されていると判断された場合に、通信が解禁されるまで前記新たなセッションによる通信を待機する第２の待機処理と、前記第２の禁止判断処理によって通信が禁止されていないと判断された場合、又は、前記待機処理による待機が解除された場合に、前記新たなセッション以外のセッションによる通信を禁止する第２の排他処理と、前記新たなセッション以外のセッションによる通信を解禁する第２の解禁処理と、を前記情報処理装置に実行させ、前記第２の要求送信処理では、前記第２の排他処理によって前記新たなセッション以外のセッションによる通信を禁止した状態で、前記第２の要求受信処理により前記新たなセッションを介して受信した前記処理要求を前記画像処理装置に送信し、前記第２の解禁処理では、前記第２の中止判断処理によって中止が通知されたと判断されることなく前記第２の要求受信処理による前記処理要求の受信が完了した場合、及び、前記第２の中止判断処理によって中止が通知されたと判断された場合に、前記新たなセッション以外のセッションによる通信を解禁してもよい。

上記通信中継プログラムによると、いずれかのセッションを介して処理要求を中継している間は他のセッションによる通信を禁止するので、処理要求に対する応答が混乱してしまうことを抑制できる。また、中止が通知されたと判断された場合に、新たなセッション以外のセッションによる通信を解禁するので、通信が禁止されていたセッションを速やかに開始することができる。

本明細書によって開示される通信中継プログラムは、画像処理装置と通信回線を介して通信可能に接続されている情報処理装置で実行される通信中継プログラムであって、マルチセッションによって通信するクライアントアプリケーションからセッションを確立する要求を受信すると、その要求に応じて前記クライアントアプリケーションとの間にセッションを確立する第３の確立処理と、前記第３の確立処理によって確立された前記セッションを介して前記クライアントアプリケーションから処理要求を受信する第３の要求受信処理と、前記第３の要求受信処理によって前記処理要求の受信が開始されると、当該処理要求の受信が完了するのを待つことなく前記画像処理装置への当該処理要求の送信を開始する第３の要求送信処理であって、当該処理要求を受信した前記セッションを識別するためのセッション情報を付加したセッション情報付き処理要求を前記画像処理装置に送信する第３の要求送信処理と、前記第３の要求送信処理によって送信された前記処理要求に対する応答として前記画像処理装置から前記セッション情報が付加されたセッション情報付き応答を受信する第１の応答受信処理と、前記第１の応答受信処理によって受信された前記セッション情報付き応答から前記セッション情報を除去した応答を、当該セッション情報によって識別される前記セッションを介して前記クライアントアプリケーションに送信する第１の応答送信処理と、前記第３の要求受信処理による前記処理要求の受信中に、前記クライアントアプリケーションから前記セッションを介して通信の中止が通知されたか否かを判断する第３の中止判断処理と、前記第３の中止判断処理によって中止が通知されたと判断された場合に、当該中止が通知された前記セッションの前記セッション情報を付加したセッション情報付き中止通知を前記画像処理装置に送信する第２の中止通知処理と、を前記情報処理装置に実行させる。

上記通信中継プログラムによると、画像処理装置とクライアントアプリケーションとの間で通信を中継する場合に、クライアントアプリケーションと通信中継プログラムとの間の通信が途中で途絶えてしまうことによって画像処理装置の受信待ち状態が長時間継続してしまうことをセッションの単位で抑制することができる。

また、上記通信中継プログラムは、前記第３の確立処理によって前記セッションが確立されると、確立された前記セッションのセッション識別子を生成する識別子生成処理と、前記識別子生成処理によって生成された前記セッション識別子と前記セッションを識別するための識別情報とを対応付けて記憶装置に記憶させる第１の記憶処理と、前記記憶装置に記憶されている前記セッション識別子と当該セッション識別子に対応付けられている前記識別情報とを前記記憶装置から削除する削除処理と、を前記情報処理装置に実行させ、前記第３の要求送信処理において、前記識別子生成処理によって生成された前記セッション識別子を前記セッション情報として前記処理要求に付加し、前記第１の応答送信処理において、前記セッション情報付き応答に前記セッション情報として付加されている前記セッション識別子に対応付けられている前記識別情報によって識別される前記セッションを介して前記クライアントアプリケーションに前記応答を送信し、前記削除処理において、前記第３の中止判断処理によって中止が通知されたと判断された場合に、当該中止が通知された前記セッションの前記セッション識別子と前記識別情報とを前記記憶装置から削除してもよい。

上記通信中継プログラムによると、クライアントアプリケーションと通信中継プログラムとの間の通信が途中で途絶えてしまうことによって画像処理装置の受信待ち状態が長時間継続してしまうことをセッションの単位で抑制することができる。

また、上記通信中継プログラムは、前記第１の応答送信処理において、前記セッション情報付き応答に前記セッション情報として付加されている前記セッション識別子が前記記憶装置に記憶されていない場合は、前記クライアントアプリケーションに前記応答を送信しないようにしてもよい。

上記通信中継プログラムによると、クライアントアプリケーションへの無駄な応答の送信を抑制できる。

また、前記通信回線はユニバーサルシリアルバスであってもよい。

上記通信中継プログラムによると、画像処理装置と情報処理装置とがユニバーサルシルアルバスを介して通信可能に接続されている場合に、クライアントアプリケーションと通信中継プログラムとの間の通信が途中で途絶えてしまうことによって画像処理装置の受信待ち状態が長時間継続してしまうことを抑制することができる。

本明細書によって開示される画像処理装置は、情報処理装置と通信回線を介して通信する第１の通信部と、第１の処理部と、前記第１の処理部から受信した処理要求に対する応答を前記第１の処理部に送信する第１の応答部と、を備え、前記第１の処理部は、前記情報処理装置から処理要求を受信する第４の要求受信処理と、前記第４の要求受信処理によって前記処理要求の受信が開始されると、前記第１の応答部との間に通信を確立する第４の確立処理と、前記第４の確立処理によって確立された前記通信を介して前記第１の応答部に前記処理要求を送信する第４の要求送信処理と、前記第４の要求送信処理によって送信された前記処理要求に対する応答を前記第１の応答部から受信する第２の応答受信処理と、前記第２の応答受信処理によって受信した前記応答を前記情報処理装置に送信する第２の応答送信処理と、前記第４の要求受信処理による前記処理要求の受信中に、前記情報処理装置から通信の中止が通知されたか否かを判断する第４の中止判断処理と、前記第４の中止判断処理によって中止が通知されたと判断された場合に、前記第４の確立処理によって確立された前記通信を終了させる第１の終了処理と、を実行する。

上記画像処理装置によると、第１の処理部と、第１の処理部から受信した処理要求に対する応答を第１の処理部に送信する第１の応答部とを備える画像処理装置において、クライアントアプリケーションと通信中継プログラムとの間の通信が途中で途絶えてしまうことによって第１の応答部の受信待ち状態が長時間継続してしまうことを抑制することができる。

また、前記第１の処理部は、前記情報処理装置から受信した前記処理要求を前記第１の応答部に送信した後、前記情報処理装置に前記応答を送信する前に前記情報処理装置から通信の中止が通知された場合は、前記第２の応答送信処理において、前記第１の応答部から送信された前記応答を前記情報処理装置に送信しないようにしてもよい。

上記画像処理装置によると、クライアントアプリケーションと通信中継プログラムとの間の通信が途中で途絶えてしまったにもかかわらず画像処理装置が情報処理装置に応答を送信しようとしてしまうことを抑制することができる。

本明細書によって開示される画像処理装置は、情報処理装置と通信回線を介して通信する第２の通信部と、第２の処理部と、前記第２の処理部から受信した処理要求に対する応答を前記第２の処理部に送信する第２の応答部と、記憶部と、を備え、前記第２の処理部は、前記情報処理装置からセッション情報付き処理要求を受信する第５の要求受信処理と、前記第５の要求受信処理によって前記セッション情報付き処理要求が受信されると、当該セッション情報付き処理要求に付加されているセッション情報が、当該第２の処理部と前記第２の応答部との間に確立されている通信を識別するための通信識別情報に対応付けられて前記記憶部に記憶されているか否かを判断する記憶判断処理と、前記記憶判断処理によって前記セッション情報が記憶されていないと判断された場合に、前記第２の応答部との間に新たな通信を確立する第５の確立処理と、前記第５の確立処理によって確立された前記通信を識別するための通信識別情報と前記セッション情報とを対応付けて前記記憶部に記憶させる第２の記憶処理と、前記記憶判断処理によって前記セッション情報が記憶されていると判断された場合は、前記セッション情報付き処理要求から前記セッション情報を除去した処理要求を、当該セッション情報に対応付けられて前記記憶部に記憶されている前記通信識別情報によって識別される前記通信を介して前記第２の応答部に送信する一方、前記記憶判断処理によって前記セッション情報が記憶されていないと判断された場合は、前記セッション情報付き処理要求から前記セッション情報を除去した処理要求を、前記第５の確立処理によって確立された前記新たな通信を介して前記第２の応答部に送信する第５の要求送信処理と、前記通信を介して前記第２の応答部に送信した前記処理要求に対する応答を、当該通信を介して前記第２の応答部から受信する第３の応答受信処理と、前記第３の応答受信処理によって受信された前記応答に当該応答を受信した前記通信の前記通信識別情報に対応付けられて前記記憶部に記憶されている前記セッション情報を付加したセッション情報付き応答を前記情報処理装置に送信する第３の応答送信処理と、前記第５の要求受信処理による前記処理要求の受信中に、前記情報処理装置からセッション情報付き中止通知を受信したか否かを判断する第５の中止判断処理と、前記第５の中止判断処理によって前記セッション情報付き中止通知を受信したと判断された場合に、当該セッション情報付き中止通知に付加されている前記セッション情報に対応付けられている前記通信識別情報によって識別される前記通信を終了させる第２の終了処理と、を実行する。

上記画像処理装置によると、第２の処理部と、第２の処理部から受信した処理要求に対する応答を第２の処理部に送信する第２の応答部とを備え、第２の処理部と第２の応答部とがマルチセッションによって通信する画像処理装置において、情報処理装置と画像処理装置との間の通信が途中で途絶えてしまうことによって第２の応答部の受信待ち状態が長時間継続してしまうことを抑制することができる。

また、前記第２の処理部は、前記第３の応答受信処理による前記応答の受信中に、前記情報処理装置からセッション情報付き中止通知を受信したか否かを判断する第６の中止判断処理と、前記第６の中止判断処理によって前記セッション情報付き中止通知を受信したと判断された場合に、当該セッション情報付き中止通知に付加されている前記セッション情報に対応付けられて前記記憶部に記憶されている前記通信識別情報によって識別される前記通信を終了させる第３の終了処理と、を実行してもよい。

上記画像処理装置によると、第２の応答部から応答を受信している途中で情報処理装置から通信の中止が通知された場合に、第２の応答部の送信待ち状態が長時間継続してしまうことを抑制することができる。

なお、本明細書によって開示される技術は、画像処理システム、通信中継装置、通信中継方法、通信中継プログラムを記録した記録媒体等の種々の態様で実現することができる。

上記通信中継プログラムによると、画像処理装置とクライアントアプリケーションとの間で通信を中継する場合に、クライアントアプリケーションと通信中継プログラムとの間の通信が途中で途絶えてしまうことによって画像処理装置の受信待ち状態が長時間継続してしまうことを抑制することができる。

実施形態１に係るＰＣ及びプリンタの電気的構成を示すブロック図。 ＰＣのプログラム構成、及び、プリンタの機能を示すブロック図。 プリンタの設定画面の一例を示す模式図。 通信中継処理の全体的な流れを示すシーケンスチャート。 スレッド生成処理のフローチャート。 Ｗｅｂブラウザから処理要求を受信する処理のフローチャート。 実施形態２に係るＷｅｂブラウザから処理要求を受信する処理のフローチャート。 ＩＰＰ／ＵＳＢ変換プログラムから処理要求を受信する処理のフローチャート。 ＩＰＰ／ＵＳＢ変換プログラムからキャンセル通知を受信したときの処理のフローチャート。 実施形態３に係る通信中継処理の全体的な流れを示すシーケンスチャート。 Ｗｅｂブラウザから処理要求を受信する処理のフローチャート。 付加データ送信処理のフローチャート（その１）。 付加データ送信処理のフローチャート（その２）。 ＩＰＰ機能から応答を受信する処理のフローチャート。 ＩＰＰ／ＵＳＢ変換プログラムから処理要求を受信する処理のフローチャート。 キャンセル処理のフローチャート。 Ｗｅｂサーバ機能から応答を受信する処理のフローチャート。

＜実施形態１＞
実施形態１を図１ないし図６によって説明する。
（１）画像処理システム
先ず、図１を参照して、実施形態１に係る画像処理システム１について説明する。画像処理システム１はパーソナルコンピュータ（ＰＣと記す）２とプリンタ３とで構成されている。ＰＣ２とプリンタ３とはＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ、ユニバーサルシリアルバス）ケーブル４によって通信可能に接続されている。また、プリンタ３はＵＳＢプリンタクラスデバイスとして構成されている。
ＰＣ２は情報処理装置及び通信中継装置の一例である。プリンタ３は画像処理装置の一例である。また、ＵＳＢは通信回線の一例である。

ＰＣ２はプリンタ３との間でＵＳＢを介して少なくとも以下の二つの通信（ａ）及び（ｂ）を行うことができる。
（ａ）プリンタ３を設定するための通信
（ｂ）プリンタ３に印刷データを送信するための通信
これらの通信はＩＰＰ ｏｖｅｒ ＵＳＢ規格（２０１２年１０月３１日時点においてＶｅｒｓｉｏｎ １．０ Ｄｒａｆｔ ２０）に従って行われる。ＩＰＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｉｎｔｉｎｇ Ｐｒｏｔｏｃｏｌ）とは、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）をベースにした規格であって、インターネットやＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）などのＴＣＰ／ＩＰネットワークを介してプリンタと通信するための規格である。

ＩＰＰ ｏｖｅｒ ＵＳＢはＵＳＢによって接続されている環境において上述したＩＰＰによる通信を実現するための規格である。ＩＰＰ ｏｖｅｒ ＵＳＢではＩＰＰの通信データがＵＳＢのパケットに格納されて送受信される。

（１−１）ＰＣの電気的構成
図１を参照して、ＰＣ２の電気的構成について説明する。ＰＣ２は、ＣＰＵ２０、ＲＯＭ２１、ＲＡＭ２２、表示部２３、操作部２４、記憶部２５、及び、ＵＳＢホストインタフェース部（図１ではＵＳＢホストＩＦ部と記す）２６を備えて構成されている。

ＣＰＵ２０はＲＯＭ２１や記憶部２５に記憶されているプログラムを実行することによってＰＣ２の各部を制御する。ＲＯＭ２１にはＣＰＵ２０によって実行されるプログラムやデータなどが記憶されている。ＲＡＭ２２はＣＰＵ２０が各種の処理を実行するための主記憶装置として用いられる。
表示部２３は、液晶ディスプレイなどの表示装置、表示装置を駆動するディスプレイ駆動回路などを備えて構成されている。
操作部２４は、キーボードやマウス、それらが接続されるインタフェースなどで構成されている。

記憶部２５は、ハードディスクやフラッシュメモリなどの不揮発性のメモリを用いて各種のプログラムやデータを記憶する装置である。記憶部２５には、オペレーティングシステム（ＯＳと記す）４１、Ｗｅｂブラウザ４２、ＩＰＰ／ＵＳＢ変換プログラム４３などのプログラムが記憶されている。これらのプログラムはＣＰＵ２０によって実行される。
Ｗｅｂブラウザ４２はマルチセッションによって通信が可能なクライアントアプリケーションの一例である。また、ＩＰＰ／ＵＳＢ変換プログラム４３は通信中継プログラムの一例である。

ＵＳＢホストインタフェース部２６は、ＵＳＢホストコントローラ、ＵＳＢケーブル４が接続されるジャックなどを備えて構成されており、ＵＳＢケーブル４を介してプリンタ３と通信可能に接続されている。

（１−２）プリンタ
次に、図１を参照して、プリンタ３の電気的構成について説明する。プリンタ３は、制御部３１、ＵＳＢクライアントインタフェース部（図１ではＵＳＢクライアントＩＦ部と記す）３２、印刷部３３、操作部３４、及び、記憶部３５を備えて構成されている。

制御部３１は、ＣＰＵ３１ａ、ＲＯＭ３１ｂ、ＲＡＭ３１ｃなどを備えて構成されている。ＣＰＵ３１ａはＲＯＭ３１ｂや記憶部３５に記憶されている制御プログラムを実行することによってプリンタ３の各部を制御する。ＲＯＭ３１ｂにはＣＰＵ３１ａによって実行される制御プログラムや各種のデータなどが記憶されている。ＲＡＭ３１ｃはＣＰＵ３１ａが各種の処理を実行するための主記憶装置として用いられる。ＣＰＵは第１の処理部、第２の処理部、第１の応答部、及び、第２の応答部の一例である。

印刷部３３は、印刷用紙などのシートに電子写真方式やインクジェット方式などで画像を印刷する装置である。
操作部３４は、液晶ディスプレイなどの表示装置や各種の操作ボタンなどを備えて構成されている。
記憶部３５は、ハードディスクやフラッシュメモリなどの不揮発性のメモリを用いて各種のデータを記憶する装置である。
ＵＳＢクライアントインタフェース部３２は、ＵＳＢケーブル４が接続されるジャックなどを備えて構成されており、ＵＳＢケーブル４を介してＰＣ２と通信可能に接続されている。

また、プリンタ３はこの他に印刷用紙が収容される第１のトレイ、及び、第２のトレイを備えている。

（２）ＰＣのプログラム構成、及び、プリンタの機能
次に、図２を参照して、ＩＰＰ ｏｖｅｒ ＵＳＢによって通信を行うためのＰＣ２のプログラム構成、及び、プリンタ３の機能について説明する。

（２−１）ＰＣのプログラム構成
先ず、ＰＣ２のプログラム構成について説明する。ＰＣ２は、ＩＰＰ／ＵＳＢ変換プログラム４３、Ｗｅｂブラウザ４２、及び、スプーラ４４を実行する。
ＩＰＰ／ＵＳＢ変換プログラム４３は、Ｗｅｂブラウザ４２とプリンタ３のＩＰＰ機能５１との間でプリンタ３を設定するための通信（ａ）を中継するとともに、スプーラ４４とＩＰＰ機能５１との間でプリンタ３に印刷データを送信するための通信（ｂ）を中継するプログラムである。

ＩＰＰ／ＵＳＢ変換プログラム４３はｈｔｔｐ://ｌｏｃａｌｈｏｓｔ:８０に対するサーバープログラムとして常駐している。ｌｏｃａｌｈｏｓｔはＰＣ２のＩＰアドレスであって、具体的には例えば１２７．０．０．１である。また８０は使用するポート番号である。なおポート番号８０は通常省略される。ＩＰＰ／ＵＳＢ変換プログラム４３はＷｅｂブラウザ４２とＨＴＴＰによって通信するとともに、スプーラ４４とＩＰＰによって通信する。
また、ＩＰＰ／ＵＳＢ変換プログラム４３はＩＰＰ機能５１とＵＳＢを介して通信する。ＩＰＰ／ＵＳＢ変換プログラム４３の詳細については後述する。

Ｗｅｂブラウザ４２はユーザがプリンタ３の設定をするためのユーザインタフェースとして用いられるものである。Ｗｅｂブラウザ４２としては一般に利用されているものを用いることができる。
ＰＣ２とプリンタ３とがＵＳＢによって接続されている環境では、Ｗｅｂブラウザ４２はｌｏｃａｌｈｏｓｔ（１２７．０.０．１）のポート８０に、プリンタ３の設定画面６０（図３参照）を表示するための画面データの送信を要求するＨＴＴＰリクエストや、設定画面６０上に表示する画像の送信を要求するＨＴＴＰリクエストなどを送信する。これらのＨＴＴＰリクエストはそれぞれ処理要求の一例である。以降の説明ではＨＴＴＰリクエストを単に処理要求という。
なお、処理要求はこれらに限られるものではない。例えばユーザが設定画面６０で設定した設定値をプリンタ３に設定するＨＴＴＰリクエスト（ＰＵＴコマンドやＰＯＳＴコマンドなど）も処理要求の一例である。
ＩＰＰ／ＵＳＢ変換プログラム４３はＷｅｂブラウザ４２から処理要求を受信すると、ＵＳＢを介してＩＰＰ機能５１にその処理要求を送信する。

ここで、画面データはＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）やＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）によって記述されているものとする。詳しくは後述するが、画面データはプリンタ３のＷｅｂサーバ機能５２が設定画面ＣＧＩ（Ｃｏｍｍｏｎ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃｅ ）を実行することによって生成される。

スプーラ４４は印刷データをスプールするプログラムである。スプーラ４４はＯＳ４１の一部として提供される。ＰＣ２とプリンタ３とがＵＳＢによって接続されている環境では、スプーラ４４はＩＰＰ／ＵＳＢ変換プログラム４３とＩＰＰによって通信することにより、ＩＰＰ／ＵＳＢ変換プログラム４３に印刷データを送信する。
ＩＰＰ／ＵＳＢ変換プログラム４３はスプーラ４４から印刷データを受信すると、ＵＳＢを介してプリンタ３のＩＰＰ機能５１にその印刷データを送信する。

なお、Ｗｅｂブラウザ４２及びスプーラ４４はＰＣ２で実行されてもよいし、ＰＣ２と通信可能に接続されている外部の通信端末５で実行されてもよい。

（２−２）プリンタの機能
次に、プリンタ３の機能について説明する。プリンタ３は、印刷部３３、ＩＰＰ機能５１、及び、Ｗｅｂサーバ機能５２を備えている。
ＩＰＰ機能５１はプリンタ３の制御部３１が制御プログラムを実行することによって実現される機能である。ＩＰＰ機能５１はＩＰＰ／ＵＳＢ変換プログラム４３とＵＳＢを介して通信する。また、ＩＰＰ機能５１はＷｅｂサーバ機能５２とＨＴＴＰによって通信するとともに、印刷部３３と所定のプロトコルに従って通信する。

Ｗｅｂサーバ機能５２もプリンタ３の制御部３１が制御プログラムを実行することによって実現される。Ｗｅｂサーバ機能５２は画面データの送信が要求されると設定画面ＣＧＩを実行して設定画面６０を表示するための画面データを生成する処理や、設定画面６０で設定された設定値を受信するとプリンタ設定ＣＧＩを実行してプリンタ３にその設定値を設定する処理などを実行する。

（３）ＵＳＢにおけるインタフェース
次に、ＵＳＢにおけるインタフェースについて説明する。ＵＳＢでは物理的に一本のＵＳＢケーブル４にインタフェースと呼ばれる１以上の論理的な通信回線が構成される。

ＵＳＢではコントロール転送を行うためのエンドポイント０と呼ばれる特殊なエンドポイントが必ず構成される。エンドポイント０は双方向通信が可能なエンドポイントである。インタフェースはエンドポイント０を介してプリンタ３から取得されるインタフェースディスクリプタに従って構成される。各インタフェースは通常１ないし複数のエンドポイントを有する。

本実施形態のプリンタ３ではエンドポイント０を用いたインタフェース０の他に、インタフェース１及びインタフェース２が構成されるものとする。さらに、インタフェース１及びインタフェース２はそれぞれリード用エンドポイントおよびライト用エンドポイントを有し、それらを使用することにより双方向通信を実現している。

そして、前述したプリンタ３を設定するための通信（ａ）はインタフェース１を用いて行われ、プリンタ３に印刷データを送信するための通信（ｂ）はインタフェース２を用いて行われるものとする。
なお、インタフェース２を構成せず、プリンタ３を設定するための通信（ａ）、及び、プリンタ３に印刷データを送信するための通信（ｂ）をどちらもインタフェース１を用いて行ってもよい。

（４）セッションの排他処理
次に、Ｗｅｂブラウザ４２とＩＰＰ／ＵＳＢ変換プログラム４３との間に確立されるセッションの排他処理について説明する。ここではプリンタ３を設定するための通信（ａ）を例に説明する。

先ず、図３を参照して、プリンタ３の設定画面６０について説明する。図３に示す設定画面６０では、プリンタ言語６１ａ、第１のトレイにセットされている用紙サイズ６１ｂ、及び、第２のトレイにセットされている用紙サイズ６１ｃを設定することができる。
また、設定画面６０には画像６２ａ、画像６２ｂ、画像６２ｃが表示される。ここでは画像６２ａ〜画像６２ｃをそれぞれＧＩＦ１、ＧＩＦ２、ＧＩＦ３というものとする。

Ｗｅｂブラウザ４２はｌｏｃａｌｈｏｓｔのポート８０にセッションの確立を要求し、確立されたセッションを介してＩＰＰ／ＵＳＢ変換プログラム４３に設定画面６０の画面データの送信を要求する。この要求はＧＥＴコマンドを送信することによって行われる。

上述したＧＥＴコマンドはＩＰＰ／ＵＳＢ変換プログラム４３によってＵＳＢを介してＩＰＰ機能５１に送信され、ＩＰＰ機能５１からＷｅｂサーバ機能５２に送信される。Ｗｅｂサーバ機能５２はＧＥＴコマンドを受信すると設定画面ＣＧＩを実行して設定画面６０の画面データを生成する。そして、Ｗｅｂサーバ機能５２は上述したＧＥＴコマンドに対する応答として、設定画面ＣＧＩによって生成された画面データをＩＰＰ機能５１に送信する。

ＩＰＰ機能５１はＷｅｂサーバ機能５２から画面データを受信すると、ＵＳＢを介してその画面データをＩＰＰ／ＵＳＢ変換プログラム４３に送信する。
ＩＰＰ／ＵＳＢ変換プログラム４３はＩＰＰ機能５１から画面データを受信すると、Ｗｅｂブラウザ４２から受信したＧＥＴコマンドに対する応答としてその画面データをＷｅｂブラウザ４２に送信する。
Ｗｅｂブラウザ４２はこの画面データを解析し、ページを表示するに足りない部品（ＧＩＦ１、ＧＩＦ２、ＧＩＦ３など）を同様に要求する。この場合に、Ｗｅｂブラウザ４２はマルチセッションによる通信が可能であるので、足りない部品（ＧＩＦ１、ＧＩＦ２、ＧＩＦ３）毎にセッションを確立して画像の送信を要求する。

例えば、Ｗｅｂブラウザ４２は最初にＧＩＦ１の送信を要求するためのセッションの確立を要求し、そのセッションを介して送信した処理要求に対する応答を待たずに、ＧＩＦ２の送信を要求するためのセッションの確立を要求する。同様に、Ｗｅｂブラウザ４２はＧＩＦ２の送信を要求するためのセッションを介して送信した処理要求に対する応答を待たずに、ＧＩＦ３の送信を要求するためのセッションの確立を要求する。

しかしながら、ＵＳＢのインタフェースにはマルチセッションの概念がない。また、ＩＰＰ機能５１は必ずしもＧＥＴコマンドの順に応答を返すわけではなく、その返す順序は不定である。
このため、各セッションがインタフェース１を介して通信すると、ＩＰＰ／ＵＳＢ変換プログラム４３がＩＰＰ機能５１から応答を受信したとき、ＩＰＰ／ＵＳＢ変換プログラム４３はその応答がいずれのセッションを介して受信した処理要求に対する応答であるかを判断できない。このため、あるセッションに対する応答が別のセッションに送信されてしまうなどのような混乱が起こり得る。
そこで、実施形態１に係るＩＰＰ／ＵＳＢ変換プログラム４３は、排他処理を実行することにより、同時に一のセッションのみを介して通信を中継する。

（５）通信の全体的な流れ
図４を参照して、通信の全体的な流れについて説明する。ここではプリンタ３を設定するための通信（ａ）を例に説明する。前述したようにプリンタ３を設定するための通信（ａ）はインタフェース１を用いて行われる。

また、ここではＷｅｂブラウザ４２は既にＩＰＰ／ＵＳＢ変換プログラム４３から設定画面６０の画面データを受信して解析が完了しているものとし、ＩＰＰ／ＵＳＢ変換プログラム４３にＧＩＦ１、ＧＩＦ２、及び、ＧＩＦ３の送信を要求するところから説明を始める。
また、ここではＩＰＰ機能５１とＷｅｂサーバ機能５２とをまとめてプリンタ３というものとする。

Ｗｅｂブラウザ４２は、先ずＩＰＰ／ＵＳＢ変換プログラム４３にセッション１の確立を要求する。ＩＰＰ／ＵＳＢ変換プログラム４３はセッション１の確立が要求されると、Ｗｅｂブラウザ４２との間にセッション１を確立する（Ｓ１０１）とともに、セッション１以外のセッションによる通信を禁止する。そして、ＩＰＰ／ＵＳＢ変換プログラム４３はセッション１を介してＷｅｂブラウザ４２とＩＰＰ機能５１との間で通信を中継する（Ｓ１０２、Ｓ１０３、Ｓ１０５、Ｓ１０６）。ここでは、上述したＷｅｂブラウザ４２がＧＩＦ１を要求してから受信するまでの通信が行われる。

Ｗｅｂブラウザ４２は、セッション１の確立を要求した後、セッション１によってＧＩＦ１が受信されるのを待つことなくセッション２の確立を要求する。ＩＰＰ／ＵＳＢ変換プログラム４３はセッション２の確立が要求されると、Ｗｅｂブラウザ４２との間にセッション２を確立する（Ｓ１０４）。しかしながら、セッション１以外の通信は禁止されているので、セッション２は待機状態となる。

ＩＰＰ／ＵＳＢ変換プログラム４３は、セッション１による通信の中継が完了すると（Ｓ１０６）、セッション１以外のセッションによる通信を解禁する。これによりセッション２の待機状態が解除される。ＩＰＰ／ＵＳＢ変換プログラム４３はセッション２の待機状態が解除されるとセッション２を介してＷｅｂブラウザ４２とＩＰＰ機能５１との間で通信を中継する（Ｓ１０７、Ｓ１０８、Ｓ１１０、Ｓ１１１）。

セッション３についても同様であり、セッション２でＷｅｂブラウザ４２がＧＩＦ２を受信するまで待機し、ＧＩＦ２の受信が完了すると通信を開始する。
これら一連の処理によってＧＩＦ１〜ＧＩＦ３がＷｅｂブラウザ４２に読み込まれ、設定画面６０上にＧＩＦ１〜ＧＩＦ３が表示される。

設定画面６０に対する操作は、ＨＴＴＰのＧＥＴコマンド、ＰＵＴコマンド、ＰＯＳＴコマンドなどの処理要求に変更されて同様にＩＰＰ／ＵＳＢ変換プログラム４３を介してプリンタ３に送信される。これにより、従来のＴＣＰ／ＩＰネットワークを介してプリンタ３の設定を行うのと同様の手順でＵＳＢを介してプリンタ３の設定を行うことができる。

（６）処理要求のデータ構造、及び、応答のデータ構造
次に、上述した処理要求のデータ構造、及び、処理要求に対してプリンタ３から送信される応答のデータ構造について説明する。

（６−１）処理要求のデータ構造
先ず、処理要求のデータ構造について説明する。ここではＰＯＳＴコマンドを例に説明する。処理要求のデータ構造はＨＴＴＰの仕様に準拠するものであり、広く用いられているものであるのでここではその概略のみを説明する。処理要求は１以上の通信データからなる。以下に処理要求の一例を示す。ここでは各通信データの前に行番号を［］で括って示す。

［１行目］ＰＯＳＴ ／ｉｐｐ／［ｆｕｎｃｔｉｏｎ］ ＨＴＴＰ／１．１＜ＣＲＬＦ＞
［２行目］Ｈｏｓｔ： ｌｏｃａｌｈｏｓｔ＜ＣＲＬＦ＞
［３行目］Ｃｏｎｔｅｎｔ−Ｔｙｐｅ： ａｐｐｌｉｃａｔｉｏｎ／ｉｐｐ＜ＣＲＬＦ＞
［４行目］Ｔｒａｎｓｆｅｒ−Ｅｎｃｏｄｉｎｇ： ｃｈｕｎｋｅｄ＜ＣＲＬＦ＞
［５行目］＜ＣＲＬＦ＞

上述した例において各行はそれぞれ一つの通信データを表している。また、上述した例から明らかなように各通信データは最後が＜ＣＲＬＦ＞で終わっている。＜ＣＲＬＦ＞は復帰改行コードである。
また、５行目に示すように処理要求の最後の通信データは＜ＣＲＬＦ＞のみである。従って、受信した通信データが＜ＣＲＬＦ＞のみである場合は一つの処理要求の受信が完了したと判断することができる。

なお、ＰＵＴコマンドやＰＯＳＴコマンドでは通常この一連の通信データの他にバイナリデータあるいはテキストデータなどの付加データが付加される。ここでは付加データも含んで処理要求という。
全ての付加データのバイト数が予めわからない場合はＴｒａｎｓｆｅｒ−Ｅｎｃｏｄｉｎｇ： ｃｈｕｎｋｅｄなどの形で細切れのデータ塊が続くことが処理要求中に示される。この場合、データ塊ごとのサイズが示される。
また、付加データが付加される場合は上述したｃｈｕｎｋｅｄに替えてＣｏｎｔｅｎｔ-Ｌｅｎｇｔｈ: ４５５４といった行が処理要求に挿入され、指定されたバイト数（この場合は４５５４）の付加データが続くことが示される場合もある。

各通信データ、付加データ、あるいは付加データを細切れにした各データ塊はそれぞれ部分処理要求データの一例である。つまり、ＩＰＰ／ＵＳＢ変換プログラム４３はＷｅｂブラウザ４２から処理要求を複数の部分処理要求データに分けて受信する。
なお、部分処理要求データは、処理の仕方によりいろいろな形態が考えられる。例えば固定長、あるいは特定の条件によってきまるデータ長ごとに受信し、それぞれを部分処理要求データとすることもできる。
（６−２）応答のデータ構造
応答のデータ構造もＨＴＴＰの仕様に準拠するものであり、広く用いられているものであるのでここではその概略のみを説明する。応答も１以上の通信データからなり、最後の通信データは＜ＣＲＬＦ＞のみである。またＧＥＴコマンドに対する応答にあっては、処理要求の場合と同様にバイナリデータやテキストデータなどの付加データが付加される。例えば前述したＧＩＦ１〜ＧＩＦ３はＧＥＴコマンドに対する応答に付加される付加データである。

各通信データ、付加データ、あるいは付加データを細切れにした各データ塊はそれぞれ部分応答データの一例である。つまり、ＩＰＰ／ＵＳＢ変換プログラム４３はＩＰＰ機能５１から応答を複数の部分応答データに分けて受信する。なお、部分応答データは処理の仕方によりいろいろな形態が考えられる。

（７）通信中継処理の課題
上述したようにＩＰＰ／ＵＳＢ変換プログラム４３はＷｅｂブラウザ４２から処理要求を複数の部分処理要求データに分けて受信する。この場合、ＩＰＰ／ＵＳＢ変換プログラム４３は全ての部分処理要求データの受信が完了するのを待つことなく、先に受信した部分処理要求データから順にＩＰＰ機能５１に送信することもできる。

しかしながら、ＩＰＰ／ＵＳＢ変換プログラム４３が全ての部分処理要求データをＩＰＰ機能５１に送信する前に、何らかの理由によってＷｅｂブラウザ４２とＩＰＰ／ＵＳＢ変換プログラム４３との間の通信が途中で途絶えてしまう場合がある。例えばユーザがＷｅｂブラウザ４２の中止ボタンをクリックしたり、あるいはＷｅｂブラウザ４２を終了させたりすることによって通信が途絶えてしまう場合がある。この場合、従来はＷｅｂブラウザ４２とＩＰＰ／ＵＳＢ変換プログラム４３との間の通信が途中で途絶えたことをＩＰＰ機能５１に通知する仕組みは考慮されていなかった。よって、ＩＰＰ機能５１はＷｅｂブラウザ４２とＩＰＰ／ＵＳＢ変換プログラム４３との間の通信が途絶えてしまったことを認識することができない。

このため、先に受信した部分処理要求データから順にＩＰＰ機能５１に送信すると、ＩＰＰ機能５１が全ての部分処理要求データの受信を完了する前にＷｅｂブラウザ４２とＩＰＰ／ＵＳＢ変換プログラム４３との間の通信が途絶えたとしても、ＩＰＰ機能５１は次の部分処理要求データを受信しようとして受信待ち状態が長時間継続してしまう。

そこで、実施形態１に係るＩＰＰ／ＵＳＢ変換プログラム４３は、上述した通信中継処理において、Ｗｅｂブラウザ４２からの処理要求の受信が完了した後にＩＰＰ機能５１への当該処理要求の送信を開始する。以下、通信中継処理の詳細について説明する。
（８）ＩＰＰ／ＵＳＢ変換プログラム４３による通信中継処理の詳細
通信中継処理では、ＩＰＰ／ＵＳＢ変換プログラム４３は次に説明するスレッド生成処理、及び、Ｗｅｂブラウザから処理要求を受信する処理を実行する。
（８−１）スレッド生成処理
先ず、図５を参照して、スレッド生成処理について説明する。前述したようにＩＰＰ／ＵＳＢ変換プログラム４３は常駐プログラムとして実行されるものであり、本処理はＰＣ２に電源が投入されると開始される。
ここで、本処理はＷｅｂブラウザ４２とＩＰＰ機能５１との間で通信を中継する処理であり、スプーラ４４とＩＰＰ機能５１との間で通信を中継する処理は本処理とは別の処理として実行されるものとする。当該別の処理についての説明は省略する。

Ｓ１０１では、ＩＰＰ／ＵＳＢ変換プログラム４３はセッションの排他処理を行うためのミューテックスを生成する。ミューテックスは排他処理を行うための仕組みであって、プログラム言語によって提供される仕組みである。ミューテックスの詳細については後述する。
なお、ここではミューテックスを用いて排他処理を行う場合を例に説明するが、排他処理を行う方法はこれに限られない。例えばセマフォを用いて行ってもよいし、ミューテックスやセマフォを用いず独自の方法で行ってもよい。

Ｓ１０２では、ＩＰＰ／ＵＳＢ変換プログラム４３はセッションを確立する要求（アクセプト要求という）を監視するソケットの生成及び設定を行う。ソケットとはＴＣＰ／ＩＰによって通信を行うための抽象化されたインタフェースのことをいう。また、ソケットの設定とは、ソケットにＰＣ２のＩＰアドレスや監視対象の通信ポートを示すポート番号などを設定し、そのソケットの動作モードをアクセプト要求の監視モードにすることをいう。本実施形態ではＩＰアドレスとして１２７．０．０．１が設定され、ポート番号として８０が設定される。
ユーザがＷｅｂブラウザ４２を立ち上げ、ＩＰアドレスとして１２７．０．０．１、ポート番号として８０を設定すると、Ｗｅｂブラウザ４２は当該アドレスおよびポート番号に対して通信の確立を要求する。この要求がアクセプト要求となる。

Ｓ１０３では、ＩＰＰ／ＵＳＢ変換プログラム４３はＷｅｂブラウザ４２からアクセプト要求を受信するまで待機し、アクセプト要求を受信するとＳ１０４に進む。
Ｓ１０４では、ＩＰＰ／ＵＳＢ変換プログラム４３はスレッドを生成する。
Ｓ１０５では、ＩＰＰ／ＵＳＢ変換プログラム４３はＯＳ４１から終了要求があったか否かを判断する。この終了要求はこの常駐プログラムであるＩＰＰ／ＵＳＢ変換プログラム４３の終了を要求するものである。ＩＰＰ／ＵＳＢ変換プログラム４３は常駐プログラムであるので通常は「否」であるが、ユーザの操作等によりプログラムの終了が指示されると終了要求を受ける。ＩＰＰ／ＵＳＢ変換プログラム４３は、終了要求があった場合は本処理を終了し、なかった場合はＳ１０３に戻って処理を繰り返す。

（８−２）Ｗｅｂブラウザから処理要求を受信する処理
次に、図６を参照して、ＩＰＰ／ＵＳＢ変換プログラム４３がＷｅｂブラウザ４２から処理要求を受信する処理について説明する。この処理は前述したＳ１０４で生成されたスレッドによって実行される。すなわち、アクセプト要求が複数ある場合は、それぞれ別のスレッドとしてこの処理は実行される。従って図６のフローチャートの中で扱うセッションは１つのみであり、複数のセッションがある場合は、別々のスレッドにより図６のフローチャートの処理が並行して行われることになる。

Ｓ２０１では、スレッドはアクセプト処理を実行する。アクセプト処理とは、アクセプト要求を送信してきた相手（すなわちＷｅｂブラウザ４２）との間に新たなセッションを確立する処理である。Ｓ２０１は第１の確立処理の一例である。
具体的には、スレッドはＷｅｂブラウザ４２と通信を行うための新たなソケットを生成し、生成したソケットを用いてＷｅｂブラウザ４２との間にセッションを確立する。なお、ソケットのオープン、クローズ、アクセプトなどのタイミングで、ＵＳＢのエンドポイント０を用いたコントロール転送を用いてプリンタ３に情報を送り、上記オープン、クローズ、アクセプトなどのタイミングでプリンタ３と同期をとってもよい。

Ｓ２０２では、スレッドはＳ２０１で確立した新たなセッション以外のセッションによる通信を禁止する排他処理を実行する。
具体的には、スレッドはＳ１０１で生成されたミューテックスの取得を試みる。ミューテックスが他のスレッドによって取得されていない場合は当該スレッドによってミューテックスが取得され、その後にミューテックスの取得を試みた他のスレッドは当該スレッドによってミューテックスが解放されるまで待機状態となる。これにより他のスレッドは通信が禁止された状態となる。

一方、ミューテックスが他のスレッドによって取得されている場合は、当該スレッドはミューテックスを取得できるまで待機状態となる。これにより当該スレッドは通信が禁止された状態となる。そして、他のスレッドがミューテックスを解放すると、当該スレッドより先に待機状態になっているスレッドがある場合は当該先に待機状態になっているスレッドによってそのミューテックスが取得され、当該スレッドは引き続き待機状態となる。当該スレッドより先に待機状態になっているスレッドがない場合は、当該スレッドによってミューテックスが取得される。
スレッドはミューテックスを取得するとＳ２０３に進む。
上述したＳ２０２は第１の禁止判断処理、第１の待機処理、及び、第１の排他処理の一例である。すなわち、ＩＰＰ／ＵＳＢ変換プログラム４３はミューテックスの仕組みを用いることによってこれらの処理を実現している。

Ｓ２０３では、スレッドはＳ２０１で確立したセッションを介してＷｅｂブラウザ４２から部分処理要求データを受信する。Ｓ２０３は第１の要求受信処理の一例である。
Ｓ２０４では、スレッドは一つの処理要求の受信が完了したか否かを判断する。具体的には、スレッドはＨＴＴＰのプロトコルに従ってデータエンドを判断する。例えば、スレッドは＜ＣＲＬＦ＞の有無や、Ｃｏｎｔｅｎｔ-ＬｅｎｇｔｈやＴｒａｎｓｆｅｒ−Ｅｎｃｏｄｉｎｇ： ｃｈｕｎｋｅｄで示される付加データのサイズを確認することにより、データエンドを判断する。これにより、一つの処理要求の受信が完了したか否かを判断することができる。
スレッドは、一つの処理要求の受信が完了していないと判断した場合はＳ２０５に進み、完了したと判断した場合はＳ２０６に進む。

Ｓ２０５では、スレッドはＷｅｂブラウザ４２から通信の中止が通知されたか否かを判断する。具体的には、スレッドはＳ２０１で確立したセッションがＷｅｂブラウザ４２によってクローズされたか否かを判断し、クローズされた場合は通信の中止が通知されたと判断する。スレッドは通信の中止が通知されていない場合はＳ２０３に戻って処理を繰り返し、中止が通知された場合は途中まで受信した処理要求を破棄してＳ２１１に進む。Ｓ２０５は第１の中止判断処理の一例である。

Ｓ２０６では、スレッドはＷｅｂブラウザ４２から受信した処理要求をＩＰＰ機能５１に送信する。Ｓ２０６は第１の要求送信処理の一例である。
Ｓ２０７では、スレッドはＩＰＰ機能５１に送信した処理要求に対する応答をＩＰＰ機能５１から受信する。具体的には、ＩＰＰ機能５１は応答を複数の部分応答データに分割してＩＰＰ／ＵＳＢ変換プログラム４３に送信するものであり、Ｓ２０７では一つの部分応答データが受信される。

Ｓ２０８では、スレッドはＩＰＰ機能５１からの応答の受信が完了したか否かを判断する。この判断はＳ２０４と同様の手順により行われる。スレッドは、応答の受信が完了していない場合はＳ２０７に戻って処理を繰り返し、完了している場合はＳ２０９に進む。
Ｓ２０９では、スレッドは上記Ｓ２０７、Ｓ２０８の処理の間にＷｅｂブラウザ４２から通信の中止が通知されたか否かを判断する。なお、スレッドは最後にＳ２０５を実行した後、Ｓ２０９を実行するまでの間にＷｅｂブラウザ４２から通信の中止が通知されたか否かを判断してもよい。前述したように通信の中止が通知されたか否かはＷｅｂブラウザ４２によってセッションがクローズされたか否かによって判断される。スレッドは、通信の中止が通知されていない場合はＳ２１０進み、通知された場合はＳ２１１に進む。

Ｓ２１０では、スレッドはＩＰＰ機能５１から受信した応答をＷｅｂブラウザ４２に送信する。
Ｓ２１１では、スレッドは排他終了処理を実行する。具体的には、スレッドはミューテックスを解放する。Ｓ２１１は第１の解禁処理の一例である。従ってＳ２０２から本Ｓ２１１までの間、換言すれば、Ｓ２０６、Ｓ２０９によりそのセッションにおけるすべての部分処理要求データ及び部分応答データを送信するまでの間、排他処理が行われ、その間に他のスレッドの処理により他のセッションの部分要求データや部分応答データが割り込むことはない。
Ｓ２１２では、スレッドはＳ２０１で生成したセッションをクローズして処理を終了する。

なお、上述したフローチャートでは省略しているが、スレッドがＩＰＰ機能５１と通信している間に何らかの理由によってＵＳＢが切断された場合は通信を中止し、ＨＴＴＰの書式に従ってＷｅｂブラウザ４２にエラーを通知してもよい。

（７）実施形態の効果
以上説明したＩＰＰ／ＵＳＢ変換プログラム４３によると、Ｗｅｂブラウザ４２からの処理要求の受信が完了した後でなければプリンタ３への処理要求の送信を開始しない。具体的には、ＩＰＰ／ＵＳＢ変換プログラム４３は、Ｓ２０５で通信の中止が通知されたと判断されることなくＳ２０４で処理要求の受信が完了したと判断した場合でなければプリンタ３への処理要求の送信を開始しない。このため、ＩＰＰ／ＵＳＢ変換プログラム４３がＷｅｂブラウザ４２から処理要求を受信している途中でＷｅｂブラウザ４２から通信の中止が通知された場合は、プリンタ３への処理要求の送信が開始されない。
よってＩＰＰ／ＵＳＢ変換プログラム４３によると、プリンタ３とＷｅｂブラウザ４２との間で通信を中継する場合に、Ｗｅｂブラウザ４２とＩＰＰ／ＵＳＢ変換プログラム４３との間の通信が途中で途絶えてしまうことによってプリンタ３の受信待ち状態が長時間継続してしまうことを抑制することができる。

更に、ＩＰＰ／ＵＳＢ変換プログラム４３によると、いずれかのセッションを介して処理要求を中継している間は他のセッションによる通信を禁止するので、処理要求に対する応答が混乱してしまうことを抑制できる。また中止の処理は中止が通知されたセッションのみにかかるので、Ｗｅｂブラウザ４２からの一部の処理要求に対してのみの中断にも対応できる。

＜実施形態２＞
次に、実施形態２を図７ないし図９によって説明する。
前述した実施形態１に係るＩＰＰ／ＵＳＢ変換プログラム４３はＷｅｂブラウザ４２からの処理要求の受信が完了した後にＩＰＰ機能５１への当該処理要求の送信を開始する。これに対し、実施形態２に係るＩＰＰ／ＵＳＢ変換プログラム４３はＷｅｂブラウザ４２からの処理要求の受信を開始すると、当該処理要求の受信が完了するのを待たずにＩＰＰ機能５１への当該処理要求の送信を開始する。

この場合、ＩＰＰ／ＵＳＢ変換プログラム４３が処理要求の受信を完了する前にＷｅｂブラウザ４２から通信の中止が通知され、それによりＩＰＰ／ＵＳＢ変換プログラム４３とＷｅｂブラウザ４２との通信が途絶えてしまうことが起こり得る。その場合、ＩＰＰ機能５１はＩＰＰ／ＵＳＢ変換プログラム４３とＷｅｂブラウザ４２との通信が途絶えていることを知ることができないので、処理要求の受信待ち状態が長時間継続してしまう。
そこで、実施形態２に係るＩＰＰ／ＵＳＢ変換プログラム４３は、Ｗｅｂブラウザ４２から通信の中止が通知されると、ＩＰＰ機能５１に通信の中止を通知する。

（７）ＩＰＰ／ＵＳＢ変換プログラムによる通信中継処理
（７−１）スレッド生成処理
実施形態２に係るスレッド生成処理は実施形態１と実質的に同一であるので説明は省略する。

（７−２）Ｗｅｂブラウザから処理要求を受信する処理
図７を参照して、実施形態２に係るＩＰＰ／ＵＳＢ変換プログラム４３がＷｅｂブラウザ４２から処理要求を受信する処理について説明する。
Ｓ３０１では、スレッドはアクセプト処理を実行する。Ｓ３０１は第２の確立処理の一例である。
Ｓ３０２では、スレッドはＳ３０１で確立した新たなセッション以外のセッションによる通信を禁止する排他処理を実行する。Ｓ３０２は、第２の禁止判断処理、第２の待機処理、及び、第２の排他処理の一例である。

Ｓ３０３では、スレッドはＳ３０１で確立したセッションを介してＷｅｂブラウザ４２から部分処理要求データを受信する。Ｓ３０３は第２の要求受信処理の一例である。
Ｓ３０４では、スレッドはＳ３０３で受信した部分処理要求データをＩＰＰ機能５１に送信する。Ｓ３０４は第２の要求送信処理の一例である。
Ｓ３０５では、スレッドは一つの処理要求の受信が完了したか否かを判断し、一つの処理要求の受信が完了していないと判断した場合はＳ３０６に進み、完了したと判断した場合はＳ３０８に進む。

Ｓ３０６では、スレッドはＷｅｂブラウザ４２から通信の中止が通知されたか否かを判断する。具体的には、スレッドはＳ３０１で確立したセッションがＷｅｂブラウザ４２によってクローズされたか否かを判断し、クローズされた場合は通信の中止が通知されたと判断する。スレッドは、通信の中止が通知されていない場合はＳ３０３に戻って処理を繰り返す。一方、中止が通知された場合は、スレッドはＳ３０７に進む。Ｓ３０６は第２の中止判断処理の一例である。

Ｓ３０７では、スレッドはＩＰＰ機能５１にキャンセル通知を送信することによってＩＰＰ機能５１に通信の中止を通知する。キャンセル通知はインタフェース０を介してコントロール転送によってＩＰＰ機能５１に送信される。Ｓ３０７は第１の中止通知処理の一例である。Ｓ３０７を終えるとＳ３１２において排他終了処理を行い、当該セッションの終了待ちで待機状態にあるスレッドを非待機状態とし、Ｓ３１３にてセッションをクローズする。

Ｓ３０８では、スレッドはＩＰＰ機能５１に送信した処理要求に対する応答をＩＰＰ機能５１から受信する。具体的には、ＩＰＰ機能５１は応答を複数の部分応答データに分割してＩＰＰ／ＵＳＢ変換プログラム４３に送信するものであり、Ｓ３０８では一つの部分応答データが受信される。
Ｓ３０９では、スレッドはＳ３０８乃至後述するＳ３１１のループ処理の間にＷｅｂブラウザ４２から通信の中止が通知されたか否かを判断し、中止が通知されていない場合はＳ３１０に進み、中止が通知された場合はＳ３０７に進み前述のとおりＩＰＰ機能にキャンセル通知を送信する。

Ｓ３１０では、スレッドはＩＰＰ機能５１から受信した部分応答データをＷｅｂブラウザ４２に送信する。
Ｓ３１１では、スレッドはＩＰＰ機能５１からの応答の受信が完了したか否かを判断する。この判断はＳ３０５と同様の手順により行われる。スレッドは、応答の受信が完了している場合はＳ３１２に進み、完了していない場合はＳ３０８に戻って処理を繰り返す。

Ｓ３１２では、スレッドは排他終了処理を実行する。Ｓ３１２は第２の解禁処理の一例である。
Ｓ３１３では、スレッドはＳ３０１で生成したセッションをクローズして処理を終了する。

なお、上述したフローチャートでは省略しているが、スレッドがＩＰＰ機能５１と通信している間に何らかの理由によってＵＳＢが切断された場合は通信を中止し、ＨＴＴＰの書式に従ってＷｅｂブラウザ４２にエラーを通知してもよい。

（２）ＩＰＰ機能の処理
次に、実施形態２に係るＩＰＰ機能５１の処理について説明する。

（２−１）ＩＰＰ／ＵＳＢ変換プログラムから処理要求を受信する処理
先ず、図８を参照して、実施形態２に係るＩＰＰ機能５１がインタフェース１又はインタフェース２を介してＩＰＰ／ＵＳＢ変換プログラム４３から処理要求を受信する処理について説明する。本処理はプリンタ３の電源がＯＮの状態で繰り返し実行される。
Ｓ４０１では、ＩＰＰ機能５１はＩＰＰ／ＵＳＢ変換プログラム４３からの受信がＷｅｂブラウザ４２からの処理要求の受信であるか否かを判断し、Ｗｅｂブラウザ４２からの処理要求の受信である場合はＳ４０２に進み、それ以外である場合はＳ４０６に進む。

Ｓ４０２では、ＩＰＰ機能５１はＷｅｂサーバ機能５２との間に通信を確立する。この通信はＴＣＰ／ＩＰのセッションとして確立されてもよいし、プリンタ３の独自の通信方式（たとえば共有メモリによるデータ送信）によって確立されてもよい。Ｓ４０２は第４の確立処理の一例である。
Ｓ４０３では、ＩＰＰ機能５１はＳ４０２で確立した通信を介してＷｅｂサーバ機能５２に処理要求を送信する。Ｓ４０３は第４の要求送信処理の一例である
Ｓ４０４では、ＩＰＰ機能５１はＷｅｂサーバ機能５２から一定時間以内に応答を受信したか否かを判断し、応答を受信した場合はＳ４０５に進み、応答を受信しなかった場合はＳ４０１に戻る。Ｓ４０４は第２の応答受信処理の一例である。

Ｓ４０５では、ＩＰＰ機能５１はＷｅｂサーバ機能５２から受信した応答を、インタフェース１を介してＩＰＰ／ＵＳＢ変換プログラム４３に送信する。Ｓ４０５は第２の応答送信処理の一例である。
Ｓ４０６では、ＩＰＰ機能５１はＩＰＰ／ＵＳＢ変換プログラム４３からの受信がスプーラ４４からの印刷ジョブの受信であるか否かを判断し、スプーラ４４からの印刷ジョブの受信である場合はＳ４０７に進み、それ以外である場合はＳ４０９に進む。

Ｓ４０７では、ＩＰＰ機能５１は受信した印刷ジョブを印刷部３３に出力する。
Ｓ４０８では、ＩＰＰ機能５１は印刷ジョブを正常に受信したことを示す応答（図８ではＯＫ応答と記す）を、インタフェース２を介してＩＰＰ／ＵＳＢ変換プログラム４３に送信する。
Ｓ４０９では、ＩＰＰ機能５１はその他の処理要求に応じた処理を実行する。

（２−２）ＩＰＰ／ＵＳＢ変換プログラムからキャンセル通知を受信したときの処理
次に、図９を参照して、ＩＰＰ機能５１がインタフェース０を介してＩＰＰ／ＵＳＢ変換プログラム４３からキャンセル通知を受信したときの処理について説明する。ＩＰＰ機能５１がキャンセル通知を受信したか否かを判断する処理は第４の中止判断処理の一例である。

Ｓ５０１では、ＩＰＰ機能５１はＷｅｂサーバ機能５２との通信を終了させる。Ｓ５０１は第１の終了処理の一例である。
Ｓ５０２では、ＩＰＰ機能５１は現在行っている通信がプリンタ３を設定するための通信（ａ）であるかプリンタ３に印刷データを送信するための通信（ｂ）であるかを判断し、プリンタ３を設定するための通信（ａ）である場合はＳ５０３に進み、そうでない場合はＳ５０６に進む。

Ｓ５０３では、ＩＰＰ機能５１はキャンセル通知が受信されたときが処理要求の受信中であるか、又は、処理要求の受信が完了した後、ＩＰＰ／ＵＳＢ変換プログラム４３に応答を送信する前であるかを判断し、処理要求の受信中である場合はＳ５０４に進み、そうでない場合はＳ５０５に進む。

Ｓ５０４では、ＩＰＰ機能５１はＩＰＰ／ＵＳＢ変換プログラム４３からの処理要求の受信待ち状態を解消する。
Ｓ５０５では、ＩＰＰ機能５１はＩＰＰ／ＵＳＢ変換プログラム４３から受信した処理要求を破棄する。
Ｓ５０６では、ＩＰＰ機能５１はキャンセル通知が受信されたときが印刷ジョブの受信中であるか、又は、印刷ジョブの受信が完了した後、ＩＰＰ／ＵＳＢ変換プログラム４３に応答を送信する前であるかを判断し、印刷ジョブの受信中である場合はＳ５０７に進み、印そうでない場合はＳ５０８に進む。

Ｓ５０７では、ＩＰＰ機能５１はＩＰＰ／ＵＳＢ変換プログラム４３からの印刷ジョブの受信待ち状態を解消する。
Ｓ５０８では、ＩＰＰ機能５１はＩＰＰ／ＵＳＢ変換プログラム４３から受信した印刷ジョブを破棄する。

（３）実施形態の効果
以上説明した実施形態２に係るＩＰＰ／ＵＳＢ変換プログラム４３によると、Ｗｅｂブラウザ４２から処理要求を受信している途中でＷｅｂブラウザ４２から通信の中止が通知された場合は、プリンタ３に通信の中止を通知する。
よってＩＰＰ／ＵＳＢ変換プログラム４３によると、プリンタ３とＷｅｂブラウザ４２との間で通信を中継する場合に、Ｗｅｂブラウザ４２とＩＰＰ／ＵＳＢ変換プログラム４３との間の通信が途中で途絶えてしまうことによってプリンタ３の受信待ち状態が長時間継続してしまうことを抑制することができる。

更に、ＩＰＰ／ＵＳＢ変換プログラム４３によると、いずれかのセッションを介して処理要求を中継している間は他のセッションによる通信を禁止するので、処理要求が混乱してしまうことを抑制できる。

また、実施形態２に係るプリンタ３によると、ＩＰＰ機能５１はＰＣ２から通信の中止が通知された場合はＷｅｂサーバ機能５２との間に確立されているセッションを終了させるので、Ｗｅｂサーバ機能５２の受信待ち状態が長時間継続してしまうことを抑制することができる。

更に、実施形態２に係るプリンタ３によると、ＩＰＰ機能５１はＰＣ２から受信した処理要求をＷｅｂサーバ機能５２に送信した後、ＰＣ２に応答を送信する前にＰＣ２から通信の中止が通知された場合は、Ｗｅｂサーバ機能５２から送信された応答をＰＣ２に送信せずに破棄するので、Ｗｅｂブラウザ４２とＩＰＰ／ＵＳＢ変換プログラム４３との間の通信が途中で途絶えてしまったにもかかわらずプリンタ３がＰＣ２に応答を送信してしまうことを抑制することができる。

＜実施形態３＞
次に、実施形態３を図１０ないし図１７によって説明する。
実施形態３は実施形態２の変形例である。実施形態３に係るＩＰＰ／ＵＳＢ変換プログラム４３は、実施形態２に係るＩＰＰ／ＵＳＢ変換プログラム４３と同様に、Ｗｅｂブラウザ４２からの処理要求の受信を開始するとその受信が完了するのを待たずにＩＰＰ機能５１への当該処理要求の送信を開始する。

この場合に、実施形態２に係るＩＰＰ／ＵＳＢ変換プログラム４３はセッション単位での排他処理を行っているが、実施形態３に係るＩＰＰ／ＵＳＢ変換プログラム４３はセッション単位での排他処理を行わない。
その替わりとして、実施形態３に係るＩＰＰ／ＵＳＢ変換プログラム４３は、Ｗｅｂブラウザ４２から受信した処理要求にセッションを識別するためのセッション情報を付加したセッション情報付き処理要求をＩＰＰ機能５１に送信する。そして、ＩＰＰ／ＵＳＢ変換プログラム４３はＩＰＰ機能５１からセッション情報が付加された応答であるセッション情報付き応答を受信する。そして、ＩＰＰ／ＵＳＢ変換プログラム４３は、セッション情報付き応答からセッション情報を除去した応答を、当該セッション情報によって識別されるセッションを介してＷｅｂブラウザ４２に送信する。

（１）ＩＰＰ／ＵＳＢ変換プログラムによる通信中継処理の全体的な流れ
先ず、図１０を参照して、ＩＰＰ／ＵＳＢ変換プログラム４３による通信中継処理の全体的な流れについて説明する。ここではプリンタ３を設定するための通信（ａ）を例に説明する。前述したようにプリンタ３を設定するための通信（ａ）はインタフェース１を用いて行われる。

また、ここではＷｅｂブラウザ４２がＩＰＰ／ＵＳＢ変換プログラム４３にＧＩＦ１、ＧＩＦ２、及び、ＧＩＦ３の送信を要求するところから説明を始める。
また、ここではＩＰＰ機能５１とＷｅｂサーバ機能５２とをまとめてプリンタ３というものとする。

Ｗｅｂブラウザ４２は、先ずＩＰＰ／ＵＳＢ変換プログラム４３にセッション１の確立を要求してセッション１を確立（Ｓ７０１）し、ＧＩＦ１の送信を要求する処理要求を、セッション１を介してＩＰＰ／ＵＳＢ変換プログラム４３に送信する（Ｓ７０２）。
ＩＰＰ／ＵＳＢ変換プログラム４３はセッション１を介して処理要求を受信すると、その処理要求にセッション１を識別するためのセッションＩＤを付加したセッションＩＤ付き処理要求を、ＵＳＢを介してプリンタ３に送信する（Ｓ７０３）。

プリンタ３は、セッションＩＤ付き処理要求を受信すると、その処理要求に対する応答としてＧＩＦ１をＩＰＰ／ＵＳＢ変換プログラム４３に送信する（Ｓ７０７）。このときプリンタ３はセッションＩＤ付き処理要求に付加されていたセッションＩＤを応答に付加して送信する。
ＩＰＰ／ＵＳＢ変換プログラム４３はセッションＩＤ付き応答を受信すると、セッションＩＤ付き応答からセッションＩＤを除去した応答を、そのセッションＩＤによって識別されるセッション、すなわちセッション１を介してＷｅｂブラウザ４２に送信する（Ｓ７０８）。

Ｗｅｂブラウザ４２は、セッション１の確立を要求した後、セッション１によってＧＩＦ１が受信されるのを待つことなくセッション２の確立を要求し（Ｓ７０４）、ＧＩＦ２の送信を要求する処理要求を、セッション２を介してＩＰＰ／ＵＳＢ変換プログラム４３に送信する（Ｓ７０５）。セッション２についてもセッション１と同様に、セッション２を識別するためのセッションＩＤを用いて通信が行われる（Ｓ７０６、Ｓ７１２、Ｓ７１３）。セッション３についても同様である。

これら一連の処理によってＧＩＦ１〜ＧＩＦ３がＷｅｂブラウザ４２に読み込まれ、設定画面６０上にＧＩＦ１〜ＧＩＦ３が表示される。

（２）セッションＩＤ付き処理要求、及び、セッションＩＤ付き応答
この処理における部分処理要求データは以下のように分けられる。
（ａ）ヘッダ
（ｂ）Ｃｏｎｔｅｎｔ-Ｌｅｎｇｔｈにより一括指定される付加データのデータ塊
（ｃ）ｃｈｕｎｋｅｄ指定により指定される複数に分割された付加データのそれぞれのデータ塊
ここでヘッダとは、処理要求のうち付加データ以外のデータのことをいう。付加データが付加されていない場合は処理要求全体がヘッダに相当する。実際の要求では、（１）のみ、あるいは（１）および（２）、あるいは（１）および単数もしくは複数の（３）により処理要求データが構成される。
付加データが付加される場合はヘッダにＣｏｎｔｅｎｔ-Ｌｅｎｇｔｈ、及び、ｃｈｕｎｋｅｄのいずれか一方が指定される。

実施形態３に係るＩＰＰ／ＵＳＢ変換プログラム４３は、例えばセッション１を介して処理要求のヘッダを受信すると、そのヘッダにセッション１のセッションＩＤを付加したセッションＩＤ付きヘッダをＩＰＰ機能５１に送信する。
そして、ＩＰＰ／ＵＳＢ変換プログラム４３は、セッション１による処理要求の受信が完了する前にセッション２を介してヘッダを受信すると、そのヘッダにセッション２のセッションＩＤを付加したセッションＩＤ付きヘッダをＩＰＰ機能５１に送信する。以下同様に、ＩＰＰ／ＵＳＢ変換プログラム４３はセッションを介して部分処理要求データを受信する毎にその部分処理要求データに当該部分処理要求データを受信したセッションのセッションＩＤを付加してＩＰＰ機能５１に送信する。
ＩＰＰ機能５１も同様に応答をヘッダと付加データとの二つの部分応答データに分け、各部分応答データにセッションＩＤを付加してＩＰＰ／ＵＳＢ変換プログラム４３に送信する。

（３）ＩＰＰ／ＵＳＢ変換プログラムによる通信中継処理
（３−１）スレッド生成処理
実施形態３に係るスレッド生成処理は実施形態１と実質的に同一であるので説明は省略する。

（３−２）Ｗｅｂブラウザから処理要求を受信する処理
先ず、図１１を参照して、実施形態３に係るＩＰＰ／ＵＳＢ変換プログラム４３がＷｅｂブラウザ４２から処理要求を受信する処理について説明する。この処理はＳ１０４で生成されたスレッドによって実行される。

Ｓ８０１では、スレッドはアクセプト処理を実行する。Ｓ８０１は第３の確立処理の一例である。
Ｓ８０２では、スレッドはＳ８０１で生成したソケットを識別すためのセッションＩＤを生成する。Ｓ８０２は識別子生成処理の一例である。
Ｓ８０３では、スレッドはＳ８０１で生成したソケットを識別するためのソケット情報とＳ８０２で生成したセッションＩＤとを対応付けて記憶部２５に記憶させる。Ｓ８０３は第１の記憶処理の一例である。また、ソケット情報はセッションを識別すための識別情報の一例である。

Ｓ８０４では、スレッドはＳ８０１で確立したセッションを介してＷｅｂブラウザ４２から処理要求のヘッダを受信する。Ｓ８０４は第３の要求受信処理の一例である。
Ｓ８０５では、スレッドはＷｅｂブラウザ４２から通信の中止が通知されたか否かを判断する。前述したように通信の中止が通知されたか否かはＷｅｂブラウザ４２によってセッションがクローズされたか否かによって判断される。スレッドは、通信の中止が通知されていない場合はＳ８０６に進み、通知された場合は本処理を終了する。Ｓ８０５は第３の中止判断処理の一例である。

Ｓ８０６では、スレッドはインタフェース１の排他処理を実行する。
Ｓ８０７では、スレッドはＳ８０２で生成したセッションＩＤを、インタフェース１を介してＩＰＰ機能５１に送信する。
Ｓ８０８では、スレッドはＳ８０４で受信したヘッダを、インタフェース１を介してＩＰＰ機能５１に送信する。ここで、処理要求のヘッダが複数の通信データからなる場合は、Ｓ８０８においてそれら複数の通信データがＩＰＰ機能５１に送信される。
上述したＳ８０７及びＳ８０８はセッション情報付き処理要求を画像処理装置に送信する第３の要求送信処理の一例である。

Ｓ８０９では、スレッドはインタフェース１の排他処理を終了する。
Ｓ８１０では、スレッドは付加データがあるか否かを判断する。具体的には、スレッドはＳ８０４で受信したヘッダにＣｏｎｔｅｎｔ-Ｌｅｎｇｔｈ又はｃｈｕｎｋｅｄが含まれている場合は付加データがあると判断し、いずれも含まれていない場合は付加データがないと判断する。スレッドは、付加データがある場合はＳ８１１に進み、付加データがない場合は本処理を終了する。
Ｓ８１１では、スレッドは付加データ送信処理を実行する。付加データ送信処理はＷｅｂブラウザ４２から付加データを受信してＩＰＰ機能５１に送信する処理である。

（３−３）付加データ送信処理
次に、図１２及び図１３を参照して、Ｓ８１１で実行される付加データ送信処理について説明する。
Ｓ９０１では、スレッドは受信したヘッダにＣｏｎｔｅｎｔ-Ｌｅｎｇｔｈが含まれているか否かを判断し、Ｃｏｎｔｅｎｔ-Ｌｅｎｇｔｈが含まれている場合はＳ９０２に進み、含まれていない場合（すなわちｃｈｕｎｋｅｄが含まれている場合）はＳ９０９に進む。

Ｓ９０２では、スレッドはＳ８０４で受信したヘッダからサイズ情報データを取得する。
Ｓ９０３では、スレッドはＷｅｂブラウザ４２からＳ９０２で取得したサイズ情報データによって示されるデータサイズの付加データを受信する。
Ｓ９０４では、スレッドは上記Ｓ９０３の実行中にＷｅｂブラウザ４２から通信の中止が通知されたか否かを判断し、通信の中止が通知されていない場合はＳ９０５に進み、通知された場合はＳ９１７に進む。

Ｓ９０５では、スレッドはインタフェース１の排他処理を実行する。
Ｓ９０６では、スレッドはＳ８０２で生成されたセッションＩＤを、インタフェース１を介してＩＰＰ機能５１に送信する。
Ｓ９０７では、スレッドはＳ９０３で受信した付加データを、インタフェース１を介してＩＰＰ機能５１に送信する。
Ｓ９０８では、スレッドはインタフェース１の排他終了処理を実行する。

Ｓ９０９では、スレッドはデータ塊のサイズ情報データを取得する。具体的には、前記Ｓ９０１でＣｈｕｎｋｅｄにより付加データが送信されていると判断された場合にＳ９０９の処理が行われる、この場合は、付加データは通常複数のデータ塊に分割され、それぞれのデータ塊に対してそのデータ数の情報が付加されている。Ｓ９０９ではそのそれぞれのデータ塊のサイズ情報データを取得する。
Ｓ９１０では、スレッドはＷｅｂブラウザ４２からＳ９０９で取得したサイズ情報データによって示されるデータサイズ分の部分付加データを受信する。

Ｓ９１１では、スレッドは前記Ｓ９０９乃至後述するＳ９１６で形成されるループ中においてＷｅｂブラウザ４２から通信の中止が通知されたか否かを判断し、通信の中止が通知されていない場合はＳ９１２に進み、通知された場合はＳ９１７に進む。
Ｓ９１２では、スレッドはインタフェース１の排他処理を実行する。
Ｓ９１３では、スレッドはＳ８０２で生成されたセッションＩＤを、インタフェース１を介してＩＰＰ機能５１に送信する。

Ｓ９１４では、スレッドはＳ９１０で受信した部分付加データを、インタフェース１を介してＩＰＰ機能５１に送信する。
Ｓ９１５では、スレッドはインタフェース１の排他終了処理を実行する。
Ｓ９１６では、スレッドは付加データの受信が完了したか否かを判断する。具体的には、受信した付加データに続くデータ塊があるか否かをＳ２０４と同様の方法で判断する。スレッドは、付加データの受信が完了した場合は本処理を終了して図１１の処理に戻り、未だ完了していない場合はＳ９０９に戻って処理を繰り返す。ただし、本処理が終了してもセッションは存続し続ける。

Ｓ９１７では、スレッドはＳ８０２で生成したセッションＩＤを付加したセッションＩＤ付きキャンセル通知を生成する。
Ｓ９１８では、スレッドはＳ９１７で生成したセッションＩＤを付加したセッションＩＤ付きキャンセル通知をコントロール転送によってＩＰＰ機能５１に送信する。前述したようにコントロール転送はインタフェース０を用いて行われる。Ｓ９１８は第２の中止通知処理の一例である。

Ｓ９１９では、スレッドはＳ８０２で生成したセッションＩＤと当該セッションＩＤに対応付けられて記憶されているソケット情報とを記憶部２５から削除する。
Ｓ９２０では、スレッドはソケットを破棄し、図１２に戻った後に図１１の処理に戻る。

（３−４）ＩＰＰ機能から応答を受信する処理
次に、図１４を参照して、ＩＰＰ／ＵＳＢ変換プログラム４３がＩＰＰ機能５１から応答を受信する処理について説明する。

Ｓ１００１では、ＩＰＰ／ＵＳＢ変換プログラム４３はＩＰＰ機能５１からセッションＩＤ付き部分応答データを受信する。Ｓ１００１は第１の応答受信処理の一例である。
Ｓ１００２では、ＩＰＰ／ＵＳＢ変換プログラム４３はセッションＩＤ付き部分応答データからセッションＩＤを取得する。

Ｓ１００３では、ＩＰＰ／ＵＳＢ変換プログラム４３はＳ１００２で取得したセッションＩＤが記憶部２５に記憶されているか否かを判断し、記憶されている場合はＳ１００４に進む。一方、記憶されていない場合は、ＩＰＰ／ＵＳＢ変換プログラム４３はＳ１００１で受信したセッションＩＤ付き部分応答データを破棄してＳ１００１に戻る。

Ｓ１００４では、ＩＰＰ／ＵＳＢ変換プログラム４３はＳ１００２で取得したセッションＩＤと同じセッションＩＤに対応付けられて記憶されているソケット情報を記憶部２５から読み出す。このソケット情報は前述したＳ８０３で記憶されたものである。
Ｓ１００５では、ＩＰＰ／ＵＳＢ変換プログラム４３はＳ１００１で受信したセッションＩＤ付き部分応答データからセッションＩＤを除去する。

Ｓ１００６では、ＩＰＰ／ＵＳＢ変換プログラム４３はＳ１００５でセッションＩＤを除去した部分応答データを、Ｓ１００４で読み出したソケット情報によって識別されるセッションを介してＷｅｂブラウザ４２に送信する。Ｓ１００６は第１の応答送信処理の一例である。
Ｓ１００７では、ＩＰＰ／ＵＳＢ変換プログラム４３はＩＰＰ機能５１からの応答の受信が完了したか否かを判断する。この判断はＳ２０８と同様の手順により行われる。ＩＰＰ／ＵＳＢ変換プログラム４３は、応答の受信が完了していない場合はＳ１００１に戻って処理を繰り返し、完了している場合はＳ１００８に進む。

Ｓ１００８では、ＩＰＰ／ＵＳＢ変換プログラム４３はＳ１００４で読み出したソケット情報によって識別されるソケットを破棄する。
Ｓ１００９では、ＩＰＰ／ＵＳＢ変換プログラム４３はＳ１００２で取得したセッションＩＤと当該セッションＩＤに対応付けられているソケット情報とを記憶部２５から削除する。Ｓ１００９は削除処理の一例である。

（４）ＩＰＰ機能の処理
次に、ＩＰＰ機能５１がＩＰＰ／ＵＳＢ変換プログラム４３から処理要求を受信する処理、及び、ＩＰＰ機能５１がＷｅｂサーバ機能５２から応答を受信する処理について説明する。

（４−１）ＩＰＰ／ＵＳＢ変換プログラムから処理要求を受信する処理
先ず、図１５を参照して、ＩＰＰ機能５１がＩＰＰ／ＵＳＢ変換プログラム４３から処理要求を受信する処理について説明する。

Ｓ１１０１では、ＩＰＰ機能５１はＩＰＰ／ＵＳＢ変換プログラム４３からＵＳＢを介してセッションＩＤ付き部分処理要求データ（ヘッダ又は付加データ）を受信する。
ここで、Ｓ１１０１はＩＰＰ／ＵＳＢ変換プログラム４３からセッションＩＤ付き部分処理要求データを受信するまで待機するのではなく、セッションＩＤ付き部分処理要求データを受信していない場合は受信したデータのデータサイズが０であるとしてＳ１１０２に進む。

Ｓ１１０２では、ＩＰＰ機能５１は後述するキャンセル処理からキャンセルが通知されたか否かを判断する。詳しくは後述するが、前述したＳ９１８でＩＰＰ／ＵＳＢ変換プログラム４３から送信されたセッションＩＤ付きキャンセル通知は後述するキャンセル処理によって受信される。後述するキャンセル処理はセッションＩＤ付きキャンセル通知を受信すると、そのセッションＩＤをＩＰＰ機能５１に通知する。ＩＰＰ機能５１はキャンセル処理からセッションＩＤが通知されたか否かによってキャンセルが通知されたか否かを判断することができる。ＩＰＰ機能５１はキャンセルが通知された場合はＳ１１０３に進み、通知されていない場合はＳ１１０５に進む。

Ｓ１１０３では、ＩＰＰ機能５１はＳ１１０１で受信したセッションＩＤ付き部分処理要求データに付加されているセッションＩＤとキャンセル処理から通知されたセッションＩＤとが一致するか否かを判断し、一致する場合はＳ１１０４に進み、一致しない場合はＳ１１０５に進む。
Ｓ１１０４では、ＩＰＰ機能５１はＳ１１０１で受信したセッションＩＤ付き処理要求を破棄してＳ１１０１に戻る。

Ｓ１１０５では、ＩＰＰ機能５１はＳ１１０１で受信したデータのデータサイズが０（零）であるか否かを判断し、０である場合はＳ１１０１に戻り、０でない場合はＳ１１０６に進む。
Ｓ１１０６では、ＩＰＰ機能５１はＳ１１０１で受信したセッションＩＤ付き部分処理要求データからセッションＩＤを取得する。
Ｓ１１０７では、ＩＰＰ機能５１はＳ１１０６で取得したセッションＩＤが、ＩＰＰ機能５１とＷｅｂサーバ機能５２との間に確立されているセッションを識別するためのソケット情報に対応付けられて記憶部３５に記憶されているか否かを判断する。具体的には、本処理はループ処理であり、後述するＳ１１０９が実行された後にＳ１１０７が実行される場合もある。その場合はＳ１１０６で取得したセッションＩＤが既に記憶部３５に記憶されている場合もある。ＩＰＰ機能５１は、記憶されていない場合はＳ１１０８に進み、記憶されている場合はＳ１１１０に進む。Ｓ１１０７は記憶判断処理の一例である。また、ソケット情報は通信識別情報の一例である。

Ｓ１１０８では、ＩＰＰ機能５１はＷｅｂサーバ機能５２と通信するためのソケットを生成し、生成したソケットを介してＷｅｂサーバ機能５２との間に新たなセッションを確立する。ＩＰＰ機能５１とＷｅｂサーバ機能５２との間に確立されたセッションは通信の一例である。以降の説明ではＩＰＰ機能５１とＷｅｂサーバ機能５２との間に確立されたセッションのことを通信という。Ｓ１１０８は第５の確立処理の一例である。
Ｓ１１０９では、ＩＰＰ機能５１はＳ１１０６で取得したセッションＩＤとＳ１１０８で生成したソケットを識別するためのソケット情報とを対応付けて記憶部３５に記憶させる。Ｓ１１０９は第２の記憶処理の一例である。

Ｓ１１１０では、ＩＰＰ機能５１はＳ１１０６で取得したセッションＩＤと同じセッションＩＤに対応付けられているソケット情報を記憶部３５から読み出す。
Ｓ１１１１では、ＩＰＰ機能５１はＳ１１０１で受信したセッションＩＤ付き部分処理要求データからセッションＩＤを除去する。
Ｓ１１１２では、ＩＰＰ機能５１はＳ１１１１でセッションＩＤを除去した部分処理要求データを、Ｓ１１０８で生成したソケット、あるいは、Ｓ１１１０で読み出したソケット情報によって識別されるソケットを介してＷｅｂサーバ機能５２に送信する。Ｓ１１１２は第５の要求送信処理の一例である。

Ｓ１１１３では、ＩＰＰ機能５１は処理要求の受信が完了したか否かを判断する。この判断は前述したＳ２０４と同様に行うことができる。ＩＰＰ機能５１は、処理要求の受信が完了している場合はＳ１１１４に進み、完了していない場合はＳ１１０１に戻って処理を繰り返す。
Ｓ１１１４では、ＩＰＰ機能５１はスレッドを生成する。このスレッドはＷｅｂサーバ機能５２から応答を受信してＩＰＰ／ＵＳＢ変換プログラム４３に送信するためのものである。

（４−２）キャンセル処理
次に、図１６を参照して、前述したキャンセル処理について説明する。本処理は前述したＳ９１８でＩＰＰ／ＵＳＢ変換プログラム４３から送信されたセッションＩＤ付きキャンセル通知を、インタフェース０を介してＩＰＰ機能５１が受信すると開始される。

Ｓ１２０１では、ＩＰＰ機能５１はＩＰＰ／ＵＳＢ変換プログラム４３からコントロール転送によって送信されたセッションＩＤ付きキャンセル通知からセッションＩＤを取得する。Ｓ１２０１は第５の中止判断処理及び第６の中止判断処理の一例である。
Ｓ１２０２では、ＩＰＰ機能５１は前述した「ＩＰＰ／ＵＳＢ変換プログラムから処理要求を受信する処理」に、キャンセル通知に付加されているセッションＩＤを通知する。このセッションＩＤが通知されると、前記Ｓ１１０２においてＹＥＳと判断される。また通知されたセッションＩＤは、前記Ｓ１１０３における判断に使用される。

Ｓ１２０３では、ＩＰＰ機能５１はＳ１２０１で取得したセッションＩＤに対応するスレッドが存在するか否かを判断し、存在する場合はＳ１２０４に進み、存在しない場合はＳ１２０５に進む。
Ｓ１２０４では、ＩＰＰ機能５１はＳ１１１４で生成されたスレッドのうち、Ｓ１２０１で取得したセッションＩＤに対応するスレッドを停止させる。
Ｓ１２０５では、ＩＰＰ機能５１はＳ１２０１で取得したセッションＩＤに対応するソケット情報によって識別されるソケットをクローズする。Ｓ１２０５は第２の終了処理及び第３の終了処理の一例である。
Ｓ１２０６では、ＩＰＰ機能５１はＳ１２０１で取得したセッションＩＤと当該セッションＩＤに対応付けられて記憶されているソケット情報とを記憶部３５から削除する。

（４−３）Ｗｅｂサーバ機能から応答を受信する処理
次に、図１７を参照して、ＩＰＰ機能５１がＷｅｂサーバ機能５２から応答を受信する処理について説明する。この処理は前述したＳ１１１４で生成されたスレッドによって実行される。なおこのスレッドは前記Ｓ１２０４によって停止される場合がある。

Ｓ１３０１では、スレッドはＳ１１０６で取得されたセッションＩＤを継承するとともに、Ｓ１１０８で生成されたソケットのソケット情報、又は、Ｓ１１１０で読み出されたソケット情報を継承する。
Ｓ１３０２では、スレッドはＷｅｂサーバ機能５２から部分応答データを受信する。Ｓ１３０２は第３の応答受信処理の一例である。

Ｓ１３０３では、スレッドはＳ１３０２で受信した部分応答データにセッションＩＤを付加する。

Ｓ１３０４では、スレッドはインタフェース１の排他処理を実行する。具体的には、スレッドはインタフェース１のミューテックスを取得する。なお、ここで取得するミューテックスはＳ１０１で生成されたものとは異なるものである。ここで取得するミューテックスは例えばプリンタ３に電源が投入されたときに実行される初期化処理によって生成されたものである。
Ｓ１３０５では、スレッドはＳ１３０４でセッションＩＤが付加されたセッションＩＤ付き部分応答データをＩＰＰ／ＵＳＢ変換プログラム４３に送信する。Ｓ１３０５は第３の応答送信処理の一例である。

Ｓ１３０６では、スレッドはインタフェース１の排他処理を終了する。
Ｓ１３０７ではＷｅｂサーバ４２からの当該セッションに関するすべての応答を受信したか否かを判断する。その結果ＹＥＳと判断した場合にはＳ１３０８に進み、ＮＯと判断した場合にはＳ１３０２に戻り残りのデータを受信する。この受信完了の判断は前述したＳ２０４と同様に行うことができる。
Ｓ１３０８では、スレッドはセッションをクローズする。
Ｓ１３０９では、スレッドはＳ１３０１で継承したセッションＩＤ及びソケット情報を記憶部３５から削除する。

（５）実施形態の効果
以上説明した実施形態３に係るＩＰＰ／ＵＳＢ変換プログラム４３によると、プリンタ３とＷｅｂブラウザ４２との間で通信が途中で途絶えてしまった場合にキャンセルを通知する。よってプリンタ３の受信待ち状態が長時間継続してしまうことをセッションの単位で抑制することができる。

更に、ＩＰＰ／ＵＳＢ変換プログラム４３によると、不要になったセッション識別子と識別情報とが記憶部２５に記憶されたままにならないようにすることができる。

更に、ＩＰＰ／ＵＳＢ変換プログラム４３によると、セッション情報付き応答にセッション情報として付加されているセッション識別子が記憶部２５に記憶されていない場合はＷｅｂブラウザ４２に応答を送信しないので、Ｗｅｂブラウザ４２への無駄な応答の送信を抑制できる。

また、実施形態３に係るプリンタ３によると、ＩＰＰ機能５１とＷｅｂサーバ機能５２とがマルチセッションによって通信中に通信が途中で途絶えてしまった場合にＩＰＰ機能５１がＷｅｂサーバ機能５２にキャンセルを通知する。よってＷｅｂサーバ機能５２の受信待ち状態が長時間継続してしまうことを抑制することができる。

更に、プリンタ３によると、Ｗｅｂサーバ機能５２から応答を受信している途中でＰＣ２から通信の中止が通知された場合に、Ｗｅｂサーバ機能５２の送信待ち状態が長時間継続してしまうことを抑制することができる。

＜他の実施形態＞
上記記述及び図面によって説明した実施形態に限定されるものではなく、例えば次のような実施形態も技術的範囲に含まれる。

（１）上記実施形態１及び２ではマルチセッションによって通信を行うクライアントアプリケーションを例に説明した。これに対し、クライアントアプリケーションはシングルセッションによって通信を行うものであってもよい。

（２）上記実施形態３ではセッション情報としてセッションＩＤを処理要求に付加する場合を例に説明した。これに対し、セッションＩＤではなくソケット情報を付加してもよい。

（３）上記実施形態３では処理要求を複数の部分処理要求データに分割する例としてヘッダと付加データとに分割する場合を例に説明した。しかしながら、処理要求を複数の部分処理要求データに分割する基準はこれに限られるものではなく、適宜の基準で分けることができる。

（４）上記実施形態では通信回線としてＵＳＢを例に説明した。しかしながら、通信回線はＵＳＢに限られない。例えばＰＣ２とプリンタ３とはプリンタ３の通信規格であるＩＥＥＥ１２８４によって通信するものであってもよい。

（５）上記実施形態ではセッションの確立が要求される毎に新たなスレッドを作成する場合を例に説明した。これに対し、スレッドを作成せず、通信中継処理において各セッションに対する処理をシーケンシャルに実行してもよい。または、スレッドに替えてプロセスを作成し、スレッドによって行っていた処理をプロセスによって行ってもよい。

（６）上記実施形態ではＰＣ２とプリンタ３とを論理的な複数の通信回線で接続する場合を例に説明した。これに対し、ＰＣ２とプリンタ３とは物理的な複数の通信回線で接続されてもよい。

（７）上記実施形態ではプリンタ３を設定するための通信をマルチセッションによって行う場合にセッションの排他制御を行う場合を例に説明した。これに加えて、プリンタ３に印刷データを送信するための通信をマルチセッションで行う場合にセッションの排他制御を行ってもよい。

（８）上記実施形態では、排他処理開始の後にＷｅｂブラウザ４２からの受信を行っている。すなわち排他処理により実行が許可されるまではＷｅｂブラウザ４２からの要求の受信をしない。しかし排他の開始はＷｅｂブラウザ４２からのデータをプリンタ３（ＩＰＰ機能５１又はＷｅｂサーバ機能５２）に送信する前であればよく、Ｗｅｂブラウザ４２からの要求を受信した後であってもかまわない。

（９）上記実施形態では画像処理装置としてプリンタ３を例に説明した。これに対し、画像処理装置は、印刷機能、スキャナ機能、コピー機能、ファクシミリ機能などを備える所謂複合機であってもよい。

（１０）上記実施形態では処理部としてＣＰＵ３１ａを例に説明した。しかしながら、処理部は２以上のＣＰＵによって構成されてもよいし、ＡＳＩＣによって構成されてもよいし、ＣＰＵとＡＳＩＣとの組み合わせによって構成されてもよい。

（１１）上記すべての実施例では、プリンタはＫｅｅｐＡｌｉｖｅ仕様により単一セッションにて複数の処理要求データを要求しないものとして構成されている。しかし応答送信終了後もソケットを破棄せずに使用することによりＫｅｅｐＡｌｉｖｅ仕様に対応することもできる。

１・・・画像処理システム、２・・・ＰＣ、３・・・プリンタ、４・・・ＵＳＢケーブル、２０・・・ＣＰＵ、２５・・・記憶部、２６・・・ＵＳホストインタフェース部、３１・・・制御部、３２・・・ＵＳＢクライアントインタフェース部、３３・・・印刷部、３５・・・記憶部、４２・・・Ｗｅｂブラウザ、４３・・・ＩＰＰ／ＵＳＢ変換プログラム、４４・・・スプーラ、５１・・・ＩＰＰ機能、５２・・・Ｗｅｂサーバ機能、６０・・・設定画面

Claims (6)

1. 画像処理装置と通信回線で接続されている情報処理装置で実行される通信中継プログラムであって、
   クライアントアプリケーションはマルチセッションによって通信するものであり、
   前記クライアントアプリケーションからセッションの確立を要求されると、その要求に応じて前記クライアントアプリケーションとの間に新たなセッションを確立する第１の確立処理と、
   前記第１の確立処理によって前記新たなセッションが確立されると、前記クライアントアプリケーションとの間に確立されている他のセッション以外のセッションによる通信が禁止されているか否かを判断する第１の禁止判断処理と、
   前記第１の禁止判断処理によって通信が禁止されていると判断された場合に、通信が解禁されるまで前記新たなセッションによる通信を待機する第１の待機処理と、
   前記第１の禁止判断処理によって通信が禁止されていないと判断された場合、又は、前記待機処理による待機が解除された場合に、前記新たなセッション以外のセッションによる通信を禁止する第１の排他処理と、
   前記クライアントアプリケーションから処理要求を受信する第１の要求受信処理と、
   前記第１の要求受信処理による前記処理要求の受信中に、前記クライアントアプリケーションから通信の中止が通知されたか否かを判断する第１の中止判断処理と、
   前記第１の中止判断処理によって中止が通知されたと判断されることなく前記第１の要求受信処理による前記処理要求の受信が完了した場合は前記処理要求を前記画像処理装置に送信する一方、前記第１の中止判断処理によって中止が通知されたと判断された場合は前記処理要求を前記画像処理装置に送信しない第１の要求送信処理であって、
   前記第１の要求送信処理で、前記第１の排他処理によって前記新たなセッション以外のセッションによる通信を禁止した状態で、前記第１の要求受信処理により前記新たなセッションを介して受信した前記処理要求を前記画像処理装置に送信する前記第１の要求送信処理と、
   前記第１の中止判断処理によって中止が通知されたと判断されることなく前記第１の要求受信処理による前記処理要求の受信が完了した場合、及び、前記第１の中止判断処理によって中止が通知されたと判断された場合に、前記新たなセッション以外のセッションによる通信を解禁する第１の解禁処理と、
   を前記情報処理装置に実行させる通信中継プログラム。
2. 画像処理装置と通信回線で接続されている情報処理装置で実行される通信中継プログラムであって、
   クライアントアプリケーションはマルチセッションによって通信するものであり、
   前記クライアントアプリケーションからセッションの確立を要求されると、その要求に応じて前記クライアントアプリケーションとの間に新たなセッションを確立する第２の確立処理と、
   前記第２の確立処理によって前記新たなセッションが確立されると、前記クライアントアプリケーションとの間に確立されている他のセッション以外のセッションによる通信が禁止されているか否かを判断する第２の禁止判断処理と、
   前記第２の禁止判断処理によって通信が禁止されていると判断された場合に、通信が解禁されるまで前記新たなセッションによる通信を待機する第２の待機処理と、
   前記第２の禁止判断処理によって通信が禁止されていないと判断された場合、又は、前記待機処理による待機が解除された場合に、前記新たなセッション以外のセッションによる通信を禁止する第２の排他処理と、
   前記クライアントアプリケーションから処理要求を受信する第２の要求受信処理と、
   前記第２の要求受信処理によって前記処理要求の受信が開始されると、当該処理要求の受信が完了するのを待つことなく前記画像処理装置への当該処理要求の送信を開始する第２の要求送信処理であって、
   前記第２の要求送信処理で、前記第２の排他処理によって前記新たなセッション以外のセッションによる通信を禁止した状態で、前記第２の要求受信処理により前記新たなセッションを介して受信した前記処理要求を前記画像処理装置に送信する前記第２の要求送信処理と、
   前記第２の要求受信処理による前記処理要求の受信中に、前記クライアントアプリケーションから通信の中止が通知されたか否かを判断する第２の中止判断処理と、
   前記第２の中止判断処理によって中止が通知されたと判断された場合に、前記画像処理装置に通信の中止を通知する第１の中止通知処理と、
   前記第２の中止判断処理によって中止が通知されたと判断されることなく前記第２の要求受信処理による前記処理要求の受信が完了した場合、及び、前記第２の中止判断処理によって中止が通知されたと判断された場合に、前記新たなセッション以外のセッションによる通信を解禁する第２の解禁処理と、
   を前記情報処理装置に実行させる通信中継プログラム。
3. 画像処理装置と通信回線を介して通信可能に接続されている情報処理装置で実行される通信中継プログラムであって、
   マルチセッションによって通信するクライアントアプリケーションからセッションを確立する要求を受信すると、その要求に応じて前記クライアントアプリケーションとの間にセッションを確立する第３の確立処理と、
   前記第３の確立処理によって確立された前記セッションを介して前記クライアントアプリケーションから処理要求を受信する第３の要求受信処理と、
   前記第３の要求受信処理によって前記処理要求の受信が開始されると、当該処理要求の受信が完了するのを待つことなく前記画像処理装置への当該処理要求の送信を開始する第３の要求送信処理であって、当該処理要求を受信した前記セッションを識別するためのセッション情報を付加したセッション情報付き処理要求を前記画像処理装置に送信する第３の要求送信処理と、
   前記第３の要求送信処理によって送信された前記処理要求に対する応答として前記画像処理装置から前記セッション情報が付加されたセッション情報付き応答を受信する第１の応答受信処理と、
   前記第１の応答受信処理によって受信された前記セッション情報付き応答から前記セッション情報を除去した応答を、当該セッション情報によって識別される前記セッションを介して前記クライアントアプリケーションに送信する第１の応答送信処理と、
   前記第３の要求受信処理による前記処理要求の受信中に、前記クライアントアプリケーションから前記セッションを介して通信の中止が通知されたか否かを判断する第３の中止判断処理と、
   前記第３の中止判断処理によって中止が通知されたと判断された場合に、当該中止が通知された前記セッションの前記セッション情報を付加したセッション情報付き中止通知を前記画像処理装置に送信する第２の中止通知処理と、
   を前記情報処理装置に実行させる、通信中継プログラム。
4. 請求項３に記載の通信中継プログラムであって、
   前記第３の確立処理によって前記セッションが確立されると、確立された前記セッションのセッション識別子を生成する識別子生成処理と、
   前記識別子生成処理によって生成された前記セッション識別子と前記セッションを識別するための識別情報とを対応付けて記憶装置に記憶させる第１の記憶処理と、
   前記記憶装置に記憶されている前記セッション識別子と当該セッション識別子に対応付けられている前記識別情報とを前記記憶装置から削除する削除処理と、
   を前記情報処理装置に実行させ、
   前記第３の要求送信処理において、前記識別子生成処理によって生成された前記セッション識別子を前記セッション情報として前記処理要求に付加し、
   前記第１の応答送信処理において、前記セッション情報付き応答に前記セッション情報として付加されている前記セッション識別子に対応付けられている前記識別情報によって識別される前記セッションを介して前記クライアントアプリケーションに前記応答を送信し、
   前記削除処理において、前記第３の中止判断処理によって中止が通知されたと判断された場合に、当該中止が通知された前記セッションの前記セッション識別子と前記識別情報とを前記記憶装置から削除する、通信中継プログラム。
5. 請求項４に記載の通信中継プログラムであって、
   前記第１の応答送信処理において、前記セッション情報付き応答に前記セッション情報として付加されている前記セッション識別子が前記記憶装置に記憶されていない場合は、前記クライアントアプリケーションに前記応答を送信しない、通信中継プログラム。
6. 請求項１乃至請求項５のいずれか一項に記載の通信中継プログラムであって、
   前記通信回線はユニバーサルシリアルバスである、通信中継プログラム。
   

Images