JP2006024187A - 通信装置、機器メッセージ処理プログラム及び記録媒体 - Google Patents

Abstract

【課題】 ネットワークを介して接続する機器より送信される機器の状態情報を複数のアプリケーションで共有させることのできる通信装置、機器メッセージ処理プログラム及び記録媒体の提供を目的とする。
【解決手段】 複数のアプリケーションを有する通信装置であって、
ネットワークを介して接続する機器が送信する該機器の状態を示すメッセージを受信し、該メッセージの内容を示すメッセージ情報を前記複数のアプリケーションのそれぞれに通知する機器メッセージ処理手段を有するにより上記課題を解決する。
【選択図】 図５

Description

本発明は、通信装置、機器メッセージ処理プログラム及び記録媒体に関し、特にネットワーク機器を管理する通信装置、機器メッセージ処理プログラム及び記録媒体に関する。

ＴＣＰ／ＩＰネットワークにおいて、プリンタ、スキャナ、ルータ、コンピュータ、及び端末等、ネットワークに接続された通信機器をネットワーク経由で監視・制御するためのプロトコルとしてＳＮＭＰ（Simple Network Management Protocol）が知られている。ＳＮＭＰによる通信は、マネージャとエージェントとの間で行われる。マネージャとは、通信機器を監視等する側のコンピュータに実装されるソフトウェアをいう。また、エージェントとは、通信機器に実装され、マネージャに対して当該機器の状態を報告するための機能をいう。

マネージャとエージェントとの間でやりとりされるメッセージのうち、エージェント側が自らにおける障害の発生等の状態変化をマネージャに通知するメッセージとしてトラップ（ＴＲＡＰ）がある。ＴＲＡＰは、マネージャからのリクエストに対する応答としてではなく、障害等を検出したエージェントが能動的に送信するメッセージである。したがって、マネージャは、エージェントからのトラップによって、通信機器の状態変化をリアルタイムで把握することができる。
特開２００１−２３６２７９号公報

しかしながら、マネージャ側でトラップを受信するためソケットのポート番号は、一つ（１６２番）に固定されているため、一台のコンピュータにおいて複数のマネージャが起動されてしまうと、これらのマネージャによるトラップの取り合いが発生し、マネージャ間でトラップ情報の共有ができないという問題がある。すなわち、いずれかのマネージャによってパケットキューの中からトラップ情報が取得されてしまうと、他のマネージャが当該トラップを取得しようとしても、パケットキューの中には、当該トラップ情報は既に存在しないからである。その結果、各マネージャは、適切に通信機器を監視することができなくなってしまう。

本発明は、上記の点に鑑みてなされたものであって、ネットワークを介して接続する機器より送信される機器の状態情報を複数のアプリケーションで共有させることのできる通信装置、機器メッセージ処理プログラム及び記録媒体の提供を目的とする。

そこで上記課題を解決するため、本発明は、複数のアプリケーションを有する通信装置であって、ネットワークを介して接続する機器が送信する該機器の状態を示すメッセージを受信し、該メッセージの内容を示すメッセージ情報を前記複数のアプリケーションのそれぞれに通知する機器メッセージ処理手段を有することを特徴とする。

このような通信装置では、ネットワークを介して接続する機器より送信される機器の状態情報を複数のアプリケーションで共有させるができる。

また、上記課題を解決するため、本発明は、上記通信装置における機能を実現する手順を実行させるための機器メッセージ処理プログラム、又は前記機器メッセージ処理プログラムを記録した記録媒体としてもよい。

本発明によれば、ネットワークを介して接続する機器より送信される機器の状態情報を複数のアプリケーションで共有させることのできる通信装置、機器メッセージ処理プログラム及び記録媒体を提供することができる。

以下、図面に基づいて本発明の実施の形態を説明する。図１は、本発明の実施の形態における機器管理システムの構成例を示す図である。図１に示される機器管理システム１は、機器管理装置１０と、スキャナ２０ａ、プリンタ２０ｂ、プリンタ２０ｃ及びコピー機２０ｄ等の各種ネットワーク機器（以下、総称する場合「機器２０」という。）とがＬＡＮ等のネットワーク３０（有線、無線の別を問わない）によって接続されることにより構成されている。

機器管理装置１０は、機器２０の状態の監視や動作の制御等、各種の管理機能が実装されているコンピュータである。機器２０は、少なくともＳＮＭＰ（Simple Network Management Protocol）通信におけるエージェントとしての機能が実装されているネットワーク機器である。

