Patent Description:
Mobile device management (MDM) is a way to ensure employees stay productive and do not breach corporate policies. Many organizations control activities of their employees using MDM products/services. MDM primarily deals with corporate data segregation, securing emails, securing corporate documents on devices, enforcing corporate policies, and integrating and managing mobile devices, including laptops and handhelds of various categories. By controlling and protecting the data and configuration settings of all mobile devices in an organization's network, MDM can reduce support costs and business risks. <CIT> describes a device policy manager for mobile devices comprising a unified interface component and a policy handler component. The policy manager manages policy configuration requests from multiple policy sources, and resolves conflicts between policy values from different sources. <CIT> described a method for developing upgrade software for systems with multiple available versions of software. A state machine is used to access one or more groups of commands which enable the transition from one version of the software to an updated version.

Embodiments described herein are directed to implementing compliance settings by a computing device for bringing the computing device into compliance with a configuration scenario. For instance, a computing device may receive, from a server, configuration information describing compliance settings for implementing by the computing device to bring the computing device into compliance with a configuration scenario. Moreover, the computing device may identify a state machine indicated by the configuration information (e.g., by an identifier) that describes a configuration process for implementing the compliance settings. The state machine may be executed to configure the computing device with the compliance settings. When executing the state machine, payloads included in the configuration information along with dependencies may be processed in the order as dictated by the state machine, to configure the computing device.

Further features and advantages of the invention, as well as the structure and operation of various embodiments of the invention, are described in detail below with reference to the accompanying drawings. It is noted that the invention is not limited to the specific embodiments described herein. Such embodiments are presented herein for illustrative purposes only. Additional embodiments will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein.

The accompanying drawings, which are incorporated herein and form a part of the specification, illustrate embodiments and, together with the description, further serve to explain the principles of the embodiments and to enable a person skilled in the pertinent art to make and use the embodiments.

A typical construct of today's mobile device management (MDM) process for an enterprise uses a MDM server to be responsible for executing and monitoring mobile device configurations, storing massive amounts of data, and performing continuous error checks and preventative maintenance. Such functions may be performed for large numbers of devices for the enterprise, including hundreds, thousands, tens of thousands, millions, hundreds of millions, and even greater numbers of devices. As a result, the server churns countless 'computing calories' (e.g., uses a large amount of processing power) to determine if all of the mobile technology resources of the enterprise's network are configured correctly, functioning within the confines of security and other important protocols, and implementing and complying with updates.

This means that the server is encumbered by having to communicate with many individual mobile devices on the enterprise's network and to ultimately oversee the configuration process and reporting needs. Scalability proves very challenging for an enterprise in this scenario, simply given the number of devices, sheer traffic, and configuration volume. In other words, the server has a tremendous amount of work to manage. Moreover, this configuration process may also be fraught with otherwise preventable errors due to the un-streamlined and device-specific nature of configuration enforcement.

These limitations can ultimately be remedied by changing the server's involvement in the device management process. For example, in embodiments, the server may experience greater productivity by requiring the mobile device to conduct its own configuration. In the embodiments described herein, the server may supply the configuration details to the mobile device and the configuration process may be driven by the mobile device by acting as a generalized state machine. These and further embodiments are described in additional detail with respect to <FIG>, as follows. Note that embodiments described herein are applicable to any operating system/computing platform, such as Apple iOS®, and Google Android™ and that references herein to Microsoft® Windows®, and/or component thereof, are for descriptive and illustrative purposes only, and are not to be considered limiting.

<FIG> is a block diagram of a compliance enforcement system <NUM> for implementing compliance settings by computing devices for bringing the computing devices into compliance with configuration scenarios, in accordance with an example embodiment. As shown in <FIG>, system <NUM> includes a server <NUM>, a computing device <NUM>, and one or more data stores <NUM> communicatively coupled via an enterprise network <NUM>. Server <NUM> includes a compliance engine <NUM>. Computing device <NUM> includes a compliance agent <NUM>. Although a single computing device <NUM> is shown, any number of computing devices may be present in system <NUM> that have compliance settings provided by server <NUM>, including tens, hundreds, thousands, tens of thousands, millions, hundreds of millions, and greater numbers of computing devices. Data store(s) <NUM> may comprise one or more physical memory and/or storage device(s). Data store(s) <NUM> may be any type of physical memory and/or storage device that is described herein, and/or as would be understood by a person of skill in the relevant art(s) having the benefit of this disclosure. Enterprise network <NUM> comprises a private computer network established by an enterprise for the purposes of interconnecting enterprise devices (e.g., computing device <NUM> and further computing devices not shown) at one or more enterprise locations to other enterprise devices and to enable enterprise devices to access and/or share computing resources.

Computing device <NUM> is a device utilized by or otherwise accessible to one or more members (e.g., employees) of an enterprise. As used herein, the term "enterprise" broadly refers to any of a wide variety of organization types, including businesses, non-profit organizations, and government agencies. Users of computing device <NUM> may be referred to herein as "enterprise users" or simply "users". Computing device <NUM> may comprise, for example and without limitation, a desktop computer, a laptop computer, a tablet computer, a netbook, a smartphone, or the like. Additional examples of computing device <NUM> are described below with reference to <FIG> and <FIG>.

Data store(s) <NUM> may be configured to store configuration information <NUM> for computing device <NUM> and/or one or more other computing devices. In embodiments, configuration information <NUM> may be stored locally in memory of server <NUM>. Configuration information <NUM> may specify one or more compliance settings for computing device <NUM> and/or for users of computing device <NUM>, as well as including data, one or more files, etc., for installing on computing device <NUM> according to the particular configuration scenario. For example, a first compliance setting of configuration information <NUM> may be associated with a first user of computing device <NUM>, and a second compliance setting of configuration information <NUM> may be associated with a second user of computing device <NUM>. Examples of compliance settings include, but are not limited to, an encryption setting to be implemented by computing device <NUM>, a security setting to be implemented by computing device <NUM>, a minimum version of at least one of an application or an operating system required to be installed on computing device <NUM>, etc. The encryption setting(s) may specify whether a storage device included in computing device <NUM> is to be encrypted (e.g., via an encryption program, such as, but not limited to BitLocker™). The security settings may specify a password policy to be implemented by computing device <NUM> (e.g., setting the password length to a minimum of <NUM> characters, <NUM> characters, etc.), whether code signing should be implemented by computing device <NUM>, whether a trusted platform module (TPM) should be implemented by computing device <NUM>, etc. It is noted that the compliance settings described above are purely exemplary and that other configuration settings may be used.

