HK1185174A - System and method for server-coupled malware prevention - Google Patents

Description

System and method for server-coupled malware prevention

Background

The present disclosure relates generally to mobile security and, in particular, to detecting and preventing data from adversely affecting a mobile communication device or group of mobile communication devices.

Today mobile communication devices, such as cellular phones, smart phones, personal data assistants with wireless functionality, tablet PCs, netbooks, etc., are becoming more common platforms for various software applications. Mobile communication device users now have more freedom to select and install different software applications, thereby customizing the mobile communication device experience. However, despite the many aggressive software applications available on the market, the ability to interact, install and operate third party software inevitably leaves the mobile communication device vulnerable to vulnerabilities, malware and other harmful software applications. Unlike desktop computers and other less portable computing devices that can install and run antivirus software to protect against harmful software applications, mobile communication devices lack the processing power or resources to efficiently run similar software.

Third party applications have been developed that provide basic scanning functionality on mobile communication devices; however, these applications are often device, operating system, or application specific. Thus, a single, general purpose, platform independent system for efficiently monitoring, scanning, remediating, and securing mobile communication devices does not exist. It would be desirable to provide a system that operates on any mobile communication device, is independent of hardware and software, and can be continuously updated to provide continuous real-time protection. In addition, it would be desirable to provide an adaptable system that can act and respond to needs and changes that affect multiple mobile communication devices, thereby providing intelligent malware protection.

One feature common to many mobile communication devices is the fact that they are continuously connected to the network. However, despite this common link, it is still difficult to fully secure the mobile communication device at the mobile network level, since the device can connect to additional networks and utilize encrypted services, both of which often bypass network level protection. It would be desirable to provide a system that remotely protects a mobile communication device to provide malware prevention and analysis measures to multiple devices without the overhead of those measures running locally on each device, rather than relying solely on the processing and memory resources of each mobile communication device on the network.

One of the problems that makes it difficult to protect mobile communication devices from undesirable applications is the many different types of data and applications that are available for such devices. While service providers are able to manage network traffic when providing applications, there is currently no way to effectively monitor the behavior of these applications after they have been installed on a user's mobile communication device. As a further result, it is difficult to identify new previously unknown malicious applications by their behavior and to track and prevent the epidemic or spread of destructive applications and data once they have been published to the network. It would be desirable to provide a system that can actively monitor a group of mobile communication devices in order to collect data about the installation and behavior of applications on the mobile communication devices.

Once such a system is in place, it would be desirable to use the data and information obtained about the mobile communications device applications to help users make more informed decisions about the applications they choose to run on their mobile communications devices, and to allow administrators and network operators to take precautionary measures to further secure both the individual devices and the network as a whole. It would also be desirable to develop a way to anonymously aggregate data regarding mobile communication device behavior and activity in order to facilitate development of more secure mobile applications.

Drawings

The present disclosure is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:

fig. 1 is an example block diagram depicting one embodiment of the present disclosure.

Fig. 2 is an example flow diagram illustrating steps of one embodiment of the present disclosure.

Fig. 3 is an example flow diagram illustrating steps of one embodiment of the present disclosure.

Fig. 4 is an example flow diagram illustrating steps of one embodiment of the present disclosure.

Fig. 5 is an example flow diagram illustrating steps of one embodiment of the present disclosure.

Fig. 6 is an example flow diagram illustrating steps of one embodiment of the present disclosure.

Fig. 7 is an example flow diagram illustrating steps of one embodiment of the present disclosure.

Fig. 8 is an example flow diagram illustrating steps of one embodiment of the present disclosure.

Fig. 9 is an example flow diagram illustrating steps of one embodiment of the present disclosure.

Fig. 10 is an example flow diagram illustrating steps of one embodiment of the present disclosure.

Fig. 11 is an example flow diagram illustrating steps of one embodiment of the present disclosure.

Fig. 12 is an example flow diagram illustrating steps of one embodiment of the present disclosure.

Detailed Description

The present disclosure relates to a system and method for using a server to provide containment and removal of undesirable applications or other data objects that may affect a mobile communication device or multiple mobile communication devices regardless of the make or model of the mobile communication device, mobile communication network, or software application present on the mobile communication device. As used herein, all services associated with identifying, analyzing, and removing potentially undesirable applications or other data objects and mobile communication device protection are described under the non-limiting term "security". Accordingly, one embodiment of the present disclosure is directed to providing security to a plurality of mobile communication devices, such as a plurality of mobile communication devices for a group of employees or a plurality of mobile communication devices accessing a particular network. One embodiment of the present disclosure is directed to securely and reliably collecting information about applications on a mobile communication device without consuming individual mobile communication devices or mobile networks and utilizing the information about the applications to secure the mobile communication device. One embodiment of the present disclosure relates to using information collected from a mobile communication device to generate user or device information that may be used to develop future products or services for the mobile communication device.

It should be appreciated that an embodiment of the disclosure can be implemented in numerous ways, including as a process, an apparatus, a system, a device, a method, a computer readable medium such as a computer readable storage medium containing computer readable instructions or computer program code, or a computer program product including a computer usable mediumThe medium has computer readable program code embodied therein. It will be understood that the mobile communication devices described herein may include any computer or computing device running an operating system for use on a handheld or mobile device, such as a smartphone, PDA, tablet, mobile phone, or the like. For example, the mobile communication device may comprise a device, such as an Applethe ApplePalm Pre^TMOr running Apple iOS^TM、Android^TMOS、Google Chrome OS、SymbianWindowsOS、PalmOr Palm Web OS^TMAny of the above devices. As used herein, a mobile communication device may also be referred to as a mobile device, a mobile client, or simply a device or client.

In the context of this document, a computer-usable or computer-readable medium may be any medium that can contain or store the program for use by or in connection with the instruction execution system, apparatus, or device. For example, the computer-readable storage medium or computer-usable medium may be, but is not limited to, a Random Access Memory (RAM), a Read Only Memory (ROM), or a persistent storage such as a mass storage device, hard drive, CDROM, DVDROM, tape, erasable programmable read only memory (EPROM or flash memory), or any magnetic, electromagnetic, infrared, optical, or electrical system, apparatus, or device for storing information. Alternatively or in addition, the computer-readable storage medium or computer-usable medium may be a combination of these devices or even paper or another suitable medium upon which the program code is printed, as the program code can be electronically captured, via, for instance, optical scanning of the paper or other medium, then compiled, interpreted, or otherwise processed in a suitable manner, if necessary, and then stored in a computer memory.

An application, software program, or computer-readable instructions may be referred to as a component or module or a data object or data item. Applications may be hard-wired or hard-coded in hardware or may take the form of software executing on a general-purpose computer such that, when the software is loaded into and/or executed by a computer, the computer becomes an apparatus for practicing the disclosure. Applications may also be downloaded in whole or in part through the use of a software development kit or toolkit that enables one embodiment of the disclosure to be created and implemented. In this specification, these implementations, or any other form that an embodiment of the disclosure may take, may be referred to as techniques. In general, the order of the steps of disclosed processes may be altered within the scope of the disclosure.

As previously mentioned, a server or group of servers operating together may provide security services to one or more mobile communication devices. There are many possible ways in which multiple servers may operate together to provide security services without departing from the scope of this disclosure. One embodiment of such a system is shown in fig. 1, where one or more servers 151 communicate with one or more mobile communication devices 101 through a cellular, wireless internet, or other network 121. As mentioned above, the mobile communication device 101 may also be referred to as a "mobile client device," "device," or "client" and may be referred to in the singular or plural. One or more servers 151 may have access to a data store 111 that stores security information for one or more mobile communication devices 101. Data, assessment information, information about the mobile communication device 101, or other objects for storage may be stored on the server 151 and/or data storage 111. The server 151 or data storage 111 may be singular or plural or may be physical or virtualized. The data storage 111 may be a database, a data table, a data structure, a file system, or other memory repository. Data store 111 may be hosted on any of one or more servers 151 or may reside external to one or more servers 151, so long as one or more servers 151 have access to data store 111. In one embodiment, the data storage 111 is an external service provided by a third party, such as Amazon Web Services, LLC simple storage service (S3) or other product. It will be appreciated that the configuration of the system shown in fig. 1 is not limiting but exemplary only, and that other configurations are possible without departing from the disclosure.

It will be appreciated that the communication between the mobile communication device 101 and the server 151 may utilize a variety of networking protocols and security measures. In one embodiment, server 151 operates as an HTTP server and device 101 operates as an HTTP client. To secure the data in transit, the mobile communication device 101 and the server 151 may use transaction layer security ("TLS"). Further, to ensure that mobile communication device 101 has privileges for accessing server 151 and/or to verify the identity of mobile communication device 101, device 101 may send one or more identifiers or authentication credentials to server 151. For example, the authentication credentials may include a username and password, a device-specific credential, or any other data that identifies the mobile communication device 101 to the server 151. Authentication may allow server 151 to store information specific to mobile communication device 101 or an account associated with mobile communication device 101 to provide customized services to device 101 and maintain a persistent view of the security status of mobile communication device 101.

To provide security services for the mobile communication device 101, one of ordinary skill in the art will appreciate that the mobile communication device 101 will transmit certain data to the server 151. As will be discussed in more detail below, server 151 will analyze this data and provide security-related assessments, responses, and/or other actions. The following describes the type of data transferred from the mobile communication device 101 to the server 151, the analysis performed by the server 151, and the actions taken on or by the mobile communication device 101.

It will be appreciated that one embodiment of the present disclosure may exist on the mobile communication device 101 itself or may be incorporated into an existing security SYSTEM resident in the mobile communication device, such as the security SYSTEM described in U.S. patent application No. 12/255,614 entitled "SYSTEM AND method FOR MONITORING AND analysis MULTIPLE services AND MULTIPLE servers," filed on 21.10.2008 AND incorporated herein in its entirety. One of ordinary skill in the art will also appreciate that in order to implement one embodiment of the present disclosure on a variety of MOBILE communication device platforms, it may be necessary to incorporate a CROSS-platform SYSTEM such as that disclosed in U.S. patent application No. 12/255,626, entitled "SYSTEM AND METHOD FOR a MOBILE CROSS SYSTEMs SYSTEM" filed 10/21 2008 and incorporated herein in its entirety. Furthermore, as discussed further below, aspects of the present disclosure may be used to determine security status for the MOBILE communication device 101, such as described in U.S. patent application No. 12/255,632 entitled "SECURE MOBILE PLATFORM SYSTEM," filed 10/21 2008 and incorporated herein in its entirety.

Those skilled in the art will appreciate that mobile communication devices are exposed to different types of data. This data includes network data, files, executable and non-executable applications, e-mail, and other types of objects that may be transmitted to, received by, or installed on the mobile communication device. Mobile communication devices also typically transmit and receive data through one or more network interfaces including bluetooth, WiFi, infrared, radio receivers, and the like. Similarly, data may be encapsulated in a layered communication protocol or set of protocols, such as TCP/IP, HTTP, Bluetooth, and the like. Current server-client security models, such as those currently available for desktop and laptop computers, cannot extend their capabilities to provide adequate evaluation and security for multiple mobile communication devices.

The present disclosure contemplates at least two types of data that may be used to evaluate and protect a mobile communication device. The first type of data includes data about the mobile communication device, i.e., "device data. Device data relates to status, capabilities, operating system, firmware version, memory capacity, available communication ports, battery limitations, hardware characteristics, and other "baseline" information that may be common to all similar devices not customized. The device data may include default specifications for the device as received from the manufacturer, service provider, or IT service. The device data may include state information that is common to all similar mobile communications after they have been upgraded in some manner. As will be discussed further below, the device data may be used to evaluate whether a vulnerability exists due to an unprotected communication port, operating system utilization, device-specific attack, and the like.

The second type of data that may be used to evaluate a mobile communication device is data that relates to a particular application, file, or object that may be installed or run on the mobile communication device. As used herein, this data is referred to as "application data". The application data includes both data objects and information about the data objects, such as behavior data or metadata. The data objects include application packages that may be specific to certain mobile communication devices. For example, iPhone OS devices typically use IPA files or APP packages, Android OS devices typically use APK files, Windows Mobile devices typically use CAB, EXE, or DLL files, and Symbian OS devices typically use SIS files. The device may also support a cross-platform application format, such as SWF format under an Adobe's Flash runtime or JAR file that may run on a Java virtual machine.

The application data comprises data objects that are malware or spyware and thus may negatively affect the mobile communication device. Malware and spyware include applications, files, and other data objects intentionally designed to adversely affect or steal information from a mobile communication device. Application data also includes data objects that are not designed for nefarious reasons, but may have coding flaws or other problems that may negatively impact the device. Application data also includes data objects that may be undesirable for various reasons. For example, a data object may be undesirable because it compromises privacy, excessively drains the battery or network connection of the device, and/or has objectionable content. As used herein, a "data object" may also be referred to as a "data item". The use of other terms is not intended to limit the data to any one form.

The application data includes metadata about the data object. For example, metadata is information about a particular data object rather than the data object itself. The metadata includes the location on the file system of the mobile communication device where the data object is stored, the hash (hash) of the data object, the name of the data object, a unique identifier present in or associated with the data object, such as a GUID or UUID, security information related to the data object, such as its cryptographic signer information or authority level approved, and characteristics of how the data object is installed on or integrated with the operating system of the mobile communication device. The metadata for a data object may also include where the data object came from (e.g., from which its URL was downloaded, from which its application marketplace (markplace) was downloaded, from which its memory card was installed or stored). Metadata may also be retrieved from the application marketplace. Such metadata, referred to as bazaar metadata, includes information about the data object (such as the number of downloads, user comments about the data object, a description of the data object, rights requested by the data object, hardware or software requirements for the data object, information about the author of the data object, the price of the data object, the language or languages supported by the data object) and other information that the bazaar may provide.

In one embodiment, the application data also includes behavior data. The behavior data includes information about how the application interacts with or uses resources of the mobile communication device, such as memory usage, battery usage, network usage, storage usage, CPU usage, API usage, errors and crashes, connected network services (e.g., remote host addresses and ports), and runtime library links. The behavior data also includes information about how the application, file, or data object utilizes the functionality of the operating system of the mobile communication device when it is running, such as notifications and messaging between processes or installed applications.

As will be further explained below, both the device data and the application data facilitate providing an assessment of the security of the device based on stored data (e.g., installed applications) or data passing through the device. Those of ordinary skill in the art will appreciate that device data and application data are merely examples of the types of data that may be used to secure a mobile communication device or provide other functionality related to a mobile communication device. The disclosed system may also evaluate other types of data without departing from the scope of the present disclosure. As used herein, the term evaluation refers to information relating to a data object that can be used to evaluate or otherwise further understand the operation or operational effect of the data object. For example, the evaluation may include determining that the application is malicious or non-malicious, bad or good, unsafe or secure or that the application may appear on a blacklist or whitelist. The evaluation may include categorizing or characterizing data for the data object, ratings, such as security rating, privacy rating, performance rating, quality rating and battery impact rating for the data object, trust rating for the data object, distribution data for the data object. The evaluation may come from the results of the server 151 gathering and/or processing data and may be exposed to a user or other system by the server 151 via an API, user interface, data feed, or other method. It will be understood that the previous description for "evaluating" is not intended to be limiting in any way.

A. Device data collection

The following is a discussion of how device data and application data are collected and stored in accordance with one embodiment of the present disclosure. In general, the following discussion includes communications between server 151 and mobile communication device 101 over network 121. Any data transmitted or received during these communications may be stored on server 151 or on data storage 111. In one embodiment, the data stored on data storage 111 or server 151 is associated with a particular account or device known to the system. The association between the data and the device or account may allow server 151 to provide customized functionality for the account or device based on previously received data. In one embodiment, some or all of the data is stored on server 151 or data storage 111 with an anonymous association with a particular account or device. For example, the data and anonymous associations may be stored together for privacy purposes, such that checking that the data on server 151 or data store 111 cannot tie the anonymously associated data to a particular account or device; the device may populate and update this anonymously associated data. Anonymous associations are described in further detail below. In one embodiment, the server 151 will request information from the mobile communication device 101, which will respond with the requested information. In one embodiment, the mobile communication device 101 will transmit the device data and/or application data to the server 151 for analysis and evaluation. For example, a user of mobile communication device 101 may wish to download files to his device, but may wish to send files or identification data associated with files to server 151 before installing the files in order to check whether the files are malicious or otherwise undesirable. Server 151 will then analyze this received information in order to provide a security assessment that can be used for any of mobile communication devices 101. In another example, it may be useful to know how an accessed data object will affect the performance or behavior of the mobile communication device, the evaluation containing information such as average battery impact or average network usage of the data object. In one embodiment, server 151 stores the evaluations of the data objects after analysis and may provide access to these evaluations in a variety of ways. The analysis performed by server 151 will be discussed further below. The process by which server 151 provides access to evaluation information is also discussed further below.

To prevent network 121 and server 151 from being consumed by network traffic, various methods may be used to reduce the amount of data requested by server 151 and transferred to server 151. For example, a hash function or hash algorithm may be applied to the data and the resulting hash of the data may be sent to the server 151 instead of transferring the full data object, such as an application file or application package, for analysis. Server 151 may use a hash to uniquely identify a data object. If the server has previously performed an evaluation of the hash-identified data object, then server 151 may return it if the previous evaluation is still valid. If server 151 has not performed an evaluation for the data object, server 151 may return a response indicating that the evaluation is unknown and/or request additional data from mobile communication device 101. One of ordinary skill in the art will appreciate that a hashing algorithm will transform any number of data into a fixed length identifier. For example, the SHA-1 hashing algorithm may digest any number of input data into a 160-bit hash. In another example, metadata may be sent in place of the data object itself in addition to the hash of the data object, e.g., metadata for an application may be sent for evaluation rather than the entire application. In many cases, metadata, such as package name, application name, file size, requested permissions, cryptographic signer, download source, unique identifier such as UUID, and other information may be sufficient as identification information for the data object; thus, if server 151 receives the appropriate identification information, it may determine whether the data object is undesirable. Those skilled in the art will appreciate that there are a variety of methods that may be used to identify data objects in a manner that may allow server 151 to determine whether a data object installed on device 101 is malicious without transferring the entire data object to server 151.

In one embodiment of the present disclosure, server 151 may request portions of a data object rather than a complete data object. The entire data object may be transmitted incrementally so that network traffic does not burden network 121. Alternatively or additionally, server 151 may request information about a particular application, but may query groups of mobile communication devices each having such an application. In this manner, server 151 may receive a portion or "chunk" of data from one mobile communication device and another portion of data from a second mobile communication device as necessary and so on. Server 151 may then aggregate this information as it is received, thereby aggregating from multiple mobile communication devices with application/file data without consuming any particular mobile communication device. Examples of such methods are discussed further below.

Fig. 2 is an overview of the transfer of different types of data between the mobile communication device 101 and the server 151. As shown in fig. 2, in block 201, the mobile communication device 101 sends application data to the server 151, which receives this data (block 203). In this embodiment, the mobile communication device sends identification or authentication information to the server 151 so that the server 151 can reference previously stored identification or authentication information about the mobile communication device 101, store and retrieve data associated with the mobile communication device 101, and specifically identify or authenticate the mobile communication device 101 among other mobile communication devices.

In one embodiment, the server 151 sends a notification to the mobile communication device 101 (block 205). Such a notification may be a reminder, message, instruction, or other information related to application data or device data specific to the mobile communication device 101. In one embodiment, the notification is due to the device having previously sent application data corresponding to data objects that were not initially evaluated as undesirable by server 151, but were subsequently determined to be undesirable by server 151. In block 207, the mobile communication device 101 receives the notification and in block 209 the mobile communication device 101 takes an action based on the notification. As will be discussed in more detail below, such action may include deactivating one or more features or applications on the mobile communication device 101.

Those skilled in the art will appreciate that the interaction between the mobile communication device 101 and the server 151 may include communication from the mobile communication device to the server and from the server to the mobile communication device. For example, in one embodiment, server 151 may receive application data from mobile communication device 101, but server 151 may require additional information before providing an evaluation or transmission notification. In block 211, the server 151 may request additional information from the mobile communication device 101. The mobile communication device receives the request (block 213), collects additional information as requested by server 151 (block 215), and then transmits the additional information to server 151 in block 217. In block 219, server 151 receives the requested additional information. It will be appreciated that this process may be repeated as necessary.

