特許 7334445 デバイス制御プログラムおよび携帯端末装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-08-21

(45)【発行日】2023-08-29

(54)【発明の名称】デバイス制御プログラムおよび携帯端末装置

(51)【国際特許分類】

   G06F 8/65 20180101AFI20230822BHJP

   G06F 3/04817 20220101ALI20230822BHJP

   G06F 3/12 20060101ALI20230822BHJP

   G06F 8/61 20180101ALI20230822BHJP

   H04L 67/55 20220101ALI20230822BHJP

   H04M 1/00 20060101ALI20230822BHJP

   H04M 1/72418 20210101ALI20230822BHJP

   H04M 1/72469 20210101ALI20230822BHJP

【ＦＩ】

G06F8/65

G06F3/04817

G06F3/12 303

G06F3/12 329

G06F3/12 330

G06F3/12 392

G06F8/61

H04L67/55

H04M1/00 R

H04M1/72418

H04M1/72469

【請求項の数】 10

(21)【出願番号】P 2019069843

(22)【出願日】2019-04-01

(65)【公開番号】P2020170230

(43)【公開日】2020-10-15

【審査請求日】2022-03-25

(73)【特許権者】

【識別番号】000005267

【氏名又は名称】ブラザー工業株式会社

(74)【代理人】

【識別番号】110000578

【氏名又は名称】名古屋国際弁理士法人

(72)【発明者】

【氏名】曽根 竜彦

【審査官】北川 純次

(56)【参考文献】

【文献】特開２００５－１９６２６９（ＪＰ，Ａ）

【文献】特開２０１７－２２８２２８（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ ８／６０－８／６５

Ｇ０６Ｆ ３／０４８１７

Ｇ０６Ｆ ３／１２

Ｈ０４Ｌ ６７／５５

Ｈ０４Ｍ １／００

Ｈ０４Ｍ １／７２

(57)【特許請求の範囲】

【請求項1】

サーバとデータ通信可能な通信部と、
表示部と、
制御部と、
を備えた携帯端末装置における前記制御部が実行可能なデバイス制御プログラムであって、
前記制御部に、
画像データを処理するデバイスを制御するデバイス制御処理と、
前記通信部を介して前記サーバから受信されたアップデート通知を取得する通知取得処理であって、前記アップデート通知は、前記デバイス制御プログラムのアップデートが可能であることを示し且つ前記アップデートの緊急度を示す緊急度情報を含む、通知取得処理と、
前記通知取得処理で取得した前記アップデート通知について特定のユーザ報知条件が成立したか否か判断する条件判断処理であって、前記ユーザ報知条件は、前記アップデート通知に含まれている前記緊急度情報が示す前記緊急度に応じて成立する、条件判断処理と、
前記条件判断処理により前記ユーザ報知条件が成立したと判断した場合、前記アップデート通知を示すアップデートオブジェクトを前記表示部に表示するアップデート表示処理と、
を実行させ、
前記デバイス制御処理は、制御可能な複数種類の前記デバイスのうち制御対象に設定された少なくとも１つを制御する処理であり、
前記アップデート通知は、前記アップデートの影響を受ける前記デバイスであるアップデート対応デバイスを示す対応デバイス情報を含み、
前記ユーザ報知条件は、前記対応デバイス情報が示す前記アップデート対応デバイスの中に、前記制御対象に設定されている前記デバイスが含まれていること、を含む、
デバイス制御プログラム。

【請求項2】

請求項１に記載のデバイス制御プログラムであって、
前記携帯端末装置は、さらに、記憶部を備え、
前記デバイス制御プログラムは、前記制御部に、さらに、
前記デバイス制御処理が実行されることに応じて、そのデバイス制御処理において制御された前記デバイスとそのデバイス制御処理が実行された時期である制御実行時期とを対応付けた制御履歴情報を前記記憶部に記憶する履歴記憶処理、
を実行させ、
前記ユーザ報知条件は、前記記憶部に記憶されている前記制御履歴情報に含まれる前記デバイスのうちの、特定期間内に前記デバイス制御処理によって制御された前記デバイスの中に、前記対応デバイス情報が示す前記アップデート対応デバイスが含まれていること、を含む、
デバイス制御プログラム。

【請求項3】

請求項２に記載のデバイス制御プログラムであって、
前記緊急度情報は、異なる複数のレベルの前記緊急度のうちの１つを示し、
前記ユーザ報知条件は、前記緊急度情報が示す前記緊急度の前記レベルと、前記記憶部に記憶されている前記制御履歴情報において前記アップデート対応デバイスに対応付けられている前記制御実行時期と、に応じて成立する、
デバイス制御プログラム。

【請求項4】

請求項３に記載のデバイス制御プログラムであって、
前記記憶部には、前記レベルと前記制御実行時期との組み合わせに応じた異なる要報知レベルが規定された報知判定テーブルが記憶されており、
前記ユーザ報知条件は、前記報知判定テーブルにおいて規定されている各前記要報知レベルのうち、前記緊急度情報が示す前記緊急度の前記レベルと前記アップデート対応デバイスの前記制御実行時期との組合せに対応する前記要報知レベルが、規定レベル以上であること、を含む、
デバイス制御プログラム。

【請求項5】

請求項４に記載のデバイス制御プログラムであって、
前記報知判定テーブルは、前記レベルが高いほど前記要報知レベルが高くなるよう、且つ、直近の前記制御実行時期が、前記アップデート通知が取得された時に近いほど前記要報知レベルが高くなるように構成されている、
デバイス制御プログラム。

【請求項6】

サーバとデータ通信可能な通信部と、
表示部と、
制御部と、
を備えた携帯端末装置における前記制御部が実行可能なデバイス制御プログラムであって、
前記制御部に、
画像データを処理するデバイスを制御するデバイス制御処理と、
前記通信部を介して前記サーバから受信されたアップデート通知を取得する通知取得処理であって、前記アップデート通知は、前記デバイス制御プログラムのアップデートが可能であることを示し且つ前記アップデートの緊急度を示す緊急度情報を含む、通知取得処理と、
前記通知取得処理で取得した前記アップデート通知について特定のユーザ報知条件が成立したか否か判断する条件判断処理であって、前記ユーザ報知条件は、前記アップデート通知に含まれている前記緊急度情報が示す前記緊急度に応じて成立する、条件判断処理と、
前記条件判断処理により前記ユーザ報知条件が成立したと判断した場合、前記アップデート通知を示すアップデートオブジェクトを前記表示部に表示するアップデート表示処理と、
を実行させ、
前記アップデート通知は、前記デバイスが有する、前記デバイス制御処理によって制御可能な少なくとも１つの機能のうち、前記アップデートが実行されるまでは前記デバイス制御処理による制御を禁止させるべき機能を示す、禁止機能情報を含み、
前記デバイス制御プログラムは、前記制御部に、さらに、
前記通知取得処理で取得した前記アップデート通知に含まれている前記禁止機能情報が示す機能を前記デバイス制御処理によって制御することを禁止する禁止処理、
を実行させる、デバイス制御プログラム。

【請求項7】

