JP4671438B2 - サーバ装置及びその制御方法 - Google Patents

Description

本発明は、コンピュータ・ネットワークに関し、特にネットワーク上に接続された各種デバイスを管理するネットワーク管理ソフトウェアを備えるサーバ装置及びその制御方法に関する。

ネットワーク上に接続された各種デバイス（以下、「ネットワークデバイス」と称す。）を管理する方法として、ＳＮＭＰ（Simple Network Management Protocol）／ＭＩＢ（Management Information Base）を使用する方法が知られている（ＳＮＭＰ／ＭＩＢの詳細に関しては、「ＴＣＰ／ＩＰネットワーク管理入門 実用的な管理をめざして」、Ｍ．Ｔ．ローズ 著／西田竹志 訳、（株）トッパン発行、１９９２年８月２０日初版を参照）。

ＳＮＭＰネットワーク管理技術によれば、ネットワーク管理システムには、少なくとも１つのネットワーク管理ステーション（ＮＭＳ）と、各々がエージェントを含むいくつかの管理対象ノードと、ネットワーク管理ステーションやエージェントが管理情報を交換するために使用するネットワーク管理プロトコルとが含まれる。そして、ユーザは、ネットワーク管理ステーション上でネットワーク管理ソフトウェアを用いて、管理対象ノード上のエージェントソフトウェアと通信することにより、ネットワークを介して管理対象に関するデータを取得し、また、そのデータを変更することができる。

また、ネットワーク上の端末間で、大容量のデータをアップロード又はダウンロードする方法として、ＦＴＰ（File Transfer Protocol）プロトコルを使用する方法がある。ＦＴＰは、ファイル転送を行う標準としてＲＦＣ（Request for Comments）９５９で定義されている。すなわち、ＲＦＣ９５９では、ＦＴＰの通信モデル、データのタイプ、ファイル構造、転送モード、ＦＴＰコマンド等が定義されている。ＦＴＰは、ＦＴＰクライアントとＦＴＰサーバとから構成され、制御コマンドを転送するコントロールセッションと、データを転送するデータセッションとの２つのセッションをクライアント／サーバ間で張ることによりファイルの転送を行うものである。

例えば、ＦＴＰは、ＦＴＰクライアントであるネットワークデバイス管理システムと、ＦＴＰサーバであるネットワークデバイスとの間で大容量データを送受信する場合にも使用される。この場合、ネットワークデバイス管理システムは、管理対象のネットワークデバイスに対してＦＴＰプロトコルを使用し、大容量データをアップデート又はダウンロードして、ネットワークデバイス内のリソースを取得し、又は変更することができる。尚、リソースの種類としては、フォントデータ、キャリブレーションデータ及びログ情報等がある。

上述したようなネットワークデバイス管理を行うためのソフトウェア（ネットワーク管理ソフトウェア）を分散環境で使用する場合、ネットワークデバイス管理機能を持つサーバアプリケーションと、各端末で起動されるクライアントアプリケーションとを用いたクライアント／サーバシステムに基づくシステム構成にすることが一般的である。

例えば、異なる端末間で、クライアントアプリケーションとサーバアプリケーションを用いてプロセス間通信を行う場合の標準として、ＲＦＣ１０５７ ＲＰＣ（Remote Procedure Call）が定義されている。このＲＰＣは、ネットワークサービスを提供する関数群をサーバ側で用意し、サーバが提供する関数をローカルマシン内の関数と同様にネットワーク上の別端末のクライアントプロセスによって呼び出せるようにしたものである。

ＲＰＣにおけるプロセス間通信の流れは次のようになる。まず、クライアントは、サーバに対するサービス要求として、サーバに用意されているＲＰＣ関数を呼び出す。この時点で、関数の呼び出し情報を格納したデータパケットがクライアントからサーバに送られ、クライアントのプログラムの実行が中断される。そして、サーバがデータパケットを受け取ると、呼び出された関数をディスパッチし、関数の引数を取り出した後、その引数に基づいてサービスを実行し、その結果をクライアントに返す。クライアントは、関数の結果を受け取った後、プログラムの実行を再開する。

尚、クライアント／サーバ間でのデータの送受信には、ネットワーク上を流れる標準的なデータ表現方法であるＸＤＲ（external Data Representation）と呼ばれる外部データ表現が用いられる。ここで、内部データ表現からＸＤＲフォーマットへの変換は「シリアライズ」と呼ばれ、ＸＤＲフォーマットから内部データ表現への変換は「デシリアライズ」と呼ばれる。尚、作成される送受信データは、関数の引数のデータサイズによって増減する。

