DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office Action is in response to the Amendment filed on 03/18/2026.
In the instant Amendment: Claims 22-23, 29, 35-36, 38-39 have been amended, claims 25-28 have been cancelled. Claims 22-24, 29-39 have been examined and are pending. This Action is made FINAL.
Response to Arguments
Applicants’ arguments with respect to amended claims 1 has been considered but are moot in view of the new ground(s) of rejection. Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically discloses as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 22-24, 29-39 are rejected under 35 U.S.C. 103 as being unpatentable over Dees (“Dees,” 20230319549, published Oct. 5, 2023) in view of Metsala et al. (“Metsala,” US 20160057121, published Feb. 25, 2016).
Regarding claim 22, Dees discloses A method comprising:
transmitting, by a first user equipment (UE), a discovery request message (Dees [0200]. Also, the NRF may use preliminary UE subscription information to check whether the UE is allowed to operate in the slice(s) it requested. Note: because the UE did not authenticate yet with the core network at this point, and it only sent information related to its identity via the relay discovery request, which may be unauthenticated data (i.e. could be easily forged/changed), the NRF does not use this information to authenticate the UE.);
receiving, by the first UE, a discovery response message (Dees [0204]. Each relay UE that receives such message will then use the information from the message to send a discovery response back to the requesting UE, optionally containing the slice information (or other information from which the requesting UE can derive whether the relay UE can support relay communication for a requested slice), and optionally the information about other candidate relay UEs.);
transmitting, by the first UE to a second UE relaying the first UE (Dees [0177], [0205]. More specifically, a cellular communication system involves a mobile device UE0 operating as cellular communication User Equipment, a set S of relay devices {UE1, . . . UEn}, n>=1 operating as cellular communication User Equipment and further being capable of relaying network traffic from UE0 to/from a cellular communication system CCS capable of supporting relay operation and network slicing. Based on the received discovery responses it received from candidate relay UE, the UE can now select the best candidate relay UE to connect to, and then connects to it, e.g. by procedures similar to ProSe, and via Core Network procedures it connects to the requested slice(s) or the attainable subset thereof.),
a direct communication request message including information related to a procedure including an authentication (Dees [0351]. Step 2: Device UE0 sends a request message M (e.g. Direct Communication Request message or Discovery Request over PC5) that includes Relay Service Code RSC1 and may also include a payload/envelope V containing a layer-2 identifier or other identifier (e.g. GPSI/TMSI/IMSI/SUPI/SUCI/GUTI or signature/hash/security credential associated with relay device UE1 or indicative of the identity of relay device UE1) received from relay device UE1 during step 1 or through other means (e.g. an identifier received from/generated by an application running on device UE0, or a temporary ID received in step 0).); and
wherein, the procedure including the authentication is performed [over a user plane], based on that the information related to the procedure includes proximity-based service (ProSe) key management function (PKMF) address information (Dees [0357], [0373], [0398]. The CCS (e.g. using core network functions such as AMF together with the Authentication Server Function (AUSF), Unified Data Management (UDM) function, ProSe Key Management Function (PKMF)) may decrypt V or the encrypted identifiers and securely determine that the message N received from relay device UE1 in step 3 is related to UE0 and relay device UE1. To this end, the CCS may verify the integrity or authenticity of the secure envelope V and/or the contents of message N and/or correlate the decrypted identifiers with other identity information the CCS has stored about device UE0 and relay device UE1. In the above embodiment ID_Remote is sent without any additional encryption (i.e. the SUCI by itself is already encrypted by the Home Network public key), and may (after being forwarded by the relay device) be used by the CCS to identity the corresponding decryption key or select the correct AUSF, PCF, UDM, PKMF or other network service responsible for the Remote UE's authentication, provisioning/configuration, subscription, prose key management and other network services in the home or visiting network. For example, the CCS (e.g. acting as the relay device's AMF) may after selecting the correct AUSF/PCF/UDM/PKMF to provide the decryption key (e.g. derived from Kausf) for decrypting the encrypted value ENCRYPT(RSC|ID_Relay), or may ask the respective network service to decrypt the encrypted value ENCRYPT(RSC|ID_Relay). Its main steps are as follows: in Step 0, the CN, in particular, PKMF and DDNMF, provision remote UE and relay UE with parameters including discovery parameters, PKMF address, or discovery parameters.),
wherein, the procedure including the authentication is performed [over a control plane], based on that the information related to the procedure does not include the PKMF address information (Dees [0357], [0373], [0398]. The CCS (e.g. using core network functions such as AMF together with the Authentication Server Function (AUSF), Unified Data Management (UDM) function, ProSe Key Management Function (PKMF)) may decrypt V or the encrypted identifiers and securely determine that the message N received from relay device UE1 in step 3 is related to UE0 and relay device UE1. To this end, the CCS may verify the integrity or authenticity of the secure envelope V and/or the contents of message N and/or correlate the decrypted identifiers with other identity information the CCS has stored about device UE0 and relay device UE1. In the above embodiment ID_Remote is sent without any additional encryption (i.e. the SUCI by itself is already encrypted by the Home Network public key), and may (after being forwarded by the relay device) be used by the CCS to identity the corresponding decryption key or select the correct AUSF, PCF, UDM, PKMF or other network service responsible for the Remote UE's authentication, provisioning/configuration, subscription, prose key management and other network services in the home or visiting network. For example, the CCS (e.g. acting as the relay device's AMF) may after selecting the correct AUSF/PCF/UDM/PKMF to provide the decryption key (e.g. derived from Kausf) for decrypting the encrypted value ENCRYPT(RSC|ID_Relay), or may ask the respective network service to decrypt the encrypted value ENCRYPT(RSC|ID_Relay). Its main steps are as follows: in Step 0, the CN, in particular, PKMF and DDNMF, provision remote UE and relay UE with parameters including discovery parameters, PKMF address, or discovery parameters.),
wherein the information is provisioned in the first UE and the second UE (Dees [0338]. Device UE0 sends a message to a relay device UE1, the message including an (optionally encrypted) Relay Service Code RSC1, the Relay Service Code identifying or associated with a set of PDU session related attributes (such as PLMN ID (+NID/CAG ID), (temporary/encrypted) S-NSSAI, (temporary/encrypted) DNN, PDU session type, group IDs, QoS requirements (such as 5QI), frequencies, security context, etc), and further containing (e.g. as part of a secured envelope V) an (optionally encrypted) identifier of UE0, and an (optionally encrypted) identifier of UE1.).
Dees does not explicitly disclose: the procedure including the authentication is performed over a user plane, the procedure during authentication is performed over a control plane.
However, in an analogous art, Metsala discloses a method, comprising the steps of:
the procedure including the authentication is performed over a user plane (Metsala [0033], [0036], [0045]. 3GPP mandates the use of IPsec for protecting LTE backhaul. Similarly, IPsec may be used for the fronthaul. IPsec supports authentication of the endpoints (IKE and X.509v3 certificates), encryption, integrity and anti-replay protection. User plane traffic (L1 data stream) is encrypted by mobile (3GPP) air interface standards, both in LTE and HSPA, so the fronthaul is protected assuming that the functional split is such that this belongs to BB (PDCP layer in LTE) or even to RNC (PDCP layer of 3G HSPA). An exemplary selection logic may be as follows: 1) identifying and separating traffic types, e.g. user plane, control plane, synchronization plane, and management plane; 2) selecting a protection layer for each of the traffic types to be Ethernet layer, IP layer, or higher layer (e.g. via TLS); 3) selecting security policy for each traffic type, e.g. integrity protection, confidentiality protection, anti-replay protection, and selecting appropriate cryptographic algorithms.),
the procedure during authentication is performed over a control plane (Metsala [0047], [0084]-[0085]. This allows e.g. an architecture where the port is authenticated (network elements mutually authenticate with X.509v3 certificates). Network management traffic of AP (if existing) is protected, e.g. by TLS. The user plane traffic is not encrypted, due to 3GPP encryption. The control plane traffic is directed either into MACsec CA or into IPsec SA, and is thus cryptographically protected. The synchronization plane is not necessarily protected, or it may be integrity protected only. According to yet another exemplary embodiment, for Ethernet transport, control plane traffic is directed to the MACsec secure connectivity association CA. According to yet another exemplary embodiment, for IP transport, control plane traffic is directed to the IPsec security association.).
Therefore, it would have been obvious to one of ordinary skill in the art on or before the effective filing date of the claimed invention to combine teachings of Metsala and Dees to include the steps of: the procedure including the authentication is performed over a user plane, the procedure during authentication is performed over a control plane. One would have been motivated to provide user with a means for selecting encryption or authentication protocols for different classes of network traffic. (See Metsala [0045].)
Regarding claim 23, Dees and Metsala disclose the method of claim 22. Dees further discloses wherein the first UE supports performing the procedure including the authentication based on ProSe UE-to- network relay service (Dees [0222], [0240]. The mobile device first checks in its UE configuration if authorization doing this procedure is granted, by the ProSe Function, for out-of-coverage situations. If this is the case, it checks in its UE configuration if ProSe Function authorization for acting as an eRemote UE when out-of-coverage is granted. If that is also granted, it sends a PC5_DISCOVERY message on sidelink (SL) spectrum of type eRelay Discovery Solicitation to request nearby eRelay UEs (which may also be called eProSe UE-to-Network relay UEs) to respond with relay information. Also, the discovery message may include some information about the security context UE operates in or wishes to operate in, for example a slice specific security context, an encrypted credential provided by eNB, an encrypted PLMN session key, a security context identifier, a ProSe group ID or service ID and related group/service credential information.).
Regarding claim 24, Dees and Metsala disclose the method of claim 23. Dees further discloses wherein the information includes a relay service code related to the ProSe UE-to-network relay service (Dees [0049], [0222]. The Network Relay Function may be arranged to receive at least one transfer request message from the relay device, the transfer request message including a Relay Service Code (RSC1) and an identifier of the mobile device. The mobile device executes the role of eRemote UE in this procedure. The mobile device first checks in its UE configuration if authorization doing this procedure is granted, by the ProSe Function, for out-of-coverage situations. If this is the case, it checks in its UE configuration if ProSe Function authorization for acting as an eRemote UE when out-of-coverage is granted. If that is also granted, it sends a PC5_DISCOVERY message on sidelink (SL) spectrum of type eRelay Discovery Solicitation to request nearby eRelay UEs (which may also be called eProSe UE-to-Network relay UEs) to respond with relay information.).
Regarding claim 29, Dees and Metsala disclose the method of claim 22. Dees further discloses
the discovery request message includes the PKMF address information (Dees [0351], [0398]. Step 2: Device UE0 sends a request message M (e.g. Direct Communication Request message or Discovery Request over PC5) that includes Relay Service Code RSC1 and may also include a payload/envelope V containing a layer-2 identifier or other identifier. Solution 18 in TR 33.847 describes a protocol for authorization and PC5 link setup for UE-to-Network relay. Its main steps are as follows: in Step 0, the CN, in particular, PKMF and DDNMF, provision remote UE and relay UE with parameters including discovery parameters, PKMF address, or discovery parameters.);
wherein the first UE requests and receives a security key from a PKMF corresponding to the PKMF address information, wherein the authentication performed based on the received security key (Dees [0371], [0398]. The message N may include the nonces and the Message Authentication Code in the NAS Relay Authorization Request/Key Request. Upon receiving message N, the CCS (e.g. the AMF together with the AUSF/UDM/PKMF) may derive K_enc and K_int based on ID_Remote and the received nonces, and may check the integrity of message fields and decrypt the encrypted RSC and/or the encrypted value ENCRYPT(RSC|ID_Relay) to obtain the RSC and ID_Relay. Its main steps are as follows: in Step 0, the CN, in particular, PKMF and DDNMF, provision remote UE and relay UE with parameters including discovery parameters, PKMF address, or discovery parameters.).
Metsala further discloses
wherein, in case that the procedure including the authentication is performed over the user plane (Metsala [0033], [0036], [0045]. 3GPP mandates the use of IPsec for protecting LTE backhaul. Similarly, IPsec may be used for the fronthaul. IPsec supports authentication of the endpoints (IKE and X.509v3 certificates), encryption, integrity and anti-replay protection. User plane traffic (L1 data stream) is encrypted by mobile (3GPP) air interface standards, both in LTE and HSPA, so the fronthaul is protected assuming that the functional split is such that this belongs to BB (PDCP layer in LTE) or even to RNC (PDCP layer of 3G HSPA). An exemplary selection logic may be as follows: 1) identifying and separating traffic types, e.g. user plane, control plane, synchronization plane, and management plane; 2) selecting a protection layer for each of the traffic types to be Ethernet layer, IP layer, or higher layer (e.g. via TLS); 3) selecting security policy for each traffic type, e.g. integrity protection, confidentiality protection, anti-replay protection, and selecting appropriate cryptographic algorithms.).
The motivation is the same as that of claim 22 above.
Regarding claim 30, Dees and Metsala disclose the method of claim 29. Dees further discloses wherein the discovery request message further includes identification information of the first UE (Dee [0351]. Device UE0 sends a request message M (e.g. Direct Communication Request message or Discovery Request over PC5) that includes Relay Service Code RSC1 and may also include a payload/envelope V containing a layer-2 identifier or other identifier (e.g. GPSI/TMSI/IMSI/SUPI/SUCI/GUTI or signature/hash/security credential associated with relay device UE1 or indicative of the identity of relay device UE1) received from relay device UE1.).
Regarding claim 31, Dees and Metsala disclose the method of claim 29. Dees further discloses
wherein the direct communication request message includes security key-related information generated based on the security key (Dees [0351]-[0352]. Step 2: Device UE0 sends a request message M (e.g. Direct Communication Request message or Discovery Request over PC5) that includes Relay Service Code RSC1 and may also include a payload/envelope V containing a layer-2 identifier or other identifier (e.g. GPSI/TMSI/IMSI/SUPI/SUCI/GUTI or signature/hash/security credential associated with relay device UE1 [Note: signature is generated by a signing key]. The payload/envelope V may also contain a (unique) identifier of UE0 (e.g. GPSI/TMSI/IMSI/SUPI/SUCI/GUTI, or a temporary ID received in step 0). The Relay Service Code and/or payload/envelope V may be encrypted by a key derived from UE0's USIM.), and
wherein the second UE transmits a key request message including the security key- related information to the PKMF (Dees [0357]-[0358]. The CCS (e.g. using core network functions such as AMF together with the Authentication Server Function (AUSF), Unified Data Management (UDM) function, ProSe Key Management Function (PKMF)) may decrypt V or the encrypted identifiers and securely determine that the message N received from relay device UE1 in step 3 is related to UE0 and relay device UE1. To this end, the messages exchanged and/or the contents of the messages N and N′ may be combined with messages used for the authorization/relay security setup procedure (e.g. message N may be NAS Relay Authorization Request/Key Request message or similar message and/or the respective messages may be extended with fields to carry the encrypted relay service code or one or more of the encrypted identifiers received from Device UE0.).
Regarding claim 32, Dees and Metsala disclose the method of claim 29. Dees further discloses
wherein, based on the information related to a procedure including an authentication including default information as the PKMF address information (Dees [0398]-[0399], [0403]. Solution 18 in TR 33.847 describes a protocol for authorization and PC5 link setup for UE-to-Network relay. Its main steps are as follows: in Step 0, the CN, in particular, PKMF and DDNMF, provision remote UE and relay UE with parameters including discovery parameters, PKMF address, or discovery parameters. In Step 1, the remote UE performs the remote user key request and retrieves PRUK and PRUK ID from the PKMF. In Step 5, the relay forwards the freshness parameter to the remote UE. With these freshness parameters and the PRUK, the remote UE can generate the same K_NRP as received by the relay UE. K_NRP serves as basis for mutual authentication and security of the PC5 link.).
Metsala further discloses the procedure including the authentication is performed over the user plane (Metsala [0033], [0036], [0045]. 3GPP mandates the use of IPsec for protecting LTE backhaul. Similarly, IPsec may be used for the fronthaul. IPsec supports authentication of the endpoints (IKE and X.509v3 certificates), encryption, integrity and anti-replay protection. User plane traffic (L1 data stream) is encrypted by mobile (3GPP) air interface standards, both in LTE and HSPA, so the fronthaul is protected assuming that the functional split is such that this belongs to BB (PDCP layer in LTE) or even to RNC (PDCP layer of 3G HSPA). An exemplary selection logic may be as follows: 1) identifying and separating traffic types, e.g. user plane, control plane, synchronization plane, and management plane; 2) selecting a protection layer for each of the traffic types to be Ethernet layer, IP layer, or higher layer (e.g. via TLS); 3) selecting security policy for each traffic type, e.g. integrity protection, confidentiality protection, anti-replay protection, and selecting appropriate cryptographic algorithms.).
The motivation is the same as that of claim 29 above.
Regarding claim 33, Dees and Metsala disclose the method of claim 29. Dees further discloses
wherein, based on the PKMF address information being the default information, the discovery request message includes the default information, and the discovery request message is transmitted to a direct discovery name management function (DDNMF) (Dees [0351], [0398], [0403]. Step 2: Device UE0 sends a request message M (e.g. Direct Communication Request message or Discovery Request over PC5) that includes Relay Service Code RSC1 and may also include a payload/envelope V containing a layer-2 identifier or other identifier. Solution 18 in TR 33.847 describes a protocol for authorization and PC5 link setup for UE-to-Network relay. Its main steps are as follows: in Step 0, the CN, in particular, PKMF and DDNMF, provision remote UE and relay UE with parameters including discovery parameters, PKMF address, or discovery parameters. In Step 5, the relay forwards the freshness parameter to the remote UE. With these freshness parameters and the PRUK, the remote UE can generate the same K_NRP as received by the relay UE. K_NRP serves as basis for mutual authentication and security of the PC5 link.), and
wherein valid PKMF address information is derived by the DDNMF and is delivered to the first UE (Dees [0398]-[0400], [0403]. Its main steps are as follows: in Step 0, the CN, in particular, PKMF and DDNMF, provision remote UE and relay UE with parameters including discovery parameters, PKMF address, or discovery parameters. In Step 1, the remote UE performs the remote user key request and retrieves PRUK and PRUK ID from the PKMF. In Step 2, the discovery procedure is performed, e.g. based on TS 33.303 or as in Solutions 3 and 4 in TR 33.847. In Step 5, the relay forwards the freshness parameter to the remote UE. With these freshness parameters and the PRUK, the remote UE can generate the same K_NRP as received by the relay UE. K_NRP serves as basis for mutual authentication and security of the PC5 link.).
Regarding claim 34, Dees and Metsala disclose the method of claim 29. Dees further discloses wherein the first UE requests and receives a security key from a PKMF corresponding to the valid PKMF address information delivered from the DDNMF and the procedure including the authentication based on the received security key (Dees [0398]-[0399], [0403]. Solution 18 in TR 33.847 describes a protocol for authorization and PC5 link setup for UE-to-Network relay. Its main steps are as follows: in Step 0, the CN, in particular, PKMF and DDNMF, provision remote UE and relay UE with parameters including discovery parameters, PKMF address, or discovery parameters. In Step 1, the remote UE performs the remote user key request and retrieves PRUK and PRUK ID from the PKMF. In Step 5, the relay forwards the freshness parameter to the remote UE. With these freshness parameters and the PRUK, the remote UE can generate the same K_NRP as received by the relay UE. K_NRP serves as basis for mutual authentication and security of the PC5 link.).
Regarding claim 35, Dees and Metsala disclose the method of claim 22. Dees further discloses wherein, in case that the procedure including the authentication is performed over the control plane, the discovery response message includes discovery-related information, and the procedure including the authentication is performed based on the discovery-related information (Dees [0360], [0367]. Relay device UE1 sends a response message M′ (e.g. a Direct Communication Response message or Direct Discovery Response message over PC5 or by forwarding message N′) to UE0, containing the encrypted RSC2 received as part of message N′ by relay device UE1 in step 5. the cellular communication system CCS only sends a message N′ containing an encrypted Relay Service Code RSC2 or PDU session information related to RSC1 to relay device UE1 if the output of decrypting the received secure envelope V or the received encrypted identifiers reveals an identifier of relay device UE1 or the Message Authentication Code as forwarded by the relay device and originating from UE0 reveals that the identifiers have not been manipulated.).
Regarding claim 36, Dees and Metsala disclose the method of claim 35. Dees further discloses
generating, by the first UE, a subscription concealed identifier (SUCI) through the identification information of the first UE based on the discovery response message, wherein the direct communication request message includes the SUCI to the second UE (Dees [0095], [0204]. In an aspect, the request message and response message include a Global Unique Temporary Identifier (GUTI) or Temporary Mobile Subscriber Identity (TMSI) or Subscription Concealed Identifier (SUCI). Each relay UE that receives such message will then use the information from the message to send a discovery response back to the requesting UE, optionally containing the slice information (or other information from which the requesting UE can derive whether the relay UE can support relay communication for a requested slice), and optionally the information about other candidate relay UEs.).
Regarding claim 37, Dees and Metsala disclose the method of claim 29. Dees further discloses
wherein the second UE transmits an NAS relay authentication request message including the SUCI to an access and mobility management function (AMF) of the second UE (Dees [0188], [0352], [0358]. In the CCS a Network Relay Function (NRF) is provided. The base station may be communicatively coupled to an Access and Mobility Management Function (AMF) in the CN. The key used for encryption may also be the same key as identified by the Home Network Public Key Identifier of the SUCI of the Remote UE. To this end, the messages exchanged and/or the contents of the messages N and N′ may be combined with messages used for the authorization/relay security setup procedure (e.g. message N may be NAS Relay Authorization Request/Key Request message or similar message and/or the respective messages may be extended with fields to carry the encrypted relay service code or one or more of the encrypted identifiers received from Device UE0.),
wherein the AMF of the second UE checks whether a relay role of the second UE is authenticated and transmits an authentication request message to an authentication server function (AUSF) of the first UE based on the SUCI (Dees [0351], [0371]. Step 2: Device UE0 sends a request message M (e.g. Direct Communication Request message or Discovery Request over PC5) that includes Relay Service Code RSC1 and may also include a payload/envelope V containing a layer-2 identifier or other identifier (e.g. GPSI/TMSI/IMSI/SUPI/SUCI/GUTI or signature/hash/security credential associated with relay device UE1 or indicative of the identity of relay device UE1) received from relay device UE1 during step 1 or through other means (e.g. an identifier received from/generated by an application running on device UE0, or a temporary ID received in step 0). The message N may include the nonces and the Message Authentication Code in the NAS Relay Authorization Request/Key Request. Upon receiving message N, the CCS (e.g. the AMF together with the AUSF/UDM/PKMF) may derive K_enc and K_int based on ID_Remote and the received nonces, and may check the integrity of message fields and decrypt the encrypted RSC and/or the encrypted value ENCRYPT(RSC|ID_Relay) to obtain the RSC and ID_Relay. The CCS also may verify if the ID_Relay matches the identity of the UE-to-Network Relay from which the message was received, before continuing with subsequent procedures.).
Regarding claim 38, claim 38 corresponds to a first user equipment corresponding to the system of claim 22. Claim 38 is similar in scope to claim 22 and is therefore rejected under similar rationale.
Regarding claim 39, claim 39 corresponds to a second user equipment corresponding to the system of claim 22. Claim 39 is similar in scope to claim 22 and is therefore rejected under similar rationale.
Conclusion
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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to EDWARD LONG whose telephone number is (571)272-8961. The examiner can normally be reached on Monday to Friday, 9 AM - 6 PM EST (Alternate Fridays).
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Luu Pham can be reached on (571) 270-5002. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system.
Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only.
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/EDWARD LONG/
Examiner, Art Unit 2439
/LUU T PHAM/ Supervisory Patent Examiner, Art Unit 2439
Prosecution Insights