JP7120708B2 - クラウドデバイス共同的リアルタイムユーザ使用および性能異常検出のシステムおよび方法 - Google Patents

Description

本願は、２０１７年１０月１３日に出願された「Ｓｙｓｔｅｍ ａｎｄ Ｍｅｔｈｏｄ ｆｏｒ Ｃｌｏｕｄ－Ｄｅｖｉｃｅ Ｃｏｌｌａｂｏｒａｔｉｖｅ Ｒｅａｌ－Ｔｉｍｅ Ｕｓｅｒ Ｅｘｐｅｒｉｅｎｃｅ Ａｂｎｏｒｍａｌｉｔｙ Ｄｅｔｅｃｔｉｏｎ」と題する米国仮特許出願第６２／５７２，３２０号の優先権を主張するものであり、この米国仮特許出願がそのまま参照により本明細書に組み込まれる。

本開示は概してアプリケーション異常検出に関するものであり、具体的な実施形態では、クラウドデバイス共同的リアルタイムユーザエクスペリエンスおよび性能異常検出のシステムおよび方法に関する。

コンピューティングデバイスは人々の日常生活において次第に重要になってきており、コンピューティングデバイスを使用する様々な必要性に対応すべく、スマートフォン、スマートウォッチ、タブレット、ラップトップ、コンピュータなどといった様々なユーザデバイスのためのアプリケーションまたはソフトウェアプログラムがますます多く開発されている。アプリケーションまたはプロセスは、コンピューティングデバイスで異常な動作をしている場合に、コンピューティングデバイスの性能、電力またはエネルギーの消費、ひいてはユーザエクスペリエンスに著しく影響を及ぼすことがある。アプリケーションの異常検出は、異常に実行されているアプリケーションの悪影響を緩和するのに適切なアクションを選択し、当該アクションを起こすのに役立ち得る。

本開示のある実施形態によれば、コンピューティングデバイスがリモートデバイスから第１異常検出モデルを受信する段階を含む方法が提供される。第１異常検出モデルは、リソース使用におけるアプリケーションのアノマリを検出するための機械学習技術を使用して訓練可能である。この方法は、第１異常検出モデルに従ってアプリケーションのリソース使用データを取得する段階も含む。リソース使用データは、コンピューティングデバイスにおいてアプリケーションによりアクセスされる１または複数のハードウェアコンポーネント、または、１または複数のサービスの使用またはエネルギー消費に関する情報を含む。この方法は、第１異常検出モデルを使用するコンピューティングデバイスが、取得されたリソース使用データに基づいて、アプリケーションにリソース使用におけるアノマリがあるかどうかを決定する段階と、リソース使用におけるアプリケーションのアノマリに関する決定に応答してアクションを起こす段階とを更に含む。１または複数の異常検出モデルを使用することにより、１または複数のリソース使用において、コンピューティングデバイスの１または複数のアプリケーションのアノマリが検出されてよい。

本開示の別の実施形態によれば、複数のコンピューティングデバイスからアプリケーションに関連するデータサンプルを取得する段階を含む、コンピュータで実装される方法が提供される。データサンプルは、複数のコンピューティングデバイスにおいてアプリケーションによりアクセスされる１または複数のハードウェアコンポーネント、または、１または複数のサービスの使用またはエネルギー消費に関する情報を含み、各データサンプルは複数のコンピューティングデバイスのうちの１つと関連付けられる。この方法は、データサンプルにラベルを割り当てる段階を更に含む。それぞれのコンピューティングデバイスと関連付けられるデータサンプルに割り当てられたラベルは、それぞれのコンピューティングデバイスでの第１リソース使用においてアプリケーションが有する一組の異常レベルのうちの１つの異常レベルを示し、第１リソース使用は第１異常パラメータに対応する。この方法は、ラベル付けされたデータサンプルと機械学習技術とを使用して異常検出モデルを構築する段階も含み、異常検出モデルは第１リソース使用におけるアプリケーションのアノマリを検出する。アプリケーションと関連付けられる複数のコンピューティングデバイスから取得されたデータサンプルに基づいて、実施形態に係る方法を使用して１または複数の異常検出モデルが構築されてよい。これらの異常検出モデルは、それぞれのコンピューティングデバイスにおけるアプリケーションのアノマリを検出するためにコンピューティングデバイスにプッシュされてよい。１または複数の異常パラメータについて１または複数のアプリケーションのアノマリを検出するために異常検出モデルが構築されてよい。

本開示の別の実施形態によれば、コンピューティングデバイスで実行されているアプリケーションにリソース使用におけるアノマリがあるかどうかを、アプリケーションについて取得されたリソース使用データに基づいて、かつ、機械学習技術を使用して構築された異常検出モデルを使用して検出することにより、アプリケーションに関する異常検出結果を生成する段階と、異常検出結果に応答してアプリケーションの実行時にアクションを起こす段階と、アプリケーションの異常検出結果と、当該異常検出結果に応答して起こされた対応するアクションとに関するデータを一定期間にわたって収集する段階と、収集されたデータに基づく適応モデルまたはカスタマイズモデルを使用して、異常検出結果に応答して起こされるアクションを調整する段階とを含む方法が提供される。このように、異常検出結果に応答して起こされたアクションがユーザ行動および使用パターンに基づいてカスタマイズされて、ユーザエクスペリエンスおよびデバイス性能を改善するのに役立ち得る。

本開示の複数の実施形態は、コンピューティングデバイスで異常に実行されているアプリケーションにより引き起こされる過度のエネルギー消費を削減することによりユーザエクスペリエンスを改善するのに役立つ。これらの実施形態はバッテリ駆動式のコンピューティングデバイスにとってより有用となり、ひいてはエネルギー源の容量が制限される。アプリケーションまたはプロセスまたはツールまたはソフトウェアがコンピューティングデバイスで一定期間にわたって異常な動作をする場合は、バッテリが通常よりも速く消耗し、ひいてはデバイスのユーザがデバイスの性能および効率に不満を感じることがある。異常は、アプリケーションによるハードウェアコンポーネント、サービス、およびリソースの使用の分析から収集されたデータを使用して検出される。アプリケーションによるエネルギー消費またはリソース使用における異常が一定期間にわたって生じる場合は、デバイスの温度が過度に上昇することがあり、それによってデバイスまたはそのコンポーネントにダメージを及ぼすか、または、デバイスまたはそのコンポーネントの性能を低下させることがある。従って、これらの実施形態の異常検出によって、デバイスの過度の加熱または温度の問題を防止することもできる。本開示の複数の実施形態は、アプリケーションまたはプロセスが、コンピューティングデバイスにおけるリソース、コンポーネント、またはサービスを異常に使用している場合または事象を検出することもでき、これによってデバイスの総合的な性能または総合的なユーザエクスペリエンスをアプリケーションが低下させるのを防止するのに役立つ。リソースが異常に使用されると、リソースが他のアプリケーションまたはシステムプロセスに割り振られる際にリソースの性能が低下することがあり、結果として、デバイスがより低い性能で機能することがある。本開示の複数の実施形態は、ユーザエクスペリエンスを改善し、性能を改善し、バッテリの寿命を改善し、総合的なエネルギー消費を削減し、過度の熱または温度の問題を軽減し、コンピューティングデバイスで利用可能なリソースまたはソフトウェアコンポーネントまたはハードウェアコンポーネントのより正常かつ効率的な利用を提供するのに役立つ。

本開示およびその利点をより完全に理解できるよう、ここでは、添付図面と併せて挙げられる以下の説明を参照する。
ある実施形態に係るコンピューティングデバイスのアーキテクチャのダイアグラムを示している。 ある実施形態に係るアプリケーションアノマリ検出の方法のフローチャートを示している。 ある実施形態に係る異常検出モデルのダイアグラムを示している。 ある実施形態に係るリソースの使用レベルを示したダイアグラムを示している。 ある実施形態に係るアプリケーションアノマリ検出のカスタマイズの方法のダイアグラムを示している。 別の実施形態に係るアプリケーションアノマリ検出のカスタマイズの方法のダイアグラムを示している。 ある実施形態に係るアプリケーションアノマリ検出の方法のダイアグラムを示している。 ある実施形態に係る、アプリケーションアノマリ検出のためのコンピューティングデバイスとサーバとの間の相互作用の方法のダイアグラムを示している。 ある実施形態に係る、異常検出モデルを構築するための方法のフローチャートを示している。 ある実施形態に係る、異常パラメータの関連使用パラメータに基づいて定義される使用グループを示したグラフを示している。 図１０に示す使用グループごとに定義される複数の異常レベルまたは異常閾値を示したダイアグラムを示している。 ある実施形態に係るアプリケーションアノマリ検出のシステムのブロックダイアグラムを示している。 ある実施形態に係るアプリケーションアノマリ検出の方法のフローチャートを示している。 ある実施形態に係る、異常検出モデルを構築するための方法のフローチャートを示している。 別の実施形態に係るアプリケーションアノマリ検出の方法のフローチャートを示している。 ある実施形態に係るアプリケーションアノマリ検出の方法のフローチャートを示している。 ある実施形態に係るアプリケーションアノマリ検出の閾値を決定するための方法のフローチャートを示している。 別の実施形態に係るアプリケーション異常検出の方法のフローチャートを示している。 処理システムまたはコンピューティングシステムのブロックダイアグラムである。 送受信機のブロックダイアグラムである。

以下では、本開示の実施形態の形成および使用について詳しく説明する。ただし、本明細書で開示する概念は多様な特定の状況において具現化され得るものであること、および、本明細書で説明する具体的な実施形態は例示に過ぎず、特許請求の範囲を限定する役割を果たすものではないことを理解されたい。更に、本明細書では、添付の特許請求の範囲により定義される本開示の趣旨および範囲から逸脱することなく、様々な変更、置換、および改変が行われ得ることを理解されたい。

本開示の複数の実施形態は、アプリケーションアノマリ検出の方法を提供する。デバイスで異常な動作をしているアプリケーションは、デバイスの性能、電力またはエネルギーの消費、ひいてはユーザエクスペリエンスに著しく影響を及ぼすことがある。故に、デバイスで実行されている１または複数のアプリケーションのアノマリを検出できることが望ましい。幾つかの実施形態によれば、デバイスがリモートデバイスから異常検出モデルを受信してよい。異常検出モデルは、リソース使用におけるアプリケーションのアノマリを検出するための機械学習技術を使用して訓練可能である。デバイスは、異常検出モデルに従ってアプリケーションのリソース使用データを取得してよい。リソース使用データは、コンピューティングデバイスにおいてアプリケーションによりアクセスされる１または複数のハードウェアコンポーネント、または、１または複数のサービスの使用またはエネルギー消費に関する情報を含んでよい。デバイスは、第１異常検出モデルを使用して、取得されたリソース使用データに基づいて、アプリケーションにリソース使用におけるアノマリがあるかどうかを決定してよく、リソース使用におけるアプリケーションのアノマリに関する決定に応答してアクションを起こしてよい。１または複数の異常検出モデルを使用することにより、１または複数のリソース使用において、コンピューティングデバイスの１または複数のアプリケーションのアノマリが検出されてよい。

幾つかの実施形態では、異常検出モデルを構築するための方法が提供され得る。この方法では、複数のコンピューティングデバイスからアプリケーションに関連するデータサンプルを取得してよい。データサンプルは、複数のコンピューティングデバイスにおいてアプリケーションによりアクセスされる１または複数のハードウェアコンポーネント、または、１または複数のサービスの使用またはエネルギー消費に関する情報を含み、各データサンプルは複数のコンピューティングデバイスのうちの１つと関連付けられる。この方法では次に、データサンプルにラベルを割り当ててよい。それぞれのコンピューティングデバイスと関連付けられるデータサンプルに割り当てられたラベルは、それぞれのコンピューティングデバイスでの第１リソース使用においてアプリケーションが有する一組の異常レベルのうちの１つの異常レベルを示し、第１リソース使用は第１異常パラメータに対応する。この方法では、ラベル付けされたデータサンプルと機械学習技術とを使用して異常検出モデルを構築する。異常検出モデルは、第１リソース使用におけるアプリケーションのアノマリを検出する。アプリケーションと関連付けられる複数のコンピューティングデバイスから取得されたデータサンプルに基づいて、実施形態に係る方法を使用して１または複数の異常検出モデルが構築され得る。これらの異常検出モデルは、それぞれのコンピューティングデバイスにおけるアプリケーションのアノマリを検出するためにコンピューティングデバイスにプッシュされてよい。１または複数の異常パラメータについて１または複数のアプリケーションのアノマリを検出するために異常検出モデルが構築されてよい。

幾つかの実施形態では、異常検出が特定のデバイス用にカスタマイズされてよい。例えば、デバイスは、デバイスで実行されているアプリケーションにリソース使用におけるアノマリがあるかどうかを、アプリケーションについて取得されたリソース使用データに基づいて、かつ、機械学習技術を使用して構築された異常検出モデルを使用して検出してよい。故に、アプリケーションについて異常検出結果が生成される。デバイスは、異常検出結果に応答してアプリケーションの実行時にアクションを起こしてよい。デバイスは、アプリケーションの異常検出結果と、当該異常検出結果に応答して起こされた対応するアクションとに関するデータを一定期間にわたって収集してよく、収集されたデータに基づく適応モデルまたはカスタマイズモデルを使用して、異常検出結果に応答して起こされたアクションを調整してよい。このように、異常検出結果に応答して起こされたアクションがユーザ行動および使用パターンに基づいてカスタマイズされて、ユーザエクスペリエンスおよびデバイス性能を改善するのに役立ち得る。

コンピューティングデバイスは、人々の日常生活においてますます重要になってきており、様々なコンピューティングデバイスが様々なニーズおよび要件に対応するように開発されたアプリケーションまたはソフトウェアの数が増えてきている。本明細書のコンピューティングデバイスは、中央処理装置（ＣＰＵ）または複数の処理装置を使用して動作する電子デバイス（または機器、装置）を指すことがある。ＣＰＵは、１または１より多くのチップを有してよい。ＣＰＵは、１または複数のコア、マイクロプロセッサ、マイクロコントローラ、プロセッサ、グラフィック処理装置（ＧＰＵ）、ニューラルネットワーク処理装置（ＮＰＵ）、コントローラ、またはこれらの任意の組み合わせを含んでよい。コンピューティングデバイスは、情報を処理する、および／または、計算を実行するように構成される。コンピューティングデバイスは、一連の数学的演算および論理演算を実行するソフトウェアプログラムに従う。コンピューティングデバイスの例には、コンピュータ、ラップトップ、タブレット、スマートフォン、ウェアラブル電子デバイス、サーバ、フィットネス機器、電子測定デバイス、監視デバイス、制御デバイス、電子補助デバイス、デジタルペット、自律走行車両、ナビゲーションデバイス、運転デバイス、ロボットなどが含まれてよい。

図１は、ある実施形態に係るコンピューティングデバイスのアーキテクチャ１００のダイアグラムを示している。アーキテクチャ１００は、コンピューティングデバイスに含まれるコンポーネントを示している。図示の通り、コンピューティングデバイスは、ディスプレイ、ＧＰＵ、ＣＰＵ、Ｗｉ－Ｆｉインタフェース、モデム、カメラ、全球測位衛星システム（ＧＮＳＳ）などの複数のハードウェアコンポーネントを含む。コンピューティングデバイスは、Ｂｌｕｅｔｏｏｔｈ（登録商標）、入出力（ＩＯ）デバイス、微小電気機械システム（ＭＥＭＳ）、機械デバイス、アクチュエータ、またはセンサなどの他のハードウェアコンポーネント１０２を含んでもよい。コンピューティングデバイスは、オペレーティングシステム（ＯＳ）およびサービス１０４も含み、ＯＳおよびサービス１０４は、コンピューティングデバイスの動作をサポートするために使用されるソフトウェアプログラムまたはツールである。図示の通り、コンピューティングデバイスは、グラフィックライブラリ、ウェブブラウザエンジン、およびメディアマネージャなどのサービスを含む。ＯＳおよびサービスは、ハードウェアコンポーネントを利用して対応する機能を実行する。例えば、グラフィックライブラリは、グラフィック関連機能を実行するためのディスプレイ、ＧＰＵ、およびＣＰＵを使用する。コンピューティングデバイスは、１または複数のアプリケーション１０６を含んでもよい。アプリケーションは、コンピューティングデバイスにインストールされ、かつ、コンピューティングデバイスで実行可能である、ソフトウェアプログラムと呼ばれることがある。アプリケーションは、ユーザにより、または、別のアプリケーションのインストールによって、コンピューティングデバイスにインストールされてよい。アプリケーションは、リモートサーバまたはクラウドサーバなどのリモートデバイスからダウンロードされ、コンピューティングデバイスにインストールされてよい。アプリケーションは、コンピューティングデバイスの一体部分としてコンピューティングデバイスに予めインストールされてもよい。アプリケーションは、バックグラウンド、フォアグラウンド、またはバックグラウンドおよびフォアグラウンドの両方で実行中であってよい。図示の通り、コンピューティングデバイスは、メッセージまたはチャットのアプリケーション、電子メールアプリケーション、ゲームアプリケーション、ナビゲーションまたはマップのアプリケーション、ソーシャルメディアアプリケーション、および撮像またはカメラのアプリケーションを含むアプリケーションを含む。アプリケーションの例には、天気予報アプリケーション、音楽またはビデオの再生アプリケーション、ウェブ閲覧アプリケーション、遠隔通信アプリケーション、検索アプリケーション、ウィルススキャンアプリケーション、コンピュータツールなどが含まれてもよい。アプリケーションは、コンピューティングデバイスで実行されているプロセスまたはシステムツールを含んでもよい。アプリケーションは、その目的の動作においてサービスおよびハードウェアコンポーネントのうちの１または複数を利用してよい。例えば、ゲームアプリケーションの実行には、グラフィックライブラリ、ウェブブラウザエンジン、メディアマネージャ、および他のサービスを利用してよい。コンピューティングデバイスは異常検出器１０８を含んでもよく、異常検出器１０８は、アプリケーションにより使用またはアクセスされるサービスおよびハードウェアコンポーネントに基づいて、アプリケーションにアノマリがあるかどうか、または、アプリケーションが異常な動作をしているかどうかを検出するために使用されてよい。異常検出器１０８は、コンピューティングデバイスで実行される各アプリケーションによりアクセスまたは使用されるコンピューティングデバイスの１または複数のリソース（１または複数のハードウェアコンポーネント、および／または、１または複数のサービスなど）に関するデータ（例えば、使用データ）を受信してよく、これらのリソースの各々の使用を対応するアプリケーションと関連付けてよい。異常検出器１０８は次に、アプリケーションによるリソース使用に基づいてアプリケーションのアノマリを検出してよい。

