Patent Description:
It is the object of the present invention to reduce network traffic for instantiating containerized applications while maintaining security.

Embodiments described herein are directed to configuring managed computing devices utilizing containerized applications. For instance, a mobile device manager at a server may provide configuration settings to a computing device via, for example, an enterprise network. A host operating system executing on the computing device determines and applies the settings that are applicable to the host operating system. The configuration settings are stored for configuring containerized applications executing on the computing device. For instance, as new containerized applications are launched by the host operating system, the containerized applications retrieve the configuration settings and determine and apply the settings that are applicable to the containerized applications. The results of applying the configuration settings to the host operating system and the containerized applications are merged and sent to the mobile device manager. The host operating system and the containerized application may, for example, implement the settings in order to be compliant with an enterprise's policy (e.g., a data and/or security policy).

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.

Instead of obtaining the configuration settings directly from the mobile device manager, the containerized applications utilize the configuration settings made available via the host operating system. Accordingly, the host operating system acts as a proxy to manage the containerized applications on behalf of the mobile device manager. By having the host operating system act as a proxy, the mobile device manager is not required to have any knowledge of each of the containerized applications and is relieved from the burden of individually managing each of the containerized applications executing on the computing device, as the mobile device manager is not required to provide configuration settings to the computing device each time a new containerized application is launched. This advantageously reduces the network traffic between the computing device and the mobile device manager, thereby freeing up network bandwidth for the enterprise network. Moreover, a lesser amount of computing resources (e.g., processing power, memory, power, etc.) of both the mobile device manager and the computing device are utilized. For instance, the mobile device manger is not required to provide numerous configuration settings at different times for each instance of a containerized application, and the computing device is not required to provide numerous requests for configuration setting requests for each containerized application executed thereon. Still further, the computing device is not required to provide results of applying the configuration settings each time they are applied to the host operating system or a particular containerized application. Instead, the computing device provides a merged version of the results to the mobile device manager.

The reduction in network transactions between the computing device and the mobile device manager advantageously decrease the configuration time for computing devices, thereby enabling a user to begin utilizing their device more quickly.

<FIG> is a block diagram of a system <NUM> for managing and configuring one or more computing devices in accordance with an example embodiment. As shown in <FIG>, system <NUM> includes a server <NUM> and one or more computing devices <NUM> that are communicatively coupled via a network <NUM>. Network <NUM> may comprise one or more networks such as local area networks (LANs), wide area networks (WANs), enterprise networks, the Internet, etc., and may include one or more of wired and/or wireless portions. 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. An enterprise network comprises a private computer network established by an enterprise for the purposes of interconnecting enterprise devices (e.g., computing device(s) <NUM>) at one or more enterprise locations to other enterprise devices and to enable enterprise devices to access and/or share computing resources. Users of computing device(s) <NUM> may be referred to herein as "enterprise users" or simply "users". Each of computing device(s) <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(s) <NUM> are described below with reference to <FIG> and <FIG>.

Server <NUM> may be configured to manage each of computing device(s) <NUM> with respect to a policy (e.g., a data and/or security policy). The policy may be specified by an enterprise. Server <NUM> may also be referred to as a mobile device manager (MDM). The policy may be specified in accordance with one or more compliance rule(s). For instance, server <NUM> may comprise a compliance engine <NUM>. Compliance engine <NUM> may determine configuration settings <NUM> to be provided to a particular computing device of computing device(s) <NUM> and provide the determined configuration(s) thereto. The determined configuration settings may comply with the compliance rule(s). The compliance rule(s) may be specified by an administrator of the enterprise (e.g., an IT administrator or other person within an enterprise who may be responsible for deploying, maintaining and/or configuring computing device(s) <NUM> on behalf of enterprise users). Configuration settings <NUM> may be maintained by server <NUM> (as shown in <FIG>) or may be stored in a data store (not shown) communicatively coupled to server <NUM>.

