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
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 05/01/2026 has been entered.
Claims 1-20 are presented for examination.
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) in further view of Jeuk (US 2021/0409277 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)).
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)
Vaikar and Archer do not teach 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 constructing the linkage information includes creating by an application, a logical topology that interconnects each of the one or more host machines included in the available set of host machines.
However, Jeuk teaches 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 constructing the linkage information includes creating by an application, a logical topology that interconnects each of the one or more host machines included in the available set of host machines (Jeuk Fig 5 Block 507 (Generate Network Topology Model.. and [0021] The deployment system may then generate a complete network topology model based on the various portions of network topologies retrieved from the different elements of the data structure. [0031] In some examples, the topology deployment system 110 may include one or more of a model generation engine 111, a model inheritance engine 112, and/or a model deployment engine 113. The model generation engine 111 may determine formal network topology models for deployment, based on logical (or intent-based) models and other inputs such as resource inventories of the workload resource domains 120, constraint inputs provided by a system architect or administrator, and/or performance data received from deployed topologies. [0078] At 508, the combined network topology model generated at 507 may be deployed within the one or more of the workload resource domains 120. The model deployment engine 113 may perform the physical deployment of the formal model using the techniques described herein. In various examples, the deployment performed at 508 may be a deployment of a new formal model, or may be a modification of an existing deployed model [0064] In other examples, the model inheritance engine 112 may determine the subsets of nodes within the network topology model to be partitioned into different branches/elements using different criteria. In some cases, the model inheritance engine 112 may structure the model hierarchy 300 by grouping different subsets of nodes corresponding to different products or departments within an organization. In other cases, the model inheritance engine 112 may group nodes of the network topology based on the level of communications between those nodes within the deployed model. In still other cases, the model inheritance engine 112 may group nodes of the network topology by the location (e.g., geographic and/or within the computing environment 200) at which the nodes are deployed within the workload resource domains 120.)
It would have been obvious to a person in the ordinary skill in the art before the effective filing date of the claimed invention to combine Jeuk with the system of Vaikar and Archer to construct linkage information. One having ordinary skill in the art would have been motivated to use Jeuk into the system of Vaikar and Archer for the purpose of generating network topology models and deploying network topologies within workload resource domains based on the models. (Jeuk paragraph 01)
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 Jeuk (US 2021/0409277 A1) and Sirton (US 2020/0106675 A1).
As per claim 3, Vaikar and Archer and Jeuk 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 and Jeuk 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 and Jeuk 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 Jeuk (US 2021/0409277 A1) and Zhao (US 2019/0312772 A1).
As per claim 5, Vaikar and Archer and Jeuk 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 and Jeuk 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 and Jeuk 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 and 16 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 Jeuk (US 2021/0409277 A1) and 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 and Jeuk 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 and Jeuk 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 and Jeuk for the purpose of efficiently creating and managing application instances in computing systems. (Ferreira paragraph 04)
As to claim 16, it is rejected based on the same reason as claim 7.
Allowable Subject Matter
Claims 8,9 and 17 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20230315531 A1 – discloses creating a container, an electronic device, and a storage medium. The method includes: acquiring an available rack list and an available network address list, the available rack list including a plurality of available racks of different available zones, each available rack including at least one server node, the available network address list including at least one available network address; locating a spare server node in the available racks in the available rack list; creating, on the spare server node, a current container corresponding to the available network address; updating the available network address list; re-ordering the available racks in the available rack list according to resource occupation information of the available racks in the available rack list; and creating another container according to a spare server node in the re-ordered available racks in the available rack list and the updated available network address list.
US 20190306026 – discloses client-directed placement of remotely configured service instances are described. One or more placement target options are selected for a client of a network-accessible service based on criteria such as service characteristics of the placement targets. The selected options, including a particular placement target that includes instance hosts configurable from remote control servers, are indicated programmatically to the client. A determination is made that a service instance is to be configured at the particular placement target on behalf of the client. A remote control server is configured to issue administrative commands to an instance host at the particular placement target to configure the service instance.
US 20180351815 A1 – discloses provided for client-side monitoring in a cloud provider environment including a network having a plurality of nodes. The method includes estimating a logical topology of the network by clustering source-destination node pairs while excluding intermediate nodes from among the plurality of nodes based on end-to-end performance measurements between various ones of the plurality of nodes forming the source-destination node pairs. The method also includes at least one of scheduling and customizing a workload within the network, and executing the workload within the network, based on the estimated logical topology.
US 20180189101 A1 - discloses migrating a workload includes: receiving workloads generated from a plurality of applications running in a plurality of server nodes of a rack system; monitoring latency requirements for the workloads and detecting a violation of the latency requirement for a workload; collecting system utilization information of the rack system; calculating rewards for migrating the workload to other server nodes in the rack system; determining a target server node among the plurality of server nodes that maximizes the reward; and performing migration of the workload to the target server node.
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
Prosecution Insights