次に、機器管理装置１０の詳細について説明する。図２は、本発明の実施の形態における機器管理装置のハードウェア構成例を示す図である。図２の機器管理装置１０は、それぞれバスBで相互に接続されているドライブ装置１００と、補助記憶装置１０２と、メモリ装置１０３と、演算処理装置１０４と、インタフェース装置１０５と、表示装置１０６と、入力装置１０７とを有するように構成される。

機器管理装置１０が利用するプログラムは、ＣＤ−ＲＯＭ等の記録媒体１０１によって提供される。プログラムを記録した記録媒体１０１は、ドライブ装置１００にセットされ、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。演算処理装置１０４は、メモリ装置１０３に格納されたプログラムに従って機器管理装置１０に係る機能を実行する。インタフェース１０５は、ネットワーク３０に接続するためのインタフェースとして用いられる。表示装置１０６は、プログラムが表示するＧＵＩ（Graphical User Interface）等を表示する。入力装置１０７はキーボード及びマウス等で構成され、様々な操作指示を入力するために用いられる。

図３は、本発明の実施の形態における機器管理装置の機能構成例を示す図である。図３において、機器管理装置１０は、一つ以上のアプリケーション１１、サービス層１７、ネットワーク層１２、及びソケットライブラリ１８等より構成され、これらはＯＳ（Operating System）１６上において動作する。

アプリケーション１１は、本実施形態では機器管理に関する各種機能を提供するアプリケーションであり、例えば、ネットワーク管理者や機器管理者といったユーザに直接利用されるものであってもよい。また、アプリケーション１１は、いわゆるＷｅｂアプリケーションでもよい。かかる意味を含めて図中では「アプリケーション／Ｗｅｂ」と示されている。

サービス層１７は、所定の業務ロジックを上位層（ここでは、アプリケーション１１）に提供するモジュール群（例えば、Ｗｅｂサービス）が実装されている層である。サービス層１７に属するモジュールとしては、例えば、機器管理サービス１７１、ＤＢサーバサービス１７２、ログサーバサービス１７３等がある。機器管理サービス１７１は、機器管理に関するサービスを提供するモジュールである。ＤＢサーバサービス１７２は、非図示のデータベースに対するアクセス機能を提供するモジュールである。ログサーバサービス１７３は、ログ情報の記録及び管理等に関する機能を提供するモジュールである。

例えば、アプリケーション１１に機器管理機能等の業務ロジックが実装されている場合、当該アプリケーション１１は、直接ネットワーク層１２を呼び出す。また、アプリケーション１１が、単にＷｅｂページの生成等、ユーザインタフェースに関する機能のみの担うようなものである場合、当該アプリケーション１１は、サービス層１７におけるモジュールを呼び出すことにより、要求された機能を実現する。例えば、機器管理に関する機能を提供するためには、機器管理サービス１７１が呼び出される。

ネットワーク層１２は、機器２０との通信機能（情報の取得や設定等）をアプリケーション１１やサービス層１７対して提供するための機能が実装されている層である。

ソケットライブラリ１８は、主にＴＣＰ／ＩＰによるネットワーク通信の制御等に関するインタフェースを提供するライブラリである。すなわち、ネットワーク層１２は、ソケットライブラリ１８を用いて機器２０とのＴＣＰ／ＩＰ通信を実現する。

ＯＳ１６は、いわゆるＯＳである。

更に、ネットワーク層１２の詳細について説明する。図４は、本発明の実施の形態におけるネットワーク層の機能構成例を示す図である。図４において、ネットワーク層１２は、共通ＡＰＩ層１３、サービス層１４、及びプロトコル層１５等より構成される。

共通ＡＰＩ層１３は、機器２０より取得する情報の種別等に依存しない抽象的なインタフェースをアプリケーション１１やサービス層１７等に対して提供するＡＰＩ（Application Program Interface）が実装されている層である。例えば、機器２０との通信を開始するための関数（Ｏｐｅｎ関数）、機器２０より情報を取得するための関数（Ｇｅｔ関数）、機器２０へ情報を設定するための関数（Ｓｅｔ関数）、機器２０との通信を終了するための関数（Ｃｌｏｓｅ関数）等が実装されている。共通ＡＰＩ層１３における各関数は、アプリケーション１１より与えられる抽象的なパラメータ（取得したい情報の種別等）や、通信を制御するためのパラメータ（タイムアウト等）に基づいて、サービス層１４を呼び出す。

