Abstract:
Techniques for protecting mobile applications are presented. A user&#39;s mobile device is provisioned and proxied over a cloud environment with enterprise policy enforced in that cloud environment. Enterprise applications run on the mobile device within the cloud environment. Administrative reporting and control occurs within the cloud environment and the enterprise applications establish connections to, authenticate to, and communicate with remote enterprise services via the provisioned cloud environment.

Description:
RELATED APPLICATIONS 
       [0001]    The present application is co-pending with, is a non-provisional filing of, and claims priority to Provisional Application No. 61/670,516 filed on Jul. 11, 2012; entitled: “Techniques for Protecting Mobile Applications,” the disclosure of which is incorporated by reference herein in its entirety. 
     
    
     BACKGROUND 
       [0002]    As mobile devices are being used as a basic part of the corporate Information Technology (IT) solutions, security is suffering. One of the reasons that security is such a problem is because the corporate IT department has little or no control of the mobile device. The company cannot control: what other applications may be running on the mobile device, the environment of the mobile device, and potential theft of the device; such circumstances expose the security of network data that the user&#39;s mobile device has legitimate access to. 
         [0003]    Making the problem harder to solve, most of the time the mobile device is not actually owned by the company, but is owned and controlled by the employee of the company. This is called the “Bring Your Own Device” (BYOD) model and is becoming a new standard for mobile devices. Today, BYOD situations are most prevalent with the tablet style iPad® devices and exasperates device management, which can be done by the company. So, the user is the owner of the device; and the user typically only authorizes control by the company to company-based applications or data, but the user does allow the company any other control or access to the user&#39;s mobile device. 
         [0004]    The situation becomes a catch-22 situation because the company is the owner of the data and therefore does not want its data used on an insecure platform or device, which the company cannot control. This creates a “mobile standoff,” which limits how mobile devices are used within the company and results in corporate modifications to the employee policy manual defining “corporate acceptable” usage of mobile devices in the corporations attempt to control behavior of employees in order to give the corporate some sense of control over the security hole created when mobile devices of employees are given access to potentially sensitive corporate data. 
       SUMMARY 
       [0005]    Various embodiments of the invention provide techniques for protecting mobile applications. Specifically and in one embodiment, a mobile application agent is registered over a network to interact with remote enterprise services that are accessed over the network from a mobile device using a remote mobile application that interacts with the mobile application agent. Next, a secure connection is established with the remote mobile application and the secure connection is used for accessing features of the remote mobile application, via user interaction with the mobile application agent. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0006]      FIG. 1  is a diagram depicting an example architecture of components used for protecting mobile applications, according to the techniques presented herein. 
           [0007]      FIG. 2A  is a diagram of a method for protecting mobile applications from a user access processing perspective, according to embodiments presented herein. 
           [0008]      FIG.2B  is a diagram of another method for protecting applications from a user access processing perspective, according to embodiments presented herein. 
           [0009]      FIG. 3A  is a diagram of another method for protecting mobile applications from an enterprise or corporate processing perspective, according to embodiments presented herein. 
           [0010]      FIG. 3B  is a diagram of still another method for protecting mobile applications from an enterprise or corporate processing perspective, according to embodiments presented herein. 
           [0011]      FIG. 4  is a diagram of a mobile application access system, according to embodiments presented herein. 
       
    
    
     DETAILED DESCRIPTION 
       [0012]    Various components are shown herein and below, each of these components are implemented on and/or reside within a non-transitory computer-readable storage medium as executable instructions, which are executed by a processing device having one or more processors and memory. The processors are specifically configured and programmed to process the executable instructions from the non-transitory storage medium and/or from the memory. The components also have access to a network and the network may be wired, wireless, or a combination of wired and wireless. 
         [0013]    A “mobile device” is a device having one or more processors, memory, and/or non-transitory computer-readable storage. Some example mobile devices include, by way of example only: a phone, a laptop, a tablet, a wearable processing device, and the like. 
         [0014]    The embodiments herein take a different approach to solving the problem associated with granting network access to remote data or resources from a user-owned and controlled mobile device. The embodiments herein do not try to build a safe processing environment on the mobile device by encrypting the data used by the device, or by sandboxing the application on the device. 
         [0015]    Rather, the novel approaches herein build a new processing environment for the user-controlled and owned mobile device applications in a “trusted” server space, which is under the complete control of the company not the user. 
         [0016]    This is achieved by using a device emulator running on a server machine as a Virtual Machine (VM). In fact, most mobile devices already have an emulation program environment that can run on platforms other than the native device platform or the mobile device. The emulation program environment is often used for: testing, presentations, or development. However, here any such emulation program environment is used to access corporate or enterprise mobile apps from a server and/or cloud environment using a user&#39;s mobile device as a form of a thin client. 
         [0017]    The techniques herein extend a mobile device&#39;s native emulation environment by separating the input and output from the emulation environment and then using the mobile device as the output screen in place of the emulation screen and using mobile input from the mobile device as input for the emulation environment. Input is not limited to a keyboard and can include many of the mobile device&#39;s existing input controls such as: Global Positioning Satellite (GPS), motion, camera, voice and others. The output of the emulation can also use the full output of the mobile device such as: sound, screen, vibration, and other output media. 
         [0018]      FIG. 1A  is a diagram depicting an example architecture  100  of components used for protecting mobile applications, according to the techniques presented herein. 
         [0019]    The architecture  100  includes a Virtual Machine (VM), which includes: a platform emulator to remotely run an enterprise mobile application from the VM on behalf of a mobile device, an output emulator, an input emulator, and a secure access link over a network connection to the user&#39;s mobile device. 
         [0020]    The architecture also includes a mobile device having a mobile Operating System (OS), a mobile interface library, and a mobile user interface. The mobile user interface (UI) acts as a thin client on the mobile device to access the secure link and process the enterprise or corporate mobile app remotely on the server using the VM. 
         [0021]      FIG. 2A  is a diagram of a method  200  for protecting mobile applications from a user access processing perspective, according to embodiments presented herein. The method  200  is implemented as instructions that are programed within memory of a mobile device of a user or that are programmed and available from a non-transitory computer readable storage medium. 
         [0022]    At  210 A, the cloud mobile application is installed and initiated on a user&#39;s mobile device (laptop, phone, wearable device, etc.). At this point in time the cloud mobile application performs some discovery work for the VM server that actually runs a secure version of an enterprise application for an enterprise. 
         [0023]    At  220 A, the cloud mobile application reads local services available on the mobile device and makes a connection to the VM/Server cloud mobile application from the mobile device. Once the connection is established, the user&#39;s mobile device acts as a thin client and the actual mobile application remains under the control of the enterprise from the remote networked server/cloud/VM. 
         [0024]    At  230 A, the cloud mobile application reports to the cloud server device on the integrity discovered for the mobile device, such as is the mobile device insecure and jail broken and other metrics can be configured to be discovered and reported as well. 
         [0025]    In an example case, at  240 A, a check is made to ensure that the mobile device is not in fact jail broken. If the mobile device is jail broken then processing can stop and/or warning messages can be issued to the user to repair the device to a version of the OS that is not jail broken. 
         [0026]    Assuming that the mobile device is not jail broken, at  250 A, the remote cloud mobile application is executed on behalf of the user and the mobile device from the server/cloud/VM, which remains under the control of the enterprise to which the mobile cloud application is associated. 
         [0027]    In an embodiment, at  260 A, a check is made to determine what type of information the remote mobile cloud application needs from the thin client cloud mobile application (mobile device agent). Some information that the agent can report can include service information, geographic position of the device, and the like. 
         [0028]    At  270 A, the agent cloud mobile application from the mobile device provides the information back to the cloud mobile local services layer (the information gathered in  260 A). 
         [0029]    At this point, the information is used and interactions occur between the agent application and the remote application so as to provide services to the user via the mobile device of the user. Eventually, the cloud mobile application agent on the mobile device is exited or terminated normally by the user, at  280 A. 
         [0030]      FIG.2B  is a diagram of another method  200 B for protecting applications from a user access processing perspective, according to embodiments presented herein. The method  200 B (herein after referred to as “mobile application agent”) is programmed as executable instructions within memory or a non-transitory computer-readable storage medium for execution on one or more processors of a network. The network can be wired, wireless, or a combination of wired and wireless. 
         [0031]    The method  200 B provides another and in some ways enhanced perspective of the method  200 A, which executes on a user&#39;s mobile device (laptop, phone, tablet, wearable device, and the like). 
         [0032]    At  210 B, the mobile application agent registers a mobile application agent over a network to interact with remote enterprise services that are accessed over the network from the user&#39;s mobile device using a remote mobile application that interacts with the mobile application agent. The mobile application agent acts as a thin client on the mobile device and the enterprise&#39;s mobile application is proxied on a remote server or cloud processing environment on behalf of the user via interactions with the mobile application agent. 
         [0033]    According to an embodiment, at  211 B, the mobile application agent provides employee credentials when registering the mobile application agent. The employee credentials can be interactively provided by the user of the mobile device or can be encrypted and stored and accessible to the mobile application agent to automatically provide on behalf of the user once the user provides a different form or authentication, such as a password. 
         [0034]    At  220 B, the mobile application agent establishes a secure connection with the remote mobile application. That is, a secure connection either via a secure protocol or via an insecure protocol using encryption is established between the mobile application agent and the remote mobile application. 
         [0035]    In an embodiment, at  221 B, the mobile application agent uses custom encryption during the secure communication between the mobile device and the remote mobile application. So, custom encryption can be used to customize the secure connection between the mobile application agent of the mobile device and the remote mobile application being proxied from a server/VM/cloud environment on behalf of an enterprise. 
         [0036]    At  230 B, the mobile application agent uses the secure connection to access features of the remote mobile application via user interaction with the mobile application agent. So, an enterprises mobile application (remote mobile application) is proxied and executed in a remote environment that is entirely separate from the user&#39;s mobile device. This allows the enterprise to continue to maintain control of the mobile application and enforce security while permitting a user to use his/her own device to access the mobile application via the mobile application agent. 
         [0037]    According to an embodiment, at  231 B, the mobile application agent operates the mobile application agent as a thin client on the mobile device where features of the remote mobile application are proxied on an enterprise cloud processing environment on behalf of the mobile application agent. 
         [0038]    In an embodiment, at  240 B, the mobile application agent provides an input interface to transfer input date that is provided from the user to the remote mobile application for processing. 
         [0039]    Continuing with the embodiment of  240 B and at  241 B, the mobile application agent provides an output interface to communicate output data on the mobile device that is produced by the remote mobile application. 
         [0040]    In one scenario, at  250 B, the mobile application agent sends metrics dynamically gathered from the processing environment of the mobile device. The metrics defined by a profile or a policy. 
         [0041]    Continuing with the embodiment of  250 B and at  251 B, the mobile application agent sends some of the metrics for initially establishing the connection to the remote mobile application. 
         [0042]    In another case of the embodiment of  250 B and at  252 B, the mobile application agent sends some of the metrics based on user interaction with the remote mobile application via the mobile application agent. 
         [0043]    According to an embodiment, at  260 B, the mobile application agent wipes any information related to the connection from memory or storage of the mobile device when the connection terminates. 
         [0044]    In still another situation, at  270 B, the mobile application agent removes the mobile application agent when instructed by the remote mobile application indicating the mobile device is being de-provisioned for access. This can occur for a variety of reasons such as employee termination, acting outside the scope of security polices, and the like. 
         [0045]      FIG. 3A  is a diagram of another method  300 A for protecting mobile applications from an enterprise or corporate processing perspective, according to embodiments presented herein. The method  300 A is programmed as executable instruction within memory and/or a non-transitory computer-readable storage medium for execution on one or more processors of a server or cloud processing environment (collections of servers). 
         [0046]    At  310 A, a detection is made that a user is joining an enterprise and at  315 A a check is made to determine that the user wants to register and use a mobile device that belongs to that user (tablet, laptop, phone, wearable device, and the like). It is assumed that the user wants to register and use the mobile device in the illustration of the  FIG. 3A . 
         [0047]    At  320 A, an enterprise administrator logs into the cloud platform that processes the method  300 A. 
         [0048]    At  330 A, mobile custom software for the cloud mobile application is provisioned. 
         [0049]    At  340 A, enterprise security policy is applied to the instance of the cloud mobile application that was provisioned in the cloud for use by the mobile device. 
         [0050]    In an embodiment, at  350 A, an email is sent to the user regarding the user&#39;s cloud mobile connect application. So, details on the mobile device&#39;s agent is sent to the user, the agent runs on the mobile device and interacts with the remote cloud mobile application, which remains under the control of the enterprise to which it is distributed. 
         [0051]    At  360 A, the mobile device&#39;s actions are monitored and can be adjusted using enterprise tools on the server/VM/cloud that is remote from the mobile device. 
         [0052]    In some situations, at  365 A, the user may quit the enterprise, in which case, at  370 , the server/VM/cloud mobile application available to the user via the agent on the mobile device is de-provisioned and any then-existing connection between the remote mobile application and the mobile device agent can be suspended. 
         [0053]      FIG. 3B  is a diagram of still another method  300 B for protecting mobile applications from an enterprise or corporate processing perspective, according to embodiments presented herein. The method  300 B (hereinafter referred to as “cloud application”) is programmed as executable instructions within memory of a non-transitory computer-readable storage medium for execution on one or more processors of a server/VM/cloud environment. 
         [0054]    The cloud application presents another and in some ways enhanced perspective of the method  300 A. 
         [0055]    At  310 B, the cloud application receives a connection request to a mobile application from a mobile agent of a mobile device. 
         [0056]    According to an embodiment, at  311 B, the cloud application sends specific connection details to the user to facilitate a connection. 
         [0057]    Continuing with the embodiment of  311 B and at  312 B, the cloud application sends the details via one of: a text message to the mobile device and an email to an email address of the user. 
         [0058]    At  320 B, the cloud application authenticates the user of the mobile agent and the mobile device for access to the mobile application. 
         [0059]    At  330 B, the cloud application provisions features and resources for use by the mobile agent. 
         [0060]    At  340 B, the cloud application configures policies in response to the authenticated user and the mobile device. 
         [0061]    According to an embodiment, at  341 B, the cloud application determines how to perform the provisioning based on an authenticated identity assigned to the user. 
         [0062]    At  350 B, the cloud application proxies the mobile application for the mobile device while enforcing policies based on interactions driven from the mobile agent of the mobile device. 
         [0063]    In an embodiment, at  360 B, the cloud application disconnects a connection between the mobile agent and the mobile application based on a detected terminated event. 
         [0064]    Continuing with the embodiment of  360 B and at  361 B, the cloud application recognizes the terminated event as one or more of: a terminated user, a user acting beyond an authorized scope according to the policies, and actions taken by the user indicating a risk of a security breach. 
         [0065]      FIG. 4  is a diagram of a mobile application access system  400 , according to embodiments presented herein. The mobile application access system  400  includes a variety of components each of which are implemented as executable instructions within memory or a non-transitory computer-readable storage medium for execution on processors of multiple devices. 
         [0066]    The mobile application access system  400  implements, inter alia, the methods  200 A,  200 B,  300 A, and  300 B. 
         [0067]    The mobile application access system  400  includes a cloud-based application  401  and a mobile device-based agent  402 . 
         [0068]    The mobile application access system  400  includes a first server or first cloud processing environment having memory programmed with the cloud-based application  401 . Example processing associated with the cloud-based application  401  was presented above with respect to the methods  300 A and  300 B of the  FIGS. 3A and 3B , respectively. 
         [0069]    The cloud-based application  401  is configured to be proxied from the first machine on behalf of a user of the second machine based on direction supplied via the mobile device-based agent  402 . 
         [0070]    According to an embodiment, the first machine is one of: a VM on a server, the server, and a cloud processing environment. 
         [0071]    The mobile application access system  400  includes a mobile device of a user having memory programmed with the mobile device-based agent  402 . Example processing associated with the mobile device-based agent  402  was presented above with respect to the methods  200 A and  200 B of the  FIGS. 2A and 2B , respectively. 
         [0072]    The mobile device-based agent  402  is configured to interact with the cloud-based application  401  to act as a thin client on the second machine on behalf of the user. 
         [0073]    According to an embodiment, the second machine is one of: a phone, a tablet, a laptop, and a wearable processing device. 
         [0074]    The techniques taught herein and above provide a variety of novel benefits for example:
       1) personal applications and enterprise applications are not mixed up;   2) enterprises are not required to manage the end user&#39;s device, so the user has more privacy in using his/her own device for other purpose;   3) managing cloud mobile is efficient and easy, the enterprise has to deal with cloud infrastructure anyway, so there is more control of enterprise applications and enterprise data;   4) cloud mobile can be accessed from any device, so there i s more flexibility in using it, for instance the user can access from a mobile device or a tablet or from a desktop browser, switching between devices is simple and one can share session data between devices;   5) cloud mobile can be configured according to an enterprise compliance policy without compromise and at the same time giving more freedom to a user&#39;s personal device; and   6) more security in accessing network enterprise information with no worries should a user&#39;s mobile device be lost since no enterprise information is stored on that personal device.       
 
         [0081]    The above description is illustrative, and not restrictive. Many other embodiments will be apparent to those of skill in the art upon reviewing the above description. The scope of embodiments should therefore be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.