請求項６に記載のデバイス制御プログラムであって、
前記携帯端末装置は、さらに、入力部を備え、
前記デバイス制御処理は、
前記少なくとも１つの機能のそれぞれに対応した機能オブジェクトを前記表示部に表示する機能オブジェクト表示処理と、
いずれか１つの前記機能オブジェクトが前記入力部を介して選択されることに応じて、前記デバイスにおけるその選択された前記機能オブジェクトに対応した機能を制御する選択機能制御処理と、
を含み、
前記デバイス制御プログラムは、前記制御部に、さらに、
前記機能オブジェクト表示処理により前記表示部に前記機能オブジェクトが表示されている状態において、前記デバイス制御処理による制御が禁止されている機能を視認可能な特定の禁止オブジェクトを前記表示部に表示する禁止オブジェクト表示処理、
を実行させる、デバイス制御プログラム。

【請求項8】

請求項１～請求項７のいずれか１項に記載のデバイス制御プログラムであって、
前記緊急度情報は、異なる複数のレベルの前記緊急度のうちの１つを示し、
前記ユーザ報知条件は、前記緊急度情報が示す前記緊急度の前記レベルに応じて成立する、
デバイス制御プログラム。

【請求項9】

サーバとデータ通信可能な通信部と、
デバイス制御プログラムが記憶された記憶部と、
表示部と、
制御部と、
を備えた携帯端末装置であって、
前記制御部は、前記記憶部に記憶されている前記デバイス制御プログラムに従って、
画像データを処理するデバイスを制御するデバイス制御処理と、
前記通信部を介して前記サーバから受信されたアップデート通知を取得する通知取得処理であって、前記アップデート通知は、前記デバイス制御プログラムのアップデートが可能であることを示し且つ前記アップデートの緊急度を示す緊急度情報を含む、通知取得処理と、
前記通知取得処理で取得した前記アップデート通知について特定のユーザ報知条件が成立したか否か判断する条件判断処理であって、前記ユーザ報知条件は、前記アップデート通知に含まれている前記緊急度情報が示す前記緊急度に応じて成立する、条件判断処理と、
前記条件判断処理により前記ユーザ報知条件が成立したと判断した場合、前記アップデート通知を示すアップデートオブジェクトを前記表示部に表示するアップデート表示処理と、
を実行し、
前記デバイス制御処理は、制御可能な複数種類の前記デバイスのうち制御対象に設定された少なくとも１つを制御する処理であり、
前記アップデート通知は、前記アップデートの影響を受ける前記デバイスであるアップデート対応デバイスを示す対応デバイス情報を含み、
前記ユーザ報知条件は、前記対応デバイス情報が示す前記アップデート対応デバイスの中に、前記制御対象に設定されている前記デバイスが含まれていること、を含む、
携帯端末装置。

【請求項10】

サーバとデータ通信可能な通信部と、
デバイス制御プログラムが記憶された記憶部と、
表示部と、
制御部と、
を備えた携帯端末装置であって、
前記制御部は、前記記憶部に記憶されている前記デバイス制御プログラムに従って、
画像データを処理するデバイスを制御するデバイス制御処理と、
前記通信部を介して前記サーバから受信されたアップデート通知を取得する通知取得処理であって、前記アップデート通知は、前記デバイス制御プログラムのアップデートが可能であることを示し且つ前記アップデートの緊急度を示す緊急度情報を含む、通知取得処理と、
前記通知取得処理で取得した前記アップデート通知について特定のユーザ報知条件が成立したか否か判断する条件判断処理であって、前記ユーザ報知条件は、前記アップデート通知に含まれている前記緊急度情報が示す前記緊急度に応じて成立する、条件判断処理と、
前記条件判断処理により前記ユーザ報知条件が成立したと判断した場合、前記アップデート通知を示すアップデートオブジェクトを前記表示部に表示するアップデート表示処理と、
を実行し、
前記アップデート通知は、前記デバイスが有する、前記デバイス制御処理によって制御可能な少なくとも１つの機能のうち、前記アップデートが実行されるまでは前記デバイス制御処理による制御を禁止させるべき機能を示す、禁止機能情報を含み、
前記制御部は、前記デバイス制御プログラムに従って、さらに、
前記通知取得処理で取得した前記アップデート通知に含まれている前記禁止機能情報が示す機能を前記デバイス制御処理によって制御することを禁止する禁止処理、
を実行する、携帯端末装置。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、プログラムのアップデートを報知する技術に関する。

【背景技術】

【0002】

特許文献１には、プログラムのアップデートに関するサーバからの通知に応じて、プログラムのアップデートが可能であることをユーザに報知するための画面を表示させるように構成された情報処理装置が開示されている。

【先行技術文献】

【特許文献】

【0003】

【文献】特開２０１６－２１２８５５号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

情報処理装置において、サーバからプログラムのアップデートの通知を受ける度にその内容にかかわらず一律にアップデートを促すメッセージを報知するようにすると、情報処理装置のユーザによっては煩わしく感じられる可能性がある。

【0005】

このような問題に対処するために、例えば、情報処理装置からサーバへアップデートが可能か否かの問い合わせが行われることに応じて、サーバから情報処理装置へアップデートが可能か否かの情報を通知し、その情報に基づいて情報処理装置がユーザへ報知を行うことが考えられる。

【0006】

しかし、アップデートの可否に関するユーザへの報知が、ユーザからサーバへの問い合わせに応じて行われるようにすると、仮に、プログラムに大きな問題が見つかって少しでも早くアップデートすべき状態が生じても、ユーザによっては、アップデートされない状態のままプログラムが長期間使用され続けてしまう可能性がある。

【0007】

本発明は上記課題に鑑みなされたものであり、プログラムのアップデートが可能であることのユーザへの報知を、ユーザの使用感が損なわれることを抑えつつ適切に行えるようにすることを目的とする。

【課題を解決するための手段】

【0008】

本発明のデバイス制御プログラムは、サーバとデータ通信可能な通信部と、表示部と、 制御部とを備えた携帯端末装置における、制御部が実行可能なプログラムである。
デバイス制御プログラムは、制御部に、デバイス制御処理と、通知取得処理と、条件判断処理と、アップデート表示処理とを実行させる。

【0009】

デバイス制御処理は、画像データを処理するデバイスを制御する処理である。
通知取得処理は、通信部を介してサーバから受信されたアップデート通知を取得する処理である。アップデート通知は、デバイス制御プログラムのアップデートが可能であることを示し、且つ緊急度情報を含む。緊急度情報は、アップデートの緊急度を示す。

【0010】

条件判断処理は、通知取得処理で取得したアップデート通知について、特定のユーザ報知条件が成立したか否か判断する処理である。ユーザ報知条件は、アップデート通知に含まれている緊急度情報が示す緊急度に応じて成立する。

【0011】

アップデート表示処理は、条件判断処理によりユーザ報知条件が成立したと判断した場合、アップデート通知を示すアップデートオブジェクトを表示部に表示する処理である。
このようなデバイス制御プログラムによれば、アップデート通知が取得された場合、そのアップデート通知を示すアップデートオブジェクトは、一律には表示されず、アップデートの緊急度に応じてユーザ報知条件が成立した場合に表示される。そのため、デバイス制御プログラムのアップデートが可能であることのユーザへの報知を、ユーザの使用感が損なわれることを抑えつつ適切に行うことが可能となる。

【図面の簡単な説明】

【0012】

【図1】実施形態の画像処理システムの概略構成を示す説明図である。

【図2】報知判定テーブルを示す説明図である。

【図3】アプリ起動画面を示す説明図である。

【図4】アップデートダイアログが表示された状態のアプリ起動画面の一例を示す説明図である。

【図5】機能ロックマークが表示された状態のアプリ起動画面の一例を示す説明図である。

【図6】通知情報受信処理のフローチャートである。