Server <NUM> may be configured to manage compliance of computing device, including computing device <NUM>, with respect to configuration scenarios. Such computing devices may include stationary devices (e.g., desktop computers) and/or mobile devices (e.g., smart phones, laptops, tablet computers, wearable computing devices (e.g., a head-mounted device including smart glasses such as Google® Glass™, virtual reality headsets, smart watches, etc.), etc.). When managing mobile devices, server <NUM> may also be referred to as a mobile device manager (MDM). A configuration scenario may be as simple as a discrete set of policies or a as complex as a configuration for a virtual private network (VPN) connection. A policy (e.g., a data and/or security policy) may be specified by an enterprise. The policy may be specified in accordance with one or more compliance settings(s). The compliance settings(s) may be specified by an administrator of the enterprise (e.g., an IT (information technology) administrator or other person within an enterprise who may be responsible for deploying, maintaining and/or configuring computing device <NUM> on behalf of enterprise users).

As shown in <FIG>, server <NUM> comprises a compliance engine <NUM>. Compliance engine <NUM> may determine configuration information <NUM> to be provided to computing device <NUM> and provide the determined configuration information <NUM> to computing device <NUM>. For example, server <NUM> may receive and/or access configuration information <NUM> in the form of a compliance manifest or other document that indicates configuration settings for deployment to a particular set of devices. Server <NUM> may obtain configuration information <NUM> via network <NUM> from data store <NUM> and provide configuration information <NUM> to the indicated devices, such as computing device <NUM>, via network <NUM>. Transmission of configuration information <NUM> over network <NUM> is depicted in <FIG> by dash lines <NUM>. Configuration information <NUM> may specify compliance settings for implementing by computing device <NUM> (and optionally further devices) to bring computing device <NUM> into compliance with a configuration scenario.

Computing device <NUM> may be configured to implement the compliance setting(s) specified by configuration information <NUM>. As shown in <FIG>, computing device <NUM> comprises compliance agent <NUM>. Computing device <NUM> may be configured to execute compliance agent <NUM>, which is configured to implement compliance settings specified by received configuration information <NUM> by identifying and executing a state machine that describes a configuration process for implementing the compliance settings for a configuration scenario on computing device <NUM>. For example, compliance agent <NUM> may identify state machine <NUM> as the state machine indicated by configuration information <NUM> and execute state machine <NUM> to configure computing device <NUM> with compliance settings for compliance with a configuration scenario.

In accordance with embodiments, state machine <NUM> may be generated in various ways. For example, during a build process, one or more documents may be generated (e.g., by a developer), which may be compiled and stored on computing device <NUM>. For example, one or more files describing configuration scenarios, which enable a server to consume and render a user interface (UI) (e.g., at an admin console generated by compliance engine <NUM> at server <NUM>), and a state machine are generated during the build. This UI allows an IT Admin to enter configuration information for a particular configuration scenario that may then be sent to computing device <NUM>. The configuration information is processed by computing device <NUM> as described herein, utilizing a configuration service provider (CSP) to alter the security and functional behavior of the computing device according to the particular configuration scenario. A CSP is an interface to read, set, modify, or delete configuration settings on a device. Moreover, when processing a state machine (e.g., state machine <NUM>), CSPs are invoked according to an order dictated by the state machine to fulfill the desired state at a computing device using configuration information supplied by a server.

After implementing the configuration settings according to state machine <NUM>, compliance agent <NUM> may provide an acknowledgment (e.g., an "alert") to compliance engine <NUM>. The acknowledgment indicates that the computing device has implemented the configuration settings, or a failure occurred. Upon receiving the acknowledgment indicating success at implementing the configuration settings, compliance engine <NUM> may designate computing device <NUM> as being in compliance with the configuration scenario. Compliance engine <NUM> may maintain the acknowledgments in various ways.

For example, server <NUM> may maintain a compliance record <NUM> that includes a designation for each user-device pairing as to whether the particular user-device pairing is in compliance. For example, compliance record <NUM> may comprise a data structure (e.g., a table) comprising a plurality of entries, where each entry specifies a particular user-device pair, and an indication as to whether that user-device pair is compliance. Server <NUM> may be further configured to maintain a local configuration reference <NUM> of the configuration settings implemented for each user-device pairing. Configuration reference <NUM> may comprise a data structure (e.g., a table) comprising a plurality of entries, where each entry specifies a particular user-device pair and the configuration settings implemented by that pair. It is noted that the structure and/or organization of configuration reference <NUM> and/or compliance record <NUM> described above is purely exemplary and that other structures and/or organizations may be used. Configuration reference <NUM> and compliance record <NUM> may be maintained by server <NUM> in any location and manner, including being stored in data store <NUM> or elsewhere.

Compliance engine <NUM> may be configured to determine whether computing device(s) <NUM> remain in compliance with compliance rules using reference <NUM>. By doing so, compliance engine <NUM> simply needs to access reference <NUM> to determine the configuration settings implemented by computing device(s) <NUM>, rather than having to query computing device(s) <NUM> for their configuration settings. Compliance engine <NUM> may determine whether computing device(s) <NUM> remain in compliance upon detecting any suitable triggering event, including an expiration of a predetermined time period, a request from an administrator, auditor, and/or other person and/or entity that manages, desires to confirm, or is otherwise interested in knowing/confirming whether computing device <NUM> and/or other computing devices are in compliance with one or more compliance settings and/or requirements. A request for determining whether devices are in compliance with compliance settings/requirements may relate to any number of devices, including hundreds, thousands, or millions of devices. As such, by accessing such compliance information from configuration reference <NUM> and/or compliance record <NUM>, a large amount of processing power need not be expended by server <NUM> relative to having to poll each device of interest separately.

