JP2022032183A - サーバー及び印刷システム - Google Patents

Abstract

【課題】 メディア情報を用いることによって、利便性向上や印刷ミス抑制が可能なサーバー及び印刷システム等の提供。【解決手段】 サーバー１００は、クライアント３００と所与のプロトコルによる通信を行う第１インターフェイス１３０と、少なくとも１つの給紙装置２７０を有する印刷装置２００とＵＳＢ規格による通信を行う第２インターフェイスと１４０と、制御部１１０と、記憶部１２０を含む。制御部１１０は、第２インターフェイス１４０を介して、印刷装置２００の給紙装置２７０に格納されているメディアのメディア情報を取得し、メディア情報を記憶部１２０に記憶する制御を行い、クライアント３００からメディア情報の取得要求を受信したとき、記憶部１２０から読み出したメディア情報を、第１インターフェイス１３０を介してクライアント３００に送信する制御を行う。【選択図】 図２

Description

本発明は、サーバー及び印刷システム等に関する。

従来、プリントサーバー等のデバイスサーバーが広く知られている。デバイスサーバーは、ＵＳＢ（Universal Serial Bus）等を用いて接続されたデバイスの情報を取得し、取得した情報に基づいて、デバイスが有する機能をネットワーク上のクライアントに提供する。

例えば特許文献１には、デバイスをネットワーク上のクライアントＰＣ（Personal Computer）で共用する場合の通信制御手法が開示されている。

特開２０１１－７６４３７号公報

特許文献１の手法では、デバイスサーバーは、印刷装置等のデバイスの情報をクライアントＰＣに提供することが可能である。ただし特許文献１のデバイスサーバーは、動的に変動する状態を提供していない。動的に変動する状態には、用紙サイズ等のメディア情報が含まれる。

本開示の一態様は、クライアントと所与のプロトコルによる通信を行う第１インターフェイスと、少なくとも１つの給紙装置を有する印刷装置とＵＳＢ規格による通信を行う第２インターフェイスと、前記第１インターフェイス及び前記第２インターフェイスの制御を行う制御部と、記憶部と、を含み、前記制御部は、前記第２インターフェイスを介して、前記印刷装置の前記給紙装置に格納されているメディアのメディア情報を取得し、取得した前記メディア情報を前記記憶部に記憶する制御を行い、前記第１インターフェイスを介して前記クライアントから前記メディア情報の取得要求を受信したとき、前記記憶部から前記メディア情報を読み出し、読み出した前記メディア情報を、前記第１インターフェイスを介して前記クライアントに送信する制御を行うサーバーに関係する。

本開示の他の態様は、少なくとも１つの給紙装置を有する印刷装置と、サーバーを含み、前記サーバーは、クライアントと所与のプロトコルによる通信を行う第１インターフェイスと、前記印刷装置とＵＳＢ規格による通信を行う第２インターフェイスと、前記第１インターフェイス及び前記第２インターフェイスの制御を行う制御部と、記憶部と、を含み、前記制御部は、前記第２インターフェイスを介して前記印刷装置の前記給紙装置に格納されているメディアのメディア情報を取得し、取得した前記メディア情報を前記記憶部に記憶する制御を行い、前記第１インターフェイスを介して前記クライアントから前記メディア情報の取得要求を受信したとき、前記記憶部から前記メディア情報を読み出し、読み出した前記メディア情報を、前記第１インターフェイスを介して前記クライアントに送信する制御を行う印刷システムに関係する。

サーバーを含む印刷システムの構成例。 サーバーの構成例。 印刷装置の構成例。 クライアントの構成例。 クライアントが印刷装置を追加する際の処理を説明する図。 印刷装置におけるメディア情報の取得処理を説明する図。 印刷装置の表示部に表示される画面例。 メディア情報の例。 サーバーが印刷装置からメディア情報を取得する処理を説明する図。 サーバーが記憶する情報の例。 クライアントがサーバーからメディア情報を取得する処理を説明する図。 印刷処理を説明する図。 印刷処理を説明する他の図。 印刷設定画面の例。 印刷設定画面の他の例。 メディア情報取得処理と印刷データ送信処理の実行タイミングを説明する図。 サーバーがメディア情報の変更を通知する場合の処理を説明する図。 クライアントの起動時の処理を説明する図。

以下、本開示の好適な実施形態について詳細に説明する。なお以下に説明する本実施形態は特許請求の範囲に記載された内容を不当に限定するものではなく、本実施形態で説明される構成の全てが必須構成要件であるとは限らない。

１．システム構成
図１は、本実施形態に係るサーバー１００を含む印刷システム１０の構成例を説明する図である。図１に示すように、印刷システム１０は、サーバー１００と印刷装置２００を含む。またサーバー１００は、ネットワークＮＷを介してクライアント３００と接続される。

サーバー１００は、デバイスサーバーであり、狭義には印刷装置２００と接続されるプリントサーバーである。印刷装置２００は、印刷機能を有する装置である。印刷装置２００は、印刷機能を含む複数の機能を有する複合機（ＭＦＰ：Multifunction Peripheral）であってもよい。クライアント３００は、スマートフォンやタブレット端末等の携帯端末装置である。またクライアント３００は、ＰＣ等の情報処理装置であってもよい。

クライアント３００上ではアプリケーションＡｐｐ、ドライバーＤｒｉ等のソフトウェアが動作する。例えばアプリケーションＡｐｐは、ドライバーＤｒｉのＡＰＩ（Application Programming Interface）を呼び出することによって、印刷設定の取得や、印刷の実行を要求する。アプリケーションＡｐｐの要求を実行するため、ドライバーＤｒｉはネットワークＮＷ経由でサーバー１００と通信する。

サーバー１００はＵＳＢ経由で印刷装置２００と接続され、ネットワークＮＷ経由でクライアント３００と接続される。より具体的には、サーバー１００は所与のプロトコルを用いてクライアント３００との通信を行う。サーバー１００は、クライアント３００からの要求を実行するため、ＵＳＢ経由で印刷装置２００にコマンドを送信し、応答を処理する。

印刷装置２００は、サーバー１００からのコマンドに基づいて、情報の応答や、印刷を実行する。印刷装置２００は、給紙装置２７０を含む。給紙装置２７０にはセンサー２７１が設けられており、印刷装置２００はセンサー２７１の出力に基づいて、メディアがセットされたことを検出できる。またセンサー２７１は、メディアのサイズを検出可能であってもよい。

なお、印刷システム１０は図１の構成に限定されず、他の構成要素を追加するなどの種々の変形実施が可能である。例えば、クライアント３００や印刷装置２００は複数であってもよい。また、アプリケーションＡｐｐがドライバーＤｒｉを介さずにサーバー１００と通信する等、クライアント３００上のソフトウェアの構成は異なってもよい。また、構成要素の省略や追加等の変形実施が可能である点は、後述する図２～図４等においても同様である。

図１の構成を用いることによって、印刷装置２００の機能を、ネットワークＮＷを介して接続されるクライアント３００に提供することが可能になる。特に、印刷装置２００が所与の通信プロトコルに対応していない場合であっても、サーバー１００が当該プロトコルを用いた通信を実行可能であることによって、クライアント３００は、印刷装置２００を、当該プロトコルを用いた印刷機能を提供する機器として利用することが可能になる。

ただし、プロトコルによっては、メディア情報が必須の場合がある。またプロトコルによっては、メディア情報は必須でないものの、メディア情報を使用することによって利便性が向上可能な場合がある。ここでのメディア情報は、印刷装置２００が画像を形成する対象となる媒体に関する情報である。メディア情報は、メディアのサイズ情報や種類情報を含む。サイズ情報とは、Ａ４、Ａ５、Ｌ版等のメディアのサイズを表す情報である。種類情報とは、普通紙や写真用紙等のメディアの種類を表す情報である。なお、以下ではメディアが紙である例について説明するが、メディアは布、フィルム、ＰＶＣ（polyvinyl chloride）等の他の媒体を含んでもよい。

特許文献１等の従来手法では、デバイスサーバーは、動的に変化する情報である印刷装置２００のメディア情報を収集、提供する手法を開示していない。また従来手法では、プロトコルと、当該プロトコルにおいて必須又は有用な情報との関係を考慮していない。そのため従来のデバイスサーバーは、例えばメディア情報が必須であるプロトコルによって、印刷装置２００の機能を提供できない。或いは従来のデバイスサーバーは、上記プロトコルによって、印刷装置２００の機能を提供できたとしても、利便性を高めることが難しい。

