JP6281440B2 - 情報処理端末、及び更新制御プログラム - Google Patents

Description

本発明は、現在利用しているソフトウェアにおいて、新しいバージョンが利用可能となった場合には、当該ソフトウェアを自動的に新しいバージョンへと更新する情報処理端末、及び更新制御プログラムに関する。

従来、現在利用しているソフトウェアの新しいバージョンが通信ネットワークを介して利用可能となった場合には、その新しいバージョンのソフトウェアを自動的にダウンロードし、更新を実施する情報処理端末が知られている。

例えば特許文献１には、情報処理端末の起動時に、現在利用しているソフトウェアのバージョン情報（例えばバージョン番号）と、当該ソフトウェアの最新バージョンのバージョン情報とを比較し、それらが異なっている場合には、当該ソフトウェアの更新を実施する方法が開示されている。

この特許文献１の方法によれば、ソフトウェアは自動的に最新バージョンに更新されていくため、ユーザは、ソフトウェアを更新するための操作を実施する必要がない。すなわち、ユーザは、そのソフトウェアの更新操作を実施することなく、最新バージョンのソフトウェアを使い続けられるという利点がある。

特開平１１−２６５２７９号公報

あるソフトウェアにおいて、そのソフトウェア開発者が新しいバージョンを配信する目的は、現在利用されているバージョンにおける不具合（いわゆるバグ）の修正や新機能の追加が代表的である。しかしながら、時として、最新バージョンのソフトウェアが新たな不具合を有していたり、ユーザの個人情報等を漏えいなどにつながるセキュリティ上の欠陥を有していたりする場合がある。

ソフトウェアの更新に対するユーザの好みは、多種多様であり、ユーザの中には、上述したリスクを承知の上で、最新バージョンのソフトウェアを使いたいユーザもいると考えられる。そのようなユーザにとっては、新しいバージョンが利用可能となったことを検出した場合に自動的に更新を実施する特許文献１の更新方法でも、好みに応じたタイミングでソフトウェアを自動更新することになる。

しかし、ユーザの中には、上述したリスクを避けるため、新しいバージョンが利用可能となった後も、一定期間様子見て、概ね問題がなさそうである事を確認してから慎重にソフトウェアを更新したいユーザ（慎重派ユーザとする）も存在する。

そのような慎重派ユーザにとっては、特許文献１の更新方法は好みに合った更新方法とはなっていない。したがって、慎重派ユーザは、特許文献１の方法による自動更新は実施させずに、手動でバージョン情報の確認や更新を実施する必要がある。

すなわち、特許文献１の更新方法では、多種多様なユーザの好みに応じたタイミングで自動的にソフトウェアを更新する事ができないといった課題があった。

本発明は、この事情に基づいて成されたものであり、その目的とするところは、ユーザの好みに応じたタイミングで、ソフトウェアを自動的に更新することができる情報処理端末、及び更新制御プログラムを提供することにある。

その目的を達成するための情報処理端末の第１の発明は、ソフトウェアを配信するソフトウェア配信サーバ（２０）から取得したソフトウェア、及び当該ソフトウェアのバージョン情報を記憶するソフトウェア記憶部（１２）と、ソフトウェア配信サーバから、最新バージョンのソフトウェアのバージョン情報と、少なくとも１種類の、最新バージョンのソフトウェアに対する信頼性を評価するために用いられる管理要素についての情報（以降、管理要素情報）と、を取得するソフトウェア情報取得部（Ｆ１３）と、ユーザ操作に基づいて、少なくとも１つの管理要素に対して設定される、ソフトウェアを最新バージョンへと更新するべきか否かの判定に用いられる自動更新条件を取得する自動更新条件取得部（Ｆ１２）と、自動更新条件取得部が取得した自動更新条件を記憶する更新条件記憶部（１１２）と、ソフトウェア情報取得部が取得したバージョン情報及び管理要素情報と、ソフトウェア記憶部に記憶されているソフトウェアのバージョン情報と、更新条件記憶部が記憶している自動更新条件と、に基づいてソフトウェア記憶部に記憶されているソフトウェアを更新するべきか否かを判定する更新判定部（Ｆ１４）と、更新判定部がソフトウェアを更新するべきであると判定したことに基づいて、ソフトウェアの更新を実施する更新実行部（Ｆ１５）と、画像又はテキストを表示する表示部（１４）と、表示部での表示を制御する表示制御部（Ｆ１１）と、を備え、更新判定部は、ソフトウェア情報取得部が取得したバージョン情報と、ソフトウェア記憶部に記憶されているソフトウェアのバージョン情報とを比較することによって、ソフトウェア記憶部に記憶されているソフトウェアが最新バージョンであるか否かを判定するバージョン情報判定部（Ｓ２３）と、バージョン情報判定部が、ソフトウェア記憶部に記憶されているソフトウェアが最新バージョンではないと判定した場合に、ソフトウェア情報取得部が取得した管理要素情報と自動更新条件とを比較することによって管理要素情報が自動更新条件を満たしているか否かを判定する自動更新条件判定部（Ｓ２５、Ｓ２６）と、を備え、自動更新条件判定部が、管理要素情報が自動更新条件を満たしていると判定した場合に、ソフトウェア記憶部に記憶されているソフトウェアを更新するべきであると判定するものであって、表示制御部は、バージョン情報判定部によってソフトウェア記憶部に記憶されているソフトウェアが最新バージョンではないと判定され、かつ、自動更新条件判定部によって管理要素情報が自動更新条件を満たしていないと判定された場合には、自動更新条件の達成度合いを表す画像又はテキストを表示部に表示させることを特徴とする。
また、上記目的を達成するための情報処理端末の第２の発明は、ソフトウェアを配信するソフトウェア配信サーバ（２０）から取得したソフトウェア、及び当該ソフトウェアのバージョン情報を記憶するソフトウェア記憶部（１２）と、ソフトウェア配信サーバから、最新バージョンのソフトウェアのバージョン情報と、少なくとも１種類の、最新バージョンのソフトウェアに対する信頼性を評価するために用いられる管理要素についての情報（以降、管理要素情報）と、を取得するソフトウェア情報取得部（Ｆ１３）と、ユーザ操作に基づいて、少なくとも１つの管理要素に対して設定される、ソフトウェアを最新バージョンへと更新するべきか否かの判定に用いられる自動更新条件を取得する自動更新条件取得部（Ｆ１２）と、自動更新条件取得部が取得した自動更新条件を記憶する更新条件記憶部（１１２）と、ソフトウェア情報取得部が取得したバージョン情報及び管理要素情報と、ソフトウェア記憶部に記憶されているソフトウェアのバージョン情報と、更新条件記憶部が記憶している自動更新条件と、に基づいてソフトウェア記憶部に記憶されているソフトウェアを更新するべきか否かを判定する更新判定部（Ｆ１４）と、更新判定部がソフトウェアを更新するべきであると判定したことに基づいて、ソフトウェアの更新を実施する更新実行部（Ｆ１５）と、を備え、ソフトウェア情報取得部は、少なくとも最新バージョンのソフトウェアのダウンロード回数を管理要素情報として取得し、自動更新条件は、少なくともダウンロード回数に対する閾値であるダウンロード閾値を含んでおり、ダウンロード閾値は、当該ソフトウェアの最新バージョンよりも１つ前のバージョンの総ダウンロード回数に、ユーザ操作に基づいて定まる所定の割合を乗算して定まる値となっており、更新判定部は、ソフトウェア記憶部に記憶されているソフトウェアが最新バージョンではなく、かつ、管理要素情報が自動更新条件を満たしている場合に、ソフトウェア記憶部に記憶されているソフトウェアを更新するべきであると判定し、ソフトウェア記憶部に記憶されているソフトウェアが最新バージョンである場合、又は、管理要素情報が自動更新条件を満たしていない場合には、ソフトウェア記憶部に記憶されているソフトウェアを更新するべきではないと判定することを特徴とする。

以上の構成では、ソフトウェア記憶部に記憶されているソフトウェアが最新バージョンのものではない場合であっても、最新バージョンのソフトウェアの管理要素情報が、自動更新条件を満たしていない場合には、更新判定部は、当該ソフトウェアの更新をするべきではないと判定する。すなわち、最新バージョンのソフトウェアの管理要素情報が自動更新条件を満たすまでは、ソフトウェアの更新は実施されない。

ここで、自動更新条件は、最新バージョンのソフトウェアに対する信頼性を評価するために用いられる要素に対してユーザが設定する条件であり、ユーザは、所望の条件を設定することができる。したがって、自動更新条件とは、ソフトウェアの更新に対するユーザの好みが反映された条件である。

例えばユーザが、比較的すぐに達成されそうな自動更新条件を設定している場合には、ソフトウェア配信サーバが最新バージョンの配信を開始してから更新判定部によって、更新するべきであると判定されるまでの時間は、相対的に小さい。特に、ソフトウェア配信サーバが最新バージョンの配信を開始した時点で満たされるような自動更新条件を設定している場合には、特許文献１と同様に、ソフトウェア配信サーバが最新バージョンを配信し始めたことをソフトウェア情報取得部が取得した時に更新が実施される。

すなわち、最新バージョンのソフトウェアが利用可能となった場合にはすぐに更新を実施させたいタイプのユーザは、比較的すぐに達成されそうな自動更新条件を設定しておくことで、好みに応じたタイミングで更新を実施させることができる。

一方、慎重派ユーザもまた、好みに応じた自動更新条件を設定しておけば良い。例えば、達成されるまでに時間がかかりそうな自動更新条件を設定しておけば、最新バージョンのソフトウェアが公開された直後に発覚されがちな、初期不良などの不具合を避けることが期待できる。

