Mobile device application monitoring software

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.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

claiming priority to U.S. provisional application No. 61/724,993 dated Nov. 11, 2012 entitled “M2AppMonitor—A Mobile Application Monitoring System enabling device users, IT Managers or Wireless Carriers to monitor Performance, Quality, Access Rights and Usage of Apps” and claiming priority to U.S. provisional application No. 61/816,183 dated Apr. 26, 2013 entitled “A Mobile Device application software monitoring and quick alert system” the contents of which are hereby incorporated by reference.

BACKGROUND

The present invention relates to mobile phone applications and methods of use thereof. In particular, the invention relates to a software system for monitoring and reporting upon the performance of mobile phone applications. The most novel element of this invention is the crowd-source dynamic feedback mechanism which pushes all of the app quality and performance data to the cloud based servers for analysis and then pushes aggregated crowd-source statistics, Flagged app alerts and recommendations down to the consumer based on their specific applications, operating system version, device and wireless carrier network they are on.

A significant fraction of mobile phone applications (hereinafter referred to as “apps”) are not efficient, optimized, or safe for mobile device performance and for the quality of a consumer's user experience. A leading cause of this problem is that a vast majority of apps in the iPhone and Android markets are designed and coded by hobbyists or other programming amateurs who do not employ sufficient quality controls. To further the problem in the Android market there are over 10,000 different device types on over 300 carrier networks, each of which performs differently. The largest Android app market, the Google Play Store, is growing at an enormous rate of approximately 1000 new apps added into the market every day. The market for iPhone apps is experiencing similar growth. The vast majority of app developers do not have the capability to properly test their apps to work on all of the different devices and carrier networks.

Flagged apps are those that are poorly designed, poorly optimized, poorly quality tested, and/or unsafe, cause consumer frustration and result in device returns for Wireless Carriers and Device OEMs. The problem of flagged apps concerns performance and quality. Additional examples of flagged apps would be malware or viruses infecting apps. Sophisticated mobile phone users deal with flagged apps by downloading 10 or more app performance and quality monitoring tools. These existing app monitoring tools enable sophisticated users to track their applications across essential performance and quality metrics. M2AppMonitor is designed to provide a complete solution, eliminating the need for users to download and install multiple applications. More importantly, the M2AppMonitor data that is gathered, is pushed to the cloud on a timed basis, integrated with data from other M2AppMonitor users and then crowd-sourced statistics, app recommendations and flagged app alerts are pushed to the consumers based on their applications, operating system version, device type and carrier network.

SUMMARY OF THE INVENTION

The invention provides a mobile device application software monitoring and quick-alert system that measures quality and performance of applications across a wide range of metrics and enables users to flag and then force-stop or uninstall poorly performing apps.

Additionally, the M2AppMonitor enables the average consumer to monitor the 10 key app performance and quality metrics in one application. The invention makes this possible by first collecting data on all 10 performance parameters and then alerting the user if there are resource overages or abnormal results on those 10 criteria. The M2AppMonitor app on the device sends the app quality and performance data gathered on the device to the M2AppMonitor Cloud Based Servers for analysis. In the cloud, the data is compared and apps are sorted by app type in to categories such as games, utilities or multi-media apps. Then norms are created for each monitoring criteria for each app category. Then, the app's performance data is compared to the criteria norms for the app's respective app category. If the app's resource usage greatly exceeds the category's norm, the M2AppMonitor user will be alerted of the app's high resource usage. Further, the software can have the feature of segmenting this data by device type, operating system version, and carrier network. This is critical because apps run differently on powerful devices and carrier networks versus devices which have low memory, cpu, storage or bandwidth availability. The M2AppMonitor database pushes the norms and alert levels down to the M2AppMonitor users and provides alerts and app recommendations for the various categories of apps based on the crowd-source metrics gathered. Based on the crowd-source metrics gathered, M2AppMonitor would then send alerts to M2AppMonitor users on apps that may run inefficiently on the user's device. Also based on the crowd-source metrics gathered, M2AppMonitor would send recommendations to M2AppMonitor users on apps that run efficiently on the user's device. This is greatly beneficial to the user because M2AppMonitor will receive alerts that are tailored to their specific device. In the event the invention determines an app is functioning poorly it alerts users to these problems as they are happening on the device using a simple notification screen. The invention further gives users a pathway to either force-stop or uninstall flagged apps.

