JP2007199825A - データ処理装置、出力装置、情報処理装置、ドライバ処理方法、プログラム - Google Patents

Abstract

【課題】 クライアントからデバイスに通知される利用時間に、デバイスからの応答に基づいて、そのドライバの登録あるいは削除を適時に実行することである。
【解決手段】 デバイスは、クライアントから受信した利用時間情報を含む利用設定メッセージを受信する。そしてデバイスは、受信した利用時間情報に従って、デバイスドライバをインストールさせるための情報を送信する構成を特徴とする。
【選択図】 図３

Description

本発明は、複数の出力装置と通信可能であり、各出力装置に対応するドライバをインストール可能なデータ処理装置、情報処理装置におけるドライバの設定処理に関するものである。

従来から、ネットワーク上に接続されたパーソナルコンピュータなどのクライアント装置からのサービス要求に応え、サービスを提供するサービス提供装置およびサービス提供システムが知られている。

近年はインターネットによる通信の飛躍的な普及に伴い、ネットワークでサービスを提供する機器として多種多様な機器が開発されている。

例えば、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｃｅ）や携帯電話などのポータビリティを持つデバイスがネットワークに対応しサービスを提供する機器が急激に増加している。他のデバイスとして、スキャナ・プリンタ・複写機・デジタルカメラなどの画像処理装置、テレビ・エアコン・冷蔵庫などの家電製品も同様である。

これに伴い、ネットワーク対応デバイスを利用する上での利便性・簡易性を高めるためのサービスが多数存在する。

このうちの１つにネットワークプラグアンドプレイがある。従来のプラグアンドプレイは各デバイスとホストコンピュータとなるＰＣをさまざまなローカルのＩ／Ｏポートに直接プラグで接続する。

その際に、デバイスが機種名（デバイスＩＤ）や製造者名（ベンダＩＤ）、シリアル番号などをホストの情報処理装置に送信する。

そして、情報処理装置はこれらの情報を参照して、デバイスを使用可能にするためのデバイスドライバを利用するクライアントに自動でインストールするという形態が主であった。

なお、Ｉ／Ｏポート例として、シリアル・パラレル・ＵＳＢ、ＰＣＩ、ＩＥＥＥ１３９４、ＰＣＭＣＩＡなどが含まれる。

ネットワークプラグアンドプレイ（ＮＰｎＰ）はこれをネットワークに接続したデバイス(ＮＣＤ：Ｎｅｔｗｏｒｋ Ｃｏｎｎｅｃｔｅｄ Ｄｅｖｉｃｅｓ)とホストコンピュータ同士の接続にまで拡張したものである。

例えばＭｉｃｒｏｓｏｆｔ（登録商標）社が提唱するＰｎＰ−Ｘ（Ｐｌｕｇ ａｎｄ Ｐｌａｙ Ｅｘｔｅｎｓｉｏｎｓ）の規格が現在規定されている。

この他に、（社）ビジネス機械・情報システム産業協会（ＪＢＭＩＡ）が推進するＢＭＬｉｎｋｓ、Ａｐｐｌｅ社が開発したＢｏｎｊｏｕｒなどの規格が現在規定されている。

ＰｎＰ−Ｘは、従来のＰｎＰに加え、所定のデバイス検出プロトコルであるＷＳ−Ｄｉｓｃｏｖｅｒｙに対応したデバイスが提供するサービス・情報を元に、ネットワーク上のデバイスを検知し、デバイスドライバのインストールを行える機能である。

ここで、所定のデバイス検出プロトコルであるＷＳ−Ｄｉｓｃｏｖｅｒｙとは、ＵＰｎＰ１．０（Ｕｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ）や、ＷＳＤ（Ｗｅｂ Ｓｅｒｖｉｃｅ ｆｏｒ Ｄｅｖｉｃｅｓ）が含まれる。

ＰｎＰ−Ｘ機能を持つＯＳは、さまざまなプロトコルのネットワークデバイスの検出を実現している。

具体的には、ファンクションディスカバリと呼ばれるクライアント（アプリケーション層）と、プロバイダ（プロトコル層）が組み合わさったシステムによって、さまざまなプロトコルのネットワークデバイスの検出を実現している。

ファンクションディスカバリクライアント「ＩＰバスエニュミレータ」は、ネットワークに接続したデバイスのＵＰｎＰやＷＳＤのサービスに応答するそれぞれのファンクションディスカバリプロバイダから通知を受け、発見したデバイスを列挙する。

列挙したデバイス情報（デバイスＩＤ・ベンダＩＤなど）は、「ＩＰバスエニュミレータ」から「プラグアンドプレイマネージャ」に引き渡され、対応したドライバのインストールが開始される。

また、ＰｎＰ−Ｘ機能はネットワークに接続され発見されたデバイスのドライバが、すべてインストールされることを防ぐためのシステムを持つ。

これは、「関連データベース」（Ａｓｓｏｃｉａｔｉｏｎ Ｄａｔａｂａｓｅ）ともう１つのファンクションディスカバリクライアントである「ネットワークデバイスの追加と削除」と呼ばれるコントロールパネルのユーザインタフェースにより実現される。

「ネットワークデバイスの追加と削除」はファンクションディスカバリプロバイダから情報を取得し、現在発見されているデバイスを列挙して、ユーザインタフェースによりリスト表示を行う。

ユーザは「ネットワークデバイスの追加と削除」を起動し、リスト表示されたデバイスから、「インストールを許可する」デバイスを選択し「追加」すると「関連データベース」に登録する。

「ＩＰバスエニュミレータ」は発見したネットワークデバイスのうち、「関連データベース」に登録してあるもののみ「プラグアンドプレイマネージャ」に渡す。これにより、ネットワークで発見されたすべてのデバイス向けのドライバがインストールされることを防止している。

また、前述のようなＰｎＰ−Ｘ機能によってインストールされたデバイスドライバに関連して、インストール時に利用可能時間を設定する。そして、データベースにその情報を保持しておいて、利用終了時間に達すると自動的にデバイスドライバをアンインストールするシステムなどが知られている（特許文献１参照）。
特開２００３−１３１８２７号公報

しかしながら、特許文献１に記載の技術では、インストールしてからのプリンタドライバの利用時間の指定は可能だが、ネットワーク上にプリンタを検出する度にプリンタドライバがインストールされていた。

また、ネットワークプラグアンドプレイにより自動的にドライバがインストールされる場合、ネットワークに接続されたデバイスを発見する度にドライバをインストールしてしまう。そのため、ユーザが必要としないドライバまでもインストールされることによりメモリの浪費やユーザのドライバの選択処理を困難にさせる恐れがあった。

本発明は、上記の課題を解決するためになされたもので、本発明の目的は、指定された利用時間に基づいてプリンタドライバの導入処理を制御する仕組みを提供することである。

上記目的を達成する本発明のデータ処理装置は以下に示す構成を備える。

複数の出力装置と通信可能であり、各出力装置に対応するドライバをインストール可能なデータ処理装置であって、前記出力装置を使用する利用時間情報を設定する設定手段と、前記設定手段により設定された利用時間情報を含む利用設定メッセージを送信する送信手段と、いずれかの出力装置から前記利用時間情報に従って応答される情報を受信することに応じて、前記出力装置のデバイスドライバをドライバデータベースに導入する導入手段とを有することを特徴とするデータ処理装置。

上記目的を達成する本発明の出力装置は以下に示す構成を備える。

また、ネットワークを介してデータ処理装置と通信可能な出力装置であって、
前記データ処理装置から利用時間情報が設定された利用設定メッセージを受信する受信手段と、前記出力装置が認識した時間情報と前記受信手段によって受信された利用時間情報に基づいて、前記受信手段により受信された利用設定メッセージに対する応答処理を実行するか否かを判断する判断手段と、前記判断手段により前記応答処理を実行すべきと判断された場合に、前記データ処理装置に対して前記出力装置に関する情報を含んだ応答を送信する送信手段とを有することを特徴とする出力装置。

上記目的を達成する本発明の情報処理装置は以下に示す構成を備える。

また、出力装置と、データ処理装置と通信可能な情報処理装置であって、前記出力装置を使用する各データ処理装置の利用時間情報と、データ処理装置を特定する情報とを設定する設定手段と、前記設定手段により設定された利用時間情報とデータ処理装置を特定する情報とが設定された送信情報メッセージを前記出力装置に対して送信する送信手段とを有することを特徴とする情報処理装置。

上記目的を達成する本発明の出力装置は以下に示す構成を備える。

また、情報処理装置と、複数のデータ処理装置と通信可能な出力装置であって、前記情報処理装置から利用時間情報とデータ処理装置を特定する情報が設定された送信情報メッセージを受信する受信手段と、前記出力装置が認識した時間情報と前記受信手段が受信した利用時間情報に従って、前記受信手段により受信された送信情報メッセージに対する応答処理を実行すべきか否かを判断する判断手段と、前記判断手段により前記応答処理を実行すべきと判断された場合に、前記データ処理装置を特定する情報に基づいて特定されたデータ処理装置に対して、応答送信する送信手段とを有することを特徴とする出力装置。

本発明によれば、指定された利用時間に基づいて、ドライバの導入処理を制御するため、メモリの浪費やユーザのドライバの選択処理を困難にさせる恐れを回避できる。

次に本発明を実施するための最良の形態について図面を参照して説明する。