Configuration settings <NUM> may specify one or more configuration settings for a particular computing device of computing device(s) <NUM> and/or a particular user of each of computing device(s) <NUM>. Thus, each of computing device(s) <NUM> may be associated with more than one of configuration settings <NUM>. For example, a first configuration of configuration settings <NUM> may be associated with a first user of a particular computing device, and a second configuration of configuration settings <NUM> may be associated with a second user of the particular computing device. Examples of configuration settings <NUM> include, but are not limited to, one or more encryption settings to be implemented by computing device(s) <NUM>, one or more security settings to be implemented by computing device(s) <NUM>, one or more network settings to be implemented by computing device(s) <NUM>, one or more application behavioral settings that affect that behavior of an application executing on computing device <NUM> (e.g., containerized application <NUM>), a minimum version of at least one of an application or an operating system required to be installed on computing device(s) <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 setting(s) 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(s) <NUM>, whether a trusted platform module (TPM) should be implemented by computing device(s) <NUM>, whether an anti-malware application is to be installed and/or activated on computing device(s) <NUM>, whether a firewall application is to be installed and/or activated on computing device(s), etc. The network setting(s) may specify network proxy settings to be implemented by computing device(s) <NUM>, network quality-of-service (QoS) settings to be implemented by computing device(s) <NUM>, network isolation settings to be implemented by computing device(s) <NUM>, etc. It is noted that the configuration settings described above are purely exemplary and that other configuration settings may be used.

Configuration settings <NUM> may have any suitable form. In accordance with an embodiment, configuration settings <NUM> may be represented by an Extensible Markup Language (XML) file including a payload associated with configuration settings <NUM> and a corresponding Uniform Resource Identifier (URI) for downloading and processing of the payload.

Each of computing device(s) <NUM> is configured to execute a host operating system <NUM>. Host operating system <NUM> is configured to launch applications via containers (shown as containerized applications <NUM>). A container is a standard unit of executable software that packages program code of an application and all its dependencies necessary for application execution so that the application runs quickly and reliably from one computing environment to another. Examples of containers include, but are not limited to, MSIX containers (for running MSIX applications), Universal Windows Platform (UWP) containers (for running UWP applications), and Win32 containers (for running Win32 applications). By running applications via containers, the security and performance of the computing device on which containerized applications <NUM> execute is improved. Each of the containers may be executed separately as a guest operating system that is secondary to host operating system <NUM>. Each guest operating system may have its own kernel, registry and drivers.

Host operating system <NUM> is configured to receive configuration settings <NUM> from server <NUM>. Host operating system <NUM> determines the configuration settings from configuration settings <NUM> that are applicable thereto and configures itself accordingly. Host operating system <NUM> further makes configuration settings <NUM> available to containerized applications <NUM>. Instead of obtaining configuration settings <NUM> directly from server <NUM>, containerized applications <NUM> utilize configuration settings <NUM> made available via host operating system <NUM> and determines the configuration settings therefrom that are applicable thereto and configures itself accordingly. Accordingly, host operating system <NUM> acts as a proxy to manage containerized applications <NUM> on behalf of server <NUM>.

By having host operating system <NUM> act as a proxy, server <NUM> is relieved from the burden of individually managing each of containerized applications <NUM>. Thus, server <NUM> is not required to have any knowledge of containerized applications <NUM> and provide configuration settings to computing devices <NUM> each time a new containerized application is launched. Instead, whenever a containerized application is launched, the containerized application obtains its configuration settings via host operating system <NUM>. This advantageously reduces the network traffic between computing device(s) <NUM> and server <NUM> and the load experienced by computing device(s) <NUM> and server <NUM>.

After configuration settings <NUM> are applied by host operating system <NUM> and containerized applications <NUM>, computing devices(s) <NUM> provide a response to server <NUM> that indicates that the results of applying the configuration settings thereon. For instance, the results may indicate whether the application of configuration settings <NUM> was successful or failed. Upon receiving the response with results specifying that each of configuration settings <NUM> were successfully applied from a particular computing device of computing device(s) <NUM>, compliance engine <NUM> designates the computing device from which the response was received as being in compliance with the compliance rule(s), and the computing device enabled to access resources of network <NUM>.