もちろん、時間の経過に伴って自動更新条件が充足された場合には、自動的にソフトウェアの更新が実施される。すなわち、慎重派ユーザにとっても、好みに応じたタイミングで自動的に更新を実施させることができる。

したがって、以上で述べた構成によれば、ユーザの好みに応じたタイミングで、ソフトウェアを自動的に更新することができる。

また、上記目的を達成するための更新制御プログラムの第１の発明は、コンピュータにインストールされているソフトウェアを配信しているソフトウェア配信サーバ（２０）から、ソフトウェアの最新バージョンのバージョン情報と、少なくとも１種類の、最新バージョンのソフトウェアに対する信頼性を評価するために用いられる管理要素についての情報（以降、管理要素情報）と、を取得するソフトウェア情報取得部（Ｆ１３）と、ユーザ操作に基づいて、少なくとも１つの管理要素に対して設定される、ソフトウェアを最新バージョンへと更新するべきか否かの判定に用いられる自動更新条件を取得する自動更新条件取得部（Ｆ１２）と、ソフトウェア情報取得部が取得したバージョン情報及び管理要素情報と、現在インストールされているソフトウェアのバージョン情報と、自動更新条件取得部が取得した自動更新条件と、に基づいて、ソフトウェアを更新するべきか否かを判定する更新判定部（Ｆ１４）と、更新判定部がソフトウェアを更新するべきであると判定したことに基づいて、ソフトウェアの更新を実施する更新実行部（Ｆ１５）と、画像又はテキストを表示する表示部での表示を制御する表示制御部（Ｆ１１）として、コンピュータを機能させるための更新制御プログラムであって、更新判定部は、ソフトウェア情報取得部が取得したバージョン情報と、コンピュータにインストールされているソフトウェアのバージョン情報とを比較することによって、コンピュータにインストールされているソフトウェアが最新バージョンであるか否かを判定するバージョン情報判定部（Ｓ２３）と、バージョン情報判定部が、コンピュータにインストールされているソフトウェアが最新バージョンではないと判定した場合に、ソフトウェア情報取得部が取得した管理要素情報と自動更新条件とを比較することによって管理要素情報が自動更新条件を満たしているか否かを判定する自動更新条件判定部（Ｓ２５、Ｓ２６）と、を備え、自動更新条件判定部が、管理要素情報が自動更新条件を満たしていると判定した場合に、コンピュータにインストールされているソフトウェアを更新するべきであると判定するものであって、表示制御部は、バージョン情報判定部によってコンピュータにインストールされているソフトウェアが最新バージョンではないと判定され、かつ、自動更新条件判定部によって管理要素情報が自動更新条件を満たしていないと判定された場合には、自動更新条件の達成度合いを表す画像又はテキストを表示部に表示させることを特徴とする。
さらに、上記目的を達成するための更新制御プログラムの第２の発明は、コンピュータにインストールされているソフトウェアを配信しているソフトウェア配信サーバ（２０）から、ソフトウェアの最新バージョンのバージョン情報と、少なくとも１種類の、最新バージョンのソフトウェアに対する信頼性を評価するために用いられる管理要素についての情報（以降、管理要素情報）と、を取得するソフトウェア情報取得部（Ｆ１３）と、ユーザ操作に基づいて、少なくとも１つの管理要素に対して設定される、ソフトウェアを最新バージョンへと更新するべきか否かの判定に用いられる自動更新条件を取得する自動更新条件取得部（Ｆ１２）と、ソフトウェア情報取得部が取得したバージョン情報及び管理要素情報と、現在インストールされているソフトウェアのバージョン情報と、自動更新条件取得部が取得した自動更新条件と、に基づいて、ソフトウェアを更新するべきか否かを判定する更新判定部（Ｆ１４）と、更新判定部がソフトウェアを更新するべきであると判定したことに基づいて、ソフトウェアの更新を実施する更新実行部（Ｆ１５）として、コンピュータを機能させるための更新制御プログラムであって、ソフトウェア情報取得部は、少なくとも最新バージョンのソフトウェアのダウンロード回数を管理要素情報として取得し、自動更新条件は、少なくともダウンロード回数に対する閾値であるダウンロード閾値を含んでおり、ダウンロード閾値は、当該ソフトウェアの最新バージョンよりも１つ前のバージョンの総ダウンロード回数に、ユーザ操作に基づいて定まる所定の割合を乗算して定まる値となっており、更新判定部は、現在インストールされているソフトウェアが最新バージョンではなく、かつ、管理要素情報が自動更新条件を満たしている場合に、ソフトウェアを更新するべきであると判定する一方、ソフトウェアが最新バージョンである場合、又は、管理要素情報が自動更新条件を満たしていない場合には、ソフトウェアを更新するべきではないと判定することを特徴とする。

この更新制御プログラムは、通常のコンピュータを、上述の情報処理端末として機能させるためのコンピュータプログラムである。したがって、更新制御プログラムをコンピュータに実行させることによって、ユーザの好みに応じたタイミングで、そのコンピュータにインストールされているソフトウェアを自動的に更新することができる。

なお、特許請求の範囲に記載した括弧内の符号は、一つの態様として後述する実施形態に記載の具体的手段との対応関係を示すものであって、本発明の技術的範囲を限定するものではない。

本実施形態におけるソフトウェア更新システム１００の概略的な構成の一例を示すブロック図である。 本実施形態に係るソフトウェア配信サーバ２０の概略的な構成の一例を示すブロック図である。 本実施形態に係るユーザ側端末１０の概略的な構成の一例を示すブロック図である。 ユーザ側制御部１１の概略的な構成の一例を示すブロック図である。 自動更新条件取得部Ｆ１２が実施する自動更新条件取得処理の一例を示すフローチャートである。 更新条件設定画面Ｉｍｇの一例である。 更新判定部Ｆ１４が実施する自動更新処理の一例を示すフローチャートである。 変形例１におけるユーザ側端末１０の作動を説明するための概念図である。 自動更新条件の達成率を通知する画面の一例である。 自動更新条件の達成率を通知する画面の一例である。 変形例７におけるユーザ側端末１０Ａの概略的な構成の一例を示すブロック図である。 変形例７におけるユーザ側制御部１１の概略的な構成の一例を示すブロック図である。

以下、本発明の実施形態について図を用いて説明する。図１は、本実施形態に係るソフトウェア更新システム１００の概略的な構成の一例を示す図である。図１に示すようにソフトウェア更新システム１００は、ソフトウェア配信サーバ２０、ユーザ側端末１０を備えている。ユーザ側端末１０とソフトウェア配信サーバ２０とは、電話回線網やインターネットなどの周知の通信ネットワーク３０を介して相互に通信を実施する。

ソフトウェア配信サーバ２０は、例えばユーザ側端末１０で利用されるソフトウェアを開発するソフトウェア開発者が管理するサーバである。ソフトウェア配信サーバ２０は、当該ソフトウェアを格納するとともに、ユーザ側端末１０からの要求に基づいて、当該ソフトウェアをユーザ側端末１０に配信する役割を担っている。

もちろん、ソフトウェア配信サーバ２０は、ソフトウェア開発者が直接管理するサーバではなく、ユーザ側端末１０へのソフトウェアの配信を代理して行うソフトウェア配信事業者が管理するサーバであってもよい。

ユーザ側端末１０は、例えば、ユーザによって携行される携帯端末であって、周知のスマートフォンや、タブレット端末などを適用することができる。なお、ユーザ側端末１０は、ユーザによって携行されるものに限らない。例えば、自宅やオフィスに設置されている情報処理端末であっても良いし、車両に搭載された車載端末であってもよい。このユーザ側端末１０が請求項に記載の情報処理端末に相当する。

ユーザは、ユーザ側端末１０を操作することで、ソフトウェア配信サーバ２０からソフトウェアをダウンロードし、さらに、ユーザ側端末１０にインストールすることができる。本実施形態におけるユーザ側端末１０には既に、ソフトウェア配信サーバ２０から取得したソフトウェアがインストールされているものとする。

また、ユーザ側端末１０は、当該ソフトウェアの新しいバージョンがソフトウェア配信サーバ２０からダウンロード可能となって、かつ、予めユーザによって設定されている自動更新条件が満たされた場合には、自動的に更新処理を実施する。

以下、ソフトウェア配信サーバ２０及びユーザ側端末１０のそれぞれの構成及び作動について、より詳細に説明する。

ソフトウェア配信サーバ２０は、図２に示すように、サーバ側制御部２１、サーバ側ソフトウェア記憶部２２、及びサーバ側通信部２３を備えている。サーバ側制御部２１と、サーバ側ソフトウェア記憶部２２、サーバ側通信部２３とはそれぞれ相互通信可能に接続されている。ソフトウェア配信サーバ２０は、通信ネットワーク３０に接続している複数のコンピュータによって実現されていてもよい。

サーバ側ソフトウェア記憶部２２は、ソフトウェア開発者によって作成された配信用ソフトウェアデータＤ２を格納する記憶装置である。配信用ソフトウェアデータＤ２は、最新バージョンのソフトウェアに対応するデータであって、ユーザ側端末１０は、当該配信用ソフトウェアデータＤ２をダウンロードすることで、自端末のソフトウェアを最新バージョンに更新することができる。サーバ側ソフトウェア記憶部２２は、例えばＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）などの、書き換え可能な不揮発性の記憶媒体を用いて実現されればよい。

