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 .
Claims 1-8, 10-19, and 21-22 are pending. Claims 9 and 20 are cancelled.
Response to Arguments
Regarding 35 U.S.C. 101:
Applicant’s amendments and arguments regarding the rejection of claims 1-20 under 35 U.S.C. 101 have been fully considered and are found to be persuasive. The rejections of claims 1-20 under 35 U.S.C. 101 are withdrawn as the claims are found to integrate the judicial exception of resource allocation into a practical application.
Regarding: Prior Art Rejections:
Applicant’s amendments and arguments regarding the rejection of claims 1-20 under 35 U.S.C. 103 have been fully considered and are moot due to new ground of rejection under Yang et al. US 20190034244 A1 in view of Korupolu US 20090228589 A1 which is necessitated by applicant’s amendment. Korupolu is relied upon to teach the amended limitation of adjusting the deployment location of the virtual machine occupying overrun memory after primary pre-deployment which is interpreted to represent dynamic migration of virtual machines away from overloaded and limited host memory resources following an initial allocation of host memory resources.
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, 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-7, 9, 11-18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Yang et al. US 20190034244 A1 in view of Korupolu US 20090228589 A1.
Regarding claim 1, Yang teaches the invention substantially as claimed including:
A virtualized network function deployment method, under an application scenario in which a virtualized network function is deployed on a virtualized platform, the method being applied to a management and orchestration platform side responsible for application resource management and the method ([0004] a control and management device of a virtualized network function (VNF) in a conventional NFV architecture, such as an NFV orchestrator (NFVO) or a VNF manager (VNFM), implements a VNF) comprising:
acquiring current deployment resource information of a deployment platform ([0009] obtaining, by the NFV control device according to the VNF instantiation request, a resource configuration information group of a VDU included in a VNF; [0113] After receiving a resource allocation request of a VDU, the VIM selects a physical machine that meets a characteristic of a resource applied for by the VDU, and allocates a resource and creating the VDU, a virtual link, and the like on the physical machine; [0133] Information about each VDU specifies a size of the VDU, for example, a quantity of central processing units (CPU) of a virtual machine, CPU performance, a memory size, bandwidth, or a storage size; Examiner notes: in order to determine if a physical machine meets the characteristic for a resource applied for by the VDU, the VIM must obtain or possess the information of the physical machine) and determining a host to be deployed ([0010] the resource allocation device may select a physical machine for the VDU), wherein the deployment resource information comprises memory information and central processing unit information of each host in the deployment platform, the memory information comprises a memory capacity and a memory margin of the each host, and the central processing unit information comprises a number of central processing units corresponding to the each host (([0140] the resource scheduling parameter includes a filter-type resource scheduling parameter (CPU usage of a physical machine), and further includes a corresponding value range (less than 60%), to constitute a filter-type configuration condition (CPU usage of a physical machine is less than 60%). If CPU usage of a physical machine is 50%, it indicates that the physical machine meets the configuration condition; Table 1: AggregateDiskFilter To determine whether hard disk usage of a physical machine is less than specified maximum hard disk usage in a set to which the physical machine belongs, AggregateRamFilter To determine whether memory usage of a physical machine is less than specified maximum memory usage in a set to which the physical machine belongs, ComputeCapabilitiesFilter To determine whether a physical machine has a specified capability ComputeFilter To determine whether a physical machine normally runs CoreFilter To determine whether a CPU of a physical machine meets a requirement (or whether usage of the CPU is less than specified usage … RamFilter To determine whether a memory of a physical machine meets a requirement);
performing, according to virtual machine information of the virtualized network function and the central processing unit information of the host to be deployed, primary pre-deployment on a virtual machine required by the virtualized network function ([0117] A resource allocation device in the embodiments of the present invention is a device that receives a resource allocation request of a VDU included in a to-be-instantiated VNF in a VNF instantiation process, selects a physical machine for the VDU based on the resource allocation request, and allocates a resource and creates the VDU, a virtual link, and the like on the physical machine), wherein the virtual machine information is used for describing requirements of a plurality of virtual machines required by the virtualized network function ([0010] the resource allocation request that includes the resource configuration information group. The resource configuration information group includes the resource scheduling parameter. The resource scheduling parameter is used to indicate the requirement of the VNF on the resource selection and scheduling policy), and the primary pre-deployment comprises selecting hosts to be deployed satisfying requirements for the plurality of virtual machines ([0042] sorting out, by the resource allocation device in a plurality of physical machines, at least one candidate physical machine that meets the filter-type resource scheduling parameter); and
generating, according to the result of the primary pre-deployment and a result of the secondary pre-deployment, a deployment result of the plurality of virtual machines, and sending the deployment result of the plurality of virtual machines to the deployment platform so that the deployment platform implements virtualized network function deployment according to a verified deployment result of the plurality of virtual machines ([0112] [0112] Then the NFVO or the VNFM generates a resource allocation request for each VDU based on the foregoing parameters, and sends the resource allocation request of each VDU to the VIM. The resource allocation request of each VDU includes a characteristic of a resource applied for by the VDU; [0113] After receiving a resource allocation request of a VDU, the VIM selects a physical machine that meets a characteristic of a resource applied for by the VDU, and allocates a resource and creating the VDU, a virtual link, and the like on the physical machine; [0132] Because the VNF may include a plurality of VDUs, these different VDUs may be combined and applied to same “deployment_flavour”; Examiner notes: the deployment results of the virtual machines for the VDUs is seen in the various selected physical machines that meet the respective VDU’s requirements. The deployment results (i.e., deployment results are sent to the physical machines for allocation, creation of VDU and the virtual link).
While Yang teaches incorporating memory requirements into VNF allocation, it does not explicitly teach performing, according to the memory information of each host in the deployment platform, secondary pre-deployment on a virtual machine occupying overrun memory in a result of the primary pre-deployment, wherein the secondary pre-deployment comprises adjusting a deployment location of the virtual machine occupying the overrun memory after the primary pre-deployment according to the memory information.
However, Korupolu teaches performing, according to the memory information of each host in the deployment platform, secondary pre-deployment on a virtual machine occupying overrun memory in a result of the primary pre-deployment ([0026] The VM migration planner 16 in the central migration component 11 utilizes current state of the system (i.e., storage network information 18 and VM state information 20) and determines where to migrate one or more of the VMs 14. For example, the VM migration planner 16 first selects an overloaded physical machine (e.g., one of the host machines 36 in FIG. 2). An overloaded physical machine can be a physical machine where the estimated needs of the VMs currently running on that machine exceed a certain threshold of the machine's available processing capacity along any of the resources. The threshold can be e.g., 100% or a user provided target such as, e.g., 85%), wherein the secondary pre-deployment comprises adjusting a deployment location of the virtual machine occupying the overrun memory after the primary pre-deployment according to the memory information ([0028] The VM migration planner 16 sorts a list of the VMs on the overloaded (source) machine in decreasing order of their UWeight-to-size ratio and selects the first VM in the sorted VM list to find a suitable target physical machine where the VM can be migrated to; [0029-0033] Migration of selected VM).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined Korupolu’s dynamic migration of virtual machines’s hosted on overloaded resources with the existing system. A person of ordinary skill in the art would have been motivated to make this combination to provide the resulting system with the advantage of providing adequate memory resources to meet VNF memory requirements by moving virtual machines to target hosts with sufficient available memory (i.e., adjusting initial virtual machine physical resource allocations/primary pre-deployments) (see Korupolu [0007] The invention provides a method and system of storage-aware selection of virtual machine migration targets. In one embodiment, a method and system selecting a target physical machine for a virtual machine (VM) migration, involves determining storage volume connectivity and spare path capacity of one or more candidate physical machines, and preferentially selecting among the candidate physical machines a migration target with storage volume connectivity and spare path capacity to satisfy storage volume access requirements of the VM).
Regarding claim 2, Yang and Korupolu teach the method of claim 1.
Yang further teaches before acquiring the current deployment resource information of the deployment platform, the method further comprises: in response to a pre-deployment requirement initiated by a user terminal, generating an instance model corresponding to the virtualized network function according to a virtualized network function package ([0111] The NFVO or the VNFM determines, based on the VNF instantiation identifier, a virtualized network function descriptor (VNFD) corresponding to a to-be-instantiated VNF; and acquiring the virtual machine information from the instance model ([0111] obtains deployment information of the VNF in the VNFD, to be specific, the following several parameters: deployment_flavour, information about at least one VDU included in the VNF, virtual_link, connection_point, dependency, and affinity/anti-affinity. The VDU describes a resource requirement of a virtual machine (VM) or a virtual container).
Regarding claim 3, Yang and Korupolu teaches the method of claim 2.
Yang further teaches acquiring the virtual machine information from the instance model comprises: extracting a resource requirement of the virtualized network function from the instance model ([0111] obtains deployment information of the VNF in the VNFD, to be specific, the following several parameters: deployment_flavour, information about at least one VDU included in the VNF, virtual_link, connection_point, dependency, and affinity/anti-affinity. The VDU describes a resource requirement of a virtual machine (VM) or a virtual container), and segmenting the resource requirement in units of virtual machines to generate the virtual machine information ([0133] Information about each VDU specifies a size of the VDU, for example, a quantity of central processing units (CPU) of a virtual machine, CPU performance, a memory size, bandwidth, or a storage size).
Regarding claim 4, Yang and Korupolu teach the method of claim 1.
Yang further teaches the deployment resource information further comprises available domain information and specification information of each host in the deployment platform (see Table 1 attributes).
Regarding claim 5, Yang and Korupolu teach the method of claim 4.
Yang further teaches determining the host to be deployed comprises: determining the host to be deployed that is in the deployment platform and matches a specification and an available domain required by the virtual machine ([0055] selecting, by the resource allocation device for the VDU based on some or all of the plurality of configuration conditions, a physical machine that meets the some or all of the plurality of configuration conditions).
Regarding claim 11, it is the management and orchestration platform of claim 1. Therefore, it is rejected for the same reasons as claim 1.
Yang further teaches at least one processor ([0253] a processor 602); and a storage apparatus configured to store at least one program; wherein the at least one program, when executed by the at least one processor, causes the at least one processor to perform ([0252] The computer software product is stored in a storage medium and includes several instructions for instructing a computer device (which may be a personal computer, a server, or a network device) or a processor to perform all or some of the steps of the methods described in the embodiments of this disclosure. The foregoing storage medium includes any medium that can store program code, such as a USB flash drive, a removable hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disc)
Regarding claim 12, it is the non-transitory computer-readable medium of claim 1. Therefore, it is rejected for the same reasons as claim 1.
Yang further teaches a non-transitory computer-readable medium storing a computer program which, when executed by a processor, causes the processor to perform ([0252] the computer software product is stored in a storage medium and includes several instructions for instructing a computer device (which may be a personal computer, a server, or a network device) or a processor to perform all or some of the steps of the methods described in the embodiments of this disclosure).
Regarding claims 13-16 they are the management and orchestration platforms of claims 2-5 respectively. Therefore, they are rejected for the same reasons as claims 2-5 respectively.
Regarding claim 22, it is the non-transitory computer-readable medium of claim 2. Therefore it is rejected for the same reasons as claim 2.
Claims 6, 7, 8, 17, 18, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Yang et al. US 20190034244 A1 in view of Korupolu US 20090228589 A1 in view of Durrant US 20120290765 A1.
Regarding claim 6, Yang and Korupolu teach the method of claim 1.
Yang and Korupolu do not explicitly teach wherein performing, according to the memory information of each host in the deployment platform, the secondary pre-deployment on the virtual machine occupying the overrun memory in the primary pre-deployment result comprises: determining, according to the memory information of each host in the deployment platform, a target virtual machine satisfying a preset location exchange condition in the primary pre-deployment result; and exchanging a deployment location of the virtual machine occupying the overrun memory with a deployment location of the target virtual machine.
However, Durrant teaches determining, according to the memory information of each host in the deployment platform, a target virtual machine satisfying a preset location exchange condition in the primary pre-deployment result ([0002] a virtual memory manager may redistribute memory resources from virtual machines having sufficient memory resources to other virtual machines that are either non-responsive or excessively swapping pages; Examiner notes: the target virtual machine must have sufficient memory as the preset location exchange condition); and exchanging a deployment location of the virtual machine occupying the overrun memory with a deployment location of the target virtual machine ([0003] The balloon driver of the virtual machine responds to the inflate instruction by (i) requesting that the guest operating system of the virtual machine provide physical memory to the balloon driver and (ii) invoking a hypervisor procedure which de-allocates the provided physical memory from the virtual machine. Once the administrator has reclaimed enough physical memory, the administrator allocates that reclaimed physical memory to the other virtual machine).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined Durrant’s swapping of memory resources between two virtual machines with the existing system. A person of ordinary skill in the art would have been motivated to make this combination to provide the resulting system with the advantage of improving memory utilization by swapping underutilized memory of virtual machines to other virtual machines sharing overutilized memory (see Durrant [0002] Efficient virtualization environments typically comprise virtual machine managers that redistribute memory resources without disrupting operation of virtual machines executing within the environment. Memory resource redistribution can include distributing memory resources amongst virtual machines executing within the virtualization environment, or distributing memory resources to new virtual machines provisioned within the virtualization environment. In some instances, a virtual memory manager may redistribute memory resources from virtual machines having sufficient memory resources to other virtual machines that are either non-responsive or excessively swapping pages).
Regarding claim 7, Yang, Korupolu, and Durrant teach the method of claim 6.
Yang teaches wherein a memory margin and a number of central processing units of a host to which the at least one candidate virtual machine belongs satisfy a requirement of the virtual machine ([0040] when a plurality of factors need to be considered to schedule a resource for the VDU, the resource configuration information group includes filter-type resource scheduling parameters that indicate a plurality of factors, and the resource allocation device may schedule a resource for the VDU based on a plurality of factors, and select, for the VDU, a physical machine that meets the filter-type resource scheduling parameters, thereby improving resource scheduling flexibility in a VNF instantiation process; [Table 1] Resource scheduling parameter Function descriptions of the resource scheduling Resource scheduling parameter parameter … AggregateRamFilter To determine whether memory usage of a physical machine is less than specified maximum memory usage in a set to which the physical machine belongs … CoreFilter To determine whether a CPU of a physical machine meets a requirement).
Durrant further teaches from virtual machines without overrun memory in the primary pre-deployment result, determining, according to the memory information of each host in the deployment platform, at least one candidate virtual machine, wherein a memory margin and a number of central processing units of a host to which the at least one candidate virtual machine belongs satisfy a requirement of the virtual machine occupying the overrun memory ([0002] a virtual memory manager may redistribute memory resources from virtual machines having sufficient memory resources to other virtual machines that are either non-responsive or excessively swapping pages); and
selecting, from the at least one candidate virtual machine, one candidate virtual machine as the target virtual machine ([0003] submitting an inflate instruction to a balloon driver of the virtual machine (e.g., by placing a value in a designated memory location which is periodically monitored). The balloon driver of the virtual machine responds to the inflate instruction by (i) requesting that the guest operating system of the virtual machine provide physical memory to the balloon driver and (ii) invoking a hypervisor procedure which de-allocates the provided physical memory from the virtual machine).
Regarding claim 8, Yang, Korupolu, and Durrant teach the method of claim 6.
Durrant further teaches determining that the target virtual machine satisfying the preset location exchange condition does not exist in the primary pre-deployment result ([0002] virtual machines that are either non-responsive or excessively swapping pages; Examiner notes: a virtual machine that remains non-responsive/excessively swaps pages has no target virtual machine balloon donor which indicates an overcommitted host).
Korupolu further teaches in response to determining that the target virtual machine satisfying the preset location exchange condition does not exist in the primary pre-deployment result, determining a target host outside the primary pre-deployment result according to the memory information and the central processing unit information of each host in the deployment platform, and pre-deploying the virtual machine occupying the overrun memory on the target host ([0005] Certain VM migration techniques determine proper VM migrations (from a source physical machine to a target physical machine) based on server-side parameters only. Such techniques involve monitoring VM resource usages and needs (e.g., CPU, memory, network bandwidth, etc.) dynamically, and responding to hotspots by migrating VMs to other physical machines such as servers, with sufficient remaining capacity along these dimensions; [0008] selecting among the candidate physical machines to host the VM, may include selecting a migration target having one or more of: sufficient processing bandwidth, sufficient memory, sufficient network bandwidth and sufficient storage access bandwidth, to host the storage volume access requirements of the VM).
Regarding claims 17-19, they are the management and orchestration platform of claims 6-8. Therefore, they are rejected for the same reasons as claims 6-8 respectively.
Claims 10 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Yang et al. US 20190034244 A1 in view of Korupolu US 20090228589 A1 in further view of Tahhan et al. US 20210111942 A1
Regarding claim 10, Yang and Korupolu teach the method of claim 1.
Yang and Korupolu do not explicitly teach in response to deployment error information sent by the deployment platform, updating the deployment resource information, and performing, according to the updated deployment resource information, the primary pre-deployment and the secondary pre-deployment again.
However, Tahhan teaches in response to deployment error information sent by the deployment platform, updating the deployment resource information, and performing, according to the updated deployment resource information, the primary pre-deployment and the secondary pre-deployment again (Figure 2C Middle/Right Scenario; [0018] Currently, after recovery from an outage of the management systems, orchestration systems (such as Open stack and Kubernetes) will attempt to re-deploy NFV applications regardless of the actual running state of the NFV services. This causes interruption of the services provided by the applications and causes a second unplanned outage after the initial outage of the management systems; [0032] Once MANO come back online, the local agent would update the MANO on status and allow it to make informed decisions about the need to redeploy VNFs; [0043-0141] For Intel Architecture, an example list of faults could include (note these are platform specific so the list will change depending on what's supported by the platform) can be as follows. Integrated Memory Controller Machine Check Errors: "Address parity error", "HA write data parity error", "HA write byte enable parity error", 8AB9726-Z …).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined Tahhan’s error handling redeployment of disrupted VNF with the system of Yang and Korupolu. A person of ordinary skill in the art would have been motivated to make this combination to provide Yang and Korupolu’s system with the advantage of improving failure recovery (Tahhan: Various embodiments attempt to increase availability of at least an NFV based service on a platform (e.g., Intel Architecture (IA) or ARM), using a remote recovery manager and recovery controller local to a platform that runs NFV services. The recovery controller is preloaded with recovery policies and recovery actions. After management systems recover from a failure, the recovery controller detects at least running VNFs and critical services and keep these services active or apply recovery policy rather than go through a redeployment phase. Various embodiments can help Cloud Service Providers (CSPs) reduce Mean Time To Remediate (MTTR) and Mean Time To Recover (MTTRec) Services in the case of an outage).
Regarding claim 21, it is the management and orchestration platform of claim 10. Therefore, it is rejected for the same reasons as claim 10.
Conclusion
Any inquiry concerning this communication or earlier communications from the
examiner should be directed to HARRISON LI whose telephone number is (703) 756-1469. The
examiner can normally be reached Monday-Friday 9:00am-5:30pm ET.
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, Aimee Li can be reached on (571) 272-4169. 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.
/H.L./
Examiner, Art Unit 2195
/Aimee Li/Supervisory Patent Examiner, Art Unit 2195
Prosecution Insights