コンピューティングデバイス内のアプリケーションは、設計通りまたは予想通りに動作しない（本明細書ではこのことを、アプリケーションが異常にまたは異常な状態で動作している、または、アプリケーションにアノマリまたは異常があると呼ぶ）場合に、コンピューティングデバイスの性能、電力またはエネルギーの消費、ひいてはユーザエクスペリエンスに著しく影響を及ぼすことがある。例えば、場合によっては、異常な状態にあるアプリケーションが、中断することも異なる状態に変化することもなく、ある状態で実行され続ける（または繰り返し動作を実行し続ける）ことがある。これは、アプリケーションが無限ループに陥り、例えばソフトウェアバグに起因して抜け出すことができない場合であり得る。これは、アプリケーションが１つの動作モードまたは動作状態から別の動作モードまたは動作状態への移行を試み続けて失敗した場合でもあり得る。これは、アプリケーションがハードウェアコンポーネントにアクセスする試みを続けて失敗した場合でもあり得る。アプリケーションが実行され続けると、コンピューティングデバイスの電力がはるかに速く消耗し、オーバーヒートが生じ、コンピューティングデバイスの性能が低下することがある。場合によっては、これによってコンピューティングデバイスにセキュリティの問題が生じることもある。例えば、機密性の高い会議中にスマートフォンを無線接続から切断する必要があるかもしれないが、そうすることができなくなる。

コンピューティングデバイスで実行されているアプリケーションの異常を検出することができ、対応するアクションを起こして、アプリケーションの異常の影響を回避または低減するか、または、ユーザに通知または警告を提供することができることが解るであろう。アプリケーションが異常な動作をしている場合、例えば、大量のエネルギーを消費している場合は、アプリケーションの内部にアクセスして何が起こっているのかを確認し、アプリケーションにアノマリがあると決定することができない。アプリケーションのコードが利用可能だとしても、場合によっては、アプリケーションから見つかったバグに基づいて、アプリケーションにアノマリがあると決定するのは概して難しい。アプリケーションのアノマリを引き起こすアプリケーションのバグを見つけること、または、アプリケーションのアノマリの原因、例えば、エネルギー使用の急増を決定することも概して難しい。ただし、異常に実行されているアプリケーションは、アプリケーションによるリソース使用に反映され得る。リソース使用は、メモリ、ディスプレイ、スピーカ、モデム、バッテリ、ＣＰＵ、ＧＰＵ、またはサービス、例えばメディアマネージャなどといった任意のハードウェアコンポーネントおよび／またはソフトウェアコンポーネントのリソースの使用を含んでよい。例えば、アノマリのあるアプリケーションには、想定外の量のバッテリ電力を消費すること、バックグラウンドまたはフォアグラウンドで想定外にＣＰＵを使用すること、想定外の回数にわたって自己再起動すること、モデムヘのアクセスにより長い時間を要すること、または、想定外にメモリを使用することなどがある。アプリケーションによるリソース使用を監視することにより、アプリケーションが異常に実行されているかどうかが検出されてよく、アプリケーションの実行をフリーズするなど、アプリケーションの異常に対処するアクションが起こされてよい。

本開示の複数の実施形態は、１または複数のハードウェアコンポーネントの関連デバイス情報、環境データ、リソース使用、および、アプリケーションにより使用されるサービスを、例えば一定期間にわたって監視し、１または複数の異常検出モデルを利用して、監視されたリソース使用に基づいて、アプリケーションにアノマリがあるかどうかを決定する。１または複数の異常検出モデルは、複数のコンピューティングデバイスから収集されたリソース使用データに基づいて、リモートサーバまたはクラウドサーバなどのリモートデバイス内の機械学習技術を使用して構築されてよく、アプリケーション異常検出のためにコンピューティングデバイスに展開されてよい。単一の異常検出モデルが、一定期間中にデバイスにより使用またはアクセスされる幾つかのアプリケーションにおける異常を検出するのをサポートしてよい。単一の異常検出モデルが、幾つかのリソース使用パラメータまたは異常パラメータにおける異常を同時に検出してもよい。

図２は、ある実施形態に係るアプリケーションアノマリ検出の方法２００のフローチャートを示している。方法２００は、コンピューティングデバイスまたはユーザデバイスで実行される動作を示している。図示の通り、方法２００の段階２０２では、異常検出モデルを受信する。異常検出モデルは、ソフトウェアプログラムとして実装されてよい。一例では、方法２００が、ネットワーク内のリモートサーバまたはクラウドサーバまたは近隣サーバまたはサポートデバイスなどのリモートデバイスから異常検出モデルをダウンロードし、コンピューティングデバイスで異常検出モデルをインストールおよび実行してよい。別の例では、異常検出モデルが、例えばリモートデバイスによりコンピューティングデバイスにプッシュされてよい。異常検出モデルは常にコンピューティングデバイスで実行され、コンピューティングデバイスで動作させられてよい。異常検出モデルは、テンソル処理装置（ＴＰＵ）、ＧＰＵ、ニューラル処理装置（ＮＰＵ）、または別個のＣＰＵなど、別個の処理装置により実行されてよい。異常検出モデルは、異常検出器または異常予測器と呼ばれることもある。異常検出モデルは、入力データを所与として異常検出のタスクを実行する必要がある計算、数学的演算、および／または分析を含む計算アルゴリズムであってよい。異常検出モデルは、機械学習技術を使用して構築されてよい。例えば、異常検出モデルは、分類モデル、回帰モデル、ディープニューラルネットワークモデル、ベイジアンネットワークを使用して構築されるモデル、意思決定ネットワーク、決定木の集合体、正規化された回帰モデル、または同様の分類モデル、予測モデル、もしくは回帰モデル、およびそれらの組み合わせであってよい。使用され得るニューラルネットワークモデルの例には、多層完全接続ネットワーク、畳み込みニューラルネットワーク（ＣＮＮまたはＣｏｎｖＮｅｔ）、リカレントニューラルネットワーク（ＲＮＮ）、強化学習、またはそれらの変形例もしくは組み合わせが含まれる。異常検出モデルの構築については、本開示で後ほど説明する。異常検出モデルは、コンピューティングデバイスの１または複数のリソースのリソース使用における１または複数のアプリケーションのアノマリを検出するように構成されてよい。

一実施形態では、異常検出モデルは、異常検出モデルを指定または説明するメタデータと関連付けられるソフトウェアモジュール（例えば、ライブラリ、実行可能なコード、または他の適用可能なコード）としてコンピューティングデバイスにより受信されてよい。ソフトウェアモジュールは、異常検出モデルの基本的なアルゴリズムの実装を含んでよい。コンピューティングデバイスは、関連付けられる説明に従って構成される受信されたソフトウェアモジュールをインスタンス化またはロードして、検出動作を実行することができる。幾つかの他の実施形態では、異常検出モデルは、コンピューティングデバイスで構成されたコアエンジン（例えば、訓練可能なニューラルネットワークなど、検出動作を実装する基本的なアルゴリズム、または他の適用可能なモデルに基づいたもの）を含んでよい。コンピューティングデバイスにより受信される検出モデルは、１または複数のファイルに設定（例えば、入力の数、モデルの構造およびタイプ、層の数、訓練周期の数、他のデバイスから収集された使用データにより訓練される重みなど）を含んでよい。コンピューティングデバイスは、異常検出動作を実行するために受信されたファイルに従ってコアエンジンを動的に構成／カスタマイズすることができる。

一実施形態では、異常検出器または異常検出モデルは、１または複数のタスクを実行するシステムツール、ソフトウェア、または、デーモンを含み、１または複数のタスクは、データ収集、ユーザエクスペリエンスおよびデバイス性能の監視、各アプリケーションによる各リソースの性能の監視、データの前処理、データ分析、リソース使用の推定、使用およびエネルギーの会計、データベース管理、異常検出、および、カスタマイズアルゴリズムまたは適応アルゴリズムを含んでよい。異常検出モデルは、リモートデバイスまたはサーバからの異常検出結果および異常検出要件に基づいてアクションを起こしてよい。リソースの計算または推定は、必要に応じて利用可能な記録データを使用して、各リソースのエネルギーを推定すること、または、各リソースの電力消費をモデリングすることを含んでよい。一例では、異常検出ツールまたは異常検出デーモンは、設定（または構成）ファイル、および異常検出モデルファイル（または、例えば複数のディープニューラルネットワークモデルを含むファイル）を使用してよく、これらのファイルは、異常検出デーモンの制御パラメータ、ニューラルネットワークモデルの構造およびアルゴリズム、関連アルゴリズムのパラメータ値、並びにニューラルネットワークモデルの重みをまとめて定義する。異常検出モデルがディープニューラルネットワークアルゴリズムに基づいている場合は、異常検出ツールまたは異常検出デーモンは、実行プロセスまたは検出プロセスを速めるために、デバイス上のＮＰＵ、ＴＰＵ、またはＧＰＵで異常検出モデルを実行してよい。システムツールまたはデーモン、構成、および異常検出モデルファイルを含む異常検出モデルの幾つかまたは全ての部分が、定期的にまたは要求に応じて更新または改訂されてよい。別の実施形態では、異常検出ツールまたは異常検出デーモンは、リモートデバイスまたはサポートデバイスもしくはサーバにデバイスおよびリソースの使用データを送信してよく、異常検出モデルは、サポートデバイスまたはリモートデバイスで実行されてよく、次に結果は、更なるアクションのためにコンピューティングデバイスに返信されてよい。

リソース使用とは、実行のためにアプリケーションにより使用またはアクセスされるリソースの使用またはエネルギー消費を指すことがある。リソースは、コンピューティングデバイスのハードウェアコンポーネント、例えば、アプリケーションにより使用されるメモリ、ディスプレイ、スピーカ、モデム、バッテリ、ＣＰＵ、ＧＰＵ、カメラ、センサ、フラッシュライト、オーディオなど、または、コンピューティングデバイスのソフトウェアコンポーネント、例えば、アプリケーションにより使用されるサービスを含んでよい。故に、リソース使用は特定のリソースに関連する。あるアプリケーションには、コンピューティングデバイスの１または幾つかのリソースのリソース使用におけるアノマリがあると決定されてよい。リソースの使用とは、（アプリケーションの実行のために）リソースにより消費されるエネルギー量、（アプリケーションの実行のために）リソースが使用またはアクセスされる頻度、（アプリケーションの実行のために）リソースが使用またはアクセスされる継続時間、リソースのサイズもしくは数、または（アプリケーションの実行のために）使用されるリソースのパラメータもしくは属性、またはこれらの任意の組み合わせを指すことがある。リソース使用の例には、バックグラウンド（ＢＧ）でのＣＰＵ、フォアグラウンド（ＦＧ）でのＣＰＵ、Ｗｉ－Ｆｉ ＢＧ、Ｗｉ－Ｆｉ ＦＧ、モデムＢＧ、モデムＦＧ、ＧＰＳ ＢＧ、ＧＰＳ ＦＧ、カメラＢＧ、またはカメラＦＧの使用またはエネルギー消費が含まれてよい。リソース使用は、ウェイクロック保持時間、アプリケーションの自己起動の数、アラーム、ＩＯデバイス使用、総エネルギー使用、またはメモリ使用を含んでもよい。各リソース使用は関連パラメータに対応する。対応するリソース使用の測定に従ってパラメータの値が割り当てられてよい。例えば、ＣＰＵ ＢＧのエネルギー消費はＣＰＵ ＢＧエネルギーのパラメータに対応し、ＩＯデバイス使用はＩＯデバイスアクセスレートのパラメータに対応してよく、モデムＢＧ使用はＢＧ内のモデムオンタイムのパラメータに対応してよく、Ｗｉ－Ｆｉ使用はＷｉ－Ｆｉロック保持時間のパラメータに対応してよい、などである。これらのパラメータは異常パラメータと呼ばれることがあり、異常パラメータについてアプリケーションのアノマリが検出される。異常パラメータは、より複合的または二次的なパラメータまたは属性を含んでもよく、当該パラメータまたは属性は、デバイスで収集された幾つかのリソース使用または他の関連データの何らかの形の組み合わせから抽出または計算される。１または複数のリソースのリソース使用におけるアプリケーションのアノマリは、１または複数のリソースの使用に対応する１または複数の異常パラメータに基づいて決定されてよい。

方法２００の段階２０４では、アプリケーションにより使用されるリソースのリソース使用データを取得する。リソース使用データは、異常検出モデルを使用してアプリケーションのアノマリを検出するために使用されてよい。方法２００では、異常検出モデルの構成に従ってリソース使用データを取得してよい。方法２００では、アプリケーションにより使用またはアクセスされる全てのリソースのリソース使用データを取得してよい。一例では、コンピューティングデバイスは、アプリケーションにより使用されるリソースを監視し、異常検出モデルの要件に従ってリソースのリソース使用データを収集し、収集されたリソース使用データを異常検出モデルに提供してよい。別の例では、異常検出モデルは、アプリケーションにより使用されるリソースのリソース使用データを監視および収集するように構成されてよい。別の例では、異常検出モデルは、記録データを使用して、各リソースにより消費されるエネルギー量を計算または推定してもよいし、各リソースにより消費される電力量をモデリングしてもよい。エネルギー推定または電力モデリングのためのアルゴリズムは、複数のデバイスから取得されたデータを使用して、または、各リソースに関する洞察を使用して、訓練または設計されてよい。別の例では、異常検出モデルは、デバイスから抽出または収集される未加工データまたは初期変数を使用して、一組のリソース使用パラメータ、定量的特徴、二次的またはより複合的なパラメータまたは属性を計算または生成してよい。リソース使用データは、コンピューティングデバイスの１または複数のハードウェアコンポーネント、または、１または複数のサービスの使用またはエネルギー消費に関する情報を含んでよい。デバイスは、デバイス内で使用またはアクセスされるありとあらゆるアプリケーションまたはプロセスに対応するリソース使用データを監視および収集してよい。

幾つかの実施形態では、リソース使用データは、アプリケーションの１または複数の実行条件下におけるコンピューティングデバイス内のハードウェアコンポーネントのエネルギー消費、使用、エネルギーパターン、または使用パターンを含んでよい。実行条件は、フォアグラウンド使用、バックグラウンド使用、スクリーンオン使用、スクリーンオフ使用、またはアプリケーションによるデバイス内のリソースの消費を含んでよい。実行条件は、アプリケーションがフォアグラウンドで実行されるのか、バックグラウンドで実行されるのか、スクリーンオンで実行されるのか、またはスクリーンオフで実行されるのかを示してよい。ハードウェアコンポーネントの使用パターンは、一定期間中のハードウェアコンポーネントの使用の一連の測定（すなわち、使用の時系列または順序）を含んでよい。他の実施形態では、使用パターンは、このハードウェアコンポーネントの使用の測定から収集／識別される頻度、平均、最大、最小、速度、および／または他の適用可能な統計を含んでもよい。ハードウェアコンポーネントのエネルギーパターンは、一定期間中のハードウェアコンポーネントの一連のエネルギー消費（すなわち、エネルギー消費の時系列または順序）を含んでよい。一例では、ハードウェアコンポーネントの使用またはエネルギー消費は、一定期間、例えば２４時間にわたってハードウェアコンポーネントにより消費される総使用量または総エネルギーを含んでよい。別の例では、ハードウェアコンポーネントの使用またはエネルギー消費は、ハードウェアコンポーネントにより最近（例えば、データ収集の最後の５分間で）消費された使用量またはエネルギーを含んでよい。この場合は、ハードウェアコンポーネントの使用またはエネルギー消費は、ディスプレイの輝度レベルなど、他の関連デバイスの属性の最新データを含んでもよい。別の例では、ハードウェアコンポーネントの使用またはエネルギー消費は、例えば、一定の分解を含む一定期間にわたる、例えば、５分間の分解（例えば、５分ごと）を含む最後の２４時間にわたる、ハードウェアコンポーネントによる一連の使用またはエネルギー消費（例えば、時系列としての使用およびエネルギー消費）を含んでよい。いずれの場合も、例えば、そのような使用またはエネルギー消費がもたらされる条件を示すために、ディスプレイ輝度またはＷｉ－Ｆｉ受信品質など、他の関連するデバイスおよび環境のデータが含まれてもよい。リソースデータは、コンピューティングデバイスで実行されるアプリケーションにより使用されるサービス、ソフトウェアコンポーネント、またはシステムツールの使用に関するデータを更に含んでよい。