＜システム構成の説明＞
〔第１実施形態〕
以下、図面を参照して本発明の実施の形態を説明する。

図１は、本発明の第１実施形態を示すネットワークシステムのブロック構成図である。本システムは、一般的なコンピュータを用いたデータ処理装置（クライアント装置ともいう）、デバイス（出力装置ともいう）、サーバ装置（情報処理装置ともいう）を含むネットワークシステムの例である。

また、デバイスは、本実施形態では、プリンタ装置の例を示すが、プリンタ装置に限らず、ネットワークデバイスで、ネットワークプラグアンドプレイに対応したデバイスであれば、本発明を適用可能である。以下、デバイスとして、プリンタ装置の例を説明する。したがって、以下、デバイスドライバは、プリンタドライバの例を示す。

なお、特に断らない限り、本発明の機能が実行されるのであれば、単体の機能であっても、複数の機器からなるシステムであってもよい。また、ＬＡＮ、ＷＡＮ等のネットワークを介して接続がなされ処理が行われるシステムであっても、本発明を適用できることは言うまでもない。

図１において、ＣＰＵ１０１は、ＲＯＭ１０２あるいはＲＡＭ１０３あるいは外部記憶装置１０５に格納されたプログラムに従って装置全体の制御を行う。ＲＡＭ１０３はＣＰＵ１０１が各種処理を行う際のワークエリアとしても使用される。

外部記憶装置１０５は、オペレーティングシステム（ＯＳ）１０５４やアプリケーションソフト１０５１、印刷関連プログラム１０５２、プリンタドライバ１０５３等を記録する。

キーボード１０８やマウスなどポインティングデバイス１０９の入力機器は、入力Ｉ／Ｆ１０４を通じて、ユーザがコンピュータに対して各種指示を与えるためのデバイスである。

出力Ｉ／Ｆ１０６は、データを外部に出力するためのインタフェースであり、モニタ１１０やプリンタ１１１に対してデータを出力する。プリンタ１１１とは、ローカルＩ／Ｏのみならず、ネットワークを通して接続されていてもよい。

また、１０７はシステムバスで、それぞれのデータのやりとりを行う。

図２は、図１に示したネットワークシステムのネットワーク環境を説明する図である。

図２において、プリンタ２０２、プリンタ２０３、プリンタ２０５がそれぞれイーサネット（登録商標）ネットワークにつながったネットワークプリンタを示している。この例では、クライアント２０１、サーバ２０４もそれぞれネットワークに接続して、ネットワークを通じてクライアント２０１もしくはサーバ２０４から印刷が可能な環境を構築している。

なお、クライアント２０１、サーバ２０４は、図１に示したハードウエア資源を備えて、所定のＯＳの管理下でアプリケーションプログラム、プリンタドライバ等を実行して印刷情報を生成する。そして、プリンタドライバが生成した印刷情報をプリンタ２０２〜２０５のいずれかに出力可能に構成されている。

プリンタ２０３は、ここではオフラインであり、物理的には接続されていても実際には使用できない状態であるが、このようなプリンタがネットワークＮＥＴ上に存在してもかまわない。

本実施形態においては、図２のようなネットワークでプリンタが利用できる環境であるものとする。

図３は、本実施形態におけるデータ処理装置上のネットワークプラグアンドプレイ（ＮＰｎＰ）のモジュール構成を説明するブロック図である。以下、図３の下位層から順にＮＰｎＰがどのように動作しているかを説明する。（１）〜（９）は各手順を示す。

図３において、まず、図２に示したように、ネットワークＮＥＴに接続されたプリンタ３０１が存在する。

このプリンタ３０１は通信機能として、イーサネット（登録商標）コントローラを内蔵しイーサネット（登録商標）に対応しており、ＴＣＰ／ＩＰネットワーク上でＨＴＴＰリクエストに動作できるようにプロトコルスタックやＨＴＴＰレイヤも実装されている。

ここではイーサネット（登録商標）コントローラとしたが、シリアル・パラレル・ＵＳＢといったシリアルＩ／Ｏ、Ｗｉ−Ｆｉ（ＩＥＥＥ８０２．１１ａ／ｂ／ｇ）やＢｌｕｅｔｏｏｔｈ、ＵＷＢといった無線通信でもかまわない。

また、プリンタ３０１が持つ通信機能の上位のレイヤには、タグを用いたマークアップ言語ＸＭＬベースのプロトコル「ＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）」を解釈可能なシステムを搭載している。

ＳＯＡＰは通信内容にＸＭＬを用い、言語やプラットフォームに依存することなくデータを通信することができるプロトコルである。

このＳＯＡＰをベースにして、プリンタ３０１は、ＷＳＤ（Ｗｅｂ Ｓｅｒｖｉｃｅｓ ｆｏｒ Ｄｅｖｉｃｅｓ）システムも搭載している。

ＷＳＤシステムは、プリンタ３０１がＷｅｂサービスを提供するために存在している。ここではネットワークＮＥＴに接続している各クライアントＰＣがデバイスの情報を返すアプリケーションプロトコルのＤＰＷＳ（Ｄｅｖｉｃｅ Ｐｒｏｆｉｌｅ ｆｏｒ Ｗｅｂ Ｓｅｒｖｉｃｅｓ）によって応答する。

このため、デバイスのＷｅｂサービスを探索するときに使用するＷＳ−Ｄｉｓｃｏｖｅｒｙと、デバイス情報を入れるデータフォーマットのＷＳ−ＭｅｔａｄａｔａＥｘｃｈａｎｇｅの２つをサポートする。

ここで、ＷＳ−Ｄｉｓｃｏｖｅｒｙとは、Ｗｅｂ Ｓｅｒｖｉｃｅｓ Ｄｙｎａｍｉｃ Ｄｉｓｃｏｖｅｒｙを意味する。

また、プリンタ３０１はＷＳＤサービスを搭載しているが、これは、ＳＳＤＰとＳＳＤＰ Ｄｉｓｃｏｖｅｒｙ Ｍｅｔａｄａｔａ ＭａｐｐｉｎｇをサポートしているＵＰｎＰサービスや、他のプロトコルであってもよい。ここで、ＳＳＤＰとは、Ｓｉｍｐｌｅ Ｓｅｒｖｉｃｅ Ｄｉｓｃｏｖｅｒｙ Ｐｒｏｔｏｃｏｌを意味する。

図３に示すプラグアンドプレイのＰｎＰ（１）を説明する前に、ＤＰＷＳの動作について図４を参照して説明する。

図４は、本実施形態におけるデータ処理装置とネットワークデバイスとの第１の通信例を説明する図である。なお、（５０１）〜（５０６）は通信手順を示す。

図４において、イーサネット（登録商標）に接続されたプリンタ３０１（ここではデバイス４００となる）が、ネットワークに接続された段階で接続通知（Ｈｅｌｌｏ）メッセージ（図５参照）をマルチキャストでネットワークに送信する（５０１）。

図５は、本実施形態における印刷装置からネットワーク上にマルチキャストされる情報を説明する図である。本例は、Ｈｅｌｌｏメッセージの例である。

ここで、マルチキャストは、複数の相手に対して同じデータを送信する手法でである。具体的に、ＷＳ−Ｄｉｓｃｏｖｅｒｙでは特定のポート（ディスカバリポート３７０２番ポート）に、特定のＩＰアドレス（ＩＰＶ４では「２３９．２５５．２５５．２５０」、ＩＰＶ６ではＦＦ０２：：Ｃ）へ送信を行うように規定されている。

ネットワークＮＥＴに接続されているＮＰｎＰ対応のホストコンピュータ（ここではクライアント２０１となる）が、Ｈｅｌｌｏメッセージを受ける。

具体的には、クライアント２０１が、ＯＳが持つＴＣＰ／ＩＰプロトコルスタック、ＨＴＴＰドライバを経由して、ＷＳＤサービス、例えばネットワーク上のデバイス検出を司るファンクションディスカバリプロバイダがＨｅｌｌｏメッセージを受ける。

図５に示すＨｅｌｌｏメッセージサンプル例では、デバイス４００のネットワークＮＥＴ上での位置を一意に定めるためのエンドポイントリファレンスとしてのｕｕｉｄが記載されている。

さらに、デバイス４００の機能情報を記述するメタデータのフォーマットバージョンが記載されている。しかし、上記以外に他にもタイプやスコープなども記述することもできる。

すでにネットワーク上に存在するＷＳＤ対応デバイスを探索する場合は、一定のタイミングでクライアント２０１がデバイス探索のためのＰｒｏｂｅメッセージ（図６参照）をマルチキャストでネットワークに通知する（５０２）。なお、上記タイミングの例として、クライアント２０１の起動時、ユーザが探索を命じたとき、一定間隔のポーリングなどが挙げられる。

図６は、本実施形態におけるデータ処理装置からネットワーク上にマルチキャストされる情報を説明する図である。

図６のＰｒｏｂｅメッセージサンプルでは、「ｉ：ＰｒｉｎｔＢａｓｉｃ」というデバイス特有の機能をタイプとして、またＬＤＡＰプロトコルメッセージをスコープとして追加して、この機能を元に返答するように要求している。

また、ＳＯＡＰヘッダに自分自身のアドレスＲｅｐｌｙＴｏを記述することによって、デバイス４００からクライアント２０１に直接メッセージを送信するように指示している。

