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 .
Priority
Acknowledgment is made of applicant's claim for foreign priority based on an application filed in China on January 30, 2022. It is noted, however, that applicant has not filed a certified copy of the 202210114372.1 application as required by 37 CFR 1.55.
Response to Arguments
Applicant’s arguments, see pages 9-11, filed 01/14/2026, with respect to the rejections of claims 1-9 and 13-20 are under 35 U.S.C. 103 as being unpatentable over Hjelm et al (US 20160254904 A1 –hereinafter –" Hjelm”) in view of CACERES et al. (US 20200382321 A1—hereinafter—"CACERES”) 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 further view of PARK et al. (US 20200178066 A1 –hereinafter—"PARK”).
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.
Claims 1-9 and 13-20 are are rejected under 35 U.S.C. 103 as being unpatentable over Hjelm et al (US 20160254904 A1 –hereinafter –" Hjelm”) in view of CACERES et al. (US 20200382321 A1—hereinafter—"CACERES”) in further view of PARK et al. (US 20200178066 A1 –hereinafter—"PARK”).
As per claim 1: Hjelm discloses a computer-implemented method, comprising:
receiving, by an authentication server from a trusted execution environment (TEE) of a terminal device, device authentication information through a secure channel between the TEE and the authentication server, wherein the device authentication information is configured to authenticate an identity ([0026] Service providers 210-A through 210-Z (generically and individually referred to herein as a “service provider 210” and collectively as “service providers 210”) may each include a respective server(s) 215-A through 215-Z (generically and individually referred to herein as a “server(s) 215” and collectively as “servers 215”) which further includes one or more network devices. Server(s) 215 of service provider 210 delivers a network service(s) to device 100. Trusted service managers 220-A through 220-Z (generically and individually referred to herein as a “service manager 220” and collectively as “service managers 220”) may each manage secure access to a network service provided by a respective server 215 of a service provider 210. Trusted service manager 220 may, for example, issue a service digital certificate for one or more network services to device 100, and grant secure access to the one or more network services based on a subsequent service request from device 100. Trusted service managers 220-A through 220-Z may manage the network service access as described further with respect to FIGS. 9 and 10 below. Multiple ones of trusted service managers 220-A through 220-Z may be implemented as a single trusted service manager);
performing, by the authentication server based on the device authentication information, device authentication on the terminal device ([0047] TEE 130 retrieves the appropriate service certificate from memory (block 930) and sends the retrieved service certificate to a trusted service manager 220 (block 940). Upon acknowledging acceptance of the network service, or requesting the initiation of the network service, by the user of device 100, TEE 130 retrieves a corresponding service certificate from memory (e.g., secure memory 135, FIG. 1A) and sends the service certificate to trusted service manager 220 via communication interface 180 and network 230. Upon receipt of the service certificate, trusted service manager 220 verifies the service certificate and, upon successful verification, authorizes the network service for device 100 via a corresponding server 215. To authorize a requested network service, trusted service manager 220 sends a service granting message to the corresponding server 215 for the requested network service); and
in response to determining that the terminal device passes the device authentication, sending, by the authentication server, a service encryption key and a device identity certificate to the TEE through the secure channel, wherein the service encryption key is configured to encrypt a service session key for encrypting service data ([0048] TEE 130 engages in a network service with a service provider, using the service certificate and a trusted application executed in TEE 130 (block 950). Referring again to FIG. 10, TEE 130 executes a trusted application (e.g., trust app Z 1005-Z) and engages in the network service (e.g., service Z implemented by server 215-Z) using the service certificate (e.g., svc cert Z 1010-Z). Engaging in the network service via the trusted app may, as depicted in FIG. 10, additionally involve interaction with an application (e.g., app Z) executed by device processing unit 105 (not shown in this FIG.; see FIG. 1A) within rich OS 107 (not shown in this FIGURE; see FIG. 1A) and outside of TEE 130. FIG. 10 shows TEE 130 executing trusted app Z 1005-Z and using service certificate Z 1010-Z to engage in a network service Z with server 215-Z via application Z 1015-Z that is “outside” of TEE 130. FIG. 10 further shows TEE 130 executing trusted app A 1005-A and using service certificate A 1010-A to engage in a network service A with server 215-A via application A 1010-A that is “outside” of TEE 130 (i.e., executed by rich OS 107). Each network service may include any type of network service provided over network 230 such as, for example, a streaming media delivery network service).
Hjelm does not explicitly disclose the authenticated identity is identity of the terminal device; and the device identity certificate indicates authenticity of the terminal device. CACERES, in analogous art however, discloses the authenticated identity is identity of the terminal device and the device identity certificate indicates authenticity of the terminal device ([0013] In some implementations, a multi-layered (e.g., dual) attestation may be performed by the attestation devices described herein, by which attestation of an application may be combined with attestation of the client device. In this way, the security associated with performing client-server transactions by way of the application further increases. [0021] The secure element may include a logically and physically tamper-resistant hardware platform, configured to securely store the attestation data. While the secure element is illustrated as being detached from the client device, the secure element may, in some cases, be secured to the client device or embedding the secure element within the client device. The secure element may include a secure chip or a microcontroller in the form of an embedded secure element, a universal integrated circuit card (UICC), an embedded universal integrated circuit card (eUICC), a secure digital (SD) card, a microSD card, a subscriber identification module (SIM) card, and/or the like. [0036] In some implementations, the application attestation described herein may be used alone, or in combination with attestation of the client device. In this way, the client device-server transactions performed using an application may be further increased. In this regard, in some implementations, the application server device may challenge the client device for a client device attestation key and/or a signed, client device certificate. The secure element may store client device attestation keys and/or the client device certificates, in addition to the application attestation keys, and respond to the challenge with the attestation key, and, at least one of a client device key, or the signed client device certificate. [0079] In some implementations, process 500 may include receiving, from an application server device, a request for a device certificate by which to verify an identity of the device, and transmitting, to the application server device, the device certificate for verifying the identity of the device). [0050] Application server device 240 may communicate attestation data and/or policies to secure element 230 of client device 210 for use in performing attestation, as described herein, by which the identities of applications running on client device 210, and/or client device 210, may be verified).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitation of the authenticated identity disclosed by Hjelm to include the authenticated identity is identity of the terminal device; and the device identity certificate indicates authenticity of the terminal device. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to provide a signed certificate, by which a client device may submit proof that the client device, and/or the software running on the client device, is in a trusted state as suggested by CACERES ([0002]).
Hjelm and CACERES do not explicitly disclose wherein the service session key is randomly generated by the TEE each time a service party requests to perform service processing, and wherein the TEE encrypts the service session key by using the service encryption key. PARK, in analogous art however, discloses wherein the service session key is randomly generated by the TEE each time a service party requests to perform service processing, and wherein the TEE encrypts the service session key by using the service encryption key ([0176-0177] In operation 318, the TEE that is the terminal secure area may verify the received card cryptogram by using an SCP03 symmetric key that is stored in the TEE. Also, the TEE may generate a session key or a session key set of the SCP03 session that is the same as that generated by the eUICC by using at least one of the SCP03 symmetric key, the card challenge, the host challenge, and the sequence counter. In operation 320, after the card cryptogram passes the verification and the session key is generated, the TEE that is the terminal secure area may allow a host cryptogram generated by using the SCP03 symmetric key to be included in an EXTERNAL AUTHENTICATE APDU message and may transmit the EXTERNAL AUTHENTICATE APDU message through the LPA to the eUICC so that the eUICC authenticates the terminal secure area. [0227] In operation 418, the TEE that is the terminal secure area may verify the received card cryptogram by using an SCP03 symmetric key that is stored in the TEE. Also, the TEE may generate a session key or a session key set of the SCP03 session that is the same as that generated by the eUICC by using at least one of the SCP03 symmetric key, the card challenge, the host challenge, and the sequence counter. [0228] In operation 420, after the card cryptogram passes the verification and the session key is generated, the TEE that is the terminal secure area may allow a host cryptogram generated by using the SCP03 symmetric key to be included in an EXTERNAL AUTHENTICATE APDU message and may transmit the EXTERNAL AUTHENTICATE APDU message through the LPA to the eUICC so that the eUICC authenticates the terminal secure area. [0279] In operation 526, when receiving the MUTUAL AUTHENTICATE Response, the TEE that is the terminal secure area may verify the receipt and may generate an SCP03 session key or an SCP03 session key set. [0679] Encryption may be performed not only by using a method (first method) of encrypting the profile data divided into the encryptable units in operation 1320 with the key of operation 1325 but also by using a method (second method) of encrypting the profile data divided into the encryptable units (i.e., encryptable unit data) in operation 1320 with an encryption key that is randomly generated and then encrypting the encryption key with the key generated in operation 1325.).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations of the service session key disclosed by Hjelm and CACERES to include wherein the service session key is randomly generated by the TEE each time a service party requests to perform service processing, and wherein the TEE encrypts the service session key by using the service encryption key. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to provide methods and devices for remotely installing, by using a wireless communication method or the like, profile information for providing, through a wireless communication network, a communication service to a terminal in which an electronic device is mounted and receiving the profile data includes receiving the profile data that is protected based on a session key obtained by the LPA as suggested by PARK ([0005-0008]).
As per claim 2: Hjelm in view of CACERES in further view of PARK discloses the computer-implemented method according to claim 1, wherein sending the device authentication information comprises:
encrypting, by the TEE based on a channel key, a device certificate of the terminal device to obtain the device authentication information, wherein the device certificate is pre-stored in the TEE, and the channel key is determined by the TEE and the authentication server through negotiation (Hjelm [0022-0023] Bus 175 may include one or more paths that enable the components of device 100 to communicate with one another, with only a secure API 170 being usable to access secure memory 135 and/or secure processing unit 140 via bus 175. ..As further shown in FIG. 1B, secure processing unit 140 may have a dedicated hardware path 185 to communication interface 180, and to other components of device 100 that are not shown in FIGS. 1A and 1B, such as device 100's input and output device(s) (e.g., speaker(s), touch screen display(s), keyboard, and/or microphone(s)). Dedicated hardware path 185 as shown in FIG. 1B is independent of, and unconnected to, bus 175, device processing unit 105 or device memory 110. FIG. 1B further depicts trusted apps/applets 155 that may be executed by secure processing unit 140 in TEE 130, including PKI applets 1-n, and trusted apps 1-m. Trusted apps 1-m and/or PKI applets 1-n may include authentication, encryption, signature generating, key management (mgt), shred and/or zip applications. PKI transactions, using PKI applets in TEE 130, may, in some implementations, be performed using one or more of communications interfaces 180. The PKI applet(s) may use a public key/digital certificate and/or a private key to perform one or more different PKI transactions, and to provide the results of the PKI transactions to apps 112 executing in rich OS 107.
As per claim 3: Hjelm in view of CACERES in further view of PARK discloses the the computer-implemented method according to claim 2, wherein performing the device authentication on the terminal device comprises: decrypting, using the channel key, the device authentication information to obtain the device certificate; and performing the device authentication on the terminal device based on the device certificate (Hjelm [0038] FIG. 6A depicts an example where a secure email app 600, executed by rich OS 107, uses TEE 130 to perform secure encryption and decryption of email messages. As shown in FIG. 6, an encrypted incoming email message 605 is received at secure email app 600 in rich OS 107. Upon receipt of encrypted message 605, secure email app performs initial unsecure processing 610 of the encrypted message 605 before issuing a secure API call 615 to a PKI applet 620 in TEE 130. Secure API call 615 includes the message to be decrypted. Upon receipt of the secure API call 615 and the message to be decrypted, PKI applet 620 in TEE 130 performs secure message processing, where the secure message processing includes decrypting 625 the email message using the private key stored in TEE 130. Upon completion of decryption of the email message, PKI applet 620 sends the decrypted message 630 via a secure path to a display (e.g., touch screen display) of device 100, where the device user may access and read the decrypted email message. For example, referring to FIG. 1B, the secure path may include the dedicated hardware path 185 between secure processing unit 140 of TEE 130 and the display of device 100. TEE 130 may not return decrypted email message 630 to rich OS 107, and all interactions with decrypted email message 630 may only occur within TEE 130).
As per claim 4: Hjelm in view of CACERES in further view of PARK discloses the computer-implemented method according to claim 2, wherein encrypting the device certificate of the terminal device comprises:
signing a challenge code received from the authentication server to obtain first signature information; and encrypting, using the channel key, the device certificate and the first signature information to obtain the device authentication information (Hjelm [0020] Secure processing unit 140 may execute one or more trusted apps or applets 155 to use the private key of the public/private key pair 145 stored in secure memory 135 and/or the digital certificate(s) 150 for external network service access 160 and/or for performing PKI functions 165, as described further below. The PKI functions 165 performed by trusted app(s) or applet(s) 155 may include authentication, encryption, signature generation, key management, data shredding, or data zipping functions. In some implementations, public/private key pair 145 stored in secure memory 135 may include multiple public/private key pairs, with each public/private key pair being associated with multiple different identities or accounts of the device user (e.g., personal account/identity, business account/identity, etc.)([0043] FIG. 8 depicts an exemplary embodiment in which a secure signature applet 800 within TEE 130 is used to respond to, and sign, a challenge that challenges the authenticity of the user of device 100. With device 100 placed into an access mode, the challenge 805 may be received at device 100 in various different ways, including via USB, RFID, NFC, network 230, a keyboard of device 100, or a touch screen of device 100. Secure signature applet 800 may receive challenge 805 via secure direct hardware (HW) access (e.g., via communication interface(s) 180 and bus 185) or via a secure API call(s) into TEE 130. In the embodiment of FIG. 8, the challenge 805 and the responding challenge signature may be processed by secure signature applet 800 in TEE 130 without processing by, or interaction with, rich OS 107. Challenge 805, which may originate via USB, RFID, NFC, network 230, keyboard of device 100, or a touch screen of device 100, may be passed to TEE 130 as a challenge message 810. Upon receipt at signature applet 800 in TEE 130, applet 800 may use a previously stored public key, and user credential information, to generate a signature 820 for signing 815 the challenge message 810. The user credential information may include any kind of data that can be used to authenticate the user of device 100, such as, for example, a hash of a user password, user biometric data, etc. Secure signature applet may use the credential information and the public key, and a signature generation algorithm, to generate signature 820. Subsequent to generation of signature 820, signature applet 800 may issue the signed challenge message. The receiving device may use its own private key to extract the credential information from the signed challenge message, and may verify the authenticity of the user based on the credential information).
As per claim 5: Hjelm in view of CACERES in further view of PARK discloses the computer-implemented method according to claim 4, wherein performing the device authentication on the terminal device comprises:
decrypting, using the channel key, the device authentication information to obtain the device certificate and the first signature information; verifying the first signature information; in response to determining that the first signature information is successfully verified, comparing the challenge code comprised in the first signature information with a locally stored challenge code; and in response to determining that the challenge code is consistent with the locally stored challenge code, performing the device authentication on the terminal device based on the device certificate (Hjelm [0036] The exemplary process may include TEE 130 of device 100 obtaining a public and private key pair (block 400). TEE 130 may, for example, execute a trusted app or PKI applet 155 that performs a key generation algorithm that generates the public and private key pair. One of various different public key algorithms may be used, such as, for example, the Rivest-Shamir-Adleman (RSA) public key algorithm. FIG. 5 depicts TEE 130 obtaining 500 a public and private key pair. TEE 130 stores the public/private key pair in secure memory 135 and provides the public key to rich OS 107 (block 410). FIG. 5 depicts the private key being stored 505 in TEE 130 of device 100, and the public key 510 being passed to rich OS 107 for use by apps 112. Rich OS 107 sends a Public Key Infrastructure (PKI) request, with the public key received in block 410, to a PKI Registration Authority (RA) (block 420). In accordance with existing PKI processes, the RA verifies the identity of the user associated with the PKI request and the public key, stores the public key, and sends a message to the PKI Certificate Authority (CA) authorizing the CA to generate and issue a digital certificate to device 100. FIG. 5 depicts rich OS 107 of device 100 sending a certificate request 515, which includes the public key and user identification information (not shown), to Registration Authority 505. Rich OS 107 receives a digital certificate from the PKI Certificate Authority (CA) (block 430). Upon receipt of authorization from Registration authority 505 (not depicted in FIG. 5), certificate authority 500 returns, as shown in FIG. 5, a PKI digital certificate 520 to rich OS 107 of device 100).
As per claim 6: Hjelm in view of CACERES in further view of PARK discloses the computer-implemented method according to claim 1, wherein sending the service encryption key and the device identity certificate to the TEE comprises:
encrypting, using a channel key, the service encryption key and the device identity certificate to obtain an encrypted service encryption key and an encrypted device identity certificate, wherein the channel key is determined by the authentication server and the TEE through negotiation; and sending the encrypted service encryption key and the encrypted device identity certificate to the TEE (CACERES [0050] Application server device 240 may communicate attestation data and/or policies to secure element 230 of client device 210 for use in performing attestation, as described herein, by which the identities of applications running on client device 210, and/or client device 210, may be verified. [0079] In some implementations, process 500 may include receiving, from an application server device, a request for a device certificate by which to verify an identity of the device, and transmitting, to the application server device, the device certificate for verifying the identity of the device).
As per claim 7: Hjelm in view of CACERES in further view of PARK discloses the computer-implemented method according to claim 2, wherein determining the channel key comprises:
sending, by the authentication server to the TEE, first authentication information that represents an identity of the authentication server; performing, by the TEE based on the first authentication information, identity authentication on the authentication server; sending, by the TEE to the authentication server, second authentication information that represents an identity of the TEE; performing, by the authentication server based on the second authentication information, identity authentication on the TEE; and determining, by the TEE and the authentication server in a handshake manner, the channel key ( CACERES [0021] The secure element may include a logically and physically tamper-resistant hardware platform, configured to securely store the attestation data. While the secure element is illustrated as being detached from the client device, the secure element may, in some cases, be secured to the client device or embedding the secure element within the client device. The secure element may include a secure chip or a microcontroller in the form of an embedded secure element, a universal integrated circuit card (UICC), an embedded universal integrated circuit card (eUICC), a secure digital (SD) card, a microSD card, a subscriber identification module (SIM) card, and/or the like. [0036] In some implementations, the application attestation described herein may be used alone, or in combination with attestation of the client device. In this way, the client device-server transactions performed using an application may be further increased. In this regard, in some implementations, the application server device may challenge the client device for a client device attestation key and/or a signed, client device certificate. The secure element may store client device attestation keys and/or the client device certificates, in addition to the application attestation keys, and respond to the challenge with the attestation key, and, at least one of a client device key, or the signed client device certificate. [0050] Application server device 240 may communicate attestation data and/or policies to secure element 230 of client device 210 for use in performing attestation, as described herein, by which the identities of applications running on client device 210, and/or client device 210, may be verified. [0079] In some implementations, process 500 may include receiving, from an application server device, a request for a device certificate by which to verify an identity of the device, and transmitting, to the application server device, the device certificate for verifying the identity of the device).
As per claim 8: Hjelm in view of CACERES in further view of PARK discloses the computer-implemented method according to claim 1, wherein the service encryption key corresponds to a target service, and wherein the service encryption key is configured to encrypt the service session key of the target service (CACERES [0025] Turning now to FIG. 1B, and by reference number 110, the application server device may send, and an application may receive, a challenge. The challenge may assert the identity of the application server device, and include a request for an attestation key, or an attestation certificate signed by a trusted source (i.e., the secure element), by which the application server device may attest to the identity and/or trusted state of the application. In some implementations, the application may not be allowed access to the application server device until the application responds, to the challenge, with the correct (expected) attestation key or signed attestation certificate. The application server device may send the challenge, using SSL/TLS protocols, when the application is opened, at runtime, periodically, simultaneous with a user logging into an application, upon initiation of a new application session by the user, during periods of increased threat-levels, and/or the like. For example, the application server device may generate and send a challenge to the application based on a time-based trigger (e.g., triggering a new challenge every few minutes, hours, etc.), or a session-based trigger (e.g., each time an application session is renewed or requested). In this way, the application may be regularly attested. The application server device may challenge the application for attestation at any time, as desired, in some cases).
As per claim 9: Hjelm in view of CACERES in further view of PARK discloses the computer-implemented method according to claim 8, wherein the service session key is randomly generated by the TEE for the target service (CACERES [0025] For example, the application server device may generate and send a challenge to the application based on a time-based trigger (e.g., triggering a new challenge every few minutes, hours, etc.), or a session-based trigger (e.g., each time an application session is renewed or requested). In this way, the application may be regularly attested. The application server device may challenge the application for attestation at any time, as desired, in some cases).
As per claim 13-19: Claims 13-19 are directed to non-transitory, computer-readable medium storing one or more instructions executable by a computer system to perform operations having substantially similar corresponding limitations of claims 1-7 respectively and therefore claims 13-19 are rejected with the same ratione given above to reject claims 1-7 respectively.
As per claim 20. Claim 20 is directed to a computer-implemented system, comprising: one or more computers; and one or more computer memory devices interoperable coupled with the one or more computers and having tangible, non-transitory, machine-readable media storing one or more instructions that, when executed by the one or more computers, perform one or more operations having substantially similar limitations of claim 1 and therefore claim 20 is reject with the same rationale given above to reject claim 1.:
Allowable Subject Matter
Claims 10-12 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims. The following is a statement of reasons for the indication of allowable subject matter: After thorough examination of the application, claims, and search, the pertinent prior arts of records, either taken alone or in combination neither anticipates nor renders obvious the following subject matter of claim 10 when combined and taken as a whole with claim 1.
claim 10: The computer-implemented method according to claim 1, further comprising: receiving, by the TEE from a service party, a request to perform a target service and service data corresponding to the target service; encrypting, by the TEE using the service session key, the device identity certificate of the terminal device and the service data to obtain service ciphertext information; encrypting, by the TEE using the service encryption key, the service session key to obtain a service session key ciphertext; sending, by the TEE to the service party, the service ciphertext information and the service session key ciphertext; sending, by the service party to a server, the service ciphertext information and the service session key ciphertext; decrypting, by the server using the service encryption key, the service session key ciphertext to obtain the service session key; decrypting, by the server using the service session key, the service ciphertext information to obtain the device identity certificate and the service data; performing, by the server, device identity authentication on the terminal device based on the device identity certificate; and in response to determining that the terminal device passes device identity authentication, processing the target service based on the service data.
Conclusion
The prior arts made of record and not relied upon are considered pertinent to applicant's disclosure. See the notice of reference cited in form PTO-892 for additional prior arts.
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.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TECHANE GERGISO whose telephone number is (571)272-3784. The examiner can normally be reached 9:30am to 6:30pm.
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, LINGLAN EDWARDS can be reached at (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 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.
/TECHANE GERGISO/ Primary Examiner, Art Unit 2408