JP6881949B2

JP6881949B2 - 管理システム、および制御方法

Info

Publication number: JP6881949B2
Application number: JP2016218210A
Authority: JP
Inventors: 浩太郎松田
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2016-11-08
Filing date: 2016-11-08
Publication date: 2021-06-02
Anticipated expiration: 2036-11-08
Also published as: CN108075924B; US11201792B2; US20180131573A1; JP2018077623A; KR20180051409A; CN108075924A; KR102214665B1

Description

本発明は、デバイスの情報を管理する管理システム、および制御方法に関する。

企業・団体などの組織内に設置されているプリンター等の管理・メンテナンス・サポート業務を、販売会社またはディーラーが、顧客に代わって代行するサービスが提供されている。これらのサービスは、ＭＰＳ（ＭａｎａｇｅｄＰｒｉｎｔＳｅｒｖｉｃｅｓ）またはＭＤＳ（ＭａｎａｇｅｄＤｏｃｕｍｅｎｔＳｅｒｖｉｃｅｓ）といった名称で呼ばれている。ＭＰＳまたはＭＤＳを顧客に提供するために、企業・団体などの顧客ネットワーク内のデバイスの一覧を管理し、各デバイスの使用履歴・運用状況・エラー状態などを把握するデバイス管理アプリケーションが活用されている。従来では、顧客ネットワーク内にデバイス管理サーバーを設置して、顧客ネットワーク内のデバイスの一覧を管理する、といった構成・形態が多かった。

特許文献１では、ネットワーク管理ソフトウェアが動作するＷＷＷサーバーは、Ｗｅｂブラウザーから管理対象デバイスの情報取得の要求を受信し、その後、管理対象デバイスから、そのデバイスが提供するＷｅｂページのＵＲＬを取得する。取得したＵＲＬが有効であると判断された場合、ＷＷＷサーバーは、取得したＵＲＬをＨＴＭＬ形式に整形した一時情報をＷｅｂブラウザーに送信する。

さらに、近年のインターネットサービスあるいはクラウドサービスの進展により、デバイス管理アプリケーションもインターネット上のＷｅｂサーバーにて提供されるようになってきている。また、デバイスの情報の１つにＩＰアドレスがある。最近のプリンターなどのデバイスでは、機器内にＷｅｂサーバーを搭載しているものも多く、ブラウザーからデバイスのＩＰアドレスにアクセスすることで、デバイスの情報を参照したり、デバイスの設定を変更したりすることができる。

特開２００３−３３０８２４号公報

上述したデバイス情報を管理する管理サーバーが提供するＷｅｂページでデバイス管理情報を表示するときに、ＩＰアドレスのみでなく、そのＩＰアドレスへのＵＲＬ（ＵｎｉｆｏｒｍＲｅｓｏｕｒｃｅＬｏｃａｔｏｒ）リンクを一緒に表示することがある。

このとき、管理サーバーへアクセスしてＷｅｂページを表示するブラウザーが実行されているクライアントコンピューターが顧客ネットワーク内に存在し、かつ該当ＩＰアドレスのデバイスと通信可能な場合、ＵＲＬリンクは正しく動作する。すなわち、ＵＲＬリンクを押下して、ブラウザーが機器内ＷｅｂサーバーへのＵＲＬへとリダイレクトすると、該当ＩＰアドレスのデバイスの機器内Ｗｅｂサーバーへとアクセスできる。上述した特許文献１では、Ｗｅｂブラウザーを有するＰＣ（ＰｅｒｓｏｎａｌＣｏｍｐｕｔｅｒ）とネットワーク管理ソフトウェアが動作するＷＷＷサーバーとは、ＬＡＮで接続されている。

しかしながら、クライアントコンピューターのインターネット接続が有効で、デバイス管理Ｗｅｂサーバーにアクセス可能であるが、顧客ネットワークには接続しておらず、デバイスのＩＰアドレスには通信不可の場合、ＵＲＬリンクは正しく動作しない。すなわち、ＵＲＬリンクによりＷｅｂサーバーのＵＲＬへとリダイレクトすると、対象のＩＰアドレスへの通信がタイムアウトしたり、または、別ネットワーク内に存在し且つＩＰアドレスが同じである別のＷｅｂサーバーに接続したりしてしまう可能性がある。特に顧客内のネットワークはプライベートネットワークである。そのため、ＲＦＣ１９１８で規定されているプライベートＩＰアドレス（例：クラスＣの場合、１９２．１６８．０．０〜１９２．１６８．２５５．２５５）をそれぞれの顧客内で様々なネットワーク体系で使用している。そのため、正しくないＷｅｂサーバーへとブラウザーをリダイレクトさせることが発生する可能性があるということは、セキュリティの面で懸念である。

そこで本発明は、情報処理端末からデバイスのウェブサーバーへのアクセスの制限を可能とするための仕組みを提供することを目的とする。

上記課題を解決するために、本発明は、デバイス情報を管理する管理システムであって、情報処理端末からデバイス情報の取得要求を受信した際に、デバイス情報を表示するための情報と、該デバイス情報に対応するデバイスが搭載するウェブサーバーへのアクセスが許可されるか否かの確認のための通信を前記情報処理端末に実行させるための命令を含むスクリプト情報と、を前記情報処理端末に対して応答する応答手段を有し、前記情報処理端末では、前記スクリプト情報に含まれる命令の実行によって、前記デバイスが搭載する前記ウェブサーバーへのアクセスが許可されないと判断した場合に、当該ウェブサーバーへのアクセスが制限されることを特徴とする。

本発明によれば、情報処理端末からデバイスのウェブサーバーへのアクセスの制限を可能となる。

システム構成およびネットワーク構成の一例を示す図情報処理機能のモジュール構成の一例を示す図本システムのソフトウェアおよびハードウェア構成の一例を示す図デバイス管理サーバーが提供するＷｅｂページの一例を示す図デバイス管理サーバーが提供するＷｅｂページの一例を示す図デバイスのウェブサーバーへのアクセスが許可されるか否かを確認するための処理の流れを示すフローチャートデバイスのウェブサーバーへのアクセスが許可されるか否かを確認するための処理の流れを示すフローチャートデバイスのウェブサーバーへのアクセスが許可されるか否かを確認するための処理の流れを示すフローチャート第２の実施例におけるデバイス管理サーバーが提供するＷｅｂページの一例を示す図第２の実施例におけるデバイスのウェブサーバーへのアクセスが許可されるか否かを確認するための処理の流れを示すフローチャート

以下、本発明を実施するための最良の形態について図面を用いて説明する。

（第１の実施例）
図１は、本発明を実施するためのシステム構成およびネットワーク構成の一例を示している。本実施例のシステムでは、インターネット上のデバイス管理Ｗｅｂサーバーにて顧客ネットワーク内のデバイスの一覧が管理される。顧客ネットワーク内のコンピューターの１台あるいは複数台に、デバイス管理エージェントというアプリケーションをインストール・稼働させる。デバイス管理エージェントは、デバイスを探索・発見したら監視を開始し、使用履歴・運用状況・エラー状態などのデバイスデータを収集して、デバイス管理Ｗｅｂサーバーに送信する。販売会社のユーザーあるいは顧客ユーザーは、クライアントコンピューターのブラウザーを使って、デバイス管理Ｗｅｂサーバーに接続・ログインして、該当顧客のデバイス一覧や各種デバイスの使用状況・ステータスを参照する。