クライアント２０１からＰｒｏｂｅを検知したデバイス４００は、Ｐｒｏｂｅメッセージに含まれる情報に基づいて、応答すべきか否かを判定する。例えば、図６のＰｒｏｂｅメッセージには「ｉ：ＰｒｉｎｔＢａｓｉｃ」としていされているので、この情報を元に自らのデバイスが該当するか否かを判定する。

ここで、デバイス４００がＰｒｏｂｅメッセージに含まれる情報に該当すると判定した場合、応答のメッセージとしてＰｒｏｂｅＭａｔｃｈメッセージ（図７参照）をユニキャストでクライアントに直接送信する（５０３）。そして、クライアント２０１内のファンクションディスカバリプロバイダがこれを受ける。

なお、本実施形態において、ユニキャストはネットワーク上において１対１でデータをやりとりする方法である。

図７は、本実施形態における印刷装置からネットワーク上にマルチキャストされる情報を説明する図である。

図７に示すのＰｒｏｂｅＭａｔｃｈメッセージサンプルでは、図５に示したＨｅｌｌｏメッセージと同等の情報のほかに、「ｉ：ＰｒｉｎｔＡｄｖａｎｃｅｄ」タイプの情報も加えて、ＲｅｐｌｙＴｏのアドレスに応答している。

この後、必要に応じてファンクションディスカバリプロバイダはＧｅｔＭｅｔａｄａｔａメッセージ（図８参照）をユニキャストでデバイス４００に送信する（５０４）。

図８は、本実施形態におけるデータ処理装置からネットワーク上にユニキャストされる情報を説明する図である。

一方、デバイス４００はＷＳ−ＭｅｔａｄａｔａＥｘｃｈａｎｇｅのプロトコルに従って自身のデバイス情報が入ったメタデータを含むＧｅｔＭｅｔａｄａｔａ Ｒｅｓｐｏｎｓｅメッセージ（図９参照）を返す（５０５）。

図９は、本実施形態における印刷装置から通知される情報を説明する図である。

図９に示すメッセージであるメタデータにはデバイスＩＤやモデル名、製造会社名、デバイスのＵＲＬアドレス、ＰＤＬ情報などのデータが含まれる。

図９に示すＧｅｔＭｅｔａｄａｔａ Ｒｅｓｐｏｎｓｅメッセージサンプルでは、このうち製造会社名とモデル名が記載されている。

最後にデバイス４００の電源が切れるなどネットワークから切断されることがデバイス自身でわかる場合は、Ｂｙｅメッセージ（図１０参照）をマルチキャストで送信して（５０６）、ネットワーク全体に自身がいなくなることを通知する。このようにＤＰＷＳは動作している。

なお、Ｂｙｅメッセージは、ネットワークからの離脱を意味するメッセージでもあるため、離脱メッセージと記載する場合もある。

図１０は、本実施形態における印刷装置からネットワーク上にマルチキャストされる情報を説明する図である。

ここではＷＳＤサービスを持ったデバイスの応答を記述したため、ファンクションディスカバリプロバイダ３０２のうちＷＳ−Ｄｉｓｃｏｖｅｒｙプロバイダ３０２１がクライアント側の窓口となり応答を行う。

なお、ＵＰｎＰサービスを持ったデバイスの場合は、ＳＳＤＰプロバイダ３０２２が各メッセージを受ける。また、ファンクションディスカバリプロバイダ３０２はプロトコルごとにプロバイダを持つことができるため、他のプロトコルであれば他のプロバイダが送受信の処理を行うことも自明である。

さて、前述のＤＰＷＳの動作を踏まえて、図３に示したプラグアンドプレイを説明する。

図３において、デバイス（図３に示す例では、プリンタ３０１）はＨｅｌｌｏメッセージもしくはＰｒｏｂｅＭａｔｃｈメッセージによって、ネットワークＮＥＴにＷＳ−Ｄｉｓｃｏｖｅｒｙのサービスを持つことを通知する（１）。

これにＷＳＤサービスを利用クライアントであるホストコンピュータにおいて、ファンクションディスカバリプロバイダ３０２のＷＳ−Ｄｉｓｃｏｖｅｒｙプロバイダ３０２１が応答する（２）。ここで、ホストコンピュータは、クライアント２０１に対応する。

そして、ファンクションディスカバリプロバイダ３０２のＷＳ−Ｄｉｓｃｏｖｅｒｙプロバイダ３０２１はデバイスを検出したら、ファンクションディスカバリクライアント３０３に通知を行う（３）。

ファンクションディスカバリクライアント３０３は検出したデバイスを列挙し、上位のプラグアンドプレイマネージャ３０４にデバイスの情報とともに通知する（４）。ファンクションディスカバリの詳細な動作については、後述する。

次に、プラグアンドプレイマネージャ３０４はファンクションディスカバリクライアント３０３からデバイスの情報を取得する。そして、検出したデバイスリストを元に通常はクラスインストーラ３０６を呼び出す（７）。クラスインストーラ３０６によってデバイスを利用するために必要なデバイスドライバのインストールを行う。

クラスインストーラ３０６はデバイスの種類（クラス）を判定し、そのデバイスのインストールを行うためにドライバデータベース３０７にアクセスする。

しかし、ここではデバイスの種類がプリンタ３０１であるのでクラスインストーラ３０６を呼び出す前に、プラグアンドプレイマネージャは、スプーラ３０５にプリンタドライバがプリンタ３０１に出力するためのプリンタポートを作成するよう通知する（５）。スプーラ３０５は、プリンタドライバがプリンタ３０１に出力するためのプリンタポートを作成する。

プリンタ３０１は、ＷＳ−Ｄｉｓｃｏｖｅｒｙプロバイダ３０２１によって検出されているため、ネットワークデバイス用のポートモニタであるＮＣＤポートモニタ３０５１とプリンタポートを関連づけて、プラグアンドプレイマネージャ３０４に返す（６）。その後、クラスインストーラ３０６を呼び出す。

クラスインストーラ３０６はホストコンピュータのドライバデータベース３０７のドライバインストール情報を持つインストールインフォメーションファイル（ＩＮＦファイル）に記述されたハードウエアＩＤが一致するＩＮＦファイル検索する。

なお、ＩＮＦファイルとはデバイスドライバをインストールすると共にホストコンピュータの記憶部に記憶されるファイルである。ＩＮＦファイルは、デバイスドライバをインストールすると識別情報を含んだファイル名と拡張子「.ＩＮＦ」という形式にて保持される。例えば、最初にインストールされたデバイスドライバのＩＮＦファイルは「ＯＥＭ１.ＩＮＦ」という形式にて保存される。

そして、次にインストールされたデバイスドライバのＩＮＦファイルは「ＯＥＭ２．ＩＮＦ」という形式にて保存される。そして、このＩＮＦファイルには、デバイスドライバの機能情報（例えばページ記述言語：ＰＤＬともいう）等が含まれる。

よって、このＩＮＦファイルを解析することでデバイスドライバの特徴を認識することが可能となる。また、このＩＮＦファイルは、デバイスドライバをアンインストールしても、該デバイスドライバと対応するＩＮＦファイルはそのままホストコンピュータの記憶部に残る。

ここで、ハードウエアＩＤとは、デバイスから取得したデバイスＩＤなどの情報を元にして、各カテゴリ（ＰＣＩ、ＵＳＢ、ＩＰバスなど）のエニュミレータが作成するＩＤである。

そして、クラスインストーラ３０６は一致したＩＮＦファイルをみつけた場合は、ＩＮＦファイルに記述されたドライバをドライバデータベース３０７にインストールする（８）。ここで、ドライバ３０８は、記憶媒体（フレキシブルディスク、ＣＤ−ＲＯＭ、ハードディスク）に記憶されている例である。

一方、クラスインストーラ３０６は一致したＩＮＦファイルを見つかられなかった場合は、「ハードウエアの追加ウィザード」のユーザインタフェースをクライアントの表示装置に表示する。そして、ユーザがドライバ３０８を選択して、その格納先からドライバを読み出して、ドライバデータベース３０７にインストールする（９）。

以上の動作によりオペレーティングシステム（ＯＳ）においてネットワークプラグアンドプレイが実現されている。

次に、図１１のファンクションディスカバリについて説明する。

図１１は、図３に示したファンクションディスカバリクライアント４０１とファンクションディスカバリプロバイダ４０２の詳細を説明するブロック図である。

本例では、ファンクションディスカバリは大きく分けてファンクションディスカバリクライアント（ＦＤＣ）４０１とファンクションディスカバリプロバイダ（ＦＤＰ）４０２の２つに分けられる。

図１１において、両者は共通のインタフェースであるファンクションディスカバリＡＰＩ４０４でデータのやりとりが行われる。

ＦＤＣ４０１は、ＦＤＰ４０２からの通知により、ファンクションディスカバリカテゴリ４０３の情報を元に動作を行う。本実施形態ではＦＤＣ４０１には、ＯＳが一般的には標準で持つネットワークデバイスの追加と削除４０１１と、ＩＰバスエニュミレータ４０１２に加える。そして、デバイスの利用時間を指定することができる図１２に示すユーザインタフェースを持つ利用時間設定クライアント４０１３が存在する。

