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

Description

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

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

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

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

一般にＷｅｂブラウザとＷｅｂサーバ機能とはマルチセッションによって通信を行っている。従って、Ｗｅｂブラウザが画像処理装置の設定画面などを表示する場合にも、ＷｅｂブラウザはマルチセッションによってＷｅｂサーバ機能と通信する。

しかしながら、ＵＳＢにはマルチセッションの概念がない。このため、端末装置と画像処理装置とがＵＳＢによって接続されている環境でＷｅｂブラウザとＷｅｂサーバ機能とがマルチセッションによって通信する場合、Ｗｅｂブラウザは複数のセッションでの要求を連続してＷｅｂサーバに送信したとしても、それらの要求に対してＷｅｂサーバはあるセッションでの要求に対しての応答を別のセッションでの要求に対する応答としてＷｅｂブラウザに送信してしまう可能性がある。よって、通信が混乱してしまう可能性がある。

本明細書では、マルチセッションの概念がない通信回線を介してクライアントアプリケーションが画像処理装置とマルチセッションによって混乱なく通信する技術を開示する。

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

上記通信中継プログラムによると、セッション情報によってセッションを識別することができるので、マルチセッションの概念がない通信回線を介してクライアントアプリケーションが画像処理装置と通信する場合であっても、マルチセッションによって混乱なく通信することができる。

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

上記通信中継プログラムによると、セッション情報によってセッションを識別することができるので、マルチセッションの概念がない通信回線を介してクライアントアプリケーションが画像処理装置と通信する場合であっても、マルチセッションによって混乱なく通信することができる。

また、上記通信中継プログラムは、前記第１の応答送信処理によって前記応答が送信された後に、当該応答に付加されていた前記セッション識別子と当該セッション識別子に対応付けられている前記識別情報とを前記記憶装置から削除する削除処理を前記情報処理装置に実行させてもよい。

上記通信中継プログラムによると、不要になったセッション識別子と識別情報とが記憶装置に記憶されたままにならないようにすることができる。

また、上記通信中継プログラムは、前記クライアントアプリケーションは前記処理要求を複数の部分処理要求データに分けて送信するものであり、当該通信中継プログラムは、前記第１の要求送信処理において、前記第１の要求受信処理によって最初の前記部分処理要求データが受信されると前記画像処理装置に前記セッション情報を送信し、その後に前記部分処理要求データを前記画像処理装置に送信してもよい。

上記通信中継プログラムによると、一つの処理要求に対してセッション情報を一度しか送信しないので、部分処理要求データ毎にセッション情報を送信する場合に比べて送信するデータ量を低減することができる。

また、上記通信中継プログラムは、前記第１の要求送信処理において、前記処理要求を複数の部分処理要求データに分割し、前記部分処理要求データ毎に前記セッション情報を付加して前記画像処理装置に送信してもよい。

上記通信中継プログラムによると、部分処理要求データ毎にセッション情報を送信するので、複数の処理要求を並行して画像処理装置に送信することができる。

また、上記通信中継プログラムは、前記第１の要求送信処理において、前記処理要求を所定のデータサイズの部分処理要求データに分割してもよい。

上記通信中継プログラムによると、部分処理要求データ毎にセッション情報を送信するので、複数の処理要求を並行して画像処理装置に送信することができる。

また、上記通信中継プログラムは、前記第１の要求送信処理において、全ての前記部分処理要求データを前記画像処理装置に送信した後に、前記処理要求の送信が完了したことを示す情報を前記画像処理装置に送信してもよい。

上記通信中継プログラムによると、画像処理装置側において処理要求の受信が完了したことを知ることができる。

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

上記通信中継プログラムによると、ユニバーサルシリアルバスを介してクライアントアプリケーションが画像処理装置とマルチセッションによって混乱なく通信することができる。

また、前記クライアントアプリケーションはＷｅｂブラウザであってもよい。

上記通信中継プログラムによると、Ｗｅｂブラウザと画像処理装置との間で通信を中継することができる。

本明細書によって開示される画像処理装置は、情報処理装置と通信回線を介して通信する第２の通信部と、第２の処理部と、を備え、前記第２の処理部は、前記情報処理装置からセッション情報付き処理要求を受信する第２の要求受信処理と、前記第２の要求受信処理によって受信された前記セッション情報付き処理要求に対する応答として、前記セッション情報を付加したセッション情報付き応答を前記情報処理装置に送信する第２の応答送信処理と、を実行する。

上記通信中継プログラムによると、情報処理装置からセッション情報付き処理要求を受信し、その処理要求に対する応答としてセッション情報付き応答を情報処理装置に送信することができる。

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

上記通信中継プログラムによると、第２の処理部と応答部との間で応答が混乱してしまわないようにすることができる。

また、前記応答部はＷｅｂサーバ機能を有していてもよい。

上記通信中継プログラムによると、第２の処理部とＷｅｂサーバ機能との間で応答が混乱してしまわないようにすることができる。

また、上記画像処理装置は、前記第２の応答送信処理において、前記第２の応答受信処理によって受信した前記応答を複数の部分応答データに分割し、分割した前記部分応答データにそれぞれ前記セッション情報を付加して前記情報処理装置に送信してもよい。

上記画像処理装置によると、部分応答データ毎にセッション情報を送信するので、複数の応答を並行して情報処理装置に送信することができる。

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

上記の通信中継プログラムによると、マルチセッションの概念がない通信回線を介してクライアントアプリケーションが画像処理装置とマルチセッションによって混乱なく通信することができる。

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

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

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

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

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

