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 .
Response to Amendment
This is in response to an amendment/response/communication filed 3/18/2026.
No claims have been cancelled.
No claims have been added.
Claims(s) 1-16 is/are currently pending.
Information Disclosure Statement
The information disclosure statement(s) (IDS(s)) submitted on 8/1/2024, 3/5/2025 and 3/18/2026 is/are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the Examiner.
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Drawings
The drawings were received on 8/1/2024. These drawings are accepted.
Specification
The lengthy specification has not been checked to the extent necessary to determine the presence of all possible minor errors. Applicant's cooperation is requested in correcting any errors of which applicant may become aware in the specification.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1, 5, 9 and 13 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claim(s) recite(s) “determining the UPF entity matches the NF discovery request message” or similarly recites, “determining the UPF entity matches the NF discovery request message”, and are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more..
The limitations of “determining the UPF entity matches the NF discovery request message” covers performance of the limitation in the mind but for the recitation of the generic communication components. That is, other than reciting “receiving, from a user plane function (UPF)”…”, “storing…”, “marking…”, “receiving, from a session management function (SMF)”, and “transmitting…” , nothing in the claim element precludes the step from practically being performed in the mind. For example, but for the “receiving, from a user plane function (UPF)”…”, “storing…”, “marking…”, “receiving, from a session management function (SMF)”, and “transmitting…”, language, “determining” in the context of the claim encompasses a person manually comparing, observing, etc. “determining the UPF entity matches the NF discovery request message”. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computing/communication components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea. The mere performance of a node handling QoS information and receiving information associated with QoS is not considered a meaningful limit of the claim’s scope, since the limitation is considered to be routine within the relevant art (see Applicant’s Admitted Prior Art (AAPA) in the PGPub specification, “5GT communication system”, para. 0005, and also. Therefore, the concept in the claim is not meaningfully different than the abstract idea.
This judicial exception is not integrated into a practical application because the claim only recites “receiving, from a user plane function (UPF)”…”, “storing…”, “marking…”, “receiving, from a session management function (SMF)”, and “transmitting…” for performing the “determining” steps. Accordingly, the “receiving, from a user plane function (UPF)”…”, “storing…”, “marking…”, “receiving, from a session management function (SMF)”, and “transmitting…” do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on the practicing the abstract idea. The claim is directed to an abstract idea.
The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements when considered both individually and as an ordered combination do not amount to significantly more than the abstract idea. While the claim recites a “receiving, from a user plane function (UPF)”…”, “storing…”, “marking…”, “receiving, from a session management function (SMF)”, and “transmitting…”, these devices/steps are merely generic pieces of hardware/processing, generally containing a processor, a memory and a number of transceivers that are readily known to one of ordinary skill in the art. Thus, taken alone, the additional elements do not amount to significantly more than the above-identified judicial exception (the abstract idea). Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination improves any other technology. Their collective functions merely to provide a conventional communication implementation. Therefore, the claim is not patent eligible.
Claims 2-4, 6-8, 10-12 and 14-16 depend upon claims 1, 5, 9 and 13, respectively and include all the limitations of claims 1, 5, 9 and 13. The claims recite additional details associated with the “NF discovery service” (claims 2, 6, 10 and 14), “NF discover request message” (claims 3, 7, 11 and 15) and “the UPF profile includes…” (claims 4, 8, 12 and 16). These additional limitations merely expand upon the abstract idea without including additional elements that are sufficient to amount to significantly more than the judicial exception.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1, 4, 5, 8, 9, 12, 13 and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Talebi Fard et al. US 20190313468 (U.S. Patent Application Publications citation #7, listed on IDS dated 2024-08-01) in view of Yang et al. US 20220191294 (U.S. Patent Application Publications citation #19, listed on IDS dated 2024-08-01).
As to claim 1:
Talebi Fard et al. discloses:
A method performed by a network repository function (NRF) entity in a mobile communication system, the method comprising:
receiving, from a user plane function (UPF) entity, a network function (NF) register request message including a UPF profile of the UPF entity;
(“In an example embodiment as depicted in FIG. 21, when a new network function/network element (e.g., UPF, NEF, NIMF, and/or the like) is instantiated or deployed, the new network function may register itself with the NRF or an OAM. The new network function (e.g., the UPF, the NEF, the NIMF) may send a registration message indicating that the new network function may support the CIoT packet transmission, small data transmission, CIoT optimization, CIoT indicator, and/or the like. In an example, the registration message may comprise at least one of a network function profile of the UPF, NEF, or NIMF, an identifier of the UPF, NEF, or NIMF, an S-NSSAI that the new network function may support, a DNN associated with the new network function, and/or the like. In an example, the NRF may be configured by an OAM with information on available UPF(s), NEF(s), NIMF(s). In an example, the registration message may comprise an information element indicating that user plane CIoT optimization, user plane CIoT packet transmission, small data transmission, the CIoT optimization, and/or the like may be supported by the new network function. In an example, the registration message may further comprise an identifier of the UPF/NEF/NIMF, a capability information of the UPF/NEF/NIMF, a traffic routing capability of the UPF/NEF/NIMF, a network function type of the UPF/NEF/NIMF, an IP address (e.g., IPv4, and/or IPv6) of the UPF/NEF/NIMF, a fully qualified domain name (FQDN) of the UPF/NEF/NIMF, a profile of the UPF/NEF/NIMF, a list of supported S-NSSAIs associated with the UPF/NEF/NIMF, and/or the like. In an example, the profile of the UPF/NEF/NIMF may be employed to describe the characteristics of a UPF/NEF/NIMF instance. When an UPF/NEF/NIMF network function instance is instantiated, the associated UPF/NEF/NIMF network function profile may be generated and stored on the UPF/NEF/NIMF network function instance. During a service registration procedure, the UPF/NEF/NIMF network function profile may be registered and stored on the NRF. The profile of the UPF/NEF/NIMF network function may comprise a type of the UPF/NEF/NIMF network function, an FQDN and/or IP address of the UPF/NEF/NIMF network function instance, network slice related identifier(s) e.g. S-NSSAI, network slice instance identifier (NSI ID), UPF/NEF/NIMF network function capacity information, permissions, authorization information, and/or the like.”; Talebi Fard et al.; 0357)
(where
“when a new network function/network element (e.g., UPF, NEF, NIMF, and/or the like) is instantiated or deployed, the new network function may register itself with the NRF or an OAM. The new network function (e.g., the UPF, the NEF, the NIMF) may send a registration message indicating that the new network function may support the CIoT packet transmission, small data transmission, CIoT optimization, CIoT indicator, and/or the like. In an example, the registration message may comprise at least one of a network function profile of the UPF” maps to “receiving, from a user plane function (UPF) entity, a network function (NF) register request message including a UPF profile of the UPF entity”, where “network function…send a registration message” maps to “receiving…a network function (NF) register request message”, “UPF” maps to “from a user plane function (UPF) entity”, “registration message may comprise at least one of a network function profile of the UPF” maps to “register request message including a UPF profile of the UPF entity”
storing the UPF profile;
(where
“the UPF/NEF/NIMF network function profile may be registered and stored on the NRF” maps to “storing the UPF profile”,
marking that the UPF entity is an available UPF;
(where
“the NRF may be configured by an OAM with information on available UPF(s)”’ maps to “marking that the UPF entity is an available UPF”
receiving, from a session management function (SMF) entity which is a NF service consumer, a NF discovery request message including information on a NF service name, information on a NF type indicating a UPF, and information on a NF type of the NF service
consumer;
(“In an example, in order to enable access to a requested NF type or NF service (e.g., the UPF, NIMF, and/or NEF supporting the NF type or the NF service), a requester NF (e.g., the SMF) may invoke the NF discovery procedure or the NF service discovery procedure by providing, to the NRF (e.g. via the at least one second message), a type of the NF or a specific service (e.g., service type), and/or other service parameters e.g., slicing related information to discover a NF. The requester (e.g. the SMF) may attempt to discover a network node (e.g. UPF, NEF, NIMF, and/or the like) supporting the type of the NF or the specific service. In an example, in response to receiving the at least one second message, the NRF may provide an IP address or a fully qualified domain name (FQDN) or an identifier of relevant services and/or NF instance(s) (e.g. an instance of the UPF, the NEF/NIMF, and/or the like) to the requester NF (e.g., the SMF) for NF selection. In an example, based on the received information (e.g., the IP address or the FQDN of the NF) from the NRF, the requester NF (e.g., the SMF) may select one or more NF instance(s) (e.g., an instance of the UPF, NEF, NIMF, and/or the like that may provide CIoT data transmission, device triggering, and/or the like) that may be able to provide the requested NF service(s).”; Talebi Fard et al.; 0333)
(“In an example, the at least one second message may be a Nnrf_NFDiscovery_Request message. The Nnrf_NFDiscovery_Request message may comprise NF service name(s) (e.g., UPF, NEF, NIMF, user plane CIoT data transmission, CIoT/MTC data transmission, and/or the like), NF type of a target NF (e.g., the UPF, NEF/NIMF), a NF type of the NF service consumer (e.g., the SMF), S-NSSAI(s), an identifier of a target NF/NF service PLMN (e.g., UPF PLMN ID, NEF PLMN ID, NIMF PLMN ID, and/or the like), serving PLMN ID, an identifier of the service consumer NF (e.g., the SMF ID), and/or the like. In an example, in response to the at least one second message, the NRF may provide to the SMF, the IP address or FQDN of the expected NF instance(s) (e.g. the UPF, NEF, NIMF, and/or the like).”; Talebi Fard et al.; 0334)
(where
“the at least one second message may be a Nnrf_NFDiscovery_Request message. The Nnrf_NFDiscovery_Request message may comprise NF service name(s) (e.g., UPF, NEF, NIMF, user plane CIoT data transmission, CIoT/MTC data transmission, and/or the like), NF type of a target NF (e.g., the UPF, NEF/NIMF), a NF type of the NF service consumer (e.g., the SMF)” maps to “receiving, from a session management function (SMF) entity which is a NF service consumer, a NF discovery request message”,
“comprise NF service name(s)” maps to “including information on a NF service name”,
“NF type of a target NF (e.g., the UPF, NEF/NIMF)” maps to “information on a NF type indicating a UPF”
“NF type of the NF service consumer” maps to “information on a NF type of the NF service”
…and
transmitting, to the SMF entity, a NF discovery request response message as a response to the NF discovery request message, wherein the NF discovery request response message ….
“in response to receiving the at least one second message, the NRF may provide an IP address or a fully qualified domain name (FQDN) or an identifier of relevant services and/or NF instance(s) (e.g. an instance of the UPF, the NEF/NIMF, and/or the like) to the requester NF (e.g., the SMF)” maps to “transmitting, to the SMF entity, a NF discovery request response message as a response to the NF discovery request message, wherein the NF discovery request response message ….”
…
wherein the UPF entity is marked as an available UPF.
(where
“the NRF may be configured by an OAM with information on available UPF(s)”’ maps to “marking that the UPF entity is an available UPF”
Talebi Fard et al. teaches a new network function like a UPF registering with an NRF where the registration message includes a UPF profile, teaches an UPF network function profile being stored on the NRF, teaches an OAM configuring the NRF with available UPF(s), teaches an SMF sending a discovery message to the NRF, where the discovery message includes NF service name(s), “NF type associated with UFP”, and NF type of the NF service consumer and teaches sending a response message from the NRF to the SMF in response to receiving the discovery message.
Talebi Fard et al. as described above does not explicitly teach:
wherein the UPF entity matches the NF discovery request message, and
However, Yang et al. further teaches a match/UPF profile capability which includes:
wherein the UPF entity matches the NF discovery request message, and
(“In one aspect, an NRF is configured to inform an NF instance that has sent a discover request toward the NRF that the number of NF instances that match the search criteria used by the NRF in response to the discover request is greater than the number of NF instance profiles included in the NF instances array of the discover response.”; Yang et al.; Abstract)
(“…target NF type is … “UPF”…; Yang et al.; Table 1)
“number of NF instances that match the search criteria used by the NRF in response to the discover request”/”target NF type is…”UPF”” maps to “determining the UPF entity matches the NF discovery request message”
Yang et al. teaches determining how many NF instances match a discover search criteria and provides parameters associated with reporting UPF NF profiles.
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the match/UPF profile capability of Yang et al. into Talebi Fard et al. By modifying the processing/communications of Talebi Fard et al. to include the match/UPF profile capability as taught by the processing/communications of Yang et al., the benefits of reduced failure rate (Talebi Fard et al.; 0320) with improved discovery (Yang et al.; Abstract) are achieved.
As to claim 4:
Talebi Fard et al. discloses:
wherein the UPF profile includes at least one …, an internet protocol (IP) address of the UPF entity, ….
(“In an example embodiment as depicted in FIG. 21, when a new network function/network element (e.g., UPF, NEF, NIMF, and/or the like) is instantiated or deployed, the new network function may register itself with the NRF or an OAM. The new network function (e.g., the UPF, the NEF, the NIMF) may send a registration message indicating that the new network function may support the CIoT packet transmission, small data transmission, CIoT optimization, CIoT indicator, and/or the like. In an example, the registration message may comprise at least one of a network function profile of the UPF, NEF, or NIMF, an identifier of the UPF, NEF, or NIMF, an S-NSSAI that the new network function may support, a DNN associated with the new network function, and/or the like. In an example, the NRF may be configured by an OAM with information on available UPF(s), NEF(s), NIMF(s). In an example, the registration message may comprise an information element indicating that user plane CIoT optimization, user plane CIoT packet transmission, small data transmission, the CIoT optimization, and/or the like may be supported by the new network function. In an example, the registration message may further comprise an identifier of the UPF/NEF/NIMF, a capability information of the UPF/NEF/NIMF, a traffic routing capability of the UPF/NEF/NIMF, a network function type of the UPF/NEF/NIMF, an IP address (e.g., IPv4, and/or IPv6) of the UPF/NEF/NIMF, a fully qualified domain name (FQDN) of the UPF/NEF/NIMF, a profile of the UPF/NEF/NIMF, a list of supported S-NSSAIs associated with the UPF/NEF/NIMF, and/or the like. In an example, the profile of the UPF/NEF/NIMF may be employed to describe the characteristics of a UPF/NEF/NIMF instance. When an UPF/NEF/NIMF network function instance is instantiated, the associated UPF/NEF/NIMF network function profile may be generated and stored on the UPF/NEF/NIMF network function instance. During a service registration procedure, the UPF/NEF/NIMF network function profile may be registered and stored on the NRF. The profile of the UPF/NEF/NIMF network function may comprise a type of the UPF/NEF/NIMF network function, an FQDN and/or IP address of the UPF/NEF/NIMF network function instance, network slice related identifier(s) e.g. S-NSSAI, network slice instance identifier (NSI ID), UPF/NEF/NIMF network function capacity information, permissions, authorization information, and/or the like.”; Talebi Fard et al.; 0357)
As to claim 5:
Talebi Fard et al. discloses:
A method performed by a session management function (SMF) entity which is
a network function (NF) service consumer in a mobile communication system, the method
comprising:
transmitting, to a network repository function (NRF) entity, a NF discovery request message including information on a NF service name, information on a NF type indicating a user plane function (UPF) entity, and information on a NF type of the NF service consumer; and
(“In an example embodiment as depicted in FIG. 21, when a new network function/network element (e.g., UPF, NEF, NIMF, and/or the like) is instantiated or deployed, the new network function may register itself with the NRF or an OAM. The new network function (e.g., the UPF, the NEF, the NIMF) may send a registration message indicating that the new network function may support the CIoT packet transmission, small data transmission, CIoT optimization, CIoT indicator, and/or the like. In an example, the registration message may comprise at least one of a network function profile of the UPF, NEF, or NIMF, an identifier of the UPF, NEF, or NIMF, an S-NSSAI that the new network function may support, a DNN associated with the new network function, and/or the like. In an example, the NRF may be configured by an OAM with information on available UPF(s), NEF(s), NIMF(s). In an example, the registration message may comprise an information element indicating that user plane CIoT optimization, user plane CIoT packet transmission, small data transmission, the CIoT optimization, and/or the like may be supported by the new network function. In an example, the registration message may further comprise an identifier of the UPF/NEF/NIMF, a capability information of the UPF/NEF/NIMF, a traffic routing capability of the UPF/NEF/NIMF, a network function type of the UPF/NEF/NIMF, an IP address (e.g., IPv4, and/or IPv6) of the UPF/NEF/NIMF, a fully qualified domain name (FQDN) of the UPF/NEF/NIMF, a profile of the UPF/NEF/NIMF, a list of supported S-NSSAIs associated with the UPF/NEF/NIMF, and/or the like. In an example, the profile of the UPF/NEF/NIMF may be employed to describe the characteristics of a UPF/NEF/NIMF instance. When an UPF/NEF/NIMF network function instance is instantiated, the associated UPF/NEF/NIMF network function profile may be generated and stored on the UPF/NEF/NIMF network function instance. During a service registration procedure, the UPF/NEF/NIMF network function profile may be registered and stored on the NRF. The profile of the UPF/NEF/NIMF network function may comprise a type of the UPF/NEF/NIMF network function, an FQDN and/or IP address of the UPF/NEF/NIMF network function instance, network slice related identifier(s) e.g. S-NSSAI, network slice instance identifier (NSI ID), UPF/NEF/NIMF network function capacity information, permissions, authorization information, and/or the like.”; Talebi Fard et al.; 0357)
(where
“when a new network function/network element (e.g., UPF, NEF, NIMF, and/or the like) is instantiated or deployed, the new network function may register itself with the NRF or an OAM. The new network function (e.g., the UPF, the NEF, the NIMF) may send a registration message indicating that the new network function may support the CIoT packet transmission, small data transmission, CIoT optimization, CIoT indicator, and/or the like. In an example, the registration message may comprise at least one of a network function profile of the UPF” maps to “receiving, from a user plane function (UPF) entity, a network function (NF) register request message including a UPF profile of the UPF entity”, where “network function…send a registration message” maps to “receiving…a network function (NF) register request message”, “UPF” maps to “from a user plane function (UPF) entity”, “registration message may comprise at least one of a network function profile of the UPF” maps to “register request message including a UPF profile of the UPF entity”
receiving, from the NRF entity, a NF discovery request response message as a response to the NF discovery request message, wherein the NF discovery request response message …
(“In an example, in order to enable access to a requested NF type or NF service (e.g., the UPF, NIMF, and/or NEF supporting the NF type or the NF service), a requester NF (e.g., the SMF) may invoke the NF discovery procedure or the NF service discovery procedure by providing, to the NRF (e.g. via the at least one second message), a type of the NF or a specific service (e.g., service type), and/or other service parameters e.g., slicing related information to discover a NF. The requester (e.g. the SMF) may attempt to discover a network node (e.g. UPF, NEF, NIMF, and/or the like) supporting the type of the NF or the specific service. In an example, in response to receiving the at least one second message, the NRF may provide an IP address or a fully qualified domain name (FQDN) or an identifier of relevant services and/or NF instance(s) (e.g. an instance of the UPF, the NEF/NIMF, and/or the like) to the requester NF (e.g., the SMF) for NF selection. In an example, based on the received information (e.g., the IP address or the FQDN of the NF) from the NRF, the requester NF (e.g., the SMF) may select one or more NF instance(s) (e.g., an instance of the UPF, NEF, NIMF, and/or the like that may provide CIoT data transmission, device triggering, and/or the like) that may be able to provide the requested NF service(s).”; Talebi Fard et al.; 0333)
(“In an example, the at least one second message may be a Nnrf_NFDiscovery_Request message. The Nnrf_NFDiscovery_Request message may comprise NF service name(s) (e.g., UPF, NEF, NIMF, user plane CIoT data transmission, CIoT/MTC data transmission, and/or the like), NF type of a target NF (e.g., the UPF, NEF/NIMF), a NF type of the NF service consumer (e.g., the SMF), S-NSSAI(s), an identifier of a target NF/NF service PLMN (e.g., UPF PLMN ID, NEF PLMN ID, NIMF PLMN ID, and/or the like), serving PLMN ID, an identifier of the service consumer NF (e.g., the SMF ID), and/or the like. In an example, in response to the at least one second message, the NRF may provide to the SMF, the IP address or FQDN of the expected NF instance(s) (e.g. the UPF, NEF, NIMF, and/or the like).”; Talebi Fard et al.; 0334)
(where
“the at least one second message may be a Nnrf_NFDiscovery_Request message. The Nnrf_NFDiscovery_Request message may comprise NF service name(s) (e.g., UPF, NEF, NIMF, user plane CIoT data transmission, CIoT/MTC data transmission, and/or the like), NF type of a target NF (e.g., the UPF, NEF/NIMF), a NF type of the NF service consumer (e.g., the SMF)” maps to “receiving, from a session management function (SMF) entity which is a NF service consumer, a NF discovery request message”,
“comprise NF service name(s)” maps to “including information on a NF service name”,
“NF type of a target NF (e.g., the UPF, NEF/NIMF)” maps to “information on a NF type indicating a UPF”
“NF type of the NF service consumer” maps to “information on a NF type of the NF service”
receiving, from the NRF entity, a NF discovery request response message as a response to the NF discovery request message, wherein the NF discovery request response message includes a UPF profile,
“in response to receiving the at least one second message, the NRF may provide an IP address or a fully qualified domain name (FQDN) or an identifier of relevant services and/or NF instance(s) (e.g. an instance of the UPF, the NEF/NIMF, and/or the like) to the requester NF (e.g., the SMF)” maps to “transmitting, to the SMF entity, a NF discovery request response message as a response to the NF discovery request message, wherein the NF discovery request response message ….”
wherein the UPF entity is marked as an available UPF.
(where
“the NRF may be configured by an OAM with information on available UPF(s)”’ maps to “marking that the UPF entity is an available UPF”
Talebi Fard et al. teaches a new network function like a UPF registering with an NRF where the registration message includes a UPF profile, teaches an UPF network function profile being stored on the NRF, teaches an OAM configuring the NRF with available UPF(s), teaches an SMF sending a discovery message to the NRF, where the discovery message includes NF service name(s), “NF type associated with UFP”, and NF type of the NF service consumer and teaches sending a response message from the NRF to the SMF in response to receiving the discovery message.
Talebi Fard et al. as described above does not explicitly teach:
determining the UPF entity matches the NF discovery request message;
However, Yang et al. further teaches a match/UPF profile capability which includes:
determining the UPF entity matches the NF discovery request message;
(“In one aspect, an NRF is configured to inform an NF instance that has sent a discover request toward the NRF that the number of NF instances that match the search criteria used by the NRF in response to the discover request is greater than the number of NF instance profiles included in the NF instances array of the discover response.”; Yang et al.; Abstract)
(“…target NF type is … “UPF”…; Yang et al.; Table 1)
“number of NF instances that match the search criteria used by the NRF in response to the discover request”/”target NF type is…”UPF”” maps to “determining the UPF entity matches the NF discovery request message”
(“max-payload-size… the NRF shall limit the number of NF profiles returned in the response…Query-Params-Ext1…List of the PDU session type (s) requested to be supported by the target Network Function (i.e. UPF)…”; Yang et al.; Table 1)
“max-payload-size… the NRF shall limit the number of NF profiles returned in the response…Query-Params-Ext1…List of the PDU session type (s) requested to be supported by the target Network Function (i.e. UPF)…” maps to “includes the UPF profile”
Yang et al. teaches determining how many NF instances match a discover search criteria and provides parameters associated with reporting UPF NF profiles.
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the match/UPF profile capability of Yang et al. into Talebi Fard et al. By modifying the processing/communications of Talebi Fard et al. to include the match/UPF profile capability as taught by the processing/communications of Yang et al., the benefits of reduced failure rate (Talebi Fard et al.; 0320) with improved discovery (Yang et al.; Abstract) are achieved.
As to claim 8:
Talebi Fard et al. discloses:
wherein the UPF profile includes at least one …, an internet protocol (IP) address of the UPF entity, ….
(“In an example embodiment as depicted in FIG. 21, when a new network function/network element (e.g., UPF, NEF, NIMF, and/or the like) is instantiated or deployed, the new network function may register itself with the NRF or an OAM. The new network function (e.g., the UPF, the NEF, the NIMF) may send a registration message indicating that the new network function may support the CIoT packet transmission, small data transmission, CIoT optimization, CIoT indicator, and/or the like. In an example, the registration message may comprise at least one of a network function profile of the UPF, NEF, or NIMF, an identifier of the UPF, NEF, or NIMF, an S-NSSAI that the new network function may support, a DNN associated with the new network function, and/or the like. In an example, the NRF may be configured by an OAM with information on available UPF(s), NEF(s), NIMF(s). In an example, the registration message may comprise an information element indicating that user plane CIoT optimization, user plane CIoT packet transmission, small data transmission, the CIoT optimization, and/or the like may be supported by the new network function. In an example, the registration message may further comprise an identifier of the UPF/NEF/NIMF, a capability information of the UPF/NEF/NIMF, a traffic routing capability of the UPF/NEF/NIMF, a network function type of the UPF/NEF/NIMF, an IP address (e.g., IPv4, and/or IPv6) of the UPF/NEF/NIMF, a fully qualified domain name (FQDN) of the UPF/NEF/NIMF, a profile of the UPF/NEF/NIMF, a list of supported S-NSSAIs associated with the UPF/NEF/NIMF, and/or the like. In an example, the profile of the UPF/NEF/NIMF may be employed to describe the characteristics of a UPF/NEF/NIMF instance. When an UPF/NEF/NIMF network function instance is instantiated, the associated UPF/NEF/NIMF network function profile may be generated and stored on the UPF/NEF/NIMF network function instance. During a service registration procedure, the UPF/NEF/NIMF network function profile may be registered and stored on the NRF. The profile of the UPF/NEF/NIMF network function may comprise a type of the UPF/NEF/NIMF network function, an FQDN and/or IP address of the UPF/NEF/NIMF network function instance, network slice related identifier(s) e.g. S-NSSAI, network slice instance identifier (NSI ID), UPF/NEF/NIMF network function capacity information, permissions, authorization information, and/or the like.”; Talebi Fard et al.; 0357)
As to claim 9:
Talebi Fard et al. discloses:
A network repository function (NRF) entity in a mobile communication system,
the NRF entity comprising:
a transceiver; and
at least one processor coupled with the transceiver and configured to:
receive, from a user plane function (UPF) entity, a network function (NF) register request message including a UPF profile of the UPF entity,
(“In an example embodiment as depicted in FIG. 21, when a new network function/network element (e.g., UPF, NEF, NIMF, and/or the like) is instantiated or deployed, the new network function may register itself with the NRF or an OAM. The new network function (e.g., the UPF, the NEF, the NIMF) may send a registration message indicating that the new network function may support the CIoT packet transmission, small data transmission, CIoT optimization, CIoT indicator, and/or the like. In an example, the registration message may comprise at least one of a network function profile of the UPF, NEF, or NIMF, an identifier of the UPF, NEF, or NIMF, an S-NSSAI that the new network function may support, a DNN associated with the new network function, and/or the like. In an example, the NRF may be configured by an OAM with information on available UPF(s), NEF(s), NIMF(s). In an example, the registration message may comprise an information element indicating that user plane CIoT optimization, user plane CIoT packet transmission, small data transmission, the CIoT optimization, and/or the like may be supported by the new network function. In an example, the registration message may further comprise an identifier of the UPF/NEF/NIMF, a capability information of the UPF/NEF/NIMF, a traffic routing capability of the UPF/NEF/NIMF, a network function type of the UPF/NEF/NIMF, an IP address (e.g., IPv4, and/or IPv6) of the UPF/NEF/NIMF, a fully qualified domain name (FQDN) of the UPF/NEF/NIMF, a profile of the UPF/NEF/NIMF, a list of supported S-NSSAIs associated with the UPF/NEF/NIMF, and/or the like. In an example, the profile of the UPF/NEF/NIMF may be employed to describe the characteristics of a UPF/NEF/NIMF instance. When an UPF/NEF/NIMF network function instance is instantiated, the associated UPF/NEF/NIMF network function profile may be generated and stored on the UPF/NEF/NIMF network function instance. During a service registration procedure, the UPF/NEF/NIMF network function profile may be registered and stored on the NRF. The profile of the UPF/NEF/NIMF network function may comprise a type of the UPF/NEF/NIMF network function, an FQDN and/or IP address of the UPF/NEF/NIMF network function instance, network slice related identifier(s) e.g. S-NSSAI, network slice instance identifier (NSI ID), UPF/NEF/NIMF network function capacity information, permissions, authorization information, and/or the like.”; Talebi Fard et al.; 0357)
(where
“when a new network function/network element (e.g., UPF, NEF, NIMF, and/or the like) is instantiated or deployed, the new network function may register itself with the NRF or an OAM. The new network function (e.g., the UPF, the NEF, the NIMF) may send a registration message indicating that the new network function may support the CIoT packet transmission, small data transmission, CIoT optimization, CIoT indicator, and/or the like. In an example, the registration message may comprise at least one of a network function profile of the UPF” maps to “receiving, from a user plane function (UPF) entity, a network function (NF) register request message including a UPF profile of the UPF entity”, where “network function…send a registration message” maps to “receiving…a network function (NF) register request message”, “UPF” maps to “from a user plane function (UPF) entity”, “registration message may comprise at least one of a network function profile of the UPF” maps to “register request message including a UPF profile of the UPF entity”
storing the UPF profile;
(where
“the UPF/NEF/NIMF network function profile may be registered and stored on the NRF” maps to “storing the UPF profile”,
marking that the UPF entity is an available UPF;
(where
“the NRF may be configured by an OAM with information on available UPF(s)”’ maps to “marking that the UPF entity is an available UPF”
receiving, from a session management function (SMF) entity which is a NF service consumer, a NF discovery request message including information on a NF service name, information on a NF type indicating a UPF, and information on a NF type of the NF service
consumer;
(“In an example, in order to enable access to a requested NF type or NF service (e.g., the UPF, NIMF, and/or NEF supporting the NF type or the NF service), a requester NF (e.g., the SMF) may invoke the NF discovery procedure or the NF service discovery procedure by providing, to the NRF (e.g. via the at least one second message), a type of the NF or a specific service (e.g., service type), and/or other service parameters e.g., slicing related information to discover a NF. The requester (e.g. the SMF) may attempt to discover a network node (e.g. UPF, NEF, NIMF, and/or the like) supporting the type of the NF or the specific service. In an example, in response to receiving the at least one second message, the NRF may provide an IP address or a fully qualified domain name (FQDN) or an identifier of relevant services and/or NF instance(s) (e.g. an instance of the UPF, the NEF/NIMF, and/or the like) to the requester NF (e.g., the SMF) for NF selection. In an example, based on the received information (e.g., the IP address or the FQDN of the NF) from the NRF, the requester NF (e.g., the SMF) may select one or more NF instance(s) (e.g., an instance of the UPF, NEF, NIMF, and/or the like that may provide CIoT data transmission, device triggering, and/or the like) that may be able to provide the requested NF service(s).”; Talebi Fard et al.; 0333)
(“In an example, the at least one second message may be a Nnrf_NFDiscovery_Request message. The Nnrf_NFDiscovery_Request message may comprise NF service name(s) (e.g., UPF, NEF, NIMF, user plane CIoT data transmission, CIoT/MTC data transmission, and/or the like), NF type of a target NF (e.g., the UPF, NEF/NIMF), a NF type of the NF service consumer (e.g., the SMF), S-NSSAI(s), an identifier of a target NF/NF service PLMN (e.g., UPF PLMN ID, NEF PLMN ID, NIMF PLMN ID, and/or the like), serving PLMN ID, an identifier of the service consumer NF (e.g., the SMF ID), and/or the like. In an example, in response to the at least one second message, the NRF may provide to the SMF, the IP address or FQDN of the expected NF instance(s) (e.g. the UPF, NEF, NIMF, and/or the like).”; Talebi Fard et al.; 0334)
(where
“the at least one second message may be a Nnrf_NFDiscovery_Request message. The Nnrf_NFDiscovery_Request message may comprise NF service name(s) (e.g., UPF, NEF, NIMF, user plane CIoT data transmission, CIoT/MTC data transmission, and/or the like), NF type of a target NF (e.g., the UPF, NEF/NIMF), a NF type of the NF service consumer (e.g., the SMF)” maps to “receiving, from a session management function (SMF) entity which is a NF service consumer, a NF discovery request message”,
“comprise NF service name(s)” maps to “including information on a NF service name”,
“NF type of a target NF (e.g., the UPF, NEF/NIMF)” maps to “information on a NF type indicating a UPF”
“NF type of the NF service consumer” maps to “information on a NF type of the NF service”
…and
transmitting, to the SMF entity, a NF discovery request response message as a response to the NF discovery request message, wherein the NF discovery request response message ….
“in response to receiving the at least one second message, the NRF may provide an IP address or a fully qualified domain name (FQDN) or an identifier of relevant services and/or NF instance(s) (e.g. an instance of the UPF, the NEF/NIMF, and/or the like) to the requester NF (e.g., the SMF)” maps to “transmitting, to the SMF entity, a NF discovery request response message as a response to the NF discovery request message, wherein the NF discovery request response message ….”
…
wherein the UPF entity is marked as an available UPF.
(where
“the NRF may be configured by an OAM with information on available UPF(s)”’ maps to “marking that the UPF entity is an available UPF”
Talebi Fard et al. teaches a new network function like a UPF registering with an NRF where the registration message includes a UPF profile, teaches an UPF network function profile being stored on the NRF, teaches an OAM configuring the NRF with available UPF(s), teaches an SMF sending a discovery message to the NRF, where the discovery message includes NF service name(s), “NF type associated with UFP”, and NF type of the NF service consumer and teaches sending a response message from the NRF to the SMF in response to receiving the discovery message.
Talebi Fard et al. as described above does not explicitly teach:
wherein the UPF entity matches the NF discovery request message, and
However, Yang et al. further teaches a match/UPF profile capability which includes:
wherein the UPF entity matches the NF discovery request message, and
(“In one aspect, an NRF is configured to inform an NF instance that has sent a discover request toward the NRF that the number of NF instances that match the search criteria used by the NRF in response to the discover request is greater than the number of NF instance profiles included in the NF instances array of the discover response.”; Yang et al.; Abstract)
(“…target NF type is … “UPF”…; Yang et al.; Table 1)
“number of NF instances that match the search criteria used by the NRF in response to the discover request”/”target NF type is…”UPF”” maps to “determining the UPF entity matches the NF discovery request message”
Yang et al. teaches determining how many NF instances match a discover search criteria and provides parameters associated with reporting UPF NF profiles.
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the match/UPF profile capability of Yang et al. into Talebi Fard et al. By modifying the processing/communications of Talebi Fard et al. to include the match/UPF profile capability as taught by the processing/communications of Yang et al., the benefits of reduced failure rate (Talebi Fard et al.; 0320) with improved discovery (Yang et al.; Abstract) are achieved.
As to claim 12:
Talebi Fard et al. discloses:
wherein the UPF profile includes at least one …, an internet protocol (IP) address of the UPF entity, ….
(“In an example embodiment as depicted in FIG. 21, when a new network function/network element (e.g., UPF, NEF, NIMF, and/or the like) is instantiated or deployed, the new network function may register itself with the NRF or an OAM. The new network function (e.g., the UPF, the NEF, the NIMF) may send a registration message indicating that the new network function may support the CIoT packet transmission, small data transmission, CIoT optimization, CIoT indicator, and/or the like. In an example, the registration message may comprise at least one of a network function profile of the UPF, NEF, or NIMF, an identifier of the UPF, NEF, or NIMF, an S-NSSAI that the new network function may support, a DNN associated with the new network function, and/or the like. In an example, the NRF may be configured by an OAM with information on available UPF(s), NEF(s), NIMF(s). In an example, the registration message may comprise an information element indicating that user plane CIoT optimization, user plane CIoT packet transmission, small data transmission, the CIoT optimization, and/or the like may be supported by the new network function. In an example, the registration message may further comprise an identifier of the UPF/NEF/NIMF, a capability information of the UPF/NEF/NIMF, a traffic routing capability of the UPF/NEF/NIMF, a network function type of the UPF/NEF/NIMF, an IP address (e.g., IPv4, and/or IPv6) of the UPF/NEF/NIMF, a fully qualified domain name (FQDN) of the UPF/NEF/NIMF, a profile of the UPF/NEF/NIMF, a list of supported S-NSSAIs associated with the UPF/NEF/NIMF, and/or the like. In an example, the profile of the UPF/NEF/NIMF may be employed to describe the characteristics of a UPF/NEF/NIMF instance. When an UPF/NEF/NIMF network function instance is instantiated, the associated UPF/NEF/NIMF network function profile may be generated and stored on the UPF/NEF/NIMF network function instance. During a service registration procedure, the UPF/NEF/NIMF network function profile may be registered and stored on the NRF. The profile of the UPF/NEF/NIMF network function may comprise a type of the UPF/NEF/NIMF network function, an FQDN and/or IP address of the UPF/NEF/NIMF network function instance, network slice related identifier(s) e.g. S-NSSAI, network slice instance identifier (NSI ID), UPF/NEF/NIMF network function capacity information, permissions, authorization information, and/or the like.”; Talebi Fard et al.; 0357)
As to claim 13:
Talebi Fard et al. discloses:
A session management function (SMF) entity which is a network function (NF)
service consumer in a mobile communication system, the SMF entity comprising:
a transceiver; and
at least one processor coupled with the transceiver and configured to:
transmit, to a network repository function (NRF) entity, a NF discovery request
message including information on a NF service name, information on a NF type indicating a user
plane function (UPF) entity, and information on a NF type of the NF service consumer, and
(“In an example embodiment as depicted in FIG. 21, when a new network function/network element (e.g., UPF, NEF, NIMF, and/or the like) is instantiated or deployed, the new network function may register itself with the NRF or an OAM. The new network function (e.g., the UPF, the NEF, the NIMF) may send a registration message indicating that the new network function may support the CIoT packet transmission, small data transmission, CIoT optimization, CIoT indicator, and/or the like. In an example, the registration message may comprise at least one of a network function profile of the UPF, NEF, or NIMF, an identifier of the UPF, NEF, or NIMF, an S-NSSAI that the new network function may support, a DNN associated with the new network function, and/or the like. In an example, the NRF may be configured by an OAM with information on available UPF(s), NEF(s), NIMF(s). In an example, the registration message may comprise an information element indicating that user plane CIoT optimization, user plane CIoT packet transmission, small data transmission, the CIoT optimization, and/or the like may be supported by the new network function. In an example, the registration message may further comprise an identifier of the UPF/NEF/NIMF, a capability information of the UPF/NEF/NIMF, a traffic routing capability of the UPF/NEF/NIMF, a network function type of the UPF/NEF/NIMF, an IP address (e.g., IPv4, and/or IPv6) of the UPF/NEF/NIMF, a fully qualified domain name (FQDN) of the UPF/NEF/NIMF, a profile of the UPF/NEF/NIMF, a list of supported S-NSSAIs associated with the UPF/NEF/NIMF, and/or the like. In an example, the profile of the UPF/NEF/NIMF may be employed to describe the characteristics of a UPF/NEF/NIMF instance. When an UPF/NEF/NIMF network function instance is instantiated, the associated UPF/NEF/NIMF network function profile may be generated and stored on the UPF/NEF/NIMF network function instance. During a service registration procedure, the UPF/NEF/NIMF network function profile may be registered and stored on the NRF. The profile of the UPF/NEF/NIMF network function may comprise a type of the UPF/NEF/NIMF network function, an FQDN and/or IP address of the UPF/NEF/NIMF network function instance, network slice related identifier(s) e.g. S-NSSAI, network slice instance identifier (NSI ID), UPF/NEF/NIMF network function capacity information, permissions, authorization information, and/or the like.”; Talebi Fard et al.; 0357)
(where
“when a new network function/network element (e.g., UPF, NEF, NIMF, and/or the like) is instantiated or deployed, the new network function may register itself with the NRF or an OAM. The new network function (e.g., the UPF, the NEF, the NIMF) may send a registration message indicating that the new network function may support the CIoT packet transmission, small data transmission, CIoT optimization, CIoT indicator, and/or the like. In an example, the registration message may comprise at least one of a network function profile of the UPF” maps to “receiving, from a user plane function (UPF) entity, a network function (NF) register request message including a UPF profile of the UPF entity”, where “network function…send a registration message” maps to “receiving…a network function (NF) register request message”, “UPF” maps to “from a user plane function (UPF) entity”, “registration message may comprise at least one of a network function profile of the UPF” maps to “register request message including a UPF profile of the UPF entity”
receiving, from the NRF entity, a NF discovery request response message as a response to the NF discovery request message, wherein the NF discovery request response message …
(“In an example, in order to enable access to a requested NF type or NF service (e.g., the UPF, NIMF, and/or NEF supporting the NF type or the NF service), a requester NF (e.g., the SMF) may invoke the NF discovery procedure or the NF service discovery procedure by providing, to the NRF (e.g. via the at least one second message), a type of the NF or a specific service (e.g., service type), and/or other service parameters e.g., slicing related information to discover a NF. The requester (e.g. the SMF) may attempt to discover a network node (e.g. UPF, NEF, NIMF, and/or the like) supporting the type of the NF or the specific service. In an example, in response to receiving the at least one second message, the NRF may provide an IP address or a fully qualified domain name (FQDN) or an identifier of relevant services and/or NF instance(s) (e.g. an instance of the UPF, the NEF/NIMF, and/or the like) to the requester NF (e.g., the SMF) for NF selection. In an example, based on the received information (e.g., the IP address or the FQDN of the NF) from the NRF, the requester NF (e.g., the SMF) may select one or more NF instance(s) (e.g., an instance of the UPF, NEF, NIMF, and/or the like that may provide CIoT data transmission, device triggering, and/or the like) that may be able to provide the requested NF service(s).”; Talebi Fard et al.; 0333)
(“In an example, the at least one second message may be a Nnrf_NFDiscovery_Request message. The Nnrf_NFDiscovery_Request message may comprise NF service name(s) (e.g., UPF, NEF, NIMF, user plane CIoT data transmission, CIoT/MTC data transmission, and/or the like), NF type of a target NF (e.g., the UPF, NEF/NIMF), a NF type of the NF service consumer (e.g., the SMF), S-NSSAI(s), an identifier of a target NF/NF service PLMN (e.g., UPF PLMN ID, NEF PLMN ID, NIMF PLMN ID, and/or the like), serving PLMN ID, an identifier of the service consumer NF (e.g., the SMF ID), and/or the like. In an example, in response to the at least one second message, the NRF may provide to the SMF, the IP address or FQDN of the expected NF instance(s) (e.g. the UPF, NEF, NIMF, and/or the like).”; Talebi Fard et al.; 0334)
(where
“the at least one second message may be a Nnrf_NFDiscovery_Request message. The Nnrf_NFDiscovery_Request message may comprise NF service name(s) (e.g., UPF, NEF, NIMF, user plane CIoT data transmission, CIoT/MTC data transmission, and/or the like), NF type of a target NF (e.g., the UPF, NEF/NIMF), a NF type of the NF service consumer (e.g., the SMF)” maps to “receiving, from a session management function (SMF) entity which is a NF service consumer, a NF discovery request message”,
“comprise NF service name(s)” maps to “including information on a NF service name”,
“NF type of a target NF (e.g., the UPF, NEF/NIMF)” maps to “information on a NF type indicating a UPF”
“NF type of the NF service consumer” maps to “information on a NF type of the NF service”
receiving, from the NRF entity, a NF discovery request response message as a response to the NF discovery request message, wherein the NF discovery request response message includes a UPF profile,
“in response to receiving the at least one second message, the NRF may provide an IP address or a fully qualified domain name (FQDN) or an identifier of relevant services and/or NF instance(s) (e.g. an instance of the UPF, the NEF/NIMF, and/or the like) to the requester NF (e.g., the SMF)” maps to “transmitting, to the SMF entity, a NF discovery request response message as a response to the NF discovery request message, wherein the NF discovery request response message ….”
wherein the UPF entity is marked as an available UPF.
(where
“the NRF may be configured by an OAM with information on available UPF(s)”’ maps to “marking that the UPF entity is an available UPF”
Talebi Fard et al. teaches a new network function like a UPF registering with an NRF where the registration message includes a UPF profile, teaches an UPF network function profile being stored on the NRF, teaches an OAM configuring the NRF with available UPF(s), teaches an SMF sending a discovery message to the NRF, where the discovery message includes NF service name(s), “NF type associated with UFP”, and NF type of the NF service consumer and teaches sending a response message from the NRF to the SMF in response to receiving the discovery message.
Talebi Fard et al. as described above does not explicitly teach:
determining the UPF entity matches the NF discovery request message;
However, Yang et al. further teaches a match/UPF profile capability which includes:
determining the UPF entity matches the NF discovery request message;
(“In one aspect, an NRF is configured to inform an NF instance that has sent a discover request toward the NRF that the number of NF instances that match the search criteria used by the NRF in response to the discover request is greater than the number of NF instance profiles included in the NF instances array of the discover response.”; Yang et al.; Abstract)
(“…target NF type is … “UPF”…; Yang et al.; Table 1)
“number of NF instances that match the search criteria used by the NRF in response to the discover request”/”target NF type is…”UPF”” maps to “determining the UPF entity matches the NF discovery request message”
(“max-payload-size… the NRF shall limit the number of NF profiles returned in the response…Query-Params-Ext1…List of the PDU session type (s) requested to be supported by the target Network Function (i.e. UPF)…”; Yang et al.; Table 1)
“max-payload-size… the NRF shall limit the number of NF profiles returned in the response…Query-Params-Ext1…List of the PDU session type (s) requested to be supported by the target Network Function (i.e. UPF)…” maps to “includes the UPF profile”
Yang et al. teaches determining how many NF instances match a discover search criteria and provides parameters associated with reporting UPF NF profiles.
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the match/UPF profile capability of Yang et al. into Talebi Fard et al. By modifying the processing/communications of Talebi Fard et al. to include the match/UPF profile capability as taught by the processing/communications of Yang et al., the benefits of reduced failure rate (Talebi Fard et al.; 0320) with improved discovery (Yang et al.; Abstract) are achieved.
As to claim 16:
Talebi Fard et al. discloses:
wherein the UPF profile includes at least one …, an internet protocol (IP) address of the UPF entity, ….
(“In an example embodiment as depicted in FIG. 21, when a new network function/network element (e.g., UPF, NEF, NIMF, and/or the like) is instantiated or deployed, the new network function may register itself with the NRF or an OAM. The new network function (e.g., the UPF, the NEF, the NIMF) may send a registration message indicating that the new network function may support the CIoT packet transmission, small data transmission, CIoT optimization, CIoT indicator, and/or the like. In an example, the registration message may comprise at least one of a network function profile of the UPF, NEF, or NIMF, an identifier of the UPF, NEF, or NIMF, an S-NSSAI that the new network function may support, a DNN associated with the new network function, and/or the like. In an example, the NRF may be configured by an OAM with information on available UPF(s), NEF(s), NIMF(s). In an example, the registration message may comprise an information element indicating that user plane CIoT optimization, user plane CIoT packet transmission, small data transmission, the CIoT optimization, and/or the like may be supported by the new network function. In an example, the registration message may further comprise an identifier of the UPF/NEF/NIMF, a capability information of the UPF/NEF/NIMF, a traffic routing capability of the UPF/NEF/NIMF, a network function type of the UPF/NEF/NIMF, an IP address (e.g., IPv4, and/or IPv6) of the UPF/NEF/NIMF, a fully qualified domain name (FQDN) of the UPF/NEF/NIMF, a profile of the UPF/NEF/NIMF, a list of supported S-NSSAIs associated with the UPF/NEF/NIMF, and/or the like. In an example, the profile of the UPF/NEF/NIMF may be employed to describe the characteristics of a UPF/NEF/NIMF instance. When an UPF/NEF/NIMF network function instance is instantiated, the associated UPF/NEF/NIMF network function profile may be generated and stored on the UPF/NEF/NIMF network function instance. During a service registration procedure, the UPF/NEF/NIMF network function profile may be registered and stored on the NRF. The profile of the UPF/NEF/NIMF network function may comprise a type of the UPF/NEF/NIMF network function, an FQDN and/or IP address of the UPF/NEF/NIMF network function instance, network slice related identifier(s) e.g. S-NSSAI, network slice instance identifier (NSI ID), UPF/NEF/NIMF network function capacity information, permissions, authorization information, and/or the like.”; Talebi Fard et al.; 0357)
Claim(s) 2, 6, 10 and 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Talebi Fard et al. US 20190313468 (U.S. Patent Application Publications citation #7, listed on IDS dated 2024-08-01) in view of Yang et al. US 20220191294 (U.S. Patent Application Publications citation #19, listed on IDS dated 2024-08-01) and in further view of Taft et al. US 10637753.
As to claim 2:
Talebi Fard et al. as described above does not explicitly teach:
wherein an NF discovery service is to learn about the available UPF.
However, Yang et al. further teaches an available capability which includes:
wherein an NF discovery service is to learn about the available UPF.
(“Requests interface 420 may be configured to respond to discovery requests for particular types of NFs. For example, if an SMF 240 needs to find a UPF device, SMF 240 may send a discovery request to NRF 258 via requests interface 420 for an available UPF 230 and NRF 258 may respond to the discovery request with information identifying one or more available UPFs 230. Transport network KPI interface 430 may be configured to receive information relating to transport network KPIs associated with particular NF devices. For example, an SDN controller associated with a particular NF instance may monitor one or more transport network KPIs associated with the particular NF instance, such as, for example, a packet loss KPI, a packet delay KPI, a load capacity KPI, and/or another type of transport network KPI, and may report the one or more transport network KPIs to NRF 258 via transport network KPI interface 430.”; Taft et al.; col. 11, lines 13-28)
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the available capability of Taft et al. into Talebi Fard et al. By modifying the processing/communications of Talebi Fard et al. to include the available capability as taught by the processing/communications of Taft et al., the benefits of reduced failure rate (Talebi Fard et al.; 0320) with improved discovery (Taft et al.; Abstract) are achieved.
As to claim 6:
Talebi Fard et al. as described above does not explicitly teach:
wherein an NF discovery service is to learn about the available UPF.
However, Yang et al. further teaches an available capability which includes:
wherein an NF discovery service is to learn about the available UPF.
(“Requests interface 420 may be configured to respond to discovery requests for particular types of NFs. For example, if an SMF 240 needs to find a UPF device, SMF 240 may send a discovery request to NRF 258 via requests interface 420 for an available UPF 230 and NRF 258 may respond to the discovery request with information identifying one or more available UPFs 230. Transport network KPI interface 430 may be configured to receive information relating to transport network KPIs associated with particular NF devices. For example, an SDN controller associated with a particular NF instance may monitor one or more transport network KPIs associated with the particular NF instance, such as, for example, a packet loss KPI, a packet delay KPI, a load capacity KPI, and/or another type of transport network KPI, and may report the one or more transport network KPIs to NRF 258 via transport network KPI interface 430.”; Taft et al.; col. 11, lines 13-28)
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the available capability of Taft et al. into Talebi Fard et al. By modifying the processing/communications of Talebi Fard et al. to include the available capability as taught by the processing/communications of Taft et al., the benefits of reduced failure rate (Talebi Fard et al.; 0320) with improved discovery (Taft et al.; Abstract) are achieved.
As to claim 10:
Talebi Fard et al. as described above does not explicitly teach:
wherein an NF discovery service is to learn about the available UPF.
However, Yang et al. further teaches an available capability which includes:
wherein an NF discovery service is to learn about the available UPF.
(“Requests interface 420 may be configured to respond to discovery requests for particular types of NFs. For example, if an SMF 240 needs to find a UPF device, SMF 240 may send a discovery request to NRF 258 via requests interface 420 for an available UPF 230 and NRF 258 may respond to the discovery request with information identifying one or more available UPFs 230. Transport network KPI interface 430 may be configured to receive information relating to transport network KPIs associated with particular NF devices. For example, an SDN controller associated with a particular NF instance may monitor one or more transport network KPIs associated with the particular NF instance, such as, for example, a packet loss KPI, a packet delay KPI, a load capacity KPI, and/or another type of transport network KPI, and may report the one or more transport network KPIs to NRF 258 via transport network KPI interface 430.”; Taft et al.; col. 11, lines 13-28)
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the available capability of Taft et al. into Talebi Fard et al. By modifying the processing/communications of Talebi Fard et al. to include the available capability as taught by the processing/communications of Taft et al., the benefits of reduced failure rate (Talebi Fard et al.; 0320) with improved discovery (Taft et al.; Abstract) are achieved.
As to claim 14:
Talebi Fard et al. as described above does not explicitly teach:
wherein an NF discovery service is to learn about the available UPF.
However, Yang et al. further teaches an available capability which includes:
wherein an NF discovery service is to learn about the available UPF.
(“Requests interface 420 may be configured to respond to discovery requests for particular types of NFs. For example, if an SMF 240 needs to find a UPF device, SMF 240 may send a discovery request to NRF 258 via requests interface 420 for an available UPF 230 and NRF 258 may respond to the discovery request with information identifying one or more available UPFs 230. Transport network KPI interface 430 may be configured to receive information relating to transport network KPIs associated with particular NF devices. For example, an SDN controller associated with a particular NF instance may monitor one or more transport network KPIs associated with the particular NF instance, such as, for example, a packet loss KPI, a packet delay KPI, a load capacity KPI, and/or another type of transport network KPI, and may report the one or more transport network KPIs to NRF 258 via transport network KPI interface 430.”; Taft et al.; col. 11, lines 13-28)
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the available capability of Taft et al. into Talebi Fard et al. By modifying the processing/communications of Talebi Fard et al. to include the available capability as taught by the processing/communications of Taft et al., the benefits of reduced failure rate (Talebi Fard et al.; 0320) with improved discovery (Taft et al.; Abstract) are achieved.
Claim(s) 3, 7, 11 and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Talebi Fard et al. US 20190313468 (U.S. Patent Application Publications citation #7, listed on IDS dated 2024-08-01) in view of Yang et al. US 20220191294 (U.S. Patent Application Publications citation #19, listed on IDS dated 2024-08-01) and in further view of Yang et al. US 20230179669 (U.S. Patent Application Publications citation #22, listed on IDS dated 2024-08-01, hereinafter “Yang2”).
As to claim 3:
Talebi Fard et al. as described above does not explicitly teach:
wherein the NF discovery request message further includes at least one of information on a NF set identifier or ….
However, Yang2 further teaches a set of candidate network entity IDs/NF instance ID capability which includes:
wherein the NF discovery request message further includes at least one of information on a NF set identifier or ….
(“Accordingly, this disclosure proposes a mechanism to enable a network entity (e.g., an NF, a network node) to more efficiently determine whether a “preferred candidate” network entity matches a filter criteria (i.e., satisfies the filter criteria). For example, in one embodiment, the mechanism enables a target AMF to more quickly determine whether or not the current SMF and/or current I-SMF serves the target Tracking Area. For example, in one embodiment, the discovery request (e.g., the NF discovery request) transmitted by a network entity to a network repository entity (NRE) (e.g., an instance of a 5G NRF or a similar repository function and/or node) includes a set of one or more query parameters, wherein the set of query parameters includes a set of N number of candidate network entity identifiers (IDs) (N>0), wherein each candidate network entity ID (e.g., candidate NF instance ID) included in the set of candidate network entity IDs identifies a candidate network entity. The NRE generates a response to the discovery request and transmits the response to the requesting network entity (a.k.a., “service consumer”), wherein the response includes a list of profiles that satisfy the filter criteria of the discovery request. In one embodiment, the list is configured such that, for each network entity ID included in the set of candidate network entity IDs, the profile of the network entity identified by the network entity ID is included in the beginning portion of the list (i.e., within the first N profiles of the list). In one embodiment, a profile of a network entity identified by a network entity ID included in the set of candidate network entity IDs is included in the beginning portion of the list regardless of whether or not the network entity identified by the network entity ID satisfies the filter criteria.”; Yang et al.; 0031)
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the set of candidate network entity IDs/NF instance ID capability of Yang2 into Talebi Fard et al. By modifying the processing/communications of Talebi Fard et al. to include the set of candidate network entity IDs/NF instance ID capability as taught by the processing/communications of Yang2, the benefits of reduced failure rate (Talebi Fard et al.; 0320) with improved efficiency (Yang2; 0035) are achieved.
As to claim 7:
Talebi Fard et al. as described above does not explicitly teach:
wherein the NF discovery request message further includes at least one of information on a NF set identifier or ….
However, Yang2 further teaches a set of candidate network entity IDs/NF instance ID capability which includes:
wherein the NF discovery request message further includes at least one of information on a NF set identifier or ….
(“Accordingly, this disclosure proposes a mechanism to enable a network entity (e.g., an NF, a network node) to more efficiently determine whether a “preferred candidate” network entity matches a filter criteria (i.e., satisfies the filter criteria). For example, in one embodiment, the mechanism enables a target AMF to more quickly determine whether or not the current SMF and/or current I-SMF serves the target Tracking Area. For example, in one embodiment, the discovery request (e.g., the NF discovery request) transmitted by a network entity to a network repository entity (NRE) (e.g., an instance of a 5G NRF or a similar repository function and/or node) includes a set of one or more query parameters, wherein the set of query parameters includes a set of N number of candidate network entity identifiers (IDs) (N>0), wherein each candidate network entity ID (e.g., candidate NF instance ID) included in the set of candidate network entity IDs identifies a candidate network entity. The NRE generates a response to the discovery request and transmits the response to the requesting network entity (a.k.a., “service consumer”), wherein the response includes a list of profiles that satisfy the filter criteria of the discovery request. In one embodiment, the list is configured such that, for each network entity ID included in the set of candidate network entity IDs, the profile of the network entity identified by the network entity ID is included in the beginning portion of the list (i.e., within the first N profiles of the list). In one embodiment, a profile of a network entity identified by a network entity ID included in the set of candidate network entity IDs is included in the beginning portion of the list regardless of whether or not the network entity identified by the network entity ID satisfies the filter criteria.”; Yang et al.; 0031)
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the set of candidate network entity IDs/NF instance ID capability of Yang2 into Talebi Fard et al. By modifying the processing/communications of Talebi Fard et al. to include the set of candidate network entity IDs/NF instance ID capability as taught by the processing/communications of Yang2, the benefits of reduced failure rate (Talebi Fard et al.; 0320) with improved efficiency (Yang2; 0035) are achieved.
As to claim 11:
Talebi Fard et al. as described above does not explicitly teach:
wherein the NF discovery request message further includes at least one of information on a NF set identifier or ….
However, Yang2 further teaches a set of candidate network entity IDs/NF instance ID capability which includes:
wherein the NF discovery request message further includes at least one of information on a NF set identifier or ….
(“Accordingly, this disclosure proposes a mechanism to enable a network entity (e.g., an NF, a network node) to more efficiently determine whether a “preferred candidate” network entity matches a filter criteria (i.e., satisfies the filter criteria). For example, in one embodiment, the mechanism enables a target AMF to more quickly determine whether or not the current SMF and/or current I-SMF serves the target Tracking Area. For example, in one embodiment, the discovery request (e.g., the NF discovery request) transmitted by a network entity to a network repository entity (NRE) (e.g., an instance of a 5G NRF or a similar repository function and/or node) includes a set of one or more query parameters, wherein the set of query parameters includes a set of N number of candidate network entity identifiers (IDs) (N>0), wherein each candidate network entity ID (e.g., candidate NF instance ID) included in the set of candidate network entity IDs identifies a candidate network entity. The NRE generates a response to the discovery request and transmits the response to the requesting network entity (a.k.a., “service consumer”), wherein the response includes a list of profiles that satisfy the filter criteria of the discovery request. In one embodiment, the list is configured such that, for each network entity ID included in the set of candidate network entity IDs, the profile of the network entity identified by the network entity ID is included in the beginning portion of the list (i.e., within the first N profiles of the list). In one embodiment, a profile of a network entity identified by a network entity ID included in the set of candidate network entity IDs is included in the beginning portion of the list regardless of whether or not the network entity identified by the network entity ID satisfies the filter criteria.”; Yang et al.; 0031)
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the set of candidate network entity IDs/NF instance ID capability of Yang2 into Talebi Fard et al. By modifying the processing/communications of Talebi Fard et al. to include the set of candidate network entity IDs/NF instance ID capability as taught by the processing/communications of Yang2, the benefits of reduced failure rate (Talebi Fard et al.; 0320) with improved efficiency (Yang2; 0035) are achieved.
As to claim 15:
Talebi Fard et al. as described above does not explicitly teach:
wherein the NF discovery request message further includes at least one of information on a NF set identifier or ….
However, Yang2 further teaches a set of candidate network entity IDs/NF instance ID capability which includes:
wherein the NF discovery request message further includes at least one of information on a NF set identifier or ….
(“Accordingly, this disclosure proposes a mechanism to enable a network entity (e.g., an NF, a network node) to more efficiently determine whether a “preferred candidate” network entity matches a filter criteria (i.e., satisfies the filter criteria). For example, in one embodiment, the mechanism enables a target AMF to more quickly determine whether or not the current SMF and/or current I-SMF serves the target Tracking Area. For example, in one embodiment, the discovery request (e.g., the NF discovery request) transmitted by a network entity to a network repository entity (NRE) (e.g., an instance of a 5G NRF or a similar repository function and/or node) includes a set of one or more query parameters, wherein the set of query parameters includes a set of N number of candidate network entity identifiers (IDs) (N>0), wherein each candidate network entity ID (e.g., candidate NF instance ID) included in the set of candidate network entity IDs identifies a candidate network entity. The NRE generates a response to the discovery request and transmits the response to the requesting network entity (a.k.a., “service consumer”), wherein the response includes a list of profiles that satisfy the filter criteria of the discovery request. In one embodiment, the list is configured such that, for each network entity ID included in the set of candidate network entity IDs, the profile of the network entity identified by the network entity ID is included in the beginning portion of the list (i.e., within the first N profiles of the list). In one embodiment, a profile of a network entity identified by a network entity ID included in the set of candidate network entity IDs is included in the beginning portion of the list regardless of whether or not the network entity identified by the network entity ID satisfies the filter criteria.”; Yang et al.; 0031)
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the set of candidate network entity IDs/NF instance ID capability of Yang2 into Talebi Fard et al. By modifying the processing/communications of Talebi Fard et al. to include the set of candidate network entity IDs/NF instance ID capability as taught by the processing/communications of Yang2, the benefits of reduced failure rate (Talebi Fard et al.; 0320) with improved efficiency (Yang2; 0035) are achieved.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
US 20190215724 – teaches UPF registering with NRF (see para. 0201).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL K PHILLIPS whose telephone number is (571)272-1037. The examiner can normally be reached M-F 8am-10am, 1pm-5pm.
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, Ricky Ngo can be reached on 571-272-3139. 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.
MICHAEL K. PHILLIPS
Examiner
Art Unit 2464
/MICHAEL K PHILLIPS/Examiner, Art Unit 2464
Prosecution Insights