CN104798355A - Mobile device management and security - Google Patents

Abstract

Systems are disclosed that include components and features for enabling enterprise users to securely access enterprise resources (documents, data, application servers, etc.) using their mobile devices. An enterprise may use some or all of the components of the system to implement, for example, a BYOD (carry-on-own device) policy securely but flexibly, where users can run personal applications and secure enterprise applications on their mobile devices. The system may, for example, use policies for controlling access of mobile devices to enterprise resources based on device attributes (e.g., what mobile applications are installed), user attributes (e.g., status or department of the user), behavioral attributes, and other criteria. Client-side code installed on a mobile device may further enhance security by, for example, creating a secure container for locally storing enterprise data, creating a secure execution environment for running enterprise applications, and/or creating a secure application tunnel for communicating with enterprise systems.

Description

Mobile Device Management and Security

incorporation by reference

This application claims priority to US Provisional Patent Application Serial No. 61/702,671 filed September 18, 2012 and incorporated herein by reference in its entirety. This US application also claims priority to US Patent Application Serial No. 13/649,076, filed October 10, 2012, entitled "GATEWAY FOR CONTROLLING MOBILEDEVICEACCESS TO ENTERPRISE RESOURCES," which is incorporated herein by reference in its entirety. This application is also incorporated herein by reference in its entirety: U.S. Patent Application Serial No. 13/649,064, filed October 10, 2012, entitled "PROTECTING ENTERPRISE DATA THROUGH POLICY BASED ENCRYPTION OFMESSAGE ATTACHMENTS"; U.S. Patent Application Serial No. 13/648,993 for "PROVIDING SECURE MOBILE DEVICEACCESS TO ENTERPRISE RESOURCES USING APPLICATION TUNNELS"; U.S. Patent Application Serial No. 13/64 entitled "SECURE EXECUTION OF ENTERPRISE APPLICATIONS ONMOBILE DEVICES," filed October 10, 2012 ; U.S. Patent Application Serial No. 13/649,022, filed October 10, 2012, entitled "MODIFYING PRE EXISTING MOBILE APPLICATIONSTO IMPLEMENT ENTERPRISE SECURITY POLICIES"; U.S. Patent Application Serial No. 13/649,063; filed October 10, 2012, entitled "SECURE CONTAINERFOR PROTECTING ENTERPRISE DATA ON A MOBILE DEVICE"; filed October 10, 2012 titled U.S. Patent Application Serial No. 13/649,071 for "RULESBASED DETECTION AND CORRECTION OF PROBLEMS ON MOBILEDEVICES OF ENTERPRISE USERS"; U.S. Patent Application Serial No. 13/ 649,073. In addition, this application hereby incorporates by reference the entire technical disclosure of US Provisional Patent Application Nos. 61/546,021, 61/546,922, and 61/649,134. This application also hereby incorporates by reference the entire technical disclosure of US Patent No. 7,788,536 to Qureshi et al. ("Qureshi '526").

background

field

The present application relates generally to mobile computing devices (smartphones, tablets, PDAs, etc.) and related applications, and to systems for automatic or semi-automatic management of devices accessing managed resources of an enterprise.

Description of related technologies

Many businesses (e.g., corporations, partnerships, academic institutions, etc.) maintain enterprise computers that allow business users to access enterprise resources such as hardware and software applications such as email, customer relationship management (CRM), document management, enterprise resource planning (ERP), etc. network. In addition, many enterprises allow users to access the enterprise network via mobile devices such as smart phones, tablet computers, and the like. In some cases, a software application running on a mobile device exchanges data with an enterprise network, some of which may be saved on the mobile device's memory hardware (eg, hard drive, SD card).

A growing trend among enterprises is to allow employees to use their personally owned mobile devices to access corporate resources and use and access their personal applications and data. Known as BYOD (bring your own device) or BYOT (bring your own technology), this trend considerably complicates the task of securing enterprise resources, including confidential and/or sensitive information.

Brief description of the drawings

Figure 1A is a schematic diagram of an embodiment of an enterprise computer system and a mobile computing device associated with the enterprise.

Figure IB is an embodiment similar to Figure IA, with the mobile device management system located in a cloud computing system ("the cloud").

Figure 1C is an implementation similar to Figure 1A, with the meta-application located in the cloud.

Fig. 1D is an embodiment similar to Fig. 1A, the secure mobile gateway is located in the firewall.

Figure IE is an embodiment similar to Figure IA, with the secure mobile gateway located at an enterprise resource.

Figure IF illustrates a mobile device screen display including selectable screen elements for exposing a user interface for selecting and launching an enterprise application.

Figure 1G shows a user interface for selecting and launching an enterprise application.

2 is a schematic diagram of an embodiment of a mobile device management system of the enterprise computer system of FIG. 1A.

3A is a schematic diagram of an embodiment of a mobile device.

Figure 3B illustrates security-related components and applications that may be installed on a mobile device.

4 is a schematic diagram of an embodiment of a gateway for securely allowing or denying requests from mobile devices to access enterprise computer systems.

5 is a flowchart illustrating an embodiment of a method in which an enterprise proxy of a mobile device redirects communications of a mobile device application to an enterprise resource through an application tunnel.

6 is a flowchart illustrating an embodiment of a method in which an enterprise computer system participates in the formation of an application tunnel between a mobile device application and an enterprise resource.

7 is a flowchart illustrating an embodiment of a method in which an enterprise computer system regulates access to enterprise resources by mobile devices.

8 is a schematic diagram of an embodiment of a partially cloud-based meta-application for managing an enterprise computer system, a mobile device management system, and/or a gateway for allowing or denying requests from mobile devices to access an enterprise computer system .

9 is a flowchart illustrating an embodiment of a method in which a mobile device detects and handles security-related or productivity-related issues using coding rules and remedial actions.

10 is a flowchart illustrating an embodiment of a method in which a mobile device caches data entered by a user in response to a loss of network connectivity to an enterprise computer system.

11 is a flowchart illustrating an embodiment of a method in which an enterprise computer system caches data to be sent to a mobile device when the network connection to the mobile device is lost.

12 is a schematic diagram of an embodiment of a controller computer for remotely controlling a mobile device.

Figure 13 is a flowchart illustrating an embodiment of a method in which a controller computer participates in a remote control session with a mobile device.

14 illustrates an embodiment of a screen display of a controller computer participating in a remote control session with a mobile device, including system information for the mobile device.

15 illustrates an embodiment of a screen display of a controller computer participating in a remote control session with a mobile device, including access to the task manager of the mobile device.

16 illustrates an embodiment of a screen display of a controller computer participating in a remote control session with a mobile device, including an interface for file transfer between the controller computer and the mobile device.

Figure 17 illustrates an embodiment of a screen display of a controller computer participating in a remote control session with a mobile device, including an interface for editing the mobile device's registry.

Figure 18 is a flowchart illustrating an embodiment of a method in which a mobile device participates in a remote control session with a controller computer.

Figure 19A illustrates an embodiment of a screen display of a controller computer participating in a remote control session with a mobile device, including a chat session interface.

Figure 19B illustrates the embodiment of the mobile device simulated in Figure 10A.

20 illustrates an embodiment of a screen display of a controller computer participating in a remote control session with a mobile device, including a shared whiteboard feature.

Figure 21 illustrates an example of data recorded by a mobile device gateway that may be provided to an analytics service, according to one embodiment.

Figure 22 shows an example of an interface for configuring the criteria under which the analytics service sends alerts based on data recorded by the mobile device gateway.

Figure 23 illustrates an embodiment of a method by which an analytics or network intelligence service assists in authenticating a user associated with a mobile device access request.

Figure 24 illustrates an embodiment of a software development kit for embedding, for example, enterprise protection functionality into a mobile device software application.

Figure 25 illustrates an embodiment in which an application tunnel is created using a proxy running on the mobile device.

Figure 26 shows a user interface (eg, web page) for enabling an administrator to create a tunnel between a mobile device and an application server.

Figure 27 shows representative communications and events that occur when an application tunnel is created between the mobile device and the application server for the embodiment of Figure 25 .

Figure 28 illustrates additional communications and events that occur when an application tunnel is established as a secure application tunnel.

Figure 29 illustrates an application modification system that enables the behavior of a mobile application to be modified without requiring the application's source code and without requiring a programmer or programming skills.

FIG. 30 illustrates one embodiment of a process used by the system of FIG. 29 to modify a mobile application.

31 illustrates representative communications and events that occur when a mobile device retrieves a message with an attachment from an enterprise resource, according to an embodiment.

32 illustrates representative communications and events that occur when a mobile device forwards a message with an attachment, according to an embodiment.

33 illustrates representative communications and events that occur when a mobile device forwards a message with an attachment, according to another embodiment.

Figure 34 is a flowchart illustrating an embodiment of a method of encrypting an attachment.

Figure 35 is a flowchart illustrating an embodiment of a method of decrypting an attachment.

Reference numbers used in this specification are generally based on the first figure in which the number appears (in the list above). Reference numbers with values between 100-199 first appear in Figure 1 , reference numbers with values between 200-299 first appear in Figure 2, and so on.

Skilled artisans will recognize that while certain figures of this disclosure show a number of items, those figures illustrate certain implementations and that other implementations may involve more or fewer items than shown.

Detailed Description of Specific Embodiments

Various inventions and inventive features are now described with reference to the accompanying drawings. As will be appreciated, many of the disclosed features and related components can be used independently of each other and implemented differently than described herein. Therefore, nothing in this detailed description (or in the preceding background section) is intended to imply that any particular feature, component or characteristic of the disclosed systems is essential. Also, it will be understood that headings are provided for convenience and do not necessarily affect the scope or meaning of the claims.

introduce

The architecture described in this specification can be used by corporations or other businesses to flexibly implement policies for allowing business users to use their mobile devices to securely access corporate resources (documents, confidential data, corporate application and database servers, etc.), Examples include company-owned devices, BYOD (bring your own device) policies. This is accomplished through, for example, various security features that enable an enterprise to specify and enforce policies for controlling mobile device access to specific enterprise resources. Policies may be based, for example, on various criteria such as the role of the respective user (e.g., which department the user is in), the configuration of the mobile device (e.g., whether any mobile applications that are blacklisted are installed), the user's recorded behavior, mobile device Control mobile device access to enterprise resources based on the location and/or time when access to enterprise resources is requested. In some implementations, the architecture further enhances security by creating application tunnels that enable enterprise mobile applications to communicate securely with enterprise systems over the network. The architecture can also enable IT staff to selectively access data from a user's mobile device when, for example, the user breaks employment or violates company policy (for example, if they jailbreak their device or otherwise use it in a configuration that is not allowed). (And remotely) wipe enterprise applications and company data.

As described in the section entitled "Protecting Attachment Data," the disclosed architecture can also implement an attachment encryption policy where encryption is applied to email attachments (or other types of messages such as attachments to SMS messages). This feature reduces the probability that an unauthorized user who has access to an enterprise member's mobile device will be able to access sensitive enterprise documents sent as attachments between enterprise users.

In some implementations, the disclosed architecture advantageously enables end users to run enterprise mobile applications (those configured or authorized to access enterprise resources) and personal (non-enterprise) mobile applications concurrently on the same mobile device without endanger safety. This can be accomplished in part through mobile device software, which creates a secure environment, or shell, in which enterprise mobile applications can run and store data. This secure environment or shell may, for example, prevent personal applications installed on the mobile device from accessing documents and other data stored on the mobile device through enterprise applications. In some implementations, the secure launcher running on the mobile device enhances the UI of the mobile operating system with the UI for launching enterprise mobile applications installed on the mobile device. When the user launches the enterprise mobile application, the user may, for example, be presented with an authentication screen for entering a personal password necessary to run the enterprise mobile application.

The use of passwords (or other types of authentication information) for enterprise applications reduces the probability that enterprise resources will be used inappropriately when, for example, the mobile device is lost or stolen, or when the mobile device is used by an employee's child to play games. In some implementations, the secure enabler (or another component installed on the mobile device) executes the mobile device's Selective erasure further reduces this risk. Selective wipe removes some or all corporate applications and related data from a mobile device without deleting any personal applications or data. In some embodiments, an enterprise's IT department can initiate a selective wipe of a particular mobile device by remotely issuing a wipe command to the device.

The architecture can also support various other types of remedial actions for protecting enterprise resources. One such remedy is to lock the mobile device or the corporate container on the device that stores corporate data such that the mobile device or container can only be unlocked using a valid code provided by IT staff. In some implementations, these and other types of remediation can be invoked automatically based on conditions detected on the mobile device, or can be initiated remotely by IT staff.

This specification also discloses a process for creating and enhancing mobile applications to enable them to use various enterprise security features. One such method is described below under the heading "Modifying the Behavior of a Pre-Existing Mobile Application." Using this approach, organizations can modify existing mobile applications to add various security features without requiring access to such applications' security code. The modified mobile application may be, for example, a custom enterprise application, or may be a commercially available mobile application configured for use within the enterprise. Through this process, a pre-existing mobile application can be configured, for example, to (a) use an application tunnel to communicate with an enterprise system, (b) use an encryption library to encrypt documents and other data it stores on the mobile device, (c) when Present a login or password screen to the user when the mobile app is launched, (d) disable cut, copy, and paste operations, (e) disable offline access, (f) use certain types of user authentication methods such as gesture-based authentication, or combination. The ability to modify pre-existing mobile applications through this process gives businesses greater flexibility in choosing mobile applications to offer to their members; for example, rather than requiring employees to use custom-developed enterprise applications for accessing cloud-based storage , an enterprise may modify (or have modified) a popular commercially available mobile application that a user is already familiar with. Furthermore, different versions of a given application can be created (using different authentication methods, encryption levels, etc.) for different types of employees.

Also disclosed are processes for efficiently adding enterprise security features to mobile applications with little or no modification of the application code of such applications. One such approach involves the use of a secure virtual machine separate from the virtual machine of the mobile device's operating system. The secure virtual machine implements or provides access to various enterprise security features (such as application tunneling, data encryption, password prompting, etc.), and these security features are inherited by or imposed on the mobile application running in the secure virtual machine running mobile application. Enterprise mobile applications can be configured or forced to use a secure virtual machine, while non-enterprise mobile applications continue to run within the native virtual machine of the mobile operating system. This capability gives the enterprise additional freedom to flexibly select mobile applications to use as enterprise applications; for example, through this method, enterprises can effectively configure users' mobile devices to enable users to use popular/familiar mobile applications to securely access enterprises resource.

The use of secure virtual machines can enable enterprises to provide a higher level of security for running enterprise applications on BYOD devices. For example, by running applications within the secure execution environment created by secure virtual machines, companies can enforce a separate set of policies for applications, including networking and storage policies.

Another approach described under the heading "Secure Web Browser" involves the use of a mobile browser application that implements various enterprise security features. Like the secure virtual machine approach, a mobile application (or web page accessed by a browser) configured to run within a secure browser effectively inherits the security mechanisms implemented by the secure browser. The use of such secure browsers also enables enterprises to implement content filtering policies where, for example, employees are blocked from accessing certain websites from their mobile devices. A secure browser can be used, for example, to enable mobile device users to access a corporate intranet without requiring a virtual private network (VPN).

The disclosed architecture may also include meta-applications or systems that monitor overall enterprise systems, including enterprise users' mobile devices. Meta-applications may generally operate as described in Qureshi '526, and may be implemented as cloud-based meta-applications. Data collected by meta-applications may include data collected and reported by enterprise agents running on mobile devices. In some implementations, the meta-application generates rules based on observed behavior, including behavior of mobile device users. These rules may include gateway rules used by the secure mobile gateway to allow and deny mobile device requests to access enterprise resources.

These and other safety features and components are described in detail in the following sections. As will be appreciated, many of the disclosed features and components can be used independently of each other. Accordingly, nothing in the following description should be read as implying that certain security features and components must be used in combination.

System Overview and Terminology

In many cases, when a mobile computing device accesses an enterprise computer/IT system, sensitive data related to the enterprise and/or enterprise-related software applications may be stored on the mobile device. Business-related data may include any data related to the business, such as without limitation production information, sales data, customer lists, business performance data, know-how, inventions, trade secrets, and the like. Because this information can be very sensitive, an enterprise may wish to protect such information.

Additionally, businesses may wish to regulate how users use their mobile devices. For example, an enterprise may want to have some control over where a mobile device is used, which mobile device features may be used, which software applications may be installed and/or run on the device, and the like. Enterprises also need to control and implement remedial actions for users who violate their mobile device usage policies.

When users in the field experience issues with their mobile devices or could benefit from information, data, software, or guidance on how to perform certain actions with the device, it can be difficult for an enterprise's IT support to provide highly effective assistance. Accordingly, there is also a need for improved security management and technical support of enterprise-related mobile devices.

The implementations described in this application address these and other concerns. The present application discloses computer systems and methods for automatically and semi-automatically managing mobile computing devices accessing an enterprise computer network, such as accessing computer-implemented resources of an enterprise. As used herein, a "business" may include virtually any type of organization including, without limitation, businesses, partnerships, corporations, and the like. A "mobile computing device" may include any of a wide variety of devices such as, without limitation, mobile phones, smartphones, personal digital assistants, tablet computers, handheld computing devices, and the like. Mobile devices managed by the disclosed system may, for example, include mobile devices running Android ^™ , IOS or Windows Mobile operating systems (or some subset thereof) or mobile devices running Android ^™ , IOS or Windows Mobile operating systems (or some subset thereof) ) of mobile devices. However, as will be appreciated, the architecture disclosed herein may be used with other mobile device operating systems, such as operating systems that may be developed in the future.

A person, entity, or group of users who use a mobile computing device to access an enterprise computer network is referred to herein as a "user." Users may include members of the business, such as employees, partners, officers, and the like. Alternatively, a user may include a person or entity who is not a member of an enterprise but nonetheless has a need or reason to access the enterprise computer network. For example, a user may be a business customer, a supplier, and so on.

"Enterprise resources" may include machine-accessible resources associated with an enterprise. Enterprise resources may include any of a variety of different types of resources, including resources that assist or enable a user to perform the user's role or responsibilities associated with the enterprise. For example, enterprise resources may include raw data stored on non-transitory computer readable storage, documents stored on non-transitory computer readable storage (such as physical servers), computer hardware (such as physical servers), Software applications on read memory, macros for software applications stored on non-transitory computer readable memory (such as word processor macros), email systems, workspaces, consumer relationship management (CRM) systems, document management systems, enterprise Resource planning (ERP) systems, billing systems, inventory systems, engineering design tools, forms, style sheets, and many other resources. Enterprise resources can be configured to be accessed and used by software applications installed and run on mobile computing devices.

1A is a schematic diagram of an embodiment of an enterprise-related computer system 110 and one or more users 115 and an enterprise-related mobile computing device 120 . In this example, each mobile device 120 is assigned to an enterprise user 115, but alternatives are possible (e.g., multiple users 115 are assigned to one device and/or a single user is assigned to multiple devices 120) . Mobile device 120 is preferably configured to communicate with enterprise system 110 (also referred to herein as an "enterprise network") over communication network 125 . The communication network 125 may include a wireless carrier network, the Internet, a wide area network, a WIFI network, and the like. Thus, network 125 may include, for example, one or more wireless networks, one or more wired networks, or a combination of wired and wireless networks. Additionally, enterprise system 110 may be configured to be accessed by non-mobile computing devices, such as desktop computers.

Enterprise system 110 preferably includes external firewall 122 and internal firewall 124 . Each firewall 122, 124 may include a device or group of devices designed to allow or deny network transmissions based on certain criteria. Firewalls 122 and 124 may include software, hardware, firmware, or a combination thereof stored on non-transitory computer readable memory. Firewalls 122 and 124 may be configured to perform basic routing functions. Embodiments of the present invention may cooperate with one or both of firewalls 122 and 124 or other devices of enterprise system 110 to filter access requests from mobile devices based on a set of gateway rules in order to protect enterprise system 110 from unauthorized access while allowing legitimate communications to pass. As described in more detail below, such access rules may be used to regulate access based on, for example, mobile device characteristics, user characteristics, specific enterprise resources 130 to which access is requested, or any combination thereof.

The physical or logical subnetwork between the two illustrated firewalls 122 and 124 may be referred to as a "demilitarized zone (DMZ)" or alternatively a "perimeter network." Typically, the DMZ contains and exposes the enterprise's external services to a larger untrusted network, usually the Internet. Typically, the purpose of a DMZ is to add an extra layer of security to an enterprise's local area network (LAN); external attackers only gain access to devices within the DMZ, not any other part of the enterprise network.

The illustrated enterprise system 110 includes a mobile device management system 126, a secure mobile gateway 128, and "meta-apps" 150, each of which are described in more detail below. Enterprise system 110 also includes enterprise resources 130 logically located behind internal firewall 124, shown as resources 1-N. At least the following enterprise resources 130 may be configured to be accessed and/or used by mobile device 120, eg, by a software application installed and running on the mobile device.

Still referring to FIG. 1A , the mobile device 120 can communicate with the carrier network 125 via a connection 142 that ultimately connects to the carrier network, such as a cellular network connection and/or a WIFI connection. A mobile device's enterprise access request can be sent to secure mobile gateway 128 via connection 146 , and gateway 128 can send the request to enterprise resource 1802 via internal connection 154 . In addition, the enterprise system 110 can use the connections 142, 146 to send information back to the mobile device 120, such as data in response to the device's enterprise access request.

In some implementations, software applications on mobile device 120 can communicate with enterprise resource 130 via connections 142 , 144 , and 152 through an application tunnel. Application tunneling is described in more detail below. In the illustrated embodiment, mobile device management system 126 acts as a "tunnel broker" within an application tunnel between mobile device 120 (and generally specific applications running on the mobile device) and enterprise resource 130 .

Figures 1B and 1C illustrate an implementation similar to Figure 1A, except that mobile device management system 126 and meta-application 150, respectively, are housed (completely or at least partially) in a cloud computing system or environment 156 ("the cloud"). (In a hybrid of these two approaches, both mobile device management system 126 and meta-application 150 reside in the cloud.) Cloud computing systems generally include computing resources configured to implement services over a network, such as the Internet. For example, a cloud computing system may include multiple distributed computing resources, such as physical servers or other computing devices. With a cloud computing system, computing resources may be located at any suitable location accessible via a network. Cloud computing systems store and process data received over a network while being accessible from remote locations. Typically, cloud computing systems are operated by service providers who charge businesses and other users of cloud-based computing systems a royalty for using the system. In some implementations, both the mobile device management system 126 and the meta-application 150 reside at least partially in the cloud 156 . In the FIG. 1B embodiment, cloud-based device management system 126 may be configured to provide gateway rules to secure mobile gateway 128 via connection 158, as described in more detail below. Additionally, software applications on mobile device 120 can communicate with enterprise resource 130 via connections 142, 160, and 162 through an application tunnel, with mobile device management system 126 acting as a tunnel intermediary. In the FIG. 1C embodiment, meta-application portion 151 located in cloud 156 may be configured to provide gateway rules to secure mobile gateway 128 via connection 164, as described in more detail below. Meta-application 151 (or its rules engine) may optionally be incorporated into mobile device management system 126 , in which case it may coordinate the management of mobile device management system 126 .

FIG. 1D is an embodiment similar to FIG. 1A , with secure mobile gateway 128 implemented in firewall 122 . In the embodiment of FIG. ID, secure mobile gateway 128 may be implemented in a threat management gateway (TMG) server. As shown in FIG. 1D , some embodiments of enterprise system 110 may be implemented without internal firewall 124 .

FIG. 1E is an implementation similar to FIG. 1A , with secure mobile gateway 128 implemented in enterprise resource 130 . In the embodiment of FIG. 1E , secure mobile gateway 128 may be implemented in an Internet Information Services (IIS) server. Such IIS may be configured as enterprise resource 130 and/or internal firewall 124 .

It will be appreciated that any enterprise system 110 may be implemented using any of the principles and advantages described herein, as appropriate. Furthermore, it will also be understood that the enterprise system shown in Figures 1A-1E is provided for illustrative purposes only and that other suitable systems can be implemented in accordance with the principles and advantages described herein.

FIG. 2 is a schematic diagram of an embodiment of the mobile device management system 126 of FIG. 1A . Mobile device management system 126 may include a system of one or more computers, computer servers, storage devices, and other components. As explained in more detail below, mobile device management system 126 may be configured to manage or co-manage the application of "mobile device rules" 214 to mobile computing devices 120, and/or between mobile devices 120 and enterprise resources 130 The tunnel acts as a "tunnel broker" during its use. Mobile device management system 126 may also be configured to regulate mobile device access to enterprise system 110, for example, during the use of such application tunnels. The illustrated components of system 126 are described below.

FIG. 3A is a schematic diagram of an embodiment of a mobile computing device 120 . The mobile device 120 may include many common or standard components of a mobile device, such as a power supply 301, a processor 302, a user interface 304, a hard drive memory 306, a memory card (such as a Secure Digital (SD) card) port 307, random access memory 308 , network interface 310 , Subscriber Identity Module (SIM) card port 312 , camera 314 and/or GPS chip 316 . The implementation and use of these components are generally known and have not been discussed in considerable detail herein. The power supply 301 may include a battery port, a battery, and/or a port for receiving electrical power from an external source (eg, a standard electrical outlet). Processor 302 may be configured to execute software applications and various other executable components. User interface 304 may include any of a variety of known components, such as a keypad 324 for receiving text input (e.g., a set of physical buttons or, alternatively, a touchscreen keypad), for displaying text, images, and/or A screen or display 326 (which may be a touch screen) for video or video, a speaker 328 or audio output port for producing audible output and/or a microphone 330 for receiving audible input. Hard drive 306 may include any of various different types of non-volatile and/or non-transitory computer-readable memory. The memory card port 307 is configured to accept a memory card (eg, SD card) on which data may be stored. Random access memory 308 may be used to store data used during the operation of various processes. Network interface 310 may be used to send and receive data over a network, such as wireless network 125, which may operate according to a number of standards such as Wi-Fi, 3G, 4G, etc. SIM card port 312 is configured to accept a SIM card, as is known in the art. Camera 314 may be configured to capture images and/or video. GPS chip 316 may be configured to process GPS signals. Mobile device 120 may also include one or more installed software applications 318 . Installed software applications 318 may be stored, for example, on hard drive 306 or in non-volatile solid-state memory. Installed applications may include enterprise applications and personal applications. It will be appreciated that mobile device 120 may include any other computer hardware components, such as accelerometers, transceivers, battery chargers, USB controllers, baseband processors, audio codecs, instead of or in addition to those shown in FIG. Encoder, etc.

In the illustrated embodiment, mobile device 120 includes enterprise agent 320, which is preferably a software application or other executable program installed on the mobile device. Enterprise agent 320 is preferably separate from the operating system of mobile device 120 . In some implementations, however, the enterprise agent 320 may be a component of or partially/fully embedded in the operating system of the mobile device 120 . In various implementations described in more detail below, enterprise agent 320 enforces mobile device rules 214 and cooperates with enterprise system 110 to regulate mobile device access to enterprise system 110 , including to enterprise resources 130 . In some implementations, enterprise system 110 may prompt enterprise agent 320 to connect to system 110 (eg, mobile device management system 126 ) by sending a text message (eg, SMS) to mobile device 120 using a connect command.

Enterprise agent 320 may be installed on mobile device 120 as a condition of the mobile device's registration with mobile device management system 126 . Businesses may use an automated subsystem for installing business agents 320 on mobile devices 120 associated with (eg, registered with) the business. For example, mobile device manager 202 may be configured to send enterprise agent 320 to mobile device 120 for automatic installation or manual installation by user 115 . Alternatively, IT staff can manually install the enterprise agent 320 onto the mobile device 120, or an end user can download and install the enterprise agent 320 from a commercially available application store. Different types of enterprise agents 320 may be provided for different mobile device types, platforms, operating systems, and the like. Mobile device manager 202 or another software component of enterprise system 110 may be configured to select an appropriate enterprise agent 320 for each given mobile device 120 based on such characteristics of mobile devices 120 (e.g., mobile device characteristics 208 of FIG. 2 ). .

Enterprise agents and other security components installed on mobile devices

Enterprise agent 320 may implement various security-related features, including features that control mobile device access to enterprise resource 130 (or enable control of mobile device access to enterprise resource 130). For example, an enterprise agent 320 installed on a given mobile device 120 may perform (i.e., instruct or cause the mobile device 120 to perform) some or all of the following tasks: (1) maintain a data connection with the enterprise system 110, which may be used for Both application tunneling and communications not involving application tunneling; (2) providing access to public or private enterprise application stores from which users can download enterprise (3) create application tunnels for enterprise applications installed on mobile devices to securely access certain enterprise resources; (4) collect characteristics and configurations about mobile devices such as their manufacturer, model, operating system, "Inventory" data of screen size, memory size, memory availability, GPS coordinates, and which personal and business mobile applications are installed on the device and transmits this data to the mobile device management system 126; Other authentication services that request and verify the user's authentication information (such as a password) when the enterprise mobile application; (6) Encrypted message attachments received from the secure mobile gateway 128, such as encrypted attachments of email messages received from other members of the user's enterprise decryption; (7) maintaining a secure key store accessible by enterprise applications for deriving keys used to encrypt and decrypt data; (8) checking for blacklisted mobile applications installed on mobile devices and sending The mobile device management system reports any such applications; (9) performs preventive actions when certain conditions are met, such as when a blacklisted mobile application is detected on the mobile device or the device is reported as stolen, such as Delete the decryption key used to decrypt message attachments; (10) Terminate any blacklisted applications or other mobile applications that are determined to pose a security risk (terminate any blacklisted applications or are determined to pose a security risk execution of other mobile applications); (11) provide one or more additional services for keeping enterprise applications and data on the device separate from personal applications and data; and (12) , all enterprise applications and data are erased from the device (in response to a command received from the mobile device management system). Some of these functions may optionally be implemented in a separate mobile application or component than enterprise agent 320, as described below.

Enterprise agent 320 collects information about the configuration of the mobile device using standard operating system APIs and mechanisms and/or using its own APIs and mechanisms. For example, in an implementation of the Android operating system, the enterprise agent may query the package manager for a list of applications installed on the device. The enterprise agent can similarly query the operating system for a list of currently running mobile applications, and can monitor broadcast messages to identify new applications being installed. Device configuration information collected by enterprise agents through this process may be reported to mobile device management system 126 , which may use the information to generate rules applied by secure mobile gateway 128 to control mobile device access to enterprise resources 130 . Enterprise agent 320 itself may also use the collected device configuration information to take various preventive actions, such as ending blacklisted mobile applications, as mentioned above.

In one embodiment, the enterprise agent 320 is a mobile application (or part thereof) that can be downloaded from an application store and installed on the mobile device 120 . Once the enterprise agent is installed and started, the end user provides configuration information, such as a corporate email address and email password, for enabling the agent to communicate with a particular enterprise system 110 . Once configured, agent 320 provides the user with access to a secure application store from which the user can download and install enterprise mobile applications approved by, and in some cases specifically configured for, the user's enterprise. Functionality for downloading and installing the enterprise mobile application may optionally be embedded within a separate "secure launcher" mobile application that runs in conjunction with the enterprise agent.

FIG. 3B shows some executable security-related components 350 that may be installed or implemented on mobile device 120 using or as part of enterprise agent 320 . As will be appreciated, some of these components 350 may be installed without others, and the components shown may be combined in various ways. One component is a key store 350A that stores one or more encryption keys. In one embodiment, the key store is implemented and managed by an enterprise agent 320 that enables enterprise applications to access the key store for encryption keys. A given enterprise application may encrypt files and other data stored to memory 348, for example, using an encryption key.

With further reference to FIG. 3B , a secure launcher 350B may also be installed on the mobile device 120 for launching enterprise applications. The secure launcher can be part of the enterprise agent 320, or can be a separate mobile application. Security launcher 350B may implement or enforce various security policies, such as requiring a user to enter a valid password when an enterprise application is launched. One embodiment of a user interface implemented by secure enabler 350B is shown in FIGS. 1F and 1G and described below. As described below, enterprise applications can be modified or written to use a secure launcher rather than a generic launcher included in the mobile device's operating system. In one embodiment, the secure enabler also includes functionality for erasing all enterprise applications and data from the mobile device 120 in response to a threshold number of consecutive invalid passcode entry attempts or in response to a remotely issued command from the enterprise's IT department .

As further shown in FIG. 3B , in some embodiments a secure virtual machine 350C may be installed on the mobile device 120 to create or enhance a secure execution environment for running some or all enterprise applications. This secure virtual machine (VM) complements and can run concurrently with the mobile operating system's default VM. For example, one or more enterprise mobile applications can run within a secure VM, while all other mobile applications—including all personal mobile applications—run on the same device in the operating system's default VM. As described below under the heading "Security Virtual Machine," the Security VM 350C implements various policies and measurements (e.g., security, management, storage, , networking and/or process execution strategies). For example, a secure VM may be able to establish an application tunnel for access to an enterprise system and may route requests from the enterprise application through the corresponding application tunnel. The secure VM may also prevent enterprise applications from running unless and until the user enters a valid password or otherwise successfully authenticates. The secure VM may be installed on the mobile device with a set of code bases used by the secure VM instead of the corresponding code base of the operating system.

One benefit of using the secure VM 350C is that it reduces or eliminates the need for mobile applications that are specially written or modified for use with the enterprise system 110. For example, an enterprise may wish to make a particular commercially available mobile application available to its employees for access to corporate resources, but may not have modified the application to implement the various security features described herein (e.g., authentication, secure storage, and secure networking). ) permission. In such a situation, the enterprise can configure the mobile application or mobile device so that this particular application, when executed, only runs within the secure VM.

Secure VM is preferably implemented as a separate mobile application, but may alternatively be part of another application or component (eg, enterprise agent 320 or secure launcher 350B). A secure VM can be invoked in various ways: for example, a security agent can request a secure VM to run a particular application, or an application can request or specify a secure VM as its execution environment when launched. In some embodiments, secure launcher 350B and secure VM 350C are used in combination to create a secure space for running enterprise applications, although each can be used independently of the other. Additional details of the Secure VM are described below in the section entitled "Secure Virtual Machine".

As further shown in FIG. 3B , secure container component 350D may also be installed on mobile device 120 , preferably as a stand-alone mobile application or as part of enterprise agent 320 . This component 350D is responsible for creating secure containers for enterprise applications on the mobile device to store documents and other information. One implementation of this feature is described below under the heading "Secure Document Container". In some implementations, some or all of the documents and data stored in the secure container are deleted from the mobile device or otherwise made inaccessible when the selective wipe operation is performed.

FIG. 3B also shows two types of mobile applications 318 that can be installed on the mobile device 120: enterprise applications 318A and personal applications 318B. As shown, enterprise application 318 may include executable secure code 360 (code library, etc.) for implementing some or all of the disclosed client-side functionality (application tunneling, password authentication, encryption of data, etc.). This security code 360 can be added via a special SDK, or can be added after development via the application packaging process described below in the section entitled "Modifying the Behavior of a Pre-Existing Mobile Application". As mentioned above, in some cases, a given enterprise application may not include any secure code 360, but instead runs within a secure VM 350C or secure browser that imposes One layer of security.

In addition to the components shown in Figure 3B, one or more code libraries may be installed on the mobile device for implementing various security functions, such as data encryption and application tunneling functions. As an example, a custom SSL library can be installed and used instead of the operating system's SSL library to create a secure application tunnel, as described below in the section entitled "Application Tunneling."

User interface for launching enterprise applications

In one embodiment depicted in FIGS. 1F and 1G , secure launcher 350B displays persistent display element 170 ( FIG. 1F ) at the edge of the mobile device's screen. This display element preferably remains visible in all home screens of the device and while the user is in the application. If the user clicks on this display element 170 or slides it to the left, a rotatable carousel or "wheel" (FIG. corresponding icon 174 of the folder). (The other icons 175 shown in FIGS. 1G and 1F generally correspond to personal mobile applications installed on the device and/or folders of such applications.) By rotating the wheel 174 via an up or down swipe gesture, the user can Additional icons 174 corresponding to additional enterprise applications or folders are made visible. Clicking on an application icon 174 causes the associated enterprise application to be launched, and clicking on a folder icon 174 causes the enterprise applications stored in the folder to be displayed. The user can also slide the wheel 172 to the right to return it to the retracted position shown in Figure IF. In the illustrated embodiment, enterprise applications can only be launched from the wheel (using the secure launcher), and cannot be launched using the device's operating system's generic launcher.

In some implementations, when a user launches an enterprise application via wheel 172, the user is prompted for a password and the application is not launched unless the correct password is entered. The task of requesting and verifying passwords can be added, for example, by enterprise agent 320 ( FIG. 3A ), by separate security enabler 350B ( FIG. 3B ), by secure virtual machine 350C ( FIG. 3C ), or by adding to an enterprise application via an SDK or application packaging process. The code 360 executes. These and other techniques for providing a secure execution environment for running enterprise mobile applications are described in further detail below.

In one embodiment shown in FIG. 1F , the wheel 172 is displayed as a transparent or translucent overlay that enables the user to view and select home screen icons 175 that fall "behind" the wheel, so that the user can activate personal application. In another embodiment, the wheel is opaque and thus obstructs the view of any icon 175 that falls behind it. In yet another embodiment, the home screen icon 175 disappears when the wheel is "pulled out" or pulled out beyond a certain point.

The secure launcher's user interface may also include features to enable the user, for example, to place icons 174 on wheel 172, control the location of the wheel (eg, which screen edge it extends from), and control the extent to which the wheel is displayed. The selectable element 170 (FIG. 1F) for pulling out and retracting the wheel is preferably persistent across all home screens of the device so that enterprise applications are easily accessible from any of these screens.

Overview of Mobile Device Management Systems

Referring to Figures 1A and 2, embodiments of the mobile device management system 126 are configured to create, edit, and provide gateway rules to the secure mobile gateway 128, as discussed in detail below. Mobile device management system 126 may also act as a tunnel intermediary for application tunnels between mobile devices 120 and enterprise resources 130 or other network resources within or even outside enterprise system 110 . The components of the illustrated mobile device management system 126 are now described.

The illustrated mobile device management system 126 includes a mobile device manager component 202 (FIG. 2), which preferably includes a software application running on one or more physical machines. Mobile device manager 202 may be configured to provision and maintain registration of mobile device 120 with an enterprise. Preferably, the mobile device manager 202 is configured to handle or participate in the provisioning and decommissioning of mobile devices 120 associated with the enterprise.

In the illustrated embodiment of FIG. 2, mobile device management system 126 includes mobile device information or attributes 204 stored in computer-readable or machine-readable memory. Mobile device information 204 preferably includes characteristics or attributes 208 of mobile device 120 registered with mobile device manager 202, such as device type or platform (e.g., platforms of iPhone ^™ , Android ^™ , Windows Mobile ^™ , etc.), device model, operating system Version, device capabilities and characteristics, identifiers of installed applications, etc. In some implementations, mobile device characteristics 208 are persistent characteristics (eg, device type, platform). In some implementations, mobile device characteristics 208 may also be characteristics that are subject to regular or periodic changes (eg, software or operating system versions, which mobile applications are installed, etc.). As mentioned above, various characteristics of a given mobile device may be determined and reported to the mobile device management system 126 by the enterprise agent 320 installed on the mobile device 120 . Device characteristic information may also be provided by a system administrator.

