JP4261742B2 - デバイス、ネットワークシステム、ジョブ処理方法、ジョブモニタ方法、及びコンピュータ読み取り可能な記憶媒体 - Google Patents
デバイス、ネットワークシステム、ジョブ処理方法、ジョブモニタ方法、及びコンピュータ読み取り可能な記憶媒体 Download PDFInfo
- Publication number
- JP4261742B2 JP4261742B2 JP2000197978A JP2000197978A JP4261742B2 JP 4261742 B2 JP4261742 B2 JP 4261742B2 JP 2000197978 A JP2000197978 A JP 2000197978A JP 2000197978 A JP2000197978 A JP 2000197978A JP 4261742 B2 JP4261742 B2 JP 4261742B2
- Authority
- JP
- Japan
- Prior art keywords
- information
- event
- job
- network
- receiving
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Debugging And Monitoring (AREA)
- Computer And Data Communications (AREA)
- User Interface Of Digital Computer (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、デバイス、ネットワークシステム、ジョブ処理方法、ジョブモニタ方法、及びコンピュータ読み取り可能な記憶媒体に関し、特に、ネットワーク上のデバイスを検索し、当該検索デバイス及びその位置情報等をユーザに対して容易に認識しやすく表示出力するために用いて好適なものである。
【０００２】
【従来の技術】
従来より例えば、ネットワーク上に接続された各種の資源（プリンタ、サーバ装置、スキャナ等のデバイス）を効率的に発見し、それを利用するための方法としては、ディレクトリサービスと呼ばれる方法が提供されている。
このディレクトリサービスとは、言わばネットワークに関する電話帳の機能を有し、様々な情報を格納するためのものである。
【０００３】
上記ディレクトリサービスを用いたディレクトリシステムの具体例としては、例えば、ＬＤＡＰ（Ｌｉｇｈｔｗｅｉｇｈｔ Ｄｉｒｅｃｔｏｒｙ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）がある。このＬＤＡＰの規定については、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｅｃｅ）が発行している、標準仕様である「ＲＦＣ（Ｒｅｑｕｅｓｔ Ｆｏｒ Ｃｏｍｍｅｔｓ）１７７７」に記載されている。
【０００４】
上述のようなディレクトリサービスにより、例えば、ネットワーク上に接続されているデバイスを検索することで、ネットワーク上で利用可能なデバイスのネットワーク上のアドレスの一覧（アドレスリスト）を得ることができる。
【０００５】
【発明が解決しようとする課題】
しかしながら、上述したような従来のディレクトリサービスにより得られるアドレスリストでは、利用可能なデバイスの位置を、認識しやすいかたちで得ることはできなかった。
【０００６】
例えば、ネットワーク上のプリンタの検索の場合、「自分のフロアにおいて、自分の場所に一番近いプリンタはどこにあるのか」、或いは「カラー画像を出力できるプリンタは、その建物の中のどの場所にあるのか」等というデバイスの階層的なロケーション情報を、ユーザに分かりやすく通知することが望まれていたが、従来ではこれを実現できなかった。
さらに、印刷等のジョブの実行をネットワーク上の情報処理装置によりプリンタへ依頼した場合に、「どの場所にあるプリンタへ印刷の依頼を行ったか」、或いは「自分が依頼した印刷が正常に終了したか否か」、或いは「ジャムや用紙切れ等のエラーが発生していないか」等という情報を、ユーザに分かりやすく通知することが望まれていたが、従来ではこれを実現できなかった。
【０００７】
そこで、本発明は、上記の欠点を除去するために成されたもので、所望するデバイスの位置と共に、当該デバイスへジョブを依頼した場合には当該ジョブの状況等の情報を、ユーザに対して認識しやすいかたちで提供できるようにすることを目的とする。
【０００８】
【課題を解決するための手段】
本発明のデバイスは、ネットワークを介して依頼されたジョブを処理するデバイスであって、前記ネットワーク上の情報処理装置から送信されたジョブを受信する受信手段と、前記ジョブについてのイベントが発生するのに応じて、自身の位置を階層的に表した階層型位置情報及び該イベントを示すイベント情報を前記情報処理装置に送信する送信手段と、を有することを特徴とする。
【０００９】
本発明のネットワークシステムは、少なくとも、ネットワークを介して依頼されたジョブを処理するデバイスと、依頼されたジョブをモニタする情報処理装置とを有するネットワークシステムであって、前記デバイスは、前記情報処理装置から送信されたジョブを受信する受信手段と、前記ジョブについてのイベントが発生するのに応じて、自身の位置を階層的に表した階層型位置情報及び該イベントを示すイベント情報を前記情報処理装置に送信する送信手段と、を含み、前記情報処理装置は、前記デバイスにジョブを送信する送信手段と、前記ジョブについてのイベントが発生するのに応じて前記デバイスから送信される情報であって、該デバイスの位置を階層的に表した階層型位置情報及び該イベントを示すイベント情報を受信する受信手段と、前記受信手段によって受信した階層型位置情報に基づいて、前記イベント情報が示すイベントを表示する表示手段と、を含むことを特徴とする。
【００１０】
本発明のジョブ処理方法は、ネットワークを介して依頼されたジョブを処理するジョブ処理方法であって、前記ネットワーク上の情報処理装置から送信されたジョブを受信する受信ステップと、前記ジョブについてのイベントが発生するのに応じて、自身の位置を階層的に表した階層型位置情報及び該イベントを示すイベント情報を前記情報処理装置に送信する送信ステップと、を有することを特徴とする。
【００１１】
本発明のジョブモニタ方法は、ネットワークを介して依頼されたジョブをモニタするジョブモニタ方法であって、前記ネットワーク上のデバイスにジョブを送信する第１の送信ステップと、前記第１の送信ステップによって送信されたジョブを受信する第１の受信ステップと、前記第１の受信ステップによって受信されたジョブについてのイベントが発生するのに応じて、自身の位置を階層的に表した階層型位置情報及び該イベントを示すイベント情報を前記ネットワーク上の情報処理装置に送信する第２の送信ステップと、前記第２の送信ステップによって送信された前記階層型位置情報及び前記イベント情報を受信する第２の受信ステップと、前記第２の受信ステップによって受信された階層型位置情報に基づいて、前記イベント情報が示すイベントを表示する表示ステップと、を含むことを特徴とする。
【００１２】
本発明のコンピュータ読み取り可能な記憶媒体は、ネットワークを介して依頼されたジョブを処理することをコンピュータに実行させるためのコンピュータプログラムを記憶したコンピュータ読み取り可能な記憶媒体であって、前記コンピュータプログラムは、前記ネットワーク上の情報処理装置から送信されたジョブを受信する受信ステップと、前記ジョブについてのイベントが発生するのに応じて、自身の位置を階層的に表した階層型位置情報及び該イベントを示すイベント情報を前記情報処理装置に送信する送信ステップと、をコンピュータに実行させることを特徴とする。
【００３２】
【発明の実施の形態】
以下、本発明の実施の形態について図面を用いて説明する。
【００３３】
本発明は、例えば、図１に示すようなデバイス検索システムに適用される。
本実施の形態のデバイス検索システムは、上記図１に示すように、クライアント装置２０、デバイス３０、及びサーバ装置１０がネットワーク４０上に配置された構成としている。
【００３４】
クライアント装置２０は、例えば、汎用のコンピュータ等からなり、検索要求モジュール２１及び表示モジュール２２を含んでいる。
検索要求モジュール２１は、サーバ装置１０へ所望のデバイス検索条件を送信し、その結果を受信する。検索要求モジュール２１にて受信された検索結果を可視表示する。
【００３５】
サーバ装置１０は、ネットワーク４０上のデバイス３０の属性情報を管理するデータベース１１を有するディレクトリサーバとしての機能を有する。
データベース１１には、ネットワーク４０上のデバイス３０の識別情報、及びデバイス３０が有する各種属性の情報が登録される。
【００３６】
また、サーバ装置１０は、検索モジュール１２及び属性登録モジュール１３を含んでいる。
検索モジュール１２は、クライアント装置２０から受信したデバイス検索条件に基づいて、データベース１１から条件に合致するデバイスを検索し、その検索結果をクライアント装置２０へ送信する。
属性登録モジュール１３は、デバイス３０等からデバイス属性を受信してデータベース１１１に登録する。
【００３７】
デバイス３０は、クライアント装置２０等に各種サービスを提供するため機能を有し、例えば、スキャナやプリンタ、或いはファクシミリ等である。
デバイス３０は、デバイス属性送信モジュール３１を含み、このデバイス属性送信モジュール３１は、デバイス３０自身の属性情報をサーバ装置１０へ送信し、データベース１１への登録要求を行う。
【００３８】
尚、上記図１では、説明の簡単のため、本デバイス検索システムの最小単位の構成を示している。すなわち、上記図１では、それぞれが１つのクライアント装置２０及びデバイス３０がネットワーク４０へ接続された構成を図示しているが、これらの接続数に限られることはなく、それぞれが複数のクライアント装置２０及びデバイス３０がネットワーク４０へ接続された構成とするようにしてもよい。
また、サーバ装置１０についても同様に、複数のサーバ装置１０をネットワーク４０上へ接続する構成とするようにしてもよい。
【００３９】
図２は、本実施の形態のデバイス検索システムが動作可能なネットワークシステムの構成の一例を示したものである。
【００４０】
上記図２において、“１０１”はカラープリンタを示し、“１０２”はＭＦＰを示し、“１０３”及び“１０４”はモノクロプリンタを示し、“１０５”はスキャナを示す。
これらのデバイス１０１〜１０５（上記図１のデバイス３０に対応、以下、「ネットワークデバイス」とも言う）は、ＬＡＮ等のネットワーク１００（上記図１のネットワーク４０に対応）に接続されている。
【００４１】
尚、上記ＭＦＰ（Ｍｕｌｔｉ Ｆｕｎｃｔｉｏｎ Ｐｅｒｉｈｅｒａｌ）とは、コピー機であるが、ネットワークプリンタとしても使用可能なものである。以下、「多機能コピー機」とも言う。
【００４２】
“１１１”及び“１１３”はそれぞれ、デスクトップ型のパーソナルコンピュータ（以下、「デスクトップＰＣ」とも言う）及びとノート型のパーソナルコンピュータ（以下、「ノートＰＣ」とも言う）である。
これらのＰＣ１１１，１１３は、本実施の形態のネットワーククライアントのプログラムが実行可能なＰＣであり、クライアント装置（上記図１のクライアント装置２０に対応）としてネットワーク１００に接続され、詳細は後述するが、ネットワーク１００上に接続されたサーバ装置に対して所望の条件を満たすデバイスに関する問い合わせ情報（デバイス検索の問い合わせの情報）を発行する機能ともに、当該デバイスの検索結果を表示する表示機能をも有する。
【００４３】
“１１２”は、本実施の形態のネットワークサーバのプログラムが実行可能なＰＣであり、サーバ装置（上記図１のサーバ装置１０に対応）としてネットワーク１００に接続される。
このため、サーバ装置１１２は、詳細は後述するが、ネットワークデバイス１０１〜１０５に関する種々の情報を保持する機能や、ネットワーク１００に接続されたクライアント装置１１１又は１１３からのデバイス検索の問い合わせを受け付け、その結果を返す機能を有する。
【００４４】
上述のような本実施の形態でのネットワークシステムでは、ネットワークデバイス１０１〜１０５のうちのカラープリンタ１０１、多機能コピー機１０２、及びモノクロプリンタ１０３と、クライアント装置１１１と、サーバ装置１１２と、後述するファイアウォール１２０とが、２階のフロアに設置されている。
また、ネットワークデバイス１０１〜１０５のうちのモノクロプリンタ１０４及びスキャナ１０５は、１階のフロアに設置されている。
ノートＰＣ１１３については、現在は１階のフロアに設置されているものとしているが、１階のフロアのネットワーク１００から取り外され、２階のフロアへ移動することもある。
【００４５】
また、１階のフロア及び２階のフロアにそれぞれ設置されたデバイスを相互に接続するネットワーク１００は、ファイアウォール１２０を介してインターネット１３０へ接続されており、さらに、インターネット１３０を介して他のネットワーク１４０とも接続されている。
【００４６】
図３は、任意のパーソナルコンピュータ２００（以下、単に「ＰＣ２００」と言う）の内部構成を示したものである。
上記図２に示したデスクトップＰＣ１１１、ノートＰＣ１１３、及びサーバ端末装置１１２等は、上記図３のＰＣ２００の機能を有する。
【００４７】
具体的には、ＰＣ２００は、ネットワーククライアントのプログラム（クライアント装置ソフトウェア）、或いはネットワーククサーバのプログラム（サーバ装置ソフトウェア）が稼動するようになされている。
尚、以下の説明では、クライアント装置ソフトウェアとサーバ装置ソフトウェアをまとめて、「ネットワークデバイス端末装置検索ソフトウェア」とも言う。
【００４８】
ＰＣ２００において、ＣＰＵ２０２は、ＲＯＭ２０３或いはハードディスク（ＨＤ）２１１に記憶されたネットワークデバイス検索ソフトウェア、或いはフロッピーディスクドライブ（ＦＤ）２１２より供給されるネットワークデバイス検索ソフトウェアを実行することで、システムバス２０１に接続された各構成部２０３〜２１３を総括的に制御する。
【００４９】
ＲＡＭ２０４は、ＣＰＵ２０２の主メモリやワークエリア等として機能する。キーボードコントローラ（ＫＢＣ）２０５は、キーボード（ＫＢ）２０９や不図示のポインティングデバイス等からの指示入力を制御する。
コントローラ（ＣＲＴＣ）２０６は、ＣＲＴディスプレイ（ＣＲＴ）２１０の表示を制御する。
【００５０】
ディスクコントローラ（ＤＫＣ）２０７は、ブートプログラムや種々のアプリケーション、編集ファイル、ユーザファイル、或いはネットワーク管理プログラム等を記憶するハードディスク（ＨＤ）２１１、及びフロッピーディスクコントローラ（ＦＤ）２１２へのアクセスを制御する。
【００５１】
ネットワークインタフェースカード（ＮＩＣ）２０８は、ＬＡＮ２２０を介して、ネットワークプリンタや他のネットワーク機器、或いは他のＰＣと双方向にデータをやリとリするためのものである。
【００５２】
マウスコントローラ（ＭＣ）２１３は、マウス（ＭＳ）２１４を制御する。
【００５３】
尚、上記図３において、ＬＡＮ２２０は、上記図２に示したＬＡＮ１００に相当するものである。
【００５４】
図４は、上記図２のネットワークシステムにおいて、ＬＡＮ１００上のデバイスの位置を表現するための階層型位置情報を説明するための図である。
本実施の形態では、階層型位置情報のデータ構造を階層構造としており、上位層から下位層へと、より詳細な位置情報を特定するようになされている。
したがって、ユーザは、用途日的に応じて所望の階層を指定すればよい。
【００５５】
例えば、上記図４では、図中“３０９”で示す「ＬＢＰ１１１０」の階層型位置情報は、（Ｃ：ＪＰ（３０１）、Ｏ：ＡＢＣ商事（３０２）、ＢＲ：東京支店（３０３）、ＯＰ＝ｅｘｔｅｎｄ（３０４）、Ｂｕ＝Ｍビル（３０５）、ＦＬ＝２Ｆ（３０６）、ＢＬ＝２−１（３０７）、ＤＶ＝ｐｒｎｔｅｒ（３０８））として指定される。この場合、マップ（ｍａｐ）は「１０Ｘ＋１０Ｙ」として示される。
【００５６】
また、それぞれのエントリーについて説明すると、「Ｃ」は国情報を示し（“ＪＰ”は“日本”、“ＵＳ”は“アメリカ”等）、「Ｏ」は組織情報を示し（“ＡＢＣ商事”、“ＸＹＺ物産”等）、「ＢＲ」は支店又は支部等の情報を示す（“東京支店”、“大阪支店”等、以下、「支店情報」と言う）。
「ＢＵ」は建物であるビルディング情報を示し（“ＡＡビル”、“ＢＢビル”等）、「ＦＬ」はフロアーの階数であるフロア情報を示し（“１Ｆ”、“２Ｆ”等）、「ＢＬ」はフロアのブロックであるブロック情報を示し（“１−１”、“２−１”等）、「ＤＶ」はデバイスを示し（“ｐｒｉｎｔｅｒ”、“ＭＦＰ”等）、「ＮＭ」はデバイス名を示す（“ＬＢＰ１１１０”、“ＬＢＰ３３１０”等）。
【００５７】
また、ブロック情報「ＢＬ」に対応して、配置レイアウトを視覚的に表示したイメージデータであるレイアウトビットマップが用意されており、上記図４における「ＭＡＰ」は、そのマップ上の座標情報を示す。
【００５８】
さらに、「ＯＰ」はオプション情報、すなわち、「ＢＵ」階層、「ＦＬ」階層、及び「ＢＬ」階層の情報を含むことを示す（ｅｘｔｅｎｄ−拡張）。
尚、オプション情報の他の階層に設定してもよいし、オプション情報の階層を設定しないデータ構造であってもよい。
【００５９】
したがって、本実施の形態の主たる目的は、ネットワーク（ここでは、ＬＡＮ１００）上に接続された各デバイスの位置情報を、上記図４に示したような階層的構造によって管理することによって、検索要求の有ったデバイスの位置を特定し、当該特定したデバイスの位置をユーザに分かりやすく表示できるようにすることにある。
【００６０】
図５〜図８は、上記図４によって示される階層型位置情報のブロック階層ＢＬに対応したレイアウトビットマップの一例でる。これらの図５〜図８のレイアウトビットマップは、クライアント装置１１１側において表示される。これにより、ユーザは、デバイスの位置を容易に確認することができる。
【００６１】
上記図５のレイアウトビットマップは、２Ｆの２−１ブロックにおける位置マップである。
このレイアウトビットマップでは、予めビットマップとして保持されたレイアウト（２Ｆのフロア内の実際の机の並びやパーティションの様子等のレイアウト）上に、カラープリンタ１０１やＭＦＰ１０２が配置されていると共に、ファイアーウォール１２０及びサーバ装置１１２が当該レイアウトで設置してある。
【００６２】
上記図６のレイアウトビットマップは、２Ｆの２−２ブロックにおける位置マップである。
上記図６に示すように、２Ｆの２−２ブロックには、ＰＣ１１１とプリンタ１０３が同図に示すようなレイアウトで設置されている。
【００６３】
上記図７のレイアウトビットマップは、１Ｆの１−１ブロックにおける位置マップである。
上記図７に示すように、１Ｆの１−１ブロックには、ＰＣ１１３とモノクロプリンタ１０４が同図に示すようなレイアウトで設置されている。
【００６４】
上記図８のレイアウトビットマップは、１Ｆの１−２ブロックにおける位置マップである。
上記図８に示すように、１Ｆの１−２ブロックには、スキャナ１０５が同図に示すようなレイアウトで設置されている。
【００６５】
上述のようなレイアウトビットマップがクライアント装置１１１にて画面表示される。
【００６６】
以下、上記図４にて示される階層型位置情報に基づいてデバイスを検索するようになされた、上記図２のネットワークシステムの動作について、第１〜５の実施の形態を説明する。
【００６７】
まず、第１の実施の形態では、クライアント装置１１１がデバイスに対して発行したジョブについてのイベント情報を、そのデバイスの位置情報と共にわかりやすく通知する。
また、第１の実施の形態では、検索されたデバイスの位置を表現するためのレイアウトビットマップをクライアント装置１１１が保持しているものとするが、第２の実施の形態では、当該レイアウトビットマップをサーバ装置１１２が保持するものとする。
さらに、第１及び第２の実施の形態では、ブロック（ＢＬ）の階層に対応したレイアウトビットマップのみを保持するものとするが、第３の実施の形態では、階層型位置情報の各階層に対応するレイアウトビットマップを保持し、それをクライアント装置１１１の検索結果表示に反映する。
【００６８】
また、第４及び第５の実施の形態では、ネットワーク１００上のデバイスの位置をわかりやすくユーザへ通知すると共にに、そのデバイスの状態をユーザに通知する。
ここで、第４の実施の形態では、デバイスの状態をデバイスからポーリングすることにより取得する構成とし、第５の実施の形態では、デバイスの状態をデバイスからのイベント通知により取得する構成とする。
【００６９】
＜第１の実施の形態＞
本実施の形態では、クライアント装置１１１がデバイスに対して発行したジョブについてのイベント情報を、そのデバイスの位置情報と共ににわかりやすく通知する。
本実施の形態におけるシステムにおいて、デバイスの位置を表現するためのレイアウトビットマップは、クライアント装置１１１に保持されている。
【００７０】
そこで、まず、サーバ装置１１２が、ネットワーク１００上の各デバイスの属性情報を管理するための構成を説明する。
【００７１】
図９は、サーバ装置１１２がネットワーク１００上の各デバイスの属性情報を管理するためのデータベースのデータ構造の一例である。
上記図９において、各列が登録されている各デバイスに関する１件のデータ、すなわち、タプル（ｔｕｐｌｅ）に相当し、各行が各タプルごとの属性（ａｔｔｒｉｂｕｔｅ）に相当する。
データベース８００では、“８０２”〜“８１０”へ階層型位置情報が、“８１１”及び“８１２”へその他の属性情報が、各デバイスごとに対応付けられて記憶されている。
上記その他の属性情報としては、ここでは、例えば、カラー入出力機能の有無を示す属性（８１１）、及びＩＰアドレス（８１２）としているが、これに限られることはなく、ステープル機能の有無を示す属性や、両面印刷機能の有無を示す属性等、デバイスが一般に備えている属性の情報を用いるようにしてもよい。
【００７２】
図１０は、デバイスが、サーバ装置１１２が管理しているデータベース８００へ自身を登録する際の、デバイス登録データのデータ構造の一例を示した図である。
デバイス登録データ９００は、デバイスの階層型位置情報がセットされたロケーション情報ＴＡＧ９０１（９０２〜９１１）と、デバイスの属性情報がセットされたデバイス属性情報ＴＡ９１２（９１３〜９１４）とを含んでいる。
各デバイスは、電源投入後、自身のデバイス登録データ９００をサーバ装置１１２へ送信する。
【００７３】
尚、デバイスが自身のデバイス登録データ９００を送信する動作は、デバイス登録データ９００内の項目に変更が生じたことに応じて実行されてもよいし、デバイスがネットワークにプラグインされたことに応じて実行されてもよいし、定期的に送信動作を実行するものであってもよい。また、サーバ装置１１２からの問い合わせに応じて、デバイスがデバイス登録データ９００を送信するものであってもよい。
【００７４】
サーバ装置１１２は、デバイスからのデバイス登録データ９００の受信に応じて、受信したデバイスに関する情報をデータベース８００へ登録する。
【００７５】
尚、上記図１０のデバイス登録データ９００は、デバイス「ＬＢＰ１１１０」についてのデバイス登録データであるが、ＬＢＰ１１１０側に階層型位置情報が未だ登録されていない場合には、“９０３”及び“９０４”〜“９１１”についてはデータがセットされていない状態、或いは意味のないデータがセットされた状態でサーバ装置１１２へ送信される。
【００７６】
図１１は、クライアント装置１１１からデバイス検索を行う場合の検索条件入力画面の一例を示したものである。
上記図１１において、“１００１ａ”、“１００１ｂ”、及び“１００１ｃ”へ検索のエントリが入力される。このときの入力は、例えば、プルダウンメニューから所望するものを選択して入力することが可能である。
“１００２ａ”、“１００２ｂ”、“１００２ｃ”には、各エントリに対応ずる属性情報が入力される。
【００７７】
例えば、エントリがデバイスとして選択された場合には、属性情報は、プリンタ（ｐｈｎｔｅｒ）、ＭＦＰ（ＭＦＰ）、スキャナ（ｓｃａｍｅｒ）の何れかがプルダウンメニューとして表示され、ユーザはその中から検索したい属性情報を選択することになる。
【００７８】
上記の各種入力が終了すると、入力ボタン１００３及び１００４によって、検索条件を入力する。
ボタン１００３は、条件のＡＮＤで検索することを示し、ボタン１００４は、条件のＯＲで検索することを示す。
ユーザは、上記検索条件を入力した後、検索開始ボタン１００５により検索を実行する。
【００７９】
図１２は、上記検索入力画面の具体例を示す図である。
上記図１２では、属性情報としてデバイスがプリンタで、且つ、カラー出力が可能であるデバイスの検索を行うことになる。
また、階層型位置情報として、例えば、設置フロアが２階であるプリンタを検索する場合には、“１００１ｃ”へ「フロア」を入力し、“１００２ｃ”へ「２Ｆ」を入力すればよい。さらに、２階フロアの、より詳細な場所を指定して検索したい場合には、例えば、“１００１ｃ”へ「ブロック」を入力し、“１００２ｃ”へ「２−１」を入力して検索を実行すれば、設置ブロックが２−１であるプリンタの検索を行うことができる。
【００８０】
図１３は、上記検索の例の検索条件を表した式を示す図である。
上記図１３では、デバイス端末装置（ＤＶ）がプリンタ（ｐｒｎｔｅｒ）で、カラー出力（ｃｏｌｏｒ）が可能（ＴＲＵＥ）である条件を示している。
【００８１】
ここで、上記図１３に示した検索条件式を受信したサーバ装置１１２が、「ＦＬ＝２Ｆ」という式をどのように評価するかについて説明する必要がある。なぜならば、２Ｆフロアという位置条件は、ユーザが所望している検索対象である「東京支店のＡＡビル」の２Ｆに設置されているデバイスが満足するのみならず、「大阪支店のＹＹビル」の２Ｆに設置されているデバイスもその条件を満足する。このため、ユーザにとっては興味が無い「大阪支店のｗビル」のデバイスまでも検索ヒットすることになってしまい、ユーザにとって極めてわかり難い検索結果が出力されてしまう。
【００８２】
そこで、上記の状況を回避するためには、フロア階層（ＦＬ）より上位階層が自動的に特定される仕組みをサーバ装置１１２が備えている必要がある。
この仕組みの一例として、サーバ装置１１２自身の階層型位置情報を保持させてフロア階層（ＦＬ）から上の階層の検索条件については、サーバ装置１１２の階層型位置情報を適用する方法がある。
【００８３】
上記の方法によれば、「東京支店のＡＡビル」に設置されているサーバ装置１１２に対して、「ＦＬ＝２Ｆ」の条件で検索依頼を発行すると、ＡＡビルの２Ｆフロアのデバイスのみを検索対象とすることが可能となる。
また、「大阪支店のＹＹビル」の２Ｆに設置されているデバイスを検索対象としたい場合には、「大阪支店のＹＹビル」に設置されているサーバ装置１１２に対して「ＦＬ＝２Ｆ」の条件で検索依頼を発行すればよい。
【００８４】
尚、上記図１２に示した画面では、１の階層のみを指定すれば指定階層からのみだが、最上位層（Ｃ）から所定階層までを指定する所謂フルパス指定にしてもよい。
この場合、上記図１３に示した検索条件式は、最上位階層からのフルパス指定（例えば、Ｃ：ＪＰ、Ｏ＝ＡＢＣ、ＢＲ＝東京支店…）となる。
このようなフルパス指定を用いれば、「東京支店のＡＡビル」に設置されているサーバ装置１１２により、「大阪支店のＹＹビル」の２Ｆに設置されているデバイスを検索させることも可能となる。
【００８５】
図１４は、上記図１３に図示した検索条件式に合致するデバイスをサーバ装置１１２がクライアント装置１１１へ返送する検索結果の一例である。
サーバ装置１１２は、クライアント装置１１１から受信した上記図１３の検索条件式に基づいて、データベース８００（上記図９参照）内を検索して、合致したデバイス情報を検索結果１３００としてクライアント装置１１１へ返送する。
検索結果１３００には、階層型位置情報１３０１〜１３１０とデバイス属性情報１３１１〜１３１２とが含まれておいる。
検索条件に合致するデバイスが複数存在する場合には、検索結果１３００には、複数のデバイスの階層型位置情報１３０１〜１３１０とデバイス属性情報１３１１〜１３１２と含まれることになる。
【００８６】
ここでは、一例として、上記図１３に図示した検索条件式に合致するデバイスがＬＢＰ１１１０のみであることから、上記図１４に示した検索結果１３００の情報のみがクライアント装置１１１へ返送されることになる。
【００８７】
図１５は、クライアント装置１１１が有する階層型位置情報のブロック階層（ＢＬ）とレイアウトビットマップ（ｂｉｔｍａｐ）の対応リストである。
このような対応リストを用いることにより、クライアント装置１１１側で、階層型位置情報からレイアウトビットマップを特定することが可能となる。
【００８８】
本実施の形態では、ブロック１−１，１−２，２−１，２−２のそれぞれに対応して、図１６、図１７、図１８、及び図１９に示すようなレイアウトビットマップを保持している。
また、その他のブロックについては、図２０のレイアウトビットマップを表示することになる。
【００８９】
すなわち、上記図１６〜上記図１９は、各ブロック階層に対応するレイアウトビットマップを示したものである。
本実施の形態では、これらのレイアウトビットマップ上に検索したデバイスを示す情報を重ねて表示することによって、検索要求があったデバイスがどのフロアのどのブロックのどの位置にあるかを視覚的に示すことができるようにしている。
【００９０】
上記図２０は、デバイスが階層型位置情報を保持していない場合や、クライアント装置１１１が有するレイアウトビットマップが合致しない場合に表示するレイアウトビットマップ（以下、「ｕｎｋｎｏｗｎＭＡＰ」と言う）である。
上記図２０において、“１９０１”のエリアにはレイアウトビットマップがないことを示し、“１９０２”のエリアには階層型位置情報を持たない、又は階層型位置情報が合致しないデバイスを表示させる。
【００９１】
図２１は、クライアント装置１１１が保持している、各デバイスを表示するためのデバイスアイコンである。
ここでのデバイスアイコンは、各デバイス名（ＮＭ）と一対一で対応づけられており、デバイス名が不明なものに対しては、ｕｎｋｎｏｗｎを示すデバイスアイコンが表示されることになる。
【００９２】
図２２は、クライアント装置１１１が、レイアウトビットマップ上にデバイスアイコンを表示する仕組みを示した図である。
クライアント装置１１１は、サーバ装置１１２から取得した検索結果から階層型位置情報とデバイス属性情報を抽出し、それぞれに対応したレイアウトビットマップとデバイスアイコンとを選択する。そして、クライアント装置１１１は、上記抽出した階層型位置情報から、上記選択したレイアウトビットマップの座標情報を得ることができるので、例えば、上記選択したレイアウトビットマップの座標「１０Ｘ＋１０Ｙ」へカラープリンタ１０１（ＬＢＰ１１１０）を表すデバイスアイコン２００２を重ねて表示する。
このようにレイアウトビットマップの対応する座標へデバイスアイコンを重ねて表示することにより、検索要求があったデバイスの位置をユーザにわかりやすく示すことが可能となる。
【００９３】
図２３は、デバイス検索の結果、クライアント装置１１１にて表示されるビットマップの一例を示している。この表示により、カラー出力可能なプリンタ１０１は、２Ｆの２−１ブロックの入り口に近いテーブル付近にあることが分かる。
【００９４】
図２４は、本実施の形態におけるカラーＬＢＰ１１１０（上記図２のプリンタ１０１）の内部構成を示すブロック図である。
上記図２４に示すように、プリンタ１０１は、システムバス２３０１に対して、プログラムを処理するＣＰＵ２３０２、プログラムが格納されているＲＯＭ２３０３、及びプログラムのワーク領域やバッファ領域等となるＲＡＭ２３０４等が接続された構成としている。
【００９５】
また、上記図２４において、“２３０５”は、ＬＢＰエンエンジンコントローラであり、このコントローラ２３０５を介して、エンジン２３０９が接続されている。
“２３０６”は、パネルコントローラであり、このパネルコントローラ２３０６は、パネル２３１０ヘの入出力をコントロールし、パネル２３１０を管理している。
【００９６】
さらに、本実施の形態におけるカラーＬＢＰ１１１０は、ハードディスク（ＨＤ）２２１１を保持し、印刷データを一時的にＨＤ２２１１内にスプールすることが可能となっている。
“２３０７”は、ディスクコントローラであり、ＨＤ２２１１を管理している。
【００９７】
“２３０８”は、ネットワークインターフェースコントローラであり、このコントローラ２３０８を介して、プリンタ１０１がネットワーク１００に接続される。
【００９８】
“２３１２”は、不揮発性ＲＡＭ（ＮＶＲＡＭ）であり、プリンタ１０１の電源が遮断されてもデータが保持される。
本実施の形態では、ＮＶＲＡＭ２３１２へ階層型位置情報や属性情報等を保持するようにしている。
【００９９】
図２５〜図２９は、本実施の形態におけるネットワークシステムでの処理手順を説明するためのフローチャートである。
以下、フローチャートを用いて、本実施の形態でのネットワークシステムの動作について具体的に説明する。
【０１００】
まず、上記図２５に示すフローチャートを用いて、デバイスの階層型位置情報の登録処理について説明する。
ここでは、一例として、プリンタ１０１（ＬＢＰ１１１０）の動作に着目してその説明をする。
【０１０１】
ＬＢＰ１１１０は、階層型位置情報および属性情報をデバイス内の不揮発性ＲＡＭ（２３１２）に保時している。ＬＢＰ１１１０のＣＰＵ２３０２は電源が投入されると、サーバ装置１１２への接続を行う（ステップＳ２８０１）。
この接続後、ＬＢＰ１１１０の不揮発性ＲＡＭ（２３１２）から階層型位置情報および属性情報を読み込み、上記図１０に示したような形式でサーバ装置１１２への登録を行う（ステップＳＳ２８０２）。
【０１０２】
上記の登録後、ＬＢＰ１１１０のＣＰＵ２３０２は、サーバ装置１１２との接続を解放する（ステップＳ２８０３）。
【０１０３】
上述のような手順を踏み、それぞれのデバイスはそれぞれ、電源投入後に、階層型位置情報及び属性情報をサーバ装置１１２へ登録する。
【０１０４】
つぎに、サーバ装置１１２の処理について、上記図２６のフローチャートを用いて説明する。
ここでは、サーバ装置１１２は、例えば、イベント駆動型のプログラムで構成され、イベントが発生するとそのイベントを解析して、対応する処理を行う。
【０１０５】
サーバ装置１１２は、電源が投入されると、最初に受信ポートをオープンする（ステップＳ２４０１）。
次に、サーバ装置１１２は、イベントを取得し（ステップＳ２４０２）、その取得したイベントが終了コマンドであるか否かを判断する（ステップＳ２４０３）。この判断の結果、上記取得したイベントが終了コマンドであった場合には、受信ポートをクローズし（ステップＳ２４０４）、本処理を終了する。
【０１０６】
一方、ステップＳ２４０３の判断の結果、終了コマンドでない場合には、サーバ装置１１２は、それが検索要求がどうかを判断する（ステップＳ２４０５）。ここで、検索要求であった場合には、ステップＳ２４０６でデータベースの検索処理を行う。
【０１０７】
一方、ステップＳ２４０５の判断の結果、検索要求ではなかった場合、サーバ装置１１２は、ステップＳ２４０７において、データベースヘの登録要求であるか否かを判断する。この判断の結果、登録要求であった場合、サーバ装置１１２は、受信したデータを、上記図９に示したテーブル８００上に登録する（ステップＳ２４０８）。この登録されたデータは、ＨＤ２１１で保持される。
また、ステップＳ２４０７の判断の結果、他の要求であった場合には、その他の処理を行う（ステップＳ２４０９）。
【０１０８】
つぎに、上記図２７を用いて、サーバ装置１１２で実行されるデータ検索処理について、より詳細に説明する。
【０１０９】
先ず、サーバ装置１１２は、全ての検索条件を処理したか否かを判断する（ステップＳ２５０１）。
この判断の結果、検索条件が全て終了するまで、本処理を繰り返すことになる。
【０１１０】
ステップＳ２５０１の判別の結果、受信パケット内の全ての検索条件を検索し終わった場合、サーバ装置１１２は、その結果をクライアント装置１１１へ送信し（ステップＳ２５０２）、本処理終了とする。
【０１１１】
ステップＳ２５０１の判別の結果、受信パケット内の全ての検索条件を検索し終えていない場合、サーバ装置１１２は、受信パケットから検索条件を取り出す（ステップＳ２５０３）。
そして、サーバ装置１１２は、その検索条件について、上記図９に示したテーブルの全ての登録デバイス情報を検索したかを判断する（ステップＳ２５０４）。
【０１１２】
ステップＳ２５０４の判断の結果、全ての登録デバイス情報を検索した場合、サーバ装置１１２は、次の検索条件を取り出すために、ステップＳ２５０１へ戻る。
【０１１３】
ステップＳ２５０４の判断の結果、全ての登録デバイス情報を検索し終えていない場合、サーバ装置１１２は、ｎ個目のデバイス情報をＨＤ２１１から取り出す（ステップＳ２５０５）。
そして、サーバ装置１１２は、上記取り出したデバイス情報が条件に一致したかどうかを判断する（ステップＳ２５０６）。
【０１１４】
ステップＳ２５０６の判断の結果、一致した場合には、サーバ装置１１２は、そのデバイス情報を取得し（ステップＳ２５０７）、結果に追記する（ステップＳ２５０８）。その後、ステップＳ２５０４へ戻る。
【０１１５】
ステップＳ２５０６の判断の結果、一致しなかった場合には、サーバ装置１１２は、次のデバイスについて処理を行うために、ステップステップＳ２５０４へ戻る。
【０１１６】
上述のような処理により、サーバ装置１１２は、それぞれの検索条件について、上記図９に示したテーブル８００内のデバイスを全て検索し、その結果をクライアント装置１１１へ送信する。
【０１１７】
つぎに、上記図２８を用いて、クライアント装置１１１での全体動作について説明する。
ここでは、クライアント装置１１１は、例えば、イベント駆動型のプログラムで構成され、イベントが発生するとそのイベントを解析して、対応する処理を行う。
【０１１８】
先ず、クライアント装置１１１は、イベントの取得を行う（ステップＳ２６０１）。ここで、終了コマンドのイベントを受信した場合には、そのまま終了する（ステップＳ２６０２）。
【０１１９】
クライアント装置１１１では、上記図１１に図示したような検索条件入力画面より、ユーザから検索条件が入力されることになる。ユーザが検索開始ボタン１００５をクリックすることによって、そのイベントが発生することになる。
【０１２０】
ステップＳ２６０３で検索コマンドの発行要求であった場合には、クライアント端末装置１１１は、検索要求をサーバ装置１１２へ送信する（ステップＳ２６０４）。
【０１２１】
このとき、上記図１２及び上記図１３に示したような検索条件式をもって、サーバ端末装置１１２へ問い合わせることになる。また、この検索条件式をＨＤ２１１に保存しておくことによって、次回のデバイス検索時には、当該条件式用いることができる。この場合、ユーザからの検索条件再入力を省くことが可能となる。
【０１２２】
次に、クライアント装置１１１は、サーバ装置１１２からの検索結果待ちとなり、そのイベントを受信した場合にはステップＳ２６０５で判断する。
ステップＳ２６０５の判断において、上記図１４に示したような検索結果を受信した場合、検索結果表示処理を行う（ステップＳ２６０６）。
また、その他のイベントを受信した場合には、他の処理を行うことになる（ステップＳ２６０７）。
【０１２３】
つぎに、上記図２９のフローチャートを用いて、上記図２８のステップＳ２６０６での検索結果表示処理をより詳細に説明する。
【０１２４】
先ず、最初のステップＳ２７０１で、全ての検索結果を処理し終わったかどうかを判断する。この判断の結果、全ての処理が終わったと判断した場合には、本処理終了とする。
【０１２５】
一方、ステップＳ２７０１の判断の結果、全ての処理が終わっていない場合には、ステップＳ２７０２に進み、受信した検索結果から階層型位置情報を取得する。そして、上記取得した階層型位置情報を元に、クライアント装置１１１がマップの表示が可能かどうかを判断する（ステップＳ２７０３）。
【０１２６】
本実施の形態では、デバイスを表示可能な階層型位置情報は、上記図１５において符号“１４０１”で示した情報を含む階層型位置情報である。これを含まない階層型位置情報であった場合には、ｕｎｋｎｏｗｎＭＡＰが表示済みであるかどうかを確認し（ステップＳ２７０９）、上記図２０に図示したｕｎｋｎｏｗｎデバイスを表示する（ステップＳ２７１０）。
【０１２７】
さらに、階層型位置情報からＮＭ情報を取得し（ステップＳ２７１１）、上記図２０において符号“１９０２”のエリアへＮＭに対応するデバイスアイコンを表示する。この場合、デバイスが正常に表示されなかった、すなわち、階層型位置情報がまだ登録されていないデバイスがここに表示されることになる
【０１２８】
一方、ステップＳ２７０３でデバイス端末表示可能と判断された場合には、階層型位置情報内のＢＬ情報を取得する（ステップＳ２７０４）。クライアント装置１１１は、ＢＬ情報を、上記図１５に示したＢＬ情報テーブルと照らし合わせて、必要なレイアウトビットマップを表示しようとするのである。
【０１２９】
ここで、対応したレイアウトビットマップが既に表示済みであるかどうかを判断する（ステップＳ２７０５）。この判断の結果、未だ表示していない場合には、対応するビットマップを表示する（ステップＳ２７０６）。そして、階層型位置情報からＮＭ情報とマップ情報を取得する（ステップＳ２７０７）。
【０１３０】
また、ステップＳ２７０５の判断の結果、表示済みであった場合には、ステップＳ２７０７に進む。ＮＭ情報から対応するデバイスアイコンを、上記図２１のテーブルから読み込む。また、マップ情報からそのデバイスアイコンをどこに表示するかを決定する。
【０１３１】
本実施の形態では、サーバ装置１１２より、検索結果として上記図１４に示したような結果が返送されてきているので、ＮＭはＬＢＰ１１１０であり、そのデバイスは「１０Ｘ＋１０Ｙ」であることから、上記図２２に示したような位置にデバイスアイコンを表示する（ステップＳ２７０８）。このデバイスアイコンを、先のレイアウトマップに重ねて表示すること１こよって、上記図２３に示したような検索結果がクライアント装置１１１のディスプレイに表示される。
【０１３２】
上述のような処理により、上記図５〜上記図８に示したようなレイアウトビットマップにがクライアント装置１１１のディスプレイ上に表示され、ユーザは検索されたデバイスの詳細な位置情報を得ることができる。
その後、クライアント装置１１１のユーザは、検索された複数のデバイスから所望のデバイスを選択して、その選択したデバイスに対してジョブを送信する。例えば、デバイスがプリンタであれば印刷ジョブを送信し、デバイスがＦＡＸであれば送信ジョブ等を送信する。
【０１３３】
図３０は、クライアント装置１１１が発行する印刷ジョブ情報の一例を示す図である。
上記図３０において、“３１０１”は、以下に続く情報がジョブ属性情報であることを示すジョブ特性ＴＡＧである。“３１０２”〜“３１０５”には、印刷ジョブ情報が続いている。
“３１０２”は、ジョブを投入されたデバイスやクライアント装置１１１がジョブを特定するためのジョブＩＤてあり、上記図３０では、ジョブＩＤが「１２３４」であることを示している。
【０１３４】
図３１は、デバイスが受信したジョブを管理するためのジョブ管理テーブル３２００である。
ジョブ管理テーブル３２００には、各ジョブごとにクライアント装置１１１へ通知すべきイベント条件と、その通知先のネットワークアドレス等とが対応付けて記憶されている。
【０１３５】
デバイスは、上記図３０に示した印刷ジョブを受信すると、当該ジョブに記述された情報に基づいて、当該ジョブをジョブ管理テーブル３２００へ記憶する。そして、デバイスは、ジョブを実行し、クライアント装置１１１へ通知すべきイベントの発生を検出すると、当該イベントをクライアント装置１１１へ通知する。
【０１３６】
図３２は、デバイスからクライアント装置１１１へ通知されるイベント通知のフォーマットの一例を示している。
このイベント通知フォーマット３３０１は、印刷ジョブが終了したときに「ＴＣＰ／ＩＰ：１９２．１．２．１６：１０２５」で示されるクライアント装置へイベント通知行うものであり、上記図１４で示した階層型位置情報３３０２が付加されている。
【０１３７】
図３３は、「ＪＯＢ ＩＤ＝１２３４］のジョブが終了したときに、クライアント装置１１１の表示装置２７上に表示される画面の一例を示したものである。
上記図３３では、印刷が終了したことを文字情報（「印刷を終了しました…」で表示されている。
【０１３８】
図３４は、クライアント装置１１１において、上記画面表示に至るまでの処理手順を示すフローチャートである。
【０１３９】
先ず、イベント通知受信処理が開始されると、最初のステップＳ３５０１において、入力情報がイベント通知か否かを判断する。この判断の結果、入力情報がイベント通知でなかった場合には本処理を終了する。
【０１４０】
また、上記入力情報がイベント通知であった場合にはステップＳ３５０２に進み、受信したイベント情報３３０１からロケーション情報（階層型位置情報）を取得する。そして、上記取得した階層型位置情報を元に、クライアント装置１１１がレイアウトビットマップの表示が可能かどうかを判断する（ステップＳ３５０３）。
【０１４１】
本実施の形態でが、デバイスを表示可能な階層型位置情報は、上記図１５にて符号“１４０１”で示した情報を含む階層型位置情報である。これを含まない階層型位置情報であった場合には、上記図２０に図示したｕｎｋｎｏｗｎＭＡＰを表示する（ステップＳ３５１０）。
【０１４２】
さらに、階層型位置情報からＮＭ情報を取得し（ステップＳ３５１１）、上記図２０に示した符号“１９０２”のエリアへＮＭに対応するデバイスアイコンを表示する（ステップＳ３５１２）。この場合には、デバイスが正常に表示されなかった、すなわち階層型位置情報がまだ登録されていないデバイスがここに表示されることになる。
【０１４３】
一方、ステップＳ３５０３でデバイス端末表示可能と判断された場合には、階層型位置情報内のＢＬ情報を取得する（ステップＳ３５０４）。そして、クライアント端末装置１１１は、上記取得したＢＬ情報を、上記図１５に図示したＢＬ情報テーブルと照らし合わせて、必要なレイアウトビットマップを表示する（ステップＳ３５０５）。
【０１４４】
上述のような処理を行うことにより、上記図３３でに示したような、「印刷を終了しました。ＪＯＢ ＩＤ＝１２３４」等の、発生したイベント情報をユーザに分かりやすく表示することが可能となる。
【０１４５】
次に、階層型位置情報からＮＭ情報とマップ情報を取得する（ステップＳ３５０６）。本実施の形態では、ＮＭはＬＢＰ１１１０であり、そのデバイスアイコンにより示されるデバイスの座標が「１ＯＸ＋１０Ｙ」であることから、上記図２２に示したような位置にデバイスアイコンを表示する（ステップＳ３５０９）。このデバイスアイコンを、先のレイアウトマップへ重ねて表示することによって、イベント通知を発行したデバイスを、上記図２３に図示したように表示することが可能となる。
【０１４６】
図３５は、デバイスにおける全体動作を示すフローチャートである。
先ず、最初のステップＳ３６０１でイベントの取得を行う。そして、上記取得したイベントが終了コマンドのイベントであるか否かを判断する（ステップＳ３６０２）。この判断の結果、上記受信したイベントが終了コマンドであった場合にはそのまま本処理を終了する。
【０１４７】
一方、ステップＳ３６０２の判断の結果、上記受信したイベントが終了コマンドでなかった場合には、ステップＳ３６０３へ進み、それがイベント登録要求であるか否かを判断する。この判断の結果、そうならばステップＳ３６０４に進みイベント登録処理を行う。
【０１４８】
一方、ステップＳ３６０３の判断の結果、イベント登録要求でない場合にはステップＳ３６０３からステップＳ３６０５へ進み、ジョブ処理要求を受信したか否かを判断する。この判断の結果、ジョブ（印刷ジョブ）処理要求であった場合にはステップＳ３６０６へ進み、印刷処理を実行する。また、ステップＳ３６０５の判断の結果、上記受信したイベントがジョブ処理要求でなかった場合にはステップＳ３６０７に進んで他の処理を行う。
【０１４９】
図３６は、デバイスでのイベント発生時の処理手順を示すフローチャートである。
先ず、イベントが発生したら、それがジョブ関係のイベントであるか否かを判断する（ステップＳ３７００）。
【０１５０】
次に、ステップＳ３７０１に進み、対応する「ＪＯＢ ＩＤ」の通知条件を判断する。この判断の結果に基づいて、ステップＳ３７０１において条件が一致したか否かを判断し、一致した場合には場合にはステップＳ３７０３に進み、階層型位置情報を取得する。
【０１５１】
次に、ステップＳ３７０４に進み、通知パケットを作成し、この作成した通知パケットを指定されたアドレスに通知する（ステップＳ３７０５）。
次に、ステップＳ３７０６において、ジョブが終了か否かを判断し、終了の場合にはステップＳ３７０７へ進みジョブ管理テーブル（上記図３１参照）から該当する「ＪＯＢ ＩＤ」のエントリを削除する処理を行う。
【０１５２】
上述のように、本実施の形態によれば、ユーザが発行したジョブについてのイベント情報を、そのイベントが発生したデバイスの場所とともにわかりやすく通知することが可能となる。
特に、クライアント装置１１１がユーザを介さず自動時にジョブの依頼先のデバイスを選択するような場合には、そのユーザにとって設置場所がわからないデバイスが選択されることもある。このような場合に、そのユーザに対して、わかりやすいデバイスの位置を通知することが可能となる。
【０１５３】
尚、デバイスに依頼されたジョブは、そのジョブについてのイベントの通知先であるクライアント装置１１１から直接依頼されたジョブに限らない。すなわち、クライアント装置からのジョブが第３の装置から転送されたものであってもよい。
【０１５４】
＜第２の実施の形態＞
第１の実施の形態では、検索されたデバイスの位置を表現するためのレイアウトビットマップをクライアント装置１１１が保持しているように構成したが、本実施の形態では、レイアウトビットマップをサーバ装置１１２が保持する。
【０１５５】
尚、本実施の形態は、第１の実施の形態をベースとしているため、ここでは、第１の実施の形態と異なる構成について具体的に説明する。
【０１５６】
本実施の形態では、上記図１６〜上記図２０で示したレイアウトビットマップ、上記図１５で示した階層型位置情報とレイアウトビットマップの対応テーブル、及び上記図２１で示したデバイスアイコンの情報は、サーバ装置１１２のハードディスクに格納されている。
そこで、まず、クライアント装置１１１の動作について、第１の実施の形態と異なる部分を説明する。
【０１５７】
図３７は、クライアント装置１１１の検索結果表示の処理を示すフローチャートである。
最初のステップＳ５００１で、すべての検索結果を処理し終わったかどうかを判断する。この判断の結果、全ての処理が終わったと判断した場合にはその処理は終了となる。
【０１５８】
一方、ステップＳ５００１の判断の結果、全ての処理が終わっていない場合には、ステップＳ５００２に進み、受信した検索結果から階層型位置情報を取得する。
次に、サーバ装置１１２へ接続し（ステップＳ５００３）、上記取得した階層型位置情報に対応するマップ情報を取得する（ステップＳ５００４）。
【０１５９】
次に、階層型位置情報に対応したマップは表示済か否かを判断する（ステップＳ５００５）。この判断の結果、未だ表示していない場合には対応したレイアウトマップを取得する（ステップＳ５００６）。
さらに、階層型位置情報からＮＭ情報とマップ情報を取得し（ステップＳ５００７）、上記取得したＮＭ情報とマップ情報に対応したデバイスビットマットを取得する（ステップＳ５００８）。
【０１６０】
次に、上記取得したデバイスビットマットをマップ上の所定位置に表示し（ステップＳ５００９）、その後にサーバ装置１１２との接続を切断する（ステップＳ５０１０）。
【０１６１】
図３８は、クライアント装置１１１がデバイスから受信したイベント通知に基づいて表示を行う処理のフローチャートである。
先ず、イベント通知受信処理が開始されると、ステップＳ５１００において、入力情報がイベント通知か否かを判断する。この判断の結果、入力情報がイベント通知でなかった場合には処理を終了する。
【０１６２】
一方、上記入力情報がイベント通知であった場合にはステップＳ５１０１に進み、サーバ装置１１２へ接続する。
次に、対応したマップが表示済みか否かを判断し、まだ表示していない場合には対応したレイアウトビットマップをサーバ装置１１２から取得する（ステップＳ５１０３）。
さらに、階層型位置情報からＮＭ情報を取得し（ステップＳ５１０４）、対応したデバイスアイコンを取得する（ステップＳ５１０５）。
【０１６３】
次に、上記取得した情報に基づいて、デバイスアイコンを受信した座標情報に基づいてレイアウトマップ上に表示する（ステップＳ５１０６）。
【０１６４】
次に、サーバ装置１１２との接続を切断するとともに（ステップＳ５１０７）、イベント情報と「ＪＯＢ ＩＤ」を取得する。そして、上記取得したイベント情報及び「ＪＯＢ ＩＤ」を表示する。これにより、上記図３３に示したような表示を実現することができる。
【０１６５】
つぎに、サーバ装置１１２の動作について、第１の実施の形態と異なる部分を説明する。
【０１６６】
図４０は、サーバ装置１１２におけるレイアウトビットマップの検索処理を示したフローチャートである。
先ず、最初のステップＳ５２０１において、検索要求がレイアウトマップの検索要求であるか否かを判断する。
【０１６７】
上記の判断の結果、レイアウトマップの検索要求であった場合にはステップＳ５２０２に進み、クライアント装置１１１から受信した階層型位置情報はマップ表示可能か否かを判断する。そして、表示可能であると判断した場合にはステップＳ５２０３において、上記図１５に示した対応テーブルから該当するレイアウトビットマップをロードし、上記取得したマップをクライアント装置１１１に返送して処理を終了する。
【０１６８】
一方、ステップＳ５２０２の判断の結果、マップ表示が不可能である場合には、ステップＳ５２０５に進み、上記図２１に示したｕｎｋｏｗｎＭＡＰを表示する。
【０１６９】
また、ステップＳ５２０１の判断の結果、検索要求がレイアウトマップの検索要求でなかった場合には、ステップＳ５２０６に進んでデバイスアイコンの検索要求であるか否かを判断する。
【０１７０】
上記の判断の結果、デバイスビットマップの検索要求であった場合には、ステップＳ５２０７に進み、上記図２１に示したテーブルから該当するデバイスアイコンをロードして、クライアント装置１１１へ返送する（ステップＳ５２０４）。
【０１７１】
尚、第１の実施の形態では、レイアウトビットマップをクライアント装置１１１に保時させるように構成したので、検索結果をクライアント装置１１１で表示するときに、サーバ装置１１２からクライアント装置１１１へレイアウトビットマップを転送しなくても済み、表示を行う際の処理及び時間を軽減することができるとともに、ネットワークシステムのトラフィックを軽減することができるという効果がある。
一方、本実施の形態では、レイアウトビットマップをサーバ装置１１２が保するように構成したので、サーバ装置１１２においてマップ情報を一元で管理することができ、クライアント装置１１１ごとにマップ情報を保持する必要を無くして、更新等のメンテナンスを容易にできるとともに、クライアント装置１１１のメモリリソースの負荷を減らすことができるという効果がある。
したがって、ネットワーク１００の負荷やクライアント装置１１１の能力等を考慮することで、適宜、第１の実施の形態或いは本実施の形態を採用すればよい。
【０１７２】
＜第３の実施の形態＞
第１及び第２の実施の形態では、ブロック（ＢＬ）階層に対応したレイアウトビットマップのみを保持するように構成したが、本実施の形態では、階層型位置情報の各階層に対応するレイアウトビットマップを保持して、それをクライアント装置１１１の検索結果表示に反映する。
本実施の形態によれば、建物レベルのラフな位置情報から、フロアの１区画のような詳細な位置情報まで、ユーザの好みに応じた階層のレイアウトビットマップに検索されたデバイスを表示させることが可能となる。
【０１７３】
尚、本実施の形態では、第１の実施の形態のようにレイアウトビットマップをクライアント装置１１１が保持するものとするが、第２の実施の形態のようにレイアウトビットマップをサーバ装置１１２が保時するようにしてもよい。
【０１７４】
図４０は、検索する各階層に対応するＭＡＰリストである。
上記図４０の下半分のリストは、上記図１５に相当するリストである。
本実施の形態では、デバイスビットマップを表示する場合、検索する階層の属性のすぐ下の属性情報に基づいて、デバイスを表示する。階層の上下関係については、上記図４に示した階層の上下関係と同様である。
【０１７５】
例えば、ＢＵ＝ＡＡビルですべてのデバイスを検索する場合には、そのすぐ下の属性ＦＬ（上記図４参照）をそのデバイスを表示するための位置情報として、レイアウトマップ上に表示する。
【０１７６】
例えば、ＡＢＣ商事にある全てのデバイスの検索を行う場合、上記図１１に示した入力画面上で、“１００１ａ”に会社名（Ｏ）をプルダウンメニューから選択し、その属性値として“１００２ａ”にＡＢＣ商事を入力して、検索開始ボタン１００５により検索開始をユーザーが実行する。
【０１７７】
クライアント装置１１１は、上述したような手順によって、検索結果をサーバ装置１１２から取得し、当該検索結果に基づき、デバイスビットマップをレイアウトビットマップに表示する。
【０１７８】
このときのクライアント装置１１１での表示処理は、図４１のフローチャートで示される。
先ず、本処理が開始されると、最初のステップＳ６００１で検索結果全ての表示が終了したか否かを判断し、処理が終わるまで、本処理を全て繰り返すことになる。
【０１７９】
ステップＳ６００１の判断の結果、検索を全て終了していない場合には、ステップＳ６００２において、検索結果から属性ＮＭを取得する。これは、ステップＳ６００８やステップＳ６０１０、或はステップＳ６０１３でデバイスアイコンを表示するために行う処理である。
【０１８０】
次に、ステップＳ６００３で検索した条件の属性に対応したレイアウトビットマップが表示済みかどうかを判断する。この例では、属性Ｏ＝属性値ＡＢＣ商事で検索実行したことから、ＭＡＰ対応リスト（上記図４１参照）から得られる、図４２に示すようなレイアウトビットマップ上に、検索結果のデバイスを表示することになる。
上記図４２のレイアウトビットマップが表示済みかどうかを判断する。この判断の結果、まだ表示していない場合には、ステップＳ６００４において表示を行い、ステップＳ６００５の処理に移行する。
【０１８１】
ステップＳ６００３の判断の結果、上記図４２のレイアウトビットマップをすでに表示済みであった場合にはステップＳ６００５の処理で、検索した属性の下層属性と属性値を検索結果から取得する。この取得した属性値が表示可能かどうかをステップＳ６００６で判断する。属性値の範囲外だったものや、属性値が入力されていないデバイスは表示不可能ということでステップＳ６０１１に進む。
【０１８２】
ステップＳ６０１１では、ｕｎｋｎｏｗｎＭＡＰが表示済みかどうかを判断し、未表示であった場合には、ステップＳ６０１２でｕｎｋｎｏｗｎＭＡＰを表示し、ステップＳ６００２で獲得したＮＭ値に対応するデバイスアイコンをｕｎｋｎｏｗｎＭＡＰのデバイス欄に表示することになる（ステップＳ６０１３）。
【０１８３】
一方、ステップＳ６００６の判断の結果、表示可能であった場合には、下層属性がＭＡＰ属性がどうかを判断する（ステップＳ６００７）。この判断の結果、ＭＡＰ属性でなかった場合には、ステップＳ６００８に進み、表示しているレイアウトビットマップ上の属性位置にステップＳ６００２で取得したＮＭ値に対応するデバイスアイコンを重ねて表示する。この場合、階層型ロケー一ション情報で（Ｏ）の階層下の階層ＢＲの属性値が、東京支店であることから（上記図４参照）、各デバイスは東京支店５００１の位置上に表示されることになる。その結果、上記図４２に示すような表示を得ることになる。
【０１８４】
また、より詳細にデバイスの位置を検索する場合、上記図１１に示した入力画面上で、“１００１ａ”にブロック名（ＢＬ）をプルダウンメニューから選択し、その属性値として“１００２ａ”へ２−１を選択し、検索開始ボタン１００５によりユーザが当該検索開始を実行する。
【０１８５】
クライアント装置１１１は、上述したような手順で、検索結果をサーバ装置１１２から取得する。サーバ装置１１２から獲得した検索結果に基づき、クライアント装置１１１は、デバイスビットマップをレイアウトビットマップ上に表示する。この時も、同様に、上記図４１で示される処理フローを実行する。この場合、スナッブＳ６００７で下層属性情報が、ＭＡＰ情報であることからステップＳ６００９に進む。
【０１８６】
ステップＳ６００９では、その座標範囲がレイアウトビットマップの範囲内かどうかを判断する。そして、範囲内であった場合には、ステップＳ６０１０で、表示しているレイアウトビットマップの座標位置にステップＳ６００２で獲得したＮＭ値に対応するデバイスアイコンを重ねて表示する。
【０１８７】
この場合、属性ＢＬ、属性値２−１で検索実行したことから、ＭＡＰ対応リスト（上記図４０参照）から得られる上記図１８のレイアウトビットマップ上に、検索結果のデバイスを表示することになる。
【０１８８】
階層ロケーション情報のＢＬの階層下の階層ＭＡＰであることから（上記図４参照）、検索結果の各デバイスは、そのレイアウト上の座標上に表示されることになる。この結果、上記図５に示したような表示を得ることになる。
【０１８９】
ここで、その他の各階層のレイアウトビットマップ図について説明する。
上述した説明したように、上記図４３は、属性Ｏ＝属性値ＡＢＣ商事で検索する場合のレイアウトビットマップを示したものである。属性Ｏの下層属性ＢＲが東京支店であるデバイスは５００１に表示され、大阪支店であるデバイスは５００２に表示される。
【０１９０】
図４３は、属性Ｏ＝属性値ＡＢＣ商事ですべてのデバイスを検索したときの結果表示である。
【０１９１】
図４４は、属性ＢＲ＝属性値東京支店で検索する場合のレイアウトビットマップである。属性値ＢＲの下層属性はＯＰであるが、これはＯＰＴＩＯＮがあることを示し、さらにもう一層下に詳細情報があることを示している。その属性ＢｕがＡＡビルであるデバイスは５２０１に表示される。
【０１９２】
図４５は、属性ＢＲ＝属性値東京支店ですべてのデバイスを検索したときの検索結果表示であり、ビル５３０２が表示される。
【０１９３】
図４６は、属性ＢＵ＝属性値ＡＡビルで検索した場合のレイアウトビットマップである。属性ＢＵの下層属性ＦＬが２Ｆであるデバイスはビットマップ５４０２に表示され、１Ｆであるデバイスはビットマップ５４０１に表示される。
【０１９４】
図４７は、属性ＢＵ＝属性値ＡＡビルですべてのデバイスを検索したときの結果の表示であり、２Ｆのビットマップ５５０２内に存在するデバイス、及び１Ｆのビットマップ５５０１内に存在するデバイスが全て表示される。
【０１９５】
図４８は、属性ＦＬ＝属性値２Ｆで検索した場合のレイアウトビットマップである。属性ＦＬの下層属性ＢＬが２−１であるデバイスはビットマップ５６０１に表示され、２−２であるデバイスはビットマップ５６０２に表示される。
【０１９６】
図４９は、属性ＦＬ＝属性値２Ｆですべてのデバイスを検索したときの結果表示であり、２Ｆ−１のビットマップ５７０１及び２Ｆ−２のビットマップ５７０２に存在するデバイスが全て表示される。
【０１９７】
図５０は、属性ＦＬ＝属性値１Ｆで検索した場合のレイアウトビットマップである。また、図５１は、属性ＦＬ＝属性値１Ｆで全てのデバイスを検索したときの結果の表示である。属性ＦＬの下層属性ＢＬが１−２であるデバイスはビットマップ５９０１１こ表示され、１−１であるデバイスはビットマップ５９０２に表示される。
【０１９８】
上述のように、本実施の形態によれば、ユーザーの検索要求レベルに応じて、詳細な表示から、おおまかな表示まで、ロケーション情報の各階層に応じた、検索とその表示を行うことが可能になる。
【０１９９】
＜第４の実施の形態＞
本実施の形態では、ネットワーク１００上のデバイスの位置をわかりやすくユーザに通知するとともに、そのデバイスの状態をユーザに通知する。
また、本実施の形態では、デバイスの状態をデバイスからポーリングすることにより取得する。
【０２００】
尚、本実施の形態は、第１の実施の形態をベースとするため、ここでは、第１の実施の形態と異なる構成について具体的に説明する。
【０２０１】
図５２は、クライアント装置１１１において各デバイスのデバイスアイコン情報を管理する管理テーブルを示したものである。
ここでのデバイスアイコン情報は、各デバイスごとにその状態を表す数種類のアイコン情報で構成される。
したがって、クライアント装置１１１は、デバイスから取得した状態に応じたデバイスアイコンを、上記図５２の管理テーブルから選択してレイアウトビットマップに表示する。
尚、上記図５２では、デバイス以外のＰＣ等のアイコンについても示されている。
【０２０２】
上記図５２では、各デバイス毎に、稼働中（Ｒｅａｄｙ）、紙切れ（Ｎｏ Ｐａｐｅｒ）、紙詰まり（Ｐａｐｅｒ Ｊａｍｍｅｄ）のそれぞれの状態に応じたデバイスアイコン情報が示されている。
それぞれのデバイスアイコン情報は、各デバイス名（ＮＭ）と対応づけられており、デバイス名が不明なものに対しては、ｕｎｋｎｏｗｎを示すデバイスアイコンが表示されることになる。
【０２０３】
図５３は、レイアウトビットマップ上に重ねて表示するデバイスアイコンの位置を示したものである。
例えば、座標情報「１０Ｘ＋１０Ｙ」のロケーション情報を持つプリンタ１０１（ＬＢＰ１１１０）は、上記図５３に示すような位置に、現在の状態に応じたビットマップアイコンの形で表示される。
上記図５３では、プリンタ１０１の状態が紙切れ（Ｎｏ Ｐａｐｅｒ）であることを示すデバイスアイコンが表示されている。
【０２０４】
上述のように、ビットマップアイコンとレイアウトビットマップとを合わせて表示することにより、検索されたデバイスの位置と当該デバイスの現在の状態とをユーザへ分かりやすく表示することが可能となる。
【０２０５】
図５４は、検索されたデバイスについて、その状態取得後にクライアント装置１１１に表示されるレイアウトビットマップを示したものである。
上記図５４に示すように、このレイアウトビットマップでは、カラー入出力が可能なプリンタ（ＬＢＰ１１１０）は２Ｆのブロック２−１の入口に近いテーブル付近にあることが視覚的に分かる。さらに、そのカラープリンタ１０１は、現在紙切れの状態であることも同時に知ることができる。
【０２０６】
図５５は、クライアント装置１１１における検索要求送信の処理を示すフローチャートである。
上記図５５に示す検索要求送信処理では、先ず最初に、上記図１２に示したような検索条件入力画面により入力された検索条件を取得し、上記図１３に示したような検索条件式の形式へと変換する（ステップＳ５６０１）。
次に、上記変換された検索条件式を含む検索要求パケットを生成し、サーバ装置１１２へ送信して問い合わせる（ステップＳ５６０２）。
【０２０７】
尚、上記検索条件式をハードディスク２１１に保存しておくことにより、次回の検索時に同じ条件でデバイス検索を行うときには、この保存しておいた検索条件式を用いることができる。これにより、ユーザが検索条件を再入力する手間を省くことも可能となる。
【０２０８】
図５６は、クライアント装置１１１のデバイス検索結果の処理を示すフローチャートである。
上記図５６において、デバイス検索の結果、検索条件に合致するデバイスが１つ以上発見されたか否かを判断する（ステップＳ５７０１）。ここで、検索条件に合致するデバイスが１つも発見されなかった場合は、該当するデバイスが発見されなかった旨のメッセージ（不図示）を表示し（ステップＳ５７０４）、本処理を終了する。
【０２０９】
一方、ステップＳ５７０１において、１つ以上のデバイスが発見されたと判断した場合は、その検索結果（該当するデバイスのロケーション情報及び属性情報）をハードディスク２１１に保存する。例えば、上記図１４に示したような検索結果が得られた場合、それをハードディスク２１１に保存することになる。その後、後述の状態取得プロセスを起動して（ステップＳ５７０３）、本処理を終了する。
【０２１０】
図５７は、上記図５６のフローチャートのステップＳ５７０３で起動される状態取得プロセスの動作を示したものである。
この状態取得プロセスは、クライアント装置１１１がある一定間隔でデバイスの状態を取得し、レイアウトビットマップ上に現在の状態に応じたデバイスアイコンを重ねて表示するためのプログラムである。
【０２１１】
状態取得プロセスが起動されると、先ず最初に、上記図５６のステップＳ５７０２でハードディスク２１１に保存された検索結果を参照し、すべての検索結果を処理し終わったかどうか、すなわち保存されている検索結果の中に含まれるすべてのＩＰアドレスのデバイスに対して状態取得の処理が終わったかどうかを判断する（ステップＳ５８０１）。
【０２１２】
ここで、全ての検索結果を処理し終わった場合には、検索処理で見つけられたデバイスの状態をある一定間隔で取得するためにポーリングタイマを起動し（ステップＳ５８１３）、その後、ステップＳ５８１４でポーリングタイマのタイムアウトイベント待ち状態となる。ポーリングタイマのタイムアウトイベントを受信すると、再びステップＳ５８０１へ進み、同様の処理を行う。
【０２１３】
ステップＳ５８０１において、処理されていない検索結果があると判断した場合は、未処理の検索結果から１デバイス分のデバイス情報（ロケーション情報や属性情報）を取得する（ステップＳ５８０２）。さらに、取得した属性情報中に含まれるＩＰアドレス宛てに状態取得要求パケット（不図示）を送信し（ステップＳ５８０３）、図５８に示されるような状態取得応答パケットの受信待ち状態となる。
例えば、上記図１４に示したような検索結果を処理する場合、ＩＰアドレスは「１９２．１．２．１」であり、このＩＰアドレス宛てに状態取得要求パケットを送信することになる。
【０２１４】
そして、ステップＳ５８０４において目的のデバイスから状態取得応答パケットを受信すると、検索結果のロケーション情報に含まれるデバイス名（ＮＭ）情報と、受信した状態取得応答パケットのデバイス状態情報とに基づいて、上記図５２に示したような各種デバイスアイコンの中から、デバイス状態に応じた適切なデバイスアイコンを選択する（ステップＳ５８０５）。
例えば、上記図１４に示したような検索結果を処理した場合、デバイス名情報は「ＬＢＰ１１１０」である。また、状態取得応答パケットのデバイス状態情報が紙切れを表す場合には、上記図５２中の“２００１”で示すビットマップアイコンが選択されることになる。
【０２１５】
次に、クライアント装置１１１が、ロケーション情報としてのブロック（ＢＬ）情報に対応したレイアウトビットマップを表示可能か否か、すなわちブロック（ＢＬ）情報に対応したレイアウトビットマップ情報を保持しているか否かを、上記図１５に示した情報テーブルを用いて判断する（ステップＳ２９０６）。
本実施の形態において、レイアウトビットマップを表示可能なロケーション情報は、上記図１４の“１４０１”で示す情報を含むロケーション情報である。これを含まないロケーション情報であった場合には、上記図２０に示したｕｎｋｎｏｗｎＭＡＰが既に表示されているか否かを判断する（ステップＳ５８１０）。
【０２１６】
ここで、まだｕｎｋｎｏｗｎＭＡＰが表示されていない場合には、上記図２０に示したエリア１９０１へｕｎｋｎｏｗｎＭＡＰを表示する（ステップＳ５８１１）。そして、上記図２０に示したエリア１９０２へ、ステップＳ５８０５にて選択したデバイスビットマップアイコンを表示する（ステップＳ５８１２）。この場合には、レイアウトマップが正常に表示されなかった、すなわちロケーション情報がまだ登録されていないデバイスのアイコンがここに表示されることになる。
【０２１７】
一方、ステップＳ５８０６でレイアウトビットマップを表示可能と判断された場合には、ロケーション情報内のブロック（ＢＬ）情報に対応するレイアウトビットマップは既に表示されているか否かを判断する（ステップＳ５８０７）。そして、まだ表示されていないと判断した場合は、上記ブロック（ＢＬ）情報に対応するレイアウトビットマップを画面上に表示する（ステップＳ５８０８）。
例えば、上記図１４に示したような検索結果を処理した場合、検索によって見つけられたカラープリンタ１０１（ＬＢＰ１１００）のブロック（ＢＬ）情報は「２−１」であるので、これに対応する上記図１８のレイアウトビットマップを表示する。
【０２１８】
そして、ロケーション情報内の座標情報（ＭＡＰ）をもとに、レイアウトビットマップ上の該当する表示位置に、ステップＳ５８０５で選択したデバイスビットマップアイコンを重ねて表示する（ステップＳ５８０９）。
例えば、上記図１４に示したような検索結果を処理した場合、カラープリンタ１０１（ＬＢＰ１１００）の座標情報（ＭＡＰ）は「１０Ｘ＋１０Ｙ」である。また、カラープリンタ１０１（ＬＢＰ１１００）に状態を問い合わせた結果が「紙切れ」である場合、上記図５３に示したような位置に紙切れを示すデバイスアイコンを表示する。このデバイスアイコンを、先のレイアウトビットマップに重ねて表示することによって、上記図５５に示したような検索結果を表示することが可能となる。
【０２１９】
図５９は、デバイスの状態取得応答動作を示したものである。
デバイスは、電源投入後に、状態取得要求パケットを受信するための受信ポートをオープンし、受信可能状態になる（ステップＳ５９０１）。
そして、クライアント装置１１１から状態取得要求パケットを受信すると（ステップＳ５９０２）、自デバイスの状態を調査し、通知すべき状態情報を決定する（ステップＳ５９０３）。例えば、「紙切れ」が発生している場合は、「紙切れ」を示す状態情報を通知すべき情報として決定する。
【０２２０】
次に、通知すべき状態情報を含めた、上記図５８に示したような応答パケットを生成する（ステップＳ５９０４）。そして、上記生成した応答パケットをクライアント装置１１１に送信し（ステップＳ５９０５）、再び状態取得要求パケットの受信可能状態になる。
【０２２１】
上述のように、本実施の形態によれば、ネットワーク１００上のデバイスの位置をわかりやすくユーザに通知するとともに、そのデバイスの情報をユーザに通知することが可能となる。
また、デバイスの状態を、デバイスからポーリングにより取得するので、ネットワーク１００上で一時的にパケットが喪失したとしても、デバイスの状態を確実に取得することが可能となる。
【０２２２】
＜第５の実施の形態＞
本実施の形態では、ネットワーク１００上のデバイスの位置をわかりやすくユーザに通知するとともに、そのデバイスの状態をユーザに通知する。
また、本実施の形態では、デバイスの状態をデバイスからのイベント通知により取得する。
【０２２３】
尚、本実施の形態は、第１の実施の形態をベースとしているため、ここでは、第１の実施の形態と異なる構成についてを具体的に説明する。
【０２２４】
図６０〜図６３は、第５の実施形態におけるクライアント装置１１１の動作を示すフローチャートである。
また、図６４〜図６５は、第５の実施形態におけるデバイスの動作を示すフローチャートである。
以下、これらのフローチャートを用いて、本実施の形態でネットワークシステムの動作を説明する。
【０２２５】
まず、上記図６０を用いて、本実施の形態でのクライアント装置１１１の全体動作について説明する。
本実施の形態では、特に、第１の実施の形態における当該動作（上記図２８参照）に対して、ステップＳ６１０７及びステップＳ６１０８の処理が追加されている。
【０２２６】
ステップＳ６１０７では、取得したイベントがデバイスからのイベント通知受信（ステップＳ２６０６での検索結果処理の中で行われるイベント通知先登録要求に対するデバイスからの応答）であるか否かを判断する。
ここで、イベント通知をデバイスから受信したと判断した場合は、後述するイベント通知受信処理を行う（スナッブＳ６１０８）。
その後、ステップＳ６１０１に戻り、クライアント装置１１１は、再びイベントの発生待ちとなる。
【０２２７】
上記図６１は、上記図６０のステップＳ２６０４における検索要求送信処理を示すフローチャートである。
この処理については、第４の実施の形態での当該処理と同様である。
【０２２８】
つぎに、上記図６２のフローチャートを用いて、上記図６０のステップＳ６１０６における検索結果処理についてより詳細に説明する。
【０２２９】
上記図６２において、デバイス検索の結果、検索条件に合致するデバイスが１つ以上発見されたか否かを判断する（ステップＳ６３０１）。ここで、検索条件に合致するデバイスが１つも発見されなかった場合は、該当するデバイスが発見されなかった旨のメッセージ（不図示）を表示し（ステップＳ６３１５）、本処理を終了する。
【０２３０】
一方、ステップＳ６３０１において、１つ以上のデバイスが発見されたと判断した場合は、その検索結果（該当するデバイスのロケーション情報及び属性情報）をハードディスク２１１に保存する。
例えば、上記図１４に示したような検索結果が得られた場合、それをハードディスク２１１へ保存することになる。
その後、ハードディスク２１１に保存された検索結果のそれぞれに対して、以降の処理ステップＳ６３０３からの処理による状態取得プロセスが実行されることになる。
【０２３１】
本実施の形態での状態取得プロセスは、クライアント装置１１１が検索結果で示されるデバイスに対してイベント通知先登録要求を発行し、それに対する応答としてデバイスから返送されてくるイベント通知を取得し、そのイベント通知の中に含まれるデバイスの状態情報に従って、レイアウトビットマップ上に現在の状態に応じたデバイスアイコンを重ねて表示するためのプログラムである。
【０２３２】
状態取得プロセスが起動されると、先ず最初に、上記ステップＳ６３０２でハードディスク２１１に保存された検索結果を参照し、すべての検索結果を処理し終わったかどうか、すなわち保存されている検索結果の中に含まれるすべてのＩＰアドレスのデバイスに対してイベント通知先の登録処理が終わったかどうかを判断する（ステップＳ６３０３）。ここで、全ての検索結果を処理し終わった場合には、本処理を終了する。
【０２３３】
一方、まだ処理されていない検索結果があると判断した場合は、未処理の検索結果から１デバイス分のデバイス情報（ロケーション情報や属性情報）を取得する（ステップＳ６３０４）。
さらに、取得した属性情報中に含まれるＩＰアドレス宛てに、図６６に示すようなイベント通知先登録パケットを送信する（ステップＳ６３０５）。
例えば、上記図１４に示した検索結果を処理する場合、ＩＰアドレスは「１９２．１．２．１」であり、このＩＰアドレス宛てにイベント通知先登録パケットを送信することになる。
【０２３４】
ここで、上記図６６に示したイベント通知先登録パケットは、どのようなイベントが発生した場合にイベント通知を行うかを示すための通知条件情報と、その通知先を示すためのイベント通知先情報とを含む。
すなわち、１番目のフィールド６７０１は、このパケットの内容がイベント通知先登録であることを示す。２番目のフィールド６７０２は、この後に続く情報が通知条件を表す情報であることを示すタグである。３番目のフィールド６７０３は、実際の通知条件を表す情報を格納するものである。また、４番目のフィールド６７０４は、この後に続く情報がイベント通知先を表す情報であることを示すタグである。最後のフィールド６７０５は、実際の通知先のネットワークアドレスを表す情報を格納するものである。
【０２３５】
上記図６６では、イベント通知先登録パケットの発行先デバイスは、上記ＩＰアドレス「１９２．１．２．１」で示されるカラープリンタ１０１であり、通知条件情報には、そのカラープリンタ１０１の「紙切れ」及び「紙詰まり」を設定し、イベント通知先情報には、自クライアントを表すＩＰアドレス「１９２．１，２．１６：１０２５」を設定している。
【０２３６】
上記イベント通知先登録パケットを送った後は、イベント通知先登録の応答パケットの受信待ち状態となる。そして、ステップＳ６３０６において目的のデバイスから、図６７に示すようなイベント通知先登録の応答パケットを受信すると、検索結果のロケーション情報に含まれるデバイス名（ＮＭ）情報と、受信した応答パケット中に含まれるデバイス状態情報とに基づいて、上記図５２に示した各種デバイスアイコンの中から、デバイス状態に応じた適切なビットマップアイコンを選択する（ステップＳ６３０７）。
【０２３７】
ここで、上記図６７は、デバイスからクライアント装置１１１に送信される応答パケットの一例を示す図である。
この応答パケットは、クライアント装置１１１からデバイスに送信されるイベント通知先登録パケット（上記図６６参照）に対して、そのときのデバイスの状態を表すデバイス状態情報を返送するために送信される。
【０２３８】
上記図６７において、１番目のフィールド６８０１は、このパケットの内容がイベント通知先登録の応答であることを示す。２番目のフィールド６８０２は、この後に続く情報がデバイスの状態を表す情報であることを示すタグである。最後のフィールド６８０３は、実際のデバイス状態を表す情報（例えばエラーコードなど）を格納するものである。
【０２３９】
例えば、上記図６７に示されるような応答パケットをクライアント装置１１１が受信した場合は、当該応答パケット中のデバイス状態情報は「紙切れ」を表しているので、上記ステップＳ６３０７では、上記図５２で示すＬＢＰ１１１０に対応するデバイスアイコンが選択されることになる。
【０２４０】
次に、クライアント装置１１１が、ロケーション情報としてのブロック（ＢＬ）情報に対応したレイアウトビットマップを表示可能か否か、すなわちブロック（ＢＬ）情報に対応したレイアウトビットマップ情報を保持しているか否かを、上記図１５の情報テーブルを用いて判断する（ステップＳ６３０８）。
本実施の形態において、レイアウトビットマップを表示可能なロケーション情報は、上記図１４の“１４０１”で示す情報を含むロケーション情報である。これを含まないロケーション情報であった場合１こは、上記図２０に示したｕｎｋｎｏｗｎＭＡＰが既に表示されているか否かを判断する（ステップＳ６３１２）。
【０２４１】
上記の判断にて、まだｕｎｋｎｏｗｎＭＡＰが表示されていない場合には、上記図２０のエリア“１９０１”にｕｎｋｎｏｗｎＭＡＰを表示する（ステップＳ６３１３）。そして、上記図２０のエリア“１９０２”に、ステップＳ６３０７にて選択したデバイスアイコンを表示する（ステップＳ６３１４）。この場合には、レイアウトマップが正常に表示されなかった、すなわちロケーション情報がまだ登録されていないデバイスのアイコンがここに表示されることになる。
【０２４２】
一方、ステップＳ６３０８でレイアウトビットマップを表示可能と判断された場合には、ロケーション情報内のブロック（ＢＬ）情報に対応するレイアウトビットマップは既に表示されているか否かを判断する（ステップＳ６３０９）。そして、まだ表示されていないと判断した場合は、上記ブロック（ＢＬ）情報に対応するレイアウトビットマップを画面上に表示する（ステップＳ６３１０）。
例えば、上記図１４の検索結果を処理した場合、検索によって見つけられたカラープリンタ１０１（ＬＢＰ１１００）のブロック（ＢＬ）情報は「２−１」であるので、これに対応する上記図１８のレイアウトビットマップを表示する。
【０２４３】
そして、ロケーション情報内の座標情報（ＭＡＰ）をもとに、レイアウトビットマップ上の該当する表示位置に、ステップＳ６３０７で選択したデバイスアイコンを重ねて表示する（ステップＳ６３１１）。
例えば、上記図１４の検索結果を処理した場合、カラープリンタ１０１（ＬＢＰ１１００）の座標情報（ＭＡＰ）は「１０Ｘ＋１０Ｙ」である。また、カラープリンタ１０１（ＬＢＰ１１００）に状態を問い合わせた結果が「紙切れ」である場合、上記図５３に示した位置へ紙切れを示すデバイスビットマップアイコンを表示する。このデバイスビットマップアイコンを、先のレイアウトビットマップに重ねて表示することによって、上記図５４に示したように検索結果を表示することが可能となる。
【０２４４】
つぎに、上記図６０のステップＳ６１０８に示したイベント通知受信処理の動作について、上記図６３のフローチャートを用いて詳細に説明する。
【０２４５】
上記図６３において、クライアント装置１１１は、先ず最初に、上記図６２のステップＳ６３０５の処理によってイベント通知先の登録が行われたデバイスから、図６８に示すようなイベント通知パケットを受信すると、そのイベント通知パケット中から当該デバイスにて発生したイベントの内容を表すイベント情報を取得するとともに（ステップＳ６４０１）、当該デバイスの位置を表すロケーション情報を取得する（ステップＳ６４０２）。
【０２４６】
ここで、上記図６８に示すように、各デバイスは、自己の状態変化を監視しており、クライアント装置１１１から登録された通知条件に合致するイベントが発生すると、同じくクライアント装置１１１から登録された通知先へそのイベント情報を送信する。このとき、そのデバイスの位置を表すものとしてデバイスに保持されているロケーション情報も一緒にパケット化して送信する。
上記図６８では、カラープリンタ１０１（ＬＢＰ１１００）にて紙切れのイベントが発生したときに送られるパケットを示している。
【０２４７】
次に、クライアント装置１１１は、デバイス検索の処理によってハードディスク２１１に記憶された検索結果の中に、上記イベント通知パケット中から取得したロケーション情報と一致する情報を有するデバイス情報が存在するか否かを判断する（ステップＳ６４０３）。これは、イベント通知先の登録処理は、他のクライアント装置１１３からも行われていることがあるので、自己の検索結果で示されるデバイスのロケーション情報と、イベント発生先のデバイスから送られてくるロケーション情報とが必ず一致するとは限らないからである。
【０２４８】
ステップＳ６４０３での判断の結果、イベント通知パケット中のロケーション情報と一致するデバイス情報が存在しないと判断した場合は、そのまま本処理を終了する。
【０２４９】
一方、一致するデバイス情報が存在する場合は、上記イベント通知パケット中から取得したイベント情報（状態情報）と、ロケーション情報に含まれるデバイス名（ＮＭ）情報と１こ基づいて、上記図５２に示した各種デバイスアイコンの中から、デバイス状態に応じた適切なデバイスアイコンを選択する（ステップＳ６４０４）。
【０２５０】
そして、上記取得したロケーション情報に対応するレイアウトビットマップを画面上に表示するとともに、当該ロケーション情報内の座標情報（ＭＡＰ）をもとに、レイアウトビットマップ上の該当する表示位置に、ステップＳ６４０４で選択したデバイスアイコンを重ねて表示する（ステップＳ６４０５）。
これにより、デバイスアイコンの表示が、デバイスの状態変化に応じて変更される。
【０２５１】
例えば、イベント通知先の登録処理を行ったときにその応答としてカラープリンタ１０１から送られてくるデバイスの状態情報が「稼働中」であり、稼働中の状態を表すデバイスアイコンを画面上に表示している状態中に、カラープリンタ１０１にて紙切れが発生した場合、その稼働中を表すデバイスアイコンは、上記図５４に示したような紙切れを表すアイコンに変更されて表示されることになる。
【０２５２】
つぎに、デバイス側のイベント通知先登録処理の動作について、上記図６４のフローチャートを用いて詳細に説明する。
ここでは、説明の簡単のために、各種デバイスのうち、カラープリンタ１０１に着目して説明する。
【０２５３】
カラープリンタ１０１は、電源投入後に、クライアント装置１１１から、上記図６６に示したようなイベント通知先登録パケットを受信するための受信ポートをオープンし、受信可能状態になる（ステップＳ６５０１）。そして、ある検索クライアントＰＣからイベント通知先登録パケットを受信すると（ステップＳ６５０２）、そのイベント通知先登録パケットに含まれる通知条件や通知先の情報を、図６９に示すようなイベント通知先テーブルに保存し、管理する（ステップＳ６５０３）。
【０２５４】
ここで、上記図６９に示すイベント通知先テーブルは、デバイス側で保持されており、クライアント装置１１１から登録された通知条件や通知先のネットワークアドレスの他に、通信プロトコルの情報も併せて記憶されている。
【０２５５】
次に、カラープリンタ１０１は、上記イベント通知先登録パケットを受信した時点での自デバイスの状態を調査し、通知すべき状態情報を決定する（ステップＳ６５０４）。
例えば、「紙切れ」の状態が発生している場合は、「紙切れ」を示す状態情報を通知すべき情報として決定する。
【０２５６】
次に、通知すべき現在の状態情報を含めた、上記図６７に示したような応答パケットを生成する（ステップＳ６５０５）。そして、上記イベント通知先登録パケットの発行元のクライアント装置１１１に対して、上記生成した応答パケットを送信し（ステップＳ６５０６）、再びイベント通知先登録パケットの受信可能状態になる。
【０２５７】
つぎに、デバイス側で行われるイベント通知処理の動作について、上記図６５のフローチャートを用いて詳細に説明する。
ここでも、説明の簡単のために、各種デバイスのうち、カラープリンタ１０１に着目して説明する。
【０２５８】
カラープリンタ１０１は、自己の状態変化を監視しており、状態変化のイベントが発生したか否かを判断する（ステップＳ６６０１）。ここで、状態変化のイベントが発生すると、上記図６９に示したようなイベント通知先テーブルを参照し、発生したイベントを通知すべきクライアント装置を検索する（ステップＳ６６０２）。
【０２５９】
そして、イベントを通知すべきクライアント装置が１つ以上存在するか否かを判断する（ステップＳ６６０３）。ここでは、カラープリンタ１０１にて発生したイベントが、上記イベント通知先テーブル内に通知条件として登録されているクライアント装置があるか否かを判断する。そのようなクライアント装置が存在する場合は、そのイベント情報を含めた、上記図６８に示したようなイベント通知パケットを生成し（ステップＳ６６０４）、それを通知すべき全てのクライアント装置に送信する（ステップＳ６６０５）。その後、ステップＳ６６０１に戻り、再び状態変化のイベント発生待ちの状態となる。
【０２６０】
上述のように、本実施形態によれば、ネットワーク１００上のデバイスの位置をわかりやすくユーザに通知するとともに、そのデバイスの情報をユーザへ通知することが可能となる。
また、デバイスの状態を、デバイスからのイベント通知により取得するので、ポーリングングによって取得する場合に比べて、ネットワーク１００のトラフィックを軽減することが可能となる。
【０２６１】
尚、第４及び第５の実施の形態では、レイアウトビットマップをクライアント装置１１１が保持している形態としたが、第２の実施の形態のようにレイアウトビットマップをサーバ装置が保持する形態としてもよい。
また、第４及び第５の実施の形態では、ブロック（ＢＬ）階層に対応したレイアウトビットマップのみを保持する形態としたが、第３の実施の形態のように階層型位置情報の各階層に対応するレイアウトビットマップを保持し、それをクライアント装置１１１の検索結果表示に反映する形態としてもよい。
【０２６２】
＜本発明の他の実施の形態１＞
第１〜第５の実施の形態におけるデバイス検索システムは、例えば、ＷＷＷ技術で利用されているような技術を用いて実現できる。この場合、サーバ装置１１２は、ＷＷＷサーバと、データベース機能（ＤＢＭＳ）と、ＷＷＷサーバ及びＤＢＭＳを仲介するゲートウェイ機能とを備えるように構成する。
【０２６３】
ＷＷＷサーバは、ＨＴＭＬ或はＸＭＬで構成される検索画面をクライアント装置へ提供する。
クライアント装置は、ブラウサソフトウェアによりＷＷＷサーバから提供された検索画面を表示し、クライアント装置のユーザは、当該表示された検索画面を用いてデバイスの検索を実行する。
【０２６４】
また、サーバ装置、クライアント装置、及びデバイスの間でやりとりされる各種データ（ＭＡＰ、アイコン等）は、ＨＴＭＬやＸＭＬ等で構成され、データをやりとりするためのプロトコルとしては、ＨＴＴＰが用いられる。
【０２６５】
また、クライアント装置側で、汎用のブラウサソフトウェアが持っていない機能を実現するには、例えば、ＪＡＶＡ技術の１つであるアプレット（Ａｐｐｌｅｔ）を利用する形態等がある。
【０２６６】
＜本発明の他の実施の形態２＞
第１〜第５の実施の形態では、クライアント装置１１１及びサーバ装置１１２の一例として、上記図３に示したような構成を有するコンピュータ装置を用いるようにしたが、例えば、スキャナ、ファクシミリ、プリンタ等のデバイスに対して、クライアント装置１１１の機能、又はサーバ装置１１２の機能を持たせるようにしてもよい。
【０２６７】
具体的には例えば、スキャナに対してクライアント装置１１１の機能を持たせる構成とした場合、当該スキャナで読み取った原稿データを印刷するプリンタの状態や、当該スキャナで読み取った原稿データを送信するファクシミリの状態を知ることが可能となる。
【０２６８】
＜本発明の他の実施の形態３＞
第１〜第５の実施の形態のホスト及び端末の機能を実現するソフトウェアのプログラムコードを記憶した記憶媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読みだして実行することによっても、本発明が達成されることは言うまでもない。
この場合、上記ソフトウェアのプログラムコード自体が、第１〜第５の実施の形態の機能を実現することになり、そのプログラムコード自体、及びそのプログラムコードをコンピュータに供給するための手段、例えば、当該プログラムコードを格納した記憶媒体が本発明を構成する。
【０２６９】
上記プログラムコードを記憶する記憶媒体としては、例えば、フロッピーディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ―ＲＯＭ、磁気テープ、不揮発性のメモリカード、ＲＯＭ等を用いることができる。
【０２７０】
また、第１〜第５の実施の形態でのネットワーク１００上のデバイス制御プログラムは、外部からインストールされるプログラムによって、ＰＣ２００（上記図３参照）によって遂行されるようにしてもよい。
この場合、上記プログラムを含む情報群が、ＣＤ―ＲＯＭやフラッシュメモリ、或はフロッピーディスク等の記憶媒体、或は電子メールやパソコン通信等のネットワークを介して、外部の記憶媒体からＰＣ２００内にロードされる場合でも、本発明は適用される。
【０２７１】
図７０は、上記記憶媒体の一例としてのＣＤ−ＲＯＭのメモリマップを示す図である。
上記図３０において、“９９９９”はディレクトリ情報を記憶してある領域であり、以降の領域９９９８及び領域９９９７の位置を示している。
領域９９９８は、インストールプログラムを記憶してある領域であり、領域９９９７は、ネットワークデバイス制御プログラムを記憶してある領域である。
【０２７２】
本発明を適用したネットワーク制御プログラムが、ＰＣ２００にインストールされる際には、先ず、インストールプログラムを記憶してある領域９９９８に記憶されている当該インストールプログラムがＰＣ２００内へロードされ、そのＣＰＵ２０２によって実行される。
そして、ＣＰＵ２０２によって実行されるインストールプログラムが、ネットワークデバイス制御プログラムを記憶してある領域９９９７から当該ネットワークデバイス制御プログラムを読み出して、ハードディスク２１１へ格納する。
【０２７３】
また、コンピュータが読みだしたプログラムコードを実行することにより、第１〜第５の実施の形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（オペレーティングシステム）等が実際の処理の一部又は全部を行い、その処理によって第１〜第５の実施の形態の機能が実現される場合も含まれることは言うまでもない。
さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された拡張機能ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部又は全部を行い、その処理によって第１〜第５の実施の形態の機能が実現される場合も含まれることは言うまでもない。
【０２７４】
【発明の効果】
以上説明したように本発明によれば、ジョブについてのイベントが発生するのに応じて、デバイスから情報処理装置に、該デバイスの位置を階層的に表した階層型位置情報及び該イベントを示すイベント情報を送信することにより、前記情報処理装置が、前記階層型位置情報に基づいて、前記イベント情報が示すイベントを、イベントの発生に応じて表示できるようにしたので、ユーザは、デバイスの階層的なロケーションを容易に認識することができるとともに、当該デバイスに依頼されたジョブについてのイベントを容易に且つ的確に認識することができる。
【図面の簡単な説明】
【図１】第１の実施の形態において、本発明を適用したデバイス検索システムの構成を示すブロック図である。
【図２】上記デバイス検索システムが動作可能なネットワークシステムの一例の構成を説明するための図である。
【図３】一般的なパーソナルコンピュータの内部構成を示すブロック図である。
【図４】階層型位置情報の一例を説明するための図である。
【図５】２階の２−１ブロックの各デバイスの位置を説明するための図である。
【図６】２階の２−２ブロックの各デバイスの位置を説明するための図である。
【図７】１階の１−１ブロックの各デバイスの位置を説明するための図である。
【図８】１階の１−２ブロックの各デバイスの位置を説明するための図である。
【図９】サーバ装置が管理する階層型位置情報及び属性情報を説明するための図である。
【図１０】デバイスが登録する階層型位置情報及び属性情報を説明するための図である。
【図１１】デバイス検索入力画面を説明するための図である。
【図１２】デバイス検索入力画面の具体例を説明するための図である。
【図１３】デバイス検索条件の一例を説明するための図である。
【図１４】デバイス検索結果の一例を説明するための図である。
【図１５】クライアント装置が管理するビットマップ及び階層型位置情報を説明するための図である。
【図１６】クライアント装置が管理するレイアウトビットマップ（１階―１フロア）を説明するための図である。
【図１７】クライアント装置が管理するレイアウトビットマップ（１階―２フロア）を説明するための図である。
【図１８】クライアント装置が管理するレイアウトビットマップ（２階―２フロア）を説明するための図である。
【図１９】クライアント装置が管理するレイアウトビットマップ（２階―２フロア）を説明するための図である。
【図２０】クライアント装置が管理するレイアウトビットマップ（ｕｎｋｏｗｎＭＡＰ）を説明するための図である。
【図２１】クライアント装置が管理するデバイスアイコンを説明するための図である。
【図２２】デバイスアイコンの位置を説明するための図である。
【図２３】デバイス検索結果を説明するための図である。
【図２４】デバイスの内部構成を示すブロック図である。
【図２５】登録処理を説明するためのフローチャートである。
【図２６】サーバ装置の全体動作を説明するためのフローチャートである。
【図２７】データベースの検索処理を説明するためのフローチャートである。
【図２８】クライアント装置の全体動作を説明するためのフローチャートである。
【図２９】検索結果表示処理を説明するためのフローチャートである。
【図３０】クライアントが発行する印刷ジョブ情報の一例を説明するための図である。
【図３１】デバイスが管理するイベント通知テーブルを説明するための図である。
【図３２】デバイスからクライアント装置へ通知されるイベント通知を説明するための図である。
【図３３】印刷終了のイベントを受信したときの表示の一例を説明するための図である。
【図３４】クライアント装置のイベント受信時の処理を説明するためのフローチャートである。
【図３５】デバイスの全体動作を説明するためのフローチャートである。
【図３６】デバイスのイベント発生時の処理を説明するためのフローチャートである。
【図３７】第２の実施の形態において、クライアント装置の動作（検索結果表示動作）を説明するためのフローチャートである。
【図３８】クライアント装置の動作（表示動作）を説明するためのフローチャートである。
【図３９】サーバ装置の動作を説明するためのフローチャートである。
【図４０】第３の実施の形態において、各階層に対応するレイアウトビットマップのリストの一例を説明するための図である。
【図４１】クライアント装置の動作を説明するためのフローチャートである。
【図４２】各階層毎に用意されたレイアウトビットマップの一例（例１）を説明するための図である。
【図４３】各階層毎に用意されたレイアウトビットマップの一例（例２）を説明するための図である。
【図４４】各階層毎に用意されたレイアウトビットマップの一例（例３）を説明するための図である。
【図４５】各階層毎に用意されたレイアウトビットマップの一例（例４）を説明するための図である。
【図４６】各階層毎に用意されたレイアウトビットマップの一例（例５）を説明するための図である。
【図４７】各階層毎に用意されたレイアウトビットマップの一例（例６）を説明するための図である。
【図４８】各階層毎に用意されたレイアウトビットマップの一例（例７）を説明するための図である。
【図４９】各階層毎に用意されたレイアウトビットマップの一例（例８）を説明するための図である。
【図５０】各階層毎に用意されたレイアウトビットマップの一例（例９）を説明するための図である。
【図５１】各階層毎に用意されたレイアウトビットマップの一例（例１０）を説明するための図である。
【図５２】第４の実施の形態において、クライアント装置におけるデバイスアイコンの管理テーブルを説明するための図である。
【図５３】レイアウトビットマップの表示の一例（例１）を説明するための図である。
【図５４】レイアウトビットマップの表示の一例（例２）を説明するための図である。
【図５５】クライアント装置の動作（検索要求送信処理）を説明するためのフローチャートである。
【図５６】クライアント装置の動作（検索結果処理）を説明するためのフローチャートである。
【図５７】クライアント装置の動作（状態取得処理）を説明するためのフローチャートである。
【図５８】デバイスの応答パケットを説明するための図である。
【図５９】デバイスの動作を説明するためのフローチャートである。
【図６０】第５の実施の形態において、クライアント装置の動作（全体動作）を説明するためのフローチャートである。
【図６１】クライアント装置の動作（検索要求送信処理）を説明するためのフローチャートである。
【図６２】クライアント装置の動作（検索結果処理）を説明するためのフローチャートである。
【図６３】クライアント装置の動作（イベント通知受信処理）を説明するためのフローチャートである。
【図６４】デバイスの動作（イベント通知先登録処理）を示すフローチャートである。
【図６５】デバイスの動作（イベント通知処理）を示すフローチャートである。
【図６６】クライアント装置のイベント通知先登録パケットを説明するための図である。
【図６７】デバイスの応答パケットを説明するための図である。
【図６８】デバイスのイベント通知パケットを説明するための図である。
【図６９】デバイスが管理するイベント通知先テーブルを説明するための図である。
【図７０】他の実施の形態において、メモリマップの一例を説明するための図である。
【符号の説明】
１０ サーバ装置
１１ データベース
１２ 検索モジュール
１３ 属性登録モジュール
２０ クライアント装置
２１ 検索要求モジュール
２２ 表示モジュール
３０ デバイス
３１ 属性送信モジュール
４０ ネットワーク
【発明の属する技術分野】
本発明は、デバイス、ネットワークシステム、ジョブ処理方法、ジョブモニタ方法、及びコンピュータ読み取り可能な記憶媒体に関し、特に、ネットワーク上のデバイスを検索し、当該検索デバイス及びその位置情報等をユーザに対して容易に認識しやすく表示出力するために用いて好適なものである。
【０００２】
【従来の技術】
従来より例えば、ネットワーク上に接続された各種の資源（プリンタ、サーバ装置、スキャナ等のデバイス）を効率的に発見し、それを利用するための方法としては、ディレクトリサービスと呼ばれる方法が提供されている。
このディレクトリサービスとは、言わばネットワークに関する電話帳の機能を有し、様々な情報を格納するためのものである。
【０００３】
上記ディレクトリサービスを用いたディレクトリシステムの具体例としては、例えば、ＬＤＡＰ（Ｌｉｇｈｔｗｅｉｇｈｔ Ｄｉｒｅｃｔｏｒｙ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）がある。このＬＤＡＰの規定については、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｅｃｅ）が発行している、標準仕様である「ＲＦＣ（Ｒｅｑｕｅｓｔ Ｆｏｒ Ｃｏｍｍｅｔｓ）１７７７」に記載されている。
【０００４】
上述のようなディレクトリサービスにより、例えば、ネットワーク上に接続されているデバイスを検索することで、ネットワーク上で利用可能なデバイスのネットワーク上のアドレスの一覧（アドレスリスト）を得ることができる。
【０００５】
【発明が解決しようとする課題】
しかしながら、上述したような従来のディレクトリサービスにより得られるアドレスリストでは、利用可能なデバイスの位置を、認識しやすいかたちで得ることはできなかった。
【０００６】
例えば、ネットワーク上のプリンタの検索の場合、「自分のフロアにおいて、自分の場所に一番近いプリンタはどこにあるのか」、或いは「カラー画像を出力できるプリンタは、その建物の中のどの場所にあるのか」等というデバイスの階層的なロケーション情報を、ユーザに分かりやすく通知することが望まれていたが、従来ではこれを実現できなかった。
さらに、印刷等のジョブの実行をネットワーク上の情報処理装置によりプリンタへ依頼した場合に、「どの場所にあるプリンタへ印刷の依頼を行ったか」、或いは「自分が依頼した印刷が正常に終了したか否か」、或いは「ジャムや用紙切れ等のエラーが発生していないか」等という情報を、ユーザに分かりやすく通知することが望まれていたが、従来ではこれを実現できなかった。
【０００７】
そこで、本発明は、上記の欠点を除去するために成されたもので、所望するデバイスの位置と共に、当該デバイスへジョブを依頼した場合には当該ジョブの状況等の情報を、ユーザに対して認識しやすいかたちで提供できるようにすることを目的とする。
【０００８】
【課題を解決するための手段】
本発明のデバイスは、ネットワークを介して依頼されたジョブを処理するデバイスであって、前記ネットワーク上の情報処理装置から送信されたジョブを受信する受信手段と、前記ジョブについてのイベントが発生するのに応じて、自身の位置を階層的に表した階層型位置情報及び該イベントを示すイベント情報を前記情報処理装置に送信する送信手段と、を有することを特徴とする。
【０００９】
本発明のネットワークシステムは、少なくとも、ネットワークを介して依頼されたジョブを処理するデバイスと、依頼されたジョブをモニタする情報処理装置とを有するネットワークシステムであって、前記デバイスは、前記情報処理装置から送信されたジョブを受信する受信手段と、前記ジョブについてのイベントが発生するのに応じて、自身の位置を階層的に表した階層型位置情報及び該イベントを示すイベント情報を前記情報処理装置に送信する送信手段と、を含み、前記情報処理装置は、前記デバイスにジョブを送信する送信手段と、前記ジョブについてのイベントが発生するのに応じて前記デバイスから送信される情報であって、該デバイスの位置を階層的に表した階層型位置情報及び該イベントを示すイベント情報を受信する受信手段と、前記受信手段によって受信した階層型位置情報に基づいて、前記イベント情報が示すイベントを表示する表示手段と、を含むことを特徴とする。
【００１０】
本発明のジョブ処理方法は、ネットワークを介して依頼されたジョブを処理するジョブ処理方法であって、前記ネットワーク上の情報処理装置から送信されたジョブを受信する受信ステップと、前記ジョブについてのイベントが発生するのに応じて、自身の位置を階層的に表した階層型位置情報及び該イベントを示すイベント情報を前記情報処理装置に送信する送信ステップと、を有することを特徴とする。
【００１１】
本発明のジョブモニタ方法は、ネットワークを介して依頼されたジョブをモニタするジョブモニタ方法であって、前記ネットワーク上のデバイスにジョブを送信する第１の送信ステップと、前記第１の送信ステップによって送信されたジョブを受信する第１の受信ステップと、前記第１の受信ステップによって受信されたジョブについてのイベントが発生するのに応じて、自身の位置を階層的に表した階層型位置情報及び該イベントを示すイベント情報を前記ネットワーク上の情報処理装置に送信する第２の送信ステップと、前記第２の送信ステップによって送信された前記階層型位置情報及び前記イベント情報を受信する第２の受信ステップと、前記第２の受信ステップによって受信された階層型位置情報に基づいて、前記イベント情報が示すイベントを表示する表示ステップと、を含むことを特徴とする。
【００１２】
本発明のコンピュータ読み取り可能な記憶媒体は、ネットワークを介して依頼されたジョブを処理することをコンピュータに実行させるためのコンピュータプログラムを記憶したコンピュータ読み取り可能な記憶媒体であって、前記コンピュータプログラムは、前記ネットワーク上の情報処理装置から送信されたジョブを受信する受信ステップと、前記ジョブについてのイベントが発生するのに応じて、自身の位置を階層的に表した階層型位置情報及び該イベントを示すイベント情報を前記情報処理装置に送信する送信ステップと、をコンピュータに実行させることを特徴とする。
【００３２】
【発明の実施の形態】
以下、本発明の実施の形態について図面を用いて説明する。
【００３３】
本発明は、例えば、図１に示すようなデバイス検索システムに適用される。
本実施の形態のデバイス検索システムは、上記図１に示すように、クライアント装置２０、デバイス３０、及びサーバ装置１０がネットワーク４０上に配置された構成としている。
【００３４】
クライアント装置２０は、例えば、汎用のコンピュータ等からなり、検索要求モジュール２１及び表示モジュール２２を含んでいる。
検索要求モジュール２１は、サーバ装置１０へ所望のデバイス検索条件を送信し、その結果を受信する。検索要求モジュール２１にて受信された検索結果を可視表示する。
【００３５】
サーバ装置１０は、ネットワーク４０上のデバイス３０の属性情報を管理するデータベース１１を有するディレクトリサーバとしての機能を有する。
データベース１１には、ネットワーク４０上のデバイス３０の識別情報、及びデバイス３０が有する各種属性の情報が登録される。
【００３６】
また、サーバ装置１０は、検索モジュール１２及び属性登録モジュール１３を含んでいる。
検索モジュール１２は、クライアント装置２０から受信したデバイス検索条件に基づいて、データベース１１から条件に合致するデバイスを検索し、その検索結果をクライアント装置２０へ送信する。
属性登録モジュール１３は、デバイス３０等からデバイス属性を受信してデータベース１１１に登録する。
【００３７】
デバイス３０は、クライアント装置２０等に各種サービスを提供するため機能を有し、例えば、スキャナやプリンタ、或いはファクシミリ等である。
デバイス３０は、デバイス属性送信モジュール３１を含み、このデバイス属性送信モジュール３１は、デバイス３０自身の属性情報をサーバ装置１０へ送信し、データベース１１への登録要求を行う。
【００３８】
尚、上記図１では、説明の簡単のため、本デバイス検索システムの最小単位の構成を示している。すなわち、上記図１では、それぞれが１つのクライアント装置２０及びデバイス３０がネットワーク４０へ接続された構成を図示しているが、これらの接続数に限られることはなく、それぞれが複数のクライアント装置２０及びデバイス３０がネットワーク４０へ接続された構成とするようにしてもよい。
また、サーバ装置１０についても同様に、複数のサーバ装置１０をネットワーク４０上へ接続する構成とするようにしてもよい。
【００３９】
図２は、本実施の形態のデバイス検索システムが動作可能なネットワークシステムの構成の一例を示したものである。
【００４０】
上記図２において、“１０１”はカラープリンタを示し、“１０２”はＭＦＰを示し、“１０３”及び“１０４”はモノクロプリンタを示し、“１０５”はスキャナを示す。
これらのデバイス１０１〜１０５（上記図１のデバイス３０に対応、以下、「ネットワークデバイス」とも言う）は、ＬＡＮ等のネットワーク１００（上記図１のネットワーク４０に対応）に接続されている。
【００４１】
尚、上記ＭＦＰ（Ｍｕｌｔｉ Ｆｕｎｃｔｉｏｎ Ｐｅｒｉｈｅｒａｌ）とは、コピー機であるが、ネットワークプリンタとしても使用可能なものである。以下、「多機能コピー機」とも言う。
【００４２】
“１１１”及び“１１３”はそれぞれ、デスクトップ型のパーソナルコンピュータ（以下、「デスクトップＰＣ」とも言う）及びとノート型のパーソナルコンピュータ（以下、「ノートＰＣ」とも言う）である。
これらのＰＣ１１１，１１３は、本実施の形態のネットワーククライアントのプログラムが実行可能なＰＣであり、クライアント装置（上記図１のクライアント装置２０に対応）としてネットワーク１００に接続され、詳細は後述するが、ネットワーク１００上に接続されたサーバ装置に対して所望の条件を満たすデバイスに関する問い合わせ情報（デバイス検索の問い合わせの情報）を発行する機能ともに、当該デバイスの検索結果を表示する表示機能をも有する。
【００４３】
“１１２”は、本実施の形態のネットワークサーバのプログラムが実行可能なＰＣであり、サーバ装置（上記図１のサーバ装置１０に対応）としてネットワーク１００に接続される。
このため、サーバ装置１１２は、詳細は後述するが、ネットワークデバイス１０１〜１０５に関する種々の情報を保持する機能や、ネットワーク１００に接続されたクライアント装置１１１又は１１３からのデバイス検索の問い合わせを受け付け、その結果を返す機能を有する。
【００４４】
上述のような本実施の形態でのネットワークシステムでは、ネットワークデバイス１０１〜１０５のうちのカラープリンタ１０１、多機能コピー機１０２、及びモノクロプリンタ１０３と、クライアント装置１１１と、サーバ装置１１２と、後述するファイアウォール１２０とが、２階のフロアに設置されている。
また、ネットワークデバイス１０１〜１０５のうちのモノクロプリンタ１０４及びスキャナ１０５は、１階のフロアに設置されている。
ノートＰＣ１１３については、現在は１階のフロアに設置されているものとしているが、１階のフロアのネットワーク１００から取り外され、２階のフロアへ移動することもある。
【００４５】
また、１階のフロア及び２階のフロアにそれぞれ設置されたデバイスを相互に接続するネットワーク１００は、ファイアウォール１２０を介してインターネット１３０へ接続されており、さらに、インターネット１３０を介して他のネットワーク１４０とも接続されている。
【００４６】
図３は、任意のパーソナルコンピュータ２００（以下、単に「ＰＣ２００」と言う）の内部構成を示したものである。
上記図２に示したデスクトップＰＣ１１１、ノートＰＣ１１３、及びサーバ端末装置１１２等は、上記図３のＰＣ２００の機能を有する。
【００４７】
具体的には、ＰＣ２００は、ネットワーククライアントのプログラム（クライアント装置ソフトウェア）、或いはネットワーククサーバのプログラム（サーバ装置ソフトウェア）が稼動するようになされている。
尚、以下の説明では、クライアント装置ソフトウェアとサーバ装置ソフトウェアをまとめて、「ネットワークデバイス端末装置検索ソフトウェア」とも言う。
【００４８】
ＰＣ２００において、ＣＰＵ２０２は、ＲＯＭ２０３或いはハードディスク（ＨＤ）２１１に記憶されたネットワークデバイス検索ソフトウェア、或いはフロッピーディスクドライブ（ＦＤ）２１２より供給されるネットワークデバイス検索ソフトウェアを実行することで、システムバス２０１に接続された各構成部２０３〜２１３を総括的に制御する。
【００４９】
ＲＡＭ２０４は、ＣＰＵ２０２の主メモリやワークエリア等として機能する。キーボードコントローラ（ＫＢＣ）２０５は、キーボード（ＫＢ）２０９や不図示のポインティングデバイス等からの指示入力を制御する。
コントローラ（ＣＲＴＣ）２０６は、ＣＲＴディスプレイ（ＣＲＴ）２１０の表示を制御する。
【００５０】
ディスクコントローラ（ＤＫＣ）２０７は、ブートプログラムや種々のアプリケーション、編集ファイル、ユーザファイル、或いはネットワーク管理プログラム等を記憶するハードディスク（ＨＤ）２１１、及びフロッピーディスクコントローラ（ＦＤ）２１２へのアクセスを制御する。
【００５１】
ネットワークインタフェースカード（ＮＩＣ）２０８は、ＬＡＮ２２０を介して、ネットワークプリンタや他のネットワーク機器、或いは他のＰＣと双方向にデータをやリとリするためのものである。
【００５２】
マウスコントローラ（ＭＣ）２１３は、マウス（ＭＳ）２１４を制御する。
【００５３】
尚、上記図３において、ＬＡＮ２２０は、上記図２に示したＬＡＮ１００に相当するものである。
【００５４】
図４は、上記図２のネットワークシステムにおいて、ＬＡＮ１００上のデバイスの位置を表現するための階層型位置情報を説明するための図である。
本実施の形態では、階層型位置情報のデータ構造を階層構造としており、上位層から下位層へと、より詳細な位置情報を特定するようになされている。
したがって、ユーザは、用途日的に応じて所望の階層を指定すればよい。
【００５５】
例えば、上記図４では、図中“３０９”で示す「ＬＢＰ１１１０」の階層型位置情報は、（Ｃ：ＪＰ（３０１）、Ｏ：ＡＢＣ商事（３０２）、ＢＲ：東京支店（３０３）、ＯＰ＝ｅｘｔｅｎｄ（３０４）、Ｂｕ＝Ｍビル（３０５）、ＦＬ＝２Ｆ（３０６）、ＢＬ＝２−１（３０７）、ＤＶ＝ｐｒｎｔｅｒ（３０８））として指定される。この場合、マップ（ｍａｐ）は「１０Ｘ＋１０Ｙ」として示される。
【００５６】
また、それぞれのエントリーについて説明すると、「Ｃ」は国情報を示し（“ＪＰ”は“日本”、“ＵＳ”は“アメリカ”等）、「Ｏ」は組織情報を示し（“ＡＢＣ商事”、“ＸＹＺ物産”等）、「ＢＲ」は支店又は支部等の情報を示す（“東京支店”、“大阪支店”等、以下、「支店情報」と言う）。
「ＢＵ」は建物であるビルディング情報を示し（“ＡＡビル”、“ＢＢビル”等）、「ＦＬ」はフロアーの階数であるフロア情報を示し（“１Ｆ”、“２Ｆ”等）、「ＢＬ」はフロアのブロックであるブロック情報を示し（“１−１”、“２−１”等）、「ＤＶ」はデバイスを示し（“ｐｒｉｎｔｅｒ”、“ＭＦＰ”等）、「ＮＭ」はデバイス名を示す（“ＬＢＰ１１１０”、“ＬＢＰ３３１０”等）。
【００５７】
また、ブロック情報「ＢＬ」に対応して、配置レイアウトを視覚的に表示したイメージデータであるレイアウトビットマップが用意されており、上記図４における「ＭＡＰ」は、そのマップ上の座標情報を示す。
【００５８】
さらに、「ＯＰ」はオプション情報、すなわち、「ＢＵ」階層、「ＦＬ」階層、及び「ＢＬ」階層の情報を含むことを示す（ｅｘｔｅｎｄ−拡張）。
尚、オプション情報の他の階層に設定してもよいし、オプション情報の階層を設定しないデータ構造であってもよい。
【００５９】
したがって、本実施の形態の主たる目的は、ネットワーク（ここでは、ＬＡＮ１００）上に接続された各デバイスの位置情報を、上記図４に示したような階層的構造によって管理することによって、検索要求の有ったデバイスの位置を特定し、当該特定したデバイスの位置をユーザに分かりやすく表示できるようにすることにある。
【００６０】
図５〜図８は、上記図４によって示される階層型位置情報のブロック階層ＢＬに対応したレイアウトビットマップの一例でる。これらの図５〜図８のレイアウトビットマップは、クライアント装置１１１側において表示される。これにより、ユーザは、デバイスの位置を容易に確認することができる。
【００６１】
上記図５のレイアウトビットマップは、２Ｆの２−１ブロックにおける位置マップである。
このレイアウトビットマップでは、予めビットマップとして保持されたレイアウト（２Ｆのフロア内の実際の机の並びやパーティションの様子等のレイアウト）上に、カラープリンタ１０１やＭＦＰ１０２が配置されていると共に、ファイアーウォール１２０及びサーバ装置１１２が当該レイアウトで設置してある。
【００６２】
上記図６のレイアウトビットマップは、２Ｆの２−２ブロックにおける位置マップである。
上記図６に示すように、２Ｆの２−２ブロックには、ＰＣ１１１とプリンタ１０３が同図に示すようなレイアウトで設置されている。
【００６３】
上記図７のレイアウトビットマップは、１Ｆの１−１ブロックにおける位置マップである。
上記図７に示すように、１Ｆの１−１ブロックには、ＰＣ１１３とモノクロプリンタ１０４が同図に示すようなレイアウトで設置されている。
【００６４】
上記図８のレイアウトビットマップは、１Ｆの１−２ブロックにおける位置マップである。
上記図８に示すように、１Ｆの１−２ブロックには、スキャナ１０５が同図に示すようなレイアウトで設置されている。
【００６５】
上述のようなレイアウトビットマップがクライアント装置１１１にて画面表示される。
【００６６】
以下、上記図４にて示される階層型位置情報に基づいてデバイスを検索するようになされた、上記図２のネットワークシステムの動作について、第１〜５の実施の形態を説明する。
【００６７】
まず、第１の実施の形態では、クライアント装置１１１がデバイスに対して発行したジョブについてのイベント情報を、そのデバイスの位置情報と共にわかりやすく通知する。
また、第１の実施の形態では、検索されたデバイスの位置を表現するためのレイアウトビットマップをクライアント装置１１１が保持しているものとするが、第２の実施の形態では、当該レイアウトビットマップをサーバ装置１１２が保持するものとする。
さらに、第１及び第２の実施の形態では、ブロック（ＢＬ）の階層に対応したレイアウトビットマップのみを保持するものとするが、第３の実施の形態では、階層型位置情報の各階層に対応するレイアウトビットマップを保持し、それをクライアント装置１１１の検索結果表示に反映する。
【００６８】
また、第４及び第５の実施の形態では、ネットワーク１００上のデバイスの位置をわかりやすくユーザへ通知すると共にに、そのデバイスの状態をユーザに通知する。
ここで、第４の実施の形態では、デバイスの状態をデバイスからポーリングすることにより取得する構成とし、第５の実施の形態では、デバイスの状態をデバイスからのイベント通知により取得する構成とする。
【００６９】
＜第１の実施の形態＞
本実施の形態では、クライアント装置１１１がデバイスに対して発行したジョブについてのイベント情報を、そのデバイスの位置情報と共ににわかりやすく通知する。
本実施の形態におけるシステムにおいて、デバイスの位置を表現するためのレイアウトビットマップは、クライアント装置１１１に保持されている。
【００７０】
そこで、まず、サーバ装置１１２が、ネットワーク１００上の各デバイスの属性情報を管理するための構成を説明する。
【００７１】
図９は、サーバ装置１１２がネットワーク１００上の各デバイスの属性情報を管理するためのデータベースのデータ構造の一例である。
上記図９において、各列が登録されている各デバイスに関する１件のデータ、すなわち、タプル（ｔｕｐｌｅ）に相当し、各行が各タプルごとの属性（ａｔｔｒｉｂｕｔｅ）に相当する。
データベース８００では、“８０２”〜“８１０”へ階層型位置情報が、“８１１”及び“８１２”へその他の属性情報が、各デバイスごとに対応付けられて記憶されている。
上記その他の属性情報としては、ここでは、例えば、カラー入出力機能の有無を示す属性（８１１）、及びＩＰアドレス（８１２）としているが、これに限られることはなく、ステープル機能の有無を示す属性や、両面印刷機能の有無を示す属性等、デバイスが一般に備えている属性の情報を用いるようにしてもよい。
【００７２】
図１０は、デバイスが、サーバ装置１１２が管理しているデータベース８００へ自身を登録する際の、デバイス登録データのデータ構造の一例を示した図である。
デバイス登録データ９００は、デバイスの階層型位置情報がセットされたロケーション情報ＴＡＧ９０１（９０２〜９１１）と、デバイスの属性情報がセットされたデバイス属性情報ＴＡ９１２（９１３〜９１４）とを含んでいる。
各デバイスは、電源投入後、自身のデバイス登録データ９００をサーバ装置１１２へ送信する。
【００７３】
尚、デバイスが自身のデバイス登録データ９００を送信する動作は、デバイス登録データ９００内の項目に変更が生じたことに応じて実行されてもよいし、デバイスがネットワークにプラグインされたことに応じて実行されてもよいし、定期的に送信動作を実行するものであってもよい。また、サーバ装置１１２からの問い合わせに応じて、デバイスがデバイス登録データ９００を送信するものであってもよい。
【００７４】
サーバ装置１１２は、デバイスからのデバイス登録データ９００の受信に応じて、受信したデバイスに関する情報をデータベース８００へ登録する。
【００７５】
尚、上記図１０のデバイス登録データ９００は、デバイス「ＬＢＰ１１１０」についてのデバイス登録データであるが、ＬＢＰ１１１０側に階層型位置情報が未だ登録されていない場合には、“９０３”及び“９０４”〜“９１１”についてはデータがセットされていない状態、或いは意味のないデータがセットされた状態でサーバ装置１１２へ送信される。
【００７６】
図１１は、クライアント装置１１１からデバイス検索を行う場合の検索条件入力画面の一例を示したものである。
上記図１１において、“１００１ａ”、“１００１ｂ”、及び“１００１ｃ”へ検索のエントリが入力される。このときの入力は、例えば、プルダウンメニューから所望するものを選択して入力することが可能である。
“１００２ａ”、“１００２ｂ”、“１００２ｃ”には、各エントリに対応ずる属性情報が入力される。
【００７７】
例えば、エントリがデバイスとして選択された場合には、属性情報は、プリンタ（ｐｈｎｔｅｒ）、ＭＦＰ（ＭＦＰ）、スキャナ（ｓｃａｍｅｒ）の何れかがプルダウンメニューとして表示され、ユーザはその中から検索したい属性情報を選択することになる。
【００７８】
上記の各種入力が終了すると、入力ボタン１００３及び１００４によって、検索条件を入力する。
ボタン１００３は、条件のＡＮＤで検索することを示し、ボタン１００４は、条件のＯＲで検索することを示す。
ユーザは、上記検索条件を入力した後、検索開始ボタン１００５により検索を実行する。
【００７９】
図１２は、上記検索入力画面の具体例を示す図である。
上記図１２では、属性情報としてデバイスがプリンタで、且つ、カラー出力が可能であるデバイスの検索を行うことになる。
また、階層型位置情報として、例えば、設置フロアが２階であるプリンタを検索する場合には、“１００１ｃ”へ「フロア」を入力し、“１００２ｃ”へ「２Ｆ」を入力すればよい。さらに、２階フロアの、より詳細な場所を指定して検索したい場合には、例えば、“１００１ｃ”へ「ブロック」を入力し、“１００２ｃ”へ「２−１」を入力して検索を実行すれば、設置ブロックが２−１であるプリンタの検索を行うことができる。
【００８０】
図１３は、上記検索の例の検索条件を表した式を示す図である。
上記図１３では、デバイス端末装置（ＤＶ）がプリンタ（ｐｒｎｔｅｒ）で、カラー出力（ｃｏｌｏｒ）が可能（ＴＲＵＥ）である条件を示している。
【００８１】
ここで、上記図１３に示した検索条件式を受信したサーバ装置１１２が、「ＦＬ＝２Ｆ」という式をどのように評価するかについて説明する必要がある。なぜならば、２Ｆフロアという位置条件は、ユーザが所望している検索対象である「東京支店のＡＡビル」の２Ｆに設置されているデバイスが満足するのみならず、「大阪支店のＹＹビル」の２Ｆに設置されているデバイスもその条件を満足する。このため、ユーザにとっては興味が無い「大阪支店のｗビル」のデバイスまでも検索ヒットすることになってしまい、ユーザにとって極めてわかり難い検索結果が出力されてしまう。
【００８２】
そこで、上記の状況を回避するためには、フロア階層（ＦＬ）より上位階層が自動的に特定される仕組みをサーバ装置１１２が備えている必要がある。
この仕組みの一例として、サーバ装置１１２自身の階層型位置情報を保持させてフロア階層（ＦＬ）から上の階層の検索条件については、サーバ装置１１２の階層型位置情報を適用する方法がある。
【００８３】
上記の方法によれば、「東京支店のＡＡビル」に設置されているサーバ装置１１２に対して、「ＦＬ＝２Ｆ」の条件で検索依頼を発行すると、ＡＡビルの２Ｆフロアのデバイスのみを検索対象とすることが可能となる。
また、「大阪支店のＹＹビル」の２Ｆに設置されているデバイスを検索対象としたい場合には、「大阪支店のＹＹビル」に設置されているサーバ装置１１２に対して「ＦＬ＝２Ｆ」の条件で検索依頼を発行すればよい。
【００８４】
尚、上記図１２に示した画面では、１の階層のみを指定すれば指定階層からのみだが、最上位層（Ｃ）から所定階層までを指定する所謂フルパス指定にしてもよい。
この場合、上記図１３に示した検索条件式は、最上位階層からのフルパス指定（例えば、Ｃ：ＪＰ、Ｏ＝ＡＢＣ、ＢＲ＝東京支店…）となる。
このようなフルパス指定を用いれば、「東京支店のＡＡビル」に設置されているサーバ装置１１２により、「大阪支店のＹＹビル」の２Ｆに設置されているデバイスを検索させることも可能となる。
【００８５】
図１４は、上記図１３に図示した検索条件式に合致するデバイスをサーバ装置１１２がクライアント装置１１１へ返送する検索結果の一例である。
サーバ装置１１２は、クライアント装置１１１から受信した上記図１３の検索条件式に基づいて、データベース８００（上記図９参照）内を検索して、合致したデバイス情報を検索結果１３００としてクライアント装置１１１へ返送する。
検索結果１３００には、階層型位置情報１３０１〜１３１０とデバイス属性情報１３１１〜１３１２とが含まれておいる。
検索条件に合致するデバイスが複数存在する場合には、検索結果１３００には、複数のデバイスの階層型位置情報１３０１〜１３１０とデバイス属性情報１３１１〜１３１２と含まれることになる。
【００８６】
ここでは、一例として、上記図１３に図示した検索条件式に合致するデバイスがＬＢＰ１１１０のみであることから、上記図１４に示した検索結果１３００の情報のみがクライアント装置１１１へ返送されることになる。
【００８７】
図１５は、クライアント装置１１１が有する階層型位置情報のブロック階層（ＢＬ）とレイアウトビットマップ（ｂｉｔｍａｐ）の対応リストである。
このような対応リストを用いることにより、クライアント装置１１１側で、階層型位置情報からレイアウトビットマップを特定することが可能となる。
【００８８】
本実施の形態では、ブロック１−１，１−２，２−１，２−２のそれぞれに対応して、図１６、図１７、図１８、及び図１９に示すようなレイアウトビットマップを保持している。
また、その他のブロックについては、図２０のレイアウトビットマップを表示することになる。
【００８９】
すなわち、上記図１６〜上記図１９は、各ブロック階層に対応するレイアウトビットマップを示したものである。
本実施の形態では、これらのレイアウトビットマップ上に検索したデバイスを示す情報を重ねて表示することによって、検索要求があったデバイスがどのフロアのどのブロックのどの位置にあるかを視覚的に示すことができるようにしている。
【００９０】
上記図２０は、デバイスが階層型位置情報を保持していない場合や、クライアント装置１１１が有するレイアウトビットマップが合致しない場合に表示するレイアウトビットマップ（以下、「ｕｎｋｎｏｗｎＭＡＰ」と言う）である。
上記図２０において、“１９０１”のエリアにはレイアウトビットマップがないことを示し、“１９０２”のエリアには階層型位置情報を持たない、又は階層型位置情報が合致しないデバイスを表示させる。
【００９１】
図２１は、クライアント装置１１１が保持している、各デバイスを表示するためのデバイスアイコンである。
ここでのデバイスアイコンは、各デバイス名（ＮＭ）と一対一で対応づけられており、デバイス名が不明なものに対しては、ｕｎｋｎｏｗｎを示すデバイスアイコンが表示されることになる。
【００９２】
図２２は、クライアント装置１１１が、レイアウトビットマップ上にデバイスアイコンを表示する仕組みを示した図である。
クライアント装置１１１は、サーバ装置１１２から取得した検索結果から階層型位置情報とデバイス属性情報を抽出し、それぞれに対応したレイアウトビットマップとデバイスアイコンとを選択する。そして、クライアント装置１１１は、上記抽出した階層型位置情報から、上記選択したレイアウトビットマップの座標情報を得ることができるので、例えば、上記選択したレイアウトビットマップの座標「１０Ｘ＋１０Ｙ」へカラープリンタ１０１（ＬＢＰ１１１０）を表すデバイスアイコン２００２を重ねて表示する。
このようにレイアウトビットマップの対応する座標へデバイスアイコンを重ねて表示することにより、検索要求があったデバイスの位置をユーザにわかりやすく示すことが可能となる。
【００９３】
図２３は、デバイス検索の結果、クライアント装置１１１にて表示されるビットマップの一例を示している。この表示により、カラー出力可能なプリンタ１０１は、２Ｆの２−１ブロックの入り口に近いテーブル付近にあることが分かる。
【００９４】
図２４は、本実施の形態におけるカラーＬＢＰ１１１０（上記図２のプリンタ１０１）の内部構成を示すブロック図である。
上記図２４に示すように、プリンタ１０１は、システムバス２３０１に対して、プログラムを処理するＣＰＵ２３０２、プログラムが格納されているＲＯＭ２３０３、及びプログラムのワーク領域やバッファ領域等となるＲＡＭ２３０４等が接続された構成としている。
【００９５】
また、上記図２４において、“２３０５”は、ＬＢＰエンエンジンコントローラであり、このコントローラ２３０５を介して、エンジン２３０９が接続されている。
“２３０６”は、パネルコントローラであり、このパネルコントローラ２３０６は、パネル２３１０ヘの入出力をコントロールし、パネル２３１０を管理している。
【００９６】
さらに、本実施の形態におけるカラーＬＢＰ１１１０は、ハードディスク（ＨＤ）２２１１を保持し、印刷データを一時的にＨＤ２２１１内にスプールすることが可能となっている。
“２３０７”は、ディスクコントローラであり、ＨＤ２２１１を管理している。
【００９７】
“２３０８”は、ネットワークインターフェースコントローラであり、このコントローラ２３０８を介して、プリンタ１０１がネットワーク１００に接続される。
【００９８】
“２３１２”は、不揮発性ＲＡＭ（ＮＶＲＡＭ）であり、プリンタ１０１の電源が遮断されてもデータが保持される。
本実施の形態では、ＮＶＲＡＭ２３１２へ階層型位置情報や属性情報等を保持するようにしている。
【００９９】
図２５〜図２９は、本実施の形態におけるネットワークシステムでの処理手順を説明するためのフローチャートである。
以下、フローチャートを用いて、本実施の形態でのネットワークシステムの動作について具体的に説明する。
【０１００】
まず、上記図２５に示すフローチャートを用いて、デバイスの階層型位置情報の登録処理について説明する。
ここでは、一例として、プリンタ１０１（ＬＢＰ１１１０）の動作に着目してその説明をする。
【０１０１】
ＬＢＰ１１１０は、階層型位置情報および属性情報をデバイス内の不揮発性ＲＡＭ（２３１２）に保時している。ＬＢＰ１１１０のＣＰＵ２３０２は電源が投入されると、サーバ装置１１２への接続を行う（ステップＳ２８０１）。
この接続後、ＬＢＰ１１１０の不揮発性ＲＡＭ（２３１２）から階層型位置情報および属性情報を読み込み、上記図１０に示したような形式でサーバ装置１１２への登録を行う（ステップＳＳ２８０２）。
【０１０２】
上記の登録後、ＬＢＰ１１１０のＣＰＵ２３０２は、サーバ装置１１２との接続を解放する（ステップＳ２８０３）。
【０１０３】
上述のような手順を踏み、それぞれのデバイスはそれぞれ、電源投入後に、階層型位置情報及び属性情報をサーバ装置１１２へ登録する。
【０１０４】
つぎに、サーバ装置１１２の処理について、上記図２６のフローチャートを用いて説明する。
ここでは、サーバ装置１１２は、例えば、イベント駆動型のプログラムで構成され、イベントが発生するとそのイベントを解析して、対応する処理を行う。
【０１０５】
サーバ装置１１２は、電源が投入されると、最初に受信ポートをオープンする（ステップＳ２４０１）。
次に、サーバ装置１１２は、イベントを取得し（ステップＳ２４０２）、その取得したイベントが終了コマンドであるか否かを判断する（ステップＳ２４０３）。この判断の結果、上記取得したイベントが終了コマンドであった場合には、受信ポートをクローズし（ステップＳ２４０４）、本処理を終了する。
【０１０６】
一方、ステップＳ２４０３の判断の結果、終了コマンドでない場合には、サーバ装置１１２は、それが検索要求がどうかを判断する（ステップＳ２４０５）。ここで、検索要求であった場合には、ステップＳ２４０６でデータベースの検索処理を行う。
【０１０７】
一方、ステップＳ２４０５の判断の結果、検索要求ではなかった場合、サーバ装置１１２は、ステップＳ２４０７において、データベースヘの登録要求であるか否かを判断する。この判断の結果、登録要求であった場合、サーバ装置１１２は、受信したデータを、上記図９に示したテーブル８００上に登録する（ステップＳ２４０８）。この登録されたデータは、ＨＤ２１１で保持される。
また、ステップＳ２４０７の判断の結果、他の要求であった場合には、その他の処理を行う（ステップＳ２４０９）。
【０１０８】
つぎに、上記図２７を用いて、サーバ装置１１２で実行されるデータ検索処理について、より詳細に説明する。
【０１０９】
先ず、サーバ装置１１２は、全ての検索条件を処理したか否かを判断する（ステップＳ２５０１）。
この判断の結果、検索条件が全て終了するまで、本処理を繰り返すことになる。
【０１１０】
ステップＳ２５０１の判別の結果、受信パケット内の全ての検索条件を検索し終わった場合、サーバ装置１１２は、その結果をクライアント装置１１１へ送信し（ステップＳ２５０２）、本処理終了とする。
【０１１１】
ステップＳ２５０１の判別の結果、受信パケット内の全ての検索条件を検索し終えていない場合、サーバ装置１１２は、受信パケットから検索条件を取り出す（ステップＳ２５０３）。
そして、サーバ装置１１２は、その検索条件について、上記図９に示したテーブルの全ての登録デバイス情報を検索したかを判断する（ステップＳ２５０４）。
【０１１２】
ステップＳ２５０４の判断の結果、全ての登録デバイス情報を検索した場合、サーバ装置１１２は、次の検索条件を取り出すために、ステップＳ２５０１へ戻る。
【０１１３】
ステップＳ２５０４の判断の結果、全ての登録デバイス情報を検索し終えていない場合、サーバ装置１１２は、ｎ個目のデバイス情報をＨＤ２１１から取り出す（ステップＳ２５０５）。
そして、サーバ装置１１２は、上記取り出したデバイス情報が条件に一致したかどうかを判断する（ステップＳ２５０６）。
【０１１４】
ステップＳ２５０６の判断の結果、一致した場合には、サーバ装置１１２は、そのデバイス情報を取得し（ステップＳ２５０７）、結果に追記する（ステップＳ２５０８）。その後、ステップＳ２５０４へ戻る。
【０１１５】
ステップＳ２５０６の判断の結果、一致しなかった場合には、サーバ装置１１２は、次のデバイスについて処理を行うために、ステップステップＳ２５０４へ戻る。
【０１１６】
上述のような処理により、サーバ装置１１２は、それぞれの検索条件について、上記図９に示したテーブル８００内のデバイスを全て検索し、その結果をクライアント装置１１１へ送信する。
【０１１７】
つぎに、上記図２８を用いて、クライアント装置１１１での全体動作について説明する。
ここでは、クライアント装置１１１は、例えば、イベント駆動型のプログラムで構成され、イベントが発生するとそのイベントを解析して、対応する処理を行う。
【０１１８】
先ず、クライアント装置１１１は、イベントの取得を行う（ステップＳ２６０１）。ここで、終了コマンドのイベントを受信した場合には、そのまま終了する（ステップＳ２６０２）。
【０１１９】
クライアント装置１１１では、上記図１１に図示したような検索条件入力画面より、ユーザから検索条件が入力されることになる。ユーザが検索開始ボタン１００５をクリックすることによって、そのイベントが発生することになる。
【０１２０】
ステップＳ２６０３で検索コマンドの発行要求であった場合には、クライアント端末装置１１１は、検索要求をサーバ装置１１２へ送信する（ステップＳ２６０４）。
【０１２１】
このとき、上記図１２及び上記図１３に示したような検索条件式をもって、サーバ端末装置１１２へ問い合わせることになる。また、この検索条件式をＨＤ２１１に保存しておくことによって、次回のデバイス検索時には、当該条件式用いることができる。この場合、ユーザからの検索条件再入力を省くことが可能となる。
【０１２２】
次に、クライアント装置１１１は、サーバ装置１１２からの検索結果待ちとなり、そのイベントを受信した場合にはステップＳ２６０５で判断する。
ステップＳ２６０５の判断において、上記図１４に示したような検索結果を受信した場合、検索結果表示処理を行う（ステップＳ２６０６）。
また、その他のイベントを受信した場合には、他の処理を行うことになる（ステップＳ２６０７）。
【０１２３】
つぎに、上記図２９のフローチャートを用いて、上記図２８のステップＳ２６０６での検索結果表示処理をより詳細に説明する。
【０１２４】
先ず、最初のステップＳ２７０１で、全ての検索結果を処理し終わったかどうかを判断する。この判断の結果、全ての処理が終わったと判断した場合には、本処理終了とする。
【０１２５】
一方、ステップＳ２７０１の判断の結果、全ての処理が終わっていない場合には、ステップＳ２７０２に進み、受信した検索結果から階層型位置情報を取得する。そして、上記取得した階層型位置情報を元に、クライアント装置１１１がマップの表示が可能かどうかを判断する（ステップＳ２７０３）。
【０１２６】
本実施の形態では、デバイスを表示可能な階層型位置情報は、上記図１５において符号“１４０１”で示した情報を含む階層型位置情報である。これを含まない階層型位置情報であった場合には、ｕｎｋｎｏｗｎＭＡＰが表示済みであるかどうかを確認し（ステップＳ２７０９）、上記図２０に図示したｕｎｋｎｏｗｎデバイスを表示する（ステップＳ２７１０）。
【０１２７】
さらに、階層型位置情報からＮＭ情報を取得し（ステップＳ２７１１）、上記図２０において符号“１９０２”のエリアへＮＭに対応するデバイスアイコンを表示する。この場合、デバイスが正常に表示されなかった、すなわち、階層型位置情報がまだ登録されていないデバイスがここに表示されることになる
【０１２８】
一方、ステップＳ２７０３でデバイス端末表示可能と判断された場合には、階層型位置情報内のＢＬ情報を取得する（ステップＳ２７０４）。クライアント装置１１１は、ＢＬ情報を、上記図１５に示したＢＬ情報テーブルと照らし合わせて、必要なレイアウトビットマップを表示しようとするのである。
【０１２９】
ここで、対応したレイアウトビットマップが既に表示済みであるかどうかを判断する（ステップＳ２７０５）。この判断の結果、未だ表示していない場合には、対応するビットマップを表示する（ステップＳ２７０６）。そして、階層型位置情報からＮＭ情報とマップ情報を取得する（ステップＳ２７０７）。
【０１３０】
また、ステップＳ２７０５の判断の結果、表示済みであった場合には、ステップＳ２７０７に進む。ＮＭ情報から対応するデバイスアイコンを、上記図２１のテーブルから読み込む。また、マップ情報からそのデバイスアイコンをどこに表示するかを決定する。
【０１３１】
本実施の形態では、サーバ装置１１２より、検索結果として上記図１４に示したような結果が返送されてきているので、ＮＭはＬＢＰ１１１０であり、そのデバイスは「１０Ｘ＋１０Ｙ」であることから、上記図２２に示したような位置にデバイスアイコンを表示する（ステップＳ２７０８）。このデバイスアイコンを、先のレイアウトマップに重ねて表示すること１こよって、上記図２３に示したような検索結果がクライアント装置１１１のディスプレイに表示される。
【０１３２】
上述のような処理により、上記図５〜上記図８に示したようなレイアウトビットマップにがクライアント装置１１１のディスプレイ上に表示され、ユーザは検索されたデバイスの詳細な位置情報を得ることができる。
その後、クライアント装置１１１のユーザは、検索された複数のデバイスから所望のデバイスを選択して、その選択したデバイスに対してジョブを送信する。例えば、デバイスがプリンタであれば印刷ジョブを送信し、デバイスがＦＡＸであれば送信ジョブ等を送信する。
【０１３３】
図３０は、クライアント装置１１１が発行する印刷ジョブ情報の一例を示す図である。
上記図３０において、“３１０１”は、以下に続く情報がジョブ属性情報であることを示すジョブ特性ＴＡＧである。“３１０２”〜“３１０５”には、印刷ジョブ情報が続いている。
“３１０２”は、ジョブを投入されたデバイスやクライアント装置１１１がジョブを特定するためのジョブＩＤてあり、上記図３０では、ジョブＩＤが「１２３４」であることを示している。
【０１３４】
図３１は、デバイスが受信したジョブを管理するためのジョブ管理テーブル３２００である。
ジョブ管理テーブル３２００には、各ジョブごとにクライアント装置１１１へ通知すべきイベント条件と、その通知先のネットワークアドレス等とが対応付けて記憶されている。
【０１３５】
デバイスは、上記図３０に示した印刷ジョブを受信すると、当該ジョブに記述された情報に基づいて、当該ジョブをジョブ管理テーブル３２００へ記憶する。そして、デバイスは、ジョブを実行し、クライアント装置１１１へ通知すべきイベントの発生を検出すると、当該イベントをクライアント装置１１１へ通知する。
【０１３６】
図３２は、デバイスからクライアント装置１１１へ通知されるイベント通知のフォーマットの一例を示している。
このイベント通知フォーマット３３０１は、印刷ジョブが終了したときに「ＴＣＰ／ＩＰ：１９２．１．２．１６：１０２５」で示されるクライアント装置へイベント通知行うものであり、上記図１４で示した階層型位置情報３３０２が付加されている。
【０１３７】
図３３は、「ＪＯＢ ＩＤ＝１２３４］のジョブが終了したときに、クライアント装置１１１の表示装置２７上に表示される画面の一例を示したものである。
上記図３３では、印刷が終了したことを文字情報（「印刷を終了しました…」で表示されている。
【０１３８】
図３４は、クライアント装置１１１において、上記画面表示に至るまでの処理手順を示すフローチャートである。
【０１３９】
先ず、イベント通知受信処理が開始されると、最初のステップＳ３５０１において、入力情報がイベント通知か否かを判断する。この判断の結果、入力情報がイベント通知でなかった場合には本処理を終了する。
【０１４０】
また、上記入力情報がイベント通知であった場合にはステップＳ３５０２に進み、受信したイベント情報３３０１からロケーション情報（階層型位置情報）を取得する。そして、上記取得した階層型位置情報を元に、クライアント装置１１１がレイアウトビットマップの表示が可能かどうかを判断する（ステップＳ３５０３）。
【０１４１】
本実施の形態でが、デバイスを表示可能な階層型位置情報は、上記図１５にて符号“１４０１”で示した情報を含む階層型位置情報である。これを含まない階層型位置情報であった場合には、上記図２０に図示したｕｎｋｎｏｗｎＭＡＰを表示する（ステップＳ３５１０）。
【０１４２】
さらに、階層型位置情報からＮＭ情報を取得し（ステップＳ３５１１）、上記図２０に示した符号“１９０２”のエリアへＮＭに対応するデバイスアイコンを表示する（ステップＳ３５１２）。この場合には、デバイスが正常に表示されなかった、すなわち階層型位置情報がまだ登録されていないデバイスがここに表示されることになる。
【０１４３】
一方、ステップＳ３５０３でデバイス端末表示可能と判断された場合には、階層型位置情報内のＢＬ情報を取得する（ステップＳ３５０４）。そして、クライアント端末装置１１１は、上記取得したＢＬ情報を、上記図１５に図示したＢＬ情報テーブルと照らし合わせて、必要なレイアウトビットマップを表示する（ステップＳ３５０５）。
【０１４４】
上述のような処理を行うことにより、上記図３３でに示したような、「印刷を終了しました。ＪＯＢ ＩＤ＝１２３４」等の、発生したイベント情報をユーザに分かりやすく表示することが可能となる。
【０１４５】
次に、階層型位置情報からＮＭ情報とマップ情報を取得する（ステップＳ３５０６）。本実施の形態では、ＮＭはＬＢＰ１１１０であり、そのデバイスアイコンにより示されるデバイスの座標が「１ＯＸ＋１０Ｙ」であることから、上記図２２に示したような位置にデバイスアイコンを表示する（ステップＳ３５０９）。このデバイスアイコンを、先のレイアウトマップへ重ねて表示することによって、イベント通知を発行したデバイスを、上記図２３に図示したように表示することが可能となる。
【０１４６】
図３５は、デバイスにおける全体動作を示すフローチャートである。
先ず、最初のステップＳ３６０１でイベントの取得を行う。そして、上記取得したイベントが終了コマンドのイベントであるか否かを判断する（ステップＳ３６０２）。この判断の結果、上記受信したイベントが終了コマンドであった場合にはそのまま本処理を終了する。
【０１４７】
一方、ステップＳ３６０２の判断の結果、上記受信したイベントが終了コマンドでなかった場合には、ステップＳ３６０３へ進み、それがイベント登録要求であるか否かを判断する。この判断の結果、そうならばステップＳ３６０４に進みイベント登録処理を行う。
【０１４８】
一方、ステップＳ３６０３の判断の結果、イベント登録要求でない場合にはステップＳ３６０３からステップＳ３６０５へ進み、ジョブ処理要求を受信したか否かを判断する。この判断の結果、ジョブ（印刷ジョブ）処理要求であった場合にはステップＳ３６０６へ進み、印刷処理を実行する。また、ステップＳ３６０５の判断の結果、上記受信したイベントがジョブ処理要求でなかった場合にはステップＳ３６０７に進んで他の処理を行う。
【０１４９】
図３６は、デバイスでのイベント発生時の処理手順を示すフローチャートである。
先ず、イベントが発生したら、それがジョブ関係のイベントであるか否かを判断する（ステップＳ３７００）。
【０１５０】
次に、ステップＳ３７０１に進み、対応する「ＪＯＢ ＩＤ」の通知条件を判断する。この判断の結果に基づいて、ステップＳ３７０１において条件が一致したか否かを判断し、一致した場合には場合にはステップＳ３７０３に進み、階層型位置情報を取得する。
【０１５１】
次に、ステップＳ３７０４に進み、通知パケットを作成し、この作成した通知パケットを指定されたアドレスに通知する（ステップＳ３７０５）。
次に、ステップＳ３７０６において、ジョブが終了か否かを判断し、終了の場合にはステップＳ３７０７へ進みジョブ管理テーブル（上記図３１参照）から該当する「ＪＯＢ ＩＤ」のエントリを削除する処理を行う。
【０１５２】
上述のように、本実施の形態によれば、ユーザが発行したジョブについてのイベント情報を、そのイベントが発生したデバイスの場所とともにわかりやすく通知することが可能となる。
特に、クライアント装置１１１がユーザを介さず自動時にジョブの依頼先のデバイスを選択するような場合には、そのユーザにとって設置場所がわからないデバイスが選択されることもある。このような場合に、そのユーザに対して、わかりやすいデバイスの位置を通知することが可能となる。
【０１５３】
尚、デバイスに依頼されたジョブは、そのジョブについてのイベントの通知先であるクライアント装置１１１から直接依頼されたジョブに限らない。すなわち、クライアント装置からのジョブが第３の装置から転送されたものであってもよい。
【０１５４】
＜第２の実施の形態＞
第１の実施の形態では、検索されたデバイスの位置を表現するためのレイアウトビットマップをクライアント装置１１１が保持しているように構成したが、本実施の形態では、レイアウトビットマップをサーバ装置１１２が保持する。
【０１５５】
尚、本実施の形態は、第１の実施の形態をベースとしているため、ここでは、第１の実施の形態と異なる構成について具体的に説明する。
【０１５６】
本実施の形態では、上記図１６〜上記図２０で示したレイアウトビットマップ、上記図１５で示した階層型位置情報とレイアウトビットマップの対応テーブル、及び上記図２１で示したデバイスアイコンの情報は、サーバ装置１１２のハードディスクに格納されている。
そこで、まず、クライアント装置１１１の動作について、第１の実施の形態と異なる部分を説明する。
【０１５７】
図３７は、クライアント装置１１１の検索結果表示の処理を示すフローチャートである。
最初のステップＳ５００１で、すべての検索結果を処理し終わったかどうかを判断する。この判断の結果、全ての処理が終わったと判断した場合にはその処理は終了となる。
【０１５８】
一方、ステップＳ５００１の判断の結果、全ての処理が終わっていない場合には、ステップＳ５００２に進み、受信した検索結果から階層型位置情報を取得する。
次に、サーバ装置１１２へ接続し（ステップＳ５００３）、上記取得した階層型位置情報に対応するマップ情報を取得する（ステップＳ５００４）。
【０１５９】
次に、階層型位置情報に対応したマップは表示済か否かを判断する（ステップＳ５００５）。この判断の結果、未だ表示していない場合には対応したレイアウトマップを取得する（ステップＳ５００６）。
さらに、階層型位置情報からＮＭ情報とマップ情報を取得し（ステップＳ５００７）、上記取得したＮＭ情報とマップ情報に対応したデバイスビットマットを取得する（ステップＳ５００８）。
【０１６０】
次に、上記取得したデバイスビットマットをマップ上の所定位置に表示し（ステップＳ５００９）、その後にサーバ装置１１２との接続を切断する（ステップＳ５０１０）。
【０１６１】
図３８は、クライアント装置１１１がデバイスから受信したイベント通知に基づいて表示を行う処理のフローチャートである。
先ず、イベント通知受信処理が開始されると、ステップＳ５１００において、入力情報がイベント通知か否かを判断する。この判断の結果、入力情報がイベント通知でなかった場合には処理を終了する。
【０１６２】
一方、上記入力情報がイベント通知であった場合にはステップＳ５１０１に進み、サーバ装置１１２へ接続する。
次に、対応したマップが表示済みか否かを判断し、まだ表示していない場合には対応したレイアウトビットマップをサーバ装置１１２から取得する（ステップＳ５１０３）。
さらに、階層型位置情報からＮＭ情報を取得し（ステップＳ５１０４）、対応したデバイスアイコンを取得する（ステップＳ５１０５）。
【０１６３】
次に、上記取得した情報に基づいて、デバイスアイコンを受信した座標情報に基づいてレイアウトマップ上に表示する（ステップＳ５１０６）。
【０１６４】
次に、サーバ装置１１２との接続を切断するとともに（ステップＳ５１０７）、イベント情報と「ＪＯＢ ＩＤ」を取得する。そして、上記取得したイベント情報及び「ＪＯＢ ＩＤ」を表示する。これにより、上記図３３に示したような表示を実現することができる。
【０１６５】
つぎに、サーバ装置１１２の動作について、第１の実施の形態と異なる部分を説明する。
【０１６６】
図４０は、サーバ装置１１２におけるレイアウトビットマップの検索処理を示したフローチャートである。
先ず、最初のステップＳ５２０１において、検索要求がレイアウトマップの検索要求であるか否かを判断する。
【０１６７】
上記の判断の結果、レイアウトマップの検索要求であった場合にはステップＳ５２０２に進み、クライアント装置１１１から受信した階層型位置情報はマップ表示可能か否かを判断する。そして、表示可能であると判断した場合にはステップＳ５２０３において、上記図１５に示した対応テーブルから該当するレイアウトビットマップをロードし、上記取得したマップをクライアント装置１１１に返送して処理を終了する。
【０１６８】
一方、ステップＳ５２０２の判断の結果、マップ表示が不可能である場合には、ステップＳ５２０５に進み、上記図２１に示したｕｎｋｏｗｎＭＡＰを表示する。
【０１６９】
また、ステップＳ５２０１の判断の結果、検索要求がレイアウトマップの検索要求でなかった場合には、ステップＳ５２０６に進んでデバイスアイコンの検索要求であるか否かを判断する。
【０１７０】
上記の判断の結果、デバイスビットマップの検索要求であった場合には、ステップＳ５２０７に進み、上記図２１に示したテーブルから該当するデバイスアイコンをロードして、クライアント装置１１１へ返送する（ステップＳ５２０４）。
【０１７１】
尚、第１の実施の形態では、レイアウトビットマップをクライアント装置１１１に保時させるように構成したので、検索結果をクライアント装置１１１で表示するときに、サーバ装置１１２からクライアント装置１１１へレイアウトビットマップを転送しなくても済み、表示を行う際の処理及び時間を軽減することができるとともに、ネットワークシステムのトラフィックを軽減することができるという効果がある。
一方、本実施の形態では、レイアウトビットマップをサーバ装置１１２が保するように構成したので、サーバ装置１１２においてマップ情報を一元で管理することができ、クライアント装置１１１ごとにマップ情報を保持する必要を無くして、更新等のメンテナンスを容易にできるとともに、クライアント装置１１１のメモリリソースの負荷を減らすことができるという効果がある。
したがって、ネットワーク１００の負荷やクライアント装置１１１の能力等を考慮することで、適宜、第１の実施の形態或いは本実施の形態を採用すればよい。
【０１７２】
＜第３の実施の形態＞
第１及び第２の実施の形態では、ブロック（ＢＬ）階層に対応したレイアウトビットマップのみを保持するように構成したが、本実施の形態では、階層型位置情報の各階層に対応するレイアウトビットマップを保持して、それをクライアント装置１１１の検索結果表示に反映する。
本実施の形態によれば、建物レベルのラフな位置情報から、フロアの１区画のような詳細な位置情報まで、ユーザの好みに応じた階層のレイアウトビットマップに検索されたデバイスを表示させることが可能となる。
【０１７３】
尚、本実施の形態では、第１の実施の形態のようにレイアウトビットマップをクライアント装置１１１が保持するものとするが、第２の実施の形態のようにレイアウトビットマップをサーバ装置１１２が保時するようにしてもよい。
【０１７４】
図４０は、検索する各階層に対応するＭＡＰリストである。
上記図４０の下半分のリストは、上記図１５に相当するリストである。
本実施の形態では、デバイスビットマップを表示する場合、検索する階層の属性のすぐ下の属性情報に基づいて、デバイスを表示する。階層の上下関係については、上記図４に示した階層の上下関係と同様である。
【０１７５】
例えば、ＢＵ＝ＡＡビルですべてのデバイスを検索する場合には、そのすぐ下の属性ＦＬ（上記図４参照）をそのデバイスを表示するための位置情報として、レイアウトマップ上に表示する。
【０１７６】
例えば、ＡＢＣ商事にある全てのデバイスの検索を行う場合、上記図１１に示した入力画面上で、“１００１ａ”に会社名（Ｏ）をプルダウンメニューから選択し、その属性値として“１００２ａ”にＡＢＣ商事を入力して、検索開始ボタン１００５により検索開始をユーザーが実行する。
【０１７７】
クライアント装置１１１は、上述したような手順によって、検索結果をサーバ装置１１２から取得し、当該検索結果に基づき、デバイスビットマップをレイアウトビットマップに表示する。
【０１７８】
このときのクライアント装置１１１での表示処理は、図４１のフローチャートで示される。
先ず、本処理が開始されると、最初のステップＳ６００１で検索結果全ての表示が終了したか否かを判断し、処理が終わるまで、本処理を全て繰り返すことになる。
【０１７９】
ステップＳ６００１の判断の結果、検索を全て終了していない場合には、ステップＳ６００２において、検索結果から属性ＮＭを取得する。これは、ステップＳ６００８やステップＳ６０１０、或はステップＳ６０１３でデバイスアイコンを表示するために行う処理である。
【０１８０】
次に、ステップＳ６００３で検索した条件の属性に対応したレイアウトビットマップが表示済みかどうかを判断する。この例では、属性Ｏ＝属性値ＡＢＣ商事で検索実行したことから、ＭＡＰ対応リスト（上記図４１参照）から得られる、図４２に示すようなレイアウトビットマップ上に、検索結果のデバイスを表示することになる。
上記図４２のレイアウトビットマップが表示済みかどうかを判断する。この判断の結果、まだ表示していない場合には、ステップＳ６００４において表示を行い、ステップＳ６００５の処理に移行する。
【０１８１】
ステップＳ６００３の判断の結果、上記図４２のレイアウトビットマップをすでに表示済みであった場合にはステップＳ６００５の処理で、検索した属性の下層属性と属性値を検索結果から取得する。この取得した属性値が表示可能かどうかをステップＳ６００６で判断する。属性値の範囲外だったものや、属性値が入力されていないデバイスは表示不可能ということでステップＳ６０１１に進む。
【０１８２】
ステップＳ６０１１では、ｕｎｋｎｏｗｎＭＡＰが表示済みかどうかを判断し、未表示であった場合には、ステップＳ６０１２でｕｎｋｎｏｗｎＭＡＰを表示し、ステップＳ６００２で獲得したＮＭ値に対応するデバイスアイコンをｕｎｋｎｏｗｎＭＡＰのデバイス欄に表示することになる（ステップＳ６０１３）。
【０１８３】
一方、ステップＳ６００６の判断の結果、表示可能であった場合には、下層属性がＭＡＰ属性がどうかを判断する（ステップＳ６００７）。この判断の結果、ＭＡＰ属性でなかった場合には、ステップＳ６００８に進み、表示しているレイアウトビットマップ上の属性位置にステップＳ６００２で取得したＮＭ値に対応するデバイスアイコンを重ねて表示する。この場合、階層型ロケー一ション情報で（Ｏ）の階層下の階層ＢＲの属性値が、東京支店であることから（上記図４参照）、各デバイスは東京支店５００１の位置上に表示されることになる。その結果、上記図４２に示すような表示を得ることになる。
【０１８４】
また、より詳細にデバイスの位置を検索する場合、上記図１１に示した入力画面上で、“１００１ａ”にブロック名（ＢＬ）をプルダウンメニューから選択し、その属性値として“１００２ａ”へ２−１を選択し、検索開始ボタン１００５によりユーザが当該検索開始を実行する。
【０１８５】
クライアント装置１１１は、上述したような手順で、検索結果をサーバ装置１１２から取得する。サーバ装置１１２から獲得した検索結果に基づき、クライアント装置１１１は、デバイスビットマップをレイアウトビットマップ上に表示する。この時も、同様に、上記図４１で示される処理フローを実行する。この場合、スナッブＳ６００７で下層属性情報が、ＭＡＰ情報であることからステップＳ６００９に進む。
【０１８６】
ステップＳ６００９では、その座標範囲がレイアウトビットマップの範囲内かどうかを判断する。そして、範囲内であった場合には、ステップＳ６０１０で、表示しているレイアウトビットマップの座標位置にステップＳ６００２で獲得したＮＭ値に対応するデバイスアイコンを重ねて表示する。
【０１８７】
この場合、属性ＢＬ、属性値２−１で検索実行したことから、ＭＡＰ対応リスト（上記図４０参照）から得られる上記図１８のレイアウトビットマップ上に、検索結果のデバイスを表示することになる。
【０１８８】
階層ロケーション情報のＢＬの階層下の階層ＭＡＰであることから（上記図４参照）、検索結果の各デバイスは、そのレイアウト上の座標上に表示されることになる。この結果、上記図５に示したような表示を得ることになる。
【０１８９】
ここで、その他の各階層のレイアウトビットマップ図について説明する。
上述した説明したように、上記図４３は、属性Ｏ＝属性値ＡＢＣ商事で検索する場合のレイアウトビットマップを示したものである。属性Ｏの下層属性ＢＲが東京支店であるデバイスは５００１に表示され、大阪支店であるデバイスは５００２に表示される。
【０１９０】
図４３は、属性Ｏ＝属性値ＡＢＣ商事ですべてのデバイスを検索したときの結果表示である。
【０１９１】
図４４は、属性ＢＲ＝属性値東京支店で検索する場合のレイアウトビットマップである。属性値ＢＲの下層属性はＯＰであるが、これはＯＰＴＩＯＮがあることを示し、さらにもう一層下に詳細情報があることを示している。その属性ＢｕがＡＡビルであるデバイスは５２０１に表示される。
【０１９２】
図４５は、属性ＢＲ＝属性値東京支店ですべてのデバイスを検索したときの検索結果表示であり、ビル５３０２が表示される。
【０１９３】
図４６は、属性ＢＵ＝属性値ＡＡビルで検索した場合のレイアウトビットマップである。属性ＢＵの下層属性ＦＬが２Ｆであるデバイスはビットマップ５４０２に表示され、１Ｆであるデバイスはビットマップ５４０１に表示される。
【０１９４】
図４７は、属性ＢＵ＝属性値ＡＡビルですべてのデバイスを検索したときの結果の表示であり、２Ｆのビットマップ５５０２内に存在するデバイス、及び１Ｆのビットマップ５５０１内に存在するデバイスが全て表示される。
【０１９５】
図４８は、属性ＦＬ＝属性値２Ｆで検索した場合のレイアウトビットマップである。属性ＦＬの下層属性ＢＬが２−１であるデバイスはビットマップ５６０１に表示され、２−２であるデバイスはビットマップ５６０２に表示される。
【０１９６】
図４９は、属性ＦＬ＝属性値２Ｆですべてのデバイスを検索したときの結果表示であり、２Ｆ−１のビットマップ５７０１及び２Ｆ−２のビットマップ５７０２に存在するデバイスが全て表示される。
【０１９７】
図５０は、属性ＦＬ＝属性値１Ｆで検索した場合のレイアウトビットマップである。また、図５１は、属性ＦＬ＝属性値１Ｆで全てのデバイスを検索したときの結果の表示である。属性ＦＬの下層属性ＢＬが１−２であるデバイスはビットマップ５９０１１こ表示され、１−１であるデバイスはビットマップ５９０２に表示される。
【０１９８】
上述のように、本実施の形態によれば、ユーザーの検索要求レベルに応じて、詳細な表示から、おおまかな表示まで、ロケーション情報の各階層に応じた、検索とその表示を行うことが可能になる。
【０１９９】
＜第４の実施の形態＞
本実施の形態では、ネットワーク１００上のデバイスの位置をわかりやすくユーザに通知するとともに、そのデバイスの状態をユーザに通知する。
また、本実施の形態では、デバイスの状態をデバイスからポーリングすることにより取得する。
【０２００】
尚、本実施の形態は、第１の実施の形態をベースとするため、ここでは、第１の実施の形態と異なる構成について具体的に説明する。
【０２０１】
図５２は、クライアント装置１１１において各デバイスのデバイスアイコン情報を管理する管理テーブルを示したものである。
ここでのデバイスアイコン情報は、各デバイスごとにその状態を表す数種類のアイコン情報で構成される。
したがって、クライアント装置１１１は、デバイスから取得した状態に応じたデバイスアイコンを、上記図５２の管理テーブルから選択してレイアウトビットマップに表示する。
尚、上記図５２では、デバイス以外のＰＣ等のアイコンについても示されている。
【０２０２】
上記図５２では、各デバイス毎に、稼働中（Ｒｅａｄｙ）、紙切れ（Ｎｏ Ｐａｐｅｒ）、紙詰まり（Ｐａｐｅｒ Ｊａｍｍｅｄ）のそれぞれの状態に応じたデバイスアイコン情報が示されている。
それぞれのデバイスアイコン情報は、各デバイス名（ＮＭ）と対応づけられており、デバイス名が不明なものに対しては、ｕｎｋｎｏｗｎを示すデバイスアイコンが表示されることになる。
【０２０３】
図５３は、レイアウトビットマップ上に重ねて表示するデバイスアイコンの位置を示したものである。
例えば、座標情報「１０Ｘ＋１０Ｙ」のロケーション情報を持つプリンタ１０１（ＬＢＰ１１１０）は、上記図５３に示すような位置に、現在の状態に応じたビットマップアイコンの形で表示される。
上記図５３では、プリンタ１０１の状態が紙切れ（Ｎｏ Ｐａｐｅｒ）であることを示すデバイスアイコンが表示されている。
【０２０４】
上述のように、ビットマップアイコンとレイアウトビットマップとを合わせて表示することにより、検索されたデバイスの位置と当該デバイスの現在の状態とをユーザへ分かりやすく表示することが可能となる。
【０２０５】
図５４は、検索されたデバイスについて、その状態取得後にクライアント装置１１１に表示されるレイアウトビットマップを示したものである。
上記図５４に示すように、このレイアウトビットマップでは、カラー入出力が可能なプリンタ（ＬＢＰ１１１０）は２Ｆのブロック２−１の入口に近いテーブル付近にあることが視覚的に分かる。さらに、そのカラープリンタ１０１は、現在紙切れの状態であることも同時に知ることができる。
【０２０６】
図５５は、クライアント装置１１１における検索要求送信の処理を示すフローチャートである。
上記図５５に示す検索要求送信処理では、先ず最初に、上記図１２に示したような検索条件入力画面により入力された検索条件を取得し、上記図１３に示したような検索条件式の形式へと変換する（ステップＳ５６０１）。
次に、上記変換された検索条件式を含む検索要求パケットを生成し、サーバ装置１１２へ送信して問い合わせる（ステップＳ５６０２）。
【０２０７】
尚、上記検索条件式をハードディスク２１１に保存しておくことにより、次回の検索時に同じ条件でデバイス検索を行うときには、この保存しておいた検索条件式を用いることができる。これにより、ユーザが検索条件を再入力する手間を省くことも可能となる。
【０２０８】
図５６は、クライアント装置１１１のデバイス検索結果の処理を示すフローチャートである。
上記図５６において、デバイス検索の結果、検索条件に合致するデバイスが１つ以上発見されたか否かを判断する（ステップＳ５７０１）。ここで、検索条件に合致するデバイスが１つも発見されなかった場合は、該当するデバイスが発見されなかった旨のメッセージ（不図示）を表示し（ステップＳ５７０４）、本処理を終了する。
【０２０９】
一方、ステップＳ５７０１において、１つ以上のデバイスが発見されたと判断した場合は、その検索結果（該当するデバイスのロケーション情報及び属性情報）をハードディスク２１１に保存する。例えば、上記図１４に示したような検索結果が得られた場合、それをハードディスク２１１に保存することになる。その後、後述の状態取得プロセスを起動して（ステップＳ５７０３）、本処理を終了する。
【０２１０】
図５７は、上記図５６のフローチャートのステップＳ５７０３で起動される状態取得プロセスの動作を示したものである。
この状態取得プロセスは、クライアント装置１１１がある一定間隔でデバイスの状態を取得し、レイアウトビットマップ上に現在の状態に応じたデバイスアイコンを重ねて表示するためのプログラムである。
【０２１１】
状態取得プロセスが起動されると、先ず最初に、上記図５６のステップＳ５７０２でハードディスク２１１に保存された検索結果を参照し、すべての検索結果を処理し終わったかどうか、すなわち保存されている検索結果の中に含まれるすべてのＩＰアドレスのデバイスに対して状態取得の処理が終わったかどうかを判断する（ステップＳ５８０１）。
【０２１２】
ここで、全ての検索結果を処理し終わった場合には、検索処理で見つけられたデバイスの状態をある一定間隔で取得するためにポーリングタイマを起動し（ステップＳ５８１３）、その後、ステップＳ５８１４でポーリングタイマのタイムアウトイベント待ち状態となる。ポーリングタイマのタイムアウトイベントを受信すると、再びステップＳ５８０１へ進み、同様の処理を行う。
【０２１３】
ステップＳ５８０１において、処理されていない検索結果があると判断した場合は、未処理の検索結果から１デバイス分のデバイス情報（ロケーション情報や属性情報）を取得する（ステップＳ５８０２）。さらに、取得した属性情報中に含まれるＩＰアドレス宛てに状態取得要求パケット（不図示）を送信し（ステップＳ５８０３）、図５８に示されるような状態取得応答パケットの受信待ち状態となる。
例えば、上記図１４に示したような検索結果を処理する場合、ＩＰアドレスは「１９２．１．２．１」であり、このＩＰアドレス宛てに状態取得要求パケットを送信することになる。
【０２１４】
そして、ステップＳ５８０４において目的のデバイスから状態取得応答パケットを受信すると、検索結果のロケーション情報に含まれるデバイス名（ＮＭ）情報と、受信した状態取得応答パケットのデバイス状態情報とに基づいて、上記図５２に示したような各種デバイスアイコンの中から、デバイス状態に応じた適切なデバイスアイコンを選択する（ステップＳ５８０５）。
例えば、上記図１４に示したような検索結果を処理した場合、デバイス名情報は「ＬＢＰ１１１０」である。また、状態取得応答パケットのデバイス状態情報が紙切れを表す場合には、上記図５２中の“２００１”で示すビットマップアイコンが選択されることになる。
【０２１５】
次に、クライアント装置１１１が、ロケーション情報としてのブロック（ＢＬ）情報に対応したレイアウトビットマップを表示可能か否か、すなわちブロック（ＢＬ）情報に対応したレイアウトビットマップ情報を保持しているか否かを、上記図１５に示した情報テーブルを用いて判断する（ステップＳ２９０６）。
本実施の形態において、レイアウトビットマップを表示可能なロケーション情報は、上記図１４の“１４０１”で示す情報を含むロケーション情報である。これを含まないロケーション情報であった場合には、上記図２０に示したｕｎｋｎｏｗｎＭＡＰが既に表示されているか否かを判断する（ステップＳ５８１０）。
【０２１６】
ここで、まだｕｎｋｎｏｗｎＭＡＰが表示されていない場合には、上記図２０に示したエリア１９０１へｕｎｋｎｏｗｎＭＡＰを表示する（ステップＳ５８１１）。そして、上記図２０に示したエリア１９０２へ、ステップＳ５８０５にて選択したデバイスビットマップアイコンを表示する（ステップＳ５８１２）。この場合には、レイアウトマップが正常に表示されなかった、すなわちロケーション情報がまだ登録されていないデバイスのアイコンがここに表示されることになる。
【０２１７】
一方、ステップＳ５８０６でレイアウトビットマップを表示可能と判断された場合には、ロケーション情報内のブロック（ＢＬ）情報に対応するレイアウトビットマップは既に表示されているか否かを判断する（ステップＳ５８０７）。そして、まだ表示されていないと判断した場合は、上記ブロック（ＢＬ）情報に対応するレイアウトビットマップを画面上に表示する（ステップＳ５８０８）。
例えば、上記図１４に示したような検索結果を処理した場合、検索によって見つけられたカラープリンタ１０１（ＬＢＰ１１００）のブロック（ＢＬ）情報は「２−１」であるので、これに対応する上記図１８のレイアウトビットマップを表示する。
【０２１８】
そして、ロケーション情報内の座標情報（ＭＡＰ）をもとに、レイアウトビットマップ上の該当する表示位置に、ステップＳ５８０５で選択したデバイスビットマップアイコンを重ねて表示する（ステップＳ５８０９）。
例えば、上記図１４に示したような検索結果を処理した場合、カラープリンタ１０１（ＬＢＰ１１００）の座標情報（ＭＡＰ）は「１０Ｘ＋１０Ｙ」である。また、カラープリンタ１０１（ＬＢＰ１１００）に状態を問い合わせた結果が「紙切れ」である場合、上記図５３に示したような位置に紙切れを示すデバイスアイコンを表示する。このデバイスアイコンを、先のレイアウトビットマップに重ねて表示することによって、上記図５５に示したような検索結果を表示することが可能となる。
【０２１９】
図５９は、デバイスの状態取得応答動作を示したものである。
デバイスは、電源投入後に、状態取得要求パケットを受信するための受信ポートをオープンし、受信可能状態になる（ステップＳ５９０１）。
そして、クライアント装置１１１から状態取得要求パケットを受信すると（ステップＳ５９０２）、自デバイスの状態を調査し、通知すべき状態情報を決定する（ステップＳ５９０３）。例えば、「紙切れ」が発生している場合は、「紙切れ」を示す状態情報を通知すべき情報として決定する。
【０２２０】
次に、通知すべき状態情報を含めた、上記図５８に示したような応答パケットを生成する（ステップＳ５９０４）。そして、上記生成した応答パケットをクライアント装置１１１に送信し（ステップＳ５９０５）、再び状態取得要求パケットの受信可能状態になる。
【０２２１】
上述のように、本実施の形態によれば、ネットワーク１００上のデバイスの位置をわかりやすくユーザに通知するとともに、そのデバイスの情報をユーザに通知することが可能となる。
また、デバイスの状態を、デバイスからポーリングにより取得するので、ネットワーク１００上で一時的にパケットが喪失したとしても、デバイスの状態を確実に取得することが可能となる。
【０２２２】
＜第５の実施の形態＞
本実施の形態では、ネットワーク１００上のデバイスの位置をわかりやすくユーザに通知するとともに、そのデバイスの状態をユーザに通知する。
また、本実施の形態では、デバイスの状態をデバイスからのイベント通知により取得する。
【０２２３】
尚、本実施の形態は、第１の実施の形態をベースとしているため、ここでは、第１の実施の形態と異なる構成についてを具体的に説明する。
【０２２４】
図６０〜図６３は、第５の実施形態におけるクライアント装置１１１の動作を示すフローチャートである。
また、図６４〜図６５は、第５の実施形態におけるデバイスの動作を示すフローチャートである。
以下、これらのフローチャートを用いて、本実施の形態でネットワークシステムの動作を説明する。
【０２２５】
まず、上記図６０を用いて、本実施の形態でのクライアント装置１１１の全体動作について説明する。
本実施の形態では、特に、第１の実施の形態における当該動作（上記図２８参照）に対して、ステップＳ６１０７及びステップＳ６１０８の処理が追加されている。
【０２２６】
ステップＳ６１０７では、取得したイベントがデバイスからのイベント通知受信（ステップＳ２６０６での検索結果処理の中で行われるイベント通知先登録要求に対するデバイスからの応答）であるか否かを判断する。
ここで、イベント通知をデバイスから受信したと判断した場合は、後述するイベント通知受信処理を行う（スナッブＳ６１０８）。
その後、ステップＳ６１０１に戻り、クライアント装置１１１は、再びイベントの発生待ちとなる。
【０２２７】
上記図６１は、上記図６０のステップＳ２６０４における検索要求送信処理を示すフローチャートである。
この処理については、第４の実施の形態での当該処理と同様である。
【０２２８】
つぎに、上記図６２のフローチャートを用いて、上記図６０のステップＳ６１０６における検索結果処理についてより詳細に説明する。
【０２２９】
上記図６２において、デバイス検索の結果、検索条件に合致するデバイスが１つ以上発見されたか否かを判断する（ステップＳ６３０１）。ここで、検索条件に合致するデバイスが１つも発見されなかった場合は、該当するデバイスが発見されなかった旨のメッセージ（不図示）を表示し（ステップＳ６３１５）、本処理を終了する。
【０２３０】
一方、ステップＳ６３０１において、１つ以上のデバイスが発見されたと判断した場合は、その検索結果（該当するデバイスのロケーション情報及び属性情報）をハードディスク２１１に保存する。
例えば、上記図１４に示したような検索結果が得られた場合、それをハードディスク２１１へ保存することになる。
その後、ハードディスク２１１に保存された検索結果のそれぞれに対して、以降の処理ステップＳ６３０３からの処理による状態取得プロセスが実行されることになる。
【０２３１】
本実施の形態での状態取得プロセスは、クライアント装置１１１が検索結果で示されるデバイスに対してイベント通知先登録要求を発行し、それに対する応答としてデバイスから返送されてくるイベント通知を取得し、そのイベント通知の中に含まれるデバイスの状態情報に従って、レイアウトビットマップ上に現在の状態に応じたデバイスアイコンを重ねて表示するためのプログラムである。
【０２３２】
状態取得プロセスが起動されると、先ず最初に、上記ステップＳ６３０２でハードディスク２１１に保存された検索結果を参照し、すべての検索結果を処理し終わったかどうか、すなわち保存されている検索結果の中に含まれるすべてのＩＰアドレスのデバイスに対してイベント通知先の登録処理が終わったかどうかを判断する（ステップＳ６３０３）。ここで、全ての検索結果を処理し終わった場合には、本処理を終了する。
【０２３３】
一方、まだ処理されていない検索結果があると判断した場合は、未処理の検索結果から１デバイス分のデバイス情報（ロケーション情報や属性情報）を取得する（ステップＳ６３０４）。
さらに、取得した属性情報中に含まれるＩＰアドレス宛てに、図６６に示すようなイベント通知先登録パケットを送信する（ステップＳ６３０５）。
例えば、上記図１４に示した検索結果を処理する場合、ＩＰアドレスは「１９２．１．２．１」であり、このＩＰアドレス宛てにイベント通知先登録パケットを送信することになる。
【０２３４】
ここで、上記図６６に示したイベント通知先登録パケットは、どのようなイベントが発生した場合にイベント通知を行うかを示すための通知条件情報と、その通知先を示すためのイベント通知先情報とを含む。
すなわち、１番目のフィールド６７０１は、このパケットの内容がイベント通知先登録であることを示す。２番目のフィールド６７０２は、この後に続く情報が通知条件を表す情報であることを示すタグである。３番目のフィールド６７０３は、実際の通知条件を表す情報を格納するものである。また、４番目のフィールド６７０４は、この後に続く情報がイベント通知先を表す情報であることを示すタグである。最後のフィールド６７０５は、実際の通知先のネットワークアドレスを表す情報を格納するものである。
【０２３５】
上記図６６では、イベント通知先登録パケットの発行先デバイスは、上記ＩＰアドレス「１９２．１．２．１」で示されるカラープリンタ１０１であり、通知条件情報には、そのカラープリンタ１０１の「紙切れ」及び「紙詰まり」を設定し、イベント通知先情報には、自クライアントを表すＩＰアドレス「１９２．１，２．１６：１０２５」を設定している。
【０２３６】
上記イベント通知先登録パケットを送った後は、イベント通知先登録の応答パケットの受信待ち状態となる。そして、ステップＳ６３０６において目的のデバイスから、図６７に示すようなイベント通知先登録の応答パケットを受信すると、検索結果のロケーション情報に含まれるデバイス名（ＮＭ）情報と、受信した応答パケット中に含まれるデバイス状態情報とに基づいて、上記図５２に示した各種デバイスアイコンの中から、デバイス状態に応じた適切なビットマップアイコンを選択する（ステップＳ６３０７）。
【０２３７】
ここで、上記図６７は、デバイスからクライアント装置１１１に送信される応答パケットの一例を示す図である。
この応答パケットは、クライアント装置１１１からデバイスに送信されるイベント通知先登録パケット（上記図６６参照）に対して、そのときのデバイスの状態を表すデバイス状態情報を返送するために送信される。
【０２３８】
上記図６７において、１番目のフィールド６８０１は、このパケットの内容がイベント通知先登録の応答であることを示す。２番目のフィールド６８０２は、この後に続く情報がデバイスの状態を表す情報であることを示すタグである。最後のフィールド６８０３は、実際のデバイス状態を表す情報（例えばエラーコードなど）を格納するものである。
【０２３９】
例えば、上記図６７に示されるような応答パケットをクライアント装置１１１が受信した場合は、当該応答パケット中のデバイス状態情報は「紙切れ」を表しているので、上記ステップＳ６３０７では、上記図５２で示すＬＢＰ１１１０に対応するデバイスアイコンが選択されることになる。
【０２４０】
次に、クライアント装置１１１が、ロケーション情報としてのブロック（ＢＬ）情報に対応したレイアウトビットマップを表示可能か否か、すなわちブロック（ＢＬ）情報に対応したレイアウトビットマップ情報を保持しているか否かを、上記図１５の情報テーブルを用いて判断する（ステップＳ６３０８）。
本実施の形態において、レイアウトビットマップを表示可能なロケーション情報は、上記図１４の“１４０１”で示す情報を含むロケーション情報である。これを含まないロケーション情報であった場合１こは、上記図２０に示したｕｎｋｎｏｗｎＭＡＰが既に表示されているか否かを判断する（ステップＳ６３１２）。
【０２４１】
上記の判断にて、まだｕｎｋｎｏｗｎＭＡＰが表示されていない場合には、上記図２０のエリア“１９０１”にｕｎｋｎｏｗｎＭＡＰを表示する（ステップＳ６３１３）。そして、上記図２０のエリア“１９０２”に、ステップＳ６３０７にて選択したデバイスアイコンを表示する（ステップＳ６３１４）。この場合には、レイアウトマップが正常に表示されなかった、すなわちロケーション情報がまだ登録されていないデバイスのアイコンがここに表示されることになる。
【０２４２】
一方、ステップＳ６３０８でレイアウトビットマップを表示可能と判断された場合には、ロケーション情報内のブロック（ＢＬ）情報に対応するレイアウトビットマップは既に表示されているか否かを判断する（ステップＳ６３０９）。そして、まだ表示されていないと判断した場合は、上記ブロック（ＢＬ）情報に対応するレイアウトビットマップを画面上に表示する（ステップＳ６３１０）。
例えば、上記図１４の検索結果を処理した場合、検索によって見つけられたカラープリンタ１０１（ＬＢＰ１１００）のブロック（ＢＬ）情報は「２−１」であるので、これに対応する上記図１８のレイアウトビットマップを表示する。
【０２４３】
そして、ロケーション情報内の座標情報（ＭＡＰ）をもとに、レイアウトビットマップ上の該当する表示位置に、ステップＳ６３０７で選択したデバイスアイコンを重ねて表示する（ステップＳ６３１１）。
例えば、上記図１４の検索結果を処理した場合、カラープリンタ１０１（ＬＢＰ１１００）の座標情報（ＭＡＰ）は「１０Ｘ＋１０Ｙ」である。また、カラープリンタ１０１（ＬＢＰ１１００）に状態を問い合わせた結果が「紙切れ」である場合、上記図５３に示した位置へ紙切れを示すデバイスビットマップアイコンを表示する。このデバイスビットマップアイコンを、先のレイアウトビットマップに重ねて表示することによって、上記図５４に示したように検索結果を表示することが可能となる。
【０２４４】
つぎに、上記図６０のステップＳ６１０８に示したイベント通知受信処理の動作について、上記図６３のフローチャートを用いて詳細に説明する。
【０２４５】
上記図６３において、クライアント装置１１１は、先ず最初に、上記図６２のステップＳ６３０５の処理によってイベント通知先の登録が行われたデバイスから、図６８に示すようなイベント通知パケットを受信すると、そのイベント通知パケット中から当該デバイスにて発生したイベントの内容を表すイベント情報を取得するとともに（ステップＳ６４０１）、当該デバイスの位置を表すロケーション情報を取得する（ステップＳ６４０２）。
【０２４６】
ここで、上記図６８に示すように、各デバイスは、自己の状態変化を監視しており、クライアント装置１１１から登録された通知条件に合致するイベントが発生すると、同じくクライアント装置１１１から登録された通知先へそのイベント情報を送信する。このとき、そのデバイスの位置を表すものとしてデバイスに保持されているロケーション情報も一緒にパケット化して送信する。
上記図６８では、カラープリンタ１０１（ＬＢＰ１１００）にて紙切れのイベントが発生したときに送られるパケットを示している。
【０２４７】
次に、クライアント装置１１１は、デバイス検索の処理によってハードディスク２１１に記憶された検索結果の中に、上記イベント通知パケット中から取得したロケーション情報と一致する情報を有するデバイス情報が存在するか否かを判断する（ステップＳ６４０３）。これは、イベント通知先の登録処理は、他のクライアント装置１１３からも行われていることがあるので、自己の検索結果で示されるデバイスのロケーション情報と、イベント発生先のデバイスから送られてくるロケーション情報とが必ず一致するとは限らないからである。
【０２４８】
ステップＳ６４０３での判断の結果、イベント通知パケット中のロケーション情報と一致するデバイス情報が存在しないと判断した場合は、そのまま本処理を終了する。
【０２４９】
一方、一致するデバイス情報が存在する場合は、上記イベント通知パケット中から取得したイベント情報（状態情報）と、ロケーション情報に含まれるデバイス名（ＮＭ）情報と１こ基づいて、上記図５２に示した各種デバイスアイコンの中から、デバイス状態に応じた適切なデバイスアイコンを選択する（ステップＳ６４０４）。
【０２５０】
そして、上記取得したロケーション情報に対応するレイアウトビットマップを画面上に表示するとともに、当該ロケーション情報内の座標情報（ＭＡＰ）をもとに、レイアウトビットマップ上の該当する表示位置に、ステップＳ６４０４で選択したデバイスアイコンを重ねて表示する（ステップＳ６４０５）。
これにより、デバイスアイコンの表示が、デバイスの状態変化に応じて変更される。
【０２５１】
例えば、イベント通知先の登録処理を行ったときにその応答としてカラープリンタ１０１から送られてくるデバイスの状態情報が「稼働中」であり、稼働中の状態を表すデバイスアイコンを画面上に表示している状態中に、カラープリンタ１０１にて紙切れが発生した場合、その稼働中を表すデバイスアイコンは、上記図５４に示したような紙切れを表すアイコンに変更されて表示されることになる。
【０２５２】
つぎに、デバイス側のイベント通知先登録処理の動作について、上記図６４のフローチャートを用いて詳細に説明する。
ここでは、説明の簡単のために、各種デバイスのうち、カラープリンタ１０１に着目して説明する。
【０２５３】
カラープリンタ１０１は、電源投入後に、クライアント装置１１１から、上記図６６に示したようなイベント通知先登録パケットを受信するための受信ポートをオープンし、受信可能状態になる（ステップＳ６５０１）。そして、ある検索クライアントＰＣからイベント通知先登録パケットを受信すると（ステップＳ６５０２）、そのイベント通知先登録パケットに含まれる通知条件や通知先の情報を、図６９に示すようなイベント通知先テーブルに保存し、管理する（ステップＳ６５０３）。
【０２５４】
ここで、上記図６９に示すイベント通知先テーブルは、デバイス側で保持されており、クライアント装置１１１から登録された通知条件や通知先のネットワークアドレスの他に、通信プロトコルの情報も併せて記憶されている。
【０２５５】
次に、カラープリンタ１０１は、上記イベント通知先登録パケットを受信した時点での自デバイスの状態を調査し、通知すべき状態情報を決定する（ステップＳ６５０４）。
例えば、「紙切れ」の状態が発生している場合は、「紙切れ」を示す状態情報を通知すべき情報として決定する。
【０２５６】
次に、通知すべき現在の状態情報を含めた、上記図６７に示したような応答パケットを生成する（ステップＳ６５０５）。そして、上記イベント通知先登録パケットの発行元のクライアント装置１１１に対して、上記生成した応答パケットを送信し（ステップＳ６５０６）、再びイベント通知先登録パケットの受信可能状態になる。
【０２５７】
つぎに、デバイス側で行われるイベント通知処理の動作について、上記図６５のフローチャートを用いて詳細に説明する。
ここでも、説明の簡単のために、各種デバイスのうち、カラープリンタ１０１に着目して説明する。
【０２５８】
カラープリンタ１０１は、自己の状態変化を監視しており、状態変化のイベントが発生したか否かを判断する（ステップＳ６６０１）。ここで、状態変化のイベントが発生すると、上記図６９に示したようなイベント通知先テーブルを参照し、発生したイベントを通知すべきクライアント装置を検索する（ステップＳ６６０２）。
【０２５９】
そして、イベントを通知すべきクライアント装置が１つ以上存在するか否かを判断する（ステップＳ６６０３）。ここでは、カラープリンタ１０１にて発生したイベントが、上記イベント通知先テーブル内に通知条件として登録されているクライアント装置があるか否かを判断する。そのようなクライアント装置が存在する場合は、そのイベント情報を含めた、上記図６８に示したようなイベント通知パケットを生成し（ステップＳ６６０４）、それを通知すべき全てのクライアント装置に送信する（ステップＳ６６０５）。その後、ステップＳ６６０１に戻り、再び状態変化のイベント発生待ちの状態となる。
【０２６０】
上述のように、本実施形態によれば、ネットワーク１００上のデバイスの位置をわかりやすくユーザに通知するとともに、そのデバイスの情報をユーザへ通知することが可能となる。
また、デバイスの状態を、デバイスからのイベント通知により取得するので、ポーリングングによって取得する場合に比べて、ネットワーク１００のトラフィックを軽減することが可能となる。
【０２６１】
尚、第４及び第５の実施の形態では、レイアウトビットマップをクライアント装置１１１が保持している形態としたが、第２の実施の形態のようにレイアウトビットマップをサーバ装置が保持する形態としてもよい。
また、第４及び第５の実施の形態では、ブロック（ＢＬ）階層に対応したレイアウトビットマップのみを保持する形態としたが、第３の実施の形態のように階層型位置情報の各階層に対応するレイアウトビットマップを保持し、それをクライアント装置１１１の検索結果表示に反映する形態としてもよい。
【０２６２】
＜本発明の他の実施の形態１＞
第１〜第５の実施の形態におけるデバイス検索システムは、例えば、ＷＷＷ技術で利用されているような技術を用いて実現できる。この場合、サーバ装置１１２は、ＷＷＷサーバと、データベース機能（ＤＢＭＳ）と、ＷＷＷサーバ及びＤＢＭＳを仲介するゲートウェイ機能とを備えるように構成する。
【０２６３】
ＷＷＷサーバは、ＨＴＭＬ或はＸＭＬで構成される検索画面をクライアント装置へ提供する。
クライアント装置は、ブラウサソフトウェアによりＷＷＷサーバから提供された検索画面を表示し、クライアント装置のユーザは、当該表示された検索画面を用いてデバイスの検索を実行する。
【０２６４】
また、サーバ装置、クライアント装置、及びデバイスの間でやりとりされる各種データ（ＭＡＰ、アイコン等）は、ＨＴＭＬやＸＭＬ等で構成され、データをやりとりするためのプロトコルとしては、ＨＴＴＰが用いられる。
【０２６５】
また、クライアント装置側で、汎用のブラウサソフトウェアが持っていない機能を実現するには、例えば、ＪＡＶＡ技術の１つであるアプレット（Ａｐｐｌｅｔ）を利用する形態等がある。
【０２６６】
＜本発明の他の実施の形態２＞
第１〜第５の実施の形態では、クライアント装置１１１及びサーバ装置１１２の一例として、上記図３に示したような構成を有するコンピュータ装置を用いるようにしたが、例えば、スキャナ、ファクシミリ、プリンタ等のデバイスに対して、クライアント装置１１１の機能、又はサーバ装置１１２の機能を持たせるようにしてもよい。
【０２６７】
具体的には例えば、スキャナに対してクライアント装置１１１の機能を持たせる構成とした場合、当該スキャナで読み取った原稿データを印刷するプリンタの状態や、当該スキャナで読み取った原稿データを送信するファクシミリの状態を知ることが可能となる。
【０２６８】
＜本発明の他の実施の形態３＞
第１〜第５の実施の形態のホスト及び端末の機能を実現するソフトウェアのプログラムコードを記憶した記憶媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読みだして実行することによっても、本発明が達成されることは言うまでもない。
この場合、上記ソフトウェアのプログラムコード自体が、第１〜第５の実施の形態の機能を実現することになり、そのプログラムコード自体、及びそのプログラムコードをコンピュータに供給するための手段、例えば、当該プログラムコードを格納した記憶媒体が本発明を構成する。
【０２６９】
上記プログラムコードを記憶する記憶媒体としては、例えば、フロッピーディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ―ＲＯＭ、磁気テープ、不揮発性のメモリカード、ＲＯＭ等を用いることができる。
【０２７０】
また、第１〜第５の実施の形態でのネットワーク１００上のデバイス制御プログラムは、外部からインストールされるプログラムによって、ＰＣ２００（上記図３参照）によって遂行されるようにしてもよい。
この場合、上記プログラムを含む情報群が、ＣＤ―ＲＯＭやフラッシュメモリ、或はフロッピーディスク等の記憶媒体、或は電子メールやパソコン通信等のネットワークを介して、外部の記憶媒体からＰＣ２００内にロードされる場合でも、本発明は適用される。
【０２７１】
図７０は、上記記憶媒体の一例としてのＣＤ−ＲＯＭのメモリマップを示す図である。
上記図３０において、“９９９９”はディレクトリ情報を記憶してある領域であり、以降の領域９９９８及び領域９９９７の位置を示している。
領域９９９８は、インストールプログラムを記憶してある領域であり、領域９９９７は、ネットワークデバイス制御プログラムを記憶してある領域である。
【０２７２】
本発明を適用したネットワーク制御プログラムが、ＰＣ２００にインストールされる際には、先ず、インストールプログラムを記憶してある領域９９９８に記憶されている当該インストールプログラムがＰＣ２００内へロードされ、そのＣＰＵ２０２によって実行される。
そして、ＣＰＵ２０２によって実行されるインストールプログラムが、ネットワークデバイス制御プログラムを記憶してある領域９９９７から当該ネットワークデバイス制御プログラムを読み出して、ハードディスク２１１へ格納する。
【０２７３】
また、コンピュータが読みだしたプログラムコードを実行することにより、第１〜第５の実施の形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（オペレーティングシステム）等が実際の処理の一部又は全部を行い、その処理によって第１〜第５の実施の形態の機能が実現される場合も含まれることは言うまでもない。
さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された拡張機能ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部又は全部を行い、その処理によって第１〜第５の実施の形態の機能が実現される場合も含まれることは言うまでもない。
【０２７４】
【発明の効果】
以上説明したように本発明によれば、ジョブについてのイベントが発生するのに応じて、デバイスから情報処理装置に、該デバイスの位置を階層的に表した階層型位置情報及び該イベントを示すイベント情報を送信することにより、前記情報処理装置が、前記階層型位置情報に基づいて、前記イベント情報が示すイベントを、イベントの発生に応じて表示できるようにしたので、ユーザは、デバイスの階層的なロケーションを容易に認識することができるとともに、当該デバイスに依頼されたジョブについてのイベントを容易に且つ的確に認識することができる。
【図面の簡単な説明】
【図１】第１の実施の形態において、本発明を適用したデバイス検索システムの構成を示すブロック図である。
【図２】上記デバイス検索システムが動作可能なネットワークシステムの一例の構成を説明するための図である。
【図３】一般的なパーソナルコンピュータの内部構成を示すブロック図である。
【図４】階層型位置情報の一例を説明するための図である。
【図５】２階の２−１ブロックの各デバイスの位置を説明するための図である。
【図６】２階の２−２ブロックの各デバイスの位置を説明するための図である。
【図７】１階の１−１ブロックの各デバイスの位置を説明するための図である。
【図８】１階の１−２ブロックの各デバイスの位置を説明するための図である。
【図９】サーバ装置が管理する階層型位置情報及び属性情報を説明するための図である。
【図１０】デバイスが登録する階層型位置情報及び属性情報を説明するための図である。
【図１１】デバイス検索入力画面を説明するための図である。
【図１２】デバイス検索入力画面の具体例を説明するための図である。
【図１３】デバイス検索条件の一例を説明するための図である。
【図１４】デバイス検索結果の一例を説明するための図である。
【図１５】クライアント装置が管理するビットマップ及び階層型位置情報を説明するための図である。
【図１６】クライアント装置が管理するレイアウトビットマップ（１階―１フロア）を説明するための図である。
【図１７】クライアント装置が管理するレイアウトビットマップ（１階―２フロア）を説明するための図である。
【図１８】クライアント装置が管理するレイアウトビットマップ（２階―２フロア）を説明するための図である。
【図１９】クライアント装置が管理するレイアウトビットマップ（２階―２フロア）を説明するための図である。
【図２０】クライアント装置が管理するレイアウトビットマップ（ｕｎｋｏｗｎＭＡＰ）を説明するための図である。
【図２１】クライアント装置が管理するデバイスアイコンを説明するための図である。
【図２２】デバイスアイコンの位置を説明するための図である。
【図２３】デバイス検索結果を説明するための図である。
【図２４】デバイスの内部構成を示すブロック図である。
【図２５】登録処理を説明するためのフローチャートである。
【図２６】サーバ装置の全体動作を説明するためのフローチャートである。
【図２７】データベースの検索処理を説明するためのフローチャートである。
【図２８】クライアント装置の全体動作を説明するためのフローチャートである。
【図２９】検索結果表示処理を説明するためのフローチャートである。
【図３０】クライアントが発行する印刷ジョブ情報の一例を説明するための図である。
【図３１】デバイスが管理するイベント通知テーブルを説明するための図である。
【図３２】デバイスからクライアント装置へ通知されるイベント通知を説明するための図である。
【図３３】印刷終了のイベントを受信したときの表示の一例を説明するための図である。
【図３４】クライアント装置のイベント受信時の処理を説明するためのフローチャートである。
【図３５】デバイスの全体動作を説明するためのフローチャートである。
【図３６】デバイスのイベント発生時の処理を説明するためのフローチャートである。
【図３７】第２の実施の形態において、クライアント装置の動作（検索結果表示動作）を説明するためのフローチャートである。
【図３８】クライアント装置の動作（表示動作）を説明するためのフローチャートである。
【図３９】サーバ装置の動作を説明するためのフローチャートである。
【図４０】第３の実施の形態において、各階層に対応するレイアウトビットマップのリストの一例を説明するための図である。
【図４１】クライアント装置の動作を説明するためのフローチャートである。
【図４２】各階層毎に用意されたレイアウトビットマップの一例（例１）を説明するための図である。
【図４３】各階層毎に用意されたレイアウトビットマップの一例（例２）を説明するための図である。
【図４４】各階層毎に用意されたレイアウトビットマップの一例（例３）を説明するための図である。
【図４５】各階層毎に用意されたレイアウトビットマップの一例（例４）を説明するための図である。
【図４６】各階層毎に用意されたレイアウトビットマップの一例（例５）を説明するための図である。
【図４７】各階層毎に用意されたレイアウトビットマップの一例（例６）を説明するための図である。
【図４８】各階層毎に用意されたレイアウトビットマップの一例（例７）を説明するための図である。
【図４９】各階層毎に用意されたレイアウトビットマップの一例（例８）を説明するための図である。
【図５０】各階層毎に用意されたレイアウトビットマップの一例（例９）を説明するための図である。
【図５１】各階層毎に用意されたレイアウトビットマップの一例（例１０）を説明するための図である。
【図５２】第４の実施の形態において、クライアント装置におけるデバイスアイコンの管理テーブルを説明するための図である。
【図５３】レイアウトビットマップの表示の一例（例１）を説明するための図である。
【図５４】レイアウトビットマップの表示の一例（例２）を説明するための図である。
【図５５】クライアント装置の動作（検索要求送信処理）を説明するためのフローチャートである。
【図５６】クライアント装置の動作（検索結果処理）を説明するためのフローチャートである。
【図５７】クライアント装置の動作（状態取得処理）を説明するためのフローチャートである。
【図５８】デバイスの応答パケットを説明するための図である。
【図５９】デバイスの動作を説明するためのフローチャートである。
【図６０】第５の実施の形態において、クライアント装置の動作（全体動作）を説明するためのフローチャートである。
【図６１】クライアント装置の動作（検索要求送信処理）を説明するためのフローチャートである。
【図６２】クライアント装置の動作（検索結果処理）を説明するためのフローチャートである。
【図６３】クライアント装置の動作（イベント通知受信処理）を説明するためのフローチャートである。
【図６４】デバイスの動作（イベント通知先登録処理）を示すフローチャートである。
【図６５】デバイスの動作（イベント通知処理）を示すフローチャートである。
【図６６】クライアント装置のイベント通知先登録パケットを説明するための図である。
【図６７】デバイスの応答パケットを説明するための図である。
【図６８】デバイスのイベント通知パケットを説明するための図である。
【図６９】デバイスが管理するイベント通知先テーブルを説明するための図である。
【図７０】他の実施の形態において、メモリマップの一例を説明するための図である。
【符号の説明】
１０ サーバ装置
１１ データベース
１２ 検索モジュール
１３ 属性登録モジュール
２０ クライアント装置
２１ 検索要求モジュール
２２ 表示モジュール
３０ デバイス
３１ 属性送信モジュール
４０ ネットワーク
Claims (8)
- ネットワークを介して依頼されたジョブを処理するデバイスであって、
前記ネットワーク上の情報処理装置から送信されたジョブを受信する受信手段と、
前記ジョブについてのイベントが発生するのに応じて、自身の位置を階層的に表した階層型位置情報及び該イベントを示すイベント情報を前記情報処理装置に送信する送信手段と、
を有することを特徴とするデバイス。 - 前記ジョブにおいて発生したイベントのうち、前記情報処理装置に通知すべきイベントを指定した情報を受信する指定情報受信手段を更に有し、
前記送信手段は、前記指定情報受信手段により受信した情報で指定されるイベントの発生に応じてイベント情報を前記情報処理装置に送信することを特徴とする請求項１に記載のデバイス。 - 少なくとも、ネットワークを介して依頼されたジョブを処理するデバイスと、依頼されたジョブをモニタする情報処理装置とを有するネットワークシステムであって、
前記デバイスは、
前記情報処理装置から送信されたジョブを受信する受信手段と、
前記ジョブについてのイベントが発生するのに応じて、自身の位置を階層的に表した階層型位置情報及び該イベントを示すイベント情報を前記情報処理装置に送信する送信手段と、
を含み、
前記情報処理装置は、
前記デバイスにジョブを送信する送信手段と、
前記ジョブについてのイベントが発生するのに応じて前記デバイスから送信される情報であって、該デバイスの位置を階層的に表した階層型位置情報及び該イベントを示すイベント情報を受信する受信手段と、
前記受信手段によって受信した階層型位置情報に基づいて、前記イベント情報が示すイベントを表示する表示手段と、
を含むことを特徴とするネットワークシステム。 - ネットワークを介して依頼されたジョブを処理するジョブ処理方法であって、
前記ネットワーク上の情報処理装置から送信されたジョブを受信する受信ステップと、
前記ジョブについてのイベントが発生するのに応じて、自身の位置を階層的に表した階層型位置情報及び該イベントを示すイベント情報を前記情報処理装置に送信する送信ステップと、
を有することを特徴とするジョブ処理方法。 - 前記ジョブにおいて発生したイベントのうち、前記情報処理装置に通知すべきイベントを指定した情報を受信する指定情報受信ステップを更に有し、
前記送信ステップは、前記指定情報受信ステップにより受信した情報で指定されるイベントの発生に応じてイベント情報を前記情報処理装置に送信することを特徴とする請求項４に記載のジョブ処理方法。 - ネットワークを介して依頼されたジョブをモニタするジョブモニタ方法であって、
前記ネットワーク上のデバイスにジョブを送信する第１の送信ステップと、
前記第１の送信ステップによって送信されたジョブを受信する第１の受信ステップと、
前記第１の受信ステップによって受信されたジョブについてのイベントが発生するのに応じて、自身の位置を階層的に表した階層型位置情報及び該イベントを示すイベント情報を前記ネットワーク上の情報処理装置に送信する第２の送信ステップと、
前記第２の送信ステップによって送信された前記階層型位置情報及び前記イベント情報を受信する第２の受信ステップと、
前記第２の受信ステップによって受信された階層型位置情報に基づいて、前記イベント情報が示すイベントを表示する表示ステップと、
を含むことを特徴とするジョブモニタ方法。 - ネットワークを介して依頼されたジョブを処理することをコンピュータに実行させるためのコンピュータプログラムを記憶したコンピュータ読み取り可能な記憶媒体であって、
前記コンピュータプログラムは、
前記ネットワーク上の情報処理装置から送信されたジョブを受信する受信ステップと、
前記ジョブについてのイベントが発生するのに応じて、自身の位置を階層的に表した階層型位置情報及び該イベントを示すイベント情報を前記情報処理装置に送信する送信ステップと、
をコンピュータに実行させることを特徴とするコンピュータ読み取り可能な記憶媒体。 - 前記コンピュータプログラムは、
前記ジョブにおいて発生したイベントのうち、前記情報処理装置に通知すべきイベントを指定した情報を受信する指定情報受信ステップを更にコンピュータに実行させ、
前記送信ステップは、前記指定情報受信ステップにより受信した情報で指定されるイベントの発生に応じてイベント情報を前記情報処理装置に送信することを特徴とする請求項７に記載のコンピュータ読み取り可能な記憶媒体。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000197978A JP4261742B2 (ja) | 1999-07-02 | 2000-06-30 | デバイス、ネットワークシステム、ジョブ処理方法、ジョブモニタ方法、及びコンピュータ読み取り可能な記憶媒体 |
Applications Claiming Priority (13)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP18972799 | 1999-07-02 | ||
| JP18972999 | 1999-07-02 | ||
| JP19238399 | 1999-07-06 | ||
| JP20084899 | 1999-07-14 | ||
| JP11-189729 | 1999-07-16 | ||
| JP11-192383 | 1999-07-16 | ||
| JP20363999 | 1999-07-16 | ||
| JP11-203639 | 1999-07-16 | ||
| JP20364099 | 1999-07-16 | ||
| JP11-189727 | 1999-07-16 | ||
| JP11-203640 | 1999-07-16 | ||
| JP11-200848 | 1999-07-16 | ||
| JP2000197978A JP4261742B2 (ja) | 1999-07-02 | 2000-06-30 | デバイス、ネットワークシステム、ジョブ処理方法、ジョブモニタ方法、及びコンピュータ読み取り可能な記憶媒体 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2001092763A JP2001092763A (ja) | 2001-04-06 |
| JP4261742B2 true JP4261742B2 (ja) | 2009-04-30 |
Family
ID=27566431
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000197978A Expired - Fee Related JP4261742B2 (ja) | 1999-07-02 | 2000-06-30 | デバイス、ネットワークシステム、ジョブ処理方法、ジョブモニタ方法、及びコンピュータ読み取り可能な記憶媒体 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4261742B2 (ja) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4095581B2 (ja) * | 2004-06-09 | 2008-06-04 | キヤノン株式会社 | 情報処理装置およびその制御方法 |
| US7378969B2 (en) * | 2005-10-25 | 2008-05-27 | Sap Ag | Systems and methods for visualizing auto-id data |
| JP2018036736A (ja) * | 2016-08-29 | 2018-03-08 | 富士ゼロックス株式会社 | 画像形成装置、装置管理システムおよびプログラム |
| CN109684495A (zh) * | 2018-12-27 | 2019-04-26 | 中民筑友科技投资有限公司 | 一种装配式建筑的大样图审图方法、装置、设备及系统 |
-
2000
- 2000-06-30 JP JP2000197978A patent/JP4261742B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2001092763A (ja) | 2001-04-06 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP2009157937A (ja) | デバイス及びデバイスの制御方法 | |
| EP1069727B1 (en) | System for searching a device on a network | |
| EP1073234B1 (en) | System and apparatus for searching for devices connected to a network | |
| EP1278334B1 (en) | A method and apparatus for managing network devices | |
| US8261259B2 (en) | Dynamic printing system, apparatus and method | |
| US7610270B2 (en) | Service retrieval apparatus having automatic change function for retrieval conditions and method therefor | |
| US7099937B1 (en) | System for searching for device on network | |
| US7237015B1 (en) | System for setting location information in a device on a network | |
| JP4261742B2 (ja) | デバイス、ネットワークシステム、ジョブ処理方法、ジョブモニタ方法、及びコンピュータ読み取り可能な記憶媒体 | |
| JP2001092764A (ja) | 情報処理装置、デバイス、ネットワークシステム、デバイスモニタ方法、デバイスの制御方法、及び記憶媒体 | |
| JP4280399B2 (ja) | 情報処理装置、情報処理方法、記憶媒体 | |
| JP4122851B2 (ja) | Ｏａ機器管理システムおよびサーバコンピュータ | |
| US20160255160A1 (en) | Method and system for determining printer location on a map | |
| JP2001092765A (ja) | 情報処理装置、デバイス、ネットワークシステム、情報処理方法、デバイス制御方法、デバイス検索方法及び記憶媒体 | |
| JP2001034561A (ja) | 情報処理装置、ネットワークシステム、デバイス検索方法、及び記憶媒体 | |
| US6782352B2 (en) | System and method for monitoring server host operation | |
| JP2006268325A (ja) | サーバ端末装置、クライアント端末装置およびネットワークシステム | |
| JP2001034563A (ja) | 情報処理装置、ネットワークシステム、デバイス検索方法、及び記憶媒体 | |
| JP2001034564A (ja) | 情報処理装置、ネットワークシステム、デバイス検索方法、及び記憶媒体 | |
| JP2003150348A (ja) | プリントサービス装置 | |
| JP2001034562A (ja) | 情報処理装置、ネットワークシステム、デバイス検索方法、及び記憶媒体 | |
| JP2001282659A (ja) | サーバ装置、クライアント端末装置、ネットワークシステム、ネットワークシステムにおけるデバイス端末表示方法、デバイス端末検索方法及び記憶媒体 | |
| JP3976957B2 (ja) | 情報処理装置、ネットワークシステム、デバイス検索装置及び方法、並びにコンピュータ読み取り可能な記録媒体 | |
| JP2004362126A (ja) | サーバ端末装置、クライアント端末装置、ネットワークシステム、ネットワークシステムにおけるデバイス端末表示方法、デバイス端末検索方法及び記憶媒体 | |
| JPH07105119A (ja) | 周辺機器制御装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20040622 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040629 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040830 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20050726 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050926 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20050929 |
|
| A912 | Re-examination (zenchi) completed and case transferred to appeal board |
Free format text: JAPANESE INTERMEDIATE CODE: A912 Effective date: 20051216 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20081212 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20090206 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120220 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130220 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140220 Year of fee payment: 5 |
|
| LAPS | Cancellation because of no payment of annual fees |