配信用ソフトウェアデータＤ２には、ソフトウェアのバージョンを示すバージョン情報が含まれている。一般的に、バージョン情報は、そのバージョンの新しさを識別するためのバージョン番号を含んでいる。初めて登録及び配信されるソフトウェアのバージョン番号は、１．００といった任意の番号となる。なお、バージョン情報には、バージョン番号の他、利用可能となった日付や、開発者、当該ソフトウェアに対応しているオペレーティングシステムなどの情報が含まれていてもよい。

ソフトウェア開発者は、当該ソフトウェアに対して新たな機能追加や不具合の修正が行わった新しいソフトウェアを開発した場合には、その新しいソフトウェアのバージョン番号をカウントアップして元の数値より大きい番号（例えば１．１０や２．００）とする。バージョン情報は、ファイル名の一部として埋め込まれていたり、ソフトウェアのメタデータとして含まれていたりすればよい。

ユーザ側端末１０で利用されているソフトウェアが、最新バージョンのソフトウェアであるか否かは、ユーザ側端末１０で利用されているソフトウェアのバージョン情報（例えばバージョン番号）と、配信用ソフトウェアデータＤ２のバージョン情報とを比較することによって判定することができる。

サーバ側通信部２３は、送受信アンテナを備え、通信ネットワーク３０を介して、ユーザ側端末１０と通信する。サーバ側通信部２３は、ユーザ側端末１０から受信した信号を復調してサーバ側制御部２１に出力するとともに、サーバ側制御部２１から入力されたデータを変調してユーザ側端末１０に送信する。

サーバ側制御部２１は、通常のコンピュータとして構成されており、周知のＣＰＵ、ＲＯＭや、フラッシュメモリなどの不揮発性メモリ、ＲＡＭなどの揮発性メモリ、Ｉ／Ｏ、及びこれらの構成を接続するバスライン（何れも図示略）などを備えている。不揮発性メモリには、種々の処理を実行するためのプログラムやデータが格納されている。サーバ側制御部２１は、配信管理部２１１、及び管理情報記憶部２１２を備える。

管理情報記憶部２１２は、配信管理部２１１の指示に基づいて、配信用ソフトウェアデータＤ２についての情報である管理情報（後述）を、そのバージョン情報と対応付けて記憶する。管理情報記憶部２１２は、例えばサーバ側制御部２１が備えるフラッシュメモリなどの、書き換え可能な記憶媒体を利用して実現されればよい。

配信管理部２１１は、ユーザ側端末１０からの要求に基づいて、サーバ側ソフトウェア記憶部２２に格納されている配信用ソフトウェアデータＤ２を配信する。より具体的には、サーバ側ソフトウェア記憶部２２から読み出した配信用ソフトウェアデータＤ２をサーバ側通信部２３に出力し、更新の要求をしてきたユーザ側端末１０に対して配信用ソフトウェアデータＤ２を送信させる。

また、配信管理部２１１は、管理情報記憶部２１２に管理情報を記憶させるとともに、その管理情報を随時更新する。配信管理部２１１は、管理情報記憶部２１２に格納されている管理情報の読み出しも実施する。

本実施形態において配信管理部２１１は、そのバージョンのソフトウェアのダウンロード回数と、経過時間を、管理情報として管理情報記憶部２１２に記憶させる。以降において、管理情報に含まれる個々の要素を管理要素と称し、管理要素について情報を管理要素用情報とする。

ダウンロード回数は、そのバージョンの配信用ソフトウェアデータＤ２がユーザ側端末１０にダウンロードされた回数を指す。また、経過時間は、そのバージョンの配信用ソフトウェアデータＤ２がサーバ側ソフトウェア記憶部２２に格納されてからの経過時間、すなわち、そのバージョンのソフトウェアをユーザがダウンロード可能となってからの経過時間を指す。

より具体的には、配信管理部２１１は、配信用ソフトウェアデータＤ２がサーバ側ソフトウェア記憶部２２に格納された場合に、そのバージョン情報を取得して管理情報記憶部２１２に記憶させる。また、それに伴って、バージョン情報に対応付けられるダウンロード回数と、経過時間を初期化する。すなわち、新しい配信用ソフトウェアデータＤ２が格納された場合には、ダウンロード回数と経過時間を０にリセットする。

その後、配信管理部２１１は、ユーザ側端末１０に、その配信用ソフトウェアデータＤ２を配信する毎に、ダウンロード回数を１つずつカウントアップする。また、経過時間については、時間の経過に伴って逐次（例えば１分毎に）更新されればよい。

ダウンロード回数や、経過時間といった管理要素は、時間の経過に伴って変化していく要素である。これらの要素は、後述するように、最新バージョンのソフトウェアに対する信頼性を評価するために用いられる。

この管理情報記憶部２１２に格納されている管理情報は、ユーザ側端末１０からの要求に基づいて、バージョン情報と対応付けられてユーザ側端末１０に配信される。

ユーザ側端末１０は、図３に示すように、ユーザ側制御部１１、ユーザ側ソフトウェア記憶部１２、ユーザ側通信部１３、表示部１４、及び操作部１５を備えている。ユーザ側制御部１１と、ユーザ側ソフトウェア記憶部１２、ユーザ側通信部１３、表示部１４、及び操作部１５とはそれぞれ相互通信可能に接続されている。

ユーザ側ソフトウェア記憶部１２は、書き換え可能な不揮発性の記憶媒体であって、ソフトウェア配信サーバ２０からダウンロードしたソフトウェアのデータＤ１を、ユーザ側制御部１１が実行可能な状態で格納している。すなわち、ユーザ側ソフトウェア記憶部１２は、インストールしたソフトウェアの保存場所として利用される記憶領域である。また、ソフトウェアデータＤ１が、ユーザ側端末１０にインストールされているソフトウェアのデータである。このソフトウェアデータＤ１も、バージョン情報を備えている。

ユーザ側ソフトウェア記憶部１２は、例えばフラッシュメモリなど周知の記憶媒体を用いて実現することできる。本実施形態においては、一例としてＳＤカードとする。このユーザ側ソフトウェア記憶部１２が請求項に記載のソフトウェア記憶部に相当する。

ユーザ側通信部１３は、送受信アンテナを備え、通信ネットワーク３０を介して、ソフトウェア配信サーバ２０と通信する。ユーザ側通信部１３は、ソフトウェア配信サーバ２０から受信した信号を復調してユーザ側制御部１１に出力するとともに、サーバ側制御部２１から入力されたデータを変調してユーザ側端末１０に送信する。ユーザ側通信部１３は、例えば、公知の第４世代移動体通信システムで用いられる通信モジュールによって実現されればよい。

表示部１４は、ユーザ側制御部１１からの入力に基づいてテキストや画像を表示する。表示部１４は、例えばフルカラー表示が可能なものであって、液晶ディスプレイ、有機ＥＬディスプレイ等を用いて構成することができる。

操作部１５は、表示部１４と一体になった静電容量式のタッチパネルとする。ユーザは、この操作部１５をタッチ操作することによりユーザ側制御部１１に、各種機能の実行指示を行う。例えばユーザは、当該操作部１５を所定の手順で操作することによって、後述する自動更新条件を設定することができる。また、ユーザは、当該操作部１５を所定の手順で操作することによって、ユーザ側端末１０にインストールされているソフトウェアデータＤ１を削除することもできる。

もちろん、ユーザ側端末１０は、ユーザの操作を受け付けるインターフェースとしてタッチパネルに代わって、メカニカルなスイッチ等を備えていてもよい。

ユーザ側制御部１１は、コンピュータとして構成されており、周知のＣＰＵ、ＲＯＭ、フラッシュメモリなどの不揮発性メモリ、ＲＡＭなどの揮発性メモリ、Ｉ／Ｏ、及びこれらの構成を接続するバスライン（図示略）などを備えている。ＲＯＭやフラッシュメモリといった不揮発性メモリには、ユーザ側制御部１１が種々の処理を実行するためのプログラムが格納されている。

ユーザ側制御部１１が備えるフラッシュメモリなどの、書き換え可能であって不揮発性の記憶領域のうち、更新制御プログラムＡｐ１を記憶している領域を更新制御プログラム記憶部１１１とする。また、ユーザ側制御部１１が備える記憶領域のうち、ユーザによって設定される自動更新条件を記憶する領域を更新条件記憶部１１２とする。

更新制御プログラムＡｐ１は、ユーザ側端末１０にインストールされているソフトウェアのデータＤ１を、ユーザの好みに応じたタイミングで自動的に更新を実施するためのアプリケーションプログラムである。

なお、本実施形態では、ユーザ側ソフトウェア記憶部１２を、ユーザ側制御部１１にとっての外部に設けられた記憶媒体（すなわちＳＤカード）で実現する例を示しているが、これに限らない。他の態様として、ユーザ側ソフトウェア記憶部１２に相当する記憶領域は、ユーザ側制御部１１が備える不揮発性の書き換え可能な記憶媒体によって実現されてもよい。

ユーザ側制御部１１は、当該更新制御プログラムＡｐ１を実行することによって実現される機能ブロックとして、図４に示すように表示制御部Ｆ１１、自動更新条件取得部Ｆ１２、管理情報取得部Ｆ１３、更新判定部Ｆ１４、及び更新実行部Ｆ１５を備える。

表示制御部Ｆ１１は、表示部１４の表示させる内容（テキストや画像）を制御する。より具体的には、表示制御部Ｆ１１は、他の機能ブロックからの要求に基づいて、テキストや画像を表示部１４に表示させる。

自動更新条件取得部Ｆ１２は、操作部１５に対するユーザ操作に基づいて、ソフトウェアデータＤ１を更新する処理を実行する条件である自動更新条件を取得する。自動更新条件には、管理情報に含まれる管理要素情報が用いられる。すなわち、本実施形態では自動更新条件として、ダウンロード回数（単位：回）と、経過時間（単位：日）が利用可能である。ユーザは、それぞれの管理要素に対して好みに応じた閾値を設定することができる。