Fig. 3-7 illustrate the transmission and aggregation of application data and device data in more detail. Fig. 3 illustrates an embodiment in which the server 151 evaluates changes to data objects stored on the mobile communication device 101. In fig. 3, the mobile communication device 101 detects a change in a particular data object (block 301). Those skilled in the art will appreciate that detecting changes to data objects may involve mechanisms such as intercepting system calls or file system operations, file system or other data object change listeners, receiving events from a packet management system (e.g., in Android)^TMPACKAGE _ update and/or PACKAGE _ replace intent in an operating system) and to round-robin data objects in a file system or other system capable of enumerating data objects. Other techniques for detecting changes may also be used. Alternatively or additionally, the following method may occur upon detection of a change to a data object, upon a user request of the mobile communication device, or upon a pre-configured schedule for analyzing and evaluating data objects on the mobile communication device.

In one embodiment, changes to data objects may include adding, removing, or modifying data objects at any time. After transmitting the application data for the data object, the mobile communication device 101 waits for an acknowledgement from the server before recording that it has successfully transmitted the application data for the data object. After receiving application data for the data object from the mobile communication device 101, the server 151 transmits an acknowledgement. If there is an error in the transmission or in the data itself, server 151 returns an error. If mobile communication device 101 receives an error from server 151 or does not receive a response after transferring the application data for the data object, mobile communication device 101 will not record the application data for the data object as having been sent and mobile communication device 101 may retry sending the data at some point in the future. Those skilled in the art will recognize that mobile communication devices sometimes cannot connect to a network or may have their network connection interrupted in the middle of a transmission. Thus, it is important for the mobile communication device 101 to record whether the server 151 has successfully received application data for a data object for the operation of a reliable data aggregation system. In one embodiment, application data for a data object, which has not been transmitted from mobile communication device 101 and has not been received by server 151 at any time, is considered changed and needs to be transmitted.

In one embodiment, the mobile communication device 101 stores whether it has transmitted and the server 151 has successfully received application data for one or more data objects present on the device. To identify which data objects have had appropriate application data reported to server 151, mobile communication device 101 may store a database containing identification information for data objects that have been successfully reported to server 151 to determine whether the device needs to transmit application data for those data objects. For example, a data object that is a file on a file system may be identified by a hash of its content. The database may not contain data for the data object the first time the data object is installed on the mobile communication device 101. Since there is no identification information for the data object, the mobile communication device 101 recognizes the data object as new and transmits application data for the data object to the server 151 to indicate that the object is new. After transmitting application data for the data object to server 151 and receiving confirmation that the server successfully received the application data, the device stores the hash of the file content and the location on the file system where the file resides in a database. If the data object is to be deleted, the mobile communication device 101 may detect that there are no files in the previously stored file system location and may report the deletion of the data object to the server 151 by reporting the hash identification information and/or file system location for the data object. If the file is to be modified, such as in the case of an update application, the mobile communication device can detect that there is a file in a previously stored location on the file system, but that the content hash of the file does not match the stored content hash. In this case, the mobile communication device 101 may report to the server that the file location and/or the data object identified by the previous content hash has been updated and report the new content hash for the file.

In an example, a security system installed on the mobile communication device 101 may report application data for a data object to the server 151 for the purpose of receiving an evaluation of the data object. If the mobile communication device downloads a new application that is malicious, it is important that the security system detects this new item as soon as possible. Server 151 may analyze the new application and provide a security assessment whereby an action may be taken based on the results. In another example, the first version of the application may be secure, but the second version of the application may be malicious. It is important that the security system recognize that this update is different from the first version of the application so that it will produce a new assessment of the second version without reporting only the first assessment. Server 151 may analyze the updated application and provide a security assessment whereby an action may be taken based on the results.

At block 303 of fig. 3, mobile communication device 101 transmits identification information for the mobile communication device to server 151. In one embodiment, the identification information is authentication information. In one embodiment, the identification information is a non-authoritative identifier for the device, such as a device ID that is not considered secret. In one embodiment, the identification information includes device information (e.g., make, model, hardware characteristics) for the mobile communication device. In addition, the mobile communication device 101 transmits information for the changed data object. Such information may include identification information for the data object, such as metadata (e.g., hash, package name, file path, cryptographic signer, unique identifier, such as UUID), and so forth. In block 305, the server 151 receives an identifier for the mobile communication device 101 and information for the changed data object. Server 151 stores the received data on a server or on data storage device 111 (block 307). In one embodiment, only some of the data received by server 151 is stored. In block 309, server 151 provides an evaluation for the changed data object using any of the techniques disclosed herein or from U.S. patent application No. 12/255,621, which is incorporated by reference in its entirety. The evaluation may include marking the changed data object as safe, malicious, or unknown instruction and/or classification. In one embodiment, some or all of the received data is stored on server 151 or data storage 111 and is associated with the device that transmitted the data. This may later allow server 151 to determine which applications the device has encountered, for example. In another embodiment, some or all of the received data is stored on server or data storage 111 in such a way that server 151 cannot directly link information to a particular device. For example, server 151 may store the received data without any link to a particular device or account. In another example, the server may associate the data with the identifier upon storage to anonymously associate the data with the device. To ensure that server 151 cannot associate stored data with a particular device, the identifier is known only to the device transmitting the data and is provided to the server whenever the device transmits the data. The server does not store this identifier, so the identifier is never directly linked to a particular device or account on server 151 or data store 111. In one embodiment, server 151 stores the results of the evaluation on a server or on data storage 111. If an evaluation 309 for the data object is needed and a previous evaluation for the data object exists and is deemed valid, server 151 retrieves the previous evaluation from data store 111 instead of performing the new evaluation. An evaluation may be considered for the same data object if the metadata related to each object matches in a variety of ways, including if the evaluation relates to data objects having the same hash, the same package name, the same cryptographic signer, or the same file path. In block 311, the assessment is transmitted to the mobile communication device 101, which receives this assessment from the server 151 (block 313) and then processes the assessment or takes appropriate action (block 315).

Those skilled in the art will appreciate that the interaction between the mobile communication device 101 and the server 151 is dynamic in that the server 151 may proactively (proactively) transmit instructions or notifications for correcting data objects whose assessment has changed, thereby requiring action by the mobile communication device 101. Fig. 4 illustrates such an embodiment. In block 401 of fig. 4, the mobile communication device 101 detects a change in a particular data object. In block 403, the mobile communication device 101 sends identification information for the device and information about the changed data object to the server 151. The server 151 receives identification information for the mobile communication device 101 and information about the changed data object (block 405). In block 407, server 151 stores the changed data information on the server or on data storage 111. In block 409, server 151 may analyze and evaluate the changed data object and may report the evaluation to mobile communication device 101 (block 411). As previously discussed, if an evaluation has been performed on a data object, the previously performed evaluation may be retrieved and used rather than re-performing the evaluation. If the server 151 reports an assessment, the mobile communication device 101 receives the assessment or other notification in block 413 and processes the assessment (block 415).

In one embodiment, the evaluation for the data object may change. For example, a data object that has been previously evaluated as safe or unknown may be later identified as malicious, causing some previously unknown vulnerability, or causing undesirable behavior such as network overuse or battery drain. In block 417, if server 151 detects an evaluation change for a previously analyzed data object, server 151 may transmit a notification, correction instruction, or the like to mobile communication device 101 in block 419. The mobile communication device 101 receives the notification from the server 151 (block 421) and then performs the recommended action or corrective instruction (block 423). In block 425, the mobile communication device 101 transmits an acknowledgement that it performed the desired action, which is received by the server 151 (block 427). In one embodiment, the notification is sent to the mobile communication device only if it is determined that a data object is present on the mobile communication device 151. In one embodiment, server 151 stores information on server 151 or on data storage 111, allowing server 151 to determine whether mobile communication device 101 currently has a data object or has previously requested an evaluation for a data object.

Those skilled in the art will appreciate that fig. 4 provides but one example of how server 151 may report evaluation changes to a mobile communication device, and that some steps may be omitted without departing from this disclosure. For example, the mobile communication device may perform a corrective instruction or other desired action without sending an acknowledgement to server 151.

In one embodiment, the server 151 may request additional information from the mobile communication device 101 regarding a particular data object. For example, mobile communication device 101 may send information about the changed data object to server 151; however, the information sent may not be sufficient for server 151 to perform a conclusive analysis. Fig. 5 illustrates this embodiment. In block 501 of fig. 5, the mobile communication device 101 detects that the data object has changed and transmits identification information for the mobile communication device 101 to the server 151 along with information for the changed data object (block 503). Server 151 receives the identification information for mobile communication device 101 and the information for the changed data object (block 505) and stores the information for the changed data object on the server or on data storage 111 (block 507). In block 509, server 151 determines whether it needs additional information about the changed data object. For example, server 151 may attempt to evaluate whether the changed data object is safe or malicious, but cannot provide a conclusive evaluation (i.e., the evaluation results in "unknown"). The determination of whether more information is needed may be performed before server 151 performs the evaluation if there is insufficient data to even begin the evaluation or may be performed after the evaluation is returned conclusively due in whole or in part to lack of data. If additional information is needed, server 151 may request additional information from mobile communication device 101 (block 511).

In block 513 of fig. 5, the mobile communication device 101 receives the request for additional information, collects the requested information (block 515), and then transmits the additional information to the server 151 (block 517). In one embodiment, the additional information comprises behavior data for the data object and application data for the data object, such as content for the data object. In block 519, the server 151 receives additional information from the mobile communication device 101 and stores the additional information (block 521). Server 151 may then analyze the changed data object information along with additional information to provide an assessment (block 523), which may be sent to mobile communication device 101 (block 525). In block 527, the mobile communication device 101 receives an evaluation of the changed data object from the server 151 and then processes the evaluation (block 529).

In one embodiment, mobile communication device 101 may choose to transmit additional information to server 151. For example, server 151 may analyze the data object but not provide a conclusive evaluation. The mobile communication device 101 may request additional evaluations by providing additional information for the data object to the server 151 without requesting additional information from the device. Fig. 6 illustrates this embodiment.

In block 601 of fig. 6, the mobile communication device 101 detects a change in the data object and then in block 603, the mobile communication device 101 sends its identification information and information for the changed data object to the server 151. In block 605, the server 151 receives identification information for the mobile communication device 101 and information for the changed data object. This information is stored by server 151 on the server or on data storage device 111 (block 607) and then analyzed by server 151 to produce an assessment (block 609). In block 611, the server 151 transmits the assessment or appropriate notification to the mobile communication device 101. Mobile communication device 101 receives the assessment from server 151 (block 613 of fig. 6). In block 615, the mobile communication device 101 determines whether to transmit additional information about the data object. For example, server 151 may not be able to generate an evaluation for a data object given the available data it has, and therefore may need more information to be able to generate an evaluation. In block 617, if the mobile communication device 101 determines that it should transmit additional information about the data object, this information is collected. In block 619, the mobile communication device 101 transmits the additional information to the server 151, which receives this information (block 621) and stores the received additional information (block 623). It will be appreciated that the server 151 will know that the additional information will relate to information previously received by the server 151 (block 605) because the mobile communication device 101 will transmit the identification information along with the additional information.

In block 625 of fig. 6, the server 151 analyzes the additional information received from the mobile communication device 101. In one embodiment, the additional information may be analyzed along with previously received information (block 605). In block 627, the server 151 transmits the assessment to the mobile communication device 101, which processes the assessment (block 629). If the mobile communication device 101 still needs to transmit additional information, it may repeat the process as necessary.

As previously noted, server 151 may have access to multiple mobile communication devices, some of which may run or store the same application or data object. Requesting data object information from a single mobile communication device may cause network traffic to affect not only the single mobile communication device but also other devices on the network. In one embodiment, if server 151 requires information about data objects stored on more than one mobile communication device, server 151 may collect portions of the required information from each of the mobile communication devices rather than relying on a single device. Fig. 7 illustrates an embodiment that uses first and second mobile communication devices, thereby optimizing the aggregation of data from two or more mobile communication devices.

In block 701 of fig. 7, the first mobile communication device detects a change in a data object. The data object is also found on the second mobile communication device but may or may not implement the same changes. The first mobile communication device transmits its identification information and information for its changed data object to server 151 (block 703). In block 705, the server 151 receives identification information for the first mobile communication device along with information for the changed data object. Server 151 stores this information (block 709). In block 711, server 151 determines that it needs additional information about the data object. In block 713, server 151 identifies a second mobile communication device that server 151 knows also stores the data object and additional information for the data object.

In block 715 of FIG. 7, server 151 requests additional information for the data object from the second mobile communication device. The second mobile communication device receives this request (block 717). In response, the second mobile communication device will collect the additional information (block 719) and then transmit the additional information to the server 151 (block 721). The server 151 receives (block 723) from the second mobile communication device and stores additional information about the data object on the server 151 or on the data storage 111 (block 725), and then analyzes this additional information along with previously received information from the first mobile communication device to submit an evaluation (block 727). This rating is transmitted to the first mobile communication device (block 729), which receives the rating (block 731) and processes the assessment (733). It will be appreciated that server 151 may also transmit the assessment to the second mobile communication device if relevant.

In one embodiment, server 151 may collect additional information from multiple devices. In one embodiment, server 151 selects from which devices to request additional information by analyzing the device information and application data previously stored by the server. For example, to characterize an application's use of SMS messaging to determine whether it is abusing SMS for spam purposes, server 151 may request a count of SMS messages sent by an application from a number of mobile communication devices that have previously reported that they have installed an application. In one embodiment, the server attempts to analyze the data object to produce an assessment without first waiting for information about the data object to be received from the device. Alternatively, the server may receive data from other sources and proactively request information from one or more devices to create an evaluation for the data object.

In one embodiment, the application data for the data objects collected by the mobile communication device 101 and transmitted to the server 151 may include behavioral data about the data objects. The use of such data by server 151, such as during analysis, is discussed in more detail below. Behavior data may include information about what a data object did when it was run on a device. Examples of behavioral data include information about network connections that are caused by the data object (e.g., server name, source/destination address and port, connection duration, connection protocol, amount of data transmitted and received, total number of connections, connection frequency, and network interface information for the connection, generated DNS requests), behaviors of the data object at runtime (e.g., system calls, API calls, libraries used, inter-process communication calls, number of SMS messages transmitted, number of email messages sent, information about user interfaces displayed, URLs accessed), overhead caused by the data object (e.g., battery used, CPU time used, network data transmitted, storage used, memory used). Other behavioral data includes the context when a particular behavior occurs (e.g., whether the screen of the phone is off when the data object sends an SMS message, whether the user uses the data object when it connects to a remote server, etc.).

Since data objects generate a large amount of behavior data each time they run, it is important that the mobile communication device does not collect or transmit all possible behavior data; otherwise, collecting and transmitting behavioral data may over-utilize resources on device 101, server 151, and network 121. In one embodiment, the mobile communication device 101 limits what types of behavior data it collects and transmits for data objects, and how often behavior data is collected and transmitted based on the time period since the data object has last changed. For example, when a data object is first installed on a mobile communication device, the device may collect and transmit the full amount of behavior data available on a daily basis. One week after installing the data object, the device may only send a limited subset of the behavior data in the weekly interval. One month after installation, the device may only send a minimum amount of behavioral data in the monthly interval. In one embodiment, if the data object is upgraded (e.g., an application is updated to a different version), the device may transmit the full range of behavioral data daily and reduce the range and frequency of data collected and transmitted after a week and/or after a month. In one embodiment, server 151 sends a configuration to mobile communication device 101 requesting that the device send a specific type of behavior data at a specific frequency. The device stores the configuration so that it can determine whether to collect and/or transmit behavioral data for the data object. In one embodiment, the configuration information is specific to a particular data object. In one embodiment, the configuration information is for all data objects encountered by the device. In one embodiment, server 151 requests behavioral data for a particular data object from a device, so that the server can minimize behavioral data collected and transmitted unnecessarily.

In one embodiment, server 151 may affect the collection of behavioral data and the transmission from device 101 to server 151. For example, the server may transmit instructions to the device requesting behavior data for a data object only if the server 151 has information indicating that the mobile communication device 101 currently has a data object and if the server needs more behavior data to better evaluate the data object. In one embodiment, server 151 determines that it needs more behavior data for the object based on the number of devices that have reported behavior data. For example, the server may require at least one hundred (100) devices to report behavioral data for each data object in order to have a confidence evaluation. In one embodiment, the difference in the behavior data reported by different devices is used to determine how much behavior data is needed to evaluate confidence. For example, if thirty (30) devices all report battery usage of a data object within a small variance, the server may not request any more behavioral data for that object; however, if those thirty (30) devices indicate a wide battery usage change, the server may request behavior data from two hundred (200) devices.

In one embodiment, the mobile communication device may transmit the behavioural data only if the data is outside a normal limit (bound). In one embodiment, the limits are common to all data objects. For example, a limit on the amount of network usage may be set so that the mobile communication device transmits behavioral data for the connection of the network of data objects only if the data object maintains at least one open connection for more than 50% of the time it runs or if the data object transmits more than one megabyte of data in a 24-hour period. In one embodiment, server 151 may update the on-device limits by transmitting updated limit information to mobile communication device 101. In one embodiment, the limits may be specific to one or more data objects. For example, a device may have a set of default limits by which it will send behavioural data, but a server may transmit limits for a particular data object that identify the data object by identifying information, such as a hash, cryptographic signer, package name, or file system location. The updated limits may instruct the device to send more or less behavioral data than the default set of limits. For example, the mobile communication device may never send behavior data by default. When a new data object is installed on a device, the device reports metadata associated with the data object and the installation event to the server. If the server has characterized the data object by behavior data from other devices, the server may send limits to the device specifying typical behavior of the data object on other devices (e.g., using less than 100 kilobytes of data per day, never sending an SMS message, never sending an email), so that if the data object deviates from these limits, the mobile communication device will send the server deviating behavior data. Such a deviation may be useful in the case of becoming a legitimate application that is utilized and begins to exhibit non-specific behavior or in the case of a "timed bomb" application that begins to become malicious only after a certain time.

In one embodiment, the data transferred from the mobile communication device 101 to the server 151 is configurable to protect user privacy; preventing overuse of device, network or server resources; or for other reasons. Some example configurations include selecting what application data to send from device 101 to server 151, how often to send the application data, and how to retransmit the application data if the initial transmission fails. Example configurations may also include transmitting only identification information (with the exception of no additional metadata or behavior data), never transmitting any application data, never transmitting data object content, transmitting application data for a data object based only on the source of the data object, transmitting only certain types of behavior data, transmitting only a certain amount of application data per day, transmitting only content of one data object per day, transmitting behavior data of each data object at most once per day, and so forth. Those skilled in the art will recognize that additional configurations are possible without departing from the scope of the disclosure. In one embodiment, the mobile device 101 and/or the server 151, a device that makes only certain transmissions, and/or a server that makes only certain requests to a device may perform the configuration. In one embodiment, one or more parties control the configuration. For example, the server 151 or software resident on the mobile communication device 101 may be automatically set or an administrator may control via the server 151 and/or a user may control configuration via the mobile device 101. In one embodiment, different parties control portions of the configuration. For example, a user may be able to control whether data objects are reported to server 151, but an administrator for server 151 may control the frequency of behavior data reporting for all devices to optimize battery usage of the security system.

In one embodiment, the software on the mobile communication device 101 displays a user interface dialog when it receives a request to transfer application data for a data object, such as its content or behavior data. As discussed above, the request for content of a data object may be for the entire content or for portions of the content, if portions are requested, the request identifies which portion of the content. The displayed user interface dialog may identify the data object to which the application data is to be sent and give the user of the device an opportunity to allow or deny the transmission. In one embodiment, the dialog allows the user to have the device remember his or her decisions for future data objects. In one embodiment, the dialog allows the user to view more in-depth information about the application data to be sent and provides a way for the user to understand the privacy implications of sending the data (such as linking to privacy policies, privacy descriptions, or other content describing how the data is transmitted, stored, and used). In one embodiment, the mobile communication device attempts to transmit the data object when it receives an indication that server 151 needs more information to generate an evaluation. In this example, the device may display a user interface dialog that prompts a user of the device to select whether to transmit the content of the data object when the device attempts to transmit the data object. In one embodiment, some attempted transmissions of certain types of application data, such as the content of a data object, result in a user interface dialog for confirmation, while other types of application data, such as metadata or behavior data, are transmitted without user confirmation.