Upon receiving a response with results specifying that one or more of the configuration settings were not successfully applied, compliance engine <NUM> may determine that the particular computing device is not in compliance and/or prevent such computing device(s) from accessing a resource accessible via network <NUM>. Such resources include, but are not limited to an email server, a data repository, an application server, etc. Access to such resources may be prevented until computing device(s) <NUM> are in compliance.

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> that are communicatively coupled via a network <NUM>. Server <NUM>, computing device <NUM>, and network <NUM> are examples of server <NUM>, computing device <NUM>, and network <NUM>, as respectively described above with reference to <FIG>. As also shown in <FIG>, server <NUM> comprises compliance engine <NUM> and configuration settings <NUM>, which are examples of compliance engine <NUM> and configuration settings <NUM>, as respectively described above with reference to <FIG>. Computing device <NUM> comprises a host operating system <NUM> and a containerized application <NUM>, which are examples of host operating system <NUM> and containerized application <NUM>, as described above with reference to <FIG>.

Host operating system <NUM> comprises a configuration agent <NUM>, a local data store <NUM>, and a results merger <NUM>. Configuration agent <NUM> is configured to receive configuration settings <NUM> from server <NUM> via network <NUM>. In accordance with an embodiment, the provision of configuration settings <NUM> by server <NUM> is initiated by configuration agent <NUM>. For example, configuration agent <NUM> may query (or "check-in" with) server <NUM> to determine whether server <NUM> comprises configuration settings <NUM> that are to be applied to computing device <NUM>. Configuration agent <NUM> may query server <NUM> on a periodic basis. However, the embodiments described herein are not so limited. For instance, configuration agent <NUM> may query server <NUM> responsive to a command from a user. In accordance with another embodiment, the provision of configuration settings <NUM> by server <NUM> is initiated by server <NUM>. For example, compliance engine <NUM> may determine that new configuration settings are to be provided to computing device <NUM> and provide (or "push") such settings to configuration agent <NUM>.

After receiving configuration settings <NUM>, configuration agent <NUM> determines one or more settings of configuration settings <NUM> that are applicable to host operating system <NUM> and applies them to the appropriate operating system components (e.g., kernel, registry, drivers, etc.) and/or applications of host operating system <NUM>. For instance, configuration agent <NUM> may apply one or more filtering rules <NUM> to determine whether particular settings of configuration settings <NUM> are applicable to host operating system <NUM>. Each filtering rule may comprise an indication as to whether a particular configuration setting of configuration settings <NUM> is to be applied to host operating system <NUM>, containerized application <NUM>, or both host operating system <NUM> and containerized application <NUM>. For example, a rule may comprise an identifier of an anti-virus application (e.g., Windows® Defender, published by Microsoft® Corporation of Redmond Washington) and an indication as to whether the anti-virus application is to be configured for host operating system <NUM>, containerized application <NUM>, or both host operating system <NUM> and containerized application <NUM>. In accordance with an embodiment, the indication may comprise a value, where the value of '<NUM>' specifies that the anti-virus application is to be configured for host operating system <NUM>, a value of '<NUM>' specifies that the anti-virus application is to be configured to for containerized application <NUM>, and a value of '<NUM>' specifies that the anti-virus application is to be configured for both host operating system <NUM> and containerized application <NUM>. Configuration agent <NUM> analyzes the indication of each filtering rule to determine whether the corresponding configuration setting of configuration settings <NUM> is to be applied to host operating system <NUM>.