しかしながら、上述したような従来のネットワークデバイス管理システムでは、ネットワーク管理ソフトウェアによるクライアントアプリケーションが、管理するデバイス毎に、デバイスへのログ情報の取得要求間隔や取得プロトコルといったログ情報取得要領が異なっていたので、クライアントアプリケーションの動作が複雑になるという問題があった。
本発明は、このような事情を考慮してなされたものであり、クライアントアプリケーションの動作を簡単にすることができる技術を提供することを目的とする。

また、本発明によれば、画像形成装置と通信可能であり、クライアント装置からの要求に応じて該画像形成装置の情報を該クライアント装置へ送信する、サーバ装置であって、前記画像形成装置が使用するプロトコルを判別する判別手段と、前記判別手段が判別したプロトコルに応じたプラグインモジュールをロードするロード手段と、前記ロード手段によりロードされたプラグインモジュールを使用して、前記画像形成装置に格納される画像形成に関するログ情報を取得する時間間隔を決定する際に用いる設定ファイルに含まれる取得時間間隔情報に従い指定された時間間隔で、前記画像形成装置から該ログ情報を受け取ることと、当該設定ファイルに含まれる取得時間間隔情報に従い指定された時間間隔とは異なるタイミングであって、前記画像形成装置の記憶手段におけるログ情報を保持可能な記憶容量がより小さくなるにつれて相対的に短い時間間隔で、該画像形成装置から該ログ情報を受け取ることとが可能な受信手段と、前記受信手段が受け取ったログ情報を前記クライアント装置の要求に応じて該クライアント装置へ送信する送信手段と、を備えることを特徴とするサーバ装置が提供される。

さらに、本発明にかかるサーバ装置は、取得したログ情報を一時的に記憶する一時記憶手段をさらに備え、前記送信手段が、新たに取得されたログ情報のうち、一時的に記憶されたログ情報を更新するログ情報のみを前記クライアント装置に対して送信することを特徴とする。

さらにまた、本発明にかかるサーバ装置において、前記取得手段は、所定レコード数の最新のログ情報のみを取得することを特徴とする。これによって、前記送信手段による通信量を軽減することが可能となる。

以上説明したように、本発明によれば、クライアントアプリケーションの動作を簡単にすることができる。

以下、図面を参照して、本発明の一実施形態によるネットワークデバイス管理システム及びネットワークを介して接続されるその周辺装置等について説明する。

図１は、本発明の一実施形態によるネットワークデバイス管理システム及び管理対象のデバイスを含むネットワークを介したデバイス管理システムの概要を示す図である。

図１において、ローカルエリアネットワーク（以下、「ＬＡＮ」と称す。）１００には、ネットワークボード１０１を備え、開放型アーキテクチャを持つプリンタ（デバイス）１０２と、本発明に係るネットワークデバイス管理システムのクライアント装置として機能するパーソナルコンピュータ（以下、「ＰＣ」と称す。）１０３と、プリンタ１０５に接続するＰＣ１０４と、ネットワークディスク１０７に接続するファイルサーバ１０６と、プリンタ１０９ａ、１０９ｂに接続するプリンタサーバ１０８と、本発明に係るネットワークデバイス管理システムのサーバ装置として機能するＰＣ１２１と、モデム／トランスポンダ１３０とが接続している。

また、ＬＡＮ１２０には、ＰＣ１２２と、モデム／トランスポンダ１３１に接続するバックボーン１４０とが接続している。そして、モデム／トランスボンダ１３０とモデム／トランスボンダ１３１とは、互いに広域ネットワーク（ＷＡＮ）を介して接続されている。

さらに、ＬＡＮ１１０には、ＬＡＮ１２０にも接続するモデム／トランスボンダ１３１と、ＰＣ１１０と、ＰＣ１１２と、ネットワークディスク１１４に接続するファイルサーバ１１３と、プリンタ１１６、１１７に接続するＰＣ１１５が接続している。

図２は、本発明に係るネットワークデバイス管理システムを実現するＰＣ１０３又はＰＣ１２１等のＰＣの構成を示す図である。図２に示すように、ＰＣ２００は、ＣＰＵ２０１と、ＲＯＭ２０２と、ＲＡＭ２０３と、キーボード（ＫＢ）２０９に接続するキーボードコントローラ（ＫＢＣ）２０５と、ＣＲＴ２１０に接続するＣＲＴコントローラ（ＣＲＴＣ）２０６と、ハードディスク（ＨＤ）２１１及びフレキシブルディスクドライブ（ＦＤ）に接続するディスクコントローラ（ＤＫＣ）２０７と、ＬＡＮ１００に接続するネットワークインタフェースカード（ＮＩＣ）がシステムバス２０４を介して接続されている。

