JP3950736B2

JP3950736B2 - Network device management system and control method thereof

Info

Publication number: JP3950736B2
Application number: JP2002129330A
Authority: JP
Inventors: 稔鳥居
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2002-04-30
Filing date: 2002-04-30
Publication date: 2007-08-01
Anticipated expiration: 2022-04-30
Also published as: JP2003323359A

Description

【０００１】
【発明の属する技術分野】
本発明は、コンピュータネットワークに関し、特に、ネットワーク上に接続された各種デバイスを管理するネットワーク管理ソフトウェアを具備するネットワークデバイス管理システム及びその制御方法に関する。
【０００２】
【従来の技術】
ネットワーク上に接続された各種デバイス（以下、「ネットワークデバイス」と称す。）を管理する方法として、ＳＮＭＰ（Simple Network Management Protocol）／ＭＩＢ（Management Information Base）を使用する方法が知られている（ＳＮＭＰ／ＭＩＢの詳細に関しては、「ＴＣＰ／ＩＰネットワーク管理入門実用的な管理をめざして」、Ｍ．Ｔ．ローズ著／西田竹志訳、（株）トッパン発行、１９９２年８月２０日初版を参照）。
【０００３】
ＳＮＭＰネットワーク管理技術によれば、ネットワーク管理システムには、少なくとも１つのネットワーク管理ステーション（ＮＭＳ）と、各々がエージェントを含むいくつかの管理対象ノードと、ネットワーク管理ステーションやエージェントが管理情報を交換するために使用するネットワーク管理プロトコルとが含まれる。そして、ユーザは、ネットワーク管理ステーション上でネットワーク管理ソフトウェアを用いて、管理対象ノード上のエージェントソフトウェアと通信することにより、ネットワークを介して管理対象に関するデータを取得し、また、そのデータを変更することができる。
【０００４】
一般に、プリンタ等の管理対象から能動的に状態変化情報を通知する場合、ＳＮＭＰプロトコルではＴＲＡＰ−ＰＤＵが使用される（ＴＲＡＰ−ＰＤＵの詳細な構造に関しては、ＭａｒｓｈａｌｌＴ．Ｒｏｓｅ、「ＴｈｅＳｉｍｐｌｅＢｏｏｋ」、Ｐｒｅｎｔｉｃｅ−Ｈａｌｌ、１９９１を参照）。
【０００５】
これによれば、例えば、プリンタから紙詰まり等のエラーに関する状態変化情報（エラー情報）が通知される場合、ＴＲＡＰ−ＰＤＵが使用される。すなわち、プリンタ内部でエラーが発生した場合、まず、プリンタはネットワーク管理ステーションに対してＴＲＡＰ−ＰＤＵによりエラー情報を送信する。エラー情報を受信したネットワーク管理ステーションでは、例えばエラーの発生のようなイベントを文字或いは図等を用いてディスプレイ上に表示することによって、受信したエラー情報をユーザに通知することができる。
【０００６】
このようなイベントの通知によってプリンタ等の状態を監視する際に使用されるプロトコルは、上述したＳＮＭＰプロトコルに限られるわけではない。例えば、ＳＮＭＰプロトコルでは、ＴＲＡＰ−ＰＤＵを受信するために、ネットワーク管理ソフトウェアで特定のポートを介してパケットを受信できるようにしている。また、プリンタにイベント受信用のポートを登録することによって、イベント受信の際に任意のポートを使用することができるようなプロトコルもある。
【０００７】
一方、ネットワーク上の端末間で、大容量のデータをアップロード又はダウンロードする方法として、ＦＴＰ（File Transfer Protocol）プロトコルを使用する方法が知られている。ＦＴＰは、ファイルの転送を行う標準としてＲＦＣ９５９で定義されている。すなわち、ＲＦＣ９５９では、ＦＴＰの通信モデル、データのタイプ、ファイル構造、転送モード及びＦＴＰコマンド等が定義されている。ＦＴＰは、ＦＴＰクライアントとＦＴＰサーバとから構成され、制御コマンドを転送するコントロールセッションと、データを転送するデータセッションとの２つのセッションをクライアント／サーバ間で張ることによりファイルの転送を行うものである。
【０００８】
例えば、ＦＴＰは、ＦＴＰクライアントであるネットワークデバイス管理システムと、ＦＴＰサーバであるネットワークデバイスとの間で大容量データを送受信する場合にも使用される。この場合、ネットワークデバイス管理システムは、管理対象のネットワークデバイスに対してＦＴＰプロトコルを使用し、大容量データをアップデート又はダウンロードして、ネットワークデバイス内のリソースを取得し、又は変更することができる。尚、リソースの種類としては、フォントデータ、キャリブレーションデータ及びログ情報等がある。
【０００９】
上述したようなネットワークデバイス管理を行うためのソフトウェア（ネットワーク管理ソフトウェア）を分散環境で使用する場合、ネットワークデバイス管理機能を持つサーバアプリケーションと、各端末で起動されるクライアントアプリケーションとを用いたクライアント／サーバシステムに基づくシステム構成にすることが一般的である。
【００１０】
例えば、異なる端末間で、クライアントアプリケーションとサーバアプリケーションを用いてプロセス間通信を行う標準として、ＲＦＣ１０５７ＲＰＣ（Remote Procedure Call）が定義されている。このＲＰＣは、ネットワークサービスを提供する関数群をサーバ側で用意し、サーバが提供する関数をローカルマシン内の関数と同様にネットワーク上の別端末のクライアントプロセスによって呼び出せるようにしたものである。
【００１１】
ＲＰＣにおけるプロセス間通信の流れは次のようになる。まず、クライアントは、サーバに対するサービス要求として、サーバに用意されているＲＰＣ関数を呼び出す。この時点で、関数の呼び出し情報を格納したデータパケットがクライアントからサーバに送られ、クライアントのプログラムの実行が中断される。そして、サーバがデータパケットを受け取ると、呼び出された関数をディスパッチし、関数の引数を取り出した後、その引数に基づいてサービスを実行し、その結果をクライアントに返す。クライアントは、関数の結果を受け取った後、プログラムの実行を再開する。
【００１２】
尚、クライアント／サーバ間でのデータの送受信には、ネットワーク上を流れる標準的なデータ表現方法であるＸＤＲ（external Data Representation）と呼ばれる外部データ表現が用いられる。ここで、内部データ表現からＸＤＲフォーマットへの変換は「シリアライズ」と呼ばれ、ＸＤＲフォーマットから内部データ表現への変換は「デシリアライズ」と呼ばれる。尚、作成される送受信データは、関数の引数のデータサイズによって増減する。
【００１３】
また、クライアント・サーバ型のネットワークデバイス管理システムにおいて、ネットワークを介して接続されたプリンタの印刷ジョブの終了を検知する場合、前述したように、プリンタから能動的に印刷ジョブの変化情報（イベント情報）を通知する方法と、ＦＴＰのようなファイル転送プロトコルを用いて印刷終了ジョブに関するログ情報を定期的に取得する方法とがある。これらのイベント情報やログ情報は、クライアント／サーバ間でプロセス間通信を用いて送受信される。
【００１４】
【発明が解決しようとする課題】
しかしながら、上述したような従来のネットワークデバイス管理システムでは、ネットワーク管理ソフトウェアによるクライアントアプリケーションが、管理するプリンタにおける印刷ジョブの終了等のネットワークデバイスのジョブの変化を検知する場合、管理するネットワークデバイスの種類に応じてイベント情報取得による検知やログ情報取得による検知等のジョブ変化検知方法を使い分けていたので、クライアントアプリケーションの動作が複雑になるという問題があった。
【００１５】
また、従来のネットワークデバイス管理システムでは、クライアントアプリケーションとサーバアプリケーション間のデータ通信において、大容量のログ情報が送受信されていたので、プロセス間通信のトラフィックが大きくなるという問題が発生していた。
【００１６】
本発明は、このような事情を考慮してなされたものであり、クライアントアプリケーションの動作を簡単にするとともに、プロセス間通信のトラフィックを小さくすることができるネットワークデバイス管理システム及びその制御方法を提供することを目的とする。
【００１７】
上記課題を解決するため、例えば本発明のネットワークデバイス管理システムは以下の構成を備える。
即ち、ネットワーク上に接続されたデバイスに関する情報をクライアント装置とサーバ装置とを用いて管理するネットワークデバイス管理システムであって、
前記サーバ装置は、
前記クライアント装置から要求された前記デバイスのデバイス構成情報を前記デバイスから取得し、取得した当該デバイス構成情報を前記クライアント装置に対して送信する送信手段と、
前記デバイスが、要求に応じてログ情報を送信するログ機能をサポートするか否か、及び、ジョブの処理に関する変化が発生した際に、当該発生したイベントを能動的に前記サーバ装置に通知するイベント通知機能をサポートするか否かを判定する判定手段と、
該判定手段が、前記デバイスが前記イベント通知機能をサポートすると判定した場合、前記デバイスからイベント通知を受信する度に、当該受信したイベント通知で示されるイベント情報を、前記クライアント装置に送信する第１の送信手段と、
前記判定手段が、前記ログ機能をサポートしていると判定した場合、前記デバイスが持つログ情報を、予め設定された期間毎に、取得する取得手段と、
取得したログ情報と従前のログ情報を比較し、変化部分からイベント情報を生成する生成手段と、
生成されたイベント情報を前記クライアント装置へ送信する第２の送信手段と、とを備え、
該クライアント装置は、
前記サーバ装置から送信された前記デバイス構成情報を受信する第１の受信手段と、
前記サーバ装置から送信された前記イベント情報を受信する第２の受信手段と、
前記第１の受信手段が受信した前記デバイス構成情報を初期値とし、前記第２の受信手段が受信したイベント情報を用いて更新された結果を、前記デバイス内のジョブに関する情報として表示する表示手段と
を備えることを特徴とする。
【００１８】
また、本発明の情報処理装置は、以下の構成を備える。
即ち、ネットワーク上に接続されたデバイス内のジョブに関する情報をクライアント装置に通知する情報処理装置であって、
前記クライアント装置から要求された前記デバイスのデバイス構成情報を前記デバイスから取得し、取得した当該デバイス構成情報を前記クライアント装置に対して送信する送信手段と、
前記デバイスが、要求に応じてログ情報を送信するログ機能をサポートするか否か、及び、ジョブの処理に関する変化が発生した際に、当該発生したイベントを能動的に前記サーバ装置に通知するイベント通知機能をサポートするか否かを判定する判定手段と、
該判定手段が、前記デバイスが前記イベント通知機能をサポートすると判定した場合、前記デバイスからイベント通知を受信する度に、当該受信したイベント通知で示されるイベント情報を、前記クライアント装置に送信する第１の送信手段と、
前記判定手段が、前記ログ機能をサポートしていると判定した場合、前記デバイスが持つログ情報を、予め設定された期間毎に、取得する取得手段と、
取得したログ情報と従前のログ情報を比較し、変化部分からイベント情報を生成する生成手段と、
生成されたイベント情報を前記クライアント装置へ送信する第２の送信手段と
を備えることを特徴とする。
【００２１】
さらにまた、本発明に係るネットワークデバイス管理システムは、前記取得手段が、前記デバイスがイベント情報をサポートする場合、前記デバイスからイベント情報を取得することを特徴とする。
【００２２】
さらにまた、本発明に係るネットワークデバイス管理システムは、前記サーバ装置が、前記デバイスに対して、ＳＮＭＰプロトコルを使用してデータ送受信することを特徴とする。
【００２３】
【発明の実施の形態】
以下、図面を参照して、本発明の一実施形態によるネットワークデバイス管理システム及びネットワークを介して接続される周辺装置等について説明する。
【００２４】
図１は、本発明の一実施形態によるネットワークデバイス管理システム及び管理対象のデバイスを含むネットワークを介したデバイス管理システムの概要を示す図である。
【００２５】
図１において、ローカルエリアネットワーク（以下、「ＬＡＮ」と称す。）１００には、ネットワークボード１０１を備え、開放型アーキテクチャを持つプリンタ（デバイス）１０２と、本発明に係るネットワークデバイス管理システムのクライアント側として機能するパーソナルコンピュータ（以下、「ＰＣ」と称す。）１０３と、プリンタ１０５に接続するＰＣ１０４と、ネットワークディスク１０７に接続するファイルサーバ１０６と、プリンタ１０９ａ、１０９ｂに接続するプリンタサーバ１０８と、本発明に係るネットワークデバイス管理システムのサーバ側として機能するＰＣ１２１と、モデム／トランスポンダ１３０とが接続している。
【００２６】
また、ＬＡＮ１２０には、ＰＣ１２２と、モデム／トランスポンダ１３１に接続するバックボーン１４０とが接続している。そして、モデム／トランスボンダ１３０とモデム／トランスボンダ１３１とは、互いに広域ネットワーク（ＷＡＮ）を介して接続されている。
【００２７】
さらに、ＬＡＮ１１０には、ＬＡＮ１２０にも接続するモデム／トランスボンダ１３１と、ＰＣ１１０と、ＰＣ１１２と、ネットワークディスク１１４に接続するファイルサーバ１１３と、プリンタ１１６、１１７に接続するＰＣ１１５が接続している。
【００２８】
図２は、本発明に係るネットワークデバイス管理システムを実現するＰＣ１０３又はＰＣ１２１等のＰＣの構成を示す図である。図２に示すように、ＰＣ２００は、ＣＰＵ２０１と、ＲＯＭ２０２と、ＲＡＭ２０３と、キーボード（ＫＢ）２０９に接続するキーボードコントローラ（ＫＢＣ）２０５と、ＣＲＴ２１０に接続するＣＲＴコントローラ（ＣＲＴＣ）２０６と、ハードディスク（ＨＤ）２１１及びフレキシブルディスクドライブ（ＦＤ）に接続するディスクコントローラ（ＤＫＣ）２０７と、ＬＡＮ１００に接続するネットワークインタフェースカード（ＮＩＣ）がシステムバス２０４を介して接続されている。
【００２９】
尚、図２に示すＰＣ２００は、図１におけるＰＣ１０３、ＰＣ１２１だけに限らず、ＰＣ１０４、１０８、１２２、１１１、１１２、１１５も同様の構成であってもよい。図２に示すＰＣ２００におけるＨＤ２１１には、後述するすべての説明での動作主体となる本発明に係るネットワーク管理ソフトウェアに関するプログラムが格納されている。
【００３０】
また、ＣＰＵ２０１は、後述するすべての説明において特に断りのない限り、ハードウェア上の制御の主体である。一方、ソフトウェア上の制御の主体は、ＨＤ２１１に格納されたプログラムで実行されるネットワーク管理ソフトウェアである。尚、本実施形態においては、オペレーティングシステム（以下、「ＯＳ」と称す。）として、マイクロソフト社製のウィンドウズ２０００を想定しているが、これに限られるものではなく、その他のＯＳであってもよい。
【００３１】
尚、本実施形態におけるネットワーク管理プログラムは、フレキシブルディスクやＣＤ−ＲＯＭなどの記憶媒体に格納された形式で供給されてもよい。尚、そのような場合には、図２に示すＦＤ２１２又は不図示のＣＤ−ＲＯＭドライブ等によって記憶媒体に格納されたプログラムが読み取られ、ＨＤ２１１にインストールされる。
【００３２】
尚、以下の説明においては、ネットワーク管理ソフトウェアのＧＵＩ（Graphical User Interface）部分のプロセス（クライアントアプリケーション）を「ＮｅｔＳｐｏｔＧＵＩ」と称し、デバイスと通信する部分のプロセス（サーバアプリケーション）を「ＶＤＣ」と称す。
【００３３】
図３は、ＬＡＮ１００に接続されたＰＣ１０３、ＰＣ１２１及びプリンタ１０２を用いたデータ通信を説明するための図である。本実施形態では、図３に示すように、ＰＣ１０３上でＮｅｔＳｐｏｔＧＵＩのプロセス、ＰＣ１２１上でＶＤＣのプロセスをそれぞれ起動してプリンタ（デバイス）１０２を管理する。すなわち、ＮｅｔＳｐｏｔＧＵＩは、プロセス間通信の機能を使用してＶＤＣとデータ通信を行い、ＶＤＣは、ＳＮＭＰプロトコルを使用して所定の管理対象デバイスと通信を行う。尚、同一ＰＣ上において、ＮｅｔＳｐｏｔＧＵＩ及びＶＤＣのプロセスを起動してプリンタ１０２を管理するようなシステムであってもよい。この場合も、プロセス間通信等の処理は同様である。
【００３４】
ここで、ネットワークデバイス管理システムが、管理対象デバイスからデバイス構成情報を取得する場合の処理について説明する。まず、ＮｅｔＳｐｏｔＧＵＩによってプロキシを用いたプロセス間通信が行われ、ＶＤＣに対して取得したいデバイス構成情報を送信する。次いで、ＶＤＣは、スタブでＮｅｔＳｐｏｔＧＵＩから受信した情報を受け取り、ＳＮＭＰプロトコルを用いてデバイスからデバイスＭＩＢ情報を取得する。このようにして取得したデバイスＭＩＢ情報は、ＶＤＣのスタブからプロセス間通信を使用してプロキシに送信され、プロキシからＮｅｔＳｐｏｔＧＵＩにコールバック通知される。そして、ＮｅｔＳｐｏｔＧＵＩは、プロキシからコールバック通知された情報に基づいてビットマップ表示等によってデバイス構成情報を表示する。
【００３５】
次に、ネットワークデバイス管理システムが、管理対象デバイスに対してデバイス構成情報を設定する場合について説明する。まず、ＮｅｔＳｐｏｔＧＵＩは、プロキシを用いてプロセス間通信を行い、ＶＤＣに対して設定したいデバイス構成情報を送信する。次いで、ＶＤＣは、スタブでＮｅｔＳｐｏｔＧＵＩからの情報を受信し、ＳＮＭＰプロトコルを用いてデバイスに対してデバイスＭＩＢ情報を設定する。尚、デバイスでの設定が成功したか失敗したかを示す設定情報が、ＶＤＣのスタブからプロセス間通信を使用してプロキシに送信され、プロキシからＮｅｔＳｐｏｔＧＵＩにコールバック通知される。そして、ＮｅｔＳｐｏｔＧＵＩは、プロキシからコールバック通知された設定情報に基づいてビットマップ表示等を行うことによってデバイス構成情報の設定結果を表示する。
【００３６】
図４は、ＮｅｔＳｐｏｔＧＵＩが所定の管理対象デバイスに関するジョブ情報（以下、「デバイスジョブ情報」と称す。）を表示する画面の一例を示す図である。ＮｅｔＳｐｏｔＧＵＩは、デバイスからデバイスジョブ情報を取得するためにプロキシを用いてプロセス間通信をし、ＶＤＣに対してデバイスジョブ情報の取得命令を送信する。ＶＤＣは、スタブでデバイスジョブ情報の取得命令を受信し、例えば、ＳＮＭＰプロトコルを用いたＪｏｂＭＩＢ、ＩＰＰ（Internet Printing Protocol）等のデバイスジョブ情報取得用プロトコルを用いてデバイスからデバイスジョブ情報を取得する。
【００３７】
すなわち、本発明に係るネットワークデバイス管理システムにおけるサーバ装置が、デバイスに対して、ＳＮＭＰプロトコルを使用してデータ送受信することを特徴とする。
【００３８】
取得されたデバイスジョブ情報は、ＶＤＣのスタブからプロセス間通信を使用してプロキシに送信され、プロキシからＮｅｔＳｐｏｔＧＵＩにコールバック通知される。そして、ＮｅｔＳｐｏｔＧＵＩは、プロキシからコールバック通知されたデバイスジョブ情報に基づいて、図４に示されるような画面を用いて当該デバイスジョブ情報をリスト表示する。
【００３９】
また、ＮｅｔＳｐｏｔＧＵＩは、デバイスジョブ情報の状態の変化をリアルタイムで表示するために、プロキシを用いてプロセス間通信を行ってＶＤＣに対しイベント情報の通知依頼命令を送信する。ＶＤＣは、イベント情報の通知依頼命令をスタブで受信し、イベント情報を通知する通知先としてＮｅｔＳｐｏｔＧＵＩ（クライアント）の情報を登録する。
【００４０】
そして、ＶＤＣは、管理対象デバイスからイベント情報を取得した場合、又は管理対象デバイスから印刷等のジョブが終了したことを示すログ情報を取得した場合に、通知先として登録されているクライアントに対して通知するために、まず、スタブからプロセス間通信を使用してプロキシに対してイベント情報をジョブ状態変化情報として送信する。プロキシは受信したジョブ状態変化情報をＮｅｔＳｐｏｔＧＵＩにコールバック通知する。そして、ＮｅｔＳｐｏｔＧＵＩは、コールバック通知されたジョブ状態変化情報に基づいてリスト内のデバイスジョブ情報を更新する。
【００４１】
以下、上述したＮｅｔＳｐｏｔＧＵＩとＶＤＣによる管理対象デバイスに関するイベント情報及びログ情報の取得動作の詳細について説明する。
【００４２】
図５は、ＶＤＣにおけるイベント情報の登録動作を説明するためのフローチャートである。まず、ＶＤＣは、ＮｅｔＳｐｏｔＧＵＩ（クライアント）からイベント情報の登録依頼を受信する（ステップＳ５１）。次に、イベント情報の登録先であるデバイスがログ機能をサポートしているか否かをチェックする（ステップＳ５２）。
【００４３】
その結果、当該デバイスがログ機能をサポートしている場合（ＹＥＳ）、デバイスからログ情報の取得を開始する（ステップＳ５３）。そして、ＶＤＣは、デバイス内部で保持可能なログ数に応じて、定期的にデバイスが保持しているログ情報を取得する。一方、当該デバイスがログ機能をサポートしていない場合（ＮＯ）、或いはステップＳ５３でログ情報の取得を開始した後、デバイスがイベント機能をサポートしているか否かをチェックする（ステップＳ５４）。
【００４４】
その結果、当該デバイスがイベント機能をサポートしていない場合（ＮＯ）、イベント情報の登録依頼のあったＮｅｔＳｐｏｔＧＵＩ（クライアント）をイベント情報通知リストに登録する（ステップＳ５９）。一方、イベント機能をサポートしているデバイスの場合（ＹＥＳ）、既にイベント情報の登録を行ったデバイスか否かを判断する（ステップＳ５５）。
【００４５】
その結果、当該デバイスにイベント情報が未登録の場合、デバイスにイベント情報の登録が行われる（ステップＳ５６）。一方、既に当該デバイスにイベント情報の登録が行われている場合、異なるイベント情報（例えば、イベント種別やイベントプロパティ等）があるか否かを判断する（ステップＳ５７）。その結果、異なるイベント情報がある場合（ＹＥＳ）、当該デバイスにそのイベント情報を追加登録する（ステップＳ５８）。そして、イベント情報の登録依頼のあったＮｅｔＳｐｏｔＧＵＩ（クライアント）をイベント情報通知リストに登録する（ステップＳ５９）。一方、異なるイベント情報がない場合（ＮＯ）、イベント情報の登録依頼のあったＮｅｔＳｐｏｔＧＵＩ（クライアント）をイベント情報の通知リストに登録する（ステップＳ５９）。
【００４６】
また、図６は、ＶＤＣにおける登録されたイベント情報の削除動作を説明するためのフローチャートである。まず、ＶＤＣは、ＮｅｔＳｐｏｔＧＵＩ（クライアント）から登録されたイベント情報の削除依頼を受信する（ステップＳ６１）。次いで、ＶＤＣは、当該ＮｅｔＳｐｏｔＧＵＩ（クライアント）をイベント情報の通知リストから削除する（ステップＳ６２）。
【００４７】
さらに、削除依頼を行ったクライアントが管理しているデバイスのイベント情報を通知する他のＮｅｔＳｐｏｔＧＵＩ（クライアント）が存在するか否かが判断される（ステップＳ６３）。その結果、他のＮｅｔＳｐｏｔＧＵＩ（クライアント）が存在する場合（ＹＥＳ）、当該削除処理を終了する。一方、他のＮｅｔＳｐｏｔＧＵＩ（クライアント）が存在しない場合（ＮＯ）、ＶＤＣがデバイスから定期的にログ情報を取得しているか否かが判断される（ステップＳ６４）。
【００４８】
その結果、ＶＤＣが定期的にログ情報を取得している場合（ＹＥＳ）、ログ情報の取得動作を終了する（ステップＳ６５）。一方、ＶＤＣが定期的にログ情報を取得していない場合（ＮＯ）、又はステップＳ６５においてログ情報の取得動作の終了処理を行った場合、デバイスに対してイベント情報の登録を行っているか否かをチェックする（ステップＳ６６）。その結果、イベント情報の登録を行っている場合（ＹＥＳ）、デバイスに対してイベント情報の登録削除依頼を行う（ステップＳ６７）。一方、イベント情報の登録を行っていない場合（ＮＯ）、処理を終了する。
【００４９】
図７は、ＶＤＣが管理対象デバイスからイベント情報を取得し、ＮｅｔＳｐｏｔＧＵＩに対してイベント情報の通知を行う場合の動作手順を説明するためのフローチャートである。まず、ＶＤＣは、管理対象デバイスからイベント情報を取得する（ステップＳ７１）。次に、ＶＤＣは、イベント情報を通知をすべきＮｅｔＳｐｏｔＧＵＩ数（クライアント数）を内部カウンタに設定する（ステップＳ７２）。そして、そのカウンタ値が０であるか否かを判断する（ステップＳ７３）。その結果、カウンタ値が０の場合（ＹＥＳ）、処理を終了する。一方、カウンタ値が０でない場合（ＮＯ）、イベント情報をＮｅｔＳｐｏｔＧＵＩ（クライアント）に通知する（ステップＳ７４）。その後、当該カウンタ値をデクリメントし（ステップＳ７５）、ステップＳ７３の処理に戻る。
【００５０】
図８は、ＶＤＣが管理対象デバイスから取得したログ情報からイベント情報を作成してクライアントに対して配信する場合の処理手順を説明するためのフローチャートである。まず、ＶＤＣは、管理対象デバイスからログ情報を取得する（ステップＳ８１）。次に、ＶＤＣは、取得したログ情報とキャッシュ（Cache）しているログ情報とを比較し、管理対象デバイス内に新たに追加されたログ情報のみを抽出し、そのログ情報をイベント情報に変換する（ステップＳ８２）。
【００５１】
さらに、ＶＤＣは、イベント情報を通知すべきＮｅｔＳｐｏｔＧＵＩ数（クライアント数）を内部カウンタに設定する（ステップＳ８３）。そして、ＶＤＣは、当該カウンタ値が０であるか否かを判断する（ステップＳ８４）。その結果、カウンタ値が０の場合（ＹＥＳ）、処理を終了する。一方、カウンタ値が０でない場合（ＮＯ）、作成したイベント情報をＮｅｔＳｐｏｔＧＵＩ（クライアント）に通知する（ステップＳ８５）。
【００５２】
尚、本実施形態では、ＮｅｔＳｐｏｔＧＵＩ（クライアント）に対するイベント情報の送信は、直ちに行われるのではなく所定時間（例えば、１０秒間）経過後に行われるようにする（ステップＳ８６）。このイベント情報の送信待ち処理は、ログ情報に基づいてＶＤＣの内部動作でイベント情報が作成され、短時間に連続してクライアントに対してイベント情報の送信が行われることになるため、プロセス間通信の負荷を軽減する目的で行われる。そして、当該カウンタ値をデクリメントし（ステップＳ８７）、ステップＳ８４の処理に戻る。
【００５３】
一般に、ＵＤＰパケットを使用して行われるデバイスからのイベント情報の通知は、ネットワーク障害等によって当該パケットが紛失する可能性がある。しかし、デバイスとの通信にＴＣＰを使用するログ情報を併用してジョブ終了を示すイベント情報を送信することにより、ＮｅｔＳｐｏｔＧＵＩ（クライアント）に対してジョブの終了を通知する精度が向上する。
【００５４】
さらに、ＶＤＣが、イベント情報の取得による検知、ログ情報の取得による検知、イベント情報とログ情報の併用による検知の３種類のジョブ終了に係る検知方法を統一してイベント情報通知を扱う仮想デバイスとして振舞うことにより、ＮｅｔＳｐｏｔＧＵＩ（クライアント）がデバイスの種類に関わらずに、イベント情報の通知のみを処理をすることができる。また、ＮｅｔＳｐｏｔＧＵＩ（クライアント）は、定期的にデータ量の大きいログ情報を取得するのではなく、データ量の少ないイベント情報の通知を受けるため、プロセス間通信のトラフィックを軽減することができる。
【００５５】
次に、ＮｅｔＳｐｏｔＧＵＩ（クライアント）の内部動作について詳細に説明する。
【００５６】
図９は、クライアントがＶＤＣに対してイベント情報の登録及び削除を行う場合の動作手順を説明するためのフローチャートである。まず、クライアントは、ＶＤＣに対してこれから処理を行うイベント情報の登録を行う（ステップＳ９１）。ここで、登録するイベント情報として、クライアントのアドレス、クライアントを一意に識別するための識別子（ＧＵＩＤ）、イベント情報の種類を示すイベント種別、各イベント種別の属性情報を示すイベントプロパティ等がある。
【００５７】
また、イベント種別の一例として、デバイスイベント、ジョブイベント等がある。さらに、イベントプロパティの一例として、ジョブイベントの属性であるジョブオーナー、ジョブ名、ジョブ状態等がある。次に、ＮｅｔＳｐｏｔＧＵＩは、イベントコールバック受信処理を行う（ステップＳ９２）。そして、クライアントは、登録したイベント情報の削除を行う（ステップＳ９３）。
【００５８】
ここで、ステップＳ９２で行われるＮｅｔＳｐｏｔＧＵＩでのイベントコールバック受信処理についてさらに説明する。図１０は、クライアントがＶＤＣからイベントコールバックを受信した場合の処理を説明するためのフローチャートである。クライアントは、ＶＤＣからイベントコールバック通知を受信する（ステップＳ９２１）。次いで、クライアントは、受信した通知に基づいてディスプレイ等の表示を更新する（ステップＳ９２２）。前述した図４は、クライアントにおけるディスプレイ表示例として、ジョブイベントを受信したときのアプリケーションを示す図である。クライアントでは、ジョブの終了イベントを受信した場合、図４におけるジョブ状態を示している文字列が「印刷中」から「印刷済」に変更される。
【００５９】
上述したように、本発明は、異なる印刷ジョブ終了検知方法を提供しているデバイス群に対してイベントによる単一の印刷ジョブ終了検知方法を提供するものである。本発明によって、クライアントアプリケーションがデバイスの種類を意識せずに単純な動作を行うことができるという効果がある。また、イベント情報とログ情報の両方をサポートしているデバイスにおいて、イベント情報とログ情報を併用して印刷ジョブ終了検知を行っているので、印刷ジョブ終了検知の精度が向上するという効果が得られる。
【００６０】
さらに、本発明は、クライアントアプリケーションが定期的にデータ量の大きいログ情報を取得する代わりに、サーバアプリケーションにおいてログ情報をログに比べてデータ量の少ないイベント情報に変換した。このように、クライアントアプリケーションに対してイベント情報のみを通知することにより、プロセス間通信のトラフィックを軽減するという効果が得られる。
【００６１】
尚、本発明は、複数の機器（例えば、ホストコンピュータ、インタフェース機器、リーダ、プリンタ等）から構成されるシステムに適用しても、一つの機器からなる装置（例えば、複写機、ファクシミリ装置等）に適用してもよい。
【００６２】
また、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記録媒体（または記憶媒体）を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムコードを読み出し実行することによっても、達成されることは言うまでもない。この場合、記録媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記録した記録媒体は本発明を構成することになる。また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているオペレーティングシステム（ＯＳ）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【００６３】
さらに、記録媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張カードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張カードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【００６４】
本発明を上記記録媒体に適用する場合、その記録媒体には、先に説明したフローチャートに対応するプログラムコードが格納されることになる。
【００６５】
【発明の効果】
以上説明したように、本発明によれば、クライアントアプリケーションの動作を簡単にするとともに、プロセス間通信のトラフィックを小さくすることができる。
【図面の簡単な説明】
【図１】本発明の一実施形態によるネットワークデバイス管理システム及び管理対象のデバイスを含むネットワークを介したデバイス管理システムの概要を示す図である。
【図２】本発明に係るネットワークデバイス管理システムを実現するＰＣ１０３又はＰＣ１２１等のＰＣの構成を示す図である。
【図３】ＬＡＮ１００に接続されたＰＣ１０３、ＰＣ１２１及びプリンタ１０２を用いたデータ通信を説明するための図である。
【図４】ＮｅｔＳｐｏｔＧＵＩが所定の管理対象デバイスに関するジョブ情報を表示する画面の一例を示す図である。
【図５】ＶＤＣにおけるイベント情報の登録動作を説明するためのフローチャートである。
【図６】ＶＤＣにおける登録されたイベント情報の削除動作を説明するためのフローチャートである。
【図７】ＶＤＣが管理対象デバイスからイベント情報を取得し、ＮｅｔＳｐｏｔＧＵＩに対してイベント情報の通知を行う場合の動作手順を説明するためのフローチャートである。
【図８】ＶＤＣが管理対象デバイスから取得したログ情報からイベント情報を作成してクライアントに対して配信する場合の処理手順を説明するためのフローチャートである。
【図９】クライアントがＶＤＣに対してイベント情報の登録及び削除を行う場合の動作手順を説明するためのフローチャートである。
【図１０】クライアントがＶＤＣからイベントコールバックを受信した場合の処理を説明するためのフローチャートである。
【符号の説明】
１００ＬＡＮ
１０２プリンタ
１０３、１２１、２００パーソナルコンピュータ
２０１ＣＰＵ
２０２ＲＯＭ
２０３ＲＡＭ
２０４システムバス
２０５キーボードコントローラ
２０６ＣＲＴコントローラ
２０７ディスクコントローラ
２０８ネットワークインタフェースカード
２０９キーボード
２１０ＣＲＴ
２１１ハードディスク
２１２フレキシブルディスクドライブ[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a computer network, and more particularly, to a network device management system including network management software for managing various devices connected to the network, and a control method therefor.
[0002]
[Prior art]
As a method for managing various devices connected to the network (hereinafter referred to as “network device”), a method using SNMP (Simple Network Management Protocol) / MIB (Management Information Base) is known (SNMP. / For details on MIB, see "Introduction to TCP / IP Network Management for Practical Management", MT Rose, translated by Takeshi Nishida, Toppan Co., Ltd., published on August 20, 1992) .
[0003]
According to the SNMP network management technology, a network management system includes at least one network management station (NMS), several managed nodes each including an agent, and the network management station and the agent exchange management information. Network management protocol to be used. Then, the user uses the network management software on the network management station to communicate with the agent software on the managed node, thereby obtaining data related to the managed object via the network, and changing the data. Can do.
[0004]
Generally, when state change information is actively notified from a management target such as a printer, a TRAP-PDU is used in the SNMP protocol (for the detailed structure of the TRAP-PDU, Marshall T. Rose, “The Simple Book”, Prentice-Hall, 1991).
[0005]
According to this, for example, when status change information (error information) regarding an error such as a paper jam is notified from the printer, the TRAP-PDU is used. That is, when an error occurs in the printer, first, the printer transmits error information to the network management station using TRAP-PDU. The network management station that has received the error information can notify the user of the received error information by, for example, displaying an event such as the occurrence of an error on a display using characters or drawings.
[0006]
The protocol used when monitoring the status of a printer or the like by notification of such an event is not limited to the SNMP protocol described above. For example, in the SNMP protocol, in order to receive TRAP-PDU, the network management software can receive a packet through a specific port. There is also a protocol in which an arbitrary port can be used for event reception by registering an event reception port in the printer.
[0007]
On the other hand, as a method for uploading or downloading a large amount of data between terminals on a network, a method using an FTP (File Transfer Protocol) protocol is known. FTP is defined in RFC959 as a standard for transferring files. That is, RFC959 defines an FTP communication model, data type, file structure, transfer mode, FTP command, and the like. FTP is composed of an FTP client and an FTP server, and transfers files by establishing two sessions between a client / server, a control session for transferring control commands and a data session for transferring data. .
[0008]
For example, FTP is also used when large-capacity data is transmitted and received between a network device management system that is an FTP client and a network device that is an FTP server. In this case, the network device management system can acquire or change resources in the network device by using the FTP protocol for the network device to be managed, updating or downloading large-capacity data. Note that the types of resources include font data, calibration data, log information, and the like.
[0009]
When software for network device management (network management software) as described above is used in a distributed environment, a client / server using a server application having a network device management function and a client application started on each terminal In general, the system configuration is based on the system.
[0010]
For example, RFC 1057 RPC (Remote Procedure Call) is defined as a standard for performing inter-process communication between different terminals using a client application and a server application. In this RPC, a group of functions for providing a network service is prepared on the server side, and functions provided by the server can be called by a client process of another terminal on the network in the same manner as a function in the local machine.
[0011]
The flow of interprocess communication in RPC is as follows. First, the client calls an RPC function prepared in the server as a service request to the server. At this point, a data packet storing function call information is sent from the client to the server, and execution of the client program is interrupted. When the server receives the data packet, it dispatches the called function, retrieves the argument of the function, executes the service based on the argument, and returns the result to the client. The client resumes program execution after receiving the result of the function.
[0012]
For data transmission / reception between the client / server, external data representation called XDR (external data representation), which is a standard data representation method that flows on the network, is used. Here, the conversion from the internal data representation to the XDR format is called “serialization”, and the conversion from the XDR format to the internal data representation is called “deserialization”. The transmission / reception data to be created increases or decreases depending on the data size of the function argument.
[0013]
In addition, when detecting the end of a print job of a printer connected via a network in a client / server type network device management system, as described above, the change information (event information) of the print job is actively sent from the printer. And a method of periodically obtaining log information related to a print end job using a file transfer protocol such as FTP. These event information and log information are transmitted and received between the client / server using inter-process communication.
[0014]
[Problems to be solved by the invention]
However, in the conventional network device management system as described above, when the client application by the network management software detects a change in the job of the network device such as the end of the print job in the printer to be managed, the type of the network device to be managed is set. Accordingly, since the job change detection method such as detection by event information acquisition or detection by log information acquisition is used separately, there is a problem that the operation of the client application becomes complicated.
[0015]
Further, in the conventional network device management system, since a large amount of log information is transmitted and received in data communication between the client application and the server application, there has been a problem that traffic for inter-process communication increases.
[0016]
The present invention has been made in consideration of such circumstances, and provides a network device management system and a control method thereof that can simplify the operation of a client application and reduce the traffic of interprocess communication. For the purpose.
[0017]
  In order to solve the above problems, for example, a network device management system of the present invention has the following configuration.
  That is, a network device management system that manages information about devices connected to a network using a client device and a server device,
  The server device
    Transmitting means for acquiring device configuration information of the device requested from the client device from the device, and transmitting the acquired device configuration information to the client device;
    An event for actively notifying the server device of the generated event when a change occurs regarding whether or not the device supports a log function for transmitting log information in response to a request and job processing A determination means for determining whether to support the notification function;
    When the determination unit determines that the device supports the event notification function, the event information indicated by the received event notification is transmitted to the client device each time an event notification is received from the device. Means for sending
    When the determination unit determines that the log function is supported, the acquisition unit acquires the log information of the device for each preset period;
    A means for comparing the acquired log information with the previous log information and generating event information from the changed portion;
    Second transmission means for transmitting the generated event information to the client device,
  The client device
    First receiving means for receiving the device configuration information transmitted from the server device;
    Receiving the event information transmitted from the server device;SecondReceiving means;
    The device configuration information received by the first receiving unit is set as an initial value, and the second receiving unit receivesevent informationThe updated result using, Information about jobs in the deviceAsDisplay means to display and
  It is characterized by providing.
[0018]
  The information processing apparatus of the present invention has the following configuration.
  That is, an information processing apparatus that notifies a client apparatus of information related to a job in a device connected to a network,
  Transmitting means for acquiring device configuration information of the device requested from the client device from the device, and transmitting the acquired device configuration information to the client device;
  An event for actively notifying the server device of the generated event when a change occurs regarding whether or not the device supports a log function for transmitting log information in response to a request and job processing A determination means for determining whether to support the notification function;
  When the determination unit determines that the device supports the event notification function, the event information indicated by the received event notification is transmitted to the client device each time an event notification is received from the device. Means for sending
  When the determination unit determines that the log function is supported, the acquisition unit acquires the log information of the device for each preset period;
  A means for comparing the acquired log information with the previous log information and generating event information from the changed portion;
  Second transmission means for transmitting the generated event information to the client device;
  It is characterized by providing.
[0021]
Furthermore, the network device management system according to the present invention is characterized in that the acquisition unit acquires event information from the device when the device supports event information.
[0022]
Furthermore, the network device management system according to the present invention is characterized in that the server device transmits / receives data to / from the device using an SNMP protocol.
[0023]
DETAILED DESCRIPTION OF THE INVENTION
Hereinafter, a network device management system and peripheral devices connected via a network according to an embodiment of the present invention will be described with reference to the drawings.
[0024]
FIG. 1 is a diagram illustrating an overview of a network device management system and a device management system via a network including devices to be managed according to an embodiment of the present invention.
[0025]
In FIG. 1, a local area network (hereinafter referred to as “LAN”) 100 includes a network board 101, a printer (device) 102 having an open architecture, and a client side of the network device management system according to the present invention. A personal computer (hereinafter referred to as “PC”) 103, a PC 104 connected to the printer 105, a file server 106 connected to the network disk 107, a printer server 108 connected to the printers 109 a and 109 b, A PC 121 functioning as a server side of the network device management system according to the invention and a modem / transponder 130 are connected.
[0026]
Further, a PC 122 and a backbone 140 connected to the modem / transponder 131 are connected to the LAN 120. The modem / trans bonder 130 and the modem / trans bonder 131 are connected to each other via a wide area network (WAN).
[0027]
Further, a modem / transbonder 131 that is also connected to the LAN 120, a PC 110, a PC 112, a file server 113 that is connected to the network disk 114, and a PC 115 that is connected to the printers 116 and 117 are connected to the LAN 110.
[0028]
FIG. 2 is a diagram showing a configuration of a PC such as the PC 103 or the PC 121 that implements the network device management system according to the present invention. As shown in FIG. 2, the PC 200 includes a CPU 201, a ROM 202, a RAM 203, a keyboard controller (KBC) 205 connected to a keyboard (KB) 209, a CRT controller (CRTC) 206 connected to a CRT 210, and a hard disk (HD). ) 211 and a disk controller (DKC) 207 connected to the flexible disk drive (FD) and a network interface card (NIC) connected to the LAN 100 are connected via the system bus 204.
[0029]
2 is not limited to the PC 103 and PC 121 shown in FIG. 1, and the PCs 104, 108, 122, 111, 112, and 115 may have the same configuration. The HD 211 in the PC 200 shown in FIG. 2 stores a program related to the network management software according to the present invention, which is an operation subject in all the descriptions to be described later.
[0030]
In addition, the CPU 201 is a main controller of hardware unless otherwise specified in all the explanations to be described later. On the other hand, the control subject on software is network management software executed by a program stored in the HD 211. In this embodiment, Windows 2000 made by Microsoft Corporation is assumed as an operating system (hereinafter referred to as “OS”), but the present invention is not limited to this, and other operating systems may be used. Good.
[0031]
Note that the network management program in the present embodiment may be supplied in a format stored in a storage medium such as a flexible disk or a CD-ROM. In such a case, the program stored in the storage medium is read by the FD 212 shown in FIG. 2 or a CD-ROM drive (not shown) and installed in the HD 211.
[0032]
In the following description, the process (client application) of the GUI (Graphical User Interface) part of the network management software is referred to as “NetSpot GUI”, and the process (server application) of the part communicating with the device is referred to as “VDC”. .
[0033]
FIG. 3 is a diagram for explaining data communication using the PC 103, the PC 121, and the printer 102 connected to the LAN 100. In this embodiment, as shown in FIG. 3, the NetSpot GUI process is started on the PC 103 and the VDC process is started on the PC 121 to manage the printer (device) 102. That is, the NetSpot GUI performs data communication with the VDC using the inter-process communication function, and the VDC communicates with a predetermined managed device using the SNMP protocol. Note that a system in which the NetSpot GUI and VDC processes are activated to manage the printer 102 on the same PC may be used. In this case as well, processing such as interprocess communication is the same.
[0034]
Here, processing when the network device management system acquires device configuration information from the management target device will be described. First, inter-process communication using a proxy is performed using the NetSpot GUI, and device configuration information desired to be acquired is transmitted to the VDC. Next, the VDC receives the information received from the NetSpotGUI with the stub, and acquires the device MIB information from the device using the SNMP protocol. The device MIB information acquired in this way is transmitted from the VDC stub to the proxy using inter-process communication, and the proxy notifies the NetSpot GUI of the callback. Then, the NetSpot GUI displays the device configuration information by a bitmap display or the like based on the information notified of the callback from the proxy.
[0035]
Next, a case where the network device management system sets device configuration information for a management target device will be described. First, the NetSpot GUI performs inter-process communication using a proxy and transmits device configuration information to be set to the VDC. Next, the VDC receives information from the NetSpot GUI via the stub and sets device MIB information for the device using the SNMP protocol. Note that setting information indicating whether the setting on the device has succeeded or failed is transmitted from the VDC stub to the proxy using inter-process communication, and the proxy notifies the NetSpot GUI of a callback. Then, the NetSpot GUI displays the setting result of the device configuration information by performing a bitmap display or the like based on the setting information notified of the callback from the proxy.
[0036]
FIG. 4 is a diagram illustrating an example of a screen on which the NetSpot GUI displays job information related to a predetermined management target device (hereinafter referred to as “device job information”). The NetSpot GUI performs inter-process communication using a proxy in order to acquire device job information from the device, and transmits a device job information acquisition command to the VDC. The VDC receives a device job information acquisition command via a stub, and acquires device job information from the device using a device job information acquisition protocol such as Job MIB using the SNMP protocol or IPP (Internet Printing Protocol). .
[0037]
That is, the server device in the network device management system according to the present invention transmits and receives data to and from a device using the SNMP protocol.
[0038]
The acquired device job information is transmitted from the VDC stub to the proxy using inter-process communication, and the proxy notifies the NetSpot GUI of a callback. Then, the NetSpot GUI displays a list of the device job information using a screen as shown in FIG. 4 based on the device job information notified of the callback from the proxy.
[0039]
Also, the NetSpot GUI transmits an event information notification request command to the VDC by performing inter-process communication using a proxy in order to display a change in the state of the device job information in real time. The VDC receives an event information notification request command via a stub, and registers information of the NetSpot GUI (client) as a notification destination for notifying event information.
[0040]
When the VDC acquires event information from the management target device or acquires log information indicating that a job such as printing has been completed from the management target device, the VDC responds to a client registered as a notification destination. In order to notify, first, event information is transmitted as job status change information from the stub to the proxy using inter-process communication. The proxy notifies the NetSpot GUI of callback of the received job state change information. Then, the NetSpot GUI updates the device job information in the list based on the job state change information notified of the callback.
[0041]
Hereinafter, details of the event information and log information acquisition operation related to the management target device by the NetSpot GUI and VDC will be described.
[0042]
FIG. 5 is a flowchart for explaining the event information registration operation in the VDC. First, the VDC receives an event information registration request from the NetSpot GUI (client) (step S51). Next, it is checked whether or not the device to which the event information is registered supports the log function (step S52).
[0043]
As a result, when the device supports the log function (YES), acquisition of log information from the device is started (step S53). Then, the VDC periodically acquires log information held by the device according to the number of logs that can be held inside the device. On the other hand, if the device does not support the log function (NO), or after starting acquisition of log information in step S53, it is checked whether the device supports the event function (step S54).
[0044]
As a result, if the device does not support the event function (NO), the NetSpot GUI (client) requested to register the event information is registered in the event information notification list (step S59). On the other hand, if the device supports the event function (YES), it is determined whether or not the device has already registered the event information (step S55).
[0045]
As a result, when the event information is not registered in the device, the event information is registered in the device (step S56). On the other hand, if event information has already been registered in the device, it is determined whether there is different event information (for example, event type, event property, etc.) (step S57). As a result, if there is different event information (YES), the event information is additionally registered in the device (step S58). Then, the NetSpot GUI (client) requested to register the event information is registered in the event information notification list (step S59). On the other hand, if there is no different event information (NO), the NetSpot GUI (client) requested to register the event information is registered in the event information notification list (step S59).
[0046]
FIG. 6 is a flowchart for explaining an operation of deleting registered event information in the VDC. First, the VDC receives a request to delete registered event information from the NetSpot GUI (client) (step S61). Next, the VDC deletes the NetSpot GUI (client) from the event information notification list (step S62).
[0047]
Further, it is determined whether or not there is another NetSpot GUI (client) that notifies the event information of the device managed by the client that has issued the deletion request (step S63). As a result, if there is another NetSpot GUI (client) (YES), the deletion process is terminated. On the other hand, when there is no other NetSpot GUI (client) (NO), it is determined whether or not the VDC regularly acquires log information from the device (step S64).
[0048]
As a result, when the VDC regularly acquires log information (YES), the log information acquisition operation is terminated (step S65). On the other hand, if the VDC does not regularly acquire log information (NO), or if the log information acquisition operation is terminated in step S65, whether or not event information is registered for the device. Is checked (step S66). As a result, if event information is registered (YES), a request to delete registration of event information is made to the device (step S67). On the other hand, if the event information is not registered (NO), the process ends.
[0049]
FIG. 7 is a flowchart for explaining an operation procedure when the VDC acquires event information from the managed device and notifies the NetSpot GUI of the event information. First, the VDC acquires event information from the management target device (step S71). Next, the VDC sets the number of NetSpot GUIs (number of clients) that should be notified of the event information in the internal counter (step S72). Then, it is determined whether or not the counter value is 0 (step S73). As a result, when the counter value is 0 (YES), the process is terminated. On the other hand, if the counter value is not 0 (NO), the event information is notified to the NetSpot GUI (client) (step S74). Thereafter, the counter value is decremented (step S75), and the process returns to step S73.
[0050]
FIG. 8 is a flowchart for explaining a processing procedure when event information is generated from log information acquired from a management target device by the VDC and distributed to the client. First, the VDC acquires log information from the management target device (step S81). Next, the VDC compares the acquired log information with the cached log information, extracts only the newly added log information in the managed device, and converts the log information into event information. (Step S82).
[0051]
Further, the VDC sets the number of NetSpot GUIs (number of clients) to be notified of the event information in the internal counter (step S83). Then, the VDC determines whether or not the counter value is 0 (step S84). As a result, when the counter value is 0 (YES), the process is terminated. On the other hand, if the counter value is not 0 (NO), the created event information is notified to the NetSpot GUI (client) (step S85).
[0052]
In the present embodiment, event information is transmitted to the NetSpot GUI (client) not immediately but after a predetermined time (for example, 10 seconds) has elapsed (step S86). In this event information transmission waiting process, event information is created by the internal operation of the VDC based on the log information, and event information is transmitted to the client continuously in a short time. This is done to reduce the load. Then, the counter value is decremented (step S87), and the process returns to step S84.
[0053]
In general, notification of event information from a device using a UDP packet may cause the packet to be lost due to a network failure or the like. However, the accuracy of notifying the end of the job to the NetSpot GUI (client) is improved by transmitting event information indicating the end of the job together with log information using TCP for communication with the device.
[0054]
Furthermore, the VDC is a virtual device that handles event information notification by unifying detection methods related to job completion of three types, detection by acquisition of event information, detection by acquisition of log information, and detection by combined use of event information and log information. By behaving, the NetSpot GUI (client) can process only notification of event information regardless of the type of device. In addition, the NetSpot GUI (client) does not regularly acquire log information with a large amount of data, but receives notification of event information with a small amount of data, thereby reducing the traffic of inter-process communication.
[0055]
Next, the internal operation of the NetSpot GUI (client) will be described in detail.
[0056]
FIG. 9 is a flowchart for explaining an operation procedure when the client registers and deletes event information with respect to the VDC. First, the client registers event information to be processed in the VDC (step S91). Here, the event information to be registered includes a client address, an identifier (GUID) for uniquely identifying the client, an event type indicating the type of event information, an event property indicating attribute information of each event type, and the like.
[0057]
Examples of event types include device events and job events. Furthermore, examples of event properties include job owner attributes, job names, job states, and the like, which are job event attributes. Next, the NetSpot GUI performs event callback reception processing (step S92). Then, the client deletes the registered event information (step S93).
[0058]
Here, the event callback reception process in the NetSpot GUI performed in step S92 will be further described. FIG. 10 is a flowchart for explaining processing when the client receives an event callback from the VDC. The client receives an event callback notification from the VDC (step S921). Next, the client updates display such as a display based on the received notification (step S922). FIG. 4 described above is a diagram illustrating an application when a job event is received as a display display example in the client. When the client receives the job end event, the character string indicating the job status in FIG. 4 is changed from “printing” to “printed”.
[0059]
As described above, the present invention provides a single print job end detection method based on an event for a group of devices that provide different print job end detection methods. According to the present invention, there is an effect that a client application can perform a simple operation without being aware of the type of device. In addition, in a device that supports both event information and log information, print job end detection is performed using event information and log information together, so that the effect of improving the accuracy of print job end detection can be obtained. .
[0060]
Furthermore, according to the present invention, instead of the client application periodically acquiring log information with a large amount of data, the server application converts the log information into event information with a smaller amount of data than the log. In this way, by notifying only the event information to the client application, an effect of reducing the traffic of interprocess communication can be obtained.
[0061]
Note that the present invention can be applied to a system composed of a plurality of devices (for example, a host computer, an interface device, a reader, a printer, etc.), but a device (for example, a copier, a facsimile machine, etc.) composed of a single device. You may apply to.
[0062]
Also, an object of the present invention is to supply a recording medium (or storage medium) in which a program code of software that realizes the functions of the above-described embodiments is recorded to a system or apparatus, and the computer (or CPU or Needless to say, this can also be achieved when the MPU) reads and executes the program code stored in the recording medium. In this case, the program code itself read from the recording medium realizes the functions of the above-described embodiment, and the recording medium on which the program code is recorded constitutes the present invention. Further, by executing the program code read by the computer, not only the functions of the above-described embodiments are realized, but also an operating system (OS) running on the computer based on the instruction of the program code. It goes without saying that a case where the function of the above-described embodiment is realized by performing part or all of the actual processing and the processing is included.
[0063]
Furthermore, after the program code read from the recording medium is written into a memory provided in a function expansion card inserted into the computer or a function expansion unit connected to the computer, the function is based on the instruction of the program code. It goes without saying that the CPU or the like provided in the expansion card or the function expansion unit performs part or all of the actual processing and the functions of the above-described embodiments are realized by the processing.
[0064]
When the present invention is applied to the recording medium, program code corresponding to the flowchart described above is stored in the recording medium.
[0065]
【The invention's effect】
As described above, according to the present invention, it is possible to simplify the operation of the client application and reduce the traffic of interprocess communication.
[Brief description of the drawings]
FIG. 1 is a diagram showing an overview of a network device management system and a device management system via a network including devices to be managed according to an embodiment of the present invention.
FIG. 2 is a diagram showing a configuration of a PC such as a PC 103 or a PC 121 that implements a network device management system according to the present invention.
3 is a diagram for explaining data communication using a PC 103, a PC 121, and a printer 102 connected to a LAN 100. FIG.
FIG. 4 is a diagram illustrating an example of a screen on which the NetSpot GUI displays job information related to a predetermined management target device.
FIG. 5 is a flowchart for explaining an event information registration operation in a VDC;
FIG. 6 is a flowchart for explaining an operation of deleting registered event information in a VDC.
FIG. 7 is a flowchart for explaining an operation procedure when the VDC acquires event information from a managed device and notifies the NetSpot GUI of the event information.
FIG. 8 is a flowchart for explaining a processing procedure when event information is created from log information acquired from a managed device by a VDC and distributed to a client.
FIG. 9 is a flowchart for explaining an operation procedure when a client registers and deletes event information for a VDC.
FIG. 10 is a flowchart for explaining processing when a client receives an event callback from a VDC;
[Explanation of symbols]
100 LAN
102 Printer
103, 121, 200 Personal computer
201 CPU
202 ROM
203 RAM
204 System bus
205 Keyboard controller
206 CRT controller
207 Disk controller
208 Network interface card
209 keyboard
210 CRT
211 hard disk
212 flexible disk drive

