Obviousness — US Patent 9542571

Obviousness Analysis of US Patent 9542571 under 35 U.S.C. § 103

This analysis identifies combinations of prior art references that would render the independent claims of US Patent 9542571 obvious to a person having ordinary skill in the art (POSITA) at the time of the invention (i.e., before the earliest priority date of April 30, 2004, or the later filing date of May 18, 2015, for any new matter). The primary prior art identified is US Patent 7,793,355, which is explicitly incorporated by reference into US9542571 and shares a priority date of December 12, 2002.

Background Prior Art: US Patent 7,793,355

US Patent 9,542,571 is a continuation-in-part of U.S. Pat. No. 8,302,185, which is a continuation of U.S. Pat. No. 7,793,355. U.S. Pat. No. 7,793,355 (hereinafter "Little") claims priority to U.S. Provisional Application No. 60/432,610 filed December 12, 2002. Little generally teaches a method of controlling an electronic device by an owner. It includes inserting owner information with data integrity and/or source authentication information onto the device, receiving owner control information, verifying its integrity, and storing and using the verified information to control device operations. Crucially, Little discloses that an application loader stores applications to a software application store only if the applications are in an authorized application list included in the owner control information. The background of US9542571 itself discusses a known scheme where "an owner loads a policy file onto a device to restrict the type of operations or software applications that may be executed by the device," and identifies the problem of users circumventing these policies.

Obviousness of Independent Claim 1 (Method of owner application control)

Claim 1: A method for owner application control of an electronic device, the method comprising:

storing, at an electronic device, owner control information for controlling operation of the electronic device, the owner control information comprising a required list identifying one or more applications required for full operation of the electronic device;
receiving an operation request at the electronic device;
verifying, responsive to the operation request, that each application in the required list is available for execution on the electronic device;
if the verifying determines that at least one application in the required list is not available for execution, disabling at least one operation of the electronic device until each application in the required list is available for execution; and
initiating download and installation of each application in the required list that is not available for execution from an external application source.

Combination of Prior Art: Little (U.S. Pat. No. 7,793,355) in combination with the general knowledge of a POSITA in enterprise device management.

Reasoning:

Storing owner control information comprising a required list: Little already teaches storing owner control information (e.g., policy files or authorization records) to control device operations and application installation, specifically mentioning an "authorized application list." A POSITA in enterprise device management would readily understand the need for both "allowed" (or "authorized") applications and "required" applications. In a corporate context, an owner would want to ensure certain applications (e.g., security software, essential communication tools) are always present and functional. The concept of a "required list" is a logical and obvious extension of an "authorized list" to mandate rather than merely permit software. US9542571 defines "required software application list" as identifying applications "mandatory" for the owner. This is a natural progression of owner control to enforce corporate policies and ensure core functionality, as also hinted at by the problem of users circumventing policies discussed in the background.
Receiving an operation request and verifying availability of required applications: Given that owner control information includes a "required list," it would be obvious for a POSITA to implement a mechanism to periodically (or in response to events like operation requests or device initialization) check if these mandatory applications are indeed present and available for execution. US9542571 describes such verification, noting that the "processor 40, application loader 42, insertion module 44, or a further device component or system is configured to periodically check to ensure that each required software application is present on the mobile device 30." This verification step is a fundamental aspect of enforcing any "required" policy.
Disabling at least one operation if required applications are not available: If applications are "required for full operation" of an electronic device, it is an obvious enforcement mechanism for a POSITA to disable certain functionalities or the entire device if these critical applications are missing. This directly addresses the problem of users circumventing policies and ensures compliance or protects the device/network if essential software (e.g., antivirus) is absent. US9542571 explicitly states that "If required applications are missing the device is disabled in part, or in whole." This is a known method for enforcing compliance in managed IT environments.
Initiating download and installation of missing required applications: Once it is determined that a "required" application is missing, the most logical and efficient way to rectify the situation and restore full device operability and policy compliance is to automatically download and install the missing application. This transparent remediation step prevents prolonged device disability and reduces administrative burden. US9542571 describes this as "the device may transparently initiate download of required applications that were determined to be unavailable." This is a standard and obvious practice in system administration for software deployment and patching.

Motivation to Combine: A POSITA, seeking to create a comprehensive and robust owner control system for electronic devices as broadly taught by Little, would be motivated to extend the existing "authorized application list" concept to include "required applications." Furthermore, to effectively enforce such "required" policies and ensure device integrity/functionality, the POSITA would find it obvious to implement verification steps, disable non-compliant devices, and provide automated remediation through downloading and installing missing applications. These additions are straightforward engineering solutions to known problems in managing networked electronic devices and directly address the need for owner control beyond simple authorization, as described in the background of US9542571.