Mobile device information 204 may also include user-device assignment records 210 identifying which users 115 or user accounts are assigned to registered mobile devices 120 and roles 206 of users 115 within the enterprise. A user's role 206 generally relates the user 115 to enterprise-related duties or activities in which the user is engaged. A role 206 may have a name and optionally an associated specification. Roles 206 (and role names) may mimic the department and job hierarchy structure of an enterprise. For example, an enterprise may specify roles with titles such as upper management, senior staff, sales department, accounting, engineering, word processing, human resources, and the like. In this scenario, a salesperson could be given the role "Sales Department", an engineer could be given the role "Engineering", and so on. Furthermore, the roles 206 can be defined broadly or narrowly as may suit the needs of the enterprise. For example, an enterprise may give all of its engineers the role of "Engineering Design". Alternatively or in addition, businesses may wish to specify narrower roles such as "Computer Engineer", "Materials Engineer", "Semiconductor Process Engineer", etc., especially if the business wishes to differentiate between its different types of mobile devices for engineering employees authorized. Additionally, user 115 may be assigned to number of roles 206 according to the user's responsibilities or activities related to the enterprise. In certain embodiments, an enterprise may use an RBAC (role-based access control) system to help govern enterprise resources 130, and user roles 206 may be related to or identical to roles specified in the RBAC system.

Enterprise agent 320 of mobile device 120 may be configured to send device-related data to mobile device management system 126 periodically and/or whenever mobile device 120 connects to mobile device management system 126 (eg, when an application tunnel is formed). For example, enterprise agent 320 may send data related to software applications installed on mobile device 120, software upgrades, system information, etc., as described above. In one embodiment, proxy 320 sends such device characteristic information over the same connection that is used for application tunneling, but without using application tunneling.

With continued reference to FIGS. 1A and 2 , the mobile device management system 126 may include one or more enterprise access policies 218 stored in computer memory. Access policies 218 preferably specify the conditions under which mobile device access to enterprise resources 130 will be permitted or denied. In some implementations, a single access policy 218 may apply to mobile devices 120 of different makes, models, operating systems, or any combination thereof. Policy 218 may depend on user role 206, mobile device characteristics 208, the particular enterprise resource 130 being requested to be accessed by mobile device 120, or any combination thereof. Mobile device management system 126 may use access policy 218 to process mobile device access requests received directly by mobile device management system 126 , including requests received via a secure application tunnel. Additionally, as described below, the secure mobile gateway 128 may utilize an access policy 218 to allow or deny mobile device access requests received directly by the secure mobile gateway 128 .

As shown in FIG. 2, the mobile device management system 126 may include a script editing tool 220 for editing scripts executable on the mobile device 120, as described below. Mobile device management system 126 may also include tools 221 for editing mobile device rules 214 and remedial actions 216, as described below.

The mobile device management system 126 may include a gateway rule generator 222 for creating, editing, and/or sending gateway rules to the secure mobile gateway 128, as described below. These tools 220, 221 may be used, for example, by IT administrators to implement various security-related features and policies, as described below.

Mobile device management system 126 may include tunnel mediation module 224 for mediating an application tunnel between a software application running on mobile device 120 and another resource, such as enterprise resource 130, as described below. Tunnel broker module 224 may also be configured to allow or deny access requests based on access policy 218 and information 204 .

Mobile device management system 126 may also include remediation agent 226 for performing remedial actions provided by meta-applications 150 and/or 151, as described below. The remediation agent 226 may perform various types of remedial actions based on conditions, such as specified by rules, as generally described in Qureshi '526.

With further reference to FIG. 2 , the above-described functional components 202, 224, 220, 221 of the mobile device management system 126 can be implemented on suitable computer hardware, such as executable program code modules running on one or more physical servers or other computing devices. , 222, 226. These components may, for example, run on a single physical server or other machine, or may be distributed among multiple machines on a network. In some implementations, some or all of these components may optionally be implemented in firmware or in dedicated hardware (ASIC, FPGA, etc.). The various data or data storage of mobile device management system 126 may be implemented in any suitable type of computer storage (e.g., hard drive, solid state memory array, optical storage device, etc.) using databases, flat files, and/or other types of data storage arrangements. Parts 210, 212, 218, 228.

For example, an enterprise may wish to use multiple mobile device management systems 126 . Businesses with multiple offices may use separate systems 126 for separate offices. This may be useful if the business has offices located in different geographic regions. For example, a large enterprise with offices in the United Kingdom, Japan, and the United States may use three different mobile device management systems 126 located in or near those office locations. In such an embodiment, each mobile device management system 126 may be responsible for managing mobile devices 120 in different geographic regions, where such mobile device management may include sending rule packets to mobile devices 120 (described below) and and/or regulate access to enterprise resources 130 . In such embodiments, the secure mobile gateway 128 is preferably configured to communicate with each mobile device management system 126 for the purposes described herein. In some implementations, a console is provided that can be used to view the various systems 126 associated with a given enterprise.

Use of secure mobile gateways to regulate mobile device access to enterprise systems

Referring to FIG. 1A , an enterprise may wish to regulate how its mobile device users 115 access enterprise resources 130 via mobile devices 120 . Any given enterprise user 115 typically only requires access to a subset of enterprise resources 130, typically based on the user's role or role within the enterprise. Thus, doing so may expose the enterprise to unnecessary security risks because the user 115 need not be provided with mobile device access to many resources 130 . For example, an enterprise may wish to prevent many users 115 from using their mobile devices 120 to access highly sensitive, confidential information of the enterprise, especially if the users do not need access to such information to perform their duties related or related to the enterprise. This prevents, for example, disgruntled employees from harming the business by accessing and perhaps distributing sensitive business-related information. Additionally, applications and files installed on mobile device 120 may have malware or viruses that may be transferred to an enterprise's computer system 110 or that may upload or steal sensitive information. Restricting mobile device access to specific enterprise resources 130 may prevent malware and viruses from infecting other enterprise resources 130 . As discussed below, the mobile device management system 126 and the secure mobile gateway 128 preferably based on user characteristics, mobile device characteristics and/or enterprise resources 130 (mobile Device access to enterprise resources 130 is requested) to handle these issues in a customizable manner.

With the proliferation of mobile devices and the existing applications that expect to use them, there is a need to act at the network level to provide controlled access to enterprise resources. Furthermore, as enterprises implement BYOD (bring your own device) or BYOT (bring your own technology) strategies, there is a need for flexibility while dealing with the increasingly complex task of securing enterprise resources and sensitive enterprise data. Such flexibility may include allowing multiple different mobile devices and/or applications running on such mobile devices to access enterprise resources while providing a desired level of control over such access to enterprise resources. As an example, mobile devices 120 with various e-mail clients are allowed to access enterprise resources and enable the enterprise to implement certain protections such as denying some access requests under certain circumstances that are configurable by the enterprise and/or to provide It may be desirable to encrypt at least a portion of data to email clients of mobile devices while allowing the various email clients to access enterprise data. Allowing various existing mobile applications to access enterprise resources can eliminate the need to develop specialized applications and/or modify existing applications in order to access enterprise resources. At the same time, achieving a desired level of control over access to enterprise data may allow an enterprise to strike a balance between protecting enterprise data and enabling users to access enterprise data on mobile devices 120 .

The secure mobile gateway 128 can help flexibly protect sensitive enterprise data accessed by the mobile device 120 . Secure mobile gateway 128 may monitor and log traffic between one or more enterprise resources 130 and mobile devices 120 . The secure mobile gateway 128 can apply rules to implement enterprise policies applied to selected mobile devices 120 . Based on specific protocols, the secure mobile gateway 128 may take actions to implement enterprise policies as applied to selected mobile devices 120 requesting access to enterprise resources 130 . Thus, in the context of a mobile device 120 in communication with an enterprise computing system 110 , the secure mobile gateway 128 can take actions related to the protocol and certain conditions to provide access to the enterprise resource 130 . It will be appreciated that secure mobile gateway 128 may control traffic related to any suitable protocol, such as those described herein. Any combination of policies, rules, and remedial actions described herein may be implemented by the secure mobile gateway 128 . Moreover, secure mobile gateway 128 can implement various other policies, rules, remedial actions, or any combination thereof in accordance with the principles and advantages described herein.

The secure mobile gateway 128 may include a gateway filter that functions as a protocol analyzer and rule remediator. Gateway filters detect prescribed protocols relevant to enterprise business, such as ActiveSync or HTTP. Gateway filters implement gateway rules that take certain actions on specific protocols and one or more conditions. For example, when the request from mobile device 120 to access enterprise resource 130 is an ActiveSync request, the gateway filter may implement rules specific to the ActiveSync protocol. In this example, the condition may be that the mobile device 120 is associated with an executive branch of a business that may receive sensitive business information. The gateway filter can then take action to encrypt the attachment data before sending the data to the executive's mobile device. In another example, a gateway filter may deny mobile device 120's request to access enterprise resource 130 because mobile device 120 has a certain application installed thereon.

Figure 4 schematically illustrates the architecture and operation of an embodiment of the secure mobile gateway 128 of Figure 1A. The secure mobile gateway 128 may implement or control any juncture in the computing system at any juncture through which protocol traffic flows. For example, secure mobile gateway 128 may be implemented in a firewall, an enterprise server (eg, an application server), or between a firewall and an enterprise server. As another example, virtual secure mobile gateway 128 may communicate with an enterprise server (eg, via a PowerShell interface) to implement enterprise access policies on requests from mobile devices. Secure mobile gateway 128 may be implemented as a plug-in to firewall server 400 of an enterprise network, such as firewall 122 of FIG. 1A . For example, most firewall products sold by Microsoft Corporation ^(TM) run Internet Information Services (IIS), which is a service that handles web server requests. IIS has a plug-in architecture that allows implementations of gateway 128 to be plugged into firewall products. A specific API for IIS is the Internet Server Application Programming Interface (ISAPI). Implementations of the secure mobile gateway 128 may be compatible with various firewall technologies such as Microsoft Forefront Threat Management Gateway (TMG), Microsoft Forefront Unified Access Gateway (UAG), Microsoft Forefront Identity Manager 2010 (FIM 2010), Microsoft ISA 2006, Barracuda Firewall, Sonic firewall, Cisco firewall, etc. are integrated together. When the secure mobile gateway 128 is integrated with certain firewalls such as TMG, the secure mobile gateway 128 may be implemented by one or more enterprise resources 130 ( FIG. 1E ) or at least one device configured to control the one or more enterprise resources 130 . In some embodiments, such as for enterprises that do not utilize perimeter firewall 122 (FIG. 1A), secure mobile gateway 128 may be integrated with the enterprise's internal server, such as an ActiveSync-enabled client access server ("CAS server"). In some other implementations, the secure mobile gateway 128 may be implemented by at least one computing device configured to communicate with a firewall server. In this manner, secure mobile gateway 128 may control some or all traffic through the firewall without the firewall server being modified. This may enable enterprises to implement secure mobile gateway 128 in conjunction with unmodified third-party firewalls.

Although secure mobile gateway 128 of FIGS. 110 - System 110 - related requests including different companies or other businesses. When handling requests associated with multiple different enterprise computing systems 110 , secure mobile gateway 128 may implement different rules for each different enterprise computing system 110 . For example, one secure mobile gateway 128 may be implemented for several different corporate email systems, each with different email policies. In some of these implementations, the secure mobile gateway 128 may communicate with different mobile device management systems 126 of enterprise computing systems 110 of different companies.

The secure mobile gateway 128 shown in FIG. 4 includes a gateway filter 401 configurable to receive and process enterprise access requests 402 from the mobile device 120 , each request formatted according to a protocol supported by the secure mobile gateway 128 . Gateway filter 401 may be embedded within firewall server 400 . In some other implementations, gateway filter 401 may be implemented to control traffic through a separate firewall server. Gateway filter 401 may be configured to allow access request 402 to enterprise resource 130 or to deny request 402 . Gateway 128 may be configured to support one or more different request protocols, such as ActiveSync requests, SharePoint requests, EWS requests, SAP requests, and/or requests associated with various other web server applications. In one embodiment, blocks 401, 404, 406, 410, and 412 in FIG. 4 represent blocks that may be added (e.g., as part of a firewall plug-in) to a commercially available firewall or firewall server 400 to implement a secure mobile gateway 128 parts.

Take the case of the secure mobile gateway 128 configured to handle ActiveSync requests to synchronize enterprise system data with the mobile device 120 as an example. ActiveSync is a well-known mobile data synchronization technology and protocol developed by Microsoft ^™ . One implementation of ActiveSync, commonly referred to as Exchange ActiveSync (or EAS), provides push synchronization of contacts, calendars, tasks, and email between an ActiveSync-enabled server and a mobile device. Gateway filter 401 may be configured to intercept each incoming request 402, determine whether it is an ActiveSync request, and consult the database of gateway rules 401 to determine whether gateway filter 401 should allow or deny the request. The request may be, for example, an HTTP request. The database of gateway rules 401 may be a local database stored on the enterprise firewall server 400 . In the case of an allowed ActiveSync request 402, gateway filter 401 may send the request to enterprise resource 130, which may include a Microsoft Exchange server.

Gateway filter 401 may detect whether request 402 is an ActiveSync request by inspecting the headers and possibly the body of the request to detect flags of the ActiveSync protocol. Each ActiveSync command generally includes a Uniform Resource Locator (URL) issued by the mobile device 120 . After the URL, the request typically includes query parameters and ActiveSync commands. To illustrate, consider the following ActiveSync request:

http://myDomain.com/Microsoft-Server-ActiveSync? User=XXX&DeviceId=XXX&DeviceType=XXX&Cmd=Ping

The secure mobile gateway 128 can get the DeviceId and DeviceType from the URL, the UserAgent parameter from the HTTP header, the authenticated User parameter and the Cmd parameter from the HTTP session. Secure mobile gateway 128 may be configured to filter requests 402 based on one or more of these characteristics. Note that the ActiveSync protocol also allows URL parameters to be optionally encoded using a base64-encoded representation. In the above example, gateway 128 may determine from the string "Microsoft-Server-ActiveSync" that the request is an ActiveSync request.

Gateway rules 404 may include one or more values for characteristics of mobile device request 402 formatted according to a protocol supported by secure mobile gateway 128 . Such properties may include URL parameters, header values, commands, and the like. Gateway filter 401 may be configured to filter requests 402 based at least in part on these characteristics. In the case of ActiveSync, the request properties may include DeviceID and DeviceType (obtained from the request URL), User and UserAgent parameters (obtained from the HTTP header), and one or more ActiveSync command parameters (ActiveSync specifies many different commands, such as making a mailbox sync, send mail, get attachments, etc.). Gateway rules 404 may specify conditions under which requests are to be allowed or denied by gateway filter 401 . Such conditions may involve logical expressions and/or combinations of one or more values of request characteristics of the protocols supported by the secure mobile gateway 128 . For example, gateway rule 404 may cause gateway filter 401 to block all ActiveSync requests that have any of a particular set of values DeviceID and issue a get attachment command (for downloading email attachments). As this example illustrates, gateway rules 404 may identify one or more mobile devices 120 and/or users 115 . As this example also shows, gateway rules 404 may allow or deny access based on what mobile device 120 is attempting to do or achieve by issuing access request 402 to enterprise system 110 . Through the secure mobile gateway 128 , an operator of the secure mobile gateway 128 can customize the gateway rules 404 for a particular enterprise computing system 110 .

In some implementations, the secure mobile gateway 128 may be configured to inspect the body or "payload" of a request 402 to access an enterprise resource 130 in order to detect additional information that may be useful in evaluating whether to allow or deny the request. The payload can provide information about the specific data being requested, how the mobile device application will use the requested data, and the like. Access policies, such as policy 218 of device management system 126, may be created to regulate or limit access based on such information. For example, secure mobile gateway 128 may inspect the payload of a message formatted according to a selected protocol, such as ActiveSync, SharePoint, SAP, or those based on HTTP. The secure mobile gateway may also modify protocol metadata in these messages to implement various security-related features. For example, as described below under the heading "Protecting Attachment Data," the Secure Mobile Gateway can be configured to inspect the payload of ActiveSync or other requests 402 to determine whether they are relevant to messages that include attachments (e.g., email attachments); Secure Mobile Gateway 128 may also encrypt some or all of the identified attachments to prevent them from being stored on the associated mobile device 120 in an unencrypted format.

Gateway rules 404 may be based on data provided by mobile device management system 126 and/or data provided by an operator of secure mobile gateway 128 . The mobile device management system 126 can translate the high-level rules into relatively simple (lower-level) rules and provide the relatively simple rules to the secure mobile gateway 128 for application to monitored traffic. The secure mobile gateway may also implement rules provided by or based on input from an inference engine (eg, inference engine 824 of FIG. 8 ) of meta-application 150 and/or meta-application portion 151 in cloud 156 . In some embodiments, rules may be generated using the methods and components described in Qureshi '526, including symptom logic.

Gateway rules 404 can take many different forms and can be written in various programming languages such as SML. In one embodiment, gateway rules 404 include a list of "groups" plus an indication of a default "action" (eg, permission or denial of an access request or whether to encrypt attachment data). In this context, a group is a collection of "group members" plus corresponding actions for that group. A group member may be a collection of values for one, some, or all of the characteristics requested 402 by the mobile device. Each group member can match incoming mobile device access requests 402 by any value of the property of the request protocol supported by the secure mobile gateway 128 . Gateway filter 401 may match incoming request 402 with group members by matching all property values of group members with corresponding property values of request 402 . If the group membership does not include any values for one or more possible requested properties, gateway filter 401 may determine for those specific properties that it does not matter what the value of the request is. In other words, group membership may effectively specify "any" or "don't care" for one or more request characteristics. Accordingly, different group members may correspond to the same mobile device 120 or user 115 . For example, for a secure mobile gateway 128 that supports ActiveSync, group membership may match incoming HTTP requests 402 by any combination of DeviceID, User, UserAgent, and DeviceType and ActiveSync Cmd values.

Here is an example of a gateway rule 404:

This gateway rule specifies the default action as a denial of incoming access requests received by the secure mobile gateway 128 from the mobile device 120 . This gateway rule also specifies the "StaticAllow" group - whose action is "Allow", the "StaticDeny" group - whose action is "Deny", the "ZdmDeny" group - whose action is "Deny" and the "ZdmAllow" group - Its action is "Allow". Together, groups and actions can be subrules. The StaticAllow and StaticDeny groups and their associated actions are examples of subrules local to the secure mobile gateway 128 . Such sub-rules may be modified by the operator of the secure mobile gateway independently of the mobile device management system 126 . The ZdmDeny and ZdmAllow groups and their associated actions are examples of subrules received from the mobile device management system 126 . Rules may be prioritized in any suitable order. In the example above, the StaticAllow and StaticDeny groups and their associated actions take precedence over the ZdmDeny and ZdmAllow groups and their associated actions. In this manner, the operator of the secure mobile gateway 128 may overrule the sub-rules provided by the mobile device management system 126 .

A number of other sub-rules from various sources can be implemented using or in place of the above-described example sub-rules provided above. Gateway rules 404 may alternatively or additionally specify a number of other actions that secure mobile gateway 128 takes with respect to various groups, such as encrypting attachments for certain groups, modifying the body of messages (e.g., emails) for certain groups, blocking messages from Certain groups of mobile devices 120 receive messages at certain locations, and so on.

To enforce the example gateway rules 404 provided above, the secure mobile gateway 128 has access to all group members of these four groups. Here is an example of a "group list" that may be provided to secure mobile gateway 128 (e.g., by provider 408 as described below):

This group list specifies the location of a file containing a list of group members, each group member identifiable by one or more values of the property of the access request 402 for the protocol supported by the gateway 128 . For the ActiveSync protocol, each group member may include values for the DeviceID, User, UserAgent, DeviceType, and Cmd parameters.

When the secure mobile gateway 128 receives an incoming mobile device request 402, the gateway filter 401 may read the values of the properties of the request 402 and match them with the corresponding property values of the group members of the group list. If there is a match, gateway filter 401 may implement group-related actions. If there is no match, gateway 128 performs the same analysis on the next group listed in gateway rules 404 . If there is no match to any set of gateway rules 404, gateway 128 implements a default action. To the extent that conflicts may exist between groups of gateway rules 404, secure mobile gateway 128 may be configured to give priority to groups that appear earlier in the rules.

Still referring to the above example of gateway rule 404, after gateway filter 401 reads the values of the request properties, gateway filter 401 reads the property values of the group members of the StaticAllow group and determines whether any of them match any of the properties of request 402 value. For example, for an ActiveSync enabled gateway 128, the DeviceID of request 402 may match the DeviceID of one of the group members. If there is such a match, the gateway filter 401 implements the action associated with the StaticAllow group, which is to allow the request 402 through the firewall. If there is no match for any property values of any group members of the StaticAllow group, gateway filter 401 reads the property values of group members of the StaticDeny group and determines whether any of them match any of the request 402 property values. If there is such a match, the gateway filter 401 implements the action associated with the StaticDeny group, which is to deny the request 402 . If there is no match for any property value of any group member of the StaticDeny group, the gateway filter 401 reads the property values of the group members of the ZdmDeny group and determines whether any of them match any of the request 402 property values. If there is a match, the gateway filter 401 implements the action associated with the ZdmDeny group, which is to deny the request 402 . If there is no match for any property value of any group member of the ZdmDeny group, gateway filter 401 reads the property values of group members of the ZdmAllow group and determines whether any of them match any property value of the request 402 . If there is a match, Gateway Filter 401 implements the action associated with the ZdmAllow group, which is Allow Request 402 . If there is no match for any property value of any group member of the ZdmAllow group, the gateway filter 401 implements a default action which is to deny the request 402 .

The secure mobile gateway 128 may include a gateway configuration service 406 that allows users (eg, administrators, IT staff, etc.) to view, edit and/or create gateway rules 404 and then save them in a local database. Configuration service 406 may be configured to allow an administrator to set “static” gateway rules 404 . Static gateway rules may identify mobile devices 120 or groups of devices 120 that are always allowed or denied access. For example, an administrator may enter a rule 404 specifying a mobile device 120 (identified, for example, by ActiveSync DeviceId) used by the CEO of the enterprise that is always allowed to access the enterprise network 110. As another example, an administrator may enter a gateway rule 404 that denies access to devices 120 that are known to have malware or are incompatible with the enterprise network 110 . Configuration service 406 may also be configured to allow a user to adjust various other settings and features of gateway 128 , including any of those described herein.

Gateway configuration service 406 may allow gateway rules 404 to be statically specified. Additionally, secure mobile gateway 128 may be configured to receive gateway rules 404 from one or more external “providers” 408 . Provider 408 may be any entity authorized by gateway 128 to provide gateway rules 404 for regulating access to enterprise network 110 . Gateway 128 may have an open architecture that allows an enterprise's IT staff to add, remove, and configure providers 408 . Preferably, gateway 128 supports any number of providers 408 . Mobile device management system 126 may be one of providers 408 . Another provider 408 may be a meta-application 150 that manages some or all of the enterprise network 110, such as a "backend" subnetwork behind firewall 124 (FIG. 1A). An exemplary meta-application implementation is described in Qureshi '536, and an at least partially cloud-based meta-application (which may be a provider 408) is described below with reference to FIG. 8 .

Each provider 408 may be configured to create and send one or more gateway rules 404 to gateway 128 . Provider 408 may be configured to query its own database of information to create rules 404 . Provider 408 may have significantly more data about allowing or denying mobile device access request 402 than gateway 128 , such as information about user 115 and/or mobile device 120 . For example, the illustrated mobile device management system 126 (FIG. 2) may include a gateway rule generator 222 configured to 206) to create and edit gateway rules 404, and then send the rules 404 to the gateway configuration service 406 of the gateway 128. Access policies 218 may include high-level rules specifying whether mobile devices 120 may access the enterprise network or specific resources 130 thereof. Gateway rule generator 222 may be configured to read access policy 218 and then query mobile device information 204 to find a particular device 120 or user 115 that matches the criteria of access policy 218 . From the detected devices and users, gateway rule generator 222 may generate device or user-specific gateway rules 404 that implement policy 218 . Mobile device management system 126 may be configured to send a list of users 115 or devices 120 (e.g., in the form of "group members" as discussed above) whose access to the enterprise is allowed or denied, and send those lists to gateway 128 . Gateway 128 may be configured to implement gateway rules 404 using lists.

For example, if access policy 218 requires that all Android ^™ mobile devices 120 with the Facebook ^™ application installed be denied access to corporate network 110, gateway rule generator 222 may query mobile device information 204 for a list of such devices 120. Gateway rule generator 222 may create one or more gateway rules 404 that instruct gateway filter 401 to deny access to listed devices 120 and send the created rules to gateway configuration service 406 . In the case of a gateway 128 supporting the ActiveSync protocol, the gateway rule generator 222 may, for example, generate a list of ActiveSync DeviceIDs of Android ^™ mobile devices 120 that have the Facebook ^™ application installed, and then create a list indicating the denial of access to such devices. or multiple gateway rules 404.

As the examples above illustrate, access policies 218 may include any logical combination that may be translated into gateway rules 404 . Policy 218 in the above example represents the union (AND operator) of two conditions: (1) the mobile device is an Android ^™ device, and (2) the device has the Facebook ^™ application installed on it. It will be understood that logical combinations of conditions may include OR operators, XOR operators, NOR operators, NAND operators, THEN operators, mathematical operators (including "less than" and "greater than"), and any other suitable operator.

In addition to generating gateway rules 404 based at least in part on mobile device information 204, gateway rule generator 222 may also be configured to base at least in part on information received from meta-application 150, such as models of enterprise network 110 and mobile device 120 or detected A locally stored database of "Signatures,""Problems," and "Root Causes" (see discussion below of the meta-application) to generate rules. In embodiments where the meta-application 150 manages Microsoft Exchange ^™ , the information received from the meta-application 150 may include ActiveSync partnership data.

As mentioned above, the meta-application 150 ( FIGS. 1A-C ) can be the direct provider 408 of the gateway rules 404 of the secure mobile gateway 128 . Meta-application 150 can generate gateway rules 404 based on various data related to enterprise network 110, users 115, mobile devices 120, or any combination thereof. Meta-application 150 can access various information on which gateway rules 404 can be based. For example, in support of its administrative tasks, meta-application 150 may be configured to conduct "discovery" of enterprise network 110 and mobile devices 120 to create and maintain a queryable model thereof. Additionally, the meta-application 150 may be configured to predict or detect "signatures," "problems," and/or "root causes," as these terms are used in Qureshi '536. New gateway rules 404 may be created based on the model, detected characteristics, problems and root causes, and other information detected or calculated by the meta-application 150 . The management and gateway control capabilities of embodiments of meta-application 150 are described more fully below.

The illustrated gateway configuration service 406 is configured to receive gateway rules 404 from a provider 408 and save them in a local storage of the rules 404 . Gateway configuration service 406 may be implemented as a web service and may have a list of all providers 408 associated with gateway 128 . The gateway configuration service 406 may be configured to periodically (eg, every 24 hours, an hour, or a few minutes, etc.) query the provider 408 for any new gateway rules 404 that are available. In this sense, configuration service 406 acts as a collector of gateway rules 404 for gateway 128 .

Protect attachment data

Mobile devices are commonly used to check email, including email associated with business email accounts. Some emails include attachments containing sensitive data. These attachments are often stored on the mobile device when the user checks email on the mobile device. Attachment data stored on a mobile device can be compromised in a number of ways. When attached data is compromised, sensitive data related to the enterprise can be exposed. Accordingly, there is a need to protect enterprise-related attachment data stored on mobile devices. This need may vary depending on the individual's status or role in the relevant organization; for example, the need to protect attachments to messages received by executives at a company may be greater than the need to protect attachments received by IT staff at the company. Furthermore, if a company's enterprise supports the use of other messaging protocols (SMS, MMS, Instant Messaging, AS, EWS, OWA, proprietary messaging protocols, etc.) to send documents, then this need can be extended to such protocols.

Aspects of certain embodiments relate to protecting corporate attachments stored on mobile devices, such as corporate email attachments, from compromise. Attachments may include, for example, Word documents, Excel documents, PowerPoint presentations, text files, and documents and files created using other applications. According to the principles and advantages described herein, attachment data can be protected on mobile devices with non-dedicated email applications, such as email applications that appear as pre-installed or later installed on iPhone or Android devices. Accordingly, any suitable email client may be used to implement features related to securing attachment data. Enterprise attachments can be protected prior to storage on the mobile device so that the protected attachment data remains safe even if the data stored on the mobile device is compromised. Attachment data is securely stored on the mobile device's common file system. Attachment data can be identified and stripped from email messages. Attachment data may be encrypted and then sent to the mobile device as encrypted attachment data. The secure mobile gateway can be configured to encrypt the attachment data and provide the encrypted attachment data to the mobile device. According to some implementations, an encrypted attachment key may also be sent along with the encrypted attachment data. Provides secure policy-based access to protected attachment data. Enterprise agents can decrypt encrypted attachment data. For example, the enterprise agent may decrypt the encrypted attachment key and then use the attachment key to decrypt the encoded attachment data. When the mobile device is compromised, the enterprise agent can be configured such that encrypted attachment data remains encrypted. For example, an enterprise agent may corrupt and/or invalidate the attachment key. In the absence of the device key to decrypt the encrypted attachment key, the encrypted attachment data may remain encrypted. When encrypted attachment data is stored on removable memory, such as a Secure Digital (SD) card, the attachment data can remain secure when the removable memory is removed from the mobile device because the attachment data is encrypted.

In one embodiment, business users access their business email accounts from their mobile devices using a business agent installed on their mobile devices. The corporate proxy can operate transparently to email clients and corporate email servers. A corporate proxy may require an end user to log in before accessing the user's email and/or before opening an encrypted attachment. An enterprise agent may register with the mobile device's platform. An enterprise agent may be invoked when a user opens an encrypted attachment. Encrypted attachments are identified by specific file extensions. After being invoked, the enterprise agent can decrypt the attachment transparently to the user.

Although the system is described herein primarily in the context of email attachments for illustrative purposes, it will be understood that the principles and advantages described herein are applicable to any other suitable communication protocol available for sending attachments from an enterprise resource to a mobile device. For example, any combination of features for protecting email attachments can be applied to protect attachments for instant messages, text messages (eg, SMS), and the like. It will be appreciated that, in certain implementations, the policy-based encryption of attachment data described herein may be implemented in conjunction with other encryption applied to attachment data. Also, while attachment data is described herein as being encrypted for illustrative purposes, it will be understood that the principles and advantages described herein may be applied to any other suitable means of securing attachment data on a mobile device, such as scrambling or the like. Furthermore, the principles and advantages described herein with reference to attachment data can be applied to securing some or all messages, such as email messages.

Referring to Figures 1A-1C, attachment data can be secured in any of the enterprise computing systems and mobile devices described herein. Attachment data can be secured in any system that has a mobile device 120 in communication with a secure mobile gateway 128 that communicates with an enterprise resource 130, such as an enterprise email server. Generally, mobile device 120 communicates with secure mobile gateway 128 via external firewall 122 (FIGS. 1A-C). In some implementations, the secure mobile gateway 128 may be implemented by an enterprise resource 130 . In one embodiment, secure mobile gateway 128 may be deployed between external firewall 122 and internal firewall 124 of enterprise system 110, as discussed above. Mobile device 120 and/or secure mobile gateway 128 may communicate with mobile device management system 126 . Mobile device management system 126 may be configured to implement functionality related to encryption keys used, for example, to encrypt attachment data, as described in more detail below. According to some implementations, the secure mobile gateway 128 and/or the agent of the mobile device 120 may be configured to decrypt the attachment.

The secure mobile gateway 128 may be configured to detect attachments in incoming and/or outgoing email messages. In some implementations, the secure mobile gateway 128 may inspect and/or modify data payloads transmitted to and/or from the mobile device 120 , such as ActiveSync data payloads. Incoming and/or outgoing data payloads can be in WBXML - a binary version of XML optimized for low bandwidth environments. Secure mobile gateway 128 may include parsers and generators that operate on data payloads. For example, parsers and generators can handle WBXML. In this example, parsers and generators can process data according to the ActiveSync WBXML schema. The secure mobile gateway 128 can programmatically identify which character encoding schemes are used. WBXML messages may include MIME payloads. Secure mobile gateway 128 may include a MIME parser and generator configured to construct and deconstruct this data. Using the parser and generator, the secure mobile gateway 128 can identify the attachment so that the attachment can be separated from the email and protected.

According to one embodiment, the secure mobile gateway 128 may register with an Internet Server Application Programming Interface (ISAPI) or other server to receive notifications in order to intercept and/or modify incoming and/or outgoing data payloads. The notifications received may correspond to various processing stages. The secure mobile gateway 128 may maintain context state to track the various processing stages of the request. Secure mobile gateway 128 may chunk and dechunk request and response data.

Secure mobile gateway 128 may modify or otherwise flag the attachment and/or references to the attachment. For example, the secure mobile gateway 128 may append a specific suffix, such as “.zendata,” to the names of encrypted attachments to indicate that they should be pre-processed by the enterprise agent 320 . As another example, the secure mobile gateway 128 may append a specific suffix, such as “.zendata,” to the name of the reference to the attachment to indicate that the attachment should be encrypted later before being distributed to the mobile device 120 . Alternatively or in addition to appending a suffix to the file or link, the secure mobile gateway 128 may also adjust header attributes (eg, in the MIME data) to recognize that the attachment data is also encrypted. Secure mobile gateway 128 may encrypt and/or decrypt attachment data and/or attachment keys. Secure mobile gateway 128 may be configured to initiate communications with mobile device management system 126 to obtain device characteristics, device policies, public device keys, etc., or any combination thereof.