In accordance with an embodiment, filtering rules <NUM> may be provided by and/or subsequently updated by a filtering rules service <NUM>. Filtering rules service <NUM> may execute on a server <NUM> communicatively coupled to computing device <NUM> via network <NUM>, as shown in <FIG>. Alternatively, filtering rules service <NUM> may execute on server <NUM>. Filtering rules service <NUM> may be configured to periodically provide updated filtering rules to computing device <NUM>. This advantageously provides the flexibility with regards to configuring computing device <NUM>, as configuration requirements for computing device <NUM> may change over time. An example of filtering rules service <NUM> includes, but is not limited to, Microsoft® OneSettings, published by Microsoft® Corporation of Redmond, Washington.

Configuration agent <NUM> stores configuration settings <NUM> and filtering rules <NUM> in local data store <NUM> maintained by host operating system <NUM>. Configuration agent <NUM> also stores the results (shown as results <NUM>) of applying the applicable configuration settings of configuration settings <NUM> in local data store <NUM>. For instance, results <NUM> may indicate whether the application of each of the applicable settings of configuration settings <NUM> were successful or failed.

Local data store <NUM> is integrated as part of computing device <NUM>. Local data store <NUM> may be any type of physical memory and/or storage device (or portion thereof) 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. Local data store <NUM> is be made accessible to containerized application <NUM>.

Containerized application <NUM> comprises a configuration agent <NUM>, a configuration engine <NUM>, and a local data store <NUM>. When a containerized application <NUM> is instantiated (or launched) by host operating system <NUM>, configuration engine <NUM> retrieves configuration settings <NUM> and filtering rules <NUM> from local data store <NUM> and stores configuration settings <NUM> and filtering rules <NUM> in local data store <NUM> maintained by containerized application <NUM>. Local data store <NUM> is integrated as part of computing device <NUM>. Local data store <NUM> may be any type of physical memory and/or storage device (or portion thereof) 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.

Configuration agent <NUM> is configured to retrieve configuration settings <NUM> and filtering rules <NUM> from local data store <NUM>. Configuration agent <NUM> determines one or more settings of configuration settings <NUM> that are applicable to containerized application <NUM> and applies them to the appropriate guest operating system components (e.g., kernel, registry, drivers, etc.) of containerized application <NUM>. For instance, configuration agent <NUM> may apply filtering rule(s) <NUM> to determine whether particular settings of configuration settings <NUM> are applicable to containerized application <NUM>. Each filtering rule may comprise an indication as to whether a particular configuration setting of configuration settings <NUM> is to be applied to host operating system <NUM>, containerized application <NUM>, or both host operating system <NUM> and containerized application <NUM>. Configuration agent <NUM> analyzes the indication of each filtering rule to determine whether the corresponding configuration setting of configuration settings <NUM> is to be applied to containerized application <NUM>.

Configuration agent <NUM> also stores the results (shown as results <NUM>) of applying the applicable configuration settings of configuration settings <NUM> in local data store <NUM>. For instance, results <NUM> may indicate whether the application of each of the applicable settings of configuration settings <NUM> were successful or failed.

Configuration engine <NUM> is configured to retrieve results <NUM> from local data store <NUM> and store results <NUM> in local data store <NUM>. Results merger <NUM> is configured to retrieve results <NUM> and results <NUM> from local data store <NUM>. Results merger <NUM> merges results <NUM> and results <NUM> to generate merged results <NUM> and provides merged results <NUM> to configuration agent <NUM>. Configuration agent <NUM> provides merged results <NUM> to server <NUM> via a response <NUM>.

If response <NUM> comprises results specifying that configuration settings <NUM> were successfully applied on computing device <NUM>, compliance engine <NUM> designates computing device <NUM> as being in compliance, and computing device <NUM> is enabled to access resources of network <NUM>.

If response <NUM> comprises results specifying that one or more of the configuration settings were not successfully applied, compliance engine <NUM> may determine that the computing device <NUM> is not in compliance and/or prevent computing device <NUM> from accessing resource(s) accessible via network <NUM>. Based on the results, compliance engine <NUM> may also provide additional configuration settings to computing device <NUM> that are to be applied by host operating system <NUM> and/or containerized application <NUM>. For instance, the results may indicate that a particular configuration setting was not applied to computing device <NUM> due to an incompatibly between the configuration setting and computing device <NUM>. In response, compliance engine <NUM> may provide an alternate configuration setting to computing device <NUM>.

