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

Abstract

【課題】ネットワーク上に配置されたデバイスの管理を確実に行うことができるネットワークデバイス管理装置を提供する。
【解決手段】ネットワークシステム１０００は、ＰＣ１００，１０１と、デバイス１０３，１０４と、これらの間に介在するルータ１０２とを備える。デバイス１０４上のディスカバリ・エージェントは、デバイス起動メッセージをデバイス１０３上のディスカバリ・プロキシに送信する。デバイス起動メッセージを受信したデバイス１０３上のディスカバリ・プロキシは、アドレス情報に基づいてデバイス１０４にアクセスしてデバイス１０４のデバイス情報を取得する。
【選択図】図２

Description

本発明は、ネットワークデバイス管理装置、ネットワークデバイス管理方法、ネットワークデバイス管理プログラム、及び記憶媒体に関する。特に、本発明は、ネットワーク上に配置されたコンピュータや複写機等のデバイスを管理するネットワークデバイス管理装置、ネットワークデバイス管理方法、ネットワークデバイス管理プログラム、及び記憶媒体に関する。

ネットワーク上に配置されたコンピュータ等のデバイスを探索するデバイス探索方法として、ＳＬＰ（Simple Location Protocol）を用いる方法が提案されている。ＳＬＰとは、ＴＣＰ／ＩＰ環境で提供しているサービスの通知、問い合わせを行うために用いられるプロトコルである。ＳＬＰを使用してデバイス探索を行う場合、特定のサービスタイプが指定されたパケットをネットワーク上のデバイスのノードの各々に、即ちマルチキャストで送信して管理対象のデバイスを探索する。

また、デバイス探索方法としては、ＳＮＭＰ（Simple Network Management Protocol）及びＭＩＢ（Management Information Base）を用いる方法も提案されている（例えば、特許文献１参照。）。ＳＮＭＰとは、ネットワーク上に配置された機器類（以下、「ネットワーク機器」という）をネットワーク経由で監視するために用いられるプロトコルである。ＭＩＢとは、ＳＮＭＰに対応したネットワーク機器に格納されたデータベースであって、このデータベースでは、ネットワーク機器に関する情報が管理情報として管理される。

ＳＮＭＰを用いることにより、マネージャと、当該マネージャの管理対象であるネットワーク機器に常駐するエージェントとの間でＵＤＰ（User datagram Protocol）通信を行うことができる。このＵＤＰ通信により、マネージャはリクエストをエージェントへ送信し、これに応じてエージェントはＭＩＢ内の情報をレスポンスとしてマネージャに送信することができ、これにより、マネージャはネットワーク管理を実現できる。ここで、マネージャによるデバイス探索は、特定のＭＩＢオブジェクトを含むＳＮＭＰパケットをブロードキャストで送信することにより実現することができる。
特開２０００−３５３１３６号公報

しかしながら、上述したような従来の技術では、ネットワーク環境が複雑な場合、例えばネットワーク内にルータが介在する場合には、ルータに対して、マルチキャストパケットやブロードキャストパケットを通過させないように設定されている場合がある。このような場合には、マネージャは、管理対象のネットワーク機器を探索することができず、ネットワーク管理を十分に行うことができない。

本発明の目的は、ネットワーク上に配置されたデバイスの管理を確実に行うことができるネットワークデバイス管理装置、ネットワークデバイス管理方法、ネットワークデバイス管理プログラム、及び記憶媒体を提供することにある。

上記目的を達成するために、本発明のネットワークデバイス管理装置は、ネットワーク上に配置された少なくとも１つのデバイスを管理するネットワークデバイス管理装置において、前記デバイスとの間でウェブサービスを用いた通信を行う通信手段を備え、前記通信手段は、前記ネットワーク上のデバイスを探索する探索手段と、前記デバイスのデバイス情報を取得する取得手段とを含むことを特徴とする。

上記目的を達成するために、本発明のネットワークデバイス管理方法は、ネットワーク上に配置された少なくとも１つのデバイスを管理するネットワークデバイス管理装置によって実行されるネットワーク管理方法であって、前記ネットワーク管理装置と前記デバイスの間でウェブサービスを用いた通信を行う通信ステップの実行中に、前記ネットワーク上のデバイスを探索する探索ステップと、前記デバイスのデバイス情報を取得する取得ステップとを実行することを特徴とする。

上記目的を達成するために、本発明のネットワークデバイス管理プログラムは、ネットワーク上に配置された少なくとも１つのデバイスを管理するネットワークデバイス管理装置が実行するためのコンピュータ読み取り可能なネットワークデバイス管理プログラムであって、前記ネットワークデバイス管理装置と前記デバイスの間でウェブサービスを用いた通信を行う通信モジュールを備え、当該通信モジュールは、前記ネットワーク上のデバイスを探索する探索モジュールと、前記デバイスの情報を取得する取得モジュールとを含むことを特徴とする。

上記目的を達成するために、本発明の記憶媒体は、上記ネットワークデバイス管理プログラムを格納したことを特徴とする。

本発明によれば、ネットワークデバイス管理装置とネットワーク上に配置された少なくとも１つのデバイスの間でウェブサービスを用いた通信を行う際に、ネットワーク上におけるデバイス探索と、デバイスのデバイス情報の取得とが実行される。これにより、ネットワークデバイス管理装置は、ネットワーク上に配置されたデバイスの管理を確実に行うことができる。

以下、本発明の実施の形態について図面を参照しながら詳細に説明する。

図１は、本発明の実施の形態に係るネットワークデバイス管理装置を含むネットワークシステムの構成を概略的に示すブロック図である。

図１において、ネットワークシステム１０００は、パーソナルコンピュータ（以下、「ＰＣ」という）１００，１０１と、デバイス１０３，１０４，１０５と、これらの間に介在するルータ１０２とを備える。

ＰＣ１００では、管理者が使用するブラウザが動作する。ＰＣ１０１では、デバイス管理ソフトウェア（ユーティリティ）が動作している。したがって、ＰＣ１００，１０１は、ルータ１０２を介してデバイス１０３〜１０５を管理するサーバとして機能する。

デバイス１０３は、ディスカバリ・プロキシ（Discovery Proxy：ＤＰ）として機能する。デバイス１０４，１０５は、ディスカバリ・プロキシからの要求に応答するディスカバリ・エージェントとして機能する。

