CTNF 18/685,760 CTNF 101688 Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. Claim Rejections - 35 USC § 112 07-30-02 AIA The following is a quotation of 35 U.S.C. 112(b): (b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention. The following is a quotation of 35 U.S.C. 112 (pre-AIA), second paragraph: The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention. 07-34-03 AIA The term “ heavy ” in claim 40 is a relative term which renders the claim indefinite. The term “ heavy ” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. The quantity in the claim rendered indefinite by the use of the term "heavy" is the quantity of internal traffic attributed to the network affinity group, as "heavy" traffic is a subjective term . “heavy” is used in the same manner in claim 47, and therefore renders that claim indefinite as well . Claim Rejections - 35 USC § 102 07-07-aia AIA 07-07 The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action: A person shall be entitled to a patent unless – 07-12-aia AIA (a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention. 07-15-03-aia AIA Claim s 31-32, 38-40, 45-47, and 50 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Kludy et al (US Patent no. 10868771), hereinafter referred to as Kludy . Regarding claim 31, Kludy teaches: A method performed by a first network node, the method comprising: receiving from a second network node a request for creating and starting a virtual machine (VM) in a network, wherein the request comprises at least one group identifier. (see e.g., column [0015], lines [0005-0010], “ The method of claim 4, further comprising, responsive to a request for a machine within the scope, selecting a machine located on one of the VLANs in the network group associated with the scope or creating a new virtual machine on one of the VLANs in the network group associated with the scope. ”) (see also e.g., column [0014], lines [0063-0067], “ The method of claim 1, further comprising receiving, by the network management device, information to associate a scope with each of the plurality of network groups, wherein the scope defines one or more machines or applications that can communicate packets to each other.”) For clarification, the scope of a group is being treated as an identifier. Regarding claim 32, Kludy teaches: The method according to claim 31, further comprising, based on the at least one group identifier, determining a compute node to instantiate the VM. (see e.g., column [0015], lines [0005-0010], “ The method of claim 4, further comprising, responsive to a request for a machine within the scope, selecting a machine located on one of the VLANs in the network group associated with the scope or creating a new virtual machine on one of the VLANs in the network group associated with the scope. ”) Regarding claim 38, Kludy teaches: The method according to claim 31, further comprising creating and starting the VM on a compute node, in accordance with the request. (see e.g., column [0015], lines [0005-0010], “ The method of claim 4, further comprising, responsive to a request for a machine within the scope, […] creating a new virtual machine on one of the VLANs in the network group associated with the scope. ”) Regarding claim 39, Kludy teaches: The method according to claim 31, wherein at least one group identified by the at least one group identifier is a network affinity group. (see also e.g., column [0014], lines [0063-0067], “ The method of claim 1, further comprising receiving, by the network management device, information to associate a scope with each of the plurality of network groups, wherein the scope defines one or more machines or applications that can communicate packets to each other.”) The specification describes a network affinity group as a group where VMs within have “internal traffic between each other”. Regarding claim 40, Kludy teaches: The method according to claim 39, wherein there is heavy internal traffic among the VMs in the network affinity group. (see also e.g., column [0014], lines [0063-0067], “ The method of claim 1, further comprising receiving, by the network management device, information to associate a scope with each of the plurality of network groups, wherein the scope defines one or more machines or applications that can communicate packets to each other.”) Regarding claim 42, Kludy teaches: The method according to claim 32, wherein the determined compute node is a candidate compute node that satisfies at least one predefined condition. (see e.g., column [0014], lines [0054-0062], “ The method of claim 1, wherein a second property of the one or more properties identifies a maximum number of machines for each Virtual Local Area Network (VLAN) in the network group 3. The method of claim 2, further comprising receiving, by the network management device, a request to add one or more additional machines to a VLAN and determining based on the second property whether the maximum number of machines for the VLAN has been reached ”) Regarding claim 45, Kludy teaches: A method performed by a second network node, the method comprising: sending to a first network node a request for creating and starting a virtual machine (VM) in a network, wherein the request comprises at least one group identifier. (see e.g., column [0015], lines [0005-0010], “ The method of claim 4, further comprising, responsive to a request for a machine within the scope, selecting a machine located on one of the VLANs in the network group associated with the scope or creating a new virtual machine on one of the VLANs in the network group associated with the scope. ”) (see also e.g., column [0014], lines [0063-0067], “ The method of claim 1, further comprising receiving, by the network management device, information to associate a scope with each of the plurality of network groups, wherein the scope defines one or more machines or applications that can communicate packets to each other.”) For clarification, the scope of a group is being treated as an identifier. Regarding claim 46, Kludy teaches: The method according to claim 45, wherein the at least one group identifier indicates that the first network node should determine a compute node to instantiate the VM. (see e.g., column [0015], lines [0005-0010], “ The method of claim 4, further comprising, responsive to a request for a machine within the scope, selecting a machine located on one of the VLANs in the network group associated with the scope or creating a new virtual machine on one of the VLANs in the network group associated with the scope. ”) Regarding claim 47, Kludy teaches: The method according to claim 45, wherein: at least one group identified by the at least one group identifier is a network affinity group; and there is heavy internal traffic among the VMs in the network affinity group. (see also e.g., column [0014], lines [0063-0067], “ The method of claim 1, further comprising receiving, by the network management device, information to associate a scope with each of the plurality of network groups, wherein the scope defines one or more machines or applications that can communicate packets to each other.”) Regarding claim 50, Kludy teaches: A first network node comprising: a processor; and a memory coupled to the processor, said memory containing instructions executable by said processor, whereby said first network node is operative to: perform the method of claim 31. As such, claim 10 is rejected as being anticipated by Kludy for the same reasons presented with respect to claim 1 . Claim Rejections - 35 USC § 103 07-20-aia AIA 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. 07-22-aia AIA Claim s 33-36 are rejected under 35 U.S.C. 103 as being unpatentable over Kludy as applied to claim s above, and further in view of Agrawal et al (US Patent Pub. no. 2011/0219372 A1), hereinafter Agrawal . Regarding claim 33, Kludy teaches: The method according to claim 31, Kludy fails to expressly teach that determining at least one compute node that has instantiated at least one VM in at least one group identified by the at least one group identifier; computing respective total network costs between one or more candidate compute nodes and the at least one compute node; and determining a compute node, from the one or more candidate compute nodes, to instantiate the VM based on the respective total network costs computed for the one or more candidate compute nodes. However, Agrawal teaches a method comprising: determining at least one node that has instantiated at least one VM in at least one group […]; computing respective total network costs between one or more candidate compute nodes and the at least one compute node; and determining a compute node, from the one or more candidate compute nodes, to instantiate the VM based on the respective total network costs computed for the one or more candidate compute nodes. (see e.g., paragraph [0046-0047], “ In this case, the network cost is considered for the selection of the target hypervisor 108. More specifically in this scenario the global indexer 110 provides a list of target hypervisors 108 sorted based on the network resources needed for the construction of the VM image on the target hypervisor 108. Again, for each target hypervisor 108, block images are downloaded from the source nodes that lead to the lowest network cost. So the network-dictated placement problem iteratively uses the network-assisted placement method (see, e.g., Table 1) […] The output is the sorted list T* of the candidate hypervisors 108. […] Select the hypervisor at the top of the list, i.e., the one that yields the minimum network cost among all candidate hypervisors, as the target hypervisor for the instantiation or the migration of the VM. ”) Kludy and Agrawal are considered to be analogous art to the claimed invention as they are reasonably pertinent to the problem faced by the inventor of instantiating VMs on nodes. Therefore, it would have been obvious to one of ordinary skill in the art that the method of organizing and starting VMs taught by Kludy could include the sorting priority by network cost as taught by Agrawal. Choosing the node with the least network cost between nodes would allow for the communicating nodes to communicate faster and more cost-efficient than they would be able to otherwise. (see e.g., Agrawal, paragraph [0027], “ Then, the system enables a more efficient transfer of a file F from node N1 (source) to node N2 (target) in block 20 by constructing the object on the target host by fetching each block of the object from those hosts that have the blocks while minimizing a cost function in fetching each block. ”) Regarding claim 34, Agrawal teaches: The method according to claim 33, wherein the total network cost between the determined compute node and the at least one compute node is lowest among the respective total network costs computed for the one or more candidate compute nodes. (see e.g., paragraph [0047], “ Select the hypervisor at the top of the list, i.e., the one that yields the minimum network cost among all candidate hypervisors, as the target hypervisor for the instantiation or the migration of the VM. ”) Regarding claim 35, Agrawal teaches: The method according to claim 33, wherein each total network cost computed for a candidate compute node is a weighted sum of network costs between the candidate compute node and a plurality of other compute nodes (see e.g., paragraph [0029], “ The cost function can refer to the network distance, network latency, available bandwidth, server load, etc. ”) Given that the cost function can refer to multiple types of values (see: distance, time (latency), resource consumption (bandwidth available / server load)), to compute a complete cost that is comparable, one would need to multiply each value by some constant to make it so that each value can affect the final cost meaningfully (i.e., without being overpowered by whichever value uses the largest numbers.) in an addition calculation. An addition calculation where each input is multiplied by a constant (that varies depending on whether it is input 1, 2, etc.) is a weighted sum. Regarding claim 36, Agrawal teaches: The method according to claim 33, wherein the total network cost is based on at least one of the following: a total network distance, a total network latency, or total network resource consumption. (see e.g., paragraph [0029], “ The cost function can refer to the network distance, network latency, available bandwidth, server load, etc. ”) available bandwidth tells how much of the network resources aren’t being used. Server load tells how much is being used. Using both, one can find the total network resource consumption as either a percentage or a quantity. Regarding claim 43, Agrawal teaches: The method according to claim 42, wherein the at least one predefined condition comprises at least one of the following: a resource requirement, an affinity policy and an anti-affinity policy. (See e.g., paragraph [0036], “ In block 220, a placement cost for a set of host machines is computed for target placement of the VM. In block 222, one or more of the host machines are selected that minimize placement cost. In block 224, the list is displayed to the user in addition to other possible metrics, e.g., CPU utilization, resource overhead, etc.).” ) The predefined condition seems to be “the lowest placement cost”, and the metrics listed are resource requirements . 07-22-aia AIA Claim s 41 and 48 are rejected under 35 U.S.C. 103 as being unpatentable over Kludy as applied to claim s above, and further in view of Pica8 ("What are the advantages of a spine-leaf architecture", 2019), hereinafter Pica8 . Regarding claim 41, Kludy teaches: The method according to claim 31 Kludy fails to explicitly teach the network comprises a data center network or the network comprises a spine-and-leaf network However, Pica8 teaches: One or more of the following applies: the network comprises a data center network, and the network comprises a spine-and-leaf network (see e.g., paragraph [001-003], “ The spine and leaf network design was originally implemented in data centers as a way to improve performance when handling the predominantly east-west traffic. It does so largely by reducing the number of “hops” between any two devices in the network to just one, because every leaf switch in the network has a direct connection to every spine switch. ”) Kludy and Pica8 are considered to be analogous art to the claimed invention as they are reasonably pertinent to the problem faced by the inventor of managing a data center. Therefore, it would have been obvious to one of ordinary skill in the art that the method to manage VMs on network nodes as taught by Kludy could be performed on a spine-and-leaf network as taught by Pica8. Doing so would, first of all, describe these network nodes in a physical manner (A data center is any facility to house computer systems and related equipment for the purpose of processing data, as per Merriam Webster). It would also give the advantage of the nodes being close to one another, reducing the network cost of transferring data between nodes. Claim 48 recites substantially the same limitations as claim 41, applied to the method of claim 45. As such, claim 48 is rejected as being unpatentable over Kludy in view of Pica8 for the same reasons as presented with claim 41 . 07-22-aia AIA Claim 37 is rejected under 35 U.S.C. 103 as being unpatentable over Kludy as applied to claim s above, and further in view of Bao Li et al (Patent Document ID CN 111399989 A), hereinafter referred to as Li . Regarding claim 37, Kludy teaches: The method according to claim 31, Kludy fails to teach: When the VM is an initial VM to be instantiated in at least one group identified by the at least one group identifier, randomly selecting a compute node to instantiate the VM, from one or more candidate compute nodes. However, Li teaches that when the VM is an initial VM to be instantiated in at least one group identified by the at least one group identifier, randomly selecting a compute node to instantiate the VM, from one or more candidate compute nodes. (see e.g., page [006], paragraph [0010], “ The preemptive scheduling method first confirms whether there is a task with a lower priority than the task in the resource pool. If so, select a group of nodes to check whether the task is satisfied after pre-destroying the low-priority task. If the operation of the task is satisfied, in this group of low-priority nodes, a node is selected through a random algorithm to destroy the actual low-priority task, and the task is scheduled to the corresponding node, so as to meet the high-priority Level tasks can be carried out smoothly and in a timely manner. ”) Kludy and Li are considered to be analogous art to the claimed invention as they are reasonably pertinent to the problem faced by the inventor of managing network nodes to perform tasks using VMs/Containers. Therefore, it would have been obvious to one of ordinary skill in the art that the method to manage VMs on network nodes as taught by Kludy could include random node selection during initialization as taught by Li. Doing so would vastly simplify the algorithm used to select nodes, without resorting to a “fixed” setup . 07-22-aia AIA Claim s 44 and 49 are rejected under 35 U.S.C. 103 as being unpatentable over Kludy as applied to claim s above, and further in view of Song Toh ("What to look for in an NFV Deployment and Orchestration Solution", 2017), herinafter Toh . Regarding claim 44, Kludy teaches: The method according to claim 31, Kludy fails to teach: The second network node is or comprises a Network Functions Virtualization Orchestrator or a Virtual Network Function manager; and the first network node is or comprises a Virtualized Infrastructure Manager. However, Toh teaches the second network node is or comprises a Network Functions Virtualization Orchestrator or a Virtual Network Function Manager; and the first network node is or comprises a Virtualized Infrastructure Manager. (see e.g., pages [001-002], paragraphs [004-009], “ Let’s take a look at the three major components of NFV Management and Orchestration (MANO) as specified by the standard body ETSI: Component: NFV Orchestrator […] Component: VNF Manager […] Component: Virtualized Infrastructure Manager (VIM) […] Knowing that our customers face these challenges, we build Cisco’s NFV product offerings to address their needs. These solutions are certified to work together, but at the same time, have also been deployed as standalone products integrating with other vendors’ NFV Orchestrator, VNFM and VIM ” [bolded for emphasis]) For clarity’s sake, the skipped over parts ([…]) are descriptions of the technology landscape of particular components and were omitted to better show the separate components of the prior art. Kludy and Toh are considered to be analogous art to the claimed invention as they are reasonably pertinent to the problem faced by the inventor of finding or building an architecture to support virtual network functions. Therefore, it would have been obvious to one of ordinary skill in the art that the method as performed by Kludy could be performed on the architecture taught by Toh. Doing so would allow for the method to outsource more detailed functions that would fall under NFVO functions, VNFM functions, or VIM functions to other vendor’s architecture (see e.g., page [002], paragraph [008], “ Knowing that our customers face these challenges, we build Cisco’s NFV product offerings to address their needs. These solutions are certified to work together, but at the same time, have also been deployed as standalone products integrating with other vendors’ NFV Orchestrator, VNFM and VIM ”) Claim 49 recites substantially the same limitations as claim 44, applied to the method of claim 45. As such, claim 49 is rejected as being unpatentable over Kludy in view of Pica8 for the same reasons as presented with claim 44. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to Connor Imiola Blackburn whose telephone number is (571)272-6547. The examiner can normally be reached M-Th 7-5. 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, Kevin Young can be reached at (571) 270 - 3180. 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. /C.I.B./Examiner, Art Unit 2194 /KEVIN L YOUNG/Supervisory Patent Examiner, Art Unit 2194 Application/Control Number: 18/685,760 Page 2 Art Unit: 2194 Application/Control Number: 18/685,760 Page 3 Art Unit: 2194 Application/Control Number: 18/685,760 Page 4 Art Unit: 2194 Application/Control Number: 18/685,760 Page 5 Art Unit: 2194 Application/Control Number: 18/685,760 Page 6 Art Unit: 2194 Application/Control Number: 18/685,760 Page 7 Art Unit: 2194 Application/Control Number: 18/685,760 Page 8 Art Unit: 2194 Application/Control Number: 18/685,760 Page 9 Art Unit: 2194 Application/Control Number: 18/685,760 Page 10 Art Unit: 2194 Application/Control Number: 18/685,760 Page 11 Art Unit: 2194 Application/Control Number: 18/685,760 Page 12 Art Unit: 2194 Application/Control Number: 18/685,760 Page 13 Art Unit: 2194
Prosecution Insights