これに対して、本実施形態に係るサーバー１００は、印刷装置２００のメディア情報を取得し、当該メディア情報をクライアント３００に提供する。以下、図２～図４を用いて、サーバー１００、印刷装置２００、クライアント３００の構成例を説明する。

図２は、サーバー１００の構成例を示す図である。サーバー１００は、制御部１１０と、記憶部１２０と、第１インターフェイス１３０と、第２インターフェイス１４０を含む。

制御部１１０は、第１インターフェイス１３０及び第２インターフェイス１４０の通信制御を行う。また制御部１１０は、記憶部１２０の書き込み及び読み出しの制御を行う。制御部１１０は、具体的にはプロセッサー又はコントローラーである。

本実施形態の制御部１１０は、下記のハードウェアによって構成される。ハードウェアは、デジタル信号を処理する回路及びアナログ信号を処理する回路の少なくとも一方を含むことができる。例えば、ハードウェアは、回路基板に実装された１又は複数の回路装置や、１又は複数の回路素子によって構成できる。１又は複数の回路装置は例えばＩＣ（Integrated Circuit）、ＦＰＧＡ（field-programmable gate array）等である。１又は複数の回路素子は例えば抵抗、キャパシター等である。

また制御部１１０は、下記のプロセッサーによって実現されてもよい。本実施形態のサーバー１００は、情報を記憶するメモリーと、メモリーに記憶された情報に基づいて動作するプロセッサーと、を含む。ここでのメモリーは、記憶部１２０であってもよいし、他のメモリーであってもよい。情報は、例えばプログラムと各種のデータ等である。プロセッサーは、ハードウェアを含む。プロセッサーは、ＣＰＵ（Central Processing Unit）、ＧＰＵ（Graphics Processing Unit）、ＤＳＰ（Digital Signal Processor）等、各種のプロセッサーを用いることが可能である。メモリーは、ＳＲＡＭ（Static Random Access Memory）、ＤＲＡＭ（Dynamic Random Access Memory）などの半導体メモリーであってもよいし、レジスターであってもよいし、ハードディスク装置等の磁気記憶装置であってもよいし、光学ディスク装置等の光学式記憶装置であってもよい。例えば、メモリーはコンピューターによって読み取り可能な命令を格納しており、当該命令をプロセッサーが実行することによって、制御部１１０の機能が処理として実現される。ここでの命令は、プログラムを構成する命令セットの命令でもよいし、プロセッサーのハードウェア回路に対して動作を指示する命令であってもよい。

記憶部１２０は、データやプログラムなどの各種の情報を記憶する。制御部１１０、第１インターフェイス１３０、第２インターフェイス１４０は例えば記憶部１２０をワーク領域として動作する。記憶部１２０は、ＳＲＡＭ、ＤＲＡＭなどの半導体メモリーであってもよいし、レジスターであってもよいし、磁気記憶装置であってもよいし、光学式記憶装置であってもよい。記憶部１２０は、印刷装置２００のメディア情報を記憶する。

第１インターフェイス１３０は、ネットワークＮＷを介してクライアント３００との通信を行うインターフェイスである。例えば、ここでのネットワークＮＷは、無線ＬＡＮ（Local Area Network）である。第１インターフェイス１３０は、例えばＩＥＥＥ８０２．１１の規格に従った無線通信を行う無線通信デバイスである。第１インターフェイス１３０は、例えばＷｉ－Ｆｉ方式の無線通信を行うＷｉ－Ｆｉチップである。ただしここでのネットワークＮＷは、イーサネット等の他のネットワークであってもよく、第１インターフェイス１３０が有線での通信を行うための通信インターフェイスであってもよい。

本実施形態のサーバー１００は、第１インターフェイス１３０を用いて、クライアント３００との間で所与のプロトコルに従った通信を行う。なお当該プロトコルに従った通信を行うための通信制御は、制御部１１０によって行われる。ここでの制御部１１０は、第１インターフェイス１３０とは別体として設けられるプロセッサーであってもよいし、第１インターフェイス１３０の内部に設けられるプロセッサーであってもよいし、その両方の組み合わせであってもよい。

第１インターフェイス１３０は、後述するように、クライアント３００へのメディア情報の送信や、クライアント３００からの印刷要求の受信等を行う。

第２インターフェイス１４０は、ＵＳＢ規格に従った通信を行う通信インターフェイスであり、印刷装置２００との通信を行う。第２インターフェイス１４０は、具体的にはＵＳＢホストコントーラーやルートハブ等を含むＵＳＢインターフェイスである。なおＵＳＢ規格はＵＳＢ２．０やＵＳＢ３．０等の種々の規格が知られている。本実施形態のＵＳＢは、これらの種々の規格や、当該規格を発展させた規格を含むことが可能である。

第２インターフェイス１４０は、後述するように、印刷装置２００からのメディア情報の取得や、印刷装置２００への印刷コマンド及び印刷データの送信等を行う。

図３は、印刷装置２００の構成の一例を示すブロック図である。印刷装置２００は、処理部２１０、通信部２２０、表示部２３０、操作部２４０、印刷部２５０、記憶部２６０、給紙装置２７０を含む。

処理部２１０は、印刷装置２００の各部の制御を行う。例えば処理部２１０は、メインＣＰＵ、サブＣＰＵなどの複数のＣＰＵを含むことができる。メインＣＰＵは、印刷装置２００の各部の制御や全体的な制御を行う。サブＣＰＵは、例えば印刷についての各種の処理を行うＣＰＵである。

本実施形態の処理部２１０は、デジタル信号を処理する回路及びアナログ信号を処理する回路の少なくとも一方を含むハードウェアによって構成される。例えば、ハードウェアは、回路基板に実装された１又は複数の回路装置や、１又は複数の回路素子によって構成できる。また処理部２１０は、ハードウェアを含むプロセッサーにより実現されてもよい。本実施形態の印刷装置２００は、情報を記憶するメモリーと、メモリーに記憶された情報に基づいて動作するプロセッサーと、を含む。プロセッサーは、ＣＰＵ、ＧＰＵ、ＤＳＰ等、各種のプロセッサーを用いることが可能である。メモリーは、半導体メモリー、レジスター、磁気記憶装置、光学式記憶装置等である。

通信部２２０は、ＵＳＢ規格に従った通信を行う。通信部２２０は、具体的にはＵＳＢホストコントーラー等を含むＵＳＢインターフェイスである。

また通信部２２０は、Ｗｉ－Ｆｉ規格に準拠した無線通信を実行する無線通信デバイスを含んでもよい。ただし、印刷装置２００の通信部２２０は、サーバー１００が第１インターフェイス１３０を用いて実行する通信に用いられる上記所与のプロトコルに非対応であることが想定される。

表示部２３０は、各種情報をユーザーに表示するディスプレイ等で構成される。操作部２４０は、ユーザーからの入力操作を受け付けるボタン等で構成される。なお、表示部２３０及び操作部２４０は、例えばタッチパネルにより一体的に構成してもよい。

印刷部２５０は、印刷エンジンを含む。印刷エンジンとは、印刷対象となるメディアへの画像の印刷を実行する機械的構成である。印刷エンジンは、例えばインクジェット方式の吐出ヘッド、当該吐出ヘッドを含むキャリッジの駆動機構等を含む。印刷エンジンは、給紙装置２７０から搬送されたメディアに対して、吐出ヘッドからインクを吐出することによって、当該メディアに画像を印刷する。なお、印刷エンジンの具体的構成はここで例示したものに限られず、電子写真方式でトナーにより印刷するものでもよい。

記憶部２６０は、データやプログラムなどの各種の情報を記憶する。処理部２１０や通信部２２０は例えば記憶部２６０をワーク領域として動作する。記憶部２６０は、半導体メモリーであってもよいし、レジスターであってもよいし、磁気記憶装置であってもよいし、光学式記憶装置であってもよい。記憶部２６０は、メディア情報を記憶する。

給紙装置２７０は、印刷に用いられるメディアが載置される装置である。給紙装置２７０は、例えば用紙カセットである。給紙装置２７０には、センサー２７１が設けられる。センサー２７１は、例えば給紙装置２７０にメディアがセットされたことを検出するセンサーである。或いはセンサー２７１は、メディアのサイズを検出可能なセンサーであってもよい。例えばセンサー２７１は、メディアの載置や搬送をガイドするための用紙ガイドの位置を検出することによって、メディアのサイズを検出する。

図４は、クライアント３００の構成の一例を示すブロック図である。クライアント３００は、処理部３１０、無線通信部３２０、表示部３３０、操作部３４０、報知部３５０、記憶部３６０を含む。