Obviousness of Independent Claim 11 (System for owner application control)

Claim 11: A system for owner application installation control of an electronic device, the system comprising:

an owner control information store configured to store owner control information comprising a required list identifying one or more applications required for full operation of the electronic device;
initialization processor instructions embodied on a computer readable medium, the initialization processor instructions for verifying, responsive to an operation request, that an application in the required list is available for execution on the electronic device;
an application loader module that is invoked by the initialization instructions when the application in the required list is not available for execution and that downloads the application from an external application source and installs it on the electronic device; and
operation control instructions embodied on a computer readable medium that disable at least one operation of the electronic device until the application loader module completes installation of the application.

Combination of Prior Art: Little (U.S. Pat. No. 7,793,355) in combination with the general knowledge of a POSITA in software and system engineering.

Reasoning: If the method described in Claim 1 is obvious, then the system configured to perform that method would also be obvious.

Owner control information store with a required list: As established for Claim 1, creating a data store for owner control information that includes a "required list" is an obvious extension of Little's teachings.
Initialization processor instructions for verifying: Implementing software instructions (e.g., a software module or application executed by a processor) to perform the verification steps for required applications is a standard programming task for a POSITA. US9542571 mentions the "processor 40, application loader 42, insertion module 44, or a further device component or system is configured to periodically check" for required applications.
Application loader module for download and installation: Little already discusses an "application loader" that stores applications based on an authorized list. Modifying or extending this existing module to handle automatic downloading and installation of missing "required" applications from an external source is a routine engineering task, given the motivation for such functionality.
Operation control instructions to disable operations: Programming instructions to disable certain device operations (e.g., restricting access to features, network connectivity, or the entire user interface) as an enforcement mechanism is well within the capabilities of a POSITA.

Motivation to Combine: A POSITA would be motivated to implement the system components necessary to carry out the obvious method of Claim 1. The functional requirements to store policy, verify compliance, disable non-compliant devices, and auto-remediate missing software would naturally lead to the system architecture described in Claim 11, using well-known software and hardware design principles.

Obviousness of Independent Claim 19 (Method for designating owner control of application operations)

Claim 19: A method for designating owner control of application operations for an electronic device, the method comprising:

receiving an operation indication of one or more operations associated with a particular application;
generating an authorization record based upon the received operation indication and the particular application;
storing the generated authorization record;
receiving a device indication of one or more electronic devices subject to owner control;
receiving a correspondence indication that associates the received device indication with one or more stored authorization records; and
communicating one or more stored authorization records to one or more electronic devices based upon the received device indication and the received correspondence indication.

Combination of Prior Art: Little (U.S. Pat. No. 7,793,355) in combination with the general knowledge of a POSITA in system administration and user interface design for enterprise software.

Reasoning:

Receiving operation indication, generating, and storing authorization record: Little teaches an owner loading "policy files" or "authorization records" onto a device to restrict operations and applications. The steps of defining these policies (receiving indications of desired controls for applications) and formalizing them into a storable "authorization record" are fundamental to any policy-driven system. US9542571 shows an "exemplary user interface on a remote server for an owner to designate application control information" (FIG. 9). Such user interfaces and the underlying logic to generate and store policy data are standard in system administration tools.
Receiving device indication, correspondence indication, and communicating authorization records: Little describes the insertion and use of owner control information on electronic devices. To deploy these policies in an enterprise setting, a POSITA would find it obvious to identify which devices (or groups of devices, as suggested by US9542571, col. 28, lines 18-19) are subject to particular policies, associate those policies with the devices, and then communicate (distribute) the relevant authorization records to them. This involves common functionalities found in device management systems, such as device enrollment, group management, and policy push mechanisms. US9542571 reiterates this, stating "An information technology manager for the device owner can control the policy for a given set of devices by changing the provided configuration information. Such changes could then be transmitted to individual devices."

Motivation to Combine: A POSITA, building on the owner control mechanisms of Little, would naturally be motivated to create an efficient system for the owner to manage and designate these controls across multiple devices. The steps outlined in Claim 19 are standard practices for administrators managing software and policies in a networked environment. Creating a user interface or other means for an owner to input policy decisions, generate machine-readable records, and then selectively distribute those records to target devices is an obvious administrative complement to the device-side enforcement.

Disclaimer: This analysis is based on the provided patent text and readily available prior art information. A full obviousness analysis would typically involve a broader prior art search and a more detailed claim construction.

Citations:

US9542571B2.