JP4839796B2 - ネットワーク装置における通信処理 - Google Patents

Description

本発明は、ネットワーク装置における通信処理の技術に関する。

ネットワークを利用した印刷システムでは、例えば、プリンタがＵＳＢケーブルを介してプリントサーバに接続され、プリントサーバとクライアントコンピュータとがＬＡＮなどのネットワークを介して接続される。

上記の印刷システムでは、クライアントコンピュータとプリントサーバとの通信は、例えばＨＴＴＰプロトコルに従って実行されるが、プリントサーバとプリンタとの通信は、例えばメーカの独自のプロトコル（以下、「内部プロトコル」とも呼ぶ）に従って実行される。このため、プリントサーバは、ＨＴＴＰプロトコルと内部プロトコルとの変換を行う。具体的には、プリントサーバは、一方のプロトコルに従った通信データのヘッダを他方のプロトコルに従った通信データのヘッダに変換する。なお、ヘッダの変換処理では、一方のプロトコルに従ったフィールド項目は、他方のプロトコルに従ったフィールド項目に変更される。

プリントサーバとプリンタとの間の第２種の通信プロトコルがクライアントコンピュータとプリントサーバとの間の第１種の通信プロトコルと異なれば、第１種の通信プロトコルがＨＴＴＰプロトコルから他のプロトコルに変更される場合に、プリントサーバのみを変更すれば済み、プリンタを変更せずに済むという利点がある。

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

ところで、ＨＴＴＰプロトコルでは、ヘッダ内に記述可能な多種類のフィールド項目（以下、「ＨＴＴＰフィールド項目」とも呼ぶ）が準備されている。一方、内部プロトコルでは、通常、ＨＴＴＰプロトコルで準備されている多種類のＨＴＴＰフィールド項目のうち、比較的少数の一部のＨＴＴＰフィールド項目に対応するフィールド項目（以下、「内部フィールド項目」とも呼ぶ）のみが準備されている。これは、プリンタで使用され得る内部フィールド項目の数が比較的少数なためである。

プリンタで使用される内部フィールド項目を追加する場合には、プリンタを変更する必要があると共に、プリントサーバを変更する必要がある。これは、上記のように、プリントサーバにおけるヘッダの変換処理では、追加される内部フィールド項目と、該内部フィールド項目に対応するＨＴＴＰフィールド項目と、の変更を行う必要があるためである。

このため、従来の印刷システムでは、プリンタで使用されるフィールド項目を追加するのは困難であった。

なお、上記の問題は、印刷システムだけでなく、ローカルデバイスを含む他のネットワークシステムにおいても同様に発生し得る。

本発明は、上述の課題を解決するためになされたものであり、ローカルデバイスで使用されるフィールド項目を容易に追加することのできる技術を提供することを目的とする。

上述の課題の少なくとも一部を解決するため、本発明の第１の装置は、制御装置であって、
ネットワークを介して接続される任意のコンピュータと第１種のプロトコルに従った第１種の通信データの通信を行う第１の通信部と、
前記ネットワークを介さずに接続されるローカルデバイスと第２種のプロトコルに従った第２種の通信データの通信を行う第２の通信部と、
前記第１の通信部が第１のコンピュータから受信した前記第１種の通信データに含まれる第１種のヘッダから、前記第２の通信部が前記ローカルデバイスに送信する前記第２種の通信データに含まれるべき第２種のヘッダを生成することによって、前記第１種のプロトコルから前記第２種のプロトコルへの変換を行うための第１の変換処理部と、
を備え、
前記第１の変換処理部は、
前記第１種のヘッダ内に含まれる第１のフィールドが予め定義されたフィールドである場合には、前記第１のフィールドに対応する第２のフィールドを含む前記第２種のヘッダを生成し、
前記第１種のヘッダ内に含まれる前記第１のフィールドが予め定義されていないフィールドである場合には、所定の識別情報と前記第１のフィールドの記述とを有する第３のフィールドを含む前記第２種のヘッダを生成することを特徴とする。

この制御装置では、第１種のヘッダ内に含まれるフィールドが予め定義されていないフィールドである場合には、該フィールドの記述に所定の識別情報が付加されたフィールドを含む第２種のヘッダが生成されるため、制御装置を変更することなく、ローカルデバイスで使用されるフィールド項目を容易に追加することが可能となる。

上記の装置において、さらに、
前記第２の通信部が前記ローカルデバイスから受信した前記第２種の通信データに含まれる第３種のヘッダから、前記第１の通信部が特定のコンピュータに送信する前記第１種の通信データに含まれるべき第４種のヘッダを生成することによって、前記第２種のプロトコルから前記第１種のプロトコルへの変換を行うための第２の変換処理部を備え、
前記第２の変換処理部は、
前記第３種のヘッダ内に含まれる第４のフィールドが予め定義されたフィールドである場合には、前記第４のフィールドに対応する第５のフィールドを含む前記第４種のヘッダを生成し、
前記第３種のヘッダ内に含まれる前記第４のフィールドが前記所定の識別情報を有するフィールドである場合には、前記所定の識別情報が削除された第６のフィールドを含む前記第４種のヘッダを生成することが好ましい。

この制御装置では、第３種のヘッダ内に含まれるフィールドが所定の識別情報を有するフィールドである場合に、所定の識別情報が削除されたフィールドを含む第４種のヘッダが生成されるため、制御装置を変更することなく、ローカルデバイスで使用されるフィールド項目を容易に追加することが可能となる。

なお、特定のコンピュータは、第１のコンピュータであってもよいし、第１のコンピュータと異なる第２のコンピュータであってもよい。

上記の装置において、
前記第１の通信部が前記第１のコンピュータから受信する前記第１種の通信データが、前記特定のコンピュータに格納された特定の情報の参照指示を含む場合には、前記第２の通信部が前記ローカルデバイスから受信する前記第２種の通信データは、前記特定のコンピュータからの前記特定の情報の取得要求を含むようにしてもよい。

本発明の第２の装置は、ネットワーク装置であって、
前記制御装置と、
前記ローカルデバイスと、
を備えることを特徴とする。

上記の装置において、
前記ローカルデバイスは、
前記制御装置と前記第２種のプロトコルに従った前記第２種の通信データの通信を行う通信部と、
前記通信部が前記制御装置から受信した前記第２種の通信データに基づいて、処理を実行する処理実行部と、
を備え、
前記処理実行部は、
前記第２種のヘッダ内に前記所定の識別情報と前記第１のフィールドの記述とを有する前記第３のフィールドが含まれる場合には、前記所定の識別情報を削除することによって得られる前記第１のフィールドに基づいて処理を実行することが好ましい。

こうすれば、制御装置を変更することなく、ローカルデバイスにおいて第３のフィールドを利用することができる。

また、上記の装置において、
前記処理実行部は、
前記通信部が前記制御装置に送信する前記第２種の通信データに含まれるべき前記第３種のヘッダを生成し、
前記処理実行部は、
前記第３種のヘッダ内に、前記制御装置において予め定義されていない前記第６のフィールドを記述する場合には、前記所定の識別情報と前記第６のフィールドの記述とを有する前記第４のフィールドを含む前記第３種のヘッダを生成することが好ましい。

こうすれば、制御装置を変更することなく、ローカルデバイスにおいて第８のフィールドを利用することができる。

上記の装置において、
前記処理実行部は、前記通信部が前記制御装置から受信する前記第２種の通信データが前記特定のコンピュータに格納された特定の情報の参照指示を含む場合には、前記特定のコンピュータからの前記特定の情報の取得要求を含む前記第３種のヘッダを生成するようにしてもよい。