処理部３１０は、無線通信部３２０、表示部３３０、操作部３４０、報知部３５０、記憶部３６０の各部の制御を行う。処理部３１０は、具体的にはプロセッサー又はコントローラーである。クライアント３００は、情報を記憶するメモリーと、メモリーに記憶された情報に基づいて動作するプロセッサーと、を含む。例えば、メモリーはアプリケーションソフトウェアとドライバーソフトウェアを格納している。プロセッサーが当該ソフトウェアに従って動作することによって、図１に示すアプリケーションＡｐｐやドライバーＤｒｉが実現される。

無線通信部３２０は、少なくとも１つの無線通信デバイスにより実現される。無線通信デバイスは、例えば、Ｗｉ－Ｆｉ規格に準拠した無線通信を実行する無線通信デバイスである。ただし、クライアント３００は、有線通信を実行する通信部を含んでもよい。

表示部３３０は、各種情報をユーザーに表示するディスプレイ等で構成される。操作部３４０は、ユーザーからの入力操作を受け付けるボタン等で構成される。なお、表示部３３０及び操作部３４０は、例えばタッチパネルにより一体的に構成してもよい。報知部３５０は、ユーザーに対する報知を行う。報知部３５０は、例えば音による報知を行うスピーカーであってもよいし、振動による報知を行う振動部であってもよいし、これらの組み合わせであってもよい。

記憶部３６０は、データやプログラムなどの各種の情報を記憶する。処理部３１０や無線通信部３２０は例えば記憶部３６０をワーク領域として動作する。記憶部３６０は、ＳＲＡＭ、ＤＲＡＭなどの半導体メモリーであってもよいし、レジスターであってもよいし、磁気記憶装置であってもよいし、光学式記憶装置であってもよい。

図２に示したように、本実施形態に係るサーバー１００は、第１インターフェイス１３０と、第２インターフェイス１４０と、制御部１１０と、記憶部１２０を含む。第１インターフェイス１３０は、クライアント３００と所与のプロトコルによる通信を行う。第２インターフェイス１４０は、印刷装置２００とＵＳＢ規格による通信を行う。制御部１１０は、第１インターフェイス１３０及び第２インターフェイス１４０の制御を行う。

なお、ネットワークを介した通信を実現する際には、複数のプロトコルが用いられる。複数のプロトコルとは、例えばＴＣＰ／ＩＰ（Transmission Control Protocol /Internet Protocol）群に含まれる種々のプロトコルである。本実施形態においても、例えばＭＡＣ（Medium Access Control）等のプロトコルを用いてイーサネットや無線ＬＡＮによる通信を実現し、さらにその上で動作する複数のプロトコルを組み合わせることによって、クライアント３００に印刷装置２００の機能を提供するための通信を実現することが想定される。ここで、上記「所与のプロトコル」は、当該複数のプロトコルの組み合わせを表すものであってもよいし、そのうちの一部のプロトコルを表すものであってもよい。本実施形態における「所与のプロトコル」とは、メディア情報が必須又は有用であるプロトコルであればよく、具体的なプロトコルは種々の変形実施が可能である。

制御部１１０は、第２インターフェイス１４０を介して、印刷装置２００の給紙装置２７０に格納されているメディアのメディア情報を取得し、取得したメディア情報を記憶部１２０に記憶する制御を行う。また制御部１１０は、第１インターフェイス１３０を介してクライアント３００からメディア情報の取得要求を受信したとき、記憶部１２０からメディア情報を読み出し、読み出したメディア情報を、第１インターフェイス１３０を介してクライアント３００に送信する制御を行う。

本実施形態の手法によれば、所与のプロトコルを用いてクライアント３００との通信を行うサーバー１００において、ＵＳＢ接続される印刷装置２００のメディア情報を収集すること、及び、収集したメディア情報をクライアント３００に提供することが可能になる。このようにすれば、印刷装置２００自体が上記所与のプロトコルに対応していない場合であっても、クライアント３００に対して当該プロトコルを用いて印刷装置２００の機能を提供することが可能になる。その際、シンプルな印刷機能を提供するだけでなく、メディア情報を利用した機能を提供することが可能になる。例えばサーバー１００を利用した印刷において、ユーザーが印刷操作を行う際に、印刷設定値のデフォルト値としてセットされている用紙サイズ及び用紙種類の少なくとも一方を表示できる。これにより、ユーザーの操作を容易にすることや、設定ミスによる印刷ミスを抑制することが可能になる。

また本実施形態の手法は、上記の印刷装置２００と、サーバー１００を含む印刷システム１０に適用できる。印刷システム１０のサーバー１００は、上述したとおり、第１インターフェイス１３０と、第２インターフェイス１４０と、制御部１１０と、記憶部１２０を含む。サーバー１００の制御部１１０は、第２インターフェイス１４０を介して印刷装置２００の給紙装置２７０に格納されているメディアのメディア情報を取得し、取得したメディア情報を記憶部１２０に記憶する制御を行う。制御部１１０は、第１インターフェイス１３０を介してクライアント３００からメディア情報の取得要求を受信したとき、記憶部１２０からメディア情報を読み出し、読み出したメディア情報を、第１インターフェイス１３０を介してクライアント３００に送信する制御を行う。

２．処理の流れ
本実施形態の処理の流れを詳細に説明する。

２．１ クライアントにおける印刷前の処理
図５は、クライアント３００において印刷前に実行される処理の流れを説明する図である。具体的には、クライアント３００は印刷装置２００の探索と、ドライバーＤｒｉのインストールを行う。なお、図５の説明では通信態様の詳細を省略する場合があるが、クライアント３００とサーバー１００との間の通信は、ネットワークＮＷを介して行われる。具体的には、サーバー１００は第１インターフェイス１３０を用いてクライアント３００と通信する。またサーバー１００と印刷装置２００の間の通信は、ＵＳＢを用いて行われる。具体的には、サーバー１００は第２インターフェイス１４０を用いて印刷装置２００と通信する。この点は、図６以降の図面の説明においても同様である。

この処理が開始されると、まずステップＳ１０１において、ユーザーがクライアント３００に印刷装置２００を追加する操作を行う。ステップＳ１０２において、クライアント３００は、ネットワークＮＷ上の印刷装置２００を探索する処理を行う。具体的には、クライアント３００は、ネットワークＮＷにマルチキャストパケットを送信する。サーバー１００は、クライアント３００と同じネットワークＮＷに接続しているため、マルチキャストパケットを受信可能である。

ステップＳ１０３において、サーバー１００は、マルチキャストパケットに対する応答として、印刷装置２００の名称や接続情報を送信する。具体的には、サーバー１００はＵＳＢ接続された印刷装置２００の情報をあらかじめ取得しておく。なお、サーバー１００にＵＳＢ接続される印刷装置２００は複数であってもよく、この場合、サーバー１００は、複数の印刷装置２００のそれぞれについて、名称や接続情報を送信する。またステップＳ１０３において、サーバー１００は、サーバー１００自身の名称や接続情報を送信してもよい。

ここでの接続情報は、クライアント３００が印刷装置２００を特定してコマンドや印刷データを送信する際に用いられる情報である。例えば接続情報は、ＩＰアドレスやポート番号を含む。またクライアント３００はＵＲＬ（Uniform Resource Locator）等を用いて印刷装置２００を特定してもよく、この場合の接続情報はＵＲＬであってもよい。

ステップＳ１０４において、クライアント３００は、サーバー１００又は印刷装置２００の名称を、表示部３３０に表示する。なお、ネットワークＮＷに他のサーバー１００や印刷装置２００が接続されてもよい。その場合、ステップＳ１０４では、複数のサーバー１００や複数の印刷装置２００の名称が表示される。

ステップＳ１０５において、ユーザーは、表示部３３０に表示された１又は複数の名称から、印刷に使用する印刷装置２００の名称を選択する。クライアント３００は、選択された印刷装置２００を使用するためのドライバーＤｒｉをインストールする処理を行う。

通信に用いるプロトコルによっては、ドライバーＤｒｉが１つに限定される場合がある。この場合、ステップＳ１０６において、クライアント３００は当該ドライバーＤｒｉをインストールする処理を行う。なお、システムによってはドライバーＤｒｉ相当の機能があらかじめ組み込まれていて、ドライバーＤｒｉのインストールが必要ないシステムもある。この場合、ステップＳ１０６の処理は省略が可能であり、クライアント３００は単にステップＳ１０５で選択された印刷装置２００の情報を記憶する。