ルータ１０２に対しては、マルチキャストパケットやブロードキャストパケットを通過させないように、即ちフィルタ制御を行うように設定されている。

図２は、図１のネットワークシステム１０００において実行されるデバイス探索に関する処理の第１の具体例を示す模式図である。

図２において、まず、矢印１に示すように、デバイス１０４，１０５上のディスカバリ・エージェントは、それぞれ、デバイス起動メッセージをデバイス１０３上のディスカバリ・プロキシに送信する。このデバイス起動メッセージには、送信元であるデバイスのアドレス情報が含まれている。このデバイス起動メッセージは、所定のデバイスをウェブサービスに接続するための仕様であるＷＳ−ディスカバリ（WS-Discovery：Web Services Dynamic Discovery）で使用される「ハロー（Hello）」メッセージであることが好ましい。

その後、デバイス起動メッセージを受信したデバイス１０３上のディスカバリ・プロキシは、アドレス情報に基づいて矢印２に示すようにデバイス１０４，１０５にアクセスし、それらのデバイス情報を取得する。このデバイス情報の取得は、ＷＳ−メタデータ交換（WS-Metadata Exchange）により行うことが好ましい。このようにして取得されたデバイス情報は、デバイス１０３上のディスカバリ・プロキシが作成したデバイスリスト内に保持される。

一方、ＰＣ１０１上のデバイス管理ソフトウェアは、定期的に、デバイス１０３上のディスカバリ・プロキシにルータ１０２を介してアクセスして（矢印３）、当該ディスカバリ・プロキシからデバイスリストを取得する。このように取得したデバイスリスト内のデバイス情報は、デバイス管理ソフトウェアが作成したデータベース内に保持される。

また、管理者は、矢印４に示すように、ＰＣ１００上のブラウザを用いて、デバイスリスト表示要求（リクエスト）をＰＣ１０１に送信する。これに応じて、ＰＣ１０１は、ＰＣ１００にデバイスリストを送信し、ＰＣ１００は受信したデバイスリストをその表示画面上に表示する。

図２の処理によれば、デバイス管理ソフトウェアがルータ１０２を介してディスカバリ・プロキシから取得したデバイスリストが表示可能、即ちデバイス探索可能となる。換言すれば、ネットワークシステム１０００において、ＰＣ１００，１０１とデバイス１０３〜１０５との間に介在するルータ１０２がフィルタ制御を行う場合であっても、ＰＣ１００，１０１は、デバイス１０３〜１０５の管理（ネットワーク管理）を確実に行うことができる。

また、図２の処理によれば、ディスカバリ・エージェントが、デバイス起動メッセージをディスカバリ・プロキシに自動的に送信するので、ＰＣ１０１は、ディスカバリ・プロキシにアクセスするだけでデバイスリストを取得することができる。この結果、ＰＣ１００，１０１によるネットワーク管理を簡素化することができる。

図３は、図１のネットワークシステム１０００において実行されるデバイス探索に関する処理の第２の具体例を示す模式図である。

図３において、まず、矢印１’に示すように、デバイス１０３上のディスカバリ・プロキシは、ネットワーク上に配置されたデバイスを探索するための探索パケットをデバイス１０４，１０５に送信することによりデバイス探索を行う。この探索パケットは、ＷＳ−ディスカバリで使用されるプローブ（Probe）パケットであることが好ましい。なお、この探索パケットは、ルータ１０２がフィルタ制御を行っていない場合には、デバイス１０４，１０５だけでなく、ＰＣ１００やＰＣ１０１にも送信されてもよい。

その後、探索パケットを受信したデバイスのうち、ディスカバリ・エージェントとして機能するデバイス１０４，１０５は、それぞれ、そのデバイスのアドレス情報を含むプローブマッチパケット（Probe Match Packet）をデバイス１０３にレスポンスとして送信する。

そして、プローブマッチパケットを受信したデバイス１０３上のディスカバリ・プロキシは、アドレス情報に基づいて矢印２に示すようにデバイス１０４，１０５にアクセスし、それらのデバイス情報を取得する。このデバイス情報の取得は、ＷＳ−メタデータ交換（WS-Metadata Exchange）により行うことが好ましい。このようにして取得されたデバイス情報は、デバイス１０３上のディスカバリ・プロキシが作成したデバイスリスト内に保持される。

一方、ＰＣ１０１上のデバイス管理ソフトウェアは、定期的に、デバイス１０３上のディスカバリ・プロキシにルータ１０２を介してアクセスして（矢印３）、当該ディスカバリ・プロキシからデバイスリストを取得する。このように取得したデバイスリスト内のデバイス情報は、デバイス管理ソフトウェアが作成したデータベース内に保持される。

また、管理者は、矢印４に示すように、ＰＣ１００上のブラウザを用いて、デバイスリスト表示要求をＰＣ１０１に送信する。これに応じて、ＰＣ１０１は、ＰＣ１００にデバイスリストを送信し、ＰＣ１００は受信したデバイスリストをその表示画面上に表示する。

図３の処理によれば、デバイス管理ソフトウェアがルータ１０２を介してディスカバリ・プロキシから取得したデバイスリストが表示可能、即ちデバイス探索可能となる。換言すれば、ネットワークシステム１０００において、ＰＣ１００，１０１とデバイス１０３〜１０５との間に介在するルータ１０２がフィルタ制御を行う場合であっても、ＰＣ１００，１０１は、デバイス１０３〜１０５の管理（ネットワーク管理）を確実に行うことができる。

また、図３の処理によれば、ディスカバリ・プロキシが探索パケットをネットワークに向けて送信するだけで、ディスカバリ・エージェントが自動的にアドレス情報を含むパケットでレスポンスする。これにより、ディスカバリ・プロキシは容易にディスカバリ・エージェントを探索することができ、この結果、ＰＣ１００によるネットワーク管理を簡素化することができる。具体的には、ルータ１０２によりサーバから分離されたネットワーク上にディスカバリ・プロキシを設けることにより、他のサーバを新規に設ける必要をなくすことができる。

図４は、図１においてディスカバリ・プロキシとして機能するデバイス１０３の構成を詳細に示すブロック図である。

