JP5100414B2 - ネットワークデバイス管理装置及びその制御方法、ネットワークシステム、並びにプログラム - Google Patents

Description

本発明は、ネットワーク上の画像処理装置等のデバイスと通信可能なネットワークデバイス管理装置及びその制御方法に関する。また、前記デバイス及びネットワークデバイス管理装置と共にネットワーク上にクライアント装置を備えたネットワークシステム、並びに前記制御方法を実現するためのプログラムに関する。

ネットワークデバイスと通信するプロトコルとして、ＩＰｖ４（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ ｖｅｒｓｉｏｎ４）がある。ＩＰｖ４は、アドレス空間を３２ビットで表現するＯＳＩ（Ｏｐｅｎ Ｓｙｓｔｅｍ Ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ）ネットワーク層に位置するプロトコルであり、アドレッシング、ルーティング、誤り制御などを行う。

近年、インターネットの普及に伴うネットワークに接続する機器の増加から、ＩＰｖ４の３２ビットで表現されるアドレス空間が不足するという問題が起きている。そこで、アドレス空間を１２８ビットに拡張したＩＰｖ６（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ ｖｅｒｓｉｏｎ６）が開発され、その導入が進んでいる。

ＩＰｖ６において、１２８ビットのアドレス構造は、上位６４ビットのネットワークアドレスと、下位６４ビットのインターフェースＩＤとからなる。上位６４ビットは、グローバルルーティングプレフィックスとサブネットＩＤからなる。

ネットワークアドレスの違いにより、ステートフルアドレス、ステートレスアドレス、リンクローカルアドレスの３種類のアドレスを表現することができる。ステートフルアドレスは、ＤＨＣＰｖ６プロトコルを使用してＤＨＣＰサーバから取得したＩＰｖ６アドレスである。ＤＨＣＰはＤｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌの略語である。ステートレスアドレスは、ルータから通知される情報に基づきＩＰｖ６機器が自動的に生成するＩＰｖ６アドレスである。リンクローカルアドレスは、ＩＰｖ６機器が属するネットワーク（同一リンク）でのみ通信可能なＩＰｖ６アドレスである。ＩＰｖ６機器は、これらのアドレスを複数設定することが可能である。

一方、ＩＰｖ４が動作するネットワーク環境において、画像処理装置などのデバイスを管理するネットワークデバイス管理装置に関しては、例えば特許文献１に提案されるものがある。

このネットワークデバイス管理装置は、ネットワークに接続されたネットワークデバイスを探索し、デバイスの一覧表示を行う。ユーザは、デバイスの一覧の中から管理対象のデバイスを選択し、そのデバイスのエラー情報等を示すステータスを監視する。デバイスのステータス情報は、定期的にネットワークデバイス管理装置が取得している。また、ユーザは、管理対象デバイスのネットワーク設定などを変更する。例えば、対象デバイスのＩＰアドレスなどを変更する。このとき、ネットワーク管理装置は、ＳＮＭＰ／ＭＩＢを使用してデバイスの設定を変更する。ここで、ＳＮＭＰは、Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌの略語であり、ＭＩＢは、Ｍａｓｔｅｒ Ｉｎｆｏｒｍａｔｉｏｎ Ｂｌｏｃｋの略語である。

また、この特許文献１によると、ネットワークデバイスがＷｅｂサーバを内蔵する場合、Ｗｅｂブラウザが動作するクライアント装置は、ネットワークデバイス管理装置のＷｅｂサーバに直接アクセスし、デバイス情報を取得して表示する。また、デバイスがＷｅｂサーバを内蔵しない場合、前記クライアント装置は、ネットワークデバイス管理装置にＳＮＭＰプロトコルによってデバイスからＭＩＢ情報を収集することを要求する。そして、前記クライアント装置は、ネットワークデバイス管理装置が取得したデバイス情報を受信し、Ｗｅｂブラウザに表示を行う。
特開２００３−３３０８２４号公報

しかしながら上記特許文献１は、ネットワーク上のデバイスと、Ｗｅｂブラウザが動作するクライアント装置とがＩＰｖ４により通信することが前提となっている。そのため、ＩＰｖ４とＩＰｖ６が混在する環境や、複数のアドレスが設定可能なＩＰｖ６で動作するネットワーク機器については考慮されていなかった。

即ち、ブラウザがＩＰｖ４、デバイスがＩＰｖ６で動作している場合、もしくはブラウザがＩＰｖ６、デバイスがＩＰｖ４で動作している場合、ブラウザとデバイスが通信できずにブラウザに通信エラー画面が表示されるという問題がある（図１９（ａ）参照）。

さらに、ブラウザとデバイスが共にＩＰｖ６で動作している環境においても、デバイスに複数設定されているＩＰｖ６アドレスの中から通信可能なアドレスを選択することができない。そのため、ブラウザに通信エラー画面が表示されてしまうという問題があった（図１９（ｂ）参照）。

本発明は上記従来の問題点に鑑み、次のような、ネットワークデバイス管理装置及びその制御方法、ネットワークシステム、並びにプログラムを提供することを目的とする。即ち、例えばＩＰｖ４とＩＰｖ６のように、異なるプロトコルが混在するネットワーク環境や、例えばＩＰｖ６のような特定のプロトコルで動作するネットワーク機器間において、通信エラー画面が表示されることなく操作性が良好なネットワーク環境を構築する。

上記目的を達成するため、本発明のネットワークデバイス管理装置は、ネットワーク上のデバイス及びクライアント装置と通信可能に接続されるネットワークデバイス管理装置において、前記クライアント装置から、前記デバイスへのアクセス要求を受け付ける受け付け手段と、前記受け付け手段によって受け付けた前記アクセス要求を送信した前記クライアント装置のアドレスを取得する第一の取得手段と、前記受け付け手段によって受け付けた前記アクセス要求の対象となる前記デバイスのアドレスを取得する第二の取得手段と、前記第一の取得手段により取得された前記クライアント装置のアドレスと前記第二の取得手段により取得された前記デバイスのアドレスのＩＰバージョンが一致するか否かを判定する判定手段と、前記判定手段により前記クライアント装置のアドレスと前記デバイスのアドレスのＩＰバージョンが一致しないと判定されたときは前記ネットワークデバイス管理装置が前記デバイスから取得したデバイス情報を前記クライアント装置に送信し、前記クライアント装置のアドレスと前記デバイスのアドレスのＩＰバージョンが一致すると判定されたときは前記クライアント装置に前記デバイスのアドレスを送信する送信手段とを備えたことを特徴とする。

また、本発明のネットワークデバイス管理装置の制御方法は、ネットワーク上のデバイス及びクライアント装置と通信可能に接続されるネットワークデバイス管理装置の制御方法であって、前記クライアント装置から、前記デバイスへのアクセス要求を受け付ける受け付け工程と、前記受け付け工程によって受け付けた前記アクセス要求を送信した前記クライアント装置のアドレスを取得する第一の取得工程と、前記受け付け手段によって受け付けた前記アクセス要求の対象となる前記デバイスのアドレスを取得する第二の取得工程と、前記第一の取得工程にて取得された前記クライアント装置のアドレスと前記第二の取得工程にて取得された前記デバイスのアドレスのＩＰバージョンが一致するか否かを判定する判定工程と、前記判定工程にて前記クライアント装置のアドレスと前記デバイスのアドレスのＩＰバージョンが一致しないと判定されたときは前記ネットワークデバイス管理装置が前記デバイスから取得したデバイス情報を前記クライアント装置に送信し、前記クライアント装置のアドレスと前記デバイスのアドレスのＩＰバージョンが一致すると判定されたときは前記クライアント装置に前記デバイスのアドレスを送信する送信工程とを有することを特徴とする。