本発明の第３の装置は、制御装置であって、
ネットワークを介して接続される任意のコンピュータと第１種のプロトコルに従った第１種の通信データの通信を行う第１の通信部と、
前記ネットワークを介さずに接続されるローカルデバイスと第２種のプロトコルに従った第２種の通信データの通信を行う第２の通信部と、
前記第２の通信部が前記ローカルデバイスから受信した前記第２種の通信データに含まれる第１種のヘッダから、前記第１の通信部が特定のコンピュータに送信する前記第１種の通信データに含まれるべき第２種のヘッダを生成することによって、前記第２種のプロトコルから前記第１種のプロトコルへの変換を行うための変換処理部と、
を備え、
前記変換処理部は、
前記第１種のヘッダ内に含まれる第１のフィールドが予め定義されたフィールドである場合には、前記第１のフィールドに対応する第２のフィールドを含む前記第２種のヘッダを生成し、
前記第１種のヘッダ内に含まれる前記第１のフィールドが所定の識別情報を有するフィールドである場合には、前記所定の識別情報が削除された第３のフィールドを含む前記第２種のヘッダを生成することを特徴とする。

この制御装置では、第１種のヘッダ内に含まれるフィールドが所定の識別情報を有するフィールドである場合に、所定の識別情報が削除されたフィールドを含む第２種のヘッダが生成されるため、制御装置を変更することなく、ローカルデバイスで使用されるフィールド項目を容易に追加することが可能となる。

この発明は、種々の形態で実現することが可能であり、制御装置および該制御装置における制御方法、ローカルデバイスおよび該ローカルデバイスにおける制御方法、制御装置とローカルデバイスとを含むネットワーク装置および該ネットワーク装置における制御方法、これらの方法または装置の機能を実現するためのコンピュータプログラム、そのコンピュータプログラムを記録した記録媒体、そのコンピュータプログラムを含み搬送波内に具現化されたデータ信号、等の形態で実現することができる。

次に、本発明の実施の形態を実施例に基づき以下の順序で説明する。
Ａ．第１実施例：
Ａ−１．印刷システムの構成：
Ａ−２．通信処理：
Ｂ．第２実施例：
Ｂ−１．印刷システムの構成：
Ｂ−２．通信処理：

Ａ．第１実施例：
Ａ−１．印刷システムの構成：
図１は、第１実施例における印刷システムの構成を示す説明図である。印刷システムシステムは、プリントサーバ１００と、プリンタ２００と、クライアントコンピュータ（以下、単に「クライアント」とも呼ぶ）３００と、を備えている。プリントサーバ１００とクライアント３００とは、ＬＡＮなどのネットワークＮＷを介して互いに接続されている。また、プリントサーバ１００とプリンタ２００とは、ＵＳＢケーブルを介して互いに接続されている。

なお、本実施例では、プリントサーバ１００とプリンタ２００とは異なる筐体に収納されているが、共通の筐体に収納されていてもよい。

本実施例におけるプリントサーバ１００が本発明における制御装置に相当し、プリンタ２００がローカルデバイスに相当する。また、プリントサーバ１００とプリンタ２００とがネットワーク装置に相当する。

プリントサーバ１００は、ＣＰＵ１１０と、ＲＯＭやＲＡＭなどのメモリ１２０と、ネットワークインタフェース（ＩＦ）部１４２と、ＵＳＢホストインタフェース（ＩＦ）部１４８と、を備えている。

ネットワークＩＦ部１４２は、ネットワークＮＷを介してクライアント３００と通信するためのインタフェースである。

ＵＳＢホストＩＦ部１４８は、ＵＳＢケーブルを介してプリンタ２００と通信するためのインタフェースである。

メモリ１２０には、変換処理部１２２と、第１の通信制御部１３２と、第２の通信制御部１３４と、の機能を有するコンピュータプログラムが格納されている。なお、各部の機能を有するコンピュータプログラムは、例えば、ＣＤ−ＲＯＭなどのコンピュータ読み取り可能な記録媒体に記録された形態で提供される。

第１の通信制御部１３２は、ネットワークＩＦ部１４２を介して、第１種のプロトコルに従った通信データを送受信する機能を有する。本実施例では、第１種のプロトコルとして、ＨＴＴＰ（Hyper Text Transfer Protocol）プロトコルが採用されている。第１の通信制御部１３２は、ＨＴＴＰサーバの処理を実行する機能を有する。すなわち、第１の通信制御部１３２は、クライアント３００から受信したＨＴＴＰプロトコルに従ったＨＴＴＰリクエストに含まれるメッセージヘッダとメッセージボディとを分離したり、メッセージヘッダとメッセージボディとを結合してＨＴＴＰプロトコルに従ったＨＴＴＰレスポンスを生成してクライアント３００に送信したりする機能を有する。また、第１の通信制御部１３２は、ＴＣＰおよび／またはＵＤＰ層の処理と、ＩＰ層の処理と、を実行する機能を有する。

第２の通信制御部１３４は、ＵＳＢホストＩＦ部１４８を介して、第２種のプロトコルに従った通信データを送受信する機能を有する。なお、本実施例では、第２種のプロトコルとして、第１種のプロトコルと異なる独自のプロトコルが採用されている。以下では、該独自のプロトコルを「内部プロトコル」と呼ぶ。第２の通信制御部１３４は、ヘッダとボディとを結合して内部プロトコルに従った内部リクエストを生成してプリンタ２００に送信したり、プリンタ２００から受信した内部プロトコルに従った内部レスポンスに含まれるヘッダとボディとを分離したりする機能を有する。

変換処理部１２２は、第１種のプロトコルと第２種のプロトコルとの変換処理を実行する。すなわち、変換処理部１２２は、第１の通信制御部１３２を介してクライアント３００から取得したＨＴＴＰプロトコルに従った通信データを、第２の通信制御部１３４を介してプリンタ２００に供給される内部プロトコルに従った通信データに、変換するための処理を実行する。また、変換処理部１２２は、第２の通信制御部１３４を介してプリンタ２００から取得した内部プロトコルに従った通信データを、第１の通信制御部１３２を介してクライアント３００に供給される内部プロトコルに従った通信データに、変換するための処理を実行する。

より具体的には、変換処理部１２２は、ＨＴＴＰリクエストに含まれるヘッダに基づいて、内部リクエストに含まれるべきヘッダを生成する。また、変換処理部１２２は、内部レスポンスに含まれるヘッダに基づいて、ＨＴＴＰレスポンスに含まれるべきヘッダを生成する。なお、ヘッダの変換は、後述するように、変換用テーブル（図示せず）を用いて実行される。

なお、本実施例におけるネットワークＩＦ部１４２と第１の通信制御部１３２とが本発明における第１の通信部に相当し、ＵＳＢホストＩＦ部１４８と第２の通信制御部１３４とが第２の通信部に相当する。

プリンタ２００は、ＣＰＵ２１０と、ＲＯＭやＲＡＭなどのメモリ２２０と、ＵＳＢデバイスインタフェース（ＩＦ）部２４８と、プリンタエンジン２５０と、を備えている。

ＵＳＢデバイスＩＦ部２４８は、ＵＳＢケーブルを介してプリントサーバ１００と通信するためのインタフェースである。

メモリ２２０には、処理実行部２２２と、通信制御部２３２と、の機能を有するコンピュータプログラムが格納されている。

通信制御部２３２は、ＵＳＢデバイスＩＦ部２４８を介して、第２種のプロトコル（内部プロトコル）に従った通信データを送受信する機能を有する。通信制御部２３２は、プリントサーバ１００から受信した内部リクエストに含まれるヘッダとボディとを分離したり、ヘッダとボディとを結合して内部レスポンスを生成してプリントサーバ１００に送信したりする機能を有する。なお、通信制御部２３２の機能は、ＵＳＢクラスドライバによって実現される。

処理実行部２２２は、コンテンツ準備部２２４を含んでいる。コンテンツ準備部２２４は、複数のコンテンツデータ（Ｗｅｂページデータ）を有しており、処理実行部２２２からの指示に従って、目的のコンテンツデータを準備する機能を有している。なお、コンテンツデータとしては、例えば、プリンタに関する種々の設定を行うための設定用画面データが挙げられる。