一方、プロトコルからドライバーＤｒｉが一意に決定されない場合、クライアント３００は印刷装置２００に問い合わせを行い、回答に応じてドライバーＤｒｉを決定する。具体的には、ステップＳ１０７において、クライアント３００はユーザーによって選択された印刷装置２００の接続情報に基づいて、機種やサポートする印刷データフォーマットを問い合わせる。クライアント３００からの問い合わせは、サーバー１００に送信される。

ステップＳ１０８において、サーバー１００は、クライアント３００からの問い合わせに基づいて、印刷装置２００に機種等を問い合わせる。ステップＳ１０９において、印刷装置２００は、機種等の情報をサーバー１００に回答する。なお、サーバー１００は、ＵＳＢ接続された際に印刷装置２００の機種等の情報をあらかじめ取得、記憶しておいてもよい。この場合、ステップＳ１０８及びＳ１０９の処理を省略できる。ステップＳ１１０において、サーバー１００は、印刷装置２００の機種等の情報をクライアント３００に回答する。

ステップＳ１１１において、クライアント３００は回答された機種やサポートする印刷データフォーマットに基づいて、ドライバーＤｒｉを選択する。ステップＳ１１２において、クライアント３００は選択したドライバーＤｒｉをインストールする。なお必要に応じて、クライアント３００はインターネット等のネットワークを用いて、ドライバーＤｒｉをダウンロードする処理を行ってもよい。

以上のように、サーバー１００の制御部１１０は、クライアント３００から印刷装置２００の探索要求を受信したとき、ＵＳＢ接続している印刷装置２００に関する印刷装置情報を、第１インターフェイス１３０を介してクライアント３００に送信する制御を行う。

ここで、探索要求とは、例えばステップＳ１０２におけるマルチキャストパケットである。ただし探索要求は、ネットワークＮＷ上に存在する印刷装置２００又はサーバー１００に対して回答を求める要求であればよく、具体的な形式はこれに限定されない。また印刷装置情報とは、印刷装置２００に関する情報であり、例えば上記のように名称及び接続情報を含む。

このようにすれば、サーバー１００は、ＵＳＢ接続している印刷装置２００に関する情報を、適切にクライアント３００に送信できる。ここでの印刷装置２００は直接ネットワークＮＷに接続されていないが、当該ネットワークＮＷに接続しているサーバー１００が、印刷装置２００に代わって回答することによって、クライアント３００から印刷装置２００を探索することが可能になる。換言すれば、本実施形態のサーバー１００は、クライアント３００から見たとき、あたかも印刷装置２００であるかのように振る舞う。

２．２ 印刷装置におけるメディア情報設定
図６は、印刷装置２００がメディア情報を取得する処理を説明する図である。まずステップＳ２０１において、ユーザーが印刷装置２００の給紙装置２７０にメディアをセットする。ここでのメディアは例えば用紙であり、ユーザーは、用紙ガイドに沿って、所定の位置に用紙を載置する。

ステップＳ２０２において、印刷装置２００は、給紙装置２７０にメディアがセットされたことをセンサー２７１を用いて検出する。メディアのセットを検出した場合、ステップＳ２０３において、印刷装置２００は表示部２３０に、メディア情報を問い合わせる画面を表示する。

図７は、ステップＳ２０３において表示される画面の例である。図７に示すように、印刷装置２００は、給紙装置２７０を特定する情報と、サイズ情報と、種類情報とを含む表示画面を表示する。給紙装置２７０を特定する情報は、Ｘ１に示すように給紙装置２７０の名称であってもよいし、Ｘ２に示すように印刷装置２００の外観図における給紙装置２７０の位置を特定する情報であってもよい。図７では、印刷装置２００は、センサー２７１の出力に基づいて、メディアがセットされた給紙装置２７０がＣ１であると特定した例を示している。

表示画面にはＸ３に示す暫定的なサイズ情報と、Ｘ４に示す暫定的な種類情報が表示されている。また表示画面には、例えばＸ５に示すように、メディア情報の確認や変更を促すテキストが表示されている。ユーザーは、表示画面を確認し、必要に応じて操作部２４０を用いてメディア情報の入力操作を行う。なお、初期状態においてはサイズ情報及び種類情報が非表示であり、ユーザーによる入力が行われた後に、サイズ情報や種類情報が表示されてもよい。或いは、初期状態においてはデフォルトとして設定されているサイズ情報及び種類情報が表示されていてもよい。デフォルトのサイズ情報及び種類情報は任意であるが、例えば使用頻度が高い「Ａ４」、「普通紙」が用いられる。

また本実施形態のセンサー２７１は、用紙サイズを検出可能なセンサーであってもよい。例えばセンサー２７１は、用紙ガイドの位置を検出することによって用紙サイズを検出する。この場合、センサー２７１の検出結果が、初期状態におけるサイズ情報として表示される。

図６に戻って説明を続ける。ステップＳ２０４において、図７に示した表示画面に基づいて、ユーザーがサイズ情報及び種類情報を入力し、決定ボタンを押下する。ステップＳ２０５において、印刷装置２００は、入力されたメディア情報を、設定値として記憶部２６０に記憶する。

なお印刷装置２００は複数の給紙装置２７０を含んでもよい。この場合、給紙装置２７０ごとに、種々のメディアをセットすることが可能である。よって印刷装置２００は、給紙装置２７０ごとのメディア情報を記憶部２６０に記憶する。また後述するように、サーバー１００の制御部１１０は、第２インターフェイス１４０を介して、複数の給紙装置２７０の各給紙装置２７０に格納されているメディアに関するメディア情報を取得する制御を行う。

図８は、印刷装置２００が記憶部２６０に記憶するメディア情報の例である。メディア情報は、給紙装置２７０を特定する情報と、サイズ情報と、種類情報とを含む。給紙装置２７０を特定する情報は、例えば給紙装置２７０の名称である。またメディア情報は、図８には不図示の他の情報を含んでもよい。

図８は、Ｃ１～Ｃ４の４つの給紙装置２７０を含む印刷装置２００におけるメディア情報の例である。この例では、Ｃ１に示す給紙装置２７０にＡ４普通紙がセットされている。同様に、Ｃ２に示す給紙装置２７０にＬ版の写真用紙がセットされ、Ｃ３に示す給紙装置２７０にＡ４普通紙がセットされ、Ｃ４に示す給紙装置２７０にＡ５普通紙がセットされている。

このように、１つの印刷装置２００におけるメディア情報は、複数の給紙装置２７０のそれぞれについて、当該給紙装置２７０にセットされたメディアを特定する情報であってもよい。このようにすれば、複数の給紙装置２７０を含む印刷装置２００にセットされたメディアの情報を適切に管理することが可能になる。図６及び図７を用いて上述したように、所与の給紙装置２７０においてメディアのセットが検出された場合、当該給紙装置２７０に関するメディア情報の更新処理が行われる。

なお、印刷装置２００は単一の給紙装置２７０を含む装置であってもよく、この場合のメディア情報は当該単一の給紙装置２７０にセットされたメディアに関する情報である。

２．３ 印刷装置からサーバーへのメディア情報の送信
図９は、印刷装置２００が記憶したメディア情報を、サーバー１００に送信する処理を説明する図である。まずステップＳ３０１において、サーバー１００はＵＳＢを用いて、印刷装置２００にメディア情報を取得するコマンドを送信する。ステップＳ３０１の処理は、例えば定期的に実行される。処理の実行間隔は例えば数秒であるが、具体的な時間はこれに限定されない。またサーバー１００に複数の印刷装置２００がＵＳＢ接続される場合、それぞれの印刷装置２００を対象として図９の処理が実行される。

コマンドを受信した印刷装置２００は、ステップＳ３０２において、記憶部２６０に記憶されたメディア情報を読み出し、当該メディア情報をＵＳＢを用いてサーバー１００に送信する。

ステップＳ３０３において、サーバー１００は、対象となる印刷装置２００の過去のメディア情報と、ステップＳ３０２で新たに取得したメディア情報を比較する。メディア情報が同じである場合、サーバー１００は処理を終了する。具体的には、印刷装置２００のメディアは変更されておらず、記憶部１２０に記憶されているメディア情報を継続して利用可能と判定される。ここでメディア情報が同じであるとは、例えば図８に示した給紙装置２７０ごとのサイズ情報及び種類情報が、全て一致することを表す。