Since a particular application may utilize multiple data objects, it may be desirable for the mobile communication device 101 and/or the server 151 to group the multiple data objects together so that the application may be analyzed as a whole. In one embodiment, the mobile communication device 101 or the server 151 may perform the grouping by comparing the application data between a plurality of data objects. Application data that may be used to group data objects includes, for example, how the data objects are installed (e.g., data objects from the same installer may be grouped), whether the data objects are linked together at runtime or dynamically, whether multiple data objects are in the same file system directory, and whether the data objects share a cryptographic signer. For example, an application installer may retrieve an executable file and a plurality of libraries to a file system on a mobile communication device. The mobile communication device 101 may use a common installer to consider grouped data objects and may store grouped information for use in collecting behavioral data (discussed below). In order for server 151 to identify the group, the application data of each data object may include identification information for the common installer. Server 151 may store the relationships of the packets explicitly on server 151 or in data storage 111 to efficiently access the packet information during analysis.

Since behavioral data cannot always be attributed to a single data object when multiple objects are executed together, such as in the context of a single process, it may be desirable for the mobile communication device 101 to group multiple data objects together and report behavioral data for the group together if the device operating system does not support granular behavioral data or by other mechanisms. In one embodiment, the mobile communication device 101 transmits information indicating the association of the grouped data objects to the server 151 and transmits application data for the grouped data objects together. For example, if a process on mobile communications loads multiple components from different sellers and network data can only be collected at each process level and/or if the process is detected to be connected to a known malicious server, it may be desirable that all components loaded in the process be identifiable by the server to determine a foul component. When the mobile communication device 101 collects behavior data for a process, such as an IP address to which the process has connected, the device reports to the server identification information for all data objects associated with the process. When the server receives behavioral data for a group of data objects, it may analyze the behavioral data from multiple devices and determine that only groups containing particular data objects will connect to a malicious server. Thus, only data objects that cause a connection to a malicious server will be considered malicious. In one embodiment, if the mobile communication device does not provide granular information about the behavior of a particular data object, the behavior data for the device as a whole may be transmitted to the server as a group representing all data objects installed on the device. For example, if the operating system does not provide per-process battery usage information, the device running the operating system may transmit to server 151 a list of applications installed on each device and a total battery life for each device. The server may then perform an analysis on this data to determine which applications are associated with better or worse battery life and to estimate the contribution of each application to battery life when installed on the device. In one embodiment, where multiple data objects in a group have different behavioral data collection configurations, the mobile communication devices will come together in a converged configuration. For example, if the mobile communication device 101 is configured to report a large amount of behavioral data per day for one data object, but is configured to report only abnormal behavioral data for another data object, and the data objects are grouped, the device may converge the two configurations and report a large amount of behavioral data for the group. Alternatively, if the second data object is configured for never reporting behavioral data for privacy reasons, then the group may be targeted to never report behavioral data to satisfy privacy constraints.

Those skilled in the art will appreciate that data transmitted by the server 151 or the mobile communication device 101, such as metadata, behavioral data, configuration information, behavioral data limits, packet data, requests for additional data, notifications, and other forms of data, may be formatted using binary or non-binary formats. Examples include formatting the data in XML, JSON, or as part of a URI. Data may be transmitted using a variety of protocols including TCP, UDP, DNS, and HTTP. Other formats and/or protocols may be used without departing from this disclosure.

The foregoing are various non-limiting examples of how data may be collected and aggregated from one or more mobile communication devices. Techniques for optimizing data aggregation are also disclosed above. As discussed, the mobile communication device 101 will transmit some or all of the data described above to the server 151 for analysis, so that the server 151 can provide an evaluation of the analyzed data. The following sections describe non-limiting examples of analysis techniques. Those skilled in the art will appreciate that although the following examples and disclosure use data collected using the methods described herein, other types of data may be transmitted and the disclosure is not limited to the data described herein.

B. Data collection system

Those skilled in the art will appreciate that server 151 may receive data from sources other than mobile communication devices for use in analyzing data objects and generating assessments. FIG. 10 illustrates one embodiment in which server 151 may receive data from multiple sources and transmit evaluation information for multiple uses. One or more servers 151 are illustrated as a "cloud" to emphasize that multiple servers can operate in coordination to provide the functionality described herein. One or more mobile communication devices 101 are illustrated as a group to emphasize that multiple devices 101 can transmit information to server 151 and receive information from server 151. As disclosed above, one or more mobile communication devices 101 may transmit application data for a data object to the server 151, and the devices 101 may receive evaluation data, requests for more information, notifications, etc. from the server.

In addition to collecting data from mobile communication devices, server 151 may also receive information relating to data objects from a variety of data collection systems. Such a system may be separate from server 151 or may be part of server 151. In one embodiment, the data collection system directly updates a database or other storage on server 151 or data storage 111 with information for one or more data objects. In one embodiment, the data collection system communicates with server 151 to provide information to server 151. There are many types of systems that may be used as data feeds to server 151. Some examples include web crawlers (web crawlers) 1003, application marketplace data collection systems 1005, honeypot technology (honeypot), and other systems that can feed information about mobile device applications to the server 151.

In one embodiment, web crawler 1003 downloads data objects that may be running on the mobile communication device and retrieves information about the data objects to feed both to server 151. For example, web crawler 1003 may utilize a search engine to find a website hosting a mobile application. Once crawler 1003 identifies sites hosting mobile downloads, the crawler may retrieve web pages available on those sites to examine the content of each page to determine additional pages to retrieve. For example, a page on a mobile download site may contain links to other pages as well as links for downloading data objects. It may be desirable for the data collection system to transmit only mobile device related information to server 151 because there is a large amount of content (e.g., PC software) available on the internet that does not affect the mobile communication device. In one embodiment, crawler 1003 may identify whether data objects available for download or already downloaded are capable of running on the mobile communication device. For example, crawler 1003 may examine the download URL for a particular string indicating that the URL corresponds to a mobile application package (e.g., SIS, APK, CAB, IPA). In another example, crawler 1003 may check the data object after it has been downloaded to determine whether it affects the mobile communication device and if so, whether it affects a particular mobile platform. In this case, crawler 1003 may check the downloaded data object for characteristics such as its name, whether it contains executable code compatible with any mobile platform, or whether it contains data typical for a particular mobile device platform. In one embodiment, web crawler 1003 collects bazaar metadata about data items and transmits bazaar metadata to server 151. Some example mart metadata includes which websites the data object is available to download from, user ratings and reviews for the data object, its price if the data object is available for purchase, the number of times the data object has been downloaded, information about the author of the data object, and other information relating to the data object available on the websites. As will be discussed below, when a given data object is available, it may be used to determine how trustworthy the data object is. For example, a data object available from a website of a reputable company may be considered more trusted than a data object uploaded on a forum by one of the users of the mobile device forum.

Since many mobile applications are only available via the mobile application marketplace, it may be important for server 151 to receive information about data objects available in the application marketplace. In one embodiment, the application marketplace data collection system 1005 retrieves information about the data objects, such as the content of the data objects and marketplace metadata for the data objects, from the mobile application marketplace and reports the information to the server 151. In one embodiment, application marketplace data collection system 1005 is part of server 151. In an alternative embodiment, the application marketplace data collection system is separate from the server 151. Application bazaars are often provided by mobile platform vendors (e.g., Android markertplace, blackberry App World, Apple App Store, Nokia Ovi Store) or third parties (e.g., GetJar, hangango) and may use proprietary APIs. In one embodiment, the application marketplace data collection system 1005 is configured to communicate with the application marketplace server via a proprietary protocol. To transfer data received from the application mart servers to server 151 in a manner usable by server 151, mart data collection system 1005 may transform the application data for the data objects from a proprietary format into a format that server 151 may use for analysis. For example, an application marketplace may provide an API for accessing user comments and ratings for applications; however, the data returned by the API may be different from the comment data of another application marketplace. In another example, the application marketplace may proactively transmit data to the marketplace data collection system 1005 so that the data collection system need not query it repeatedly. To allow server 151 to be able to analyze review data from multiple application marts, application mart data collection system 1005 may transform the differently formatted review data into a standard format for transmission to server 151. In one embodiment, the application marketplace data collection system 1005 may search the user review for certain items such as "battery drain," "crash," "privacy settings," "not working," "phone number," "contacts," etc., which may be used to establish the trustworthiness of the application or to characterize the application as "known bad" using the system components described herein. In an alternative embodiment, the application marketplace data collection system 1005 may collect all of the review data, and the server may perform an analysis of the review data. Similarly, the server 151 or the application marketplace data collection system 1005 may be able to identify positive reviews or scores for data objects, thereby improving the evaluation and/or credibility for the data objects.

In addition to automatically collecting data object information, it may also be important for server 151 to receive human information 1007. Such information may include subjective trust scores, specific keywords, or other characteristics, such as heuristics, for mobile application sellers that may classify the mobile application as suspicious. Those skilled in the art will recognize that other types of information that a human may provide in connection with the analysis of data objects for a mobile device are possible without departing from the scope of the present disclosure. In one embodiment, server 151 provides a user interface by which someone may provide information to server 151 about a particular data object, a group of data objects (e.g., data objects from a particular developer, all data objects on a particular platform), or information for the analytics system as a whole (e.g., updated analytics heuristics). In one embodiment, a server separate from server 151 provides a user interface through which someone can provide information about a particular data object, group of data objects, or for the analytics system as a whole. This separate server may transfer the user-provided information to server 151, where server 151 stores it on server 151 or in data storage 111. In one embodiment, the disjoint server directly updates the data storage 111 with information provided by the user.

FIG. 10 illustrates how server 151 may provide information about data objects to external systems. In one embodiment, information provided by server 151 may be transferred via an API; providing the information as a list, data feed, report, or formatted data, such as firewall or virus definitions; or in other forms. In one embodiment, server 151 provides information about the data objects to application marketplace 1009. For example, server 151 may provide bazaar 1009 with a list of malicious data objects present in bazaar 1009. In another example, server 151 may expose an API through which application marketplace 1009 may transmit identification information (e.g., a hash of the content of the data object) to server 151 to determine whether the data object is deemed malicious or otherwise undesirable. In one embodiment, server 151 provides data to network security infrastructure 1011 so that network security infrastructure 1011 can protect against malicious or undesirable applications at the network level. Even mobile communication devices without installed security software may benefit from protection, for example, by protection at the network level. In one embodiment, server 151 transmits a threat signature to network security infrastructure 1011. Such threat signatures may take a variety of forms, such as hashes of undesirable applications, binary sequences for undesirable applications, packet names of undesirable applications, firewall rules for blocking malicious servers or attackers, and rules for network security systems such as Snort. In one embodiment, server 151 provides data in the form of data feeds 1013. The data feed 1013 may contain a collection of data from the server or a variety of data available to the server 151 or data storage 11 from further analysis (described below), a list of any data objects, e.g., using more network traffic than a given threshold to identify misbehaving or abusing applications, a list of most prevalent malicious data objects, and a list of applications that match criteria, such as a set of heuristics for identifying potentially malicious applications.

C. Server-side analysis system

To produce an evaluation or other form of useful output for the data object, the server may use a variety of analysis methods. In one embodiment, since the server has access to information collected about the data objects from one or more sources, the server may process the information to generate an evaluation for the data objects. FIG. 11 illustrates an embodiment in which server 151 aggregates application data for data objects, stores information, generates characterizations and classifications for the data objects, evaluates the data objects to produce evaluation information, and transmits the evaluation information. In block 1101 of FIG. 11, application data (e.g., data object content, metadata, behavioral data, mart metadata) is collected for the data object. Some of the possible methods for collection and types of data collected have been discussed above. Such methods may include collecting data from devices, from websites, from application marts, from demographics, and from other sources. In block 1103, application data for the data object is stored on server 151 or data storage 111 so that it can be used at a different time than when the data was collected.

At block 1105, device data is collected and stored (block 1107) on server 151 or data storage 111. It may be desirable for the device data to be linked to application data of the device for reporting so that the evaluation, categorization and characterization may take into account the source of the data. For example, if an application fails only when installed on a particular device type, it is important that server 151 be able to analyze the device-provided application data in the context of what particular device type provides the data. In one embodiment, when storing the application data 1103, it is associated with device data for the device that provided it. For example, when device 101 transmits application data to server 151, the device may transmit authentication information that allows server 151 to retrieve previously stored data for device 101. If device 101 has transferred device data to server 151, then previously stored device data may be associated with the new application data. In such data collection systems, it may be important to protect privacy and minimize the individually identifiable information stored by server 151 or data storage 111. In one embodiment, application data for multiple devices having the same device data is aggregated such that the stored data is not linked to a particular device, but is a set of device data shared for one or more devices. In the design of such systems, it may be important to consider a balance between device data granularity and the level at which aggregated data may be attributed to a particular device.

As part of analyzing the data object, it may be desirable for server 151 to characterize and/or categorize it (block 1109). In one embodiment, server 151 stores characterization and classification data for data objects (block 1111). It may be desirable to update the characterizing and categorizing data as more data becomes available or the analysis of the data changes. In one embodiment, server 151 performs additional analysis (block 1109) and updates the stored classification and characterization data for the data objects (block 1111) when new or updated data for the data objects used by the analysis system is available.

The characterizing data includes information that describes the function, behavior, and reputation of the data object, such as its capabilities, metrics for the data object, analysis of other data related to the data object, and so forth. In one embodiment, server 151 uses application data, device data, mart data, distribution data, and other data available to server 151 to generate characterization data for data objects. Although some methods are described below, those skilled in the art will appreciate that there are other methods for generating characterization information that may be employed without departing from the scope of the present disclosure. In one embodiment, server 151 transmits characterization information as an evaluation. It will be appreciated that the characterization information may be helpful to a user in deciding whether to install an application. For example, if the user considers downloading a game, but the user receives an assessment indicating that the game has the capability to send the user's location to the internet, the user may decide not to install the game. In another example, if a user is considering downloading an instant messaging application and is concerned that the application may use an unequal amount of battery power, the user may receive an evaluation to learn an average amount of battery usage metrics for the application and decide, based on the metrics, that the application is acceptable for installation. In one embodiment, the characterization information may be consumed (consume) as input to one or more other analysis systems. For example, an analytics system that produces an assessment of privacy risks of an application may use the characterizing information to determine whether the application has the ability to risk, such as sending location or contact list information to an internet server.

A capability is a form of characterizing data that server 151 may generate. In one embodiment, server 151 extracts capabilities from data objects. In some mobile operating systems or application environments, an application may request granular rights for accessing privileged functionality on the device (such as sending or receiving network data, accessing the location of a phone, reading or writing contact entries, and SMS messaging). In one embodiment, server 151 uses data regarding the rights requested by the data object to determine the capabilities of the data object. The server may determine the rights data by a variety of means including metadata and behavioral data reported by the device, mart data, static analysis of data objects, and dynamic analysis of data objects. For example, applications on the Android operating system must assert permissions at install time, so server 151 may analyze the permissions of these assertions in an application package to determine permission data either directly via metadata reported by one or more devices about the application package or via mart data.

In one embodiment, server 151 performs an analysis of the content of the data objects to determine what APIs on the device the data objects utilize. In one embodiment, API analysis may include searching a data object for a data sequence indicating an API call; analyzing specific libraries, functions, classes, or other imported data structures in the data object; analyzing dynamic link procedure calls; analyzing calls to local or remote services; statically analyzing the data object; dynamically analyzing the data object; and analyzing the behavior data reported by the one or more devices. In one embodiment, server 151 utilizes the extracted API call information to determine that an application has particular capabilities. For example, if the application calls an API for interacting with a GPS radio on the device, server 151 determines that the application has the capability to determine the location of the device. While such analysis may detect the majority of the APIs used by data objects, it is possible that advanced self-modifying code may prevent a thorough analysis of the data objects. In one embodiment, server 151 detects whether the code is or may be self-modifying. The ability of a data object to modify itself may indicate that the data object is at a higher risk than a simpler, direct data object. Although many instances of malware on PCs use self-modifying code to hide from the anti-malware system, copy protection systems also often encrypt code to prevent unauthorized access; thus, self-modification may not be sufficient in itself to classify a data object as malicious, it may be used by the analysis system to generate an evaluation for the data object in addition to other characteristics, such as behavioral data.

In one embodiment, server 151 analyzes the behavioral data to determine capabilities for the data object. For example, server 151 may look for data objects to make phone calls, send SMS messages, access the internet, or perform other actions indicative of particular application capabilities. In some cases, it is important to understand not only which individual functions a data object utilizes, but also whether applications exchange data between APIs. Applications that use the internet, for example, and can read the device's contact list can have a number of capabilities that have significantly different risks. Simply using the internet, for example, to check for updated address book applications has less privacy risks than an address book application that reads contacts and sends those contacts to the internet. In one embodiment, server 151 analyzes data objects to determine whether there is a code path to send data returned or generated by one API or service to another API or service. For example, server 151 may perform taint tracking between two APIs to determine whether an application is transferring data between the APIs. For example, server 151 may determine whether there is a code path in the data object through which data returned by any calls to the contact API on the device may be provided to any network API on the mobile device. If such a code path is available, server 151 determines that the data object has the ability to send contacts to the Internet. Having such a capability may be more valuable during further analysis by server 151 or the user than simply knowing that the application accesses the contact and that it accesses the internet. Many applications may use two rights; fewer applications may actually send contact data to the internet, however. A user or automated analysis system would be able to use the ability to know there is a code path between two APIs as a much stronger capability indicator than a less granular capability measure.

In one embodiment, server 151 runs data objects in virtual (e.g., emulated or simulated) or physical devices and analyzes the behavior of the data objects at run-time. In one embodiment, a virtual or physical device is instrumented so that it reports behavioral data for data objects. In one embodiment, server 151 analyzes network traffic, calls, and SMS messages for virtual or physical devices. For example, a virtual device may be configured to always report a specific location via its location API that is unlikely to occur in any real-world situation. Server 151 can determine whether a data object is attempting to report the location of the device to the server by analyzing the device's network traffic for various encodings of the location, such as binary double encoding, radix 64 encoding, and literal encoding. In one embodiment, server 151 checks for a difference in the state of a virtual or physical device before a data object is run on the device and after the data object has been run. For example, a data object may utilize a kernel on the device on which it is installed in order to install an invisible rootkit. In this case, the virtual device may be aware of substantial differences in certain memory segments, such as in the system call dispatch table, that should not change under normal circumstances. In one embodiment, the physical or virtual device has custom root certificate privileges in its list of trust certificates, and server 151 uses the server certificate signed by the custom certificate privileges to intercept all TLS traffic and proxy the traffic to its original destination. Since the device has custom certificate privileges, the data object is able to establish a valid TLS connection through server 151 and all encrypted traffic can be analyzed by server 151.

In addition to the capabilities of the data objects, it may also be important for server 151 to collect metrics relating to the effect of the data object running on the device or its use of the capabilities on the device. For example, network data, email, or SMS messaging overuse may be considered an abusive or malicious or exploitable application. In one embodiment, server 151 analyzes application data from many mobile communication devices, such as metadata and behavioral data, device data, and other data it has, which can be used to generate metric data characterizing data objects. For example, server 151 may determine how much battery usage an application requires on average for all devices or for a particular device type, how much data a data object sends over any network interface or over a cellular ratio to a Wi-Fi network interface, how many email messages or SMS messages a data object sends, how many phone calls an object makes, and other metrics.

Server 151 may generate other characterizing information from information already described above, which may assist in further analysis by server 151 to generate an assessment or may be exposed directly by server 151. In one embodiment, server 151 analyzes the network traffic information associated with the data object to generate network characterization data, such as a list of servers to which the data object has been connected, ports and protocols on those servers with which the data object is in communication, how much data is transmitted to and received from each server. In one embodiment, the network characterization information includes what proportion of devices running a particular data object are connected to each server. An application, for example, connected to an IM server or to a known malicious bot command and control server, may connect to only one or a small number of servers on all the devices on which it is installed; however, a web browser or application that allows a user-specified connection may connect to a large number of different servers on different devices. In one embodiment, if a data object connects to many different servers, server 151 notifies one or more devices not to aggregate network behavior data for the data object to minimize unnecessary data reporting. In one embodiment, network traffic information is collected as behavioral data from mobile communication devices or is collected by server 151 running data objects on virtual or physical devices.

In one embodiment, server 151 determines whether the data object causes mobile communication device 101 to access the malicious Internet or other public or private network. For example, data objects that cause a mobile communication device to access a malicious website may subject the device to exploitation. One embodiment of the present disclosure allows for resolving a transmitted internet or intranet address (e.g., URL) to determine if the address will direct the mobile communication device to a secure website rather than a nefarious website or a phishing geist. This information may be stored as it relates to a particular data object.