サービス層１４は、機器情報サービス１４１、機器検索サービス１４２、トラップサービス１４３、宛先管理サービス１４４等、それぞれのサービスに特化した機能を提供するモジュール群によって構成される。機器情報サービス１４１は、機器２０の各種情報の取得や設定等の機能を提供するモジュールであり、機器検索サービス１４２は、ネットワーク３０に接続している機器２０の検索機能を提供するモジュールである。トラップサービス１４３は、機器２０とのＳＮＭＰ通信において機器２０が自発的に送信する機器２０の状態を示すメッセージであるトラップ（ＴＲＡＰ）を受信し、受信したトラップをアプリケーション１１に対して通知する機能を提供するモジュールである。宛先管理サービス１４４は、メールの送信等における宛先に関する情報を管理するモジュールである。サービス層１４は、共通ＡＰＩ層１３を介してアプリケーション１１より与えられる抽象的なパラメータや、プロトコルに関するパラメータ（通信に利用するプロトコルについて、その種別の指定や、自動的な判断に任せる旨の指定等）等に基づいて、プロトコル層１５を呼び出す。

プロトコル層１５は、各プロトコルに依存したインタフェースによって、当該プロトコルによる機器２０等との通信機能を上位層（ここではサービス層１４）に提供する層である。例えば、ＳＮＭＰ（Simple Network Management Protocol）、ＦＴＰ（File Transfer Protocol）、ＨＴＴＰ（HyperText Transfer Protocol）、及びＳＯＡＰ（Simple Object Access Protocol）等によって通信するためのモジュールが実装されている。

第一の実施の形態について説明する。図５は、第一の実施の形態におけるトラップサービスの機能構成例を示す図である。図５に示されるトラップサービス１４２は、クライアントモジュール１４２１及びサーバモジュール１４２２から構成される。なお、図５の機器管理アプリ１１ａは、図３におけるアプリケーション１１の具体例として、トラップサービス１４２を利用することにより機器２０の管理機能を提供するアプリケーションである。機器管理装置１０においては、複数の機器管理アプリ１１ａが並列して起動され得る。

クライアントモジュール１４２１は、実行時には、機器管理アプリ１１ａ一つに対して一つずつ個別に存在し、サーバモジュール１４２２と機器管理アプリ１１ａとの仲介役として機能するモジュールである。クライアントモジュール１４２１は、通知マネージャ１４２１ａ及びクライアント管理部１４２１ｂ等から構成される。通知マネージャ１４２１ａは、サーバモジュール１４２２によって受信されたトラップを対応する機器管理アプリ１１ａに対して通知する。クライアント管理部１４２１ｂは、機器管理アプリ１１ａに対してトラップを通知するために必要とされる各種情報を管理する。クライアント管理部１４２１ｂは、例えば、機器管理アプリ１１ａより、当該情報の登録要求、削除要求等を受け付けると共に、通知マネージャ１４２１ａより、当該情報の取得開始要求、取得中断要求、取得終了要求等を受け付ける。

サーバモジュール１４２２は、機器２０からのトラップを受信するためのモジュールであり、機器２０との通信がＳＮＭＰによる場合は、ＳＮＭＰマネージャとして機能する。サーバモジュール１４２２は、実行時には、独立したプロセスとして機器管理装置１０において一つ生成され、複数のクライアントモジュール１４２１より共通的に利用される。サーバモジュール１４２２は、トラップ監視部１４２２ａ、クライアント管理部ディスパッチャ１４２２ｂ及びトラップ監視スレッド１４２２ｃ等から構成される。

トラップ監視部１４２２ａは、機器２０からのトラップを受信するための唯一のソケット（ポート）を介してトラップを受信する。クライアント管理部ディスパッチャ１４２２ｂは、クライアントモジュール１４２１より当該クライアントモジュール１４２１を識別するための情報等の登録を受け付ける等、クライアントモジュール１４２１とのやり取りを管理又は制御する。トラップ監視スレッド１４２２ｃは、クライアント管理部ディスパッチャ１４２２ｂによってクライアントモジュール１４２１一つに対して一つ生成され、各クライアントモジュール１４２１との通信を制御するためのスレッドである。したがって、トラップ監視部１４２２ａは、複数のトラップ監視スレッド１４２２ｃに対して共通的に対応することになる。

図６は、第一の実施の形態におけるトラップサービスによるトラップの通知方式（イベント方式）を説明するための図である。第一の実施の形態においては、機器２０からのトラップがソケットを介して受信されると（Ｓ１１）、サーバモジュール１４２２は、各機器管理アプリ１１ａに対応したそれぞれのクライアントモジュール１４２１の分だけ、トラップの受信の通知と共にトラップの内容を示す情報（以下「トラップ通知」という。）を生成し、当該トラップ通知を各クライアントモジュール１４２１に送信する（Ｓ１２）。各クライアントモジュール１４２１は、それぞれが対応する機器管理アプリ１１ａに対してトラップ通知を通知する（Ｓ１３）。このようにして、一つのソケットを介して受信されるトラップを、複数の機器管理アプリ１１ａに通知する。

