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 
       [0001]    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 
       [0002]    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. 
         [0003]    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&#39;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. 
         [0004]    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 
       [0005]    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. 
         [0006]    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&#39;s performance data is compared to the criteria norms for the app&#39;s respective app category. If the app&#39;s resource usage greatly exceeds the category&#39;s norm, the M2AppMonitor user will be alerted of the app&#39;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&#39;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&#39;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. 
         [0007]    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&#39;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&#39;s device. 
         [0008]    Additionally, the M2AppMonitor is a single interface that allows users to see how their installed apps are affecting their device&#39;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&#39;s device in the background, even while the user is using other apps or functions on the mobile device. 
         [0009]    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 
         [0010]      FIG. 1  is a flow diagram showing the two timed operations that are employed for populating the table and assessing application performance. 
           [0011]      FIG. 2  is a flow diagram of the method for summation. 
           [0012]      FIG. 3  is a flow diagram of the method for Application Summation. 
           [0013]      FIG. 4  is a flow diagram of the Logging of Application Readings. 
           [0014]      FIG. 5  is a flow diagram of the method for Performing Checks. 
           [0015]      FIG. 6  is a flow diagram of the method for Get and Combine Data. 
           [0016]      FIG. 7  is a flow diagram of the method for Get Running Applications. 
           [0017]      FIG. 8  is a flow diagram of the method for Get Memory Information. 
           [0018]      FIG. 9  is a flow diagram of the method for Get CPU Information. 
           [0019]      FIG. 10  is a flow diagram of the method for Get Data Usage. 
           [0020]      FIG. 11  is a flow diagram of the method for Combine Data. 
           [0021]      FIG. 12  is a flow diagram of the method for Get Battery Usage. 
           [0022]      FIG. 13  is a flow diagram of the M2AppMonitor App Data Transmission. 
           [0023]      FIG. 14  is a flow diagram of the M2AppMonitor initial data collection for newly installed apps or upgraded apps. 
       
    
    
     DETAILED DESCRIPTION OF THE EMBODIMENTS 
       [0024]    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. 
         [0025]    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. 
         [0026]    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. 
         [0027]    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. 
         [0028]    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. 
         [0029]    Step  8  is to Get and Combine the data, comprising a series of processes that collect and organize data about the applications. 
         [0030]    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. 
         [0031]    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. 
         [0032]      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. 
         [0033]    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. 
         [0034]    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. 
         [0035]    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. 
         [0036]      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. 
         [0037]      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. 
         [0038]    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.