また少なくとも１つの給紙装置２７０において、サイズ情報及び種類情報の少なくとも一方が変化している場合、２つのメディア情報は異なると判定される。この場合、ステップＳ３０４において、サーバー１００は、ステップＳ３０２で取得したメディア情報を記憶部１２０に記憶する。またステップＳ３０４において、サーバー１００はメディア情報のバージョン情報を更新する。ここでのバージョン情報とは、メディア情報のバージョンを表す情報である。バージョン情報は、メディア情報が更新されるごとに値がインクリメントされる数値データであってもよいし、更新タイミングを表すタイムスタンプであってもよい。またバージョン情報は、メディア情報の内容に応じて変化する情報であってもよい。

図１０は、サーバー１００が記憶部１２０に記憶する情報の例である。サーバー１００には、１又は複数の印刷装置２００がＵＳＢ接続される。この場合、印刷装置２００ごとに、当該印刷装置２００を特定する情報、接続情報、メディア情報及びバージョン情報が記憶される。

印刷装置２００を特定する情報は、名称であってもよいし、ＭＡＣアドレス等の識別情報であってもよい。接続情報は、上述したようにＩＰアドレス、ポート番号、ＵＲＬ等である。メディア情報は、図８を用いて上述したように、給紙装置２７０ごとのサイズ情報及び種類情報である。バージョン情報は、上述したように、１つのメディア情報のバージョンを管理する情報である。ここでは、１つの印刷装置２００について１つのメディア情報が対応付けられるため、バージョン情報も印刷装置２００ごとに管理される。ただし、給紙装置２７０ごとにバージョン情報を付与する等の変形実施も妨げられない。

以上のように、制御部１１０は、第２インターフェイス１４０を介してメディア情報を取得したとき、取得したメディア情報と、記憶部１２０に記憶された過去のメディア情報との比較処理に基づいて、メディア情報のバージョン情報の管理を行う。ここで比較対象となるのは、同一の印刷装置２００から取得されたタイミングの異なる２つのメディア情報である。このようにすれば、メディア情報の更新の有無をバージョン情報を用いて判定することが可能になる。例えば、図１１を用いて後述するように、サーバー１００は、まずクライアント３００へバージョン情報を送信して更新の有無を判定させる。これにより、不必要な場面でのメディア情報の送信を省略し、通信負荷を抑制すること等が可能になる。

なお、図１１を用いて後述するように、メディア情報はクライアント３００において利用される情報である。クライアント３００は、メディア情報が必要となった場面でサーバー１００に対して問い合わせを行う。そのため、サーバー１００は、クライアント３００からの問い合わせをトリガーとして、図９に示す処理を実行することも妨げられない。ただし、ＵＳＢの通信状態によっては、サーバー１００は、メディア情報を取得するためのコマンドを発行できないタイミングがある。例えば、サーバー１００が、メディア情報の取得対象である印刷装置２００に対して印刷データを送信中の場合、コマンドを発行できない。

よって上述したように、サーバー１００は、図９のステップＳ３０１に示したコマンド送信を定期的に実行してもよい。このようにすれば、サーバー１００が保持するメディア情報が数秒ごとに更新される。クライアント３００からの問い合わせがあったときに、サーバー１００は印刷装置２００にコマンドを発行せずに、自身が保持するメディア情報を回答すればよいため、回答に遅延が発生することを抑制できる。

２．４ サーバーからクライアントへのメディア情報の送信
図１１は、サーバー１００からクライアント３００へメディア情報を送信する処理を説明する図である。まずステップＳ４０１において、クライアント３００は、所与の印刷装置２００のメディア情報が必要となったときに、サーバー１００に問い合わせを送信する。ステップＳ４０１の処理は、例えばドライバーＤｒｉによって行われる。メディア情報が必要になるときとは、後述するように、図１２に示す印刷操作が行われた場合や、図１３に示す印刷設定操作が行われた場合である。ステップＳ４０１における問い合わせは、具体的にはバージョン情報の問い合わせである。

ステップＳ４０２において、サーバー１００は、対象となった印刷装置２００に対応付けられたバージョン情報を回答する。ステップＳ４０３において、クライアント３００は、取得したバージョン情報と、対象となる印刷装置２００に関する前回の問い合わせによって取得、記憶していたバージョン情報とを比較する。ステップＳ４０３の処理は、例えばドライバーＤｒｉによって行われる。

バージョンが同一である場合、クライアント３００はステップＳ４０４～Ｓ４０６の処理を省略する。そして、ステップＳ４０７において、過去に取得した印刷装置２００のメディア情報を継続して利用する。

バージョンが異なる場合、ステップＳ４０４において、クライアント３００は、印刷装置２００のメディア情報をサーバー１００に問い合わせる。ステップＳ４０４の処理は、例えばドライバーＤｒｉによって行われる。ステップＳ４０５において、サーバー１００は、問い合わせ対象である印刷装置２００のメディア情報を、クライアント３００に送信する。ステップＳ４０６において、クライアント３００は、取得したメディア情報を記憶部３６０に記憶する。この場合、ステップＳ４０７において、クライアント３００は、新たに取得したメディア情報を利用する。

以上のように、サーバー１００の制御部１１０は、第１インターフェイス１３０を介してクライアント３００にバージョン情報を送信し（ステップＳ４０２）、バージョン情報に基づいて、クライアント３００からメディア情報の取得要求を受信した場合に（ステップＳ４０４）、メディア情報を送信する（ステップＳ４０５）。

このようにすれば、サーバー１００とクライアント３００との間のメディア情報の送受信を、バージョン情報を用いて制御することが可能になる。バージョン情報は、例えばメディア情報の更新ごとに値が変化する数値データであるため、メディア情報に比べてデータ量が少ない。また、２つのバージョン情報の比較処理は、２つのメディア情報の比較処理に比べて処理負荷が低い。よって図１１に示すように、まずバージョン情報を送受信することによって、メディア情報の更新有無をクライアント３００で判定する際に、当該判定を少ない通信データ量で容易に実現することが可能になる。結果として、メディア情報が更新されていない場合、不要な通信を抑制することが可能になる。

２．５ 印刷
図１２は、印刷に関する処理の流れを説明する図である。まずステップＳ５０１において、ユーザーは、クライアント３００のアプリケーションＡｐｐを操作し、印刷操作を行う。印刷操作とは、例えばアプリケーションＡｐｐによって表示される印刷ボタンの押下操作である。ステップＳ５０１の操作に基づいて、クライアント３００は、所与の印刷装置２００のメディア情報が必要となったと判定する。よってステップＳ５０１をトリガーとして、図１１に示した処理が実行され、クライアント３００は、給紙装置２７０ごとのサイズ情報及び種類情報を取得する。ステップＳ５０２以降の処理は、図１１のステップＳ４０７に対応する。

ステップＳ５０２において、クライアント３００のアプリケーションＡｐｐは、ドライバーＤｒｉからデフォルトの給紙装置２７０と、当該給紙装置２７０に対応付けられたサイズ情報を取得する。またステップＳ５０２において、アプリケーションＡｐｐはサイズ情報に合わせて印刷用の画像を生成する。

ステップＳ５０３において、アプリケーションＡｐｐはドライバーＤｒｉのＡＰＩを呼び出すことによって、印刷を要求する。なおステップＳ５０３の印刷要求には、ステップＳ５０２で生成された画像が付与される。

ステップＳ５０４において、ドライバーＤｒｉは、デフォルトの給紙装置２７０と、当該給紙装置２７０に対応付けられたサイズ情報及び種類情報に基づいて、印刷データを生成する。ここでの印刷データは、例えば印刷画像を特定するデータを含む。ステップＳ５０５において、ドライバーＤｒｉは、ネットワークＮＷを介してサーバー１００に印刷データ送信し、印刷を要求する。

ステップＳ５０６において、サーバー１００はＵＳＢを用いて、印刷コマンド及び印刷データを印刷装置２００に送信する。ステップＳ５０７において、印刷装置２００は、印刷部２５０を用いて印刷を実行する。

図１２に示す処理では、ユーザーは印刷操作を行えば、それ以降は給紙装置２７０の選択操作等を行う必要がないため、印刷に関するユーザー負担を軽減できる。

図１３は、印刷に関する他の処理の流れを説明する図である。まずステップＳ６０１において、ユーザーは、クライアント３００のアプリケーションＡｐｐを操作し、印刷設定操作を行う。印刷設定操作とは、印刷前にメディアのサイズ及び種類を設定するための操作である。なお印刷前の設定には、カラー／モノクロの設定や、片面／両面印刷の設定等が含まれてもよい。ステップＳ６０１の操作に基づいて、クライアント３００は、印刷装置２００のメディア情報が必要となったと判定する。よってステップＳ６０１をトリガーとして、図１１に示した処理が実行され、クライアント３００は、給紙装置２７０ごとのサイズ情報及び種類情報を取得する。ステップＳ６０２以降の処理は、図１１のステップＳ４０７に対応する。