A device agent for mobile device 120, such as an operating system and/or enterprise agent 320 (FIG. 3), may be configured to register mobile device 120 with enterprise system 110 and manipulate encrypted data file types (e.g., ". Appropriate rendering and/or processing is invoked on the attachment data of the mobile device 120. The device agent of the mobile device 120 may be configured to obtain and/or manage a private device key.

The mobile device management system 126 can generate a device key. Mobile device management system 126 may distribute device keys, or portions thereof, to mobile devices 120 and/or secure mobile gateway 128 . A suitable key can be used by the secure mobile gateway 128 to encrypt the attachment data, and another suitable key can be used by the mobile device 120 to decrypt the encrypted attachment data. For example, mobile device 120 may receive a private device key from mobile device management system 126 and secure mobile gateway 128 may receive a public device key from mobile device management system 126 . According to some implementations, the secure mobile gateway 128 need not include special key management and/or key archiving. Encrypted attachments may be unrecoverable when the attachment is encrypted and the corresponding device key is subsequently destroyed, invalidated, and/or replaced.

A number of different rules and/or policies related to securing attachments may be implemented by enterprise system 110 . For example, features related to securing accessories may be implemented based on one or more characteristics of the particular mobile device 120 receiving the accessory data. In this example, certain mobile devices 120 that have certain software applications installed may have accessory protection enabled by default. As another example, protecting the accessory can be enabled and/or disabled based on one or more characteristics of the user of the mobile device 120 receiving the accessory data. For example, employees of a business, such as executives and/or members of the legal team, who may receive attachments with sensitive and/or confidential information may have the attachments encrypted by default. Conversely, employees who are unlikely to receive attachments with sensitive and/or confidential data may have attachment protection disabled by default. As yet another example, an attachment may be protected based on one or more characteristics of the attachment itself, such as a filename, file type, data included in the attachment, or any combination thereof. For example, attachments may be searched for one or more keywords and phrases such as "confidential," "proprietary," "attorney-client privileged," etc., and if such keywords or phrases are found, the attachment may be is encrypted. It will be appreciated that rules and/or policies may allow an enterprise to configure features related to securing accessories in a flexible manner based on mobile device characteristics, user characteristics, accessory characteristics, the like, or any combination thereof. Any rules and/or policies related to securing attachments may be implemented in conjunction with any other rules described herein, rule packages described herein, policies described herein, similar rules, or any combination thereof.

Moreover, any of these rules and/or policies related to securing attachments may be implemented by any suitable computer hardware described herein. For example, secure mobile gateway 128 may be configured to globally enable and/or disable features related to securing attachments, such as encrypted attachments. Secure mobile gateway 128 may obtain policies related to securing accessories from mobile device management system 126 . Mobile device management system 126 may be configured to manage any selection policies related to securing attachments, such as which mobile devices 120 receive encrypted attachments and/or what types of attachments are encrypted.

In a typical use case scenario, mobile device 120 may receive email with attachments from a corporate email server, such as an Exchange server, according to the ActiveSync protocol. The mobile device 120 can retrieve encrypted email attachments such that the attachment data stored on the mobile device 120 is protected using a device-specific key. According to some implementations, only the enterprise agent 320 running on the mobile device 120 may be used to decrypt the saved attachment data. For example, enterprise agent 320 may control and manage device-specific keys used to decrypt attachment data. The mobile device management system 126 can select and designate the mobile devices 120 and/or users for which attachments are to be encrypted. For example, selected mobile devices 120 may be excluded from receiving encrypted attachments based on one or more mobile device management system 126 policies and/or one or more secure mobile gateway 128 policies.

Encrypted attachments forwarded and/or sent from mobile device 120 may be decrypted by secure mobile gateway 128 before being distributed to a new recipient. As a result, new recipients within the enterprise can receive attachments based on its policies. When the new recipient is a mobile device 120 with an enterprise proxy 320, the attachment data may be re-encrypted for that particular recipient mobile device 120. When the new recipient is an unmanaged mail client, the attachment data can be distributed unencrypted.

Example communications and events involved in distributing email with attachments from enterprise resource 130 to mobile device 120 via secure mobile gateway 128 will be described with reference to FIG. 31 . Example communications and events related to forwarding and/or sending email from mobile device 120 through secure mobile gateway 128 or enterprise resource 130 will then be described with reference to FIGS. 32 or 33 .

FIG. 31 shows an example of a process by which emails with encrypted attachments may be distributed to mobile devices 120. During this process, the secure mobile gateway 128 identifies attachments to emails that are distributed to the mobile device 120 . Secure mobile gateway 128 may encrypt the attachment data prior to transmitting the attachment to mobile device 120 . Attachment data may be encrypted and sent to mobile device 120 before the email message is sent to mobile device 120 or in response to a user of mobile device 120 attempting to open the attachment. The secure mobile gateway 128 may also encrypt the attachment key associated with the encrypted attachment data. In event A of FIG. 31 , the mobile device 120 transmits a synchronization request to the secure mobile gateway 128, eg, via the ActiveSync protocol. Secure mobile gateway 128 then transmits a synchronization request to enterprise resource 130 in event B. Enterprise resource 130 may be, for example, an enterprise email server, such as a Microsoft Exchange server. In event C, enterprise resource 130 sends a synchronization response to secure mobile gateway 128 . The synchronization response may include an email message to be distributed to the mobile device 120 .

In event D of FIG. 31 , secure mobile gateway 128 processes an email message sent to mobile device 120 . Such processing may include determining whether the email message includes an attachment. For example, when an enterprise email server sends a response including an email message in event C, secure mobile gateway 128 may parse the response and programmatically identify attachments. For example, attachments can be identified from the name and server reference in the WBXML message. As another example, attachments can be identified by being inline in the MIME message. Secure mobile gateway 128 may mark and/or modify attachments in a detectable manner. For example, secure mobile gateway 128 may rename the attachment. In one embodiment, a suffix can be appended to the name of the attachment file. For example, an original name with "Foo.xyz" could be renamed to "Foo.xyz.zendata".

Attachments may also be encrypted in event D of FIG. 31 when the attachment is included inline or otherwise included with the email in substantially complete form, such as in a MIME message. Any suitable attachments such as documents (eg Word documents, PDF documents, etc.) may be encrypted. The secure mobile gateway 128 may also encrypt the accessory key associated with the accessory. The accessory key may be generated by the secure mobile gateway 128 and/or received by the secure mobile gateway 128, eg, from the mobile device management system 126, as discussed in more detail with reference to FIG. 34 . An encrypted attachment key can be included in a new attachment file along with the encrypted attachment file.

The synchronization response from the enterprise email server and/or another enterprise response 130 as modified by the secure mobile gateway 128 is distributed to the mobile device 120 in event E of FIG. 31 . In some cases, this may provide mobile device 120 with encrypted attachment data. For example, a MIME message with an embedded encrypted attachment can be provided to mobile device 120 . For some other types of messages, the mobile device 120 may be provided an email with a renamed attachment reference that may be used with a subsequent request to retrieve the attachment.

For emails with attachment references, such as WBXML emails, a request to retrieve the attachment may be sent from the mobile device 120 in event F of FIG. 31 . Then in event G, the secure mobile gateway 128 can detect that the attachment reference has been flagged and/or modified. For example, secure mobile gateway 128 may programmatically recognize that the attachment reference includes a particular suffix previously added by secure mobile gateway 128, such as "zendata" in the example provided above. The secure mobile gateway 128 can then unmap the attachment reference so that the enterprise email server and/or another enterprise resource 130 can process the request to provide the attachment. In some implementations, this may involve URL rewriting. In event H, the secure mobile gateway 128 requests the attachment from the enterprise email server and/or another enterprise resource 130 . The corporate email server then distributes the attachment to the secure mobile gateway 128 in event 1. The secure mobile gateway encrypts the attachment in event J. The secure mobile gateway 128 may also encrypt the attachment key associated with the attachment. The encrypted attachment key can be included in the file with the encrypted attachment data and/or provided separately to the mobile device 120 . Then in event K, the secure mobile gateway 128 distributes the encrypted attachment data to the mobile device 128 .

Email messages and associated attachments stored on mobile device 120 can be forwarded from mobile device 120 to new recipients. 32 and 33 illustrate an example of a process for forwarding an email message from a mobile device 120 . In the example shown in FIG. 32 , secure mobile gateway 128 may act as a conduit in transmitting a request to forward an email message with an attachment from mobile device 120 to enterprise resource 130 . The process shown in Figure 32 can be implemented in situations where the email with the attachment is stored on the corporate email server or the corporate email server is otherwise able to access the attachment data. For example, mobile device 120 may send information identifying the attachment, such as a reference, via secure mobile gateway 128 to an enterprise email server. In some implementations, the process of FIG. 32 can be implemented with a smart forwarding feature in which a tag is inserted into forwarded email messages with attachments. Enterprise resource 130, such as an Exchange server or other enterprise email server, may insert attachments into forwarded email messages sent to recipients by the smart forwarding feature. In this manner, the mobile device 120 can forward the email without downloading the entire email message and attachments to the mobile device 120 .

In event A of FIG. 32, mobile device 120 sends secure mobile gateway 128 a request to forward the email message including the reference to the attachment. Secure mobile gateway 128 then simply passes the email message to enterprise resource 130 in event B. The corporate email server can then use the reference to identify the attachment stored on the corporate email server. When the recipient is a mobile device 120 associated with an enterprise, the email and attachment may then be sent to the recipient via the process shown in FIG. 31 . In event C, enterprise resource 130 responds to secure mobile gateway 128 to confirm that the message was sent. Secure mobile gateway 128 passes the response to mobile device 120 in event D.

In the example shown in FIG. 33 , when a request to forward an email message with an attachment is sent from mobile device 120 to enterprise resource 130, such as an enterprise email server, secure mobile gateway 128 decrypts the encrypted attachment data from mobile device 120 . The process shown in FIG. 33 may be implemented when an email message with an attachment is transmitted from the mobile device 120 . Such a process may be implemented, for example, on a mobile device 120 where the process shown in FIG. 32 is not supported (eg, a mobile device 120 that does not support smart forwarding) and/or disabled.

In event A of FIG. 33 , mobile device 120 sends a request to secure mobile gateway 128 to forward the email message with an attachment. Requests can include encrypted attachment data. Secure mobile gateway 128 in event B detects a previously encrypted attachment and decrypts the encrypted attachment data. For example, the secure mobile gateway 128 may programmatically identify attachments that are marked and/or modified to indicate that they are encrypted, such as with the suffix ".zendata" in the example provided above. More details on some example decryption methods that may be performed in Event B will be described with reference to FIG. 35 . In event C, a request to forward the email message including the decrypted attachment data is transmitted to enterprise resource 130 . Enterprise resource 130 responds to secure mobile gateway 128 in event D to confirm that the message was sent. The secure mobile gateway 128 passes the response to the mobile device 120 in event E.

To encrypt email messages, various keys may be generated, distributed to other devices, encrypted, used to decrypt encrypted attachment data, the like, or any combination thereof. While encryption of email attachments may be described herein with respect to certain computing devices performing specific functions for illustrative purposes, it will be understood that any features related to encrypting and/or decrypting attachments described herein may be performed by any suitable computing device . For example, some of the functions described as related to encryption/decryption performed by the secure mobile gateway 128 and/or the mobile device management system 126 , or a subcombination thereof, may be performed by the mobile device 120 . As another example, some of the functions described as being performed by the secure mobile gateway 128 and/or the mobile device management system 126 related to encryption/decryption, or a subcombination thereof, may alternatively or additionally be performed by the other of the two computing systems. one executes.

In certain implementations, the secure mobile gateway 128 can generate keys associated with the attachment, and the mobile device management system 126 can generate keys for selected mobile devices 120 . For example, secure mobile gateway 128 may generate a symmetric secure mobile gateway key Smgkey and store this key in an appropriate data store. A symmetric secure mobile gateway key Smgkey may be generated, for example, when the secure mobile gateway 128 is installed and/or when software is installed thereon. According to some implementations, the mobile device management system 126 may generate an asymmetric key DeviceKey associated with the selected mobile device 120 . Alternatively or in addition, mobile device management system 126 may generate an asymmetric key associated with a group of mobile devices 120, users of an enterprise, or the like, or any combination thereof. Such an asymmetric key may be used instead of or in combination with the asymmetric key DeviceKey. The mobile device management system 126 may distribute the private key DeviceKeyPr of the asymmetric key DeviceKey to the selected mobile device 120 . The mobile device management system 126 may distribute the public key DeviceKeyPb of the asymmetric key DeviceKey to the secure mobile gateway 128 .

Figure 34 is a flowchart illustrating an embodiment of a method of encrypting an attachment. Some or all of the methods shown in FIG. 34 may be performed, for example, in event D and/or event J of FIG. 31 . At block 3410, an attachment key AttachmentKey is generated. The attachment key AttachmentKey may be a symmetric key. The attachment key AttachmentKey may be generated by the secure mobile gateway 128 .

The attachment key AttachmentKey is encrypted at block 3420 . For example, the secure mobile gateway 128 may encrypt the attachment key AttachmentKey using the secure mobile gateway key Smgkey. This produces an encrypted secure mobile gateway attachment key EncyptedSmgAttachmentKey for the secure mobile gateway 128, which may be used, for example, by the secure mobile gateway 128 to decrypt the encrypted attachment data, as described with respect to FIG. 35 . Additionally, the secure mobile gateway 128 may encrypt the attachment key AttachmentKey using the public key DeviceKeyPb. This results in an encrypted device attachment key, EncryptedDeviceAttachmentKey, for mobile device 120, which may be used, for example, by mobile device 120 to decrypt encrypted attachment data, as described with respect to FIG. 35 .

At block 3430, the attachment data is encrypted using the attachment key AttachmentKey to generate encrypted attachment data. The secure mobile gateway 128 replaces the previous attachment data with the encrypted attachment data at block 3440. The encrypted attachment keys EncyptedSmgAttachmentKey and EncryptedDeviceAttachmentKey may also be included with the encrypted attachment data. For example, the secure mobile gateway 128 may replace the attachment data with encrypted attachment data, an encrypted secure mobile gateway attachment key EncyptedSmgAttachmentKey, and an encrypted device attachment key EncryptedDeviceAttachmentKey.

Encrypted attachment data can be decrypted in order to access the attachment data. In some implementations, when accessing encrypted attachment data on the mobile device 120, the user may be prompted to log in or otherwise provide access credentials. To maintain protection of encrypted attachment data, an encrypted key associated with the attachment data may be provided to a particular computing device. For example, as discussed with respect to block 3420 of FIG. 34 , the secure mobile gateway 128 may encrypt an attachment key, AttachmentKey, specifically for use with the selected mobile device 120 and/or the secure mobile gateway 128 . Figure 35 is a flowchart illustrating an embodiment of a method of decrypting an attachment. When encrypted attachment data stored on the mobile device is accessed by an application on the mobile device 120 and/or in event B of FIG. 33, some or all of the method steps shown in FIG. The mobile gateway 128 performs.

At block 3510, the computing device receives the encrypted attachment. In some implementations, the computing device may also receive an encrypted attachment key along with the encrypted attachment data. According to some of these implementations, both the encrypted attachment data and the encrypted attachment key may be included in the same file. The encrypted attachment key is decrypted at block 3520. Then at block 3530, the attachment data is decrypted using the attachment key.

The method shown in FIG. 35 may be performed by an enterprise agent 320 on a mobile device 120, for example. According to the process shown in FIG. 31, this may include mobile device 120 receiving, for example, an encrypted attachment and an encrypted attachment key. The enterprise agent 320 of the mobile device 120 can decrypt the encrypted device attachment key EncryptedDeviceAttachmentKey using the private device key DeviceKeyPr. The decrypted device attachment key may be the attachment key AttachmentKey. Using the attachment key AttachmentKey, the enterprise agent 320 of the mobile device 120 can decrypt the encrypted attachment data. This may provide mobile device 120 with raw attachment data sent by enterprise resource 130 to mobile device 120, such as an enterprise email server. Such data may eg be plaintext data.

The method shown in FIG. 35 may be performed on the secure mobile gateway 128, for example. This may include, for example, secure mobile gateway 128 receiving an encrypted attachment when mobile device 120 forwards an email message with an encrypted attachment. The secure mobile gateway 128 may decrypt the encrypted secure mobile gateway attachment key EncryptedSmgAttachmentKey using the secure mobile gateway key Smgkey. The decrypted device attachment key may be the attachment key AttachmentKey. Using the attachment key AttachmentKey, the secure mobile gateway 128 can decrypt the encrypted attachment data. This may provide secure mobile gateway 128 with raw attachment data previously sent to mobile device 120 by enterprise resource 130, such as an enterprise email server. Secure mobile gateway 128 may then forward the attachment data to enterprise resource 130 .

To support distribution and/or updating of public device keys, such as public device key DeviceKeyPb, a web service interface or other suitable interface may be provided. The interface may enable a user to specify device/key pairs and/or user/key pairs. The interface may enable a user, such as a member of the IT staff or an enterprise network administrator, to update a key pair by, for example, adding a new pair, replacing an existing pair, removing a pair, the like, or any combination thereof. The interface may enable a user to map mobile device 120 to a set of properties (eg, name/value pairs). Such properties may include attachment public key, block attachments, block selected attachment types, block contacts sync, block calendar sync, client certificate ID, any other properties described herein, similar properties, or any combination thereof.

application tunnel

Referring to FIGS. 1A-3 , a tunnel intermediary, such as tunnel intermediary 224 of mobile device management system 126, may be configured to receive requests for access to enterprise resources 130 (in particular, including software applications) generated by software applications 318 installed on mobile devices 120. 130) and create an application tunnel between the device application 318 and the enterprise resource 130. Application tunneling is a technique in which one network protocol (such as a distribution protocol) encapsulates a different network protocol. By using tunnels it is possible, for example, to provide a secure path through an untrusted network.

One benefit of using an application tunnel for communication between a mobile device application 318 and an enterprise resource 130 is that it may limit the mobile device's access to those enterprise resources 130 that the user 115 of the mobile device 120 needs to use to fulfill his or her corporate role 206. Another potential advantage of using application tunneling is that access control can be provided at the application level for pre-existing applications. In a preferred embodiment, application tunneling is specified at the application layer in the OSI model. This is in contrast to virtual private networks (VPNs), a method widely used to provide remote offices or individual users with secure access to their organization's network. VPNs operate at the network layer (or lower) of the Open Systems Interconnection (OSI) model and typically provide users with full access to all resources within an enterprise's computer network. The obvious problem with using a VPN connection is that there is no adequate mechanism for restricting access to the VPN connection via mobile apps (and mobile apps that may contain malware). Instead, each application tunnel may be exclusive to (only available for use by) a single corresponding mobile application, as described below. The use of application tunneling can promote enterprise network security by restricting access to only those enterprise resources 130 required by specific users 115 .

As explained in more detail below, an additional benefit of using an application tunnel for communications between the mobile device 120 and the enterprise system 110 is that it allows the enterprise to improve the user's connection experience (e.g., by caching data in the event of a network connection loss). ), record data flow, and implement other features.

To implement application tunneling, a tunnel intermediary may be provided through which tunneled communications may flow. A tunnel intermediary is a component that receives mobile device application communications formatted according to an encapsulation protocol, "fetches" or extracts data from the communications using the protocol, and sends the fetched or extracted data to network resources requested or specified by the mobile device application. The tunnel intermediary is also substantially the same for communications sent by the network resource to the mobile device application via the tunnel intermediary. A tunnel intermediary may include a software application installed on a server. The tunnel intermediary may reside within enterprise system 110 (eg, tunnel intermediary 224 of mobile device management system 126 ), or alternatively external to enterprise system 110 (eg, in cloud computing environment 156 as in FIG. 1B ).

Tunnel broker or enterprise proxy 320 may use the tunnel definition to construct an application tunnel according to the methods described below. The mobile device management system 126 shown in FIG. 2 includes a repository 228 of tunnel definitions. A tunnel definition may include information to implement an application tunnel between mobile device application 318 and a remote resource (eg, enterprise resource 130). Tunnel definitions may be specific to a particular application 318 or type thereof. Similarly, tunnel definitions can be specific to a particular remote resource or type. A tunnel definition may identify a specific port of the mobile device 120 or/or a URL or a specific port of a computer server where the remote resource is installed. Thus, a tunnel definition may include application or server ports and information that maps such ports to client ports to specify the endpoints of the application tunnel. The tunnel definition may also include the URL of the tunnel broker, which may be useful, especially in implementations involving multiple tunnel brokers. Multiple application tunnels can be mapped to a specific port of the mobile device 120 and/or a URL or a specific port of a computer server where the remote resource is installed, and multiple application tunnels can be multiplexed such that a single port of the mobile device 120 and/or a specific port The URL or specific port of the computer server where the remote resource is installed is used to implement multiple application tunnels. Mobile device management system 126 may be configured to send (eg, push) at least a portion of tunnel definition 228 to mobile device 120 . For example, a tunnel definition may be sent with a "rules packet" described below. Enterprise agent 320 may be configured to store tunnel definitions locally on mobile device 120 and use the tunnel definitions to generate application tunnel information requests, as described below.

A tunnel broker or related system may include an interface, such as a web console, for viewing, creating and editing tunnel definitions. The interface may also allow an administrator or others to view data related to mobile devices 120 suitable for connection via the application tunnel. At least some of the data may be obtained from a repository of mobile device information 204 (FIG. 2).

Many mobile device software applications 318 are capable of issuing network communications (also referred to as “application-generated communications”), including requests to access and communicate with enterprise resources 130 . Enterprise proxy 320 may be configured to intercept and/or receive these communications and redirect at least some of them to a URL associated with one or more tunneling intermediaries, such as intermediary 224 . The tunnel intermediary can redirect application-generated communications to the requested enterprise resource 130 , receive reply communications from the enterprise resource 130 , and forward the reply communications back to the mobile device 120 . Advantageously, the tunnel intermediary can add a layer of enterprise security by applying access policies 218 to allow or deny access and restrict access to only requested enterprise resources 130 .

In one embodiment, when intercepting and/or receiving an application-generated communication for accessing enterprise resource 130 (or another resource), enterprise agent 320 searches the application tunnel definition stored in local memory to retrieve and generate application A tunnel definition associated with the software application 318 of the resulting communication and/or associated with the requested enterprise resource 130 (or other resource). Enterprise agent 320 generates an application tunneling request identifying the retrieved tunnel definition and encapsulates at least a portion of the application-generated communication within one or more headers of an encapsulation protocol. Packaged application-generated communications are also referred to herein as "proxy-generated communications." Enterprise agent 320 sends the application tunneling request and the encapsulated application-generated communication (which together may constitute a single communication) to tunnel intermediary 224 (e.g., via connections 142 and 144 of FIGS. 1A and 1C or via connections 142 and 160 of FIG. 1B ). or another such intermediary defined in the tunnel definition. The skilled artisan will appreciate that the defined tunnel intermediary may be one of a plurality of tunnel intermediaries associated with proxy 320 and enterprise system 110 .

Tunnel broker 224 receives application tunneling requests (which identify tunnel definitions) and proxy-generated communications. Tunnel broker 224 may read the tunnel definition identified in the tunnel formation request and then retrieve the identified tunnel definition from repository 228 . Tunnel broker 224 may determine the URL and/or port of the computer server or other computing device where requested enterprise resource 130 is located from the retrieved tunnel definition or even from information provided in the tunnel formation request. Tunnel broker 224 opens a network connection to a server port (eg, connection 152 of FIGS. 1A and 1C or connection 162 of FIG. 1B ). In some implementations, tunnel intermediary 224 maintains a connection to enterprise resource 130 at all times or during a pre-scheduled time frame such that a connection may be immediately available upon receipt of an application tunneling request from mobile device 120 . Based on the encapsulation protocol, the tunnel intermediary 224 extracts the application-generated communication from the proxy-generated communication and sends the application-generated communication to the URL/server port associated with the requested enterprise resource 130 . At this point, an application tunnel is formed between the mobile device 120 and the requested enterprise resource 130 . In some implementations, the tunnel broker 224 sends a message back to the mobile device 120 to indicate the formation of the tunnel and to ask the enterprise agent 320 to affirmatively accept the tunnel before sending the application-generated communication to the enterprise resource 130 . Once the tunnel is formed, enterprise proxy 320 can send additional application-generated communications (encapsulated using an encapsulation protocol) to tunnel intermediary 224 , which can forward them to enterprise resource 130 .

Communications in the opposite direction (eg, from enterprise resource 130 to mobile device application 318 ) may be encapsulated by tunnel intermediary 224 , sent by tunnel intermediary 224 to mobile device 120 , and then unpacked by enterprise proxy 320 according to the encapsulation protocol. Tunnel intermediary 224 may communicate with enterprise resource 130 as if intermediary 224 were mobile device application 318, and cause resources generated by enterprise resource 130 to return to tunnel intermediary 224 (e.g., via connection 152 of FIGS. 1A and 1C and connection 162 of FIG. 1B ). ). When tunnel intermediary 224 receives such responses to application-generated communications, tunnel intermediary 224 may encapsulate at least a portion of each of these "resource-generated responses" in one or more headers, such as HTTP headers, according to an encapsulation protocol Internally, and then send the encapsulated response to the enterprise agent 320 (eg, via connection 144 or 142 of FIGS. 1A and 1C and connection 160 or 142 of FIG. 1B ). Tunnel broker 224 may be configured to send its communications to a specific port of mobile device 120 as defined in the tunnel definition associated with the operational application tunnel. Enterprise proxy 320 may be configured to "listen" for tunneled communications from tunnel intermediary 224 on this local port. Based on the encapsulation protocol, enterprise agent 320 can extract the resource-generated response from the one or more headers and then provide the resource-generated response to application 318 .

In this type of application tunneling, a software application 318 installed on a mobile device 120 may be given the impression that it is directly connected to a resource (e.g., enterprise resource 130) associated with the URL of the network request issued by the application 318 . In fact, application 318 actually communicates with the resource via a tunnel intermediary (eg, tunnel intermediary 224). Therefore, the application 318 does not need to be aware of the existence of the tunnel.

In some implementations, enterprise agent 320 may be configured to filter out those application-generated communications that meet predetermined and/or configurable criteria. Such criteria may include, for example, any one or more of the following, as well as various other criteria: (1) URL (e.g., of enterprise system 110, of a web site whose access is restricted by the enterprise), (2) server port, Application 318 attempts to send a request to this server port, (3) data about the requesting application (e.g., name, version, etc.), (4) time of day, (5) day of week, and/or (6) mobile The geographic location of the device 120 . Such filtering criteria may be communicated by enterprise system 110 to mobile device 120 via wireless communication to enterprise agent 320 .

In one method of initiating the formation of an application tunnel, enterprise agent 320 is configured to intercept application-generated communications from software application 318 . For example, in mobile devices 120 running certain Microsoft ^™ operating systems (eg, Windows Mobile ^™ , Windows CE ^™ ), a Layered Service Provider (LSP) may be used to filter network requests issued by mobile device applications 318 . The LSP, which is a feature of the Microsoft Windows Winsock 2 Service Provider Interface (SPI), is a DLL that uses the Winsock API to insert itself within the TCP/IP protocol stack. Once in the stack, the LSP can intercept and modify incoming and outgoing Internet traffic. The LSP may allow handling of all TCP/IP traffic that occurs between the Internet and the device's software applications 318 . The LSP can be configured to be loaded automatically by any application 318 using the network connection. LSP has a layered model, like filters. Therefore, whenever an application 318 makes a network call, it goes through the LSP. The LSP allows enterprise proxy 320 to intercept every application network communication attempting to send information to one or more specified URLs, and redirect the communication to a tunneling intermediary, such as intermediary 224 associated with enterprise system 110 . In this manner, enterprise proxy 320 can detect requests from applications 318 to connect to enterprise resources 130 and modify and redirect the requests to the URL of the tunneling intermediary. Enterprise proxy 320 may be configured to filter requests from application 318 through one or more identified ports of enterprise resource 130 . Enterprise proxy 320 may be configured to select a port of the tunneling intermediary to send the redirected request based at least in part on the enterprise resource port provided within the request.

As mentioned above, after the tunneling broker establishes the application tunneling connection between the brokering and the requested resource, the brokering can send its notification to the enterprise proxy 320, and the enterprise proxy 320 can accept the application tunneling connection. All of these operations can occur transparently with respect to the software application 318 . According to some implementations, the application 318 may send the network request via the tunnel intermediary without modification or reconfiguration of the application 318 .

Unfortunately, in some mobile devices, it may be difficult or even impossible for mobile device 120 to intercept network connection requests issued by software application 318 . Some mobile device operating systems, such as iOS ^™ and Android ^™ , can limit the ability of different software applications to interact with each other and share data. Such restrictions may sometimes be referred to as "sandboxing" of software applications, and may be useful in preventing rogue applications from stealing data from mobile device 120 and sending data to unauthorized Internet locations. This prevents enterprise applications 320 from accessing or modifying network requests made by applications 310 .

Thus, another method of initiating the formation of an application tunnel is to reconfigure how software applications 318 send their network requests (or at least some of them). In some embodiments, the software application 318 is reconfigured to send its network requests to the local host of the mobile device 120, which is on a specified mobile device port. Enterprise proxy 320 may be configured to "listen" to this port and react to the application's network request by establishing a connection with the tunnel broker (if it is not already established) to open an application tunnel with the resource requested by application 318. Enterprise agent 320 may consult the relevant application tunnel definition in order to determine the port to listen to for application tunnel requests. In other implementations, the software application 318 is reconfigured to send at least some of its network requests directly to the tunneling intermediary. Additionally, the application 318 may also be configured to "unpack" (encapsulate via an encapsulation protocol) communications received from the tunneling intermediary. The enterprise may make available an application store of downloadable mobile device applications 318 configured to generate application tunneling requests as described herein.

The encapsulation protocol used to create the application tunnel is now further described. Enterprise agent 320 or software application 318 (depending on which particular method of forming an application tunnel is used) may be configured to modify the software application's network connection request using any of a variety of different methods or encapsulation protocols. An encapsulation protocol for use in application tunneling may allow the addition of metadata for various purposes. For example, the encapsulation protocol may identify a particular application tunnel via added metadata that allows the tunnel intermediary to distinguish that tunnel from other application tunnels that the tunnel intermediary may handle concurrently. This can help prevent data from being mixed between different application tunnels, helping to ensure that tunneled data is distributed to the correct resource (eg, enterprise resource 130). In other words, the encapsulation protocol can add metadata that enables multiple application tunnels to be multiplexed for transport over a common connection. The added metadata can also specify the length of each message sent through the tunnel. The added metadata may also be independent of the application tunnel or the application 318 that initiated the tunnel, such as a list of software applications 318 installed on the mobile device 120 or the result of a command sent by the mobile device management system 126 to the mobile device 120 . Such data may be used by mobile device management system 126 to update mobile device information 204 .

A typical network connection request generated by software application 318 may use a multi-layer communication protocol involving multiple protocol headers. In a simplified example, an access request generated by software application 318 may take the following form:

[IP header][TCP header][HTTP header][SOAP header][SOAP body],

Where "IP" refers to Internet Protocol, "TCP" refers to Transmission Control Protocol, "HTTP" refers to Hypertext Transfer Protocol, and "SOAP" refers to Simple Object Access Protocol. In this example, the mobile device's enterprise agent 320 may be configured to intercept this communication at the TCP layer (e.g., through the use of LSPs), and then repackage or encapsulate the TCP payload in multiple layers according to the encapsulation protocol used by the enterprise agent 320 (which in this example is [HTTP header][SOAP header][SOAP body]). For example, enterprise agent 320 may repack or encapsulate TCP payloads within multiple layers of: SSL (Secure Sockets Layer), TCP, IP, etc. Enterprise proxy 320 may then send the encapsulated request to the tunnel intermediary. In other embodiments as described above, the software application 318 may be configured to send the request to a local port of the mobile device 120 from which the enterprise proxy 320 receives, encapsulates, or redirects the request to a tunnel intermediary) or even encapsulates request and send it directly to the tunnel broker.

When an encapsulated request is received from mobile device 120, the tunnel intermediary can unpack the request according to the encapsulation protocol. In the above example, the tunnel intermediary extracts the TCP payload generated by the software application 318 of the mobile device. The tunnel intermediary may then send a TCP payload to the URL/port (derived from the associated tunnel definition 228 ) of the requested enterprise resource 130 (eg, the server port of the server on which the requested enterprise resource 130 is installed). In the above example, the extracted TCP payload contains higher level protocols, HTTP and SOAP. In some implementations, the encapsulation protocol uses Secure Sockets Layer (SSL) over HTTPS to tunnel.

5 is an embodiment illustrating a method in which an enterprise proxy 320 of a mobile device 120 redirects communications generated by a mobile device application 318 to an enterprise resource 130 through an application tunnel. In step 502 , application 318 generates a network request to access enterprise resource 130 of enterprise computer system 110 . As explained above, this request may include a payload to the enterprise resource 130, encapsulated within other protocol headers ("application generated communication"). In step 504, enterprise agent 320 intercepts or receives the request. In step 506, enterprise proxy 320 modifies the request by encapsulating some or all of the request within one or more headers (creating a "proxy-generated communication") according to the encapsulation protocol. For example, enterprise agent 320 may encapsulate a portion of a payload containing a response to enterprise resource 130 . In step 508, enterprise agent 320 opens a network connection (e.g., connections 142, 144 of FIGS. 1A and 1C or connection 142 of FIG. , 160). In step 510, the enterprise proxy 320 sends the proxy-generated communication to the tunneling intermediary via the network connection. At step 512, the enterprise agent 320 receives data from the tunneling intermediary, the received data being in response to the request ("resource-generated response"). Received data may be encapsulated according to an encapsulation protocol, and enterprise agent 320 may need to unpack the data, eg, according to an encapsulation protocol. Finally, in step 514 , enterprise agent 320 provides the received data to application 318 .

FIG. 6 is a flowchart illustrating an embodiment of an application tunneling method from the perspective of the enterprise system 110 . As with all methods described herein, some of the illustrated steps may be optional. In step 602 , a tunnel broker (eg, tunnel broker 224 ) of or associated with enterprise system 110 receives a request from mobile device application 318 to access enterprise resource 130 . As explained above, the request may include agent-generated communications intercepted or received by the device's enterprise agent 320, modified according to the encapsulation protocol, and then redirected to the tunneling intermediary (e.g., via network communication links 142 and 144 of FIG. 1A)— Application Generated Communications. The request may include a payload to the enterprise resource 130 . In step 604, enterprise system 110 may determine whether access to enterprise resource 130 is authorized. For example, mobile device manager 202 or tunnel intermediary 224 may determine whether the request is permissible under one or more enterprise access policies 218 of mobile device management system 126, as described below. In step 606, after the request is authorized, the tunnel intermediary extracts the payload to enterprise resource 130 from the encapsulated request. In step 608, the tunnel intermediary or another component of enterprise system 110 records information about the request and/or payload. This recording function is described in more detail below. In step 610, the tunnel broker opens a resource network connection (eg, connection 152 of FIGS. 1A and 1C or connection 162 of FIG. 1B ) between the tunnel broker and the server port associated with the requested enterprise resource 130 . In step 612, the tunnel intermediary sends at least the enterprise resource payload to the server port via the resource network connection. In many applications, enterprise resource 130 responds to the request by sending data back to mobile device 120 ("resource-generated response"). Accordingly, in step 614, the tunnel intermediary receives data (eg, a plurality of data packets) from enterprise resource 130 via the resource network connection. The data generally responds to the request received in step 602 . In step 616 , the tunnel intermediary (or another component) records information about the data received from enterprise resource 130 . Finally in step 618 the tunnel broker sends the data to the mobile device 120 .

The illustrated recording steps 608 and 616 of FIG. 6 may allow an enterprise to note the progress of data flowing through resource network connections (eg, connections 152, 162 of FIGS. 1A-1C ) between the tunnel intermediary and enterprise resource 130 . The use of application tunneling for such logging enables user and device behavior to be tracked at a more granular level and under greater levels of control. For example, because each application tunnel is typically tied to a particular mobile device 120, user, and mobile application, data transmitted over that tunnel related to that mobile device, user, and application may be stored. This gives businesses greater visibility into the activities of their mobile device users 115 . The Tunnel Broker (or other components related to it) may be configured to record various types of information, such as the actual data sent over the resource network connection, the amount of data sent over the resource network connection, the type of data sent over the resource network connection, The name of the file sent over the resource network connection, the number of times a particular user has accessed one or more enterprise resources 130, the time when a user requested access to one or more enterprise resources 130, and the like. Analysis can be generated from recorded data. Mobile device management system 126 may set rules based on such analysis. As one example, access to one or more enterprise resources 130 may be restricted for mobile devices 120 with large downloads.

Application tunneling as described above may also be used for purposes other than accessing enterprise resources 130 . For example, an application tunnel may be used to conduct a "remote control session" between the mobile device 120 and the controller computer, as described below with respect to Figures 12, 13, and 18.

Another use of application tunneling involves so-called "web filtering" or "content filtering," where an enterprise may wish to limit network sites (eg, websites) or other online information resources that mobile device 120 is authorized to access. Performing content filtering using application tunneling may be accomplished using features related to modifying pre-existing mobile applications or/or through the use of a secure web browser as described below. Access may be granted, for example, always, only during business hours, etc. In some embodiments, enterprise proxy 320 may be configured to tunnel intranet and/or Internet requests generated by mobile device 120 (for information resources available on the World Wide Web, such as URLs entered into a web browser or The HTTP request generated by the web browser) is redirected to the content filtering server associated with the enterprise. A content filtering server acts as a tunnel intermediary and checks each request to determine whether the requested site is authorized by the enterprise. For example, the content filtering server may maintain a list of sites that are "blacklisted" by the enterprise, and may deny requests to access the blacklisted sites. In some implementations, this determination may be based on the particular mobile device 120 and user 115 making the request (eg, based on the user role 206). The content filtering server may be located within or outside of enterprise system 110 and may be a third party server operated at least in part for the benefit of the enterprise. If the request is authorized, the content filtering server may send the request to a server associated with the authorized site to be accessed by the mobile device 120 . The content filtering server may be configured to modify the request to remove any headers generated by the enterprise proxy 320 to form an application tunnel with the content filtering server (according to the encapsulation protocol). The server associated with the requested site may then receive the request as if it had never been sent to the content filtering server.

Figure 25 illustrates an embodiment in which an application tunnel is created using an enterprise agent 320 running on a mobile device 120 (one shown). In this embodiment, the enterprise proxy 320 includes or acts as an HTTP proxy server 320a for one or more mobile applications running on the mobile device 120 . Enterprise agent 320 communicates via a wireless network (WIFI, cellular, etc.) with mobile device management system 126 , which may be implemented, for example, on a dedicated server within enterprise system 110 . The mobile device management system 126 shown in FIG. 25 includes a web management console 126a that enables administrators to configure and deploy application tunnels between mobile devices 120 and application servers 2500 via a web-based interface. The mobile device management system 126 shown in FIG. 25 also includes a tunnel broker 126 b that implements the tunnel encapsulation protocol and routes packets between the mobile device 120 and the application server 2500 .

In this embodiment of FIG. 25, the enterprise agent 320 when deploying the application tunnel creates a socket that listens on a specific port known to the mobile application using the application tunnel. When the mobile application writes to this port (by writing to localhost:XXX, where "XXX" is the listening port number), the enterprise proxy 320, acting as an HTTP proxy for the mobile application, for example, encapsulates and forwards the message, as described above. More specifically, when a mobile application generates an HTTP request directed to the application server 2500 (or other resource) of the enterprise system 110, the enterprise proxy 320 intercepts the request and passes it through the application tunnel established between the mobile device 120 and the mobile device management system 126 send request. The tunnel intermediary component 126b of the mobile device management system 126 then extracts the encapsulated HTTP message and sends it to the relevant application server 2500 .

A potential problem with this approach is that some application servers such as Microsoft SharePoint will reject requests if the hostname is incorrect. To handle this, the enterprise proxy 320 in some embodiments replaces the hostname (localhost:XXX) in the intercepted request with the correct hostname of the target application server 2500. This involves modifying one or more relevant HTTP headers of the original HTTP request received from the mobile application and then sending the modified HTTP request via the application tunnel. In other implementations, the task of replacing the hostname is instead performed by the mobile device management system 126 when receiving and extracting the encapsulated HTTP request.

The process by which HTTP requests are intercepted and modified in the configuration of FIG. 25 is further shown in FIG. 27 . In event A, the administrator configures and deploys an application tunnel between the mobile device 120 and the application server 2500 . This can be accomplished using the web management console 126a as will be described below. In event B, the proxy 320 in response to deployment of the tunnel creates a socket and begins listening on the relevant port (addressable as localhost:XXX). In event C, proxy 320 acting as an HTTP proxy receives or “intercepts” an HTTP request from an application running on mobile device 120 and modifies the hostname to the actual hostname of target application server 2500 . Proxy 320 then encapsulates the modified HTTP request and sends it to mobile device management system 126 . In event D, the tunnel broker 126b running on the mobile device management system 126 extracts the modified HTTP request and sends it to the application server 2500 associated with the tunnel. The tunnel intermediary 126b also encapsulates the application server's response for transmission to the mobile device 120 .

FIG. 26 illustrates one embodiment of a tunnel configuration page/screen provided by the web management console 126a of FIG. 25 . An administrator can use this page to establish an application tunnel between a particular mobile device 120 and the application server 2500 . In the example shown in FIG. 26 , the tunnels would be deployed on and specific to a single mobile device 120 . The "Application Device Parameters" section includes a "Client Port" field for specifying the port on which the proxy 320 listens on the mobile device 120 . The Application Device Parameters section also includes three options for specifying how traffic will be intercepted and redirected. The page also includes various other configuration options, including the option to use a secure (SSL) connection.

Referring again to FIG. 25, in some configurations, a custom SSL (Secure Sockets Layer) library 320b may be installed on the mobile device 120 to support secure application tunneling. Custom SSL library 320b may be part of proxy 320 (shown in Figure 25) or may be different. The custom SSL library 320b complements the standard SSL library provided by the mobile device's operating system and modifies the SSL handshake protocol in a way that enables the SSL handshake sequence to be performed over the application tunnel. More specifically, the custom SSL library enables mobile device 120 to accept transmission of a digital certificate by an application server even if the hostname transmitted by using this digital certificate does not match the expected hostname. In contrast, the standard SSL libraries typically provided with existing mobile operating systems will reject the application server's digital certificate in this case. The custom SSL library 320b can perform this task by overriding some of the trust management certificate checking functions to create exceptions for mismatches in hostnames as part of the certificate. To support the use of custom SSL library 320b, application developers may be provided with APIs (eg, Java files) that enable them to develop mobile applications that use custom SSL library 320b to establish SSL connections.

FIG. 28 illustrates additional processing performed when an application tunnel is established as a secure (SSL) tunnel in the configuration of FIG. 25 . During this process, a custom SSL library 320b (shown in FIG. 25 ) installed on the mobile device 120 makes an exception to the requirement that the application server's digital certificate must specify a hostname that matches the expected hostname. In Event A of Figure 28, the administrator configures and deploys HTTPS application tunneling, preferably using the web management console 126a. In event B, proxy 320 spawns a socket and begins listening on port localhost:XXX, as described above with respect to FIG. 27 . (Although not shown in FIG. 27, proxy 320 in this embodiment uses the same process as shown in FIG. 27 to intercept and modify requests from applications.) In event C, mobile device 120 uses custom SSL library 320b to initiate an SSL handshake with the application server 2500 via the application tunnel. This involves the mobile device 120 sending a hello message, including the SSL version, encrypted and compressed information, and a 28-byte random number. This message is intercepted by proxy 320 (as described above with respect to FIG. 27 ) and sent via proxy 320 to mobile device management system 126 , which forwards the message to application server 2500 .

In event D of Figure 28, the application server 2500 responds by returning a digital certificate containing the public key and cipher suite. This digital certificate contains or specifies the hostname of the proxy 320's local host (localhost:XXX). Normally (ie, if the standard SSL library is used), the SSL library will reject this digital certificate because it expects the digital certificate to specify the hostname of the application server. As shown in Event E of Figure 28, custom SSL library 320b avoids this problem by making an exception to this requirement. A custom SSL library can generate this exception by updating the SSL Trustmanager to allow a mismatch between the application server's hostname and the localhost's hostname used by proxy 320 . (Although exceptions can be made for all hostnames, this can facilitate man-in-the-middle attacks.) As further shown in event E, custom SSL library 320b also sends to application server 2500 an authentication code key encrypted with the application server's public key . Thus, the mobile device 120 and the application server 2500 can use the symmetric key for encryption during the duration of the SSL session.

Use of mobile device management systems to regulate mobile device access to enterprise systems

If mobile device management system 126 is used as a tunnel intermediary for an application tunnel between mobile device 120 and enterprise resource 130 , system 126 may be configured to regulate device access to resource 130 . System 126 may be configured to read information from the application tunnel request header or body, compare it to mobile device data 204 (FIG. 2) to determine information about user 115 and/or mobile device 120 associated with the request, and implement Access policy 218 to allow or deny application tunneling requests. Access policies 218 may be enforced based on locally stored user roles 206, mobile device characteristics 208, user device assignments 210, other data, or any combination thereof. It will also be understood that any tunnel intermediary other than intermediary 224 may be configured to enforce access policy 218 so long as the tunnel intermediary has access to mobile device information 204 .