尚、図２に示すＰＣ２００は、図１におけるＰＣ１０３、ＰＣ１２１だけに限らず、ＰＣ１０４、１０８、１２２、１１１、１１２、１１５も同様の構成であってもよい。図２に示すＰＣ２００におけるＨＤ２１１には、後述するすべての説明での動作主体となる本発明に係るネットワーク管理ソフトウェアに関するプログラムが格納されている。

また、ＣＰＵ２０１は、後述するすべての説明において特に断りのない限り、ハードウェア上の制御の主体である。一方、ソフトウェア上の制御の主体は、ＨＤ２１１に格納されたプログラムで実行されるネットワーク管理ソフトウェアである。尚、本実施形態においては、オペレーティングシステム（以下、「ＯＳ」と称す。）として、マイクロソフト社製のウィンドウズ（登録商標）２０００を想定しているが、これに限られるものではなく、その他のＯＳであってもよい。

尚、本実施形態におけるネットワーク管理プログラムは、フレキシブルディスクやＣＤ−ＲＯＭ等の記憶媒体に格納された形式で供給されてもよい。この場合、図２に示すＦＤ２１２又は不図示のＣＤ−ＲＯＭドライブ等によって記憶媒体に格納されたプログラムが読み取られ、ＨＤ２１１にインストールされるものであってもよい。

尚、以下の説明においては、ネットワーク管理ソフトウェアのＧＵＩ（Graphical User Interface）部分のプロセス（クライアントアプリケーション）を「ＮｅｔＳｐｏｔ ＧＵＩ」と称し、デバイスと通信する部分のプロセス（サーバアプリケーション）を「ＶＤＣ」と称す。

図３は、ＬＡＮ１００に接続されたＰＣ１０３、ＰＣ１２１及びプリンタ１０２間のプロセス通信を説明するための図である。本実施形態では、図３に示すように、ＰＣ１０３上でＮｅｔＳｐｏｔ ＧＵＩのプロセス、ＰＣ１２１上でＶＤＣのプロセスがそれぞれ起動されて、プリンタ１０２が管理される。すなわち、ＮｅｔＳｐｏｔ ＧＵＩは、プロセス間通信の機能を使用してＶＤＣとデータ通信を行い、ＶＤＣは、ＳＮＭＰプロトコルを使用して所定の管理対象デバイス（ここでは、プリンタ１０２）と通信を行う。尚、同一ＰＣ上において、ＮｅｔＳｐｏｔ ＧＵＩ及びＶＤＣのプロセスを起動してプリンタ１０２を管理するようなシステムであってもよい。この場合も、プロセス間通信等の処理は同様である。

ここで、ネットワークデバイス管理システムが、管理対象デバイスからデバイス構成情報を取得する場合の処理手順について説明する。

まず、ＰＣ１０３におけるＮｅｔＳｐｏｔ ＧＵＩによってプロキシを用いたプロセス間通信が行われ、ＶＤＣに対して取得したいデバイス構成情報を送信する。次いで、ＶＤＣは、スタブでＮｅｔＳｐｏｔ ＧＵＩから受信した情報を受け取り、ＳＮＭＰプロトコルを用いてデバイスからＭＩＢ情報を取得する。このようにして取得したデバイスＭＩＢ情報は、ＶＤＣのスタブからプロセス間通信を使用してプロキシに送信され、プロキシからＮｅｔＳｐｏｔ ＧＵＩにコールバック通知される。そして、ＮｅｔＳｐｏｔ ＧＵＩは、プロキシからコールバック通知された情報に基づいてビットマップ表示等を行うことによってデバイス構成情報を表示する。

次に、ネットワークデバイス管理システムが、管理対象デバイスに対してデバイス構成情報を設定する場合の処理手順について説明する。

まず、ＮｅｔＳｐｏｔ ＧＵＩは、プロキシを用いてプロセス間通信を行い、ＶＤＣに対して設定したいデバイス構成情報を送信する。次いで、ＶＤＣは、スタブでＮｅｔＳｐｏｔ ＧＵＩからの情報を受け取り、ＳＮＭＰプロトコルを用いてデバイスに対してデバイスＭＩＢ情報を設定する。尚、デバイスでの設定が成功したか失敗したかを示す設定情報が、ＶＤＣのスタブからプロセス間通信を使用してプロキシに送信され、プロキシからＮｅｔＳｐｏｔ ＧＵＩにコールバック通知される。そして、ＮｅｔＳｐｏｔ ＧＵＩは、プロキシからコールバック通知された情報に基づいてビットマップ表示等を行うことによってデバイス構成情報の設定結果を表示する。