幾つかの実施形態では、リソース使用データは、ＣＰＵのフォアグラウンド使用、ＣＰＵのバックグラウンド使用、ウェイクロック保持時間、自己起動の数、アプリケーションのオンスクリーン時間、アプリケーションのオフスクリーン時間、セルラ、遠隔通信またはモデムの使用およびパターン、Ｗｉ－Ｆｉまたはネットワークの使用およびパターン、メモリ使用、マルチメディアの使用およびパターン、撮像センサまたはカメラの使用およびパターン、ＧＰＵの使用、任意の他のセンサまたはハードウェアコンポーネントの使用およびパターン、ＩＯデバイスへのアクセス回数を含むＩＯデバイス使用、または使用されている位置サービスの数を含む位置サービスの使用およびパターンを含んでよい。

幾つかの実施形態では、リソース使用データは、グラフィック処理サービスの使用、ニューラル処理サービスの使用、到着通知の数、オーディオサービスの使用、マルチメディアサービスの使用、Ｂｌｕｅｔｏｏｔｈ（登録商標）の使用、Ｗｉ－Ｆｉサービスの使用、遠隔通信サービスの使用、モデムまたは無線サービスの使用、カメラサービスの使用、位置サービスまたはナビゲーションサービスの使用、センササービスの使用、メッセージングサービスの使用、ヒューマンインタフェースサービスの使用、メディアマネージャサービスの使用、通知マネージャサービスの使用、システムサービスの各々の使用、Ｗｉ－Ｆｉまたはネットワークアクセスサービスの品質、モデムまたは遠隔通信サービスの品質、オーディオの音量および品質、オーディオルート、マルチメディアルート、周囲の配光、ディスプレイ輝度分布、温度、湿度、バッテリまたは他のコンポーネントの電流、バッテリまたは他のコンポーネントの電圧、またはユーザデータへのアクセス数を含んでもよい。

幾つかの実施形態では、リソース使用データは、コンピューティングデバイスに関する情報、例えば、コンピューティングデバイスのモデル、コンピューティングデバイスの製品バージョン、または、アプリケーションに関する情報、例えば（複数のアプリケーションのうちの１つのアプリケーションを識別するために使用される）アプリケーションのアプリケーション名またはアプリケーション識別子、アプリケーションバージョンを含んでよい。リソース使用データは、コンピューティングデバイスを使用する環境条件、例えば、コンピューティングデバイスの位置、またはアプリケーションの実行の日付もしくは時刻、またはコンピューティングデバイスの性能情報を更に含んでよい。

方法２００の段階２０６では、取得されたリソース使用データに基づいて、異常検出モデルを使用してアプリケーションのアノマリを検出する。異常検出モデルは、リソース使用データを入力として見なし、アプリケーションに、コンピューティングデバイスの、１または複数のリソースのリソース使用、または、異常パラメータにおけるアノマリがあるかどうかを決定してよい。１または複数のリソースは、異常検出モデルで予め構成されてよく、異常検出モデルは、１または複数のリソースのリソース使用についてそれぞれの異常検出結果を出力してよい。例えば、異常検出モデルは、アプリケーションに、ＣＰＵ ＢＧ、ＣＰＵ ＦＧ、ウェイクロック、アラーム、Ｗｉ－Ｆｉ、およびモデムなどのリソースのリソース使用におけるアノマリがあるかどうかを検出してよい。異常検出モデルは、リソース使用における複数のアプリケーションのアノマリを同時に検出するように構成されてよい。異常検出モデルは、複数のリソース使用または異常パラメータにおける異常を同時に予測または検出してよい。異常検出モデルにより、複数のレベルまたは種別の異常が同時に検出または識別されてよい。

図３は、ある実施形態に係る、デバイスにより使用される１または幾つかのアプリケーションのアノマリを検出するための異常検出モデル３００のダイアグラムを示している。この例における異常検出モデル３００は、深層学習技術を使用して訓練されるディープニューラルネットワークである。実例として、異常検出モデル３００に入力されたリソース使用データは、ＣＰＵ、Ｗｉ－Ｆｉ、ＧＰＵ、ＧＮＳＳ、ディスプレイ、ＢＴ、オーディオ、フラッシュライト、フロントカメラ、リアカメラ、およびセンサなど、デバイスのありとあらゆるハードウェアコンポーネントの使用およびエネルギー消費を含む。入力されたデータは、アプリケーション名またはアプリケーション識別子、ＣＰＵウェイクロック、モデム受信品質、地理的領域、および日付など、他の関連するデバイス、性能、またはアプリケーションの属性を含んでもよい。入力されたリソース使用データを用いて、異常検出モデル３００は、アプリケーションにＣＰＵ ＢＧのアノマリ、ＣＰＵ ＦＧのアノマリ、ウェイクロックのアノマリ、アラームのアノマリ、自己起動のアノマリ、Ｗｉ－Ｆｉのアノマリ、モデムのアノマリ、ＧＰＳのアノマリ、または他のアノマリがあるかどうかを示す異常検出結果を一度に出力してよい。異常検出モデル３００は、デバイスにより使用される幾つかのアプリケーションにおける異常を検出してよい。ここで、アプリケーションのデータがデータのバッチとしてモデルに入力され、各データサンプルは１つのアプリケーションに属する。

異常検出モデル３００は、記録された全てのリソース使用およびデバイスのデータを使用してもよいし、入力されたデータの一部を使用してもよい。異常検出モデルに入力されたデータは、幾つかのリソース使用パラメータ、デバイスまたは環境のデータまたは情報の、何らかの形の組み合わせまたは数学的マッピングから計算される１または複数の属性または定量的特徴を含んでよい。例えば、数学的演算を適用すること、または４つのリソース使用データまたはパラメータに対するマッピングを行うことにより、異常検出モデル３００に入力されたデータの一部としてこれらの属性のうちの１つを抽出して、異常検出を実行するための、より有用な、より関連がある、またはより識別力のある属性を取得してよい。入力されたパラメータまたは属性の組み合わせを使用する、入力された属性の設計および構築は、複数のデバイスから収集されたデータを使用して、例えばリモートサーバで実行されたデータ分析に基づいて決定されてよい。

幾つかの実施形態では、異常検出モデル３００は、異常のレベルを含む異常検出結果を生成してよい。一例では、異常のレベルまたは種別は、異常なし、異常、高度の異常、または過度の異常を含んでよい。別の例では、異常のレベルは、１または複数のレベルの使用、例えば、多い使用または過度の使用を含んでもよい。例えば、異常検出モデル３００は、アプリケーションにＣＰＵ ＢＧの使用に関する高度の異常があること、アプリケーションにモデムの使用に関する過度の異常があること、または、アプリケーションにＣＰＵ ＦＧに関する過度の使用があることを検出してよい。アプリケーションが有する異常のレベルを検出する異常検出モデルは、アノマリレベル検出モデルと呼ばれることがある。幾つかの実施形態では、異常検出モデル３００は、アプリケーションが一組の異常レベル（異常確率または異常尤度と呼ばれることがある）に該当する確率の推定を出してもよい。例えば、リソース使用または異常パラメータについては、異常検出モデル３００は、アプリケーションが正常である（または異常がない）確率がＰ１％、リソースの過度の使用がある確率がＰ２％、異常である確率がＰ３％、および高度に異常である確率がＰ４％であると推定してよく、モデルが４つの異常レベルを検出した場合は、ｐ１＋ｐ２＋ｐ３＋ｐ４＝１００％である。アプリケーションが一組の異常レベルに該当する推定確率を出す異常検出モデルは、異常尤度推定モデルと呼ばれることがある。

図２を改めて参照すると、幾つかの実施形態において、方法２００では段階２０６に進む前に、アプリケーションにより使用されるサービスが実用的なシナリオであるかどうかをチェックしてよい。実用的なシナリオは、アプリケーションがランタイムに特定のサービス（例えば、システムサービス）を呼び出すように構成される制約、特権、および／または制限に関連することがある。例えば、方法２００では、ソーシャルメディアアプリケーションまたはメッセージングアプリケーションによるバックグラウンドでの音楽の再生が許可され、かつ、通常の使用事例として見なされているかどうかをチェックしてよい。サービスの使用シナリオが実用的である場合は、方法２００では、異常検出モデルを実行して、そのようなサービスに関連するリソースのバックグラウンド使用が異常であるかどうかを検出する必要はないかもしれない。使用シナリオが実用的でない場合は、方法２００では、取得されたデータを異常検出モデルに供給し、異常検出モデルを実行して、関連する使用およびエネルギー消費が異常であるかどうかを検出してよい。幾つかの実施形態では、ハードウェアコンポーネントによる使用およびエネルギー消費、並びに他の入力データと、サービスの使用とが、異常検出モデル、例えばモデル３００に入力されてよい。異常検出モデルは次に、他の入力データおよび使用データと共にアプリケーションごとの実用的なシナリオを考慮して、異常検出出力を自動的に生成してよい。

方法２００の段階２０８では、アプリケーションにアノマリがあることを検出したことに応答してアクションを起こす。本明細書において、アクションを起こすことは、特定の操作を実行することを指すことがある。例えば、アプリケーションがアノマリを有するか、または、ある条件下で異常な動作をしているとコンピューティングデバイスが決定すると、コンピューティングデバイスは、それに応答して操作を実行するように構成される。動作は予め構成されてよく、ソフトウェアプログラムの実行、デバイスでの操作、および／または、リソース使用の制限、もしくは、異常な動作が検出されたアプリケーションによる１または複数のリソースへのアクセスの制限を含む。アプリケーションの異常の悪影響が軽減または回避されるように、アクションが起こされてよい。一例では、異常検出モデルは、複数の異常レベルを検出してよい、または、１または複数のリソースを使用する際の１または複数のアプリケーションの異常、またはリソース使用の重大度を推定する。それに応答して起こされるアプリケーションごとのアクションは、検出された異常レベル、および／またはリソース使用の重要性に依存してよい。一例では、アプリケーションの実行をフリーズするアクションが起こされてよい。別の例では、アプリケーションの実行を一定期間にわたってフリーズするアクションが起こされてよい。別の例では、アプリケーションが利用できる幾つかのリソースおよび／またはサービスを制限するアクションが起こされてよい。別の例では、アプリケーションを強制終了するアクションが起こされてよい。更に別の例では、アプリケーションを再起動するアクションが起こされてよい。更に別の例では、通知、例えば異常通知（例えば、ユーザインタフェースポップアップメッセージ、サウンドアラート、インスタントメッセージング、または、ユーザまたはシステムに通知するための他の適用可能な機構）が、コンピューティングデバイスのユーザまたはコントローラに与えられてよい。この通知は異常の発生を示してよいことから、ユーザはそれに応答して自らが適切と見なすアクションを起こしてよい。この通知は、アプリケーションに関する異常検出結果を示してよい。この通知は、ユーザが異常の発生に応答して選択できるアクションのリストを示してもよい。場合によっては、ユーザは、自らの嗜好、経験、または専門知識に基づいて、異常通知にかかわらずアクションを起こさないことがある。

幾つかの実施形態では、各異常パラメータについて、複数の異なる異常レベルに対応して、または推定確率に対応して、アクションのリストが予め決定されてよい。例えば、異常検出モデルは、正常（または異常なし）、過度の使用、異常、高度に異常を含む一組の異常レベルに従って、ＣＰＵ ＦＧの使用におけるアプリケーションのアノマリを検出する。当該一組の異常レベルに対応して予め決定されたアクションは、表１にそれぞれ示すように、「なし」（すなわち、アクションをしないこと）、「通知」（すなわち、通知を提供すること）、「フリーズ」（すなわち、一定期間にわたってアプリケーションをフリーズまたは中断すること）、「再起動」（すなわち、アプリケーションを再起動すること）を含んでよい。故に、コンピューティングデバイスは、当該一組の異常レベルと予め決定されたアクションとの間の対応関係に基づく異常検出結果に応答して、予め決定されたアクションを選択し、起こしてよい。幾つかの実施形態では、異常レベルに対してアクションの組み合わせが起こされてよい。幾つかの実施形態では、アクションは、アプリケーションで生じる異常の継続時間に基づいていてもよい。例えば、リソース使用に関するアプリケーションの異常が閾値よりも長い期間にわたって続く場合は、起こすアクションが変更されてよい。

方法２００の段階２１０では、アプリケーションのアノマリ検知に関連するデータを記憶する。記憶されるデータは、段階２０４で取得されるリソース使用データおよび他の関連データ、段階２０６で生成される検出結果、段階２０８で起こされるアクション、アプリケーションの異常パラメータ、アプリケーションの使用パターン、例えば段階２１６で受信されるユーザエクスペリエンスフィードバックまたはユーザ嗜好を含んでよい。方法２００では、一定期間にわたってある間隔で、データのある部分または全てを記録してよい、例えば、２ヶ月間にわたって５分ごとに異常検出結果を記録してよい。この方法では、記録データを使用して、アプリケーションにおけるユーザ行動、またはコンピューティングデバイスにおけるアプリケーションの使用パターンを推定してよい。方法２００の段階２１２では、記憶されたデータをリモートデバイスに送信してよい。記憶されたデータは、周期的にまたは要求に応じてリモートデバイスに送信されてよい。リモートデバイスに送信される記憶されたデータは、１または複数の異常検出モデルを訓練または更新するために使用されてよい。

この方法の段階２１４では、アクションをカスタマイズまたは適応させてよい。幾つかの実施形態において、方法２００では、段階２１０で記録されたデータとユーザフィードバック情報とに基づいて、アプリケーションの異常レベルを検出したことに応答してコンピューティングデバイスにより起こされるアクションを調整してよい。例えば、方法２００では、上の表１に従ってアクションを起こしてよい。方法２００では、アプリケーションの異常結果と、一定期間、例えば２週間にわたって記録された、起こされた対応するアクションとに基づいて、異常パラメータ、例えばＣＰＵのフォアグラウンド使用についてアプリケーションのアノマリパターンを決定してよい。アプリケーションに２週間にわたって多数の（例えば、閾値数より多い）過度の使用（例えば、閾値量より多い使用）があったが、それに応答してユーザによりアクションが起こされたことがないことを、検出された異常レベルのヒストグラム、またはデバイスのアノマリパターンが示す場合は、方法２００では、アプリケーションが実際に正常に実行されていると決定し、ひいては過度の使用の異常レベルに対応するアクションを「通知」から「なし」に調整してよい。これは、このアプリケーションに関するＣＰＵのフォアグラウンド使用の過度の使用がユーザにとって受け入れ可能であるか、または、ユーザにより通常と見なされる場合であり得る。別の例では、アノマリパターンは、アプリケーションに２週間にわたって過度の使用の少数の例（例えば、閾値数より少ない数の例）があり、異常または過度の異常が検出されなかったことを示し、アプリケーションを再起動するアクションがユーザにより時々起こされた。この場合は、方法２００では、アプリケーション（および、ユーザまたはデバイス）が主に使用の少ないグループにあり、このユーザまたはデバイスについては過度の使用が実際に異常と見なされると決定してよい。方法２００では、過度の使用の異常レベルに対応するアクションを「通知」から「フリーズ」に調整（例えば、異なる動作を選択）してよい。更に別の例において、方法２００では、ユーザエクスペリエンスフィードバック情報に起因して表１の全てのアクションを「通知」に調整してよく、例えば、ユーザは、異常検出結果を考慮してアプリケーションに対してすべきことを制御しようとする。例えば、ユーザは、高度の異常が一定期間にわたって検出された場合にアプリケーションをフリーズしようとすること、または、アプリケーションの異常が一定期間にわたって続いた場合にアプリケーションを再起動しようとすることがある。このように、コンピューティングデバイスにより起こされるアクションが、コンピューティングデバイスのユーザの具体的な要件、ニーズ、または行動にカスタマイズされる。アプリケーションについて履歴データが生成されてよく、履歴データは、アプリケーションの異常検出結果、アプリケーションの異常検出結果に応答して起こされるアクション、アプリケーションの使用パターン、アプリケーションのエネルギー消費パターン、ユーザフィードバック、またはこれらの任意の組み合わせを含んでよい。履歴データは、アクションが決定または調整され得る方法を決定するために使用されてよい。アクションは、履歴データと適応機構またはカスタマイズ機構とに基づいて（例えば、カスタマイズアルゴリズムに基づいて）機械学習モデルなどのモデルを使用してカスタマイズされてもよい。幾つかの実施形態では、一定期間を通じて観察された異常検出結果の履歴またはパターンに加えて、リソース使用のパターン、使用の位置、日付、または時刻を含む他の関連するデバイスまたはユーザの情報を含む、他の関連情報がカスタマイズアルゴリズムへの入力として使用されてよい。