FIG. 7 is a flow diagram illustrating an embodiment of a method in which a tunneling intermediary, such as intermediary 224 in FIG. 2 , uses access policies 218 to regulate mobile device access to enterprise resources 130 . Mobile device management system 126 may be configured to receive an application tunnel access request from mobile device 120 (eg, via application tunnel using network connection 142 or 144 ) to access enterprise resource 130 . Accordingly, in step 702 of FIG. 7 , the mobile device management system 126 receives an access request from one of the mobile devices 120 . In some embodiments, when such a request is received from a mobile device 120, the tunnel intermediary 224 is configured to deny the request if one or more characteristics of the mobile device 120 and/or one of the characteristics assigned to the user 115 of the mobile device 120 One or more properties do not comply with one or more access policies 218 . Accordingly, in decision step 704, tunnel intermediary 224 determines whether one or more characteristics of mobile device 120 comply with one or more associated access policies 218 (eg, general access policies or access policies related to the requested enterprise resource 130). The mobile device characteristics against which tunnel intermediary 224 may evaluate the access request may be device characteristics 208 or other characteristics determined from the request itself. If the mobile device characteristics determined from the access request do not comply with the associated access policy 218, then in step 710, the tunnel intermediary 224 may deny the access request. On the other hand, if the mobile device characteristics conform to one or more relevant access policies 218, the method proceeds to decision step 706, where the tunnel intermediary 224 determines whether the one or more characteristics assigned to the user 115 of the mobile device 120 conform to one or more of the relevant access policies 218. A number of related access policies 218 . The characteristics of the user 115 may be, for example, the user's role 206 or other user-related information that may or may not be stored within the mobile device information 204 . Tunnel broker 224 may determine which user 115 is assigned to mobile device 120 by, for example, using user device assignment record 210 . If the one or more user characteristics comply with the one or more access policies 218, the tunnel intermediary 224 allows the mobile device 120 to access the requested resource 130 (via connection 152 or 162) in step 708. If not, tunnel broker 224 denies access in step 710 . It will be appreciated that this approach allows an enterprise to regulate mobile device access to enterprise resources 130 based on various combinations of mobile device characteristics and user characteristics in a very flexible manner.

As mentioned above, in some implementations, the tunnel intermediary 224 is located outside the enterprise system 110 (eg, in a cloud computing system as in FIG. 1B ). It will be appreciated that mobile device information 204 , enterprise access policies 218 , mobile device rules 214 , and/or remedial action descriptions 216 may also be stored outside enterprise system 110 , eg, along with tunnel intermediary 224 . In those implementations, the tunnel intermediary 224 can still be configured to receive access requests from the mobile device 120 and then allow or deny the requests based on the access policies 218 . In such an embodiment, tunnel intermediary 224 may be configured to route the granted access request to a network node located within enterprise system 110 , which in turn routes the request to the requested enterprise resource 130 . For example, a network node may include a computer server, secure mobile gateway 128, or another network device.

Examples of policies used to control mobile device access to enterprise system resources

There are many possible situations in which an enterprise may wish to regulate or limit mobile device access to enterprise resources 130 based on mobile device characteristics and/or characteristics of users 115 assigned to mobile devices 120 . Several of these "use cases" are now described. For clarity, the use cases are now enumerated. Furthermore, for simplicity, usage is described in the context of access policies 218 stored in mobile device management system 126 . As discussed above, system 126 can be a provider 408 of gateway rules 404 for secure mobile gateway 128, or/or can regulate mobile device access to enterprise resources 130 via application tunneling. However, it will be appreciated that such gateway rules 404 may be created and provided to gateway 128 by any other provider 408 .

The skilled artisan will understand that the examples below represent only a fraction of the full range of possibilities for how enterprise access may be regulated using the disclosed components and/or processes. For example, it will be appreciated that access policy 218 may depend on a combination of characteristics of user 115, characteristics of mobile device 120 (e.g., device characteristics 208), specific enterprise resources 130 to which access is requested, and other information, as provided below The specific examples of are merely illustrative and far from exhaustive. Furthermore, it will be understood that some use cases may be combined.

Use Case 1 : One or more access policies 218 may require mobile devices 120 requesting access (“access requesting devices”) to register with the mobile device manager 202 . This helps prevent access to enterprise resources from being given to people not associated with the enterprise.

Use Case 2 : One or more access policies 218 may require that the access requesting device 120 be a certain device type (eg, iPhone ^™ , Mobile ^™ , etc.).

Use Case 3 : One or more access policies 218 may require that the access requesting device 120 have certain settings, such as being password protected. This helps prevent enterprise resource access from being given to someone not associated with the enterprise (e.g., not user 115), but who somehow obtains mobile device 120 (e.g., misplaced or lost device 120 by assigned user 115) and attempts to Enterprise system 110 is accessed.

Use Case 4 : One or more access policies 218 may require the access requesting device 120 to use the current operating system version.

Use Case 5 : One or more access policies 218 may require that an access requesting device 120 comply with an enterprise's security requirements (eg, antivirus requirements). Allowing device 120 to access enterprise resource 130 may allow a virus to infect resource 130 if mobile device 120 is not compliant (e.g., does not have up-to-date antivirus software installed or has not had a sufficiently recent automatic scan of its files, data, or applications for viruses). , potentially jeopardizing the operability of the enterprise system 110, or at least the specific resource 130 to which access is given. Accordingly, these types of access policies 218 may prevent such undesired outcomes.

Use Case 6 : One or more access policies 218 may require that the access requesting device 120 is not "jailbroken". Jailbreaking is the process of allowing a mobile device 120 to gain full access ("root access") to unlock all features of its operating system, thereby removing restrictions that may be imposed by the device manufacturer. Once jailbroken, mobile device 120 may be able to download previously unavailable applications and extension files. Jailbreaking the mobile device 120 provides access to its root file system, allowing modification and installation of third-party software components. As such, a jailbroken device is often a device with security protections removed. Thus, preventing jailbroken devices from accessing enterprise resources 130 further protects enterprise systems 110 from security threats and vulnerabilities.

Use Case 7 : One or more access policies 218 may require that the access requesting device 120 not install unauthorized applications. In this example, an "unauthorized application" may be a software application that is not authorized to be installed on the access-requesting device 120 or/or on a particular group of devices 120 of which the access-requesting device is a member.

Use Case 8 : One or more access policies 218 may require that a user 115 assigned to an access requesting device 120 have one or more predetermined roles 206 associated with the enterprise. For example, access policy 218 may deny mobile device access to one or more enterprise resources 130 assigned to mobile device 120 of user 115 having a role 206 not related to sales, engineering, or upper management.

Use Case 9 : One or more access policies 218 may depend on which particular enterprise resource 130 is requested to be accessed by the access requesting device 120 . For example, the conditions under which an enterprise may allow mobile devices to access CRM resources may differ from the conditions under which an enterprise may allow access to a product information database. Accordingly, different access policies 218 can be created and used for different enterprise resources 130 . In addition to being dependent on the requested enterprise resource 130, the access policy 218 may also require that the user 115 assigned to the access requesting device 120 have certain characteristics, such as a specific role 206 (as in use case 8 described above) or Another status indication. For example, an enterprise may wish to give mobile device access to CRM resources 130 only to users 115 with roles 206 related to sales or upper management. In that case, the access policy 218 of the CRM resource 130 may require that the user 115 assigned to the access-requesting device 120 have a sales or upper management role 206, and the mobile device administrator 202 may be configured to deny requests from users assigned to users without those roles. 206 the user's mobile device 120 requests. The access policy 218 may further require that the user 115 assigned to the access requesting device 120 comply with enterprise regulations (eg, the employment of the user 115 is not terminated and is not in trial status).

meta app

Referring again to FIG. 1A , meta-application 150 , if present, may be configured to discover, model, and/or monitor various components of enterprise system 110 , including through the methods described in Qureshi '536. Meta-application 150 may also be configured to use coded logic rules to detect "signatures" and "problems," perform "root cause analysis," plan "remedial actions," and/or execute remedial actions on enterprise systems 110, including through the Qureshi' The method described in 536. In this context, a logic rule may comprise a logical combination of features of the managed system 110 and may correspond to at least one question. In addition, logic rules may include queries for specific information from enterprise systems ("telemetry queries") or queries for models from enterprise systems ("enterprise model queries"), where the enterprise models are generated by meta-applications 150 . A problem may include any problematic state of any software, hardware, or firmware of enterprise system 110 or mobile device 120 . The meta-application 150 can detect problems through logic that satisfies corresponding logic rules. Features may include conditions of the problem. For example, logical rules may include telemetry data queries or enterprise model queries for detecting characteristics of the enterprise system 110 . Root cause analysis may refer to the detection of components (again, software, hardware, firmware, or even relationships between such types of components) that are the "root cause" of observed problematic behavior. Meta-application 150 may be configured to address detected issues by planning or executing remedial actions related to the issue.

The input (e.g., features) to the logical rules used by the meta-app 150 to detect problems may not only come from the "back end" of the enterprise system 110 (the part of the system 110 behind the internal firewall 124), but also from other sources, such as a secure mobile gateway 128. An embodiment of an enterprise agent 320 on a mobile device 120, or an application tunneling intermediary such as a mobile device management system 126. For example, an input to a logic rule may be the permission or denial of an access request 402 made by a mobile device through the secure mobile gateway 128 . For example, a logic rule may specify a particular problem, at least in part, as the denial of access through the gateway 128 of the enterprise system to the mobile device 120 used by the CEO of the enterprise. If the CEO is denied access, then the data indicating this event satisfies this part of the logical rule. In another example, an input to a logic rule may be data instructing user 115 to download data greater than a certain threshold amount within a specified period of time. Such data may be provided to meta-application 150 by an application tunneling intermediary. In yet another example, the input to the logic rule may be data indicative of a device's configuration or capabilities, such as data indicating that the user 115 has installed a certain software application on the user's mobile device 120 . Such data may be provided to the meta-application 150 by the enterprise agent 320 of the user's device 120 .

In some implementations, one type of remedial action defined by the logic rules used by the meta-application 150 may be the creation of new gateway rules 404 or the modification of existing gateway rules 404 along with sending the new or modified gateway rules to the secure mobile gateway 128. In this manner, the meta-app 150 can be configured to programmatically control the gateway 128 to prevent mobile device access in an automated fashion. Another type of remedial action may be the creation of a new access policy 218 or the modification of an existing access policy 218 along with sending the new or modified policy to the mobile device management system 126 . Another type of remedial action may be creation of mobile device rules 214 or modification of existing mobile device rules 214 along with sending new or modified mobile device rules to mobile device management system 126 and/or one or more mobile devices 120 . Another type of remedial action may be to send commands directly to one or more mobile devices 120 for execution by enterprise agent 320 . In this manner, meta-app 150 can effectively perform actions on device 120, such as wiping data or applications from device 120, locking device 120 (i.e., preventing use of device 120), preventing certain applications from being installed on the device Run, turn device features on or off, adjust device settings, etc.

In the embodiment of FIG. 1C , the meta-application includes a portion 150 residing in the enterprise's backend and a portion 151 residing in a cloud computing system or “cloud” 156 . Cloud-based system 156 is typically separate and distinct from enterprise system 110 (eg, the two systems do not share any physical computers or servers), and is typically primarily operated by a cloud service provider business entity that is separate and distinct from the enterprise. In some embodiments, the back-end meta-application part 150 collects data from the enterprise system 110, sends it to the cloud-based meta-application part 151, and possibly also detects "signatures" as mentioned above. In certain embodiments, cloud-based meta-application portion 151 uses data to model enterprise system 110 to detect "problems" and "root causes," plan remedial actions, and/or execute remedial actions.

Figure 8 illustrates one particular implementation of a partially cloud-based meta-application. A meta-application includes several components residing on enterprise server 802 and other components residing on servers within cloud 156 . Additionally, the meta-application communicates with the mobile device management system 126 , the secure mobile gateway 128 , and the enterprise device agent 320 running on the mobile device 120 .

In the illustrated embodiment, enterprise system 110 includes one or more computer servers 802, which may include some or all of the elements shown in system 110 of FIGS. 1A-C. A meta-application agent 804 may be installed on each server 802 that has components that need to be monitored and/or managed by the meta-application 150 . Each meta-application proxy 804 may be "born" (at install time) with the URL of the cloud-based meta-application portion. Optionally, agent 804 may be configured to receive a URL from an administrator. It will be appreciated that it is not necessary to install meta-application agent 804 on every computer server of enterprise system 110 . The enterprise-based portion of the meta-application may be configured to allow an IT administrator to select an enterprise server 802 with a meta-application agent 804 installed as part of the meta-application's installation process.

In the illustrated embodiment, meta-application agent 804 includes enterprise modeling processor 806 , telemetry data processor 808 , feature detector 810 , and remediation agent 812 . These components are now described.

Enterprise modeling processor 806 may be configured to access and/or obtain information from server 802 that is needed or useful for constructing queryable model 814 of the enterprise system. Enterprise model 814 may describe the hardware, software, and/or firmware of enterprise system 110 and may include, for example, configuration information, registry information, database information, and other information useful for evaluating logic rules 818 . The enterprise model 814 may include a graph of objects representing hardware, software, firmware, the relationships therebetween, and the like. Exemplary methods and approaches to modeling are described in Qureshi '536, particularly the sections relating to "Discovery" and "Applied Models". Each enterprise modeling processor 806 may be configured to construct a model of the particular server 802 on which it is installed. The cloud-based meta-application portion may be configured to receive data from the enterprise modeling processor 806 and use the data to construct an overall enterprise model 814 . The enterprise modeling processor 806 can be configured to send new data to the cloud-based meta-application portion on an ongoing basis to support dynamic updates of the enterprise model 814 . Finally, it will be appreciated that the enterprise agent 320 of the mobile device 120 may also be configured to conduct discovery of information about the device 120 and send the discovered information to the enterprise model 814, and the enterprise model 814 may thereby emulate one or more devices 120 and enterprise system 110 . In other words, agent 320 may include enterprise modeling processor 806 or similar functionality.

The telemetry data processor 808 may be configured to receive a request from the cloud-based meta-application portion 151 for specific data about the server 802 on which it is installed. Telemetry data processor 808 may be configured to respond to such requests by collecting the requested data (referred to herein as "telemetry data") and providing it to feature detector 810 for analysis. Telemetry data can include different types of data about the hardware, software, and/or firmware of the enterprise system 110, including without limitation configuration data, performance data, data about the mobile device 120, and from or about the mobile device management system 126, secure mobile Gateway 128 and enterprise resource 130 data. Telemetry data may include "status metric data" as described in Qureshi '536. State metric data may include raw time-varying data indicative of the state of server 802 or any component thereof. It will be appreciated that the enterprise agent 320 of the device 120 may also be configured to collect device data based on requests for device data from the meta-application portion 151 and send the collected telemetry data to the local feature detector 810 or back to the meta-application Section 151. In other words, agent 320 may include telemetry data processor 808 or similar functionality.

Feature detector 810 may be configured to analyze telemetry data received from telemetry data processor 808 to detect features of logical rules 818 . Features may be specified within telemetry data queries sent by the cloud-based meta-application portion to the meta-application proxy 804 . Performing feature detection at least partially within enterprise system 110, as opposed to within cloud 156, can significantly reduce the bandwidth used for communications between meta-application agent 804 and cloud 156 because in some applications not all telemetry data is available. is sent to cloud 156. For example, meta-application agent 804 may only send detected features to cloud 156 . The skilled artisan will understand that a signature may be less data sensitive than the raw telemetry data from which the signature was detected. For example, a feature may simply be an indication that a certain condition is true. In an alternative embodiment, feature detector 810 resides within cloud 156, and telemetry data processor 808 may send some or all of the collected telemetry data to the cloud for feature detection. It will be appreciated that the enterprise agent 320 of the mobile device 120 may also be configured to analyze telemetry data collected in response to requests from the meta-application portion 151 in order to detect characteristics of the logical rules 818 and send those characteristics back to the meta-application portion 151 . In other words, agent 320 may include feature detector 810 or similar functionality.

Remediation agent 812 may be configured to perform remedial action 820 on server 802 on which it is installed. The meta-application agent 804 can receive a remedial action 820 from the cloud-based meta-application portion. Although not shown in FIG. 8 , mobile device management system 126 may include remediation agent 226 ( FIG. 2 ), and secure mobile gateway 128 may include remediation agent 226 as well. Such a remediation agent may allow the meta-application to perform remedial actions on the mobile device management system 126 and the secure mobile gateway 128 . It will be appreciated that enterprise agent 320 of mobile device 120 may also be configured to perform remedial action 820 on device 120 . In other words, agent 320 may include remediation agent 812 or similar functionality.

Still referring to FIG. 8 , the illustrated cloud-based meta-application portion 151 includes a telemetry data monitor 822, an enterprise model 814, a logic rules repository 816, an inference engine 824, a repository of detected problems and/or root causes 826, a user interface 828 , notification manager 830 and remediation workflow module 832. It will be understood that the cloud-based meta-application portion need not include all of these components, and may also include additional components not shown in FIG. 8 .

Telemetry data monitor 822 may manage communications between the cloud-based meta-application portion and meta-application proxy 804 and any other component that provides data that the cloud-based meta-application portion may use to evaluate logic rules 818 Examples are enterprise agent 320 for mobile device 120 , mobile device management system 126 , and secure mobile gateway 128 . Accordingly, the telemetry data monitor 822 can receive the features detected by the feature detector 810 and can provide the features to the inference engine 824 . Telemetry data monitor 822 may be configured to prioritize incoming feature and other data such that more important or urgent information is passed to other components of the meta-application before less important or less urgent information.

Inference engine 824 may be configured to access repository 816 of logical rules 818 and evaluate whether individual rules 818 are satisfied by deployed features, where each satisfied rule corresponds to the detection of at least one problem. Logical rules 818 may include queries for information, such as telemetry data queries or enterprise model queries. Inference engine 824 may be configured to process these queries of logical rules 818 by querying enterprise model 814 or related agents of meta-application agent 804 for required information (eg, characteristics of the rule). Inference engine 824 may also be configured to perform root cause analysis to detect root causes of problematic behavior of enterprise system 110 . A root cause may be an object of an enterprise model 814 , which represents a component of an enterprise system 110 . The inference engine 824 may be configured to use rule evaluation methods and root cause analysis methods as taught in the '536 Qureshi patent (referring to discussions of "problem logic" and root cause analysis, respectively). Inference engine 824 may be further configured to log detected issues and root causes in repository 826 .

User interface 828 may allow administrators to interact with cloud-based meta-application portions. The illustrated user interface 828 includes a web server interface for easy access via the Internet. User interface 828 may also include a server terminal interface.

Notification manager 830 may be configured to send notifications to administrators about information detected or calculated by meta-applications, such as problems and root causes. Notifications may include, for example, emails, voice messages, SMS text messages, and the like. Preferably, the notification manager 830 allows the IT administrator to set and adjust the criteria under which the notification manager 830 sends notifications.

Remedial workflow module 832 may be configured to select remedial action 820 for attempting to resolve or address a problem or root cause detected by inference engine 824 . Remedial actions 820 may be stored in repository 816 of logic rules 818 . Remedial actions 820 associated with one or more logic rules 818 may be stored. Remedial workflow module 832 may be configured to determine an optimal sequence of execution of remedial actions 820 related to a detected problem or root cause. Remedial action 820 may be abstract or generalized to many different types of managed computer systems 110 . In that case, the remedial workflow module 832 can be configured to customize the remedial action 820 into a plan appropriate for the particular enterprise system 110 and mobile device 120 managed by the meta-application. The remediation workflow module 832 may be configured to send customized plans and/or other instructions to the remediation agent 812 of the meta-application agent 804, similar remediation agents of the mobile device management system 126 and the secure mobile gateway 128, or a remediation agent installed on the mobile device 120 Corporate Proxy 320 . These remedial/enterprise agents may be configured to execute plans and/or other instructions on such systems and devices. Planning may require human (eg, IT administrator) validation of planning steps for planned phases. Plans can also be designed to be executed by the remediation agent 812 without human intervention or approval.

Meta-application 150 of FIGS. 1A and 1B may include all of the components shown in FIG. 8 , including components that reside within cloud 156 , and all such components may reside within enterprise system 110 .

A meta-application component installed on mobile device 120 (e.g., within enterprise agent 320 or separately) may be configured to collect state metric data from device 120 and send that data back to cloud-based meta-application portion 150 and/or enterprise systems 110. Such data may be collected on a regular basis (eg, periodically) or when explicitly requested by the cloud-based or enterprise system-based meta-application portion. Such data may be analyzed (eg, using logical rules 818 by inference engine 824 ) to diagnose problems involving device 120 and select remedial actions for addressing such problems. Such analysis can be performed even if there is no currently available connection to device 120 .

Those of ordinary skill in the art will appreciate that meta-applications can be configured to implement and implement various different types of logic rules 818 and remedial actions 820 involving the mobile device 120 . For example, logic rule 818 may specify a problem as downloading more than a certain threshold amount of data to mobile device 120 . The enterprise backend portion of the meta-application may detect the throughput of data being downloaded to the user device 120 and determine whether it exceeds the threshold specified in rule 818 . Remedial action 820 related to rule 818 may entail disabling mobile device 120, or perhaps simply disabling the device's ability to download data. Such remedial action 820 may involve a meta-application of the enterprise agent 320 sending a command or script configured to implement remediation to the device. Optionally, remedial action 820 may entail revocation of the mobile device's certificate by the mobile device management system 126 . Still further, the rule 818 may revoke the device's permission to use the application tunnel for communication with the enterprise resource 130 or other network resources.

In another example, meta-app 150 may be configured to be created based at least in part on when mobile device 120 is "erased" (eg, deletion of some or all data stored on the device or removal of a software application from the device) Gateway rule 404.

In embodiments where the meta-app 150 is configured to manage Microsoft Exchange ^™ , the meta-app 150 may have full visibility into the ActiveSync partnership data of the mobile devices 120 associated with the enterprise. The meta-application 150 can use the ActiveSync partnership data to generate gateway rules 404 that filter mobile device access requests 402 based on such data. For example, the ActiveSync partnership data includes the ActiveSync DeviceID of the mobile device 120 . Meta-application 150 can use this information to generate gateway rules 404 that filter access requests 402 based on known DeviceIDs.

Management system present on the device

In some implementations, an enterprise may wish to regulate settings, applications, usage, other activities, or any combination thereof related to mobile devices 120 used by enterprise users 115 . This can prevent threats to the security of enterprise data and resources and/or address productivity risks—risks where a user uses the mobile device 120 in a manner that can negatively impact user productivity while meeting the user's responsibilities to the enterprise. Such an embodiment is now described.

With continued reference to FIG. 2 , the illustrated mobile device management system 126 includes a computer-readable storage repository 212 that stores a plurality of different mobile device rules 214 . Storage repository 212 may be implemented on any suitable non-transitory computer-readable medium. The mobile device rules 214 may be coded codes configured to be used by the mobile device 120 (e.g., by an enterprise agent 320 installed on the mobile device 120) to detect issues indicative of security and/or productivity risks to which the device 120 may expose the enterprise. Computer-readable rules. Many examples or "use cases" of issues that may be detected using mobile device rules 214 are described below.

Mobile device rules 214 may be relatively simple, taking the form of, for example, IF-THEN statements and/or simple declarative logic rules. In other embodiments, the mobile device rules 214 can be much more complex, such as the logic rules described in Qureshi '536, which describes logic rules configured to create virtual circuits with atomic gates and downstream operator gates. Mobile device rules 214 may include metadata for calculating various parameters related to the rules and related questions, such as confidence values indicating confidence in the detection of questions related to mobile device rules 214 as taught, for example, in Qureshi '536 .

In some implementations, mobile device rules 214 have the following format:

<rule name>

<security key><authentication information>

<encrypt><rule body>

The rule name may be the name of a specific mobile device rule 214 . If the rule 214 is encrypted, the security key may allow the enterprise agent 320 to decrypt the body of the rule. The authentication information may include data related to the applicability of the rules to the mobile device 120 . The enterprise agent 320 can use the authentication information to determine whether the rules 214 can run on the mobile device 120 . A rule body includes the underlying logic of the rule and is the part that the enterprise agent 320 evaluates in order to detect a problem and perform one or more related remedial actions 216 .

In certain embodiments, the mobile device rules 214 map one or more mobile device state metric data values to one of a number of aforementioned issues indicative of security risks and/or productivity risks to which the device 120 may expose the enterprise. . A "status metric" can be any data item that indicates the status of a mobile device, such as an error log entry, a record indicating activation of a device feature, operating system version, installed software applications 318 (including that an enterprise can "blacklist" as unauthorized installation), whether the mobile device 120 is roaming, the battery level of the mobile device 120, the signal strength of the signal received by the mobile device 120, the available memory of the mobile device 120, and the like. For example, a "status metric" may be a metric that indicates whether a mobile device feature (eg, camera, web browser, password protection, etc.) is activated. Another example of a status metric is an indicator of whether the mobile device's SIM card is properly engaged with the mobile device 120 . Other examples of state metrics will be apparent from the examples of mobile device rule applications provided below.

With continued reference to FIG. 2 , the repository 212 may include a plurality of encoded computer-readable remedial actions 216 for addressing the problem. In some implementations, each remedial action 216 corresponds to one or more issues related to mobile device rules 214 . Examples of remedial actions 216 are provided below. In some implementations, the mobile device management system 126 (or another component of the enterprise system 110 ) can include a tool 221 to assist IT staff in creating and/or editing mobile device rules 214 and/or remedial actions 216 . Such tools 221 may include, for example, a custom word processor or other software application with extensions, guides, etc. to help construct rules 214 and/or actions 216 .

In some implementations, mobile device rules 214 and their associated remedial actions 216 are organized into separate "rule packages," each rule package including one or more rules 214 and, preferably, the rules' associated remedial actions 216 . Each rules package can be designed or customized for a user 115 using a particular type of user persona 206 and/or mobile device characteristics 208 . Accordingly, each rules package may be associated with one or more user roles 206 and/or with one or more mobile device characteristics 208 . For example, a rule package of mobile device rules 214 and associated remedial actions 216 may be prepared for all users 115 with a sales-oriented role 206 (eg, all salespeople in an enterprise). As another example, one rules package may be prepared for people using iPhones ^(TM) , and another rules package for people using Android ^(TM) devices. Mobile device rules 214 and associated remedial actions 216 may be developed for different types of mobile devices 120 if it is desired to differentiate permissible activities associated with mobile device users 115 having a given role 206 based on differences in mobile device characteristics 208 different rule packs. For example, an enterprise may form one rule package of mobile device rules 214 and remedial actions 216 for salespeople using iPhones ^™ , another rule package of mobile device rules 214 and remedial actions 216 for salespeople using Android ^™ devices, etc. . In this manner, rule packages can be customized for different user roles 206 and/or mobile device characteristics 208 as desired.

It will be appreciated that different mobile device rule packages may share common mobile device rules 214 and/or remedial actions 216 . For example, assume that a first mobile device rule and related remedial actions are appropriate for salespeople and company board members, and a second mobile device rule and related remedial actions are only applicable for salespeople. A rule package for a user 115 who is a salesperson may include first and second mobile device rules and their remedial actions, while a user 115 who is a board member of a corporate enterprise may include a first mobile device rule and remedial actions but Excludes second mobile device rules and remedial actions. Many other examples are possible and in accordance with the principles and advantages described herein.

The mobile device manager 202 is preferably responsible for sending the appropriate rules package to the mobile device 120 based on, for example, the characteristics 208 of the mobile device and/or the role 206 assigned to the user 115 of the mobile device. In some implementations, deployment rules are associated with each rule package or individual mobile device rules 214 and associated remedial actions 216 . The mobile device manager 202 may be configured to use deployment rules to determine which mobile devices 120 send rule packages or individual mobile device rules 214 and associated remedial actions 216 . Deploying rules may enable mobile device manager 202 to access mobile device information 204 to identify mobile devices 120 whose assigned users 115 have roles 206 associated with a given rules package or rule in a rule package or rules, and/or mobile Device 120 - whose properties 208 are associated with a given rule package or rule. Additionally, mobile device manager 202 may be configured to send a given rules package (including mobile device rules 214 and/or remedial actions 216 ) to identified mobile devices 120 . In this manner, the mobile device manager 202 can send the appropriate mobile device rules package to each mobile device 120 .

For example, assume a new mobile device user 115 (eg, a new employee) joins an enterprise. The new user's role information 206 and/or mobile device characteristics 208 may be entered into the enterprise's mobile device information 204 (by an administrator and/or through an automated computer process). In one embodiment, the user's role information 206 is entered into the enterprise's RBAC system, and a software module (eg, mobile device manager 202 ) communicates the role information 206 to the mobile device information 204 . In another embodiment, the user role information 206 of the mobile device information 204 directly supports the RBAC role repository of the RBAC system. The mobile device manager 202 can be configured to use the new user's persona information 206 and/or mobile device characteristics 208 to determine an appropriate mobile device rules package to send to the new user's mobile device 120 . In another embodiment, the mobile device information 204 is not from or does not support an RBAC system.

In another example, assume that an enterprise modifies its policy regarding a particular group of mobile device users 115 . IT staff can modify mobile device rule packages customized for specific user groups. This may include creating new mobile device rules 214 of the rules package, deleting rules 214 from the rules package, and/or modifying some of the rules 214 of the rules package. Alternatively or in addition, modifying the mobile device rules package may include remedial action 216 of creating, deleting and/or modifying the rules package. The mobile device manager 202 can send the updated mobile device rules package to each mobile device 120 of that particular group of users 115 .

In many cases, the updated mobile device rules package may be quite similar to older mobile device rules packages that have been sent to the user's mobile device 120 . In such cases, the mobile device manager 202 may be configured to only apply new and/or modified mobile device rules 214 and/or remedial actions 216 along with those rules 214 and/or actions for deletion that have been deleted from the rules package 216 instructions are sent together to each mobile device 120 , such instructions being executed by the enterprise agent 320 of each mobile device 120 . In this manner, mobile device manager 202 may be configured to send rules package updates to mobile device 120 .

In some implementations, the enterprise agent 320 is configured to implement and/or enforce the mobile device rules 214 on the mobile device 120 . Accordingly, enterprise agent 320 is preferably configured to receive (e.g., via web interface 310) mobile device rules 214 and/or remedial actions 216 from mobile device management system 126 associated with the enterprise, and to 216 is stored in a computer-readable memory of the mobile device 120 such as the hard drive 306 or a memory card inserted into the memory card slot 307 . Enterprise agent 320 may be configured to receive and store the aforementioned mobile device rule packages and rule package updates from mobile device management system 126 and store them on hard drive 306 or a memory card. In the illustrated embodiment, the hard drive 306 stores a plurality of mobile device rules 214 and remedial actions 216 . In some implementations, the enterprise agent 320 is configured to separately store the rules package and/or the mobile device rules 214 and remedial actions 216 updated by the rules package. In other implementations, mobile device rules 214 and their corresponding remedial actions 216 are stored together in relation to each other. In some implementations, the mobile device 120 may receive the mobile device rules 214 and/or remedial actions 216 from sources other than the mobile device management system 126 .

9 is a high-level flow diagram illustrating an embodiment of a method in which mobile device 120 applies mobile device rules 214 to detect a security-related or productivity-related issue related to mobile device 120 and in which mobile device 120 processes the issue. According to the method shown in FIG. 9 , at step 902 , the enterprise agent 320 obtains or receives status metric data values associated with the mobile device 120 . These status metric data values are preferably used for status metrics expressed in one or more mobile device rules 214 . Enterprise agent 320 may be configured to obtain or receive one or more status metric data from other hardware, software, or firmware components of other mobile devices 120 . Enterprise agent 320 may be configured to actively collect data values for certain state metrics, for example, by issuing API calls to the data. For other status metrics or operating systems, the agent 320 may subscribe to the notification callback mechanism of the mobile device 120 so that the mobile device 120 notifies the enterprise agent 320 about certain events that occur on the mobile device 120 .

With continued reference to FIG. 9 , in step 904 , enterprise agent 320 detects one or more issues specified by mobile device rules 214 . Enterprise agent 320 is preferably configured to programmatically detect instances of problems at least in part by analyzing received status metric data values using mobile device rules 214 . In some implementations, received status metric data may be analyzed in conjunction with other data values (eg, user characteristics, time of day, date, etc.). Additionally, enterprise agent 320 may be configured to respond to a detected instance of one of the problems by performing remedial action 216 on mobile device 120 in step 906, wherein the remedial action 216 performed corresponds to the detected instance in step 904. The problem. In some cases, there may be multiple remedial actions 216 corresponding to a particular problem, and enterprise agent 320 may be configured to perform remedial actions based on various factors such as the probability of successfully addressing the problem (e.g., based on past results of running remedial actions), and Action-related computational costs, user preferences, business preferences, etc. are selected among available remedial actions. In some instances, enterprise agent 320 may perform two or more remedial actions 216 in response to detecting a particular problem.

Some remedial actions 216 may include generating an alert, such as a message distributed to the user 115 of the mobile device 120 . Messages may include text, images, audio and/or video. Enterprise agent 320 may be configured to generate and communicate the message to user 115 via user interface 304 , such as displaying the message on screen 326 and/or playing the message audibly using speaker 328 . The message may include information about the detected problem and/or instructions for the user 115 to perform an action on the mobile device 120 , such as activating or deactivating a feature of the device 120 . The message may be statically specified in remedial action 216 . Optionally, when e.g. evaluating mobile device rules 214 (e.g., by resolution of queries), messages can be specified using variables that can be tied to actual data values, as taught in Qureshi '536. This may allow the enterprise agent 320 to tailor messages to the particular circumstances of the device 120 . Furthermore, any remedial action 216 instructing agent 320 to generate such a message may further include instructions for actions to be taken by enterprise agent 320 if user 115 (or others manipulating mobile device 120 ) does not perform the action indicated by the message. For example, remedial action 216 may cause business agent 320 to take the action if user 115 does not perform the indicated action within the time period specified in remedial action.

The enterprise may vary the punitive nature of the remedial action 216 to apply to the detected issue or violation of the mobile device rules 214 based on the characteristics of the mobile device 120 and/or its user 115 . For example, it may be desirable to change remediation based on the role 206 of the user 115 . In one example, a business may wish to apply less stringent remedial actions to more senior executives of the business.

As mentioned above, some of the remedial actions 216 may include actions performed by the enterprise agent 320 on the mobile device 120 (other than generating and communicating the message to the user). In some implementations, remedial action 216 may include actions that mobile device 120 has been designed to take, such as activating or deactivating certain mobile device features, adjusting device settings, and the like. In such cases, enterprise agent 320 may be configured to use the mobile device's API to take such remedial action 216 .

In some implementations, the enterprise agent 320 includes a scripting engine 322 and the at least one remedial action 216 includes a script that the scripting engine 322 is configured to execute on the mobile device 120 . Scripts may be written in a scripting language associated with mobile device 120, which may be a set of commands targeted at controlling the device's hardware, software, and/or operating system. Script engine 322 may be configured to interpret scripts and/or convert scripts into bytecode or other forms that can be interpreted relatively quickly. In some cases, mobile device management system 126 (or another component of enterprise system 110 ) may include one or more scripting tools or applications 220 that assist IT staff in creating scripts.

In some implementations, the script may have the following high-level format:

#USE CASE:[description of what the script does]

import android

import zenlib

[decryption & authentication]

[rule body]

In this example, the script imports a library of code associated with the Android ^™ operating system ("android") and a library of compiled code ("zenlib") that interprets rule bodies and decryption and authentication information. For example, the "zenlib" code can be configured to interpret logical, mathematical and/or Boolean operators such as "AND", "OR", "THEN", "LESS THAN", "MORE THAN", etc.

From the various use cases described below, it will be appreciated that it is possible to provide many different types of mobile device rules 214 that enable enterprise agent 320 to detect and prevent various types of problematic events related to mobile devices 120 . It is also possible to provide many different types of corresponding remedial actions 216, which cause the agent 320 to perform various types of actions such as restricting network communications, implementing password protection, sending reports back to the enterprise system 110 (such as data stored on the mobile device 120) content, data usage on device 120, applications 318 running on mobile device 120, and many other types of information), deleting data from device 120, uninstalling applications 318 from mobile device 120, and many other actions to respond to such React to problematic events.

The use of mobile device rules 214 , remedial actions 216 , and/or scripts run by script engine 322 may be used to conduct compliance audits of mobile devices 120 . In certain implementations, the enterprise system 110 may be configured to cause the enterprise agent 320 for all or only some of the mobile devices 120 registered with the mobile device manager 202 to run one or more mobile device rules 214 at the enterprise's request.

For example, suppose an enterprise learns of a new computer virus to which the enterprise's mobile device 120 may be particularly vulnerable. In such a case, the enterprise's IT staff can cause the mobile device manager 202 to send instructions to the enterprise agent 320, such as to run a scan for new viruses or simply determine whether the mobile device 120 is updated with the latest antivirus software. Mobile Device Rule 214.

In some cases, an enterprise's IT staff can cause mobile device manager 202 to send one or more "special" mobile device rules 214 to mobile device 120 . In some instances, special mobile device rules 214 may be sent along with instructions for enterprise agent 320 to immediately determine whether mobile device 120 complies with these rules. Furthermore, special mobile device rules 214 may be sent along with related remedial actions 216 , and it will be understood that different types of these special mobile device rules 214 and remedial actions 216 may be sent to different types of mobile devices 120 . The mobile device manager 202 can send special mobile device rules 214 to all mobile devices 120 to which the assigned user 115 has a specific role 206 . These special mobile device rules 214 may or may not be the same as the mobile device rules 214 and remedial actions 216 provided within the custom rules package described above.

Upon receipt of such special mobile device rules 214 and possible special remedial actions 216 or upon receipt of an instruction to execute mobile device rules 214 already stored on mobile device 120, the mobile device's enterprise agent 320 may be configured to Whether device 120 complies with rule 214 . If the mobile device 120 is not compliant, the enterprise agent 320 can be configured to simply implement the special remedial action 216 .

Alternatively or in addition, the agent 320 may be configured to send a compliance report detailing the results of running the particular mobile device rule 214 (e.g., a report detailing compliance or non-compliance with the rule and/or the degree of compliance) to the mobile device management device 202. Mobile device manager 202 can be configured to use these reports for various purposes. For example, the mobile device manager 202 can send (1) an instruction for the agent 320 to run one or more additional mobile device rules 214 to only those mobile devices 120 that do not comply with the enforced mobile device rules and if the mobile device 120 non-compliance with additional mobile device rules 214 then one or more additional remedial actions or (2) additional specific mobile device rules 214 and/or feature remedial actions 216 to respond to the report. These additional mobile device rules 214 may check for other forms of non-compliance based on the assumption that a mobile device 120 that is not compliant with one mobile device rule 214 is more likely to be non-compliant with other mobile device rules 214 .

Example use case for a management system present on a device

There are many possible "use cases" for which an enterprise may wish to employ mobile device rules 214 and associated remedial actions 216 on mobile devices 120 . An example of such a use case is now described. It will be appreciated that the following examples are not exhaustive and that many different types of mobile device rules 214 and associated remedial actions 216 can be used for many different purposes. Furthermore, the skilled artisan will understand that the remedial actions described below for a particular use case may alternatively be performed on any other mobile device rule, problem, or use case, as an enterprise may desire. Some of the use cases described below contain one or more sub-cases also described below. Finally, some of these use cases overlap in some ways.

Use Case 1 : One possible use case involves a situation where a mobile device 120 is lost or stolen from its assigned user 115 (FIG. 1A). Mobile device rules 214 may specify conditions for concluding that a device is lost or stolen. Mobile device rules 214 may specify that mobile device 120 is lost or stolen. Related remedial action 216 may cause enterprise agent 320 to remove data and/or software application 318 from mobile device 120 , such as enterprise-related application, all applications, enterprise-related data, or all data. An optional remedial action 216 may have the agent 320 lock the device 120 so that it becomes unusable. These remedies are useful because mobile devices 120 may contain valuable and/or confidential enterprise-related data that is desired to be kept private from those not associated with the enterprise. In some implementations, enterprise system 110 may then issue a command to device 120 to delete the data and/or destroy the encryption keys used to decrypt the data. This command may be sent by the mobile device management system to the mobile device 120 over the wireless carrier network 125 .