ステップＳ６０２において、クライアント３００のアプリケーションＡｐｐは、ドライバーＤｒｉからデフォルトの給紙装置２７０と、当該給紙装置２７０に対応付けられたサイズ情報及び種類情報を取得する。ステップＳ６０３において、アプリケーションＡｐｐは取得したサイズ情報及び種類情報を選択肢として表示部３３０に表示する。

図１４は、ステップＳ６０３において表示される印刷設定画面の例である。印刷設定画面は、選択されている給紙装置２７０と、当該給紙装置２７０に対応付けられたサイズ情報及び種類情報を表示する画面である。選択されている給紙装置２７０は、例えばプルダウンメニュー等を用いて変更可能である。

図１５は、ステップＳ６０３において表示される印刷設定画面の他の例である。印刷設定画面は、印刷装置２００が有する１又は複数の給紙装置２７０と、各給紙装置２７０に対応付けられたサイズ情報及び種類情報を一覧表示する画面である。図１５に示す例では、例えばラジオボタン等を用いて、いずれか１つの給紙装置２７０を選択する操作が可能である。

ステップＳ６０４において、ユーザーは給紙装置２７０を変更する操作を行う。ステップＳ６０４の操作は、図１４におけるプルダウンメニューの操作であってもよいし、図１５におけるラジオボタンの選択操作であってもよいし、他の操作であってもよい。クライアント３００のアプリケーションＡｐｐは、選択操作に応じて表示画面を更新する。図１４であれば、アプリケーションＡｐｐは、表示されるサイズ情報及び種類情報を、選択された給紙装置２７０に応じて変更する。図１５であれば、アプリケーションＡｐｐは、ラジオボタンの選択状態を変更する。またステップＳ６０５において、アプリケーションＡｐｐは、現在のサイズ及び種類の設定を、選択状態になっている給紙装置２７０に対応するサイズ情報及び種類情報を用いて更新する。なお、ステップＳ６０４及びＳ６０５の処理は、複数回行われてもよいし、１回も行われなくてもよい。

ステップＳ６０６においてユーザーが印刷操作を行うと、ステップＳ６０７において、アプリケーションＡｐｐはドライバーＤｒｉのＡＰＩを呼び出すことによって、印刷を要求する。ステップＳ６０６の操作は、例えば図１４や図１５におけるＯＫボタンの押下操作である。

ステップＳ６０８において、ドライバーＤｒｉは、選択状態になっている給紙装置２７０と、当該給紙装置２７０に対応付けられたサイズ情報及び種類情報に基づいて、印刷データを生成する。ステップＳ６０９において、ドライバーＤｒｉは、ネットワークＮＷを介してサーバー１００に印刷データ送信し、印刷を要求する。

ステップＳ６１０において、サーバー１００はＵＳＢを用いて、印刷コマンド及び印刷データを印刷装置２００に送信する。ステップＳ６１１において、印刷装置２００は、印刷部２５０を用いて印刷を実行する。

このようにすれば、サーバー１００を用いてクライアント３００に印刷装置２００の機能を提供する場合において、印刷時にメディア情報を利用することが可能になる。そのため、ユーザーの操作負担を軽減できる。例えば図１２に示したように、印刷操作以外の操作を省略することも可能である。また図１３に示した例でも、デフォルトのサイズ及び種類を利用可能である場合、ユーザーの選択操作を簡略化できる。また、ここでのサイズ情報及び種類情報は、サーバー１００を介して印刷装置２００から取得したメディア情報であるため、サイズや種類の設定ミスを抑制することが可能である。

なおステップＳ５０６やステップＳ６１０に示したように、サーバー１００は、第２インターフェイス１４０を用いて、印刷装置２００に印刷データを送信する。また図９のステップＳ３０１及びＳ３０２に示したように、サーバー１００は、第２インターフェイス１４０を用いて、印刷装置２００との間で、定期的にコマンド送信とメディア情報の受信を行う。第２インターフェイス１４０を用いた通信の態様にもよるが、例えばＵＳＢでは、同じ印刷装置２００を対象として、印刷データの送信とメディア情報の受信を同時に行うことはできない。そのため、印刷データのデータ量が大きい場合、印刷データの送信が継続的に行われることによって、サーバー１００による定期的なメディア情報の取得が妨げられるおそれがある。

よってサーバー１００の制御部１１０は、第１インターフェイス１３０を介して、クライアント３００から印刷データを受信する場合に、印刷データの送信よりも、メディア情報の取得を優先的に実行するように、第２インターフェイス１４０を制御してもよい。このようにすれば、印刷データの送信によってメディア情報の取得が妨げられることを抑制できる。即ち、サーバー１００は定期的にメディア情報を取得できるため、クライアント３００に適切なメディア情報を提供することが可能になる。

例えば制御部１１０は、第１インターフェイス１３０を介して、クライアント３００から印刷データを受信した場合であっても、印刷装置２００にメディア情報の取得コマンドを送信してから、メディア情報を取得するまでの期間において、印刷データを印刷装置２００に送信しない。

図１６は、メディア情報の取得タイミングと、印刷データの送信タイミングの関係を説明する図である。図１６の横軸は時間を表す。上述したように、コマンド送信及びメディア情報の取得は定期的に行われる。図１６の例では、ｔａ１のタイミングでサーバー１００はコマンドを送信し、ｔａ２のタイミングでメディア情報の取得を完了する。同様に、ｔａ３、ｔａ５がコマンドの送信タイミングを表し、ｔａ４及びｔａ６がメディア情報の取得完了タイミングを表す。ｔａ１とｔａ３の間隔、ｔａ３とｔａ５の間隔であるＴ１が数秒程度に設定される。なお、ｔａ１とｔａ２の間隔はＴ１に比べて十分短い。

サーバー１００は、例えばｔａ１～ｔａ２、ｔａ３～ｔａ４、ｔａ５～ｔａ６の期間では、印刷データの送信を行わない。例えばサーバー１００は、図１６に示したようにｔｂ１～ｔｂ２の期間や、ｔｂ３～ｔｂ４の期間に印刷データを送信する。ｔｂ１はｔａ２よりも後のタイミングであり、ｔｂ２はｔａ３よりも前のタイミングである。ｔｂ３はｔａ４よりも後のタイミングであり、ｔｂ４はｔａ５よりも前のタイミングである。

このようにすれば、コマンド送信及びメディア情報の取得が、印刷データ送信によって阻害されることを抑制できる。特に、コマンド送信タイミングがあらかじめ定期的に設定されている場合、コマンドを送信してからメディア情報を取得するまでの期間は、図１６に示すようにある程度既知となる。よって当該期間に印刷データを送信しない制御を実現することが容易である。

この際、所与のクライアント３００から取得した１つの印刷ジョブに係る印刷データは、第１～第ｎの印刷データに分割されていてもよい。ｎは２以上の整数である。ここでの印刷ジョブとは、印刷装置２００に１回の印刷動作を行わせるための情報であり、印刷実行を指示する印刷コマンドと、画像を特定する印刷データを含む。サーバー１００の制御部１１０は、第ｉの印刷データを送信した後、印刷装置２００へのメディア情報の取得コマンドの送信及びメディア情報の受信を行い、メディア情報の受信後に第ｉ＋１の印刷データを送信する。ｉは１≦ｉ＜ｎを満たす整数である。

例えば図１６において、制御部１１０は、ｔｂ１～ｔｂ２の期間において第ｉの印刷データを送信し、ｔｂ３～ｔｂ４の期間において第ｉ＋１の印刷データを送信する。このように１つの印刷ジョブの印刷データを複数回に分けて送信することによって、ある程度データ量の多い印刷データの印刷要求を受け付けた場合であっても、適切にメディア情報を取得することが可能になる。

この際、第１～第ｎの印刷データは、取得コマンドの送信間隔よりも短い期間で送信可能なデータ量に調整されている。取得コマンドの送信間隔は、例えば図１６のＴ１である。より具体的には、第１～第ｎの印刷データは、メディア情報の取得後、次の取得コマンドの送信までの期間よりも短い期間で送信可能なデータ量に調整されている。このようにすれば、ｎ個に分割された印刷データのうちの１つの印刷データの送信は、次のコマンド送信までに完了することが期待できる。そのため、印刷データの送信が、メディア情報の取得を阻害することをより抑制することが可能になる。