【図7】メイン処理のフローチャートである。

【発明を実施するための形態】

【0013】

以下、本発明の実施形態について、図面を参照しながら説明する。
（１）画像処理システムの概要
図１に示す本実施形態の画像処理システム１は、モバイル端末１０と、画像処理装置３０と、サーバ１００とを備える。モバイル端末１０は、無線によりネットワーク１５０に接続し、ネットワーク１５０を通じて、画像処理装置３０およびサーバ１００とデータ通信可能である。モバイル端末１０は、ネットワーク１５０を介さずに画像処理装置３０と無線通信可能であってもよい。

【0014】

ネットワーク１５０は、どのように構成されていてもよい。ネットワーク１５０は、例えば、インターネットと、無線中継装置とを備えていてもよい。この場合、サーバ１００と無線中継装置とがインターネットに接続されていてもよい。そして、モバイル端末１０が、無線中継装置と無線通信可能であって無線中継装置を介して画像処理装置３０およびサーバ１００とデータ通信可能であってもよい。また、画像処理装置３０は、無線中継装置と無線通信可能であって無線中継装置を介してモバイル端末１０およびサーバ１００とデータ通信可能であってもよい。画像処理装置３０は、有線にてインターネットと接続可能であってもよい。

【0015】

（２）画像処理装置の構成
図１に示す本実施形態の画像処理装置３０は、各種の画像データを各種の処理方法で処理可能に構成されている。画像処理装置３０は、例えばスキャン機能、印刷機能、コピー機能、ファクス機能などの、複数の機能を備えている。スキャン機能は、原稿の画像を読み取ってその読み取った画像の画像データを生成する機能である。印刷機能は、シート状の記録用紙へ、印刷用の画像データに基づく画像を印刷する機能である。コピー機能は、スキャン機能により読み取った画像を印刷機能により印刷する機能である。ファクス機能は、画像データを含むファクスデータの送受信を行う機能である。

【0016】

画像処理装置３０は、ＣＰＵ及びメモリを含む、マイクロコンピュータを備えている。メモリには、上述した各種機能を実現するための各種プログラムやデータ等が格納される。上述の各種機能は、メモリに格納された各種プログラムをＣＰＵが実行することにより実現される。なお、上述の各種機能は、プログラムの実行によって（即ち、ソフトウェア処理によって）実現されることに限るものではなく、その一部又は全部について、一つあるいは複数のハードウェアを用いて実現されてもよい。

【0017】

画像処理装置３０は、モバイル端末１０における後述するモバイルアプリ１２ｂによって制御される。即ち、モバイル端末１０のユーザは、モバイルアプリ１２ｂを利用することによって、モバイル端末１０から画像処理装置３０へ各種機能を指示することにより、その指示した機能を実行させることができる。

【0018】

（３）モバイル端末の構成
モバイル端末１０は、例えばスマートフォン、タブレット端末などの、無線通信可能な携帯型の通信端末である。図３～図５は、モバイル端末１０を正面視した状態を示している。

【0019】

モバイル端末１０は、制御部１１と、記憶部１２と、表示部１３と、入力部１４と、第１無線通信部１５と、第２無線通信部１６と、音声入出力部１７とを備える。これら各部は、バスライン２０を介して互いにデータの送受が可能に接続されている。

【0020】

制御部１１は、例えばＣＰＵを有する。記憶部１２は、例えばＲＯＭ、ＲＡＭ、ＮＶＲＡＭ、フラッシュメモリなどの半導体メモリを有する。即ち、本実施形態のモバイル端末１０は、ＣＰＵ及び半導体メモリを含むマイクロコンピュータを備えている。

【0021】

制御部１１は、非遷移的実体的記録媒体に格納されたプログラムを実行することにより各種機能を実現する。本実施形態では、記憶部１２が、プログラムを格納した非遷移的実体的記録媒体に該当する。なお、制御部１１により実現される各種機能は、プログラムの実行によって（即ち、ソフトウェア処理によって）実現することに限るものではなく、その一部又は全部について、一つあるいは複数のハードウェアを用いて実現してもよい。

【0022】

記憶部１２には、各種のソフトウェアやデータが記憶されている。本実施形態では、記憶部１２に、ソフトウェアとして、ＯＳ（オペレーティングシステムの略称）１２ａと、モバイルアプリ１２ｂとが記憶されている。モバイルアプリ１２ｂは、報知判定テーブル１２ｄ（図２参照）を含む。ＯＳ１２ａおよびモバイルアプリ１２ｂは、制御部１１を含むコンピュータシステムにインストールされる。また、記憶部１２には、モバイルアプリ１２ｂによって利用履歴情報１２ｃが記憶される。

【0023】

なお、以下の説明では、プログラムを実行する制御部１１（詳しくは制御部１１が有する不図示のＣＰＵ）のことを、単にプログラム名で記載する場合もある。例えば「モバイルアプリ１２ｂは」という記載が「モバイルアプリ１２ｂを実行するＣＰＵは」を意味する場合もある。

【0024】

モバイルアプリ１２ｂは、画像処理装置３０を制御できるように構成されたアプリケーションソフトである。モバイルアプリ１２ｂは、例えば、画像処理装置３０のベンダが管理するサーバからダウンロードすることが可能である。ユーザは、モバイル端末１０にモバイルアプリ１２ｂをダウンロードおよびインストールすることで、モバイルアプリ１２ｂを用いて、各種機能を実行することができる。

【0025】

モバイルアプリ１２ｂが実行可能な機能（以下、「モバイル機能」と称する）には、モバイルプリント機能と、モバイルスキャン機能と、モバイルコピープレビュー機能と、モバイルファクス機能と、モバイルステータス確認機能とが含まれる。

【0026】

モバイルプリント機能は、モバイル端末１０内の画像データをモバイル端末１０から画像処理装置３０へ送信することにより、その画像データが示す画像を画像処理装置３０の印刷機能で印刷させる機能である。

【0027】

モバイルスキャン機能は、原稿読取の指示、および原稿の読み取りに必要な各種設定項目の設定値を、モバイル端末１０から画像処理装置３０へ送信することにより、画像処理装置３０にスキャン機能を実行させて原稿の画像を読み取らせる機能である。

【0028】

モバイルコピープレビュー機能は、画像処理装置３０でコピー機能が実行される際に、読み取られた原稿の画像を示す画像データを含む印刷データを画像処理装置３０から受信して、その印刷データが示すプレビュー画像を表示部１３に表示する機能である。プレビュー画像は、画像データが示す画像が実際に記録用紙に印刷された状態を示す画像である。

【0029】

モバイルファクス機能は、モバイル端末１０内の画像データをモバイル端末１０から画像処理装置３０へ送信することにより、その画像データを含むファクス送信データを、ファクス機能を利用して、指定された送信先へファクス送信させる機能である。

【0030】

モバイルステータス確認機能は、モバイル端末１０から画像処理装置３０へ、画像処理装置３０における各種の状態を示すステータス情報を要求することにより、画像処理装置３０からステータス情報を受信し、その受信したステータス情報を表示部１３に表示する機能である。

【0031】

モバイルアプリ１２ｂは、画像処理装置３０との間で、モバイル機能に必要な各種データを送受信することにより、モバイル機能を実現する。
モバイルアプリ１２ｂは、制御可能なデバイスが特定の１機種に限定された専用アプリケーションであってもよいが、本実施形態では、図１に示した画像処理装置３０を含む、異なる複数の機種のデバイスを制御可能である。なお、本明細書において、「デバイス」とは、画像データを処理可能なデバイスを意味する。