ＣＰＵ２０はＲＯＭ２１や記憶部２５に記憶されているプログラムを実行することによってＰＣ２の各部を制御する。ＲＯＭ２１にはＣＰＵ２０によって実行されるプログラムやデータなどが記憶されている。ＲＡＭ２２はＣＰＵ２０が各種の処理を実行するための主記憶装置として用いられる。ＣＰＵ２０は第１の処理部の一例である。

表示部２３は、液晶ディスプレイなどの表示装置、表示装置を駆動するディスプレイ駆動回路などを備えて構成されている。
操作部２４は、キーボードやマウス、それらが接続されるインタフェースなどで構成されている。

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

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

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

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

印刷部３３は、印刷用紙などのシートに電子写真方式やインクジェット方式などで画像を印刷する装置である。
操作部３４は、液晶ディスプレイなどの表示装置や各種の操作ボタンなどを備えて構成されている。
記憶部３５は、ハードディスクやフラッシュメモリなどの不揮発性のメモリを用いて各種のデータを記憶する装置である。記憶部３５は記憶装置の一例である。

ＵＳＢクライアントインタフェース部３２は、ＵＳＢケーブル４が接続されるジャックなどを備えて構成されており、ＵＳＢケーブル４を介してＰＣ２と通信可能に接続されている。ＵＳＢクライアントインタフェース部３２は第２の通信部の一例である。

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

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

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

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

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

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

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

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

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

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

（３）ＵＳＢにおけるインタフェース
次に、ＵＳＢにおけるインタフェースについて説明する。ＵＳＢでは物理的に一本のＵＳＢケーブル４にインタフェースと呼ばれる１以上の論理的な通信回線が構成される。
ＵＳＢではコントロール転送を行うためのエンドポイント０と呼ばれる特殊なエンドポイントが必ず構成される。エンドポイント０は双方向通信が可能なエンドポイントである。インタフェースはエンドポイント０を介してプリンタ３から取得されるインタフェースディスクリプタに従って構成される。各インタフェースは通常１ないし複数のエンドポイントを有する。

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

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

（４）ＵＳＢを介してマルチセッションによる通信を行う場合の課題
次に、ＵＳＢを介してマルチセッションによる通信を行う場合の課題について説明する。ここではプリンタ３を設定するための通信（ａ）を例に説明する。
先ず、図３を参照して、プリンタ３の設定画面６０について説明する。図３に示す設定画面６０では、プリンタ言語６０ａ、第１のトレイにセットされている用紙サイズ６０ｂ、及び、第２のトレイにセットされている用紙サイズ６０ｃを設定することができる。また、設定画面６０には画像６２ａ、画像６２ｂ、画像６２ｃが表示される。ここでは画像６２ａ〜６２ｃをそれぞれＧＩＦ１、ＧＩＦ２、ＧＩＦ３というものとする。

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

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

ＩＰＰ機能５１はＷｅｂサーバ機能５２から画面データを受信すると、ＵＳＢを介してその画面データをＩＰＰ／ＵＳＢ変換プログラム４３に送信する。
ＩＰＰ／ＵＳＢ変換プログラム４３はＩＰＰ機能５１から画面データを受信すると、Ｗｅｂブラウザ４２から受信したＧＥＴコマンドに対する応答としてその画面データをＷｅｂブラウザ４２に送信する。

Ｗｅｂブラウザ４２はこの画面データを解析し、ページを表示するに足りない部品（ＧＩＦ１、ＧＩＦ２、ＧＩＦ３など）を同様に要求する。この場合に、Ｗｅｂブラウザ４２はマルチセッションによる通信が可能であるので、足りない部品（ＧＩＦ１，ＧＩＦ２、ＧＩＦ３）毎にセッションを確立して画像の送信を要求する。
例えば、Ｗｅｂブラウザ４２は最初にＧＩＦ１の送信を要求するためのセッションの確立を要求し、そのセッションを介して送信した処理要求に対する応答を待たずに、ＧＩＦ２の送信を要求するためのセッションの確立を要求する。同様に、Ｗｅｂブラウザ４２はＧＩＦ２の送信を要求するためのセッションを介して送信した処理要求に対する応答を待たずに、ＧＩＦ３の送信を要求するためのセッションの確立を要求する。

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

そこで、ＩＰＰ／ＵＳＢ変換プログラム４３は、処理要求（上述した例ではＧＥＴコマンド）にセッションを識別するためのセッションＩＤを付加したセッションＩＤ付き処理要求をＩＰＰ機能５１に送信し、ＩＰＰ機能５１からその処理要求に対する応答として当該セッションＩＤが付加された応答であるセッションＩＤ付き応答を受信する。セッションＩＤはセッション情報及びセッション識別子の一例である。
そして、ＩＰＰ／ＵＳＢ変換プログラム４３はセッションＩＤ付き応答からセッションＩＤを除去した応答を、当該セッションＩＤによって識別されるセッションを介してＷｅｂブラウザ４２に送信する。

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

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

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

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

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

プリンタ３は、セッションＩＤ付き処理要求を受信すると、その処理要求に対する応答としてＧＩＦ２をＩＰＰ／ＵＳＢ変換プログラム４３に送信する（Ｓ０１２）。このときプリンタ３はセッションＩＤ付き処理要求に付加されていたセッションＩＤをその応答に付加して送信する。
ＩＰＰ／ＵＳＢ変換プログラム４３はセッションＩＤ付き応答を受信すると、セッションＩＤ付き応答からセッションＩＤを除去した応答を、そのセッションＩＤによって識別されるセッション、すなわちセッション２を介してＷｅｂブラウザ４２に応答を送信する（Ｓ０１３）。
セッション３についても同様にセッションの要求とそれに対する応答が行われる。
これら一連の処理によってＧＩＦ１〜ＧＩＦ３がＷｅｂブラウザ４２に読み込まれ、設定画面６０上にＧＩＦ１〜ＧＩＦ３が表示される。

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

