Mobile device application monitoring software

• US 20150133076A1
• Filed: 11/12/2013
• Published: 05/14/2015
• Est. Priority Date: 11/11/2012
• Status: Abandoned Application

• Current Assignee: Michael Brough
• Original Assignee: Michael Brough
• Inventors: Brough, Michael
• Application Number:
  US14/078,518
• Publication Number:
  US 20150133076A1
• Time in Patent Office: Days
• US Class Current: 455/405
• CPC Class Codes: G06F 11/302 where the computing system component is a software system
• CPC Class Codes: G06F 11/3438 monitoring of user actions tracking the activity of the user H04L67/535
• CPC Class Codes: H04L 43/16 Threshold monitoring
• CPC Class Codes: H04W 24/10 Scheduling measurement reports ; Arrangements for measurement reports
• CPC Class Codes: H04W 4/60 Subscription-based services using application servers or record carriers, e.g. SIM application toolkits

Abstract

A software application for monitoring the performance of other software applications on mobile devices using efficient crowd sourced data and efficient proxies for performance of the applications.

Claims

1. A method for identifying mobile device app parameters that negatively impact system efficiency and/or security, said system comprises comprising obtaining statistical data of app performance of a large number of apps, said statistical data being used for establishing a performance metric for each app parameter, said app parameters being measured during use of said mobile device and providing an alert to a user when a parameter exceeds crowd source derived limits for the metric.

2. A method as in claim 1 wherein the parameters for which a metric is established comprise one or more of:

battery usage, data usage, memory usage, CPU usage, storage space usage, permissions incidence, crash incidence, notification incidence, and analytics.

3. A method as in claim 1 to supply crowd source information to said mobile device where application averages and limits are transmitted to said device.

4. A method as in claim 1 wherein comparative values for battery usage, data consumption, cpu, memory and storage are transmitted back to said device, comparing against all other devices, devices with the same operating system version, devices of the same model and devices on the same carrier network

5. A method as in claim 1 wherein crowd-source based application recommendations and information reports will be fed back into the application.

6. A method as in claim 1 wherein a back-end database will analyze application information supplied from all users and will determine if an extreme application alert notification should be sent to a device type, carrier group or operating system, and when such a notification is deemed appropriate M2AppMonitor will collect the notification request and display the alert to the device user.

7. A method as in claim 1 providing an indication of the performance of each of a plurality of installed apps on a mobile phone comprising aggregating metrics data for performance and/or quality of each of a plurality of apps and after collecting data on all of these parameters, M2AppMonitor compares the application'"'"'s data to crowd-sourced data and those apps with usage above the 95th percentile are flagged for high resource usage.

8. A method as in claim 1 comprising assessing said data for determining a crowd-source performance threshold for each app and providing a notification icon in the notification tray as a visual indicator that an app is performing above the threshold.

9. A method as in claim 1 wherein scoring of the parameters and flagging resource overages of apps is made by summation and is an objective measurement of the parameters in their own units.

10. A method as in claim 1 wherein scoring of the parameters and flagging of apps is made by comparison to the 5th to the 99th percentile of performance of similar apps in the same performance category.

11. A method as in claim 1 wherein scoring of the parameters and flagging of apps is made by comparison to a threshold performance of similar apps in the same performance category where the threshold is set by the user.

12. A method as in claim 1 comprising a pathway for a user to force stop a flagged app.

13. A method as in claim 1 comprising a pathway for a user to uninstall a flagged app.

14. A method as in claim 1 comprising providing alert data to a system carrier.

15. A method as in claim 1 wherein said carrier comprises software responsive to alert data from user.

16. A method as in claim 1 wherein said carrier is responsive to the receipt of data representative of said scoring for identifying unintended app operation.

17. A method as in claim 1 comprising continually monitoring said plurality of apps while said mobile device is turned on.

18. A method as in claim 1 comprising providing a notification icon in the device notification tray as a visual indicator that an app is performing below the threshold

19. A method as in claim 1 for controlling unwanted mobile device app operations comprising an internet carrier and a plurality of mobile devices, each of said devices being configured to operate controllably in communication with said carrier, each of said devices having installed therein a plurality of apps, each of said apps being characterized by operator selected operation features and “

unintended”

operation that negatively impacts system efficiency and security, said system comprising mobile devices each adapted to include app monitoring software for scoring of one or more of key metrics.

20. A method of identifying mobile device app parameters that negatively impact system efficiency and/or security comprising:

starting a timer that raises a flag at ten minutes and which then restarts;

creating a table in memory to store information on currently running apps;

pulling the data collected in the table every ten minutes;

summing the pulled data, summing said data for each app in an active application table, computing a latest application average CPU usage with new data, computing a latest application average memory usage with new data, computing a latest application average battery use with new data, computing a latest application average data usage with new data, computing a number of times an app has crashed during a given monitoring cycle, computing a current application storage usage, computing a permission, a security and a resource overage, updating the application table with all newly computed data, updating a notification status to match resource flags to be displayed in the app and a status bar;

logging current app readings, writing an entry of the app readings for each app, pushing the current app readings to the log table;

checking the data to determine whether it is necessary for the M2AppMonitor to take any outward actions, checking the database size, averaging data and trimming the database, trimming the database in the event it is too large, checking for four different extreme notifications, checking whether storage exceeds threshold, checking whether battery exceeds threshold, checking whether data use exceeds threshold, checking whether data use exceeds a plan limit, sending notification when there are flagged apps, sending notification when an extreme notification condition is satisfied, checking if it is time to submit data to a master database, when it is time submitting a summary of application data to M2AppMonitor master database;

clearing the table in preparation for the next cycle;

starting a fifteen second cycle where a flag is raised at the 15 second mark, indicating the start of running application data collection;

getting a list of running applications, adding each app to the main app table if it is not yet in the table, tracking the start time of newly added apps, tracking the stop time in the event an app has stopped running, start a tracking time for an app that is a “

front”

app, stop tracking time for an app that is no longer a “

front”

app;

getting memory information, obtaining app memory usage, averaging collected memory data with previous data, pushing the average value to a running application table;

getting CPU information, obtaining CPU information for all processes used by an application, combining the collected CPU data per application, averaging collected CPU data with the previous data, averaging foreground usage with past foreground usage, averaging background usage with past background usage, pushing the average value to a running application table;

getting data usage, starting to collect data readings if data usage has not been collected for the app, adding to a tally of data usage collected for the app, tallying background data usage, tallying Wi-Fi data usage, tallying mobile data usage;

combining data, averaging all of the collected data, organizing and combining all collected data, averaging background data, combining background data, averaging Wi-Fi data, combine Wi-Fi data, averaging mobile data, combining mobile data

getting battery usage, obtaining battery usage for each app, averaging collected battery data with previous data, pushing battery data to the table, updating the table with the latest collected data, wait for the fifteen second cycle to complete before restarting;

transmitting collected data to a back-end server, collecting device information, collecting app information from a database, collecting app log record from database, combing data in a JSON object, compressing said object, transmitting data to backend server, receiving application category information, update database with app categories, sending JSON data and device information to back end server, receiving crowd source data, updating the local database with crowd source data;

adding new apps to M2AppMonitor when M2AppMonitor is initially installed, adding new apps to M2AppMonitor when new apps are installed, adding new apps to M2AppMonitor when an existing app is updated, collecting storage usage, collecting permissions, collecting notification access, collecting analytics used, updating count incrementally.