ここで、図５に示すフローチャートを用いて、自動更新条件取得部Ｆ１２が実施する、自動更新条件を取得するための処理（以降、自動更新条件取得処理）について説明する。図５に示すフローチャートは、自動更新条件を設定するためのユーザ操作を操作部１５が受け付けた場合に開始されればよい。なお、図５に示すフローチャートの各ステップは、自動更新条件取得部Ｆ１２によって実施される。

まず、ステップＳ１１では、各管理要素に対する閾値をユーザが入力するための更新条件設定画面１４ａ（図６参照）を、表示制御部Ｆ１１に表示させる。図６に示す更新条件設定画面１４ａは、各管理要素を自動更新条件として採用するかを選択するためのチェックボックスＣｂｘ１、Ｃｂｘ２と、各管理要素に対応した閾値（回数や日数）をユーザが入力するための入力フォームＦｒｍ１、Ｆｒｍ２を備える。

より具体的に、チェックボックスＣｂｘ１は、自動更新条件としてダウンロード回数を採用するか否かをユーザが選択するためのボタンである。ユーザは、当該チェックボックスＣｂｘ１上をタッチすることで、自動更新条件としてダウンロード回数を採用している状態と、採用していない状態とを切り替えることができる。

自動更新条件としてダウンロード回数を採用している場合には、後述するダウンロード回数に対応する入力フォームＦｒｍ１に入力されている回数が、自動更新条件として採用される。なお、図６のチェックボックスＣｂｘ１は、自動更新条件としてダウンロード回数を採用している状態を表している。

チェックボックスＣｂｘ２は、自動更新条件として経過時間を採用するか否かをユーザが選択するためのボタンである。ユーザは、当該チェックボックスＣｂｘ２上をタッチすることで、自動更新条件として経過時間を採用している状態と、採用していない状態とを切り替えることができる。

自動更新条件として経過時間を採用している場合には、後述する経過時間に対応する入力フォームＦｒｍ２に入力されている日数が自動更新条件として採用される。なお、図６のチェックボックスＣｂｘ２は、自動更新条件としてダウンロード回数が採用されていない状態を表している。

入力フォームＦｒｍ１は、ダウンロード回数に対する閾値（ダウンロード閾値とする）を入力するための領域である。ユーザは、当該入力フォームＦｒｍ１を選択している状態において、操作部１５を操作することによってダウンロード閾値とする回数を入力することができる。

ダウンロード閾値は、ダウンロード回数の観点からユーザが、当該最新バージョンのソフトウェアに対する信頼性を評価するための指標である。すなわち、多くの他のユーザによってダウンロードされているソフトウェアであれば、ユーザによってあまりダウンロードされていないソフトウェアよりも相対的に信頼できそうであるといった推測に基づいて設定される条件である。実際の（すなわち管理情報に含まれる）ダウンロード回数が、このダウンロード閾値以上となっている場合に、自動更新条件を構成する項目のうち、ダウンロード回数に対して設定されている条件が満たされたと判定される。

なお、図６では、ダウンロード閾値は５０００回としているが、もちろん、この値はユーザの好みに応じた値とすればよい。例えば、最新バージョンのソフトウェアを、仮に不具合があってもよいからすぐに使いたいというユーザは、５００や、１０００などの相対的に少ない数を設定すればよい。一方、なるべく不具合というは避けたいというユーザであれば、１万や１０万といった多くの回数を設定しておけばよい。

入力フォームＦｒｍ２は、経過時間に対する閾値（経過時間閾値とする）を入力するための領域であって、ユーザは、当該入力フォームＦｒｍ２を選択した状態において、操作部１５を操作することによって経過時間閾値とする日数を入力することができる。なお、図６は、経過時間は３０日としている例を示している。

経過時間閾値は、経過時間の観点からユーザが、当該最新バージョンのソフトウェアに対する信頼性を評価するための指標である。すなわち、新しいバージョンのソフトウェアが配信開始されてからある程度の時間が経過していれば、初期不良などのトラブルに巻き込まれる恐れは、配信開始の直後よりも低いだろうといった推測に基づいて設定される条件である。経過時間が、この経過時間閾値以上となっている場合に、自動更新条件を構成する項目のうち、経過時間に対して設定されている条件が満たされたと判定される。

なお、更新条件設定画面１４ａは、以上で述べた当該更新条件設定画面１４ａにおいてユーザが入力した条件を自動更新条件として更新条件記憶部１１２に保存することを指示するための決定ボタンＢ１と、当該更新条件設定画面１４ａで入力した条件を更新条件記憶部１１２に保存しないことを指示するためのキャンセルボタンＢ２を備える。ユーザは、種々の項目に対して条件を入力した後に決定ボタンＢ１を選択することで、その入力内容を自動更新条件として設定することができる。

以上、図６を用いて更新条件設定画面１４ａの一例について述べたが、もちろん更新条件設定画面１４ａの表示態様は、図６に示すものに限らない。よりデザイン性に優れていたり、ユーザにとってわかりやすいデザインに変更されたりすればよい。

なお、更新条件設定画面１４ａを表示部１４に表示させるための画像データは更新制御プログラム記憶部１１１に格納されていれば良い。再び図５に戻り、自動更新条件取得処理について説明をする。

ステップＳ１１で上述したような更新条件設定画面１４ａを表示制御部Ｆ１１に表示させると、ステップＳ１２に移る。ステップＳ１２では、操作部１５に対するユーザ操作に基づいて、ダウンロード閾値を取得し、ステップＳ１３に移る。なお、ユーザがダウンロード回数を自動更新条件として採用しないことを選択した場合にも、ステップＳ１３に移ればよい。

ステップＳ１３では、操作部１５に対するユーザ操作に基づいて経過時間閾値を取得し、ステップＳ１４に移る。ユーザが経過時間を自動更新条件として採用しないことを選択した場合にもステップＳ１４に移ればよい。

ステップＳ１４では、ステップＳ１２及びＳ１３で取得した閾値を、自動更新条件として設定し、更新条件記憶部１１２に保存する。なお、このステップＳ１４を実行する場合とは、更新条件設定画面１４ａにおいて、前述の通り、決定ボタンＢ１がユーザによって選択された場合である。

以降では、一例として、ダウンロード回数と経過時間の両方が、自動更新条件として採用されており、ダウンロード閾値と経過時間閾値の両方が設定されているものとする。なお、初期状態においては、ダウンロード回数と経過時間の両方が自動更新条件として採用されており、ダウンロード閾値と経過時間閾値のそれぞれには、所定の初期値が設定されているものとすればよい。

管理情報取得部Ｆ１３は、ソフトウェア配信サーバ２０から、現在配信されている最新バージョンのソフトウェアのバージョン情報（以降、最新バージョン情報）と、その最新バージョンのソフトウェアに対応する管理情報を取得する。最新バージョン情報とは、配信用ソフトウェアデータＤ２のバージョン情報である。

より具体的には、更新判定部Ｆ１４からの指示に基づいて、管理情報を送信するように要求する管理情報要求信号を生成し、ユーザ側通信部１３を介してソフトウェア配信サーバ２０に送信する。ソフトウェア配信サーバ２０は、ユーザ側端末１０からの管理情報要求信号を受信すると、最新バージョン情報と、その時点における管理情報とを対応付けてユーザ側端末１０に送信する。

そして、管理情報取得部Ｆ１３は、管理情報要求信号に対する応答としてソフトウェア配信サーバ２０が送信した最新バージョン情報及びその管理情報を受信する。管理情報取得部Ｆ１３が取得した最新バージョン情報及びその管理情報は、逐次更新判定部Ｆ１４に提供される。この管理情報取得部Ｆ１３が請求項に記載のソフトウェア情報取得部に相当する。

なお、本実施形態では、ソフトウェア配信サーバ２０は、ユーザ側端末１０からの要求に基づいて最新バージョン情報及びその管理情報を送信する構成とするがこれに限らない。定期的に（例えば１２時間毎に）、最新バージョン情報及びその管理情報を配信する構成としてもよい。

更新判定部Ｆ１４は、管理情報取得部Ｆ１３に管理情報要求信号を送信させる。また、更新判定部Ｆ１４は、管理情報取得部Ｆ１３が取得した最新バージョン情報とその管理情報、ソフトウェアデータＤ１のバージョン情報、及び自動更新条件に基づいて、ソフトウェアデータＤ１を更新するべきか否かの判定を行う。この更新判定部Ｆ１４の、より詳細な作動については後述する。

更新実行部Ｆ１５は、更新判定部Ｆ１４がソフトウェアデータＤ１を更新するべきであると判定した場合に、ユーザ側通信部１３と協働してソフトウェア配信サーバ２０から配信用ソフトウェアデータＤ２を取得し、ソフトウェアデータＤ１の更新を実施する。

次に、図７に示すフローチャートを用いて、ユーザ側制御部１１が実施する自動更新処理について説明する。自動更新処理は、ユーザ側ソフトウェア記憶部１２に格納されているソフトウェアデータＤ１を自動的に更新するための処理である。図７に示すフローチャートは、定期的に、例えば毎日午前０時に開始されればよい。このフローチャートを実施する時間帯や周期は適宜設計されればよい。ただし、ソフトウェアの更新処理中は当該ソフトウェアを利用することが出来ないため、ユーザが当該ソフトウェアを利用する可能性が低い時間帯に実行されることがより好ましい。