In order for a user to apply application policies to a mobile device without having to make separate decisions for each individual application, it may be helpful to categorize the applications so that the user can simply decide which application categories to allow or deny. In one embodiment, server 151 uses the available data it has, such as application data, device data, mart data, and characterization data, to classify the data object. For example, if characterizing the data object as calling a location API on the mobile communication device, server 151 may classify the data object as a map or other location-based application. In one embodiment, the categories may map directly to capabilities, such as an application that reads your contact list or an application that can send your location to the internet. Other example categories include whether the data object transmits any information from the contact list of the mobile communication device, whether the data object causes other data, such as the phone number of the device, to be transmitted by the mobile communication device, and other actions that may affect the privacy security of the mobile communication device. In one embodiment, server 151 uses the metric data for the data object to classify it. For example, a server may have a heavy battery user category that includes data objects that typically use more than 10% of the device's battery. Since the categorization may depend on the device data in addition to the characterization data, the battery-waste category may depend on what device type the evaluation is for. For example, more than 10% of the data objects using the battery of one device may use only 5% of the battery of another device.

In one embodiment, server 151 may infer classification information if the data object does not directly provide such information. For example, server 151 may determine that the data object is an IM application if the data object is in communication with a known instant messaging server. For example, applications connected to servers belonging to a popular social network may be classified as social networking applications during analysis, applications connected to known malicious IRC servers may be classified as malicious bots, and applications that drain the battery of one or more devices may be marked as battery consumers.

Since the categorization of an application can be subjective and difficult to determine automatically, it may be desirable to have one or more people within an organization or as part of a collaborative community work determine a category for the application. In one embodiment, server 151 exposes an interface through which a user may suggest categories for data objects. For example, server 151 may define categories of applications that are not suitable for children, with content that includes pornography or violence. In this example, one or more users check in to a community voting system provided as a web application in which they can search and browse all applications known to server 151. The device-reported application data and bazaar crawls may populate an application list. Each application may have a page in which the user may select the categories they recommend for that application. In one embodiment, the user interface shows information about the data objects, such as aggregated application data, characteristics for the data objects, and other information available to server 151 so that the user can make decisions based on the analysis output. In one embodiment, the user interface allows the user to select from a list of categories, add a new category, and add tags for the data object. In one embodiment, the user interface has a discussion component so that one can discuss the appropriate categorization for the data object. In one embodiment, a voting system by which a user may select their preferred category for an application may determine the category for the application, with the most user selected category being the authoritative category for the application. In one embodiment, a user interface is displayed on a mobile communication device, displays a list of data objects installed on the device, and allows a user to suggest categories for those data objects.

In one embodiment, server 151 processes the application data and device data to determine distribution data for the data objects. The distribution data may include how widely a given application is currently distributed, what the increase in the distribution of the application has been in the period of time that the application has been available, what client population, such as geography, has installed the application, and other prevalent functions of the application among the group of mobile communication devices. For example, server 151 may check how many mobile communication devices report that a data object has been installed at the current time to determine how prevalent the application is. In one embodiment, server 151 uses the distribution data to determine the trustworthiness of the data object or to analyze the data object for risk, as discussed below. For example, applications that have been installed on many devices for a long period of time without being uninstalled may be less risky than applications of a new brand and installed on only a few devices.

Since server 151 may encounter legitimate applications in development and therefore not widely distributed, one embodiment of the present disclosure involves server 151 identifying which applications may be in development, thereby preventing them from being classified as undesirable in an anti-malware or other system. Server 151 may receive application data for a data object indicating that the data object has characteristics inherent to the application under development, such as debugging symbols, debuggable rights or flags, links to debugging libraries, and other characteristics. Applications in development may also have low or isolated profiles. If server 151 identifies that the application is in development, it may store an indication that the application is deemed to be in development and use that indication to prevent server 151 from evaluating the application as suspicious or undesirable or to reduce the likelihood that the server will reach such an evaluation. In one embodiment, server 151, in determining whether a data object should be considered "under development," considers previous data objects encountered by the device that encountered the data object in question. If a device frequently encounters a data object under development, server 151 is more likely to classify the data object as under development. If a device encounters a data object under development less frequently, server 151 is less likely to classify the data object as under development.

In one embodiment, server 151 establishes a reputation or level of trust for the data object. In one embodiment, a level of trust is determined manually or automatically and assigned to a single data object, multiple data objects that are part of an application, multiple versions of an application, or for all applications from a given developer on one platform or multiple platforms. In one embodiment, server 151 stores trust data on a server or in data storage 111 so it can be used directly at a later time or as part of generating an assessment.

In one embodiment, trust is approved for an application via a manual review process. For example, if server 151 considers an application to be risky based only on its capabilities (e.g., having access to private data and/or utilizing sensitive APIs), a user viewing the evaluation may choose not to download it even if the application is viewed well. To address this issue, manual review may assign a trust rating to the application. If the application is deemed trustworthy by the review, the reporting application is assessed as risk-free; however, if the application is determined to be suspicious at review, the evaluation may continue to report the application as risky. Since a reputable application may be composed of multiple data objects, may be updated with new data objects, or may have versions for multiple platforms, it may be important to allow trust ratings to span multiple data objects, applications, and even platforms so that no manual review needs to be done for each version or file that is part of the application. Similarly, since many reputable software sellers may produce multiple applications that may be assumed to be trustworthy, it may be desirable to automatically approve high trust levels for data objects identified as originating from those sellers. In one embodiment, server 151 approves a high level of trust for a data object if the data object can be attributed to a trusted seller or trusted application through data available to server 151, such as a cryptographic signer, package name, or mart metadata for the data object.

In one embodiment, server 151 uses the distribution data and application data to establish trust for the application. For example if popular applications are installed on millions of mobile communication devices, such asMaps and having multiple previous versions of the application that all have the same cryptographic signer and similar distribution characteristics, then subsequent versions of the application having that cryptographic signer will be considered to have a high level of trust. If server 151 encounters a web page with a popular application, such asAnother application with a same name for Maps, installed on only a few devices, and using different cryptographic signers, server 151 may grant a low level of trust to the low distribution application. The anti-malware system may use such data indicating that the data object has low trust to automatically evaluate the data object as undesirable or mark it for manual review. In thatIn one embodiment, trust data for an application may take into account associated applications, such as applications determined to be created by the same developer on the same platform or on different platforms. For example, if a company produces an application for one mobile platform with a large number of users and a good rating and the company publishes a new application on a different platform, it may be given a high trust rating based on its association with the first application.

In one embodiment, server 151 analyzes the application data to determine whether the data objects are part of the mobile communication device operating system or preloaded by the manufacturer or developer. In one embodiment, if server 151 determines that the data object is part of a mobile operating system or is preloaded, a high level of trust is automatically granted to it.

In one embodiment, server 151 analyzes user-generated ratings and reviews for applications, such as ratings and reviews collected by application marketplace data collection system 1005. For example, server 151 may use the ratings and reviews to determine a trust rating for the application. If the application has a low rating and negative comment indicating that the application "crashes" or is otherwise "bad," server 151 assigns a low trust rating to the application's comment based on the reputation indicated in it; however, if the application has a consistently high rating and many reviews, server 151 assigns a high trust rating to the application. In another example, server 151 uses ratings and reviews as subjective application quality indicators for use in generating an assessment for an application. If the application has a significant number of reviews with text indicating that the application is "battery drained" or "battery drained," server 151 determines that the application has a reputation for producing adverse battery effects and produces an evaluation of the application indicating this.

In one embodiment, the server exposes trust data to third parties via an API. For example, a trusted application may be considered an observed authentication. In one embodiment, the trust level exposed by the API is binary (e.g., trusted, untrusted), obfuscated (e.g., 86% trusted, 11% trusted), or by category (e.g., fully trusted, malicious, suspicious, semi-trusted). The mobile application marketplace may wish to display an indicator of this authentication on the application download user interface as a signal that the application has good reputation. In this case, the server 151 may expose an API through which a third party may supply the data object or identification information for the data object, such as a hash identifier, a package name, or a cryptographic signer. After receiving the data object or sufficient information to identify the data object, server 151 responds with an indication of whether the data object is considered authenticated. In one embodiment, the response is an image indicating whether server 151 believes the data object is authenticated. In one embodiment, the response contains a hyperlink to server 151 by which the user can verify that the authentication for the application is authentic. In one embodiment, the webpage that the hyperlink references shows additional information about the application, such as why it is considered trusted or untrusted (e.g., by manual review, distributing data), what permissions the application requests, the properties and capabilities the application has, and comments about the application during manual review.

Using data collected by server 151 or from the analysis system described herein, the server may generate an evaluation (block 1113, FIG. 11). After generating the evaluation, server 151 may store the evaluation of the data object so that it may be retrieved at a later time (block 1115). The server may then transmit an evaluation for the data object (block 1117). For example, the server may publish an evaluation on an application provider website, provide the evaluation in the form of a searchable report, transmit a notification to the mobile communication device, transmit a virus signature containing such an evaluation that a given data object is known to be good or known to be bad, and transmit a response to an API call that queries the evaluation of the data object. Such information may be in readable text, machine readable format, or may include "scores", badges, icons, or other symbolic ratings. Those skilled in the art will appreciate that other scenarios are possible in which server 151 transmits an evaluation for a data object without departing from the scope of the present disclosure.

In one embodiment, the assessment data includes output from the analysis system, such as characterization data, classification data, trust data, and distribution data. For example, the evaluation for the data object may include (alone or in addition to other information) the detected capabilities for the data object, the average battery usage for the data object, the average number of SMS or email messages sent by the data object, the most common server to which the data object connects, the average amount of network data for the data object, and the trust rating for the data object. It will be appreciated that the above-described assessment data can be provided as input into server 151. For example, a network operator or enterprise may operate a server that generates evaluation data and feeds back the data to a master server. In another example, a user may determine the evaluation data and provide it to server 151 via an interface, such as a web application. In this case, the user may provide subjective trust data, risk ratings, categorizations, or other assessment data that the server may use. In one embodiment, server 151 combines evaluation data received from multiple sources to produce an aggregate evaluation. For example, if a malware author attempts to transmit an assessment to server 151 indicating the security of a malicious application in the arms of a desire to have server 151 produce a false assessment, the server may utilize multiple unique sources that provide the assessment and the trustworthiness of those sources to produce an aggregate assessment. If one hundred evaluations are received from different reliable sources, such as network operators and enterprises, indicating that the application is malicious, but ten thousand evaluations from a particular unauthenticated source indicate that the application is secure, the server generates an aggregate evaluation indicating that the application is malicious.

In one embodiment, the evaluation data generated by server 151 includes one or more ratings for the data objects. For example, the evaluation for the data object may include a rating of server 151 for the privacy of the data object that considers whether the application has the capability to send location data, contact data, SMS messages or files from the device to the server. In another example, the evaluation for the data object may include a rating of server 151 for the security of the data object that considers whether there are any known vulnerabilities for the application, whether the application is listening to network connections on any ports, whether it satisfies a security coding guideline, what the level of trust of the application is, and whether there are exceptions in the application (e.g., stealth code, decrypted code, structural exceptions). In another example, the evaluation for the data object may include a rating of server 151 for the battery impact of the data object that takes into account the device reported battery usage data, such as an estimated number of minutes of phone battery life reduction. In another example, the evaluation for the data object may include a rating generated by server 151 for the performance of the data object that takes into account the average CPU usage of the application and the frequency with which the application has not responded to user input events. In another example, the evaluation for the data object includes a quality rating generated by server 151 that takes into account application collapse frequency, user reviews, user ratings, and average time to keep the application on the device. In one embodiment, server 151 provides multiple ratings as part of one evaluation to provide information about data objects along multiple dimensions. In one embodiment, the evaluation may be binary (e.g., good, bad) or ambiguous (e.g., 100%, 90%, 10%). In one embodiment, multiple ratings may be combined into an overall rating.

In one embodiment, server 151 processes multiple data sources available to server 151 to generate ratings for data objects. For example, server 151 may utilize application data, device data, characterization data, trust data, distribution data, and user-supplied data to determine whether an application is malicious. The server may utilize a variety of systems or models available at the server that apply to the data to generate the evaluation. For example, generating an assessment of whether a data object is malicious may involve a malware detection system that includes a heuristic engine that analyzes characteristic data to identify behavior of potentially malicious data objects. Some example heuristics include detecting whether a data object utilizes any capabilities for circumventing detection by hiding from an application enumeration system on the OS on which it is installed, whether an application attempts to modify itself, whether an application has capabilities associated with known spyware, and whether an application connects to a known malicious server.

Those skilled in the art will appreciate that the analysis portion performed at server 151 to produce the assessment can be viewed as extracting features for the data objects, and another analysis portion can be viewed as applying a model to those features to produce a useful assessment; thus, a variety of systems, such as artificial intelligence systems or algorithms, may be applied to process features for data objects to achieve a desired form of rating and evaluation.

In one embodiment, server 151 generates multiple evaluations for data objects that take into account different device data or configuration information. For example, if server 151 is configured to generate an evaluation of whether a data object will work correctly, and if a data object fails when installed on one type of device, but works correctly when installed on another device type, then the server may generate two evaluations for the data object. If server 151 has an API through which mobile communication device 101 can request an evaluation for a data object when given identification information for the data object and the mobile communication device has sent device data to server 151, server 151 can provide an evaluation for the data object corresponding to the device requesting the evaluation. If the device 101 in which the data object is to fail requests an evaluation, server 151 will return an evaluation indicating the failed behavior of the data object on that device 101. If device 101, where the data object will work correctly, requests an evaluation, server 151 will return an evaluation indicating the behavior of the proper work on that device 101.

In one embodiment, the evaluation indicates whether the data object is allowed to run on the device when given the policies set by the administrator. If multiple policies are configured on server 151 and data store 111 stores which policy is to be applied to device 101, a given data object may have multiple evaluations that depend on the policy of the device being evaluated in question. For example, if a device with a strict privacy policy requests an evaluation for an application that may share the user's location, server 151 transmits an evaluation indicating that the application is not allowed. If a device with relaxed privacy policy requests an evaluation for the same application, server 151 transmits an evaluation indicating that the application is allowed. In one embodiment, the assessment data is not stored and only the information used to generate the assessment, such as application data, device data, distribution information, characterization information, trust data, and classification information, is stored and the assessment is performed by applying the policy to the stored information upon request.

While automated analysis systems can produce acceptable results most of the time, there may be situations where manual analysis overrides automated analysis results. In one embodiment, server 151 stores results of the manual analysis for the data objects and transmits the results of the manual analysis as an evaluation. For example, server 151 may classify an application as a social networking application based on its behavior data; the application may actually be a word processing application that allows users to post notes to a social network. In this case, a user or administrator may override the categorization for the data object, server 151 stores the categorization and transmits it in response to requesting an evaluation of the data object. In another example, the anti-malware system identifies data objects with certain characteristics as undesirable. It may also be desirable for a user to manually configure server 151 to treat particular data objects as undesirable. Server 151 stores a list of data objects deemed undesirable and returns an evaluation indicating that a data object is undesirable when an evaluation is required for one of these data objects.

Since it may be desirable for the evaluation on the data object to reflect the latest information available, in one embodiment, server 151 first generates the evaluation and then updates the evaluation if additional application data or device data becomes available or if the analysis system itself is updated. In one embodiment, if the data object is re-evaluated (e.g., due to new application data, device data, or updated analytics system), server 151 stores the new evaluation 1111 and transmits it 1113. For example, after collecting application data and device data for a data object from ten devices, server 151 may generate an evaluation for the data object. Then if server 151 receives device data and application data from one thousand more devices, it may reanalyze the data objects as new data to produce new evaluations for the data objects. If the updated evaluation is substantially different from the first evaluation, server 151 may perform an action, such as notifying a device or user.

C. Anti-malware system

In one embodiment, the server 151 and the mobile communication device 101 are configured to work together to prevent malware or spyware from adversely affecting the mobile communication device. Since mobile communication devices are limited in memory, processing power, and battery capacity, it may be desirable for server 151 to perform analysis, such as the analysis described herein, to determine whether an application is considered malware or spyware, rather than performing the analysis per device. In addition, it may be desirable for the server to store the results of the analysis so that if multiple devices encounter the same application, the analysis need not be repeated. Further, it may be desirable for server 151 to aggregate data regarding potentially malicious applications using the data aggregation system described herein in order to provide data from a variety of sources for use by the analysis system.

In one embodiment, when mobile communication device 101 evaluates a data object, such as an application package or executable file, to determine whether the data object is malicious or otherwise undesirable, the device sends a request for evaluation of the data object to server 151, the request containing identification information for the data object. In one embodiment, the request transmitted by the mobile communication device 101 contains application data for the data object for use by the server in performing the evaluation. For example, in addition to transmitting identification information, such as the package name and hash of an application, the mobile communication device may additionally transmit the rights requested by the data object and information determined by the device by performing static analysis, such as a list of utilized APIs.

In one embodiment, the mobile communication device 101 collects metadata for data objects by using tools and potentially additional processing provided by the operating system. For example, the Blackberry and Android platforms provide mechanisms by which an anti-malware application can query a list of packages installed on a device. Each platform also provides a method for querying additional information about the package, such as cryptographic signature information and information about how the package chooses to integrate with or expose them to the operating system.

In another example, mobile communication device 101 can extract features from the data object to assist server 151 in generating the assessment. In one embodiment, the mobile communication device 101 performs static analysis on the data objects to extract application data for transmission to the server 151. For example, on Android, a device may parse an executable portion of an application package, commonly referred to as a "classes. The device may extract a list of inter-process communication calls, performed directly or indirectly by the executable file, using a "binder" mechanism, and transmit information about the calls to server 151 for use in analyzing the application package.

In one embodiment, server 151 may analyze the data objects immediately or may need to collect additional information using a process, such as the processes disclosed herein. After generating the assessment for the data object, the server transmits the assessment to the mobile communication device 101. In one embodiment, the evaluation includes an indication of whether the data object is considered undesirable. For example, server 151 may transmit one of three evaluations, known good, known bad, and unknown. If the server determines that the data object is known to be good (e.g., because it has a high level of trust), it will return an assessment that the data object is known to be good. If the server determines that the data object is known to be bad (e.g., because it is determined to be a piece of malware), it will return an assessment that the data object is known to be bad. If the server does not have enough information to make the determination, it will return an assessment that the data object is unknown. In one embodiment, a risk level containing the data object or a confidence level of a known good or known bad assessment is evaluated, so that the mobile communication device or its user can use the risk or confidence level to determine how to classify the data object.

In one embodiment, the evaluation transmitted by server 151 to mobile communication device 101 contains information as to why server 151 determined the data object to be undesirable. For example, the server 151 may transmit a name that determines the malware family to which the data object belongs, or the server may transmit an HTTP URL that references the server 151 that the mobile communication device 101 may use to display additional information about the data object, the URL containing an identifier that the server 151 decodes to allow it to retrieve stored information about the data object. The web page may display additional information, such as output from different analysis systems used to generate the assessment. For example, a web page may display distribution information for data objects, information about common servers to which the data objects connect, information provided by human analysis of the data objects, trust data associated with the data objects, information about the geographic distribution of the data objects, information about similar data objects, and information about the author of the data objects.

It may be desirable to minimize the requests for evaluation of data objects that mobile communication device 101 needs to send to server 151, so that the device minimizes the amount of data it transmits and receives, reduces the time required to access data objects, optimizes battery consumption, and minimizes the load on server 151. In one embodiment, mobile communication device 101 maintains a local cache of evaluation information received from server 151. The local cache may be stored using a lightweight database, such as SQLite, or in a proprietary binary file format optimized for evaluation storage. For example, the cache may contain an indication as to whether the data object is undesirable, a risk level associated with the data object, and defining information, such as identification information for the data object. As the device scans the data object, it may look up the identification information of the data object in the local cache. If the evaluation for the data object is cached, the evaluation is used. If the evaluation is not cached, the device retrieves the evaluation from server 151. In one embodiment, when a mobile communication device inserts an evaluation for a data object encountered on the device into its cache, it generates definition information for the data object. For example, the device may use a hash of the content of the data object to ensure that it caches the evaluation results from the server. In one embodiment, server 151 transmits the definition information along with the evaluation so that the mobile communication device can apply the evaluation to the appropriate set of applications. For example, in some cases, server 151 may indicate that the evaluation applies only to a particular data object identified by a hash of its content, while in other cases, the server may indicate that the evaluation applies to all data objects signed with the same cryptographic key.

