DETAILED ACTION
This final Office action is responsive to Applicant’s amendment filed July 9, 2026. Claims 1, 6-8, 11, and 16-18 have been amended. 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 .
Response to Arguments
Applicant's arguments filed July 9, 2026 have been fully considered but they are not persuasive.
Applicant argues the claims as currently amended. The Jain reference has been introduced into the rejections in order to help address the claim amendments.
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 1-7 and 11-17 are rejected under 35 U.S.C. 103 as being unpatentable over Shantharam et al. (US 2018/0173517) in view of Jain et al. (US 2021/0099450).
[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 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 the 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.”).
Shantharam discloses that an administrator may authorize a software update (Shantharam: ¶ 39) in an operating system management environment (Shantharam: abstract); however, Shantharam does not explicitly disclose wherein an OS vendor limits an ability to update the OS during product update operations by requiring administrative credentials and a secure token to implement modification to the OS.
However, in a cloud-based environment, Jain discloses wherein a cloud-based resource vendor limits an ability to access the cloud-based resource operations by requiring administrative credentials and a secure token to implement access to the cloud-based resource operations (Jain: abstract – “Techniques for managing permissions to cloud-based resources with session-specific attributes are described.”; ¶ 14 – “Aspects of the present disclosure address the above and other challenges by evaluating attribute-based rules that determine whether to grant access to a particular resource of a provider network with attributes included with a session request. In some embodiments, entities such as users or applications establish a session with an access control service of the provider network in order to access other provider-network resources. As part of establishing a session, entities can assume a particular role that has zero or more pre-defined attributes (also referred to herein as “tags”). Assumption of the role can be contingent on a set of one or more role trust rules associated with the role that govern whether an entity can assume the role. Additionally, the entity may be able to override existing attributes or to specify additional attributes when assuming a role, subject to the set of role trust rules. In some embodiments, the set of role trust rules are part of a role trust policy. The tags—whether pre-defined or specified upon assumption of the role—can be stored as part of session data. In addition to tags, the session data can include other metadata identifying the entity's session with the provider network (e.g., the session role, any session-specific policies, etc.). Tags or attributes are also applied to resources of the provider network. For example, a certain computing resource might have a given cost center. An entity is granted or denied access to a resource based on an evaluation of the tag(s) of the resource and the tag(s) of the entity's session against a set of one or more role permission rules that govern what actions or operations the role can initiate or perform using resources. For example, the set of one or more role permission rules may specify that access to a certain resource is only permitted to sessions tagged with a cost center that matches the cost center of the resource. In some embodiments, the set of role permission rules are part of a role permissions policy.”; ¶ 30 – “As indicated at circle D, the entity controlling an electronic device 120—whether a user or application—can request credentials from the ACS 110 (referred to herein as ACS credentials). ACS credentials can be temporary session credentials that include an identifier that identifies the session, a secret access key that the entity can use to sign requests submitted during the session, and a token that includes the session data. The session data can include metadata identifying the entity's session with the provider network (e.g., the session role, any session-specific policies, etc.). In some embodiments, the request is an API call to the ACS 110 to return ACS credentials for a session with the provider network 100 using an assumed role. The API can accept the IDP credential, an identifier of the role to assume for the session, and zero or more user-specified session tags (e.g., user-specified attributes). The user-specified session tags can be used to supplement and/or replace attributes embedded within the IDP credential or default attributes as determined by the role trust rules. The entity can specify additional tags not present in the IDP credentials (e.g., the entity can specify a “Department=Sales” tag, specify additional tags that are present in the IDP credentials or to overwrite the value of a tag that exists in the IDP credentials. Note that the electronic device 120 may be connected to the third-party network 101 or the provider network 100.”; ¶ 18 – “For example, virtualization technologies may be used to provide users the ability to control or utilize compute instances (e.g., a VM using a guest operating system (O/S) that operates using a hypervisor that may or may not further operate on top of an underlying host O/S, a container that may or may not operate in a VM, an instance that can execute on “bare metal” hardware without an underlying hypervisor), where one or multiple compute instances can be implemented using a single electronic device.”; ¶ 39 – “For example, the ACS 110 can maintain the key used to encrypt and decrypt the token in the data store 112 (not shown).”).
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 an OS vendor limits an ability to update the OS during product update operations by requiring administrative credentials and a secure token to implement modification to the OS in order to facilitate easier and more efficient approval or denial of access requests, especially in a system with a large number of users of varying roles and electronic devices, and in order to allow Shantharam to be adapted to a wider range of service environments (including a cloud-based resource provider environment). For example, as explained by Jain, “[b]y allowing entities to change tags during session establishment with the provider network, those entities can customize their session without requiring an administrator to create and maintain many different roles to control access to resources. For example, an administrator could create a single developer role that allows the specification of a project tag and tag various resources with their associated project(s). For example, a first resource might be allocated to entities associated with the projects ‘Blue’ and ‘Green,’ a second resource might be allocated to only entities associated with the project ‘Green,’ and a third resource might be allocated to only entities associated with the project ‘Red.’ When an entity assumes that role, the entity can specify a session-specific project tag that identifies one or more projects. For example, the entity may specify that it is part of projects ‘Blue’ and ‘Red’ to gain access to both the first and the third resources using a single role. In this manner, both the number of roles an administrator would need to manage and the number of different roles an entity would have to assume during daily activities would be reduced. Reducing the number of roles reduces the complexity and effort of access management.” (Jain: ¶ 15) Additionally, Jain states, “Generic rules such as those illustrated in FIG. 4 can be created and subsequently rely on user-specified session tags, tags can be attributed to resources, and tags can be attributed to the entity associated with a session (e.g., attributes created upon adding the user in the identity data 134, user-specified tags, and/or default tags associated with an assumed role). As a result, as the organization adds new resources in the provider network 100 and/or new users, administrators can continue to rely on the existing rules to manage user access to those resources without requiring any updated rules or roles.” (Jain: ¶ 43)
Shantharam does not explicitly disclose:
in response to a determination that the managed endpoint is not enrolled in the MDM environment, checking availability of an existing role account stored in a secured data storage, the existing role account enabling access to the secure token and the administrative credentials that allow a modification to the OS to install the OS update;
responsive to the existing role account being available, decrypting the administrative credentials from the existing role account and entering the administrative credentials;
responsive to the existing role account being unavailable:
generating a new role account based on the secure token and the administrative credentials,
storing the new role account in the secured data storage;
retrieving the new role account from the secured data storage, and
entering the administrative credentials from the new role account.
Jain discloses that a new session can be established, which may include assigning a new role, a new token, and new credentials, requested via an electronic device and provided via the ACS (access control service) of the provider network (Jain: ¶ 19 – “The provider network includes an access control service (ACS) 110 and a resource interface 150 through which an entity such as a user or application can issue actions or operations to cloud-based resources such as resources 170 and 172.”; ¶ 48 – “FIG. 6 is a diagram illustrating persisting certain tags across multiple roles according to some embodiments. In some scenarios, an entity may wish to assume a first role and then use that first role to assume a second role. For example, a user can establish a first session under the first role and obtain the ACS credentials for that session either by authenticating with an ACS 610 or by submitting IDP credentials, as described above. Once the user has obtained the ACS credentials for the first session, the user can request ACS credentials for a new session in which the user assumes a different role. As indicated at circle A, an electronic device 620 can request new ACS credentials using the existing ACS credentials from the first session. As indicated at circle B, the ACS 610 can generate a new session token or session state as described above. As indicated at circle C, the ACS 610 can then return the new token or the session state identifier to identify the new session state in the session states data 614 to the electronic device. As part of generating the new session data (whether contained in a session state object or session token), the ACS 610 can include some tags from the previous session data. For example, in some embodiments, the session data can include a parameter that indicates whether each tag in the session data can be inherited upon assumption of a new role. As shown, the session data in the previous session token or session state can include the example contents 650. The example contents 650 includes a CostCenter tag with a value of “1234” and a “RoleID” tag with a value of “Dev.” The session data also includes a “Transitive” parameter to indicate whether the respective tag is transitive amongst sessions. The transitive parameter can be set when generating the original tag. For example, a session tag originating as a user-specified tag in the prior request (e.g., at circle D in FIG. 1 or circle A in FIG. 5) can be marked as transitive while other tags can be marked as not transitive. Upon receipt of the request for the new ACS credentials at circle A, the ACS can evaluate the contents of the previous session data to determine which tags to include in the new ACS credentials. Here, because the RoleID tag is not transitive, the new value is “Manager” (e.g., based on a default tag value associated with the new role). Additionally, because the CostCenter tag is transitive, the new value matches the old value of “1234,” potentially overwriting a default tag value associated with the new role.”). Aside from the MDM environment and modification to the OS to install the OS update (which are addressed by Shantharam above), Jain’s teachings address in response to a determination that the managed endpoint is not enrolled in the MDM environment, checking availability of an existing role account stored in a secured data storage, the existing role account enabling access to the secure token and the administrative credentials that allow a modification to the OS to install the OS update (where the MDM details are suggested by Jain’s analogous management of electronic devices and the modification to the OS to install the OS update is analogous to Jain’s provision of access to cloud-based resources and corresponding operations).
Jain’s creation of a new role (e.g., as discussed above in regard to ¶ 48 of Jain) is also suggestive of the following claimed limitations:
responsive to the existing role account being unavailable:
generating a new role account based on the secure token and the administrative credentials,
storing the new role account in the secured data storage;
retrieving the new role account from the secured data storage, and
entering the administrative credentials from the new role account.
For example, requiring a new role (as seen in ¶ 48 of Jain) is responsive to some need for a new role, such as needing to establish a second session that operates using a second role after establishing a first role under a first session. The claimed “existing role being unavailable” analogously suggests that a new role is needed for some reason. Furthermore, Jain stores role and permission information (including updated and newly-created information) in a data store, including for encryption and decryption (i.e., secure) purposes (Jain: ¶¶ 14, 25, 26, 39, 47).
A user must be approved (which includes identifying the user’s role, as discussed in ¶ 48 of Jain, reproduced above) before being granted access to the cloud-based resources and corresponding operations. Jain further explains that credentials are encrypted and decrypted as part of the login process for a user (Jain: ¶ 29 – “As indicated at circle C, the user authenticates with the IDP 130 and in response receives credentials from the IDP (referred to herein as IDP credentials). Exemplary IDP credentials include a SAML assertion or an OpenID Connect ID token. In some embodiments, the IDP credentials are protected to prevent tampering by the user (e.g., signed or encrypted by the IDP 130 so the ACS 110 can verify or decrypt the IDP credentials using a public key in communications at circle B). In some embodiments, the IDP credentials include one or more of the attributes associated with the user in the identity data 134. For example, the IDP credentials upon the successful login of Jane Doe can include a “UserID=JaneDoe” key-value pair and a “CostCenter=1234” key-value pair. In other embodiments, all of the attributes associated with the user in the identity data 134 are included in the IDP credentials. In yet other embodiments, some subset of the attributes associated with the user in the identity data 134 are included in the IDP credentials as negotiated between the IDP 130 and the ACS 110. For example, the ACS 110 can indicate to the ICS 130 that all IDP credentials include the CostCenter attribute.”). This addresses the claim limitation “responsive to the existing role account being available, decrypting the administrative credentials from the existing role account and entering the administrative credentials.”
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 following:
in response to a determination that the managed endpoint is not enrolled in the MDM environment, checking availability of an existing role account stored in a secured data storage, the existing role account enabling access to the secure token and the administrative credentials that allow a modification to the OS to install the OS update;
responsive to the existing role account being available, decrypting the administrative credentials from the existing role account and entering the administrative credentials;
responsive to the existing role account being unavailable:
generating a new role account based on the secure token and the administrative credentials,
storing the new role account in the secured data storage;
retrieving the new role account from the secured data storage, and
entering the administrative credentials from the new role account
in order to facilitate easier and more efficient approval or denial of access requests, especially in a system with a large number of users of varying roles and electronic devices, and in order to allow Shantharam to be adapted to a wider range of service environments (including a cloud-based resource provider environment). For example, as explained by Jain, “[b]y allowing entities to change tags during session establishment with the provider network, those entities can customize their session without requiring an administrator to create and maintain many different roles to control access to resources. For example, an administrator could create a single developer role that allows the specification of a project tag and tag various resources with their associated project(s). For example, a first resource might be allocated to entities associated with the projects ‘Blue’ and ‘Green,’ a second resource might be allocated to only entities associated with the project ‘Green,’ and a third resource might be allocated to only entities associated with the project ‘Red.’ When an entity assumes that role, the entity can specify a session-specific project tag that identifies one or more projects. For example, the entity may specify that it is part of projects ‘Blue’ and ‘Red’ to gain access to both the first and the third resources using a single role. In this manner, both the number of roles an administrator would need to manage and the number of different roles an entity would have to assume during daily activities would be reduced. Reducing the number of roles reduces the complexity and effort of access management.” (Jain: ¶ 15) Additionally, Jain states, “Generic rules such as those illustrated in FIG. 4 can be created and subsequently rely on user-specified session tags, tags can be attributed to resources, and tags can be attributed to the entity associated with a session (e.g., attributes created upon adding the user in the identity data 134, user-specified tags, and/or default tags associated with an assumed role). As a result, as the organization adds new resources in the provider network 100 and/or new users, administrators can continue to rely on the existing rules to manage user access to those resources without requiring any updated rules or roles.” (Jain: ¶ 43)
[NOTE: Claim 1 is a method claim and method claims are limited by positively recited and performed steps. The actions following the phrases “in response to” and “responsive to” present conditionally performed actions. Each action is only actively performed within the scope of the method claims if the respectively associated condition is met. Consequently, not all of the recited actions presented in the claims (particularly the actions corresponding to conditions not actively met) are performed within the scope of the method, unlike the corresponding actions in the mirroring article of manufacture claim (e.g., claim 11) in which all computer-executable actions are actively programmed and stored in the non-transitory medium. In the interest of compact prosecution, all actions presented in claim 1 have explicitly been addressed in the prior art rejection.]
[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.).
[Claim 6] Shantharam discloses wherein the generating the new role account includes:
attempting to obtain credentials of a user authorized to enable the remediation operation (Shantharam: ¶ 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.”); and
in response to the credentials being obtained, generating the 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 (Shantharam: ¶ 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).
It is noted that the details of the new role account in the context defined in the independent claim have been addressed by the Shantharam-Jain combination in the rejection of the independent claim above. The corresponding analysis extends to the rejection of the dependent claims as well.
[Claim 7] 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). Jain uses an identity provider (IDP) to perform user authentication on behalf of the provider network via a federated model. A user’s credentials are provided via the IDP to the ACS (Jain: ¶¶ 27-29). For example, Jain states, “As indicated at circle C, the user authenticates with the IDP 130 and in response receives credentials from the IDP (referred to herein as IDP credentials). Exemplary IDP credentials include a SAML assertion or an OpenID Connect ID token. In some embodiments, the IDP credentials are protected to prevent tampering by the user (e.g., signed or encrypted by the IDP 130 so the ACS 110 can verify or decrypt the IDP credentials using a public key in communications at circle B). In some embodiments, the IDP credentials include one or more of the attributes associated with the user in the identity data 134. For example, the IDP credentials upon the successful login of Jane Doe can include a “UserID=JaneDoe” key-value pair and a “CostCenter=1234” key-value pair. In other embodiments, all of the attributes associated with the user in the identity data 134 are included in the IDP credentials. In yet other embodiments, some subset of the attributes associated with the user in the identity data 134 are included in the IDP credentials as negotiated between the IDP 130 and the ACS 110. For example, the ACS 110 can indicate to the ICS 130 that all IDP credentials include the CostCenter attribute.” (Jain: 29)
Furthermore, it is noted that the details of the new role account in the context defined in the independent claim have been addressed by the Shantharam-Jain combination in the rejection of the independent claim above. The corresponding analysis extends to the rejection of the dependent claims as well.
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 prevent tampering by a user attempting to access the provider system (as suggested in ¶ 29 of Jain, which states “In some embodiments, the IDP credentials are protected to prevent tampering by the user (e.g., signed or encrypted by the IDP 130 so the ACS 110 can verify or decrypt the IDP credentials using a public key in communications at circle B).”).
[Claims 11-17] Claims 11-17 recite limitations already addressed by the rejections of claims 1-7 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.”).
Claims 8-10 and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Shantharam et al. (US 2018/0173517) in view of Jain et al. (US 2021/0099450), as applied to claims 1, 6, 11, and 16 above, in view of Vetter et al. (US 2023/0085027).
[Claims 8, 18] Shantharam and Jain do 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 the Shantharam-Jain combination 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 and Jain do 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 the Shantharam-Jain combination 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.
Mangalvedkar et al. (US 2020/0177589) – Controls access to cloud-based services.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
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