Use Case 2 : This use case is related to use case 1. A thief can securely store a similar or equivalent card, such as a Service Subscriber Key (IMSI) used to identify the user on the mobile device 120, by removing the device's SIM card (or depending on the mobile device 120) from the SIM card port 312 )—this may actually disable the connection of the mobile device 120 to the carrier network 125—to prevent wireless commands sent from the enterprise system 110 from reaching the mobile device 120. In such instances, an enterprise may be prevented from deleting data from device 120, and a thief may be able to access the data. This problem can be handled by providing mobile device rules 214 that the enterprise agent 320 uses to detect the detachment of the SIM card from the SEM card port 312 of the device 120 . In this use case, agent 320 may perform remedial action 216 including generating a message distributed via user interface 304 instructing a person using device 120 (eg, user 115 or a thief) to re-engage the SIM card with SIM card port 312 . For example, the message may instruct the person to re-engage the SIM card with the SIM card port 312 within a specified period of time (eg, five minutes), otherwise all data (or just enterprise-related data) on the mobile device 120 will be deleted. In that case, the agent 320 may be further configured to delete the data if the SIM card is not re-engaged within a specified period of time. Alternatively or additionally, encryption keys used to decrypt enterprise data may be invalidated or deleted as a remedial action related to issues related to SIM disengagement.

Use Case 3 : The enterprise agent 320 may use the mobile device rules 214 to detect issues specified to disable password protection on the mobile device 120 . A corresponding remedial action 216 may cause agent 320 to generate a message on user interface 304 instructing user 115 to activate password protection on device 120 (perhaps within a specified period of time). Remedial action 216 may also include instructions to agent 320 where password protection is not activated, such as disabling mobile device 120, deleting enterprise-related data from device 120, decommissioning device 120 (e.g., revoking its certificate and/or terminating its access to mobile device manager 202 registration), etc. It will be appreciated that deleting data from mobile device 120 (in the context of this use case or any other) may include permanently deleting data, or alternatively just deleting a pointer to the data or deleting and/or invalidating a data decryption key. In a related example, mobile device rules 214 may require user 115 to change the password periodically, eg, every 90 days.

Use case 4 : The enterprise agent 320 can use the mobile device rules 214 to detect issues specified as the mobile device 120 being outside an authorized geographic area or the device being located within an unauthorized geographic area. Geographical regions can be specified in various ways, such as by entering a location (eg, on a map or longitude/latitude values), the shape and size of the geographic region, and the positional relationship between the entered location and the shape of the region. For example, a circular area centered on the entered location can be specified by specifying the radius of the geographic circle. Mobile device rules 214 may also include a time frame (hours, days, etc.) within which the restriction applies. Agent 320 may use GPS chip 316 to detect the location of device 120 .

A corresponding remedial action 216 may cause agent 320 to generate a message distributed via user interface 304 instructing user 115 to return device 120 to an authorized geographic zone or to leave an unauthorized zone, eg, within a specified time period. Remedial action 216 may also include instructions to agent 320 if device 120 moves as indicated, such as disabling mobile device 120, disabling features or software applications of device 120 (e.g., camera, Bluetooth connection, Wi-Fi connection, etc.) , delete enterprise-related data from the device 120, and the like. Remedial action 216 may simply send a message (eg, SMS text, email) to the appropriate authorities of the enterprise, alerting them of the location of the mobile device.

Use Case 5 : As described above in Use Case 4, the mobile device rules 214 can effectively cause the mobile device 120 to Activation or deactivation of a feature. The mobile device features in question may be user interface 304 (keyboard, touch screen, etc.), network interface 310, camera 314, microphone 330, USB connection, and the like.

Take the video camera 314 as an example. The enterprise agent 320 may use the mobile device rules 214 to detect issues where the mobile device 120 is specified to be on the premises of the enterprise, and the camera 314 may be used. An enterprise may wish to prevent the use of the camera 314 when the mobile device 120 is on the enterprise premises to prevent the camera from capturing any sensitive or confidential information, images or video from within the premises. As used herein, "business premises" may include any building, facility, factory, campus, design house, or other structure or area owned, used, or operated by a business. In one embodiment, a remedial action 216 corresponding to this problem may cause the agent 320 to deactivate or deactivate the camera 314 without the user's consent. In another embodiment, remedial action 216 corresponding to this problem may cause agent 320 to generate a message distributed via user interface 304 instructing user 115 to deactivate or deactivate camera 314 (perhaps within a specified period of time). The remedial action 216 may also include instructions to the agent 320 if the user 115 does not deactivate or deactivate the camera 314, such as to deactivate or deactivate the camera 314 without the user's consent. Preferably, after remedial action 216 is performed (and camera 314 is disabled), agent 320 is configured to detect when mobile device 120 leaves the enterprise premises. At that time, the agent 320 may be configured to reactivate the camera 314 without the user's consent, or generate a message distributed via the user interface 304 informing the user 115 that the user is authorized to reactivate the camera 314 .

Use Case 6 : Related to Use Case 5, another example of a mobile device "feature" that may be adjusted based on the location of the mobile device is a software application 318, such as the device's web browser. For example, the enterprise agent 320 may use the mobile device rules 214 to detect issues that specify that the mobile device 120 is on the premises of the enterprise, the device's web browser may be used. A corresponding remedial action 216 may have the agent 320 instruct the user to disable the web browser (by generating a message on the user interface 304), or simply disable the web browser without the user's consent. Then, when the mobile device 120 subsequently leaves the corporate premises, the proxy 320 can be configured to detect this and notify the user that the web browser can be used or simply re-enable the web browser without the user's knowledge or consent. It will be appreciated that other software applications 318 besides web browsers may also be similarly adjusted.

Use Case 7 : Related to Use Cases 4 and 5, upon detection of mobile device 120 entering a defined geographic area (e.g., corporate premises), enterprise agent 320 may be configured to perform remedial action 216, which causes agent 320 to require user 115 to enter a password into device 120 to use certain device features, such as camera 314 and/or a web browser. Such remedial action may be more appropriate for user 115 whose role 206 requires the user to access such features within a geographic area. Once the mobile device 120 leaves the prescribed area, the agent 320 can be configured to no longer require the user's 115 password to use such mobile device features.

Use case 8 : Mobile device rules 214 may enable enterprise agent 320 to disable certain mobile device features (e.g., camera, microphone) based on temporal information (possibly without regard to geographic data) such as time of day, day of week, calendar date range, etc. .

Use Case 9 : The mobile device 120 may include a credit card scanner for use in a store or other retail establishment. When the scanner's agent 320 detects that the scanner has physically left the store, the agent may perform a remedial action 216 that instructs the scanner's user 115 to return the scanner to the store within a specified time period. Remedial action 216 may also include instructions to delete the scanned credit card data from the scanner if the scanner is not returned to the store.

Use Case 10 : Another mobile device feature that can be adjusted is the network connectivity capabilities of the device, such as the network interface 310 . Enterprise agent 320 may use mobile device rules 214 to detect issues defined as mobile devices using network connectivity capabilities to connect or attempt to connect to insecure or blacklisted communication networks (e.g., rogue Wi-Fi base stations) . For example, user 115 may attempt to connect to an unsecured Wi-Fi network or a blacklisted cellular service tower, which may expose mobile device 120 to security threats. Remedial action 216 may prevent device 120 from accessing the restricted network.

In another embodiment, the remedial action 216 corresponding to this issue may cause the proxy 320 to terminate or prevent the mobile device's connection to the unsecured network without the user's consent. In another embodiment, the remedial action 216 may cause the proxy 320 to deactivate the mobile device's network connectivity capabilities (eg, by shutting down the network interface 310 ) without the user's consent. Such action may keep one type of network communication capability available (eg, a cellular network, such as a 3G or 4G network), while only terminating network communication capabilities (eg, Wi-Fi) associated to unsecured networks. In another embodiment, remedial action 216 may cause agent 320 to generate an audio warning to user 115 or a message distributed via user interface 304 indicating that user 115 of device 120 (perhaps within a specified period of time) terminated to an unsafe network connection. In yet another embodiment, remedial action 216 may cause agent 320 to generate a message distributed via user interface 304 instructing user 115 of device 120 to deactivate the device's network connectivity capabilities (perhaps within a specified period of time). In embodiments where the proxy 320 generates messages distributed via the user interface 304, the remedial action 216 may also include instructions to the proxy 320 without the user 115 terminating the connection or deactivating the network connection capability, such as without the user's consent. Take one of these actions. In yet other implementations, the remedial action 216 may cause the agent 320 to lock the mobile device 120 to render it unstable, perhaps until the device is disconnected from the unsecured or blacklisted communication network.

Use Case 11 : An enterprise may wish to regulate which software applications 318 are authorized to be installed on a mobile device 120 . For example, certain types of software applications 318 may negatively impact a user's productivity (e.g., by distracting the user from his or her duties), while other applications 318 may create security threats (e.g., may allow other devices to 120; or a rogue app that has malware or is determined to collect device data and send the data to a rogue server). The enterprise agent 320 can use the mobile device rules 214 to detect that the mobile device 120 is specified to have installed software applications 318 that the enterprise blacklists (i.e., is prohibited from installing) or at least is not whitelisted (explicitly allowed to install). The problem. Agent 320 may be configured to use device-specific APIs to determine which applications are installed on mobile device 120 .

Because different mobile device platforms vary with respect to the ability of enterprise system 110 to uninstall unauthorized applications 318 without the user's consent, several different remedial actions 216 are possible. In one embodiment, the corresponding remedial action 216 may cause the agent 320 to generate a message on the user interface 304 instructing the user 115 to uninstall the unauthorized software application 318 from the mobile device 120 (perhaps within a specified period of time). The remedial action 216 may also include instructions to the agent 320 if the user 115 does not uninstall the unauthorized application 318, such as disabling the mobile device 120, uninstalling the unauthorized application 318 (e.g., by causing the script engine 322 to run a script or program that uninstalls the application) , prevent unauthorized application 318 from launching or running (e.g., by causing script engine 322 to run a script that terminates one or more processes associated with unauthorized application 318), delete enterprise-related data from device 120 (this may also be performed by a script that runs an appropriate script engine 322), sending a warning message (SMS text, email, etc.) about the installation of the blacklisted application to an enterprise management agency, etc. In another implementation, the corresponding remedial action 216 may cause the agent 320 to uninstall the unauthorized application 318 from the mobile device 120 without the user's consent. For mobile device platforms that do not allow enterprise systems 110 to uninstall unauthorized applications 318 from mobile devices 120 without the consent of the user, the enterprise may choose to have agent 320 use scripting engine 322 to run one or Script for multiple processes, thus preventing it from running on mobile devices.

The enterprise may vary the punitive nature of the remedial action based on the role 206 assigned to the user 115 of the mobile device 120 running the unauthorized software application 318 . For example, consider a corporate enterprise that has some users 115 with roles 206 corresponding to senior executives, other users 115 with roles 206 corresponding to mid-level managers, and others with roles 206 corresponding to junior employees. For senior executives (whose mobile device 120 has the unauthorized application 318 ), the agent 320 can implement a remedial action 216 that simply instructs the user 115 to uninstall the application 318 . For mid-level administrators (whose mobile device 120 has an unauthorized application 318), the agent 320 can implement remedial action 216 that causes the scripting engine 322 to terminate one or more processes associated with the unauthorized application 318, thereby preventing it from running on the mobile device 120. run. Also, agent 320 may only run such scripts under certain conditions, such as when the mobile device is on business premises during normal business hours. Finally, for low-level employees (whose mobile devices 120 have unauthorized applications 318), the agent 320 can implement remedial action 216 of uninstalling the application 318 without the user's consent. The skilled artisan will recognize that an enterprise may vary its remedial actions in many different ways based on different sets of criteria, and that this is but one example.

The enterprise may allow certain software applications 318 to be installed on the mobile device 120 , but only under certain conditions, such as those related to the user role 206 and/or mobile device characteristics 208 . An enterprise may allow users 115 with certain roles 206 to install such applications on their devices 120, while prohibiting other users 115 from doing so. An enterprise may allow certain software applications 318 to be installed on mobile devices 120 of certain types, while disallowing these software applications 318 for different device types. The prohibition of installation of specific software applications 318 on mobile devices 120 can be regulated in a very flexible and customizable manner by specifying appropriate mobile device rules 214 .

Use Case 12 : Related to Use Case 11, mobile device rules 214 may specify a problem as an attempt to run (as opposed to install) a software application 318 in violation of the specified restrictions. Such restrictions may be temporal (applications are allowed to run only during certain times and/or days), geographic (applications are only allowed to run when mobile device 120 is in one or more specified geographic regions), passwords Dependent (the application is allowed to run only if the user provides the correct password associated with the application), other types of restrictions or conditions, or a combination thereof.

In one embodiment, the rules 214 include a list of applications 318 that are restricted or blacklisted and a list of applications 318 that may not even be restricted or whitelisted. Enterprise agent 320 may use application monitor service 334 (which may be part of agent 320 itself or, alternatively, another part of mobile device 120, as shown) to detect which applications 318 or processes are running. For example, the Android ^™ operating system provides mechanisms for collecting and viewing system output, whereby logs from various applications and parts of the system are collected in a series of circular buffers and can then be viewed through the "logcat" command and filter. The "logcat" command can be used from the ADB (Android Debug Bridge) shell to read log messages. Alternatively, Android's Dalvik Debug Monitor Server (DDMS) can automatically report "logcat" information via a connection to ADB. Thus, in a mobile device 120 running the Android ^™ operating system, the enterprise agent 320 can be configured to "listen" to certain "logcat" messages and detect calls of mobile device applications of interest. It will be appreciated that other mobile device operating systems provide alternative systems and methods for detecting invocations of mobile device applications.

When the agent 320 determines that the application 318 is invoked, the agent 320 determines whether the application is blacklisted (or whitelisted). If the application 318 is whitelisted or at least not blacklisted, the agent 320 allows the application to run. If the application 318 is blacklisted (or, perhaps more strictly, not whitelisted), the agent 320 can use the rules 214 to determine the prescribed restrictions for the application and whether the restrictions apply. For example, if the restriction is temporal, agent 320 may determine whether allowing the application to currently run violates the temporal restriction. If the restriction is geographic, agent 320 may determine whether device 120 is in the restricted geographic region. If the restriction is password related, agent 320 may invoke a password entry activity that prompts user 115 for the password associated with application 318 (which may be part of remedial action 216). If any restriction is violated (e.g. unauthorized time or day, device 120 outside authorized geographic area, incorrect password provided, other restrictions, combination of these restrictions, etc., as specified in rule 214), the agent 230 may prevent application 318 from running by, for example, script engine 322 running a script that terminates the application.

In some implementations, the agent 320 is configured to terminate the running application 318 if the usage restriction is violated after the application 318 is invoked. In other words, agent 320 may be configured to end application 318 if the usage condition is met at the time of invocation of application 318 but then subsequently violated during use of application 318 . For example, assume that applicable mobile device rules 318 allow application 318 to be used only during a specified time window and that application 318 is only invoked during the allowed time window but then remains in use when the time window expires. In this case, rules 318 may instruct agent 320 to terminate application 318 . In another example, assume that mobile device rules 318 allow application 318 to be used only when mobile device 120 is within a specified geographic area, and application 318 is invoked when this condition is met. Assume further that user 115 takes device 120 outside of the specified geographic area during use of application 318 . In such a case, the rules 318 may direct the agent 320 to terminate the application 318 whenever the device 120 leaves the specified geographic area.

Use Case 13: Mobile Device Rules 214 may also specify a problem to remove a required software application 318 from the mobile device 120 . A user 115 may uninstall an application accidentally or intentionally. A related remedial action 216 may cause the enterprise agent 320 to notify the user 115 of the removal of the application 318 and that its reinstallation is required.

Use Case 14 : Related to Use Case 13, the mobile device rules 214 can also be used by the enterprise agent 320 to detect when a required software application 318 is installed but not running on the mobile device 120. A related remedial action 216 may cause the enterprise agent 320 to notify the user 115 and instruct the user to run the required application.

Use Case 15 : The enterprise agent 320 can use the mobile device rules 214 to detect issues where the mobile device 120 is specified to store enterprise-related data, which the device is not authorized to store. In one embodiment, a corresponding remedial action 216 may cause agent 320 to generate a message on user interface 304 instructing user 115 to delete unauthorized enterprise-related data from mobile device 120 (perhaps within a specified period of time). The remedial action 216 may also include instructions to the agent 320 if the user did not delete the data, such as deleting data from the device 120 without the user's consent, disabling the device 120, and the like. In another embodiment, the corresponding remedial action 216 may cause the agent 320 to delete the enterprise-related data from the mobile device 120 without the user's consent.

Use case 16 : Mobile device rules 214 can be used by enterprise agent 320 to detect when mobile device 120 is in a roaming network, and related remedial action 216 can cause agent 320 to alert user 115 of it. Remedial action 216 may also have agent 320 connect device 120 to an available Wi-Fi network while the device is roaming.

Use Case 17 : The remedial action 216 may cause the agent 320 to start recording the location of the mobile device during a certain period of time, eg, when the device 120 is roaming. Agent 320 may report this information back to enterprise system 110 .

Use Case 18 : Mobile Device Rules 214 may enable Enterprise Agent 320 to activate or formulate applicable new Mobile Device Rules 214 if Mobile Device 120 operates for a certain period of time (e.g. hours or days) without being connected to the Enterprise System 110.

Use Case 19 : Mobile Device Rules 214 may cause Enterprise Agent 320 to switch Mobile Device 120 from its airplane mode if Wi-Fi or other network becomes available to the device.

Use Case 20 : If the mobile device 120 uses a VPN, the mobile device rules 214 can cause the enterprise proxy 320 to disable connections to network hotspots.

Use Case 21 : Related to Use Case 11, Mobile Device Rules ²¹⁴ may enable Enterprise Agent ³²⁰ to detect when User 115 or Mobile ^Device 120 ^attempts to send Sensitive or confidential corporate data. Related remedial action 216 may cause agent 320 to terminate software application 318, uninstall it, or other action to prevent data transfer.

Use Case 22 : Related to Use Case 21, mobile device rules 214 may enable enterprise agent 320 to detect when user 115 or mobile device 120 connects to enterprise resource 130 and accesses sensitive or confidential data. In some cases, remedial action 216 may cause agent 320 to prevent device 120 from downloading, copying, and/or sending data to anyone else.

Use case 23 : Mobile device rules 214 may enable enterprise agent 320 to detect when the number of SMS messages in a mobile device inbox exceeds a prescribed number, and related remedial action 216 may enable agent 320 to alert IT administrators.

Use Case 24 : The mobile device rules 214 may enable the enterprise agent 320 to monitor the mobile device's message inbox and detect incoming SMS messages from blacklisted members or messages containing confidential or sensitive enterprise information. A related remedial action 216 may have the agent 320 alert the IT administrator, disable the device 120, delete sensitive messages, disable the device's messaging capabilities, and the like.

Use Case 25 : Related to Use Case 24, the Mobile Device Rules 214 can enable the Enterprise Agent 320 to monitor the mobile device's outgoing message queue and detect outgoing SMS messages addressed to blacklisted phone numbers or containing confidential or sensitive enterprise information news. A related remedial action 216 may have the agent 320 alert the IT administrator, disable the device 120, delete sensitive messages, disable the device's messaging capabilities, and the like.

Use case 26 : The mobile device rules 214 can be used by the enterprise agent 320 to detect when a new or unauthorized SIM card is inserted into the mobile device 120 . Remedial action 216 may cause agent 320 to send a message to the corporate authority for the new SIM card, instructing user 115 to remove the SIM card, and so on.

Use case 27 : Mobile device rules 214 may be used by enterprise agent 320 to detect patterns or signatures of suspicious behavior by users 115 of mobile devices 120 . For example, rules 214 may specify certain logical combinations involving user behavior, such as frequenting blacklisted or suspicious websites, use of blacklisted or suspicious IP addresses, and/or being logged into The installation or operation of applications on mobile devices that are blacklisted. If agent 320 determines that user 115's actions violated rules 214, agent 320 may implement remedial action 216, such as preventing user 115 from logging into enterprise system 110, deleting all enterprise data from device 120, etc.

Some mobile device operating systems do not allow applications (eg, enterprise agent 320 ) to see what other applications are doing on device 120 . This is sometimes referred to as "sandboxing" of applications on device 120 . Preferably, the mobile device's application, the use of which is required to address the mobile device rules 214 that dictate patterns of suspicious behavior by the user, is programmed to log these behaviors into the secure document container 336 described more fully below. By doing so, agent 320 may be configured to read those suspicious behaviors by accessing container 336 .

Use case 28 : The enterprise agent 320 can use the mobile device rules 214 to detect issues specified as mobile devices receiving unauthorized or suspicious network connections. Typically, a mobile device 120 receives far fewer incoming network connections than it makes outgoing connections because the user 115 of the mobile device 120 connects more often (eg, when the user 115 browses a website, searches an online store, etc.). Thus, an incoming network connection may be due to an attempt by a third party to break into mobile device 120 for nefarious reasons, such as stealing corporate information, disabling device 120, and the like. Of course, there are instances when the incoming connection is authorized or benign, such as when mobile device 120 receives an email. However, email is typically received through a well-known port on device 120, which the agent can be configured to determine. Accordingly, enterprise agent 320 may be configured to react to incoming network connections by checking parameters of the connection, such as the connected mobile device port. If the check results in a determination that the incoming connection is authorized, the proxy 320 may be configured to allow the incoming connection. On the other hand, if the inspection results in a determination that the incoming connection is unauthorized or suspicious, agent 320 may be configured to perform a corresponding remedial action 216 of denying, preventing, or terminating the unauthorized or suspicious network connection. This functionality may be referred to as a "mobile firewall".

cloud-based enterprise

In some implementations, the enterprise system 110 is provided substantially or entirely within the cloud 156 . Any required mobile device management system 126 , secure mobile gateway 128 , and enterprise resources 130 are deployed substantially or entirely within cloud 156 in such cloud-based enterprise system 110 . A meta-app system can be deployed in the cloud 156 and/or within the mobile device 120 to help manage the device 120 . Such implementations may or may not include non-cloud enterprise systems or meta-application components deployed within non-cloud enterprise systems.

For example, an enterprise (e.g., a social networking enterprise) may provide mobile devices 120 (e.g., iPads ^™ ) to a group of people, the meta-application is deployed within the device 120, and the meta-application components and any required systems 126, gateways 128, and resources 130 Deployed within cloud 156 only. In certain implementations, the enterprise may use policies (eg, access policy 218 ) stored within the cloud 156 and/or device 120 to help manage or limit mobile device communications or access to cloud-based enterprise resources. Meta-applications can also be used to monitor/measure/remediate cloud or cloud-based services used by enterprises.

Enhanced communication experience between enterprise and mobile devices

For many carrier networks 125, there are typically geographic areas where wireless service is weak or unavailable. This can arise if, for example, a wireless carrier has relatively few or no cellular communication nodes or towers in such an area. Referring to FIG. 1A , the network connection 142 between the mobile device 120 and the carrier network 125 is often unreliable, especially when the mobile device 120 is located in such an area with weak or non-existent wireless service. Consequently, the network connections 142, 144 between the mobile device 120 and the enterprise system 110 are often unreliable.

From the perspective of mobile device 120 , the loss of network connection 142 may be inconvenient when user 115 enters data to be sent to enterprise resource 130 of enterprise system 110 . For example, the software application 318 may be configured to open a network connection 142 , 144 to the mobile device management system 126 or other network component, and to request data input from a user, typically via the user interface 304 of the mobile device 120 . For example, application 318 may be configured to provide one or more data fields on display 326 configured to receive user data as text input via keypad 324 . Application 318 may also be configured to send data to enterprise resource 130 once the data is received by user 115 . However, the application 318 may discard the data entered by the user 115 if the network connection 142 is lost before the data is sent to the mobile device management system 126 . For example, upon receiving a TCP socket error reporting a lost connection 142, the application 318 may drop data. Alternatively, the application 318 may attempt to send data to the mobile device management system 126 and wait for a reply. Because the connection 142 is lost, the application 318 will eventually time out when no reply is received during a certain period of time. In either case, the application 318 may discard the data provided by the user 115 without the data being sent to the mobile device management system 126 . Ultimately, this allows user 115 to re-enter data once connection 142 is restored.

From the perspective of enterprise resource 130 and tunnel intermediary 224 (or other tunnel intermediaries), a somewhat similar dynamic may arise. In particular, when the tunnel intermediary 224 attempts to send data to the mobile device 120 via the application tunnel, the mobile device's network connection 142 may become lost.

In some implementations, when an application tunnel is created between a software application 318 of a mobile device 120 and an enterprise resource 130 as described above, the device's enterprise proxy 320 and/or the enterprise's tunnel intermediary 224 (or other tunnel intermediaries) may Configured to enhance communication between mobile device 120 and enterprise resource 130 by caching data. For example, proxy 320 may cache data on mobile device 120 and tunnel broker 224 may cache data within mobile device management system 126 .

FIG. 10 is an embodiment illustrating a method in which mobile device 120 may cache data entered by user 115 in response to loss of network connection 142 to enterprise computer system 110 . The method is described in the context of FIG. 1A, but can also be used in other computing systems, such as any of the systems of FIGS. 1B-1E. The method begins in step 1002 where the software application 318 on the mobile device 120 prompts the user 115 for data input. At this point, an application tunnel may have been formed between application 318 and enterprise resource 130 via a tunnel intermediary. In step 1004 , the application 318 receives data, eg, via the user interface 304 of the mobile device 120 . In step 1006 , application 318 generates a request to send the received data to enterprise resource 130 of enterprise system 110 . In step 1008 , enterprise agent 320 receives or intercepts the application's request to send the received data to enterprise resource 120 . In decision step 1010 , proxy 320 determines the availability of network connections 142 , 144 between mobile device 120 and tunnel intermediary 224 . If the network connection 142, 144 is available, then in step 1012 the proxy 320 starts sending data via the connection 142, 144 to the tunnel intermediary. For example, proxy 320 may open a TCP socket to the tunnel intermediary server. If the agent is able to send all the data received from the user 115, the application 318 may take no further action regarding the data previously received from the user at step 1004. In some implementations, the method may return to step 1004 if the user 115 is still entering new data into the application 318 .

If the network connection 142, 144 is lost and unavailable, then in step 1016, the agent 320 may prevent the software application 318 from detecting the loss of the network connection 142, 144. For example, proxy 320 may prevent application 318 from detecting TCP socket errors caused by loss of connection 142 , 144 . Then in step 1018 the proxy 320 caches at least a portion (and preferably all) of the received data that has not yet been sent from the mobile device 120 to the tunnel intermediary 224 . Data may be cached in any suitable machine-readable memory device, such as random access memory 308 , hard drive 306 , flash memory, or a memory card that engages memory card port 307 of mobile device 120 . Then, in decision step 1020, the proxy 320 determines whether the network connection 142, 144 to the tunnel intermediary 224 is restored. The determination in decision step 1020 may involve the proxy 320 receiving a notification from a notification service to which the proxy subscribes. If the network connection 142 , 144 to the tunnel intermediary 224 is not restored, the method may wait for a period of time and then return to decision step 1020 . Once the network connection 142 , 144 is restored, the proxy 320 sends the cached data to the tunnel intermediary 224 via the restored network connection 142 , 144 .

In the illustrated embodiment, enterprise proxy 320 caches user-provided data (step 1018) only after proxy 320 determines that the connection to tunnel intermediary 224 has been lost (step 1010). In other implementations, the proxy 320 may be configured to cache user-supplied data prior to determining whether the connection to the tunneling broker 224 is lost or unavailable. For example, proxy 320 may cache data in response to receiving data from a user at step 1004 . In such implementations, the cached data may be erased after the data is sent to tunnel intermediary 224 .

It will be appreciated that the software application 318 may conduct the process of the user entering data in several successive stages, with the application 318 attempting to send the received data after each stage. If the network connection 142, 144 is lost before the final data entry stage and the application 318 receives additional data after the connection 142, 144 is lost, the enterprise proxy 320 may be configured to cache at least a portion (and preferably all) of the additional data ). In that case, the proxy 320 may respond to the restoration of the network connection 142 , 144 by sending the cached additional data to the tunnel intermediary via the restored network connection 142 , 144 .

As mentioned above, in step 1016, enterprise agent 320 may prevent software application 318 from detecting the loss of network connection 142,144. From the point of view of the software application 318, the connections 142, 144 are available under such circumstances. As far as application 318 is concerned, it has an IP address and a server port to use to communicate. In this way, when in fact the application 318 only communicates with the proxy 320 (when the connection 142, 144 is lost) or communicates with the tunnel intermediary 224 via the proxy 320 (when the connection 142, 144 is available), it can give Apply 318 the impression that it is communicating with enterprise resource 130 . When the connection 142, 144 is lost, the proxy 320 can give the application 318 the impression that the enterprise resource 130 is still in the process of reading and responding to the request, thereby preventing the application 318 from timing out.

The mobile device user's experience may be similar to that of application 318 . The user's experience depends on the application 318 . So if the proxy 320 keeps the application 318 unaware of the lost network connection 142, 144, the user can also remain unaware of it. This approach prevents the aforementioned problems of having to re-enter data into the application 318 when the connection 142, 144 is lost, for example.

In some cases, particularly when mobile device 120 is downloading large amounts of data from enterprise system 110 , it may be useful to respond to a lost network connection by buffering data packets within enterprise system 110 . 11 is an embodiment illustrating a method in which the enterprise computer system 110 buffers data to be sent to the mobile device 120 when the network connection 142, 144 to the mobile device 120 is lost. The method is described in the context of enterprise resource 130 sending data to mobile device 120 . Although the method is described in the context of FIG. 1A, it may be used in other computing systems, such as any of the systems of FIGS. 1B-1E. The method begins in step 1102, where an application tunnel is established between mobile device application 318 and enterprise resource 130, eg, via tunnel intermediary 224, as described above. For example, an application tunnel may be established in response to an access request generated on mobile device 120 by software application 318 . In step 1104 , tunnel intermediary 224 receives one or more data packets from enterprise resource 130 . In decision step 1106, tunnel broker 224 determines whether a network connection 142, 144 between tunnel broker 224 and mobile device 120 is available. If the network connection 142 , 144 is available, then in step 1108 the tunnel intermediary 224 sends the data packet to the mobile device 120 via the network connection 142 , 144 . On the other hand, if the network connection 142 , 144 is not available, then in step 1110 the tunnel intermediary 224 buffers the one or more received data packets in computer-readable memory, such as the memory of the mobile device management system 126 . In step 1110 , tunnel intermediary 224 may be configured to send one or more acknowledgments of receipt of data to enterprise resource 130 on behalf of mobile device 120 , if resource 130 expects such acknowledgments from device 120 . After either steps 1108 and 1110 , tunnel intermediary 224 determines in decision step 1112 whether tunnel intermediary 224 received additional data packets from enterprise resource 130 . If so, the method returns to decision step 1106 . If not, the method may end in step 1114 .

In the illustrated embodiment, tunnel intermediary 224 only caches data (step 1110 ) after intermediary 224 determines that the connection to mobile device 120 has been lost (step 1106 ). In other implementations, the tunnel intermediary 224 can be configured to cache data until it is determined that the connection to the mobile device 120 is lost or available. For example, tunnel intermediary 224 may cache data in response to receipt of data from enterprise resource 130 . In such implementations, the cached data may be wiped after the data is sent to the mobile device 120 .

As mentioned above, during the method shown in FIG. ) The impression that the network connection 142, 144 has not been lost. Similarly, a tunneling intermediary (eg, intermediary 224 ) may be configured to give enterprise resource 130 the impression that network connection 142 , 144 has not been lost, such as in accordance with the method shown in FIG. 11 .

In some implementations, a tunneling intermediary (eg, intermediary 224 ) and/or enterprise proxy 320 is configured to compress data tunneled through the application. The tunnel intermediary may be configured to compress data received from enterprise resource 130 (or another resource external to enterprise system 110 ) over resource network connection 152 and to send the compressed data to mobile device 120 over network connections 142 , 144 . Upon receiving compressed data, enterprise agent 320 may be configured to decompress the data before it is provided to software application 318, which is the intended recipient of the data. Therefore, application 318 need not be able to decompress the data.

Similarly, the mobile device's enterprise agent 320 may be configured to compress data intercepted or received from the software application 318 and send the compressed data over the network connection 142, 144 to the tunneling intermediary. When compressed data is received, the tunnel intermediary may be configured to decompress the data before the data is provided to enterprise resource 130 (or another resource external to enterprise system 110), which is the intended recipient of the data . Therefore, enterprise resource 130 need not be able to decompress the data.

This compression function may be useful when the mobile device 120 is sending or receiving large data files or when the mobile device 120 is in an area where the network connection 142, 144 has low bandwidth. In some embodiments, the data is compressed by about 20-95%. The degree of data compression may depend on the type of data, the available data bandwidth of network connections 142, 144, and 152, and other factors. Also, both the application 318 and the user 115 of the mobile device 120 may remain unaware of the compression and decompression of data.

In some implementations, the application tunnel can be used by the enterprise system 110 for error correction (eg, parity checking), retransmission of lost data packets, and the like. Tunnel broker 224 may be used for load balancing or thread safety/synchronization for thread-unsafe server applications.

"Remote Control" of Mobile Devices

In some embodiments, a "remote control" system and method may be provided to allow an enterprise's mobile device 120 to be controlled by one or more help desk operators at a computer located remotely relative to the mobile device 120 (the "controller computer"). , an administrator or others (collectively referred to herein as a "controller") to diagnose and control. Such systems and methods are now described.

With respect to FIGS. 2 and 12 , the mobile device management system 126 may be configured to facilitate a "remote control session" between the mobile device 120 and the controller computer 1200 on which the remote control module 1202 is installed. Controller computer 1200 is operated by a user referred to herein as controller 1204, and may be located within or outside of enterprise computer system 110 (FIG. 1A). In this context, tunnel intermediary 224 may facilitate the formation of an application tunnel between controller computer 1200 and enterprise agent 320 ( FIG. 3 ) of mobile device 120 .

Referring to FIG. 12 , the remote control module 1202 is preferably configured to initiate a network connection (eg, via the Internet) to a server associated with the tunnel broker 224 (eg, the server storing the tunnel definition 228 or a proxy server). In some embodiments, this connection is via an application tunnel, such as those described above. It will be appreciated that an enterprise may have multiple mobile device management systems 126 . Accordingly, remote control module 1202 may allow controller 1204 to specify one or more tunnel brokers 224 to connect to.

User 115 of mobile device 120 may be experiencing technical difficulties with the user of mobile device 120 and may wish to seek assistance from a help desk service. The help desk service may be operated exclusively by or for an enterprise, or alternatively for a plurality of enterprises. In some implementations, the user 115 may request a remote control session with the controller computer 1200 by contacting a help desk service (eg, by phone call, email, text message, etc.). In such an embodiment, the controller 1204 associated with the help desk service may then cause the remote control module 1202 of the controller computer 1200 to send a request for a remote control session between the controller computer 1200 and the mobile device 120 to the user mobile device 120 . In some implementations, the enterprise agent 320 of the mobile device 120 allows the user 115 to request or initiate a remote control session with the controller computer 1200 . In some implementations, a remote control session may be initiated by the controller 1204 without first being requested by the user 115 .

FIG. 13 is a flowchart illustrating an embodiment of a method in which the controller computer 1200 ( FIG. 12 ) participates in a remote control session with the mobile device 120 . The method begins when the remote control module 1202 connects to a server associated with the tunnel broker 224 (or another broker of a remote control session with the mobile device 120).

In step 1302, the remote control module 1202 provides the controller 1204 with identifications of one or more mobile devices 120 that are available for the remote control session. This may be done by the remote control module 1202 sending a request to the mobile device management system 126 for such identification and the mobile device manager 202 responds by looking up the information in the mobile device information 204 and sending the requested information to the controller computer 1200 to achieve. The provided identification may include, for example, the name or username of the user 115 assigned to the mobile device 120 . Devices 120 identified (eg, by mobile device manager 202 or remote control module 1202 ) may be filtered according to any criteria, such as criteria specified by controller 1204 to remote control module 1202 . For example, the remote control module 1202 may list only those mobile devices 120 currently connected to the enterprise system 110 or only those mobile devices 120 or users 115 that are members of a specified group of users. Additionally, the remote control module 1202 may be configured to allow the controller 1204 to search against registered mobile devices 120 , eg, to search for a particular device 120 or user 115 . In addition to identifying the user 115 of the mobile device 120 to the controller 1204, the remote control module 1202 may also be configured to provide additional information about the identified device 120, such as device model, operating system version, platform, and the like. Mobile device manager 202 may obtain such information, such as mobile device characteristics 208 , from mobile device information 204 .

Still referring to FIG. 13 , in step 1304 , the remote control module 1202 receives a selection of at least one of the mobile devices 120 and/or an instruction to initiate a remote control session with the selected device 120 from the controller 1204 . In step 1306 , the remote control module 1202 sends a request for a remote control session to the selected mobile device 120 . In embodiments where the remote control session is conducted via an application tunnel, the request may be sent to the tunnel broker 224 . In other implementations, the request is sent directly to the selected mobile device 120 . In step 1308 , the controller computer 1200 begins to repeatedly receive several batches of the most recently updated “user interface simulation data” from the mobile device 120 . In the context of an application tunnel, this data flows from the mobile device 120 to the controller computer 1200 via the tunnel intermediary 224 . User interface emulation data may include mobile device 120 enterprise agent 320 captured using any of a variety of device display "scraping" methods (also known as "screen scraping" and/or "screen buffer capture") data, as is generally known in the field of desktop computers. For example, in a desktop computer environment, one known protocol for providing a graphical interface to another computer is the Remote Desktop Protocol, RDP, developed by Microsoft ^™ .

With continued reference to FIG. 13 , in step 1310 , the remote control module 1202 simulates the current state of the user interface 304 of the mobile device 120 using the user interface simulation data. For example, FIG. 14 shows an embodiment of a screen display of a controller computer 1200 that includes a virtual user interface 1402 that emulates the user interface 304 of a mobile device 120 participating in a remote control session with the controller computer 1200 . Referring again to FIG. 13, steps 1308 and 1310 typically occur repeatedly and one after the other. Accordingly, a batch of user interface simulation data is received (step 1308) and then used by the remote control module 1202 to simulate the user interface 304 of the mobile device (step 1310), and then a new batch of user interface simulation data is received (step 1308) step 1308) and then used to simulate the user interface 304 (step 1310), and so on. In this manner, the remote control module 1202 keeps updating the simulated user interface to reflect the current state of the user interface 304 .

Preferably, the remote control module 1202 of the controller computer 1200 allows the controller 1204 to issue commands to the mobile device 120 . Such commands are referred to herein as "remote control commands". Accordingly, still referring to FIG. 13 , the remote control module 1202 may receive a remote control command from the controller 1204 in step 1312 . In some implementations, the controller 1204 may provide these commands via the simulated user interface 1402 . Remote control commands can be used to access resources installed on the mobile device 120 . In this context, mobile device resources may include operating system features and functions, software applications, mobile device hardware, data resources, files, and the like. Then in step 1314 the remote control module 1202 sends the remote control command to the mobile device 120 . At least some of the remote control commands may be commands that the user 115 would otherwise enter directly into the mobile device 120 . Mobile device 120 may react to such remote control commands as if they were received via user interface 304 of device 120 . These types of remote control commands will generally cause the user interface 304 of the mobile device 120 to change, which in turn will be reflected in a new batch of user interface simulation data received from the mobile device. Thus in step 1316, the remote control module 1202 receives updated user interface simulation data from the mobile device 120 reflecting the state of the device's user interface 304 after the device 120 has reacted to at least some of the remote control commands as if they were via the user interface 304 is received the same. Then in step 1318 the remote control module 1202 simulates the current state of the user interface 304 of the mobile device 120 using the updated user interface simulation data.