The overall sequence of operation of the app is First the app identifies each and every app installed on the device. Second the app reads the application resource usage for each app on the following list of parameters: battery usage wherein flagged apps require disproportionately more battery drain; wireless data usage wherein flagged apps require disproportionately greater bandwidth; memory usage wherein a flagged app will use a disproportionately large amount of device memory; CPU usage wherein a flagged app will use disproportionately more CPU time; storage usage wherein flagged apps use disproportionately more device storage; permissions wherein flagged apps require an unreasonably high number of permissions as well as relatively more invasive permissions; crashes wherein flagged apps crash more often; notification wherein flagged apps send unimportant or excessive notifications to the user; analytics wherein flagged apps have a disproportionately high number of analytic agents installed; and updates wherein flagged apps update frequently for non-essential matters. Third, after collecting data on all of these parameters, M2AppMonitor compares the application's data to crowd-sourced data. Applications with usage above the 95th percentile are flagged for high resource usage. Multiple methods and statistical tools could be used to compare usage data between apps within given usage categories. For example in a preferred embodiment the 95th percentile is used as a cutoff point to determine which apps should be flagged in a given category. When the app in question exceeds the 95th percentile threshold in usage terms then it will be flagged. In yet a further embodiment, users will have an option to adjust the threshold for each monitored parameter after which the app will be flagged. Finally, the scoring information is output to the M2AppMonitor where the user can view and assess the performance of apps installed on the user's device.

Additionally, the M2AppMonitor is a single interface that allows users to see how their installed apps are affecting their device's health and performance. From the M2AppMonitor, the user can not only either force-stop or uninstall flagged apps but may also filter the display of apps by any of the 10 performance metrics. The M2AppMonitor will continuously monitor applications running on a user's device in the background, even while the user is using other apps or functions on the mobile device.

In view of the shortcomings of the prior art, it is the object of this invention to provide a mobile device application software monitoring and quick-alert system that measures quality and performance of applications across a wide range of metrics. Further objects and advantages of the invention will become apparent to those skilled in the art upon reading and consideration of the following description of a preferred embodiment and the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a flow diagram showing the two timed operations that are employed for populating the table and assessing application performance.

FIG. 2 is a flow diagram of the method for summation.

FIG. 3 is a flow diagram of the method for Application Summation.

FIG. 4 is a flow diagram of the Logging of Application Readings.

FIG. 5 is a flow diagram of the method for Performing Checks.

FIG. 6 is a flow diagram of the method for Get and Combine Data.

FIG. 7 is a flow diagram of the method for Get Running Applications.

FIG. 8 is a flow diagram of the method for Get Memory Information.

FIG. 9 is a flow diagram of the method for Get CPU Information.

FIG. 10 is a flow diagram of the method for Get Data Usage.

FIG. 11 is a flow diagram of the method for Combine Data.

FIG. 12 is a flow diagram of the method for Get Battery Usage.

FIG. 13 is a flow diagram of the M2AppMonitor App Data Transmission.

FIG. 14 is a flow diagram of the M2AppMonitor initial data collection for newly installed apps or upgraded apps.

DETAILED DESCRIPTION OF THE EMBODIMENTS

Referring now to the drawings wherein the showings are for purposes of illustrating a preferred embodiment of the present invention and not for purposes of limiting the same, FIGS. 1-12 show the method of collecting data on, and assessing each application. FIG. 1 is a flow diagram showing the two timed operations that are employed for populating the table and assessing application performance. The process begins by initiating a ten minute cycle, followed by the creation of an application table in memory for storing the data. After the application table is created and the ten minute clock is initiated, a fifteen-second cycle runs forty times repeatedly. Upon initiation of each 15 second cycle. Step 1 is to start a timer that will raise a flag at the 10 minute mark. This timer restarts approximately every ten minutes after the data table is cleared. Step 2 is to create a table in memory to store information on currently running applications. Step 3 is to pull the data collected in the table every ten minutes. Step 4 is Summation, which is a series of processes that run computations on the collected data.

Step 4.1 is Application Summation which is a series of processes that run computations on the collected data. Step 4.1.1 is to repeat the Application Summation for every app in the active application table. Step 4.1.2 is to compute the application latest average CPU usage with new data. Step 4.1.3 is to compute the application latest average memory usage with new data. Step 4.1.4 is to compute the latest application average battery use with new data. Step 4.1.5 comprises computing the application average as to data usage. Step 4.1.6 comprises summing the number of times an app has crashed during this monitoring cycle. Step 4.1.7 is to determine current application storage. Step 4.1.8 is to determine permission, security, and resource overages. Step 4.1.9 is to update the application table with all the newly computed data. Step 4.1.10 is to update notification status to match the new resource flags to be displayed in the app and status bar.

Step 4.2 is to log the current application readings. Step 4.2.1 is to write an entry for each application and then push the app data to the log table.