また、本発明のネットワークシステムは、ネットワーク上のデバイス及びクライアント装置と、前記デバイス及び前記クライアント装置と通信可能に接続されるネットワークデバイス管理装置とを備えたネットワークシステムであって、前記ネットワークデバイス管理装置は、前記クライアント装置から、前記デバイスへのアクセス要求を受け付ける受け付け手段と、前記受け付け手段によって受け付けた前記アクセス要求を送信した前記クライアント装置のアドレスを取得する第一の取得手段と、前記受け付け手段によって受け付けた前記アクセス要求の対象となる前記デバイスのアドレスを取得する第二の取得手段と、前記第一の取得手段により取得された前記クライアント装置のアドレスと前記第二の取得手段により取得された前記デバイスのアドレスのＩＰバージョンが一致するか否かを判定する判定手段と、前記判定手段により前記クライアント装置のアドレスと前記デバイスのアドレスのＩＰバージョンが一致しないと判定されたときは前記ネットワークデバイス管理装置が前記デバイスから取得したデバイス情報を前記クライアント装置に送信し、前記クライアント装置のアドレスと前記デバイスのアドレスのＩＰバージョンが一致すると判定されたときは前記クライアント装置に前記デバイスのアドレスを送信する送信手段とを備えたことを特徴とする。

また、本発明のプログラムは、ネットワーク上のデバイス及びクライアント装置と通信可能に接続されるネットワークデバイス管理装置の制御方法を実行するための、コンピュータで読み取り可能なプログラムであって、前記クライアント装置から、前記デバイスへのアクセス要求を受け付ける受け付けステップと、前記受け付けステップによって受け付けた前記アクセス要求を送信した前記クライアント装置のアドレスを取得する第一の取得ステップと、前記受け付けステップによって受け付けた前記アクセス要求の対象となる前記デバイスのアドレスを取得する第二の取得ステップと、前記第一の取得ステップにより取得された前記クライアント装置のアドレスと前記第二の取得ステップにより取得された前記デバイスのアドレスのＩＰバージョンが一致するか否かを判定する判定ステップと、前記判定ステップにより前記クライアント装置のアドレスと前記デバイスのアドレスのＩＰバージョンが一致しないと判定されたときは前記ネットワークデバイス管理装置が前記デバイスから取得したデバイス情報を前記クライアント装置に送信し、前記クライアント装置のアドレスと前記デバイスのアドレスのＩＰバージョンが一致すると判定されたときは前記クライアント装置に前記デバイスのアドレスを送信する送信ステップとを備えたことを特徴とする。

本発明によれば、異なるプロトコルが混在するネットワーク環境や、特定のプロトコルで動作するネットワーク機器間において、通信エラー画面が表示されることなく操作性が良好なネットワーク環境を構築することが可能になる。

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

［第１の実施の形態］
〈システム構成〉
図１は、本発明の実施の形態に係るネットワークシステムの構成を示す模式図である。

このネットワークシステムは、ＬＡＮ等のネットワーク４００上に、ネットワークデバイス管理装置１００と、パーソナルコンピュータ（ＰＣ）から成るクライアント装置２００と、画像処理装置であるデバイス３００とが接続されている。

ネットワークデバイス管理装置１００には、デバイス管理アプリケーション１０１が動作し、クライアント装置２００にはブラウザ１０２が動作する。

ブラウザ１０２は、ＩＴ管理者１０３が操作するクライアント装置２００上で動作するＷｅｂブラウザである。ＩＴ管理者１０３は、ブラウザ１０２を使用してネットワーク４００上に存在するデバイスを遠隔地から管理する。例えば、デバイスのステータスを取得し、エラーが起きているデバイスを見つけ、そのデバイスのエラーを復旧し印刷可能な状態にする。

デバイス管理アプリケーション１０１は、ブラウザ１０２からの要求に応じて、ネットワーク４００上のデバイス（デバイス３００を含む）を管理する。デバイス管理アプリケーション１０１は、ブラウザ１０２からの、デバイス情報の取得要求に従って、デバイスからデバイス情報を取得したり、デバイス設定の変更要求に従って、デバイスの設定を適切な値を設定したりする。

例えばデバイス３００は、ネットワーク４００上に存在する画像処理装置であり、デバイス管理アプリケーション１０１からの要求に従い、デバイス情報を返信したり、デバイス内部の設定値を変更したりする。また、デバイス３００は、ブラウザ１０２からのＷｅｂページ表示要求に対し、デバイス情報を含むＨＴＭＬデータの返信を行う。

〈システムにおける各機器の構成〉
図２は、画像処理装置から成るデバイス３００の構成を示すブロック図である。

デバイス３００は、主にリーダ部１、プリンタ部２、及び画像入出力制御部３で構成されている。リーダ部１は、プリンタ部２及び画像入出力制御部３に接続され、原稿の画像読み取りを行うとともに、読み取った画像データをプリンタ部２又は画像入出力制御部３に出力する。プリンタ部２は、リーダ部１及び画像入出力制御部３から出力された画像データを記録紙に印刷する。画像入出力制御部３は、外部のネットワーク４００や公衆回線網と接続して画像データの入出力を行う。

画像入出力制御部３は、ファクシミリ部４、ファイル部５、記憶装置６、ネットワークインターフェース部７、ＰＤＬフォーマッタ部８、画像メモリ部９、及びコア部１０で構成される。ファイル部５は、コア部１０及び記憶装置６に接続され、コア部１０から送信された画像データの圧縮を行い、圧縮した画像データを検索するためのキーワードと共に記憶装置６に記憶する。また、記憶装置６には、画像データのみならずＣＰＵ１７で実行するアプリケーションプログラム等を格納する。

ネットワークインターフェース部７は、外部のネットワーク４００を介して接続されたネットワークデバイス管理装置１００やクライアント装置２００とコア部１０との間のインターフェースである。このネットワークインターフェース部７には、Ｗｅｂサーバが内蔵されているものとする。

フォーマッタ部８は、コア部１０に接続され、クライアント装置２００から送信されたＰＤＬデータをプリンタ部２でプリント可能な画像データに展開するものである。画像メモリ部９は、リーダ部１からの読み取り画像情報や、ネットワークインターフェース部７を介してクライアント装置２００等から送られてきた画像情報を一時的に蓄積しておくためのものである。

コア部１０は、上述したリーダ部１、ファクシミリ部４、ファイル部５、ネットワークインターフェース部７、及びフォーマッタ部８のそれぞれの間を流れるデータ等の制御を行う。さらに、ジョブ制御データの解析を行い、ユーザの使用状況・コピー枚数・印刷枚数・スキャン枚数等の情報をＲＡＭ１８或いは記憶装置６へ蓄積するよう制御する。また、コア部１０では、画像データに対する変倍、回転、解像度変換、フォーマット変換などの画像処理も行う。コア部１０内のＣＰＵ１７は、ＲＯＭ１９或いは記憶装置６に格納されたアプリケーションプログラムをＲＡＭ１８へロードして実行することで、画像入出力制御部３の全体の各種制御を司る。