図４において、デバイス１０３は、スキャン機能を有するスキャナ２０７０と、プリント機能を有するプリンタ２０９５と、スキャナ２０７０及びプリンタ２０９５を制御する制御部（Controller Unit）２０００と、操作部２０１２とを備える。制御部２０００は、ＬＡＮ２０１１や公衆回線網としてのＷＡＮ２０５１に接続されており、デバイス１０４，１０５のデバイス情報やデバイス１０３のデバイス情報の入出力に関する制御も行う。操作部２０１２は、ユーザが入力した情報を制御部２０００に伝達するユーザインタフェース（ＵＩ）として機能する。

スキャナ２０７０は、原稿の画像を読み取り画像情報を取得する画像入力デバイスとして機能する。プリンタ２０９５は、画像情報に基づいて可視像化した画像を記録紙に印刷する画像出力デバイスとして機能する。したがって、デバイス１０３は画像を処理する画像処理装置として機能する。

制御部２０００は、システムバス２００７と、画像バス２００８と、これらの間に接続された画像バスインタフェース（Image Bus I/F）２００５とを備える。システムバス２００７には、ＣＰＵ２００１、ＲＡＭ２００２、ＲＯＭ２００３、ハードディスクドライブ（ＨＤＤ）２００４、操作部インタフェース（Ｉ／Ｆ）２００６、ネットワークＩ／Ｆ２０１０、及びモデム（MODEM）２０５０が接続されている。画像バス２００８には、デバイスＩ／Ｆ２０２０、画像回転部２０３０、画像圧縮部２０４０、ラスタイメージプロセッサ（ＲＩＰ）２０６０、スキャナ画像処理部２０８０、及びプリンタ画像処理部２０９０が接続されている。

ＣＰＵ２００１は、デバイス１０３全体を制御するコントローラである。ＲＡＭ２００２は、ＣＰＵ２００１が動作するためのワークメモリとして機能すると共に、画像データ（画像情報）を記憶するための画像メモリとして機能する。ＲＯＭ２００３は、デバイス１０３のブートプログラムが格納されているブートＲＯＭから成る。ＨＤＤ２００４は、ソフトウェアのプログラムや画像データなどを格納する。

操作部Ｉ／Ｆ２００６は、ＵＩとしての操作部２０１２のためのインタフェースであり、操作部２０１２に表示すべき画像データを出力すると共に、ユーザが入力した情報をＣＰＵ２００１に伝達する。ネットワークＩ／Ｆ２０１０は、複数のデバイス、例えば図１のデバイス１０４，１０５が接続されたＬＡＮ２０１１にデバイス１０３を接続する。これにより、デバイス１０３とデバイス１０４，１０５の間で情報の入出力が可能となる。モデム２０５０は、一般的な公衆回線網の一例であるＷＡＮ２０５１にデバイス１０３を接続する。これにより、デバイス１０３は、公衆回線網を介した情報の入出力が可能となる。

画像バス２００８は、画像データの転送をシステムバス２００７より高速で実行することができるように構成されており、例えばＰＣＩバス又はＩＥＥＥ１３９４で規格化されたバスから成る。そこで、システムバス２００７と画像バス２００８とを互いに接続する画像バスＩ／Ｆ２００５は、画像データなどのデータのデータ構造を変換するバスブリッジとして機能する。

ＲＩＰ２０６０は、ＰＤＬコードの画像データをビットマップイメージに展開する。デバイスＩ／Ｆ２０２０は、スキャナ２０７０やプリンタ２０９５を制御部２０００に接続しており、入出力される画像データの同期系／非同期系の変換を行う。

スキャナ画像処理部２０８０は、入力された画像データに対して補正、加工、編集などの処理を施す。プリンタ画像処理部２０９０は、プリントすべき画像データに対して、補正、解像度変換などの処理を施す。画像回転部２０３０は、画像データの回転を行う。画像圧縮部２０４０は、画像データの圧縮処理や伸張処理を行い、これにより、例えば、多値の画像データがＪＰＥＧ形式の画像データに変換され、２値の画像データがＪＢＩＧ形式、ＭＭＲ形式、ＭＨ形式などの画像データに変換される。

図５は、図４におけるスキャナ２０７０及びプリンタ２０９５の外観を示す側面図である。なお、図５は、図１におけるデバイス１０３の部分側面図に該当する。

図５に示すように、スキャナ２０７０には、原稿を載置（セット）するトレイ２０７３と、トレイ２０７３にセットされた原稿を１枚ずつフィードする原稿フィーダ２０７２とが設けられている。スキャナ２０７０は、原稿に対して光を照射しながらＣＣＤラインセンサ（不図示）を用いて原稿表面を走査することにより、原稿の画像を読み取り、この読み取った画像を電気信号に変換することによりラスタイメージデータを取得する。スキャナ２０７０による原稿の画像の読み取り動作は、ユーザがトレイ２０７３に原稿をセットし、操作部２０１２を介して読み取り起動の指示を入力することにより開始される。

また、プリンタ２０９５は、用紙サイズや用紙向きを選択可能にすべく設けられた複数の給紙段として給紙カセット２１０１，２１０２，２１０３，２１０４と、プリント動作完了後に排紙された記録紙を積載する排紙トレイ２１１１とを備える。プリント動作は、ＣＰＵ２００１からの指示に応じて開始される。プリント動作時には、電気信号であるラスタイメージデータが可視画像に変換され、その画像は記録紙上に形成される。なお、プリンタ２０９５としては、感光体ドラムや感光体ベルトを用いた電子写真方式、又は微小ノズルアレイからインクを吐出することにより記録紙上に画像を直接的に形成するインクジェット方式などが採用される。

図６は、図４のディスカバリ・プロキシとして機能するデバイス１０３のソフトウェア構成を詳細に示すブロック図である。なお、図６に示すモジュール構成は、一例に過ぎず、必要なモジュールのみを採用することができるのは云うまでもない。

図６において、デバイス１０３は、ユーザがデバイス１０３の各種操作・設定を行う際に操作部２０１２をインタフェースとして機能させるためのモジュールとしてＵＩ１５０１を備える。ＵＩ１５０１は、以下に説明する各モジュールにユーザの操作に応じた処理の依頼を行ったり、以下に説明する各モジュールに対して、ユーザの操作に応じた入力情報に対応するデータを設定したりする。