処理実行部２２２は、通信制御部２３２を介してプリントサーバ１００から取得した内部リクエストに基づいて、種々の処理を実行する。例えば、処理実行部２２２は、通信制御部２３２が内部リクエストに対応する内部レスポンスを送信するための処理を実行する。具体的には、処理実行部２２２は、内部レスポンスに含まれるべきヘッダを生成する。また、処理実行部２２２は、コンテンツ準備部２２４を制御して、内部レスポンスに含まれるべきデータ（コンテンツデータ）を準備する。

なお、本実施例におけるＵＳＢデバイスＩＦ部２４８と通信制御部２３２とが、本発明における通信部に相当する。

Ａ−２．通信処理：
図２は、図１の印刷システムで行われる通信処理の一例を示すフローチャートである。なお、この通信処理は、例えば、クライアント３００が、プリントサーバ１００に接続されたプリンタ２００から、コンテンツデータを取得する際に、実行される。

以下では、比較例における通信処理を、第１実施例における通信処理に先行して説明する。比較例では、図１とほぼ同様の印刷システムが利用され、比較例のプリントサーバ１００ｚでは、変換処理部１２２ｚが利用される共に、比較例のプリンタ２００ｚでは、処理実行部２２２ｚが利用される。

図３は、比較例における通信データの内容を模式的に示す説明図である。図３は、図２に示す通信処理が実行される際に伝送される通信データを示している。ただし、図３では、主に、通信データのヘッダが示されている。

ステップＳ１０２（図２）では、クライアント３００は、ＨＴＴＰリクエストＨＲＥＱｚをプリントサーバ１００ｚに送信する。具体的には、クライアント３００のユーザは、Ｗｅｂブラウザ画面を介して、プリントサーバ１００ｚとコンテンツ（Ｗｅｂページ）とを指定して、コンテンツデータの取得を要求する。このとき、クライアント３００は、ＨＴＴＰリクエストＨＲＥＱｚを生成する。

図３（Ａ）は、ＨＴＴＰリクエストＨＲＥＱｚの内容を示す。周知のように、ＨＴＴＰリクエストには、メッセージヘッダと、メッセージボディと、が含まれており、メッセージヘッダには、リクエストラインと、ヘッダフィールドと、が含まれている。図３（Ａ）の１行目は、リクエストラインを示しており、２行目以降は、ヘッダフィールドを示している。

１行目のリクエストラインには、メソッド（GET）と、リクエストＵＲＩ（Epson/Device.html）と、ＨＴＴＰバージョン（HTTP/1.1）と、が記述されている。２行目には、「User-Agent」フィールドが記述されており、フィールド値は、クライアント３００で使用されるＷｅｂブラウザ名（Mozilla/4.0）を示している。３行目には、「Host」フィールドが記述されており、フィールド値は、リソース（コンテンツデータ）を提供するホスト（epson.co.jp）を示している。なお、ホストは、プリントサーバ１００ｚを意味している。

図３（Ａ）に示すＨＴＴＰリクエストＨＲＥＱｚの記述から、プリントサーバ１００ｚ（epson.co.jp）からのコンテンツデータ（Epson/Device.html）の取得が要求されていることが分かる。

ステップＳ１０４（図２）では、プリントサーバ１００ｚの第１の通信制御部１３２は、クライアント３００からＨＴＴＰリクエストＨＲＥＱｚを取得する。そして、変換処理部１２２ｚは、ＨＴＴＰプロトコルと内部プロトコルとの変換を行う。具体的には、変換処理部１２２ｚは、ＨＴＴＰリクエストＨＲＥＱｚに含まれるヘッダから、内部リクエストＩＲＥＱｚに含まれるべきヘッダを生成する。そして、第２の通信制御部１３４は、内部リクエストＩＲＥＱｚを生成してプリンタ２００ｚに送信する。

図３（Ｂ）は、内部リクエストＩＲＥＱｚの内容を示す。１行目には、「URI」フィールドが記述されており、フィールド値はＵＲＩ(Epson/Device.html)を示している。「URI」フィールドは、ＨＴＴＰリクエストＨＲＥＱｚ（図３（Ａ））内の１行目のリクエストラインを利用して作成される。２行目には、「UserAgent」フィールドが記述されており、フィールド値は、Ｗｅｂブラウザ名（Mozilla/4.0）を示している。「UserAgent」フィールドは、ＨＴＴＰリクエストＨＲＥＱｚ（図３（Ａ））内の２行目の「User-Agent」フィールドを利用して作成される。

この説明から分かるように、変換処理部１２２ｚは、ＨＴＴＰプロトコルに従うフィールド名（例えば「User-Agent」）と、内部プロトコルに従うフィールド名（例えば「UserAgent」）と、の対応関係が定義されたテーブルを備えている。そして、変換処理部１２２ｚは、該テーブルを利用して、ＨＴＴＰプロトコルから内部プロトコルへの変換を実行する。

ステップＳ１０６（図２）では、プリンタ２００ｚの通信制御部２３２は、プリントサーバ１００ｚから内部リクエストＩＲＥＱｚを取得し、内部レスポンスＩＲＥＳｚをプリントサーバ１００ｚに送信する。この際、処理実行部２２２ｚは、内部リクエストＩＲＥＱｚに基づいて、コンテンツ準備部２２４に、指定されたコンテンツデータ（Device.html）を準備させる。また、処理実行部２２２ｚは、内部レスポンスＩＲＥＳｚに含まれるべきヘッダを準備する。そして、通信制御部２３２は、ヘッダとコンテンツデータ（Device.html）とを含む内部レスポンスＩＲＥＳｚを生成する。

図３（Ｃ）は、内部レスポンスＩＲＥＳｚの内容を示す。１行目には、「Return」フィールドが記述されており、フィールド値は、内部リクエストに対する結果（Success）を示している。２行目には、「Size」フィールドが記述されており、フィールド値はコンテンツデータのサイズ（2000）を示している。３行目には、「Format」フィールドが記述されており、フィールド値はコンテンツデータの形式（text/hrml）を示している。また、４行目には、「CookieInfo」フィールドが記述されている。このフィールドは、クライアント３００に対する命令を示しており、この命令に従って、クライアント３００は、クッキー情報（param1=ABCDおよびpath=/Epson/Printer）を保存する。この結果、クライアント３００は、「path」部分に記述されたＵＲＩ（Epson/Printer）に再度アクセスするときには、保存されたパラメータ（param1=ABCD）を使用することができる。

ステップＳ１０８（図２）では、プリントサーバ１００ｚの第２の通信制御部１３４は、プリンタ２００ｚから内部レスポンスＩＲＥＳｚを取得する。そして、変換処理部１２２ｚは、内部プロトコルとＨＴＴＰプロトコルとの変換を行う。具体的には、変換処理部１２２ｚは、内部レスポンスＩＲＥＳｚに含まれるヘッダから、ＨＴＴＰレスポンスＨＲＥＳｚに含まれるべきヘッダを生成する。そして、第１の通信制御部１３２は、ＨＴＴＰレスポンスＨＲＥＳｚを生成してクライアント３００に送信する。

図３（Ｄ）は、ＨＴＴＰレスポンスＨＲＥＳｚの内容を示す。周知のように、ＨＴＴＰレスポンスには、メッセージヘッダと、メッセージボディと、が含まれており、メッセージヘッダには、ステータスラインと、ヘッダフィールドと、が含まれている。図３（Ｄ）の１行目は、ステータスラインを示しており、２行目以降は、ヘッダフィールドを示している。