Step 5 is Perform Checks, which comprises a series of processes that analyze the collected data to determine whether it is necessary for M2AppMonitor to take any outward action. Step 5.1 is to check the database size. Step 5.2 is to Perform data averaging and then trimming the database. Step 5.3 is to Perform database trimming in the event it is too large. Next, check for four different Extreme Notifications: does storage exceed threshold, does battery exceed threshold, does data use exceed threshold, does data use exceed plan limit. Step 5.4 is to Send Notification when there are flagged apps or Extreme Notifications to report. Step 5.5 is to check if it is time to submit data to the master database. If it is time, the app will submit summary of application data to M2AppMonitor master database.

Step 6 is to clear the table in preparation for the next cycle. Step 7 is to start a 15 second cycle where a flag is raised at the 15 second mark, indicating the start of running application data collection.

Step 8 is to Get and Combine the data, comprising a series of processes that collect and organize data about the applications.

Step 8.1 is to Get Running Applications, comprising a series of steps that obtains information about the running applications. Step 8.1.1 is to Get a list of running applications. Step 8.1.2 is to Add each app to the main app table if it is not yet in the table. Step 8.1.3 is to Track the start time of the newly added app. Step 8.1.4 is to Track stop time, where in the event an app has stopped running its stop time is tracked. Step 8.1.5 is Start tracking time for an app that is a “front” app. Step 8.1.6 is Stop tracking time if an app is no longer a “front” app.

Step 8.2 is to Get memory information, comprising a series of processes that obtain data about memory usage. Step 8.2.1 is to Collect memory for application comprising obtaining app memory usage. Step 8.2.2 is Average with last reading comprising averaging collected memory data with previous data. Step 8.2.3 is Enter in running application table, comprising pushing memory data to the table.

8.3 is to get CPU information comprising a series of processes that obtain data about CPU usage. Step 8.3.1 is to collect CPU information for processes. Step 8.3.2 is to Combine CPU for all processes per application comprising organizing CPU data per application. Step 8.3.3 is Average CPU reading with last readings comprising averaging collected CPU data with previous data. Step 8.3.4 is to average foreground usage with past foreground usage. Step 8.3.5 is to average background usage with past background usage. Step 8.3.6 is to enter in running application table, comprising pushing the CPU data to the table.

Step 8.4 is to get the Data usage comprising a series of processes that obtain data about Data usage. Step 8.4.1 is to Start collecting data readings comprising if data usage has not been collected for the app. Step 8.4.2 is to Add to tally of data collected, comprising if data usage has already been collected for the app then update the current information. Step 8.4.3 is to tally background data usage. Step 8.4.4 is to tally Wi-Fi data usage. Step 8.4.5 is to tally mobile data usage.

Step 8.5 is to Combine data comprising a series of processes that organizes the collected data. Step 8.5.1 is Average Data, comprising averaging all of the collected data. Step 8.5.2 is Combine data comprising organizing and combining all collected data. Step 8.5.3 is to average background data. Step 8.5.4 is to combine background data. Step 8.5.5 is to average Wi-Fi data. Step 8.5.6 is to combine Wi-Fi data. Step 8.5.7 is to average mobile data. Step 8.5.8 is to combine mobile data.

Step 8.6 is to Get battery usage comprising a series of processes that obtain data about battery usage. Step 8.6.1 is to Collect battery usage for application comprising obtaining app battery usage. Step 8.6.2 is Average with last reading comprising averaging collected battery data with previous data. Step 8.6.3 is Enter in running application table, comprising pushing battery data to the table. Step 9 is to Update the Table with the latest collected data. Step 10 is to Wait until 15 second are met, comprising the data collection process is repeated every 15 seconds, and if the process ends early due to faster hardware, the software still waits 15 seconds before restarting.

FIG. 13 shows the method of transmitting the collected data to a back-end server. Step 11 is to collect device information. Step 12 is to collect app information from database. Step 13 is to collect app log record data from database. Step 14 is to combine data into JSON object. Step 15 is to compress data object. Step 16 is to transmit data to back-end server. Step 17 is to receive application category information. Step 18 is to update database with app categories. Step 19 is to send JSON with device info to back end server. Step 20 is to receive crowd source data. Step 21 is to update the local database with crowd source data.

FIG. 14 shows the method of adding new applications to M2AppMonitor. This occurs on initial install of M2AppMonitor, install of new applications on a device, or update of an existing app. Step 22 is to collect storage usage. Step 23 is to collect permissions. Step 24 is to collect notification access. Step 25 is to collect analytics used. Step 26 is to increment update count.

Additional modifications and improvements of the present invention may also be apparent to those skilled in the art. Thus, the particular combination of parts described and illustrated herein is intended to represent only one embodiment of the invention, and is not intended to serve as a limitation of alternative devices within the spirit and scope of the invention.

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.