JP2003006068A - ネットワークデバイス管理装置、管理方法及び管理プログラム - Google Patents

Abstract

(57)【要約】 【課題】 ネットワークデバイスからの応答が全く無く
なった場合でにも、適宜、電子メールにてネットワーク
デバイスの状態をユーザに通知する。 【解決手段】 ネットワークデバイスに対して、所定の
タイミングで応答要求命令を送信し、前記応答要求命令
に対する前記ネットワークデバイスの応答状態を記憶し
ておく。前回の応答状態を記憶手段から読み出し（Ｓ８
０１)、応答ありかを判定し（Ｓ８０２）、応答ありで
あれば、さらに今回も応答ありかを判定する（Ｓ８０
３）。ここで、応答がなくなっていれば、デバイスの応
答が無くなった旨の電子メールを作成し（Ｓ８０４）、
送信する（Ｓ８０７）。一方で、前回は応答が無かった
のに、今回は応答が帰ってきた場合は（Ｓ８０５）、デ
バイスが回復した旨の電子メールを作成し（Ｓ８０
４）、送信する（Ｓ８０７）。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本願発明は、コンピュータネ
ットワークに接続された各種ネットワークデバイスを管
理する技術に係り、とりわけ、ネットワークデバイス管
理装置、管理方法及び管理プログラムに関する。

【０００２】

【従来の技術】複数のコンピュータをＬＡＮ（ローカル
エリアネットワーク）によって相互に接続することで、
オフィス等ではネットワーク化が進んでいる。ＬＡＮ
は、ビルの１フロアに配置されている複数のコンピュー
タをネットワーク化するだけでなく、ビル全体、ビル群
（構内）、地域、あるいは国境を越えて存在する多数の
コンピュータをもネットワーク化することがある。さら
に、ＬＡＮ同士を相互に接続することでより大きなネッ
トワークが構成されたり、ときにはインターネット等と
接続されたりすることもある。また、ＬＡＮにはコンピ
ュータだけでなく、プリンタなど様々な情報処理機器が
接続される。このように、ＬＡＮには、複数の情報処理
機器が接続さているため、その規模に応じた管理が必要
となる。

【０００３】ＳＯＨＯ（スモール・オフィス・ホーム・
オフィス）などの小規模なＬＡＮであれば、ユーザ自身
が機器を取り替えたり、ソフトウェアをインストールし
たり、また問題点を診断したりすることができるため、
とりわけ、システム管理責任者などを配置して、厳密に
ネットワークを保守・管理する必要性は乏しい。

【０００４】しかし、複雑な構成のＬＡＮや、多数のＬ
ＡＮが相互に接続されてなる大規模なＬＡＮグループで
は、機器の増設や除去、ソフトウェアの更新、および障
害監視などを絶えず行う必要がある。そのため、より高
度な「管理」が必要となる。ここで、「管理」とは、一
般に、ネットワーク管理者による管理と、ネットワーク
管理者が使用するソフトウェアやハードウエアによる管
理との双方を意味するが、本願においては、システム全
体を管理するためのソフトウェアによる管理を特に意味
することがある。また、「ユーザ」とはネットワークデ
バイス管理ソフトウェアを使用する人を意味するものと
する。このユーザは、通常、システム管理責任者であ
る。ユーザは、ネットワークデバイス管理ソフトウェア
を使用して、ネットワーク上に接続された各種機器から
管理データを取得し、この管理データを変更することが
できる。いずれのネットワークであっても、ネットワー
クを円滑に運用するためには保守等の管理が必要とな
る。

【０００５】

【発明が解決しようとする課題】ところで、本願発明に
関連する技術として、ネットワークデバイス管理ソフト
ウェアによって実現されるデバイス監視モジュールが、
予め設定された周期で、定期的に管理対象デバイスから
状態を取得し、取得された状態の内容が異常を示してい
た場合には、管理対象デバイスに異常が発生している旨
の電子メールを生成して、ユーザに送信するものがあ
る。

【０００６】しかしながら、この関連技術においては、
取得された状態の内容に基づいて、異常か正常かを判断
していたため、仮に、管理対象デバイスからの応答がな
かった場合には、判断の対象が存在しないことになり、
管理対象デバイスに異常が発生したとはみなさず、電子
メールでの通知をしていなかった。

【０００７】ちなみに、状態の問い合わせに対して、管
理対象デバイスが応答を返さない状態というのは、(1)
管理対象デバイスの電源が落ちている場合、(2) 管理対
象デバイスのネットワークケーブルが抜けている場合、
(3) 管理対象デバイスに致命的な異常が発生している場
合、といったように、重大な異常が発生している場合が
考えられ、このような異常状態が通知されないのは問題
となることが多かった。

【０００８】

【課題を解決するための手段】上記課題を解決すべく、
本願発明は、ネットワークに接続されたネットワークデ
バイスを管理するネットワークデバイスの管理装置であ
って、前記ネットワークデバイスに対して、所定のタイ
ミングで応答要求命令を送信する送信手段と、前記応答
要求命令に対する前記ネットワークデバイスの応答状態
の変化を検出する検出手段と、前記検出手段において応
答状態の変化が検出されると、所定のメールアドレスに
対して、前記検出手段の検出結果に対応する電子メール
を送信する電子メール送信手段とを含むことを特徴とす
るネットワークデバイスの管理装置を提供する。

【０００９】なお、前記検出手段は、前記応答要求命令
に対する前記ネットワークデバイスからの応答の連続性
が変化した場合に前記応答状態に変化があったと検出す
るように構成してもよい。

【００１０】また、前記検出手段の検出結果に対応する
電子メールを作成する電子メール作成手段をさらに備
え、前記電子メール送信手段は、電子メール作成手段に
より作成された前記電子メールを送信するようにネット
ワークデバイスの管理装置を構成してもよい。

【００１１】また、前記検出手段は、前記応答要求命令
に対して応答を送信していたネットワークデバイスから
の応答が途絶えた場合に前記応答状態に変化があったと
検出し、前記電子メール作成手段は、前記ネットワーク
デバイスに障害が生じたことを意味する電子メールを作
成するようにネットワークデバイスの管理装置を構成し
てもよい。

【００１２】また、前記検出手段は、前記応答要求命令
に対して応答を送信してこなかったネットワークデバイ
スから、応答が送信されてきた場合に前記応答状態に変
化があったと検出し、前記電子メール作成手段は、前記
ネットワークデバイスの状態が回復したことを意味する
電子メールを作成するようにネットワークデバイスの管
理装置を構成してもよい。

【００１３】前記検出手段は、前記ネットワークデバイ
スの過去の応答状態を少なくとも１つ記憶する記憶手段
と、前記過去の応答状態と現在の応答状態とを比較し、
双方が一致しない場合に応答状態が変化したと判定する
判定手段とを含むようにネットワークデバイスの管理装
置を構成してもよい。

【００１４】さらに、上記課題を解決すべく、本願発明
は、ネットワークに接続されたネットワークデバイスを
管理するネットワークデバイスの管理装置であって、前
記ネットワークデバイスに対して、所定のタイミングで
応答要求命令を送信する送信手段と、前記ネットワーク
デバイスが前記応答要求命令に応答して応答情報を送信
してきた場合に該応答情報を受信する受信手段と、前記
受信手段において前記応答情報が受信されたか否かを判
定する判定手段と、所定のメールアドレスに対して、前
記判定手段の判定結果に対応する電子メールを作成する
電子メール作成手段と、前記電子メール作成手段により
作成された前記電子メールを送信する電子メール送信手
段と、を含むことを特徴とするネットワークデバイスの
管理装置を提供する。

【００１５】また、前記判定手段により前記応答情報は
受信されなかったと判定されると、前記電子メール作成
手段は、前記ネットワークデバイスは応答しなくなった
ことを表す内容の電子メールを作成するようにネットワ
ークデバイスの管理装置を構成してもよい。

【００１６】また、前記送信手段は、前記応答要求命令
に対して応答しなくなった前記ネットワークデバイスに
対しても応答要求命令を送信し、前記判定手段は、前記
応答要求命令に対して応答しなくなった前記ネットワー
クデバイスから、再び、前記応答情報が送信され、前記
受信手段により受信されるようになったか否かを判定
し、前記判定手段により前記応答情報が再び受信される
ようになったと判定されると、前記電子メール作成手段
は、前記ネットワークデバイスが回復したことを表す内
容の電子メールを作成するようにネットワークデバイス
の管理装置を構成してもよい。

【００１７】また、前記判定手段による判定結果を時系
列的に記憶する記憶手段と、前記記憶手段により記憶さ
れた時間的に相前後する第１の判定結果と第２の判定結
果との間の変化を検出する検出手段と、をさらに備え、
前記検出手段において変化が検出されると、前記電子メ
ール作成手段は、前記変化に応じた内容の電子メールを
作成するようにネットワークデバイスの管理装置を構成
してもよい。

【００１８】前記判定手段による判定結果のうち、少な
くとも前回の判定結果を蓄積する蓄積手段と、前記蓄積
手段により蓄積されている前回の判定結果（第１の判定
結果）と、今回の判定結果（第２の判定結果）との間の
変化を検出する検出手段と、をさらに備え、前記検出手
段において変化が検出されると、前記電子メール作成手
段は、前記変化に応じた内容の電子メールを作成するよ
うにネットワークデバイスの管理装置を構成してもよ
い。

