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
2. This is a Final Office action in response to applicant’s remarks and arguments filed on 12/23/2025.
3. Status of the claims:
• Claims 1-3, 5-12, 14-20 have been amended.
• Claims 4 and 13 have been canceled.
• Claims 21-22 have been added.
• Claims 1-3, 5-12, 14-22 are currently pending and have been examined.
Response to remarks/arguments
4. Applicant’s remarks and arguments filed on12/23/2025 with respect to the rejection of claims 1-3, 5-12, 14-20 have been fully considered but are moot in view of the new ground(s) of rejection. Upon further search and consideration, a new ground(s) of obviousness rejection is made in view of Velev et al. (US 20190261185 A1).
5. In response to Applicant’s remarks and arguments filed on 12/23/2025 regarding claims 1-3, 5-12, 14-22, the Examiner acknowledges that Kalliola does not explicitly teach the newly recited features as argued by Applicant. However, the system of Velev et al. (US 20190261185 A1) cures this deficiency.
Please see the rejection below.
Claim Rejections - 35 USC § 103
6. 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 (i.e., changing from AIA to pre-AIA ) 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.
7. 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.
8. The factual inquiries 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.
9. This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
10. Claims 1-3, 5-12, 14-22 are rejected under 35 U.S.C. 103 as being unpatentable over Kalliola et al. (US 10,602,396 B2) in view of Velev et al. (US 20190261185 A1).
Regarding claim 1, Kalliola discloses a method, comprising:
monitoring first traffic [[associated with a first network slice in a mobile network]] (Kalliola, col. 6, lines 7-10: monitoring, by a first traffic analysis module by using machine learning and the received configuration parameters, traffic in a radio access network of a wireless communication system);
applying machine learning to the monitored first traffic to determine at least one metric for detecting traffic anomalies in the [[first network slice]] (Kalliola, col. 3, lines 10-15: enabling the plurality of local traffic analysis modules to use machine learning to detect anomalies from monitored traffic in the radio access network. col. 13, lines 24-35: information transferred between the central traffic analysis modules 400 to 404 in step 808 may include one or more metrics indicating prediction quality, current load, status of the anomaly, training data, traffic data or other data related to the anomaly for analysis).
Although Kalliola discloses triggering countermeasures based on the determined at least one first metric (Kalliola, col. 13, lines 24-35: information transferred between the central traffic analysis modules 400 to 404 in step 808 may include one or more metrics indicating prediction quality, current load, status of the anomaly, training data, traffic data or other data related to the anomaly for analysis. FIG. 5, step 510. Execute the countermeasures by controlling traffic associated with the UE), but Kalliola does not appear to explicitly disclose traffic associated with a first network slice in a mobile network; triggering, based on the determined at least one first metric at least one of: applying, by a first Policy Control Function (PCF) in the first network slice, one or more first network slice-specific policy rules to second traffic in the first network slice, or updating, by the first PCF in the first network slice, the one or more first network slice-specific the policy rules.
In the same field of endeavor, Velev teaches monitoring traffic associated with a first network slice in a mobile network (Velev, para. [0182] [0200]: first configured network slice selection assistance information for a first public land mobile network); triggering, based on the determined at least one first metric, at least one of: applying, by a first Policy Control Function (PCF) in the first network slice, one or more first network slice specific policy rules to second traffic in the network slice, or updating, by the first PCF in the first network slice, the one or more first network slice-specific the policy rules (Velev, para. [0198]: the remote unit route selection policy update is received via a policy control function (PCF) triggered update procedure. In certain embodiments, the network slice selection policy comprises an indication indicating that the network slice selection policy is to be used to update the configured network slice selection assistance information).
Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Kalliola with the teaching of Velev by using the above such that updating, by the first PCF in the first network slice, the one or more first network slice-specific the policy rules as taught by Velev. The motivation for doing so would have been to use the configured network slice selection assistance information in the first mobile network (Velev, para. [0005]).
Regarding claim 2, Kalliola and Velev disclose the method of claim 1, further comprising: monitoring third traffic associated with the first network slice (Kalliola, col. 9, lines 44-64: monitoring traffic across multiple protocol layers in the radio access network); applying the machine learning to the monitored third traffic to learn traffic patterns of the first network slice (Kalliola, col. 11, lines 41-55: the central traffic analysis module may employ the machine learning and/or pattern detection algorithm and attempt discovery of anomalies in the traffic data. Upon detecting an anomaly in block 506, the central traffic analysis module 402 may share information about the detection with another traffic analysis modules) 404 in step 600); and determining traffic signatures for the network slice based on the learned traffic patterns, wherein the at least one first metric comprises at least one distance metric, and wherein applying the machine learning further determines the at least one distance metric relative to the determined traffic signatures (Kalliola, col. 11, lines 7-17: the local traffic analysis module 410 and/or the central traffic analysis module 412 may communicate details of the mitigation and/or anomaly patterns to the other local traffic analysis as a part of the “inoculation” process. This enables sharing of knowledge of the anomalies and their signatures and improves the machine learning capabilities in the other modules. Upon receiving the information on the anomaly, e.g. its signatures or conditions under which the anomaly was detected, the local traffic analysis module 412 may adapt its machine learning algorithm to better detect the anomaly).
Regarding claim 3, Kalliola and Velev disclose the method of claim 2, wherein the third traffic comprises training data sent over the first network slice (Kalliola, col. 10, lines 17-19: The central traffic analysis module 402 may have carried out a different type of learning phase because of different type of available training data).
Regarding claim 5, Kalliola and Velev disclose the method of claim 1, further comprising: generating at least one anomaly score based on the determined at least one first metric, wherein the triggering is further based on the at least one anomaly score (Kalliola, col. 13, lines 24-35: Actual information transferred between the central traffic analysis modules 400 to 404 in step 808 may include a state of the machine learning algorithm, one or more metrics indicating prediction quality, current load, status of the anomaly (e.g. malicious attack, malfunctioning UE, etc.) training data, traffic data or other data related to the anomaly for analysis).
Regarding claim 6, Kalliola and Velev disclose the method of claim 5, further comprising: determining, based on the monitored first traffic and the at least one anomaly score, a need for changes to the first network slice to maintain adequate traffic performance characteristics for the first network slice (Kalliola, col. 16, lines 11-25: processing circuitry 50 may comprise a traffic analysis circuitry 58 configured to perform the traffic analysis and mitigation according to any one of the above-described embodiments described in connection with the central traffic analysis module. The traffic analysis circuitry 58 may comprise an anomaly detection circuitry 54 configured to perform the analysis of the traffic data received from one or more local traffic analysis modules. The anomaly detection circuitry 54 may employ a different algorithm and/or different configuration parameters than the anomaly detection circuitry 14. Upon detecting the anomaly, the anomaly detection circuitry 54 may output a notification of the anomaly and, in some embodiments, an identified source of the anomaly to a mitigation circuitry 55 configured to mitigate the anomaly); and triggering changes to the network slice based on the determined need for changes (Kalliola, col 11, lines 18-25: the central traffic analysis module 402 may also cause updates and/or changes to a register of the identified UE causing the anomaly).
Regarding claim 7, Kalliola and Velev disclose the method of claim 1, further comprising: receiving configuration data associated with performing traffic management functions for the first network slice, wherein monitoring the first traffic is based on the received configuration data (Kalliola, col 9, lines 8-18: Upon receiving the configuration parameters in step 500, the local traffic analysis module may start monitoring traffic in an access node or an interface of the access node (block 502). The traffic analysis may include a learning phase where the machine learning algorithm builds a local traffic model representing traffic in the access node and/or interface under normal conditions. When sufficient amount of learning has been carried out, the algorithm is capable of detecting anomalies in the traffic. According to an aspect, the operation of the machine learning algorithm is constant learning even after the capability of detecting the anomalies).
Regarding claim 8, Kalliola and Velev disclose the method of claim 7, wherein the configuration data comprises at least one of: data that identifies traffic attributes to collect for the network slice; data that identifies monitoring thresholds for the first network slice; or data that identifies thresholds associated with the determined at least one first metric (Kalliola, col 8, lines 59-64: the configuration parameters may include at least some of the following parameters: characteristics of known anomalies, one or more threshold values for use in detection of the anomalies, a blacklist or a whitelist of contents in packet headers of monitored traffic, complexity (computational), resource consumption, timing parameters).
Regarding claim 9, Kalliola and Velev disclose the method of claim 2, wherein determining the traffic signatures for the first network slice comprises: storing certain of the learned traffic patterns as the traffic signatures in a traffic signature repository (Kalliola, col. 14, lines 51-57 and col 11, lines 8-17: The memory may comprise a configuration database 24 for storing configuration data for the traffic analysis; the central traffic analysis module 412 may communicate details of the mitigation and/or anomaly patterns to the other local traffic analysis as a part of the “inoculation” process. This enables sharing of knowledge of the anomalies and their signatures and improves the machine learning capabilities in the other modules. Upon receiving the information on the anomaly, e.g. its signatures or conditions under which the anomaly was detected, the local traffic analysis module 412 may adapt its machine learning algorithm to better detect the anomaly).
Regarding claim 10, Kalliola and Velev disclose the method of claim 1, wherein monitoring the first traffic comprises: monitoring traffic attributes of control plane (CP) and User Plane (UP) traffic associated with the first network slice (Kalliola, Fig. 7, col 12, 1-3: Referring to FIG. 7, the local traffic analysis module may monitor that control/user plane traffic in the radio access network. Col 17, lines 62-65 further discloses monitoring any control and/or user plane traffic that is available at the radio access network and/or the core network).
Regarding claim 11, Kalliola discloses a network device (Fig. 9: the apparatus may be an electronic device comprising electronic circuitries), comprising: at least one communication interface configured to communicate via a network (Fig. 9: communication interface 26); and at least one processor (Fig. 9: Processing circuitry 10) configured to: monitor first traffic [[associated with a network slice in a mobile network]] (Kalliola, col. 6, lines 7-10: monitoring, by a first traffic analysis module by using machine learning and the received configuration parameters, traffic in a radio access network of a wireless communication system), apply machine learning to the monitored first traffic to determine at least one metric for detecting traffic anomalies in the network slice (Kalliola, col. 3, lines 10-15: enabling the plurality of local traffic analysis modules to use machine learning to detect anomalies from monitored traffic in the radio access network. col. 13, lines 24-35: information transferred between the central traffic analysis modules 400 to 404 in step 808 may include one or more metrics indicating prediction quality, current load, status of the anomaly, training data, traffic data or other data related to the anomaly for analysis).
Although Kalliola discloses triggering countermeasures, based on the determined at least one first metric (Kalliola, col. 13, lines 24-35: information transferred between the central traffic analysis modules 400 to 404 in step 808 may include one or more metrics indicating prediction quality, current load, status of the anomaly, training data, traffic data or other data related to the anomaly for analysis. FIG. 5, step 510. Execute the countermeasures by controlling traffic associated with the UE), but Kalliola does not appear to explicitly disclose first traffic associated with a first network slice in a mobile network; trigger, based on the determined at least one first metric at least one of: apply, by a first Policy Control Function (PCF) in the first network slice, one or more first network slice-specific policy rules to second traffic in the first network slice, or update, by the first PCF in the first network slice, the one or more first network slice-specific the policy rules.
In the same field of endeavor, Velev teaches first traffic associated with a first network slice in a mobile network (Velev, para. [0182] [0200]: first configured network slice selection assistance information for a first public land mobile network); trigger, based on the determined at least one first metric, at least one of: apply, by a first Policy Control Function (PCF) in the first network slice, one or more first network slice-specific policy rules to second traffic in the first network slice, or update, by the first PCF in the first network slice, the one or more first network slice-specific the policy rules (Velev, para. [0198]: the remote unit route selection policy update is received via a policy control function (PCF) triggered update procedure. In certain embodiments, the network slice selection policy comprises an indication indicating that the network slice selection policy is to be used to update the configured network slice selection assistance information).
Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Kalliola with the teaching of Velev by using the above such that updating, by the first PCF in the first network slice, the one or more first network slice-specific the policy rules as taught by Velev. The motivation for doing so would have been to use the configured network slice selection assistance information in the first mobile network (Velev, para. [0005]).
Regarding claim 12, Kalliola and Velev disclose the network device of claim 11, wherein the at least one processor is further configured to: monitor third traffic associated with the first network slice (Kalliola, col. 9, lines 44-64: monitoring traffic across multiple protocol layers in the radio access network); apply the machine learning to the monitored third traffic to learn traffic patterns of the network slice (Kalliola, col. 11, lines 41-55: the central traffic analysis module may employ the machine learning and/or pattern detection algorithm and attempt discovery of anomalies in the traffic data. Upon detecting an anomaly in block 506, the central traffic analysis module 402 may share information about the detection with another traffic analysis modules) 404 in step 600); and determine traffic signatures for the network slice based on the learned traffic patterns, wherein the at least one first metric comprises at least one distance metric, and wherein applying the machine learning further determines the at least one distance metric relative to the determined traffic signatures (Kalliola, col. 11, lines 7-17: the local traffic analysis module 410 and/or the central traffic analysis module 412 may communicate details of the mitigation and/or anomaly patterns to the other local traffic analysis as a part of the “inoculation” process. This enables sharing of knowledge of the anomalies and their signatures and improves the machine learning capabilities in the other modules. Upon receiving the information on the anomaly, e.g. its signatures or conditions under which the anomaly was detected, the local traffic analysis module 412 may adapt its machine learning algorithm to better detect the anomaly).
Regarding claim 14, Kalliola and Velev disclose the network device of claim 11, wherein the at least one processor is further configured to: generate at least one anomaly score based on the determined at least one first metric, wherein the triggering is further based on the at least one anomaly score (Kalliola, col. 13, lines 24-35: Actual information transferred between the central traffic analysis modules 400 to 404 in step 808 may include a state of the machine learning algorithm, one or more metrics indicating prediction quality, current load, status of the anomaly (e.g. malicious attack, malfunctioning UE, etc.) training data, traffic data or other data related to the anomaly for analysis).
Regarding claim 15, Kalliola and Velev disclose the network device of claim 14, wherein the at least one processor is further configured to: determine, based on the monitored first traffic and the at least one anomaly score, a need for changes to the first network slice to maintain adequate traffic performance characteristics for the first network slice (Kalliola, col. 16, lines 11-25: processing circuitry 50 may comprise a traffic analysis circuitry 58 configured to perform the traffic analysis and mitigation according to any one of the above-described embodiments described in connection with the central traffic analysis module. The traffic analysis circuitry 58 may comprise an anomaly detection circuitry 54 configured to perform the analysis of the traffic data received from one or more local traffic analysis modules. The anomaly detection circuitry 54 may employ a different algorithm and/or different configuration parameters than the anomaly detection circuitry 14. Upon detecting the anomaly, the anomaly detection circuitry 54 may output a notification of the anomaly and, in some embodiments, an identified source of the anomaly to a mitigation circuitry 55 configured to mitigate the anomaly); and trigger changes to the first network slice based on the determined need for changes (Kalliola, col 11, lines 18-25: the central traffic analysis module 402 may also cause updates and/or changes to a register of the identified UE causing the anomaly).
Regarding claim 16, Kalliola and Velev disclose the network device of claim 11, wherein the at least one processor is further configured to: receive configuration data associated with performing traffic management functions for the first network slice, wherein monitoring the first traffic is based on the received configuration data (Kalliola, col 9, lines 8-18: Upon receiving the configuration parameters in step 500, the local traffic analysis module may start monitoring traffic in an access node or an interface of the access node (block 502). The traffic analysis may include a learning phase where the machine learning algorithm builds a local traffic model representing traffic in the access node and/or interface under normal conditions. When sufficient amount of learning has been carried out, the algorithm is capable of detecting anomalies in the traffic. According to an aspect, the operation of the machine learning algorithm is constant learning even after the capability of detecting the anomalies), and wherein the configuration data comprises at least one of: data that identifies traffic attributes to collect for the first network slice, data that identifies monitoring thresholds for the first network slice, or data that identifies thresholds associated with the determined at least one first metric (Kalliola, col 8, lines 59-64: the configuration parameters may include at least some of the following parameters: characteristics of known anomalies, one or more threshold values for use in detection of the anomalies, a blacklist or a whitelist of contents in packet headers of monitored traffic, complexity (computational), resource consumption, timing parameters).
Regarding claim 17, Kalliola discloses a non-transitory storage medium storing instructions executable by a network device (Fig. 10: network device of Fig. 10), wherein the instructions comprise instructions to cause the network device to:
monitor first traffic [[associated with a first network slice in a mobile network]] (Kalliola, col. 6, lines 7-10: monitoring, by a first traffic analysis module by using machine learning and the received configuration parameters, traffic in a radio access network of a wireless communication system);
apply machine learning to the monitored first traffic to determine at least one metric for detecting traffic anomalies in the first network slice (Kalliola, col. 3, lines 10-15: enabling the plurality of local traffic analysis modules to use machine learning to detect anomalies from monitored traffic in the radio access network. col. 13, lines 24-35: information transferred between the central traffic analysis modules 400 to 404 in step 808 may include one or more metrics indicating prediction quality, current load, status of the anomaly, training data, traffic data or other data related to the anomaly for analysis).
Although Kalliola discloses triggering countermeasures, based on the determined at least one first metric (Kalliola, col. 13, lines 24-35: information transferred between the central traffic analysis modules 400 to 404 in step 808 may include one or more metrics indicating prediction quality, current load, status of the anomaly, training data, traffic data or other data related to the anomaly for analysis. FIG. 5, step 510. Execute the countermeasures by controlling traffic associated with the UE), but Kalliola does not appear to explicitly disclose first traffic associated with a first network slice in a mobile network; trigger, based on the determined at least one first metric at least one of: apply, by a first Policy Control Function (PCF) in the first network slice, one or more first network slice-specific policy rules to second traffic in the first network slice, or update, by the first PCF in the first network slice, the one or more first network slice-specific the policy rules.
In the same field of endeavor, Velev teaches first traffic associated with a first network slice in a mobile network (Velev, para. [0182] [0200]: first configured network slice selection assistance information for a first public land mobile network); trigger, based on the determined at least one first metric, at least one of: apply, by a first Policy Control Function (PCF) in the first network slice, one or more first network slice-specific policy rules to second traffic in the first network slice, or update, by the first PCF in the first network slice, the one or more first network slice-specific the policy rules (Velev, para. [0198]: the remote unit route selection policy update is received via a policy control function (PCF) triggered update procedure. In certain embodiments, the network slice selection policy comprises an indication indicating that the network slice selection policy is to be used to update the configured network slice selection assistance information).
Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Kalliola with the teaching of Velev by using the above such that updating, by the first PCF in the first network slice, the one or more first network slice-specific the policy rules as taught by Velev. The motivation for doing so would have been to use the configured network slice selection assistance information in the first mobile network (Velev, para. [0005]).
Regarding claim 18, Kalliola and Velev disclose the non-transitory storage medium of claim 17, wherein the instructions further comprise instructions to cause the network device to:
monitor third traffic associated with the first network slice (Kalliola, col. 9, lines 44-64: monitoring traffic across multiple protocol layers in the radio access network); apply the machine learning to the monitored third traffic to learn traffic patterns of the network slice (Kalliola, col. 11, lines 41-55: the central traffic analysis module may employ the machine learning and/or pattern detection algorithm and attempt discovery of anomalies in the traffic data. Upon detecting an anomaly in block 506, the central traffic analysis module 402 may share information about the detection with another traffic analysis modules) 404 in step 600); and determine traffic signatures for the first network slice based on the learned traffic patterns, wherein the at least one first metric comprises at least one distance metric, and wherein applying the machine learning further determines the at least one distance metric relative to the determined traffic signatures (Kalliola, col. 11, lines 7-17: the local traffic analysis module 410 and/or the central traffic analysis module 412 may communicate details of the mitigation and/or anomaly patterns to the other local traffic analysis as a part of the “inoculation” process. This enables sharing of knowledge of the anomalies and their signatures and improves the machine learning capabilities in the other modules. Upon receiving the information on the anomaly, e.g. its signatures or conditions under which the anomaly was detected, the local traffic analysis module 412 may adapt its machine learning algorithm to better detect the anomaly).
Regarding claim 19, Kalliola and Velev disclose the non-transitory storage medium of claim 17, wherein the instructions further comprise instructions to cause the network device to: generate at least one anomaly score based on the determined at least one first metric, wherein the triggering is further based on the at least one anomaly score (Kalliola, col. 13, lines 24-35: Actual information transferred between the central traffic analysis modules 400 to 404 in step 808 may include a state of the machine learning algorithm, one or more metrics indicating prediction quality, current load, status of the anomaly (e.g. malicious attack, malfunctioning UE, etc.) training data, traffic data or other data related to the anomaly for analysis).
Regarding claim 20, Kalliola and Velev disclose the non-transitory storage medium of claim 19, wherein the instructions further comprise instructions to cause the network device to: determine, based on the monitored first traffic and the at least one anomaly score, a need for changes to the first network slice to maintain adequate traffic performance characteristics for the first network slice (Kalliola, col. 16, lines 11-25: processing circuitry 50 may comprise a traffic analysis circuitry 58 configured to perform the traffic analysis and mitigation according to any one of the above-described embodiments described in connection with the central traffic analysis module. The traffic analysis circuitry 58 may comprise an anomaly detection circuitry 54 configured to perform the analysis of the traffic data received from one or more local traffic analysis modules. The anomaly detection circuitry 54 may employ a different algorithm and/or different configuration parameters than the anomaly detection circuitry 14. Upon detecting the anomaly, the anomaly detection circuitry 54 may output a notification of the anomaly and, in some embodiments, an identified source of the anomaly to a mitigation circuitry 55 configured to mitigate the anomaly); and trigger changes to the network slice based on the determined need for changes (Kalliola, col 11, lines 18-25: the central traffic analysis module 402 may also cause updates and/or changes to a register of the identified UE causing the anomaly).
Regarding claim 21, Kalliola and Velev disclose method of claim 1, comprising:
monitoring third traffic [[associated with a second network slice in a mobile network]] (Kalliola, Fig. 7, col. 6, lines 7-10: monitoring, by a first traffic analysis module by using machine learning and the received configuration parameters, traffic in a radio access network of a wireless communication system);
applying machine learning to the monitored third traffic to determine at least one second metric for detecting traffic anomalies in the second network slice (Kalliola, Fig. 7, col. 3, lines 10-15: enabling the plurality of local traffic analysis modules to use machine learning to detect anomalies from monitored traffic in the radio access network. col. 13, lines 24-35: information transferred between the central traffic analysis modules 400 to 404 in step 808 may include one or more metrics indicating prediction quality, current load, status of the anomaly, training data, traffic data or other data related to the anomaly for analysis).
Although Kalliola discloses triggering countermeasures, based on the determined at least one second metric (Kalliola, col. 13, lines 24-35: information transferred between the central traffic analysis modules 400 to 404 in step 808 may include one or more metrics indicating prediction quality, current load, status of the anomaly, training data, traffic data or other data related to the anomaly for analysis), but Kalliola does not appear to explicitly disclose third traffic associated with a second network slice in a mobile network; triggering, based on the determined at least one second metric at least one of: applying, by a second Policy Control Function (PCF) in the second network slice, one or more second network slice-specific policy rules to second traffic in the first network slice, or updating, by the second PCF in the second network slice, the one or more second network slice-specific the policy rules.
In the same field of endeavor, Velev teaches third traffic associated with a second network slice in a mobile network (Velev, para. [0182] [0200]: first configured network slice selection assistance information for a first public land mobile network); triggering, based on the determined at least one second metric, at least one of: applying, by a second Policy Control Function (PCF) in the second network slice, one or more second network slice-specific policy rules to second traffic in the first network slice, or updating, by the second PCF in the second network slice, the one or more second network slice-specific the policy rules (Velev, para. [0198]: the remote unit route selection policy update is received via a policy control function (PCF) triggered update procedure. In certain embodiments, the network slice selection policy comprises an indication indicating that the network slice selection policy is to be used to update the configured network slice selection assistance information).
Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Kalliola with the teaching of Velev by using the above such that updating, by the first PCF in the first network slice, the one or more first network slice-specific the policy rules as taught by Velev. The motivation for doing so would have been to use the configured network slice selection assistance information in the first mobile network (Velev, para. [0005]).
Regarding claim 22, Kalliola and Velev disclose network device of claim 11, wherein the at least one processor is further configured to:
monitor third traffic [[associated with a second network slice in a mobile network]] (Kalliola, Fig. 7, col. 6, lines 7-10: monitoring, by a first traffic analysis module by using machine learning and the received configuration parameters, traffic in a radio access network of a wireless communication system);
applying machine learning to the monitored third traffic to determine at least one second metric for detecting traffic anomalies in the second network slice (Kalliola, Fig. 7, col. 3, lines 10-15: enabling the plurality of local traffic analysis modules to use machine learning to detect anomalies from monitored traffic in the radio access network. col. 13, lines 24-35: information transferred between the central traffic analysis modules 400 to 404 in step 808 may include one or more metrics indicating prediction quality, current load, status of the anomaly, training data, traffic data or other data related to the anomaly for analysis).
Although Kalliola discloses triggering countermeasures, based on the determined at least one second metric (Kalliola, col. 13, lines 24-35: information transferred between the central traffic analysis modules 400 to 404 in step 808 may include one or more metrics indicating prediction quality, current load, status of the anomaly, training data, traffic data or other data related to the anomaly for analysis), but Kalliola does not appear to explicitly disclose third traffic associated with a second network slice in a mobile network; triggering, based on the determined at least one second metric at least one of: applying, by a second Policy Control Function (PCF) in the second network slice, one or more second network slice-specific policy rules to second traffic in the first network slice, or updating, by the second PCF in the second network slice, the one or more second network slice-specific the policy rules.
In the same field of endeavor, Velev teaches third traffic associated with a second network slice in a mobile network (Velev, para. [0182] [0200]: first configured network slice selection assistance information for a first public land mobile network); triggering, based on the determined at least one second metric, at least one of: applying, by a second Policy Control Function (PCF) in the second network slice, one or more second network slice-specific policy rules to second traffic in the first network slice, or updating, by the secondPCF in the second network slice, the one or more second network slice-specific the policy rules (Velev, para. [0198]: the remote unit route selection policy update is received via a policy control function (PCF) triggered update procedure. In certain embodiments, the network slice selection policy comprises an indication indicating that the network slice selection policy is to be used to update the configured network slice selection assistance information).
Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Kalliola with the teaching of Velev by using the above such that updating, by the first PCF in the first network slice, the one or more first network slice-specific the policy rules as taught by Velev. The motivation for doing so would have been to use the configured network slice selection assistance information in the first mobile network (Velev, para. [0005]).
Conclusion
11. Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
12. Any inquiry concerning this communication or earlier communications from the examiner should be directed to JEAN F VOLTAIRE whose telephone number is (571)272-3953. The examiner can normally be reached M-F 9:30-6: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, REBECCA E. SONG can be reached at (571)270-3667. 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.
/JEAN F VOLTAIRE/Examiner, Art Unit 2417
/REBECCA E SONG/Supervisory Patent Examiner, Art Unit 2417
Prosecution Insights