JP5972121B2 - アプリケーション管理システム、管理装置、アプリケーション実行端末、アプリケーション管理方法、アプリケーション実行端末の制御方法及びプログラム - Google Patents

Description

本発明は、端末でのアプリケーションの実行を抑制するシステム、装置、方法及びプログラムに関する。

従来、公開されたアプリケーションの不具合（市場障害）は、障害に遭遇したユーザがそのアプリケーションの提供元（開発元）のコールセンターに電話するなどして発見されていた。障害情報を収集する手段として、アプリケーション実行端末上でエラー検出プログラムを動作させ、発生したエラーをサーバに通知する手法も普及しつつある。アプリケーションの提供元は、収集された障害情報に基づいて、障害が起きるアプリケーションをユーザに通知する。また、対策を施したアプリケーションを改めて開発し、市場障害の抑制を行うこともある。

市場障害を抑制する手法の一つは、収集した障害情報をユーザに通知する手法である。収集した障害情報をユーザに通知する手段としては、サーバ上で管理する情報に各端末がネットワークを介してアクセスし、取得した情報に該当するアイコンの描画を変更する手法が知られている。（例えば特許文献１参照）また、エラーが発生した端末と関連する端末に、サーバがエラーを通知する手法が知られている（例えば特許文献２参照）。

市場障害を抑制するためのより高度な手段として、障害が起きるアプリケーションのインストールや実行を制御する方法がある。端末がインストール時にサーバにアプリケーションのインストールを許可するか否かを判断し、端末がその判断結果に基づいてインストールする手法が知られている。（例えば特許文献３参照）また、ある機種がＡ４の横向きでホチキス留めで印刷しようとしたときに不具合が起きる、といった情報をＭＦＰのサービスマンが報告し、サーバに手動で障害辞書を作成することが知られている。印刷設定ソフトは印刷前にユーザが指示した印刷設定が障害発生条件となっているかを確認し、障害が発生する設定ならユーザにダイアログで通知する。（例えば特許文献４参照）また、アプリケーションのインストール状態に応じてアイコンクリック時の動作を変更する手法が知られている。（例えば特許文献５参照）

特開平１１―２３２２２３号公報 特開２００２−１４８８０号公報 特開２００２−４９４３４号公報 特開２００６−２４３９１１号公報 特開２００４−５２５４号公報

特許文献１では、サーバ上のデータに応じて、全端末がアイコンの描画を変更する。しかしながら、アイコンクリック時の動作は変更されない。

特許文献２では、ある端末で発生したエラーが、別の端末上にも表示される。しかしながら、どの端末でエラーが発生する可能性があるのかを考慮していない。

特許文献３では、端末がアプリケーションをインストールする際に、インストールの判断をサーバに委ねる。しかし、サーバ側でどのようにインストールの判断を行うかは考慮されていない。

特許文献４では、市場障害の対策版アプリケーションが提供可能になる迄の期間、既知の障害に対する回避手段を含む情報ファイル（障害辞書）をクライアント環境に送信する。また、障害辞書ファイルをサーバ装置から常時リモート更新可能とすることで、障害の発生を予防する。しかし、どのような条件の端末で障害が発生するのかを判定して障害辞書を作成することは行っていない。

特許文献５では、端末上にインストール可能なアプリケーションのアイコンをすべて表示し、アイコンクリック時にそのアプリケーションがインストール済みであれば起動する。未インストールであれば、インストールするかをユーザに問うダイアログを表示した上で、インストールを行う。しかし、アイコンクリック時の動作を変更する条件は、その端末内でのアプリケーションのインストール状態のみである。

多数のアプリケーションがアプリケーション配布サーバに登録され、多様な端末の利用者がアプリケーション配布サーバから任意のアプリケーションをダウンロードして利用する環境を想定する。すると、アプリケーションの公開後に不具合が見つかった場合、そのアプリケーションの実行を抑制することが必要となる。しかし、不具合が起きる条件はアプリケーションと端末の組み合わせによる場合があり、不具合が起きたアプリケーションを全てのユーザ端末に通知する必要はない。

本発明は上記の課題に鑑みてなされたものであり、特定の端末でアプリケーションのエラーが起こる条件を検出する。エラーの起こる可能性のある端末（ユーザ）に絞って、エラーが起きるアプリケーションの実行を抑制させるアプリケーション管理システム、管理装置、アプリケーション実行端末、管理方法、アプリケーション実行端末の制御方法及びプログラムを提供することを目的とする。

本発明に係る管理装置は、以下の構成を備える。即ち、接続可能な複数の端末を管理する管理装置であって、アプリケーションをインストールした複数の端末から前記アプリケーションのエラー情報を受信する受信手段と、前記複数の端末に関する情報と、前記複数の端末にインストールされた前記アプリケーションの情報とを管理する管理手段と、前記エラー情報と前記複数の端末に関する情報と前記アプリケーションの情報とに基づいて、前記アプリケーションがエラーを起こす条件を判定する判定手段と、インストールされた前記アプリケーションがエラーを起こす条件を満たしていることを示す情報を、前記複数の端末のうち当該条件を満たす端末に送信する送信手段。

本発明に係るアプリケーション実行端末は、以下の構成を備える。即ち、複数の端末を管理する管理装置に接続され管理されている端末であって、前記管理装置が判定した、アプリケーションがエラーを起こす条件を受信する受信手段と、前記エラーを起こす条件を満たすアプリケーションの表示形態を変更して表示させる表示制御手段。

本発明に係るアプリケーション実行端末は、以下の構成を備える。即ち、複数の端末を管理する管理装置に接続され管理されている端末であって、前記管理装置が判定した、アプリケーションがエラーを起こす条件を受信する受信手段と、前記エラーを起こす条件を満たすアプリケーションの起動の指示を受けると、エラーを起こす条件を満たしていることに基づくメッセージを表示させる表示制御手段。

本発明に係るアプリケーション実行端末は、以下の構成を備える。即ち、複数の端末を管理する管理装置に接続され管理されている端末であって、自端末にインストールされているアプリケーションの情報を管理する管理手段と、前記管理装置から、前記アプリケーションのエラー情報と前記アプリケーションがインストールされた複数の端末に関する情報とを受信する受信手段と、前記エラー情報と前記複数の端末に関する情報と前記アプリケーションの情報とに基づいて、前記アプリケーションがエラーを起こす条件を判定する判定手段と、前記アプリケーションのうち、前記エラーを起こす条件を満たすアプリケーションの表示形態を変更して表示させる表示制御手段。

本発明に係るアプリケーション実行端末は、以下の構成を備える。即ち、複数の端末を管理する管理装置に接続され管理されている端末であって、自端末にインストールされているアプリケーションの情報を管理する管理手段と、前記管理装置から、前記アプリケーションのエラー情報と前記アプリケーションがインストールされた複数の端末に関する情報とを受信する受信手段と、前記エラー情報と前記複数の端末に関する情報と前記アプリケーションの情報とに基づいて、前記アプリケーションがエラーを起こす条件を判定する判定手段と、前記アプリケーションのうち、前記エラーを起こす条件を満たすアプリケーションの起動の指示を受けると、エラーを起こす条件を満たしていることに基づくメッセージを表示させる表示制御手段。

本発明によれば、アプリケーションを実行するとエラーが起きる条件を満たす端末に絞って、エラーが起きるアプリケーションの実行の抑制をすることができる。

（ａ）サーバ及び端末のハードウェア構成の一例を示す図 （ｂ）サーバ及び端末のシステム構成の一例を示す図 実施形態１にかかるサーバと端末の機能のブロック図 実施形態１にかかるアプリケーションのインストール処理手順を示すフローチャート 実施形態１にかかるアプリケーションのエラー検知とエラー報告の手順を示すフローチャート 実施形態１にかかるエラー条件判定の手順を示すフローチャート （ａ）実施形態１にかかるエラー報告管理テーブルを示す図 （ｂ）実施形態１にかかるエラー条件判定テーブルを示す図 実施形態１にかかるエラー通知受信時の処理の手順を示すフローチャート 実施形態１にかかるアプリケーションのアイコンクリック時の処理の手順を示すフローチャート 実施形態２にかかるサーバと端末の機能のブロック図 実施形態２にかかるエラー報告受信時のサーバの処理の手順を示すフローチャート 実施形態２にかかるエラー条件判定の手順を示すフローチャート （ａ）実施形態３にかかるエラー条件判定テーブルを示す図 （ｂ）実施形態３にかかるエラー条件判定テーブルを示す図 （ａ）実施形態４にかかるエラー報告管理テーブルを示す図 （ｂ）実施形態４にかかるエラー条件判定テーブルを示す図 （ａ）実施形態５にかかるエラー報告管理テーブルを示す図（ｂ）実施形態５にかかるエラー条件判定テーブルを示す図 実施形態６にかかるエラー条件判定結果の通知処理の手順を示すフローチャート 実施形態６にかかるアプリケーションのアイコンクリック時の処理の手順を示すフローチャート 実施形態７にかかるサーバと端末の機能のブロック図 実施形態７にかかるアプリケーションのインストール処理手順を示すフローチャート 実施形態８にかかるエラー条件判定処理の手順を示すフローチャート （ａ）実施形態１にかかるアイコンの変化例を示す図 （ｂ）実施形態１にかかる端末識別情報管理テーブルを示す図 （ｃ）実施形態１にかかるアプリケーションインストール状態管理テーブルを示す図 実施形態５にかかるアプリケーション実行状態管理テーブルを示す図 実施形態１にかかるエラー報告受信時の処理の手順を示すフローチャート 実施形態２にかかるアプリケーションのリスト受信時のサーバの処理の手順を示すフローチャート 実施形態９にかかるアプリケーションのエラー検知とエラー報告の手順を示すフローチャート 実施形態１０にかかるアプリケーションのエラー検知とエラー報告の手順を示すフローチャート