（６）処理要求のデータ構造、及び、応答のデータ構造
次に、図５を参照して、セッションＩＤが付加された処理要求のデータ構造、及び、セッションＩＤが付加された応答のデータ構造について説明する。

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

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

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

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

サイズ情報データ、各通信データ、付加データ、あるいは付加データを細切れにした各データ塊はそれぞれ部分処理要求データの一例である。つまり、ＩＰＰ／ＵＳＢ変換プログラム４３はＷｅｂブラウザ４２から処理要求を複数の部分処理要求データに分けて受信する。
なお、部分処理要求データは処理の仕方によりいろいろな形態が考えられる。例えば固定長、あるいは特定の条件によってきまるデータ長ごとに受信し、それぞれを部分処理要求データとすることもできる。

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

（７）ＩＰＰ／ＵＳＢ変換プログラム４３による通信中継処理の詳細
次に、図６を参照して、ＩＰＰ／ＵＳＢ変換プログラム４３による通信中継処理についてより具体的に説明する。前述したようにＩＰＰ／ＵＳＢ変換プログラム４３は常駐プログラムとして実行されるものであり、本処理はＰＣ２に電源が投入されると開始される。
ここで、本処理はＷｅｂブラウザ４２とＩＰＰ機能５１との間で通信を中継する処理であり、スプーラ４４とＩＰＰ機能５１との間で通信を中継する処理は本処理とは別の処理として実行されるものとする。当該別の処理についての説明は省略する。

Ｓ１０１では、ＩＰＰ／ＵＳＢ変換プログラム４３はインタフェース１を排他的に用いるためのミューテックスを生成する。ミューテックスは排他処理を行うための仕組みであって、プログラム言語によって提供される仕組みである。ミューテックスの詳細については後述する。

なお、ここではミューテックスを用いて排他処理を行う場合を例に説明するが、排他処理を行う方法はこれに限られない。例えばセマフォを用いて行ってもよいし、ミューテックスやセマフォを用いず独自の方法で行ってもよい。

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

ユーザがＷｅｂブラウザ４２を立ち上げ、ＩＰアドレスとして１２７．０．０．１、ポート番号として８０を設定すると、Ｗｅｂブラウザ４２は当該アドレスおよびポート番号に対してセッションの確立を要求する。この要求がアクセプト要求となる。

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

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

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

Ｓ２０２では、スレッドはＳ２０１で生成したソケットを識別すためのＩＤ（Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）を生成する。ソケットとセッションとは一対一に対応しているので、ソケットを識別すためのＩＤはセッションを識別するためのＩＤとして用いることができる。以降の説明ではソケットを識別すためのＩＤのことをセッションＩＤというものとする。Ｓ２０２は識別子生成処理の一例である。

Ｓ２０３では、スレッドはＳ２０１で確立したセッションを介してＷｅｂブラウザ４２から部分処理要求データを受信する。Ｓ２０３は第１の要求受信処理の一例である。
Ｓ２０４では、スレッドはＳ２０３で受信した部分処理要求データにＳ２０２で生成したセッションＩＤを付加する。具体的には、部分処理要求データの最初の８バイトをセッションＩＤとする、又は、部分処理要求データの最初の一行はセッションＩＤとするなど、予め決められたルールによってセッションＩＤを付加する。

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

一方、ミューテックスが他のスレッドによって取得されている場合は、当該スレッドはミューテックスを取得できるまで待機状態となる。これにより当該スレッドは通信が禁止された状態となる。そして、他のスレッドがミューテックスを解放すると、当該スレッドより先に待機状態になっているスレッドがある場合は当該先に待機状態になっているスレッドによってそのミューテックスが取得され、当該スレッドは引き続き待機状態となる。当該スレッドより先に待機状態になっているスレッドがない場合は、当該スレッドによってミューテックスが取得される。
スレッドはミューテックスを取得するとＳ２０６に進む。

Ｓ２０６では、スレッドはＳ２０４でセッションＩＤを付加したセッションＩＤ付き部分処理要求データを、ＵＳＢを介してＩＰＰ機能５１に送信する。Ｓ２０６は第１の要求送信処理の一例である。

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

Ｓ２０８では、スレッドはＷｅｂブラウザ４２から次の部分処理要求データを受信する。
Ｓ２０９では、スレッドはＳ２０８で受信した部分処理要求データを、ＵＳＢを介してＩＰＰ機能５１に送信する。ただし、ここではスレッドは部分処理要求データにセッションＩＤを付加せずに送信する。

Ｓ２１０では、スレッドはインタフェース１の排他処理を終了する。従ってＳ２０５から本Ｓ２１０までの間、換言すれば、Ｓ２０６、Ｓ２０９によりそのセッションにおけるすべての部分処理要求データを送信するまでの間、排他処理が行われ、その間に他のスレッドの処理により他のセッションの部分処理要求データが割り込むことはない。
Ｓ２１１では、スレッドはＳ２０１で生成したソケットを識別するためのソケット情報とＳ２０２で生成したセッションＩＤとを対応付けて記憶部２５に記憶させる。Ｓ２１１は記憶処理の一例である。また、ソケット情報はセッションを識別するための識別情報の一例である。

ただし、本処理が終了してもソケットは存続し続ける。つまり、ＩＰＰ／ＵＳＢ変換プログラム４３とＷｅｂブラウザ４２とのセッションは維持されたままとなる。これは、そのセッションを用いてＷｅｂブラウザ４２に応答を送信するためである。

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