In accordance with an embodiment, containerized application <NUM> may initiate a request for configuration settings. As server <NUM> is unaware of containerized application <NUM>, host operating system <NUM> provides (or forwards) the request on behalf of containerized application <NUM>. For example, configuration agent <NUM> may provide a request specifying the requested configuration settings to configuration agent <NUM> of host operating <NUM>, and configuration agent <NUM> forwards the request to server <NUM>. Responsive to receiving the request, compliance engine <NUM> provides the requested configuration settings to configuration agent <NUM>. Configuration agent <NUM> stores the configuration results in local data store <NUM>. Configuration engine <NUM> of containerized application <NUM> retrieves the configuration settings from local data store <NUM> and stores the configuration settings in local data store <NUM> of containerized application <NUM>. Configuration agent <NUM> retrieves the configuration settings and applies them to containerized application <NUM>. Additional details regarding containerized application requests for configuration settings are described below with reference to <FIG> and <FIG>.

Accordingly, computing devices may be managed and configured in many ways. For example, <FIG> depicts a flowchart <NUM> of an example method implemented by a computing device for configuring a host operating system and a containerized application executing thereon in accordance with an example embodiment. The method of flowchart <NUM> will be described with continued reference to system <NUM> of <FIG>, although the method is not limited to that implementation. Other structural and operational embodiments will be apparent to persons skilled in the relevant art(s) based on the discussion regarding flowchart <NUM> and system <NUM> of <FIG>.

As shown in <FIG>, the method of flowchart <NUM> begins at step <NUM>, in which a plurality of configuration settings for the computing device are received from a server. For example, with reference to <FIG>, configuration agent <NUM> of host operating system <NUM> executing on computing device <NUM> receives configuration settings <NUM> from server <NUM> via network <NUM>. Server <NUM> may be a mobile device manager.

At step <NUM>, a first subset of configuration settings of the plurality of configuration settings are applied to a host operating system executing on the computing device. For example, with reference to <FIG>, configuration agent <NUM> of host operating system <NUM> applies configuration settings <NUM> to host operating system <NUM>.

In accordance with one or more embodiments, a first filtering rule is applied to the plurality of configuration settings to determine the first subset of configuration settings. The first subset of configuration settings is applicable to the first operating system. For example, with reference to <FIG>, configuration agent <NUM> applies filtering rules <NUM> to configuration settings <NUM> to determine a subset of configuration settings <NUM> that are applicable to host operating system <NUM>. Local data store <NUM> stores filtering rules <NUM>.

At step <NUM>, the configuration settings are stored in a local data store. For example, with reference to <FIG>, configuration agent <NUM> stores configuration settings <NUM> in local data store <NUM>.

At step <NUM>, a containerized application instantiated by host operating system and executing on the computing device retrieves at least a second subset of configuration settings of the plurality of configuration settings from the local data store. For example, with reference to <FIG>, configuration engine <NUM> of containerized application <NUM> retrieves configuration settings <NUM> from local data store <NUM> and stores configuration settings <NUM> in local data store <NUM>. Configuration engine <NUM> may retrieve all of configuration settings <NUM>. Alternatively, configuration engine <NUM> may retrieve and filtering rules <NUM> and utilize filtering rules <NUM> to retrieve a subset of configuration settings of configuration settings <NUM> that are applicable to containerized application <NUM>.

At step <NUM>, the second subset of configuration settings of the plurality of configuration settings are applied to the containerized application. For example, with reference to <FIG>, configuration agent <NUM> of containerized application <NUM> retrieves configuration settings <NUM> from local data store <NUM> and applies the second subset of configuration settings <NUM> to containerized application <NUM>.