以下、添付の図面を参照して、本発明の好適な実施形態を詳細に説明する。なお、以下の実施形態において示す構成は一例に過ぎず、本発明は図示された構成に限定されるものではない。

＜実施形態１＞
図１（ａ）は、サーバ２０２及び端末２０１のハードウェアとして想定される、一般的な情報管理装置１０１のハードウェア構成の一例を示す図である。図１（ａ）に示されるように情報管理装置１０１は、ハードウェア構成として、ＣＰＵ１１を含む。

ＣＰＵ１１が、記憶装置１３に記憶されている後述するアプリケーションやプログラム実行環境等の各々に対応するプログラムに基づき処理を行うことによって、後述する各機能、又はフローチャートを実現する。

また、ＣＰＵ１１には、バス１０を介して、入力装置１２、記憶装置１３及び表示装置１４が接続されている。記憶装置１３は、例えば、ＲＯＭ、ＲＡＭ、ハードディスク装置等からなり、上述した各プログラム以外に、プログラムに基づく処理で用いられるデータ等を記憶する。表示装置１４は、画面等を表示するディスプレイである。制御プログラムは、表示装置の表示制御を行う。入力装置１２は、情報を入力するキーボード及び／又はマウスである。外部接続ＩＦ１５は、ネットワークインタフェース、外部機器との各種接続インタフェースである。

尚、ＣＰＵ１１はプログラムを実行することで各種の手段として機能することが可能である。なお、ＣＰＵ１１と協調して動作するＡＳＩＣなどの制御回路がこれらの手段として機能してもよい。また、ＣＰＵ１１と画像処理装置の動作を制御する制御回路との協調によってこれらの手段が実現されてもよい。また、ＣＰＵ１１は単一のものである必要はなく、複数であってもよい。この場合、複数のＣＰＵ１１は分散して処理を実行することが可能である。また、複数のＣＰＵ１１は単一のコンピュータに配置されていてもよいし、物理的に異なる複数のコンピュータに配置されていてもよい。なお、ＣＰＵ１１がプログラムを実行することで実現する手段が専用の回路によって実現されてもよい。

次に、情報管理装置１０１上に構築するシステム構成について、図１（ｂ）を用いて説明する。図１（ｂ）は、情報管理装置１０１のシステム構成の一例を示す図である。

オペレーティングシステム１０００１は、システム全体の基盤となるソフトウェアである。アプリケーション実行環境１０００２は、例えば仮想マシンのように、オペレーティングシステム１０００１上のプロセスでありながら、自身の上でアプリケーションが動作する環境を提供するソフトウェアである。アプリケーション実行環境１０００２は、各アプリケーション１０００３の動作状態を管理する機能を含む。

本実施形態で用いるサーバ２０２と端末２０１のハードウェア構成とシステム構成は、情報管理装置１０１と同様である。サーバ２０２には、多数の接続可能な端末２０１が接続される。各端末２０１のハードウェア構成とオペレーティングシステム１０００１は、機種やバージョンによる違いが存在しうる。また、各端末２０１はインストールするアプリケーションを個々に選択するため、システム構成も一様とはならない。このため、アプリケーションは多様な実行環境で動作し、特定の条件を満たす実行環境ではエラーが発生することがある。

そこで、ある端末で発生したエラー情報をもとにエラーが起きる条件を検出し、条件を満たす実行環境でアプリケーションを動作させているユーザの端末に警告することが課題となる。また、エラーが起きるアプリケーションの実行をユーザが容易に停止できる仕組みも課題となる。

本実施形態は、これらの課題を解決するために、サーバ２０２と端末２０１から構成されるシステムによって、エラーが発生する可能性のあるアプリケーションのアンインストールとアップデートをユーザが容易に指示できる仕組みを実現する。

次に、サーバ２０２と端末２０１から構成されるシステムの具体的な動作について説明する。初めに、端末２０１がアプリケーションをインストールする動作について、図２、図３、図２０（ｂ）、図２０（ｃ）を用いて説明する。図２は、サーバ２０２と端末２０１が備える機能を示すブロック図である。図３は、アプリケーション管理部２０３がアプリケーションをインストールする処理を示すフローチャートである。フローチャートは、ＣＰＵが制御プログラムを実行することにより実現されるものとする。図２０（ｂ）は、端末情報管理部２０６が端末識別情報を管理する端末識別情報管理テーブル２００２である。図２０（ｃ）は、端末情報管理部２０６がアプリケーションのインストール状態を管理するアプリケーションインストール状態管理テーブル２００３である。

端末２０１は、アプリケーション実行環境１０００２内に、アプリケーション管理（インストール・アップデート・アンインストール・スタート）を行うアプリケーション管理部２０３をもつ。アプリケーションは、各アプリケーションで一意となるアプリケーションＩＤをもつ。また、修正版によるアップデートを管理するため、アプリケーションはバージョン番号をもつ。以降、アプリケーションＩＤとバージョン番号を含む情報を、アプリケーション識別情報と記す。また、端末２０１は、端末の機種の名前である端末機種名と、各端末で一意となる端末ＩＤと、ファームウェアやハード構成によって異なる端末バージョンをもっている。以降、端末機種名、端末ＩＤ、端末バージョンを含む情報を、端末識別情報と記す。端末識別情報は後述するＰＵＳＨ通信のために、端末のＩＰアドレスを含んでもよい。

端末２０１はアプリケーションのインストール開始時に、アプリケーションのプログラムを取得する（ステップＳ３０１）。取得は入力装置１２のネットワークや記憶装置１３を介して行われる。アプリケーションを取得すると、アプリケーション管理部２０３はインストールを行う（ステップＳ３０２）。インストールが完了すると、アプリケーション管理部２０３は、インストールしたアプリケーションのアプリケーション識別情報と端末識別情報をサーバ２０２の端末情報管理部２０６に送信する（ステップＳ３０３）。送信が完了すると、インストールは終了する。ただし、インストールを終了する条件に、送信の完了は必須ではない。端末２０１がネットワークにアクセスできない場合などは、送信を後回しにすることも可能である。

サーバ２０２は、送信されたアプリケーション識別情報と端末識別情報を端末情報管理部２０６で管理する。端末識別情報は、端末識別情報管理テーブル２００２で管理される。送信された情報から、端末２０１がアプリケーションをインストールしたとわかるため、端末情報管理部２０６は、アプリケーションインストール状態管理テーブル２００３に、送信されたアプリケーション識別情報と、端末識別情報の端末ＩＤを追加する。

次に、端末２０１で動作するアプリケーションがエラーを発生させた場合の動作について、図２、図４を用いて説明する。図４は、アプリケーション実行中にエラーが起きた場合のエラー検知部２０４の処理を示すフローチャートである。フローチャートは、ＣＰＵが制御プログラムを実行することにより実現されるものとする。

端末２０１で動作するアプリケーションは、アプリケーション管理部２０３によってスタートされる。アプリケーション実行環境１０００２は、アプリケーションが実行中に発生させた例外やエラーを、エラー検知部２０４によって検知する（ステップＳ４０１）。エラーが起きると、エラー検知部２０４はプログラムスタックを解析し、エラーを起こしたアプリケーションを特定する。そして、エラーが起きたアプリケーションのアプリケーション識別情報、エラー発生時のプログラムスタックの情報（エラーメッセージ）、端末識別情報をサーバに送信する（ステップＳ４０２）。以降、エラーが起きたアプリケーションのアプリケーション識別情報、エラー発生時のプログラムスタックの情報（エラーメッセージ）、端末識別情報を含むメッセージを、エラー報告と記す。

次に、サーバ２０２が端末２０１からエラー報告を受信した場合の動作について、図２、図２２，図６（ａ）、図６（ｂ）を用いて説明する。図２２は、エラー報告受信時のサーバ２０２の動作を示すフローチャートである。フローチャートは、ＣＰＵが制御プログラムを実行することにより実現されるものとする。図６（ａ）は、エラー報告管理部２０５が受信したエラー報告の管理に用いるエラー報告管理テーブル６０１である。図６（ｂ）は、エラー条件判定部２０７がエラーの起きる条件を検出するのに用いるエラー条件判定テーブル６０２である。

サーバ２０２は、エラー報告を受信すると、エラー報告管理部２０５で処理を開始する。本実施形態では、今回新たに受信したエラー報告の内容は、エラー報告管理テーブル６０１の３行目の内容とする。また、アプリケーションをインストールした端末数に占めるエラーを報告した端末数の割合を、エラー発生率と定義する。エラー条件判定部２０７は、エラー発生率が５０％以上の場合、エラー条件を満たしていると判定する。

初めに、エラー報告管理部２０５は、受信したエラー報告をエラー報告管理テーブル６０１に記録する（ステップＳ２２０１）。ステップＳ２２０１において、エラー報告管理部２０５は、受信した報告からアプリケーションＩＤ＝ＡｐｐＩＤ＿１のアプリケーションがエラーを起こしたと認識する。以降、アプリケーションＩＤ＝ＡｐｐＩＤ＿１のアプリケーションをアプリケーションＡと記す。