In one embodiment, the mobile communication device 101 stores a defined local cache for known good data objects and known bad data objects for use by an identification component (described below) operating on the mobile communication device. Using the identification component, the mobile communication device can determine an evaluation for the suspect data object if the local cache contains a definition corresponding to the suspect data object and a corresponding evaluation. For example, the definition may use criteria such as hash identifiers, package names, and cryptographic signers to match the data object. Each definition may have a corresponding rating (e.g., "good", "bad"). If the definition matches the suspect data object, the evaluation of the definition may be for the suspect data object. If no definitions correspond to the data object, such as identifying the data as safe or unsafe, the mobile communication device 101 may transmit the application data for the suspect data object to the server 151 for more comprehensive analysis.

In one embodiment, the cache serves as the primary storage for anti-malware definitions that determine whether anti-malware on mobile communication device 101 will identify a data object as malicious without querying server 151. In one embodiment, definition information used by the identification component on the cache storage device is cached. For example, the cache may contain defining information such as a package name, cryptographic signer, byte sequence, pattern, or logic to match a data object on the device with the cache's evaluation. If the cache contains an entry linking a particular byte sequence to an evaluation for a malicious application and a data object on the device containing the byte sequence, the device will determine that the data object is malicious without contacting server 151. In one embodiment, the cache contains only definition information, all definitions corresponding to a single evaluation of the data object as malicious. In one embodiment, the cache may contain evaluation information that may contain an identifier as discussed above, which may be transmitted to server 151 for the device to retrieve the information for display to the user. Such an identifier used to retrieve data from server 151 allows the cache to minimize the information it stores about potential malware. In one embodiment, the device cache serves as both a white list and a black list. The cache contains definition information for known good and known bad data objects such that if a data object is determined to be known good or known bad, the device need not request an evaluation from server 151, in one embodiment the cache, which serves as both a blacklist and a whitelist, is used by an identification component on the mobile communication device to determine whether the data object is identifiably bad or identifiably good. If the data object encountered by the device is neither recognizably good nor bad based on the definition data stored in the cache, the device may transmit application data for the data object to server 151, so the device may receive an evaluation for the data object from the server. In one embodiment, anti-malware on a mobile communication device is installed with pre-populated caches defined as follows, the device modifying these definitions when it receives a new evaluation or a stored evaluation is deemed invalid.

In one embodiment, the evaluation and definition of the cache on the device is deemed valid only for a period of time, so that the mobile communication device is not dependent on potentially stale data. In one embodiment, the cache's evaluations and definitions are stored indefinitely and treated as valid without time constraints. In one embodiment, the device stores only certain types of evaluations and definitions. For example, the device may cache only known good evaluations or may cache only known bad evaluations. In this case, definitions are only stored if they have a corresponding evaluation. In one embodiment, the cached portion is stored in volatile storage, such as RAM, and the cached portion is stored on non-volatile memory, such as flash memory. Since volatile memory is typically more limited and faster than non-volatile memory, the device may store frequently accessed assessments and definitions in volatile memory and less frequently accessed assessments and definitions in non-volatile memory. For example, if an anti-malware system analyzes data objects each time they are opened, it may be desirable to quickly determine an evaluation for data objects if they have been recently scanned and have not changed. By storing recently used definitions and evaluations in volatile memory, the device can quickly recall previous evaluations.

In one embodiment, server 151 transmits cache control information with the assessment indicating whether the device should cache the assessment and, if so, for how long. For example, server 151 may transmit an evaluation for popular applications from reputable companies that includes cache control information indicating that the device should cache the evaluation. If server 151 transmits evaluations for fewer known applications, it may include cache control information indicating that the device should not cache evaluations, as applications may become undesirable in the future when more are known about it. In one embodiment, server 151 determines cache control information based on the evaluated confidence level. For example, a known good evaluation for an application with a high trust level may be considered highly trusted, while an evaluation indicating that the application is unknown due to lack of data available to the server may not be considered trusted. In one embodiment, upon expiration of an assessment, cached definition information associated with the assessment also expires.

Since the evaluations of the retrieval cache are faster than the retrieval of the cache from server 151 (thereby minimizing the latency and overhead associated with determining whether the data object is malicious), it may be desirable to maximize the number of evaluations that may be determined locally from the cached data. In one embodiment, the server transmits the assessments to the mobile communication device without the device requesting the assessments, and the mobile communication stores the assessments in its cache. Since all evaluations available to the server 151 may require more storage than is desired on the mobile communication device 101, the server may transmit only a subset of its available evaluations. In one embodiment, server 151 determines which assessments to transmit to mobile communication device 101 by analyzing device data and application data. For example, server 151 may store the operating systems associated with evaluations for data objects that are compatible with the data object in such a manner that the server may query all evaluations related to a given operating system. Server 151 may then transmit to the mobile communication device only an evaluation of data objects that are compatible with the operating system on which the device is running. No other assessments are transmitted to the device because the data objects referenced by the other assessments cannot run on the operating system of the device. In another example, the server may use the country, language, or region code of the device to determine what assessment to transmit to the device. Just as russian users are unlikely to download spanish language applications, american users are unlikely to download russian language applications.

In one embodiment, server 151 stores which assessments it has transmitted to the device and which the device has successfully received, thereby retransmitting the assessments unnecessarily. If the device has not accepted the desired assessment, the server transmits the assessment the next time the device connects. To efficiently track which assessments a device has received, server 151 may group the assessments so that a given device receives all of the assessments in one or more groups. For example, a given evaluation group may have multiple changes per day (e.g., access to new data objects, change existing evaluations); however, the device may be configured to receive updated assessments only once per day. To determine what assessment to transmit to the device, the server may record the time when the device has last received the latest assessment for the group and only check for changes to the group since the device has last received the assessment. For example, if a device receives all assessments for a given group on monday and adds two new assessments to the group on tuesday, then if the device connects on wednesday, the server need only query what assessments have changed in the group since together on the week and will determine that it needs to transmit only the two added assessments. In one embodiment, the server utilizes a push service, such as the push service described herein, to alert the device that the server is ready for additional evaluations of transmissions to the device. When using such a push service, all devices receiving an evaluation from a group can be updated with the latest evaluation nearly immediately when the server updates the evaluation as part of the group.

There are a variety of ways in which server 151 may group assessments for selective transmission of the assessments to the devices. For example, there may be more evaluations for data objects compatible with a given operating system than are desired to be stored on the device. In this case, the server may generate an evaluation group corresponding to the most prevalent data object based on distribution data or market data available to server 151. In this case, the device will cache an evaluation for the data objects that they are most likely to encounter. It is also possible to further increase the likelihood that a device has an assessment cached for the data objects it encounters by analyzing application data available at the server corresponding to data objects previously encountered by the device and predicting what data objects the device may encounter in the future based on those previous encounters by server 151. The evaluation for those possible data objects may then be transmitted to the device.

Since the optimal amount of assessment data to be cached on a device may vary depending on the hardware of the device, user behavior, or user preferences, it may be desirable for the amount of data to be tunable. In one embodiment, the server 151 determines the amount of evaluation data to be cached on the mobile communication device 101. For example, server 151 may check the amount of storage available on the device, the frequency with which the user downloads the application, and how likely additional cached assessment data will reduce the number of required assessment requests transmitted by the device. If the device has a large amount of available storage and its user downloads a large number of applications, the server may determine to cache a large amount of evaluation data; however, if the device has little available storage and its user rarely downloads the application, the server may determine to cache only a small amount of data or not to cache the data. The server may also examine previous evaluation requests made by the device to determine whether the device caching the additional evaluation information may have avoided those requests. For example, if the device currently receives evaluations that belong to a particular application group and the server evaluates whether the device should receive evaluations for additional application groups, the server checks previous evaluation requests to determine how many of those evaluations are in the second group. If server 151 determines that enough of the evaluation requests will have been avoided, it will begin transmitting evaluations from both sets to the device. In one embodiment, the user may control the amount of storage that will be allocated to the evaluation of the cache on the mobile communication device 101.

It may be desirable for server 151 to report that it has no assessment yet rather than always producing an absolute assessment (e.g., known good or known bad). In one embodiment, server 151 transmits an evaluation for the data object that indicates that the undesirability of the object is unknown. When mobile communication device 101 encounters a data object, it transmits a request for an evaluation to server 151 and receives an unknown evaluation, the device temporarily trusts the data object and retries the request for an evaluation at a later time. To avoid unnecessary requests, the device increases the time delay between retries if it continues to receive unknown evaluations. During such a temporary trust period, the device does not retransmit the evaluation request each time it scans a data object. For example, in an anti-malware system on a mobile device designed to scan files on a file system when they are accessed, first accessing a data object may cause the device to transmit an evaluation request to server 151. If the server returns an unknown evaluation, the device stores in its evaluation database a temporary entry indicating identification information for the data object, a time period for which the temporary evaluation and evaluation indicating that the data object is allowed, is valid.

In one embodiment, server 151 transmits information about the data object in an unknown evaluation, and mobile communication device 101 uses the data evaluation from server 151 as input into a local analytics system. For example, mobile communication device 101 may have a heuristic system that analyzes the content of a data object to determine if it is malicious. In the event of a known good or known bad result from server 151, the device then either does not run the heuristic system or discards the result from the heuristic system. If server 151 returns an unknown result that includes a level of trust for the data object, device 101 combines the result from the heuristic system with the level of trust provided by the server to determine whether the data object is considered undesirable. For example, mobile communication device 101 may scale the results from the local analysis based on the trust level reported by server 151. If the heuristic system on the device determines that the data object is at 66% risk and the unknown evaluation from server 151 indicates that the data object has a suspect 1% level of trust, then the device determines that the data object is undesirable; however, if the unknown evaluation from server 151 indicates that the data object has a 70% level of trust, then device 101 determines that the data object is desirable.

In order to respond to undesirable applications, such as malware and spyware, once they are identified as undesirable, it may be desirable for server 151 to transmit a notification to mobile communication device 101 of data objects that were determined to be undesirable after being previously classified as good or unknown. In one embodiment, server 151 stores information about data objects encountered by mobile communication device 101 so that if a data object encountered by a device is evaluated as good or unknown, but is subsequently determined to be undesirable, server 151 can determine all devices that have encountered the data object and transmit a notification indicating that the data object is undesirable. In one embodiment, server 151 sends a notification to device 101 only if the data object that is the subject of the notification can operate on the device's operating system. For example, if the device runs Blackberry and encounters an Android spyware application, server 151 will not transmit a notification to the device; however, if the device encounters the Blackberry spyware application, the server 151 will transmit a notification. As disclosed herein, it may be determined whether a data object may run on a given device by analyzing device data for the device and application data for the data object.

In one embodiment, the notification transmitted from server 151 to device 101 is designed for consumption by the device and includes both identification information and correction information for the data object. For example, the notification may utilize a push service provided by the platform seller and include a package name and a content hash for the data object. The notification may also specify corrective actions, such as "killing" any processes that contain the data object, requesting the user to unload the data object, and deleting the object without user intervention. In one embodiment, the notification includes information about the data object for display to the user, such as corrective instructions, a description for why the data object is considered undesirable, or a request to take a particular action. In one embodiment, the notification is in the form of a human-readable message, such as a text message, an email, or a telephone call. It may be desirable for the server to perform both human-readable and machine-readable notifications to ensure that the user responds to the threat data object. For example, the server may transmit an email message to the user and send a notification for the device to remove the data object without user intervention.

In one embodiment, mobile communication device 101 contains a database of all data objects present on the device, and server 151 transmits updated signature data to the device when data objects encountered by the device are determined to be undesirable. When the device receives the updated signature data, it compares the updated signature data with the data objects present on the device. If any object present on the device is deemed undesirable by the updated signature data, the device immediately initiates corrective action without waiting for the next scan of the data object.

If the anti-malware system performs an evaluation of a data object, it may be desirable to trust the data object as long as it has not changed to avoid having to re-evaluate the data object. In one embodiment, the mobile communication device 101 maintains a list of identified data objects that have been analyzed and deemed desirable. When it is desired to scan a data object, the device may first check this list to see if the data object is present. If the object is present, the device does not rescan the object. After scanning the file and determining that it is desirable, the device places an identifier for the data object in the list. Example identifiers include a file name, a file system node identifier, or an operating system specific data object handle. In one embodiment, the mobile communication device saves this list of data objects to non-volatile storage, so that the list can be preserved even if the device is rebooted or runs out of battery. When storing evaluations and accessing them at a later time, it is important that any stored evaluation is valid only for a particular set of data object content. If the content of the data object changes, a different evaluation may be necessary because the data object may have been modified to include malicious code that is not present in the original data object. In one embodiment, the list contains a cryptographic hash of the contents of the data object. When the device determines that the data object is deemed to be on the list, it compares the hash of the data object as stored on the device with the hash stored in the list. If the hashes match, the data object is considered to be on the list. In one embodiment, the anti-malware software may determine when to open and close files. If a file on the list is opened with write access, it is removed from the list. At the time of open write to a file, the file cannot be added to the list.

It will be appreciated that one embodiment of the present disclosure contemplates other ways to reduce network traffic while providing sufficient options for securing a mobile communication device. In one embodiment, the mobile communication device may request analysis of all data residing on the device ("scan") when the mobile communication device is first started or powered up or when an application responsible for monitoring mobile communications is first launched. This provides a baseline analysis of the security of the mobile communication device. Future scans may be performed when the mobile communication device accesses a new application or at preset time intervals or upon user request. The scanning may be adjusted based on access to the network 121. If connectivity is an issue, only newer data or suspect data may be accessed. The scan may be queued and performed as connectivity improves.

In one embodiment, the anti-malware system on the mobile communication device 101 has the capability to perform both on-demand and scheduled scanning of all data objects present on the device. If the anti-malware system utilizes server 151 to perform evaluations on data objects, it may be desirable to optimize the time required to perform a scan. Since network latency causes a delay between the time the device transmits the request for evaluation and the time the device receives the response from server 151, it may be desirable to pipeline the request in such a way that the device simply does not idle while waiting for the response. In one embodiment, the mobile communication device transmits a request to server 151 to provide an evaluation for a plurality of data objects, and server 151 transmits the evaluation for those plurality of data objects to the device. For example, during an on-demand scan, a device may be configured to enumerate all data objects on the device and then send a request to server 151 to evaluate all enumerated data objects. In another example, a device may enumerate ten data objects at a time, then send a request to the server and receive a request for those ten data objects before scanning for additional data objects. In another example, the device may enumerate data objects and transmit evaluation requests to continue the enumeration process without waiting for an evaluation response from the server. The device may only wait for a response when enumeration is complete.

In an anti-malware system that prevents loading or executing data objects until the system has reached deployment, it may be desirable to access the data objects before it needs to be loaded or executed. In one embodiment, the mobile communication device 101 proactively scans data objects and stores the results so that the device can reference the previous scan results when loading the data objects. For example, when a device loads a program that depends on multiple other files (e.g., an executable file linked to a shared library), the anti-malware system on the device may analyze the program to determine all libraries it depends on, send a request to the server 151 for an evaluation of the program and its dependent libraries, and then allow execution of the program to continue once the device receives a positive evaluation result. When the operating system of the device loads the library on which the application depends, no request to server 151 is needed, since the system already has the latest evaluation for the library. If the library is not proactively analyzed, the total load time for the program may be greater because the device may have to wait for multiple requests to server 151 to appear in series. In one embodiment, the software on the mobile communication device analyzes the data objects after they are downloaded, but before they are executed. For example, anti-malware on a device may monitor a download directory for new files or may simply wait to create, write, and then close a file. After the download is complete, the software may initiate a scan of the new file so that once the file is opened, the system has access to it and can call back the previous evaluation.

If the anti-malware system prevents a user-requested operation or system operation while it evaluates a data object, it may be desirable to give the user an indication that the evaluation is in progress, especially if the evaluation relies on a network connection that may have significant latency. In one embodiment, the anti-malware system on the mobile communication device 101 displays a user interface indicating that a data object is being scanned when the system scans the data object and blocks the operation requested by the user. For example, if the anti-malware system prevents the application from being executed until the application and all its dependent libraries have been accessed by inserting themselves into the application launch process, there may be a significant delay noticeable by the user of the device. The annoyance associated with the delay can be mitigated by informing the user what happens rather than the device simply appearing to be unresponsive. When a user launches an application, the device displays a user interface view indicating that the anti-malware system is accessing the user-launched application. In one embodiment, the user interface allows the user of the device to skip waiting for the scan to complete. For example, if the device's scan of data objects requires connection to server 151 and the user does not want to wait, the user may proceed without waiting for an evaluation return. If such an assessment that the data object is malicious is subsequently returned, the device may initiate corrective action, such as destroying any processes that contain the data object and deleting the data object, even if the data object is allowed to run.

The user may be interested in having the application accessed, but does not want to wait for a response from server 151. The user may choose to use the application prior to the full analysis and while waiting for the analysis results. In such a scenario, it would be helpful if the server 151 or the user's mobile communication device 101 could provide a temporary trustworthiness assessment prior to the formal analysis. The reports may be in the form of interface elements (interface elements), notifications, alerts, risk ratings, and the like. In one embodiment, mobile communication device 101 may run a local analysis to determine if the application is temporarily trustworthy. It may also be desirable to show information on the data object on the user interface indicating when the anti-malware system is waiting for an evaluation from the server so that the user does not accidentally ignore high-risk items. In one embodiment, the wait user interface shows the local analysis results while waiting for evaluation from server 151. For example, the user interface may show the capabilities of the data object or the risk score for the data object. In one embodiment, the device allows the user to skip waiting for evaluation from server 151 only if the local analysis determines that the data object is at low risk. The risk score may be calculated, for example, by analyzing what sensitive functions the data object accesses. Data objects that access the user's contact list and browser history may be considered more risky than data objects that do not access any sensitive functionality.

In one embodiment, the anti-malware system on device 101 determines whether it should wait for a response from server 151 before reaching a conclusion based on the context of the scan. Scanning, which occurs, for example, during system startup or in the absence of an active network connection, should not prevent waiting for a response from the server. To determine whether there is a network connection, the anti-malware system may rely on a variety of methods, such as querying the operating system for provided network interface state information and analyzing whether the request to server 151 has timed out. If the anti-malware system intercepts the system call, scans that occur due to the system attempting to execute the data object should be blocked while waiting for a response from server 151, while scans that occur due to the application obtaining information about the data object (e.g., the file manager extracting an icon for the data object) should not be blocked while waiting for a response. In one embodiment, if a request for data object evaluation cannot be completed, it is retried at a later time.

In one embodiment, the anti-malware system omits a server or part of the local analysis if an accurate assessment can be produced without additional analysis. For example, if the local analysis determines that the data object is risk free, the device may not request an assessment from server 151 — only if the scanned data object has a minimum risk as determined by the local analysis component on the device may request an assessment from server 151. In an example, the determination of whether to ignore waiting for additional results is determined by both the results and which system returns each result. "bad" results from local analysis before receiving results from server 151 may be sufficient to treat the data object as malicious; however, a "good" result from the local analysis may still require the system to wait for an evaluation from server 151 to confirm that the data object is good before determining the final placement.

In one embodiment, if multiple analysis systems produce different results, the anti-malware system on the device analyzes the results of the systems to make a determination regarding the final placement of the data objects that takes into account both what results are produced and which system produces each result. For example, the anti-malware system may determine that a single undesirable result is sufficient to mark the data object as undesirable. In another example, server 151 may be considered authoritative, or server 151 may communicate a confidence level of its evaluation so that device 101 may determine whether the evaluation is considered authoritative. In another example, known bad results from server 151 may be authoritative, but known bad results from a local analytics system on device 101 may override known good results from the server.

In one embodiment, server 151 stores a list of malware or other undesirable applications that have been detected on the device and are still active on the device. To populate this list, mobile communication device 101 sends events to server 151, including whenever it encounters an undesirable application, whenever it removes an undesirable application, and whenever it ignores an undesirable application. The event includes identification information for the data object so that server 151 can correlate the event with known data objects. For example, because a user may choose to ignore malware, it is important that the user be able to view his or her list of ignored malware to avoid situations in which a malicious user installs malware on someone else's phone and configures anti-malware software on the phone to ignore the malware to prevent the system from automatically removing it. In this situation, the legitimate user of the phone can tell that a piece of malware is active on his or her device, but is ignored. In one embodiment, since server 151 has data indicating whether device 101 currently has active malware, a network access control system that queries server 151 for the status of a given device may allow or deny network access to the device based on its malware status.