【００１９】前記第１の判定結果において前記応答情報
は受信されたとの判定結果であったものが、前記第２の
判定結果において前記応答情報は受信されなかったとの
判定結果に変化したことを、前記検出手段が検出する
と、前記電子メール作成手段は、前記ネットワークデバ
イスは応答しなくなったことを表す内容の電子メールを
作成するようにネットワークデバイスの管理装置を構成
してもよい。

【００２０】前記第１の判定結果において前記応答情報
が受信されなかったとの判定結果であったものが、前記
第２の判定結果において前記応答情報は受信されたとの
判定結果に変化したことを、前記検出手段が検出する
と、前記電子メール作成手段は、前記ネットワークデバ
イスが回復したことを表す内容の電子メールを作成する
ようにネットワークデバイスの管理装置を構成してもよ
い。

【００２１】また、前記応答情報には、前記ネットワー
クデバイスの状態に関する情報が含まれているようにネ
ットワークデバイスの管理装置を構成してもよい。

【００２２】ここで、所定のタイミングは、たとえば、
定期的なタイミングであってもよいし、任意のタイミン
グであってもよい。要するに、本願発明では送信した応
答要求命令に対して返答が帰ってくるか否かを判定でき
ればよいのである。ただし、保守管理は、定期的に行う
ことが多いため、前者のほうが都合がよいかもしれな
い。

【００２３】

【発明の実施の形態】［共通の実施形態］以下、管理が
必要な大規模なネットワークの一例について説明する。
図１は、開放型アーキテクチャを備えるプリンタ１０２
に、ＮＢ（ネットワークボード）１０１を接続した状況
を示す図である。ＮＢ１０１は、例えば、同軸コネクタ
を備えるＥｔｈｅｒｎｅｔインタフェース１０Ｂａｓｅ
−２や、ＲＪ−４５を備える１０Ｂａｓｅ−Ｔ等のＬＡ
Ｎインタフェースを介して、ＬＡＮ１００に接続されて
いる。

【００２４】ＬＡＮ１００には、さらに、ＰＣ（パーソ
ナルコンピュータ）１０３やＰＣ１０４等も接続されて
おり、ネットワークオペレーティングシステムの制御の
下、これらのＰＣはＮＢ１０１と通信することができ
る。ＰＣの１つ、例えばＰＣ１０３を、ネットワーク管
理部として使用するように指定することができる。ＰＣ
に、ＰＣ１０４に接続されているプリンタ１０５のよう
なプリンタを接続してもよい。

【００２５】また、ＬＡＮ１００には、ファイルサーバ
１０６が接続されており、ファイルサーバ１０６には、
大容量のネットワークディスク１０７が接続されてい
る。ネットワークディスク１０７には複数のファイルが
記憶されており、ＰＣがこれらのファイルにアクセスす
る際には、ファイルサーバ１０６がこれらのアクセスを
管理する。プリントサーバ１０８は、プリンタ１０９ａ
および１０９ｂ、または遠隔地にあるプリンタ１０５な
どのプリンタに印刷を行わせる。電子メールサーバ１１
７は、電子メールを集配する役割を備えるサーバであ
り、電子メールアドレスを備えるユーザがＰＣ１０３、
ＰＣ１０４などのクライアントから電子メールサーバに
接続した際に、ユーザから送信された電子メールを他の
電子メールサーバに送信したり、他の電子メールサーバ
から配信された電子メールを各ユーザに振り分けたりす
るように機能する。また他の図示しない周辺機器をＬＡ
Ｎ１００に接続してもよい。

【００２６】更に詳しくは、図１に示すネットワーク
は、様々なネットワークメンバー間で効率良く通信を行
うために、Ｎｏｖｅｌｌ社のＯＳやＵＮＩＸ （登録商
標）ＯＳなどのネットワークソフトウェアを使用するこ
とができる。本願発明は、ネットワークソフトウェアに
よって依存するものではなく、どのようなネットワーク
ソフトウェアを使用することも可能であるが、ここで
は、一例として、Ｎｏｖｅｌｌ社のＮｅｔＷａｒｅ（Ｎ
ｏｖｅｌｌ社の商標。以下省略）ソフトウェアを使用す
るものと仮定して説明する。このソフトウェアパッケー
ジに関する詳細な説明は、ＮｅｔＷａｒｅパッケージに
同梱されているオンラインドキュメンテーションを参照
のこと。これは、Ｎｏｖｅｌｌ社からＮｅｔＷａｒｅパ
ッケージとともに購入可能である。

【００２７】簡潔に説明すると、ファイルサーバ１０６
は、ＬＡＮメンバ間でデータのファイルの送受信、記
憶、キューイング又はキャッシングなどを行う際のファ
イル管理部としての役割を果たす。例えば、ＰＣ１０３
およびＰＣ１０４のそれぞれによって作られたデータフ
ァイルは、ファイルサーバ１０６へ送られ、ファイルサ
ーバ１０６はこれらのデータファイルを順に並べ、そし
てプリントサーバ１０８からのコマンドに従って、並べ
られたデータファイルをプリンタ１０９ａへ送信する。

【００２８】ＰＣ１０３とＰＣ１０４はそれぞれ、パー
ソナルコンピュータであり、データファイルを生成した
り、ＬＡＮ１００を介して生成したデータファイルを送
信したり、ＬＡＮ１００を通じてファイルを受信した
り、ファイルを表示したりする。図１には、パーソナル
コンピュータが示されているが、ネットワークソフトウ
ェアを実行する他のコンピュータ機器が含まれていても
よい。例えば、ネットワークソフトウェアがＵＮＩＸ
ＯＳの場合は、他のコンピュータ機器としてＵＮＩＸワ
ークステーションがネットワークに接続される。

【００２９】通常、ＬＡＮ１００などは、ある建物内の
１フロアまたは連続した複数階に存在するユーザグルー
プ等、幾分ローカルなユーザグループにサービスを提供
する。一方、ユーザが他の建物や他県にも存在する場合
は、ＷＡＮ（ワイドエリアネットワーク）を構成しても
よい。ＷＡＮは、基本的に、いくつかのＬＡＮをＩＳＤ
Ｎ（高速度サービス総合デジタルネットワーク）等のデ
ジタルラインで接続して形成された集合体である。ＷＡ
Ｎの一例を図１に示すと、ＬＡＮ１００、ＬＡＮ１１０
及びＬＡＮ１２０は、ＭＯＤＥＭ（変調／復調）／ルー
タ１３０およびバックボーン１４０を介して、相互に接
続され、ＷＡＮを形成する。これらの接続は、数本のバ
スによる単純な電気的接続である。

【００３０】ＬＡＮには必ずしも必要なわけではない
が、ファイルサーバ、プリントサーバ及び電子メールサ
ーバが含まれてもよい。従って、図１に示すように、Ｌ
ＡＮ１１０は、ＰＣ１１１と、ＰＣ１１２と、ファイル
サーバ１１３と、ネットワークディスク１１４と、プリ
ントサーバ１１５と、プリンタ１１６ａおよびプリンタ
１１６ｂを含む。対照的に、ＬＡＮ１２０はＰＣ１２１
とＰＣ１２２のみを含む。ＬＡＮ１００と、ＬＡＮ１１
０と、ＬＡＮ１２０とに接続されている機器は、ＷＡＮ
接続を介して、他のＬＡＮ機器の機能にアクセスするこ
とができる。

【００３１】前述のような大規模ネットワーク上のデバ
イスを管理する方法として、これまでにいくつかの試み
が数多くの標準機関でなされている。たとえば、ＩＳＯ
（国際標準化機構）はＯＳＩ（開放型システム間相互接
続）モデルと呼ばれる汎用基準フレームワークを提供し
ている。ネットワーク管理プロトコルのＯＳＩモデル
は、ＣＭＩＰ（共通管理情報プロトコル）と呼ばれる。
ＣＭＩＰはヨーロッパの共通ネットワーク管理プロトコ
ルである。

【００３２】米国においては、より共通性の高いネット
ワーク管理プロトコルとして、ＳＮＭＰ（簡易ネットワ
ーク管理プロトコル）と呼ばれるＣＭＩＰの一変種が存
在する。ＳＮＭＰに関しては、「ＴＣＰ／ＩＰネットワ
ーク管理入門 実用的な管理をめざして」Ｍ．Ｔ．ロー
ズ 著／西田竹志 訳（株）トッパン発行１９９２年８月
２０日初版を参照のこと。ＳＮＭＰネットワーク管理技
術によれば、ネットワーク管理システムには、少なくと
も１つのネットワーク管理ステーション、管理対象ノー
ド、管理対象ノードに備えられたエージェントおよびネ
ットワーク管理ステーションやエージェントが管理情報
を交換するために使用するネットワーク管理プロトコル
が含まれる。ユーザは、ネットワーク管理ステーション
上でネットワークデバイス管理ソフトウェアを用いて管
理対象ノード上のエージェントソフトウェアと通信する
ことにより、ネットワーク上のデータを得、またデータ
を変更することができる。

【００３３】エージェントとは、各々のターゲット装置
についてのバックグラウンドプロセスとして走るソフト
ウェアである。ユーザがネットワーク上の装置に対して
管理データを要求すると、管理ソフトウェアはオブジェ
クト識別情報を管理パケットまたはフレームに入れてタ
ーゲットエージェントへ送り出す。エージェントは、そ
のオブジェクト識別情報を解釈して、そのオブジェクト
識別情報に対応するデータを取り出し、そのデータをパ
ケットに入れてユーザに送り返す。時には、データを取
り出すために対応するプロセスが呼び出される場合もあ
る。