１０１は、インターネットなどのネットワーク網である。１０５は、プライベートネットワークあるいはローカルエリアネットワーク（ＬＡＮ）などのネットワークである。１１１は、本実施例での管理システムとして機能するデバイス管理サーバーである。なお、１１１は、クラウド上に構築されるシステムであってもよい。１２１および１２２はコンピューターである。コンピューター１２１、１２２としては、パーソナルコンピューター、ラップトップコンピューター、タブレットコンピューター、スマートフォンなどの情報処理端末である。１３１および１３２は、オフィス複合機、プリンター、ネットワークカメラ、デジタル医療機器、造形装置などのネットワークデバイスである。なお、本実施例で、デバイス１３１および１３２は、オフィス複合機やプリンターなどの印刷機器を例に説明する。第１の実施例の構成では、コンピューター１２２がデバイス管理エージェントとしての機能を備える中継装置であり、デバイス１３１、１３２を監視して、収集したデバイスの情報をデバイス管理Ｗｅｂサーバーに送信する。

図２は、デバイス管理サーバー１１１、コンピューター１２１、１２２、デバイス１３１、１３２の情報処理機能のモジュール構成図を示している。ユーザーインターフェース２０１は、ディスプレイ、キーボード、マウス、タッチパネル、ボタンなどによる、情報や信号の入出力を行う。これらのハードウェアを備えないコンピューターは、リモートデスクトップやリモートシェルなどにより、他のコンピューターから接続・操作することも可能である。ネットワークインターフェース２０２は、ＬＡＮなどのネットワークに接続して、他のコンピューターやネットワーク機器との通信を行う。通信の方式としては、有線・無線のいずれでもよい。

ＲＯＭ２０４には、組込済みプログラムおよびデータが記録されている。ＲＡＭ２０５は、一時メモリ領域である。二次記憶装置２０６は、ＨＤＤやフラッシュメモリなどである。ＣＰＵ２０３は、ＲＯＭ２０４、ＲＡＭ２０５、二次記憶装置２０６などから読み込んだプログラムを実行する。２０１乃至２０６の各部は内部バス２０７を介して接続されている。

図３は、本システムのソフトウェア構成およびハードウェア構成の一例を示す図である。各ハードウェアにインストールされたソフトウェアは、それぞれＣＰＵ２０３で実行され、ネットワーク接続の矢印で図示するように、相互に通信可能な構成となっている。

３１１は、デバイス管理サーバー１１１にインストールされたＷｅｂサーバーである。３１２は、Ｗｅｂサーバー３１１によって提供されるＲＥＳＴ（ＲｅｐｒｅｓｅｎｔａｔｉｏｎａｌＳｔａｔｅＴｒａｎｓｆｅｒ）ＡＰＩ（ＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍｍｉｎｇＩｎｔｅｒｆａｃｅ）である。３１３は、Ｗｅｂサーバー３１１によって提供されるＷｅｂＵＩである。３１４は、収集したデータを保存・格納するデータストアである。

３２１は、コンピューター１２１にインストールされたブラウザーである。Ｗｅｂサーバーにアクセスして、ＨＴＭＬ（ＨｙｐｅｒＴｅｘｔＭａｒｋｕｐＬａｎｇｕａｇｅ）文書などを表示する。

３３１は、コンピューター１２２またはデバイス１３１にインストールされたデバイス管理エージェントである。デバイス管理エージェント３３１は、デバイス管理アプリケーション３３２とＷｅｂサーバー３３３とを有する。デバイス管理アプリケーション３３２は、デバイス１３１、１３２からデータを収集し、デバイス管理サーバー１１１に送信する。ブラウザー３２１から、Ｗｅｂサーバー３３３にアクセスして、デバイス管理エージェント３３１の情報を参照したり、設定を変更したりすることが可能である。３３４は、デバイス管理エージェント３３１が収集したデータを保存・格納するデータストアである。

３４１は、デバイス１３１、１３２に搭載されているログ記録部である。３４２は、同じくデバイス１３１、１３２に搭載されているログストレージである。ログ記録部は、デバイス１３１または１３２の動作履歴・エラー履歴・消耗品の状態など、デバイスの動作ログやステータスをログストレージ３４２に記録する。３４３は、ログストレージ３４２に記録しているデータを取得するためのＡＰＩである。３４４は、デバイス１３１、１３２に搭載されているＷｅｂサーバーである。ブラウザー３２１からＷｅｂサーバー３４４にアクセスして、デバイス１３１、１３２の情報を参照したり、設定の変更をしたりすることが可能である。

本システムにおいて、デバイス管理エージェント３３１がデバイス１３１、１３２からデバイスデータを取得し、デバイス管理サーバー１１１に送信する処理の流れを説明する。デバイス管理アプリケーション３３２は、ＳＮＭＰ（ＳｉｍｐｌｅＮｅｔｗｏｒｋＭａｎａｇｅｍｅｎｔＰｒｏｔｏｃｏｌ）などの通信プロトコルを用いて、デバイス１３１、１３２等が通信可能なネットワーク内に存在するか探索する。デバイス管理アプリケーション３３２は、デバイス１３１、１３２を検出したら、ＳＮＭＰ等により監視を開始し、必要に応じてＡＰＩ３４３と通信して、デバイスデータを取得する。取得したデバイスデータは、データストア３３４に格納される。エラー情報など、比較的緊急性が高いデータは、即時にデバイス管理サーバー１１１に送信される。動作履歴などのデータは、定期的にデバイス管理サーバー１１１に送信される。その際、デバイス管理アプリケーション３３２は、ＲＥＳＴＡＰＩ３１２にデバイスデータの登録リクエストを送信する。ＲＥＳＴＡＰＩ３１２は、受信したデバイスデータをデータストア３１４に保存する。デバイス管理サーバーのユーザーは、ブラウザー３２１を用いてＷｅｂサーバー３１１にアクセスし、デバイスの管理画面などを表示して、閲覧、データの編集・変更などを実行する。この際、ブラウザー３２１は、ＷｅｂＵＩ３１３からＨＴＭＬ、ＪａｖａＳｃｒｉｐｔ（登録商標）などのＷｅｂページを構成するファイルを取得する。ブラウザー３２１は、取得したＪａｖａＳｃｒｉｐｔ内の命令を実行し、ＲＥＳＴＡＰＩ３１２にデータ取得リクエストを送信し、ページ表示に必要なデータを取得する。ＲＥＳＴＡＰＩ３１２は、前記データ取得リクエストを受信すると、データストア３１４を検索して、必要なデータを取得して、ブラウザー３２１に応答する。ブラウザー３２１は、ＪａｖａＳｃｒｉｐｔ内の命令によって、前記取得したデータを埋め込んだＨＴＭＬを生成し、Ｗｅｂページを表示する。