まず、ステップＳ２１では、ソフトウェア配信サーバ２０から最新バージョン情報とその管理情報を取得する。すなわち、管理情報取得部Ｆ１３に管理情報要求信号をソフトウェア配信サーバ２０へ送信させ、その管理情報要求信号に対する応答として管理情報取得部Ｆ１３が取得した最新バージョン情報及びその管理情報を取得する。このステップＳ２１での処理が完了すると、ステップＳ２２に移る。

ステップＳ２２では、ユーザ側ソフトウェア記憶部１２に格納されているソフトウェアデータＤ１に含まれているバージョン情報を参照して、ステップＳ２３に移る。

ステップＳ２３では、ステップＳ２１で取得した最新バージョン情報、すなわち配信用ソフトウェアデータＤ２のバージョン情報と、ユーザ側ソフトウェア記憶部１２に格納されているソフトウェアデータＤ１のバージョン情報を比較する。そして、ソフトウェアデータＤ１が最新バージョンであるか否かを判定する。このステップＳ２３が請求項に記載のバージョン情報判定部に相当する。

ソフトウェアデータＤ１が最新バージョンであると判定する場合とは、例えば配信用ソフトウェアデータＤ２のバージョン番号と、ソフトウェアデータＤ１のバージョン番号が一致している場合とすれば良い。また、ソフトウェアデータＤ１が最新バージョンではないと判定する場合とは、配信用ソフトウェアデータＤ２のバージョン番号が、ソフトウェアデータＤ１のバージョン番号よりも大きい数字となっている場合とすれば良い。

そして、ユーザ側ソフトウェア記憶部１２に格納されているソフトウェアデータＤ１が最新バージョンであると判定した場合には、ステップＳ２３がＹＥＳとなって本フローを終了する。ユーザ側ソフトウェア記憶部１２に格納されているソフトウェアデータＤ１が最新バージョンではないと判定した場合には、ステップＳ２３がＮＯとなってステップＳ２４に移る。

ステップＳ２４では、更新条件記憶部１１２にアクセスし、自動更新条件として設定されているダウンロード閾値と経過時間閾値を読み出してステップＳ２５に移る。ステップＳ２５では、ステップＳ２１で取得した管理情報に含まれているダウンロード回数、すなわち現在のダウンロード回数と、更新条件記憶部１１２に記憶されているダウンロード閾値とを比較する。

そして、現在のダウンロード回数がダウンロード閾値以上である場合（ステップＳ２５ ＹＥＳ）には、ステップＳ２６に移る。一方、現在のダウンロード回数がダウンロード閾値未満である場合には、ステップＳ２５はＮＯとなって、本フローを終了する。なお、自動更新条件としてダウンロード回数が採用されていない場合には、ステップＳ２５を省略してステップＳ２６に移ればよい。このステップＳ２５と、次に説明するステップＳ２６のそれぞれが請求項に記載の自動更新条件判定部に相当する。

ステップＳ２６では、ステップＳ２１で取得した管理情報に含まれている経過時間、すなわち、配信用ソフトウェアデータＤ２がダウンロード可能となってから現在までの経過時間と、更新条件記憶部１１２に記憶されている経過時間閾値とを比較する。

そして、現在の経過時間が経過時間閾値以上となっている場合には、ステップＳ２６がＹＥＳとなって、ステップＳ２７に移る。一方、現在の経過時間が経過時間閾値未満である場合には、ステップＳ２６はＮＯとなって、本フローを終了する。なお、自動更新条件として経過時間が採用されていない場合には、ステップＳ２６を省略してステップＳ２７に移ればよい。

ステップＳ２７では、更新実行部Ｆ１５に当該ソフトウェアの更新を実行するように指示して、本フローを終了する。

以上で述べた構成によれば、例えば、種々のユーザのうち、最新バージョンがダウンロード可能となった場合には、相対的に早いタイミングで最新バージョンを利用したいユーザは、ダウンロード閾値、経過時間閾値を相対的に小さい値に設定しておけばよい。ダウンロード閾値、経過時間閾値を相対的に小さい値に設定しておけば、ソフトウェア配信サーバ２０が最新バージョンの配信を開始してから更新判定部Ｆ１４によって、更新するべきであると判定されるまでの時間は、相対的に小さくなる。すなわち、相対的に早いタイミングでソフトウェアが自動的に更新される。

特に、最新バージョンがダウンロード可能となった場合には、いち早く最新バージョンを利用したいユーザは、ソフトウェア配信サーバが最新バージョンの配信を開始した時点で満たされるような自動更新条件としておけばよい。ソフトウェア配信サーバ２０が最新バージョンの配信を開始した時点で満たされるような自動更新条件としておけば、バージョン情報の比較の結果、ソフトウェア配信サーバ２０が最新バージョンの配信を開始したことを検出した場合に更新が実施される。

ソフトウェア配信サーバ２０が最新バージョンの配信を開始した時点で満たされるような自動更新条件とは、ダウンロード閾値を０回、経過時間を０日とした条件である。もちろん、自動更新条件として、ダウンロード閾値と経過時間の両方を採用しないように設定した場合も、同様の効果が得られる。

一方、新しいバージョンが利用可能となった後も、一定期間様子見てからソフトウェアの更新を実施させたいユーザ（慎重派ユーザとする）は、達成されるまでに時間がかかりそうな自動更新条件を設定しておけばよい。例えば、ダウンロード閾値を１０万回、経過時間を３０日としておけばよい。

一般的に、最新バージョンのソフトウェアが、致命的なバグやセキュリティ上の欠陥を有している場合には、ダウンロード回数が伸び悩んで、ダウンロード閾値を達成されなかったりする。したがって、ダウンロード閾値を達成する前に、ソフトウェア開発者が当該バージョンの公開を停止したりすることが期待される。

また、ダウンロード回数がダウンロード閾値を超えたということは、単純計算でダウンロード閾値以上のユーザによって受け入れられているソフトウェアであることを意味する。したがって、このダウンロード閾値を大きくしておけば、致命的なバグやセキュリティ上の欠陥があるバージョンへと更新してしまう可能性を相対的に小さくすることができる。

また、前バージョンのソフトウェアが、多数のユーザにとって好評であった場合には、最新バージョンの公開とともに、比較的に少ない日数でダウンロード回数がダウンロード閾値を越える場合もあり得る。しかし、経過日数を相対的に長い日数としておけば、ダウンロード数がダウンロード閾値を超えた場合であっても、経過日数が経過日数閾値を越えるまでは、更新は実施されない。

前述の通り、最新バージョンのソフトウェアの不具合が周知となった場合には、当該最新バージョンの公開が停止されたり、その不具合が修正されたより新しいバージョンの公開がされたりするなどの対応処置が想定される。

したがって、経過日数を相対的に長く設定しておけば、仮に上述の不具合が見つからないまま、ダウンロード数がダウンロード閾値を超えた場合であっても、不具合を備えたバージョンへと更新してしまう可能性を相対的に小さくすることができる。

すなわち、上述のように、達成されるまでに時間がかかりそうな自動更新条件を設定しておけば、最新バージョンのソフトウェアが公開された直後に発覚されがちな、初期不良などの不具合を避けることが期待できる。

したがって、本実施形態の構成によれば、多種多様なユーザの好みに応じたタイミングで、ソフトウェアを自動的に更新することができる。

以上、本発明の実施形態を説明したが、本発明は上述の実施形態に限定されるものではなく、下記の種々の変形例も本発明の技術的範囲に含まれ、さらに、下記以外にも要旨を逸脱しない範囲内で種々変更して実施することができる。

＜変形例１＞
以上では、１種類のソフトウェアに対する動作例を述べたが、図８に示すように、本発明は、複数種類のソフトウェアのそれぞれの更新に対応していても良い。この場合、更新条件記憶部１１２は、ソフトウェア毎に設定されていればよい。

図８に示すユーザ側ソフトウェア記憶部１２は、複数種類のソフトウェアＡ、Ｂ、ＣのデータＤ１ａ、Ｄ１ｂ、Ｄ１ｃを記憶している。また、更新条件記憶部１１２は、ソフトウェアＡ用の自動更新条件Ｃａ、ソフトウェアＢ用の自動更新条件Ｃｂ、及びソフトウェアＣ用の自動更新条件Ｃｃを、ソフトウェアデータＤ１ａ、Ｄ１ｂ、Ｄ１ｃのそれぞれと対応付けて記憶している。各自動更新条件Ｃａ、Ｃｂ、Ｃｃは、前述の実施形態と同様に、ユーザ操作に基づいて設定されていればよい。

この変形例１の構成では、各ソフトウェアは、そのソフトウェアの新しいバージョンがダウンロード可能となって、かつ、そのソフトウェアに対応する自動更新条件が充足された場合に、自動的に更新される。すなわち、この変形例１の構成によれば、複数種類のソフトウェアのそれぞれに対して、ユーザの好みに応じたタイミングで自動的に更新させることができる。

なお、一般に、ソフトウェアの種類ごとに、そのソフトウェアを利用しているユーザ数は異なる。したがって、ソフトウェア毎に、ダウンロード閾値等の自動更新条件も異なってくる。この変形例１の構成によれば、そういったソフトウェア毎の傾向に応じた自動更新条件を設定する事ができる。

＜変形例２＞
以上では、ダウンロード回数に対してユーザが自動更新条件として設定する条件の単位を回数とする構成としたが、これに限らない。例えば、ユーザは、ダウンロード回数に対する自動更新条件として、最新バージョンよりも１つ前のバージョンのソフトウェアの最終的なダウンロード回数に対する割合（単位：％）を設定する構成としてもよい。ここでの最終的なダウンロード回数は、最新バージョンが利用可能となる直前に管理情報として取得したダウンロード回数とすればよい。この最終的なダウンロード回数が、請求項に記載の総ダウンロード回数に相当する。

