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 .
DETAILED ACTION
Response to Amendment
This office action is in response to applicant’s amendment filed, 01 June 2026, of application filed, with the above serial number, on 11 October 2023 in which claims 1, 14, 25-27, 29 have been amended. Claims 1-3, 5-6, 8, 10, 14, 16-19, 21, 23, 25-30 are pending in the application. It is noted the amendment to claim 25 contains unmarked claim amendments, see at least claims filed 1/26/26 claim 25 limitation a) with current amendment. It is therefore not clear on the status of claim 25 nor the current text of the claims. The amendments to claim 25 are partially incorporated herein below to the best of the Examiner’s ability in order to advance prosecution.
Information Disclosure Statement
The information disclosure statement filed 27 July 2026 fails to comply with the provisions of 37 CFR 1.97, 1.98 and MPEP § 609 because 37 CFR 1.98(a)(3) applies to the NPL on the IDS. It has been placed in the application file, but the information referred to therein has not been considered as to the merits. Applicant is advised that the date of any re-submission of any item of information contained in this information disclosure statement or the submission of any missing element(s) will be the date of submission for purposes of determining compliance with the requirements based on the time of filing the statement, including all certification requirements for statements under 37 CFR 1.97(e). See MPEP § 609.05(a).
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(d):
(d) REFERENCE IN DEPENDENT FORMS.—Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
The following is a quotation of pre-AIA 35 U.S.C. 112, fourth paragraph:
Subject to the following paragraph [i.e., the fifth paragraph of pre-AIA 35 U.S.C. 112], a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
Claim 6, 19 is rejected under 35 U.S.C. 112(d) or pre-AIA 35 U.S.C. 112, 4th paragraph, as being of improper dependent form for failing to further limit the subject matter of the claim upon which it depends, or for failing to include all the limitations of the claim upon which it depends. Claim 6 depends from claim 1 and does not appear to further narrow claim 1 as amended as the second network function is claimed in claim 1 to be the SMF. Claim 1 does not define the third network function, but as the limitations are in alternative limitations, the second network function SMF performing claim 1 and 6 does not further define claim 1. Claim 19 is similarly rejected with claim 14. Applicant may cancel the claim(s), amend the claim(s) to place the claim(s) in proper dependent form, rewrite the claim(s) in independent form, or present a sufficient showing that the dependent claim(s) complies with the statutory requirements.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-3, 5-6, 8, 10, 14, 16-19, 21, 23, 25-30 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. The claims are amended to add “receiving, from one of the second network function and a third network function, on a per network function basis via a DNS configuration management procedure, DNS configuration information of the network” and related “applying the DNS configuration information received on the per network function basis and the serving DNS information to process at least one subsequent DNS query received from at least one UE for edge application server (EA) discovery, without transmitting a request to the SMF per each such DNS query”. It is not clear what is being claimed ‘on a per network function basis’ as what is received is from one or the 2nd or 3rd network function. Thus, what may be received is dependent on the network function but the claim recites only receiving from one of the 2nd or 3rd NF, thus only one DNS configuration information is received and the ‘per network function basis’ does not appear to have any impact on what is claimed.
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.
Claim(s) 1-3, 5-6, 8, 10, 14, 16-19, 21, 23, 25-26 is/are rejected under 35 U.S.C. 102a1 as being anticipated by 3GPP TS 23.548 V0.1.0 (2021-03) Technical Specification 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 5G System Enhancements for Edge Computing; Stage 2 (Release 17) (hereinafter “3GPP TS 23.548”).
As per Claim 1, 3GPP TS 23.548 discloses a method performed by a first network function comprising an edge application server discovery function (EASDF) of a network, the method comprising:
receiving, from a second network function comprising a session management function (SMF) of the network, serving domain name service (DNS) information which indicates a first condition for handling DNS messages forwarding for a protocol data unit (PDU) session, the first condition being at least one of: (i) a current service area associated with one of a DNS server or a data network access identifier (DNAI) of a PDU session anchor (PSA) user plane function (UPF) providing an up path for supported fully qualified domain names (FQDNs) for the PDU session; or (ii) a DNAI of a PSA UPF providing an up path for supported FQDNs for the PDU session (at least section 6.2.3.2.2; DNS query from UE sent to SMF to select EASDF with FQDN and candidate DNAI(s); During the PDU Session establishment procedure, the SMF selects an EASDF and provides its address to the UE as the DNS Server to be used for the PDU Session; SMF may configure the EASDF with DNS message handling rules to forward DNS messages of the UE and/or report when detecting DNS messages. The DNS message reporting rule may include DNS message type (i.e. DNS Query or DNS Response), IP address range(s) or FQDN range(s) in DNS Answer field or FQDN range(s) in DNS Query field. If the FQDN in a DNS Query matches the FQDN(s) provided by the SMF, based on instructions by SMF, one of the following options is executed by the EASDF… Options (A or B)...SMF then provides instructions to EASDF to execute one of the above Options (A or B));
receiving, from one of the second network function and a third network function, on a per network function basis via a DNS configuration management procedure, DNS configuration information of the network, wherein the DNS configuration information includes at least one of: a list of one or more DNS servers; a list of one or more service areas; and a list of one or more supported FQDNs (at least section 6.2.3.2.2; ECS option or the Local DNS server address provided by the SMF to the EASDF are part of the rules to handle DNS queries from the UE. They are related to candidate DNAI(s) for that FQDN for the UE location. The SMF may provide rules to handle DNS queries from the UE to the EASDF either when the SMF establishes the association with the EASDF for the UE);
selecting one of a DNS server or an extension for DNS client subnet (ECS) option for a FQDN originating from a user equipment (UE) (at least section 6.2.3.2.2; DNS query from UE sent to SMF to select EASDF with FQDN, Option A: EASDF adds the EDNS Client Subnet (ECS) option into the DNS Query message; Option B: The EASDF forwards the DNS Query message to a suitable Local DNS server), wherein the selected one of the DNS server or the ECS option is selected based on:
(a) the serving DNS information (at least section 6.2.3.2.2; EASDF is provisioned with the forwarding rule(s), i.e. ECS option(s) or local DNS Server(s) for the … DNAI(s)); and
(b) at least one of DNS configuration information of the network and one or more rules for handling DNS information (at least section 6.2.3.2.2; EASDF is provisioned with the forwarding rule(s), i.e. ECS option(s) or local DNS Server(s) for the FQDN(s) and DNAI(s); SMF selects EASDF as described clause 6.3.x (TBD) of TS 23.501 [2]. This selection may use NRF discovery or may be based on SMF local configuration); and
applying the DNS configuration information received on the per network function basis and the serving DNS information to process at least one subsequent DNS query received from at least one UE for edge application server (EA) discovery, without transmitting a request to the SMF per each such DNS query, wherein the DNS configuration information is applied to any PDU session associated with the first network function (at least section 6.2.3.2.2-6.2.3.2.3; SMF configuring EASDF with DNS message handling rules before PDU Session is created between UE and EASDF, then once configured the UE establishes and uses EASDF configuration with PDU session establishment; If DNS query from UE matches rule, using Option A or B, else forward to preconfigured DNS server, not all queries needing SMF request, some are forwarded depending on rule matching; EASDF configured with DNS message handling rules to forward DNS messages of the UE with Option A and/or B where EASDF sends or forwards DNS Query to DNS server for the time of the PDU session; SMF only used for session for reporting information to and from optionally; see also Option D: subsequent DNS queries).
As per Claim 2. The method of Claim 1, wherein the serving DNS information is included in at least one of:
a notification from the second network function indicating a change of the serving DNS information; the change being triggered by at least one of a mobility of the UE, an insertion of a local PSA, and a removal of a local PSA; a message associated with a DNS context create procedure; and a message associated with a DNS context update procedure (at least Figure 6.2.3.2.2-1; 2. Select EASDF 3. Neasdf_DNSContext_Create Request; and/or 6. Neasdf_DNSContext_Update Request ; Section 6.2.3.2.2: EASDF creates a DNS context for the PDU Session; SMF may invoke Neasdf_DNSContext_Update Request (PDU Session Context ID, rules to handle DNS queries from the UE) to EASDF. The update may be triggered by UE mobility, e.g. when UE moves to a new location, or by a reporting by EASDF of a DNS Query with certain FQDN, or, the update may be triggered by insertion/removal of Local PSA, e.g. to update rules to handle DNS messages from the UE or by new PCC rule information).
As per Claim 3. The method of Claim 1, wherein the serving DNS information is used for indicating a second condition for selecting the DNS server or a third condition for handling DNS information, and the serving DNS information includes at least one of:
a list of DNAIs if the DNS server serves two or more DNAIs, wherein a new identifier for DNS server accessing corresponds to the list of DNAI(s) which share the same DNS server information with a current accessing DNAI;
an identifier for identifying a service area of a serving DNS server; and
an ECS option corresponding to a current PSA of one of a PDU session and a FQDN in a received DNS query message (at least section 6.2.3.2.2; For the selection of the candidate DNAI(s) for an FQDN for the UE, the SMF may consider the UE location, network topology and information of EAS deployment received as part of PCC rules; DNS server resolves the EAS IP address considering the ECS option, and sends the DNS Response to the EASDF).
As per Claim 5. The method of Claim 1, further comprising:
receiving the one or more rules for handling DNS messages received from the UE (at least section 6.2.3.2.2; rules to handle DNS queries from the UE), wherein the one or more rules for handling DNS information includes at least one of:
a DNS information reporting rule; and a DNS information forwarding rule, wherein the DNS information forwarding rule includes at least one of:
one or more ECS options for handling the DNS information; and information relating to one or more DNS servers, the information including at least one of:
a list of one or more DNS servers; a list of one or more service areas; and a list of one or more supported FQDNs (at least section 6.2.3.2.2; “The ECS option or the Local DNS server address provided by the SMF to the EASDF are part of the rules to handle DNS queries from the UE. They are related to candidate DNAI(s) for that FQDN for the UE location. The SMF may provide rules to handle DNS queries from the UE to the EASDF either when the SMF establishes the association with the EASDF for the UE, and may update the rules at any time when the association exists. For the selection of the candidate DNAI(s) for an FQDN for the UE, the SMF may consider the UE location, network topology and information of EAS deployment received as part of PCC rules”).
As per Claim 6. The method of Claim 1, further comprising:
receiving the DNS configuration information on a per network function basis via a DNS configuration management procedure from at least one of:
the SMF; and a network exposure function (NEF), which receives the DNS configuration information from an application function (AF) of the network and stores the DNS configuration information in a unified data repository (UDR) of the network (at least section 6.2.3.2.2; SMF; L-NEF).
As per Claim 8. The method of Claim 1, further comprising: buffering a received DNS query message; and waiting for updated information to forward the buffered DNS query message, the updated information relating to at least one of: DNS configuration information of the network; one or more rules for handling DNS information; and the serving DNS information (at least section 6.3.5; 6.2.3.2.2; Figure 6.2.3.2.2-1; steps 8-18 in Figure EASDF holds DNS query for context notification to then send DNS query).
As per Claim 10. The method of Claim 1, wherein: if the DNS server is associated with the FQDN in a received DNS query message, the method further comprises forwarding the received DNS query message to the selected DNS server; and if the ECS option is associated with the FQDN in a received DNS query message, the method further comprises forwarding the received DNS query message with the selected ECS option (at least section 6.2.3.2.2; “If the FQDN in a DNS Query matches the FQDN(s) provided by the SMF, based on instructions by SMF, one of the following options is executed by the EASDF:… - Option A: The EASDF adds the EDNS Client Subnet (ECS) option into the DNS Query message as defined in RFC 7871[6], and sends the DNS Query message to the DNS server. The DNS server resolves the EAS IP address considering the ECS option, and sends the DNS Response to the EASDF. - Option B: The EASDF forwards the DNS Query message to a suitable Local DNS server which is responsible for resolving EAS within the corresponding Local DN, and receives DNS Response message from Local DNS server.”).
Claims 14, 16-19, 21, 23 do not, in substance, add or define any additional limitations over claims 1-3, 5-6, 8, 10 and therefore are rejected for similar reasons, supra.
As per Claim 25, 3GPP TS 23.548 discloses an apparatus providing a session management function (SMF) of a network, the apparatus comprising:
a processor; and a wireless transceiver coupled to the processor (at least section 4.3; ie. 5G3C), wherein the processor is configured to:
receive, via the wireless transceiver, domain name service (DNS) configuration information of the network on a per network function basis via a DNS configuration management procedure (at least section 6.2.3.2.2; EASDF is provisioned with the forwarding rule(s), i.e. ECS option(s) or local DNS Server(s) for the FQDN(s) and DNAI(s); SMF selects EASDF as described clause 6.3.x (TBD) of TS 23.501 [2]. This selection may use NRF discovery or may be based on SMF local configuration.); and
transmit, via the wireless transceiver, to a second network function comprising an edge application server discovery function (EASDF):
(a) serving DNS information (at least section 6.2.3.2.2; DNS query from UE sent to SMF to select EASDF with FQDN and candidate DNAI(s)); and
(b) one or more rules for handling DNS information, in order to select a DNS server or an extension for DNS client subnet (ECS) option for a fully qualified domain name (FQDN) originating from a user equipment (UE) (at least section 6.2.3.2.2; ECS option or the Local DNS server address provided by the SMF to the EASDF are part of the rules to handle DNS queries from the UE. They are related to candidate DNAI(s) for that FQDN for the UE location. The SMF may provide rules to handle DNS queries from the UE to the EASDF either when the SMF establishes the association with the EASDF for the UE),
provisioning the EASDF with the DNS configuration information on the per network function basis and the serving DNS information such that the EASDF applies the DNS configuration information and the serving DNS information to process at least one subsequent DNS query received from at least one UE for edge application server (EA) discovery, without transmitting a request to the SMF per each such DNS query, wherein the provisioning of the EASDF with the DNS configuration information provides DNS configuration that is applied to any PDU session associated with the EASDF (at least section 6.2.3.2.2-6.2.3.2.3; SMF configuring EASDF with DNS message handling rules before PDU Session is created between UE and EASDF, then once configured the UE establishes and uses EASDF configuration with PDU session establishment; If DNS query from UE matches rule, using Option A or B, else forward to preconfigured DNS server, not all queries needing SMF request, some are forwarded depending on rule matching; EASDF configured with DNS message handling rules to forward DNS messages of the UE with Option A and/or B where EASDF sends or forwards DNS Query to DNS server for the time of the PDU session; SMF only used for session for reporting information to and from optionally; see also Option D: subsequent DNS queries).
As per Claim 26. The apparatus of Claim 25, wherein the processor is further configured to: receive DNS configuration information of the network via a DNS configuration management procedure from a network exposure function (NEF) of the network (at least section 6.4.2; Local NEF selection based on UE mobility/area configuration; local NEF exposures); and transmit the DNS configuration information to the second network function (at least section 6.2.3.2.2; SMF transmitting rules and configuration to EASDF; ECS option or the Local DNS server address provided by the SMF to the EASDF are part of the rules to handle DNS queries from the UE. They are related to candidate DNAI(s) for that FQDN for the UE location. The SMF may provide rules to handle DNS queries from the UE to the EASDF either when the SMF establishes the association with the EASDF for the UE).
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.
Claim(s) 27-30 is/are rejected under 35 U.S.C. 103 as being unpatentable over 3GPP TS 23.548 in view of 3GPP TS 23.502 V17.0.0 (2021-03) Technical Specification 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Procedures for the 5G System (5GS); Stage 2 (Release 17) (hereinafter “3GPP TS 23.502”).
As per Claim 27, 29. 3GPP TS 23.548 fails to explicitly disclose wherein the processor is further configured to receive the DNS configuration information from the NEF via a pull mode comprising: the SMF receiving the DNS configuration information when at least one of: a PDU session for a data network name (DNN), a single network slice selection assistance information (S-NSSAI), and/or a DNAI is established and DNS configuration information provided by a NEF are not available at the SMF; and when a caching timer for the DNS configuration elapses and there is PDU session(s) for this DNN, SNSSAI, and/or DNAI(s) and/or application(s).
However, the use and advantages for using such a system was well known to one skilled in the art before the effective filing date of the claimed invention as evidenced by the teachings of 3GPP TS 23.502. 3GPP TS 23.502 discloses, in an analogous art, SMF invokes the Nnef_PFDManagement_Fetch command to retrieve via pull PFD information and the NEF replies with the information (at least section 4.18.3.1).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the use of 3GPP TS 23.502 fetching with 3GPP TS 23.548 as 3GPP TS 23.548 teaches in at least section 6.2.3.2.2 that the information being pulled is DNS configuration information as well as in the Editor’s Note in said section that how the SMF gets such DNS related information is “specified in TS 23.502”. As well as in Annex C.1 that the DNS records have a TTL and are cached for a certain amount of time.
As per Claim 28, 30. 3GPP TS 23.548 fails to explicitly disclose wherein the processor is further configured to receive the DNS configuration information from the NEF via a push mode comprising: the SMF sending a subscribe request to the NEF, and the NEF distributing the DNS configuration information to the SMF following a delay to optimize a signaling load, wherein the NEF distributes the DNS configuration information within an indicated time interval in response to receiving an allowed delay.
However, the use and advantages for using such a system was well known to one skilled in the art before the effective filing date of the claimed invention as evidenced by the teachings of 3GPP TS 23.502. 3GPP TS 23.502 discloses, in an analogous art, SMF subscribes to PFD notifications from the NEF (PFDF) by sending Nnef_PFDManagement_Subscribe message and NEF (PFDF) invokes Nnef_PFD_Management_Notify (Application Identifier, PFDs, PFDs operation) to the SMF(s) to which the PFD(s) shall be provided. The NEF (PFDF) may decide to delay the distribution of PFDs to the SMF(s) for some time to optimize the signaling load. If the NEF (PFDF) received an Allowed Delay for a PFD, the NEF (PFDF) shall distribute this PFD within the indicated time interval (at least section 4.18.3.2).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the use of 3GPP TS 23.502 subscription or pushing with 3GPP TS 23.548 as 3GPP TS 23.548 teaches in at least section 6.2.3.2.2 that the information being sent is DNS configuration information as well as in the Editor’s Note in said section that how the SMF gets such DNS related information is “specified in TS 23.502”.
Response to Arguments
Applicant's arguments filed 01 June 2026 have been fully considered but they are not persuasive.
See above 112 Rejection.
Also see note above regarding claim 25 status and claim markings.
In response to Applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., handling similar DNS queries by the UEs; population of UEs in an area being handled) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). The support of par. 32 given by Applicant further supports this as only one UE (“a UE”) is having DNS queries handled.
Applicant argues that the amendment ‘wherein the DNS configuration information is applied to any PDU session associated with the first network function’ supports that any and all UEs with similar queries are applying such configuration information. However, the broadest reasonable interpretation allows that ‘any PDU session’ associated with the EASDF 1st NF would include, with the open ended ‘comprising’ preamble, any PDU session associated with the first network function, including only with the UE or even any single session. The recitation of any is not every or all as argued. 3GPP TS 23.548 clearly teaches the UE using the EASDF configuration for the PDU session.
As it is Applicant's right to claim as broadly as possible their invention, it is also the Examiner's right to interpret the claim language as broadly as possible. It is the Examiner's position that the detailed functionality that allows for Applicant's invention to overcome the prior art used in the rejection, fails to differentiate in detail how these features are unique. Examiner recommends, as in the 5/27/26 Interview, positively reciting in the claims multiple different UEs and their unique queries and timing to align with the arguments presented.
Applicant argues, in substance, that the amendment to the independent claim 1 overcomes the 23.548 reference. Applicant argues that 3GPP TS 23.548 teaches the SMF being involved in all queries by rather than the EASDF. However, the claims have been broadly amended for the EASDF to be configured and then ‘at least one subsequent DNS query’ ie. one query being received and not transmitting ‘a request’ to the SMF for the query. 3GPP TS 23.548 clearly teaches the SMF configuring EASDF with DNS message handling rules before PDU Session is created between UE and EASDF, then once configured the UE establishes and uses EASDF configuration with PDU session establishment; If DNS query from UE matches rule, using Option A or B, else forward to preconfigured DNS server, not all queries needing SMF request, some are forwarded depending on rule matching (at least section 6.2.3.2.2-6.2.3.2.3). In other words, once the EASDF is configured, the UE and EASDF establish a PDU session and if a rule is matched as configured, not involving the SMF, the EASDF responds or forwards accordingly.
See also the two Editor’s notes in 6.2.3.2.2 that 1) the EAS’s FQDN information is non-UE specific, and 2) guaranteeing that the UE uses the EASDF’s IP address for subsequent DNS query.
See also 6.2.3.2.2 Option D for subsequent DNS query messages destined for EASDF being handled by a DNS proxy to forward the query to a local DNS server.
See also 6.3.3.2 where some UE(s) are moved from an old target EAS to a new target EAS as identified by the DNAI.
See also 892 2022/0321475 Thiebaut par. 37-38, 78 for offloading traffic from an SMF by using another network function such as UPF.
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 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.
The prior art made of record and not relied upon considered pertinent to applicant's disclosure is indicated in PTO form 892.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GREGORY TODD whose telephone number is (303)297-4763. The examiner can normally be reached 8:30-5 MST.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor Nicholas Taylor can be reached on 571-272-3889. 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.
/GREGORY TODD/ Primary Examiner, Art Unit 2443
Prosecution Insights