図４、５は、デバイス管理サーバー１１１が提供するＷｅｂページの例である。図４（ａ）において４００は、デバイス一覧画面である。なお、４００は、１台のデバイスの情報を表示する画面であってもよい。

４０１は、表示対象の顧客テナント名・顧客テナントＩＤを表示するフィールドである。テナントとは、インターネット上のＷｅｂサービスをパブリックに公開・提供する際に、ユーザーの企業や団体ごとに分離される専用の記憶領域である。クラウドサービス等において、Ｗｅｂサービスやそのバックエンドにあるデータストアは、全ての顧客のデータを共有されたコンピューティングリソース上に配置・保管される。顧客がデバイス管理サーバー１１１で管理される情報にアクセスする場合には、自分の所属するテナントのデータにしかアクセスできず、他のテナントへのアクセスを制限される。

顧客テナント名・顧客テナントＩＤ４０１は、デバイス管理サーバーが様々な顧客が登録され、管理されている場合、テナント分離されたうちの１つの顧客のデータを参照していることを示す。４０２は、前述の顧客テナント内で管理されているデバイス一覧を表示しており、デバイスの情報あるいはステータスなどのデータが参照可能である。

図４（ｂ）において４１０は、顧客テナント内で管理されているデバイス管理エージェント一覧を表示しており、エージェントの情報あるいはステータスなどのデータが参照可能である。

図５（ａ）において５００は、４００同様のデバイス一覧画面である。５０２も、４０２同様顧客テナント内で管理されているデバイス一覧を表示しており、デバイスの情報あるいはステータスなどのデータが参照可能である。５０３は、デバイスのＩＰアドレスを表示するカラムである。画面４００との違いは、一部のデバイスのＩＰアドレスに、ＵＲＬリンクが生成されている点である。５０３において、ＩＰアドレスに下線が引かれている場合は、該当ＩＰアドレスに対して、ＵＲＬリンクが設定されていることを示す。このＵＲＬの宛先は、デバイス１３１、１３２のＷｅｂサーバー３４４のアドレスである。例えば、ＩＰアドレスが１９２．１６８．０．２０１のデバイスのＷｅｂサーバーの場合、宛先ＵＲＬは、ｈｔｔｐ：／／１９２．１６８．０．２０１などとなる。

図５（ｂ）において５１０は、リンク先が設定されている５０３のＵＲＬを選択した場合に表示されるデバイスの詳細画面の一例である。５１１は、デバイス情報各種を表示するフィールドである。５１２は、エラーや消耗品の情報などの詳細ステータスや履歴を表示するフィールドである。５１３は、該当デバイスがデバイス管理エージェントからの通信要求に応答しないため、通信不可エラーが発生していることを示すメッセージ表示フィールドである。５１４は、５０３同様にＩＰアドレスを表示するフィールドである。

図６のフローチャートを用いて、第１の実施例の処理フローを説明する。図６のフローチャートに示す処理は、各装置のＣＰＵ２０３が、ＲＯＭ２０４や二次記憶装置２０６などに記録されたプログラムを読み出して実行することにより実現される。なお、以降のフローチャートについても同様である。

Ｓ６０１で、ブラウザー３２１は、ユーザーからの指示に基づき、デバイス一覧またはデバイス情報のＷｅｂページ（画面情報）の取得要求のためのリクエストをデバイス管理サーバー１１１のＷｅｂサーバー３１１に送信する。

例えば、Ｗｅｂサーバー３１１のＦＱＤＮ（ＦｕｌｌｙＱｕａｌｉｆｉｅｄＤｏｍａｉｎＮａｍｅ）が、「ｗｗｗ．ｄｅｖｉｃｅ−ｍａｎａｇｅｍｅｎｔ−ｃｌｏｕｄ．ｃｏｍｐａｎｙ」の場合、ＵＲＬ、ＨＴＴＰリクエストの例は以下のようになる。
ＵＲＬ：
ｈｔｔｐｓ：／／ｗｗｗ．ｄｅｖｉｃｅ−ｍａｎａｇｅｍｅｎｔ−ｃｌｏｕｄ．ｃｏｍｐａｎｙ／ｓｉｔｅ／ｄｅｖｉｃｅｓ／
ＨＴＴＰリクエスト（抜粋）：
ＧＥＴ／ｓｉｔｅ／ｄｅｖｉｃｅｓ／ＨＴＴＰ／１．１
Ｈｏｓｔ：ｗｗｗ．ｄｅｖｉｃｅ−ｍａｎａｇｅｍｅｎｔ−ｃｌｏｕｄ．ｃｏｍｐａｎｙ
Ｓ６０２で、Ｗｅｂサーバー３１１は、ブラウザー３２１からリクエストを受信して、ユーザーからの正しいリクエストであるかどうかを判定する。ユーザーからの正しいリクエストかどうかを判定する方法としては、ＨＴＴＰのリクエストヘッダーの、Ａｕｔｈｏｒｉｚａｔｉｏｎフィールドを使用する例などがある。Ａｕｔｈｏｒｉｚａｔｉｏｎフィールドに、認証済みユーザーであることを示す認証トークンをセットし、Ｗｅｂサーバー側で検証する実装例などが挙げられる。Ｓ６０２で受信したリクエストが正しいと判定されると、Ｓ６０３に処理が進められる。

Ｓ６０３で、Ｗｅｂサーバー３１１は、ＨＴＭＬ、ＪａｖａＳｃｒｉｐｔなどのＷｅｂページを構成するファイルをブラウザー３２１へ応答する。Ｓ６０４で、ブラウザー３２１は、ＨＴＭＬ、ＪａｖａＳｃｒｉｐｔなどのファイルをＷｅｂサーバー３１１から受信する。Ｓ６０５で、ブラウザー３２１は、ＪａｖａＳｃｒｉｐｔの命令を実行し、ページを構成する必要なデータを取得するために、ＲＥＳＴＡＰＩ３１２を呼び出す。Ｓ６０６で、Ｗｅｂサーバー３１１は、ＲＥＳＴＡＰＩ３１２へのリクエストを受信して、Ｓ６０２同様に、ユーザーからの正しいリクエストであるかどうかを判定する。Ｓ６０６で受信したリクエストが正しいと判定されると、Ｓ６０７に処理が進められる。

Ｓ６０７で、Ｗｅｂサーバー３１１は、リクエストされたＲＥＳＴＡＰＩの処理を実行する。Ｗｅｂサーバー３１１は、リクエスト内のＵＲＩやリクエストヘッダー・ボディーで指定されたデバイス情報あるいはエージェント情報をデータストア３１４から読みだす。Ｓ６０８で、Ｗｅｂサーバー３１１は、ＪＳＯＮ（ＪａｖａＳｃｒｉｐｔＯｂｊｅｃｔＮｏｔａｔｉｏｎ）などのデータ記述言語に変換したデータをブラウザー３２１へ応答する。