【0032】

なお、モバイルアプリ１２ｂがモバイル機能を実行する際に制御対象のデバイスへ必要に応じて送信する各種コマンドは、制御対象の機種によって異なり得る。
表示部１３は、例えば液晶ディスプレイや有機ＥＬディスプレイなどの、画像を表示可能な表示デバイスを有する。

【0033】

入力部１４は、各種入力操作を受け付けるための入力用デバイスを有する。入力部１４が有する入力用デバイスには、タッチパネル１４ａが含まれる。タッチパネル１４ａは、表示部１３が有する表示デバイスにおける画像の表示領域に重畳配置される。

【0034】

タッチパネル１４ａは、表示デバイスにおける画像表示領域に対する、指示体による接触又は近接による指示操作を検出可能である。即ち、タッチパネル１４ａは、画像表示領域に対して指示体による指示操作が行われている場合に、その指示操作が行われている位置である指示位置を示す位置情報を出力可能に構成されている。本実施形態のタッチパネル１４ａは、指示体により指示操作が行われている間、位置情報を連続的又は周期的に出力するよう構成されている。

【0035】

なお、タッチパネル１４ａは、指示操作として接触のみ検出可能な構成であってもよいし、近接のみ検出可能な構成であってもよいし、接触及び近接の両方を検出可能な構成であってもよい。

【0036】

制御部１１は、タッチパネル１４ａから出力される位置情報を取得し、その取得した位置情報に基づいて、指示体の指示操作の有無、指示操作が行われている場合における指示位置、指示操作が行われている場合における指示体による少なくとも一種類の特定の操作を検出することができる。

【0037】

制御部１１が検出可能な特定の操作には、例えば、タップ、フリック、ドラッグなどが含まれる。タップは、指示体により指示操作が行われた後、同じ位置で指示体が離れる操作である。指示操作を行うことが可能な指示体の具体的態様は種々考えられ、例えば指先であってもよいし、スタイラスペンなどの特定の指示用デバイスであってもよい。

【0038】

第１無線通信部１５は、例えば、無線ＬＡＮによる無線通信を行うためのインタフェース部である。本実施形態では、第１無線通信部１５が行う無線ＬＡＮ通信は、ＩＥＥＥ８０２．１１ｂ／ｇ／ｎの規格に準拠した無線ＬＡＮ通信である。モバイル端末１０は、第１無線通信部１５を介して、画像処理装置３０と無線ＬＡＮ通信を行うことができる。

【0039】

なお、第１無線通信部１５は、例えば、Ｂｌｕｅｔｏｏｔｈ（以下、「ＢＴ」と略称する）の通信規格に従った無線通信方式による無線通信を行うための通信インタフェースを備えていてもよいし、Ｂｌｕｅｔｏｏｔｈ Ｌｏｗ Ｅｎｅｒｇｙ（以下、「ＢＬＥ」と略称する）の通信規格に従った無線通信方式による無線通信を行うための通信インタフェースを備えていてもよいし、ＮＦＣの通信規格に従った近距離無線通信を行うための通信インタフェースを備えていてもよいし、これら以外の他の通信方式による通信を行うための通信インタフェースを備えていてもよい。なお、「Ｂｌｕｅｔｏｏｔｈ」は登録商標である。また、「ＮＦＣ」は、「Ｎｅａｒ Ｆｉｅｌｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ」の略称である。

【0040】

上述のモバイル機能は、どの通信インタフェースを介して（つまりどの無線通信方式の無線通信を用いて）実行可能であってもよい。
第２無線通信部１６は、不図示の移動通信網を介した音声通話やデータ通信を行うためのインタフェース部である。第２無線通信部１６は、例えば、ＬＴＥ規格による無線通信を行うことが可能な構成であってもよい。なお、「ＬＴＥ」は、「Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ」の略称である。

【0041】

音声入出力部１７は、マイクやスピーカなどで構成された音声入出力用デバイスである。
（４）サーバの機能
サーバ１００は、例えば、モバイルアプリ１２ｂのベンダが管理するサーバである。サーバ１００は、例えばモバイルアプリ１２ｂにバグが発見されるなどして、モバイルアプリ１２ｂがベンダによって改訂されると、モバイルアプリ１２ｂがインストールされた各種情報処理装置へ、その改訂された新たなバージョンのモバイルアプリ１２ｂにアップデートすることを案内するアップデート通知を送信する。

【0042】

本実施形態のサーバ１００は、例えば、プッシュ通知にてアップデート通知を送信する。プッシュ通知とは、モバイルアプリ１２ｂが起動されているときはもちろん、起動されていない状態においても、モバイルアプリ１２ｂに対して通知を送ることを可能とするフレームワークを意味する。本実施形態では、サーバ１００からのモバイルアプリ１２ｂのアップデート通知がモバイル端末１０で受信されると、まずＯＳ１２ａにてそのアップデート通知が処理され、ＯＳ１２ａからモバイルアプリ１２ｂへ引き渡される。

【0043】

（５）モバイルアプリ
（５－１）モバイルアプリの機能の概要
本実施形態では、モバイルアプリ１２ｂにデバイスを登録することによって、その登録したデバイスを制御対象としたモバイル機能を利用可能となる。よって、モバイルアプリ１２ｂに画像処理装置３０を登録することで、モバイル端末１０からモバイルアプリ１２ｂにて画像処理装置３０を制御対象としたモバイル機能を利用することができる。以下、モバイルアプリ１２ｂに画像処理装置３０が登録され、画像処理装置３０が制御対象として設定されていることを想定して説明する。

【0044】

モバイルアプリ１２ｂを起動すると、表示部１３に、図３に例示するアプリ起動画面４０が表示される。アプリ起動画面４０には、プリントアイコン４１と、スキャンアイコン４２と、コピープレビューアイコン４３と、ファクスアイコン４４と、ステータスアイコン４５とが含まれる。

【0045】

図３に例示するアプリ起動画面４０に表示されている「ＭＦＰ－ＡＢＣ」は、画像処理装置３０の機種を示す。なお、モバイルアプリ１２ｂには、複数のデバイスを登録することができる。複数のデバイスが登録されている場合、例えばユーザが何れか１つのデバイスを制御対象に選択することで、その選択したデバイスを対象としたモバイル機能を利用できるようになる。なお、デバイスの登録を要することは一例であって、登録しなくても、あるいは登録とは異なる特定の設定等を行うことによって、特定のデバイスを選択的に制御できてもよい。

【0046】

プリントアイコン４１には、モバイルプリント機能が対応付けられている。モバイルアプリ１２ｂは、プリントアイコン４１が選択操作（例えばタップ）されると、モバイルプリント機能を実行する。具体的には、モバイルアプリ１２ｂは、印刷する画像をユーザに選択させるための不図示の画像選択画面を表示部１３に表示する。画像選択画面においてユーザにより画像が選択されると、表示部１３に不図示のプレビュー画面を表示する。プレビュー画面が表示されている状態でユーザにより印刷実行の指示操作がなされると、選択された画像を示す画像データを含む印刷コマンドを画像処理装置３０に送信する。これにより、選択された画像が画像処理装置３０で印刷される。

【0047】