そして、更新判定部Ｆ１４は、その最終的なダウンロード回数にユーザが設定した割合を乗算することによって、ダウンロード閾値に換算し、最新バージョンのダウンロード回数との比較を行う。

このようにユーザがダウンロード回数に対する自動更新条件として設定する単位を回数ではなく、最新バージョンよりも１つ前のバージョンのソフトウェアの最終的なダウンロード回数に対する割合とする利点は次の通りである。

一般に、ソフトウェア毎に、新しいバージョンのソフトウェアがユーザにダウンロードされると見込まれる回数や、勢い（例えば１日当りのダウンロード数）などが異なる。より具体的には、１０万人のユーザが利用しているソフトウェアもあれば、５０００人のユーザしか利用していないソフトウェアもある。

ここで、仮に実施形態の構成においてダウンロード閾値を１００００回と設定した場合、前者のようにユーザ数が多いソフトウェアであれば、時間の経過に伴って最新バージョンのソフトウェアのダウンロード数も当該ダウンロード閾値を越える可能性が高い。しかし、後者のようにユーザ数が５０００人しかいないソフトウェアでは、ユーザ数がダウンロード閾値を下回っているため、最新バージョンのダウンロード回数がダウンロード閾値を越える可能性は低く、自動更新条件がずっと満たされない可能性がある。

そこで、この変形例２のように、ユーザがダウンロード回数に対する自動更新条件として、最新バージョンよりも１つ前のバージョンのソフトウェアの最終的なダウンロード回数に対する割合を設定し、更新判定部Ｆ１４がその割合に基づいてダウンロード閾値を算出する構成とすれば、ダウンロード閾値を、ユーザ数に応じた数値とすることができる。

なお、ここでは、最新バージョンよりも１つ前のバージョンがダウンロードされた回数をユーザ数と見なす。もちろん、バージョンの違いを無視して計上される、当該ソフトウェアがインストールされているユーザ側端末の数をユーザ数としてもよい。

例えば、ダウンロード回数に対する自動更新条件を２０％に設定しておけば、１つ前のバージョンが１０万回ダウンロードされた実績のあるソフトウェアでは２万回ダウンロードされた時点で、ダウンロード回数における自動更新条件は充足されるようになる。また、前回のバージョンが５０００回しかダウンロードされなかったソフトウェアでは１０００回ダウンロードが実行された時点で、ダウンロード回数における自動更新条件は充足されるようになる。したがって、ソフトウェアのユーザ数の差による上記の問題が発生する可能性は低減される。

ここでは、割合として設定されたダウンロード閾値と、最新バージョンよりも１つ前のバージョンの最終的なダウンロード回数との乗算値を、最新バージョンのソフトウェアをダウンロードするか否かの判定に用いる閾値としたが、これに限らない。

そのソフトウェアのユーザ数を管理要素情報として取得できる場合には、ユーザ数を用いて、最新バージョンのソフトウェアをダウンロードするか否かの判定に用いる閾値を算出してもよい。

＜変形例３＞
変形例２では、ダウンロード回数に対して設定される自動更新条件を、最新バージョンよりも１つ前のバージョンのダウンロード回数に対する割合とする構成を例示したが、これに限らない。

実施形態において、ダウンロード閾値（単位は回数）の初期値を、そのソフトウェアのユーザ数や、最新バージョンよりも１つ前のバージョンの最終的なダウンロード数に基づいて応じた値（例えば５０％に相当する回数）に、自動的に設定する構成としても良い。もちろん、その場合もユーザは、操作部１５を操作することで、ダウンロード閾値を初期値以外の値に設定できるものとする。

このような構成によれば、ユーザはその初期値を見ることで、そのソフトウェアにおけるダウンロード閾値として妥当な値の見当をつけることができる。すなわち、ソフトウェアのユーザ数や、最新バージョンよりも１つ前のバージョンの最終的なダウンロード数に応じたダウンロード閾値を設定することができるため、この変形例３においても変形例２と同様の効果を奏することができる。

＜変形例４＞
上述の実施形態では、ダウンロード回数と経過時間の両方を自動更新条件として採用した構成を例示としたが、これに限らない。自動更新条件としてユーザが選択可能な項目（すなわち管理要素）は、ダウンロード回数と経過時間の何れか一方だけであっても良い。

また、管理情報が管理要素として備える要素は、ダウンロード回数や、経過時間に限らない。一般に、ソフトウェアに対する評価を、星の数や、点数で表す仕組みは広く普及している。ソフトウェアに対する他のユーザの評価もまた、そのソフトウェアに対する信頼性を評価するための指標となりうる。

したがって、ソフトウェア配信サーバ２０が、管理要素情報として、ソフトウェアに対するユーザの評価を収集する構成となっている場合には、ソフトウェアに対するユーザの評価を自動更新条件として採用してもよい。

ソフトウェアに評価を収集する仕組みは、周知の仕組みを援用すればよい。ソフトウェア配信サーバ２０は、ソフトウェアに対する評価を、バージョンと対応付けて集計すればよい。

また、インターネット上において配信されているソフトウェアに対してユーザがコメントを投稿し、そのソフトウェアに対応付けられているコメントを、ユーザ間で共有することができるシステムも普及している。

ソフトウェア更新システム１００が、そのようにユーザ間においてソフトウェアに対するコメントを共有できるシステムとなっている場合には、更新判定部Ｆ１４は、最新バージョンのソフトウェアに対して寄せられているコメントに基づいて、更新するべきか否かを判定してもよい。

例えば、ソフトウェア配信サーバ２０は、あるバージョンのソフトウェアに対して投稿されたコメントをそのバージョン情報と対応付けて、すなわち、そのバージョンの管理要素情報として保存していく。更新判定部Ｆ１４は、最新バージョンのソフトウェアに対応付けられているコメント群に対して、自動更新条件としてユーザによって設定されているキーワードを用いてテキスト検索を実施する。例えば、ユーザは、キーワードとして、不具合や、バグ、欠陥などの単語を登録しておけばよい。

そして、更新判定部Ｆ１４は、検索の結果、該当したコメントの数がその最新バージョンに対して投稿されているコメントの総数に対して所定の割合以下である場合には、更新してもよいと判定すればよい。一方、該当コメント数が所定の割合以上である場合には、更新するべきではないと判定すればよい。

すなわち、最新バージョンのソフトウェアに対して他のユーザが投稿したコメントも、管理要素及び自動更新条件として用いてもよい。なお、テキスト検索処理は周知の方法を援用すればよい。

＜変形例５＞
また、上述した実施形態において、ソフトウェアの新しいバージョンが出ているが（ステップＳ２３ ＮＯ）、ステップＳ２５やＳ２６でＮＯとなって更新を実行していない場合には、その自動更新条件の達成度合い（以降、達成率とする）を表すテキストや画像を表示部１４に表示してもよい。

例えば、表示制御部Ｆ１１は、そのソフトウェアを起動した場合に表示する最初の画面、又は起動処理を実施している間の画面（待機画面とする）において、図９に示すような達成率通知画像Ｉｍｇ２を表示してもよい。なお、図９は、待機画面を表示している表示部１４の一例を表している。図中の符号１４１で指し示す領域は、電波状況や電池残量などといった、ユーザ側端末１０の状態を表示するステータス通知領域を表している。

また、表示制御部Ｆ１１は、ソフトウェアが起動された場合に、図１０に示すように、自動更新条件の達成率をステータス通知領域１４１にテキスト表示してもよい。

達成率は、自動更新条件として採用されている管理要素情報毎に、表示制御部Ｆ１１が算出して表示すればよい。例えば、ダウンロード閾値が１００００回と設定されてあって、かつ、現在のダウンロード回数が９０００回である場合には、達成率は９０％と表示する。

この変形例５の構成によれば、ユーザは、自動更新条件の達成率を認識することができる。ユーザは、その達成率に応じて、手動で更新させたり、達成率の変化が停滞している場合には、停滞している原因を調べたりすることができる。また、達成率の変化の速度に応じて、自動更新条件を再設定するなどの対応をとることができる。

なお、達成率が停滞している場合とは、自動更新条件として採用されている管理要素情報のうち、経過時間以外の管理要素情報の達成率の、一定期間（例えば１週間）での変化が、所定の閾値以下となっている場合を指す。ここで用いる閾値は、達成率が停滞していると判定するための閾値であって、適宜設計されればよい。

なお、自動更新条件の達成率は、新しいバージョンのソフトウェアが公開されている場合に常時表示してもよいし、達成率が停滞している場合にのみ表示してもよい。また、ここでは自動更新条件の達成度合いを割合で表す態様を例示したが、その他の態様で表しても良い。

＜変形例６＞
ところで、ソフトウェア開発者の立場からすると、最新バージョンよりも以前のバージョンのソフトウェアに欠陥があり、そのソフトウェアがインストールされている全てのユーザ側端末１０に対して強制的に更新を実施させたい場合がある。そのような場合を想定してソフトウェア更新システム１００は次のように構成されてあってもよい。

まず、ソフトウェア配信サーバ２０は、ユーザ側端末１０にソフトウェアの更新を実行する必要があるか否かを表す情報（更新要否情報とする）を含む管理情報を配信するように構成しておく。そして、ユーザ側端末１０の更新判定部Ｆ１４は、ソフトウェアの更新を実行する必要がある旨を表す更新要否情報を含む管理情報を取得した場合には、自動更新条件を無視して当該ソフトウェアの更新を実行する。

このような構成によれば、ソフトウェア開発者の都合に応じたタイミングで更新を実施させることができる。