System <NUM> of <FIG> may be implemented in various ways, in embodiments. For instance, <FIG> depicts a detailed block diagram of system <NUM>, according to an example embodiment. System <NUM> is an example of system <NUM>. As shown in <FIG>, system <NUM> includes server <NUM> and a computing device <NUM>. Computing device <NUM> is an example of computing device <NUM>, as described above with reference to <FIG>. As further shown in <FIG>, computing device <NUM> includes a compliance agent <NUM>, a state machine (SM) data store <NUM>, and a configuration information (CI) data store <NUM>. State machine data store <NUM> and configuration information data store <NUM> may each comprise one or more physical memory and/or storage device(s), including any type of physical memory and/or storage device that is described herein, and/or as would be understood by a person of skill in the relevant art(s) having the benefit of this disclosure. Compliance agent <NUM> is an example of compliance agent <NUM>, as described above with reference to <FIG>.

Server <NUM> is configured to determine configuration information <NUM> to be provided to computing device <NUM> and provide the determined configuration information <NUM> thereto. For example, when a user first logs into a computing device newly provisioned thereto, server <NUM> retrieves device configuration information <NUM> associated with that computing device and/or user and provide configuration information <NUM> to the computing device. Additionally, server <NUM> may retrieve configuration information <NUM> associated with that computing device and/or user and provide configuration information <NUM> to the computing device when software or firmware (including a device driver) is newly installed to the computing device, when new hardware is added to the computing device, when software and/or firmware is updated or deleted from the computing device, when hardware is removed from the computing device, and/or during other events that modify a configuration of the computing device.

Similar to computing device <NUM> described with reference to <FIG>, computing device <NUM> may be configured to execute compliance agent <NUM>, which is configured to implement the configuration settings specified by configuration information <NUM>. More specifically, compliance agent <NUM> consumes an appropriate state machine based on the desired configuration scenario. Server <NUM> may provide a "configuration scenario identifier" in configuration information <NUM> to specify to computing device <NUM> the appropriate state machine. Compliance agent <NUM> may utilize this identifier to find the correct state machine for the orchestrator to follow. Configuration information <NUM>, supplied by server <NUM>, is then provided to the appropriate CSPs by compliance agent <NUM> based on the state machine, as described in further detail below.

As shown in <FIG>, compliance agent <NUM> includes a configuration manager <NUM> and an orchestrator engine <NUM>. Furthermore, configuration manager <NUM> includes a compliance configuration information handler <NUM> and a configuration information error checker <NUM>.

Compliance configuration information handler <NUM> may be configured to access configuration information <NUM> (e.g., delivery to computing device <NUM> via SyncML or CDN (Content Delivery Network)) from compliance engine <NUM> of server <NUM> and store configuration information <NUM> in configuration information data store <NUM> (as depicted by dashed lines <NUM> in <FIG> between server <NUM>, compliance configuration information handler <NUM>, and configuration information data store <NUM>). As another example, configuration information <NUM> may be supplied by JavaScript Object Notation (JSON). Configuration information <NUM> may be delivered by a server to computing device directly or the server may instruct the computing device where to obtain configuration information <NUM> via CDN (which is described in more detail below).

Configuration information <NUM> may have any suitable form. In accordance with an embodiment, configuration information <NUM> may be represented by an Extensible Markup Language (XML) file including a payload associated with the compliance settings and a corresponding Uniform Resource Identifier (URI) for downloading and processing of the payload. For example, a CDN stored payload may include a separate tag that denotes the URI for asynchronous downloading and processing of the payload. To further illustrate, a simple configuration scenario for a set of discrete policies (e.g., provided by a policy CSP) may only require a single payload included in an XML file. For more complex configuration scenarios (e.g., a configuration for a VPN connection), multiple payloads may need to be specified in an XML file. For example, in the VPN configuration scenario, a profile payload and a certificate payload may be provided. These scenario configuration files may be created by a server before attempting a sync session with a computing device. This avoids creating the same file on demand for each computing device interacting with the server and leaves the server available to perform more useful work, thereby increasing scalability.

Below is an example of a scenario configuration XML file that indicates policies to be set by a policy CSP, which includes multiple declarative configuration payloads. Note "Id", "checksum", and "OSDefinedScenario" attributes of the example scenario configuration XML file make up a unique identifier. Further note that the "OSDefinedScenario" attribute in this example indicates that this is a published configuration scenario, meaning that the configuration scenario will rely upon a declared configuration scenario state machine that dictates how to configure the configuration scenario. This state machine may be stored in a registry after an operating system (OS) build compiles a declared configuration scenario state machine Windows® manifest. Furthermore, there may be no need to specify whether each payload should be atomic or whether the entire document should be atomic because this behavior may be specified in the state machine. In addition, the XML file below sets some computing device wide policies and configures an example encryption feature (i.e., Microsoft® BitLocker™):
<IMG>
<IMG>
<IMG>.

Compliance configuration information handler <NUM> may be further configured to request (e.g., using a Hypertext Transfer Protocol (HTTP) GET method request) from server <NUM> configuration information <NUM> and to provide configuration information <NUM> to configuration information error checker <NUM>.

Configuration information error checker <NUM> may be configured to parse configuration information <NUM>, determine an error in configuration information <NUM> (e.g., errors with the XML code, attributes, URIs in an XML configuration scenario file, etc.), and request correction of the error from server <NUM>. For instance, in the example discussed above in which configuration information <NUM> is represented as an XML file, configuration information error checker <NUM> may parse and verify the XML code, store the URIs in a registry location, and if any errors are detected, synchronously report the errors to server <NUM> and request the errors be amended by server <NUM> (as depicted in <FIG> by dashed line <NUM>). Conventionally, an MDM server ensures that there are no conflicts or errors in the configuration information. However, the client device detecting conflicts and errors allows for immediate feedback to be provided to a MDM server and for fast correction of any errors in configuration information.