In one embodiment of the present disclosure, server-side or "cloud" analysis may be performed using a version of the three-component system described in U.S. patent application No. 12/255,621, which is incorporated herein in its entirety. An example of a three-component system is illustrated in fig. 9, and includes a first component 903, which first component 903 may be used to identify data that is secure or "known good" (also referred to herein as forming part of or included on a "white list"). The second component 905 can be used to identify data that is malicious, wasteful of device resources, or "known bad" (also referred to herein as forming part of or included on a "blacklist"). The third component 907 is a decision component that can be used to evaluate data that is neither known good nor known bad, i.e. "unknown". In one embodiment, the known good component 903 and the known bad component 905 can reside on the mobile communication device 101 and the decision component 907 can reside on the server 151. In one embodiment, the known good component 903, the known bad component 905, and the decision component 907 may all reside on the server 151. In one embodiment, portions of the known good component 903, the known bad component 905, and/or the decision component 907 may reside on the mobile communication device 101, and portions of the known good component 903, the known bad component 905, and/or the decision component 907 may reside on the server 151. In one embodiment, the known good component 903 and the known bad component 905 reside on the server 151, while the decision component 907 resides on the mobile communication device 101.

For example, data store 111 may contain malware definitions that are continually updated and accessible by server 151. The mobile communication device 101 may be configured to send application data, such as a hash identifier, for the suspect data object to the server 151 for analysis. Server 151 may contain known good component 903, known bad component 905, and decision component 907, or the components may be distributed across two or more servers. The one or more servers may thereby use the application data to determine whether the suspect data object is a identifiably secure data object. If the suspect data object is identifiably secure, the one or more servers may notify the mobile communication device or pointing device that it may accept and process the data object. The one or more servers may then use the application data to determine whether the suspect data object is identifiably malicious. If the suspect data object is suspect malicious, the one or more servers may notify the mobile communication device or instruct the device to reject the data object and not process it further. The known good and known bad components may have a variety of methods for identifying known good and known bad data objects. The data, logic, and any other information used by known good and/or known bad components to identify an identifiably good or identifiably bad data object, respectively, may be referred to as a "signature" or "definition" (described further below).

If known good and known bad components are not conclusive, the one or more servers may perform additional analysis to make decisions regarding the placement of the data objects. In one embodiment, server 151 contains a decision component that uses one or more analysis systems to analyze application data for data objects and make a determination as to whether a data object is deemed undesirable. In one embodiment, if there is insufficient information to perform additional analysis, the one or more servers may request that the mobile communication device send additional application data to the server for analysis. For example, the device may initially send the hash identifier, package name, and cryptographic signer information for the data object to the server for analysis. If the known good or known bad component is unable to identify the data object as known good or known bad, the server may request that the device send the entire data object to the server so that the data object itself may be analyzed. Upon receipt of the additional application data, further analysis to arrive at an arrangement as to whether the device should accept or reject the data object may be performed by decision component 907 or manually. In one embodiment, the server stores whether manual analysis is required for a given data object, so that an analysis team can easily determine what data objects need to be analyzed.

Since the evaluation of data objects may be generated in dependence on human analysis, server 151 may use an analysis system to generate a list storing suspicious data objects that require further study. In one embodiment, some results from the analysis system on server 151 produce an assessment that is transmitted to mobile communication device 101, and other results identify the data object as requiring human analysis. For example, if server 151 utilizes sets of heuristics to identify malicious applications, some sets of heuristics may be well tested and provide acceptable accuracy in correctly identifying malicious behavior, while other sets of heuristics may be experimental and require human analysis to determine if the results are acceptable.

Each of the above-identified components is described in more detail below. Those skilled in the art will appreciate that since the total number of known good applications for a mobile communication device can be identified, the use of a known good component 903 coupled to a database, logic, or other data store containing definitions for known good data objects (e.g., application data such as hash identifiers) can significantly reduce the detection of misjudged undesirable applications and reduce the need to perform computationally expensive analyses or contact a server for analysis. It will also be appreciated that the use of known good components 903 may be particularly effective for data containing executable software code. Executable software code for a given application rarely changes between different mobile communication devices, so creating a database of known good application data or logic for evaluating application data may be an efficient method for identifying security or trust data. This database may vary in size depending on the resources available on the mobile communication device. Alternatively, aspects of the present disclosure, such as known good components and known bad components, may have access to a remote server having a larger library of application data for known good or bad data objects, such as server 151 coupled to data store 111 in fig. 1.

In one embodiment of the present disclosure, the known bad part 905 may have access to a database, logic, or other data store containing definitions for bad data objects that may be stored on the mobile communication device without occupying a large amount of memory. For example, viruses and other malware or spyware definitions may include application data stored in a database or other memory cache, such as hash identifiers, package names, cryptographic signers, byte sequences, and byte patterns. In other words, there may be a known bad database that complements the known good database stored on the mobile communication device 101. Additionally or alternatively, the known bad part 905 may be able to identify malware using characteristics common to other malware code. When applied to network data or data files, the known bad part 905 may have access to a database containing patterns or other characteristics of protocol data units or file formats that present security threats. The known bad part 905 can also identify data that undesirably affects the mobile communication device, such as exposing vulnerabilities, expending battery life, transmitting private or unauthorized information to third parties, or exhausting unnecessary device resources. Any data identified as "bad" may be deleted, quarantined, or rejected from further processing of the mobile communication device, similar to the known good component 903 and database. If a known bad data object is deleted, one embodiment of the present disclosure may display a notification or other message similar to that described in co-pending U.S. patent application No. 12/255,635, entitled "SECURITY STATUS and information DISPLAY SYSTEM," filed 10/21/2008 and incorporated herein in its entirety.

Decision component 907 can be used to evaluate data that cannot be characterized as known good or known bad. Since most of the data received on the mobile communication device 101 may fall within this category, this component may reside on the server 151. This component may utilize a variety of methods to generate an assessment for a data object, including using any of the analysis systems disclosed herein. For example, decision component 907 can apply static analysis, dynamic analysis, distributed analysis, or other analytical methods to determine whether it can be delivered to the intended target of the received data or rejected in order to prevent damage from reaching the device. Examples of such analysis are discussed below.

The following example illustrates how one or more servers may be used to augment or replace the method described in U.S. patent application No. 12/255,621.

Multiple systems are possible including known good components, known bad components, and decision components. Depending on the specific data type being analyzed and the type of security threat being prevented, different execution sequences and logic applied to the output of each component may be employed. In one embodiment, if the known good component 903 does not determine the data to be good (block 805), it will be rejected from the process 813. The data determined to be good by the known good component 903 (block 805) is still analyzed by the known bad component 905 (block 807). If the known bad part 905 determines that the data is bad (block 807), it is rejected from process 813, otherwise decision part 907 can analyze the data (block 809). In one embodiment, if the known good component 903 does not determine that the data is known good, the known bad component 905 analyzes it. If the known good component determines that the data is good, it is allowed. If the known bad part 905 determines that the data is bad, it will be rejected from process 813. If the known bad part 905 does not determine that the data is bad, the decision logic 907 may analyze the data to arrive at an evaluation for the data.

An example analysis of network data or data files present on a mobile communication device is shown in fig. 8. As shown in fig. 8, block 801 may involve collecting data sent to or received from a mobile communication device. The data may be analyzed to identify its protocol and tracking status (block 803). In block 805, a known good component 903 resident on the mobile communication device can evaluate the collected data for known good characteristics. Known good characteristics may include those previously discussed or described in U.S. patent application No. 12/255,621. If the data contains sufficiently known good characteristics, it may be allowed to continue (block 811) to its intended destination for processing, execution, or other operations. Alternatively, the data may also be analyzed by a known bad part 905 residing on the mobile communication device to confirm that the data is truly secure (block 807). If the known bad part determines that the data is truly safe, the data may be allowed to continue toward its intended destination (block 811). Decision component 907 may also be used to provide a final check (block 809) before allowing the data to continue (block 811).

The analysis of the data objects may be performed at any time. The data object may be evaluated, for example, before being accessed or downloaded, or after being downloaded if the data is an application, but before or after being installed, before or after a new version of the data object is installed. In one embodiment, data objects that have not yet been downloaded to the device are evaluated by using identification information about the data objects. For example, if an application marketplace accessible to the mobile communication device makes available to the application for downloading and providing identifying information about the data object, such as a hash of the content of the application or a package name for the application, the software on the mobile communication device may use the identifying information to determine an evaluation for the application by evaluating the identifying information locally using any of the systems described herein or by transmitting the identifying information to the server 151 and receiving the evaluation from the server. In this way, software on the mobile communication device can evaluate whether applications are undesirable before they are downloaded by the user.

At any point during the analysis, if the known good component 903, the known bad component 905, or the decision component 907 (discussed further below) determines that the data is not good or positively contains a security threat, data inconsistency, etc., the data will be blocked, rejected, deleted, or quarantined in block 813. In one embodiment of the present disclosure, the signal event or security event information log may be updated to record data that is subject to contamination.

The analysis of executable data on the mobile communication device, such as applications, programs and/or libraries, may continue as shown in fig. 9. In block 901, it is determined whether an executable file needs to be classified as good or bad as a result of an attempt to access the executable file, install the executable file, or download or otherwise transfer the executable file to the mobile device. The executable file may or may not be preprocessed to extract additional application data, such as a hash identifier, cryptographic signer, package name, or other characteristic, prior to evaluation (block 903) by a known good component 903 resident on the mobile communication device. This evaluation may include comparing a hash identifier or other characteristic of the executable file to a database of known good characteristics, identifying whether the executable file has sufficiently known good characteristics, or any of the criteria discussed above or described in U.S. patent application No. 12/255,621.

If the executable file is identified as known good, it may be allowed to execute its code or continue for processing or other operations toward its intended destination in block 911. If the known good component 903 cannot allow executable file data, then a known bad component 905 residing on the mobile communication device may perform its analysis (block 905). If the known bad part 905 confirms that the executable file is malicious, the executable file may be quarantined, rejected, or deleted and an event may be logged (block 909). If it is known that bad part 905 cannot characterize the executable file, decision part 907 may perform its analysis as further described below (block 907). If decision component 907 ultimately determines that the executable file is safe, then the executable file is allowed (block 911). If the decision component 907 ultimately determines that the executable file is not secure or remains uncertain, the executable file may be quarantined (block 909). It will be appreciated that since the executable file may contain code that may cause significant damage to the mobile communication device, it may require more rigorous analysis before the executable file is allowed to continue.

It will be appreciated that the known good component 903 and the known bad component 905 may be kept lightweight on the resident mobile communication device by storing only the definition information about those applications that the mobile communication device is most likely to access. As described above, such information may be determined, for example, based on device data, previously installed applications on the mobile communication device, and the manner in which the mobile communication device is used (e.g., work versus entertainment, access to a public network versus a private network, etc.). It will be understood that each mobile communication device may store different definition information and that one embodiment of the present disclosure contemplates such granularity.

As discussed above and throughout, one embodiment of the present disclosure relates to server-side analysis of data in the event that the known good component 903 and the known bad component 905 cannot determine whether the data is safe. In one embodiment, decision component 907 resides on one or more servers 151 in communication with the mobile communication device over network 121, i.e., "in the cloud". The decision component can rely on one or more analysis systems, such as the analysis systems disclosed herein. Since decision component 907 resides on more powerful computing resources than the mobile communication device, it can provide a more robust analysis to determine whether the data should be deemed bad or good for device 101. Additionally, the analysis occurring on the server 151 may utilize the server aggregated data to produce an evaluation that may not rely solely on data available to the mobile communication device 101. Decision component 907 on server 151 may determine that the data object is malicious, for example, if the device reported behavioral data indicates that the data object sent a premium rate SMS message or dialed a premium rate phone number on the device on which it is installed.

In one embodiment, the decision component 907 utilizes one or more types of internal analysis systems to characterize whether a data object is good or bad. The decision component 907 is designed to detect security threats that have no specific definition of threats for precaution. In other words, the decision component 907 may operate as an additional security component to compensate for any shortcomings from the known good component 903 or the known bad component 905 and identify new threats that have not been previously identified.

It will be appreciated that there are a number of analysis systems that decision component 907 may utilize, including but not limited to systems that use heuristic algorithms, rule-based or non-rule-based expert systems, fuzzy logic systems, neural networks, or other methods that systems may use to classify data objects. As described above, such a system can employ a variety of data that can be employed by the decision component 907, including but not limited to distribution data, characterization data, categorization data, trust data, application data, and the like. For example, decision component 907 can analyze an application, library, or other executable file on the mobile communication device. In an example, decision component 907 may contain a neural network that analyzes characteristics of the executable file and determines a security assessment based on network connection characteristics. Such characteristics may be determined based on information contained in the executable file format or as a result of processing the content of the executable file. In another example, decision component 907 may comprise an expert system that analyzes the behavior of an executable file through actions or function calls, system calls that may be taken by the executable file to the operating system. If an executable accesses a sensitive system call in a manner that represents malicious behavior, the system may mark the executable as potentially malware and may take action.

If decision component 907 is located on mobile communication device 101, it may be desirable to update the rules or analysis parameters independently of updating the executable code that powers the decision component. In one embodiment, the decision component 907 comprises a virtual machine-based decision system by which a set of rules updated independently of the decision component itself can classify the executable file. Such a system can add new logic for detecting certain new undesirable application classes on the fly without updating the entire decision component. The system may pre-process the executable file so that the logic of the virtual machine may symbolically reference the executable file rather than having to process the executable file itself.

In an example, the decision component 907 can consider third party information to evaluate the data. Those skilled in the art will appreciate that the mobile communication device 101 has access to an application provider, such as Apple's App Store, android market, or other software repository or digital distribution platform, for providing applications available for download and installation on the mobile communication device. In one embodiment, server 151 has access to such application providers and may aggregate information about specific applications. For example, server 151 may search for and aggregate user-generated reviews or ratings for applications. Applications with favorable ratings may be considered safe, while applications with significantly negative ratings may be considered undesirable. Since server 151 may also determine trust data for the data object, if the application has a low trust rating, the evaluation for the application with a negative review may only indicate that the application is undesirable, while applications with a high trust rating and negative review may still be deemed desirable by the anti-malware system.

The above examples illustrate how the decision component 907 may utilize various analysis methods in order to fully evaluate the threat level of data received by or transmitted from the mobile communication device. Other examples may be envisaged without departing from the scope of the present disclosure.

It will be appreciated that identifying recognizably good data objects and recognizably bad data objects, such as mobile communication device 101 or server 151, may be performed by a single component rather than by separate "known good" and "known bad" components. In one embodiment, a single identification component performs the function of identifying both identifiably good and identifiably bad data objects.

In one embodiment, the identification component utilizes the definition to determine an evaluation for the data object. The identification component first examines the application data for the data object to determine if any definitions correspond to the data object. For example, if the identification component has access to definitions that are hashes of the contents of the data objects, then it is determined that a definition having the same hash as the hash of the contents of a given data object corresponds to a data object. In another example, if the identification component accesses a definition that contains a byte sequence signature, it is determined that the definition that has a byte sequence contained in the content of the data object corresponds to the data object. Each definition may be associated with an evaluation such that the identification component may examine the application data for the data object to determine the corresponding definition, determine the corresponding evaluation for the definition, and thereby generate an evaluation corresponding to the data object. For example, application data for a data object may include identification information, such as a hash of the data object, a package name, a unique identifier, or other application data, such as the content of the data object. In one embodiment, the definition used by the recognition component represents a known data object. In this case, the analyzed data object and the known data object need not be exactly the same when the recognition component determines whether the evaluation for the known data object corresponds to the analyzed data object. For example, if the first application from a particular developer is determined by analysis (e.g., manual analysis, automated analysis) to be undesirable, a definition may be created for the first application that matches the package name of the first application. If the developer creates a modified application having the same package name as the first application and the identification component encounters the modified application, then it is determined that the definition corresponds to the modified application because the package name in the definition matches the package name of the modified application. The identification component then determines that the undesirable assessment for the first application is applicable to the modified application.

For example, the identification component may access a database of definitions, each of which indicates a hash of the content of a data object and an indication of whether the data object to which the definition corresponds is deemed good or bad. In one embodiment, a definition of the use of one or more identification components operating on server 151 is stored on server 151 or on data storage 111. In one embodiment, the known good component 903 and the known bad component 905 are each implemented on the server 151 using an identification component. For example, a known good component may include an identification component, wherein all definitions accessed by the identification component correspond to an evaluation that the data object is deemed good. In one embodiment, the known good component and the known bad component are each implemented as an identification component that matches application data for the data object with known good and known bad application data. For example, a known good component may have a list of known good hash identifiers, package names, and secret signers that it attempts to match the analyzed data object. In one embodiment, a data object is considered safe if it has any characteristics in a known good list. In one embodiment, the server may use a similar known bad application data that matches the known bad application data with the application data of the data object for analysis. Other known good and known bad analysis systems are possible without departing from the scope of the present disclosure. In one embodiment, the identification component produces multiple assessments — not just "good" or "bad". In one embodiment, if all definitions have only a single corresponding evaluation, such as in a case where the identification component only identifies whether a data object is "known bad," then the identification component uses the single evaluation rather than storing multiple evaluations. Other variations are also possible without departing from the scope of the disclosure.

FIG. 12 illustrates one embodiment of the present disclosure used to evaluate data objects on a mobile communication device. The mobile communication device 101 may initiate a scan 1201 of data objects, such as in the case of a system-wide scan or when a data object is executed or installed. The identification component evaluates application data (e.g., package name, hash of content of the data object, unique identifier, content of the data object) for the data object to determine whether the definition accessible to the identification component corresponds to the data object (block 1202). For example, as discussed above, correspondence may include matching identification information for the data object with data contained in the definition or matching the content of the data object with a sequence, pattern, or logic contained in the definition. If the definition corresponds to a data object, the identification component determines a corresponding evaluation for the data object. In one embodiment, the identification component utilizes a data store of definition and evaluation information in block 1202. For example, as discussed above, the definitions stored on the mobile communication device may be pre-populated or populated as the mobile communication device receives the definition and evaluation information from server 151. In one embodiment, the definitions stored on the mobile communication device may be considered a cache, which operates as described above. If the recognition component on the mobile communication device determines an evaluation for the data object (block 1203), the evaluation is processed to determine how to treat the data object (block 1204). For example, if the evaluation indicates that the data object is malicious, the mobile communication device may not allow the data object to be executed or prompt a user of the device to offload the data object. If the identification component on the mobile communication device does not determine an evaluation for the data object (block 1203), the mobile communication device 101 transmits data object information, such as application data (e.g., identification information, content of the data object), to the server 151 (block 1205). The server receives the data object information (block 1206), and an identification component on the server evaluates the data object information to determine whether a definition accessible to the identification component corresponds to the data object (block 1207). If the definition corresponds to a data object (block 1208), server 151 determines an evaluation for the data object and transmits it to the mobile communication device (block 1209). If the identification component does not determine an evaluation or corresponding definition for the data object (block 1208), a decision component on the server analyzes the data object information (block 1210). If the decision component produces an assessment, server 151 transmits the assessment to the mobile communication device (block 1209). If the decision component does not produce an evaluation, the server transmits an indication to the mobile communication device that the data object is unknown (block 1209). The mobile communication device 101 receives the assessment from the server (block 1211) and processes the assessment information to determine how to treat the data object (block 1204). In one embodiment, mobile communication device 101 adds information from the evaluation received from server 151 to its locally defined cache as it processes the evaluation information (block 1204). For example, the device may store information such as an arrangement for the data object (e.g., "known good," "known bad," "malware," "spyware"), an identifier transmitted by server 151, and defining information (e.g., a hash of the content of the data object, a package name of the data object) generated by the device or transmitted by server 151.

In one embodiment, in the event that the identification component on the mobile communication device does not determine an evaluation, the mobile communication device performs an analysis on the scanned data object using a local decision component on the mobile communication device prior to transmitting the data object information to server 151. In one embodiment, the analysis by the local decision component and the transmission of the data object information to the server occur in parallel to minimize delay to the user. Those skilled in the art will appreciate that a variety of configurations of components in a combined client-server anti-malware system are possible without departing from the scope of the present disclosure.

