(57)【要約】      （修正有）【課題】コンピューティングネットワーク内で印刷デバイスを見つける技術及び装置を提供する。【解決手段】デバイス状態管理システム（ＤＳＭＳ）は、印刷デバイスにプローブメッセージを送信し、応答を受信後、ＤＳＭＳに関連付けられているデバイスデータベース（ＤＤＢ）内に記憶されるデータに基づいて、未確認の印刷デバイスの数を判定する。ＤＳＭＳは、未確認の印刷デバイスの数に関連付けられているシステム不安定値を判定し、システム不安定値が閾値を超えると判定した場合、未確認の印刷デバイスに関連付けられているアドレスクラスタを判定し、少なくとも１つのアドレスクラスタ内のアドレスにプローブメッセージを送信し、応答内のデータを使用してＤＤＢを更新する。【選択図】図６
2019003617.tif 000002
【特許請求の範囲】
【請求項１】
コンピューティングデバイスであって、
１以上のプロセッサと、
デバイス状態管理システムのための命令を含み、前記１以上のプロセッサによって実行されると前記コンピューティングデバイスにタスクを実施させるコンピュータ読み込み可能な命令を少なくとも記憶するよう構成されるデータ記憶部と、
を備えるコンピューティングデバイスであって、
前記タスクは、
前記デバイス状態管理システムから複数のプローブメッセージを複数の印刷デバイスに送信し、
前記デバイス状態管理システムにおいて、前記複数のプローブメッセージの数以下であって、前記複数のプローブメッセージに対する複数の応答メッセージを受信し、
前記複数の応答メッセージの受信後、前記デバイス状態管理システムに関連付けられているデバイスデータベース内に記憶されるデータに基づいて未確認の印刷デバイスの数を判定し、
前記デバイス状態管理システムを使用して、前記未確認の印刷デバイスの数に関連付けられているシステム不安定値を判定し、
前記デバイス状態管理システムを使用して、前記未確認の印刷デバイスの数に関連付けられている前記システム不安定値がシステム不安定値の閾値を超えているか否か判定し、
前記システム不安定値が前記システム不安定値の閾値を超えていると判定した後、前記デバイス状態管理システムは、
各アドレスクラスタが１以上の印刷デバイスに関連付けられている１以上のアドレスを含み、前記未確認の印刷デバイスに関連付けられている１以上のアドレスクラスタを判定し、
前記１以上のアドレスクラスタの少なくとも１つの内にある１以上のアドレスに１以上のプローブメッセージを送信し、
前記１以上のプローブメッセージに対する１以上の応答を受信し、
前記１以上の応答で受信されるデータを使用して前記デバイスデータベースを更新することを含むコンピューティングデバイス。
【請求項２】
請求項１に記載のコンピューティングデバイスであって、さらに、
前記デバイス状態管理システムからアドレス要求メッセージを送信し、
前記アドレス要求メッセージに応じて、前記複数の印刷デバイスに関連付けられている１以上のネットワークアドレスを受信し、
前記受信された１以上のネットワークアドレスに基づいて前記デバイスデータベースを更新するコンピューティングデバイス。
【請求項３】
請求項２に記載のコンピューティングデバイスであって、
前記デバイス状態管理システムから前記アドレス要求メッセージを送信することは、前記デバイス状態管理システムからのアドレス要求メッセージを動的ホスト構成プロトコル（ＤＨＣＰ）サーバに送信することを含むコンピューティングデバイス。
【請求項４】
請求項２に記載のコンピューティングデバイスであって、
前記デバイス状態管理システムに関連付けられている前記デバイスデータベース内に記憶されたデータに基づいて前記未確認の印刷デバイスの数を判定することは、
前記受信された１以上のネットワークアドレスの特定のネットワークアドレスを判定し、
前記デバイスデータベースが前記特定のネットワークアドレスに関連付けられているデータを記憶していないか否か判定し、
前記デバイスデータベースが前記特定のネットワークアドレスに関連付けられているデータを記憶していないと判定した後、前記未確認の印刷デバイスの数の値をインクリメントさせることを含むコンピューティングデバイス。
【請求項５】
請求項１乃至４のいずれか１項に記載のコンピューティングデバイスであって、
前記未確認の印刷デバイスの数に関連付けられている前記システム不安定値は、前記未確認の印刷デバイスの数を含み、
前記システム不安定値の閾値は、未確認の印刷デバイスの閾値の数を含むコンピューティングデバイス。
【請求項６】
請求項１乃至５のいずれか１項に記載のコンピューティングデバイスであって、さらに、
前記デバイス状態管理システムを使用して前記複数の印刷デバイスの印刷デバイス毎にデバイスアクティビティレベルを判定するコンピューティングデバイス。
【請求項７】
請求項６に記載のコンピューティングデバイスであって、
前記未確認の印刷デバイスの数に関連付けられている前記システム不安定値を判定することは、前記未確認の印刷デバイスの数の前記デバイスアクティビティレベルに基づいて前記未確認の印刷デバイスの数に関連付けられている前記システム不安定値を判定することを含み、前記システム不安定値の閾値は、デバイスアクティビティレベルに基づいた閾値を含むコンピューティングデバイス。
【請求項８】
請求項１乃至７のいずれか１項に記載のコンピューティングデバイスであって、
前記デバイス状態管理システムに関連付けられている前記デバイスデータベースは、前記１以上の印刷デバイスの特定の印刷デバイスのために、
前記特定の印刷デバイスのためのシリアル番号と、
前記特定の印刷デバイスのための機種名と、
前記特定の印刷デバイスのためのネットワークアドレスと、
を記憶するコンピューティングデバイス。
【請求項９】
請求項８に記載のコンピューティングデバイスであって、
前記デバイス状態管理システムに関連付けられている前記デバイスデータベースは、さらに、前記特定の印刷デバイスのために、前記特定の印刷デバイスのデバイスアクティビティレベルを記憶するコンピューティングデバイス。
【請求項１０】
請求項１乃至９のいずれか１項に記載のコンピューティングデバイスであって、
前記未確認の印刷デバイスの数に関連付けられている前記システム不安定値を判定することは、
特定の印刷デバイスに関連付けられている前記複数の応答メッセージの特定の応答メッセージを判定し、
前記特定の応答メッセージ内の応答メッセージシリアル番号が、前記デバイスデータベースからの前記特定の印刷デバイスのシリアル番号と異なるか否か判定し、
前記特定の応答メッセージ内の前記応答メッセージシリアル番号が、前記デバイスデータベースからの前記特定の印刷デバイスの前記シリアル番号と異なると判定した後、前記システム不安定値を増加させることを含むコンピューティングデバイス。
【請求項１１】
請求項１乃至１０のいずれか１項に記載のコンピューティングデバイスであって、
前記未確認の印刷デバイスに関連付けられている前記１以上のアドレスクラスタを判定することは、ベクトル量子化技術を使用して前記未確認の印刷デバイスに関連付けられている前記１以上のアドレスクラスタを判定することを含むコンピューティングデバイス。
【請求項１２】
請求項１乃至１１のいずれか１項に記載のコンピューティングデバイスであって、
前記未確認の印刷デバイスに関連付けられている前記１以上のアドレスクラスタを判定することは、自然分類技術を使用して前記未確認の印刷デバイスに関連付けられている前記１以上のアドレスクラスタを判定することを含むコンピューティングデバイス。
【請求項１３】
請求項１乃至１２のいずれか１項に記載のコンピューティングデバイスであって、
前記１以上のアドレスクラスタの少なくとも１つの内にある前記１以上のアドレスに前記１以上のプローブメッセージを送信することは、
アドレスが第１クラスタ内にある未確認の印刷デバイスの数に基づいて前記１以上のアドレスクラスタの前記第１クラスタを選択し、
前記第１クラスタ内にある１以上のアドレスに１以上のプローブメッセージを送信することを含むコンピューティングデバイス。
【請求項１４】
請求項１３に記載のコンピューティングデバイスであって、
前記１以上のアドレスクラスタの前記第１クラスタを選択することは、アドレスが前記第１クラスタ内にある未確認の印刷デバイスの密度に基づいて前記第１クラスタを選択することを含み、
アドレスが前記第１クラスタ内にある前記未確認の印刷デバイスの密度は、アドレスが前記第１クラスタ内にある前記未確認の印刷デバイスの数に基づくコンピューティングデバイス。
【請求項１５】
請求項１乃至１４のいずれか１項に記載のコンピューティングデバイスであって、
前記１以上のアドレスクラスタの少なくとも１つの内にある１以上のアドレスに１以上のプローブメッセージを送信することは、
前記１以上のアドレスクラスタの少なくとも１つの内にある前記１以上のアドレスの中間アドレスを判定し、
前記中間アドレスから始まる前記１以上のアドレスに前記１以上のプローブメッセージを送信することを含むコンピューティングデバイス。
【請求項１６】
請求項１５に記載のコンピューティングデバイスであって、
前記中間アドレスから始まる前記１以上のアドレスに前記１以上のプローブメッセージを送信することは、前記中間アドレスにプローブメッセージを送信し、その後、前記中間アドレスに隣接するアドレスにプローブメッセージを送信する順番で前記中間アドレスから始まる前記１以上のアドレスに前記１以上のプローブメッセージを送信することを含むコンピューティングデバイス。
【請求項１７】
請求項１６に記載のコンピューティングデバイスであって、
前記中間アドレスに隣接する前記アドレスは、前記中間アドレスの直後のアドレス及び前記中間アドレスの直前のアドレスの１つであるコンピューティングデバイス。
【請求項１８】
請求項１乃至１７のいずれか１項に記載のコンピューティングデバイスであって、さらに、
前記デバイス状態管理システムに関連付けられている前記デバイスデータベース内に記憶されたデータに基づいて印刷デバイスのために交換可能品を注文するコンピューティングデバイス。
【請求項１９】
方法であって、
コンピューティングデバイス上で実行するソフトウェアを備えるデバイス状態管理システムから複数のプローブメッセージを複数の印刷デバイスに送信し、
前記デバイス状態管理システムにおいて、前記複数のプローブメッセージの数以下であって、前記複数のプローブメッセージに対する複数の応答メッセージを受信し、
前記複数の応答メッセージの受信後、前記デバイス状態管理システムに関連付けられているデバイスデータベース内に記憶されるデータに基づいて未確認の印刷デバイスの数を判定し、
前記デバイス状態管理システムを使用して、前記未確認の印刷デバイスの数に関連付けられているシステム不安定値を判定し、
前記デバイス状態管理システムを使用して、前記未確認の印刷デバイスの数に関連付けられている前記システム不安定値がシステム不安定値の閾値を超えているか否か判定し、
前記システム不安定値が前記システム不安定値の閾値を超えていると判定した後、前記デバイス状態管理システムは、
各アドレスクラスタが１以上の印刷デバイスに関連付けられている１以上のアドレスを含み、前記未確認の印刷デバイスに関連付けられている１以上のアドレスクラスタを判定し、
前記１以上のアドレスクラスタの少なくとも１つの内にある１以上のアドレスに１以上のプローブメッセージを送信し、
前記１以上のプローブメッセージに対する１以上の応答を受信し、
前記１以上の応答で受信されるデータを使用して前記デバイスデータベースを更新する方法。
【請求項２０】
コンピューティングデバイスにタスクを実施させるコンピュータープログラムであって、
前記タスクは、
デバイス状態管理システムから複数のプローブメッセージを複数の印刷デバイスに送信し、
前記デバイス状態管理システムにおいて、前記複数のプローブメッセージの数以下であって、前記複数のプローブメッセージに対する複数の応答メッセージを受信し、
前記複数の応答メッセージの受信後、前記デバイス状態管理システムに関連付けられているデバイスデータベース内に記憶されるデータに基づいて未確認の印刷デバイスの数を判定し、
前記デバイス状態管理システムを使用して、前記未確認の印刷デバイスの数に関連付けられているシステム不安定値を判定し、
前記デバイス状態管理システムを使用して、前記未確認の印刷デバイスの数に関連付けられている前記システム不安定値がシステム不安定値の閾値を超えているか否か判定し、
前記システム不安定値が前記システム不安定値の閾値を超えていると判定した後、前記デバイス状態管理システムは、
各アドレスクラスタが１以上の印刷デバイスに関連付けられている１以上のアドレスを含み、前記未確認の印刷デバイスに関連付けられている１以上のアドレスクラスタを判定し、
前記１以上のアドレスクラスタの少なくとも１つの内にある１以上のアドレスに１以上のプローブメッセージを送信し、
前記１以上のプローブメッセージに対する１以上の応答を受信し、
前記１以上の応答で受信されるデータを使用して前記デバイスデータベースを更新することを含むコンピュータープログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、印刷デバイスの状況的及びイベント駆動型発見最適化に関する。
【背景技術】
【０００２】
印刷デバイスは、台数が増大して世界中の各地域に普及しており、ますますネットワークに接続されるようになってきた。これらのネットワークは印刷サーバを含むことができる。典型的に、１以上の文書及び／又は他の印刷データが印刷されるようにスケジュールされる場合、印刷データは直接１台の印刷デバイスに送信されるか印刷サーバに送信されるかのいずれかである。
【０００３】
ネットワークは、多数の印刷デバイスを含むことができる。いくつかの又は全ての印刷デバイスは異なる特性、機能及び能力を有することができる。例えば、印刷デバイスには、カラー印刷を行うものがある一方、行わないものもある。他の例としては、印刷デバイスには、両面印刷ハードウェアを備えて、１枚の用紙の両側に印刷できるものがある一方、他の印刷デバイスは１枚の用紙の片面にしか印刷できないものもある。
【発明の概要】
【０００４】
第１の態様では、方法が提供される。コンピューティングデバイス上で実行するソフトウェアを含むデバイス状態管理システムは、複数のプローブメッセージを複数の印刷デバイスに送信する。デバイス状態管理システムは、前記複数のプローブメッセージに対する複数の応答メッセージを受信し、前記複数の応答メッセージの数は前記複数のプローブメッセージの数以下である。前記複数の応答メッセージの受信後、前記デバイス状態管理システムに関連付けられているデバイスデータベース内に記憶されるデータに基づいて未確認の印刷デバイスの数が判定される。前記デバイス状態管理システムは、前記未確認の印刷デバイスの数に関連付けられているシステム不安定値を判定する。前記デバイス状態管理システムは、前記未確認の印刷デバイスの数に関連付けられている前記システム不安定値がシステム不安定値の閾値を超えているか否か判定する。前記システム不安定値が前記システム不安定値の閾値を超えていると判定した後、前記デバイス状態管理システムは、前記未確認の印刷デバイスに関連付けられている１以上のアドレスクラスタを判定し、各アドレスクラスタは１以上の印刷デバイスに関連付けられている１以上のアドレスを備えており、前記１以上のアドレスクラスタの少なくとも１つの内にある１以上のアドレスに１以上のプローブメッセージを送信し、前記１以上のプローブメッセージに対する１以上の応答を受信し、前記１以上の応答で受信されるデータを使用して前記デバイスデータベースを更新する。
【０００５】
別の態様では、コンピューティングデバイスが提供される。コンピューティングデバイスは、１以上のプロセッサとデータ記憶部とを含む。前記データ記憶部は、コンピュータ読み込み可能な命令を記憶するよう構成される。コンピュータ読み込み可能な命令は、デバイス状態管理システムのための命令を含み、前記１以上のプロセッサによって実行されると前記コンピューティングデバイスにタスクを実施させる。前記タスクは、前記デバイス状態管理システムから複数のプローブメッセージを複数の印刷デバイスに送信し、前記デバイス状態管理システムにおいて、前記複数のプローブメッセージに対する複数の応答メッセージを受信し、前記複数の応答メッセージの数は前記複数のプローブメッセージの数以下であり、前記複数の応答メッセージの受信後、前記デバイス状態管理システムに関連付けられているデバイスデータベース内に記憶されるデータに基づいて未確認の印刷デバイスの数を判定し、前記デバイス状態管理システムを使用して、前記未確認の印刷デバイスの数に関連付けられているシステム不安定値を判定し、前記デバイス状態管理システムを使用して、前記未確認の印刷デバイスの数に関連付けられている前記システム不安定値がシステム不安定値の閾値を超えているか否か判定し、前記システム不安定値が前記システム不安定値の閾値を超えていると判定した後、前記デバイス状態管理システムは、前記未確認の印刷デバイスに関連付けられている１以上のアドレスクラスタを判定し、各アドレスクラスタは１以上の印刷デバイスに関連付けられている１以上のアドレスを備えており、前記１以上のアドレスクラスタの少なくとも１つの内にある１以上のアドレスに１以上のプローブメッセージを送信し、前記１以上のプローブメッセージに対する１以上の応答を受信し、前記１以上の応答で受信されるデータを使用して前記デバイスデータベースを更新する。
【０００６】
別の態様では、製品が提供される。前記製品は、デバイス状態管理システムのための命令を含むコンピュータ読み込み可能な命令を少なくとも記憶する非一時的なデータ記憶部を備える。コンピュータ読み込み可能な命令は、コンピューティングデバイスの１以上のプロセッサによって実行されると前記コンピューティングデバイスにタスクを実施させる。前記タスクは、前記デバイス状態管理システムから複数のプローブメッセージを複数の印刷デバイスに送信し、前記デバイス状態管理システムにおいて、前記複数のプローブメッセージに対する複数の応答メッセージを受信し、前記複数の応答メッセージの数は前記複数のプローブメッセージの数以下であり、前記複数の応答メッセージの受信後、前記デバイス状態管理システムに関連付けられているデバイスデータベース内に記憶されるデータに基づいて未確認の印刷デバイスの数を判定し、前記デバイス状態管理システムを使用して、前記未確認の印刷デバイスの数に関連付けられているシステム不安定値を判定し、前記デバイス状態管理システムを使用して、前記未確認の印刷デバイスの数に関連付けられている前記システム不安定値がシステム不安定値の閾値を超えているか否か判定し、前記システム不安定値が前記システム不安定値の閾値を超えていると判定した後、前記デバイス状態管理システムは、前記未確認の印刷デバイスに関連付けられている１以上のアドレスクラスタを判定し、各アドレスクラスタは１以上の印刷デバイスに関連付けられている１以上のアドレスを備えており、前記１以上のアドレスクラスタの少なくとも１つの内にある１以上のアドレスに１以上のプローブメッセージを送信し、前記１以上のプローブメッセージに対する１以上の応答を受信し、前記１以上の応答で受信されるデータを使用して前記デバイスデータベースを更新する。
【０００７】
その他の態様、実施の形態、及び実装例は、必要に応じて添付の図面を参照しながら以下の詳細の説明を読むことによって当業者にとって明らかになるであろう。
【図面の簡単な説明】
【０００８】
【図１Ａ】例示の実施形態に係る印刷ネットワークを表す図である。
【図１Ｂ】例示の実施形態に係るコンピューティングデバイスを表す概略ブロック図である。
【図２Ａ】例示の実施形態に係るデバイス状態管理システムを使用してネットワーク化された印刷デバイスを発見することに関連する方法のフローチャートである。
【図２Ｂ】例示の実施形態に係るデバイス状態管理システムを使用してネットワーク化された印刷デバイスを発見することに関連する方法のフローチャートである。
【図３Ａ】例示の実施形態に係るシステム安定化の間に印刷システムが不安定であると判定され、デバイスデータベースがリフレッシュされるシナリオを表す。
【図３Ｂ】例示の実施形態に係るシステム安定化の間に印刷システムが不安定であると判定され、デバイスデータベースがリフレッシュされるシナリオを表す。
【図３Ｃ】例示の実施形態に係るデバイスデータベースのフォーマットを表す。
【図４Ａ】例示の実施形態に係るデバイスデータベース内のデータがリフレッシュされるシナリオを表す。
【図４Ｂ】例示の実施形態に係るデバイスデータベース内のデータがリフレッシュされるシナリオを表す。
【図４Ｃ】例示の実施形態に係るデバイスデータベース内のデータがリフレッシュされるシナリオを表す。
【図４Ｄ】例示の実施形態に係るデバイスデータベース内のデータがリフレッシュされるシナリオを表す。
【図４Ｅ】例示の実施形態に係るデバイスデータベース内のデータがリフレッシュされる他のシナリオを表す。
【図４Ｆ】例示の実施形態に係るデバイスデータベース内のデータがリフレッシュされる他のシナリオを表す。
【図４Ｇ】例示の実施形態に係るデバイスデータベース内のデータがリフレッシュされる他のシナリオを表す。
【図４Ｈ】例示の実施形態に係るデバイスデータベース内のデータがリフレッシュされる他のシナリオを表す。
【図５Ａ】例示の実施形態に係る印刷システムを安定化する方法のフローチャートである。
【図５Ｂ】例示の実施形態に係る印刷システムの失われた及び／又は危殆化した印刷デバイスのアドレスの例示のクラスタ及びアドレスのクラスタに対する例示のプローブ決定を表す。
【図６】例示の実施形態に係る方法のフローチャートを表す。
【発明を実施するための形態】
【０００９】
以下に、説明を構成する一部となる添付図面を参照して、詳細な説明をする。図面において、同様の符号は、典型的に、特記がない限り、同様の構成要素とする。詳細な説明、図面及び請求項に記載された例示の実施形態は限定することを意図するものではない。開示された主題の範囲を逸脱せずに、他の実施形態を使用してもよいし、また他の変更を行ってもよい。本明細書内で全般的に説明され、図面に示されている本開示の諸態様は、広範囲にわたる様々な異なる構成において配置、代用、組み合わせ、分割、及び設計されることができ、それらの全てが本明細書内で明らかに考慮されていることは容易に理解される。
Ｉ．   概要
【００１０】
コンピューティングネットワーク内で印刷デバイスを見つける技術及び装置を説明する。コンピューティングネットワークには、印刷デバイスが含まれる、１以上の地理的領域にわたる豊富な数のコンピューティングデバイスを繋げる広大で複雑なネットワークもある。例えば、大企業又は行政機関はこのようなコンピューティングネットワークを活用しているかも知れない。コンピューティングネットワークの成長に伴い、対応する基礎構造は、次第に複雑で高機能となり得、セキュリティ、透明性及び拡張性における要求をカバーするよう設計された１以上のネットワーク階層を含み得る。例えば、複雑なコンピューティングネットワークは、多数のルータ、スイッチ及び動的ホスト構成プロトコル（ＤＨＣＰ）サーバを有するいくつかの相互接続したネットワークセグメントを含むネットワーク階層を有し得る。このようなコンピューティングネットワークは、１００万等の多数のインターネットプロトコル（ＩＰ）アドレスを含むことができ、ＩＰアドレスの割り当てに関する非常に複雑な規則に従うことができる。それらの規則は、ＩＰアドレスの割り当て及び管理に関与している高機能ＤＨＣＰセクタ構造又はその他の外部サブシステムの一部であるかもしれない。このようなネットワーク階層は多数のＩＰアドレスセグメントにわたって広がることができる。
【００１１】
このような環境で新たなハードウェア及び／又はソフトウェアを展開する時、本明細書中に開示されるような、迅速及び確実に印刷デバイスを発見する技術は、状態モニタリング及び生涯保守の結果として発生するタスクを補完できる。これらの発見技術は、ＩＰアドレス等の論理的なデバイスの位置をモニタリング及び追跡できる。これらの技術は、結果的にコンピューティングネットワーク内で連続的にＩＰアドレスを変更し、ホストを切り替えることになるかもしれない、最適なＩＰアドレスの割り当ての実施に努めるネットワーク階層を含むコンピューティングネットワークをはじめとする様々なコンピューティングネットワーク内で使用できる。
【００１２】
例えば、（複雑な）コンピューティングネットワークを管理するため、デバイス名、型番、シリアル番号、インターネットプロトコル（ＩＰ）アドレス及び／又は印刷デバイスに関連するその他の情報等の印刷デバイス情報は、デバイス状態管理システム（ＤＳＭＳ）により維持できるデバイスデータベース（ＤＤＢ）に記憶することができる。
【００１３】
デバイスデータベースは、印刷デバイスを維持するデバイス状態管理システムによって使用できる印刷デバイス情報を記憶できる。例えば、デバイスデータベースに印刷デバイスのトナーが少ないと示すデータがある場合、デバイス状態管理システムは印刷デバイスのためにトナーを注文できる。しかしながら、印刷デバイス情報のデータベース内の情報に一貫性がない場合、十分にトナーが供給されている印刷デバイスのためにトナーを注文したり、ほぼ又は完全にトナーのなくなった印刷デバイスのためにトナーを注文し損ねたりし得る。他の例としては、デバイスデータベースは、１以上の印刷デバイスの現在のステータスに関するフィードバックを提供する際、及び印刷デバイスのイベントに対するほぼリアルタイム又はリアルタイムの反応を可能にする際に使用される情報を提供できる。
【００１４】
多くの状況が、デバイス状態管理システムが知る現時点の印刷デバイスについての知識を反映できるデバイスデータベースを信頼性のない状態に導き得る。例えば、デバイスデータベース内の情報が矛盾するようになった場合、デバイス状態管理システムはデバイスデータベースを修正できる。矛盾する情報の例としては、デバイス状態管理システムが、次のようである状況が含まれるが、これらに限らない。矛盾する情報の例としては、デバイス状態管理システムが、印刷デバイスとの接続を失った場合、印刷デバイスのシリアル番号又は機種名が変更されたことを検知した場合、ネットワーク障害、致命的なデバイスの障害又は故障を検知した場合、新たに発見された印刷デバイス（すなわち、デバイスデータベース内に既に記憶されているデータを持たない印刷デバイス）が既知の印刷デバイス（すなわち、デバイスデータベース内に既に記憶されているデータを持つ印刷デバイス）と同じシリアル番号を持っているが、ＩＰアドレスは新たに発見された印刷デバイスと既知の印刷デバイスとでは異なることを検知した場合、及び印刷デバイスのＩＰアドレスのその他の変化を検知した場合等が挙げられる。
【００１５】
デバイスデータベースは、これらの矛盾に対処する及び／又はその他の理由で定期的に（例えば、毎晩）更新できる。他の理由とは、新たなプリンタのためにデータを記録する等である。印刷デバイスには、デバイス状態管理システムがデバイスデータベースを適切に更新できるように、ＩＰアドレスに変更があった時、印刷デバイスの接続が切れた時等に、デバイス状態管理システムにメッセージを送信できるエージェントを有するものがあるが、全ての印刷デバイスが有するわけではない。全ての印刷デバイスがエージェントを有するわけではないため、上記のように印刷デバイスデータベースを維持するために印刷デバイスを発見する等で、全てではないとしてもほとんどの印刷デバイスが発見されるような状況では、プローブメッセージ（又は略称して「プローブ」）を使用できる。プローブは印刷デバイスに送信でき、印刷デバイスは上記の印刷デバイスについての印刷デバイス情報のいくつか又は全てに応答できる。
【００１６】
印刷デバイスからのプローブに対する応答、つまり「プローブ応答」に、印刷デバイスのためにデバイスデータベースに記憶されたデータと一致するデータが含まれる場合、印刷デバイスのプローブは成功したと考えることができる。デバイス状態管理システムによってプローブ応答が受信されない場合又はプローブ応答がデバイスデータベースと一貫性のないデータを有する場合、プローブは失敗したと考えることができる。場合によっては、相対的に少量のネットワークトラフィックしか印刷デバイスに割り当てることができず、そのため、失敗プローブはしばらくの間、フォローアップされないかもしれない。このように、印刷デバイス情報のデバイスデータベースは、失敗プローブがフォローアップされるまでに、徐々に期限切れとなり得る。
【００１７】
プローブは様々な理由で失敗し得る。失敗プローブの理由の１つに印刷デバイスのためのＩＰアドレス情報が時間と共に変化することがある。例えば、印刷デバイスがシャットダウンされ、その後、電源が入れられた場合、印刷デバイスは、ＤＨＣＰサーバ等のサーバに印刷デバイスの使用のためにＩＰアドレスを割り当てるように依頼できる。新たに割り当てられるＩＰアドレスは、シャットダウンより前に印刷デバイスによって使用されていた前回割り当てられていたＩＰアドレスと異なっていてもよい。印刷デバイスの接続が切れ得る失敗プローブの他の理由としては、おそらくプローブメッセージが送信される時に電源が切られていることがある。例えば、営業日の終わりに印刷デバイスがシャットダウンされ、プローブが営業時間でない間に送信されている場合、シャットダウンした印刷デバイスはネットワークからの接続が切れるので、シャットダウンした印刷デバイスへのプローブメッセージの送信は失敗する。その他の失敗プローブの理由も考えられる。
【００１８】
デバイスデータベースを維持するため、デバイス状態管理システムはネットワーク上のデバイスにプローブを送信でき、対応するプローブ応答を受信できる。プローブ応答の受信後、デバイス状態管理システムは、未確認の印刷デバイスの数を判定できる。デバイス状態管理システムは、（１）デバイスＤのプローブ応答内のデータがデバイスデータベース内に記憶されているデータと矛盾する時、又は（２）デバイスＤがプローブに応答しなかった時のいずれかの時にプローブメッセージに応答するデバイスＤが未確認の印刷デバイスであると判定できる。つまり、デバイスＤに対するプローブが失敗した場合、デバイスＤは未確認の印刷デバイスであると分類されることができる。
【００１９】
プローブ応答内のデータはデバイスデータベース内に記憶されたデータと多くの理由で矛盾し得る。例えば、プローブ応答は、印刷デバイスのシリアル番号、機種名及びネットワーク／ＩＰアドレスを含むことができる。しかし、ＤｅｖｉｃｅＡのシリアル番号及び／又は機種名は、例えば、ＤＨＣＰサーバ又はユーザによって新たなＩＰアドレスがＤｅｖｉｃｅＡに割り当てられたり、ＤｅｖｉｃｅＡの古いＩＰアドレスが異なるＤｅｖｉｃｅＢに再び割り振られたりした時に変更され得る。また、デバイスデータベース内で失われたデバイスのシリアル番号及び／又は機種名は、新たな印刷デバイスのシリアル番号及び／又は機種名であり得る。他の例として、ＤｅｖｉｃｅＣがプローブ応答に一致する同じシリアル番号（及びおそらく機種名）を有する記録をデバイスデータベース内に持つ場合、ＤｅｖｉｃｅＣのＩＰアドレスは変更され得る。ＩＰアドレスは、新たな又は追加のネットワークアダプタの使用、異なるＩＰバージョン（ＩＰｖ４又はＩＰｖ６）が有効にされた、新たなＩＰアドレスがＤＨＣＰサーバ又はユーザによってＤｅｖｉｃｅＣに割り振られた等、多くの理由で変更し得る。
【００２０】
デバイス状態管理システムは、デバイス状態管理システムを使用して未確認の印刷デバイスの数に関連付けられているシステム不安定値を判定できる。一例では、システム不安定値は、未確認の印刷デバイスの数であることができる。他の例では、システム不安定値は、未確認の印刷デバイスの数の多数のアクティビティレベルの和又は他の数学的組み合わせであることができる。特定の未確認の印刷デバイスＵＰＤのアクティビティレベルは、印刷デバイスＵＰＤによって使用されるトナー量、印刷デバイスＵＰＤから得られるページカウンタ等のカウンタの数値、印刷デバイスＵＰＤにより生成されるアラートの数及び／又は種類、並びにそれらの組み合わせに基づくことができる。
【００２１】
より具体的には、アクティビティレベルは、１以上の数値の変化率に基づくことができる。例えば、デバイス状態管理システムが、未確認の印刷デバイスＵＰＤのページカウンタが１日目は１０００で２日目は１２００であると判定した場合、これらのページカウンタの変化率は、印刷デバイスＵＰＤがこの特定の日において２００ページ印刷したことを示す。そして、デバイス状態管理システムは、１日２００ページの数値に基づいて印刷デバイスＵＰＤのアクティビティレベルを判定できる。他の例として、印刷デバイスＵＰＤのトナーレベルが１日目は８０％で、２日目は７８．３％である場合、印刷デバイスＵＰＤのアクティビティレベルは、印刷デバイスＵＰＤのトナーレベルにおける１．７％の減少に基づくことができる。例えば、２００ページ／１日及びトナーレベルにおける１．７％の変化に基づいて印刷デバイスＵＰＤのアクティビティレベルを判定するような組み合わせも考えられる。システム不安定値を判定する際にアクティビティレベルを使用することは、未確認の印刷デバイスの不等な重み付けを招き得る。つまり、未確認の印刷デバイスにはシステムの不安定性に大きな影響を与えるものもあり得れば、未確認の印刷デバイスにはシステムの不安定性にほとんど又は一切影響を与えないものもあり得る。極端な例では、アクティビティレベルの高い未確認の印刷デバイスを１つ有することでシステムを不安定にさせることもあり得る。その他の例のシステム不安定値及びアクティビティレベルも考えられる。
【００２２】
デバイス状態管理システムは、システム不安定値がシステム不安定値の閾値を超えると判定することで、デバイスデータベースが不安定であると判定できる。そうでなく、システム不安定値がシステム不安定値の閾値を超えない場合、デバイスデータベースは安定していると考えることができ、デバイス状態管理システムはそのままデバイスデータベースを活用できる。例えば、デバイス状態管理システムが、Ｎ＞０である、Ｎ台の印刷デバイスに関するデータを有する場合、システム不安定値の閾値は、例えば１、１０、５０、６６、１００、５００のような所定の数の未確認の印刷デバイス、例えばＮの１０％、Ｎの１５％、Ｎ＋１の２０％のようなデバイスの割合、及び／又はその他の技術を使用して判定された１以上の数値に基づくことができる。他の例としては、システム不安定値の閾値は、所定の数の未確認の印刷デバイスのアクティビティレベルの和又は他の数学的組み合わせであることができる。例えば、未確認の印刷デバイスからの１日１０、３００、５０００又は１５００００ページといったページ数／１日の合計、例えば、未確認の印刷デバイスにおけるトナーレベルの変化１０％、２５％、１００％、２５０％、５００％といったトナーレベルの累積率又はその他の変化、例えば、未確認の印刷デバイスから累積的に受信される１、１０、２５、５０、１００、２５０といったアラートの数等、及びそれらの組み合わせがシステム不安定値の閾値となることができる。その他のシステム不安定値の閾値も考えられる。
【００２３】
デバイスデータベースとプローブ応答との間の矛盾を解決するため、デバイス状態管理システムは、見当たらないデバイスを発見し、既知のデバイスは全て接続して連絡可能であることを確認できる。見当たらないデバイスの発見は、予防システムメンテナンス発見アプローチ及び／又は状況的システム安定化発見アプローチを使用して行うことができる。例えば、システム不安定値が、システム不安定閾値未満の時、予防システムメンテナンス発見アプローチが使用できる。予防システムメンテナンス発見アプローチは、潜在的なシステムのコンフリクトの数を最小限に抑えることを目的し、システム状態に信頼性がないと考えられる可能性のある状況を防止できる。システム不安定値がシステム不安定閾値を超える時等の、その他の場合では、状況的システム安定化発見アプローチが使用できる。状況的システム安定化発見アプローチは、実際的な問題が発生し、予防システムメンテナンス発見アプローチを使用して検知又は解決されていない時にシステム状態を安定させることを目的とできる。
【００２４】
予防システムメンテナンス発見アプローチは、潜在的なコンフリクト及び状態が信頼できず、環境が変化していない又は危殆化していないという最小の適時保証をシステムが少なくとも有する必要があるケースを最小限に抑えることができる。潜在的なコンフリクトの数を最小限に抑えるために、デバイス状態管理システムは、１以上のＤＨＣＰサーバと結合及び接続してＩＰアドレス等の印刷デバイスに関連付けられているかもしれないネットワークアドレスの１以上のリストを取得する、デバイス状態モニタリングシステムによって１以上の既存のＩＰアドレス割り当てサブシステムと通信を行うことができる。ネットワークアドレスのリストを取得後、デバイス状態管理システムは、リスト上のＩＰ／ネットワークアドレスをデバイスデータベース内に記憶される既知のＩＰ／ネットワークアドレスと比較できる。
【００２５】
予防システムメンテナンス発見アプローチは、ＩＰアドレス情報によって印刷デバイスをその他のデバイスと区別できる。場合によっては、印刷デバイスにはＩＰアドレスの特定の範囲が割り振られる。ＩＰアドレスのこれらの範囲は、ＩＰネットワーク及び／又はそのネットワーク内の印刷デバイスを管理するネットワーク管理者によってデバイス状態管理システムに提供されることができるが、それらの範囲は時間と共に変化し得る。また、提供される範囲内にないＩＰアドレスに印刷デバイスが割り振られる可能性もある。デバイス状態管理システムが印刷デバイスを発見するためにＩＰアドレス範囲を使用しようとする時、デバイス状態管理システムは、過去にどのＩＰアドレス範囲が印刷デバイスにより使用されたかについての履歴情報及び／又はプローブメッセージに対する応答で返信されたＩＰアドレス範囲についての情報等の付加情報により補充されるこの提供情報を使用できる。さらに、多くの非印刷デバイスはシリアル番号情報を提供しないので、シリアル番号情報を含むプローブ応答によって印刷デバイスを区別できる。
【００２６】
実施形態によっては、デバイス状態管理システムは、ＤＨＣＰサーバと同じコンピューティングデバイス上で実行でき、そうすると、１以上の設定ファイルを使用することで、いくつかの又は全てのネットワークアドレスのリストを読み出せる。その他の実施形態では、デバイス状態管理システムは、ＤＨＣＰサーバと異なるコンピューティングデバイス上で実行でき、そうすると、１以上のネットワーク通信プロトコル（例えば、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、Ｅｘｔｅｎｓｉｂｌｅ  Ｍｅｓｓａｇｉｎｇ  ａｎｄ  Ｐｒｅｓｅｎｃｅ  Ｐｒｏｔｏｃｏｌ（ＸＭＰＰ）、簡易ネットワーク管理プロトコル（ＳＮＭＰ）、テルネット、ファイル転送プロトコル（ＦＴＰ）、伝送制御プロトコル（ＴＣＰ）、ソケットベース通信プロトコル）を使用することで、いくつかの又は全てのネットワークアドレスのリストを読み出せる。
【００２７】
より具体的には、デバイス状態管理システムはＤＨＣＰサーバに接続でき、ＤＨＣＰサーバにより割り当てられて既知であったＩＰアドレスのリストを読み出せる。予防システムメンテナンス発見アプローチを継続して、デバイス状態管理システムは、既知のＩＰアドレスとＤＨＣＰサーバから返信されたアドレスのリストとを比較できる。未知のＩＰアドレスがいくつか返信される場合、未知のＩＰアドレスは（新たな）印刷デバイスのＩＰアドレスである可能性があるため、未知の各ＩＰアドレスにプローブメッセージを送信する等の単純なプローブ方法を使用して未知のＩＰアドレスをプローブできる。未知のＩＰアドレスのプローブによって、ＤＨＣＰサーバから返信されず、予め解決されなかった既知のＩＰアドレスがいくつかあることが明らかになった場合、これらの既知のＩＰアドレスを確認し、システムがそれらのデバイスとの接続を失っていないこと及びシステム状態が正確であることを確かめることができる。
【００２８】
システム不安定値がシステム不安定値の閾値を超えていると判定した後、デバイス状態管理システムは、デバイスデータベースが不安定であると判定でき、それによりデバイスデータベースは未確認の印刷デバイスを確認するために更新される。デバイスデータベースが不安定な時は、状況的システム安定化発見アプローチが使用できる。状況的システム安定化発見アプローチは、効率的にシステム状態を回復／デバイスデータベースを更新して、確実にデバイスデータベースが印刷デバイスについての完全で正確な情報を有するようにできる。
【００２９】
場合によっては、状況的システム安定化発見アプローチを使用する前に、予防システムメンテナンス発見アプローチを行うことができる。例えば、予防システムメンテナンス発見アプローチが、状況的システム安定化発見アプローチを実際に呼び出さずにデバイスデータベースを安定状態にできるという意図のもと、予防システムメンテナンス発見アプローチを事前に行わないまま状況的システム安定化発見アプローチが呼び出される時である。
【００３０】
状況的システム安定化発見アプローチは、デバイスデータベース内の未確認の印刷デバイスを全て見つけようと試みることができる。しかし、順次的なＩＰアドレスプロービングを使用して広大なネットワーク中の全てのデバイスにプローブメッセージを送信することは、デバイスの新たなＩＰアドレスを見つけることに長時間を費やし得る。つまり、最適化なしでは、失われたデバイスの順次的なＩＰアドレスプロービングは、（全範囲プロービングによる）大規模なシステムでコストがかかり過ぎるかも知れない及び／又は（単一ターゲットプロービング又は単純範囲ターゲットプロービングにより）不確定過ぎるかも知れない。
【００３１】
デバイスデータベースを更新するために送信されるプローブメッセージの数を最適化するため、状況的システム安定化発見アプローチは、未確認の印刷デバイスに関連付けられている１以上のアドレスクラスタを判定できる。例えば、多数の未確認の印刷デバイスが、１以上の特定の近接サブネット等のＩＰアドレスの特定の範囲と関連付けられ、各サブネットに２５６個のＩＰアドレスがあるとすると、アドレスクラスタはＩＰアドレスの特定の範囲の一部又は全てを含むことができる。
【００３２】
特に、ベクトル量子化技術を未確認の印刷デバイスのリストに適用して、危殆化したデバイスの再発見を最大限にし、探す範囲を最小限に抑えることができる。ベクトル量子化の方法は、未確認の印刷デバイスに関連付けられているＩＰアドレスを、数量分類学類似の、ＩＰアドレス範囲上の位置に基づいたクラスタにまとめることができる。ベクトル量子化の方法は、ｋ平均法を使用して、未確認の印刷デバイスに関連付けられているＩＰアドレスを区分できる。つまり、クラスタ化によって、未確認の印刷デバイスに関連付けられているＩＰアドレスのリストを、ｋクラスタに分類できる。場合によっては、未確認の印刷デバイスに関連付けられているＩＰアドレスは、一変量の（１次元の）データであると考えることができ、そのため、１次元データの分類可能な特性を活用するジェンクス自然分類最適化（Ｊｅｎｋｓ  ｎａｔｕｒａｌ  ｂｒｅａｋｓ  ｏｐｔｉｍｉｚａｔｉｏｎ）を使用して、ＩＰアドレスをクラスタ化できる。
【００３３】
未確認の印刷デバイスに関連付けられているＩＰアドレスが一旦クラスタ化されたら、クラスタは、１以上のアドレスクラスタの特性に従って、対象となる発見と診断されることができる。診断に関するクラスタ特性の例を以下に挙げるが、これらに限らない。
l  クラスタ範囲（クラスタ内のＩＰアドレスの数）
l  クラスサイズ（当該クラスタ内で見つかった未確認の印刷デバイスの数）
l  クラスタ密度（クラスタ範囲に対するクラスサイズの比率）
l  不安定性の履歴（当該クラスタが危殆化する頻度）
l  総実働時間（失われた、危殆化した又は照合が必要と考えられる前にデバイスデータベース内にデバイスがあった期間）
対象となる発見に適したアドレスクラスタをクラスタ特性に基づいて判定した後、デバイス状態管理システムは、適したアドレスクラスタ内のＩＰアドレスにプローブを送信し、プローブに対する応答を受信し、プローブ応答に基づいてデバイスデータベースを更新できる。このように、デバイス状態管理システムは対象となる発見を使用してデバイスデータベースをリフレッシュ／再構築できる。
【００３４】
本明細書中に説明されている技術及び装置は、相対的に少量の帯域幅を使用して印刷デバイスのためのデバイスデータベースを維持することを可能にする。全てではないとしてもほとんどの本明細書中に説明されている技術及び装置は、コンピューティングネットワークのトラフィックが相対的に低いと見込まれる及び／又は測定される時に活用でき、その他のコンピューティングネットワークの活動への影響を抑えることができる。これらの技術及び装置は、プローブメッセージングを、失敗プローブの数が相対的に多いアドレスクラスタに集中させるため、デバイスデータベースの維持に対して有効な情報を生み出しそうもないアドレス範囲内のデバイスへ送信するプローブ及びプローブ応答を減少させることによって、デバイスデータベースを維持するために必要な情報を効率良く取得できる。
ＩＩ． 印刷システム例
【００３５】
図１Ａは、例示の実施形態に係る印刷ネットワーク１００を示す図である。印刷ネットワーク１００は、コンピューティングデバイス１１０、１以上の非印刷デバイス１２０、１２２、１２４、１２６、１２８、１４０、ＤＨＣＰサーバ１４４、及びネットワーク１５０を使用して相互接続された１以上の印刷デバイス（ＰＤ）１３０、１４２を備える。例によっては、印刷ネットワーク１００は、図１Ａに示すよりも多い、少ない及び／又は異なる種類のアセスメントデバイス、非印刷デバイス及び／又は印刷デバイスを備えることができる。
【００３６】
コンピューティングデバイス１１０、ＤＨＣＰサーバ１４４及び／又は非印刷デバイス１２０、１２２、１２４、１２６、１２８、１４０は、ネットワーク１５０を使用して、相互に及び印刷デバイス１３０、１４２と通信を行うように構成されたコンピューティングデバイスであること又は含むことができる。コンピューティングデバイス１１０は、デバイス状態管理システム（ＤＳＭＳ）１１２用のソフトウェア及び／又はデバイスデータベース（ＤＤＢ）１１４のデータを含む印刷又は非印刷デバイスであることができる。デバイス状態管理システム１１２は印刷デバイスをプローブすること、プローブ応答を受信すること及びデバイスデータベース１１４を維持するためのその他のデータを収集することができる。デバイスデータベース１１４は印刷ネットワーク１００及びおそらくその他のネットワーク内の印刷デバイスを維持するためのデータを含むことができる。デバイスデータベース１１４に記憶されるデータの例は、少なくとも以下の図３Ｃ、４Ｂ、４Ｄ、４Ｆ及び４Ｈと関連して説明されている。
【００３７】
印刷デバイス１３０、１４２は、用紙で又は電子的にのいずれかで本来入手できる原稿及び／又はファイルのスキャン、印刷、複写、電子メール送信、確認、通信及び／又はその他の処理を行うように構成されたデバイスを含むことができる。印刷ネットワーク１００では、非印刷デバイスは、印刷デバイスでないコンピューティングデバイスであることができ、非印刷デバイスは、ネットワーク１５０を使用してその他の非印刷デバイス及び印刷デバイス１３０、１４２と通信を行うように構成されることができる。
【００３８】
１以上の印刷デバイス１３０、１４２によって処理された後、原稿及び／又はファイルは、その後、要求に応じて、用紙又は電子的のいずれかで入手できる。つまり、印刷デバイス１３０、１４２は、少なくとも、以下によって用紙原稿ＰＤ又は電子原稿ＥＤを処理できる。ＰＤの内容を表す電子原稿ＥＤ１を作成すること（例えば、ＰＤをスキャンしてＥＤ１を作成すること）、ＰＤの用紙での複写を１以上作ること、１以上の種類の用紙にＥＤ及び／又はＥＤ１の１以上の複写を印刷すること、ＥＤ及び／又はＥＤ１の電子的複写を１以上作ること、ＥＤ及び／又はＥＤ１の形式を変更すること（例えば、ＯＣＲスキャンを実施すること、ＥＤ及び／又はＥＤ１を記憶するために使用されるファイル形式を変換すること）、印刷デバイス１３０、１４２以外のその他のデバイスがＥＤ及び／又はＥＤ１を使用／アクセスできるようにする遠隔アクセス可能なストレージ（例えば、文書ボックス）を維持すること、及び／又はＥＤ及び／又はＥＤ１の内容を他のデバイスへ／から通信することによって用紙原稿ＰＤ又は電子原稿ＥＤを処理できる。
【００３９】
文書ボックスは、印刷デバイス、印刷サーバ又は他のデバイス上のエンティティ（例えば、ユーザ、管理者、企業、他の種類のエンティティ）に対して割り当てられるストレージであることができ、従って、エンティティは原稿、ファイル及び／又はその他のデータを保持及び維持できる。実施形態によっては、文書ボックスは、アドレス帳等の個人データ用のストレージ及び／又はデバイスアカウント処理ストレージを伴う及び／又は含むことができる。文書ボックス、アドレス帳及びデバイスアカウント処理ストレージは、１以上の原稿、ファイル、個人データ及び／又は連絡先、用途及び用途限定等のその他のデータを記憶できる。
【００４０】
実施形態によっては、印刷デバイス１３０、１４２は、その他のタスク及び／又はその他の処理もまた実施できる。印刷デバイス１３０、１４２としては、様々な製造者からの、多様な色、速度、演算能力、機能性、ネットワーク接続性及び／又はその他の特徴を持つ製品が挙げられる。
【００４１】
例示の実施形態においては、いくつか又は全ての印刷デバイス１３０、１４２は１以上の、おそらく異なるネットワークプロトコルを通してネットワーク１５０に接続できる。データは、非印刷デバイスと、印刷デバイスと、ネットワーク１５０との間の有線及び／又は無線のリンクによって、印刷デバイス１３０、１４２と非印刷デバイス１２０、１２２、１２４、１２６、１２８、１４０との間で伝送できる。印刷ネットワーク１００内でのデバイス間のそれぞれのデータ伝送の形式は、１以上の様々な異なる形式を含むことができる。１以上の様々な異なる形式としては、テキスト形式、画像フォーマット、拡張マークアップ言語（ＸＭＬ）、データベーステーブル、フラットファイル形式又は他の形式が挙げられる。実施形態によっては、非印刷デバイスは、１以上の印刷デバイスのための印刷サーバとして作動するよう構成されることができる。印刷サーバは、ジョブを処理（例えば、ジョブ関連データをスプールする、ジョブを計画する、ジョブにユーザ及び／又はサーバ関連アカウントを提供する、ジョブに関連する認証及び承認規則を確認／執行する）及び印刷ネットワーク１００内の印刷デバイス関連データを記憶するよう構成できる。例えば、ネットワーク１５０では、非印刷デバイス１４０は、少なくとも印刷デバイス１４２の印刷サーバとなるよう構成される。
【００４２】
非印刷デバイスと印刷デバイスとの間の通信として、コンピューティングデバイス１１０及び／又は非印刷デバイス１２０、１２２、１２４、１２６、１２８、１４０が印刷ジョブのデータ及び／又は印刷用の印刷ジョブの割り当て分を印刷デバイス１３０、１４２に送信し、印刷デバイス１３０、１４２がアラート、ステータス、エラー及び／又はその他のメッセージを送信して、その他のデバイスに印刷デバイスのエラー又はその他の状況を通知することが挙げられる。例えば、待機、印刷、休止、紙詰まり、用紙の減少又は切れ、トナー／インクの減少又は切れ等である。１以上のコンピューティングデバイスと、１以上の非印刷デバイスと、
１以上の印刷デバイス間のその他の通信も考えられる。例えば、デバイス状態管理システム１１２及び／又はデバイスデータベース１１４に関連する後述の通信である。
【００４３】
ＤＨＣＰサーバ１４４は、ＩＰアドレス等のアドレス指定情報をネットワーク１５０内のコンピューティングデバイスに提供できる。例においては、非印刷デバイス１２０の電源が切られ、後に電源が入れられるようにする。電源が入ると、非印刷デバイス１２０又はネットワーク１５０はＤＨＣＰサーバ１４４にＤＨＣＰ発見メッセージを送信して、ネットワーク１５０及び／又はインターネット等のその他のネットワークに接続する及び使用するための新たなＩＰアドレスを要求することができる。ＤＨＣＰ発見メッセージに応じて、ＤＨＣＰサーバ１４４は、非印刷デバイス１２０による使用のためのＩＰアドレスを割り当て（又は貸し出し）でき、新たに割り当てられるＩＰアドレスを含む非印刷デバイス１２０にＤＨＣＰオファーメッセージを送信できる。非印刷デバイス１２０は、ＤＨＣＰオファーメッセージを受け付け、新たに割り当てられるＩＰアドレスを使用してアクセスできる。印刷デバイスがＤＨＣＰサーバ１４４からＩＰアドレスを取得するためにも同様の処理を使用できる。
【００４４】
図１Ｂは、例示の実施形態に係るコンピューティングデバイス１６０を示す概略ブロック図である。実施形態によっては、コンピューティングデバイス１６０は、１以上の本明細書中に説明されている、印刷ネットワーク１００、コンピューティングデバイス１１０、デバイス状態管理システム１１２、デバイスデータベース１１４、デバイスデータベース形式１１４ａ、１１４ｂ、１１４ｃ、１１４ｄ、非印刷デバイス１２０、１２２、１２４、１２６、１２８、１４０、印刷デバイス１３０、１４２、３１０、ＤＨＣＰサーバ１４４、方法２００、５００、６００、デバイス４１０、４２０、クラスタ化されたＩＰＬｉｓｔ４３４、及びシナリオ３００、４００、４００ａ及び５８０に関連する本明細書中に説明されている機能性の少なくとも一部の機能を実施するよう構成できる。
【００４５】
コンピューティングデバイス１６０は、１以上の入力デバイス１６２、１以上の出力デバイス１６４、１以上のプロセッサ１６６及び記憶部１６８を含むことができる。入力デバイス１６２は、ユーザ入力デバイス、ネットワーク入力デバイス、センサ及び／又はその他の種類の入力デバイスを含むことができる。例えば、入力デバイス１６２は、タッチスクリーン、キーボード、キーパッド、コンピュータマウス、トラックボール、ジョイスティック、カメラ、音声認識モジュール及び／又はその他の同様のデバイス等のユーザ入力デバイスを含むことができる。ネットワーク入力デバイスは、イーサネット（登録商標）トランシーバ、ユニバーサル・シリアル・バス（ＵＳＢ）トランシーバ又はツイストペア線、同軸ケーブル、光ファイバーリンク又はネットワーク１５０の有線箇所等の有線ネットワークへの同様の物理的接続を介して通信するように設定できる同様のトランシーバ等の有線ネットワークレシーバ及び／又はトランシーバ及び／又はＢＬＵＥＴＯＯＴＨ（登録商標）トランシーバ、Ｚｉｇｂｅｅトランシーバ、Ｗｉ−Ｆｉトランシーバ、ＷｉＭＡＸトランシーバ、無線広域ネットワーク（ＷＷＡＮ）トランシーバ及び／又はネットワーク１５０の無線箇所等の無線ネットワークを介して通信するように設定できるその他の同様の種類の無線トランシーバ等の無線ネットワークレシーバ及び／又はトランシーバを含むことができる。センサは、コンピューティングデバイス１６０の環境内の状況を測定するよう構成されるデバイスを含み、その環境についてのデータを提供することができる。このようなデータには、コンピューティングデバイス１６０の位置データ、速度（速さ、方向）データ、加速度データ及び環境についてのその他のデータが含まれるが、これらに限らない。センサの例として、ＧＰＳセンサ、位置センサ、ジャイロスコープ、加速度計、磁力計、カメラ、光センサ、赤外線センサ及びマイクロホンが挙げられるが、これらに限らない。他の入力デバイス１６２も考えられる。
【００４６】
出力デバイス１６４は、ユーザ表示デバイス、可聴出力デバイス、ネットワーク出力デバイス及び／又はその他の種類の出力デバイスを含むことができる。ユーザ表示デバイスは、１以上の印刷コンポーネント、液晶ディスプレイ（ＬＣＤ）、発光ダイオード（ＬＥＤ）、レーザ、デジタル光処理（ＤＬＰ）技術を使用したディスプレイ、陰極線管（ＣＲＴ）、電球及び／又はその他の同様のデバイスを含むことができる。可聴出力デバイスは、スピーカ、スピーカジャック、音声出力ポート、音声出力装置、ヘッドホン、イヤホン及び／又はその他の同様のデバイスを含むことができる。ネットワーク出力デバイスは、イーサネット（登録商標）トランシーバ、ユニバーサル・シリアル・バス（ＵＳＢ）トランシーバ又はツイストペア線、同軸ケーブル、光ファイバーリンク又はネットワーク１５０の有線箇所等の有線ネットワークへの同様の物理的接続を介して通信するように設定できる同様のトランシーバ等の有線ネットワークトランスミッタ及び／又はトランシーバ及び／又はＢＬＵＥＴＯＯＴＨ（登録商標）トランシーバ、Ｚｉｇｂｅｅトランシーバ、Ｗｉ−Ｆｉトランシーバ、ＷｉＭＡＸトランシーバ、無線広域ネットワーク（ＷＷＡＮ）トランシーバ及び／又はネットワーク１５０の無線箇所等の無線ネットワークを介して通信するように設定できるその他の同様の種類の無線トランシーバ等の無線ネットワークトランスミッタ及び／又はトランシーバを含むことができる。その他の種類の出力デバイスとしては、振動装置、触覚フィードバック装置及び赤外線又は紫外線を出射する装置等の不可視光放射装置が挙げられるが、これらに限らない。その他の出力デバイス１６４も考えられる。
【００４７】
プロセッサ１６６は、１以上の汎用プロセッサ、中央処理装置（ＣＰＵ）、ＣＰＵコア及び／又は１以上の専用プロセッサ（例えば、グラフィックス・プロセッシング・ユニット（ＧＰＵ）、デジタル・シグナル・プロセッサ（ＤＳＰ）、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、特定用途向け集積回路（ＡＳＩＣ）等）を含むことができる。プロセッサ１６６は、記憶部１６８に含まれるコンピュータ読み込み可能な命令１７０及び／又は本明細書中に説明されているその他の命令を実行するよう構成できる。
【００４８】
記憶部１６８は、データ及び／又は命令を記憶するよう構成された非一時的な機械読み取り可能な記憶装置を含むことができる。例によっては、記憶部１６８は、デバイス状態管理システム１１２及び／又はデバイスデータベース１１４のデータの一部又は全てを記憶できる。その他の例では、記憶部１６８は、プロセッサ１６６により実行されると、コンピューティングデバイスに本明細書中に説明されている機能を実施させることができるコンピュータ読み込み可能な命令１７０を記憶できる。機能とは、本明細書中に説明されているデバイス、ネットワーク、方法、特徴及びシナリオの機能等であるが、これらに限らない。特に、コンピュータ読み込み可能な命令１７０は、少なくともいくつかのデバイス状態管理システム１１２及び／又はデバイスデータベース１１４のための及び／又は関連する命令を含むことができる。
ＩＩＩ．      印刷デバイスを見つけてデバイスデータを更新する装置及び方法
【００４９】
図２Ａ及び２Ｂは、例示の実施形態に係るネットワーク化された印刷デバイスを、デバイス状態管理システムを使用して発見することに関連する方法２００のフローチャートである。方法２００は、デバイス状態管理システム１１２等のデバイス状態管理システムにより実行されることができる。デバイス状態管理システムは、図１Ａに関連して上記で説明されているコンピューティングデバイス１１０及び／又は図１Ｂに関連して上記で説明されているコンピューティングデバイス１６０等のコンピューティングデバイスにより実行されるソフトウェアであること又はソフトウェアを含むことができる。
【００５０】
図２Ａは、デバイス状態管理システムがネットワーク化された印刷デバイスを発見する一環としてプローブを送信するか否かを判定できる、ラベル「Ａ」に関連付けられたブロック２１０で方法２００が開始できることを示す。例えば、上記の予防システムメンテナンス発見アプローチは、プローブの送信を含まないのに対して、上記の状況的システム安定化発見アプローチはプローブの送信を含む。
【００５１】
デバイス状態管理システムが、この時にプローブを送信することがネットワーク化された印刷デバイスを発見する一環であると判定した場合、デバイス状態管理システムはブロック２１２に進むことができる。そうでなく、デバイス状態管理システムが、この時にプローブを送信することはネットワーク化された印刷デバイスを発見する一環でないと判定した場合、デバイス状態管理システムはブロック２１４に進むことができる。
【００５２】
ブロック２１２で、デバイス状態管理システムは、この時にプローブを送信することがネットワーク化された印刷デバイスを発見する一環であることを示す、ＵｓｅＰｒｏｂｅ変数＝１を設定できる。例えば、状況的システム安定化発見アプローチを呼び出すことは、ブロック２１２の実行及びＵｓｅＰｒｏｂｅ＝１の設定を導くことができる。ブロック２１２を完了した後、デバイス状態管理システムはブロック２１８に進むことができる。
【００５３】
ブロック２１４で、デバイス状態管理システムは、この時にプローブを送信することはネットワーク化された印刷デバイスを発見する一環でないことを示す、ＵｓｅＰｒｏｂｅ変数＝０を設定できる。例えば、予防システムメンテナンス発見アプローチを呼び出すことは、ブロック２１４の実行及びＵｓｅＰｒｏｂｅ＝０の設定を導くことができる。ブロック２１４を完了した後、デバイス状態管理システムはブロック２１８に進むことができる。
【００５４】
ブロック２１８で、デバイス状態管理システムは、ＩＰアドレスを照合することがネットワーク化された印刷デバイスを発見する一環であるか否かを判定できる。デバイス状態管理システムが、この時にＩＰアドレスを照合することがネットワーク化された印刷デバイスを発見する一環であると判定した場合、デバイス状態管理システムはブロック２２０に進むことができる。そうでなく、デバイス状態管理システムが、この時にＩＰアドレスを照合することがネットワーク化された印刷デバイスを発見する一環でないと判定した場合、デバイス状態管理システムはブロック２２２に進むことができる。
【００５５】
ブロック２２０で、デバイス状態管理システムは、この時にＩＰアドレスを照合することはネットワーク化された印刷デバイスを発見する一環であることを示す、ＵｓｅＮＡ変数＝１を設定でき、ブロック２２６に進むことができる。
【００５６】
ブロック２２２で、デバイス状態管理システムは、この時にＩＰアドレスを照合することはネットワーク化された印刷デバイスを発見する一環でないことを示す、ＵｓｅＮＡ変数＝０を設定でき、ブロック２２６に進むことができる。
【００５７】
ブロック２２６で、デバイス状態管理システムは、ＵｓｅＰｒｏｂｅ及びＵｓｅＮＡ変数の両方が共に０に等しいかを判定できる。ＵｓｅＰｒｏｂｅ及びＵｓｅＮＡ変数の両方が共に０に等しい場合、プローブ及びＩＰ照合のいずれもこの時に実施されず、ネットワーク化された印刷デバイスの発見がこの時に実施されないことを示す。そして、ＵｓｅＰｒｏｂｅ及びＵｓｅＮＡ変数の両方が共に０に等しい場合、デバイス状態管理システムはブロック２２８に進むことができる。そうでなく、ＵｓｅＰｒｏｂｅ及びＵｓｅＮＡ変数の少なくとも１つが０に等しくない場合、デバイス状態管理システムはブロック２３２に進むことができる。
【００５８】
ブロック２２８で、デバイス状態管理システムは、しばらくの間、例えば、１分間、３時間、半日、２１時間、１日間、待機できる。しばらくの待機後、デバイス状態管理システムはブロック２１０に進むことができる。実施形態によっては、方法２００は、しばらくの間待機する代わりに、ブロック２２８で終了できる。
【００５９】
ブロック２３２で、デバイス状態管理システムは、見当たらない印刷デバイスを評価するかカウントするか判定できる。見当たらないプリンタを査定することには、「見当たらない」又は未確認の印刷デバイスのアクティビティレベルの判定が含まれ、続いて、上記で説明されているように、未確認の印刷デバイスのアクティビティレベルを数学的に組み合わせ、システム不安定値を判定する。見当たらない印刷デバイスをカウントすることには、上記で説明されているように、未確認の印刷デバイスの数の維持及び未確認の印刷デバイスの数をシステム不安定値として利用することを伴う。
【００６０】
デバイス状態管理システムが見当たらない／未確認の印刷デバイスをカウントしようとする場合、デバイス状態管理システムはブロック２３４に進むことができる。そうでなく、デバイス状態管理システムが見当たらない／未確認の印刷デバイスを査定しようとする場合、デバイス状態管理システムはブロック２３６に進むことができる。
【００６１】
ブロック２３４で、デバイス状態管理システムはＵｓｅＲａｔｅ変数＝０を設定し、Ｔｈｒｅｓｈｏｌｄ変数＝ＣｏｕｎｔＴｈｒｅｓｈｏｌｄ値を設定できる。方法２００のＴｈｒｅｓｈｏｌｄ変数は、システム不安定レベルの閾値として使用され、上記で説明されているように、デバイスデータベースが不安定であるか否かを判定できる。ＣｏｕｎｔＴｈｒｅｓｈｏｌｄ値を判定する例として、デバイス状態管理システムに、Ｎ＞０である、Ｎ台の印刷デバイスに関するデータをデバイスデータベース内に持たせる。そして、上記で説明されているように、ＣｏｕｎｔＴｈｒｅｓｈｏｌｄ値は、１、１０、５０、６６、１００、５００等の未確認の印刷デバイスの所定の数、Ｎの１０％、Ｎの１５％、Ｎ＋１の２０％等のデバイスの割合及び／又はその他の技術を使用して判定される１以上の数値に基づくことができる。ＣｏｕｎｔＴｈｒｅｓｈｏｌｄ値を判定するその他の技術も考えられる。ブロック２３４の手順が完了すると、デバイス状態管理システムはブロック２４０に進むことができる。
【００６２】
ブロック２３６で、デバイス状態管理システムはＵｓｅＲａｔｅ変数＝１を設定でき、Ｔｈｒｅｓｈｏｌｄ変数＝ＲａｔｅＴｈｒｅｓｈｏｌｄ値を設定できる。例として、ＲａｔｅＴｈｒｅｓｈｏｌｄ値は、１日（又はその他の期間）あたりの見当たらない／未確認の印刷デバイスによって印刷されたページの累積数、見当たらない／未確認の印刷デバイスによって使用されたトナーの累積量又は使用されたトナーの割合、見当たらない／未確認の印刷デバイスによって及び／又は見当たらない／未確認の印刷デバイスから受信されたアラートの累積数、及び／又は上記で説明されている内容の組み合わせ等の１以上のアクティビティレベルに基づくことができる。ＲａｔｅＴｈｒｅｓｈｏｌｄ値を判定するその他の技術も考えられる。
【００６３】
ブロック２４０で、デバイス状態管理システムは、ネットワークアドレスのリストＬをＤＨＣＰサーバ１４４等のＤＨＣＰサーバから取得できる。
【００６４】
ラベル「Ｅ」に関連付けられたブロック２４４で、デバイス状態管理システムはＵｓｅＰｒｏｂｅ変数＝０であるか否か判定できる。ＵｓｅＰｒｏｂｅ変数が０と等しい場合、デバイス状態管理システムは、ラベル「Ｂ」に関連付けられたブロック２６６に進むことができる。そうでなく、ＵｓｅＰｒｏｂｅ変数が０と等しくない場合、デバイス状態管理システムはブロック２４８に進むことができる。
【００６５】
ブロック２４８、２５２、２５６、２６０及び２６２の手順はプローブメッセージを利用する発見技術に関する。ブロック２４８で、デバイス状態管理システムは、リストＬから印刷デバイスＰＤのネットワークアドレスＮＡを取得できる。そして、デバイス状態管理システムは、印刷デバイスＰＤのネットワークアドレスＮＡにプローブを送信できる。
【００６６】
ブロック２５２で、デバイス状態管理システムは、ブロック２４８で送信されたプローブに対する応答が印刷デバイスＰＤからであるか否か判定できる。デバイス状態管理システムがプローブに対する応答を受信した場合、デバイス状態管理システムは、ラベル「Ｃ」に関連付けられたブロック２５６に進むことができる。そうでなく、デバイス状態管理システムがプローブに対する応答を受信していない場合、デバイス状態管理システムはラベル「Ｄ」に関連付けられたブロック２６２に進むことができる。
【００６７】
図２Ｂを参照し、ラベル「Ｃ」に関連付けられたブロック２５６で、デバイス状態管理システムは、印刷デバイスＰＤからのプローブ応答の中のデータがデバイスデータベース内に記憶されたデータと一致するか否か判定できる。印刷デバイスＰＤからのプローブ応答の中のデータがデバイスデータベース内に記憶されたデータと一致する場合、デバイス状態管理システムはブロック２６０に進むことができる。そうでなく、印刷デバイスＰＤからのプローブ応答の中のデータがデバイスデータベース内に記憶されたデータと一致しない場合、デバイス状態管理システムはブロック２６２に進むことができる。
【００６８】
ブロック２６０で、デバイス状態管理システムは、印刷デバイスＰＤのデバイスデータベースエントリを確認済みとマーキングできる。また、デバイス状態管理システムは、現在の印刷デバイスＰＤが未確認又は「不良」印刷デバイスではないと示す、ＢａｄＰＤ変数＝０を設定できる。ブロック２６０の手順が完了すると、デバイス状態管理システムはブロック２６６に進むことができる。
【００６９】
ラベル「Ｄ」に関連付けられたブロック２６２で、デバイス状態管理システムは、印刷デバイスＰＤのデバイスデータベースエントリを「要照合」又は未確認とマーキングできる。また、デバイス状態管理システムは、現在の印刷デバイスＰＤが未確認／不良印刷デバイスであると示す、ＢａｄＰＤ変数＝１を設定できる。
【００７０】
ラベル「Ｂ」に関連付けられたブロック２６６で、デバイス状態管理システムはＵｓｅＮＡ変数が０に設定されているか否か判定できる。ＵｓｅＮＡ変数が０に等しい場合、デバイス状態管理システムは、ブロック２８０に進むことができる。そうでなく、ＵｓｅＮＡ変数が０に等しくない場合、デバイス状態管理システムは、ブロック２６８に進むことができる。
【００７１】
ブロック２６８、２７２、２７４及び２７６の手順は、デバイスデータベース内に記憶されたデータでリストＬのＩＰアドレスを照合することを利用する発見技術に関する。これらの発見技術は、以下に示されるようなプローブメッセージの使用を必要としない。ブロック２６８で、デバイス状態管理システムは、印刷デバイスＰＤのネットワークアドレスＮＡをリストＬから取得できる。
【００７２】
ブロック２７２で、デバイス状態管理システムは、デバイスデータベース内にネットワークアドレスＮＡに関連付けられているエントリがあるか否か判定できる。デバイスデータベース内にネットワークアドレスＮＡに関連付けられているエントリがある場合、デバイス状態管理システムはブロック２７４に進むことができる。そうでなく、デバイスデータベース内にネットワークアドレスＮＡに関連付けられているエントリがない場合、デバイス状態管理システムは、ブロック２７６に進むことができる。
【００７３】
ブロック２７４で、デバイス状態管理システムは、印刷デバイスＰＤのデバイスデータベースエントリを確認済みとマーキングできる。また、デバイス状態管理システムは、現在の印刷デバイスＰＤが未確認／不良印刷デバイスではないと示す、ＢａｄＰＤ変数＝０を設定できる。ブロック２７４の手順が完了すると、デバイス状態管理システムはブロック２８０に進むことができる。
【００７４】
ブロック２７６で、デバイス状態管理システムは、印刷デバイスＰＤのデバイスデータベースエントリを「要照合」又は未確認とマーキングできる。また、デバイス状態管理システムは、現在の印刷デバイスＰＤが未確認／不良印刷デバイスであると示す、ＢａｄＰＤ変数＝１を設定できる。
【００７５】
ブロック２８０で、デバイス状態管理システムは、ＢａｄＰＤ変数の数値が０、すなわち現在の印刷デバイスＰＤが未確認／不良印刷デバイスではないか否か判定できる。ＢａｄＰＤ変数の数値が０の場合、デバイス状態管理システムはブロック２８６に進むことができる。そうでなく、ＢａｄＰＤ変数の数値がゼロでない、すなわち現在の印刷デバイスＰＤが未確認／不良印刷デバイスである場合、デバイス状態管理システムはブロック２８２に進むことができる。
【００７６】
ブロック２８２で、デバイス状態管理システムは印刷デバイスＰＤのアクティビティレベル値ＡＬ１を判定できる。そして、デバイス状態管理システムは、図２Ｂで示される、次の数式：ＳＩ＝ＳＩ＋（（ＵｓｅＲａｔｅ）＊ＡＬ１）＋（１−ＵｓｅＲａｔｅ）を使用して、システム不安定値ＳＩを更新できる。方法２００では、上記のブロック２３４及び２３６に関連して説明されているように、ＵｓｅＲａｔｅの数値は０又は１のいずれかである。そして、ＵｓｅＲａｔｅ＝０の場合、数式：ＳＩ＝ＳＩ＋（（ＵｓｅＲａｔｅ）＊ＡＬ１）＋（１−ＵｓｅＲａｔｅ）は簡略化され、ＳＩ＝ＳＩ＋（１−ＵｓｅＲａｔｅ）→ＳＩ＝ＳＩ＋１となり、従って、ＳＩは値がインクリメントされ、未確認の印刷デバイスのカウントが更新される。ＵｓｅＲａｔｅ＝１の場合、数式：ＳＩ＝ＳＩ＋（（ＵｓｅＲａｔｅ）＊ＡＬ１）＋（１−ＵｓｅＲａｔｅ）は簡略化され、ＳＩ＝ＳＩ＋（ＵｓｅＲａｔｅ＊ＡＬ１）＋０→ＳＩ＝ＳＩ＋ＡＬ１となり、従って、ＳＩはＳＩの前の数値にＡＬ１値を加算することで更新され、未確認の印刷デバイスのアクティビティレベルの合計が更新される。
【００７７】
ブロック２８６で、デバイス状態管理システムは、判断すべきデバイスがもっとあるか否か判定できる。判断とは、リストＬ内の全てのアドレスが照合されたか、デバイスデータベース内の全てのエントリが確認済み又は要照合のいずれかにマーキングされているか、方法２００の実行のために割り当てられた時間及び／又は他のリソースが消費されたか等である。判断すべきデバイスがもっとある場合、デバイス状態管理システムはラベル「Ｅ」に関連付けられたブロック２４４に進むことができる。そうでなく、これ以上判断すべきデバイスがない場合、デバイス状態管理システムはブロック２９０に進むことができる。
【００７８】
ブロック２９０で、デバイス状態管理システムは、システム不安定値ＳＩがＴｈｒｅｓｈｏｌｄ値よりも大きいか否か判定できる。ＳＩがＴｈｒｅｓｈｏｌｄよりも大きい場合、デバイス状態管理システムはブロック２９２に進むことができる。そうでなく、ＳＩがＴｈｒｅｓｈｏｌｄよりも大きくない場合、デバイス状態管理システムは、ラベル「Ａ」に関連付けられたブロック２１０に進むことができる。
【００７９】
ブロック２９２で、デバイス状態管理システムは、デバイスデータベースをリフレッシュすることでシステムを安定化できる。デバイスデータベースをリフレッシュすることは、未確認の印刷デバイスに関連付けられているＩＰアドレスのクラスタを生成すること、生成されたクラスタ内で印刷デバイスをプローブすること、プローブ応答に基づいてデバイスデータベースを更新すること、及びシステム不安定レベルＳＩを０にリセットすることを含むことができる。システムを安定化すること及びデバイスデータベースをリフレッシュすることはまた、少なくとも下記の方法５００並びに図５Ａ及び５Ｂと関連して説明されている。安定化した／リフレッシュしたデバイスデータベースは、安定化した／リフレッシュしたデバイスデータベース内に記憶されたデータに基づく印刷デバイス用の交換可能品（例えば、トナー）の注文、デバイスステータスのチェック及び／又はその他の機能等のプリンタ関連機能を実施するために使用できる。ブロック２９２の手順が完了すると、デバイス状態管理システムは、ラベル「Ａ」に関連付けられたブロック２１０に進むことができる。
【００８０】
図３Ａ、３Ｂ及び３Ｃは、例示の実施形態に係る印刷ネットワーク１００と同様の印刷システムが不安定だと判定され、デバイスデータベースがシステム安定化中にリフレッシュされるシナリオ３００を示す。シナリオ３００は、ＵｓｅＮＡ変数が０に設定され、ＵｓｅＰｒｏｂｅ変数が１に設定される、つまりデバイスデータベースが最新か否か判定するためにプローブが使用される場合の方法２００に従うデバイス状態管理システム１１２を伴うことができる。
【００８１】
シナリオ３００では、デバイス状態管理システム１１２は、印刷デバイス１３０、１４２及び３１０にプローブを送信する。シナリオ３００では、印刷デバイス１３０へのプローブはデバイスデータベース内に記憶されている一貫した情報を返信するので、デバイスデータベース内の印刷デバイス１３０のためのエントリは確認済みとマーキングされる。印刷デバイス１４２へ送信されたプローブはデバイスデータベースと一貫性のない情報を返信するので、デバイスデータベース内の印刷デバイス１４２のためのエントリは要照合とマーキングされ、システム不安定値ＳＩが更新される。印刷デバイス３１０へ送信されたプローブは応答なしに時間切れとなるので、デバイスデータベース内の印刷デバイス３１０のためのエントリは要照合とマーキングされ、システム不安定値ＳＩが更新される。
【００８２】
シナリオ３００では、システム不安定値ＳＩが閾値を超えるので、デバイス状態管理システム１１２は、照合が必要又は危殆化したデバイスデータベースからＩＰアドレスを入手し、返信されたＩＰアドレスをクラスタ化する。デバイス状態管理システム１１２は続いて、ＩＰアドレスのクラスタ内のデバイスにプローブを送信する。これらのプローブ送信には、印刷デバイス１４２及び３１０にプローブを送信することが含まれる。続いて、デバイス状態管理システム１１２は、プローブ応答に従ってデバイスデータベースを更新し、システム不安定値ＳＩを０にリセットする。
【００８３】
シナリオ３００は、デバイス状態管理システム１１２が方法２００を実行することを含む。シナリオ３００の開始に先立って、ＵｓｅＮＡ変数は０に設定され、ＵｓｅＰｒｏｂｅ変数は１に設定され、リストＬはＤＨＣＰサーバ１４４から取得されている。図３Ａは、デバイス状態管理システム１１２がプローブ３２０を生成し、印刷デバイス１３０に送信するところからシナリオ３００が開始することを示す。印刷デバイス１３０は続いて、プローブ応答３２２を生成し、デバイス状態管理システム１１２に送信する。プローブ応答３２２には、ＩＰアドレス「ＩＰ１３０」、機種名「Ｎａｍｅ１３０」及びシリアル番号「ＳｅｒＮｏ１３０」が含まれる。その他のシナリオでは、プローブ応答３２２等のプローブ応答は、印刷デバイス１３０等のデバイスについてのより少ない、より多い及び／又は異なる情報を含むことができる。例えば、デバイス名、完全修飾ドメイン名（ＦＱＤＮ）等のドメイン名、ソフトウェア、ハードウェア、記憶部及び／又はファームウェアの情報、媒体アクセス制御（ＭＡＣ）及び／又はイーサネット（登録商標）アドレス情報等だが、これらに限らないＩＰアドレス以外のアドレス情報、１以上のタイムスタンプ、ハッシュ値／奇偶検査情報である。
【００８４】
プローブ応答３２２を受信すると、デバイス状態管理システム１１２は、ブロック３２４の手順を実施して、「ＩＰ１３０」のＩＰアドレスを有するデバイスのデバイスデータベースからエントリ「ＥＮＴＲＹ０」を入手できる。
【００８５】
図３Ｃは、デバイスデータベースの形式１１４ａ、１１４ｂ、１１４ｃ、１１４ｄを示す。形式１１４ａ、１１４ｂ、１１４ｃ、１１４ｄがそれぞれ、シナリオ３００の３つの印刷デバイスの３つのエントリを記憶していることが示されている。デバイスデータベース形式１１４ａ、１１４ｂ、１１４ｃ及び１１４ｄはそれぞれ、（１）「ＥＮＴＲＹ０」、「ＥＮＴＲＹ１」及び「ＥＮＴＲＹ２」である３つのエントリの名前を示す「エントリ名」情報、（２）「ＤＤ＿ＩＰ１３０」、「ＤＤ＿ＩＰ１４２」及び「ＤＤ＿ＩＰ３１０」の各「ＩＰアドレス」、（３）「確認済み」、「要照合」及び「要照合」の各エントリの各「状態」、及び（４）「ｘｘ．ｘ％」、「ｙｙ．ｙ％」及び「ｚｚ．ｚ％」の各「トナー」値を有する。実施形態によっては、いくつか又は全ての形式１１４ａ、１１４ｂ、１１４ｃ、１１４ｄは、エントリ名を含まなくてもよい及び／又はエントリ名を数字、その他の英数字及び／又はバイナリキーに代えてもよい。
【００８６】
印刷デバイスのトナー値は、印刷デバイスのデバイスアクティビティレベルの一例であることができる。印刷デバイスのその他のデバイスアクティビティレベルの例としては、ページカウンタ等の印刷デバイスから取得されるカウンタ数値、印刷デバイスにより生成されるアラートの数及び／又は種類、これらの数値の変更率（例えば、１日毎のトナー使用率、ページカウンタ値の差に基づいて判定される週毎の印刷ページ数）及びそれらの組み合わせが挙げられる。実施形態によっては、これらのデバイスアクティビティレベルのいくつか又は全てが、デバイスデータベース１１４に記憶されることができる。
【００８７】
図３Ｃの上部に示されるデバイスデータベース形式１１４ａは、エントリ毎に「デバイス名」も含む。エントリＥＮＴＲＹ０、ＥＮＴＲＹ１及びＥＮＴＲＹ２の各デバイス名は、「ＰＤ１３０」、「ＰＤ１４２」及び「ＰＤ３１０」である。図３Ｃの下部に示されるデバイスデータベース形式１１４ｄも、デバイスデータベース形式１１４ａに示されるのと同じデバイス名を含む。図３Ｃの中央部上側には、デバイスデータベース形式１１４ｂが示され、上述のエントリ名、ＩＰアドレス及び状態情報と共に「シリアルＮｏ．」及び「機種名」情報が含まれる。デバイスデータベース形式１１４ｂ及び１１４ｃ（図３Ｃの中央部下側に示される）は、両方とも各エントリＥＮＴＲＹ０、ＥＮＴＲＹ１及びＥＮＴＲＹ２の「シリアルＮｏ．」情報である「ｘｘｘｘｘｘｘｘｘ」、「ｙｙｙｙｙｙｙｙｙ」及び「ｚｚｚｚｚｚｚｚｚ」を有し、両方とも各エントリの各「機種名」情報である「ＸＸＸ」、「ＹＹＹ」及び「ＺＺＺ」を有する。デバイスデータベース形式１１４ｃはまた、各エントリＥＮＴＲＹ０、ＥＮＴＲＹ１及びＥＮＴＲＹ２の「デバイス名」情報である「ＸＸＸ−ｘｘｘｘｘｘｘｘｘ」、「ＹＹＹ−ｙｙｙｙｙｙｙｙｙ」及び「ＺＺＺ−ｚｚｚｚｚｚｚｚｚ」を含む。つまり、デバイスデータベース形式１１４ｃ内のデバイス名は、各機種名と、「−」の記号と、各シリアル番号を連結したものである。従って、その他のシナリオでは、デバイスデータベース形式１１４ｃで使用されるシリアル番号及び機種名情報又はデバイス名情報のいずれかが、不必要として取り除かれ得る。１１４ａ〜１１４ｄ以外のデバイスデータベース形式も考えられる。例えば、形式１１４ａはデバイス名と共に又はデバイス名に代えて機種名を記憶できる。
【００８８】
シナリオ３００では、デバイスデータベース１１４はデバイスデータベース形式１１４ｄを使用する。
【００８９】
図３Ａのブロック３２４に戻り、ＩＰアドレス「ＩＰ１３０」と一致するとしてＥＮＴＲＹ０がデバイスデータベース１１４内で見つかると、続いて、ＩＰアドレス「ＩＰ１３０」はＥＮＴＲＹ０のデバイスデータベース内に記憶されたＩＰアドレス「ＤＤ＿ＩＰ１３０」と一致する。シナリオ３００では、デバイスデータベース１１４はＥＮＴＲＹ０をシリアル番号である「ｘｘｘｘｘｘｘｘｘ」及び機種名である「ＸＸＸ」と共に記憶する。デバイス状態管理システム１１２はデバイスデータベース１１４からシリアル番号「ｘｘｘｘｘｘｘｘｘ」を変数「ＤＤ＿ＳｅｒＮｏ１３０」として読み出し、機種名「ＸＸＸ」を変数「ＤＤ＿Ｎａｍｅ１３０」として読み出す。
【００９０】
ブロック３２６で、デバイス状態管理システム１１２は、プローブ応答３２２からの情報ＩＰ１３０、Ｎａｍｅ１３０及びＳｅｒＮｏ１３０をデバイスデータベース１１４からの各情報ＤＤ＿ＩＰ１３０、ＤＤ＿Ｎａｍｅ１３０及びＤＤ＿ＳｅｒＮｏ１３０と比較し、プローブ応答情報が印刷デバイス１３０／ＥＮＴＲＹ０のデバイスデータベース情報と一致することを判定する。デバイス状態管理システム１１２は続いて、デバイスデータベース１１４のＥＮＴＲＹ０を、図３Ｃに示されるように、「確認済み」とマーキングする。
【００９１】
図３Ａは、デバイス状態管理システム１１２のプローブ３３０の生成及び印刷デバイス１４２への送信に続くシナリオ３００を示す。印刷デバイス１４２は続いて、プローブ応答３３２を生成し、デバイス状態管理システム１１２へ送信する。プローブ応答３３２はＩＰアドレス「ＩＰ１４２」、機種名「Ｎａｍｅ１４２」及びシリアル番号「ＳｅｒＮｏ１４２」を含む。
【００９２】
プローブ応答３３２を受信すると、デバイス状態管理システム１１２はブロック３３４の手順を実施し、「ＩＰ１４２」のＩＰアドレスを有するデバイスのエントリ「ＥＮＴＲＹ１」をデバイスデータベース１１４から入手する。シナリオ３００では、デバイスデータベース１１４のＥＮＴＲＹ１はシリアル番号「ｙｙｙｙｙｙｙｙｙ」及び機種名「ＹＹＹ」を含む。デバイス状態管理システム１１２は、デバイスデータベース１１４からのシリアル番号「ｙｙｙｙｙｙｙｙｙ」を変数「ＤＤ＿ＳｅｒＮｏ１４２」で、機種名「ＹＹＹ」を変数「ＤＤ＿Ｎａｍｅ１４２」で記憶する。
【００９３】
ブロック３３６で、デバイス状態管理システム１１２は、プローブ応答３３２からの情報ＩＰ１４２、Ｎａｍｅ１４２及びＳｅｒＮｏ１４２をデバイスデータベース１１４からの各情報ＤＤ＿ＩＰ１４２、ＤＤ＿Ｎａｍｅ１４２及びＤＤ＿ＳｅｒＮｏ１４２と比較し、プローブ応答情報が印刷デバイス１４２／ＥＮＴＲＹ１のデバイスデータベース情報と一致しないことを判定する。デバイス状態管理システム１１２は続いて、デバイスデータベース１１４のＥＮＴＲＹ１を、図３Ｃに示されるように、「要照合」とマーキングする。
【００９４】
ブロック３３６の手順の一環として、デバイス状態管理システム１１２は続いて、システム不安定値ＳＩを更新して、印刷デバイス１４２のプローブ応答３３２で受信したデータがデバイスデータベース１１４内に記憶されたデータと一貫性がないため、印刷ネットワークがより不安定であると示す。シナリオ３００では、見当たらないプリンタがカウントされているので、方法２００のＵｓｅＲａｔｅ変数は０に設定され、ＣｏｕｎｔＴｈｒｅｓｈｏｌｄ変数は１に設定されている。そして、デバイス状態管理システム１１２は、ＳＩの値を１と等しくなるようインクリメントさせることでシステム不安定値ＳＩを更新する。
【００９５】
デバイス状態管理システム１１２のプローブ３４０の生成及び印刷デバイス３１０への送信にシナリオ３００は続く。シナリオ３００では、印刷デバイス３１０はプローブ３４０が送信される時に電源が切られるので、印刷デバイス３１０はプローブ３４０に応答しない。
【００９６】
ブロック３４２で、デバイス状態管理システム１１２はプローブ３４０の応答待ちの時間切れとなる。ブロック３４４で、方法２００に従って、デバイスデータベース１１４内の印刷デバイス３１０のエントリＥＮＴＲＹ２は、図３Ｃに示されるように、「要照合」とマーキングされる。ブロック３４４の手順の一環として、続いて、印刷デバイス３１０のプローブ応答が受信されなかったため、デバイス状態管理システム１１２は、システム不安定値ＳＩを更新して印刷ネットワークがより不安定であると示す。シナリオ３００のこの段階では、デバイス状態管理システム１１２はＳＩを２と等しくなるようインクリメントさせることでシステム不安定値ＳＩを更新する。
【００９７】
図３Ｂを参照し、ブロック３５０で、デバイス状態管理システム１１２は、２であるシステム不安定値ＳＩが、１であるＴｈｒｅｓｈｏｌｄ値を超えていることを判定する。
【００９８】
ブロック３５２で、デバイス状態管理システム１１２は、照合の必要がある又は危殆化したエントリ、すなわち、状態フィールドが「要照合」又は「危殆」と同等であるエントリをデバイスデータベース１１４に問い合わせる。少なくともエントリＥＮＴＲＹ１及びＥＮＴＲＹ２が、この問い合わせの結果としてデバイスデータベース１１４から読み出される。読み出されたエントリからデバイス状態管理システム１１２は、エントリのＩＰアドレスフィールドに記憶されたＩＰアドレスを選択し、ＩＰアドレスのリスト「ＩＰ＿ＣＨＥＣＫ」を形成する。従って、ＩＰ＿ＣＨＥＣＫはＩＰアドレスＤＤ＿ＩＰ１４２及びＤＤ＿ＩＰ３１０を含む。
【００９９】
ブロック３５４で、デバイス状態管理システム１１２は、ＩＰアドレスの、ｎ＞０である、ｎ個のクラスタＣ１、Ｃ２…Ｃｎを、ブロック３５２で生成されたＩＰ＿ＣＨＥＣＫリストから生成する。クラスタは、少なくとも図５Ａ及び５Ｂと関連して下記でより詳細に説明されている、自然分類技術等のベクトル量子化技術を使用して生成されることができる。
【０１００】
ブロック３５６で、デバイス状態管理システム１１２は、プローブを送信するクラスタＣ１を選択し、クラスタＣ１内のＩＰアドレスにミドルアウトからプローブを送信する。例えば、クラスタＣ１が、ＩＰ＿ＨＩＧＨ＞ＩＰ＿ＬＯＷである、ＩＰアドレスの範囲［ＩＰ＿ＬＯＷ、ＩＰ＿ＨＩＧＨ］を含むようにする。すると、デバイス状態管理システム１１２は、この範囲の中間アドレスをＩＰ＿ＭＩＤ＝（ＩＰ＿ＬＯＷ＋ＩＰ＿ＨＩＧＨ）／２と判定できる。そして、クラスタＣ１のミドルアウトからプローブを送信するために、デバイス状態管理システム１１２は次のようにＩＰアドレスにプローブを送信できる。第１のプローブを中間アドレスＩＰ＿ＭＩＤへ送信し、第２のプローブをＩＰアドレスＩＰ＿ＭＩＤ＋１（又はＩＰ＿ＭＩＤ−１）へ送信し、第３のプローブをＩＰアドレスＩＰ＿ＭＩＤ−１（又はＩＰ＿ＭＩＤ＋１）へ送信し、第４のプローブをＩＰアドレスＩＰ＿ＭＩＤ＋２（又はＩＰ＿ＭＩＤ−２）へ送信し、第５のプローブをＩＰアドレスＩＰ＿ＭＩＤ−２（又はＩＰ＿ＭＩＤ＋２）へ送信し、最終的にＩＰアドレスＩＰ＿ＨＩＧＨ及びＩＰ＿ＬＯＷ（又はその反対）にプローブを送信するまで続ける。
【０１０１】
クラスタＣ１内のＩＰアドレスにプローブを送信する一環として、デバイス状態管理システム１１２は、プローブメッセージ３６０を生成して、印刷デバイス３１０に送信する。それに応じて、印刷デバイス３１０はプローブ応答３６２を生成して、デバイス状態管理システム１１２に送信する。プローブ応答３６２は、ＩＰアドレス「ＩＰ３１０」、機種名「Ｎａｍｅ３１０」及びシリアル番号「ＳｅｒＮｏ３１０」を含む。
【０１０２】
ブロック３７０で、デバイス状態管理システム１１２は、プローブ応答３６２からのデータ、例えば、ＩＰアドレスＩＰ３１０、機種名Ｎａｍｅ３１０及びシリアル番号ＳｅｒＮｏ３１０で、デバイスデータベース１１４の印刷デバイス３１０のエントリＥＮＴＲＹ２を更新する。つまり、デバイス状態管理システム１１２は、デバイスデータベース１１４に書き込む。値ＩＰ３１０をエントリＥＮＴＲＹ２のＩＰアドレスフィールドに書き込み、値Ｎａｍｅ３１０をエントリＥＮＴＲＹ２の機種名フィールドに書き込み、値ＳｅｒＮｏ３１０をエントリＥＮＴＲＹ２のシリアルＮｏ．フィールドに書き込む。例によっては、デバイス状態管理システム１１２は、デバイスデータベース１１４のエントリＥＮＴＲＹ２の状態フィールドに「確認済み」の（又は同様の）値を書き込むことができる。シナリオ３００は、クラスタＣ１にプローブを送信し終えたデバイス状態管理システム１１２で継続する。
【０１０３】
ブロック３７２で、デバイス状態管理システム１１２は、プローブを送信するクラスタＣ２を選択し、ミドルアウトからクラスタＣ２内のＩＰアドレスにプローブを送信する。クラスタのミドルアウトからＩＰアドレスにプローブを送信することは、上記でブロック３５６に関して説明されている。
【０１０４】
ブロック３７４で、デバイス状態管理システム１１２は、プローブを送信するクラスタＣｎを選択し、ミドルアウトからクラスタＣｎ内のＩＰアドレスにプローブを送信する。クラスタのミドルアウトからＩＰアドレスにプローブを送信することは、上記でブロック３５６に関して説明されている。
【０１０５】
クラスタＣｎ内のＩＰアドレスにプローブを送信する一環として、デバイス状態管理システム１１２はプローブメッセージ３８０を生成して、印刷デバイス１４２に送信する。それに応じて、印刷デバイス１４２は、プローブ応答３８２を生成して、デバイス状態管理システム１１２に送信する。プローブ応答３８２はＩＰアドレス「ＩＰ１４２」、機種名「Ｎａｍｅ１４２」及びシリアル番号「ＳｅｒＮｏ１４２」を含む。
【０１０６】
ブロック３９０で、デバイス状態管理システム１１２は、プローブ応答３８２からのデータ、例えば、ＩＰアドレスＩＰ１４２、機種名Ｎａｍｅ１４２及びシリアル番号ＳｅｒＮｏ１４２で、デバイスデータベース１１４の印刷デバイス１４２用のエントリＥＮＴＲＹ１を更新する。つまり、デバイス状態管理システム１１２はデバイスデータベース１１４に書き込む。値ＩＰ１４２をエントリＥＮＴＲＹ１のＩＰアドレスフィールドに書き込み、値Ｎａｍｅ１４２をエントリＥＮＴＲＹ１の機種名フィールドに書き込み、値ＳｅｒＮｏ１４２をエントリＥＮＴＲＹ１のシリアルＮｏ．フィールドに書き込む。例によっては、デバイス状態管理システム１１２は、デバイスデータベース１１４のエントリＥＮＴＲＹ１の状態フィールドに「確認済み」の（又は同様の）値を書き込むことができる。
【０１０７】
シナリオ３００は、クラスタＣｎにプローブを送信し終えたデバイス状態管理システム１１２で継続する。クラスタＣｎがブロック３５４で生成されたクラスタの最後のクラスタであるため、ＳＩがＴｈｒｅｓｈｏｌｄより大きいと判定された後のブロック３５０で開始された発見処理は完了でき、従って、システム不安定値ＳＩを０に設定できる。ブロック３９０の手順が完了すると、シナリオ３００を完了できる。
【０１０８】
図４Ａ、４Ｂ、４Ｃ及び４Ｄは、例示の実施形態に係るデバイスデータベース内のデータがリフレッシュされるシナリオ４００を示す。シナリオ４００では、デバイスデータベース１１４内のデータをリフレッシュするために、本明細書中に説明されている予防システムメンテナンス発見アプローチが使用され、形式１１４ａで使用されたトナー値がページカウント値に代わっていることを除き、形式１１４ａと同様のデバイスデータベース形式を利用する。方法２００に関連して、ＵｓｅＮＡ変数は、１に設定され、ＵｓｅＰｒｏｂｅ変数は０に設定される。
【０１０９】
デバイスデータベース１１４は、印刷デバイス１４２、印刷デバイス４１０及び印刷デバイス４２０の３つの印刷デバイスを含む印刷ネットワーク１００と同様の印刷システムについてのデータを記憶する。シナリオ４００の開始時のデバイスデータベース１１４の内容は、図４Ｂに示される。
【０１１０】
シナリオ４００は、デバイス状態管理システム１１２がＤＨＣＰサーバ１４４にＩＰアドレスを要求することから始まる。ＩＰアドレスは、ＤＨＣＰサーバ１４４からデバイス状態管理システム１１２にリスト「ＩＰＬｉｓｔ」として提供される。ＩＰＬｉｓｔを受信後、デバイス状態管理システム１１２はＩＰＬｉｓｔをデバイスデータベース１１４に統合する。ＩＰＬｉｓｔをデバイスデータベース１１４に統合する一環として、デバイス状態管理システム１１２は、デバイスデータベース１１４内にまだ存在しない３つのＩＰアドレスの新たなエントリを追加し、ＩＰＬｉｓｔに基づいて既存のエントリの状態情報を更新する。
【０１１１】
図４Ａは、デバイス状態管理システム１１２が、ＧｅｔＩＰＡｄｄｒｅｓｓｅｓメッセージ４３０を生成し、ＤＨＣＰサーバ１４４に送信して始まるシナリオ４００を示す。ＧｅｔＩＰＡｄｄｒｅｓｓｅｓメッセージ４３０に応じて、ＤＨＣＰサーバ１４４は、ＤＨＣＰサーバ１４４によって既知のＩＰアドレスのリスト「ＩＰＬｉｓｔ」付のＩＰＡｄｄｒｅｓｓｅｓメッセージ４３２を生成及び送信する。
【０１１２】
ＩＰＡｄｄｒｅｓｓｅｓメッセージ４３２を受信すると、デバイス状態管理システム１１２はブロック４４０の手順を行って、ＩＰＬｉｓｔをデバイスデータベース１１４に統合する。ＩＰＬｉｓｔをデバイスデータベース１１４に統合するには、デバイス状態管理システム１１２はデバイスデータベース１１４にＩＰＬｉｓｔ内の各ＩＰアドレスを問い合わせ、問い合わせたＩＰアドレスのエントリがデバイスデータベース１１４内に存在するか否かを判定できる。このようなエントリが存在する場合、そのエントリは確認済みと考えられる。そうでなく、問い合わせたＩＰアドレスのエントリが存在しない場合、デバイス状態管理システム１１２は、デバイスデータベース１１４に問い合わせたＩＰアドレスのエントリを追加できる。
【０１１３】
図４Ｂは、ＩＰＬｉｓｔの統合より前のデバイスデータベース１１４の内容を示す。特に、デバイスデータベース１１４は、各ＩＰアドレスである「ＤＤ＿ＩＰ１３０」、「ＤＤ＿ＩＰ１４２」及び「ＤＤ＿ＩＰ３１０」、各デバイス名「ＰＤ１３０」、「ＰＤ１４２」及び「ＰＤ３１０」、各状態である「要照合」、「要照合」及び「要照合」、並びに各「ページカウント」値である「ａａａ」、「ｂｂｂ」及び「ｃｃｃ」を記憶する「ＥＮＴＲＹ１」、「ＥＮＴＲＹ２」及び「ＥＮＴＲＹ３」の３つのエントリを含む。
【０１１４】
図４Ｃは、ＩＰＬｉｓｔ４３４としてＩＰＡｄｄｒｅｓｓｅｓメッセージ４３２で返信されたＩＰＬｉｓｔの内容を示す。ＩＰＬｉｓｔ４３４は、印刷デバイス３１０のＩＰアドレスである「ＩＰＬｉｓｔ１＿Ａｄｄ０」、印刷デバイス１４２のＩＰアドレスである「ＩＰＬｉｓｔ１＿Ａｄｄ１」、デバイス４１０のＩＰアドレスである「ＩＰＬｉｓｔ１＿Ａｄｄ２」及びデバイス４２０のＩＰアドレスである「ＩＰＬｉｓｔ１＿Ａｄｄ３」の４つのＩＰアドレスを含む。シナリオ４００では、デバイス４１０は非印刷デバイスで、ＩＰＬｉｓｔ１＿Ａｄｄ３のＩＰアドレスに「デバイス４２０／ＰＤ４２０」の注釈で示されるように、デバイス４２０は印刷デバイスである。なお、図４Ｃの挿入的な注釈は、ＩＰＡｄｄｒｅｓｓｅｓメッセージ４３２で提供されるＩＰＬｉｓｔ４３４の一部ではない。むしろ、これらの注釈は説明の目的のみで図４Ｃに示されている。例によっては、ＩＰＬｉｓｔ４３４は、下記の表１に示されるような数値を有するＩＰｖ４形式の実際のＩＰアドレスを有することができる。
【表１】
2019003617.tif 000003
その他の例では、ＩＰＬｉｓｔ４３４は、ＩＰｖ６又はおそらく他の形式の実際のＩＰアドレスを有することができる。
【０１１５】
図４Ａに戻り、デバイス状態管理システム１１２は、デバイスデータベースにＩＰＬｉｓｔからのＩＰＬｉｓｔ１＿Ａｄｄ０を問い合わせ、ＩＰＬｉｓｔ１＿Ａｄｄ０と等しいＩＰアドレスＤＤ＿ＩＰ３１０を有するエントリＥＮＴＲＹ３を見つける。デバイスデータベース１１４は、ＩＰＬｉｓｔからのＩＰＬｉｓｔ１＿Ａｄｄ０に対応するＥＮＴＲＹ３を有するため、デバイス状態管理システム１１２はＥＮＴＲＹ３の状態を「確認済み」とマーキングする。
【０１１６】
ブロック４４２で、デバイス状態管理システム１１２は、３つの新たなエントリをデバイスデータベース１１４に追加する。より具体的には、デバイス状態管理システム１１２は、デバイスデータベース１１４にＩＰＬｉｓｔからのＩＰＬｉｓｔ１＿Ａｄｄ１を問い合わせるが、ＩＰＬｉｓｔ１＿Ａｄｄ１の特定のエントリは見つけない。シナリオ４００で、ＩＰＬｉｓｔからのＩＰＬｉｓｔ１＿Ａｄｄ１及びデバイスデータベース１１４内のＥＮＴＲＹ２の両方は、印刷デバイス１４２に関連付けられているが、ＩＰＬｉｓｔ１＿Ａｄｄ１は、デバイスデータベース１１４のＥＮＴＲＹ２と記憶されるＤＤ＿ＩＰ１４２とは異なる。従って、デバイスデータベース１１４内でのＩＰＬｉｓｔ１＿Ａｄｄ１の問い合わせは、失敗する。デバイスデータベース１１４は、ＩＰＬｉｓｔからのＩＰＬｉｓｔ１＿Ａｄｄ１に対応するエントリを持たないため、デバイス状態管理システム１１２は、デバイスデータベース１１４にエントリ「ＥＮＴＲＹ４ａ」を、ＩＰＬｉｓｔ１＿Ａｄｄ１のＩＰアドレス及び「要照合」の状態付きで追加し、デバイス名及びページカウントのフィールドを、図４Ｄで、「――――」で表されるデフォルト値に設定する。
【０１１７】
そして、デバイス状態管理システム１１２は、デバイスデータベース１１４にＩＰＬｉｓｔからのＩＰＬｉｓｔ１＿Ａｄｄ２を問い合わせるが、ＩＰＬｉｓｔ１＿Ａｄｄ２の特定のエントリは見つけない。シナリオ４００では、ＩＰＬｉｓｔ１＿Ａｄｄ２及び関連付けられているデバイス４１０のいずれもデバイスデータベース１１４内のデータによって表されていない。従って、デバイスデータベース１１４内でのＩＰＬｉｓｔ１＿Ａｄｄ２の問い合わせは、失敗する。デバイスデータベース１１４は、ＩＰＬｉｓｔからのＩＰＬｉｓｔ１＿Ａｄｄ２に対応するエントリを持たないため、デバイス状態管理システム１１２は、デバイスデータベース１１４にエントリ「ＥＮＴＲＹ５ａ」を、ＩＰＬｉｓｔ１＿Ａｄｄ２のＩＰアドレス及び「要照合」の状態付きで追加し、デバイス名及びページカウントのフィールドを、デフォルト値に設定する。
【０１１８】
さらに、デバイス状態管理システム１１２は、デバイスデータベース１１４に、ＩＰＬｉｓｔからのＩＰＬｉｓｔ１＿Ａｄｄ３を問い合わせるが、ＩＰＬｉｓｔ１＿Ａｄｄ３の特定のエントリは見つけない。シナリオ４００では、ＩＰＬｉｓｔ１＿Ａｄｄ３及び関連付けられているデバイス４２０のいずれもデバイスデータベース１１４内のデータによって表されていない。従って、デバイスデータベース１１４内でのＩＰＬｉｓｔ１＿Ａｄｄ３の問い合わせは、失敗する。デバイスデータベース１１４は、ＩＰＬｉｓｔからのＩＰＬｉｓｔ１＿Ａｄｄ３に対応するエントリを持たないため、デバイス状態管理システム１１２は、デバイスデータベース１１４にエントリ「ＥＮＴＲＹ６ａ」を、ＩＰＬｉｓｔ１＿Ａｄｄ３のＩＰアドレス及び「要照合」の状態付きで追加し、デバイス名及びページカウントのフィールドを、デフォルト値に設定する。
【０１１９】
図４Ｄは、ＥＮＴＲＹ６ａが追加された後のデバイスデータベース１１４を示す。デバイスデータベース１１４内の６つのエントリのうちの５つは「要照合」の状態である。シナリオによっては、デバイスデータベース１１４は、シナリオ４００のこの段階では、デバイスデータベース１１４内の５／６のデータが要照合とマーキングされているため、不安定と考えることができる。
【０１２０】
図４Ａのブロック４４４で、ＩＰＬｉｓｔ内のどのＩＰアドレスも、ＥＮＴＲＹ１のＩＰアドレスであるＤＤ＿ＩＰ１３０に対応しないと判定されることができ、よって、ＥＮＴＲＹ１の状態は「要照合」のままとなることができる。ブロック４４４の手順が完了すると、シナリオ４００は完了できる。
【０１２１】
図４Ｅ、４Ｆ、４Ｇ及び４Ｈは、例示の実施形態に係るデバイスデータベース内のデータがリフレッシュされるシナリオ４００ａを示す。シナリオ４００ａでは、デバイスデータベース１１４内のデータをリフレッシュするために、本明細書中に説明されている状況的システム安定化発見アプローチが使用され、形式１１４ａで使用されたトナー値がページカウント値に代わっていることを除き、形式１１４ａと同様のデバイスデータベース形式を利用する。方法２００に関連して、ＵｓｅＮＡ変数は０に設定され、ＵｓｅＰｒｏｂｅ変数は１に設定される。
【０１２２】
両方のシナリオで、デバイスデータベース１１４が当初同じデータを有する点で、シナリオ４００ａはシナリオ４００と類似する。また、ＤＨＣＰサーバ１４４により提供されるＩＰＬｉｓｔデータは、両方のシナリオで同じである。しかしながら、上述のように、シナリオ４００では、予防システムメンテナンス発見アプローチを使用して、ＩＰＬｉｓｔからのデータをデバイスデータベース１１４に統合する一方、シナリオ４００ａでは、状況的システム安定化発見アプローチを使用して、ＩＰＬｉｓｔからのデータをデバイスデータベース１１４に統合する。
【０１２３】
シナリオ４００ａの開始時、デバイスデータベース１１４は、シナリオ４００と関連して上記で説明されているように、印刷デバイス１４２、印刷デバイス４１０及び印刷デバイス４２０の３つの印刷デバイスを含む印刷ネットワーク１００と同様の印刷システムについての同じデータを記憶する。シナリオ４００ａの開始時のデバイスデータベース１１４の内容は、（図４Ｂに示されるのと同じ）図４Ｆに示される。
【０１２４】
シナリオ４００ａは、デバイス状態管理システム１１２がＤＨＣＰサーバ１４４にＩＰアドレスを要求することから始まる。ＩＰアドレスは、ＤＨＣＰサーバ１４４からデバイス状態管理システム１１２にリスト「ＩＰＬｉｓｔ」として提供される。ＩＰＬｉｓｔを受信後、デバイス状態管理システム１１２はＩＰＬｉｓｔをデバイスデータベース１１４に統合する。ＩＰＬｉｓｔをデバイスデータベース１１４に統合する一環として、デバイス状態管理システム１１２は、デバイスデータベース１１４内にまだ存在しない３つのＩＰアドレスの新たなエントリを追加し、ＩＰＬｉｓｔに基づいて既存のエントリの状態情報を更新し、プローブメッセージを送信してデバイスデータベース１１４内のデータを確認する。
【０１２５】
図４Ｅは、デバイス状態管理システム１１２がＧｅｔＩＰＡｄｄｒｅｓｓｅｓメッセージ４５０を生成し、ＤＨＣＰサーバ１４４に送信して始まるシナリオ４００ａを示す。ＧｅｔＩＰＡｄｄｒｅｓｓｅｓメッセージ４５０に応じて、ＤＨＣＰサーバ１４４は、ＤＨＣＰサーバ１４４によって既知のＩＰアドレスのリスト「ＩＰＬｉｓｔ」付のＩＰＡｄｄｒｅｓｓｅｓメッセージ４５２を生成及び送信する。
【０１２６】
ＩＰＡｄｄｒｅｓｓｅｓメッセージ４５２を受信すると、デバイス状態管理システム１１２はブロック４５６、４６４、４６６、４７２、４７４、４８４及び４９０の手順を行って、ＩＰＬｉｓｔをデバイスデータベース１１４に統合する。ＩＰＬｉｓｔをデバイスデータベース１１４に統合する一環として、デバイス状態管理システム１１２はデバイスデータベース１１４にＩＰＬｉｓｔ内の各ＩＰアドレスを問い合わせ、問い合わせたＩＰアドレスのエントリがデバイスデータベース１１４内に存在するか否かを判定できる。このようなエントリが存在する場合、そのエントリは確認済みと考えられる。そうでなく、問い合わせたＩＰアドレスのエントリが存在しない場合、デバイス状態管理システム１１２は、デバイスデータベース１１４に問い合わせたＩＰアドレスのエントリを追加できる。
【０１２７】
図４Ｆは、ＩＰＬｉｓｔの統合より前のデバイスデータベース１１４の内容を示す。特に、デバイスデータベース１１４は、各ＩＰアドレスである「ＤＤ＿ＩＰ１３０」、「ＤＤ＿ＩＰ１４２」及び「ＤＤ＿ＩＰ３１０」、各デバイス名「ＰＤ１３０」、「ＰＤ１４２」及び「ＰＤ３１０」、各状態である「要照合」、「要照合」及び「要照合」、並びに各「ページカウント」値である「ａａａ」、「ｂｂｂ」及び「ｃｃｃ」を記憶する「ＥＮＴＲＹ１」、「ＥＮＴＲＹ２」及び「ＥＮＴＲＹ３」の３つのエントリを含む。
【０１２８】
図４Ｇは、ＩＰＬｉｓｔ４３４であるＩＰＡｄｄｒｅｓｓｅｓメッセージ４５２で返信されたＩＰＬｉｓｔの内容を示す。図４ＣのＩＰＬｉｓｔ４３４と関連して上記で説明されているのと同じデータがＩＰＡｄｄｒｅｓｓｅｓメッセージ４５２の「ＩＰＬｉｓｔ」として提供されている。図４ＧのＩＰＬｉｓｔ４３４についてのさらなる情報は、表１を含む図４ＣのＩＰＬｉｓｔ４３４と関連して提供される。
【０１２９】
図４Ｅのブロック４５６に戻り、デバイス状態管理システム１１２は、デバイスデータベースにＩＰＬｉｓｔからのＩＰＬｉｓｔ１＿Ａｄｄ０を問い合わせ、ＩＰＬｉｓｔ１＿Ａｄｄ０に等しいＩＰアドレスＤＤ＿ＩＰ３１０を有するエントリＥＮＴＲＹ３を見つける。デバイスデータベース１１４は、ＩＰＬｉｓｔからのＩＰＬｉｓｔ１＿Ａｄｄ０に対応するＥＮＴＲＹ３を有するため、デバイス状態管理システム１１２はＥＮＴＲＹ３の状態を「確認済み」とマーキングする。
【０１３０】
またブロック４５６で、デバイス状態管理システム１１２は３つの新たなエントリをデバイスデータベース１１４に追加する。より具体的には、デバイス状態管理システム１１２は、デバイスデータベース１１４にＩＰＬｉｓｔからのＩＰＬｉｓｔ１＿Ａｄｄ１を問い合わせるが、ＩＰＬｉｓｔ１＿Ａｄｄ１の特定のエントリは見つけない。シナリオ４００ａでは、ＩＰＬｉｓｔからのＩＰＬｉｓｔ１＿Ａｄｄ１及びデバイスデータベース１１４内のＥＮＴＲＹ２の両方とも印刷デバイス１４２に関連付けられているが、ＩＰＬｉｓｔ１＿Ａｄｄ１は、デバイスデータベース１１４のＥＮＴＲＹ２と記憶されるＤＤ＿ＩＰ１４２とは異なる。従って、デバイスデータベース１１４内でのＩＰＬｉｓｔ１＿Ａｄｄ１の問い合わせは失敗する。デバイスデータベース１１４がＩＰＬｉｓｔからのＩＰＬｉｓｔ１＿Ａｄｄ１に対応するエントリを持たないため、デバイス状態管理システム１１２は、エントリ「ＥＮＴＲＹ４」をデバイスデータベース１１４にＩＰＬｉｓｔ１＿Ａｄｄ１のＩＰアドレス及び「要照合」の状態付きで追加し、デバイス名及びページカウントのフィールドを、図４Ｄで、「――――」で表されるデフォルト値に設定する。
【０１３１】
そして、デバイス状態管理システム１１２は、デバイスデータベース１１４にＩＰＬｉｓｔからのＩＰＬｉｓｔ１＿Ａｄｄ２を問い合わせるが、ＩＰＬｉｓｔ１＿Ａｄｄ２の特定のエントリは見つけない。シナリオ４００ａでは、ＩＰＬｉｓｔ１＿Ａｄｄ２及び関連付けられているデバイス４１０のいずれもデバイスデータベース１１４内のデータによって表されていない。従って、デバイスデータベース１１４内でのＩＰＬｉｓｔ１＿Ａｄｄ２の問い合わせは、失敗する。デバイスデータベース１１４は、ＩＰＬｉｓｔからのＩＰＬｉｓｔ１＿Ａｄｄ２に対応するエントリを持たないため、デバイス状態管理システム１１２は、デバイスデータベース１１４にエントリ「ＥＮＴＲＹ５」を、ＩＰＬｉｓｔ１＿Ａｄｄ２のＩＰアドレス及び「要照合」の状態付きで追加し、デバイス名及びページカウントのフィールドを、デフォルト値に設定する。
【０１３２】
さらに、デバイス状態管理システム１１２は、デバイスデータベース１１４に、ＩＰＬｉｓｔからのＩＰＬｉｓｔ１＿Ａｄｄ３を問い合わせるが、ＩＰＬｉｓｔ１＿Ａｄｄ３の特定のエントリは見つけない。シナリオ４００ａでは、ＩＰＬｉｓｔ１＿Ａｄｄ３及び関連付けられているデバイス４２０のいずれもデバイスデータベース１１４内のデータによって表されていない。従って、デバイスデータベース１１４内でのＩＰＬｉｓｔ１＿Ａｄｄ３の問い合わせは、失敗する。デバイスデータベース１１４は、ＩＰＬｉｓｔからのＩＰＬｉｓｔ１＿Ａｄｄ３に対応するエントリを持たないため、デバイス状態管理システム１１２は、デバイスデータベース１１４にエントリ「ＥＮＴＲＹ６」を、ＩＰＬｉｓｔ１＿Ａｄｄ３のＩＰアドレス及び「要照合」の状態付きで追加し、デバイス名及びページカウントのフィールドを、デフォルト値に設定する。
【０１３３】
ＥＮＴＲＹ６のデバイスデータベース１１４への追加が完了した後、デバイス状態管理システム１１２は、ＩＰＬｉｓｔ内のデバイスをプローブする。より具体的には、デバイス状態管理システム１１２は、プローブメッセージ４６０を生成し、印刷デバイス１４２のＩＰアドレスである、ＩＰアドレスＩＰＬｉｓｔ１＿Ａｄｄ１に送信する。プローブメッセージ４６０の受信に応じて、印刷デバイス１４２はプローブ応答４６２を生成し、デバイス状態管理システム１１２に送信する。プローブ応答４６２は、ＩＰＬｉｓｔ１＿Ａｄｄ１と等しい印刷デバイス１４２のＩＰアドレスである「ＩＰ１４２」、印刷デバイス１４２のデバイス名である「Ｎａｍｅ１４２」及び印刷デバイス１４２のページカウント値である「ＰＣ１４２」を含む。その他のシナリオでは、プローブ応答は、印刷デバイスのシリアル番号及び印刷デバイスの機種名／番号等だが、これらに限らない、印刷デバイスについての追加的及び／又は異なるデータを含むことができる。
【０１３４】
ブロック４６４で、デバイス状態管理システム１１２はプローブ応答４６２を調べ、「Ｎａｍｅ１４２」として提供される値と等しいデバイス名を有するデバイスについてデバイスデータベースに問い合わせる。シナリオ４００ａで、「Ｎａｍｅ１４２」で提供されるデバイス名の値は「ＰＤ１４２」で、「ＰＣ１４２」で提供される値は「ｂｂｂ」である。「ＰＤ１４２」についてデバイスデータベース１１４に問い合わせると、デバイスデータベース１１４は印刷デバイス１４２のＥＮＴＲＹ２を返信する。そして、デバイス状態管理システム１１２は、状態フィールドを、プローブ応答４６２内のデータに基づいて「確認済み」とマーキングしてＥＮＴＲＹ２を更新する。
【０１３５】
ブロック４６６で、デバイス状態管理システム１１２は、ＩＰＬｉｓｔのＩＰアドレスＩＰＬｉｓｔ１＿Ａｄｄ１のために追加されたエントリである、デバイスデータベース１１４のＥＮＴＲＹ４を、プローブ応答４６２からのデバイス名の値である「ＰＤ１４２」及びページカウント値である「ｂｂｂ」で更新する。そして、デバイス状態管理システム１１２は、プローブ応答４６２内のデータに基づいて、状態フィールドを「確認済み」とマーキングしてＥＮＴＲＹ４を更新する。
【０１３６】
シナリオ４００ａは、ＩＰＬｉｓｔ内でデバイスをプローブし続けるデバイス状態管理システム１１２で継続する。より具体的には、デバイス状態管理システム１１２は、プローブメッセージ４７０を生成し、デバイス４１０のＩＰアドレスであるＩＰアドレスＩＰＬｉｓｔ１＿Ａｄｄ２に送信する。シナリオ４００ａで、図４Ｅに示されるようにプローブ４７０がブロック４７２で時間切れとなるため、デバイス４１０はプローブ４７０に応答しない。
【０１３７】
ブロック４７４で、デバイス状態管理システム１１２は、ＩＰＬｉｓｔからＩＰアドレスＩＰＬｉｓｔ１＿Ａｄｄ２のために追加されたＥＮＴＲＹ５をデバイスデータベース１１４から削除することで時間切れしたプローブ４７０に応答する。図４Ｈは、「削除済み」の状態を含むＥＮＴＲＹ５のデータを示す。その他のシナリオでは、ＥＮＴＲＹ５は、デバイスデータベース１１４から取り除かれることもできる。
【０１３８】
シナリオ４００ａは、ＩＰＬｉｓｔ内でデバイスをプローブし続けるデバイス状態管理システム１１２で継続する。より具体的には、デバイス状態管理システム１１２は、プローブメッセージ４８０を生成し、デバイス４２０のＩＰアドレスであるＩＰアドレスＩＰＬｉｓｔ１＿Ａｄｄ３に送信する。プローブメッセージ４８０の受信に応じて、デバイス４２０はプローブ応答４８２を生成し、デバイス状態管理システム１１２に送信する。プローブ応答４８２は、デバイス４２０のＩＰアドレスである「ＩＰＬｉｓｔ１＿Ａｄｄ３」、印刷デバイス４２０のデバイス名である「Ｎａｍｅ４２０」及びデバイス４２０のページカウント値である「ＰＣ４２０」を含む。プローブ応答４８２内のデータ、例えばデバイス名及びページカウントデータを利用することで、デバイス状態管理システム１１２は、デバイス４２０が印刷デバイスであると判定できる。シナリオ４００ａでは、「Ｎａｍｅ４２０」で提供されるデバイス名の値は「ＰＤ４２０」で、「ＰＣ４２０」により提供される値は「ｄｄｄ」である。
【０１３９】
ブロック４８４で、デバイス状態管理システム１１２は、デバイスデータベース１１４にデバイス名「ＰＤ４２０」を問い合わせるが、この問い合わせは失敗して、印刷デバイス４２０は、プローブメッセージ４８０及びプローブ応答４８２により発見された以前は未知だった印刷デバイスであるということを示す。デバイス状態管理システム１１２は続いて、ＩＰＬｉｓｔのＩＰアドレスＩＰＬｉｓｔ１＿Ａｄｄ３のために追加されたエントリであるデバイスデータベース１１４のＥＮＴＲＹ６を、プローブ応答４８２からのデバイス名の値である「ＰＤ４２０」及びページカウント値である「ｄｄｄ」で更新する。デバイス状態管理システム１１２は、状態フィールドを「確認済み」とマーキングすることによって、ＥＮＴＲＹ６も更新できる。
【０１４０】
ブロック４９０で、デバイス状態管理システム１１２は、デバイス名がデバイスデータベース１１４のＥＮＴＲＹ１内の「ＰＤ１３０」である印刷デバイスがＩＰＬｉｓｔ内のＩＰアドレスによって表されていないと判定する。このように、ＥＮＴＲＹ１は、例えば、印刷ネットワークから取り除かれた及び／又はＥＮＴＲＹ１に記憶され、期限切れとなったデータを十分有する等の失われたデバイスと対応する。その結果、デバイス状態管理システム１１２は、図４Ｈに示されるように、デバイスデータベース１１４のＥＮＴＲＹ１の状態を「失われた」とマーキングできる。その他のシナリオでは、デバイス状態管理システム１１２は、失われたデバイスに対応するデバイスデータベース１１４のエントリを削除できる。さらに他のシナリオでは、失われたデバイスは印刷ネットワークの状態を危殆化させると考えることができる。
【０１４１】
図４Ｈは、シナリオ４００ａの最後におけるデバイスデータベース１１４内のデータを示す。シナリオ４００ａの最後において、５つの削除されていないエントリ中１つのエントリのみが確認されていない。シナリオによっては、デバイスデータベース１１４内のデータの１／５が失われたとマーキングされ、データの４／５が確認済みなため、デバイスデータベース１１４は、シナリオ４００ａのこの段階では安定していると考えることができる。
【０１４２】
図５Ａは、例示の実施形態に係る印刷システムを安定化させる方法５００のフローチャートである。例によっては、方法５００は、図２Ｂと関連して上記で説明されている方法２００のブロック２９２の機能を実施するために使用できる。つまり、方法５００は、ＩＰアドレスの１以上のクラスタ内のＩＰアドレスに送信されるプローブを使用してシステムを安定化及び／又はデバイスデータベースをリフレッシュするために呼び出すことができる。
【０１４３】
方法２００と同様に、方法５００は、デバイス状態管理システム１１２等のデバイス状態管理システムによって実行できる。デバイス状態管理システムは、図１Ａと関連して上記で説明されているコンピューティングデバイス１１０及び／又は図１Ｂと関連して上記で説明されているコンピューティングデバイス１６０等のコンピューティングデバイスにより実行されるソフトウェアであること又はソフトウェアを含むことができる。
【０１４４】
方法５００は、デバイス状態管理システムが印刷システムを安定化する必要があると判定できる、ブロック５１０を開始できる。例えば、方法２００のシステム不安定値ＳＩが閾値Ｔｈｒｅｓｈｏｌｄを超える場合、デバイス状態管理システムはシステムを安定化する必要があると判定できる。
【０１４５】
ブロック５１２で、印刷システムを安定化する必要があると判定した後、デバイス状態管理システムは、失われた及び／又は危殆化したデバイスのＩＰアドレスのリストＩＰ＿ＬＯＳＴを判定できる。例えば、図４Ｈに示される例示データを使用して、デバイス状態管理システムは、デバイスデータベースを問い合わせ、図４Ｈに示される例で、状態値が「失われた」、「危殆」又は「要照合」であるデータベースのエントリの全てのＩＰアドレスを読み出せる。このような問い合わせは１つのＩＰアドレス「ＤＤ＿ＩＰ１３０」をＩＰ＿ＬＯＳＴリストとして返信する。他の例として、図４Ｄに示されるような例示データを使用して、デバイス状態管理システムは、デバイスデータベースを問い合わせ、図４Ｄに示される例で、状態値が「失われた」、「危殆」又は「要照合」であるデータベースのエントリの全てのＩＰアドレスを読み出せる。このような問い合わせは、「ＤＤ＿ＩＰ１３０」、「ＤＤ＿ＩＰ１４２」、「ＩＰＬｉｓｔ１＿Ａｄｄ１」、「ＩＰＬｉｓｔ１＿Ａｄｄ２」及び「ＩＰＬｉｓｔ１＿Ａｄｄ３」の５つのＩＰアドレスのリストをＩＰ＿ＬＯＳＴリストとして返信する。その他の例示の問い合わせ及び問い合わせ応答も考えられる。
【０１４６】
ブロック５２０で、デバイス状態管理システムは、ＩＰ＿ＬＯＳＴリストのためのＩＰアドレスのクラスタ「Ｃ１、Ｃ２…Ｃｎ」として図５Ａに示される、ｎ＞０である、ｎ個のクラスタを判定できる。クラスタＣ１、Ｃ２…Ｃｎを判定するには、ｋ平均法又は自然分類アルゴリズム等のベクトル量子化アルゴリズムが使用できる。ｋ平均法アルゴリズムは、クラスタの数を表す、ｋ＞０である数値ｋ、すなわちこの例ではｋ＝ｎを選択することを含むことができる。そして、ＩＰアドレスの各クラスタは、クラスタの平均値によって表される。例えば、ＩＰアドレスが、２５６個の異なるＩＰアドレスの全範囲に関して、１０．１００．０．０乃至１０．１００．０．２５５の範囲Ｒ１内にあり、ｋ＝ｎ＝２であると仮定する。そうすると、第１のクラスタＣ１がそのＲ１内の第１の１２８個のアドレスを初期平均値１０．１００．０．６４で表せ、第２のクラスタＣ２がＲ１内の第２の１２８個のアドレスを初期平均値１０．１００．０．１９２で表せる。ｎ個のクラスタに対する初期平均の割り振りの他の技術としては、クラスタ化される第１のｎ値、つまりＩＰ＿ＬＯＳＴリスト内の値を選択し、第１のｎ値のそれぞれにＣ１、Ｃ２…Ｃｎクラスタの１つを割り振る。初期平均を判定するその他の技術も考えられる。
【０１４７】
そして、ＩＰ＿ＬＯＳＴアドレスリスト内のＩＰアドレスＩ＿ＩＮ毎に、ｋ平均法アルゴリズムは、先ずＩ＿ＩＮに最も近い平均であるＩ＿ＩＮのためのクラスタを選択することを含むことができる。例えば、Ｉ＿ＩＮ＝１０．１００．０．２２である場合、平均１０．１００．０．６４を有するクラスタＣ１がＩ＿ＩＮとして選択される。これは、１０．１００．０．６４が１０．１００．０．１９２（クラスタＣ２の平均）よりも１０．１００．０．２２に近いからである。そして、Ｉ＿ＩＮが選択されたクラスタに追加され、選択されたクラスタ内の数値の平均が再計算される。つまり、Ｉ＿ＩＮがクラスタＣ１に追加された後、１０．１００．０．２２であるＩ＿ＩＮの数値となる新たな平均が判定できる。そして、ＩＰ＿ＬＩＳＴがクラスタＣ１に追加される第２のＩＰアドレス、１０．１００．０．６を有すると仮定する。１０．１００．０．６をＣ１に追加後、Ｃ１の平均は、（１０．１００．０．２２＋１０．１００．０．６）／２＝１０．１００．０．１４に更新できる。ＩＰ＿ＬＯＳＴアドレスリストの全てのアドレスがｎ個のクラスタに追加された後、ｋ平均法アルゴリズムは完了できる。
【０１４８】
自然分類アルゴリズムは、ＩＰ＿ＬＯＳＴアドレスリスト等のデータセット内の固有のクラスタリングを見つけることに基づく。このような固有のクラスタリングは、同様の数値を有する及びクラスタ間に相対的に大きな差があるクラスタに基づくことができる。自然分類アルゴリズムの一例としては、ＩＰ＿ＬＩＳＴ内のＩＰアドレス等の一変量（１つの変数）データに対するジェンクス最適化がある。ジェンクス最適化は、データをｎ個のクラスタにクラスタ化する第１の試みを行うことを含む。この第１の試みは無作為なクラスタリングであることができる。例えば、ＩＰ＿ＬＩＳＴがリスト内にＮＩＰ値を有し、従って、クラスタＣ１はＩＰ＿ＬＩＳＴ内の第１ＮＩＰ／ｎ値の可能性があり、クラスタＣ２はＩＰ＿ＬＩＳＴ内の第２ＮＩＰ／ｎ値の可能性があり、クラスタＣｎがＩＰ＿ＬＩＳＴ内の最終ＮＩＰ／ｎ値と判定されるまで続くと仮定する。
【０１４９】
（初期）クラスタリングの判定後、ジェンクス最適化はデータのクラスタ上で動作する反復プロセスである。つまり、クラス内分散が最小となるクラスタのセットはどれかを判定するため、異なるクラスタを選択して計算を繰り返さなくてはならない。
【０１５０】
ジェンクス最適化の反復毎に、デバイス状態管理システムは下記を行える。
１.  クラスタ毎の平均を判定、クラスタ平均の平均ＣＭＥＡＮを判定、及び各クラスタ平均とＣＭＥＡＮ値の差の平方和を取ることにより、配列（クラスタ）平均ＳＤＡＭから偏差平方和を計算する。
２.  クラスタＣ＿ｉ毎に、クラスタ内の各クラスタ平均と各数値との間の差の平方和ＳＤ＿ｉを判定し、ＳＤＢＣをｎ個のクラスタ全てにわたって各ＳＤ＿ｉ値の和と等しくさせることにより、クラスタＳＤＢＣ間の偏差平方和を計算する。
３．  ＳＤＡＭからＳＤＢＣを減算する。（ＳＤＡＭ−ＳＤＢＣ）これは、クラス平均（ＳＤＣＭ）からの偏差平方和と等しい。
４．  最大のＣ＿ｉ値を有するクラスタから１つのＩＰアドレスを最小のＣ＿ｉ値を有するクラスタに移動させる。
【０１５１】
反復プロセスの代替手段として、全ての考え得るクラスタの組み合わせを検討してもよく、組み合わせ毎にＳＤＣＭが算出され、そして最も低いＳＤＣＭを持つ組み合わせが選択される。全てのブレーク組み合わせが検討されるため、最も低いＳＤＣＭを持つものが見つかることを保証する。また、ＧＶＦ統計（分散適合度）が算出できる。ＧＶＦは、（ＳＤＡＭ−ＳＤＣＭ）／ＳＤＡＭと定義される。ＧＶＦは０（最悪適合）から１（完全適合）の範囲で変動する。その他のクラスタリング技術も考えられる。
【０１５２】
ブロック５２０でも、デバイス状態管理システムはクラスタ指標値ＣＬを１に等しく初期化できる。
【０１５３】
ブロック５３０〜５６４は、クラスタＣ１、Ｃ２…Ｃｎ毎に行われることが意図される。ブロック５３０で、デバイス状態管理システムは、クラスタ指標値ＣＬが、クラスタの総数であるｎよりも大きいか否か判定できる。ＣＬがｎよりも大きい場合、デバイス状態管理システムはブロック５７０に進むことができる。そうでなく、ＣＬがｎ以下である場合、デバイス状態管理システムはブロック５４０に進むことができる。
【０１５４】
ブロック５４０で、デバイス状態管理システムはクラスタＣＬの１以上の特性ＣＨ１を判定できる。特性ＣＨ１としては、クラスタＣＬのアドレスの範囲ＡＲ、失われたデバイス、危殆化したデバイス及び／又はクラスタＣＬ内で照合の必要なデバイスの数、クラスタＣＬについての履歴情報（例えば、失われた／危殆化したデバイスを有するアドレスの前回のカウントや、失われた／危殆化したデバイスを有していたクラスタＣＬ内の特定のアドレスについての情報等）、クラスタＣＬの実働時間ＡＴ及びクラスタＣＬのアドレス密度ＡＤを挙げることができるが、これらに限らない。
【０１５５】
クラスタＣＬの実働時間ＡＴは、クラスタＣＬのアドレス範囲内にある１以上のデバイスが失われた、危殆化した及び／又は照合が必要となった時間量として判定できる。例えば、実働時間ＡＴは、クラスタ内にあるデバイスが失われた、危殆化した及び／又は照合が必要と判定されてからの最長時間に基づいて、クラスタ内にある全てのデバイスが失われた、危殆化した及び／又は照合が必要と判定された平均時間に基づいて、又はクラスタ内にある１以上のデバイスが失われた、危殆化した及び／又は照合が必要とマーキングされてからの時間量を表すその他の数値に基づいて、判定できる。
【０１５６】
クラスタＣのアドレス密度ＡＤは次のように判定できる。
ＡＤ＝ＮＬＦ／ＮＡＣ
ＮＬＦ＝クラスタＣ内にある失われた／危殆化したデバイスの数
ＮＡＣ＝クラスタ内のアドレスの数
ＮＡＣ値は、ＮＡＣ＝ＡＲ＿ＨＩ−ＡＲ＿ＬＯ＋１で判定でき、ＡＲ＿ＨＩは、クラスタのアドレス範囲ＡＲ内の最も高いＩＰアドレスで、ＡＲ＿ＬＯはアドレス範囲ＡＲ内の最も低いＩＰアドレスで、ＡＲ＿ＨＩはＡＲ＿ＬＯ以上であると見なされる。
【０１５７】
ブロック５５０で、デバイス状態管理システムは特性ＣＬ１に基づいてクラスタＣＬをプローブするか否か判定できる。デバイス状態管理システムがクラスタＣＬをプローブすると判定した場合、デバイス状態管理システムはブロック５６０に進むことができる。そうでなく、デバイス状態管理システムがクラスタＣＬをプローブしないと判定した場合、ブロック５６４に進むことができる。
【０１５８】
一般に言えば、相対的に小さなアドレス範囲／アドレス数を持つクラスタは、相対的に大きなアドレス範囲を持つクラスタよりもプローブされやすい。また、失われたデバイス、危殆化したデバイス及び／又は照合が必要なデバイスの数が相対的に多いクラスタは、失われた／危殆化したデバイスの数が相対的に少ないクラスタよりもプローブされやすい。従って、ＡＤの値が高いクラスタは、クラスタアドレス毎の失われた／危殆化したデバイスの数が相対的に多いため、アドレス密度ＡＤの値が相対的に高いクラスタは、アドレス密度ＡＤの値が相対的に低いクラスタよりもプローブされやすい。さらに、実働時間ＡＴの値が相対的に高いクラスタは、比較的に古い情報を有するため、実働時間ＡＴの値が相対的に低いクラスタよりもプローブされやすい。
【０１５９】
図５Ｂは、例示の実施形態に係る、印刷システムの失われた及び／又は危殆化した印刷デバイスのアドレスのクラスタに関連するヒストグラム５９０及びアドレスのクラスタに対するプローブ決定５９２を示す。図５Ｂに示される例では、５つのクラスタ（ｎ＝５）のＩＰアドレス範囲が判定される。ヒストグラム５９０は、Ｘ軸に沿って増大するアドレス値及びＹ軸に沿ったアドレス範囲内にある失われた及び／又は危殆化したデバイスの数を示す。ヒストグラム５９０のより高い（又はより短い）棒は、棒により表されるＩＰアドレス範囲の特定の箇所内にある失われた及び／又は危殆化したデバイスの数がより多い（又はより少ない）ことを示す。
【０１６０】
図５Ｂに示される、クラスタＡ、Ｂ、Ｃ、Ｄ及びＥの５つのクラスタ毎に判定された特性ＣＬ１に基づいて、ブロック５５０でプローブ決定が判定され、ブロック５６０で精緻化できる。ブロック５５０でなされたプローブ決定により、クラスタのいずれかの箇所をプローブするか否か判定できる。例えば、クラスタＡは、アドレス範囲に関しては相対的に大きなクラスタであるが、クラスタＤ等のその他のクラスタと比べて失われた／危殆化したデバイスの数が相対的に少ない。そのため、アドレス範囲が大きいこと及びおそらく失われた／危殆化したデバイスの数が少ないことに基づいて、クラスタＡのプローブ決定はクラスタをプローブしないこととなる。従って、方法５００のブロック５６０及び５６２はクラスタＡには実行されない。クラスタＣのアドレス密度ＡＤに基づいて、同様の計算が判定できる。
【０１６１】
図５Ａに戻り、ブロック５６０で、デバイス状態管理システムは、クラスタＣＬで１以上のプローブ範囲を判定できる。ブロック５６０は、全てのプローブされたクラスタは無差別に扱われないというコンセプトに関する。クラスタは、クラスタに対する１以上の特性ＣＨ１に基づいて危殆化重症度のレベル内で変動し得る。この重症度における変動に起因して、クラスタ中心からの目標範囲又は平均値は、それを区分するために使用されるプロパティに関して算出できる。
【０１６２】
図５Ｂに示される例では、プローブ決定５９２は、ヒストグラム５９０のクラスタＢ、Ｄ及びＥがプローブされ、そのため、方法５００のブロック５６０及び５６２がこれらのクラスタのために実行されることを示す。クラスタＤについては、ブロック５６０で、デバイス状態管理システムが、クラスタＤはより小さなクラスタ範囲及びクラスタ内により多くの数の失われた／危殆化したデバイスを有し、クラスタＤ内の各アドレスがプローブされるフルディスカバリから恩恵を受けるだろうと判定できる。しかしながら、クラスタＢ及びＥには部分的ディスカバリで十分であることができる。クラスタＢについては、範囲の下側半分に失われた／危殆化したデバイスの数が相対的に多いため、ブロック５６０ではデバイス状態管理システムは、クラスタＢの下側半分を含むプローブ範囲をプローブすると判定できる。同様に、クラスタＥについては、アドレス範囲の下側２／３に失われた／危殆化したデバイスの数が相対的に多いため、デバイス状態管理システムは、クラスタＥの下側２／３を含むプローブ範囲をプローブすると判定できる。その他のプローブ決定も考えられる。
【０１６３】
図５Ａに戻り、ブロック５６２で、デバイス状態管理システムは１以上のプローブメッセージを、ブロック５６０で判定したクラスタＣＬのプローブ範囲を有するＩＰアドレスに送信できる。プローブメッセージを送信後、デバイス状態管理システムは待機し、おそらくプローブメッセージに対する１以上のプローブ応答を受信できる。例によっては、プローブメッセージは、少なくとも図３Ｂのブロック３５６と関連して上記で説明されているように、ミドルアウトから送信できる。プローブ応答を受信すると、デバイス状態管理システムは、少なくとも図３Ａ〜４Ｈと関連して上記で説明されているようにプローブメッセージ内のデータに基づいてデバイスデータベースを更新できる。
【０１６４】
ブロック５６４で、デバイス状態管理システムは、クラスタ指標値ＣＬの値をインクリメントさせることができる。ＣＬの値をインクリメントさせた後、デバイス状態管理システムはブロック５３０に進むことができる。
【０１６５】
ブロック５７０で、デバイス状態管理システムは、システム不安定値ＳＩをリセットできる。すなわち、ＳＩ＝０に設定する。ブロック５７０の手順が完了すると、方法５００は完了できる。
ＩＶ． 操作方法例
【０１６６】
図６は、例示の実施形態に係る方法６００のフローチャートを示す。方法６００は、デバイス状態管理システムにより実施できる。デバイス状態管理システムは、コンピューティングデバイス１１０及び／又はコンピューティングデバイス１６０等のコンピューティングデバイスにより実行可能なソフトウェアに実装することができる。
【０１６７】
方法６００は、デバイス状態管理システムが、少なくとも図２Ａ〜３Ｂ及び４Ｅ〜５Ａと関連して上記で説明されているように複数の印刷デバイスに複数のプローブメッセージを送信できる、ブロック６１０で開始できる。
【０１６８】
ブロック６２０で、デバイス状態管理システムは、複数のプローブメッセージに対する複数の応答メッセージを受信できる。ここで、少なくとも図２Ａ〜３Ｂ及び４Ｅ〜５Ａと関連して上記で説明されているように、複数の応答メッセージの数は、複数のプローブメッセージの数以下である。
【０１６９】
ブロック６３０で、複数の応答メッセージを受信後、少なくとも図２Ａ〜３Ｂと関連して上記で説明されているように、デバイス状態管理システムに関連付けられているデバイスデータベースに記憶されたデータに基づいて未確認の印刷デバイスの数が判定できる。実施形態によっては、デバイス状態管理システムに関連付けられているデバイスデータベースは、１以上の印刷デバイスの特定の印刷デバイスに関して、少なくとも図２Ａ〜３Ｃと関連して上記で説明されているように、特定の印刷デバイスに関するシリアル番号、特定の印刷デバイスに関する機種名、及び特定の印刷デバイスに関するネットワークアドレスを記憶できる。これらの実施形態で特に、デバイス状態管理システムに関連付けられているデバイスデータベースはさらに、特定の印刷デバイスに関して、少なくとも図２Ａ〜３Ｃと関連して上記で説明されているような、特定の印刷デバイスに関するデバイスアクティビティレベルを記憶できる。
【０１７０】
ブロック６４０で、デバイス状態管理システムは、少なくとも図２Ａ〜３Ｂと関連して上記で説明されているような、未確認の印刷デバイスの数に関連付けられているシステム不安定値を判定できる。実施形態によっては、未確認の印刷デバイスの数に関連付けられているシステム不安定値を判定することは、少なくとも図２Ａ〜３Ｂと関連して上記で説明されているように、特定の印刷デバイスに関連付けられている複数の応答メッセージのうちの特定の応答メッセージを判定すること、特定の応答メッセージ内の応答メッセージシリアル番号がデバイスデータベースからの特定の印刷デバイスのシリアル番号と異なるか否か判定すること、及び特定の応答メッセージ内の応答メッセージシリアル番号がデバイスデータベースからの特定の印刷デバイスのシリアル番号と異なると判定した後、システム不安定値を増大させること、を含むことができる。
【０１７１】
ブロック６５０で、デバイス状態管理システムは、少なくとも図２Ａ〜３Ｂと関連して上記で説明されているように、未確認の印刷デバイスの数に関連付けられているシステム不安定値がシステム不安定値の閾値を越えているかどうか、デバイス状態管理システムを使用して判定できる。実施形態によっては、少なくとも図２Ａ〜３Ｂと関連して上記で説明されているように、未確認の印刷デバイスの数に関連付けられているシステム不安定値は、未確認の印刷デバイスの数を含むことができ、システム不安定値の閾値は未確認の印刷デバイスの閾値数を含むことができる。
【０１７２】
ブロック６６０で、システム不安定値がシステム不安定値の閾値を超えると判定した後、少なくとも図２Ａ〜３Ｂ、５Ａ及び５Ｂと関連して上記で説明されているように、デバイス状態管理システムは下記を行うことができる。未確認の印刷デバイスに関連付けられている１以上のアドレスクラスタを判定すること（各アドレスクラスタは、１以上の印刷デバイスに関連付けられている１以上のアドレスを含んでいる）、１以上のアドレスクラスタの少なくとも１つの内にある１以上のアドレスに１以上のプローブメッセージを送信すること、１以上のプローブメッセージに対する１以上の応答を受信すること、及び１以上の応答で受信したデータを使用してデバイスデータベースを更新すること、を行うことができる。
【０１７３】
実施形態によっては、未確認の印刷デバイスに関連付けられている１以上のアドレスクラスタを判定することは、少なくとも図５Ａ及び５Ｂと関連して上記で説明されているように、ベクトル量子化技術を使用して未確認の印刷デバイスに関連付けられている１以上のアドレスクラスタを判定することを含むことができる。他の実施形態では、未確認の印刷デバイスに関連付けられている１以上のアドレスクラスタを判定することは、少なくとも図５Ａ及び５Ｂと関連して上記で説明されているように、自然分類技術を使用して未確認の印刷デバイスに関連付けられている１以上のアドレスクラスタを判定することを含むことができる。
【０１７４】
また、その他の実施形態では、１以上のアドレスクラスタのうち少なくとも１つの内にある１以上のアドレスに１以上のプローブメッセージを送信することは、少なくとも図２Ｂ、３Ａ、３Ｂ、５Ａ及び５Ｂと関連して上記で説明されているように、第１クラスタ内にアドレスがある未確認の印刷デバイスの数に基づいて１以上のアドレスクラスタの第１クラスタを選択すること、及び第１クラスタ内の１以上のアドレスに１以上のプローブメッセージを送信することを含むことができる。これらの実施形態のいくつかによっては、１以上のアドレスクラスタの第１クラスタを選択することは、少なくとも図５Ａ及び５Ｂと関連して上記で説明されているように、第１クラスタ内にアドレスがある未確認の印刷デバイスの密度に基づいて第１クラスタを選択することを含むことができる。第１クラスタ内にアドレスがある未確認の印刷デバイスの密度は、第１クラスタ内にアドレスがある未確認の印刷デバイスの数に基づいている。
【０１７５】
さらにその他の実施形態では、１以上のアドレスクラスタの少なくとも１つの内にある１以上のアドレスに１以上のプローブメッセージを送信することは、少なくとも図３Ａ及び３Ｂと関連して上記で説明されているように、１以上のアドレスクラスタの少なくとも１つの内にある１以上のアドレスの中間アドレスを判定すること、及び中間アドレスから始まる１以上のアドレスに１以上のプローブメッセージを送信することを含むことができる。これらの実施形態では特に、中間アドレスから始まる１以上のアドレスに１以上のプローブメッセージを送信することは、少なくとも図３Ａ及び３Ｂと関連して上記で説明されているように、次の順で中間アドレスから始まる１以上のアドレスに１以上のプローブメッセージを送信することを含む。中間アドレスにプローブメッセージを送信し、続いて、中間アドレスと隣接するアドレスにプローブメッセージを送信することを含む。これらの実施形態を、より具体的にすると、中間アドレスに隣接するアドレスは、少なくとも図３Ａ及び３Ｂと関連して上記で説明されているように、中間アドレスの直後のアドレス及び中間アドレスの直前のアドレスの１つであることができる。
【０１７６】
実施形態によっては、方法６００は、少なくとも図２Ａ〜４Ｈと関連して上記で説明されているように、さらに下記を含むことができる。デバイス状態管理システムからのアドレス要求メッセージを送信すること、アドレス要求メッセージに応じて複数の印刷デバイスに関連付けられている１以上のネットワークアドレスを受信すること、及び受信された１以上のネットワークアドレスに基づいてデバイスデータベースを更新することを含むことができる。これらの実施形態のいくつかでは、デバイス状態管理システムからアドレス要求メッセージを送信することは、少なくとも図２Ａ〜４Ｈと関連して上記で説明されているように、デバイス状態管理システムからアドレス要求メッセージを動的ホスト構成プロトコル（ＤＨＣＰ）サーバへ送信することを含むことができる。これらの実施形態のその他においては、デバイス状態管理システムに関連付けられているデバイスデータベース内に記憶されたデータに基づいて未確認の印刷デバイスの数を判定することは、少なくとも図２Ａ〜３Ｂと関連して上記で説明されているように、下記を含む。受信された１以上のネットワークアドレスの特定のネットワークアドレスを判定すること、デバイスデータベースが特定のネットワークアドレスに関連付けられているデータを記憶していないか判定すること、及びデバイスデータベースが特定のネットワークアドレスに関連付けられているデータを記憶していないと判定した後、未確認の印刷デバイスの数の値をインクリメントさせることを含むことができる。
【０１７７】
その他の実施形態では、方法６００は、少なくとも図２Ａ及び２Ｂと関連して上記で説明されているように、デバイス状態管理システムを使用して複数の印刷デバイス内の印刷デバイス毎のデバイスアクティビティレベルを判定することをさらに含むことができる。これらの実施形態のいくつかでは、少なくとも図２Ａ及び２Ｂと関連して上記で説明されているように、未確認の印刷デバイスの数に関連付けられているシステム不安定値を判定することは、未確認の印刷デバイスの数のデバイスアクティビティレベルに基づいて未確認の印刷デバイスの数に関連付けられているシステム不安定値を判定することを含むことができ、システム不安定値の閾値はデバイスアクティビティレベルに基づいた閾値を含むことができる。さらにその他の実施形態では、方法６００は、少なくとも図２Ａ及び２Ｂと関連して上記で説明されているように、デバイス状態管理システムに関連付けられているデバイスデータベース内に記憶されたデータに基づいて印刷デバイス用の交換可能品の注文を行うことをさらに含むことができる。
【０１７８】
詳細な説明、図面及び請求項に記載された例示の実施形態は限定することを意図するものではない。本記載で提示された主題の主旨又は範囲を逸脱せずに、他の実施形態を使用してもよいし、また他の変更を行ってもよい。本明細書内で全般的に説明され、図面に示されている本開示の諸態様は、広範囲にわたる様々な異なる構成において配置、代用、組み合わせ、分割、及び設計されることができ、それらの全てが本明細書内で明らかに考慮されていることは容易に理解される。
【０１７９】
図面における任意の又は全てのラダー図、シナリオ、及びフローチャートに対して並びに本記載で説明されたように、各ブロック及び／又は通信は、例示の実施形態に従って情報の処理及び／又は情報の送信を表してもよい。別の実施形態も当該例示の実施形態の範囲に含まれる。当該別の実施形態において、例えば、ブロックとして記載された機能、送信、通信、要求、応答及び／又はメッセージは、ほぼ同時又は逆の順序も含めて、関係する機能性に応じて、示された又は説明された順序から外れた順序で実行してもよい。さらに、本記載で説明された任意のラダー図、シナリオ、及びフローチャートを用いて、より多い又はより少ないブロック及び／又は機能を使用してもよく、また当該ラダー図、シナリオ、及びフローチャートは、部分的又は全体的にお互いに結合してもよい。
【０１８０】
情報の処理を表すブロックは、方法又は手法の特定の論理機能を実施するように構成することができる回路に対応してもよい。それに代えて又はさらに、情報の処理を表すブロックは、モジュール、セグメント、又はプログラムコードの一部（関連するデータを含めて）に対応してもよい。プログラムコードは、方法又は手法において特定の論理機能又は動作を実行するために、プロセッサにより実行可能な１以上の命令を含んでもよい。プログラムコード及び／又は関連データは、ディスク若しくはハードドライブ又はその他の記憶媒体を含む記憶装置等、任意の種類のコンピュータ読み取り可能な媒体に記憶してもよい。
【０１８１】
コンピュータ読み取り可能な媒体は、また、レジスタメモリ、プロセッサキャッシュ、及びランダムアクセスメモリ（ＲＡＭ）のような、短期間、データを記憶するコンピュータ読み取り可能な媒体等の、非一時的なコンピュータ読み取り可能な媒体を含んでもよい。コンピュータ読み取り可能な媒体は、また、例えば、リードオンリーメモリ（ＲＯＭ）、光学又は磁気ディスク、コンパクトディスク・リードオンリーメモリ（ＣＤ‐ＲＯＭ）のような、二次又は持続的長期記憶装置等の、より長期間、プログラムコード及び／又はデータを記憶する非一時的なコンピュータ読み取り可能な媒体を含んでもよい。コンピュータ読み取り可能な媒体は、また、その他の揮発性又は非揮発性の記憶システムであってもよい。コンピュータ読み取り可能な媒体は、コンピュータ読み取り可能な記憶媒体、例えば、有形の記憶デバイスと考えてもよい。
【０１８２】
本記載において様々な態様及び実施形態が開示されてきたが、その他の態様及び実施形態も当業者にとって明白であろう。本記載において開示された様々な態様及び実施形態は、例示目的であって限定することを意図するものではなく、真の範囲は請求項により示されている。
【符号の説明】
【０１８３】
１００  印刷ネットワーク
１１０  コンピューティングデバイス
１１２  デバイス状態管理システム（ＤＳＭＳ）
１１４  デバイスデータベース（ＤＤＢ）
１２０  非印刷デバイス
１３０  印刷デバイス（ＰＤ）
１２２  非印刷デバイス
１２８  非印刷デバイス
１５０  ネットワーク
１４４  ＤＨＣＰサーバ
１２４  非印刷デバイス
１２６  非印刷デバイス
１４０  非印刷デバイス
１４２  印刷デバイス
【図１Ａ】
2019003617.tif 000004
【図１Ｂ】
2019003617.tif 000005
【図２Ａ】
2019003617.tif 000006
【図２Ｂ】
2019003617.tif 000007
【図３Ａ】
2019003617.tif 000008
【図３Ｂ】
2019003617.tif 000009
【図３Ｃ】
2019003617.tif 000010
【図４Ａ】
2019003617.tif 000011
【図４Ｂ】
2019003617.tif 000012
【図４Ｃ】
2019003617.tif 000013
【図４Ｄ】
2019003617.tif 000014
【図４Ｅ】
2019003617.tif 000015
【図４Ｆ】
2019003617.tif 000016
【図４Ｇ】
2019003617.tif 000017
【図４Ｈ】
2019003617.tif 000018
【図５Ａ】
2019003617.tif 000019
【図５Ｂ】
2019003617.tif 000020
【図６】
2019003617.tif 000021
【外国語明細書】
Computing devices, Methods, and Computer programs for Situational and Event-Driven Discovery Optimization of Printing Devices
FIELD
[0001]      The present invention relates to a situational and event-driven discovery optimization of printing devices.
BACKGROUND
[0002]      Printing devices have increased in number and geographic footprint throughout the world and have become increasingly connected to networks. These networks can include a print server. Typically, when one or more documents and/or other print data are scheduled to be printed, the print data is either directly sent to one printing device, or sent to a print server. 
[0003]      The networks can include many printing devices. Some or all of the printing devices can have different features, functions, and capabilities. For example, some printing devices print in color, while others do not. As another example, some printing devices are equipped with duplexing hardware that allows printing on both sides of a sheet of paper, while other printing devices can only print on one side of a sheet of paper.
SUMMARY
[0004]      In one aspect, a method is provided. A device state management system, which includes software executing on a computing device, sends a plurality of probe messages to a plurality of printing device. The device state management system receives a plurality of response messages to the plurality of probe messages, where a number of the plurality of response messages is less than or equal to a number of the plurality of probe messages. After receiving the plurality of response messages, a number of unconfirmed printing devices is determined based on data stored in a device database associated with the device state management system. The device state management system determines a system-instability value associated with the number of unconfirmed printing devices. The device state management system determines whether the system-instability value associated with the number of unconfirmed printing devices exceeds a threshold system-instability value. After determining that the system-instability value exceeds the threshold system-instability value, the device state management system: determines one or more address clusters associated with the unconfirmed printing devices, each address cluster including one or more addresses associated with one or more printing devices; sends one or more probe messages to one or more addresses within at least one of the one or more address clusters; receives one or more responses to the one or more probe messages; and updates the device database using data received in the one or more responses.
[0005]      In another aspect, a computing device is provided. The computing device includes one or more processors and data storage. The data storage is configured to store computer-readable instructions. The computer-readable instructions include instructions for a device state management system that, when executed by the one or more processors, cause the computing device to perform tasks. The tasks include: sending a plurality of probe messages to a plurality of printing devices from the device state management system; receiving, at the device state management system, a plurality of response messages to the plurality of probe messages, where a number of the plurality of response messages is less than or equal to a number of the plurality of probe messages; after receiving the plurality of response messages, determining a number of unconfirmed printing devices based on data stored in a device database associated with the device state management system; determining a system-instability value associated with the number of unconfirmed printing devices using the device state management system; determining whether the system-instability value associated with the number of unconfirmed printing devices exceeds a threshold system-instability value using the device state management system; and after determining that the system-instability value exceeds the threshold system-instability value, the device state management system: determining one or more address clusters associated with the unconfirmed printing devices, each address cluster including one or more addresses associated with one or more printing devices; sending one or more probe messages to one or more addresses within at least one of the one or more address clusters; receiving one or more responses to the one or more probe messages; and updating the device database using data received in the one or more responses.
[0006]      In another aspect, an article of manufacture is provided. The article of manufacture includes non-transitory data storage storing at least computer-readable instructions that include instructions for a device state management system. The computer-readable instructions, when executed by one or more processors of a computing device, cause the computing device to perform tasks. The tasks include: sending a plurality of probe messages to a plurality of printing devices from the device state management system; receiving, at the device state management system, a plurality of response messages to the plurality of probe messages, where a number of the plurality of response messages is less than or equal to a number of the plurality of probe messages; after receiving the plurality of response messages, determining a number of unconfirmed printing devices based on data stored in a device database associated with the device state management system; determining a system-instability value associated with the number of unconfirmed printing devices using the device state management system; determining whether the system-instability value associated with the number of unconfirmed printing devices exceeds a threshold system-instability value using the device state management system; and after determining that the system-instability value exceeds the threshold system-instability value, the device state management system determining one or more address clusters associated with the unconfirmed printing devices, each address cluster including one or more addresses associated with one or more printing devices; sending one or more probe messages to one or more addresses within at least one of the one or more address clusters; receiving one or more responses to the one or more probe messages; and updating the device database using data received in the one or more responses.
[0007]      Other aspects, embodiments, and implementations will become apparent to those of ordinary skill in the art by reading the following detailed description, with reference where appropriate to the accompanying drawings.
BRIEF DESCRIPTION OF THE FIGURES
[0008]      FIG. 1A is a diagram illustrating a printing network, according to an example embodiment;
FIG. 1B is a schematic block diagram illustrating a computing device, according to an example embodiment;
FIG. 2A is a flowchart for a method related to discovering networked printing devices using a device state management system, according to an example embodiment;
FIG. 2B is a flowchart for a method related to discovering networked printing devices using a device state management system, according to an example embodiment;
FIG. 3A illustrates a scenario where a printing system is determined to be unstable and a device database is refreshed during system stabilization, according to an example embodiment;
FIG. 3B illustrates a scenario where a printing system is determined to be unstable and a device database is refreshed during system stabilization, according to an example embodiment;
FIG. 3C illustrates formats for a device database, according to an example embodiment;
FIG. 4A illustrates a scenario where data in a device database is refreshed, according to an example embodiment;
FIG. 4B illustrates a scenario where data in a device database is refreshed, according to an example embodiment;
FIG. 4C illustrates a scenario where data in a device database is refreshed, according to an example embodiment;
FIG. 4D illustrates a scenario where data in a device database is refreshed, according to an example embodiment;
FIG. 4E illustrates another scenario where data in a device database is refreshed, according to an example embodiment;
FIG. 4F illustrates another scenario where data in a device database is refreshed, according to an example embodiment;
FIG. 4G illustrates another scenario where data in a device database is refreshed, according to an example embodiment;
FIG. 4H illustrates another scenario where data in a device database is refreshed, according to an example embodiment;
FIG. 5A is a flowchart of a method for stabilizing a printing system, according to an example embodiment;
FIG. 5B illustrates example clusters of addresses of lost and/or compromised printing devices of a printing system and example probe decisions for the clusters of addresses, according to an example embodiment; and
FIG. 6 shows a flowchart for a method, according to an example embodiment.
DETAILED DESCRIPTION
[0009]      In the following detailed description, reference is made to the accompanying figures, which form a part hereof. In the figures, similar symbols typically identify similar components, unless context dictates otherwise. The illustrative embodiments described in the detailed description, figures, and claims are not meant to be limiting. Other embodiments may be utilized, and other changes may be made, without departing from the scope of the subject matter presented herein. It will be readily understood that the aspects of the present disclosure, as generally described herein, and illustrated in the figures, can be arranged, substituted, combined, separated, and designed in a wide variety of different configurations, all of which are explicitly contemplated herein.
I.     Overview
[0010]      Techniques and apparatus for finding printing devices in a computing network are described. Some computing networks are large, complex networks connecting an extensive number of computing devices over one or more geographical regions, including printing devices; for example, a large corporation or governmental agency may utilize such computing networks. With the growth of a computing network, the corresponding infrastructure can become increasingly complicated and sophisticated, and include one or more network hierarchies designed to cover security, transparency and scalability requirements. For example, a complex computing network can have network hierarchies that include several interconnected network segments with multiple routers, switches and Dynamic Host Configuration Protocol (DHCP) servers. Such a computing network can include a large number, such as millions, of Internet Protocol (IP) addresses and obey very complicated rules for the IP address assignment. Those rules could be a part of sophisticated DHCP sector configuration or any other external subsystem that is responsible for IP address assignment and management. Such network hierarchies can be spread over many IP address segments.
[0011]      When a new hardware and/or software is deployed in such kind of environment, quick and reliable printing device discovery techniques, as disclosed herein, can complement the consequent tasks of state monitoring and lifetime maintenance. These discovery techniques can monitor and track logical device locations, such as IP addresses. These techniques can be used in a variety of computing networks, including computing networks that include network hierarchies striving to produce optimal IP address allocation that may result in continuous IP address changes and switches of the hosts in the computing network.
[0012]      For example, to administer a (complex) computing network, printing device information, such as device names, model numbers, serial numbers, Internet Protocol (IP) addresses, and/or other information related to printing devices can be stored in a device database (DDB) that can be maintained by a device state management system (DSMS). 
[0013]      The device database can store printing device information that can be used by the device state management system to maintain printing devices. For example, if the device database has data indicating a printing device is low on toner, then the device state management system can order toner for the printing device. However, if information in the database of printing device information is inconsistent, toner can be ordered for printing devices that have adequate supplies of toner and/or not ordered for printing devices that are nearly or completely out of toner. As another example, the device database can provide information used in providing feedback about a current status of one or more printing devices and in enabling near real-time or real-time reactions to printing device events. 
[0014]      Multiple situations can lead to the state of the device database, which can reflect current knowledge of the device state management system about printing devices, becoming unreliable. For example, if information in the device database becomes contradictory, the device state management system can correct the device database. Examples of contradictory information include, but are not limited to, situations where the device state management system: loses a connection with a printing device, detects that serial number or model name of a printing device has been changed, detects a network failure, critical device failure, or malfunction, detects that a newly-discovered printing device (i.e., a printing device without data already stored in the device database) has the same serial number as an already-known printing device (i.e., a printing device with data already stored in the device database), but the IP addresses differ between the newly-discovered printing device and the already-known devices, and detects other changes of printing device IP addresses.
[0015]      The device database can be updated periodically (e.g., nightly) to address these contradictions and/or for other reasons; e.g., to record data for new printers. Some, but not all, printing devices have agents that can send a message to the device state management system when an IP address changes, when the printing device is disconnected, etc., so that the device state management system can update the device database appropriately. Since not all printing devices have agents, probe messages (or “probes” for short) can be used in situations where most if not all printing devices are to be discovered, such as discovering printing devices to maintain the printing device database mentioned above. A probe can be sent to the printing device, and the printing device can respond with some or all of the above-mentioned printing device information for the printing device. 
[0016]      If a response to a probe or “probe response” from a printing device includes data matching data stored in the device database for the printing device, the probe of the printing device can be considered to have succeeded. If no probe response is received by the device state management system or if a probe response has data that is inconsistent with the device database, the probe can be considered to have failed. In some cases, only a relatively-small amount of network traffic can be allocated to printing devices, so a failing probe may not be followed up for some time. Thus, the device database of printing device information can gradually become out of date until the failing probes are followed up.
[0017]      Probes can fail for a variety of reasons. One reason for failing probes is that IP address information for printing devices changes over time. For example, if a printing device is shut down and then powered up, the printing device can ask a server, such as a DHCP server, to allocate an IP address for the printing device’s use. The newly-allocated IP address may differ than a previously-allocated IP address used by the printing device prior to shut down. Another reason for failing probes that a printing device can be disconnected, perhaps being powered off, when the probe message is sent. For example, if a printing device is shut down at the end of a business day, and probes are sent during non-business hours, then a probe message sent to the shut-down printing device will fail as the shut-down printing device is disconnected from the network. Other reasons for failing probes are possible as well. 
[0018]      To maintain the device database, the device state management system can send probes to devices on the network, and receive corresponding probe responses. After receiving the probe responses, the device state management system can determine a number of unconfirmed printing devices. The device state management system can determine that a device D responding to a probe message is an unconfirmed printing device when either (1) data in device D’s probe response is contradictory to data stored in the device database or (2) device D did not respond to the probe. That is, device D can be labeled as an unconfirmed printing device if the probe for device D fails.
[0019]      The data in a probe response can be contradictory to data stored in the device database for a number of reasons. For example, a probe response can include a serial number, model name, and a network / IP address for a printing device. But, the serial number and/or model name of a DeviceA can be changed, such as when a new IP address was assigned to DeviceA by a DHCP server or a user, and the old IP address for DeviceA has been reassigned to a different DeviceB. Also, a serial number and/or model name of a device that is not found in the device database can be the serial number and/or model name of a new printing device. As another example, the IP address of a DeviceC can be changed, where DeviceC has a record in the device database having the same serial number (and perhaps model name) matching the probe response. IP addresses can change for a number of reasons; e.g., use of a new or additional network adaptor, a different IP version (IPv4 or IPv6) was enabled, a new IP address was assigned to DeviceC by a DHCP server or a user.
[0020]      The device state management system can determine a system-instability value associated with the number of unconfirmed printing devices using the device state management system. In one example, the system-instability value can be the number of unconfirmed printing devices. In another example, the system-instability value can be a sum or another mathematical combination of a number of activity levels of the number of unconfirmed printing devices. An activity level of a particular unconfirmed printing device UPD can be based on an amount of toner used by printing device UPD, values of counters, such as page counters, obtained from printing device UPD, numbers and/or types of alerts generated by printing device UPD, and combinations thereof. 
[0021]      More particularly, an activity level can be based on a rate of change of one or more values; e.g., if the device state management system determines that unconfirmed printing device UPD has a page counter of 1000 on day 1 and 1200 on day 2, then, the rate of change of these page counters indicates printing device UPD prints 200 pages on this particular day. Then, the device state management system can determine the activity level for printing device UPD based on the 200 pages per day value. As another example, if a toner level for printing device UPD is 80% on day 1 and 78.3% on day 2, the activity level for printing device UPD can be based on a 1.7% decrease in toner levels for printing device UPD. Combinations, such as determining the activity level for printing device UPD based on the 200 pages / day and 1.7% change in toner levels, are possible as well. The use of activity levels in determining system-instability values can lead to an unequal weighting of unconfirmed printing devices; that is, some unconfirmed printing devices can have a large impact on system instability and some unconfirmed printing devices can have little or no impact on system instability. In an extreme case, having one unconfirmed printing device with a high activity level can cause the system to be unstable. Other examples of system-instability values and activity levels are possible as well.
[0022]      The device state management system can determine that the device database is unstable by determining that the system-instability value exceeds a threshold system-instability value. Otherwise, as the system-instability value does not exceed the threshold system-instability value, the device database can be considered to be stable and the device state management system can utilize the device database as is. For example, if the device state management system has data on N printing devices, N > 0, the threshold system-instability value can be based on: a predetermined number of unconfirmed printing devices, such as 1, 10, 50, 66, 100, 500, a percentage of devices, such as 10% of N, 15% of N, 20% of N + 1, and/or on one or more values determined using other techniques. As another example, a threshold system-instability value can be a sum or another mathematical combination of activity levels of the predetermined number of unconfirmed printing devices; e.g., the threshold system-instability value can be a total of a number of pages / day, such as 10, 300, 5000, or 150,000 pages / day from the unconfirmed printing devices, a cumulative percentage or other change of toner levels, such as a 10%, 25%, 100%, 250%, 500% change of toner levels in the unconfirmed printing devices, a number of alerts, such as 1, 10, 25, 50, 100, 250, cumulatively received from the unconfirmed printing devices, etc. and combinations thereof. Other threshold system-instability values are possible as well. 
[0023]      To resolve contradictions between the device database and probe responses, the device state management system can discover missing devices and ensure that all known devices are connected and reachable. The discovery of missing devices can be performed using a preventive system maintenance discovery approach and/or a situational system stabilization discovery approach. For example, when the system-instability value is less than the system-instability threshold, the preventive system maintenance discovery approach can be used. The preventive system maintenance discovery approach can aim to minimize the number of potential system conflicts and prevent the situation when system state could be considered as unreliable. In other cases, such as when the system-instability value exceeds than the system-instability threshold, the situational system stabilization discovery approach can be used. The situational system stabilization discovery approach can aim to stabilize system state when the actual problem has happened and has not been detected and resolved using preventive system maintenance discovery approach.
[0024]      The preventive system maintenance discovery approach can minimize possible conflicts and the cases when the state is not reliable and the system needs to have at least a minimal timely guarantee that the environment has not been changed or compromised. To minimize a number of possible conflicts, the device state management system can communicate with the device state monitoring system to one or more existing IP address assignment subsystems, such as binding and connecting with one or more DHCP servers to obtain one or more lists of network addresses, such as IP addresses, that may be associated with printing devices. After obtaining the list(s) of network addresses, the device state management system can compare IP / network addresses on the list(s) with known IP / network addresses stored in the device database. 
[0025]      The preventive system maintenance discovery approach can distinguish printing devices from other devices by IP address information. In some cases, printing devices are assigned specific ranges of IP addresses. These ranges of IP addresses can be provided to the device state management system by network-management personnel administering an IP network and/or printing devices in that network, but those ranges can change over time. Also, a printing device could be assigned to an IP address that is not in a provided range. When the device state management system is to use IP address ranges to discover printing devices, the device state management system can use this provided information supplemented by additional information, such as historical information about what IP address ranges were used by printing devices in the past and/or information about IP address ranges returned in responses to probe messages. Further, many non-printing devices do not provide serial number information, so printing devices can be distinguished by probe responses that include serial number information.
[0026]      In some embodiments, the device state management system can execute on the same computing device as the DHCP server, and then some or all of the list(s) of network addresses can be retrieved using one or more configuration files. In other embodiments, the device state management system can execute on a different computing device as the DHCP server, and then some or all of the list(s) of network addresses can be retrieved using one or more network communication protocols (e.g., Hypertext Transport Protocol (HTTP), Extensible Messaging and Presence Protocol (XMPP), Simple Network Management Protocol (SNMP), telnet, File Transfer Protocol (FTP), Transmission Control Protocol (TCP), a socket-based communication protocol).
[0027]      More particularly, the device state management system can connect to a DHCP server and retrieve the list of IP addresses that were allocated by and known to the DHCP server. Continuing with the preventive system maintenance discovery approach, the device state management system can compare the known IP addresses and the list of addresses that is returned from the DHCP server. If some unknown IP addresses are returned, they can be probed using a simple probing method, such as sending probe messages to each unknown IP address, as an unknown IP address could be an IP address of a (new) printing device. If probing of unknown IP addresses reveals that there are some known IP addresses that were not returned from the DHCP server and not previously resolved, these known IP addresses can be verified to ensure that the system has not lost a connection to those devices and the system state is accurate. 
[0028]      After determining that the system-instability value exceeds the threshold system-instability value, the device state management system can determine that the device database is unstable, and so is to be updated to account for the unconfirmed printing devices. When the device database is unstable, the situational system stabilization discovery approach can be used. The situational system stabilization discovery approach can efficiently recover the system state / update the device database to ensure the device database has complete and accurate information about printing devices.
[0029]      In some cases, the preventive system maintenance discovery approach can be performed before the situational system stabilization discovery approach is used; for example, when the situational system stabilization discovery approach is invoked without prior execution of the preventive system maintenance discovery approach, with an intention that the preventive system maintenance discovery approach can put the device database into a stable state without actually invoking the situational system stabilization discovery approach.
[0030]      The situational system stabilization discovery approach can attempt to find all of the unconfirmed printing devices in the device databases. But, sending probe messages to all devices in a large network using sequential IP address probing can take a long period of time to find a new IP address of the device. That is, without optimization, sequential IP address probing for lost devices may be too expensive in large-scale systems (by full range probing) and/or too inconclusive (by single target probing or simple ranged targeted probing). 
[0031]      To optimize the number of probe messages sent to update the device database, the situational system stabilization discovery approach can determine one or more address clusters associated with unconfirmed printing devices. For example, if a number of the unconfirmed printing devices are associated with a particular range of IP addresses, such as one or more particular contiguous subnets, each subnet having 256 IP addresses, then an address cluster can include part or all of the particular range of IP addresses. 
[0032]      In particular, a vector quantization technique can be applied to a list of the unconfirmed printing devices to maximize rediscovery of compromised devices and minimize ranges searched. The vector quantization method can organize IP addresses associated with unconfirmed printing devices into clusters based on their location on the IP address range, akin to numerical taxonomy. The vector quantization method can classify IP addresses associated with unconfirmed printing devices using k-means; that is, the clustering can sort a list of IP addresses associated with unconfirmed printing devices into k clusters. In some cases, the IP addresses associated with unconfirmed printing devices can be considered to be univariate (one-dimensional) data and so the Jenks natural breaks optimization that takes advantage of the sortable property of one-dimensional data can be used to cluster IP addresses.
[0033]      Once IP addresses associated with unconfirmed printing devices have been clustered, the clusters can be evaluated for targeted discovery according to one or more properties of the address cluster. Example cluster properties for evaluation can include, but are not limited to:
cluster range (number of IP addresses in the cluster),
class size (number of unconfirmed printing devices found in this cluster),
cluster density (ratio of class size to cluster range),
history of instability (frequency of this cluster being compromised), and
total active time (duration of device in device database before being considered as lost, compromised, or needing checking).
After determining address cluster(s) suitable for targeted discovery based on the cluster properties, the device state management system can send probes to IP addresses in the suitable address cluster(s), receive responses to the probes, and update the device database based on the probe responses. Thus, the device state management system can refresh / rebuild the device database using targeted discovery.
[0034]      The herein-described techniques and apparatus allow for maintaining a device database for printing devices using a relatively-small amount of bandwidth. Most, if not all of herein-described techniques and apparatus, can be utilized when computing network traffic is expected and/or measured to be relatively low, reducing the impact on other computing network activities. These techniques and apparatus can concentrate probe messaging into address clusters that have a relatively-high number of failing probes, and so can efficiently obtain the information needed to maintain the device database by reducing the probes and probe response sent to devices in address ranges that are unlikely to yield usable information for maintaining the device database. 
II.    Printing System
Examples
[0035]      FIG. 1A is a diagram illustrating printing network 100, according to an example embodiment. Printing network 100 includes computing device 110, one or more non-printing devices 120, 122, 124, 126, 128, 140, DHCP server 144, and one or more printing devices (PDs) 130, 142 interconnected using network 150. In some examples, printing network 100 can have more, fewer, and/or different types of assessment devices, non-printing devices, and/or printing devices than indicated in FIG. 1A. 
[0036]      Computing device 110, DHCP server 144, and/or non-printing devices 120, 122, 124, 126, 128, 140 can be or include computing devices configured to communicate with each other and with printing devices 130, 142 using network 150. Computing device 110 can be a printing or non-printing device that includes software for device state management system (DSMS) 112 and/or data of device database (DDB) 114. Device state management system 112 can probe printing devices, receive probe responses, and collect other data to maintain device database 114. Device database 114 can include data for maintaining printing devices in printing network 100 and perhaps other networks - example data stored in device database 114 is discussed below in the context of at least FIGS. 3C, 4B, 4D, 4F, and 4H.
[0037]      Printing devices 130, 142 can include devices configured to scan, print, copy, e-mail, account for, communicate and/or otherwise process documents and/or files that are originally available either on paper or electronically. In printing network 100, a non-printing device can be a computing device that is not a printing device, where the non-printing device can be configured to communicate with other non-printing devices and with printing devices 130, 142 using network 150.
[0038]      After processing by one or more of printing devices 130, 142, the documents and/or files can be subsequently available either on paper or electronically, as requested. That is, printing devices 130, 142 can process a paper document PD or electronic document ED by at least: creating an electronic document ED1 representing the contents of PD (e.g., scanning PD to create ED1), making one or more paper copies of PD, printing one or more copies of ED and/or ED1 on one or more types of paper, making one or more electronic copies of ED and/or ED1, changing a format of ED and/or ED1 (e.g., perform OCR scanning, converting a file format used to store ED and/or ED1), maintaining remotely-accessible storage (e.g., a document box) enabling other devices than printing devices 130, 142 to use/access ED and/or ED1, and/or communicating the contents of ED and/or ED1 to/from another device. 
[0039]      A document box can be storage allocated to an entity (e.g., a user, an administrator, a company, another type of entity) on a printing device, print server, or another device so the entity can keep and maintain documents, files, and/or other data. In some embodiments, the document box can be accompanied by and/or include storage for personal data, such as address book and/or device accounting storage. The document box, address book, and device accounting storage can store one or more documents, files, personal data, and/or other data, such as contacts, usage and usage limits. 
[0040]      In some embodiments, printing devices 130, 142 can perform other tasks and/or other processing as well. Printing devices 130, 142 can include products from various manufacturers with variations in color, speed, computing power, functionality, network connectivity, and/or other features.
[0041]       In an example embodiment, some or all printing devices 130, 142 can be connected to network 150 through one or more, possibly different, network protocols. Data can be transmitted between printing devices 130, 142 and non-printing devices 120, 122, 124, 126, 128, 140 over wired and/or wireless links between non-printing devices, printing devices, and network 150. The format of each respective data transmission between devices in printing network 100 can include one or more of a variety of different formats including: text formats, image formats, extensible mark-up language (XML), database tables, a flat file format, or another format. In some embodiments, a non-printing device can be configured to act as a print server for one or more printing devices. A print server can be configured to process jobs (e.g., spool job-related data, route jobs, provide user and/or server-related accounting for jobs, verify / enforce authentication and authorization rules related to jobs) and store data related to printing devices in printing network 100. For example, in network 150, non-printing device 140 is configured to be a print server for at least printing device 142.
[0042]      Communications between the non-printing devices, and printing devices can include: computing device 110 and/or non-printing devices 120, 122, 124, 126, 128, 140 sending data for print jobs and/or print job portions for printing to printing devices 130, 142 and printing devices 130, 142 sending alert, status, error, and/or other messages to inform other devices about error or other conditions of the printing devices; e.g., idle, printing, sleeping, paper jam, low or out of paper, low or out of toner/ink, etc. Other communications between one or more computing devices, one or more non-printing devices, and one or more printing devices are possible as well; e.g., the communications described below related to device state management system 112 and/or device database 114.
[0043]      DHCP server 144 can provide addressing information, such as IP addresses, to computing devices in network 150. In an example, let non-printing device 120 be powered down and later powered up. Upon power up, non-printing device 120 or network 150 can send a DHCP discover message to DHCP server 144 to request a new IP address for connecting to and using network 150 and/or other networks; e.g., the Internet. In response to the DHCP discover message, DHCP server 144 can allocate (or lease) an IP address for use by non-printing device 120, and send a DHCP offer message to non-printing device 120 that includes the newly-allocated IP address. Non-printing device 120 can accept the DHCP offer message and use the newly-allocated IP address to access. A similar process can be used by printing devices to obtain IP addresses from DHCP server 144.
[0044]      FIG. 1B is a schematic block diagram illustrating computing device 160, according to an example embodiment. In some embodiments, computing device 160 can be configured to perform one or more herein-described functions of: printing network 100, computing device 110, device state management system 112, device database 114, device database formats 114a, 114b, 114c, 114d, non-printing devices 120, 122, 124, 126, 128, 140, printing devices 130, 142, 310, DHCP server 144, methods 200, 500, 600, devices 410, 420, IPList 434, clustered, as well as at least part of the herein-described functionality related to scenarios 300, 400, 400a, and 580.
[0045]      Computing device 160 can include one or more input devices 162, one or more output devices 164, one or more processors 166 and memory 168. Input devices 162 can include user input devices, network input devices, sensors, and/or other types of input devices. For example, input devices 162 can include user input devices such as a touch screen, a keyboard, a keypad, a computer mouse, a track ball, a joystick, a camera, a voice recognition module, and/or other similar devices. Network input devices can include wired network receivers and/or transceivers, such as an Ethernet transceiver, a Universal Serial Bus (USB) transceiver, or similar transceiver configurable to communicate via a twisted pair wire, a coaxial cable, a fiber-optic link, or a similar physical connection to a wireline network, such as wired portions of network 150, and/or wireless network receivers and/or transceivers, such as a Bluetooth transceiver, a Zigbee transceiver, a Wi-Fi transceiver, a WiMAX transceiver, a wireless wide-area network (WWAN) transceiver and/or other similar types of wireless transceivers configurable to communicate via a wireless network, such as wireless portions of network 150. Sensors can include devices configured to measure conditions in an environment of computing device 160 and provide data about that environment, such data including, but not limited to, location data, velocity (speed, direction) data, acceleration data, and other data about the environment for computing device 160. Example sensors include, but are not limited to, GPS sensor(s), location sensors(s), gyroscope(s), accelerometer(s), magnetometer(s), camera(s), light sensor(s), infrared sensor(s), and microphone(s). Other input devices 162 are possible as well.
[0046]      Output devices 164 can include user display devices, audible output devices, network output devices, and/or other types of output devices. User display devices can include one or more printing components, liquid crystal displays (LCD), light emitting diodes (LEDs), lasers, displays using digital light processing (DLP) technology, cathode ray tubes (CRT), light bulbs, and/or other similar devices. Audible output devices can include a speaker, speaker jack, audio output port, audio output device, headphones, earphones, and/or other similar devices. Network output devices can include wired network transmitters and/or transceivers, such as an Ethernet transceiver, a Universal Serial Bus (USB) transceiver, or similar transceiver configurable to communicate via a twisted pair wire, a coaxial cable, a fiber-optic link, or a similar physical connection to a wireline network, such as wired portions of network 150, and/or wireless network transmitters and/or transceivers, such as a Bluetooth transceiver, a Zigbee transceiver, a Wi-Fi transceiver, a WiMAX transceiver, a wireless wide-area network (WWAN) transceiver and/or other similar types of wireless transceivers configurable to communicate via a wireless network, such as wireless portions of network 150. Other types of output devices can include, but are not limited to, vibration devices, haptic feedback devices, and non-visible light emission devices; e.g., devices that emit infra-red or ultra-violet light. Other output devices 164 are possible as well.
[0047]      Processors 166 can include one or more general purpose processors, central processing units (CPUs), CPU cores, and/or one or more special purpose processors (e.g., graphics processing units (GPUs), digital signal processors (DSPs), field programmable gated arrays (FPGAs), application specific integrated circuits (ASICs), etc.). Processors 166 can be configured to execute computer-readable instructions 170 that are contained in memory 168 and/or other instructions as described herein. 
[0048]      Memory 168 can include non-transitory machine-readable storage configured to store data and/or instructions. In some examples, memory 168 can store part or all of the data of device state management system 112 and/or device database 114. In other examples, memory 168 can store computer -readable instructions 170 that, when executed by processor(s) 166, can cause a computing device to perform herein-described functions, such as but not limited to, functions of herein-described devices, networks, methods, features, and scenarios. In particular, computer-readable instructions 170 can include at least some instructions for and/or related to device state management system 112 and/or device database 114. 
III. Apparatus and Methods for Finding Printing Devices and Updating Device Data
[0049]      FIGS. 2A and 2B are a flowchart for a method 200 related to discovering networked printing devices using a device state management system, according to an example embodiment. Method 200 can be executed by a device state management system, such as device state management system 112. The device state management system can be or include software executed by a computing device, such as computing device 110 discussed above in the context of FIG. 1A and/or computing device 160 discussed above in the context of FIG. 1B.
[0050]      FIG. 2A shows that method 200 can begin at block 210, which is associated with label “A”, where the device state management system can determine whether or not to send probes as part of discovering networked printing devices. For example, the above-mentioned preventive system maintenance discovery approach does not involve sending probes, while the above-mentioned situational system stabilization discovery approach does involve sending probes.
[0051]      If the device state management system determines that sending probes is part of discovering networked printing devices at this time, the device state management system can proceed to block 212. Otherwise, the device state management system determines that sending probes is not part of discovering networked printing devices at this time and the device state management system can proceed to block 214.
[0052]      At block 212, the device state management system can set a UseProbe variable equal to 1 to indicate that sending probes is part of discovering networked printing devices at this time. For example, invoking the situational system stabilization discovery approach can lead to execution of block 212 and setting UseProbe = 1. After completing block 212, the device state management system can proceed to block 218.
[0053]      At block 214, the device state management system can set the UseProbe variable equal to 0 to indicate that sending probes is not part of discovering networked printing devices at this time. For example, invoking the preventive system maintenance discovery approach can lead to execution of block 214 and setting UseProbe = 0. After completing block 214, the device state management system can proceed to block 218.
[0054]      At block 218, the device state management system can determine whether or not to check IP addresses as part of discovering networked printing devices. If the device state management system determines that checking IP addresses is part of discovering networked printing devices at this time, the device state management system can proceed to block 220. Otherwise, the device state management system determines that checking IP addresses is not part of discovering networked printing devices at this time and the device state management system can proceed to block 222.
[0055]      At block 220, the device state management system can set a UseNA variable equal to 1 to indicate that checking IP addresses is part of discovering networked printing devices at this time and can proceed to block 226.
[0056]      At block 222, the device state management system can set the UseNA variable equal to 0 to indicate that checking IP addresses is not part of discovering networked printing devices at this time and can proceed to block 226.
[0057]      At block 226, the device state management system can determine whether both the UseProbe and UseNA variables are both equal to 0. If both the UseProbe and UseNA variables are both equal to 0, then neither probing nor IP checking is to be performed at this time, indicating that discovering networked printing devices is not to be performed at this time. Then, if both the UseProbe and UseNA variables are both equal to 0, the device state management system can proceed to block 228. Otherwise, at least one of the UseProbe and UseNA variables is not equal to 0, and the device state management system can proceed to block 232. 
[0058]      At block 228, the device state management system can wait for a period of time; e.g., 1 minute, 3 hours, 1/2 day, 21 hours, 1 day. After waiting for the period of time, the device state management system can proceed to block 210. In some embodiments, method 200 can end at block 228 instead of waiting for a period of time. 
[0059]      At block 232, the device state management system can determine whether to rate or count missing printing devices. Rating missing printers involves determining activity levels for “missing” or unconfirmed printing devices, and then mathematically combining the activity levels for unconfirmed printing devices to determine a system-instability value, as discussed above. Counting missing printing devices involves maintaining a number of unconfirmed printing devices and utilizing the number of unconfirmed printing devices as a system-instability value, as also discussed above.
[0060]      If the device state management system is to count missing / unconfirmed printing devices, the device state management system can proceed to block 234. Otherwise, the device state management system is to rate missing / unconfirmed printing devices and the device state management system can proceed to block 236. 
[0061]      At block 234, the device state management system can set a UseRate variable equal to 0 and set a Threshold variable equal to a CountThreshold value. The Threshold variable of method 200 can be used as a threshold system-instability level to determine whether or not the device database is unstable, as discussed above. As an example of determining the CountThreshold value, let the device state management system have data on N printing devices, N > 0, in the device database. Then, the CountThreshold value can be based on: a predetermined number of unconfirmed printing devices, such as 1, 10, 50, 66, 100, 500, a percentage of devices, such as 10% of N, 15% of N, 20% of N + 1, and/or one or more values determined using other techniques, as discussed above. Other techniques for determining the CountThreshold value are possible. Upon completion of the procedures of block 234, the device state management system can proceed to block 240.
[0062]      At block 236, the device state management system can set a UseRate variable equal to 1 and set a Threshold variable equal to a RateThreshold value. As an example, the RateThreshold value can be based on one or more activity levels, such as a cumulative number of pages printed by the missing / unconfirmed printing devices per day (or other time period), a cumulative amount of toner used or percentage of toner used by the missing / unconfirmed printing devices, a cumulative number of alerts received by and/or from the missing / unconfirmed printing devices, and/or combinations thereof as discussed above. Other techniques for determining the RateThreshold value are possible.
[0063]      At block 240, the device state management system can obtain a list L of network addresses from a DHCP server, such as DHCP server 144. 
[0064]      At block 244, which is associated with label “E”, the device state management system can determine whether the UseProbe variable equals 0. If the UseProbe variable does equal 0, the device state management system can proceed to block 266, which is associated with label “B”. Otherwise, as the UseProbe variable does not equal 0, the device state management system can proceed to block 248.
[0065]      The procedures of blocks 248, 252, 256, 260, and 262 relate to discovery techniques utilizing probe messages. At block 248, the device state management system can obtain a network address NA for printing device PD from list L. Then, the device state management system can send a probe to network address NA for printing device PD.
[0066]      At block 252, the device state management system can determine whether there is a response to the probe sent at block 248 from printing device PD. If the device state management system has received a response to the probe, the device state management system can proceed to block 256, which is associated with label “C”. Otherwise, the device state management system has not received a response to the probe and the device state management system can proceed to block 262, which is associated with label “D”.
[0067]      Turning to FIG. 2B, at block 256, which is associated with label “C”, the device state management system can determine whether data in the probe response from printing device PD matches data stored in the device database. If the data in the probe response from printing device PD matches data stored in the device database, the device state management system can proceed to block 260. Otherwise, data in the probe response from printing device PD does not match data stored in the device database and the device state management system can proceed to block 262.
[0068]      At block 260, the device state management system can mark the device database entry for printing device PD as being confirmed. Also, the device state management system can set a BadPD variable equal to 0, indicating that current printing device PD is not an unconfirmed or “bad” printing device. Upon completion of the procedures of block 260, the device state management system can proceed to block 266.
[0069]      At block 262, which is associated with label “D”, the device state management system can mark the device database entry for printing device PD as “needing checking” or unconfirmed. Also, the device state management system can set the BadPD variable equal to 1, indicating that current printing device PD is an unconfirmed / bad printing device. 
[0070]      At block 266, which is associated with label “B”, the device state management system can determine whether the UseNA variable is set to 0. If the UseNA variable does equal 0, the device state management system can proceed to block 280. Otherwise, as the UseNA variable does not equal 0, the device state management system can proceed to block 268.
[0071]      The procedures of blocks 268, 272, 274, and 276 relate to discovery techniques utilizing checking IP addresses of list L with data stored in the device database. These discovery techniques do not require use of probe messages as indicated below. At block 268, the device state management system can obtain a network address NA for printing device PD from list L. 
[0072]      At block 272, the device state management system can determine whether there is an entry in the device database associated with network address NA. If there is an entry in the device database associated with network address NA, the device state management system can proceed to block 274. Otherwise, no entry in the device database is associated with network address NA and the device state management system can proceed to block 276
[0073]      At block 274, the device state management system can mark the device database entry for printing device PD as being confirmed. Also, the device state management system can set the BadPD variable equal to 0, indicating that current printing device PD is not an unconfirmed / bad printing device. Upon completion of the procedures of block 274, the device state management system can proceed to block 280.
[0074]      At block 276, the device state management system can mark the device database entry for printing device PD as “needing checking” or unconfirmed. Also, the device state management system can set the BadPD variable equal to 1, indicating that current printing device PD is an unconfirmed / bad printing device. 
[0075]      At block 280, the device state management system can determine whether the BadPD variable has a value of 0; i.e., current printing device PD is not an unconfirmed / bad printing device. If the BadPD variable has a value of 0, the device state management system can proceed to block 286. Otherwise, the BadPD variable has a non-zero value; i.e., current printing device PD is an unconfirmed / bad printing device, and the device state management system can proceed to block 282.
[0076]      At block 282, the device state management system can determine an activity level value AL1 for printing device PD. Then, the device state management system can update a system-instability value SI using the following equation: SI = SI + ((UseRate) * AL1) + (1-UseRate), as indicated in FIG. 2B. In method 200, UseRate has a value of either 0 or 1, as discussed above in the context of blocks 234 and 236. Then, if UseRate = 0, the equation: SI = SI + ((UseRate) * AL1) + (1-UseRate) simplifies to be SI = SI + (1 - UseRate) → SI = SI + 1, and thus SI will be incremented to update a count of unconfirmed printing devices. If UseRate = 1, the equation: SI = SI + ((UseRate) * AL1) + (1-UseRate) simplifies to be SI = SI + (UseRate * AL1) + 0 → SI = SI + AL1, and thus SI will be updated by summing the previous value of SI with the AL1 value to update a sum of activity levels of unconfirmed printing devices. 
[0077]      At block 286, the device state management system can determine whether there are more devices to assess; e.g., whether all addresses in list L have been checked, whether all entries in the device database have been marked as either confirmed or needing checking, whether time and/or other resources allocated to execution of method 200 have been consumed, etc. If there are more devices to assess, the device state management system can proceed to block 244, which is associated with label “E”. Otherwise, there are no more devices to assess and the device state management system can proceed to block 290.
[0078]      At block 290, the device state management system can determine whether the system-instability value SI is greater than the Threshold value. If SI is greater than Threshold, the device state management system can proceed to block 292. Otherwise, SI is not greater than Threshold and the device state management system can proceed to block 210, which is associated with label “A”.
[0079]      At block 292, the device state management system can stabilize the system by refreshing the device database. Refreshing the device database can include generating clusters of IP addresses associated with unconfirmed printing devices, probing for printing devices within the generated clusters, updating the device database based on probe responses, and resetting the system instability level SI to 0. Stabilizing the system and refreshing the device database are also discussed below in at least in the context of method 500 and FIGS. 5A and 5B. The stabilized / refreshed device database can be used to perform printer-related functions, such ordering replaceable supplies (e.g., toner) for a printing device based on data stored in the stabilized / refreshed device database, checking device status, and/or other functions. Upon completion of the procedures of block 292, the device state management system can proceed to block 210, which is associated with label “A”.
[0080]      FIGS. 3A, 3B, and 3C illustrate scenario 300 where a printing system similar to printing network 100 is determined to be unstable and a device database is refreshed during system stabilization, according to an example embodiment. Scenario 300 can involve device state management system 112 following method 200 where the UseNA variable is set to 0 and the UseProbe variable is set to 1; that is, probes are used to determine whether the device database is up to date.
[0081]      In scenario 300, device state management system 112 sends probes to printing devices 130, 142, and 310. In scenario 300, the probe to printing device 130 returns information that is consistent stored in the device database, and so an entry for printing device 130 in the device database is marked as confirmed. The probe sent to printing device 142 returns information that is inconsistent with the device database, and so an entry for printing device 142 in the device database is marked as needing checking and system-instability value SI is updated. The probe sent to printing device 310 times out without a response, and so an entry in the device database for printing device 310 is marked as needing checking and system-instability value SI is updated.
[0082]      In scenario 300, the system-instability value SI exceeds the threshold, and so device state management system 112 gets IP addresses from the device database that need checking or are compromised and clusters the returned IP addresses. Device state management system 112 then sends probes to the devices in the clusters of IP addresses - sending these probes includes sending probes to printing devices 142 and 310. Subsequently, device state management system 112 updates the device database according to the probe responses and resets the system-instability value SI to 0. 
[0083]      Scenario 300 involves device state management system 112 executing method 200. Prior to the onset of scenario 300, the UseNA variable was set to 0, the UseProbe variable was set to 1, and list L was obtained from DHCP server 144. FIG. 3A shows that scenario 300 begins with device state management system 112 generating and sending probe 320 to printing device 130. Printing device 130 then generates and sends probe response 322 to device state management system 112, where probe response 322 includes an IP address “IP130”, a model name “Name130”, and a serial number “SerNo130”. In other scenarios, a probe response, such as probe response 322, can include less, more, and/or different information about a device, such as printing device 130; e.g., a device name, a domain name such as a Fully Qualified Domain Name (FQDN), software, hardware, memory and/or firmware information, other address information than an IP address such as but not limited to Media Access Control (MAC) and/or Ethernet address information, one or more timestamps, hash sum / parity checking information.
[0084]      Upon reception of probe response 322, device state management system 112 can perform the procedures of block 324 to get an entry “ENTRY0” from the device database for a device having an IP address of “IP130”. 
[0085]      FIG. 3C illustrate formats 114a, 114b, 114c, 114d for a device database. Each of formats 114a, 114b, 114c, 114d is shown storing three entries for the three printing devices of scenario 300. Each of device database formats 114a, 114b, 114c, and 114d has: (1) “Entry Name” information to name the three entries as “ENTRY0”, “ENTRY1”, and “ENTRY2”; (2) respective “IP Address[es]” of “DD_IP130”,”DD_IP142”, and “DD_IP310”; (3) respective “State[s]” of each entry of “Confirmed”, “Need Checking”, and “Need Checking”, and (4) respective “Toner” values of “xx.x%”, “yy.y%”, and “zz.z%”. In some embodiments, some or all of formats 114a, 114b, 114c, 114d may not include an Entry Name and/or replace the Entry Name with a numerical, other alphanumeric, and/or binary key.
[0086]      The Toner value for a printing device can be an example device activity level for the printing device. Other example device activity levels for the printing device include: values of counters, such as page counters, obtained from the printing device, numbers and/or types of alerts generated by the printing device, rates of change of these values (e.g., a daily toner usage rate, a number of pages printed per week determined based on differences in page counter values) and combinations thereof. In some embodiments, some or all of these device activity levels can be stored in device database 114.
[0087]      Device database format 114a, illustrated in an upper portion of FIG. 3C, also includes a “Device Name” for each entry - the respective device names for entries ENTRY0, ENTRY1, and ENTRY2 are “PD130”, “PD142”, and “PD310”. Device database format 114d, illustrated in a lower portion of FIG. 3C, also includes the same device names as shown in device database format 114a. An upper-central portion of FIG. 3C shows that device database format 114b includes “Serial No.” and “Model Name” information along with the above-mentioned Entry Name, IP Address, and State information. Device database formats 114b and 114c (which is illustrated in a lower-central portion of FIG. 3C) both have “Serial No.” information for respective entries ENTRY0, ENTRY1, and ENTRY2 of “xxxxxxxxx”, “yyyyyyyyy”, and “zzzzzzzzz”, and both have respective “Model Name” information for the respective entries of “XXX”, “YYY”, and “ZZZ”. Device database format 114c also includes “Device Name” information for respective entries ENTRY0, ENTRY1, and ENTRY2 of “XXX-xxxxxxxxx”, “YYY- yyyyyyyyy”, and “ZZZ- zzzzzzzzz” - that is, the Device Names in device database format 114c are a concatenation of a respective model name, a “-“ character, and a respective serial number. As such, in other scenarios, either the serial number and model name information or the device name information used in device database format 114c can be removed as redundant. Other device database formats than 114a-114d are possible as well; e.g., format 114a can store model names along with or instead of device names.
[0088]      In scenario 300, the device database 114 uses device database format 114d.
[0089]      Returning to block 324 of FIG. 3A, as ENTRY0 is found in device database 114 as a match for IP address “IP130”, then IP address “IP130” matches the IP address “DD_IP130” stored in the device database for ENTRY0. In scenario 300, device database 114 stores ENTRY0 with a serial number of “xxxxxxxxx” and a model name of “XXX”. Device state management system 112 retrieves the “xxxxxxxxx” serial number from device database 114 as a variable “ DD_SerNo130”, and retrieves the “XXX” model name as a variable “ DD_Name130”.
[0090]       At block 326, device state management system 112 compares the IP130, Name130, and SerNo130 information from probe response 322 with respective DD_IP130, DD_Name130, and DD_SerNo130 information from device database 114 and determines that the probe response information matches the device database information for printing device 130 / ENTRY0. Device state management system 112 then marks ENTRY0 of device database 114 as “Confirmed” as indicated in FIG. 3C.
[0091]      FIG. 3A shows that scenario 300 continues with device state management system 112 generating and sending probe 330 to printing device 142. Printing device 142 then generates and sends probe response 332 to device state management system 112, where probe response 332 include an IP address “IP142”, a model name “Name142”, and a serial number “SerNo142”.
[0092]      Upon reception of probe response 332, device state management system 112 can perform the procedures of block 334 to get an entry “ENTRY1” from device database 114 for a device having an IP address of “IP142”. In scenario 300, ENTRY1 of device database 114 includes a serial number of “yyyyyyyyy” and a model name of “YYY”. Device state management system 112 stores the “yyyyyyyyy” serial number from device database 114 in a variable “DD_SerNo142”, and the “YYY” model name in a variable “DD_Name142”.
[0093]      At block 336, device state management system 112 compares the IP142, Name142, and SerNo142 information from probe response 332 with respective DD_IP142, DD_Name142, and DD_SerNo142 information from device database 114 and determines that the probe response information does not match the device database information for printing device 142 / ENTRY1. Device state management system 112 then marks ENTRY1 of device database 114 as “Need[s] Checking” as indicated in FIG. 3C. 
[0094]      As part of the procedures of block 336, device state management system 112 then updates system-instability value SI to indicate the printing network is more unstable since the data received in probe response 332 for printing device 142 is inconsistent with data stored in device database 114. In scenario 300, missing printers are counted, so the UseRate variable of method 200 is set to 0, and the CountThreshold variable is set to 1. Then, device state management system 112 updates system-instability value SI by incrementing SI to be equal to 1.
[0095]      Scenario 300 continues with device state management system 112 generating and sending probe 340 to printing device 310. In scenario 300, printing device 310 is powered down when probe 340 is sent, and so printing device 310 does not respond to probe 340. 
[0096]      At block 342, device state management system 112 times out waiting for a response to probe 340. At block 344, in accordance with method 200, an entry ENTRY2 in device database 114 for printing device 310 is marked as “Need[s] Checking” as indicated in FIG. 3C. As part of the procedures of block 344, device state management system 112 then updates system-instability value SI to indicate the printing network is more unstable since no probe response was received for printing device 310. At this stage of scenario 300, device state management system 112 updates system-instability value SI by incrementing SI to be equal to 2.
[0097]      Turning to FIG. 3B, at block 350, device state management system 112 determines that system-instability value SI of 2 exceeds the Threshold value of 1.
[0098]      At block 352, device state management system 112 queries device database 114 for entries that need checking or are compromised; i.e., entries whose State field is equal to “Need Checking” or “Compromised”. At least entries ENTRY1 and ENTRY2 are retrieved from device database 114 as a result of this query. From the retrieved entries, device state management system 112 selects the IP addresses stored in the IP address field of the entries to form a list of IP addresses “IP_CHECK”. As such, IP_CHECK includes the IP addresses DD_IP142 and DD_IP310.
[0099]      At block 354, device state management system 112 generates n clusters, C1, C2 … Cn, n > 0, of IP addresses from the IP_CHECK list generated at block 352. The clusters can be generated using a vector quantization technique, such as a natural breaks technique as discussed in more detail below in the context of at least FIGS. 5A and 5B.
[00100]     At block 356, device state management system 112 selects cluster C1 to send probes and sends probes to IP addresses in cluster C1 from the middle out. For example, let cluster C1 include a range of IP addresses [IP_LOW, IP_HIGH], IP_HIGH > IP_LOW. Then, device state management system 112 can determine a midpoint address in this range IP_MID = (IP_LOW + IP_HIGH) / 2. Then to send probes from the middle out of cluster C1, device state management system 112 can send probes to IP addresses as follows: send a first probe to midpoint address IP_MID, send a second probe to IP address IP_MID + 1 (or IP_MID - 1), send a third probe to IP address IP_MID - 1 (or IP_MID + 1), send a fourth probe to IP address IP_MID + 2 (or IP_MID - 2), send a fifth probe to IP address IP_MID - 2 (or IP_MID + 2), and so on until finally sending probes to IP address IP_HIGH and IP_LOW (or vice versa). 
[00101]     As part of sending probes to IP addresses in cluster C1, device state management system 112 generates and sends probe message 360 to printing device 310. In response, printing device 310 generates and sends probe response 362 to device state management system 112. Probe response 362 includes an IP address “IP310”, a model name “Name310”, and a serial number “SerNo310”. 
[00102]     At block 370, device state management system 112 updates entry ENTRY2 of device database 114 for printing device 310 with the data from probe response 362; e.g., IP address IP310, model name Name310, and serial number SerNo310. That is, device state management system 112 writes into device database 114: the value IP310 into the IP Address field of entry ENTRY2, the value Name310 into the Model Name field of entry ENTRY2 and the value SerNo310 into the Serial No. field of entry ENTRY2. In some examples, device state management system 112 can write a state field of entry ENTRY2 in device database 114 with a “Confirmed” (or similar) value. Scenario 300 continues with device state management system 112 finishing sending probes to cluster C1.
[00103]     At block 372, device state management system 112 selects cluster C2 to send probes and sends probes to IP addresses in cluster C2 from the middle out. Sending probes to IP addresses from the middle out of a cluster is discussed above with regards to block 356. 
[00104]     At block 374, device state management system 112 selects cluster Cn to send probes and sends probes to IP addresses in cluster Cn from the middle out. Sending probes to IP addresses from the middle out of a cluster is discussed above with regards to block 356.
[00105]     As part of sending probes to IP addresses in cluster Cn, device state management system 112 generates and sends probe message 380 to printing device 142. In response, printing device 142 generates and sends probe response 382 to device state management system 112. Probe response 382 includes an IP address “IP142”, a model name “Name142”, and a serial number “SerNo142”.
[00106]     At block 390, device state management system 112 updates entry ENTRY1 of device database 114 for printing device 142 with the data from probe response 382; e.g., IP address IP142, model name Name142, and serial number SerNo142. That is, device state management system 112 writes into device database 114: the value IP142 into the IP Address field of entry ENTRY1, the value Name142 into the Model Name field of entry ENTRY1 and the value SerNo142 into the Serial No. field of entry ENTRY1. In some examples, device state management system 112 can write a state field of entry ENTRY1 in device database 114 with a “Confirmed” (or similar) value.
[00107]      Scenario 300 continues with device state management system 112 finishing sending probes to cluster Cn. As cluster Cn is the last cluster of the clusters generated at block 354, a discovery process begun at block 350 after SI was determined to be greater than Threshold can be completed, and so the system-instability value SI can be set to 0. Upon completion of the procedures of block 390, scenario 300 can be completed.
[00108]     FIGS. 4A, 4B, 4C, and 4D illustrate scenario 400 where data in a device database is refreshed, according to an example embodiment. In scenario 400, the herein-described preventive system maintenance discovery approach is used to refresh data in device database 114, which utilizes a device database format similar to format 114a, except that toner values used in format 114a are replaced by page count values. In the context of related method 200, the UseNA variable is set to 1, and the UseProbe variable is set to 0.
[00109]     Device database 114 stores data about a printing system similar to printing network 100 that includes three printing devices: printing device 142, printing device 410, and printing device 420. The contents of device database 114 at the onset of scenario 400 are shown in FIG. 4B.
[00110]     Scenario 400 starts with device state management system 112 requesting IP addresses from DHCP server 144, which are provided to device state management system 112 from DHCP server 144 as a list “IPList”. After receiving IPList, device state management system 112 integrates IPList into device database 114. As part of integrating IPList into device database 114, device state management system 112 adds new entries for three IP addresses not already present in device database 114 and updates state information for existing entries based on IPList. 
[00111]     FIG. 4A shows that scenario 400 begins with device state management system 112 generating and sending GetIPAddresses message 430 to DHCP server 144. In response to GetIPAddresses message 430, DHCP server 144 generates and sends IPAddresses message 432 with a list of IP addresses “IPList” that are known to DHCP server 144.
[00112]     Upon reception of IPAddresses message 432, device state management system 112 carries out the procedures of block 440 to integrate IPList into device database 114. To integrate IPList into device database 114, device state management system 112 can query device database 114 with each IP address in IPList to determine whether or not there exists an entry in device database 114 for the queried-for IP address. If such an entry exists, that entry can be considered to be confirmed. Otherwise, as no entry exists for the queried-for IP address, device state management system 112 can add an entry to device database 114 for the queried-for IP address
[00113]     FIG. 4B shows contents of device database 114 prior to the integration of IPList. In particular, device database 114 includes three entries “ENTRY1”, “ENTRY2”, and “ENTRY3” which store respective IP addresses of “DD_IP130”, “DD_IP142”, and “DD_IP310”, respective device names “PD130”, “PD142”, and “PD310”, respective states of “Need Checking”, “Need Checking”, and “Need Checking”, and respective “Page Count” values of “aaa”, “bbb”, and “ccc”. 
[00114]     FIG. 4C shows the contents of IPList that were returned in IPAddresses message 432 as IPList 434. IPList 434 includes four IP addresses: “IPList1_Add0”, which is an IP address for printing device 310, “IPList1_Add1”, which is an IP address for printing device 142, “IPList1_Add2”, which is an IP address for device 410, and “IPList1_Add3”, which is an IP address for device 420. In scenario 400, device 410 is a non-printing device, and device 420 is a printing device, as indicated by the “Device 420 / PD420” annotation of the IPList1_Add3 IP address. Note that the parenthetical annotations shown in FIG. 4C are not part of IPList 434 as provided in IPAddresses message 432; rather, these annotations are provided in FIG. 4C for illustrative purposes only. In some examples, IPList 434 can have actual IP addresses in IPv4 format with values such as shown in Table 1 below: 
2019003617.tif 000022
In other examples, IPList 434 can have actual IP addresses in IPv6 or perhaps another format.
[00115]     Returning to FIG. 4A, device state management system 112 queries device database for IPList1_Add0 from IPList and finds entry ENTRY3 having IP address DD_IP310 that equals IPList1_Add0. As device database 114 has ENTRY3 corresponding to IPList1_Add0 from IPList, device state management system 112 marks a state of ENTRY3 as “Confirmed”.
[00116]     At block 442, device state management system 112 adds three new entries to device database 114. More specifically, device state management system 112 queries device database 114 for IPList1_Add1 from IPList and does not find a specific entry for IPList1_Add1. In scenario 400, both IPList1_Add1 from IPList and ENTRY2 in device database 114 are associated with printing device 142, but IPList1_Add1 differs from DD_IP142 stored with ENTRY2 of device database 114. As such, the query for IPList1_Add1 in device database 114 fails. As device database 114 does not have an entry corresponding to IPList1_Add1 from IPList, device state management system 112 adds an entry “ENTRY4a” to device database 114 with an IP address of IPList1_Add1, a state of “Need Checking”, and sets the device name and page count fields to default values represented as “----“ in FIG. 4D.
[00117]     Then, device state management system 112 queries device database 114 for IPList1_Add2 from IPList and does not find a specific entry for IPList1_Add2. In scenario 400, neither IPList1_Add2 nor the associated device 410 is represented by data in device database 114. As such, the query for IPList1_Add2 in device database 114 fails. As device database 114 does not have an entry corresponding to IPList1_Add2 from IPList, device state management system 112 adds an entry “ENTRY5a” to device database 114 with an IP address of IPList1_Add2, a state of “Need Checking”, and sets the device name and page count fields to default values.
[00118]     Additionally, device state management system 112 queries device database 114 for IPList1_Add3 from IPList and does not find a specific entry for IPList1_Add3. In scenario 400, neither IPList1_Add3 nor the associated device 420 is represented by data in device database 114. As such, the query for IPList1_Add3 in device database 114 fails. As device database 114 does not have an entry corresponding to IPList1_Add3 from IPList, device state management system 112 adds an entry “ENTRY6a” to device database 114 with an IP address of IPList1_Add3, a state of “Need Checking”, and sets the device name and page count fields to default values.
[00119]     FIG. 4D shows device database 114 after ENTRY6a has been added - five of the six entries in device database 114 have a state of “Need Checking”. In some scenarios, device database 114 can be considered to be unstable at this stage of scenario 400 as 5/6ths of the data in device database 114 is marked as needing checking.
[00120]     At block 444 of FIG. 4A, it can be determined that no IP address in IPList corresponds to DD_IP130, which is the IP address for ENTRY1, and thus the state of ENTRY1 can remain as “Need Checking”. Upon completion of the procedures of block 444, scenario 400 can be completed.
[00121]     FIGS. 4E, 4F, 4G, and 4H illustrate scenario 400a where data in a device database is refreshed, according to an example embodiment. In scenario 400a, the herein-described situational system stabilization discovery approach is used to refresh data in device database 114, which utilizes a device database format similar to format 114a, except that toner values used in format 114a are replaced by page count values. In the context of related method 200, the UseNA variable is set to 0, and the UseProbe variable is set to 1.
[00122]     Scenario 400a is similar to scenario 400, in that, initially, device database 114 has the same data in both scenarios. Also, the IPList data provided by DHCP server 144 is the same in both scenarios. However as mentioned above, the preventive system maintenance discovery approach is used in scenario 400 to integrate data from IPList into device database 114, while the situational system stabilization discovery approach is used in scenario 400a to integrate data from IPList into device database 114.
[00123]     At the onset of scenario 400a, device database 114 stores the same data about a printing system similar to printing network 100 that includes three printing devices: printing device 142, printing device 410, and printing device 420, as discussed above in the context of scenario 400. The contents of device database 114 at the onset of scenario 400a are shown in FIG. 4F (which are the same as shown in FIG. 4B).
[00124]     Scenario 400a starts with device state management system 112 requesting IP addresses from DHCP server 144, which are provided to device state management system 112 from DHCP server 144 as a list “IPList”. After receiving IPList, device state management system 112 integrates IPList into device database 114. As part of integrating IPList into device database 114, device state management system 112 adds new entries for three IP addresses not already present in device database 114 and updates state information for existing entries based on IPList and sends probe messages to confirm data in device database 114. 
[00125]     FIG. 4E shows that scenario 400a begins with device state management system 112 generating and sending GetIPAddresses message 450 to DHCP server 144. In response to GetIPAddresses message 450, DHCP server 144 generates and sends IPAddresses message 452 with a list of IP addresses “IPList” that are known to DHCP server 144.
[00126]     Upon reception of IPAddresses message 452, device state management system 112 carries out the procedures of block 456, 464, 466, 472, 474, 484, and 490 to integrate IPList into device database 114. As part of integrating IPList into device database 114, device state management system 112 can query device database 114 with each IP address in IPList to determine whether or not there exists an entry in device database 114 for the queried-for IP address. If such an entry exists, that entry can be considered to be confirmed. Otherwise, as no entry exists for the queried-for IP address, device state management system 112 can add an entry to device database 114 for the queried-for IP address.
[00127]     FIG. 4F shows contents of device database 114 prior to the integration of IPList. In particular, device database 114 includes three entries “ENTRY1”, “ENTRY2”, and “ENTRY3” which store respective IP addresses of “DD_IP130”, “DD_IP142”, and “DD_IP310”, respective device names “PD130”, “PD142”, and “PD310”, respective states of “Need Checking”, “Need Checking”, and “Need Checking”, and respective “Page Count” values of “aaa”, “bbb”, and “ccc”. 
[00128]     FIG. 4G shows the contents of IPList that were returned in IPAddresses message 452 as IPList 434, as the same data discussed above in the context of IPList 434 of FIG. 4C is provided as the “IPList” of IPAddresses message 452. More information about IPList 434 of FIG. 4G is provided in the context of IPList 434 of FIG. 4C, including Table 1.
[00129]     Returning to FIG. 4E at block 456, device state management system 112 queries device database for IPList1_Add0 from IPList and finds entry ENTRY3 having IP address DD_IP310 that equals IPList1_Add0. As device database 114 has ENTRY3 corresponding to IPList1_Add0 from IPList, device state management system 112 marks a state of ENTRY3 as “Confirmed”.
[00130]     Also at block 456, device state management system 112 adds three new entries to device database 114. More specifically, device state management system 112 queries device database 114 for IPList1_Add1 from IPList and does not find a specific entry for IPList1_Add1. In scenario 400a, both IPList1_Add1 from IPList and ENTRY2 in device database 114 are associated with printing device 142, but IPList1_Add1 differs from DD_IP142 stored with ENTRY2 of device database 114. As such, the query for IPList1_Add1 in device database 114 fails. As device database 114 does not have an entry corresponding to IPList1_Add1 from IPList, device state management system 112 adds an entry “ENTRY4” to device database 114 with an IP address of IPList1_Add1, a state of “Need Checking”, and sets the device name and page count fields to default values represented as “----“ in FIG. 4D.
[00131]     Then, device state management system 112 queries device database 114 for IPList1_Add2 from IPList and does not find a specific entry for IPList1_Add2. In scenario 400a, neither IPList1_Add2 nor the associated device 410 is represented by data in device database 114. As such, the query for IPList1_Add2 in device database 114 fails. As device database 114 does not have an entry corresponding to IPList1_Add2 from IPList, device state management system 112 adds an entry “ENTRY5” to device database 114 with an IP address of IPList1_Add2, a state of “Need Checking”, and sets the device name and page count fields to default values.
[00132]     Additionally, device state management system 112 queries device database 114 for IPList1_Add3 from IPList and does not find a specific entry for IPList1_Add3. In scenario 400, neither IPList1_Add3 nor the associated device 420 is represented by data in device database 114. As such, the query for IPList1_Add3 in device database 114 fails. As device database 114 does not have an entry corresponding to IPList1_Add3 from IPList, device state management system 112 adds an entry “ENTRY6” to device database 114 with an IP address of IPList1_Add3, a state of “Need Checking”, and sets the device name and page count fields to default values.
[00133]     After completing adding ENTRY6 to device database 114, device state management system 112 probes devices in IPList. More specifically, device state management system 112 generates and sends probe message 460 to IP address IPList1_Add1, which is an IP address for printing device 142. In response to receiving probe message 460, printing device 142 generates and sends probe response 462 to device state management system 112. Probe response 462 includes “IP142”, which is an IP address for printing device 142 that equals IPList1_Add1, “Name142”, which is a device name of printing device 142, and “PC142”, which is a page count value for printing device 142. In other scenarios, a probe response can include additional and/or different data about printing devices, such as, but not limited to, a serial number for a printing device and a model name / number for the printing device. 
[00134]     At block 464, device state management system 112 examines probe response 462 and queries device database for devices having a device name equal to the value provided as “Name142”. In scenario 400a, the value of the device name provided by “Name142” is “PD142” and the value provided by “PC142” is “bbb”. Upon querying device database 114 for “PD142”, device database 114 returns ENTRY2 for printing device 142. Then, device state management system 112 updates ENTRY2 by marking the state field to be “Confirmed” based on the data in probe response 462.
[00135]     At block 466, device state management system 112 updates ENTRY4 of device database 114, which is an entry added for IP address IPList1_Add1 of IPList, with the device name value of “PD142” and page count value of “bbb” from probe response 462. Then, device state management system 112 updates ENTRY4 by marking the state field to be “Confirmed” based on the data in probe response 462.
[00136]     Scenario 400a continues with device state management system 112 continuing to probe devices in IPList. More specifically, device state management system 112 generates and sends probe message 470 to IP address IPList1_Add2, which is an IP address for device 410. In scenario 400a, device 410 does not respond to probe 470, as indicated in FIG. 4E by probe 470 timing out at block 472. 
[00137]     At block 474, device state management system 112 responds to probe 470 timing out by deleting ENTRY5, which was added for IP address IPList1_Add2 from IPList, from device database 114. FIG. 4H shows data for ENTRY5 including a state of “Deleted”. In other scenarios, ENTRY5 can be removed from device database 114.
[00138]     Scenario 400a continues with device state management system 112 continuing to probe devices in IPList. More specifically, device state management system 112 generates and sends probe message 480 to IP address IPList1_Add3, which is an IP address for device 420. In response to receiving probe message 480, device 420 generates and sends probe response 482 to device state management system 112. Probe response 482 includes “IPList1_Add3”, which is an IP address for device 420, “Name420”, which is a device name of printing device 420, and “PC420”, which is a page count value for device 420. Utilizing the data in probe response 482, such as the device name and page count data, device state management system 112 can determine that device 420 is a printing device. In scenario 400a, the value of the device name provided by “Name420” is “PD420” and the value provided by “PC420” is “ddd”.
[00139]     At block 484, device state management system 112 queries device database 114 for device name “PD420”, and this query fails, indicating that printing device 420 is a previously unknown printing device that was discovered by probe message 480 and probe response 482. Device state management system 112 then updates ENTRY6 of device database 114, which is an entry added for IP address IPList1_Add3 of IPList, with the device name value of “PD420” and page count value of “ddd” from probe response 482. Device state management system 112 can also update ENTRY6 by marking the state field to be “Confirmed”.
[00140]     At block 490, device state management system 112 determines that the printing device whose device name is “PD130” in ENTRY1 of device database 114 is not represented by an IP address in IPList. Thus, ENTRY1 corresponds to a device that has been lost; e.g., removed from the printing network and/or had enough data about the device changed to render the data stored in ENTRY1 as out of date. Then, device state management system 112 can mark the state of ENTRY1 of device database 114 as “Lost”, as indicated in FIG. 4H. In other scenarios, device state management system 112 can delete entries of device database 114 corresponding to lost devices. In still other scenarios, a lost device can be considered to compromise the state of the printing network.
[00141]     FIG. 4H shows the data in device database 114 at the end of scenario 400a. At the end of scenario 400a, only one entry out of five non-deleted entries is not confirmed. In some scenarios, device database 114 can be considered to be stable at this stage of scenario 400a as 1/5th of the data in device database 114 is marked as lost, and 4/5ths of the data is confirmed.
[00142]     FIG. 5A is a flowchart of a method 500 for stabilizing a printing system, according to an example embodiment. In some examples, method 500 can be used to perform the functionality of block 292 of method 200 discussed above in the context of FIG. 2B; that is, method 500 can be invoked to stabilize system and/or refresh the device database using probes sent to IP addresses within one or more clusters of IP addresses.
[00143]     As with method 200, method 500 can be executed by a device state management system, such as device state management system 112. The device state management system can be or include software executed by a computing device, such as computing device 110 discussed above in the context of FIG. 1A and/or computing device 160 discussed above in the context of FIG. 1B.
[00144]     Method 500 can begin at block 510, where the device state management system can determine that a printing system needs stabilization. For example, if the system-instability value SI of method 200 exceeds threshold Threshold, then the device state management system can determine that the system needs stabilization.
[00145]     At block 512, after determining that the printing system needs stabilization, the device state management system can determine a list IP_LOST of IP addresses of lost and/or compromised devices. For example, using example data as shown in FIG. 4H, the device state management system can query the device database to retrieve all IP addresses of entries in the database whose state values are “Lost”, “Compromised”, or “Need Checking” - in the example shown in FIG. 4H, such a query would return one IP address “DD_IP130” as the IP_LOST list. As another example, using example data as shown in FIG. 4D, the device state management system can query the device database to retrieve all IP addresses of entries in the database whose state values are “Lost”, “Compromised”, or “Need Checking” - in the example shown in FIG. 4D, such a query would return a list of five IP addresses as the IP_LOST list: “DD_IP130”, “DD_IP142”, “IPList1_Add1”, “IPList1_Add2”, and “IPList1_Add3”. Other example queries and query responses are possible as well.
[00146]     At block 520, the device state management system can determine n clusters, n > 0, shown in FIG. 5A as clusters “C1, C2 … Cn” of IP addresses for the IP_LOST list. To determine clusters C1, C2 … Cn, a vector quantization algorithm, such as a k-means or a natural breaks algorithm can be used. The k-means algorithm can involve selecting a value k, k > 0, representing a number of clusters; i.e., in this example, k = n. Then, each cluster of IP addresses is represented by a mean (average) value for the cluster. For example, suppose the IP addresses are in a range R1 of 10.100.0.0 to 10.100.0.255 for a total range of 256 different IP addresses, and k = n = 2. Then, a first cluster C1 can represent the first 128 addresses in that R1, with an initial mean value of 10.100.0.64, and a second cluster C2 can represent the second 128 addresses in R1, with an initial mean value of 10.100.0.192. Another technique for assigning initial means to the n clusters is to select the first n values to be clustered, that is, values in the IP_LOST list, and assign each of the first n values to one of the C1, C2 … Cn clusters. Other techniques for determining initial means are possible as well.
[00147]     Then, for each IP address I_IN in the IP_LOST address list the k-means algorithm can include first selecting a cluster for I_IN that has the closest mean to I_IN. For example if I_IN = 10.100.0.22, then cluster C1 having mean 10.100.0.64 is selected for I_IN, as 10.100.0.64 is closer to 10.100.0.22 than 10.100.0.192 (the mean of cluster C2). Then, I_IN is added to the selected cluster and the mean of the values in the selected cluster is recalculated - that is, after I_IN is added to cluster C1, the new mean can be determined to be the value of I_IN, 10.100.0.22. Then, suppose IP_LIST had a second IP address, 10.100.0.6 to be added to cluster C1. After adding 10.100.0.6 to C1, the mean of C1 can be updated to be (10.100.0.22 + 10.100.0.6) / 2 = 10.100.0.14. After all of the addresses in the IP_LOST address list have been added to the n clusters, the k-means algorithm can be completed.
[00148]     A natural breaks algorithm is based on finding inherent clustering in a data set, such as the IP_LOST address list. Such an inherent clustering can be based on clusters having similar values and with relatively-large differences between clusters. An example of a natural breaks algorithm is the Jenks optimization for univariate (one variable) data, such as the IP addresses in IP_LIST. The Jenks optimization involves making a first attempt to cluster the data into n clusters. This first attempt can be an arbitrary clustering. For example, suppose IP_LIST had NIP values in the list, so cluster C1 could be the first NIP/n values in IP_LIST, cluster C2 could be the second NIP/n values in IP_LIST, and so on, until determining cluster Cn as the last NIP/n values in IP_LIST.
[00149]     After an (initial) clustering has been determined, the Jenks optimization is an iterative process operating on the clusters of data. That is, calculations must be repeated using different choices of clusters to determine which set of clusters has the smallest in-class variance. 
[00150]     For each iteration of the Jenks optimization, the device state management system can:
1.    Calculate the sum of squared deviations from the array (cluster) mean SDAM by determining a mean for each cluster, determining a mean of the cluster means CMEAN, and taking the sum of squares of differences between each cluster mean and the CMEAN value.
2.    Calculate the sum of squared deviations between clusters SDBC by determining, for each cluster C_i, a sum SD_i of squares of differences between each cluster mean and each value in the cluster, and then letting SDBC equal a sum of the respective SD_i values over all n clusters. 
3.    Subtract the SDBC from the SDAM (SDAM-SDBC). This equals the sum of the squared deviations from the class means (SDCM), and.
4.    Move one IP address from the cluster having the largest C_i value to the cluster having the smallest C_i value.
[00151]     As an alternative to iterative processing, all possible cluster combinations may be examined, SDCM calculated for each combination, and the combination with the lowest SDCM selected. Since all break combinations are examined, this guarantees that the one with the lowest SDCM is found. Also, a GVF statistic (goodness of variance fit) can be calculated. GVF is defined as (SDAM - SDCM) / SDAM. GVF ranges from 0 (worst fit) to 1 (perfect fit). Other clustering techniques are possible as well.
[00152]     Also at block 520, the device state management system can initialize a cluster index value CL equal to 1.
[00153]     Blocks 530 through 564 are intended to be performed for each cluster C1, C2 … Cn. At block 530, the device state management system can determine whether the cluster index value CL is greater than n, which is the total number of clusters. If CL is greater than n, the device state management system can proceed to block 570. Otherwise, CL is less than or equal to n, and the device state management system can proceed to block 540.
[00154]     At block 540, the device state management system can determine one or more characteristics CH1 of cluster CL. The characteristics CH1 can include, but are not limited to, a range of addresses AR for cluster CL, a number of lost devices, compromised devices, and/or devices that need checking in cluster CL, historical information about cluster CL (e.g., information about previous counts of addresses with lost/compromised devices, specific addresses in cluster CL that have had lost/compromised devices, etc.), an active time AT of cluster CL, and an address density AD of cluster CL. 
[00155]     An active time AT of cluster CL can be determined as an amount of time that one or more devices within an address range of cluster CL have been lost, compromised, and/or needed checking. For example, an active time AT can be determined based on a longest time since a device within a cluster has been determined to be lost, compromised and/or needed checking, an average time for all devices within the cluster have been determined to be lost, compromised and/or needed checking, or some other value representing an amount time since one or more devices within the cluster have been marked as lost, compromised and/or needed checking.
[00156]     The address density AD of a cluster C can be determined as: 
AD = NLF / NAC, 
where:
NLF = a number of lost / compromised devices within cluster C, and 
NAC = a number of addresses in the cluster. 
The NAC value can be determined as: NAC = AR_HI - AR_LO + 1, where AR_HI is the highest IP address in address range AR for the cluster, and AR_LO is the lowest IP address in address range AR, and where AR_HI is assumed to be greater than or equal to AR_LO. 
[00157]     At block 550, the device state management system can determine whether to probe cluster CL based on characteristics CL1. If the device state management system determines to probe cluster CL, the device state management system can proceed to block 560. Otherwise, the device state management system determines not to probe cluster CL and can proceed to block 564.
[00158]     Generally speaking, clusters with relatively-small address ranges / numbers of addresses are more likely to be probed than clusters with relatively-large address ranges. Also, clusters with relatively-large numbers of lost devices, compromised devices, and/or devices that need checking are more likely to be probed than clusters with relatively-small numbers of lost/compromised devices. As such, clusters with relatively-high address density AD values are more likely to be probed than clusters with relatively-low address density AD values, as clusters with high AD values have a relatively-large number of lost/compromised devices per cluster address. Further, clusters with relatively-high active time AT values are more likely to be probed, as having relatively stale information, than clusters with relatively-low active time AT values. 
[00159]     FIG. 5B illustrates a histogram 590 related to clusters of addresses of lost and/or compromised printing devices of a printing system and probe decisions 592 for the clusters of addresses, according to an example embodiment. In the example shown in FIG. 5B, an IP address range of five clusters (n = 5) have been determined. Histogram 590 shows the address value increasing along an X axis and a number of lost and/or compromised devices within the address range along a Y axis - a taller (or shorter) bar in histogram 590 indicates a larger (or smaller) number of lost and/or compromised devices within a particular portion of the IP address range represented by the bar.
[00160]     Based on the characteristics CL1 determined for each of the five clusters - Clusters A, B, C, D, and E - shown in FIG. 5B, a probe decision can be determined at block 550 and refined and block 560. The probe decision made at block 550 can be to determine whether to probe any portion a cluster. For example, cluster A is a relatively large cluster in terms of address range, but has a relatively small number of lost/compromised devices relative to other clusters, such as cluster D. Therefore, based on the large address range and perhaps the small number of lost/compromised devices, the probe decision for cluster A is to not probe the cluster. As such, blocks 560 and 562 of method 500 would not be executed for cluster A. A similar calculation, based on address density AD of cluster C can be determined.
[00161]     Returning to FIG 5A, at block 560, the device state management system can determine one or more probe ranges with cluster CL. Block 560 relates to the concept that all probed clusters are not treated indiscriminately. Clusters can vary in the level of compromised severity based on one or more characteristics CH1 for the cluster. Due to this variance in severity, target ranges from a cluster centroid, or mean value, can be calculated with regard to the properties used to classify it.
[00162]     In the example shown in FIG. 5B, probe decisions 592 indicate that clusters B, D, and E of histogram 590 are to be probed, and so blocks 560 and 562 of method 500 would be executed for these clusters. For cluster D, at block 560, the device state management system can determine that cluster D has a smaller cluster range and a higher number of lost / compromised devices within the cluster and could benefit from full discovery where each address in cluster D is probed. However, partial discovery can suffice for clusters B and E. For cluster B, the lower half of the range has a relatively large number of lost / compromised devices, and so at block 560, the device state management system can determine that a probe range including the lower half of cluster B is to be probed. Similarly, for cluster E, the lower 2/3rd of the address range has a relatively large number of lost / compromised devices, and so the device state management system can determine that a probe range including the lower 2/3rd of cluster E is to be probed. Other probe decisions are possible as well.
[00163]     Returning to FIG 5A, at block 562, the device state management system can send one or more probe messages to IP addresses with the probe range(s) for cluster CL determined at block 560. After sending the probe message(s), the device state management system can await and perhaps receive one or more probe responses to the probe messages. In some examples, probe messages can be sent from the middle out as discussed above in the context of at least block 356 of FIG. 3B. Upon reception of the probe responses, the device state management system can update the device database based on data in the probe messages, such as discussed above at least in the context of FIGS. 3A-4H.
[00164]     At block 564, the device state management system can increment the cluster index value CL by one. After incrementing CL, the device state management system can proceed to block 530.
[00165]     At block 570, the device state management system can reset the system-instability value SI; i.e., set SI = 0. Upon completion of the procedures of block 570, method 500 can be completed.
IV.    Example Methods of Operation
[00166]     FIG. 6 shows a flowchart for method 600, according to an example embodiment. Method 600 can be carried out by a device state management system. The device state management system can be implemented in software executable by a computing device, such as computing device 110 and/or computing device 160. 
[00167]     Method 600 can begin at block 610, where the device state management system can send a plurality of probe messages to a plurality of printing devices, such as discussed above at least in the context of FIGS. 2A-3B and 4E-5A.
[00168]     At block 620, the device state management system can receive a plurality of response messages to the plurality of probe messages, where a number of the plurality of response messages is less than or equal to a number of the plurality of probe messages, such as discussed above at least in the context of FIGS. 2A-3B and 4E-5A.
[00169]     At block 630, after receiving the plurality of response messages, a number of unconfirmed printing devices can be determined based on data stored in a device database associated with the device state management system, such as discussed above at least in the context of FIGS. 2A-3B. In some embodiments, the device database associated with the device state management system can store, for a particular printing device of the one or more printing devices: a serial number for the particular printing device; a model name for the particular printing device; and a network address for the particular printing device, such as discussed above at least in the context of FIGS. 2A-3C. In particular of these embodiments, the device database associated with the device state management system can further store, for the particular printing device, a device activity level for the particular printing device, such as discussed above at least in the context of FIGS. 2A-3C.
[00170]     At block 640, the device state management system can determine a system-instability value associated with the number of unconfirmed printing devices, such as discussed above at least in the context of FIGS. 2A-3B. In some embodiments, determining the system-instability value associated with the number of unconfirmed printing devices can include: determining a particular response message of the plurality of response messages that is associated with a particular printing device; determining whether a response-message serial number in the particular response message differs from a serial number for the particular printing device from the device database; and after determining that the response-message serial number in the particular response message differs from the serial number for the particular printing device from the device database, increasing the system-instability value, such as discussed above at least in the context of FIGS. 2A-3B.
[00171]     At block 650, the device state management system can determine whether the system-instability value associated with the number of unconfirmed printing devices exceeds a threshold system-instability value using the device state management system, such as discussed above at least in the context of FIGS. 2A-3B. In some embodiments, the system-instability value associated with the number of unconfirmed printing devices can include the number of unconfirmed printing devices, and the threshold system-instability value can include a threshold number of unconfirmed printing devices, such as discussed above at least in the context of FIGS. 2A-3B.
[00172]     At block 660, after determining that the system-instability value exceeds the threshold system-instability value, the device state management system can: determine one or more address clusters associated with unconfirmed printing devices, each address cluster including one or more addresses associated with one or more printing devices; send one or more probe messages to one or more addresses within at least one of the one or more address clusters; receive one or more responses to the one or more probe messages; and update the device database using data received in the one or more responses, such as discussed above at least in the context of FIGS. 2A-3B, 5A, and 5B.
[00173]     In some embodiments, determining the one or more address clusters associated with unconfirmed printing devices can include determining the one or more address clusters associated with unconfirmed printing devices using a vector quantization technique, such as discussed above at least in the context of FIGS. 5A and 5B. In other embodiments, determining the one or more address clusters associated with unconfirmed printing devices can include determining the one or more address clusters associated with unconfirmed printing devices using a natural breaks technique, such as discussed above at least in the context of FIGS. 5A and 5B.
[00174]     In still other embodiments, sending the one or more probe messages to the one or more addresses within at least one of the one or more address clusters can include: selecting a first cluster of the one or more address clusters based on a number of unconfirmed printing devices whose addresses are within the first cluster; and sending one or more probe messages to one or more addresses within the first cluster, such as discussed above at least in the context of FIGS. 2B, 3A, 3B, 5A, and 5B. In some of these embodiments, selecting the first cluster of the one or more address clusters can include selecting the first cluster based on a density of unconfirmed printing devices whose addresses are within the first cluster; where the density of unconfirmed printing devices whose addresses are within the first cluster is based on the number of unconfirmed printing devices whose addresses are within the first cluster, such as discussed above at least in the context of FIGS. 5A and 5B.
[00175]     In even other embodiments, sending one or more probe messages to one or more addresses within at least one of the one or more address clusters can include: determining a midpoint address of the one or more addresses within at least one of the one or more address clusters; and sending the one or more probe messages to the one or more addresses starting with the midpoint address, such as discussed above at least in the context of FIGS. 3A and 3B. In particular of these embodiments, sending the one or more probe messages to the one or more addresses starting with the midpoint address can include sending the one or more probe messages to the one or more addresses starting with the midpoint address in an order that includes: sending a probe message to the midpoint address and then sending a probe message to an address adjacent to the midpoint address, such as discussed above at least in the context of FIGS. 3A and 3B. In more particular of these embodiments, the address adjacent to the midpoint address can be one of: an address immediately after the midpoint address and an address immediately preceding the midpoint address, such as discussed above at least in the context of FIGS. 3A and 3B.
[00176]     In some embodiments, method 600 can further include: sending an address-request message from the device state management system; in response to the address-request message, receiving one or more network addresses associated with the plurality of printing devices; and updating the device database based on the received one or more network addresses, such as discussed above at least in the context of FIGS. 2A-4H. In some of these embodiments, sending the address-request message from the device state management system can include sending an address-request message from the device state management system to a Dynamic Host Configuration Protocol (DHCP) server, such as discussed above at least in the context of FIGS. 2A-4H. In other of these embodiments, determining the number of unconfirmed printing devices based on data stored in the device database associated with the device state management system includes: determining a particular network address of the received one or more network addresses; determining whether the device database does not store data associated with the particular network address; and after determining that the device database does not store data associated with the particular network address, incrementing the number of unconfirmed printing devices, such as discussed above at least in the context of FIGS. 2A-3B.
[00177]     In other embodiments, method 600 can further include: determining a device activity level for each printing device in the plurality of printing devices using the device state management system, such as discussed above at least in the context of FIGS. 2A and 2B. In some of these embodiments, determining the system-instability value associated with the number of unconfirmed printing devices can include determining the system-instability value associated with the number of unconfirmed printing devices based on the device activity levels of the number of unconfirmed printing devices, and the threshold system-instability value can include a threshold value that is based on device activity levels, such as discussed above at least in the context of FIGS. 2A and 2B. In still other embodiments, method 600 can further include: generating an order for replaceable supplies for a printing device based on data stored in the device database associated with the device state management system, such as discussed above at least in the context of FIGS. 2A and 2B.
[00178]     The illustrative embodiments described in the detailed description, figures, and claims are not meant to be limiting. Other embodiments can be utilized, and other changes can be made, without departing from the spirit or scope of the subject matter presented herein. It will be readily understood that the aspects of the present disclosure, as generally described herein, and illustrated in the figures, can be arranged, substituted, combined, separated, and designed in a wide variety of different configurations, all of which are explicitly contemplated herein.
[00179]     With respect to any or all of the ladder diagrams, scenarios, and flow charts in the figures and as discussed herein, each block and/or communication may represent a processing of information and/or a transmission of information in accordance with example embodiments. Alternative embodiments are included within the scope of these example embodiments. In these alternative embodiments, for example, functions described as blocks, transmissions, communications, requests, responses, and/or messages may be executed out of order from that shown or discussed, including substantially concurrent or in reverse order, depending on the functionality involved. Further, more or fewer blocks and/or functions may be used with any of the ladder diagrams, scenarios, and flow charts discussed herein, and these ladder diagrams, scenarios, and flow charts may be combined with one another, in part or in whole. 
[00180]     A block that represents a processing of information may correspond to circuitry that can be configured to perform the specific logical functions of a method or technique. Alternatively or additionally, a block that represents a processing of information may correspond to a module, a segment, or a portion of program code (including related data). The program code may include one or more instructions executable by a processor for implementing specific logical functions or actions in the method or technique. The program code and/or related data may be stored on any type of computer readable medium such as a storage device including a disk or hard drive or other storage medium. 
[00181]     The computer readable medium may also include non-transitory computer readable media such as computer-readable media that stores data for short periods of time like register memory, processor cache, and random access memory (RAM). The computer readable media may also include non-transitory computer readable media that stores program code and/or data for longer periods of time, such as secondary or persistent long term storage, like read only memory (ROM), optical or magnetic disks, compact-disc read only memory (CD-ROM), for example. The computer readable media may also be any other volatile or non-volatile storage systems. A computer readable medium may be considered a computer readable storage medium, for example, or a tangible storage device. 
[00182]     While various aspects and embodiments have been disclosed herein, other aspects and embodiments will be apparent to those skilled in the art. The various aspects and embodiments disclosed herein are for purposes of illustration and are not intended to be limiting, with the true scope being indicated by the claims.
REFFERENCE SIGNS LIST
[00183]      
100    Printing Network
110    Computing Device
112    Device State Management System (DSMS)
114    Device Database (DDB)
120    Non-Printing Device
130    Printing Device (PD)
122    Non-Printing Device
128    Non-Printing Device
150    Network
144    DHCP Server
124    Non-Printing Device
126    Non-Printing Device
140    Non-Printing Device
142    Printing Device
What is claimed is:
1.    A computing device, comprising:
one or more processors; and
data storage configured to store at least computer-readable instructions that comprise instructions for a device state management system and that, when executed by the one or more processors, cause the computing device to perform tasks comprising:
sending a plurality of probe messages to a plurality of printing devices from the device state management system;
receiving, at the device state management system, a plurality of response messages to the plurality of probe messages, wherein a number of the plurality of response messages is less than or equal to a number of the plurality of probe messages;
after receiving the plurality of response messages, determining a number of unconfirmed printing devices based on data stored in a device database associated with the device state management system;
determining a system-instability value associated with the number of unconfirmed printing devices using the device state management system;
determining whether the system-instability value associated with the number of unconfirmed printing devices exceeds a threshold system-instability value using the device state management system; and
after determining that the system-instability value exceeds the threshold system-instability value, the device state management system:
determining one or more address clusters associated with the unconfirmed printing devices, each address cluster comprising one or more addresses associated with one or more printing devices;
sending one or more probe messages to one or more addresses within at least one of the one or more address clusters; 
receiving one or more responses to the one or more probe messages; and
updating the device database using data received in the one or more responses.
2.    The computing device of claim 1, further performing:
sending an address-request message from the device state management system; 
in response to the address-request message, receiving one or more network addresses associated with the plurality of printing devices; and
updating the device database based on the received one or more network addresses.
3.    The computing device of claim 1 or 2, wherein sending the address-request message from the device state management system comprises sending an address-request message from the device state management system to a Dynamic Host Configuration Protocol (DHCP) server.
4.    The computing device of claim 2, wherein determining the number of unconfirmed printing devices based on data stored in the device database associated with the device state management system comprises:
determining a particular network address of the received one or more network addresses; 
determining whether the device database does not store data associated with the particular network address; and
after determining that the device database does not store data associated with the particular network address, incrementing the number of unconfirmed printing devices.
5.    The computing device of any of claims 1 to 4, wherein the system-instability value associated with the number of unconfirmed printing devices comprises the number of unconfirmed printing devices, and wherein the threshold system-instability value comprises a threshold number of unconfirmed printing devices.
6.    The computing device of any of claims 1 to 5, further performing:
determining a device activity level for each printing device in the plurality of printing devices using the device state management system.
7.    The computing device of claim 6, wherein determining the system-instability value associated with the number of unconfirmed printing devices comprises determining the system-instability value associated with the number of unconfirmed printing devices based on the device activity levels of the number of unconfirmed printing devices, and wherein the threshold system-instability value comprises a threshold value that is based on device activity levels.
8.    The computing device of any of claims 1 to 7, wherein the device database associated with the device state management system stores, for a particular printing device of the one or more printing devices:
a serial number for the particular printing device;
a model name for the particular printing device; and 
a network address for the particular printing device.
9.    The computing device of claim 8, wherein the device database associated with the device state management system further stores, for the particular printing device, a device activity level for the particular printing device.
10.   The computing device of any of claims 1 to 9, wherein determining the system-instability value associated with the number of unconfirmed printing devices comprises:
determining a particular response message of the plurality of response messages that is associated with a particular printing device;
determining whether a response-message serial number in the particular response message differs from a serial number for the particular printing device from the device database; and
after determining that the response-message serial number in the particular response message differs from the serial number for the particular printing device from the device database, increasing the system-instability value.
11.   The computing device of any of claims 1 to 10, wherein determining the one or more address clusters associated with the unconfirmed printing devices comprises determining the one or more address clusters associated with the unconfirmed printing devices using a vector quantization technique.
12.   The computing device of any of claims 1 to 11, wherein determining the one or more address clusters associated with the unconfirmed printing devices comprises determining the one or more address clusters associated with the unconfirmed printing devices using a natural breaks technique.
13.   The computing device of any of claims 1 to 12, wherein sending the one or more probe messages to the one or more addresses within at least one of the one or more address clusters comprises:
selecting a first cluster of the one or more address clusters based on a number of unconfirmed printing devices whose addresses are within the first cluster; and
sending one or more probe messages to one or more addresses within the first cluster.
14.   The computing device of claim 13, wherein selecting the first cluster of the one or more address clusters comprises selecting the first cluster based on a density of unconfirmed printing devices whose addresses are within the first cluster; and 
wherein the density of unconfirmed printing devices whose addresses are within the first cluster is based on the number of unconfirmed printing devices whose addresses are within the first cluster.
15.   The computing device of any of claims 1 to 14, wherein sending one or more probe messages to one or more addresses within at least one of the one or more address clusters comprises:
determining a midpoint address of the one or more addresses within at least one of the one or more address clusters; and
sending the one or more probe messages to the one or more addresses starting with the midpoint address.
16.   The computing device of claim 15, wherein sending the one or more probe messages to the one or more addresses starting with the midpoint address comprises sending the one or more probe messages to the one or more addresses starting with the midpoint address in an order that includes: sending a probe message to the midpoint address and then sending a probe message to an address adjacent to the midpoint address.
17.   The computing device of claim 16, wherein the address adjacent to the midpoint address is one of: an address immediately after the midpoint address and an address immediately preceding the midpoint address.
18.   The computing device of any of claims 1 to 17, further performing:
generating an order for replaceable supplies for a printing device based on data stored in the device database associated with the device state management system.
19.   A method, comprising:
sending a plurality of probe messages to a plurality of printing devices from a device state management system that comprises software executing on a computing device;
receiving, at the device state management system, a plurality of response messages to the plurality of probe messages, wherein a number of the plurality of response messages is less than or equal to a number of the plurality of probe messages;
after receiving the plurality of response messages, determining a number of unconfirmed printing devices based on data stored in a device database associated with the device state management system;
determining a system-instability value associated with the number of unconfirmed printing devices using the device state management system;
determining whether the system-instability value associated with the number of unconfirmed printing devices exceeds a threshold system-instability value using the device state management system; and
after determining that the system-instability value exceeds the threshold system-instability value, the device state management system:
determining one or more address clusters associated with the unconfirmed printing devices, each address cluster comprising one or more addresses associated with one or more printing devices;
sending one or more probe messages to one or more addresses within at least one of the one or more address clusters; 
receiving one or more responses to the one or more probe messages; and
updating the device database using data received in the one or more responses.
20.   A computer program for causing a computing device to perform tasks comprising:
sending a plurality of probe messages to a plurality of printing devices from the device state management system;
receiving, at the device state management system, a plurality of response messages to the plurality of probe messages, wherein a number of the plurality of response messages is less than or equal to a number of the plurality of probe messages;
after receiving the plurality of response messages, determining a number of unconfirmed printing devices based on data stored in a device database associated with the device state management system;
determining a system-instability value associated with the number of unconfirmed printing devices using the device state management system;
determining whether the system-instability value associated with the number of unconfirmed printing devices exceeds a threshold system-instability value using the device state management system; and
after determining that the system-instability value exceeds the threshold system-instability value, the device state management system:
determining one or more address clusters associated with the unconfirmed printing devices, each address cluster comprising one or more addresses associated with one or more printing devices;
sending one or more probe messages to one or more addresses within at least one of the one or more address clusters; 
receiving one or more responses to the one or more probe messages; and
updating the device database using data received in the one or more responses.
1.  Abstract
2.  SOLUTION
Methods and apparatus for updating data for printing devices are provided. A device state management system (DSMS) can send probe messages to printing devices. The DSMS can receive responses to the probe messages, where the number of probe messages can exceed the number of responses. After receiving the responses, a number of unconfirmed printing devices can be determined based on data stored in a device database (DDB) associated with the DSMS. The DSMS can determine a system-instability value associated with the number of unconfirmed printing devices. The DSMS can determine whether the system-instability value exceeds a threshold. After determining that the system-instability value exceeds the threshold, the DSMS can: determine address clusters associated with the unconfirmed printing devices; send probe messages to addresses within at least one address cluster; receive responses to the probe messages; and update the DDB using data in the responses.
3. Representative Drawing: Fig. 1A 
2019003617.tif 000023
2019003617.tif 000024
2019003617.tif 000025
2019003617.tif 000026
2019003617.tif 000027
2019003617.tif 000028
2019003617.tif 000029
2019003617.tif 000030
2019003617.tif 000031
2019003617.tif 000032
2019003617.tif 000033
2019003617.tif 000034
2019003617.tif 000035
2019003617.tif 000036
2019003617.tif 000037
2019003617.tif 000038
2019003617.tif 000039
2019003617.tif 000040