Compliance configuration information handler <NUM> may be further configured to transmit stored configuration information <NUM> to server <NUM>, and receive updated configuration information and/or additional configuration information from server <NUM> in response to sending the configuration information to server <NUM>. For example, compliance configuration information handler <NUM> may be configured to verify the status (e.g., out of date or stale) of configuration information data <NUM> stored in configuration information data store <NUM> by sending it to server <NUM>, and based on the status of stored configuration information <NUM> determined by server <NUM>, server <NUM> may provide compliance configuration information handler <NUM> with updated configuration information and/or additional configuration information. Subsequently, compliance configuration information handler <NUM> may store the received updated configuration information and/or additional configuration information in configuration information data store <NUM> (as depicted in <FIG> by dashed lines <NUM>). As described as follows, orchestrator engine <NUM> of compliance agent <NUM> is configured to implement the configuration settings received in configuration information <NUM>, and generates configuration results <NUM> based thereon.

In particular, <FIG> depicts a detailed block diagram of system <NUM>, according to an example embodiment. System <NUM> is a further example of system <NUM>. As shown in <FIG>, system <NUM> includes server <NUM> and a computing device <NUM>. Computing device <NUM> is a further example of computing device <NUM> of <FIG>. Furthermore, computing device <NUM> includes a compliance agent <NUM>, SM data store <NUM>, and configuration information data store <NUM>. Compliance agent <NUM> is a further example of compliance agent <NUM>, as described above with reference to <FIG>.

Similar to computing device <NUM> described with reference to <FIG>, computing device <NUM> executes compliance agent <NUM>, which is configured to implement the configuration settings specified by configuration information <NUM>. As shown in <FIG>, compliance agent <NUM> includes configuration manager <NUM> and orchestrator engine <NUM>. Configuration manager <NUM> includes compliance configuration information handler <NUM> and a settings implementation triggerer <NUM>. Orchestrator engine <NUM> includes a state machine selector <NUM> and a state machine execution engine <NUM>. These features of compliance agent <NUM> are described as follows.

Settings implementation triggerer <NUM> is configured to trigger orchestrator engine <NUM> to implement compliance settings described by configuration information <NUM> in computing device <NUM>. For example, as shown in <FIG>, settings implementation triggerer <NUM> provides a trigger <NUM> to state machine selector <NUM>. More specifically, trigger <NUM> may cause the scheduling of a task (and the scheduled task may be triggered by a "DeclaredConfiguration" CSP) after configuration information error checker <NUM> parses and verifies configuration information <NUM>, as described above with reference to <FIG>. In accordance to embodiments, the task may be stored in an activity queue and processed after any unprocessed tasks stored in the activity queue have been processed.

State machine selector <NUM> is configured to receive a trigger from settings implementation triggerer <NUM> to implement compliance settings in computing device <NUM>. In an embodiment, state machine selector <NUM> identifies a state machine indicated by configuration information <NUM> that describes a configuration process for implementing the compliance settings. After receiving trigger <NUM>, state selector machine <NUM> may obtain stored configuration information <NUM> from configuration information data store <NUM> and determine that state machine <NUM> is associated with configuration information <NUM> after consuming attributes of stored configuration information <NUM>. For instance, configuration information <NUM> may specify an identifier for a particular state machine.

State machine selector <NUM> may be further configured to provide state machine <NUM> to state machine execution engine <NUM>. State machine execution engine <NUM> is configured to execute state machine <NUM> to configure computing device <NUM> with compliance settings described in configuration information <NUM>. For example, state machine selector <NUM> may process payloads included in configuration information <NUM> (as described with reference to <FIG>) along with dependencies in the order as dictated by state machine <NUM>. Alternatively, if there is no state machine associated with configuration information <NUM>, then payloads specified by configuration information <NUM> are processed in the order dictated by configuration information <NUM>. Further, state machine selector <NUM> may access state machine data store <NUM> to obtain a manifest of state machine <NUM>. The manifest may include state machine <NUM> and its dependencies.

An example XML file of a declared configuration scenario state machine manifest is reproduced below. <IMG>
<IMG>.

State machine execution engine <NUM> may be further configured to store configuration results <NUM> (e.g., an XML file with the URIs and values, events, last error code, status etc.) in configuration information data store <NUM>. For example, configuration results <NUM> may include one or more compliance records <NUM> and/or configuration references <NUM> described above with respect to <FIG>. Compliance configuration information handler <NUM> may be configured to obtain configuration results <NUM> from configuration information data store <NUM> and provide configuration results <NUM> to compliance engine <NUM> (as depicted in <FIG> by dashed lines <NUM>) to be analyzed by server <NUM>. In the event that configuration results <NUM> includes an error, server <NUM> may provide compliance configuration information handler <NUM> with an earlier version of confirmation information <NUM> so that any erroneous changes to the mobile device may be reversed, including by directing orchestrator engine <NUM> to rollback the state of the computing device to the state prior to execution of the state machine.

For example, in accordance with embodiments described herein, the state machine may contain configuration directives for the configuration scenario. To further illustrate, a state may be described by entities "FromState", "Activity", and "ToState". An Activity may have the form of executable code owned and created by configuration scenario owner(s). Furthermore, an Activity can return a different ToState state at runtime to be used to go to a next step. If the Activity, does not modify the Tostate, then the default ToState is used and is specified in the data representation of the state machine. An Activity may have predefined input data and output data expressed as XML that are marshalled to the Activity. This ensures that an individual Activity can be developed and tested individually. The ability to have an Activity modify the ToState allows for runtime adjustments to a state machine. The state machine may be used to configure, verify, refresh, and delete configuration scenarios.

Systems <NUM>, <NUM>, and <NUM> may operate in various ways to perform its functions. For instance, <FIG> depicts a flowchart <NUM> of a method for implementing compliance settings by a computing device for bringing the computing device into compliance with a configuration scenario, according to an example embodiment. <FIG> is described with continued reference to <FIG>, <FIG>, and <FIG>. However, other structural and operational embodiments will be apparent to persons skilled in the relevant art(s) based on the following discussion regarding flowchart <NUM> and systems <NUM>, <NUM>, and <NUM> of <FIG>, <FIG>, and <FIG>.

As shown in <FIG>, flowchart <NUM> begins at step <NUM>. In step <NUM>, configuration information is received from a server, the configuration information describing compliance settings for implementing by a mobile device to bring the mobile device into compliance with a configuration scenario. For example, with continued reference to <FIG>, <FIG>, and <FIG>, compliance configuration information handler <NUM> receives information <NUM> from compliance engine <NUM> of server <NUM>.

