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 and RCE filed, 26 January 2026, of application filed, with the above serial number, on 11 October 2023 in which claims 1, 3, 6, 14, 17, 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.
Claim Rejections - 35 USC § 112
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.
Claim 27, 29 recite the limitation "a DNN / S-NSSAI and/or DNAI" in line 4. It is indefinite if DNN and S-NSSAI with ‘DNN / S-NSSAI’ is one of DNN / S-NSSAI and/or DNAI or “DNN, S-NSSAI and/or DNAI”. In other words DNN and S-NSSAI are separated by a forward slash with DNAI not separated as well as “and/or” it not being clear if it is one of DNN or S-NSSAI together and/or DNAI or simply one of the three alternatives.
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. Amended claim 1 recites ‘the first condition being at least one of a current service area which is associated with one of a DNS server or data network access identifiers (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’. The claimed ‘at least one of’ a current service area only has one option to be the first condition, it is indefinite if there is an other first condition(s) that are not listed.
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 a current service area which is associated with one of a DNS server or data network access identifiers (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 (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, 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
handling at least one subsequent DNS query from at least one UE without involvement of the SMF for edge application server (EA) discovery, reducing system load for the SMF, based on having been provisioned by the SMF in time for choosing information related to a server discovery procedure (at least section 6.2.3.2.2; 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).
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 (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 in time for choosing information related to a server discovery procedure to handle at least one subsequent DNS query from at least one UE without involvement of the SMF for edge application server (EA) discovery, reducing system load for the SMF (at least section 6.2.3.2.2; 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).
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) / single network slice selection assistance information (S-NSSAI) and/or DNAI(s) 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/S-NSSAI 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 26 January 2026 have been fully considered but they are not persuasive.
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., handle similar DNS queries by one or more 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).
Applicant argues, in substance, 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 ‘at least one UE’ subsequent DNS query being handled, such UE not being claimed as other UEs. In fact, the claims are reciting that the serving DNS information indicating a first condition is for “a PDU session”. As is well known for a PDU session to be defined as ‘a logical, end-to-end user plane connection between a User Equipment (UE) and a Data Network (DN), such as the internet or IMS, allowing for packet data transfer. Established via the SMF and UPF,…’. Thus, the claims as amended do not align with the argument, whether as broadly claimed to include any UE including the original, or as defined that such being for a single PDU session from a single UE according to a PDU session as well known in the art.
3GPP TS 23.548 clearly teaches in at least section 6.2.3.2.2, that the EASDF is 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)
It is further noted that the emphasized amended claim language ‘handling at least one subsequent DNS query from at least one UE without involvement of the SMF for edge application server (EA) discovery, reducing system load for the SMF, based on having been provisioned by the SMF in time for choosing information related to a server discovery procedure’ is not given patentable weight in such method claim as it simply expresses the intended result of a process step positively recited before it with the EASDF handling the query. However, 3GPP TS 23.548 teaches the SMF not being used further, and thus reduced load, for the time of PDU session of the UE unless the UE mobility event indicates a new EASDF being needed.
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.
Conclusion
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