図４は、ＮｅｔＳｐｏｔ ＧＵＩが所定の管理対象デバイスに関するジョブ情報（以下、「デバイスジョブ情報」と称す。）を表示する画面の一例を示す図である。ＮｅｔＳｐｏｔ ＧＵＩは、デバイスからデバイスジョブ情報を取得するためにプロキシを用いてプロセス間通信を行い、ＶＤＣに対してデバイスジョブ情報の取得命令を送信する。ＶＤＣは、スタブでデバイスジョブ情報の取得命令を受け取り、例えば、ＳＮＭＰプロトコルを用いたＪｏｂ ＭＩＢ、ＩＰＰ（Internet Printing Protocol）等のデバイスジョブ情報取得用プロトコルを用いて、デバイスからジョブ情報を取得する。

取得されたデバイスジョブ情報は、ＶＤＣのスタブからプロセス間通信を使用してプロキシに送信され、プロキシからＮｅｔＳｐｏｔ ＧＵＩにコールバック通知される。そして、ＮｅｔＳｐｏｔ ＧＵＩは、プロキシからコールバック通知されたデバイスジョブ情報に基づいて、図４に示されるような画面を用いて当該デバイスジョブ情報のリスト表示を行う。

また、ＮｅｔＳｐｏｔ ＧＵＩは、プリンタ（デバイス）１０２におけるジョブの印刷終了状態を確実に検知するために、デバイスのジョブログ情報を取得する。ＮｅｔＳｐｏｔ ＧＵＩは、プロキシを用いてプロセス間通信を行い、ＶＤＣにジョブログ情報取得要求を送信する。ＶＤＣは、スタブで受信したジョブログ情報の取得要求を受け取り、デバイスからジョブログ情報を取得する。ＶＤＣは、デバイスから取得したジョブログ情報をＮｅｔＳｐｏｔ ＧＵＩにコールバック通知し、ＮｅｔＳｐｏｔ ＧＵＩは、取得したジョブログ情報から印刷が終了しているジョブを検出して、ジョブ状態を印刷終了状態に変更する表示を行う。

図５は、ＮｅｔＳｐｏｔ ＧＵＩにおいてジョブログ情報が表示されている画面を示す図である。デバイスからジョブログ情報を取得するために、ＮｅｔＳｐｏｔ ＧＵＩは、プロキシを用いてプロセス間通信を行い、ＶＤＣにジョブログ情報の取得要求を送信する。ＶＤＣは、スタブで受信したジョブログ情報取得要求を受け取り、デバイスからジョブログ情報を取得する。そして、ＶＤＣは、デバイスから取得したジョブログ情報をＮｅｔＳｐｏｔ ＧＵＩにコールバック通知する。ＮｅｔＳｐｏｔ ＧＵＩは、取得したジョブログ情報からジョブ受付番号、ジョブ名、ジョブオーナー名、印刷ページ数、印刷時刻及び印刷結果等を検出して、印刷が終了したジョブに関する情報の一覧を表示する。

すなわち、本発明は、ネットワーク上に接続されたデバイスに関する情報をクライアント装置とサーバ装置とを用いて管理するネットワークデバイス管理システムである。そして、クライアント装置は、サーバ装置に対して、プロセス間通信によってデバイスに関するログ情報の取得を要求し、サーバ装置から取得したデバイスに関するログ情報を記憶し、デバイスに関するログ情報を表示し、新たに取得したログ情報に基づいて、表示されたデバイスに関するログ情報を変更させる。また、サーバ装置は、所定のプロトコルを用いて、デバイスに関するログ情報を取得し、クライアント装置に対して、要求されたログ情報をプロセス間通信によって送信する。

次に、図面を参照して、上述した構成のＶＤＣ（サーバ側）のジョブログ情報取得動作、ＮｅｔＳｐｏｔ ＧＵＩ（クライアント側）のジョブログ情報取得要求動作、及びＮｅｔＳｐｏｔ ＧＵＩのジョブログ情報取得要求に対するＶＤＣのレスポンス動作について詳細に説明する。

図６は、ＶＤＣによるジョブログ情報取得動作手順を説明するためのフローチャートである。以下、本実施形態では、ＶＤＣによるジョブログ情報取得動作について説明するが、ＶＤＣに関するログ情報取得動作はジョブログ情報に限るものではない。すなわち、ログ情報の種類として、ジョブログ情報以外にもデバイス内のエラー情報を示すエラーログ情報等が存在する。