ＦＤＰ４０２によって通知されたデバイスは、ファンクションディスカバリカテゴリ４０３の検出デバイスリスト４０３１に保存され列挙される。

ユーザは、例えばＯＳが提供するコントロールパネルからネットワークデバイスの追加と削除４０１１を選択し、図１３に示すユーザインタフェースをファンクションディスカバリカテゴリ４０３が起動する。

これにより、ネットワークデバイスの追加と削除４０１１は検出デバイスリスト４０３１の情報を元に図１３に示したユーザインタフェースのデバイスリストビューに列挙を行う。

図１３は、本実施形態のデータ処理装置で検索されたネットワークデバイスの追加／削除設定のためのユーザインタフェースの一例を示す図である。

図１３に示すユーザインタフェース上に列挙されたデバイスは現在ネットワーク上で発見されたデバイスを示しており、ユーザは使用したいデバイスを選択し、追加ボタン１３−１を押す。

そして、この押下指示に基づいて追加されたデバイスはファンクションディスカバリカテゴリ４０３の関連データベース４０３２にＦＤＰがＧｅｔＭｅｔａｄａｔａ Ｒｅｓｐｏｎｓｅメッセージにより受信したメタデータのデバイス情報とともに追加する。

一方、図１３に示すユーザインタフェース上で、削除ボタン１３−２を押すと、選択されたデバイスが関連データベース４０３２から削除する。

ここでは、あくまで関連データベース４０３２から削除するのみなので、ユーザインタフェース上にはまだ発見されたデバイスとしては列挙され表示されている。

図１３に示すユーザインタフェース上で更新リストボタン１３−３を押すとファンクションディスカバリプロバイダ４０２のＷＳ−Ｄｉｓｃｏｖｅｒｙプロバイダ４０２１に通知を行う。そして、再度Ｐｒｏｂｅメッセージをネットワーク上に投げてデバイスの探索を行う。

ＩＰバスエニュミレータ４０１２は、ファンクションディスカバリカテゴリ４０３の関連データベース４０３２の情報を元にデバイスを列挙して、図３に示した上位のプラグアンドプレイマネージャ３０４に通知する。

したがって、ネットワークＮＥＴで検出した全てのデバイスではなく、ネットワークデバイスの追加と削除４０１１でユーザが指定したデバイス、すなわち関連データベース４０３２にあるデバイスのみ、ＮＰｎＰを有効にするように動作している。ここで、ＮＰｎＰとは、ネットワークプラグアンドプレイを意味する。

次に、本実施形態の中心となる図１２に示すユーザインタフェースを持つ利用時間設定クライアント４０１３を含む動作を、図１１に示したファンクションディスカバリと、図１４のシーケンス例を参照して説明する。

ユーザは、クライアントで所定の操作を行うことにより利用時間設定のユーザインタフェース（図１２）を起動する。

図１２は、本実施形態のデータ処理装置で表示可能な利用時間設定のユーザインタフェースの一例を示す図である。本ユーザインタフェースは、利用時間設定クライアント４０１３によりクライアントの表示装置に表示される。

図１４は、本実施形態におけるデータ処理装置とネットワークデバイスとの第２の通信シーケンス例を説明する図である。

図１４において、図１２に示す利用時間設定のユーザインタフェースは、まず「利用可能」時間の設定か、「利用不可」時間の設定かのどちらかをラジオボタンＢ１２−１、Ｂ１２−２により選択する。そして、開始時間ＳＴＴ１、ＳＴＴ２と終了時間ＥＤＴ１、ＥＤＴ２を設定する（６０１）。

ユーザが利用時間を設定して図１２に示したユーザインタフェースを閉じると、デバイス探索を行うために図１２において設定された利用時間情報を含めたＰｒｏｂｅメッセージをデバイス４００に通知する。

これは図１５に示すようにＰｒｏｂｅメッセージのタイプ（ｗｓｄ：Ｔｙｐｅｓ）としてｉ：ＰｒｉｎｔＡｖａｉｌａｂｌｅＴｉｍｅを記述する。そして、スコープ（ｗｓｄ：Ｓｃｏｐｅｓ）に利用可能時間をディレクトリサービスにアクセスするためのプロトコルであるＬＤＡＰ（Ｌｉｇｈｔｗｅｉｇｈｔ Ｄｉｒｅｃｔｏｒｙ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）で記述することで実現する。

図１５は、図１４に示したクライアント２０１からデバイス４００にマルチキャストで通知されるＰｒｏｂｅメッセージの一例を示す図である。

このように記述した図１５に示したＰｒｏｂｅメッセージをマルチキャストでデバイス４００に対して送信し、デバイス４００はＰｒｏｂｅメッセージを受信することでメッセージを出したクライアント２０１のデバイス利用可能時間情報を取得する（６０２）。

なお、以後においてＰｒｏｂｅメッセージは、利用設定メッセージとも記載する場合もあるが同義である。

まだ、ネットワークＮＥＴに接続していないデバイスの場合は、ネットワークＮＥＴに接続した時点で、ＨｅｌｌｏメッセージをマルチキャストでネットワークＮＥＴに送信し、ネットワークに接続した旨を通知する（６０３）。

クライアント２０１はそのＨｅｌｌｏメッセージに応答する。しかし、ＦＤＰ４０２は、Ｈｅｌｌｏメッセージの送信元のデバイス情報をファンクションディスカバリカテゴリ４０３の検出デバイスリスト４０３１には列挙せず、Ｈｅｌｌｏメッセージに応答する。

この際、クライアント２０１は、Ｐｒｏｂｅメッセージに図１２にて設定した利用可能時間情報を加えたＰｒｏｂｅメッセージをてマルチキャストで送信する（６０４）。なお、Ｐｒｏｂｅメッセージ（利用設定メッセージ）に含まれる利用時間情報には、少なくとも利用開始時刻情報が含まれていれば良い。

また、Ｐｒｏｂｅメッセージに含まれる利用時間情報には、デバイスドライバの利用開始時刻情報およびデバイスドライバの利用終了時刻情報を含むことで、図１４にて後述するアンインストール処理（６１４）を行うことも可能である。

こうしてクライアント２０１からＰｒｏｂｅメッセージによって利用可能時間情報を受け取ったデバイス４００は、以下のよう動作が制限される。つまり、通常Ｐｒｏｂｅメッセージには、ＷＳ−Ｄｉｓｃｏｖｅｒｙの仕様にあるように５００mm秒以内に応答のＰｒｏｂｅＭａｔｃｈメッセージを返さなければ無効となる。

しかしながら、デバイス４００は、クライアント２０１から受信したＰｒｏｂｅメッセージ情報に利用時間情報が含まれていた場合、利用可能時間になるまではＰｒｏｂｅＭａｔｃｈメッセージを返さない。そして、クライアント２０１はＬｉｓｔｅｎ状態で待ち続ける（図１４の（６０５）に波線でその状態を示す）。

そして、デバイス４００は内蔵している時計もしくは図示しないタイムサービスを提供するＮＴＰサーバなどに問い合わせて現在の時間と利用可能時間を比較し、利用開始時間になったかどうかを判断する。

そして、デバイス４００が利用開始時間になったと判断した場合は、ＰｒｏｂｅＭａｔｃｈメッセージを、Ｐｒｏｂｅを送ってきた図１４に示すクライアント２０１に返す（６０５）。

クライアント２０１は、ＰｒｏｂｅＭａｔｃｈがデバイス４００から返ってきたことで、デバイス４００がネットワークＮＥＴ上に発見されたと認識し、ファンクションディスカバリカテゴリの検出デバイスリスト４０３１に列挙する。

そして、ネットワークＮＥＴ上にて発見したデバイス４００に関する情報を検出デバイスリスト４０３１に通知する。その結果、関連データベース４０３２にデバイス４００に関する情報が追加され、プラグアンドプレイでデバイスドライバをインストールすることができる（６０６）。

なお、デバイスドライバのドライバ情報は、クライアント装置の記憶手段に保持されていても、ネットワークを介して取得しても良い。

本実施形態では、上述したようにＰｒｏｂｅＭａｔｃｈメッセージを返すタイミングをデバイス４００側で制御することで、利用可能時間になったら、デバイスドライバが自動でインストールされる。これにより、ユーザはネットワークのデバイスを利用可能な状態に遷移させることができる。

一方、電源断を行うなどデバイス４００がネットワークＮＥＴから切断されるときには、ネットワークＮＥＴにＢｙｅメッセージを送信する（６０７）。

クライアント２０１はＢｙｅメッセージをデバイス４００から受信したら、ネットワークＮＥＴからデバイス４００が切断されたことを知り、該当するデバイスのドライバをアンインストールする（６０８）。

これはＦＤＰ４０２のＷＳ−Ｄｉｓｃｏｖｅｒｙプロバイダ４０２１がＦＤＣ４０１の利用時間設定クライアント４０１３に通知を行う。そして、利用時間設定クライアント４０１３がＯＳのＡＰＩのＤｅｌｅｔｅＰｒｉｎｔｅｒ（）をコールして関連データベース４０３２に登録されていたドライバから、Ｂｙｅメッセージを送信したデバイスに対応するドライバを削除する。

もし、利用時間内にデバイス４００が再びネットワークＮＥＴに接続された場合は、通常と同様にデバイス４００がＨｅｌｌｏメッセージをマルチキャストで送信する（６０９）。そして、クライアント２０１のＦＤＰ４０２が列挙せずにＰｒｏｂｅに利用時間を入れて返す（６１０）。