In step <NUM>, the configuration information is stored. For example, with continued reference to <FIG>, <FIG>, and <FIG>, compliance configuration information handler <NUM> stores configuration information <NUM> in configuration information data store <NUM>.

In step <NUM>, a trigger is received to implement the compliance settings in the mobile device. For example, with continued reference to <FIG>, <FIG>, and <FIG>, settings implementation triggerer <NUM> provides trigger <NUM> to state machine selector <NUM> of orchestrator engine <NUM>, starting the implementation of compliance settings described by the configuration information <NUM> in computing device <NUM>.

In step <NUM>, a state machine, indicated by the configuration information that describes a configuration process for implementing the compliance settings, is identified. For example, with continued reference to <FIG>, <FIG>, and <FIG>, after receiving trigger <NUM>, state selector machine <NUM> obtains stored configuration information <NUM> from configuration information data store <NUM> and determines that state machine <NUM> is associated with configuration information <NUM>.

In step <NUM>, with continued reference to <FIG>, <FIG>, and <FIG>, the state machine is executed to configure the mobile device with the compliance settings. For example, with continued reference to <FIG>, <FIG>, and <FIG>, state machine selector <NUM> provides state machine <NUM> (or a pointer thereto) to state machine execution engine <NUM> and state machine execution engine <NUM> executes state machine <NUM> to configure computing device <NUM> with compliance settings described in configuration information <NUM>.

<FIG> depicts a flowchart <NUM> of a method for determining whether the mobile device is appropriately configured according to the configuration information, according to an example embodiment. <FIG> is described with continued reference to <FIG>, <FIG>, and <FIG>. However, other structural and operational embodiments will be apparent to persons skilled in the relevant art(s) based on the following discussion regarding flowchart <NUM> and systems <NUM>, <NUM>, and <NUM> of <FIG>, <FIG>, and <FIG>.

As shown in <FIG>, flowchart <NUM> includes step <NUM>. In step <NUM>, the state machine is executed to determine whether the mobile device is appropriately configured according to the configuration information. For example, with continued reference to <FIG>, <FIG>, and <FIG>, state machine execution engine <NUM> executes state machine <NUM> without modifying the configuration of computing device <NUM> to evaluate that computing device <NUM> is in the correct configuration state. In particular, in accordance with embodiments described herein, a state machine may run in either of two modes, a "Configure" mode and an "Analyze" mode. The Configure mode configures the computing device based on the configuration information (as described above). The Analyze mode performs an evaluation of the computing device without modification thereto to ensure the device is indeed in the correct configuration state. For example, the state machine be configured to retrieve one or more current settings and/or other information (related to a particular hardware/software/firmware configuration) of the computing device (e.g., determine an operating system version number, a version number of another application, an entry in a file such as a DLL (Dynamic-Link Library) file, etc.; determine the presence or absence of one or more files, etc.). The state machine may compare the retrieved information to correct configuration information maintained or accessible by the state machine for the computing device. If all the information matches, the state machine may indicate the computing device in compliance for the particular configuration. If not all information matches, the state machine may indicate the computing devices is not in compliance.

As described above, the results of a particular configuration performed by a state machine may be transmitted to the compliance engine. For example, <FIG> depicts a flowchart <NUM> of a method for storing and transmitting configuration results, according to an embodiment. <FIG> is described with continued reference to <FIG>, <FIG>, and <FIG>. However, other structural and operational embodiments will be apparent to persons skilled in the relevant art(s) based on the following discussion regarding flowchart <NUM> and systems <NUM>, <NUM>, and <NUM> of <FIG>, <FIG>, and <FIG>.

As shown in <FIG>, flowchart <NUM> begins at step <NUM>. In step <NUM>, configuration results, generated by executing the state machine in a configuration information data store, are stored. For example, with continued reference to <FIG>, <FIG>, and <FIG>, state machine execution engine <NUM> stores configuration results <NUM> in configuration information data store <NUM>. In embodiments, configuration results <NUM> may include one or more indications. For instance, configuration results <NUM> may provide an indication that the configuration setting(s) were successfully installed by orchestrator engine <NUM>, the installation is in-progress, or that a failure occurred, and the configuration setting(s) were not successfully installed. If a failure occurred, configuration results <NUM> may include an indication of the failure, such as by listing one or more errors (by error code and/or description), event tracing (e.g., logging of information about state machine execution that may be used for debugging), and/or other diagnostic data generated by the state machine.

In steps <NUM> and <NUM>, the configuration results from the configuration information data store are obtained (step <NUM>) and transmitted to the server (step <NUM>). For example, with continued reference to <FIG>, <FIG>, and <FIG>, compliance configuration information handler <NUM> obtains configuration results <NUM> from configuration information data store <NUM> and provides configuration results <NUM> to compliance engine <NUM> to be analyzed by server <NUM>. In the event that configuration results <NUM> includes an error, server <NUM> may provide compliance configuration information handler <NUM> with an earlier version of confirmation information <NUM> so that any erroneous changes to the mobile device may be reversed, including by directing orchestrator engine <NUM> to rollback the state of the computing device to the state prior to execution of the state machine. For instance, prior to executing a state machine, or during the execution of the state machine, a current state of the computing device may be saved (e.g., saving versions of settings, affected files, etc., that existed prior to execution of the state machine), and the computing device may be reconfigured with the saved state by reverting the computing device to the saved state information. Alternatively, the computing device may be instructed to not rollback to the previous last known good state so that a detailed analysis may be performed of the failure state. For instance, another mode may be defined, referred to as a "developer mode" (or by another label), in which the computing device does not rollback to the last known good state in the event of an error.

Furthermore, note that if an error is encountered during execution of a state machine, the compliance agent may attempt to correct the error rather than rolling back to a prior state. For instance, <FIG> depicts a flowchart <NUM> of a method for requesting correction of an error with configuration information, according to an example embodiment. <FIG> is described with continued reference to <FIG>, <FIG>, and <FIG>. However, other structural and operational embodiments will be apparent to persons skilled in the relevant art(s) based on the following discussion regarding flowchart <NUM> and systems <NUM>, <NUM>, and <NUM> of <FIG>, <FIG>, and <FIG>.

