DETAILED ACTION
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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 9/10/2026 has been entered.
Response to Amendment / Arguments
Regarding claims rejected under 35 USC 103:
Independent claims 1, 13, and 14; Dependent claims 3 and 16:
Applicant’s arguments, in view of the amended claim language, have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Patel (“AI-Enabled Cybersecurity Threat Prediction and Response Systems for Distributed Computing Environments”).
Dependent claims 10, 11, 23, and 24:
Applicant's arguments have been fully considered but they are not persuasive.
Applicant argues that each claim “requires that a revised reputation score be computed from the execution result and stored in a blockchain. Those two halves sit in different references and neither reference contains the other: Safford, the only reference of record disclosing a blockchain, computes no score of any kind its graded output is the three-state status "secure," "warning," or "compromised," written as a new timestamped record on each attestation rather than a value that is revised while Mehr, which does update its trust score, never mentions a blockchain or any distributed ledger. The only reason given for joining them is the reason given for putting an attestation report on chain, "preventing attempts at spoofing reports," which is a reason to ledger an attestation report and not a reason to ledger a reputation score.” In response to Applicant’s argument that there is no teaching, suggestion, or motivation to combine the references, the examiner recognizes that obviousness may be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007). In this case, the cited portions of Safford are drawn to the known usage of utilizing blockchains for storing assertions such as attestations in a provable and public manner to address the byzantine generals problem. Thus, placing information on a blockchain helps to prevent attempts at fraud concerning reported information.
In response to applicant's argument that “[t]hose two halves sit in different references and neither reference contains the other,” the test for obviousness is not whether the features of a secondary reference may be bodily incorporated into the structure of the primary reference; nor is it that the claimed invention must be expressly suggested in any one or all of the references. Rather, the test is what the combined teachings of the references would have suggested to those of ordinary skill in the art. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981). In this case, the prior art suggests using blockchains to hold reported information in a trusted manner.
Dependent claims 2 and 15:
Applicant's arguments have been fully considered but they are not persuasive.
Applicant argues that “Mehr nowhere refers to a fault, a failure, or a deployment, and the score revision it does describe is triggered by "a change in the characteristics of that cotenant" (col. 20, 11. 56-58) rather than by counting faults after a deployment. The nearest language, "the frequency of the security problems" (col. 20, 11. 1-2), concerns "publically known security issues" and self-reported "security issues," which are neither faults nor tied to a deployment. Applicant notes for the record that these claims require the score to be revised based on such a number, and that the Office Action recites them as reciting only that the score "is based on" it.” In response, it is noted that Col. 3, Ll. 44-Col. 4, Ll. 3 and Col. 20, Ll. 36-41 of Mehr explicitly discuss recalculating the score for each tenant based on their respective performance characteristics (e.g., failures). The recalculation may take place after launch. This is considered to disclose revising the reputation score since Mehr recalculates its score after launch and based on the performance characteristics.
Dependent claims 4 and 17:
Applicant’s arguments have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Dependent claims 12 and 25:
Applicant's arguments have been fully considered but they are not persuasive.
Applicant argues that each claim “requires determining "based on analytics whether a task is threatened by a security risk." Mehr discloses no analytics, and the entity Mehr evaluates is a container and its cotenant policy rather than a task; in Mehr a task is a unit defined in a task definition file, and Mehr nowhere assesses whether such a task is threatened.” In response, it is noted that the claim language merely requires “determine based on analytics whether a task is threatened by a security risk” at a high level of generality as to the task and how it is to be threatened. Thus, Mehr’s teachings of scoring and periodic rescoring based on tasks defined in the task definition file (e.g., a low score indicative of tasks threatened by a security risk).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
Claim(s) 1-6, 9-19, and 22-25 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sharifi Mehr (US 10,104,185 B1), hereinafter “Mehr,” in view of Kanso (US 11,956,266 B2), Safford (US 2018/0287780 A1), and Patel (“AI-Enabled Cybersecurity Threat Prediction and Response Systems for Distributed Computing Environments”).
Regarding claim 1, Mehr discloses: A system for implementing intent-driven security mechanisms, comprising:
a processor; and
memory to store instructions, which when executed by the processor (e.g., FIG. 16 of Mehr concerning a processor and memory), cause the system to:
determine, based on a risk tolerance intent (i.e., cotenant policy in Mehr) related to execution of an application on a compute node (e.g., Col. 4, Ll. 20-29 of Mehr concerning a container and its programs), whether execution of [a container and its components] requires a trust evaluation; and
Refer to at least Col. 11, 7-13 and Col. 10, Ll. 57-65 of Mehr with respect to launching a new container including an evaluation of whether the container is associated with a cotenant policy.
in response to determining that the [container and its components] requires the trust evaluation: obtain a reputation score of the [container and its components];
Refer to at least Col. 3, Ll. 54-59, Col. 18, Ll. 54-67, and Col. 20, Ll. 31-35 of Mehr with respect to trust scores calculated (or otherwise obtained) for containers associated with the launching. For instance, a trust score for the container to be launched.
determine a minimum reputation score from the risk tolerance intent;
Refer to at least Col. 3, Ll. 66-Col. 4, Ll. 3 and Col. 20, Ll. 9-15 of Mehr with respect to cotenant policy specifying a minimum trust score.
compare the reputation score of the [container and its components] to the minimum reputation score; and
Refer to at least Col. 20, Ll. 3-56, Col. 10, Ll. 13-21, and Col. 11, Ll. 66-Col. 12, Ll. 14 of Mehr with respect to comparing characteristics (including the trust score) of involved containers against associated cotenant policies. For instance, whether the container to be launched meets a minimum trust score.
reject or permit execution of the [container and its components] based on the comparison.
Refer to at least Col. 12, Ll. 15-28 and Col. 20, Ll. 52-56 of Mehr with respect to rejecting or permitting the launch based on the comparison.
monitor the execution of the software-implemented operator to obtain an execution result;
Refer to at least Col. 16, Ll. 4-60 and Col. 20, Ll. 52-62 of Mehr with respect to monitoring the container after launch.
Mehr discusses TPMs generally (e.g., Col. 19, Ll. 37-41) and discloses evaluating a container and its components (e.g., Col. 19, Ll. 1-Col. 20, Ll. 2 of Mehr) for a trust score against a cotenant policy using container agents (e.g., Col. 16, Ll. 19-38 and Col. 9, Ll. 6-10 of Mehr), but it does not specify circuitry to implement a hardware root-of-trust; the container and its components further comprising a software-implemented operator; wherein the software-implemented operator comprises orchestration software that manages deployment of workload containers; wherein the execution result comprises a performance metric of the software-implemented operator obtained by monitoring telemetry during execution. Mehr further does not specify: check the execution result against an expected execution result, the expected execution result comprising a guardrail value corresponding to the reputation score of the software-implemented operator; and attest the execution result by generating an attestation that cryptographically binds the execution result to an identity of the compute node using a device-unique key stored in the hardware root-of-trust, wherein the hardware root-of-trust is selected from a Trusted Platform Module (TPM), a Device Identity Composition Engine (DICE), a DICE Protection Module (DPM), or a RPMB (Replay Protected Memory Block). However, Mehr in view of Kanso discloses: the container and its components further comprising a software-implemented operator;
Refer to at least Col. 20, Ll. 37-Col. 21, Ll. 9 and Col. 23, Ll. 11-Col. 24, Ll. 10 of Kanso with respect to evaluating a container operator for risk.
wherein the software-implemented operator comprises orchestration software that manages deployment of workload containers.
Refer to at least Col. 1, Ll. 15-18, Col. 20, Ll. 37-58, Col. 23, Ll. 10-64 of Kanso with respect to Kubernetes orchestration and operators, which are part of Kubernetes.
The teachings of Mehr and Kanso both concern security evaluation for containers, and are considered to be within the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Mehr to further implement evaluating an operator as part of calculating a risk score for at least the purpose of increasing security by inclusion of additional risk factors (i.e., more coverage and a more comprehensive cotenant policy).
Mehr-Kanso does not specify: circuitry to implement a hardware root-of-trust; wherein the execution result comprises a performance metric of the software-implemented operator obtained by monitoring telemetry during execution; check the execution result against an expected execution result, the expected execution result comprising a guardrail value corresponding to the reputation score of the software-implemented operator; and attest the execution result by generating an attestation that cryptographically binds the execution result to an identity of the compute node using a device-unique key stored in the hardware root-of-trust, wherein the hardware root-of-trust is selected from a Trusted Platform Module (TPM), a Device Identity Composition Engine (DICE), a DICE Protection Module (DPM), or a RPMB (Replay Protected Memory Block). However, Mehr-Kanso in view of Safford discloses: circuitry to implement a hardware root-of-trust;
Refer to at least [0038] and [0045] of Safford with respect to a TPM providing a root of trust.
check the execution result against an expected execution result;
Refer to at least [0029]-[0030] and FIG. 2 of Safford with respect to matching an actual integrity value against a reported integrity value for a run-time report.
attest the execution result by generating an attestation that cryptographically binds the execution result to an identity of the compute node using a device-unique key stored in the hardware root-of-trust, wherein the hardware root-of-trust is selected from a Trusted Platform Module (TPM), a Device Identity Composition Engine (DICE), a DICE Protection Module (DPM), or a RPMB (Replay Protected Memory Block).
Refer to at least [0038] and [0045]-[0047] of Safford with respect to attestation for the run-time report using the TPM. The TPM implements a secure enclave for security keys (e.g., a private key) used in establishing device identity.
The teachings of Safford likewise concern security evaluation for client devices and are considered to be within the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Mehr-Kanso to further implement run-time attestation using a TPM for at least the purpose of ensuring QoS and preventing erroneous or misconfigured execution; as well as to allow for auditing. Use of a TPM adds further security against tampering.
Mehr-Kanso-Safford does not specify: wherein the execution result comprises a performance metric of the software-implemented operator obtained by monitoring telemetry during execution; the expected execution result comprising a guardrail value corresponding to the reputation score of the software-implemented operator. However, Mehr-Kanso-Safford in view of Patel discloses: wherein the execution result comprises a performance metric of the software-implemented operator obtained by monitoring telemetry during execution;
Refer to at least the abstract, paragraph 1 on page 12, 3.1, and 3.2.1-3.2.2 of Patel with respect to obtaining telemetry (e.g., metrics) from, e.g., containers.
the expected execution result comprising a guardrail value corresponding to the reputation score of the software-implemented operator.
Refer to at least the abstract, 3.2.2, 5.3, and 7.1 of Patel with respect to guardrails associated with a risk score and ensuring compliance with policy.
The teachings of Patel likewise Kubernetes and concern security evaluation for containers, and are considered to be within the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Mehr-Kanso-Safford to further implement additional behavioral monitoring (as in Patel) as part of the security policy for at least the purpose of more accurately identifying risk (i.e., more input data for analysis and assessment), upholding policy and service requirements (i.e., the cited portions of Patel), and shutting down misbehaving containers during re-evaluation as in, e.g., Col. 16, Ll. 33-45 of Mehr.
Regarding claim 2, Mehr-Kanso-Safford-Patel discloses: The system of claim 1, wherein the reputation score is revised based on a number of subsequent faults after a deployment of the software-implemented operator.
Refer to at least Col. 3, Ll. 44-50, Col. 16, Ll. 4-63, and Col. 20, Ll. 36-41 of Mehr with respect to subsequently reevaluating the risk score. For instance, compliance failures may result in a violation.
Regarding claim 3, Mehr-Kanso-Safford-Patel discloses: The system of claim 1, wherein the reputation score is revised based on telemetry indicating service mesh disruption caused by the software-implemented operator.
Refer to at least 2.3, 3.1, and 3.2.1 of Patel with respect to service mesh information as part of the telemetry and machine learning analysis for remediation.
This claim would have been obvious for substantially the same reasons as claim 1 above.
Regarding claim 4, Mehr-Kanso-Safford-Patel discloses: The system of claim 1, wherein the reputation score is revised based on application service level agreement (SLA) violations caused by the software-implemented operator.
Refer to at least Col. 19, Ll. 62-Col. 20, Ll. 2 with respect to past security problems as a risk score factor; with respect to Col. 20, Ll. 53-61 and Col. 16, Ll. 4-60 of Mehr with respect to evaluating policy compliance.
Refer to at least the abstract of Patel with respect to service level objectives as part of the machine learning analysis.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Mehr-Kanso-Safford-Patel to further implement SLA compliance as a risk score factor for substantially the same reasons as claim 1 above (e.g., more coverage and a more comprehensive cotenant policy—e.g., a tenant may not want to share space with another tenant known for SLA violations, which may be indicative of poor security compliance).
Regarding claim 5, it is rejected for substantially the same reasons as claim 2 above (i.e., the citations). Refer to at least TABLE I in Col. 8 of Mehr with respect to an operational history as a factor; Col. 19, Ll. 1-Col. 20, Ll. 2 of Mehr concerning factors such as past bugs and security problems.
Regarding claim 6, it is rejected for substantially the same reasons as claim 5 above (e.g., Col. 19, Ll. 1-Col. 20, Ll. 2 of Mehr concerning factors such as past bugs and security problems).
Regarding claim 9, Mehr-Kanso-Safford-Patel discloses: The system of claim 1, wherein the system is to store the execution result and the attestation in a blockchain.
Refer to at least the abstract, [0031], [0038]-[0039], and [0048] of Safford with respect to storing attestation reports to a blockchain.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Mehr-Kanso-Safford-Patel to further implement on-chain reporting for at least the purpose of preventing attempts at spoofing reports (i.e., placing reports on a publicly available ledger which is easy to check but extremely difficult to maliciously modify, as per the properties of blockchain).
Regarding claim 10, Mehr-Kanso-Safford-Patel discloses: The system of claim 9, wherein the system is to: compute a revised reputation score based on the execution result (Col. 16, Ll. 4-60 and Col. 20, Ll. 52-62 of Mehr concern recomputing the trust score based on monitoring); and store the revised reputation score in the blockchain.
Refer to at least the abstract, [0031], [0038]-[0039], and [0048] of Safford with respect to storing attestation reports to the blockchain.
This claim would have been obvious for substantially the same reasons as claim 9 above.
Regarding claim 11, Mehr-Kanso-Safford-Patel discloses: The system of claim 10, wherein to compute the revised reputation score, the system is to evaluate historical operation of the software-implemented operator, a source of the software- implemented operator, or the compute node that the software-implemented operator executed on.
Refer to at least TABLE I in Col. 8 of Mehr with respect to an operational history as a factor; Col. 19, Ll. 1-Col. 20, Ll. 2 of Mehr concerning factors such as past bugs and security problems.
Regarding claim 12, Mehr-Kanso-Patel discloses: The system of claim 1, where the system is to: determine based on analytics whether a task is threatened by a security risk; and
Refer to at least Col. 16, Ll. 21-38 of Mehr with respect to monitoring compliance (i.e., with a tenant’s task definition having cotenant policy as in Col. 6, Ll. 45-60 of Mehr).
initiate a responsive action that is consistent with the risk tolerance intent.
Refer to at least Col. 12, Ll. 15-28 and Col. 20, Ll. 52-56 of Mehr with respect to remedial actions based on, e.g., policy violations.
Regarding independent claim 13, it is substantially similar to independent claim 1 above, and is therefore likewise rejected (i.e., the citations and obviousness rationale).
Regarding independent claim 14, it is substantially similar to independent claim 1 above, and is therefore likewise rejected (i.e., the citations and obviousness rationale).
Regarding claims 15, 17-19, and 25, they are substantially similar to claims 2, 4-6, and 12 above, and are therefore likewise rejected.
Regarding claim 16, it is substantially similar to claim 3 above, and is therefore likewise rejected.
Regarding claims 22-24, they are substantially similar to claims 9-11 above, and are therefore likewise rejected.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VADIM SAVENKOV whose telephone number is (571)270-5751. The examiner can normally be reached 12PM-8PM.
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, Jeffrey L Nickerson can be reached at (469) 295-9235. 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.
/Jeffrey Nickerson/Supervisory Patent Examiner, Art Unit 2432
/V.S/Examiner, Art Unit 2432