ここで、デバイス４００はすでに利用時間内であることを判断してからＰｒｏｂｅＭａｔｃｈメッセージをクライアント２０１に向けて送信する(６１１)。これにより、クライアント２０１はデバイス４００を検出デバイスリストに入れ、ドライバをインストールする（６１２）。この結果として、利用時間内であればユーザはすぐにネットワークＮＥＴに接続されたデバイス４００を利用できるようになる。

そして、設定された利用終了時間になったら、デバイス４００はネットワークＮＥＴから実際に切断されていないにもかかわらず、Ｂｙｅメッセージを強制的にクライアント２０１に送信する（６１３）。

クライアント２０１は、デバイス４００から送信されたＢｙｅメッセージに応答してＦＤＣ４０１の利用時間設定クライアント４０１３がファンクションディスカバリカテゴリ４０３の検出デバイスリスト４０３１から削除する。

そして、デバイス４００に対するドライバを自動的にアンインストールする（６１４）。

つまり、クライアント２０１は、インストールしたデバイスドライバのデバイスから利用終了時刻情報に従って送信される離脱メッセージ（Ｂｙｅメッセージ）情報を受信することに応じて、ドライバデータベースに登録されたデバイスドライバを削除する。

なお、ドライバデータベースは、オペレーティングシステムのシステム管理ファイルに含まれる。

本実施形態によれば、デバイス４００があたかも利用時間内のみネットワークで見つかるように動作するため、ＯＳが持つネットワークプラグアンドプレイの機能を不必要に妨げることがなくなる。

このように、クライアント２０１側で、デバイスの利用時間設定によって、ネットワークＮＥＴに接続されているデバイスのドライバを自動的にインストール並びにアンインストールすることができる。

なお、図１２に示した利用時間設定クライアント４０１３のユーザインタフェースで利用不可能時間をラジオボタンＢ１２−２を押下して設定した場合は、前述のシーケンスにおいてデバイス４００が逆に動作する。

つまりデバイス４００は、ＰｒｏｂｅＭａｔｃｈメッセージを利用不可能時間には返さない。また、利用不可能時間になった場合、デバイス４００は、Ｂｙｅメッセージを送信する。その結果、クライアントは記憶装置上からデバイス４００のドライバを自動的にアンインストールする。

本実施形態におけるデータ処理装置、デバイスの機能処理についてさらに説明する。

ネットワークＮＥＴ上の複数のデバイス（デバイス４００を含む）と通信して各デバイスに対応するドライバをインストール可能なクライアント２０１は、以下の手段または機能を備える。

各デバイスに対応するデバイスドライバを記憶するドライバ記憶手段に対応するドライバデータベース３０７を備える。

また、デバイスを使用する利用時間を図１２に示すＵＩ画面を介してモニタ１１０に表示してユーザが設定する機能（図１１に示す利用時間設定クライアント４０１）を備える。

そして、設定された利用時間情報を含むメッセージ（Ｐｒｏｂｅメッセージ）をネットワーク上にファンクションディスカバリプロバイダ３０２を介して送信する機能を備える。

そして、ネットワークＮＥＴ上のいずれかのデバイスから利用時間内に応答される情報を受信する。そして、プラグアンドプレイマネージャ３０４を介して探索されたデバイスのデバイスドライバをドライバデータベース３０７に登録するデバイスドライバ管理機能を備える。デバイスドライバ管理機能は、後述する図１４に示すシーケンス手順あるいは、図１７に示すフローチャートの手順に従う。

また、上記デバイスドライバ管理機能は、いずれかのデバイスから利用時間外に応答される情報、例えばＢｙｅメッセージをデバイス４００から受信して、ドライバデータベース３０７に登録されたデバイスドライバを削除する。

さらに、ドライバデータベース３０７は、オペレーティングシステム１０５４のシステム管理ファイルに含まれる。なお、ＯＳがWindows（登録商標）の場合には、レジストリ上でプリンタデータベースとして登録される。

また、利用時間外に応答される情報は、デバイスからの離脱メッセージ（Ｂｙｅメッセージ）である。

一方、ネットワークを介してクライアント２０１と通信して特定の処理を行うデバイス４００は、以下の構成を備える。

クライアント２０１から利用時間が設定されたメッセージを受信する受信機能を備える。本実施形態では、利用時間情報はプローブメッセージに含まれる。

また、現在時間がプローブメッセージから取得した利用時間かどうかを判断する判断機能を有する。なお、時刻情報は、上述しているように内蔵時計あるいは、タイムサーバ等から取得可能としている。

そして、判断機能により現在時間が利用時間であると判断した場合に、メッセージ、本実施形態では、プローブＭａｔｃｈメッセージをクライアント２０１に送信する。

以下、図１７、図１８に示すフローチャートを参照して、クライアント側とデバイス側のドライバ処理方法について説明する。

図１７は、本実施形態におけるデータ処理装置における第１のドライバ処理手順の一例を示すフローチャートである。本処理は、デバイス４００に利用時間情報を送信した後、その利用時間内にデバイス４００からプローブＭａｔｃｈを受信してデバイスドライバをインストールするとともに、Ｂｙｅメッセージを受信してドライバを削除する処理である。

また、Ｓ１〜Ｓ１１は各ステップを示す。各ステップは、図１に示したＯＳ１０５４がＲＡＭ１０３にロードされた後、システム処理としてＣＰＵ１０１が実行することで実現される。

なお、本願のデータ処理装置は、複数の出力装置と通信可能であり、各デバイスに対応するドライバをインストールすることができる。

まず、ステップＳ１で、クライアント２０１は、図１２に示すＵＩ画面をモニタ１１０に表示する。そして、クライアント２０１は、ポインティングデバイス１０９等を操作して入力されたデバイスを使用する利用時間情報を設定する。なお、Ｓ１で設定された情報は、クライアント２０１のＲＡＭ等に保持される。

次に、ステップＳ２で、クライアント２０１は、Ｓ１にて設定された利用時間情報とクライアントＩＤ等を含む利用設定メッセージ（Ｐｒｏｂｅメッセージ）をネットワークＮＥＴ上にマルチキャストで送信する。

次に、ステップＳ３で、ネットワークＮＥＴ上のいずれかのデバイス（例えばデバイス４００）からプローブＭａｔｃｈメッセージを受信するまで待機する。なお、クライアント２０１は、この時、現在時刻が先のステップＳ２で送信した利用時間内にならない間は、ＦＤＣ４０１からプローブＭａｔｃｈメッセージを受信していない。

次に、クライアント２０１が、デバイス４００からプローブＭａｔｃｈメッセージを受信したら、ステップＳ５で、デバイス４００がネットワークＮＥＴ上に発見されたと認識し、ファンクションディスカバリカテゴリの検出デバイスリスト４０３１に列挙する。つまり、Ｓ５において認識したデバイス４００に関する情報を検出デバイスリスト４０３１に登録する。

そして、ネットワークＮＥＴ上に発見されたデバイスに関する情報を検出デバイスリスト４０３１に登録する。

この登録処理により、クライアント２０１は、関連データベース４０３２にデバイス４００に関する情報を追加し、クラスインストーラ３０６がプラグアンドプレイでデバイス４００のデバイスドライバをインストールする。

つまり、クライアント２０１は、いずれかのデバイスから利用時間情報に従って応答される情報を受信することに応じて、デバイスのデバイスドライバをドライバデータベースにインストールする。

そして、ステップＳ６で、ファンクションディスカバリプロバイダ３０２は、ネットワークＮＥＴを介してＢｙｅメッセージが受信されたか否かを判断する。そして、Ｂｙｅメッセージを受信したら、クライアント２０１は、Ｂｙｅメッセージを受信した時間が利用時間の外であるかを判断する。

ここで、利用時間外であると判断した場合は、ステップＳ１１に進み、クネットワークＮＥＴからデバイス４００が切断されたことになるので、クライアント２０１から該当するデバイスのドライバをアンインストールして、処理を終了する。

一方、ステップＳ７で、利用時間内であると判断した場合は、ステップＳ８へ進み、Ｂｙｅメッセージを送信したデバイスのデバイスドライバを削除する。

ステップＳ９で、ファンクションディスカバリプロバイダ３０２がＨｅｌｌｏメッセージを受信しているかどうかを判断する。

ここで、ファンクションディスカバリプロバイダ３０２がＨｅｌｌｏメッセージを受信したと判断した場合、ステップＳ１０で、クライアント２０１は、利用時間を含むプローブをネットワーク上に送信して、ステップＳ４へ戻り、同様の処理を繰り返す。

図１８は、本実施形態の出力装置におけるドライバ処理手順の一例を示すフローチャートである。本処理は、クライアント２０１から利用時間情報が設定されたプローブメッセージを受信して、プローブＭａｔｃｈメッセージを応答あるいはＢｙｅメッセージを送信する処理である。

また、Ｓ２１〜Ｓ３０は各ステップを示す。各ステップは、デバイス、本実施形態ではプリンタのＣＰＵがＲＯＭやハードディスク等に記憶された制御プログラムをＲＡＭ上にロードして実行することで実現される。