【００３４】エージェントは、自分の状態に関するデー
タをデータベースの形式で保持している。このデータベ
ースのことをＭＩＢ（管理情報ベース）と呼ぶ。図２
は、ＭＩＢの構造を示す概念図である。図２に示すよう
に、ＭＩＢは木構造のデータ構造をしており、全てのノ
ードが一意に番号付けされている。図２において、かっ
こ内に書かれている番号が、そのノードの識別子であ
る。例えば、図２においてノード４０１の識別子は"１"
である。ノード４０２の識別子は、ノード４０１の下
の"３"であるので、"１．３"と表記される。同様にし
て、ノード４０３の識別子は、"１．３．６．１．２"と
表記される。このノードの識別子のことを、オブジェク
ト識別子と呼ぶ。このＭＩＢの構造は、ＳＭＩ（管理情
報構造）と呼ばれ、ＲＦＣ１１５５「Structure and Id
entification of Management Informationfor TCP/IP-b
ased Internets」で規定されている。

【００３５】図２には、標準として規定されているＭＩ
Ｂのうち、一部のもののみを抜き出して記載してある。
４０４は、標準ＭＩＢと呼ばれ、オブジェクト群の頂点
になるノードである。標準ＭＩＢは、ＳＮＭＰで管理さ
れる機器に標準的に備えられるオブジェクト群である。
ノード４０４の下に位置するオブジェクトの詳細な構造
については、ＲＦＣ１２１３「Management Information
Base for Network Management of TCP/IP-based Inter
nets：MIB-II」に規定されている。

【００３６】４０５は、プリンタＭＩＢと呼ばれ、オブ
ジェクト群の頂点になるノードである。プリンタＭＩＢ
は、ＳＮＭＰで管理されるプリンタに標準的に備えられ
るオブジェクト群であある。ノード４０５の下に位置す
るオブジェクトの詳細な構造については、ＲＦＣ１７５
９「Printer MIB」で規定されている。

【００３７】さらに、４０６はプライベートＭＩＢと呼
ばれ、企業や団体などが独自のＭＩＢ定義を行うための
頂点となるノードである。４０７は企業拡張ＭＩＢと呼
ばれ、プライベートＭＩＢの中で企業が独自の拡張を行
うための頂点となるノードである。例えば、ある企業に
は、独自の定義を行うために企業番号として１６０２が
割り当てられており、この企業独自のＭＩＢを定義する
ための頂点ノード４０８が、企業を意味するノードであ
るノード４０７の下に位置している。この企業独自のＭ
ＩＢの頂点ノードのオブジェクト識別子は、"１．３．
６．１．４．１．１６０２"である。

【００３８】エージェントの実装例として、プリンタを
ネットワークに接続するためのネットワークボード上に
エージェントを実装することが考えられる。これによ
り、プリンタをネットワークデバイス管理ソフトウェア
による管理の対象とすることができる。ユーザは、ネッ
トワークデバイス管理ソフトウェアを用いて制御対象の
プリンタの情報を得、また状態を変更することができ
る。より具体的には、例えばプリンタの液晶ディスプレ
イに表示されている文字列を取得したり、デフォルトの
給紙カセットを変更したりすることができる。

【００３９】以下、エージェントを実装したＮＢ（ネッ
トワークボード）をプリンタに接続する実施形態につい
て説明する。

【００４０】図３は、ＮＢ１０１をプリンタ１０２にイ
ンストールした状態を示す断面図である。図３に示すよ
うに、ＮＢ１０１はネットワーク接続の為のフェースプ
レート１０１ｂを設置した印刷回路ボード１０１ａから
構成されており、コネクタ１７０を介してプリンタイン
タフェースカード１５０に接続されている。プリンタイ
ンタフェースカード１５０は、プリンタ１０２のプリン
タエンジンを直接制御する。印刷データおよびプリンタ
状態コマンドは、ＮＢ１０１からコネクタ１７０を介し
て、プリンタインタフェースカード１５０へ入力され、
また、プリンタ状態情報はプリンタインタフェースカー
ド１５０からやはりコネクタ１７０を介して得られる。
ＮＢ１０１はこの情報を、フェースプレート１０１ｂの
ネットワークコネクタを介して、ＬＡＮ１００上で通信
する。同時に、プリンタ１０２は、従来のシリアルポー
ト１０２ａおよびパラレルポート１０２ｂから、印刷デ
ータを受信することもできる。

【００４１】図３に示すように、好ましくは、ＮＢ１０
１は、プリンタ１０２の内部拡張Ｉ／Ｏスロットに内蔵
されており、ＮＢ１０１は、下に示す処理およびデータ
記憶機能を備える「埋め込まれた」ネットワークノード
となる。

【００４２】このＮＢ１０１の構成により、大きなマル
チエリアＷＡＮネットワークを統括および管理するため
の、特徴的な補助機能がもたらされる。これらの補助機
能としては、例えば、ネットワーク上の遠隔地（ネット
ワーク統括者の事務所など）からのプリンタ制御機能、
状態観察機能、各印刷ジョブ後の次のユーザに対して保
証初期環境を提供するためのプリンタ構成の自動管理機
能、およびプリンタの負荷量を特徴付け、あるいはトナ
ーカートリッジの交換スケジュールを組むためにネット
ワークを通してアクセスする機能、プリンタログまたは
使用統計を記録するための機能が含まれる。

【００４３】ＮＢ設計において重要なのは、共有メモリ
２００等の両方向インタフェースを介して、ＮＢ１０１
からプリンタ制御機能にアクセスする機能である。共有
メモリ以外に、ＳＣＳＩインタフェース等のインタフェ
ースを使用することもできる。これにより、プリンタ操
作情報をＮＢ１０１または外部ネットワークノードへ送
出することができ、さらに、このプリンタ情報に基づい
て多数の便利な補助機能プログラムが実行される。印刷
画像データおよび制御情報のブロックは、ＮＢ１０１上
にあるマイクロプロセッサ３０１によって作成されて、
共有メモリ２００に書き込まれ、そして、プリンタ１０
２によって読み込まれる。同様に、プリンタ状態情報
は、プリンタ１０２から共有メモリ２００へ送られ、そ
こからＮＢ上のマイクロプロセッサ３０１によって読み
込まれる。

【００４４】図４は、ＮＢ１０１、プリンタ１０２及び
ＬＡＮ１００の電気的接続を示すブロック図である。Ｎ
Ｂ１０１は、ＬＡＮ１００に対してはＬＡＮインタフェ
ースを介して、プリンタ１０２に対してはプリンタイン
タフェースカード１５０を介して直接接続されている。
ＮＢ１０１上にはＮＢ１０１を制御するためのマイクロ
プロセッサ３０１と、マイクロプロセッサ３０１の動作
プログラムを格納するためのＲＯＭ３０３と、マイクロ
プロセッサ３０１がプログラムを実行する際にワークエ
リアとして用いるＲＡＭ３０２と、ＮＢ１０１とプリン
タインタフェースカード１５０とが相互にデータをやり
とりするための共有メモリ２００があり、内部バスを通
じて相互に接続されている。ＮＢ１０１がＳＮＭＰのエ
ージェントとして動作するためのプログラムはＲＯＭ３
０３に格納されている。マイクロプロセッサ３０１は、
ＲＯＭ３０３に格納されたプログラムに従って動作し、
ワークエリアとしてＲＡＭ３０２を用いる。また、プリ
ンタインタフェースカード１５０と相互に通信するため
のバッファ領域として共有メモリ２００を用いる。

【００４５】プリンタインタフェースカード１５０上の
マイクロプロセッサ１５１はＮＢ１０１とのデータのア
クセスを、ＮＢ１０１に設置されている共有メモリ２０
０を介して行う。プリンタインタフェースカード１５０
上のマイクロプロセッサ１５１は、実際に印刷機構を動
かすプリンタエンジン１６０とも通信する。

【００４６】一方、ネットワークデバイス管理ソフトウ
ェアが稼動するＰＣ側について、図５を用いて説明す
る。図５は、ネットワークデバイス管理ソフトウェアが
稼動可能なＰＣの構成を示すブロック図である。

【００４７】図５において、５００は、ネットワークデ
バイス管理ソフトウェアが稼動するＰＣであり、図１に
おける１０３と同等である。ＰＣ５００は、ＲＯＭ５０
２もしくはＨＤ（ハードディスク）５１１に記憶され
た、あるいはＦＤ（フロッピー（登録商標）ディスクド
ライブ）５１２より供給されるネットワーク管理プログ
ラムを実行するＣＰＵ５０１を備え、システムバス５０
４に接続される各デバイスを総括的に制御する。

【００４８】５０３はＲＡＭで、ＣＰＵ５０１の主メモ
リ、ワークエリア等として機能する。５０５はＫＢＣ
（キーボードコントローラ）で、ＫＢ（キーボード）５
０９や不図示のポインティングデバイス等からの指示入
力を制御する。５０６はＣＲＴＣ（ＣＲＴコントロー
ラ）で、ＣＲＴ（ＣＲＴディスプレイ）５１０の表示を
制御する。５０７はＤＫＣ（ディスクコントローラ）
で、ブートプログラム、種々のアプリケーション、編集
ファイル、ユーザファイルそしてネットワーク管理プロ
グラム等を記憶するＨＤ５１１およびＦＤ５１２とのア
クセスを制御する。５０８はＮＩＣ（ネットワークイン
タフェースカード）で、ＬＡＮ１００を介して、エージ
ェントあるいはネットワーク機器と双方向にデータをや
りとりする。