＜変形例７＞
上述した実施形態では、主としてユーザに携行されるスマートフォンなどの携帯端末を想定した構成の一例について述べたが、冒頭にも述べたように、ユーザ側端末は、車両に搭載された車載端末であってもよい。そのように、ユーザ側端末が車載端末である場合の構成（これを変形例７とする）について、図１１及び図１２を用いて説明する。

図１１に示すように、変形例７におけるユーザ側端末１０Ａは、実施形態のユーザ側端末と同様のユーザ側制御部１１、ユーザ側ソフトウェア記憶部１２、ユーザ側通信部１３、表示部１４、操作部１５に加えて、位置検出器１６、及び電源回路１７を備える。

位置検出器１６は、自端末の位置情報（緯度及び経度）を取得する機器である。位置検出器１６は、例えば、ＧＮＳＳ（Ｇｌｏｂａｌ Ｎａｖｉｇａｔｉｏｎ Ｓａｔｅｌｌｉｔｅ Ｓｙｓｔｅｍ）で用いられる衛星からの電波を受信するＧＮＳＳ受信機や、ジャイロセンサ、速度センサなどを組み合わせて実現されればよい。ＧＮＳＳ受信機としては、例えばＧＰＳ受信機を用いることができる。

電源回路１７は、ユーザ側端末１０Ａを動作させるための電力を供給する回路である。例えば電源回路は、車載バッテリーやイグニッション電源等に接続されていればよい。

また、変形例７におけるユーザ側制御部１１は、図１２に示すように、前述の実施形態のユーザ側制御部１１が備える機能ブロック（Ｆ１１〜Ｆ１５）に加えて、駐車判定部Ｆ１６、電源管理部Ｆ１７を備える。

駐車判定部Ｆ１６は、当該ユーザ側端末１０Ａが搭載された車両（以降、自車両）が駐車されようとしているか否かを判定する。例えば駐車判定部Ｆ１６は、位置検出器１６が検出している位置情報に基づいて、自車両と自宅との距離が所定距離（例えば３００ｍ）以上となっている状態から、所定距離未満となった場合に、駐車されようとしていると判定すればよい。なお、自宅の住所は予め登録されていればよい。

なお、ここでの自車両が駐車されようとしている状態には、駐車されてユーザが車両から降りるまでの状態を含む。例えば、駐車判定部Ｆ１６は、図示しない車載センサ、例えばシフトレバーのポジションを検出するシフトポジションセンサからの信号に基づいて、自車両が駐車されようとしているか否かを判定してもよい。すなわち、シフトポジションセンサが、シフトレバーが駐車ポジションに設定されていることを示す信号を出力した場合に、自車両が駐車されようとしていると判定すればよい。

自車両が駐車されようとしているか否かの判定に用いる車載センサはシフトポジションセンサに限らず、イグニッション電源のオン／オフを検出するイグニッション電源センサであってもよい。自車両が駐車されそうであるか否かを判定する方法は、周知の方法を援用すればよい。電源管理部Ｆ１７は、電源回路１７のオン／オフを制御する。この電源管理部Ｆ１７が請求項に記載の電源制御部に相当する。

この変形例７において、ユーザ側制御部１１が、実施形態で述べた機能ブロックに加えて駐車判定部Ｆ１６、電源管理部Ｆ１７を備える構成とした理由は、次の通りである。

すなわち、ユーザ側端末が、スマートフォンなどの携帯端末であれば、常時電源がオンとなっている可能性が高いため、実施形態で述べたように、毎日０時となったタイミングで定期的に自動更新処理を実施することができる。

しかし、ユーザ側端末が車載端末である場合、毎日決まった時間に電源がオンとなっているとは限らない。また、前述の通り、ソフトウェアの更新中は、そのソフトウェアをユーザが利用することができなくなってしまう。そこで、ユーザが車両を降りるタイミングで、自動更新処理を実施する態様が好ましい。さらに、自動更新処理中においては、電力の供給が維持される必要がある。

すなわち、駐車判定部Ｆ１６、電源管理部Ｆ１７は、ユーザが車両を降りるタイミングで自動更新処理を実施し、更新実行部Ｆ１５がソフトウェアの更新を実施する場合には、その更新処理が完了するまで電力の供給を維持するための機能である。

より具体的には、駐車判定部Ｆ１６が、自車両が駐車されそうであると判定した場合に、更新判定部Ｆ１４は自動更新処理を開始する。そして、ステップＳ２６がＹＥＳとなって更新実行部Ｆ１５に更新処理を実施させる場合には、電源管理部Ｆ１７が、その更新処理が完了するまで電源回路１７を制御して、電力の供給を維持する。また、更新処理を実施しなかった場合や、更新処理が完了した場合に、電源回路１７を制御して車載バッテリーからの電力供給を遮断する。

１００ ソフトウェア更新システム、１０ ユーザ側端末（情報処理端末）、２０ ソフトウェア配信サーバ、２１ サーバ側制御部、２２ サーバ側ソフトウェア記憶部、２３ サーバ側通信部、１１ ユーザ側制御部、１２ ユーザ側ソフトウェア記憶部（ソフトウェア記憶部）、１３ ユーザ側通信部、１４ 表示部、１５ 操作部、１１１ 更新制御プログラム記憶部、１１２ 更新条件記憶部、Ｆ１１ 表示制御部、Ｆ１２ 自動更新条件取得部、Ｆ１３ 管理情報取得部（ソフトウェア情報取得部）、Ｆ１４ 更新判定部、Ｆ１５ 更新実行部、Ｄ１ ソフトウェアデータ、Ｄ２ 配信用ソフトウェアデータ

Claims (9)

1. ソフトウェアを配信するソフトウェア配信サーバ（２０）から取得した前記ソフトウェア、及び当該ソフトウェアのバージョン情報を記憶するソフトウェア記憶部（１２）と、
   前記ソフトウェア配信サーバから、最新バージョンの前記ソフトウェアのバージョン情報と、少なくとも１種類の、最新バージョンの前記ソフトウェアに対する信頼性を評価するために用いられる管理要素についての情報（以降、管理要素情報）と、を取得するソフトウェア情報取得部（Ｆ１３）と、
   ユーザ操作に基づいて、少なくとも１つの前記管理要素に対して設定される、前記ソフトウェアを最新バージョンへと更新するべきか否かの判定に用いられる自動更新条件を取得する自動更新条件取得部（Ｆ１２）と、
   前記自動更新条件取得部が取得した前記自動更新条件を記憶する更新条件記憶部（１１２）と、
   前記ソフトウェア情報取得部が取得したバージョン情報及び前記管理要素情報と、前記ソフトウェア記憶部に記憶されている前記ソフトウェアのバージョン情報と、前記更新条件記憶部が記憶している前記自動更新条件と、に基づいて前記ソフトウェア記憶部に記憶されている前記ソフトウェアを更新するべきか否かを判定する更新判定部（Ｆ１４）と、
   前記更新判定部が前記ソフトウェアを更新するべきであると判定したことに基づいて、前記ソフトウェアの更新を実施する更新実行部（Ｆ１５）と、
   画像又はテキストを表示する表示部（１４）と、
   前記表示部での表示を制御する表示制御部（Ｆ１１）と、を備え、
   前記更新判定部は、
   前記ソフトウェア情報取得部が取得したバージョン情報と、前記ソフトウェア記憶部に記憶されている前記ソフトウェアのバージョン情報とを比較することによって、前記ソフトウェア記憶部に記憶されている前記ソフトウェアが最新バージョンであるか否かを判定するバージョン情報判定部（Ｓ２３）と、
   前記バージョン情報判定部が、前記ソフトウェア記憶部に記憶されている前記ソフトウェアが最新バージョンではないと判定した場合に、前記ソフトウェア情報取得部が取得した前記管理要素情報と前記自動更新条件とを比較することによって前記管理要素情報が前記自動更新条件を満たしているか否かを判定する自動更新条件判定部（Ｓ２５、Ｓ２６）と、を備え、
   前記自動更新条件判定部が、前記管理要素情報が前記自動更新条件を満たしていると判定した場合に、前記ソフトウェア記憶部に記憶されている前記ソフトウェアを更新するべきであると判定するものであって、
   前記表示制御部は、前記バージョン情報判定部によって前記ソフトウェア記憶部に記憶されている前記ソフトウェアが最新バージョンではないと判定され、かつ、前記自動更新条件判定部によって前記管理要素情報が前記自動更新条件を満たしていないと判定された場合には、前記自動更新条件の達成度合いを表す画像又はテキストを前記表示部に表示させることを特徴とする情報処理端末。
2. 請求項１において、
   前記ソフトウェア情報取得部は、少なくとも最新バージョンの前記ソフトウェアのダウンロード回数を前記管理要素情報として取得し、
   前記自動更新条件は、少なくともダウンロード回数に対する閾値であるダウンロード閾値を含んでおり、
   前記ダウンロード閾値は、当該ソフトウェアの最新バージョンよりも１つ前のバージョンの総ダウンロード回数に、ユーザ操作に基づいて定まる所定の割合を乗算して定まる値となっていることを特徴とする情報処理端末。