また、デバイスは、クライアントが使用する特定のプロトコル（ＴＣＰ／ＩＰ、ＳＯＡＰ）に基づく通信を行うための、ネットワークカードを備えている。さらに、デバイスは、ＷＳＤシステムを搭載している。

まず、ステップＳ２１で、デバイス４００は、ネットワークＮＥＴに接続された状態で、クライアント２０１からの利用時間情報が設定された利用設定（プローブ）メッセージを受信しているかどうかを判断する。

そして、ステップＳ２１にてＰｒｏｂｅメッセージを受信したと判定した場合、ステップＳ２で、デバイス４００は、クライアント２０１から送信されたプローブメッセージに含まれる利用時間情報を取得する。

次に、ステップＳ２３で、デバイス４００は内蔵している時計もしくは図示しないタイムサービスを提供するＮＴＰサーバなどに現在時刻を問い合わせて取得する。

そして、デバイス４００は、ステップＳ２２にて受信した利用時間情報と現在の時刻とを比較し、利用開始時間になったかどうかを判断する。

つまり、デバイス４００は、デバイスが認識した時間情報と受信された利用時間情報に基づいて、受信された利用設定メッセージに対する応答処理を実行するか否かを判断する。

この応答処理にて送信される情報は、クライアント２０１に対してデバイス４００のドライバを導入させるための情報を含んだ応答情報である。

そして、Ｓ２４で、デバイス４００は、現在の時刻と利用時間情報とを比較し、利用時間情報になったと判断した時点で、ステップＳ２１受信しているプローブメッセージに対応するプローブＭａｔｃｈメッセージをクライアント２０１に送信する。

つまり、デバイス４００は、ステップＳ２３により応答処理を実行すべきと判断した場合、クライアント２０１に対してデバイスに関する情報を含んだ応答（プローブＭａｔｃｈ）を送信する。

このプローブＭａｔｃｈメッセージをクライアント２０１が受信することで、当該デバイスのドライバのインストール処理を開始する。

次に、ステップＳ２５で、デバイス４００は、ネットワークＮＥＴに対して、何からの切断要因、例えば電源がＯＦＦ指示されている等の要因が発生しているかどうかを判断する。

そして、ステップＳ２５で、切断要因が発生していると判断した場合、デバイス４００は、ステップＳ２６で、ＢｙｅメッセージをネットワークＮＥＴ上に送信する。

これにより、利用時間内であっても、クライアント２０１にデバイスドライバを削除する指示が通知されることとなる。

次に、ステップＳ２７で、デバイス４００は、ネットワークＮＥＴに対して何らかの接続要因、例えば電源投入等が発生しているかどうかを判断する。

そして、接続要因が発生していると判断した場合には、ステップＳ２８で、ＨｅｌｌｏメッセージをネットワークＮＥＴ上に送信して、ステップＳ２１に戻り、同様の処理を繰り返す。

この場合、クライアント２０１は、再度、利用時間情報を含んだプローブメッセージを送信してくる。そこで、これをステップＳ２１で取得することで、デバイス４００は、プローブメッセージに対するプローブＭａｔｃｈを適正なタイミング（Ｓ２３のタイミング）でクライアント２０１に送信する。

一方、ステップＳ２５で、切断要因が発生していないと判断した場合、デバイス４００は、ステップＳ２９で、現在時刻が利用時間情報の終了時刻であるかどうかをステップＳ２３と同様の手法で判断する。

つまり、デバイス４００は、現在時刻情報と利用終了時刻情報に基づいて離脱（Ｂｙｅ）メッセージ情報を送信すべきか否かを判断する。

そして、ステップＳ３０で、デバイス４００が、終了時刻に一致している判断したタイミングで、Ｂｙｅメッセージをクライアント２０１に送信して、本処理を終了する。

つまり、デバイス４００は、離脱メッセージ情報を送信すべきであると判断した場合、離脱（Ｂｙｅ）メッセージ情報を送信する。その結果、クライアント２０１ではＢｙｅメッセージ送信元のデバイスのドライバをアンインストールするため、利用時間情報に基づきデバイスドライバの使用が不可となる。

本実施形態によれば、クライアント２０１からデバイス４００に通知される利用時間に、デバイスからの応答に基づいて、そのドライバの登録あるいは削除を適時に実行できる。

さらに、クライアントが設定したネットワーク上に接続されたデバイスの利用時間をデバイスに通知して、利用時間内にデバイスから応答があれば、そのドライバをドライバデータベースに登録し、利用時間外はドライバデータベースから削除できる。

また、ネットワーク上に接続されたデバイスの利用可能時間をクライアント側から設定して、クライアント装置により設定された利用可能時間外の場合はネットワークプラグアンドプレイでデバイスが検出されることがなくなる。

さらに、デバイスのドライバが利用可能時間以前から使用されることがなくなり、デバイスの利用時間を厳密に管理することが可能になる。

〔第２実施形態〕
第２実施形態では、図１１に示したように、ファンクションディスカバリの利用時間設定クライアント４０１３による利用時間を設定する図１２に示したユーザインタフェースがクライアント２０１には存在せず、代わりにデバイス管理サーバにある場合を述べる。

なお、デバイス管理サーバは、図２に示したサーバ２０４がその機能を備える。また、サーバ２０４は、いわゆるコンピュータシステムとしてのハードウエア資源と、ハードウエア資源としての、例えばハードディスク等に記憶されるＯＳ、システムプログラム、デバイスドライバ等のプログラムをソフトウエア資源として備える。

また、サーバ２０４は、所定のプロトコル（ＳＯＡＰを含む）でネットワークＮＥＴ上のデバイスやクライアントと通信可能に構成されている。

図１６は、本実施形態におけるサーバ装置が備えるデータベースの一例を示す図である。

図１６に示すように、本実施形態では、デバイス管理サーバでは、特定のＩＴ管理者がネットワークＮＥＴに接続された各デバイスに対して、クライアント毎のデバイス利用可能時間設定を行う。そして、デバイス管理サーバに備えるハードディスク上のデータベースに保持する。

これはクライアントの位置情報であるクライアントＵＲＩと、利用可能時間設定のテーブルを、ネットワークに接続されたデバイス利用可能時間設定を行うクライアントごとに別々に持ち、デバイスごとに管理する。

デバイス管理サーバは、デバイス４００のＨｅｌｌｏメッセージに応答して、ＲｅｐｌｙＴｏにクライアントのＵＲＩおよび各クライアントの利用可能時間情報を入れてＰｒｏｂｅメッセージをマルチキャストで送信する。

なお、第２実施形態においてクライアントを特定するための情報と利用時間情報を含んだＰｒｏｂｅメッセージを送信情報メッセージとも記載する。

つまり、デバイス管理サーバは、デバイスを使用する各クライアントの利用時間情報と、クライアントを特定する情報とを設定する。そして、設定された利用時間情報とクライアントを特定する情報とが設定された送信情報メッセージをデバイスに対して送信する。

このデバイス管理サーバの処理により発行された送信情報メッセージをデバイスが受信した場合、デバイス管理サーバから利用時間情報とデータ処理装置を特定する情報が設定された送信情報メッセージを受信する。

デバイスは、認識した時間情報と受信した利用時間情報に従って、受信された送信情報メッセージに対する応答処理を実行すべきか否かを判断する。

そして、デバイスが、応答処理を実行すべきと判断した場合、クライアントを特定する情報に基づいて特定されたデータ処理装置に対して、応答を送信する。

この後は、第１実施形態に示したデバイスドライバのインストール、アンインストールのシーケンス例とまったく同等に動作する。

第２実施形態によれば、ＩＴ管理者が、あたかも各クライアントが利用時間設定をしたものとまったく同じように動作させることができることで、ＩＴ管理者がユーザごとにデバイスの利用時間をすべて一括して管理できるようになる。また、利用時間の設定を個別化したり、グループ化したりすることも可能となる。

また、デバイス管理サーバは利用可能時間設定をＷｅｂサービスとして提供することで、各クライアントから利用可能時間設定がＷｅｂブラウザなどを通して設定することも可能である。

これにより利用可能時間設定が、サーバ装置側一箇所で集中管理できることになるので、利用時間の分散化など利便性が向上する。

例えば、ネットワークプリンタの使用でデバイスを占有するために予約時間を指定したり、混み合っているので多数のユーザでデバイスの利用可能時間をずらして使用しようとする場合に、第２実施形態が有効である。

〔第３実施形態〕
第３実施形態では、利用時間を設定するユーザインタフェースがデバイスに存在するケースを述べる。

ネットワークＮＥＴ上のデバイス上にあるパネル画面などから、クライアントの位置情報であるＵＲＩと、利用可能時間情報をそれぞれ指定する。

以下、この後は、第１実施形態に示したデバイスドライバのインストール、アンインストールのシーケンス例とまったく同等に動作する。

つまり、デバイスは、クライアントから受信したＰｒｏｂｅ情報に含まれるＵＲＩから、クライアントを特定し、特定されたクライアントに設定されている利用時間情報に基づいてＰｒｏｂｅＭａｔｃｈを送信する。

第３実施形態によれば、クライアントでユーザが勝手に利用可能時間を設定することがなくなるので、デバイス利用時間の競合や占有などを防ぐことができる。

〔第４実施形態〕
第１実施形態においては、利用時間情報に基づいてデバイス４００がＰｒｏｂｅメッセージを送信すべきか否かを判断して、デバイス主導の処理について説明した。これに対し第４実施形態ではクライアント主導の処理について説明する。