幾つかの実施形態では、異常検出モデルにより検出される異常には、異常レベルと呼ばれる複数のレベルまたは種別があってよい。複数のレベルまたは種別は、複数の異常閾値に基づいて決定されてよい。図４は、ある実施形態に係る、アプリケーションにより使用されるリソースの使用レベルを示したダイアグラムを示している。使用レベルは、最低レベル（例えば、観察された最小のリソース使用）から最高レベル（例えば、観察された極度のリソース使用）まである。この実施形態では、一組の異常閾値Ｔ１からＴ７（使用レベル閾値と呼ばれることもある）に従って、リソースの使用に関するアプリケーションのアノマリ検知のために複数の異なる異常レベルが定義されてよい。例えば、複数のデバイスでの使用分布を考慮した場合にアプリケーションによるリソースの使用がデバイス（または複数の類似デバイス）の母集団で９９％を上回るなど、Ｔ７より多いリソース使用が極めて異常と定義されてよい。これは極めて稀なまたは珍しい使用事例であるかもしれない。アプリケーションによるリソースの使用がデバイスの母集団で９６％から９９％であるなど、Ｔ７とＴ６との間のリソース使用は、過度に異常と定義されてよい。これも極めて稀なまたは珍しい事例であるかもしれない。アプリケーションによるリソースの使用が複数のデバイスの母集団で５０％から６５％であるなど、Ｔ２とＴ１との間のリソース使用は、比較的多い使用として定義されてよい。Ｔ１より少ないリソース使用は、正常と定義されてよい。幾つかの実施形態では、幾つかの異常レベルが検出および認識され得るとしても、それに応答して起こされるアクションが２つまたは３つのアクションに限定されてよい。例えば、Ｔ４より少ないリソース使用は、正常（故に、アクションは起こされない）と見なされてよく、Ｔ４を上回るリソース使用は、異常と見なされる（例えば、リソース使用がＴ５、Ｔ６、またはＴ７を上回るかどうかにかかわらず、アプリケーションがフリーズされることを意味することがある）。

幾つかの他の実施形態では、アプリケーションの異常は、複数の異常レベルまたは異常種別ではなく、連続的な異常パラメータ、例えば、連続的な使用パラメータまたは属性により特徴付けられてよい。そのような場合は、コンピューティングデバイスで実行されているアプリケーションごとに、異常検出モデルは、コンピューティングデバイスから収集された入力データを所与として、連続的な異常パラメータを推定または予測し、それに応答して起こされるアクションは、推定または予測される異常パラメータ値と一組の閾値とに基づいていてよい。例えば、連続的な異常パラメータは当該一組の閾値と比較されてよく、次に、比較結果に基づいて、起こすアクションが決定されてよい。そのような場合は、異常検出モデルは、異常推定器、異常予測器、またはリソース使用レベル推定器と呼ばれることがある。使用される当該一組の閾値は、コンピューティングデバイスで実行されている全てのアプリケーションに使用される共通の組の閾値であってよい、または、各アプリケーションは、推定される異常パラメータの値または範囲に基づいて、起こすアクションを決定するために使用される異なる組の閾値を有してよい。

幾つかの実施形態では、特定のデバイス内のアプリケーションのユーザフィードバック、ユーザエクスペリエンス、使用パターン、または異常パターンに基づいて、アプリケーションアノマリ検出がカスタマイズされてよい。例えば、ユーザフィードバックおよび制御を受信して、異常のレベルを決定するために異常検出モデルにより使用される基準を調整してよい。ユーザは、アプリケーションのアノマリ検知で適用される異常または閾値のレベルに影響を与えてもよいし、リソース使用の異常の検出および制御がどの程度厳格に適用されるかを決定してもよい。図４を実例として使用すると、フリーズアクションを起こすべきかどうかを決定するために異常検出モデルにより使用されるデフォルト事例が、異常レベルが閾値Ｔ４を上回っているときのものである場合は、ユーザは、より制限の少ない異常評価を使用することを決定してよい。次に、ユーザフィードバック、例えばユーザ命令または設定制御が異常検出モデルに提供されてよく、これにより、異常検出モデルは、Ｔ５を使用して、アプリケーションがリソース使用において異常であるかどうかを決定する（例えば、Ｔ５より多いリソース使用は異常であり、Ｔ５より少ないリソース使用は正常である）よう強いられてよい。別の例では、ユーザが単にリソース使用またはエネルギー消費に対する最小限の制御を好む場合は、ユーザは、例えば設定制御によって、より高い閾値（例えば、Ｔ６またはＴ７）を閾値として使用して、アプリケーションがリソース使用において異常であるかどうかを検出するよう、異常検出モデルに命令してよい。

図５は、ある実施形態に係るアプリケーションアノマリ検出のカスタマイズの方法のダイアグラム５００を示している。この例では、リソースの使用パターン（または異常パラメータの変動パターン）に基づいて、異常閾値がカスタマイズされる。図５は、一定期間にわたる２つの異なるデバイスまたは２人の異なるユーザ、すなわち、デバイス１およびデバイス２における同じアプリケーションのリソース使用（例えば、エネルギー消費）をそれぞれ表すグラフ５１０および５２０を示している。ｙ軸は使用頻度または使用ヒストグラムを表し、ｘ軸はリソース使用のレベルを表す。この例では、図４に示す閾値は、異常のレベルを決定するために使用される。これら２つのデバイスにより同じ異常検出モデルが使用される。この例では、２つの異常レベルが使用される。すなわち、ライン５３０で示すように、異常検出モデルは、Ｔ４より少ないリソース使用が正常であり、Ｔ４より多いリソース使用が異常であると決定する。グラフ５１０および５２０からは、デバイス１およびデバイス２に異なる使用パターンまたはユーザ行動があったことが分かる。これら２つのデバイスのリソース使用のヒストグラムは異なり、結果的に、これら２つのデバイスの異常検出結果は異なるものを意味する。デバイス１内のアプリケーションのリソース使用は、一定期間にわたって常にＴ２より少なかった、ひいては、一定期間中に常に正常であると決定されたが、デバイス２内のアプリケーションのリソース使用は、かなりの時間の割合でＴ４より多かった、ひいては異常に多くの回数として予測または分類された。一例では、使用パターンに基づいて、デバイス１内の異常検出モデルは、Ｔ４ではなく（ライン５３２で示すような）Ｔ２を使用して、アプリケーションがデバイス１でのリソース使用において異常であるかどうかを検出するよう（例えば、段階２１４で説明したカスタマイズ機構により）命令されてよい。これは、ユーザが不審なアプリケーションの実行を防止しようとし得る場合であり得る。異常検出モデルは、Ｔ４ではなく（ライン５３４で示すような）Ｔ５を使用して、アプリケーションがリソース使用において異常であるかどうかを検出するようカスタマイズ機構により命令されてよい。これは、デバイス２およびアプリケーションが大量のリソースを消費するのが正常であるとデバイス２のユーザが決定する場合であり得る。カスタマイズ機構は、閾値を増大させて、アプリケーションが実際に正常に実行されている間にアノマリを示す異常検出結果を頻繁に受信するのを回避することができる。

図６は、別の実施形態に係るアプリケーションアノマリ検出のカスタマイズの方法のダイアグラム６００を示す。この例では、異常パラメータに関するアプリケーションの異常パターンに基づいて、異常レベルおよび／またはアクションがカスタマイズされてよい。図６は、一定期間にわたって２つのデバイス、すなわち、デバイス１およびデバイス２で、ある異常パラメータについて検出された同じアプリケーションに関する異常の数をそれぞれ示したグラフ６１０および６２０を示している。これら２つのデバイスにより同じ異常検出モデルが使用される。ｘ軸は異常パラメータを表し、ｙ軸は検出された異常の数を表す。一定期間にわたって検出された異常は、一組の異常閾値Ｔ１からＴ７に基づいて定義される複数の異常レベルに該当してよい。例えば、異常パラメータがＴ１より小さい場合は異常が異常レベル１にあってよく、異常パラメータがＴ１とＴ２との間である場合は異常レベル２にあってよく、異常パラメータがＴ２とＴ３との間である場合は異常レベル３にあってよい、などである。故に、グラフ６１０および６２０は、デバイス１およびデバイス２の異常パターンをそれぞれ示す。一例では、デバイスごとの異常検出結果のヒストグラムが一定期間にわたって計算され、それぞれのデバイス内のアプリケーションについて各異常レベルが検出された頻度または回数を示すために使用されてよい。履歴データ、例えば、図２の段階２１０で記録されるデータは、ヒストグラムを決定するために使用されてよい。異常検出モデルがライン６３０で示すようなＴ４に基づいて、アプリケーションが異常であるかどうかを決定すると仮定すると、これら２つのデバイスに関する異常閾値は、それぞれの異常パターンに基づいて調整されてよい。図示の通り、デバイス１については、検出された全ての異常が、異常パラメータがＴ２を下回る（すなわち、異常レベル１および２のみを有する）場合に生じ、一定期間中にこれより高い異常レベルは検出されなかった。一例では、（ライン６３２で示すような）閾値Ｔ２が、アノマリを検出するための閾値としてデバイス１のために選択されてよい。Ｔ２を超えるリソース使用レベルはいずれも、このデバイスにとって異常または想定外と見なされる。一方、デバイス２はリソースを大量に消費するユーザであり、異常検出モデルは、複数の異なる異常レベルにある異常の例を多く検出した。過度の量の通知を与えるのを回避すべく、例えば、または、アプリケーションおよびユーザがデバイスリソースをより自由に使用できるようにすべく、デバイス２は、Ｔ４ではなく（ライン６３４で示すような）閾値Ｔ５を使用して、アプリケーションが異常であるかどうかを検出してよい。異常パターンに基づいて、異常レベルごとに起こされるアクションが調整されてもよい。

図２を改めて参照すると、方法２００の段階２１６では、ユーザフィードバックを受信してよい。ユーザフィードバックは、例えば、特定のアクションを起こすこと、より低い異常レベルまたはより低い閾値を異常検出に使用してより多くのエネルギー節約を適用すること、特定の閾値を異常のレベルに使用すること、または、特定の異常のレベルを使用してアプリケーションをラベル付けすること、アプリケーションが、必要なだけのリソースを多かれ少なかれ自由に使用できるようにすること、通知を確認する頻度を変更すること、検出された異常のレベル、または、アプリケーションアノマリを検出し、かつ、適切なアクションを起こすために使用され得る、任意の他のフィードバック情報に基づいてアクションを変更することなどを行うための、ユーザの命令、指標、または選択を含んでよい。フィードバック情報は、段階２１０でコンピューティングデバイスにより記憶されてもよい。段階２１０で記録されるデータは、ソフトウェアコンポーネントおよびハードウェアコンポーネントを含むデバイス、サービス、またはアプリケーションのユーザエクスペリエンス、デバイス性能、設計、および開発を改善するのに役立つ利点を提供してよい。例えば、データは、アプリケーションまたはプロセスにおけるバグまたは性能の問題を識別するために使用されてよい。データは、様々なデバイスモデル、複数の異なるバージョンのソフトウェアコンポーネントまたはハードウェアコンポーネント間で性能およびユーザエクスペリエンスを比較するために使用されてよい。データは、現在および将来の製品におけるソフトウェアコンポーネントおよびハードウェアコンポーネントの設計および性能を改善し、デバイスに対するユーザ満足度を改善するために使用されてもよい。

幾つかの実施形態では、コンピューティングデバイスが、１または複数の異常パラメータについて１または複数のアプリケーションのアノマリを検出するための複数の異常検出モデルを受信および実行してよい。複数の異常検出モデルの各々は、機械学習技術を使用して構築されてよい。複数の異常検出モデルは、同じ組の異常パラメータまたは異なる組の異常パラメータについてアプリケーションのアノマリを検出するように構成されてよい。複数の異常検出モデルは、同じ組のアプリケーション、または、デバイス内の異なる組のアプリケーションの異常を検出するように設計されてよい。複数の異常検出モデルは、デバイスで使用される１または複数のアプリケーションの異常を検出するために、同じ組の入力データ（例えば、上記のリソース使用、エネルギー消費、および他の関連するアプリケーションおよびデバイスのデータ）を使用してもよいし、異なる組の入力データを使用してもよい。複数の異常検出モデルは、複数の異常検出モデルが別様に設計または構築されることに起因して、例えば、ディープニューラルネットワークモデルを使用して訓練されるときのランダムな初期化に起因して、または、機械学習を使用して訓練されている場合に複数の異なる訓練方法を使用することに起因して、同じ異常パラメータについて同じアプリケーションに関する複数の異なる異常検出結果を出してよい。

複数の異常検出モデルは、１または複数のアプリケーションのアノマリを同時に検出するためにコンピューティングデバイスにより使用されてよい。総合的な検出性能を改善するために、複数の異常検出モデルが使用されてよい。図７は、ある実施形態に係るアプリケーションアノマリ検出の方法７００のダイアグラムを示している。この例では、コンピューティングデバイスが、複数の異常検出モデル、すなわち、モデル１（７０２）、モデル２（７０４）、...および、モデルＫ（７０６）を使用して、Ｍ個の異常パラメータ、すなわち、パラメータ１、パラメータ２、...パラメータＭについて、１または複数のアプリケーションのアノマリを検出する。例えば、異常パラメータは、ＣＰＵ ＦＧエネルギー、ＣＰＵ ＢＧエネルギー、および自己起動の数であってよい。幾つかの実施形態では、同じ入力データ、例えば、図２に示すリソース使用データおよび他の関連データがモデル１からＫの各々に入力される。ただし、モデルは、アプリケーションアノマリ検出にリソース使用データの一部のみを使用してよい。モデル１からＫの各々は、入力データを受信し、Ｍ個の異常パラメータの各々について異常検出結果を生成する。一例では、Ｋ個のモデルの各々は、アプリケーションの異常のレベルを検出するアノマリレベル検出モデルであってよい。別の例では、３つのモデルの各々は、アプリケーションが一組の異常レベルに該当する推定確率を生成するアノマリ尤度推定モデルであってよい。更に別の例では、１つのモデル、例えば、モデル１は異常レベル検出モデルであり、その他のモデルはアノマリ尤度推定モデルである。更に別の例では、モデル１はアノマリ尤度推定モデルであり、その他のモデルはアノマリレベル検出モデルである。更に別の例では、モデル１からＫの全てまたはほとんどが異常検出モデルであるが、各々が異なる機械学習方法を使用して、または異なる訓練アルゴリズムを使用して訓練される。モデル１からＫの異常検出結果を組み合わせ、かつ、Ｍ個の異常パラメータの各々についてアプリケーションに関する統合された検出結果または推定結果を生成するために、モデルＥ（７０８）が使用されてよい。モデルＥは、コンピューティングデバイスにより受信および実行されてもよい。モデルＥは、機械学習技術を使用して構築されてよい。モデルＥは、ニューラルネットワークモデル、ベイジアンネットワークモデル、または多数決投票モデルであってよい。モデルＥは、様々な方法、例えば、多数決投票または加重和などを使用して、モデル１からＫの検出結果を組み合わせてよい。実例として、Ｋ＝３およびＭ＝２の場合は、表２は、モデル１から３の異常検出結果、およびモデルＥの統合結果、例えば、ある時点にまたは一定期間にわたってデバイスで記録されたアプリケーションに関するデータを示している。この例では、モデル１およびモデル３は、３つの異常レベル、すなわち、過度の使用、異常、高度に異常の検出結果を生成するアノマリレベル検出モデルである。モデル２は、３つの異常レベルにおける確率を生成するアノマリ尤度推定モデルである。「異常検出モデル」という用語は、アノマリレベル検出モデル、または異常尤度推定モデル、またはこれらの組み合わせを指すことがある。

図８は、ある実施形態に係る、アプリケーションアノマリ検出のためのコンピューティングデバイスとサーバとの間の相互作用の方法８００のダイアグラムを示している。コンピューティングデバイス８１０がサーバ８２０から１または複数の異常検出モデルをダウンロードまたは受信してよく、１または複数の異常検出モデルを実行し、１または複数の異常パラメータについて１または複数のアプリケーションのアノマリを検出する。コンピューティングデバイス８１０は、図２に示す方法２００を実行してよい。コンピューティングデバイス８１０は、図２の段階２１２と同様に、自らが一定期間にわたって記録したデータをサーバ８２０に送信してよい。

サーバ８２０は、ローカルネットワークサーバ、リモートサーバ、またはクラウドサーバであってよい。サーバ８２０は、複数のコンピューティングデバイス、例えば、８３０～８３４および８１０から１または複数の異常検出モデルを構築するためのデータを収集するように構成される。データは、例えば、一組のアプリケーションの性能およびユーザエクスペリエンスを改善するのに役立つよう、ユーザの合意または同意に基づいて、ランダムに選択された組のデバイスから収集されてよい。ランダムな選択は、ユーザが地理的に多様化した地域の出身であり、世界中に均等に分布するよう、プライバシーを保護するためのものである。ユーザの選択ではいかなる特定の地域にも焦点を当てないというポリシが定義されてよく、識別可能またはプライバシーセンシティブなデータは収集することができない。全てのデータが匿名であり、ユーザデータのプライバシーが保護され、ユーザデータのセキュリティが保証される。サーバとコンピューティングデバイスとの間の通信または相互作用は、データおよびモデルを送受信するために双方向性であってよい。サーバ８２０は、収集されたデータを取得し、収集されたデータの分析を実行し、１または複数の異常検出モデルを訓練する。サーバ８２０は、１または複数の異常検出モデルを１または複数のコンピューティングデバイスにプッシュしてよい。サーバ８２０は、異常検出モデルをダウンロードまたはアップグレードする準備ができていることを１または複数のコンピューティングデバイスに通知してよい。サーバ８２０は、データを周期的に収集し、新たに収集されたデータを使用してモデルを訓練することより１または複数の異常検出モデルを更新してよい。故に、１または複数の異常検出モデルは、ユーザ行動の変化または環境の変化に対応するよう更新されてよい。