In one embodiment, the mobile communication device 101 transmits authentication information, such as authentication credentials or session information, to the server 151 whenever it sends information about a data object so that the server can associate the exchanged information with a particular account on the server.

D. Application evaluation and recommendation system

The previous section of this disclosure describes various systems and methods as follows: which is used to aggregate different types of data from one or more mobile communication devices and other sources and analyze the aggregated data to produce an evaluation for the data object. The following is a discussion of how server 151 may use the evaluation for display, exposure via an API, and a variety of other purposes. Some examples of evaluations that have been disclosed herein include output from one or more analytics systems (e.g., characterization data, classification data, trust data, and distribution data) and one or more ratings for data objects (e.g., security rating, privacy rating, battery rating, performance rating, quality rating). One of ordinary skill in the art will appreciate that the evaluation information relates to a wide variety of information beyond the evaluation of whether a data object is malicious by typical anti-malware systems that may be used to understand the impact of installing a given data object on a mobile communication device. In addition, this evaluation information may be used to guide decisions as to whether to download and install different types of data objects. Such information may be useful to an individual user who is attempting to decide whether to install a certain application on his mobile communication device. Such information may also be useful to an IT administrator who attempts to decide whether to deploy an application to multiple mobile communication devices. In one embodiment, a user or IT administrator may use this evaluation information for application policy enforcement.

Those skilled in the art will appreciate that the data available to server 151 and the server-generated evaluations are useful beyond the intent of anti-malware. For example, the evaluation may detail whether the data object is known to overcommit the battery of the mobile communication device or whether the data object utilizes an undesirable amount of network resources. Since server 151 continues to collect, store, and analyze data to generate assessment information, in one embodiment, server 151 may provide information detailing how the data object is estimated to affect the mobile communication device before the data object is installed on the mobile communication device. For example, server 151 may provide estimated battery usage information and/or network usage information for an application.

When a user interacts with an assessment, it may be desirable for the assessment to represent an appropriate level of granularity so that the user does not feel that the assessment is too broad or too narrow. In one embodiment, server 151 merges the evaluations for multiple data objects into a single evaluation and transmits the merged evaluation. For example, if an application contains multiple data objects (e.g., an executable file and multiple libraries), a user may wish to view an evaluation for the application as a whole rather than for its constituent data objects. Similarly, if there are multiple versions of an application (on a single platform or multiple platforms) that exhibit similar characteristics, an enterprise policy administrator making decisions about the application may only wish to view a single evaluation that encompasses all versions of the application.

To consolidate evaluations for multiple data objects, server 151 may use application data, such as file path, version number, package name, cryptographic signer, installer source, and other information to determine that a group of data objects relates to a particular version of an application and/or that one or more data objects or groups of data objects belong to different versions of an application. For example, if a set of executables are collectively seen in the same directory, server 151 may determine that those executables are all related to the same application. In another example, if an application package has both a package name and a version identifier embedded in the application package, server 151 may determine that two data objects having the same package name and human-readable application name, but different version identifiers, are multiple versions of the same application.

Since it may be desirable to evaluate forms of consistent information provided between platforms, one embodiment of the present disclosure involves server 151 including some or all of the same fields in an evaluation for data objects running on different platforms. For example, even if the location APIs on different smartphone operating systems are very different in their functionality, server 151 may still perform operating system-specific analysis on the data objects to produce a cross-platform assessment of whether each data object accesses the location of the device. If the assessment is in the form of a list of capabilities for data objects, both the mapping application on BlackBerry and the location-based social network on Android will have "access device location" capabilities. Similarly, battery usage may be calculated differently on different platforms, but server 151 may generate a cross-platform assessment of estimated daily battery usage measured as a percentage of total battery capacity. In one embodiment, the evaluation of the merging for the plurality of data objects includes information about the characteristics and the classification range for the data objects. For example, the evaluation may show battery usage trends for multiple versions of an application. Applications that use large amounts of batteries in older versions, but have recently reduced their battery usage, may be acceptable, while applications with consistently high battery usage may be unacceptable.

One embodiment of the present disclosure relates to server 151 evaluating data objects available via a web interface. For example, users may wish to be able to learn more about the nature and capabilities of applications they have on their mobile devices. Server 151 may expose an index of applications for which evaluations are available and an evaluation for each of these applications as a web interface. To facilitate ease of locating applications, server 151 may organize applications in a variety of ways, such as alphabetically, by their nature, by their categorization, and by platform. Further, server 151 may allow a user to search for applications (e.g., all applications running on the Android OS and sending locations to the internet) using a search term that matches the name, description, or field in the evaluation of the application. In addition, the publicly displayed assessment may aid in the transparency of the application.

For example, an application seller may direct the user to an evaluation page collected by server 151 that serves as an independent third party evaluation of the capabilities of the application so that the user can verify what the application does. In one embodiment, the server generates a web interface that allows the user to view a conditional evaluation of the application based on the device data (e.g., how much battery this application uses on Motorola Droid, how much network data this application uses on AT & T Wireless) and compare the different conditional evaluations (e.g., how much battery this application uses on Motorola Droid versus HTC Hero, how much network data this application uses on AT & T Wireless versus verizon Wireless). Such conditional evaluation may help identify anomalous behavior in certain circumstances-e.g., an evaluation page may indicate that a handset, operating system version, or some set of other applications installed on the device cause a higher error rate or anomalous changes for certain evaluation characteristics of such an application. In one embodiment, server 151 identifies data objects having extreme values for a particular evaluation value. For example, server 151 may generate a web page that identifies which applications use more than 1 gigabyte of network data per month or which applications use more than 10% of the device's battery.

Since the evaluation data generated by server 151 may be used to provide a variety of other products and services, one embodiment of the present disclosure involves server 151 exposing the evaluation data via an API. All functions exposed by the web interface as described above may also be exposed as an API, so that a variety of products and services may be built. For example, the server 151 may provide an HTTP API through which provisioning the packet name or content hash of the data object in the request URL will cause the server to return an evaluation of the data object identified for the packet name or content hash. In another example, server 151 may generate a JavaScript file that the remote web page may include and may display an interaction evaluation view for a particular data object.

In one embodiment, server 151 may cause evaluation data, such as ratings or arrangements regarding whether the application is desirable, to appear in the application marketplace. It will be appreciated that the application marketplace may be implemented in a variety of ways, such as using a website, using a mobile client application, using a PC-based client application, and using a messaging service, such as SMS. Thus, this embodiment of the present disclosure will provide objective assessment information for an application or other data object rather than subjective review information provided by the user.

For example, server 151 may provide an API through which it may be queried for assessment data, or server 151 may proactively analyze all applications available in the application marketplace to transfer assessment data to the marketplace provider. In one embodiment, a user may search the application marketplace for only those applications that meet certain desirable criteria, such as security, privacy, device efficiency, trustworthiness, and so forth. In one embodiment, the application provider may use the aggregated information to provide quality control measures. The application provider may only present applications that meet certain battery efficiency criteria, criteria for acceptable number of crashes or errors, certain network traffic restrictions, privacy protection, and so forth. In this way, one embodiment of the present disclosure may increase offers (referrings) on the application marketplace, thereby encouraging developers to create better applications. In one embodiment, the assessment information may be used as an authentication system where an application meeting certain criteria is marked with a symbol, badge or other icon representing a positive assessment for the application. For example, applications with a high trust rating or applications that only access a minimal set of private information may be considered authenticated. To verify the authentication of the application, the authentication marker may have a link or other means for the user to retrieve the full evaluation from server 151.

In one embodiment, the server 151 transmits the assessment information to the mobile communication device 101 for display. For example, the mobile device may have an interface through which a user may explore evaluations for all applications installed on the device. The interface may allow the user to view assessment information for a particular application and to see which applications match a set of assessment criteria (e.g., all applications sending the location of the device to the internet, the top 10 battery users, all applications using more than 50 megabytes of network traffic per month). In one embodiment, the mobile communication device 101 displays an interface on the mobile communication device as part of an application marketplace, an application download process, or an application installation process so that a user browsing applications available for download or downloading/installing applications sees evaluation information for the applications. Upon browsing, downloading, or installing the application, the device transmits the identification information to server 151 and receives an evaluation for the application to display some or all of the evaluation on the user interface. For example, the interface may display capabilities of the application or characteristics of the application. The interfaces may also interact to allow a user to explore aspects of the assessment to request additional assessment information from server 151 if necessary. In another example, the device may display a trust indicator for the application as determined by server 151 and transmitted to device 101 as part of the evaluation. Can be displayed in various ways Trust indicators, including as authentication stamps (e.g. "Lookout^TMAuthentication ") or a rating (e.g.," a + "," B- "," C + ").

In some cases, the user does not read a lengthy security description, and it is therefore important to display security information about the application in a manner that can be easily understood. In one embodiment, the mobile communication device 101 displays a graphical assessment indication for an application. For example, a salient aspect of the assessment may be displayed as an icon or badge for the application. Some examples include badges for "battery efficient," battery exclusive, "" access location, "with" spy capability, "" social network, "and" file sharing applications. The badge for each significant assessment may include a graphic to make the badge easily understandable and a coloring to indicate whether the assessment is only a heuristic or potentially critical item. For example, an application that is efficient in battery use may have a green icon indicating a full battery, while an application that typically uses a large number of batteries may have a red icon showing an empty battery.

Since server 151 is constantly collecting information and improving the assessment, assessment information can be updated on the application marketplace and/or mobile communication device that has cached the assessment information. For example, server 151 may send a notification to the application marketplace or mobile communication device indicating that new assessment information is available. In another example, server 151 may simply transmit updated evaluation information so that old information is overwritten.

In addition to viewing an assessment on a device for a data object installed on the device, it may also be desirable to view an assessment for a data object installed on a device from a web interface. For example, a user may wish to use his or her PC to explore evaluations for applications installed on his or her device. As discussed, in one embodiment, the mobile communication device 101 transmits application data for the data objects it has installed to the server 151. Since server 151 may store which applications are currently installed on device 101, the server may generate a user interface that displays an evaluation for those applications. For example, server 151 may generate and transmit a web interface that allows the user to view a list of all applications installed on the device, view an evaluation for each installed application, and explore which installed applications match a particular evaluation value (e.g., all applications that may access my location). To prevent disclosure of private information, server 151 may require the user to log in using authentication credentials to view an evaluation for an application on his or her device. Additionally, an enterprise administrator may wish to view an assessment for a group of devices from a central management console.

In one embodiment, server 151 generates a web interface that allows a user to view an evaluation of applications installed on multiple devices. For example, the web interface may allow a user to explore all applications installed on a device group that matches a certain evaluation field (e.g., file sharing applications), view a risk rating evaluation for the device group, view all capabilities for the applications installed on the deployment, and determine which devices and which applications cause certain capabilities and risk exposures. A user may start by using server 151 to generate an aggregate set of security, privacy, and battery risk ratings for a group of devices, and then click on the rating to view a list of applications that contribute most to the risk rating. The user can then see which devices have a given application. In another example, a user may start by using server 151 to generate a list of all capabilities for applications installed on a group, and then click on a given capability to view all applications installed on the group with that capability. From there the user can further explore which devices in the group have a given application installed. In one embodiment, server 151 exposes an evaluation for a device group in the form of an API for use by an external service, such as a management console. For example, server 151 may expose a risk rating for a group of devices to the centralized security reporting system via an HTTP API.

On mobile communication devices, battery and network data are often limited in such a way that the application may adversely affect the battery life of the device and may cause excessive costs for network usage. One embodiment of the present disclosure relates to using the assessment to let the user know the network or battery usage of the application and to remind the user in case of misuse of the application. Software on the device retrieves the assessment containing battery and network usage characteristics for the application from server 151 and displays the assessment to the user. As described above, the device that requests evaluation information from server 151 may include application data for the application. The assessment may be tailored to the particular device used by the user, by the device sending device data when retrieving the assessment, or by sending authentication data that associates the assessment request with previously transmitted device data. For example, the evaluation may indicate that the application will likely reduce the battery life of the phone of the user's model by 5% or 1 hour; while different model phones with different battery life characteristics may receive an assessment that the same application reduces the battery life of the phone by 10% or 3 hours. The evaluation display may appear as part of the device application marketplace, or as a user interface dialog, before, during, or after installation of the application.

Additionally, after a user installs multiple applications, it may be desirable for the user to understand which applications contribute most to network usage or battery life based on the actual behavior of the applications on the device. In one embodiment, the device aggregates behavioral data for battery and network usage of the application and allows the user to view the actual behavioral data from an interface on the device. For example, the interface may allow a user to view battery and network usage for a particular application and to view the network and the highest battery usage application in order to identify which applications contribute to network excess (over) or short battery life. In one embodiment, the mobile communication device 101 reports behavioral data for applications installed on the device to the server 151 and allows the user to view the actual behavioral data via a server-generated web interface. One of ordinary skill in the art will appreciate that other characteristics of the mobile application may also be monitored and shown to the user.

Since a single application may cause significant problems with battery life, network usage, or other limited resources, it may be desirable to notify a user when application behavior is undesirable. In one embodiment, the mobile communication device 101 monitors network and battery usage of applications installed on the device and notifies the user of the device when the applications exceed desirable limits. For example, the user may set a threshold for how much data the application can transmit and receive when he or she is notified. In another example, the user is notified when the device determines that the application will adversely affect the user's battery life or phone bill. If the user typically uses the phone for 20 hours before plugging it in and the application on the device reduces the estimated battery life to less than 20 hours, it is likely that the user will run out of battery. It may then be important to remind the user that he or she has the action he or she can take to avoid running out of the battery, i.e., uninstalling or otherwise deactivating the battery high use application.

In one embodiment, to avoid applications on the user's device exceeding the user's data plan, device 101 or server 151 predicts the device's future data usage and collects information about the device's data plan. To collect information about the data plan of the device, device 101 or server 151 connects to a network operator's server to determine data plan information such as data allocation per billing period, what their billing period is, and how much data has been used during the current billing period. Communication to the network operator's server may occur in a number of ways, such as via HTTP API or SMS messaging. If the software on the device uses SMS messaging to retrieve the user's data plan information, the software may automatically consume a response message sent by a server of the network operator to prevent communications from appearing in the user's inbox. To predict future data usage, server 151 may analyze typical data usage for applications installed on the device and actual data usage on the device. Typical data usage may be used if the application is newly installed, while actual data usage may be used for applications that are already on the device for months. If the application on the device 101 uses network data at a rate that will exceed the device's data plan allocation by the end of the billing period, the software on the device displays a reminder indicating that there may be excessive charges. The reminder may also display the application that most contributes to the data usage and give the user to uninstall or reconfigure the application. Device 101 may report alerts to server 151, which may also send notifications (e.g., via email) indicating that there is a possibility of being too much data. Software on device 101 or server 151 may display an indication of the current predicted data usage for the data allocation to the device so that the user can adjust his or her application usage pattern accordingly. For example, if a user is concerned about exceeding his or her data plan, he or she may check what the current predicted data usage is before participating in a video chat.

Since applications installed on a device may have a significant impact on the risk exposure of the device, it may be desirable for a user or administrator to set a policy for what applications are desired to be installed on a device or group of devices. The following is a discussion of how a protection policy may be implemented on one or more mobile communication devices. In one embodiment, the policies include blacklists and whitelists. A blacklist is a set of applications or evaluation criteria that are explicitly rejected to run on the mobile communication device, and a whitelist is a set of applications or evaluation criteria that are explicitly allowed to run on the mobile communication device. For example, a policy may allow only applications that are on the white list or only applications that are not on the black list. In one embodiment, explicit application entries have a higher priority than evaluation criteria entries. For example, a policy may specify certain capabilities for blacklisting (e.g., the location of the device to be sent to the internet), but certain applications for whitelisting. In this case, all applications that send locations to the internet can be blocked unless they are explicitly on the white list, since explicit applications on the white list have a higher priority than evaluation criteria on the black list. Those skilled in the art will appreciate that various policy schemes may be implemented without departing from the scope of the present disclosure.

Users may have individual preferences for the type of application they are using on their mobile devices. Some users may be sensitive to privacy issues, for example, while other issues may want to optimize their battery life. To allow users to utilize application evaluation to gain greater insight into the applications they may use or consider using, one embodiment of the present disclosure relates to software on a mobile communication device that allows users to set policies based on evaluation criteria for the applications that prevent applications that exceed an undesirability threshold. When a user attempts to install an application, the software requests an evaluation for the application from server 151 and receives the evaluation from the server.

For example, if a user attempts to install an application that has the capability to send location information to the internet, but has a policy for disallowing any application that can send his or her location to the internet, software on the mobile communication device will prevent installation. In another example, the user may individually set privacy, security, and battery life policy thresholds on a relative scale (e.g., 0 to 10). When a user installs an application, software on the device retrieves an evaluation for the application and compares the privacy, security, and battery rating of the application to policy thresholds and alerts the user if the application exceeds the configured policy. The user may want to simply be alerted of the undesirability rather than preventing installation of the undesirable application.

In one embodiment, the user may ignore the reminder and choose to accept the application anyway. In one embodiment, the device displays a user interface that indicates that the application is undesirable to the user. For example, the mobile device may display an indication of whether the application viewed in the application marketplace for possible download satisfies the user's desirability criteria. In another example, software on the device may allow the user to view all applications that do not meet desirability criteria. Such an interface may be useful if a user changes his or her criteria and wants to view applications that are now undesirable given the new criteria.

An IT administrator, parent, network operator, or other person responsible for multiple mobile communication devices may wish to set policies on multiple mobile communication devices without physical access to all of the devices. In one embodiment, server 151 allows a user or administrator to set policies for a device or group of devices. When device 101 attempts to install an application, the device sends a request for an evaluation of the application to server 151. Based on the policy configured on server 151, the evaluation includes an indication of whether the application is allowed or not allowed and may also include policy criteria for why the disallowed application is evaluated as disallowed. In one example, the policy on server 151 is configurable via a web interface.

In one embodiment, server 151 allows policies to be configured according to evaluation criteria and on a per-application basis. For example, an administrator may use server 151 to block all applications in a certain category, such as social networking applications, or all applications that access certain capabilities, such as the ability to transfer files or other sensitive data from a device. In an example, an administrator may wish to allow only certain applications, blocking all applications that are not on the white list by creating the white list. In yet another example, the administrator may allow all applications except for specific applications on the blacklist, as these specific applications are known to be undesirable. Since the set of applications allowed or rejected under the policy can be pre-computed, one embodiment of the present disclosure involves the server 151 generating a set of policy definitions and transmitting the policy definitions to one or more mobile communication devices 101. For example, if the device group has a policy for allowing only applications on the white list, server 151 may transmit a list of identification information for the white listed applications to the mobile device, so that the device need not contact the server for evaluation each time it encounters an application.

When configuring policies using abstractions, such as application categorization and capabilities, it may be desirable for a user or administrator to see what applications will be allowed/rejected or whether particular applications will be allowed/rejected if a configuration change is to be made. In one embodiment, the policy configuration user interface on the mobile communication device 101 or server 151 includes an interface for viewing applications that are to be blocked or allowed as part of a configuration change. If a configuration change interface is displayed on mobile communication device 101, the device may send a request for data to server 151 to populate the interface. It may be desirable to show all applications that are allowed or blocked after the configuration change has taken effect or to show only the differences between the current configuration and the new configuration. Since the number of applications affected by a configuration change can be large, the interface can display summary information and allow the user to search for a particular application to determine if the configuration change affects the application and whether the configuration change will cause the application to be allowed or blocked. In one embodiment, the interface that displays the impact of the configuration change indicates whether any popular applications will be blocked. Application popularity may be determined, for example, based on server 151 or overall distribution data determined by the prevalence of applications in the managed group of devices. In one embodiment, the change results interface displays only changes that affect the application currently installed on at least one device in the managed group.

To prevent the policy system from interfering with the acceptable usage of the mobile communication device, one embodiment of the present disclosure involves server 151 maintaining a set of acceptable applications and allowing a user or IT administrator to easily add those sets to a white list that automatically includes changes to the set of acceptable applications. For example, server 151 may maintain a general list of popular applications or a list of popular applications by application category. In the policy configuration interface, the server may present a way to include all popular applications or only popular applications in a specific category (e.g., games, social networks) in the white list of policies. In one embodiment, such a dynamic list policy has a higher priority than evaluation criteria entries on the blacklist and whitelist, but a lower priority than explicit application entries. In another example, server 151 may maintain a list of applications with high trust. In a policy configuration interface, the server may present a way to include all high trust applications in the white list of policies. Applications with high trust are effectively considered whitelisted when making policy evaluations whenever the high trust list is updated.

