Patent Publication Number: US-9407640-B2

Title: Assessing a security state of a mobile communications device to determine access to specific tasks

Description:
CROSS REFERENCE TO RELATED APPLICATIONS 
     The present application is a continuation of U.S. patent application Ser. No. 14/034,320, filed Sep. 23, 2013, entitled Assessing the Security State of a Mobile Communications Device; which was a continuation of U.S. patent application Ser. No. 13/742,110, filed Jan. 15, 2013, entitled Enforcing Security Based on Security State Assessment of a Mobile Device, now U.S. Pat. No. 8,561,144; which was a continuation of U.S. patent application Ser. No. 13/314,032, filed Dec. 7, 2011, entitled Providing Access Levels to Services Based Upon Mobile Device Security State, now U.S. Pat. No. 8,365,252; which was a continuation of U.S. patent application Ser. No. 12/255,632, filed Oct. 21, 2008, entitled Secure Mobile Platform System, now U.S. Pat. No. 8,087,067; which is related to the following U.S. patents and co-pending U.S. patent applications: U.S. patent application Ser. No. 12/255,635, filed Oct. 21, 2008, entitled Security Status and Information Display System, now U.S. Pat. No. 8,060,936; U.S. patent application Ser. No. 12/255,626, filed Oct. 21, 2008, entitled System and Method for a Mobile Cross-Platform Software System, now U.S. Pat. No. 8,099,472; U.S. patent application Ser. No. 12/255,621, filed Oct. 21, 2008, entitled System and Method for Attack and Malware Prevention, now U.S. Pat. No. 8,108,933; and U.S. patent application Ser. No. 12/255,614, filed Oct. 21, 2008, entitled System and Method for Monitoring and Analyzing Multiple Interfaces and Multiple Protocols, now U.S. Pat. No. 8,051,480, all of which are hereby incorporated by reference. 
    
    
     TECHNICAL FIELD 
     The present invention relates generally to mobile security, and specifically, to establishing a secure mobile platform system on a mobile communications device to enable secure transactions between the mobile communications device and a service provider, for example, a financial services transaction. 
     BACKGROUND 
     Because of inherent security concerns, mobile communications devices such as mobile phones, PDAs, and smartphones have yet to provide the same breadth of trusted connectivity found on desktop and laptop computer platforms. For example, mobile device users are less likely to access confidential information and/or perform financial transactions with a mobile communications device because such devices are not sufficiently secure. Similarly, service providers such as banks, online payment services and providers of confidential information are less likely to offer access to their services through mobile communications devices. As a result, mobile communications device users are limited by the types and availability of many online services. This is because present methods for securing mobile communications devices do not contemplate many ways users may wish to access online services and online service providers, and are therefore inadequate for providing a secure platform for access to and from online services or service providers. 
     Previous methods for securing mobile communications devices focus on an all-or-nothing approach. Access to or from the mobile device is either granted or not granted based upon whether the device meets certain standards, possesses certain configurations, or adheres to certain policy rules. If the device passes these standards, access is granted. If the device is deficient in any way, access is denied. Such an approach does not consider the types or levels of access required by certain service providers, nor does this approach contemplate the security and repair capabilities of the device itself. Indeed, prior art security systems and methods ignore the recent activity of the mobile device in relation to its overall security state. Furthermore, prior art security systems are typically limited to authorizing access to a given network, making them unsuitable for controlling access and access levels to services and service providers based on a device&#39;s security state. 
     What is therefore needed is a system and method for providing security for mobile communications devices that considers the security state of the device and provides a platform for integrating with services and service providers. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The present invention is illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements, and in which: 
         FIG. 1  is an exemplary block diagram depicting an embodiment of the present invention. 
         FIG. 2  is an exemplary messaging diagram illustrating the flow of communications according to an embodiment of the present invention. 
         FIG. 3  is an exemplary messaging diagram illustrating the flow of communications according to an embodiment of the present invention. 
         FIG. 4  is an exemplary flow diagram illustrating the steps of an embodiment of the present invention. 
         FIG. 5  is an exemplary flow diagram illustrating the steps of an embodiment of the present invention. 
         FIG. 6  is an exemplary flow diagram illustrating the steps of an embodiment of the present invention. 
         FIG. 7  is an exemplary flow diagram illustrating the steps of an embodiment of the present invention. 
         FIG. 8  is an exemplary flow diagram illustrating the steps of an embodiment of the present invention. 
         FIG. 9  is an exemplary flow diagram illustrating the steps of an embodiment of the present invention. 
         FIG. 10  is an exemplary flow diagram illustrating the steps of an embodiment of the present invention. 
     
    
    
     DETAILED DESCRIPTION 
     The present invention is a system and method for creating a customizable secure environment on a mobile communications device in order to permit safe access to and from trusted services. The present invention is not limited to a simple grant or denial of access to the mobile communications device, nor is the present invention limited to network or protocol authorization. The present invention allows mobile communications device users to access services, and allows service providers to access a mobile communications device with the confidence that the mobile communications device, or portions of the mobile communications device, is secure. As used herein, the term “mobile communications device” refers to mobile phones, PDAs and smartphones, but excludes laptop computers, notebook computers or sub-notebook computers. In the present application, mobile communication device may also be referred to as “handset,” “device,” “mobile client” or “client.” Specifically, mobile communications devices include devices for which voice communications are a primary function, but may offer data or other wireless Internet access capabilities, including Bluetooth, infrared, or wireless Internet access. 
     It should be appreciated that the present invention can be implemented in numerous ways, including as a process, an apparatus, a system, a device, a method, or a computer readable medium such as a computer readable storage medium containing computer readable instructions or computer program code, or a computer network wherein computer readable instructions or computer program code are sent over optical or electronic communication links. Applications may take the form of software executing on a general purpose computer or be hardwired or hard coded in hardware. In this specification, these implementations, or any other form that the invention may take, may be referred to as techniques. In general, the order of the steps of disclosed processes may be altered within the scope of the invention. 
     A. The Secure Mobile Platform System 
       FIG. 1  illustrates the various components that may comprise a system embodiment of the present invention. As shown, mobile communications device  101  is connected to a network  121 . Network  121  may include access to different communications protocols, such as a wireless network, a cellular network, Bluetooth, infrared, Wi-Fi or any other network that device  101  may access. Network  121  provides a communications link between device  101  and server  111 . In this fashion, network  121  may carry communications between device  101  and server  111 , or between device  101  and service provider  150 , or between server  111  and service provider  150 . Network  121  may also carry communications between other wireless network or wireless Internet components not pictured in  FIG. 1 . 
     One skilled in the art will appreciate that the present invention comprises a local software component  105  installed on device  101 . In an embodiment, local software component  105  may be responsible for maintaining a secure line of communication with server  111  over network  121 . In addition, local software component  105  may manage requests for access to and from device  101 . As will be discussed further below, managing requests for access may include requests between device  101  and service provider  150 , requests between service provider  150  and server  111 , requests between device  101  and server  111 , etc. In an embodiment, these requests may be managed in whole or in part by server  111 , or may be managed in whole or in part by a remote software component  115  residing on server  111 . Remote software component  115  may be responsible for maintaining a secure line of communication with device  105  or service provider  150  over network  121 . One will appreciate that in the examples discussed herein, reference may be made to communications between device  101 , server  111  and service provider  150 . One skilled in the art will appreciate that these communications may actually be between local software component  105 , remote software component  115  and service provider  150 . Other variations are also possible without departing from this disclosure or the scope of the invention. 
     A person having skill in the art will also appreciate that the system illustrated in  FIG. 1  is merely exemplary, and that additional components or configurations may be incorporated without departing from this disclosure or the scope of the invention. For example, server  111  may be connected over network  121  to multiple mobile communications devices, and/or multiple service providers, and/or other servers. In another example, service provider  150  may host server  111 . Alternatively, service provider  150  may manage server  111 , in which case the services provided by service provider  150  may be hosted by server  111  in addition to the secure mobile platform system provided by server  111 . 
     B. Secure Mobile 
     1. Security State 
     As discussed above, access to various sensitive services is currently neither available nor encouraged on a mobile communications device because the state of its security is often unknown. In order to assure service providers that a device is secure, the present invention provides information on recent security events, if any. Security events include but are not limited to finding possible threats such as exploits, suspicious network traffic, viruses, malware, suspicious system or function calls, authentication failures, etc. Security events may also include hardware or physical issues with the mobile communications device, such as a broken antenna, a cracked screen or case, or a malfunctioning Bluetooth or infrared sensor. Systems and methods for detecting and assessing security events are discussed in co-pending U.S. patent application Ser. No. 12/255,621, entitled System and Method for Attack and Malware Prevention, now U.S. Pat. No. 8,108,933, which is hereby incorporated by reference. 
     Using the system illustrated in  FIG. 1 , the present invention may provide a dynamic assessment of the security of device  101 , also termed device  101 &#39;s “security state” or “state.” An assessment of device  101 &#39;s state may be performed in whole or in part by remote software component  115  on server  111 , in whole or in part by local software component  105  on device  101 , or a combination of the two. One will appreciate that as used herein, the data or information used to determine device  101 &#39;s state may be called “security state information,” and the resulting assessment using this information may be called device  101 &#39;s “state.” Device  101 &#39;s state therefore reflects the its current, recent or historic level of security, and may be a measure, calculation or assessment of the security level of device in light of recent security events or other security state information. Device  101 &#39;s state may also reflect attempts to repair or recover device  101  from harmful security events. 
     An assessment of the device&#39;s state can be made in any number of ways, from logging or counting the number of security events that have recently occurred, to calculating a rating or score based upon weighing the severities of various security events and determining if any events interact. For example, the device may have recently been subjected to any single security event or a set number of security events, at which point the device&#39;s state may be classified as “not secure,” and thereby not be able to access any service provider or be able to be accessed by any service provider. Alternatively, events such as viruses that may be spread to other devices may be considered severe security events, whereas suspicious network traffic may be considered less severe. If such events are scaled based on severity, the device may be scored accordingly or not classified as “not secure” until the score reaches a certain acceptable limit. In either scenario, if the event is repaired, such as by removing or quarantining the virus, deleting the infected email or message, etc., then the state of the device may improve or otherwise change. In this fashion, a device&#39;s state is a dynamic assessment. When a device&#39;s state is referenced, it may either be at the time of reference or a time range. Historical data for a device&#39;s state may be stored on device  101 , on server  111 , or a combination of the two. Similarly, data about the device, including its state and information on recent security events, may be stored on device  101 , on server  111 , or a combination of the two. 
     In an embodiment, a device&#39;s state may be reported or displayed on device  101 , or outputted to server  111 . Systems and methods for displaying state information and other security event-related information are discussed in co-pending U.S. patent application Ser. No. 12/255,635, entitled Security Status and Information Display System, now U.S. Pat. No. 8,060,936, which is hereby incorporated by reference. In an embodiment, a device&#39;s state may be sent to server  111  so that it has the most updated security state information about the device. This security state information may also include the device&#39;s identifier, configuration, settings, information on recent security events, as well as the device&#39;s state. As shown in  FIG. 2 , mobile communications device  101  may send this security data to server  111  over network  121  (step  201 ). In step  202 , server  111  may acknowledge receipt of the security data from device  101 . 
     In an embodiment, server  111  may initiate a request for device  101 &#39;s security state information. This may occur if device  101  has not recently sent its security state information to server  101  in accordance with an update or data synchronization schedule, or if server  111  is communicating with device  101  for the first time. As shown in  FIG. 3 , server  111  may request that device  101  connect to server  111  using a secure protocol (step  301 ). In step  302 , device  101  connects to server  111  over network  121  using the secure protocol indicated by server  111 . In step  303 , server  111  may request device  101 &#39;s security state information, which device  101  transmits in step  304 . In step  305 , server  111  may acknowledge receipt of the security state information. Therefore, as shown in  FIGS. 2 and 3 , the present invention provides for two sources of a mobile communications device  101 &#39;s security state information: the device itself, or on a secure server  111  that communicates with device  101 . This information may be stored in a database, table or other memory on device  101  or server  111 , or may form part of the local software component  105  or remote software component  115 . One will appreciate that other sources of a mobile communications device&#39;s security state information are possible without departing from this disclosure or the scope of the present invention, and that  FIGS. 2 and 3  are merely exemplary and are not intended to limit the present invention. 
     In an embodiment, the process for assessing the security state information for device  101  may be performed by the remote software component  115  on server  111 . In this embodiment, the security state information may be received as raw or partially processed data from device  101 . Server  111  may also store a database of security events and may compare device  101 &#39;s security state information against information in this database in order to assess a severity, score or other determination of device  101 &#39;s state. In an embodiment, this processing and assessment may be performed in whole or in part on device  101 . One will appreciate that other methods for processing security state information or data to assess a mobile communications device&#39;s security state information are possible without departing from this disclosure or the scope of the present invention. 
     In an embodiment, the state of the device  101  may be a function of having installed a particular security software application. In other words, if this application is present on device  101 , then its state may be considered “secure,” and able to request or accept access from a service provider  150 . The application may enable secure communications with the service provider  150  or with a trusted server  111 . Similarly, the state of device  101  may be a function of having access to a specific server  111  or remote software component  115  capable of monitoring activities on the mobile communications device  101 . Access may be granted through the secure server  111 , which then establishes a trusted and secure communications link  121  with mobile device  101 . In this fashion, device  101  is considered secure since communications to and from the device must go through secure server  111 . 
     2. Access 
     In an embodiment, the level of access that service provider  150  has to mobile communications device  101 , and/or the level of access that device  101  has to service provider  150 , may depend upon the device&#39;s state, either at the time access is requested, or based upon historical data for the device&#39;s state, or based upon security state information stored on server  111  for device  101 . One will appreciate that “access” to and by mobile communications device  101  may have different meanings based upon the service provided by service provider  150 . One will also appreciate that the method for granting access or processing requests for access may be performed in whole or in part by service provider  150 , server  111  (on its own or as a proxy server for service provider  150 ), or a remote software component  115  on server  111 . For example, if service provider  150  is a bank or similar financial institution, access may include checking an account balance, viewing previous financial transactions, transferring funds, etc. Access may include all of the activities typically conducted on website accessed by a desktop computer. However, if the mobile communications device  101  is compromised in any manner, and therefore exists in a “not secure” state, then access may be limited or even denied. For example, device  101  may only be able to check an account balance, but not transfer any funds. Alternatively, device  101  may be denied any access to service provider  150 , and/or service provider  150  may not have any access to device  101 . Service provider  150  may customize the level of allowable access based upon given states, or the level of access may be automatically determined by device  101 , local component  105 , server  111  and/or remote component  115 . 
     In another example, service provider  150  may be a web application provider, such as Google® Docs or Zoho®. Alternatively, service provider  150  may be an organization that provides access to online documentation or other sensitive materials over the web. Using the present invention, a service provider  150  may be able to adjust access based upon the state of the device. For example, a device  101  in a severely compromised state may be denied from accessing service provider  150 &#39;s website, or may be limited to only viewing a list of documents or files, or may be limited to viewing portions of the files. A device  101  that is not compromised may be able to access, edit, send, upload or perform other activities on the service provider  150 &#39;s site. One will appreciate that other levels of access and interaction are available based upon device  101 &#39;s state. 
     In another example, access may simply be a response returned following a request for security state information and/or the state of a mobile communications device. A service provider  150  or other third party may already have established communication with a mobile communications device, or the mobile communications device user may already be a user of the services provided by service provider  150 . The present invention may have subsequently implemented, and service provider  150  may wish to check on the status of a mobile communications device. As such, service provider  150  may send a query to device  101  for its security state, or alternatively, service provider  150  may send a query server  111  that maintains updated security state information on device  101 . The present invention provides a way for a service provider  150  to quickly and simply access information on a mobile communication device&#39;s security state without having to install or maintain its own security system network. 
     Various methods for enabling access to mobile communications device  101  are described in detail below. Access may originate as a request from mobile device  101  to service provider  150 . As will be described in more detail below, this request may be passed through server  111 . Alternatively, a request for access may originate from service provider  150 , in which case the request may be directed toward device  101 , or passed through server  111 . In any case, an embodiment of the present invention provides a secure mobile platform system in which the level of interactivity between the mobile communications device  101  and the service provider  150  depends upon the state and security of device  101 . Different examples are outlined further below, and are illustrated in the accompanying figures. However, one skilled in the art will appreciate that the following are merely exemplary, and not intended to limit the scope of the invention in any way. 
     a. Device to Server to Service Provider 
     In an embodiment, the user of a mobile communications device  101  may request access to service provider  150 . As illustrated above, this may be an embodiment where the user attempts to access a banking service or other network based service using software installed on a handset. As shown in  FIG. 4 , this request may be managed by server  111 , which receives the request from device  101  (step  401 ). Server  111  may access a database or other memory to determine whether it has updated security state information for device  101  (step  403 ). If not, then in step  405 , this security state information is obtained from device  101 . Once obtained, the security state for device  101  may be assessed (step  407 ). This assessment may be any method as described previously or incorporated by reference. If the security state is acceptable, then device  101  may have access to service provider  150  (step  413 ). If device  101 &#39;s security state is unacceptable, then access may be limited or denied (step  411 ). As previously discussed, the acceptability of a device&#39;s security state and the level of access to the mobile communications device  101  may be set by the provider of server  111 , the service provider  150 , the manufacturer or provider of device  101 , or other parties responsible for managing the system of the present invention. 
     b. Service Provider to Device 
     In an embodiment, service provider  150  may wish to query server  111  for the security status, security state or to gain security state information for a mobile communications device monitored or managed by server  111 . In an embodiment, service provider  150  may not manage server  111 , but may have a trust relationship with server  111  in order to allow access to the security state of device  101 . In another embodiment, service provider  150  may manage server  111  and have an implicit trust relationship to allow the service to access the security state of the device. In either instance, service provider  150  may have the ability to communicate securely and directly with device  101  without using the server  111  to proxy or otherwise enable the connection. 
       FIG. 5  illustrates a method by which a service provider  150  may request device  101 &#39;s security state. In step  501 , the service provider  150  initiates the request to get mobile communication device  101 &#39;s security state from server  111 . In step  503 , server  111  checks to see if there is updated security state information for device  101 . This may require communicating with a database or memory store storing such information, or communicating directly with device  101 . If the information is not updated, then in step  505 , server  111  obtains the security state information from device  101 . Once this information is obtained, then in step  507 , server  111  determines the state of device  101 . In step  509 , device  101 &#39;s state may be stored in a server  111  managed by service provider  150  or stored in a database or memory store accessible by service provider  150 . This method may provide service provider  150  with a continuously updated overview of the security state of a mobile communications device  101  accessed by service provider  150 . 
     In an embodiment, the server  111  may provide access to the security state of a device  101  through an API over a protocol such as HTTP. This API may have encryption and require authentication for a service provider  150  to retrieve security state information corresponding to a mobile communications device. As such, service provider  150  may perform step  501  of  FIG. 5  by using the API. Alternatively, the server  111  may access an API hosted by service provider  150  whenever the security state of device  101  changes to update the service provider  150  with the newest state information. 
     As such, the present invention provides a simple implementation by which service providers can be updated on the security state of a device  101  monitored by server  111 . This provides a significant advantage over prior art that requires installation of a security system or portions of a security system, and delegates security monitoring to a server specifically tailored for the task. 
     c. Service Provider to Server to Device 
     In an embodiment, service provider  150  may request access to device  101  through server  111 . In other words, server  111  may be responsible for processing or proxying requests for access based upon device  101 &#39;s state. If device  101  is in an acceptable state, server  111  may provide the desired access to device  101  by service provider  150 . This is shown in  FIG. 6 . 
     In step  601 , server  111  receives a request from service provider  150  to access device  101 . One will appreciate that server  111  may be responsible for proxying access to device  101  from service provider  150 , or service provider  150  may be allowed to access device  101  directly. In step  603 , server  111  may check to see if the security state information for device  101  is up to date. Alternatively, this check may be performed by service provider  150  before or after it passes the request for device  101  to the server  111 . If the security state information for device  101  is not updated, then this information is obtained from device  101  (step  605 ). In step  607 , server  111  assesses device  101 &#39;s state based upon the information received. This step may also be performed by the service provider  150 . Once device  101 &#39;s state is determined, server  111  or service provider  150  or a combination of the two may determine whether device  101 &#39;s security state is acceptable (step  609 ). If not, access may be limited or denied (step  611 ). If it is acceptable, then service provider  150  may have access to device  101  (step  613 ). 
     In an embodiment, a variation of the above steps may be performed when service provider  150  directly requests access to device  101 , but device  101  passes the request to server  111 . In this embodiment, the steps of checking whether security state information for device  101  is updated (step  603 ), obtaining device  101 &#39;s security state information (step  605 ), assessing device  101 &#39;s security state (step  607 ) then granting (step  613 ) or denying (step  611 ) service provider  150  access to device  101  may be all be performed by server  111 . 
     Similarly, in an embodiment, service provider may directly request access to device  101 , and device  101  may itself determine whether it is in an acceptable state. This may require that device  101  run a separate process that oversees the security state of the device  101 . If the process is not kept separate from device  101 &#39;s other running functions, then it may be compromised by malware or other security event that tricks device  101  into presenting that it is more secure than it may in fact be. One skilled in the art will appreciate that other methods for self-monitoring device  101 &#39;s security state are possible. 
     d. Conditional Access to Device 
     As mentioned previously, service provider  150  may be granted limited or conditional access depending upon the state of device  101 . Such things as recent security events, unsuccessfully quarantined viruses, or hardware issues may prevent normal access to device  101 . As such, the present invention contemplates instances where access may be limited in order to protect the overall secure mobile platform system and prevent contamination of other system components. In an embodiment, limited or conditional access may be decided by server  111  which may proxy the request for access to or from device  101  or may process the request locally. One will appreciate that if device  101  is attempting to access service provider  150 , but is not in a sufficiently secure state, the request may be denied without notifying service provider  150  of the attempted access. 
     For example, in  FIG. 7 , step  701  illustrates that service provider  150  may receive a request to access its services from device  101 . This request may originate directly from device  101 , or through server  111 . Alternatively, server  111  may receive the request to access service provider  150  from device  101 . In step  703 , service provider  150  or server  111  checks to see if the security state information for device  101  is up to date. If not, then in step  705 , this information is obtained from device  101 . Once obtained, server  111  may determine the security state for device  101  (step  707 ). If device  101 &#39;s state is unacceptable, then access to service provider  150  will be denied (step  711 ). In such a case, if server  111  has determined that device  101 &#39;s state is unacceptable, service provider  150  may never receive device  101 &#39;s request for access. However, if device  101 &#39;s state is acceptable, then there may be an additional check to ensure that the state is acceptable for the specific service request or task requested by device  101  (step  713 ). If device  101 &#39;s state is acceptable for the requested task, then in step  717 , access is granted. If device  101 &#39;s state is unacceptable, then in step  715 , then access is denied. As such, in  FIG. 7 , device  101  may gain access to service provider  150 , but may be denied from performing certain tasks (step  715 ). In the previous examples, this may be an instance where device  101  has access to checking an account balance (step  717 ), but transferring funds may be denied (step  715 ) because of a recent or present security event that has affected device  101 &#39;s state. 
     Similarly, conditional access and communications between service provider  150  and device  101  may be primarily managed by server  111 . In this embodiment, server  111  provides device  101 &#39;s security state information to service provider  150 , rather than device  101  providing its security state information to service provider  150 , as shown in  FIG. 7 . This is illustrated in  FIGS. 8 and 9 . 
     In  FIG. 8 , service provider  150  receives a request for access from device  101  (step  801 ). However, in step  803 , service provider  150  obtains device  101 &#39;s security state information from server  111 , rather than from device  101  (step  705  of  FIG. 7 ). Server  111  or service provider  150  may then determine whether device  101 &#39;s state is acceptable for further access to service provider  150 . If device  101 &#39;s state is acceptable, then access is granted (step  807 ). If not, then device  101 &#39;s access to service provider  150  is denied. 
       FIG. 9  illustrates steps similar to  FIG. 8 . In step  901 , service provider  150  receives a request for access from device  101 . Service provider  150  then obtains the security state information for device  101  from server  111  (step  903 ). If service provider  150  (or server  111 ) determines that device  101  is not in an acceptably secure state, then further access is denied (step  907 ). If, however, device  101  is acceptably secure, then there may be an additional assessment to determine whether device  101 &#39;s state is acceptably secure for the particular service request (step  909 ). If so, then access to service provider  150  for that particular request is granted (step  913 ). If not, then access to service provider  150  for that particular request is denied. 
       FIG. 10  illustrates steps for conditionally accessing device  101  by service provider  150  depending on the state of device  101  as provided by server  111 . This embodiment may occur after service provider  150  has established a trusted relationship with server  111 , which in turn has established trusted relationships with device  101 . Service provider  150  may interact with server  111  to check device  101 &#39;s state before accessing device  101 . In step  1001 , service provider  150  requests device  101 &#39;s security state from server  111 . Service provider  150  (or server  111 ) determines whether device  101  is acceptably secure. If not, then service provider  150  will not access device  101  (step  1005 ). If device  101  is acceptably secure, then service provider  150  may access device  101  (step  1007 ). 
     One will appreciate that any of steps of the methods described above and depicted in the accompanying drawings may be performed in a different order or combined. For example, in  FIGS. 7, 8 and 9 , the steps of determining whether device  101  is acceptably secure for a specific task or request for access may be combined with the steps for determining whether device  101  is acceptably secure enough to access service provider  150 . Other variations are possible without departing from this disclosure or the scope of the present invention. 
     C. Counteracting Cyber-Terrorism 
     One will appreciate that the present invention is directed to creating and implementing a secure mobile platform system that provides limited to complete access to one or more mobile communications devices depending upon the security state of the one or more devices. While this may be practical and important in most daily business transactions, it is especially important in the context of national security. While mobile devices may not usually be used for accessing sensitive or potentially classified information, at present, there is little to stop someone from attempting such access, especially since many mobile devices today are Internet, intranet and enterprise-enabled. As such, terrorist organizations have many available points of entry into supposedly secure systems simply by hijacking the mobile devices connected to those systems. Similarly, terrorist organizations can use non-secure systems to capture and control connected mobile communications devices. The present invention provides a secure defense against such attacks by continuously and dynamically monitoring the security state of all connected mobile devices. If an attack is underway, the system will be aware of such attacks and may possess the means to contain and classify the attack. Similarly, the mobile platform system will be aware if a mobile device is removed from contact, since the system will no longer be receiving updates on the device&#39;s security state. Because the present invention provides a gateway system for evaluating the security state of a device before granting access to or from the device, device providers as well as service providers can rest assured that they are protected against cyberattacks—on their systems. 
     The descriptions above illustrate how the present invention provides a secure platform for mobile communications devices, whereby the security state of the device affects the level and types of services accessible by the device. Similarly, the security state of the device determines the level and types of services that may access the device. One will appreciate that in the description above and throughout, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be evident, however, to one of ordinary skill in the art, that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form to facilitate explanation. The description of the preferred embodiments is not intended to limit the scope of the claims appended hereto.