図９は、ある実施形態に係る、異常検出モデルを構築するための方法９００のフローチャートである。方法９００は、図８のサーバ８２０などのサーバにより実行される動作を示す。以下では、１つのアプリケーションおよび１つの異常パラメータを実例として使用しながら、方法９００について説明する。ただし、方法９００は、１または複数の異常パラメータについて複数のアプリケーションのアノマリを検出するための異常検出モデルを構築するために使用されてよい。図示の通り、方法９００の段階９０２では、複数のコンピューティングデバイスで実行されているアプリケーションに関連するデータサンプルを取得する。複数のアプリケーションの場合は、方法９００では、複数のコンピューティングデバイスで実行されている複数のアプリケーションに関連するデータサンプルを取得してよい。複数のコンピューティングデバイスの各々から収集されるデータサンプルは、図２の段階２１２との関連で説明したようなコンピューティングデバイスにより送信されるデータを含んでよい。例えば、複数のコンピューティングデバイスの各々から収集されるデータサンプルは、アプリケーションのリソース使用データ、例えば、図２との関連で説明したリソース使用データ、アプリケーションについて生成される検出結果、例えば、図２の段階２０６で取得される検出結果、アプリケーションで起こされるアクション、例えば、図２の段階２０８で起こされるアクション、アプリケーションの異常パラメータ、例えば、ＣＰＵ ＢＧエネルギー、ＣＰＵ ＦＧエネルギー、ウェイクロック保持時間、ＩＯアクセスレート、メモリスペース、電力消費など、アプリケーションの使用パターン、またはユーザエクスペリエンスフィードバック、例えば、図２の段階２１６で受信されるフィードバックを含んでよい。複数のコンピューティングデバイスの各々から収集されるデータサンプルは、複数の組のデータサンプルを含んでよく、各組のデータサンプルは、特定のタイムスタンプと関連付けられてよい。

方法９００の段階９０４では、異常パラメータを決定する。異常パラメータは、アプリケーションによりアクセスされるリソースの関連リソース使用に対応する。方法９００では、異常パラメータについてアプリケーションに関するアノマリを検出するように異常検出モデルを訓練するための異常パラメータを決定または選択してよい。異常パラメータは、アプリケーションが正常に実行されているかどうかを決定するために使用されるコンピューティングデバイスのリソースを示す。異常パラメータは、専門家、設計者、またはサービスプロバイダなどから受信される入力に基づいて決定されてよい。異常パラメータの選択は、設計目標、エネルギー節約要件、または顧客要件に基づいていてよい。複数の異常パラメータが決定されてよく、複数の異常パラメータの各々は、１または複数のアプリケーションのアノマリ検知に使用される。異常パラメータは、幾つかのリソース使用パラメータに対する数学的演算を何らかの形で組み合わせるかまたは実行することから計算される、組み合わせパラメータ、または属性、または定量的特徴であってよい。例えば、異常パラメータは、Ｗｉ－Ｆｉ ＢＧの使用、モデムＢＧの使用、およびＢｌｕｅｔｏｏｔｈ（登録商標）ＢＧの使用の加重和であってよい。別の例として、異常パラメータは、リアカメラの使用、フロントカメラの使用、およびマルチメディアの使用の加重和であってよい。

方法９００の段階９０６では、決定された異常パラメータについて生成される異常検出結果のフォーマットを決定する。例えば、異常検出結果は、アプリケーションが正常であるのか異常であるのかを示すフォーマットであってよい。別の例では、異常検出結果は、一組の異常レベルのうちの１つにあるアノマリをアプリケーションが有するかどうかを示すフォーマットであってよい。別の例では、異常検出結果は、アプリケーションが一組の異常レベルにある確率を示すフォーマットであってよい。当該一組の異常レベルは、図４との関連で説明したような異常のレベルを含んでよい。方法９００では、組み合わせられたフォーマットの使用を決定してもよい。例えば、方法９００では、一組の異常レベルのうちの１つにあるＣＰＵ ＦＧエネルギー消費に関するアノマリをアプリケーションが有するかどうかの検出を決定してよく、アプリケーションが当該一組の異常レベルに該当する確率を推定してもよい。異なる異常パラメータについては、異常検出結果または異常レベルのフォーマットが異なっていてよい。異常検出結果または異常レベルまたは異常種別のフォーマットは、専門知識および経験、設計目標、エネルギー節約要件、または顧客要件に基づいて、専門家、設計者、またはサービスプロバイダにより決定されてよい。

方法９００の段階９０８では、収集されたデータサンプルのデータ分析を実行する。データサンプルに対して実行されるデータ分析は、異常パラメータに関連または依存する１または複数のパラメータを識別するために使用されてよい。複数の異なるリソース使用が互いに関連または依存してよい。故に、関連または依存する第２のリソース使用を考慮することにより、第１リソース使用におけるアノマリを決定する必要があるかもしれない。異常パラメータに関連または依存するパラメータは、使用パラメータと呼ばれることもある。図１０は、第１異常パラメータと、関連リソース使用パラメータまたは属性（説明を目的として関連パラメータと呼ばれる）との関係を示したグラフ１０００を示している。この関係は、複数のユーザデバイスから収集され、かつ、アプリケーションと関連付けられる、データサンプルに基づいて示される。図１０の各点（または黒丸）は、１つのコンピューティングデバイスまたは１つの使用データサンプルを示す。ｘ軸は、第１異常パラメータに強く関連または依存する関連パラメータ（すなわち、関連リソース使用パラメータまたは属性）を表し、ｙ軸は第１異常パラメータを表す。図示の通り、関連パラメータと第１異常パラメータとの間には有意な相関性がある。第１異常パラメータ（リソース使用であってよい）は、関連パラメータが増加するにつれて増加する。例として、関連パラメータ（ｘ軸）は、ユーザまたはデバイスが使用するために選択されるアクティブまたは自発的なリソース使用の量を示すパラメータであってよいが、第１異常パラメータ（ｙ軸）は、ユーザによるリソースのアクティブな使用に何らかの形で関連するかまたは引き起こされる、自由裁量のリソース使用の量として見なされてよい。

第１異常パラメータに係るアプリケーションにおけるアノマリは、ＣＰＵ ＢＧの使用などのリソース使用であってよく、第１異常パラメータがライン１００２で示すような一定の閾値を超えているかどうかをチェックすることにより決定される。第１異常パラメータが閾値を超えている場合は、アプリケーションは、第１異常パラメータにおいて異常であると決定される。ただし、場合によって、アプリケーションの第１異常パラメータの値がより大きいことは、アプリケーションの関連リソース使用パラメータの値がより大きいことにより引き起こされることから、正常であるかもしれない。この場合は、関連リソース使用パラメータの値が高いときにアプリケーションにアノマリがあると決定されるべきではない。

一実施形態では、複数のコンピューティングデバイスの強く関連または依存するリソース使用パラメータ（図１０のｘ軸）の値が分析され、幾つかの使用グループ、例えば１から６に類別されてよい。グループ１から６の各々は、関連リソース使用パラメータの値の範囲に対応する。複数のコンピューティングデバイスは次に、第１異常パラメータに強く関連または依存するリソース使用パラメータの値に基づいて、使用グループに類別される。コンピューティングデバイスでアプリケーションにより使用される関連リソース使用パラメータの値は、コンピューティングデバイスから収集されたデータサンプルを使用して生成されてよい。次に、各グループ内の関連リソース使用パラメータに基づいて、１または複数の異常閾値が使用グループごとに具体的に計算されてよい。１つの異常レベルのみを考慮すると（それで正常な使用と異常な使用とを識別できることを意味する）、図１０に示す例では、統計アノマリ分析、異常評価、もしくは異常検出基準に基づいて、または、専門家の知識を使用して、または、アプリケーションログもしくはシステムログを使用して、ライン１００４から１０１４は、グループ１から６について計算された閾値をそれぞれ示す。下の表３は、グループ１から６について計算された６つの閾値（Ｔ１，１）から（Ｔ１，６）を示す。（Ｔ１，ｉ）は、グループｉに関する閾値Ｔ１を示す。閾値は、それぞれのグループにおける関連リソース使用パラメータの影響を考慮して計算される。異常閾値が決定された状態で、コンピューティングデバイス上のアプリケーションに第１異常パラメータに関するアノマリがあるかどうかを決定する場合は、まず、コンピューティングデバイスが、関連付けられる関連リソース使用パラメータに基づいてグループ１から６のグループに類別されてよく、次に、グループに関する閾値が識別され、アプリケーションの第１異常パラメータと比較される。アプリケーションの第１異常パラメータが識別された閾値を超えている場合は、アプリケーションに第１異常パラメータにおけるアノマリがあると決定される。コンピューティングデバイスを複数の異なる使用グループに類別し、かつ、グループ固有閾値を使用することにより、アノマリ検知における失敗または間違いを低減または回避してよい。各使用パラメータに基づいて類別される使用グループは、更新または再定義されてよく、新たに収集されたデータサンプルに基づいて、対応する閾値が再計算されてよい。

幾つかの実施形態では、異常パラメータと複数の関連リソース使用パラメータとの間の依存関係が確立または識別されてよい。関連または依存する複数のパラメータの各々に基づいて、複数のグループが定義されてよい。この場合は、関連または依存する複数のパラメータのうちの幾つかまたは全ての組み合わせに基づいて定義されるグループを考慮して、閾値が計算されてよい。例えば、異常パラメータが、２つの異なるリソース使用パラメータ、すなわち、パラメータ１およびパラメータ２に依存していると識別される。パラメータ１およびパラメータ２の例には、オンスクリーン時間、Ｗｉ－Ｆｉロック時間、オーディオ使用時間、およびマルチメディア使用時間が含まれてよい。例えば、収集されたデータサンプルのデータ分析に基づいて、４つのグループがパラメータ１に基づいて定義され、２つのグループがパラメータ２に基づいて定義される。使用パラメータごとのグループは、図１０との関連で上述したものと同様に定義されてよい。次に、関連パラメータの全てに基づいて定義されるグループの様々な考えられる組み合わせに該当するコンピューティングデバイスの状況を考慮して、閾値が計算されてよい。表４は、この場合に計算される閾値の例を示している。表４では、Ｇｋｉはパラメータｋに基づいて定義されるｉ番目のグループを表し、ｋ＝１、２であり、ｉ＝１、２、３、４である。グループの各組み合わせに対応して、８つの閾値、すなわち（Ｔ１，１）から（Ｔ１，８）が決定される。例えば、コンピューティングデバイスがパラメータ１およびパラメータ２に基づくＧ１１とＧ２１との組み合わせに該当する場合は、閾値（Ｔ１，１）を使用して異常パラメータと比較し、アプリケーションに異常パラメータにおけるアノマリがあるかどうかを決定する。コンピューティングデバイスがパラメータ１および２に基づくＧ１３とＧ２２との組み合わせに該当する場合は、閾値Ｔ１，６が使用される。幾つかの実施形態では、グループの同じ組み合わせに該当するコンピューティングデバイスが１つの組み合わせグループに類別されてよい。表４に示すように、Ｇ１１とＧ２１との組み合わせに該当するコンピューティングデバイスは、組み合わせグループＣＧ１として類別され、Ｇ１１とＧ２２との組み合わせに該当するコンピューティングデバイスは、ＣＧ２として類別され、Ｇ１２とＧ２１との組み合わせに該当するコンピューティングデバイスは、ＣＧ３として類別される、などである。故に、この例の関連または依存する２つのリソース使用パラメータ、パラメータ１および２に基づいて、８つの組み合わせグループ、すなわち、ＣＧ１からＣＦ８が定義されてよく、各組み合わせグループは、閾値（Ｔ１，１）から（Ｔ１，８）にそれぞれ対応する。関連または依存する単一パラメータが１つだけ異常パラメータについて識別される場合は、もたらされる組み合わせグループが、関連または依存する単一パラメータに基づいて類別されるグループと同じになる。本開示では、組み合わせグループが使用グループと呼ばれることもある。なぜなら、対応する閾値を有する使用グループに基づいてアノマリが検出されるからである。

幾つかの実施形態では、図１０で説明したような使用グループごとに単一の異常閾値を使用するのではなく、複数の異常レベル、複数の異常種別、または複数の異常閾値が使用グループごとに識別されてよい。例として、図１１は、３つの異常閾値がある場合を示しており、これらの異常閾値は、４つの異常種別（例えば、正常、過度の使用、異常、高度に異常）を有することになるかもしれない。図１１では、Ｔｉ，ｊは、使用グループｊに関する閾値Ｔｉを表し、ｉ＝１、２、３であり、ｊ＝１、２、...、６である。使用グループ１における「正常」の種別は、関連リソース使用パラメータがグループ１に属する場合に異常パラメータの値が閾値（Ｔ１，１）より小さいことを意味する。使用グループ１については、「高度に異常」とは、異常パラメータの値が閾値（Ｔ３，１）を上回っていることなどを意味する。

故に、図９を改めて参照すると、段階９０８で実行されるデータ分析に基づいて、方法９００の段階９１０では、異常パラメータに関連または依存する１または複数のパラメータを識別する。方法９００の段階９１２では、関連または依存する１または複数のパラメータに基づいて、複数の使用グループを決定する。方法９００の段階９１４では、複数の使用グループの各々について異常のレベルまたは閾値を計算する。これは、統計分析および異常評価アルゴリズムに基づいて行われてよい。方法９００では、複数の異常レベルの検出を考慮すると、図１１で説明したような使用グループごとに１つの閾値ではなく複数の閾値を識別してよい。方法９００の段階９１６では、異常パラメータについて各コンピューティングデバイスからの各データサンプルが該当する異常レベルを決定する。これは、対応するコンピューティングデバイスから収集されたデータサンプルに基づいて、かつ、複数の組み合わせグループに対応して生成された閾値を使用して決定される。例えば、方法９００では、コンピューティングデバイスが属する組み合わせグループ、例えば、表４のＣＧ４を決定し、コンピューティングデバイス上のアプリケーションの異常パラメータの値を、決定された組み合わせグループに対応する閾値、すなわち（Ｔ１，４）と比較する。方法９００では次に、対応するコンピューティングデバイスのデータサンプルに対応する異常検出結果を生成する。例えば、コンピューティングデバイスから収集されたデータサンプルが、異なる時間にコンピューティングデバイスにより記録された６組のデータサンプルを含み、かつ、各組のデータサンプルが図２で記憶されるようなデータを含む場合、この方法では、例として表５に示すような６つの異常検出結果を生成してよい。各データサンプルは、各サンプルが属する異常種別を示す、対応する異常検出結果を有する。

方法９００では、複数のコンピューティングデバイスの各々のデータサンプルの各々について、または、コンピューティングデバイスの一部について、異常種別または異常レベルを生成してよい。生成された種別またはレベルは、基準の異常種別または異常レベルと呼ばれることがある。段階９１８で生成される基準の異常種別または異常レベルを用いて、方法９００では、各データサンプルに異常ラベルを割り当てる。データサンプルに割り当てられる異常ラベルは、データサンプルに対応する異常種別または異常レベルを示す。表５を例として使用すると、データサンプル１は「正常」のラベルを割り当てられてよく、データサンプル２は「過度の使用」のラベルを割り当てられてよく、データサンプル３は「正常」のラベルを割り当てられてよく、データサンプル４および５は「異常」のラベルをそれぞれ割り当てられてよく、データサンプル６は「高度に異常」のラベルを割り当てられてよい。このように、収集されたデータサンプルの全てまたは一部がラベル付けされてよい。方法９００の段階９２０では、ラベル付けされたデータサンプルのうちの幾つかまたは全てを使用して、異常検出モデルを訓練する。異常検出モデルは、このタスクに適用可能かつ効率的である機械学習技術を使用して訓練されてよい。例えば、異常検出モデルは、人工ニューラルネットワーク、ディープニューラルネットワーク、またはベイジアンネットワークなどであってよい。方法９００の段階９２２では、更新された異常検出モデルをユーザまたはデバイスに通知してよい。方法９００では、異常検出モデルをダウンロードまたはアップグレードする準備ができていることを通知してよい。方法９００の段階９２４では、異常検出モデルをデバイスにプッシュしてよい。

方法９００では、大量のデータサンプルを収集して、１または複数の異常検出モデルを訓練してよい。方法９００では、複数の異常パラメータに基づいて複数のアプリケーションのアノマリを検出するための異常検出モデルを構築するために使用されてよい。方法９００では、複数のコンピューティングデバイスで実行されている複数のアプリケーションに関連するデータサンプルを取得することができ、アプリケーションごとに、方法９００の段階９０４から９２０が実行されてよい。次に、アプリケーションと異常パラメータとの組み合わせのラベル付けされたデータを使用して、複数のアプリケーション、および、複数の異常パラメータまたは予測出力について異常を一度に検出できる１または複数の異常検出モデルを構築する。

図１２は、ある実施形態に係るアプリケーションアノマリ検出のシステム１２００のブロックダイアグラムを示す。図示の通り、実施形態に係るシステム１２００は、コンピューティングデバイス１２１０と、サーバ１２５０とを含む。コンピューティングデバイス１２１０は、監視およびデータ記録モジュール１２１２と、異常検出モジュール１２１４と、アクションモジュール１２１６と、送受信モジュール１２１８と、記憶装置またはメモリ１２２０と、カスタマイズまたはデバイス適応モジュール１２２２とを含む。サーバ１２５０は、送受信モジュール１２５２と、データ取り込みおよびデータ分析モジュール１２５４と、機械学習モジュール１２５６と、記憶モジュール１２５８とを含む。

