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 .
DETAILED ACTION
This Office Action is in response to the amendment filed 09/19/2025.
Claims 1-3, 5-12, and 14-20 are pending in this application.
Claims 1,10 and 18 are independent claims.
Claims 1, 5, 7, 10, 14, 16, and 18 are currently amended.
This Office Action is made final.
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,6,10,11,15,18 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Vaikar (US 2022/0182288 A1) in view of Archer (US 2012/0185867 A1).
As per claim 1, Vaikar teaches A method comprising:
storing, for each host machine of a plurality of host machines, locality information for the host machine that identifies a rack comprising the host machine; (Vaikar [0035] Each rack includes multiple host computing devices in a cluster of host computing devices. Topology information for the network may indicate which nodes run on which hosts and/or which hosts are located on which racks. As such, the topology information indicates associations between nodes and racks. For example, topology information may indicate that nodes 224, 226, and 228 are located on rack 220, while nodes 234, 236, and 238 are located on rack 230. [0046] At 320, network analyzer 302 analyzes the topology of the network. In some embodiments, network analyzer 302 receives network topology information from manager 138 of FIG. 1, physical routers, physical switches, and/or from components on hosts (e.g., monitoring component 118 of FIG. 1). Analyzing the network topology may involve determining associations between nodes and racks.)
responsive to receiving a request requesting execution of a workload: (Vaikar [0036] In FIG. 2, four microservices (S1, S2, S3, and S4) are deployed as container workloads on nodes in racks 220 and 230. [0058] At step 402, an indication is received of user intent for deployment of one or more services [workloads] in a network, wherein the indication of the user intent comprises a domain specific language (DSL)).
constructing linkage information of the one or more host machines included in the available set of host machines based on the locality information of the one or more host machines, wherein linkage information corresponds to a logical topology formed by the one or more host machines included in the available set of host machines (Viakar [0018] The deployment engine may gather topology information and network performance information from one or more components in the network, such as from monitoring nodes on hosts, physical routers, physical switches, and/or from a manager. The topology information may indicate which machines (e.g., hosts, VCIs, and the like) are located on which racks. The network performance information may include, for example, latency and RTT values between pairs of machines, such as the current latency or RTT between two given machines. Latency and RTT are included as examples, and other types of network performance information may be gathered and used in deployment rules. For example, other types of network performance information that may be used with techniques described herein include network throughput (e.g., average data rate of successful packet delivery), bandwidth availability (e.g., how much data can be transmitted per time period), packet loss rate (e.g., the average rate over which transmitted packets are dropped), and the like. References to comparison with a threshold may refer to either an upper threshold (e.g., for network performance information that are intended to be minimized, such as latency) or a lower threshold (e.g., for network performance information that are intended to be maximized, such as throughput) [0061] At step 408, network performance information for the network is determined.).
The examiner is interpreting this “linkage information” according to what is disclosed in the specification (0164] It is appreciated that the linkage information of the one or more host machines corresponds to a logical topology (e.g., logical topology as depicted in FIG. 8B) formed by the one or more host machines.). The available set of machines is taught by Archer and is shown below.
providing the locality information and the linkage information of the one or more host machines included in the available set of host machines in response to the request. (Vaikar [0018] The deployment engine may gather topology information and network performance information from one or more components in the network, such as from monitoring nodes on hosts, physical routers, physical switches, and/or from a manager [0032] Deployment engine 140 generally represents one or more components that perform operations related to rack-aware and network performance-aware service deployment. For example, as described in more detail below with respect to FIGS. 2-5, deployment engine 140 may receive deployment constraints from user device 150 and deploy services according to the deployment constraints in view of network topology information and network performance information gathered from components such as monitoring node 118 and manager 138.).
Vaikar does not teach generating an available set of host machines by identifying one or more host machines of the plurality of host machines that are available for executing the workload, obtaining, for each host machine included in the available set of host machines the locality information for the host machine and receiving a selection of a subset of the one or more host machines included in the available set of host machines; and executing the workload on the subset of the one or more host machines included in the available set of host machines.
However, Archer teaches generating an available set of host machines by identifying one or more host machines of the plurality of host machines that are available for executing the workload, obtaining, for each host machine included in the available set of host machines the locality information for the host machine (Archer Fig 6 and [0066] The example of FIG. 6 also includes determining (614) specific resource requirements for the workload (612a) to be deployed. In the example of FIG. 6, determining (614) specific resource requirements for the workload (612a) to be deployed may be carried out, for example, by examining the computer program instructions that make up the workload (612a). The computer program instructions that make up the workload (612a) may be examined to determine, for example, the number of floating point instructions in the workload (612a), the amount of data communications operations in the workload (612a), the amount of I/O operations in the workload (612a), the number of message passing operations in the workload (612a), and so on. Determining (614) specific resource requirements for the workload (612a) to be deployed may therefore be carried out by determining the nature and amount of system resources that are needed to execute each of the component parts of the workload (612a). [0067] The example of FIG. 6 also includes determining (616) a required geometry of the nodes (602a-602e) to run the workload (612a). In the example of FIG. 6, a required geometry of the nodes (602a-602e) to run the workload (612a) may be determined (616), for example, based on the computer program instructions that make up the workload (612a). For example, a particular workload (612a) may include a collective operation as described above. In such an example, the collective operation requires that the nodes (602a-602e) are organized as a tree. The required geometry of the nodes (602a-602e) to run the workload (612a) in such an example is therefore a tree geometry. Alternatively, a particular workload (612a) may require a high number of data communications operations such that a geometry of nodes (602a-602e) in which the nodes (602a-602e) are within close physical proximity of each other may be preferred so as to avoid data communications between nodes (602a-602e) over long physical distances. [0068] The example of FIG. 6 also includes selecting (618) a set of nodes having attributes that meet the specific resource requirements and arranged to meet the required geometry. In the example of FIG. 6, selecting (618) a set of nodes having attributes that meet the specific resource requirements and arranged to meet the required geometry [locality information] may be carried out, for example, by comparing the attributes (606) of a particular set of nodes (602a-602e) to the resource requirements and required geometry for a workload (612a) to determine a best match. Determining a best match may include prioritizing specific resource requirements of the workload (612a), determining a score for a candidate set of nodes (602a-602e), and so on).
Archer also teaches receiving a selection of a subset of the one or more host machines included in the available set of host machines; (Archer Fig 6 Block 618 and Fig 7 Block 710 and [0068] The example of FIG. 6 also includes selecting (618) a set of nodes having attributes that meet the specific resource requirements and arranged to meet the required geometry. In the example of FIG. 6, selecting (618) a set of nodes having attributes that meet the specific resource requirements and arranged to meet the required geometry may be carried out, for example, by comparing the attributes (606) of a particular set of nodes (602a-602e) to the resource requirements and required geometry for a workload (612a) to determine a best match. Determining a best match may include prioritizing specific resource requirements of the workload (612a), determining a score for a candidate set of nodes (602a-602e), and so on.)
executing the workload on the subset of the one or more host machines included in the available set of host machines. (Archer [0069] The example of FIG. 6 also includes deploying (620) the workload (612a) on the selected nodes. In the example of FIG. 6, deploying (620) the workload (612a) on the selected nodes may be carried out, for example, by sending the workload (612a), or a portion thereof, to an execution queue on the selected nodes, assigning the workload (612a) for execution on processors of the selected nodes, and so on.)
It would have been obvious to a person in the ordinary skill in the art before the filing date of the claimed invention to combine Archer with the system of Vaikar to choose a set of nodes for deploying a workload. One having ordinary skill in the art would have been motivated to use Archer into the system of Vaikar for the purpose of achieving an optimal deployment of a workload on a distributed processing system. (Archer paragraph 03)
As per claim 2, Vaikar teaches wherein the locality information for the host machine comprises information including a rack identifier of the rack comprising the host machine. (Vaikar [0035] Each rack includes multiple host computing devices in a cluster of host computing devices. Topology information for the network may indicate which nodes run on which hosts and/or which hosts are located on which racks. As such, the topology information indicates associations between nodes and racks. For example, topology information may indicate that nodes 224, 226, and 228 are located on rack 220, while nodes 234, 236, and 238 are located on rack 230. [0046] At 320, network analyzer 302 analyzes the topology of the network. In some embodiments, network analyzer 302 receives network topology information from manager 138 of FIG. 1, physical routers, physical switches, and/or from components on hosts (e.g., monitoring component 118 of FIG. 1). Analyzing the network topology may involve determining associations between nodes and racks
As per claim 6, Vaikar teaches wherein the locality information for the host machine is obtained from an instance metadata service, the locality information being stored in the host machine by the instance metadata service via a network virtualization device associated with the host machine. (Vaikar [0028] Hypervisor [network virtualization device] 116 comprises a monitoring node 118 that gathers data related to host 105 and/or VCIs 135, such as network performance and/or topology information. In some embodiments, monitoring node 118 is one component of a distributed monitoring system that gathers metrics for endpoints throughout data center 130. [0035] Each rack includes multiple host computing devices in a cluster of host computing devices. Topology information for the network may indicate which nodes run on which hosts and/or which hosts are located on which racks. As such, the topology information indicates associations between nodes and racks. For example, topology information may indicate that nodes 224, 226, and 228 are located on rack 220, while nodes 234, 236, and 238 are located on rack 230. [0046] At 320, network analyzer 302 analyzes the topology of the network. In some embodiments, network analyzer 302 receives network topology information from manager 138 of FIG. 1, physical routers, physical switches, and/or from components on hosts (e.g., monitoring component 118 of FIG. 1). Analyzing the network topology may involve determining associations between nodes and racks.)
As to claims 10 and 18, they are rejected based on the same reason as claim 1.
As to claims 11 and 19, they are rejected based on the same reason as claim 2.
As to claim 15, it is rejected based on the same reason as claim 6.
Claims 3, 12 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Vaikar (US 2022/0182288 A1) in view of Archer (US 2012/0185867 A1) in further view of Sirton (US 2020/0106675 A1).
As per claim 3, Vaikar and Archer do not teach wherein the locality information for the host machine includes an identifier of a top-of-rack switch associated with the rack.
However, Sirton teaches wherein the locality information for the host machine includes an identifier of a top-of-rack switch associated with the rack. (Sirton [0014] FIG. 7 shows a flowchart describing a method for identifying top-of-rack network devices in accordance with one or more embodiments of the invention. [0016] FIG. 9 shows a flowchart describing a method for identifying top-of-rack network device candidates in accordance with one or more embodiments of the invention).
It would have been obvious to a person in the ordinary skill in the art before the filing date of the claimed invention to combine Sirton with the system of Vaikar and Archer to use an identifier of a top-of-rack switch. One having ordinary skill in the art would have been motivated to use Sirton into the system of Vaikar and Archer for the purpose of enabling automatic classification of computing devices (Sirton paragraph 02).
As to claims 12 and 20, they are rejected based on the same reason as claim 3.
Claims 5 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Vaikar (US 2022/0182288 A1) in view of Archer (US 2012/0185867 A1) in further view of Zhao (US 2019/0312772 A1).
As per claim 5, Vaikar and Archer do not teach wherein the logical topology formed by the one or more host machines is a ring topology.
However, Zhao teaches wherein the logical topology formed by the one or more host machines is a ring topology (Zhao Fig 2A and 2B [0007] FIGS. 2A and 2B schematically illustrate alternative embodiments for configuring a plurality of GPU devices in a ring communication configuration to implement all-reduce operations for distributed DL training, wherein FIG. 2A schematically illustrates a plurality of GPU devices configured in a logical communication ring on a single server node, and wherein FIG. 2B schematically illustrates a plurality of GPU devices configured in a logical communication ring across multiple server nodes. [0044] FIGS. 2A and 2B schematically illustrate alternative embodiments for configuring a plurality of GPU devices in a ring communication configuration to implement all-reduce operations for distributed DL training. In particular, FIG. 2A schematically illustrates a plurality of GPU devices configured in a logical communication ring on a single server node 200. In the illustrative embodiment of FIG. 2A, the plurality of GPU devices comprises four GPU devices, GPU0, GPU1, GPU2, and GPU3, which are arranged in a logical ring with intra-node communication links 202-1, 202-2, 202-3, and 202-4 (collectively, intra-node communication links 202) to communicate in a clockwise direction. In particular, GPU0 sends data to only GPU1 over the intra-node communication link 202-1, GPU1 sends data to only GPU2 over the intra-node communication link 202-2, GPU2 sends data to only GPU3 over the intra-node communication link 202-3, and GPU3 sends data to only GPU0 over the intra-node communication link 202-4. The intra-node communication links can be implemented using, e.g., NVLink, PCIe, etc. [0048] FIG. 2B schematically illustrates a plurality of GPU devices configured in a logical communication ring across multiple server nodes 210 and 220. In the illustrative embodiment of FIG. 2A, the plurality of GPU devices comprises eight GPU devices, GPU0, GPU1, GPU2, GPU3, GPU4, GPU5, GPU6, and GPU7, which are arranged in a logical ring. The server node 220 comprises GPU devices, GPU0, GPU1, GPU2, and GPU3 and intra-node communication links 222-1, 222-2, and 232-3 (collectively, intra-node links 222). The server node 210 comprises GPU devices, GPU4, GPU5, GPU6, and GPU7 and intra-node communication links 212-1, 212-2, and 212-3 (collectively, intra-node links 212). The GPU device GPU7 in the server node 210 communicates with the GPU device GPU0 in the sever node 220 over an inter-node communication link 230, and the GPU device GPU3 in the server node 220 communicates with the GPU device GPU4 in the sever node 210 over an inter-node communication link 240.)
It would have been obvious to a person in the ordinary skill in the art before the filing date of the claimed invention to combine Zhao with the system of Vaikar and Archer to use a ring topology. One having ordinary skill in the art would have been motivated to use Zhao into the system of Vaikar and Archer for the purpose of provisioning computing resources in a distributed computing system (Zhao paragraph 01)
As to claim 14, it is rejected based on the same reason as claim 5.
Claims 7,8,16 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Vaikar (US 2022/0182288 A1) in view of Archer (US 2012/0185867 A1) in further view of Ferreira (US 2022/0043680 A1).
As per claim 7, Vaikar teaches receiving, by a customer, the locality information and the linkage information of the one or more host machines; (Vaikar [0067] If deployment is not possible in view of the constraints then, at 504, feedback is provided to the user (e.g., to user device 150 of FIG. 1) indicating why deployment is not possible. For example, the feedback may indicate that there are not two nodes on separate racks with a latency value between them of 10 milliseconds or less[linkage info]. The feedback may provide the user with information that may be used to revise the constraints such that deployment is possible. For example, the user may provide an updated indication of user intent in which the latency limit is raised or the rack co-location constraint is changed).
the selecting being performed based on one or more constraints associated with the workload;. (Vaikar [0018] For example, a deployment engine may be configured to parse code or parameters written in domain specific language in order to identify specific user-defined constraints. The constraints may include, for example, whether certain microservices are to be deployed on the same or different racks[ desired degree of availability], maximum latency allowed between two given microservices [latency threshold] maximum round trip time (RTT) allowed between two given microservices, and the like. The deployment engine may gather topology information and network performance information from one or more components in the network, such as from monitoring nodes on hosts, physical routers, physical switches, and/or from a manager. The topology information may indicate which machines (e.g., hosts, VCIs, and the like) are located on which racks. The network performance information may include, for example, latency and RTT values between pairs of machines, such as the current latency or RTT between two given machines. Latency and RTT are included as examples, and other types of network performance information may be gathered and used in deployment rules. For example, other types of network performance information that may be used with techniques described herein include network throughput (e.g., average data rate of successful packet delivery), bandwidth availability (e.g., how much data can be transmitted per time period), packet loss rate (e.g., the average rate over which transmitted packets are dropped), and the like. References to comparison with a threshold may refer to either an upper threshold (e.g., for network performance information that are intended to be minimized, such as latency) or a lower threshold (e.g., for network performance information that are intended to be maximized, such as throughput) [0049] In an example, the domain specific language includes keywords and/or variables that are used to define criteria for deployment. For example, a user may define a resource set including one or more services, and may specify placement criteria for the resource set using keywords such as “colocation” at the “host” level or “rack” level. In another example, the user may define a network constraint for a resource set by setting a “latency” variable (or a variable corresponding to a different type of network performance information), such as to the value of 10, such as meaning that latency between services in the resource set cannot exceed 10 milliseconds. These are included as examples, and many types of domain specific languages may be employed with techniques described herein)
Vaikar and Archer do not teach selecting, by the customer, a subset of the one or more host machines for executing the workload.
However, Ferreira teaches selecting, by the customer, a subset of the one or more host machines for executing the workload (Ferreira [0067] Turning now to FIG. 13, another example user interface for selecting system resources is shown. In this embodiment, a graphical representation 1310 of the logical topology of the application selected is shown together with a graphical representation of two different available computing resources 1340 and 1350. While two representations are presented in the example, more are possible and contemplated (e.g., accessible by scrolling). The graphical representation may be based on configuration information for each of the systems (e.g., entered by a system administrator or captured based on configuration files). The user interface permits the user to select and drag subsets of nodes (e.g., subset 1320 and subset 1330) onto one of the graphical representations of the computing resources 1340. The representation of the resources used for the selected subsets of nodes may change (e.g., change color or pattern or outline) to indicate that they have been allocated to the selected subset of nodes).
It would have been obvious to a person in the ordinary skill in the art before the filing date of the claimed invention to combine Ferreira with the system of Vaikar and Archer to select a subset of host machines. One having ordinary skill in the art would have been motivated to use Ferreira into the system of Vaikar and Archer for the purpose of efficiently creating and managing application instances in computing systems. (Ferreira paragraph 04)
As per claim 8, Vaikar teaches wherein one or more constraints includes a first constraint corresponding to a latency threshold associated with workload and a second constraint associated with a desired degree of availability in executing the workload. (Vaikar [0018] For example, a deployment engine may be configured to parse code or parameters written in domain specific language in order to identify specific user-defined constraints. The constraints may include, for example, whether certain microservices are to be deployed on the same or different racks[ desired degree of availability], maximum latency allowed between two given microservices [latency threshold] maximum round trip time (RTT) allowed between two given microservices, and the like. The deployment engine may gather topology information and network performance information from one or more components in the network, such as from monitoring nodes on hosts, physical routers, physical switches, and/or from a manager. The topology information may indicate which machines (e.g., hosts, VCIs, and the like) are located on which racks. The network performance information may include, for example, latency and RTT values between pairs of machines, such as the current latency or RTT between two given machines. Latency and RTT are included as examples, and other types of network performance information may be gathered and used in deployment rules. For example, other types of network performance information that may be used with techniques described herein include network throughput (e.g., average data rate of successful packet delivery), bandwidth availability (e.g., how much data can be transmitted per time period), packet loss rate (e.g., the average rate over which transmitted packets are dropped), and the like. References to comparison with a threshold may refer to either an upper threshold (e.g., for network performance information that are intended to be minimized, such as latency) or a lower threshold (e.g., for network performance information that are intended to be maximized, such as throughput) [0049] In an example, the domain specific language includes keywords and/or variables that are used to define criteria for deployment. For example, a user may define a resource set including one or more services, and may specify placement criteria for the resource set using keywords such as “colocation” at the “host” level or “rack” level. In another example, the user may define a network constraint for a resource set by setting a “latency” variable (or a variable corresponding to a different type of network performance information), such as to the value of 10, such as meaning that latency between services in the resource set cannot exceed 10 milliseconds. These are included as examples, and many types of domain specific languages may be employed with techniques described herein).
The examiner is interpreting this availability according to what is disclosed in the specification ([0162] Such a constraint corresponds to the customer desiring to have a certain degree of availability of the host machines i.e., at least some of the host machines selected for executing the workload need to be positioned in different racks. Such a constraint is typically incorporated by the customer to address failure of rack issues)
As to claim 16, it is rejected based on the same reason as claim 7.
As to claim 17, it is rejected based on the same reason as claim 8.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Vaikar (US 2022/0182288 A1) in view of Archer (US 2012/0185867 A1) in further view of Ferreira (US 2022/0043680 A1) and Zhao (US 2019/0312772 A1) .
As per claim 9, Vaikar and Archer and Ferreira do not teach wherein the selecting the subset of the one or more host machines is further based on the linkage information of the one or more host machines.
However, Zhao teaches wherein the selecting the subset of the one or more host machines is further based on the linkage information of the one or more host machines. (Zhao Fig 6 Block 608 and 610 and [0081] Next, the control server node will access the resource usage database 148 and evaluate the selected GPU devices (606) using current resource usage information in the resource usage database to determine an optimal communication order for the selected GPU devices (block 608). And [0083] Once the communication order is determined (in block 608), the selected GPU devices [subset] are provisioned in specified communication order to begin executing the workload associated with the service request (block 610).)
It would have been obvious to a person in the ordinary skill in the art before the filing date of the claimed invention to combine Zhao with the system of Vaikar and Archer and Ferreira to select a subset of hosts. One having ordinary skill in the art would have been motivated to use Zhao into the system of Vaikar and Archer and Ferreira for the purpose of provisioning computing resources in a distributed computing system (Zhao paragraph 01)
Response to Arguments
Applicant's arguments filed on 09/19/2025 have been fully considered but they are not persuasive.
Applicant’s arguments with respect to claims 1, 10 and 18 have been considered but are moot because the arguments do not apply because of the introduction of new art by Archer.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any 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 MEHRAN KAMRAN whose telephone number is (571)272-3401. The examiner can normally be reached on 9-5.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor April Blair, can be reached on (571)270-1014. 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.
/MEHRAN KAMRAN/Primary Examiner, Art Unit 2196