スキャンアイコン４２には、モバイルスキャン機能が対応付けられている。モバイルアプリ１２ｂは、スキャンアイコン４２が選択操作されると、モバイルスキャン機能を実行する。具体的には、モバイルアプリ１２ｂは、不図示のスキャン設定画面を表示部１３に表示する。スキャン設定画面には、画像処理装置３０における原稿の読み取りに必要な各種のスキャン設定項目の設定値が表示される。ユーザは、スキャン設定画面を見ることによって、どのような設定値でスキャンが行われるかを知ることができる。また、ユーザは、スキャン設定画面に対する特定の設定変更操作を行うことで、設定値を個別に変更することができる。スキャン設定画面が表示されている状態でユーザによりスキャン実行の指示操作がなされると、各スキャン設定項目の現在設定されている設定値を含むスキャンコマンドを画像処理装置３０に送信する。これにより、画像処理装置３０において、その送信した設定値を用いて原稿の画像が読み取られる。

【0048】

コピープレビューアイコン４３には、モバイルコピープレビュー機能が対応付けられている。モバイルアプリ１２ｂは、コピープレビューアイコン４３が選択操作されると、前述のモバイルコピープレビュー機能を実行する。

【0049】

ファクスアイコン４４には、モバイルファクス機能が対応付けられている。モバイルアプリ１２ｂは、ファクスアイコン４４が選択操作されると、前述のモバイルファクス機能を実行する。

【0050】

ステータスアイコン４５には、モバイルステータス確認機能が対応付けられている。モバイルアプリ１２ｂは、ステータスアイコン４５が選択操作されると、前述のモバイルステータス確認機能を実行する。

【0051】

モバイルアプリ１２ｂは、さらに、利用履歴保存機能と、アップデート制御機能とを備えている。
利用履歴保存機能は、モバイル機能を実行した場合に記憶部１２に利用履歴情報１２ｃを保存する機能である。利用履歴情報１２ｃは、実行したモバイル機能における制御対象のデバイスを示す利用デバイス情報と、そのモバイル機能を実行した時期を示す制御実行時期情報とが対応付けられた情報である。

【0052】

制御実行時期情報は、モバイル機能を実行した時期を示すどのような情報であってもよい。制御実行時期情報は、例えば、モバイル機能を実行した日、月日、年月日、モバイル機能を実行した日を含む一定範囲の期間（例えば〇月の第△週）などであってもよい。また、制御実行時期情報は、どのような方法で取得してもよい。本実施形態では、例えば、モバイル端末１０にリアルタイムクロックが搭載されており、そのリアルタイムクロックからの出力信号に基づいて、制御実行時期情報を取得する。

【0053】

アップデート制御機能は、サーバ１００からモバイルアプリ１２ｂのアップデート通知を受信した場合に、そのアップデート通知の内容に応じてモバイルアプリ１２ｂをアップデートする機能である。本実施形態では、前述の通り、アップデート通知はプッシュ通知にてサーバ１００から送信され、ＯＳ１２ａからモバイルアプリ１２ｂへ引き渡される。

【0054】

ベンダ等によるモバイルアプリ１２ｂの改訂は、種々の要因で行われる。例えば、制御可能な全てのデバイスの制御にかかわるプログラムモジュール部分にバグが発見されてそのバグが修正されることもあれば、特定のデバイスの制御のみにかかわるプログラムモジュール部分あるいはコマンド等にバグが発見されてそのバグが修正されることもある。

【0055】

特定のデバイスの制御のみにかかわる改訂が施された改訂版については、その特定のデバイスを使用しないユーザにとっては、必ずしもその改訂版にアップデートする必要はない。

【0056】

さらに、仮に、ユーザが利用しているデバイスの制御に関係するプログラムモジュール部分あるいはコマンド等にかかわる改訂が行われたとしても、必ずしもすぐにその改訂版にアップデートしなければならないとは限らない。例えば、アップデートしなくても問題は生じ得るかも知れないがその問題は一般的に許容し得る範囲内のものである場合は、ユーザによっては、アップデートの手間を考慮して、あえてアップデートせずに放置することを望むかもしれない。

【0057】

つまり、アップデート通知が受信されたとしても、その内容あるいはユーザによるモバイルアプリ１２ｂの使用状況等によっては、必ずしもそのアップデート通知をユーザに報知する必要がない場合があり得る。

【0058】

そこで、本実施形態のモバイルアプリ１２ｂは、アップデート通知を受けた場合、アップデート通知を受けた旨のユーザへの報知を無条件に行わず、後述するように、ユーザ報知条件を満たした場合にユーザへ報知する。

【0059】

（５－２）アップデート通知の概要
サーバ１００から通知されるモバイルアプリ１２ｂのアップデート通知は、モバイルアプリ１２ｂのアップデートが可能であることを示す情報と、通知種別と、緊急度レベルと、対応デバイス情報と、ダイアログ表示情報と、禁止機能情報と、バージョン情報とを含む。

【0060】

通知種別及び緊急度レベルは、アップデートの緊急度を示す。通知種別は、複数種類の種別のうちの１つを示す。通知種別には、例えば、アップデートの緊急性を要しない「通常バグ」と、アップデートの緊急性を要する「緊急バグ」とがある。本実施形態のアップデート通知には、「通常バグ」および「緊急バグ」のどちらか一方が通知種別として含まれる。

【0061】

緊急度レベルは、通知種別が「緊急バグ」のときに通知される。本実施形態では、緊急度レベルとして、例えば、「高」、「中」、「低」の３種類のうちのいずれかが含まれる。「高」は、アップデートの緊急性が最も高いこと、即ち少しでも早くアップデートすることが強く推奨されることを示す。「中」は、「高」よりも相対的にアップデートの緊急性が低いことを示す。「低」は、「中」よりも相対的にアップデートの緊急性が低いことを示す。

【0062】

つまり、通知種別が「緊急バグ」の場合は、そのこと自体が、なるべく早くアップデートすべきであることを示しているが、その「緊急バグ」がさらに複数の緊急度レベルに分類されて通知される。なお、通知種別が「通常バグ」のアップデートは「緊急バグ」よりも緊急性が低い。そのため、「通常バグ」は、前述の「低」よりも緊急性が低い緊急度レベル（例えば「極低」）を有しているとみなすことができる。

【0063】

対応デバイス情報は、モバイルアプリ１２ｂによって制御可能な各種デバイスのうち、アップデートによって改訂されるプログラムモジュール部分の影響を受けるデバイスであるアップデート対応デバイスを示す情報である。アップデート対応デバイスは、モバイルアプリ１２ｂがアップデートされることによって、モバイルアプリ１２ｂを用いて制御される際にそのアップデートの影響を受けるデバイスである。例えば、ある特定のデバイスの制御のみにかかわるプログラムモジュール部分のみが改訂された改訂版へのアップデートを通知するアップデート通知においては、対応デバイス情報として、その特定のデバイス（即ちアップデート対応デバイス）を示す対応デバイス情報が含まれる。また例えば、モバイルアプリ１２ｂが制御可能な全ての機種に共通して関係するアップデートを通知するアップデート通知においては、対応デバイス情報として、その全ての機種のデバイスを示す対応デバイス情報が含まれる。この場合、全ての機種のデバイスがアップデート対応デバイスである。

【0064】

ダイアログ表示情報は、後述するアップデートダイアログ５０（図４参照）を表示させるための情報である。アップデートダイアログ５０は、サーバ１００からアップデート通知を受けたことをユーザに報知するための情報である。

【0065】