監視モジュール１２１２は、コンピューティングデバイス１２１０におけるアプリケーションの動作または実行中にアプリケーションのリソース使用を監視し、アプリケーションのリソース使用データと、他の関連するデバイスおよび環境のデータとを取得および収集するように構成されてよい。監視モジュール１２１２により取得されたデータは、記憶装置１２２０に記憶されてよい。異常検出モジュール１２１４は、１または複数の異常検出モデルを使用して、例えば、図２または図７に示す実施形態に係る方法を使用して、コンピューティングデバイス１２１０で実行されている１または複数のアプリケーションの異常を検出するように構成されてよい。アクションモジュール１２１６は、異常検出モジュール１２１４の結果に応答してアクションを起こすように構成されてよく、例えば、図２の段階２０８を実行する。アクションモジュール１２１６は、記憶装置１２２０からアクションを取り込み、異常検出結果に対応して、起こされるアクションを記憶装置１２２０に記録してよい。送受信モジュール１２１８は、記憶装置１２２０に記憶されたデータを取り込み、当該データをサーバ１２５０に送信し、サーバ１２５０から１または複数の異常検出モデルを受信するように構成されてよい。カスタマイズモジュール１２２２は、図２の段階２１４を実行し、１２１６により使用される基準を調整して図４から図６との関連で上述したアクションを起こすように構成されてよい。

送受信モジュール１２５２は、記憶装置１２５８から１または複数の異常検出モデルを取り込み、コンピューティングデバイス１２１０および他のコンピューティングデバイスに１または複数の異常検出モデルを送信するように構成されてよい。送受信モジュール１２５２は、コンピューティングデバイス１２１０および他のコンピューティングデバイスからデータを受信し、受信されたデータを記憶装置１２５８に記憶するように構成されてもよい。データ取り込みモジュール１２５４は、機械学習モジュール１２５６が１または複数の異常検出モデルを構築または訓練できるよう、記憶装置１２５８からデータを取り込むように構成される。機械学習モジュール１２５６は、段階９０８から９２０を実行し、１または複数の異常検出モデルを構築すること、および、設計または構築された異常検出モデルを記憶装置１２５８に記憶することを行うように構成されてよい。サーバ１２５０は、複数のコンピューティングデバイスに接続され、複数のコンピューティングデバイスから関連データを受信し、複数のコンピューティングデバイスから受信されたデータを使用して１または複数の異常検出モデルを構築してよい。

幾つかの実施形態では、異常検出モジュール１２１４がデバイス内で完全に実行されないことがあり、代わりに、リソース使用データおよび他の関連データがローカルコンピューティングサーバまたはリモートコンピューティングサーバに送信されて、異常検出を実行してもよい。これは、デバイスにモジュール１２１４がないかもしれず、異常検出タスクがデバイスの外部で実行されてよく、次に、検出結果がデバイスに返信されることを意味する。デバイスは次に、デバイスにより使用されるアプリケーションごとに検出された異常レベルに応答してアクションを起こしてよい。別の実施形態では、異常検出モジュール１２１４は、２つの部分に分割されてよい。デバイスの内部では、例えば、属性または使用リソースパラメータの抽出、データ分析、および前処理を含む第１部分が実行されてよく、ローカルまたはリモートのコンピューティングサーバまたはサポートデバイスでは、異常検出プロセスの残りが実行されてよく、次に、異常検出結果はデバイスに返信される。

図１３は、ある実施形態に係るアプリケーションアノマリ検出の方法１３００のフローチャートを示している。方法１３００は、ユーザデバイスで実行される動作を示すことができる。図示の通り、方法１３００の段階１３０２では、リモートデバイスから第１異常検出モデルを受信する。第１異常検出モデルは、リソース使用に関するアプリケーションのアノマリを検出するための機械学習技術を使用して訓練可能である。方法１３００の段階１３０４では、アプリケーションのリソース使用データを取得する。リソース使用データは、第１異常検出モデルに従って取得されてよい。リソース使用データは、関連するデバイスおよび環境のデータと、コンピューティングデバイスにおいてアプリケーションによりアクセスされる１または複数のハードウェアコンポーネント、または、１または複数のサービスの使用またはエネルギー消費に関する情報とを含む。方法１３００の段階１３０６では、第１異常検出モデルを使用して、取得されたリソース使用データに基づいて、アプリケーションにリソース使用におけるアノマリがあるかどうかを決定する。方法１３００の段階１３０８では、リソース使用に関するアプリケーションのアノマリに関する決定に応答してアクションを起こす。

図１４は、ある実施形態に係る、異常検出モデルを構築するための方法１４００のフローチャートを示している。方法１４００では、ローカルコンピューティングサーバ、リモートサーバ、またはクラウドサーバなどのリモートデバイスにおける動作を示すことができる。図示の通り、方法１４００の段階１４０２では、複数のコンピューティングデバイスからアプリケーションに関連するデータサンプルを取得する。データサンプルは、複数のコンピューティングデバイスにおいてアプリケーションによりアクセスされる１または複数のハードウェアコンポーネント、または、１または複数のサービスの使用またはエネルギー消費に関する情報と、他の関連するデバイスおよび環境のデータとを含んでよい。各データサンプルは、複数のコンピューティングデバイスのうちの１つと関連付けられてよい。方法１４００の段階１４０４では、データサンプルにラベルを割り当てる。それぞれのコンピューティングデバイスと関連付けられるデータサンプルに割り当てられたラベルは、それぞれのコンピューティングデバイスでの第１リソース使用においてアプリケーションが有する複数の異常レベルのうちの１つの異常レベルを示す。方法１４００の段階１４０６では、ラベル付けされたデータサンプルと機械学習技術とを使用して異常検出モデルを構築する。異常検出モデルは、第１リソース使用におけるアプリケーションのアノマリを検出するように構成される。

検出されるアプリケーションのアノマリについて、第１リソース使用（またはパラメータ、属性、または定量的パラメータ）が決定されてよい。第１リソース使用は、第１異常パラメータまたは属性に対応する。当該一組の異常レベルは、第１リソース使用におけるアプリケーションのアノマリのレベルを示すと決定されてよい。複数のコンピューティングデバイスの各々について、それぞれのコンピューティングデバイスのデータサンプルに基づいて、アプリケーションに第１リソース使用におけるアノマリがあるかどうかが検出または決定されてよい。故に、複数のコンピューティングデバイスのデータサンプルに関する複数の異常評価（または検出）結果が生成されてよく、複数の異常評価結果の各々は、当該一組の異常レベルのうちの１つの異常レベルを示す。次に、データサンプルには、評価結果に基づいて、対応する異常レベルがラベル付けされてよい。

アプリケーションのアノマリは、図９の段階９１２から９１６で説明した方法を使用して決定されてよい。幾つかの実施形態では、収集されたデータサンプルの分析に基づいてアプリケーションのアノマリを決定するために、他の方法が使用されてもよい。例えば、密度または分布に基づく方法、距離に基づく方法、クラスタリングに基づく方法、類似度に基づく方法、機械学習に基づく方法、または、再構築エラーに基づく方法など、異常評価およびデータ分析の方法が、データサンプルの異常レベルを評価するために使用されてよい。１つのアプリケーションと関連付けられるデータサンプルについては、次に、関係する属性またはリソース使用ごとに、対応する異常ラベルがデータサンプルの各々に割り当てられてよい。別の実施形態では、一組のラベルまたは異常レベルをこれらのデータサンプルに割り当てるのではなく、各データサンプルに連続的な異常または使用の重大度の値が割り当てられ、各データサンプルは次に、リソース使用および異常レベルを推定または予測するためのモデルを訓練するために使用される。幾つかの実施形態では、複数のデバイスから収集された大量のデータに対する統計分析、異常評価、およびデータ分析を使用するのではなく、性能ログ、使用ログ、事象報告、またはユーザエクスペリエンスフィードバックを使用して、アプリケーションにリソース使用におけるアノマリがあるかどうかを決定してよい。加えて、専門家は、自らの経験、洞察、および知識に基づいて、収集されたデータサンプルおよび記録を評価して、デバイスでアプリケーションアノマリが生じたかどうかを決定することができる。

図１５は、別の実施形態に係るアプリケーションアノマリ検出の方法１５００のフローチャートを示している。図示の通り、方法１５００の段階１５０２では、コンピューティングデバイスで実行されているアプリケーションにリソース使用におけるアノマリがあるかどうかを検出する。アプリケーションのアノマリは、アプリケーションについて取得されたリソース使用データに基づいて、かつ、機械学習技術を使用して構築された異常検出モデルを使用して検出されてよい。方法１５００では、アプリケーションに複数の異常レベルおよび使用レベルにおけるアノマリがあるかどうかを検出してよい。次に、アプリケーションに関する異常検出結果が生成されてよく、これには、１または複数の異常レベルおよび各レベルの尤度の検出が含まれてよい。方法１５００の段階１５０４では、異常検出結果に応答して、アプリケーションの実行時にアクションを起こす。方法１５００の段階１５０６では、アプリケーションの異常検出結果と、当該異常検出結果に応答して起こされた対応するアクションとに関するデータを一定期間にわたって収集する。方法１５００の段階１５０８では、収集されたデータに基づく適応モデルまたはカスタマイズモデルを使用して、異常検出結果に応答して起こされるアクションを調整する。これは、コンピューティングデバイスのユーザエクスペリエンスまたは性能を改善するのに役立ち得る。

本開示の複数の実施形態は、コンピューティングデバイスで異常に実行されているアプリケーションにより引き起こされる過度のエネルギー消費を削減することによりユーザエクスペリエンスを改善するのに役立つ。これらの実施形態はバッテリ駆動式のコンピューティングデバイスにとってより有用となり、ひいてはエネルギー源の容量が制限される。アプリケーション、プロセス、ツール、またはソフトウェアがデバイスで一定期間にわたって異常な動作をする場合は、バッテリが通常よりも速く消耗し、ひいてはデバイスのユーザがデバイスの性能および効率に不満を感じることがある。異常は、アプリケーションによるハードウェアコンポーネント、サービス、およびリソースの使用の分析から収集されたデータを使用して検出される。アプリケーションによるエネルギー消費またはリソース使用における異常が一定期間にわたって生じる場合は、デバイスの温度が過度に上昇することがあり、それによってデバイスまたはそのコンポーネントにダメージを及ぼすか、または、デバイスまたはそのコンポーネントの性能を低下させることがある。従って、これらの実施形態の異常検出によって、デバイスの過度の加熱または温度の問題を防止することもできる。本開示の複数の実施形態は、アプリケーションまたはプロセスが、コンピューティングデバイスにおけるリソース、コンポーネント、またはサービスを異常に使用している場合または事象を検出することもでき、これによってデバイスの総合的な性能または総合的なユーザエクスペリエンスをアプリケーションが低下させるのを防止するのに役立つ。リソースが異常に使用されると、リソースが他のアプリケーションまたはシステムプロセスに割り振られる際にリソースの性能が低下することがあり、結果として、デバイスがより低い性能で機能することがある。本開示の複数の実施形態は、ユーザエクスペリエンスを改善し、性能を改善し、バッテリの寿命を改善し、総合的なエネルギー消費を削減し、過度の熱または温度の問題を軽減し、コンピューティングデバイスで利用可能なリソース、例えば、ソフトウェアコンポーネントまたはハードウェアコンポーネントのより正常かつ効率的な利用を提供するのに役立つ。

図１６は、ある実施形態に係る、コンピューティングデバイスで実行されているアプリケーションの異常検出の方法１６００のフローチャートを示している。方法１６００では、アプリケーションの実行中に収集されたデータに基づいてアプリケーションが実行されている間にアプリケーションの異常を検出することで、リアルタイムのアプリケーション異常検出を実現する。図示の通り、方法１６００の段階１６０２では、コンピューティングデバイスで実行されているアプリケーションを監視する。幾つかの実施形態では、アプリケーションを監視する段階は、アプリケーションの動作または実行中にアプリケーションによりアクセスされる１または複数のハードウェア、１または複数のサービス、１または複数のソフトウェアコンポーネント、または１または複数のリソースの使用など、アプリケーションにより直接的または間接的に使用またはアクセスされるリソースの使用を監視する段階を含む。ハードウェアの使用は、アクセス継続時間、アクセスレート、アクセスの開始時刻および終了時刻などといった、ハードウェアがアクセスまたは使用されるパターンを含んでよい。方法１６００では、アプリケーションによる１または複数のハードウェアの使用に関連するデータを取得、例えば、収集または受信してよい。幾つかの実施形態では、１または複数のハードウェアの使用に関連するデータは、ＣＰＵのフォアグラウンド使用、ＣＰＵのバックグラウンド使用、ウェイクロック保持時間、自己起動の数、アプリケーションのオンスクリーン時間、セルラの使用およびパターン（例えば、フォアグラウンドおよび／またはバックグラウンドのセルラ使用、および／または受信品質を含む）、Ｗｉ－Ｆｉの使用およびパターン（例えば、フォアグラウンドおよび／またはバックグラウンドのＷｉ－Ｆｉ使用、および／または受信品質を含む）、メモリ使用、入出力（ＩＯ）デバイス使用、または位置サービス使用（例えば、使用される位置サービスの数）、またはこれらの任意の組み合わせを含んでよい。幾つかの実施形態では、１または複数のハードウェアの使用に関連するデータは、ＧＰＵの使用（例えば、フォアグラウンドおよび／またはバックグラウンドのＧＰＵ使用を含む）、到着通知の数、バージョン情報、オーディオサービスの使用（例えば、フォアグラウンドおよび／またはバックグラウンドのオーディオ使用）、またはユーザデータへのアクセス数、またはこれらの任意の組み合わせを含んでもよい。１または複数のハードウェアの使用に関連するデータは、アプリケーションの実行の異常を検出するために使用されることになる。当業者であれば、ここで与えられた１または複数のハードウェアの使用に関連する例は説明を目的としたものに過ぎず、ハードウェアの使用に関連するデータはいずれも実施形態に係る方法に適用可能であることが分かるであろう。

スマートフォンにインストールされる「ワッツアップ」という名のソーシャルネットワーキングアプリケーションを例に挙げると、スマートフォンのハードディスクにアクセスしてハードディスクに記憶された音楽を再生してよく、メモリキャッシュを使用して再生用の音楽のデータを一時的に記憶してよく、スマートフォンのスクリーンにアクセスして音楽の再生を表示してよく、スピーカにアクセスして音楽を再生してよい。方法１６００は、ワッツアップによるこれらのハードウェア、すなわち、ハードディスク、メモリ、スクリーン、およびスピーカの使用を監視し、使用データを適宜収集してよい。例えば、使用データは、スクリーン表示継続時間、スピーカオン継続時間、再生に使用されるキャッシュのサイズ、ハードディスクのアクセス数を含んでよい。データは、ワッツアップの実行により消費される電力（例えば、バッテリ電力）を含んでもよい。データは、ワッツアップの実行中に一定期間にわたってディスプレイにより消費されるエネルギー、ワッツアップの実行中に一定期間にわたってＣＰＵにより消費されるエネルギーなどを含んでもよい。一例では、ワッツアップがＷｉ－Ｆｉを介してオンラインで曲を再生する場合に、方法１６００では、例えば無線インタフェースの使用を監視してもよく、Ｗｉ－Ｆｉインタフェースの使用に関するデータ、例えばＷｉ－Ｆｉロック保持時間を取得する。

幾つかの実施形態において、方法１６００では、１または複数のハードウェアの使用に関連する取得されたデータをアプリケーションと関連付けてよい。これは、アプリケーションによりアクセスされるハードウェアの使用に関連するデータが、コンピューティングデバイスにおける異なるプロセス、またはコンピューティングデバイスのオペレーティングシステムなど、アプリケーションとは異なるエンティティにより実際に生成されるが、使用の寄与因子、すなわちアプリケーションが識別されないといった幾つかの場合に有益である。音楽再生用のワッツアップの例では、スマートフォン内のオーディオサーバまたはメディアマネージャが実際に有効化されてワッツアップ用のストリーミングオーディオを配信し、エネルギーを消費する。オーディオサーバがワッツアップの音楽再生に起因してエネルギー量ｘを消費した場合は、エネルギー量ｘは、オーディオサーバの動作について記録されてよいが、消費されるエネルギーの実際のソース寄与因子であるワッツアップとは関連付けられない。１または複数のハードウェアの使用に関連する取得されたデータと、データのソース寄与因子、すなわちアプリケーションとの関連付けは、アプリケーションの実行と関連付けられる使用データを識別するのに役立ち、当該使用データは、アプリケーションの異常を決定するために使用されることになる。アプリケーションに複数の異なるバージョンがある場合は、この関連付けは、アプリケーションのバージョンを識別する情報を含んでよい。