ＵＩ１５０１内のアドレスブック（Address Book）１５０２は、データの送付先や通信先などの宛先を管理するためのデータベースモジュールである。アドレスブック１５０２には、宛先に関する情報だけでなく、当該宛先に送信すべきデータのデータ形式や送信可能な画像データの形態、画像の解像度などの情報も記憶されている。アドレスブック１５０２では、ＵＩ１５０１からの入力情報に応じて、管理されているデータの取得、追加、削除などが行われる。また、アドレスブック１５０２で管理されているデータは、ユーザの操作に応じて各モジュールにデータの宛先に関する情報を与えるために使用される。

制御ＡＰＩ（Control API）１５１８は、当該制御ＡＰＩ１５１８とＵＩ１５０１の間に配置された上流（上位）モジュールと、制御ＡＰＩ１５１８の下流（下位）モジュールとの間に設けられたインタフェースである。制御ＡＰＩ１５１８を用いることにより、上流モジュールと下流モジュールの間の依存関係を軽減することができるので、上流モジュール及び下流モジュールとして様々なモジュールを使用することができる。

ウェブサーバ（Web Server）モジュール１５０３は、ネットワーク上のウェブクライアント（例えば、ＰＣ１０１）からの要求に応じて、デバイス１０３及びデバイス１０４，１０５に関する情報を管理情報として通知するために使用される。この管理情報の通知は、制御ＡＰＩ（Control API）１５１８を介して行われる。

ユニバーサル・センド（Universal Send）・モジュール１５０４は、プリンタモジュール１５０５、電子メール（E-mail）モジュール１５０６、データベースモジュール１５０７、及びディスカバリ・プロキシ（ＤＰ）モジュール１５０８を備える。ユニバーサル・センド・モジュール１５０４は、各種データの配信を司っており、具体的には、ユーザがＵＩ１５０１を介して指示したデータを指示された宛先（出力先）に配布する。また、ユーザがスキャナ２０７０のスキャン機能を使用して配布すべきデータの生成を指示したときは、ユニバーサル・センド・モジュール１５０４は、制御ＡＰＩ１５１８を介して所定の機器を動作させて必要なデータを生成する。

プリンタモジュール１５０５は、出力先としてプリンタ２０９５が指定された際に使用される。電子メールモジュール１５０６は、通信先として電子メールアドレスが入力された際に使用される。データベースモジュール１５０７は、出力先としてデータベースが指定された際に使用される。ＤＰモジュール１５０８は、出力先としてデバイス１０３と同様の機能を有するデバイスが指定された際に使用される。

リモート・コピー・スキャン（Remote Copy Scan）モジュール１５０９は、スキャナ２０７０のスキャン機能を使用して取得した画像データを、ネットワーク等を介して接続された他のプリンタに出力しプリント動作を実行する際に使用される。なお、プリンタとしては、例えば、デバイス１０４，１０５を使用することができる。このモジュール１５０９によれば、デバイス１０３のスキャナ２０７０のスキャン機能及びプリンタ２０９５のプリント機能によって実現可能なコピー機能の一部であるプリント機能を他のデバイスに分散させることができる。

リモート・コピー・プリント（Remote Copy Print）モジュール１５１０は、ネットワーク等を介して接続された他のデバイスから入力された画像データに対して、プリンタ２０９５のプリント機能を使用してプリント動作を実行する際に使用される。なお、画像データの入力元としては、例えば、ＰＣ１００，１０１やデバイス１０４，１０５を使用することができる。このモジュール１５１０によれば、デバイス１０３が実現可能なコピー機能の一部、例えばスキャン機能を他のデバイスに分散させることができる。

ウェブ・プル・プリント（Web Pull Print）モジュール１５１１は、インタネット又はイントラネット上の各種ウェブサイト（ホームページ）の情報を読み出して印刷する際に使用される。

ネットワークドライバ（Network Driver）１５１７は、ネットワークに物理的に接続される部分を制御する。ＴＣＰ／ＩＰモジュール１５１６は、ネットワークドライバ１５１７がウェブサーバモジュール１５０３やウェブ・プル・プリントモジュール１５１１にＴＣＰ／ＩＰの規格に準拠した通信を提供する際に使用される。

ＨＴＴＰモジュール１５１２は、デバイス１０３がＨＴＴＰを介した通信を行う際に使用される。エルピーアール（ｌｐｒ：Line PRinter daemon protocol）モジュール１５１３は、ＴＣＰ／ＩＰモジュール１５１６がプリンタモジュール１５０５にエルピーアール（ｌｐｒ）を用いた通信を提供する際に使用される。ＳＭＴＰモジュール１５１４は、ＴＣＰ／ＩＰモジュール１５１６が電子メールモジュール１５０６にＳＭＴＰを用いた通信を提供する際に使用される。ＳＬＭ（Salutation Manager）モジュール１５１５は、ＴＣＰ／ＩＰモジュール１５１６がモジュール１５０７〜１５１０にサリュテーションアーキテクチャ（Salutation Architecture）に基づいた通信を提供する際に使用される。

ジョブマネージャ（Job Manager）１５１９は、制御ＡＰＩ１５１８を介して指示された処理内容、即ちジョブの種別を解釈する。解釈した処理内容に応じて、コーデックマネージャ（CODEC Manager）１５２０、スキャナマネージャ（Scanner Manager）１５２４、及びプリンタマネージャ（Printer Manager）１５２６の少なくとも１つに指示が伝達される。

コーデックマネージャ１５２０は、ジョブマネージャ１５１９から伝達された指示に対応する処理として実行すべき圧縮処理や伸張処理を管理したり制御したりする。ＦＢＥエンコーダ（encoder）１５２１は、ジョブマネージャ１５１９が取得したデータやスキャンマネージャ１５２４が実行したスキャン処理により取得したデータに対してＦＥＢフォーマットで圧縮処理を施す。ＪＰＥＧコーデック１５２２は、同様に取得したデータに対してＪＰＥＧ圧縮処理を施す。また、ＪＰＥＧコーデック１５２２はプリンタマネージャ１５２６がプリント処理を実行すべき印刷データに対してＪＰＥＧ展開処理を施す。ＭＭＲコーデック１５２３は、ＪＰＥＧコーデック１５２２と同様に、取得したデータに対してＭＭＲ圧縮処理を施すと共に、印刷データに対してＭＭＲ伸張処理を施す。