１行目のステータスラインには、ＨＴＴＰバージョン（HTTP/1.1）と、ステータスコード（200）と、結果フレーズ（OK）と、が記述されている。２行目には、「Content-type」フィールドが記述されており、該フィールドは、内部レスポンスＩＲＥＳｚ（図３（Ｃ））内の３行目の「Format」フィールドを利用して作成される。３行目には、「Content-Length」フィールドが記述されており、該フィールドは、内部レスポンスＩＲＥＳｚ（図３（Ｃ））内の２行目の「Size」フィールドを利用して作成される。４行目には、「Set-Cookie」フィールドが記述されており、該フィールドは、内部レスポンスＩＲＥＳｚ（図３（Ｃ））内の４行目の「CookieInfo」フィールドを利用して作成される。

前述したように、変換処理部１２２ｚは、ＨＴＴＰプロトコルに従うフィールド名（例えば「Content-type」）と、内部プロトコルに従うフィールド名（例えば「Format」）と、の対応関係が定義されたテーブルを備えており、該テーブルを利用して、内部プロトコルからＨＴＴＰプロトコルへの変換を実行する。

ステップＳ１１０（図２）では、クライアント３００は、ＨＴＴＰレスポンスＨＲＥＳｚを取得する。そして、クライアント３００のＷｅｂブラウザは、ＨＴＴＰレスポンスＨＲＥＳｚ（図３（Ｄ））に含まれるコンテンツデータを用いて、Ｗｅｂページを表示する。また、クライアント３００は、ＨＴＴＰレスポンスＨＲＥＳｚに含まれる「Set-Cookie」フィールドに従って、クッキー情報の設定を行う。

上記のように、プリントサーバ１００ｚの変換処理部１２２ｚは、ＨＴＴＰリクエスト／レスポンスのヘッダと、内部リクエスト／レスポンスのヘッダと、を変更することによって、より具体的には、ヘッダフィールドのフィールド名を変更することによって、ＨＴＴＰプロトコルと内部プロトコルとの間の変換を実行している。

ところで、前述したように、プリンタで使用されるフィールド項目を追加する場合には、プリンタ２００ｚの処理実行部２２２ｚを変更する必要があると共に、プリントサーバ１００ｚの変換処理部１２２ｚを変更する必要がある。具体的には、追加のフィールド項目を使用できるように、処理実行部２２２ｚの処理内容を変更する必要があると共に、変換処理部１２２ｚが有するテーブルを変更する必要がある。そこで、本実施例では、プリンタで使用されるフィールド項目を追加する場合にも、プリントサーバ１００を変更せずに済むように工夫している。

図４は、第１実施例における通信データの内容を模式的に示す説明図であり、図３に対応する。図４は、図３と同様に、図２に示す通信処理が実行される際に伝送される通信データを示している。

ステップＳ１０２（図２）では、前述したように、クライアント３００は、ＨＴＴＰリクエストＨＲＥＱをプリントサーバ１００に送信する。

図４（Ａ）は、ＨＴＴＰリクエストＨＲＥＱの内容を示す。図４（Ａ）は、図３（Ａ）とほぼ同様であるが、４行目の「Accept-Language」フィールドが追加されている。「Accept-Language」フィールドの値は、クライアント３００のＷｅｂブラウザが表示可能な言語（ja：日本語）を示す。

ステップＳ１０４（図２）では、前述したように、プリントサーバ１００は、クライアント３００からＨＴＴＰリクエストＨＲＥＱを取得し、内部リクエストＩＲＥＱを生成してプリンタ２００に送信する。この際、変換処理部１２２は、ＨＴＴＰリクエストＨＲＥＱに含まれるヘッダから、内部リクエストＩＲＥＱに含まれるべきヘッダを生成する。

本実施例では、プリントサーバ１００において「Accept-Language」フィールドが定義されていない場合を想定している。換言すれば、変換処理部１２２は、「Accept-Language」フィールドを解釈不能である。従来では、ＨＴＴＰリクエストのヘッダ内に未定義のフィールドが含まれる場合には、プリントサーバは、内部リクエストを生成することができなかった。しかしながら、本実施例では、プリントサーバ１００は、ＨＴＴＰリクエストのヘッダ内に未定義のフィールドが含まれる場合にも、内部リクエストを生成することができる。

図４（Ｂ）は、内部リクエストＩＲＥＱの内容を示す。図４（Ｂ）は、図３（Ｂ）とほぼ同様であるが、「Data」フィールドが追加されている。「Data」フィールドには、図４（Ａ）のＨＴＴＰリクエストＨＲＥＱ内に記述された未定義の「Accept-Language」フィールドの記述と、該未定義のフィールドの先頭に付与された識別情報「Data」と、を含んでいる。識別情報「Data」は、変換処理部１２２によって付加される。このようにすれば、プリントサーバ１００は、ＨＴＴＰリクエストのヘッダ内に記述されたフィールドが未定義である場合にも、該未定義のフィールドの記述がヘッダ内に含まれる内部リクエストをプリンタ２００に送信することができる。

なお、上記の説明から分かるように、変換処理部１２２は、特定のフィールドが変換用テーブルに登録されている場合には、該テーブルに登録された対応するフィールドを準備し、特定のフィールドが変換用テーブルに登録されていない場合には、該特定のフィールドの記述に識別情報「Data」を付与して「Data」フィールドを準備する。

ステップＳ１０６（図２）では、前述したように、プリンタ２００は、プリントサーバ１００から内部リクエストＩＲＥＱを取得し、内部レスポンスＩＲＥＳを生成してプリントサーバ１００に送信する。このとき、処理実行部２２２は、内部リクエストＩＲＥＱに含まれる「Data」フィールドから識別情報「Data」を除去して、「Accept-Language」フィールドを得る。そして、処理実行部２２２は、「Accept-Language」フィールドを解釈し、「Accept-Language」フィールドで指定された言語のコンテンツデータをコンテンツ準備部２２４に準備させる。

図４（Ｃ）は、内部レスポンスＩＲＥＳの内容を示す。図４（Ｃ）は、図３（Ｃ）とほぼ同様であるが、「CookieInfo」フィールドに代えて、「Data」フィールドが記述されている。「Data」フィールド内には、「Set-Cookie:param1=ABCD; path=/Epson/Printer」が記述されている。

本実施例では、プリントサーバ１００において「Set-Cookie」フィールドが定義されていない場合を想定している。換言すれば、変換処理部１２２は、「Set-Cookie」フィールドを解釈不能である。このため、処理実行部２２２は、未定義の「Set-Cookie」フィールドの記述の先頭に、識別情報「Data」を付与することによって、「Data」フィールドを作成している。

ステップＳ１０８（図２）では、前述したように、プリントサーバ１００は、プリンタ２００から内部レスポンスＩＲＥＳを取得し、ＨＴＴＰレスポンスＨＲＥＳを生成してクライアント３００に送信する。

図４（Ｄ）は、ＨＴＴＰレスポンスＨＲＥＳの内容を示す。図４（Ｄ）は、図３（Ｄ）と同じである。プリントサーバ１００は、図４（Ｃ）の内部レスポンスＩＲＥＳを利用して、図４（Ｄ）のＨＴＴＰレスポンスＨＲＥＳを生成する。この際、変換処理部１２２は、図３（Ｄ）の「Data」フィールドから識別情報「Data」を削除して、「Set-Cookie」フィールドを作成する。このようにすれば、プリントサーバ１００は、プリントサーバ１００において定義されていないフィールドを含むＨＴＴＰレスポンスを生成してクライアント３００に送信することができる。

なお、上記の説明から分かるように、変換処理部１２２は、特定のフィールドが「Data」フィールドである場合には、識別情報「Data」が削除されたフィールドを準備し、特定のフィールドが「Data」フィールドでない場合には、変換用テーブルを参照して、対応するフィールドを準備する。

ステップＳ１１０（図２）では、前述したように、クライアント３００は、ＨＴＴＰレスポンスＨＲＥＳを取得する。