3. ソフトウェアを配信するソフトウェア配信サーバ（２０）から取得した前記ソフトウェア、及び当該ソフトウェアのバージョン情報を記憶するソフトウェア記憶部（１２）と、
   前記ソフトウェア配信サーバから、最新バージョンの前記ソフトウェアのバージョン情報と、少なくとも１種類の、最新バージョンの前記ソフトウェアに対する信頼性を評価するために用いられる管理要素についての情報（以降、管理要素情報）と、を取得するソフトウェア情報取得部（Ｆ１３）と、
   ユーザ操作に基づいて、少なくとも１つの前記管理要素に対して設定される、前記ソフトウェアを最新バージョンへと更新するべきか否かの判定に用いられる自動更新条件を取得する自動更新条件取得部（Ｆ１２）と、
   前記自動更新条件取得部が取得した前記自動更新条件を記憶する更新条件記憶部（１１２）と、
   前記ソフトウェア情報取得部が取得したバージョン情報及び前記管理要素情報と、前記ソフトウェア記憶部に記憶されている前記ソフトウェアのバージョン情報と、前記更新条件記憶部が記憶している前記自動更新条件と、に基づいて前記ソフトウェア記憶部に記憶されている前記ソフトウェアを更新するべきか否かを判定する更新判定部（Ｆ１４）と、
   前記更新判定部が前記ソフトウェアを更新するべきであると判定したことに基づいて、前記ソフトウェアの更新を実施する更新実行部（Ｆ１５）と、を備え、
   前記ソフトウェア情報取得部は、少なくとも最新バージョンの前記ソフトウェアのダウンロード回数を前記管理要素情報として取得し、
   前記自動更新条件は、少なくともダウンロード回数に対する閾値であるダウンロード閾値を含んでおり、
   前記ダウンロード閾値は、当該ソフトウェアの最新バージョンよりも１つ前のバージョンの総ダウンロード回数に、ユーザ操作に基づいて定まる所定の割合を乗算して定まる値となっており、
   前記更新判定部は、
   前記ソフトウェア記憶部に記憶されている前記ソフトウェアが最新バージョンではなく、かつ、前記管理要素情報が前記自動更新条件を満たしている場合に、前記ソフトウェア記憶部に記憶されている前記ソフトウェアを更新するべきであると判定し、
   前記ソフトウェア記憶部に記憶されている前記ソフトウェアが最新バージョンである場合、又は、前記管理要素情報が前記自動更新条件を満たしていない場合には、前記ソフトウェア記憶部に記憶されている前記ソフトウェアを更新するべきではないと判定することを特徴とする情報処理端末。
4. 請求項３において、
   前記更新判定部は、
   前記ソフトウェア情報取得部が取得したバージョン情報と、前記ソフトウェア記憶部に
   記憶されている前記ソフトウェアのバージョン情報とを比較することによって、前記ソフ
   トウェア記憶部に記憶されている前記ソフトウェアが最新バージョンであるか否かを判定
   するバージョン情報判定部（Ｓ２３）と、
   前記バージョン情報判定部が、前記ソフトウェア記憶部に記憶されている前記ソフトウ
   ェアが最新バージョンではないと判定した場合に、前記ソフトウェア情報取得部が取得し
   た前記管理要素情報と前記自動更新条件とを比較することによって前記管理要素情報が前
   記自動更新条件を満たしているか否かを判定する自動更新条件判定部（Ｓ２５、Ｓ２６）
   と、を備え、
   前記自動更新条件判定部が、前記管理要素情報が前記自動更新条件を満たしていると判
   定した場合に、前記ソフトウェア記憶部に記憶されている前記ソフトウェアを更新するべ
   きであると判定することを特徴とする情報処理端末。
5. 請求項１から４の何れか１項において、
   前記管理要素として、最新バージョンの前記ソフトウェアのダウンロード回数と、最新バージョンの前記ソフトウェアがダウンロード可能な状態となってからの経過時間の、少なくとも何れか一方を用いることを特徴とする情報処理端末。
6. 請求項１から５の何れか１項において、
   前記ソフトウェア記憶部は、複数種類の前記ソフトウェアを、前記ソフトウェア毎にそのバージョン情報と対応付けて記憶し、
   前記自動更新条件取得部は、前記ソフトウェア記憶部が記憶している前記ソフトウェア毎の前記自動更新条件を取得し、
   前記更新条件記憶部は、前記自動更新条件取得部が取得した前記ソフトウェア毎の前記自動更新条件を、前記ソフトウェアと対応付けて記憶し、
   前記更新判定部は、前記ソフトウェア記憶部が記憶している前記ソフトウェア毎に、そのソフトウェアを更新するべきか否かを判定することを特徴とする情報処理端末。
7. 請求項１から６の何れか１項において、
   前記情報処理端末は、車両に搭載されてあって、
   前記車両が駐車されようとしているか否かを判定する駐車判定部（Ｆ１６）と、
   前記車両が備えられている電源から当該情報処理端末への電力の供給及び遮断を制御する電源制御部（Ｆ１７）と、を備え、
   前記更新判定部は、前記駐車判定部によって前記車両が駐車されようとしていると判定された場合に、前記ソフトウェア記憶部が記憶している前記ソフトウェアを更新するべきか否かの判定を実施し、
   前記電源制御部は、前記更新実行部が前記ソフトウェアの更新を実施している間は前記電源から当該情報処理端末への電力の供給を維持し、前記更新実行部による更新が完了した場合に、前記電源から当該情報処理端末への電力の供給を遮断することを特徴とする情報処理端末。
8. コンピュータにインストールされているソフトウェアを配信しているソフトウェア配信サーバ（２０）から、前記ソフトウェアの最新バージョンのバージョン情報と、少なくとも１種類の、最新バージョンの前記ソフトウェアに対する信頼性を評価するために用いられる管理要素についての情報（以降、管理要素情報）と、を取得するソフトウェア情報取得部（Ｆ１３）と、
   ユーザ操作に基づいて、少なくとも１つの前記管理要素に対して設定される、前記ソフトウェアを最新バージョンへと更新するべきか否かの判定に用いられる自動更新条件を取得する自動更新条件取得部（Ｆ１２）と、
   前記ソフトウェア情報取得部が取得した前記バージョン情報及び前記管理要素情報と、現在インストールされている前記ソフトウェアのバージョン情報と、前記自動更新条件取得部が取得した前記自動更新条件と、に基づいて、前記ソフトウェアを更新するべきか否かを判定する更新判定部（Ｆ１４）と、
   前記更新判定部が前記ソフトウェアを更新するべきであると判定したことに基づいて、前記ソフトウェアの更新を実施する更新実行部（Ｆ１５）と、
   画像又はテキストを表示する表示部での表示を制御する表示制御部（Ｆ１１）として、前記コンピュータを機能させるための更新制御プログラムであって、
   前記更新判定部は、
   前記ソフトウェア情報取得部が取得したバージョン情報と、前記コンピュータにインストールされている前記ソフトウェアのバージョン情報とを比較することによって、前記コンピュータにインストールされている前記ソフトウェアが最新バージョンであるか否かを判定するバージョン情報判定部（Ｓ２３）と、
   前記バージョン情報判定部が、前記コンピュータにインストールされている前記ソフトウェアが最新バージョンではないと判定した場合に、前記ソフトウェア情報取得部が取得した前記管理要素情報と前記自動更新条件とを比較することによって前記管理要素情報が前記自動更新条件を満たしているか否かを判定する自動更新条件判定部（Ｓ２５、Ｓ２６）と、を備え、
   前記自動更新条件判定部が、前記管理要素情報が前記自動更新条件を満たしていると判定した場合に、前記コンピュータにインストールされている前記ソフトウェアを更新するべきであると判定するものであって、
   前記表示制御部は、前記バージョン情報判定部によって前記コンピュータにインストールされている前記ソフトウェアが最新バージョンではないと判定され、かつ、前記自動更新条件判定部によって前記管理要素情報が前記自動更新条件を満たしていないと判定された場合には、前記自動更新条件の達成度合いを表す画像又はテキストを前記表示部に表示させることを特徴とする更新制御プログラム。
9. コンピュータにインストールされているソフトウェアを配信しているソフトウェア配信サーバ（２０）から、前記ソフトウェアの最新バージョンのバージョン情報と、少なくとも１種類の、最新バージョンの前記ソフトウェアに対する信頼性を評価するために用いられる管理要素についての情報（以降、管理要素情報）と、を取得するソフトウェア情報取得部（Ｆ１３）と、
   ユーザ操作に基づいて、少なくとも１つの前記管理要素に対して設定される、前記ソフトウェアを最新バージョンへと更新するべきか否かの判定に用いられる自動更新条件を取得する自動更新条件取得部（Ｆ１２）と、
   前記ソフトウェア情報取得部が取得した前記バージョン情報及び前記管理要素情報と、現在インストールされている前記ソフトウェアのバージョン情報と、前記自動更新条件取得部が取得した前記自動更新条件と、に基づいて、前記ソフトウェアを更新するべきか否かを判定する更新判定部（Ｆ１４）と、
   前記更新判定部が前記ソフトウェアを更新するべきであると判定したことに基づいて、前記ソフトウェアの更新を実施する更新実行部（Ｆ１５）として、前記コンピュータを機能させるための更新制御プログラムであって、
   前記ソフトウェア情報取得部は、少なくとも最新バージョンの前記ソフトウェアのダウンロード回数を前記管理要素情報として取得し、
   前記自動更新条件は、少なくともダウンロード回数に対する閾値であるダウンロード閾値を含んでおり、
   前記ダウンロード閾値は、当該ソフトウェアの最新バージョンよりも１つ前のバージョンの総ダウンロード回数に、ユーザ操作に基づいて定まる所定の割合を乗算して定まる値となっており、
   前記更新判定部は、
   現在インストールされている前記ソフトウェアが最新バージョンではなく、かつ、前記管理要素情報が前記自動更新条件を満たしている場合に、前記ソフトウェアを更新するべきであると判定する一方、前記ソフトウェアが最新バージョンである場合、又は、前記管理要素情報が前記自動更新条件を満たしていない場合には、前記ソフトウェアを更新するべきではないと判定することを特徴とする更新制御プログラム。

Images