デバイスインタラクションツリー及び技術
【課題】デバイスの状態を決定するためのデバイスインタラクションツリーを生成及び利用する方法、装置及び非一時的コンピュータ可読記憶媒体が開示される。
【解決手段】デバイスインタラクションツリーは、ルートノード、中間ノード及びリーフノードを有する。中間ノードは、クエリ及びテストを規定し、リーフノードは、デバイスの状態を規定する。所与のデバイスの状態は、ルートノードから１以上の中間ノードを介しリーフノードまでデバイスインタラクションツリーを移動することによって決定される。移動中、ツリーの現在ノードに関連付けされたクエリが、レスポンスを取得するため所与のデバイスに送信される。現在ノードに関連付けされたテストが、１以上の値に対してレスポンスを評価するのに利用される。テストの結果は、ツリーのリーフノードに向かうパス上の次のノードを決定する。デバイスの状態は、ツリーの移動から得られるリーフノードによって特定される。
【解決手段】デバイスインタラクションツリーは、ルートノード、中間ノード及びリーフノードを有する。中間ノードは、クエリ及びテストを規定し、リーフノードは、デバイスの状態を規定する。所与のデバイスの状態は、ルートノードから１以上の中間ノードを介しリーフノードまでデバイスインタラクションツリーを移動することによって決定される。移動中、ツリーの現在ノードに関連付けされたクエリが、レスポンスを取得するため所与のデバイスに送信される。現在ノードに関連付けされたテストが、１以上の値に対してレスポンスを評価するのに利用される。テストの結果は、ツリーのリーフノードに向かうパス上の次のノードを決定する。デバイスの状態は、ツリーの移動から得られるリーフノードによって特定される。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、デバイスとやりとりするためのデバイスインタラクションツリーに関する。
【背景技術】
【０００２】
中規模から大規模な企業はしばしば、パーソナルコンピュータに加えてアタッチされた各種デバイスを有する多様なコンピュータネットワークを有している。プリンタや複合機などのデバイスが入力されるリクエストを処理するのに十分な用紙やトナーを備えてオンラインのワーキング状態に維持されるとき、企業は最も効率的に機能する。限られた予算とスタッフを有するＩＴ（Ｉｎｆｏｒｍａｔｉｏｎ Ｔｅｃｈｎｏｌｏｇｙ）部門は、典型的には、これらのデバイスを利用可能にし続けるために、これらをメンテナンス及び修繕する。例えば、プリンタや複合機などのデバイスは、用紙やトナーレベルが低いとき、用紙やトナーを補充することによってメンテナンスされる。他の例として、デバイスは、紙詰まりを取り除いたり、開放されたままのデバイスのカバーを閉じることによって修復される。リクエストを処理することができないデバイスは、企業の効率的な運営を妨げ、ＩＴ部門に対して影響を及ぼす可能性がある。
【０００３】
デバイスを物理的にチェックする代わりに、ＩＴスタッフは、ネットワークを介しデバイスと遠隔的にやりとりするよう設計されたカスタマイズされたマネージメントアプリケーションを利用するかもしれない。各種のデバイスが、各種のカスタマイズされたデバイスマネージメント命令に応答する。各種デバイスが企業によって利用されるため、ＩＴスタッフは、企業により利用されるすべてのデバイスとやりとりすることが可能な単一のマネージメントアプリケーションを有していない可能性がある。さらに、マネージメントアプリケーションはネットワークに現在あるすべてのデバイスとやりとりすることが可能であったとしても、サポートされていないデバイスがネットワークに追加される可能性がある。新たなデバイスをサポートするためカスタマイズされたマネージメントアプリケーション更新することは大変であり、カスタマイズされたマネージメントアプリケーションの複雑さのため高いレベルのスキルを必要とする。さらに、セキュリティのため、カスタマイズされたマネージメントアプリケーションの更新は、高い権限のユーザを必要とするかもしれない。更新されたマネージメントアプリケーションが信頼されたソースからのものであったとしても、更新されたマネージメントアプリケーションにおけるバグは、マネージメントアプリケーションを実行するマシーンと共に、マネージメントアプリケーションにより管理されるデバイスに対して予期せぬ影響を与える可能性がある。
【０００４】
ここで説明されたアプローチは、追求可能なアプローチであるが、必ずしも以前に想到又は追求されたアプローチであるとは限らない。従って、特段の指摘がない場合、ここで説明されたアプローチはここに記載されたことによって従来技術とみなされるべきでない。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
本発明の課題は、デバイスの状態を決定するためのデバイスインタラクションツリーを生成及び利用するための技術を提供することである。
【課題を解決するための手段】
【０００６】
デバイスインタラクションツリーは、ルートノード、中間ノード及びリーフノードを有する。デバイスインタラクションツリーの具体例として、デバイス状態決定ツリー、デバイスコンフィギュレーションツリー、デバイスアクションツリーなどがあげられる。デバイス状態決定ツリーの中間ノードはクエリとテストとを規定し、リーフノードはデバイス状態を規定する。所与のデバイスの状態は、ルートノードから１以上の中間ノードを介してリーフノードまでデバイス状態決定ツリーを移動することによって決定される。移動中、ツリーの現在ノードに関連付けされたクエリが、レスポンスを取得するため所与のデバイスに送信される。現在ノードに関連付けされたテストは、１以上の値に対してレスポンスを評価するのに利用される。テストの結果は、ツリーのリーフノードに向かうパス上の次のノードを決定する。デバイスの状態は、ツリーの移動先となるリーフノードにより規定される。
【発明の効果】
【０００７】
本発明によると、デバイスの状態を決定するためのデバイスインタラクションツリーを生成及び利用するための技術を提供することができる。
【図面の簡単な説明】
【０００８】
【図１Ａ】図１Ａは、ネットワーク内の複数のデバイスをモニタリングするための一例となるデバイスモニタシステムを示す。
【図１Ｂ】図１Ｂは、既知のクラスのデバイスがネットワークに追加されたことを検出する一例となるデバイスモニタシステムを示す。
【図１Ｃ】図１Ｃは、未知のクラスのデバイスがネットワークに追加されたことを検出する一例となるデバイスモニタシステムを示す。
【図２】図２は、デバイスインタラクションツリーセットのための一例となるクラス図である。
【図３】図３は、デバイスとやりとりするためのツリーセットにおける一例となるコンポーネントを示す。
【図４】図４は、３レベルの一例となるツリーを示す。
【図５】図５は、デバイスのクラスを決定し、複数のデバイスインタラクションツリーの１つを選択するための一例となるデバイス分類を示す。
【図６】図６は、デバイスのベンダＩＤを取得するための一例となるツリーを示す。
【図７Ａ】図７Ａは、デバイスを単一のクラスに分類するための一例となるツリーを示す。
【図７Ｂ】図７Ｂは、デバイスを複数のクラスの１つに分類するための一例となるツリーを示す。
【図８Ａ】図８Ａは、クエリレスポンスディクショナリの一例となる構造を示す。
【図８Ｂ】図８Ｂは、８個のクエリを有する一例となるクエリレスポンスディクショナリを示す。
【図８Ｃ】図８Ｃは、４個のクエリがＩＤクエリである１１個のクエリを有する一例となるクエリレスポンスディクショナリを示す。
【図９Ａ】図９Ａは、新たなデバイスをサポートするためツリーを自動的に更新するための一例となる処理を示す。
【図９Ｂ】図９Ｂは、新たなデバイスをサポートするためツリーを手動により更新するための一例となる処理を示す。
【図１０Ａ】図１０Ａは、ツリーへの更新が中央サーバから受信される実施例を示す。
【図１０Ｂ】図１０Ｂは、ツリーへの更新がユーザ入力に基づく実施例を示す。
【図１１】図１１は、デバイスマネージメントアプリケーションがツリーを利用及び更新する実施例を示すフローチャートである。
【図１２】図１２は、デバイスマネージメントアプリケーションが一時的にツリーにノードを追加し、ノードが永続的なものになる前にクライアントがノードを有効にすることを可能にする実施例を示すフローチャートである。
【図１３】図１３は、デバイスマネージメントアプリケーションが中央サーバから受信したクエリレスポンスディクショナリに基づきツリーを更新する実施例を示す。
【図１４Ａ】図１４Ａは、一例となるデバイスインタラクションツリーの移動を示すフローチャートである。
【図１４Ｂ】図１４Ｂは、一例となるデバイスインタラクションツリーの移動を示すフローチャートである。
【図１４Ｃ】図１４Ｃは、一例となるデバイスインタラクションツリーの移動を示すフローチャートである。
【図１５】図１５は、開示された各種実施例を実行する一例となるコンピュータシステムを示す。
【発明を実施するための形態】
【０００９】
以下の説明では、本発明の完全な理解を提供するため、説明のための多数の具体的詳細が提供される。しかしながら、本発明はこれらの具体的詳細なしに実現されてもよいことは明らかであろう。他の例では、本発明を不必要に不明りょうにすることを避けるため、周知の構成及び装置はブロック図の形式により示される。
［全体概略］
デバイスの状態を決定するためのデバイスインタラクションツリーを生成及び利用するための方法、装置及び非一時的なコンピュータ可読記憶媒体が開示される。デバイスインタラクションツリーは、ルートノード、中間ノード及びリーフノードを有する。デバイスインタラクションツリーの具体例として、デバイス状態決定ツリー、デバイスコンフィギュレーションツリー、デバイスアクションツリーなどがあげられる。デバイス状態決定ツリーの中間ノードはクエリとテストとを規定し、リーフノードはデバイス状態を規定する。所与のデバイスの状態は、ルートノードから１以上の中間ノードを介してリーフノードまでデバイス状態決定ツリーを移動することによって決定される。移動中、ツリーの現在ノードに関連付けされたクエリが、レスポンスを取得するため所与のデバイスに送信される。現在ノードに関連付けされたテストは、１以上の値に対してレスポンスを評価するのに利用される。テストの結果は、ツリーのリーフノードに向かうパス上の次のノードを決定する。デバイスの状態は、ツリーの移動先となるリーフノードにより規定される。
【００１０】
デバイスインタラクションツリーの具体例の詳細な理解を提供するため、デバイス状態決定ツリーの各種具体例が示される。これらの具体例の多くは、デバイスの状態を決定する代わりに又は加えて、デバイスのパラメータを変更するよう構成されるデバイスコンフィギュレーションツリーに関して適用されてもよい。例えば、デバイスコンフィギュレーションツリーは、デバイスの名前を変更するのに利用されてもよい。あるいは、これらの具体例の多くは、デバイスの状態を決定する代わりに又は加えて、デバイスに特定のアクションを実行させるよう構成されるデバイスアクションツリーに関して適用されてもよい。例えば、デバイスアクションツリーは、デバイスに指定された設定に従って文書を印刷させるのに利用されてもよい。
［状態決定ツリー］
１つの状態決定ツリーが、複数のデバイスの状態を決定するのに利用されてもよい。サポートされるデバイスは、様々な機能を備えたデバイス、様々な構成を備えたデバイス、様々なメーカーからのデバイス、及び／又は同じクエリに異なって応答する同一の状態を備えたデバイスを含むものであってもよい。デバイスインタラクションツリーは、デバイスインタラクションツリーを移動するため構成されたソフトウェアを修正することなく、生成又は修正されてもよい。一実施例では、デバイスインタラクションツリーの生成、修正、置換及び／又はテストは、より少数のセキュリティ権限を要求し、特殊化されたデバイスマネージメントソフトウェアをインストール、コンパイル又は修正するよりも、ネットワーク上のデバイスに対してより低いセキュリティリスクしか有さない。
【００１１】
ここに開示される技術は、何れかのタイプのデバイス状態に適用されてもよい。デバイス状態の具体例として、限定することなく、アイドル、スリープ中、処理中又は印刷中、印刷準備完了、ウォーミングアップ、トナー交換、調整、ジョブ中止、カバーオープン、トナー切れ、フューザ切れ、又は紙詰まりがあげられる。デバイス状態は、デバイスの動作状態を記述するものであってもよい。一実施例では、動作状態は、デバイスによって現在実行中のアクションのタイプ又はアクションがないことを含む。他の実施例では、動作状態は、デバイスがアクションを実行することを阻害しているエラーを含む。他の実施例では、デバイス状態は、用紙トレーサイズ、３穴パンチ、２穴パンチ又はステープラなどのデバイス設定を含む。他の実施例では、デバイス状態は、トナーレベル（７５％など）、用紙残量（５０頁など）、又はバッテリ残量（６０％又は３時間など）などの供給状態を含む。各種実施例では、各種タイプの状態が同一のツリーにより表現されてもよい。例えば、単一の状態決定ツリーは、エラー、動作状態、デバイスの設定及び／又は供給状態に関する情報を提供するものであってもよい。一実施例では、デバイスの状態に対するリクエストは、要求されるタイプの情報を指定する。例えば、１つのリクエストは、デバイスの動作状態に対するものであり、他のリクエストは、デバイスが３穴パンチャを備えるよう構成されているかを決定するためのものであってもよい。
【００１２】
一実施例では、デバイスマネージメントアプリケーションは、デバイスの状態に対するリクエストを受信する。一例では、リクエストは、アドレスによってデバイスを特定する。デバイスマネージメントアプリケーションは、アドレスに送信するクエリを選択するため、状態決定ツリーにアクセスし、当該アドレスにおいてデバイスからレスポンスが受信される。デバイスマネージメントアプリケーションは、デバイスからのレスポンスに基づき１以上の中間ノードを介しリーフノードまで状態決定ツリーを移動することによって、デバイスの状態を決定する。リーフノードはデバイスの状態を示し、デバイスマネージメントアプリケーションは、デバイス状態のリクエストに応答して、デバイス状態をユーザインタフェース上に表示するようにしてもよい。ツリーの移動中、デバイスマネージメントアプリケーションは、単にクエリを利用し、状態決定ツリーにより規定されるテストを適用する。従って、デバイスマネージメントアプリケーションが状態決定ツリーなどのデバイスインタラクションツリーを移動するよう構成されると、デバイスインタラクションツリーは、デバイスマネージメントアプリケーションのコードを修正することなく更新されるようにしてもよい。
【００１３】
一実施例では、デバイスマネージメントアプリケーションはネットワーク上のデバイスをモニタし、状態決定ツリーがネットワーク内のあるデバイスの状態を提供することができないことを検出したことに応答して、状態決定ツリーが更新される。一実施例では、この更新は、更新されたデバイスインタラクションツリーを提供するサーバから要求される。この更新は、デバイスマネージメントアプリケーションのコードを修正することなく、既存のデバイスインタラクションツリーの置換、新たなデバイスインタラクションツリーの生成、及び／又は既存のデバイスのノードの追加、削除又は変更を行うものであってもよい。
【００１４】
一実施例では、デバイスマネージメントアプリケーションは、クエリ及びレスポンス情報に関連付けされた受信した状態情報に基づき、状態決定ツリーを生成又は修正する。一実施例では、この情報は、新たな関連付けが検出されると、デバイスマネージメントアプリケーションに通知するサーバから受信される。関連付けされた状態情報、クエリ情報及びレスポンス情報は、新たな状態決定ツリーを生成するため、デバイスマネージメントアプリケーションのコードを修正することなく既存の状態決定ツリーのノードを追加、削除又は修正するのに利用されてもよい。
【００１５】
他の実施例では、ツリーを生成又は修正するのに利用される情報の一部又はすべてが、ユーザインタフェースを介しユーザにより提供されるようにしてもよい。一例では、ユーザは、ネットワーク上のあるデバイスのある状態が観察されたことを示す。これに応答して、デバイスマネージメントアプリケーションは、あるレスポンスを導くため、当該デバイスにあるクエリを送信する。特定の状態、クエリ及びレスポンスの指示は、デバイスマネージメントアプリケーションのコードを変更することなく、新たな状態決定ツリーを生成するため、及び／又は既存の状態決定ツリーについてノードを追加、削除若しくは修正するのに利用されてもよい。
【００１６】
図１Ａは、ネットワーク１０８を介しデバイス１１０Ａ，１１０Ｂ，１１０Ｃと通信する一例となるデバイスモニタシステム１００を示す。例えば、デバイスモニタシステム１００は、１以上の状態決定ツリーを用いてネットワーク１０８のデバイス１１０Ａ，１１０Ｂ，１１０Ｃの状態を決定するデバイスマネージメントアプリケーション（図示せず）を有してもよい。図示されるように、デバイスモニタシステム１００は、クエリ及びテストを指定する実行可能コード及び状態決定ツリー１０２のファンクションライブラリ１０６を有する。ファンクションライブラリ１０６は、デバイス１１０Ａ，１１０Ｂ，１１０Ｃに関して汎用的であって、任意的にはデバイスのクラスに関しても汎用的なファンクションを有する。すなわち、これらのファンクションは、何れかの状態決定ツリーと何れかのデバイス情報セットとにより機能する。一実施例では、デバイスマネージメントアプリケーションは、状態決定ツリー１０２を構成、実行又は更新するため、ファンクションライブラリ１０６からファンクションを呼び出す。ファンクションライブラリ１０６からのＣｏｎｓｔｒｕｃｔＱＴｒｅｅファンクションは、状態決定ツリーを構成する。ファンクションライブラリ１０６からのＥｘｅｃｕｔｅＱＴｒｅｅファンクションは、デバイスに送信するため状態決定ツリー１０２からクエリを選択し、デバイスから結果を受信し、当該結果に状態決定ツリー１０２からのテストを適用し、デバイスの状態を決定する。
【００１７】
図示されるように、デバイスモニタシステムはまた、デバイスインタラクションツリー１０２が構成されるデバイス情報１０４を有する。デバイス情報１０４は、各デバイス１１０Ａ，１１０Ｂ，１１０Ｃに固有の情報を有する。デバイスインタラクションツリー１０２は、デバイスモニタシステム１００がデバイス１１０Ａ，１１０Ｂ，１１０Ｃに関する新たな情報を受信すると、ＵｐｄａｔｅＱＴｒｅｅファンクションにより修正されてもよい。
［クエリ及びレスポンス］
デバイス状態は、当該デバイスに対するクエリ系列へのレスポンスに基づき決定されてもよい。例えば、第１クエリに対する第１レスポンスは、デバイスが属するデバイスのクラスを決定するのに十分な情報を提供し、第２クエリに対する第２レスポンスは、デバイスの状態を決定するのに十分な情報を提供するものであってもよい。他の例では、第２クエリに対する第３レスポンスと、おそらく第４クエリに対する第４レスポンスとが、状態が決定可能になる前に求められる。
【００１８】
ここに開示される技術は、デバイスから情報を抽出するための何れかのタイプのクエリに適用されてもよい。クエリのタイプの具体例として、ＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）クエリ、ＰＪＬ（Ｐｒｉｎｔｅｒ Ｊｏｂ Ｌａｎｇｕａｇｅ）クエリ、ＰｏｓｔＳｃｒｉｐｔクエリ、ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）クエリがあげられる。開示される各種実現形態は、これらクエリのタイプの具体例のすべて、１つ又は組み合わせを利用するものであってもよいし、又は何れを利用しなくてもよい。一実施例では、状態決定ツリーのクエリ及びテストは、何れかのデバイスの状態又は設定を変更不可であり、又はネットワーク内のデバイス上で実行されるソフトウェアを変更不可である。このようにして、状態決定ツリーに対する更新は、ツリーのソースが未知であったとしても、又はソースの評判が未知であったとしても、大きなセキュリティリスクなくテストされてもよい。
【００１９】
テーブル１は、各種メーカーにより製造される各種デバイスについて、ｈｒＤｅｖｉｃｅＤｅｓｃｒ、ｈｒＰｒｉｎｔｅｒＳｔａｔｕｓ、ｈｒＤｅｖｉｃｅＳｔａｔｕｓ、ｈｒＰｒｉｎｔｅｒＤｅｔｅｃｔｅｄＥｒｒｏｒＳｔａｔｅ、ｐｒｔＡｌｅｒｔＣｏｄｅ、ｐｒｔＡｌｅｒｔＣｏｄｅ、ｐｒｔＡｌｅｒｔＧｒｏｕｐ、ｐｒｔＡｌｅｒｔＬｏｃａｔｉｏｎ、ｐｒｔＡｌｅｒｔＳｅｖｅｒｉｔｙＬｅｖｅｌ、及びｐｒｔＡｌｅｒｔＴｒａｎｓｉｎｉｎｇＬｅｖｅｌを含むＳＮＭＰクエリに対する一例となるデバイスレスポンスを示す。すべてのプリンタがアイドル又はスリープ状態にあり、３つが低トナー状態を報告していた（Ｓａｍｓｕｎｇ７７０，ＯＫＩ ＭＣ３６０及びＲｉｃｏｈ Ａｆｉｃｉｏ Ｃ４２０）。テーブル１は、Ａｐｐｅｎｄｉｘ Ａに含まれている。
【００２０】
図示されるように、ＩＰアドレス１７２．３０．４．５５のデバイスは、“ＨＰ ＬａｓｅｒＪｅｔ Ｐ４０１４”によりｈｒＤｅｖｉｃｅＤｅｓｃｒクエリに応答し、“ｉｄｌｅ”によりｈｒＰｒｉｎｔｅｒＳｔａｔｕｓクエリに応答し、“ｒｕｎｎｉｎｇ”によりｈｒＤｅｖｉｃｅ Ｓｔａｔｕｓに応答し、“００”によりｈｒＰｒｉｎｔｅｒＤｅｔｅｃｔｅｄ Ｅｒｒｏｒ Ｓｔａｔｅクエリに応答し、“ｓｕｂｕｎｉｔＰｏｗｅｒＳａｖｅｒ”によりｐｒｔＡｌｅｒｔＣｏｄｅクエリに応答し、“ｇｅｎｅｒａｌＰｒｉｎｔｅｒ”によりｐｒｔＡｌｅｒｔＧｒｏｕｐクエリに応答し、“３５０７８”によりｐｒｔＡｌｅｒｔＬｏｃａｔｉｏｎクエリに応答し、“ｏｔｈｅｒ”によりｐｒｔＡｌｅｒｔＳｅｖｅｒｉｔｙＬｅｖｅｌクエリに応答し、“ｕｎｔｒａｉｎｅｄ”によりｐｒｔＡｌｅｒｔＴｒａｎｉｎｉｎｇＬｅｖｅｌクエリに応答した。この情報は、当該デバイス及び他のデバイスに関する他の情報と共に、デバイスの状態を確実に決定するため、状態決定ツリーを構成するのに利用されてもよい。一実施例では、状態決定ツリーの利用は、デバイスがアイドルであることを決定する前に、これらのクエリのすべてではないが一部をデバイスに送信する。
【００２１】
１７２．３０．４．５５のデバイスが“ｉｄｌｅ”によりｈｒＰｒｉｎｔｅｒＳｔａｔｕｓに応答したが、他のアイドル状態のデバイスは、“ｉｄｌｅ”により同じクエリに応答しなかった。例えば、１７２．３０．４．６１のデバイスは、“ｏｔｈｅｒ”によりｈｒＰｒｉｎｔｅｒＳｔａｔｕｓクエリに応答した。従って、デバイスのアドレスを超えた情報がない場合、ｈｒＰｒｉｎｔｅｒＳｔａｔｕｓクエリは、デバイスの実際の状態を決定するのに不十分であるかもしれない。
【００２２】
実際、異なるデバイスモデル、異なる設定を備えた同一モデル、及び異なるインストールされたファームウェアを備えた同一モデルが、同一のクエリに異なって応答するようにしてもよい。一実施例では、状態決定ツリーは、ネットワーク内の各デバイスについて、デバイスの状態を決定するため、デバイスに対する問題へのクエリを指定する。デバイスはクエリに応答し、レスポンスに基づき、状態決定ツリーはデバイスの状態を特定するリーフノードに移動する。
【００２３】
テーブル１の具体例を再び参照して、ｈｒＰｒｉｎｔｅｒＤｅｔｅｃｔｅｄＥｒｒｏｒＳｔａｔｅクエリに対するレスポンスは、低トナーの３つのプリンタについて非ゼロとなる（また、その他のプリンタがゼロを表現する方法の数に留意されたい）。Ｈｏｓｔ Ｒｅｓｏｕｒｃｅｓ ＭＩＢ（ＲＦＣ２７９０）は、ビット＃２が低トナーを示し、ビット＃０が第１バイトの最上位ビットである、タイプＯＣＴＥＴ ＳＴＲＩＮＧを有する当該値のビットとしてエラー状態が符号化されることを述べている。ＲｉｃｏｈとＯｋｉは、これを３２（２の５乗）又は１６進数の０ｘ２０に対応する左から３番目のビットを意味するものとして解釈し、それは生の値としてリターンされる（スペース文字）。しかしながら、Ｒｉｃｏｈ Ａｆｉｃｉｏを含む他のすべてのプリンタは、コロン文字によりセパレートされたＡＳＣＩＩ数字により表現されるようなＯＣＴＥＴ ＳＴＲＩＮＧの値をリターンし（ＯＣＴＥＴ ＳＴＲＩＮＧがいくつかの文書において示される）、すなわち、ゼロを示すのにヌルの代わりに４９（ＡＳＣＩＩの“０”）をリターンする。また、Ｓａｍｓｕｎｇのエンジニアは、自らの規格の解釈において重要な相違を有しているようであり、左の代わりに右からビットをカウントしているようである。すなわち、ビット＃０がビット＃２を４（２の２乗）に対応させる最下位ビットであり、低トナーは“０４”として報告される。
【００２４】
さらなる状況の複雑化は、複数のプリンタ状態が可能であるという事実であり、ＳＮＭＰレスポンスの異なる組み合わせは、関係するプリンタモデルに応じて同じプリンタ状態を示すものであってもよいし、そうでなくてもよい。１つのアプローチは、すべてのプリンタモデルについてＳＮＭＰレスポンスのデータベースを構築することである。対象となるデバイスがネットワーク上において特定され、それのモデル名が決定されると、対象となるデバイスの予想されるＳＮＭＰレスポンスが、データベースのモデル名を検索することによって決定できる。しかしながら、このアプローチは、利用可能なすべてのプリンタモデルを表す極めて大きなデータベースの構築及び継続的な更新を必要とする。すべての既知のベンダからのすべての既知のプリンタの信頼でき、一貫したデータセットを維持するタスクは、ベンダの協力なしには、開発チームに対して大きな負担となりうる。
【００２５】
テーブル２は、各種状態にある単一のデバイスのデバイスレスポンスの具体例を示す。テーブル２は、Ａｐｐｅｎｄｉｘ Ａに含まれる。図示されるように、デバイスは、異なる状態にあるとき、異なってクエリに応答する。従って、クエリの一部又はすべてに対するレスポンスに基づきデバイスの状態を決定することができる。
【００２６】
テーブル２に参照されるデバイスのケースでさえ、ｈｒＰｒｉｎｔｅｒＤｅｔｅｃｔｅｄＥｒｒｏｒＳｔａｔｅがどのように報告されるかについていくつかの変形がある。カバーがオープンされているとき、生のバイトである０ｘｏＢがリターンされ、ＡＳＣＩＩの“１１”であり、８＋２＋１に等しい。ＭＩＢ規格によると、これは、ｃｏｖｅｒＯｐｅｎ（８）、ｏｆｆｌｉｎｅ（２）及びｓｅｒｖｉｃｅ ｒｅｑｕｅｓｔｅｄ（１）を示す。しかしながら、紙詰まりなどの他の状態に応答して（プリンタが落ち着き、一貫して同じ値をリターンした数秒後）、ストリング“０７”がリターンされ、それはＡＳＣＩＩバイトの４８及び５５を含む。ＡＳＣＩＩ数字として解釈された場合、“０７”は数字の７を示し、それはｊａｍｍｅｄ（４）、ｏｆｆｌｉｎｅ（２）及びｓｅｒｖｉｃｅ ｒｅｑｕｓｔｅｄ（１）に対応する。従って、プリンタは、生のバイトとしてｈｒＰｒｉｎｔｅｒＤｅｔｅｃｔｅｄＥｒｒｏｒＳｔａｔｅとリターンするときもあり、ＡＳＣＩＩ数字の文字列としてリターンするときもある。
【００２７】
ネットワーク内のデバイスのデバイス状態を取得する複雑さのため、カスタムデバイスマネージメントソフトウェアに対する更新は、極めて時間と費用のかかるものとなる可能性があり、ソフトウェアの頻繁な更新は、セキュリティリスクをもたらし、予期せぬソフトウェアバグのリスクを高める。コンパイルされたソフトウェアがパッチされると、新たなバイナリの配布がクライアントにされる。これらのクライアントは、ソフトウェアをインストールする前にウィルス感染や他のセキュリティ問題のためにこの新たなバイナリ配布をチェックする必要がある。
【００２８】
一実施例では、カスタムデバイスマネージメントソフトウェアを更新する代わりに、サイトに固有の状態決定ツリーが、ネットワーク内のデバイスの状態を決定するため構成される。一実施例では、汎用的なデバイスマネージメントソフトウェアが、何れかのデバイスインタラクションツリーを利用するため構成され、デバイスマネージメントソフトウェアは、ツリーの変更による更新を要求しない。
【００２９】
一実施例では、デバイスインタラクションツリーは、ネットワーク内にあるすべてのプリンタタイプのブランチを含む。ツリー構造は、デバイスマネージメントソフトウェアを修正することなく容易に置換及び更新されてもよい。従って、ツリー構造は、維持するのにより効率的であり、ネットワーク上のモニタ対象のプリンタセットと共に拡大するようにしてもよい。ツリーは、一般的なテーブルより容易に特有なデバイス動作を処理することが可能である。例えば、ｈｒＰｒｉｎｔｅｒＤｅｔｅｃｔｅｄＥｒｒｏｒＳｔａｔｅの異なる解釈のため、ブランチがツリーに追加されてもよい。一実施例では、ツリーは、プリンタが複数の状態の何れにあるか決定するため、複数のプリンタタイプの複数のＳＮＭＰオブジェクトを抽出するためのクエリを格納する。
【００３０】
状態決定ツリーのノードは、デバイスに対して実行されるクエリを規定する。一実施例では、ツリーは、デバイスの状態を決定するのに十分な情報を有する前に、デバイスに送信される平均的なクエリ数を最小化するよう構成される。一例では、ツリーの高さを最小化するため、又はルートノードと各リーフノードとの間の平均ノード数を最小化するためのツリー最適化技術が利用される。クエリはデバイスからのレスポンスをトリガーし、レスポンスに基づき、状態決定ツリーがリーフノードに向かって移動される。リーフノードは、デバイスの状態を特定する。
［テスト及びアサインメント］
デバイスに対して送信されるクエリを規定することに加えて、状態決定ツリーはまた、１以上の値に対してデバイスからのレスポンスを評価するテストを規定する。一実施例では、デバイスマネージメントアプリケーションは、デバイスに送信されるクエリを決定するため、状態決定ツリーのノードにアクセスする。クエリはデバイスに送信され、レスポンスがデバイスから受信される。レスポンスは、デバイスの状態を規定するリーフノードに向かうツリーの移動において次のノードを決定するため、１以上の値に対して処理及びテストされてもよい。ノードは、処理されたレスポンスに適用されるテストを規定する。例えば、規定されたテストは、レスポンスがある文字列を有するか否かのテストであってもよい。
【００３１】
テスト前、レスポンスはアサインメント段階において処理されてもよい。開示される技術は何れかのタイプのアサインメントに限定されるものでない。一実施例では、何れのアサインメントも必要とされない。図３において、ＳｔｒｉｐＰｒｅｆｉｘ、ＳｔｒｉｐＰｒｅｆｉｘＳｔａｒｔｓＷｉｔｈ、ＳｔｒｉｐＳｕｆｆｉｘ、ＳｔｒｉｐＳｕｆｆｉｘＳｔａｒｔｓＷｉｔｈ、Ｐｒｅｐｅｎｄ、Ａｐｐｅｎｄなどのアサインメントの具体例が提供される。他のタイプのアサインメントは、これらのアサインメント例に加えて又は代わりに利用されてもよい。アサインメントは、処理済みレスポンスを生成するため、レスポンス又は他の格納されているデータに対して実行されてもよい。
【００３２】
処理済みレスポンスが、１以上の値に対してテストされる。開示される技術は、何れか特定のタイプのテストに限定されるものでない。テストは、リターンされるパラメータ名やリターンされるパラメータの値など、テストされるアイテムを規定するものであってもよい。テストはまた、処理済みレスポンスをテストするため実行される処理又は比較を規定するものであってもよい。処理の具体例として、ＩｓＮｕｌｌ、Ｅｑｕａｌｓ、Ｃｏｎｔａｉｎｓ、ＧｒｅａｔｅｒＴｈａｎなどがあげられ、図３に提供される。ＩｓＮｕｌｌ処理は、Ｎｕｌｌという値と等しいという演算との双方を規定する点で特有なものである。ある具体例では、処理済みレスポンスは、処理“Ｅｑｕａｌｓ”と“Ｏｔｈｅｒ”の値とを用いてテストされる。その後、レスポンスが“Ｏｔｈｅｒ”であるとき、テストの結果は“ｔｒｕｅ”である。そうでない場合、テストの結果は“ｆａｌｓｅ”である。他のタイプのテストが、テスト例に加えて又は代わりに利用されてもよい。
【００３３】
一実施例では、アサインメントがテスト段階の結果として適用される。例えば、状態変数は、当該状態がアイドルであることを結論付けるテストの結果として“ｉｄｌｅ”に割り当てられてもよい。アサインメントはまた、状態決定ツリーの以降のノードによる利用のため情報を処理及び格納するのに利用されてもよい。
【００３４】
一実施例では、状態決定ツリーの中間ノードは、２つのチャイルドノードを有する。中間ノードは、デバイスに送信するクエリ、クエリの結果に適用されるアサインメント、及び処理済みの結果に適用される真偽テストを規定する。テストの結果が真である場合、デバイスマネージメントアプリケーションは、真のブランチを下って２つのチャイルドノードの１つに状態決定ツリーを移動する。テストの結果が偽である場合、デバイスマネージメントアプリケーションは、偽のブランチを下って２つのチャイルドノードの他方に状態決定ツリーを移動する。他の実施例では、ノードは他の個数のチャイルドを有してもよく、テストは単なる真偽テスト以外のものであってもよい。
【００３５】
他の実施例では、中間ノードは３つのチャイルドノードを有し、ある値の範囲の２つの値に対してテストが実行される。処理済みレスポンスが第１の値以下である場合、状態決定ツリーは３つのチャイルドノードの第１ノードに移動される。処理済みレスポンスが２つの値の間にある場合、状態決定ツリーは、３つのチャイルドノードの第２ノードに移動される。処理済みレスポンスが第２の値以上である場合、状態決定ツリーは、３つのチャイルドノードの第３ノードに移動される。さらなる他の実施例では、３つのチャイルドノードによる中間ノードは、一方が他方のチャイルドである２つのバイナリ中間ノードとしてモデル化することが可能である。
【００３６】
さらなる他の実施例では、２以上の他の値に対してテストが実行される。例えば、テストは、レスポンスが“ｉｄｌｅ”、“ｒｕｎｎｉｎｇ”又は“ｏｔｈｅｒ”であるか決定可能である。テストの結果として、他のブランチがツリーにおいて移動される。一実施例では、状態決定ツリーのいくつかのノードは、テスト又はサブテストを規定し、クエリを規定しない。クエリがデバイスに送信されると、クエリに対するレスポンスがツリーの異なる複数のレベルにおいて異なる複数の方法によりテストされてもよい。
［デバイスクラス］
各種実施例では、デバイスは、各デバイスをクエリに対して同様に応答させるメーカー、年、機能又は他の何れかのファクタに基づきクラスに分類されてもよい。各クラスは、クラス内のデバイスの状態を決定するため別々の状態決定ツリーを有するようにしてもよい。一実施例では、クラス決定ツリーは、デバイスが属するクラスを決定する。デバイスのクラスがクラス決定ツリーにより決定されると、当該クラスの状態決定ツリーが、デバイスの状態を決定するのに利用されてもよい。
【００３７】
テーブル４３．１８．１は、デバイスが同一状態にあるときに同じクエリに対して同じように応答するデバイスを含むよう規定されるデバイスのクラスを示す。テーブル４３．１８．１は、Ａｐｐｅｎｄｉｘ Ａに提供される。
【００３８】
図示されるように、クラスＡ，Ｂ，Ｃ，Ｄ，Ｆ，Ｇの各デバイスは、トナーが低レベルであるとき（Ｌｏｗ：Ｔｏｎｅｒ）、同じＳＮＭＰクエリに対して同じように応答する。また図示されるように、クラスＥのデバイスは、ブラックトナーが低く、シアントナーが低く、マゼンタトナーが低く、イエロートナーが低いとき、同じＳＮＭＰクエリに対して同じように応答する。個別のデバイス又はデバイスのクラスがサンプルクエリに対してどのように応答するかに関する情報が、図示されるようなテーブル又は他の何れかの機構により格納されてもよい。一実施例では、デバイスインタラクションツリーが、テーブル２などのテーブルに格納される情報に基づき構成される。
【００３９】
一実施例では、クラスＡ，Ｂ，Ｃ，Ｄ，Ｆ，Ｇの何れかのデバイスが、ｗａｒｎｉｎｇ（３）によりｈｒＤｅｖｉｃｅＳｔａｔｕｓクエリと、２０ｈによりｈｒＰｒｉｎｔｅｒＤｅｔｅｃｔｅｄＥｒｒｏｒＳｔａｔｅクエリとに応答するとき、“Ｌｏｗ：Ｔｏｎｅｒ”の状態を有すると決定されてもよい。他の実施例では、ｍａｒｋｅｒＴｏｎｅｒＡｌｍｏｓｔＥｍｐｔｙ（１１０４）のレスポンスによる追加的なｐｒｔＡｌｅｒｔＣｏｄｅクエリが、デバイスの状態を決定するのに利用される。他のデバイス状態を有する他のデバイスについて、異なる個数のクエリがデバイス状態を決定するため実行されてもよい。
【００４０】
図１Ａの例では、デバイスモニタシステム１００は、３つのクラスＡ，Ｂ，Ｃに属する５つのデバイスとやりとりする。各クラスの状態決定ツリーは、クラス内のデバイスを分類するのに利用されるクエリとテストとを有する。状態決定ツリー１０２は、個々のツリーに分割されるか、又は１つのツリーとして合成されてもよい。一実施例では、クラス決定ツリーとクラスＡ，Ｂ，Ｃの状態決定ツリーとは、一緒になってネットワーク１０８内の何れかのデバイスの状態決定ツリーを構成する。
【００４１】
図１Ｂの例では、既知のクラスＣの新たなデバイスがネットワークに追加される。既知のクラスＣの状態決定ツリーは、当該デバイスを分類するための機能をすでに有している。従って、状態決定ツリー１０２は、本例では更新されない。ファンクション“ＥｘｅｃｕｔｅＴｒｅｅ”は、既知のクラスＣの既存の状態決定ツリーにより新たなデバイスに関する情報を取得するのに利用可能である。
【００４２】
図１Ｃの例では、未知のクラスＤの新たなデバイスがネットワークに追加される。デバイスモニタシステム１００は、既存の状態決定ツリー１０２により新たなデバイスがサポートされていないことを検出する。これに応答して、デバイスモニタシステム１００は、ファンクション“ＵｐｄａｔｅＴｒｅｅ”を用いて状態決定ツリー１０２を更新する。例えば、デバイスモニタシステム１００は、図１０Ａに示されるように、サーバから未知のクラスのためのツリー又は他の情報をダウンロードしてもよい。デバイスモニタシステムが未知のクラスＤの他の情報を受信する場合、他の情報は、ファンクションライブラリ１０６のＣｏｎｓｔｒｕｃｔＴｒｅｅファンクションを用いてクラスＤのツリーを構成するのに利用されてもよい。
【００４３】
図５は、デバイスの状態を決定するためデバイスマネージメントアプリケーションにより利用可能な複数のツリーの具体例を示す。第１ツリー５００は、デバイスを複数のデバイスクラスの１つに分類する。第１ツリー５００のリーフノードは、デバイスクラスの識別子を規定する。この識別子は、第２ツリー５０２〜５０６の１つを選択するのに利用される。第２ツリー５０２〜５０６のそれぞれは、１以上のデバイスクラスのグループに属するデバイスに送信するクエリ及びテストのセットを規定する。第２ツリー５０２〜５０６のそれぞれは、第２ツリーによりカバーされるクラスのグループのデバイスのデバイス状態を規定するリーフノードを有する。図５に図示されない実施例では、第１ツリーと第２ツリーとは、１つのツリーに合成される。
【００４４】
一実施例では、デバイスのベンダの身元を決定するツリーは、デバイスの他の状態情報を決定するより大きなツリーの一部である。例えば、ベンダの身元は、デバイスが属するクラスの決定の一部であってもよい。
【００４５】
図６は、デバイスのベンダを決定するためのツリーの実現形態を示す。デバイスマネージメントアプリケーションは、デバイスのｖｅｎｄｏｒＩＤのリクエストを受信する。ノード６００は、デバイスのアドレスがＮＵＬＬであるかテストする。ＮＵＬＬである場合、ｖｅｎｄｏｒＩＤは決定されず、ツリーの移動はノード６０４において終了する。ＮＵＬＬでない場合、ノード６０２は、ｖｅｎｄｏｒＩＤパラメータがＮＵＬＬであるかテストする。ｖｅｎｄｏｒＩＤパラメータがＮＵＬＬである場合、ｖｅｎｄｏｒＩＤパラメータは決定されず、ツリーの移動はノード６０８において終了する。ｖｅｎｄｏｒＩＤパラメータがＮＵＬＬでない場合、ノード６０６は、ｖｅｎｄｏｒＩＤパラメータの値を決定する。各種実施例では、複数のパラメータが、ベンダの身元を決定するためチェックされる必要があってもよい。例えば、いくつかのプリンタは“ｖｅｎｄｏｒＩＤ”などのベンダの身元を格納せず、他のパラメータがこれらのデバイスから抽出される必要がある可能性がある。
【００４６】
図７Ａは、シングルステップデバイス分類ツリーを示す。ノード７００Ａは、特定のデバイスクラスをテストする。例えば、ノード７００Ａは、１以上のクエリと１以上のテストとを有してもよい。デバイスがクラスにある場合、ツリーの移動はノード７０４Ａに続く。そうでない場合、移動は７０２Ａに続く。図７Ｂは、第２デバイスクラスをサポートするため更新されるデバイス分類ツリーを示す。図示されるように、ノード７０２Ｂは、第２デバイスクラスのテストを含む。デバイスが何れのクラスのメンバーでもない場合、移動はノード７０６Ｂに続き、デバイスが第２デバイスクラスのメンバーであるとき、移動はノード７０８Ｂに続く。
［デバイスインタラクションツリーの生成、修正及び置換］
一実施例では、デバイスのクラスに対するデバイスインタラクションツリーは、当該デバイスのクラスを製造したメーカーにより生成される。デバイスインタラクションツリーは、クライアントに配布されてもよい。例えば、異なるバージョンの状態ツリーが、ウェブサーバ上で利用可能とされてもよい。クライアントは、前のバージョンのツリーを新たなバージョンと置換し、又は異なるタイプのデバイスによる利用のために双方のバージョンを格納するようにしてもよい。
【００４７】
他の実施例では、デバイスマネージメントアプリケーションは、デバイス状態、クエリ及びレスポンスとの間の格納されている関連付けに基づき状態決定ツリーを生成する。モニタ対象の選択された各デバイスの選択された各状態について、デバイスマネージメントアプリケーションは、デバイス状態を特定する一意的なパラメータの１以上のセットを決定する。複数のデバイスのデバイス状態のパラメータセットは合成されてもよく、最も頻繁に利用されるセットが、状態決定ツリーの上位レベルの基礎を形成してもよい。このようにして、状態を決定するため最も頻繁にクエリされる情報は、状態決定ツリーの移動中の早期の段階でクエリされてもよい。１つ又は少数の特定のデバイスに対してのみクエリされる情報は、状態決定ツリーの移動中の以降の段階でクエリされるようにしてもよい。ある実施例では、デバイスマネージメントアプリケーションは、あるネットワーク上のプリンタセットの関連するクエリとレスポンス情報とを含むクエリレスポンスディクショナリのコレクションを用いて、最小の又は最適化された状態決定ツリーを自動構成する。
【００４８】
図２は、状態決定ツリーのセットの一例となるクラス図である。図示されるように、状態決定ツリーセット２００は、状態決定ツリー２０２のアレイを含む。各状態決定ツリー２０２は、１以上のクエリ２０８、アサインメント及びテスト２１０を含む１以上の状態決定ユニット２０４を有する。この例では、各テストは、真のチャイルドノード又は偽のチャイルドノードにナビゲートするブールタイプ２０６の結果をもたらす。図示されるように、テストは、主部と、主部自体の値又は主部に一致する名前を有する変数の値をテストするか決定する主部演算子２１４とを含む。さらに図示されるように、テストは、述部と、主部のテスト方法を規定する述部演算子２１６とを含む。この例では、テスト２１０は、主部が述部を含む、述部に等しい又は述部より大きいか決定することが可能である。一例となるクエリ２０８は文字列によって応答され、一例となるテスト２１０は文字列に対して処理する。他の実現形態によると、クエリレスポンスは何れかのフォーマットにより値を規定し、テストは何れかのフォーマットの値に対して実行されてもよい。状態決定ツリーの結果２１８は、デバイスの状態のテキスト記述を規定するノードを特定する。
【００４９】
図３は、デバイス状態を決定するためのデータ構造の図である。図示されるように、ツリー３００のセットは、１以上の個々のツリー３０２を有する。各ツリー３０２はノード３０４又はツリーユニットを有し、各ノードは１以上のクエリ３１２、アサインメント３１４及びテスト３１６を有する。一実施例では、少なくとも１つのクエリと少なくとも１つのテストとを含むツリーユニットのコレクションは、単一のノードとして一緒にグループ化される。他の実施例では、すべての非リーフノードは、少なくとも１つのクエリと少なくとも１つのテストとを含む。
【００５０】
クエリは、１以上の規定されたプロトコルを用いてモニタされているデバイスに送信される。アサインメントは、クエリのレスポンスにおいて規定されたものなど、ＳｔｒｉｐＰｒｅｆｉｘ、ＳｔｒｉｐＰｒｅｆｉｘＳｔａｒｔｓＷｉｔｈ、ＳｔｒｉｐＳｕｆｆｉｘ、ＳｔｒｉｐＳｕｆｆｉｘＳｔａｒｔｓＷｉｔｈ、Ｐｒｅｐｅｎｄ及び／又はＡｐｐｅｎｄなどの値に対する演算を実行するための１以上の値修飾子３１８を含む。１以上のアサインメント３１４により処理されたレスポンスは、テスト３１６を受ける。図示された例では、テスト３１６は、主部自体がテストされている値であるか、又は主部がテストされている値を規定するパラメータの名前であるかなど、主部演算３２０を規定する。例えば、アサインメントは、レスポンスが値を規定するとき、キー値ペアの値に適用されてもよい。アサインメントはまた、他のノードによる以降の抽出のため、デバイスマネージメントアプリケーションによりキー値ペアを格納するようにしてもよい。他の例では、アサインメントは、状態決定ツリーの移動中に以前に規定された“ＣｙａｎＰａｇｅＣｏｕｎｔ”などのキーに基づき格納されている値に適用されてもよい。この場合、状態決定ツリーを移動するデバイスマネージメントアプリケーションは、“ＣｙａｎＰａｇｅＣｏｕｎｔ”と呼ばれるパラメータの格納されている値を検索する。一実施例では、アサインメントが状態決定ツリーのノード間でわたされる。他の実施例では、アサインメントはグローバルに定義される。
【００５１】
テスト３１６はまた、主部に適用する１以上の述部の値と１以上の述部演算３２２とを有する。一実施例では、述部演算は、主部と述部とを比較するための比較演算である。例えば、テストは、クエリに対する処理済みレスポンスの値が“ｉｄｌｅ”に等しいか、又は値が０２ｈより大きいかを決定するものであってもよい。他の述部演算の具体例として、ＩｓＮｕｌｌ、Ｃｏｎｔａｉｎｓ及びｓｔａｒｔｓＷｉｔｈがあげられる。レスポンスはまた、具体例に示されない他の述部演算を用いて処理されてもよい。
【００５２】
テスト３１６の結果に基づき、デバイスマネージメントアプリケーションは、ノード３０４の真のチャイルドノード又は偽のチャイルドノードへのポインタを用いてツリー３０２を移動する。一実施例では、チャイルドノードは、デバイスの状態を規定するリーフノードである。他の実施例では、チャイルドノードは、デバイス状態の決定前に行われる１以上の他のクエリと１以上の他のテストとを規定する。状態決定ツリー３０２の移動は、デバイスの状態を規定するリターン３１０をもたらす。
【００５３】
図４は、３レベルの一例となる状態決定ツリーの構成を示す。この例では、ルート４００とユニット４０２とは、ツリーの第１レベルを規定する。ユニット４０２は、０以上のクエリ、０以上のアサインメント及び１以上のテストを有する。この例では、テストは、真偽テストである。テスト結果が偽である場合、ツリーの移動はユニット４０２からユニット４０４に続く。テスト結果が真である場合、ツリーの移動はユニット４０２からユニット４０６に続く。ユニット４０４と４０６はそれぞれ、０以上のクエリ、０以上のアサインメント及び１以上のテストを規定する。状態決定ツリーの移動は、リーフノード４０８〜４１４の１つへのナビゲートを生じさせる。結果として得られたリーフノードは、デバイスの状態を規定する。
【００５４】
Ａｐｐｅｎｄｉｘ Ｂは、ＤＩＴ．ＸＭＬにより規定されるより複雑な状態決定ツリーの一例を示す。状態決定ツリーのノード（＜ＱＮｏｄｅ＞）は、クエリ（＜Ｑｕｅｒｉｅｓ＞）、アサインメント（＜Ａｓｓｉｇｎｍｅｎｔｓ＞）及びテスト（＜Ｔｅｓｔ＞）を規定する。クエリノードに移動すると、デバイスマネージメントアプリケーションは、クエリノードに関連付けされた１以上のクエリを実行する。アサインメントノードに移動すると、デバイスマネージメントアプリケーションは、アサインメントノードに関連付けされた何れかのアサインメントを適用する。テストノードに移動すると、デバイスマネージメントアプリケーションは、テストノードに関連付けされた何れかのテストを適用する。状態決定ツリーは、ルートノードから、クエリ及びテストを規定する中間ノードを介しデバイス状態を規定するリーフノードまで移動される。
【００５５】
一実施例では、デバイスマネージメントアプリケーションは、中央サーバからクエリ及びレスポンスに関連する状態に関する情報を受信する。例えば、当該情報は、サーバからデバイスマネージメントアプリケーションに通信されるテーブルに格納されてもよい。
【００５６】
図８Ａは、状態決定ツリーの構成及び更新に利用されるクエリレスポンスディクショナリの全体構成を示す。クエリレスポンスディクショナリは、デバイスへのクエリとデバイスからのレスポンスとに関連するデバイスの状態に関する情報を格納する。レスポンスは、デバイスが規定された状態にあって、規定されたクエリによりクエリされる場合にデバイスが実行するであろう実際のレスポンスである。クエリレスポンスディクショナリは、デバイスが構成又は修正中にアクセス可能であることが不要となるように、ツリーの構成又は修正中にデバイスをエミュレートするのに利用されてもよい。一実施例では、クエリレスポンスディクショナリは、デバイスのモデルに関する情報を必要としない。状態がクエリ及びレスポンスに関連付けされる限り、関連付けされた情報は状態決定ツリーを構成するのに利用されてもよい。
【００５７】
図８Ｂは、ＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）のための３つのクエリ、ＰＪＬ（Ｐｒｉｎｔｅｒ Ｊｏｂ Ｌａｎｇｕａｇｅ）のための２つのクエリ、ＰｏｓｔＳｃｒｉｐｔのための１つのクエリ、及びＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）のための１つのクエリを有する一例となるクエリレスポンスディクショナリを示す。一例では、ＨＴＴＰクエリは、レスポンスを導くためにデバイスによって、提供されるウェブサーバに対して発行される。
【００５８】
図８Ｃは、クエリのうちの４つがデバイスクラスへのデバイスの分類に利用可能な“ＩＤクエリ”又はクエリである１１個のクエリを有する一例となるクエリレスポンスディクショナリを示す。デバイスの分類は、選択されたデバイスのクラスに特化したデバイスインタラクションツリーの選択を可能にするものであってもよい。
【００５９】
他の実施例では、デバイスマネージメントアプリケーションは、デバイス上で観察された状態に関する情報をユーザから受信する。例えば、ユーザは、デバイスに関する識別情報を、デバイスについて観察された状態と共にユーザインタフェースを介し送信してもよい。これに応答して、デバイスマネージメントアプリケーションは、１以上のクエリによってデバイスに照会し、１以上のレスポンスを受信する。デバイスマネージメントアプリケーションは、状態情報に関連付けてクエリレスポンスペアを格納する。
【００６０】
状態決定ツリーを自動生成するための開示される技術は、ツリーのノードを決定するため、関連付けされた状態、クエリ及びレスポンスに関する既知の情報を組み合わせるための特定の技術に限定されるものでない。２つの可能な状態を備えた３デバイスシステムのシンプルな例では、パラメータＸが１であって、パラメータＹが１０であるとき、第１デバイスが状態Ａにあり、パラメータＸが１であって、パラメータＹが２０であるとき、第２デバイスが状態Ａにあり、パラメータＸが２であって、パラメータＹが１０であるとき、第３デバイスが状態Ａにある。パラメータＸが２であって、パラメータＹが２０であるとき、すべてのデバイスが状態Ｂにあると仮定する。一例となる状態決定ツリーは、まずデバイスにＸを照会し、Ｘが１であるかテストし、その後にデバイスにＹを照会し、Ｙが１０であるかテストする。これら２つのクエリとテストとの結果は、何れのデバイスがテストされているに関係なく、デバイスが状態Ａ又はＢにあるか決定するのに利用可能である。
【００６１】
さらに、類似情報の大文字、プリフィックス、サフィックス、値フォーマット及び他の表現の相違がツリーの同じノードにより表現されるように、クエリ及びパラメータのセットが一般化されてもよい。例えば、１つのノードは、パラメータの処理値が“ｉｄｌｅ”であるか、実際に受信したパラメータが“ｉｄｌｅ”であったか、“Ｉｄｌｅ”又は“ｉｄｌｅ”にマップされる他の文字列を決定するものであってもよい。
【００６２】
開示される技術によると、状態決定ツリーは、有用なものにするため、完全に最適化される必要はなく、又はまったく最適化される必要もない。例えば、１つのツリーは、２つのツリーが開示された技術を含むものであったとしても、他のツリーと同じデバイスの同一状態を決定するのに平均してより多くのクエリ及び／又はテストを必要とするものであってもよい。一実施例では、デバイスマネージメントアプリケーションは、平均的により少数のクエリ及び／又はテストによって、又はより小さなツリーを用いて、同じデバイスの同一状態を管理する他のバージョンのツリーをサーバ上で検出する。これに応答して、デバイスマネージメントアプリケーションは、他のバージョンのツリーをダウンロードし、前のバージョンのツリーを置換してもよい。他のバージョンは、デバイスの状態を決定するために他のツリーがまた正確であると判断されるまで、アクティブなツリーとして一時的に指定されてもよい。
【００６３】
他の実施例では、デバイスマネージメントアプリケーションのユーザは、他のバージョンのツリーを求めてもよい。ユーザは、他のバージョンのツリーをダウンロードし、ソフトウェアをコンパイル及びインストールし、又はデバイスマネージメントアプリケーションを実行するマシーンへの登録を更新する権限を有することなく、前のバージョンのツリーを置換してもよい。
【００６４】
一実施例では、デバイスマネージメントアプリケーションは、状態決定ツリーがネットワーク内のデバイスの状態を提供できないことを検出したことに応答して、状態決定ツリーを更新する。例えば、デバイスマネージメントアプリケーションは、サポートされていないデバイスがネットワークに追加されたこと、又は要求されたタイプの状態情報が状態決定ツリーにすでに表現されるデバイスについてサポートされていないことを検出するようにしてもよい。更新された状態決定ツリーは、デバイスマネージメントアプリケーションのコードを修正することなく、以前には未サポートのデバイスをサポートする。
【００６５】
図９Ａ及び９Ｂは、状態決定ツリーへの更新をトリガするための他の一例となる技術であり、１つは自動的なものであり、１つは手動によるものを示す。図９Ａの一例となる自動更新技術に示されるように、ツリー９００〜９０４の少なくとも１つの実行９０６は、未知のクラスの新たなデバイス９１０Ａの状態を提供することができない。この失敗を検出したことに応答して、デバイスマネージメントアプリケーションは、状態決定ツリーへの更新９０８Ａを要求する。図９Ｂにおいて、人間によるオペレータ９１２が、未知のクラスの新たなデバイス９１０Ａの存在を検出する。新たなデバイス９１０Ａの存在を検出することに基づき、オペレータは状態決定ツリーへの更新を要求する。
【００６６】
図１０Ａ及び１０Ｂは、状態決定ツリーへの更新を取得するための他の一例となる技術を示す。図１０Ａにおいて、デバイスモニタシステム１０００Ａは、新たなデバイスをサポートする更新を取得するため、デバイス記述１００２を中央サーバ１００４に送信する。図示されるように、中央サーバ１００４は、クエリレスポンスディクショナリ１００６などのクエリ及びレスポンスに関連する状態に関する情報を提供することによって、リクエストに応答する。図示しない実施例では、中央サーバは、状態決定ツリーをデバイスモニタシステム１０００Ａに直接提供する。中央サーバから新たに提供された情報は、デバイスモニタシステム１０００Ａが以前にサポートされていたクラスのデバイスと新たなデバイスとを区別することを可能にする。
【００６７】
図１０Ｂの例では、人間のオペレータ１０１０に、状態情報１００８を提供するためのインタフェースが示される。人間のオペレータ１０１０は、状態情報１０１２をデバイスモニタシステム１０００Ｂに提供するため、インタフェースとやりとりする。デバイスモニタシステムは、デバイスにクエリを送信し、送信されたクエリとデバイスから受信したレスポンスとに関連付けて状態を格納する。他の実施例では、ユーザはまた、ユーザに既知の関連付けされたクエリ及びレスポンス情報を入力する。
【００６８】
図１１は、状態決定ツリーの処理に関する一例となるステップを示すフローチャートである。未サポートのデバイスのために失敗すると、失敗前のノードの身元が、以前にはサポートされていないデバイスをサポートする新たな状態決定データによって状態決定ツリーを更新するのに利用可能である。図１１に示されるように、クライアントは、ステップ１１０２において、デバイスモニタから新たなデバイスに関するデータをリクエストする。ステップ１１０４において、デバイスモニタは、状態決定ツリーを処理し、リクエストされたデータを取得するため、ツリー移動ファンクションを呼び出す。判定ステップ１１０６において、実行が成功したか判断される。実行が成功しなかった場合、ステップ１１０８において、失敗したノードの身元がクライアントにリターンされる。これに応答して、ステップ１１１０において、クライアントは、ツリーに追加すべきノードをリターンする。デバイスモニタは、ステップ１１１２において、ツリーの失敗したノードの前に新たな状態決定ノードを追加し、ステップ１１１４において、配置された新たなノードによりツリーを再実行する。
【００６９】
ステップ１１０６において判定されるように、実行が成功した場合、ステップ１１１６において、リクエストされたデータはクライアントにリターンされる。クライアントは、ステップ１１１８において、リターンされたデータを検証する。データが正確でない場合、失敗したノードの身元がクライアントにリターンされ、処理はステップ１１１０に進む。そうでない場合、データはツリーから良好に抽出され、クライアントにより検証され、当該処理はステップ１１２２において終了する。
【００７０】
図１２は、一時的更新機能を備えた一例となるデバイスクエリ処理を示す。ステップ１２０２において、クライアントは、デバイスモニタ１２０２から新たなデバイスに関するデータをリクエストする。デバイスモニタは、ステップ１２０４において、リクエストされたデータを取得するため、Ｔｒｅｅを実行する。ステップ１２０６において、実行が成功したか判断される。実行が成功しなかった場合、ステップ１２０８〜１２１０に反映されるように、失敗したノードの身元がクライアントにリターンされ、クライアントはツリーに追加すべきノードをリターンする。デバイスモニタは、ステップ１２１２において、前の実行から残っている一時的ノードを破棄し、ステップ１２１４において、ツリーの失敗したノードの前に新たなノードを一時的に追加する。ステップ１２１６において、現在配置された一時的なノードによって、ツリーが再実行される。
【００７１】
ステップ１２０６において実行が成功した場合、ステップ１２１８において、リクエストされたデータはクライアントにリターンされる。ステップ１２２０において、クライアントは、リターンされたデータを検証する。データが検証され、ステップ１２２４において判断されるように、ツリーに一時的ノードがあった場合、ステップ１２２６において、デバイスモニタは、一時的ノードを永続的なものにする。
【００７２】
図１３は、サーバから配布されたクエリレスポンスディクショナリに基づく他の一例となる更新処理を示す。ステップ１３０２において、クライアントは、新たなデバイスのモデルやメーカー名などの識別情報を中央サーバに送信する。ステップ１３０４において、中央サーバは、クエリレスポンスディクショナリ（ＱＲＤ）をクライアントに送り返す。クライアントは、ステップ１３０６において、デバイスモニタのＡｄｄＤｅｖｉｃｅメソッドを実行し、提供されたＱＲＤを用いてデバイスをツリーに追加する。ステップ１３０８において、デバイスモニタは、新たなデバイスのＱＲＤからのデータによって状態決定ツリーを更新する。
［デバイスインタラクションツリーの利用］
一実施例では、デバイスの状態に対するリクエストが、１以上の計算装置とのインタフェースにより受信される。当該リクエストは、デバイスの１以上の属性を特定するものであってもよい。他の実施例では、リクエストは、デバイスが属するワークグループと名前とによってデバイスを特定する。１以上の計算装置上のデバイスインタラクションロジックは、デバイスインタラクションツリーを用いて、ツリーのスタートノードに関連付けされたクエリとテストとを決定するよう構成される。クエリはデバイスに送信され、レスポンスがデバイスから受信される。一実施例では、テスト段階前に、レスポンスは、スタートノードに関連付けされた１以上のアサインメントに従って、デバイスインタラクションロジックによって処理される。他の実施例では、レスポンスは、処理することなく受信されたままテストされる。レスポンスは、ツリーのスタートノードに関連付けされたテストを用いてテストされる。当該テストは、レスポンスを評価するため、１以上の値と１以上の演算とを規定する。一実施例では、１以上のアサインメントは、テストの結果として以降のノードのために値を格納又は準備するため実行されてもよい。テストの結果に基づき、デバイスモニタリングロジックツリーは、リーフノードに向かって移動される。一例では、リーフノードは、デバイスの状態を表す。各種実施例では、スタートノードは、複数のブランとの何れがツリーにおいて移動されるか決定するため、クエリとテストの系列とによるノードの集合によって表されてもよい。
【００７３】
ツリーの次のノードがリーフノードである場合、リーフノードにより規定される状態がデバイスの状態となる。一実施例では、次のノードは、移動における第２ノードである。第２ノードがリーフノードでない場合、第２クエリと第２テストとがツリーの第２ノードから決定される。デバイスは、第２レスポンスを導くため次のクエリにより照会される。第２レスポンスは、ツリーの第２ノードに関連付けされた何れかのアサインメントに従って処理されてもよい。レスポンスは、ツリーの移動における次の又は第３ノードを決定するため、第２テストに対して評価される。一実施例では、第３ノードは、スタートノードと第２ノードと同様にして処理される。他のノードが移動のパス上にあってもよく、デバイスの状態を規定するリーフノードへの移動をもたらす。
【００７４】
状態決定ロジックは、リクエストに応答してデバイスの状態を提供する。例えば、状態決定ロジックは、ユーザインタフェース上でデバイスの状態をリクエストするユーザに、デバイスの状態のテキスト及び／又は画像説明又は表現を表示する。例えば、状態決定ロジックは、アイドル状態に関連付けされたアイコンと共に、“ｉｄｌｅ”を表示するようにしてもよい。
【００７５】
一実施例では、ツリーを移動するためのデバイスインタラクションロジックは、ツリーのコンテンツに関して汎用的なものである。すなわち、デバイスインタラクションロジックは、あるネットワーク上の特定のデバイスについて特別に構成される必要はない。例えば、状態決定ロジックは、あるネットワーク上のデバイスの状態を決定するため特別に構成される必要はない。一実施例では、デバイスインタラクションロジックは、ツリーを移動するため１以上の計算装置により実行される格納されている命令を含む。他の実施例では、デバイスインタラクションロジックは、１以上の計算装置にツリーを移動させる１以上の特殊なハードウェアコンポーネントを用いて構成されてもよい。
【００７６】
Ａｐｐｅｎｄｉｘ Ｂは、ツリーのＤＩＴ．ＸＭＬ．Ｎｏｄｅｓ（＜ＱＮｏｄｅ＞）により規定される一例となる状態決定ツリーがクエリ（＜Ｑｕｅｒｉｅｓ＞）、アサインメント（＜Ａｓｓｉｇｎｍｅｎｔｓ＞）及びテスト（＜Ｔｅｓｔ＞）を規定することを示す。ノードに移動すると、デバイスマネージメントアプリケーションは、ノードに関連付けされた１以上のクエリを実行し、ノードに関連付けされた何れかのアサインメントを適用し、ノードに関連付けされたテストによってクエリへのレスポンスをテストする。
【００７７】
ＤＩＴ．ＸＭＬによる一例では、デバイスマネージメントアプリケーションは、ユーザからデバイス状態に対するリクエストを受信し、“＜Ｑｕｅｒｙ ｐｒｏｔｏｃｏｌ＝”ｓｎｍｐ“ ｍｅｓｓａｇｅ＝”ｐｒｔＡｌｅｒｔＣｏｄｅ“ ｒｅｓｐｏｎｓｅＫｅｙ＝”ＡｌｅｒｔＣｏｄｅ“／＞”によるクエリを規定し、“＜Ｔｅｓｔ ｓｕｂｊｅｃｔ＝”ＡｌｅｒｔＣｏｄｅ“ ｓｕｂｊｅｃｔＯｐ＝”ｖａｌｕｅＯｆ“ ｐｒｅｄｉｃａｔｅ＝”ｓｕｂｕｎｉｔＭｉｓｓｉｎｇ“ ｐｒｅｄｉｃａｔｅＯｐ＝“ｅｑｕａｌｓ”／＞“のテストにより結果をテストするＱＮｏｄｅに状態決定ツリーを移動する。すなわち、デバイスマネージメントアプリケーションは、メッセージ”ｐｒｔＡｌｅｒｔＣｏｄｅ“によってＳＮＭＰクエリをデバイスに送信する。デバイスマネージメントアプリケーションは、”ＡｌｔｅｒＣｏｄｅ“としてデバイスからのレスポンスを保存する。その後、デバイスマネージメントアプリケーションは、ＡｌｅｒｔＣｏｄｅの値が”ｓｕｂｕｎｉｔＭＩｓｓｉｎｇ“に等しいか評価するためテストを利用する。
【００７８】
テストの結果が真である場合、デバイスマネージメントアプリケーションは、他のＱＮｏｄｅのブランチへのデバイスインタラクションツリーの移動を続ける。移動におけるこのポイントにおいて、デバイスマネージメントアプリケーションは、ＰｒｉｎｔｅｒＳｔａｔｕｓが“ｉｄｌｅ”であり、ＤｅｖｉｃｅＳｔａｔｕｓが“ｗａｒｎｉｎｇ”であり、ＡｌｅｒｔＣｏｄｅが“ｓｕｂｕｎｉｔＭｉｓｓｉｎｇ”であると決定した。デバイスマネージメントアプリケーションは、“ｐｒｔＡｌｅｒｔＧｒｏｕｐ”のメッセージによるＳＮＭＰクエリによって再びデバイスに照会する。レスポンスは、“ＡｌｅｒｔＧｒｏｕｐ”として保存される。この結果は、“＜Ｔｅｓｔ ｓｕｂｊｅｃｔ＝”ＡｌｅｒｔＣｏｄｅ“ ｓｕｂｊｅｃｔＯｐ＝”ｖａｌｕｅＯｆ“ ｐｒｅｄｉｃａｔｅ＝”ｉｎｐｕｔ“ ｐｒｅｄｉｃａｔｅＯｐ＝“ｅｑｕａｌｓ”／＞“によりテストされる。すなわち、デバイスマネージメントアプリケーションは、結果の値が”ｉｎｐｕｔ“に等しいか判断する。等しい場合、デバイスマネージメントアプリケーションは、アサインメント”＜Ｓｅｔ ｋｅｙ＝“ＳｔａｔｕｓＮａｍｅ” ｖａｌｕｅ＝“ｅｒｒｏｒ”／＞“及び”＜Ｓｅｔ ｋｅｙ＝“ＥｒｒｏｒＮａｍｅ” ｖａｌｕｅ＝“Ｎｏｉｎｐｕｔｔｒａｙ”／＞“に基づき、デバイスの状態を決定する。従って、デバイスマネージメントアプリケーションは、”Ｅｒｒｏｒ：Ｎｏ Ｉｎｐｕｔ Ｔｒａｙ“によりデバイス状態に対するリクエストに応答する。
【００７９】
図１４は、一例となる状態決定ツリーを移動する一例となる処理を示すフローチャートである。当該処理は、１以上の格納されている状態決定ツリーを用いてネットワーク上のデバイスの状態を取得するデバイスマネージメントアプリケーションにより実行される。デバイスマネージメントアプリケーションは、状態決定ツリーのクエリ、アサインメント及びテスト及びテストにより規定されるルールに従うよう一般に構成されてもよい。図示されないアサインメントステートメントは、デバイスから受信されたレスポンスに基づき、パラメータに値を割り当てるためデバイスインタラクションツリーに含まれる。割り当てられた値は、図示されるような比較ステップにおいて利用される。デバイスマネージメントアプリケーションは、所与のネットワーク又は所与のデバイスインタラクションツリーについて特別に構成される必要はない。当該処理を進めるデバイスインタラクションツリーは、ソフトウェアをインストールしたり、デバイスのレジストリを修正するためのセキュリティ権限を有さないユーザによって、生成、更新及び置換されてもよい。一実施例では、状態決定ツリーなどのデバイスインタラクションツリーは自ら実行するソフトウェアを有さないため、デバイスインタラクションツリーは、それらが保存されるシステムのセキュリティを危険にさらすものでない。
［デバイスコンフィギュレーションツリー］
一実施例では、デバイスインタラクションツリーはデバイスコンフィギュレーションツリーである。デバイスマネージメントアプリケーションなどのデバイスインタラクションロジックは、デバイスを設定するためデバイスコンフィギュレーションツリーを移動するよう構成される。一実施例では、ユーザは、デバイスに関するパラメータを設定するためのリクエストを送信する。デバイスインタラクションロジックは、このリクエストを受信し、デバイスセットの何れかのデバイスに関するパラメータを設定するため、デバイスコンフィギュレーションツリーを選択する。デバイスインタラクションロジックは、ロートノードからクエリ及びテストを規定する中間ノードまでデバイスコンフィギュレーションツリーを移動する。デバイスインタラクションロジックは、デバイスに送信するコンフィギュレーションコマンドを規定するリーフノードに到達するため、クエリの結果に対してテストを適用する。デバイスコンフィギュレーションツリーは、コンフィギュレーションコマンドがデバイスに良好に送信されたか判断するため、１以上のさらなるコマンドを規定してもよい。
【００８０】
例えば、ユーザは、デバイスの名前を変更するようリクエストしてもよい。当該リクエストは、ＩＰアドレスによりデバイスを特定し、またデバイスの新たな名前を規定してもよい。リクエストに基づき、デバイスインタラクションロジックは、デバイスの名前を変更するため、デバイスコンフィギュレーションツリーを選択する。デバイスインタラクションロジックは、デバイスコンフィギュレーションツリーを移動し、１以上のクエリを送信し、クエリの１以上のレスポンスに１以上のテストを適用する。デバイスコンフィギュレーションツリーを移動すると、デバイスインタラクションロジックは、デバイスの名前を変更するためのコマンドを規定するリーフノードに到達する。デバイスインタラクションロジックは、当該コマンドをデバイスに送信する。任意的には、デバイスコンフィギュレーションツリーは、デバイスの名前がコマンドによって良好に変更されたか判断するため、１以上の他のクエリと１以上の他のテストとを規定する。コマンドを送信するか、又はコマンドがデバイスに関するパラメータを良好に変更したことを確認したことに応答して、デバイスインタラクションロジックは、デバイスの名前が変更されたという表示をユーザに示す。
【００８１】
他の各種設定変更が、デバイスコンフィギュレーションツリーを用いてデバイスになされてもよい。例えば、デバイスコンフィギュレーションツリーは、デバイスのタイムアウト値を変更するためのコマンド、又はデバイスがスタートアップするとテストページが印刷されるか指示する設定を変更するためのコマンドを規定してもよい。デバイスコンフィギュレーションツリーを生成及び利用するための技術は、何れか特定タイプの設定変更に限定されず、各種コンフィギュレーションツリーが、デバイスに送信する設定コマンドを決定するのに利用されてもよい。一実施例では、デバイスコンフィギュレーションツリーは、自己実行可能なコードを含まない。また、デバイスインタラクションロジックは、何れかのデバイスのパラメータを変更するため特別に構成されることなく、デバイスコンフィギュレーションツリーを移動するよう汎用的に構成されてもよい。一実施例では、コンフィギュレーションツリーは、異なるタイプのデバイス、異なる機能を備えたデバイス、及び／又は同一の設定変更を実現するため異なる設定コマンドを要求する異なるメーカーからのデバイスを設定するためのクエリ、テスト及び設定コマンドを規定する。
［デバイスアクションツリー］
一実施例では、デバイスインタラクションツリーは、デバイスアクションツリーである。デバイスマネージメントアプリケーションなどのデバイスインタラクションロジックは、デバイスにアクションを実行させるためデバイスアクションツリーを移動するよう構成される。一実施例では、ユーザは、デバイスにアクションを実行させるためのリクエストを送信する。デバイスインタラクションロジックは、当該リクエストを受信し、デバイスセットの何れかのデバイス上でアクションを実行させるためのデバイスアクションツリーを選択する。デバイスインタラクションロジックは、ルートノードからクエリ及びテストを規定する中間ノードまでデバイスアクションツリーを移動する。デバイスインタラクションロジックは、デバイスに送信するアクションコマンドを規定するリーフノードに到達するため、クエリの結果にテストを適用する。デバイスコンフィギュレーションツリーは、アクションコマンドがデバイスによって良好に実行されたか判断するため１以上のさらなるコマンドを規定してもよい。
【００８２】
例えば、ユーザは、指定されたフォーマットに従って文書を印刷するようリクエストしてもよい。当該リクエストは、ＩＰアドレスによりデバイスを特定し、また文書及び所望のフォーマットを指定してもよい。当該リクエストに基づき、デバイスインタラクションロジックは、デバイス上で文書を印刷するためのデバイスアクションツリーを選択する。デバイスインタラクションロジックは、デバイスアクションツリーを移動し、１以上のクエリを送信し、クエリの１以上のレスポンスに１以上のテストを適用する。デバイスアクションツリーを移動すると、デバイスインタラクションロジックは、指定されたフォーマットに従って文書を印刷するためのコマンドを規定するリーフノードに到達する。デバイスインタラクションロジックは、コマンドをデバイスに送信する。任意的には、デバイスコンフィギュレーションツリーは、デバイスが指定されたフォーマットにより文書を印刷するのに成功したか判断するため、１以上の他のクエリと１以上の他のテストとを規定する。アクションコマンドを送信するか、又はアクションコマンドが良好に実行されたことを確認したことに応答して、デバイスインタラクションロジックは、デバイスが指定されたフォーマットにより文書を印刷したという表示をユーザに示す。
【００８３】
他の各種アクションコマンドが、デバイスアクションツリーを利用してデバイスに送信されてもよい。例えば、デバイスアクションツリーは、デバイスにファックス、電子メール又はテキストメッセージを送信させるためのコマンド、又はデバイスにコピーさせ、テストページを印刷させ、又はクリーニング処理を実行させるためのコマンドを規定してもよい。デバイスアクションツリーを生成及び利用するための技術は、何れか特定タイプのアクションに限定されず、各種アクションツリーが、デバイスに送信するアクションコマンを決定するのに利用されてもよい。一実施例では、デバイスアクションツリーは、自己実行可能なコードを含まない。また、デバイスインタラクションロジックは、何れかのデバイス上でアクションを実行させるよう特別に構成されることなく、デバイスアクションツリーを移動するよう汎用的に構成されてもよい。一実施例では、アクションツリーは、異なるタイプのデバイス、異なる機能を備えたデバイス、及び／又は同一のアクションを実行するため異なるアクションコマンドを要求する異なるメーカーからのデバイスによってアクションを実行させるためのクエリ、テスト及び設定コマンドを規定する。
［実現機構］
一実施例によると、開示された技術は１以上の特定用途計算装置により実現される。特定用途計算装置は、当該技術を実行するため配線が組み込まれ、又は当該技術を実行するため永続的にプログラムされた１以上のＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ−Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）又はＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）などのデジタル電子デバイスを有し、又はファームウェア、メモリ、他のストレージ若しくは組み合わせのプログラム命令に従って当該技術を実行するようプログラムされた１以上の汎用ハードウェアプロセッサを有してもよい。このような特定用途計算装置はまた、カスタム配線論理、ＡＳＩＣ又はＦＰＧＡを当該技術を実現するためのカスタムプログラミングと組み合わせるようにしてもよい。特定用途計算装置は、デスクトップコンピュータシステム、ポータブルコンピュータシステム、携帯デバイス、ネットワーキングデバイス又は当該技術を実現するための配線及び／又はプログラム論理を搭載した他の何れかのデバイスであってもよい。
【００８４】
例えば、図１５は、本発明の実施例が実現されるコンピュータシステム１５００を示すブロック図である。コンピュータシステム１５００は、情報を通信するためのバス１５０２又は他の通信機構と、情報を処理するためバス１５０２に接続されたハードウェアプロセッサ１５０４とを有する。ハードウェアプロセッサ１５０４は、例えば、汎用マイクロプロセッサであってもよい。
【００８５】
コンピュータシステム１５００はまた、プロセッサ１５０４により実行される命令及び情報を格納するため、バス１５０２に接続されたＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）や他のダイナミックストレージデバイスなどのメインメモリ１５０６を有する。メインメモリ１５０６はまた、プロセッサ１５０４により実行される命令の実行中に一時的変数や他の中間情報を格納するのに利用されてもよい。このような命令は、プロセッサ１５０４にアクセス可能な非一時的記憶媒体に格納されると、コンピュータシステム１５００を命令に指示される処理を実行するようカスタマイズされた特定用途マシーンに変換する。
【００８６】
コンピュータシステム１５００はさらに、プロセッサ１５０４のための静的情報及び命令を格納するため、バス１５０２に接続されたＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１５０８や他のスタティックストレージデバイスを有する。磁気ディスクや光ディスクなどの記憶装置１５１０が設けられ、情報及び命令を格納するためバス１５０２に接続される。
【００８７】
コンピュータシステム１５００は、コンピュータユーザに情報を表示するため、バス１５０２を介しＣＲＴ（Ｃａｔｈｏｄｅ Ｒａｙ Ｔｕｂｅ）などのディスプレイ１５１２に接続されてもよい。英数字及び他のキーを含む入力装置１５１４が、プロセッサ１５０４に情報及びコマンド選択を通信するため、バス１５０２に接続される。他のタイプのユーザ入力装置は、指示情報及びコマンド選択をプロセッサ１５０４に通信し、ディスプレイ１５１２上のカーソルの動きを制御するため、マウス、トラックボール又はカーソル方向キーなどのカーソル制御１５１６である。この入力装置は、典型的には、デバイスが平面上の位置を指定することを可能にする第１軸（ｘなど）と第２軸（ｙなど）の２つの軸の２つの自由度を有する。
【００８８】
コンピュータシステム１５００は、コンピュータシステム１５００を特定用途マシーンにする又はプログラムする、カスタマイズされた配線論理、１以上のＡＳＩＣ又はＦＰＧＡ、ファームウェア及び／又はプログラムロジックを用いて、開示された技術を実現してもよい。一実施例によると、当該技術は、プロセッサ１５０４がメインメモリ１５０６に含まれる１以上の命令の１以上のシーケンスを実行することに応答して、コンピュータシステム１５００により実行される。このような命令は、ストレージデバイス１５１０などの他の記憶媒体からメインメモリ１５０６に読み込まれてもよい。メインメモリ１５０６に含まれる命令シーケンスの実行は、プロセッサ１５０４に開示された方法の各ステップを実行させる。他の実施例では、配線回路が、ソフトウェア命令の代わりに又は一緒に利用されてもよい。
【００８９】
ここで用いられる“記憶媒体”という用語は、マシーンを特定の方法で実行させるデータ及び／又は命令を格納する何れかの非一時的媒体を表す。このような記憶媒体は、不揮発性媒体及び／又は揮発性媒体から構成されてもよい。不揮発性媒体は、例えば、ストレージデバイス１５１０などの光又は磁気ディスクなどを含む。揮発性媒体は、メインメモリ１５０６などのダイナミックメモリを含む。記憶媒体の通常形態は、例えば、フロッピー（登録商標）ディスク、フレキシブルディスク、ハードディスク、ソリッドステートドライブ、磁気テープ、他の何れかの磁気データ記憶媒体、ＣＤ−ＲＯＭ、他の何れかの光データ記憶媒体、ホールパターンによる何れかの物理媒体、ＲＡＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＦＬＡＳＨ−ＥＰＲＯＭ、ＮＶＲＡＭ、他の何れかのメモリチップ又はカートリッジなどを含む。
【００９０】
記憶媒体は、伝送媒体と異なるものであるが、これと共に利用されてもよい。伝送媒体は、記憶媒体の間の情報の伝送に用いられる。例えば、伝送媒体は、バス１５０２を構成する配線を含む同軸ケーブル、銅線及び光ファイバを含む。伝送媒体はまた、無線波及び赤外線データ通信中に生成されるものなど、音響波又は光波の形態をとることも可能である。
【００９１】
各種形態の媒体が、実行のためプロセッサ１５０４に１以上の命令の１以上のシーケンスを担持することに関する。例えば、これらの命令は、リモートコンピュータの磁気ディスク又はソリッドステートドライブ上に初期的には担持されてもよい。リモートコンピュータは、それのダイナミックメモリに命令をロードし、モデムを用いて電話線により命令を送信することが可能である。コンピュータシステム１５００にローカルなモデムは、電話線によりデータを受信し、データを赤外線信号に変換するため、赤外線送信機を利用することができる。赤外線検出装置が、赤外線信号により搬送されたデータを受信し、適切な回路が、当該データをバス１５０２に配置することができる。バス１５０２は、データをメインメモリ１５０６に搬送し、そこからプロセッサ１５０４は命令を抽出及び実行する。メインメモリ１５０６により受信された命令は、任意的には、プロセッサ１５０４による実行前後にストレージデバイス１５１０に格納されてもよい。
【００９２】
コンピュータシステム１５００はまた、バス１５０２に接続された通信インタフェース１５１８を有する。通信インタフェース１５１８は、ローカルネットワーク１５２２に接続されるネットワークリンク１５２０との双方向データ通信接続を提供する。例えば、通信インタフェース１５１８は、ＩＳＤＮ（Ｉｎｔｅｇｒａｔｅｄ Ｓｅｒｖｉｃｅｓ Ｄｉｇｉｔａｌ Ｎｅｔｗｏｒｋ）カード、ケーブルモデム、衛星モデム、又は対応するタイプの電話線とのデータ通信接続を提供するモデムであってもよい。他の例として、通信インタフェース１５１８は、互換性のあるＬＡＮとのデータ通信接続を提供するためのＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）カードであってもよい。無線リンクがまた実装されてもよい。このような何れかの実現形態では、通信インタフェース１５１８は、各種タイプの情報を表すデジタルデータストリームを搬送する電気、電磁気又は光信号を送受信する。
【００９３】
ネットワークリンク１５２０は、典型的には、１以上のネットワークを介し他のデータデバイスとのデータ通信を提供する。例えば、ネットワークリンク１５２０は、ローカルネットワーク１５２２を介しＩＳＰ（Ｉｎｔｅｒｎｅｔ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ）１５２６により運営されるデータ機器又はホストコンピュータ１５２４との接続を提供するものであってもよい。さらに、ＩＳＰ１５２６は、“インターネット”１５２８として一般に参照されるワールドワイドパケットデータ通信ネットワークを介しデータ通信サービスを提供する。ローカルネットワーク１５２２とインターネット１５２８とは共に、デジタルデータストリームを搬送する電気、電磁気又は光信号を利用する。各種ネットワークを介した信号と、ネットワークリンク１５２０及び通信インタフェース１５１８を介した信号とは、コンピュータシステム１５００に対してデジタルデータを搬送し、伝送媒体の一例となる形態である。
【００９４】
コンピュータシステム１５００は、ネットワーク、ネットワークリンク１５２０及び通信インタフェース１５１８を介し、プログラムコードを含むデータ及びメッセージを送受信することができる。インターネットの例では、サーバ１５３０は、インターネット１５２８、ＩＳＰ１５２６、ローカルネットワーク１５２２及び通信インタフェース１５１８を介しアプリケーションプログラムのためのリクエストされたコードを送信してもよい。
【００９５】
受信されたコードは、そのままプロセッサ１５０４により実行されてもよく、以降の利用のためストレージデバイス１５１０や他の不揮発性ストレージに格納されてもよい。
【００９６】
上述した明細書において、実現形態毎に可変的な多数の具体的詳細を参照して本発明の実施例が説明された。明細書及び図面は、限定的なものでなく例示的なものとしてみなされるべきである。本発明の範囲及び出願人が本発明の範囲であると意図するものは、何れか以降の補正を含む請求項に記載された特定の形態による請求項の文言上及び均等の範囲である。
【００９７】
【表１−１】
【表１−２】
【表２−１】
【表２−２】
【表３−１】
【表３−２】
【表３−３】
【表３−４】
【表３−５】
【表３−６】
【表３−７】
【表４−１】
【表４−２】
【表４−３】
【表４−４】
【表４−５】
【表４−６】
【表４−７】
【表４−８】
【表４−９】
【表４−１０】
【表４−１１】
【表４−１２】
【表４−１３】
【表４−１４】
【表４−１５】
【表４−１６】
【表４−１７】
【表４−１８】
【表４−１９】
【表４−２０】
【表４−２１】
【表４−２２】
【００９８】
以上、本発明の実施例について詳述したが、本発明は上述した特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【符号の説明】
【００９９】
１００ デバイスモニタシステム
１０２ 状態決定ツリー
１０４ デバイス情報
１０６ ファンクションライブラリ
１０８ ネットワーク
１１０ デバイス
【技術分野】
【０００１】
本発明は、デバイスとやりとりするためのデバイスインタラクションツリーに関する。
【背景技術】
【０００２】
中規模から大規模な企業はしばしば、パーソナルコンピュータに加えてアタッチされた各種デバイスを有する多様なコンピュータネットワークを有している。プリンタや複合機などのデバイスが入力されるリクエストを処理するのに十分な用紙やトナーを備えてオンラインのワーキング状態に維持されるとき、企業は最も効率的に機能する。限られた予算とスタッフを有するＩＴ（Ｉｎｆｏｒｍａｔｉｏｎ Ｔｅｃｈｎｏｌｏｇｙ）部門は、典型的には、これらのデバイスを利用可能にし続けるために、これらをメンテナンス及び修繕する。例えば、プリンタや複合機などのデバイスは、用紙やトナーレベルが低いとき、用紙やトナーを補充することによってメンテナンスされる。他の例として、デバイスは、紙詰まりを取り除いたり、開放されたままのデバイスのカバーを閉じることによって修復される。リクエストを処理することができないデバイスは、企業の効率的な運営を妨げ、ＩＴ部門に対して影響を及ぼす可能性がある。
【０００３】
デバイスを物理的にチェックする代わりに、ＩＴスタッフは、ネットワークを介しデバイスと遠隔的にやりとりするよう設計されたカスタマイズされたマネージメントアプリケーションを利用するかもしれない。各種のデバイスが、各種のカスタマイズされたデバイスマネージメント命令に応答する。各種デバイスが企業によって利用されるため、ＩＴスタッフは、企業により利用されるすべてのデバイスとやりとりすることが可能な単一のマネージメントアプリケーションを有していない可能性がある。さらに、マネージメントアプリケーションはネットワークに現在あるすべてのデバイスとやりとりすることが可能であったとしても、サポートされていないデバイスがネットワークに追加される可能性がある。新たなデバイスをサポートするためカスタマイズされたマネージメントアプリケーション更新することは大変であり、カスタマイズされたマネージメントアプリケーションの複雑さのため高いレベルのスキルを必要とする。さらに、セキュリティのため、カスタマイズされたマネージメントアプリケーションの更新は、高い権限のユーザを必要とするかもしれない。更新されたマネージメントアプリケーションが信頼されたソースからのものであったとしても、更新されたマネージメントアプリケーションにおけるバグは、マネージメントアプリケーションを実行するマシーンと共に、マネージメントアプリケーションにより管理されるデバイスに対して予期せぬ影響を与える可能性がある。
【０００４】
ここで説明されたアプローチは、追求可能なアプローチであるが、必ずしも以前に想到又は追求されたアプローチであるとは限らない。従って、特段の指摘がない場合、ここで説明されたアプローチはここに記載されたことによって従来技術とみなされるべきでない。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
本発明の課題は、デバイスの状態を決定するためのデバイスインタラクションツリーを生成及び利用するための技術を提供することである。
【課題を解決するための手段】
【０００６】
デバイスインタラクションツリーは、ルートノード、中間ノード及びリーフノードを有する。デバイスインタラクションツリーの具体例として、デバイス状態決定ツリー、デバイスコンフィギュレーションツリー、デバイスアクションツリーなどがあげられる。デバイス状態決定ツリーの中間ノードはクエリとテストとを規定し、リーフノードはデバイス状態を規定する。所与のデバイスの状態は、ルートノードから１以上の中間ノードを介してリーフノードまでデバイス状態決定ツリーを移動することによって決定される。移動中、ツリーの現在ノードに関連付けされたクエリが、レスポンスを取得するため所与のデバイスに送信される。現在ノードに関連付けされたテストは、１以上の値に対してレスポンスを評価するのに利用される。テストの結果は、ツリーのリーフノードに向かうパス上の次のノードを決定する。デバイスの状態は、ツリーの移動先となるリーフノードにより規定される。
【発明の効果】
【０００７】
本発明によると、デバイスの状態を決定するためのデバイスインタラクションツリーを生成及び利用するための技術を提供することができる。
【図面の簡単な説明】
【０００８】
【図１Ａ】図１Ａは、ネットワーク内の複数のデバイスをモニタリングするための一例となるデバイスモニタシステムを示す。
【図１Ｂ】図１Ｂは、既知のクラスのデバイスがネットワークに追加されたことを検出する一例となるデバイスモニタシステムを示す。
【図１Ｃ】図１Ｃは、未知のクラスのデバイスがネットワークに追加されたことを検出する一例となるデバイスモニタシステムを示す。
【図２】図２は、デバイスインタラクションツリーセットのための一例となるクラス図である。
【図３】図３は、デバイスとやりとりするためのツリーセットにおける一例となるコンポーネントを示す。
【図４】図４は、３レベルの一例となるツリーを示す。
【図５】図５は、デバイスのクラスを決定し、複数のデバイスインタラクションツリーの１つを選択するための一例となるデバイス分類を示す。
【図６】図６は、デバイスのベンダＩＤを取得するための一例となるツリーを示す。
【図７Ａ】図７Ａは、デバイスを単一のクラスに分類するための一例となるツリーを示す。
【図７Ｂ】図７Ｂは、デバイスを複数のクラスの１つに分類するための一例となるツリーを示す。
【図８Ａ】図８Ａは、クエリレスポンスディクショナリの一例となる構造を示す。
【図８Ｂ】図８Ｂは、８個のクエリを有する一例となるクエリレスポンスディクショナリを示す。
【図８Ｃ】図８Ｃは、４個のクエリがＩＤクエリである１１個のクエリを有する一例となるクエリレスポンスディクショナリを示す。
【図９Ａ】図９Ａは、新たなデバイスをサポートするためツリーを自動的に更新するための一例となる処理を示す。
【図９Ｂ】図９Ｂは、新たなデバイスをサポートするためツリーを手動により更新するための一例となる処理を示す。
【図１０Ａ】図１０Ａは、ツリーへの更新が中央サーバから受信される実施例を示す。
【図１０Ｂ】図１０Ｂは、ツリーへの更新がユーザ入力に基づく実施例を示す。
【図１１】図１１は、デバイスマネージメントアプリケーションがツリーを利用及び更新する実施例を示すフローチャートである。
【図１２】図１２は、デバイスマネージメントアプリケーションが一時的にツリーにノードを追加し、ノードが永続的なものになる前にクライアントがノードを有効にすることを可能にする実施例を示すフローチャートである。
【図１３】図１３は、デバイスマネージメントアプリケーションが中央サーバから受信したクエリレスポンスディクショナリに基づきツリーを更新する実施例を示す。
【図１４Ａ】図１４Ａは、一例となるデバイスインタラクションツリーの移動を示すフローチャートである。
【図１４Ｂ】図１４Ｂは、一例となるデバイスインタラクションツリーの移動を示すフローチャートである。
【図１４Ｃ】図１４Ｃは、一例となるデバイスインタラクションツリーの移動を示すフローチャートである。
【図１５】図１５は、開示された各種実施例を実行する一例となるコンピュータシステムを示す。
【発明を実施するための形態】
【０００９】
以下の説明では、本発明の完全な理解を提供するため、説明のための多数の具体的詳細が提供される。しかしながら、本発明はこれらの具体的詳細なしに実現されてもよいことは明らかであろう。他の例では、本発明を不必要に不明りょうにすることを避けるため、周知の構成及び装置はブロック図の形式により示される。
［全体概略］
デバイスの状態を決定するためのデバイスインタラクションツリーを生成及び利用するための方法、装置及び非一時的なコンピュータ可読記憶媒体が開示される。デバイスインタラクションツリーは、ルートノード、中間ノード及びリーフノードを有する。デバイスインタラクションツリーの具体例として、デバイス状態決定ツリー、デバイスコンフィギュレーションツリー、デバイスアクションツリーなどがあげられる。デバイス状態決定ツリーの中間ノードはクエリとテストとを規定し、リーフノードはデバイス状態を規定する。所与のデバイスの状態は、ルートノードから１以上の中間ノードを介してリーフノードまでデバイス状態決定ツリーを移動することによって決定される。移動中、ツリーの現在ノードに関連付けされたクエリが、レスポンスを取得するため所与のデバイスに送信される。現在ノードに関連付けされたテストは、１以上の値に対してレスポンスを評価するのに利用される。テストの結果は、ツリーのリーフノードに向かうパス上の次のノードを決定する。デバイスの状態は、ツリーの移動先となるリーフノードにより規定される。
【００１０】
デバイスインタラクションツリーの具体例の詳細な理解を提供するため、デバイス状態決定ツリーの各種具体例が示される。これらの具体例の多くは、デバイスの状態を決定する代わりに又は加えて、デバイスのパラメータを変更するよう構成されるデバイスコンフィギュレーションツリーに関して適用されてもよい。例えば、デバイスコンフィギュレーションツリーは、デバイスの名前を変更するのに利用されてもよい。あるいは、これらの具体例の多くは、デバイスの状態を決定する代わりに又は加えて、デバイスに特定のアクションを実行させるよう構成されるデバイスアクションツリーに関して適用されてもよい。例えば、デバイスアクションツリーは、デバイスに指定された設定に従って文書を印刷させるのに利用されてもよい。
［状態決定ツリー］
１つの状態決定ツリーが、複数のデバイスの状態を決定するのに利用されてもよい。サポートされるデバイスは、様々な機能を備えたデバイス、様々な構成を備えたデバイス、様々なメーカーからのデバイス、及び／又は同じクエリに異なって応答する同一の状態を備えたデバイスを含むものであってもよい。デバイスインタラクションツリーは、デバイスインタラクションツリーを移動するため構成されたソフトウェアを修正することなく、生成又は修正されてもよい。一実施例では、デバイスインタラクションツリーの生成、修正、置換及び／又はテストは、より少数のセキュリティ権限を要求し、特殊化されたデバイスマネージメントソフトウェアをインストール、コンパイル又は修正するよりも、ネットワーク上のデバイスに対してより低いセキュリティリスクしか有さない。
【００１１】
ここに開示される技術は、何れかのタイプのデバイス状態に適用されてもよい。デバイス状態の具体例として、限定することなく、アイドル、スリープ中、処理中又は印刷中、印刷準備完了、ウォーミングアップ、トナー交換、調整、ジョブ中止、カバーオープン、トナー切れ、フューザ切れ、又は紙詰まりがあげられる。デバイス状態は、デバイスの動作状態を記述するものであってもよい。一実施例では、動作状態は、デバイスによって現在実行中のアクションのタイプ又はアクションがないことを含む。他の実施例では、動作状態は、デバイスがアクションを実行することを阻害しているエラーを含む。他の実施例では、デバイス状態は、用紙トレーサイズ、３穴パンチ、２穴パンチ又はステープラなどのデバイス設定を含む。他の実施例では、デバイス状態は、トナーレベル（７５％など）、用紙残量（５０頁など）、又はバッテリ残量（６０％又は３時間など）などの供給状態を含む。各種実施例では、各種タイプの状態が同一のツリーにより表現されてもよい。例えば、単一の状態決定ツリーは、エラー、動作状態、デバイスの設定及び／又は供給状態に関する情報を提供するものであってもよい。一実施例では、デバイスの状態に対するリクエストは、要求されるタイプの情報を指定する。例えば、１つのリクエストは、デバイスの動作状態に対するものであり、他のリクエストは、デバイスが３穴パンチャを備えるよう構成されているかを決定するためのものであってもよい。
【００１２】
一実施例では、デバイスマネージメントアプリケーションは、デバイスの状態に対するリクエストを受信する。一例では、リクエストは、アドレスによってデバイスを特定する。デバイスマネージメントアプリケーションは、アドレスに送信するクエリを選択するため、状態決定ツリーにアクセスし、当該アドレスにおいてデバイスからレスポンスが受信される。デバイスマネージメントアプリケーションは、デバイスからのレスポンスに基づき１以上の中間ノードを介しリーフノードまで状態決定ツリーを移動することによって、デバイスの状態を決定する。リーフノードはデバイスの状態を示し、デバイスマネージメントアプリケーションは、デバイス状態のリクエストに応答して、デバイス状態をユーザインタフェース上に表示するようにしてもよい。ツリーの移動中、デバイスマネージメントアプリケーションは、単にクエリを利用し、状態決定ツリーにより規定されるテストを適用する。従って、デバイスマネージメントアプリケーションが状態決定ツリーなどのデバイスインタラクションツリーを移動するよう構成されると、デバイスインタラクションツリーは、デバイスマネージメントアプリケーションのコードを修正することなく更新されるようにしてもよい。
【００１３】
一実施例では、デバイスマネージメントアプリケーションはネットワーク上のデバイスをモニタし、状態決定ツリーがネットワーク内のあるデバイスの状態を提供することができないことを検出したことに応答して、状態決定ツリーが更新される。一実施例では、この更新は、更新されたデバイスインタラクションツリーを提供するサーバから要求される。この更新は、デバイスマネージメントアプリケーションのコードを修正することなく、既存のデバイスインタラクションツリーの置換、新たなデバイスインタラクションツリーの生成、及び／又は既存のデバイスのノードの追加、削除又は変更を行うものであってもよい。
【００１４】
一実施例では、デバイスマネージメントアプリケーションは、クエリ及びレスポンス情報に関連付けされた受信した状態情報に基づき、状態決定ツリーを生成又は修正する。一実施例では、この情報は、新たな関連付けが検出されると、デバイスマネージメントアプリケーションに通知するサーバから受信される。関連付けされた状態情報、クエリ情報及びレスポンス情報は、新たな状態決定ツリーを生成するため、デバイスマネージメントアプリケーションのコードを修正することなく既存の状態決定ツリーのノードを追加、削除又は修正するのに利用されてもよい。
【００１５】
他の実施例では、ツリーを生成又は修正するのに利用される情報の一部又はすべてが、ユーザインタフェースを介しユーザにより提供されるようにしてもよい。一例では、ユーザは、ネットワーク上のあるデバイスのある状態が観察されたことを示す。これに応答して、デバイスマネージメントアプリケーションは、あるレスポンスを導くため、当該デバイスにあるクエリを送信する。特定の状態、クエリ及びレスポンスの指示は、デバイスマネージメントアプリケーションのコードを変更することなく、新たな状態決定ツリーを生成するため、及び／又は既存の状態決定ツリーについてノードを追加、削除若しくは修正するのに利用されてもよい。
【００１６】
図１Ａは、ネットワーク１０８を介しデバイス１１０Ａ，１１０Ｂ，１１０Ｃと通信する一例となるデバイスモニタシステム１００を示す。例えば、デバイスモニタシステム１００は、１以上の状態決定ツリーを用いてネットワーク１０８のデバイス１１０Ａ，１１０Ｂ，１１０Ｃの状態を決定するデバイスマネージメントアプリケーション（図示せず）を有してもよい。図示されるように、デバイスモニタシステム１００は、クエリ及びテストを指定する実行可能コード及び状態決定ツリー１０２のファンクションライブラリ１０６を有する。ファンクションライブラリ１０６は、デバイス１１０Ａ，１１０Ｂ，１１０Ｃに関して汎用的であって、任意的にはデバイスのクラスに関しても汎用的なファンクションを有する。すなわち、これらのファンクションは、何れかの状態決定ツリーと何れかのデバイス情報セットとにより機能する。一実施例では、デバイスマネージメントアプリケーションは、状態決定ツリー１０２を構成、実行又は更新するため、ファンクションライブラリ１０６からファンクションを呼び出す。ファンクションライブラリ１０６からのＣｏｎｓｔｒｕｃｔＱＴｒｅｅファンクションは、状態決定ツリーを構成する。ファンクションライブラリ１０６からのＥｘｅｃｕｔｅＱＴｒｅｅファンクションは、デバイスに送信するため状態決定ツリー１０２からクエリを選択し、デバイスから結果を受信し、当該結果に状態決定ツリー１０２からのテストを適用し、デバイスの状態を決定する。
【００１７】
図示されるように、デバイスモニタシステムはまた、デバイスインタラクションツリー１０２が構成されるデバイス情報１０４を有する。デバイス情報１０４は、各デバイス１１０Ａ，１１０Ｂ，１１０Ｃに固有の情報を有する。デバイスインタラクションツリー１０２は、デバイスモニタシステム１００がデバイス１１０Ａ，１１０Ｂ，１１０Ｃに関する新たな情報を受信すると、ＵｐｄａｔｅＱＴｒｅｅファンクションにより修正されてもよい。
［クエリ及びレスポンス］
デバイス状態は、当該デバイスに対するクエリ系列へのレスポンスに基づき決定されてもよい。例えば、第１クエリに対する第１レスポンスは、デバイスが属するデバイスのクラスを決定するのに十分な情報を提供し、第２クエリに対する第２レスポンスは、デバイスの状態を決定するのに十分な情報を提供するものであってもよい。他の例では、第２クエリに対する第３レスポンスと、おそらく第４クエリに対する第４レスポンスとが、状態が決定可能になる前に求められる。
【００１８】
ここに開示される技術は、デバイスから情報を抽出するための何れかのタイプのクエリに適用されてもよい。クエリのタイプの具体例として、ＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）クエリ、ＰＪＬ（Ｐｒｉｎｔｅｒ Ｊｏｂ Ｌａｎｇｕａｇｅ）クエリ、ＰｏｓｔＳｃｒｉｐｔクエリ、ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）クエリがあげられる。開示される各種実現形態は、これらクエリのタイプの具体例のすべて、１つ又は組み合わせを利用するものであってもよいし、又は何れを利用しなくてもよい。一実施例では、状態決定ツリーのクエリ及びテストは、何れかのデバイスの状態又は設定を変更不可であり、又はネットワーク内のデバイス上で実行されるソフトウェアを変更不可である。このようにして、状態決定ツリーに対する更新は、ツリーのソースが未知であったとしても、又はソースの評判が未知であったとしても、大きなセキュリティリスクなくテストされてもよい。
【００１９】
テーブル１は、各種メーカーにより製造される各種デバイスについて、ｈｒＤｅｖｉｃｅＤｅｓｃｒ、ｈｒＰｒｉｎｔｅｒＳｔａｔｕｓ、ｈｒＤｅｖｉｃｅＳｔａｔｕｓ、ｈｒＰｒｉｎｔｅｒＤｅｔｅｃｔｅｄＥｒｒｏｒＳｔａｔｅ、ｐｒｔＡｌｅｒｔＣｏｄｅ、ｐｒｔＡｌｅｒｔＣｏｄｅ、ｐｒｔＡｌｅｒｔＧｒｏｕｐ、ｐｒｔＡｌｅｒｔＬｏｃａｔｉｏｎ、ｐｒｔＡｌｅｒｔＳｅｖｅｒｉｔｙＬｅｖｅｌ、及びｐｒｔＡｌｅｒｔＴｒａｎｓｉｎｉｎｇＬｅｖｅｌを含むＳＮＭＰクエリに対する一例となるデバイスレスポンスを示す。すべてのプリンタがアイドル又はスリープ状態にあり、３つが低トナー状態を報告していた（Ｓａｍｓｕｎｇ７７０，ＯＫＩ ＭＣ３６０及びＲｉｃｏｈ Ａｆｉｃｉｏ Ｃ４２０）。テーブル１は、Ａｐｐｅｎｄｉｘ Ａに含まれている。
【００２０】
図示されるように、ＩＰアドレス１７２．３０．４．５５のデバイスは、“ＨＰ ＬａｓｅｒＪｅｔ Ｐ４０１４”によりｈｒＤｅｖｉｃｅＤｅｓｃｒクエリに応答し、“ｉｄｌｅ”によりｈｒＰｒｉｎｔｅｒＳｔａｔｕｓクエリに応答し、“ｒｕｎｎｉｎｇ”によりｈｒＤｅｖｉｃｅ Ｓｔａｔｕｓに応答し、“００”によりｈｒＰｒｉｎｔｅｒＤｅｔｅｃｔｅｄ Ｅｒｒｏｒ Ｓｔａｔｅクエリに応答し、“ｓｕｂｕｎｉｔＰｏｗｅｒＳａｖｅｒ”によりｐｒｔＡｌｅｒｔＣｏｄｅクエリに応答し、“ｇｅｎｅｒａｌＰｒｉｎｔｅｒ”によりｐｒｔＡｌｅｒｔＧｒｏｕｐクエリに応答し、“３５０７８”によりｐｒｔＡｌｅｒｔＬｏｃａｔｉｏｎクエリに応答し、“ｏｔｈｅｒ”によりｐｒｔＡｌｅｒｔＳｅｖｅｒｉｔｙＬｅｖｅｌクエリに応答し、“ｕｎｔｒａｉｎｅｄ”によりｐｒｔＡｌｅｒｔＴｒａｎｉｎｉｎｇＬｅｖｅｌクエリに応答した。この情報は、当該デバイス及び他のデバイスに関する他の情報と共に、デバイスの状態を確実に決定するため、状態決定ツリーを構成するのに利用されてもよい。一実施例では、状態決定ツリーの利用は、デバイスがアイドルであることを決定する前に、これらのクエリのすべてではないが一部をデバイスに送信する。
【００２１】
１７２．３０．４．５５のデバイスが“ｉｄｌｅ”によりｈｒＰｒｉｎｔｅｒＳｔａｔｕｓに応答したが、他のアイドル状態のデバイスは、“ｉｄｌｅ”により同じクエリに応答しなかった。例えば、１７２．３０．４．６１のデバイスは、“ｏｔｈｅｒ”によりｈｒＰｒｉｎｔｅｒＳｔａｔｕｓクエリに応答した。従って、デバイスのアドレスを超えた情報がない場合、ｈｒＰｒｉｎｔｅｒＳｔａｔｕｓクエリは、デバイスの実際の状態を決定するのに不十分であるかもしれない。
【００２２】
実際、異なるデバイスモデル、異なる設定を備えた同一モデル、及び異なるインストールされたファームウェアを備えた同一モデルが、同一のクエリに異なって応答するようにしてもよい。一実施例では、状態決定ツリーは、ネットワーク内の各デバイスについて、デバイスの状態を決定するため、デバイスに対する問題へのクエリを指定する。デバイスはクエリに応答し、レスポンスに基づき、状態決定ツリーはデバイスの状態を特定するリーフノードに移動する。
【００２３】
テーブル１の具体例を再び参照して、ｈｒＰｒｉｎｔｅｒＤｅｔｅｃｔｅｄＥｒｒｏｒＳｔａｔｅクエリに対するレスポンスは、低トナーの３つのプリンタについて非ゼロとなる（また、その他のプリンタがゼロを表現する方法の数に留意されたい）。Ｈｏｓｔ Ｒｅｓｏｕｒｃｅｓ ＭＩＢ（ＲＦＣ２７９０）は、ビット＃２が低トナーを示し、ビット＃０が第１バイトの最上位ビットである、タイプＯＣＴＥＴ ＳＴＲＩＮＧを有する当該値のビットとしてエラー状態が符号化されることを述べている。ＲｉｃｏｈとＯｋｉは、これを３２（２の５乗）又は１６進数の０ｘ２０に対応する左から３番目のビットを意味するものとして解釈し、それは生の値としてリターンされる（スペース文字）。しかしながら、Ｒｉｃｏｈ Ａｆｉｃｉｏを含む他のすべてのプリンタは、コロン文字によりセパレートされたＡＳＣＩＩ数字により表現されるようなＯＣＴＥＴ ＳＴＲＩＮＧの値をリターンし（ＯＣＴＥＴ ＳＴＲＩＮＧがいくつかの文書において示される）、すなわち、ゼロを示すのにヌルの代わりに４９（ＡＳＣＩＩの“０”）をリターンする。また、Ｓａｍｓｕｎｇのエンジニアは、自らの規格の解釈において重要な相違を有しているようであり、左の代わりに右からビットをカウントしているようである。すなわち、ビット＃０がビット＃２を４（２の２乗）に対応させる最下位ビットであり、低トナーは“０４”として報告される。
【００２４】
さらなる状況の複雑化は、複数のプリンタ状態が可能であるという事実であり、ＳＮＭＰレスポンスの異なる組み合わせは、関係するプリンタモデルに応じて同じプリンタ状態を示すものであってもよいし、そうでなくてもよい。１つのアプローチは、すべてのプリンタモデルについてＳＮＭＰレスポンスのデータベースを構築することである。対象となるデバイスがネットワーク上において特定され、それのモデル名が決定されると、対象となるデバイスの予想されるＳＮＭＰレスポンスが、データベースのモデル名を検索することによって決定できる。しかしながら、このアプローチは、利用可能なすべてのプリンタモデルを表す極めて大きなデータベースの構築及び継続的な更新を必要とする。すべての既知のベンダからのすべての既知のプリンタの信頼でき、一貫したデータセットを維持するタスクは、ベンダの協力なしには、開発チームに対して大きな負担となりうる。
【００２５】
テーブル２は、各種状態にある単一のデバイスのデバイスレスポンスの具体例を示す。テーブル２は、Ａｐｐｅｎｄｉｘ Ａに含まれる。図示されるように、デバイスは、異なる状態にあるとき、異なってクエリに応答する。従って、クエリの一部又はすべてに対するレスポンスに基づきデバイスの状態を決定することができる。
【００２６】
テーブル２に参照されるデバイスのケースでさえ、ｈｒＰｒｉｎｔｅｒＤｅｔｅｃｔｅｄＥｒｒｏｒＳｔａｔｅがどのように報告されるかについていくつかの変形がある。カバーがオープンされているとき、生のバイトである０ｘｏＢがリターンされ、ＡＳＣＩＩの“１１”であり、８＋２＋１に等しい。ＭＩＢ規格によると、これは、ｃｏｖｅｒＯｐｅｎ（８）、ｏｆｆｌｉｎｅ（２）及びｓｅｒｖｉｃｅ ｒｅｑｕｅｓｔｅｄ（１）を示す。しかしながら、紙詰まりなどの他の状態に応答して（プリンタが落ち着き、一貫して同じ値をリターンした数秒後）、ストリング“０７”がリターンされ、それはＡＳＣＩＩバイトの４８及び５５を含む。ＡＳＣＩＩ数字として解釈された場合、“０７”は数字の７を示し、それはｊａｍｍｅｄ（４）、ｏｆｆｌｉｎｅ（２）及びｓｅｒｖｉｃｅ ｒｅｑｕｓｔｅｄ（１）に対応する。従って、プリンタは、生のバイトとしてｈｒＰｒｉｎｔｅｒＤｅｔｅｃｔｅｄＥｒｒｏｒＳｔａｔｅとリターンするときもあり、ＡＳＣＩＩ数字の文字列としてリターンするときもある。
【００２７】
ネットワーク内のデバイスのデバイス状態を取得する複雑さのため、カスタムデバイスマネージメントソフトウェアに対する更新は、極めて時間と費用のかかるものとなる可能性があり、ソフトウェアの頻繁な更新は、セキュリティリスクをもたらし、予期せぬソフトウェアバグのリスクを高める。コンパイルされたソフトウェアがパッチされると、新たなバイナリの配布がクライアントにされる。これらのクライアントは、ソフトウェアをインストールする前にウィルス感染や他のセキュリティ問題のためにこの新たなバイナリ配布をチェックする必要がある。
【００２８】
一実施例では、カスタムデバイスマネージメントソフトウェアを更新する代わりに、サイトに固有の状態決定ツリーが、ネットワーク内のデバイスの状態を決定するため構成される。一実施例では、汎用的なデバイスマネージメントソフトウェアが、何れかのデバイスインタラクションツリーを利用するため構成され、デバイスマネージメントソフトウェアは、ツリーの変更による更新を要求しない。
【００２９】
一実施例では、デバイスインタラクションツリーは、ネットワーク内にあるすべてのプリンタタイプのブランチを含む。ツリー構造は、デバイスマネージメントソフトウェアを修正することなく容易に置換及び更新されてもよい。従って、ツリー構造は、維持するのにより効率的であり、ネットワーク上のモニタ対象のプリンタセットと共に拡大するようにしてもよい。ツリーは、一般的なテーブルより容易に特有なデバイス動作を処理することが可能である。例えば、ｈｒＰｒｉｎｔｅｒＤｅｔｅｃｔｅｄＥｒｒｏｒＳｔａｔｅの異なる解釈のため、ブランチがツリーに追加されてもよい。一実施例では、ツリーは、プリンタが複数の状態の何れにあるか決定するため、複数のプリンタタイプの複数のＳＮＭＰオブジェクトを抽出するためのクエリを格納する。
【００３０】
状態決定ツリーのノードは、デバイスに対して実行されるクエリを規定する。一実施例では、ツリーは、デバイスの状態を決定するのに十分な情報を有する前に、デバイスに送信される平均的なクエリ数を最小化するよう構成される。一例では、ツリーの高さを最小化するため、又はルートノードと各リーフノードとの間の平均ノード数を最小化するためのツリー最適化技術が利用される。クエリはデバイスからのレスポンスをトリガーし、レスポンスに基づき、状態決定ツリーがリーフノードに向かって移動される。リーフノードは、デバイスの状態を特定する。
［テスト及びアサインメント］
デバイスに対して送信されるクエリを規定することに加えて、状態決定ツリーはまた、１以上の値に対してデバイスからのレスポンスを評価するテストを規定する。一実施例では、デバイスマネージメントアプリケーションは、デバイスに送信されるクエリを決定するため、状態決定ツリーのノードにアクセスする。クエリはデバイスに送信され、レスポンスがデバイスから受信される。レスポンスは、デバイスの状態を規定するリーフノードに向かうツリーの移動において次のノードを決定するため、１以上の値に対して処理及びテストされてもよい。ノードは、処理されたレスポンスに適用されるテストを規定する。例えば、規定されたテストは、レスポンスがある文字列を有するか否かのテストであってもよい。
【００３１】
テスト前、レスポンスはアサインメント段階において処理されてもよい。開示される技術は何れかのタイプのアサインメントに限定されるものでない。一実施例では、何れのアサインメントも必要とされない。図３において、ＳｔｒｉｐＰｒｅｆｉｘ、ＳｔｒｉｐＰｒｅｆｉｘＳｔａｒｔｓＷｉｔｈ、ＳｔｒｉｐＳｕｆｆｉｘ、ＳｔｒｉｐＳｕｆｆｉｘＳｔａｒｔｓＷｉｔｈ、Ｐｒｅｐｅｎｄ、Ａｐｐｅｎｄなどのアサインメントの具体例が提供される。他のタイプのアサインメントは、これらのアサインメント例に加えて又は代わりに利用されてもよい。アサインメントは、処理済みレスポンスを生成するため、レスポンス又は他の格納されているデータに対して実行されてもよい。
【００３２】
処理済みレスポンスが、１以上の値に対してテストされる。開示される技術は、何れか特定のタイプのテストに限定されるものでない。テストは、リターンされるパラメータ名やリターンされるパラメータの値など、テストされるアイテムを規定するものであってもよい。テストはまた、処理済みレスポンスをテストするため実行される処理又は比較を規定するものであってもよい。処理の具体例として、ＩｓＮｕｌｌ、Ｅｑｕａｌｓ、Ｃｏｎｔａｉｎｓ、ＧｒｅａｔｅｒＴｈａｎなどがあげられ、図３に提供される。ＩｓＮｕｌｌ処理は、Ｎｕｌｌという値と等しいという演算との双方を規定する点で特有なものである。ある具体例では、処理済みレスポンスは、処理“Ｅｑｕａｌｓ”と“Ｏｔｈｅｒ”の値とを用いてテストされる。その後、レスポンスが“Ｏｔｈｅｒ”であるとき、テストの結果は“ｔｒｕｅ”である。そうでない場合、テストの結果は“ｆａｌｓｅ”である。他のタイプのテストが、テスト例に加えて又は代わりに利用されてもよい。
【００３３】
一実施例では、アサインメントがテスト段階の結果として適用される。例えば、状態変数は、当該状態がアイドルであることを結論付けるテストの結果として“ｉｄｌｅ”に割り当てられてもよい。アサインメントはまた、状態決定ツリーの以降のノードによる利用のため情報を処理及び格納するのに利用されてもよい。
【００３４】
一実施例では、状態決定ツリーの中間ノードは、２つのチャイルドノードを有する。中間ノードは、デバイスに送信するクエリ、クエリの結果に適用されるアサインメント、及び処理済みの結果に適用される真偽テストを規定する。テストの結果が真である場合、デバイスマネージメントアプリケーションは、真のブランチを下って２つのチャイルドノードの１つに状態決定ツリーを移動する。テストの結果が偽である場合、デバイスマネージメントアプリケーションは、偽のブランチを下って２つのチャイルドノードの他方に状態決定ツリーを移動する。他の実施例では、ノードは他の個数のチャイルドを有してもよく、テストは単なる真偽テスト以外のものであってもよい。
【００３５】
他の実施例では、中間ノードは３つのチャイルドノードを有し、ある値の範囲の２つの値に対してテストが実行される。処理済みレスポンスが第１の値以下である場合、状態決定ツリーは３つのチャイルドノードの第１ノードに移動される。処理済みレスポンスが２つの値の間にある場合、状態決定ツリーは、３つのチャイルドノードの第２ノードに移動される。処理済みレスポンスが第２の値以上である場合、状態決定ツリーは、３つのチャイルドノードの第３ノードに移動される。さらなる他の実施例では、３つのチャイルドノードによる中間ノードは、一方が他方のチャイルドである２つのバイナリ中間ノードとしてモデル化することが可能である。
【００３６】
さらなる他の実施例では、２以上の他の値に対してテストが実行される。例えば、テストは、レスポンスが“ｉｄｌｅ”、“ｒｕｎｎｉｎｇ”又は“ｏｔｈｅｒ”であるか決定可能である。テストの結果として、他のブランチがツリーにおいて移動される。一実施例では、状態決定ツリーのいくつかのノードは、テスト又はサブテストを規定し、クエリを規定しない。クエリがデバイスに送信されると、クエリに対するレスポンスがツリーの異なる複数のレベルにおいて異なる複数の方法によりテストされてもよい。
［デバイスクラス］
各種実施例では、デバイスは、各デバイスをクエリに対して同様に応答させるメーカー、年、機能又は他の何れかのファクタに基づきクラスに分類されてもよい。各クラスは、クラス内のデバイスの状態を決定するため別々の状態決定ツリーを有するようにしてもよい。一実施例では、クラス決定ツリーは、デバイスが属するクラスを決定する。デバイスのクラスがクラス決定ツリーにより決定されると、当該クラスの状態決定ツリーが、デバイスの状態を決定するのに利用されてもよい。
【００３７】
テーブル４３．１８．１は、デバイスが同一状態にあるときに同じクエリに対して同じように応答するデバイスを含むよう規定されるデバイスのクラスを示す。テーブル４３．１８．１は、Ａｐｐｅｎｄｉｘ Ａに提供される。
【００３８】
図示されるように、クラスＡ，Ｂ，Ｃ，Ｄ，Ｆ，Ｇの各デバイスは、トナーが低レベルであるとき（Ｌｏｗ：Ｔｏｎｅｒ）、同じＳＮＭＰクエリに対して同じように応答する。また図示されるように、クラスＥのデバイスは、ブラックトナーが低く、シアントナーが低く、マゼンタトナーが低く、イエロートナーが低いとき、同じＳＮＭＰクエリに対して同じように応答する。個別のデバイス又はデバイスのクラスがサンプルクエリに対してどのように応答するかに関する情報が、図示されるようなテーブル又は他の何れかの機構により格納されてもよい。一実施例では、デバイスインタラクションツリーが、テーブル２などのテーブルに格納される情報に基づき構成される。
【００３９】
一実施例では、クラスＡ，Ｂ，Ｃ，Ｄ，Ｆ，Ｇの何れかのデバイスが、ｗａｒｎｉｎｇ（３）によりｈｒＤｅｖｉｃｅＳｔａｔｕｓクエリと、２０ｈによりｈｒＰｒｉｎｔｅｒＤｅｔｅｃｔｅｄＥｒｒｏｒＳｔａｔｅクエリとに応答するとき、“Ｌｏｗ：Ｔｏｎｅｒ”の状態を有すると決定されてもよい。他の実施例では、ｍａｒｋｅｒＴｏｎｅｒＡｌｍｏｓｔＥｍｐｔｙ（１１０４）のレスポンスによる追加的なｐｒｔＡｌｅｒｔＣｏｄｅクエリが、デバイスの状態を決定するのに利用される。他のデバイス状態を有する他のデバイスについて、異なる個数のクエリがデバイス状態を決定するため実行されてもよい。
【００４０】
図１Ａの例では、デバイスモニタシステム１００は、３つのクラスＡ，Ｂ，Ｃに属する５つのデバイスとやりとりする。各クラスの状態決定ツリーは、クラス内のデバイスを分類するのに利用されるクエリとテストとを有する。状態決定ツリー１０２は、個々のツリーに分割されるか、又は１つのツリーとして合成されてもよい。一実施例では、クラス決定ツリーとクラスＡ，Ｂ，Ｃの状態決定ツリーとは、一緒になってネットワーク１０８内の何れかのデバイスの状態決定ツリーを構成する。
【００４１】
図１Ｂの例では、既知のクラスＣの新たなデバイスがネットワークに追加される。既知のクラスＣの状態決定ツリーは、当該デバイスを分類するための機能をすでに有している。従って、状態決定ツリー１０２は、本例では更新されない。ファンクション“ＥｘｅｃｕｔｅＴｒｅｅ”は、既知のクラスＣの既存の状態決定ツリーにより新たなデバイスに関する情報を取得するのに利用可能である。
【００４２】
図１Ｃの例では、未知のクラスＤの新たなデバイスがネットワークに追加される。デバイスモニタシステム１００は、既存の状態決定ツリー１０２により新たなデバイスがサポートされていないことを検出する。これに応答して、デバイスモニタシステム１００は、ファンクション“ＵｐｄａｔｅＴｒｅｅ”を用いて状態決定ツリー１０２を更新する。例えば、デバイスモニタシステム１００は、図１０Ａに示されるように、サーバから未知のクラスのためのツリー又は他の情報をダウンロードしてもよい。デバイスモニタシステムが未知のクラスＤの他の情報を受信する場合、他の情報は、ファンクションライブラリ１０６のＣｏｎｓｔｒｕｃｔＴｒｅｅファンクションを用いてクラスＤのツリーを構成するのに利用されてもよい。
【００４３】
図５は、デバイスの状態を決定するためデバイスマネージメントアプリケーションにより利用可能な複数のツリーの具体例を示す。第１ツリー５００は、デバイスを複数のデバイスクラスの１つに分類する。第１ツリー５００のリーフノードは、デバイスクラスの識別子を規定する。この識別子は、第２ツリー５０２〜５０６の１つを選択するのに利用される。第２ツリー５０２〜５０６のそれぞれは、１以上のデバイスクラスのグループに属するデバイスに送信するクエリ及びテストのセットを規定する。第２ツリー５０２〜５０６のそれぞれは、第２ツリーによりカバーされるクラスのグループのデバイスのデバイス状態を規定するリーフノードを有する。図５に図示されない実施例では、第１ツリーと第２ツリーとは、１つのツリーに合成される。
【００４４】
一実施例では、デバイスのベンダの身元を決定するツリーは、デバイスの他の状態情報を決定するより大きなツリーの一部である。例えば、ベンダの身元は、デバイスが属するクラスの決定の一部であってもよい。
【００４５】
図６は、デバイスのベンダを決定するためのツリーの実現形態を示す。デバイスマネージメントアプリケーションは、デバイスのｖｅｎｄｏｒＩＤのリクエストを受信する。ノード６００は、デバイスのアドレスがＮＵＬＬであるかテストする。ＮＵＬＬである場合、ｖｅｎｄｏｒＩＤは決定されず、ツリーの移動はノード６０４において終了する。ＮＵＬＬでない場合、ノード６０２は、ｖｅｎｄｏｒＩＤパラメータがＮＵＬＬであるかテストする。ｖｅｎｄｏｒＩＤパラメータがＮＵＬＬである場合、ｖｅｎｄｏｒＩＤパラメータは決定されず、ツリーの移動はノード６０８において終了する。ｖｅｎｄｏｒＩＤパラメータがＮＵＬＬでない場合、ノード６０６は、ｖｅｎｄｏｒＩＤパラメータの値を決定する。各種実施例では、複数のパラメータが、ベンダの身元を決定するためチェックされる必要があってもよい。例えば、いくつかのプリンタは“ｖｅｎｄｏｒＩＤ”などのベンダの身元を格納せず、他のパラメータがこれらのデバイスから抽出される必要がある可能性がある。
【００４６】
図７Ａは、シングルステップデバイス分類ツリーを示す。ノード７００Ａは、特定のデバイスクラスをテストする。例えば、ノード７００Ａは、１以上のクエリと１以上のテストとを有してもよい。デバイスがクラスにある場合、ツリーの移動はノード７０４Ａに続く。そうでない場合、移動は７０２Ａに続く。図７Ｂは、第２デバイスクラスをサポートするため更新されるデバイス分類ツリーを示す。図示されるように、ノード７０２Ｂは、第２デバイスクラスのテストを含む。デバイスが何れのクラスのメンバーでもない場合、移動はノード７０６Ｂに続き、デバイスが第２デバイスクラスのメンバーであるとき、移動はノード７０８Ｂに続く。
［デバイスインタラクションツリーの生成、修正及び置換］
一実施例では、デバイスのクラスに対するデバイスインタラクションツリーは、当該デバイスのクラスを製造したメーカーにより生成される。デバイスインタラクションツリーは、クライアントに配布されてもよい。例えば、異なるバージョンの状態ツリーが、ウェブサーバ上で利用可能とされてもよい。クライアントは、前のバージョンのツリーを新たなバージョンと置換し、又は異なるタイプのデバイスによる利用のために双方のバージョンを格納するようにしてもよい。
【００４７】
他の実施例では、デバイスマネージメントアプリケーションは、デバイス状態、クエリ及びレスポンスとの間の格納されている関連付けに基づき状態決定ツリーを生成する。モニタ対象の選択された各デバイスの選択された各状態について、デバイスマネージメントアプリケーションは、デバイス状態を特定する一意的なパラメータの１以上のセットを決定する。複数のデバイスのデバイス状態のパラメータセットは合成されてもよく、最も頻繁に利用されるセットが、状態決定ツリーの上位レベルの基礎を形成してもよい。このようにして、状態を決定するため最も頻繁にクエリされる情報は、状態決定ツリーの移動中の早期の段階でクエリされてもよい。１つ又は少数の特定のデバイスに対してのみクエリされる情報は、状態決定ツリーの移動中の以降の段階でクエリされるようにしてもよい。ある実施例では、デバイスマネージメントアプリケーションは、あるネットワーク上のプリンタセットの関連するクエリとレスポンス情報とを含むクエリレスポンスディクショナリのコレクションを用いて、最小の又は最適化された状態決定ツリーを自動構成する。
【００４８】
図２は、状態決定ツリーのセットの一例となるクラス図である。図示されるように、状態決定ツリーセット２００は、状態決定ツリー２０２のアレイを含む。各状態決定ツリー２０２は、１以上のクエリ２０８、アサインメント及びテスト２１０を含む１以上の状態決定ユニット２０４を有する。この例では、各テストは、真のチャイルドノード又は偽のチャイルドノードにナビゲートするブールタイプ２０６の結果をもたらす。図示されるように、テストは、主部と、主部自体の値又は主部に一致する名前を有する変数の値をテストするか決定する主部演算子２１４とを含む。さらに図示されるように、テストは、述部と、主部のテスト方法を規定する述部演算子２１６とを含む。この例では、テスト２１０は、主部が述部を含む、述部に等しい又は述部より大きいか決定することが可能である。一例となるクエリ２０８は文字列によって応答され、一例となるテスト２１０は文字列に対して処理する。他の実現形態によると、クエリレスポンスは何れかのフォーマットにより値を規定し、テストは何れかのフォーマットの値に対して実行されてもよい。状態決定ツリーの結果２１８は、デバイスの状態のテキスト記述を規定するノードを特定する。
【００４９】
図３は、デバイス状態を決定するためのデータ構造の図である。図示されるように、ツリー３００のセットは、１以上の個々のツリー３０２を有する。各ツリー３０２はノード３０４又はツリーユニットを有し、各ノードは１以上のクエリ３１２、アサインメント３１４及びテスト３１６を有する。一実施例では、少なくとも１つのクエリと少なくとも１つのテストとを含むツリーユニットのコレクションは、単一のノードとして一緒にグループ化される。他の実施例では、すべての非リーフノードは、少なくとも１つのクエリと少なくとも１つのテストとを含む。
【００５０】
クエリは、１以上の規定されたプロトコルを用いてモニタされているデバイスに送信される。アサインメントは、クエリのレスポンスにおいて規定されたものなど、ＳｔｒｉｐＰｒｅｆｉｘ、ＳｔｒｉｐＰｒｅｆｉｘＳｔａｒｔｓＷｉｔｈ、ＳｔｒｉｐＳｕｆｆｉｘ、ＳｔｒｉｐＳｕｆｆｉｘＳｔａｒｔｓＷｉｔｈ、Ｐｒｅｐｅｎｄ及び／又はＡｐｐｅｎｄなどの値に対する演算を実行するための１以上の値修飾子３１８を含む。１以上のアサインメント３１４により処理されたレスポンスは、テスト３１６を受ける。図示された例では、テスト３１６は、主部自体がテストされている値であるか、又は主部がテストされている値を規定するパラメータの名前であるかなど、主部演算３２０を規定する。例えば、アサインメントは、レスポンスが値を規定するとき、キー値ペアの値に適用されてもよい。アサインメントはまた、他のノードによる以降の抽出のため、デバイスマネージメントアプリケーションによりキー値ペアを格納するようにしてもよい。他の例では、アサインメントは、状態決定ツリーの移動中に以前に規定された“ＣｙａｎＰａｇｅＣｏｕｎｔ”などのキーに基づき格納されている値に適用されてもよい。この場合、状態決定ツリーを移動するデバイスマネージメントアプリケーションは、“ＣｙａｎＰａｇｅＣｏｕｎｔ”と呼ばれるパラメータの格納されている値を検索する。一実施例では、アサインメントが状態決定ツリーのノード間でわたされる。他の実施例では、アサインメントはグローバルに定義される。
【００５１】
テスト３１６はまた、主部に適用する１以上の述部の値と１以上の述部演算３２２とを有する。一実施例では、述部演算は、主部と述部とを比較するための比較演算である。例えば、テストは、クエリに対する処理済みレスポンスの値が“ｉｄｌｅ”に等しいか、又は値が０２ｈより大きいかを決定するものであってもよい。他の述部演算の具体例として、ＩｓＮｕｌｌ、Ｃｏｎｔａｉｎｓ及びｓｔａｒｔｓＷｉｔｈがあげられる。レスポンスはまた、具体例に示されない他の述部演算を用いて処理されてもよい。
【００５２】
テスト３１６の結果に基づき、デバイスマネージメントアプリケーションは、ノード３０４の真のチャイルドノード又は偽のチャイルドノードへのポインタを用いてツリー３０２を移動する。一実施例では、チャイルドノードは、デバイスの状態を規定するリーフノードである。他の実施例では、チャイルドノードは、デバイス状態の決定前に行われる１以上の他のクエリと１以上の他のテストとを規定する。状態決定ツリー３０２の移動は、デバイスの状態を規定するリターン３１０をもたらす。
【００５３】
図４は、３レベルの一例となる状態決定ツリーの構成を示す。この例では、ルート４００とユニット４０２とは、ツリーの第１レベルを規定する。ユニット４０２は、０以上のクエリ、０以上のアサインメント及び１以上のテストを有する。この例では、テストは、真偽テストである。テスト結果が偽である場合、ツリーの移動はユニット４０２からユニット４０４に続く。テスト結果が真である場合、ツリーの移動はユニット４０２からユニット４０６に続く。ユニット４０４と４０６はそれぞれ、０以上のクエリ、０以上のアサインメント及び１以上のテストを規定する。状態決定ツリーの移動は、リーフノード４０８〜４１４の１つへのナビゲートを生じさせる。結果として得られたリーフノードは、デバイスの状態を規定する。
【００５４】
Ａｐｐｅｎｄｉｘ Ｂは、ＤＩＴ．ＸＭＬにより規定されるより複雑な状態決定ツリーの一例を示す。状態決定ツリーのノード（＜ＱＮｏｄｅ＞）は、クエリ（＜Ｑｕｅｒｉｅｓ＞）、アサインメント（＜Ａｓｓｉｇｎｍｅｎｔｓ＞）及びテスト（＜Ｔｅｓｔ＞）を規定する。クエリノードに移動すると、デバイスマネージメントアプリケーションは、クエリノードに関連付けされた１以上のクエリを実行する。アサインメントノードに移動すると、デバイスマネージメントアプリケーションは、アサインメントノードに関連付けされた何れかのアサインメントを適用する。テストノードに移動すると、デバイスマネージメントアプリケーションは、テストノードに関連付けされた何れかのテストを適用する。状態決定ツリーは、ルートノードから、クエリ及びテストを規定する中間ノードを介しデバイス状態を規定するリーフノードまで移動される。
【００５５】
一実施例では、デバイスマネージメントアプリケーションは、中央サーバからクエリ及びレスポンスに関連する状態に関する情報を受信する。例えば、当該情報は、サーバからデバイスマネージメントアプリケーションに通信されるテーブルに格納されてもよい。
【００５６】
図８Ａは、状態決定ツリーの構成及び更新に利用されるクエリレスポンスディクショナリの全体構成を示す。クエリレスポンスディクショナリは、デバイスへのクエリとデバイスからのレスポンスとに関連するデバイスの状態に関する情報を格納する。レスポンスは、デバイスが規定された状態にあって、規定されたクエリによりクエリされる場合にデバイスが実行するであろう実際のレスポンスである。クエリレスポンスディクショナリは、デバイスが構成又は修正中にアクセス可能であることが不要となるように、ツリーの構成又は修正中にデバイスをエミュレートするのに利用されてもよい。一実施例では、クエリレスポンスディクショナリは、デバイスのモデルに関する情報を必要としない。状態がクエリ及びレスポンスに関連付けされる限り、関連付けされた情報は状態決定ツリーを構成するのに利用されてもよい。
【００５７】
図８Ｂは、ＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）のための３つのクエリ、ＰＪＬ（Ｐｒｉｎｔｅｒ Ｊｏｂ Ｌａｎｇｕａｇｅ）のための２つのクエリ、ＰｏｓｔＳｃｒｉｐｔのための１つのクエリ、及びＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）のための１つのクエリを有する一例となるクエリレスポンスディクショナリを示す。一例では、ＨＴＴＰクエリは、レスポンスを導くためにデバイスによって、提供されるウェブサーバに対して発行される。
【００５８】
図８Ｃは、クエリのうちの４つがデバイスクラスへのデバイスの分類に利用可能な“ＩＤクエリ”又はクエリである１１個のクエリを有する一例となるクエリレスポンスディクショナリを示す。デバイスの分類は、選択されたデバイスのクラスに特化したデバイスインタラクションツリーの選択を可能にするものであってもよい。
【００５９】
他の実施例では、デバイスマネージメントアプリケーションは、デバイス上で観察された状態に関する情報をユーザから受信する。例えば、ユーザは、デバイスに関する識別情報を、デバイスについて観察された状態と共にユーザインタフェースを介し送信してもよい。これに応答して、デバイスマネージメントアプリケーションは、１以上のクエリによってデバイスに照会し、１以上のレスポンスを受信する。デバイスマネージメントアプリケーションは、状態情報に関連付けてクエリレスポンスペアを格納する。
【００６０】
状態決定ツリーを自動生成するための開示される技術は、ツリーのノードを決定するため、関連付けされた状態、クエリ及びレスポンスに関する既知の情報を組み合わせるための特定の技術に限定されるものでない。２つの可能な状態を備えた３デバイスシステムのシンプルな例では、パラメータＸが１であって、パラメータＹが１０であるとき、第１デバイスが状態Ａにあり、パラメータＸが１であって、パラメータＹが２０であるとき、第２デバイスが状態Ａにあり、パラメータＸが２であって、パラメータＹが１０であるとき、第３デバイスが状態Ａにある。パラメータＸが２であって、パラメータＹが２０であるとき、すべてのデバイスが状態Ｂにあると仮定する。一例となる状態決定ツリーは、まずデバイスにＸを照会し、Ｘが１であるかテストし、その後にデバイスにＹを照会し、Ｙが１０であるかテストする。これら２つのクエリとテストとの結果は、何れのデバイスがテストされているに関係なく、デバイスが状態Ａ又はＢにあるか決定するのに利用可能である。
【００６１】
さらに、類似情報の大文字、プリフィックス、サフィックス、値フォーマット及び他の表現の相違がツリーの同じノードにより表現されるように、クエリ及びパラメータのセットが一般化されてもよい。例えば、１つのノードは、パラメータの処理値が“ｉｄｌｅ”であるか、実際に受信したパラメータが“ｉｄｌｅ”であったか、“Ｉｄｌｅ”又は“ｉｄｌｅ”にマップされる他の文字列を決定するものであってもよい。
【００６２】
開示される技術によると、状態決定ツリーは、有用なものにするため、完全に最適化される必要はなく、又はまったく最適化される必要もない。例えば、１つのツリーは、２つのツリーが開示された技術を含むものであったとしても、他のツリーと同じデバイスの同一状態を決定するのに平均してより多くのクエリ及び／又はテストを必要とするものであってもよい。一実施例では、デバイスマネージメントアプリケーションは、平均的により少数のクエリ及び／又はテストによって、又はより小さなツリーを用いて、同じデバイスの同一状態を管理する他のバージョンのツリーをサーバ上で検出する。これに応答して、デバイスマネージメントアプリケーションは、他のバージョンのツリーをダウンロードし、前のバージョンのツリーを置換してもよい。他のバージョンは、デバイスの状態を決定するために他のツリーがまた正確であると判断されるまで、アクティブなツリーとして一時的に指定されてもよい。
【００６３】
他の実施例では、デバイスマネージメントアプリケーションのユーザは、他のバージョンのツリーを求めてもよい。ユーザは、他のバージョンのツリーをダウンロードし、ソフトウェアをコンパイル及びインストールし、又はデバイスマネージメントアプリケーションを実行するマシーンへの登録を更新する権限を有することなく、前のバージョンのツリーを置換してもよい。
【００６４】
一実施例では、デバイスマネージメントアプリケーションは、状態決定ツリーがネットワーク内のデバイスの状態を提供できないことを検出したことに応答して、状態決定ツリーを更新する。例えば、デバイスマネージメントアプリケーションは、サポートされていないデバイスがネットワークに追加されたこと、又は要求されたタイプの状態情報が状態決定ツリーにすでに表現されるデバイスについてサポートされていないことを検出するようにしてもよい。更新された状態決定ツリーは、デバイスマネージメントアプリケーションのコードを修正することなく、以前には未サポートのデバイスをサポートする。
【００６５】
図９Ａ及び９Ｂは、状態決定ツリーへの更新をトリガするための他の一例となる技術であり、１つは自動的なものであり、１つは手動によるものを示す。図９Ａの一例となる自動更新技術に示されるように、ツリー９００〜９０４の少なくとも１つの実行９０６は、未知のクラスの新たなデバイス９１０Ａの状態を提供することができない。この失敗を検出したことに応答して、デバイスマネージメントアプリケーションは、状態決定ツリーへの更新９０８Ａを要求する。図９Ｂにおいて、人間によるオペレータ９１２が、未知のクラスの新たなデバイス９１０Ａの存在を検出する。新たなデバイス９１０Ａの存在を検出することに基づき、オペレータは状態決定ツリーへの更新を要求する。
【００６６】
図１０Ａ及び１０Ｂは、状態決定ツリーへの更新を取得するための他の一例となる技術を示す。図１０Ａにおいて、デバイスモニタシステム１０００Ａは、新たなデバイスをサポートする更新を取得するため、デバイス記述１００２を中央サーバ１００４に送信する。図示されるように、中央サーバ１００４は、クエリレスポンスディクショナリ１００６などのクエリ及びレスポンスに関連する状態に関する情報を提供することによって、リクエストに応答する。図示しない実施例では、中央サーバは、状態決定ツリーをデバイスモニタシステム１０００Ａに直接提供する。中央サーバから新たに提供された情報は、デバイスモニタシステム１０００Ａが以前にサポートされていたクラスのデバイスと新たなデバイスとを区別することを可能にする。
【００６７】
図１０Ｂの例では、人間のオペレータ１０１０に、状態情報１００８を提供するためのインタフェースが示される。人間のオペレータ１０１０は、状態情報１０１２をデバイスモニタシステム１０００Ｂに提供するため、インタフェースとやりとりする。デバイスモニタシステムは、デバイスにクエリを送信し、送信されたクエリとデバイスから受信したレスポンスとに関連付けて状態を格納する。他の実施例では、ユーザはまた、ユーザに既知の関連付けされたクエリ及びレスポンス情報を入力する。
【００６８】
図１１は、状態決定ツリーの処理に関する一例となるステップを示すフローチャートである。未サポートのデバイスのために失敗すると、失敗前のノードの身元が、以前にはサポートされていないデバイスをサポートする新たな状態決定データによって状態決定ツリーを更新するのに利用可能である。図１１に示されるように、クライアントは、ステップ１１０２において、デバイスモニタから新たなデバイスに関するデータをリクエストする。ステップ１１０４において、デバイスモニタは、状態決定ツリーを処理し、リクエストされたデータを取得するため、ツリー移動ファンクションを呼び出す。判定ステップ１１０６において、実行が成功したか判断される。実行が成功しなかった場合、ステップ１１０８において、失敗したノードの身元がクライアントにリターンされる。これに応答して、ステップ１１１０において、クライアントは、ツリーに追加すべきノードをリターンする。デバイスモニタは、ステップ１１１２において、ツリーの失敗したノードの前に新たな状態決定ノードを追加し、ステップ１１１４において、配置された新たなノードによりツリーを再実行する。
【００６９】
ステップ１１０６において判定されるように、実行が成功した場合、ステップ１１１６において、リクエストされたデータはクライアントにリターンされる。クライアントは、ステップ１１１８において、リターンされたデータを検証する。データが正確でない場合、失敗したノードの身元がクライアントにリターンされ、処理はステップ１１１０に進む。そうでない場合、データはツリーから良好に抽出され、クライアントにより検証され、当該処理はステップ１１２２において終了する。
【００７０】
図１２は、一時的更新機能を備えた一例となるデバイスクエリ処理を示す。ステップ１２０２において、クライアントは、デバイスモニタ１２０２から新たなデバイスに関するデータをリクエストする。デバイスモニタは、ステップ１２０４において、リクエストされたデータを取得するため、Ｔｒｅｅを実行する。ステップ１２０６において、実行が成功したか判断される。実行が成功しなかった場合、ステップ１２０８〜１２１０に反映されるように、失敗したノードの身元がクライアントにリターンされ、クライアントはツリーに追加すべきノードをリターンする。デバイスモニタは、ステップ１２１２において、前の実行から残っている一時的ノードを破棄し、ステップ１２１４において、ツリーの失敗したノードの前に新たなノードを一時的に追加する。ステップ１２１６において、現在配置された一時的なノードによって、ツリーが再実行される。
【００７１】
ステップ１２０６において実行が成功した場合、ステップ１２１８において、リクエストされたデータはクライアントにリターンされる。ステップ１２２０において、クライアントは、リターンされたデータを検証する。データが検証され、ステップ１２２４において判断されるように、ツリーに一時的ノードがあった場合、ステップ１２２６において、デバイスモニタは、一時的ノードを永続的なものにする。
【００７２】
図１３は、サーバから配布されたクエリレスポンスディクショナリに基づく他の一例となる更新処理を示す。ステップ１３０２において、クライアントは、新たなデバイスのモデルやメーカー名などの識別情報を中央サーバに送信する。ステップ１３０４において、中央サーバは、クエリレスポンスディクショナリ（ＱＲＤ）をクライアントに送り返す。クライアントは、ステップ１３０６において、デバイスモニタのＡｄｄＤｅｖｉｃｅメソッドを実行し、提供されたＱＲＤを用いてデバイスをツリーに追加する。ステップ１３０８において、デバイスモニタは、新たなデバイスのＱＲＤからのデータによって状態決定ツリーを更新する。
［デバイスインタラクションツリーの利用］
一実施例では、デバイスの状態に対するリクエストが、１以上の計算装置とのインタフェースにより受信される。当該リクエストは、デバイスの１以上の属性を特定するものであってもよい。他の実施例では、リクエストは、デバイスが属するワークグループと名前とによってデバイスを特定する。１以上の計算装置上のデバイスインタラクションロジックは、デバイスインタラクションツリーを用いて、ツリーのスタートノードに関連付けされたクエリとテストとを決定するよう構成される。クエリはデバイスに送信され、レスポンスがデバイスから受信される。一実施例では、テスト段階前に、レスポンスは、スタートノードに関連付けされた１以上のアサインメントに従って、デバイスインタラクションロジックによって処理される。他の実施例では、レスポンスは、処理することなく受信されたままテストされる。レスポンスは、ツリーのスタートノードに関連付けされたテストを用いてテストされる。当該テストは、レスポンスを評価するため、１以上の値と１以上の演算とを規定する。一実施例では、１以上のアサインメントは、テストの結果として以降のノードのために値を格納又は準備するため実行されてもよい。テストの結果に基づき、デバイスモニタリングロジックツリーは、リーフノードに向かって移動される。一例では、リーフノードは、デバイスの状態を表す。各種実施例では、スタートノードは、複数のブランとの何れがツリーにおいて移動されるか決定するため、クエリとテストの系列とによるノードの集合によって表されてもよい。
【００７３】
ツリーの次のノードがリーフノードである場合、リーフノードにより規定される状態がデバイスの状態となる。一実施例では、次のノードは、移動における第２ノードである。第２ノードがリーフノードでない場合、第２クエリと第２テストとがツリーの第２ノードから決定される。デバイスは、第２レスポンスを導くため次のクエリにより照会される。第２レスポンスは、ツリーの第２ノードに関連付けされた何れかのアサインメントに従って処理されてもよい。レスポンスは、ツリーの移動における次の又は第３ノードを決定するため、第２テストに対して評価される。一実施例では、第３ノードは、スタートノードと第２ノードと同様にして処理される。他のノードが移動のパス上にあってもよく、デバイスの状態を規定するリーフノードへの移動をもたらす。
【００７４】
状態決定ロジックは、リクエストに応答してデバイスの状態を提供する。例えば、状態決定ロジックは、ユーザインタフェース上でデバイスの状態をリクエストするユーザに、デバイスの状態のテキスト及び／又は画像説明又は表現を表示する。例えば、状態決定ロジックは、アイドル状態に関連付けされたアイコンと共に、“ｉｄｌｅ”を表示するようにしてもよい。
【００７５】
一実施例では、ツリーを移動するためのデバイスインタラクションロジックは、ツリーのコンテンツに関して汎用的なものである。すなわち、デバイスインタラクションロジックは、あるネットワーク上の特定のデバイスについて特別に構成される必要はない。例えば、状態決定ロジックは、あるネットワーク上のデバイスの状態を決定するため特別に構成される必要はない。一実施例では、デバイスインタラクションロジックは、ツリーを移動するため１以上の計算装置により実行される格納されている命令を含む。他の実施例では、デバイスインタラクションロジックは、１以上の計算装置にツリーを移動させる１以上の特殊なハードウェアコンポーネントを用いて構成されてもよい。
【００７６】
Ａｐｐｅｎｄｉｘ Ｂは、ツリーのＤＩＴ．ＸＭＬ．Ｎｏｄｅｓ（＜ＱＮｏｄｅ＞）により規定される一例となる状態決定ツリーがクエリ（＜Ｑｕｅｒｉｅｓ＞）、アサインメント（＜Ａｓｓｉｇｎｍｅｎｔｓ＞）及びテスト（＜Ｔｅｓｔ＞）を規定することを示す。ノードに移動すると、デバイスマネージメントアプリケーションは、ノードに関連付けされた１以上のクエリを実行し、ノードに関連付けされた何れかのアサインメントを適用し、ノードに関連付けされたテストによってクエリへのレスポンスをテストする。
【００７７】
ＤＩＴ．ＸＭＬによる一例では、デバイスマネージメントアプリケーションは、ユーザからデバイス状態に対するリクエストを受信し、“＜Ｑｕｅｒｙ ｐｒｏｔｏｃｏｌ＝”ｓｎｍｐ“ ｍｅｓｓａｇｅ＝”ｐｒｔＡｌｅｒｔＣｏｄｅ“ ｒｅｓｐｏｎｓｅＫｅｙ＝”ＡｌｅｒｔＣｏｄｅ“／＞”によるクエリを規定し、“＜Ｔｅｓｔ ｓｕｂｊｅｃｔ＝”ＡｌｅｒｔＣｏｄｅ“ ｓｕｂｊｅｃｔＯｐ＝”ｖａｌｕｅＯｆ“ ｐｒｅｄｉｃａｔｅ＝”ｓｕｂｕｎｉｔＭｉｓｓｉｎｇ“ ｐｒｅｄｉｃａｔｅＯｐ＝“ｅｑｕａｌｓ”／＞“のテストにより結果をテストするＱＮｏｄｅに状態決定ツリーを移動する。すなわち、デバイスマネージメントアプリケーションは、メッセージ”ｐｒｔＡｌｅｒｔＣｏｄｅ“によってＳＮＭＰクエリをデバイスに送信する。デバイスマネージメントアプリケーションは、”ＡｌｔｅｒＣｏｄｅ“としてデバイスからのレスポンスを保存する。その後、デバイスマネージメントアプリケーションは、ＡｌｅｒｔＣｏｄｅの値が”ｓｕｂｕｎｉｔＭＩｓｓｉｎｇ“に等しいか評価するためテストを利用する。
【００７８】
テストの結果が真である場合、デバイスマネージメントアプリケーションは、他のＱＮｏｄｅのブランチへのデバイスインタラクションツリーの移動を続ける。移動におけるこのポイントにおいて、デバイスマネージメントアプリケーションは、ＰｒｉｎｔｅｒＳｔａｔｕｓが“ｉｄｌｅ”であり、ＤｅｖｉｃｅＳｔａｔｕｓが“ｗａｒｎｉｎｇ”であり、ＡｌｅｒｔＣｏｄｅが“ｓｕｂｕｎｉｔＭｉｓｓｉｎｇ”であると決定した。デバイスマネージメントアプリケーションは、“ｐｒｔＡｌｅｒｔＧｒｏｕｐ”のメッセージによるＳＮＭＰクエリによって再びデバイスに照会する。レスポンスは、“ＡｌｅｒｔＧｒｏｕｐ”として保存される。この結果は、“＜Ｔｅｓｔ ｓｕｂｊｅｃｔ＝”ＡｌｅｒｔＣｏｄｅ“ ｓｕｂｊｅｃｔＯｐ＝”ｖａｌｕｅＯｆ“ ｐｒｅｄｉｃａｔｅ＝”ｉｎｐｕｔ“ ｐｒｅｄｉｃａｔｅＯｐ＝“ｅｑｕａｌｓ”／＞“によりテストされる。すなわち、デバイスマネージメントアプリケーションは、結果の値が”ｉｎｐｕｔ“に等しいか判断する。等しい場合、デバイスマネージメントアプリケーションは、アサインメント”＜Ｓｅｔ ｋｅｙ＝“ＳｔａｔｕｓＮａｍｅ” ｖａｌｕｅ＝“ｅｒｒｏｒ”／＞“及び”＜Ｓｅｔ ｋｅｙ＝“ＥｒｒｏｒＮａｍｅ” ｖａｌｕｅ＝“Ｎｏｉｎｐｕｔｔｒａｙ”／＞“に基づき、デバイスの状態を決定する。従って、デバイスマネージメントアプリケーションは、”Ｅｒｒｏｒ：Ｎｏ Ｉｎｐｕｔ Ｔｒａｙ“によりデバイス状態に対するリクエストに応答する。
【００７９】
図１４は、一例となる状態決定ツリーを移動する一例となる処理を示すフローチャートである。当該処理は、１以上の格納されている状態決定ツリーを用いてネットワーク上のデバイスの状態を取得するデバイスマネージメントアプリケーションにより実行される。デバイスマネージメントアプリケーションは、状態決定ツリーのクエリ、アサインメント及びテスト及びテストにより規定されるルールに従うよう一般に構成されてもよい。図示されないアサインメントステートメントは、デバイスから受信されたレスポンスに基づき、パラメータに値を割り当てるためデバイスインタラクションツリーに含まれる。割り当てられた値は、図示されるような比較ステップにおいて利用される。デバイスマネージメントアプリケーションは、所与のネットワーク又は所与のデバイスインタラクションツリーについて特別に構成される必要はない。当該処理を進めるデバイスインタラクションツリーは、ソフトウェアをインストールしたり、デバイスのレジストリを修正するためのセキュリティ権限を有さないユーザによって、生成、更新及び置換されてもよい。一実施例では、状態決定ツリーなどのデバイスインタラクションツリーは自ら実行するソフトウェアを有さないため、デバイスインタラクションツリーは、それらが保存されるシステムのセキュリティを危険にさらすものでない。
［デバイスコンフィギュレーションツリー］
一実施例では、デバイスインタラクションツリーはデバイスコンフィギュレーションツリーである。デバイスマネージメントアプリケーションなどのデバイスインタラクションロジックは、デバイスを設定するためデバイスコンフィギュレーションツリーを移動するよう構成される。一実施例では、ユーザは、デバイスに関するパラメータを設定するためのリクエストを送信する。デバイスインタラクションロジックは、このリクエストを受信し、デバイスセットの何れかのデバイスに関するパラメータを設定するため、デバイスコンフィギュレーションツリーを選択する。デバイスインタラクションロジックは、ロートノードからクエリ及びテストを規定する中間ノードまでデバイスコンフィギュレーションツリーを移動する。デバイスインタラクションロジックは、デバイスに送信するコンフィギュレーションコマンドを規定するリーフノードに到達するため、クエリの結果に対してテストを適用する。デバイスコンフィギュレーションツリーは、コンフィギュレーションコマンドがデバイスに良好に送信されたか判断するため、１以上のさらなるコマンドを規定してもよい。
【００８０】
例えば、ユーザは、デバイスの名前を変更するようリクエストしてもよい。当該リクエストは、ＩＰアドレスによりデバイスを特定し、またデバイスの新たな名前を規定してもよい。リクエストに基づき、デバイスインタラクションロジックは、デバイスの名前を変更するため、デバイスコンフィギュレーションツリーを選択する。デバイスインタラクションロジックは、デバイスコンフィギュレーションツリーを移動し、１以上のクエリを送信し、クエリの１以上のレスポンスに１以上のテストを適用する。デバイスコンフィギュレーションツリーを移動すると、デバイスインタラクションロジックは、デバイスの名前を変更するためのコマンドを規定するリーフノードに到達する。デバイスインタラクションロジックは、当該コマンドをデバイスに送信する。任意的には、デバイスコンフィギュレーションツリーは、デバイスの名前がコマンドによって良好に変更されたか判断するため、１以上の他のクエリと１以上の他のテストとを規定する。コマンドを送信するか、又はコマンドがデバイスに関するパラメータを良好に変更したことを確認したことに応答して、デバイスインタラクションロジックは、デバイスの名前が変更されたという表示をユーザに示す。
【００８１】
他の各種設定変更が、デバイスコンフィギュレーションツリーを用いてデバイスになされてもよい。例えば、デバイスコンフィギュレーションツリーは、デバイスのタイムアウト値を変更するためのコマンド、又はデバイスがスタートアップするとテストページが印刷されるか指示する設定を変更するためのコマンドを規定してもよい。デバイスコンフィギュレーションツリーを生成及び利用するための技術は、何れか特定タイプの設定変更に限定されず、各種コンフィギュレーションツリーが、デバイスに送信する設定コマンドを決定するのに利用されてもよい。一実施例では、デバイスコンフィギュレーションツリーは、自己実行可能なコードを含まない。また、デバイスインタラクションロジックは、何れかのデバイスのパラメータを変更するため特別に構成されることなく、デバイスコンフィギュレーションツリーを移動するよう汎用的に構成されてもよい。一実施例では、コンフィギュレーションツリーは、異なるタイプのデバイス、異なる機能を備えたデバイス、及び／又は同一の設定変更を実現するため異なる設定コマンドを要求する異なるメーカーからのデバイスを設定するためのクエリ、テスト及び設定コマンドを規定する。
［デバイスアクションツリー］
一実施例では、デバイスインタラクションツリーは、デバイスアクションツリーである。デバイスマネージメントアプリケーションなどのデバイスインタラクションロジックは、デバイスにアクションを実行させるためデバイスアクションツリーを移動するよう構成される。一実施例では、ユーザは、デバイスにアクションを実行させるためのリクエストを送信する。デバイスインタラクションロジックは、当該リクエストを受信し、デバイスセットの何れかのデバイス上でアクションを実行させるためのデバイスアクションツリーを選択する。デバイスインタラクションロジックは、ルートノードからクエリ及びテストを規定する中間ノードまでデバイスアクションツリーを移動する。デバイスインタラクションロジックは、デバイスに送信するアクションコマンドを規定するリーフノードに到達するため、クエリの結果にテストを適用する。デバイスコンフィギュレーションツリーは、アクションコマンドがデバイスによって良好に実行されたか判断するため１以上のさらなるコマンドを規定してもよい。
【００８２】
例えば、ユーザは、指定されたフォーマットに従って文書を印刷するようリクエストしてもよい。当該リクエストは、ＩＰアドレスによりデバイスを特定し、また文書及び所望のフォーマットを指定してもよい。当該リクエストに基づき、デバイスインタラクションロジックは、デバイス上で文書を印刷するためのデバイスアクションツリーを選択する。デバイスインタラクションロジックは、デバイスアクションツリーを移動し、１以上のクエリを送信し、クエリの１以上のレスポンスに１以上のテストを適用する。デバイスアクションツリーを移動すると、デバイスインタラクションロジックは、指定されたフォーマットに従って文書を印刷するためのコマンドを規定するリーフノードに到達する。デバイスインタラクションロジックは、コマンドをデバイスに送信する。任意的には、デバイスコンフィギュレーションツリーは、デバイスが指定されたフォーマットにより文書を印刷するのに成功したか判断するため、１以上の他のクエリと１以上の他のテストとを規定する。アクションコマンドを送信するか、又はアクションコマンドが良好に実行されたことを確認したことに応答して、デバイスインタラクションロジックは、デバイスが指定されたフォーマットにより文書を印刷したという表示をユーザに示す。
【００８３】
他の各種アクションコマンドが、デバイスアクションツリーを利用してデバイスに送信されてもよい。例えば、デバイスアクションツリーは、デバイスにファックス、電子メール又はテキストメッセージを送信させるためのコマンド、又はデバイスにコピーさせ、テストページを印刷させ、又はクリーニング処理を実行させるためのコマンドを規定してもよい。デバイスアクションツリーを生成及び利用するための技術は、何れか特定タイプのアクションに限定されず、各種アクションツリーが、デバイスに送信するアクションコマンを決定するのに利用されてもよい。一実施例では、デバイスアクションツリーは、自己実行可能なコードを含まない。また、デバイスインタラクションロジックは、何れかのデバイス上でアクションを実行させるよう特別に構成されることなく、デバイスアクションツリーを移動するよう汎用的に構成されてもよい。一実施例では、アクションツリーは、異なるタイプのデバイス、異なる機能を備えたデバイス、及び／又は同一のアクションを実行するため異なるアクションコマンドを要求する異なるメーカーからのデバイスによってアクションを実行させるためのクエリ、テスト及び設定コマンドを規定する。
［実現機構］
一実施例によると、開示された技術は１以上の特定用途計算装置により実現される。特定用途計算装置は、当該技術を実行するため配線が組み込まれ、又は当該技術を実行するため永続的にプログラムされた１以上のＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ−Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）又はＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）などのデジタル電子デバイスを有し、又はファームウェア、メモリ、他のストレージ若しくは組み合わせのプログラム命令に従って当該技術を実行するようプログラムされた１以上の汎用ハードウェアプロセッサを有してもよい。このような特定用途計算装置はまた、カスタム配線論理、ＡＳＩＣ又はＦＰＧＡを当該技術を実現するためのカスタムプログラミングと組み合わせるようにしてもよい。特定用途計算装置は、デスクトップコンピュータシステム、ポータブルコンピュータシステム、携帯デバイス、ネットワーキングデバイス又は当該技術を実現するための配線及び／又はプログラム論理を搭載した他の何れかのデバイスであってもよい。
【００８４】
例えば、図１５は、本発明の実施例が実現されるコンピュータシステム１５００を示すブロック図である。コンピュータシステム１５００は、情報を通信するためのバス１５０２又は他の通信機構と、情報を処理するためバス１５０２に接続されたハードウェアプロセッサ１５０４とを有する。ハードウェアプロセッサ１５０４は、例えば、汎用マイクロプロセッサであってもよい。
【００８５】
コンピュータシステム１５００はまた、プロセッサ１５０４により実行される命令及び情報を格納するため、バス１５０２に接続されたＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）や他のダイナミックストレージデバイスなどのメインメモリ１５０６を有する。メインメモリ１５０６はまた、プロセッサ１５０４により実行される命令の実行中に一時的変数や他の中間情報を格納するのに利用されてもよい。このような命令は、プロセッサ１５０４にアクセス可能な非一時的記憶媒体に格納されると、コンピュータシステム１５００を命令に指示される処理を実行するようカスタマイズされた特定用途マシーンに変換する。
【００８６】
コンピュータシステム１５００はさらに、プロセッサ１５０４のための静的情報及び命令を格納するため、バス１５０２に接続されたＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１５０８や他のスタティックストレージデバイスを有する。磁気ディスクや光ディスクなどの記憶装置１５１０が設けられ、情報及び命令を格納するためバス１５０２に接続される。
【００８７】
コンピュータシステム１５００は、コンピュータユーザに情報を表示するため、バス１５０２を介しＣＲＴ（Ｃａｔｈｏｄｅ Ｒａｙ Ｔｕｂｅ）などのディスプレイ１５１２に接続されてもよい。英数字及び他のキーを含む入力装置１５１４が、プロセッサ１５０４に情報及びコマンド選択を通信するため、バス１５０２に接続される。他のタイプのユーザ入力装置は、指示情報及びコマンド選択をプロセッサ１５０４に通信し、ディスプレイ１５１２上のカーソルの動きを制御するため、マウス、トラックボール又はカーソル方向キーなどのカーソル制御１５１６である。この入力装置は、典型的には、デバイスが平面上の位置を指定することを可能にする第１軸（ｘなど）と第２軸（ｙなど）の２つの軸の２つの自由度を有する。
【００８８】
コンピュータシステム１５００は、コンピュータシステム１５００を特定用途マシーンにする又はプログラムする、カスタマイズされた配線論理、１以上のＡＳＩＣ又はＦＰＧＡ、ファームウェア及び／又はプログラムロジックを用いて、開示された技術を実現してもよい。一実施例によると、当該技術は、プロセッサ１５０４がメインメモリ１５０６に含まれる１以上の命令の１以上のシーケンスを実行することに応答して、コンピュータシステム１５００により実行される。このような命令は、ストレージデバイス１５１０などの他の記憶媒体からメインメモリ１５０６に読み込まれてもよい。メインメモリ１５０６に含まれる命令シーケンスの実行は、プロセッサ１５０４に開示された方法の各ステップを実行させる。他の実施例では、配線回路が、ソフトウェア命令の代わりに又は一緒に利用されてもよい。
【００８９】
ここで用いられる“記憶媒体”という用語は、マシーンを特定の方法で実行させるデータ及び／又は命令を格納する何れかの非一時的媒体を表す。このような記憶媒体は、不揮発性媒体及び／又は揮発性媒体から構成されてもよい。不揮発性媒体は、例えば、ストレージデバイス１５１０などの光又は磁気ディスクなどを含む。揮発性媒体は、メインメモリ１５０６などのダイナミックメモリを含む。記憶媒体の通常形態は、例えば、フロッピー（登録商標）ディスク、フレキシブルディスク、ハードディスク、ソリッドステートドライブ、磁気テープ、他の何れかの磁気データ記憶媒体、ＣＤ−ＲＯＭ、他の何れかの光データ記憶媒体、ホールパターンによる何れかの物理媒体、ＲＡＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＦＬＡＳＨ−ＥＰＲＯＭ、ＮＶＲＡＭ、他の何れかのメモリチップ又はカートリッジなどを含む。
【００９０】
記憶媒体は、伝送媒体と異なるものであるが、これと共に利用されてもよい。伝送媒体は、記憶媒体の間の情報の伝送に用いられる。例えば、伝送媒体は、バス１５０２を構成する配線を含む同軸ケーブル、銅線及び光ファイバを含む。伝送媒体はまた、無線波及び赤外線データ通信中に生成されるものなど、音響波又は光波の形態をとることも可能である。
【００９１】
各種形態の媒体が、実行のためプロセッサ１５０４に１以上の命令の１以上のシーケンスを担持することに関する。例えば、これらの命令は、リモートコンピュータの磁気ディスク又はソリッドステートドライブ上に初期的には担持されてもよい。リモートコンピュータは、それのダイナミックメモリに命令をロードし、モデムを用いて電話線により命令を送信することが可能である。コンピュータシステム１５００にローカルなモデムは、電話線によりデータを受信し、データを赤外線信号に変換するため、赤外線送信機を利用することができる。赤外線検出装置が、赤外線信号により搬送されたデータを受信し、適切な回路が、当該データをバス１５０２に配置することができる。バス１５０２は、データをメインメモリ１５０６に搬送し、そこからプロセッサ１５０４は命令を抽出及び実行する。メインメモリ１５０６により受信された命令は、任意的には、プロセッサ１５０４による実行前後にストレージデバイス１５１０に格納されてもよい。
【００９２】
コンピュータシステム１５００はまた、バス１５０２に接続された通信インタフェース１５１８を有する。通信インタフェース１５１８は、ローカルネットワーク１５２２に接続されるネットワークリンク１５２０との双方向データ通信接続を提供する。例えば、通信インタフェース１５１８は、ＩＳＤＮ（Ｉｎｔｅｇｒａｔｅｄ Ｓｅｒｖｉｃｅｓ Ｄｉｇｉｔａｌ Ｎｅｔｗｏｒｋ）カード、ケーブルモデム、衛星モデム、又は対応するタイプの電話線とのデータ通信接続を提供するモデムであってもよい。他の例として、通信インタフェース１５１８は、互換性のあるＬＡＮとのデータ通信接続を提供するためのＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）カードであってもよい。無線リンクがまた実装されてもよい。このような何れかの実現形態では、通信インタフェース１５１８は、各種タイプの情報を表すデジタルデータストリームを搬送する電気、電磁気又は光信号を送受信する。
【００９３】
ネットワークリンク１５２０は、典型的には、１以上のネットワークを介し他のデータデバイスとのデータ通信を提供する。例えば、ネットワークリンク１５２０は、ローカルネットワーク１５２２を介しＩＳＰ（Ｉｎｔｅｒｎｅｔ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ）１５２６により運営されるデータ機器又はホストコンピュータ１５２４との接続を提供するものであってもよい。さらに、ＩＳＰ１５２６は、“インターネット”１５２８として一般に参照されるワールドワイドパケットデータ通信ネットワークを介しデータ通信サービスを提供する。ローカルネットワーク１５２２とインターネット１５２８とは共に、デジタルデータストリームを搬送する電気、電磁気又は光信号を利用する。各種ネットワークを介した信号と、ネットワークリンク１５２０及び通信インタフェース１５１８を介した信号とは、コンピュータシステム１５００に対してデジタルデータを搬送し、伝送媒体の一例となる形態である。
【００９４】
コンピュータシステム１５００は、ネットワーク、ネットワークリンク１５２０及び通信インタフェース１５１８を介し、プログラムコードを含むデータ及びメッセージを送受信することができる。インターネットの例では、サーバ１５３０は、インターネット１５２８、ＩＳＰ１５２６、ローカルネットワーク１５２２及び通信インタフェース１５１８を介しアプリケーションプログラムのためのリクエストされたコードを送信してもよい。
【００９５】
受信されたコードは、そのままプロセッサ１５０４により実行されてもよく、以降の利用のためストレージデバイス１５１０や他の不揮発性ストレージに格納されてもよい。
【００９６】
上述した明細書において、実現形態毎に可変的な多数の具体的詳細を参照して本発明の実施例が説明された。明細書及び図面は、限定的なものでなく例示的なものとしてみなされるべきである。本発明の範囲及び出願人が本発明の範囲であると意図するものは、何れか以降の補正を含む請求項に記載された特定の形態による請求項の文言上及び均等の範囲である。
【００９７】
【表１−１】
【表１−２】
【表２−１】
【表２−２】
【表３−１】
【表３−２】
【表３−３】
【表３−４】
【表３−５】
【表３−６】
【表３−７】
【表４−１】
【表４−２】
【表４−３】
【表４−４】
【表４−５】
【表４−６】
【表４−７】
【表４−８】
【表４−９】
【表４−１０】
【表４−１１】
【表４−１２】
【表４−１３】
【表４−１４】
【表４−１５】
【表４−１６】
【表４−１７】
【表４−１８】
【表４−１９】
【表４−２０】
【表４−２１】
【表４−２２】
【００９８】
以上、本発明の実施例について詳述したが、本発明は上述した特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【符号の説明】
【００９９】
１００ デバイスモニタシステム
１０２ 状態決定ツリー
１０４ デバイス情報
１０６ ファンクションライブラリ
１０８ ネットワーク
１１０ デバイス
【特許請求の範囲】
【請求項１】
複数のデバイスのデバイスの状態に対するリクエストを受信するステップと、
デバイスインタラクションツリーの特定のノードにより規定される特定のクエリと１以上の値を規定する特定のテストとを決定するステップであって、前記デバイスインタラクションツリーは、クエリとテストとを規定する中間ノードとデバイスの状態を規定するリーフノードとを有する、前記決定するステップと、
前記デバイスに前記特定のクエリを含む前記クエリの１以上を送信するステップと、
前記デバイスから前記特定のクエリに対する特定のレスポンスを含む前記１以上のクエリに対する１以上のレスポンスを受信するステップと、
前記１以上の値に対して前記特定のレスポンスを評価する前記特定のテストを前記特定のレスポンスに適用するステップと、
前記特定のテストを前記特定のレスポンスに適用した結果として、前記特定のノードから前記リーフノードの１以上に向かって前記デバイスインタラクションツリーを移動するステップと、
前記テストの１以上を前記１以上のレスポンスに適用し、前記デバイスインタラクションツリーのリーフノードの前記デバイスの状態を規定する特定のリーフノードに到達することによって、前記デバイスの状態を決定するステップと、
前記デバイスの状態に対するリクエストに応答して、前記デバイスの状態を提供するステップと、
を１以上の計算装置に実行させる命令を格納する非一時的コンピュータ可読記憶媒体。
【請求項２】
前記特定のクエリは、前記１以上のクエリの第１クエリであり、
前記特定のレスポンスは、前記１以上のレスポンスの第１レスポンスであり、
前記特定のテストは、前記１以上のテストの第１テストであり、
前記１以上の値は、１以上の第１の値であり、
前記特定のノードは、前記デバイスインタラクションツリーの第１ノードであり、
前記第１テストを前記第１レスポンスに適用した結果として、前記第１ノードから前記デバイスインタラクションツリーを移動するステップは、前記デバイスインタラクションツリーの第２ノードに向かって前記デバイスインタラクションツリーを移動することからなり、
前記命令は、
前記第２ノードに関連付けされた、第２クエリと１以上の第２の値を規定する第２テストとを決定するステップであって、前記クエリの１以上が前記第２クエリを含み、前記１以上のレスポンスが前記第２クエリに対する第２レスポンスを含む、前記決定するステップと、
前記１以上の第２の値に対する前記第２レスポンスを評価する前記第２テストを前記第２レスポンスに適用するステップと、
前記第２テストを前記第２レスポンスに適用した結果として、前記第２ノードから前記特定のリーフノードに向かって前記デバイスインタラクションツリーを移動するステップと、
を前記１以上の計算装置に実行させる、請求項１記載の非一時的コンピュータ可読記憶媒体。
【請求項３】
前記リクエストは、前記デバイスのアドレスを指定し、
前記１以上のクエリが、前記アドレスに送信され、
前記デバイスの状態は、動作状態、デバイス設定、又はデバイスエラーの１以上を含み、
前記クエリの１以上は、ＳＮＭＰクエリ、ＰＪＬクエリ、ＰｏｓｔＳｃｒｉｐｔクエリ又はＨＴＴＰクエリの１以上を含む、請求項１記載の非一時的コンピュータ可読記憶媒体。
【請求項４】
前記命令が前記１以上の計算装置により実行されると、デバイスマネージメントアプリケーションは、前記リクエストを受信するステップと、前記特定のクエリと前記特定のテストとを決定するステップと、前記１以上のクエリを送信するステップと、前記１以上のレスポンスを受信するステップと、前記特定のテストを適用するステップと、前記デバイスインタラクションツリーを移動するステップと、前記デバイスの状態を決定するステップと、前記デバイスの状態を提供するステップとを前記１以上の計算装置に実行させ、
前記命令は、前記デバイスマネージメントアプリケーションのコードを修正することなく前記デバイスインタラクションツリーを更新するステップを前記１以上の計算装置に実行させる、請求項１記載の非一時的コンピュータ可読記憶媒体。
【請求項５】
前記命令が前記１以上の計算装置により実行されると、デバイスマネージメントアプリケーションは、前記リクエストを受信するステップと、前記特定のクエリと前記特定のテストとを決定するステップと、前記１以上のクエリを送信するステップと、前記１以上のレスポンスを受信するステップと、前記特定のテストを適用するステップと、前記デバイスインタラクションツリーを移動するステップと、前記デバイスの状態を決定するステップと、前記デバイスの状態を提供するステップとを前記１以上の計算装置に実行させ、
前記命令は、
前記デバイスインタラクションツリーが前記複数のデバイスの特定のデバイスの特定の状態を提供できないことを検出するステップと、
前記デバイスインタラクションツリーが前記複数のデバイスの特定のデバイスの特定の状態を提供できないことを検出することに応答して、前記デバイスマネージメントアプリケーションのコードを修正することなく前記特定のデバイスをサポートするよう前記デバイスインタラクションツリーを更新するステップと、
を前記１以上の計算装置に実行させる、請求項１記載の非一時的コンピュータ可読記憶媒体。
【請求項６】
前記命令が前記１以上の計算装置により実行されると、デバイスマネージメントアプリケーションは、前記リクエストを受信するステップと、前記特定のクエリと前記特定のテストとを決定するステップと、前記１以上のクエリを送信するステップと、前記１以上のレスポンスを受信するステップと、前記特定のテストを適用するステップと、前記デバイスインタラクションツリーを移動するステップと、前記デバイスの状態を決定するステップと、前記デバイスの状態を提供するステップとを前記１以上の計算装置に実行させ、
前記命令は、
クエリ及びレスポンス情報に関連付けされた状態情報を受信するステップと、
前記デバイスマネージメントアプリケーションのコードを修正することなく前記クエリ及びレスポンス情報に関連付けされた状態情報をサポートするよう前記デバイスインタラクションツリーを更新するステップと、
を前記１以上の計算装置に実行させる、請求項１記載の非一時的コンピュータ可読記憶媒体。
【請求項７】
前記命令は、
ユーザインタフェース上で特定の状態が特定のデバイスについて観察されたという指示を受信するステップと、
前記特定のデバイスに特定のクエリを送信するステップと、
前記特定のクエリに対して特定のレスポンスを受信するステップと、
前記指示、前記特定のクエリ及び前記特定のレスポンスを有する情報セットに少なくとも部分的に基づき前記デバイスインタラクションツリーを更新するステップと、
を前記１以上の計算装置に実行させる、請求項１記載の非一時的コンピュータ可読記憶媒体。
【請求項８】
前記デバイスインタラクションツリーは、前記複数のデバイスの所与のデバイスについて、前記所与のデバイスの状態を規定するリーフノードを含み、
前記複数のデバイスは、異なる機能を備えた少なくとも２つのデバイス、異なる設定を備えた少なくとも２つのデバイス、異なるメーカーからの少なくとも２つのデバイス及び同一のクエリに異なって応答する同一のデバイスの状態を備えた少なくとも２つのデバイスを含む、請求項１記載の非一時的コンピュータ可読記憶媒体。
【請求項９】
１以上のプロセッサと、
複数のデバイスへの１以上のインタフェース及び前記複数のデバイスからの１以上のインタフェースと、
前記１以上のプロセッサ、前記複数のデバイスへの１以上のインタフェース及び前記複数のデバイスからの１以上のインタフェースと接続される計算論理と、
を有する計算装置であって、
前記計算論理は、
複数のデバイスのデバイスの状態に対するリクエストを受信するステップと、
デバイスインタラクションツリーの特定のノードにより規定される特定のクエリと１以上の値を規定する特定のテストとを決定するステップであって、前記デバイスインタラクションツリーは、クエリとテストとを規定する中間ノードとデバイスの状態を規定するリーフノードとを有する、前記決定するステップと、
前記デバイスに前記特定のクエリを含む前記クエリの１以上を送信するステップと、
前記デバイスから前記特定のクエリに対する特定のレスポンスを含む前記１以上のクエリに対する１以上のレスポンスを受信するステップと、
前記１以上の値に対して前記特定のレスポンスを評価する前記特定のテストを前記特定のレスポンスに適用するステップと、
前記特定のテストを前記特定のレスポンスに適用した結果として、前記特定のノードから前記リーフノードの１以上に向かって前記デバイスインタラクションツリーを移動するステップと、
前記テストの１以上を前記１以上のレスポンスに適用し、前記デバイスインタラクションツリーのリーフノードの前記デバイスの状態を規定する特定のリーフノードに到達することによって、前記デバイスの状態を決定するステップと、
前記デバイスの状態に対するリクエストに応答して、前記デバイスの状態を提供するステップと、
を実行するよう構成される計算装置。
【請求項１０】
前記特定のクエリは、前記１以上のクエリの第１クエリであり、
前記特定のレスポンスは、前記１以上のレスポンスの第１レスポンスであり、
前記特定のテストは、前記１以上のテストの第１テストであり、
前記１以上の値は、１以上の第１の値であり、
前記特定のノードは、前記デバイスインタラクションツリーの第１ノードであり、
前記第１テストを前記第１レスポンスに適用した結果として、前記第１ノードから前記デバイスインタラクションツリーを移動するステップは、前記デバイスインタラクションツリーの第２ノードに向かって前記デバイスインタラクションツリーを移動することからなり、
前記計算論理はさらに、
前記第２ノードに関連付けされた、第２クエリと１以上の第２の値を規定する第２テストとを決定するステップであって、前記クエリの１以上が前記第２クエリを含み、前記１以上のレスポンスが前記第２クエリに対する第２レスポンスを含む、前記決定するステップと、
前記１以上の第２の値に対する前記第２レスポンスを評価する前記第２テストを前記第２レスポンスに適用するステップと、
前記第２テストを前記第２レスポンスに適用した結果として、前記第２ノードから前記特定のリーフノードに向かって前記デバイスインタラクションツリーを移動するステップと、
を実行するよう構成される、請求項９記載の計算装置。
【請求項１１】
前記リクエストは、前記デバイスのアドレスを指定し、
前記１以上のクエリが、前記アドレスに送信され、
前記デバイスの状態は、動作状態、デバイス設定、又はデバイスエラーの１以上を含み、
前記クエリの１以上は、ＳＮＭＰクエリ、ＰＪＬクエリ、ＰｏｓｔＳｃｒｉｐｔクエリ又はＨＴＴＰクエリの１以上を含む、請求項９記載の計算装置。
【請求項１２】
前記計算論理はさらに、デバイスマネージメントアプリケーションに、前記リクエストを受信するステップと、前記特定のクエリと前記特定のテストとを決定するステップと、前記１以上のクエリを送信するステップと、前記１以上のレスポンスを受信するステップと、前記特定のテストを適用するステップと、前記デバイスインタラクションツリーを移動するステップと、前記デバイスの状態を決定するステップと、前記デバイスの状態を提供するステップとを実行させ、
前記計算論理はさらに、前記デバイスマネージメントアプリケーションのコードを修正することなく前記デバイスインタラクションツリーを更新するステップを実行するよう構成させる、請求項９記載の計算装置。
【請求項１３】
前記計算論理はさらに、デバイスマネージメントアプリケーションに、前記リクエストを受信するステップと、前記特定のクエリと前記特定のテストとを決定するステップと、前記１以上のクエリを送信するステップと、前記１以上のレスポンスを受信するステップと、前記特定のテストを適用するステップと、前記デバイスインタラクションツリーを移動するステップと、前記デバイスの状態を決定するステップと、前記デバイスの状態を提供するステップとを実行させ、
前記計算論理はさらに、
前記デバイスインタラクションツリーが前記複数のデバイスの特定のデバイスの特定の状態を提供できないことを検出するステップと、
前記デバイスインタラクションツリーが前記複数のデバイスの特定のデバイスの特定の状態を提供できないことを検出することに応答して、前記デバイスマネージメントアプリケーションのコードを修正することなく前記特定のデバイスをサポートするよう前記デバイスインタラクションツリーを更新するステップと、
を実行するよう構成させる、請求項９記載の計算装置。
【請求項１４】
前記計算論理はさらに、デバイスマネージメントアプリケーションに、前記リクエストを受信するステップと、前記特定のクエリと前記特定のテストとを決定するステップと、前記１以上のクエリを送信するステップと、前記１以上のレスポンスを受信するステップと、前記特定のテストを適用するステップと、前記デバイスインタラクションツリーを移動するステップと、前記デバイスの状態を決定するステップと、前記デバイスの状態を提供するステップとを実行させ、
前記計算論理はさらに、
クエリ及びレスポンス情報に関連付けされた状態情報を受信するステップと、
前記デバイスマネージメントアプリケーションのコードを修正することなく前記クエリ及びレスポンス情報に関連付けされた状態情報をサポートするよう前記デバイスインタラクションツリーを更新するステップと、
を実行するよう構成させる、請求項９記載の計算装置。
【請求項１５】
前記計算論理はさらに、
ユーザインタフェース上で特定の状態が特定のデバイスについて観察されたという指示を受信するステップと、
前記特定のデバイスに特定のクエリを送信するステップと、
前記特定のクエリに対して特定のレスポンスを受信するステップと、
前記指示、前記特定のクエリ及び前記特定のレスポンスを有する情報セットに少なくとも部分的に基づき前記デバイスインタラクションツリーを更新するステップと、
を実行するよう構成させる、請求項９記載の計算装置。
【請求項１６】
前記デバイスインタラクションツリーは、前記複数のデバイスの所与のデバイスについて、前記所与のデバイスの状態を規定するリーフノードを含み、
前記複数のデバイスは、異なる機能を備えた少なくとも２つのデバイス、異なる設定を備えた少なくとも２つのデバイス、異なるメーカーからの少なくとも２つのデバイス及び同一のクエリに異なって応答する同一のデバイスの状態を備えた少なくとも２つのデバイスを含む、請求項９記載の計算装置。
【請求項１７】
複数のデバイスのデバイスの状態に対するリクエストを受信するステップと、
デバイスインタラクションツリーの特定のノードにより規定される特定のクエリと１以上の値を規定する特定のテストとを決定するステップであって、前記デバイスインタラクションツリーは、クエリとテストとを規定する中間ノードとデバイスの状態を規定するリーフノードとを有する、前記決定するステップと、
前記デバイスに前記特定のクエリを含む前記クエリの１以上を送信するステップと、
前記デバイスから前記特定のクエリに対する特定のレスポンスを含む前記１以上のクエリに対する１以上のレスポンスを受信するステップと、
前記１以上の値に対して前記特定のレスポンスを評価する前記特定のテストを前記特定のレスポンスに適用するステップと、
前記特定のテストを前記特定のレスポンスに適用した結果として、前記特定のノードから前記リーフノードの１以上に向かって前記デバイスインタラクションツリーを移動するステップと、
前記テストの１以上を前記１以上のレスポンスに適用し、前記デバイスインタラクションツリーのリーフノードの前記デバイスの状態を規定する特定のリーフノードに到達することによって、前記デバイスの状態を決定するステップと、
前記デバイスの状態に対するリクエストに応答して、前記デバイスの状態を提供するステップと、
を有する、１以上の計算装置によって実行される方法。
【請求項１８】
前記リクエストは、前記デバイスのアドレスを指定し、
前記１以上のクエリが、前記アドレスに送信され、
前記デバイスの状態は、動作状態、デバイス設定、又はデバイスエラーの１以上を含み、
前記クエリの１以上は、ＳＮＭＰクエリ、ＰＪＬクエリ、ＰｏｓｔＳｃｒｉｐｔクエリ又はＨＴＴＰクエリの１以上を含む、請求項１７記載の方法。
【請求項１９】
デバイスマネージメントアプリケーションが、前記リクエストを受信するステップと、前記特定のクエリと前記特定のテストとを決定するステップと、前記１以上のクエリを送信するステップと、前記１以上のレスポンスを受信するステップと、前記特定のテストを適用するステップと、前記デバイスインタラクションツリーを移動するステップと、前記デバイスの状態を決定するステップと、前記デバイスの状態を提供するステップとを前記１以上の計算装置に実行させ、
当該方法はさらに、前記デバイスマネージメントアプリケーションのコードを修正することなく前記デバイスインタラクションツリーを更新するステップを有する、請求項１７記載の方法。
【請求項２０】
ユーザインタフェース上で特定の状態が特定のデバイスについて観察されたという指示を受信するステップと、
前記特定のデバイスに特定のクエリを送信するステップと、
前記特定のクエリに対して特定のレスポンスを受信するステップと、
前記指示、前記特定のクエリ及び前記特定のレスポンスを有する情報セットに少なくとも部分的に基づき前記デバイスインタラクションツリーを更新するステップと、
をさらに有する、請求項１７記載の方法。
【請求項１】
複数のデバイスのデバイスの状態に対するリクエストを受信するステップと、
デバイスインタラクションツリーの特定のノードにより規定される特定のクエリと１以上の値を規定する特定のテストとを決定するステップであって、前記デバイスインタラクションツリーは、クエリとテストとを規定する中間ノードとデバイスの状態を規定するリーフノードとを有する、前記決定するステップと、
前記デバイスに前記特定のクエリを含む前記クエリの１以上を送信するステップと、
前記デバイスから前記特定のクエリに対する特定のレスポンスを含む前記１以上のクエリに対する１以上のレスポンスを受信するステップと、
前記１以上の値に対して前記特定のレスポンスを評価する前記特定のテストを前記特定のレスポンスに適用するステップと、
前記特定のテストを前記特定のレスポンスに適用した結果として、前記特定のノードから前記リーフノードの１以上に向かって前記デバイスインタラクションツリーを移動するステップと、
前記テストの１以上を前記１以上のレスポンスに適用し、前記デバイスインタラクションツリーのリーフノードの前記デバイスの状態を規定する特定のリーフノードに到達することによって、前記デバイスの状態を決定するステップと、
前記デバイスの状態に対するリクエストに応答して、前記デバイスの状態を提供するステップと、
を１以上の計算装置に実行させる命令を格納する非一時的コンピュータ可読記憶媒体。
【請求項２】
前記特定のクエリは、前記１以上のクエリの第１クエリであり、
前記特定のレスポンスは、前記１以上のレスポンスの第１レスポンスであり、
前記特定のテストは、前記１以上のテストの第１テストであり、
前記１以上の値は、１以上の第１の値であり、
前記特定のノードは、前記デバイスインタラクションツリーの第１ノードであり、
前記第１テストを前記第１レスポンスに適用した結果として、前記第１ノードから前記デバイスインタラクションツリーを移動するステップは、前記デバイスインタラクションツリーの第２ノードに向かって前記デバイスインタラクションツリーを移動することからなり、
前記命令は、
前記第２ノードに関連付けされた、第２クエリと１以上の第２の値を規定する第２テストとを決定するステップであって、前記クエリの１以上が前記第２クエリを含み、前記１以上のレスポンスが前記第２クエリに対する第２レスポンスを含む、前記決定するステップと、
前記１以上の第２の値に対する前記第２レスポンスを評価する前記第２テストを前記第２レスポンスに適用するステップと、
前記第２テストを前記第２レスポンスに適用した結果として、前記第２ノードから前記特定のリーフノードに向かって前記デバイスインタラクションツリーを移動するステップと、
を前記１以上の計算装置に実行させる、請求項１記載の非一時的コンピュータ可読記憶媒体。
【請求項３】
前記リクエストは、前記デバイスのアドレスを指定し、
前記１以上のクエリが、前記アドレスに送信され、
前記デバイスの状態は、動作状態、デバイス設定、又はデバイスエラーの１以上を含み、
前記クエリの１以上は、ＳＮＭＰクエリ、ＰＪＬクエリ、ＰｏｓｔＳｃｒｉｐｔクエリ又はＨＴＴＰクエリの１以上を含む、請求項１記載の非一時的コンピュータ可読記憶媒体。
【請求項４】
前記命令が前記１以上の計算装置により実行されると、デバイスマネージメントアプリケーションは、前記リクエストを受信するステップと、前記特定のクエリと前記特定のテストとを決定するステップと、前記１以上のクエリを送信するステップと、前記１以上のレスポンスを受信するステップと、前記特定のテストを適用するステップと、前記デバイスインタラクションツリーを移動するステップと、前記デバイスの状態を決定するステップと、前記デバイスの状態を提供するステップとを前記１以上の計算装置に実行させ、
前記命令は、前記デバイスマネージメントアプリケーションのコードを修正することなく前記デバイスインタラクションツリーを更新するステップを前記１以上の計算装置に実行させる、請求項１記載の非一時的コンピュータ可読記憶媒体。
【請求項５】
前記命令が前記１以上の計算装置により実行されると、デバイスマネージメントアプリケーションは、前記リクエストを受信するステップと、前記特定のクエリと前記特定のテストとを決定するステップと、前記１以上のクエリを送信するステップと、前記１以上のレスポンスを受信するステップと、前記特定のテストを適用するステップと、前記デバイスインタラクションツリーを移動するステップと、前記デバイスの状態を決定するステップと、前記デバイスの状態を提供するステップとを前記１以上の計算装置に実行させ、
前記命令は、
前記デバイスインタラクションツリーが前記複数のデバイスの特定のデバイスの特定の状態を提供できないことを検出するステップと、
前記デバイスインタラクションツリーが前記複数のデバイスの特定のデバイスの特定の状態を提供できないことを検出することに応答して、前記デバイスマネージメントアプリケーションのコードを修正することなく前記特定のデバイスをサポートするよう前記デバイスインタラクションツリーを更新するステップと、
を前記１以上の計算装置に実行させる、請求項１記載の非一時的コンピュータ可読記憶媒体。
【請求項６】
前記命令が前記１以上の計算装置により実行されると、デバイスマネージメントアプリケーションは、前記リクエストを受信するステップと、前記特定のクエリと前記特定のテストとを決定するステップと、前記１以上のクエリを送信するステップと、前記１以上のレスポンスを受信するステップと、前記特定のテストを適用するステップと、前記デバイスインタラクションツリーを移動するステップと、前記デバイスの状態を決定するステップと、前記デバイスの状態を提供するステップとを前記１以上の計算装置に実行させ、
前記命令は、
クエリ及びレスポンス情報に関連付けされた状態情報を受信するステップと、
前記デバイスマネージメントアプリケーションのコードを修正することなく前記クエリ及びレスポンス情報に関連付けされた状態情報をサポートするよう前記デバイスインタラクションツリーを更新するステップと、
を前記１以上の計算装置に実行させる、請求項１記載の非一時的コンピュータ可読記憶媒体。
【請求項７】
前記命令は、
ユーザインタフェース上で特定の状態が特定のデバイスについて観察されたという指示を受信するステップと、
前記特定のデバイスに特定のクエリを送信するステップと、
前記特定のクエリに対して特定のレスポンスを受信するステップと、
前記指示、前記特定のクエリ及び前記特定のレスポンスを有する情報セットに少なくとも部分的に基づき前記デバイスインタラクションツリーを更新するステップと、
を前記１以上の計算装置に実行させる、請求項１記載の非一時的コンピュータ可読記憶媒体。
【請求項８】
前記デバイスインタラクションツリーは、前記複数のデバイスの所与のデバイスについて、前記所与のデバイスの状態を規定するリーフノードを含み、
前記複数のデバイスは、異なる機能を備えた少なくとも２つのデバイス、異なる設定を備えた少なくとも２つのデバイス、異なるメーカーからの少なくとも２つのデバイス及び同一のクエリに異なって応答する同一のデバイスの状態を備えた少なくとも２つのデバイスを含む、請求項１記載の非一時的コンピュータ可読記憶媒体。
【請求項９】
１以上のプロセッサと、
複数のデバイスへの１以上のインタフェース及び前記複数のデバイスからの１以上のインタフェースと、
前記１以上のプロセッサ、前記複数のデバイスへの１以上のインタフェース及び前記複数のデバイスからの１以上のインタフェースと接続される計算論理と、
を有する計算装置であって、
前記計算論理は、
複数のデバイスのデバイスの状態に対するリクエストを受信するステップと、
デバイスインタラクションツリーの特定のノードにより規定される特定のクエリと１以上の値を規定する特定のテストとを決定するステップであって、前記デバイスインタラクションツリーは、クエリとテストとを規定する中間ノードとデバイスの状態を規定するリーフノードとを有する、前記決定するステップと、
前記デバイスに前記特定のクエリを含む前記クエリの１以上を送信するステップと、
前記デバイスから前記特定のクエリに対する特定のレスポンスを含む前記１以上のクエリに対する１以上のレスポンスを受信するステップと、
前記１以上の値に対して前記特定のレスポンスを評価する前記特定のテストを前記特定のレスポンスに適用するステップと、
前記特定のテストを前記特定のレスポンスに適用した結果として、前記特定のノードから前記リーフノードの１以上に向かって前記デバイスインタラクションツリーを移動するステップと、
前記テストの１以上を前記１以上のレスポンスに適用し、前記デバイスインタラクションツリーのリーフノードの前記デバイスの状態を規定する特定のリーフノードに到達することによって、前記デバイスの状態を決定するステップと、
前記デバイスの状態に対するリクエストに応答して、前記デバイスの状態を提供するステップと、
を実行するよう構成される計算装置。
【請求項１０】
前記特定のクエリは、前記１以上のクエリの第１クエリであり、
前記特定のレスポンスは、前記１以上のレスポンスの第１レスポンスであり、
前記特定のテストは、前記１以上のテストの第１テストであり、
前記１以上の値は、１以上の第１の値であり、
前記特定のノードは、前記デバイスインタラクションツリーの第１ノードであり、
前記第１テストを前記第１レスポンスに適用した結果として、前記第１ノードから前記デバイスインタラクションツリーを移動するステップは、前記デバイスインタラクションツリーの第２ノードに向かって前記デバイスインタラクションツリーを移動することからなり、
前記計算論理はさらに、
前記第２ノードに関連付けされた、第２クエリと１以上の第２の値を規定する第２テストとを決定するステップであって、前記クエリの１以上が前記第２クエリを含み、前記１以上のレスポンスが前記第２クエリに対する第２レスポンスを含む、前記決定するステップと、
前記１以上の第２の値に対する前記第２レスポンスを評価する前記第２テストを前記第２レスポンスに適用するステップと、
前記第２テストを前記第２レスポンスに適用した結果として、前記第２ノードから前記特定のリーフノードに向かって前記デバイスインタラクションツリーを移動するステップと、
を実行するよう構成される、請求項９記載の計算装置。
【請求項１１】
前記リクエストは、前記デバイスのアドレスを指定し、
前記１以上のクエリが、前記アドレスに送信され、
前記デバイスの状態は、動作状態、デバイス設定、又はデバイスエラーの１以上を含み、
前記クエリの１以上は、ＳＮＭＰクエリ、ＰＪＬクエリ、ＰｏｓｔＳｃｒｉｐｔクエリ又はＨＴＴＰクエリの１以上を含む、請求項９記載の計算装置。
【請求項１２】
前記計算論理はさらに、デバイスマネージメントアプリケーションに、前記リクエストを受信するステップと、前記特定のクエリと前記特定のテストとを決定するステップと、前記１以上のクエリを送信するステップと、前記１以上のレスポンスを受信するステップと、前記特定のテストを適用するステップと、前記デバイスインタラクションツリーを移動するステップと、前記デバイスの状態を決定するステップと、前記デバイスの状態を提供するステップとを実行させ、
前記計算論理はさらに、前記デバイスマネージメントアプリケーションのコードを修正することなく前記デバイスインタラクションツリーを更新するステップを実行するよう構成させる、請求項９記載の計算装置。
【請求項１３】
前記計算論理はさらに、デバイスマネージメントアプリケーションに、前記リクエストを受信するステップと、前記特定のクエリと前記特定のテストとを決定するステップと、前記１以上のクエリを送信するステップと、前記１以上のレスポンスを受信するステップと、前記特定のテストを適用するステップと、前記デバイスインタラクションツリーを移動するステップと、前記デバイスの状態を決定するステップと、前記デバイスの状態を提供するステップとを実行させ、
前記計算論理はさらに、
前記デバイスインタラクションツリーが前記複数のデバイスの特定のデバイスの特定の状態を提供できないことを検出するステップと、
前記デバイスインタラクションツリーが前記複数のデバイスの特定のデバイスの特定の状態を提供できないことを検出することに応答して、前記デバイスマネージメントアプリケーションのコードを修正することなく前記特定のデバイスをサポートするよう前記デバイスインタラクションツリーを更新するステップと、
を実行するよう構成させる、請求項９記載の計算装置。
【請求項１４】
前記計算論理はさらに、デバイスマネージメントアプリケーションに、前記リクエストを受信するステップと、前記特定のクエリと前記特定のテストとを決定するステップと、前記１以上のクエリを送信するステップと、前記１以上のレスポンスを受信するステップと、前記特定のテストを適用するステップと、前記デバイスインタラクションツリーを移動するステップと、前記デバイスの状態を決定するステップと、前記デバイスの状態を提供するステップとを実行させ、
前記計算論理はさらに、
クエリ及びレスポンス情報に関連付けされた状態情報を受信するステップと、
前記デバイスマネージメントアプリケーションのコードを修正することなく前記クエリ及びレスポンス情報に関連付けされた状態情報をサポートするよう前記デバイスインタラクションツリーを更新するステップと、
を実行するよう構成させる、請求項９記載の計算装置。
【請求項１５】
前記計算論理はさらに、
ユーザインタフェース上で特定の状態が特定のデバイスについて観察されたという指示を受信するステップと、
前記特定のデバイスに特定のクエリを送信するステップと、
前記特定のクエリに対して特定のレスポンスを受信するステップと、
前記指示、前記特定のクエリ及び前記特定のレスポンスを有する情報セットに少なくとも部分的に基づき前記デバイスインタラクションツリーを更新するステップと、
を実行するよう構成させる、請求項９記載の計算装置。
【請求項１６】
前記デバイスインタラクションツリーは、前記複数のデバイスの所与のデバイスについて、前記所与のデバイスの状態を規定するリーフノードを含み、
前記複数のデバイスは、異なる機能を備えた少なくとも２つのデバイス、異なる設定を備えた少なくとも２つのデバイス、異なるメーカーからの少なくとも２つのデバイス及び同一のクエリに異なって応答する同一のデバイスの状態を備えた少なくとも２つのデバイスを含む、請求項９記載の計算装置。
【請求項１７】
複数のデバイスのデバイスの状態に対するリクエストを受信するステップと、
デバイスインタラクションツリーの特定のノードにより規定される特定のクエリと１以上の値を規定する特定のテストとを決定するステップであって、前記デバイスインタラクションツリーは、クエリとテストとを規定する中間ノードとデバイスの状態を規定するリーフノードとを有する、前記決定するステップと、
前記デバイスに前記特定のクエリを含む前記クエリの１以上を送信するステップと、
前記デバイスから前記特定のクエリに対する特定のレスポンスを含む前記１以上のクエリに対する１以上のレスポンスを受信するステップと、
前記１以上の値に対して前記特定のレスポンスを評価する前記特定のテストを前記特定のレスポンスに適用するステップと、
前記特定のテストを前記特定のレスポンスに適用した結果として、前記特定のノードから前記リーフノードの１以上に向かって前記デバイスインタラクションツリーを移動するステップと、
前記テストの１以上を前記１以上のレスポンスに適用し、前記デバイスインタラクションツリーのリーフノードの前記デバイスの状態を規定する特定のリーフノードに到達することによって、前記デバイスの状態を決定するステップと、
前記デバイスの状態に対するリクエストに応答して、前記デバイスの状態を提供するステップと、
を有する、１以上の計算装置によって実行される方法。
【請求項１８】
前記リクエストは、前記デバイスのアドレスを指定し、
前記１以上のクエリが、前記アドレスに送信され、
前記デバイスの状態は、動作状態、デバイス設定、又はデバイスエラーの１以上を含み、
前記クエリの１以上は、ＳＮＭＰクエリ、ＰＪＬクエリ、ＰｏｓｔＳｃｒｉｐｔクエリ又はＨＴＴＰクエリの１以上を含む、請求項１７記載の方法。
【請求項１９】
デバイスマネージメントアプリケーションが、前記リクエストを受信するステップと、前記特定のクエリと前記特定のテストとを決定するステップと、前記１以上のクエリを送信するステップと、前記１以上のレスポンスを受信するステップと、前記特定のテストを適用するステップと、前記デバイスインタラクションツリーを移動するステップと、前記デバイスの状態を決定するステップと、前記デバイスの状態を提供するステップとを前記１以上の計算装置に実行させ、
当該方法はさらに、前記デバイスマネージメントアプリケーションのコードを修正することなく前記デバイスインタラクションツリーを更新するステップを有する、請求項１７記載の方法。
【請求項２０】
ユーザインタフェース上で特定の状態が特定のデバイスについて観察されたという指示を受信するステップと、
前記特定のデバイスに特定のクエリを送信するステップと、
前記特定のクエリに対して特定のレスポンスを受信するステップと、
前記指示、前記特定のクエリ及び前記特定のレスポンスを有する情報セットに少なくとも部分的に基づき前記デバイスインタラクションツリーを更新するステップと、
をさらに有する、請求項１７記載の方法。
【図１Ａ】
【図１Ｂ】
【図１Ｃ】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７Ａ】
【図７Ｂ】
【図８Ａ】
【図８Ｂ】
【図８Ｃ】
【図９Ａ】
【図９Ｂ】
【図１０Ａ】
【図１０Ｂ】
【図１１】
【図１２】
【図１３】
【図１４Ａ】
【図１４Ｂ】
【図１４Ｃ】
【図１５】
【図１Ｂ】
【図１Ｃ】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７Ａ】
【図７Ｂ】
【図８Ａ】
【図８Ｂ】
【図８Ｃ】
【図９Ａ】
【図９Ｂ】
【図１０Ａ】
【図１０Ｂ】
【図１１】
【図１２】
【図１３】
【図１４Ａ】
【図１４Ｂ】
【図１４Ｃ】
【図１５】
【公開番号】特開２０１２−１６０１８６（Ｐ２０１２−１６０１８６Ａ）
【公開日】平成２４年８月２３日（２０１２．８．２３）
【国際特許分類】
【出願番号】特願２０１２−１７７９４（Ｐ２０１２−１７７９４）
【出願日】平成２４年１月３１日（２０１２．１．３１）
【出願人】（０００００６７４７）株式会社リコー (37,907)
【Ｆターム（参考）】
【公開日】平成２４年８月２３日（２０１２．８．２３）
【国際特許分類】
【出願日】平成２４年１月３１日（２０１２．１．３１）
【出願人】（０００００６７４７）株式会社リコー (37,907)
【Ｆターム（参考）】
[ Back to top ]