以上説明したように、本実施例では、プリントサーバ１００の変換処理部１２２は、ステップＳ１０４において、クライアント３００から受信したＨＴＴＰリクエストに含まれるヘッダから、プリンタ２００に送信される内部リクエストに含まれるべきヘッダを生成することによって、ＨＴＴＰプロトコルから内部プロトコルへの変換を行う。この際、変換処理部１２２は、ＨＴＴＰリクエストのヘッダ内に含まれるフィールド（例えば「User-Agent」フィールド）を解釈可能な場合には、対応するフィールド（例えば「UserAgent」フィールド）を含む内部リクエストのヘッダを生成する。一方、変換処理部１２２は、ＨＴＴＰリクエストのヘッダ内に含まれるフィールド（例えば「Accept-Language」フィールド）を解釈不能な場合には、識別情報「Data」と該フィールドの記述とを有する「Data」フィールドを含む内部リクエストのヘッダを生成する。

また、プリンタ２００の処理実行部２２２は、ステップＳ１０６において、内部リクエストのヘッダ内に「Data」フィールドが含まれる場合には、識別情報「Data」を削除することによって得られるフィールド（例えば「Accept-Language」フィールド）に基づいて処理を実行する。

そして、プリンタ２００の処理実行部２２２は、ステップＳ１０６において、内部レスポンスのヘッダ内に、変換処理部１２２が解釈不能なフィールド（例えば「Set-Cookie」フィールド）を記述する場合には、識別情報「Data」と該フィールドの記述とを有する「Data」フィールドを含む内部レスポンスのヘッダを生成する。

さらに、プリントサーバ１００の変換処理部１２２は、ステップＳ１０８において、プリンタ２００から受信した内部レスポンスに含まれるヘッダから、クライアント３００に送信されるＨＴＴＰレスポンスに含まれるべきヘッダを生成することによって、内部プロトコルからＨＴＴＰプロトコルへの変換を行う。この際、変換処理部１２２は、内部レスポンスのヘッダ内に含まれるフィールド（例えば「Format」フィールド）を解釈可能な場合には、対応するフィールド（例えば「Content-type」フィールド）を含むＨＴＴＰレスポンスのヘッダを生成する。一方、変換処理部１２２は、内部レスポンスのヘッダ内に「Data」フィールドが含まれる場合には、識別情報「Data」が削除されたフィールド（例えば「Set-Cookie」フィールド）を含むＨＴＴＰレスポンスのヘッダを生成する。

上記のように、本実施例では、「Data」フィールドが利用されるため、プリントサーバ１００を変更することなく、プリンタ２００で使用されるフィールド項目を容易に追加することが可能となる。

Ｂ．第２実施例：
Ｂ−１．印刷システムの構成：
第１実施例では、クライアントによって発行されたＨＴＴＰリクエストに基づいて通信処理が実行される場合について説明したが、本実施例では、プリンタによって発行された内部リクエストに基づいて通信処理が実行される場合について説明する。

図５は、第２実施例における印刷システムの構成を示す説明図である。図５は、図１とほぼ同じであるが、プリントサーバ１００Ｂとプリンタ２００Ｂとが変更されている。具体的には、プリントサーバ１００Ｂの変換処理部１２２Ｂと第１の通信制御部１３２Ｂと第２の通信制御部１３４Ｂとが変更されている。また、プリンタ２００Ｂの処理実行部２２２Ｂと通信制御部２３２Ｂとが変更されている。さらに、サーバコンピュータ（以下、単に「サーバ」とも呼ぶ）４００が追加されている。

プリントサーバ１００Ｂの第１の通信制御部１３２Ｂは、第１実施例の第１の通信制御部１３２（図１）と同様に、ＨＴＴＰサーバの処理を実行する機能を有する。また、本実施例の第１の通信制御部１３２Ｂは、ＨＴＴＰクライアントの処理を実行する機能を有する。すなわち、第１の通信制御部１３２Ｂは、メッセージヘッダとメッセージボディとを結合してＨＴＴＰリクエストを生成してサーバ４００に送信したり、サーバ４００から受信したＨＴＴＰレスポンスに含まれるメッセージヘッダとメッセージボディとを分離したりする機能を有する。

第２の通信制御部１３４Ｂは、第１実施例の第２の通信制御部１３４（図１）と同様に、内部プロトコルに従った通信データを送受信する機能を有する。特に、第２の通信制御部１３４Ｂは、プリンタ２００から受信した内部リクエストに含まれるヘッダとボディとを分離したり、ヘッダとボディとを結合して内部レスポンスを生成してプリンタ２００に送信したりする機能を有する。

変換処理部１２２Ｂは、第１実施例の変換処理部１２２（図１）と同様に、ＨＴＴＰプロトコルと内部プロトコルとの変換処理を実行する。特に、変換処理部１２２Ｂは、内部リクエストに含まれるヘッダに基づいて、ＨＴＴＰリクエストに含まれるべきヘッダを生成する。また、変換処理部１２２Ｂは、ＨＴＴＰレスポンスに含まれるヘッダに基づいて、内部レスポンスに含まれるべきヘッダを生成する。なお、ヘッダの変換は、前述したように、変換用テーブル（図示せず）を用いて実行される。

プリンタ２００Ｂの通信制御部２３２Ｂは、第１実施例の通信制御部２３２（図１）と同様に、内部プロトコルに従った通信データを送受信する機能を有する。特に、通信制御部２３２Ｂは、ヘッダとボディとを結合して内部リクエストを生成してプリントサーバ１００Ｂに送信したり、プリントサーバ１００Ｂから受信した内部レスポンスに含まれるヘッダとボディとを分離したりする機能を有する。

処理実行部２２２Ｂは、第１実施例の処理実行部２２２と同様に、プリントサーバ１００Ｂから取得した内部リクエストに基づいて、種々の処理を実行する。さらに、処理実行部２２２Ｂは、プリントサーバ１００Ｂから取得した内部リクエスト内に他のコンピュータ（例えばサーバ４００）に格納された情報を参照する旨の指示が含まれる場合に、内部リクエストを生成するための処理を実行する。

プリンタ２００Ｂには、さらに、時計部２４０が追加されている。時計部２４０は、例えば、水晶振動子とカウンタとを含んでおり、現在時刻を計測する機能を有している。

なお、本実施例では、プリンタ２００Ｂは、時計部２４０を備えているため、現在時刻を知ることができるが、プリントサーバ１００Ｂは、時計部を備えておらず、現在時刻を知ることができない場合を想定している。

Ｂ−２．通信処理：
図６は、図５の印刷システムで行われる通信処理の一例を示すフローチャートである。なお、この通信処理は、例えば、クライアント３００が、プリンタエンジン２５０に参照印刷を実行させる際に、実行される。なお、参照印刷は、クライアント３００と異なる他の装置（本実施例ではサーバ４００）に格納された画像データを利用して印刷することを意味している。参照印刷を利用すれば、クライアント３００はプリントサーバ１００Ｂにサイズの大きな画像データを送信せずに済むという利点がある。

図７は、第２実施例における通信データの内容を模式的に示す説明図である。図７は、図６に示す通信処理が実行される際に伝送される通信データを示している。ただし、図７では、主に、通信データのヘッダが示されている。

ステップＳ２０２（図６）では、クライアント３００は、ＨＴＴＰリクエストＨＲＥＱ１をプリントサーバ１００Ｂに送信する。具体的には、クライアント３００のユーザは、Ｗｅｂブラウザ画面を介して、プリントサーバ１００Ｂと印刷対象の画像とを指定して、参照印刷の実行を要求する。このとき、クライアント３００は、ＨＴＴＰリクエストＨＲＥＱ１を生成する。