図６に示すように、まず、ＶＤＣではログ情報の取得時間間隔が決定される（ステップＳ１）。図７は、ＶＤＣにおけるログ情報を取得する時間間隔を決定する手順を詳細に説明するためのフローチャートである。ログ情報を取得する時間間隔の決定手順では、図７に示すように、まず、設定ファイルにログ情報を取得する時間間隔を示す取得時間間隔情報が存在するか否かがチェックされる（ステップＳ１１）。本設定ファイルは、ＶＤＣが参照する静的な情報を格納するファイルである。その結果、取得時間間隔情報が存在する場合（ＹＥＳ）、ログ情報を取得する時間間隔を設定ファイルから読み出した値に設定する（ステップＳ１４）。

一方、ステップＳ１１において取得時間間隔情報が存在しない場合（ＮＯ）、ログ情報取得対象のデバイスがハードディスクを搭載していないか否かがチェックされる（ステップＳ１２）。その結果、デバイスがハードディスクを搭載している場合（ＮＯ）、デバイスはハードディスクサイズに応じて大量のレコード数を保持することができることになる。

一方、ハードディスクを搭載していない場合（ＹＥＳ）、デバイスはＲＡＭ上でログを実現するために少量のレコード数しか保持することができない。そこで、ハードディスクを搭載していない場合、ログ情報を取得する時間間隔を「短」に設定する（ステップＳ１５）。例えば、本実施形態では、ログ情報を取得する時間間隔を２０秒に設定する。尚、この値は、ユーザのデバイス使用頻度においてチューニングすることが可能である。

また、ステップＳ１２においてデバイスがハードディスクを搭載している場合は、次に、デバイスが保持できるレコード数が一定レコード数よりも小さいか否かがチェックされる（ステップＳ１３）。例えば、本実施形態では、２５６レコードよりも小さいかどうかをチェックする。ハードディスクを搭載しているデバイスにおいてハイエンドのデバイスは、搭載しているディスク容量が大きいので大量のログ情報を保持することができる。しかし、ローエンドのデバイスは、搭載しているディスク容量があまり大きくないので大量のレコードを保持することができない。

その結果、デバイスが保持できるレコード数が一定レコード数（２５６レコード）よりも小さい場合（ＹＥＳ）、取得の時間間隔を「中」に設定する（ステップＳ１６）。例えば、本実施形態では、ログ情報を取得する時間間隔を１分に設定する。尚、この値は、ユーザのデバイス使用頻度においてチューニングすることが可能である。

一方、デバイスが保持できるレコード数が一定レコード数（２５６レコード）よりも大きい場合（ＮＯ）、取得の時間間隔を「長」に設定する（ステップＳ１７）。例えば、本実施形態では、ログ情報を取得する時間間隔を３分に設定する。尚、この値は、ユーザのデバイス使用頻度においてチューニングすることが可能である。上述したように、本実施形態における取得する時間間隔は、デバイスのハードディスク搭載の有無及びサイズで３つのレベルに設定しているが、３つのレベル以上の複数レベルの取得の時間間隔を持つようにすることは可能である。

すなわち、本発明に係るネットワークデバイス管理システムでは、サーバ装置は、デバイスに関するログ情報を所定の取得の時間間隔で取得する。また、デバイスが保持可能なレコード数に応じて、前記時間間隔を設定する。さらに、デバイスのハードディスクの搭載の有無により取得の時間間隔が設定される。

ＶＤＣでは、ステップＳ１においてログ情報を取得する時間間隔が設定された後、デバイスからログ情報が取得される（ステップＳ２）。図８は、図６のステップＳ２におけるＶＤＣがデイバスからログ情報を取得する動作手順を詳細に説明するためのフローチャートである。

図８に示すように、ＶＤＣでは、まずＦＴＰプロトコルを使用してログ情報を取得するデバイスか否かがチェックされる（ステップＳ２１）。その結果、ＦＴＰプロトコルを使用する場合（ＹＥＳ）、使用プロトコルをＦＴＰプロトコルに設定する（ステップＳ２３）。一方、ＦＴＰプロトコルを使用しない場合（ＮＯ）、ＨＴＴＰプロトコルを使用してログ情報を取得するデバイスか否かがチェックされる（ステップＳ２２）。

その結果、ＨＴＴＰプロトコルを使用する場合（ＹＥＳ）、使用プロトコルをＨＴＴＰプロトコルに設定する（ステップＳ２５）。一方で、ＨＴＴＰプロトコルを使用しない場合（ＮＯ）、使用プロトコルを独自プロトコルに設定する（ステップＳ２４）。

ステップＳ２３、Ｓ２４、Ｓ２５の処理が行われた後、取得するログ情報のフォーマットが終了ジョブフォーマットであるか否かがチェックされる（ステップＳ２６）。その結果、終了ジョブフォーマットの場合（ＹＥＳ）、ログフォーマットを終了ジョブに設定する（ステップＳ２７）。一方、終了ジョブフォーマットでない場合（ＮＯ）、ログフォーマットを実行ジョブに設定する（ステップＳ２８）。

