DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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 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.
Claims 1-20 are pending.
Examiner Note
In light of ¶56 of the originally filed specification which states “A computer-readable storage medium, as that term is used in the present disclosure, is not to be construed as storage in the form of transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide, light pulses passing through a fiber optic cable, electrical signals communicated through a wire, and/or other transmission media”, the claimed “computer readable storage medium” in claims 1 and 10 has been interpreted as a non-transitory computer readable storage medium.
Claim Objections
Claims 1, 4, 2, 8, 10, 11, 16, 17, and 20 are objected to because of the following informalities:
In this section, line numbers shown in the claim set have been used for referencing in most cases.
“a trusted execution environment” in line 6 of claim 1, line 20 of claim 10, line 9 of claim 16 should read “the trusted execution environment”.
“the executed command of the control element” in claims 2, 11, 17 should read “the executed command
“the remediation action of the control element” in claims 2, 11, 17 should read “the remediation action
“the control element having the executed command” in claims 4, 8, 20 should read “the control element including the executed command”.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
In this section, line numbers shown in the claim set have been used for referencing in most cases.
Claim 1 recites “the element” in line 14. However, it’s unclear whether this refers to “an element” in line 8, “an element” in line 13 or some other element. Claims 2-9 depend from claim 1 and thus also have this issue. For examination purposes, “the element” in line 14 has been interpreted as referring to “an element” in line 13.
Claim 5 recites “the verifying compliance of an element” in lines 1-2 of claim 5. However, it’s unclear whether this refers to “to verify compliance of an element” in line 8 of claim 1 or “to verify compliance of an element” in lines 12-13 of claim 1. For examination purposes, “the verifying compliance of an element” in lines 1-2 of claim 5 has been interpreted as referring to “to verify compliance of an element” in lines 12-13 of claim 1.
Claim 8 recites “the control element” in lines 2 and 4. However, it’s unclear whether this refers to “control element” in line 7 of claim 1 or “the triggered control element” in line 12 of claim 1. For examination purposes, “the control element” in lines 2 and 4 has been interpreted as referring to “control element” in line 7 of claim 1.
Claim 10 recites “the element” in its last two lines. However, it’s unclear whether this refers to “an element” in line 23, “an element” in line 28 or some other element. Claims 12-15 depend from claim 10 and thus also have this issue. For examination purposes, “the element” in last two lines has been interpreted as referring to “an element” in line 28.
Claim 16 recites “the element” in line 17. However, it’s unclear whether this refers to “an element” in line 11, “an element” in line 16 or some other element. Claims 17-20 depend from claim 16 and thus also have this issue. For examination purposes, “the element” in line 17 has been interpreted as referring to “an element” in line 16.
Claim 20 recites “the control element” in lines 12 and 14. However, it’s unclear whether this refers to “control element” in line 10 of claim 16 or “the triggered control element” in line 15 of claim 16. For examination purposes, “the control element” in lines 12 and 14 has been interpreted as referring to “control element” in line 15 of claim 16.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-6, 10-13, and 16-18 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Smith (US 20240241944).
Claim 1, Smith discloses A computer program product for performing integrity check of an application in a trusted computing environment, the computer program product comprising a computer readable storage medium having computer readable program code embodied therein that when executed performs operations, (e.g. ¶260, 267) the operations comprising:
providing a control program for a trusted execution environment having a plurality of control elements provided by users, wherein a control element of the control elements includes a command to execute to verify compliance of an element in a workload in the trusted execution environment with a requirement; (e.g. ¶55, 57, 59-60, 62, 64, 67-68, 84, 121: Security measures are complicated by static aspects and dynamic aspects of workload execution. Even when a system is following best practices, there may be a number of dynamic aspects of security risks that only arise during time of the execution. For example, the workload itself might have dependencies, so the security risk might only become apparent at a later time (e.g., days, weeks, months, years after the initial deployment) when the dependencies are invoked during execution. There may also be a concern of a security risk in the workload itself or an action involved with the workload, including whether the resource or action involved in the workload has been previously exploited, or is subject to a newly discovered vulnerability…A security intent as discussed herein is a definition of security features or requirements, which includes some set of multiple expressed primitives related to security aspects such as confidentiality, integrity, isolation, auditability, etc. Security intents can be customized to a given containerized or non-containerized workload based on the workload's application context needs, for instance, to enable the containerized workload to be rendered with more security or less security. Accordingly, the security primitives allow control of the defined aspects to ensure that properties such as confidentiality, integrity, auditability can be successfully met, and that appropriate remedial measures can enhance security functionality when needed…The high-level intents 704 may specify some details of workload execution, such as target latency or performance metrics (including those metrics corresponding to a service level objective or service level agreement). Based on these intents, various execution plans 710 are evaluated and explored, and a “best” execution plan is selected and executed 720. The execution of the best plan 720 is used to implement various aspects of the workload processing based on the high-level intents 704. Periodic or event-driven monitoring is used to detect deviations in the desired state, which trigger re-planning and corrective actions…even customers and end users can provide and update a workload specification that provide aspects of security intents…dynamic aspects of security risks include those risks noted above, with the additional consideration of security conditions encountered at runtime of the specific workload. Such conditions at runtime may be caused by conditions such as: the workload itself may have dependencies; specific vulnerabilities may have different levels of risk or exploitation; different types of vulnerabilities may exist; workload dependencies may be vulnerable, or the workload dependency might be exploitable; other workloads might attack a particular workload; or a workload might have its own vulnerabilities and other workloads might have their own vulnerabilities…if the user has specified high confidentiality (e.g., an intent of “confidentiality: high” in the intent definition), this intent can translate into launching the workload 702 in a hardware-enabled trusted execution environment…The use of security intents 706 thus provides an additional specification of execution features to ensure appropriate security actions are performed. Within the node, the high-level security intent is translated into low-level security actions, to address the whole set of high-level requirements. Thus, in contrast to the use of individual security tools, the security intents 706 can be used to invoke a series of tools and actions—on demand—that operationalize and apply an overall security policy for workload execution. This can help ensure that a specified security model will correctly apply to the specific workload execution…even a TEE-protected workload can be malicious and launch attacks on other workloads, so even a TEE-protected workload needs to plug vulnerabilities and have appropriate network security measures in place)
detecting a trigger event associated with a triggered control element of the control elements during execution of the workload in the trusted execution environment; and (e.g. ¶60, 64, 69, 87, 125: The execution of the best plan 720 is used to implement various aspects of the workload processing based on the high-level intents 704. Periodic or event-driven monitoring is used to detect deviations in the desired state, which trigger re-planning and corrective actions…dynamic aspects of security risks include those risks noted above, with the additional consideration of security conditions encountered at runtime of the specific workload. Such conditions at runtime may be caused by conditions such as: the workload itself may have dependencies; specific vulnerabilities may have different levels of risk or exploitation; different types of vulnerabilities may exist; workload dependencies may be vulnerable, or the workload dependency might be exploitable; other workloads might attack a particular workload; or a workload might have its own vulnerabilities and other workloads might have their own vulnerabilities…The dynamic phase operations 740 involves monitoring workloads for any new vulnerabilities and taking action (such as when triggered by a new CVE detection), with the security risk monitoring 730…monitoring is performed with the use of a monitoring component. The monitoring component periodically checks to determine if any new vulnerabilities have been reported that affects the running workloads…Operation 2140 includes controlling the execution of the workload within the execution environment, based on the identified security intents. This may include the use of security hygiene as discussed above. For instance, security hygiene may include perform ongoing scanning of the execution environment and the workload to identify common vulnerabilities and exposures (CVEs). Then, operations to adapt the execution environment can be performed based on a remedial action in response to the identified CVEs. In still further examples, controlling the execution of the workload may include monitoring the execution of the workload with a trust coordination framework, as discussed above. This can enable detection of real-time/dynamic changes and security conditions that might not be immediately detected.)
executing the command for the triggered control element to verify compliance of an element in the workload, wherein the triggered control element is executed multiple times during execution of the workload to verify compliance of the element in the workload in response to multiple instances of detecting the trigger event. (e.g. ¶60, 64, 69, 83, 87, 121, 125, 134: The execution of the best plan 720 is used to implement various aspects of the workload processing based on the high-level intents 704. Periodic or event-driven monitoring is used to detect deviations in the desired state, which trigger re-planning and corrective actions…dynamic aspects of assessing and implementing security measures. Such aspects of security risks may include evaluating the workload or the system for Common Vulnerabilities and Exposures (CVEs, e.g., publicly disclosed computer security flaws), evaluating the particular configuration of a container used with the workload (e.g., capabilities, signature validation), and the application and verification of security policies on a node or cluster-based level. As an example, dynamic aspects of security risks include those risks noted above, with the additional consideration of security conditions encountered at runtime of the specific workload. Such conditions at runtime may be caused by conditions such as: the workload itself may have dependencies; specific vulnerabilities may have different levels of risk or exploitation; different types of vulnerabilities may exist; workload dependencies may be vulnerable, or the workload dependency might be exploitable; other workloads might attack a particular workload; or a workload might have its own vulnerabilities and other workloads might have their own vulnerabilities…The dynamic phase operations 740 involves monitoring workloads for any new vulnerabilities and taking action (such as when triggered by a new CVE detection), with the security risk monitoring 730…monitoring is performed with the use of a monitoring component. The monitoring component periodically checks to determine if any new vulnerabilities have been reported that affects the running workloads…Operation 2140 includes controlling the execution of the workload within the execution environment, based on the identified security intents. This may include the use of security hygiene as discussed above. For instance, security hygiene may include perform ongoing scanning of the execution environment and the workload to identify common vulnerabilities and exposures (CVEs). Then, operations to adapt the execution environment can be performed based on a remedial action in response to the identified CVEs. In still further examples, controlling the execution of the workload may include monitoring the execution of the workload with a trust coordination framework, as discussed above. This can enable detection of real-time/dynamic changes and security conditions that might not be immediately detected…Operation 2250 includes dynamically monitoring the execution of the workload on the selected computing node, to verify compliance. This may implement the operations discussed in operation 2140, above, as performed by an orchestrator.)
Claim 2, Smith discloses The computer program product of claim 1, wherein a control element of the control elements includes a remediation action to execute if the executed command of the control element does not verify compliance of the element in the workload, wherein the operations further comprise: executing the remediation action of the control element in response to the executed command of the control element not verifying compliance of the element in the workload. (e.g. ¶57, 69, 83, 125)
Claim 3, Smith discloses The computer program product of claim 2, wherein the remediation action is a member of a set of remediation actions consisting of shutting down the workload executing in the trusted execution environment, implementing a read-only mode for operations in the workload, restricting access to resources in the workload, executing a fix program to modify parameters in the workload, key rotation, and disable features. (e.g. ¶69, 83-84, 125)
Claim 4, Smith discloses The computer program product of claim 2, wherein the operations further comprise: including a result of the executing the remediation action in a record identifying the control element having the executed command; and returning the record to a user that provided the control element having the executed remediation action. (e.g. ¶78, 83)
Claim 5, Smith discloses The computer program product of claim 1, wherein the verifying compliance of an element of the workload is a member of a set of compliance verifications consisting of: comparing a software bill of materials of the workload with a list of vulnerabilities; checking vulnerability of databases accessed by the workload; monitoring workload behavior for behavior indicating vulnerabilities; checking for network activity indicating vulnerabilities; and checking on operability of dependent systems. (e.g. ¶64, 84-85, 89, 125)
Claim 6, Smith discloses The computer program product of claim 1, wherein the trigger event is a member of a set of trigger events consisting of expiration of a time period, an occurrence of a specified result in the workload, and an unauthorized user attempting to access a resource. (e.g. ¶60, 64, 69, 87, 125)
Claim 10, this claim is rejected for similar reasons as in claim 1. Smith further discloses A system for performing integrity check of an application in a trusted computing environment, comprising: a processor; and a computer readable storage medium having computer readable program code embodied therein that when executed by the processor performs operations (e.g. ¶260, 267).
Claims 11-13, these claims are rejected for similar reasons as in claims 2, 4, and 5.
Claim 16, this claim is rejected for similar reasons as in claim 1.
Claims 17-18, these claims are rejected for similar reasons as in claims 2 and 4.
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 of this title, 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 7, 14, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Smith (US 20240241944) in view of Tarkhanyan (US 20220094690).
Claim 7, Smith discloses The computer program product of claim 1, wherein the operations further comprise: receiving control elements from users; including the control elements in the control program (e.g. ¶59-60, 62, 68, 76, 121)
Although Smith discloses control elements and including the control elements in the control program to execute (see above), Smith does not appear to explicitly disclose but Tarkhanyan discloses receiving encrypted control elements from users; including the encrypted control elements in the control program; and decrypting a control element in the control program to execute using a decryption key. (e.g. ¶37, 50-52, 55)
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the features described by Tarkhanyan into the invention of Smith for the purpose of keeping the security requirements confidential (Tarkhanyan, ¶52).
Claims 14 and 19, these claims are rejected for similar reasons as in claim 7.
Claims 8, 15, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Smith (US 20240241944) in view of Schiff (WO 2022050930).
Claim 8, Smith discloses The computer program product of claim 1 (see above) and does not appear to explicitly disclose but Schiff discloses wherein the operations further comprise: generating an attestation record in response to executing the command for the control element including a result of verifying compliance of the element in the workload and an identifier of the control element having the executed command; and providing the attestation record to the user that provided the control element. (e.g. ¶68, 99, 101-102, 104)
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the features described by Schiff into the invention of Smith for the purpose of enabling the user to perform verification that the policy was enforced (Schiff, ¶99, 102).
Claims 15 and 20, these claims are rejected for similar reasons as in claim 8.
Allowable Subject Matter
Claim 9 would be allowable if rewritten (a) in independent form including all of the limitations of the base claim and any intervening claims and (b) to overcome the 112(b) rejection set forth above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Magowan (US 20230068221) discloses trusted execution environment 218 provides isolated and secure execution of a set of containers in a pod sandbox virtual machine corresponding to a service, which is provided by an application owner in a container orchestration environment, based on a set of rules contained in a trusted execution environment contract that corresponds to a pod deployment description for the set of containers…The secure agent enforces the trusted execution environment contract within the trusted execution environment by validating or verifying any external orchestration request from the container runtime, container orchestration environment administrator, or any other source outside the trusted execution environment against rules included in the trusted execution environment contract. It should be noted that the orchestration request can include a sequence of commands to deploy or start an application workload. The secure agent refuses any orchestration request to be performed that is not permitted by a rule in the trusted execution environment contract… all or certain portions of the trusted execution environment contract can be encrypted…The secure agent within the trusted execution environment is capable of decrypting the trusted execution environment contract using the private key and enforcing the trusted execution environment contract within a boundary of the trusted execution environment…The trusted execution environment contract can include, for example, at least one of signatures corresponding to containers, restrictions on containers, secrets, cryptographic keys, or the like…The restrictions on the containers define which containers in the set of containers can gain access to at least one of configuration maps, secrets, or persistent volume claims, which describe how a container consumes a persistent volume.
Mencias (US 20230128099) discloses a computer implemented method for executing an application. The method comprises: executing a bootloader in a trusted execution environment, wherein the executing comprises: decrypting received encrypted secrets using decryption keys of the boot loader, storing the decrypted secrets in a storage accessible by the application, creating a proof record indicating the application, the secrets and the trusted execution environment, storing the proof record in the storage, and deleting the decryption keys. The application may be executed in the trusted execution environment using the decrypted secrets. The proof record may be provided by the application for proving authenticity.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TRONG NGUYEN whose telephone number is (571)270-7312. The examiner can normally be reached on Monday through Thursday 9:00 AM - 5:00 PM EST.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, GELAGAY SHEWAYE can be reached on (571)272-4219. 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 the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/TRONG H NGUYEN/Primary Examiner, Art Unit 2436