DETAILED ACTION
713.09 Interviews Between Final Rejection and Notice of Appeal [R-08.2017]
Normally, one interview after final rejection is permitted in order to place the application in condition for allowance or to resolve issues prior to appeal. However, prior to the interview, the intended purpose and content of the interview should be presented briefly, preferably in writing. Such an interview may be granted if the examiner is convinced that disposal or clarification for appeal may be accomplished with only nominal further consideration. Interviews merely to restate arguments of record or to discuss new limitations which would require more than nominal reconsideration or new search should be denied. See MPEP § 714.13.
Interviews may be held after the expiration of the shortened statutory period and prior to the maximum permitted statutory period of 6 months without an extension of time. See MPEP § 706.07(f).
A second or further interview after a final rejection may be held if the examiner is convinced that it will expedite the issues for appeal or disposal of the application.
For interviews after notice of appeal, see MPEP § 1204.03.
Interview time will be revised to a limit of 1 hour per new application or RCE (utility)/CPA (design), when during prosecution, the examiner conducts an interview. When more than one interview is needed in an application supervisors will have the flexibility to approve additional time and ensure that the interviews are being used to advance prosecution.
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 .
Response to Amendment
In response to the claims amendment in view of the Remarks filed 07/19/2026, the 112 rejection has been withdrawn.
In response to the claims amendment in view of the Remarks, the 101 rejection has been withdrawn.
In response to the claims amendment in view of the Remarks, the double patenting rejection has been withdrawn.
Drawings
The drawings are objected to as failing to comply with 37 CFR 1.84(p)(5) because they do not include the following reference sign(s) mentioned in the description: “software payload 2” (See specification; page 13).
Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Claim Objections
Claim 1 – 4, 6 – 12 and 14 are objected to because of the following informalities:
Regarding claims 1, 12, and 14, the limitation “the hash output” lacks proper antecedent basis.
Claims 2 – 4, 6 – 10 are dependent claims and thus also objected.
Regarding claim 14; the limitation “the instance of a cloud service provider” lacks proper antecedent basis.
Appropriate correction is required.
Claim Rejections - 35 USC § 103
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 (i.e., changing from AIA to pre-AIA ) 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.
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 – 4, 6 – 10, 12 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over the prior art of record, Steiner et al., (US 2019/0065406 A1) (hereinafter “Steiner”) in view of the prior art of record, Lee et al., (US 2010/0281273 A1) (hereinafter “Lee”).
Regarding claim 1, Steiner discloses; a computer-implemented method to establish a secure channel between an owner device of a software payload and the software payload itself when running into a hardware-based trusted execution environment, HW TEE, at an instance of a cloud service provider, the method comprising the following steps:
generating, by the software payload, a payload key pair: public key and private key [i.e., generates a public/private key pair for the server application (page 3, para 0027)];
mixing, by the software payload, the payload public key [i.e., binding the public key to the attestation by including a hash of the public key in the attestation/quote (page 7, para 0073)];
computing, by the HW TEE, an attestation using mixed with the payload public key [i.e., obtaining a platform attestation report (PAR) i.e., quote from the processor for the enclave, with attestation data attesting to enclave integrity (page 3, para 0024) i.e., the attester may include a cryptographic hash of the public key in the PAR/quote to tie the TLS key pair to that enclave instance (page 3, para 0025)];
sending, by the software payload, at least the attestation, and the payload public key to the owner [i.e., the attester sends the ETE certificate to the challenger during the TLS handshake process (page 3, para 0028) i.e., the server enclave public key (SEPK), the attestation evidence, and the verification flow to the client (page 7, para 0064 – 0068), (see figure 2)];
verifying, by the owner device, the attestation using mixed with the received payload public key [i.e., the client extracting SEPK-Hash 174 from the attestation evidence, hashing the received public key, and verifying the match (page 4, para 0043), (page 7, para 0068), (see figures 1 and 6)];
generating, by the software payload and the owner device, a session key between them [i.e., generate one or more TLS session keys 160 for protecting communications between server enclave 170 and client enclave 150 (page 2, para 0021), (page 4, para 0043), (page 7, para 0069 - 0071), (see figures 1 and 2)]; and
establishing a secure channel between the owner device and the software payload running into the HW TEE [i.e., after successful completion of the handshake, the endpoints may conduct regular communications via the established channel (page 2, para 0021)].
Steiner does not disclose;
sending, by the owner device, at least a nonce to the software payload; mixing the payload public key with the nonce, wherein the software payload firstly computes a hash of the payload public key and then scrambles the hash output with the nonce generated by the owner device; computing an attestation using at least this nonce; and verifying the attestation using the sent nonce.
However, Lee discloses;
sending, by the owner device, at least a nonce to the software payload [i.e., an attestation request from a remote party is made to a trusted software module in D with a session nonce N (labeled 252) for freshness (page 14, pare 0119), (see figure 10) Note; the remote party corresponds to the claimed owner];
mixing the payload public key with the nonce [i.e., creates a certificate MC 260 using a hash function 258 to bind the public encryption key EK to the session’s nonce N (page 14, para 0119), (see figure 10)], wherein the software payload firstly computes a hash of the payload public key and then scrambles the hash output with the nonce generated by the owner device [i.e., an attestation request from a remote party is made to a trusted software module with a session nonce N (252) for freshness. Upon receiving the attestation request, the trusted software module generates a public/private key pair EK (254), DK (256) and creates certificate MC (260) using hash function 258 to bind the public encryption key EK to the session nonce N (page 14, para 0119), (see figure 10) i.e., the module thereafter invokes the hypervisor, which generates hypervisor report 266, and the processor’s attestation function 268 signs an attestation message binding the hypervisor identity and combined module identities to certificate MC to produce attestation report 274. The signature, public encryption key EK, and attestation report are subsequently returned to the requester (page 14, para 0119), (see figure 10)];
computing an attestation using at least this nonce [i.e., the processor signs an attestation message binding the hypervisor identity HV 272 to the combined module identities in H(D) and certificate MC and the produce an attestation report 274 (page 14, para 0119), (see figured 10)]; and
verifying the attestation using the sent nonce [i.e., the nonce is bound into the certificate used in the attestation flow, and that the nonce is there for freshness (page 14, para 0119), (see figure 10)].
Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to modify the teachings of Steiner by adapting the teachings of Lee to improved security for computer systems (See Lee; page 1, para 0004).
Regarding claim 2, Steiner discloses; the method according to claim 1, further comprising the following steps for generating the session key by the software payload and the owner device using a non-authenticated key- agreement protocol:
generating and sending, by the owner device, owner public data to the software payload [i.e., generates a public/private key pair for the server application (page 3, para 0027)];
generating, by the software payload, payload public data and signing this payload public data using the generated payload private key [i.e., generates a public/private key pair for the server application (page 3, para 0027)];
sending, by the software payload, the payload public data and the signed payload public data to the owner device [i.e., the attester sends the ETE certificate to the challenger during the TLS handshake process (page 3, para 0028) i.e., the server enclave public key (SEPK), the attestation evidence, and the verification flow to the client (page 7, para 0064 – 0068), (see figure 2)];
verifying, by the owner device, the signed payload public data using the received payload public key [i.e., the client extracting SEPK-Hash 174 from the attestation evidence, hashing the received public key, and verifying the match (page 4, para 0043), (page 7, para 0068), (see figures 1 and 6)]; and
computing, by the software payload and the owner device, a shared secret using owner public data and payload public data, respectively [i.e., generate one or more TLS session keys 160 for protecting communications between server enclave 170 and client enclave 150 (page 2, para 0021), (page 4, para 0043), (page 7, para 0069 - 0071), (see figures 1 and 2)].
Regarding claim 3, Steiner discloses; method according to claim 2, wherein the non-authenticated key-agreement protocol is based on a Elliptic Curve Diffie-Hellman, ECDH, protocol [i.e., the attester sends the ETE certificate to the challenger during the TLS handshake process (page 3, para 0028) i.e., the server enclave public key (SEPK), the attestation evidence, and the verification flow to the client (page 7, para 0064 – 0068), (see figure 2)].
Regarding claim 4, Steiner discloses; method according to claim 2, wherein the shared secret is passed through a key derivation function, KDF, to generate the session key [i.e., client application 144 and server application 146 may then use that “master secret” value to generate one or more TLS session keys (para 0071)].
Regarding claim 6, Steiner discloses; the method according to claim 1 [i.e., (see claim 1 above)].
Steiner does not disclose;
wherein, once the secure channel has been established between the owner device and the software payload running into the HW TEE, the owner device sends an owner authentication information to the payload, this owner authentication means being configured to allow subsequent authentication of the owner device to the payload to re-establish a secure channel.
However, Lee discloses;
once the secure channel has been established between the owner device and the software payload running into the HW TEE, the owner device sends an owner authentication information to the payload, this owner authentication means being configured to allow subsequent authentication of the owner to the payload to re-establish a secure channel [i.e., trusted modules validate data received from outside the trust domain using cryptographic validation and keys stored in sealed storage (para 0036) i.e., a module can authenticate the caller or a trusted authority using known/public keys and authenticated interface (para 0113) i.e., secure communication channels to trusted authorities by authenticating the authority using a public key embedded in the modules data space (para 0068)].
Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to modify the teachings of Steiner by adapting the teachings of Lee to improved security for computer systems (See Lee; page 1, para 0004).
Regarding claim 7, Steiner discloses; the method according to claim 6, wherein said owner authentication information is a X.509 certificate [i.e., ETE certificate that is formatted as an X.509 certificate (para 0027)].
Regarding claim 8, Steiner discloses; the method according to claim 6, wherein the owner device generates an owner key pair: public key and private key using, for example, ECDSA, and then sends the owner public key to the software payload for subsequent authentication purposes [i.e., the client extracting SEPK-Hash 174 from the attestation evidence, hashing the received public key, and verifying the match (page 4, para 0043), (page 7, para 0068), (see figures 1 and 6)].
Regarding claim 9, Steiner discloses; the method according to claim 6 [i.e., (see claim 6 above)].
Steiner does not disclose;
wherein, after receiving the authentication information, the software payload stores it in a memory under the protection of the HW TEE.
However, Lee discloses;
after receiving the authentication information, the software payload stores it in a memory under the protection of the HW TEE [i.e., encrypted/integrity-checked pages, sealed storage, storage of keys in protected storage, and recovery of keys/hashes only when the requesting module identity matches (para 0058)].
Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to modify the teachings of Steiner by adapting the teachings of Lee to improved security for computer systems (See Lee; page 1, para 0004).
Regarding claim 10, Steiner discloses; a computer-implemented method to re-establish an authenticated secure channel between an owner device of a software payload and the software payload itself when running into a hardware-based trusted execution environment, HW TEE, at the instance of a cloud service provider, the method comprising the following steps:
establishing a secure channel according to the method of claim 1 [i.e., (see claim 1 above)];
stopping the secure channel [i.e., after successful completion of the handshake, the endpoints may conduct regular communications via the established channel (page 2, para 0021)];
generating, by the owner device, new owner public data [i.e., generates a public/private key pair for the server application (page 3, para 0027)];
signing, by the owner device, this new owner public data and sending it to the software payload [i.e., binding the public key to the attestation by including a hash of the public key in the attestation/quote (page 7, para 0073)];
retrieving, by the software payload, owner authentication information configured to allow subsequent authentication of the owner device to the payload to re-establish a secure channel [i.e., after successful completion of the handshake, the endpoints may conduct regular communications via the established channel (page 2, para 0021)];
verifying, by the software payload, the signed new owner public data by using the owner authentication information [i.e., the attester sends the ETE certificate to the challenger during the TLS handshake process (page 3, para 0028) i.e., the server enclave public key (SEPK), the attestation evidence, and the verification flow to the client (page 7, para 0064 – 0068), (see figure 2)];
generating, by the software payload, new payload public data and signing this payload public data using the payload private key [i.e., generate one or more TLS session keys 160 for protecting communications between server enclave 170 and client enclave 150 (page 2, para 0021), (page 4, para 0043), (page 7, para 0069 - 0071), (see figures 1 and 2)];
sending, by the software payload, the new payload public data and the signed new payload public data to the owner device [i.e., after successful completion of the handshake, the endpoints may conduct regular communications via the established channel (page 2, para 0021)];
verifying, by the owner device, the signed new payload public data using the payload public key [i.e., the attester sends the ETE certificate to the challenger during the TLS handshake process (page 3, para 0028) i.e., the server enclave public key (SEPK), the attestation evidence, and the verification flow to the client (page 7, para 0064 – 0068), (see figure 2)];
computing, by the software payload and the owner device, a new shared secret using new owner public data and new payload public data, respectively [i.e., the attester sends the ETE certificate to the challenger during the TLS handshake process (page 3, para 0028) i.e., the server enclave public key (SEPK), the attestation evidence, and the verification flow to the client (page 7, para 0064 – 0068), (see figure 2)];
generating, by the software payload and the owner device, a session key between them [i.e., generate one or more TLS session keys 160 for protecting communications between server enclave 170 and client enclave 150 (page 2, para 0021), (page 4, para 0043), (page 7, para 0069 - 0071), (see figures 1 and 2)]; and
re-establishing a secure channel between the owner device and the software payload running into the HW TEE [i.e., after successful completion of the handshake, the endpoints may conduct regular communications via the established channel (page 2, para 0021)].
Regarding claim 12, Steiner discloses; an owner of a software payload [i.e., entity that control data processing system 120 (para 0026), (see figure 1)] for establishing a secure channel [i.e., generate one or more TLS session keys 160 for protecting communications between server enclave 170 and client enclave 150 (page 2, para 0021), (page 4, para 0043), (page 7, para 0069 - 0071), (see figures 1 and 2)] with the software payload itself when running into a hardware-based trusted execution environment (HW TEE) at an instance of a cloud service provider, the owner device being configured to send the software payload to the HW TEE for its execution, wherein the owner device is further configured to
send at least a nonce to the software payload for mixing with a generated payload public key [i.e., binding the public key to the attestation by including a hash of the public key in the attestation/quote (page 7, para 0073)]; and
to receive, from the software payload, said payload public key and an attestation computed by the HW TEE using said mix of the payload public key;
mix the received payload public key with [i.e., binding the public key to the attestation by including a hash of the public key in the attestation/quote (page 7, para 0073)], and verify the received attestation from the software payload using this mixed information [i.e., the client extracting SEPK-Hash 174 from the attestation evidence, hashing the received public key, and verifying the match (page 4, para 0043), (page 7, para 0068), (see figures 1 and 6)]; and
generate a session key [i.e., generate one or more TLS session keys 160 for protecting communications between server enclave 170 and client enclave 150 (page 2, para 0021), (page 4, para 0043), (page 7, para 0069 - 0071), (see figures 1 and 2)] thus establishing the secure channel with the software payload [i.e., after successful completion of the handshake, the endpoints may conduct regular communications via the established channel (page 2, para 0021)].
Steiner does not disclose;
sending, by the owner, at least a nonce to the software payload; mixing the payload public key with the nonce, wherein the software payload firstly computes a hash of the payload public key and then scrambles the hash output with the nonce generated by the owner device; computing an attestation using at least this nonce; and verifying the attestation using the sent nonce.
However, Lee discloses;
sending, by the owner, at least a nonce to the software payload [i.e., an attestation request from a remote party is made to a trusted software module in D with a session nonce N (labeled 252) for freshness (page 14, pare 0119), (see figure 10) Note; the remote party corresponds to the claimed owner];
mixing the payload public key with the nonce [i.e., creates a certificate MC 260 using a hash function 258 to bind the public encryption key EK to the session’s nonce N (page 14, para 0119), (see figure 10)], wherein the software payload firstly computes a hash of the payload public key and then scrambles the hash output with the nonce generated by the owner device [i.e., an attestation request from a remote party is made to a trusted software module with a session nonce N (252) for freshness. Upon receiving the attestation request, the trusted software module generates a public/private key pair EK (254), DK (256) and creates certificate MC (260) using hash function 258 to bind the public encryption key EK to the session nonce N (page 14, para 0119), (see figure 10) i.e., the module thereafter invokes the hypervisor, which generates hypervisor report 266, and the processor’s attestation function 268 signs an attestation message binding the hypervisor identity and combined module identities to certificate MC to produce attestation report 274. The signature, public encryption key EK, and attestation report are subsequently returned to the requester (page 14, para 0119), (see figure 10)];
computing an attestation using at least this nonce [i.e., the processor signs an attestation message binding the hypervisor identity HV 272 to the combined module identities in H(D) and certificate MC and the produce an attestation report 274 (page 14, para 0119), (see figured 10)]; and
verifying the attestation using the sent nonce [i.e., the nonce is bound into the certificate used in the attestation flow, and that the nonce is there for freshness (page 14, para 0119), (see figure 10)].
Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to modify the teachings of Steiner by adapting the teachings of Lee to improved security for computer systems (See Lee; page 1, para 0004).
Regarding claim 14, Steiner discloses; an hardware-based trusted execution environment, HW TEE, at the instance of a cloud service provider for establishing a secure channel between an owner of a software payload and the software payload itself when running into a the HW TEE, wherein the HW TEE is operated by the cloud service provider; wherein the HW TEE is configured to:
received a payload public key generated by the payload mixed with originally sent by the owner [i.e., binding the public key to the attestation by including a hash of the public key in the attestation/quote (page 7, para 0073)];
compute an attestation using at least this received nonce mixed with the payload public key [i.e., obtaining a platform attestation report (PAR) i.e., quote from the processor for the enclave, with attestation data attesting to enclave integrity (page 3, para 0024) i.e., the attester may include a cryptographic hash of the public key in the PAR/quote to tie the TLS key pair to that enclave instance (page 3, para 0025)]; and
send said attestation to the software payload for its further verification by the owner device [i.e., the attester sends the ETE certificate to the challenger during the TLS handshake process (page 3, para 0028) i.e., the server enclave public key (SEPK), the attestation evidence, and the verification flow to the client (page 7, para 0064 – 0068), (see figure 2)].
Steiner does not disclose;
received a payload public key generated by the payload mixed with a nonce, wherein the software payload firstly computes a hash of the payload public key and then scrambles the hash output with the nonce generated by the owner device.
However, Lee discloses;
received a payload public key generated by the payload mixed with a nonce [i.e., an attestation request from a remote party is made to a trusted software module in D with a session nonce N (labeled 252) for freshness (page 14, pare 0119), (see figure 10) Note; the remote party corresponds to the claimed owner], wherein the software payload firstly computes a hash of the payload public key and then scrambles the hash output with the nonce generated by the owner device [i.e., an attestation request from a remote party is made to a trusted software module with a session nonce N (252) for freshness. Upon receiving the attestation request, the trusted software module generates a public/private key pair EK (254), DK (256) and creates certificate MC (260) using hash function 258 to bind the public encryption key EK to the session nonce N (page 14, para 0119), (see figure 10) i.e., the module thereafter invokes the hypervisor, which generates hypervisor report 266, and the processor’s attestation function 268 signs an attestation message binding the hypervisor identity and combined module identities to certificate MC to produce attestation report 274. The signature, public encryption key EK, and attestation report are subsequently returned to the requester (page 14, para 0119), (see figure 10)].
Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to modify the teachings of Steiner by adapting the teachings of Lee to improved security for computer systems (See Lee; page 1, para 0004).
Response to Arguments
Applicants’ arguments in the Remarks filed 07/19/2026 have been fully considered but they are not persuasive because of the followings;
Regarding claims 1, 12 and 14, applicant argues that Lee fails to disclose the newly added limitation requiring that the software payload “firstly computes a hash of the payload public key and then scrambles the hash output with the nonce generated by the owner device.” In particular, Applicant argues that Lee merely uses a hash function to bind the public key EK to nonce N and does not disclose scrambling the hash output with nonce, such as by an XOR operation.
The Examiner respectfully disagrees with this argument because as previously set forth in the rejection, Lee expressly discloses, with reference to figure 10, that an attestation request from a remote party includes session nonce N (252) for freshness. Upon receiving the request, the trusted software module generates public/private key pair EK (254), DK (256) and creates certificate MC (260) using hash function 258 to bind public encryption key EK to session nonce N (Lee, para 0119 and figure 10). Lee therefore does not merely disclose a certificate-generation operation unrelated to the nonce, as Applicant’s argument appears to suggest. Rather, Lee expressly associates the public encryption key EK, hash function 258, session nonce N, and certificate MC 260 within the same cryptographic operation, with nonce N expressly being provided for freshness. The resulting certificate MC is thereafter incorporated into the processor-signed attestation report.
To the extent Applicant argues that “scrambling” requires XOR-ing the hash output with the nonce, such argument is not persuasive because the claim does not expressly require an XOR operation as the particular manner of scrambling. Lee’s disclosure instead expressly teaches hash-based cryptographic binding of the payload public key EK with the owner provided nonce N. Thus, the fact that Lee does not expressly characterize the disclosed binding operation as an “XOR” operation does not distinguish the claimed subject matter.
Moreover, the corresponding embodiment of Lee confirms that the nonce-binding operation is part of the attestation procedure rather than an unrelated certificate operation. In para 0139, Lee again teaches that, upon receiving an attestation request from P2Pcall server 310, the trusted SRM first generates public/private key pair EK/DK and creates certificate C binding public encryption key EK to session nonce N used by the server for freshness. The VMM and processor thereafter incorporate certificate C into the signed attestation message returned to the server. Accordingly, Lee’s disclosure of using hash function 258 to bind public encryption key EK with requester provided nonce N for freshness teaches or at least suggest the claimed hash-based mixing/scrambling of the payload public-key information with the nonce.
Regarding claim 10, applicant argued that claim 10 recites the limitation of establishing a secure channel according to the method of claim 1, which means that the claim 10 establishes the secure channel by implementing the steps of claim 1. Thus, claim 10 is also novel and non-obvious in view of these cited references.
The Examiner respectfully disagrees with this argument because of the response to argument with respect to claim 1 and the rejection above.
Conclusion
THIS ACTION IS MADE FINAL. 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 SYED A RONI whose telephone number is (571)270-7806. The examiner can normally be reached M-F 9:00-5:00 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, Jeffrey L Nickerson can be reached at (469) 295-9235. 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.
/SYED A RONI/Primary Examiner, Art Unit 2432
Prosecution Insights