In some implementations, the remote control module 1202 can allow the controller 1204 to view information about the mobile device 120 . The controller's view of the information may be separate from the user interface 304 of the mobile device 120 . Thus in step 1320 the remote control module 1202 may receive a request from the controller 1204 for information about the mobile device 120 . In step 1322 , the remote control module 1202 can send a request for information to the mobile device 120 . The request may essentially automate the mobile device feature's API (eg, APIs of the task manager, file manager, registry editor, etc.) that returns the requested information. In step 1324 , remote control module 1202 may receive the requested information from mobile device 120 , preferably without displaying the information within simulated user interface 1402 . In step 1326 , remote control module 1202 may display the requested information on a display associated with controller computer 1200 , preferably at a location other than simulated user interface 1402 . Examples of mobile device information that may be requested in steps 1320 and 1322, received in step 1324, and displayed in step 1326 include system information for the mobile device, processes present on the mobile device, files, registry and other data of the mobile device.

For example, the screen display of FIG. 14 includes a system information display 1404 displayed alongside a simulated user interface 1402 . The system information display 1404 may provide, for example, the operating system version, platform, model, hardware serial number, CPU type, total storage capacity, memory in use, memory free, total RAM, RAM in use, free memory, etc. of the mobile device. Some or all of RAM, total memory card memory (eg, SD card) capacity, memory card memory in use, free memory card memory, AC power availability, remaining battery power, and/or device usage time available from remaining battery power . It will be appreciated that additional information may also be provided.

In another example, FIG. 15 illustrates an implementation of a screen display of a controller computer 1200 participating in a remote control session with a mobile device 120, wherein the screen display includes a task manager displaying application processes as they appear on the mobile device 120. display 1502 . The illustrated task manager display 1502 is shown next to the simulated user interface 1402 . The task manager display 1502 may display, for example, the name of the application associated with the process, the amount of RAM used by the process, the percentage of CPU power utilized by the process, the amount of CPU time consumed by the process, the number of threads associated with the process, and Some or all of the device paths. It will be appreciated that additional information related to such processes may also be provided. In some implementations, the controller 1204 may issue (to the remote control module 1202 ) remote control commands related to the task manager, such as terminating one or more processes on the mobile device 120 . For example, such remote control commands may be issued in response to selections made via the task manager display 1502 .

FIG. 16 shows an embodiment of a screen display of the controller computer 1200 participating in a remote control session with the mobile device 120, including for viewing files stored on the mobile device 120 (in any of the aforementioned memories), Interface 1602 for downloading files from mobile device 120 to controller computer 1200 and/or uploading files from controller computer 1200 or from a different networked computer to mobile device 120 . Commands issued by the controller 1204 to the remote control module 1202 to view files, download files and/or upload files may be sent to the mobile device 120 as remote control commands.

In another example, FIG. 17 illustrates an implementation of a screen display of a controller computer 1200 participating in a remote control session with a mobile device 120 that includes an interface 1702 for viewing and/or editing the registry of the mobile device 120 . The illustrated registry interface 1702 is shown next to the simulated user interface 1402 .

FIG. 18 shows a flowchart of an embodiment of a method of a mobile device 120 participating in a remote control session with a controller computer 1200 . The method shown in FIG. 18 may correspond to the method shown in FIG. 13 , except that the method of FIG. 18 is shown from the perspective of mobile device 120 . As described elsewhere herein, the mobile device 120 may include a user interface 304 configured to receive local commands from the user 115 of the mobile device 120 for accessing resources installed on the mobile device. Additionally, user interface 304 is generally configured to communicate information to user 115 , such as via a screen or display 326 .

The method begins in step 1802, where the enterprise agent 320 of the mobile device 120 receives a request from the controller computer 1200 to participate in a remote control session with the controller computer. In some implementations, proxy 320 may be configured to automatically accept such requests. In other embodiments, agent 320 is configured to obtain permission from user 115 to participate in the remote control session, eg, by prompting the user for an indication of permission. In the illustrated method, proxy 320 determines in decision step 1804 whether to accept the request. If the proxy 320 does not accept the request (eg, because the user 115 denies the request, or because the user 115 simply does not give permission within a predetermined period of time), the method may end in step 1806 .

On the other hand, if the enterprise proxy 320 accepts the request, the proxy 320 responds to the request by requesting or establishing an application tunnel connection with the controller computer 1200 and getting the user interface emulation data (described above) from the mobile device 120 in step 1808. out response. In step 1810 , agent 320 sends user interface simulation data to controller computer 1200 . The agent 320 may repeatedly send updated user interface simulation data, for example, at regular intervals or perhaps only when a change occurs to the user interface 304 of the mobile device.

Still referring to FIG. 18 , at step 1812 the agent 320 may receive a remote control command from the controller computer 1200 for accessing resources installed on the mobile device 120 . As mentioned above, such mobile device resources may include operating system features and functions, software applications, mobile device hardware, data resources, files, and the like. At least some of these remote control commands may be commands that user 115 could otherwise input directly into mobile device 120 via user interface 304 . Thus in step 1814 mobile device 120 reacts to at least some remote control commands as if they were received via user interface 304 . Step 1814 may involve the agent 320 transferring and/or providing the remote control commands in the device's natural language to the device's hardware and/or software in the same manner as the commands are received via the mobile device's user interface 304. will receive commands the same way. Because step 1814 may result in changes to the device's user interface 304 , agent 320 may be configured to then send updated user interface simulation data to controller computer 1200 .

In step 1816, the enterprise agent 320 of the mobile device 120 receives a request from the controller computer 1200 for information about the mobile device. For example, such information may include the information described above in steps 1320, 1322, 1324, and 1326 of FIG. 13 . In step 1818 , agent 320 sends the requested information to controller computer 1200 without displaying the information on user interface 304 of mobile device 120 .

Enterprise agent 320 of mobile device 120 may be configured to allow controller 1204 to perform actions on mobile device 120 while a remote control session is in progress with remote control module 1202 of controller computer 1200 . In some cases, these may include gestures that even the user 115 of the device 120 cannot perform (eg, if the remote control module 1202 has functionality beyond that of the software application 318 installed on the mobile device 120).

It will be appreciated that the remote control module 1202 can be configured to allow the controller 1204 to perform many other operations on the mobile device 120 during a remote control session. For example, remote control module 1202 may be configured to allow controller 1204 to shut down or restart mobile device 120 . In another example, remote control module 1202 may be configured to allow controller 1204 to install new software onto mobile device 120 . This may involve sending a software application installation file from the controller computer 1200 or another networked computer to the mobile device 120, and then installing the application. In another example, remote control module 1202 may be configured to allow controller 1204 to uninstall software application 318 from mobile device 120 . Many other operations are possible.

In some implementations, remote control module 1202 of controller computer 1200 and enterprise agent 320 of mobile device 120 are configured to enable controller 1204 and mobile device user 115 to communicate with each other using controller computer 1200 and mobile device 120 . For example, remote control module 1202 and enterprise agent 320 may be configured to enable a Voice over Internet Protocol (VOIP) session that allows controller 1204 and user 115 to speak audibly to each other. The mobile device 120 may use the speaker 328 of the mobile device 120 to audibly broadcast the controller's voice (via the microphone of the controller computer 1200 ) to the user 115 . Alternatively, the user 115 can listen to the controller's voice by connecting a pair of headphones to the headphone jack of the mobile device 120 . Similarly, the speaker of the controller computer 1200 may broadcast the user's voice (input at the microphone 330 of the mobile device 120 ) to the controller 1204 .

In another example, remote control module 1202 and enterprise agent 320 may be configured to enable a text chat session between controller 1204 and user 115 . 19A illustrates an embodiment of a screen display of controller computer 1200 participating in a remote control session with mobile device 120, which includes a chat session interface. In the illustrated embodiment, the remote control module 1202 creates a chat session area 1902 where the controller 1204 can enter a text message to be sent to the user 115 and where the user's text message is displayed to the controller 1204 . The illustrated chat session area 1902 is shown next to the simulated user interface 1402 . FIG. 19B illustrates an embodiment of the mobile device 120 emulated in FIG. 19A. Enterprise agent 320 is preferably configured to display on screen 326 of mobile device 120 substantially the same text communication displayed in chat session area 1902 of FIG. 19A .

In another example, remote control module 1202 and enterprise agent 320 may be configured to enable shared whiteboard communication between controller 1204 and user 115 . Figure 20 shows an embodiment of a screen display of a controller computer 1200 participating in a remote control session with a mobile device 120, which includes a shared whiteboard feature. In the illustrated embodiment, remote control module 1202 allows controller 1204 to superimpose image 2002 onto simulated user interface 1402 . Agent 320 of mobile device 120 may be configured to receive images 2002 and then superimpose them on screen 326 of mobile device 120 . Image 2002 may include, for example, text, graphics, and the like. In the screen display shown, the controller 1204 circles the icon on the simulated user interface 1402 and superimposes the words "click here" (click here).

In some implementations, remote control module 1202 is configured to allow controller 1204 to adjust the view of simulation user interface 1402 . For example, in various embodiments, the remote control module 1202 is configured to allow the controller 1204 to adjust the resolution, color matching, bits per pixel (BPP), zoom level, rotation orientation, etc. of the simulation interface. Additionally, the remote control module 1202 may be configured to allow the controller 1204 to adjust the “refresh rate” at which the mobile device's enterprise agent 320 sends updated user interface simulation data to the controller computer 1200 . Remote control module 1202 may also be configured to allow controller 1204 to specify whether data received from mobile device 120 is compressed by enterprise agent 320, and to specify the degree of compression.

In some implementations, the remote control module 1202 is configured to capture and save aspects of a remote control session. For example, the remote control module 1202 may be configured to allow the controller 1204 to capture images of the simulated user interface, print the images onto hardcopy printouts, record video of the remote control session, and the like. Remote control module 1202 may be configured to allow controller 1204 to edit captured images or video, and/or send captured media files to others via email or the like.

In some implementations, the remote control module 1202 may be configured to allow the controller 1204 to create macros for activating or executing certain features, settings, and/or software applications of the mobile device 120 .

Analysis on Secure Mobile Gateway

Referring again to FIG. 4 , the secure mobile gateway 128 may include a repository 410 of recorded data. Repository 410 may store data indicative of status information generated at mobile device 120 or by secure mobile gateway 128 . For example, logged data may include various information, such as data regarding the permission and denial of mobile device access requests through gateway filter 401 . Recorded data may alternatively or additionally include data recorded by and retrieved from the managed mobile device 120 . Such recorded data may include, for example, indications of documents downloaded to the mobile device 120, system status on the particular mobile device 120, programs launched on the particular mobile device 120, websites visited by the particular mobile device 120, or other Records of network resources, information related to email accounts of users copied on messages related to managed mobile devices 120 , data attached to emails or other messages received by mobile devices 120 , etc. The recorded data may include data obtained from the mobile device request 402 . For example, for a secure mobile gateway 128 that supports ActiveSync, logged data may include the DeviceId, DeviceType, User, and/or UserAgent from the ActiveSync request 402 and the ActiveSync command issued by the request. In the case of an access denial, the logged data may also include the provider 408 of the gateway rule 404 that was violated and information indicating the reason for the denial. If access is denied based on a violated enterprise access policy 218 of the mobile device management system 126 , the gateway 128 may determine which policy 218 was violated from the mobile device management system 126 and store it in the repository 410 of logged data. Logged data may also include mobile traffic data and/or other network information about the request 402, such as the IP address of the requesting mobile device 120. Logged data can be stored according to a logging standard such as Syslog, making the data readable by other applications.

Logged data may be provided to or accessed by analytics service 414 . In the illustrated embodiment, the secure mobile gateway 128 includes a log redirector service 412 that periodically reads logged data 410 and sends some or all of it to an analysis service 414 . Log redirection service 412 is preferably configurable such that an IT administrator can direct it to send only those portions of logged data that match configurable criteria. For example, the log redirector service 412 may be configured to send only logged data related to denied requests 402 or only logged data related to allowed requests 402 or based on different criteria. Additionally, the log redirector service 412 and/or the repository of logged data 410 may include features that enable other systems (e.g., the analytics service 414) to query or extract data related to the logged request 402, such as user data, mobile device data, mobile business data (such as the IP address of the sender's device), etc. It will be appreciated that the principles and advantages described with reference to the analysis with respect to the secure mobile gateway 128 may be applied to enable various data mining and correlation for security or other purposes. As an example, if logged data indicates that the mobile device 120 has visited certain prohibited sites and confidential documents that were also recently downloaded and then forwarded to external email, this information may be the basis for a denial of access to enterprise resources.

Analysis services 414 may include, for example, a security information management (SIM) system, a security event management (SEM) system, or a security information and event management (SIEM) system. SIEM solutions are a combination of SIM and SEM solutions. Analysis service 414 may be configured to monitor, analyze, and/or generate and send alerts, notifications, or reports based on logged data. Analysis service 414 may be configured to detect patterns in recorded data, provide metrics useful for further analysis or action, and diagnose problems associated with the data. Analysis service 414 may be configured to process data formatted according to various standards, such as Syslog. For example, analytics service 414 may utilize Splunk, a software program with these types of features. Analysis service 414 may be part of enterprise system 110 , or alternatively may be part of a third-party system for analyzing the types of data recorded in warehouse 410 .

For example, analytics service 414 may be configured to handle denied access by secure mobile gateway 128 by sending a message (e.g., an email or SMS message) to denied user 115, possibly specifying a reason for the denial of access (e.g., "Your request for XYZ The request for access to the company's network was denied because your mobile device does not comply with the company's policy against installing the Angry Birds ^TM software application").

FIG. 21 illustrates an example of logged data that may be provided to analytics service 414, according to one implementation. In this example, the logged data consists of a table of rows and columns. Each row corresponds to a mobile device access request 402 . Columns 2102 and 2104 include data indicating the date and time, respectively, when secure mobile gateway 128 recorded the corresponding row of data. With respect to column 2106, "Priority" is a configurable Syslog setting that identifies the collector and level of the message. Priority is a configurable item that applies to all Syslog collection types. Column 2108 under the heading "Hostname" is the IP address of the host that provided the corresponding row of data. In the illustrated embodiment, hostname 2108 is the IP address of gateway 128 . Column 2110 under the heading "Messages" includes various information about the selected mobile device access request 402 . The message data shown includes the date and time when the request was received, the action gateway 128 took on the request (allow or deny), the user associated with the request (in the first line, "jmcginty"), the mobile device type and when The IP address of the mobile device used to submit the access request.

FIG. 22 shows an example of an interface for configuring the analysis service 414 of the standard under which the analysis service sends alerts based on data recorded by the secure mobile gateway 128 . The interface shown is part of the Splunk SIEM tool. The interface allows administrators to enter the conditions under which alerts will be sent ("Splunk alerts: Allow ActiveSync user alerts"), the content of alerts ("Include search results"), etc.

Authentication of mobile device users

An enterprise network typically authenticates its users at the beginning of a transaction between the user's computer and an enterprise resource. In existing systems, authentication typically involves a login process of receiving a username and password from a user's client device, verifying that the username corresponds to an authorized user, and verifying that the password is a proof password of the username. While some enterprise resources 130 may be configured to consume username data for all transactions with the device (eg, to allow access based on user ID, user role 206 or other group membership, etc.), other resources 130 are not. For some types of enterprise resources 130, after authentication, the user is permitted to conduct at least some transactions with the resource 130 without providing login information. For a specified period of time after the last transaction with an authenticated user, some enterprise resources 130 downstream of the enterprise's firewall assume the IP address of the authenticated IP address (i.e., the IP address of the device sending the user's login information to the enterprise network) New requests come from authorized users. Such enterprise resources typically do not request and confirm the user's login information for every transaction with the user's computing device.

While this approach is generally suitable for non-mobile client devices, it can present security risks unique to mobile devices. Mobile devices often change their IP addresses while in use. For example, a mobile device connected to a cellular network may switch between different cellular towers while in a moving vehicle. Similarly, a mobile device can switch between different Wi-Fi networks. Mobile devices can also switch between different IP addresses associated with a single cell tower or Wi-Fi network. Thus, an enterprise resource 130 that determines a user associated with an incoming mobile device request by examining only the IP address of the request runs the risk of conducting a transaction with someone who is not the user.

23 illustrates an embodiment of a method by which analytics service 414 may utilize secure mobile gateway 128 ( FIG. 4 ) to help determine whether and/or how to respond to mobile device request 2302 to access or use enterprise resource 130. response. For example, enterprise resource 130 may receive mobile device request 2302 via a gateway other than secure mobile gateway 128 . The request 2302 can be received via an application tunnel. While the illustrated embodiment depicts querying the analysis service 414 to find the resource 130 for the binding of user information (e.g., the ID number of the user 115) to mobile service data (e.g., an IP address), components other than the resource 130 (e.g., the tunnel broker 224) It can also be configured to do the same.

In the illustrated embodiment, the secure mobile gateway 128 includes, for example, a gateway filter 401 and a repository 410 of logged data, as described above. Logged data may include data from mobile device access requests 402 received by gateway filter 401 , for example. For example, if the gateway 128 supports ActiveSync, the logged data may include the DeviceId, DeviceType, User and/or UserAgent property values from the ActiveSync request 402 and the ActiveSync command issued by the request 402 .

The request 2302 may include mobile service data, such as the IP address of the mobile device 120 sending the request 2302 . The request 2302 may or may not include data about the mobile device 120 sending the request 2302 . Enterprise resource 130 may receive request 2302 and send user determination request 2304 to analytics service 414 . The user determines that the request 2304 includes the mobile service data requested 2302 . User determination request 2304 may additionally include the time when request 2302 was received by enterprise resource 130 , data about mobile device 120 that sent the request, and other data related to request 2302 . In some implementations, user determination request 2304 may include an identification of user 115 that enterprise resource 130 or another enterprise component believes to be the sender of request 2302, such that analysis service 414 is essentially requested to verify whether identified user 115 is the sender The actual person who requested 2302.

Analysis service 414 may use a user determination algorithm for determining user information related to request 2302 received by enterprise resource 130 . In this context, user information may include a determination of whether the request 2302 was sent by the user 115 (as opposed to someone not associated with or registered with the business), whether the user 115 identified in the user determination request 2304 was the one who sent the request 2302 to Identification of the person of the enterprise resource 130 and/or identification (eg, username) of the user 115 who sent the request 2302 . The user determination algorithm may additionally determine a reliability score indicating a level of confidence in the computed binding—the degree of confidence that the particular user 115 is the actual person who sent the request 2302 . The analysis service 414 may generate and send a response 2306 containing the results generated by the user-determined algorithm. The results of the algorithm may include user information and/or reliability scores.

In the embodiment shown in FIG. 23 , enterprise resource 130 receives request 2302 and sends user determination request 2304 to analysis service 414 , and analysis service 414 sends response 2306 back to enterprise resource 130 . In such implementations, enterprise resource 130 may be configured to use data within response 2306 to determine how to respond to request 2302 . For example, the enterprise may respond to the request 2302 by responding to the device 120 that sent the request 2302, ignoring the request 2302, sending a warning to an IT administrator, etc. Enterprise resource 130 may be configured to make this determination based at least in part on a reliability score (if provided) and/or a particular action or command issued within request 2302 . For example, enterprise resource 130 may be configured to require a relatively high reliability score if request 2302 attempts to download sensitive or confidential enterprise data, while imposing a relatively low reliability score if request 2302 attempts to upload data to resource 130. Enterprise resource 130 may be configured to allow an administrator to configure a reliability score threshold at which resource 130 will take any given action in response to request 2302 .

In other embodiments, a component upstream of the enterprise resource 130 (e.g., a gateway, firewall, proxy server, DLP monitoring device, tunnel broker, SSL traffic inspection device, or other component other than the secure mobile gateway 128) receives the request 2302, generates The user determines the request 2304 and sends the user determined request 2304 to the analysis service 414 , and the analysis service 414 sends a response 2306 to the component upstream of the enterprise resource 130 . In these implementations, an upstream component may be configured to use data within resource 2306 to determine whether to pass request 2302 to enterprise resource 130 . Furthermore, the upstream component can be configured to make this determination based at least in part on the reliability score and/or the action or command issued within the request 2302 . For example, if request 2302 attempts to download sensitive or confidential enterprise data, the upstream component may be configured to send request 2302 to enterprise resource 130 only if the reliability score exceeds a relatively high value. In another example, if the request 2302 attempts to upload data to the enterprise resource 130 , the upstream component may be configured to require a relatively low reliability score for delivering the request 2302 to the resource 130 . The upstream component may be configured to allow an administrator to configure a reliability score threshold at which the upstream component will take any given action in response to the request 2302 .

In some implementations, the analytics service 414 unsolicitedly sends its calculated binding of the user 115 to mobile traffic data (eg, IP address) to the enterprise resource 130 . Analysis service 414 may send the binding directly to resource 130 and/or one or more components upstream of resource 130 that attach the binding or related data to the mobile device communication transmitted to resource 130 . In these approaches, resource 130 may use the computed bindings without requesting them from analysis service 414 .

The user determination algorithm used by the analysis service 414 may include scanning some or all of the recorded data for mobile traffic data (from the mobile device request 402 received by the secure mobile gateway 128) that matches the mobile traffic data received within the user determination request 2304 . For any request 402 that has mobile service data that matches that of request 2302 , the algorithm may also include determining from recorded data 410 the user data or mobile device data provided within the request 402 . For example, user data and mobile device data may include values of the User property and DevicelD property of the ActiveSync request 402, respectively. The analytics service 414 may determine the user 115 corresponding to the user data and/or mobile device data by, for example, requesting the user data and/mobile device data from the mobile device management system 126 . For example, the User and DeviceID property values may correspond to a particular user 115 in the mobile device information 204 . Analysis service 414 may determine that request 2302 was not sent by user 115 if the recorded data does not include (or analytics service 414 cannot find) mobile traffic data that matches that of request 2302 .

To determine user information and calculate a reliability score, a user determination algorithm may evaluate various factors. In some embodiments, the user determination algorithm compares the time when the request 2302 is received by the enterprise resource 130 with the time of receipt (by the secure mobile gateway 128 ) of the mobile device access request 402 with mobile service data matching the data of the request 2302 . For example, assume that ActiveSync request 402 has User and DeviceID property values corresponding to user 115 . Assume further that the sender IP address within request 402 is the same as the sender IP address of request 2302, and within a relatively narrow period of time (either before or after) from when request 2302 was received by enterprise resource 130 (or an upstream component). ) request 402 is received by the secure mobile gateway 128. In such a case, analytics service 414 may calculate a high reliability score indicating that user 115 associated with request 402 is the person who sent request 2302 to enterprise resource 130 . The user determination algorithm may calculate a lower reliability score as the time period between the receipt of Request 2 302 and the receipt of the temporally closest Request 402 with the same sender IP address increases. On the other hand, if the sender IP address within request 402 is different than the sender IP address of request 2302, analysis service 414 may calculate a relatively low reliability score and/or determine that user 115 associated with request 402 may not be The request 2302 is sent to the person at the enterprise resource 130 . Furthermore, if gateway 128 does not receive request 402 with the same sender IP address as request 2302 within a specified or dynamically calculated time window from (before or after) the time of receipt of request 2302, the analysis service 414 may calculate a relatively low reliability score.

In some embodiments, the user determines the algorithm evaluation frequency at which the enterprise network sees a particular user 115 associated with certain mobile traffic data, such as an IP address. For example, assume that secure mobile gateway 128 receives many ActiveSync requests 402 with user values corresponding to a particular user 115 within a relatively short time window encompassing the time when enterprise resource 130 receives requests 2302 . Assume further that all of said ActiveSync requests 402 include the same sender IP address as the request 2302 sender IP address. Under these conditions, analytics service 414 may calculate a very high reliability score indicating that user 115 associated with request 402 is the person who sent request 2302 to enterprise resource 130 . On the other hand, if the sender IP address within request 402 is different from the sender IP address of request 2302, analysis service 414 may calculate a very low reliability score and/or determine that user 115 associated with request 402 may not be The request 2302 is sent to the person at the enterprise resource 130 .

In some embodiments, the user determination algorithm evaluates the extent to which different access requests 402 associated with a particular user 115 have different mobility data. For example, the fact that the string of access requests 402 from a particular user 115 has many different sender IP addresses may indicate that the user 115 is active and constantly switching IP addresses while communicating with the enterprise system 110 . In these cases, analytics service 414 may calculate a reliability score that is relatively lower than if all access requests 402 from a particular user 115 had the same sender IP address as request 2302 . In one particular approach, the analytics service 414 determines (1) to have user data corresponding to the particular user 115 of interest, (2) to have mobile traffic data that does not match the mobile traffic data received within the user determination request 2304, and ( 3) The total number of access requests 402 received by the secure mobile gateway 128 within a predetermined or dynamically calculated time window of the time of receipt contained in the user determination request 2304 . As the total number of determined access requests 402 increases, analytics service 414 may decrease the calculated reliability score (in the level of confidence that request 2302 is from a particular user 115 ).

In some implementations, the user determination algorithm considers whether the IP address of the request 2302 is from a known block or subset of IP addresses registered with or otherwise associated with the enterprise system 110 . Such a block or subset of IP addresses may be available via the enterprise's own equipment, primarily for use by enterprise employees, such as a Wi-Fi network, enterprise VPN assigning blocks, or roaming external IP addresses. Blocks or subsets of IP addresses may be registered with secure mobile gateway 128 . The algorithm may be configured to calculate a higher reliability score if the request 2302 is sent from an IP address associated with the enterprise.

It will be appreciated that the user determination algorithm used to calculate the reliability score may also include other factors in addition to those described above. It will also be understood that the algorithm need not take into account all of the factors described above, and any sub-combination thereof may be used.

In the embodiment shown in FIG. 23 , the analytics service 414 is configured to examine recorded data in the repository 410 of the secure mobile gateway 128 to establish bindings of users and/or mobile devices to mobile service data (eg, IP addresses). However, analytics service 414 may be configured to query multiple different logs of movement request data to compute such bindings. If enterprise system 110 has multiple different secure mobile gateways 128 (eg, for different types or protocols of mobile device communications), analytics service 414 may be configured to query logged data from each gateway 128 .

The analytics service 414 may be configured to generate reports and displays of bindings of users and mobile devices to mobile traffic data (eg, IP addresses). Enterprise system 110 may include a web-based or other type of user interface for viewing such bindings. For example, such information may be displayed via a user interface of the mobile device management system 126 .

In a preferred embodiment, various components of enterprise system 110 may track or log network usage events for one or more mobile devices 120 using the binding of user and/or device to mobile business data generated by analytics service 414 . Analysis service 414 may be queryable and configured to share its information with other components via, for example, web services.

As mentioned above, analytics service 414 may be configured to generate and send notifications to users 115 or IT administrators based on recorded data. Additionally, analytics service 414 may be configured to send such notifications based at least in part on one or more reliability scores calculated according to a user-determined algorithm. For example, if a large number of requests are rejected, and if the reliability scores associated therewith meet specified thresholds, the analytics service 414 may be configured to send an appropriate alert. On the other hand, analysis service 414 may be configured to ignore cases involving low reliability scores. If there are a large number of access denials, but they all have low reliability scores, it may not be worth generating and sending notifications.

For security purposes, analytics service 414 may be configured to bind encryption of user, device, and mobility data generated by service 414 .

Secure Document Container

Referring again to FIG. 3 . In some implementations, mobile device 120 may include a secure document container 336, which may be referred to as a "container." As explained herein, container 336 can help prevent enterprise information from spreading to different applications and components of mobile device 120 and other devices. Enterprise system 110 (which may be partially or entirely within cloud 156 ) may transmit the document to device 120 , and the document may be stored (eg, by enterprise agent 320 ) within container 336 . Container 336 may prevent unauthorized applications 318 and other components of device 120 from accessing information within container 336 . For enterprises that allow users 115 to use their own mobile devices 120 for accessing, storing and using enterprise data, providing a container 336 on the device 120 helps protect the enterprise data. For example, providing container 336 on devices 120 may centralize enterprise data in one location on each device 120 and may facilitate selective or complete deletion of enterprise data from devices 120 .

As used in this context, a "document" may include any computer-readable file, including text, audio, video, and/or other types of information or media. Documents may include any single type or combination of these media types.

Secure document container 336 may include an application implementing a file system 338 that stores documents and/or other types of files. File system 338 may include a portion of the computer-readable memory of mobile device 120 . The file system 338 may be logically separate from other portions of the computer readable memory of the mobile device 120 . In this manner, corporate data can be stored in the secure document container 336 and private data can be stored in a separate portion of the computer-readable memory of the mobile device 120 . Container 336 may allow enterprise agent 320, mobile device application 318, and/or other components of device 120 to read information from, write information to, and/or delete information from file system 338 (if authorized to do so). ). Deleting data from container 336 may include deleting actual data stored in container 336, deleting pointers to data stored in container 336, deleting encryption keys used to decrypt data stored in container 336, and the like. Container 336 may be installed by, for example, agent 320 , an IT administrator of enterprise system 110 , or a manufacturer of device 120 . Container 336 may enable some or all enterprise data stored in file system 338 to be deleted without modifying private data stored on mobile device 120 external to container 336 . File system 338 may facilitate selective or complete deletion of data from file system 338 . For example, components of enterprise system 110 may delete data from file 338 based on, for example, encoding rules. In some implementations, agent 320 deletes data from file system 338 in response to receiving a delete command from enterprise system 110 . In other implementations, the data is deleted without the assistance of the agent 320, eg, if the agent 320 is not provided.

Secure document container 336 may include access manager 340 that manages access to file system 338 by applications 318 and other components of mobile device 120 . Access to file system 338 may be managed based on document access policies (eg, encoding rules) stored in document and/or file system 338 . Document access policies may be based on (1) which application 318 or other component of device 120 is requesting access, (2) which documents are being requested, (3) time or date, (4) geographic location of device 120, (5) requesting Access to the file system 338 is limited by whether the application 318 or other component of the application 318 provided one or more correct credentials, (6) whether the user of the device 120 provided the correct credentials, (7) other conditions, or any combination thereof. A user's credentials may include, for example, a password, one or more answers to security questions (eg, what is your high school mascot?), biometric information (eg, fingerprint scan, eye scan, etc.), and the like. Thus, using access manager 340 , container 336 may be configured to be accessed only by applications 318 authorized to access container 336 . As one example, access manager 340 may enable enterprise applications installed on mobile device 120 to access data stored within container 336 and prevent non-enterprise applications from accessing data stored within container 336 .

Time and geographic restrictions on document access may be useful. For example, an enterprise administrator may employ a document access policy that limits the availability of documents (stored within container 336) to specified time windows and/or geographic regions (e.g., as determined by GPS chip 316) within which device 120 must be present. within a time window or geographic area to access documents. Additionally, the document access policy may instruct container 336 or agent 320 to delete documents from container 336 or otherwise render them unavailable when a specified time period expires or if mobile device 120 is taken outside a specified geographic area.

Some documents may have an access policy that prohibits documents from being saved within the secure document container 336 . In such an embodiment, the document is viewable on the mobile device 120 only when the user 115 is logged on to the enterprise system 110 .

Access manager 340 may also be configured to enforce certain connection patterns between remote devices (eg, enterprise resource 130 or other enterprise servers) and containers 336 . For example, access manager 340 may require that documents received by container 336 from and/or sent from container 336 to a remote device be transmitted through, for example, application tunneling, as described above. Such application tunneling may use tunnel intermediary 224 of enterprise system 110 . Access manager 340 may require that all documents transmitted to and from container 336 be encrypted. Enterprise agent 320 or access manager 340 may be configured to encrypt documents sent from container 336 and decrypt documents sent to container 336 . Documents in container 336 may also be stored in encrypted form.

Secure document container 336 may be configured to prevent documents or data contained within the document from being used by unauthorized applications and components of mobile device 120 or other devices. For example, a mobile device application 318 with authorization to access a document from container 336 may be programmed to prevent a user from copying the document's data and pasting it into another file or application interface or saving the document or document data locally as New files outside container 336. Similarly, container 336 may include a document viewer and/or editor that does not allow such copy/paste and local saving issues. Also, the access manager 340 may be configured to prevent such copy/paste and local save issues. Furthermore, container 336 and applications 318 programmed and authorized to access documents from container 336 may be configured to prevent users from attaching such documents to email or other forms of messages.

The mobile device application 318 can be programmed to look for and locate the secure document container 336 (or the secure web browser 332 described below including the container 336 ) as a resource of the mobile device 120 . In some implementations, the application 318 may run in a secure virtual machine separate from the virtual machine of the operating system of the mobile device 120 . According to some other implementations, the application may run within the secure web browser 332 . Application 318 may be programmed to only write enterprise-related data to container 336 . For example, the source code of application 318 may be provided with the resource name of container 336 . Similarly, a remote application (eg, enterprise resource 130 ) may be configured to send data or documents to one or more containers 336 of mobile device 120 (as opposed to other components or memory locations of device 120 ). Storing data to container 336 may occur automatically, for example, under the control of application 318 , enterprise agent 320 , or web browser 332 . Application 318 may be programmed to encrypt or decrypt documents stored or to be stored within container 336 . In some implementations, container 336 may only be used by applications (either on device 120 or remotely) that are programmed to find and use container 336 and have authorization to do so.

Secure document container 336 may serve as a temporary repository for documents and other files that are sent to mobile device 120 . Remote applications may be configured to send documents to container 336 (eg, via an application tunnel) on a one-time or periodic basis. For example, a sales-related enterprise resource 130 may be programmed to send sales-related documents (eg, a recent price list) to a container 336 of a group of users 115 (eg, salespeople) having a sales-related role 206 each morning. Sales related documents may have a document access policy such that the document will "self-destruct" (e.g. automatically delete from container 336 - deleted by e.g. 336 itself or the enterprise agent 320 executes). Document distribution policies (e.g., encoding rules) may be provided (e.g., within mobile device management system 126) to control when and how remote applications (e.g., enterprise resources 130) send documents to containers 336, to which users 115, to which What restrictions (eg temporal or geographical restrictions) are imposed on the use and availability of documents (eg in the form of document access policies as described above), and so on.

A remote application that sends documents to one or more secure document containers 336 of a mobile device 120 may be configured to integrate with other repositories for the purpose of sending documents from such repositories to containers 336 . Such other repositories may, for example, be stored within enterprise systems 110 (eg, enterprise document repositories such as Microsoft Sharepoint ^™ repositories) or in cloud computing systems (eg, Box.net ^™ repositories).

Software Development Kit for Mobile Device Applications

Another aspect of certain embodiments relates to a software development kit that enables an application developer to embed one or more of the functions described herein within a mobile device software application, such as software application 318 . As used herein, "embedding" may include modification of an application's source code. FIG. 24 illustrates a software development system 2402 including an SDK 2404 for creating mobile device applications 2406. Software development system 2402 can be implemented by any suitable computer hardware. A software developer can create an application 2406, for example, by generating program code and compiling it into an executable program compatible with the mobile device 120.

SDK 2404 may include libraries of development tools 2408 that provide different functionality. Development tools 2408 may include code snippets, data structures, protocols, routines, and the like. SDK 2404 may provide an application programming interface (API) 2410 that enables applications 2406 to interface with development tools 2408. SDK 2404 may include a program editor 2412 for generating code for application 2406 and a compiler 2414 for converting the code into a machine-readable format. SDK 2404 may include debugging tools 2416 for debugging the developed code. It will be appreciated that the SDK 2404 may include other features in addition to these. It will also be recognized that the SDK 2404 need not include all of the features shown.

Development tools 2408 may include tools for embedding one or more of the functions described herein into mobile device software applications 2406 . It will be appreciated that any subcombination of these tools may be embedded in application 2406, and that other functionality not described herein may be so embedded. Various development tools 2408 are now described.

In some embodiments, SDK 2404 includes development tools 2408 that allow application developers to embed within applications 2406 functionality for forming and maintaining application tunnels (e.g., as described above) with network resources and transmit and The ability to receive communications to communicate with network resources. Network resources may include enterprise resources 130, for example. Tool 2408 may be configured to add application tunneling functionality that participates with enterprise agent 320 . As described above in the Application Tunneling section, the enterprise agent 320 may receive network communications from the applications 2406, encapsulate them according to an encapsulation protocol, send the encapsulated communications to the tunnel intermediary, receive similar communications from the tunnel intermediary (which come from the tunnel endpoints resource), unpacks the encapsulated communication that may be received from the tunnel intermediary, and sends the unpacked communication to the application 2406. Alternatively, tool 2408 may provide functionality for forming application tunnels without involvement of enterprise agent 320, where application 2406 itself performs these actions using the encapsulation protocol described above.

In some embodiments, the SDK 2404 includes a development tool 2408 that allows an application developer to embed within the application 2406 functionality for improving the communication experience between the mobile device 120 and a network resource such as the network resource 130, particularly for the application Tunnel communication. Such functionality may include locally caching user-entered data on the mobile device 120 in the event of loss of connectivity to the network, as described above. Such functions may also include compression of data to be sent to network resources, decompression of data received from network resources, as described above. Again, such embedded functionality may engage with the enterprise agent 320 to enable these features, or may provide these features separately from the enterprise agent 320 .

In some embodiments, the SDK 2404 includes a development tool 2408 that allows an application developer to embed within the application 2406 functionality for participating in a remote control session between the mobile device 120 and a help desk operator, as described above. Such functionality may allow a help desk operator to view data about and/or control aspects of the application 2406 installed on the mobile device 120 and possibly other features of the mobile device 120 . Such functionality may include sending user interface simulation data to a help desk operator's computer, as described above. Such functionality may include receiving commands from a help desk operator to perform actions on the mobile device 120 . Again, such embedded functionality may engage with the enterprise agent 320 to enable these features, or may provide these features separately from the enterprise agent 320 .

In some embodiments, the SDK 2404 includes a development tool 2408 that allows an application developer to embed within the application 2406 methods for locating the secure document container 336, providing credentials to the secure document container 336, reading from the secure document container 336, and/or Write to secure document container 336 functionality, as described above. This may allow applications 2406 to access and update information within container 336 . This may also allow the application 2406 to access documents securely received by the mobile device 120 from network resources, such as the enterprise resource 130 or other applications or components of the enterprise system 110 . Development tool 2408 may be configured to modify the source code of application 2406 such that application 2406 can find container 336 by its resource name on device 120 . Development tool 2408 may be configured to modify the source code of application 2406 such that application 2406 writes all data (or perhaps only data related to enterprise 110 ) into the container. For example, development tools 2408 may be configured to parse the source code of an application to find commands for writing data to memory (e.g., an application that allows a user to stop using an application and then later restart it in the exact state the user left it on). state data) or commands to read data from memory, and adjust one or more of those portions of the source code to write data into and read data from container 336.

In some implementations, the SDK's development tools 2408 may embed within the application 2406 the ability to encrypt documents stored within the container 336 and/or decrypt documents obtained from the container 336 . The development tool 2408 may embed an editor within the application 2406 for allowing the user 115 of the mobile device 120 to view and/or edit documents obtained from the container 336 . The editor may also allow user 115 to upload edited or newly created documents to container 336 or a network resource (eg, enterprise resource 130 of enterprise system 110 ).