図３は、デバイス３００のＩＰｖ６設定画面を示す表示画面図である。

“ＩＰｖ６を使用”３０１をＯＮに設定することにより、本デバイス３００のＩＰｖ６（第２のプロトコル）機能を有効にすることができる。図３では、それぞれ３０２、３０３に示すように、ステートレスアドレスとステートフルアドレスが有効になっている例を示している。本デバイス３００の例では、ステートレスアドレス５つ、ステートフルアドレス１つが設定されている。

図４は、図１中のネットワークデバイス管理装置１００及びクライアント装置２００の構成を示すブロック図である。

ネットワークデバイス管理装置１００は、各種プログラムを実行するＣＰＵ２２０１を備えており、ＣＰＵ２２０１は、システムバス２２０４を介して、各種のハードウェアモジュールに接続されている。

即ち、システムバス２２０４には、ＲＯＭ２２０２及びＲＡＭ２２０３が接続されている。さらには、ディスクコントローラ（ＤＫＣ）２２０７を介してハードディスク（ＨＤ）２２１１が接続されている。ＲＯＭ２２０２又はハードディスク（ＨＤ）２２１１には、本実施の形態に係るソフトウェア上の制御の主体であるデバイス管理アプリケーション１０１等のプログラムが格納されている。ＲＡＭ２２０３は、ＣＰＵ２２０１の主メモリやワークエリアなどに使用される。

なお、デバイス管理アプリケーション１０１は、ＤＶＤやＣＤ−ＲＯＭなどの記憶媒体に格納された形で供給されても良い。その場合には図４に示すＤＶＤコントローラ（ＤＶＤ）２２１２又は不図示のＣＤ−ＲＯＭドライブなどによって記憶媒体からプログラムが読み取られ、ハードディスク（ＨＤ）２２１１にインストールされる。

また、システムバス２２０４には、ネットワークインターフェースカード（ＮＩＣ）２２０８が接続されている。ネットワークインターフェースカード２２０８は、ＬＡＮ４００を介して、クライアント装置２００やデバイス３００等の他のネットワーク機器と双方向にデータをやりとりする。

さらに、システムバス２２０４には、キーボードコントローラ（ＫＢＣ）２２０５及びＣＲＴコントローラ（ＣＲＴＣ）２２０６が接続されている。キーボードコントローラ（ＫＢＣ）は、キーボード（ＫＢ）２２０９や不図示のポインティングデバイス等からの指示入力を制御する。ＣＲＴコントローラ（ＣＲＴＣ）２２０６は、ＣＲＴディスプレイ（ＣＲＴ）２２１０の表示を制御する。

また、クライアント装置２００も図４に示すように、ネットワークデバイス管理装置１００と同様の構成である。但し、ハードディスク（ＨＤ）２２１１には、ブラウザ１０２が格納されている。

〈デバイス管理アプリケーションの構成〉
次に、デバイス管理アプリケーション１０１の構成について説明する。

図５は、デバイス管理アプリケーション１０１の構成を示したブロック図である。

デバイス管理アプリケーション１０１は、ＨＴＭＬ画面生成部５０１、アドレス判定部５０２、クライアント通信部５０３、デバイス探索部５０４、デバイス情報取得部５０５、デバイス通信部５０６、及びデバイス情報保持部５０７から構成される。

ＨＴＭＬ画面生成部５０１は、ブラウザ１０２に出力するＨＴＭＬデータを生成する。アドレス判定部５０２は、ブラウザ１０２が動作しているクライアント装置２００から取得したアドレスとデバイス３００から取得したアドレスを比較して通信可能なアドレスを選択する。これらのアドレスは、ＩＰｖ４、またはこれを更新したＩＰｖ６で定義されたアドレスである。

クライアント通信部５０３は、ブラウザ１０２が動作しているクライアント装置２００に設定されているアドレスの取得、ＨＴＭＬ画面の送受信を行う。

デバイス探索部５０４は、ネットワーク上のデバイスを探索し、そのデバイスに関する情報をデータベース５０８に保持する。探索時にデバイスに設定されている全ＩＰアドレス情報、ＩＰｖ４及びＩＰｖ６のＯＮ／ＯＦＦ設定情報、ＩＰｖ６のアドレス種類（ステートレス、ステートフル、リンクローカル）、ＦＱＤＮ名を取得しデータベース５０８に格納する。デバイス情報取得部５０５は、デバイスのＩＰアドレス、ロケーション情報、オプション構成などデバイスに関する情報を取得する。デバイス通信部５０６は、ＳＮＭＰｖ１／ＳＮＭＰｖ３／Ｗｅｂサービス等のプロトコルを用いて、デバイスと通信する。デバイス情報保持部５０７は、デバイスから取得した情報をデータベース５０８に保持する。

図６は、デバイス管理アプリケーション１０１により表示されるデバイスリスト画面を示す表示画面図である。

この画面に表示されるデバイス一覧は、デバイス探索部５０４がデータベース５０８に格納したデバイスに関する情報を取得することにより、表示がなされる。

〈ネットワーク機器間のシーケンス〉
図７は、第１の実施の形態に係るネットワークシステムのシーケンスを示すシーケンス図であり、ブラウザ１０２、デバイス管理アプリケーション１０１、及びデバイス３００の間のシーケンスを示している。また、図８は、ブラウザ１０２に表示されるＲＵＩ画面の一例を示す画面図であり、図９は、ブラウザ１０２に表示されるデバイス詳細画面の一例を示す画面図である。

ＩＴ管理者１０３は、ブラウザ１０２によりネットワーク４００上のデバイスを管理している。ブラウザ１０２にはデバイスの一覧が表示され、管理対象のデバイスがリスト表示されている。ここで、ＩＴ管理者１０３は特定のデバイス３００の詳細情報を参照するために、デバイス３００に内蔵されているＷｅｂサーバにアクセスし、図８に示すようなデバイス情報（以下、ＲＵＩと呼ぶ）を表示しようとする。ＲＵＩは、Ｒｅｍｏｔｅ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅの略語である。

このとき、ブラウザ１０２は、デバイス管理アプリケーション１０１にＲＵＩ表示要求（アクセス要求）を送信する（Ｓ１１）。デバイス管理アプリケーション１０１は、ブラウザ１０２が動作しているクライアント装置２００のアドレスと、ジャンプ先のＲＵＩが存在するデバイス３００のアドレスとを比較する。そして、ブラウザ１０２とデバイス３００が通信可能であるか否かを判定する（Ｓ１２）。

