JP4618358B2 - 周辺装置管理プログラム、および周辺装置管理システム - Google Patents

Description

本発明は、周辺装置管理プログラム、および周辺装置管理システムに関する。

従来、周辺装置のファームウェアを更新する際に利用される技術として、下記特許文献１に記載の技術が提案されている。
この特許文献１に記載の技術において、クライアントＰＣは、プリンタメーカのウェブサイトから提供される最新ファームウェアのバージョンと、既にプリンタに導入済みのファームウェアのバージョンについて、いずれが高バージョンかを確認する。そして、最新ファームウェアの方が高バージョンであれば、所定の処理（特許文献１においては、プリンタのファームウェアをアップデートする処理）を実行している。
特開２００４−１１０３９６号公報

ところで、ネットワーク上の周辺装置は、常に電源が入っているとは限らず、また、電源は入っていてもオフラインになっている等、常にＰＣと通信可能な状態になっているとは限らない。そのため、上記特許文献１に記載の技術を利用する場合でも、ファームウェアバージョンを確認するタイミングによっては、周辺装置からファームウェアのバージョン情報を取得できず、ファームウェアバージョンの確認に失敗することがある。

ここで、ファームウェアバージョンの確認に失敗した場合の対策としては、例えば、ファームウェアバージョンの確認に成功するまで、ある程度時間が経過する毎に、ファームウェアバージョンの確認を再試行する、といった方法が考えられる。

しかし、過剰に頻繁にファームウェアバージョンの確認を再試行することになると、そのような処理を実行する情報処理装置には相応の負荷がかかり、また、周辺装置が接続されたネットワークにも相応の負荷がかかる、という問題がある。

もちろん、単に情報処理装置やネットワークにかかる負荷を軽減することだけを考えれば、次にファームウェアバージョンの確認を再試行するまでの期間を十分に長くすることで、再試行の頻度を低下させることはできる。

しかし、単に再試行の頻度を低下させるだけでは、実際にファームウェアバージョンの確認ができる状況にあったか否かを問わず、確認タイミングが遅くなってしまう、という問題がある。

つまり、ファームウェアバージョンの確認を再試行する頻度は、一律に高くしても一律に低くしても相応に問題があり、適切なタイミングで周辺装置から情報を取得することは、必ずしも容易なことではない、という問題があった。

本発明は、上記問題を解決するためになされたものであり、その目的は、周辺装置からファームウェアの情報が取得できなかった場合に、その後適切なタイミングでファームウェアの情報を取得することができる周辺装置管理プログラム、および周辺装置管理システムを提供することにある。

以下、本発明において採用した構成について説明する。
請求項１に記載の周辺装置管理プログラムは、情報処理装置と通信可能な周辺装置に搭載されるファームウェアについて、前記情報処理装置と通信可能なサーバから新しいファームウェアをダウンロード可能か否かを確認し、ダウンロード可能な場合に、その旨を利用者に通知する処理を、前記情報処理装置に実行させるための周辺装置管理プログラムであって、前記情報処理装置を、前記ファームウェアのダウンロードが可能か否かの確認をする確認タイミングに至ったか否かを判定する確認タイミング判定手段と、前記確認タイミング判定手段によって前記確認タイミングに至ったと判定された場合に、前記周辺装置に搭載済みのファームウェアに関するファームウェア情報を、前記周辺装置から取得するファームウェア情報取得手段と、前記ファームウェア情報取得手段によって前記ファームウェア情報を前記周辺装置から正常に取得できた場合に、前記ファームウェア情報に基づいて特定されるファームウェアよりも新しいファームウェアを、前記サーバからダウンロード可能か否かを確認する確認手段と、前記確認手段によって、新しいファームウェアを前記サーバからダウンロード可能であると確認できた場合に、ダウンロード可能なファームウェアが存在する旨を利用者に通知する通知手段と、過去に一回の処理によって、正常に取得できた前記ファームウェア情報の数の内、最も頻度の高かった数をしきい値として、前記ファームウェア情報取得手段による前記ファームウェア情報の取得状況が、前記しきい値以上の周辺装置から前記ファームウェア情報を取得できた状況であった場合には、あらかじめ定められた第１期間の経過後を、前記確認タイミングとして設定する一方、前記しきい値以上の周辺装置から前記ファームウェア情報を取得できる状況ではなかった場合には、前記第１期間よりも短期間となるあらかじめ定められた第２期間の経過後を、前記確認タイミングとして設定する確認タイミング設定手段として機能させるためのプログラムである。

このように構成された周辺装置管理プログラムにより、情報処理装置を上記各手段として機能させれば、情報処理装置は、確認タイミングに至ったら、周辺装置に搭載されるファームウェアについて、サーバから新しいファームウェアをダウンロード可能か否かを確認する。そして、ダウンロード可能な場合には、その旨を利用者に通知するので、利用者はファームウェアのダウンロードが可能であることを察知できる。

しかも、ファームウェア情報取得手段によるファームウェア情報の取得状況が、上記のようなしきい値以上の周辺装置からファームウェア情報を取得できた状況であった場合には、第１期間の経過後、次回の確認タイミングとして設定する。一方、上記しきい値以上の周辺装置からファームウェア情報を取得できる状況ではなかった場合には、前記第１期間よりも短期間となる第２期間の経過後を、次回の確認タイミングとして設定する。
つまり、情報処理装置は、正常に取得できる可能性が高いファームフェア情報の数をしきい値として、しきい値以上の周辺装置からファームウェア情報を取得できる状況になかった場合には、次の確認タイミングを早めることができる。

したがって、単に第１期間相当の期間が経過するたびに確認を行うものとは異なり、上記しきい値以上の周辺装置からファームウェア情報を取得できる状況ではなかった場合には、より短期間で次の確認時期になるので、次の確認時期が過剰に遅い時期になってしまうことがなく、短期間で利用者への通知を行うことができる。
特に、正常にファームウェア情報を取得できる可能性が高い周辺装置について、たまたまファームウェア情報の取得に失敗していたとしても、次の取得機会をより早期に到来させることができ、これにより、ダウンロード可能なファームウェアが存在するか否かの確認を、より早期に再試行できる。

また、単に第２期間相当の期間が経過するたびに確認を行うものとも異なり、上記のようなしきい値以上の周辺装置からファームウェア情報を取得できた状況であったにもかかわらず、次の確認時期が過剰に早い時期になってしまうことはなく、サーバやネットワークに過大な負荷をかけることがない。

請求項２に記載の周辺装置管理プログラムは、情報処理装置と通信可能な複数の周辺装置に搭載されるファームウェアについて、前記情報処理装置と通信可能なサーバから新しいファームウェアをダウンロード可能か否かを確認し、ダウンロード可能な場合に、その旨を利用者に通知する処理を、前記情報処理装置に実行させるための周辺装置管理プログラムであって、前記情報処理装置を、前記ファームウェアのダウンロードが可能か否かの確認をする確認タイミングに至ったか否かを、複数の前記周辺装置それぞれについて判定する確認タイミング判定手段と、前記確認タイミング判定手段によって前記確認タイミングに至ったと判定された場合に、前記確認タイミングに至ったと判定された周辺装置のみを対象に、前記周辺装置に搭載済みのファームウェアに関するファームウェア情報を、前記周辺装置から取得するファームウェア情報取得手段と、前記ファームウェア情報取得手段によって前記ファームウェア情報を前記周辺装置から正常に取得できた場合に、前記ファームウェア情報に基づいて特定されるファームウェアよりも新しいファームウェアを、前記サーバからダウンロード可能か否かを確認する確認手段と、前記確認手段によって、新しいファームウェアを前記サーバからダウンロード可能であると確認できた場合に、ダウンロード可能なファームウェアが存在する旨を利用者に通知する通知手段と、前記ファームウェア情報取得手段による前記ファームウェア情報の取得状況が、あらかじめ取り決められた条件を満足する取得状況であった場合には、複数の前記周辺装置の全てについて、あらかじめ定められた第１期間の経過後を、前記確認タイミングとして設定する一方、あらかじめ取り決められた条件を満足する取得状況ではなかった場合には、複数の前記周辺装置のそれぞれについて、前記第１期間よりも短期間となるあらかじめ定められた第２期間の経過後を、前記確認タイミングとして設定する確認タイミング設定手段として機能させるための周辺装置管理プログラムである。

このように構成された周辺装置管理プログラムにより、情報処理装置を上記各手段として機能させれば、情報処理装置は、確認タイミングに至ったら、周辺装置に搭載されるファームウェアについて、サーバから新しいファームウェアをダウンロード可能か否かを確認する。そして、ダウンロード可能な場合には、その旨を利用者に通知するので、利用者はファームウェアのダウンロードが可能であることを察知できる。

しかも、ファームウェア情報取得手段によるファームウェア情報の取得状況が、あらかじめ取り決められた条件を満足する取得状況であった場合には、第１期間の経過後、次回の確認タイミングとして設定する。