デバイス情報のデータ例をＪＳＯＮ形式で以下に示す。
｛
“ｄｅｖｉｃｅ”：［
｛
“ｓｅｒｉａｌ−ｎｕｍｂｅｒ”： “ＭＤＸ７８４６１”，
“ｍａｎｕｆａｃｔｕｒｅｒ−ｎａｍｅ”： “α”，
“ｐｒｏｄｕｃｔ−ｎａｍｅ”： “ＯｆｆｉｃｅＰｒｉｎｔｅｒ５”，
“ｉｐ−ａｄｄｒｅｓｓ”： “１９２．１６８．０．２０１”，
“ｄｅｖｉｃｅ−ｓｔａｔｕｓ”： “ｏｐｅｒａｔｉｎｇ”，
“ｅｒｒｏｒ−ｌｅｖｅｌ ”： “ｎｏｎｅ”，
“ｄｅｖｉｃｅ−ｔｙｐｅ”： “ＭＦＰ”，
“ｍｏｎｉｔｏｒｉｎｇ−ａｇｅｎｔ−ｉｄ”： “６ｃ３ｅｃ８５ｅ−５０７８−１１ｅ６−ｂｅｂ８−９ｅ７１１２８ｃａｅ７７”
｝，
｛
“ｓｅｒｉａｌ−ｎｕｍｂｅｒ”： “ＰＭＤ２２６７０”，
“ｍａｎｕｆａｃｔｕｒｅｒ−ｎａｍｅ”： “α”，
“ｐｒｏｄｕｃｔ−ｎａｍｅ”： “ＬＢＰ８Ｒ”，
“ｉｐ−ａｄｄｒｅｓｓ”： “１９２．１６８．０．２０２”，
“ｄｅｖｉｃｅ−ｓｔａｔｕｓ”： “ｏｐｅｒａｔｉｎｇ”，
“ｅｒｒｏｒ−ｌｅｖｅｌ ”： “ｗａｒｎｉｎｇ”，
“ｄｅｖｉｃｅ−ｔｙｐｅ”： “ＭＦＰ”，
“ｍｏｎｉｔｏｒｉｎｇ−ａｇｅｎｔ−ｉｄ”： “６ｃ３ｅｃ８５ｅ−５０７８−１１ｅ６−ｂｅｂ８−９ｅ７１１２８ｃａｅ７７”
｝，
｛
“ｓｅｒｉａｌ−ｎｕｍｂｅｒ”： “ＯＬＹ３７５５２”，
“ｍａｎｕｆａｃｔｕｒｅｒ−ｎａｍｅ”： “α”，
“ｐｒｏｄｕｃｔ−ｎａｍｅ”： “ＰｈｏｔｏＤｅｖｉｃｅＰ１”，
“ｉｐ−ａｄｄｒｅｓｓ”： “１９２．１６８．０．２０３”，
“ｄｅｖｉｃｅ−ｓｔａｔｕｓ”： “ｃｏｍｍｕｎｉｃａｔｉｏｎ−ｅｒｒｏｒ”，
“ｅｒｒｏｒ−ｌｅｖｅｌ”： “ｅｒｒｏｒ”，
“ｄｅｖｉｃｅ−ｔｙｐｅ”： “ＬＦＰ”，
“ｍｏｎｉｔｏｒｉｎｇ−ａｇｅｎｔ−ｉｄ”： “６ｃ３ｅｃ８５ｅ−５０７８−１１ｅ６−ｂｅｂ８−９ｅ７１１２８ｃａｅ７７”
｝
］
｝
エージェント情報のデータ例をＪＳＯＮ形式で以下に示す。
｛
“ａｇｅｎｔ”：［
｛
“ａｇｅｎｔ−ｔｙｐｅ”： “ＰＣＡｇｅｎｔ”，
“ｖｅｒｓｉｏｎ”： “５．０．２”，
“ａｇｅｎｔ−ｉｄ”： “６ｃ３ｅｃ８５ｅ−５０７８−１１ｅ６−ｂｅｂ８−９ｅ７１１２８ｃａｅ７７”，
“ａｇｅｎｔ−ｎａｍｅ”： “ＰＣＡｇｅｎｔ００１”，
“ｉｐ−ａｄｄｒｅｓｓ”： “１９２．１６８．０．１１”，
“ａｇｅｎｔ−ｓｔａｔｕｓ”： “ｏｐｅｒａｔｉｎｇ”，
“ｌａｓｔ−ｃｏｍｍｕｎｉｃａｔｉｏｎ−ｄａｔｅｔｉｍｅ”： “２０１６−０７−２３Ｔ１１：２３：５５”，
“ｎｕｍｂｅｒ−ｏｆ−ｍｏｎｉｔｏｒｉｎｇ−ｄｅｖｉｃｅｓ”：５２
｝，
｛
“ａｇｅｎｔ−ｔｙｐｅ”： “ＰＣＡｇｅｎｔ”，
“ｖｅｒｓｉｏｎ”： “５．０．５”，
“ａｇｅｎｔ−ｉｄ”： “０００５３０ｂ１−８ａｄ１−４５ｃ５−ａ２２ｃ−３２ｄ１１ｂ３ｆ２５３４”，
“ａｇｅｎｔ−ｎａｍｅ”： “ＰＣＡｇｅｎｔ００２”，
“ｉｐ−ａｄｄｒｅｓｓ”： “１９２．１６８．１．７１”，
“ａｇｅｎｔ−ｓｔａｔｕｓ”： “ｏｐｅｒａｔｉｎｇ”，
“ｌａｓｔ−ｃｏｍｍｕｎｉｃａｔｉｏｎ−ｄａｔｅｔｉｍｅ”： “２０１６−０７−２３Ｔ１２：４５：０３”，
“ｎｕｍｂｅｒ−ｏｆ−ｍｏｎｉｔｏｒｉｎｇ−ｄｅｖｉｃｅｓ”：２８
｝，
｛
“ａｇｅｎｔ−ｔｙｐｅ”： “ＤｅｖｉｃｅＡｇｅｎｔ”，
“ｖｅｒｓｉｏｎ”： “５．０”，
“ａｇｅｎｔ−ｉｄ”： “ＰＲＤ２０１６８”，
“ａｇｅｎｔ−ｎａｍｅ”： “ＤｅｖＡｇｅｎｔ１０１”，
“ｉｐ−ａｄｄｒｅｓｓ”： “１９２．１６８．５．３１”，
“ａｇｅｎｔ−ｓｔａｔｕｓ”： “ｏｐｅｒａｔｉｎｇ”，
“ｌａｓｔ−ｃｏｍｍｕｎｉｃａｔｉｏｎ−ｄａｔｅｔｉｍｅ”： “２０１６−０７−２２Ｔ２２：０５：０１”，
“ｎｕｍｂｅｒ−ｏｆ−ｍｏｎｉｔｏｒｉｎｇ−ｄｅｖｉｃｅｓ”：５
｝
］
｝
Ｓ６０９で、ブラウザー３２１は、ＪＳＯＮデータを受信する。Ｓ６１０で、ブラウザー３２１は、ＪａｖａＳｃｒｉｐｔ内の命令を実行し、受信したＪＳＯＮデータをＨＴＭＬ内に展開・表示する。結果として、ブラウザー３２１に、画面４００あるいは４１０のような、デバイス情報あるいはエージェント情報を表示するＷｅｂページが表示される。