In accordance with one or more embodiments, the plurality of configuration settings comprises at least one of a security setting to be implemented for the computing device, a network setting to be implemented for the computing device, an encryption setting to be implemented for the computing device, or an application behavioral setting to be implemented for the containerized application.

In accordance with one or more embodiments, a second filtering rule is applied to the plurality of configuration settings to determine the second subset of configuration settings. The second subset of configuration settings is applicable to the containerized application. For example, with reference to <FIG>, configuration engine <NUM> retrieves filtering rules <NUM> from local data store <NUM>. Configuration agent <NUM> retrieves filtering rules <NUM> and applies filtering rules <NUM> to configuration settings <NUM> to determine a subset of configuration settings <NUM> that are applicable to containerized application <NUM>.

In accordance with one or more embodiment, the first filtering rule and the second filtering rule are received by the host operating system via the network from a filtering rules service. For example, with reference to <FIG>, filtering rules <NUM> are received by host operating system <NUM> via network <NUM> from filtering rules service <NUM> executing on server <NUM>.

<FIG> depicts a flowchart <NUM> of an example method for returning results of the application of configuration settings on a computing device in accordance with an example embodiment. The method of flowchart <NUM> will be described with continued reference to system <NUM> of <FIG>, although the method is not limited to that implementation. Other structural and operational embodiments will be apparent to persons skilled in the relevant art(s) based on the discussion regarding flowchart <NUM> and system <NUM> of <FIG>.

As shown in <FIG>, the method of flowchart <NUM> begins at step <NUM>, in which first results of the application of the first subset of configuration settings are stored in the local data store. The first results indicate whether the application of the first subset of configuration settings was successful. For example, with reference to <FIG>, configuration agent <NUM> stores results <NUM> of the application of the first subset of configuration settings <NUM> in local data store <NUM>.

At step <NUM>, second results of the application of the second subset of configuration settings are stored in the local data store. The second results indicate whether the application of the second subset of configuration settings was successful. For example, with reference to <FIG>, configuration agent <NUM> of containerized application <NUM> stores results <NUM> of the application of the second subset of configuration settings <NUM> in local data store <NUM>. Configuration engine <NUM> retrieves results <NUM> from local data store <NUM> and stores results <NUM> in local data store <NUM>.

At step <NUM>, the first results and the second results are merged to generate merged results. For example, with reference to <FIG>, results merger <NUM> retrieves results <NUM> and results <NUM> from local data store <NUM> and merges results <NUM> and results <NUM> to generate merged results <NUM>.

At step <NUM>, the merged results are provided to the server via the network. For example, with reference to <FIG>, results merger <NUM> provides merged results <NUM> to configuration agent <NUM>, and configuration agent <NUM> provides merged results <NUM> via network <NUM> to server <NUM> via response <NUM>.

In accordance with one or more embodiments, additional configuration settings are received from the server via the network based on the merged results. For example, with reference to <FIG>, based on merged results <NUM>, server <NUM> may determine additional configuration settings for computing device <NUM> and provide them to computing device <NUM> via network <NUM>. Computing device <NUM> may apply the additional configuration settings in accordance with flowchart <NUM>, as described above.