なお、第４実施形態においても上記実施形態と異なる点についてのみ記載するものとし、その他の点は上記実施形態と同様の処理を行うものとする。

第４実施形態におけるクライアントの処理について図２１を用いて説明する。

図１９は、本実施形態におけるデータ処理装置における第２のドライバ処理手順の一例を示すフローチャートである。なお、図１９の各ステップの処理はクライアントのＣＰＵによって実行される。

クライアント２０１は、図１２のＵＩを用いて利用時間情報を設定し、ＲＡＭ等に保持しておく。

続いて、クライアント２０１は２つの処理を並行して行う。１つ目の処理は現在時間がＳ２１０１にて設定された利用開始時刻か否かを判定する処理である（Ｓ２１０２）。

また、クライアント２０１は、デバイスからＨｅｌｌｏメッセージを受信したか否かを判定する（Ｓ２１０３）。Ｓ２１０３により、Ｈｅｌｌｏメッセージを受信した場合、現在時間は利用開始時刻か否かを判定する（Ｓ２１０４）。

つまり、クライアントは、デバイスからＨｅｌｌｏメッセージを受信しても現在時間が利用開始時刻でなければＨｅｌｌｏメッセージに対する応答は行わない。

クライアントは現在時間が利用開始時間であると判定した場合、Ｐｒｏｂｅメッセージを送信して（Ｓ２１０５）、デバイスからのＰｒｏｂｅＭａｔｃｈメッセージを受信したか否かを判定する（Ｓ２１０６）。

Ｓ２１０６において、ＰｒｏｂｅＭａｔｃｈを受信した場合、クライアント２０１は、ＰｒｏｂｅＭａｔｃｈの送信元のデバイス情報を検索デバイスリストに登録して（Ｓ２１０７）、該デバイスのドライバをインストールする（Ｓ２１０８）。

この登録の際に、インストールされたドライバに対して利用終了時刻情報を対応付けて登録する。

さらに、クライアントは、各デバイスデバイスドライバの利用時間終了時間と現在時間を比較して、利用時間終了となっているドライバの有無を判定する（Ｓ２１０９）。

Ｓ２１０９により、利用時間終了となっているドライバがあると判定された場合、クライアント２０１は、Ｓ２１０９にて判定されたドライバのアンインストール処理を実行する（Ｓ２１１０）。また、利用時間内であっても、デバイスからＢｙｅメッセージを受信することに応じて、該デバイスのドライバをアンインストールする。

第１実施形態では、各デバイスが利用時間を判定して、ＰｒｏｂｅＭａｔｃｈの送信処理や、Ｂｙｅメッセージの送信処理を制御する必要があるため、各デバイスに制御機能を搭載する必要があった。

本実施形態によれば、例えば、出張や外出により普段のネットワーク環境とは異なるネットワーク環境にクライアントを接続した場合であっても、利用時間に応じてドライバのインストールおよびアンインストールを制御することが可能となる。

〔第５実施形態〕
以下、図２０、図２１に示すメモリマップを参照して本発明に係るネットワークシステムで読み取り可能なデータ処理プログラムの構成について説明する。

図２０は、本発明に係るデータ処理装置で読み取り可能な各種データ処理プログラムを格納する記憶媒体のメモリマップを説明する図である。

図２１は、本発明に係るデバイスで読み取り可能な各種データ処理プログラムを格納する記憶媒体のメモリマップを説明する図である。

なお、特に図示しないが、記憶媒体に記憶されるプログラム群を管理する情報、例えばバージョン情報，作成者等も記憶され、かつ、プログラム読み出し側のＯＳ等に依存する情報、例えばプログラムを識別表示するアイコン等も記憶される場合もある。

さらに、各種プログラムに従属するデータも上記ディレクトリに管理されている。また、各種プログラムをコンピュータにインストールするためのプログラムや、インストールするプログラムが圧縮されている場合に、解凍するプログラム等も記憶される場合もある。

本実施形態における図１７、図１８、図１９に示す機能が外部からインストールされるプログラムによって、ホストコンピュータにより遂行されていてもよい。そして、その場合、ＣＤ−ＲＯＭやフラッシュメモリやＦＤ等の記憶媒体により、あるいはネットワークを介して外部の記憶媒体から、プログラムを含む情報群を出力装置に供給される場合でも本発明は適用されるものである。

以上のように、前述した実施形態の機能を実現するソフトウエアのプログラムコードを記録した記憶媒体を、システムあるいは装置に供給する。そして、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。

この場合、記憶媒体から読み出されたプログラムコード自体が本発明の新規な機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。

従って、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等、プログラムの形態を問わない。

プログラムを供給するための記憶媒体としては、例えばフレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤなどを用いることができる。

この場合、記憶媒体から読出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。

その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続する。そして、該ホームページから本発明のコンピュータプログラムそのもの、もしくは、圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。

また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバやｆｔｐサーバ等も本発明の請求項に含まれるものである。

また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせる。そして、その鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。

また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけではない。例えばそのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行う。そして、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込ませる。その後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

本発明は上記実施形態に限定されるものではなく、本発明の趣旨に基づき種々の変形（各実施形態の有機的な組合せを含む）が可能であり、それらを本発明の範囲から排除するものではない。

本発明の様々な例と実施形態を示して説明したが、当業者であれば、本発明の趣旨と範囲は、本明細書内の特定の説明に限定されるのではない。

本発明の第１実施形態を示すネットワークシステムのブロック構成図である。 図１に示したネットワークシステムのネットワーク環境を説明する図である。 本実施形態におけるデータ処理装置上のネットワークプラグアンドプレイ（ＮＰｎＰ）のモジュール構成を説明するブロック図である。 本実施形態におけるデータ処理装置とネットワークデバイスとの第１の通信例を説明する図である。 本実施形態における印刷装置からネットワーク上にマルチキャストされる情報を説明する図である。 本実施形態におけるデータ処理装置からネットワーク上にマルチキャストされる情報を説明する図である。 本実施形態における印刷装置からネットワーク上にマルチキャストされる情報を説明する図である。 本実施形態におけるデータ処理装置からネットワーク上にユニキャストされる情報を説明する図である。 本実施形態における印刷装置から通知される情報を説明する図である。 本実施形態における印刷装置からネットワーク上にマルチキャストされる情報を説明する図である。 図３に示したファンクションディスカバリクライアントとファンクションディスカバリプロバイダの詳細を説明するブロック図である。 本実施形態のデータ処理装置で表示可能な利用時間設定のユーザインタフェースの一例を示す図である。 本実施形態のデータ処理装置で検索されたネットワークデバイスの追加／削除設定のためのユーザインタフェースの一例を示す図である。 本実施形態におけるデータ処理装置とネットワークデバイスとの第１の通信例を説明する図である。 図１４に示したクライアントからデバイスにマルチキャストで通知されるＰｒｏｂｅメッセージの一例を示す図である。 本実施形態におけるサーバ装置が備えるデータベースの一例を示す図である。 本実施形態におけるデータ処理装置における第１のドライバ処理手順の一例を示すフローチャートである。 本実施形態における出力装置におけるドライバ処理手順の一例を示すフローチャートである。 本実施形態におけるデータ処理装置における第２のドライバ処理手順の一例を示すフローチャートである。 本発明に係るデータ処理装置で読み取り可能な各種データ処理プログラムを格納する記憶媒体のメモリマップを説明する図である。 本発明に係る出力装置で読み取り可能な各種データ処理プログラムを格納する記憶媒体のメモリマップを説明する図である。

符号の説明

３０１ プリンタ
３０２ ファンクションディスカバリプロバイダ
３０３ ファンクションディスカバリクライアント
３０４ プラグアンドプレイマネージャ
３０５ スプーラ
３０６ クラスインストーラ
３０７ ドライバデータベース

Claims (20)

1. 複数の出力装置と通信可能であり、各出力装置に対応するドライバをインストール可能なデータ処理装置であって、
   前記出力装置を使用する利用時間情報を設定する設定手段と、
   前記設定手段により設定された利用時間情報を含む利用設定メッセージを送信する送信手段と、
   いずれかの出力装置から前記利用時間情報に従って応答される情報を受信することに応じて、前記出力装置のデバイスドライバをドライバデータベースに導入する導入手段と、
   を有することを特徴とするデータ処理装置。
2. 前記利用時間情報は、デバイスドライバの利用開始時刻情報およびデバイスドライバの利用終了時刻情報を含んでおり、
   前記導入手段により導入したデバイスドライバの出力装置から前記利用終了時刻情報に従って送信される離脱メッセージ情報を受信することに応じて、前記ドライバデータベースに登録されたデバイスドライバを削除する削除手段を更に有することを特徴とする請求項１記載のデータ処理装置。
3. 前記ドライバデータベースは、オペレーティングシステムのシステム管理ファイルに含まれることを特徴とする請求項１または２記載のデータ処理装置。
4. ネットワークを介してデータ処理装置と通信可能な出力装置であって、
   前記データ処理装置から利用時間情報が設定された利用設定メッセージを受信する受信手段と、
   前記出力装置が認識した時間情報と前記受信手段によって受信された利用時間情報に基づいて、前記受信手段により受信された利用設定メッセージに対する応答処理を実行するか否かを判断する判断手段と、
   前記判断手段により前記応答処理を実行すべきと判断された場合に、前記データ処理装置に対して前記出力装置に関する情報を含んだ応答を送信する送信手段と、
   を有することを特徴とする出力装置。