Ｓ６１１乃至Ｓ６１９は、画面５００のデバイス１３１あるいは１３２のＩＰアドレス表示フィールド５０３に、該当デバイスのＩＰアドレスへのＵＲＬリンクを動的に生成するための処理である。Ｓ６１１で、ブラウザー３２１は、ＪａｖａＳｃｒｉｐｔ内の命令を実行して、Ｗｅｂページ上の表示対象デバイスを監視しているデバイス管理エージェントを特定する。前述のＪＳＯＮデータ例において、シリアルナンバーが「ＭＤＸ７８４６１」のデバイスは、エージェントＩＤが「６ｃ３ｅｃ８５ｅ−５０７８−１１ｅ６−ｂｅｂ８−９ｅ７１１２８ｃａｅ７７」のデバイス管理エージェントによって監視されている。そのデバイスのＩＰアドレスは、１９２．１６８．０．２０１である。そのデバイス管理エージェントは、エージェント名「ＰＣＡｇｅｎｔ００１」であり、ＩＰアドレスは１９２．１６８．０．１１である。

ここで、ブラウザー３２１からデバイス１３１、１３２のＩＰアドレスに通信疎通確認を行って、疎通確認に成功したデバイスのＩＰアドレスのみにＵＲＬリンクを生成するのが望ましい。しかし、前述したように、デバイス管理サーバーのＷｅｂサーバー３１１のＦＱＤＮは、ｗｗｗ．ｄｅｖｉｃｅ−ｍａｎａｇｅｍｅｎｔ−ｃｌｏｕｄ．ｃｏｍｐａｎｙである。一方、デバイス１３１、１３２は、プライベートネットワークである顧客ネットワーク内に存在するので、ＩＰアドレスやホスト名などがＷｅｂサーバー３４４のアドレスとなる。ＨＴＴＰ通信の観点から見ると、この通信手順はクロスドメイン通信となる。ブラウザー３２１が、デバイス管理サーバーのＷｅｂサーバー３１１のＷｅｂページを表示し、そのＷｅｂページ内のＪａｖａＳｃｒｉｐｔ命令から、異なるドメインであるデバイスのＩＰアドレスに通信を行うためである。

ここで、デバイス１３１、１３２自体に、デバイス管理サーバーのＷｅｂサーバー３１１とのクロスドメイン通信機能を搭載する場合には、次のような困難が伴う。メーカーや機種によっては、そのような新機能を後から搭載するのが困難である。また、業界標準が規定されたとしても、全てのメーカーが対応を完了するのに長い年月を要する、または対応しないメーカーや機種が残ってしまうなどの問題点がある。

そこで、デバイス１３１、１３２を常時監視していて、デバイス管理サーバー１１１にデータを送信しているデバイス管理エージェント３３１を利用して、コンピューター１２１とデバイス１３１、１３２が通信可能であるかどうかの判定が行われる。

まず、前提条件として、デバイス管理エージェント３３１に、前述したデバイス管理サーバーのＷｅｂサーバー３１１からのクロスドメイン通信を受け付ける機能をＷｅｂサーバー３３３に搭載しておく。また、本実施例では、クロスドメイン通信の標準技術であるＣＯＲＳ（Ｃｒｏｓｓ−ＯｒｉｇｉｎＲｅｓｏｕｒｃｅＳｈａｒｉｎｇ）を利用した場合の処理フローで説明する。クロスドメイン通信を許可するには、転送元であるオリジンドメインを信頼するドメインとする設定が必要である。Ｗｅｂサーバー３３３に、デバイス管理サーバーのＷｅｂサーバー３１１のドメイン「ｗｗｗ．ｄｅｖｉｃｅ−ｍａｎａｇｅｍｅｎｔ−ｃｌｏｕｄ．ｃｏｍｐａｎｙ」をオリジンドメインとする通信を許可する。不明な第三者のドメインを信頼するのはセキュリティ上推奨されないが、デバイス管理エージェント３３１は、デバイス管理サーバー１１１にＲＥＳＴＡＰＩ３１２を介してデータを送信するクライアントにあたる。そのため、元々サーバー・クライアントの信頼関係にあり、デバイス管理サーバーのＷｅｂサーバー３１１のドメインを許可することは問題ない。

Ｓ６１２で、ブラウザー３２１は、ＪａｖａＳｃｒｉｐｔ内の命令を実行して、デバイス管理エージェント３３１のＷｅｂサーバー３３３へ、通信疎通確認リクエストを送信する。ブラウザー３２１は、クロスドメイン通信と判断した場合に、リクエストヘッダーにＯｒｉｇｉｎフィールドを付けて、オリジンドメインをセットする。この際の、通信宛先ＵＲＬおよびＨＴＴＰリクエストの例は以下のようになる。
ＵＲＬ：
ｈｔｔｐｓ：／／１９２．１６８．０．１１／ａｇｅｎｔ／ａｐｉ／ｅｃｈｏ／
ＨＴＴＰリクエスト（抜粋）：
ＰＯＳＴ／ａｇｅｎｔ／ａｐｉ／ｅｃｈｏ／ＨＴＴＰ／１．１
Ｈｏｓｔ：１９２．１６８．０．１１
Ｏｒｉｇｉｎ：ｈｔｔｐｓ：／／ｗｗｗ．ｄｅｖｉｃｅ−ｍａｎａｇｅｍｅｎｔ−ｃｌｏｕｄ．ｃｏｍｐａｎｙ
Ｓ６１３で、通信先ＩＰアドレスからリクエストに対する応答がない場合は、コンピューター１２２が、コンピューター１２１と通信可能なネットワーク内に存在しないと判定される。そして、該当の管理エージェントの管理対象デバイスのＩＰアドレスへのＵＲＬリンクは生成されない。

Ｓ６１４で、デバイス管理エージェント３３１のＷｅｂサーバー３３３は、ブラウザー３２１から通信疎通確認リクエストを受信する。Ｓ６１５で、Ｗｅｂサーバー３３３は、ＨＴＴＰリクエストヘッダーにセットされてきたＯｒｉｇｉｎフィールドを読み出す。Ｓ６１６で、Ｗｅｂサーバー３３３は、許可済みのオリジンドメインとして保持している、デバイス管理サーバーのＷｅｂサーバー３１１のドメイン「ｗｗｗ．ｄｅｖｉｃｅ−ｍａｎａｇｅｍｅｎｔ−ｃｌｏｕｄ．ｃｏｍｐａｎｙ」であるか否かを確認する。Ｓ６１６での判定がＮｏの場合、Ｓ６１７でＷｅｂサーバー３３３はエラーを応答する。ブラウザー３２１は、エラー応答の場合Ｓ６１３に進み、該当の管理エージェントの管理対象デバイスのＩＰアドレスへのＵＲＬリンクは生成しない。Ｓ６１６の判定がＹｅｓの場合、Ｓ６１８でＷｅｂサーバー３３３はＯＫを応答する。この場合のＨＴＴＰレスポンスの例は以下のようになる。
ＨＴＴＰ／１．１２００ＯＫ
Ａｃｃｅｓｓ−Ｃｏｎｔｒｏｌ−Ａｌｌｏｗ−Ｏｒｉｇｉｎ：ｈｔｔｐｓ：／／ｗｗｗ．ｄｅｖｉｃｅ−ｍａｎａｇｅｍｅｎｔ−ｃｌｏｕｄ．ｃｏｍｐａｎｙ
Ａｃｃｅｓｓ−Ｃｏｎｔｒｏｌ−Ａｌｌｏｗ−Ｏｒｉｇｉｎヘッダーフィールドは、ＣＯＲＳで規定されている許可対象オリジンドメインを示すフィールドである。