図４に例示するアップデートダイアログ５０は、アップデートメッセージ５１と、インストールボタン５２と、閉じるボタン５３とを含む。アップデートメッセージ５１は、アップデートが可能であることやアップデートの重要性などをユーザに知らせるためのメッセージである。インストールボタン５２および閉じるボタン５３は、アップデートメッセージ５１の下に配置される。インストールボタン５２と閉じるボタン５３とは、左右方向に隣接配置され、インストールボタン５２が右側に配置される。

【0066】

このようなアップデートダイアログ５０は、アップデート通知に含まれているダイアログ情報に基づいて生成され、表示される。即ち、ダイアログ情報には、アップデートメッセージ５１、インストールボタン５２および閉じるボタン５３のそれぞれに含まれるテキストや、各ボタン５１，５２，５３の配置位置や大きさなどを示す情報などが含まれる。モバイルアプリ１２ｂは、アップデート通知に含まれているダイアログ情報に基づいてアップデートダイアログ５０を生成し、表示する。

【0067】

禁止機能情報は、モバイルアプリ１２ｂによって実行可能な前述の各種機能のうち、アップデートによって改訂されるプログラムモジュール部分の影響を受ける機能を示す情報である。本実施形態では、モバイルアプリ１２ｂのうち特定の機能に関わるプログラムモジュール部分の改訂が必要になった場合、その改訂が施された改訂版にアップデートされるまではユーザがその特定の機能を使用できないようにするために、その特定の機能を示す禁止機能情報がアップデート通知に含まれる。

【0068】

モバイルアプリ１２ｂは、禁止機能情報を含むアップデート通知を受信した場合、そのアップデート通知に対応したアップデートが行われるまでは、そのアップデート通知に含まれる禁止機能情報が示す機能（以下、「禁止機能」と称する）を無効にする。具体的には、図５に例示するように、禁止機能に対応したアイコンに、機能ロックマーク６０を重畳表示する。

【0069】

図５は、モバイルプリント機能およびモバイルファクス機能にかかわるプログラムモジュール部分を改訂するアップデート通知を受けたことに応じて、プリントアイコン４１およびファクスアイコン４４に機能ロックマーク６０が重畳表示されている例を示す。この例では、アップデート通知において、禁止機能情報としてモバイルプリント機能およびモバイルファクス機能が禁止機能として含まれている。モバイルアプリ１２ｂは、その禁止機能情報に基づいて、プリントアイコン４１およびファクスアイコン４４に機能ロックマーク６０を重畳表示する。

【0070】

機能ロックマーク６０が表示されたアイコンは、ユーザによる選択操作が無効にされる。つまり、図５の例では、プリントアイコン４１およびファクスアイコン４４に対する選択操作は無効にされ、選択操作されてもモバイル機能は実行されない。

【0071】

なお、機能ロックマーク６０は、どのような形態の画像であってもよいし、どこに表示されてもよい。機能ロックマーク６０は、対応するアイコンに重畳表示されなくてもよい。
バージョン情報は、改訂版のモバイルアプリ１２ｂのバージョンを示す。

【0072】

（５－３）ユーザ報知条件
モバイルアプリ１２ｂは、ユーザによるアップデート報知設定を受け付ける。本実施形態では、ユーザは、アップデート報知設定を「常時」、「オフ」および「緊急時のみ」のうちのいずれかに設定可能である。

【0073】

アップデート報知設定が「常時」に設定された場合は、モバイルアプリ１２ｂは、アップデート通知を受ける度に、その内容にかかわらず、例えば図４に例示したアップデートダイアログ５０を表示すること等によって、アップデート通知を受けたことをユーザに報知する。

【0074】

アップデートダイアログ５０が表示されると、ユーザは、アップデートが可能であることや、そのアップデートの重要性などを認識できる。アップデートダイアログ５０が表示されている状態において、閉じるボタン５３が選択操作されると、アップデートは行われず、アップデートダイアログ５０が消去される。インストールボタン５２が選択操作されると、モバイルアプリ１２ｂのアップデートが行われる。本実施形態では、例えば、モバイルアプリ１２ｂがサーバ１００にアクセスし、モバイルアプリ１２ｂの改訂版をダウンロードする。そして、その改訂版にアップデートする。

【0075】

なお、サーバ１００は、アップデート通知を送信する際に改訂版も送信するように構成されていてもよい。つまり、モバイル端末１０でアップデート通知が受信される際はあわせて改訂版も受信されてもよい。この場合、アップデートダイアログ５０におけるインストールボタン５２が選択操作された場合は、すでに受信済みの改訂版にアップデートする。また、改訂版へのアップデートは、モバイルアプリ１２ｂ自身が行ってもよいし、たとえば改訂版にインストーラが含まれていてそのインストーラが既存のモバイルアプリ１２ｂを改訂版にアップデートするようにしてもよい。

【0076】

アップデート報知設定が「オフ」に設定されている場合は、モバイルアプリ１２ｂは、アップデート通知を受けてもユーザへの報知を行わない。
アップデート報知設定が「緊急時のみ」に設定されている場合は、モバイルアプリ１２ｂは、アップデート通知を受けたときにユーザ報知条件が成立するか否か判断し、ユーザ報知条件が成立する場合に、アップデートダイアログ５０を表示することによってユーザに報知する。

【0077】

本実施形態のユーザ報知条件は、以下の条件Ａ～条件Ｄを全て満たす場合に成立する。
条件Ａ：通知種別が「緊急バグ」であること。
条件Ｂ：現在インストールされているモバイルアプリ１２ｂのバージョンが、旧バージョン、即ち、アップデート通知に含まれているバージョン情報が示すバージョンよりも古いこと。
条件Ｃ：デバイス要件を満たすこと。具体的には、アップデート対応デバイスがモバイルアプリ１２ｂに登録されていて、且つ、緊急度レベルが「中」または「低」の場合においてアップデート対応デバイスが利用履歴情報１２ｃに含まれていること。
条件Ｄ：要報知レベルが規定レベル（例えば２）以上であること。

【0078】

条件Ｄを判断するために、モバイルアプリ１２ｂは、図２に例示する報知判定テーブル１２ｄを有する。報知判定テーブル１２ｄには、緊急度レベルと、特定期間内における利用履歴の有無との組合せに応じた、異なる複数の要報知レベルが規定されている。

【0079】

例えば、緊急度レベルが「高」に対しては、利用履歴の有無に関係なく要報知レベルが「３」に設定されている。
緊急度レベルが「中」に対しては、アップデート通知が通知された時以前の第１の特定期間内にアップデート対応デバイスの利用履歴がある場合は要報知レベルが「３」に設定され、第１の特定期間内にアップデート対応デバイスの利用履歴がない場合は要報知レベルが「２」に設定されている。第１の特定期間は、本実施形態では、アップデート通知が通知された時からその１年前までの期間である。

【0080】

緊急度レベルが「低」に対しては、アップデート通知が通知された時以前の第２の特定期間内にアップデート対応デバイスの利用履歴がある場合は要報知レベルが「３」に設定されている。第２の特定期間は、本実施形態では、アップデート通知が通知された時からその１ヶ月前までの期間である。また、第１の特定期間内にアップデート対応デバイスの利用履歴がある場合は要報知レベルが「２」に設定され、第１の特定期間内にアップデート対応デバイスの利用履歴がない場合は要報知レベルが「１」に設定されている。

【0081】

つまり、本実施形態の報知判定テーブル１２ｄは、緊急度レベルが高いほど要報知レベルが高くなるよう、且つ、直近の制御実行時期が、アップデート通知が通知された時に近いほど、要報知レベルが高くなるように構成されている。そして、前述の条件Ｄは、この報知判定テーブル１２ｄを参照して判断される。