終了ジョブフォーマットでは、ジョブＩＤ、ジョブ名、ジョブのオーナー名、印刷開始時刻、印刷終了時刻、ジョブ終了結果及び印刷ページ数等のフィールドを持つレコードが定義されている。実行ジョブフォーマットでは、ジョブＩＤ、ジョブ名、ジョブのオーナー名、印刷開始時刻、ジョブステータス及びページ数等のフィールドを持つレコードが定義されている。本実施形態では、終了ジョブフォーマット及び実行ジョブフォーマットの２種類が扱われるが、ログ情報のフォーマットはこれに限るものではない。

さらに、使用するプロトコル、ログフォーマットの設定後、使用プロトコルに応じたプラグインモジュールがロードされる（ステップＳ２９）。そして、ロードしたプラグインモジュールを使用して、図７のフローチャートで説明したログ情報を取得する時間間隔を用いてデバイスから定期的にログ情報が取得される（ステップＳ３０）。すなわち、本発明に係るネットワークデバイス管理システムは、デバイスのログ機能に基づいて、使用可能なプロトコルが選択される。

そして、ステップＳ２においてログ情報が取得された後、ＶＤＣ内に保持していたログ情報のキャッシュが更新される（ステップＳ３）。図９は、ＶＤＣがデバイスから取得したログ情報をＶＤＣ内部のキャッシュに保存する動作手順を詳細に説明するためのフローチャートである。

ＶＤＣでは、まず取得したログ情報からキャッシュに保存すべきログ情報が抽出される（ステップＳ３１）。ジョブログ情報には、フィールドの一項目としてデバイスが選択しなかったＩＤが存在するので、取得したログの中からキャッシュに保存していないＩＤを持つレコードをキャッシュに保存すべきログ情報として抽出する。そして、それらの中からキャッシュを更新するログ情報が存在するか否かがチェックされる（ステップＳ３２）。すなわち、ネットワーク管理ソフトウェアのサーバアプリケーションにおけるログキャッシュ機能を利用することにより、クライアントアプリケーションが必要とするログ情報のみ送受信してプロセス間通信のトラフィックを軽減することができる。

すなわち、本発明に係るネットワークデバイス管理システムは、サーバ装置が、取得したログ情報を一時的に記憶し、新たに取得されたログ情報のうち、一時的に記憶されたログ情報を更新するログ情報のみをクライアント装置に対して送信する。

その結果、キャッシュを更新するログ情報が存在する場合（ＹＥＳ）、キャッシュの内容を更新する（ステップＳ３３）。一方、キャッシュを更新するログ情報が存在しない場合（ＮＯ）、処理を終了する。本実施形態では、ログ情報を保持（記憶）する手段としてＶＤＣ内部のメモリを使用したキャッシュを用いている。しかし、ログ情報を保持する手段は、ＶＤＣ内部のキャッシュに限らず、データベースのようなＶＤＣ外に存在するデータ保持手段を使用することも可能である。

すなわち、本発明に係るネットワークデバイス管理システムは、複数の管理対象デバイスが存在する場合、すべてのデバイスで同一レコード数を保持するようにしてもよい。また、デバイスが保持するログ情報のフォーマットの種類に基づいて、デバイスに関するログ情報を取得するようにしてもよい。

また、ＶＤＣは、本キャッシュ機能を用いることにより、各デバイス内で保持できるレコード数が異なる場合であっても、ＶＤＣ内部で一定量のレコード数を保持する仮想デバイスとして取り扱うことが可能である。また、いずれのデバイスにおいてもクライアントに同様の動作を提供することが可能になる。さらに、ＶＤＣのクライアントとして、サードパーティが開発するアプリケーションが存在するので、全てのデバイスにおいて共通のログ情報取得方法を提供することにより、クライアントアプリケーションの開発効率が向上する。すなわち、ネットワーク管理ソフトウェアのサーバアプリケーションが管理対象デバイスの差異を吸収した仮想デバイスとして振舞うことにより、異なるアクセス方法を提供しているデバイス群に対して共通のログ情報取得方法を提供し、クライアントアプリケーションがデバイス毎の違いを意識しない単純な動作を行うことができる。

次に、クライアント側のログ情報取得動作について説明する。図１０は、ＮｅｔＳｐｏｔ ＧＵＩ（クライアント側）のログ情報取得動作手順を説明するためのフローチャートである。図５に示すように、まずＮｅｔＳｐｏｔ ＧＵＩでは、ＶＤＣに対してログ情報の取得要求を行う時間間隔であるログ情報取得間隔に関する情報が設定ファイルに記載されているか否かがチェックされる（ステップＳ１０１）。