Claims

A network device management system that manages information about devices connected to a network using a client device and a server device,
The server device
Transmitting means for acquiring device configuration information of the device requested from the client device from the device, and transmitting the acquired device configuration information to the client device;
An event for actively notifying the server device of the generated event when a change occurs regarding whether or not the device supports a log function for transmitting log information in response to a request and job processing A determination means for determining whether to support the notification function;
When the determination unit determines that the device supports the event notification function, the event information indicated by the received event notification is transmitted to the client device each time an event notification is received from the device. Means for sending
When the determination unit determines that the log function is supported, the acquisition unit acquires the log information of the device for each preset period;
A means for comparing the acquired log information with the previous log information and generating event information from the changed portion;
Second transmission means for transmitting the generated event information to the client device,
The client device
First receiving means for receiving the device configuration information transmitted from the server device;
Second receiving means for receiving the event information transmitted from the server device;
Display means for displaying the device configuration information received by the first receiving means as an initial value, and the results updated using the event information received by the second receiving means as information about jobs in the device A network device management system comprising:

An information processing apparatus that notifies a client apparatus of information related to a job in a device connected on a network,
Transmitting means for acquiring device configuration information of the device requested from the client device from the device, and transmitting the acquired device configuration information to the client device;
An event for actively notifying the server device of the generated event when a change occurs regarding whether or not the device supports a log function for transmitting log information in response to a request and job processing A determination means for determining whether to support the notification function;
When the determination unit determines that the device supports the event notification function, the event information indicated by the received event notification is transmitted to the client device each time an event notification is received from the device. Means for sending
When the determination unit determines that the log function is supported, the acquisition unit acquires the log information of the device for each preset period;
A means for comparing the acquired log information with the previous log information and generating event information from the changed portion;
An information processing apparatus comprising: second transmission means for transmitting the generated event information to the client apparatus.

