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 .
Response to Amendment / Arguments
Regarding claims rejected under 35 USC 103:
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 Altmaier (US 11,811,804 B1).
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-2, 4-6, 9-15, 17-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 Altmaier (US 11,811,804 B1).
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 an output generated by the software-implemented operator during execution. Mehr further does not specify: check the execution result against an expected execution result; 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 an output generated by the software-implemented operator during execution; check the execution result against an expected execution result; 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 an output generated by the software-implemented operator during execution. However, Mehr-Kanso-Safford in view of Altmaier discloses: wherein the execution result comprises an output generated by the software-implemented operator during execution.
Refer to at least the abstract, FIG. 2, Col. 1, Ll. 45-62, and Col. 3, Ll. 63-Col. 4, Ll. 52 of Altmaier with respect to agents for monitoring operating signals of a Kubernetes orchestrator to determine anomalies.
The teachings of Altmaier 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 part of the security policy for at least the purpose of more accurately identifying risk (i.e., more input data for analysis and assessment) 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-Altmaier discloses: The system of claim 1, wherein the reputation score is 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 4, Mehr-Kanso-Safford-Altmaier discloses: The system of claim 1, wherein the reputation score is 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 Col. 31, Ll. 19-25 of Kanso with respect to SLAs having required service levels.
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 SLA compliance as a risk score factor for substantially the same reasons as claim 1 above (i.e., 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-Altmaier 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 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-Altmaier 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-Altmaier 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-Altmaier 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 claims 22-24, they are substantially similar to claims 9-11 above, and are therefore likewise rejected.
Claim(s) 3 and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mehr-Kanso-Safford-Altmaier as applied to claims 1-2, 4-6, 9-15, 17-19, and 22-25 above, and further in view of Kravtsov (US 11,822,672 B1).
Regarding claim 3, Mehr-Kanso-Safford-Altmaier does not specify: wherein the reputation score is based on telemetry indicating service mesh disruption caused by to the software-implemented operator. However, Mehr-Kanso-Safford-Altmaier in view of Kravtsov discloses: wherein the reputation score is based on telemetry indicating service mesh disruption caused by to the software-implemented operator.
Refer to at least Col. 5, Ll. 46-60 of Kravtsov with respect to a risk assessment concerning the service mesh for containers.
The teachings of Kravtsov likewise 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-Altmaier to further implement the service mesh as a risk score factor for at least the purpose of increasing security by inclusion of additional risk factors (i.e., more coverage and a more comprehensive cotenant policy).
Regarding claim 16, it is substantially similar to claim 3 above, and is therefore likewise rejected.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
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 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
Prosecution Insights