Since a mobile device deployment may already have a device management server or service in place, it may be desirable for server 151 to provision data to the device manager server that actually performs policy enforcement. In one embodiment, server 151 interfaces with a device management server to configure application policies on the device management server. For example, the device management server may support configurable application blacklists and whitelists. If the user sets a configuration on server 151 to allow only applications on the white list or that match certain evaluation criteria, server 151 generates a list of applications to be whitelisted and transmits the list of applications to the device management server in a format and protocol supported by the device management server. Similarly, if the user configures a blacklist on server 151, the server generates a list of applications on the blacklist and configures the device management server to enforce the blacklist. In one embodiment, the server is capable of configuring multiple device management servers. For example, if an organization supports multiple mobile device operating systems and uses different mobile device management servers, an administrator may configure a cross-platform policy on server 151 (e.g., block all file sharing applications). Server 151 may then identify all applications across multiple platforms for which it evaluates a match to the policy and configure the appropriate application policy on the device management server. Since each device management server may only support a subset of the mobile device platforms supported by server 151, server 151 only transmits policy information to the device management server corresponding to data objects running on operating systems supported by the device management server. For example, if the device management server supports only Blackberry devices, server 151 may configure the blacklist and/or whitelist of the device management server with only information about the Blackberry application.

In one embodiment, the server 151 or the mobile communication device 101 may perform policy compliance checking. For example, if the server performs a compliance check, any compliance settings are stored on the server 151 so that any configuration performed on the mobile communication device 101 results in the configuration being transmitted to the server. When a device requests an evaluation for an application from server 151, the server includes an indication in the evaluation of whether the policy allows or disallows the application. In another example, if the mobile communication device 101 performs a compliance check, any compliance settings are stored on the mobile communication device 101, such that any configuration performed on the server 151 results in the transfer of the configuration to the device. When the device receives an evaluation for an application, it compares the evaluation to the policy configuration to determine whether to allow the application.

In one embodiment, policy management is integrated with a server-coupled anti-malware system, such that signatures and evaluations for applications provided by server 151 enable device 101 to block data objects that violate policies. For example, if the application is deemed malicious or it violates a policy when device 101 requests an evaluation from server 151, the evaluation of the server indicates that the application is undesirable. In either case, the resulting evaluation may indicate further information as to why the application was found to be malicious or violated a policy. In another example, server 151 may preemptively transmit a signature for a malicious or policy-violating application to mobile communication device 101 so that the device can identify whether a data object is desirable or undesirable without contacting server 151.

If the device 101 has installed an application that violates a protection policy in place on the device or server 151 or has updated an evaluation for the application so that it violates the protection policy, it may be desirable for the device or other system to take corrective action. In one embodiment, if a device has installed an application that violates a protection policy for the device, the server or software on the device may enact corrective action to be taken. Depending on whether policy compliance is determined at the device 151 or the server 101, the device or the server may determine what corrective action is to be taken.

For example, if a user installs an application and the evaluation received from server 151 indicates that the application is acceptable, but at some point in the future the server determines that the application is not acceptable, server 151 transmits to the device an updated evaluation that includes the corrective action to be taken by the device. In another example, if the user installs an application on the device and the device receives an evaluation from server 151 indicating that the application is acceptable, but the software on the device collects behavior data indicating that the application violates a policy (e.g., the application attempts to obtain the user's location), the device may take a preconfigured corrective action, such as removing the application. The device may also transmit this behavior data to server 151 and indicate a policy violation. Those skilled in the art will appreciate that using behavior data to enforce policies may protect a mobile communication device in a number of situations as follows: such as when exploiting vulnerabilities in the application, when the application is undesirable only on a subset of devices (e.g., a targeted attack against employees of a particular company), or when the application is undesirable only after a period of time (i.e., a timed bomb).

Upon detection of a policy violation by the device, a variety of corrective actions are possible, e.g., any offending application may have their process ended, may be offloaded or isolated from accessing certain system functions (e.g., internet, private data), or may be restricted from accessing certain networks (e.g., only allowed access to Wi-Fi and not cellular). It may also be desirable to isolate the entire device from accessing sensitive resources, such as corporate email or VPN servers, to prevent information leakage while the device is out of compliance. Other corrective actions may include those disclosed in U.S. patent application No. 12/225,614 filed on 21/10/2008 and incorporated herein in its entirety.

If an administrator is able to set policies using server 151, it may also be desirable for a user to use server 151 to view the compliance status of the device to which the policy applies. In one embodiment, server 151 determines whether the group of mobile communication devices is compliant with the application policy and which applications are installed on the devices in the group. For example, if the mobile communication devices report applications that they have installed and server 151 contains policy configurations, the server may determine which devices are currently violating the policies set by the administrator. To allow an administrator to view the compliance status, server 151 may generate a web interface that enumerates whether all devices are compliant and how many if any are out of compliance. The interface may also allow the administrator to view the specific device out of compliance, see which applications are out of compliance with the device, and remotely initiate corrective actions (e.g., remove the application).

In one embodiment, server 151 presents a single click corrective action, where an administrator can click a single button to remotely initiate a corrective action on all devices in the group managed by the administrator. For example, if an administrator manages 100 devices and 10 of the devices have applications that violate a policy, the administrator may click on a one-click correction button on the web interface to cause the server to send an indication to each of the 10 out-of-compliance devices to remove undesirable applications without any user intervention. Once the corrective action is complete, each device 101 may send an indication to server 151 indicating whether it was successful. During the correction process, server 151 may generate an interface through which an administrator may view the status of the correction. Other methods of server exposure compliance status include server 151 exposing an API (e.g., for use by a security management console) and server 151 generating reports that may be downloaded.

In some cases, it may be desirable for a user or administrator to receive a notification if he or she installs an application that is deemed undesirable or if a previously installed application is re-deemed undesirable based on an updated evaluation. In one embodiment, the mobile communication device 101 transmits information about the installation data object to the server 151. If server 151 determines that the data object is undesirable based on the general undesirable characteristic or the characteristic for the user, the server transmits a notification. For example, if a user installs an application that is evaluated as desirable, but at some point in the future, the application begins to exhibit malicious or other undesirable behavior, such as wasting battery, the server may alter its evaluation to indicate that the application is undesirable. The notification may take many forms, such as a user interface dialog box or an email, SMS message displayed on a web page, on a PC or on a mobile communication device.

For an IT administrator managing multiple mobile communication devices, policies may be set for an application even if a particular application is available on multiple platforms and has multiple versions. IT is not uncommon for an IT administrator, for example, to manage mobile communication devices running different operating systems in batches. Bulk mobile communication devices may include iphones, BlackBerry devices, and Android devices. However, if an application is known to be an undesirable social networking application on all three device operating systems, such as may reveal private information, the IT administrator may prevent all versions of the application from being installed regardless of the platform. However, if an application can share sensitive information on one platform, but not on other platforms, an IT administrator may allow the application to be installed only on platforms that do not share sensitive information. As discussed above, IT may also be desirable for an IT administrator to make policy decisions regarding all versions of an application at the same time rather than having to maintain a policy that treats multiple versions of an application as separate decisions. Managing application policies can quickly become a difficult task if an administrator cannot treat all versions of a particular application as a policy decision, since there are some applications that are updated very frequently.

Since applications can change dramatically between updates, it is desirable for the administrator to be aware of any changes that may affect the administrator's decision on whether or not to allow the application. One embodiment of the present disclosure involves server 151 sending notifications in the event that an application present on a blacklist or whitelist changes its capabilities or characteristics significantly. For example, if a new version of an application on the administrator's whitelist has the capability to transfer files from the user's device but the previous version does not, server 151 may send an email or text message to the administrator indicating the change. The policy management interface on server 151 may also display a list of applications that may need attention based on the changed characteristics.

To simplify configuration, one embodiment of the present disclosure involves that software on the mobile communication device 101 or server 151 may provide a default policy that addresses common use cases. For example, a user may be able to choose that they focus on battery life and location privacy, but that they do not focus on network usage and phone number privacy. By selecting such concerns, the device or server automatically configures policies and thresholds for undesirable applications. In one embodiment, server 151 or device 101 contains a preset policy for compliance with regulations. For example, financial or healthcare workers may be required to have a particular set of application policies in place to prevent disclosure of sensitive information. Since the set of applications allowed or rejected under these regulations may change over time, server 151 may automatically update the specific policy decisions that enforce the regulations without the administrator specifically configuring them. To allow for inspection and auditing, server 151 may generate a list of policy decisions that it uses to comply with regulations and may notify an administrator when a policy decision will change. If the administrator denies certain policy decisions, he or she may override the default policy set by server 151.

Since it may be desirable to simplify the policy configuration process, one embodiment of the present disclosure involves the server 151 or mobile communication device 101 presenting a series of questions to a user or administrator, the answers to which are used to automatically set the policy. For example, when a user first sets up application policy software on his or her device, the software may ask the user whether the user has an unlimited data plan, whether the user wants to allow service access to the location of the device, and whether the user wants to block all tools that may be used to monitor on the device. Based on the answers to the questions, the device may set policies whether to block high data usage applications, whether to alert the user in the case of high data usage applications, whether to block sending the user's location to the internet applications, and whether to block spying on the applications. After this initial setup, the user may wish to adjust the policy decision, while other users may accept the automatically configured policy.

Since abusive applications can have a number of negative impacts on wireless networks, one embodiment of the present disclosure is directed to providing "early warning" information about potentially abusive applications. In one embodiment, server 151 may use information, such as behavior data and other data available to it, to generate an assessment of whether an application has network access characteristics that may be detrimental to the mobile network. Applications that receive or transmit large amounts of data, send large numbers of SMS messages, or open large numbers of persistent connections, for example, can adversely affect the performance of the mobile network. After evaluating the application to determine whether it is potentially harmful to the mobile network, server 151 stores the evaluation. In one embodiment, server 151 notifies an administrator after identifying potentially harmful applications. For example, the notification may be in the form of an email or text message containing information about the potentially harmful data object.

In one embodiment, server 151 generates a web interface that displays applications that have been evaluated as potentially harmful to the mobile network. The web interface may be designed to support review workflows so that an administrator can further analyze potentially harmful applications. After inspecting the application, the administrator may want to take corrective action in some cases, while in other cases the administrator may not want to take corrective action. If the administrator chooses not to take action, the application will not be considered potentially harmful unless its behavior changes significantly, thereby triggering server 151 to identify the application for review. To prevent multiple data objects for a given application from being repeatedly identified as potentially harmful, if the administrator chooses to ignore the application, all versions of the application will also be ignored, as server 151 can determine whether multiple data objects belong to the same application or other grouping.

If the administrator knows that a potentially harmful application is installed on more devices, he or she can take proactive steps to avoid serious problems. In one embodiment, server 151 generates a web interface that allows an administrator to take corrective action for applications deemed harmful. A variety of corrective actions are possible. For example, server 151 may present an interface that allows a network administrator to communicate with the publisher of the application and complete the resolution of harmful behavior. Server 151 may extract the publisher's email address from the mart data and allow the network administrator to type messages into the server's web interface that the publisher sends via server 151. When server 151 sends an email, the reply address in the outgoing email is specifically set so that when the publisher responds, the server associates the response with the initial message and publishes the response in the web interface for the administrator to view and potentially continue the conversation. In one embodiment, server 151 generates a web interface that allows an administrator to configure security software installed on a device group. For example, an administrator may wish to configure security software to block potentially harmful applications or isolate applications so that it cannot communicate via the cellular network. If the administrator wishes to block the application, server 151 may use a variety of mechanisms, such as those discussed herein, to block the application from being installed on the device or to remove the application if it is already installed on the device. Since server 151 may identify multiple data objects corresponding to the same application, if the administrator blocks the application, all data objects for the application are considered blocked. Server 151 may allow an administrator to specify a range of versions of an application to be blocked if a potentially harmful application is repaired in a subsequent version.

Since it may be desirable to prevent downloading of undesirable applications, one embodiment of the present disclosure involves server 151 generating network infrastructure configuration data. For example, server 151 may store a set of blacklisted data objects and may be capable of generating an intrusion prevention system or a set of HTTP proxy rules. The rules may attempt to match identifiers used by mobile devices to download data objects from the application marketplace, or to identify the contents of undesirable data objects as they are transmitted across the network.

In one embodiment, server 151 generates network infrastructure configuration data for blocking network traffic associated with undesirable applications. By server 151 using the behavioral data for the undesirable application to characterize network communications associated with the application and generate rules that block similar network traffic (e.g., traffic destined for the same IP address, subnet, or hostname), server 151 generates network infrastructure configuration rules that prevent network communications associated with the undesirable application. To prevent blocking legitimate traffic, server 151 may analyze how unique the network traffic of the undesirable application is relative to the desirable application and only block the undesirable application-specific network traffic. For example, if an application communicates with two servers, one server being a well-known server used by many legitimate applications and the other server being an unknown server with which only this application communicates, server 151 will be considered as being unique to the undesirable application.

After determining the appropriate network traffic to block, server 151 generates a firewall or other network configuration rule for blocking network traffic of the undesirable application. For example, if a malicious application uses a particular server to steal screening of sensitive data from a person's phone, the behavioral data for the application may indicate the IP address, port, and protocol used to transmit the sensitive data. When an administrator wishes to block the ability of a malicious application to steal data, he or she can see the list of servers that the application communicates with and how many other applications the server 151 knows are typically communicating with the server. The administrator then has the ability to select which servers to block. After selecting a server to block, server 151 generates a rule to block network traffic. In one embodiment, server 151 enables configuration data, such asIntrusion detection and prevention system rules are available for download via a web interface. In thatIn one embodiment, server 151 is configured to interface directly with a network infrastructure management system to deploy configuration data.

Since administrators may be primarily concerned with a particular network, one embodiment of the present disclosure involves server 151 generating both an aggregate assessment and an operator-specific assessment for identifying potentially harmful applications and generating a user interface containing both. Aggregated behavior data may be within normal limits, for example, if an application is misbehaving only when running on a device connected to a particular type of mobile network; however, behavioral data for a particular network may be harmful. A network administrator may want to view the behavior of an application on the type of network he or she is supervising. Since various mobile networks may view different behaviors as abuses, a user on server 151 may configure criteria for considering applications that are harmful to the network.

In the description above and throughout the description, numerous specific details are set forth in order to provide a thorough understanding of the disclosure. It will be apparent, however, to one skilled in the art that the disclosure may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to facilitate explanation. The description of the preferred embodiments is not intended to limit the scope of the claims appended hereto. Additionally, in the methods disclosed herein, various steps are disclosed that illustrate some of the functionality of the disclosure. It will be understood that these steps are merely exemplary and are not intended to be limiting in any way. Other steps and functions may be conceived without departing from the disclosure.

Claims (20)

1. A method for a server computer to evaluate a data object, comprising:

receiving data at the server computer, the data identifying at least a portion of the data objects accessible to a mobile communication device;

determining whether definition information for a data object corresponds to the data, the definition information being stored in a data store accessible to the server, the data store storing corresponding evaluations for the definition information;

if definition information corresponds to the data, the server provides the evaluation corresponding to the definition information.

2. The method of claim 1, further comprising:

prior to the server computer receiving data, determining whether definition information stored in a local store of the mobile communication device that stores a corresponding evaluation for the definition information corresponds to the data; and is

Receiving at least a portion of the data from the mobile communication device at the server if the definition information in the local repository does not correspond to the data.

3. The method of claim 1, further comprising:

if the data does not correspond to definition information stored in the data store, the server analyzes at least a portion of the data to determine an evaluation; and is

Storing the assessment in the data store.

4. The method of claim 1, further comprising:

if the data does not correspond to definition information stored in the data store, the server analyzes at least a portion of the data to determine an evaluation;

the server requesting additional data relating to the data object accessible to the mobile communication device;

the server analyzing at least a portion of the additional data to determine an evaluation; and is

Storing the assessment in the data store.

5. A method for evaluating a data object, comprising:

the mobile communications device determining whether the definition information in the local repository corresponds to a data object accessible by the mobile communications device;

receiving data relating to the data object at a server computer if the definition information in the local store does not correspond to the data object;

the server computer determining whether definition information for a data object corresponds to the received data, the definition information being stored in a data store accessible to the server, the data store storing corresponding evaluations for the definition information; and is

If definition information corresponds to the received data, the server transmits the evaluation corresponding to the definition information.

6. The method of claim 5, further comprising:

if the definition information does not correspond to the received data, the server uses the received data to determine an evaluation for the data object.

7. The method of claim 5, further comprising:

the server requesting additional data relating to the data object accessible to the mobile communication device; and is

The additional data is analyzed.

8. A method for assembling data about one or more data objects accessible by at least one mobile communications device, the method comprising:

receiving data from a first mobile communication device of a plurality of mobile communication devices at a server, the server configured to authenticate the first mobile communication device, the data identifying a data object accessible to the first mobile communication device, the server further configured to use at least part of the data to provide an evaluation of the data object; and is

Storing at least a portion of the data on a data store accessible by the server such that the stored data is associated with the first mobile communication device.

9. The method of claim 8, further comprising:

the server authenticates the first mobile communication device.

10. The method of claim 8, further comprising:

receiving data from a second mobile communication device of the plurality of mobile communication devices at a server, the server configured to authenticate the second mobile communication device, the data identifying a data object accessible to the second mobile communication device, the server further configured to use at least part of the data to provide an evaluation of the data object; and is

Storing at least a portion of the data on a data store accessible to the server such that the stored data is associated with the second mobile communication device.

11. A method for assembling data about one or more data objects accessible by at least one mobile communications device, the method comprising:

a server transmitting a request to a first mobile communication device for data residing on the first mobile communication device;

the server receiving at least part of the data from the first mobile communication device;

transmitting, by the server, a request to a second mobile communication device for data residing on the second mobile communication device if the server does not receive at least part of the data from the first mobile communication device; and is

The server stores the received data portion from the first or second mobile communication device for the purpose of using the received data portion to provide an assessment.

12. A method for aggregating data regarding one or more mobile communication devices, the method comprising:

a server transmitting a first request to a first mobile communication device for data residing on the first mobile communication device;

the server receiving at least a first portion of data from the first mobile communication device;

the server transmitting a second request to a second mobile communication device for data residing on the second mobile communication device;

the server receiving at least a second portion of data from the second mobile communication device; and is

The server stores a first portion of the received data from the first mobile communication device and a second portion of the data from the second mobile communication device for the purpose of using the received data portions to provide the evaluation.

13. A method for a server to provide an evaluation of a data object, the method comprising:

receiving, at the server, data relating to the data object from a plurality of mobile communications devices, the data being generated by the plurality of mobile communications devices having accessed the data object;

The server processing the data received from the plurality of mobile communication devices to determine an evaluation for the data object; and is

Providing the evaluation for the data object.

14. The method of claim 13, wherein the data is generated by the plurality of mobile communication devices that have executed the data object.

15. The method of claim 13, wherein the evaluation is selected from the group consisting of battery usage information, memory usage information, CPU usage information, Application Program Interface (API) usage information, network usage information, privacy information, data usage information, and location query information.

16. A method for a server to provide an evaluation of a data object, the method comprising:

receiving, at the server, application data for the data object from a plurality of mobile communication devices;

the server processing the received application data to determine an evaluation for the data object; and is

Providing the evaluation for the data object.

17. The method of claim 16, further comprising:

prior to processing, receiving at the server device data for at least one of the plurality of mobile communication devices that has accessed the data object;

Wherein processing includes processing the received device data to determine an evaluation.

18. A method for a server to provide an evaluation of a data object, the method comprising:

receiving, at the server, data relating to the data object from a plurality of mobile communications devices, the data being generated by the plurality of mobile communications devices having accessed the data object;

the server processing the data received from the plurality of mobile communication devices to determine an evaluation for the data object;

the server receiving a request for the evaluation from a computing device having a type; and is

Providing the evaluation for the data object to the computing device, the evaluation based on the type of the computing device.

19. A system, comprising:

a server configured to receive data relating to a data object from a plurality of mobile communication devices, the server configured to determine an evaluation of the data object based on the data, the server further configured to provide the evaluation, the evaluation comprising a result of at least one of the plurality of mobile communication devices accessing the data object.

20. The system of claim 19, wherein the server is further configured to dynamically limit access to the data object by at least one of the plurality of mobile communication devices based on the evaluation.