図７（Ａ）は、ＨＴＴＰリクエストＨＲＥＱ１の内容を示す。１行目のリクエストラインには、メソッド（POST）と、リクエストＵＲＩ（Epson/Printer/swimming.xhtml）と、ＨＴＴＰバージョン（HTTP/1.1）と、が記述されている。なお、図３（Ａ）と同様に、２行目には、「User-Agent」フィールドが記述されており、３行目には、「Host」フィールドが記述されている。また、ＨＴＴＰリクエストＨＲＥＱ１には、ＸＨＴＭＬデータ（swimming.xhtml）が含まれている。

図７（Ａ）に示すＨＴＴＰリクエストＨＲＥＱ１の記述から、プリンタエンジン２５０（Epson/Printer）へのＸＨＴＭＬデータ（swimming.xhtml）の供給が要求されていることが分かる。

ステップＳ２０４（図６）では、図２のステップＳ１０４と同様に、プリントサーバ１００Ｂは、クライアント３００からＨＴＴＰリクエストＨＲＥＱ１を取得し、内部リクエストＩＲＥＱ１を生成してプリンタ２００Ｂに送信する。

図７（Ｂ）は、内部リクエストＩＲＥＱ１の内容を示す。図７（Ｂ）は、図３（Ｂ）とほぼ同じであるが、内部リクエストＩＲＥＱ１にはＸＨＴＭＬデータ（swimming.xhtml）が含まれている。

ステップＳ２０６（図６）では、図２のステップＳ１０６と同様に、プリンタ２００Ｂは、プリントサーバ１００Ｂから内部リクエストＩＲＥＱ１を取得し、内部レスポンスＩＲＥＳ１を生成してプリントサーバ１００Ｂに送信する。

図７（Ｃ）は、内部レスポンスＩＲＥＳ１の内容を示す。図７（Ｃ）では、図３（Ｃ）と同様に、１行目には、リクエストの結果（Success）を示す「Return」フィールドが記述されており、２行目には、「Size」フィールドが記述されている。なお、本実施例では、内部レスポンスＩＲＥＳ１には、コンテンツデータは含まれない。

なお、プリンタ２００Ｂでは、ステップＳ２０６の処理に続いてステップＳ２２２の処理が実行されるが、ステップＳ２２２の処理については後述する。

ステップＳ２０８（図６）では、図２のステップＳ１０８と同様に、プリントサーバ１００Ｂは、プリンタ２００Ｂから内部レスポンスＩＲＥＳ１を取得し、ＨＴＴＰレスポンスＨＲＥＳ１を生成してクライアント３００に送信する。

図７（Ｄ）は、ＨＴＴＰレスポンスＨＲＥＳ１の内容を示す。１行目には、図３（Ｄ）と同様に、リクエストの結果を示すステータスラインが記述されている。また、２行目には、「Content-Length」フィールドが記述されており、該フィールドは、内部レスポンスＩＲＥＳ１（図７（Ｃ））内の２行目の「Size」フィールドを利用して作成される。３行目には、「Connection」フィールドが記述されており、フィールド値は、コネクションの状態（close）を示している。

ステップＳ２１０（図６）では、図２のステップＳ１１０と同様に、クライアント３００は、ＨＴＴＰレスポンスＨＲＥＳ１を取得する。

ステップＳ２２２（図６）では、プリンタ２００Ｂの処理実行部２２２Ｂは、ステップＳ２０６で取得した内部リクエストＩＲＥＱ１に含まれるＸＨＴＭＬデータを解釈する。

図８は、ＸＨＴＭＬデータの一例を示す説明図である。図示するように、ＸＨＴＭＬデータに含まれるＩＭＧタグ＜img src＝""＞には、参照すべき画像データのファイル名が記述されている。ＩＭＧタグ＜img src＝""＞内に記述された「http://169.254.100.200/swimming.jpg」から、ＩＰアドレス「169.254.100.200」を有するサーバ４００に格納された画像データ「swimming.jpg」を参照すべきことが分かる。

そして、ステップＳ２２２では、プリンタ２００Ｂの通信制御部２３２Ｂは、内部リクエストＩＲＥＱ２をプリントサーバ１００Ｂに送信する。この際、プリンタ２００Ｂの処理実行部２２２Ｂは、内部リクエストＩＲＥＱ１の解析結果に基づいて、内部リクエストＩＲＥＱ２に含まれるべきヘッダを準備する。

図７（Ｅ）は、内部リクエストＩＲＥＱ２の内容を示す。１行目には、「Request」フィールドが記述されており、フィールド値は、利用されるべきＨＴＴＰメソッド（GET）を示している。２行目には、「URI」フィールドが記述されており、フィールド値は、ＵＲＩ（169.254.100.200/swimming.jpg）を示している。

図７（Ｅ）に示す内部リクエストＩＲＥＱ２の記述から、サーバ４００（169.254.100.200）からの画像データ（swimming.jpg）の取得が要求されていることが分かる。

また、３行目には、「Data」フィールドが記述されている。「Data」フィールド内には、「If-Modified-Since:Sat, 29 Oct 2004 19:43:31 GMT」が記述されている。

本実施例では、プリントサーバ１００Ｂにおいて「If-Modified-Since」フィールドが定義されていない場合を想定している。換言すれば、変換処理部１２２Ｂは「If-Modified-Since」フィールドを解釈不能である。このため、処理実行部２２２Ｂは、未定義の「If-Modified-Since」フィールドの記述の先頭に、識別情報「Data」を付与することによって、「Data」フィールドを作成している。

なお、「If-Modified-Since」フィールドは、画像データの取得条件を示しており、画像データが「Sat, 29 Oct 2004 19:43:31」以降に変更（更新）されている場合にのみ、画像データを取得することを示している。

すなわち、本実施例では、プリンタ２００Ｂのキャッシュ領域（図示せず）内に画像データ「swimming.jpg」が既に格納されている場合を想定している。そして、該画像データがキャッシュ領域に格納された日時は「Sat, 29 Oct 2004 19:43:31」である。なお、該日時は、ＣＰＵ２１０が時計部２４０を参照することによって決定される。そして、本実施例では、処理実行部２２２Ｂは、該画像データがキャッシュ領域に格納された日時を参照して、該日時以降に画像データが変更されている場合にのみ画像データを取得すべきことを示す「If-Modified-Since」フィールドを作成している。

ステップＳ２２４（図６）では、プリントサーバ１００Ｂは、プリンタ２００Ｂから内部リクエストＩＲＥＱ２を取得し、ＨＴＴＰリクエストＨＲＥＱ２を生成してサーバ４００に送信する。この際、変換処理部１２２は、内部リクエストＩＲＥＱ２に含まれるヘッダから、ＨＴＴＰリクエストＨＲＥＱ２に含まれるべきヘッダを生成する。

図７（Ｆ）は、ＨＴＴＰリクエストＨＲＥＱ２の内容を示す。１行目のリクエストラインには、メソッド（GET）と、リクエストＵＲＩ（swimming.jpg）と、ＨＴＴＰバージョン（HTTP/1.1）と、が記述されている。２行目には、「Host」フィールドが記述されており、フィールド値は、リソース（画像データ）を提供するホスト（169.254.100.200）を示している。なお、ホストは、サーバ４００を意味している。リクエストラインと「Host」フィールドとは、内部リクエストＩＲＥＱ２（図７（Ｅ））内の１行目の「Request」フィールドと２行目の「URI」フィールドとを利用して作成される。３行目には、「If-Modified-Since」フィールドが記述されている。「If-Modified-Since」フィールドは、変換処理部１２２Ｂが図７（Ｅ）の「Data」フィールドから識別情報「Data」を削除することによって、作成される。

ステップＳ２２６（図６）では、サーバ４００は、プリントサーバ１００ＢからＨＴＴＰリクエストＨＲＥＱ２を取得し、ＨＴＴＰレスポンスＨＲＥＳ２をプリントサーバ１００Ｂに送信する。この際、サーバ４００は、ＨＴＴＰリクエストＨＲＥＱ２に基づいて、指定された画像データ（swimming.jpg）を読み出す。そして、サーバ４００は、画像データ（swimming.jpg）を含むＨＴＴＰレスポンスＨＲＥＳ２を生成する。