以下、図５の機器管理装置１０の処理手順について説明する。図７は、第一の実施の形態における機器管理装置の処理を説明するためのシーケンス図である。

機器管理アプリ１１ａは、起動されると共通ＡＰＩ層１３のＯｐｅｎ関数を呼び出すことにより自分自身を識別するための情報（例えば、プロセスＩＤ等）をクライアント管理部１４２１ｂに登録する（Ｓ１０１）。続いて、クライアント管理部１４２１ｂが、クライアントモジュール１４２１の初期処理としてサーバモジュール１４２２の生成（起動）を行う（Ｓ１０２）と、サーバモジュール１４２２のトラップ監視部１４２２ａは、トラップ通知を受信するためのポートのオープンをプロトコル層１５に対して要求する（Ｓ１０３）。例えば、ＳＮＭＰによってトラップ通知を受信する場合は、ＳＮＭＰのポート番号によるポートがオープンされる。但し、サーバモジュール１４２２が既に起動されている場合は、改めてサーバモジュール１４２２の生成及びポートのオープンは行われない。

ステップＳ１０３に続いてステップＳ１０４に進み、クライアント管理部１４２１ｂは、クライアント管理部ディスパッチャ１４２２ｂに対しクライアントモジュール１４２１に関する情報（以下、「クライアントモジュール情報」という。）の登録を要求する。クライアントモジュール情報には、例えば、クライアントモジュール１４２１が実装されている装置のＩＰアドレス、クライアントモジュール１４２１に割り当てられたポート番号、クライアントモジュール１４２１のプロセス番号、クライアントモジュール１４２１に対する通知を意味するメッセージＩＤ等が含まれている。これらの情報は、後述されるトラップ監視スレッド１４２２ｃがクライアント管理部１４２１ｂに対してトラップ通知を通知する際に、クライアント管理部１４２１ｂを特定するために用いられる。

ステップＳ１０４に続いてステップＳ１０５に進み、クライアント管理部ディスパッチャ１４２２ｂが、トラップ監視スレッド１４２２ｃを生成すると、トラップ監視スレッド１４２２ｃは、後述するステップＳ１１２においてトラップ通知を受けるため、トラップ監視部１４２２ａに自らを識別するための情報を登録する（Ｓ１０６）。以上の処理が終了すると、クライアント管理部１４２１ｂは、Ｏｐｅｎ関数が正常終了した旨を機器管理アプリ１１ａに通知する（Ｓ１０７）。

Ｏｐｅｎ関数の正常終了に応じ、機器管理アプリ１１ａは、共通ＡＰＩ層１３のＳｅｔ関数を呼び出すことにより、機器２０からのトラップ通知を自分自身（機器管理アプリ１１ａ）に通知させるための方法（トラップ情報通知方法）に関する情報をライアント管理部１４２１ｂに登録する（Ｓ１０８）。トラップ情報通知方法には、様々なものが考えられるが、例えば、コールバック方式とメッセージ方式が挙げられる。

コールバック方式とは、機器管理アプリ１１ａがトラップ通知を受信するための関数（コールバック関数）を用意し、このコールバック関数をクライアント管理部１４２１ｂに登録しておく方式である。クライアント管理部１４２１ｂは、トラップ通知を受信すると、登録された関数の引数にトラップ情報を指定して当該関数を呼び出すことで、トラップ通知を機器管理アプリ１１ａに通知する。

一方、メッセージ方式とは、機器管理アプリ１１ａがイベントメッセージを受け取るためのハンドル（Ｗｉｎｄｏｗｓ（登録商標）メッセージ通信のハンドル）とイベントメッセージＩＤ（例えば、Ｗｉｎｄｏｗｓ（登録商標）メッセージ通信に使用されるＩＤ）とを用意し、このハンドルとイベントメッセージＩＤとをクライアント管理部１４２１ｂに登録しておく方式である。クライアント管理部１４２１ｂは、トラップ通知を受信すると、登録されたハンドルに対して、登録されたイベントメッセージＩＤによるメッセージを送る。

ステップＳ１０８に続いてステップＳ１０９に進み、クライアント管理部１４２１ｂは、通知マネージャ１４２１ａを生成し、Ｓｅｔ関数が正常終了した旨を機器管理アプリ１１ａに通知する（Ｓ１１０）。

以上で、機器管理アプリ１１ａの起動時の初期処理が完了する。続いて、機器２０からのトラップが受信された際の処理について説明する。