【００４９】次に、本願発明のネットワークデバイス管
理ソフトウェアの構成について説明する。本願発明のネ
ットワーク管理装置は、図５に示すようなＰＣ上でネッ
トワークデバイス管理ソフトウェアを起動することによ
り実現される。ＨＤ５１１には、ネットワークデバイス
管理ソフトウェアのプログラムが格納され、ＣＰＵ５０
１と相まって後述の説明で動作主体を構成する。後述の
すべての説明において、特に断りのない限り、ハード上
の実行主体はＣＰＵ５０１である。一方、ソフトウェア
上の制御の主体は、ＨＤ５１１に格納されたネットワー
クデバイス管理ソフトウェアである。本実施形態におい
ては、ＯＳは例えば、ウィンドウズ（マイクロソフト社
製）を想定しているが、もちろん、本願発明はこれに限
られるものではない。

【００５０】なお本願に係るネットワーク管理プログラ
ムは、フロッピーディスクやＣＤ−ＲＯＭなどの記憶媒
体に格納された形で供給されても良く、その場合には図
５に示すＦＤ５１２または不図示のＣＤ−ＲＯＭドライ
ブなどによって記憶媒体からプログラムが読み取られ、
ＨＤ５１１にインストールされる。

【００５１】図６は、本願発明に係るネットワークデバ
イス管理ソフトウェアのモジュール構成図である。本願
発明に係るネットワークデバイス管理ソフトウェアは、
図５におけるＨＤ５１１に格納されており、ＣＰＵ５０
１によって実行される。その際、ＣＰＵ５０１はワーク
エリアとしてＲＡＭ５０３を使用する。

【００５２】図６において、６０１はデバイスリストモ
ジュールであり、ネットワークに接続されたネットワー
クデバイスを一覧にして表示するなどのユーザインタフ
ェースを提供する。デバイスリストモジュール６０１
は、ユーザからの指示に従って、後述の全体制御モジュ
ール６０２に対して処理要求を出したり、後述のＵＩＡ
６０６ａ、ＵＩ Ｂ６０６ｂといった他のユーザインタ
フェースを表示したりする。また、デバイスリストモジ
ュール６０１は、ネットワークデバイスを一覧にして表
示する機能の他に、ネットワークデバイスを探索するた
めのプロトコルの切り替えや、ネットワークデバイスの
探索範囲、管理対象デバイスの選択などのユーザインタ
フェースも備える。

【００５３】６０２は全体制御モジュールであり、デバ
イスリストモジュール６０１からの要求に応じて、他の
下位モジュールを統括する。

【００５４】６０３は、デバイス探索モジュールであ
り、ネットワークに接続されているネットワークデバイ
スを探索する。デバイス探索の方法の一例としては、後
述のＳＮＭＰ探索モジュール６０９を用いてネットワー
クデバイス管理ソフトウェアがインストールされている
ＰＣが接続されたネットワーク上で、所定のＭＩＢオブ
ジェクトに対してＧｅｔＲｅｑｕｅｓｔパケットをブロ
ードキャストし、前記ＧｅｔＲｅｑｕｅｓｔパケットを
受信したネットワークデバイスがＧｅｔＲｅｓｐｏｎｓ
ｅパケットを送信し、当該ＰＣのＳＮＭＰ探索モジュー
ル６０９でこのＰＣＧｅｔＲｅｓｐｏｎｓｅパケットを
受信する方法がある。デバイス探索モジュール６０３で
探索されたネットワークデバイスは、前記デバイスリス
トモジュール６０１により一覧表示される。

【００５５】６０４は、デバイス監視モジュールであ
り、前記デバイスリストモジュール６０１で選択した特
定のネットワークデバイス（以下、管理対象デバイスと
いう）の状態を監視するためのものである。デバイス監
視モジュール６０４は、管理対象デバイス状態に異常が
発生した場合、発生した異常の内容を通知するための電
子メールを作成し、予め設定された宛先に対して通知す
るものがある。管理対象デバイスの状態は、それぞれの
管理対象デバイスの状態を示す適切なＭＩＢオブジェク
トの値をＧｅｔＲｅｑｕｅｓｔパケットで問い合わせる
方法が一般的である。例えば、企業独自のＭＩＢを搭載
したネットワークプリンタの場合、プリンタの状態を示
すＭＩＢオブジェクトの値を取得することで、プリンタ
に異常（紙なし、紙づまり、カセットオープン、トナー
切れ、など）が発生しているかどうかがわかる。

【００５６】６０５は、電子メール制御モジュールであ
り、前記デバイス監視モジュール６０４が生成した電子
メールを予め設定された宛先に送信する。電子メール制
御モジュール６０５は、前記デバイス監視モジュール６
０４から渡された電子メールの内容を、所定の電子メー
ルデータの形式に変換し、後述のＷｉｎＳｏｃｋ６１４
経由で電子メールサーバ１１７に前記電子メールデータ
を送信する。

【００５７】６０６ａおよび６０６ｂは、ＵＩモジュー
ル（ＵＩ ＡおよびＵＩ Ｂ）であり、前記デバイスリス
トモジュール６０１で表示されたネットワークデバイス
の一覧から特定のネットワークデバイスを選択した場合
に、前記選択したネットワークデバイスに関する詳細な
情報を表示・設定するためのユーザインタフェースを提
供する。図６では、ＵＩモジュールとしてＵＩ Ａ６０
６ａおよびＵＩ Ｂ６０６ｂの２つのみを明記している
が、実際にはネットワークデバイス管理ソフトウェアが
対応するネットワークデバイスの種類ごとに専用のＵＩ
モジュールが存在する。

【００５８】６０７ａおよび６０７ｂは、制御モジュー
ルであり、ネットワークデバイスに関する詳細な情報を
表示・設定するために必要な、機種特有の制御を行う。
制御モジュールは、前記ＵＩモジュールごとに存在す
る。

【００５９】６０８は、ＭＩＢモジュールであり、上位
モジュールから指定されたオブジェクトキーをオブジェ
クト識別子に変換するためのモジュールである。ここで
オブジェクトキーとは、オブジェクト識別子と１対１に
対応する３２ビットの整数のことである。オブジェクト
識別子は可変長の識別子であり、ネットワークデバイス
管理ソフトウェアを実装する上で扱いが面倒なので、本
願に係るネットワークデバイス管理ソフトウェアにおい
てはオブジェクト識別子と１対１に対応する固定長の識
別子を内部的に用いている。ＭＩＢモジュール６０８よ
り上位のモジュールはこのオブジェクトキーを用いてＭ
ＩＢの情報を扱う。これにより、ネットワークデバイス
管理ソフトウェアの実装が楽になる。

【００６０】６０９は、ＳＮＭＰモジュールであり、Ｓ
ＮＭＰパケット（ＧｅｔＲｅｑｕｅｓｔ、ＧｅｔＮｅｘ
ｔＲｅｑｕｅｓｔ、ＳｅｔＲｅｑｕｅｓｔ、Ｔｒａｐ）
の送信と受信を行う。

【００６１】６１０は、共通トランスポートモジュール
であり、ＳＮＭＰデータを運搬するための下位プロトコ
ルの差を吸収するモジュールである。実際には、動作時
にユーザが選択したプロトコルに応じて、ＵＤＰハンド
ラ６１１またはＩＰＸハンドラ６１２のいずれかのモジ
ュールがデータを転送する役割を担う。なお、ＵＤＰハ
ンドラ６１１は実装としてＷｉｎＳｏｃｋ６１４を用い
ており、ＩＰＸハンドラ６１２は実装としてＮｅｔＷａ
ｒｅ６１５を用いている。なお、ＷｉｎＳｏｃｋ６１４
については、例えば「Windows Socket API v1.1」の仕
様書を参照のこと。このドキュメントは、複数箇所から
入手可能であるが、例えばマイクロソフト社製のコンパ
イラである「Microsoft Visual C/C++」に同梱されてい
る。また、ＮｅｔＷａｒｅ６１５については、例えばＮ
ｏｖｅｌｌ社から発行されている「NetWare Programme
r's Guide for C」等を参照のこと。この書籍はノベル
株式会社から購入可能である。

【００６２】６１３は、ＮｅｔＷａｒｅジョブモジュー
ルであり、ＮｅｔＷａｒｅ６１５を用いてネットワーク
サーバからプリントジョブの状況を取得する。

【００６３】以下、図面を用いて本願発明の実施形態で
あるネットワークデバイス管理ソフトウェアの動作につ
いて詳細に説明する。

【００６４】なお、後述のすべての説明において、特に
断りのない限り、ハード上の実行主体はＣＰＵ５０１で
あり、ソフトウェア上の制御の主体は、ＨＤ５１１にイ
ンストールされたネットワークデバイス管理ソフトウェ
アである。また、図１においてネットワークに接続され
たＮＢ１０１とそのネットワークボードが装着されたプ
リンタ１０２の組み合わせをネットワークデバイスと呼
ぶ。

【００６５】図７は、本願発明実施形態のネットワーク
デバイス管理ソフトウェアの一実施形態において、デバ
イス状態の監視処理の一例を示すフローチャートであ
る。