【0082】

（６）通知情報受信処理
次に、モバイル端末１０の制御部１１がモバイルアプリ１２ｂに従って実行する通知情報受信処理について、図６を参照して説明する。通知情報受信処理は、モバイルアプリ１２ｂに含まれる各種処理の中の１つである。制御部１１は、モバイルアプリ１２ｂを実行中、サーバ１００からのアップデート通知をＯＳ１２ａを介して受けると、通知情報受信処理を実行する。

【0083】

制御部１１は、通知情報受信処理を開始すると、Ｓ１１０で、ＯＳ１２ａから引き渡されたアップデート通知Ｄｕｐを記憶部１２に保存する。Ｓ１２０では、アップデート報知設定の設定値を判断する。アップデート報知設定が「オフ」に設定されている場合は、通知受信処理を終了する。アップデート報知設定が「常時」に設定されている場合は、Ｓ２１０に移行する。

【0084】

Ｓ２１０では、アップデート要求処理を実行する。具体的には、アップデートフラグをオンに設定する。Ｓ２２０では、アップデート通知Ｄｕｐから禁止機能情報を取得する。Ｓ２３０では、禁止機能情報に禁止機能が含まれているか否か判断する。禁止機能が含まれていない場合は通知情報受信処理を終了する。禁止機能が含まれている場合は、Ｓ２４０で、禁止機能設定処理を実行する。具体的には、禁止機能フラグをオンに設定する。

【0085】

Ｓ１２０で、アップデート報知設定が「緊急時のみ」に設定されている場合は、Ｓ１３０に移行する。Ｓ１３０では、アップデート通知Ｄｕｐから通知種別を取得する。Ｓ１４０では、取得した通知種別が「緊急バグ」であるか否か判断する。このＳ１４０の判断は、前述の条件Ａの判断に対応する。「緊急バグ」ではない場合は通知情報受信処理を終了する。「緊急バグ」である場合は、Ｓ１５０に移行する。

【0086】

Ｓ１５０では、アップデート通知Ｄｕｐからバージョン情報を取得する。Ｓ１６０では、取得したバージョン情報に基づき、現在インストールされているモバイルアプリ１２ｂのバージョンが旧バージョンであるか否か判断する。このＳ１６０の判断は、前述の条件Ｂの判断に対応する。旧バージョンではない場合、即ちすでに最新の改訂版にアップデートされている場合は、通知情報受信処理を終了する。旧バージョンである場合は、Ｓ１７０に移行する。

【0087】

Ｓ１７０では、利用履歴情報１２ｃを取得する。Ｓ１８０では、デバイス要件が成立するか否か判断する。このＳ１８０の判断は、前述の条件Ｃに対応する。デバイス要件が成立しない場合、即ち、アップデート対応デバイスがモバイルアプリ１２ｂに登録されていないか、もしくは緊急度レベルが「中」または「低」であってアップデート対応デバイスが利用履歴情報１２ｃに含まれていない場合は、通知情報受信処理を終了する。デバイス要件が成立する場合は、Ｓ１９０に移行する。

【0088】

Ｓ１９０では、図２の報知判定テーブルを参照して、要報知レベルを算出する。例えば、アップデート通知Ｄｕｐにおける緊急度レベルが「中」であって、アップデート対応デバイスを直近１年以内にモバイルアプリ１２ｂから利用している場合は、要報知レベルは「３」となる。

【0089】

Ｓ２００では、Ｓ１９０で算出した要報知レベルが規定レベル（例えば２）以上であるか否か判断する。要報知レベルが規定レベルより小さい場合は通知情報受信処理を終了する。要報知レベルが規定レベル以上の場合は、Ｓ２１０に移行し、その結果、アップデートフラグがオンに設定される。

【0090】

（７）メイン処理
次に、モバイル端末１０の制御部１１がモバイルアプリ１２ｂに従って実行するメイン処理について、図７を参照して説明する。メイン処理は、モバイルアプリ１２ｂに含まれる各種処理の中の１つである。制御部１１は、ユーザによる特定の起動操作が行われることに応じて、メイン処理を実行する。なお、図６の通知情報受信処理は、メイン処理と並行して（即ちマルチタスクとして）実行される。

【0091】

制御部１１は、メイン処理を開始すると、Ｓ３１０で、アプリ起動画面４０を表示部１３に表示する。Ｓ３２０では、機能禁止フラグがオンに設定されているか否か判断する。機能禁止フラグがオフに設定されている場合はＳ３４０に移行する。機能禁止フラグがオンに設定されている場合はＳ３３０に移行する。Ｓ３３０では、アプリ起動画面４０における、禁止機能に対応したアイコンに、機能ロックマーク６０を重畳表示する。Ｓ３３０の処理後はＳ３４０に移行する。

【0092】

Ｓ３４０では、アップデートフラグがオンに設定されているか否か判断する。アップデートフラグがオフに設定されている場合は、Ｓ３５０に移行する。Ｓ３５０では、アプリ起動画面４０におけるいずれかのアイコンに対してユーザの選択操作が行われたか否か判断する。アイコンの選択操作が行われていない場合は、Ｓ３４０に移行する。アイコンの選択操作が行われた場合は、Ｓ３６０に移行する。

【0093】

Ｓ３６０では、アップデート通知Ｄｕｐに含まれている禁止機能情報に基づき、選択操作されたアイコンに対応する機能が禁止機能であるか否か判断する。禁止機能である場合は、Ｓ３７０でエラー処理を行って、Ｓ３１０に移行する。エラー処理は、選択操作されたアイコンに対応した機能を実行できないことをユーザに知らせる処理である。Ｓ３６０で、禁止機能ではない場合は、Ｓ３８０に移行する。Ｓ３８０では、選択操作されたアイコンに対応した機能を実行する。Ｓ３９０では、今回実行した機能の利用履歴情報１２ｃを記憶部１２に保存する。Ｓ３９０の処理後はＳ３１０に移行する。

【0094】

Ｓ３４０で、アップデートフラグがオンに設定されている場合は、Ｓ４００に移行する。Ｓ４００では、アップデート通知Ｄｕｐからダイアログ表示情報を取得する。Ｓ４１０では、取得したダイアログ表示情報に基づいてアップデートダイアログ５０を生成する。Ｓ４２０では、Ｓ４１０で生成したアップデートダイアログ５０を、アプリ起動画面４０内に重畳表示する（図４参照）。

【0095】

Ｓ４３０では、アップデートダイアログ５０におけるインストールボタン５２および閉じるボタン５３のどちらが選択操作されたか判断する。閉じるボタン５３が選択操作された場合は、Ｓ４６０で、アップデートフラグをオフに設定して、Ｓ３１０に移行する。この場合、アップデートダイアログ５０が消去されたアプリ起動画面４０が表示される。

【0096】

Ｓ４３０で、インストールボタン５２が選択操作された場合は、Ｓ４４０に移行する。Ｓ４４０では、インストール処理を行う。具体的には、サーバ１００へアクセスして、アップデート通知Ｄｕｐに対応した改訂版のモバイルアプリ１２ｂを要求し、その改訂版をダウンロードする。そして、ダウンロードした改訂版をインストールすることにより、モバイルアプリ１２ｂをその改訂版にアップデートする。アップデート終了後は、Ｓ４５０で禁止機能フラグをオフにして、Ｓ４６０に移行する。