エラー報告管理部２０５は、エラー報告を記録すると、エラー条件の判定を行うかどうかを判断する（ステップＳ２２０２）。これは、エラー条件の判定をエラー報告受信の度に行うと負荷が高くなるためである。判断の方法としては、最後に判定を行なってから、一定数のエラー報告を受信した場合にエラー条件の判定を行うことが考えられる。また、一日一回、決まった時刻にエラー条件の判定を行うことも考えられる。本実施形態では、アプリケーションＡのエラー報告を受信した例で説明する。

ステップＳ２２０２でエラー条件の判定を行うと判断した場合、エラー報告管理部２０５は、アプリケーションＡをインストールしている端末の端末識別情報を、端末情報管理部２０６から取得する（ステップＳ２２０３）。取得後、エラー報告管理部２０５は、アプリケーションＡをインストールしている端末の端末識別情報とエラー報告管理テーブル６０１の情報を、エラー条件判定部２０７に送信し、エラー条件の判定を行わせる（ステップＳ２２０４）。

ただし、エラー条件判定部２０７に送信する情報は、エラー報告管理テーブル６０１の全ての情報でなくてもよい。例えば、エラー条件判定部２０７は、エラーが１００回以上報告されたアプリケーションについて、エラー条件を判定するとする。このとき、エラー報告管理部２０５は、アプリケーションごとにエラー報告を集計し、エラー報告が１００回以上報告されたアプリケーションに関する情報をエラー条件判定部２０７に与えることで、与えるデータサイズを削減できる。

次に、エラー条件の判定処理について、図５を用いて説明する。図５は、エラー条件判定部２０７がエラー条件の判定を行う動作を示すフローチャートである。フローチャートは、ＣＰＵが制御プログラムを実行することにより実現されるものとする。

エラー条件判定部２０７は、送信された情報からエラーが起きる条件を判定する。エラー条件判定部２０７は判定において、アプリケーションＡをインストール済みの端末数を端末機種名ごとに集計し、エラー条件判定テーブル６０２を作成する（ステップＳ５０１）。または、前回の判定で作成したエラー条件判定テーブル６０２を保持しておき、更新する。エラー条件判定テーブル６０２を確認すると、アプリケーションＡは端末機種名がＤｅｖｉｃｅ＿Ｘの場合に、エラー発生率が５０％となっており、所定のエラー発生率を上回っているとわかる（ステップＳ５０２）。そのため、エラー条件判定部２０７はアプリケーションＡのエラー条件を端末Ｄｅｖｉｃｅ＿Ｘにインストールされた場合であると判定する。そして、エラー条件判定部２０７は、テーブル２００２、２００３を参照し、アプリケーションＡをインストールしている端末機種情報から、端末機種名がＤｅｖｉｃｅ＿Ｘである端末にアプリケーションＡがエラーを起こす条件を満たしていることを通知する（ステップＳ５０３）。以降、この通知をエラーアプリ通知と記す。エラーアプリ通知の手段には、サーバ２０２から端末２０１へのＰＵＳＨ送信や、端末２０１がサーバ２０２をポーリングする方法が挙げられる。

次に、端末２０１がエラーアプリ通知を受信したときの処理を、図２、図７、図２０（ａ）を用いて説明する。図７は、端末２０１がエラーアプリ通知を受信したときの処理を示すフローチャートである。フローチャートは、ＣＰＵが制御プログラムを実行することにより実現されるものとする。図２０（ａ）は、ステップＳ７０１で、アプリケーション管理部２０３がアイコンに与えるエフェクトの例を示す図である。

端末２０１はエラーアプリ通知を受信すると、アプリケーション管理部２０３に転送する。アプリケーション管理部２０３はエラーアプリ通知を受け取ると、エラーアプリ通知の受信処理を開始する。アプリケーション管理部２０３は、エラーを起こす条件をみたしたアプリケーションＡのアイコンに、ユーザの注意をひきつけるエフェクトを加えて表示形態を変更し、表示するという変更を行う（ステップＳ７０１）。エフェクトの例としては、図２０（ａ）のテーブル２５０１に示すように、発煙エフェクト、炎上エフェクト、明度低下エフェクト、ワンポイント付与エフェクトが考えられる。アプリケーション管理部２０３は、アプリケーションＡのアイコンクリック時の動作を変更する（ステップＳ７０２）。変更処理が完了すると、エラーアプリ通知の受信処理は終了する。ただし、アプリケーションのイメージ低下を避けるために、ステップＳ７０１を省略してもよい。また、ステップＳ７０１において、エラーが起きるアプリケーションをユーザが起動しにくいように、アイコンを別の画面やフォルダに移動させることも考えられる。

次に、端末２０１が表示するアプリケーションのアイコンをクリックした時のアプリケーション管理部２０３の動作について、図８のフローチャートを用いて説明する。フローチャートは、ＣＰＵが制御プログラムを実行することにより実現されるものとする。

アプリケーションのアイコンがクリックされると、アプリケーション管理部２０３は、アイコンに対応するアプリケーションの起動処理を開始する。アプリケーション管理部は、受信済みのエラーアプリ通知によって、起動対象のアプリケーションがエラー条件を満たすかを確認する（ステップＳ８０１）。

起動対象のアプリケーションがエラー条件を満たす場合、アプリケーション管理部２０３はユーザにアプリケーションのアンインストールを提案するダイアログを表示する（ステップＳ８０２）。アンインストールの提案以外にも、起動対象アプリケーションは、エラーの発生率が高いことが報告されているというメッセージを出してもよい。その他、アップデートすることを勧めるメッセージを出してもよい。

ユーザが提案ダイアログの選択肢を選択すると、アプリケーション管理部２０３はユーザがアンインストールに同意したかを確認する（ステップＳ８０３）。

ユーザがアンインストールに同意した場合、アプリケーション管理部２０３はアンインストール処理を実行する（ステップＳ８０４）。

ユーザがアンインストールに同意しなかった場合、またはステップＳ８０２において起動対象のアプリケーションがエラー条件を満たさない場合は、アプリケーションのスタート処理を実行する（ステップＳ８０５）。

以上の処理を終えると、アプリケーションのアイコンをクリックしたときの処理は終了する。

以上、エラー条件判定部２０７がサーバ２０２に備わる場合の実施形態を説明した。アプリケーションの実行エラーが発生する端末の条件を判定し、エラー条件を満たすユーザの端末に絞って通知することで、精度よくエラーアプリ通知を送ることができる。また、ユーザの端末での、エラーの発生確率が高いアプリケーションのアイコンの変更または、アイコンクリック時の動作の変更をすることで、エラーが発生し易いアプリケーションの実行を抑制することができる。

＜実施形態２＞
次に、実施形態２にかかる端末２０１とサーバ２０２の動作について説明する。端末２０１とサーバ２０２とのハードウェア構成は図１に示した構成の通りである。

エラー条件判定部２０７は、エラーが起きたアプリケーションがインストールされている端末の情報とエラー報告管理テーブル６０１の内容があれば、エラーの条件を判定できる。そのため、エラー検知部２０４がサーバ２０２にエラー報告を送信した際に、エラー報告管理部２０５はステップＳ２２０４でエラー条件判定部２０７に与えた情報を端末２０１に応答すれば、エラー条件判定部２０７を端末２０１に備える構成を実現できる。

サーバ２０２は端末情報管理部２０６とエラー報告管理部２０５を備え、端末２０１がエラー条件判定部２０７を備える実施形態を、実施形態２として説明する。

端末２０１がアプリケーションをインストールする動作は、実施形態１と同様である。また、端末２０１で動作するアプリケーションがエラーを発生させた場合の動作も、実施形態１と同様である。また、端末２０１は、まだアプリケーションの実行エラーが発生していなくても、自端末にインストール済みのアプリケーションがエラーを生じる可能性がないかを確認する。そのために、端末２０１は、一定時間おきにサーバ２０２にインストール済みのアプリケーションのリストを送信し、リストに存在するアプリケーションに対応するエラー報告管理テーブル６０１の情報を取得する。

はじめに、サーバ２０２がエラー報告を受信した場合の動作について、図６（ａ）、図９、図１０を用いて説明する。図９は、サーバ２０２と端末２０１が備える機能を示すブロック図である。図１０は、エラー報告受信時のサーバ２０２の動作を示すフローチャートである。フローチャートは、ＣＰＵが制御プログラムを実行することにより実現されるものとする。

サーバ２０２は、エラー報告を受信すると、エラー報告管理部２０５で処理を開始する。受信したエラー報告はエラー報告管理テーブル６０１の３行目の内容とする。

初めに、エラー報告管理部２０５は、受信したエラー報告を、エラー報告管理テーブル６０１に記録する（ステップＳ１００１）。ステップＳ１００１において、エラー報告管理部２０５は、受信した報告からアプリケーションＡ（定義は実施形態１を参照）がエラーを起こしたと認識する。