【００６６】尚、本処理は、ネットワークデバイス管理
ソフトウェアの起動時に開始され、ネットワークデバイ
ス管理ソフトウェアの終了時に停止されるものとする。
また、本実施形態において、デバイスリストモジュール
６０１に実装される管理対象デバイスを指定するための
ユーザインタフェースは予め管理対象デバイスを設定
し、ＨＤ５１１上に保存されている管理対象デバイスの
一覧が、ネットワークデバイス管理ソフトウェアの起動
時に前記ＲＡＭ５０３上のワークエリアにインデックス
参照可能な形式でロードされているものとする。

【００６７】図７において、ステップＳ７０１では、管
理対象デバイスから状態を取得する間隔を計時するため
のタイマ（以下、監視タイマという）を起動し、ステッ
プＳ７０２に進む。ステップＳ７０２では、前記ステッ
プＳ７０１で起動された監視タイマがタイムアウトした
かどうか検査し、タイムアウトした場合はステップＳ７
０３に進み（ステップＳ７０２：Ｙｅｓ）、タイムアウ
トしていない場合はステップＳ７０２に進む（ステップ
Ｓ７０２：Ｎｏ）。ステップＳ７０３では、管理対象デ
バイスをインデックス参照するための変数ｉを０に初期
化し、ステップＳ７０４に進む。ステップＳ７０４で
は、前記変数ｉの値と管理対象デバイスの数を比較し、
変数ｉの値が管理対象デバイスの数よりも小さい場合は
ステップＳ７０５に進み（ステップＳ７０４：Ｙｅ
ｓ）、それ以外の場合はステップＳ７０１に進む（ステ
ップＳ７０４：Ｎｏ）。

【００６８】ステップＳ７０５では、ｉ番目の管理対象
デバイスについて、状態を問い合わせるための要求を発
行し(情報取得ステップ)、ステップＳ７０６に進む。本
実施形態では、前記管理対象デバイスの状態を示すＭＩ
Ｂオブジェクトを取得するための、ＧｅｔＲｅｑｕｅｓ
ｔパケットを送信するものとする。ステップＳ７０６で
は、ｉ番目の管理対象デバイスについて、前記ステップ
Ｓ７０５において発行した状態の問い合わせ要求に対す
る、前記管理対象デバイスからの応答待ち時間を計時す
るためのタイマ（以下、応答待ちタイマという）を起動
し、ステップＳ７０７に進む。

【００６９】ステップＳ７０７では、ｉ番目の管理対象
デバイスについて、前記ステップＳ７０５において発行
した、状態の問い合わせ要求に対して、前記管理対象デ
バイスから応答があったかどうかを検査し、応答があっ
た場合はステップＳ７０８に進み（ステップＳ７０７：
Ｙｅｓ）、応答がない場合はステップＳ７１１に進む
（ステップＳ７０７：Ｎｏ）。本実施形態では、前記管
理対象デバイスからの応答のありなしを、前記管理対象
デバイスからのＧｅｔＲｅｓｐｏｎｓｅパケットの受信
により判断するものとする。ステップＳ７０８では、ｉ
番目の管理対象デバイスについて、前記ステップＳ７０
６で起動した応答待ちタイマを停止し、ステップＳ７０
９に進む。ステップＳ７０９では、ｉ番目の管理対象デ
バイスについて、今回の情報取得要求に対して応答があ
った旨を前記ＲＡＭ５０３上のワークエリアに記録し
（応答状況保持ステップ）、ステップＳ７１０に進む。

【００７０】ステップＳ７１０では、ｉ番目の管理対象
デバイスについて、前記管理対象デバイスの最新の状態
に関する一般的なデバイス監視処理を実行し、ステップ
Ｓ７１３に進む。ここで実行するデバイス監視処理に関
しては詳述しないが、例えば管理対象デバイスの状態が
異常であった場合に、予め設定された宛先に対して電子
メールを送信するなどの処理があげられる。

【００７１】ステップＳ７１１では、ｉ番目の管理対象
デバイスについて、前記ステップＳ７０６で起動した応
答待ちタイマがタイムアウトしたかどうか検査し、タイ
ムアウトした場合はステップＳ７１２に進み（ステップ
Ｓ７１１：Ｙｅｓ）、タイムアウトしていない場合はス
テップＳ７０７に進む（ステップＳ７１１：Ｎｏ）。ス
テップＳ７１２では、ｉ番目の管理対象デバイスについ
て、今回の情報取得要求に対して応答がなかった旨を前
記ＲＡＭ５０３上のワークエリアに記録し（応答状況保
持ステップ）、ステップＳ７１３に進む。

【００７２】ステップＳ７１３では、ｉ番目の管理対象
デバイスについて、後述の図８に示すデバイス応答状況
通知処理を実行し、ステップＳ７１４に進む。ステップ
Ｓ７１４では、ｉ番目の管理対象デバイスについて、前
記ステップＳ７０９またはステップＳ７１２でＲＡＭ５
０３上のワークエリアに記憶した最新の情報取得に対す
る応答の有無を、前記ＲＡＭ５０３上に保存されている
１つ前の情報取得に対する応答の有無に上書きして保存
し（応答状況保持ステップ）、ステップＳ７１５に進
む。ステップＳ７１５では、前記変数ｉの値を１加算
し、ステップＳ７０４に進む。

【００７３】［第１の実施形態］図８は、本願発明実施
形態のネットワークデバイス管理ソフトウェアの一実施
形態において、前記図７のステップＳ７１３で起動され
るデバイス応答状況通知処理の一例を示すフローチャー
トである。

【００７４】同図において、ステップＳ７１４で状態取
得要求に対するｉ番目の管理対象デバイスからの応答の
有無をＲＡＭ５０３上に保存したが、ステップＳ８０１
でそれを読み出し、ステップＳ８０２に進む。すなわ
ち、読み出されたのは、前回の応答結果ということにな
る。

【００７５】ステップＳ８０２では、ｉ番目の管理対象
デバイスについて、前記ステップＳ８０１において取得
した、１つ前の状態取得要求に対する応答の有無を検査
し、１つ前の状態取得要求に対する応答があった場合は
ステップＳ８０３に進み（ステップＳ８０２：Ｙｅ
ｓ）、応答がなかった場合はステップＳ８０５に進む
（ステップＳ８０２：Ｎｏ）。

【００７６】ステップＳ８０３では、ｉ番目の管理対象
デバイスについて、前記図７のステップＳ７０９または
ステップＳ７１２において記憶した、最新の状態取得要
求に対する応答の有無を検査し（応答なし検出ステッ
プ）、最新の状態取得要求に対する応答がなかった場合
はステップＳ８０４に進み（ステップＳ８０３：Ｙｅ
ｓ）、最新の要求に対する応答があった場合は本処理を
終了する（ステップＳ８０３：Ｎｏ）。

【００７７】ステップＳ８０４では、ｉ番目の管理対象
デバイスについて、当該管理対象デバイスからの応答が
なくなった旨の電子メールを生成し（応答なしメール生
成ステップ）、前記電子メール制御モジュール６１８を
介して予め設定された宛先に送信し、ステップＳ８０７
に進む。ここでは、例えば、図９に示すような内容の電
子メールを生成する。

【００７８】ステップＳ８０５では、ｉ番目の管理対象
デバイスについて、前記図７のステップＳ７０９または
ステップＳ７１２において記憶した、最新の状態取得要
求に対する応答の有無を検査し（応答回復検出ステッ
プ）、最新の状態取得要求に対する応答があった場合は
ステップＳ８０６に進み（ステップＳ８０５：Ｙｅ
ｓ）、応答がなかった場合は本処理を終了する（ステッ
プＳ８０５：Ｎｏ）。

【００７９】ステップＳ８０６では、ｉ番目の管理対象
デバイスについて、当該管理対象デバイスからの応答が
回復した旨の電子メールを生成し（応答回復メール生成
ステップ）、前記電子メール制御モジュール６１８を介
して予め設定された宛先に送信し、ステップＳ８０６に
進む。ここでは、例えば、図１０に示すような内容の電
子メールを生成する。ステップＳ８０７では、前記ステ
ップＳ８０４またはステップＳ８０６で生成した電子メ
ールを予め設定されている宛先に対して送信し（電子メ
ール送信ステップ）、本処理を終了する。

【００８０】［第２の実施形態］第１の実施形態では、
前記ステップＳ８０２およびステップＳ８０５の判断処
理によって、１つ前の情報取得処理のときから引き続き
応答がなかった場合には、管理対象デバイスからの応答
がなくなった旨の電子メールを通知しないように制御し
ていた。

【００８１】第２の実施形態では、複数回連続して応答
がなかった場合であって、前記ステップＳ８０４および
ステップＳ８０７の処理を実行し、管理対象デバイスか
らの応答がない旨のメールを継続して通知するものであ
る。

