Prosecution Insights
Last updated: October 02, 2026
Application No. 18/635,586

METHOD AND SYSTEM FOR MANAGING WORKLOAD PLACEMENT IN DIFFERENT ENVIRONMENTS

Non-Final OA §103§112
Filed
Apr 15, 2024
Examiner
KIM, DONG U
Art Unit
Tech Center
Assignee
Dell Products L.P.
OA Round
1 (Non-Final)
87%
Grant Probability
Favorable
1-2
OA Rounds
2m
Est. Remaining
99%
With Interview

Examiner Intelligence

Grants 87% — above average
87%
Career Allowance Rate
625 granted / 722 resolved
+26.6% vs TC avg
Moderate +13% lift
Without
With
+13.4%
Interview Lift
resolved cases with interview
Typical timeline
2y 8m
Avg Prosecution
28 currently pending
Career history
748
Total Applications
across all art units

Statute-Specific Performance

§101
10.4%
-29.6% vs TC avg
§103
45.3%
+5.3% vs TC avg
§102
10.2%
-29.8% vs TC avg
§112
27.4%
-12.6% vs TC avg
Black line = Tech Center average estimate • Based on career data from 722 resolved cases

Office Action

§103 §112
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 . Claim Interpretation The following is a quotation of 35 U.S.C. 112(f): (f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof. The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph: An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof. This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: the management system is configured to execute a method, in claim(s) 10. Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof. If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. Claim Rejections - 35 USC § 112 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. Claim(s) 1-20 is/are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. The term “business requirement” in claim 1 (similarly claims 10 and 19) is a relative term which renders the claim indefinite. The term “business requirement” 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 examiner is unclear in what particular aspect of a business, the business requirement is referring to. Claim 1 (similarly claim 10) recite: “notification of the user”. The examiner is unclear if a notification is notification of the user or if it was intended to be notification to the user. The term “governance requirement” and “compliance requirement” in claim 4 (similarly claim 13) is a relative term which renders the claim indefinite. The term “governance requirement” and “compliance requirement” are 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 metes-and-bounds of the terms are not clearly defined. The term “business goal” in claim 17 is a relative term which renders the claim indefinite. The term “business goal” 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 examiner is unclear in what particular aspect of a business, the business goal is referring to. Claim 18 recite: “General Data Protection Regulation” (GDPR). This limitation is ambiguous, since there are multiple revisions to the GDPR throughout the years. The examiner is unclear what particular GDPR the GDPR is referring to. Claims 2-9, 11-18 and 20 are rejected based on rejection of its corresponding dependent claim. Claim Rejections - 35 USC § 103 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. 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. Claim(s) 1-13, 17, 19 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Espy et al. (Pat 10152357) (hereafter Espy) in view of Dippenaar et al. (Pub 20150040127) (hereafter Dippenaar). As per claim 1, Espy teaches: A method for managing workload placement, the method comprising: receiving, by an orchestrator, a workload placement request from a user via a client, wherein the workload placement request comprises at least a specification; ([Column 3 line 1-12], Such client devices may comprise, for example, mobile telephones, laptop computers, tablet computers, desktop computers or other types of devices utilized by members of an enterprise, in any combination. Such devices are examples of what are more generally referred to herein as “processing devices.” Some of these processing devices are also generally referred to herein as “computers.” [Column 2 line 66-67 – column 3 line 1-12], Although not explicitly shown in FIG. 1, one or more of applications 104 may be implemented on respective client devices coupled to network 110. [Column 4 line 62-67], The processor 112 further comprises an alignment and learning module 118 and enhanced request generation module 120. Enhanced request generation module 120 is configured to receive application requests comprising specifications for application workloads from applications 104.) invoking, by the orchestrator, an engine by sending the specification to obtain a placement rule; invoking, by the engine, a parser by sending the specification to obtain a domain-classified requirement; obtaining, upon the invoking by the engine and by the parser, a business requirement; ([Column 16 line 6-21], Policies may be obtained from various sources. Some policies may be user-defined, created by analyzing an application request, learned from other application workloads running on or previously run on the IT infrastructure 108 or one or more other infrastructures utilizing analytics module 604, etc. In some embodiments, certain policies may be obtained from external sources, or may be created by analyzing information from external sources. Examples of such external sources include Docker Compose, Cloud Foundry® and Symmetric VMAX® Fully Automated Storage Tiering (FAST). Embodiments, however, are not limited to use of these specific external sources. Various other types of external sources may be used in other embodiments. Information from external sources may be used to create new policies, or possibly to augment or modify existing policies. [Column 1 line 48-67 and Column 2 line 1-4], In one embodiment, a method comprises selecting a given hardware configuration for a given application workload based on aligning an application workload specification template with a first hardware configuration template in a first repository comprising a plurality of hardware configuration templates, wherein the application workload specification template is generated by parsing and interpreting hardware-agnostic service level objective expressions of an application request, scheduling the given application workload to run on information technology infrastructure utilizing the given hardware configuration, the given hardware configuration comprising a first set of a plurality of heterogeneous elements of the information technology infrastructure, monitoring the information technology infrastructure, and modifying the given hardware configuration for the given application workload based on aligning the application workload specification template with a second hardware configuration template in the first repository responsive to said monitoring, the modified hardware configuration comprising a second set of the plurality of heterogeneous elements of the information technology infrastructure. [Column 16 line 41-59], As an example, if an application class indicates that an application is important for a business or other entity, more resources may be devoted to monitoring that application's workloads or the thresholds used for determining a breach of an SLA or SLO may be finer grained relative to thresholds used for other applications that are considered less important. [Column 7 line 60-67 and column 8 line 1-10], HERE 102 parses and interprets the application workload requirements and any detailed manifest information, and compares this information to a learned knowledge base repository of configurations based on an existing platform catalog to determine a recommended hardware configuration. The recommended hardware configuration is combined with the original application request to form an enhanced application request sent to scheduler 106. Whereas the original application request may be abstracted SLO expressions not usable by the scheduler 106, the enhanced application request may be a finer grained declarative job statement which the scheduler 106 may use to fulfill the application request. As a result, scheduler 106 is able to utilize IT infrastructure 108 which includes heterogeneous elements 222. In some embodiments, this results in improved hardware element to application alignment and utilization while minimizing impact on scheduler 106 and catalog and telemetry functions described below.) generating, based on the business requirement and the specification, and by the parser, the domain-classified requirement, wherein the parser provides the domain-classified requirement to the engine; generating, based on the domain-classified requirement and by the engine, the placement rule, wherein the engine provides the placement rule to the orchestrator; ([Column 7 line 60-67 and column 8 line 1-10], HERE 102 parses and interprets the application workload requirements and any detailed manifest information, and compares this information to a learned knowledge base repository of configurations based on an existing platform catalog to determine a recommended hardware configuration. The recommended hardware configuration is combined with the original application request to form an enhanced application request sent to scheduler 106. Whereas the original application request may be abstracted SLO expressions not usable by the scheduler 106, the enhanced application request may be a finer grained declarative job statement which the scheduler 106 may use to fulfill the application request. As a result, scheduler 106 is able to utilize IT infrastructure 108 which includes heterogeneous elements 222. In some embodiments, this results in improved hardware element to application alignment and utilization while minimizing impact on scheduler 106 and catalog and telemetry functions described below. [Column 12 line 12-25], In other embodiments, selecting the given hardware configuration may be based on performance requirements associated with the given application workload and one or more other application workloads that utilize IT infrastructure 108. For example, the given hardware configuration for the given application workload may be selected so as to increase net productivity over multiple different application workloads. It is to be appreciated that while FIG. 5 and various embodiments are described herein with respect to generating an enhanced application request for a single application workload, embodiments are not so limited. The FIG. 5 process may be repeated so as to generate enhanced application requests for all or some subset of application requests that are directed to or otherwise utilize IT infrastructure 108. [Column 1 line 48-67], In one embodiment, a method comprises selecting a given hardware configuration for a given application workload based on aligning an application workload specification template with a first hardware configuration template in a first repository comprising a plurality of hardware configuration templates, wherein the application workload specification template is generated by parsing and interpreting hardware-agnostic service level objective expressions of an application request, scheduling the given application workload to run on information technology infrastructure utilizing the given hardware configuration… [Column 5 line 64-67 and Colum 6 line 1-5], Other processing platforms may be used to implement portions of the system 100 such as HERE 102 in other embodiments, such as different types of virtualization infrastructure in place of or in addition to virtualization infrastructure comprising virtual machines. Such virtualization infrastructure illustratively includes container-based virtualization infrastructure configured to provide Docker containers or other types of Linux containers (LXCs).) performing, based on the placement rule and by the orchestrator, the workload placement request; and ([Column 7 line 41-59], Application requests are directed to scheduler 106 from applications (not shown in FIG. 2 for clarity), and may include application workload requirements as well as an application manifest or hints relating to the application request. HERE 102 may be configured so as to receive the application request and provide an enhanced application request to the scheduler 106. [Column 17 line 46-67], The runtime monitoring provided by analytics module 604 can track the behavior of numerous application workloads, such as a large sampling of different classes of applications and their corresponding workloads…) Although Espy discloses monitoring runtime information of deployed workload (i.e. completion of workload placement request). Espy does not explicitly disclose initiating, by the orchestrator, notification of the user about a completion of the workload placement request. Dippenaar teaches initiating, by the orchestrator, notification of the user about a completion of the workload placement request.([Paragraph 67], Accordingly, the management sub-system may be configured to transmit one or more executable instructions that, when executed by the customer interface, may cause the customer interface to notify the customer that the virtual machine instance is now available for use. Accordingly, the customer may utilize the customer interface and the management sub-system to resume his or her interactions with the virtual machine instance, according to the customer's needs. [Paragraph 69], The success message may include an informative notification to the customer that the virtual machine instance currently has been allocated to a physical host computer system with the requested hardware specifications or simply that the request is successfully fulfilled.) Dippenaar also teaches workload placement request from a user; workload specification; domain-classified/business requirement; placement rule. ([Paragraph 17, 20, 24]) It would have been obvious to a person with ordinary skill in the art, before the effective filing date of the invention, to combine the teachings of Espy wherein a workload placement request and workload specification from a user is received, the workload specification is parsed to obtain domain-classified requirement (i.e. hardware specification/requirement) and business requirement, a placement rule is generated to place the workload and execute the workload, into teachings of Dippenaar wherein the user is notified of completion of the workload placement request, because this would enhance the teachings of Espy wherein by notifying the user, the user is aware the workload placement request has been completed thus, the workload is available for use based on the workload specification. As per claim 2, rejection of claim 1 is incorporated: Espy teaches wherein the specification specifies at least a resource related parameter for a resource and a workload related parameter, wherein the resource is a central processing unit (CPU), a graphics processing unit (GPU), a data processing unit (DPU), memory, or a network source. ([Column 16 line 41-59], Templates may also contain information relating to operating parameters for a hardware configuration. … [Column 11 line 32-44], For example, heterogeneous elements of the IT infrastructure 108 may include two or more different types of processors, but the hardware-agnostic SLOs of the application request received in step 500 may not specify a particular type of processor to be used for the given application workload. Different types of processors include, by way of example, processors with different central processing unit (CPU) architectures (e.g., x86, ARM, OpenPOWER, etc.) processors with different instruction set architectures (ISAs), processors with specialized function off-load capabilities, graphics processing units (GPUs) including general purpose GPUs (GPGPUs), system-on-chip (SOC) integrated circuits, field programmable gate arrays (FPGAs), etc.) Dippenaar also teaches ([Paragraph 17], In some embodiments, the virtual computer system service may receive a request from a customer for a virtual machine instance that may include a requirement or preference for hardware specifications to instantiate the instance. Accordingly, the virtual computer system service may determine whether a physical host with the requested hardware specifications is available for allocation. ) As per claim 3, rejection of claim 2 is incorporated: Dippenaar teaches wherein the resource related parameter specifies at least one selected from a group consisting of a virtual graphics processing unit (vGPU) count required to perform the workload, a type of a vGPU scheduling policy, a type of a GPU virtualization approach that needs to be implemented, a virtual central processing unit (vCPU) count required to perform the workload, and a virtual network interface card (vNIC) count required to perform the workload. ([Paragraph 54], The physical host computer system may comprise the minimum resources necessary to instantiate the instance such that a customer may still utilize the virtual machine instance for his or her purposes.) Espy also teaches ([Column 2 line 60-65], For example, the system 100 and/or IT infrastructure 108 may be a network of computing devices, a cloud computing platform, one or more data center(s), distributed virtual infrastructure, converged infrastructure, etc. [Column 8 line 30-33], For example, a compute node including processor, memory and Input/Output (I/O) elements may be considered a unit in platform 230… ) As per claim 4, rejection of claim 2 is incorporated: Espy teaches wherein the workload related parameter specifies at least one selected from a group consisting of a scalability requirement, an affinity requirement, an anti-affinity requirement, a governance requirement, and a compliance requirement. ([Column 16 line 41-59], Templates may also contain information relating to operating parameters for a hardware configuration. The operating parameters may include telemetry data that will be collected, monitored and analyzed to determine if and when one or more service level agreements (SLAs) or SLOs for an application will be breached.) Dippenaar also teaches ([Paragraph 34], The customer interface 304 may contain certain security safeguards to ensure that the customer has authorization to access the virtual computer system service 302. For instance, in order to access the virtual computer system service 302, a customer may need to provide a username and a corresponding password or encryption key when using the customer interface 304. Additionally, requests (e.g., API calls) submitted to the customer interface 304 may require an electronic signature generated using a cryptographic key such that the electronic signature is verifiable by the virtual computer system service 302, such as by an authorization system (not shown).) As per claim 5, rejection of claim 1 is incorporated: Dippenaar teaches wherein the orchestrator performs the workload placement request by placing the workload on a first physical computing device executing in a first zone, wherein the workload is a set of microservices. ([Paragraph 51], The management sub-system may be configured to add in this evaluation any physical hosts comprising virtual machine instances based on a preference for certain hardware resources and physical hosts comprising virtual machine instances generated with no preference whatsoever. For instance, if the request for a virtual machine instance with a certain set of resources is a preference, this request may be given priority over any existing instantiated instances created without any hardware preferences. Additionally, in another instance, if the request is a set requirement, this request may be given greater priority over any existing instantiated instances created without any hardware preferences or instances created with merely a hardware preference (e.g., not a set requirement). Thus, the management sub-system may determine that certain physical hosts are available to fulfill the request even though the hosts may comprise existing instantiated instances. [Paragraph 16], The entity may be a customer of a computing resource service provider that operates various services such as data storage services, virtual computer system services and/or database services. A customer may express hardware preferences in various ways, such as through a request for the creation or migration of a virtual machine instance. A requested hardware configuration may be embodied in one or more physical hosts that may be provided by the virtual computer system service. ) As per claim 6, rejection of claim 5 is incorporated: Dippenaar teaches wherein the first zone, a second zone, and a third zone form a heterogeneous environment, wherein the second zone is a cloud environment and executes a logical computing device, wherein the first zone, the second zone, and the third zone are distinct zones, and wherein the first zone is operably connected to the third zone over a network. ([Paragraph 51], The management sub-system may be configured to add in this evaluation any physical hosts comprising virtual machine instances based on a preference for certain hardware resources and physical hosts comprising virtual machine instances generated with no preference whatsoever. For instance, if the request for a virtual machine instance with a certain set of resources is a preference, this request may be given priority over any existing instantiated instances created without any hardware preferences. Additionally, in another instance, if the request is a set requirement, this request may be given greater priority over any existing instantiated instances created without any hardware preferences or instances created with merely a hardware preference (e.g., not a set requirement). Thus, the management sub-system may determine that certain physical hosts are available to fulfill the request even though the hosts may comprise existing instantiated instances. [Paragraph 52], If one or more physical host computer systems comprise the resources to satisfy the customer preferences or requirements and these physical host computer systems additionally include sufficient empty slots to instantiate the virtual machine instance, the management sub-system may allocate 706 the virtual machine instance to the empty slots in the physical host computer system. If more than one physical host computer system exists, the management sub-system may be configured to apply an algorithm in order to rank the available slots within the available physical host computer systems. For example, the management sub-system may use the algorithm to generate a ranking of available slots within the available physical host computer systems based upon the hardware specifications of each physical host computer system and the resources made available to an instance instantiated in a slot. Thus, a physical host computer system that comprises one or more available slots and precisely matches the hardware specifications provided for in the request may yield a higher ranking for the slots included therein, leading to instantiation of the virtual machine instance into a slot within this physical host computer system. However, if no slots or physical host computer systems are available to accommodate the customer preferences or requirements, the management sub-system may be configured to determine 708 if the request for a specific set of resources is either a preference or a requirement. If the customer request includes a requirement for a set of resources to support the virtual machine instance, the management sub-system may be configured to transmit executable instructions to the customer interface, that when executed by the customer interface cause the customer interface to display 710 an error message. This error message may include information regarding the unavailability of resources. Additionally, the error message may invite the customer to submit the request at a later time. Thus, the management sub-system may once again receive 702 another request from the customer and repeat the process described above. [Paragraph 25], FIG. 2 shows an illustrated example of an environment 200 in which various embodiments of the present disclosure may be practiced. In the environment 200, a computing resource service provider 202 may provide a variety of services to a customer 204. The customer 204 may be an organization that may utilize the various services provided by the computing resource service provider 202 to remotely generate, test and maintain one or more web servers or applications. As illustrated in FIG. 2, the customer 204 may communicate with the computing resource service provider 202 through one or more communications networks 206, such as the Internet. ) As per claim 7, rejection of claim 6 is incorporated: Dippenaar teaches further comprising: prior to receiving the workload placement request: monitoring, by an inventory and capability provider (ICP), the first physical computing device executing in the first zone and a second physical computing device executing in the second zone to obtain a data set, wherein the data set comprises at least hardware resource set information of the first physical computing device and a network topology relationship between the first zone and the second zone; inferring, based on the data set and by the ICP, inventory and capability information associated with each of the first physical computing device and the second physical computing device; and storing, by the ICP, a copy of the inventory and capability information in storage. ([Paragraph 51], The management sub-system may be configured to add in this evaluation any physical hosts comprising virtual machine instances based on a preference for certain hardware resources and physical hosts comprising virtual machine instances generated with no preference whatsoever. For instance, if the request for a virtual machine instance with a certain set of resources is a preference, this request may be given priority over any existing instantiated instances created without any hardware preferences. Additionally, in another instance, if the request is a set requirement, this request may be given greater priority over any existing instantiated instances created without any hardware preferences or instances created with merely a hardware preference (e.g., not a set requirement). Thus, the management sub-system may determine that certain physical hosts are available to fulfill the request even though the hosts may comprise existing instantiated instances. [Paragraph 52], If one or more physical host computer systems comprise the resources to satisfy the customer preferences or requirements and these physical host computer systems additionally include sufficient empty slots to instantiate the virtual machine instance, the management sub-system may allocate 706 the virtual machine instance to the empty slots in the physical host computer system. If more than one physical host computer system exists, the management sub-system may be configured to apply an algorithm in order to rank the available slots within the available physical host computer systems. For example, the management sub-system may use the algorithm to generate a ranking of available slots within the available physical host computer systems based upon the hardware specifications of each physical host computer system and the resources made available to an instance instantiated in a slot. Thus, a physical host computer system that comprises one or more available slots and precisely matches the hardware specifications provided for in the request may yield a higher ranking for the slots included therein, leading to instantiation of the virtual machine instance into a slot within this physical host computer system. However, if no slots or physical host computer systems are available to accommodate the customer preferences or requirements, the management sub-system may be configured to determine 708 if the request for a specific set of resources is either a preference or a requirement. If the customer request includes a requirement for a set of resources to support the virtual machine instance, the management sub-system may be configured to transmit executable instructions to the customer interface, that when executed by the customer interface cause the customer interface to display 710 an error message. This error message may include information regarding the unavailability of resources. Additionally, the error message may invite the customer to submit the request at a later time. Thus, the management sub-system may once again receive 702 another request from the customer and repeat the process described above. [Paragraph 16], Techniques described and suggested herein relate to the allocation and migration of a virtual machine instance based on a customer preference for a specific hardware configuration to instantiate and support the instance. In an embodiment, an entity (e.g., an organization) may communicate with a virtual computer system service, such as through appropriately configured application programming interface (API) calls to the service, to request the creation or migration of a virtual machine instance. The entity may be a customer of a computing resource service provider that operates various services such as data storage services, virtual computer system services and/or database services. A customer may express hardware preferences in various ways, such as through a request for the creation or migration of a virtual machine instance. A requested hardware configuration may be embodied in one or more physical hosts that may be provided by the virtual computer system service. A physical host may comprise various hardware components. For instance, the physical host may include one or more processors, one or more data storage devices (e.g., solid-state drives or magnetic disk drives), random-access memory (RAM) and other components that may be necessary to instantiate and support a virtual machine instance. In some embodiments, the virtual computer system service may configure each physical host to include a number of slots to instantiate the virtual machine instances. These slots may serve to provide a guarantee average performance for the slot for the life of the virtual machine instance by corresponding to an allocation of the various hardware resources of an underlying computer system. Accordingly, when a virtual machine instance is instantiated in a physical host, the instance may be instantiated in one or more slots based on the hardware specifications necessary to instantiate and support the virtual machine instance.) Espy also teaches ([Column 6 line 50-58], The alignment function of HERE 102 can be used to generate a hardware element and/or topology recommendation, or more generally a hardware configuration, for a requesting application and workload using a configuration knowledge base and a local element catalog, or more generally using one or more hardware configuration templates and information identifying a plurality of heterogeneous elements of IT infrastructure 108.) As per claim 8, rejection of claim 7 is incorporated: Espy teaches wherein, after obtaining the inventory and capability information from the storage, the engine converts the domain-classified requirement to the placement rule using the inventory and capability information. ([Column 6 line 58-67 and Colum 7 line 1-5], The re-alignment function of HERE 102 can be used for exception handling and improved opportunities. For example, exception handling may be used when the available or overall capacity of IT infrastructure 108 is unable to fulfill an application request at a particular time. Improved opportunity may handle situations in which better hardware options become available as an application workload is running. [Column 8 line 22-33], Platform M&O layer 224 provides telemetry 226, catalog 228 and platform 230. Telemetry 226 functions for receiving feedback from heterogeneous elements 222 including their state and related measurements. Telemetry 226 may use various monitoring tools, including active performance monitors, OnRack®, etc. Catalog 228 functions as a registry of the heterogeneous elements 222, including their capabilities and capacities. Platform 230 includes units composed from basic ones of the heterogeneous elements 222. For example, a compute node including processor, memory and Input/Output (I/O) elements may be considered a unit in platform 230.) Dippenaar also teaches ([Paragraph 62], Once the management sub-system has identified a virtual machine instance requiring migration and the necessary resources to migrate the instance, the management sub-system may be configured to identify 906 one or more target slots in a physical host computer system for allocating the virtual machine instance. As illustrated in FIG. 4, each physical host computer system may have different hardware specifications and, accordingly, varying computing capabilities. [Paragraph 20], For instance, the backlog may be used to inform system capacity planning and/or hardware purchasing decisions. Additional uses are also enabled by the various techniques described therein.) As per claim 9, rejection of claim 7 is incorporated: Espy teaches wherein the first zone is a first geographic region in the world, wherein the second zone is a second geographical region in the world. ([Column 2 line 46-65], For example, the system 100 and/or IT infrastructure 108 may be a network of computing devices, a cloud computing platform, one or more data center(s), distributed virtual infrastructure, converged infrastructure, etc.) As per claims 10-13, these are system claims corresponding to the method claims 1-4. Therefore, rejected based on similar rationale. As per claim 17, rejection of claim 13 is incorporated: Espy teaches wherein the governance requirement specifies a framework that needs to be implemented by an organization while placing the workload in order to achieve a predetermined business goal. ([Column 2 line 46-65], For example, the system 100 and/or IT infrastructure 108 may be a network of computing devices, a cloud computing platform, one or more data center(s), distributed virtual infrastructure, converged infrastructure, etc. [Column 16 line 41-59], As an example, if an application class indicates that an application is important for a business or other entity, more resources may be devoted to monitoring that application's workloads or the thresholds used for determining a breach of an SLA or SLO may be finer grained relative to thresholds used for other applications that are considered less important.) Dippenaar also teaches ([Paragraph 17], In some embodiments, the virtual computer system service may receive a request from a customer for a virtual machine instance that may include a requirement or preference for hardware specifications to instantiate the instance. Accordingly, the virtual computer system service may determine whether a physical host with the requested hardware specifications is available for allocation.) As per claims 19 and 20, these are non-transitory computer readable medium claims corresponding to the method claims 1, 2 and 4. Therefore, rejected based on similar rationale. Claim(s) 14-16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Espy in view of Dippenaar and further in view of Govindaraju el al. (Pub 20200186445) (hereafter Govind). As per claim 14, rejection of claim 12 is incorporated: Espy teaches resources that may be unavailable due to a failure. Dippenaar discloses preventing data or computing loss due to a failure. However, Espy in view of Dippenaar do not explicitly disclose wherein the scalability requirement specifies a minimum number of instances of the workload required to be implemented in order to generate at least one fault domain. Govind teaches wherein the scalability requirement specifies a minimum number of instances of the workload required to be implemented in order to generate at least one fault domain. ([Paragraph 92], By contrast, users may have significant requirements for other applications, such as communications latencies and networking bandwidths for server applications that host front-and web servers for e-commerce applications. [Paragraph 55], to replace virtual machines disabled by physical hardware problems and failures, and to ensure that multiple virtual machines supporting a high-availability virtual appliance are executing on multiple physical computer systems so that the services provided by the virtual appliance are continuously accessible, even when one of the multiple virtual appliances becomes compute bound, data-access bound, suspends execution, or fails. Thus, the virtual data center layer of abstraction provides a virtual-data-center abstraction of physical data centers to simplify provisioning, launching, and maintenance of virtual machines and virtual appliances as well as to provide high-level, distributed functionalities that involve pooling the resources of individual physical servers and migrating virtual machines among physical servers to achieve load balancing, fault tolerance, and high availability.) It would have been obvious to a person with ordinary skill in the art, before the effective filing date of the invention, to combine the teachings of Espy and Dippenaar wherein a workload placement request and workload specification from a user is received, the workload specification is parsed to obtain domain-classified requirement (i.e. hardware specification/requirement) and business requirement, a placement rule is generated to place the workload, notify completion of the workload placement request and execute the workload, into teachings of Govind wherein replacement instances of the workload are specified for fault tolerance/fail over, because this would enhance the teachings of Espy and Dippenaar wherein by providing a minimum number of instances of the workload required to be implemented (i.e. replace instances), it allows seamless failover and high availability to occur to a replacement instances for each instances of the workload which has failed to provide continuous accessibility. As per claim 15, rejection of claim 13 is incorporated: Espy and Dippenaar teaches utilizing better resources available to achieve better performance levels. However, Espy and Dippenaar do not explicitly disclose wherein the affinity requirement specifies at least a placement rule, wherein the placement rule specifies placing the workload geographically closer to a second workload to minimize latency between the workload and the second workload. Govind teaches wherein the affinity requirement specifies at least a placement rule, wherein the placement rule specifies placing the workload geographically closer to a second workload to minimize latency between the workload and the second workload. ([Paragraph 92], By contrast, users may have significant requirements for other applications, such as communications latencies and networking bandwidths for server applications that host front-and web servers for e-commerce applications. [Paragraph 93], FIGS. 24A-F illustrate processing of the application blueprint and the types of data extracted from the application blueprint by the automated application subsystem. As shown in FIG. 24A, the application blueprint is logically a hierarchical graph 2400. The root node 2402 corresponds to an application to be provisioned, installed, and configured across one or more cloud-computing-provider computing facilities. Second-level nodes 2404-2405 may represent, in the example shown in FIG. 23, geographically discrete computer facilities. Additional node levels specify virtual machines, application instances, operating systems, basic hardware support, and may include details at the level of individual virtual disks, represented by nodes 2406-2410 in the graph shown in FIG. 24A. Each node includes a specification for the corresponding computational resource and various constraints associated with the resource. The level of detail generally varies from application to application. As one example, many applications are generic with respect to operating system and processor hardware, but certain applications may be specifically developed for a particular operating system and even for a particular processor architecture. As shown in FIG. 24B, the graph also includes various types of constraints and dependency relationships between computational entities, represented as dashed lines, such as dashed line 2412 that represents an inter-resource constraint between the two network resources represented by nodes 2414-2415. This constraint may specify, for example, a maximum average latency for message transmission between the two network resources via the fastest wide-area-network interconnection between the two computer systems represented by nodes 2404 and 2405, a minimum average data-transmission capacity between the two network resources, or other such constraints and interdependencies. [Paragraph 118], FIG. 35C illustrates an implementation of the function-affinity filter (3428 in FIG. 34). The function-affinity filter receives an indication of a function to provision, ƒ, in step 3501c. In step 3502c, the function-affinity filter characterizes the operational characteristics C of the function ƒ. In step 3503c, the function-affinity filter accesses stored information to identify a set v of all possible cloud-computing vendors that can run the function ƒ. In step 3504c, the function-affinity filter calls the latency filter to generate a list wl of weights for each candidate cloud-computing vendor in the set v that reflects the desirability of the candidate cloud-computing vendor with respect to response latency. In step 3505c, the function-affinity filter calls the geo-location-constraints analyzer to similarly generate a list wg of weights reflective of the desirability of the geographical locations of the cloud-computing vendors. In step 3506c, the function-affinity filter initializes a list of weights, w. Then, in the nested for-loops of steps 3507c-3512c, the function-affinity filter calculates, for each candidate cloud-computing vendor with index i in the list v, an overall weight w[i] that is the sum of a policy-related weight, weight(v.sub.i, p), for each vendor-selection policy p and the previously determined geo-location-constraint weight wg[i] and latency weight wl[i]. In step 3513c, the list v of candidate cloud-computing vendors is sorted by overall weight, in descending order, and, in step 3514c, the highest-weighted vendors are selected as the final members of the sorted list of candidate cloud-computing vendors, which is returned to the caller along with the operational characteristics C.) It would have been obvious to a person with ordinary skill in the art, before the effective filing date of the invention, to combine the teachings of Espy and Dippenaar wherein a workload placement request and workload specification from a user is received, the workload specification is parsed to obtain domain-classified requirement (i.e. hardware specification/requirement) and business requirement, a placement rule is generated to place the workload, notify completion of the workload placement request and execute the workload, into teachings of Govind wherein workload is placed to closer to another workload to minimize latency, because this would enhance teachings of Espy and Dippenaar wherein by providing a placement rule to place workloads within close proximity, higher bandwidth, etc., it allows users who has significant requirements for latency sensitive workloads such as front-end and web servers for e-commerce, place workloads on resources which are in close proximity with high bandwidth to minimize communication latency(ies). As per claim 16, rejection of claim 13 is incorporated: Espy teaches resources that may be unavailable due to a failure. Dippenaar discloses preventing data or computing loss due to a failure. However, Espy and Dippenaar do not explicitly disclose wherein the anti-affinity requirement specifies a placement rule, wherein the placement rule specifies placing the workload geographically distant to a second workload to prevent being the workload and the second workload located in a same fault domain. Govind teaches wherein the anti-affinity requirement specifies a placement rule, wherein the placement rule specifies placing the workload geographically distant to a second workload to prevent being the workload and the second workload located in a same fault domain. ([Paragraph 62], The VCC server provides a VCC server interface that can be displayed on a local or remote terminal, PC, or other computer system 1026 to allow a cloud-aggregation administrator or other user to access VCC-server-provided aggregate-cloud distributed services. In general, the cloud-computing facilities that together form a multiple-cloud-computing aggregation through distributed services provided by the VCC server and VCC nodes are geographically and operationally distinct. [Paragraph 93], FIGS. 24A-F illustrate processing of the application blueprint and the types of data extracted from the application blueprint by the automated application subsystem. As shown in FIG. 24A, the application blueprint is logically a hierarchical graph 2400. The root node 2402 corresponds to an application to be provisioned, installed, and configured across one or more cloud-computing-provider computing facilities. Second-level nodes 2404-2405 may represent, in the example shown in FIG. 23, geographically discrete computer facilities. Additional node levels specify virtual machines, application instances, operating systems, basic hardware support, and may include details at the level of individual virtual disks, represented by nodes 2406-2410 in the graph shown in FIG. 24A. Each node includes a specification for the corresponding computational resource and various constraints associated with the resource. The level of detail generally varies from application to application. [Paragraph 55], to replace virtual machines disabled by physical hardware problems and failures, and to ensure that multiple virtual machines supporting a high-availability virtual appliance are executing on multiple physical computer systems so that the services provided by the virtual appliance are continuously accessible, even when one of the multiple virtual appliances becomes compute bound, data-access bound, suspends execution, or fails. Thus, the virtual data center layer of abstraction provides a virtual-data-center abstraction of physical data centers to simplify provisioning, launching, and maintenance of virtual machines and virtual appliances as well as to provide high-level, distributed functionalities that involve pooling the resources of individual physical servers and migrating virtual machines among physical servers to achieve load balancing, fault tolerance, and high availability.) It would have been obvious to a person with ordinary skill in the art, before the effective filing date of the invention, to combine the teachings of Espy and Dippenaar wherein a workload placement request and workload specification from a user is received, the workload specification is parsed to obtain domain-classified requirement (i.e. hardware specification/requirement) and business requirement, a placement rule is generated to place the workload, notify completion of the workload placement request and execute the workload, into teachings of Govind workloads are placed in distant locations, because this would enhance the teachings of Espy and Dippenaar, wherein by placing workloads which are geographically different, eliminates hardware failures from one location affecting workloads on a different location, ensuring fault tolerance and high availability. Claim(s) 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Espy in view of Dippenaar and further in view of Pabon et al. (Pub 20230195373) (hereafter Pabon). As per claim 18, rejection of claim 13 is incorporated: Espy teaches arrangement of network security systems, modules, notifications, alerts and other features. ([Column 19]) Dippenaar teaches utilization of security safe guards through user of passwords, encryption key, authorization/authentication systems. However, Espy and Dippenaar do not explicitly disclose wherein the compliance requirement is a rule that complies with General Data Protection Regulations. Papon teaches wherein the compliance requirement is a rule that complies with General Data Protection Regulations. ([Paragraph 219], For example, one or more data compliance services may be offered to a user to ensure that the user's datasets are managed in a way so as to adhere to the General Data Protection Regulation (‘GDPR’)… [Paragraph 326], In this example method, before the controller 502 redeploys an application from a first cluster to a second cluster based on the first cluster not providing resources specified by a resource specification for the application, the controller 502 attempts to request additional resources from the first cluster to satisfy a resource allocation of the application.) It would have been obvious to a person with ordinary skill in the art, before the effective filing date of the invention, to combine the teachings of Espy and Dippenaar wherein a workload placement request and workload specification from a user is received, the workload specification is parsed to obtain domain-classified requirement (i.e. hardware specification/requirement) and business requirement, a placement rule is generated to place the workload, notify completion of the workload placement request and execute the workload, into teachings of Papon wherein the compliance requirement complies with General Data Protection Regulations (GDPR), because this would enhance the teachings of Espy and Dippenaar wherein by adhering to the GDPR, it ensures users data are managed in a way so as to adhere to a well-known and established regulatory standard(s)/act(s). Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to DONG U KIM whose telephone number is (571)270-1313. The examiner can normally be reached 9:00am - 5:00pm. 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, Bradley Teets can be reached at 5712723338. 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. /DONG U KIM/Primary Examiner, Art Unit 2197
Read full office action

Prosecution Timeline

Apr 15, 2024
Application Filed
Aug 13, 2026
Non-Final Rejection mailed — §103, §112 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12737209
INTERRUPT CONTROL USING A GUEST OWNED BACKING PAGE
3y 8m to grant Granted Sep 15, 2026
Patent 12737211
SECURELY COMMUNICATING BETWEEN ON-PREMISES SERVICES AND CLIENTS IN AN EXTERNAL NETWORK
3y 2m to grant Granted Sep 15, 2026
Patent 12737223
CONCURRENT CONTROL FOR SHARE QUOTA FOR STRICT LIMITS IN REALTIME CHARGING
2y 10m to grant Granted Sep 15, 2026
Patent 12730663
VIRTUAL DATA LINKS
3y 4m to grant Granted Sep 08, 2026
Patent 12717609
ENFORCEMENT OF END-TO-END TRANSACTION LATENCY
2y 8m to grant Granted Aug 25, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

1-2
Expected OA Rounds
87%
Grant Probability
99%
With Interview (+13.4%)
2y 8m (~2m remaining)
Median Time to Grant
Low
PTA Risk
Based on 722 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month