次に、エラー報告管理部２０５はステップＳ２２０３と同様に、アプリケーションＡをインストールしている端末の端末識別情報を、端末情報管理部２０６から取得する（ステップＳ１００２）。取得後、エラー報告管理部２０５は、アプリケーションＡをインストールしている端末の情報とエラー報告管理テーブル６０１の情報を、端末２０１に応答する（ステップＳ１００３）。ただし、エラー報告管理テーブル６０１の情報をすべて応答する必要はない。応答メッセージのサイズを削減するために、アプリケーションＡに関するエラー報告に絞ったテーブルを応答してもよい。また、エラー報告管理テーブル６０１の要素から、エラーメッセージや端末ＩＤの要素を削除して応答してもよい。また、端末情報管理部２０６から取得した端末識別情報を、機種ごとの端末数に集約して応答してもよい。また、サーバ２０２から端末２０１へのプッシュ通信が可能な環境であれば、アプリケーションＡをインストール済みの全端末に応答メッセージを送信してもよい。端末２０１へ応答すると、エラー報告受信の処理は終了する。

次に、エラー検知部２０４がエラー報告の応答をサーバ２０２から受信した場合の動作について、図９、図１１を用いて説明する。図１１は、端末２０１のエラー条件判定部２０７がエラー条件を判定する動作を示すフローチャートである。フローチャートは、ＣＰＵが制御プログラムを実行することにより実現されるものとする。実施形態２では、エラー条件判定部２０７が端末２０１側にある。

エラー検知部２０４が受信したエラー報告の応答には、アプリケーションＡをインストールしている端末の情報と、エラー報告管理テーブル６０１の情報が含まれている。エラー検知部２０４は、エラー条件判定部２０７にこれらの情報を与える。

エラー条件判定部２０７は、与えられた情報からエラーが起きる条件を判定する（ステップＳ１１０１）。判定する処理は、ステップＳ５０１、Ｓ５０２と同様である。そして、エラー条件判定部２０７は、自端末がエラー条件を満たすかどうかを判定する（ステップＳ１１０２）。自端末がエラー条件を満たす場合、ステップＳ７０１、Ｓ７０２と同様の処理を行う（ステップＳ１１０３、Ｓ１１０４）。

次に、サーバ２０２が端末２０１からインストール済みのアプリケーションのリストを受信した場合の動作を図２３のフローチャートを用いて説明する。フローチャートは、ＣＰＵが制御プログラムを実行することにより実現されるものとする。

サーバ２０２は、アプリケーションのリストを受信すると、エラー報告管理部２０５で処理を開始する。はじめに、エラー報告管理部２０５はステップＳ２２０３と同様に、リストに含まれる各アプリケーションをインストールしている端末の端末識別情報を、端末情報管理部２０６から取得する（ステップＳ２３０１）。取得後、エラー報告管理部２０５は、各アプリケーションをインストールしている端末の情報とエラー報告管理テーブル６０１の情報を、端末２０１に応答する（ステップＳ２３０２）。応答するメッセージのサイズを削減するために、応答内容をステップＳ１００３と同様の処理を行なってもよい。

端末２０１は、応答を受信すると、ステップＳ１１０１、Ｓ１１０２、Ｓ１１０３、Ｓ１１０４と同様の処理を行う。

以上、エラー条件判定部２０７が端末２０１に備わる場合の実施形態を説明した。

＜実施形態３＞
アプリケーションはアップデートによって変更されうる。また、端末２０１も、アップデートによって変更されうる。エラー条件判定テーブル６０２では、アプリケーションＩＤと端末機種名でエラー条件を判定したが、アプリケーションバージョンと端末バージョンを考慮することで、より正確な判定が可能となる。エラー条件判定部２０７がアプリケーションバージョンと端末バージョンを考慮する実施形態を、実施形態３として説明する。エラー条件判定部２０７は、端末２０１側、サーバ２０２側どちらにあってもよい。

実施形態３にかかるエラー条件判定部２０７の動作について、図１２（ａ）、図１２（ｂ）を用いて説明する。図１２（ａ）のテーブルは、エラー条件判定部２０７が作成する、アプリケーションＡのバージョン１．０のエラー発生率を求めるためのエラー条件判定テーブル１２０１である。図１２（ｂ）は、アプリケーションＡのバージョン２．０のエラー発生率を求めるためのエラー条件判定テーブル１２０２である。端末２０１とサーバ２０２とのハードウェア構成は図１に示した構成の通りである。

端末２０１がアプリケーションＡに関するエラー報告を送信したときを例として説明する。アプリケーションＡには、バージョン１．０と２．０が存在するものとする。また、機種名Ｄｅｖｉｃｅ＿Ｘの端末２０１には、端末バージョン１と端末バージョン２のものが存在するとする。また、機種名Ｄｅｖｉｃｅ＿Ｙの端末２０１には、端末バージョン１のみが存在するものとする。

エラー報告管理部２０５はエラー報告を受信すると、ステップＳ２２０４と同様にエラー条件判定部２０７に情報を送信する。

エラー条件判定部２０７は、アプリケーションＡのバージョン１．０に関するエラー条件判定テーブル１２０１と、アプリケーションＡのバージョン２．０に関するエラー条件判定テーブル１２０２を作成する。または、前回の判定で作成したエラー条件判定テーブル１２０１，エラー条件判定テーブル１２０２を保持しておき、更新する。

各テーブルは、端末２０１を端末機種名と端末バージョンで分類している。エラー条件判定部２０７は、分類した各列に対して、インストール端末数とエラー発生端末数から求めたエラー発生率を計算する。そして、エラー発生率が５０％以上であるアプリケーション、アプリケーションバージョン、端末機種名、端末バージョンの組み合わせをエラー条件と判定する。テーブル１２０１の場合、アプリケーションＡかつアプリケーションバージョン１．０かつ端末機種名Ｄｅｖｉｃｅ＿Ｙかつ端末バージョン１をエラー条件と判定する。またテーブル１２０２の場合、エラー発生率が１００％であるアプリケーションＡかつアプリケーションバージョン２．０かつ端末機種名Ｄｅｖｉｃｅ＿Ｘかつ端末バージョン２を、エラー条件と判定する。このように、アプリケーションと端末２０１のバージョンを勘案することで、エラー条件の判定精度を高めることが可能となる。

ただし、アプリケーションＩＤの設定方法によっては、アプリケーションバージョンの情報を用いずに、同等の精度で判定が可能である。アプリケーションのバージョンが違う場合はアプリケーションＩＤが異なるようにアプリケーションＩＤを設定するなら、アプリケーションのバージョン情報は必要ない。同様に、端末バージョンが異なる場合に端末機種名が異なるように端末機種名を設定するなら、端末バージョンの情報は必要ない。

以上、エラー条件判定部２０７がアプリケーションバージョンと端末バージョンを考慮する実施形態を説明した。

＜実施形態４＞
端末２０１で動作するアプリケーションは複数あるため、インストールしたアプリケーション間の組み合わせが原因でエラーが起きることがある。エラー条件判定部２０７が、アプリケーション間の組み合わせを考慮する実施形態を、実施形態４として説明する。

実施形態４にかかるエラー条件判定部２０７とエラー報告管理部２０５の動作について、図１３（ａ）、図１３（ｂ）を用いて説明する。図１３（ａ）は、エラー報告管理部２０５が管理するエラー報告の管理テーブル１３０１である。図１３（ｂ）は、エラー条件判定部２０７がエラー条件の判定のために作成するエラー条件判定テーブル１３０２である。端末２０１とサーバ２０２とのハードウェア構成は図１に示した構成の通りである。

エラー報告管理部２０５が、アプリケーションＡに関するエラー報告を受信する例で説明する。エラー報告管理部２０５は、エラー報告を受信するとステップＳ２２０１と同様の処理を行う。加えて、エラー報告管理部２０５は、エラー報告を送信した端末２０１がインストール済みのアプリケーションのリストも、エラー時端末情報としてエラー報告管理テーブル１３０１に保存する。インストール済みアプリケーションのリストは端末情報管理部２０６から取得してもよいし、端末２０１がエラー報告に含めてもよい。

例として、エラー報告管理部２０５が受信したエラー報告が、エラー報告管理テーブル１３０１の３行目の内容であり、エラー報告管理テーブルには２行目までの内容しか保持されていないとする。受信した報告は、端末ＩＤがＩＤ＿３である端末２０１からの報告である。ＩＤ＿３の端末２０１がインストール済みのアプリケーションのリストは、アプリケーションＩＤがＡｐｐＩＤ＿３０かつアプリケーションバージョンがｖ１、および、アプリケーションＩＤがＡｐｐＩＤ＿１０かつアプリケーションバージョンがｖ１のアプリである。そこで、エラー報告管理部はエラー報告管理テーブル１３０１の３行目の内容を、エラー報告管理テーブル１３０１に追加する。そしてエラー報告管理部２０５は、ステップＳ２２０４と同様にエラー条件判定部２０７に情報を送信する。

エラー条件判定部２０７は、ステップＳ５０１と同様に、エラー条件判定テーブル１３０２を作成する。または、前回の判定で作成したエラー条件判定テーブル１３０２を保持しておき、更新する。エラー条件判定テーブル１３０２は、アプリケーションＡをインストール済みの端末２０１を、他にインストール済みのアプリケーションの組み合わせで分けて集計したものである。前述のように、エラー条件判定部２０７は、エラー発生率が５０％以上の条件をエラー条件と判定する。エラー発生率は固定値でも良いし、可変にしてもよい。エラー条件判定テーブル１３０２より、アプリケーションＣをインストール済みの場合が、アプリケーションＡのエラー条件と判定される。このように、エラー条件判定部２０７がアプリケーションの組み合わせを考慮することで、エラー条件の判定精度を高めることが可能となる。