【００８２】第２の実施形態のフローチャートを図１１
に示す。ステップＳ８０５において、今回も「応答な
し」と判定されるとステップＳ９０１に進む。ステップ
Ｓ９０１では、応答なしが連続して続いた回数をカウン
トすべく、カウンタｊの値をインクリメントする。ステ
ップＳ９０２へ進み、カウンタｊの値と所定のしきい値
ｋとを比較し、回数が所定回数未満であれば、応答なし
の旨の電子メールを送付すべく、ステップ８０４へ進
む。ここで、所定のしきい値ｋは、ユーザにより任意に
設定可能である。すなわち、「応答なし」についての電
子メールがあまりにも多く到着したのでは、ユーザは煩
わしいであろうから、たとえば、しきい値ｋを数回程度
に設定するのが現実的かもしれない。ただし、応答なし
の旨を毎回通知して欲しいと望むユーザもいるかもしれ
ない。その場合は、しきい値を無限大（現実には、数千
回など、かなり大きな値）に設定すれば、ステップＳ９
０２での分岐は、常に、ステップＳ８０４に進むことに
なり、毎回、応答なしの通知がなされることになろう。
もちろん、ステップＳ９０１〜Ｓ９０３を設けずに、ス
テップ８０５のＮｏから直接、ステップＳ８０４に移行
するようにしてもよい。このようにフローチャートを組
めば、管理対象デバイスからの応答が回復するまでの
間、デバイスの状態監視の周期（前記図７のステップＳ
７０１において起動するデバイス監視タイマのタイムア
ウトのタイミング）で管理対象デバイスからの応答がな
い旨の電子メールが定期的に通知される。

【００８３】ステップＳ８０５で、応答ありの場合は、
デバイスが回復したことを意味するので、ｊを１に設定
することでカウンタの初期化を行う。カウンタの初期値
を１とするのは、Ｓ８０５においてＮｏとなる場合は、
必ず、前回も応答なしであったはずだからである。

【００８４】さて、ステップＳ９０２で、所定回数以上
（ｊ＞＝ｋ）、応答なしが連続したと判定されると、も
はや電子メールを送信することは煩わしいだけなので、
Ｓ８０４とＳ８０７はスキップして、デバイスの回復を
待つべくＳ８０１へ進む。

【００８５】以上のようにして、応答なしを通知するか
否かを、応答なしの連続度に応じて自由に設定すること
ができる。

【００８６】［第３の実施形態］第２の実施形態は、
「応答なし」通知の通知回数を自由に設定できるもので
あった。それに対して本実施形態では、「応答あり」通
知の回数を自由に設定できるようにするものである。

【００８７】図１２に、本実施形態のフローチャートを
示す。ステップＳ８０３において、今回は応答なしでは
ない（すなわち今回も応答あり）と判定されると、ステ
ップＳ１２０１に進む。ステップ１２０１で、応答あり
の回数をカウントするためのカウンタの値ｎをインクリ
メントする。なお、ｎの初期値はｊの場合と同様の理由
で１となる。ステップＳ１２０２で、応答ありが連続し
た回数ｎがｍ回未満であるか否かを判定する。ｎがｍ未
満であれば、それほど連続していないと判定し、ステッ
プＳ８０４に進み、応答ありの電子メールを作成する。
ｎがｍ以上になると、もはや電子メールの通知を行うこ
とはせず、ステップＳ８０１へと戻り、応答なしの検出
をまつ。なお、ステップＳ８０３で今回は応答なしと判
定されると、デバイスの応答がなくなる、つまり、応答
ありの連続が途絶えたことになるので、ステップ１２０
３で、カウンタｎを１に初期化する。

【００８８】［他の実施形態］以上のように、各実施形
態を説明してきたが、これらは個別に用いてもよいし、
適宜組み合わせて用いてもよい。たとえば、第２の実施
形態と、第３の実施形態を組み合わせてもよく、組み合
わせれば、応答なしと応答ありの通知回数を同時に制限
できよう。

【００８９】また、本願発明は、複数の機器（例えばホ
ストコンピュータ、インタフェース機器、リーダなど）
から構成されるシステムあるいは統合装置に適用して
も、ひとつの機器からなる装置に適用してもよい。

【００９０】前述した実施形態の機能を実現するソフト
ウェアのプログラムコードを記録した記憶媒体を、シス
テムあるいは装置に供給し、そのシステムあるいは装置
のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に
格納されたプログラムコードを読み出し実行することに
よっても、本願発明の目的が達成されることは言うまで
もない。この場合、記憶媒体から読み出されたプログラ
ムコード自体が本願発明の新規な機能を実現することに
なり、そのプログラムコードを記憶した記憶媒体は本願
発明を構成することになる。プログラムコードを供給す
るための記憶媒体としては、例えば、フロッピーディス
ク、ハードディスク、光ディスク、光磁気ディスク、Ｃ
Ｄ-ＲＯＭ、ＣＤ-Ｒ、ＤＶＤ-ＲＯＭ、磁気テープ、不
揮発性のメモリカード、ＲＯＭなどを用いることができ
る。

【００９１】また、コンピュータが読み出したプログラ
ムコードを実行することによって、前述した実施形態の
機能が実現される他、そのプログラムコードの指示に基
づき、コンピュータ上で稼動しているＯＳなどが実際の
処理の一部または全部を行い、その処理によっても前述
した実施形態の機能が実現され得る。

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

【００９３】なお、本願発明は、記憶媒体に記憶された
前述した実施形態の機能を実現するソフトウェアのプロ
グラムコードを、パソコン通信などの通信ラインを介し
て要求者にそのプログラムを配信する場合にも適用でき
ることは言うまでもない。

【００９４】上述のように、本願発明を実現すべく、コ
ンピュータにプログラムを供給する場合は、当該プログ
ラムを実行することにより、図７、８、１１又は１２の
フローチャートに従った処理が実現される。

【００９５】その他の実施形態について具体例を説明す
ると、上記で説明した本願発明に係るネットワークデバ
イス管理ソフトウェアは、外部からインストールされる
プログラム、すなわち、ネットワークデバイス管理ソフ
トウェアがＰＣ５００によって遂行される。その場合、
そのプログラムはＣＤ-ＲＯＭやフラッシュメモリやフ
ロッピーディスクなどの記憶媒体により、あるいは電子
メールやパソコン通信などのネットワークを介して、外
部の記憶媒体からプログラムを含む情報群をＰＣ５００
上にロードすることにより、ＰＣ５００に供給される場
合でも本願発明は適用されるものである。

【００９６】図１２は、記憶媒体の一例であるＣＤ-Ｒ
ＯＭのメモリマップを示す図である。９９９９はディレ
クトリ情報を記憶してある領域で、以降のインストール
プログラムを記憶してある領域９９９８およびネットワ
ークデバイス管理ソフトウェアを記憶してある領域９９
９７の位置を示している。９９９８は、インストールプ
ログラムを記憶してある領域である。９９９７は、ネッ
トワークデバイス管理ソフトウェアを記憶してある領域
である。本願発明のネットワークデバイス管理ソフトウ
ェアがＰＣ５００にインストールされる際には、まずイ
ンストールプログラムを記憶してある領域９９９８に記
憶されているインストールプログラムがシステムにロー
ドされ、ＣＰＵ５０１によって実行される。次に、ＣＰ
Ｕ５０１によって実行されるインストールプログラム
が、ネットワークデバイス管理ソフトウェアを記憶して
ある領域９９９７からネットワークデバイス管理ソフト
ウェアを読み出して、ハードディスク５１１に格納す
る。このようにして、ハードディスク５１１に格納され
たネットワークデバイス管理ソフトウェアは、適宜のタ
イミングで起動され、本願発明を実施することになる。

【発明の効果】以上説明したように、本願発明の第１の
側面によれば、管理対象デバイスからの応答がなくなっ
たときに、当該管理対象デバイスからの応答がなくなっ
た旨の電子メールを、予め設定されている宛先に通知す
ることが可能になり、管理対象デバイスに、(1) 電源が
落ちている、(2) ネットワークケーブルが外れている、
(3) 致命的な異常が発生している、といった重要な問題
が発生してことを管理者あるいはサービス担当者に通知
することが可能になるという効果がある。

【００９７】また、本願発明の第２の側面によれば、管
理対象デバイスからの応答が回復したときに、当該管理
対象デバイスからの応答が回復した旨の電子メールを、
予め設定されている宛先に通知することが可能になり、
前記管理対象デバイスからの応答がなくなった旨の電子
メールを受信していた管理者あるいはサービス担当者
が、すでに応答が回復している管理対象デバイスの状況
を確認するために、余計な時間を浪費することを回避す
ることができるという効果がある。

【００９８】さらに、本願発明の第３の側面によれば、
一般的なネットワークデバイス管理ソフトウェアのデバ
イス監視モジュールにおいて実装される情報取得処理を
応用することにより、前記管理対象デバイスからの応答
のありなしを判断することが可能になる。そのため、前
記管理対象デバイスからの応答があるかどうかを調べる
ためだけに別途情報取得要求を発行する必要がなくな
り、ネットワーク上のトラフィックおよび管理対象デバ
イスの負荷を軽減することが可能になるという効果もあ
る。もちろん、本願発明に特化して、情報取得要求や、
応答情報を定義して発明を実施してもよいことはいうま
でもない。

【図面の簡単な説明】

【図１】共通の実施形態に係るネットワーク構成を示す
図である。

【図２】ＭＩＢの構造を示す図である。

【図３】エージェントを実装したネットワークボードが
接続されたプリンタを示す図である。

【図４】ネットワークボード、プリンタ及びＬＡＮとの
電気的接続を示すブロック図である。

【図５】ネットワークデバイス管理ソフトウェアが稼動
可能なPCの構成を示す図である。

【図６】ネットワークデバイス管理ソフトウェアのモジ
ュール構成図である。

【図７】共通の実施形態に係るデバイス応答状況の監視
処理についてのフローチャートである。