なお、１つの印刷ジョブに関する印刷データを第１～第ｎの印刷データに分割する処理は、例えばサーバー１００の制御部１１０が実行する。ただし当該処理は、クライアント３００において実行されてもよい。

３．変形例
以上では、図１１～図１３を用いて上述したように、クライアント３００が必要となった場合に、クライアント３００からサーバー１００にメディア情報の問い合わせが行われる例を説明した。ただし、サーバー１００からクライアント３００へメディア情報を送信する制御はこれに限定されない。

図１７は、変形例における処理を説明する図である。ステップＳ７０１～Ｓ７０４は、図９のステップＳ３０１～Ｓ３０４と同様である。具体的には、まずステップＳ７０１において、サーバー１００は、印刷装置２００にコマンドを送信する。コマンドを受信した印刷装置２００は、ステップＳ７０２において、記憶部２６０に記憶されたメディア情報を読み出し、当該メディア情報をＵＳＢを用いてサーバー１００に送信する。

ステップＳ７０３において、サーバー１００は、対象となる印刷装置２００の過去のメディア情報と、ステップＳ７０２で新たに取得したメディア情報を比較する。メディア情報が同じである場合、サーバー１００は処理を終了する。２つのメディア情報が異なる場合、ステップＳ７０４において、サーバー１００は、ステップＳ７０２で取得したメディア情報を記憶部１２０に記憶する。

次にステップＳ７０５において、サーバー１００は、クライアント３００にメディア情報の変更を通知する。具体的には、サーバー１００はネットワークＮＷへマルチキャストパケットを送信する。

ステップＳ７０６において、クライアント３００のドライバーＤｒｉは、マルチキャストパケットを受信した際に、ネットワークＮＷを介して、サーバー１００へメディア情報を問い合わせる。ステップＳ７０７において、サーバー１００は給紙装置２７０ごとのサイズ情報及び種類情報を回答する。ステップＳ７０８において、クライアント３００のドライバーＤｒｉは、サーバー１００からの回答を受信し、メディア情報を記憶部３６０に記憶する。

このようにすれば、メディア情報の更新があった場合に、サーバー１００からクライアント３００に対して問い合わせを促すことが可能になる。メディア情報が更新されなければクライアント３００から問い合わせを行う必要がないため、通信負荷を抑制することが可能になる。また、ステップＳ７０５における通知は、例えばマルチキャストパケットを用いて行われる。そのため、クライアント３００の電源が切れている場合であっても、サーバー１００の動作への影響を抑制できる。例えばサーバー１００は、クライアント３００からの応答がない場合に、タイムアウトを待つ必要がない。

ただし、電源が切れているクライアント３００は、サーバー１００が保持するメディア情報が更新されたとしても、その更新を検知できないため、サーバー１００が保持するメディア情報とクライアント３００が保持するメディア情報が乖離してしまう。よってクライアント３００は、起動時に問い合わせを行ってもよい。

図１８は、ドライバーＤｒｉの起動時の処理を説明する図である。まずステップＳ８０１において、クライアント３００においてドライバーＤｒｉが動作を開始する。ステップＳ８０２において、ドライバーＤｒｉは動作開始時に、サーバー１００へネットワークＮＷ経由でメディア情報を問い合わせる。

ステップＳ８０３において、サーバー１００は、問い合わせに対する回答としてメディア情報を返答する。クライアント３００のドライバーＤｒｉは、回答を受信し、給紙装置２７０ごとのサイズ情報及び種類情報を記憶する。このようにすれば、サーバー１００が保持するメディア情報とクライアント３００が保持するメディア情報の乖離を、動作開始時に解消することが可能になる。

また以上では、メディア情報として、サイズ情報及び種類情報を用いる例を説明した。ただしメディア情報は、所与の給紙装置２７０にメディアがセットされているか否かの情報を含んでもよい。この場合のクライアント３００は、例えば図１２のステップＳ５０２において、デフォルトに設定されている給紙装置２７０にメディアがセットされていないと判定したら、選択する給紙装置２７０を他の給紙装置２７０に変更する処理を行う。或いはクライアント３００は、図１３のＳ６０３の表示処理において、メディアがセットされていない給紙装置２７０を選択肢から除外する処理を行ってもよい。

また以上では、図６に示すようにまず印刷装置２００がメディア情報を取得し、その後、図９に示すようにサーバー１００が印刷装置２００から第２インターフェイス１４０を用いて当該メディア情報を取得する。ただし、印刷装置２００は、メディア情報を使用する所与のプロトコルに対応していない機器であることが想定される。そのため、印刷装置２００は、メディア情報を取得する機能を有さない場合がある。

よってサーバー１００は、印刷装置２００においてメディア情報をユーザーに入力させるための制御を実行してもよい。例えば、サーバー１００は、図７に示す表示画面を生成する制御、及び当該表示画面を印刷装置２００の表示部２３０に表示させる制御を行う。このようにすれば、サーバー１００を起点として印刷装置２００にメディア情報を取得させることが可能になる。

或いは、サーバー１００は、第１インターフェイス１３０と、第２インターフェイス１４０と、制御部１１０と、記憶部１２０と、不図示の表示部と操作部とを含んでもよい。例えば制御部１１０は、図７と同様の表示画面をサーバー１００の表示部に表示し、操作部は当該表示画面に基づくユーザー入力を受け付ける。制御部１１０は、印刷装置２００の給紙装置２７０に格納されているメディアのメディア情報を操作部を用いて取得し、取得したメディア情報を記憶部１２０に記憶する制御を行う。

このようにすれば、サーバー１００が印刷装置２００のメディア情報を直接取得することが可能になる。これ以降の制御は同様である。制御部１１０は、第１インターフェイス１３０を介してクライアント３００からメディア情報の取得要求を受信したとき、記憶部１２０からメディア情報を読み出し、読み出したメディア情報を、第１インターフェイス１３０を介してクライアント３００に送信する制御を行う。

以上で説明したように、本実施形態のサーバーは、クライアントと所与のプロトコルによる通信を行う第１インターフェイスと、印刷装置とＵＳＢ（Universal Serial Bus）規格による通信を行う第２インターフェイスと、第１インターフェイス及び第２インターフェイスの制御を行う制御部と、記憶部と、を含む。制御部は、第２インターフェイスを介して、印刷装置の給紙装置に格納されているメディアのメディア情報を取得し、取得したメディア情報を記憶部に記憶する制御を行う。制御部は、第１インターフェイスを介してクライアントからメディア情報の取得要求を受信したとき、記憶部からメディア情報を読み出し、読み出したメディア情報を、第１インターフェイスを介してクライアントに送信する制御を行う。

本実施形態の手法によれば、所与のプロトコルを用いてクライアントに印刷装置の機能を提供するサーバーにおいて、印刷装置のメディア情報をクライアントに送信することが可能になる。これにより、ユーザーの負担軽減や、印刷ミスの抑制が可能になる。また、所与のプロトコルがメディア情報を要求するプロトコルである場合にも、当該プロトコルに従ったサービスの提供が可能になる。

また本実施形態では、制御部は、クライアントから印刷装置の探索要求を受信したとき、ＵＳＢ接続している印刷装置に関する印刷装置情報を、第１インターフェイスを介してクライアントに送信する制御を行ってもよい。

このようにすれば、サーバーにＵＳＢ接続された印刷装置を、クライアントから適切に探索することが可能になる。

また本実施形態では、印刷装置は複数の給紙装置を含み、制御部は、第２インターフェイスを介して、複数の給紙装置の各給紙装置に格納されているメディアに関するメディア情報を取得する制御を行ってもよい。

このようにすれば、複数の給紙装置を含む印刷装置を対象とする場合にも、メディア情報を適切に取得することが可能になる。

また本実施形態では、制御部は、第１インターフェイスを介して、クライアントから印刷データを受信し、制御部は、印刷データの送信よりも、メディア情報の取得を優先的に実行するように、第２インターフェイスを制御してもよい。

このようにすれば、メディア情報の取得が、印刷データの送信によって妨げられることを抑制できる。

また本実施形態では、制御部は、第１インターフェイスを介して、クライアントから印刷データを受信した場合であっても、印刷装置にメディア情報の取得コマンドを送信してから、メディア情報を取得するまでの期間において、印刷データを印刷装置に送信しなくてもよい。