<FIG> depicts a flowchart <NUM> of an example method for providing a request for configuration settings from a containerized application to a mobile device manager in accordance with an example embodiment. The method of flowchart <NUM> will now be described with reference to <FIG>, although flowchart <NUM> is not limited to the implementation depicted therein. <FIG> is a block diagram of a system <NUM> for configuring a computing device for compliance in accordance with an example embodiment. As shown in <FIG>, system <NUM> comprises a server <NUM>, a server <NUM>, and a computing device <NUM> communicatively coupled via a network <NUM>. Server <NUM>, server <NUM>, computing device <NUM>, and network <NUM> are examples of server <NUM>, server <NUM>, computing device <NUM>, and network <NUM>, as described above with reference to <FIG>. Server <NUM> comprises compliance engine <NUM> and configuration settings <NUM>, which are examples of compliance engine <NUM> and configuration settings <NUM>, as described above with reference to <FIG>. Server <NUM> comprises a filtering rules service <NUM>, which is an example of filtering rules service <NUM>, as described above with reference to <FIG>. Computing device <NUM> comprises a host operating system <NUM> and a containerized application <NUM>, which are examples of host operating system <NUM> and containerized application <NUM>, as described above with reference to <FIG>. Host operating system <NUM> comprises a configuration agent <NUM>, filtering rules <NUM>, a results merger <NUM>, and a local data store <NUM>, which are examples of configuration agent <NUM>, filtering rules <NUM>, results merger <NUM>, and local data store <NUM>. Local data store <NUM> stores configuration settings <NUM>, filtering rules <NUM>, results <NUM>, and results <NUM>. Results <NUM> and results <NUM> are examples of results <NUM> and results <NUM>, as described above with reference to <FIG>. Containerized application <NUM> comprises a configuration agent <NUM>, a configuration engine <NUM>, and a local data store <NUM>, which are examples of configuration agent <NUM>, configuration engine <NUM>, and local data store <NUM>, as described above with reference to <FIG>. Local data store <NUM> stores configuration settings <NUM>, filtering rules <NUM>, and results <NUM>. Other structural and operational embodiments will be apparent to persons skilled in the relevant art(s) based on the discussion regarding flowchart <NUM> and system <NUM> of <FIG>.

As shown in <FIG>, the method of flowchart <NUM> begins at step <NUM>, in which a request for additional configuration settings is provided by the containerized application and to the host operating system. For example, with reference to <FIG>, configuration agent <NUM> of containerized application may provide a request <NUM> for additional configuration settings to configuration agent <NUM> of host operating system <NUM>.

At step <NUM>, the request is forward by the host operating system to the server via the network. For example, with reference to <FIG>, configuration agent <NUM> forwards request <NUM> to server <NUM> via network <NUM>.

At step <NUM>, the additional configuration settings are received by the host operating system from the server via the network. For example, with reference to <FIG>, configuration agent <NUM> receives the additional configuration settings (e.g., configuration settings <NUM>) from server <NUM> via network <NUM>.

At step <NUM>, the additional configuration settings are stored in the local data store. For example, with reference to <FIG>, configuration agent <NUM> stores the additional configuration settings in local data store <NUM>.

At step <NUM>, the containerized application retrieves the additional configuration settings from the local data store. For example, with reference to <FIG>, configuration engine <NUM> retrieves the additional configuration settings (e.g., configuration settings <NUM>) from local data store <NUM> and stores the settings in local data store <NUM>. Configuration agent <NUM> retrieves the settings from local data store <NUM> and applies the settings to containerized application <NUM>.