トラップ監視部１４２２ａは、機器２０からのトラップを受信すると（Ｓ１１１）、受信したトラップの内容に基づいてトラップ通知を生成し、生成したトラップ通知を、ステップＳ１０６において登録されているトラップ監視スレッド１４２２ｃに通知する（Ｓ１１２）。ここで、機器管理アプリ１１ａが複数起動されている場合、すなわち、クライアントモジュール１４２１が複数起動されている場合は、それぞれに対応するトラップ監視スレッド１４２２ｃが登録されているため、それらの各トラップ監視スレッド１４２２ｃに対するトラップ通知を生成し、それぞれのトラップ監視スレッド１４２２ｃに対して当該トラップ通知を通知する。なお、トラップ通知には、機器２０のアドレス情報（ＩＰアドレス、ＭＡＣアドレス等）、時刻情報、発生した事象（例えば、カバーオープンやトナー切れ等）を識別するための情報等が含まれている。

ステップＳ１１２に続いてステップＳ１１３に進み、トラップ監視スレッド１４２２ｃ は、登録されているクライアントモジュール情報に基づいてトラップ通知の送信先のクライアント管理部１４２１ｂを特定し、当該クライアント管理部１４２１ｂにトラップ通知を送信する。ステップＳ１１３に続いてステップＳ１１４に進み、クライアント管理部１４２１ｂは、受信したトラップ通知を通知マネージャ１４２１ａに通知する。ステップＳ１１４に続いてステップＳ１１５に進み、通知マネージャ１４２１ａは、予め機器管理アプリ１１ａより登録を受けているトラップ情報通知方法に基づいて、機器管理アプリ１１ａに対してトラップ通知を通知する。

なお、機器管理アプリ１１ａが終了する際等、トラップ通知を受ける必要が無くなったときは、機器管理アプリ１１ａは、共通ＡＰＩ層１３のＣｌｏｓｅ関数を呼び出す。これによって、トラップサービス１４２において機器管理アプリ１１ａごとに登録されていた各種情報が削除され、当該機器管理アプリ１１ａはトラップ通知の対象から除外される。

次に第二の実施の形態として、第一の実施の形態におけるイベント方式とは異なる方式で複数の機器管理アプリ１１ａの間でトラップ通知の共有を可能とした例について説明する。図８は、第二の実施の形態におけるトラップサービスの機能構成例を示す図である。図８中、図５と同一部分には同一符号を付し、その説明は省略する。図８においては、トラップ管理部１４２２ｄが新たに追加されている。トラップ管理部１４２２ｄは、トラップ監視部１４２２ａが機器２０より受信したトラップに基づいて生成したトラップ通知を保存（スプール）しておく。

図９は、第二の実施の形態におけるトラップサービスによるトラップの通知方式（スプール方式）を説明するための図である。第二の実施の形態においては、機器２０からのトラップがソケットを介して受信されると（Ｓ２１）、サーバモジュール１４２２は、各機器管理アプリ１１ａに対応したそれぞれのクライアントモジュール１４２１の分だけトラップ通知を生成し、当該トラップ通知を各クライアントモジュール１４２１に送信する（Ｓ２２）。各クライアントモジュール１４２１は、受信したトラップ通知を所定の記憶領域にスプールしておく（Ｓ２３）。その後、各機器管理アプリ１１ａからの定期的な要求（Ｓ２４ａ、Ｓ２４ｂ，Ｓ２４ｃ）に応じて、各クライアントモジュール１４２１は、スプールされているトラップ通知を取り出し（Ｓ２５）、当該トラップ通知をそれぞれが対応する機器管理アプリ１１ａに対して通知する（Ｓ２６ａ、Ｓ２６ｂ、Ｓ２６ｃ）。このようにして、一つのソケットを介して受信されるトラップを、複数の機器管理アプリ１１ａに通知する。

図１０は、第二の実施の形態における機器管理装置の処理を説明するためのシーケンス図である。ステップＳ２０１からステップＳ２１０までの起動時の初期処理については、図７におけるステップＳ１０１からステップＳ１１０までの処理と同様であるのでその説明は省略する。

トラップ監視部１４２２ａは、機器２０からのトラップを受信すると（Ｓ２１１）、受信したトラップの内容に基づいてトラップ通知を生成し、生成したトラップ通知をトラップ管理部１４２２ｄに出力する（Ｓ２１２）。ステップＳ２１２に続いてステップＳ２１３に進み、トラップ管理部１４２２ｄは、受信したトラップ通知を補助記憶装置１０２又はメモリ装置１０３等における記憶領域にスプールする。以上で、機器２０からのトラップの受信に基づいて実行される処理は終了する。