5. 前記出力装置は現在時刻情報を取得する取得手段を更に有しており、
   前記受信手段によって受信される利用設定メッセージは前記出力装置の利用開始時刻情報および前記出力装置の利用終了時刻情報を含み、
   前記判断手段は、前記取得手段によって取得された現在時刻情報と、前記受信手段によって受信された利用設定メッセージに含まれる利用開始時刻情報とを比較し、前記現在時刻情報の時刻が前記利用開始時刻情報の時刻を過ぎていると判定した場合、前記送信手段は、前記データ処理装置に対して前記出力装置のドライバを導入させるための情報を含んだ応答を送信することを特徴とする請求項４に記載の出力装置。
6. 前記判断手段は、前記現在時刻情報と前記利用終了時刻情報に基づいて離脱メッセージ情報を送信すべきか否かを判断し、
   前記送信手段は、前記判断手段によって前記離脱メッセージ情報を送信すべきであると判断された場合に、前記離脱メッセージ情報を送信することを特徴とする請求項５に記載の出力装置。
7. データ処理装置と出力装置とが通信可能なネットワークシステムであって、
   前記データ処理装置は、
   前記出力装置を使用する利用時間情報を設定する設定手段と、
   前記設定手段により設定された利用時間情報を含む利用設定メッセージを送信する送信手段と、
   いずれかの出力装置から前記利用時間情報に従って応答される情報を受信することに応じて、前記出力装置のデバイスドライバをドライバデータベースに導入する導入手段とを有し、
   前記出力装置は、
   前記データ処理装置から利用時間情報が設定された利用設定メッセージを受信する受信手段と、
   前記出力装置が認識した時間情報と前記受信手段によって受信された利用設定メッセージに対する応答処理を実行するか否かを判断する判断手段と、
   前記判断手段により前記応答処理を実行すべきと判断された場合に、前記データ処理装置に対して前記出力装置に関する情報を含んだ応答を送信する送信手段とを有することを特徴とするネットワークシステム。
8. 出力装置と、データ処理装置と通信可能な情報処理装置であって、
   前記出力装置を使用する各データ処理装置の利用時間情報と、データ処理装置を特定する情報とを設定する設定手段と、
   前記設定手段により設定された利用時間情報とデータ処理装置を特定する情報とが設定された送信情報メッセージを前記出力装置に対して送信する送信手段と、
   を有することを特徴とする情報処理装置。
9. 情報処理装置と、複数のデータ処理装置と通信可能な出力装置であって、
   前記情報処理装置から利用時間情報とデータ処理装置を特定する情報が設定された送信情報メッセージを受信する受信手段と、
   前記出力装置が認識した時間情報と前記受信手段が受信した利用時間情報に従って、前記受信手段により受信された送信情報メッセージに対する応答処理を実行すべきか否かを判断する判断手段と、
   前記判断手段により前記応答処理を実行すべきと判断された場合に、前記データ処理装置を特定する情報に基づいて特定されたデータ処理装置に対して、応答送信する送信手段と、
   を有することを特徴とする出力装置。
10. 出力装置と、複数のデータ処理装置と通信可能な情報処理装置とを含むネットワークシステムであって、
    前記情報処理装置は、
    前記出力装置を使用する各データ処理装置の利用時間情報を設定する設定手段と、
    前記設定手段により設定された利用時間情報とデータ処理装置を特定する情報とが設定された送信情報メッセージを前記出力装置に送信する送信手段とを有し、
    前記データ処理装置は、
    出力装置に対応するデバイスドライバを記憶するドライバ記憶手段と、
    いずれかの出力装置から前記利用時間情報に基づいて応答される情報を受信することに応じて、前記出力装置のデバイスドライバをドライバデータベースに導入する導入手段とを有し、
    前記出力装置は、
    前記情報処理装置から利用時間情報とデータ処理装置を特定する情報が設定された送信情報メッセージを受信する受信手段と、前記出力装置が認識した時間情報と前記受信手段によって受信された利用時間情報に基づいて、前記受信手段により受信された送信情報メッセージに対する応答処理を実行するか否かを判断する判断手段と、
    前記判断手段により前記応答処理を実行すべきと判断された場合に、前記データ処理装置を特定する情報に基づいて特定されたデータ処理装置に対して、応答を送信する送信手段と、
    を有することを特徴とするネットワークシステム。
11. 複数の出力装置と通信可能であり、各出力装置に対応するドライバをインストール可能なデータ処理装置におけるドライバ処理方法であって、
    前記出力装置を使用する利用時間情報を設定する設定ステップと、
    前記設定ステップにより設定された利用時間情報を含む利用設定メッセージを送信する送信ステップと、
    いずれかの出力装置から前記利用時間情報に従って応答される情報を受信することに応じて、前記出力装置のデバイスドライバをドライバデータベースに導入する導入ステップと、
    を有することを特徴とするドライバ処理方法。
12. 前記利用時間情報は、デバイスドライバの利用開始時刻情報およびデバイスドライバの利用終了時刻情報を含んでおり、
    前記導入ステップにより導入したデバイスドライバの出力装置から前記利用終了時刻情報に従って送信される離脱メッセージ情報を受信することに応じて、前記ドライバデータベースに登録されたデバイスドライバを削除する削除ステップを更に有することを特徴とする請求項１１記載のドライバ処理方法。
13. 前記ドライバデータベースは、オペレーティングシステムのシステム管理ファイルに含まれることを特徴とする請求項１１または１２記載のドライバ処理方法。
14. ネットワークを介してデータ処理装置と通信可能な出力装置におけるドライバ処理方法であって、
    前記データ処理装置から利用時間情報が設定された利用設定メッセージを受信する受信ステップと、
    前記出力装置が認識した時間情報と前記受信ステップによって受信された利用時間情報に基づいて、前記受信ステップにより受信された利用設定メッセージに対する応答処理を実行するか否かを判断する判断ステップと、
    前記判断ステップにより前記応答処理を実行すべきと判断された場合に、前記データ処理装置に対して前記出力装置に関する情報を含んだ応答を送信する送信ステップと、
    を有することを特徴とするドライバ処理方法。
15. 前記出力装置は現在時刻情報を取得する取得ステップを更に有しており、
    前記受信ステップによって受信される利用設定メッセージは前記出力装置の利用開始時刻情報および前記出力装置の利用終了時刻情報を含み、
    前記判断ステップは、前記取得ステップによって取得された現在時刻情報と、前記受信ステップによって受信された利用設定メッセージに含まれる利用開始時刻情報とを比較し、前記現在時刻情報の時刻が前記利用開始時刻情報の時刻を過ぎていると判定した場合、前記送信ステップは、前記データ処理装置に対して前記出力装置のドライバを導入させるための情報を含んだ応答を送信することを特徴とする請求項１４に記載のドライバ処理方法。
16. 前記判断ステップは、前記現在時刻情報と前記利用終了時刻情報に基づいて離脱メッセージ情報を送信すべきか否かを判断し、
    前記送信ステップは、前記判断ステップによって前記離脱メッセージ情報を送信すべきであると判断された場合に、前記離脱メッセージ情報を送信することを特徴とする請求項１５に記載のドライバ処理方法。
17. 出力装置と、データ処理装置と通信可能な情報処理装置におけるドライバ処理方法であって、
    前記出力装置を使用する各データ処理装置の利用時間情報と、データ処理装置を特定する情報とを設定する設定ステップと、
    前記設定ステップにより設定された利用時間情報とデータ処理装置を特定する情報とが設定された送信情報メッセージを前記出力装置に対して送信する送信ステップと、
    を有することを特徴とするドライバ処理方法。
18. 複数の出力装置と通信可能であり、各出力装置に対応するドライバをインストール可能なデータ処理装置を制御するプログラムであって、
    前記出力装置を使用する利用時間情報を設定する設定手段と、
    前記設定手段により設定された利用時間情報を含む利用設定メッセージを送信する送信手段と、
    いずれかの出力装置から前記利用時間情報に従って応答される情報を受信することに応じて、前記出力装置のデバイスドライバをドライバデータベースに導入する導入手段として機能させることを特徴とするプログラム。
19. ネットワークを介してデータ処理装置と通信可能な出力装置を制御するプログラムであって、
    前記データ処理装置から利用時間情報が設定された利用設定メッセージを受信する受信手段と、
    前記出力装置が認識した時間情報と前記受信手段によって受信された利用時間情報に基づいて、前記受信手段により受信された利用設定メッセージに対する応答処理を実行するか否かを判断する判断手段と、
    前記判断手段により前記応答処理を実行すべきと判断された場合に、前記データ処理装置に対して前記出力装置に関する情報を含んだ応答を送信する送信手段として機能させることを特徴とするプログラム。
20. 出力装置と、データ処理装置と通信可能な情報処理装置を制御するプログラムであって、
    前記出力装置を使用する各データ処理装置の利用時間情報と、データ処理装置を特定する情報とを設定する設定手段と、
    前記設定手段により設定された利用時間情報とデータ処理装置を特定する情報とが設定された送信情報メッセージを前記出力装置に対して送信する送信手段として機能させることを特徴とするプログラム。

Images