Prosecution Insights
Last updated: July 17, 2026
Application No. 18/550,600

Message Handling in a Fifth Generation Network

Final Rejection §103
Filed
Sep 14, 2023
Priority
Apr 14, 2021 — EU 21382316.4 +2 more
Examiner
JAIN, SWATI
Art Unit
2649
Tech Center
2600 — Communications
Assignee
Telefonaktiebolaget Lm Ericsson(Publ)
OA Round
2 (Final)
84%
Grant Probability
Favorable
3-4
OA Rounds
0m
Est. Remaining
99%
With Interview

Examiner Intelligence

Grants 84% — above average
84%
Career Allowance Rate
105 granted / 125 resolved
+22.0% vs TC avg
Strong +25% interview lift
Without
With
+25.3%
Interview Lift
resolved cases with interview
Typical timeline
2y 10m
Avg Prosecution
31 currently pending
Career history
153
Total Applications
across all art units

Statute-Specific Performance

§103
93.3%
+53.3% vs TC avg
§102
5.9%
-34.1% vs TC avg
§112
0.6%
-39.4% vs TC avg
Black line = Tech Center average estimate • Based on career data from 125 resolved cases

Office Action

§103
DETAILED ACTION This Office Action is in response to the Applicants' communication filed on April 6, 2026. Claims 33, 42, 43, 47 and 55 are amended. Claims 33-56 are currently pending and have been examined. 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 Arguments Applicant’s arguments/remarks made in an amendment filed April 6, 2026, have been fully considered and is not persuasive. Applicant argues on pages 8-12 that prior art, U.S. Pat. Pubs. 2020/0313996 ("Krishan"), 2015/0163131 ("Bauer") and the 3GPP document C4-201219 ("Huawei") alone or in combination do not disclose “receiving, from a second network node, a message including an indication that a second NF node of the one or more second NF nodes is under testing in the network, wherein the message further indicates the second NF node is a candidate for selection when selecting at least one second NF node of the one or more second NF nodes towards which network traffic is to be transmitted and the message includes load information for the second NF node, that the load information is representative of a predefined amount of network traffic that the second NF node is required to receive for the testing in the network”. Examiner respectfully disagrees as also shown in the detailed action. First, Page 26, lines 7-8 of the specification says, “the second response comprises an indication (e.g. a flag) that the selected second NF node 30 of the one or more second NF nodes 30, 50 is under testing in the network”. So, it is interpreted as the node is under testing and hence prior art discloses service node selection based on load information etc. Page 26, lines 11-13, also says, “That is, the second response advantageously comprises an indication that signals (e.g. flags) that the load information is to be interpreted as the expected amount of network traffic (or load) to be received by the second NF node 30. The second NF node 30 may, for example, require the predefined amount of network traffic to undergo testing (e.g. canary testing) in the network”. Which is interpreted as the network traffic of node 30 is undergoing testing. It is confusing from the claim language if the node is selected for testing or the network traffic is selected for testing. Bauer discloses indication that a second NF node of the one or more second NF nodes is under testing in the network (Fig. 1: 122U: “Under-Test application component”, Fig. 3:310, [0004], “In at least some embodiments, an apparatus includes a processor and a memory communicatively connected to the processor, where the processor is configured to receive traffic intended for a cloud-based application including a set of in-service application components and an under-test application component (NF node under test in the network), distribute a first portion of the received traffic across the set of in-service application components, and direct a second portion of the received traffic to the under-test application component”. [0014], “As depicted in FIG. 1, system 100 includes a set of application traffic sources 102.sub.1-102.sub.N and a cloud environment 110. The cloud environment 110 includes a cloud-based application 120 and an application load balancer 130. The system 100 also may include a test generator depending on whether application traffic or test traffic is used for online testing of grown application capacity of cloud-based application 120”. [0035], “At step 210, a grown application component providing growth of the application capacity of the cloud-based application is set to an UNDER-TEST state. At step 220, the grown application component is tested to determine whether the grown application component is functioning properly. If the grown application component is determined to be functioning properly, method 200 proceeds to step 240, at which point the grown application component is moved from the UNDER-TEST state to an IN-SERVICE state (i.e., the grown application component becomes part of the set of in-service application components of the cloud-based application)”). Huawei discloses receiving, from a second network node, a message that includes load information for the second NF node (Page 6, section 6.3.z.4: Load Control Information, “A NF Service Producer (method performed by second node of sending indication of load in the header) may include one LCI header (LCI header is the indication from the second node) in a service response or in a notification/callback request message sent to a NF Service Consumer”. Page 7, lines 1-2, “The LCI information shall always include the Timestamp, Load Metric and Scope parameters (see clause 5.2.3.2.y for the complete list of parameters)” (load metric is load information in the indication)) and the message further indicates that the second NF node is a candidate for selection when selecting at least one second NF node of the one or more second NF nodes towards which network traffic is to be transmitted (Page 6, lines 6-7, “The NF service consumer that is discovering the NF service producer, may use the available information (e.g. NF capacity information, load information) to select the appropriate NF instance as specified in 3GPP TS 29 .510” (using load based on LCI header to select an appropriate NF producer node)). Further, in view of the amended claims 33, 42, 43, 47 and 55 and upon further consideration, a new ground(s) of rejection, necessitated by the amendments is made in view of different interpretation of the previously applied references as presented in this Office action. Applicant’s arguments with respect to claim(s) 33-56 are therefore moot. 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) 33, 39-43, 46, 47 and 53-56 are rejected under 35 U.S.C. 103 as being unpatentable over US 20200313996 A1 (Krishan) in view of US 20150163131 A1 (Bauer et al.) (hereinafter Bauer) in view of HUAWEI et al.: "Dynamic Load Control", 3GPP DRAFT; 3RD GENERATION PARTNERSHIP PROJECT (3GPP), vol. CT WG4, no. E-Meeting; Feb 17-28, 2020 (hereinafter Huawei) and in further view of US 20220131945 A1 (Sapra et al.) (hereinafter Sapra). In re claims 33 and 47, Krishan discloses a method performed by a first network node and a second network node ([0008], “A method for handling multiple instances of a service provided by one or more producer network functions (NFs) includes, at a service-based architecture (SBA) platform, which may be, for example a 5G proxy, a service communication proxy (SCP), a security protection proxy (SEPP), or any other 5G nodes (as defined in 3GPP release 16)”. [0009], “This procedure can be executed on any consumer NF in 5G architecture, intermediate smart 5G proxies, or other 5G nodes like the SCP”) for handling messages in a fifth generation (5G) network ([0002], “In the 5G network architecture specified by the Third Generation Partnership Project (3GPP), the network function (NF) repository function (NRF) is the network entity that maintains the NF profile of available NF instances and their supporting services”) that includes a first network function (NF) node of a consumer for a service (Fig. 3:300) and one or more second NF nodes of a producer for the service (Fig. 3:304, [0002], “NF functions are the nodes in the 5G system architecture that provide services, in the case of producer NFs, and that consume services, in the case of consumer NFs. The same NF may be both a producer NF and a consumer NF if the NF both consumes and provides services”. [0003], “In FIG. 1, any of the nodes besides NRFs 100 can be either consumer NFs or producer NFs, depending on whether they are requesting or receiving services”), the method comprising: receiving, from a second network node, a message including an indication that a second NF node of the one or more second NF nodes is under testing in the network, wherein the message further indicates one or more of the following: that the second NF node is a candidate for selection when selecting at least one second NF node of the one or more second NF nodes towards which network traffic is to be transmitted; and when the message includes load information for the second NF node ([0004], “Producer NFs can register capacity and priority information with the NRF. Consumer NFs can discover producers that have registered to provide a specific service and can use the capacity and priority information to select a producer NF” (selection of producer node based on load information)), that the load information is representative of a predefined amount of network traffic that the second NF node is required to receive for the testing in the network, wherein the first network node is the first NF node or a first service communication proxy (SCP) node configured to operate as an SCP between the first NF node and the one or more second NF nodes (Fig. 3:300, [0009], “This procedure can be executed on any consumer NF in 5G architecture, intermediate smart 5G proxies, or other 5G nodes like the SCP or SEPP (as defined in 3GPP release 16)...An SCP is a smart 5G proxy that can reside between a producer and a consumer NF”. [0024], “According to yet another aspect of the subject matter described herein, the network node comprises a proxy separate from the consumer NF that performs the selecting of the producer NF” (here SCP). [0061], “In the example above in Table 2, consumer NF1 will first contact producer NF1” (here first network node)). Krishan does not explicitly disclose receiving, from a second network node, a message including an indication that a second NF node of the one or more second NF nodes is under testing in the network. Bauer discloses indication that a second NF node of the one or more second NF nodes is under testing in the network (Fig. 1: 122U: “Under-Test application component”, Fig. 3:310, [0004], “In at least some embodiments, an apparatus includes a processor and a memory communicatively connected to the processor, where the processor is configured to receive traffic intended for a cloud-based application including a set of in-service application components and an under-test application component (NF node under test in the network), distribute a first portion of the received traffic across the set of in-service application components, and direct a second portion of the received traffic to the under-test application component”. [0014], “As depicted in FIG. 1, system 100 includes a set of application traffic sources 102.sub.1-102.sub.N and a cloud environment 110. The cloud environment 110 includes a cloud-based application 120 and an application load balancer 130. The system 100 also may include a test generator depending on whether application traffic or test traffic is used for online testing of grown application capacity of cloud-based application 120”. [0035], “At step 210, a grown application component providing growth of the application capacity of the cloud-based application is set to an UNDER-TEST state. At step 220, the grown application component is tested to determine whether the grown application component is functioning properly. If the grown application component is determined to be functioning properly, method 200 proceeds to step 240, at which point the grown application component is moved from the UNDER-TEST state to an IN-SERVICE state (i.e., the grown application component becomes part of the set of in-service application components of the cloud-based application)”). It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Krishan with Bauer to provide a method for distributing traffic among the second network nodes of the network, based on a first indication whether the second NF node is under test or not. The advantage of doing so is to load balance the network traffic and select an appropriate node while enabling the grown application capacity of a cloud-based application to be tested and validated while the application remains online for handling of application traffic. Krishan and Bauer do not explicitly disclose receiving, from a second network node, a message including an indication that includes load information for the second NF node and the indication further indicates that the second NF node is a candidate for selection when selecting at least one second NF node of the one or more second NF nodes towards which network traffic is to be transmitted. Huawei discloses receiving, from a second network node, a message including an indication (Page 6, section 6.3.z.4: Load Control Information, “A NF Service Producer (method performed by second node of sending indication of load in the header) may include one LCI header (LCI header is the indication from the second node) in a service response or in a notification/callback request message sent to a NF Service Consumer” (method performed by first node of sending service request)) that includes load information for the second NF node (Page 7, lines 1-2, “The LCI information shall always include the Timestamp, Load Metric and Scope parameters (see clause 5.2.3.2.y for the complete list of parameters)” (load metric is load information in the indication)) and the indication further indicates that the second NF node is a candidate for selection when selecting at least one second NF node of the one or more second NF nodes towards which network traffic is to be transmitted (Page 6, lines 6-7, “The NF service consumer that is discovering the NF service producer, may use the available information (e.g. NF capacity information, load information) to select the appropriate NF instance as specified in 3GPP TS 29 .510” (using load based on LCI header to select an appropriate NF producer node)). It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Krishan and Bauer with Huawei to provide a method for distributing traffic among the second network nodes of the network, based on a first indication whether the second NF node is under test or not. The advantage of doing so is to load balance the network traffic and select an appropriate node while enabling the grown application capacity of a cloud-based application to be tested and validated while the application remains online for handling of application traffic. Krishan, Bauer and Huawei do not explicitly disclose that the load information is representative of a predefined amount of network traffic that the second NF node is required to receive for the testing in the network. Sapra discloses that the load information is representative of a predefined amount of network traffic that the second NF node is required to receive (Fig. 2-4, [0129], “Producer network function 304 sends a current load value (for example, load: 40%) to NRF 302 in a first message 310”. [0013], “In some examples, the network function discovery node is configured for registering each of the producer network functions and, during registration, receiving the published capacity of the producer network function”. [0014], “In some examples, the network function discovery node is a network function (NF) repository function (NRF) or a service communications proxy (SCP)”. [0048], “In some examples, the NRF processes the discovery procedure output and assigns an available capacity based on the current load of the producer network function as follows: CA=PC−(PL*PC)”. [0052], “PL=published load of the network function instance (in %)” (discloses a predetermined load transmitted to the network function discover node by the producer network function). [0089], “NRF 108 can be configured for tasks such as load balancing”. [0094], “Storing such information at NRF 108 can lead to better network function selection decision making at NRF 108”). It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Krishan, Bauer and Huawei with Sapra to provide a method for distributing traffic among the second network nodes of the network, based on a first indication whether the second NF node is under test or not. The advantage of doing so is to load balance the network traffic and select an appropriate node while enabling the grown application capacity of a cloud-based application to be tested and validated while the application remains online for handling of application traffic. In re claims 39 and 53, the combination discloses the method of claim 33 and the method of claim 47, wherein Huawei discloses wherein the message includes a load control information (LCI) header, which includes the indication (Page 6, section 6.3.z.4: Load Control Information, “A NF Service Producer (second node) may include one LCI header (LCI header is the indication from the second node) in a service response or in a notification/callback request message sent to a NF Service Consumer” (first node). Page 7, lines 1-2, “The LCI information shall always include the Timestamp, Load Metric and Scope parameters (see clause 5.2.3.2.y for the complete list of parameters)” (header includes the indication of load)). In re claim 40, the combination discloses the method of claim 33, wherein Huawei discloses further comprising selecting, based on the indication, atleast one of the one or more second NF nodes towards which network traffic is to be transmitted (Page 6, lines 6-7, “The NF service consumer that is discovering the NF service producer, may use the available information (e.g. NF capacity information, load information) to select the appropriate NF instance as specified in 3GPP TS 29 .510” (using load based on LCI header to select an appropriate NF producer node)). In re claims 41 and 54, the combination discloses the method of claim 33 and the method of claim 47, wherein Krishan discloses wherein one or more of the following applies: selecting the at least one second NF node is for the at least one second NF node to provide a service requested by the first NF node ([0004], “Producer NFs register with the NRF to indicate the type of services that producer NFs provide. Producer NFs can register capacity and priority information with the NRF. Consumer NFs can discover producers that have registered to provide a specific service and can use the capacity and priority information to select a producer NF”. [0049], “In model 3 in FIG. 3, consumer NFs 300 and 302 detect the need for a service Svc1 provided by producer NF 304”); and the network traffic comprises a service request for provision of the service requested by the first NF node ([0053], “In operation, SBA platform 400 detects a need for a service to be provided to consumer NF 402 in response to receiving a message from consumer NF 402”). In re claims 42 and 55, the combination discloses the method of claim 33 and the method of claim 47, wherein Krishan discloses wherein the predefined amount of network traffic that the second NF node is required to receive for the testing in the network is a predefined percentage of a total amount of network traffic available for transmission ([0060], “In FIG. 4, SBA platform 400 determines that 70% of the service traffic should be routed to service instance 408 and 30% should be routed to service instance 412, both of which implement the current or older version of the service. This determination may be made based on the requests received from consumer NF or based on published capacities and load of older service instances 408 and 412 only. Of the 70% of traffic that should be routed to older service instance 408, SBA platform 400 routes X % of 70% (i.e. overall traffic destined for producer 404) to service instance 408 and Y % of 70% to new service instance 410. X and Y may be percentages determined based on published service capacity (weight) or based on an operator configured ratio”). In re claim 43, the combination discloses the method of claim 33, wherein Krishan discloses the method further comprising initiating transmission, towards the second NF node, of the predefined amount of network traffic that the second NF node is required to receive for the testing in the network ([0017], “the process of canary testing includes receiving, from a network function repository function (NRF) and during the canary testing, updated capacities for the first and second service instances and dynamically changing the relative amounts of traffic being sent to the first and second service instances during the canary testing”. [0004], “producer NFs register with the NRF to indicate the type of services that producer NFs provide. Producer NFs can register capacity and priority information with the NRF. Consumer NFs can discover producers that have registered to provide a specific service and can use the capacity and priority information to select a producer NF” (transmitting traffic on the selected second NF node based on published capacity)). In re claims 46 and 56, the combination discloses the method of claim 33 and the method of claim 47, wherein Krishan discloses the first and the second network node comprising processing circuitry configured to perform the methods of claim 33 and claim 47 (Fig. 6:600, [0091], “Referring to FIG. 6, SBA platform 400 includes at least one processor 600 and a memory 602”). Claim(s) 34-38, 44, 45 and 48-52 are rejected under 35 U.S.C. 103 as being unpatentable over US 20200313996 A1 (Krishan) in view of US 20150163131 A1 (Bauer et al.) (hereinafter Bauer) in view of HUAWEI et al.: "Dynamic Load Control", 3GPP DRAFT; 3RD GENERATION PARTNERSHIP PROJECT (3GPP), vol. CT WG4, no. E-Meeting; Feb 17-28, 2020 (hereinafter Huawei in view of US 20220131945 A1 (Sapra et al.) (hereinafter Sapra) and in further view of WO 2021251948 A1 (SHARMA). In re claims 34 and 48, the combination discloses the method of claim 33 and the method of claim 47, but does not explicitly disclose wherein: the message includes a profile of the second NF node, the indication is included in the profile, and when the message includes the load information, the load information is included in the profile. Sharma discloses wherein: the message includes a profile of the second NF node, the indication is included in the profile, and when the message includes the load information, the load information is included in the profile (Page 2, lines 23-27, “The processor causes the NF service consumer to query an NRF to discover a plurality of NF service producers, and to receive NF profiles associated with the NF service producers from the NRF. The processor causes the NF service consumer to parse the NF profiles to identify localities of the NF service producers” (message includes profile that is parsed by the consumer node). Page 2, lines 14-19, “Within each NF group, the NF service consumer apportions the group workload share into NF workload shares that are attributed to the individual NF service producers in the NF group, such as based on the locality of the NF service producers, capacity values in the NF profiles, dynamic load information at the NF service producers, etc. Based on this information, the NF service consumer is able to distribute service requests to one or more of the NF service producers” (profile includes load information)). It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Krishan, Bauer, Huawei and Sapra with SHARMA to provide a method for distributing traffic among the second network nodes of the network, based on the profiles of the producer nodes that includes load information. The advantage of doing so is to load balance the network traffic and select an appropriate node while enabling the grown application capacity of a cloud-based application to be tested and validated while the application remains online for handling of application traffic. In re claims 35 and 49, the combination discloses the method of claim 34 and the method of claim 48, wherein SHARMA discloses wherein the profile comprises one or more attributes for the second NF node, and one of the attributes is set to the indication (Page 3, lines 18-21, “In another embodiment, the processor causes the NF service consumer to parse the NF profiles to identify capacity values assigned to the NF service producers of the NF groups, and to apportion the group workload shares into the NF workload shares for the NF service producers within the NF groups based on the capacity values” (here attribute in the profile is capacity values). Page 3, lines 31-32; page 4, line 1, “In another embodiment, the processor causes the NF service consumer to parse the NF profiles to identify load values indicated for the NF service producers within an NF group, to identify an overload threshold” (here attribute in the profile is load values of the NF nodes)). In re claims 36 and 50, the combination discloses the method of claim 35 and the method of claim 49, wherein SHARMA discloses wherein the attribute set to the indication is one or more of the following: a locality attribute indicative of a location of the second NF node; an attribute to be prioritized when selecting the at least one second NF node; and an attribute that at least partially matches a corresponding attribute for the first NF node (Page 4, lines 18-27, “The method comprises parsing the NF profiles to identify localities of the NF service producers, and arranging the NF service producers based on the localities. For a locality, the method comprises parsing the NF profiles to identify priority values assigned to the NF service producers for the locality, identifying one or more NF groups for the locality that share a priority value of the priority values, apportioning a workload for the NF service consumer into group workload shares for the NF groups of the locality based on the priority values for the NF groups, and apportioning the group workload shares into NF workload shares for the NF service producers within the NF groups of the locality”). In re claims 37 and 51, the combination discloses the method of claim 34 and the method of claim 48, wherein Krishan discloses wherein: the second network node is a network repository function (NRF) node ([0003], “In FIG. 1, any of the nodes besides NRFs 100 can be either consumer NFs or producer NFs, depending on whether they are requesting or receiving services”; and the message is received in response to one or more of the following: a change to the load information ([0020], “the canary tester is configured to receive (through NRF subscribe and notify procedures), from a network function repository function (NRF) and during the canary testing, updated capacities (change in load) for the first and second service instances and dynamically change the relative amounts of traffic being sent to the first and second service instances during the canary testing”. [0046], “For scaled service variants, consumer(s) may perform load-balancing between multiple service instances from the same provider NF. For backward compatible API version instances, the consumer NF may perform load balancing or canary testing between service instances”); and wherein SHARMA discloses a discovery request for information indicative of producers of a service requested by the first NF node (Page 1, lines 26-32; Page 2, lines 1-2, “For the service discovery function, the NRF receives NF Discovery Requests from NF instances, and provides the information of the available NF instances fulfilling certain criteria (e.g., supporting a given service). The roles of NFs with the 5GC may be defined as a service consumer and a service producer. An NF service producer is an NF that exposes a service, and an NF service consumer is an NF that requests a service. The NRF stores the NF profiles of the NF service producers, and the NF service consumers are able to query the NRF with a discovery function to obtain the NF profiles of the NF service producers”). In re claims 38 and 52, the combination discloses the method of claim 34 and the method of claim 48, wherein SHARMA discloses wherein the second network node is the second NF node, and the message is a response to a service request for the second NF node to provide a service requested by the first NF node (Page 12, lines 23-24, “In response to the discover service request, NRF 326 provides information for the NF(s) that match the input parameters to NF service consumer 402”. Page 12, lines 31-32; Page 13, lines 1-2, “In FIG. 7, NF service consumer 402 sends an NF service request to an NF service producer 404 for one or more of the CP transactions. The NF service producer 404 then provides a service based on the NF service request from NF service consumer 402”. Page 13, lines 3-4, “As illustrated in FIG. 7, NF service consumer 402 sends a service request to NF service producer 404”). In re claim 44, the combination discloses the method of claim 43, but does not explicitly disclose wherein the one or more second NF nodes include a plurality of second NF nodes, and the method further comprising initiating transmission, towards at least one other of the plurality of second NF nodes, of a remaining amount of network traffic available for transmission. SHARMA discloses wherein the one or more second NF nodes include a plurality of second NF nodes, and the method further comprising initiating transmission, towards at least one other of the plurality of second NF nodes, of a remaining amount of network traffic available for transmission (Page 16, lines 5-15, “NF service consumer 802 has a requirement to fulfill a workload 1300, which is a theoretical representation of a number of service requests to be distributed by NF service consumer 802 to NF service producers 404. For the example shown in FIG. 13, it is assumed that three NF groups were identified. Thus, workload distributor 812 apportions or divides workload 1300 into group workload shares 1302 that are attributed to the NF groups. Within the NF groups, workload distributor 812 apportions or divides a group workload share 1302 into NF workload shares 1304 that are attributed to the individual NF service producers 404 in the NF group. NF workload shares 1304 are a fair share of the group workload share 1302 among the NF service producers 404 in the NF group. Based on this information, workload distributor 812 is able to distribute service requests to one or more of the NF service producers 404” (plurality of second NF as a NF group. Workload distributor apportions or divides the workload attributed to the NF groups for the remaining amount of network traffic available)). It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Krishan, Bauer, Huawei and Sapra with SHARMA to provide a method for distributing traffic among the second network nodes of the network, based on the profiles of the producer nodes that includes load information. The advantage of doing so is to load balance the network traffic and select an appropriate node while enabling the grown application capacity of a cloud-based application to be tested and validated while the application remains online for handling of application traffic. In re claim 45, the combination discloses the method of claim 44, wherein SHARMA discloses wherein transmission of the remaining amount of network traffic is initiated towards at least two other of the plurality of second NF nodes with a distribution that balances load on the at least two other second NF nodes (Page 15, lines 29-32; Page 16, lines 1-4, “The NF service producers 404 having the same priority value (or within a particular range) are grouped together in an “NF group” or “NF band” for the locality. For example, if the same priority value has been assigned to three NF service producers 404, then these three NF service producers 404 are assumed to belong to the same NF group. Each NF group has an associated priority value. Workload distributor 812 determines a share of traffic or workload to be handled by the different NF groups, which is referred to a group workload share” (example shows load distribution for share of traffic on the three remaining NF nodes)). Conclusion Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action. Contact Any inquiry concerning this communication or earlier communications from the examiner should be directed to SWATI JAIN whose telephone number is (571)270-0699. The examiner can normally be reached Mon - Fri (830 am - 530 pm). 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, Pan Yuwen can be reached on 571-272-7855. 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. /SWATI JAIN/Examiner, Art Unit 2649 /YUWEN PAN/Supervisory Patent Examiner, Art Unit 2649
Read full office action

Prosecution Timeline

Sep 14, 2023
Application Filed
Jan 06, 2026
Non-Final Rejection mailed — §103
Apr 06, 2026
Response Filed
Jun 10, 2026
Final Rejection mailed — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12676667
LENSING USING LOWER EARTH ORBIT REPEATERS
3y 10m to grant Granted Jul 07, 2026
Patent 12677141
Request to Store Information for a Plurality of Cells
3y 7m to grant Granted Jul 07, 2026
Patent 12672032
EI SIGNALLING FOR GROUP HANDOVER
3y 5m to grant Granted Jun 30, 2026
Patent 12672096
EMERGENCY RESPONSE (ER) SYSTEM FOR HYBRID WORK SOFTPHONE MOBILE DEVICES IN SDA/SDN FABRIC NETWORKS
2y 9m to grant Granted Jun 30, 2026
Patent 12672104
METHOD FOR TRANSMITTING INFORMATION, USER EQUIPMENT, ACCESS NETWORK DEVICE, AND CORE NETWORK
2y 8m to grant Granted Jun 30, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

3-4
Expected OA Rounds
84%
Grant Probability
99%
With Interview (+25.3%)
2y 10m (~0m remaining)
Median Time to Grant
Moderate
PTA Risk
Based on 125 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month