Ｓ６１９で、ブラウザー３２１は、ＪａｖａＳｃｒｉｐｔ内の命令を実行し、該当の管理エージェントの管理対象デバイスのＩＰアドレスへのＵＲＬリンクを生成する。

以上の処理によって、ブラウザー３２１からデバイス管理エージェント３３１のＷｅｂサーバー３３３と通信疎通確認が取れた場合のみ、該当のエージェントの管理対象デバイスのＩＰアドレスへのリンクを動的に生成することが可能となった。この場合、コンピューター１２１は、コンピューター１２２、デバイス１３１、１３２と同じプライベートネットワークに存在していると判定できる。すなわち、ブラウザー３２１から、デバイス１３１、１３２のＷｅｂサーバー３４４へのＵＲＬリンクを押下した際に、目的とするデバイスへのＷｅｂサーバーに接続できる。ただし、この判定には一部のケースで例外が存在する。ネットワーク、ルーター、ファイアウォール等の設定によっては、通信元・通信先のアドレスやポート番号によって、プライベートネットワーク内においても通信が遮断されている場合もある。しかしながら、これらの少数の例外ケース以外においては、リンクは正しく動作し、ユーザーの利便性向上に寄与する。

ここで、Ｓ６１９にて、デバイスのＩＰアドレスへのＵＲＬリンクを生成後、コンピューター１２１が別のネットワークに移動した場合の動作について説明する。スマートフォンなどのように、コンピューター１２１がＧＰＳ（ＧｌｏｂａｌＰｏｓｉｔｉｏｎｉｎｇＳｙｓｔｅｍ）やモーションセンサーなどで位置情報の変化を検出したら、Ｗｅｂページをリロードして、Ｓ６０１から再実行すればよい。これにより、コンピューター１２１の最新のネットワークロケーションに応じて、デバイスのＩＰアドレスのＵＲＬへのリンクの有効化・無効化の制御が可能である。なお、位置情報などが取得できない通常のコンピューター等であれば、定期的にリロードして、表示中のＷｅｂページを最新の状態に更新する、という方法でも構わない。

次に、図７のフローチャートを用いて、デバイス管理エージェントのエージェントＩＤを確認する追加の処理フローを説明する。図６にて示した処理フローでは、デバイス管理エージェントを個々に特定する情報としてＩＰアドレスのみを用いている。そのため、別々のプライベートネットワークに、同じＩＰアドレスがアサインされたデバイス管理エージェントがそれぞれ存在する場合に次のような問題がある。コンピューター１２１がどこのネットワーク内に存在するかによって、間違ったデバイス管理エージェント３３１と通信疎通確認をしてしまう可能性がある。

これを解決するには、デバイス管理エージェント３３１が稼働しているコンピューター１２２のＩＰアドレスだけでなく、エージェントＩＤも用いて、通信疎通確認をする。図６の参照ポイントＲ１から図７のＳ７０１に進む。Ｓ７０１で、デバイス管理エージェント３３１のＷｅｂサーバー３３３による通信疎通確認リクエストの応答時にエージェントＩＤを含める。Ｓ７０２で、ブラウザー３２１は、ＪａｖａＳｃｒｉｐｔ内の処理において、Ｓ６１１で特定したデバイス管理エージェント３３１のエージェントＩＤと応答されたエージェントＩＤとを比較する。Ｓ７０３で、ブラウザー３２１は、エージェントＩＤが一致するかを判定する。Ｓ７０３の判定がＮｏの場合、Ｓ７０４に進み、Ｓ６１３と同様に、ブラウザー３２１はデバイスのＩＰアドレスへのＵＲＬリンクを生成しない。Ｓ７０３の判定がＹｅｓの場合、Ｓ７０５に進み、Ｓ６１９と同様に、ブラウザー３２１は該当の管理エージェントの管理対象デバイスのＩＰアドレスへのＵＲＬリンクを生成する。

次に、図８のフローチャートを用いて、デバイスのＩＰアドレスへのＵＲＬリンクを生成する際に、デバイスのステータスを確認する追加の処理フローを説明する。前述の説明のように、ブラウザー３２１からデバイス管理エージェント３３１に通信疎通確認が成功しても、管理対象デバイスの中には、電源が入っていない、一時的にネットワークから外れている、などのケースがあり得る。これらのケースの場合、デバイスのＩＰアドレスへのＵＲＬリンクを生成しても、リンク押下時に通信エラーとなってしまう可能性がある。

これを解決するために、デバイス管理エージェント３３１がデバイス管理サーバー１１１に送信している各デバイスのステータス情報を用いて、通信エラーとなってしまう可能性があるデバイスの取り扱いを区別する手段を提供する。図６の参照ポイントＲ２から図８のＳ８０１に進む。

