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 .
This Office Action is responsive to a response filed on January 21st, 2026. In this office action:
Claims 1 and 3-4 are pending.
Claims 1 and 4 are rejected.
Claim 3 is objected to.
Summary of Previous Office Action
In the Non-final Office Action mailed on October 22nd, 2025:
Claims 1-4 were objected to because of informalities.
Claims 1-4 were rejected under 35 U.S.C. 102 (a)(1) as being anticipated by Embarmannar Vijayan et al. (Pub. No. US 2020/0235986).
Response to Amendment
The amendments filed on January 21st, 2026 have been entered.
Claims 1 and 3-4 have been amended.
Claim 2 has been canceled.
The previously raised claim objections are withdrawn for claims 1-3 and partially withdrawn for claim 4 in light of the amendments.
Response to Arguments
Applicant’s arguments filed on January 21st, 2026 have been fully considered by the Examiner, and they are moot in view of the new grounds of rejection, as presented in this office action.
Claim Objections
Claim 4 is objected to because it recites acronyms that are not defined within the claims. The acronyms are: VNF and CNF.
Claim 4 is objected to because of the following informality:
“… in a case in which the degradation in performance is not occuring in the one or more VNFs or CNFs belonging to the group …” should read (Examiner’s suggestion) “… in a case in which the degradation in performance is not [[occuring]] occurring in the one or more VNFs or CNFs belonging to the group …”
Appropriate correction(s) is/are required.
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 1 and 4 are rejected under 35 U.S.C. 103 as being unpatentable over Embarmannar Vijayan et al. (Pub. No. US 2020/0235986), hereinafter Embarmannar; in view of Savoor et al. (Pub. No. US 2020/0213205), hereinafter Savoor.
Claim 1. Embarmannar discloses [a] network management apparatus comprising:
memory configured to store at least one instruction; wherein the at least one instruction, when executed by at least one processor (See Parag. [0086]; a processor and a non-transitory, computer-readable storage medium), causes the at least one processor to:
execute a reception process of receiving a signal (alert) supplied when degradation in performance of a virtual network function (VNF) or a cloud-native network function (CNF) exceeding a threshold value is detected in a network virtualization environment (See Parag. [0025]; evaluator engine receives the KPI information from a virtual analytics engine … The virtual analytics engine can provide alerts when KPI thresholds are breached … See Parag. [0027]; The KPI information can include performance information of a virtual component, such as a VM. The VM can be a virtual networking component, such as a virtual switch or router. Such virtual networking components are also referred to as VNFs. The KPI information can indicate one or more of packet drops, input packet rate, output packet rate, read latency, write latency, throughput, number of operations, and others; the KPI information is sent to the evaluator engine when the virtual analytics engine determines that particular measured metrics exceed a performance threshold … For example, if a number of packet drops exceeds a threshold during a time period, then the virtual analytics engine can send corresponding KPI information to the evaluator engine. See also Parag. [0007] [0033] [0035] [0037] [0081-0086], Fig. 1B, and Fig. 3 “video service degradation is detected”. Examiner’s interpretation: The claim is interpreted as “a reception process of receiving a signal supplied when degradation in performance of a virtual network function (VNF) exceeding a threshold value is detected in a network virtualization environment”),
based on the receiving of the signal, execute a first determination process of determining whether degradation in performance is occurring in one or more other VNFs or CNFs belonging to a group comprising a plurality of load-balanced VNFs or CNFs, wherein the group includes the VNF or CNF having the degraded performance (See Parag. [0009]; a root cause originating with hardware in the physical layer can be used to remediate one or more virtual components (e.g., VNFs) in the virtual layer. See Parag. [0046]; The adaptor can also translate actions in the policy action file into commands for an orchestrator associated with a VNF. An example orchestrator is Cloudify®. For example, the adaptor can generate one or more commands that cause the orchestrator to invoke a new virtual infrastructure configuration action. These commands can include sending a new blueprint to the orchestrator. A blueprint can indicate which VNFs should be instantiated on which physical devices. For remedial actions in the virtual layer, additional example commands can invoke a load balancing change or an instantiation of a VM (i.e., VNF, See Parag. [0027]). See Parag. [0089]; when multiple VNF alerts indicate that video service is degraded, the prediction valuator can determine that all of these VNFs are running on the same physical host (a group comprising a plurality of load-balanced VNFs). The prediction valuator can create an RCA event indicating the host is down and send the RCA event to the self-healing component and associated action framework. See Parag. [0025]; The virtual analytics engine can provide alerts when KPI thresholds are breached (i.e., exceed the threshold, See Parag. [0027]). See also Parag. [0069] [0088] [0094]),
in a case in which the determination in the first determination process is negative, execute a specifying process of specifying a hardware resource (physical/hardware component) related to the performance degradation of the VNF or CNF when the signal is received (See Parag. [0030-0031]; the system can correlate the physical fault information to the KPI information … The KPI information can indicate one or more VMs and the physical fault information can indicate particular hardware components or ports of those hardware components … The system can use a topology of mapping services to associate the particular virtual components to hardware components. The topology can allow the engines to more accurately correlate the KPI information and the physical fault information. See also Parag. [0033]; the virtual analytics engine can discover virtual components while the physical analytics engine monitors discovered hardware components. The hardware components can report which VNFs they are running, in one example. By discovering both the hardware and virtual components, the system can map these together. See also Parag. [0011] [0028-0029] [0032]),
based on the specifying the hardware resource related to the performance degradation, execute a first command transmission process of transmitting a command to perform auto-healing (self-healing) by redeploying the VNF or CNF from the hardware resource on which it is deployed to a different hardware resource (See Parag. [0034]; A self-healing component of the evaluator engine can then take remedial actions based on the correlation; the self-healing component determines a remedial action based on an action policy file … See Parag. [0037]; an alert object can contain identifying information regarding the component to which the alert relates; For a hardware component, the object can identify a rack, shelf, card, and port … For example, if a particular VNF is implicated, the self-healing component can send a new blueprint to an orchestrator associated with that VNF, resulting in automatic deployment of the VNF to other physical hardware that is not experiencing a physical fault (a different hardware resource) ... See also Parag. [0036] [0038-0042] [0046]).
Embarmannar doesn’t explicitly disclose in a case in which a determination in the first determination process is affirmative, execute a second command transmission process of transmitting a command to perform auto-scaling.
However, Savoor discloses in a case in which a determination in the first determination process is affirmative, execute a second command transmission process of transmitting a command to perform auto-scaling (See Parag. [0022]; controller 128 may be collocated with one or more VNFs, or may be deployed in a different host device or at a different physical location. In one example, the controller 128 may be configured to evaluate the efficiency of individual nodes 102-108 as described herein, where the efficiency may be defined as a node's unit cost per workload processed under varying network traffic conditions (e.g., overload, traffic redirection, etc.). Once the efficiency of a node is known, the controller 128 may be further configured to evaluate the effectiveness of auto-scaling triggers and to make modifications to the auto-scaling triggers where appropriate. For instance, the controller 128 may be configured to perform the steps, functions, and/or operations of the methods 200 and 300, described below, to adjust virtual network function auto-scaling triggers. See Parag. [0032]; rank the VNF relative to other VNFs in the network based on the VNF's efficiency (e.g., unit cost per workload) as calculated in step 206. That is, the processor may calculate the unit cost per workload (as discussed in connection with step 206) for each VNF of a plurality of VNFs. The plurality of VNFs may then be ranked (e.g., from lowest unit cost per workload to highest unit cost per workload) in order to identify which VNFs process their workloads most efficiently. Knowing which VNFs process their workloads most efficiently may help a network operator to identify optimal VNF configurations, resource allocations, and/or workload distributions that will help improve the efficiencies of VNFs whose unit costs per workload are relatively high. See Parag. [0034]; define an auto-scaling trigger associated with a VNF. In one example, the auto-scaling trigger is a scaling up trigger (e.g., a trigger that, when activated, causes additional resources to be extended to the VNF). In one example, a scaling up trigger may be a pre-rated VM scaling trigger, a KPI degradation scaling trigger, a resource utilization scaling trigger, or a VNF-specific scaling trigger. See also Parag. [0036]).
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 actions based on KPI degradation, taught by Embarmannar, to include a process of transmitting a command to perform auto-scaling, as taught by Savoor. This would be convenient to quantifying the efficiency of virtual network function software and for adjusting virtual network function auto-scaling triggers to improve efficiency (Savoor, See Parag. [0001]).
Claim 4. Embarmannar discloses [a] network management method comprising:
receiving a signal (alert) supplied when degradation in performance of a VNF or CNF exceeding a threshold value is detected in a network virtualization environment (See Parag. [0025]; evaluator engine receives the KPI information from a virtual analytics engine … The virtual analytics engine can provide alerts when KPI thresholds are breached … See Parag. [0027]; The KPI information can include performance information of a virtual component, such as a VM. The VM can be a virtual networking component, such as a virtual switch or router. Such virtual networking components are also referred to as VNFs. The KPI information can indicate one or more of packet drops, input packet rate, output packet rate, read latency, write latency, throughput, number of operations, and others; the KPI information is sent to the evaluator engine when the virtual analytics engine determines that particular measured metrics exceed a performance threshold … For example, if a number of packet drops exceeds a threshold during a time period, then the virtual analytics engine can send corresponding KPI information to the evaluator engine. See also Parag. [0007] [0033] [0035] [0037] [0081-0086], Fig. 1B, and Fig. 3 “video service degradation is detected”. Examiner’s interpretation: The claim is interpreted as “receiving a signal supplied when degradation in performance of a VNF exceeding a threshold value is detected in a network virtualization environment”);
based on the receiving of the signal, determining whether degradation in performance is occurring in one or more other VNFs or CNFs belonging to a group comprising a plurality of load-balanced VNFs or CNFs, wherein the group includes the VNF or CNF having the degraded performance (See Parag. [0009]; a root cause originating with hardware in the physical layer can be used to remediate one or more virtual components (e.g., VNFs) in the virtual layer. See Parag. [0046]; The adaptor can also translate actions in the policy action file into commands for an orchestrator associated with a VNF. An example orchestrator is Cloudify®. For example, the adaptor can generate one or more commands that cause the orchestrator to invoke a new virtual infrastructure configuration action. These commands can include sending a new blueprint to the orchestrator. A blueprint can indicate which VNFs should be instantiated on which physical devices. For remedial actions in the virtual layer, additional example commands can invoke a load balancing change or an instantiation of a VM (i.e., VNF, See Parag. [0027]). See Parag. [0089]; when multiple VNF alerts indicate that video service is degraded, the prediction valuator can determine that all of these VNFs are running on the same physical host (a group comprising a plurality of load-balanced VNFs). The prediction valuator can create an RCA event indicating the host is down and send the RCA event to the self-healing component and associated action framework. See Parag. [0025]; The virtual analytics engine can provide alerts when KPI thresholds are breached (i.e., exceed the threshold, See Parag. [0027]). See also Parag. [0069] [0088] [0094]);
in a case in which the degradation in performance is not occuring in the one or more VNFs or CNFs belonging to the group, specifying a hardware resource (physical/hardware component) related to the performance degradation of the VNF or CNF when the signal is received (See Parag. [0030-0031]; the system can correlate the physical fault information to the KPI information … The KPI information can indicate one or more VMs and the physical fault information can indicate particular hardware components or ports of those hardware components … The system can use a topology of mapping services to associate the particular virtual components to hardware components. The topology can allow the engines to more accurately correlate the KPI information and the physical fault information. See also Parag. [0033]; the virtual analytics engine can discover virtual components while the physical analytics engine monitors discovered hardware components. The hardware components can report which VNFs they are running, in one example. By discovering both the hardware and virtual components, the system can map these together. See also Parag. [0011] [0028-0029] [0032]); and
based on the specifying the hardware resource related to the performance degradation, transmitting a command to perform auto-healing (self-healing) by redeploying the VNF or CNF from the hardware resource on which it is deployed to a different hardware resource (See Parag. [0034]; A self-healing component of the evaluator engine can then take remedial actions based on the correlation; the self-healing component determines a remedial action based on an action policy file … See Parag. [0037]; an alert object can contain identifying information regarding the component to which the alert relates; For a hardware component, the object can identify a rack, shelf, card, and port … For example, if a particular VNF is implicated, the self-healing component can send a new blueprint to an orchestrator associated with that VNF, resulting in automatic deployment of the VNF to other physical hardware that is not experiencing a physical fault (a different hardware resource) ... See also Parag. [0036] [0038-0042] [0046]).
Embarmannar doesn’t explicitly disclose in a case in which a degradation in performance is occurring in the one or more VNFs or CNFs belonging to the group, transmitting a command to perform auto-scaling.
However, Savoor discloses in a case in which a degradation in performance is occurring in the one or more VNFs or CNFs belonging to the group, transmitting a command to perform auto-scaling (See Parag. [0022]; controller 128 may be collocated with one or more VNFs, or may be deployed in a different host device or at a different physical location. In one example, the controller 128 may be configured to evaluate the efficiency of individual nodes 102-108 as described herein, where the efficiency may be defined as a node's unit cost per workload processed under varying network traffic conditions (e.g., overload, traffic redirection, etc.). Once the efficiency of a node is known, the controller 128 may be further configured to evaluate the effectiveness of auto-scaling triggers and to make modifications to the auto-scaling triggers where appropriate. For instance, the controller 128 may be configured to perform the steps, functions, and/or operations of the methods 200 and 300, described below, to adjust virtual network function auto-scaling triggers. See Parag. [0032]; rank the VNF relative to other VNFs in the network based on the VNF's efficiency (e.g., unit cost per workload) as calculated in step 206. That is, the processor may calculate the unit cost per workload (as discussed in connection with step 206) for each VNF of a plurality of VNFs. The plurality of VNFs may then be ranked (e.g., from lowest unit cost per workload to highest unit cost per workload) in order to identify which VNFs process their workloads most efficiently. Knowing which VNFs process their workloads most efficiently may help a network operator to identify optimal VNF configurations, resource allocations, and/or workload distributions that will help improve the efficiencies of VNFs whose unit costs per workload are relatively high. See Parag. [0034]; define an auto-scaling trigger associated with a VNF. In one example, the auto-scaling trigger is a scaling up trigger (e.g., a trigger that, when activated, causes additional resources to be extended to the VNF). In one example, a scaling up trigger may be a pre-rated VM scaling trigger, a KPI degradation scaling trigger, a resource utilization scaling trigger, or a VNF-specific scaling trigger. See also Parag. [0036]).
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 actions based on KPI degradation, taught by Embarmannar, to include a process of transmitting a command to perform auto-scaling, as taught by Savoor. This would be convenient to quantifying the efficiency of virtual network function software and for adjusting virtual network function auto-scaling triggers to improve efficiency (Savoor, See Parag. [0001]).
Note: The Examiner notes, that for examination purposes, only one condition needs to be satisfied in “in a case in which a degradation in performance is occurring in the one or more VNFs or CNFs belonging to the group, transmitting a command to perform auto-scaling; in a case in which the degradation in performance is not occuring in the one or more VNFs or CNFs belonging to the group ...”
Allowable Subject Matter
Claim 3 is objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and overcome the claim objections set forth in this office action.
The following is the reason for objecting to claim 3:
With regards to claim 3, Embarmannar Vijayan et al. (Pub. No. US 2020/0235986) in view of Savoor et al. (Pub. No. US 2020/0213205) fails to fairly teach or suggest “in a case in which the determination in the first determination process is negative, execute a second determination process of determining whether the degradation in performance of the VNF or CNF exceeding a threshold value is detected in one or more other VNFs or CNFs that operate on a network function virtualization infrastructure (NFVI) on which the VNF or CNF having the degraded performance operates, in a case in which a determination in the second determination process is affirmative, specify a hardware resource related to the NFVI in the specifying process”
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Vasudevan et al. (Pub. No. US 2024/0276399) – Related art in the area of adaptive dimensioning and provisioning a resource of current resources of a cloud-based infrastructure of a telecommunications network, (Abstract; A method performed by a network node for adaptive dimensioning and provisioning a resource of current resources of a cloud-based infrastructure of a telecommunications network is provided. The method includes dimensioning bounds of usage of the resource for a dimensioning interval that is greater than a scaling interval of an underlying orchestrator based on an amount of data available. The method further includes provisioning of the resource when a maximum bound of the dimensioning exceeds the current resources; checking whether measurement of actual usage of the resource deviates from at least one of the bounds by more than a deviation threshold value; performing a change to the value of the deviation threshold based on the checking).
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.
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, Oscar Louie can be reached on 571-270-1684. 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 2445
/OSCAR A LOUIE/Supervisory Patent Examiner, Art Unit 2445
Prosecution Insights