一方、あらかじめ取り決められた条件を満足する取得状況ではなかった場合には、前記第１期間よりも短期間となる第２期間の経過後を、次回の確認タイミングとして設定する。

したがって、単に第１期間相当の期間が経過するたびに確認を行うものとは異なり、あらかじめ取り決められた条件を満足する取得状況ではなかった場合には、より短期間で次の確認時期になるので、次の確認時期が過剰に遅い時期になってしまうことがなく、短期間で利用者への通知を行うことができる。

また、単に第２期間相当の期間が経過するたびに確認を行うものとも異なり、あらかじめ取り決められた条件を満足する取得状況であったにもかかわらず、次の確認時期が過剰に早い時期になってしまうことはなく、サーバやネットワークに過大な負荷をかけることがない。

さらに、請求項２に記載の周辺装置管理プログラムの場合、情報処理装置は、あらかじめ取り決められた条件を満足する取得状況であった場合、複数の周辺装置の全てについて、第１期間の経過後を確認タイミングとして設定する。

したがって、その後、確認タイミングに至ったと判定された周辺装置のみを対象にファームウェア情報を取得する際には、複数の周辺装置の全てから情報取得を試行することができる。

その一方、情報処理装置は、あらかじめ取り決められた条件を満足する取得状況ではなかった場合であっても、複数の周辺装置のそれぞれについて確認タイミングが設定される。そして、その後は、確認タイミングに至ったと判定された周辺装置のみを対象にファームウェア情報を取得する。したがって、常にすべての周辺装置からの情報取得を試行するものに比べ、効率的に情報取得を行うことができ、情報処理装置にかかる負荷を軽減できる。

請求項３に記載の周辺装置管理プログラムは、請求項２に記載の周辺装置管理プログラムにおいて、前記確認タイミング設定手段は、前記ファームウェア情報取得手段による前記ファームウェア情報の取得状況が、所定数以上の周辺装置から前記ファームウェア情報を取得できた状況であった場合には、前記第１期間の経過後を前記確認タイミングとして設定する一方、所定数以上の周辺装置から前記ファームウェア情報を取得できる状況ではなかった場合には、前記第２期間の経過後を前記確認タイミングとして設定する手段とされていることを特徴とする。

このように構成された周辺装置管理プログラムにより、情報処理装置を上記各手段として機能させれば、情報処理装置は、所定数以上の周辺装置からファームウェア情報を取得できる状況になかった場合には、次の確認タイミングを早めることができる。したがって、多くの周辺機器からファームウェア情報を取得できなかった場合には、ダウンロード可能なファームウェアが存在するか否かの確認を、より早期に再試行できる。

請求項４に記載の周辺装置管理プログラムは、請求項３に記載の周辺装置管理プログラムにおいて、前記確認タイミング設定手段は、過去に一回の処理によって、正常に取得できた前記ファームウェア情報の数の内、最も頻度の高かった数をしきい値として、前記ファームウェア情報取得手段による前記ファームウェア情報の取得状況が、前記しきい値以上の周辺装置から前記ファームウェア情報を取得できた状況であった場合には、前記第１期間の経過後を前記確認タイミングとして設定する一方、前記しきい値以上の周辺装置から前記ファームウェア情報を取得できる状況ではなかった場合には、前記第２期間の経過後を前記確認タイミングとして設定する手段とされていることを特徴とする。

このように構成された周辺装置管理プログラムにより、情報処理装置を上記各手段として機能させれば、情報処理装置は、正常に取得できる可能性が高いファームフェア情報の数をしきい値として、しきい値以上の周辺装置からファームウェア情報を取得できる状況になかった場合には、次の確認タイミングを早めることができる。

したがって、正常にファームウェア情報を取得できる可能性が高い周辺装置について、たまたまファームウェア情報の取得に失敗していたとしても、次の取得機会をより早期に到来させることができ、これにより、ダウンロード可能なファームウェアが存在するか否かの確認を、より早期に再試行できる。
請求項５に記載の周辺装置管理プログラムは、請求項１〜請求項４のいずれか一項に記載の周辺装置管理プログラムにおいて、前記情報処理装置を、さらに、複数の周辺装置の中から選ばれる１以上の周辺装置を監視対象周辺装置として、前記監視対象周辺装置の接続状態がオンラインになったことを検出する検出手段として機能させ、前記確認タイミング判定手段は、前記監視対象周辺装置の接続状態がオンラインになったことを前記検出手段が検出した際に、当該オンラインになった監視対象周辺装置に対して前記確認タイミングに至ったと判定する手段とされていることを特徴とする。
このように構成された周辺装置管理プログラムにより、情報処理装置を上記各手段として機能させれば、情報処理装置は、監視対象周辺装置の接続状態がオンラインになった場合に、サーバから新しいファームウェアをダウンロード可能か否かを確認する。そして、ダウンロード可能な場合に、その旨を利用者に通知する。
したがって、監視対象周辺装置の接続状態がオフラインになっていたことに起因して、ファームウェアをダウンロード可能か否かの確認ができていなかった場合にも、監視対象周辺装置の接続状態がオンラインになったことを契機として、迅速に確認をとることができる。

請求項６に記載の周辺装置管理プログラムは、請求項１〜請求項５のいずれか一項に記載の周辺装置管理プログラムにおいて、前記確認タイミング設定手段は、前記ファームウェア情報取得手段による前記ファームウェア情報の取得状況が、あらかじめ取り決められた特定の周辺装置から前記ファームウェア情報を取得できた状況であった場合には、前記第１期間の経過後を前記確認タイミングとして設定する一方、あらかじめ取り決められた特定の周辺装置から前記ファームウェア情報を取得できる状況ではなかった場合には、前記第２期間の経過後を前記確認タイミングとして設定する手段とされていることを特徴とする。

このように構成された周辺装置管理プログラムにより、情報処理装置を上記各手段として機能させれば、情報処理装置は、あらかじめ取り決められた特定の周辺装置からファームウェア情報を取得できる状況になかった場合には、次の確認タイミングを早めることができる。

したがって、例えば、利用者にとって特に重要な周辺装置を上記特定の周辺装置として取り決めておくことにより、その特定の周辺装置について、ダウンロード可能なファームウェアが存在するか否かの確認を、より早期に再試行できる。

請求項７に記載の周辺装置管理プログラムは、請求項１〜請求項６のいずれか一項に記載の周辺装置管理プログラムにおいて、前記確認タイミング設定手段は、前記ファームウェア情報取得手段による前記ファームウェア情報の取得状況が、あらかじめ取り決められた条件を満足する取得状況ではなかった場合に、前記ファームウェア情報を取得できる頻度があらかじめ定められた基準値より高い周辺装置については、前記第２期間の経過後を前記確認タイミングとして設定する一方、前記ファームウェア情報を取得できる頻度が前記基準値より低い周辺装置については、前記第１期間よりも長期間となるあらかじめ定められた第３期間の経過後を、前記確認タイミングとして設定する手段とされていることを特徴とする。

このように構成された周辺装置管理プログラムにより、情報処理装置を上記各手段として機能させれば、情報処理装置は、あらかじめ取り決められた特定の周辺装置からファームウェア情報を取得できる状況になかった場合に、ファームウェア情報を取得できる頻度が高い周辺装置については、次の確認タイミングを早めることができる。

逆に、ファームウェア情報を取得できる頻度が低い周辺装置については、次の確認タイミングを遅くすることができる。したがって、あまり使用しない周辺装置についての過剰な確認を抑制でき、情報処理装置にかかる負荷を軽減できる。

さらに、請求項８に記載の周辺装置管理システムは、情報処理装置と、前記情報処理装置と通信可能な周辺装置と、前記情報処理装置と通信可能なサーバとを備え、前記情報処理装置が、前記周辺装置に搭載されるファームウェアについて、前記サーバから新しいファームウェアをダウンロード可能か否かを確認し、ダウンロード可能な場合に、その旨を利用者に通知する処理を実行するように構成された周辺装置管理システムであって、前記情報処理装置が、前記ファームウェアのダウンロードが可能か否かの確認をする確認タイミングに至ったか否かを判定する確認タイミング判定手段と、前記確認タイミング判定手段によって前記確認タイミングに至ったと判定された場合に、前記周辺装置に搭載済みのファームウェアに関するファームウェア情報を、前記周辺装置から取得するファームウェア情報取得手段と、前記ファームウェア情報取得手段によって前記ファームウェア情報を前記周辺装置から正常に取得できた場合に、前記ファームウェア情報に基づいて特定されるファームウェアよりも新しいファームウェアを、前記サーバからダウンロード可能か否かを確認する確認手段と、前記確認手段によって、新しいファームウェアを前記サーバからダウンロード可能であると確認できた場合に、ダウンロード可能なファームウェアが存在する旨を利用者に通知する通知手段と、過去に一回の処理によって、正常に取得できた前記ファームウェア情報の数の内、最も頻度の高かった数をしきい値として、前記ファームウェア情報取得手段による前記ファームウェア情報の取得状況が、前記しきい値以上の周辺装置から前記ファームウェア情報を取得できた状況であった場合には、あらかじめ定められた第１期間の経過後を、前記確認タイミングとして設定する一方、前記しきい値以上の周辺装置から前記ファームウェア情報を取得できる状況ではなかった場合には、前記第１期間よりも短期間となるあらかじめ定められた第２期間の経過後を、前記確認タイミングとして設定する確認タイミング設定手段とを備えることを特徴とする。