Ｓ３０１では、ＩＰＰ／ＵＳＢ変換プログラム４３はＩＰＰ機能５１に送信した処理要求に対する応答をＩＰＰ機能５１から受信する。詳しくは後述するが、ＩＰＰ機能５１は応答を複数の部分応答データに分割し、最初の部分応答データにセッションＩＤを付加してＩＰＰ／ＵＳＢ変換プログラム４３に送信する。Ｓ３０１ではそのセッションＩＤが付加されたセッションＩＤ付き部分応答データが受信される。Ｓ３０１は第１の応答受信処理の一例である。

Ｓ３０２では、ＩＰＰ／ＵＳＢ変換プログラム４３はセッションＩＤ付き部分応答データからセッションＩＤを取得する。ＩＰＰ機能５１は、例えば応答データの最初の８バイトをセッションＩＤとする、又は、部分処理要求データの最初の一行はセッションＩＤとするなど、予め決められたルールによってセッションＩＤを付加する。よって、ＩＰＰ／ＵＳＢ変換プログラム４３は、応答データのうち、ルールに従って付加された部分をセッションＩＤとして取得する。
Ｓ３０３では、ＩＰＰ／ＵＳＢ変換プログラム４３はＳ３０２で取得したセッションＩＤと同じセッションＩＤに対応付けられて記憶されているソケット情報を記憶部２５から読み出す。

Ｓ３０４では、ＩＰＰ／ＵＳＢ変換プログラム４３はＳ３０１で受信したセッションＩＤ付き部分応答データからセッションＩＤを除去する。
Ｓ３０５では、ＩＰＰ／ＵＳＢ変換プログラム４３はＳ３０４でセッションＩＤを除去した部分応答データを、Ｓ３０３で読み出したソケット情報によって識別されるセッションを介してＷｅｂブラウザ４２に送信する。Ｓ３０５は第１の応答送信処理の一例である。

Ｓ３０６では、ＩＰＰ／ＵＳＢ変換プログラム４３はＩＰＰ機能５１からの応答の受信が完了したか否かを判断する。この判断はＳ２０７と同様の手順により行われる。ＩＰＰ／ＵＳＢ変換プログラム４３は、応答の受信が完了していない場合はＳ３０７に進み、完了している場合はＳ３０９に進む。

Ｓ３０７では、ＩＰＰ／ＵＳＢ変換プログラム４３はＵＳＢを介して次の部分応答データを受信する。なお、次の部分応答データにはセッションＩＤは付加されていないものとする。
Ｓ３０８では、ＩＰＰ／ＵＳＢ変換プログラム４３はＳ３０７で受信した部分応答データを、Ｓ３０３で読み出したソケット情報によって識別されるセッションを介してＷｅｂブラウザ４２に送信する。

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

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

（８−１）ＩＰＰ／ＵＳＢ変換プログラムから処理要求を受信する処理
先ず、図９を参照して、ＩＰＰ機能５１がＩＰＰ／ＵＳＢ変換プログラム４３から処理要求を受信する処理について説明する。
Ｓ４０１では、ＩＰＰ機能５１はＩＰＰ／ＵＳＢ変換プログラム４３からＵＳＢを介して部分処理要求データを受信する。前述したように最初の部分処理要求データにはセッションＩＤが付加されている。Ｓ４０１は第２の要求受信処理の一例である。

Ｓ４０２では、ＩＰＰ機能５１はＳ４０１で受信したセッションＩＤ付き部分処理要求データからセッションＩＤを取得する。Ｓ２０４において、セッションＩＤは予め決められたルールに従って部分処理要求データに付加される。よって、ＩＰＰ機能５１は、部分処理要求データのうち、ルールに従って付加された部分をセッションＩＤとして取得する。
Ｓ４０３では、ＩＰＰ機能５１はＳ４０２で取得したセッションＩＤが、記憶部３５に記憶されているか否かを判断する。詳しくは後述するが、ＩＰＰ機能５１は、セッションＩＤ付処理要求データを受信した新たなソケットを生成すると、そのソケットを識別するための通信識別情報に対応付けて記憶部３５に記憶する。Ｓ４０３にて、ＩＰＰ機能５１は、記憶されていないと判断した場合はＳ４０４に進み、記憶されていると判断した場合はＳ４０６に進む。Ｓ４０３は記憶判断処理の一例である。

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

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

Ｓ４０９では、ＩＰＰ機能５１は処理要求の受信が完了したか否かを判断する。この判断は前述したＳ２０７と同様に行うことができる。ＩＰＰ機能５１は、処理要求の受信が完了していない場合はＳ４１０に進み、完了している場合はＳ４１１に進む。
Ｓ４１０では、ＩＰＰ機能５１はＩＰＰ／ＵＳＢ変換プログラム４３からＵＳＢを介して次の部分処理要求データを受信する。ただし、ここで受信される部分処理要求データにはセッションＩＤは付加されていない。
Ｓ４１１では、ＩＰＰ機能５１はスレッドを生成する。このスレッドはＷｅｂサーバ機能５２から応答を受信してＩＰＰ／ＵＳＢ変換プログラム４３に送信するためのものである。

（８−２）Ｗｅｂサーバ機能から応答を受信する処理
次に、図１０を参照して、ＩＰＰ機能５１がＷｅｂサーバ機能５２から応答を受信する処理について説明する。この処理は前述したＳ４１１で生成されたスレッドによって実行される。
Ｓ５０１では、スレッドはＳ４０２で取得されたセッションＩＤを継承するとともに、Ｓ４０４で生成されたソケットのソケット情報、又は、Ｓ４０６で読み出されたソケット情報を継承する。