【図８】第１の実施形態に係るデバイス応答状況の通知
処理についてのフローチャートである。

【図９】デバイス応答なしの場合に通知されるメールの
一例を示す図である。

【図１０】デバイスの応答が回復した場合に通知される
メールの一例を示す図である。

【図１１】第２の実施形態に係るフローチャートであ
る。

【図１２】第３の実施形態に係るフローチャートであ
る。

【図１３】本願発明のプログラムが格納された記憶媒体
の一例であるＣＤ-ＲＯＭのメモリマップを示す図であ
る。

【符号の説明】

１００…ＬＡＮ（ローカルエリアネットワーク） １０１…ＮＢ（ネットワークボード） １０１ａ…印刷回路ボード １０１ｂ…フェースプレート １０２…開放型アーキテクチャを備えるプリンタ １０２ａ…シリアルポート １０２ｂ…パラレルポート １０３…ＬＡＮ１００に接続されているＰＣ（パーソナ
ルコンピュータ） １０４…ＬＡＮ１００に接続されているＰＣ（パーソナ
ルコンピュータ） １０５…ＰＣ１０４に接続されているプリンタ １０６…ＬＡＮ１００に接続されているファイルサーバ １０７…ＬＡＮ１００に含まれるネットワークディスク １０８…ＬＡＮ１００に含まれるプリントサーバ １０９ａ…プリントサーバ１０８に接続されたプリンタ １０９ｂ…プリントサーバ１０８に接続されたプリンタ １１０…ＬＡＮ（ローカルエリアネットワーク） １１１…ＬＡＮ１１０に接続されているＰＣ（パーソナ
ルコンピュータ） １１２…ＬＡＮ１１０に接続されているＰＣ（パーソナ
ルコンピュータ） １１３…ＬＡＮ１１０に接続されているファイルサーバ １１４…ＬＡＮ１１０に含まれるネットワークディスク １１５…ＬＡＮ１１０に含まれるプリントサーバ １１６ａ…プリントサーバ１１０に接続されたプリンタ １１６ｂ…プリントサーバ１１０に接続されたプリンタ １１７…電子メールサーバ １２０…ＬＡＮ（ローカルエリアネットワーク） １２１…ＬＡＮ１２０に接続されているＰＣ（パーソナ
ルコンピュータ） １２２…ＬＡＮ１２０に接続されているＰＣ（パーソナ
ルコンピュータ） １３０…ＭＯＤＥＭ（変調／復調）／ルータ １４０…バックボーン １５０…プリンタインタフェースカード １５１…マイクロプロセッサ １６０…プリンタエンジン １７０…コネクタ ２００…共有メモリ ３０１…マイクロプロセッサ ３０２…マイクロプロセッサ３０１の動作プログラムを
格納するためのＲＯＭ ３０３…ワークエリアとして用いるためのＲＡＭ ４０１…ＭＩＢのノードＩＳＯ（１） ４０２…ＭＩＢのノードｏｒｇ（３） ４０３…ＭＩＢのノードｍｇｍｔ（２） ４０４…ＭＩＢのノードＭＩＢ−２（１） ４０５…ＭＩＢのノードｐｒｉｎｔｍｉｂ（４３） ４０６…ＭＩＢのノードｐｒｉｖａｔｅ（４） ４０７…ＭＩＢのノードｅｎｔｅｒｐｒｉｓｅｓ（１） ４０８…ＭＩＢのノードｃａｎｏｎ（１６０２） ５００…ネットワークデバイス管理ソフトウェアが稼動
するＰＣ ５０１…ＦＤ５１２より供給されるネットワーク管理プ
ログラムを実行するＣＰＵ ５０２…ＰＣ５００のＲＯＭ ５０３…ＰＣ５００のＲＡＭ ５０４…ＰＣ５００のシステムバス ５０５…ＰＣ５００のＫＢＣ（キーボードコントロー
ラ） ５０６…ＰＣ５００のＣＲＴＣ（ＣＲＴコントローラ） ５０７…ＰＣ５００のＤＫＣ（ディスクコントローラ） ５０８…ＰＣ５００のＮＩＣ（ネットワークインタフェ
ースカード） ５０９…ＰＣ５００のＫＢ（キーボード） ５１０…ＰＣ５００のＣＲＴ（ＣＲＴディスプレイ） ５１１…ＰＣ５００のＨＤ（ハードディスク） ５１２…ＦＤ（フロッピーディスクドライブ） ６０１…デバイスリストモジュール ６０２…全体制御モジュール ６０３…デバイス探索モジュール ６０４…デバイス監視モジュール ６０５…電子メール制御モジュール ６０６ａ…ＵＩモジュールＡ ６０６ｂ…ＵＩモジュールＢ ６０７ａ…制御モジュールＡ ６０７ｂ…制御モジュールＢ ６０８…ＭＩＢモジュール ６０９…ＳＮＭＰモジュール ６１０…共通トランスポートモジュール ６１１…ＵＤＰハンドラ ６１２…ＩＰＸハンドラ ６１３…ＮｅｔＷａｒｅジョブモジュール ６１４…ＷｉｎＳｏｃｋ ６１５…ＮｅｔＷａｒｅ

Claims (32)

【特許請求の範囲】
1. 【請求項１】ネットワークに接続されたネットワークデ
   バイスを管理するネットワークデバイスの管理装置であ
   って、 前記ネットワークデバイスに対して、所定のタイミング
   で応答要求命令を送信する送信手段と、 前記応答要求命令に対する前記ネットワークデバイスの
   応答状態の変化を検出する検出手段と、 前記検出手段において応答状態の変化が検出されると、
   所定のメールアドレスに対して、前記検出手段の検出結
   果に対応する電子メールを送信する電子メール送信手段
   と、 を含むことを特徴とするネットワークデバイスの管理装
   置。
2. 【請求項２】前記検出手段の検出結果に対応する電子メ
   ールを作成する電子メール作成手段をさらに備え、 前記電子メール送信手段は、前記電子メール作成手段に
   より作成された前記電子メールを送信することを特徴と
   する請求項１に記載のネットワークデバイスの管理装
   置。
3. 【請求項３】前記検出手段は、前記応答要求命令に対す
   る前記ネットワークデバイスからの応答の連続性が変化
   した場合に前記応答状態に変化があったと検出すること
   を特徴とする請求項１に記載のネットワークデバイスの
   管理装置。
4. 【請求項４】前記検出手段は、 前記応答要求命令に対して応答を送信してきていたネッ
   トワークデバイスからの応答が途絶えた場合に前記応答
   状態に変化があったと検出し、 前記電子メール作成手段は、 前記ネットワークデバイスに障害が生じたことを意味す
   る電子メールを作成することを特徴とする請求項３に記
   載のネットワークデバイスの管理装置。
5. 【請求項５】前記検出手段は、 前記応答要求命令に対して応答を送信してこなかったネ
   ットワークデバイスから、応答が送信されてきた場合に
   前記応答状態に変化があったと検出し、 前記電子メール作成手段は、 前記ネットワークデバイスの状態が回復したことを意味
   する電子メールを作成することを特徴とする請求項３に
   記載のネットワークデバイスの管理装置。
6. 【請求項６】前記検出手段は、 前記ネットワークデバイスの過去の応答状態を少なくと
   も１つ記憶する記憶手段と、 前記過去の応答状態と現在の応答状態とを比較し、双方
   が一致しない場合に応答状態が変化したと判定する判定
   手段と、 を含むことを特徴とする請求項１乃至請求項５の何れか
   １項に記載のネットワークデバイスの管理装置。
7. 【請求項７】ネットワークに接続されたネットワークデ
   バイスを管理するネットワークデバイスの管理装置であ
   って、 前記ネットワークデバイスに対して、所定のタイミング
   で応答要求命令を送信する送信手段と、 前記ネットワークデバイスが前記応答要求命令に応答し
   て応答情報を送信してきた場合に該応答情報を受信する
   受信手段と、 前記受信手段において前記応答情報が受信されたか否か
   を判定する判定手段と、 所定のメールアドレスに対して、前記判定手段の判定結
   果に対応する電子メールを作成する電子メール作成手段
   と、 前記電子メール作成手段により作成された前記電子メー
   ルを送信する電子メール送信手段と、 を含むことを特徴とするネットワークデバイスの管理装
   置。
8. 【請求項８】前記判定手段により前記応答情報は受信さ
   れなかったと判定されると、前記電子メール作成手段
   は、前記ネットワークデバイスは応答しなくなったこと
   を表す内容の電子メールを作成することを特徴とする請
   求項７に記載のネットワークデバイスの管理装置。
9. 【請求項９】前記送信手段は、前記応答要求命令に対し
   て応答しなくなった前記ネットワークデバイスに対して
   も前記応答要求命令を送信し、 前記判定手段は、前記応答要求命令に対して応答しなく
   なった前記ネットワークデバイスから、再び、前記応答
   情報が送信され、前記受信手段により受信されるように
   なったか否かを判定し、 前記判定手段により前記応答情報が再び受信されるよう
   になったと判定されると、前記電子メール作成手段は、
   前記ネットワークデバイスが回復したことを表す内容の
   電子メールを作成することを特徴とする請求項７乃至請
   求項８に記載のネットワークデバイスの管理装置。
