CTNF 19/019,442 CTNF 86906 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. DETAILED ACTION This is in response to Application #19/019,442 filed on 01/13/2025 in which Claims 1-5 are presented for examination. 12-151 AIA 26-51 12-51 Status of Claims Claims 1-5 are pending, of which Claims 1-3, 5 are rejected under 35 U.S.C. 103, dependent Claim(s) 4, is/are objected to as being allowable as a whole over prior art if rewritten in independent form including all of the limitations of its/their base independent claim and any intervening dependent claims. Applicant’s Most Recent Claim Set of 01/13/2025 Applicant’s most recent claim set of 01/13/2025 is considered to be the latest claim set under consideration by the examiner. Claim Objections Regarding Claim 1, this claim is objected to for an apparent missing punctuation typographical error, with a colon missing at the end of Line 5. This claim recites the phrase “ which, upon execution by the processing unit, are configured to cause the processing unit to ” in Line(s) 5. This phrase is construed to read as “ which, upon execution by the processing unit, are configured to cause the processing unit to : ” in Claim 1 Line 5. Regarding Claim 1, this claim is objected to for lack of antecedent basis. This claim recites the apparent acronym “ TEE ” in Line(s) 9, 11. This “ TEE ” is not defined in Claim 1, or any potential parent claims to Claim 1. Regarding Claim 4, this claim is objected to for lack of antecedent basis. This claim recites the apparent acronym “ TEE ” in Line(s) 4. This “ TEE ” is not defined in Claim 4, or any potential parent claims to Claim 4. Regarding Claim 5, this claim is objected to for lack of antecedent basis. This claim recites the apparent acronym “ TEE ” in Line(s) 6. This “ TEE ” is not defined in Claim 5, or any potential parent claims to Claim 5. Appropriate correction is required. Prior Art Rejections - 35 USC § 102 and/or 35 USC § 103 07-06 AIA 15-10-15 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. Claim Rejections - 35 USC § 103 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 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. 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-3, are rejected under 35 U.S.C. 103 as being unpatentable over Behm et al US Patent #10,298,404 in view of RAMANATRAN et al US Patent Application Publication #2022/0014551 . Regarding Claim 1, Behm et al discloses: A first Transport Layer Security, TLS, endpoint device, the first TLS endpoint device comprising: a processing unit; a memory coupled to the processing unit and configured to store executable instructions which, upon execution by the processing unit, are configured to cause the processing unit to [(Behm et al. Col 2 Lines 41-45; Col 25 Lines 26-38) where Behm et al teaches that the Transport Layer Security (TLS) endpoint devices utilized in Behm et al including TLS client endpoint devices and TLS server endpoint devices have processor units with memory coupled to them which execute instructions to implement the software portions of Behm et al] receive, within a TLS handshake message exchange with a second TLS endpoint, attestation data, and an instance-specific public key; verify the attestation data [(Behm et al. Col 18 Lines 36-41, 60-65) where Behm et al teaches the exchanging of a TLS handshake message between two endpoints with attestation data of a fingerprint of a certificate and with instance specific information of a public key of the certificate which are utilized in client verification or authentication] ; receive a signature, the signature signed by an instance-specific private key corresponding to the instance-specific public key; and verify the signature using the instance-specific public key [(Behm et al. Col 19 Lines 35-39, 44-46) where Behm et al teaches the receipt or obtaining of a digitally signed signature of a request using the private portion of the cryptographic key pair (since one signs with the private key and verifies the resulting signature with the public key of a cryptographic key pair utilized in digital signing) containing the public portion of the instance specific public key utilized in establishing the encrypted communications session via the client- authenticated TLS handshake which is verified by the server to which it is transmitted by authenticating that the signed request matches the encrypted communications session to which it belongs]. Behm et al does not appear to explicitly disclose: that the digital signature is a TEE signature However, RAMANATRAN et al discloses: that the digital signature is a TEE signature [(RAMANATRAN et al Par 77 Lines 1-9) where RAMANATRAN et al teaches utilizing a Trusted Execution Environment to create a trusted TEE signature]. Behm et al and RAMANATRAN et al are analogous art because they are from the “same field of endeavor” and are from the same “problem-solving area”. Namely, they are both from the field of “information security”. 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 Behm et al and the teachings of RAMANATRAN et al by providing a Trusted Execution Environment to create a trusted TEE signature as taught by RAMANATRAN et al in the teaching described by Behm et al. The motivation for doing so would be to increase the usability and flexibility of Behm et al by providing a Trusted Execution Environment to create a trusted TEE signature as taught by RAMANATRAN et al in the teaching described by Behm et al so as to provide a trusted TEE signature that meets required standards of trust in a particular system. Regarding Claim 2, most of the limitations of this claim have been noted in the rejection of Claim 1. Applicant is directed to the rejection of Claim 1 above. In addition, the combination of Behm et al and RAMANATRAN et al discloses: The first TLS endpoint device of claim 1, wherein the memory is configured to store executable instructions which, upon execution by the processing unit, are configured to cause the processing unit to: generate a TLS ClientHello message, the ClientHello message including an indication that the first TLS endpoint device wants to receive the TLS Certificate message that includes the attestation data [(Behm et al Col 12 Lines 59-67; Col 13 Lines 1-10) where Behm et al teaches transmitting a TLS ClientHello message as part of the process to initiate a TLS handshake and receiving back a TLS server certificate message including attestation or authentication data] . Regarding Claim 3, most of the limitations of this claim have been noted in the rejection of Claim 1. Applicant is directed to the rejection of Claim 1 above. In addition, the combination of Behm et al and RAMANATRAN et al discloses: The first TLS endpoint device of claim 1, wherein the memory is configured to store executable instructions which, upon execution by the processing unit, are configured to cause the processing unit to: send the attestation data to an attestation endpoint in a network domain of the second TLS endpoint; and in response, receive verification of the attestation data [(Behm et Col 12 Lines 59-67; Col 13 Lines 1-10, 32-28) where Behm et al teaches a TLS server certificate message including attestation or authentication data being sent by a sender endpoint to a recipient endpoint as part of the process to initiate a TLS handshake between the sender endpoint and the recipient endpoint with the receipt of successful establishment of a TLS communications session between the sender endpoint and the recipient endpoint indicating to the sender that the recipient endpoint has successfully verified the attestation or authentication data by agreeing to the establishment of the TLS communications session] . 07-21-aia AIA Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Behm et al US Patent #10,298,404 in view of RAMANATRAN et al US Patent Application Publication #2022/0014551 and further in view of Ueno et al US Patent Application Publication #2010/0250951 . Regarding Claim 5: the combination of Behm et al and RAMANATRAN et al discloses: The first TLS endpoint device of claim 1, wherein the memory is configured to store executable instructions which, upon execution by the processing unit, are configured to cause the processing unit to: that the digital signature is a TEE signature [(RAMANATRAN et al Par 77 Lines 1-9) where RAMANATRAN et al teaches utilizing a Trusted Execution Environment to create a trusted TEE signature]. The combination of Behm et al and RAMANATRAN et al does not appear to explicitly disclose: generate a transcript hash from a transcript of preceding messages of the TLS handshake message exchange; verify the signature based on the transcript hash However, Ueno et al discloses: generate a transcript hash from a transcript of preceding messages of the TLS handshake message exchange; verify the signature based on the transcript hash [(Ueno et al Par 153 Lines 1-14; Par 154 Lines 24-32) where Ueno et al teaches that a signature is generated based on a hash of previously exchanged TLS handshake messages, with the generated signature later verified against the hash of the previously exchanged TLS handshake messages] . Behm et al and RAMANATRAN et al, and Ueno et al are analogous art because they are from the “same field of endeavor” and are from the same “problem-solving area,”. Namely, they are both from the field of “information security”. 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 Behm et al and RAMANATRAN et al and the teachings of Ueno et al by providing a signature that is generated based on a hash of previously exchanged TLS handshake messages, with the generated signature later verified against the hash of the previously exchanged TLS handshake messages as taught by Ueno et al in the teaching described by Behm et al and RAMANATRAN et al. The motivation for doing so would be to increase the usability and flexibility of Behm et al and RAMANATRAN et al, and Ueno et al by providing a signature that is generated based on a hash of previously exchanged TLS handshake messages, with the generated signature later verified against the hash of the previously exchanged TLS handshake messages as taught by Ueno et al in the teaching described by Behm et al and RAMANATRAN et al so as provide an additional layer of complexity in the generation and later verification of a signature generated based on previously generated TLS handshake messages that are exchanged between two endpoints during a TLS handshake procedure. Allowable Subject Matter – Dependent Claim(s) Claim(s) 4 is/are objected to as being dependent upon a rejected base claim, but would be allowable as a whole over prior art if rewritten in independent form including all of the limitations of its/their base independent claim, and any intervening dependent claims . 13-03-01 The following is a statement of reasons for the indication of allowable subject matter. The closest prior art, as recited, Behm et al US Patent #10,298,404 and RAMANATRAN et al US Patent Application Publication #2022/0014551, are also generally directed to various aspects of providing improvement of the security of cryptographically secure network connections utilizing the Transport Layer Security Protocol in conjunction with a Trusted Execution Environment. However, Behm et al or RAMANATRAN et al does not teach or suggest, either singularly or in combination, the particular combination of steps or elements as recited in the dependent Claim(s) 4 when also incorporating all of the limitations of its/their base independent claim and any intervening dependent claims. For example, none of the cited prior art teaches or suggests the steps of: receive, within the TLS handshake message exchange, a TEE certificate including the attestation data. As recited in dependent Claim(s) 4, when also incorporating all of the limitations of its/their base independent claim, any intervening dependent claims, and any additional limitations found in dependent Claim(s) 4. Conclusion 07-96 AIA The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Moyer et al - US_20230013347: where Moyer et al teaches Transport Layer Security with remote attestation. Sharaga et al - US_20160182499: where Sharaga et al teaches the establishment of trust between a Trusted Execution Environment and peripheral devices . Any inquiry concerning this communication or earlier communications from the examiner should be directed to BRADLEY HOLDER whose telephone number is 571-270-3789. The examiner can normally be reached on Monday-Friday 10:00AM-7:00PM Eastern Time. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Linglan Edwards, can be reached on (571) 270-5440. 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. /BRADLEY W HOLDER/ Primary Examiner, Art Unit 2408 Application/Control Number: 19/019,442 Page 2 Art Unit: 2408 Application/Control Number: 19/019,442 Page 3 Art Unit: 2408 Application/Control Number: 19/019,442 Page 4 Art Unit: 2408 Application/Control Number: 19/019,442 Page 5 Art Unit: 2408 Application/Control Number: 19/019,442 Page 6 Art Unit: 2408 Application/Control Number: 19/019,442 Page 7 Art Unit: 2408 Application/Control Number: 19/019,442 Page 8 Art Unit: 2408 Application/Control Number: 19/019,442 Page 9 Art Unit: 2408 Application/Control Number: 19/019,442 Page 10 Art Unit: 2408 Application/Control Number: 19/019,442 Page 11 Art Unit: 2408 Application/Control Number: 19/019,442 Page 12 Art Unit: 2408 Application/Control Number: 19/019,442 Page 13 Art Unit: 2408
Prosecution Insights