ブラウザ１０２とデバイス３００が通信可能な場合、デバイス管理アプリケーション１０１は、通信可能なデバイス３００のアドレスにリダイレクトするようにリダイレクト要求をブラウザ１０２に送信する（Ｓ１３）。リダイレクト要求とは、ＨＴＴＰにおけるサーバからの応答の種類の１つで、ブラウザ１０２にＵＲＬが変更されたことを知らせる機能である。なお、ＨＴＴＰとは、Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏの略語であり、ＵＲＬとは、Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒの略語である。その後、デバイス３００は、ブラウザ１０２からのＲＵＩ表示要求を受け付け（Ｓ１４）、ブラウザ１０２にＲＵＩ画面（図８参照）を返信する（Ｓ１５）。

一方、デバイス３００とブラウザ１０２が通信できない場合、デバイス管理アプリケーション１０１は、ＳＮＭＰｖ１／ＳＮＭＰｖ３／Ｗｅｂサービス等のデバイス３００と通信可能なプロトコルを用いて、デバイス３００から情報を取得する（Ｓ２１、Ｓ２２）。そして、デバイス管理アプリケーション１０１は、デバイス詳細画面（図９参照）を生成し、ブラウザ１０２に返信する（Ｓ２３）。

〈デバイス管理アプリケーションの動作〉
次に、図７のシーケンスにおける、本実施の形態に係るデバイス管理アプリケーション１０１の動作について、図１０〜図１４のフローチャートを参照して説明する。

（Ａ）全体フロー
図１０は、第１の実施の形態に係るデバイス管理アプリケーション１０１の動作を示したフローチャートである。

まずＳ１−１において、デバイス管理アプリケーション１０１はブラウザ１０２からデバイス３００のＲＵＩへジャンプする要求を受信する。次のＳ１−２において、デバイス管理アプリケーション１０１は、ＲＵＩへのジャンプ要求を示すリクエストデータから送信先アドレス（ブラウザ１０２が動作しているＰＣのアドレス）を抽出する。

続くＳ１−３では、デバイス管理アプリケーション１０１は、例えばｇｅｔａｄｄｒｉｎｆｏ関数を用いて、ブラウザ１０２が動作しているクライアント装置２００に設定されているアドレス一覧を取得する（第一の取得処理）。さらにＳ１−４において、デバイス管理アプリケーション１０１は、ＲＵＩへのジャンプ要求を示すリクエストデータからデバイス３００のアドレスを取得する（第二の取得処理）。また、Ｓ１−５において、デバイス探索時に保持してあるデバイス３００のアドレス一覧をデータベース５０８から取得する。

そして、Ｓ１−６において、デバイス管理アプリケーション１０１はブラウザ１０２とデバイス３００とが通信可能であるかの通信可否を判断する。Ｓ１−６の判断に関する詳細は別途説明する。

ブラウザ１０２とデバイス３００が通信可能な場合、デバイス管理アプリケーション１０１はＳ１−７に進み、通信可能なデバイス３００のアドレスにリダイレクトする。具体的には、“ＩＰｖ６を使用”３０１をＯＮに設定し、Ｌｏｃａｔｉｏｎにｈｔｔｐ：／／（通信可能なデバイス３００のアドレス）を設定したＨＴＴＰレスポンスをブラウザ１０２に返信する。リダイレクト要求を受けたブラウザ１０２は、デバイス３００と通信し、ＲＵＩ画面を表示することが可能になる。

ブラウザ１０２とデバイス３００が通信できない場合、デバイス管理アプリケーション１０１はＳ１−８に進み、ＳＮＭＰｖ１／ｖ３／Ｗｅｂサービスなどのプロトコルを用いて、デバイス３００から例えばステータス、設置場所などのデバイス情報を取得する。このとき、デバイス管理アプリケーション１０１は、デバイス探索時にデバイス３００が返信したアドレスを使用する。

Ｓ１−９において、デバイス管理アプリケーション１０１は、デバイス３００から取得したデバイス情報をＨＴＭＬに変換してデバイス詳細画面を作成し、ブラウザ１０２に返信する（第一の送信処理）。ＨＴＭＬを受信したブラウザ１０２は、デバイス詳細画面を表示することが可能になる。

（Ｂ）通信判定処理Ｓ１−６の詳細
次に、図１１のフローチャートを用いて、図１０のＳ１−６の詳細を説明する。

図１１は、図１０のＳ１−６の詳細を示すフローチャートである。

まずＳ２−１において、デバイス管理アプリケーション１０１は、ブラウザ１０２、デバイス３００が共にＩＰｖ４で動作しているかチェックする。ブラウザ１０２のアドレスは、ＨＴＴＰリクエストの送信元アドレスから取得する。デバイス３００のＩＰアドレスはデバイス探索時に取得してデータベース５０８に格納してある。

このブラウザ１０２とデバイス３００のアドレスを比較して、ブラウザ１０２、デバイス３００が共にＩＰｖ４（第１のプロトコル）で動作しているか判断する。共にＩＰｖ４の場合、Ｓ２−２に進み、デバイス管理アプリケーション１０１は、従来のシーケンスを実行し、処理を終了する。

ここで、従来のシーケンスとは、デバイス３００がＷｅｂサーバを内蔵する場合には、デバイス管理アプリケーション１０１は、ブラウザとデバイスとが通信可能であると判断してデバイス３００にリダイレクトする。また、デバイス３００がＷｅｂサーバを内蔵していない場合には、デバイスからＳＮＭＰによりデバイス情報を取得する（特開２００３−３３０８２４号公報の図８参照）。

ブラウザ１０２とデバイス３００が共にＩＰｖ４でない場合、デバイス管理アプリケーション１０１は、Ｓ２−３に進み、ブラウザ１０２とデバイス３００のＩＰバージョンが異なるかチェックする。ＩＰバージョンが異なるとは、ブラウザ１０２がＩＰｖ４のみ、デバイス３００がＩＰｖ６（第２のプロトコル）のみ使用されている、もしくは、ブラウザ１０２がＩＰｖ６のみ、デバイス３００がＩＰｖ４のみ使用されていることを示す。

ブラウザ１０２とデバイス３００のＩＰバージョンが異なるとき、デバイス管理アプリケーション１０１は、図１０のＳ１−８に進み、デバイス３００から情報取得を行う。
ブラウザ１０２とデバイス３００が共にＩＰｖ６のとき、Ｓ２−４に進み、デバイス管理アプリケーション１０１は、ブラウザ１０２、デバイス管理アプリケーション１０１、デバイス３００のＩＰｖ６アドレスのプレフィックスが全て同じかチェックする。

プレフィックスの比較は、ＩＰｖ６アドレスのネットワークアドレス部分である上位６４ビットの値を比較する。３つとも同一のプレフィックスの場合、ブラウザ１０２、デバイス３００、デバイス管理アプリケーション１０１は、同一のネットワークに存在しているので互いに通信可能と判断する。そして、デバイス管理アプリケーション１０１は、図１０のＳ１−７に進み、デバイス３００のアドレスへリダイレクトする要求をブラウザ１０２に送信する（第二の送信処理）。

プレフィックスが異なるとき、Ｓ２−５に進み、デバイス管理アプリケーション１０１は、ブラウザ１０２とデバイス３００が同一のプレフィックスを持つかチェックする。同一のプレフィックスを持つ場合、ブラウザ１０２とデバイス３００は同一のネットワークに存在しているので互いに通信可能と判断する。そして、デバイス管理アプリケーション１０１は、図１０のＳ１−７に進み、デバイス３００のアドレスへリダイレクトする要求をブラウザ１０２に送信する。

