U.S. patent application number 14/078518 was filed with the patent office on 2015-05-14 for mobile device application monitoring software.
The applicant listed for this patent is Michael Brough. Invention is credited to Michael Brough.
Application Number | 20150133076 14/078518 |
Document ID | / |
Family ID | 53044196 |
Filed Date | 2015-05-14 |
United States Patent
Application |
20150133076 |
Kind Code |
A1 |
Brough; Michael |
May 14, 2015 |
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.
Inventors: |
Brough; Michael; (Aliso
Viejo, CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Brough; Michael |
Aliso Viejo |
CA |
US |
|
|
Family ID: |
53044196 |
Appl. No.: |
14/078518 |
Filed: |
November 12, 2013 |
Current U.S.
Class: |
455/405 |
Current CPC
Class: |
G06F 11/302 20130101;
G06F 11/3438 20130101; H04W 24/10 20130101; H04W 4/60 20180201;
H04L 43/16 20130101 |
Class at
Publication: |
455/405 |
International
Class: |
H04W 24/10 20060101
H04W024/10; H04W 4/00 20060101 H04W004/00 |
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.
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'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'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.
[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'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.
[0008] 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.
[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.
* * * * *