一方、機器管理アプリ１１ａが、共通ＡＰＩ層１３のＧｅｔ関数を呼び出すことによりクライアント管理部１４２１ｂに対してトラップ通知の取り出しを要求すると（Ｓ２１４）、クライアント管理部１４２１ｂは、クライアントモジュール情報（ＩＰアドレス、クライアントモジュールのポート番号及びプロセス番号等）と共に、トラップ通知の取り出し要求をクライアント管理部ディスパッチャ１４２２ｂに対して送信する（Ｓ２１５）。

ステップＳ２１５に続いてステップＳ２１６に進み、クライアント管理部ディスパッチャ１４２２ｂが、クライアントモジュール情報を伴うトラップ通知の取出し要求をトラップ管理部１４２２ｄに通知すると、トラップ管理部１４２２ｄは、保存されているトラップ通知を記憶領域より取り出し、当該トラップ通知をトラップ通知の取り出し要求元のクライアントモジュール１４２１に対応したトラップ監視スレッド１４２２ｃに対して出力する（Ｓ２１７）。なお、トラップ通知の取り出し要求元のクライアントモジュール１４２１に対応したトラップ監視スレッド１４２２は、トラップ通知の取り出し要求に伴っているクライアントモジュール情報に基づいて特定される。

以降、ステップＳ２１８からステップＳ２２０においては、図７におけるステップＳ１１３からステップＳ１１５と同様の処理によって、機器管理アプリ１１ａに対してトラップ通知が通知される。

上述したように、第一及び第二の実施の形態における機器管理装置１０によれば、一つのソケットを介して受信されるトラップを複数の機器管理アプリ１１ａに通知することができる。したがって、機器管理アプリ１１ａ間によるトラップの奪い合いを解消することができ、それぞれの機器管理アプリ１１ａにおける情報の欠落を防止することができる。

ところで、第一の実施の形態において説明した処理（図７）では、機器２０から受信された全てのトラップに基づくトラップ通知が、各機器管理アプリ１１ａに通知されることになる。しかし、機器管理アプリ１１ａによっては、所定の条件を満たすトラップ通知のみが必要な場合も考えられる。そこで、機器管理アプリ１１ａに通知するトラップ通知のフィルタリングを可能とした例を第三の実施の形態として説明する。図１１は、第三の実施の形態における機器管理装置の処理を説明するためのシーケンス図である。

図１１において、ステップＳ３０１からステップＳ３１０までの起動時の初期処理は、図７のステップＳ１０１からステップＳ１１０までと同様である。但し、ステップＳ３０８において、機器管理アプリ１１ａは、トラップ情報通知方法と共に、通知対象とするトラップ通知を限定するための条件（以下「通知条件」という。）をクライアント管理部１４２１ｂに登録する。通知条件としては、例えば、特定のＩＰアドレスを対象とするトラップ通知のみに限定する場合や、エラーを示すトラップ通知のみに限定する場合等、種々のものを対象とすることができる。

その後、機器２０からのトラップの受信（Ｓ３１１）に基づいて、図７におけるステップＳ１１２からステップＳ１１４と同様の手順で、通知マネージャ１４２１ａにトラップ通知が通知されると（Ｓ３１２〜Ｓ３１４）、通知マネージャ１４２１ａは、クライアント管理部１４２１ｂに対して通知条件の提供を要求することにより（Ｓ３１５）、クライアント管理部１４２１ｂより通知条件を取得する（Ｓ３１６）。

ステップＳ３１６に続いてステップＳ３１７に進み、通知マネージャ１４２１ａは、通知を受けたトラップ通知が、通知条件を満たすトラップ通知であるか否かを判断し、通知条件を満たす場合は、当該トラップ通知を機器管理アプリ１１ａに通知する。なお、通知条件を満たさない場合はトラップ通知の通知は行われない。

上述したように第三の実施の形態における機器管理装置１０によれば、機器管理アプリ１１ａごとに必要なトラップ通知のみを通知することが可能となり、機器管理アプリ１１ａの利便性を向上させることができる。

ところで、第二の実施の形態において説明した処理（図１０）では、第一の実施の形態の場合と同様、機器２０から受信された全てのトラップに基づくトラップ通知が、各機器管理アプリ１１ａに通知されることになる。また、トラップ通知は、一旦スプールされるためリアルタイム性に欠ける場合がある。したがって、緊急のトラップが発生した場合等に適切に対応することが困難なことも予想される。また、トラップ通知が記憶領域に蓄積されることにより、補助記憶装置１０２等の記憶容量が圧迫され、ひいては、新たなトラップ通知をスプールできなくなってしまうという可能性も考えられる。更に、同一の機器２０からの複数のトラップ通知が蓄積された場合に、機器管理アプリ１１ａに対して、全てのトラップ通知を通知対象とするか、又は最新のトラップ通知のみを通知対象とするか等の指定ができると便宜である。そこで、以上の課題を解決した例を第四の実施の形態として説明する。