In some embodiments, the SDK 2404 includes a development tool 2408 that allows an application developer to embed mobile device rules, such as the rules 214 described above, within the application 2406. Additionally, development tools 2408 may allow developers to embed functionality for evaluating mobile device rules, including querying devices 120 or other network resources for data needed for evaluation. Embedded functionality may also include remedial actions related to mobile device rules, such as remedial action 216 described above. Embedded functionality may also include a remediation agent for automatically performing remedial actions on the mobile device, as described above. In contrast to the aforementioned mobile device rules 218 (which are primarily described above as user-specific and device-specific rules), software developers can embed rules and remedial actions that are customized to specific applications 2406 . In some embodiments, SDK 2404 includes tools for creating and editing mobile device rules and remedial actions, such as tool 221 described above. Software developers can use creation/development tools to create mobile device rules and remedial actions and embed them within the application 2406. Certain embodiments provide an online library of mobile device rules and remedial actions that software developers can use with or without modification and embedded within the application 2406.

In some embodiments, SDK 2404 includes development tools 2408 that allow application developers to embed within applications 2406 tools for application failure detection (e.g., using mobile device rules as described above), application performance measurements, and detection of related events. Function. Embedded functionality may include logging of detected faults, performance measurements, related events, event times, event locations, and other data within the local memory of the mobile device 120 . Development tools 2408 may allow applications 2406 to be configured to report such data to network resources, such as components of enterprise system 110, and/or analysis services, such as analysis service 414 described above. This embedded functionality can give IT managers visibility into what is happening on the mobile device, at least as it pertains to the specific applications installed on it 2406. Additionally, the analysis service can analyze data among a plurality of different mobile devices 120 running a particular application 2406 . Embedded functionality may include encryption of data logged on mobile device 120 and/or reported to other components via network communications.

In some implementations, SDK 2404 includes development tools 2408 that allow application developers to embed within applications 2406 for collaboration with meta-applications such as enterprise system-based meta-application portion 150 and/or cloud-based meta-application portion 151. Function. Embedded functionality may include discovering information about the installed application 2406 or the mobile device 120 it is installed on and sending the discovered information to the meta-application for use in, for example, constructing a queryable model (similar to the enterprise Model 814), application 2306 and/or mobile device 120 form at least a portion of the queryable model. Embedded functionality may include receiving queries from the meta-application, responding to the queries by retrieving the queried data from the mobile device 120, and sending the queried data to the meta-application. As discussed above, the meta-application can use the queried data to detect problems, perform root cause analysis, and/or select remedial action. Accordingly, embedded functionality may include receiving remedial actions from the meta-application, performing remedial actions on the mobile device 120, and reporting the results of performing remedial actions to the meta-application. In some implementations, the embedded functionality is shared with the enterprise agent 320 present on the device to provide these features, while in other implementations, the embedded functionality provides these features without cooperation with the enterprise agent 320 .

secure web browser

Another aspect of certain embodiments relates to a web browser within which other mobile device software applications can run. Web browsers can be provided with some or all of the enterprise security and other features described herein, and can extend those features for use with mobile device applications running within the browser. In this way, the browser can be used to implement BYOD policies while maintaining a desired level of control over applications running on enterprise users' 115 mobile devices 120 . An enterprise may require some or all of its users 115 to install and use this web browser to reduce enterprise security risks associated with the use of such mobile device applications. Furthermore, in some cases, such web browsers may make it unnecessary for application developers to develop different versions of mobile device applications for different mobile device platforms. As mentioned above, secure browsers can also be used to enable mobile device users to access corporate intranets without the need for a virtual private network (VPN).

Referring to FIG. 3 , mobile device 120 may include a dedicated web browser 332 . Web browser 332 may be configured to perform the functions of a conventional web browser, including surfing on Internet sites, displaying and/or playing multimedia content received from the web browser, and the like. Web browser 332 may store data accessed over the network in secure document container 336 and/or in a secure browser cache. Such data may be deleted at the direction of the business. For example, the mobile device management system 126 may initiate deletion or otherwise cause data stored in the secure document container 336 or/or secure browser cache to of data becomes inaccessible. Additionally, web browser 332 is preferably configured to act as a container for at least some other software applications 318 installed on mobile device 120 to allow those applications 318 to run within browser 332 . Software application 318 may be configured to launch browser 332 when application 318 itself is launched by user 115 . Furthermore, the application 318 may be configured to launch a browser 332 and run within the browser 332 in a manner transparent to the user 115 . In other words, the user 115 can be given the impression that the application 318 is running as usual without involving the web browser 332 . Web browser 332 may utilize protocols that facilitate its use as a container for other software applications 318 . For example, web browser 332 may utilize HTML5 for this purpose.

Web browser 332 may provide some or all of the functionality described herein. For example, web browser 332 may include some or all of the functionality provided by SDK 2404 and/or enterprise agent 320 described above. Accordingly, web browser 332 may be configured to use application tunneling for communicating with network resources (eg, enterprise resource 130). Web browser 332 may receive (or embed) mobile device rules 214 and remedial actions 216 from mobile device management system 126 or another component of enterprise system 110 . Web browser 332 may optionally embed mobile device rules and remedial actions. Web browser 332 may utilize caching and/or compression methods within the application tunnel to enhance the user's communication experience as described above. Web browser 332 may be configured to provide credentials to secure document container 336, read from, write to secure document container 336, and/or provide an editor for displaying and clipping files obtained from secure document container 336 of mobile device 120. Documentation, as above. In some implementations, web browser 332 may implement secure document container 336 . Web browser 332 may prompt user 115 to provide and verify access credentials before exposing the functionality of application 318 running within browser 332 to user 115 . Alternatively or in addition, web browser 332 may cause data stored to mobile device 120 by applications 318 running within web browser 332 to be encrypted. Web browser 332 may be configured to participate in a remote control session with a help desk operator, as described above. Web browser 332 may be configured to record troubleshooting, performance measurements, related events, event times, and other data, and provide such data to analysis services as described above with respect to SDK 2404. Web browser 332 may be configured to participate in communications with meta-applications, again as described above. By providing at least some of these and/or other functionalities, the web browser 332 can make it unnecessary for mobile device application developers to embed such functionality within the mobile device application 318 .

In some implementations, web browser 332 is configurable such that one or more of these functions can be activated or deactivated under specified conditions that can be configured by a remote computer system, such as enterprise system 110, eg, remotely. Conditions that may be specified include time conditions, location conditions, mobile device characteristics, user characteristics (eg, role 206), and the like. A time condition can be a time of day. For example, web browser 332 may be configured to force all mobile traffic (at least for applications 318 configured to launch browser 332) to go through the application tunnel only during business hours (e.g., 8am to 5pm Monday through Friday), and between those hours Otherwise, send business as usual. The location condition may be the location of the mobile device 120 . For example, browser 332 may be configured to activate the aforementioned compression and caching features when device 120 is in a geographic area known to have poor wireless connections.

Different web browsers 332 can be created for different mobile device platforms, each browser version using a single standard to run mobile device applications. This may advantageously allow mobile device application developers to develop mobile device applications 318 in only one programming language, as opposed to creating different versions for various mobile device platforms. This can substantially reduce application development workload for developers.

An enterprise may require its users 115 to install a web browser 332 on their mobile devices 120, and may prohibit the use of other web browsers. Required browser 332 may be configured to tunnel at least some mobile device traffic to an enterprise-controlled tunneling intermediary, such as intermediary 224 described above. This gives enterprises greater control over their operations, reducing security risks. Enterprises may use mobile device rules 214 , which enable enterprise agents 320 or web browsers 332 present on the devices themselves to detect the installation and/or use of prohibited web browsers on mobile devices 120 . Relevant remedial action 216 may prevent usage of the prohibited web browser, eg, by uninstalling it, preventing it from running, etc., according to the methods described above.

In some implementations, secure web browser 332 may be configured to direct some or all web surfing requests to a content filtering server as described above.

Modify the behavior of pre-existing mobile applications

Systems and processes for enabling non-developers, such as members of a company's IT department, to add to or otherwise modify the behavior of existing mobile applications, such as Android, IOS, or Windows Mobile applications, will now be described. The system or process can be used as an example to create different versions of a mobile application (with different privileges, access rights, etc.) based on the user's role within an enterprise. For example, different versions of the mobile application may be created for different job categories (eg, executives, non-managerial employees, interns, etc.) and/or different departments (sales, IT, human resources, etc.). The processes described in this section may be implemented in application modification or "wrapper" tools or utilities available to enterprises using the disclosed system. This utility may, for example, be hosted on a server accessible to the enterprise (eg as a web service) or provided to the enterprise (eg as a PC application).

In a general use case scenario, the mobile application to be modified is a custom application developed for a specific enterprise. However, this need not be the case. For example, the disclosed systems and processes are also applicable to commercially available mobile applications available in application stores. Mobile applications may be modified without being specifically written to support or enable such modifications. For example, the developer is not required to include any special code or functionality in the application to enable or facilitate modification, and need not be involved in the disclosed process of modifying the application.

The modified behavior generally includes or consists of behavior involving standard API calls or classes. The following are examples of some types of behavior that may be added or modified via the disclosed process:

1. Cut and paste capabilities typically provided by mobile device operating systems such as Android and IOS can be disabled within certain mobile applications such as applications that provide access to confidential corporate data. This change in behavior may be desirable to prohibit employees (or a class of employees) from accidentally or maliciously sending or moving confidential data to unauthorized locations.

2. A mobile application that stores output in a non-encrypted format can be modified to store its output in an encrypted format. In one embodiment, this is accomplished in part by modifying the mobile application's input/output references to cause the application to use an encryption library to encrypt and decrypt data it writes to or reads from memory. Code may also be inserted that causes the mobile application to obtain keys from the enterprise agent for use in encrypting and decrypting data.

3. A mobile application that uses a certain level or type of encryption can be modified to use a different level or type of encryption. For example, if the federal government requires businesses to start using a particular encryption library, existing mobile applications can be modified to effectively replace the existing encryption library with the new encryption library.

4. The enterprise can modify the mobile application so that it uses a special secure connection to the enterprise's network or enterprise systems. For example, mobile applications can be configured to use secure application tunneling as described above.

5. The mobile application can be modified to add login or other authentication prompts or screens.

6. The mobile application can be configured to record and/or report data about its usage. This data may include, for example, time and duration of use, location of use (based on, for example, GPS coordinates), application features invoked, access points visited, and the like. (Existing mobile device operating systems such as Android and IOS provide functionality for enabling applications to obtain these and other types of usage parameters). This usage data can be used by the enterprise, for example, to monitor employee compliance with the enterprise's usage restriction policies, to identify and correct problems with particular enterprise mobile applications, or to determine whether to continue paying for an application license for a particular user. Application usage data collected on mobile devices 120 may be reported, for example, by enterprise agent 320 to mobile device management system 126 or some other system for analysis.

7. The mobile application can be modified to enable the enterprise to remotely initiate deletion of the application's data on a specific mobile device 120 of a specific employee without affecting other users of the application. As mentioned above, such selective wipe operations may also be performed when, for example, a user fails to enter a valid enterprise password a threshold number of times.

8. The mobile application can be modified so that it can be launched by the secure launcher 350B (FIG. 3B) instead of the general launcher of the mobile device's operating system. This can be done, for example, by changing one or more references in the mobile application to the mobile operating system's generic launcher so that they instead point to the secure launcher. As explained above, a secure launcher may implement one or more security policies, such as requiring entry of a valid password before an enterprise application can be launched. The secure launcher can also cause the enterprise application to run in a secure execution environment, for example, by causing the enterprise application to be executed using a secure virtual machine (FIG. 3B) separate from the mobile operating system's virtual machine. (See section below.)

9. The mobile application can be modified so that it launches in virtual machine 350C (FIG. 3B). This can be done by, for example, modifying a reference in the application (eg in the Android application's manifest or in any way where the application is launched) so that it is launched in the secure VM. As explained below in the section titled "Secure Virtual Machine," a secure VM can implement some of the client-side security functions described herein (encryption, application tunneling, etc.), reducing or eliminating the need to add such functionality to the mobile application itself. need. This enables corporate applications to run in a secure execution environment, while private applications run in the default VM.

Other examples include disabling offline access, adding URL filtering, adding API filtering, disabling writing to local storage, and preventing documents from opening in new applications.

Figure 29 illustrates one embodiment of an application modification system. The system includes an application transformer 2900 that modifies based on operator selected policies. For Android applications, the transformer 2900 receives the application's .APK (application package) file and outputs a new .APK file representing the modified application. For IOS, the transformer 2900 receives an .IPA (iPhone Application Archive) file and outputs a new .IPA file representing the modified application. Various other file formats and mobile device operating systems are supported. As shown in Figure 29, the application transformer 2900 preferably includes a disassembler 2900A (for disassembling the application's executable code), a code analyzer/mapper 2900B, a code modifier/inserter 2900C and an application rebuilder 2900D.

As shown in FIG. 29, transformer 2900 accesses policy repository 2902 that contains policy descriptions for various policies and related actions, such as those listed above. For example, a "disable cut and paste" policy may be provided. Policies may be described in any suitable language and format. For example, policy descriptions are stored as smali files. As further shown in FIG. 29, the system also includes a control interface 2904 or "console" that enables an administrator to select one or more policies to apply to a given application. Console 2904 may also include tools for enabling administrators to specify new policies. For example, new policies could be specified that add authentication sequences, disable cut and paste, and cause all files to be stored in encrypted form. This strategy can then be used as a basis for modifying multiple mobile applications.

In a typical use case scenario, a member of a company's IT department uses the control interface 2904 to: select a mobile application to be modified, select one or more policies to apply, and initiate the transformation process. The modified application is then distributed to relevant employees or other users (eg, through a special application store, which is accessible through an enterprise agent, as described above). This process can be repeated with different policy choices to create different versions of the application for different users. Policy repository 2902 may, for example, include policy files for implementing some or all of the types of policies described above (and various other policies).

Figure 30 illustrates a sequence of steps that may be performed by transformer 2900 to modify an Android application based on a selected set of one or more policies. A similar process can be used to transform applications written for other operating systems, such as IOS and Windows Mobile. The entire process shown in Figure 30 is preferably fully automated, meaning that no human intervention is required. In block 3000, the .APK file is opened. As is known in the art, this file contains various application components, such as the application's executable code, images, XML files, manifests, and other resources. In block 3002, the disassembler 2900A disassembles the application's executable code to produce one or more text smali files. As will be appreciated, intermediate languages other than smali may be used to implement the disclosed modification tasks.

At block 3004, the analyzer/mapper 2900B analyzes and maps the application code (in smali format) to generate information about API calls that will likely be replaced. In block 3006, the relevant API calls are replaced with new API calls for implementing the one or more selected policies. Additionally, relevant code from policy library 2902 is added. For example, if the cut and paste functionality is disabled, any API calls used by the application to access the switching and pasting functionality of the operating system may be removed or replaced.

As an example, a new version of the Java I/O File Input Stream (java.io.FileInputStream) class can be created, and all references to the original class can be modified to point to this new version. The new version may, for example, include code for encrypting and decrypting data on file write and read operations, respectively.

In block 3008 of Figure 30, if applicable, additional code may be added to implement the replaced one or more features or behaviors that do not require any existing API calls. As one example, code can be added to enable an authorized administrator to remotely trigger the deletion of an application's data stored on a particular mobile device on a user-specific or mobile-device-specific basis. In this example, the code added in block 3008 would add functionality for receiving and processing messages containing commands to perform such selective wipe or delete operations.

To provide an additional layer of security, obfuscation methods and functions known in the art may be used to obfuscate the portion of code modified in the preceding block. The use of obfuscation compromises the ability of others to reverse engineer security features added to an application. Obfuscation can be applied to disassembled code (eg smali code) or can be applied at different levels.

In block 3010 of Figure 30, the application's manifest (eg, AndroidManifest.xml) is modified, if necessary, to reflect the modified behavior. As an example, if the application was modified to launch in a secure shell, the manifest would be modified to instruct the Android operating system to use the secure shell to launch the application. In some implementations, this involves replacing references to the operating system's generic launcher with references to secure launcher 350B (FIG. 5B). In block 3012, the modified smali code and manifest are compiled into a new .APK file along with other extracted application components. In block 3014, the new .APK file is signed using a digital certificate.

Mobile applications written for the IOS operating system can be modified in a similar manner. Typically, such applications are distributed as an IPA file that includes an executable, P-list, and resources in Mach-O format. Once the executable is disassembled to produce ARM assembly code, it is mapped to identify classes that may be replaced, and then by (1) identifying the specific class or classes to be replaced, (2) adding/modifying code To replace such classes, (3) adjust the class structure to reflect the modifications so that each new class is a subclass of the original code and (4) update references to point to one or more new classes as modified.

In some implementations, the process described above may be augmented with one or more tests for verifying that the mobile application to be modified does not contain malware or otherwise present a risk to enterprise security. One such test involves generating a hash of some or all of the application files and then comparing this hash to a library of hashes associated with known malware. If a match is found (indicating that the application may include malware), the application modification process can be terminated.

Another such test involves examining API calls and URL requests made by applications to check for suspicious activity. Examples of suspicious activity include reading private contacts stored on the device, sending emails to cloud storage devices, and sending location information without first asking the user for permission. Based on this analysis, a score can be generated (eg, on a scale of 1 to 100) representing the level of risk posed by the mobile application. If this score exceeds a threshold, the modification process can be terminated. Scores may additionally or alternatively be included in reports detailing detected suspicious activity. The application modification tool may output this report for review, for example, and may prompt the administrator-user for confirmation or to indicate whether the modification process should proceed.

The application modification system shown in FIG. 29 may be implemented, for example, on a server, personal computer, workstation, or other computer or system within a company's enterprise system. Alternatively, the application modification system may be implemented as a hosted service accessible to corporate customers via the Internet. The various components 2900-2904 of the system may be implemented as modules of code stored on any type of non-transitory computer storage device or system.

Components 2900, 2902, 2904 of the system shown in FIG. 29 may be provided to companies as part of a larger system (such as the systems described in other sections of this specification) for use in enabling companies to manage mobile devices and secure Data accessed by the device. For example, these components may be bundled and licensed with various other components described in this disclosure. Alternatively, the application modification system of FIG. 29 may be offered to companies as a stand-alone product or as a system hosted by a service provider and accessed over a network.

Secure Virtual Machine

As mentioned above, one approach for effectively adding a security layer to enterprise mobile applications is to configure or force such applications to run within a secure VM 350C (FIG. 3B) installed on the mobile device. A secure VM can be similar to a mobile operating system's VM, but can point to special code libraries added to the mobile device, including code libraries for performing functions such as encrypting/decrypting data and using application tunneling. The use of a secure VM enables an enterprise's IT department to effectively add a security layer to a pre-existing mobile application with little or no modification to the application itself. This may be desirable when, for example, an enterprise wishes to use a popular commercially available mobile application as an enterprise application but does not have the authorization to (or otherwise does not wish to) make certain types of modifications to the application.

The Secure VM 350C can load its own dedicated libraries for storage, networking, policy management, etc. For example, some or all data stored by applications running in secure VM 350C may use some encryption policy. The secure VM 350C may implement a set of policies (e.g., authentication, disabling of cut/paste, prevention of access to certain ULRs, prevention of access to certain APIs, etc.) to control the execution of applications within the secure VM 350C.

The security VM 350C may prevent the execution of applications running within it based on the detection of certain conditions, such as conditions indicating that the application has a virus or malware. Hooks can be added to the security VM 350C to prevent programs from being executed when certain conditions are detected. Secure VM 350C may observe the execution characteristics of applications running within it to determine that the applications do not exhibit malicious behavior.

By using a custom VM, all corporate content can be essentially separated from other content stored on the device. Such a custom VM may prevent sharing data or applications with applications executing in the default VM of the mobile device 120 . Also, data accessed and/or manipulated by applications running in the custom VM may be stored in the secure data container 336, as described above.

In one embodiment, a single secure VM is provided on the mobile device 120 for running enterprise applications and can be used to run multiple enterprise applications concurrently. In another embodiment, multiple secure VMs are provided on the mobile device such that each enterprise application runs within a separate secure VM. A mixture of the two approaches is also possible.

Various methods are available to force or configure pre-existing mobile applications to use the secure VM. One such method involves modifying the mobile application so that it uses the secure launcher 350B, as described in the previous section. The secure launcher starts the secure VM when the application is launched, and then effectively passes the mobile application to the secure VM for execution. Another approach involves modifying the mobile application by replacing references to the operating system's default virtual machine with references to the secure VM. Another approach involves instructing the mobile device's operating system to execute the mobile application in a secure VM at the time of application installation.

In one embodiment, whenever a mobile application running in the secure VM performs a file read or write operation, the secure VM uses the encryption library to process the data being read or written. The secure VM thus applies encryption to enterprise data stored locally by enterprise applications.

The library files used by the Secure VM may in some implementations be incorporated into the operating system or otherwise with the cooperation of the OS developer, device manufacturer/seller, or other party with the appropriate level of permission to manufacture such add-ons Install on mobile devices. The ability to add such library files generally increases the security capabilities of a secure VM, but is not essential.

One benefit of running applications in a secure VM is that the secure VM can load an optional set of specialized libraries for storage, networking, policy management, and the like. For example, a library can be loaded that causes all data stored by the application to be encrypted using some encryption library. Libraries can also be loaded that eg disable cut/copy/paste operations, require user authentication, prevent access to certain URLs, prevent access to certain APIs, etc. Specific libraries may be loaded, for example, based on the user's role or status within the enterprise, the particular application being launched, or/or other criteria.

Another benefit of running an application in a secure or custom VM is that the execution of the application can be blocked if the application exhibits suspicious behavior of the type present in malware or viruses. This can be accomplished by adding hooks to the secure VM to enable the execution of applications to be monitored and/or blocked.

A secure or custom VM also provides mechanisms for keeping enterprise content separate from other content stored on the device. For example, through the use of a secure VM, data stored by an enterprise may be stored in a secure container, as described above. This data is advantageously inaccessible in unencrypted form to the device's default VM or applications running within it.

In the context of the Android OS, one method available for launching applications in a secure VM involves the use of the app_process command to modify the standard boot sequence. For example, once Zygote initializes a subprocess, a command of the following format can be used: execvp(“/system/bin/app_process”,..<args>..). (Zygote is a special process created when Android boots; once created, it opens a server socket to listen for process creation requests.) This call replaces the old executable image with the new one and makes the secure VM Can use some existing libraries/jars and be loaded with some new libraries/jars implementing features such as enterprise policy push, secure storage and secure networking. The new instance is not a share of Zygote or any other parent process, but rather a completely new process with its own execution environment and increased set of behaviors. Once the secure VM is loaded, the following steps can be performed to start the application in the secure VM: (1) the newly created process performs an "attach" operation; (2) once the ActivityManagerService receives an attach request from the newly created process, It just sends it the stored intent, so that the ActivityThread will look for the intent in the application's manifest, and will create the activity; and (3) it then starts running the application. These three steps are the same as the last three steps normally performed when the application is launched in Android. The Android runtime or any other compatible runtime can be loaded into the secure VM, making the application compatible with the secure VM. This above procedure can be altered by one skilled in the art for use with other operating systems.

Applications can be configured or "flagged" to use the secure/custom VM in various ways. For example, in the context of Android, the standard command "adb shell pm enable(packagename)" can be used to set the "enabled" state or flag of an application package. As another example, an enterprise agent installed on the device could make a call to this API at install time and specify all applications to run in the secure/custom VM. When such an application is launched later, the "enabled" flag can be checked (before Zygote is asked to create/fork a new process) and based on the state of this flag a new secure VM instance can be created. This procedure can be altered by one skilled in the art for use with other operating systems.

in conclusion

Secure mobile gateway 128 and mobile device management system 126 may each be implemented by a computer system comprised of one or more computing devices (eg, physical servers, workstations, etc.) that may, but need not, be co-located. Each such computing device generally includes a processor (or processors) that executes program instructions or modules stored in memory or other non-transitory computer-readable storage medium or device. Secure mobile gateway 128 and mobile device management system 126 may be implemented on common hardware or on separate and distinct hardware.

All of the methods and processes described above may be embodied in and fully implemented via software code modules executed by one or more computer devices (e.g., smartphones, tablet computers, other types of mobile devices, physical servers, etc.) automation. Each such computer device generally includes a processor (or multiple processors) executing program instructions or modules stored in a memory or other non-transitory computer-readable storage medium or other computer storage device. Code modules may be stored on any type of computer readable storage medium or other computer storage devices. Some or all of the methods may optionally be embodied in special purpose computer hardware such as an ASIC or FPGA. Where a given software component (e.g., an enterprise agent or a secure enabler) is described herein as performing or implementing a given function, it should be understood that the component indicates, by way of executable instructions, that one or more processors (the processor of the mobile device) To perform or realize a function.

Various modifications to the implementations described in this disclosure may be readily apparent to those skilled in the art, and the generic principles laid down herein may be applied to other implementations without departing from the spirit or scope of this disclosure. Accordingly, nothing in this specification is intended to imply that any feature, characteristic or attribute of the disclosed systems and processes is essential.

Certain features that are described in this specification in the context of separate implementations can also be implemented in combination in a single implementation. Conversely, various features that are described in the context of a single implementation can also be implemented in multiple implementations separately or in any suitable subcombination. Moreover, although features may be described above as functioning in certain combinations and even initially claimed as such, one or more features from a claimed combination may in some cases be deleted from the combination, and the claimed combination may Points to a subcomposition or a variant of a subcomposition.

Similarly, while operations are depicted in the figures in a particular order, this should not be read as requiring that such operations be performed in the particular order shown, or in sequential order, or that all illustrated operations be performed to achieve the desired result. In some cases, multitasking and parallel processing may be advantageous. Moreover, the separation of various system components in the implementations described above should not be construed as requiring such separation in all implementations, and it is understood that the program components and systems may often be integrated together in a single software product or package into multiple software products.

Example implementation

Example implementations of the present disclosure include:

1. A non-transitory computer memory storing executable components configured to provide functionality for selectively securing attachment data rendered to a mobile device, the executable components comprising directing one or more Instructions for a computing device to perform a process, the process including:

Receives an attachment to a message from an enterprise resource that is rendered to the mobile device;

determining whether to encrypt the attachment based on one or more configurable access policies of the enterprise; and

When a determination is made to encrypt the attachment,

encrypt said attachment; and

An encrypted attachment is caused to be transmitted to the mobile device in place of the attachment, the mobile device being configured to detect that the encrypted attachment is encrypted and to decrypt the encrypted attachment.

2. The computer storage of claim 1, wherein determining is based at least in part on a role of a user of the mobile device within the enterprise.

3. The computer memory of claim 1, wherein determining is based at least in part on one or more characteristics of the mobile device.

4. The computer memory of claim 3, wherein determining is based at least in part on whether a particular mobile application is installed on the mobile device.

5. The computer storage of claim 1, wherein determining is based at least in part on one or more characteristics of the accessory.

6. The computer memory of claim 1, wherein the process further comprises at least one of the following operations:

naming the encrypted attachment a suffix that is different from a corresponding attachment prior to encryption of the attachment, wherein the mobile device is configured to detect that the encrypted attachment is encrypted based on the suffix; and

Give links to said attachments a suffix that is different from corresponding links to unencrypted attachments.

7. The computer memory of claim 1, wherein the process further comprises encrypting an attachment key used to encrypt the attachment and transmitting the encrypted attachment key with the encrypted attachment to the mobile device.

8. The computer memory of claim 1, wherein the message is an electronic mail message.

9. The computer memory of claim 8, wherein encryption of the attachment is transparent to an email client of the mobile device.

10. The computer storage of claim 1, wherein the process further comprises modifying the one or more configurable access policies of the enterprise.

11. The computer storage of claim 1, wherein causing the message with the encrypted attachment to be transmitted to a selected mobile device comprises causing the message to be transmitted through a firewall of an enterprise computing system.

12. The computer memory of claim 1, wherein the process further comprises, when a determination is made not to encrypt the attachment, causing the attachment to be transmitted to the selected mobile device in unencrypted form.

13. The computer memory of claim 1, wherein the process further comprises:

receiving a request from the mobile device to forward the message;

decrypt the encrypted attachment; and

The message with the decrypted attachment is caused to be transmitted to the enterprise resource.

14. The computer memory of claim 13, wherein the decryption is transparent to an email client installed on the mobile device.

15. The computer storage of claim 13, wherein the process further comprises when the forwarded message is rendered to a different mobile device, based on at least one of the one or more configurable access policies of the enterprise Whether to indicate that the attachment is encrypted for the different mobile device determines whether to re-encrypt the attachment.

16. A system comprising:

a data store configured to store one or more rules specifying conditions under which attachments are encrypted; and

one or more computing devices in communication with the data store, the one or more computing devices configured to:

monitor messages from enterprise computing systems that are rendered to mobile devices; and

at least in part by comparing a condition associated with the selected message with a value associated with the condition in the one or more rules stored in the data store. Attachments to messages are encrypted.

17. The system of claim 16, wherein the condition includes a characteristic of the mobile device.

18. The system of claim 16, wherein the condition includes a characteristic of a user associated with the mobile device.

19. The system of claim 16, wherein the condition includes a characteristic of the accessory.

20. The system of claim 16, wherein the message is an email message from an enterprise email server, the email message being rendered to the mobile device.

21. The system of claim 20, wherein the one or more computing devices are configured to encrypt the attachment transparently to an email client of the mobile device.

22. The system of claim 20, wherein the monitored messages are formatted according to the ActiveSync protocol.

23. The system of claim 16, wherein the one or more computing devices are further configured to:

encrypting the attachment key used to encrypt the attachment; and

causing the encrypted attachment key to be transmitted to the mobile device.

24. The system of claim 23, wherein the one or more computing devices are configured to encrypt the accessory key such that only the mobile device is configured to decrypt the accessory key.

25. The system of claim 16, wherein the one or more computing devices are further configured to compare conditions associated with the selected message with the one or more messages stored in the data store. A value associated with a condition in a rule is used to encrypt at least a portion of the selected message.

26. The system of claim 16, wherein the one or more computing devices comprise at least one of a firewall server, an application server, a computing device configured to control a firewall server, or a computing device configured to control an application server.

27. The system of claim 16, wherein the one or more computing devices are configured to cause transmission of the encrypted attachment to the mobile device separately from transmission of the message to the mobile device.

28. The system of claim 16, wherein the one or more computing devices are configured to:

encrypting the attachment in response to a determination that the attachment is encrypted; and

An encrypted attachment is caused to be transmitted to the mobile device in place of the attachment.

29. A method of selectively securing email attachment data rendered to a mobile device, the method comprising:

Monitor email messages from corporate resources that are delivered to mobile devices;

detecting that data requested by the mobile device from the enterprise resource includes an attachment of a selected one of the email messages;

determining whether to encrypt the attachment for transmission to the mobile device at least in part by comparing a value of a property in at least one rule with a property associated with at least one of: the selected email message, the accessory, the user of the mobile device, and the mobile device; and

Encrypting the attachment when the determination is made to encrypt the attachment:

The method is performed by a computing system including one or more computing devices.

30. A non-transitory computer memory storing executable components configured to be installed on a mobile device to provide functionality for securely accessing data from an enterprise computing system, the executable components comprising a bootstrap Instructions for performing a process by the mobile device, the process comprising:

determining that an email message received by the mobile device includes an attachment encrypted by a gateway associated with the enterprise computing system; and

Decrypting said attachment stored on said mobile device using a key derived from said enterprise computing system, said decryption occurring transparently to an email client installed on said mobile device, said decryption also An enterprise email server of the enterprise computing system appears transparently.

31. The non-transitory computer storage of claim 30, wherein the process further comprises prompting a user of the mobile device to provide access credentials, and wherein the decryption is responsive to detecting the access received from the user The credentials indicate that the user is authorized to access the attachment according to one or more enterprise access policies.

32. The non-transitory computer storage of claim 31, wherein the access credentials include a password.

Example implementation

Another example implementation of the present disclosure includes:

1. A computer readable medium having stored thereon an agent component configured to be installed on a user's mobile device to provide secure access to an enterprise resource of an enterprise system over a network, the agent component comprising implementing a process executable code, the process includes:

intercepting HTTP requests generated by applications installed on said mobile device;

encapsulating the representation of said HTTP request according to a tunneling protocol; and

The encapsulated representation of the HTTP request is sent over a network to a tunnel intermediary configured to extract the representation of the HTTP request and forward the representation of the HTTP request to a corresponding enterprise resource.

2. The computer-readable medium of claim 1, wherein encapsulating the representation of the HTTP request comprises modifying the HTTP request by substituting a hostname of the enterprise resource for a hostname, and encapsulating the modified HTTP request.

3. The computer-readable medium of claim 1, wherein the proxy component is configured to intercept the HTTP request as an HTTP proxy server.

4. The computer-readable medium of claim 1, wherein the proxy component is configured to send the encapsulated representation of the HTTP request in conjunction with the application-specific tunnel definition installed on the mobile device.

5. The computer-readable medium of claim 1 , wherein the proxy component is configured to send the encapsulated representation of the HTTP request via an application tunnel dedicated to Communication between the application and the enterprise resource.

6. The computer-readable medium of claim 1 , wherein the process further comprises multiplexing encapsulated communications from multiple applications installed on the mobile device for transmission to the tunneling intermediary over a common connection such that Multiple application tunnels are multiplexed over the common connection.

7. The computer-readable medium of claim 1 , wherein the proxy component is configured to use a custom SSL (Secure Sockets Layer) library to establish a secure session with the enterprise resource and use the secure connection to send the Said encapsulation of said HTTP request indicates that said custom SSL library is configured to accept digital certificates returned by said enterprise resource regardless of hostname mismatch, such that hostname matching requirements are ignored.

8. A computing system comprising one or more computing devices programmed to:

a repository of application tunnel definitions, each tunnel definition corresponding to a mobile device application and indicating a server port associated with a resource of said computer system; and

The tunnel broker, which is configured as:

receiving an application tunneling request from an agent installed on the mobile device, the application tunneling request identifying one of the tunnel definitions;

retrieving the identified tunnel definition from the repository;

determining a server port of a resource of the computer system from the retrieved tunnel definition;

receiving at least one proxy-generated communication from the proxy, the proxy-generated communication comprising an application-generated communication from an application installed on the mobile device, the application associated with the identified tunnel definition, the application generating The communications of are encapsulated by the proxy within one or more headers of an encapsulation protocol;

extracting the application-generated communications from the proxy-generated communications; and

Communications generated by the application are sent to the server port via a resource network connection.

8. The computer system of claim 8, wherein the tunnel intermediary is further configured to:

receiving a response to the application-generated communication from the resource via the resource network connection;

encapsulating the response within one or more headers of the encapsulation protocol; and

An encapsulated response is sent to the agent of the mobile device.

10. The computer system of claim 8, wherein:

The mobile device application includes a web browser;

Communications generated by the application include Uniform Resource Locators (URLs) of information resources available on the World Wide Web; and

The tunnel broker is configured as:

applying a policy governing whether access to said URL is permitted by an enterprise associated with said computer system;

responding to a determination that access to the URL is permitted by sending the application-generated communication to the URL; and

A determination that access to the URL is not permitted is responded to by not sending the application-generated communication to the URL.

11. The computer system of claim 8 , further comprising a mobile device manager associated with the tunnel broker, the mobile device manager configured to if the mobile device or the user assigned to the mobile device The request is denied if one or more characteristics do not comply with one or more policies associated with the mobile device manager.

12. The computer system of claim 8, wherein the tunnel intermediary is further configured to:

receiving data from the resource via the resource network connection;

initiating sending of the data to the mobile device via a mobile device network connection between the tunneling broker and the mobile device;

responding to a loss of the mobile device's network connection by caching at least a portion of the data not yet sent to the mobile device; and

Resume of the mobile device network connection is responded to by sending the cached data to the mobile device via the restored network connection.

13. The computer system of claim 8, wherein the tunnel intermediary is further configured to record information about at least one of: (1) information received from a specific application and connected by the tunnel intermediary via the resource network application-generated communications sent to the resource; and (2) resource-generated communications received from the resource and sent by the tunneling intermediary to the mobile device.

14. A mobile device comprising a processor and memory, the mobile device comprising:

one or more application tunnel definitions stored in said memory, each tunnel definition corresponding to a mobile device application and indicating a local mobile device port;

an agent installed on the mobile device, the agent being associated with the remote computer system and configured to:

receiving an application-generated communication generated by an application installed on the mobile device configured to communicate with a resource of a remote computer system;

searching the memory to retrieve tunnel definitions associated with the application;

generating an application tunnel formation request based on the retrieved tunnel definition;

encapsulating at least a portion of communications generated by the application within one or more headers of an encapsulation protocol; and

The application tunneling request and the encapsulated application-generated communication are sent to a tunneling intermediary of the remote computer system.

15. The mobile device of claim 14 , wherein the application-generated communications include HTTP requests, and the proxy is configured to (1) replace the hostname in the HTTP request with the hostname of the resource modifying the HTTP request, and (2) encapsulating the modified HTTP request within the one or more headers of the encapsulation protocol.

16. The mobile device of claim 14, wherein the proxy is configured to operate as an HTTP proxy server for the application.

17. The mobile device of claim 14, wherein the agent is further configured to:

receiving a response to the application-generated communication from the tunnel intermediary via a local mobile device port defined in the retrieved tunnel definition, the response encapsulated within one or more headers of the encapsulation protocol;

extracting a response resulting from the resource from the one or more headers; and

The response generated by the resource is provided to the first application.

18. The mobile device of claim 17, wherein the response is generated by the resource and encapsulated by the tunnel intermediary.

19. The mobile device of claim 14 , wherein the proxy is configured to respond to a loss of mobile device connectivity by caching data that has not yet been sent to the tunnel intermediary; The device connection sends cached data to the tunnel intermediary in response to restoration of the mobile device connection.

20. A non-transitory computer memory comprising executable instructions directing a mobile device to perform a process, the process comprising:

intercepting messages sent by a mobile application running on said mobile device;

modifying the hostname specified by said message to correspond to the target application server;

encapsulating the modified message according to the application tunneling protocol; and

The encapsulated modified message is sent over the wireless network for distribution to the application server via the application tunnel.

21. The non-transitory computer storage of claim 20, wherein the instructions form an HTTP proxy server component implementing the process.

22. The non-transitory computer storage of claim 20, wherein the application tunnel is dedicated to communication between the mobile application and the target application server.

23. A non-transitory computer readable memory comprising executable code configured to be installed on a mobile device for enabling a mobile application installed on the mobile device to pass through a network via a secure application tunnel A process of communicating with an application server, the process including:

creating a secure SSL (Secure Sockets Layer) session with the application server, wherein creating the secure SSL session includes ignoring hostname mismatches during checking of digital certificates received from the application such that the digital certificates are not rejected ;as well as

A proxy server is implemented that intercepts messages from a mobile application in said mobile device, encapsulates said messages according to an encapsulation protocol, and sends said encapsulated messages over said network using said secure SSL connection.

24. The non-transitory computer readable memory of claim 23, wherein the process creates an exception on the mobile device to the hostname matching requirement, the exception enabling the mobile device to accept The digital certificate for the hostname of the local host used by the server.

Example implementation

Additional example embodiments of the present disclosure include:

1. A method of providing a secure environment for executing an enterprise application on a mobile device, the method comprising:

installing a secure launcher on the mobile device, the secure launcher being separate from a general launcher included within an operating system of the mobile device, the general launcher providing for launching the functionality of non-enterprise applications; and

installing an enterprise application on the mobile device such that the enterprise application can be launched using only the secure launcher and not using a universal launcher, the enterprise application including functionality for accessing enterprise systems;

Wherein the secure launcher is configured to implement an authentication policy, wherein a user must enter valid authentication information when launching an enterprise application.

2. The method of claim 1, further comprising installing on the mobile device a secure virtual machine separate from the virtual machine of the mobile device's operating system, and configuring the mobile device such that at least some of the enterprise applications but none of the non-enterprise applications run within the secure virtual machine.

