(57)【特許請求の範囲】
【請求項１】
デバイス及び端末装置と通信可能な情報処理装置であって、
上記デバイスでのイベントを上記端末装置に通知するイベント通知の登録の要求を上記端末装置から受け付ける受付手段と、
上記受付手段により受け付けた登録の要求に従って、上記端末装置をイベント通知の通知先として登録する登録手段と、
上記デバイスでのイベントを上記情報処理装置に通知するイベント通知の登録を上記デバイスに要求する要求手段と、
上記デバイスから、上記デバイスでのイベントに関するイベント通知情報を受信する受信手段と、
上記端末装置がイベント通知の通知先として上記登録手段によって登録されている場合、上記受信手段により受信されたイベント通知情報を、上記端末装置に配信する配信手段と、
上記デバイスでのイベントを上記端末装置に通知するイベント通知の登録を削除する要求を上記端末装置から受け付ける第２の受付手段と、
上記第２の受付手段により受け付けた登録を削除する要求に従って、上記端末装置をイベント通知の通知先から削除する削除手段と、
上記削除手段により上記端末装置がイベント通知の通知先から削除された結果、登録されているイベント通知の通知先がなくなった場合に、上記デバイスでのイベントを上記情報処理装置に通知するイベント通知の登録を削除することを上記デバイスに要求する削除要求手段と、
を有することを特徴とする情報処理装置。
【請求項２】
上記デバイスからイベント通知を受けるためのポートを確立する確立手段と、
上記確立手段によりポートが確立された場合、ポートが確立された装置を管理する管理部に、ポートが確立された旨を通知する通知手段と、
を有することを特徴とする請求項１記載の情報処理装置。
【請求項３】
上記通知手段は、上記確立手段によりポートが確立されなかった場合、上記管理部に、ポートが確立されなかった旨を通知することを特徴とする請求項２記載の情報処理装置。
【請求項４】
上記管理部は、上記端末装置からの要求に応じて、上記デバイスでのイベントを上記端末装置に通知するイベント通知の登録の要求先を識別する情報を上記端末装置に送信することを特徴とする請求項２又は３記載の情報処理装置。
【請求項５】
上記受信手段は、上記確立手段により確立されたポートを介して、上記デバイスから上記イベント通知情報を受信することを特徴とする請求項２乃至４のいずれか１項に記載の情報処理装置。
【請求項６】
上記受付手段により受け付けた登録の要求に従って、上記デバイスでのイベントを上記情報処理装置に通知するイベント通知の登録が上記デバイスになされているか否かを判別する判別手段を有し、
上記要求手段は、イベント通知の登録が上記デバイスになされていないと判別された場合に、イベント通知の登録を上記デバイスに要求することを特徴とする請求項１乃至５のいずれか１項に記載の情報処理装置。
【請求項７】
複数の端末装置が上記登録手段によりイベント通知の通知先として登録されている場合、上記配信手段は、上記複数の端末装置のそれぞれに上記イベント通知情報を配信することを特徴とする請求項１乃至６のいずれか１項に記載の情報処理装置。
【請求項８】
デバイスを管理するデバイス管理方法であって、
情報処理装置において、上記デバイスでのイベントを端末装置に通知するイベント通知の登録の要求を上記端末装置から受け付ける受付ステップと、
上記情報処理装置において、上記受付ステップで受け付けた登録の要求に従って、上記端末装置をイベント通知の通知先として登録する登録ステップと、
上記情報処理装置において、上記デバイスでのイベントを上記情報処理装置に通知するイベント通知の登録を上記デバイスに要求する要求ステップと、
上記情報処理装置において、上記デバイスから、上記デバイスでのイベントに関するイベント通知情報を受信する受信ステップと、
上記情報処理装置において、上記端末装置がイベント通知の通知先として上記登録ステップで登録されている場合、上記受信ステップで受信されたイベント通知情報を、上記端末装置に配信する配信ステップと、
上記情報処理装置において、上記デバイスでのイベントを上記端末装置に通知するイベント通知の登録を削除する要求を上記端末装置から受け付ける第２の受付ステップと、
上記情報処理装置において、上記第２の受付ステップで受け付けた登録を削除する要求に従って、上記端末装置をイベント通知の通知先から削除する削除ステップと、
上記削除ステップにより上記端末装置がイベント通知の通知先から削除された結果、登録されているイベント通知の通知先がなくなった場合、上記情報処理装置において、上記デバイスでのイベントを上記情報処理装置に通知するイベント通知の登録を削除することを上記デバイスに要求する削除要求ステップと、
を有することを特徴とするデバイス管理方法。
【請求項９】
上記デバイスからイベント通知を受けるためのポートを確立する確立ステップを有することを特徴とする請求項８記載のデバイス管理方法。
【請求項１０】
上記確立ステップでポートが確立された場合、ポートが確立された装置を管理する管理部に、ポートが確立された旨を通知する第１の通知ステップと、
上記確立ステップでポートが確立されなかった場合、上記管理部に、ポートが確立されなかった旨を通知する第２の通知ステップと、
を有することを特徴とする請求項９記載のデバイス管理方法。
【請求項１１】
上記端末装置において、上記デバイスでのイベントを上記端末装置に通知するイベント通知の登録の要求先を識別する情報を上記管理部から取得する識別情報取得ステップを有することを特徴とする請求項１０記載のデバイス管理方法。
【請求項１２】
上記受信ステップでは、上記確立ステップで確立されたポートを介して、上記デバイスから上記イベント通知情報を受信することを特徴とする請求項８乃至１１のいずれか１項に記載のデバイス管理方法。
【請求項１３】
上記情報処理装置において、上記受付ステップ受け付けた登録の要求に従って、上記デバイスでのイベントを上記情報処理装置に通知するイベント通知の登録が上記デバイスになされているか否かを判別する判別ステップを有し、
上記要求ステップは、イベント通知の登録が上記デバイスになされていないと判別された場合に、イベント通知の登録を上記デバイスに要求することを特徴とする請求項８乃至１２のいずれか１項に記載のデバイス管理方法。
【請求項１４】
上記情報処理装置において、上記登録ステップにより複数の端末装置がイベント通知の通知先として登録されている場合、上記配信ステップでは、上記複数の端末装置のそれぞれに上記イベント通知情報を配信することを特徴とする請求項８乃至１３のいずれか１項に記載のデバイス管理方法。
【請求項１５】
上記端末装置において、上記デバイスでのイベントをクライアントソフトウェアに通知するイベント通知の登録の要求を上記クライアントソフトウェアから受け付ける第３の受付ステップと、
上記端末装置において、上記第３の受付ステップで受け付けた登録の要求に従って、上記クライアントソフトウェアをイベント通知の通知先として登録する第２の登録ステップと、
上記端末装置において、上記デバイスでのイベントを上記端末装置に通知するイベント通知の登録を上記情報処理装置に要求する第２の要求ステップと、
上記端末装置において、上記情報処理装置から、上記イベント通知情報を受信する第２の受信ステップと、
上記クライアントソフトウェアがイベント通知の通知先として上記第２の登録ステップで登録されている場合、上記端末装置において、上記第２の受信ステップで受信された上記イベント通知情報を、上記クライアントソフトウェアに配信する第３の配信ステップと、
を有することを特徴とする請求項８乃至１４のいずれか１項に記載のデバイス管理方法。
【請求項１６】
請求項８乃至１５のいずれか１項に記載のデバイス管理方法の各ステップをコンピュータに実行させるためのプログラムを記録したコンピュータ読取可能な記憶媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、例えば、ネットワーク上に接続されたデバイスを管理するための装置或いはシステムに用いられる、情報処理装置、デバイス管理方法、及びそれを実施するためのプログラムを記憶したコンピュータ読取可能な記憶媒体に関するものである。
【０００２】
【従来の技術】
従来より例えば、ネットワーク上のデバイスを管理する方法としては、ＳＮＭＰ（ｓｉｍｐｌｅ  ｎｅｔｗｏｒｋ  ｍａｎａｇｅｍｅｎｔ  ｐｒｏｔｏｃｏｌ）／ＭＩＢ（ｍａｎａｇｅｍｅｎｔ  ｉｎｆｏｒｍａｔｉｏｎ  ｂａｓｅ）による方法がある。
ＳＮＭＰとは、ＴＣＰ／ＩＰネットワーク上でネットワーク管理システムを構成するためのプロトコルである。ＭＩＢとは、当該ネットワーク管理システム上で、管理ソフトウェア（マネージャ）が管理情報を効率的に検索及び設定できるようにツリー上に番号付けして並べた仮想的なデータベースである。
【０００３】
尚、ＳＮＭＰ／ＭＩＢについての詳細は、「“ＴＣＰ／ＩＰ ネットワーク管理入門 実用的な管理をめざして”、Ｍ．Ｔ．ローズ：著／西田竹志：訳、（株）トッパン発行、１９９２年８月２０日初版」等に記載されている。
【０００４】
ＳＮＭＰ／ＭＩＢによるネットワークデバイス管理技術によれば、ネットワーク管理システムには少なくとも１つのネットワーク管理ステーション（ＮＭＳ）、それぞれがエージェントを含むいくつかの管理対象ノード（管理対象デバイス、以下、「デバイス」を「ノード」とも言う）、及び管理ステーションやエージェントが管理情報を交換するために使用するネットワーク管理プロトコルが含まれるため、ユーザは、ＮＭＳ上でネットワークデバイス管理用のソフトウェアを用いて管理対象ノード上のエージェントソフトウェアと通信することで、ネットワーク上のデータを取得することや、当該データの変更を行うことができる。
【０００５】
また、ネットワーク上のデバイスを管理する方法としては、上述のＳＮＭＰ／ＭＩＢによる方法の他に、例えば、大容量データのダウンロード／アップロードを行う場合、コネクション型のプロトコル（ＴＣＰ等）を用いたＦＴＰプロトコル等による方法がある。
【０００６】
ところで、上述したようなネットワークデバイス管理用のソフトウェアを分散環境（当該ソフトウェアを起動可能な端末装置が分散して設置された環境）で使用する場合、ネットワーク管理機能を有するサーバアプリケーション（サーバ側の端末装置で動作するアプリケーション）、及びそれぞれの端末装置で起動されるＧＵＩ部分である複数のクライアントアプリケーション（クライアント側の端末装置で動作するアプリケーション）による構成をとることが一般的である。
【０００７】
分散環境における異なる端末装置間で、クライアントアプリケーションとサーバアプリケーションはプロセス間通信を行うことになる。プロセス間通信を行う標準に関しては、ＲＦＣ（Ｒｅｑｕｅｓｔ  Ｆｏｒ  Ｃｏｍｍｅｎｔｓ）１０５７ＲＰＣ（Ｒｅｍｏｔｅ  Ｐｒｏｃｅｄｕｒｅ  Ｃａｌｌ）が定義されている。
【０００８】
ＲＰＣとは、ネットワークサービスを提供する関数群をサーバ側の端末装置（以下、単に「サーバ」とも言う）で用意し、その中の関数（以下、「ＲＰＣ関数」とも言う）をローカルマシン内の関数と同様に、ネットワーク上の別の端末装置（クライアント側の端末装置、以下、単に「クライアント」とも言う）のクライアントプロセスから呼び出せるようにした手法である。
ＲＰＣにおけるプロセス間通信の流れは以下のようになる。
【０００９】
先ず、クライアントは、サーバに対するサービス要求として、サーバに用意されているＲＰＣ関数を呼び出す。この時点で、ＲＰＣ関数の呼び出し情報を格納したデータパケットがサーバに対して送られ、クライアントで実行されているプログラムが中断される。
サーバは、クライアントからのデータパケットを受け取ると、当該データパケットにより示される、クライアントが呼び出したＲＰＣ関数をディスパッチし、当該ＲＰＣ関数の引数を取り出した後、当該引数に基いてサービスを実行し、当該実行結果をクライアントに対して返送する。
クライアントは、サーバからのサービス実行結果を受け取ると、プログラムの実行を再開する。
【００１０】
ネットワーク管理機能を有するサーバアプリケーションが起動されるサーバは、一般的に、ネットワーク（分散ネットワーク）上に１つ配置され、サーバアプリケーション内で複数のインスタンスを有することにより、ネットワーク上の複数のデバイスを管理するように構成されている。
一方、クライアントアプリケーションが起動されるクライアントは、複数の異なる端末装置として存在し、それぞれで動作し、上述したプロセス間通信によりサーバにアクセスすることで、ネットワーク上のデバイスに関する情報の取得や設定等が行えるように構成されている。
【００１１】
ところで、上述したようなネットワークシステムにおいて、例えば、イベント通知を使用してネットワーク上のプリンタのエラー状況を管理する場合、ＴＲＡＰ−ＰＤＵ（Ｐｒｏｔｏｃｏｌ  Ｄａｔａ  Ｕｎｉｔ）を使用したＳＮＭＰプロトコルにより、プリンタにおけるエラーに関する状態変化（エラー状況）がプリンタから通知される。
ＴＲＡＰ−ＰＤＵを使用したＳＮＭＰプロトコルでは、ＴＲＡＰ−ＰＤＵによるイベント通知のパケットを受信するために、ネットワーク管理ソフトウェアは、特定のポートをオープンしてパケットを受信できるようにしている。その他のプロトコルでは、イベント通知のパケット受信用のポートをプリンタに対して登録することで、イベント受信に対して任意のポートを使用することができるものもある。
【００１２】
【発明が解決しようとする課題】
しかしながら、上述したような従来のネットワークシステムでは、イベント通知を使用してネットワーク上のプリンタ等のデバイスのエラー状況を管理するために、例えば、ＴＲＡＰ−ＰＤＵ（Ｐｒｏｔｏｃｏｌ  Ｄａｔａ  Ｕｎｉｔ）を使用したＳＮＭＰプロトコルにより、ネットワーク管理ソフトウェアで特定のポートをオープンしてパケット受信する構成とした場合、既に他のアプリケーションによって特定のポートがオープンされているときにはイベント通知のためのパケット受信ができない、という問題があった。
【００１３】
また、例えば、デバイスに対してイベント通知の受信用のポートを登録するプロトコルを使用する構成とした場合、複数のネットワーク管理ソフトウェアが動作しており、これらのネットワーク管理ソフトウェアによりデバイスに対してポート登録がなされると、デバイスは、ポート登録された全てのネットワーク管理ソフトウェアに対してイベント通知する必要があった。このため、例えば、デバイスがプリンタである場合、印刷開始通知や、状態通知、或いは終了通知等のイベント通知が頻繁に起きると、当該デバイスのパフォーマンスを劣化させてしまう、という問題があった。
【００１４】
そこで、本発明は、上記の欠点を除去するために成されたもので、デバイスからのイベント通知を一括して扱うことが可能であり、イベント通知に関わるデバイスのパフォーマンスの劣化を防ぐことが可能な、情報処理装置、デバイス管理方法、及びそれを実施するためのプログラムを記憶したコンピュータ読取可能な記憶媒体を提供することを目的とする。
【００１５】
【課題を解決するための手段】
斯かる目的下において、第１の発明に係る情報処理装置は、デバイス及び端末装置と通信可能な情報処理装置であって、上記デバイスでのイベントを上記端末装置に通知するイベント通知の登録の要求を上記端末装置から受け付ける受付手段と、上記受付手段により受け付けた登録の要求に従って、上記端末装置をイベント通知の通知先として登録する登録手段と、上記デバイスでのイベントを上記情報処理装置に通知するイベント通知の登録を上記デバイスに要求する要求手段と、上記デバイスから、上記デバイスでのイベントに関するイベント通知情報を受信する受信手段と、上記端末装置がイベント通知の通知先として上記登録手段によって登録されている場合、上記受信手段により受信されたイベント通知情報を、上記端末装置に配信する配信手段と、上記デバイスでのイベントを上記端末装置に通知するイベント通知の登録を削除する要求を上記端末装置から受け付ける第２の受付手段と、上記第２の受付手段により受け付けた登録を削除する要求に従って、上記端末装置をイベント通知の通知先から削除する削除手段と、上記削除手段により上記端末装置がイベント通知の通知先から削除された結果、登録されているイベント通知の通知先がなくなった場合に、上記デバイスでのイベントを上記情報処理装置に通知するイベント通知の登録を削除することを上記デバイスに要求する削除要求手段と、を有することを特徴とする。
【００１６】
第２の発明に係る情報処理装置は、上記第１の発明において、上記デバイスからイベント通知を受けるためのポートを確立する確立手段と、上記確立手段によりポートが確立された場合、ポートが確立された装置を管理する管理部に、ポートが確立された旨を通知する通知手段と、を有することを特徴とする。
【００１７】
第３の発明は、上記第２の発明において、上記通知手段は、上記確立手段によりポートが確立されなかった場合、上記管理部に、ポートが確立されなかった旨を通知することを特徴とする。
【００１８】
第４の発明に係る情報処理装置は、上記第２又は第３の発明において、上記管理部は、上記端末装置からの要求に応じて、上記デバイスでのイベントを上記端末装置に通知するイベント通知の登録の要求先を識別する情報を上記端末装置に送信することを特徴とする。
【００１９】
第５の発明に係る情報処理装置は、上記第２乃至第４の発明のいずれかにおいて、上記受信手段は、上記確立手段により確立されたポートを介して、上記デバイスから上記イベント通知情報を受信することを特徴とする。
【００２０】
第６の発明に係る情報処理装置は、上記第１乃至第５の発明のいずれかにおいて、上記受付手段により受け付けた登録の要求に従って、上記デバイスでのイベントを上記情報処理装置に通知するイベント通知の登録が上記デバイスになされているか否かを判別する判別手段を有し、上記要求手段は、イベント通知の登録が上記デバイスになされていないと判別された場合に、イベント通知の登録を上記デバイスに要求することを特徴とする。
【００２１】
第７の発明に係る情報処理装置は、上記第１乃至第６の発明のいずれかにおいて、複数の端末装置が上記登録手段によりイベント通知の通知先として登録されている場合、上記配信手段は、上記複数の端末装置のそれぞれに上記イベント通知情報を配信することを特徴とする。
【００２４】
第８の発明に係るデバイス管理方法は、デバイスを管理するデバイス管理方法であって、情報処理装置において、上記デバイスでのイベントを端末装置に通知するイベント通知の登録の要求を上記端末装置から受け付ける受付ステップと、上記情報処理装置において、上記受付ステップで受け付けた登録の要求に従って、上記端末装置をイベント通知の通知先として登録する登録ステップと、上記情報処理装置において、上記デバイスでのイベントを上記情報処理装置に通知するイベント通知の登録を上記デバイスに要求する要求ステップと、上記情報処理装置において、上記デバイスから、上記デバイスでのイベントに関するイベント通知情報を受信する受信ステップと、上記情報処理装置において、上記端末装置がイベント通知の通知先として上記登録ステップで登録されている場合、上記受信ステップで受信されたイベント通知情報を、上記端末装置に配信する配信ステップと、上記情報処理装置において、上記デバイスでのイベントを上記端末装置に通知するイベント通知の登録を削除する要求を上記端末装置から受け付ける第２の受付ステップと、上記情報処理装置において、上記第２の受付ステップで受け付けた登録を削除する要求に従って、上記端末装置をイベント通知の通知先から削除する削除ステップと、上記削除ステップにより上記端末装置がイベント通知の通知先から削除された結果、登録されているイベント通知の通知先がなくなった場合、上記情報処理装置において、上記デバイスでのイベントを上記情報処理装置に通知するイベント通知の登録を削除することを上記デバイスに要求する削除要求ステップと、を有することを特徴とする。
【００２５】
第９の発明に係るデバイス管理方法は、上記第８の発明において、上記デバイスからイベント通知を受けるためのポートを確立する確立ステップを有することを特徴とする。
【００２６】
第１０の発明に係るデバイス管理方法は、上記第９の発明において、上記確立ステップでポートが確立された場合、ポートが確立された装置を管理する管理部に、ポートが確立された旨を通知する第１の通知ステップと、上記確立ステップでポートが確立されなかった場合、上記管理部に、ポートが確立されなかった旨を通知する第２の通知ステップと、を有することを特徴とする。
【００２７】
第１１の発明に係るデバイス管理方法は、上記第１０の発明において、上記デバイスでのイベントを上記端末装置に通知するイベント通知の登録の要求先を識別する情報を上記管理部から取得する識別情報取得ステップを有することを特徴とする。
【００２８】
第１２の発明に係るデバイス管理方法は、上記第８乃至第１１の発明のいずれかにおいて、上記受信ステップでは、上記確立ステップで確立されたポートを介して、上記デバイスから上記イベント通知情報を受信することを特徴とする。
【００２９】
第１３の発明に係るデバイス管理方法は、上記第８乃至第１２の発明のいずれかにおいて、上記情報処理装置において、上記受付ステップ受け付けた登録の要求に従って、上記デバイスでのイベントを上記情報処理装置に通知するイベント通知の登録が上記デバイスになされているか否かを判別する判別ステップを有し、上記要求ステップは、イベント通知の登録が上記デバイスになされていないと判別された場合に、イベント通知の登録を上記デバイスに要求することを特徴とする。
【００３０】
第１４の発明に係るデバイス管理方法は、上記第８乃至第１３の発明のいずれかにおいて、上記情報処理装置において、上記登録ステップにより複数の端末装置がイベント通知の通知先として登録されている場合、上記配信ステップでは、上記複数の端末装置のそれぞれに上記イベント通知情報を配信することを特徴とする。
【００３３】
第１５の発明に係るデバイス管理方法は、上記第８乃至第１４の発明のいずれかにおいて、上記端末装置において、上記デバイスでのイベントをクライアントソフトウェアに通知するイベント通知の登録の要求を上記クライアントソフトウェアから受け付ける第３の受付ステップと、上記端末装置において、上記第３の受付ステップで受け付けた登録の要求に従って、上記クライアントソフトウェアをイベント通知の通知先として登録する第２の登録ステップと、上記端末装置において、上記デバイスでのイベントを上記端末装置に通知するイベント通知の登録を上記情報処理装置に要求する第２の要求ステップと、上記端末装置において、上記情報処理装置から、上記イベント通知情報を受信する第２の受信ステップと、上記クライアントソフトウェアがイベント通知の通知先として上記第２の登録ステップで登録されている場合、上記端末装置において、上記第２の受信ステップで受信された上記イベント通知情報を、上記クライアントソフトウェアに配信する第３の配信ステップと、を有することを特徴とする。
【００３４】
第１６の発明に係るコンピュータ読取可能な記憶媒体は、上記第８乃至第１５の発明のいずれかのデバイス管理方法の各ステップをコンピュータに実行させるためのプログラムを記録したことを特徴とする。
【００４２】
【発明の実施の形態】
以下、本発明の実施の形態について図面を用いて説明する。
【００４３】
本発明は、例えば、図１に示すようなネットワークシステム１００に適用される。
以下、本実施の形態のネットワークシステム１００の構成及び動作について具体的に説明する。
【００４４】
＜ネットワークシステム１００の全体構成及び動作＞
ネットワークシステム１００は、分散ネットワーク環境のシステムであり、上記図１に示すように、ローカルエリアネットワーク（ＬＡＮ）１５０，１２０，１１０上に接続された各種のデバイスを含む構成としている。
【００４５】
ＬＡＮ１５０には、パーソナルコンピュータ（以下、単に「ＰＣ」と言う）１０３，１２１と、プリンタ１０５が接続されたＰＣ１０４と、ネットワークディスク１０７が接続されたファイルサーバ１０６と、プリンタ１０９ａ，１０９ｂが接続されたプリントサーバ１０８と、ネットワークボード１０１を有するプリンタ１０２と、ＷＡＮを介したネットワーク１２０，１１０との接続のためのモデム（変調／復調）／トランスポンダー１３０ａとが接続されている。
ＬＡＮ１２０には、ＰＣ１２２と、モデム／トランスポンダー１３０ａと同様の構成を有するモデム／トランスポンダー１３０ｂが接続されたバックボーン１４０とが接続されている。
ＬＡＮ１１０には、ＰＣ１１１，１１２と、ネットワークディスク１１４が接続されたファイルサーバ１１３と、プリンタ１１６，１１７が接続されたプリントサーバ１１５８とが接続されている。
【００４６】
ここで、図２は、上記図１に示したネットワークシステム１００（上記図１参照）において、例えば、ＰＣ１０３，１０４，１２１及びプリンタ１０２に着目した場合の構成の一例を示したものである。
【００４７】
ＰＣ１０３では、クライアントアプリケーション１のプロセスＡが起動され、ＰＣ１０４では、クライアントアプリケーション２のプロセスＣが起動され、ＰＣ１２１では、サーバアプリケーションのプロセスＢが起動されるように構成されている。このような構成により、ＳＮＭＰエージェントが実装されているプリンタ１０２が管理される。
【００４８】
クライアントアプリケーション１及び２は、プロセス間通信の機能により、サーバアプリケーションとの通信を行い、サーバアプリケーションは、ＳＮＭＰプロトコル等により、デバイスとしてのプリンタ１０２との通信を行う。
【００４９】
例えば、クライアントアプリケーション１が起動されるＰＣ１０３がプリンタ１０２の情報（デバイス情報）を取得する場合、ＰＣ１０３において、クライアントアプリケーション１は、プロキシを用いたプロセス間通信を行うことで、サーバアプリケーションが起動されるＰＣ１２１に対して、情報取得したいデバイス（ここでは、プリンタ１０２）を示す情報を送信する。
ＰＣ１２１において、サーバアプリケーションは、スタブによりクライアントアプリケーション１から送信されてきた情報を受信し、当該受信情報によりデバイス情報を取得すべきデバイス（プリンタ１０２）を認識し、ＳＮＭＰプロトコル等によりプリンタ１０２のデバイス情報を取得し、当該取得情報を、プロセス間通信によりプロキシを介してクライアントアプリケーション１が起動されるＰＣ１０３に対して返送（コールバック通知）する。
この通知を受けたＰＣ１０３において、クライアントアプリケーション１は、当該通知情報に基づいてビットマップ表示等を行うことで、ＰＣ１０３のユーザに対してデバイス情報を表示する。
【００５０】
また、例えば、クライアントアプリケーション１が起動されるＰＣ１０３がプリンタ１０２に対して情報設定する場合、ＰＣ１０３において、クライアントアプリケーション１は、プロキシを用いたプロセス間通信により、サーバアプリケーションが起動されるＰＣ１２１に対して設定希望する情報（デバイス情報）を送信する。
ＰＣ１２１において、サーバアプリケーションは、スタブによりクライアントアプリケーション１から送信されてきた情報を受信し、当該受信情報により示される情報設定対象のデバイス（プリンタ１０２）に対して、ＳＮＭＰプロトコル等によりデバイスに情報を設定し、当該設定が成功したか或いは失敗したかを示す情報を、スタブからプロセス間通信によりプロキシを介してクライアントアプリケーション１が起動されるＰＣ１０３に対してコールバック通知する。
ＰＣ１０３において、クライアントアプリケーション１は、サーバアプリケーションからのコールバック通知情報に基いてビットマップ表示等を行うことで、ＰＣ１０３のユーザに対してデバイスへの設定情報を表示する。
【００５１】
図３は、上記図１に示したネットワークシステム１００（上記図１参照）において、例えば、イベント通知を使用してＬＡＮ１５０，１２０，１１０上のプリンタ等のデバイスのエラー状況を管理する場合の動作をフローチャートによって示したものである。
【００５２】
まず、プリンタ等の管理対象となるデバイスから能動的に状態変化情報を通知（イベント通知）する場合、例えば、ＳＮＭＰプロトコルでは一般に、ＴＲＡＰ−ＰＤＵが使用される。このため、ＳＮＭＰプロトコルでは、ＴＲＡＰ−ＰＤＵを受信するために、ネットワーク管理ソフトウェアにより特定のポートをオープンしイベント通知を受信できるようになされている。したがって、ここでは、デバイスからエラーに関する状態変化が通知（エラー情報のイベント通知）される場合、ＴＲＡＰ−ＰＤＵが使用される。
【００５３】
尚、ＴＲＡＰ−ＰＤＵについての詳細な説明は、例えば、「Marshall T. Rose, The Simple Book, Prentice-Hall, 1991 」等に記載されている。
【００５４】
また、上記図３を用いた以下の説明では、その説明の簡単のため、管理対象のデバイスをプリンタ１０２とし、これをネットワーク管理ソフトウェアの起動により管理しているＰＣをＰＣ１０３とする。
【００５５】
そこで、上記図３に示すように、先ず、ＰＣ１０３は、プリンタ１０２からのＴＲＡＰ−ＰＤＵによるイベント通知を受信し（ステップＳ９０１）、この受信情報からエラー情報を取得する（ステップＳ９０２）。そして、ＰＣ１０３は、自端末装置に接続されているＣＲＴ等のディスプレイ上に対して、ステップＳ５０２で取得したエラー情報を、文字又は図等により表示する（ステップＳ９０３）。
このようにして、ＰＣ１０３で動作するネットワーク管理ソフトウェアにより、プリンタ１０２でのエラー情報がユーザに対して通知される。
【００５６】
尚。本実施の形態では、イベント通知によるプリンタ等のデバイスの状態監視に使用されるプロトコルを、ＳＮＭＰプロトコルとしているが、これに限るものではない。例えば、デバイスに対してイベント通知のパケットを送受信するためのポートを登録することで、イベント通知の受信に任意のポートを使用することができるプロトコル等を適用可能である。
【００５７】
＜ネットワークシステム１００の特徴とする構成及び動作＞
ネットワークシステム１００は、ネットワークデバイス管理機能を有するものであり、当該ネットワークデバイス管理機能は、特に、分散ネットワーク環境にあるネットワークシステム１００に存在する端末装置で並行動作し、上記図１に示したＰＣやプリンタ等のデバイスからのネットワーク管理ソフトウェアによるイベント通知を一括して受信して処理する構成、及びイベント通知のためのポートをオープンする際に、他のアプリケーションにより既にオープンされた状態の場合には当該他のアプリケーションを利用してイベント通知を受信可能とする構成により、他のアプリケーションによるイベント通知のバッティングを防ぎ、イベント通知の送信にかかわるデバイスのパフォーマンスの劣化を防ぐことが可能なように構成されている。
【００５８】
図４は、上記ネットワークデバイス管理機能が設けられるＰＣ２００（以下、「ネットワーク管理装置２００」とも言う）の構成を示したものである。
ネットワーク管理装置２００は、上記図４に示すように、ＣＰＵ２０１と、ＲＯＭ２０２と、ＲＡＭ２０３と、キーボード（ＫＢ）２０９のキーボードコントローラ（ＫＢＣ）２０５と、表示部としてのＣＲＴディスプレイ（ＣＲＴ）２１０のＣＲＴコントローラ（ＣＲＴＣ）２０６と、ハードディスク（ＨＤ）２１１及びフレキシブルディスク（ＦＤ）２１２のディスクコントローラ（ＤＫＣ）２０７と、上記図１に示したＬＡＮ１５０，１２０，１１０に相当するネットワーク２５０との接続のためのネットワークインターフェースコントローラ（ＮＩＣ）２０８とが、システムバス２０４を介して互いに通信可能に接続された構成としている。
【００５９】
ＣＰＵ２０１は、ＲＯＭ２０２或いはＨＤ２１１に記憶されたソフトウェア、或いはＦＤ２１２より供給されるソフトウェアを実行することで、システムバス２０４に接続された各構成部を総括的に制御する。
すなわち、ＣＰＵ２０１は、所定の処理シーケンスに従った処理プログラムを、ＲＯＭ２０２、或いはＨＤ２１１、或いはＦＤ２１２から読み出して実行することで、本実施の形態での動作を実現するための制御を行う。
【００６０】
ＲＡＭ２０３は、ＣＰＵ２０１の主メモリ或いはワークエリア等として機能する。
ＫＢＣ２０５は、ＫＢ２０９や図示していないポインティングデバイス等からの指示入力を制御する。
ＣＲＴＣ２０６は、ＣＲＴ２１０の表示を制御する。
ＤＫＣ２０７は、ブートプログラム、種々のアプリケーション、編集ファイル、ユーザファイル、ネットワーク管理プログラム、及び本実施の形態における所定の処理プログラム等を記憶するＨＤ２１１及びＦＤ２１２とのアクセスを制御する。
ＮＩＣ２０８は、ネットワーク２５０上の装置或いはシステムと双方向にデータをやりとりする。
【００６１】
尚、本実施の形態では、例えば、ハードディスク（ＨＤ）２１１に対して、後述する全ての説明で動作主体となる本実施の形態に係るネットワークデバイス管理のためのソフトウェアのプログラムが格納される。また、後述の全ての説明において、特に断りのない限り、実行の主体はハード上ではＣＰＵ２０１である。一方、ソフトウェア上の制御の主体はハードディスク（ＨＤ）２１１に格納されたネットワーク管理ソフトウェアである。
また、本実施の形態では、オペレーションシステム（ＯＳ）として、マイクロソフト社のウィンドウズ（Ｒ）９８等を想定しているが、これに限られるものではない。
また、本実施の形態におけるネットワークデバイス管理プログラムは、例えば、ＦＤ２１２やＣＤ−ＲＯＭ等の記憶媒体に格納された形態で供給されるように構成してもよい。この場合、ＦＤコントローラ（ＦＤ）としてのＤＫＣ２０７により、或いは不図示のＣＤ−ＲＯＭドライブ等により当該記憶媒体からネットワーク管理プログラムが読み出され、ハードディスク（ＨＤ）２１１上にインストールされる。
【００６２】
図５は、ネットワーク管理するためのソフトウェアコンポーネントの構成を示す図である。
全てのソフトウェアコンポーネント３０８，３０９，３１０，３０３，３０５，３０７，３１１，３１２は、上記図１に示したＰＣやサーバ等でそれぞれ起動され、ＣＳＢと呼ばれる論理的なソフトウェアバス３０１上に接続されている。
【００６３】
ＣＳＢ−ＬＭ（３０２）は、ＣＳＢ（３０１）に接続されているそれぞれのソフトウェアコンポーネント間のメッセージ配信機能を提供する。
【００６４】
ＶＤＣ１（３０３）は、分散ネットワーク環境に存在する端末装置上で並行動作が可能であり、デバイス１（３０４）を管理するサーバソフトウェアコンポーネントである。また、ＶＤＣ２（３０５）も同様に、分散ネットワーク環境に存在する端末装置上で並行動作が可能であり、デバイス２（３０６）を管理するサーバソフトウェアコンポーネントである。デバイス１（３０４）及びデバイス２（３０６）はそれぞれ、上記図１に示したプリンタ等に相当する。
すなわち、本実施の形態では、デバイス１（３０４）については、これに対応するＶＤＣ１（３０３）が起動され、デバイス２（３０６）については、これに対応するＶＤＣ２（３０５）が起動される構成としており、これにより、デバイス毎に独立してデータを扱い負荷分散が可能となる。
【００６５】
ＶＤＣ−Ａｇｅｎｔ（３０７）は、ＶＤＣ１（３０３）及びＶＤＣ２（３０５）のプロセスが動作している端末装置（上記図１に示したＰＣ等に相当）のアドレス、ＶＤＣ１（３０３）及びＶＤＣ２（３０５）のインタフェースポインタ、及びＶＤＣ１（３０３）及びＶＤＣ２（３０５）が管理しているデバイスの基本情報（デバイス名やアドレス等の情報）を管理するソフトウェアコンポーネントである。
Ｄｉｓｃｏｖｅｒｙ−ＦＳＡ（３０８）は、デバイスを探索するソフトウェアコンポーネントである。
クライアントソフトウェア１（３０９），２（３１０）は、上述の各種のソフトウェアコンポーネントを利用するためのソフトウェアである。
【００６６】
イベントマネージャー（３１１）は、デバイス３０４，３０６から通知されるイベントを受信してクライアントソフトウェア１（３０９），２（３１０）に配信するソフトウェアコンポーネントである。
管理コンソール３１２は、上述の各種のソフトウェアコンポーネントを管理するためのソフトウェアコンポーネントである。
【００６８】
例えば、クライアントソフトウェア１（３０９）が搭載されたＰＣが、デバイス１（３０４）の情報を取得したい場合、先ず、当該ＰＣは、クライアントソフトウェア１（３０９）により、ＣＳＢ−ＬＭ（３０２）に対して、論理的なバスであるＣＳＢ３０１を介してＣＳＢメッセージを送信することで、Ｄｉｓｃｏｖｅｒｙ−ＦＳＡ（３０８）のクラスＩＤ、及びこれが動作している端末装置のアドレスを取得する。
そして、当該ＰＣは、クライアントソフトウェア１（３０９）により、上記の取得情報に基いて、Ｄｉｓｃｏｖｅｒｙ−ＦＳＡ（３０８）のインタフェースポインタを取得することでＤｉｓｃｏｖｅｒｙ−ＦＳＡ（３０８）にアクセスし、デバイス１（３０４）のデバイス基本情報（デバイス名やアドレス等の情報）を取得する。
【００６９】
次に、クライアントソフトウェア１（３０９）が搭載されたＰＣは再び、ＣＳ−ＢＬＭ（３０２）に対して、論理的なバスであるＣＳＢ３０１を介して、ＣＳＢメッセージを送信することで、Ｄｉｓｃｏｖｅｒｙ−ＦＳＡ（３０８）のクラスID及びこれが動作している端末装置のアドレスを取得する。
そして、当該ＰＣは、クライアントソフトウェア１（３０９）により、上記の取得情報に基いて、Ｄｉｓｃｏｖｅｒｙ−ＦＳＡ（３０８）のインタフェースポインタを取得することでＤｉｓｃｏｖｅｒｙ−ＦＳＡ（３０８）にアクセスし、デバイス１（３０４）のデバイス基本情報を用いて、Ｄｉｓｃｏｖｅｒｙ−ＦＳＡ（３０８）から、デバイス１（３０４）を管理しているＶＤＣ１（３０３）インタフェースポインタを取得することで、ＶＤＣ１（３０３）からデバイス１（３０４）の情報を取得する。
【００７０】
図６は、上記図５に示した各種のソフトウェアコンポーネントの中の任意のソフトウェアコンポーネント（ここでは説明の簡単のため、クライアントソフトウェア１（３０９）とし、以下、「ノード３０９」と言う）と、同図に示したＣＳＢ−ＬＭ（３０２）との間の動作を示したものである。
【００７１】
先ず、ノード３０９は、起動を示すＣＳＢメッセージをＣＳＢ−ＬＭ（３０２）に対して送信する。ＣＳＢ−ＬＭ（３０２）は、管理しているノードリストに対して、新たに起動されたノード３０９が動作している端末装置（上記図１に示したＰＣ等に相当）のアドレス及びノードのクラスＩＤを追加する（ステップＳ４０１）。
次に、ノード３０９は、必要に応じてアクセスしたい他のノードの情報をＣＳＢ−ＬＭ（３０２）から取得するために、ＣＳＢ−ＬＭ（３０２）に対してＣＳＢ−Ｌｏｏｋ−Ｕｐメッセージを送信する（ステップＳ４０２）。
これを受けたＣＳＢ−ＬＭ３０２は、ノード３０９が必要としているノード情報を通知する（ステップＳ４０２−１）。
そして、ノード３０９は、起動終了する前に、ＣＳＢ−ＬＭ（３０２）に対して、自ノードが終了したことを示すＣＳＢメッセージを送信する（ステップＳ４０３）。
【００７２】
図７は、上記図５に示したような各種のソフトウェアコンポーネントの配置構成を有するネットワークシステム１００において、デバイスからイベント通知を受信する場合の動作を示したものである。
以下の説明では、その説明の簡単のため、デバイス３０４がＶＤＣ１（３０３）を介してイベント通知を行い、当該イベント通知を、クライアントソフトウェア１（３０９）が動作しているＰＣに対して配信するものとする。
【００７３】
先ず、管理コンソール（３１２）は、イベントマネージャー（Event Mgr）（３１１）を起動する（ステップＳ４１１）。
イベントマネージャー（３１１）は、ＳＮＭＰプロトコルにおけるＴＲＡＰポート等のイベント通知受信用のポート（以下、単に「イベントポート」とも言う）をオープンする等の初期化処理を実行し、ＣＳＢ−ＬＭ（３０２）に対して、起動による初期化処理が終了（起動正常終了）したことを示すＣＳＢメッセージを送信する（ステップＳ４１１−１）。
【００７４】
次に、クライアントソフトウェア１（３０９）は、管理対象のデバイス（ここではデバイス３０４）を扱っているＶＤＣ（ここではＶＤＣ１（３０３））を起動する（ステップＳ４１２）。
ＶＤＣ１（３０３）は、ＣＳＢ−ＬＭ（３０２）に対して、イベントマネージャー（３１１）のＣＬＳ−ＩＤの取得を依頼し（ステップＳ４１２−１）、当該依頼に対してＣＳＢ−ＬＭ（３０２）から返信されてきたＣＬＳ−ＩＤを用いて（ステップＳ４１２−２）、イベントマネージャー（３１１）のインターフェースポインタを取得する（ステップＳ４１２−３）。
【００７５】
次に、クライアントソフトウェア１（３０９）は、デバイス３０４からのイベント通知を受信するために、ＶＤＣ１（３０３）に対してイベント登録を行う（ステップＳ４１３）。
ＶＤＣ１（３０３）は、イベントマネージャー（３１１）に対してイベント登録を行う（ステップＳ４１３−１）。
イベントマネージャー（３１１）は、デバイス３０４に対してイベント登録を行う（ステップＳ４１３−２）。
【００７６】
そこで、デバイス３０４において、エラー、或いは、印刷が始まる等の状態変化が発生した場合、デバイス３０４は、イベント通知する（ステップＳ４１４）。
イベントマネージャー（３１１）は、デバイス３０４からのイベント通知を受けると、このイベント通知情報を含むＣＳＢメッセージを、イベント登録がなされたＶＤＣ１（３０３）に対して送信する（ステップＳ４１４−１）。
ＶＤＣ１（３０３）は、イベントマネージャー（３１１）からのＣＳＢメッセージを受信すると、イベント登録を行ったクライアントソフトウェア１（３０９）に対してコールバック通知する（ステップＳ４１４−２）。
【００７７】
クライアントソフトウェア１（３０９）は、ＶＤＣ１（３０３）からのデバイス３０４が出力したイベント情報を含むコールバック通知を受け取る。  クライアントソフトウェア１（３０９）はイベント通知の必要がなくなると、ＶＤＣ１（３０３）に対してイベント登録解除を行う（ステップＳ４１５）。
ＶＤＣ１（３０３）は、イベントマネージャー（３１１）に対してイベント登録解除を行う（ステップＳ４１５−１）。
イベントマネージャー（３１１）は、デバイス３０４に対してイベント登録解除を示す情報送信する（ステップＳ４１５−２）。
【００７８】
そして最後に、管理コンソール（３１２）は、イベントマネージャー（３１１）の起動を終了させる（ステップＳ４１６）。
イベントマネージャー（３１１）は、イベントポートをクローズする等の終了処理を実行し、その終了通知を示すＣＳＢメッセージをＣＳＢ−ＬＭ（３０２）に対して送信する。
その後、本アプリケーション終了となる。
【００７９】
図８は、上記図６に示した動作におけるクライアントソフトウェア１（３０９）の処理（イベント登録／削除処理）を具体的に示したものである。
【００８０】
ステップＳ４２１：
クライアントソフトウェア１（３０９）は、管理対象のデバイス３０４のＶＤＣ１（３０３）に対してイベント登録を行う。
ここでのイベント登録する情報としては、例えば、クライアントソフトウェア１（３０９）のアドレス、クライアントソフトウェア１（３０９）を一意に識別する識別子(ＧＵＩＤ)、イベント通知の種類を示すイベント種別、及び各イベント種別の属性情報を示すイベントプロパティ等が挙げられる。また、イベント種別としては、例えば、デバイスイベントやジョブイベント等が挙げられる。また、イベントプロパティとしては、例えば、ジョブイベントの属性であるジョブオーナー、ジョブ名、及びジョブ状態等が挙げられる。
【００８１】
ステップＳ４２２：
クライアントソフトウェア１（３０９）は、ＶＤＣ１（３０３）からのイベントコールバック通知（デバイス３０４のイベント通知に対応する通知）の受信処理を実行する。
具体的には例えば、図９に示すように、クライアントソフトウェア１（３０９）は、ＶＤＣ１（３０３）からのイベントコールバック通知の受信し（ステップＳ４３１）、当該通知情報に基づいて、自端末装置の表示を更新する（ステップＳ４３２）。
図１０は、ステップＳ４３２において、例えば、ＣＲＴ２１０に表示される画面の一例を示したものである。
【００８２】
ステップＳ４２３：
クライアントソフトウェア１（３０９）は、ステップＳ４２２での処理終了後、デバイス３０４のＶＤＣ１（３０３）に対してイベント解除を行いう。
その後、本処理終了となる。
【００８３】
図１１は、上記図６に示した動作におけるＶＤＣ１（３０３）の処理（イベント登録処理）を具体的に示したものである。
【００８４】
ステップＳ５０１、ステップＳ５０２：
ＶＤＣ１（３０３）は、クライアントソフトウェア１（３０９）からのイベント登録（依頼）を受けると（ステップＳ５０１）、イベントマネージャー（３１１）のインタフェースポインタを既に取得しているか否かを判別する（ステップＳ５０２）。
この判別の結果、イベントマネージャー（３１１）のインタフェースポインタを既に取得している場合にはステップＳ５０５に進み、イベントマネージャー（３１１）のインタフェースポインタを取得していない場合にはステップＳ５０３に進む。
【００８５】
ステップＳ５０３、ステップＳ５０４：
ステップＳ５０２の判別の結果、イベントマネージャー（３１１）のインタフェースポインタを取得していない場合、ＶＤＣ１（３０３）は、ＣＳＢ−ＬＭ（３０２）に対して、イベントマネージャー（３１１）のノード情報を問い合わせる（ステップＳ５０３）。
これにより、ＶＤＣ１（３０３）は、ＣＳＢ−ＬＭ（３０２）から、イベントポートオープンに成功しているイベントマネージャー（３１１）のノード情報を取得することになるため（ステップＳ５０４）、デバイス３０４からイベント通知を受信できることが保証される。また、ＶＤＣ１（３０３）が動作している端末装置において、他のアプリケーションによりイベントポートがオープンされている場合であっても、他の端末装置で動作しているイベントマネージャーを使用して、イベント通知の受信が可能になる。
【００８６】
ステップＳ５０５：
ステップＳ５０４の処理後、又はステップＳ５０２でイベントマネージャー（３１１）のインタフェースポインタを既に取得していると判別された場合、ＶＤＣ１（３０３）は、クライアントソフトウェア１（３０９）がイベント通知を受信したいデバイス（ここではデバイス３０４）が既にイベントマネージャー（３１１）に対して登録済みであるか否かを確認する。
この確認の結果、デバイス３０４が既にイベントマネージャー（３１１）に対して登録済みである場合にはステップＳ５０７に進み、デバイス３０４がイベントマネージャー（３１１）に対して未登録である場合にはステップＳ５０６に進む。
【００８７】
ステップＳ５０６：
ステップＳ５０５の確認の結果、デバイス３０４がイベントマネージャー（３１１）に対して未登録である場合、ＶＤＣ１（３０３）は、イベントマネージャー（３１１）に対してデバイス３０４のイベント登録を依頼する。
その後、ステップＳ５０９に進む。
【００８８】
ステップＳ５０７：
ステップＳ５０５の確認の結果、デバイス３０４がイベントマネージャー（３１１）に対して既に登録済みである場合、ＶＤＣ１（３０３）は、クライアントソフトウェア１（３０９）が管理対象とするデバイス（ここではデバイス３０４）に対して異なるイベント登録を要求しているか否かを確認する。ここでの「異なるイベント登録」とは、例えば、イベント種別及びイベントプロパティの何れかが現在の登録済みの内容と比較して追加登録される登録等を意味する。
この確認の結果、異なるイベント登録を要求している場合にはステップＳ５０８に進み、そうでない場合にはステップＳ５０９に進む。
【００８９】
ステップＳ５０８：
ステップＳ５０７の確認の結果、異なるイベント登録を要求している場合、ＶＤＣ１（３０３）は、イベントマネージャー（３１１）に対して当該イベント登録を追加登録する。
【００９０】
ステップＳ５０９：
ステップＳ５０８の処理後、又はステップＳ５０６の処理後、又はステップＳ５０７で異なるイベント登録を要求していないことが確認された場合、ＶＤＣ１（３０３）は、クライアントソフトウェア１（３０９）をイベント通知リストに追加登録する。
その後、本処理終了となる。
【００９１】
上述のように、ＶＤＣ１（３０３）が、同一デバイス３０４に対するクライアントソフトウェア１（３０９）のイベント通知の登録をマージするように構成したので、デバイス３０４がイベント通知する先であるクライアントソフトウェア１（３０９）に対する送信情報量を削減することができる。これにより、イベント通知の送信を行うことで発生するデバイス３０４のパフォーマンスの劣化を防ぐことができる。
また、例えば、クライアントソフトウェア１（３０９）が、イベントマネージャー（３１１）と同一の端末装置で動作しているクライアントソフトウェアである場合、イベント通知の際に、クライアントソフトウェア１（３０９）とＶＤＣ１（３０３）間のプロセス間通信しか発生しないので、ネットワークトラフィックを発生させることがない。
【００９２】
図１２は、上記図６に示した動作におけるＶＤＣ１（３０３）の処理（イベント登録削除処理）を具体的に示したものである。
【００９３】
ステップＳ５１１、ステップＳ５１２：
ＶＤＣ１（３０３）は、クライアントソフトウェア１（３０９）からのイベント登録削除（解除）を受けると（ステップＳ５１１）、上記図１１に示したイベント登録処理でイベント通知リストに登録したクライアントソフトウェア１（３０９）を削除する（ステップＳ５１２）。
【００９４】
ステップＳ５１３：
ＶＤＣ１（３０３）は、ステップＳ５１２でイベント通知リストから削除したクライアントソフトウェア１（３０９）の管理対象デバイス（ここではデバイス３０４）に対してイベント通知を行うクライアントソフトウェアが存在するか否かを判別する。
この判別の結果、該当するクライアントソフトウェアが存在する場合にはそのまま本処理終了とし、該当するクライアントソフトウェアが存在しない場合のみ次のステップＳ５１４に進む。
【００９５】
ステップＳ５１４：
ステップＳ５１３の判別の結果、ステップＳ５１２でイベント通知リストから削除したクライアントソフトウェア１（３０９）の管理対象デバイス（デバイス３０４）に対してイベント通知を行うクライアントソフトウェアが存在しない場合、ＶＤＣ１（３０３）は、イベントマネージャー（３１１）に対してイベント登録削除の依頼を行う。
その後、本処理終了となる。
【００９６】
図１３は、上記図６に示した動作におけるＶＤＣ１（３０３）の処理（イベント配信処理）を具体的に示したものである。
【００９７】
ステップＳ５２１：
ＶＤＣ１（３０３）は、イベントマネージャー（３１１）から送信されてきたＣＳＢメッセージ（デバイス３０４のイベント通知を含むメッセージ）を受信する。
ステップＳ５２２：
ＶＤＣ１（３０３）は、内部カウンタに対して、デバイス３０４のイベント通知を所望しているクライアントソフトウェアの数を設定する。ここでの設定値は、上述したイベント通知リストにより取得できる。
【００９８】
ステップＳ５２３：
ＶＤＣ１（３０３）は、内部カウンタの値が“０”であるか否かを判別し、内部カウンタの値が“０”となるまで、次のステップＳ５２４からの処理を繰り返し実行する。内部カウンタの値が“０”となったときに、本処理終了となる。
【００９９】
ステップＳ５２４：
ＶＤＣ１（３０３）は、内部カウンタの値で示されるクライアントソフトウェアをイベント通知リストから認識し、当該クライアントソフトウェアに対して、ステップＳ５２１で受信したＣＳＢメッセージをコールバック通知する。
ステップＳ５２５：
ＶＤＣ１（３０３）は、内部カウンタの値をデクリメントし、再びステップＳ５２３へ戻る。
【０１００】
図１４は、上記図６に示した動作におけるイベントマネージャー（３１１）の処理（イベントポートのオープン／クローズ処理）を具体的に示したものである。
【０１０１】
ステップＳ６０１、ステップＳ６０２：
イベントマネージャー（３１１）は、デバイス３０４からのイベント通知を受信するためにイベントポートをオープンし（ステップＳ６０１）、このイベントポートのオープンに成功したか否かを判別する（ステップＳ６０２）。
この判別の結果、イベントポートのオープンに失敗した場合にはステップＳ６０３に進み、イベントポートのオープンに成功した場合にはステップＳ６０４に進む。
【０１０２】
ステップＳ６０３：
ステップＳ６０２の判別の結果、イベントポートのオープンに失敗した場合、イベントマネージャー（３１１）は、起動失敗を示すＣＳＢメッセージをＣＳＢ−ＬＭ３０２に対して送信する。
その後、本処理終了となる。
【０１０３】
ステップＳ６０４：
ステップＳ６０２の判別の結果、イベントポートのオープンに成功した場合、イベントマネージャー（３１１）は、起動成功（起動正常終了）を示すＣＳＢメッセージをＣＳＢ−ＬＭ３０２に対して送信する。
このとき、ＣＳＢ−ＬＭ３０２は、イベントポートのオープンに成功したイベントマネージャー（ここではイベントマネージャ（３１１））のノード情報を管理しているので、ＣＳＢ−ＬＭ３０２からイベントマネージャーのノード情報を取得したＶＤＣ１（３０３）は、必ずイベントマネージャー経由でイベント通知を受けられることが保証される。
【０１０４】
ステップＳ６０５：
イベントマネージャー（３１１）は、詳細は後述するが、ＶＤＣ１（３０３）からのイベント登録及びイベント登録削除、及びデバイス３０４から受信したイベント通知の配信を行う。
【０１０５】
ステップＳ６０６、ステップＳ６０７：
イベントマネージャー（３１１）は、イベントポートをクローズし（ステップＳ６０６）、本アプリケーションの終了を示すＣＳＢメッセージをＣＳＢ−ＬＭ（３０２）に対して送信する。
【０１０６】
図１５は、上記図１４に示したステップＳ６０５の処理において、イベント登録処理を具体的に示したものである。
先ず、ＶＤＣ１（３０３）からのイベント登録を受けると（ステップＳ６１１）、当該イベント登録を行うデバイス（ここではデバイス３０４）が既にイベント登録済みのデバイスであるか否かを判別する（ステップＳ６１２）。
ステップＳ６１２の判別の結果、デバイス３０４がイベント未登録の場合、デバイス３０４に対してイベント登録を行い（ステップＳ６１３）、後述するステップＳ６１６に進む。
一方、デバイス３０４が既にイベント登録済みである場合、今回のイベント登録の要求（依頼）の内容が現在登録済みのイベント登録と異な内容（イベント種別やイベントプロパティの追加等）であるか否かを判別し（ステップＳ６１４）、この判別の結果、異なる場合にのみ、デバイス３０４に対して当該イベント登録を追加する（ステップＳ６１５）。
ステップＳ６１５又はステップＳ６１３の処理後、又はステップＳ６１４で異なるイベント登録でないと判別された場合、ＶＤＣ１（３０３）をイベント通知リストに追加登録する（ステップＳ６１６）。
その後、本処理終了となる。
【０１０７】
図１６は、上記図１４に示したステップＳ６０５の処理において、デバイス３０４からのイベント通知配信処理を具体的に示したものである。
先ず、デバイス３０４からイベント通知を受信すると（ステップＳ６２１）、当該イベント通知を配信すべきＶＤＣの数を上述したイベント通知リストから取得して内部カウンタに設定する（ステップＳ６２２）。そして、内部カウンタの値が“０”となるまで（ステップＳ６２３）、次のステップＳ６２４からの処理を繰り返し実行する。
すなわち、ステップＳ６２１で受信したイベント通知情報を含むＣＳＢメッセージを、現在の内部カウンタの値により示されるＶＤＣに対して配信する（ステップＳ６２４）。そして、内部カウンタの値をデクリメントし、再びステップＳ６２３に戻る。
【０１０８】
上述のように、イベントマネージャー（３１１）が一括して、デバイス３０４からのイベント通知の受信を行い、当該イベント通知を配信すべき複数のＶＤＣに対して、当該イベント通知を含むＣＳＢメッセージを配信するように構成したので、デバイス３０４は、イベント通知を希望しているクライアントソフトウェアのそれぞれに対して個別にイベント通知を送信する必要がなくなり、この結果、イベント通知の送信にかかわるパフォーマンスの劣化を防ぐことが可能となる。
【０１０９】
図１７は、上記図１４に示したステップＳ６０５の処理において、イベント登録削除処理を具体的に示したものである。
先ず、ＶＤＣ１（３０３）からイベント登録削除の依頼を受けると（ステップＳ６３１）、ＶＤＣ１（３０３）をイベント通知リストから削除する（ステップＳ６３２）。
次に、ＶＤＣ１（３０３）がイベント登録していたデバイス（ここではデバイス３０４）に対して、他にイベント登録しているＶＤＣが存在するか否かを判別する（ステップＳ６３３）。
ステップＳ６３３の判別の結果、デバイス３０４に対してイベント登録している他のＶＤＣが存在する場合には本処理終了とするが、これに対して、他のＶＤＣが存在しない場合、デバイス３０４に対してイベント登録削除の依頼を行い（ステップＳ６３４）、その後、本処理終了とする。
【０１１０】
図１８は、上記図６に示した動作における管理コンソール（３１２）の処理（イベントマネージャー（３１１）に対する起動及び終了のリクエスト処理）を具体的に示したものである。
【０１１１】
ステップＳ７０１：
管理コンソール（３１２）は、イベントマネージャー（３１１）の起動を行う。
ステップＳ７０２：
管理コンソール（３１２）は、イベントマネージャー（３１１）から起動終了を示すＣＳＢメッセージを受信する。
【０１１２】
ステップＳ７０３：
管理コンソール（３１２）は、ステップＳ７０２で受信したＣＳＢメッセージにより、イベントマネージャー（３１１）が起動成功したか否かを判別する。
この判別の結果、イベントマネージャー（３１１）が起動成功した場合には本処理終了とし、イベントマネージャー（３１１）が起動成功していない場合にはステップＳ７０４に進む。
【０１１３】
ステップＳ７０４：
ステップＳ７０３の判別の結果、イベントマネージャー（３１１）が起動成功していない場合、管理コンソール（３１２）は、他の端末装置でイベントマネージャー（３１１）を起動し、再びステップＳ７０２からの処理を実行する。
このような構成により、イベントポートのオープンに成功しているイベントマネージャー（３１１）をネットワーク上に起動して、クライアントソフトウェア（３０９）からのアクセスを可能とする。
【０１１４】
尚、本発明の目的は、本実施の形態のホスト及び端末の機能を実現するソフトウェアのプログラムコードを記憶した記憶媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読みだして実行することによっても、達成されることは言うまでもない。
この場合、記憶媒体から読み出されたプログラムコード自体が本実施の形態の機能を実現することとなり、そのプログラムコードを記憶した記憶媒体及び当該プログラムコードは本発明を構成することとなる。
プログラムコードを供給するための記憶媒体としては、ＲＯＭ、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード等を用いることができる。
また、コンピュータが読みだしたプログラムコードを実行することにより、本実施の形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ等が実際の処理の一部又は全部を行い、その処理によって本実施の形態の機能が実現される場合も含まれることは言うまでもない。
さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された拡張機能ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部又は全部を行い、その処理によって本実施の形態の機能が実現される場合も含まれることは言うまでもない。
【０１１５】
【発明の効果】
以上説明したように本発明では、情報処理装置は、デバイスでのイベントを端末装置に通知するイベント通知の登録の要求を端末装置から受け付けて、端末装置をイベント通知の通知先として登録するように構成した。これにより、端末装置は、イベント通知の登録をデバイスに要求しなくても、情報処理装置を介してデバイスでのイベントに関するイベント通知情報を取得することができる。
具体的には、例えば、端末装置においてネットワーク管理ソフトウェアによりイベント通知の受信をするに当たって、既に他のアプリケーションによって特定ポートがオープンされている場合であっても、従来のようにイベント通知を受信ができないということはなく、情報処理装置を介して、イベント通知を受信できる。
【０１１６】
また、情報処理装置は、登録の要求を端末装置から受け付けると、デバイスでのイベントを情報処理装置に通知するイベント通知の登録をデバイスに要求するように構成した。これにより、情報処理装置がデバイスからのイベント通知情報を受信して、そのイベント通知情報を複数の要求元へ一括して配信することができるので、デバイスのイベント通知により発生するデバイスの負荷を軽減することができる。具体的には例えば、デバイスがプリンタの場合、印刷開始通知、状態通知、及び終了通知等のイベント通知が頻繁に起きる場合でもデバイスの負荷を軽減することができる。
【図面の簡単な説明】
【図１】本発明を適用したネットワークシステムの構成を示すブロック図である。
【図２】上記ネットワークシステムにおいて、クライアントアプリケーションが動作する端末装置と、サーバアプリケーションが動作する端末装置との関係を説明するための図である。
【図３】上記ネットワークシステムにおいて、イベント通知を使用してネットワーク上のデバイスのエラー状況を管理する処理を説明するためのフローチャートである。
【図４】上記ネットワークシステムのデバイス管理装置の構成を示すブロック図である。
【図５】上記ネットワークシステムにおけるソフトウェアコンポーネントの配置構成を説明するための図である。
【図６】上記ソフトウェアコンポーネントの配置構成において、ＣＳＢＬＭとノードの関係を説明するための図である。
【図７】上記ソフトウェアコンポーネントの配置構成において、分散環境におけるイベント処理を説明するための図である。
【図８】上記イベント処理において、クライアントの動作（イベント登録／削除）を説明するためのフローチャートである。
【図９】上記イベント処理において、クライアントの動作（イベント受信）を説明するためのフローチャートである。
【図１０】上記イベント受信処理による画面表示の一例を説明するための図である。
【図１１】上記イベント処理において、ＶＤＣの動作（イベント登録）を説明するためのフローチャートである。
【図１２】上記イベント処理において、ＶＤＣの動作（イベント登録削除）を説明するためのフローチャートである。
【図１３】上記イベント処理において、ＶＤＣの動作（イベント配信）を説明するためのフローチャートである。
【図１４】上記イベント処理において、イベントマネージャーの動作（ポートのオープン／クローズ）を説明するためのフローチャートである。
【図１５】上記イベントマネージャーの動作において、イベント登録処理を説明するためのフローチャートである。
【図１６】上記イベントマネージャーの動作において、イベント配信処理を説明するためのフローチャートである。
【図１７】上記イベントマネージャーの動作において、イベント登録削除処理を説明するためのフローチャートである。
【図１８】上記イベント処理において、管理コンソールの動作を説明するためのフローチャートである。
【符号の説明】
１００  ネットワークシステム
１０１  ネットワークボード（ＮＢ）
１０２  プリンタ
１０３，１０４，１２１  パーソナルコンピュータ（ＰＣ）
１０５  プリンタ
１０６  ファイルサーバ
１０７  ネットワークディスク
１０８  プリントサーバ
１０９ａ，１０９ｂ  プリンタ
１１０，１２０，１５０  ローカルエリアネットワーク（ＬＡＮ）
１１１，１１２  パーソナルコンピュータ（ＰＣ）
１１３  ファイルサーバ
１１４  ネットワークディスク
１１５  プリントサーバ
１１６，１１７  プリンタ
１２２  パーソナルコンピュータ（ＰＣ）
１３０  変調／復調（ＭＯＤＥＭ）／トランスポンダー
１４０  バックボーン
３０１  ＣＳＢ（論理ソフトウェアバス）
３０２  ＣＳＢ  ＬＭ（ＣＳＢメッセージ配信機構）
３０３，３０５  ＶＤＣ（デバイスを管理するサーバソフトウェアコンポーネント）
３０４，３０６  デバイス
３０７  ＶＤＣ  Ａｇｅｎｔ（ＶＤＣの情報を管理するソフトウェアコンポーネント）
３０８  Ｄｉｓｃｏｖｅｒｙ  ＦＳＡ（デバイス探索を行うソフトウェアコンポーネント）
３０９，３１０  クライアントソフトウェアコンポーネント
３１１  イベントマネージャー
３１２  管理コンソール
【図１】
0003962571.tif 000002
【図２】
0003962571.tif 000003
【図３】
0003962571.tif 000004
【図４】
0003962571.tif 000005
【図５】
0003962571.tif 000006
【図６】
0003962571.tif 000007
【図７】
0003962571.tif 000008
【図８】
0003962571.tif 000009
【図９】
0003962571.tif 000010
【図１０】
0003962571.tif 000011
【図１１】
0003962571.tif 000012
【図１２】
0003962571.tif 000013
【図１３】
0003962571.tif 000014
【図１４】
0003962571.tif 000015
【図１５】
0003962571.tif 000016
【図１６】
0003962571.tif 000017
【図１７】
0003962571.tif 000018
【図１８】
0003962571.tif 000019