Ｓ８０１で、ブラウザー３２１は、ＪａｖａＳｃｒｉｐｔ内の処理で、前記受信したデバイス情報のＪＳＯＮデータ内から、それぞれのデバイスにおけるステータスを確認する。Ｓ８０２で、ブラウザー３２１は、ＪＳＯＮデータを参照して、該当デバイスが“ｄｅｖｉｃｅ−ｓｔａｔｕｓ”：“ｃｏｍｍｕｎｉｃａｔｉｏｎ−ｅｒｒｏｒ”のデータを持つかどうか、すなわち該当デバイスは通信エラーが発生中であるかどうかを判定する。Ｓ８０２の判定がＮｏの場合は、Ｓ８０３に処理が進められる。Ｓ８０３で、ブラウザー３２１は、Ｓ６１９同様に、該当デバイスのＩＰアドレスへのＵＲＬリンクを生成する。Ｓ８０２の判定がＹｅｓの場合、Ｓ８０４に処理が進められる。Ｓ８０４では、Ｓ８０３とは異なり、ブラウザー３２１は画面５００のＩＰアドレス表示フィールド５０３に、該当デバイスの詳細ステータス画面５１０へのＵＲＬリンクを生成する。Ｓ８０６では、ブラウザー３２１において、ステータス画面へのＵＲＬリンクが押下されるとＵＲＬリダイレクトが実行されて、デバイス詳細ステータス画面のＷｅｂページがデバイス管理サーバーのＷｅｂサーバー３１１にリクエストされる。Ｓ８０７で、Ｗｅｂサーバー３１１は、前記リクエストを受信して、ユーザーからの正しいリクエストかどうかを判定する。リクエストが正しいと判定されると、Ｓ８０８で、Ｗｅｂサーバー３１１は、ＨＴＭＬ、ＪａｖａＳｃｒｉｐｔなどのＷｅｂページを構成するファイルを応答する。Ｓ８０９で、ブラウザー３２１は、ＨＴＭＬ、ＪａｖａＳｃｒｉｐｔなどのファイルをＷｅｂサーバー３１１から受信する。Ｓ８１０で、ブラウザー３２１は、ＪａｖａＳｃｒｉｐｔの命令を実行し、ページを構成する必要なデータを取得するために、ＲＥＳＴＡＰＩを呼び出す。Ｓ８１１で、Ｗｅｂサーバー３１１は、ブラウザー３２１からＲＥＳＴＡＰＩへのリクエストを受信して、Ｓ８０７と同様にユーザーからの正しいリクエストかどうかを判定する。Ｗｅｂサーバー３１１は、リクエストが正しいと判定されると、リクエストされたＲＥＳＴＡＰＩの処理を実行する。Ｓ８１２で、Ｗｅｂサーバー３１１は、該当デバイス情報の詳細ステータス情報をデータストア３１４から読みだす。Ｓ８１３で、Ｗｅｂサーバー３１１は、データをＪＳＯＮなどのデータ記述言語に変換して、ブラウザー３２１へ応答する。Ｓ８１４で、ブラウザー３２１は、Ｗｅｂサーバー３１１からＪＳＯＮデータを受信する。Ｓ８１５で、ブラウザー３２１は、ＪａｖａＳｃｒｉｐｔ内の命令を実行し、受信したＪＳＯＮデータをＨＴＭＬ内に展開・表示する。結果として、ブラウザー３２１に、画面５１０の、デバイス詳細情報を表示するＷｅｂページが表示される。受信したＪＳＯＮデータを展開・表示した結果が、デバイス情報表示フィールド５１１、詳細ステータス表示フィールド５１２などである。この際、該当デバイスはデバイス管理エージェント３３１が通信エラーを検出している旨の注意喚起のため、メッセージ５１３を表示する。さらに、Ｓ８１６で、ブラウザー３２１は、表示フィールド５１４にデバイスのＩＰアドレスへのＵＲＬリンクを生成する。

図８のフローチャートの処理により、図６のフローチャートで説明した処理に加え、ステータスが通信エラーのデバイスが存在する場合に、以下の追加の処理が可能となる。通信エラーの対象デバイスの場合は、デバイス詳細ステータス画面へリダイレクトして、注意喚起のメッセージを表示した上で、デバイスのＩＰアドレスのＵＲＬリンクを提供することができる。

本実施例では、以上説明したように、デバイス管理サーバー１１１のＷｅｂサーバー３１１が提供するＷｅｂページをブラウザー３２１で表示する際に、次のことが可能となる。デバイス管理サーバー１１１からの応答に含まれるスクリプト情報に基づき、ブラウザー３２１からデバイス管理エージェント３３１への通信疎通確認が実行された。ブラウザー３２１が実行されているコンピューター１２１とデバイス１３１、１３２が同一プライベートネットワークに存在する場合、疎通確認が成功となる。その後、ブラウザー３２１では、デバイス管理エージェント３３１の管理対象デバイス１３１、１３２のＩＰアドレスへのリンクが生成されて、デバイスのウェブサーバーへのアクセスを可能とする表示制御が行われる。本実施例により、ブラウザーが実行されているコンピューターが、表示対象のデバイスと同一プライベートネットワークに存在することの確認が取れた際に、デバイスのＩＰアドレスへのリンクを生成することが可能となる。

（第２の実施例）
次に、図９、１０を用いて、第２の実施例を説明する。第２の実施例では、デバイス管理エージェント３３１がデバイス１３１のうちの１台あるいは複数台にインストールされて運用されるケースにおける実施の形態を説明する。

まず、この形態の一つのメリットとして、デバイス１３１、１３２を監視・管理するために、デバイス管理エージェント３３１の動作するコンピューター１２２を用意しなくても良いという点が挙げられる。一方、デバイス１３１、１３２のハードウェア・ソフトウェア仕様・制限・構成によっては、追加のソフトウェアを動作させることができないデバイスも存在する。

図９は、デバイス管理サーバー１１１が提供するＷｅｂページの例である。９００はデバイス一覧画面である。９０１は、４０１と同様に、表示対象の顧客テナント名・顧客テナントＩＤを表示するフィールドである。９０２は、前述の顧客テナント内で管理されているデバイス一覧を表示しており、デバイスの情報あるいはステータスなどのデータが参照可能である。９０３は、各デバイスのＩＰアドレスを表示するカラムである。９１０はデバイス管理エージェント一覧画面である。９１１は、顧客テナント内で管理されているデバイス管理エージェント一覧を表示しており、エージェントの情報あるいはステータスなどのデータが参照可能である。第１の実施例と異なる点は、次の通りである。まず、第２の実施例において、９１１に示されるデバイス１３１にインストールしたデバイス管理エージェントのエージェントタイプはＤｅｖｉｃｅＡｇｅｎｔである。これは、第１の実施例においてコンピューター１２２にインストールしたデバイス管理エージェントのエージェントタイプはＰＣＡｇｅｎｔであり、インストール先の違いによって区別をしている。９０２内、通信対象エージェントのカラムには、各々のデバイスがどのデバイス管理エージェントによって監視されているかの関係が示されている。さらに、９１１内のエージェント名やＩＰアドレスと突き合わせると、どのデバイスがどのデバイス内のデバイス管理エージェント３３１によって監視されているのかの関係が確認できる。シリアルナンバーＩＭＲ８３２２１のデバイスとＰＣＹ７５５１８のデバイスは、自身のデバイス内のデバイス管理エージェント３３１によって、自デバイスの動作ログやステータスを取得、デバイス管理サーバー１１１にデータを送信している。シリアルナンバーＩＭＲ８３２２０のデバイスは、自身のデバイス内のデバイス管理エージェント３３１によって、自デバイスに加え、他３つのデバイスの動作ログやステータスを取得し、デバイス管理サーバー１１１にデータを送信している。

図１０のフローチャートを用いて、デバイス１３１にデバイス管理エージェント３３１をインストールして運用している形態の場合に、デバイス一覧画面９００にデバイスのＩＰアドレスへのリンクを生成する処理フローについて説明する。

最初の処理は、図６のＳ６０１からＳ６１１まで、第１の実施例と同じである。図６の参照ポイントＲ３から、図１０のＳ１００１に進む。Ｓ１００１で、ブラウザー３２１は、ＪａｖａＳｃｒｉｐｔ内の処理において、デバイス管理エージェント一覧内でエージェントのバージョンとステータスを確認する。Ｓ１００２で、ブラウザー３２１は、ステータスが稼働中、かつ、通信疎通確認のためのリクエストを受信可能とするＡＰＩを搭載しているバージョンのデバイス管理エージェントが存在するかを判定する。Ｓ１００２の判定がＮｏの場合、Ｓ１００３に進み、デバイスのＩＰアドレスへのＵＲＬリンクは生成されない。