その結果、設定ファイルに記載がある場合（ＹＥＳ）、ＮｅｔＳｐｏｔ ＧＵＩがＶＤＣへログ情報取得要求をする時間間隔を設定ファイルに記載された値にする（ステップＳ１０２）。一方、設定ファイルに記載がない場合（ＮＯ）、ＮｅｔＳｐｏｔ ＧＵＩがＶＤＣへログ情報取得要求をする時間間隔をＶＤＣがデバイスにログ情報を取得する時間間隔より長い値を設定する（ステップＳ１０３）。本実施形態では、ログ情報取得要求をする時間間隔をＶＤＣがデバイスにログ情報を取得する時間間隔の２倍の値に設定している。しかし、ＮｅｔＳｐｏｔ ＧＵＩがＶＤＣへログ情報取得要求に行く時間間隔は、ＶＤＣがデバイスにログ情報を取得する時間間隔より長い値であればどのような値であってもよい。

次に、ＶＤＣでは最新の数レコードのみ取得するか否かがチェックされる（ステップＳ１０４）。図４に示したようなジョブの状態を変更するためにログ情報を使用する場合は、印刷が終了した最新の数レコードのみ必要であり、印刷が終了して数時間経過したレコードは必要ない。プロセス間通信の通信量を削減するために、必要な最新の数レコードのみＶＤＣに取得要求することが可能である。すなわち、本発明に係るネットワークデバイス管理システムは、所定レコード数の最新のログ情報のみを取得する。

一方、図５に示したようなデバイスの終了ジョブのログ情報一覧を表示する画面では、全てのレコードを取得する必要がある。この場合、ＶＤＣ内でデバイスにかかわらず一定量のレコード数が保持されているため、どのデバイスでも同一のレコード数を表示することができる。従って、ステップＳ１０４において最新の数レコードのみ取得する場合（ＹＥＳ）、取得フラグを最新の数レコードに設定する（ステップＳ１０５）。また、最新の数レコードのみを取得しない場合（ＮＯ）、取得フラグを全レコードに設定する（ステップＳ１０６）。そして、ステップＳ１０５及びＳ１０６において取得フラグを設定した後、ＶＤＣにログ情報取得要求を発呼する（ステップＳ１０７）。

図１１は、クライアントからログ情報取得要求があったときのＶＤＣの動作手順を説明するためのフローチャートである。図１１に示すように、まずＶＤＣは、クライアントからログ情報取得要求を受信する（ステップＳ１１１）。次いで、ＶＤＣは、キャッシュが存在するか否かをチェックする（ステップＳ１１２）。

その結果、キャッシュが存在すると判定された場合（ＹＥＳ）、取得レコード数に応じてレコードセットを作成する（ステップＳ１１４）。一方、キャッシュが存在しないと判定された場合（ＮＯ）、図５に示したＶＤＣのデバイスへのログ情報取得動作に従って、デバイスからログ情報を取得する（ステップＳ１１３）。そして、ステップＳ１１３又はＳ１１４における動作の後、ＶＤＣは、クライアントにレコードセットを返信する（ステップＳ１１５）。このとき、クライアントは、返信されたレコードセットに応じて、アプリケーションの表示を変更する。

本発明は、上述したように、複数の機器（例えば、ホストコンピュータ、インタフェース機器、リーダ、プリンタ等）から構成されるシステムに適用しても、一つの機器からなる装置（例えば、複写機、ファクシミリ装置等）に適用してもよい。

また、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記録媒体（または記憶媒体）を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムコードを読み出し実行することによっても、達成されることは言うまでもない。この場合、記録媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記録した記録媒体は本発明を構成することになる。また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているオペレーティングシステム（ＯＳ）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

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

本発明を上記記録媒体に適用する場合、その記録媒体には、先に説明したフローチャートに対応するプログラムコードが格納されることになる。

本発明の一実施形態によるネットワークデバイス管理システム及び管理対象のデバイスを含むネットワークを介したデバイス管理システムの概要を示す図である。 本発明に係るネットワークデバイス管理システムを実現するＰＣ１０３又はＰＣ１２１等のＰＣの構成を示す図である。 ＬＡＮ１００に接続されたＰＣ１０３、ＰＣ１２１及びプリンタ１０２間のプロセス通信を説明するための図である。 ＮｅｔＳｐｏｔ ＧＵＩが所定の管理対象デバイスに関するジョブ情報を表示する画面の一例を示す図である。 ＮｅｔＳｐｏｔ ＧＵＩにおいてジョブログ情報が表示されている画面を示す図である。 ＶＤＣによるジョブログ情報取得動作手順を説明するためのフローチャートである。 ＶＤＣにおけるログ情報を取得する時間間隔を決定する手順を詳細に説明するためのフローチャートである。 図６のステップＳ２におけるＶＤＣがデイバスからログ情報を取得する動作手順を詳細に説明するためのフローチャートである。 ＶＤＣがデバイスから取得したログ情報をＶＤＣ内部のキャッシュに保存する動作手順を詳細に説明するためのフローチャートである。 ＮｅｔＳｐｏｔ ＧＵＩ（クライアント側）のログ情報取得動作手順を説明するためのフローチャートである。 クライアントからログ情報取得要求があったときのＶＤＣの動作手順を説明するためのフローチャートである。