Receiving means for receiving an event information acquisition request for a job in the target device from a client device on the network;
A registration means for registering the client terminal of the request for acquiring the received event information in the event notification list;
3. The first and second transmission units are configured to transmit event information based on event notification or log information from the device, with a client terminal registered in the event notification list as a transmission destination. The information processing apparatus described in 1.

Furthermore, if the device in the determination means determines that supports logging, prior to registration by the registration unit, characterized in that it comprises means for acquiring the log information to be compared from the device The information processing apparatus according to claim 3.

An information processing apparatus control method for notifying a client apparatus of information related to a job in a device connected on a network,
A transmission step of acquiring device configuration information of the device requested from the client device from the device, and transmitting the acquired device configuration information to the client device;
An event for actively notifying the server device of the generated event when a change occurs regarding whether or not the device supports a log function for transmitting log information in response to a request and job processing A determination step of determining whether to support the notification function;
When it is determined in the determination step that the device supports the event notification function, the event information indicated by the received event notification is transmitted to the client device every time the event notification is received from the device. 1 transmission process;
When it is determined in the determination step that the log function is supported, an acquisition step of acquiring log information of the device for each preset period;
Compare the acquired log information with the previous log information, generate the event information from the change part,
And a second transmission step of transmitting the generated event information to the client device.

A receiving step of receiving an event information acquisition request regarding a job in the target device from the client device on the network;
A registration step of registering the client terminal of the request for acquiring the received event information in the event notification list,
Said first, second transmission step, according to claim 5, wherein the event the client terminals registered in the notification list as a transmission destination, and transmits the event information based on the event notification or log information from the device A method for controlling the information processing apparatus according to claim 1.

Further, when it is determined in the determination step that the device supports a log function, the device includes a step of acquiring log information to be compared from the device prior to registration by the registration step. control method according to claim 5 or 6.

By computer executes read, a computer program for executing the steps of any one of method claims 5 to 7.