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 .
DETAILED ACTION
This Office Action is in response to the amendment filed on 12/02/2025; claims 1, 3, 8, 15, 17, 18, and 20 have been amended; Claims 1, 15, and 18 are independent claims. Claims 1-20 have been examined and are pending. This Action is made non-FINAL.
Response to Arguments
The rejection of claims 1-4, 6-12 and 14-20 under 35 U.S.C. 101 is withdrawn as the claims have been amended and applicant’s arguments are found persuasive.
Applicants’ arguments with respect to the amended limitations “during an attempted onboarding of an endpoint device of the endpoint devices to a deployment as part of a change in ownership over the endpoint device and after an onboarding voucher has been attempted to be used to establish trust between the endpoint device and an orchestrator of the deployment”, with respect to claims 1, 6, 9, 15, 18, 2, 16, 19, 3, 17, 20, 4,-5, 7-8, and 10 (Applicant Remarks/Arguments, pages 8-11) have been fully considered but are moot in view of the new ground(s) of rejection.
Applicant’ arguments in the instant amendment, filed on 12/02/2025, with respect to limitations listed below, have been fully considered but they are not persuasive.
a. Applicant argues: “the scoring system of Ellsworth is less restrictive than Shravan's comparison system to specific data...the proposed combination does not provide the contemplated advantage of 'comprehensive endpoint security assessment capabilities' because Shravan's system already provides for such analysis...one of ordinary skill in the art would not make the proposed combination...because no actual contemplated advantage is provided.” (Applicant Remarks/Arguments, page 11).
The Examiner respectfully disagrees with the applicant as follows:
This argument is not persuasive. The motivation to combine does not require that the combination improve upon every aspect of the primary reference. KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398, 418 (2007). The motivation here is not that Ellsworth improves Shravan's access control — it is that Ellsworth provides a quantification mechanism that Shravan lacks. Shravan teaches compliance evaluation (par. 0041, 0044, 0046) but does not teach how to numerically score or quantify compliance results for threshold comparison. Ellsworth fills exactly that gap: Col. 8 lines 52-61 expressly collects "vulnerability, compliance, and system data" and scores it against defined thresholds (Col. 18 lines 46-55: "alert...based on a threshold being exceeded"). One of ordinary skill in the art would be motivated to incorporate Ellsworth's quantification mechanism into Shravan's compliance framework to produce prioritized, scored compliance decisions rather than binary pass/fail outcomes. Teaching away requires that a reference "criticize, discredit, or otherwise discourage" the proposed combination. In re Fulton, 391 F.3d 1195, 1201 (Fed. Cir. 2004). A broader scoring system in some configurations does not discourage one of ordinary skill in the art from adopting its quantification mechanism.
b. Applicant argues: “the sections of Ellsworth cited in the Office Action are unrelated to onboarding and much less ownership changes...Ellsworth, like Shravan, is also silent with respect to the above claim limitations.” (Applicant Remarks / Arguments, pages 11-12).
The Examiner respectfully disagrees with the applicant as follows:
This argument is not persuasive. Applicant mischaracterizes the rejection by arguing that Ellsworth must describe onboarding to be combinable, when Ellsworth is cited solely for the scoring mechanism — not for the onboarding context, which is already supplied by Shravan and Pritikin. Ellsworth is cited solely for elements of claim 11 — the scoring system, quantification, and threshold comparison. Shravan and Pritikin already supply the onboarding and ownership transfer context for claim 1. A reference need not be combinable in its entirety — it need only teach the specific limitation for which it is cited. In re Keller, 642 F.2d 413, 425 (CCPA 1981) ("one cannot show non-obviousness by attacking references individually where the rejection is based on a combination of references").
For claim 14 specifically, Ellsworth Col. 8, lines 52-61 expressly uses the term “credentialed audits” — language that directly maps to "audit of the endpoint device." The fact that Ellsworth does not describe onboarding is irrelevant because claim 14 only requires that the validation event be an audit — not that the audit occur during onboarding. Shravan and Pritikin supply the onboarding context; Ellsworth supplies the audit trigger.
c. Applicant argues: “The sections of Bainbridge cited in the Office Action are unrelated to onboarding and much less ownership changes. Accordingly, Bainbridge, like Shravan, is also silent with respect to the above claim limitations” (Applicant Remarks / Arguments, page 12).
The Examiner respectfully disagrees with the applicant as follows:
This argument is not persuasive. Applicant repeats the same mischaracterization raised against Ellsworth for claims 11 and 14 — that a reference must describe onboarding or ownership transfer to be combinable. That is not the legal standard.
Bainbridge is cited solely for one specific limitation: that the assignment of a workload constitutes a validation event that triggers compliance evaluation. Bainbridge par. 0005 expressly teaches a "scheduling trigger" that initiates compliance tracking — directly mapping onto claim 12's "validation event is an assignment of a workload." Whether Bainbridge describes onboarding or ownership transfer is entirely irrelevant because Shravan and Pritikin already supply that context for claim 1. Bainbridge fills only the workload-assignment gap. In re Keller, 642 F.2d 413, 425 (CCPA 1981).Applicant's assertion that Bainbridge "is also silent with respect to the above claim limitations" is conclusory and unsupported. Applicant does not address par. 0004 ("receiving unassigned workloads for assignment on nodes"), par. 0005 ("scheduling trigger" initiating compliance tracking), or par. 0033 ("periodic policy rule evaluation" marking policies as compliant, within limits, or in violation) — the specific paragraphs cited in the Office Action.
d. Applicant argues: “The sections of Rao cited in the Office Action are unrelated to onboarding and much less ownership changes. Accordingly, Rao, like Shravan and Bainbridge, is also silent with respect to the above claim limitations.” (Applicant Remarks / Arguments, page 12).
The Examiner respectfully disagrees with the applicant as follows:
This argument is not persuasive. Applicant repeats the same mischaracterization raised against Ellsworth for claims 11 and 14, and against Bainbridge for claim 12 — that each reference must describe onboarding or ownership transfer to be combinable. As previously addressed, that is not the legal standard. In re Keller, 642 F.2d 413, 425 (CCPA 1981).
Rao is cited solely for one specific limitation: the binary accept/reject logic based on compliance state — that a non-compliant entity is rejected and a compliant entity is accepted. Rao par. 0036 expressly teaches "rules for content that is non-compliant (e.g. and should be rejected) and rules for content that is compliant (e.g., and should be approved)" — directly mapping onto claim 13's binary structure of rejecting non-compliant devices and accepting compliant devices as workload candidates. Whether Rao describes onboarding or ownership transfer is irrelevant because Shravan, Pritikin, and Bainbridge already supply that context. Rao fills only the binary accept/reject gap.
Applicant's assertion that Rao "is also silent with respect to the above claim limitations" is conclusory and unsupported. Applicant does not address par. 0036 — the specific paragraph cited in the Office Action — nor does Applicant explain why the binary compliant/non-compliant accept/reject mechanism taught by Rao fails to map onto claim 13's identical binary structure.
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-10 and 15-18 are rejected under 35 U.S.C. 103 as being unpatentable over Shravan et al. (“Shravan,” US 2021/0281576), in view of M. Pritikin et al. (“Pritikin,” RFC 8995, May 2021, pages 1-116).
Regarding claim 1, Pritikin teaches a method for managing endpoint devices, the method comprising:
identifying an occurrence of a validation event for an endpoint device (Shravan: par. 0011, in response to receiving, by a network appliance, a first request to access a protected network resource from an endpoint device; par. 0027, “when access request is received”; par. 0025, authentication check; par. 0027, periodic authentication checks; par. 0036, performs an authentication check; par. 0041, associated with the credential supplied during the authentication check; par. 0043, Initially, the client 120 makes an initial request for access to a protected network zone and/or protected resource 116 within the private network 104 (602));
based on the occurrence of the validation event:
identifying a compliance policy which governs the endpoint device (Shravan: fig. 5, par. 0041, The network appliance 110 receives the access request and determines the applicable policies for the user device 118 (506) [] The policies include characteristics that, when true, make the policy applicable”, fig. 6, par. 0044, The network appliance 110 determines requirements for relevant policies for access (604). For example, the network appliance 110 may request policies from the policy server 114 applicable to the user device 118);
obtaining, from the endpoint device and based at least on the compliance policy, compliance data (Shravan: par. 0011, (b) requesting all of the determined compliance information from the client software module; fig. 5, par. 0041, The network appliance 110 compiles the requirements and sends request for full compliance information to the client 120 that specifies the requirements (508), In response to receiving a request for full compliance data, the client 120 collects the requested compliance information from the user device 118 (510). The client 120 sends the collected compliance information to the network appliance 110 (512); fig. 6, par. 0045, The client 120 collects user device details related to the requirements received from the network appliance 110 (608))
identifying, based on at least the compliance policy and the compliance data, a compliance state for the endpoint device (Shravan: par. 0011, evaluating the compliance of the endpoint device based on the compliance information received from the client software module; fig. 5, par. 0041, The network appliance 110 evaluates the full compliance information provided by the client 120 against applicable policies (514); fig. 6, par. 0046, the network appliance 110 evaluates the compliance (sometimes referred to as "evaluating the compliance state") of the user device 118 using the compliance infor-mation received from client 120 (614)); and
managing operation of the endpoint device based on the compliance state (Shravan: par. 0011, providing access when the compliance information satisfies the policies; fig. 5, par. 0041, When the compliance data satisfies the applicable policies, the network appliance 110 provides access to one or more of the protected resources 116; fig. 6, par. 0046, The network appliance 110 provides access to the protected network zone and/or protected resources 114 of the private network 104 based on the compliance ( e.g., based on the compliance state) of the user device 118 with the applicable policies (618). For example, if the user device 118 is compliant with all of the policies, the network appliance 110 may provide full access [] if the user device 118 is partially compliant with the policies, the network appliance 110 may provide a limited form of access).
Shravan discloses managing operation of the endpoint device based on the compliance state does not explicitly “to complete the attempted onboarding of the endpoint device to provision desired computer implemented services” and
during an attempted onboarding of an endpoint device of the endpoint devices to a deployment as part of a change in ownership over the endpoint device and after an onboarding voucher has been attempted to be used to establish trust between the endpoint device and an orchestrator of the deployment:
However, in an analogous art, Pritikin discloses
during an attempted onboarding of an endpoint device of the endpoint devices to a deployment as part of a change in ownership over the endpoint device (Pritikin: Section 5, page 36, "The pledge MUST initiate BRSKI after boot if it is unconfigured."; Section 2.5.1, page 21, "The pledge is the device that is attempting to join." Section 2.1, state diagram description, pages 14-16, "The pledge is now a member of, and can be managed by, the domain and will only repeat the discovery aspects of bootstrapping if it is returned to factory default settings.", “"1. Discover a communication channel to a registrar. 2. Identify itself. 3. Request to join the discovered registrar. 4. Imprint on the registrar. 5. Enroll."; Section 1.2 Terminology, Pledge definition, pages 8-10, "Pledge: The prospective (unconfigured) device, which has an identity installed at the factory."; Section 2.5.1, page 21, "The pledge is the device that is attempting to join."; Section 1, Introduction, pages 6-7, "Pledges have an Initial Device Identifier (IDevID) installed in them at the factory."; Section 1.2 Terminology, pages 6-7, Domain definition, "Domain: The set of entities that share a common local trust anchor. This includes the proxy, registrar, domain CA, management components, and any existing entity that is already a member of the domain."; Section 2, Architectural Overview, pages 13-14, "The domain is the managed network infrastructure with a key infrastructure that the pledge is joining."; Section 1.3.4, Bootstrapping is Not Booting, page 12, "Bootstrapping occurs only infrequently such as when a device is transferred to a new owner or has been reset to factory default settings."; Section 1, Introduction , page 7, "The BRSKI protocol requires a significant amount of communication between manufacturer and owner: in its default modes, it provides a cryptographic transfer of control to the initial owner."; Section 1, Introduction , page 7, "Resale of devices is possible, provided that the manufacturer is willing to authorize the transfer."; Section 1.3.4, page 12, "This document describes 'bootstrapping' as the protocol used to obtain a local trust anchor."; Section 1.3.4, page 12, "Bootstrapping occurs only infrequently such as when a device is transferred to a new owner or has been reset to factory default settings."; Section 2.1, Pledge state diagram description , pages 14-16, "The pledge goes through a series of steps, which are outlined here at a high level."; Section 2.1, Step 3, "Request to join the discovered registrar. A unique nonce is included, ensuring that any responses can be associated with this particular bootstrapping attempt."; Section 2.1, Step 4, "Imprint on the registrar. This requires verification of the manufacturer-service-provided voucher."; Section 2.1, Step 5, "Enroll. After imprint, an authenticated TLS (HTTPS) connection exists between the pledge and registrar."; Section 5, page 36, "The pledge MUST initiate BRSKI after boot if it is unconfigured. The pledge MUST NOT automatically initiate BRSKI if it has been configured or is in the process of being configured.") and after an onboarding voucher has been attempted to be used to establish trust between the endpoint device and an orchestrator of the deployment (Pritikin: Section 2.2, page 16, "A voucher is a cryptographically protected artifact (using a digital signature) to the pledge device authorizing a zero-touch imprint on the registrar domain."; Section 1.2, Terminology, pages 8-10, "Voucher: A signed artifact from the MASA that indicates the cryptographic identity of the registrar it should trust to a pledge."; Section 2.1, Step 4, page 15, "Imprint on the registrar. This requires verification of the manufacturer-service-provided voucher. A voucher contains sufficient information for the pledge to complete authentication of a registrar."; Section 2.4, Protocol Flow, pages 19-21, "After the registrar has applied any local policy to the voucher, if it accepts the voucher, then the voucher is returned to the pledge for imprinting."; Section 1.2, Terminology, page 8-10, "The process where a device obtains the cryptographic key material to identify and trust future interactions with a network." Section 2.1, Step 3, page 15, "Request to join the discovered registrar. A unique nonce is included, ensuring that any responses can be associated with this particular bootstrapping attempt."; Section 1, Introduction, page 6-7, "Before any other operation, the pledge and registrar need to establish mutual trust: 1. Registrar authenticating the pledge...2. Registrar authorizing the pledge...3. Pledge authenticating the registrar...4. Pledge authorizing the registrar." ; Section 1.2, page 9, Join Registrar definition, "Join Registrar (and Coordinator): A representative of the domain that is configured, perhaps autonomically, to decide whether a new device is allowed to join the domain. The administrator of the domain interfaces with a 'Join Registrar (and Coordinator)' to control this process. Typically, a Join Registrar is 'inside' its domain."; Section 2.5.3, Domain Registrar, page 22, " domain's registrar operates as the BRSKI-MASA client when requesting vouchers from the MASA. The registrar operates as the BRSKI-EST server when pledges request vouchers."; Section 2.4, Protocol Flow temporal sequence, page 19-20.)
to complete the attempted onboarding of the endpoint device to provision desired computer implemented services (Pritikin: Abstract, page 2, "Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device."; Section 2.1, after Step 5, page 16, "The pledge is now a member of, and can be managed by, the domain and will only repeat the discovery aspects of bootstrapping if it is returned to factory default settings."; Section 1.2, Terminology, enrollment, page 9: "The process where a device presents key material to a network and acquires a network-specific identity."; Section 2.5.1, Pledge, page 21: "In most cases, the pledge has no other connectivity until the pledge completes the enrollment process and receives some kind of network credential." Section 2.1, after Step 5, page 16, "The pledge is now a member of, and can be managed by, the domain."; Section 2.4, Protocol Flow, page 20, "Continue with enrollment using now bidirectionally authenticated TLS session per RFC 7030.").
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Pritikin with the method and system of Shravan to include disclose during an attempted onboarding of an endpoint device of the endpoint devices to a deployment as part of a change in ownership over the endpoint device and after an onboarding voucher has been attempted to be used to establish trust between the endpoint device and an orchestrator of the deployment and managing operation of the endpoint device based on the compliance state to complete the attempted onboarding of the endpoint device to provision desired computer implemented services. Pritikin Section 1, pages 6-7 explicitly identifies that the registrar must answer the question: “Is it mine? Do I want it? What are the chances it has been compromised?” but provides no compliance evaluation mechanism for answering it. Pritikin Section 2.4, pages 20-21, further creates an explicit decision window during which the registrar examines “other sources of information to determine whether the device has been tampered with and whether the bootstrap should be accepted” — but leaves that determination mechanism undefined. Shravan provides exactly that missing mechanism — compliance policy evaluation producing a compliance state that governs device admission. A person of ordinary skill in the art would have been motivated to combine the two references because Pritikin itself identifies the authorization problem and creates the decision window that Shravan's compliance machinery fills, and both references are directed to the same problem of securely managing device admission into a managed network domain, making the combination the predictable application of known elements yielding predictable results. KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007)."
Regarding claim 2, the combination of Shravan and Pritikin teaches the method of claim 1. The combination of wherein the compliance policy is specified by an operator a deployment which the endpoint device is attempting to join (Shravan: fig. 5, par. 0041, The network appliance 110 receives the access request and determines the applicable policies for the user device 118 (506) [] The policies include characteristics that, when true, make the policy applicable”, fig. 6, par. 0044, The network appliance 110 determines requirements for relevant policies for access (604). For example, the network appliance 110 may request policies from the policy server 114 applicable to the user device 118); Pritikin: Section 1.2, page, 9, Join Registrar definition; "A representative of the domain that is configured, perhaps autonomically, to decide whether a new device is allowed to join the domain. The administrator of the domain interfaces with a 'Join Registrar (and Coordinator)' to control this process."; Section 2.2, page 16, "The registrar maintains control over the transport and policy decisions, allowing the local security policy of the domain network to be enforced."; Section 2.4, Protocol Flow, page 20 , "After the registrar has applied any local policy to the voucher, if it accepts the voucher, then the voucher is returned to the pledge for imprinting."; Section 2, Architectural Overview, page 14, "The domain is the managed network infrastructure with a key infrastructure that the pledge is joining."; Section 1.2, Domain definition, page 9, "The set of entities that share a common local trust anchor. This includes the proxy, registrar, domain CA, management components, and any existing entity that is already a member of the domain."; Section 2.5.1, Pledge, page 21, "The pledge is the device that is attempting to join."; Section 1.2, Pledge definition. Page 10, The prospective (unconfigured) device, which has an identity installed at the factory.").
Regarding claim 3, the combination of Shravan and Pritikin further teaches the method of claim 2. The combination of Shravan and Pritikin teaches, wherein the validation event is the attempted onboarding of the endpoint device to the deployment (Shravan: par. 0011, in response to receiving, by a network appliance, a first request to access a protected network resource from an endpoint device; Pritikin; section 2.1 Step 3, page 15, "Request to join the discovered registrar. A unique nonce is included, ensuring that any responses can be associated with this particular bootstrapping attempt."; Section 2.4 Protocol Flow, page 20).
Regarding claim 4, the combination of Shravan and Pritikin further teaches the method of claim 3. The combination of Shravan and Pritikin further teaches the, wherein managing operation of the endpoint device based on the compliance state comprises:
in a first instance of the identifying where the compliance state is non-compliant (Shravan par. 0011: "in response to receiving...a first request to access a protected network resource from an endpoint device [] determining which compliance information”; par. 0041, The network appliance 110 receives the access request and determines the applicable policies for the user device 118 (506) [] The policies include characteristics that, when true, make the policy applicable”, par. 0046 , if the user device 118 is compliant with all of the policies, the network appliance 110 may provide full access [] if the user device 118 is partially compliant with the policies, the network appliance 110 may provide a limited form of access).
preventing the onboarding of the endpoint device to complete prior to remediation of the compliance state (Pritikin: 8995 section 5.3, page 40, "If validation fails, the registrar SHOULD respond with the HTTP 404 error code."; section 5.8.3, page 55, "refuse to forward the voucher. The registrar MUST then refuse any EST actions."); and
in a second instance of the identifying where the compliance state is compliant (Shravan par. 0041, "The network appliance 110 receives the access request and determines the applicable policies for the user device 118."— compliant result = device satisfies applicable policies):
allowing the onboarding of the endpoint device to be completed without the remediation of the compliance state (Pritikin; section 5.3, page 40, "If authorization is successful, the registrar obtains a voucher from the MASA service and returns that MASA-signed voucher to the pledge."; Section 2.4, page 21, " this is a binary yes-or-no decision [] if it accepts the voucher, then the voucher is returned to the pledge for imprinting."; section 2.1 Steps 4- 5, page 15, Enroll. After imprint, an authenticated TLS connection exists between the pledge and registrar. EST can then be used to obtain a domain certificate from a registrar.").
Regarding claim 5, the combination of Shravan and Pritikin teaches the method of claim 4. The combination of Shravan and Pritikin further teaches comprising:
providing computer implemented services using the endpoint device after onboarding to the deployment is completed (Shravan: par. 0011, "managing operation of the endpoint device...to provision desired computer implemented services"; par. 0041: "when compliance data satisfies...provides access"; par. 0046: "if compliant...full access"; Pritikin: Abstract, page 1, "Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device. The established secure connection can be used to deploy a locally issued certificate to the device as well"; Section 2.1 after Step 5, page 16"The pledge is now a member of, and can be managed by, the domain"; Section 1.2 Terminology defines enrollment, page 9, "The process where a device presents key material to a network and acquires a network-specific identity"; Section 2.5.1, page 21, “receives some kind of network credential").
Regarding claim 6, the combination of Shravan and Pritikin teaches the method of claim 1. The combination of Shravan and Pritikin further discloses, wherein the compliance policy specifies metrics which must be met for the compliance state of the endpoint device to be identified as compliant (Shravan: par. 0044, a policy may require that the user device 118 have a certain antivirus product, settings of the antivirus product , a certain firewall product, settings of the firewall product, a certain patch management product, settings of the patch management product, a certain status of an application ( e.g., the application is open, etc.), a certain a file on the device, a certain status of one or more ports, and/or settings of registry keys, etc.; Pritikin: section 5.3, page 40).
Regarding claim 7, the combination of Shravan and Pritikin teaches the method of claim 6. The combination of Shravan and Pritikin further teaches wherein the metrics comprise at least one metric selected from a list of metrics consisting of:
possession of a first certificate indicating that the endpoint device was manufactured by a predetermined entity and signed by the predetermined entity (Pritikin: section 2.3, page 16:"Pledge authentication...is via a PKIX-shaped certificate installedduring the manufacturing process. This is the 802.1AR IDevID... Each device manufacturer can generate its own root certificate.");
possession of a second certificate indicating that the endpoint device was manufactured by a predetermined entity and signed by an intermediate entity which the predetermined entity has delegated authority over the endpoint device (Pritikin: section 1.2, page 10, manufacturer definition: "typically the OEM, but in more complex situations, it could be a VALUE ADDED RETAILER (VAR), or possibly even a SYSTEMS INTEGRATOR."; section 3.4 YANG module, pages 27-29: "produced by a pledge's manufacturer or DELEGATE (MASA) to securely assign a pledge to an owner.");
possession of a third certificate indicating that the endpoint device is a particular type of device (Pritikin: section 5.3, page 40, "examples of automated acceptance may include the allowance of: any device of a SPECIFIC TYPE (as determined by the X.509 IDevID)"); and
possession of a fourth certificate indicating that the endpoint device comprises a particular type of hardware (Pritikin: section 2.3, page 6: "Uniquely identifying the pledge by the Distinguished Name (DN) and subjectAltName (SAN) parameters in the IDevID."; Section 5.3, page 40, "a specific device from a vendor (as determined by the X.509 IDevID) against a domain acceptlist").
Regarding claim 8, the combination of Shravan and Pritikin teaches the method of claim 7. The combination of Shravan and Pritikin further teaches wherein at least one of the first certificate, the second certificate, the third certificate, and the fourth certificate is part of the onboarding voucher that delegates authority of the endpoint device to an operator of the endpoint device (Pritikin: section 5.5, pages 41-42, "The voucher-request CMS object includes some number of certificates."; Pritikin: section 3, page 24, A pledge forms the "pledge voucher-request", signs it with its IDevID, and submits it to the registrar; Section 1, page 7, "cryptographic transfer of control to the initial owner."; Section 3.4 Yang Module, pages 27-29, "to securely assign a pledge to an owner.").
Regarding claim 9, the combination of Shravan and Pritikin teaches the method of claim 6. The combination of Shravan and Pritikin further discloses, wherein the compliance policy further specifies characteristics of the endpoint device which must be met for the compliance state of the endpoint device to be identified as compliant (Shravan: par. 0044, a policy may require that the user device 118 have a certain antivirus product, settings of the antivirus product, a certain firewall product, settings of the firewall product, a certain patch management product, settings of the patch management product, a certain status of an application ( e.g., the application is open, etc.), a certain a file on the device, a certain status of one or more ports, and/or settings of registry keys, etc; Pritikin: section 5.3, page 40, any device of specific type, any device from specific vendor, “a specific device from a vendor against a domain acceptlist”).
Regarding claim 10, the combination of Shravan and Pritikin teaches the method of claim 9. The combination of Shravan and Pritikin further teaches, wherein the characteristics comprise at least one characteristic selected from a list of characteristics consisting of:
a type of hardware component in an inventory of the endpoint device (Shravan: par. 0044, a policy may require that the user device 118 have a certain antivirus product, settings of the antivirus product, a certain firewall product, settings of the firewall product, a certain patch management product, settings of the patch management product, a certain status of an application ( e.g., the application is open, etc.), a certain a file on the device, a certain status of one or more ports, and/or settings of registry keys, etc; Pritikin: section 2.3, page 16, "Pledge authentication and pledge voucher-request signing is via a PKIX-shaped certificate installed during the manufacturing process...provides a basis for authenticating the pledge.");
a type of firmware hosted by the endpoint device (Pritikin: section 1.2, page 10, manufacturer terminology: "a single device, with a uniform firmware load, to be shipped directly to all customers. This eliminates costs for the manufacturer. This also reduces the number of products supported in the field, increasing the chance that firmware will be more up to date.");
a type of boot loader hosted by the endpoint device;
a type of operating system hosted by the endpoint device (Shravan: par. 0044, a policy may require that the user device 118 have a certain antivirus product, settings of the antivirus product, a certain firewall product, settings of the firewall product, a certain patch management product, settings of the patch management product, a certain status of an application ( e.g., the application is open, etc.), a certain a file on the device, a certain status of one or more ports, and/or settings of registry keys, et; Pritikin: section 5.3, page 40 , "examples of automated acceptance may include the allowance of: any device of a specific type (as determined by the X.509 IDevID)."); and
a security architecture implemented by the endpoint device (Shravan: par. 0044, a policy may requirestatus of an application ( e.g., the application is open, etc.), a certain a file on the device, a certain status of one or more ports, and/or settings of registry keys, etc.); Pritikin, section 5.8.3., page 55, "it is RECOMMENDED that this only be configured if hardware-assisted (i.e., Transport Performance Metrics (TPM) anchored) Network Endpoint Assessment (NEA) [RFC5209] is supported.").
Regarding claim 15, claim 15 is directed to a non-transitory machine-readable medium (Shravan: par. 0051) having instructions stored therein, which when executed by a processor (Shravan: pars. 0049, 0051), cause the processor to perform operations for managing endpoint devices associated with the method claimed in claim 1; claim 15 is similar in scope to claim 1, and is therefore rejected under similar rationale.
Regarding claim 16, claim 16 is similar in scope to claim 2, and is therefore rejected under similar rationale.
Regarding claim 17, claim 17 is similar in scope to claim 3, and is therefore rejected under similar rationale.
Regarding claim 18, claim 18 is directed to a management system, comprising: a processor (Shravan: pars. 0049, 0051); and a memory (Shravan: par. 0051) coupled to the processor to store instructions, which when executed by the processor, cause the management system to perform operations for managing an endpoint device associated with the method claimed in claim 1; claim 18 is similar in scope to claim 1, and is therefore rejected under similar rationale.
Regarding claim 19, claim 19 is similar in scope to claim 2, and is therefore rejected under similar rationale.
Regarding claim 20, claim 20 is similar in scope to claim 3, and is therefore rejected under similar rationale.
Claims 11 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Shravan et al. (“Shravan,” US 2021/0281576), in view of M. Pritikin et al. (“Pritikin,” RFC 8995, May 2021, pages 1-116), further in view of Ellsworth et al. (“Ellsworth,” US 12,395513).
Regarding claim 11, the combination of Shravan discloses the method of claim 1. Shravan and Pritikin do not explicitly disclose obtaining a scoring system; and obtaining a quantification based, at least in part, on the compliance policy, wherein the compliance state is identified by comparing the quantification to a criteria specified by the scoring system.
However, in an analogous art, Ellsworth discloses
obtaining a scoring system (Ellsworth: Col. 14, lines 14-29; In FIG. 4, a risk assessment component 430 is illustrated as receiving various data feeds from assets on the network (e.g., network 100/200) and outputting various risk scores 340-348 []. The risk assessment component 430 may receive asset data 420 from active scanners 110 or passive scanners 120, probes, or endpoint agents on assets (e.g., assets 130). Additionally, the risk assessment component 430 may receive application data 422 which may be derived from scanners, endpoint agents, or enterprise application management services. One or more risk assessment components 430 may be provided in a network 100/200; Col. 14, line 48 to Col. 15, line 7, In general, these inputs 410, 420, 422, and 424 form a basis for determining intrusion likelihood and exposure risks for assets and endpoint devices 230 of the networks 100/200/300. [] . That is, the rules 410 may connect vulnerabilities to one or more subsets of application data and assets data that would enable to vulnerability to be successfully exploited. The rules 410 may include a risk value or generalized scale that scores particular vulnerability to application data pairs or scores particular vulnerability to asset data pairs, or a combination thereof (e.g., score for application X on asset Y, if vulnerability Z)); and
obtaining a quantification base, at least in part, on the compliance policy (Ellsworth: Col. 14, line 48 to Col. 15, In general, these inputs 410, 420, 422, and 424 form a basis for determining intrusion likelihood and exposure risks for assets and endpoint devices 230 of the networks 100/200/300. [] . That is, the rules 410 may connect vulnerabilities to one or more subsets of application data and assets data that would enable to vulnerability to be successfully exploited .The rules 410 may include a risk value or generalized scale that scores particular vulnerability to application data pairs or scores particular vulnerability to asset data pairs, or a combination thereof (e.g., score for application X on asset Y, if vulnerability Z); Col. 20, lines 53-64, The endpoint agents 310/320 of asset 520 may be equipped with rules 410 and plugins to identify vulnerabilities in one or more of the applications (e.g., second application 723) or the other elements 732-738 of the asset 520. The endpoint agents 310 may also collect activity information, configuration information, functional information, or environmental information from the applications 721-727, elements 732-738, interface 740, and configuration 750. The endpoint agents 310 may perform some risk assessments based on rules 410 provided to them and may transmit the collected information to a central risk assessment component 430 as described above), wherein the compliance state is identified by comparing the quantification to a criteria specified by the scoring system (Ellsworth: Col. 18, line 31-45, The risk score 442 related to functional aspects, the risk score 444 related to configuration aspects, the risk score 446 related to activity aspects, and the risk score 448 related to environmental aspects may be combined in various ways to form a combined score 440. The combined score 340 may define a risk of exploitation from a vulnerability or set of vulnerabilities for an application or an asset with respect to the functional, configuration, environment, and activity aspects based on a weighting or average of these aspects. That is, these aspects of the risk to an application or an asset or an application on an asset may not be equal for the same application on different assets or for the same asset in two areas of the network. Accordingly, it is contemplated that these scores may change quickly with changed environment, for example; Col. 18, limes 46-55, The scores 440-448 may be provided to a database, a dashboard, a display or other manner of presentation. The scoring for vulnerabilities and sets of vulnerabilities may be individually presented for each application on each asset or for an application or for an asset including all of its applications. The scores 440-448 or 440 may be sorted based on riskiness depict the applications or assets most vulnerable to exploitation. The scores 440-448 may be logged and may be used to alert security professionals based on a threshold being exceeded by one of the scores 440-448).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Ellsworth Shravan and Pritikin with the method and system of Shravan to include obtaining a scoring system; and obtaining a quantification based, at least in part, on the compliance policy, wherein the compliance state is identified by comparing the quantification to a criteria specified by the scoring system. One would have been motivated to provide comprehensive endpoint security assessment capabilities (Shravan: par. 0027; Ellsworth: Col. 8, lines 52-61; Col. 13, limes 24-35).
Regarding claim 14, the combination of Shravan and Pritikin discloses the method of claim 1. The combination of Shravan Pritikin discloses identifying validation event as recited above but does not explicitly disclose audit-type validation events
However, in an analogous art, Ellsworth teaches that the vulnerability scan/audit serves as the triggering event that initiates compliance evaluation (Ellsworth: Col. 13, limes 24-35, an endpoint agent 320 running on an endpoint device 230 may perform a vulnerability scan of the endpoint device 230. In an implementation, the vulnerability scan performed by the endpoint agent 320 need not be limited to scanning active applications and/or services, i.e., need not be limited to applications/services currently running on the endpoint device 230; Col. 13, lines 36-49; endpoint agent 320 performs the vulnerability scan on corresponding endpoint device 230, the vulnerability scan may be correlated with the discovered assets and/or the identified vulnerabilities; par. 0048, the vulnerability management system 250 may be configured to correlate the discovered assets and/or the identified vulnerabilities with vulnerability scan (e.g., provided in the vulnerability scan report). The passive scanners 220, active scanners 110, and endpoint scanners 310 and endpoint agents 320 may transmit scan results to the vulnerability management system 250; Col. 8, lines 52-61, the active scanners 110 may include one or more agents (e.g., lightweight programs) locally installed on a suitable asset 130 and given sufficient privileges to collect vulnerability, compliance, and system data to be reported back to the vulnerability management system 150. As such, the credentialed audits performed with the active scanners 110 may generally be used to obtain highly accurate host-based data that includes various client-side issues (e.g., missing patches, operating system settings, locally running services, etc.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Ellsworth Shravan with the method and system of Shravan and Pritikin to include wherein the validation event is an audit of the endpoint device. One would have been motivated to provide comprehensive endpoint security assessment capabilities (Shravan: par. 0027; Ellsworth: Col. 8, lines 52-61, Col. 13, limes 24-35).
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Shravan et al. (“Shravan,” US 2021/0281576), in view of M. Pritikin et al. (“Pritikin,” RFC 8995, May 2021, pages 1-116), further in view of Bainbridge et al. (“Bainbridge,” US 2024/0281280).
Regarding claim 12, the combination of Shravan and Pritikin discloses the method of claim 1. The combination of Shravan discloses identifying validation event as recited above but does not disclose assignment workload-type validation events
However, in an analogous art, Bainbridge discloses assignment/scheduling of workloads to nodes triggers compliance tracking (Bainbridge: abstract, par. 0004, receiving unassigned workloads for assignment on nodes for execution; and, responsive to a scheduling trigger, scheduling the multiple unassigned workloads; par. 0005, subsequent to the scheduling and implementation of the workload, tracking compliance of the workload to the constraint policy; and, responsive to a violation of the compliance, performing one or more of ignoring the violation, mediating the violation to meet the compliance, and evicting the workload; par. 0033, "periodic policy rule evaluation" and "marking of those policies as within compliant, within limits, or in violation, "periodic policy rule evaluation" and "marking of those policies as within compliant, within limits, or in violation.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Bainbridge with the method and system of Shravan and Pritikin to include wherein the validation event is an assignment of a workload. One would have been motivated to provide the method allowing workloads to be scheduled considering both already scheduled workloads and workloads that are not yet scheduled. The method allows an operator to define a common or shared set of constraints and apply them to multiple workloads (Bainbridge: pars. 0002, 0048).
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Shravan et al. (“Shravan,” US 2021/0281576), in view of M. Pritikin et al. (“Pritikin,” RFC 8995, May 2021, pages 1-116), and Bainbridge et al. (“Bainbridge,” US 2024/0281280), further in view of Rao et at. (“Rao,” US 2021/0174089).
Regarding claim 13, the combination of Shravan, Pritikin, and Bainbridge discloses the method of claim 12. The combination of Shravan, Pritikin, and Bainbridge further discloses the wherein the validation event is an assignment of a workload as recited above but does not explicitly disclose, “wherein managing the operation of the endpoint device comprises: in a first instance of the identifying where the compliance state is non-compliant: rejecting the endpoint device as a candidate for the workload; and in a second instance of the identifying where the compliance state is compliant: accepting the endpoint device as the candidate for the workload.”
However, in an analogous art, Rao discloses
in a first instance of the identifying where the compliance state is non-compliant: rejecting (Rao: par. 0036, may include a policy defined by an entity associated with the server device (e.g., a social media service provider) and may specify rules for content that is non-compliant (e.g., and should be rejected) and rules for content that is compliant ( e.g., and should be approved)); and
in a second instance of the identifying where the compliance state is compliant: accepting (Rao: par. 0036, may include a policy defined by an entity associated with the server device (e.g., a social media service provider) and may specify rules for content that is non-compliant (e.g., and should be rejected) and rules for content that is compliant ( e.g., and should be approved)).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Rao with the method and system of Shravan, Pritikin, and Bainbridge to include in a first instance of the identifying where the compliance state is non-compliant: rejecting the endpoint device as a candidate for the workload; and in a second instance of the identifying where the compliance state is compliant: accepting the endpoint device as the candidate for the workload. One would have been motivated to apply Rao's established accept/reject logic to solve the known problem of managing endpoint devices based on compliance state, yielding the predictable benefit of enhanced workload deployment security.
Conclusion
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 extension fee 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 CANH LE whose telephone number is (571)270-1380. The examiner can normally be reached on Monday to Friday 6:00AM to 3:30PM other Friday off.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Luu Pham, can be reached at telephone number 571-270-5002. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center and the Private Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from Patent Center or Private PAIR. Status information for unpublished applications is available through Patent Center and Private PAIR for authorized users only. Should you have questions about access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/Canh Le/
Examiner, Art Unit 2439
March 11th, 2026
/LUU T PHAM/Supervisory Patent Examiner, Art Unit 2439