エラー条件の判定には、報告された大量のエラーログをデータマイニングで解析する。本実施形態では、解析対象要素を、アプリの種類、バージョンだけでなく、インストール済みのアプリリストに拡張することで、エラー発生率が高くなるアプリケーションの組み合わせを抽出している。

常にアプリの組み合わせによるエラーを判定すべきだが、解析対象要素を増やすと、データマイニングの負荷は高くなる。そこで、エラー条件判定部２０７を処理するサーバの負荷をトリガーとし、負荷が低い場合に、アプリの組み合わせによるエラーを判定することが考えられる。また、他のアプリに依存する場合、アプリの設定ファイルに依存するアプリが記載されていることがある。その場合、設定ファイルに依存するアプリが記載されていることをトリガーとして、アプリの組み合わせによるエラーを判定することも考えられる。

エラーアプリ通知を受信した端末のアプリケーション管理部２０３では、エラーアプリ通知の対象となっているアプリケーション実行時に、同時に実行するとエラーが発生する他のアプリケーションを示し、そのアプリを停止させることを提案することも考えられる。もちろん、エラーアプリ通知の対象となっているアプリケーションのアンインストールを提案してもよい。

以上、エラー条件判定部がアプリケーションの組み合わせを考慮する実施形態を説明した。エラー報告管理テーブル１３０１が管理するエラー時端末情報を、エラー時に実行中だったアプリケーションのリストとすることで、アプリケーションの実行の組み合わせによるエラー条件を判定することも可能である。

＜実施形態５＞
アプリケーションは実行されないとエラーを起こさない。そのため、アプリケーションをインストールしただけで実行をしない端末が存在すると、実施形態１で定義したエラー発生率ではエラーが起きる条件を正確に判定できない。アプリケーションの実行回数とエラー回数から求められる実行時エラー発生率を用いれば、より正確なエラー条件の判定が可能となる。エラー条件判定部が、アプリケーションの実行回数とエラー回数から求めた実行時エラー発生率によってエラー条件を判定する実施形態を、実施形態５として説明する。

実施形態５にかかるエラー条件判定部２０７とエラー報告管理部２０５の動作について、図１４（ａ）、図１４（ｂ）、図２１を用いて説明する。図１４（ａ）は、エラー報告管理部２０５が管理するエラー報告の管理テーブル１４０１である。図１４（ｂ）は、エラー条件判定部２０７がエラー条件の判定のために作成するエラー条件判定テーブル１４０２である。図２１は、端末情報管理部２０６が管理するアプリケーションの実行状態管理テーブル２１０１である。エラー条件判定部２０７は、アプリケーションの実行回数とエラー回数から求められる実行時エラー発生率が５０％以上の場合に、エラー条件と判定するものとする。端末２０１とサーバ２０２とのハードウェア構成は図１に示した構成の通りである。実施形態１では、エラー発生率を計算するときの分母がインストール端末数であったが、実施形態５では、エラー発生率を計算するときの分母が実行回数になっている。

アプリケーション管理部２０３は、アプリケーションが実行された回数を記録する。エラー報告を送信する直前、またはアプリケーションが一定回数実行される、または最後にサーバ２０２に実行回数を報告してから一定期間経つと、アプリケーション管理部２０３は記録した各アプリケーションの実行回数をサーバ２０２に報告する。報告を受信したサーバ２０２は、端末情報管理部２０６によって管理されているアプリケーション実行状態管理テーブル２１０１の実行回数を増分する。報告を終えると、アプリケーション管理部２０３は記録した実行回数を０に初期化する。

次に、エラー報告管理部２０５が、アプリケーションＡに関するエラー報告を受信する処理を説明する。エラー報告管理部２０５は、エラー報告を受信するとステップＳ２２０１と同様の処理を行う。そしてエラー報告管理部２０５は、ステップＳ２２０４と同様にエラー条件判定部２０７に情報を送信する。エラー判定部２０７に送信する情報は、アプリケーションＡを実行したことがある端末２０１の情報とエラー報告管理テーブル１４０１の内容である。

エラー条件判定部２０７は、送信された情報からエラー条件判定テーブル１４０２を作成する。または、前回の判定で作成したエラー条件判定テーブル１４０２を保持しておき、更新する。エラー条件判定テーブル１４０２は、アプリケーションＡを実行したことがある端末２０１を機種名で分けて、その実行回数とエラー回数を集計したものである。エラー条件判定テーブル１４０２より実行時エラー発生率を求めると、Ｄｅｖｉｃｅ＿Ｘで実行された場合が５０％以上となる。そのため、アプリケーションＡのエラー条件は、Ｄｅｖｉｃｅ＿Ｘで実行された場合と判定される。このように、エラー条件判定部２０７がアプリケーションの実行回数を考慮してエラー条件を判定することで、アプリケーションをインストールしただけで実行しない端末が存在しても、正確にエラー条件を判定できる。

以上、エラー条件判定部２０７がアプリケーションの実行回数を考慮してエラー条件を判定する実施形態を説明した。

＜実施形態６＞
アプリケーションのエラー条件が判定され、報告されると、開発者はエラー条件でも動作する修正版を開発し、修正版にアップデートを促すことで対応することが一般的である。エラー条件が判定されるとすぐにユーザにアンインストールを促すのではなく、修正版が公開されるまで待ってから、ユーザにアップデートを促すことで、ユーザの満足度が高いサービスを実現できる。エラー条件判定後に、開発者に連絡して修正版が開発されるまでユーザに通知しない実施形態を、実施形態６として説明する。端末２０１とサーバ２０２とのハードウェア構成は図１に示した構成の通りである。

実施形態６にかかるエラー条件判定部２０７とアプリケーション管理部２０３の動作について、説明する。エラー条件判定部２０７は、サーバ２０２側にある。

初めに、エラー条件判定部２０７が判定した結果をアプリケーション管理部２０３に通知する動作について、図１５を用いて説明する。図１５は、エラー条件判定部２０７がエラー条件を判定した場合の開発者への連絡とユーザへの通知処理の流れを示すフローチャートである。フローチャートは、ＣＰＵが制御プログラムを実行することにより実現されるものとする。

開発者Ｄが開発したアプリケーションＡのエラー条件を、エラー条件判定部２０７が判定した例で説明する。前提として、一般的な技術であるために図２には図示していないものの、アプリケーションＡはアプリケーション配布サーバＳに登録されており、サーバ２０２はサーバＳと通信可能なものとする。エラー条件判定部２０７は、エラー条件を判定すると、開発者Ｄへの通知を開始する。まず、エラー条件判定部２０７は、アプリケーションＡのエラー条件を開発者Ｄへ連絡する（ステップＳ１５０１）。開発者Ｄへの連絡方法としては、アプリケーションを配布するサーバＳを経由して行う手法などが考えられるが、特に制限はない。サーバ２０２にアプリケーション配布機能を持たせてもよい。

エラー条件判定部２０７は開発者Ｄへの連絡を終えると、一定の期間が経過するまで、エラーアプリ通知を待機する（ステップＳ１５０２）。待機中は、開発者がアプリケーションＡの修正版をアップデートしたかを適宜確認する（ステップＳ１５０３）。修正版がアップデートされると、エラー条件判定部２０７はエラー条件を満たすアプリケーションＡをインストールしている端末２０１のアプリケーション管理部２０３に、アプリケーションＡの修正版があることを通知する（ステップＳ１５０５）。以降、この通知を修正版アプリ通知と記す。ステップＳ１５０２において一定の期間を経過してもアプリケーションＡの修正版が公開されなければ、エラー条件判定部２０７はエラーアプリ通知を行う（ステップＳ１５０４）。ステップＳ１５０４，Ｓ１５０５が完了すれば、エラー判定結果の通知は完了する。

次に、修正版アプリ通知、エラーアプリ通知の受信に伴う、アプリケーション管理部２０３の動作について、図１６を用いて説明する。図１６は、エラー条件判定部２０７からエラーアプリ通知、または修正版アプリ通知を受け取ったアプリケーション管理部２０３における、アプリケーションのアイコンクリック時の処理の流れを示すフローチャートである。フローチャートは、ＣＰＵが制御プログラムを実行することにより実現されるものとする。アプリケーション管理部が通知の受信によってアイコンのグラフィックを変化させる処理は、ステップＳ７０１、Ｓ７０２と同様である。

ユーザがアプリケーションのアイコンをクリックすると、アプリケーション管理部２０３はアイコンに対応するアプリケーションの起動処理を開始する。以降、起動処理を行うアプリケーションを起動対象アプリケーションと記す。アプリケーション管理部２０３は、起動対象アプリケーションがそれまでに受信したエラーアプリ通知、あるいは修正版アプリ通知に該当するかを確認する（ステップＳ１６０１）。起動対象アプリケーションが該当しなければ、通常通りアプリケーションを起動する（ステップＳ１６０６）。

ステップＳ１６０１で該当する場合、修正版アプリ通知をもとに起動対象アプリケーションの修正版が存在するかを確認する（ステップＳ１６０２）。修正版が存在する場合、アプリケーション管理部２０３は、ユーザにアップデートをするかを提案する（ステップＳ１６０３）。提案方法としては、ダイアログを表示する手法などがある。

ユーザが提案に対して回答すると、アプリケーション管理部２０３は回答内容によって処理を分岐する（ステップＳ１６０４）。ユーザがアップデートの提案に同意した場合、アプリケーション管理部２０３は起動対象アプリケーションをアップデートし（ステップＳ１６０５）、ステップＳ１６０６へ進む。ユーザがアップデートの提案に同意しなければ、そのままステップＳ１６０６へ進む。