Ｓ１００４で、ブラウザー３２１は、同一サブネットの管理エージェントとの疎通確認を１台ずつ実行するかどうかの判定をする。Ｓ１００４の判定がＹｅｓの場合、Ｓ１００５に処理が進められる。Ｓ１００５で、デバイス管理エージェントが稼働しているデバイス１台１台に対して、図６のＳ６１２からと同じ処理フローを実行する。結果として、デバイス管理エージェントとの通信疎通確認が成功した場合、画面９００のＩＰアドレス表示カラム９０３に、該当のデバイス管理エージェントの管理対象デバイスへのＵＲＬリンクが生成される。Ｓ１００１の判定がＮｏの場合、Ｓ１００６に処理が進められる。Ｓ１００６で、ブラウザー３２１は、同一サブネット内の１台のデバイスに対して、Ｓ６１２からと同じ処理フローを実行する。Ｓ１００７で、ブラウザー３２１は、デバイス管理エージェントが稼働しているデバイス１台ごとに通信疎通確認に成功したかを判定する。Ｓ１００７の判定がＮｏの場合は、次のデバイスに対して、デバイス管理エージェントへの通信疎通確認リクエストを試行する。Ｓ１００７の判定がＹｅｓの場合、Ｓ１００８で、ブラウザー３２１は、画面９００のデバイスのＩＰアドレス表示カラム９０３において、同一サブネット内のデバイスのＩＰアドレスへのＵＲＬリンクを生成する。

本実施例では、デバイス管理エージェントがデバイス１３１のうちの１台あるいは複数台にインストールされている場合について説明した。以上説明したように、デバイス管理サーバー１１１のＷｅｂサーバー３１１が提供するＷｅｂページをブラウザー３２１で表示する際に、次のことが可能となる。ブラウザー３２１は、ステータスが稼働中、かつ、通信疎通確認リクエストを受け付けるＡＰＩを搭載しているバージョンのデバイス管理エージェントが存在すると確認できた際に、デバイス１台１台に対して通信疎通確認を行う。その後、通信疎通確認に成功した際に、ブラウザー３２１では、デバイス管理エージェント３３１の管理対象デバイス１３１、１３２のＩＰアドレスへのリンクが生成された。本実施例により、ブラウザーが実行されているコンピューターが、表示対象のデバイスと同一プライベートネットワークに存在することの確認が取れた際に、デバイスのＩＰアドレスへのリンクを生成することが可能となる。

なお、上述の実施例においては、デバイスのＩＰアドレスのＵＲＬリンクを生成する、という説明をしたが、ＷｅｂサーバーのＵＲＬとして有効なものであれば、他の形式でも構わない。例えば、ＩＰアドレスの代わりに、デバイスのホスト名、あるいはプライベートドメインのＦＱＤＮなど、該当のデバイスのＷｅｂサーバーのＵＲＬとして有効なものであれば利用可能である。

（他の実施例）
本発明は、上述した実施形態を適宜組み合わせることにより構成された装置あるいはシステムやその方法も含まれるものとする。

ここで、本発明は、上述した実施形態の機能を実現する１つ以上のソフトウェア（プログラム）を実行する主体となる装置あるいはシステムである。また、その装置あるいはシステムで実行される上述した実施形態を実現するための方法も本発明の１つである。また、そのプログラムは、ネットワークまたは各種記憶媒体を介してシステムあるいは装置に供給され、そのシステムあるいは装置の１つ以上のコンピューター（ＣＰＵやＭＰＵ等）によりそのプログラムが読み出され、実行される。つまり、本発明の１つとして、さらにそのプログラム自体、あるいは当該プログラムを格納したコンピューターにより読み取り可能な各種記憶媒体も含むものとする。また、上述した実施形態の機能を実現する回路（例えば、ＡＳＩＣ）によっても、本発明は実現可能である。

１１１デバイス管理サーバー
１２１コンピューター
１２２コンピューター
２０３ＣＰＵ
３２１ブラウザー
３３１デバイス管理エージェント
３３２デバイス管理アプリケーション
３３３Ｗｅｂサーバー

Claims

デバイス情報を管理する管理システムであって、
情報処理端末からデバイス情報の取得要求を受信した際に、デバイス情報を表示するための情報と、該デバイス情報に対応するデバイスが搭載するウェブサーバーへのアクセスが許可されるか否かの確認のための通信を前記情報処理端末に実行させるための命令を含むスクリプト情報と、を前記情報処理端末に対して応答する応答手段を有し、
前記情報処理端末では、前記スクリプト情報に含まれる命令の実行によって、前記デバイスが搭載する前記ウェブサーバーへのアクセスが許可されないと判断した場合に、当該ウェブサーバーへのアクセスが制限されることを特徴とする管理システム。
前記ウェブサーバーへのアクセスが許可されるか否かの確認のための通信では、ＨＴＴＰ（ＨｙｐｅｒｔｅｘｔＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ）でのクロスドメイン通信が用いられることを特徴とする請求項１に記載の管理システム。
複数のデバイスと前記複数のデバイスを監視する中継装置とが顧客ネットワーク内に存在し、かつ、前記中継装置がクロスドメイン通信を受け付ける機能を備えている場合に、前記情報処理端末では、前記応答手段により応答されたスクリプト情報に含まれる命令の実行によって前記中継装置に対してクロスドメイン通信を行うことで、前記ウェブサーバーへのアクセスが許可されるか否かの確認が実行されることを特徴とする請求項１または２に記載の管理システム。
前記情報処理端末では、
前記情報処理端末が前記顧客ネットワーク内に存在する場合には、前記中継装置との前記クロスドメイン通信が成功し、前記ウェブサーバーへのアクセスが許可され、
前記情報処理端末が前記顧客ネットワーク内に存在しない場合には、前記中継装置との前記クロスドメイン通信が失敗することを特徴とする請求項３に記載の管理システム。
前記情報処理端末では、前記デバイス情報を表示するための情報に基づき、デバイス一覧が表示され、
前記デバイス一覧に含まれるデバイスが搭載するウェブサーバーへのアクセスを許可される場合に、前記デバイス一覧に含まれるデバイスが搭載するウェブサーバーへアクセスするためのリンクが有効化されることを特徴とする請求項１乃至４のいずれか１項に記載の管理システム。
前記情報処理端末が移動したことに応じて、または、定期的に、前記情報処理端末で表示中の画面が更新されることを特徴とする請求項１乃至５のいずれか１項に記載の管理システム。
デバイス情報を管理する管理システムの制御方法であって、
情報処理端末からデバイス情報の取得要求を受信した際に、デバイス情報を表示するための情報と、該デバイス情報に対応するデバイスが搭載するウェブサーバーへのアクセスが許可されるか否かの確認のための通信を前記情報処理端末に実行させるための命令を含むスクリプト情報と、を前記情報処理端末に対して応答する応答工程を有し、
前記情報処理端末では、前記スクリプト情報に含まれる命令の実行によって、前記デバイスが搭載する前記ウェブサーバーへのアクセスが許可されないと判断した場合に、当該ウェブサーバーへのアクセスが制限されることを特徴とする制御方法。