ブラウザ１０２とデバイス３００が異なるプレフィックスを持つ場合、Ｓ２−６に進み、デバイス管理アプリケーション１０１は、デバイス管理アプリケーション１０１とデバイス３００が同一のプレフィックスを持つかチェックする。同一のプレフィックスを持つ場合、デバイス管理アプリケーション１０１とデバイス３００は同一のネットワークに存在している。そのため、デバイス管理アプリケーション１０１と通信可能なブラウザ１０２は、デバイス３００とも通信可能と判断する。そして、デバイス管理アプリケーション１０１は、図１０のＳ１−７に進み、デバイス３００のアドレスへリダイレクトする要求をブラウザ１０２に送信する。

デバイス管理アプリケーション１０１とデバイス３００が異なるプレフィックスを持つ場合、Ｓ２−７に進み、デバイス管理アプリケーション１０１は、ブラウザ１０２とデバイス管理アプリケーション１０１のプレフィックスが同じものがあるかをチェックする。同じプレフィックスがある場合、デバイス管理アプリケーション１０１は、判定処理１を行う。同じプレフィックスがない場合、デバイス管理アプリケーション１０１は、Ｓ２−９へ進む。

Ｓ２−９において、デバイス管理アプリケーション１０１は、ＳＮＭＰプロトコルを用いてデバイス３００のルーティング情報を取得する。ルーティング情報とは、ルータやデバイスなどのネットワーク機器が保持するパケットの配送先に関する経路情報である。ＩＰｖ６の場合、経路情報として、ネットワークアドレスのテーブルを保持する。

次のＳ２−１０において、デバイス管理アプリケーション１０１は、ブラウザ１０２とデバイス３００が通信可能なプレフィックスがあるかをチェックする。デバイス３００のルーティング情報に、ブラウザ１０２のネットワークアドレスが含まれている場合、デバイス３００はブラウザ１０２に直接パケットを転送できる。そのため、デバイス３００とブラウザ１０２は通信可能と判断することができる。

通信可能なプレフィックスがある場合、Ｓ１−７に進み、デバイス管理アプリケーション１０１は、通信可能なプレフィックスを持つデバイス３００のＩＰｖ６アドレスにリダイレクトするようにブラウザ１０２に要求する。

通信可能なプレフィックスがない場合、Ｓ２−１１に進み、デバイス管理アプリケーション１０１は、判定処理２を行うかどうかをチェックする。判定処理２を行う場合、Ｓ２−１２に進み、デバイス管理アプリケーション１０１は判定処理２を行う。判定処理２の詳細は別途説明する。判定処理２を行わない場合、Ｓ１−８に進み、デバイス管理アプリケーション１０１はデバイス３００から情報取得を行う。

次に、上述したＳ２−９以降の処理について他の例を２つ説明する。

上記Ｓ２−７において、ブラウザ１０２とデバイス管理アプリケーション１０１のプレフィックスが同じものがあるかをチェックする。そして、同じプレフィックスがない場合、デバイス管理アプリケーション１０１は、上述したＳ２−９〜Ｓ２−１２処理に代わって、以下のような処理を行っても構わない。この処理について、第１の処理例、第２の処理例として説明する。

第１の処理例は次のようなものである。

即ち、上記Ｓ２−７のチェックにおいて、同じプレフィックスがないと判定した場合には、デバイス管理アプリケーション１０１は、ＳＮＭＰプロトコルを用いてブラウザ１０２が動作しているクライアント装置２００のルーティング情報を取得する。そして、デバイス管理アプリケーション１０１は、ブラウザ１０２とデバイス３００が通信可能なプレフィックスがあるかをチェックする。

ブラウザ１０２が動作しているクライアント装置２００のルーティング情報に、デバイス３００のネットワークアドレスが含まれている場合、ブラウザ１０２はデバイス３００に直接パケットを転送できる。そのため、ブラウザ１０２はデバイス３００と通信可能と判断することができる。

通信可能なプレフィックスがある場合、デバイス管理アプリケーション１０１は、通信可能なプレフィックスを持つデバイス３００のＩＰｖ６アドレスにリダイレクトするようにブラウザ１０２に要求する（Ｓ２−７参照）。通信可能なプレフィックスがない場合、デバイス管理アプリケーション１０１は、判定処理２を行うかどうかをチェックする。判定処理２を行う場合、デバイス管理アプリケーション１０１は、後述する判定処理２を実行する。判定処理２を行わない場合、デバイス管理アプリケーション１０１はデバイス３００から情報取得を行う（Ｓ１−８参照）。

第２の処理例は次のようなものである。

上記Ｓ２−７のチェックにおいて、同じプレフィックスがないと判定した場合には、デバイス管理アプリケーション１０１は、ルータのルーティング情報を取得する。そして、デバイス管理アプリケーション１０１は、ブラウザ１０２とデバイス３００が通信可能なプレフィックスがあるかをチェックする。ルータのルーティング情報がブラウザ１０２のプレフィックスとデバイス３００のプレフィックスを両方含み、かつ、直接転送が可能な場合、ブラウザ１０２とデバイス３００は通信可能と判断することができる。

通信可能なプレフィックスがある場合、前述したＳ１−７の処理を実行する。通信可能なプレフィックスがない場合、判定処理２を行うかどうかをチェックして、上記第１の処理例と同様の処理を行う。

（Ｂ−１）判定処理１の詳細
次に、上記判定処理１の詳細について、図１２（ａ）、（ｂ）を参照して説明する。

図１２（ａ）、（ｂ）は、図１１中の判定処理１（Ｓ２−８）の詳細を示すフローチャートであり、同図（ａ）は、第１の例であり、同図（ｂ）は第２の例である。デバイス管理アプリケーション１０１は、判定処理１として、図１２（ａ）、図１２（ｂ）のいずれかのフローチャートに従って処理を行う。

図１２（ａ）に示す判定処理１の第１の例は、次のようなものである。

まず、Ｓ３ａ−１において、デバイス管理アプリケーション１０１は、探索時にレスポンスパケットのソースアドレスとして返信されたデバイス３００のＩＰｖ６アドレスをデータベース５０８から取得する。その後、Ｓ１−７に進み、デバイス管理アプリケーション１０１は、そのアドレスにリダイレクトするようにブラウザ１０２に要求する。

図１２（ｂ）に示す判定処理１の第２の例は、次のようなものである。

まずＳ３ｂ−１において、デバイス管理アプリケーション１０１は、データベース５０８からデバイス３００に設定されているＩＰｖ６アドレスを全て取得する。次にＳ３ｂ−２において、デバイス管理アプリケーション１０１は、ＰＩＮＧパケットをデバイス３００に送信し、Ｓ３ｂ−３において、デバイス３００から返信があるかを確認する。

デバイス３００から返信がある場合、Ｓ１−７に進み、デバイス管理アプリケーション１０１は、返信のあったＩＰｖ６アドレスにリダイレクトする要求をブラウザ１０２に送る。デバイス３００から返信がない場合、Ｓ３ｂ−４に進み、デバイス管理アプリケーション１０１は、次のＩＰｖ６アドレスを用いてＰＩＮＧパケットによる通信チェックを繰り返す。データベース５０８には、デバイス探索時に通信したアドレスが含まれているため、デバイス管理アプリケーション１０１とデバイス３００が通信可能なＩＰｖ６アドレスが少なくとも１つ含まれている。