ステップＳ１６０２において修正版が存在しなければ、アプリケーション管理部２０３はユーザにアンインストールを提案する（ステップＳ１６０７）。若しくは、起動しないことを提案する。そして、ユーザの回答内容を確認し（ステップＳ１６０８）、ユーザがアンインストールに同意すれば起動対象アプリケーションをアンインストールする（ステップＳ１６０９）。ユーザがアンインストールに同意しなければ、ステップＳ１６０６へ進む。

ステップＳ１６０９，Ｓ１６０６のいずれかの処理が完了すれば、アプリケーション管理部２０３は処理を終了する。また、同一の提案を複数回ユーザに行わないために、アプリケーション管理部２０３はステップＳ１６０３、Ｓ１６０７にてユーザに提案したのち、該当する通知を削除する、または無効にする処理を行ってもよい。

以上、エラー条件が判定されるとアプリケーションの修正版があるかどうかを確認し、アプリケーションの修正版が公開されていれば、ユーザにアップデートを促す実施形態を説明した。

＜実施形態７＞
ユーザが複数のアプリケーションからインストールするアプリケーションを選択するときを考える。このとき、エラー報告管理部２０５の情報を参照して、ユーザの環境で安定して動作するアプリケーションを推薦することで、ユーザの環境で発生するエラーを未然に防ぐことが可能となる。アプリケーション管理部２０３がエラー報告管理部２０５と端末情報管理部２０６の情報を参照して、ユーザがインストールするアプリケーションの選択を支援する実施形態を、実施形態７として説明する。

実施形態７にかかるアプリケーション管理部２０３と端末情報管理部２０６の動作について、図１７、図１８を用いて説明する。図１７は、サーバ２０２と端末２０１が備える機能を示すブロック図である。端末２０１とサーバ２０２とのハードウェア構成は図１に示した構成の通りである。図２との違いは、端末情報管理部２０６がエラー報告管理部２０５の情報を利用できる点である。図１８は、ユーザがインストールするアプリケーションを選択してインストールを行う際の、アプリケーション管理部２０３の動作を示すフローチャートである。フローチャートは、ＣＰＵが制御プログラムを実行することにより実現されるものとする。

ユーザはインストール可能なアプリケーションを表示するビューアを起動して、インストールするアプリケーションの選択を開始する。ビューアとしては、アプリケーションを管理するサーバＳへの接続クライアントなどが想定される。本実施形態では、アプリケーション管理部２０３がアプリケーションのビューア機能を備えるものとする。アプリケーション管理部２０３は、アプリケーションを管理するサーバＳから、端末２０１がインストール可能なアプリケーションの一覧をインストール候補リストとして取得する（ステップＳ１８０１）。ただし、インストール可能なアプリケーションをすべてリストに含めると、リストのサイズが大きくなってしまうため、インストール候補リストに含めるアプリケーションの選択にステップＳ１８０２以降を適用してもよい。

アプリケーション管理部２０３はインストール候補リストを取得すると、インストール候補リストのアプリケーションがアプリケーション実行環境１０００２と同一の環境で実行されたエラー発生率を、端末情報管理部２０６から取得する（ステップＳ１８０２）。取得のためにアプリケーション管理部２０３は、端末情報管理部に、インストール候補リスト、端末２０１の端末機種名、端末バージョンを含む問い合わせを送信する。

問い合わせを受信した端末情報管理部２０６は、エラー報告管理部２０５から取得した情報（エラー報告管理テーブル６０１）と端末識別情報管理テーブル２００２とアプリケーション実行状態管理テーブル２１０１を参照する。そして、端末２０１の端末機種名かつ端末バージョンにおける、インストール候補リスト内の各アプリケーションのエラー発生率を応答する。

また、実施形態４のようにアプリケーションの組み合わせによってエラーが起こりえる可能性を応答してもよい。負荷の軽減のために、エラー報告管理部２０５は、各アプリケーションの他アプリケーションとの組み合わせによる判定済みエラー条件をキャッシュしており、あるアプリケーションにとってエラー条件となるアプリケーションをすぐに応答できるとする。端末情報管理部２０６は、端末２０１がインストール済みのアプリケーションの一覧を、アプリケーションインストール状態管理テーブル２００３から、インストール済みアプリケーションリストとして取得する。端末情報管理部２０６は、インストール済みアプリケーションリストの各アプリケーションについて、エラー報告管理部２０５からエラー条件となるアプリケーションを取得する。エラー条件となるアプリケーションがインストール済みアプリケーションリストに含まれていると、エラー報告管理部２０５は、端末２０１にインストール候補リスト内の該当するアプリケーションがエラー条件を満たしている旨を応答する。

アプリケーション管理部２０３は応答を受信すると、エラー発生率を反映したアプリケーション一覧を表示する（ステップＳ１８０３）。反映の方法としては、実行された回数と発生したエラー数から求められる実行時エラー発生率が低いものを優先して表示したり、複数バージョンがインストール可能な場合はエラーが少ないバージョンを優先して表示することが考えられる。また、エラー発生率が高いアプリケーションのアイコンを、ステップＳ７０１で行ったようなエフェクトをつけて表示することもあり得る。ユーザが表示されたアプリケーションからインストールするアプリケーションを選択すると、アプリケーション管理部２０３はインストールを行い（ステップＳ１８０４）、処理は終了する。

以上、アプリケーション管理部２０３がエラー報告管理部２０５と端末情報管理部２０６の情報を参照して、ユーザがインストールするアプリケーションの選択を支援する実施形態を説明した。

＜実施形態８＞
エラー条件判定部２０７がエラー条件を判定する閾値を、アプリケーションごとに変えることがある。例えば、自社製のアプリケーションはエラー発生率が１０％以上でエラー条件を満たすと判定し、他社製のアプリケーションはエラー発生率が３０％以上でエラー条件を満たすと判定する場合である。エラー条件判定部２０７がエラー条件を判定する方法を、アプリケーションの開発元に応じて変える場合の実施形態を、実施形態８として説明する。端末２０１とサーバ２０２とのハードウェア構成は図１に示した構成の通りである。

実施形態８にかかるエラー条件判定部２０７の動作について、図１９を用いて説明する。図１９は、アプリケーションの開発元によってエラー条件判定部２０７が判定条件を変更する処理の流れを示すフローチャートである。フローチャートは、ＣＰＵが制御プログラムを実行することにより実現されるものとする。前提として、実施形態６と同様に、エラー条件判定部２０７は、アプリケーションの開発元をサーバＳから取得できるものとする。
ステップＳ５０１、Ｓ５０２で説明したように、エラー条件判定部２０７は判定において、端末機種ごとに、アプリケーションＡのエラー発生率を求める。実施形態１においては、ある端末機種で動作することがエラー条件となるかは、エラー発生率が５０％以上であることで判定し、エラー発生率の閾値は５０で固定であった。本実施形態では、エラー条件の判定に用いるエラー発生率の閾値は、アプリケーションの開発元に応じて変化する。

次に、エラー条件判定部２０７がアプリケーションの開発元に応じてエラー条件の判定に用いるエラー発生率の閾値を変更する処理を説明する。

はじめに、エラー条件判定部２０７は、アプリケーションＡの開発元がＸ社であるかを確認する（ステップＳ１９０１）。開発元がＸ社である場合、エラー発生率が１０％以上であるかを確認する（ステップＳ１９０２）。１０％以上である場合、エラー条件であると判定される（ステップＳ１９０３）。１０％未満の場合、エラー条件でないと判定される（ステップＳ１９０４）。ステップＳ１９０１において、アプリケーションの開発元がＸ社でない場合、エラー条件判定部２０７は開発元がＹ社であるかを確認する（ステップＳ１９０５）。開発元がＹ社の場合、エラー発生率が３０％以上であるかを確認する（ステップＳ１９０６）。３０％以上である場合、エラー条件であると判定される（ステップＳ１９０３）。３０％未満の場合、エラー条件でないと判定される（ステップＳ１９０４）。開発元がＸ社でもＹ社でもない場合、エラー発生率が５０％を超えるかを判定する（ステップＳ１９０７）。５０％以上である場合、エラー条件であると判定される（ステップＳ１９０３）。５０％未満の場合、エラー条件でないと判定される（ステップＳ１９０４）。ステップＳ１９０４、Ｓ１９０３のいずれかの処理が終わると、エラー条件判定処理は完了する。以降の処理は、ステップＳ５０３と同様である。

以上、エラー条件判定部２０７が、エラー条件の判定基準をアプリケーションの開発元に応じて変更する例を説明した。

＜実施形態９＞
エラー検知部２０４がエラー報告管理部２０５に送るエラーメッセージには、端末２０１のユーザの個人情報が含まれる場合がある。含まれる情報としては、ユーザのアカウント情報などがあげられる。エラー報告を送信する前に、報告する内容をユーザが確認し、報告する可否をユーザが決定する場合の実施形態を、実施形態９として説明する。端末２０１とサーバ２０２とのハードウェア構成は図１に示した構成の通りである。

実施形態９にかかるエラー検知部２０４の動作について、図２４を用いて説明する。図２４は、アプリケーション実行中にエラーが起きた場合のエラー検知部２０４の処理を示すフローチャートである。フローチャートは、ＣＰＵが制御プログラムを実行することにより実現されるものとする。

