DETAILED ACTION
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 .
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1, 11 and 42 are rejected under 35 U.S.C. 102(a)(1) as being anticipated over Rajadurai et al. (US 12335727 B2, hereinafter Rajadurai)
Regarding Claim 1, Rajadurai teaches the method comprising:
transmitting authentication and authorization information to an edge configuration server (ECS) (Rajadurai [Col.7, lines 30-37, FIG. 4A] The UE 101 sends an initial provisioning request message to the ECS 110. In this scenario, the UE 101 acts as an AKMA client and the ECS 110 acts as an Application Function (AF) for the AAnF 106 (as defined in 3GPP specifications). Therefore, the UE 101 includes the AKMA Key ID and generates MAC-I over the initial provisioning request message using the key K.sub.ECS to prove its authenticity.);
wherein the authentication and authorization information is configured to request a token for service authorization.(Rajadurai [Col. 9, line 50-51] The AAnF 106 issues EES tokens and provides the EES tokens to the ECS 110. [FIG. 3])
Regarding Claim 11, Rajadurai teaches the method comprising:
receiving authentication and authorization information transmitted by an edge enabler client (EEC)(Rajadurai [Col. 5Lines 33-36] On receiving the MAC-I from the UE, the server (for example, ECS) also generates the message authentication code using the security credential in its possession for the UE.);
wherein the authentication and authorization information is configured to request a token for service authorization(Rajadurai [Col. 10, lines 65-67 and Col. 11, line 1] The validation of the MEC service registration request, received from the EEC 103, is performed by verification of the EES token issued by the ECS 110 to the UE 101.)
Regarding Claim 42, Rajadurai teaches
A communication device, comprising:
a memory; and
one or more processors connected to the memory,
and configured to of implementing the method according to claim 1, by executing a computer-executable instruction stored in the memory (Rajadurai [Col. 6, lines 12-15] The Modem 104 in the UE 101 can store network access security credentials such as subscription credentials or User Services Identity Module (USIM) credentials (credentials stored in the memory of the USIM), [Col. 25, lines 5-6] at least one microprocessor and at least one memory
Claim 31 is rejected under 35 U.S.C. 35 U.S.C. 102(a)(1) as being anticipated over CHAO (CN101729998A, hereinafter Chao)
Regarding Claim 31, Chao teaches the method comprising:
receiving application request information transmitted by an ECS (Chao [0108] The authentication center 201, network application server 201, and Zn interface proxy server (Zn-Proxy) 203 belong to the home network of user equipment 206.
[0184] After receiving the authentication request, Zn-Proxy forwards the authentication request to the UE's visiting BSF based on the actual domain name of the visited BSF server carried in the authentication request.);
wherein the application request information comprises at least one of the following:
a B-TID received by the ECS;
a network application function (NAF) identifier (ID) (Chao [0145] If the NAF needs to authenticate the UE, it returns an HTTP 401 Unauthorized message containing a WWW-Authenticate header, indicating that the UE needs to undergo the authentication process.)
(Note: According to the definition of NAF ID, it can be tied to the application-specific interface the NAF uses with the US (e.g. HTTP/HTTPS endpoint.); and
a key type indicator.
(Note: Claim language requires examiner to find at least one limitation in the reference citation. Examiner has elaborated one and that is considered to be sufficient.)
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 2-3, 5, 7-8, 15 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Rajadurai et al. (US 12335727 B2, hereinafter Rajadurai) and in view of Guo et al. (US 20230276231 A1, hereinafter Guo)
Regarding Claim 2 and as applied to Claim 1, Rajadurai fail to teach
receiving the token transmitted by the ECS.
However, in a similar endeavor, Guo teaches
receiving the token transmitted by the ECS(Guo [0117, lines 4-5] an ECS may provide a token to the UE upon verifying the EEC (e.g., in 606a and/or 606c))
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the examined application to have modified Rajdurai and by incorporating Guo to have the ECS receive the token for service authorization.
The motivation of doing so would have enabled a secure connection process.
Regarding Claim 3, the combination of Raidurai and Guo teach the method of claim 2,
wherein the receiving the token transmitted by the ECS comprises:
receiving, through a transport layer security (TLS) connection, the token transmitted by the ECS (Rajadurai [Col. 7, lines 24-27] Step 2B: The EEC 110 can establish a Secure Sockets Layer (SSL) or a Transport Layer Security (TLS) session with the ECS 110, for securing the communication between the UE 101 and the ECS 110.)
wherein the token comprises at least one of the following:
a fully qualified domain name (FODN) of the edge configuration server (ECS);
an EEC identifier (ID);
a generic public subscription identifier (GPSI) (Rajadurai [Col. 18, lines 34-36] The AAF 901 can derives the edge authentication key (K.sub.ECS) using at least one of an edge key (K.sub.EDGE) and a Generic Public Subscription Identifier (GPSI)).
an expected edge enabler server (EES) service name;
an FODN of an EES;
effective time;
and a digital signature.
(Note: Claim language requires examiner to find at least one limitation in the reference citation. Examiner has elaborated one and that is considered to be sufficient.)
Regarding Claim 5, Rajadurai teaches the method according to claim 1, but fails to teach
wherein the authentication and authorization information comprises at least one of the following:
a bootstrapping transaction identifier (B-TID);
an encrypted EEC ID;
a key type indicator;
a generic public subscription identifier (GPSI); and
a message authentication code.
However, in a similar endeavor, Guo teaches
wherein the authentication and authorization information comprises at least one of the following:
a bootstrapping transaction identifier (B-TID);
an encrypted EEC ID;
a key type indicator;
a generic public subscription identifier (GPSI); and
a message authentication code (Guo [0007, lines 6-7] first authentication code for a first edge enabler client (EEC) operating at the UE).
(Note: Claim language requires examiner to find at least one limitation in the reference citation. Examiner has elaborated one and that is considered to be sufficient.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the examined application to have modified Rajdurai and by incorporating Guo to have the authentication and authorization information contain a message authentication code.
The motivation of doing so would have enabled the system to have a secured connection.
Regarding Claim 7 the combination of Raidurai and Guo teach the method of claim 5.
wherein the message authentication code is a message authentication code for integrity (MAC-I) determined based on KECS and is configured to protect integrity of the B-TID, the encrypted EEC ID, the GPSI and/or the key type indicator (Rajadurai [Col. 17, lines 3-7] The MAC-I is generated by the UE 101 using the initial provisioning request message and the key K.sub.ECS to prove its authenticity. The B-TID is used to bind the subscriber identity to the keying material in reference points Ua, Ub and Zn.
[Col. 19, lines 50-54] Step 2B: The UE 101 can send an initial provisioning request to the ECS 110. The initial provisioning request comprises at least one of: an AKMA key ID, B-TID, MAC-I, and GPSI.)
The motivation of doing so would ensure the integrity of the system.
Regarding Claim 8 Rajadura teaches the method according to claim 1, but fails to teach
obtaining a B-TID from a bootstrapping server function (BSF) of a home network during running of a generic bootstrapping architecture;
But in a similar endeavor, Guo teaches
obtaining a B-TID from a bootstrapping server function (BSF) of a home network during running of a generic bootstrapping architecture (Guo [0138, lines 3-5] The BSF may also generate a B-TID value in format of NAI, e.g., based on the RAND value from step 3, and the BSF server name.)
determining a key KEEC-ECS based on a key KECs and an EEC identifier (ID)(Guo [0113, lines 4-9] For example, the for an ECS (e.g., in 606a and/or 606c), the key (e.g., K.sub.ECS1) may be based on K.sub.ECS0 and the identifier of the EEC (e.g., EEC ID). Similarly, for an EES (e.g., in 606b and/or 606d), the key (e.g., K.sub.EES1) may be based on K.sub.EES0 and the identifier of the EEC (e.g., EEC ID)).
(Note: Claim language requires examiner to find at least one limitation in the reference. Examiner has elaborated two and that is considered to be sufficient.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the examined application to have modified Rajdurai and by incorporating Guo to obtain B-TID from BSF.
The motivation of doing so would have enabled a secure EEC–ECS trust establishment.
And Rajadurai, further, teaches
executing mutual identity authentication (Rajadurai (Col. 10, lines 51-54] At Step 2L, the ECS 110 sends the EES token to the UE 101 in a secure way (the token is encrypted using K.sub.AKMA key or other derived keys or secured by the established TLS/SSL)).
and/or establishment of a transport layer security (TLS) connection between the EEC and the ECS based on the key KEEC-ECS.
(Note: Claim language requires examiner to find at least one limitation in the reference citation. Examiner has elaborated one and that is considered to be sufficient.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the examined application to have modified Guo and by incorporating Rajadurai for the system to have mutual identity authentication.
The motivation of doing so would have enabled an efficient identity authentication.
Regarding Claim 15 Rajadurai teaches the method according to claim 11, but fails to teach
in response to receiving the authentication and authorization information, determining a network to which the ECS is connected;
in response to determining that an identifier of the network to which the ECS is connected
However, in a similar endeavor Guo teaches
in response to receiving the authentication and authorization information, determining a network to which the ECS is connected (Guo [0097, lines 3-5] The EAS(s), the EES(s), and the ECS(s) may interact with a network such as a 3GPP core network.)
in response to determining that an identifier of the network to which the ECS is connected (Guo [0099, lines 1-3] An edge server such as an ECS and/or EES may include one or more network interface operably coupled to one or more processors, according to some embodiments.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the examined application to have modified Rajadurai and by incorporating Guo to determine the network where ECS connected.
The motivation of doing so would have enabled a secure and trusted connection.
In a similar endeavor, Rajadurai, further, teaches
is identical to an identifier of a public land mobile network of the EEC that is configured to establish a connection to the ECS, and the identifier of the public land mobile network of the EEC that is configured to establish a connection to the ECS is different from a home network identifier of the EEC, establishing a connection to the network to which the ECS is connected (Rajadurai [Col. 6, lines 38-44] This embodiment is represented in the architecture depicted in FIG. 1. In this embodiment the AAnF (AKMA Anchor Function) 106 is configured to manage security credentials creation, distribution and management. The AAnF 106 in a part of the Home Public Land Mobile Network (HPLMN).
[Col. 17, line 38-48] As depicted in FIG. 9, the architecture comprises the UE 101, the 3GPP network 105, the EDN 109, and the ECS 110. The UE 101 comprises at least one application client 102, the EEC 103, and the Modem 104. The at least one application client 102 can refer to at least one edge application installed in the UE 101. The 3GPP network 105 in the architecture can be a 5G network with SA architecture or NSA architecture. The 3GPP network 105 includes an Authentication and Authorization Function (AAF) 901, an AUSF 107, and a Home Subscriber System (HSS) 902 or a UDM 108.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the examined application to have modified Guo and by incorporating Rajadurai to have the system a public land mobile network as an EEC to connect with ECS.
The motivation of doing so would have enabled a secure and trusted connection in a roaming authorization in visited PLMN scenarios
Regarding Claim 17, the combination of Rjadurai and Guo teach the method of claim 15,
further comprising at least one of the following:
determining the home network identifier of the EEC based on a B-TID (Rajadurai [Col. 17, lines 8-9] (105) The ECS 110 contacts the BSF 701 (using B-TID) to obtain the key K.sub.ECS (K.sub.S-NAF) generated by the UE 101.
[Col. 6, lines 42-43] The AAnF 106 in a part of the Home Public Land Mobile Network (HPLMN).
Rajadurai [Col. 16, line 67, Col. 17, line 1] The UE 101 includes a Bootstrapping Transaction Identifier (B-TID));
and obtaining the identifier
and/or an access type of the public land mobile network of the EEC that is configured to establish a connection to the ECS from a policy control function (PCF)
(Note: Claim language requires examiner to find at least one limitation in the reference citation. Examiner has elaborated one and that is considered to be sufficient.)
The motivation of doing so would link request to bootstrapping context.
Claims 19-22, 27 and 29 are rejected under 35 U.S.C. 103 as being unpatentable over Rajadurai et al. (US 12335727 B2, hereinafter Rajadurai) and in view of Guo et al. (US 20230276231 A1, hereinafter Guo) and in further view of CHAO (CN101729998A, hereinafter Chao)
Regarding Claim 19, the combination of Rjadurai and Guo teach the method of claim 15, but fail to teach
transmitting application request information to a Zn-Proxy in a home network of the EEC; wherein the application request information comprises at least one of the following:
a B-TID received by the ECS;
a network application function (NAF) identifier (ID); and
a key type indicator.
However, in a similar endeavor, Chao teaches
transmitting application request information to a Zn-Proxy in a home network of the EEC(Chao [0108] The authentication center 201, network application server 201, and Zn interface proxy server (Zn-Proxy) 203 belong to the home network of user equipment 206.);
wherein the application request information comprises at least one of the following:
a B-TID received by the ECS;
a network application function (NAF) identifier (ID)(Chao [0006] The system includes: Authentication Centre (AuC), Bootstrapping Service, User Equipment (UE), Zn-Proxy, and Network Application Function (NAF)) ; and
a key type indicator.
(Note: Claim language requires examiner to find at least one limitation in the reference citation. Examiner has elaborated one and that is considered to be sufficient.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the examined application to have modified the combination of Rajudrai and Guo and by incorporating Chao to have the system transmit application request information to a Zn-Proxy in a home network
The motivation of doing so would have enable an efficient system of communication in roaming cases.
Regarding Claim 20, the combination of Rjadurai, Guo, and Chao teaches the method of claim 19 and Chao further teaches
receiving application response information transmitted by the Zn-Proxy (Chao [0165] If the visiting BSF and the NAF that needs to authenticate the UE are located in different areas, the area Zn-Proxy of the roaming area needs to be used to forward the request for GBA-related key data of the NAF in the area to the visiting BSF. A secure information transmission method should be used between the area Zn-Proxy and the visiting BSF, such as carrying on the Transport Layer Security (TLS) protocol.),
wherein the application response information comprises a key KECS (Rajadurai [Col. 17, lines 3-7] The MAC-I is generated by the UE 101 using the initial provisioning request message and the key K.sub.ECS to prove its authenticity. The B-TID is used to bind the subscriber identity to the keying material in reference points Ua, Ub and Zn.)
and/or effective time information of the key KEcs.
(Note: Claim language requires examiner to find at least one limitation in the reference citation. Examiner has elaborated one and that is considered to be sufficient.)
The motivation of doing so would have enabled a secure and efficient authentication process.
Regarding Claim 21, the combination of Rjadurai, Guo, and Chao teaches the method of claim 20,
further comprising
verifying integrity of the authentication and authorization information based on the key KECS and/.
or an MAC-I (Rajadurai [Col. 7, Lines 39-44] The key K.sub.ECS is used by the ECS 110 to verify the MAC-I generated by the UE 101 (sent by the UE 101 along with the initial provisioning request message) and provide a provisioning response. Once the MAC-I is verified by the ECS 110, the ECS 110 provides an initial provisioning response for authenticating the UE 101.)
Regarding Claim 22, the combination of Rjadurai, Guo, and Chao teaches the method of claim 21, and Rajadurai further teaches
wherein the verifying integrity of the authentication and authorization information based on the key KECS and/orMAC- I comprises: generating the MAC-I based on the key KEcs and the authentication and authorization information (Rajadurai [Col. 17, lines 3-5] The MAC-I is generated by the UE 101 using the initial provisioning request message and the key K.sub.ECS to prove its authenticity.);
comparing the generated MAC-I with an MAC-I of the authentication and authorization information (Rajadurai [Col. 19, lines 59-61] The K.sub.ECS key is provided to the ECS 110, wherein the ECS 110 validates the MAC-I generated by the UE 101 using K.sub.ECS.);
in response to determining that the generated MAC-I is consistent with the MAC-I of the authentication and authorization information, determining that the authentication and authorization information is not modified(Rajadurai (Col. 20, lines 8-14] Once the EES-1 (111) obtains the key K.sub.EES-1 from the ECS 110 (ECS 110 generates the K.sub.EES-1 in same way as the UE 101 using the K.sub.ECS), the EES-1 (111) validates the MAC-I (by generating MAC-I using the key K.sub.EES-1 (or keys generated further using K.sub.EES-1) and the received MEC registration request message).
[Col. 19, lines 18-23] The architecture is applicable for providing MEC services to the UE 101 through a 5G NSA architecture. The UE 101 can directly connect with the ECS 110, the EES 111, and the EAS 112, once the UE 101 has been authenticated using 3GPP network access security credentials of the UE 101. The embodiment does not require introducing modifications in AKMA or GBA entities to generate the application keys.);
or, in response to determining that the generated MAC-I is inconsistent with the MAC-I of the authentication and authorization information, determining that the authentication and authorization information is modified.
(Note: Claim language requires examiner to find at least one limitation in the reference citation. Examiner has elaborated one and that is considered to be sufficient.)
Regarding Claim 27, the combination of Rjadurai, Guo, and Chao teaches the method of claim 20 further comprising:
in response to determining that the mutual identity authentication succeeds and the TLS connection is established between the EEC and the ECS, generating the token for the EEC to request the service authorization (Rajadurai [Col. 7, lines 24-27] Step 2B: The EEC 110 can establish a Secure Sockets Layer (SSL) or a Transport Layer Security (TLS) session with the ECS 110, for securing the communication between the UE 101 and the ECS 110.);
transmitting the token to the EEC (Rajadurai [Col. 10, lines 52-54] ECS 110 sends the EES token to the UE 101 in a secure way (the token is encrypted using K.sub.AKMA key or other derived keys or secured by the established TLS/SSL)).
Regarding Claim 29, the combination of Rjadurai, Guo, and Chao teaches the method of claim 27, wherein the transmitting the token to the EEC comprises:
transmitting the token to the EEC through the TLS connection (Rajadurai [Col. 10, lines 52-54] ECS 110 sends the EES token to the UE 101 in a secure way (the token is encrypted using K.sub.AKMA key or other derived keys or secured by the established TLS/SSL)),
wherein the token comprises at least one of the following:
a fully qualified domain name (FQDN) of the ECS;
the EEC identifier (ID);
a GPSI (Rajadurai [Col. 18, lines 34-36] The AAF 901 can derives the edge authentication key (K.sub.ECS) using at least one of an edge key(K.sub.EDGE) and a Generic Public Subscription Identifier (GPSI)).
an expected EES service name;
an FQDN of an EES;
effective time; and a digital signature.
(Note: Claim language requires examiner to find at least one limitation in the reference citation. Examiner has elaborated one and that is considered to be sufficient.)
Claim 23 is rejected under 35 U.S.C. 103 as being unpatentable over Rajadurai et al. (US 12335727 B2, hereinafter Rajadurai) and in view of Guo et al. (US 20230276231 A1, hereinafter Guo) and CHAO (CN101729998A, hereinafter Chao) and in further view of Kunz et al. (US 20230199483 A1, hereinafter Kunz)
Regarding Claim 23, the combination of Rjadurai, Guo, and Chao teaches the method of claim 21, but Rajadurai, Guo and Chao fail to teach
in response to determining that the authentication and authorization information is modified, terminating an authentication and authorization process; or,
in response to determining that the authentication and authorization information is not modified, decrypting an encrypted EEC ID received by the ECS.
However, in a similar endeavor, Kunz teaches
in response to determining that the authentication and authorization information is modified, terminating an authentication and authorization process; or,
in response to determining that the authentication and authorization information is not modified, decrypting an encrypted EEC ID received by the ECS. (Kunz [0003, lines 13-15] In certain embodiments, the method includes transmitting a response message to the edge server function. The response message includes: the K.sub.AFEEC; and an unencrypted EEC-ID.g an encrypted EEC ID received by the ECS.)
(Note: Claim language requires examiner to find at least one limitation in the reference citation. Examiner has elaborated one and that is considered to be sufficient.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the examined application to have modified the combination of Rajadurai, Guo, Chao and by incorporating Kunz to have the system decrypt an encrypted EEC ID.
The motivation of doing so would have enabled the secure authentication process.
Claim 24 is rejected under 35 U.S.C. 103 as being unpatentable over Rajadurai et al. (US 12335727 B2, hereinafter Rajadurai) and in view of Guo et al. (US 20230276231 A1, hereinafter Guo), CHAO (CN101729998A, hereinafter Chao), Kunz et al. (US 20230199483 A1, hereinafter Kunz) in further view of Kobayashi (US 11082225 B2, hereinafter Kobayashi)
Regarding Claim 24 the combination of Rjadurai, Guo, Chao and Kunz teach the method of claim 23 further comprising:
based on the decrypted EEC ID, determining whether the EEC is authorized to execute a configuration request operation according to a predetermined policy (Rajadurai [Col. 8, lines 64-67] In order to avail MEC services from the EAS-B (112), the UE 101 can generate an EAS access key based on the security policy.)
But Rajadurai, Guo, Chao and Kunz fail to teach
in response to determining that the EEC is not authorized to execute the configuration request operation an authentication and authorization request operation, terminating the configuration request authentication and authorization process.
However, in a similar endeavor, Kobayashi teaches
in response to determining that the EEC is not authorized to execute the configuration request operation an authentication and authorization request operation, terminating the configuration request authentication and authorization process (Kobayashi [Col. 16, lines 8-12] a configuration may also be used where an error occurs in the token provider 440 when the number of times of execution exceeds a certain value or when a certain period of time elapses, whereby the processing is terminated.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the examined application to have modified the combination of Rajadurai, Guo, Chao, Kunz and by incorporating Chao to have the system terminating authentication process when determined that EEC is not authorized to communicate.
The motivation of doing so would have enabled a secure system with reliability of communication.
Claim 35 rejected under 35 U.S.C. 103 as being unpatentable over CHAO (CN101729998A, hereinafter Chao) in view of Rajadurai et al. (US 12335727 B2, hereinafter Rajadurai)
Regarding Claim 35, Chao teaches the method according to claim 31, but fails to teach
Receiving], by a bootstrapping server function (BSF), the application request
information transmitted by the Zn-Proxy;
determining a key KECS based on the application request information; and
transmitting application response information to the Zn-Proxy, wherein the
application response information comprises the key KECS and/ or effective time information of the key KECS.
However, in a similar endeavor, Rajadurai teaches
Receiving , by a bootstrapping server function (BSF), the application request
information transmitted by the Zn-Proxy;
determining a key KECS based on the application request information; and
transmitting application response information to the Zn-Proxy, wherein the
application response information comprises the key KECS (Rajadurai (104) The B-TID is used to bind the subscriber identity to the keying material in reference points Ua, Ub and Zn.
(102) (102) Step 1A: At the end of the GBA Bootstrapping procedures, the UE 101 and the BSF 701 are in possession of a key K.sub.S. The UE 101 derives the key K.sub.ECS (edge authentication key), for availing MEC service, based on ECS 110 specific parameters (such as Network Application Function (NAF) Identity (ID))) and/or effective time information of the key KECS.
(Note: Claim language requires examiner to find at least one limitation in the reference citation. Examiner has elaborated one and that is considered to be sufficient.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the examined application to have Chao and by incorporating Chao to have to determine KECS and Zn-Proxy integrity in place.
The motivation of doing so would have enabled a secure system with reliability of communication.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RANA HASSAN MAHMUD whose telephone number is (571)272-8939. The examiner can normally be reached Mon-Friday.
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, Kathy Wang-Hurst can be reached at 5712705371. 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.
/RANA H MAHMUD/Examiner, Art Unit 2644
/SAID M ELNOUBI/Examiner, Art Unit 2644
Prosecution Insights