判定処理１は、ブラウザ１０２とデバイス管理アプリケーション１０１が同一のプレフィックスを持つ場合、行われる処理である。このとき、ブラウザ１０２とデバイス管理アプリケーション１０１は同一のネットワークに存在する。デバイス管理アプリケーション１０１とデバイス３００が通信可能な場合、同一のネットワークに存在するブラウザ１０２もデバイス３００と通信可能と判断する。

（Ｂ−２）判定処理２の詳細
次に、上記判定処理２の詳細について、図１３、図１４及び図１５を参照して説明する。図１３、図１４及び図１５は、図１１中の判定処理２（Ｓ２−１２）の詳細を示すフローチャートであり、図１３は、第１の例であり、図１４は第２の例であり、図１５は第３の例を示している。デバイス管理アプリケーション１０１は、判定処理２として、図１３、図１４、図１５のいずれかのフローチャートに従って処理を行う。判定処理２は、ユーザが予め判定処理２を行うように設定している場合に実行される。

図１３に示す判定処理２の第１の例は、次のようなものである。

まずＳ５ａ−１において、デバイス管理アプリケーション１０１は、デバイス３００のＲＵＩへのジャンプ要求に対して、ユーザがＦＱＤＮ名を使用するに設定してあるかをチェックする。ＦＱＤＮ名とは、ネットワーク機器を一意に識別可能な名前であって、例えば、「ｐｃ１２３．ａｂｃｄ．ｃｏｍ」のように記載される。

ＦＱＤＮ名を使用しない場合、Ｓ１−８に進み、デバイス管理アプリケーション１０１は、デバイス３００から情報取得を行う。ＦＱＤＮ名を使用する場合、Ｓ５ａ−２に進み、デバイス管理アプリケーション１０１は、データベース５０８からデバイス探索時に保持してあるデバイス３００のＦＱＤＮ名を取得する。

Ｓ５ａ−３において、デバイス管理アプリケーション１０１は、ＦＱＤＮ名が取得できたかどうかを判定する。取得できた場合、Ｓ１−７に進み、デバイス管理アプリケーション１０１は、ＦＱＤＮ名を使用してデバイス３００にリダイレクトする要求をブラウザ１０２に送信する。取得できなかった場合、Ｓ１−８に進み、デバイス管理アプリケーション１０１はデバイス３００から情報取得を行う。

図１４に示す判定処理２の第２の例は、次のようなものである。

まずＳ５ｂ−１において、デバイス管理アプリケーション１０１は、デバイス３００のＲＵＩへのジャンプ要求に対して、ユーザが予め設定するユーザ設定において「ＩＰｖ６アドレス種類情報を使用する」に設定してあるかをチェックする。ＩＰｖ６アドレス種類情報を使用しない場合、Ｓ１−８に進み、デバイス管理アプリケーション１０１は、デバイス３００から情報取得を行う。

ＩＰｖ６アドレス種類情報を使用する場合、Ｓ５ｂ−２に進み、デバイス管理アプリケーション１０１はデータベース５０８からＩＰｖ６アドレス種類情報を取得する。Ｓ５ｂ−３において、デバイス管理アプリケーション１０１は、データベース５０８からデバイス３００のＩＰｖ６アドレスとそのアドレス種類を取得する。

次のＳ５ｂ−４において、デバイス管理アプリケーション１０１は、取得したＩＰｖ６アドレスが、リダイレクトするＩＰｖ６アドレス種類かをチェックする。リダイレクトするＩＰｖ６アドレス種類の場合、Ｓ１−７に進み、デバイス管理アプリケーション１０１は、リダイレクトする要求をブラウザ１０２に送信する。

取得したＩＰｖ６アドレスが、リダイレクトしないＩＰｖ６アドレス種類の場合、Ｓ５ｂ−５に進み、デバイス管理アプリケーション１０１は全てのデバイス３００のＩＰｖ６アドレスをチェックしたかを判定する。全てのＩＰｖ６アドレスをチェックしていない場合、Ｓ５ｂ−６に進み、デバイス管理アプリケーション１０１はデバイス３００のＩＰｖ６アドレス一覧から次のＩＰｖ６アドレスを選択する。

全てのＩＰｖ６アドレスをチェックしている場合、Ｓ１−８に進み、デバイス管理アプリケーション１０１はデバイス３００から情報取得を行う。ＩＰｖ６アドレス種類情報のユーザ設定のデフォルト値は、ステートレスアドレスの場合、リダイレクトする設定である。

図１５に示す判定処理２の第３の例は、次のようなものである。

まずＳ５ｃ−１において、デバイス管理アプリケーション１０１は、デバイス３００のＲＵＩへのジャンプ要求に対して、ユーザが予め設定するユーザ設定において「ルーティング情報を使用する」に設定してあるかをチェックする。ユーザ設定のルーティング情報を使用しない場合、Ｓ１−８に進み、デバイス管理アプリケーション１０１は、デバイス３００から情報取得を行う。

ユーザ設定のルーティング情報を使用する場合、Ｓ５ｃ−２に進み、デバイス管理アプリケーション１０１はデータベース５０８からユーザ設定のルーティング情報を取得する。次のＳ５ｃ−３において、デバイス管理アプリケーション１０１は、ユーザ設定のルーティング情報を用いてブラウザ１０２とデバイス３００が通信可能かどうかを判定する。通信可能と判定した場合、Ｓ１−７に進み、デバイス管理アプリケーション１０１は、デバイス３００にリダイレクトする要求をブラウザ１０２に送信する。通信できないと判定した場合、Ｓ１−８に進み、デバイス管理アプリケーション１０１はデバイス３００から情報取得を行う。

〈第１の実施の形態に係る利点〉
本実施の形態は、次のような利点を有する。

クライアント装置２００のブラウザ１０２からデバイス３００に内蔵されているＷｅｂサーバにアクセスして、図８に示すようなＲＵＩ画面を表示しようとする場合、デバイス管理アプリケーション１０１を経由する。その際に、デバイス管理アプリケーション１０１は、ブラウザ１０２が動作しているクライアント装置２００のアドレスと、ＲＵＩが存在するデバイス３００のアドレスとを比較する（Ｓ１２）。その結果、ブラウザ１０２とデバイス３００が通信不可である場合（例えば、ブラウザ１０２とデバイス３００のＩＰバージョンが異なる）には、次のように処理する。即ち、デバイス管理アプリケーション１０１がデバイス３００から情報を取得する。そして、デバイス３００から取得した情報を基に図９に示すようなデバイス詳細画面を作成してブラウザ１０２に返信する。

これにより、ブラウザ１０２とデバイス３００のＩＰバージョンが異なる環境においても、クライアント装置２００には、通信エラー画面が表示されることなく、ＲＵＩ画面の代わりにデバイス詳細画面を表示することが可能になる。

尚、本実施例では、クラインアント装置とデバイスとが同じ通信プロトコルであるかどうかをＩＰアドレスに基づいて判断しているが、アドレスではなく、通信プロトコルを示すその他の情報を取得して、この情報によって判断してもよい。