このように構成された周辺装置管理システムによれば、情報処理装置は、請求項１に記載の周辺装置管理プログラムについて述べたとおりの作用、効果を奏するものとなる。したがって、利用者はファームウェアのダウンロードが可能であることを察知できる。

しかも、単に第１期間相当の期間が経過するたびに確認を行うものとは異なり、上記しきい値以上の周辺装置からファームウェア情報を取得できる状況ではなかった場合には、より短期間で次の確認時期になるので、次の確認時期が過剰に遅い時期になってしまうことがなく、短期間で利用者への通知を行うことができる。

また、単に第２期間相当の期間が経過するたびに確認を行うものとも異なり、上記のようなしきい値以上の周辺装置からファームウェア情報を取得できた状況であったにもかかわらず、次の確認時期が過剰に早い時期になってしまうことはなく、サーバやネットワークに過大な負荷をかけることがない。
また、請求項９に記載の周辺装置管理システムは、情報処理装置と、前記情報処理装置と通信可能な複数の周辺装置と、前記情報処理装置と通信可能なサーバとを備え、前記情報処理装置が、前記周辺装置に搭載されるファームウェアについて、前記サーバから新しいファームウェアをダウンロード可能か否かを確認し、ダウンロード可能な場合に、その旨を利用者に通知する処理を実行するように構成された周辺装置管理システムであって、前記情報処理装置が、前記ファームウェアのダウンロードが可能か否かの確認をする確認タイミングに至ったか否かを、複数の前記周辺装置それぞれについて判定する確認タイミング判定手段と、前記確認タイミング判定手段によって前記確認タイミングに至ったと判定された場合に、前記確認タイミングに至ったと判定された周辺装置のみを対象に、前記周辺装置に搭載済みのファームウェアに関するファームウェア情報を、前記周辺装置から取得するファームウェア情報取得手段と、前記ファームウェア情報取得手段によって前記ファームウェア情報を前記周辺装置から正常に取得できた場合に、前記ファームウェア情報に基づいて特定されるファームウェアよりも新しいファームウェアを、前記サーバからダウンロード可能か否かを確認する確認手段と、前記確認手段によって、新しいファームウェアを前記サーバからダウンロード可能であると確認できた場合に、ダウンロード可能なファームウェアが存在する旨を利用者に通知する通知手段と、前記ファームウェア情報取得手段による前記ファームウェア情報の取得状況が、あらかじめ取り決められた条件を満足する取得状況であった場合には、複数の前記周辺装置の全てについて、あらかじめ定められた第１期間の経過後を、前記確認タイミングとして設定する一方、あらかじめ取り決められた条件を満足する取得状況ではなかった場合には、複数の前記周辺装置のそれぞれについて、前記第１期間よりも短期間となるあらかじめ定められた第２期間の経過後を、前記確認タイミングとして設定する確認タイミング設定手段とを備えることを特徴とする。
このように構成された周辺装置管理システムによれば、情報処理装置は、請求項２に記載の周辺装置管理プログラムについて述べたとおりの作用、効果を奏するものとなる。したがって、利用者はファームウェアのダウンロードが可能であることを察知できる。
さらに、この周辺装置管理システムの場合、情報処理装置は、あらかじめ取り決められた条件を満足する取得状況であった場合、複数の周辺装置の全てについて、第１期間の経過後を確認タイミングとして設定する。したがって、その後、確認タイミングに至ったと判定された周辺装置のみを対象にファームウェア情報を取得する際には、複数の周辺装置の全てから情報取得を試行することができる。
その一方、情報処理装置は、あらかじめ取り決められた条件を満足する取得状況ではなかった場合であっても、複数の周辺装置のそれぞれについて確認タイミングが設定される。そして、その後は、確認タイミングに至ったと判定された周辺装置のみを対象にファームウェア情報を取得する。したがって、常にすべての周辺装置からの情報取得を試行するものに比べ、効率的に情報取得を行うことができ、情報処理装置にかかる負荷を軽減できる。

次に、本発明の実施形態について一例を挙げて説明する。
［システム全体の構成］
図１は、周辺装置管理システム全体の構成を示した概略構成図である。本実施形態において、周辺装置管理システムは、パーソナルコンピュータ１（本発明でいう情報処理装置に相当；以下、ＰＣ１という）、プリンタ２Ａ〜２Ｅ（本発明でいう周辺装置に相当）、およびサーバ３などによって構成される。

ＰＣ１とプリンタ２Ａ〜２Ｅは、ＬＡＮ（Local Area Network）５を介して互いに通信可能となっている。また、ＬＡＮ５は、ルータ６を介してＷＡＮ（Wide Area Network；例えば、インターネット）７に接続され、ＰＣ１は、ＷＡＮ７を介してサーバ３とも通信可能となっている。

これらの内、ＰＣ１は、制御部１１、記憶部１２、入力部１３、表示部１４、ネットワークインターフェイス１５などを備えている。
制御部１１は、ＣＰＵ，ＲＯＭ，ＲＡＭ等のハードウェアと、ＯＳ（Operating System）やアプリケーション等のソフトウェアによって構成される。この制御部１１において、周辺装置管理システムに関連するソフトウェアとしては、ステータスモニタ１１Ａ、パーサ１１Ｂなどが機能している。

ステータスモニタ１１Ａは、プリンタ２Ａ〜２Ｅに関連する各種情報を、表示部１４に出力することで利用者に通知する処理、あるいは、利用者から情報の入力を受け付ける処理などを実行する。

パーサ１１Ｂは、プリンタジョブ言語（ＰＪＬ；Printer Job Language）に準拠した形式で記述されたコマンドをプリンタ２Ａ〜２Ｅに出力し、そのコマンドを受け取ったプリンタ２Ａ〜２Ｅから出力される各種情報を取得する処理を実行する。そして、取得した情報の構文解析を行って、その情報をステータスモニタ１１Ａが参照可能なデータ形式に変換し、ステータスモニタ１１Ａへと出力する処理を実行する。

記憶部１２は、制御部１１が備えるＲＡＭとは別に設けられた、より大容量のハードディスク装置や不揮発性メモリによって構成されるもので、比較的大きいサイズのデータや、電力供給が遮断されたときにも消失させたくないデータを記憶する際に利用される。本実施形態において、この記憶部１２には、プリンタ２Ａ〜２Ｅのファームウェアの更新に関する履歴情報１２Ａが記憶される。

また、プリンタ２Ａは、制御部２１、記憶部２２、操作部２３、表示部２４、ネットワークインターフェイス２５、印刷部２６などを備えている。
記憶部２２は、不揮発性メモリによって構成されるもので、プリンタ２Ａが備えるハードウェアを制御するためのファームウェア２２Ａ、およびそのファームウェアに関連する情報（ファームウェアのバージョン情報等；以下、ファーム情報ともいう。）などが、記憶部２２に記憶されている。

なお、図１においては、プリンタ２Ａについてのみ内部構成を図示してあるが、他のプリンタ２Ｂ〜２Ｅの内部構成も、プリンタ２Ａと同様になっている。
さらに、サーバ３は、制御部３１、記憶部３２、ネットワークインターフェイス３３などを備えている。

記憶部３２は、大容量のハードディスク装置によって構成されるもので、サーバ３が配信可能なプリンタ用ファームウェアに関するファームウェア管理情報３２Ａなどが、記憶部３２に記憶されている。ファームウェア管理情報３２Ａには、ファームウェアの最新のバージョン情報などが含まれている。

なお、サーバ３は、クライアントからの要求に応じてプリンタ用ファームウェアを配信する機能を備えており、記憶部３２には、配信対象となるプリンタ用ファームウェア（図示略）も記憶されている。ただし、本実施形態で説明する周辺装置管理システムは、サーバ３が配信可能なファームウェアに関する情報をＰＣ１に伝達するシステムであって、プリンタ用ファームウェアそのものを配信するシステムとは別のシステムとして構成されている。

図２は、上記周辺装置管理システム内でやり取りされるデータの伝送経路を示したブロック図である。
上記周辺装置管理システムにおいて、ステータスモニタ１１Ａは、パーサ１１Ｂに対してファーム情報の提供を命令する。この命令は、プリンタ２Ａ〜２Ｅがオンラインになっていれば、パーサ１１Ｂからプリンタ２Ａ〜２Ｅへと伝達され、この命令を受けたプリンタからパーサ１１Ｂに対しては、ファーム情報が提供される。そして、このファーム情報と取得結果（取得に成功した旨の情報）がステータスモニタ１１Ａへと伝達される。