【0097】

（８）実施形態の効果
以上説明した実施形態によれば、以下の効果を奏する。
即ち、本実施形態のモバイルアプリ１２ｂは、アップデート報知設定が「緊急時のみ」に設定されている場合において、アップデート通知を受けた場合、そのアップデート通知について無条件にユーザに報知せず、ユーザ報知条件が成立した場合にユーザに報知する。そのため、モバイルアプリ１２ｂのアップデートが可能であることのユーザへの報知を、ユーザの使用感が損なわれることを抑えつつ適切に行うことができる。

【0098】

ユーザ報知条件には、前述の条件Ａ～条件Ｄが含まれる。
ユーザ報知条件が条件Ａを含んでいることにより、通知種別が「通常バグ」である場合はユーザに報知されない。つまり、緊急性がある場合に報知され、緊急性がない場合は報知されない。そのため、緊急性がない通知が逐一ユーザに報知されることによってユーザの使用感が低下することが抑制される。

【0099】

しかも、通知種別が「緊急バグ」である場合、即ち緊急性がある場合においても、必ずユーザに報知されるわけではない。本実施形態では、「緊急バグ」については緊急度のレベルがより細分化して通知される。そして、緊急度レベルに応じて要報知レベルが算出され、要報知レベルに基づいてユーザへの報知の要否が決定される。そのため、ユーザへの報知の必要性を、アップデートの緊急度に応じてより適切に決定することができる。

【0100】

さらに、本実施形態では、アップデートの緊急度に加えて、ユーザの利用履歴も考慮して、報知の要否が決定される。また、その利用履歴は、図２に例示したように、緊急度レベルと組み合わせて判断される。そのため、緊急度と利用履歴の双方を勘案してより適切にユーザへの報知の要否が決定される。

【0101】

また、本実施形態では、アップデート通知におけるアップデート対応デバイスがモバイルアプリ１２ｂに登録されていない場合は、ユーザに報知されない。モバイルアプリ１２ｂに登録されていないデバイスに関係したアップデートは必ずしも必要ではない。そのため、そのような場合はユーザに報知しないようにすることで、不要な報知によるユーザの使用感の低下を抑制することができる。

【0102】

なお、本実施形態において、画像処理装置３０はデバイスの一例に相当する。モバイル端末１０は携帯端末装置の一例に相当する。モバイルアプリ１２ｂはデバイス制御プログラムの一例に相当する。第１無線通信部１５は通信部の一例に相当する。プリントアイコン４１、スキャンアイコン４２、コピープレビューアイコン４３、ファクスアイコン４４およびステータスアイコン４５の各々は機能オブジェクトの一例に相当する。アップデートダイアログ５０はアップデートオブジェクトの一例に相当する。 機能ロックマーク６０は禁止オブジェクトの一例に相当する。

【0103】

また、Ｓ１１０の処理は通知取得処理の一例に相当する。Ｓ１２０，Ｓ１４０，Ｓ１６０，Ｓ１８０，Ｓ２００の処理の各々は条件判断処理の一例に相当する。Ｓ２４０およびＳ３７０の処理は禁止処理の一例に相当する。Ｓ３３０の処理は禁止オブジェクト表示処理の一例に相当する。Ｓ３８０の処理はデバイス制御処理および選択機能制御処理の一例に相当する。Ｓ４２０の処理はアップデート表示処理の一例に相当する。

【0104】

（９）他の実施形態
以上、本発明の実施形態について説明したが、本発明は上述の実施形態に限定されることなく、種々変形して実施することができる。

【0105】

（９－１）ユーザ報知条件は、どのような条件であってもよい。例えば、前述の条件Ａ～条件Ｄのうちのいずれか１つのみ或いは特定の２つ以上のみ、を含んでいてもよい。また例えば、条件Ａ～条件Ｄのうちのいずれか１つ以上と、条件Ａ～条件Ｄとは異なる他の１つ以上の条件と、を含んでいてもよい。

【0106】

また例えば、緊急度レベルと利用履歴との組合せに基づく条件Ｄについては、報知判定テーブルを用いる方法とは異なる方法で判断するようにしてもよい。例えば、緊急度レベルにおける「高」、「中」、「低」それぞれに緊急度レベル係数ａ１，ａ２，ａ３（ａ１＞ａ２＞ａ３）を設定し、利用履歴に関しても、異なる特定期間Ｔ１，Ｔ２，Ｔ３のそれぞれに利用履歴係数ｂ１，ｂ２，ｂ３（ｂ１＞ｂ２＞ｂ３）を設定してもよい。なお、特定期間Ｔ１は例えば通知時の直近１週間以内、特定期間Ｔ２は例えば通知時の直近１ヶ月以内、特定期間Ｔ３は例えば通知時の直近１年以内、であってもよい。そして、緊急度レベル係数と利用履歴係数とを乗算し、その乗算値が閾値以上の場合に、ユーザに報知するようにしてもよい。具体例を挙げると、例えば、緊急度レベルが「中」で、直近１週間以内にアップデート対応デバイスの利用履歴がある場合、緊急度レベル係数ａ２と利用履歴係数ｂ１を乗算する。そして、その乗算結果が閾値以上の場合、ユーザに報知する。

【0107】

（９－２）緊急度レベルは、２段階あるいは４段階以上に設定されていてもよい。利用履歴を区分する特定期間についても、上記実施形態の１年以内あるいは１ヶ月以内とは異なる期間であってもよい。

【0108】

さらに、報知判定テーブルは、図２に例示した報知判定テーブルとは異なっていても良い。例えば、緊急度レベル「高」においても、利用履歴に応じて要報知レベルが複数種類設定されてもよい。

【0109】

（９－３）サーバ１００からモバイルアプリ１２ｂへのアップデート通知は、プッシュ通知とは異なる方法で通知されてもよい。
（９－４）アップデートダイアログ５０（図４参照）はどのような内容であってもよいし、画面内のどこにどのように表示されてもよい。

【0110】

また、アップデート通知をユーザに報知する方法は、アップデートダイアログ５０を表示する方法とは異なる方法であってもよい。例えば、音声でユーザに報知してもよい。
（９－５）上記実施形態における１つの構成要素が有する複数の機能を、複数の構成要素によって実現したり、１つの構成要素が有する１つの機能を、複数の構成要素によって実現したりしてもよい。また、複数の構成要素が有する複数の機能を、１つの構成要素によって実現したり、複数の構成要素によって実現される１つの機能を、１つの構成要素によって実現したりしてもよい。また、上記実施形態の構成の一部を省略してもよい。また、上記実施形態の構成の少なくとも一部を、他の上記実施形態の構成に対して付加又は置換してもよい。

【符号の説明】

【0111】

１…画像処理システム、１０…モバイル端末、１１…制御部、１２…記憶部、１２ｂ…モバイルアプリ、１２ｃ…利用履歴情報、１２ｄ…報知判定テーブル、１３…表示部、１４…入力部、１５…第１無線通信部、１６…第２無線通信部、１７…音声入出力部、３０…画像処理装置、４０…アプリ起動画面、４１…プリントアイコン、４２…スキャンアイコン、４３…コピープレビューアイコン、４４…ファクスアイコン、４５…ステータスアイコン、５０…アップデートダイアログ、５１…アップデートメッセージ、５２…インストールボタン、５３…閉じるボタン、６０…機能ロックマーク、１００…サーバ、１５０…ネットワーク。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】