取得されたデータを用いて、方法１６００では、アプリケーションが異常に実行されているかどうか、または、アプリケーションに異常が生じているかどうかを検出してよい。方法１６００では、アプリケーションによるハードウェア、サービス、または他のリソースの使用を一定期間にわたって監視し、関連データを取得し、異常が生じているかどうかを周期的に検出してよい。異常が生じているかどうかは、様々な異常検出条件または異常検出要件に従って検出されてよい。異常検出条件または異常検出要件は、アプリケーション異常の検出動作をトリガまたは開始してよい。例えば、アプリケーションは、自らが占有するメモリスペースが閾値を超えている場合に異常があると決定されてよい。故に、この場合の要件または条件は、閾値を超えているメモリスペースである。別の例では、アプリケーションは、自らが閾値量より多い電力を消費している場合に異常があると決定されてよい。故に、この場合の要件または条件は、閾値または制限を超えている電力消費である。更に別の例では、アプリケーションは、Ｗｉ－Ｆｉロック継続時間が閾値を超えている場合に異常な状態にあると決定されてよい。故に、この場合の要件または条件は、Ｗｉ－Ｆｉロック継続時間である。異常検出要件または異常検出条件の例には、メモリスペース、Ｗｉ－Ｆｉロック保持時間、電力、ＩＯアクセス、ＣＰＵ使用、ＧＰＵ使用、ウェイクロック保持時間などが含まれる。本開示を通じて、「異常検出条件」および「異常検出要件」という用語は同義で使用されている。一実施形態では、アプリケーションの異常は、単一の異常検出条件が満たされている場合に検出されてよい。別の実施形態では、アプリケーションの異常は、複数の異常検出条件または異常検出要件が満たされている場合に検出されてよい。複数の異なる異常検出条件を組み合わせて使用して、アプリケーションの異常を決定してよい。異常検出条件または異常検出要件は、メモリスペースサイズ、電力消費量、またはＷｉ－Ｆｉロック継続時間など、アプリケーションの異常を決定するために使用されるパラメータに対応すると理解することもできる。このパラメータは、アプリケーションの実行中にアプリケーションによりアクセスされるハードウェアの使用を示す。異常検出条件により示されるパラメータに従って、アプリケーションの異常が検出される。パラメータの例には、メモリスペースの平均サイズ、ＩＯデバイスのアクセスレート、平均ウェイクロック保持時間、平均Ｗｉ－Ｆｉロック保持時間、ＧＰＵサービス時間、ＣＰＵサービス時間、平均エネルギー量、またはＣＰＵバックグラウンド実行時間が含まれてよい。当業者であれば、実施形態に係る方法で適用可能である様々な異常検出要件およびパラメータを認識するであろう。

図１６に示すように、方法１６００の段階１６０４では、異常検出条件に従って、１または複数のハードウェアの使用に関連するデータに基づいて、異常検出条件により示されるパラメータに対応する値を計算する。幾つかの実施形態において、方法１６００では、一組のモデルを確立（または構成）してよく、当該一組のモデルの各々は異常検出条件に対応している。モデルの各々は、１または複数のハードウェアの使用に関連する取得されたデータを入力として見なし、異常検出条件により示されるパラメータに対応する値を出力として生成する。これらのモデルを組み合わせて、複数の異なる異常検出条件に対応するパラメータ値を生成できる１つの単一モデルにしてもよい。この場合は、単一モデルは、１または複数のハードウェアまたはサービスの使用に関連する取得されたデータを入力として、値を計算するために使用される異常検出条件を示す指標を出力として見なしてよい。モデルは、アプリケーション異常検出のために予め決定された数学的モデルであってよい。例えば、数学的モデルは、

という式に従ってパラメータの値を計算してよく、

は、機械学習技術を使用して訓練される係数であり、「Ｔｘ」はアップロードされたデータの量であり、「Ｒｘ」はダウンロードされたデータの量であり、「キャリア」はサービスプロバイダを指し、「ＲＡＴ」は使用される無線技術であり、「ｆ」は使用される無線チャネルであり、「ＭＩＭＯ」はＭＩＭＯモードが有効であるかどうかを示し、「ＣＡ」はキャリアアグリゲーション状態であり、「Ｓ」は信号強度であり、「モビリティ」はデバイスの動きを示し、「位置」はデバイスのサービス提供セルサイトを示す。別の実施形態では、アプリケーション異常検出のための数学的モデルは、収集された入力データのより大きな組、入力データの様々な組み合わせ、または、様々な二次的またはより高レベルの属性もしくは定量的特徴を使用して、異常パラメータを推定するか、または、１または複数のアプリケーションに関する異常条件を検出する、ディープニューラルネットワークまたはベイジアン推定ネットワークなどのより複合的または複雑なマルチ段階モデルまたはマルチレベルモデルであってよい。

この方法の段階１６０６では、計算されたパラメータの値が、異常検出条件／要件に対応する閾値を超えているかどうかを決定する。例えば、値が電力消費のパラメータに対応している場合は、閾値は電力閾値であってよい。別の例では、値がＣＰＵサービス時間長のパラメータに対応している場合は、閾値は時間長閾値であってよい。更に別の例では、値がＩＯアクセスレートのパラメータに対応している場合は、閾値はアクセスレート閾値である。コンピューティングデバイスは、複数の異なる異常検出条件／要件に対応する閾値のリストを、例えば表に維持してよい。異常検出条件／要件に対応して、またはアプリケーションについて定義された閾値がない場合は、方法１６００は、いかなる次の段階にも進むことなく、ここで中断してよい。

方法１６００の段階１６０８では、計算された値が閾値を超えている場合に、アプリケーションに異常が生じていると決定し、それに応答してアクションを起こす。アプリケーションの異常の悪影響が軽減または回避されるように、アクションが起こされてよい。一例では、アプリケーションの実行をフリーズするアクションが起こされる。別の例では、アプリケーションを強制終了するアクションが起こされる。更に別の例では、コンピューティングデバイスのユーザに通知、例えば異常通知が示されてよい。この通知は異常の発生を示してよいことから、ユーザはそれに応答して自らが適切と見なすアクションを起こしてよい。この通知は、計算された値と、異常を決定するために使用される閾値とを示してよい。この通知は、ユーザが異常の発生に応答して選択できるアクションのリストを示してもよい。場合によっては、ユーザは、自らの経験または専門知識に基づいて、異常通知にかかわらずアクションを起こさないことがある。

幾つかの実施形態において、方法１６００では、２またはそれより多くの異なる異常検出要件の組み合わせに基づいてアプリケーションの異常を検出してよい。例えば、方法１６００では、ハードウェアの使用に関連するデータに基づいてバッテリ電力消費の値およびＷｉ－Ｆｉロック保持時間の値を計算し、これらの値の各々を対応する閾値と比較してよい。複数の異なる基準を定義して、異常が検出されているかどうかを決定してよい。例えば、これらの値がどちらも対応する閾値を超えている場合は、方法１６００では、異常が検出されていると決定する。別の例では、これら２つの値のどちらか一方が対応する閾値を超えている場合は、異常が検出されていると決定される。

方法１６００の段階１６１０では、段階１６０６での決定に基づいて閾値を更新してよい。閾値は、例えば、電力消費、オーバーヒート、性能、ユーザエクスペリエンスなどの観点から、アプリケーションの異常の悪影響を受けないように、コンピューティングデバイスをより保守的に保護するよう更新されてよい。例示目的でワッツアップを例に挙げると、ワッツアップにより消費される電力が１０Ｗ（すなわち、ワッツアップによりアクセスされたハードウェアに関連するデータに基づいて、かつ、モデルを使用して計算された値）である一方で閾値が３Ｗである場合は、方法１６００では、ワッツアップが異常に実行されていると決定し、ワッツアップを終了する。ワッツアップの異常の検出を理由として、方法１６００では、次回により早く異常検出ができるよう、閾値を例えば０．５Ｗだけ更に低下させることを決定してよい。別の例では、ワッツアップの異常の検出に応答してユーザがいかなるアクションも起こさない場合は、計算された消費電力、すなわち１０Ｗが、ユーザに固有の新たな閾値として使用されてよく、そこからの電力消費に基づく異常の検出に使用されることになる。閾値が更新されるかどうか、および、閾値が更新される方法を決定する様々な規則が定義されてよい。方法１６００では、異常が検出されるたびに、または、予め決定された回数だけ異常が検出された後に、閾値を更新または調整してよい。方法１６００では、閾値が更新されるべきかどうか、および／または、閾値が更新される方法を決定するよう、コンピューティングデバイスのユーザに要求してもよい。段階１６１０でもたらされる更新された閾値は、コンピューティングデバイスで実行されているアプリケーションに固有で、かつ、異常検出条件に対応する閾値である。

幾つかの実施形態では、閾値または一組の閾値は、サーバ、例えばクラウドサーバからコンピューティングデバイスにより受信されてよい。サーバから受信された閾値は、異常検出要件について全てのアプリケーションまたはアプリケーションのグループに適用可能な共通閾値と呼ばれることがある。コンピューティングデバイスは、同じ共通閾値を使用する異常検出要件に従って、任意のアプリケーション（またはグループ内の任意のアプリケーション）に関する異常検出を実行することができる。コンピューティングデバイスは、一組の異常検出要件に従って、共通閾値のリストをサーバから受信し、維持してよい。コンピューティングデバイスは、更新された共通閾値を受信し、対応する古い共通閾値を更新された共通閾値と置換してもよい。

幾つかの実施形態では、コンピューティングデバイスは、異常検出要件に対応する初期の共通閾値を受信してよく、初期の共通閾値を使用して、例えば、異常検出要件により示されるパラメータの値を初期の共通閾値と比較することによって、アプリケーション異常を決定する。コンピューティングデバイスはその後、初期の共通閾値の更新（第２共通閾値）を受信し、アプリケーション異常検出のために、初期の共通閾値を更新された共通閾値と置換してよい。コンピューティングデバイスが、図１６の段階１６１０に示すように、異常を検出した後に（例えば、第２共通閾値を使用して）閾値更新を実行することにより、第３閾値を生成する場合は、コンピューティングデバイスは、更新された第２共通閾値を第３閾値と置換しない。代わりに、コンピューティングデバイスは、第３閾値を、異常検出要件に対応する、コンピューティングデバイス上のアプリケーションに具体的に適用可能なデバイス固有閾値として記憶してよい。故に、異常検出要件に対応して、コンピューティングデバイスは、２つの閾値、すなわち、共通閾値およびデバイス固有閾値を有してよい。

幾つかの実施形態では、コンピューティングデバイスは、表６に示すように、異なる異常検出要件に対応する一組のユーザ固有閾値および共通閾値のリストを有してよい。表６は、３つの異常検出条件、すなわち、Ｗｉ－Ｆｉロック保持時間、ＧＰＵサービス時間、およびＩＯアクセスレートを示し、これらの条件の各々は、共通閾値およびデバイス固有閾値に対応する。デバイス固有閾値は、例えば、アプリケーションの名前を使用して、アプリケーションと関連付けられてよい。デバイス固有閾値とアプリケーションとの関連付けは、アプリケーションのバージョン情報を含んでもよい。例えば、表６に示すように、ＩＯアクセスレートに対応するデバイス固有閾値は、アプリケーションの名前、すなわち「ワッツアップ」と、ワッツアップのバージョン番号、すなわち「１．０．３」とを含んでもよい。

コンピューティングデバイスが異常検出条件に対応する共通閾値およびデバイス固有閾値の両方を有する場合は、コンピューティングデバイスは、例えば、予め定義された規則または基準に基づいて、これらの閾値のどちらか一方を異常検出に使用することを選択してよい。例えば、共通閾値およびデバイス固有閾値が互いに近い場合は、例えば、これら２つの閾値間の差が差分閾値より小さい場合は、コンピューティングデバイスは、共通閾値およびデバイス固有閾値のうちの一方をランダムに選んでよい。あるいは、これら２つの閾値間の差が差分閾値以上である場合は、デバイス固有閾値が使用されてよい。アプリケーション異常を検出するための共通閾値またはデバイス固有閾値を選択するために、他の基準が定義されてもよい。

段階１６１０で閾値が更新された後、方法１６００では次に、（アプリケーションが強制終了またはフリーズされていない場合は）段階１６０２に戻ってアプリケーションの監視を継続し、アプリケーションの異常を検出してもよいし、（アプリケーションが強制終了またはフリーズされている場合は）他のアプリケーションを監視してもよい。段階１６０６で、計算されたパラメータの値が閾値を超えていない場合は、方法１６００は段階１６０２に戻る。方法１６００ではアプリケーションに対していかなるアクションも起こさず、アプリケーションが実行され続けることになる。

方法１６００は、コンピューティングデバイスで実行可能な別個のアプリケーションとして実装されてよい。方法１６００は、コンピューティングデバイスのバックグラウンドで実行されているデーモンまたはシステムプロセスとして実装されてもよい。これらの場合のどちらか一方において、ある実施形態に係るアプリケーション（またはデーモンプロセス）が起動または有効化されている場合は、当該実施形態に係るアプリケーションはまず、アプリケーションの異常を決定するためのパラメータの値を計算するための１または複数のモデルをロードしてよい。１または複数の共通閾値（および１または複数のデバイス固有閾値）、および１または複数の異常検出要件がロードされてもよい。方法１６００では、コンピューティングデバイスで実行されている単一アプリケーション、アプリケーションのグループ、またはありとあらゆるアプリケーションの異常を検出してよい。

幾つかの実施形態では、コンピューティングデバイスは、複数の異なる異常検出条件に対応する閾値を決定および更新するために、クラウドサーバなどのサーバと相互作用してよい。コンピューティングデバイスは、有線または無線でサーバに接続されてよい。上述のように、コンピューティングデバイスは、クラウドサーバから共通閾値および／または共通閾値の更新を受信してよい。幾つかの実施形態では、コンピューティングデバイスは、コンピューティングデバイスで実行されているアプリケーションによりアクセスされるハードウェアまたはサービスの使用に関連するデータ（図１６との関連で上述したデータなど）をクラウドサーバに送信してよい。コンピューティングデバイスは、取得されたそのようなデータの全てを周期的にクラウドサーバにアップロードしてよい。コンピューティングデバイスは、異常検出条件に対応する共通閾値およびデバイス固有閾値をクラウドサーバに送信してもよい。デバイス固有閾値を送信する場合は、コンピューティングデバイスは、対応するアプリケーションおよび対応するアプリケーションのバージョン情報を識別する情報を送信してもよい。コンピューティングデバイスによりサーバに送信されたデータ／情報は、共通閾値を決定するか、または共通閾値を更新するためにサーバにより使用されてよい。幾つかの実施形態では、サーバは、共通閾値または更新された共通閾値を１または複数のデバイスに送信するように構成されてよい。サーバは共通閾値を周期的に更新し、１または複数のデバイスに送信してよい。サーバは、複数の異なる異常検出条件に対応する１または複数の共通閾値を決定および／または更新するために、１または複数のコンピューティングデバイスからデータ／情報を受信するように構成されてもよい。情報の例には、コンピューティングデバイス上のアプリケーションによりアクセスされるハードウェアまたはサービスの使用に関連するデータ、異常検出条件に対応する共通閾値、異常検出条件に対応するデバイス固有閾値、アプリケーション名、バージョン番号などといったアプリケーションに関する情報が含まれる。

幾つかの実施形態では、サーバまたはリモート制御デバイスは、複数のデバイスから上述の情報を受信してよく、受信された情報に基づいて、異常検出条件に対応する共通閾値（または更新された共通閾値）を決定する。図１７は、ある実施形態に係る、異常検出条件に対応する共通閾値を決定するための方法１７００のフローチャートを示す。方法１７００は、クラウドサーバなどのサーバ、またはサポートデバイスにより実行されてよい。図示の通り、段階１７０２では、サーバは、複数のコンピューティングデバイスで実行されている１または複数のアプリケーションに関連する、複数のコンピューティングデバイスにより伝送された情報を記憶デバイスから取り込む。図１６との関連で上述した情報は、それぞれのコンピューティングデバイス上のそれぞれのアプリケーションによりアクセスされるハードウェア、サービス、または他のリソースの使用に関連するデータを含んでよい。データは、ＣＰＵのフォアグラウンド使用、ＣＰＵのバックグラウンド使用、ウェイクロック保持時間、自己起動の数、アプリケーションのオンスクリーン時間、セルラの使用およびパターン、Ｗｉ－Ｆｉの使用およびパターン、メモリ使用、ＩＯデバイスへのアクセス回数、または位置サービス使用、ＧＰＵ使用、到着通知の数、オーディオサービスの使用、またはユーザデータへのアクセス数、またはこれらの任意の組み合わせを含んでよい。情報は、アプリケーションの名前または識別子などのアプリケーションデータと、アプリケーションのバージョン情報とを含んでもよい。情報は、異常検出条件に対応する、コンピューティングデバイスにより使用される共通閾値および／またはデバイス固有閾値を更に含んでよい。情報は、エンドユーザライセンス契約書（ＥＵＬＡ）で指定された一定時間にわたってクラウドストレージに記憶されてよい。方法１７００では、クラウドストレージから最新アップロード情報を周期的に取り込み、必要な特徴を抽出し、分析を実行し、共通閾値または共通閾値のリストをコンパイルしてよい。