このようにすれば、メディア情報の取得が、印刷データの送信によって妨げられることを抑制できる。

また本実施形態では、制御部は、第１インターフェイスを介して、クライアントから印刷データを受信し、印刷データは、第１～第ｎ（ｎは２以上の整数）の印刷データに分割されており、制御部は、第ｉ（ｉは１≦ｉ＜ｎを満たす整数）の印刷データを送信した後、印刷装置へのメディア情報の取得コマンドの送信及びメディア情報の受信を行い、メディア情報の受信後に第ｉ＋１の印刷データを送信してもよい。

このようにすれば、メディア情報の取得が、印刷データの送信によって妨げられることを抑制できる。

また本実施形態では、第１～第ｎの印刷データは、取得コマンドの送信間隔よりも短い期間で送信可能なデータ量に調整されていてもよい。

このようにすれば、メディア情報の取得が、印刷データの送信によって妨げられることを抑制できる。

また本実施形態では、制御部は、第２インターフェイスを介してメディア情報を取得したとき、取得したメディア情報と、記憶部に記憶された過去のメディア情報との比較処理に基づいて、メディア情報のバージョン情報の管理を行ってもよい。

このようにすれば、サーバーにおいてメディア情報のバージョン管理を行うことが可能になる。

また本実施形態では、制御部は、第１インターフェイスを介してクライアントにバージョン情報を送信し、バージョン情報に基づいて、クライアントからメディア情報の取得要求を受信した場合に、メディア情報を送信してもよい。

このようにすれば、クライアントにおいて、バージョン情報を用いてメディア情報の更新の有無を判定することが可能になる。

また本実施形態の印刷システムは、印刷装置と、サーバーを含む。サーバーは、クライアントと所与のプロトコルによる通信を行う第１インターフェイスと、印刷装置とＵＳＢ（Universal Serial Bus）規格による通信を行う第２インターフェイスと、第１インターフェイス及び第２インターフェイスの制御を行う制御部と、記憶部と、を含む。制御部は、第２インターフェイスを介して印刷装置の給紙装置に格納されているメディアのメディア情報を取得し、取得したメディア情報を記憶部に記憶する制御を行う。制御部は、第１インターフェイスを介してクライアントからメディア情報の取得要求を受信したとき、記憶部からメディア情報を読み出し、読み出したメディア情報を、第１インターフェイスを介してクライアントに送信する制御を行う。

本実施形態の手法によれば、所与のプロトコルを用いてクライアントに印刷装置の機能を提供する印刷システムにおいて、印刷装置のメディア情報をクライアントに送信することが可能になる。これにより、ユーザーの負担軽減や、印刷ミスの抑制が可能になる。また、所与のプロトコルがメディア情報を要求するプロトコルである場合にも、当該プロトコルに従ったサービスの提供が可能になる。

なお、上記のように本実施形態について詳細に説明したが、本実施形態の新規事項及び効果から実体的に逸脱しない多くの変形が可能であることは当業者には容易に理解できるであろう。従って、このような変形例はすべて本開示の範囲に含まれるものとする。例えば、明細書又は図面において、少なくとも一度、より広義又は同義な異なる用語と共に記載された用語は、明細書又は図面のいかなる箇所においても、その異なる用語に置き換えることができる。また本実施形態及び変形例の全ての組み合わせも、本開示の範囲に含まれる。またサーバー、印刷装置、クライアント、印刷システム等の構成及び動作等も、本実施形態で説明したものに限定されず、種々の変形実施が可能である。

Ａｐｐ…アプリケーション、Ｄｒｉ…ドライバー、ＮＷ…ネットワーク、１０…印刷システム、１００…サーバー、１１０…制御部、１２０…記憶部、１３０…第１インターフェイス、１４０…第２インターフェイス、２００…印刷装置、２１０…処理部、２２０…通信部、２３０…表示部、２４０…操作部、２５０…印刷部、２６０…記憶部、２７０…給紙装置、２７１…センサー、３００…クライアント、３１０…処理部、３２０…無線通信部、３３０…表示部、３４０…操作部、３５０…報知部、３６０…記憶部

Claims (10)

1. クライアントと所与のプロトコルによる通信を行う第１インターフェイスと、
   少なくとも１つの給紙装置を有する印刷装置とＵＳＢ（Universal Serial Bus）規格による通信を行う第２インターフェイスと、
   前記第１インターフェイス及び前記第２インターフェイスの制御を行う制御部と、
   記憶部と、
   を含み、
   前記制御部は、
   前記第２インターフェイスを介して、前記印刷装置の前記給紙装置に格納されているメディアのメディア情報を取得し、取得した前記メディア情報を前記記憶部に記憶する制御を行い、
   前記第１インターフェイスを介して前記クライアントから前記メディア情報の取得要求を受信したとき、前記記憶部から前記メディア情報を読み出し、読み出した前記メディア情報を、前記第１インターフェイスを介して前記クライアントに送信する制御を行う、
   ことを特徴とするサーバー。
2. 請求項１において、
   前記制御部は、
   前記クライアントから前記印刷装置の探索要求を受信したとき、ＵＳＢ接続している前記印刷装置に関する印刷装置情報を、前記第１インターフェイスを介して前記クライアントに送信する制御を行うことを特徴とするサーバー。
3. 請求項１又は２において、
   前記印刷装置は、複数の前記給紙装置を含み、
   前記制御部は、
   前記第２インターフェイスを介して、複数の前記給紙装置の各給紙装置に格納されている前記メディアに関する前記メディア情報を取得する制御を行うことを特徴とするサーバー。
4. 請求項１乃至３のいずれか一項において、
   前記制御部は、
   前記第１インターフェイスを介して、前記クライアントから印刷データを受信し、
   前記制御部は、
   前記印刷データの送信よりも、前記メディア情報の取得を優先的に実行するように、前記第２インターフェイスを制御することを特徴とするサーバー。
5. 請求項１乃至３のいずれか一項において、
   前記制御部は、
   前記第１インターフェイスを介して、前記クライアントから印刷データを受信した場合であっても、
   前記印刷装置に前記メディア情報の取得コマンドを送信してから、前記メディア情報を取得するまでの期間において、前記印刷データを前記印刷装置に送信しないことを特徴とするサーバー。
6. 請求項１乃至３のいずれか一項において、
   前記制御部は、
   前記第１インターフェイスを介して、前記クライアントから印刷データを受信し、
   前記印刷データは、第１～第ｎ（ｎは２以上の整数）の印刷データに分割されており、
   前記制御部は、
   第ｉ（ｉは１≦ｉ＜ｎを満たす整数）の印刷データを送信した後、前記印刷装置への前記メディア情報の取得コマンドの送信及び前記メディア情報の受信を行い、前記メディア情報の受信後に第ｉ＋１の印刷データを送信することを特徴とするサーバー。
7. 請求項６において、
   前記第１～第ｎの印刷データは、前記取得コマンドの送信間隔よりも短い期間で送信可能なデータ量に調整されていることを特徴とするサーバー。
8. 請求項１乃至７のいずれか一項において、
   前記制御部は、
   前記第２インターフェイスを介して前記メディア情報を取得したとき、取得した前記メディア情報と、前記記憶部に記憶された過去の前記メディア情報との比較処理に基づいて、前記メディア情報のバージョン情報の管理を行うことを特徴とするサーバー。
9. 請求項８において、
   前記制御部は、
   前記第１インターフェイスを介して前記クライアントに前記バージョン情報を送信し、前記バージョン情報に基づいて、前記クライアントから前記メディア情報の取得要求を受信した場合に、前記メディア情報を送信することを特徴とするサーバー。
10. 少なくとも１つの給紙装置を有する印刷装置と、
    サーバーを含み、
    前記サーバーは、
    クライアントと所与のプロトコルによる通信を行う第１インターフェイスと、
    前記印刷装置とＵＳＢ（Universal Serial Bus）規格による通信を行う第２インターフェイスと、
    前記第１インターフェイス及び前記第２インターフェイスの制御を行う制御部と、
    記憶部と、
    を含み、
    前記制御部は、
    前記第２インターフェイスを介して前記印刷装置の前記給紙装置に格納されているメディアのメディア情報を取得し、取得した前記メディア情報を前記記憶部に記憶する制御を行い、
    前記第１インターフェイスを介して前記クライアントから前記メディア情報の取得要求を受信したとき、前記記憶部から前記メディア情報を読み出し、読み出した前記メディア情報を、前記第１インターフェイスを介して前記クライアントに送信する制御を行う、
    ことを特徴とする印刷システム。

Images