ステップＳ２２８（図６）では、プリントサーバ１００Ｂは、サーバ４００からＨＴＴＰレスポンスＨＲＥＳ２を取得し、内部レスポンスＩＲＥＳ２を生成してプリンタ２００Ｂに送信する。なお、内部レスポンスＩＲＥＳ２には、画像データ（swimming.jpg）が含まれている。

ステップＳ２３０（図６）では、プリンタ２００Ｂは、内部レスポンスＩＲＥＳ２を取得する。そして、処理実行部２２２Ｂは、内部レスポンスＩＲＥＳ２に含まれる画像データ（swimming.jpg）を用いて、プリンタエンジン２５０に印刷を実行させる。

以上説明したように、本実施例では、プリントサーバ１００Ｂの変換処理部１２２Ｂは、ステップＳ２２４においてプリンタ２００Ｂから受信した内部リクエストに含まれるヘッダから、サーバ４００に送信されるＨＴＴＰリクエストに含まれるべきヘッダを生成することによって、内部プロトコルからＨＴＴＰプロトコルへの変換を行う。この際、変換処理部１２２Ｂは、内部リクエストのヘッダ内に含まれるフィールド（例えば「URI」フィールド）を解釈可能な場合には、対応するフィールド（例えば「Host」フィールド）を含むＨＴＴＰリクエストのヘッダを生成する。一方、変換処理部１２２Ｂは、内部リクエストのヘッダ内に「Data」フィールドが含まれる場合には、識別情報「Data」が削除されたフィールド（例えば「If-Modified-Since」フィールド）を含むＨＴＴＰリクエストのヘッダを生成する。

なお、本実施例では、変換処理部１２２Ｂは、ステップＳ２２８において、サーバ４００から受信したＨＴＴＰレスポンスに含まれるヘッダから、プリンタ２００Ｂに送信される内部レスポンスに含まれるべきヘッダを生成することによって、ＨＴＴＰプロトコルから内部プロトコルへの変換を行っている。この際、変換処理部１２２Ｂは、第１実施例と同様に、ＨＴＴＰレスポンスのヘッダ内に含まれるフィールドを解釈可能な場合には、対応するフィールドを含む内部レスポンスのヘッダを生成し、ＨＴＴＰレスポンスのヘッダ内に含まれるフィールドを解釈不能な場合には、識別情報「Data」と該フィールドの記述とを有する「Data」フィールドを含む内部レスポンスのヘッダを生成すればよい。

上記のように、本実施例でも、「Data」フィールドが利用されるため、プリントサーバ１００Ｂを変更することなく、プリンタ２００Ｂで使用されるフィールド項目を容易に追加することが可能となる。

なお、この発明は上記の実施例や実施形態に限られるものではなく、その要旨を逸脱しない範囲において種々の態様において実施することが可能であり、例えば次のような変形も可能である。

（１）上記実施例では、第１種のプロトコルとして、ＨＴＴＰプロトコルが利用されているが、これに代えて、他のプロトコル（例えば、ＦＴＰ（File Transfer Protocol）プロトコル）が利用されてもよい。

（２）上記実施例では、ローカルデバイスとしてプリンタが利用されているが、これに代えて、他のデバイスが利用されてもよい。他のデバイスとしては、スキャナや、ストレージ等が利用可能である。また、他のデバイスとしては、複数の機能（印刷，スキャナ等）を有する複合機が利用されてもよい。

（３）上記実施例において、ハードウェアによって実現されていた構成の一部をソフトウェアに置き換えるようにしてもよく、逆に、ソフトウェアによって実現されていた構成の一部をハードウェアに置き換えるようにしてもよい。

第１実施例における印刷システムの構成を示す説明図である。 図１の印刷システムで行われる通信処理の一例を示すフローチャートである。 比較例における通信データの内容を模式的に示す説明図である。 第１実施例における通信データの内容を模式的に示す説明図である。 第２実施例における印刷システムを示す説明図である。 図５の印刷システムで行われる通信処理の一例を示すフローチャートである。 第２実施例における通信データの内容を模式的に示す説明図である。 ＸＨＴＭＬデータの一例を示す説明図である。

符号の説明

１００，Ｂ…プリントサーバ
１１０…ＣＰＵ
１２０…メモリ
１２２，Ｂ…変換処理部
１３２，Ｂ…第１の通信制御部
１３４，Ｂ…第２の通信制御部
１４２…ネットワークＩＦ部
１４８…ＵＳＢホストＩＦ部
２００，Ｂ…プリンタ
２１０…ＣＰＵ
２２０…メモリ
２２２，Ｂ…処理実行部
２２４…コンテンツ準備部
２３２，Ｂ…通信制御部
２４０…時計部
２４８…ＵＳＢデバイスＩＦ部
２５０…プリンタエンジン
３００…クライアントコンピュータ
４００…サーバコンピュータ
ＮＷ…ネットワーク

Claims (15)

1. 制御装置であって、
   ネットワークを介して接続される任意のコンピュータと第１種のプロトコルに従った第１種の通信データの通信を行う第１の通信部と、
   前記ネットワークを介さずに接続されるローカルデバイスと第２種のプロトコルに従った第２種の通信データの通信を行う第２の通信部と、
   前記第１の通信部が第１のコンピュータから受信した前記第１種の通信データに含まれる第１種のヘッダから、前記第２の通信部が前記ローカルデバイスに送信する前記第２種の通信データに含まれるべき第２種のヘッダを生成することによって、前記第１種のプロトコルから前記第２種のプロトコルへの変換を行うための第１の変換処理部と、
   を備え、
   前記第１の変換処理部は、
   前記第１種のヘッダ内に含まれる第１のフィールドが予め定義されたフィールドである場合には、前記第１のフィールドに対応する第２のフィールドを含む前記第２種のヘッダを生成し、
   前記第１種のヘッダ内に含まれる前記第１のフィールドが予め定義されていないフィールドである場合には、所定の識別情報と前記第１のフィールドの記述とを有する第３のフィールドを含む前記第２種のヘッダを生成することを特徴とする制御装置。
2. 請求項１記載の制御装置であって、さらに、
   前記第２の通信部が前記ローカルデバイスから受信した前記第２種の通信データに含まれる第３種のヘッダから、前記第１の通信部が特定のコンピュータに送信する前記第１種の通信データに含まれるべき第４種のヘッダを生成することによって、前記第２種のプロトコルから前記第１種のプロトコルへの変換を行うための第２の変換処理部を備え、
   前記第２の変換処理部は、
   前記第３種のヘッダ内に含まれる第４のフィールドが予め定義されたフィールドである場合には、前記第４のフィールドに対応する第５のフィールドを含む前記第４種のヘッダを生成し、
   前記第３種のヘッダ内に含まれる前記第４のフィールドが前記所定の識別情報を有するフィールドである場合には、前記所定の識別情報が削除された第６のフィールドを含む前記第４種のヘッダを生成する、制御装置。
3. 請求項２記載の制御装置であって、
   前記特定のコンピュータは、前記第１のコンピュータである、制御装置。
4. 請求項２記載の制御装置であって、
   前記特定のコンピュータは、前記第１のコンピュータと異なる第２のコンピュータである、制御装置。
5. 請求項４記載の制御装置であって、
   前記第１の通信部が前記第１のコンピュータから受信する前記第１種の通信データが、前記特定のコンピュータに格納された特定の情報の参照指示を含む場合には、前記第２の通信部が前記ローカルデバイスから受信する前記第２種の通信データは、前記特定のコンピュータからの前記特定の情報の取得要求を含む、制御装置。
6. ネットワーク装置であって、
   請求項１ないし５のいずれかに記載の前記制御装置と、
   前記ローカルデバイスと、
   を備えることを特徴とするネットワーク装置。