スキャナマネージャ１５２４は、ジョブマネージャ１５１９から伝達された指示に対応する処理として実行すべきスキャン処理を管理したり制御したりする。ＳＣＳＩドライバ１５２５は、デバイス１０３の内部においてスキャナ２０７０との間で通信を行う。

プリンタマネージャ１５２６は、ジョブマネージャ１５１９から伝達された指示に対応する処理として実行すべきプリント処理を管理したり制御したりする。エンジンインタフェース（Engine I/F）ドライバ１５２７は、プリンタマネージャ１５２６とプリンタ２０９５（印刷部）とのインタフェースとして機能する。パラレル（Parallel）ポートドライバ１５２８は、ウェブ・プル・プリントモジュール１５１１がパラレルポート（不図示）を介して他のデバイスにデータを出力する際のインタフェースとして機能する。

図７は、図１におけるデバイス管理ソフトウェアが動作するＰＣ１０１の構成を詳細に示すブロック図である。

図７において、ＰＣ１０１は、ＣＰＵ２０１、ＲＯＭ２０２、ＲＡＭ２０３、及びこれらを接続するシステムバス２０４を備える。また、ＰＣ１０１は、キーボード（ＫＢ）２０９、ＣＲＴ２１０、ＨＤＤ２１１、及びフロッピー（登録商標）ディスクコントローラ（ＦＤ）２１２を備える。システムバス２０４とキーボード２０９の間にはキーボードコントローラ（ＫＢＣ）２０５が接続されている。システムバス２０４とＣＲＴ２１０の間にはＣＲＴコントローラ（ＣＲＴＣ）２０６が接続されている。システムバス２０４とＨＤＤ２１１の間及びシステムバス２０４とＦＤ２１２の間にはディスクコントローラ（ＤＫＣ）２０７が接続されている。また、システムバス２０４には、ＬＡＮ２０１１と接続可能なＮＩＣ２０８が接続されている。

ＨＤＤ２１１には、本発明によるデバイス探索の制御主体となるデバイス管理ソフトウェアのプログラムが格納されている。ＣＰＵ２０１は、デバイス管理ソフトウェアのプログラムの実行主体である。なお、デバイス管理ソフトウェアのプログラムは、ＦＤやＣＤ−ＲＯＭなどの記憶媒体に格納されていてもよく、この場合には、ＦＤ２１２又は不図示のＣＤ−ＲＯＭドライブなどによって読み込まれる。この際、読み込んだプログラムをＨＤＤ２１１にインストールすることが好ましい。また、本実施の形態において、デバイス１０１のオペレーティングシステム（ＯＳ）は、マイクロソフト社製ウィンドウズ（登録商標）であることが好ましいが、これに限られることはない。

図８は、図３におけるデバイス１０３上のディスカバリ・プロキシが実行するデバイス探索処理のフローチャートである。なお、本処理は、デバイス管理ソフトウェアが動作するＰＣ１０１からのデバイス探索要求（リクエスト）に応じて実行される。

図８において、まず、デバイス１０３上のディスカバリ・プロキシは、ＰＣ１０１からデバイス探索要求を受信する（ステップＳ１０１）。続いて、ステップＳ１０２では、探索パケットを送信すべき時刻であるか否かを判別する。探索パケットを送信すべき時刻に到達していないときは、当該時刻に到達するまで待機する（ステップＳ１０３）。

一方、探索パケットを送信すべき時刻に到達したときは（ステップＳ１０２でＹＥＳ）、探索パケットとしてのプローブパケットのレスポンスであるプローブマッチパケットの受信待機時間を設定すべくタイマをセットする（ステップＳ１０４）。タイマをセットする理由は、複数のデバイスからのレスポンスを受信するためである。

続くステップＳ１０５では、デバイス１０３はプローブパケットをマルチキャストで送信し、プローブパケットを受信したデバイス、例えばデバイス１０４，１０５からのレスポンスの受信待機状態となる。その後、ステップＳ１０４で設定した受信待機時間が経過（タイムアウト）したか否かを判別し（ステップＳ１０６）、タイムアウトしていない場合には、受信待機状態を継続すると共に、後述する図９のプローブマッチパケット受信処理を行う（ステップＳ１０７）。

一方、ステップＳ１０６の判別の結果、タイムアウトした場合には、本処理を終了する。

図９は、図８のステップＳ１０７のプローブマッチパケット受信処理の詳細を示すフローチャートである。なお、本処理は、デバイス１０３が１つのデバイスからレスポンスを受信する度に実行される。

図９において、まず、デバイス１０３上のディスカバリ・プロキシがプローブパケットを受信したデバイス上のディスカバリ・エージェントからプローブマッチパケットをレスポンスとして受信したか否かを判別する（ステップＳ２０１）。

レスポンスを受信したときは（ステップＳ２０１でＹＥＳ）、デバイス１０３は、受信したプローブマッチパケットに含まれているアドレス情報に基づいて、当該プローブマッチパケットの送信元であるデバイス、例えばデバイス１０４にアクセスする。そして、デバイス１０３は、デバイス１０４に関するデバイス情報を示すメタデータを取得する（ステップＳ２０２）。このデバイス情報には、デバイス１０４のアドレス情報も含まれている。

続くステップＳ２０３では、デバイス１０３は、ディスカバリ・プロキシが保持しているデバイスリスト内に、取得したデバイス情報に含まれているＭＡＣ（Media Access Control）アドレスと同一のＭＡＣアドレスが含まれているか否かを判別する。

デバイスリスト内に同一のＭＡＣアドレスが含まれていた場合には（ステップＳ２０３でＹＥＳ）、デバイスリスト内で、当該ＭＡＣアドレスに関連するアドレス情報を、取得したデバイス情報でアップデート（更新）する（ステップＳ２０４）。これにより、ＰＣ１００，１０１の管理対象であるデバイス１０３〜１０５のデバイス情報を常に最新の状態で保持することができる。そして、本処理を終了し、図８の処理にリターンする。