Flowchart <NUM> begins with step <NUM>. In step <NUM>, the configuration information is parsed. For example, orchestrator engine <NUM> may be configured to parse configuration information <NUM> for one or more configuration settings that correspond to a received error code/error description.

In step <NUM>, an error with the configuration information is determined. In an embodiment, during the parsing, orchestrator engine <NUM> may be determine the one or more configuration settings that correspond to a received error code/error description.

In step <NUM>, correction of the error is requested from the server. In an embodiment, compliance agent <NUM> may transmit error information (e.g., an error code, an error description, an event tracing, etc.) to compliance <NUM> to request correction of the error.

For instance, with continued reference to <FIG>, <FIG>, and <FIG>, in the example discussed above in which configuration information <NUM> is represented by an XML file, configuration information error checker <NUM> may parse and verify the XML file, store the URIs in a registry location, and if any errors are detected, synchronously report the errors to server <NUM> and request server <NUM> to immediately amend the errors.

Note that in response to a request for correction of an error, and/or at any other time, compliance engine <NUM> may provide updated configuration information to a compliance agent. For instance, <FIG> depicts a flowchart <NUM> of a method for receiving updated configuration information and/or additional configuration information, according to an example embodiment. <FIG> is described with continued reference to <FIG>, <FIG>, and <FIG>. However, other structural and operational embodiments will be apparent to persons skilled in the relevant art(s) based on the following discussion regarding flowchart <NUM> and systems <NUM>, <NUM>, and <NUM> of <FIG>, <FIG>, and <FIG>.

As shown in <FIG>, flowchart <NUM> begins with step <NUM>. In step <NUM>, the configuration information is stored in a configuration information data store. For example, with continued reference to <FIG> and <FIG>, configuration information <NUM> is stored in configuration information data store <NUM>.

In step <NUM>, the stored configuration information is transmitted to the server. In embodiments, compliance agent <NUM> may transmit configuration <NUM> to compliance engine <NUM> at server <NUM> for any reason, including due to an error (as described above), to check for updates, and for any other reason. For instance, compliance configuration information handler <NUM> may verify the status (e.g., out of date or stale) of configuration information <NUM> stored in configuration information data store <NUM>. If handler <NUM> determines configuration information <NUM> to contain an error, to be out of date, to be stale, etc., handler <NUM> may transmit configuration information <NUM> (or a portion thereof) to server <NUM>.

In step <NUM>, updated configuration information and/or additional configuration information is received from the server in response to sending the configuration information to the server. Based on a status of stored configuration information <NUM> determined by server <NUM>, server <NUM> may provide compliance configuration information handler <NUM> with updated configuration information and/or additional configuration information. As such, compliance configuration information handler <NUM> may update configuration information data store <NUM> with the updated configuration information and/or additional configuration information.

Accordingly, embodiments improve the efficiency of pushing configuration settings to large numbers of devices, and to maintaining track of the compliance of such devices with requirements based on their having received and implemented the configuration settings.

Embodiments reduces client/server latency (the delay before a transfer of data begins following an instruction for its transfer), by putting more responsibility onto the client devices to get themselves into the desired state. Each client device accepts the request to implement configuration settings from the server, turning immediately back to the server. The request is handled asynchronously by the client devices. When a client device has completed the request, it will initiate a session to send the server an alert indicating success or failure of the implementation of the configuration settings by the client device. Embodiments also reduce network activity between the client and server devices by removing the need for the server to continually monitor state of the client devices and in a piecemeal fashion maintain the desired device state. In embodiments, the server provides each client with the desired state (in the form of configuration settings) and expects the client to maintain the settings (and to notify the server, without prompting by the server, if unable to do so). Embodiments also provide a uniform manner, initiated by the server, to configure client devices with settings, rather than having service providers (e.g., software and/or hardware providers) to have to manage the process for their own products.

The systems and methods described above, including the device compliance management embodiments described in reference to <FIG>, may be implemented in hardware, or hardware combined with one or both of software and/or firmware. For example, compliance engine <NUM>, compliance agent <NUM>, orchestrator engine <NUM>, configuration information error checker <NUM>, compliance agent <NUM>, compliance configuration information handler <NUM>, settings implementation triggerer <NUM>, state machine selector <NUM>, state machine execution engine <NUM>, compliance agent <NUM> and/or each of the components described therein, and flowcharts <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> may be each implemented as computer program code/instructions configured to be executed in one or more processors and stored in a computer readable storage medium. Alternatively, compliance engine <NUM>, compliance agent <NUM>, orchestrator engine <NUM>, configuration information error checker <NUM>, compliance agent <NUM>, compliance configuration information handler <NUM>, settings implementation triggerer <NUM>, state machine selector <NUM>, state machine execution engine <NUM>, compliance agent <NUM> and/or each of the components described therein, and flowcharts <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> may be implemented as hardware logic/electrical circuitry. In an embodiment, compliance engine <NUM>, compliance agent <NUM>, orchestrator engine <NUM>, configuration information error checker <NUM>, compliance agent <NUM>, compliance configuration information handler <NUM>, settings implementation triggerer <NUM>, state machine selector <NUM>, state machine execution engine <NUM>, compliance agent <NUM> and/or each of the components described therein, and flowcharts <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> may be implemented in one or more SoCs (system on chip). An SoC may include an integrated circuit chip that includes one or more of a processor (e.g., a central processing unit (CPU), microcontroller, microprocessor, digital signal processor (DSP), etc.), memory, one or more communication interfaces, and/or further circuits, and may optionally execute received program code and/or include embedded firmware to perform functions.

Furthermore, server <NUM>, computing device(s) <NUM>, computing device <NUM>, and computing device <NUM> may each be implemented in various device types. For instance, <FIG> shows a block diagram of an exemplary mobile device <NUM> including a variety of optional hardware and software components, shown generally as components <NUM>. Any number and combination of the features/elements of compliance engine <NUM>, compliance agent <NUM>, orchestrator engine <NUM>, configuration information error checker <NUM>, compliance agent <NUM>, compliance configuration information handler <NUM>, settings implementation triggerer <NUM>, state machine selector <NUM>, state machine execution engine <NUM>, compliance agent <NUM>, and/or flowcharts <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> may be implemented as components <NUM> included in a mobile device embodiment, as well as additional and/or alternative features/elements, as would be known to persons skilled in the relevant art(s). It is noted that any of components <NUM> can communicate with any other of components <NUM>, although not all connections are shown, for ease of illustration. Mobile device <NUM> can be any of a variety of mobile devices described or mentioned elsewhere herein or otherwise known (e.g., cell phone, smartphone, handheld computer, Personal Digital Assistant (PDA), etc.) and can allow wireless two-way communications with one or more mobile devices over one or more communications networks <NUM>, such as a cellular or satellite network, or with a local area or wide area network.

