CTFR 17/628,896 CTFR 85279 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. This action Is in response to the claims filed 6/24/2026. Claims 1, 2, 4, 5, 7-16, 23, 24, and 29-37 are pending. Claims 1 (a machine), 9 (a non-transitory CRM), and 23 (a method) are independent. Effective filing date: 9/30/2019 Applicant's remarks on page 8 are persuasive. The Appendix to the provisional application 62/908,386 discloses a token along with attestation. Therefore, the effective filing date of the present application is the filing date of the provisional '386, 9/30/2019. As the cited Smith reference US 2019/0138294 was published on 05/09/2019, less than a year before the effective filing date of the present application, the Smith reference may be invalided as prior art per MPEP 2153.01(a) with a declaration under 37 CFR 1.130(a) asserting that the cited portions of the Smith reference are the inventors own work (i.e. not the work of the John Browne, Vincent Zimmer, and Kapil Sood inventors of the Smith publication US 2019/0138294). Claim Rejections - 35 USC § 112 07-30-01 AIA The following is a quotation of the first paragraph of 35 U.S.C. 112(a): (a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention. The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112: The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention. 07-31-01 Claims 34 is rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. New claim 34 requires: “disable the telemetry interface in response to enabling access to the attestation interface” The words enable and disable are not found within the specification. More specifically, disabling an interface in response to enabling an interface was not found within the specification. Response to Arguments 07-37 AIA Applicant's arguments filed 6/24/2026 have been fully considered but they are not persuasive. Exemplary claim 1 recites in the relevant portion: "cause, in response to receipt of the token, an attestation interface corresponding to the first object to enable access to the evidence by external objects and systems, the evidence to be accessed via the attestation interface by the external objects and systems for verification of the first object," Applicant's specification does not describe enabling access. Rather Applicant's specification discloses: Applicant's specification ¶ 92: "the AIO interface 712 may be provided/utilized for fully out-of- band attestation assessments that occur independent of data accesses or telemetry collection. For example, a risk management monitoring system may sample the AIO interface 712 regularly to observe changes in trustworthiness. A device, service or object onboarding task may consult the AIO interface 712 as a prerequisite to pursuing further onboarding actions." Applicant's specification ¶ 125: "the verifier 1204 may open a side-band connection to the AIO Interface 710 to perform an assessment of trustworthiness while the data or TIO 708 session is blocked waiting for the attestation assessment to complete." In summary, Applicant's specification does not disclose enabling interfaces but rather discloses attestation (validation) performed prior to further communication. As is normally done for validations. This providing of access to the evidence is shown by the forwarding of the token in Knauth steps 6 and 7, as shown in Figure 1. Further this is shown in Smith in ¶¶ 117 and 131-135, where a token is received and forwarded to a peer device for verification. As to the newly added limitation: "the evidence to be accessed via the attestation interface by the external objects and systems for verification of the first object,"; this "to be" limitation is non-limiting intended use as it is explicitly performed in the future and not within the boundary of the claimed invention. However, this is also shown by the citations (above) illustrating enablement of access to the evidence through providing the token to external parties. As to the newly presented claims 33-37: (claim 33) Receiving requests for the evidence (the token), this is shown by the respective requests in Knauth and Smith that result in the token being provided. (claims 34-35) The terms enabling and disabling are not found in Applicant's specification and the most relevant subject matter, conditioning access on the validation of the token, is shown in Smith ¶¶ 108 and 118. (claim 36) Both Knauth and Smith disclose that the token is in response to an attestation, i.e. that the object is verified. (claim 37) Both Knauth and Smith disclose that the token is in response to an attestation, i.e. that the object is verified. More generally, in the context of Applicants prior disclosures of tokens provided in response to attestation (Knauth and Smith being Applicant published disclosures) the various use cases of the claims such as using the token to verify attestations and condition access logically follow from the purpose of the token created . 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, 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-21-aia AIA Claim (s) 1, 2, 4, 5, 7-16, 23, 24, and 33-37 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 a multi-access edge computing (MEC) platform based on the association; (“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 MEC platform; (“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.) the evidence to be accessed via the attestation interface by the external objects and systems for verification of the first object (transmitting the quote it on to the challenger (Step 6). The Intel Attestation Service (IAS) verifies the quote (Step 7).” Knauth § 2.1.) 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, the evidence to be accessed via the attestation interface by the external objects and systems for verification of the first object (note that "to be" is intended future action and therefore not part of the claimed invention. However, see Smith ¶ 117: "the attestation record may be a token issued to the edge device by the token server 1225 based on the verification. The token may contain the SVN, version or other attribute to describe the status of the software update and its current operational status such that a consumer of the token (e.g., peer device 1240, etc.) may inspect the various additional values to compare to policies directing access control and/or risk management processes affected.") 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 claim 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 claim 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, and 15, 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 33, Knauth in view of Smith discloses the machine/CRM/method of claims 1, 9, and 23 and further discloses: wherein one or more of the at least one programmable circuitry is to receive, via the attestation interface, a request from the external objects and systems; and provide the evidence to the external objects and systems based on the token. (See Knauth § 2.1. "Step 7: Attestation result sent (e.g., by the verifier 1220) to Token Server 1225. Step 8: Token issued (e.g., by the token server 1225). Step 9: Peer device 1240 contacts and receives token (e.g., from the device 1235). Step 10: Peer device 1240 validates/verifies token". Also Smith ¶¶ 131-134). As to claims 34, Knauth in view of Smith discloses the machine/CRM/method of claims 33 and further discloses: wherein one or more of the at least one programmable circuitry is to disable the telemetry interface in response to enabling access to the attestation interface. ("When a peer device 1240 interacts with the device 1235, before data is exchanged, the peer device 1240 queries the device 1235 for its attestation token and verifies the token was issued by the token server 1225." Smith ¶ 108. "If step 4 f is not successful, the software update is retracted, and the peer devices may later perform steps 9 and 10 to obtain and verify the pre-update tokens (which apply as the update was undone). If attestation token verification succeeds, the peer device knows it is safe to request services or exchange data with the device." Smith ¶ 118. Token must be issued/reissued before communication between peers may commence.) As to claims 35, Knauth in view of Smith discloses the machine/CRM/method of claims 1, 9, and 23 and further discloses: wherein one or more of the at least one programmable circuitry is to change the attestation interface from a disabled state to an enabled state in response to receiving the token from the MEC platform. ("When a peer device 1240 interacts with the device 1235, before data is exchanged, the peer device 1240 queries the device 1235 for its attestation token and verifies the token was issued by the token server 1225." Smith ¶ 108.) As to claims 36, Knauth in view of Smith discloses the machine/CRM/method of claims 1, 9, and 23 and further discloses: wherein the token indicates that the first object has been verified. ("the attestation record may be a token issued to the edge device by the token server 1225 based on the verification. The token may contain the SVN, version or other attribute to describe the status of the software update and its current operational status such that a consumer of the token (e.g., peer device 1240, etc.) may inspect the various additional values to compare to policies directing access control and/or risk management processes affected. " Smith ¶ 117. Also Smith ¶ 108) As to claims 37, Knauth in view of Smith discloses the machine/CRM/method of claims 36 and further discloses: wherein the token indicates that the first object has been verified based on the association of the evidence with the telemetry data. (various additional values "the attestation record may be a token issued to the edge device by the token server 1225 based on the verification. The token may contain the SVN, version or other attribute to describe the status of the software update and its current operational status such that a consumer of the token (e.g., peer device 1240, etc.) may inspect the various additional values to compare to policies directing access control and/or risk management processes affected. " Smith ¶ 117. Also Smith ¶ 108) 07-21-aia AIA 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 . 07-21-aia AIA 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 07-21-aia AIA 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 07-96 AIA The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See PTO-892, particularly: Sood et al., US 2018/0114012, discloses telemetry collection in a MEC context. 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 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 Application/Control Number: 17/628,896 Page 2 Art Unit: 2492 Application/Control Number: 17/628,896 Page 3 Art Unit: 2492 Application/Control Number: 17/628,896 Page 4 Art Unit: 2492 Application/Control Number: 17/628,896 Page 5 Art Unit: 2492 Application/Control Number: 17/628,896 Page 6 Art Unit: 2492 Application/Control Number: 17/628,896 Page 7 Art Unit: 2492 Application/Control Number: 17/628,896 Page 8 Art Unit: 2492 Application/Control Number: 17/628,896 Page 9 Art Unit: 2492 Application/Control Number: 17/628,896 Page 10 Art Unit: 2492 Application/Control Number: 17/628,896 Page 11 Art Unit: 2492 Application/Control Number: 17/628,896 Page 12 Art Unit: 2492 Application/Control Number: 17/628,896 Page 13 Art Unit: 2492 Application/Control Number: 17/628,896 Page 14 Art Unit: 2492 Application/Control Number: 17/628,896 Page 15 Art Unit: 2492 Application/Control Number: 17/628,896 Page 16 Art Unit: 2492 Application/Control Number: 17/628,896 Page 17 Art Unit: 2492 Application/Control Number: 17/628,896 Page 18 Art Unit: 2492 Application/Control Number: 17/628,896 Page 19 Art Unit: 2492 Application/Control Number: 17/628,896 Page 20 Art Unit: 2492
Prosecution Insights