CTNF 18/361,964 CTNF 90978 DETAILED ACTION Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia 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 Application This office action is in response to the Application filed on 07/31/2023. Claims 1-20 are presented for examination. Drawings The drawings submitted on 07/31/2023 are accepted. Claim Rejections - 35 USC § 112 07-30-02 AIA 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. 07-34-01 AIA Claim s 1, 11 and 20 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. Claims 1 and 11 recite a “remote attestation caching server” , then says the communication comprises providing requests to the “remote attestation server” , and later says result is provided after communication with the “remote attestation server.” It is unclear whether “remote attestation server” and “remote attestation caching server” are the same. Claim 20 is directed to A non-transitory, computer-readable medium comprising a program code…, yet claim 20 depend on claim 11 , which is directed to a method . Dependency of a claim on another claim of a different statutory class renders the claim scope unclear. See MPEP 2173.05(p) . Because claim 20 is A non-transitory, computer-readable medium and claim 11 is a method claim, the dependency creates uncertainty regarding claim scope. Claim Rejections - 35 USC § 103 07-06 AIA 15-10-15 In the event a determination of the status of the application as subject to AIA 35 U.S.C. 102, 103, and 112 (or as subject to pre-AIA 35 U.S.C. 102, 103, and 112) is incorrect, any correction of the statutory basis for a rejection will not be considered a new ground of rejection if the prior art relied upon and/or the rationale supporting the rejection, would be the same under either status. 07-20-aia AIA 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. 07-23-aia AIA The factual inquiries set forth in Graham v. John Deere Co. , 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows: 1. Determining the scope and contents of the prior art. 2. Ascertaining the differences between the prior art and the claims at issue. 3. Resolving the level of ordinary skill in the pertinent art. 4. Considering objective evidence present in the application indicating obviousness or nonobviousness. 07-20-02-aia AIA This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention. 07-21-aia AIA Claim s 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Scarlata et al. ( US 2018/0183580; hereinafter Scarlata’580 ) in view of Scarlata et al. (NPL “Supporting Third Party Attestation for Intel® SGX with Intel® Data Center Attestation Primitives”; hereinafter 2018 DCAP Whitepaper ) and further in view of PCCS (NPL “Design Guide for Intel® SGX Provisioning Certificate Caching Service (Intel® SGX PCCS)” Rev 0.6 (October 2020); hereinafter 2020 PCCS Design Guide ) . Regarding independent claims 1, 11 and 20 , taking claim 1 as exemplary analysis, Scarlata’580 teaches An apparatus for a computer system, the apparatus comprising interface circuitry, machine-readable instructions, and a processor to execute the machine-readable instructions ( [0074], apparatus, a system, a machine readable storage, a machine readable medium, hardware-and/or software-based logic (e.g., memory buffer logic), and method ) to: obtain a request to perform remote attestation for a trusted execution environment from an application running in the trusted execution environment of the processor ( Scarlata’580 , [0014], The attestation system 105 can receive data, or “quotes,” generated by secured logical components, or enclaves, running on host systems (e.g., 110, 115, 120, 125) to attest to the authenticity and security (and other characteristics) of another application or enclave of the host and confirm the attestation based on the received quote; [0042]–[0045], “the migration enclave may send quote data ... to a virtual machine registration service” Fig.3-4, wherein Application Enclave 240” interacting with Quoting Enclave 245 to generate Attestation (Quote)) Scarlata’580 teaches multi-step remote service interactions and certificate handling for VM enclaves ([0024]–[0027] describing code executed on a machine with secure enclaves; [0035]–[0040] quoting enclave and migration enclave components executed by the processor The apparatus obtains a request to perform remote attestation for a trusted execution environment from code/applications running inside the TEE: the quoting/migration enclave performs attestation of the VM/enclave in response to launch or migration events triggered by in-VM code. [0042]–[0045] “the migration enclave may send quote data ... to a virtual machine registration service”), but Scarlata’580 does not teach a remote attestation caching server, the use of a plurality of requests/responses specifically for fetching cached attestation collateral, no fixed binding/arbitrary number of interchangeable servers, explicit certificate chain download from a caching server, or the entire flow encapsulated in a single contiguous function/driver/library. 2018 DCAP Whitepaper teaches communication with an intermediary service for third-party attestation (“CSPs may choose to continue to use the previous Attestation Keys until all platforms are upgraded and all certificates are downloaded and provided to the CSP Attestation Service” (Section 5); “application receives an attestation request… application requests that its enclave produce an attestation” (section 2)) 2020 PCCS Design Guide teaches the remote attestation caching server and the plurality of requests/plurality of responses for collateral, with the final result returned to the caller: (“The proposed architecture centers around a caching service that maintains the Intel® SGX attestation collateral … and provides that collateral to quote-generating servers” (Section 2, Overview); “multiple sequential requests (PCK cert ID → certificate chain → TCB info → CRLs)” (Section 3.1 and Figure 1). It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention was made, to modify the multi-step attestation/provisioning flow of Scarlata’580 to use the 2020 PCCS Design Guide caching server and the multi-request collateral fetching pattern taught by the 2018 DCAP Whitepaper because both are from the same SGX ecosystem: 2018 DCAP Whitepaper explicitly extends Scarlata-era attestation architecture to distributed deployments and third-party-managed infrastructure. A person of ordinary skill in the art would be motivated to have done so to enable scalable third-party attestation in data centers, as explicitly motivated in the 2018 DCAP Whitepaper (to support “third party attestation” without per-request Internet dependency on Intel services) and to reduce latency, improve scalability, and eliminate reliance on centralized services, leading to caching-based attestation servers and multiple request/response interactions. Thus, the combination teaches communicate with at least one remote attestation caching server based on the request to perform remote attestation, wherein the communication with the remote attestation caching server comprises providing a plurality of requests to the remote attestation server and obtaining a plurality of responses from the remote attestation caching server; The combination further teaches provide a result of the remote attestation request to the application running in the trusted execution environment after having completed the communication with the remote attestation server (Scarlata’580 , Fig. 1; Fig. 4 shows Attestation Service 105, Provisioning Service 135, and VM Registration Service 130 connected via network; Fig. 4 shows multiple interactions: retrieval of Attestation Key Certs 415 retrieval of VM Certs 410; 2018 DCAP Whitepaper , p.1, “allow 3rd parties to build and manage their own… attestation infrastructure”; “when an application receives an attestation request from an off-platform challenger (1), the application requests that its enclave produce an attestation (2)” (Section 2). 2020 PCCS Design Guide, “The proposed architecture centers around a caching service that maintains the Intel® SGX attestation collateral … and provides that collateral to quote-generating servers” (Section 2, Overview); “multiple sequential requests (PCK cert ID → certificate chain → TCB info → CRLs)” (Section 3.1 and Figure 1 ). Regarding claim(s) 2 and 12 , the combination further teaches communicate with one of a plurality of remote attestation caching servers ( Scarlata’580 teaches multiple remote services (Fig. 1, Fig. 4); multiple services/hosts in VM migration ([0046]–[0050]); 2018 DCAP Whitepaper teaches distributed infrastructure across multiple entities: “CSPs may choose to continue to use the previous Attestation Keys until all platforms are upgraded...” (Section 5). The 2020 PCCS Design Guide allows multiple PCCS instances (Section 2.1: “configurable hosts and flexible infrastructure”). It would have been obvious to communicate with one of a plurality of attestation servers) . Regarding claim(s) 3 and 13 , the combination further teaches use an arbitrary number of remote attestation caching servers during the communication (The 2020 PCCS Design Guide supports an arbitrary number of PCCS instances for data-center scalability: “The proposed architecture centers around a caching service...” (Section 2.1 and configuration options). Combined with the scalable CSP model in the 2018 DCAP Whitepaper and the VM deployment flexibility in Scarlata’580, use of an arbitrary number of caching servers is obvious) . Regarding claim(s) 4 and 14 , the combination further teaches communicate with the at least one remote attestation caching server without a binding between the communication performed on behalf of the application and a remote attestation caching server (The 2018 DCAP Whitepaper and 2020 PCCS Design Guide use configurable URLs with no fixed binding: “any valid PCCS instance works interchangeably” (2020 PCCS Design Guide, Section 6). Scarlata’580 uses interchangeable remote services without hard-coded dependency ([0046]–[0050]; 2018 DCAP Whitepaper teaches independent third-party infrastructure (no centralized binding). It would have been obvious that communication is not bound to a specific server (stateless service design)) . Regarding claim(s) 5 and 15 , the combination further teaches wherein the request for remote attestation comprises an identifier of a trusted computing platform of the computer system, wherein the processor is to include the identifier of the trusted computing platform in each of the plurality of requests ( The 2018 DCAP Whitepaper requires platform identifiers in PCK requests: “PPID, PCEID, FMSPC, CPUSVN, etc.” (Section 4.2.1). The 2020 PCCS Design Guide mandates these identifiers in each collateral request: “encrypted_ppid, cpusvn, pceid, qeid, fmspc” (Section 3.1). Scarlata’580 teaches signed quote data containing platform/TEE identifiers sent to services ([0043]–[0045]). Scarlata teaches platform-specific attestation data: Attestation keys, VM root keys, control structures (Fig. 4), tied to platform identity and included in requests. It would have been obvious to include the identifier in each request) . Regarding claim(s) 6 and 16 , the combination further teaches perform the acts of obtaining the request, communicating with the at least one remote attestation caching server and providing the result of the remote attestation within a single session or a single contiguous function ( The 2018 DCAP Whitepaper describes the attestation flow as a logical sequence. The 2020 PCCS Design Guide implements the full flow in single high-level QPL calls: “the Quote Provider Library (QPL) ... performs multiple sequential requests ... and returns the completed quote” (Section 2, Figure 1). Scarlata’580 teaches the flow as a contiguous sequence during VM launch/migration ([0042]–[0053]; Scarlata shows integrated attestation flow within system architecture (Fig. 4), performing steps within a single execution flow/session is an obvious implementation detail) . Regarding claim(s) 7 and 17 , the combination further teaches obtaining the request, communicating with the at least one remote attestation caching server and providing the result of the remote attestation as part of a driver ( The 2018 DCAP Whitepaper references platform software/drivers for quoting enclaves. The 2020 PCCS Design Guide integrates with SGX drivers via QPL. Scarlata’580 operates in conjunction with SGX platform drivers for enclaves and quoting. Scarlata discloses software stack components (enclaves, services), Implementing as: driver or software library, is a routine design choice) . Regarding claim(s) 8 and 18 , the combination further teaches obtaining the request, communicating with the at least one remote attestation caching server and providing the result of the remote attestation as part of a software library (The 2018 DCAP Whitepaper and 2020 PCCS Design Guide teach implementation as part of the QPL software library: “reference code” (2018 DCAP Whitepaper, Section 6) and explicit QPL (2020 PCCS Design Guide). Scarlata’580 discloses software stack components (enclaves, services), Implementing as: driver or software library, is a routine design choice) . Regarding claim(s) 9 and 19 , the combination further teaches download a certificate chain from the remote attestation caching server as part of the communication, and to prepare the result based on the certificate chain (The 2018 DCAP Whitepaper discusses downloading PCK certificates and chains (Section 3.1 and 4.2.1). The 2020 PCCS Design Guide teaches explicit download of the certificate chain from the caching server: “response header sgx-pck-certificate-issuer-chain (URL-encoded PEM)” (Section 3.1). Scarlata’580 teaches certificate generation and use for validation: “the registration service may generate a certificate for the root key” ([0048]–[0050]). Scarlata explicitly teaches certificate retrieval: “Attestation Key Certs 415” “VM Certs 410”, corresponds to downloading a certificate chain) . Regarding claim(s) 10 , the combination of further teaches wherein the certificate chain attests that the trusted execution environment of the processor is capable of performing confidential computations ( The 2018 DCAP Whitepaper states that PCK certificate chains attest platform trustworthiness: “complete signature chain from the Quotes to an Intel CA” (Section 3.1). DCAP, “demonstrating that the enclave has been established in a secure hardware environment”, corresponds to attesting capability for confidential computation; The 2020 PCCS Design Guide confirms the chains attest genuine SGX platforms capable of confidential computing (Sections 3.1 and 3.3). Scarlata’580 teaches that the certificate and validation attest the enclave/VM is capable of secure/confidential computations: “attestation establishes trustworthiness for confidential VM operations” ([0052]–[0053]) . Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to TRACY C CHAN whose telephone number is (571)272-9992. The examiner can normally be reached on Monday - Friday 10 AM to 6 PM EST. 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, TIM VO can be reached on (571)272-3642. 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 https://ppair-my.uspto.gov/pair/PrivatePair. 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. /TRACY C CHAN/ Primary Examiner, Art Unit 2138 Application/Control Number: 18/361,964 Page 2 Art Unit: 2138 Application/Control Number: 18/361,964 Page 3 Art Unit: 2138 Application/Control Number: 18/361,964 Page 4 Art Unit: 2138 Application/Control Number: 18/361,964 Page 5 Art Unit: 2138 Application/Control Number: 18/361,964 Page 6 Art Unit: 2138 Application/Control Number: 18/361,964 Page 7 Art Unit: 2138 Application/Control Number: 18/361,964 Page 8 Art Unit: 2138 Application/Control Number: 18/361,964 Page 9 Art Unit: 2138 Application/Control Number: 18/361,964 Page 10 Art Unit: 2138 Application/Control Number: 18/361,964 Page 11 Art Unit: 2138 Application/Control Number: 18/361,964 Page 12 Art Unit: 2138
Prosecution Insights