アプリケーション実行環境１０００２は、ステップＳ４０１と同様に、アプリケーションが実行中に発生させた例外やエラーを、エラー検知部２０４によって検知する（ステップＳ２４０１）。エラーが起きると、エラー検知部２０４はプログラムスタックを解析し、エラーを起こしたアプリケーションを特定する。そして、エラーが起きたアプリケーションのアプリケーション識別情報、エラー発生時のプログラムスタックの情報、端末識別情報をエラー報告として作成する。

次に、アプリケーション実行環境１０００２は、作成したエラー報告の内容をユーザに提示する（ステップＳ２４０２）。提示方法には、ダイアログ表示などが考えられる。ダイアログである場合、ダイアログの表示にはユーザが送信の許可・不許可を指示するボタンが含まれる。ユーザが許可したかどうかは、ダイアログの押されたボタンで認識する（ステップＳ２４０３）。ユーザが送信を許可した場合、ステップＳ４０２と同様に、サーバ２０２にエラー報告を送信する（ステップＳ２４０４）。ユーザが許可しなかった場合、エラー報告を送信せずに処理は終了する。

以上、エラー報告を送信する前に、報告する内容をユーザが確認し、報告する可否をユーザが決定する実施形態を説明した。

＜実施形態１０＞
例えば、画像の顔検出を行うアプリケーションにおいて、顔検出で検出される顔が０個の場合にエラーが起きるとする。エラー時に処理していた画像をエラーメッセージに含め、開発者がこの画像を取得できるなら、開発者は容易にエラーを再現して修正版の開発に活用できる。エラーメッセージにエラー時に処理していたデータを含める実施形態を、実施形態１０として説明する。

実施形態１０にかかるエラー検知部２０４の動作について、図２５を用いて説明する。図２５は、アプリケーション実行中にエラーが起きた場合のエラー検知部２０４の処理を示すフローチャートである。フローチャートは、ＣＰＵが制御プログラムを実行することにより実現されるものとする。

アプリケーション実行環境１０００２は、ステップＳ２４０１と同様に、アプリケーションが実行中に発生させた例外やエラーを、エラー検知部２０４によって検知する（ステップＳ２５０１）。エラーが起きると、エラー検知部２０４はプログラムスタックを解析し、エラーを起こしたアプリケーションを特定する。そして、エラーが起きたアプリケーションのアプリケーション識別情報、エラー発生時のプログラムスタックの情報、端末識別情報をエラー報告として作成する。

さらに、エラー検知部２０４は、エラーが発生したアプリケーションが画像ファイルを開いていたかを確認する（ステップＳ２５０２）。端末２０１がＬｉｎｕｘＯＳ（登録商標）で動作し、アプリケーション実行環境１０００２は、各アプリケーションにプロセスを割り当てるとする。この場合、プロセスＩＤディレクトリのファイル記述子を参照することで、エラーが発生したアプリケーションが開いていた画像ファイルを特定できる。

ステップＳ２５０２において画像ファイルを開いていた場合、エラー検知部２０４は画像ファイルをエラー報告に含める（ステップＳ２５０３）。ただし、画像ファイル数が多かった場合は、画像ファイルへのアクセス時刻が最も新しいファイルのみをエラー報告に含めてもよい。

ステップＳ２５０２で画像ファイルを開いていなかった場合、またはステップＳ２５０３の処理が終わった場合、エラー検知部２０４はステップＳ２４０２と同様に、ユーザにエラー報告の内容を提示する（ステップＳ２５０４）。ただし、提示するダイアログには、エラー報告のエラーメッセージ、画像ファイルのサムネイルなどの各項目を分けて表示し、各項目にチェックボックスを設ける。ユーザは、各項目のチェックボックスを選択して、報告の内容を決定する（ステップＳ２５０５）。

エラー検知部２０４は、ユーザがダイアログに入力した内容から、ユーザが送信を許可したかどうかを認識する（ステップＳ２５０６）。ユーザが送信を許可した場合、ユーザが選択した項目のみをエラー報告に含め、サーバ２０２に送信する（ステップＳ２５０７）。ユーザが送信を許可しなかった場合は、エラー報告を送信せずに処理は終了する。

以上、エラーメッセージにエラー時に処理していたデータを含める実施形態を説明した。

＜その他の実施形態＞
以上、実施形態例を詳述したが、本発明は例えば、システム、装置、方法、プログラム若しくは記録媒体（記憶媒体）等としての実施態様をとることが可能である。具体的には、複数の機器（例えば、ホストコンピュータ、インタフェース機器、撮像装置、ｗｅｂアプリケーション等）から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。

また、本発明の目的は、以下のようにすることによって達成されることはいうまでもない。即ち、前述した実施形態の機能を実現するソフトウェアのプログラムコード（コンピュータプログラム）を記録した記録媒体（または記憶媒体）を、システムあるいは装置に供給する。係る記憶媒体は言うまでもなく、コンピュータ読み取り可能な記憶媒体である。そして、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムコードを読み出し実行する。この場合、記録媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記録した記録媒体は本発明を構成することになる。

Claims (27)

1. 接続可能な複数の端末を管理する管理装置であって、
   アプリケーションをインストールした複数の端末から前記アプリケーションのエラー情報を受信する受信手段と、
   前記複数の端末に関する情報と、前記複数の端末にインストールされた前記アプリケーションの情報とを管理する管理手段と、
   前記エラー情報と前記複数の端末に関する情報と前記アプリケーションの情報とに基づいて、前記アプリケーションがエラーを起こす条件を判定する判定手段と、
   インストールされた前記アプリケーションがエラーを起こす条件を満たしていることを示す情報を、前記複数の端末のうち当該条件を満たす端末に送信する送信手段と、
   を備えることを特徴とする管理装置。
2. 前記判定手段は、前記アプリケーションの所定の数の前記エラー情報を受信した場合に、前記アプリケーションがエラーを起こす条件を判定することを特徴とする請求項１記載の管理装置。
3. 前記判定手段では、アプリケーションをインストール済みの端末数と当該アプリケーションのエラーを報告した端末数とに基づいて前記アプリケーションがエラーを起こす条件を判定することを特徴とする請求項１または２何れかに記載の管理装置。
4. 前記判定手段では、アプリケーションをインストール済みの端末数と前記アプリケーションのエラーを報告した端末数とを、前記アプリケーションのバージョンと前記前記エラーを報告した端末のバージョンで分類して集計し、前記アプリケーションがエラーを起こす条件を判定することを特徴とする請求項１または２何れかに記載の管理装置。
5. 前記判定手段では、アプリケーションをインストール済みの端末数と前記アプリケーションのエラーを報告した端末数とを、前記管理手段を参照してエラーを発生した端末にインストールされているアプリケーションによって分類して集計し、前記アプリケーションがエラーを起こす条件を判定することを特徴とする請求項１または２何れかに記載の管理装置。
6. 前記受信手段では、エラーを報告した端末でエラー発生時に実行中だったアプリケーションの情報を含めて受信し、
   前記判定手段では、アプリケーションをインストール済みの端末数と前記アプリケーションのエラーを報告した端末数とを、エラーを報告した端末がエラー発生時に実行中だったアプリケーションによって分類して集計し、前記アプリケーションがエラーを起こす条件を判定することを特徴とする請求項１乃至５何れか１項に記載の管理装置。
7. 前記判定手段では、アプリケーションの実行回数とエラー回数とに基づいて、前記アプリケーションがエラーを起こす条件を判定することを特徴とする請求項１または２何れかに記載の管理装置。
8. 前記判定手段がエラーを起こす条件を満たすと判定したアプリケーションの開発元に通知を行う通知手段と、
   前記アプリケーションの修正版が公開されたことを検出する検出手段と、を更に備え、
   前記送信手段は、前記アプリケーションの修正版を前記アプリケーションがエラーを起こす条件を満たす端末に送信することを特徴とする請求項１乃至７何れか１項に記載の管理装置。
9. 複数の端末を管理する管理装置に接続され管理されている端末であって、
   前記管理装置が判定した、アプリケーションがエラーを起こす条件を受信する受信手段と、
   前記エラーを起こす条件を満たすアプリケーションの表示形態を変更して表示させる表示制御手段と、
   を備えることを特徴とするアプリケーション実行端末。
10. 複数の端末を管理する管理装置に接続され管理されている端末であって、
    前記管理装置が判定した、アプリケーションがエラーを起こす条件を受信する受信手段と、
    前記エラーを起こす条件を満たすアプリケーションの起動の指示を受けると、エラーを起こす条件を満たしていることに基づくメッセージを表示させる表示制御手段と、
    を備えることを特徴とするアプリケーション実行端末。
11. 複数の端末を管理する管理装置に接続され管理されている端末であって、
    自端末にインストールされているアプリケーションの情報を管理する管理手段と、
    前記管理装置から、前記アプリケーションのエラー情報と前記アプリケーションがインストールされた複数の端末に関する情報とを受信する受信手段と、
    前記エラー情報と前記複数の端末に関する情報と前記アプリケーションの情報とに基づいて、前記アプリケーションがエラーを起こす条件を判定する判定手段と、
    前記アプリケーションのうち、前記エラーを起こす条件を満たすアプリケーションの表示形態を変更して表示させる表示制御手段と、
    を備えることを特徴とするアプリケーション実行端末。