一方、デバイスリスト内に同一のＭＡＣアドレスが含まれていなかった場合には（ステップＳ２０３でＮＯ）、デバイスリストに、取得したデバイス情報を追加することにより、新たなデバイスを登録する（ステップＳ２０５）。そして、本処理を終了し、図８の処理にリターンする。

なお、ステップＳ２０１において、プローブマッチパケットを受信していないときは、図８の処理にリターンすることにより、図８のステップＳ１０６〜Ｓ１０７の処理を繰り返す。

図８及び図９の処理によれば、デバイス１０３上のディスカバリ・プロキシがデバイス探索を実行して、デバイス１０４，１０５のデバイス情報を取得する。これにより、ＰＣ１０１は、デバイス１０３にアクセスするだけで、デバイス１０３〜１０５のデバイス情報を容易に取得することができる。

また、図８及び図９の処理をしている間に、デバイス１０３は、デバイスリスト内のデバイス１０３のデバイス情報も更新することが好ましい。

図１０及び図１１は、図８のステップＳ１０１において、デバイス管理ソフトウェアが動作するＰＣ１０１からデバイス１０３上のディスカバリ・プロキシが受信したデバイス探索要求のデータ構造を例示する図である。図１０及び図１１のデータは、互いに連続する一連のデータを示している。

図１０及び図１１に示すデータは、デバイス探索要求用のＳＯＡＰ（Simple Object Access Protocol）パケットの一例を示している。このＳＯＡＰパケットは、時刻２３：００：００にデバイス探索を１回（once）行い、アクション（Action）としてデバイスリストをアップデートすることを要求（Request）するものである。ここで、図１１におけるボディ（Body）部分のアップデート種別を示すタグ<dsc:updatetype>内には、所望の変数を入力することが可能である。これにより、所望のスケジュールで、例えば定期的にデバイス探索（ポーリング：Polling）を行うことができる。

図１２及び図１３は、図１０及び図１１に示したようなデバイス探索要求に対するレスポンスのデータ構造を例示する図である。図１２及び図１３のデータは、互いに連続する一連のデータを示している。

図１２及び図１３に示すデータも、図１０及び図１１のデータと同様にＳＯＡＰパケットの一例を示している。このＳＯＡＰパケットは、図１０及び図１１に示したようなデバイス探索要求に対するレスポンスとして「成功（success）」を伝達する応答パケットである。

図１４は、図３におけるデバイス１０３上のディスカバリ・プロキシが実行するデバイス起動メッセージ受信処理のフローチャートである。なお、本処理は、図２におけるデバイス１０４，１０５の少なくとも一方のデバイスに電源が投入され、当該デバイス上のディスカバリ・エージェントがデバイス起動メッセージを送信したときに実行される。

図１４において、まず、ステップＳ３０１では、デバイス１０３上のディスカバリ・プロキシは、電源が投入されたデバイス、例えばデバイス１０４からデバイス起動メッセージとして「ハロー」メッセージを含むハローパケットを受信する（ステップＳ３０１）。
このハローパケットには、電源が投入されたデバイスのアドレス情報が含まれている。

続いて、ステップＳ３０２では、デバイス１０３は、受信したハローパケットに含まれているアドレス情報に基づいて、当該ハローパケットの送信元であるデバイス１０４にアクセスする。

その後のステップＳ３０２〜Ｓ３０４の処理では、図９のステップＳ２０２〜Ｓ２０４の処理と同様に、デバイス１０３は、デバイス１０４に関するデバイス情報を取得して、デバイスリストに反映させる。そして、本処理を終了する。

図１４の処理によれば、デバイス１０４，１０５がデバイス起動メッセージをデバイス１０３上のディスカバリ・プロキシに自動的に送信する。これにより、デバイス１０３上のディスカバリ・プロキシは、デバイス１０４，１０５のデバイス情報を取得すべきタイミングを容易に決定することができる。その結果、デバイスリスト内のデバイス情報を常に最新の状態で保持することができる。

図１５は、図２，図３におけるデバイス１０３上のディスカバリ・プロキシが実行するデバイスリスト取得要求応答処理のフローチャートである。なお、本処理は、図２，図３においてデバイス管理ソフトウェアが動作するＰＣ１０１がデバイスリスト取得要求を送信したときに実行される。

図１５において、まず、デバイス１０３上のディスカバリ・プロキシは、ＰＣ１０１から後述する図１６及び図１７に示すようなデバイスリスト取得要求を受信する（ステップＳ４０１）。続いて、ステップＳ４０２では、デバイスリスト取得要求にフィルタ条件（図１７参照）が設定されているか否かを判別する。

デバイスリスト取得要求にフィルタ条件が設定されている場合には（ステップＳ４０２でＹＥＳ）、デバイス１０３は、デバイスリストに登録されているデバイスの中から、フィルタ条件に合致したデバイスを抽出し（ステップＳ４０３）、ステップＳ４０４に進む。一方、デバイスリスト取得要求にフィルタ条件が設定されていない場合には（ステップＳ４０２でＮＯ）、ステップＳ４０３の処理をスキップ又は省略してステップＳ４０４に進む。

続くステップＳ４０４では、デバイス１０３は、抽出したデバイスのみが登録されたデバイスリスト又は全てのデバイスが登録されたデバイスリストをＳＯＡＰパケットに添付する。ここで、デバイスリスト添付の方法は、いかなる方法であってもよいが、ＷＳ−アタッチメント（WS-Attachment）を使用することが好ましい。

ステップＳ４０４において、該デバイスリストが添付されたＳＯＡＰパケットをＰＣ１０１に送信することにより、ＰＣ１０１上で動作するデバイス管理ソフトウェアに対して応答を行い（ステップＳ４０５）、本処理を終了する。

図１５の処理によれば、デバイス１０３は、ＰＣ１０１からのデバイスリスト取得要求に応じて動作する。したがって、ＰＣ１０１においてデバイスリスト取得要求を送信すべきタイミングを制御することにより、ＰＣ１０１は、所望のタイミングで最新のデバイスリストを取得することができる。