［第２の実施の形態］
第２の実施の形態では、ブラウザとデバイスが共にＩＰｖ６で動作しているネットワーク環境において、デバイスに複数設定されているＩＰｖ６アドレスの中から通信可能なアドレスを選択することができるようにしたものである。

図１６は、第２の実施の形態に係るデバイス管理アプリケーション１０１の動作を示したフローチャートである。

図１６のＳ６−１からＳ６−５までの処理は、それぞれ図１０のＳ１−１からＳ１−５までの処理と同じであるので、その説明を省略する。

Ｓ６−６においては、デバイス管理アプリケーション１０１は、ブラウザ１０２、デバイス３００が共にＩＰｖ４で動作しているかチェックする。共にＩＰｖ４の場合、Ｓ６−８に進み、デバイス管理アプリケーション１０１は、前述した従来のシーケンスを実行し処理を終了する。

ブラウザ１０２とデバイス３００が共にＩＰｖ４でない場合、デバイス管理アプリケーション１０１は、Ｓ６−７において、ブラウザ１０２とデバイス３００のＩＰバージョンが異なるかチェックする。ブラウザ１０２とデバイス３００のＩＰバージョンが異なるとき、デバイス管理アプリケーション１０１は、Ｓ６−９に進む。

Ｓ６−９では、デバイス管理アプリケーション１０１は、ＮＭＰｖ１／ｖ３／Ｗｅｂサービスなどのプロトコルを用いて、デバイス３００から、ステータス、設置場所などの情報を取得する。このとき、デバイス管理アプリケーション１０１は、第１の実施の形態と同様にデバイス探索時にデバイス３００が返信したアドレスを使用する。

ブラウザ１０２とデバイス３００が共にＩＰｖ６のときは、デバイス管理アプリケーションは、Ｓ６−１０に進む。Ｓ６−１０では、デバイス管理アプリケーション１０１は、デバイス３００に複数設定されているアドレスの選択用画面である図１７のようなアドレス選択画面を表示するためのＨＴＭＬ情報を生成する。

その後、デバイス管理アプリケーション１０１は、生成したアドレス選択画面をブラウザ１０２に返信する。このＨＴＭＬ情報を受信したブラウザ１０２は、アドレス選択画面を表示することが可能になる。

図１７は、アドレス選択画面の一例を示す画面図である。

このアドレス選択画面には、図１７に示すように、選択されたデバイス３００のアドレス一覧を表示するための一覧表示エリア１７１と、デバイス管理アプリケーション１０１でデバイス３００から情報を取得するための「取得」ボタン１７２とが表示される。また、表示エリア１７１には、各アドレス毎に「表示」ボタン１７１ａが表示される。

一覧表示エリア１７１の「表示」ボタン１７１ａを押下すると、そのアドレスを使用してリダイレクトが行われ、ＲＵＩ画面を表示することが可能になる。また、「取得」ボタン１７２が押下されると、デバイス管理アプリケーション１０１によってデバイスに関する情報の取得が行われる。

〈第２の実施の形態に係る利点〉
ブラウザ１０２からデバイス３００のＷｅｂサーバにアクセスして、ＲＵＩ画面（図８参照）を表示しようとする場合に、ブラウザ１０２とデバイス３００が共にＩＰｖ６で動作しているときには、次のような処理を行う。即ち、デバイス管理アプリケーション１０１は、アドレス選択画面を生成してブラウザ１０２に返信する。

これにより、ブラウザ１０２とデバイス３００が共にＩＰｖ６で動作している環境においても、クライアント装置２００には、通信エラー画面が表示されることなく、アドレス選択画面（図１７参照）を表示することが可能になる。したがって、ＩＴ管理者１０３は、アドレス選択画面によって、デバイス３００に複数設定されているＩＰｖ６アドレスの中から通信可能なアドレスを選択してリダイレクトし、ＲＵＩ画面を表示することが可能になる。

［第３の実施の形態］
第３の実施の形態では、図１に示したネットワークシステムにおいてプロキシが存在する場合のシーケンスについて説明する。

図１８は、本発明の第３の実施の形態に係るネットワークシステムのシーケンスを示すシーケンス図であり、図７と共通の要素には同一の符号を付し、その説明を省略する。

ブラウザ１０２にはデバイス一覧が表示され、管理対象のデバイスがリスト表示されている。ここで、ＩＴ管理者は特定のデバイス３００の詳細情報を参照するために、デバイス３００に内蔵されているＷｅｂサーバにアクセスしＲＵＩを表示しようとする。

このとき、ブラウザ１０２はプロキシ経由でデバイス管理アプリケーション１０１にＲＵＩへのジャンプ要求を送信する（Ｓ３１）。プロキシは、ブラウザ１０２からのリクエストをデバイス管理アプリケーション１０１へリダイレクトする（Ｓ３２）。

その後は、図７の説明と同様に、Ｓ１１及びＳ１２を実行した後、Ｓ１３〜Ｓ１５又はＳ２１〜Ｓ２３を実行する。

本実施の形態のように、プロキシが存在する場合であっても、上記第１の実施の形態と同様の利点を得ることができる。

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

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

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

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

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

実施の形態に係るネットワークシステムの構成を示す模式図である。 画像処理装置から成るデバイス３００の構成を示すブロック図である。 デバイスのＩＰｖ６設定画面を示す表示画面図である。 図１中のネットワークデバイス管理装置及びクライアント装置の構成を示すブロック図である。 デバイス管理アプリケーションの構成を示したブロック図である。 デバイス管理アプリケーションにより表示されるデバイスリスト画面を示す表示画面図である。 第１の実施の形態に係るネットワークシステムのシーケンスを示すシーケンス図である。 ブラウザに表示されるＲＵＩ画面の一例を示す画面図である。 ブラウザに表示されるデバイス詳細画面の一例を示す画面図である。 第１の実施の形態に係るデバイス管理アプリケーションの動作を示したフローチャートである。 図１０のＳ１−６の詳細を示すフローチャートである。 図１１中の判定処理１（Ｓ２−８）の詳細を示すフローチャートである。 図１１中の判定処理２（Ｓ２−１２）の詳細を示すフローチャートである。 図１１中の判定処理２（Ｓ２−１２）の詳細を示すフローチャートである。 図１１中の判定処理２（Ｓ２−１２）の詳細を示すフローチャートである。 第２の実施の形態に係るデバイス管理アプリケーション１０１の動作を示したフローチャートである。 アドレス選択画面の一例を示す画面図である。 第３の実施の形態に係るネットワークシステムのシーケンスを示すシーケンス図である。 従来のネットワークシステムの構成を示す模式図である。

符号の説明

１００ ネットワークデバイス管理装置
１０１ デバイス管理アプリケーション
２００ クライアント装置
１０２ ブラウザ
３００ デバイス
４００ ネットワーク
５０１ ＨＴＭＬ画面生成部
５０２ アドレス判定部
５０３ クライアント通信部
５０４ デバイス探索部
５０５ デバイス情報取得部
５０６ デバイス通信部
５０７ デバイス情報保持部
５０８ データベース

Claims (11)