Ｓ５０２では、スレッドはＷｅｂサーバ機能５２から応答を受信する。ここでは、スレッドはＷｅｂサーバ機能５２からの応答の受信が完了した後にＳ５０３に進むものとする。例えばＷｅｂサーバ機能５２から応答を部分応答データに分けて受信する場合には全ての部分応答データの受信が完了した後にＳ５０３に進むものとする。Ｓ５０２は第２の応答受信処理の一例である。
Ｓ５０３では、スレッドはインタフェース１の排他処理を実行する。具体的には、スレッドはインタフェース１のミューテックスを取得する。なお、ここで取得するミューテックスはＳ１０１で生成されたものとは異なるものである。ここで取得するミューテックスは例えばプリンタ３に電源が投入されたときの初期化処理において生成されたものである。

Ｓ５０４では、スレッドは応答を複数の部分応答データに分割し、最初の部分応答データにＳ５０１で継承したセッションＩＤを付加してＩＰＰ／ＵＳＢ変換プログラム４３に送信する。
Ｓ５０５では、スレッドは２番目以降の部分応答データにはセッションＩＤを付加せずに順次ＩＰＰ／ＵＳＢ変換プログラム４３に送信する。
上述したＳ５０４及びＳ５０５は第２の応答送信処理の一例である。

Ｓ５０６では、スレッドはインタフェース１の排他処理を終了する。
Ｓ５０７では、スレッドはＳ５０１で継承したセッションＩＤ及びソケット情報を記憶部３５から削除する。

（９）実施形態の効果
以上説明したＩＰＰ／ＵＳＢ変換プログラム４３によると、Ｗｅｂブラウザ４２から受信した処理要求にセッションＩＤを付加する。そして、ＩＰＰ／ＵＳＢ変換プログラム４３によると、ＩＰＰ機能５１にセッションＩＤ付き処理要求を送信し、その応答としてＩＰＰ機能５１からセッションＩＤ付き応答を受信するので、ＩＰＰ機能５１から応答を受信したとき、どのセッションを介してＷｅｂブラウザ４２にその応答を送信すればよいかを、当該応答に付加されているセッションＩＤによって識別できる。
よってＩＰＰ／ＵＳＢ変換プログラム４３によると、ＵＳＢのようなマルチセッションの概念がない通信回線でＷｅｂブラウザとＷｅｂサーバとが通信を行う場合であっても、ＵＳＢ（より具体的にはインタフェース１）を介してＷｅｂブラウザ４２がプリンタ３とマルチセッションによって混乱なく通信することができる。
つまり、従来はＵＳＢにはセッションの概念がなかったので、セッションＩＤを付加する、ということは行われていなかったが、ＩＰＰ／ＵＳＢ変換プログラム４３でそれを行うことにより、ＩＰＰ ｏｖｅｒ ＵＳＢでも混信なく通信を行うことができる。

更に、ＩＰＰ／ＵＳＢ変換プログラム４３によると、処理要求をＩＰＰ機能５１に送信したあとその処理要求の応答を待つことなく別の処理要求に関するデータの送受信を行えるため、処理要求の応答待ちのためにＵＳＢでデータが非転送状態になる時間を縮小でき、処理速度が向上する。

更に、ＩＰＰ／ＵＳＢ変換プログラム４３によると、セッションＩＤ付き応答に付加されていたセッションＩＤと当該セッションＩＤに対応付けられているソケット情報とを記憶部２５から削除するので、不要になったセッションＩＤとソケット情報とが記憶部２５に記憶されたままにならないようにすることができる。

更に、ＩＰＰ／ＵＳＢ変換プログラム４３によると、一つの処理要求に対してセッションＩＤを一度しか送信しないので、部分処理要求データ毎にセッションＩＤを送信する場合に比べて送信するデータ量を低減することができる。

また、プリンタ３によると、ＩＰＰ／ＵＳＢ変換プログラム４３からセッションＩＤ付き処理要求を受信し、その処理要求に対する応答としてセッションＩＤ付き応答をＰＣ２に送信することができる。これにより、処理要求と応答との対応関係を確実にとることができる。

更に、プリンタ３によると、ＩＰＰ機能５１とＷｅｂサーバ機能５２との間で応答が混乱してしまわないようにすることができる。

＜実施形態２＞
次に、実施形態２を図１１ないし図１６によって説明する。
図１１を参照して、実施形態２に係るセッションＩＤ付き処理要求について説明する。前述した実施形態１に係るＩＰＰ／ＵＳＢ変換プログラム４３は一つの処理要求についてＩＰＰ機能５１にセッションＩＤを一度しか送信しない。これに対し、実施形態２に係るＩＰＰ／ＵＳＢ変換プログラム４３は、Ｗｅｂブラウザ４２から受信した処理要求を複数の部分処理要求データに分割し、部分処理要求データ毎にセッションＩＤを付加して送信する。

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

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

図１１では省略しているが、ＩＰＰ機能５１も同様に応答をヘッダと付加データとの部分応答データに分け、各部分応答データにセッションＩＤを付加してＩＰＰ／ＵＳＢ変換プログラム４３に送信するものとする。

（１）Ｗｅｂブラウザから処理要求を受信する処理
次に、実施形態２に係るＷｅｂブラウザから処理要求を受信する処理について説明する。

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

