(57)【特許請求の範囲】
【請求項１】
外部からのアクセスにより省電力状態から復帰する印刷装置と通信可能で、印刷装置にアクセスする第１アクセス手段と、第２アクセス手段と、を有する情報処理システムであって、
前記第２アクセス手段は、前記第１アクセス手段の前記印刷装置に対するアクセスを伴う処理により発生されるイベントの通知を依頼する依頼手段と、前記通知により前記イベントの発生の有無を判定する判定手段と、を備え、
前記イベントが発生したと前記判定手段が判定したことに基づいて、前記第２アクセス手段が前記印刷装置に対してアクセスする
ことを特徴とする情報処理システム。
【請求項２】
前記第２アクセス手段は、前記依頼手段による依頼に基づき、前記イベントの通知先を前記第１アクセス手段に知らせるイベント管理手段を更に備え、
前記第１アクセス手段は、前記イベント管理手段により知らされた前記通知先に前記イベントの通知を行うことを特徴とする請求項１に記載の情報処理システム。
【請求項３】
前記第２アクセス手段は、前記第１アクセス手段からイベントの通知を受信したことに応じて、当該通知を前記依頼の依頼元に通知するイベント管理手段を備えることを特徴とする請求項１に記載の情報処理システム。
【請求項４】
前記イベント管理手段が複数の依頼元から前記通知を配信する依頼を受信した場合、前記イベント管理手段は、前記第１アクセス手段からの通知に応じて、前記複数の依頼元に通知を配信することを特徴とする請求項３に記載の情報処理システム。
【請求項５】
前記判定手段の判定により前記通知の種別を判断し、前記第２アクセス手段は前記判定手段の判断に基づき前記印刷装置に対するアクセスを行うことを特徴とする請求項１乃至４の何れか１項に記載の情報処理システム。
【請求項６】
前記第２アクセス手段は、前記第１アクセス手段を検索する検索手段を更に備え、
前記依頼手段は、前記検索手段により検索された第１アクセス手段に対して、前記イベントの通知を依頼することを特徴とする請求項１に記載の情報処理システム。
【請求項７】
前記第１アクセス手段はプリンタドライバであり、
前記イベントは、前記第１アクセス手段による印刷ジョブ開始イベントまたは印刷ジョブ終了イベントを含むことを特徴とする請求項１に記載の情報処理システム。
【請求項８】
外部からのアクセスにより省電力状態から復帰する印刷装置と通信可能で、印刷装置にアクセスする第１アクセス手段と、第２アクセス手段と、を有する情報処理システムにおける情報処理方法であって、
前記第２アクセス手段が、前記第１アクセス手段の前記印刷装置に対するアクセスを伴う処理により発生されるイベントの通知を依頼する依頼工程と、
前記第２アクセス手段が、前記通知により前記イベントの発生の有無を判定する判定工程と、を備え、
前記イベントが発生したと前記判定工程が判定したことに基づいて、前記第２アクセス手段が前記印刷装置に対してアクセスする
ことを特徴とする情報処理方法。
【請求項９】
前記第２アクセス手段が、前記依頼工程による依頼に基づき、前記イベントの通知先を前記第１アクセス手段に知らせるイベント管理工程を更に備え、
前記第１アクセス手段は、前記イベント管理工程により知らされた前記通知先に前記イベントの通知を行うことを特徴とする請求項８に記載の情報処理方法。
【請求項１０】
前記第２アクセス手段が、前記第１アクセス手段からイベントの通知を受信したことに応じて、当該通知を前記依頼の依頼元に通知するイベント管理工程を備えることを特徴とする請求項８に記載の情報処理方法。
【請求項１１】
前記イベント管理工程が複数の依頼元から前記通知を配信する依頼を受信した場合、当該前記イベント管理工程は、前記第１アクセス手段からの通知に応じて、前記複数の依頼元に通知を配信することを特徴とする請求項１０に記載の情報処理方法。
【請求項１２】
前記判定工程の判定により前記通知の種別を判断し、前記第２アクセス手段は前記判定工程の判断に基づき前記印刷装置に対するアクセスを行うことを特徴とする請求項８乃至１１の何れか１項に記載の情報処理方法。
【請求項１３】
前記第２アクセス手段が、前記第１アクセス手段を検索する検索工程を更に備え、
前記依頼工程は、前記検索工程により検索された前記第１アクセス手段に対して、前記イベントの通知を依頼することを特徴とする請求項８に記載の情報処理方法。 
【請求項１４】
前記第１アクセス手段はプリンタドライバであり、
前記イベントは、前記第１アクセス手段による印刷ジョブ開始イベントまたは印刷ジョブ終了イベントを含むことを特徴とする請求項８に記載の情報処理方法。
【請求項１５】
請求項８乃至１４のいずれか１項に記載の情報処理方法をコンピュータに実行させることを特徴とするプログラム。
【請求項１６】
請求項１５に記載のプログラムを格納したことを特徴とするコンピュータ可読の記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークに接続されたプリンタ、複写機など、およびそれらを統合したマルチファンクション機などのデバイスをネットワーク環境で管理する情報処理技術に関するものである。
【背景技術】
【０００２】
デバイスの状態を監視し、更にデバイスから何らかの情報取得を行う技術として、ポーリング技術が一般的である。ポーリング技術によれば、ホストコンピュータ上で動作するアプリケーションが、定期的にデバイスから状態情報を取得し、状態情報に基づいてアプリケーションユーザに対する表示を変更し、アプリケーション自体の実行が決定されていた。
【０００３】
アプリケーションの実行が決定された場合、デバイスはアプリケーションの要求に応答して動作を実行する。例えば、省電力状態（「スリープモード」ともいう）で待機中であるデバイスは通常の動作が可能な状態（通常動作モード）に移行する。ここでの通常の動作とは、例えば、外部との各種情報（例えば、ＰＤＬや各種ステイタス情報等を含む情報）の授受を行う部位を稼動させる動作モードをいう。
【０００４】
特許文献１では、処理の対象となるデバイスがスリープモードにある場合、デバイスの代行手段を用いている構成が開示されている。
【特許文献１】特開２００２−２８７９３６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、アプリケーションの頻繁なアクセスにより、デバイスがスリープモードから通常動作モードに移行すると、その後スリープモードへの移行には、（１）、（２）に示すように、一定期間の経過が必要になる。
【０００６】
（１）デバイスが備える操作パネルへの操作が一定期間無いこと
（２）デバイスに対して、ネットワークを経由したアクセスが一定期間無いこと
すなわち、アプリケーションの頻繁なアクセスにより、十分な省電力効果が得られないという問題がある。通常動作モードからスリープモードへ状態を移行させるために、一切のデバイスへのアクセスを制限する場合、ユーザの利便性は低下する。
【０００７】
また、特許文献１の構成では、デバイスの代行手段を用いているが、この場合、処理の対象となるデバイスがスリープモードにあるか判定する必要があり、システムにおけるプロセスは煩雑なものとなっていた。
【０００８】
本発明は、上記従来技術の問題を鑑みてなされたものであり、ユーザの利便性を低下させず、よりシンプルなプロセスによりデバイスの消費電力を抑制することを可能にする情報処理技術の提供を目的とする。
【課題を解決するための手段】
【０００９】
従来技術の問題を鑑み、上記目的を達成するべく、本発明に係る情報処理システムは、外部からのアクセスにより省電力状態から復帰する印刷装置と通信可能で、印刷装置にアクセスする第１アクセス手段と、第２アクセス手段と、を有する情報処理システムであって、
前記第２アクセス手段は、前記第１アクセス手段の前記印刷装置に対するアクセスを伴う処理により発生されるイベントの通知を依頼する依頼手段と、前記通知により前記イベントの発生の有無を判定する判定手段と、を備え、
前記イベントが発生したと前記判定手段が判定したことに基づいて、前記第２アクセス手段が前記印刷装置に対してアクセスすることを特徴とする。
【発明の効果】
【００１０】
本発明によれば、ユーザの利便性に優れ、デバイス側に複雑な消費電力抑制の仕組みを組み込む事無く、デバイスの消費電力を抑制する情報処理技術の提供が可能になる。
【発明を実施するための最良の形態】
【００１１】
（第１実施形態）
以下、図面を参照して、本発明の第１実施形態に係る情報処理システムを説明する。図１は、本発明の実施形態に係る情報処理システムの概略的な構成を示すブロック図である。情報処理システムを構成する各情報処理装置にプログラムが供給されることにより、各情報処理装置はプログラム（アプリケーション）の処理を実現する手段として機能する。
【００１２】
１０１は情報処理装置（クライアントコンピュータ）であり、１０２はクライアントコンピュータ１０１で実行可能なアプリケーションである。アプリケーション１０２は、例えば、印刷のための文書あるいは画像データを作成し、ネットワーク１２０に接続するデバイスに対して印刷を指示する。
【００１３】
１０３はグラフィックデバイスインタフェース（ＧＤＩ）であり、ＧＤＩ１０３はアプリケーション１０２からの印刷指示を受け付ける。１０４はＧＤＩ１０３から呼び出されるプリンタドライバであり、アプリケーション１０２が印刷を指示すると、アプリケーション１０２はＧＤＩ１０３の呼び出しを行う。ＧＤＩ１０３の呼び出しは、印刷先のデバイスに依存しない、より抽象的な印刷指示コマンドである。プリンタドライバ１０４は、ＧＤＩ１０３からの呼び出しを印刷設定に従ってデバイスが解釈できるＰａｇｅＤｅｓｃｒｉｐｔｉｏｎＬａｎｇｕａｇｅ(ＰＤＬ)データに変換する。
【００１４】
尚、変換されるデータは、必ずしもＰＤＬである必要はなく、デバイスが解釈できるデータであればよい。変換されたデータはスプーラ１０５に送られる。スプーラ１０５は送られたデータをキューイングし、順次、送信部１０６にデータを送る。送信部１０６はスプーラ１０５からデータを受けとり、デバイスがデータの受付が可能か判定しながら、適切にデバイスへデータの送信を行う。１０７はイベントマネージャであり、他の情報処理装置（サーバコンピュータ１０８）の様々なアプリケーションからのイベント通知依頼（クライアントコンピュータ１０１で発生したイベントの通知の配信を依頼（「イベント通知依頼」ともいう））を受理する。つまり、イベントマネージャ１０７はイベント発生の通知先を管理する管理手段として動作する。具体的には、イベントマネージャ１０７は、受理したイベント通知依頼に基づいてイベント通知先（依頼元）を記憶し、イベント通知先（依頼元）をプリンタドライバ１０４に通知する。プリンタドライバ１０４は、イベントマネージャ１０７により通知されたイベント通知先（依頼元）に、デバイスに対してアクセスするイベント発生の通知を行う。このイベント発生の通知を受けたアプリケーション１０９は、デバイスＡ１１０、またはデバイスＢ１１１に対するアクセス（アプリケーションの処理）を開始することが可能になる。
【００１５】
尚、図１においてイベントマネージャ１０７は、クライアントコンピュータ１０１内に設けられているが、本発明の趣旨はこの構成に限定されるものではない。例えば、図１４に示すように、クライアントコンピュータ１０１とは独立した構成のサーバコンピュータ１１４にイベントマネージャ１０７を設けてもよい。また、プリンタドライバ１０４によるアプリケーション１０９へのイベント発生の通知のみに限定されない。この場合、例えば、図１４の構成において、サーバコンピュータ１０８のアプリケーション１０９はイベントマネージャ１０７にイベント通知依頼を行い、イベントマネージャ１０７はイベント通知先（依頼元）をプリンタドライバ１０４に通知する。そして、プリンタドライバ１０４は、デバイスに対してアクセスする場合、イベント通知先（依頼元）ではなく、サーバコンピュータ１１４のイベントマネージャ１０７にイベント発生の通知を行うことも可能である。そして、この通知を受けたイベントマネージャ１０７は、イベント発生の通知をイベント通知先（依頼元）に通知することも可能である。このイベント発生の通知を受けたアプリケーション１０９は、デバイスＡ１１０、またはデバイスＢ１１１に対するアクセス（アプリケーションの処理）を開始することが可能になる。
【００１６】
また、図１４の構成において、サーバコンピュータ１１２のアプリケーション１１３もイベントマネージャ１０７にイベント通知依頼を行っている場合、イベントマネージャ１０７は、複数の依頼元にイベント発生の通知を配信することも可能である。このイベント発生の通知を受けた各アプリケーション（１０９、１１３）は、それぞれデバイスＡ１１０、またはデバイスＢ１１１に対するアクセス（アプリケーションの処理）を開始することが可能になる。
【００１７】
図１、図１４の構成により、アプリケーション（１０９、１１３）のデバイスに対するアクセス（アプリケーションの処理）は、イベント発生の通知を受信するまで抑制されることになる。スリープモードから通常動作モードに移行させるイベント（例えば、プリンタドライバによる印刷の実行）の発生に連動して、他のアプリケーションによるデバイスへのアクセスタイミングを制御することで、デバイスの消費電力の抑制が可能になる。  本実施形態においては、デバイスへのアクセス動作処理を行うアクセス手段を概ね２つに分類できる。
【００１８】
１つ目は、ソフトウェアの機能・性質上、デバイスへのアクセス優先度が高いアクセス手段である。例えば、プリンタドライバソフトウェア等がこの１つ目のアクセス手段に該当する。プリンタドライバは生成した印刷データをプリンタデバイスにより印刷させる為のものであり、例えプリンタデバイスが省電力状態であっても、デバイスへのアクセスを必要とする場合が大きい。図１、１４のプリンタドライバ１０４がこれに該当する。また、その他に、プリンタデバイスへのアクセス優先度が高いアクセス手段として、例えば、フォームをダウンロードするアプリケーション等などが挙げられる。
【００１９】
２つ目は、ソフトウェアの機能・性質上、プリンタデバイスへのアクセスが比較的低いアクセス手段である。ここでの低いとは、少なくとも、上述の１つ目のアクセス手段よりも、デバイスへのアクセス優先度が低いことを指す。例えば、プリンタデバイスでの動作履歴を収集するログ収集ソフトウェアがこの２つ目のアクセス手段に該当する。そもそも、プリンタデバイスが省電力状態に移行している場合には、プリンタの動作履歴は変化しないことが想定される。従って、プリンタの省電力移行時には、必ずしもプリンタへアクセスする必要が無い。図１、１４のアプリケーション１０９、１１３がこれに該当する。また、その他に、比較的プリンタデバイスへのアクセス優先度が低いアクセス手段として、例えば、ジョブの状態を監視・通知するアプリケーション等が挙げられる。
【００２０】
以下の説明では、１つ目の分類のアクセス手段として、プリンタドライバ１０４を、また、２つ目の分類のアクセス手段として、アプリケーション１０９、１１３を例に説明を行う。しかしながら、何れのアクセス手段も、プリンタ等の特定のアプリケーションに限定されない。
【００２１】
説明を図１に戻し、サーバコンピュータ１０８には、アプリケーション１０９が搭載されており、ネットワーク１２０を介して、適宜ネットワーク１２０上のデバイスと通信してデバイスの情報を取得し、ユーザに様々なサービスを提供することが可能である。
【００２２】
１１０、１１１はネットワーク１２０に接続されているデバイス（デバイスＡ、デバイスＢ）であり、クライアントコンピュータ１０１から送信されるＰＤＬデータ等を印刷することが可能である。デバイスの機能としては、印刷の他、複写機能やＦＡＸ機能などを備えていても良い。また、それらを統合したマルチファンクション機能を有するデバイスとして構成してもよい。
【００２３】
図２は、クライアントコンピュータ１０１、サーバコンピュータ１０８の構成を示すブロック図である。図２において、２０１は中央処理装置（ＣＰＵ）であり、コンピュータ全体の制御および演算処理等を司る。２０２は読み出し専用メモリ（ＲＯＭ）であり、システム起動プログラムの情報等の記憶領域として機能する。２０３はランダムアクセスメモリ（ＲＡＭ）であり、使用制限のないデータ記憶領域として機能する。また、ＲＡＭ２０３は、オペレーティングシステム、アプリケーション、デバイスドライバおよび通信制御などのプログラムがロードされ、ロードされたプログラムの実行領域として機能する。
【００２４】
２０４はキーボード制御部（ＫＢＣ）であり、キーボードより入力データを受け取りＣＰＵへ伝達する。２０５はディスプレイ制御部（ＣＲＴ制御部）であり、ディスプレイ装置（ＣＲＴ）２１０への表示制御をする。２０６はフレキシブルディスク（ＦＤ）装置あるいはハードディスク（ＨＤ）装置あるいは不揮発性記憶装置（ＳＲＡＭ）等の外部記憶装置であり、プログラムおよびデータを記憶、格納しておき、実行時に必要に応じて参照またはＲＡＭ２０３へロードする。２０７は通信部であり、ネットワーク通信制御を行う。通信部２０７を介して、図１に示したネットワーク１２０に接続された他のコンピュータやデバイス（１１０、１１０）との通信が可能である。２０８はシステムバスであり、上述の各構成要素間を接続し、システムバス２０８を介して各構成要素間でデータの送受が可能である。
【００２５】
２１１はタイマーであり、現在時刻の計測を行う。ＣＰＵ２０１はタイマー２１１の計測結果に基づいて、アプリケーションの実行のタイミングを制御することが可能である。
【００２６】
図３はデバイスＡ１１０、デバイスＢ１１１の構成を示すブロック図である。図３において、３０５はデバイス全体を制御するコントローラである。コントローラ３０５の内部構成として３０１は中央処理装置（ＣＰＵ）であり、コントローラ３０５の制御および演算処理等を司る。３０２はＲＯＭであり、システム起動プログラムの情報等の記憶領域として機能する。３０３はＲＡＭであり、使用制限のないデータ記憶領域である。ＲＡＭ３０３にはオペレーティングシステムや通信制御およびエンジン制御などのプログラムがロードされ、ロードされたプログラムの実行領域として機能する。３０４はハードディスク（ＨＤ）あるいはＳＲＡＭなど不揮発性記憶装置（外部記憶装置）である。
【００２７】
３０６はデバイス（１１０、１１１）の入出力エンジン部であり、コントローラ３０５の制御のもとで印刷動作や画像読み取り動作を実行する。３０７は通信部であり、ネットワーク通信制御を行う。通信部３０７を介して、図１に示したネットワーク１２０に接続されたクライアントコンピュータ１０１やサーバコンピュータ１０８との通信が可能である。３０８は、ユーザ操作入出力部であり、ユーザから入力される入出力設定に関する処理を行う。３０９はシステムバスであり、上述の各構成要素間を接続し、システムバス３０８を介して各構成要素間でデータの送受が可能である。
【００２８】
図４はクライアントコンピュータ１０１の処理実行時におけるメモリマップ４０の構成を例示する図である。４１は基本Ｉ／Ｏプログラムを示す。４２はウインドウシステム等オペレーティングシステムがＲＡＭ２０３にロードされ実行可能となった状態のメモリマップを示す。４３は本発明の実施形態に係るプログラムがＲＡＭ２０３にロードされ実行可能となった状態のメモリマップを示す。４４は関連データがＲＡＭ２０３にロードされ実行可能となった状態のメモリマップを示す。４５は各々のプログラムが使用するワークエリアのメモリマップを示す。
【００２９】
本発明の実施形態に係るプログラムおよび関連データはフレキシブルディスク（ＦＤ）等の記憶媒体中に記録されている。図５は記憶媒体中に格納されている内容を示す図である。フレキシブルディスク（ＦＤ）等の記憶領域５０には、ボリューム情報５１、ディレクトリ情報５２、アプリケーション実行ファイル５３、プログラム関連データファイル５４等が格納されている。
【００３０】
図６に示すように、フレキシブルディスク（ＦＤ）６０に格納されたプログラムおよび関連データ等は、ＦＤドライブ（ＤＫＣ）６１を介して、クライアントコンピュータ１０１またはサーバコンピュータ１０８にロードすることができる。フレキシブルディスク（ＦＤ）６０をＦＤドライブ（ＤＫＣ）６１にセットすると、オペレーティングシステム４２及び基本Ｉ／Ｏプログラム４１の制御の下、プログラムおよび関連データ５４がフレキシブルディスク（ＦＤ）６０から読み出される。そして、プログラムおよび関連データ５４は、ＲＡＭ２０３にロードされて使用可能になる。
【００３１】
（プリンタドライバ１０４の処理）
次に、クライアントコンピュータ１０１にインストールされているプリンタドライバ１０４の処理の流れを図７のフローチャートを用いて説明する。このフローチャートはアプリケーション１０２が印刷を実行する場合を例とするものである。
【００３２】
このフローチャートはプリンタドライバの従来の処理に追加されるイベント通知を示すものである。
【００３３】
ステップＳ７０１において、イベントマネージャ１０７からプリンタドライバのジョブ処理の開始に対応する１又は複数のイベント通知先を取得する。例えば、イベントマネージャは規定のファイルにイベント通知先のアドレスを保存しており（後述の９０２で送信し、Ｓ９０４で受信待機するアドレス）、該ファイルからイベント通知先のアドレスを読み込むことによりＳ７０１の取得処理を行う。また、イベントマネージャとプロセス間の通信を行い取得するといった方法でイベント通知先を取得することもできる。
【００３４】
上でイベント通知先の文言を用いて文章を説明してきたが、例えば、図１におけるイベント通知先とは、ジョブの送信開始や終了をトリガとして動作するアプリケーションが該当する。このイベント通知先に該当するアプリケーションとしては、例えばジョブのステイタスを監視するアプリやジョブログを収集するアプリなどが考えられる。
【００３５】
ステップＳ７０２では、イベント発生の通知の１つであるジョブ開始イベントの通知の処理をＳ７０１で取得したアドレスに基づき行う。ステップＳ７０３では、ＧＤＩ１０３からの呼び出しを処理する。例えばジョブのステイタスを監視するアプリケーションはジョブ開始イベントをトリガにステイタス監視処理を開始することが考えられるが、このようなアプリケーションにジョブ開始イベントが利用される。
【００３６】
ステップＳ７０４では、すべてのＧＤＩの呼び出しを処理したか判別し、すべての処理を終えた場合は（Ｓ７０４−Ｙｅｓ）、ステップＳ７０５へ処理を進める。そうでない場合は（Ｓ７０４−Ｎｏ）、処理をステップＳ７０３に戻し、全てのＧＤＩの呼び出し処理が完了するまで、ステップＳ７０３、Ｓ７０４の処理を繰り返す。
【００３７】
ステップＳ７０５では、イベントマネージャ１０７からジョブ終了時のイベント通知先を取得する。
【００３８】
ステップＳ７０６では、イベント発生の通知の１つである、プリンタドライバのジョブ処理の終了を示すイベントの通知処理をＳ７０１で取得したアドレスに基づき行う。例えばジョブログを収集するアプリはこれをトリガとして処理を開始すればよい。これにより、ジョブログを収集するアプリケーションは、無駄に早期にアクセスすることなく、適切な遅延したタイミングでデバイスへアクセスすることができる。また、デバイスのステイタス監視アプリケーション等は、このＳ７０６の通知に対応してデバイスへのステイタス取得のアクセス（例えばポーリング）終了を行える。これにより、デバイスへの無駄なアクセスを抑止し、デバイスを早期に省電力状態に移行させることができる。
【００３９】
（イベント通知処理（S７０２、S７０６））
図８Ａのフローチャートを用いて、前述したステップＳ７０２、Ｓ７０６のイベント通知処理の流れを説明する。
【００４０】
ステップＳ８０１からＳ８０３は、すべての通知先にもれなくイベントを通知するための処理である。
【００４１】
ステップＳ８０１では、イベントマネージャ１０７から取得したすべての通知先への通知を行ったか判別し、すべての通知を行っていれば（Ｓ８０１−Ｙｅｓ）、処理を終了する。一方、未処理の通知先があれば（Ｓ８０１−Ｎｏ）、処理をステップＳ８０２に進め、通知先のアドレスをひとつ取り出す。
【００４２】
ステップＳ８０３において、先のステップＳ８０２で取り出した通知先のアドレスに対して通知処理を行う。ここで、通知処理とは、ＴＣＰ／ＩＰのポートに接続し、あらかじめ定められた形式で、ステップＳ８０２で取得したアドレスに対して、必要なデータを送信する処理をいう。Ｓ８０２における通知データの例を図８Ｂに示す。この例では、データはＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）形式で記述されている。タグ＜ＣｏｍｐｕｔｅｒＮａｍｅ＞８１０はイベントが発生したコンピュータのＴＣＰ／ＩＰにおけるホスト名を示す。タグ＜ＵｓｅｒＮａｍｅ＞８２０はイベントを発生させたユーザのログイン名を示す。タグ＜Ｄｅｖｉｃｅ＞８３０はジョブを送信する先のデバイスのＴＣＰ／ＩＰにおけるホスト名を示す。タグ＜ＪｏｂＳｔａｔｕｓ＞８４０はＢｅｆｏｒｅＪｏｂあるいはＡｆｔｅｒＪｏｂ等の通知内容の種類を表す値をとり、図８Ｂの場合では、ジョブの処理開始前、処理開始後を示す。
【００４３】
（アプリケーション１０９の処理）
次に、サーバコンピュータ１０８にインストールされているアプリケーション１０９の処理の流れを図９Ａのフローチャートを用いて説明する。図９Ａの例はジョブログを取得するアプリケーションの例を示している。取得したジョブログをＨＤＤやデータベースに蓄積することによって、単位期間ごとに、ユーザごとの印刷量を求めたり、印刷されたドキュメント名を一覧表示させたりするといったジョブアカウント機能を実現することができる。
【００４４】
ステップＳ９０１において、アプリケーション１０９は、アプリケーション１０９により状態を取得したいデバイスへのジョブ送信イベントを仲介するイベントマネージャ１０７（図１、図１４を参照）のアドレスを取得する。ここでのアドレス取得は後述の図１０のＵＩを介して設定された複数のイベントマネージャのアドレス（ＩＰアドレス及びポート番号の組）を取得する。アプリケーション１０９は、ここで取得したアドレスに対して、後述のＳ９０２のイベントデータの送信を行う。アドレスは通信プロトコルにより決まるが、ここでは、ＴＣＰ／ＩＰ上で独自のプロトコルの通信を行うものとする。イベントマネージャ１０７のアドレスはユーザが設定アプリケーションによりセットすることが可能である。
【００４５】
図１０は、アドレス設定ダイアログ１００１の例を示す図である。アドレスとはイベントマネージャの所在を示すものである。アドレス設定ダイアログ１００１にはアドレス一覧リスト１００２、アドレス入力欄１００３、追加ボタン１００４、削除ボタン１００５、終了ボタン１００６が表示される。ユーザはアドレス入力欄１００３からＩＰアドレス１０５０とポート番号１０６０とからなるアドレス入力することができる。追加ボタン１００４の押下により、入力されたアドレスがアドレス一覧１００２に追加され、削除ボタン１００５により登録されているアドレスを削除することができる。終了ボタン１００６の押下によりアドレス設定ダイアログの表示は終了する。
【００４６】
説明を図９Ａに戻し、ステップＳ９０２において、先のステップＳ９０１で取得した１又は複数のイベントマネージャ１０７のアドレスとＴＣＰ／ＩＰで接続を確立し、イベント通知依頼を示すデータをイベントマネージャ１０７に送信する。ここで通知したイベント通知先が、上に説明した図８Ａにおける通知先になり、複数の各アプリケーション１０９の各々によりＳ９０２の処理が実行され、結果、図８ＡのＳ８０１乃至Ｓ８０３のループで複数の通知先が取り出される。
【００４７】
イベント通知依頼を示すデータの例を図９Ｂに示す。タグ＜ＣｏｍｐｕｔｅｒＮａｍｅ＞９１５はイベント通知依頼をするコンピュータのＴＣＰ／ＩＰにおけるホスト名を示す。タグ＜Ａｄｄｒｅｓｓ＞９１６は、イベントを受信するサーバ１０８のアドレスを示す。タグ＜ＵｓｅｒＮａｍｅ＞９１７はイベント通知依頼するユーザのログイン名を示す。そして、タグ＜ＪｏｂＳｔａｔｕｓ＞９１８はジョブがどの状態でイベントを発生すべきかを示す。ＢｅｆｏｒｅＪｏｂあるいはＡｆｔｅｒＪｏｂのいずれかの値をとり、それぞれジョブの処理開始前、処理開始後を表す。
【００４８】
イベントマネージャからの返信データの主要部分の例を、図９Ｃに示す。＜ＳｕｂｓｃｒｉｂｅＩｄ＞９２０は整数値をとり、正の数であれば成功であり、その値によりイベント通知依頼を一意に特定することができる。アプリケーションが処理を終えるときは、この数値でイベント通知依頼を解除する。なお、図９Ｃ及び後述する各データ例には、＜Ａｄｄｒｅｓｓ＞等のタグが省略されているが、実際には、図９Ｂで説明したものと同様に、２者間で通信を行うに必要なデータが含まれているものとする。
【００４９】
また、＜ＳｕｂｓｃｒｉｂｅＩｄ＞９２０が負の数であればイベント通知依頼は失敗したことを示す。
【００５０】
ステップＳ９０３において、例えば図１の場合、アプリケーション１０９はデバイスA１１０と接続し、最も新しいジョブログの最新ジョブログ情報（最新ログ番号）を取得する。これを読み込み済みログ番号とする。アプリケーション１０９とデバイスとの通信については後述する。
【００５１】
ステップＳ９０４において、先のステップＳ９０２でイベント通知依頼としてイベントマネージャ１０７に送信したアドレスを受け口としてオープンする。以後、データの受信が可能になる。すなわちＳ９０１−９０４がジョブログをもれなく取得するための前処理と言える。以降は待ち受けとイベントをトリガとする処理の説明である。
【００５２】
その後、所定の時間が経過して、デバイスＡ１１０は通常の動作が可能な状態（通常動作モード）から省電力状態（スリープモード）に移行しているものとする。ここでデバイスの省電力状態には複数の状態が想定される。例えば、プリンタエンジンの通電を抑制した状態が挙げられる。この状態では、プリンタコントローラ部やネットワークインタフェース（ＮＩＣ）部分は通常の動作が可能な状態で可動している。また、プリンタエンジン、及び、プリンタコントローラ部、及び、ネットワークインタフェース（ＮＩＣ）部分の通常通信機能を停止した超省電力状態等も挙げることができる。ここで、通常通信機能とは、ＰＤＬや各種ステイタス要求等に関するデータの送受信が可能な機能をいう。ネットワークインタフェース（ＮＩＣ）部分は、通常通信機能の一部を停止させた状態でも、例えば、ＡＲＰ（Address  Resolution  Protocol）パケット等の特定のパターンデータの送受信は可能である。
【００５３】
何れの省電力状態でも、外部からのアクセスにより省電力復帰が発生し、この省電力復帰を抑制することが望まれる。本実施形態では、省電力状態の１例として、上記の超省電力状態を例に説明を行う。
【００５４】
ステップＳ９０５において、アプリケーション１０９は、イベント発生の通知が着信しているか判別し、イベント発生の通知が着信していれば（Ｓ９０５−Ｙｅｓ）、処理をステップＳ９０６へ進める。なお、実際には、不図示のステップで、イベント発生通知の内容（種別）を判断し、該判断に基づきＳ９０６へ処理を移行させるかを判断する。具体的には図８Ｂで例示した通知内容を識別し、着信有りとすべきかを判定する。
【００５５】
一方、ステップＳ９０５の判定で、イベント発生の通知の着信がなければ（Ｓ９０５−Ｎｏ）、イベント発生通知の着信待ちの状態で待機する（Ｓ９０５）。
【００５６】
イベント発生通知の着信がある場合（Ｓ９０５−Ｙｅｓ）、イベント発生の通知を受けたアプリケーション１０９は、デバイスＡ１１０に対するアクセス（最新ログ番号を取得するアプリケーションの処理）を開始することが可能になる。
【００５７】
そして、ステップＳ９０６において、アプリケーション１０９は、図８Ｂで例示した通知内容に基づいて、デバイスＡ１１０と接続し、最新ログ番号をデバイスＡ１１０から取得する。デバイスとの通信については後述する。
【００５８】
先のステップＳ９０５において、イベント発生通知の着信が有ると判定されると、アプリケーション１０９は、ステップＳ９０６によりデバイスＡ１１０と直ちに通信を開始することが可能である。しかし、この時点において、デバイスＡ１１０がスリープモードから通常動作モードへ移行が完了していない場合、通信は失敗することがありうる。このような場合、通常はリトライを行うが、ステップＳ９０５とステップＳ９０６との間に一定のウエイト時間を設け、アプリケーション１０９は通信処理を開始するタイミングを遅らせることも可能である。これにより、デバイスＡ１１０がスリープモードのときに、通信が開始してしまうことを防ぐことも可能である。
【００５９】
ステップＳ９０７において、最新ログ番号と読み込み済みログ番号を比較し、最新ログ番号が読込済番号より大きければ（Ｓ９０７−Ｙｅｓ）、処理をステップＳ９０９に進める。そうでなければ（Ｓ９０７−Ｎｏ）、ステップＳ９０８へ処理を進める。
【００６０】
ステップＳ９０８では、規定の時間（例えば、２０秒）だけ待機状態とする（待機処理）。規定時間の待機処理は、デバイス１１０に対する通信が過多になるのを防ぐことを目的とするものであり、規定の時間の設定は可変である。
【００６１】
ステップＳ９０９において、アプリケーション１０９はデバイスと通信して、（読み込み済みログ番号＋１）から最新ログ番号までのジョブログを取得する。デバイスＡ１１０との通信については後述する。
【００６２】
そして、ステップＳ９１０において、取得したジョブログを外部記憶装置２０６に保存する。
【００６３】
ステップＳ９１１において、アプリケーション１０９に終了要求が来ているか判別し、終了要求が来ていれば（Ｓ９１１−Ｙｅｓ）、処理をステップＳ９１２に進める。そして、アプリケーション１０９は、イベント通知依頼の解除を示すデータをイベントマネージャ１０７に送信する。図９Ｄは、イベント通知依頼の解除データの主要部を例示する図である。一方、ステップＳ９１１の判定で、終了要求が来ていなければ（Ｓ９１１−Ｎｏ）、処理をステップＳ９０５に戻し、特定の内容（種別）を示すイベント発生通知の着信待ちの状態で待機する（Ｓ９０５）。
【００６４】
ステップＳ９１３では、先のステップＳ９０４でオープンしたイベント受信用のポートをクローズし、処理を終了する。
【００６５】
（デバイスとの通信）
次に、前述したデバイスＡ１１０（或はデバイスＢ１１１）とアプリケーション１０９との通信について説明する。ネットワーク機器の通信プロトコルとしては、従来からＳＮＭＰが提案されているのでこれを用いても良いし、図９Ｅに示すデータの例のように、ＸＭＬ形式で通信することも考えられる。図９Ｅは、最新ログ番号を取得するリクエストデータの例を示す図であり、データはＴＣＰ／ＩＰで送信・受信される。また、図９Ｆは、デバイスから返信されるデータの例を示す図である。タグ＜ＬａｔｅｓｔＪｏｂＬｏｇＮｕｍｂｅｒ＞９２５より、最新のログナンバは「３０」である。
【００６６】
次に、アプリケーション１０９がログデータを取得するリクエストデータの例を図９Ｇに示す。タグ＜Ｆｒｏｍ＞９３０、タグ＜Ｔｏ＞９３５は、取得するログ番号が２１以上２２未満のジョブログデータの要求であることを示す。図９Ｈは、ログデータの取得要求に対してデバイスＡ１１０が返信するデータを例示する図である。タグ＜Ｎｕｍｂｅｒ＞９４０は、返信されるデータがログ番号：２１であることを示し、タグ＜ＤｏｃｕｍｅｎｔＮａｍｅ＞９４５は、ドキュメント名が「ＳｔａｔｕｓＲｅｐｏｒｔ．ｔｘｔ」であることを示している。タグ＜ＪｏｂＴｙｐｅ＞９５０は、ジョブタイプがＰＤＬ印刷であることを示し、タグ＜＜ＵｓｅｒＮａｍｅ＞９５５は、ユーザ名が「Ｔａｎａｋａ」であることを示している。
【００６７】
尚、デバイスＡ１１０から返信されるデータとしては、上述の図９Ｈの例に限定されるものではない。例えば、図１１に示す、「論理ページの数」、「用紙数」、「用紙片面あたりの割付ページ数」、「両面、片面」、「開示時刻」、「終了時刻」等が、デバイスＡ１１０におけるジョブの実行の状態に応じて返信される。
【００６８】
以上説明したとおり、本実施形態に拠れば、アプリケーションによりデバイスのログ情報を取得する場合、ユーザの利便性に優れ、よりシンプルなプロセスによりデバイスの消費電力を抑制することが可能になる。
【００６９】
（第２実施形態）
次に、本発明の第２実施形態を、図１２、図１３Ａ、図１３Ｂ及び図１３Ｃの参照により説明する。システムの構成は第１実施形態と同様であるが、アプリケーション１０９は、デバイス上で実行されるジョブの状態を監視する「ジョブ状態監視アプリケーション」である点において相違する。
【００７０】
図１２は、例えば、デバイスＡ１１０で実行されるジョブの状態を、ＣＲＴ制御部２０５の制御の下、ＣＲＴ２１０上に表示されるダイアログ１２０１を示す図である。ダイアログ１２０１は、対象となるデバイスＡ１１０で処理中のジョブの一覧を示すリスト表示１２０２により構成される。ジョブ一覧表示１２０２には、ジョブ名１２０４、ユーザ名１２０５、デバイス１１０におけるジョブの処理状態１２０６を示す情報が含まれる。終了ボタン１２０３が押下されるとジョブ状態表示ダイアログ１２０１が閉じられる。
【００７１】
次に、本発明の第２実施形態に係るアプリケーション１０９の処理の流れを図１３Ａのフローチャートを用いて説明する。
【００７２】
ステップＳ１３０１において、アプリケーション１０９はイベントマネージャ１０７（図１、図１４を参照）のアドレスを取得する。この処理内容は前述したステップＳ９０１と同じである。
【００７３】
ステップＳ１３０２において、先のステップＳ１３０１で取得したイベントマネージャ１０７のアドレスとＴＣＰ／ＩＰで接続を確立し、イベント通知依頼を示すデータをイベントマネージャ１０７に送信する。この処理内容は前述したステップＳ９０２と同じである。
【００７４】
ステップＳ１３０３において、先のステップＳ１３０２で、イベント通知依頼を示すデータをイベントマネージャ１０７に送信したアドレスを受信ポートとしてオープンする。以後、データの受信が可能になる。
【００７５】
その後、所定の時間が経過して、デバイスＡ１１０は通常の動作が可能な状態（通常動作モード）から省電力状態（スリープモード）に移行しているものとする。
【００７６】
ステップＳ１３０４において、アプリケーション１０９は、図９Ｂの＜ＪｏｂＳｔａｔｕｓ＞のタグで説明したような、特定内容のイベント発生の通知が着信しているか判別する。そして、特定内容のイベント発生の通知が着信していれば（Ｓ１３０４−Ｙｅｓ）、処理をステップＳ１３０５へ進める。一方、ステップＳ１３０４の判定で、イベント発生通知の着信がなければ（Ｓ１３０４−Ｎｏ）、イベント発生通知の着信待ちの状態で待機する（Ｓ１３０４）。
【００７７】
イベント発生通知の着信がある場合（Ｓ１３０４−Ｙｅｓ）、イベント発生の通知を受けたアプリケーション１０９は、デバイスＡ１１０に対するアクセス（デバイスＡ１１０の状態監視処理）を開始することが可能になる。
【００７８】
ステップＳ１３０５において、アイドル開始時刻という変数を設け、それを「０」に初期化する。この変数は、０であるとき、監視対象のデバイスがアイドル状態にあることを示し、時刻が設定されている場合、その時刻は、アプリケーション１０９がデバイスのアイドル状態を検知した最初の時刻を示す。
【００７９】
ステップＳ１３０６において、ＣＲＴ制御部２０５の表示制御の下、ＣＲＴ２１０上に図１２で示したジョブ状態表示ダイアログ１２０１を表示する。このときジョブ一覧リスト１２０２は空の状態である。
【００８０】
ステップＳ１３０７において、アプリケーション１０９はデバイスＡ１１０と通信し、ジョブリストを取得する。このジョブリストは、デバイスＡ１１０上で実行が開始され、まだ終了していないジョブのリストである。デバイスＡ１１０とアプリケーション１０９との通信は、第１実施形態で説明した最新ログ番号を取得する手順（図９ＡのステップＳ９０６）と同様であるので詳細な説明は省略する。
【００８１】
ジョブリストを取得するためのリクエストデータの例を図１３Ｂに示す。図１３Ｂにおいて、タグ＜ＪｏｂＳｔａｔｕｓ＞１３２０は返信を要求するジョブの状態を示す。なお、図１３Ｂ、Ｃには、＜Ａｄｄｒｅｓｓ＞等のタグが省略されているが、実際には、図９Ｂで説明したものと同様に、２者間で通信を行うに必要なデータが含まれているものとする。ジョブの状態としては、例えば、待機中／実行中／エラー／完了／すべて／などが考えられ、図１３Ｂでは「すべて」を示す「ＡＬＬ」が指定されている。タグ＜ＪｏｂＴｙｐｅ＞１３３０は返信を要求するジョブのタイプを示す。ジョブのタイプとしては、ＰＤＬ／コピー／ＦＡＸ送信／保存ジョブ／すべて／などが考えられ、図１３Ｂでは「すべて」を示す「ＡＬＬ」が指定されている。
【００８２】
次に、図１３Ｂに示すリクエストに対してデバイスＡ１１０が返信するデータの例を図１３Ｃに示す。返信されるデータには、デバイスＡ１１０において、実行が開始され、まだ終了していないジョブとして、ジョブ１（１３３５）、ジョブ２（１３４０）、ジョブ３（１３４５）に関するデータが返信される。例えば、ジョブ１（１３３５）の場合、タグ＜Ｎｕｍｂｅｒ＞９４０は、返信されるデータがログ番号：２１であることを示し、タグ＜ＤｏｃｕｍｅｎｔＮａｍｅ＞１３３６は、ドキュメント名が「ＳｔａｔｕｓＲｅｐｏｒｔ．ｔｘｔ」であることを示している。タグ＜ＵｓｅｒＮａｍｅ＞１３３７は、ユーザ名が「Ｔａｎａｋａ」であることを示している。タグ＜Ｓｔａｔｕｓ＞１３３８は、用紙なしの状態であることを示している。ジョブ２（１３４０）、ジョブ３（１３４５）についても、それぞれのジョブ内容が記述されたデータが返信されることになる（図１３Ｃにおいて、ジョブ２（１３４０）、ジョブ３（１３４５）の詳細は表記が省略されているものとする）。
【００８３】
説明を図１３Ａに戻し、ステップＳ１３０８において、アプリケーション１０９は、先のステップＳ１３０７で取得したジョブリストの内容が前回のジョブリストと変化があるか判定する。ジョブリストに変化があれば（Ｓ１３０８−Ｙｅｓ）、処理をステップＳ１３０９に進め、変化がなければ（Ｓ１３０８−Ｎｏ）、処理をステップＳ１３１１に進める。前回ジョブリストは後述するステップＳ１３１０で保存されているものとする。
【００８４】
ステップＳ１３０９において、ＣＲＴ制御部２０５は、先のステップＳ１３０７で取得したジョブリストを基にジョブ一覧リスト１２０２を更新する。
【００８５】
そして、ステップＳ１３１０において、ステップＳ１３０７で取得したジョブリストを前回ジョブリストとして、外部記憶装置２０６に記憶する。
【００８６】
ステップＳ１３１１において、あらかじめ定めた規定の時間（例えば、２０秒）だけ待機状態とする（待機処理）。この処理はステップＳ１３０７の処理が過多になることを防ぐものである。規定時間の待機処理は、デバイス１１０に対する通信が過多になるのを防ぐことを目的とするものであり、規定の時間の設定は可変である。
【００８７】
ステップＳ１３１２において、ステップＳ１３０７で取得したジョブリスト中にジョブの数が１以上有るか判定する。ジョブの数が１以上の場合（Ｓ１３１２−Ｙｅｓ）、処理をステップＳ１３１３に進め、ステップＳ１３１３において、アプリケーション１０９はアイドル開始時刻を０クリアする。
【００８８】
一方、ステップＳ１３１２の判定でジョブの数が１つ以上でない場合、すなわち、０の場合（Ｓ１３１２−Ｎｏ）、処理をステップＳ１３１４に進め、ステップＳ１３１４において、アプリケーション１０９はアイドル開始時刻が０であるか判定する。アイドル開始時刻が０であれば（Ｓ１３１４−Ｙｅｓ）、処理をステップＳ１３１５へ進め、ステップＳ１３１５において、アイドルが開始されたと判定し、アイドル開始時刻に現在時刻をセットして、処理をステップＳ１３０７に戻す。ステップＳ１３０７において、ジョブリストの取得以降の処理が同様に実行される。
【００８９】
一方、ステップＳ１３１４の判定で、アイドル開始時刻が０でなく、時刻データが既に設定されている場合（Ｓ１３１４−Ｎｏ）、処理をステップＳ１３１６に進める。ステップＳ１３１６において、前回のアクセスからデバイスＡ１１０のアイドル状態が継続している場合、アプリケーション１０９はアイドル開始時刻から現在時刻までの経過時間を算出する。そして、アプリケーション１０９は算出した経過時間があらかじめ定めた設定値（時間）より長ければ（Ｓ１３１６−Ｙｅｓ）、処理をステップＳ１３１７に進める。
【００９０】
一方、ステップＳ１３１６の判定で、アイドル開始時刻から現在時刻までの経過時間が、設定値（時間）より短ければ（Ｓ１３１６−Ｎｏ）、処理はステップＳ１３０７に戻され、ジョブリストの取得以降の処理が継続して実行される。
【００９１】
ステップＳ１３１７において、ＣＲＴ制御部２０５は、先のステップＳ１３０６で表示され、ステップＳ１３０９で更新されたジョブ状態表示ダイアログ１２０１を非表示に制御する。
【００９２】
ステップＳ１３１８においてアプリケーション１０９は、イベント通知依頼の解除を示すデータ（図９Ｄを参照）をイベントマネージャ１０７に送信する。
【００９３】
そして、ステップＳ１３１９において、先のステップＳ１３０３でオープンしたイベント受信用のポートをクローズし、処理を終了する。
【００９４】
以上説明したとおり、本実施形態に拠れば、アプリケーションによりデバイスの状態監視処理を実行する場合、ユーザの利便性に優れ、よりシンプルなプロセスによりデバイスの消費電力を抑制することが可能になる。
【００９５】
（第３実施形態）
第１実施形態において、イベントマネージャ１０７のアドレスは、図１０に示すアドレス設定ダイアログ１００１により設定されていたが、イベントマネージャ１０７の所在（アドレス）は、Ｗｅｂサービスによる検索を用いて取得することも可能である。この場合、印刷ジョブ送信などを行うアプリケーション（図１の場合、プリンタドライバ１０４）はＵＤＤＩに、自分自身が（１）デバイスをスリープモードから通常モードに移行させること、（２）移行させる前にイベント発生を通知することを登録しておく。
【００９６】
ここで、ＵＤＤＩ  とはＵｎｉｖｅｒｓａｌ  Ｄｅｓｃｒｉｐｔｉｏｎ，  Ｄｉｓｃｏｖｅｒｙ  ａｎｄ  Ｉｎｔｅｇｒａｔｉｏｎの略である。ＵＤＤＩ  はＸＭＬを応用した、インターネット上に存在するＷｅｂサービスの検索・照会システムである。
【００９７】
ジョブログやデバイスの状態監視情報を取得するアプリケーション１０９は、ＵＤＤＩからデバイスをスリープモードから通常モードに移行させる。そして、イベント発生の通知を行うアプリケーション（例えばプリンタドライバ１０４）を検索し、検索されたアプリケーションに対してイベント通知依頼をすることも可能である。
【００９８】
プリンタドライバ１０４等のイベント通知依頼先のアプリケーションをＵＤＤＩの検索により特定することで、図１０のように手動でイベントマネージャ１０７のアドレスを設定することが不要になり、よりユーザの利便性を向上させることが可能になる。
【００９９】
（第４実施形態）
上述の第３実施形態では、プリンタドライバ等の１つ目の分類に属するアクセス手段を検索する手段として、ＵＤＤＩを例に説明してきた。しかし、検索手段としてはこれに限定されない。例えば、ＭＩＢを新たに定義し、その新たに定義したＭＩＢを用いてプリンタドライバ等の１つ目の分類に属するアクセス手段を検索する検索手段を構築しても良い。
【０１００】
（他の実施形態）
なお、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システムあるいは装置に供給することによっても、達成されることは言うまでもない。また、システムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読出し実行することによっても、達成されることは言うまでもない。
【０１０１】
この場合、記憶媒体から読出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【０１０２】
プログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク，ハードディスク，光ディスク，光磁気ディスク，ＣＤ−ＲＯＭ，ＣＤ−Ｒ，不揮発性のメモリカード，ＲＯＭなどを用いることができる。
【０１０３】
また、コンピュータが読出したプログラムコードを実行することにより、前述した実施形態の機能が実現される。また、プログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態が実現される場合も含まれることは言うまでもない。
【図面の簡単な説明】
【０１０４】
【図１】本発明の実施形態に係る情報処理システムの概略的な構成を示すブロック図である。
【図２】本発明の実施形態に係るクライアントコンピュータ１０１、サーバコンピュータ１０８の構成を示すブロック図である。
【図３】本発明の実施形態に係るデバイスA１１０、デバイスB１１１の構成を示すブロック図である。
【図４】クライアントコンピュータ１０１の処理実行時におけるメモリマップの構成を例示する図である。
【図５】記憶媒体中に格納されている内容を例示する図である。
【図６】フレキシブルディスク（ＦＤ）に格納されたプログラム等のロードを説明する図である。
【図７】本発明の第１実施形態に係るプリンタドライバ１０４の処理の流れを説明する図である。
【図８Ａ】図７のステップＳ７０２、Ｓ７０６におけるイベント通知処理の流れを説明する図である。
【図８Ｂ】通知データの例を示す図である。
【図９Ａ】本発明の第１実施形態に係るアプリケーション１０９の処理の流れを説明する図である。
【図９Ｂ】イベント通知依頼を示すデータの例を示す図である。
【図９Ｃ】イベント通知依頼に対するデバイスからの返信データの例を示す図である。
【図９Ｄ】イベント通知依頼の解除データを例示する図である。
【図９Ｅ】最新ログ番号を取得するリクエストデータの例を示す図である。
【図９Ｆ】最新ログ番号を取得するリクエストに対してデバイスから返信されるデータの例を示す図である。
【図９Ｇ】アプリケーション１０９がログデータを取得するリクエストデータの例を示す図である。
【図９Ｈ】ログデータの取得要求に対してデバイスが返信するデータを例示する図である。
【図１０】アドレス設定ダイアログの例を示す図である。
【図１１】本発明の第１実施形態において、デバイスから返信されるデータの内容を例示する図である。
【図１２】本発明の第２実施形態において、デバイスで実行されるジョブの状態を、ＣＲＴ制御部の制御の下、ＣＲＴに表示されるダイアログを示す図である。
【図１３Ａ】本発明の第２実施形態に係るアプリケーション１０９の処理の流れを説明する図である。
【図１３Ｂ】ジョブリストを取得するためのリクエストデータの例を示す図である。
【図１３Ｃ】図１３Ｂに示すリクエストに対してデバイスが返信するデータの例を示す図である。
【図１４】本発明の実施形態に係る情報処理システムの概略的な構成を示すブロック図である。
【図１】
0004455523.tif 000002
【図２】
0004455523.tif 000003
【図３】
0004455523.tif 000004
【図４】
0004455523.tif 000005
【図５】
0004455523.tif 000006
【図６】
0004455523.tif 000007
【図７】
0004455523.tif 000008
【図８Ａ】
0004455523.tif 000009
【図８Ｂ】
0004455523.tif 000010
【図９Ａ】
0004455523.tif 000011
【図９Ｂ】
0004455523.tif 000012
【図９Ｃ】
0004455523.tif 000013
【図９Ｄ】
0004455523.tif 000014
【図９Ｅ】
0004455523.tif 000015
【図９Ｆ】
0004455523.tif 000016
【図９Ｇ】
0004455523.tif 000017
【図９Ｈ】
0004455523.tif 000018
【図１０】
0004455523.tif 000019
【図１１】
0004455523.tif 000020
【図１２】
0004455523.tif 000021
【図１３Ａ】
0004455523.tif 000022
【図１３Ｂ】
0004455523.tif 000023
【図１３Ｃ】
0004455523.tif 000024
【図１４】
0004455523.tif 000025