図１６及び図１７は、図１５のステップＳ４０１において、デバイス管理ソフトウェアが動作するＰＣ１０１からデバイス１０３上のディスカバリ・プロキシが受信したデバイスリスト取得要求のデータ構造を例示する図である。図１６及び図１７のデータは、互いに連続する一連のデータを示している。

図１６及び図１７に示すデータは、デバイスリスト取得（GetDeviceList）要求用のＳＯＡＰパケットの一例を示している。ここで、図１７におけるボディ（Body）部分のフィルタ条件の内容を示すタグ<dsc:Filter>内には「all」や「nothing」が記述され、これにより、フィルタ条件が設定される。図１７に示すように、フィルタ条件として「all」を設定した場合には、上記ステップＳ４０３においてデバイスリストに登録されている全てのデバイスが抽出されることになる。なお、フィルタ条件として「nothing」を設定した場合には、上記ステップＳ４０３の処理がスキップ又は省略されることを意味する。換言すれば、上記ステップＳ４０３においてデバイスリストに登録されているデバイスを１つも抽出しないのではない。

図１８乃至図２０は、図１６及び図１７に示したようなデバイスリスト取得要求に対するレスポンスのデータ構造を例示する図である。図１８乃至図２０のデータは、互いに連続する一連のデータを示している。

図１８乃至図２０に示すデータも、図１６及び図１７のデータと同様にＳＯＡＰパケットの一例を示している。このＳＯＡＰパケットは、図１６及び図１７に示したようなデバイスリスト取得要求に対するレスポンスとして上記ステップＳ４０５において送信される。

ここで、図１９におけるボディ（Body）部分のリファレンス先を示すタグ<xbinc:Include href=xxx>内には、デバイスリストが添付されている位置に関する情報が記載される。デバイスリスト内のデバイス情報は、図１９に示す「-- MINE_boundary」以下に記述されている。図１９及び図２０に示す例では、製品名「ｉＲ Ｃ３２００」，「ｉＲ Ｃ３２０１」，「ｉＲ Ｃ３２０２」に関するデバイス情報として、それぞれのＩＰアドレス、ＭＡＣアドレス、位置などの情報が記載されている。

以上詳細に説明したように、本発明の実施の形態では、デバイス１０３にはディスカバリ・プロキシ機能が付与され、デバイス１０４，１０５にはディスカバリ・エージェント機能が付与されている。また、ＰＣ１０１は、ウェブサービスを用いてデバイス１０３上のディスカバリ・プロキシにアクセスする。これにより、ＰＣ１００，１０１は、ネットワークシステム１０００がルータ１０２を含む場合であっても、ネットワーク上において配置されたデバイス１０３〜１０５のデバイス探索を行ってそれらのデバイス情報を取得することができる。したがって、本実施の形態によれば、ＰＣ１００，１０１は、ルータ１０２がフィルタ制御を行うか否かに依存することなく、これらデバイス１０３〜１０５の管理を確実に行うことができる。

また、本実施の形態によれば、デバイス１０３〜１０５にデバイス管理ソフトウェアをインストールできない場合であっても、デバイス１０３〜１０５の少なくとも１つのデバイスにディスカバリ・プロキシ機能を付与するだけでデバイス探索が可能となる。

なお、上記実施の形態では、ディスカバリ・プロキシとして機能するデバイスは、デバイス１０３のみであるが、ネットワークシステム１０００が含む他のデバイスがディスカバリ・プロキシとして機能してもよい。この場合、ディスカバリ・プロキシとして機能するデバイスは１台に限られることはない。

また、本実施の形態において、ＰＣ１０１においてＰＣ１００と同様のブラウザが動作可能であってもよい。また、ＰＣ１００にデバイス管理ソフトウェアがインストールされていてもよい。

また、上記実施の形態において、ネットワークシステム１０００は、ネットワーク上に設けられたルータ１０２を含むとしたが、ルータ１０２を含まなくてもよい。換言すれば、ネットワークシステム１０００は、ルータ１０２を設置可能なネットワークを備えるものであればいかなるものであってもよい。また、フィルタ制御を行うものは、ルータであるとしたが、ルータに限られることはなく、マルチキャストパケットやブロードキャストパケットを通過させないような設定が可能なデバイスであればよい。

また、本発明の目的は、以下の処理を実行することによって達成される。即ち、上述した実施の形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵなど）が記憶媒体に格納されたプログラムコードを読み出す処理である。

この場合、記憶媒体から読み出されたプログラムコード自体が上記実施の形態の機能を実現することになり、そのプログラムコード及び該プログラムコードを記憶した記憶媒体は本発明を構成することになる。

また、プログラムコードを供給するための記憶媒体としては、次のものを用いることができる。例えば、フロッピー（登録商標）ディスク、ハードディスク、光磁気ディスク、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＤＶＤ−ＲＷ、ＤＶＤ＋ＲＷ等の光ディスク、磁気テープ、不揮発性のメモリカード、ＲＯＭなどである。または、プログラムコードをネットワークを介してダウンロードしてもよい。

また、コンピュータが読み出したプログラムコードを実行することにより、上記実施の形態の機能が実現される場合も本発明に含まれる。加えて、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳなどが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現される場合も含まれる。

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

本発明の実施の形態に係るネットワークデバイス管理装置を含むネットワークシステムの構成を概略的に示すブロック図である。 図１のネットワークシステムにおいて実行されるデバイス探索に関する処理の第１の具体例を示す模式図である。 図１のネットワークシステムにおいて実行されるデバイス探索に関する処理の第２の具体例を示す模式図である。 図１においてディスカバリ・プロキシとして機能するデバイスの構成を詳細に示すブロック図である。 図４におけるスキャナ及びプリンタの外観を示す側面図である。 図４のディスカバリ・プロキシとして機能するデバイスのソフトウェア構成を詳細に示すブロック図である。 図１におけるデバイス管理ソフトウェアが動作するＰＣの構成を詳細に示すブロック図である。 図３におけるデバイス上のディスカバリ・プロキシが実行するデバイス探索処理のフローチャートである。 図８のステップＳ１０７のプローブマッチパケット受信処理の詳細を示すフローチャートである。 図８のステップＳ１０１において、デバイス管理ソフトウェアが動作するＰＣからデバイス上のディスカバリ・プロキシが受信したデバイス探索要求のデータ構造を例示する図である。 図１０のデータに連続するデータを示す図である。 図１０及び図１１に示したようなデバイス探索要求に対するレスポンスのデータ構造を例示する図である。 図１２のデータに連続するデータを示す図である。 図３におけるデバイス上のディスカバリ・プロキシが実行するデバイス起動メッセージ受信処理のフローチャートである。 図２，図３におけるデバイス上のディスカバリ・プロキシが実行するデバイスリスト取得要求応答処理のフローチャートである。 図１５のステップＳ４０１において、デバイス管理ソフトウェアが動作するＰＣからデバイス上のディスカバリ・プロキシが受信したデバイスリスト取得要求のデータ構造を例示する図である。 図１６のデータに連続するデータを示す図である。 図１６及び図１７に示したようなデバイスリスト取得要求に対するレスポンスのデータ構造を例示する図である。 図１８のデータに連続するデータを示す図である。 図１９のデータに連続するデータを示す図である。