Ｓ６０３では、スレッドはＳ６０２で生成したソケットを識別するためのソケット情報とＳ６０２で生成したセッションＩＤとを対応付けて記憶部２５に記憶させる。
Ｓ６０４では、スレッドはＳ６０１で確立したセッションを介してＷｅｂブラウザ４２から処理要求のヘッダを受信する。
Ｓ６０５では、スレッドはインタフェース１の排他処理を実行する。

Ｓ６０６では、スレッドはＳ６０２で生成したセッションＩＤを、インタフェース１を介してＩＰＰ機能５１に送信する。この送信は種々の方法で行うことができる。例えば以下のＳ６０７で送信する部分処理要求データの最初の８バイトをセッションＩＤとする、又は、部分処理要求データの最初の一行はセッションＩＤとするなど、予め決められた適宜のルールによってセッションＩＤを送信することができる。

Ｓ６０７では、スレッドはＳ６０４で受信したヘッダを、インタフェース１を介してＩＰＰ機能５１に送信する。ここで、処理要求のヘッダが複数の通信データからなる場合は、Ｓ６０７においてそれら複数の通信データがＩＰＰ機能５１に送信される。
Ｓ６０８では、スレッドはインタフェース１の排他処理を終了する。

Ｓ６０９では、スレッドは付加データがあるか否かを判断する。具体的には、スレッドはＳ６０４で受信したヘッダにＣｏｎｔｅｎｔ-Ｌｅｎｇｔｈ又はｃｈｕｎｋｅｄが含まれている場合は付加データがあると判断し、いずれも含まれていない場合は付加データがないと判断する。スレッドは、付加データがある場合はＳ６１０に進み、付加データがない場合は本処理を終了する。

Ｓ６１０では、スレッドは付加データ送信処理を実行する。付加データ送信処理はＷｅｂブラウザ４２から付加データを受信してＩＰＰ機能５１に送信する処理である。付加データ送信処理の詳細については後述する。

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

Ｓ７０２では、スレッドはＳ６０４で受信したヘッダからサイズ情報データを取得する。
Ｓ７０３では、スレッドはＷｅｂブラウザ４２からＳ７０２で取得したサイズ情報データによって示されるデータサイズの付加データを受信する。
Ｓ７０４では、スレッドはインタフェース１の排他処理を実行する。

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

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

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

Ｓ７１４では、スレッドは付加データの受信が完了したか否かを判断する。具体的には、受信した付加データに続くデータ塊があるか否かを判断する。この判断はＳ２０７と同様の手順により行われる。スレッドは、付加データの受信が完了した場合は本処理を終了して「Ｗｅｂブラウザから処理要求を受信する処理」に戻り、未だ完了していない場合はＳ７０８に戻って処理を繰り返す。
ただし、本処理が終了してもソケットは存続し続ける。

（１−３）ＩＰＰ機能から応答を受信する処理
次に、図１４を参照して、実施形態２に係るＩＰＰ／ＵＳＢ変換プログラム４３がＩＰＰ機能５１から応答を受信する処理について説明する。ここでは図８と実質的に同一の処理には同一の符号を付して説明を省略する。

Ｓ８０１では、ＩＰＰ／ＵＳＢ変換プログラム４３はＩＰＰ機能５１からインタフェース１を介してセッションＩＤ付きヘッダ、セッションＩＤ付き付加データの単位で応答を受信する。具体的には、最初にＳ８０１が実行された時点ではセッションＩＤ付きヘッダが受信され、その後、Ｓ３０６で処理要求の受信が完了していないと判断されて再度Ｓ８０１が実行されたときにはセッションＩＤ付き付加データが受信される。
以後の処理は図８の同一番号を付した部分と同じ処理を行う。ただし、図１４の処理では各部分応答データごとにセッションＩＤが付与されているので、ＩＰＰ／ＵＳＢ変換プログラム４３はＳ３０６にて「否」と判断した場合はＳ８０１に戻り、再びセッションＩＤ付部分応答データを受信するとともに、Ｓ３０２、Ｓ３０３を経てＳ３０４にてセッションＩＤを削除したのちにＳ３０５においてＷｅｂブラウザ４２に送信する。

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

（２−１）ＩＰＰ／ＵＳＢ変換プログラムから処理要求を受信する処理
図１５を参照して、実施形態２に係るＩＰＰ機能５１がＩＰＰ／ＵＳＢ変換プログラム４３から処理要求を受信する処理について説明する。ここでは図９と実質的に同一の処理には同一の符号を付して説明を省略する。

Ｓ９０１では、ＩＰＰ機能５１はＩＰＰ／ＵＳＢ変換プログラム４３からインタフェース１を介してセッションＩＤ付きヘッダ、セッションＩＤ付き付加データの単位で処理要求を受信する。具体的には、最初にＳ９０１が実行された時点ではセッションＩＤ付きヘッダが受信され、その後、Ｓ４０９で処理要求の受信が完了していないと判断されて再度Ｓ９０１が実行されたときにはセッションＩＤ付き付加データが受信される。
以下は図９とほぼ同様であるが、Ｓ４０９で「否」と判断された場合は、ＩＰＰ機能５１はＳ９０１に戻る。これは実施形態２では各部分処理要求データにセッションＩＤが付与されているので、それらすべてをＳ４０７にて除去した上でＷｅｂサーバ機能５２に送信するためである。

（２−２）Ｗｅｂサーバ機能から応答を受信する処理
図１６を参照して、実施形態２に係るＩＰＰ機能５１がＷｅｂサーバ機能５２から応答を受信する処理について説明する。ここでは図１０と実質的に同一の処理には同一の符号を付して説明を省略する。