3. The method of claim 2, wherein the secure virtual machine includes functionality for enforcing an enterprise data encryption policy, wherein data stored by the enterprise application on the mobile device is encrypted.

4. The method of claim 1 , further comprising installing executable code on the mobile device, the executable code configured to create a secure container on the mobile device and use the secure container to store For documents output by the enterprise application, the secure container is separate from storage space used by the non-enterprise application to store data.

5. The method of claim 1 , further comprising installing executable code on the mobile device, the executable code configured to create an Each application tunnel is specific to a corresponding enterprise application.

6. The method of claim 1 , further comprising modifying at least one of the enterprise applications via an application modification utility prior to installing the enterprise applications on the mobile device to configure the enterprise applications to use an encryption library Data stored on the mobile device is encrypted.

7. The method of claim 1 , wherein the method includes modifying at least one of the enterprise applications by replacing a reference to the universal launcher with a reference to the secure launcher such that the enterprise application The app uses the secure launcher.

8. A mobile device comprising a processor and memory, said mobile computing device having mounted thereon:

a plurality of enterprise applications configured to communicate with the enterprise system over the network; and

a secure launcher that provides a user interface for launching the enterprise application on the mobile device, the secure launcher is separate from a generic launcher for launching non-enterprise applications on the mobile device, the generic the launcher is part of the operating system of the mobile device, and the secure launcher is separate from the operating system, the enterprise application can only use the secure launcher instead of the universal launcher in the mobile device is activated on

Wherein the secure launcher is configured to authenticate a user of the mobile device when the user attempts to launch an enterprise application, and is configured to prevent execution of the enterprise application when the user fails to provide valid authentication information.

9. The mobile device of claim 8, wherein the user interface of the secure launcher includes a persistent display element displayed in a plurality of screens of the mobile device, the persistent display element enabling a user to selectively The arrangement of enterprise application icons associated with a particular enterprise application, the arrangement of enterprise application icons being selectable to initiate the launch of the corresponding enterprise application, and the arrangement of enterprise application icons for launching non-enterprise applications The layout is separated.

10. The mobile device of claim 9, wherein the arrangement of application icons comprises a rotatable wheel display element rotatable via a swipe operation to reveal and hide business application icons.

11. The mobile device of claim 8 , further comprising a secure virtual machine installed on the mobile device, the secure virtual machine being separate from the virtual machine of the operating system, wherein the mobile device is configured such that at least Some of the enterprise applications are executed by the secure virtual machine and cause the non-enterprise applications to be executed by the operating system's virtual machine.

12. The mobile device of claim 11, wherein the security virtual machine includes functionality for encrypting data stored in the memory of the mobile device by an enterprise application.

13. The mobile device of claim 11, wherein the secure launcher is configured to launch the secure virtual machine and cause an enterprise application selected by a user to be executed by the secure virtual machine.

14. The mobile device of claim 8, wherein the secure launcher is configured to perform a selective erase operation wherein data associated with the enterprise application is deleted from the mobile device without deleting Data related to enterprise applications.

15. The mobile device of claim 8, wherein said mobile device has installed thereon an enterprise agent component in communication with said enterprise system, said agent component comprising executable code for creating an application tunnel, said Application tunnels enable the enterprise application to communicate with the enterprise application over the network, each application tunnel being specific to a particular enterprise application.

16. The mobile device of claim 15 , wherein the agent is configured to collect information identifying the non-enterprise application installed on the mobile device and report the information to a mobile device management component of the enterprise system .

17. A method of providing a secure environment for execution of an enterprise application on a mobile device comprising a non-enterprise application thereon, the method comprising:

installing a secure virtual machine on the mobile device, the secure virtual machine separate from a virtual machine included within an operating system of the mobile device; and

configuring the mobile device to run at least one enterprise application but none of the non-enterprise applications in the secure virtual machine, whereby the non-enterprise applications continue to use the virtual machine included within the operating system ;

Wherein the secure virtual machine includes functionality for implementing an encryption policy, wherein data stored by the enterprise application on the mobile device is encrypted.

18. The method of claim 17, wherein the secure virtual machine further comprises a device for creating an application tunnel between the mobile device and an enterprise system and using the application tunnel for communication between the enterprise application and the enterprise system. Describes the functionality of communication between enterprise systems.

19. The method of claim 17, wherein the method includes including a reference to the secure virtual machine in the enterprise application.

20. The method of claim 17, further comprising installing a secure launcher on the mobile device and configuring the enterprise application to use the secure launcher, the secure launcher being compatible with a Universal launcher separation within the operating system of the device.

Example implementation

Additional example embodiments of the present disclosure include:

1. A non-transitory computer memory storing an application modification utility that enables a pre-existing mobile application to be configured for use by members of an enterprise to securely access enterprise data on a mobile device, the utility Programs include executable code that directs a computer system to perform processes including:

disassemble the executable code of said mobile application;

Analyze disassembled code;

modifying the disassembled code to increase functionality for implementing at least one enterprise security policy, the modification comprising replacing one or more API (application programming interface) calls associated with the one or more behaviors to be modified; and

The mobile application is rebuilt using the modified disassembled code.

2. The computer memory of claim 1, wherein modifying the disassembled code includes adding functionality to cause the mobile application to use an encryption library to encrypt data stored on the mobile device.

3. The computer memory of claim 1, wherein modifying the disassembled code includes adding functionality to cause the mobile application to use a secure application tunnel to communicate with an enterprise resource over a network.

4. The computer memory of claim 1, wherein modifying the disassembled code includes adding functionality that causes a user to be prompted for a password when the mobile application is launched.

5. The computer memory of claim 1, wherein the process further comprises obfuscating at least one modified portion of the mobile application to inhibit reverse engineering of associated security features.

6. The computer memory of claim 1, wherein modifying the disassembled code includes disabling cut and paste functionality.

7. The computer memory of claim 1, wherein modifying the disassembled code includes adding code that enables the enterprise to remotely initiate deletion of data related to the mobile application from a particular mobile device.

8. The computer memory of claim 1 , wherein the process further comprises replacing a reference to a generic launcher of a mobile device operating system in the mobile application with a reference to a secure launcher, such that the mobile The app uses the secure launcher.

9. The computer memory of claim 1, wherein the process further comprises modifying references in the mobile application to cause the mobile application to run in a secure virtual machine separate from an operating system virtual machine.

10. The computer memory of claim 1, wherein analyzing the disassembled code includes examining behaviors that represent potential security risks.

11. The computer memory of claim 1, wherein the utility is configured to generate a score representative of a level of risk associated with the mobile application, the score based at least in part on an analysis of the disassembled code.

12. A computer-implemented method of deploying a pre-existing mobile application for use by members of an enterprise to securely access enterprise resources using a mobile device, the method comprising:

disassemble the executable code of said mobile application;

Analyze disassembled code;

modifying the disassembled code to increase functionality for implementing at least one enterprise security policy, the modification comprising replacing one or more API calls associated with the one or more behaviors to be modified; and

rebuilding the mobile application using the modified disassembled code;

The method is performed by a computer system under the control of executable instructions.

13. The computer-implemented method of claim 12, wherein modifying the disassembled code includes adding functionality to cause the mobile application to use an encryption library to encrypt data stored on a mobile device.

14. The computer-implemented method of claim 12, wherein modifying the disassembled code includes adding functionality to cause the mobile application to use application tunneling to communicate with enterprise resources over a network.

15. The computer-implemented method of claim 12, wherein modifying the disassembled code includes adding functionality that causes a user to be prompted for a password when the mobile application is launched.

16. The computer-implemented method of claim 12, further comprising obfuscating at least one modified portion of the mobile application to inhibit reverse engineering of associated security features.

17. The computer-implemented method of claim 12, wherein modifying the disassembled code includes disabling cut and paste functionality.

18. The computer-implemented method of claim 12, wherein modifying the disassembled code includes adding code that enables the enterprise to remotely initiate deletion of data related to the mobile application from a particular mobile device.

19. The computer-implemented method of claim 12 , further comprising replacing a reference to a generic launcher of a mobile device operating system in the mobile application with a reference to a secure launcher, such that the mobile application Use said secure launcher.

20. The computer-implemented method of claim 12, further comprising modifying references in the mobile application to cause the mobile application to run in a secure virtual machine separate from an operating system virtual machine.

Example implementation

Additional example embodiments of the present disclosure include:

1. A mobile device comprising a user interface, memory and at least one processor configured to run an application stored on said memory, said mobile device comprising:

a web browser installed on said memory of said mobile device; and

an enterprise application installed on said memory of said mobile device, said enterprise application being configured to respond to being executed by launching said web browser and running within said web browser;

Wherein the web browser is configured to regulate operation of the enterprise application according to one or more enterprise policies.

2. The mobile device of claim 1 , wherein the web browser is configured to route communications from the mobile device to enterprise resources through one or more computing devices configured as proxy servers to make content filtering possible.

3. The mobile device of claim 1, wherein the web browser is configured to communicate with an enterprise resource of an enterprise computing system via an application tunnel through a tunnel intermediary of the enterprise computing system.

4. The mobile device of claim 1, wherein the web browser is configured to cause data written to the memory by the software application to be encrypted.

5. The mobile device of claim 1, wherein the web browser is configured to verify access credentials provided by a user via the user interface prior to exposing functionality of the enterprise application to the user.

6. The mobile device of claim 5, wherein the access credentials include a password.

7. The mobile device of claim 1, wherein the web browser is configured to:

receiving or intercepting requests sent by the enterprise application to network resources;

encapsulating at least a portion of the request within one or more headers of an encapsulation protocol; and

The encapsulated portion of the request is sent to a tunnel broker associated with the network resource to establish a communication tunnel with the tunnel broker.

8. The mobile device of claim 7, wherein the enterprise application is configured to receive data via the user interface and generate a request to send the data to a network resource, and wherein the web browser is configured to:

responding to loss of network connectivity by caching at least a portion of said data not yet sent to said tunneling intermediary; and

The restoration of the network connection is responded to by sending the cached data to the tunnel intermediary via the restored network connection.

9. The mobile device of claim 7, wherein the enterprise application is configured to generate a request to send the first data to a network resource, and wherein the web browser is configured to:

compressing the first data;

sending the compressed first data to the tunnel intermediary via the communication tunnel;

decompressing second data received from the tunnel broker via the communication tunnel; and

The decompressed second data is provided to the enterprise application.

10. The mobile device of claim 1, wherein one or more enterprise policies are configured to: Access to network resources by the enterprise application is restricted when requested.

11. The mobile device of claim 1, wherein the one or more enterprise policies include one or more enterprise access rules specifying conditions under which the mobile device is allowed to access enterprise resources.

12. The mobile device of claim 1 , wherein the enterprise application is configured to be based on at least one of time conditions, location conditions, mobile device characteristics, or characteristics of a user of the mobile device by launching the web browser and Runs within the web browser in response to being run.

13. The mobile device of claim 1, wherein the web browser is configured to:

receiving one or more data values of one or more state metrics associated with the mobile device;

detecting an instance of a problem associated with the mobile device at least in part by analyzing the received one or more data values using machine-readable logic rules; and

A machine readable remedial action is performed in response to the detected problem instance.

14. A non-transitory computer readable medium having stored thereon computer readable instructions that, when executed, cause a mobile device to perform operations comprising:

In response to a request received via a user interface of the mobile device to run a software application installed on the mobile device, invoking a web browser and running the software application within the web browser, the web browser configuring enable access to information resources via the Internet; and

Operation of the software application is controlled via the web browser in accordance with one or more enterprise policies to protect enterprise data.

15. The non-transitory computer readable medium of claim 14 , wherein said invoking said web browser and running said software application within said web browser is substantially transparent to a user of said mobile computing device of.

16. The non-transitory computer readable medium of claim 14, wherein controlling the operation of the software application comprises sending communications between the software application and an enterprise resource via an application tunnel.

17. The non-transitory computer-readable medium of claim 14 , wherein controlling the operation of the software application includes routing communications from the mobile device to enterprise resources through one or more computing devices configured as proxy servers to Make content filtering possible.

18. The non-transitory computer readable medium of claim 14, wherein the operations further comprise, via the web browser, causing data written to the memory by the software application to be encrypted.

19. The non-transitory computer readable medium of claim 14, wherein the operations further comprise the web browser prompting a user for a password and verifying the password before running the software application.

20. The non-transitory computer-readable medium of claim 14, wherein controlling the operation of the software application comprises comparing conditions associated with the mobile device with enterprise access data stored on the non-transitory computer-readable medium. The value of the condition in the rule to regulate the mobile device's access to enterprise resources.

21. The non-transitory computer readable medium of claim 14, wherein the operating operations further comprise:

sending a request for an information resource to a server based on information indicative of a Uniform Resource Locator (URL) received by the user interface;

receiving the information resource from the server; and

The information resource is made available via the user interface of the mobile device.

22. A non-transitory computer readable medium having computer readable instructions stored thereon, the executable instructions configured to implement a secure browser configured to at least:

run on a business user's mobile device; and

Execution of at least one enterprise application configured to run within the secure browser is controlled to enforce at least one enterprise security policy to protect enterprise data, wherein the at least one enterprise application is stored on the mobile device.

23. The non-transitory computer readable medium of claim 22, wherein the secure browser is configured to control execution of the at least one enterprise application by one or more of the following:

communicating with an enterprise resource of an enterprise computing system via an application tunnel that uses protocol encapsulation to send data over a network through a tunnel intermediary of the enterprise computing system;

routing communications from the at least one enterprise application to an external computing device through one or more computing devices configured as proxy servers to perform content filtering; and

Access by the mobile device to the at least one enterprise resource is regulated based on comparing a condition associated with the mobile device with a value of a condition in one or more enterprise access rules.

24. The mobile device of claim 26, wherein the secure browser is configured to encrypt data written to the mobile device by the at least one enterprise application.

25. The mobile device of claim 26, wherein the secure browser is configured to verify a password provided by the user prior to exposing functionality of the at least one enterprise application to the user.

26. A mobile device comprising:

a non-transitory memory configured to store a first application and a second application, the first application comprising executable instructions to automatically cause the mobile device to launch the second application in response to the first application being executed, The second application includes executable instructions to run the first application within the second application, and the second application further includes executable instructions to implement one or more enterprise access policies to govern access to at least one enterprise resource access; and

At least one processor in communication with the non-transitory memory, the at least one processor configured to run the first application and the second application.

27. The mobile device of claim 26, wherein the executable instructions implementing one or more enterprise access policies are configured to cause the second application to perform one or more of the following:

communicating with the enterprise resource via an application tunnel through a tunnel intermediary of an enterprise computing system, the enterprise computing system comprising the one or more enterprise resources:

routing communications from the mobile device to the at least one enterprise resource via one or more computing devices configured as proxy servers to perform content filtering; and

regulating access by the mobile device to the at least one enterprise resource based on comparing a condition associated with the mobile device with a value of a condition in one or more enterprise access rules stored on the non-transitory computer readable medium .

28. The mobile device of claim 26, wherein the executable instructions implementing one or more enterprise access policies are configured to cause the second application to cause the Data is encrypted and access credentials provided by the user are verified before the functionality of the first application is made visible to the user.

Example implementation

Additional example embodiments of the present disclosure include:

1. A computer-readable memory and at least one processor configured to execute computer-executable code stored on the computer-readable memory, the mobile device comprising:

a file system comprising a first portion of the computer-readable memory of the mobile device, the file system configured to store enterprise data including enterprise documents;

a second portion of the computer readable memory configured to store private data related to activities of the user of the mobile device outside of the user's role in an enterprise, the second portion logically associated with the the filesystem separation described above; and

an access manager implemented by computer-executable code stored on the computer-readable memory of the mobile device, the access manager configured to store the enterprise documents on the file system such that the enterprise The document is logically separated from the private data, and access to the enterprise document by a software application installed on the mobile device is restricted based on one or more document access policies associated with the enterprise document such that the software application has Restrictions on access to said corporate documents that differ from said private data.

2. The mobile device of claim 1 , wherein the access manager is configured to enable the enterprise to remotely initiate deletion of at least a portion of the enterprise data stored on the file system without modifying stored data. The private data on the second portion of the computer readable memory.

3. The mobile device of claim 1 , wherein the access manager is configured to determine whether an enterprise document received from an enterprise computing system will be based on a mode of communication between the mobile device and the enterprise computing system stored on the file system.

4. The mobile device of claim 3 , wherein the access manager is configured to transfer the received enterprise file stored on the file system.

5. The mobile device of claim 1 , wherein the access manager is configured to prevent the software application from performing at least one of the following operations based on the one or more access policies:

Copy data from said corporate profile;

saving said enterprise document on said mobile device outside of said file system; or

The enterprise document is attached to a communication sent from the mobile device to another computing device.

6. The mobile device of claim 1 , wherein the one or more document access policies restrict access to documents in the file system based on access credentials provided by at least one of the user or the software application. Access to the Enterprise Documentation.

7. The mobile device of claim 1 , wherein the one or more document access policies are based on at least one of characteristics of the software application or a component of the mobile device requesting access to the enterprise document. Access to the enterprise documents in the file system is restricted.

8. The mobile device of claim 1 , wherein the access manager is configured to enable enterprise applications installed on the mobile device to access the enterprise documents stored in the file system and prevent non-enterprise applications from The enterprise documents stored in the file system are accessed.

9. The mobile device of claim 1, wherein the access manager is configured to require that the enterprise documents stored in the file system be encrypted.

10. A method of protecting enterprise data stored on a mobile device, the method comprising:

receiving enterprise data from an enterprise resource via the mobile device;

storing the corporate data in a secure document container of the mobile device such that the corporate data is logically separated from non-corporate data, the secure document container comprising computer readable memory, the stored on the mobile device automatically appear under the control of a running corporate agent; and

Selectively control access to said enterprise data stored in said secure document container of said mobile device according to one or more document access policies, said one or more document access policies for accessing said enterprise A condition of the data, wherein access to the non-enterprise data is independent of the one or more document access policies.

11. The method of claim 10, further comprising deleting the file in the secure document container in response to at least one of an indication that the mobile device is damaged or an indication that the user of the device is no longer associated with the enterprise. of the enterprise data and keep the non-enterprise data unmodified.

12. The method of claim 10, further comprising deleting the enterprise data in response to receiving an indication of one or more of an expiration of a period of time or a location of the mobile device outside a geographic area.

13. The method of claim 10, wherein the condition includes one or more of an expiration of a period of time or a location of the mobile device outside a geographic area.

14. The method of claim 10, wherein the conditions include one or more of the following:

which application stored on the mobile device is requesting access to the enterprise data;

which component of the mobile device is requesting access to the enterprise data; or

Information related to credentials provided with requests to access said enterprise data.

15. The method of claim 10, wherein the enterprise data is received from the enterprise resource via an application tunnel formed between the enterprise resource and an application running on the mobile device, the application tunnel using Protocol encapsulation to send data over the network.

16. The method of claim 15, wherein storing the enterprise data in the secure document container of the mobile device is at least in part responsive to detecting that the enterprise data is received by the application tunnel.

17. The method of claim 10, further comprising preventing the enterprise data stored in the secure document container of the mobile device from being stored outside of the secure document container on the mobile device.

18. A non-transitory storage medium comprising instructions stored thereon executable by a mobile device to perform a process, the process comprising:

creating a secure document container for storing enterprise data within a portion of memory of the mobile device, the secure document container being separate from storage space for storing non-enterprise data;

storing enterprise data received from an enterprise computing system in the secure document container of the mobile device; and

restricting access to the enterprise data stored in the secure document container based on one or more rules specifying conditions for allowing access to the enterprise data stored in the secure document container, wherein Access to the non-enterprise data stored on the mobile device is independent of the one or more rules.

19. The storage medium of claim 18 , wherein the process includes enabling all applications running on the mobile device via an application tunnel formed between the enterprise resource and an application running on the mobile device The application communicates with an enterprise resource of the enterprise computing system, and the application tunnel uses protocol encapsulation to send enterprise data over a network.

20. The storage medium of claim 18 , wherein the process further comprises in response to at least one of detecting or receiving an indication of a condition specified in at least one of the one or more rules, The enterprise data in the secure document container is deleted independently of modifications to other data stored on the mobile device outside of the secure document container.

21. The storage medium of claim 18, wherein the one or more rules are configured to restrict access to the enterprise data based on at least one of geographic restrictions or temporal restrictions.

22. The storage medium of claim 21, wherein the process further comprises deleting at least a portion of the enterprise data from the secure document container when a specified time period expires or the mobile device is located outside a specified geographic area.

23. The storage medium of claim 18, wherein the condition includes verification of access credentials provided by a user of the mobile device.

24. The storage medium of claim 18, wherein the process further comprises obtaining the enterprise data from an application running in a secure virtual machine separate from a virtual machine of the mobile device's operating system .

25. The storage medium of claim 18, wherein the process further comprises obtaining the enterprise data via an application running in a secure browser installed on the mobile device, the secure browser configured to govern the Access to the secure document container is applied.

26. The storage medium of claim 18, wherein the one or more rules are configured to deny access to the enterprise data stored in the secure document container when a non-enterprise application requests access to the enterprise data Access.

Example implementation

Additional example embodiments of the present disclosure include:

1. A mobile device, comprising:

processor and memory;

an enterprise agent installed on the mobile device, the enterprise agent including functionality for enabling enterprise applications installed on the mobile device to securely access resources of the enterprise's enterprise systems, the enterprise agent configured to collect data values for a plurality of state metrics associated with the mobile device;

a plurality of rules stored in said memory, at least some of said rules mapping a status indicated by one or more of said status metric data values to issues indicative of security risks and/or productivity risks associated with said enterprise;

remedial action data stored in said memory, said remedial action data specifying remedial actions to address particular issues, each remedial action corresponding to one or more of said issues;

Wherein the agent is configured as:

programmatically detecting instances of the problem at least in part by analyzing the state metric data values using the rules; and

Responsive to the detected instance of one of the problems by performing one of the remedial actions on the mobile device, the performed remedial action corresponding to the problem of the detected problem instance.

2. The mobile device of claim 1, wherein at least some of the questions indicate a security risk to the enterprise.

3. The mobile device of claim 1, wherein at least some of the issues indicate a productivity risk to the business.

4. The mobile device of claim 1, wherein the agent is further configured to update the rules based on rule information received from the enterprise system.

5. The mobile device of claim 1 , wherein the remedial action comprises remedial action comprising generating a message on a user interface of the mobile device, the message instructing a user of the device to perform an action on the device .

6. The mobile device of claim 5 , wherein the remedial action corresponds to a problem specified as detaching a SIM card from the mobile device, and the action indicated by the message includes detaching the SIM card from the mobile device. Re-engage with said device.

7. The mobile device of claim 5 , wherein the remedial action corresponds to a question specified as disabling password protection on the device, and the action indicated by the message includes activating password protection on the device. password protection.

8. The mobile device of claim 1 , wherein a specific one of the remedial actions corresponds to a problem specified as the device receiving an unauthorized network connection, the specific remedial action comprising preventing the unauthorized Internet connection.

9. The mobile device of claim 1 , wherein specific ones of the remedial actions include one of the following actions:

activate or deactivate features of the mobile device; and

A message is generated on a user interface of the device, the message instructing a user of the device to activate or deactivate the feature of the mobile device.

10. The mobile device of claim 9, wherein:

The features include a camera of the device;

said specific remedial action corresponds to being defined as said equipment being on the premises of said business and said camera being available for use;

The specified remedial action includes one of the following:

deactivate the camera; and

The message is generated on the user interface of the device, the message instructing the user of the device to deactivate the camera.

11. The mobile device of claim 9, wherein:

The characteristics include network connectivity capabilities of the device;

said specific remedial action corresponds to being defined as said device using said network connectivity capability to connect or attempt to connect to an unsecured network;

The specified remedial action includes one of the following:

Terminate or prevent connections to said unsecured networks;

deactivating the network connectivity capability;

generating said message on said user interface of said device, said message instructing said user of said device to terminate said connection to said unsecured network; and

The message is generated on the user interface of the device, the message instructing the user of the device to deactivate network connectivity capabilities.

12. The mobile device of claim 1, wherein specific ones of the remedial actions include one of the following:

uninstall the application from said device; and

The message is generated on the user interface of the device, the message instructing the user of the device to uninstall the application from the device.

13. The mobile device of claim 12, wherein the specific remedial action corresponds to a problem specified as the application not being authorized to be installed on the mobile device.

14. The mobile device of claim 1, wherein at least one of the remedial actions includes at least one of the following:

delete data from said business in relation to said business; and

The message is generated on the user interface of the device, the message instructing the user of the device to delete data related to the enterprise.

15. A non-transitory storage medium having stored thereon executable instructions that direct a mobile device to perform a process, the process comprising:

collecting data values for a plurality of state metrics associated with the mobile device;

receiving and storing a plurality of rules on said mobile device, at least some of said rules mapping a status indicated by one or more of said status metric data values to issues indicative of security risks and/or productivity risks associated with the enterprise,

receiving and storing remedial action data specifying remedial actions to address particular issues, each remedial action corresponding to one or more of said issues;

detecting instances of the problem at least in part by analyzing the collected state metric data values using the rules; and

Responding to the detected instance of one of the problems by performing one of the remedial actions on the mobile device, the performed remedial action corresponding to the problem of the detected problem instance.

16. A system comprising:

a gateway comprising one or more computing devices configured to:

receiving access requests from mobile devices to resources of enterprise systems;

allowing or denying the access request based on configurable criteria; and

recording data related to the gateway's permission and denial of the access request; and an analysis service configured to:

receiving a user determination request comprising mobile traffic data related to communications sent from a mobile computing device to a resource of the enterprise system;

searching recorded data for mobile service data matching said mobile service data received within said user determination request;

determining a mobile device access request received by the gateway, the mobile device access request comprising matching mobile service data;

determining user data contained within said access request comprising said matching mobile service data; and

A reliability score is calculated indicating a level of confidence that the mobile device user corresponds to the user data initiating the communication.

17. The system of claim 16, wherein:

The mobile service data of the communication includes an IP address; and

The matched mobile service data includes an IP address.

18. The system of claim 16, wherein:

the user determination request includes a time of receipt of the communication; and

The analysis service is configured to calculate a reliability score based at least in part on comparing the time of receipt to a time when the gateway received the access request containing the matching mobile traffic data.

19. The system of claim 16, wherein:

the user determination request includes a time of receipt of the communication; and

The analysis service is configured as:

searching recorded data to determine that (1) there is mobile service data matching said mobile service data received within said user determination request and (2) received by said gateway within a time window that includes said time of receipt the total number of access requests for ; and

The reliability score is calculated based at least in part on the total number of access requests.

Example implementation

Additional example embodiments of the present disclosure include:

CLAIMS 1. A system for controlling mobile device access to enterprise resources of an enterprise system, the system comprising:

an enterprise agent running on an enterprise user's mobile device, the enterprise agent configured to cause the mobile device to collect and report mobile device characteristic information, including information about applications installed on the mobile device; and

A mobile device management system configured to store at least (1) said mobile device characteristic information reported by said mobile device, (2) user information about a user of said mobile device, including said user specified in an enterprise and (3) data specifying enterprise access policies of the enterprise, including access policies related to specific enterprise resources, and the mobile device management system includes one or more computing devices;

the mobile device management system is configured to use stored mobile device characteristic information and user information associated with the mobile device in conjunction with the data specifying the enterprise access policy to control access by the mobile device to the enterprise resource Access.

2. The system of claim 1, wherein the mobile device management system is configured based at least in part on whether the mobile device has a Unauthorized applications on the computer to determine whether to allow the mobile device's request to access corporate resources.

3. The system of claim 1 , wherein the mobile device management system is configured to look up the mobile device characteristic information and user information related to the device and by determining the searched mobile device characteristic information and user information Whether to respond to a request from a mobile device to access an enterprise resource is in compliance with at least one enterprise access policy associated with the enterprise resource.

4. The system of claim 3, wherein the request from the mobile device to access the enterprise resource is to form an application tunnel between the enterprise resource and an application running on the mobile device request.

5. The system of claim 3, wherein the mobile device management system is configured to allow or deny the request based at least in part on a role of the user of the mobile device within the enterprise.

6. The system of claim 1, wherein the mobile device management system is configured to allow or deny the request based at least in part on a location of the mobile device as reported by the mobile device via the enterprise agent .

7. The system of claim 1 , wherein the mobile device management system is configured to generate gateway rules based on stored data specifying the enterprise access policy in combination with the mobile device characteristic information and/or user information, and Access is controlled at least in part by providing the gateway rules to a mobile gateway that regulates access of mobile devices to enterprise resources.

8. The system of claim 7, wherein the mobile device management system is configured to generate the at least partly based on at least stored mobile device characteristic information and user information by translating enterprise access policies into lower-level gateway rules. the gateway rules described above.

9. The system of claim 7, further comprising a mobile gateway configured to apply the rules to access requests received from the mobile device, the mobile gateway comprising a mobile gateway configured to run on an enterprise firewall server filter.

10. The system of claim 1, wherein the enterprise agent is capable of performing remedial action on the mobile device in response to determining that an unauthorized application is installed on the mobile device.

11. The system of claim 1, wherein the remedial action includes at least one of: (1) preventing execution of the unauthorized application, and (2) deleting data from the mobile device.

12. The system of claim 1, wherein the mobile device management system is configured to send rules to the mobile device, including rules indicating specific conditions requiring relevant remedial action, and wherein the enterprise agent is configured to The rule is applied on the corresponding mobile device on which the enterprise agent is installed.

13. A non-transitory computer readable medium having stored thereon an agent component configured to be installed on a mobile device of an enterprise user, the agent component configured to at least:

providing one or more authorized applications installed on said mobile device with a secure path to access enterprise resources of an enterprise system;

identifying applications installed on said mobile device;

determining whether any of the applications installed on the mobile device is an unauthorized application; and

Remedial action is performed on the mobile device in response to determining that the unauthorized application is installed on the mobile device.

14. The non-transitory computer readable medium of claim 13, wherein the remedial action includes preventing the unauthorized application from running on the mobile device.

15. The non-transitory computer readable medium of claim 13, wherein the remedial action comprises uninstalling the unauthorized application from the mobile device.

16. The non-transitory computer readable medium of claim 13, wherein the remedial action includes blocking the mobile device from accessing the enterprise system.

17. The non-transitory computer readable medium of claim 13, wherein the remedial action includes deleting from the mobile device information necessary to decrypt encrypted enterprise data stored on the mobile device.

18. The non-transitory computer readable medium of claim 13, wherein the proxy component creates the secure path by using protocol encapsulation to create an application tunnel between a specific authorized application and a specific enterprise resource.

19. The non-transitory computer readable medium of claim 13, wherein the agent component is configured to report device characteristic information to a mobile device management system associated with the enterprise system, including information about application information.

20. The non-transitory computer readable medium of claim 19, in combination with the mobile device management system, wherein the mobile device management system is configured to use information about which applications are installed in conjunction with other information related to the mobile device. information on the mobile device to determine whether the one or more authorized applications' requests for access to enterprise resources are permitted.

21. A non-transitory computer readable medium having stored thereon an enterprise agent configured to be installed on a mobile device of a member of the enterprise, the enterprise agent comprising executable code that directs a mobile The device comes with:

maintaining a repository of mobile device rules, including rules received from mobile device management systems associated with said enterprise, at least some of said mobile device rules specifying conditions and related remedial actions for protecting enterprise resources;

collect mobile device characteristic information, including information about applications installed on said mobile device; and

Applying the mobile device rule on the mobile device, wherein applying the mobile device rule includes using the collected mobile device characteristic information to determine whether the condition exists, and performing a remedial action related to the detected condition.

22. The computer-readable medium of claim 21 , wherein the enterprise agent is configured via application of mobile device rules to determine whether an unauthorized application is installed on the mobile device and to perform remedial action if an unauthorized application is installed .

23. The computer-readable medium of claim 21, wherein the enterprise agent is configured via application of mobile device rules to determine if a SIM card has detached from the mobile device and to perform remedial action in response to detecting such detachment.

24. The computer-readable medium of claim 21, wherein the enterprise agent is configured via application of mobile device rules to instruct a user to activate password protection in response to determining that password protection is disabled on the mobile device.

25. The computer-readable medium of claim 21 , wherein the enterprise agent is configured via application of a mobile device rule to disable the mobile device in response to determining that the mobile device is located in an area where use of a camera is not authorized of the camera.

26. The computer-readable medium of claim 21 , wherein the enterprise agent is configured to maintain on the mobile device a secure document container accessible to authorized applications installed on the mobile device, and is configured to respond to Data is deleted from the secure document container upon detection of a condition representing an enterprise security risk.

27. The computer-readable medium of claim 21 , wherein the enterprise agent is configured to use protocol encapsulation to create an application tunnel for a corresponding authorized application installed on the mobile device to communicate with a specific enterprise resource over a network Communicate securely.

Claims (28)

1. An enterprise system configured to control mobile device access to enterprise resources, the enterprise system comprising: an enterprise resource configured to electronically communicate with a computing device over a communications network; and a gateway comprising computer hardware configured to: receiving a request from a mobile device to access the enterprise resource, the request formatted according to a protocol including characteristics associated with the mobile device; Receive gateway rules from one or more gateway rule providers, each gateway rule includes: one or more values of one or more of said characteristics of said protocol; and an indication of the selected action to take when the request has one or more property values corresponding to one or more property values of the gateway rule; determining whether said request has one or more property values corresponding to one or more property values of any of said gateway rules; and When the request has one or more property values corresponding to one or more property values of one of the gateway rules, based on an indication in the one of the gateway rules, the The indicated action is taken. 2. The computer system of claim 1, wherein the selected action comprises at least one of allowing access to the enterprise resource or denying access to the enterprise resource. 3. The computer system of claim 2, wherein one or more characteristics of the protocol indicate that one or more mobile applications are stored on the mobile device, and wherein the gateway is configured to A mobile application is stored on the mobile device to determine whether to allow or deny the mobile device access to the enterprise resource. 4. The computer system of claim 1, wherein the gateway is configured to deny a request to access the enterprise resource based on an indication of the gateway rule when the mobile device has a particular application stored thereon. 5. The computer system of claim 1, wherein the selected action includes encrypting data transmitted to the mobile device via the gateway. 6. The computer system of claim 1, wherein the selected action comprises preventing the mobile device from receiving email attachments. 7. The computer system of claim 1, wherein the gateway rules include rules having instructions to take different actions when a user of the mobile device has a different role in an enterprise. 8. The computer system of claim 1, wherein the one or more computing devices configured to implement the gateway include at least one of a firewall server, a computing device configured to control a firewall server, or other enterprise resources. 9. The computer system of claim 1, wherein the gateway rules include at least one statically defined rule and at least one rule received from the one or more gateway rule providers. 10. The computer system of claim 1 , wherein the gateway is configured to determine the request at least in part by examining a payload of the request and comparing data from the payload with at least one of the gateway rules Whether there are one or more property values corresponding to one or more property values of any of said gateway rules. 11. The computer system of claim 1, wherein the characteristic of the protocol is associated with a mobile device application stored on the mobile device. 12. The computer system of claim 1, wherein the characteristic of the protocol is associated with a user of the mobile device. 13. A non-transitory computer memory storing a gateway component for controlling mobile device access to enterprise resources, the gateway component comprising executable code that directs a computing system to perform a process, the process comprising: receiving a request from a mobile device to access an enterprise resource, the request formatted according to a protocol including characteristics associated with the mobile device; determining whether the request has one or more property values corresponding to one or more property values of one or more gateway rules, each gateway rule comprising: one or more values of one or more of said characteristics of said protocol; and an indication of an action to take when the request has one or more property values corresponding to one or more property values of the gateway rule; and The action indicated in one of the gateway rules is caused to be taken when the request has one or more property values corresponding to one or more property values of one of the gateway rules. 14. The non-transitory computer storage of claim 13 , wherein the process further comprises determining a relative priority among a plurality of gateway rules having one or more property values corresponding to the one or more property values of the request level, wherein the action taken corresponds to the indication in the gateway rule of the plurality of gateway rules having the highest relative priority of the plurality of gateway rules. 15. A non-transitory computer memory storing executable gateway software for an enterprise computing system, said gateway software comprising: a gateway configuration service configured to receive gateway rules from one or more gateway rule providers, each gateway rule comprising: one or more values of one or more of said characteristics of said protocol; and an indication of an action to take when a request formatted according to the protocol has one or more property values that match one or more property values of the gateway rule; and Gateway filter, which is configured as: receiving requests from mobile devices for access to computer-implemented resources of the enterprise computing system, at least some of the requests being processed according to a protocol including characteristics associated with at least one of the mobile device, a mobile device application, or a mobile device user format; accessing gateway rules received by said gateway configuration service; for each said request formatted according to said protocol, determining whether said request has one or more property values that match one or more property values of any of said gateway rules; and For each of said requests having one or more property values matching one or more property values of one of said gateway rules, said request is allowed or denied based on instructions of said gateway rule. 16. The non-transitory computer storage of claim 15, wherein the gateway configuration service is configured to: periodically sending new gateway rule requests to the one or more gateway rule providers; and New gateway rules are received from the one or more gateway rule providers in response to the new gateway rule request. 17. The non-transitory computer storage of claim 15, wherein the gateway configuration service is configured to receive at least one of the gateway rules from a meta-application. 18. The non-transitory computer storage of claim 15, wherein the action to be taken includes allowing or denying the request. 19. A system for controlling mobile device access policies, the system comprising: a first machine-readable repository of enterprise access policies specifying conditions under which actions are performed in connection with requests from mobile devices to access computer-implemented resources of the enterprise; a second computer-readable repository of attributes of mobile devices associated with the enterprise and/or users associated with the mobile devices; and A computer system running a gateway rule generator configured to: reading the enterprise access policy from the first repository; querying for said attribute of said second repository; and Create gateway rules to enforce the access policy read from the first repository, each of the gateway rules comprising: one or more values of one or more characteristics of a protocol requested by a mobile device for accessing a computer-implemented enterprise resource, at least some of which characteristics correspond to a particular mobile device; and an indication to take action related to a mobile device request formatted according to the protocol when the request has one or more property values matching one or more property values of the gateway rule; Wherein the system is configured to cause the gateway rule to be transmitted to a gateway configured to receive a mobile device request to access the enterprise resource. 20. A computer-implemented method of facilitating communication between a mobile device and an enterprise computing system, the method comprising: Under control of at least one computing device programmed with specific executable instructions: monitoring communications between the mobile device and enterprise resources of the enterprise computing system; detecting that selected ones of said communications between said mobile device and said enterprise resource are formatted according to a protocol; determining a selected action identified in one or more predetermined rules corresponding to a protocol-specific condition of the protocol associated with the selected communication; and The selected action of the selected communication is performed in response to the determination. 21. The computer-implemented method of claim 20, wherein performing the selected action comprises allowing or denying a request from the mobile device to access the enterprise resource. 22. The computer-implemented method of claim 20, wherein the selected action includes allowing a request from the mobile device to access the enterprise resource, and wherein the agreement-specific condition includes a One or more characteristics of the mobile device are associated with the user's particular role within the enterprise. 23. The computer-implemented method of claim 20, wherein the protocol-specific conditions include whether a particular application is installed on the mobile device. 24. The computer-implemented method of claim 20, wherein the protocol-specific conditions include a geographic location of the mobile device. 25. The computer-implemented method of claim 20, wherein the protocol specific condition includes a time associated with the communication. 26. The computer-implemented method of claim 20, wherein the protocol is an electronic mail protocol. 27. The computer-implemented method of claim 20, wherein performing the selected action comprises encrypting data presented from the enterprise resource to the mobile device. 28. The computer-implemented method of claim 27, wherein the encrypted data includes encrypted email attachments.