DETAILED ACTION
Claims 1-20 are presented for examination.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Comment – re: 35 USC § 101
Claims 1-20 are deemed to present statutory subject matter. Claims 1-20 fall into at least one category of statutory subject matter (claims 1-10 being process claims and claims 11-20 being article of manufacture claims). While the claims may incorporate some abstract concepts (like “determining whether the managed endpoint is enrolled in a mobile device management (MDM) environment,” recited in the independent claims), the claims are not specifically directed to any judicial exceptions. Even if an abstract idea were identified in the claims, the operations of the claims mainly focus on technical operations that help improve technical computing operations by presenting an algorithm for detecting the need for an operating system (OS) product update and the implementation of the OS product update on an endpoint device. Thus, the specific technical operations presented in the claims would be deemed to present significantly more than any abstract idea(s).
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-5 and 11-15 are rejected under 35 U.S.C. 102(a)(1)/(a)(2) as being anticipated by Shantharam et al. (US 2018/0173517).
[Claim 1] Shantharam discloses a method of product update management in systems having product access restrictions associated with administrative credentials (¶ 29 – “The update policies 151 can include constraints specified by an administrator for a client device 106 to be in “compliance” with the management service 118. The update policies 151 can include compliance rules or other criteria. In one example, the agent application 124 can configure hardware or software functionality of a client device 106 such that the client device 106 is in conformance with the update policies 151. For instance, an administrator can specify particular types of software updates 145 that are automatically installed on the client devices 106. Additionally, the agent application 124 can identify when the client device 106 is not in conformance with the update policies 151, as well as other policies, and can take appropriate remedial actions, such as denying access to enterprise data 136, denying installation of a software update 145, or other features of the agent application 124. In further examples, remedial actions can include, for example, encrypting enterprise data 136 such that the enterprise data 136 cannot be accessed until the client devices 106 comes into conformance with the update policies 151, denying access to sharing functions, such as network-based tile transfers, restricting execution of certain client applications, or similar functions.”), the method comprising:
detecting that an operating system (OS) update is outstanding for an OS at a managed endpoint (¶ 15 – “In one example, an agent application executing on an enrolled device can identify when a software update becomes available on the device. When a software update is identified, the agent application can communicate information pertaining to the software update to a management service. For example, the agent application can send an identifier that uniquely identifies the software update to the management service. Additionally, the agent application can prevent the software update from being installed on the enrolled device until authorized by an administrator.”; ¶ 28 – “Software updates 145 can include, for example, an operating system update, an application update, a driver update, a firmware update, or other update to a software component of the client device 106. To this end, the software update data 130 can include identifiers 148a . . . 148b (collectively “identifiers 148”) as well as update policies 151. The identifiers 148 can include strings of alphanumeric characters that uniquely identifies a corresponding one of the software updates 145. For instance, an identifier 148 can be used to retrieve information associated with a particular software update 145 from the data store 115 or the operating system update service 109.”);
communicating a request for an OS update to the managed endpoint (¶ 15 – “In one example, an agent application executing on an enrolled device can identify when a software update becomes available on the device. When a software update is identified, the agent application can communicate information pertaining to the software update to a management service. For example, the agent application can send an identifier that uniquely identifies the software update to the management service. Additionally, the agent application can prevent the software update from being installed on the enrolled device until authorized by an administrator.”; ¶ 28 – “Software updates 145 can include, for example, an operating system update, an application update, a driver update, a firmware update, or other update to a software component of the client device 106. To this end, the software update data 130 can include identifiers 148a . . . 148b (collectively “identifiers 148”) as well as update policies 151. The identifiers 148 can include strings of alphanumeric characters that uniquely identifies a corresponding one of the software updates 145. For instance, an identifier 148 can be used to retrieve information associated with a particular software update 145 from the data store 115 or the operating system update service 109.”);
determining whether the managed endpoint is enrolled in a mobile device management (MDM) environment (¶ 32 – “Device data 133 can include, for example, data pertaining to an enrollment status 154 for individual ones of the client devices 106. In one example, a client device 106 designated as “enrolled” can be permitted to access the enterprise data 136 while a client device 106 designated as “not enrolled” or having no designation can be denied access to the enterprise data 136. Device data 133 can also include data pertaining to user groups 157. An administrator can specify one or more of the client devices 106 as belonging to a particular user group 157. The management service 118 can use a deployment profile 139 applicable to the particular user group 157 to instruct the agent application 124 to download specified software updates 145 as well as perform an installation of the software updates 145.”; ¶ 21 – “As referred to herein, enrollment oft client device 106 with the management service 118 can include the client device 106 subscribing or registering with the management service 118 such that the management service 118 can manage or oversee operation of the client device 106.”; ¶ 86 – “The client devices 106 or devices comprising the computing environment 103 can include at least one processor circuit, for example, having a processor and at least one memory device, both of which are coupled to a local interface, respectively. The device can include, for example, at least one computer, a mobile device, smartphone, computing device, or like device.”);
in response to a determination that the managed endpoint is enrolled in the MDM environment, communicating a request for an MDM call to an MDM module of a management device, wherein the MDM module includes authority to initiate the OS update at the managed endpoint (¶ 32 – “Device data 133 can include, for example, data pertaining to an enrollment status 154 for individual ones of the client devices 106. In one example, a client device 106 designated as “enrolled” can be permitted to access the enterprise data 136 while a client device 106 designated as “not enrolled” or having no designation can be denied access to the enterprise data 136. Device data 133 can also include data pertaining to user groups 157. An administrator can specify one or more of the client devices 106 as belonging to a particular user group 157. The management service 118 can use a deployment profile 139 applicable to the particular user group 157 to instruct the agent application 124 to download specified software updates 145 as well as perform an installation of the software updates 145.”);
queuing and scheduling an OS update command with an MDM requester (¶ 26 – “In any case, the agent application 124 can retrieve the contents of the command queue by checking in with the management service 118 and requesting the contents of the command queue. In one example, the contents of the command queue can include a command that the agent application 124 should cause to be executed on the client device 106. In another example, the contents of the command queue can include a resource or client application that the agent application 124 should cause to be installed on the client device 106, which the client device 106 may access through a specified uniform resource locator (URL).”; ¶ 50 – “Turning now to FIG. 3, shown is another example of a user interface 169 of an administrator console generated by the computing environment 103. The computing environment 103 can generate a user interface 169 to provide an administrator with all software updates 145 available to a particular one of the client devices 106 (“Rsmith's Desktop”) enrolled with the management service 118. In some examples, the administrator can use the user interface 169 shown in FIG. 3 to cause installations or removals of software updates 145 on the client device 106. For instance, software updates 145 can be shown in the user interface 169 to await approval by the administrator. Based on an approval of a software update 145, a deployment profile 139 can be generated that causes an agent application 124 executable on the client device 106 to cause an installation of the software update 145 on the client device 106,”; ¶ 51 – “As can be appreciated, installation of software updates 145 may not be instantaneous. Accordingly, the administrator console can provide an administrator with a status of installation (or removal) of individual ones of the software updates 145. In the example of FIG. 3, the user interface 169 shows that 22 software updates 145 are available for the client device 106, 20 of the software updates 145 have been, approved by an administrator, and 14 of the software updates 145 have been installed on the client device 106. As can be appreciated, two of the software updates 145 await approval from an administrator before being deployed on the client device 106.”; ¶ 61 – “Alternatively, if the software update 145 has been approved, the process can proceed to step 515 where the client device 106 can start installation of the software update 145. In some examples, the agent application 124 can generate a command line argument to start an installation of the software update 145. Additionally, the installation of the software update 145 can be performed silently, as a background process unnoticeable by the user of the client device 106, based on a tag of the command line argument. Thereafter, the process can proceed to completion.”);
communicating, by the MDM requester, an update command to a vendor agent of the managed endpoint (¶ 32 – “Device data 133 can include, for example, data pertaining to an enrollment status 154 for individual ones of the client devices 106. In one example, a client device 106 designated as “enrolled” can be permitted to access the enterprise data 136 while a client device 106 designated as “not enrolled” or having no designation can be denied access to the enterprise data 136. Device data 133 can also include data pertaining to user groups 157. An administrator can specify one or more of the client devices 106 as belonging to a particular user group 157. The management service 118 can use a deployment profile 139 applicable to the particular user group 157 to instruct the agent application 124 to download specified software updates 145 as well as perform an installation of the software updates 145.”);
interfacing with a third party update service to retrieve an OS product update (¶ 35 – “The operating system update service 109 can include a service independent from those of the computing, environment 103 and operated by an entity who oversees software updates 145 for a particular platform of operating system 166. For example, the operating system update service 109 can include the Windows® Server Update Services (WSUS) operated by Microsoft® or similar services. The operating system 166 can communicate with the operating system update service 109 to periodically check for software updates 145.”; ¶ 74 – “Hence, in step 606, the identifier 148 can be used to query a service to identify information pertaining to the software update 145. In one example, the computing environment 103 can query the operating system update service 109 to identify information pertaining to the software update 145. The operating system update service 109 may be a service operated by an entity who oversees updates for an operating system. For example, the operating system update service 109 can include WSUS operated by Microsoft® or similar services.”; ¶ 63 – “In one example, the agent application 124 can check for available software updates 145 periodically by generating and executing a command line argument, as described above with respect to step 503. Additionally, the agent application 124 can communicate information pertaining to the one or more software updates 145 to the management service 118. In some examples, the identifier can be generated by an entity providing the software update 145 that uniquely identifies the software update 145. For example, the agent application 124 can send an identifier 148 that uniquely identifies the software update 145 to the management service.”; ¶ 52 – “…the software update 145 can be obtained from the operating system update service 109, the computing environment 103, or from another suitable service.”); and
communicating with the OS to initiate a product update operation, wherein the product update operation is implemented to modify the OS at the managed endpoint to install the OS product update (¶ 35 – “The operating system update service 109 can include a service independent from those of the computing, environment 103 and operated by an entity who oversees software updates 145 for a particular platform of operating system 166. For example, the operating system update service 109 can include the Windows® Server Update Services (WSUS) operated by Microsoft® or similar services. The operating system 166 can communicate with the operating system update service 109 to periodically check for software updates 145.”; ¶ 74 – “Hence, in step 606, the identifier 148 can be used to query a service to identify information pertaining to the software update 145. In one example, the computing environment 103 can query the operating system update service 109 to identify information pertaining to the software update 145. The operating system update service 109 may be a service operated by an entity who oversees updates for an operating system. For example, the operating system update service 109 can include WSUS operated by Microsoft® or similar services.”; ¶ 63 – “In one example, the agent application 124 can check for available software updates 145 periodically by generating and executing a command line argument, as described above with respect to step 503. Additionally, the agent application 124 can communicate information pertaining to the one or more software updates 145 to the management service 118. In some examples, the identifier can be generated by an entity providing the software update 145 that uniquely identifies the software update 145. For example, the agent application 124 can send an identifier 148 that uniquely identifies the software update 145 to the management service.”; ¶ 52 – “…the software update 145 can be obtained from the operating system update service 109, the computing environment 103, or from another suitable service.”).
[Claim 2] Shantharam discloses communicating an update status to a vulcore endpoint at the management device (¶ 18 – “The computing environment 103 can include, for example, a server computer or any other system providing computing capability. Alternatively, the computing environment 103 can include a plurality of computing devices that are arranged, for example, in one or more server banks, computer banks, or other arrangements. The computing environments 103 can include a grid computing resource or any other distributed computing arrangement. The computing devices can be located in a single installation or can be distributed among many different geographical locations. The computing environments 103 can also include or be operated as one or more virtualized computer instances.”; NOTE: Applicant’s Specification states, “The vulcore endpoint 217 is a virtual location on the remote management device 104.” (Spec: ¶ 80) In other words, the vulcore endpoint at the management device performs its respective operations via a virtual location. Shantharam explains that the computing environments may be operated as one or more virtualized computer instances, which implies that the “server computer or any other system providing computing capability” (described in ¶ 18 of Shantharam) may be implemented as virtual devices. Shantharam also describes system elements that perform the operations attributed to the vulcore endpoint at the management device; therefore, Shantharam is interpreted as disclosing an example of a vulcore endpoint at the management device.; ¶ 30 – “In some examples, the management service 118 communicates with the agent application 124 or other client application executable on the client device 106 to determine whether vulnerabilities exist on the client device 106 that do not satisfy update policies 151. Vulnerabilities can include, for example, the presence of a virus or malware on the client device 106, the client device 106 being “rooted” or “jailbroken” where root access is provided to a user of the client device 106, the presence of particular applications or tiles, questionable device configurations, vulnerable versions of client applications, or other vulnerability as can be appreciated. The software update data 130 can include additional information pertaining to software updates 145, as will be described.”; ¶ 24 – “The management service 118 can direct the agent application 124 to perform device management functions on the client device 106. For example, the management service 118 can direct the agent application 124 to control access to certain software or hardware functions available on the client device 106. In one example, the agent application 124 can permit or restrict access to particular software applications on the client device 106. In another examples, the agent application 124 can permit or restrict access to camera functions, global positioning system (GPS) modules, networking hardware, such as Bluetooth® modules and mobile hotspots, or other hardware functions. As a result, the management service 118 can verify that the configuration and operation of the client device 106 is in conformance with predefined criteria that ensures that enterprise data, or other data, is protected from data loss, unauthorized access, or other harmful event.”).
[Claim 3] Shantharam discloses wherein:
the update status includes a success message or an error message of the product update operation (¶ 49 – “The user interface 169 can include various information associated with software updates 145, such as the information obtained from the operating system update service 109. Additionally, the user interface 169 can include information pertaining to a deployment of a software update 145 to a user group 157 or collection of user groups 157. For example, the first one of the software updates 145a is shown as pending installation on two devices while having, been installed on seven devices (for a total of nine devices in the user groups 157).”); and
the update status is assessed and communicated by an agent at the managed endpoint (fig. 1, ¶¶ 15-16, 23, 40-41, 51, 83-84 – An agent application and/or another application running on the client device convey(s) data regarding installation status, including a need for authorization to install updated software and a date and time when the metadata for the update finished downloading, both of which present information implying a success or error related to a software download.).
[Claim 4] Shantharam discloses requesting a vendor agent for an inventory synchronization with a mobile sync module of the managed endpoint (¶¶ 63-66 – Software updates are evaluated for incompatibilities, potential threats, comparison of current software to available revision number of an update.); and
communicating to the mobile sync module a call with a current version number of the OS update to a status module (¶¶ 63-66 -- Software updates are evaluated for incompatibilities, potential threats, comparison of current software to available revision number of an update.; ¶ 13 – Function calls are invoked to a library of the operation system as part of the process of updating software on a device.).
[Claim 5] Shantharam discloses checking a version of the OS at the managed endpoint, wherein the checking the version includes verifying a version of a pending OS update includes an equal or lower version number than a current version at the managed endpoint (¶ 65 – “The administrator can then make an informed decision whether to authorize or prevent a software update 145 from being installed on a client device 106. For instance, certain characteristics of a software update 145 can indicate a trustworthiness of the software update 145, such as a type of the update, a revision number, or a publication date indicative of the software update 145.”; ¶ 66 – “In one example, an administrator can use a revision number associated with a software update 145 to determine whether similar software updates 145 having the same revision number are stable when installed on other client devices 106, or determine whether the similar software updates 145 are incompatible with various client devices 106. In another example, the revision number can indicate whether a software update 145 is the most recently released version of the software update 145. As can be appreciated, the most recently released version or most recent publication date may include the most stable release of a software update 145.”; ¶ 63 – “According to various examples, the computing environment 103 can oversee software updates 145 performed on client devices 106 enrolled with or otherwise managed by the management service 118. As a result, software updates 145 performed on devices can be managed such that software updates 145 are not installed that can subject the device to data loss or unauthorized data access. To this end, the agent application 124 executing on a client device 106 can be configured to identify when one or more software updates 145 become available on the client device 106. In one example, the agent application 124 can check for available software updates 145 periodically by generating and executing a command line argument, as described above with respect to step 503. Additionally, the agent application 124 can communicate information pertaining to the one or more software updates 145 to the management service 118. In some examples, the identifier can be generated by an entity providing the software update 145 that uniquely identifies the software update 145. For example, the agent application 124 can send an identifier 148 that uniquely identifies the software update 145 to the management service. Also, the agent application 124 can delay or prevent installation of the one or more software updates 145 being installed on the enrolled device until authorized by an administrator.”; ¶¶ 41, 65-65 – Having the most recent release and/or the most stable version of software may be a goal for the client device. It is understood that having an equal version of software at a client device compared to the most recent and/or most stable software version would indicate that a software update is not necessarily needed at the time.); and
communicating a success report to a vulcore endpoint in response to the version of the pending OS update being the equal or lower version number than the current version at the managed endpoint (¶ 65 – “The administrator can then make an informed decision whether to authorize or prevent a software update 145 from being installed on a client device 106. For instance, certain characteristics of a software update 145 can indicate a trustworthiness of the software update 145, such as a type of the update, a revision number, or a publication date indicative of the software update 145.”; ¶ 66 – “In one example, an administrator can use a revision number associated with a software update 145 to determine whether similar software updates 145 having the same revision number are stable when installed on other client devices 106, or determine whether the similar software updates 145 are incompatible with various client devices 106. In another example, the revision number can indicate whether a software update 145 is the most recently released version of the software update 145. As can be appreciated, the most recently released version or most recent publication date may include the most stable release of a software update 145.”; ¶ 63 – “According to various examples, the computing environment 103 can oversee software updates 145 performed on client devices 106 enrolled with or otherwise managed by the management service 118. As a result, software updates 145 performed on devices can be managed such that software updates 145 are not installed that can subject the device to data loss or unauthorized data access. To this end, the agent application 124 executing on a client device 106 can be configured to identify when one or more software updates 145 become available on the client device 106. In one example, the agent application 124 can check for available software updates 145 periodically by generating and executing a command line argument, as described above with respect to step 503. Additionally, the agent application 124 can communicate information pertaining to the one or more software updates 145 to the management service 118. In some examples, the identifier can be generated by an entity providing the software update 145 that uniquely identifies the software update 145. For example, the agent application 124 can send an identifier 148 that uniquely identifies the software update 145 to the management service. Also, the agent application 124 can delay or prevent installation of the one or more software updates 145 being installed on the enrolled device until authorized by an administrator.”; ¶¶ 41, 65-65 – Having the most recent release and/or the most stable version of software may be a goal for the client device. It is understood that having an equal version of software at a client device compared to the most recent and/or most stable software version would indicate that a software update is not necessarily needed at the time.; ¶ 18 – “The computing environment 103 can include, for example, a server computer or any other system providing computing capability. Alternatively, the computing environment 103 can include a plurality of computing devices that are arranged, for example, in one or more server banks, computer banks, or other arrangements. The computing environments 103 can include a grid computing resource or any other distributed computing arrangement. The computing devices can be located in a single installation or can be distributed among many different geographical locations. The computing environments 103 can also include or be operated as one or more virtualized computer instances.”; NOTE: Applicant’s Specification states, “The vulcore endpoint 217 is a virtual location on the remote management device 104.” (Spec: ¶ 80) In other words, the vulcore endpoint at the management device performs its respective operations via a virtual location. Shantharam explains that the computing environments may be operated as one or more virtualized computer instances, which implies that the “server computer or any other system providing computing capability” (described in ¶ 18 of Shantharam) may be implemented as virtual devices. Shantharam also describes system elements that perform the operations attributed to the vulcore endpoint at the management device; therefore, Shantharam is interpreted as disclosing an example of a vulcore endpoint at the management device.).
[Claims 11-15] Claims 11-15 recite limitations already addressed by the rejections of claims 1-5 above; therefore, the same rejections apply. Furthermore, Shantharam discloses a non-transitory computer-readable medium having encoded therein programming code executable by one or more processors to perform or control performance of operations (Shantharam: ¶¶ 86-95) of product update management in systems having product access restrictions associated with administrative credentials, the operations comprising the disclosed operations (Shantharam: ¶ 29 – “The update policies 151 can include constraints specified by an administrator for a client device 106 to be in “compliance” with the management service 118. The update policies 151 can include compliance rules or other criteria. In one example, the agent application 124 can configure hardware or software functionality of a client device 106 such that the client device 106 is in conformance with the update policies 151. For instance, an administrator can specify particular types of software updates 145 that are automatically installed on the client devices 106. Additionally, the agent application 124 can identify when the client device 106 is not in conformance with the update policies 151, as well as other policies, and can take appropriate remedial actions, such as denying access to enterprise data 136, denying installation of a software update 145, or other features of the agent application 124. In further examples, remedial actions can include, for example, encrypting enterprise data 136 such that the enterprise data 136 cannot be accessed until the client devices 106 comes into conformance with the update policies 151, denying access to sharing functions, such as network-based tile transfers, restricting execution of certain client applications, or similar functions.”).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 6-10 and 16-20 are rejected under 35 U.S.C. 103 as being unpatentable over Shantharam et al. (US 2018/0173517), as applied to claims 1 and 11 above, in view of Vetter et al. (US 2023/0085027).
[Claims 6, 16] Shantharam discloses in response to a determination that the managed endpoint is not enrolled in the MDM environment (¶¶ 21, 32):
checking availability of an existing role account that enables a remediation operation at the managed endpoint (¶ 32 – “In one example, a client device 106 designated as “enrolled” can be permitted to access the enterprise data 136 while a client device 106 designated as “not enrolled” or having no designation can be denied access to the enterprise data 136. Device data 133 can also include data pertaining to user groups 157. An administrator can specify one or more of the client devices 106 as belonging to a particular user group 157. The management service 118 can use a deployment profile 139 applicable to the particular user group 157 to instruct the agent application 124 to download specified software updates 145 as well as perform an installation of the software updates 145.);
in response to the existing role account being unavailable (¶ 21, 32 – A client device not yet having been enrolled is an example of an existing role account being unavailable.):
attempting to obtain credentials of a user authorized to enable the remediation operation (¶ 21 – “In one example, enrollment of the client device 106 with the management service can include authenticating a user of the client device 106 using authentication data, such as an email address, a username, a password, a personal identification number (PIN), biometric information or other data.”);
in response to the credentials being obtained, generating a new role account configured to enable the remediation operation, wherein generation of the new role account is enabled by the obtained credentials and includes a secured password (¶ 21 – “In one example, enrollment of the client device 106 with the management service can include authenticating a user of the client device 106 using authentication data, such as an email address, a username, a password, a personal identification number (PIN), biometric information or other data.”; ¶ 32);
retrieving the new role account from the secured data storage (fig. 1, ¶¶ 21, 31-32); and
executing the remediation operation to implement the OS product update at the managed endpoint (abstract, ¶¶ 38, 46).
While Shantharam allows for relevant information to be stored in a data store, the data store is external to the client device (Shantharam: fig. 1). Shantharam does not explicitly disclose:
storing the new role account in a secured data storage at the managed endpoint; and
entering the credentials from the retrieved role account.
Vetter discloses that credentials may be provisioned to client devices, including to provide a client application on the client device (Vetter: abstract). As part of the process, when a user needs credentials, the administrator may create a credential request (Vetter: ¶¶ 40-41) and the administrator may have to log into the administrator interface via a web page (Vetter: ¶ 67). The end user is also given temporary credentials that are stored in the end user’s device, such as in a keychain by using an OS-provided API on the device (Vetter: ¶ 60 – “The credential provisioning module 174 on the mobile device 170 may decrypt the file using the stored password associated with the initial credential request (e.g., the user's enterprise password or the generated temporary encryption password) and stored the credentials (e.g., the signed certificate and the private key) in the specified keystore/keychain 182 (e.g., using an API provided by the OS on the device). In this manner, credentials may be provisioned on the mobile device 170 in association with the client application 172 based on keys and a certificate generated at the credential provisioning server 110.”). Credential parameters are established for the particular mobile device, including based on the type of device (Vetter: ¶ 55 – “If the mobile device 170 (or OS, OS type, etc.) is not on the blacklist (or is on the whitelist), the credential parameters may be determined (417), for example, from the rule base 119 based on the type of mobile device, the OS type or OS version or other criteria associated with the credential request. These credential parameters may include where the credentials should be generated, the type or length of key to use, the keystore/keychain where the credentials should be stored, or other desired parameters.”) The Examiner submits that it would have been obvious to one of ordinary skill in the art before the effective filing date of Applicant’s invention to modify Shantharam to perform the steps of:
storing the new role account in a secured data storage at the managed endpoint; and
entering the credentials from the retrieved role account
in order to more effectively facilitate “a mutual secure connection with a trusted server” (Vetter: ¶ 14), which is particularly useful in improving security in Bring Your Own Device (“BYOD”) environments (as suggested in ¶¶ 3-8 of Vetter) and in a mobile device management platform (Vetter: title, ¶¶ 9-10).
[Claims 7, 17] Shantharam does not explicitly disclose wherein the new role account and the secured password are generated as a background process and securely passed to the secured data storage such that new role account and the secured password are not visible and not accessible by a user of the managed endpoint. Shantharam does, however, allow for installation to be performed silently as a background process that is unnoticeable by the user of the client device (Shantharam: ¶¶ 45, 61). Vetter discloses that credentials may be provisioned to client devices, including to provide a client application on the client device (Vetter: abstract). As part of the process, when a user needs credentials, the administrator may create a credential request (Vetter: ¶¶ 40-41) and the administrator may have to log into the administrator interface via a web page (Vetter: ¶ 67). The end user is also given temporary credentials that are stored in the end user’s device, such as in a keychain by using an OS-provided API on the device (Vetter: ¶ 60 – “The credential provisioning module 174 on the mobile device 170 may decrypt the file using the stored password associated with the initial credential request (e.g., the user's enterprise password or the generated temporary encryption password) and stored the credentials (e.g., the signed certificate and the private key) in the specified keystore/keychain 182 (e.g., using an API provided by the OS on the device). In this manner, credentials may be provisioned on the mobile device 170 in association with the client application 172 based on keys and a certificate generated at the credential provisioning server 110.”). Use of a keychain to provide credentials is also an example of providing credentials in the background without requiring a user to enter such information. Credential parameters are established for the particular mobile device, including based on the type of device (Vetter: ¶ 55 – “If the mobile device 170 (or OS, OS type, etc.) is not on the blacklist (or is on the whitelist), the credential parameters may be determined (417), for example, from the rule base 119 based on the type of mobile device, the OS type or OS version or other criteria associated with the credential request. These credential parameters may include where the credentials should be generated, the type or length of key to use, the keystore/keychain where the credentials should be stored, or other desired parameters.”) A one-time use encrypted password is provided for the user to sign in, which implies that the end user does not view or access the password directly (Vitter: ¶¶ 13-14, 48). The Examiner submits that it would have been obvious to one of ordinary skill in the art before the effective filing date of Applicant’s invention to modify Shantharam wherein the new role account and the secured password are generated as a background process and securely passed to the secured data storage such that new role account and the secured password are not visible and not accessible by a user of the managed endpoint in order to more effectively facilitate “a mutual secure connection with a trusted server” (Vetter: ¶ 14), which is particularly useful in improving security in Bring Your Own Device (“BYOD”) environments (as suggested in ¶¶ 3-8 of Vetter) and in a mobile device management platform (Vetter: title, ¶¶ 9-10).
[Claims 8, 18] Shantharam does not explicitly disclose wherein the secured data storage includes a password management system on the managed endpoint. Vetter discloses that credentials may be provisioned to client devices, including to provide a client application on the client device (Vetter: abstract). As part of the process, when a user needs credentials, the administrator may create a credential request (Vetter: ¶¶ 40-41) and the administrator may have to log into the administrator interface via a web page (Vetter: ¶ 67). The end user is also given temporary credentials that are stored in the end user’s device, such as in a keychain by using an OS-provided API on the device (Vetter: ¶ 60 – “The credential provisioning module 174 on the mobile device 170 may decrypt the file using the stored password associated with the initial credential request (e.g., the user's enterprise password or the generated temporary encryption password) and stored the credentials (e.g., the signed certificate and the private key) in the specified keystore/keychain 182 (e.g., using an API provided by the OS on the device). In this manner, credentials may be provisioned on the mobile device 170 in association with the client application 172 based on keys and a certificate generated at the credential provisioning server 110.”). Credential parameters are established for the particular mobile device, including based on the type of device (Vetter: ¶ 55 – “If the mobile device 170 (or OS, OS type, etc.) is not on the blacklist (or is on the whitelist), the credential parameters may be determined (417), for example, from the rule base 119 based on the type of mobile device, the OS type or OS version or other criteria associated with the credential request. These credential parameters may include where the credentials should be generated, the type or length of key to use, the keystore/keychain where the credentials should be stored, or other desired parameters.”) The Examiner submits that it would have been obvious to one of ordinary skill in the art before the effective filing date of Applicant’s invention to modify Shantharam wherein the secured data storage includes a password management system on the managed endpoint in order to more effectively facilitate “a mutual secure connection with a trusted server” (Vetter: ¶ 14), which is particularly useful in improving security in Bring Your Own Device (“BYOD”) environments (as suggested in ¶¶ 3-8 of Vetter) and in a mobile device management platform (Vetter: title, ¶¶ 9-10).
[Claims 9, 19] Shantharam does not explicitly disclose in response to the attempt to obtain the credentials being unsuccessful:
alerting a user of the managed endpoint that an update to the OS is outstanding; and
causing display on a user interface for entering administrative credentials on the managed endpoint to enable remediation of the update to the OS.
However, Shantharam does disclose alerting a user of the managed endpoint that an update to the OS is outstanding (abstract, fig. 6, ¶¶ 23-24 – It may be determined that an OS software update is available.; ¶ 79 – “In other examples, the EULA for the software update 145 can be sent to client devices 106 for acceptance by an end user.”). Vetter discloses that credentials may be provisioned to client devices, including to provide a client application on the client device (Vetter: abstract). As part of the process, when a user needs credentials, the administrator may create a credential request (Vetter: ¶¶ 40-41) and the administrator may have to log into the administrator interface via a web page (Vetter: ¶ 67). The end user is also given temporary credentials that are stored in the end user’s device, such as in a keychain by using an OS-provided API on the device (Vetter: ¶ 60 – “The credential provisioning module 174 on the mobile device 170 may decrypt the file using the stored password associated with the initial credential request (e.g., the user's enterprise password or the generated temporary encryption password) and stored the credentials (e.g., the signed certificate and the private key) in the specified keystore/keychain 182 (e.g., using an API provided by the OS on the device). In this manner, credentials may be provisioned on the mobile device 170 in association with the client application 172 based on keys and a certificate generated at the credential provisioning server 110.”). Credential parameters are established for the particular mobile device, including based on the type of device (Vetter: ¶ 55 – “If the mobile device 170 (or OS, OS type, etc.) is not on the blacklist (or is on the whitelist), the credential parameters may be determined (417), for example, from the rule base 119 based on the type of mobile device, the OS type or OS version or other criteria associated with the credential request. These credential parameters may include where the credentials should be generated, the type or length of key to use, the keystore/keychain where the credentials should be stored, or other desired parameters.”) The Examiner submits that it would have been obvious to one of ordinary skill in the art before the effective filing date of Applicant’s invention to modify Shantharam to perform the steps of, in response to the attempt to obtain the credentials being unsuccessful:
alerting a user of the managed endpoint that an update to the OS is outstanding; and
causing display on a user interface for entering administrative credentials on the managed endpoint to enable remediation of the update to the OS
in order to more effectively facilitate “a mutual secure connection with a trusted server” (Vetter: ¶ 14), which is particularly useful in improving security in Bring Your Own Device (“BYOD”) environments (as suggested in ¶¶ 3-8 of Vetter) and in a mobile device management platform (Vetter: title, ¶¶ 9-10).
[Claims 10, 20] Shantharam discloses wherein the alert is initiated by the agent (abstract, fig. 6, ¶¶ 23-24 – It may be determined that an OS software update is available.; ¶ 79 – “In other examples, the EULA for the software update 145 can be sent to client devices 106 for acceptance by an end user.”).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Vetrovsky et al. (US 2017/0366402) – Manages mobile operating system MDM protocol.
Mohiuddin, Khaja Taiyab. "Mobile Device Management and Their Security Concerns." International Research Journal of Engineering and Technology (IRJET), vol. 10, no. 10, October 2023 – Manages mobile devices and policies in an organization.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SUSANNA M DIAZ whose telephone number is (571)272-6733. The examiner can normally be reached M-F, 8 am-4:30 pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Brian Epstein can be reached at (571) 270-5389. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/SUSANNA M. DIAZ/
Primary Examiner
Art Unit 3625A