Ｓ１００１では、スレッドはＷｅｂサーバ機能５２から応答としてヘッダ、又は、付加データを受信する。具体的には、最初にＳ１００１が実行された時点ではヘッダが受信され、その後、Ｓ１００４で応答の受信が完了していないと判断されて再度Ｓ１００１が実行されたときには付加データが受信される。

また、実施形態２ではヘッダ及び付加データのそれぞれにセッションＩＤを付加してＩＰＰ／ＵＳＢ変換プログラム４３に送信される。例えばＳ１００１でヘッダが受信された場合はＳ１００２においてそのヘッダにセッション情報が付加され、Ｓ１００３においてセッション情報が付加されているヘッダがＩＰＰ／ＵＳＢ変換プログラム４３に送信される。一方、Ｓ１００１で付加データが受信された場合はＳ１００２においてその付加データにセッション情報が付加され、Ｓ１００３においてセッション情報が付加されている付加データがＩＰＰ／ＵＳＢ変換プログラム４３に送信される。
Ｓ１００４では、スレッドはＷｅｂサーバ機能５２からの応答の受信が完了したか否かを判断する。スレッドは、完了したと判断した場合はＳ５０７に進み、完了していないと判断した場合はＳ１００１に戻る。

（３）実施形態の効果
以上説明した実施形態２に係るＩＰＰ／ＵＳＢ変換プログラム４３によると、処理要求を複数の部分処理要求データ（具体的にはヘッダ及び付加データ）に分割し、部分処理要求データ毎にセッションＩＤを付加してプリンタ３に送信するので、複数の処理要求を並行してプリンタ３に送信することができる。

また、実施形態２に係るプリンタ３によると、Ｗｅｂサーバ機能５２から受信した応答を複数の部分応答データ（具体的にはヘッダ及び付加データ）に分割し、分割した部分応答データにそれぞれセッション情報を付加してＩＰＰ／ＵＳＢ変換プログラム４３に送信するので、複数の応答を並行してＩＰＰ／ＵＳＢ変換プログラム４３に送信することができる。
また、実施形態２に係るＩＰＰ／ＵＳＢ変換プログラム４３及びプリンタ３によると、Ｃｈｕｎｋｅｄで送られる長いデータもそれぞれのデータ塊ごとに送信でき、かつそのデータ塊の送信の合間に別のデータを送ることもできるので、実施例１に比べてさらに効率よくデータ転送が可能になり、高速動作が期待できる。

＜実施形態３＞
次に、実施形態３を図１７ないし図１８によって説明する。
図１７を参照して実施形態３に係る処理要求について説明する。前述した実施形態２に係るＩＰＰ／ＵＳＢ変換プログラム４３は処理要求をヘッダと付加データとの部分処理要求データに分けてＩＰＰ機能５１に送信する場合を例に説明した。これに対し、実施形態３に係るＩＰＰ／ＵＳＢ変換プログラム４３は、処理要求を所定のデータサイズ（例えば２０４８バイト）の部分処理要求データに分割し、分割した部分処理要求データにそれぞれセッションＩＤとＬａｓｔＦｌａｇとを付加してＩＰＰ機能５１に送信する。

ＬａｓｔＦｌａｇとは、処理要求の送信が完了したか否かを０（零）又は１で示す情報である。０は処理要求の送信が完了していないことを示し、１は処理要求の送信が完了したことを示す。ＩＰＰ機能５１はＬａｓｔＦｌａｇを参照することにより、処理要求の受信が完了したか否かを判断することができる。

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

（１）Ｗｅｂブラウザから処理要求を受信する処理
次に、図１８を参照して、実施形態３に係るＩＰＰ／ＵＳＢ変換プログラム４３がＷｅｂブラウザ４２から処理要求を受信する処理について説明する。
Ｓ１１０１では、スレッドはアクセプト処理を実行する。
Ｓ１１０２では、スレッドはＷｅｂブラウザ４２からヘッダを受信する。

Ｓ１１０３では、スレッドはＷｅｂブラウザ４２から付加データを受信する。スレッドは付加データの受信が完了した後にＳ１１０４に進む。
Ｓ１１０４では、スレッドはＳ１１０２で受信したヘッダのデータサイズ及びＳ１１０３で受信した付加データのデータサイズの合計値を計算し、計算した合計値を、未送信のデータ（残データという）のデータサイズを示す変数である残データ数に初期値として設定する。
Ｓ１１０５では、スレッドはセッションＩＤを生成する。

Ｓ１１０６では、スレッドはＳ１１０１で生成したソケットを示すソケット情報とＳ１１０５で生成したセッションＩＤとを対応付けて記憶部２５に記憶させる。
Ｓ１１０７では、スレッドはインタフェース１の排他処理を実行する。
Ｓ１１０８では、スレッドは残データ数が２０４８より大きいか否かを判断し、２０４８より大きい場合は１１０９に進み、２０４８以下である場合はＳ１１１４に進む。

Ｓ１１０９では、スレッドはＳ１１０５で生成したセッションＩＤをＩＰＰ機能５１に送信する。
Ｓ１１１０では、スレッドは残データ数から２０４８を減じる。
Ｓ１１１１では、スレッドはサイズ情報データとして２０４８をＩＰＰ機能５１に送信する。
Ｓ１１１２では、スレッドはＬａｓｔＦｌａｇとして０（零）をＩＰＰ機能５１に送信する。
Ｓ１１１３では、スレッドはＩＰＰ機能５１に２０４８バイト分の部分処理要求データを送信してＳ１１０８に戻る。