10. 【請求項１０】前記判定手段による判定結果を時系列的
    に記憶する記憶手段と、 前記記憶手段により記憶された時間的に相前後する第１
    の判定結果と第２の判定結果との間の変化を検出する検
    出手段と、 をさらに備え、 前記検出手段において変化が検出されると、前記電子メ
    ール作成手段は、前記変化に応じた内容の電子メールを
    作成することを特徴とする請求項７に記載のネットワー
    クデバイスの管理装置。
11. 【請求項１１】前記判定手段による判定結果のうち、少
    なくとも前回の判定結果を蓄積する蓄積手段と、 前記蓄積手段により蓄積されている前回の判定結果（第
    １の判定結果）と、今回の判定結果（第２の判定結果）
    との間の変化を検出する検出手段と、 をさらに備え、 前記検出手段において変化が検出されると、前記電子メ
    ール作成手段は、前記変化に応じた内容の電子メールを
    作成することを特徴とする請求項７に記載のネットワー
    クデバイスの管理装置。
12. 【請求項１２】前記第１の判定結果において前記応答情
    報は受信されたとの判定結果であったものが、前記第２
    の判定結果において前記応答情報は受信されなかったと
    の判定結果に変化したことを、前記検出手段が検出する
    と、 前記電子メール作成手段は、前記ネットワークデバイス
    は応答しなくなったことを表す内容の電子メールを作成
    することを特徴とする請求項１０又は請求項１１に記載
    のネットワークデバイスの管理装置。
13. 【請求項１３】前記第１の判定結果において前記応答情
    報が受信されなかったとの判定結果であったものが、前
    記第２の判定結果において前記応答情報は受信されたと
    の判定結果に変化したことを、前記検出手段が検出する
    と、 前記電子メール作成手段は、前記ネットワークデバイス
    が回復したことを表す内容の電子メールを作成すること
    を特徴とする請求項１０又は請求項１１に記載のネット
    ワークデバイスの管理装置。
14. 【請求項１４】前記応答情報には、前記ネットワークデ
    バイスの状態に関する情報が含まれていることを特徴と
    する請求項７乃至請求項１３の何れか１項に記載のネッ
    トワークデバイスの管理装置。
15. 【請求項１５】前記所定のタイミングとは、定期的なタ
    イミングであることを特徴とする請求項１乃至請求項１
    ４のいずれか１項に記載されたネットワークデバイスの
    管理装置。
16. 【請求項１６】ネットワークに接続されたネットワーク
    デバイスを管理するためのネットワークデバイスの管理
    方法であって、 前記ネットワークデバイスに対して、所定のタイミング
    で応答要求命令を送信する送信ステップと、 前記応答要求命令に対する前記ネットワークデバイスの
    応答状態の変化を検出する検出ステップと、 前記検出ステップにおいて応答状態の変化が検出される
    と、所定のメールアドレスに対して、前記検出ステップ
    の検出結果に対応する電子メールを送信する電子メール
    送信ステップと、 を含むことを特徴とするネットワークデバイスの管理方
    法。
17. 【請求項１７】前記検出ステップの検出結果に対応する
    電子メールを作成する電子メール作成ステップをさらに
    備え、 前記電子メール送信ステップにおいて、前記電子メール
    作成ステップにより作成された前記電子メールを送信す
    ることを特徴とする請求項１６に記載のネットワークデ
    バイスの管理方法。
18. 【請求項１８】前記検出手ステップにおいて、前記応答
    要求命令に対する前記ネットワークデバイスからの応答
    の連続性が変化した場合に前記応答状態に変化があった
    と検出することを特徴とする請求項１６に記載のネット
    ワークデバイスの管理方法。
19. 【請求項１９】前記検出ステップにおいて、 前記応答要求命令に対して応答を送信してきていたネッ
    トワークデバイスからの応答が途絶えた場合に前記応答
    状態に変化があったと検出し、 前記電子メール作成ステップにおいて、 前記ネットワークデバイスに障害が生じたことを意味す
    る電子メールを作成することを特徴とする請求項１８に
    記載のネットワークデバイスの管理方法。
20. 【請求項２０】前記検出ステップにおいて、 前記応答要求命令に対して応答を送信してこなかったネ
    ットワークデバイスから、応答が送信されてきた場合に
    前記応答状態に変化があったと検出し、 前記電子メール作成ステップにおいて、 前記ネットワークデバイスの状態が回復したことを意味
    する電子メールを作成することを特徴とする請求項１８
    に記載のネットワークデバイスの管理方法。
21. 【請求項２１】前記検出ステップにおいて、 前記ネットワークデバイスの過去の応答状態を少なくと
    も１つ記憶する記憶ステップと、 前記過去の応答状態と現在の応答状態とを比較し、双方
    が一致しない場合に応答状態が変化したと判定する判定
    ステップと、 を含むことを特徴とする請求項１６乃至請求項２０の何
    れか１項に記載のネットワークデバイスの管理方法。
22. 【請求項２２】ネットワークに接続されたネットワーク
    デバイスを管理するネットワークデバイスの管理方法で
    あって、 前記ネットワークデバイスに対して、所定のタイミング
    で応答要求命令を送信する送信ステップと、 前記ネットワークデバイスが前記応答要求命令に応答し
    て応答情報を送信してきた場合に該応答情報を受信する
    受信ステップと、 前記受信ステップにおいて前記応答情報が受信されたか
    否かを判定する判定ステップと、 所定のメールアドレスに対して、前記判定ステップの判
    定結果に対応する電子メールを作成する電子メール作成
    ステップと、 前記電子メール作成ステップにより作成された前記電子
    メールを送信する電子メール送信ステップと、 を含むことを特徴とするネットワークデバイスの管理方
    法。
23. 【請求項２３】前記判定ステップにより前記応答情報は
    受信されなかったと判定されると、前記電子メール作成
    ステップにおいて、前記ネットワークデバイスは応答し
    なくなったことを表す内容の電子メールを作成すること
    を特徴とする請求項２２に記載のネットワークデバイス
    の管理方法。
24. 【請求項２４】前記送信ステップにおいて、前記応答要
    求命令に対して応答しなくなった前記ネットワークデバ
    イスに対しても応答要求命令を送信し、 前記判定ステップにおいて、前記応答要求命令に対して
    応答しなくなった前記ネットワークデバイスから、再
    び、前記応答情報が送信され、前記受信ステップにより
    受信されるようになったか否かを判定し、 前記判定ステップにより前記応答情報が再び受信される
    ようになったと判定されると、前記電子メール作成ステ
    ップにおいて、前記ネットワークデバイスが回復したこ
    とを表す内容の電子メールを作成することを特徴とする
    請求項２２乃至請求項２３に記載のネットワークデバイ
    スの管理方法。
25. 【請求項２５】前記判定ステップによる判定結果を時系
    列的に記憶する記憶ステップと、 前記記憶ステップにより記憶された時間的に相前後する
    第１の判定結果と第２の判定結果との間の変化を検出す
    る検出ステップと、 をさらに備え、 前記検出ステップにおいて変化が検出されると、前記電
    子メール作成ステップは、前記変化に応じた内容の電子
    メールを作成することを特徴とする請求項２２に記載の
    ネットワークデバイスの管理方法。
26. 【請求項２６】前記判定ステップによる判定結果のう
    ち、少なくとも前回の判定結果を蓄積する蓄積ステップ
    と、 前記蓄積ステップにより蓄積されている前回の判定結果
    （第１の判定結果）と、今回の判定結果（第２の判定結
    果）との間の変化を検出する検出ステップと、 をさらに備え、 前記検出ステップにおいて変化が検出されると、前記電
    子メール作成ステップは、前記変化に応じた内容の電子
    メールを作成することを特徴とする請求項２２に記載の
    ネットワークデバイスの管理方法。
27. 【請求項２７】前記第１の判定結果において前記応答情
    報は受信されたとの判定結果であったものが、前記第２
    の判定結果において前記応答情報は受信されなかったと
    の判定結果に変化したことを、前記検出ステップにおい
    て検出されると、 前記電子メール作成ステップにおいて、前記ネットワー
    クデバイスは応答しなくなったことを表す内容の電子メ
    ールを作成することを特徴とする請求項２５又は請求項
    ２６に記載のネットワークデバイスの管理方法。
28. 【請求項２８】前記第１の判定結果において前記応答情
    報が受信されなかったとの判定結果であったものが、前
    記第２の判定結果において前記応答情報は受信されたと
    の判定結果に変化したことを、前記検出ステップにおい
    て検出されると、 前記電子メール作成ステップにおいて、前記ネットワー
    クデバイスが回復したことを表す内容の電子メールを作
    成することを特徴とする請求項２５又は請求項２６に記
    載のネットワークデバイスの管理方法。
29. 【請求項２９】前記応答情報には、前記ネットワークデ
    バイスの状態に関する情報が含まれていることを特徴と
    する請求項１６乃至請求項２８の何れか１項に記載のネ
    ットワークデバイスの管理方法。
30. 【請求項３０】前記所定のタイミングとは、定期的なタ
    イミングであることを特徴とする請求項１６乃至請求項
    ２９のいずれか１項に記載されたネットワークデバイス
    の管理方法。
31. 【請求項３１】請求項１乃至請求項１５の何れか１項に
    記載された前記手段のそれぞれとしてコンピュータを機
    能させるためのネットワークデバイスの管理プログラ
    ム。
32. 【請求項３２】請求項１６乃至請求項２９に記載された
    前記ステップのそれぞれをコンピュータに実行させるた
    めのネットワークデバイスの管理プログラム。