符号の説明

１００，１０１ ＰＣ（パーソナルコンピュータ）
１０２ ルータ
１０３，１０４，１０５ デバイス
２０１ ＣＰＵ
１０００ ネットワークシステム
１５０３ ウェブサーバモジュール
１５０８ ディスカバリ・プロキシ（ＤＰ）モジュール
１５１６ ＴＣＰ／ＩＰモジュール
２０００ 制御部
２００１ ＣＰＵ
２０１１ ＬＡＮ
２０７０ スキャナ
２０９５ プリンタ

Claims (18)

1. ネットワーク上に配置された少なくとも１つのデバイスを管理するネットワークデバイス管理装置において、前記デバイスとの間でウェブサービスを用いた通信を行う通信手段を備え、前記通信手段は、前記ネットワーク上のデバイスを探索する探索手段と、前記デバイスのデバイス情報を取得する取得手段とを含むことを特徴とするネットワークデバイス管理装置。
2. 前記探索手段により探索されたデバイスのデバイス情報を保持する保持手段を備えることを特徴とする請求項１記載のネットワークデバイス管理装置。
3. 前記通信手段は、前記保持手段が保持しているデバイス情報を定期的に更新する更新手段を含むことを特徴とする請求項２記載のネットワーク管理装置。
4. 前記取得手段は、前記デバイスから起動に関する起動情報を取得し、前記探索手段は、前記取得した起動情報に基づいて前記探索を実行することを特徴とする請求項１乃至３のいずれか１項に記載のネットワーク管理装置。
5. 前記探索手段は、前記ネットワーク上のデバイスに探索パケットを送信し、前記取得手段は、前記探索パケットに応答したデバイスから当該デバイスのデバイス情報を取得することを特徴とする請求項１乃至３のいずれか１項に記載のネットワーク管理装置。
6. 前記通信手段は、前記探索手段が前記探索を実行すべき時刻が指定されているデバイス探索リクエストを前記ネットワーク上に配置されたサーバから受信する受信手段を含むことを特徴とする請求項１乃至５のいずれか１項に記載のネットワークデバイス管理装置。
7. 前記通信手段は、前記デバイス情報を前記ネットワーク上に配置された少なくとも１つのサーバへ送信する送信手段を含むことを特徴とする請求項１乃至６のいずれか１項に記載のネットワークデバイス管理装置。
8. 前記送信手段により送信されるデバイス情報は、前記ネットワークデバイス管理装置のデバイス情報を含むことを特徴とする請求項７記載のネットワークデバイス管理装置。
9. ネットワーク上に配置された少なくとも１つのデバイスを管理するネットワークデバイス管理装置によって実行されるネットワーク管理方法であって、前記ネットワーク管理装置と前記デバイスの間でウェブサービスを用いた通信を行う通信ステップの実行中に、前記ネットワーク上のデバイスを探索する探索ステップと、前記デバイスのデバイス情報を取得する取得ステップとを実行することを特徴とするネットワークデバイス管理方法。
10. 前記探索ステップにおいて探索したデバイスのデバイス情報を保持する保持ステップを有することを特徴とする請求項９記載のネットワークデバイス管理方法。
11. 前記通信ステップは、前記保持ステップにおいて保持したデバイス情報を定期的に更新する更新ステップを含むことを特徴とする請求項１０記載のネットワーク管理方法。
12. 前記取得ステップでは、前記デバイスから起動に関する起動情報を取得し、前記探索ステップでは、前記取得した起動情報に基づいて前記探索を実行することを特徴とする請求項９乃至１１のいずれか１項に記載のネットワーク管理方法。
13. 前記探索ステップでは、前記ネットワーク上のデバイスに探索パケットを送信し、前記取得ステップでは、前記探索パケットに応答したデバイスから当該デバイスのデバイス情報を取得することを特徴とする請求項９乃至１１のいずれか１項に記載のネットワーク管理装置。
14. 前記通信ステップは、前記探索ステップにおいて前記探索を実行すべき時刻が指定されているデバイス探索リクエストを前記ネットワーク上に配置されたサーバから受信する受信ステップを含むことを特徴とする請求項９乃至１３のいずれか１項に記載のネットワークデバイス管理方法。
15. 前記通信ステップは、前記デバイス情報を前記ネットワーク上に配置された少なくとも１つのサーバへ送信する送信ステップを含むことを特徴とする請求項９乃至１４のいずれか１項に記載のネットワークデバイス管理方法。
16. 前記送信ステップにおいて送信されるデバイス情報は、前記ネットワークデバイス管理装置のデバイス情報を含むことを特徴とする請求項１５記載のネットワークデバイス管理方法。
17. ネットワーク上に配置された少なくとも１つのデバイスを管理するネットワークデバイス管理装置が実行するためのコンピュータ読み取り可能なネットワークデバイス管理プログラムであって、前記ネットワークデバイス管理装置と前記デバイスの間でウェブサービスを用いた通信を行う通信モジュールを備え、当該通信モジュールは、前記ネットワーク上のデバイスを探索する探索モジュールと、前記デバイスのデバイス情報を取得する取得モジュールとを含むことを特徴とするネットワークデバイス管理プログラム。
18. 請求項１７記載のネットワークデバイス管理プログラムを格納したことを特徴とするコンピュータ読み取り可能な記憶媒体。

Images