12. 複数の端末を管理する管理装置に接続され管理されている端末であって、
    自端末にインストールされているアプリケーションの情報を管理する管理手段と、
    前記管理装置から、前記アプリケーションのエラー情報と前記アプリケーションがインストールされた複数の端末に関する情報とを受信する受信手段と、
    前記エラー情報と前記複数の端末に関する情報と前記アプリケーションの情報とに基づいて、前記アプリケーションがエラーを起こす条件を判定する判定手段と、
    前記アプリケーションのうち、前記エラーを起こす条件を満たすアプリケーションの起動の指示を受けると、エラーを起こす条件を満たしていることに基づくメッセージを表示させる表示制御手段と、
    を備えることを特徴とするアプリケーション実行端末。
13. 前記表示制御手段は、前記アプリケーションのうち、前記エラーを起こす条件を満たすアプリケーションの表示形態を前記管理装置から送信された当該条件に基づいて変更して表示させることを特徴とする請求項９または１１何れかに記載のアプリケーション実行端末。
14. 前記表示制御手段は、アンインストールを提案するメッセージを表示させることを特徴とする請求項１０または１２何れかに記載のアプリケーション実行端末。
15. 前記受信手段では、前記エラーを起こす条件を満たすアプリケーションの修正版が存在を示す情報を含めて受信し、
    前記表示制御手段は、前記アプリケーションの修正版へのアップデートを提案するメッセージを表示させることを特徴とする請求項１０に記載のアプリケーション実行端末。
16. アプリケーション実行端末と前記アプリケーション実行端末が接続可能な管理装置とから構成されるアプリケーション管理システムであって、
    前記管理装置は、
    アプリケーションをインストールした複数の端末から前記アプリケーションのエラー情報を受信する受信手段と、
    前記複数の端末に関する情報と、前記複数の端末にインストールされた前記アプリケーションの情報とを管理する管理手段と、
    前記エラー情報と前記複数の端末に関する情報と前記アプリケーションの情報とに基づいて、前記アプリケーションがエラーを起こす条件を判定する判定手段と、
    インストールされた前記アプリケーションがエラーを起こす条件を満たしていることを示す情報を、前記複数の端末のうち当該条件を満たす端末に送信する送信手段と、を備え、
    前記アプリケーション実行端末は、
    前記管理装置が判定した、アプリケーションがエラーを起こす条件を受信する受信手段と、
    前記エラーを起こす条件を満たすアプリケーションの表示形態を変更して表示させる表示制御手段と、
    を備えることを特徴とするアプリケーション管理システム。
17. アプリケーション実行端末と前記アプリケーション実行端末が接続可能な管理装置とから構成されるアプリケーション管理システムであって、
    前記管理装置は、
    アプリケーションをインストールした複数の端末から前記アプリケーションのエラー情報を受信する受信手段と、
    前記複数の端末に関する情報と、前記複数の端末にインストールされた前記アプリケーションの情報とを管理する管理手段と、
    前記エラー情報と前記複数の端末に関する情報と前記アプリケーションの情報とに基づいて、前記アプリケーションがエラーを起こす条件を判定する判定手段と、
    インストールされた前記アプリケーションがエラーを起こす条件を満たしていることを示す情報を、前記複数の端末のうち当該条件を満たす端末に送信する送信手段と、を備え、
    前記アプリケーション実行端末は、
    前記管理装置が判定した、アプリケーションがエラーを起こす条件を受信する受信手段と、
    前記エラーを起こす条件を満たすアプリケーションの起動の指示を受けると、エラーを起こす条件を満たしていることに基づくメッセージを表示させる表示制御手段と、
    を備えることを特徴とするアプリケーション管理システム。
18. 接続可能な複数の端末を管理する管理装置を制御するアプリケーション管理方法であって、
    アプリケーションをインストールした複数の端末から前記アプリケーションのエラー情報を受信する受信工程と、
    前記複数の端末に関する情報と、前記複数の端末にインストールされた前記アプリケーションの情報とを管理する管理手段の作成工程と、
    前記エラー情報と前記複数の端末に関する情報と前記アプリケーションの情報とに基づいて、前記アプリケーションがエラーを起こす条件を判定する判定工程と、
    インストールされた前記アプリケーションがエラーを起こす条件を満たしていることを示す情報を、前記複数の端末のうち当該条件を満たす端末に送信する送信工程と、
    を備えることを特徴とするアプリケーション管理方法。
19. 複数の端末を管理する管理装置に接続され管理されている端末の制御方法であって、
    前記管理装置が判定した、アプリケーションがエラーを起こす条件を受信する受信工程と、
    前記エラーを起こす条件を満たすアプリケーションの表示形態を変更して表示させる表示制御工程と、
    を備えることを特徴とするアプリケーション実行端末の制御方法。
20. 複数の端末を管理する管理装置に接続され管理されている端末の制御方法であって、
    前記管理装置が判定した、アプリケーションがエラーを起こす条件を受信する受信工程と、
    前記エラーを起こす条件を満たすアプリケーションの起動の指示を受けると、エラーを起こす条件を満たしていることに基づくメッセージを表示させる表示制御工程と、
    を備えることを特徴とするアプリケーション実行端末の制御方法。
21. 複数の端末を管理する管理装置に接続され管理されている端末であって、
    自端末にインストールされているアプリケーションの情報を管理する管理手段の作成工程と、
    前記管理装置から、前記アプリケーションのエラー情報と前記アプリケーションがインストールされた複数の端末に関する情報とを受信する受信工程と、
    前記エラー情報と前記複数の端末に関する情報と前記アプリケーションの情報とに基づいて、前記アプリケーションがエラーを起こす条件を判定する判定工程と、
    前記アプリケーションのうち、前記エラーを起こす条件を満たすアプリケーションの表示形態を変更して表示させる表示制御工程と、
    を備えることを特徴とするアプリケーション実行端末の制御方法。
22. 複数の端末を管理する管理装置に接続され管理されている端末の制御方法であって、
    自端末にインストールされているアプリケーションの情報を管理する管理手段の作成工程と、
    前記管理装置から、前記アプリケーションのエラー情報と前記アプリケーションがインストールされた複数の端末に関する情報とを受信する受信工程と、
    前記エラー情報と前記複数の端末に関する情報と前記アプリケーションの情報とに基づいて、前記アプリケーションがエラーを起こす条件を判定する判定工程と、
    前記アプリケーションのうち、前記エラーを起こす条件を満たすアプリケーションの起動の指示を受けると、エラーを起こす条件を満たしていることに基づくメッセージを表示させる表示制御工程と、
    を備えることを特徴とするアプリケーション実行端末の制御方法。
23. コンピュータを、
    接続可能な複数の端末を管理する管理装置であって、
    アプリケーションをインストールした複数の端末から前記アプリケーションのエラー情報を受信する受信手段と、
    前記複数の端末に関する情報と、前記複数の端末にインストールされた前記アプリケーションの情報とを管理する管理手段と、
    前記エラー情報と前記複数の端末に関する情報と前記アプリケーションの情報とに基づいて、前記アプリケーションがエラーを起こす条件を判定する判定手段と、
    インストールされた前記アプリケーションがエラーを起こす条件を満たしていることを示す情報を、前記複数の端末のうち当該条件を満たす端末に送信する送信手段と、
    として機能させるためのプログラム。
24. コンピュータを、
    複数の端末を管理する管理装置に接続され管理されている端末であって、
    前記管理装置が判定した、アプリケーションがエラーを起こす条件を受信する受信手段と、
    前記エラーを起こす条件を満たすアプリケーションの表示形態を変更して表示させる表示制御手段と、
    として機能させるためのプログラム。
25. コンピュータを、
    複数の端末を管理する管理装置に接続され管理されている端末であって、
    前記管理装置が判定した、アプリケーションがエラーを起こす条件を受信する受信手段と、
    前記エラーを起こす条件を満たすアプリケーションの起動の指示を受けると、エラーを起こす条件を満たしていることに基づくメッセージを表示させる表示制御手段と、
    として機能させるためのプログラム。
26. コンピュータを、
    複数の端末を管理する管理装置に接続され管理されている端末であって、
    自端末にインストールされているアプリケーションの情報を管理する管理手段と、
    前記管理装置から、前記アプリケーションのエラー情報と前記アプリケーションがインストールされた複数の端末に関する情報とを受信する受信手段と、
    前記エラー情報と前記複数の端末に関する情報と前記アプリケーションの情報とに基づいて、前記アプリケーションがエラーを起こす条件を判定する判定手段と、
    前記アプリケーションのうち、前記エラーを起こす条件を満たすアプリケーションの表示形態を変更して表示させる表示制御手段と、
    として機能させるためのプログラム。
27. コンピュータを、
    複数の端末を管理する管理装置に接続され管理されている端末であって、
    自端末にインストールされているアプリケーションの情報を管理する管理手段と、
    前記管理装置から、前記アプリケーションのエラー情報と前記アプリケーションがインストールされた複数の端末に関する情報とを受信する受信手段と、
    前記エラー情報と前記複数の端末に関する情報と前記アプリケーションの情報とに基づいて、前記アプリケーションがエラーを起こす条件を判定する判定手段と、
    前記アプリケーションのうち、前記エラーを起こす条件を満たすアプリケーションの起動の指示を受けると、エラーを起こす条件を満たしていることに基づくメッセージを表示させる表示制御手段と、
    として機能させるためのプログラム。

Images