1. ネットワーク上のデバイス及びクライアント装置と通信可能に接続されるネットワークデバイス管理装置において、
   前記クライアント装置から、前記デバイスへのアクセス要求を受け付ける受け付け手段と、
   前記受け付け手段によって受け付けた前記アクセス要求を送信した前記クライアント装置のアドレスを取得する第一の取得手段と、
   前記受け付け手段によって受け付けた前記アクセス要求の対象となる前記デバイスのアドレスを取得する第二の取得手段と、
   前記第一の取得手段により取得された前記クライアント装置のアドレスと前記第二の取得手段により取得された前記デバイスのアドレスのＩＰバージョンが一致するか否かを判定する判定手段と、
   前記判定手段により前記クライアント装置のアドレスと前記デバイスのアドレスのＩＰバージョンが一致しないと判定されたときは前記ネットワークデバイス管理装置が前記デバイスから取得したデバイス情報を前記クライアント装置に送信し、前記クライアント装置のアドレスと前記デバイスのアドレスのＩＰバージョンが一致すると判定されたときは前記クライアント装置に前記デバイスのアドレスを送信する送信手段とを備えたことを特徴とするネットワークデバイス管理装置。
2. 前記判定手段により前記クライアント装置のアドレスと前記デバイスのアドレスのＩＰバージョンが一致すると判定された場合に、前記クライアント装置と前記デバイスと前記ネットワークデバイス管理装置のプレフィックスを比較し、その比較の結果に基づいて、前記クライアント装置と前記デバイスとの通信の可否を判定することを特徴とする請求項１に記載のネットワークデバイス管理装置。
3. 前記クライアント装置と前記デバイスと前記ネットワークデバイス管理装置のプレフィックスが同一の場合は、前記送信手段は、前記クライアント装置に前記デバイスのアドレスを送信することを特徴とする請求項２に記載のネットワークデバイス管理装置。
4. 前記クライアント装置と前記デバイスのプレフィックスが同一の場合は、前記送信手段は、前記クライアント装置に前記デバイスのアドレスを送信することを特徴とする請求項２に記載のネットワークデバイス管理装置。
5. 前記ネットワークデバイス管理装置と前記デバイスのプレフィックスが同一の場合は、前記送信手段は、前記クライアント装置に前記デバイスのアドレスを送信することを特徴とする請求項２に記載のネットワークデバイス管理装置。
6. 前記クライアント装置と前記ネットワークデバイス管理装置のプレフィックスが同一の場合は、前記デバイスから取得したデバイス情報から前記特定のプロトコルで定義されたソースアドレスを抽出し、そのソースアドレスを前記デバイスのアドレスとして前記送信手段により送信することを特徴とする請求項２に記載のネットワークデバイス管理装置。
7. 前記クライアント装置と前記ネットワークデバイス管理装置のプレフィックスが同一の場合は、特定のパケットを用いて、前記デバイスから取得したデバイス情報から前記デバイスと通信可能な前記特定のプロトコルで定義されるアドレスを抽出し、そのアドレスを前記デバイスのアドレスとして前記送信手段により送信することを特徴とする請求項２に記載のネットワークデバイス管理装置。
8. 前記送信手段によって送信されるデバイス情報は、前記デバイスから取得した情報に基づいて生成されたＨＴＭＬデータであり、前記送信手段によって送信されるアドレスは、前記デバイスが備えるＷｅｂサーバにアクセスするためのＵＲＬであることを特徴とする請求項１乃至７のいずれか一項に記載のネットワークデバイス管理装置。
9. ネットワーク上のデバイス及びクライアント装置と通信可能に接続されるネットワークデバイス管理装置の制御方法であって、
   前記クライアント装置から、前記デバイスへのアクセス要求を受け付ける受け付け工程と、
   前記受け付け工程によって受け付けた前記アクセス要求を送信した前記クライアント装置のアドレスを取得する第一の取得工程と、
   前記受け付け手段によって受け付けた前記アクセス要求の対象となる前記デバイスのアドレスを取得する第二の取得工程と、
   前記第一の取得工程にて取得された前記クライアント装置のアドレスと前記第二の取得工程にて取得された前記デバイスのアドレスのＩＰバージョンが一致するか否かを判定する判定工程と、
   前記判定工程にて前記クライアント装置のアドレスと前記デバイスのアドレスのＩＰバージョンが一致しないと判定されたときは前記ネットワークデバイス管理装置が前記デバイスから取得したデバイス情報を前記クライアント装置に送信し、前記クライアント装置のアドレスと前記デバイスのアドレスのＩＰバージョンが一致すると判定されたときは前記クライアント装置に前記デバイスのアドレスを送信する送信工程とを有することを特徴とするネットワークデバイス管理装置の制御方法。
10. ネットワーク上のデバイス及びクライアント装置と、前記デバイス及び前記クライアント装置と通信可能に接続されるネットワークデバイス管理装置とを備えたネットワークシステムであって、
    前記ネットワークデバイス管理装置は、
    前記クライアント装置から、前記デバイスへのアクセス要求を受け付ける受け付け手段と、
    前記受け付け手段によって受け付けた前記アクセス要求を送信した前記クライアント装置のアドレスを取得する第一の取得手段と、
    前記受け付け手段によって受け付けた前記アクセス要求の対象となる前記デバイスのアドレスを取得する第二の取得手段と、
    前記第一の取得手段により取得された前記クライアント装置のアドレスと前記第二の取得手段により取得された前記デバイスのアドレスのＩＰバージョンが一致するか否かを判定する判定手段と、
    前記判定手段により前記クライアント装置のアドレスと前記デバイスのアドレスのＩＰバージョンが一致しないと判定されたときは前記ネットワークデバイス管理装置が前記デバイスから取得したデバイス情報を前記クライアント装置に送信し、前記クライアント装置のアドレスと前記デバイスのアドレスのＩＰバージョンが一致すると判定されたときは前記クライアント装置に前記デバイスのアドレスを送信する送信手段とを備えたことを特徴とするネットワークシステム。
11. ネットワーク上のデバイス及びクライアント装置と通信可能に接続されるネットワークデバイス管理装置の制御方法を実行するための、コンピュータで読み取り可能なプログラムであって、
    前記クライアント装置から、前記デバイスへのアクセス要求を受け付ける受け付けステップと、
    前記受け付けステップによって受け付けた前記アクセス要求を送信した前記クライアント装置のアドレスを取得する第一の取得ステップと、
    前記受け付けステップによって受け付けた前記アクセス要求の対象となる前記デバイスのアドレスを取得する第二の取得ステップと、
    前記第一の取得ステップにより取得された前記クライアント装置のアドレスと前記第二の取得ステップにより取得された前記デバイスのアドレスのＩＰバージョンが一致するか否かを判定する判定ステップと、
    前記判定ステップにより前記クライアント装置のアドレスと前記デバイスのアドレスのＩＰバージョンが一致しないと判定されたときは前記ネットワークデバイス管理装置が前記デバイスから取得したデバイス情報を前記クライアント装置に送信し、前記クライアント装置のアドレスと前記デバイスのアドレスのＩＰバージョンが一致すると判定されたときは前記クライアント装置に前記デバイスのアドレスを送信する送信ステップとを備えたことを特徴とするプログラム。

Images