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 .
Remarks
The present application having Application No. 18/896,839 filed on 09/25/2024 presents claims 1-20 for examination.
The present application is a continuation of U.S. Patent Application No. 18/337,566, filed on June 20, 2023, now issued US Patent No. 12,118,407, which is a continuation of U.S. Patent Application No. 16/976,999, filed on August 31, 2020, now issued US Patent No. 11,720,412 B2, which is a U.S. national stage patent application under 35 U.S.C. 371 of PCT Patent Application No. PCT/US2018/020352, filed on March 1, 2018.
Examiner Notes
Examiner cites particular columns and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
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.
Drawings
The applicant’s drawings submitted are acceptable for examination purposes.
Priority
Acknowledgment is made of applicant's claim for priority based on a national stage entry from a PCT application (PCT/US2018/020352) filed 03/01/2018.
Information Disclosure Statement
The information disclosure statements (IDSs) submitted on 09/25/2024 and 09/10/2025 have been acknowledged and the cited references have been considered by the examiner.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the claims at issue are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the reference application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO internet Web site contains terminal disclaimer forms which may be used. Please visit http://www.uspto.gov/forms/. The filing date of the application will determine what form should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to http://www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claim 1-9 and 11-19 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-26 of U.S. Patent No. US 11,720,412 B2. Although the claims at issue are not identical, they are not patentably distinct from each other because the claims of present application are fully anticipated by the claims of issued patent. The issued US patent and the instant application are claiming common subject matter. The one of ordinary skill in the art would recognize that they are obvious variants.
Claims 1-9 and 11-19 are compared to claims 1-11 and 14-26 of US patent 11,720,412 B2 in the following table:
Instant Application
US Patent No : 11,720,412 B2
Claim 1: A computer-implemented method executed by data processing hardware that causes the data processing hardware to perform operations comprising:
executing a primary pool of primary virtual machine (VM) instances, the primary pool of VM instances comprising a first amount of primary VM instances, each primary VM instance executing a corresponding individual service instance;
determining, based on the first amount of primary VM instances in the primary pool of primary VM instances, a first amount of secondary VM instances required to maintain availability of each individual service instance when one or more of the primary VM instances are unavailable;
instantiating a secondary pool of secondary VM instances based on the first amount of secondary VM instances required to maintain availability of each individual service instance;
after instantiating the secondary pool of secondary VM instances, determining that the primary pool of primary VM instances comprises a second amount of primary VM instances different than the first amount of primary VM instances; determining, based on the second amount of primary VM instances in the primary pool of primary VM instances, a second amount of secondary VM instances required to maintain availability of each individual service instance when one or more of the primary VM instances are unavailable; and updating the secondary pool of secondary VM instances based on the second amount of secondary VM instances required to maintain availability of each individual service instance.
Claim 2 The computer-implemented method of claim 1, wherein the secondary pool of secondary VM instances is passive and idle until a failover causes the secondary pool of secondary VM instances to commence executing the corresponding individual service instance associated with a particular primary VM instance that is unavailable.
Claim 3 The computer-implemented method of claim 1, wherein the secondary pool of secondary VM instances is shared among multiple customers of a distributed system.
Claim 4 The computer-implemented method of claim 1, wherein the first amount of secondary VM instances is less than the first amount of primary VM instances.
Claim 5 The computer-implemented method of claim 1, wherein the second amount of secondary VM instances is less than the second amount of primary VM instances.
Claim 6 The computer-implemented method of claim 1, wherein the operations further comprise: determining a corresponding VM type for each primary VM instance in the primary pool of primary VM instances; and for each particular VM type in the pool of primary VM instances, instantiating at least one secondary VM instance having the particular VM type.
Claim 7 The computer-implemented method of claim 6, wherein the particular VM type indicates at least one of a memory resource requirement, a computing resource requirement, a network specification requirement, or a storage resource requirement.
Claim 8 The computer-implemented method of claim 1, wherein the operations further comprise identifying unavailability of a particular primary VM instance of the pool of primary VM instances.
Claim 9 The computer-implemented method of claim 8, wherein the operations further comprise causing the corresponding individual service instance executing on the particular primary VM instance to failover to one of the secondary VM instances to commence executing the corresponding individual service instance.
Claim 11-19 are system claims that corresponds to method claims 1-9.
Claim 1: A method of maintaining availability of on a distributed system, the method comprising:
executing, by data processing hardware of the distributed system, a pool of primary virtual machine (VM) instances, each primary VM instance executing a corresponding individual service instance
determining, by the data processing hardware, a number of secondary VM instances required to maintain availability of the individual service instances when one or more of the primary VM instances are unavailable based on the number of primary VM instances in the pool of primary VM instances
instantiating, by the data processing hardware, a pool of secondary VM instances based on the number of secondary VM instances required to maintain availability of the individual service instances;
Claim 3The method of claim 1, further comprising updating, by the data processing hardware, the number of secondary VM instances required to maintain availability of the individual service instances when the number of primary VM instances executing in the pool changes.
Detecting change in number of primary VM instances and then updating the number of secondary VM instances to maintain availability implies determining primary pool of VM instances comprises different amount. The pending first/second amount terminology merely recites the initial and subsequently updated quantities of issued claims 1 and 3.
Claim 7
wherein each secondary VM instances in the pool of secondary VM instances is passive and idle unless a failover causes the corresponding secondary VM instances to commence executing an individual service instance associated with an unavailable primary VM instance in the pool of primary VM instances
Claim 11
wherein the pool of secondary VM instances are shared among multiple customers of the distributed system.
Claim 2
wherein a number of secondary VM instances in the pool of secondary VM instances is less than the number of primary VM instances in the pool of primary VM instances.
Claims 2 and 3
wherein a number of secondary VM instances in the pool of secondary VM instances is less than the number of primary VM instances in the pool of primary VM instances.
Claims 2 and 3 together recite the less-than secondary/primary relationship and updating the secondary quantity when the primary quantity changes. Retaining the issued claim 2 redundancy relationship after the claim 3 update is an obvious and predictable implementation.
Claim 8
wherein instantiating the pool of secondary VM instances comprises: determining a corresponding VM type for each primary VM instance in the pool of primary VM instances; and for each different VM type in the pool of primary VM instances, instantiating at least one secondary VM instances having the same VM type.
Claim 9 The method of claim 8, wherein the corresponding VM type for each primary VM instance indicates at least one of memory resource requirements, computing resource requirements, network specification requirements, or storage resource requirements for the corresponding primary VM instance.
Claim 1
identifying, by the data processing hardware, unavailability of one of the primary VM instances in the pool of primary VM instances;
Claim 1
causing, by the data processing hardware, the unavailable primary VM instance to failover to one of the secondary VM instances in the pool of secondary VM instances to commence executing the individual service instance associated with the unavailable primary VM instance;
Claims 14-26 are corresponding system claims.
Claim Rejections - 35 USC § 103
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 of this title, 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.
Claims 1, 2, 4-6, 8-9, 11, 12, 14-16, 18 and 19 are rejected under pre-AIA 35 U.S.C. 103 as being unpatentable over Paul Miller (US 2017/0116020 A1) (hereinafter Miller) in view of Bruun et al. (US 2016/0335111 A1) (hereinafter Bruun).
As per claim 1, Miller discloses A computer-implemented method executed by data processing hardware that causes the data processing hardware to perform operations (e.g., Miller: Miller discloses a VNF manager and infrastructure manager that manage virtual-machine capacity and cause VMs to be provisioned or decommissioned. Miller 0006–0008, 0035–0036, 0068–0073; Figs. 1 and 6.) comprising: executing a primary pool of primary virtual machine (VM) instances, the primary pool of VM instances comprising a first amount of primary VM instances, each primary VM instance executing a corresponding individual service instance (e.g., Miller discloses service-component instances 208-1 through 208-4 executing on respective VMs 206-1 through 206-4. [Miller 0043–0048; Fig. 2.] Miller additionally teaches N VMs sufficient to meet current service demand and, in an active/standby arrangement, N active VMs that provide services. Miller 0051–0052, 0059, and 0070. Miller: [0059] discloses a redundancy model is an active/standby model. In an active/standby model, the N virtual machine [a pool of primary VM instances] actively provide services while the M virtual machines are idle or on standby. For example, Fig. 3b illustrates six of the nine virtual machine may be designated as active virtual machines [primary VMs] while three may be designated as standby virtual machines [secondary VMs]. [0003] discloses various telecommunication functions that provide telecommunication services. [Fig. 2] discloses executing a plurality of VMs (206-1 to 4), each VM executing a corresponding VNF service instance (208-1 to 4).); determining, based on the first amount of primary VM instances in the primary pool of primary VM instances, a first amount of secondary VM instances required to maintain availability of each individual service instance when one or more of the primary VM instances are unavailable (e.g. Miller: teaches high availability for failure of VMs and physical machines. [Miller 0019–0021]. Miller determines N, the service-demand VM quantity, and M, an additional VM quantity for worst-case failure. [Miller 0020–0023, 0050–0052, and 0070–0071]. Miller teaches that an additional VM can take over when a VM running a VNF component fails. [Miller 0049]. In Miller’s example, eight VMs satisfy service demand and four additional VMs are provisioned because four VMs may be lost upon failure of one physical machine. [Miller 0021]. [0059] discloses a redundancy model is an active/standby model. In an active/standby model, the N virtual machine actively provide services while the M virtual machines [number of secondary VM instances] are idle or on standby. For example, Fig. 3B illustrates six of the nine virtual machine may be designated as active virtual machines [primary VMs] while three may be designated as standby virtual machines [secondary VMs]. M represents number of secondary VMs and N represents number of primary VMs. [0006-0007] [0020] discloses determining a second number of VMs [secondary VMs] that handles failure of active/primary VMs. [0049] discloses if any of the VMs running VNF components/services fails, then one of the additional virtual machines can take over for the failed virtual machine. [0071] discloses determining a second number that is equal to the highest number of virtual machines being provided by a machine. The second number corresponds to M [secondary VMs]. In other words the second number of VMs represents the number of VMs above the number deemed sufficient to meet current demand for services. By having this number equal to the highest number of VMs being provided by a single machine, the VNF is capable of handling a situation in which that physical machine which supports the highest number of VMs fails.); instantiating a secondary pool of secondary VM instances based on the first amount of secondary VM instances required to maintain availability of each individual service instance (e.g., Miller defines total VM capacity as N+M, where N is the current-demand VM amount and M is the additional VM amount. Miller ¶ 0051. Miller compares N+M to the currently provisioned amount and instructs NFVI to provision or decommission VMs as needed. [Miller 0056–0057 and 0070–0072]. In the active/standby model, M VMs are idle or standby. [Miller 0059].); after instantiating the secondary pool of secondary VM instances, determining that the primary pool of primary VM instances comprises a second amount of primary VM instances different than the first amount of primary VM instances (e.g. Miller: [0056] discloses total number of VMs (i.e., 9) is equal to N(i.e., 6) + M (i.e., 3). M is less than N, M represents number of secondary VMs and N represents primary VMs. [0059] six of the nine virtual machines may be designated as active virtual machines [primary VM instances] while three of the nine virtual machines may be designated as standby virtual machines Miller teaches that VNF component instances and their VMs are created as demand increases and removed/decommissioned when demand decreases. [Miller 0018, 0022, 0042, 0047–0048, 0060, and 0068.]); determining, based on the second amount of primary VM instances in the primary pool of primary VM instances, a second amount of secondary VM instances required to maintain availability of each individual service instance when one or more of the primary VM instances are unavailable; and updating the secondary pool of secondary VM instances based on the second amount of secondary VM instances required to maintain availability of each individual service instance (e.g. . [0006-0007] [0020-0021] discloses determining a second number of VMs [secondary VMs] that handles failure of active/primary VMs. [0049] discloses if any of the VMs running VNF components/services fails, then one of the additional virtual machines can take over for the failed virtual machine. [0071] discloses determining a second number that is equal to the highest number of virtual machines being provided by a machine. The second number corresponds to M [secondary VMs]. In other words the second number of VMs represents the number of VMs above the number deemed sufficient to meet current demand for services. By having this number equal to the highest number of VMs being provided by a single machine, the VNF is capable of handling a situation in which that physical machine which supports the highest number of VMs fails. Miller teaches changing redundancy quantity M, but principally determines M from the highest number of service VMs supported by a physical machine.).
Miller does not expressly describe the additional capacity as a separately managed secondary pool having a desired capacity level that is redetermined from the changed primary-pool amount and updated according to that redetermined capacity. Specifically, Miller does not expressly disclose determining, based on the second amount of primary VM instances in the primary pool of primary VM instances, a second amount of secondary VM instances; and updating the secondary pool of secondary VM instances based on the second amount of secondary VM instances.
However, Bruun discloses determining, based on the second amount of primary VM instances in the primary pool of primary VM instances, a second amount of secondary VM instances required to maintain availability of each individual service instance when one or more of the primary VM instances are unavailable; and updating the secondary pool of secondary VM instances based on the second amount of secondary VM instances required to maintain availability of each individual service instance (e.g., Bruun: Bruun discloses VNF components implemented by VMs, deactivated VMs, a resource pool of deactivated VMs, and activation of a selected number of deactivated VMs for scale-out. [Bruun 0020–0028, 0030–0032, 0045–0052, and 0060–0064; Figs. 2 and 4]. Bruun teaches that the deactivated VM resource pool has a desired capacity level. [Bruun 0045–0046]. After a VM is activated from the pool, Bruun creates and hibernates a new VM of the corresponding type to replenish the pool and maintain the desired capacity. [Bruun 0053]. During scale-in, a VM may be returned to the pool or deleted according to the desired capacity level. [Bruun 0055–0057].).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Miller’s dynamically provisioned additional/standby VM capacity using Bruun’s separately managed deactivated-VM pool technique. The modification would predictably replenish, retain, or reduce standby capacity as Miller’s primary service population changes, maintain sufficient availability capacity for changed service demand, reduce delay in providing additional VM capacity, and avoid unnecessary resource consumption by excess standby VMs. Miller teaches dynamic availability capacity adjustment and resource efficiency, while Bruun teaches maintaining a desired pool capacity. (Miller: 0049, 0054–0055, 0067, and 0074; Bruun: 0021–0028, 0046, 0050–0058, and 0063–0064).
As per claim 2, the combination of Miller and Bruun discloses The computer-implemented method of claim 1 [See rejection to claim 1 above], wherein the secondary pool of secondary VM instances is passive and idle until a failover causes the secondary pool of secondary VM instances to commence executing the corresponding individual service instance associated with a particular primary VM instance that is unavailable (e.g., Miller teaches an active/standby model in which N VMs actively provide services while M VMs are idle or standby. [Miller 0059]. Miller also teaches that an additional VM can take over after failure of a VM running a VNF component. [Miller 0049].).
As per claim 4, the combination of Miller and Bruun discloses The computer-implemented method of claim 1 [See rejection to claim 1 above], wherein the first amount of secondary VM instances is less than the first amount of primary VM instances (e.g. Miller: Miller’s [Fig. 3B and 0056] disclose N=6 active/service VMs and M=3 additional/standby VMs. [Miller 0059] identifies the six VMs as active and three VMs as standby.).
As per claim 5, the combination of Miller and Bruun discloses The computer-implemented method of claim 1 [See rejection to claim 1 above], wherein the second amount of secondary VM instances is less than the second amount of primary VM instances (e.g. Miller teaches dynamically changing redundancy quantity M as the primary/service VM population changes. [Miller 0060–0067, 0072, and 0074]. Miller demonstrates a redundancy policy in which M<N. To the extent Miller does not expressly state that every dynamically updated M remains less than the updated N, it would have been obvious to retain the demonstrated M<N relationship while updating the secondary pool. Miller seeks adequate redundancy while consuming as few computing resources as possible. [Miller 0049, 0054–0055, 0067, and 0074].).
As per claim 6, the combination of Miller and Bruun discloses The computer-implemented method of claim 1 [See rejection to claim 1 above], wherein the operations further comprise: determining a corresponding VM type for each primary VM instance in the primary pool of primary VM instances; and for each particular VM type in the pool of primary VM instances, instantiating at least one secondary VM instance having the particular VM type (e.g. Miller teaches different VNF component types, including database, service, and load-balancer components, executing on respective VMs. [Miller 0043–0046; Fig. 2]. Bruun teaches creating at least one VM for each VNFC type, deactivating the VMs, forming a resource pool, and activating a suitable VM type from the pool. [Bruun 0042–0046 and 0060–0064; Fig. 4].).
As per claim 8, the combination of Miller and Bruun discloses The computer-implemented method of claim 1 [See rejection to claim 1 above], wherein the operations further comprise identifying unavailability of a particular primary VM instance of the pool of primary VM instances (e.g., Miller teaches handling failures of VMs and physical machines, and teaches that an additional VM can take over if a VM running a VNF component fails. [Miller 0019–0021, 0049, and 0058].).
As per claim 9, the combination of Miller and Bruun discloses The computer-implemented method of claim 8 [See rejection to claim 8 above], wherein the operations further comprise causing the corresponding individual service instance executing on the particular primary VM instance to failover to one of the secondary VM instances to commence executing the corresponding individual service instance (e.g., Miller teaches another service component taking over for a failed service component, an additional VM taking over for a failed VM, and other VMs taking over processing services formerly provided by failed VMs. [Miller 0044, 0049, and 0058]. Miller discloses determining failure of VMs executing on a physical machine and mechanisms to handle failure of VMs. [Miller 0019-0021]. Miller discloses Fault tolerance scheme, If any of the VMs running those VNF components fails [primary VM unavailable], then one of the additional VMs [secondary VMs] can take over for the failed VM. [Miller 0019-0021]. Also see [0067] [0074].).
As per claims 11, 12 14-16, 18 and 19, these are system claims having similar limitations as cited in method claims 1, 2, 4-6, 8 and 9, respectively. Thus, claims 11, 12 14-16, 18 and 19 are also rejected under the same rationale as cited in the rejection of rejected claims 1, 2, 4-6, 8 and 9, respectively.
Claims 3, 7, 13 and 17 are rejected under pre-AIA 35 U.S.C. 103 as being unpatentable over Miller in view of Bruun and further in view of Chin et al. (US 2014/0007097 A1) (hereinafter Chin).
As per claim 3, the combination of Miller and Bruun discloses The computer-implemented method of claim 1 [See rejection to claim 1 above], but does not expressly disclose wherein the secondary pool of secondary VM instances is shared among multiple customers of a distributed system.
However, Chin discloses wherein the secondary pool of secondary VM instances is shared among multiple customers of a distributed system (e.g. Chin teaches resource changes for VMs provided for a customer pursuant to SLA information. [Chin 0009 and 0092–0094]. Chin also teaches multiple virtual routers provisioned to different customers or tenants on one system and dynamic allocation/deallocation of system resources among the tenant virtual routers. [Chin 0158–0161].).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to apply Chin’s known multi-customer/tenant virtualized environment into Miller-Bruun pooled secondary capacity. The modification would permit standby capacity to be shared across customer services while maintaining availability and improving utilization of idle virtualized resources. Chin teaches sharing and dynamically allocating resources among multiple tenant VMs, and Miller teaches avoiding excess availability capacity while retaining sufficient redundancy. (Chin: 0158–0161; Miller: 0049, 0054–0055, 0067, and 0074.)
As per claim 7, the combination of Miller and Bruun discloses The computer-implemented method of claim 6 [See rejection to claim 6 above], but does not expressly disclose wherein the particular VM type indicates at least one of a memory resource requirement, a computing resource requirement, a network specification requirement, or a storage resource requirement.
However, Chin discloses wherein the particular VM type indicates at least one of a memory resource requirement, a computing resource requirement, a network specification requirement, or a storage resource requirement (e.g. Chin teaches VM resources including processing resources, memory resources, I/O resources, network resources, bandwidth, ports, and non-volatile memory/storage. [Chin 0008 and 0032–0037]. Chin further teaches resource configuration information that identifies resources assigned to a VM at launch, including processing resources, system memory, non-volatile memory, networking resources, bandwidth, and I/O resources. [Chin 0045–0046, 0055–0058, and 0068–0073].).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to use Chin’s known VM resource configurations to define or select VM types used in the Miller-Bruun primary and secondary pools. A VNF component’s computing, memory, network, and storage requirements determine the VM configuration needed to execute that component. The modification allows the management system to select and maintain a secondary VM type capable of supporting the corresponding primary service workload.
As per claims 13 and 17, these are system claims having similar limitations as cited in method claims 3 and 7, respectively. Thus, claims 13 and 17 are also rejected under the same rationale as cited in the rejection of rejected claims 3 and 7, respectively.
Claims 10 and 20 are rejected under pre-AIA 35 U.S.C. 103 as being unpatentable over Miller in view of Bruun and further in view of Rangarajan et al. (US 2021/0144056 A1) (hereinafter Rangarajan).
As per claim 10, the combination of Miller and Bruun discloses The computer-implemented method of claim 1 [See rejection to claim 1 above], but does not expressly disclose wherein each primary VM instance further executes a corresponding container.
However, Rangarajan discloses wherein each primary VM instance further executes a corresponding container (e.g. Rangarajan: Rangarajan teaches Kubernetes as a platform for automating deployment, scaling, and operation of containers across clusters of hosts. Rangarajan further teaches that containers provide isolation for cloud-platform microservices and that Kubernetes containers and pods may be deployed in VMs. [Rangarajan 0040]. Rangarajan additionally teaches an NFVI in which VNFC instances are deployed on VMs. [Rangarajan 0002–0006, 0037, and 0046]. Thus, Rangarajan teaches a VM-based VNF environment in which a VM deploys or hosts a containerized workload.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to configure each Miller-Bruun primary VM to execute a corresponding container as taught by Rangarajan. Miller teaches VM-based VNF service components and dynamic availability management. [Miller 0043–0049, 0051–0059, and 0068–0074]. Bruun teaches VM-based VNF components and dynamically maintained deactivated VM capacity. [Bruun 0020–0023, 0045–0057, and 0060–0064]. Rangarajan teaches a well-known containerized implementation for workloads deployed in VMs. [Rangarajan 0040]. The combination would predictably provide container-based isolation and independently deployable/scalable service workloads inside Miller’s primary VMs while retaining the Miller-Bruun dynamic primary/secondary VM availability architecture.
As per claim 20, this is a system claim having similar limitations as cited in method claim 10. Thus, claim 20 is also rejected under the same rationale as cited in the rejection of rejected claim 10.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Hiren Patel whose telephone number is (571) 270-3366. The examiner can normally be reached on Monday-Friday 9:30 AM to 6:00 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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
If attempts to reach the above noted Examiner by telephone are unsuccessful, the Examiner’s supervisor, Emerson Puente, can be reached at the following telephone number: (571) 272-3652. 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 Patent Center and the Private Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from Patent Center or Private PAIR. Status information for unpublished applications is available through Patent Center or Private PAIR to authorized users only. Should you have questions on access to Patent Center or the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
September 29, 2026
/HIREN P PATEL/Primary Examiner, Art Unit 2196