また、プリンタ２Ａ〜２Ｅがオンラインになっていなければ（例えば、オフライン、あるいは電源オフなどになっていれば）、パーサ１１Ｂからプリンタ２Ａ〜２Ｅへ命令を伝達することはできないので、ファーム情報は取得できず、取得結果（取得に失敗した旨の情報）だけがステータスモニタ１１Ａへと伝達される。

こうしてファーム情報等を取得したステータスモニタ１１Ａは、サーバに送信する情報をまとめて、取得したファーム情報をサーバ３へ送信する。サーバ３では、ステータスモニタ１１Ａから伝達される情報に基づいて、到来したファーム情報よりも新しいファームウェアの提供が可能か否かを確認し、その確認結果をステータスモニタ１１Ａへと返信する。

ステータスモニタ１１Ａは、サーバ３から送信されてくる確認結果を受信し、ファームウェアのアップデートが可能である旨の確認結果を受信した場合には、その旨を表示部１４に表示することで、利用者に対する通知を行う。

したがって、この通知を見た利用者は、プリンタ２Ａ〜２Ｅいずれかのファームウェアをアップデートできることがわかるので、後は、利用者の判断で、ファームウェアのダウンロードやアップデート作業を実施できる。

すなわち、上記周辺装置管理システムでは、ファームウェアのアップデートが可能である旨の情報を利用者に通知する処理を実施するが、実際にファームウェアのダウンロードやアップデート作業を実施するか否かは、利用者の判断に任される。

［ステータスモニタおよびパーサが実行する処理の詳細］
次に、上述したような周辺装置管理システムを実現するため、ＰＣ１においてステータスモニタ１１Ａおよびパーサ１１Ｂが実行する処理の詳細について、図３〜図６のフローチャートに基づいて説明する。

以下に説明する処理は、ＰＣ１においてステータスモニタ１１Ａが起動された際に実行される処理となる。ステータスモニタ１１Ａを起動する契機は任意であるが、例えば、ＰＣ１において、プリンタ２Ａ〜２Ｅに対する印刷出力が行われる際には、プリンタドライバ（図示略）が印刷関連の処理を実行する中で、プリンタドライバとは別のプロセスとしてステータスモニタ１１Ａを起動する。また、ＰＣ１の起動時にステータスモニタ１１Ａが起動される構成となっていてもよいし、利用者がマニュアル操作でステータスモニタ１１Ａを起動できるように構成されていてもよい。

ステータスモニタ１１Ａが起動されたことにより、ＰＣ１が図３に示す処理を開始すると、ステータスモニタ１１Ａ（厳密には、ステータスモニタ１１Ａとして機能するＰＣ１；以下、単にステータスモニタ１１Ａという。）は、まず、プリンタ２Ａ〜２Ｅのファームウェアに関する更新確認を行う（Ｓ１０５）。このＳ１０５の処理は、詳しくは図４に示すような処理となる。

図４に示す更新確認処理を開始すると、ステータスモニタ１１Ａは、まず、前回確認年月日を取得する（Ｓ２０５）。本実施形態において、記憶部１２に記憶された履歴情報１２Ａには、図７（ａ）〜同図（ｅ）に例示するように、プリンタ名、前回確認年月日、確認タイミング、以上３項目を１組とするデータ群が、プリンタ２Ａ〜２Ｅの数と同数組含まれている。また、図示しないが、履歴情報１２Ａには、ファーム情報を取得した日時と、ファーム情報の取得に成功したか否かを示す情報とが、プリンタごとに記憶されている。

このような履歴情報１２Ａにおいて、プリンタ名：Ａ〜Ｅとなっている各組は、それぞれプリンタ２Ａ〜２Ｅに対応する組であるが、「前回確認年月日」については各組とも共通の日付が格納されている。そのため、Ｓ２０５では、履歴情報１２Ａ中にあるいずれかの組から「前回確認年月日」を読み出す。

そして、前回確認年月日を取得したら、続いて、ステータスモニタ１１Ａは、確認タイミングを経過したプリンタがあるか否かを判断する（Ｓ２１０）。Ｓ２１０では、履歴情報１２Ａ中にある「確認タイミング」が、プリンタ２Ａ〜２Ｅに対応する各組について読み出され、「前回確認年月日」に「確認タイミング」を足し合わせた日付と、現在の日付とを対比することで、確認タイミングを経過したプリンタがあるか否かが判断される。また、このＳ２１０では、履歴を使用し、前回更新の確認に失敗したプリンタの内、失敗頻度が低いプリンタのみを処理対象となるプリンタとして選択するが、この点については、後から図７を参照して、具体的な事例を交えて詳述することにする。

さて、このＳ２１０において、確認タイミングを経過したプリンタが無ければ（Ｓ２１０：ＮＯ）、図４に示す更新確認処理を終了する。一方、Ｓ２１０において、確認タイミングを経過したプリンタがあれば（Ｓ２１０：ＹＥＳ）、Ｓ２１５へと進む。

Ｓ２１５へ進んだ場合、ステータスモニタ１１Ａは、対象プリンタ（＝確認タイミングを経過したプリンタ；以下同様）にファーム情報の提供を命令する（Ｓ２１５）。ここで、Ｓ２１５の処理を実行した場合、ステータスモニタ１１Ａが、別プロセスでパーサ１１Ｂを起動することにより、パーサ１１Ｂ（厳密には、パーサ１１Ｂとして機能するＰＣ１；以下、単にパーサ１１Ｂという。）は、図６に示すパーサ処理を開始する。

図６に示すパーサ処理を開始すると、パーサ１１Ｂは、まず、対象プリンタがオンラインか否かを判断する（Ｓ４１０）。ここで、対象プリンタがオンラインであれば（Ｓ４１０：ＹＥＳ）、パーサ１１Ｂは、ファーム情報の提供を対象プリンタに命令する（Ｓ４１５）。この命令は、ＰＣ１が備えるネットワークインターフェイス２５を経由して対象プリンタ（プリンタ２Ａ〜２Ｅのいずれか１つまたは２つ以上）へ伝達される。

そして、この命令を受けた対象プリンタからは、バージョン情報を含むファーム情報がＰＣ１に対して提供されるので、パーサ１１Ｂは、このファーム情報を取得する（Ｓ４１５）。一方、対象プリンタがオンラインでなければ（Ｓ４１０：ＮＯ）、Ｓ４１５をスキップしてＳ４２０に進む。

そして、ファーム情報を取得したパーサ１１Ｂからステータスモニタ１１Ａへ、プロセス間通信により、取得したファーム情報と、その取得の成否に関する情報とを送信して（Ｓ４２０）、図６に示すパーサ処理を終了する。

以上のようなパーサ処理が、ＰＣ１において実行された結果、ステータスモニタ１１Ａとして機能するプロセスには、対象プリンタからのファーム情報と取得の成否が伝送されてくるので、ステータスモニタ１１Ａ側では、それらを受信する（Ｓ２２０）。

そして、ステータスモニタ１１Ａは、受信した情報に基づいて、すべての対象プリンタの中から、ファーム情報取得に失敗したプリンタを抽出する（Ｓ２２５）。次に、対象プリンタのファーム情報の取得状況を示す情報を、履歴として履歴情報１２Ａに登録する（Ｓ２３０）。

次いで、ステータスモニタ１１Ａは、ファーム情報を正しく取得できたプリンタがあるか否かを判断する（Ｓ２３５）。このＳ２３５において、ファーム情報を正しく取得できたプリンタが無ければ（Ｓ２３５：ＮＯ）、Ｓ２６０へと進む。Ｓ２６０については後述する。一方、Ｓ２３５において、ファーム情報を正しく取得できたプリンタがあれば（Ｓ２３５：ＹＥＳ）、Ｓ２４０へと進む。

Ｓ２４０へ進んだ場合、ステータスモニタ１１Ａは、ファーム情報を正しく取得できたプリンタについて、当該プリンタの情報をまとめてサーバに送信する（Ｓ２４０）。ここで、この情報を受信したサーバ３側では、記憶部３２に記憶しているファームウェア管理情報３２Ａを参照して、サーバ３からＰＣ１へ提供可能な最新のファームウェアが存在するか否かを確認し、その確認結果をＰＣ１に対して送信する処理が実行される。

このような処理がサーバ３側で実行された結果、ＰＣ１側へは上記確認結果が送信されてくるので、ステータスモニタ１１Ａは、サーバ３から確認結果を受信し（Ｓ２４５）、その確認結果に基づいて、一つでも更新できるプリンタがあるか否かを判断する（Ｓ２５０）。