図１２は、第四の実施の形態における機器管理装置の処理を説明するためのシーケンス図である。

ステップＳ４０１からステップＳ４１０までの起動時の初期処理は、図１０のステップＳ２０１からステップＳ２１０までと同様である。但し、ステップＳ４０６において、トラップ監視スレッド１４２２ｃは、当該トラップ監視スレッド１４２２ｃが対応するクライアント管理部１４２１ｂの識別情報をトラップ管理部１４２２ｄに登録する。これは、後述するステップＳ４１４において、クライアント管理部１４２１ｂがとラップ管理部１４２２ｄよりトラップ通知があったことの通知を受信することができるようにするためである。また、ステップＳ４０８において、機器管理アプリ１１ａは、トラップ情報通知方法と共に、通知条件をクライアント管理部１４２１ｂに登録する。通知条件には、第三の実施の形態において説明した条件の他、同一の機器２０からのトラップに基づくトラップ通知について、最新のもののみを通知対象とするか否かについての条件も更に付加される。

その後、機器２０からのトラップ（Ｓ４１１）を受信したトラップ監視部１４２２ａよりトラップ通知（Ｓ４１２）を受けたトラップ管理部１４２２ｄは、トラップ通知を記憶領域にスプールする（Ｓ４１３）。この際、トラップ管理部１４２２ｄは、予め設定されている保存期間を過ぎたトラップ通知を記憶領域から削除する。これによって、記憶領域の圧迫を軽減することができる。なお、保存期間は、機器管理アプリ１１ａより設定できるようにすればよい。

ステップＳ４１３に続いてステップＳ４１４に進み、トラップ管理部１４２２ｄは、トラップ通知がスプールされた旨の通知（以下「スプール通知」という。）をクライアント管理部１４２１ｂに対して送信する（Ｓ４１４）。クライアント管理部１４２１ｂは、スプール通知を通知マネージャ１４２１ａに対して通知し（Ｓ４１５）、通知マネージャ１４２１ａは、スプール通知をトラップ情報通知方法に基づいて機器管理アプリ１１ａに通知する（Ｓ４１６）。なお、記憶領域に空き領域がなくトラップ通知を保存できなかった場合は、スプール通知の代わりに、保存できなかった旨を示す通知（スプールエラー通知）が、トラップ管理部１４２２ｄより、クライアント管理部１４２１ｂ及び通知マネージャ１４２１ａを介して機器管理アプリ１１ａに通知される。機器管理アプリ１１ａが、スプールエラー通知をユーザに通知することで、空き領域の作成等、ユーザは適切な対応を行うことができる。

スプール通知に基づいてトラップ通知がスプールされたことを認識した機器管理アプリ１１ａが、共通ＡＰＩ層１３のＧｅｔ関数を呼び出すことによりクライアント管理部１４２１ｂに対してトラップ通知の取り出しを要求すると（Ｓ４１７）、図１０におけるステップＳ２１５からステップＳ２１９までと同様の処理によってトラップ通知が取り出され、通知マネージャ１４２１ａに通知される（Ｓ４１８〜Ｓ４２２）。

通知マネージャ１４２１ａは、クライアント管理部１４２１ｂに対して通知条件の提供を要求することにより（Ｓ４２３）、クライアント管理部１４２１ｂより通知条件を取得する（Ｓ４２４）。ステップＳ４２４に続いてステップＳ４２５に進み、通知マネージャ１４２１ａは、通知を受けたトラップ通知の中から、通知条件を満たすトラップ通知を抽出し、抽出されたトラップ通知を機器管理アプリ１１ａに通知する。

図１３は、通知条件を満たすトラップ通知を抽出する様子を概念的に示す図である。図１３においては、複数のトラップ通知５０１の履歴に対して、通知条件５０２が適用されることにより、トラップ通知５０３が抽出された例を示している。通知条件５０２には、通知対象とするＩＰアドレスが「１１．２２．３３．４４」でありトラップ通知を通知対象とし、更に、最新モード（最新のトラップのみを通知対象とするモード）がＯＮである旨が設定されている。したがって、トラップ通知５０１において、通知対象ＩＰアドレスが「１１．１１．２２．３３．４４」であるトラップ通知のうち最新のトラップ通知がトラップ通知５０３として抽出されている。