符号の説明

１００ ＬＡＮ
１０２ プリンタ
１０３、１２１、２００ パーソナルコンピュータ
２０１ ＣＰＵ
２０２ ＲＯＭ
２０３ ＲＡＭ
２０４ システムバス
２０５ キーボードコントローラ
２０６ ＣＲＴコントローラ
２０７ ディスクコントローラ
２０８ ネットワークインタフェースカード
２０９ キーボード
２１０ ＣＲＴ
２１１ ハードディスク
２１２ フレキシブルディスクドライブ

Claims (7)

1. 画像形成装置と通信可能であり、クライアント装置からの要求に応じて該画像形成装置の情報を該クライアント装置へ送信する、サーバ装置であって、
   前記画像形成装置が使用するプロトコルを判別する判別手段と、
   前記判別手段が判別したプロトコルに応じたプラグインモジュールをロードするロード手段と、
   前記ロード手段によりロードされたプラグインモジュールを使用して、前記画像形成装置に格納される画像形成に関するログ情報を取得する時間間隔を決定する際に用いる設定ファイルに含まれる取得時間間隔情報に従い指定された時間間隔で、前記画像形成装置から該ログ情報を受け取ることと、当該設定ファイルに含まれる取得時間間隔情報に従い指定された時間間隔とは異なるタイミングであって、前記画像形成装置の記憶手段におけるログ情報を保持可能な記憶容量がより小さくなるにつれて相対的に短い時間間隔で、該画像形成装置から該ログ情報を受け取ることとが可能な受信手段と、
   前記受信手段が受け取ったログ情報を前記クライアント装置の要求に応じて該クライアント装置へ送信する送信手段と、
   を備えることを特徴とするサーバ装置。
2. 受け取ったログ情報を一時的に記憶する一時記憶手段をさらに備え、
   前記送信手段が、新たに受け取ったログ情報のうち、一時的に記憶されたログ情報を更新するログ情報のみを前記クライアント装置に対して送信する
   ことを特徴とする請求項１に記載のサーバ装置。
3. 前記受信手段は、所定レコード数の最新のログ情報のみを受け取ることを特徴とする請求項１又は２に記載のサーバ装置。
4. 画像形成装置と通信可能であり、クライアント装置からの要求に応じて該画像形成装置の情報を該クライアント装置へ送信する、サーバ装置の制御方法であって、
   判別手段が、前記画像形成装置が使用するプロトコルを判別する判別工程と、
   ロード手段が、前記判別工程において判別されたプロトコルに応じたプラグインモジュールをロードするロード工程と、
   受信手段が、前記ロード工程においてロードされたプラグインモジュールを使用して、前記画像形成装置に格納される画像形成に関するログ情報を取得する時間間隔を決定する際に用いる設定ファイルに含まれる取得時間間隔情報に従い指定された時間間隔、又は、当該設定ファイルに含まれる取得時間間隔情報に従い指定された時間間隔とは異なるタイミングであって、前記画像形成装置の記憶手段におけるログ情報を保持可能な記憶容量がより小さくなるにつれて相対的に短い時間間隔で、前記画像形成装置から該ログ情報を受け取る受信工程と、
   送信手段が、前記受信工程において受け取ったログ情報を前記クライアント装置からの要求に応じて該クライアント装置へ送信する送信工程と、
   を備えることを特徴とするサーバ装置の制御方法。
5. 前記サーバ装置が、受け取ったログ情報を一時的に記憶する一時記憶手段をさらに備えており、
   前記送信工程においては、新たに受け取ったログ情報のうち、一時的に記憶されたログ情報を更新するログ情報のみが前記クライアント装置に対して送信される
   ことを特徴とする請求項４に記載のサーバ装置の制御方法。
6. 前記受信工程においては、所定レコード数の最新のログ情報のみが受け取られることを特徴とする請求項４又は５に記載のサーバ装置の制御方法。
7. コンピュータを請求項１乃至３のいずれか１項に記載のサーバ装置として機能させるためのコンピュータプログラム。

Images