Ｓ２５０において、一つでも更新できるプリンタがあると判断した場合（Ｓ２５０：ＹＥＳ）、ステータスモニタ１１Ａは、更新情報があることを利用者に通知して（Ｓ２５５）、Ｓ２６０へと進む。また、一つも更新できるプリンタが無いと判断した場合（Ｓ２５０：ＮＯ）、Ｓ２５５はスキップして、Ｓ２６０へと進む。こうしてＳ２６０へ進むと、ステータスモニタ１１Ａは、履歴情報の更新を行う（Ｓ２６０）。この履歴情報更新処理は、詳しくは図５に示すような処理となる。

図５に示す履歴情報更新処理を開始すると、ステータスモニタ１１Ａは、まず、所定の条件を満たす取得状況であったか否かを判断する（Ｓ３０５）。より具体的には、本実施形態において、Ｓ３０５では、「所定数以上のプリンタからファーム情報を正しく取得できること」が上記「所定の条件」となっている。

すなわち、Ｓ３０５では、所定数以上のプリンタからファーム情報を正しく取得できた場合に、所定の条件を満たす取得状況であったとの判断がなされる。また、所定数未満のプリンタからしかファーム情報を正しく取得できなかった場合、Ｓ３０５では、所定の条件を満たす取得状況ではなかったとの判断がなされる。

また、Ｓ３０５において、上記所定数は、過去の情報取得履歴に基づいて、情報取得に成功する頻度の最も高い台数が所定数として設定される。具体例を交えて説明すると、例えば、プリンタ２Ａ〜２Ｃは、通常はオンラインになっていることが多く、且つ、プリンタ２Ｄ，２Ｅは電源が切られていることが多い場合、通常は３台のプリンタから情報取得に成功する機会が多くなる。このような場合、その履歴に基づいて、上記所定数としては「３」が設定される。

このような判定条件に基づいて、Ｓ３０５において所定の条件を満たす取得状況であったと判断された場合（Ｓ３０５：ＹＥＳ）、ステータスモニタ１１Ａは、全てのプリンタの次回更新確認を行うタイミングを３０日に変更する（Ｓ３１０）。そして、前回確認年月日を登録して（Ｓ３１５）、図５に示す履歴情報更新処理を終了する。

一方、Ｓ３０５において所定の条件を満たす取得状況では無かったと判断された場合（Ｓ３０５：ＮＯ）、ステータスモニタ１１Ａは、全てのプリンタを対象にしてＳ３２０〜Ｓ３４０の処理を繰り返す。

具体的には、まず、全ての対象プリンタのタイミング変更が完了したか否かを判断し（Ｓ３２０）、変更が完了していない場合は（Ｓ３２０：ＮＯ）、その変更が完了していないプリンタについて、ファーム情報の取得に成功したプリンタか否かを判断する（Ｓ３２５）。

Ｓ３２５において、ファーム情報の取得に成功したプリンタであった場合は（Ｓ３２５：ＹＥＳ）、そのプリンタについて、次回更新確認を行うタイミングを３０日に変更し（Ｓ３３０）、Ｓ３２０へと戻る。

一方、Ｓ３２５において、ファーム情報の取得に成功したプリンタでは無かった場合は（Ｓ３２５：ＮＯ）、そのプリンタについて、ファーム情報の取得に失敗する頻度を履歴から算出する（Ｓ３３５）。そして、失敗する頻度に応じて次回更新確認を行うタイミングを変更し（Ｓ３４０）、Ｓ３２０へと戻る。

これらＳ３３５〜Ｓ３４０について、具体例を交えて説明すると、例えば、あるプリンタ２Ｃについて、ファーム情報の取得に成功した回数が９回、失敗した回数が１回、といった履歴が残っている場合、失敗率は１０％程度であり、ファーム情報の取得に成功する確率が相応に高い。

そこで、このような場合は、時間をおいてファーム情報の取得を再試行すれば、成功する可能性が高いものと期待できるので、この場合、Ｓ３４０では、次回更新確認を行うタイミングを２日後に変更する。

一方、例えば、あるプリンタ２Ｅについて、ファーム情報の取得に成功した回数が１回、失敗した回数が９回、といった履歴が残っている場合、失敗率は９０％程度であり、ファーム情報の取得に失敗する確率が相応に高い。

そこで、このような場合は、時間をおいてファーム情報の取得を再試行しても、失敗する可能性が高いものと予想されるので、この場合、Ｓ３４０では、次回更新確認を行うタイミングを６０日後に変更する。

このような手法で次回更新確認を行うタイミングを変更すると、ファーム情報の取得に成功する可能性が高いプリンタについては、たまたまファーム情報の取得に失敗することがあったとしても、比較的迅速に次回の更新確認タイミングが到来することになる。また、ファーム情報の取得に失敗する可能性が高いプリンタについては、ファーム情報の取得に失敗する機会をいたずらに増やさないことで、ＰＣ１に余計な負荷がかからないようにすることができる。

以上説明したようなＳ３２０〜Ｓ３４０の処理を、全てのプリンタを対象にして繰り返した結果、全ての対象プリンタのタイミング変更が完了した場合は（Ｓ３２０：ＹＥＳ）、既に説明したＳ３１５へと進んで前回確認年月日を登録して（Ｓ３１５）、図５に示す履歴情報更新処理を終了する。

そして、図５に示す履歴情報更新処理を終了した場合、図４に示したＳ２６０を終えたことになるので、この場合は、図４に示す更新確認処理を終了する。また、図４に示す更新確認処理を終了したことにより、図３に示したＳ１０５を終えたことになるので、引き続いてＳ１１０へと進む。

Ｓ１１０では、ステータスモニタ１１Ａは、監視対象プリンタのステータスに変化があるまで待機して（Ｓ１１０）、変化があった場合、監視対象プリンタがオンラインになったか否かを判断する（Ｓ１１５）。

ここで、監視対象プリンタとは、ステータスモニタ１１Ａによって、プリンタのステータス変化を監視されるプリンタのことである。例えば、ネットワーク上の全てのプリンタが、監視対象プリンタとして設定されていてもよいし、ユーザによって予め指定されているプリンタが設定されていてもよい。また、Ｓ２２５で抽出されたファーム情報の取得に失敗したプリンタが設定されていてもよい。

Ｓ１１５において、監視対象プリンタがオンラインになっていなければ（Ｓ１１５：ＮＯ）、Ｓ１１０へと戻ることにより、再び待機状態になる。一方、監視対象プリンタがオンラインになっていれば（Ｓ１１５：ＹＥＳ）、ステータスモニタ１１Ａは、オンラインになったプリンタが前回の更新確認に成功しているか否かを判断する（Ｓ１２０）。

Ｓ１２０では、履歴情報１２Ａを参照して、オンラインになったプリンタが前回の更新確認に成功していれば（Ｓ１２０：ＹＥＳ）、Ｓ１１０へと戻ることにより、再び待機状態になる。一方、オンラインになったプリンタが前回の更新確認に失敗していれば（Ｓ１２０：ＮＯ）、Ｓ１０５へと戻ることにより、更新確認を行う（Ｓ１０５）。なお、Ｓ１０５において実行される処理の詳細については既に説明したので、ここでの説明は省略する。

［更新確認タイミングに関する具体的な事例］
さて次に、上記のような処理を実行することにより、プリンタ２Ａ〜２Ｅに対応する確認タイミングがどのように変更されてゆくのかを、図７（ａ）〜同図（ｅ）に例示した具体的事例を参照しながら説明する。

まず初期状態として、図７（ａ）に示すように、プリンタ２Ａ〜２Ｅすべてに対応する前回確認年月日が“２００８／７／３０”で、確認タイミングとして“３０日後”が設定されている場合（図７（ａ）参照）、現在の日付が“２００８／９／２”になると、上記Ｓ２１０で肯定判断がなされる。

この場合に、プリンタ２Ａのファーム情報を取得できたものの、プリンタ２Ｂ〜２Ｃについてファーム情報の取得に失敗したケースを想定すると、この場合、Ｓ３０５では否定判断がなされる。

より詳しくは、本実施形態において、Ｓ３０５では、３台以上のプリンタからファーム情報が取得できた場合に、所定の条件を満たすとの判断がなされる。そのため、１台のプリンタ２Ａからファーム情報を取得できても、その場合、プリンタの台数は３台未満なので、Ｓ３０５では否定判断がなされることになる。

その結果、Ｓ３０５からＳ３２０側へと進むことになり、プリンタ２Ａについては、Ｓ３３０で確認タイミングが“３０日後”に変更される。また、プリンタ２Ｂ，２Ｄ，２Ｅは、この時点ではファーム情報の取得に成功する頻度が高いプリンタとなっている事例を想定している。そのため、これらプリンタ２Ｂ，２Ｄ，２Ｅは、Ｓ３４０で確認タイミングが“２日後”に変更される。

一方、プリンタ２Ｃは、この時点ではファーム情報の取得に成功する頻度が低いプリンタとなっている事例を想定している。そのため、プリンタ２Ｃについては、Ｓ３４０で確認タイミングが“６０日後”に変更される。

