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 .
This action Is in response to the claims filed 11/13/2025. Claims 1-16, 23-25, and 27-32 are pending. Claims 1 (a machine), 9 (a non-transitory CRM), and 23 (a method) are independent.
Effective filing date: 9/30/2020
Applicant’s claim for the benefit of a prior-filed application under 35 U.S.C. 119(e) or under 35 U.S.C. 120, 121, 365(c), or 386(c) is acknowledged. Applicant has not complied with one or more conditions for receiving the benefit of an earlier filing date under 35 U.S.C. 119(e) as follows:
The later-filed application must be an application for a patent for an invention which is also disclosed in the prior application (the parent or original nonprovisional application or provisional application). The disclosure of the invention in the parent application and in the later-filed application must be sufficient to comply with the requirements of 35 U.S.C. 112(a) or the first paragraph of pre-AIA 35 U.S.C. 112, except for the best mode requirement. See Transco Products, Inc. v. Performance Contracting, Inc., 38 F.3d 551, 32 USPQ2d 1077 (Fed. Cir. 1994).
The disclosure of the prior-filed application, Application No. 62/908,386, fails to provide adequate support or enablement in the manner provided by 35 U.S.C. 112(a) or pre-AIA 35 U.S.C. 112, first paragraph for one or more claims of this application. For example, at least the ‘token’ and ‘telemetry’/’attestation’ interfaces are not disclosed in ‘386.
Therefore, the effective filing date of the pending claims is 9/30/2020, the filing of PCT/US20/53649.
Response to Arguments
Applicant’s arguments, see page 9, filed 11/13/2025, with respect to the rejection(s) of claim(s) 1-16, 23-25, and 27-32 under Knauth – Integrating Remote Attestation with Transport Layer Security in view of Blanke, US 2016/0219043 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 Knauth in view of Smith, US 2019/0138294.
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, 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-16, 23-25, and 27-28 is/are rejected under 35 U.S.C. 103 as being unpatentable over Knauth – Integrating Remote Attestation with Transport Layer Security (published 2018), in view of Smith, US 2019/0138294 (published 2019-05).
As to claims 1, 9, and 23, Knauth discloses a machine/CRM/method comprising:
interface circuitry;
machine-readable instructions; and
at least one programmable circuitry to be programmed by the machine-readable instructions to: (“Intel SGX is a recent (2015) Intel processor extension available since the 6th Gen Intel® Core™ processors. Intel SGX enables application developers to construct trusted execution environments – called enclaves – to perform computation on commodity CPUs while maintaining previously untenable security protections.” Knauth §1)
(See Applicant’s Figure 7 and Knauth Figure 1)
access evidence indicative of an authenticity of a first object, (“application computes a hash of the manifest and includes this hash” Knauth § 2.1. Figure 7 steps (2) and (3))
the first object having an object interface to access the first object; (object interface is Knauth Figure 1, steps (1) and (6). See Applicant’s ¶¶ 87 and 93, describing the “object interface” as an interface for accessing the system by an external entity, such as an HTTPS/TLS tunnel over a network))
access telemetry data associated with the first object via a telemetry interface associated with the first object; (telemetry interface is Knauth Figure 1, steps (2) and (3):
“The application creates a manifest that includes a response to the challenge as well as an ephemeral key to encrypt future communication with the challenger (Steps 2 and 3). The application computes a hash of the manifest and includes this hash as user-defined data when creating the report. Including a hash of the manifest into the report is crucial, as this binds the secret key to this enclave. Binding the key to the specific enclave instance is crucial to avoid masquerading attacks [6] [1] [7]. Next, the enclave generates a report that summarizes the enclave and platform state. The report includes information on the platform (security version number), enclave attributes, enclave measurement, software version, software vendor security version number, and additional user-provided data [8].” Knauth § 2.1)
associate the evidence (“application computes a hash of the manifest and includes this hash” Knauth § 2.1) with the telemetry data; and (“generates a report that summarizes the enclave and platform state. The report includes information on the platform (security version number), enclave attributes, enclave measurement, software version, software vendor security version number, and additional user-provided data [8].” Knauth § 2.1)
send an attestation request to (“send the quote to IAS to receive an attestation verification report. These steps must be performed at startup” Knauth § 4.1. Illustrated in Figure 3)
receive a token from the (“to receive an attestation verification report. These steps must be performed at startup” Knauth § 4.1. Illustrated in Figure 3)
cause, in response to receipt of the token, an attestation interface corresponding to the first object (telemetry interface is Knauth Figure 1, steps (4) and (5)) to enable access to the evidence by external objects and systems, (“The signed report, now called a quote, is returned to the application (Step 5) which passes it on to the challenger (Step 6). The Intel Attestation Service (IAS) verifies the quote (Step 7).” Knauth § 2.1. the quoting enclave being required to produce the quote.)
wherein the object interface, the telemetry interface and the attestation interface are separate interfaces (as cited above).
Knauth does not disclose:
A multi-access edge computing (MEC) platform.
Smith discloses:
interface circuitry; (see Smith Fig. 12 and respective communications to/from the communicator and device 1230/1235)
machine-readable instructions; and (Smith Fig. 6, 682)
at least one programmable circuitry to be programmed by the machine-readable instructions to: (Smith Fig. 6, 688)
access evidence indicative of an authenticity of a first object, the first object having an object interface to access the first object; (“Rebooting the new update image (which causes a new cryptographic identity to be formed); and countersign the pre-signed image using the new key (KeyB) (e.g., sigB=[sigA]KeyB).” Smith ¶ 106, the attestation of device 1235)
access telemetry data associated with the first object via a telemetry interface associated with the first object; (the same data as above, e.g. Smith ¶ 106, or the update manifest of communication (4) in Fig. 12 “The orchestrator 1205 contains re-attestation functionality, including a Reference Integrity Measurement (RIM) Generator that accepts as input a software update manifest and produces a RIM manifest.” Smith ¶ 102.)
associate the evidence with the telemetry data; (associated by being computed based on each other: “The verifier 1220 checks the signatures and verifies the image hash matches the expected hash contained in the RIM. If they match, the verifier 1220 issues a new cryptographic identity for the Device 1235 (e.g. issues a certificate containing public KeyB as the identity).” Smith ¶ 107
send an attestation request to a multi-access edge computing (MEC) platform based on the association; (MEC, see Smith ¶¶ 4-6. “the edge device may operate in a MEC network according to ETSI MEC standards. The software update package manifest may be transmitted from a device communicator 1230 to the orchestrator communicator 1210 to an orchestrator communicator 1210.” Smith ¶ 112. “The verifier 1220 may initiate an attestation request with the edge device. The verifier may verify the edge device based on the at least one integrity measurement and the result (e.g., a response received with valid attestation information, etc.) of the attestation request.” Smith ¶ 115. The response with attestation information, e.g. Smith ¶ 106, is the claimed ‘attestation request’.)
receive a token from the MEC platform and (“the attestation record may be a token issued to the edge device by the token server 1225 based on the verification.” Smith ¶ 117)
cause, in response to receipt of the token, an attestation interface corresponding to the first object to enable access (“peer devices that have registered for active indication of re-attestation are informed before software update proceeds in step 4f; and, if step 4f is successful, then the remaining steps 5-11 shown in FIG. 12 continue. If step 4f is not successful, the software update is retracted…. If attestation token verification succeeds, the peer device knows it is safe to request services or exchange data with the device.” Smith ¶ 118. See also Smith ¶ 32, 41, 47, data exchange) to the evidence by external objects and systems, wherein the object interface, the telemetry interface and the attestation interface are separate interfaces. (the various software routines of Smith that perform the cited actions).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Knauth with Smith by incorporating the attestation interfaces of Knauth into a MEC platform. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Knauth with Smith in order to provide dynamic content and computing capabilities at a network edge for low latency high bandwidth radio network information technology, Smith, ¶¶ 4-6, while ensuring that updates to network elements are trusted, Smith ¶ 28.
As to claims 2, 10, and 24, Knauth discloses the machine/CRM/method of claims 1, 9, and 23 and further discloses:
wherein one or more of the at least one processor circuit (“Intel SGX is a recent (2015) Intel processor extension available since the 6th Gen Intel® Core™ processors. Intel SGX enables application developers to construct trusted execution environments – called enclaves – to perform computation on commodity CPUs while maintaining previously untenable security protections.” Knauth § 1) is to generate a telemetry information object, and wherein the telemetry data is the telemetry information object. (“Next, the enclave generates a report that summarizes the enclave and platform state. The report includes information on the platform (security version number), enclave attributes, enclave measurement, software version, software vendor security version number, and additional user-provided data [8].” Knauth § 2.1)
As to claims 3, 11, Knauth discloses the machine/CRM/method of claims 1, 9, and 23 and further discloses:
wherein the first object is a subsystem of a computing device. (“Intel SGX is a recent (2015) Intel processor extension available since the 6th Gen Intel® Core™ processors. Intel SGX enables application developers to construct trusted execution environments – called enclaves – to perform computation on commodity CPUs while maintaining previously untenable security protections.” Knauth § 1. “Next, the enclave generates a report that summarizes the enclave and platform state. The report includes information on the platform (security version number), enclave attributes, enclave measurement, software version, software vendor security version number, and additional user-provided data [8].” Knauth § 2.1)
As to claims 4, 12, Knauth discloses the machine/CRM/method of claims 1, 9, and 23 and further discloses:
wherein one or more of the at least one processor circuit is to store trusted information for the apparatus.
(“Intel SGX is a recent (2015) Intel processor extension available since the 6th Gen Intel® Core™ processors. Intel SGX enables application developers to construct trusted execution environments – called enclaves – to perform computation on commodity CPUs while maintaining previously untenable security protections.” Knauth § 1. E.g. “Including a hash of the manifest into the report is crucial, as this binds the secret key to this enclave.” Knauth § 2.1)
As to claims 5, 13, Knauth discloses the machine/CRM/method of claims 1, 9, and 23 and further discloses:
wherein one or more of the at least one processor circuit is to sign the evidence using a key retrieved from a root of trust. (“The Attestation Report Signing CA Certificate is self-signed and trusted…. since we propose to use Intel SGX as a trust root, we can simply self-sign” § 3.2)
As to claims 6 and 14, Knauth in view of Smith discloses the machine/CRM/method of claims 1, 9, and 23 and further discloses:
wherein the object is an edge node in a multi-access edge computing platform. (MEC, see Smith ¶¶ 4-6. “the edge device may operate in a MEC network according to ETSI MEC standards. The software update package manifest may be transmitted from a device communicator 1230 to the orchestrator communicator 1210 to an orchestrator communicator 1210.” Smith ¶ 112.)
As to claims 7, 15, and 25, Knauth discloses the machine/CRM/method of claims 1, 9, and 23 and further discloses:
wherein the interface circuitry (Intel SGX) is to receive a request for an attestation information object from a second object. (“The assessing party is called challenger while the assessed party is the attester. Based on the attestation, the challenger can decide whether to trust the platform by comparing the attester’s state to a reference value.” Knauth § 2.1).
As to claims 8, 16, Knauth discloses the machine/CRM/method of claims 1, 9, and 23 and further discloses:
wherein the second object is to verify the attestation information to attest the authenticity of the object to a relaying party. (“The Attestation Service will reply with an attestation verification report, confirming or denying the authenticity of the quote and the enclave it originates from [9].” Knauth § 2.1. See Knauth Figure 1. “Later, anybody can use the attestation verification report to independently verify the link between the server’s public key and the server’s Intel SGX identity.” Knauth § 3.1)
As to claims 27, Knauth discloses the machine/CRM/method of claims 1, 9, and 23 and further discloses:
wherein the telemetry data corresponds to resources of a computing device. (“the enclave generates a report that summarizes the enclave and platform state. The report includes information on the platform (security version number), enclave attributes, enclave measurement, software version, software vendor security version number, and additional user-provided data [8].” Knauth § 2.1)
As to claims 28, Knauth discloses the machine/CRM/method of claims 1, 9, and 23 and further discloses:
wherein one or more of the at least one processor circuit is to sign an event of the telemetry data based on the association of the evidence and the telemetry data. (“The signed report, now called a quote, is returned to the application (Step 5) which passes it on to the challenger (Step 6). The Intel Attestation Service (IAS) verifies the quote (Step 7).” Knauth § 2.1.)
Claim(s) 29 and 31, is/are rejected under 35 U.S.C. 103 as being unpatentable over Knauth – Integrating Remote Attestation with Transport Layer Security (published 2018), in view of Smith, US 2019/0138294 (published 2019-05), and Blanke, US 2016/0219043 (filed 2014).
As to claims 29, Knauth in view of Smith discloses the machine/CRM/method of claims 1, 9, and 23 but does not disclose:
wherein the attestation interface is a side band interface that is enabled, and wherein the telemetry interface is disabled by blocking a session of the telemetry interface.
Blanke discloses:
Wherein the attestation interface is a side band interface that is enabled, (“the authentication client 201 initiates an out-of-band secure connection with the relying party 202 (e.g., an out-of-band transaction) and communicates with the relying party 202 using the key provisioning protocol (e.g., the DSKPP protocol mentioned above).” Blanke ¶ 33)
and wherein the telemetry interface is disabled by blocking a session of the telemetry interface. (“Once device registration is complete (as described in FIG. 2), the relying party 201 will accept an authentication response” Blanke ¶ 36.)
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Knauth in view of smith with Blanke by requiring a successful out of band authentication prior to allowing transactions. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Knauth with Blanke in order to perform authentication with remote parties while mitigating man in the middle attacks, Blanke ¶¶ 4-6.
As to claims 31, Knauth in view of Smith discloses the machine/CRM/method of claims 1, 9, and 23 but does not disclose:
wherein the attestation interface is enabled in response to determining a presence of out-of-band attestation assessments corresponding to at least one of the telemetry data or the evidence.
Blanke discloses:
Wherein the attestation interface is enabled in response to determining a presence of out-of-band (“the authentication client 201 initiates an out-of-band secure connection with the relying party 202 (e.g., an out-of-band transaction) and communicates with the relying party 202 using the key provisioning protocol (e.g., the DSKPP protocol mentioned above).” Blanke ¶ 33) attestation assessments corresponding to at least one of the telemetry data or the evidence. (“to initiate the registration process, the relying party 202 generates a randomly generated challenge (e.g., a cryptographic nonce) that must be presented by the authentication client 201 during device registration.” Blanke ¶ 33).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Knauth in view of smith with Blanke by requiring a successful out of band authentication prior to allowing transactions. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Knauth with Blanke in order to perform authentication with remote parties while mitigating man in the middle attacks, Blanke ¶¶ 4-6.
Claim(s) 30, is/are rejected under 35 U.S.C. 103 as being unpatentable over Knauth – Integrating Remote Attestation with Transport Layer Security (published 2018), in view of Smith, US 2019/0138294 (published 2019-05), and Hardjono et al., US 2007/0180495 (published 2007).
As to claims 30, Knauth in view of Smith discloses the machine/CRM/method of claims 1, 9, and 23 and but does not disclose:
wherein the attestation interface is enabled for a monitoring system to sample the attestation interface, the monitoring system to observe a change in trustworthiness of the telemetry data.
Hardjono discloses
wherein the attestation interface is enabled for a monitoring system to sample the attestation interface, the monitoring system to observe a change in trustworthiness of the telemetry data.
(“if routers in network 805 have their integrity/trust scores change (e.g., by changing components), if routers become unavailable, or if the integrity/trust scores have expired (see below with reference to FIG. 11 regarding use-by dates), then other paths might be selected.” Hardjono ¶ 60)
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Knauth in view of Smith with Hardjono by utilizing the trust score change monitoring of Hardjono to judge suitability of a terminal. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Knauth in view of Smith with Hardjono in order judge the suitability of other devices to be communication partners, Hardjono ¶¶ 3-5
Claim(s) 32, is/are rejected under 35 U.S.C. 103 as being unpatentable over Knauth – Integrating Remote Attestation with Transport Layer Security (published 2018), in view of Smith, US 2019/0138294 (published 2019-05), and Sprague et al., US 2015/0089568 (published 2015)
As to claims 32, Knauth in view of Smith discloses the machine/CRM/method of claims 1, 9, and 23 and but does not disclose:
wherein one or more of the at least one programmable circuitry is to assign weighting to the telemetry data based on the evidence.
Sprague discloses: wherein one or more of the at least one programmable circuitry is to assign weighting to the telemetry data based on the evidence.
(“the process 150 preferably determines a handful of identifiers, which are used at 222 to compute an aggregated weighting score to establish the trust level for device 150. Each one of the additional context verification tests/factors has a respective ranking and weight, which correspond to a measure of trust associated with that test/factor.” Sprague ¶ 87)
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Knauth in view of Smith with Sprague by utilizing weights in a trust calculation for the authentication/attestation mechanism of Knauth in view of Smith. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Knauth in view of Smith with Sprague in order to multi-factor authentication that balances ease of use with security, Sprague ¶¶ 15-17.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See PTO-892, particularly:
Kondapalli et al., US 2020/0076715, disclosing Technologies for capturing processing resource metrics as a function of time.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL W CHAO whose telephone number is (571)272-5165. The examiner can normally be reached M, W-F 8-5.
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, Rupal Dharia can be reached at (571) 272-3880. 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.
/MICHAEL W CHAO/ Primary Examiner, Art Unit 2492