The illustrated mobile device <NUM> can include a controller or processor referred to as processor circuit <NUM> for performing such tasks as signal coding, image processing, data processing, input/output processing, power control, and/or other functions. Processor circuit <NUM> may execute program code stored in a computer readable medium, such as program code of one or more applications <NUM>, operating system <NUM>, any program code stored in memory <NUM>, etc. Operating system <NUM> can control the allocation and usage of the components <NUM> and support for one or more application programs <NUM> (a. applications, "apps", etc.). Application programs <NUM> can include common mobile computing applications (e.g., email applications, calendars, contact managers, web browsers, messaging applications) and any other computing applications (e.g., word processing applications, mapping applications, media player applications).

As illustrated, mobile device <NUM> can include memory <NUM>. Memory <NUM> can include non-removable memory <NUM> and/or removable memory <NUM>. The non-removable memory <NUM> can include RAM, ROM, flash memory, a hard disk, or other well-known memory storage technologies. The removable memory <NUM> can include flash memory or a Subscriber Identity Module (SIM) card, which is well known in GSM communication systems, or other well-known memory storage technologies, such as "smart cards. " The memory <NUM> can be used for storing data and/or code for running operating system <NUM> and applications <NUM>. Example data can include web pages, text, images, sound files, video data, or other data sets to be sent to and/or received from one or more network servers or other devices via one or more wired or wireless networks. Memory <NUM> can be used to store a subscriber identifier, such as an International Mobile Subscriber Identity (IMSI), and an equipment identifier, such as an International Mobile Equipment Identifier (IMEI). Such identifiers can be transmitted to a network server to identify users and equipment.

A number of programs may be stored in memory <NUM>. These programs include operating system <NUM>, one or more application programs <NUM>, and other program modules and program data. Examples of such application programs or program modules may include, for example, computer program logic (e.g., computer program code or instructions) for implementing the systems described above, including the device compliance management embodiments described in reference to <FIG>.

Mobile device <NUM> can support one or more input devices <NUM>, such as a touch screen <NUM>, microphone <NUM>, camera <NUM>, physical keyboard <NUM> and/or trackball <NUM> and one or more output devices <NUM>, such as a speaker <NUM> and a display <NUM>.

Other possible output devices (not shown) can include piezoelectric or other haptic output devices. Some devices can serve more than one input/output function. For example, touch screen <NUM> and display <NUM> can be combined in a single input/output device. The input devices <NUM> can include a Natural User Interface (NUI).

Wireless modem(s) <NUM> can be coupled to antenna(s) (not shown) and can support two-way communications between processor circuit <NUM> and external devices, as is well understood in the art. The modem(s) <NUM> are shown generically and can include a cellular modem <NUM> for communicating with the mobile communication network <NUM> and/or other radio-based modems (e.g., Bluetooth <NUM> and/or Wi-Fi <NUM>). Cellular modem <NUM> may be configured to enable phone calls (and optionally transmit data) according to any suitable communication standard or technology, such as GSM, <NUM>, <NUM>, <NUM>, etc. At least one of the wireless modem(s) <NUM> is typically configured for communication with one or more cellular networks, such as a GSM network for data and voice communications within a single cellular network, between cellular networks, or between the mobile device and a public switched telephone network (PSTN).

Mobile device <NUM> can further include at least one input/output port <NUM>, a power supply <NUM>, a satellite navigation system receiver <NUM>, such as a Global Positioning System (GPS) receiver, an accelerometer <NUM>, and/or a physical connector <NUM>, which can be a USB port, IEEE <NUM> (FireWire) port, and/or RS-<NUM> port. The illustrated components <NUM> are not required or all-inclusive, as any components can be not present and other components can be additionally present as would be recognized by one skilled in the art.

Furthermore, <FIG> depicts an exemplary implementation of a computing device <NUM> in which embodiments may be implemented, including computing device <NUM>, computing device <NUM>, computing device <NUM>, server <NUM>. The description of computing device <NUM> provided herein is provided for purposes of illustration, and is not intended to be limiting. Embodiments may be implemented in further types of computer systems, as would be known to persons skilled in the relevant art(s).

A number of program modules may be stored on the hard disk, magnetic disk, optical disk, ROM, or RAM. These programs include operating system <NUM>, one or more application programs <NUM>, other programs <NUM>, and program data <NUM>. Application programs <NUM> or other programs <NUM> may include, for example, computer program logic (e.g., computer program code or instructions) for implementing the systems described above, including the device compliance management embodiments described in reference to <FIG>.

As used herein, the terms "computer program medium," "computer-readable medium," and "computer-readable storage medium" are used to generally refer to physical hardware media such as the hard disk associated with hard disk drive <NUM>, removable magnetic disk <NUM>, removable optical disk <NUM>, other physical hardware media such as RAMs, ROMs, flash memory cards, digital video disks, zip disks, MEMs, nanotechnology-based storage devices, and further types of physical/tangible hardware storage media (including system memory <NUM> of <FIG>). Communication media typically embodies computer-readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave. Embodiments are also directed to such communication media.

In an embodiment not covered by the appended independent claims, a mobile device comprises at least one processor circuit; and at least one memory that stores program code configured to be executed by the at least one processor circuit, the program code comprising: a configuration manager configured to, when a user first logs into the mobile device, receive, from a server, configuration information describing compliance settings for implementing by the mobile device to bring the mobile device into compliance with a configuration scenario, wherein a designation of a user-device pairing is maintained at the server in a configuration reference, the user device pairing corresponding to the user and the mobile device; a configuration error checker configured to: determine an error in the received configuration information, transmit a request for correction of the error to the server, receive updated configuration information from the server; and an orchestration engine configured to: configure the mobile device with the compliance settings.