これらの結果、各プリンタ２Ａ〜２Ｅに対応する確認タイミングは、図７（ｂ）に示すような日数に変更される。なお、前回確認年月日については、ファーム情報の取得に成功したか否かを問わず、プリンタ２Ａ〜２Ｅのすべてが共通の日付で更新される。

次に、現在の日付が“２００８／９／４”になると、プリンタ２Ｂ，２Ｄ，２Ｅについて、上記Ｓ２１０で肯定判断がなされる。
この場合に、プリンタ２Ｂのファーム情報を取得できたものの、プリンタ２Ｄ，２Ｅについてファーム情報の取得に失敗したケースを想定すると、この場合、Ｓ３０５では否定判断がなされる。より詳しくは、上述の通り、本実施形態において、Ｓ３０５では、３台以上のプリンタからファーム情報が取得できた場合に、所定の条件を満たすとの判断がなされる。

この判断において、ファーム情報が取得できたプリンタの台数は、過去にファーム情報の取得に成功したプリンタの台数も含む累積値によって判定が行われる。具体的には、上述の事例の場合、過去に１台のプリンタ２Ａからファーム情報を取得できており、今回はプリンタ２Ｂからファーム情報を取得できたので、ファーム情報の取得に成功したプリンタの台数は２台とされる。

ただし、上述の通り、Ｓ３０５では、３台以上のプリンタからファーム情報が取得できた場合に、所定の条件を満たすとの判断がなされるので、２台のプリンタ２Ａ，２Ｂからファーム情報を取得できても、その場合、プリンタの台数は３台未満なので、Ｓ３０５では否定判断がなされることになる。

その結果、Ｓ３０５からＳ３２０側へと進むことになり、プリンタ２Ｂについては、Ｓ３３０で確認タイミングが“３０日後”に変更される。また、プリンタ２Ｄは、この時点でもファーム情報の取得に成功する頻度が高いプリンタとなっている事例を想定している。そのため、Ｓ３４０では確認タイミングが“２日後”に変更される。

一方、プリンタ２Ｅは、ファーム情報の取得失敗が続いていたことが原因で、この時点でファーム情報の取得に成功する頻度が低いプリンタとなった事例を想定している。そのため、Ｓ３４０では確認タイミングが“６０日後”に変更される。

これらの結果、各プリンタ２Ａ〜２Ｅに対応する確認タイミングは、図７（ｃ）に示すような日数に変更される。なお、既に説明した通り、前回確認年月日については、ファーム情報の取得に成功したか否かを問わず、プリンタ２Ａ〜２Ｅのすべてが共通の日付で更新される。

ちなみに、プリンタ２Ａ，２Ｃについては、確認タイミングが変更されないまま、前回確認年月日だけが更新されるので、次の確認タイミングが到来する時期は、当初設定より若干遅れることになるが、このような若干の遅れが生じること自体は特に問題ない。

次に、現在の日付が“２００８／９／７”になると、プリンタ２Ｄについて、上記Ｓ２１０で肯定判断がなされる。この場合も、プリンタ２Ｄについてファーム情報の取得に失敗するか成功するかによって、情報の更新内容が変わる。

具体的には、まず、プリンタ２Ｄについてファーム情報の取得に失敗した場合について説明すると、この場合、ファーム情報の取得に成功したプリンタの台数は、累積で２台のままなので、Ｓ３０５では、３台以上のプリンタからファーム情報が取得できていないと、否定判断がなされることになる。

そして、ここでプリンタ２Ｄについても、ファーム情報の取得失敗が続いていたことが原因で、この時点でファーム情報の取得に成功する頻度が低いプリンタとなった事例を想定すると、Ｓ３４０では確認タイミングが“６０日後”に変更される。つまり、ファーム情報の取得失敗が続くと、確認タイミングは、標準である“３０日後”よりも長期間となる“６０日後”に変更されることになる。

その結果、各プリンタ２Ａ〜２Ｅに対応する確認タイミングは、図７（ｄ）に示すような日数に変更される。なお、既に説明した通り、前回確認年月日については、ファーム情報の取得に成功したか否かを問わず、プリンタ２Ａ〜２Ｅのすべてが共通の日付で更新される。

ちなみに、プリンタ２Ａ，２Ｂ，２Ｃ，２Ｅについては、確認タイミングが変更されないまま、前回確認年月日だけが更新されるので、次の確認タイミングが到来する時期は、当初設定より若干遅れることになるが、このような若干の遅れが生じること自体は特に問題ない。

一方、確認タイミングが、図７（ｃ）に示すような日数に変更された後、プリンタ２Ｄについてファーム情報の取得に失敗した場合について説明すると、この場合、ファーム情報の取得に成功したプリンタの台数は、累積で３台となるので、Ｓ３０５では肯定判断がなされる。この場合、ファーム情報の取得に成功したプリンタの台数はリセットされるとともに、Ｓ３１０により、すべてのプリンタ２Ａ〜２Ｅに対応する確認タイミングは、“３０日後”に変更される。

すなわち、すべてのプリンタ２Ａ〜２Ｅに対応する確認タイミングは、図７（ｅ）に示すような日数に変更される。なお、既に説明した通り、前回確認年月日については、ファーム情報の取得に成功したか否かを問わず、プリンタ２Ａ〜２Ｅのすべてが共通の日付で更新される。

以上説明したように、ファーム情報の取得に成功している場合、通常は、標準である“３０日後”が確認タイミングとして設定される。また、ファーム情報の取得に失敗した場合、ファーム情報の取得に成功する頻度が高いプリンタであれば、確認タイミングは、標準である“３０日後”よりも短期間となる“２日後”に変更される。さらに、ファーム情報の取得に失敗した場合、ファーム情報の取得に成功する頻度が低いプリンタであれば、確認タイミングは、標準である“３０日後”よりも長期間となる“６０日後”に変更される。

このようにすることで、ファーム情報の取得に失敗した場合であっても、ファーム情報の取得に成功する頻度が高いプリンタであれば、なるべく早めにファーム情報の取得を再試行して、これにより、利用者に対する情報通知をなるべく早期に実現できるようにする。また、ファーム情報の取得に成功する頻度が低いプリンタであれば、いたずらにファーム情報の取得頻度を高めないようにして、ＰＣ１に余計な負荷がかからないようにすることができる。

さらに、３台以上のプリンタからファーム情報が取得できた結果、所定の条件を満たすとの判断がなされれば、すべてのプリンタ２Ａ〜２Ｅについて、確認タイミングを、標準である“３０日後”に揃える。こうすることで、ある程度まとまった台数のプリンタからファーム情報が取得できれば、上記のような“２日後”、“３０日後”、“６０日後”といったばらつきを一旦リセットすることができる。したがって、これにより、サーバ３への問い合わせタイミングを揃えて、サーバ３への問い合わせが発生する頻度を低下させることができるので、サーバ３にかかる負荷を軽減することができる。

［本実施形態の効果］
以上説明した周辺装置管理システムによれば、ＰＣ１は、確認タイミングに至ったら、プリンタ２Ａ〜２Ｅに搭載されるファームウェアについて、サーバ３から新しいファームウェアをダウンロード可能か否かを確認する。そして、ダウンロード可能な場合には、その旨を利用者に通知するので、利用者はファームウェアのダウンロードが可能であることを察知できる。

しかも、Ｓ３０５により、ファームウェア情報の取得状況が、あらかじめ取り決められた条件を満足する取得状況であった場合には、３０日後を次回の確認タイミングとして設定する一方、あらかじめ取り決められた条件を満足する取得状況ではなかった場合には、３０日後よりも短期間となる２日後を、次回の確認タイミングとして設定する。

したがって、単に３０日が経過するたびに確認を行うものとは異なり、あらかじめ取り決められた条件を満足する取得状況ではなかった場合には、より短期間で次の確認時期になるので、次の確認時期が過剰に遅い時期になってしまうことがなく、短期間で利用者への通知を行うことができる。

また、単に２日が経過するたびに確認を行うものとも異なり、あらかじめ取り決められた条件を満足する取得状況であったにもかかわらず、次の確認時期が過剰に早い時期になってしまうことはなく、サーバ３やネットワーク（ＬＡＮ５，ＷＡＮ７）に過大な負荷をかけることがない。

また、ＰＣ１は、Ｓ２４０により、プリンタ２Ａ〜２Ｅから取得したファームウェア情報をサーバ３へ送信することで、新しいファームウェアをＰＣ１へ送信可能か否かの判断をサーバ３側に任せ、Ｓ２４５により、その判断結果をサーバ３から取得し、Ｓ２５０において、新しいファームウェアをサーバ３からダウンロード可能か否かを確認している。

したがって、このような構成を採用すれば、サーバ３が提供可能なファームウェアの情報すべてをＰＣ１がサーバ３から取得した上で、その中に新しいファームウェアが含まれるかどうかを、ＰＣ１が自ら判断する必要はなく、ＰＣ１の負荷を軽減できる。