7. 請求項６記載のネットワーク装置であって、
   前記ローカルデバイスは、
   前記制御装置と前記第２種のプロトコルに従った前記第２種の通信データの通信を行う通信部と、
   前記通信部が前記制御装置から受信した前記第２種の通信データに基づいて、処理を実行する処理実行部と、
   を備え、
   前記処理実行部は、
   前記第２種のヘッダ内に前記所定の識別情報と前記第１のフィールドの記述とを有する前記第３のフィールドが含まれる場合には、前記所定の識別情報を削除することによって得られる前記第１のフィールドに基づいて処理を実行する、ネットワーク装置。
8. ネットワーク装置であって、
   請求項２ないし５のいずれかに記載の前記制御装置と、
   前記ローカルデバイスと、
   を備え、
   前記ローカルデバイスは、
   前記制御装置と前記第２種のプロトコルに従った前記第２種の通信データの通信を行う通信部と、
   前記通信部が前記制御装置から受信した前記第２種の通信データに基づいて、処理を実行する処理実行部と、
   を備え、
   前記処理実行部は、
   前記通信部が前記制御装置に送信する前記第２種の通信データに含まれるべき前記第３種のヘッダを生成し、
   前記処理実行部は、
   前記第３種のヘッダ内に、前記制御装置において予め定義されていない前記第６のフィールドを記述する場合には、前記所定の識別情報と前記第６のフィールドの記述とを有する前記第４のフィールドを含む前記第３種のヘッダを生成することを特徴とするネットワーク装置。
9. 請求項８記載のネットワーク装置であって、
   前記処理実行部は、前記通信部が前記制御装置から受信する前記第２種の通信データが前記特定のコンピュータに格納された特定の情報の参照指示を含む場合には、前記特定のコンピュータからの前記特定の情報の取得要求を含む前記第３種のヘッダを生成する、ネットワーク装置。
10. 制御装置であって、
    ネットワークを介して接続される任意のコンピュータと第１種のプロトコルに従った第１種の通信データの通信を行う第１の通信部と、
    前記ネットワークを介さずに接続されるローカルデバイスと第２種のプロトコルに従った第２種の通信データの通信を行う第２の通信部と、
    前記第２の通信部が前記ローカルデバイスから受信した前記第２種の通信データに含まれる第３種のヘッダから、前記第１の通信部が特定のコンピュータに送信する前記第１種の通信データに含まれるべき第４種のヘッダを生成することによって、前記第２種のプロトコルから前記第１種のプロトコルへの変換を行うための変換処理部と、
    を備え、
    前記変換処理部は、
    前記第３種のヘッダ内に含まれる第４のフィールドが予め定義されたフィールドである場合には、前記第４のフィールドに対応する第５のフィールドを含む前記第４種のヘッダを生成し、
    前記第３種のヘッダ内に含まれる前記第４のフィールドが所定の識別情報を有するフィールドである場合には、前記所定の識別情報が削除された第６のフィールドを含む前記第４種のヘッダを生成することを特徴とする制御装置。
11. ネットワークを介して接続される任意のコンピュータと第１種のプロトコルに従った第１種の通信データの通信を行う第１の通信部と、前記ネットワークを介さずに接続されるローカルデバイスと第２種のプロトコルに従った第２種の通信データの通信を行う第２の通信部と、を備える制御装置によって実行される制御方法であって、
    前記第１の通信部が第１のコンピュータから受信した前記第１種の通信データに含まれる第１種のヘッダから、前記第２の通信部が前記ローカルデバイスに送信する前記第２種の通信データに含まれるべき第２種のヘッダを生成することによって、前記第１種のプロトコルから前記第２種のプロトコルへの変換を行う工程を備え、
    前記変換工程は、
    前記第１種のヘッダ内に含まれる第１のフィールドが予め定義されたフィールドである場合には、前記第１のフィールドに対応する第２のフィールドを含む前記第２種のヘッダを生成し、
    前記第１種のヘッダ内に含まれる前記第１のフィールドが予め定義されていないフィールドである場合には、所定の識別情報と前記第１のフィールドの記述とを有する第３のフィールドを含む前記第２種のヘッダを生成する工程を含むことを特徴とする制御方法。
12. ネットワークを介して接続される任意のコンピュータと第１種のプロトコルに従った第１種の通信データの通信を行う第１の通信部と、前記ネットワークを介さずに接続されるローカルデバイスと第２種のプロトコルに従った第２種の通信データの通信を行う第２の通信部と、を備える制御装置によって実行される制御方法であって、
    前記第２の通信部が前記ローカルデバイスから受信した前記第２種の通信データに含まれる第３種のヘッダから、前記第１の通信部が特定のコンピュータに送信する前記第１種の通信データに含まれるべき第４種のヘッダを生成することによって、前記第２種のプロトコルから前記第１種のプロトコルへの変換を行う工程を備え、
    前記変換工程は、
    前記第３種のヘッダ内に含まれる第４のフィールドが予め定義されたフィールドである場合には、前記第４のフィールドに対応する第５のフィールドを含む前記第４種のヘッダを生成し、
    前記第３種のヘッダ内に含まれる前記第４のフィールドが所定の識別情報を有するフィールドである場合には、前記所定の識別情報が削除された第６のフィールドを含む前記第４種のヘッダを生成する工程を含むことを特徴とする制御方法。
13. ネットワークを介して接続される任意のコンピュータと第１種のプロトコルに従った第１種の通信データの通信を行う第１の通信部と、前記ネットワークを介さずに接続されるローカルデバイスと第２種のプロトコルに従った第２種の通信データの通信を行う第２の通信部と、を備える制御装置に制御を実行させるためのコンピュータプログラムであって、
    前記第１の通信部が第１のコンピュータから受信した前記第１種の通信データに含まれる第１種のヘッダから、前記第２の通信部が前記ローカルデバイスに送信する前記第２種の通信データに含まれるべき第２種のヘッダを生成することによって、前記第１種のプロトコルから前記第２種のプロトコルへの変換を行う機能を、前記制御装置に実現させ、
    前記変換機能は、
    前記第１種のヘッダ内に含まれる第１のフィールドが予め定義されたフィールドである場合には、前記第１のフィールドに対応する第２のフィールドを含む前記第２種のヘッダを生成し、
    前記第１種のヘッダ内に含まれる前記第１のフィールドが予め定義されていないフィールドである場合には、所定の識別情報と前記第１のフィールドの記述とを有する第３のフィールドを含む前記第２種のヘッダを生成する機能を含むことを特徴とするコンピュータプログラム。
14. ネットワークを介して接続される任意のコンピュータと第１種のプロトコルに従った第１種の通信データの通信を行う第１の通信部と、前記ネットワークを介さずに接続されるローカルデバイスと第２種のプロトコルに従った第２種の通信データの通信を行う第２の通信部と、を備える制御装置に制御を実行させるためのコンピュータプログラムであって、
    前記第２の通信部が前記ローカルデバイスから受信した前記第２種の通信データに含まれる第３種のヘッダから、前記第１の通信部が特定のコンピュータに送信する前記第１種の通信データに含まれるべき第４種のヘッダを生成することによって、前記第２種のプロトコルから前記第１種のプロトコルへの変換を行う機能を、前記制御装置に実現させ、
    前記変換機能は、
    前記第３種のヘッダ内に含まれる第４のフィールドが予め定義されたフィールドである場合には、前記第４のフィールドに対応する第５のフィールドを含む前記第２種のヘッダを生成し、
    前記第３種のヘッダ内に含まれる前記第４のフィールドが所定の識別情報を有するフィールドである場合には、前記所定の識別情報が削除された第６のフィールドを含む前記第４種のヘッダを生成する機能を含むことを特徴とするコンピュータプログラム。
15. 請求項１３または１４記載のコンピュータプログラムを記録したコンピュータ読み取り可能な記録媒体。

Images