(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-09-30
(45)【発行日】2024-10-08
(54)【発明の名称】制御プログラム、端末
(51)【国際特許分類】
G06F 3/12 20060101AFI20241001BHJP
G06F 8/65 20180101ALI20241001BHJP
H04N 1/00 20060101ALI20241001BHJP
B41J 29/38 20060101ALN20241001BHJP
【FI】
G06F3/12 330
G06F3/12 303
G06F3/12 331
G06F8/65
H04N1/00 127B
B41J29/38
(21)【出願番号】P 2020180125
(22)【出願日】2020-10-28
【審査請求日】2023-09-26
(73)【特許権者】
【識別番号】000005267
【氏名又は名称】ブラザー工業株式会社
(74)【代理人】
【識別番号】110000992
【氏名又は名称】弁理士法人ネクスト
(72)【発明者】
【氏名】曽根 竜彦
【審査官】佐藤 実
(56)【参考文献】
【文献】特開2018-037764(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06F 3/09 - 3/12
B41J 29/00 -29/70
G06F 8/65
H04N 1/00
(57)【特許請求の範囲】
【請求項1】
通信インタフェースと、ユーザインタフェースとを備え、前記通信インタフェースを介
して画像形成装置、及びサーバと通信可能な端末のコントローラで実行可能な制御プログ
ラムであって、
前記制御プログラムは、前記コントローラに、
前記通信インタフェースを介して、前記画像形成装置からファームウェアのバージョン情報を取得する取得処理と、
取得された前記バージョン情報が前回取得済みの前記バージョン情報と同じである場合に、前記サーバに対して、前記画像形成装置に対応するファームウェアのバージョンを確認し、
取得された前記バージョン情報が前回取得済みの前記バージョン情報と異なっている場合に、前記サーバに対して前記ファームウェアのバージョンを確認しない確認処理と、
前記確認処理により、前記ファームウェアのバージョンが新しくなったと確認された場合に、前記ユーザインタフェースを介して通知を行う通知処理と、を実行させる制御プログラム。
【請求項2】
前記端末には、前記通知処理における通知対象となる複数の前記画像形成装置が登録されており、
前記確認処理では、登録された前記複数の画像形成装置における前記バージョン情報を、前記サーバに対して個別に確認する請求項1に記載の制御プログラム。
【請求項3】
前記取得処理では、第1期間毎に、前記画像形成装置から前記ファームウェアの前記バージョン情報を取得し、
前記確認処理では、
前記登録された複数の画像形成装置毎に、前記サーバに対して、前記ファームウェアのバージョンを確認した最終時刻を記憶しており、
前記取得処理により取得された前記バージョン情報が前回取得済みの前記バージョン情報と同じである場合に、記憶された全ての前記最終時刻のうち最も新しい時刻から第2期間を経過していることを条件に、前記サーバに対して前記ファームウェアのバージョンを確認し、前記第2期間は、前記第1期間以上の期間である請求項2に記載の制御プログラム。
【請求項4】
前記取得処理では、第1期間毎に、前記画像形成装置から前記ファームウェアのバージョン情報を取得し、
前記確認処理では、
前記サーバに対して、前記ファームウェアのバージョンを確認した最終時刻を記憶しており、
前記取得処理により取得された前記バージョン情報が前回取得済みの前記バージョン情報と同じである場合に、同一の前記画像形成装置に対応する前記最終時刻から第3期間が経過していることを条件に、前記サーバに対して前記ファームウェアのバージョンを確認し、前記第3期間は前記第1期間よりも長い期間である請求項2又は3に記載の制御プログラム。
【請求項5】
前記確認処理では、前記登録された複数の画像形成装置に対して前記ファームウェアのバージョンを確認する優先順序が定められており、前記優先順序が高いものから順に前記サーバに対して前記ファームウェアのバージョンを確認する請求項2~4のいずれか一項に記載の制御プログラム。
【請求項6】
前記確認処理では、使用頻度が高い前記画像形成装置、又は最終使用日時が直近の前記画像形成装置ほど、前記優先順序を高くする請求項5に記載の制御プログラム。
【請求項7】
前記取得処理では、前記通信インタフェースにより、ローカルエリアネットワークを通じて前記画像形成装置から前記バージョン情報を取得する請求項1~6のいずれか一項に記載の制御プログラム。
【請求項8】
前記取得処理では、
前記画像形成装置に対して、HTTPプロトコルに応じた前記バージョン情報の取得要求を、前記通信インタフェースを介して送信し、
前記バージョン情報の取得要求を送信する前に、前記ユーザインタフェースにHTTPプロトコルに応じた通信を行うことを報知させる請求項7に記載の制御プログラム。
【請求項9】
前記通知処理では、前記ユーザインタフェースに、新しいバージョンの前記ファームウェアが前記サーバに記憶されていることを示す通知画面を表示させ、
前記制御プログラムは、前記コントローラに、前記通知画面上
で指示操作を受付けた場合に、前記サーバから前記ファームウェアを前記画像形成装置にダウンロードさせるための処理を実行する請求項1~8のいずれか一項に記載の制御プログラム。
【請求項10】
通信インタフェースと、ユーザインタフェースと、コントローラと、を備え、前記通信インタフェースを介して画像形成装置、及びサーバと通信可能であり、
前記コントローラは、
前記通信インタフェースを介して、前記画像形成装置からファームウェアのバージョン情報を取得する取得処理と、
取得された前記バージョン情報が前回取得済みの前記バージョン情報と同じである場合に、前記サーバに対して、前記画像形成装置に対応するファームウェアのバージョンを確認し、
取得された前記バージョン情報が前回取得済みの前記バージョン情報と異なっている場合に、前記サーバに対して前記ファームウェアのバージョンを確認しない確認処理と、
前記確認処理により、前記ファームウェアのバージョンが新しくなったと確認された場合に、前記ユーザインタフェースを介して通知を行う通知処理と、を実行する端末。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、画像形成装置のファームウェアがアップデート可能か否かを通知する技術に関する。
【背景技術】
【0002】
特許文献1には、画像形成装置のファームウェアがアップデート可能な場合に、ユーザインタフェースにより当該ファームウェアをアップデート可能であることを通知する端末が記載されている。具体的には、端末は、サーバに対して新たなバージョンのファームウェアが記憶されているか否かの確認を行い、確認結果に応じて、ファームウェアのアップデートの可否を判断している。
【先行技術文献】
【特許文献】
【0003】
【発明の概要】
【発明が解決しようとする課題】
【0004】
端末が、サーバに対してファームウェアのバージョンを頻繁に確認すると、サーバにおける通信負荷が高くなるおそれがある。しかし、画像形成装置におけるファームウェアのアップデートが遅れることで、当該画像形成装置の動作に悪影響を及ぼすことも懸念される。
【0005】
本発明は、上記課題に鑑みたものであり、サーバに対する通信負荷の増加の抑制と、ファームウェアのアップデートタイミングの適正化とをバランスよく両立させることを目的とする。
【課題を解決するための手段】
【0006】
上記課題を解決するために本発明は、通信インタフェースと、ユーザインタフェースとを備え、通信インタフェースを介して画像形成装置、及びサーバと通信可能な端末のコントローラで実行可能な制御プログラムに関する。コントローラは、制御プログラムを実行することで、通信インタフェースを介して、画像形成装置からファームウェアのバージョン情報を取得する取得処理と、取得されたバージョン情報が前回取得済みのバージョン情報と同じである場合に、サーバに対して、画像形成装置に対応するファームウェアのバージョンを確認し、取得されたバージョン情報が前回取得済みのバージョン情報と異なっている場合に、サーバに対してファームウェアのバージョンを確認しない確認処理と、ファームウェアのバージョンが新しくなったと確認された場合に、ユーザインタフェースを介して通知を行う通知処理と、を実行する。
【0007】
上記構成では、バージョン情報が前回取得済みのバージョン情報から変更された場合は、サーバに対してファームウェアのバージョンが確認されない。一方で、バージョン情報が前回取得済みのバージョン情報と同じである場合は、ファームウェアが新しいバージョンとなっている可能性があるため、サーバに対してファームウェアのバージョンが確認される。これにより、一定の間隔で一律にサーバに対してファームウェアのバージョンを確認する場合と比べて、サーバに対する通信負荷の増加の抑制と、ファームウェアのアップデートタイミングの適正化とをバランスよく両立させることができる。
【0008】
本発明は、種々の形態により実現することが可能であり、コンピュータが実行する制御プログラムの発明以外にも、制御プログラムによる各機能を実現する端末の発明としても実現することができる。
【発明の効果】
【0009】
本発明によれば、サーバに対する通信負荷の増加の抑制と、ファームウェアのアップデートタイミングの適正化とをバランスよく両立させることができる。
【図面の簡単な説明】
【0010】
【
図6】端末で実行される処理の手順を説明するタイミングチャート。
【
図7】
図6のS16で実行される処理の手順を示すフローチャート。
【
図8】端末で実行される処理の手順を説明するタイミングチャート。
【発明を実施するための形態】
【0011】
(第1実施形態)
本実施形態係に係るスキャンシステムを、図面を参照しつつ説明する。
【0012】
図1に示すシステム100は、端末10と、サーバ30と、MFP(Multifunction Peripheral/Printer/Product)50,58,59とを備えている。端末10と、MFP50,58,59とはローカルエリアネットワーク(LAN)200に接続されている。LAN200は、有線の他、無線であってもよいし有線と無線の組み合わせにより構成されていてもよい。LAN200は、インターネット201に接続されており、このインターネット201にはサーバ30が接続されている。
【0013】
MFP50の構成を説明する。なお、MFP58,59のハードウェア構成は、MFP50と同様であるため、説明を省略する。MFP50は、バス51、通信IF52、プリンタ部53、読取部54、ユーザIF55、コントローラ56及びメモリ57を備えている。MFP50を構成する各部は、バス51を介して通信可能に接続されている。IFは、Interfaceの略称である。
【0014】
通信IF52は、所定の通信プロトコルに準拠して、MFP50をLAN200又はインターネット201に接続する。ユーザIF55は、MFPのコントローラ56とユーザとの間に介在するインタフェースであり、本実施形態では、タッチパネルや、操作キーを備えている。コントローラ56は、プリンタ部53、読取部54、ユーザIF55の各動作を制御する。
【0015】
プリンタ部53は、シートやディスクなどの被記録媒体に画像を印刷するプリント動作を実行する。プリンタ部53の記録方式としては、記録媒体としてのインクを被記録媒体に吐出するインクジェット方式や、感光体にトナー像を形成し、形成されたトナー像を被記録媒体に転写する電子写真方式などを採用することができる。読取部54は、原稿に記録されている画像を読み取ってスキャンデータを生成するスキャン動作を実行する。MFP50のコントローラ56は、読取部54に、ADF(Auto Document Feeder)又は読取り台にセットされた原稿を読み取らせることで、スキャンデータを作成させ、作成されたスキャンデータを、通信IF52を介してサーバ30又は端末10に送信することができる。また、MFP50は、複数の動作を組み合わせた複合動作を実行可能であってもよい。プリンタ部53によるプリント動作と、読取部54によるスキャン動作とを組み合わせたコピー動作は、複合動作の一例である。
【0016】
コントローラ56は、CPUや、ASIC(Application Specific Integrated Circuit)等により構成されており、MFP50を構成する各部を制御する。本実施形態において、メモリ57は、例えば、RAM(Random Access Memory)、ROM(Read Only Memory)、フラッシュメモリーが組み合わされて構成されている。また、メモリ57は、コンピュータであるコントローラ56が読み取り可能なストレージ媒体であってもよい。ストレージ媒体とは、CD-ROM、DVD-ROM等の記録媒体も含まれる。以下、後述するメモリ17,35においても同様である。
【0017】
メモリ57には、コントローラ56が参照するデータとして、ファームウェア41(以下、FWと記載する。)と、MIB(Management Information Base)42とが記憶されている。FW41は、MFP50における各動作を制御するためのプログラムである。MIB42には、MFP50を識別するための識別情報と、MFP50が実行可能な動作や、能力を示す情報とが記憶されている。更に、MIB42には、現在のFWのバージョンを示すバージョン情報が記憶されている。バージョン情報は、FWのバーションを識別する情報であり、数字又はアルファベットにより記述されている。MIB42には、MFP50のメモリ57に記憶された現在のFWのバージョン情報が記憶されている。
【0018】
次に、サーバ30の構成を説明する。サーバ30は、バス31と、サーバ側CPU32と、ユーザIF33と、通信IF34と、メモリ35とを備えている。サーバ30を構成する各部は、バス31を介して通信可能に接続されている。
【0019】
メモリ35のデータ記憶領域には、MFP50,58,59にダウンロード可能なFWと、ファームウェア情報43とが記憶されている。ファームウェア情報43は、
図2に示すように、装置のモデル名と、各装置に対応するFWのバージョンを示すバージョン情報とが関連づけて記憶されている。
図2において、モデル名「MFP-0001」は、MFP50のモデル名であり、モデル名「MFP-0002」は、MFP58のモデル名であり、モデル名「MFP-0003」は、MFP59のモデル名である。サーバ側CPU32は、FWが新たなバージョンに変更された場合、FWの新たなバージョン情報を、該当するファームウェア情報43の欄に記憶する。
【0020】
次に、端末10の構成を説明する。端末10は、スマートフォンやタブレット端末である。端末10は、バス11と、端末側CPU12と、ユーザIF13と、通信IF16と、メモリ17とを備えている。これらの構成要素は、バス11を介して互いに通信可能にされている。
【0021】
ユーザIF13は、タッチパネル14と、操作キー15とを備えている。タッチパネル14は、タッチセンサを有しており、タッチセンサによる検出結果に応じた信号を出力する。なお、本実施形態における「タッチ」とは、入力媒体をタッチパネル14の表示画面に接触させる操作全般を含む。具体的には、タッチした入力媒体を所定時間内にタッチパネル14から離間させるタップ操作をタッチの一例として説明するが、ロングタッチ操作、スライド操作、フリック操作、ピンチイン操作、ピンチアウト操作等であってもよい。また、入力媒体をタッチパネル14との間の距離がごく僅かな位置まで入力媒体を近接させることを、前述の「タッチ」の概念に含めてもよい。さらに入力媒体とは、ユーザの指であってもよいし、タッチペン等であってもよい。
【0022】
通信IF16は、例えば、IEEEの802.11の規格およびそれに準ずる規格に基づいて、Wi-Fi(R)(登録商標)方式の無線通信を行うことが可能とされている。また、通信IF16は、MFP50との間でBluetooth(登録商標)などの近距離無線通信を行うものであってもよいし、基地局を介した移動通信システムを利用した無線通信を行うものであってもよい。
【0023】
端末側CPU12は、メモリ17に記憶されたプログラムを実行することで、端末10の各部を制御する。本実施形態では、端末側CPU12が、コントローラの一例である。メモリ17には、OS20(Operating System)と、制御プログラム21とデバイス管理情報40とが記憶されている。以下では、プログラムを実行する端末側CPU12のことを、単にプログラム名でも記載する場合がある。例えば、「制御プログラム21が」という記載は、「制御プログラム21を実行する端末側CPU12が」ということを意味する場合がある。
【0024】
なお、本実施形態では、主に、プログラムに記述された命令に従ったCPUの処理を示す。すなわち、以下の説明における「判断」、「抽出」、「選択」、「算出」、「決定」、「特定」、「取得」、「受付」、「制御」等の処理は、CPUやコントローラの処理を表している。CPUによる処理は、OS20を介したハードウェア制御も含む。なお「取得」は要求を必須とはしない概念で用いる。すなわち、制御プログラム21が要求することなくデータを受信するという処理も、「CPUがデータを取得する」という概念に含まれる。また、本明細書中の「データ」とは、コンピュータに読取可能な形式で表される。そして、実質的な意味内容が同じでフォーマットが異なるデータは、同一のデータとして扱われるものとする。本明細書中の「情報」についても同様である。
【0025】
OS20は、制御プログラム21に対して、OS20が備える機能の利用、サーバ30及び各MFP50,58,59との通信、及び他のプログラムの機能の利用を可能にするAPI(Application Programming Interface)を備えている。制御プログラム21は、OS20の機能により、通信IF16を介して接続可能なMFPに対して、プリント動作、スキャン動作、FAX動作等を実行させる。
【0026】
メモリ17のデータ記憶領域には、
図3に示すデバイス管理情報40が記憶されている。デバイス管理情報40は、端末10により制御対象として登録された装置におけるFWのバージョン情報や、FWのバージョンの確認を行った履歴を管理する情報である。デバイス管理情報40の詳細については後述する。
【0027】
次に、端末10の操作に応じて、MFP50に所定の機能(プリント動作、スキャン動作)を実行させる手順を説明する。端末10の制御プログラムは、ユーザIF13を介して、トップ画面の表示操作を受付けると、
図4に示すトップ画面60をユーザIF13に表示させる。トップ画面60は、端末10が制御対象として登録している装置に対する指示を受付ける画面であり、本実施形態では、機能表示領域61と、装置指定領域65を含んでいる。
【0028】
機能表示領域61は、指定済みの装置に実行させる機能の指定を受付ける領域である。
図4に示す機能表示領域61では、指定された装置に対して、「プリント動作」を実行させるための指示を受付ける操作アイコン63と、「スキャン動作」を実行させるための指示を受付ける操作アイコン64とが表示されている。制御プログラム21は、トップ画面60上で、操作アイコン63の指定操作を受付けた場合、印刷ジョブデータを生成し、生成された印刷ジョブデータを、指定済みの装置に送信する。
【0029】
装置指定領域65は、現在、端末10の制御対象となっている装置のモデル名を表示する領域である。
図4では、装置指定領域65には、MFP50のモデル名である「MFP-0001」が表示されている。
制御プログラム21は、ユーザIF13を介して装置指定領域65に対する指示操作を受付けると、装置指定領域65に表示されたモデル名の変更を受付ける画面をユーザIF13に表示させる。制御プログラム21は、ユーザIF13を介して装置指定領域65に表示されるモデル名の変更を受付けることで、制御対象となる装置を変更することができる。
【0030】
制御プログラム21は、トップ画面60上で、ユーザIF13を介してインフォメーションアイコン62の指定操作を受付けた場合、
図5に示すインフォメーション画面70を表示させる。インフォメーション画面70には、制御対象となる装置(
図5では、MFP10)に関連する各種情報を表示する複数の表示欄を含んでいる。具体的には、インフォメーション画面70には、装置指定領域65上で指定された装置のモデル名を表示する表示欄71、指定された装置におけるFWのバージョンを示す表示欄72、指定された装置におけるIPアドレスを表示する表示欄73、指定された装置におけるシリアル番号を表示する表示欄74が含まれている。本実施形態では、サーバ30に記憶されたFWが新しいバージョンに変更された場合、表示欄73には、FWのバージョンが変化したことを示すアップデート通知アイコン76が表示される。なお、表示欄71を指定して、モデル名を変更することで、インフォメーション画面70に含まれる各表示欄の値を、変更されたモデル名に対応する値に変更することができる。
【0031】
制御プログラム21は、サーバ30に記憶されているFWのバージョンが新しくなったか否かを判断するため、サーバ30からFWのバージョンを問い合わせる必要がある。しかし、サーバ30に対して頻繁に問い合わせを行うと、サーバ30における通信負荷が高くなるおそれがある。しかし、FWのアップデートが遅れることで、装置の動作に悪影響を及ぼすことも懸念される。そこで、本実施形態では、制御プログラム21は、サーバに対するバージョンの確認頻度と、FWのアップデートの最適化とをバランスよく両立させるように各処理を実行する。
【0032】
次に、
図6を用いて、サーバ30に対して、FWのバージョンを確認する処理の手順を説明する。
図6では、制御プログラム21による機能を、ビュアー22、ステータス監視部23、ステータス取得部24、アップデートチェック部25として機能的に示している。
図6に示す処理は、ユーザIF13に
図4に示すトップ画面60が表示されたことを契機に実行される。
【0033】
ステップ10(以下、S10と記載する。)では、ビュアー22は、今回の
図6で示す処理の対象となる装置を決定する。本実施形態では、現在、デバイス管理情報40に登録された複数の装置に対してバージョン情報を確認する優先順序が定められている。具体的には、制御プログラム21は、現在、デバイス管理情報40に登録された装置のうち、使用された日時が新しい装置ほど、優先順序を高くする。
【0034】
図3に示すように、デバイス管理情報40には、端末10が制御可能な装置の「モデル名」に関連づけて、FWの「バージョン情報」、「最終使用日時」、「最終確認時刻」が登録されている。最終使用日時は、装置を最後に使用した時刻である。最終確認時刻は、サーバ30に対して最後にFWのバージョンを確認した時刻である。
図3に示すデバイス管理情報40では、最終使用日時が最も新しいMFP50(モデル名は「MFP-0001」)が、今回の対象装置に決定される。なお、次回の
図6の処理では、最終使用日時が次に新しいMFP59(モデル名は「MFP-0003」)が対象装置に決定される。なお、本実施形態では、一度、優先順序が定められると、デバイス管理情報40に登録された全ての装置に対して
図6に示す処理が実行されるまで優先順序は変更されない。また、デバイス管理情報40に登録されている装置が1台しかない場合、優先順序が設定されず、登録された1台の装置が対象装置に決定される。
【0035】
S11では、ビュアー22は、前回、トップ画面60が表示されてから、第1期間を経過しているか否かを判断する。第1期間は、例えば、1時間である。S10を否定判定した場合、
図6の処理を終了する。一方、S10を肯定判定した場合、ビュアー22は、S12で、ステータス監視部23に、対象装置のFWにおけるアップデートの確認要求を送信する。
【0036】
ステータス監視部23は、アップデートの確認要求を受けると、S13では、ステータス取得部24に対して、FWのバージョン情報に対する取得要求を送信する。
【0037】
ステータス取得部24は、バージョン情報の取得要求を受けると、S14で、対象装置からバージョン情報を取得する。本実施形態では、制御プログラム21は、通信IF16により、LAN200を通じて対象装置からバージョン情報を取得する。これは、インターネット201を通じて通信を行う場合と比べて、バージョン情報を取得する際の通信負荷の増加を抑制するためである。そして、MFP50のコントローラ56は、バージョン情報の取得要求を受けると、MIB42に登録されたバージョン情報を読み出し、端末10に返信する。
【0038】
ステータス取得部24は、S15で、対象装置であるMFP50から返信されたバージョン情報を、ステータス監視部23に返信する。ステータス監視部23は、バージョン情報を取得すると、S16では、取得されたバージョン情報の比較を行う。
図7は、
図6のS16で、ステータス取得部24が実行する処理の詳細な手順を説明するフローチャートである。
【0039】
S40では、対象装置におけるバージョン情報の比較を行う。具体的には、S14で対象装置から取得されたバージョン情報と、デバイス管理情報40に記憶されている対象装置におけるバージョン情報とを比較し、バージョン情報が異なっているか否かを判断する。対象装置のFWが既にアップデートされている場合、対象装置から取得されたバージョン情報は、新しい値に変更されているため、デバイス管理情報40に記憶されているバージョン情報とは異なる値となる。
【0040】
S41では、FWのバージョン情報は一致するか否かを判断する。バージョン情報が一致しており、S41を肯定判定すると、S42に進み、メモリ17に記憶された比較結果フラグをバージョン情報が一致することを示す値に設定する。一方、バージョン情報が一致しておらず、S41を否定判定すると、S43に進み、メモリ17に記憶された比較結果フラグをバージョン情報が不一致であることを示す値に設定する。S42,S43でメモリ17に記憶された比較結果フラグは、今回の
図6の処理が終了したことを条件に消去される。S42又はS43の処理が終了すると、S17に進む。
【0041】
図6に戻り、ステータス監視部23は、S17で、比較結果フラグの値を参照し、バージョン情報が変更されているか否かを判断する。S17を肯定判定した場合、ステータス監視部23は、S18に進み、対象装置から取得されたバージョン情報を、現在の対象装置におけるFWのバージョン情報として、デバイス管理情報40に記憶する。S19では、ステータス監視部23は、アップデート判定フラグを「不要」を示す値に設定する。アップデート判定フラグは、現在、対象装置に対してFWのアップデートが必要であるか否かを示すフラグであり、必要である場合は「必要」を示す値とし、不要である場合は「不要」を示す値となる。
【0042】
S20では、ステータス監視部23は、S19で設定したアップデート判定フラグの値に応じて、S12でのアップデートの確認要求に対する返信を行う。この場合、ステータス監視部23は、FWのアップデートは必要でないことを返信する。ビュアー22は、S20での返信を受けると、
図5に示すインフォメーション画面70において、表示欄73にアップデート通知アイコン76を表示させない。即ち、FWのアップデートが必要であることを通知しない。
【0043】
一方、S17を否定判定した場合、ステータス監視部23は、S21に進み、現在、アップデート判定フラグが「必要」を示す値となっているか否かを判断する。ステータス監視部23は、S21を肯定判断すると、前回の
図6の処理において、FWに対するバージョンの確認(後述するS25の処理)が実行されているため、処理を終了する。一方、S21を否定判定すると、S22に進み、前回、確認処理(後述するS25)を行った日時から第2期間以上経過しているか否かを判断する。具体的には、ステータス監視部23は、デバイス管理情報40に登録された全ての最終確認時刻のうち、最も新しい時刻から現在の時刻までに、第2期間以上経過しているか否かを判断する。第2期間は、第1期間以上の期間で後述する第3期間より短い期間であるとよい。例えば、第2期間は、1時間以上で、6日以下の期間とすることができる。これにより、FWのバージョンの確認は、少なくとも第2期間以上の期間を開けて実行される。S22を否定判定した場合、処理を終了する。
【0044】
S22を肯定判定した場合、S23に進み、デバイス管理情報40に記憶された最終確認時刻のうち、今回の対象装置(本実施形態では、MFP50)における最終確認時刻から第3期間以上経過しているか否かを判断する。第3期間は、第1期間よりも長い期間であり、第2期間よりも長い期間とするとよい。第3期間は、例えば、7日である。これにより、同じ装置に対するFWのバージョンの確認は、少なくとも第3期間以上の期間を開けて実行される。S23を否定判定した場合、処理を終了する。
【0045】
S23を肯定判定した場合、S24に進み、アップデートチェック部25に、サーバ30に対するFWのバージョンの確認の要求、即ち、確認処理の開始要求を送信する。なお、S21-S23のいずれか一つを否定判定する場合、
図6の処理を終了する。即ち、サーバ30に対して確認処理が実行されない。
【0046】
アップデートチェック部25は、確認処理の開始要求を受けると、S25で、サーバ30に対して、対象装置のFWにおけるバージョンを問い合わせる。具体的には、アップデートチェック部25は、FWのバージョンを問い合わせるためのXMLリクエストを作成し、作成されたXMLリクエストをサーバ30に送信する。XMLリクエストには、FWのバージョンの問合せと共に、対象装置を指定するためのモデル名が送信される。アップデートチェック部25(制御プログラム21)により実行されるS25の処理が、確認処理の一例である。
【0047】
サーバ30のサーバ側CPU32は、XMLリクエストを受信すると、ファームウェア情報43を参照し、指定された対象装置(本実施形態では、MFP50)のFWのバージョン情報を確認する。そして、サーバ側CPU32は、バージョン情報を、XMLレスポンスとして、端末10に返信する。
【0048】
次に、端末10が、サーバ30からのXMLレスポンスを返信した後の処理の手順を、
図8を用いて説明する。アップデートチェック部25は、S30で、サーバ30からXMLレスポンスを受信したか否かを判断する。S30を否定判定する場合、待機する。アップデートチェック部25は、サーバ30からXMLレスポンスを受信すると、S30を肯定判定し、S31に進む。S31では、アップデートチェック部25は、XLMレスポンスにより示されるFWのバージョン情報は、新たなバージョン情報であるか否かを判断する。例えば、アップデートチェック部25は、XMLレスポンスに含まれるバージョン情報が、デバイス管理情報40に記憶されたバージョン情報と異なっている場合、サーバ30には新たなバージョンのFWが記憶されていると判断する。
【0049】
アップデートチェック部25は、XMLリクエストに含まれる対象装置のFWのバージョンが新しい場合、S31を肯定判定し、S32に進み、アップデート判定フラグを、FWのアップデートが必要であることを示す値に設定する。一方、アップデートチェック部25は、S31を否定判定すると、S33に進み、アップデート判定フラグを、FWのアップデートが不要であることを示す値に設定する。
【0050】
S34では、アップデートチェック部25は、ステータス監視部23に対して、アップデート判定フラグを設定したことを通知する。ステータス監視部23は、アップデート判定フラグが設定されたことの通知を受けると、S35で、デバイス管理情報40に記憶された対象装置の最終確認時刻を、現在の時刻に更新する。
【0051】
ステータス監視部23は、S36で、確認処理の結果をビュアー22に通知する。ビュアー22は、S37で、確認処理の結果であるアップデート判定フラグの値に応じて、FWのアップデートの必要の有無を通知するための通知処理を行う。具体的には、ビュアー22は、アップデート判定フラグが「必要」を示す値である場合、インフォメーション画面70における表示欄73にアップデート通知アイコン76を表示させる。一方、ビュアー22は、アップデート判定フラグが「不要」を示す値である場合、インフォメーション画面70における表示欄73にアップデート通知アイコン76を表示しない。本実施形態では、アップデート通知アイコン76が表示されたインフォメーション画面70が、通知画面の一例である。
【0052】
制御プログラム21は、表示欄73にアップデート通知アイコン76が表示された状態で、ユーザIF13を介して、表示欄73のタッチ操作を受付けると、ユーザIF13に、
図9に示すダウンロード指示画面80を表示させる。ダウンロード指示画面80は、サーバ30からFWを対象装置にダウンロードさせるための指示操作を受付ける画面である。ダウンロード指示画面80には、ユーザIF13を介して、FWをダウンロードさせるための処理の指示操作を受付ける開始アイコン81を含んでいる。
【0053】
制御プログラム21は、開始アイコン81に対する指示操作を受付けると、サーバ30にFWをダウンロードさせるための処理として、MFP50のEWS(Embedded Web Server)にFWダウンロード用のWebページデータをダウンロードさせる。EWSは、Webサーバであり、コントローラ56がメモリ57に記憶された不図示のプログラムを実行することで実現する機能である。制御プログラム21は、ダウンロードされたWebページデータにより、ダウンロード受付け画面をタッチパネル14に表示させる。制御プログラム21は、ダウンロード受付け画面上で、新たなバージョンのFWのダウンロードの指定操作を受付けた場合、ダウンロード対象となるFWを指定する情報を、MFP50に送信する。
【0054】
MFP50のコントローラ56は、端末10から送信された情報により、サーバ30に対して指定されたFWのダウンロードを要求する。これにより、サーバ30からMFP50に対してFWがダウンロードされ、MFP50のコントローラ56により、メモリ57に記憶されたFW41がアップロードされる。
【0055】
以上説明した本実施形態では、以下の効果を奏することができる。
端末10の制御プログラム21は、MFP50においてFWのバージョン情報が前回取得済みのバージョン情報から変更された場合は、サーバ30に対してFWのアップデートが確認されない。一方で、FWのバージョン情報が前回取得済みのバージョン情報と同じである場合は、サーバ30に対してFWのバージョン情報が確認される。これにより、一定の間隔で一律にサーバに対してバージョン情報を確認する場合と比べて、サーバ30に対する通信負荷の増加の抑制と、FWのアップデートタイミングの適正化とをバランスよく両立させることができる。
【0056】
端末10には、FWのアップデートの通知対象となる複数のMFPが登録されており、制御プログラム21は、デバイス管理情報40に登録された複数のMFPに対して、個別にサーバ30に対してバージョン情報を確認する。これにより、全てのMFPのFWに対するバージョン情報を一括で、サーバ30に確認する場合と比べて、1回の通信で扱われるデータ量の増加を抑制することができる。その結果、サーバ30の通信負荷の一時的な増加を抑制することができる。
【0057】
制御プログラム21は、対象装置から取得されたバージョン情報が前回取得済みのバージョン情報と同じである場合に、デバイス管理情報40に記憶された全ての最終時刻のうち最も新しい最終時刻から第2期間を経過していることを条件に、サーバ30に対してバージョン情報を確認する。これにより、サーバ30に対する確認処理の実行間隔が近くなることに伴う通信負荷の増加を抑制することができる。
【0058】
制御プログラム21は、対象装置から取得されたバージョン情報が前回取得済みのバージョン情報と同じである場合に、デバイス管理情報40に記憶された同一の装置における最終時刻から第3期間を経過していることを条件に、サーバ30に対してバージョン情報を確認する。これにより、同一の装置に対してサーバ30に対する確認処理の実行間隔が近くなることを抑制し、ひいては、サーバ30の通信負荷の増加をいっそう抑制することができる。
【0059】
制御プログラム21は、デバイス管理情報40に登録された複数のMFPに対してバージョン情報を確認する優先順序が定められており、優先順序が高いものから順にサーバ30に対してバージョン情報を確認する。これにより、FWを優先してアップデートさせたい装置と、優先させないMFPとの間で、優先順序を異ならせることができる。
【0060】
制御プログラム21は、最終使用日時が新しい装置ほど、優先順序を高く設定する。これにより、ユーザの使用実績に合わせて優先順序を設定することができる。
【0061】
制御プログラム21は、通信IF16により、LAN200を通じて前記画像形成装置からバージョン情報を取得する。これにより、端末10は、インターネット201を通じて通信を行う場合と比べて、対象装置からバージョン情報を取得する際の通信負荷の増加を抑制することができる。
【0062】
制御プログラム21は、ユーザIF13に、新しいバージョンのFWがサーバ30に記憶されていることを示すアップデート通知アイコン76を表示させ、このアップデート通知アイコン76が表示されたインフォメーション画面70上で指示操作を受付けた場合に、サーバ30からファームウェアを対象装置にダウンロードさせるための処理を実行する。これにより、端末10に表示された画面上でFWをダウンロードさせるための処理に対する操作を受付けることができるため、ユーザの利便性を高めることができる。
【0063】
(第1実施形態の変形例)
制御プログラム21は、
図6のS10において、使用頻度が高い装置ほど、優先順序を高くしてもよい。この場合において、制御プログラム21は、デバイス管理情報40を参照して、各装置における所定期間での使用頻度を判断すればよい。
【0064】
制御プログラム21は、
図6のS10において、デバイス管理情報40に記憶された最終確認時刻が古い装置ほど、優先順序を高くしてもよい。また、制御プログラム21は、
図6のS10において、販売日が新しい装置ほど、優先順序を高く設定してもよい。
【0065】
制御プログラム21は、
図9に示すダウンロード指示画面80上で開始アイコン81に対する指示操作を受付けた場合に、サーバ30に対して、新たなバージョンのFWに対する、MFP50へのダウンロードを直接要求してもよい。
【0066】
制御プログラム21は、今回の
図6の処理が登録された全ての装置における最終時刻から第2期間を経過していることを、確認処理を開始する条件としなくともよい。この場合、
図6のS22で示す処理を抹消すればよい。制御プログラム21は、今回の
図6の処理が同一の装置における最終時刻から第3期間を経過していることを、確認処理を開始する条件としなくともよい。この場合、
図6のS23で示す処理を抹消すればよい。また、
図6のS22と
図6のS23の順は入れ替えてもよい。
【0067】
(第2実施形態)
第2実施形態では、第1実施形態と異なる構成を主に説明を行う。第2実施形態において第1実施形態と同一の箇所については同じ符号を付し、その説明を繰り返さない。
【0068】
本実施形態では、制御プログラム21は、S14において、対象装置に対してバージョン情報の取得を要求する際に、ユーザIF13に、HTTPプロトコルに応じた通信を行う旨の報知を行う。これは、暗号化を伴わないHTTPプロトコルに応じた通信を行うことをユーザに認識させるためである。この場合において、ユーザがHTTPプロトコルに応じた通信を拒否する指示操作を行った場合に、S14でのバージョン情報の取得を実行しないものとしてもよい。
【0069】
以上説明した本実施形態では、制御プログラム21は、対象装置に対してバージョン情報の取得要求を送信する前に、ユーザIF13によりHTTPプロトコルに応じた通信を行うことを報知させる。これにより、ユーザインタフェースにより報知を行うことで、通信が暗号化されていない旨をユーザに報知することができる。
【0070】
(その他の実施形態)
本明細書で開示される技術は、上述の実施形態に限られるものではなく、その要旨を逸脱しない範囲において種々の形態に変形することができ、例えば次のような変形も可能である。
上述した各実施形態では、制御プログラム21は、通知処理として、S37で、インフォメーション画面70上で、アップデート通知アイコン76を表示させた。これに代えて、制御プログラム21は、通知処理として、S37で、トップ画面60上、アップデート通知アイコン76を表示させてもよい。
【0071】
画像形成装置を、MFP50を用いて説明したことは一例であり、画像形成装置はFWを備え、このFWをアップデートできる装置であれば、プリンタや、スキャナ装置といった単体の機能のみを備える装置であってもよい。
【符号の説明】
【0072】
10…端末、12…端末側CPU、13…ユーザIF、30…サーバ、50,60,61…MFP