また、ＰＣ１は、Ｓ１１５，Ｓ１２０により、プリンタ２Ａ〜２Ｅの接続状態がオンラインになった場合に、サーバ３から新しいファームウェアをダウンロード可能か否かを確認する。そして、ダウンロード可能な場合に、Ｓ２５５により、その旨を利用者に通知する。

したがって、プリンタ２Ａ〜２Ｅの接続状態がオフラインになっていたことに起因して、ファームウェアをダウンロード可能か否かの確認ができていなかった場合にも、プリンタ２Ａ〜２Ｅの接続状態がオンラインになったことを契機として、迅速に確認をとることができる。

また、ＰＣ１は、Ｓ３０５において、あらかじめ取り決められた条件を満足する取得状況ではなかった場合であっても、Ｓ３２０〜Ｓ３４０により、プリンタ２Ａ〜２Ｅそれぞれについて確認タイミングが設定される。そして、その後は、Ｓ２１５〜Ｓ２２０において、確認タイミングに至ったと判定されたプリンタのみを対象にファームウェア情報を取得する。したがって、常にすべてのプリンタ２Ａ〜２Ｅからの情報取得を試行するものに比べ、効率的に情報取得を行うことができ、ＰＣ１にかかる負荷を軽減できる。

また、ＰＣ１は、Ｓ３０５において、所定数（上記実施形態では３台）以上のプリンタからファームウェア情報を取得できる状況になかった場合には、Ｓ３４０において、次の確認タイミングを早めることができる。したがって、多くのプリンタからファームウェア情報を取得できなかった場合には、ダウンロード可能なファームウェアが存在するか否かの確認を、より早期に再試行できる。

また、ＰＣ１は、正常に取得できる可能性が高いファームフェア情報の数（上記実施形態では３）をしきい値として、しきい値以上のプリンタからファームウェア情報を取得できる状況になかった場合には、次の確認タイミングを早めることができる。

したがって、正常にファームウェア情報を取得できる可能性が高いプリンタについて、たまたまファームウェア情報の取得に失敗していたとしても、次の取得機会をより早期に到来させることができ、これにより、ダウンロード可能なファームウェアが存在するか否かの確認を、より早期に再試行できる。

さらに、ＰＣ１は、あらかじめ取り決められた特定の周辺装置からファームウェア情報を取得できる状況になかった場合に、Ｓ３４０において、ファームウェア情報を取得できる頻度が高い周辺装置については、確認タイミングとして“２日後”を設定することで、次の確認タイミングを早めることができる。逆に、ファームウェア情報を取得できる頻度が低い周辺装置については、確認タイミングとして“６０日後”を設定することで、次の確認タイミングを遅くすることができる。したがって、あまり使用しない周辺装置についての過剰な確認を抑制でき、ＰＣ１にかかる負荷を軽減できる。

［変形例等］
以上、本発明の実施形態について説明したが、本発明は上記の具体的な一実施形態に限定されず、この他にも種々の形態で実施することができる。

例えば、上記実施形態において、Ｓ３４０では、上述の通り、情報取得に成功する頻度が高いものと低いものとの２通りに分類し、次回更新確認を行うタイミングについては、２日後、６０日後のいずれかを設定していたが、情報取得に成功する頻度については３通り以上に分類してもよく、その場合、それぞれ異なる日数を設定してもよい。また、２日後、６０日後といった日数についても、ＰＣ１やサーバ３にかかる負荷を考慮しながら、それぞれ所望の日数を設定できる。

また、上記実施形態においては、Ｓ３０５において、３台以上のプリンタからファーム情報を取得できた場合に、所定の条件を満たす取得状況であったと判断する事例を示したが、所定の条件については、上記実施形態で例示した具体的な一例に限らない。

例えば、所定の条件を「ＰＣ１において「通常使用するプリンタ（デフォルトプリンタ）」とする旨の設定がなされたプリンタから、ファーム情報を取得できたこと」としてもよい。このようにすれば、あらかじめ取り決められた特定のプリンタからファームウェア情報を取得できる状況になかった場合には、次の確認タイミングを早めることができる。

したがって、利用者にとって特に重要なデフォルトプリンタについて、ダウンロード可能なファームウェアが存在するか否かの確認を、より早期に再試行できる。
また、上記実施形態においては、Ｓ３０５において、所定数としては、過去の情報取得履歴に基づいて、情報取得に成功する頻度の最も高い台数が所定数として設定される旨を説明し、その台数が３台である例を示したが、過去の情報取得履歴とは無関係なしきい値を設定してもよい。

いくつかの具体例を挙げれば、例えば、システム内に存在する全プリンタの内、過半数のプリンタからファーム情報を取得できたら、所定の条件を満たす取得状況であったと判断するようにしてもよい。あるいは、過半数に限らず、全プリンタの何十％以上からファーム情報を取得できたら、所定の条件を満たす取得状況であったと判断するようにしてもよい。

あるいは、例えば、システム内に存在する全プリンタの内、異なる機種のプリンタがいくつかあれば、少なくとも１機種につき１台のプリンタからファーム情報を取得できたら、所定の条件を満たす取得状況であったと判断するようにしてもよい。

また、上記実施形態においては、周辺装置の一例としてプリンタを例示したが、プリンタ以外の周辺装置であっても、本発明の構成を採用することにより、周辺装置のファームウェアに関し、アップデートが可能か否かを利用者に通知することができる。

プリンタ以外の周辺装置の具体的な例としては、例えば、ファクシミリ、あるいはＭＦＰ（Multifunction Peripheral）などの印刷系デバイス、スキャナ、ネットワークカメラ、あるいは既に印刷系デバイスとしても例示したＭＦＰなどの画像入力系デバイス、上述したファクシミリやＭＦＰなどの画像通信系デバイス、ネットワークルータ、ネットワークポイントなどの通信経路系デバイス、ネットワークストレージなどのデータストレージ系デバイスなど、様々な周辺装置を挙げることができる。

さらに、上記実施形態では、周辺装置のファームウェアに関し、アップデートが可能か否かを利用者に通知する構成を例示したが、さらに利用者設定により、アップデートが可能な場合は、ファームウェアのダウンロードを実行する構成や、ダウンロードしたファームウェアを周辺装置に適用する構成などを併せて採用してもよい。

周辺装置管理システム全体の概略構成を示すブロック図。 周辺装置管理システムにおける情報伝達手順を示すタイミングチャート。 ステータスモニタが実行する処理のフローチャート。 更新確認処理のフローチャート。 履歴情報更新処理のフローチャート。 パーサが実行する処理のフローチャート。 更新確認タイミングに関する具体的な事例を示す説明図。

１・・・パーソナルコンピュータ、２Ａ，２Ｂ，２Ｃ，２Ｄ，２Ｅ・・・プリンタ、３・・・サーバ、６・・・ルータ、１１，２１，３１・・・制御部、１１Ａ・・・ステータスモニタ、１１Ｂ・・・パーサ、１２，２２，３２・・・記憶部、１２Ａ・・・履歴情報、１３・・・入力部、１４，２４・・・表示部、１５，２５，３３・・・ネットワークインターフェイス、２２Ａ・・・ファームウェア、２３・・・操作部、２６・・・印刷部、３２Ａ・・・ファームウェア管理情報。

Claims (9)

1. 情報処理装置と通信可能な周辺装置に搭載されるファームウェアについて、前記情報処理装置と通信可能なサーバから新しいファームウェアをダウンロード可能か否かを確認し、ダウンロード可能な場合に、その旨を利用者に通知する処理を、前記情報処理装置に実行させるための周辺装置管理プログラムであって、
   前記情報処理装置を、
   前記ファームウェアのダウンロードが可能か否かの確認をする確認タイミングに至ったか否かを判定する確認タイミング判定手段と、
   前記確認タイミング判定手段によって前記確認タイミングに至ったと判定された場合に、前記周辺装置に搭載済みのファームウェアに関するファームウェア情報を、前記周辺装置から取得するファームウェア情報取得手段と、
   前記ファームウェア情報取得手段によって前記ファームウェア情報を前記周辺装置から正常に取得できた場合に、前記ファームウェア情報に基づいて特定されるファームウェアよりも新しいファームウェアを、前記サーバからダウンロード可能か否かを確認する確認手段と、
   前記確認手段によって、新しいファームウェアを前記サーバからダウンロード可能であると確認できた場合に、ダウンロード可能なファームウェアが存在する旨を利用者に通知する通知手段と、
   過去に一回の処理によって、正常に取得できた前記ファームウェア情報の数の内、最も頻度の高かった数をしきい値として、前記ファームウェア情報取得手段による前記ファームウェア情報の取得状況が、前記しきい値以上の周辺装置から前記ファームウェア情報を取得できた状況であった場合には、あらかじめ定められた第１期間の経過後を、前記確認タイミングとして設定する一方、前記しきい値以上の周辺装置から前記ファームウェア情報を取得できる状況ではなかった場合には、前記第１期間よりも短期間となるあらかじめ定められた第２期間の経過後を、前記確認タイミングとして設定する確認タイミング設定手段
   として機能させるための周辺装置管理プログラム。