方法１７００の段階１７０４では、取り込まれた情報に基づいて、異常検出条件に対応する共通閾値を生成する。方法１７００では、取り込まれた情報に基づいて、複数の異なる異常検出条件に対応する共通閾値を生成してよい。幾つかの実施形態において、方法１７００では、情報の全てまたは一部をクラウド側学習モジュールに入力してよく、クラウド側学習モジュールは、異常検出条件に対応する共通閾値を出力する。クラウド側学習モジュールは、入力情報を使用して学習ネットワークを訓練するように構成される機械学習モジュールであってよい。例えば、クラウド側学習モジュールは、以下に限定されるわけではないが、ベイジアン推定モデル、回帰モデル、畳み込みニューラルネットワーク（ＣＮＮ）、または決定木の集合体などであってよい。学習ネットワークの例には、多層ニューラルネットワークまたは回帰学習ネットワークが含まれてよい。クラウド側学習モジュールは、任意の機械学習機構を使用して、コンピューティングデバイスから受信された情報に基づいて共通閾値を取得してよい。

方法１７００の段階１７０６では、生成された共通閾値を検証する。例えば、分野の専門家は、例えば、システムログまたはアプリケーションログを使用して、生成された共通閾値を検査するか、または、その正確性をチェックすることができる。共通閾値は、専門家の入力に基づいて変更されてもよい。方法１７００の段階１７０８では、生成された共通閾値をコンピューティングデバイスに伝送する。生成された共通閾値は、コンピューティングデバイスが異常検出条件に従ってアプリケーションの異常を決定するために使用する初期の共通閾値であってよい。生成された共通閾値は、コンピューティングデバイスにとって更新された共通閾値であってもよい。この場合は、コンピューティングデバイスは、共通閾値をこの更新された共通閾値と置換する。方法１７００では、生成された共通閾値を無線（ＯＴＡ）のプッシュまたは転送により伝送してよい。方法１７００では、生成された共通閾値をソフトウェア更新によってコンピューティングデバイスに伝送してもよい。この場合は、生成された共通閾値は、ソフトウェアを更新する場合にシステムソフトウェアに付属しているか、またはアプリケーションストアからダウンロードされてよい。

実施形態に係る方法では、コンピューティングデバイスは、１または複数の異常検出条件に従って、かつ、アプリケーションの実行に関連する収集されたデータと、クラウドサーバにより提供される１または複数の共通閾値とを利用して、アプリケーションの実行中にアプリケーション異常を検出してよく、クラウドサーバは、アプリケーションの実行に関連するコンピューティングデバイスおよび／または他のコンピューティングデバイスにより提供されるデータに基づいて、１または複数の共通閾値を決定する。コンピューティングデバイスおよびクラウドサーバの両方が（コンピューティングデバイスおよび／または他のコンピューティングデバイスにより提供されるデータに基づく、クラウド側の）１または複数の共通閾値を周期的に更新し、（異常の検出に基づく、デバイス側の）１または複数のデバイス固有閾値を生成してよい。このように、コンピューティングデバイスおよびクラウドサーバは、リアルタイムでアプリケーション異常の検出を共同的に実装し、結果的に、コンピューティングデバイスの性能、ひいてはユーザエクスペリエンスを改善する。

図１８は、ある実施形態に係るアプリケーション異常検出の方法１８００のフローチャートを示している。方法１８００は、コンピュータで実装される方法であってよい。方法１８００は、コンピューティングデバイスでの動作を示している。図示の通り、方法１８００の段階１８０２では、コンピューティングデバイスで実行されているアプリケーションによる１または複数のハードウェアの使用に関するデータを取得し、アプリケーションは、コンピューティングデバイスにおけるアプリケーションの実行中にコンピューティングデバイスの１または複数のハードウェアにアクセスする。方法１８００では、アプリケーションによりアクセスされる、サービスなどの１または複数の他のリソースの使用に関するデータを取得し、当該データを使用してアプリケーションのアノマリを検出してよい。方法１８００の段階１８０４では、異常検出要件に従って、当該データに基づいて、アプリケーションが異常に実行されているかどうかを検出する。異常検出要件は、アプリケーションの異常を決定するために使用されるパラメータを示す。アプリケーションが異常に実行されているかどうかの検出は、データに基づいて計算されるパラメータの値を、異常検出要件に対応する閾値と比較することにより実行される。方法１８００の段階１８０６では、アプリケーションが異常に実行されていることを決定したことに応答して、アプリケーションの実行時にアクションを起こす。

幾つかの実施形態では、１または複数のハードウェアの使用に関するデータは、ＣＰＵのフォアグラウンド使用、ＣＰＵのバックグラウンド使用、ウェイクロック保持時間、自己起動の数、アプリケーションのオンスクリーン時間、セルラの使用およびパターン、Ｗｉ－Ｆｉの使用およびパターン、メモリ使用、ＩＯデバイス使用、例えばＩＯデバイスのアクセス回数、または位置サービス使用、例えば使用される位置サービスの数を含む。

幾つかの実施形態では、１または複数のハードウェアの使用に関するデータは、グラフィック処理装置（ＧＰＵ）の使用、到着通知の数、アプリケーションのバージョン情報、オーディオサービスの使用、またはユーザデータのアクセス数を更に含んでよい。

幾つかの実施形態では、パラメータは、アプリケーションにより占有されるメモリスペース、ＩＯデバイスのアクセスレート、ウェイクロック保持時間、Ｗｉ－Ｆｉロック保持時間、ＧＰＵサービス時間、ＣＰＵサービス時間、またはＣＰＵバックグラウンド実行時間を含む。

幾つかの実施形態では、アプリケーションの実行時にアクションを起こす段階は、アプリケーションの実行をフリーズする段階、またはアプリケーションを強制終了する段階を含む。

幾つかの実施形態では、アプリケーションの実行時にアクションを起こす段階は、アプリケーションが異常に実行されていることを通知する通知を生成する段階を含む。

幾つかの実施形態において、方法１８００では、一定期間にわたってアプリケーションの実行中に１または複数のハードウェアの使用を監視してよい。

幾つかの実施形態において、方法１８００では、取得されたデータをアプリケーションと関連付けてよい。

幾つかの実施形態において、方法１８００では、予め確立されたモデルを使用してパラメータの値を計算してよい。

幾つかの実施形態において、方法１８００では、パラメータ値が閾値を超えている場合にアプリケーションに異常が生じていると決定してよい。

幾つかの実施形態において、方法１８００では、クラウドサーバから閾値を受信してよい。幾つかの実施形態では、受信された閾値は、複数の異なるアプリケーションに適用可能な共通閾値である。

幾つかの実施形態において、方法１８００では、アプリケーションが異常に実行されていると決定した後に閾値を更新してよい。

幾つかの実施形態では、更新された閾値は、異常検出要件に対応する、コンピューティングデバイスで実行されているアプリケーションに具体的に適用可能なデバイス固有閾値である。

幾つかの実施形態において、方法１８００では、使用および閾値に関するデータをクラウドサーバに伝送してよい。

幾つかの実施形態において、方法１８００では、更新された閾値をクラウドサーバに伝送してよい。幾つかの実施形態では、使用および閾値に関するデータをクラウドサーバに伝送する段階が周期的に実行される。

幾つかの実施形態では、アプリケーションが異常に実行されているかどうかを検出する段階が、周期的にまたは要求に応じて実行される。

幾つかの実施形態において、方法１８００では、更新された閾値をクラウドサーバから受信し、当該閾値を更新された閾値と置換してよい。

本開示の複数の実施形態は、コンピュータで実装される方法として実装されてよい。これらの実施形態は、処理システムにより実行されてよい。本開示における実施形態に係る方法は、非一時的コンピュータ可読媒体に記憶され、かつ、１または複数のプロセッサにより実行可能である、コンピュータ命令として実装されてよい。コンピュータ可読非一時的媒体は、磁気記憶媒体、光記憶媒体、フラッシュ媒体、およびソリッドステート記憶媒体を含む、全てのタイプのコンピュータ可読媒体を含む。異常検出モデルおよび関連ソフトウェアは、コンピューティングデバイスに予めインストールされ得ることを理解されたい。代替的に、ソフトウェアを取得し、コンピューティングデバイスにロードすることができる。これには、物理媒体または配布システムを介して、例えば、ソフトウェア作成者により所有されるサーバから、または、ソフトウェア作成者により所有はされないが使用されるサーバから、ソフトウェアを取得することが含まれる。ソフトウェアは、例えば、インターネットを介して配布するためにサーバに記憶され得る。

図１９は、ある実施形態に係る、本明細書で説明する方法を実行するための処理システム１９００のブロックダイアグラムを示している。処理システム１９００は、ホストデバイスにインストールされてよい。図示の通り、処理システム１９００は、プロセッサ１９０４と、メモリ１９０６と、インタフェース１９１０から１９１４とを含む。これらは、図１９に示すように配置されて（もされなくても）よい。プロセッサ１９０４は、計算および／または他の処理関連タスクを実行するように適合させられる任意のコンポーネントまたはコンポーネントの集合であってよく、メモリ１９０６は、プロセッサ１９０４による実行のためのプログラミングおよび／または命令を記憶するように適合させられる任意のコンポーネントまたはコンポーネントの集合であってよい。ある実施形態では、メモリ１９０６は、非一時的コンピュータ可読媒体を含む。インタフェース１９１０、１９１２、１９１４は、処理システム１９００が他のデバイス／コンポーネントおよび／またはユーザと通信することを可能にする任意のコンポーネントまたはコンポーネントの集合であってよい。例えば、インタフェース１９１０、１９１２、１９１４のうちの１または複数が、プロセッサ１９０４からホストデバイスおよび／またはリモートデバイスにインストールされたアプリケーションに、データ、制御メッセージ、または管理メッセージを伝達するように適合されてよい。別の例として、インタフェース１９１０、１９１２、１９１４のうちの１または複数が、ユーザまたはユーザデバイス（例えば、パーソナルコンピュータ（ＰＣ）など）が処理システム１９００と相互作用／通信することを可能にするように適合されてよい。処理システム１９００は、長期間記憶装置（例えば、不揮発性メモリなど）など、図１９には示していない更なるコンポーネントを含んでよい。

幾つかの実施形態では、処理システム１９００は、遠隔通信ネットワークにアクセスしているか、またはさもなければ遠隔通信ネットワークの一部であるネットワークデバイスに含まれる。一例では、処理システム１９００は、無線または有線の遠隔通信ネットワークにおけるネットワーク側デバイス、例えば、基地局、中継局、スケジューラ、コントローラ、ゲートウェイ、ルータ、アプリケーションサーバ、または遠隔通信ネットワークにおける任意の他のデバイスにある。他の実施形態では、処理システム１９００は、無線または有線の遠隔通信ネットワーク、例えば、移動局、ユーザ機器（ＵＥ）、パーソナルコンピュータ（ＰＣ）、タブレット、ウェアラブル通信デバイス（例えば、スマートウォッチなど）、または、遠隔通信ネットワークにアクセスするように適合させられる任意の他のデバイスにアクセスしているユーザ側デバイスにある。

幾つかの実施形態では、インタフェース１９１０、１９１２、１９１４のうちの１または複数が、遠隔通信ネットワークを介してシグナリングを伝送および受信するように適合させられる送受信機に処理システム１９００を接続する。図２０は、遠隔通信ネットワークを介してシグナリングを伝送および受信するように適合させられる送受信機２０００のブロックダイアグラムを示している。送受信機２０００は、ホストデバイスにインストールされてよい。図示の通り、送受信機２０００は、ネットワーク側インタフェース２００２と、カプラ２００４と、伝送機２００６と、受信機２００８と、信号プロセッサ２０１０と、デバイス側インタフェース２０１２とを含む。ネットワーク側インタフェース２００２は、無線または有線の遠隔通信ネットワークを介してシグナリングを伝送または受信するように適合させられる任意のコンポーネントまたはコンポーネントの集合を含んでよい。カプラ２００４は、ネットワーク側インタフェース２００２を介して双方向通信を容易にするように適合させられる任意のコンポーネントまたはコンポーネントの集合を含んでよい。伝送機２００６は、ベースバンド信号を、ネットワーク側インタフェース２００２を介した伝送に最適な変調キャリア信号に変換するように適合させられる任意のコンポーネントまたはコンポーネントの集合（例えば、アップコンバータ、電力増幅器など）を含んでよい。受信機２００８は、ネットワーク側インタフェース２００２を介して受信されたキャリア信号をベースバンド信号に変換するように適合させられる任意のコンポーネントまたはコンポーネントの集合（例えば、ダウンコンバータ、低ノイズ増幅器など）を含んでよい。信号プロセッサ２０１０は、ベースバンド信号を、デバイス側インタフェース２０１２を介した通信に最適なデータ信号に変換するか、または逆変換するように適合させられる任意のコンポーネントまたはコンポーネントの集合を含んでよい。デバイス側インタフェース２０１２は、信号プロセッサ２０１０とホストデバイス内のコンポーネント（例えば、処理システム１９００、ローカルエリアネットワーク（ＬＡＮ）ポートなど）との間でデータ信号を伝達するように適合させられる任意のコンポーネントまたはコンポーネントの集合を含んでよい。

送受信機２０００は、任意のタイプの通信媒体を介してシグナリングを伝送および受信してよい。幾つかの実施形態では、送受信機２０００は、無線媒体を介してシグナリングを伝送および受信する。例えば、送受信機２０００は、セルラプロトコル（例えば、ロングタームエボリューション（ＬＴＥ）など）、無線ローカルエリアネットワーク（ＷＬＡＮ）プロトコル（例えば、Ｗｉ－Ｆｉなど）、または任意の他のタイプの無線プロトコル（例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）、近距離無線通信（ＮＦＣ）など）などの無線遠隔通信プロトコルに従って通信するように適合させられる無線送受信機であってよい。そのような実施形態では、ネットワーク側インタフェース２００２は、１または複数のアンテナ／放射要素を含む。例えば、ネットワーク側インタフェース２００２は、単一のアンテナ、複数の別個のアンテナ、または多層通信、例えば、単入力多出力（ＳＩＭＯ）、多入力単出力（ＭＩＳＯ）、多入力多出力（ＭＩＭＯ）などのために構成されるマルチアンテナアレイを含んでよい。他の実施形態では、送受信機２０００は、有線媒体、例えば、ツイストペアケーブル、同軸ケーブル、光ファイバなどを介してシグナリングを伝送および受信する。特定の処理システムおよび／または送受信機が、示されているコンポーネントの全て、または当該コンポーネントのサブセットのみを利用してよく、統合レベルがデバイスごとに異なっていてよい。

本明細書で提供する実施形態に係る方法の１または複数の段階が、対応するユニットまたはモジュールにより実行され得ることを理解されたい。例えば、伝送ユニットまたは伝送モジュールにより信号が伝送されてよい。受信ユニットまたは受信モジュールにより信号が受信されてよい。処理装置または処理モジュールにより信号が処理されてよい。データを取得し異常検出モジュールを取得するための取得ユニット／モジュール、アプリケーションまたはプロセスの異常を決定するための決定ユニット／モジュール、アプリケーションと関連付けられるデータに異常レベルを割り当てるための割り当てユニット／モジュール、計算ユニット／モジュール、アクション実行ユニット／モジュール、ダウンロードユニット／モジュール、アップロードユニット／モジュール、異常類別ユニット／モジュール、データ分析ユニット／モジュール、異常検出ユニット／モジュール、カスタマイズユニット／モジュール、データ取り込みユニット／モジュール、データ収集ユニット／モジュール、確率推定ユニット／モジュール、機械学習ユニット／モジュール、検出結果統合ユニット／モジュール、識別ユニット／モジュール、訓練ユニット／モジュール、通知ユニット／モジュール、プッシュユニット／モジュール、モデル構築ユニット／モジュール、監視ユニット／モジュール、更新ユニット／モジュール、および／または検出ユニット／モジュールにより他の段階が実行されてよい。それぞれのユニット／モジュールは、ハードウェア、ソフトウェア、またはこれらの組み合わせであってよい。例えばユニット／モジュールのうちの１または複数が、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）または特定用途向け集積回路（ＡＳＩＣ）などの集積回路であってよい。

本開示は例示的な実施形態を参照して説明されているが、この説明は限定的な意味に解釈されることを意図するものではない。この説明を参照すれば、様々な修正形態および例示的な実施形態の組み合わせ、並びに本開示の他の実施形態が当業者にとって明らかになるであろう。従って、添付の特許請求の範囲はそのようなあらゆる修正形態または実施形態を包含することが意図されている。

Claims (33)

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. 前記アプリケーションに関する前記リソース使用データは、請求項２から８のいずれか一項に記載のリソース使用データを含む、請求項２５または２６に記載のコンピュータで実装される方法。
28. 前記異常検出結果は、複数の異常レベルのうちの１つの異常レベルを含む、請求項２５から２７のいずれか一項に記載のコンピュータで実装される方法。
29. 前記複数の異常レベルは、異常なし、異常、高度の異常、または過度の異常を含む、請求項２８に記載のコンピュータで実装される方法。
30. 前記複数の異常レベルは、多い使用または過度の使用を含む１または複数のレベルの使用を含む、請求項２８または２９に記載のコンピュータで実装される方法。
31. 前記アプリケーションの前記実行時に起こされる前記アクションは、請求項１６または１７に記載のアクションを含む、請求項２５から３０のいずれか一項に記載のコンピュータで実装される方法。
32. 命令を有する非一時的メモリストレージと、
    前記非一時的メモリストレージと通信している１または複数のプロセッサと
    を備える装置であって、
    前記１または複数のプロセッサは、前記命令を実行して請求項１から３１のいずれか一項に記載の方法を実行する、
    装置。
33. １または複数のプロセッサに、請求項１から３１のいずれか一項に記載の方法を実行させるためのプログラム。

Images