The systems and methods described above, including the device management and configuration 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, server <NUM>, compliance engine <NUM>, computing device(s) <NUM>, host operating system <NUM>, containerized applications <NUM>, server <NUM>, compliance engine <NUM>, computing device <NUM>, host operating system <NUM>, containerized application <NUM>, configuration agent <NUM>, local data store <NUM>, results merger <NUM>, configuration agent <NUM>, local data store <NUM>, configuration engine <NUM>, server <NUM>, compliance engine <NUM>, computing device <NUM>, host operating system <NUM>, containerized application <NUM>, configuration agent <NUM>, local data store <NUM>, results merger <NUM>, configuration agent <NUM>, local data store <NUM>, configuration engine <NUM> and/or each of the components described therein, and flowchart <NUM>, <NUM>, and/or flowchart <NUM> 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, server <NUM>, compliance engine <NUM>, computing device(s) <NUM>, host operating system <NUM>, containerized applications <NUM>, server <NUM>, compliance engine <NUM>, computing device <NUM>, host operating system <NUM>, containerized application <NUM>, configuration agent <NUM>, local data store <NUM>, results merger <NUM>, configuration agent <NUM>, local data store <NUM>, configuration engine <NUM>, server <NUM>, compliance engine <NUM>, computing device <NUM>, host operating system <NUM>, containerized application <NUM>, configuration agent <NUM>, local data store <NUM>, results merger <NUM>, configuration agent <NUM>, local data store <NUM>, configuration engine <NUM> and/or each of the components described therein, and flowchart <NUM>, <NUM>, and/or flowchart <NUM> may be implemented as hardware logic/electrical circuitry. In an embodiment, server <NUM>, compliance engine <NUM>, computing device(s) <NUM>, host operating system <NUM>, containerized applications <NUM>, server <NUM>, compliance engine <NUM>, computing device <NUM>, host operating system <NUM>, containerized application <NUM>, configuration agent <NUM>, local data store <NUM>, results merger <NUM>, configuration agent <NUM>, local data store <NUM>, configuration engine <NUM>, server <NUM>, compliance engine <NUM>, computing device <NUM>, host operating system <NUM>, containerized application <NUM>, configuration agent <NUM>, local data store <NUM>, results merger <NUM>, configuration agent <NUM>, local data store <NUM>, configuration engine <NUM> and/or each of the components described therein, and flowchart <NUM>, <NUM>, and/or flowchart <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.

<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 server <NUM>, compliance engine <NUM>, computing device(s) <NUM>, host operating system <NUM>, containerized applications <NUM>, server <NUM>, compliance engine <NUM>, computing device <NUM>, host operating system <NUM>, containerized application <NUM>, configuration agent <NUM>, local data store <NUM>, results merger <NUM>, configuration agent <NUM>, local data store <NUM>, configuration engine <NUM>, server <NUM>, compliance engine <NUM>, computing device <NUM>, host operating system <NUM>, containerized application <NUM>, configuration agent <NUM>, local data store <NUM>, results merger <NUM>, configuration agent <NUM>, local data store <NUM>, configuration engine <NUM> and/or each of the components described therein, and flowchart <NUM>, <NUM>, and/or flowchart <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 server <NUM>, compliance engine <NUM>, computing device(s) <NUM>, host operating system <NUM>, containerized applications <NUM>, server <NUM>, compliance engine <NUM>, computing device <NUM>, host operating system <NUM>, containerized application <NUM>, configuration agent <NUM>, local data store <NUM>, results merger <NUM>, configuration agent <NUM>, local data store <NUM>, configuration engine <NUM>, server <NUM>, compliance engine <NUM>, computing device <NUM>, host operating system <NUM>, containerized application <NUM>, configuration agent <NUM>, local data store <NUM>, results merger <NUM>, configuration agent <NUM>, local data store <NUM>, configuration engine <NUM> and/or each of the components described therein, and flowchart <NUM>, <NUM>, and/or flowchart <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 management and configuration 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.

Claim 1:
A method implemented by a computing device (<NUM>), comprising:
receiving (<NUM>) a plurality of configuration settings (<NUM>) for the computing device from a server (<NUM>) via a network (<NUM>);
applying (<NUM>) a first subset of configuration settings of the plurality of configuration settings to a host operating system (<NUM>) executing on the computing device;
storing (<NUM>) the configuration settings (<NUM>) and first results (<NUM>) of applying the applicable configuration settings in a local data store (<NUM>), the first results indicating whether the application of the first subset of configuration settings was successful;
responsive to a containerized application being instantiated by the host operating system on the computing device, retrieving (<NUM>), by the containerized application, at least a second subset of configuration settings of the plurality of configuration settings from the local data store; and
applying (<NUM>) the second subset of configuration settings of the plurality of configuration settings to the containerized application and storing second results (<NUM>) of the application of the second subset of configuration settings in the local data store, the second results indicating whether the application of the second subset of configuration settings was successful;
the method further comprising:
merging the first results (<NUM>) and the second results (<NUM>) to generate merged results (<NUM>); and
providing the merged results to the server via the network.