Ｓ１１１４では、スレッドはＳ１１０５で生成したセッションＩＤをＩＰＰ機能５１に送信する。
Ｓ１１１５では、スレッドはサイズ情報データとして残データ数をＩＰＰ機能５１に送信する。
Ｓ１１１６では、スレッドはＬａｓｔＦｌａｇとして１をＩＰＰ機能５１に送信する。
Ｓ１１１７では、スレッドは残データ数によって示されるデータサイズの残データをＩＰＰ機能５１に送信する。
Ｓ１１１８では、スレッドはインタフェース１の排他処理を終了する。
ＩＰＰ機能５１は、受信した部分処理要求データより、セッションＩＤおよびＬａｓｔＦｌａｇを除去してＷＥＢサーバに送信する。
ＩＰＰ機能５１からＩＰＰ／ＵＳＢ変換プログラム４３に応答を送信する際にも同様にして送信する。すなわち応答データを２０４８バイトごとの部分応答データごとに分け、それぞれにデータ数情報およびＬａｓｔＦｌａｇ（０）を付して送信し、最後の部分応答データに関してはそのデータ数情報およびＬａｓｔＦｌａｇ（１）を付して送信する。
ＩＰＰ/ＵＳＢ変換プログラム４３は、ＩＰＰ機能５１から受信した部分応答データからセッションＩＤ及びＬａｓｔＦｌａｇを除去してＷｅｂブラウザ４２に送信する。
セッションＩＤ、ソケットの使用方法などは実施形態１及び実施形態２と同じである。

（２）実施形態の効果
以上説明した実施形態３に係るＩＰＰ／ＵＳＢ変換プログラム４３によると、決められたサイズの部分処理要求データに分け、それぞれの部分処理要求データにセッション情報を付加してＩＰＰ機能５１に送信するので、複数の処理要求を並行してプリンタ３に送信することができる。

更に、ＩＰＰ／ＵＳＢ変換プログラム４３によると、全ての部分処理要求データをプリンタ３に送信した後に、処理要求の送信が完了したことを示す情報をプリンタ３に送信するので、プリンタ３側において処理要求の受信が完了したことを知ることができる。

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

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

（２）上記実施形態２では処理要求を複数の部分処理要求データに分割する例としてヘッダと付加データとに分割する場合を例に説明した。しかしながら、処理要求を複数の部分処理要求データに分割する基準はこれに限られるものではなく、適宜の基準で分けることができる。例えばＷｅｂブラウザ４２から一度に受信する通信データの単位に分けてもよい。

（３）上記実施形態ではマルチセッションによって通信するクライアントアプリケーションとしてＷｅｂブラウザ４２を例に説明した。しかしながら、クライアントアプリケーションはマルチセッションによって通信するものであれば他のアプリケーションであってもよい。

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

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

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

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

（８）上記実施形態では制御部３１が一つのＣＰＵ３１ａを備える場合を例に説明した。これに対し、制御部３１は１以上のＣＰＵによって構成されてもよいし、ＡＳＩＣによって構成されてもよいし、１以上のＣＰＵとＡＳＩＣとの組み合わせによって構成されてもよい。

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

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

Claims (3)

1. Ｗｅｂブラウザを有しマルチセッションによって通信する情報処理装置とマルチセッションの概念がないＩＰＰ over ＵＳＢ規格を使ってユニバーサルシリアルバス（ＵＳＢ）回線を介して通信する通信部と、
   処理部と、
   前記処理部から受信した処理要求に対する応答を前記処理部に送信する応答部と、
   を備え、
   前記処理部は、
   前記情報処理装置からセッションを識別するためのセッション情報が付加されたセッション情報付き処理要求を受信する要求受信処理と、
   前記要求受信処理によって受信された前記セッション情報付き処理要求に対する応答として、前記セッション情報を付加したセッション情報付き応答を前記情報処理装置に送信する応答送信処理と、
   前記要求受信処理によって前記セッション情報付き処理要求が受信されると、当該セッション情報付き処理要求に付加されているセッション情報が、当該処理部と前記応答部との間に確立されている通信を識別するための通信識別情報に対応付けられて記憶装置に記憶されているか否かを判断する記憶判断処理と、
   前記記憶判断処理によって記憶されていないと判断された場合に、前記応答部との間に新たな通信を確立する確立処理と、
   前記確立処理によって確立された前記新たな通信を識別するための通信識別情報と前記セッション情報とを対応付けて前記記憶装置に記憶させる記憶処理と、
   前記記憶判断処理によって記憶されていると判断された場合は、前記セッション情報付き処理要求から前記セッション情報を除去した処理要求を、当該セッション情報に対応付けられている前記通信識別情報によって識別される前記通信を介して前記応答部に送信する一方、前記記憶判断処理によって記憶されていないと判断された場合は、前記セッション情報付き処理要求から前記セッション情報を除去した処理要求を、前記確立処理によって確立された前記新たな通信を介して前記応答部に送信する要求送信処理と、
   前記応答部から前記通信を介して前記処理要求に対する応答を受信する応答受信処理と、
   を実行し、
   前記応答送信処理において、前記応答受信処理によって前記応答部から受信された前記応答に当該応答を受信した前記通信の前記通信識別情報に対応付けられて前記記憶装置に記憶されている前記セッション情報を付加したセッション情報付き応答を前記情報処理装置に送信する、画像処理装置。
2. 請求項１に記載の画像処理装置であって、
   前記応答部はＷｅｂサーバ機能を有する、画像処理装置。
3. 請求項１乃至請求項２のいずれか一項に記載の画像処理装置であって、
   前記応答送信処理において、前記応答受信処理によって受信した前記応答を複数の部分応答データに分割し、分割した前記部分応答データにそれぞれ前記セッション情報を付加して前記情報処理装置に送信する、画像処理装置。
   

Images