In an embodiment of the foregoing mobile device, the configuration manager is further configured to store the configuration information, and the orchestrator engine is further configured to: receive a trigger from the configuration manager to implement the compliance settings in the mobile device; identify a state machine indicated by the configuration information that describes a configuration process for implementing the compliance settings; and execute the state machine to configure the mobile device with the compliance settings.

In an embodiment of the foregoing mobile device, the orchestrator engine is further configured to execute the state machine to determine whether the mobile device is appropriately configured according to the configuration information.

In an embodiment of the foregoing mobile device, the orchestrator engine is further configured to store configuration results generated by executing the state machine in a configuration information data store; and the configuration manager is further configured to obtain the configuration results from the configuration information data store and transmit the configuration results to the server.

In an embodiment of the foregoing mobile device, the configuration manager is further configured to: parse the configuration information; determine an error with the configuration information; and request correction of the error from the server.

In an embodiment of the foregoing mobile device, the configuration manager is further configured to: store the configuration information in a configuration information data store; transmit the stored configuration information to the server; and receive updated configuration information and/or additional configuration information from the server in response to sending the configuration information to the server.

In an embodiment of the foregoing mobile device, the state machine is stored in a state machine data store on the mobile device.

In an embodiment of the foregoing mobile device, the configuration information is received from the server in an Extensible Markup Language (XML) file including a payload associated with the compliance settings and a corresponding Uniform Resource Identifier (URI) for downloading and processing of the payload.

In another embodiment not covered by the appended independent claims, a method comprises: when a user first logs into a mobile device, receiving, from a server, configuration information describing compliance settings for implementing by a mobile device to bring the mobile device into compliance with a configuration scenario wherein a designation of a user-device pairing is maintained at the server in a configuration reference, the user-device pairing corresponding to the user and the mobile device, wherein a designation of a user-device pairing is maintained at the server in a configuration reference, the user-device pairing corresponding to the user and the mobile device; determining an error in the received configuration information; transmitting a request for correction of the error to the server; receiving updated configuration information from the server; and configuring the mobile device with the compliance settings.

In an embodiment, the foregoing method further comprises: storing the configuration information; receiving a trigger to implement the compliance settings in the mobile device; identifying a state machine indicated by the configuration information that describes a configuration process for implementing the compliance settings; and executing the state machine to configure the mobile device with the compliance settings.

In an embodiment, the foregoing method further comprises: executing the state machine to determine whether the mobile device is appropriately configured according to the configuration information.

In an embodiment, the foregoing method further comprises: storing configuration results generated by executing the state machine in a configuration information data store; obtaining the configuration results from the configuration information data store; and transmitting the configuration results to the server.

In an embodiment, the foregoing method further comprises: parsing the configuration information; determining an error with the configuration information; and requesting correction of the error from the server.

In an embodiment, the foregoing method further comprises: storing the configuration information in a configuration information data store; transmitting the stored configuration information to the server; and receiving updated configuration information and/or additional configuration information from the server in response to sending the configuration information to the server.

In an embodiment of the foregoing method, the state machine is stored in a state machine data store on the mobile device.

In an embodiment of the foregoing method, the configuration information is received from the server in an Extensible Markup Language (XML) file including a payload associated with the compliance settings and a corresponding Uniform Resource Identifier (URI) for downloading and processing of the payload.

In another embodiment not covered by the appended independent claims, a computer-readable storage medium having program instructions recorded thereon that, when executed by at least one processing circuit of a mobile device, perform a method comprising: when a user first logs into a mobile device, receiving, from a server, configuration information describing compliance settings for implementing by a mobile device to bring the mobile device into compliance with a configuration scenario wherein a designation of a user-device pairing is maintained at the server in a configuration reference, the user-device pairing corresponding to the user and the mobile device, wherein a designation of a user-device pairing is maintained at the server in a configuration reference, the user-device pairing corresponding to the user and the mobile device; determining an error in the received configuration information; transmitting a request for correction of the error to the server; receiving updated configuration information from the server; and configuring the mobile device with the compliance settings.

In an embodiment of the foregoing method comprises: executing the state machine to determine whether the mobile device is appropriately configured according to the configuration information.

In an embodiment of the foregoing method,the method further comprises: storing configuration results generated by executing the state machine in a configuration information data store; obtaining the configuration results from the configuration information data store; and transmitting the configuration results to the server.

In an embodiment of the foregoing method comprises: parsing the configuration information; determining an error with the configuration information; and requesting correction of the error from the server.

In an embodiment of the foregoing method comprises: storing the configuration information in a configuration information data store; transmitting the stored configuration information to the server; and receiving updated configuration information and/or additional configuration information from the server in response to sending the configuration information to the server.

Claim 1:
A mobile device (<NUM>), comprising:
at least one processor circuit (<NUM>,<NUM>); and
at least one memory (<NUM>, <NUM>) that stores program code (<NUM>, <NUM>) configured to be executed by the at least one processor circuit, (<NUM>, <NUM>) the program code comprising:
a configuration manager (<NUM>) configured to:
when a user first logs into the mobile device (<NUM>), receive (<NUM>), from a server (<NUM>), configuration information (<NUM>) describing compliance settings for implementing by the mobile device (<NUM>) to bring the mobile device into compliance with a configuration scenario, wherein a designation of a user-device pairing is maintained at the server (<NUM>) in a configuration reference, the user-device pairing corresponding to the user and the mobile device; and
store (<NUM>) the configuration information (<NUM>);
a configuration information error checker (<NUM>) configured to:
determine (<NUM>) an error in the received configuration information (<NUM>),
transmit (<NUM>) a request for correction of the error to the server (<NUM>), and
receive updated configuration information from the server (<NUM>); and
an orchestrator engine (<NUM>) configured to:
receive (<NUM>) a trigger (<NUM>) from the configuration manager (<NUM>) to implement the compliance settings in the mobile device (<NUM>);
identify (<NUM>) a state machine (<NUM>) indicated by the configuration information (<NUM>) that describes a configuration process for implementing the compliance settings, and
execute (<NUM>) the state machine (<NUM>) to configure the mobile device with the compliance settings.