2. 情報処理装置と通信可能な複数の周辺装置に搭載されるファームウェアについて、前記情報処理装置と通信可能なサーバから新しいファームウェアをダウンロード可能か否かを確認し、ダウンロード可能な場合に、その旨を利用者に通知する処理を、前記情報処理装置に実行させるための周辺装置管理プログラムであって、
   前記情報処理装置を、
   前記ファームウェアのダウンロードが可能か否かの確認をする確認タイミングに至ったか否かを、複数の前記周辺装置それぞれについて判定する確認タイミング判定手段と、
   前記確認タイミング判定手段によって前記確認タイミングに至ったと判定された場合に、前記確認タイミングに至ったと判定された周辺装置のみを対象に、前記周辺装置に搭載済みのファームウェアに関するファームウェア情報を、前記周辺装置から取得するファームウェア情報取得手段と、
   前記ファームウェア情報取得手段によって前記ファームウェア情報を前記周辺装置から正常に取得できた場合に、前記ファームウェア情報に基づいて特定されるファームウェアよりも新しいファームウェアを、前記サーバからダウンロード可能か否かを確認する確認手段と、
   前記確認手段によって、新しいファームウェアを前記サーバからダウンロード可能であると確認できた場合に、ダウンロード可能なファームウェアが存在する旨を利用者に通知する通知手段と、
   前記ファームウェア情報取得手段による前記ファームウェア情報の取得状況が、あらかじめ取り決められた条件を満足する取得状況であった場合には、複数の前記周辺装置の全てについて、あらかじめ定められた第１期間の経過後を、前記確認タイミングとして設定する一方、あらかじめ取り決められた条件を満足する取得状況ではなかった場合には、複数の前記周辺装置のそれぞれについて、前記第１期間よりも短期間となるあらかじめ定められた第２期間の経過後を、前記確認タイミングとして設定する確認タイミング設定手段
   として機能させるための周辺装置管理プログラム。
3. 前記確認タイミング設定手段は、前記ファームウェア情報取得手段による前記ファームウェア情報の取得状況が、所定数以上の周辺装置から前記ファームウェア情報を取得できた状況であった場合には、前記第１期間の経過後を前記確認タイミングとして設定する一方、所定数以上の周辺装置から前記ファームウェア情報を取得できる状況ではなかった場合には、前記第２期間の経過後を前記確認タイミングとして設定する手段とされている
   ことを特徴とする請求項２に記載の周辺装置管理プログラム。
4. 前記確認タイミング設定手段は、過去に一回の処理によって、正常に取得できた前記ファームウェア情報の数の内、最も頻度の高かった数をしきい値として、前記ファームウェア情報取得手段による前記ファームウェア情報の取得状況が、前記しきい値以上の周辺装置から前記ファームウェア情報を取得できた状況であった場合には、前記第１期間の経過後を前記確認タイミングとして設定する一方、前記しきい値以上の周辺装置から前記ファームウェア情報を取得できる状況ではなかった場合には、前記第２期間の経過後を前記確認タイミングとして設定する手段とされている
   ことを特徴とする請求項３に記載の周辺装置管理プログラム。
5. 前記情報処理装置を、さらに、
   複数の周辺装置の中から選ばれる１以上の周辺装置を監視対象周辺装置として、前記監視対象周辺装置の接続状態がオンラインになったことを検出する検出手段
   として機能させ、
   前記確認タイミング判定手段は、前記監視対象周辺装置の接続状態がオンラインになったことを前記検出手段が検出した際に、当該オンラインになった監視対象周辺装置に対して前記確認タイミングに至ったと判定する手段とされている
   ことを特徴とする請求項１〜請求項４のいずれか一項に記載の周辺装置管理プログラム。
6. 前記確認タイミング設定手段は、前記ファームウェア情報取得手段による前記ファームウェア情報の取得状況が、あらかじめ取り決められた特定の周辺装置から前記ファームウェア情報を取得できた状況であった場合には、前記第１期間の経過後を前記確認タイミングとして設定する一方、あらかじめ取り決められた特定の周辺装置から前記ファームウェア情報を取得できる状況ではなかった場合には、前記第２期間の経過後を前記確認タイミングとして設定する手段とされている
   ことを特徴とする請求項１〜請求項５のいずれか一項に記載の周辺装置管理プログラム。
7. 前記確認タイミング設定手段は、前記ファームウェア情報取得手段による前記ファームウェア情報の取得状況が、あらかじめ取り決められた条件を満足する取得状況ではなかった場合に、前記ファームウェア情報を取得できる頻度があらかじめ定められた基準値より高い周辺装置については、前記第２期間の経過後を前記確認タイミングとして設定する一方、前記ファームウェア情報を取得できる頻度が前記基準値より低い周辺装置については、前記第１期間よりも長期間となるあらかじめ定められた第３期間の経過後を、前記確認タイミングとして設定する手段とされている
   ことを特徴とする請求項１〜請求項６のいずれか一項に記載の周辺装置管理プログラム。
8. 情報処理装置と、前記情報処理装置と通信可能な周辺装置と、前記情報処理装置と通信可能なサーバとを備え、前記情報処理装置が、前記周辺装置に搭載されるファームウェアについて、前記サーバから新しいファームウェアをダウンロード可能か否かを確認し、ダウンロード可能な場合に、その旨を利用者に通知する処理を実行するように構成された周辺装置管理システムであって、
   前記情報処理装置が、
   前記ファームウェアのダウンロードが可能か否かの確認をする確認タイミングに至ったか否かを判定する確認タイミング判定手段と、
   前記確認タイミング判定手段によって前記確認タイミングに至ったと判定された場合に、前記周辺装置に搭載済みのファームウェアに関するファームウェア情報を、前記周辺装置から取得するファームウェア情報取得手段と、
   前記ファームウェア情報取得手段によって前記ファームウェア情報を前記周辺装置から正常に取得できた場合に、前記ファームウェア情報に基づいて特定されるファームウェアよりも新しいファームウェアを、前記サーバからダウンロード可能か否かを確認する確認手段と、
   前記確認手段によって、新しいファームウェアを前記サーバからダウンロード可能であると確認できた場合に、ダウンロード可能なファームウェアが存在する旨を利用者に通知する通知手段と、
   過去に一回の処理によって、正常に取得できた前記ファームウェア情報の数の内、最も頻度の高かった数をしきい値として、前記ファームウェア情報取得手段による前記ファームウェア情報の取得状況が、前記しきい値以上の周辺装置から前記ファームウェア情報を取得できた状況であった場合には、あらかじめ定められた第１期間の経過後を、前記確認タイミングとして設定する一方、前記しきい値以上の周辺装置から前記ファームウェア情報を取得できる状況ではなかった場合には、前記第１期間よりも短期間となるあらかじめ定められた第２期間の経過後を、前記確認タイミングとして設定する確認タイミング設定手段と
   を備えることを特徴とする周辺装置管理システム。
9. 情報処理装置と、前記情報処理装置と通信可能な複数の周辺装置と、前記情報処理装置と通信可能なサーバとを備え、前記情報処理装置が、前記周辺装置に搭載されるファームウェアについて、前記サーバから新しいファームウェアをダウンロード可能か否かを確認し、ダウンロード可能な場合に、その旨を利用者に通知する処理を実行するように構成された周辺装置管理システムであって、
   前記情報処理装置が、
   前記ファームウェアのダウンロードが可能か否かの確認をする確認タイミングに至ったか否かを、複数の前記周辺装置それぞれについて判定する確認タイミング判定手段と、
   前記確認タイミング判定手段によって前記確認タイミングに至ったと判定された場合に、前記確認タイミングに至ったと判定された周辺装置のみを対象に、前記周辺装置に搭載済みのファームウェアに関するファームウェア情報を、前記周辺装置から取得するファームウェア情報取得手段と、
   前記ファームウェア情報取得手段によって前記ファームウェア情報を前記周辺装置から正常に取得できた場合に、前記ファームウェア情報に基づいて特定されるファームウェアよりも新しいファームウェアを、前記サーバからダウンロード可能か否かを確認する確認手段と、
   前記確認手段によって、新しいファームウェアを前記サーバからダウンロード可能であると確認できた場合に、ダウンロード可能なファームウェアが存在する旨を利用者に通知する通知手段と、
   前記ファームウェア情報取得手段による前記ファームウェア情報の取得状況が、あらかじめ取り決められた条件を満足する取得状況であった場合には、複数の前記周辺装置の全てについて、あらかじめ定められた第１期間の経過後を、前記確認タイミングとして設定する一方、あらかじめ取り決められた条件を満足する取得状況ではなかった場合には、複数の前記周辺装置のそれぞれについて、前記第１期間よりも短期間となるあらかじめ定められた第２期間の経過後を、前記確認タイミングとして設定する確認タイミング設定手段と
   を備えることを特徴とする周辺装置管理システム。

Images