上述したように第四の実施の形態における機器管理装置１０によれば、トラップ通知がスプールされた旨が各機器管理アプリ１１ａにリアルタイムに通知されるため、トラップが発生したタイミングで機器管理アプリ１１ａにトラップ通知を通知することができる。また、最新のトラップ通知のみを通知対象とするか否かを含め、所定の条件を満たしたトラップ通知のみを通知対象とすることが可能となるため、機器管理アプリ１１ａの利便性を向上させることができる。更に、スプールされているトラップ通知に保存期間を設け、その保存期間を経過したトラップ通知は自動的に削除されるため、記憶領域の不足により新たなトラップ通知のスプールができないといった事態の発生を防止することができる。

以上、本発明の実施例について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

本発明の実施の形態における機器管理システムの構成例を示す図である。 本発明の実施の形態における機器管理装置のハードウェア構成例を示す図である。 本発明の実施の形態における機器管理装置の機能構成例を示す図である。 本発明の実施の形態におけるネットワーク層の機能構成例を示す図である。 第一の実施の形態におけるトラップサービスの機能構成例を示す図である。 第一の実施の形態におけるトラップサービスによるトラップの通知方式（イベント方式）を説明するための図である。 第一の実施の形態における機器管理装置の処理を説明するためのシーケンス図である。 第二の実施の形態におけるトラップサービスの機能構成例を示す図である。 第二の実施の形態におけるトラップサービスによるトラップの通知方式（スプール方式）を説明するための図である。 第二の実施の形態における機器管理装置の処理を説明するためのシーケンス図である。 第三の実施の形態における機器管理装置の処理を説明するためのシーケンス図である。 第四の実施の形態における機器管理装置の処理を説明するためのシーケンス図である。 通知条件を満たすトラップ通知を抽出する様子を概念的に示す図である。

符号の説明

１ 機器管理システム
１０ 機器管理装置
１１ アプリケーション
１１ａ、１１ａ−１、１１ａ−２、１１ａ−３ 機器管理アプリ
１２ ネットワーク層
１３ 共通ＡＰＩ層
１４ サービス層
１５ プロトコル層
１６ ＯＳ（Operating System）
１７ サービス層
１８ ソケットライブラリ
２０ 機器
２０ａ スキャナ
２０ｂ、２０ｃ プリンタ
２０ｄ コピー機
１００ ドライブ装置
１０１ 記録媒体
１０２ 補助記憶装置
１０３ メモリ装置
１０４ 演算処理装置
１０５ インタフェース装置
１０６ 表示装置
１０７ 入力装置
１４１ 機器情報サービス
１４２ 機器検索サービス
１４３ トラップサービス
１４４ 宛先管理サービス
１４２１ クライアントモジュール
１４２１ａ 通知マネージャ
１４２１ｂ クライアント管理部
１４２２ サーバモジュール
１４２２ａ トラップ監視部
１４２２ｂ クライアント管理部ディスパッチャ
１４２２ｃ トラップ監視スレッド
１４２２ｄ トラップ管理部
Ｂ バス

Claims (6)

1. 複数のアプリケーションを有する通信装置であって、
   ネットワークを介して接続する機器が送信する該機器の状態を示すメッセージを受信し、該メッセージの内容を示すメッセージ情報を前記複数のアプリケーションのそれぞれに通知する機器メッセージ処理手段を有することを特徴とする通信装置。
2. 前記機器メッセージ処理手段は、前記アプリケーションごとに個別に対応するメッセージ個別処理手段と、
   複数の前記メッセージ個別処理手段に共通に対応し、前記メッセージを前記機器より受信するメッセージ共通処理手段とを有し、
   前記メッセージ共通処理手段は、受信された前記メッセージに基づいて前記メッセージ個別処理手段ごとに生成した前記メッセージ情報を前記メッセージ個別処理手段のそれぞれに通知し、
   前記メッセージ個別処理手段は、それぞれが対応する前記アプリケーションに前記メッセージ情報を通知することを特徴とする請求項１記載の通信装置。
3. 前記機器メッセージ処理手段は、前記メッセージ情報を所定の記憶領域に保存し、前記アプリケーションからの要求に応じて、保存されている前記メッセージ情報を該アプリケーションに通知することを特徴とする請求項１又は２記載の通信装置。
4. 前記機器メッセージ処理手段は、予め設定された条件を満たすメッセージ情報を前記アプリケーションに通知することを特徴とする請求項１又は２記載の通信装置。
5. 複数のアプリケーションを有する通信装置に、
   ネットワークを介して接続する機器が送信する該機器の状態を示すメッセージを受信する受信手順と、
   前記受信手順において受信されたメッセージの内容を示すメッセージ情報を前記複数のアプリケーションのそれぞれに通知するメッセージ通知手順とを実行させるための機器メッセージ処理プログラム。
6. 請求項５記載の機器メッセージ処理プログラムを記録したコンピュータ読み取り可能な記録媒体。
   

Images