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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on February 24th, 2025 has been entered.
In this office action:
Claims 38-57 are pending.
Claims 38-57 are rejected.
Response to Amendment
The amendments filed on February 24th, 2025 have been entered.
Claims 18-27 and 30-37 have been canceled.
Claims 38-57 have been added.
Response to Arguments
Applicant’s arguments/remarks filed on February 24th, 2025 have fully considered, but are moot in view of the new grounds of rejection as presented in this Office Action.
The independent claim(s), as amended, recite(s):
obtaining one or more of the following information from respective profiles for the one or more second NF nodes:
a first indication that the second NF node is under testing and a predefined amount of network traffic required by the second NF node for the testing;
a network traffic capacity for the second NF node;
and an amount of network traffic currently handled by the second NF node
The Examiner note that the claim is interpreted as: “obtaining one or more of the following information from respective profiles for the one or more second NF nodes: a network traffic capacity for the second NF node.”
Based on the broadest reasonable interpretation of the claim language, the claim(s) require(s) at least one information to be obtained.
Claim Objections
Claim 38 and 48 are objected to because of the following informality:
“for each second NF node whose profile includes the first indication, the predefined amount of traffic required by the second NF node for the testing” should read (Examiner’s suggestion) “for each second NF node whose profile includes the first indication, the predefined amount of network traffic required by the second NF node for the testing.”
Appropriate correction(s) is/are required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 38-57 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 38 and 48 recite:
distributing network traffic for executing the service among the one or more second NF nodes based on the information obtained from the respective profiles and according to traffic distribution criteria including the following:
for each second NF node whose profile includes the first indication, the predefined amount of traffic required by the second NF node for the testing, which results in a remaining network traffic to be distributed; and
for remaining second NF nodes whose profiles does not include the first indication: when all profiles for the remaining second NF nodes indicate the amount of network traffic currently handled, the remaining network traffic among the remaining second NF nodes according to respective differences between the network traffic capacities and the amounts of network traffic currently handled for the remaining second NF nodes
It’s unclear what is exactly the distribution criteria are and how they contribute in distributing network traffic for executing the service among the one or more second NF nodes. Therefore, the Examiner is unable to determine the metes and the bounds of the claim language.
Claims 39-47 are rejected under 35 U.S.C. 112(b), as they depend on the rejected claim 38.
In addition, claim 39 recites:
wherein the traffic distribution criteria also include the following:
when none of the profiles include the first indication and at least one of the profiles does not indicate the amount of traffic currently handled, the network traffic among the one or more second NF nodes according to the respective network traffic capacities of the one or more second NF nodes; and
when none of the profiles include the first indication and all of the profiles indicate the amount of network traffic currently handled, the network traffic among the one or more second NF nodes according to respective differences between the network traffic capacities and the amounts of network traffic currently handled for the one or more second NF nodes.
It’s unclear what is exactly the distribution criteria are and how they contribute in distributing network traffic for executing the service among the one or more second NF nodes. Therefore, the Examiner is unable to determine the metes and the bounds of the claim language.
In addition, claim 40 recites:
wherein the traffic distribution criteria also include the following for remaining second NF nodes whose profiles does not include the first indication:
when one or more profiles for the remaining second NF nodes do not indicate the amount of network traffic currently handled, the remaining traffic among the remaining second NF nodes according to respective network traffic capacities for the remaining second NF nodes, irrespective of the amounts of network traffic currently handled by the remaining second NF nodes.41. (New) The method of claim 40, wherein the remaining traffic is distributed among the remaining second NF nodes irrespective of the amounts of network traffic currently handled by the remaining second NF nodes, except when the amount of network traffic currently handled by at least one of the remaining second NF nodes is at a maximum load capability.
It’s unclear what is exactly the distribution criteria are and how they contribute in distributing network traffic for executing the service among the one or more second NF nodes. Therefore, the Examiner is unable to determine the metes and the bounds of the claim language.
Claims 49-57 are rejected under 35 U.S.C. 112(b), as they depend on the rejected claim 48.
In addition, claim 49 recites:
wherein the traffic distribution criteria also include the following:
when none of the profiles include the first indication and at least one of the profiles does not indicate the amount of traffic currently handled, the network traffic among the one or more second NF nodes according to the respective network traffic capacities of the one or more second NF nodes; and
when none of the profiles include the first indication and all of the profiles indicate the amount of network traffic currently handled, the network traffic among the one or more second NF nodes according to respective differences between the network traffic capacities and the amounts of network traffic currently handled for the one or more second NF nodes.
It’s unclear what is exactly the distribution criteria are and how they contribute in distributing network traffic for executing the service among the one or more second NF nodes. Therefore, the Examiner is unable to determine the metes and the bounds of the claim language.
In addition, claim 50 recites:
wherein the traffic distribution criteria also include the following for remaining second NF nodes whose profiles does not include the first indication:
when one or more profiles for the remaining second NF nodes do not indicate the amount of network traffic currently handled, the remaining traffic among the remaining second NF nodes according to respective network traffic capacities for the remaining second NF nodes, irrespective of the amounts of network traffic currently handled by the remaining second NF nodes.41. (New) The method of claim 40, wherein the remaining traffic is distributed among the remaining second NF nodes irrespective of the amounts of network traffic currently handled by the remaining second NF nodes, except when the amount of network traffic currently handled by at least one of the remaining second NF nodes is at a maximum load capability.
It’s unclear what is exactly the distribution criteria are and how they contribute in distributing network traffic for executing the service among the one or more second NF nodes. Therefore, the Examiner is unable to determine the metes and the bounds of the claim language.
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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 38-57 are rejected under 35 U.S.C. 103 as being unpatentable over Sapra et al. (Pub. No. US 2022/0131945), hereinafter Sapra; in view of Sharma (WO 2021/251948); and further in view of Krishan et al. (Patent No. US 10,791,044), hereinafter Krishan.
Claim 38. Sapra discloses [a] method performed by a network node for handling execution of a service in a network that includes a first network function (NF) node of a consumer for the service and one or more second NF nodes of a producer for the service (See Parag. [0009]; network function discovery node (network node); consumer network function (first network function (NF) node of a consumer); producer network function(s) (one or more second NF nodes of a producer for the service). See Parag. [0014]; the network function discovery node is a network function (NF) repository function (NRF) or a service communications proxy (SCP)), the method comprising:
obtaining one or more of the following information from respective profiles for the one or more second NF nodes (See Parag. [0080-0081]; NRF supports the following functions: Maintains the profiles of the available NF instances and their supported services in the 5G core network):
a first indication that the second NF node is under testing and a predefined amount of network traffic required by the second NF node for the testing; a network traffic capacity for the second NF node; and an amount of network traffic currently handled by the second NF node (See Parag. [0140-0142]; method 400 can be performed by an NRF or SCP, or any other appropriate network function discovery node … registering producer network functions (402). During registration, method 400 can include receiving a load reporting interval specifying a rate of load reporting for the producer network function. Method 400 can include, during registration, receiving a load reporting interval specifying a rate of load reporting for the producer network function. Registration can also include receiving, e.g., a published capacity, a permissible load threshold, an abatement load threshold, and any other appropriate information (i.e., a network traffic capacity for the second NF node). See also Parag. [0124]); and
distributing network traffic for executing the service among the one or more second NF nodes based on the information obtained from the respective profiles and according to traffic distribution criteria including the following:
for each second NF node whose profile includes the first indication, the predefined amount of traffic required by the second NF node for the testing, which results in a remaining network traffic to be distributed (See Parag. [0106-0112]; determining, for each producer network function, an available capacity for the producer network function based on the current load value and a published capacity of the producer network function … dynamic load receiver assigns an available capacity based on the current load of the producer network function as follows: C.sub.A=P.sub.C−(P.sub.L*P.sub.C); where, C.sub.A=available capacity of a network function instance; P.sub.C=published capacity of the network function instance; and P.sub.L=published load of the network function instance (in %). See also Parag. [0020] [0129]; (load: 40%). Examiner’s note: Sapra discloses assigning capacity for each producer network function based on the current load of the producer network function. It is known in the art that "Network function capacity" refers to the maximum amount of data a specific network function can process and transfer within a given timeframe, reflecting the ability to handle traffic on a network. In addition, the applicant teaches in the specification identifying that network traffic for executing the service is to be distributed among the second NF nodes according to a capacity of one or more of the second NF nodes (Specification, Page 4 lines 29-32)).
Sapra doesn’t explicitly disclose the first indication as a first indication that the second NF node is under testing; [and] for remaining second NF nodes whose profiles does not include the first indication: when all profiles for the remaining second NF nodes indicate the amount of network traffic currently handled, the remaining network traffic among the remaining second NF nodes according to respective differences between the network traffic capacities and the amounts of network traffic currently handled for the remaining second NF nodes.
However, Sharma discloses:
for remaining second NF nodes whose profiles does not include the first indication:
when all profiles for the remaining second NF nodes indicate the amount of network traffic currently handled, the remaining network traffic among the remaining second NF nodes according to respective differences between the network traffic capacities and the amounts of network traffic currently handled for the remaining second NF nodes (See Page 16 lines 1-4; Workload distributor determines a share of traffic or workload to be handled by the different NF groups, which is referred to a group workload share. See Page 19 lines 1-16; within an NF group, workload distributor calculates initial NF workload values for NF service producers within the NF group based on the capacity values. To do so, workload distributor calculates a total capacity of the NF service producers within the NF group, and calculates a percentage of the total capacity for each of the NF service producers within the NF group by dividing a respective capacity value for an NF service producer by the total capacity. Workload distributor then calculates initial NF workload values for the NF service producers by multiplying a respective percentage of the total capacity with the group workload value for the NF group. The initial NF workload values represent the proportion of a group workload share (i.e., the NF workload share) that is attributed to each of NF service producers within the NF group based on the capacity values of the NF service producers. See Page 14 lines 15-25; There may be situations where information for one or more of attributes are not specified by an NF service producer when registering with NRF… When attributes are not specified, NRF or an NF service consumer may handle the absence of these attributes as follows… When the load attribute is not specified, the load value may be set to a normal operating region. See Page 24 lines 12-16; With the workload 1300 apportioned into group workload shares 1302, NF service
consumer 802 parses the NF profiles 820 to identify capacity values assigned to the NF service producers 404 of the NF group 1402, and apportions the group workload shares 1302 into NF workload shares 1304 for the NF service producers 404 within the NF groups 1402 based on the capacity values. Examiners’ interpretation: When the load attribute is not specified, the service is to be distributed among said one or more of the second NF nodes according to the other attributes (e.g., capacity) of the one or more of the second NF nodes for which load information is specified).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the network function discovery node, taught by Sapra, such that when all profiles for the remaining second NF nodes indicate the amount of network traffic currently handled, the remaining network traffic among the remaining second NF nodes according to respective differences between the network traffic capacities and the amounts of network traffic currently handled for the remaining second NF nodes, as taught by Sharma. This would be convenient to apportion the group workload share for each of the NF groups (Sharma, Page 19 lines 16-17).
Sapra in view of Sharma doesn’t explicitly disclose the first indication as a first indication that the second NF node is under testing.
However, Krishan discloses a first indication that the second NF node is under testing (See Col. 3 lines 50-67; system includes an application programming interface (API) decoder for obtaining first and second application programming interface (API) version indicators associated with first and second service instances implemented by one or more producer NFs, decoding the first and second API version indicators, and detecting, based on results of the decoding, multiple instances of the same service and that a first service instance is backward compatible with a second service instance. The system further includes a canary tester for, responsive to the API decoder detecting that the first and second service instances implement multiple versions of the same service (from a single producer NF) and that the first service instance is backward compatible with the second service instance, implementing canary testing of the first service instance).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the network function discovery node, taught by Sapra in view of Sharma, to obtain a first indication that the second NF node is under testing, as taught by Krishan. This would be convenient for handling multiple versions of the same service provided by producer NFs (Krishan, Col. 2 lines 20-22).
Claim 39. Sapra in view of Sharma and Krishan discloses [t]he method of claim 38,
Sapra further discloses wherein the traffic distribution criteria also include the following:
when none of the profiles include the first indication and all of the profiles indicate the amount of network traffic currently handled, the network traffic among the one or more second NF nodes according to respective differences between the network traffic capacities and the amounts of network traffic currently handled for the one or more second NF nodes (See Parag. [0106-0112]; determining, for each producer network function, an available capacity for the producer network function based on the current load value and a published capacity of the producer network function … dynamic load receiver assigns an available capacity based on the current load of the producer network function as follows: C.sub.A=P.sub.C−(P.sub.L*P.sub.C); where, C.sub.A=available capacity of a network function instance; P.sub.C=published capacity of the network function instance; and P.sub.L=published load of the network function instance (in %). See also Parag. [0020] [0129]; (load: 40%). Examiner’s note: Sapra discloses assigning capacity for each producer network function based on the current load of the producer network function. It is known in the art that "Network function capacity" refers to the maximum amount of data a specific network function can process and transfer within a given timeframe, reflecting the ability to handle traffic on a network. In addition, the applicant teaches in the specification identifying that network traffic for executing the service is to be distributed among the second NF nodes according to a capacity of one or more of the second NF nodes (Specification, Page 4 lines 29-32)).
Sharma further discloses when none of the profiles include the first indication and at least one of the profiles does not indicate the amount of traffic currently handled, the network traffic among the one or more second NF nodes according to the respective network traffic capacities of the one or more second NF nodes (See Page 16 lines 1-4; Workload distributor determines a share of traffic or workload to be handled by the different NF groups, which is referred to a group workload share. See Page 19 lines 1-16; within an NF group, workload distributor calculates initial NF workload values for NF service producers within the NF group based on the capacity values. To do so, workload distributor calculates a total capacity of the NF service producers within the NF group, and calculates a percentage of the total capacity for each of the NF service producers within the NF group by dividing a respective capacity value for an NF service producer by the total capacity. Workload distributor then calculates initial NF workload values for the NF service producers by multiplying a respective percentage of the total capacity with the group workload value for the NF group. The initial NF workload values represent the proportion of a group workload share (i.e., the NF workload share) that is attributed to each of NF service producers within the NF group based on the capacity values of the NF service producers. See Page 14 lines 15-25; There may be situations where information for one or more of attributes are not specified by an NF service producer when registering with NRF… When attributes are not specified, NRF or an NF service consumer may handle the absence of these attributes as follows… When the load attribute is not specified, the load value may be set to a normal operating region).
Claim 40. Sapra in view of Sharma and Krishan discloses [t]he method of claim 38,
Sharma further discloses wherein the traffic distribution criteria also include the following for remaining second NF nodes whose profiles does not include the first indication:
when one or more profiles for the remaining second NF nodes do not indicate the amount of network traffic currently handled, the remaining traffic among the remaining second NF nodes according to respective network traffic capacities for the remaining second NF nodes, irrespective of the amounts of network traffic currently handled by the remaining second NF nodes (See Page 16 lines 1-4; Workload distributor determines a share of traffic or workload to be handled by the different NF groups, which is referred to a group workload share. See Page 19 lines 1-16; within an NF group, workload distributor calculates initial NF workload values for NF service producers within the NF group based on the capacity values. To do so, workload distributor calculates a total capacity of the NF service producers within the NF group, and calculates a percentage of the total capacity for each of the NF service producers within the NF group by dividing a respective capacity value for an NF service producer by the total capacity. Workload distributor then calculates initial NF workload values for the NF service producers by multiplying a respective percentage of the total capacity with the group workload value for the NF group. The initial NF workload values represent the proportion of a group workload share (i.e., the NF workload share) that is attributed to each of NF service producers within the NF group based on the capacity values of the NF service producers. See Page 14 lines 15-25; There may be situations where information for one or more of attributes are not specified by an NF service producer when registering with NRF… When attributes are not specified, NRF or an NF service consumer may handle the absence of these attributes as follows… When the load attribute is not specified, the load value may be set to a normal operating region. Examiners’ interpretation: When the load attribute is not specified, the service is to be distributed among said one or more of the second NF nodes according to the other attributes (e.g., capacity) of the one or more of the second NF nodes for which load information is specified).
Claim 41. Sapra in view of Sharma and Krishan discloses [t]he method of claim 40,
Sapra further discloses wherein the remaining traffic is distributed among the remaining second NF nodes irrespective of the amounts of network traffic currently handled by the remaining second NF nodes, except when the amount of network traffic currently handled by at least one of the remaining second NF nodes is at a maximum load capability (See Parag. [0124]; discovery request handler (Note: of the network function discovery node) may receive a producer network function discovery request from a consumer network function; determine a list of a producer network functions that are responsive to one or more criteria in the producer network function discovery request; and send a network function discovery response back to the consumer network function with a list of identifiers for the producer network functions. The list may be, for example, sorted by available capacity or priority, or the network function discovery response may include the available capacities and/or priority values for the producer network functions on the list. See Parag. [0126]; network function discovery node is configured for determining, for each producer network function, whether the current load for the producer network function exceeds a permissible load threshold (the amount of network traffic currently handled by at least one of the remaining second NF nodes is at a maximum load capability) and, if the current load exceeds the permissible load threshold, removing the producer network function from consideration in responding to at least one network function discovery request. Network function discovery node can then be configured for reconsidering a removed producer network function in response to determining that the current load for the removed producer network function has dropped below an abatement load threshold).
Claim 42. Sapra in view of Sharma and Krishan discloses [t]he method of claim 38,
Sapra further discloses wherein for at least one of the second NF nodes, the predefined amount of network traffic is a predefined percentage of the network traffic for executing the service (See Parag. [0012]; the network function discovery node is configured for determining, for each producer network function, whether the current load for the producer network function exceeds a permissible load threshold and, if the current load exceeds the permissible load threshold, removing the producer network function from consideration in responding to at least one network function discovery request; the network function discovery node is configured for reconsidering a removed producer network function in response to determining that the current load for the removed producer network function has dropped below an abatement load threshold. See Parag. [0108-0112]; dynamic load receiver (Note: of the network function discovery node) assigns an available capacity based on the current load of the producer network function as follows: C.sub.A=P.sub.C−(P.sub.L*P.sub.C); where, C.sub.A=available capacity of a network function instance; P.sub.C=published capacity of the network function instance; and P.sub.L=published load of the network function instance (in %). See also Parag. [0129]; (load: 40%)).
Claim 43. Sapra in view of Sharma and Krishan discloses [t]he method of claim 38,
Sapra doesn’t explicitly disclose wherein for at least one of the second NF nodes, the network traffic capacity is based on the following: a total of the network traffic capacities of all other of the one or more second NF nodes, and the predefined amount of network traffic.
However, Sharma discloses wherein for at least one of the second NF nodes, the network traffic capacity is based on the following: a total of the network traffic capacities of all other of the one or more second NF nodes, and the predefined amount of network traffic (See Page 16 lines 1-4; Workload distributor determines a share of traffic or workload to be handled by the different NF groups, which is referred to a group workload share. See Page 19 lines 1-16; within an NF group, workload distributor calculates initial NF workload values for NF service producers within the NF group based on the capacity values. To do so, workload distributor calculates a total capacity of the NF service producers within the NF group, and calculates a percentage of the total capacity for each of the NF service producers within the NF group by dividing a respective capacity value for an NF service producer by the total capacity. Workload distributor then calculates initial NF workload values for the NF service producers by multiplying a respective percentage of the total capacity with the group workload value for the NF group. The initial NF workload values represent the proportion of a group workload share (i.e., the NF workload share) that is attributed to each of NF service producers within the NF group based on the capacity values of the NF service producers).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the capacity for the producer network functions (the at least one of the second NF nodes), taught by Sapra, to be determined based on a total of the network traffic capacities of all other of the one or more second NF nodes, and the predefined amount of network traffic, as taught by Sharma. This would be convenient to apportion the group workload share for each of the NF groups (Sharma, Page 19 lines 16-17).
Claim 44. Sapra in view of Sharma and Krishan discloses [t]he method of claim 38,
Sapra discloses the method further comprising identifying that the network traffic for executing the service is to be distributed among the one or more second NF nodes based on the information obtained from the respective profiles and according to traffic distribution criteria, in response to the following: an event indicating that the service is to be executed, and a traffic distribution configuration of the first NF node (See Parag. [0124]; discovery request handler (Note: of the network function discovery node) may receive a producer network function discovery request from a consumer network function (an event indicating that the service is to be executed); determine a list of a producer network functions that are responsive to one or more criteria in the producer network function discovery request; and send a network function discovery response back to the consumer network function with a list of identifiers for the producer network functions. The list may be, for example, sorted by available capacity or priority, or the network function discovery response may include the available capacities and/or priority values for the producer network functions on the list. See Parag. [0126]; network function discovery node is configured for determining, for each producer network function, whether the current load for the producer network function exceeds a permissible load threshold and, if the current load exceeds the permissible load threshold, removing the producer network function from consideration in responding to at least one network function discovery request. Network function discovery node can then be configured for reconsidering a removed producer network function in response to determining that the current load for the removed producer network function has dropped below an abatement load threshold).
Claim 45. Sapra in view of Sharma and Krishan discloses [t]he method of claim 44,
Sapra further discloses wherein the event is one of the following: reception of a service request for the service to be executed, or an event internal to the network node that requires the service to be executed (See Parag. [0124]; discovery request handler (Note: of the network function discovery node) may receive a producer network function discovery request from a consumer network function (i.e., reception of a service request for the service to be executed)).
Claim 46. Sapra in view of Sharma and Krishan discloses [t]he method of claim 45,
Sapra further discloses wherein the traffic distribution configuration of the first NF node indicates that the first NF node is configured to distribute network traffic for executing the service according to one of the following: the respective network traffic capacities of the one or more second NF nodes irrespective of the amounts of traffic currently handled by the one or more second NF nodes; the respective network traffic capacities of the one or more second NF nodes when the amount of traffic currently handled is unavailable in the profile for at least one second NF node; or irrespective of the amount of traffic currently handled by the one or more second NF nodes (See Parag. [0105]; Network function registration engine (Note: of the network function discovery node) is configured for registering producer network functions. During registration, network function registration engine can receive a load reporting interval specifying a rate of load reporting for the producer network function. Network function registration engine can, during registration, receive a load reporting interval specifying a rate of load reporting for the producer network function. Registration can also include receiving, e.g., a published capacity, a permissible load threshold, an abatement load threshold, and any other appropriate information. See Parag. [0126]; network function discovery node is configured for determining, for each producer network function, whether the current load for the producer network function exceeds a permissible load threshold and, if the current load exceeds the permissible load threshold, removing the producer network function from consideration in responding to at least one network function discovery request (Note: request is received from the consumer network function) (the first NF node is not configured to support distributing network traffic among the second NF nodes according to the load on the one or more of the second NF nodes). See also Parag. [0120-0122]).
Claim 47. Sapra in view of Sharma and Krishan discloses [t]he method of claim 38,
Sapra further discloses wherein the 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 (See Parag. [0014]; the network function discovery node is a network function (NF) repository function (NRF) or a service communications proxy (SCP)).
Claim 48. Sapra discloses [a] network node configured to handle execution of a service in a network that includes a first network function (NF) node of a consumer for the service and one or more second NF nodes of a producer for the service (See Parag. [0009]; network function discovery node (network node); consumer network function (first network function (NF) node of a consumer); producer network function(s) (one or more second NF nodes of a producer for the service). See Parag. [0014]; the network function discovery node is a network function (NF) repository function (NRF) or a service communications proxy (SCP)), the network node comprising processing circuitry configured to:
obtain one or more of the following information from respective profiles for the one or more second NF nodes (See Parag. [0080-0081]; NRF supports the following functions: Maintains the profiles of the available NF instances and their supported services in the 5G core network):
a first indication that the second NF node is under testing and a predefined amount of network traffic required by the second NF node for the testing; a network traffic capacity for the second NF node; and an amount of network traffic currently handled by the second NF node (See Parag. [0140-0142]; method 400 can be performed by an NRF or SCP, or any other appropriate network function discovery node … registering producer network functions (402). During registration, method 400 can include receiving a load reporting interval specifying a rate of load reporting for the producer network function. Method 400 can include, during registration, receiving a load reporting interval specifying a rate of load reporting for the producer network function. Registration can also include receiving, e.g., a published capacity, a permissible load threshold, an abatement load threshold, and any other appropriate information (i.e., a network traffic capacity for the second NF node). See also Parag. [0124]); and
distribute network traffic for executing the service among the one or more second NF nodes based on the information obtained from the respective profiles and according to traffic distribution criteria including the following:
for each second NF node whose profile includes the first indication, the predefined amount of traffic required by the second NF node for the testing, which results in a remaining network traffic to be distributed (See Parag. [0106-0112]; determining, for each producer network function, an available capacity for the producer network function based on the current load value and a published capacity of the producer network function … dynamic load receiver assigns an available capacity based on the current load of the producer network function as follows: C.sub.A=P.sub.C−(P.sub.L*P.sub.C); where, C.sub.A=available capacity of a network function instance; P.sub.C=published capacity of the network function instance; and P.sub.L=published load of the network function instance (in %). See also Parag. [0020] [0129]; (load: 40%). Examiner’s note: Sapra discloses assigning capacity for each producer network function based on the current load of the producer network function. It is known in the art that "Network function capacity" refers to the maximum amount of data a specific network function can process and transfer within a given timeframe, reflecting the ability to handle traffic on a network. In addition, the applicant teaches in the specification identifying that network traffic for executing the service is to be distributed among the second NF nodes according to a capacity of one or more of the second NF nodes (Specification, Page 4 lines 29-32)).
Sapra doesn’t explicitly disclose the first indication as a first indication that the second NF node is under testing; [and] for remaining second NF nodes whose profiles does not include the first indication: when all profiles for the remaining second NF nodes indicate the amount of network traffic currently handled, the remaining network traffic among the remaining second NF nodes according to respective differences between the network traffic capacities and the amounts of network traffic currently handled for the remaining second NF nodes.
However, Sharma discloses for remaining second NF nodes whose profiles does not include the first indication: when all profiles for the remaining second NF nodes indicate the amount of network traffic currently handled, the remaining network traffic among the remaining second NF nodes according to respective differences between the network traffic capacities and the amounts of network traffic currently handled for the remaining second NF nodes (See Page 16 lines 1-4; Workload distributor determines a share of traffic or workload to be handled by the different NF groups, which is referred to a group workload share. See Page 19 lines 1-16; within an NF group, workload distributor calculates initial NF workload values for NF service producers within the NF group based on the capacity values. To do so, workload distributor calculates a total capacity of the NF service producers within the NF group, and calculates a percentage of the total capacity for each of the NF service producers within the NF group by dividing a respective capacity value for an NF service producer by the total capacity. Workload distributor then calculates initial NF workload values for the NF service producers by multiplying a respective percentage of the total capacity with the group workload value for the NF group. The initial NF workload values represent the proportion of a group workload share (i.e., the NF workload share) that is attributed to each of NF service producers within the NF group based on the capacity values of the NF service producers. See Page 14 lines 15-25; There may be situations where information for one or more of attributes are not specified by an NF service producer when registering with NRF… When attributes are not specified, NRF or an NF service consumer may handle the absence of these attributes as follows… When the load attribute is not specified, the load value may be set to a normal operating region. See Page 24 lines 12-16; With the workload 1300 apportioned into group workload shares 1302, NF service consumer 802 parses the NF profiles 820 to identify capacity values assigned to the NF service producers 404 of the NF group 1402, and apportions the group workload shares 1302 into NF workload shares 1304 for the NF service producers 404 within the NF groups 1402 based on the capacity values. Examiners’ interpretation: When the load attribute is not specified, the service is to be distributed among said one or more of the second NF nodes according to the other attributes (e.g., capacity) of the one or more of the second NF nodes for which load information is specified).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the network function discovery node, taught by Sapra, such that when all profiles for the remaining second NF nodes indicate the amount of network traffic currently handled, the remaining network traffic among the remaining second NF nodes according to respective differences between the network traffic capacities and the amounts of network traffic currently handled for the remaining second NF nodes, as taught by Sharma. This would be convenient to apportion the group workload share for each of the NF groups (Sharma, Page 19 lines 16-17).
Sapra in view of Sharma doesn’t explicitly disclose the first indication as a first indication that the second NF node is under testing.
However, Krishan discloses a first indication that the second NF node is under testing (See Col. 3 lines 50-67; system includes an application programming interface (API) decoder for obtaining first and second application programming interface (API) version indicators associated with first and second service instances implemented by one or more producer NFs, decoding the first and second API version indicators, and detecting, based on results of the decoding, multiple instances of the same service and that a first service instance is backward compatible with a second service instance. The system further includes a canary tester for, responsive to the API decoder detecting that the first and second service instances implement multiple versions of the same service (from a single producer NF) and that the first service instance is backward compatible with the second service instance, implementing canary testing of the first service instance).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the network function discovery node, taught by Sapra in view of Sharma, to obtain a first indication that the second NF node is under testing, as taught by Krishan. This would be convenient for handling multiple versions of the same service provided by producer NFs (Krishan, Col. 2 lines 20-22).
Claim 49 is taught by Sapra in view of Sharma and Krishan as described for claim 39.
Claim 50 is taught by Sapra in view of Sharma and Krishan as described for claim 40.
Claim 51 is taught by Sapra in view of Sharma and Krishan as described for claim 41.
Claim 52 is taught by Sapra in view of Sharma and Krishan as described for claim 42.
Claim 53 is taught by Sapra in view of Sharma and Krishan as described for claim 43.
Claim 54 is taught by Sapra in view of Sharma and Krishan as described for claim 44.
Claim 55 is taught by Sapra in view of Sharma and Krishan as described for claim 45.
Claim 56 is taught by Sapra in view of Sharma and Krishan as described for claim 46.
Claim 57 is taught by Sapra in view of Sharma and Krishan as described for claim 47.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Rajput et al. (Patent No. US 10,833,938) – Related art in the area of NF topology synchronization in 5G and subsequent generation networks in which consumer NFs, such as service communications proxies (SCPs) subscribed for producer NF topology information from an NF repository function (NRF), (Abstract; A method for network function (NF) topology synchronization includes, at a network node including at least one processor, maintaining NF instance identifiers and corresponding NF profile version identifiers in an NF topology database local to the network node, the NF profile version identifiers indicating most current NF profile versions stored by the network node for each NF instance identifier. The method further includes obtaining a list of NF instance identifiers and NF profile version identifiers from an NF repository function (NRF), accessing the NF topology database, determining, by comparing the NF profile version identifiers in the list with NF profile version identifiers for corresponding NF instance identifiers in the NF topology database, whether the NF profiles stored by the network node are lagging behind the NF profiles stored by the NRF, and auditing or refraining from auditing the NRF for updated NF profiles based on results of the comparison).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ABDELBASST TALIOUA whose telephone number is (571)272-4061. The examiner can normally be reached on Monday-Thursday 7:30 am - 5:30 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, William Trost can be reached on 571-272-7872. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Abdelbasst Talioua/Examiner, Art Unit 2442