DETAILED ACTION
This communication is a Final Office Action rejection on the merits. Claims 1-4 and 6-21 are currently pending and have been addressed below.
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 .
Response to Arguments
Applicant's arguments filed on 11/26/2025 (related to the 103 Rejections) have been fully considered but are moot in view of new grounds of rejection. Applicant's amendments necessitated the new ground(s) of rejection presented in this Office action. Rejection based on a newly cited reference(s) follows.
Applicant's arguments filed on 11/26/2025 (related to the 101 Rejections) have been fully considered but they are not persuasive.
Applicant states, on pages 10-13, that Applicant traverses the conclusory and general allegation that the claims recite "mere nominal recitation of generic computer components," as the claims explicitly require "processing, using one or more artificial neural networks, at least a portion of the obtained data," "migrating resources to at least one cloud storage structure," and "migrating compute resources in connection with one or more load balancing operations." The Office Action has provided no supporting evidence or explanation detailing why such particular technical requirements would be properly deemed "mere nominal recitation of generic computer components."
Further, and relatedly, Applicant questions the argument based on the allegation of "[t]he additional element of a machine learning model," as the claims clearly - and more specifically -require the express use of one or more artificial neural networks. Further still, Applicant respectfully traverses the vague allegation that the additional element of a machine learning model "is merely used to identify at least one option and/or recommendation." It is unclear exactly what the Examiner is attempting to qualify with this allegation, as the independent claims plainly and clearly require the active step of "processing, using one or more artificial neural networks in conjunction with one or more logistic regression algorithms, at least a portion of the obtained data." Applicant respectfully requests clarification on the "option and/or recommendation" rejection basis.
Lastly, because the amended independent claims expressly require "automatically training at least a portion of the one or more artificial neural networks based at least in part on feedback related to the one or more recommended tasks" (which were generated as outputs by the one or more artificial neural networks), the claims are to be properly deemed an example of claims that do not recite abstract ideas, per the above-noted MPEP rubric.
Examiner respectfully disagrees with Applicant. Claim 1 is considered to be an abstract idea because the claim elements are directed to “mental processes” which include “evaluations.” In this case, the claim recites “collecting information, analyzing it, and displaying certain results of the collection and analysis," where the data analysis steps are recited at a high level of generality such that they could practically be performed in the human mind (see MPEP 2106.04(a)). In this case, Examiner notes that the limitations of: obtaining data related to at least one decision-making …; classifying at least a portion of the obtained data into one or more of multiple categories …; and recommending one or more cloud-based infrastructure migration tasks in furtherance of the at least one decision-making context … are merely describing evaluation of data to create migration plan, which is considered a mental process. Although the claim further requires “processing using one or more artificial neural networks” and “migrating resources …,” the claimed invention is described as a concept that is performed in the human mind and applicant is merely claiming that concept performed 1) on a generic computer, or 2) in a computer environment, or 3) is merely using a computer as a tool to perform the concept. In these situations, the claim is considered to recite a mental process (see MPEP 2106.04(a), a claim that requires a computer may still recite a mental process). If a claim limitation, under its broadest reasonable interpretation, covers evaluations, then it falls within the “mental processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
The mere nominal recitation of generic computer components does not take the claim out of the “mental processes” grouping. The additional element of a machine learning model is merely used to identify at least one option and/or recommendation (e.g., the most suitable option) for migration using one or more classification algorithms (Paragraphs 0062-0063, one or more logistic regression algorithms). In this case, the machine learning model includes inputs (e.g., data related to at least one decision-making context) and outputs (e.g., at least one option and/or recommendation for migration). Although the machine learning model receives feedback over time to improve an accuracy score (Paragraph 0065), the claim and specification do not include any specific details about how the trained machine learning model operates or how the recommendations are generated, which is merely claiming the idea of a solution or outcome (see MPEP 2106.05(a)). Rather, “receiving data/feedback to improve accuracy of the machine learning” is just an inherent characteristic used to train a machine learning over time. See example 47 of July 2024 AI Subject Matter Eligibility. Therefore, the machine learning is recited at a high level of generality, which results in “apply it” (see MPEP 2106.05(f)).
Also, the additional element of “performing one or more automated actions based at least in part on the one or more recommended cloud-based infrastructure migration tasks, wherein performing one or more automated actions comprises automatically migrating resources from the at least one system to a particular cloud-based infrastructure in accordance with the one or more recommended cloud-based infrastructure migration tasks, wherein automatically migrating resources comprises migrating resources to at least one cloud storage structure and migrating compute resources in connection with one or more load balancing operations” does not provide a specific application of machine learning to a particular technological field (see MPEP 2106.05(f)). For example, the function of migrating resources to balance computational resources is considered a “well-known” function in the art (see MPEP 2106.05(d)). Further, the step of "automatically training at least a portion of the one or more artificial neural networks based at least in part on feedback related to the one or more recommended tasks" is considered a well-understood, routing, and conventional function since it’s just “performing repetitive calculations” (MPEP 2106.05(d)).
Lastly, the claim fails to recite any improvements to another technology or technical field, improvements to the functioning of the computer itself, use of a particular machine, effecting a transformation or reduction of a particular article to a different state or thing, adding unconventional steps that confine the claim to a particular useful application, and/or meaningful limitations beyond generally linking the use of an abstract idea to a particular environment. See 84 Fed. Reg. 55. Viewed individually or as a whole, these additional claim element(s) do not provide meaningful limitation(s) to transform the abstract idea into a patent eligible application of the abstract idea such that the claim(s) amounts to significantly more than the abstract idea itself. Thus, the claim is ineligible.
Independent claims 13 and 17 recite similar features and therefore are rejected for the same reasons as independent claim 1. Claims 2-4, 6-12, 14-16, and 18-21 are rejected for having the same deficiencies as those set forth with respect to the claims that they depend from, independent claims 1, 13, and 17.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-4 and 6-21 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., an abstract idea) without reciting significantly more.
Independent Claim 1
Step One - First, pursuant to step 1 in the January 2019 Revised Patent Subject Matter Eligibility Guidance (“2019 PEG”) on 84 Fed. Reg. 53, the claim 1 is directed to a method which is a statutory category.
Step 2A, Prong One - Claim 1 recites: A implemented method comprising: obtaining data related to at least one decision-making context in connection with at least one system, wherein the data comprises data related to hardware configurations of the at least one system, data related to software configurations of the at least one system, data related to network parameters, associated with the at least one system, and comprising hit rate data and disaster recovery data, data pertaining to one or more cluster-specific redundancy amounts, data pertaining to one or more concurrent computational requests associated with the at least one system, and data related to storage infrastructure associated with the at least one system; classifying at least a portion of the obtained data into one or more of multiple categories of action-related requirements associated with the at least one decision-making context, wherein classifying at least a portion of the obtained data comprises classifying the at least a portion of the obtained data into one or more of multiple categories pertaining to usage-related parameters associated with the at least one decision-making context and one or more of multiple categories pertaining to cloud-based infrastructure requirements associated with the at least one decision-making context; recommending one or more migration tasks in furtherance of the at least one decision-making context by processing at least a portion of the classified data, wherein recommending one or more migration tasks comprises processing at least a portion of the obtained data classified into the one or more of multiple categories pertaining to usage-related parameters and at least a portion of the obtained data classified into the one or more of multiple categories pertaining to requirements; and automatically training based at least in part on feedback related to the one or more recommended tasks. These claim elements are considered to be abstract ideas because they are directed to “mental processes” which include “evaluations.” In this case, the claim recites “collecting information, analyzing it, and displaying certain results of the collection and analysis," where the data analysis steps are recited at a high level of generality such that they could practically be performed in the human mind (see MPEP 2106.04(a)). If a claim limitation, under its broadest reasonable interpretation, covers evaluations, then it falls within the “mental processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Step 2A Prong 2 - The judicial exception is not integrated into a practical application. Claim 1 includes additional elements: a computer; machine learning techniques; one or more artificial neural networks in conjunction with one or more logistic regression algorithms; a cloud-based infrastructure; performing one or more automated actions … automatically migrating resources from the at least one system to a particular cloud-based infrastructure in accordance with the one or more recommended cloud-based infrastructure migration tasks, ...; and wherein the method is performed by at least one processing device comprising a processor coupled to a memory.
The computer and processor are merely used to execute instructions (Paragraph 0030). The memory is merely used to store instructions (Paragraph 0030). The machine learning model is merely used to identify at least one option and/or recommendation (e.g., the most suitable option) for migration using one or more classification algorithms (Paragraphs 0062-0063, one or more logistic regression algorithms). The cloud-based infrastructure is merely a combination of physical and virtual processing resources that are utilized to implement at least a portion of the information processing system (Paragraph 0083). Merely stating that the step is performed by a computer component results in “apply it” on a computer (MPEP 2106.05f). These elements of “computer,” “processor,” “memory,” “machine learning in conjunction with one or more logistic regression algorithms,” and “cloud-based infrastructure” are recited at a high level of generality such that it amounts no more than mere instructions to apply the exception using a generic computer element. Accordingly, alone and in combination, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. Therefore, the claim is directed to an abstract idea.
Step 2B - The claim does not include additional elements that are sufficient to amount significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the claims describe how to generally “apply” the concept of generating recommendations based on data related to at least one decision-making context. The specification shows that the computer and processor are merely used to execute instructions (Paragraph 0030). The memory is merely used to store instructions (Paragraph 0030). The machine learning model is merely used to identify at least one option and/or recommendation (e.g., the most suitable option) for migration using one or more classification algorithms (Paragraphs 0062-0063, one or more logistic regression algorithms). The cloud-based infrastructure is merely a combination of physical and virtual processing resources that are utilized to implement at least a portion of the information processing system (Paragraph 0083). Also, Examiner notes that the claim does not provide any details about how the machine learning operates or how the recommendations are generated (see MPEP 2106.05(a) & 2024 AI Guidance, Example 47). Lastly, the additional element of “performing one or more automated actions … automatically migrating resources from the at least one system to a particular cloud-based infrastructure in accordance with the one or more recommended cloud-based infrastructure migration tasks, ...” does not provide a specific application of machine learning to a particular technological field (see MPEP 2106.05(f)). For example, the function of migrating resources to balance computational resources is considered a “well-known” function in the art (see MPEP 2106.05(d)). Lastly, the step of "automatically training at least a portion of the one or more artificial neural networks based at least in part on feedback related to the one or more recommended tasks" is considered a well-understood, routing, and conventional function since it’s just “performing repetitive calculations” (MPEP 2106.05(d)). Thus, nothing in the claim adds significantly more to the abstract idea. The claim is ineligible.
Independent claim 13 is directed to an article of manufacture at step 1, which is a statutory category. Claim 13 recites similar limitations as claim 1 and is rejected for the same reasons at step 2a, prong one; step 2a, prong 2; and step 2b. Claim 13 further recites: a non-transitory processor-readable storage medium. The non-transitory processor-readable storage medium is merely used to store instructions and is treated under MPEP 2106.05f in the same manner as claim 1. Accordingly, this additional element of “non-transitory processor-readable storage medium” is viewed as “apply it on a computer” at step 2a, prong 2 and step 2b. Therefore, the claim is ineligible.
Independent claim 17 is directed to an apparatus at step 1, which is a statutory category. Claim 17 recites similar limitations as claim 1 and claim 13 and is rejected for the same reasons at step 2a, prong one; step 2a, prong 2; and step 2b. Therefore, the claim is ineligible.
Dependent claims 2, 6-12, 14, and 18 are not directed to any additional claim elements. Rather, these claims offer further descriptive limitations of the abstract idea mentioned above - such as: steps of how the data is classified into one or more categories; how the domain-related repository pertaining to the at least one decision-making context is built; and wherein the at least one decision-making context comprises at least one information technology deployment-related decision- making context. These processes are similar to the abstract idea noted in the independent claim because they further the limitations of the independent claim which are directed to “mental processes” which include “evaluations.” In addition, there are no additional elements to consider at Step 2A Prong 2 and Step 2B. Therefore, the claims still recite an abstract idea that can be grouped into mental processes.
Dependent claims 3-4, 15-16, and 19-21 are not directed to any additional claim elements. Rather, these claims offer further descriptive limitations of elements found in the independent claims and addressed above - such as by: wherein performing one or more automated actions comprises automatically initiating at least one of the one or more recommended tasks; wherein performing one or more automated actions comprises automatically outputting information pertaining to the one or more recommended tasks to one or more domain experts associated with the at least one system and the at least one decision-making context; and wherein recommending one or more tasks in furtherance of the at least one decision-making context comprises recommending one or more tasks related to virtual infrastructure. In this case, the automatic action is considered “field of use” (MPEP 2106.05h) at step 2A, Prong 2; as it’s just used to provide/output information pertaining to the one or more recommended tasks, but the technology is not improved. At Step 2B, this is conventional still, receiving or transmitting data over a network (MPEP 2106.05d). Thus, nothing in the claim adds significantly more to the abstract idea. The claim is ineligible.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-4, 6-8, and 10-21 are rejected under 35 U.S.C. 103 as being unpatentable over Lange et al. (US 2022/0229707 A1), in view of Guha (US 2021/0349749 A1), in further view of Sheshadi et al. (US 2022/0383324 A1) and Shrestha et al. (US 2024/0195687 A1).
Regarding claim 1 (Currently Amended), Lange et al. discloses a computer-implemented method comprising (Abstract, Examples described herein relate to a management node and a method for managing migration of workload resources):
obtaining data related to at least one decision-making context in connection with at least one system, wherein the data comprises data related to hardware configurations of the at least one system, data related to software configurations of the at least one system, data related to network parameters, associated with the at least one system, and comprising [performance such as usage/utilization and storage needs] data, data pertaining to one or more cluster-specific redundancy …, …, and data related to storage infrastructure associated with the at least one system (Paragraph 0012, In some instances, the management node may deploy one or more replicas of the workload resources on several member nodes to enable high availability of the workload resources; Paragraph 0016, Furthermore, in some instances, the workload resources may have different resource utilizations based on the types of workloads running thereon. For example, a workload resource running CPU and memory workloads (e.g., machine learning (ML), integer, floating point operations) may utilize more compute power, whereas another workload resource running storage-centric database workloads (e.g., SQL server, SAP HANA) may utilize more storage from a respective member node. In some instances, a performance of a given workload may be adversely impacted if a workload resource running the given workload is placed on hardware that is not tuned or optimized for a given workload type. In such case, to achieve the customer's Service Level Agreement (SLA) requirements, additional compute and storage may be provisioned to the workload resource, thereby increasing the overall hardware cost, which, in turn, may increase the capital expenditure of in the networked systemParagraph 0026, In FIG. 1, although the networked system 100 is shown to include three member nodes 102-106, the networked system 100 may include any number of member nodes, without limiting the scope of the present disclosure. The member nodes 102-106 may have similar or varying hardware and/or software configurations in a given implementation of the networked system 100. By way of example, while some member nodes may have high-performance compute capabilities, some member nodes may facilitate strong data security, some member nodes may facilitate low-latency data read and/or write operations, certain member nodes may have enhanced thermal capabilities, some member nodes may be good at handling database operations, or some member nodes may be good at handling graphics processing operations; Paragraph 0027, The member nodes 102-106 may facilitate resources, for example, compute, storage, and/or networking capabilities, for one or more workload resources to execute thereon. The term workload resource may refer to a computing resource including, but not limited to, an application (e.g., software program), a virtual machine (VM), a container, a pod, a database, a data store, a logical disk, or a containerized application. As will be understood, a workload resource such as a VM include an instance of an operating system hosted on a given member node via a VM host program such as a hypervisor. Further, a workload resource such as a container may be an application packaged with its dependencies (e.g., operating system resources, processing allocations, memory allocations, etc.) hosted on a given member node via a container host program such as a container runtime (e.g., Docker Engine), for example; Paragraph 0036, The management node 108 may obtain the platform capability data (e.g., platform capability labels and respective settings) for each of member nodes 102-106 and the performance data corresponding to the workload resources (e.g., one or more of the workload resources WLR1-WLR6) from the respective member nodes 102-106);
classifying at least a portion of the obtained data into one or more of multiple categories of action-related requirements associated with the at least one decision-making context, wherein classifying at least a portion of the obtained data comprises classifying the at least a portion of the obtained data into one or more of multiple categories pertaining to cloud-based infrastructure usage-related parameters associated with the at least one decision-making context and one or more of multiple categories pertaining to cloud-based infrastructure requirements associated with the at least one decision-making context (Paragraph 0013, The scheduling (e.g., deployment) and/or migration of the workload resources may be managed to address the need for rapid deployment of services, at cloud scale, keeping in mind factors like agility, ease of application upgrades or rollbacks and cloud-native workload resources; Paragraph 0052, Moreover, in some examples, the processing resource 118 may execute one or more of the instructions 122 to determine a temporal usage pattern classification of each workload resource of the workload resource WLR1-WLR6. In some examples, the processing resource 118 may execute one or more machine learning (ML) models, for example, a usage pattern classification ML model 133 (labeled as UPC MLM 133 in FIG. 1), stored in the machine-readable medium 120 to determine the temporal usage pattern classification of each of the workload resources (WLR1-WLR2). Examples of the temporal usage classifications may include, but are not limited to, a periodic pattern, a seasonal pattern, a maintenance pattern, or an unpredictable operation. The usage pattern classification ML model 133 may include any or combinations of a Random Forest classifier, Adaptive Boosting (Ada Boost) algorithm, or K Nearest Neighbor (KNN) classifier. The processing resource 118 may train the usage pattern classification ML model 133 using a training datasets that emulate workloads that demonstrate one or more of a periodic pattern, a seasonal pattern, a maintenance pattern, or an unpredictable operation. By using the training datasets of such known workloads to train the usage pattern classification ML model 133, the usage pattern classification ML model 133 may learn such characteristics which is then used to determine the temporal usage pattern classification of workload resources running on the member nodes 102-106; Paragraph 0056, Further, in some examples, the processing resource 118 may execute one or more of the instructions 122 to determine a migration plan for a candidate workload resource of the workload resources based on the capability tag of each of the plurality of member nodes 102-106, the resource requirement classification and the temporal usage pattern classification of each workload resource hosted on the member nodes 102-106. Determination of the migration plan, in some examples, may include identifying the candidate workload resource, the target member node to which the candidate workload resource is to be migrated, and a time-schedule during which the migration of the candidate workload resource may be initiated);
recommending one or more cloud-based infrastructure migration tasks in furtherance of the at least one decision-making context by processing at least a portion of the classified data using one or more machine learning techniques, wherein recommending one or more cloud-based infrastructure migration tasks comprises processing, using one or more artificial neural networks in conjunction with one or more [k-nearest neighbors algorithms], at least a portion of the obtained data classified into the one or more of multiple categories pertaining to cloud-based infrastructure usage-related parameters and at least a portion of the obtained data classified into the one or more of multiple categories pertaining to cloud-based infrastructure requirements (Paragraph 0013, The scheduling (e.g., deployment) and/or migration of the workload resources may be managed to address the need for rapid deployment of services, at cloud scale, keeping in mind factors like agility, ease of application upgrades or rollbacks and cloud-native workload resources; Paragraph 0052, Moreover, in some examples, the processing resource 118 may execute one or more of the instructions 122 to determine a temporal usage pattern classification of each workload resource of the workload resource WLR1-WLR6. In some examples, the processing resource 118 may execute one or more machine learning (ML) models, for example, a usage pattern classification ML model 133 (labeled as UPC MLM 133 in FIG. 1), stored in the machine-readable medium 120 to determine the temporal usage pattern classification of each of the workload resources (WLR1-WLR2). Examples of the temporal usage classifications may include, but are not limited to, a periodic pattern, a seasonal pattern, a maintenance pattern, or an unpredictable operation. The usage pattern classification ML model 133 may include any or combinations of a Random Forest classifier, Adaptive Boosting (Ada Boost) algorithm, or K Nearest Neighbor (KNN) classifier. The processing resource 118 may train the usage pattern classification ML model 133 using a training datasets that emulate workloads that demonstrate one or more of a periodic pattern, a seasonal pattern, a maintenance pattern, or an unpredictable operation. By using the training datasets of such known workloads to train the usage pattern classification ML model 133, the usage pattern classification ML model 133 may learn such characteristics which is then used to determine the temporal usage pattern classification of workload resources running on the member nodes 102-106; Paragraph 0056, Further, in some examples, the processing resource 118 may execute one or more of the instructions 122 to determine a migration plan for a candidate workload resource of the workload resources based on the capability tag of each of the plurality of member nodes 102-106, the resource requirement classification and the temporal usage pattern classification of each workload resource hosted on the member nodes 102-106. Determination of the migration plan, in some examples, may include identifying the candidate workload resource, the target member node to which the candidate workload resource is to be migrated, and a time-schedule during which the migration of the candidate workload resource may be initiated);
and performing one or more automated actions based at least in part on the one or more recommended cloud-based infrastructure migration tasks, wherein performing one or more automated actions comprises automatically migrating resources from the at least one system to a particular cloud-based infrastructure in accordance with the one or more recommended cloud-based infrastructure migration tasks, wherein automatically migrating resources comprises migrating resources to at least one cloud storage structure and migrating compute resources in connection with one or more load balancing operations (Paragraph 0013, The scheduling (e.g., deployment) and/or migration of the workload resources may be managed to address the need for rapid deployment of services, at cloud scale, keeping in mind factors like agility, ease of application upgrades or rollbacks and cloud-native workload resources; Paragraph 0056, Further, in some examples, the processing resource 118 may execute one or more of the instructions 122 to determine a migration plan for a candidate workload resource of the workload resources based on the capability tag of each of the plurality of member nodes 102-106, the resource requirement classification and the temporal usage pattern classification of each workload resource hosted on the member nodes 102-106. Determination of the migration plan, in some examples, may include identifying the candidate workload resource, the target member node to which the candidate workload resource is to be migrated, and a time-schedule during which the migration of the candidate workload resource may be initiated; Paragraph 0063, Once the migration plan is determined, the processing resource 118 may execute one or more of the instructions 122 to migrate the candidate workload resource(s) as per the determined migration plan. In some examples, the candidate workload resource(s) may be migrated to the respective target node(s) without application data being lost by using a persistent storage. In some examples, migration of the candidate workload resource(s) may include configuring and deploying the candidate workload resource(s) on the identified target member nodes as recommended in the migration plan data 136. Once the candidate workload resource(s) are deployed on the identified target member nodes, the candidate workload resource(s) are operationalized on the target member nodes);
and … training at least a portion of the one or more artificial neural networks based at least in part on [training datasets] … (Paragraph 0052, The processing resource 118 may train the usage pattern classification ML model 133 using a training datasets that emulate workloads that demonstrate one or more of a periodic pattern, a seasonal pattern, a maintenance pattern, or an unpredictable operation. By using the training datasets of such known workloads to train the usage pattern classification ML model 133, the usage pattern classification ML model 133 may learn such characteristics which is then used to determine the temporal usage pattern classification of workload resources running on the member nodes 102-106);
wherein the method is performed by at least one processing device comprising a processor coupled to a memory (Paragraph 0068, The method 300 may include method blocks 302, 304, 306, and 308 (hereinafter collectively referred to as blocks 302-308) which may be performed by a processor-based system such as, for example, the management node 108. In particular, operations at each of the method blocks 302-308 may be performed by the processing resource 118 by executing the instructions 122 stored in the machine-readable medium 120 (see FIG. 1)).
Although Lange et al. discloses recommending one or more cloud-based infrastructure migration tasks based on data related to at least one decision-making context (e.g., usage/utilization patterns for different SW and HW configurations, storage needs, etc.), Lange et al. does not specifically wherein the data related to the at least one decision-making context further includes hit rate data & disaster recovery data.
However, Guha discloses comprising hit rate data and disaster recovery data, data pertaining to one or more cluster-specific redundancy …, data pertaining to one or more concurrent computational requests associated with the at least one system (Paragraph 0006, Unfortunately, reactively migrating VM virtual storage can result in performance problems. For example, the new storage system to which the VM has been migrated may not be the best choice. This is a limitation of the VM manager enforcing the SLAs for VMs since it does not have visibility into the detailed performance capabilities of the storage system. The storage system in many cases can make better decisions since it has in-depth knowledge of the physical storage attributes including availability or redundancy, compression, performance, encryption, and storage capacity. However, the physical storage system that contains the VM virtual storage does not always have visibility into the application workload's performance requirements. The combination of the limitations faced by the VM manager and storage systems increases the difficulty of dynamically provisioning VM storage in virtualized data centers; Paragraph 0064, The basis for determining whether a VM 108 can be satisfied by an LSV 102 is determined by the service level objectives (SLOs) of the VM 108, that includes specifications or limits or thresholds on performance, availability, compression, security, etc. An example of a performance SLO could be latency less than 1 ms. An SLO on availability might include recovery time objective (RTO) or time it takes to recover from a data loss event and how long it takes to return to service; Paragraph 0225, Cache hit rate (CHR) for a given workload is estimated by observing the completion times of IOs for the workload. Whenever a random IO completes less than typical disk times (<0 (ms)), then it is expected to be from a cache hit, otherwise it is from a disk. If the CHR is consistent, it can be used to get a better weighted estimate of the IO service time; Paragraph 0238, IOs are submitted to the SDS 100 from the ordered set as soon as the schedule for submission is completed. It is assumed that the SDS 100 can execute then in any order or concurrently).
It would have been obvious to one ordinary skill in the art before the effective filing date to modify the method for recommending one or more cloud-based infrastructure migration tasks based on data related to at least one decision-making context (e.g., usage/utilization patterns for different SW and HW configurations, requirements, performance, etc.) of the invention of Lange et al. to further incorporate hit rate and disaster recovery data of the invention of Guha because doing so would allow the method to make better migration decisions based on performance requirements such as recovery time objective and cache hit (see Guha, Paragraphs 0006 & 0064). Further, the claimed invention is merely a combination of old elements, and in combination each element would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Although the combination of Lange et al. and Guha discloses data pertaining to one or more cluster-specific redundancy (see Lange et al., one or more replicas of resources to enable high availability of workload resources; Guha, Paragraph 0006, physical storage attributes including availability or redundancy), the combination of Lange et al. and Guha does not specifically disclose wherein the data pertaining to one or more cluster-specific redundancy includes redundancy amounts.
However, Sheshadi et al. discloses data pertaining to one or more cluster-specific redundancy amounts, data pertaining to one or more concurrent computational requests associated with the at least one system (Paragraph 0049, These ML models may therefore predict future resource usage (e.g., a CPU usage rate or percentage, as well as similar usages and/or required allocation for latency, TPM, container count, and other requirements of compute pools and other machines). Such recommendations may be for rising and falling flux in future predicted resource usage, which may include a predicted max TPM, a buffer of extra resources, a threshold or baseline amount of resources that may always be allocated, and/or an architectural buffer based on rising, flux or peak, and falling predicted usages; Paragraph 0050, Reactive sizing 204 may receive a prediction of future resource usage from ML components 208, and may utilize the prediction to allocate server and computing resources at one or more future times based on the available resources of the service provider's platform and/or system at the future time(s). Reactive sizing 204, based on predictive outputs by ML components 208, may perform reactive sizing and allocation of server and computing resources, such as machines and pools of machines for pool 218, based on a future window (e.g., periodically and/or continuously in 30-minute forward windows). Further, the reactive sizing may include scaling zones, such as climbing, peak, and descending zones for resource usage and demand, and consider scale down lag for sizing and allocation of resources based on usage and demand. Reactive sizing 204 may perform monitoring after allocation. Monitoring by reactive sizing 204 may include alert dynamic sizing for hierarchical alerts on CPU and latency, such as monitoring CPU usage when between 70-110% capacity. Reserve sizing 206 may also establish a reserve of additional server and/or computing resources that may be provided to demand systems in response to data processing requests and the like. The reserved or extra capacity may be associated with unused capacity and may be reserved for required overages from demand and resource usage, or provided for other computational tasks and requirements of the service provider's computing platform and/or system. For example, reserve sizing 206 may provide a strategy to size one or more compute pools up to a peak and size down to a valley, such as by combining information from alerts, recommendations, and raw TPM at certain time intervals (e.g., 15 minutes). In some embodiments, a baseline threshold or amount of resources may always be allocated to prevent reactive sizing 204 from allocating too little or no resources based on a ML prediction of future resource usage; Examiner interprets “buffer and/or reserve” as the “specific redundancy amounts”).
It would have been obvious to one ordinary skill in the art before the effective filing date to modify the method for recommending one or more cloud-based infrastructure migration tasks based on data related to at least one decision-making context (e.g., usage/utilization patterns for different SW and HW configurations, requirements, performance, etc.) of the invention of Lange et al. to further incorporate data pertaining to one or more cluster-specific redundancy amounts of the invention of Sheshadi et al. because doing so would allow the method to allocate an amount of resources to prevent reactive sizing (see Sheshadi et al., Paragraph 0050). Further, the claimed invention is merely a combination of old elements, and in combination each element would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Lange et al. discloses recommending, using one or more classification algorithms such as a k-nearest neighbor, one or more cloud-based infrastructure migration tasks. Although Lange et al. discloses all the limitations above and one or more classification algorithms, the combination of Lange et al., Guha, and Sheshadi et al. does not specifically disclose wherein the classification algorithm is a logistic regression algorithm.
However, Shrestha et al. discloses wherein recommending one or more cloud- based infrastructure migration tasks comprises processing, using one or more artificial neural networks in conjunction with one or more logistic regression algorithms (Paragraph 0090, In some embodiments, a given pretrained predictive model may include a classifier or a regression model that was trained using: a support vector machine technique, a classification and regression tree technique, least-squares regression, logistic regression, another regression technique, lasso logistic regression, LASSO, logistic linear regression, a neural network technique (such as a convolutional neural network technique, a generative adversarial network or another type of neural network technique) and/or another linear or nonlinear supervised-learning technique; Paragraph 0110; Paragraph 0156, Note that the network problem may be detected (operation 1012) using a pretrained model, such as a machine-learning model or a neural network. When detecting the network problem (operation 1012), the information may be input to the pretrained model and information specifying the network problem may be output from the pretrained model. Alternatively, or additionally, the remedial action may be determined (operation 1016) using a rule engine, a look-up table or a second pretrained model, such as a machine-learning model or a neural network. When determining the remedial action (operation 1016), the information specifying the network problem may be used as an input and the remedial action may be an output from the rule engine, the look-up table or the second pretrained model; Paragraph 0160, Note that the remedial action or the second remedial action may include a configuration change in the network), …
and automatically training at least a portion of the one or more artificial neural networks based at least in part on feedback related to the one or more recommended tasks (Paragraph 0065, By automatically determining and performing the remedial action when possible and, when it is not possible to determine the remedial action, by dynamically collecting additional data, diagnosing the network problem, computing the second remedial action, and receiving approval for the second remedial action, these monitoring techniques may provide automated feedback and continuous learning for the network. These capabilities may allow a relationship between a potential cause (e.g., a configuration) and an effect (e.g., the network problem) to be determined. These capabilities may facilitate accurate anomaly detection (e.g., with reduced false positives or false alarms) and appropriate corrective action (such as the remedial action or the second remedial action) to address the network problem, such as a component failure or communication-performance degradation in the network; Paragraph 0084, Moreover, computer system 104 may determine a recommended configuration change for the network based at least in part on the detected network problem, where the recommended configuration change is predicted to improve communication performance of the network in at least a portion of the network. Note that the recommended configuration change may be determined using the same or a different pretrained model, such as a machine-learning model or a neural network; Paragraph 0137, Furthermore, during the monitoring techniques, the recommendation knowledgebase may be built from or using: domain expertise: machine learning of current and historical communication-performance metrics and recommendations. Additionally, during the monitoring techniques, the recommendation knowledge graph may be optimized using continuous learning of dynamic and static factors: and/or communication-performance metrics and key performance indicators before and after a recommendation was applied).
It would have been obvious to one ordinary skill in the art before the effective filing date to modify the method for recommending one or more cloud-based infrastructure migration tasks based on data related to at least one decision-making context (e.g., by using one or more classification algorithms such as a k-nearest neighbor) of the invention of Lange et al. to further incorporate other classification algorithms and feedback related to the one or more recommended tasks of the invention of Shrestha et al. because doing so would allow the method to optimize recommendations by receiving continuous learning (see Shrestha et al., Paragraph 0137). Further, the claimed invention is merely a combination of old elements, and in combination each element would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Regarding claim 13 (Currently Amended), Lange et al. discloses a non-transitory processor-readable storage medium having stored therein program code of one or more software programs, wherein the program code when executed by at least one processing device causes the at least one processing device (Paragraph 0068, The method 300 may include method blocks 302, 304, 306, and 308 (hereinafter collectively referred to as blocks 302-308) which may be performed by a processor-based system such as, for example, the management node 108. In particular, operations at each of the method blocks 302-308 may be performed by the processing resource 118 by executing the instructions 122 stored in the machine-readable medium 120 (see FIG. 1)):
to obtain data related to at least one decision-making context in connection with at least one system, wherein the data comprises data related to hardware configurations of the at least one system, data related to software configurations of the at least one system, data related to network parameters, associated with the at least one system, and comprising [performance such as usage/utilization and storage needs] data, data pertaining to one or more cluster-specific redundancy …, …, and data related to storage infrastructure associated with the at least one system (Paragraph 0012, In some instances, the management node may deploy one or more replicas of the workload resources on several member nodes to enable high availability of the workload resources; Paragraph 0016, Furthermore, in some instances, the workload resources may have different resource utilizations based on the types of workloads running thereon. For example, a workload resource running CPU and memory workloads (e.g., machine learning (ML), integer, floating point operations) may utilize more compute power, whereas another workload resource running storage-centric database workloads (e.g., SQL server, SAP HANA) may utilize more storage from a respective member node. In some instances, a performance of a given workload may be adversely impacted if a workload resource running the given workload is placed on hardware that is not tuned or optimized for a given workload type. In such case, to achieve the customer's Service Level Agreement (SLA) requirements, additional compute and storage may be provisioned to the workload resource, thereby increasing the overall hardware cost, which, in turn, may increase the capital expenditure of in the networked systemParagraph 0026, In FIG. 1, although the networked system 100 is shown to include three member nodes 102-106, the networked system 100 may include any number of member nodes, without limiting the scope of the present disclosure. The member nodes 102-106 may have similar or varying hardware and/or software configurations in a given implementation of the networked system 100. By way of example, while some member nodes may have high-performance compute capabilities, some member nodes may facilitate strong data security, some member nodes may facilitate low-latency data read and/or write operations, certain member nodes may have enhanced thermal capabilities, some member nodes may be good at handling database operations, or some member nodes may be good at handling graphics processing operations; Paragraph 0027, The member nodes 102-106 may facilitate resources, for example, compute, storage, and/or networking capabilities, for one or more workload resources to execute thereon. The term workload resource may refer to a computing resource including, but not limited to, an application (e.g., software program), a virtual machine (VM), a container, a pod, a database, a data store, a logical disk, or a containerized application. As will be understood, a workload resource such as a VM include an instance of an operating system hosted on a given member node via a VM host program such as a hypervisor. Further, a workload resource such as a container may be an application packaged with its dependencies (e.g., operating system resources, processing allocations, memory allocations, etc.) hosted on a given member node via a container host program such as a container runtime (e.g., Docker Engine), for example; Paragraph 0036, The management node 108 may obtain the platform capability data (e.g., platform capability labels and respective settings) for each of member nodes 102-106 and the performance data corresponding to the workload resources (e.g., one or more of the workload resources WLR1-WLR6) from the respective member nodes 102-106);
to classify at least a portion of the obtained data into one or more of multiple categories of action-related requirements associated with the at least one decision-making context, wherein classifying at least a portion of the obtained data comprises classifying the at least a portion of the obtained data into one or more of multiple categories pertaining to cloud-based infrastructure usage-related parameters associated with the at least one decision-making context and one or more of multiple categories pertaining to cloud-based infrastructure requirements associated with the at least one decision-making context (Paragraph 0013, he scheduling (e.g., deployment) and/or migration of the workload resources may be managed to address the need for rapid deployment of services, at cloud scale, keeping in mind factors like agility, ease of application upgrades or rollbacks and cloud-native workload resources; Paragraph 0052, Moreover, in some examples, the processing resource 118 may execute one or more of the instructions 122 to determine a temporal usage pattern classification of each workload resource of the workload resource WLR1-WLR6. In some examples, the processing resource 118 may execute one or more machine learning (ML) models, for example, a usage pattern classification ML model 133 (labeled as UPC MLM 133 in FIG. 1), stored in the machine-readable medium 120 to determine the temporal usage pattern classification of each of the workload resources (WLR1-WLR2). Examples of the temporal usage classifications may include, but are not limited to, a periodic pattern, a seasonal pattern, a maintenance pattern, or an unpredictable operation. The usage pattern classification ML model 133 may include any or combinations of a Random Forest classifier, Adaptive Boosting (Ada Boost) algorithm, or K Nearest Neighbor (KNN) classifier. The processing resource 118 may train the usage pattern classification ML model 133 using a training datasets that emulate workloads that demonstrate one or more of a periodic pattern, a seasonal pattern, a maintenance pattern, or an unpredictable operation. By using the training datasets of such known workloads to train the usage pattern classification ML model 133, the usage pattern classification ML model 133 may learn such characteristics which is then used to determine the temporal usage pattern classification of workload resources running on the member nodes 102-106; Paragraph 0056, Further, in some examples, the processing resource 118 may execute one or more of the instructions 122 to determine a migration plan for a candidate workload resource of the workload resources based on the capability tag of each of the plurality of member nodes 102-106, the resource requirement classification and the temporal usage pattern classification of each workload resource hosted on the member nodes 102-106. Determination of the migration plan, in some examples, may include identifying the candidate workload resource, the target member node to which the candidate workload resource is to be migrated, and a time-schedule during which the migration of the candidate workload resource may be initiated);
to recommend one or more cloud-based infrastructure migration tasks in furtherance of the at least one decision-making context by processing at least a portion of the classified data using one or more machine learning techniques, wherein recommending one or more cloud-based infrastructure migration tasks comprises processing, using one or more artificial neural networks in conjunction with one or more [k-nearest neighbors algorithms], at least a portion of the obtained data classified into the one or more of multiple categories pertaining to cloud-based infrastructure usage-related parameters and at least a portion of the obtained data classified into the one or more of multiple categories pertaining to cloud-based infrastructure requirements (Paragraph 0013, he scheduling (e.g., deployment) and/or migration of the workload resources may be managed to address the need for rapid deployment of services, at cloud scale, keeping in mind factors like agility, ease of application upgrades or rollbacks and cloud-native workload resources; Paragraph 0052, Moreover, in some examples, the processing resource 118 may execute one or more of the instructions 122 to determine a temporal usage pattern classification of each workload resource of the workload resource WLR1-WLR6. In some examples, the processing resource 118 may execute one or more machine learning (ML) models, for example, a usage pattern classification ML model 133 (labeled as UPC MLM 133 in FIG. 1), stored in the machine-readable medium 120 to determine the temporal usage pattern classification of each of the workload resources (WLR1-WLR2). Examples of the temporal usage classifications may include, but are not limited to, a periodic pattern, a seasonal pattern, a maintenance pattern, or an unpredictable operation. The usage pattern classification ML model 133 may include any or combinations of a Random Forest classifier, Adaptive Boosting (Ada Boost) algorithm, or K Nearest Neighbor (KNN) classifier. The processing resource 118 may train the usage pattern classification ML model 133 using a training datasets that emulate workloads that demonstrate one or more of a periodic pattern, a seasonal pattern, a maintenance pattern, or an unpredictable operation. By using the training datasets of such known workloads to train the usage pattern classification ML model 133, the usage pattern classification ML model 133 may learn such characteristics which is then used to determine the temporal usage pattern classification of workload resources running on the member nodes 102-106; Paragraph 0056, Further, in some examples, the processing resource 118 may execute one or more of the instructions 122 to determine a migration plan for a candidate workload resource of the workload resources based on the capability tag of each of the plurality of member nodes 102-106, the resource requirement classification and the temporal usage pattern classification of each workload resource hosted on the member nodes 102-106. Determination of the migration plan, in some examples, may include identifying the candidate workload resource, the target member node to which the candidate workload resource is to be migrated, and a time-schedule during which the migration of the candidate workload resource may be initiated);
and to perform one or more automated actions based at least in part on the one or more recommended cloud-based infrastructure migration tasks, wherein performing one or more automated actions comprises automatically migrating resources from the at least one system to a particular cloud-based infrastructure in accordance with the one or more recommended cloud-based infrastructure migration tasks, wherein automatically migrating resources comprises migrating resources to at least one cloud storage structure and migrating compute resources in connection with one or more load balancing operations (Paragraph 0013, The scheduling (e.g., deployment) and/or migration of the workload resources may be managed to address the need for rapid deployment of services, at cloud scale, keeping in mind factors like agility, ease of application upgrades or rollbacks and cloud-native workload resources; Paragraph 0056, Further, in some examples, the processing resource 118 may execute one or more of the instructions 122 to determine a migration plan for a candidate workload resource of the workload resources based on the capability tag of each of the plurality of member nodes 102-106, the resource requirement classification and the temporal usage pattern classification of each workload resource hosted on the member nodes 102-106. Determination of the migration plan, in some examples, may include identifying the candidate workload resource, the target member node to which the candidate workload resource is to be migrated, and a time-schedule during which the migration of the candidate workload resource may be initiated; Paragraph 0063, Once the migration plan is determined, the processing resource 118 may execute one or more of the instructions 122 to migrate the candidate workload resource(s) as per the determined migration plan. In some examples, the candidate workload resource(s) may be migrated to the respective target node(s) without application data being lost by using a persistent storage. In some examples, migration of the candidate workload resource(s) may include configuring and deploying the candidate workload resource(s) on the identified target member nodes as recommended in the migration plan data 136. Once the candidate workload resource(s) are deployed on the identified target member nodes, the candidate workload resource(s) are operationalized on the target member nodes);
and … training at least a portion of the one or more artificial neural networks based at least in part on [training datasets] … (Paragraph 0052, The processing resource 118 may train the usage pattern classification ML model 133 using a training datasets that emulate workloads that demonstrate one or more of a periodic pattern, a seasonal pattern, a maintenance pattern, or an unpredictable operation. By using the training datasets of such known workloads to train the usage pattern classification ML model 133, the usage pattern classification ML model 133 may learn such characteristics which is then used to determine the temporal usage pattern classification of workload resources running on the member nodes 102-106).
Although Lange et al. discloses to recommend one or more cloud-based infrastructure migration tasks based on data related to at least one decision-making context (e.g., usage/utilization patterns for different SW and HW configurations, storage needs, etc.), Lange et al. does not specifically wherein the data related to the at least one decision-making context further includes hit rate data & disaster recovery data.
However, Guha discloses comprising hit rate data and disaster recovery data, data pertaining to one or more cluster-specific redundancy …, data pertaining to one or more concurrent computational requests associated with the at least one system (Paragraph 0006, Unfortunately, reactively migrating VM virtual storage can result in performance problems. For example, the new storage system to which the VM has been migrated may not be the best choice. This is a limitation of the VM manager enforcing the SLAs for VMs since it does not have visibility into the detailed performance capabilities of the storage system. The storage system in many cases can make better decisions since it has in-depth knowledge of the physical storage attributes including availability or redundancy, compression, performance, encryption, and storage capacity. However, the physical storage system that contains the VM virtual storage does not always have visibility into the application workload's performance requirements. The combination of the limitations faced by the VM manager and storage systems increases the difficulty of dynamically provisioning VM storage in virtualized data centers; Paragraph 0064, The basis for determining whether a VM 108 can be satisfied by an LSV 102 is determined by the service level objectives (SLOs) of the VM 108, that includes specifications or limits or thresholds on performance, availability, compression, security, etc. An example of a performance SLO could be latency less than 1 ms. An SLO on availability might include recovery time objective (RTO) or time it takes to recover from a data loss event and how long it takes to return to service; Paragraph 0225, Cache hit rate (CHR) for a given workload is estimated by observing the completion times of IOs for the workload. Whenever a random IO completes less than typical disk times (<0 (ms)), then it is expected to be from a cache hit, otherwise it is from a disk. If the CHR is consistent, it can be used to get a better weighted estimate of the IO service time; Paragraph 0238, IOs are submitted to the SDS 100 from the ordered set as soon as the schedule for submission is completed. It is assumed that the SDS 100 can execute then in any order or concurrently).
It would have been obvious to one ordinary skill in the art before the effective filing date to modify the method for recommending one or more cloud-based infrastructure migration tasks based on data related to at least one decision-making context (e.g., usage/utilization patterns for different SW and HW configurations, requirements, performance, etc.) of the invention of Lange et al. to further incorporate hit rate and disaster recovery data of the invention of Guha because doing so would allow the method to make better migration decisions based on performance requirements such as recovery time objective and cache hit (see Guha, Paragraphs 0006 & 0064). Further, the claimed invention is merely a combination of old elements, and in combination each element would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Although the combination of Lange et al. and Guha discloses data pertaining to one or more cluster-specific redundancy (see Lange et al., one or more replicas of resources to enable high availability of workload resources; Guha, Paragraph 0006, physical storage attributes including availability or redundancy), the combination of Lange et al. and Guha does not specifically disclose wherein the data pertaining to one or more cluster-specific redundancy includes redundancy amounts.
However, Sheshadi et al. discloses data pertaining to one or more cluster-specific redundancy amounts, data pertaining to one or more concurrent computational requests associated with the at least one system (Paragraph 0049, These ML models may therefore predict future resource usage (e.g., a CPU usage rate or percentage, as well as similar usages and/or required allocation for latency, TPM, container count, and other requirements of compute pools and other machines). Such recommendations may be for rising and falling flux in future predicted resource usage, which may include a predicted max TPM, a buffer of extra resources, a threshold or baseline amount of resources that may always be allocated, and/or an architectural buffer based on rising, flux or peak, and falling predicted usages; Paragraph 0050, Reactive sizing 204 may receive a prediction of future resource usage from ML components 208, and may utilize the prediction to allocate server and computing resources at one or more future times based on the available resources of the service provider's platform and/or system at the future time(s). Reactive sizing 204, based on predictive outputs by ML components 208, may perform reactive sizing and allocation of server and computing resources, such as machines and pools of machines for pool 218, based on a future window (e.g., periodically and/or continuously in 30-minute forward windows). Further, the reactive sizing may include scaling zones, such as climbing, peak, and descending zones for resource usage and demand, and consider scale down lag for sizing and allocation of resources based on usage and demand. Reactive sizing 204 may perform monitoring after allocation. Monitoring by reactive sizing 204 may include alert dynamic sizing for hierarchical alerts on CPU and latency, such as monitoring CPU usage when between 70-110% capacity. Reserve sizing 206 may also establish a reserve of additional server and/or computing resources that may be provided to demand systems in response to data processing requests and the like. The reserved or extra capacity may be associated with unused capacity and may be reserved for required overages from demand and resource usage, or provided for other computational tasks and requirements of the service provider's computing platform and/or system. For example, reserve sizing 206 may provide a strategy to size one or more compute pools up to a peak and size down to a valley, such as by combining information from alerts, recommendations, and raw TPM at certain time intervals (e.g., 15 minutes). In some embodiments, a baseline threshold or amount of resources may always be allocated to prevent reactive sizing 204 from allocating too little or no resources based on a ML prediction of future resource usage; Examiner interprets “buffer and/or reserve” as the “specific redundancy amounts”).
It would have been obvious to one ordinary skill in the art before the effective filing date to modify the method for recommending one or more cloud-based infrastructure migration tasks based on data related to at least one decision-making context (e.g., usage/utilization patterns for different SW and HW configurations, requirements, performance, etc.) of the invention of Lange et al. to further incorporate data pertaining to one or more cluster-specific redundancy amounts of the invention of Sheshadi et al. because doing so would allow the method to allocate an amount of resources to prevent reactive sizing (see Sheshadi et al., Paragraph 0050). Further, the claimed invention is merely a combination of old elements, and in combination each element would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Lange et al. discloses recommending, using one or more classification algorithms such as a k-nearest neighbor, one or more cloud-based infrastructure migration tasks. Although Lange et al. discloses all the limitations above and one or more classification algorithms, the combination of Lange et al., Guha, and Sheshadi et al. does not specifically disclose wherein the classification algorithm is a logistic regression algorithm.
However, Shrestha et al. discloses wherein recommending one or more cloud- based infrastructure migration tasks comprises processing, using one or more artificial neural networks in conjunction with one or more logistic regression algorithms (Paragraph 0090, In some embodiments, a given pretrained predictive model may include a classifier or a regression model that was trained using: a support vector machine technique, a classification and regression tree technique, least-squares regression, logistic regression, another regression technique, lasso logistic regression, LASSO, logistic linear regression, a neural network technique (such as a convolutional neural network technique, a generative adversarial network or another type of neural network technique) and/or another linear or nonlinear supervised-learning technique; Paragraph 0110; Paragraph 0156, Note that the network problem may be detected (operation 1012) using a pretrained model, such as a machine-learning model or a neural network. When detecting the network problem (operation 1012), the information may be input to the pretrained model and information specifying the network problem may be output from the pretrained model. Alternatively, or additionally, the remedial action may be determined (operation 1016) using a rule engine, a look-up table or a second pretrained model, such as a machine-learning model or a neural network. When determining the remedial action (operation 1016), the information specifying the network problem may be used as an input and the remedial action may be an output from the rule engine, the look-up table or the second pretrained model; Paragraph 0160, Note that the remedial action or the second remedial action may include a configuration change in the network), …
and automatically training at least a portion of the one or more artificial neural networks based at least in part on feedback related to the one or more recommended tasks (Paragraph 0065, By automatically determining and performing the remedial action when possible and, when it is not possible to determine the remedial action, by dynamically collecting additional data, diagnosing the network problem, computing the second remedial action, and receiving approval for the second remedial action, these monitoring techniques may provide automated feedback and continuous learning for the network. These capabilities may allow a relationship between a potential cause (e.g., a configuration) and an effect (e.g., the network problem) to be determined. These capabilities may facilitate accurate anomaly detection (e.g., with reduced false positives or false alarms) and appropriate corrective action (such as the remedial action or the second remedial action) to address the network problem, such as a component failure or communication-performance degradation in the network; Paragraph 0084, Moreover, computer system 104 may determine a recommended configuration change for the network based at least in part on the detected network problem, where the recommended configuration change is predicted to improve communication performance of the network in at least a portion of the network. Note that the recommended configuration change may be determined using the same or a different pretrained model, such as a machine-learning model or a neural network; Paragraph 0137, Furthermore, during the monitoring techniques, the recommendation knowledgebase may be built from or using: domain expertise: machine learning of current and historical communication-performance metrics and recommendations. Additionally, during the monitoring techniques, the recommendation knowledge graph may be optimized using continuous learning of dynamic and static factors: and/or communication-performance metrics and key performance indicators before and after a recommendation was applied).
It would have been obvious to one ordinary skill in the art before the effective filing date to modify the method for recommending one or more cloud-based infrastructure migration tasks based on data related to at least one decision-making context (e.g., by using one or more classification algorithms such as a k-nearest neighbor) of the invention of Lange et al. to further incorporate other classification algorithms and feedback related to the one or more recommended tasks of the invention of Shrestha et al. because doing so would allow the method to optimize recommendations by receiving continuous learning (see Shrestha et al., Paragraph 0137). Further, the claimed invention is merely a combination of old elements, and in combination each element would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Regarding claim 17 (Currently Amended), Lange et al. discloses an apparatus comprising: at least one processing device comprising a processor coupled to a memory; the at least one processing device being configured (Paragraph 0003, FIG. 1 depicts a networked system including a plurality of member nodes and a management node for managing migration of a workload resource among the plurality of the member nodes; Paragraph 0068, The method 300 may include method blocks 302, 304, 306, and 308 (hereinafter collectively referred to as blocks 302-308) which may be performed by a processor-based system such as, for example, the management node 108. In particular, operations at each of the method blocks 302-308 may be performed by the processing resource 118 by executing the instructions 122 stored in the machine-readable medium 120 (see FIG. 1)):
to obtain data related to at least one decision-making context in connection with at least one system, wherein the data comprises data related to hardware configurations of the at least one system, data related to software configurations of the at least one system, data related to network parameters, associated with the at least one system, and comprising [performance such as usage/utilization and storage needs] data, data pertaining to one or more cluster-specific redundancy …, …, and data related to storage infrastructure associated with the at least one system (Paragraph 0012, In some instances, the management node may deploy one or more replicas of the workload resources on several member nodes to enable high availability of the workload resources; Paragraph 0016, Furthermore, in some instances, the workload resources may have different resource utilizations based on the types of workloads running thereon. For example, a workload resource running CPU and memory workloads (e.g., machine learning (ML), integer, floating point operations) may utilize more compute power, whereas another workload resource running storage-centric database workloads (e.g., SQL server, SAP HANA) may utilize more storage from a respective member node. In some instances, a performance of a given workload may be adversely impacted if a workload resource running the given workload is placed on hardware that is not tuned or optimized for a given workload type. In such case, to achieve the customer's Service Level Agreement (SLA) requirements, additional compute and storage may be provisioned to the workload resource, thereby increasing the overall hardware cost, which, in turn, may increase the capital expenditure of in the networked systemParagraph 0026, In FIG. 1, although the networked system 100 is shown to include three member nodes 102-106, the networked system 100 may include any number of member nodes, without limiting the scope of the present disclosure. The member nodes 102-106 may have similar or varying hardware and/or software configurations in a given implementation of the networked system 100. By way of example, while some member nodes may have high-performance compute capabilities, some member nodes may facilitate strong data security, some member nodes may facilitate low-latency data read and/or write operations, certain member nodes may have enhanced thermal capabilities, some member nodes may be good at handling database operations, or some member nodes may be good at handling graphics processing operations; Paragraph 0027, The member nodes 102-106 may facilitate resources, for example, compute, storage, and/or networking capabilities, for one or more workload resources to execute thereon. The term workload resource may refer to a computing resource including, but not limited to, an application (e.g., software program), a virtual machine (VM), a container, a pod, a database, a data store, a logical disk, or a containerized application. As will be understood, a workload resource such as a VM include an instance of an operating system hosted on a given member node via a VM host program such as a hypervisor. Further, a workload resource such as a container may be an application packaged with its dependencies (e.g., operating system resources, processing allocations, memory allocations, etc.) hosted on a given member node via a container host program such as a container runtime (e.g., Docker Engine), for example; Paragraph 0036, The management node 108 may obtain the platform capability data (e.g., platform capability labels and respective settings) for each of member nodes 102-106 and the performance data corresponding to the workload resources (e.g., one or more of the workload resources WLR1-WLR6) from the respective member nodes 102-106);
to classify at least a portion of the obtained data into one or more of multiple categories of action-related requirements associated with the at least one decision-making context, wherein classifying at least a portion of the obtained data comprises classifying the at least a portion of the obtained data into one or more of multiple categories pertaining to cloud-based infrastructure usage-related parameters associated with the at least one decision-making context and one or more of multiple categories pertaining to cloud-based infrastructure requirements associated with the at least one decision-making context (Paragraph 0013, The scheduling (e.g., deployment) and/or migration of the workload resources may be managed to address the need for rapid deployment of services, at cloud scale, keeping in mind factors like agility, ease of application upgrades or rollbacks and cloud-native workload resources; Paragraph 0052, Moreover, in some examples, the processing resource 118 may execute one or more of the instructions 122 to determine a temporal usage pattern classification of each workload resource of the workload resource WLR1-WLR6. In some examples, the processing resource 118 may execute one or more machine learning (ML) models, for example, a usage pattern classification ML model 133 (labeled as UPC MLM 133 in FIG. 1), stored in the machine-readable medium 120 to determine the temporal usage pattern classification of each of the workload resources (WLR1-WLR2). Examples of the temporal usage classifications may include, but are not limited to, a periodic pattern, a seasonal pattern, a maintenance pattern, or an unpredictable operation. The usage pattern classification ML model 133 may include any or combinations of a Random Forest classifier, Adaptive Boosting (Ada Boost) algorithm, or K Nearest Neighbor (KNN) classifier. The processing resource 118 may train the usage pattern classification ML model 133 using a training datasets that emulate workloads that demonstrate one or more of a periodic pattern, a seasonal pattern, a maintenance pattern, or an unpredictable operation. By using the training datasets of such known workloads to train the usage pattern classification ML model 133, the usage pattern classification ML model 133 may learn such characteristics which is then used to determine the temporal usage pattern classification of workload resources running on the member nodes 102-106; Paragraph 0056, Further, in some examples, the processing resource 118 may execute one or more of the instructions 122 to determine a migration plan for a candidate workload resource of the workload resources based on the capability tag of each of the plurality of member nodes 102-106, the resource requirement classification and the temporal usage pattern classification of each workload resource hosted on the member nodes 102-106. Determination of the migration plan, in some examples, may include identifying the candidate workload resource, the target member node to which the candidate workload resource is to be migrated, and a time-schedule during which the migration of the candidate workload resource may be initiated);
to recommend one or more cloud-based infrastructure migration tasks in furtherance of the at least one decision-making context by processing at least a portion of the classified data using one or more machine learning techniques, wherein recommending one or more cloud-based infrastructure migration tasks comprises processing, using one or more artificial neural networks in conjunction with one or more [k-nearest neighbors algorithms], at least a portion of the obtained data classified into the one or more of multiple categories pertaining to cloud-based infrastructure usage-related parameters and at least a portion of the obtained data classified into the one or more of multiple categories pertaining to cloud-based infrastructure requirements (Paragraph 0013, The scheduling (e.g., deployment) and/or migration of the workload resources may be managed to address the need for rapid deployment of services, at cloud scale, keeping in mind factors like agility, ease of application upgrades or rollbacks and cloud-native workload resources; Paragraph 0052, Moreover, in some examples, the processing resource 118 may execute one or more of the instructions 122 to determine a temporal usage pattern classification of each workload resource of the workload resource WLR1-WLR6. In some examples, the processing resource 118 may execute one or more machine learning (ML) models, for example, a usage pattern classification ML model 133 (labeled as UPC MLM 133 in FIG. 1), stored in the machine-readable medium 120 to determine the temporal usage pattern classification of each of the workload resources (WLR1-WLR2). Examples of the temporal usage classifications may include, but are not limited to, a periodic pattern, a seasonal pattern, a maintenance pattern, or an unpredictable operation. The usage pattern classification ML model 133 may include any or combinations of a Random Forest classifier, Adaptive Boosting (Ada Boost) algorithm, or K Nearest Neighbor (KNN) classifier. The processing resource 118 may train the usage pattern classification ML model 133 using a training datasets that emulate workloads that demonstrate one or more of a periodic pattern, a seasonal pattern, a maintenance pattern, or an unpredictable operation. By using the training datasets of such known workloads to train the usage pattern classification ML model 133, the usage pattern classification ML model 133 may learn such characteristics which is then used to determine the temporal usage pattern classification of workload resources running on the member nodes 102-106; Paragraph 0056, Further, in some examples, the processing resource 118 may execute one or more of the instructions 122 to determine a migration plan for a candidate workload resource of the workload resources based on the capability tag of each of the plurality of member nodes 102-106, the resource requirement classification and the temporal usage pattern classification of each workload resource hosted on the member nodes 102-106. Determination of the migration plan, in some examples, may include identifying the candidate workload resource, the target member node to which the candidate workload resource is to be migrated, and a time-schedule during which the migration of the candidate workload resource may be initiated);
and to perform one or more automated actions based at least in part on the one or more recommended cloud-based infrastructure migration tasks, wherein performing one or more automated actions comprises automatically migrating resources from the at least one system to a particular cloud-based infrastructure in accordance with the one or more recommended cloud-based infrastructure migration tasks, wherein automatically migrating resources comprises migrating resources to at least one cloud storage structure and migrating compute resources in connection with one or more load balancing operations (Paragraph 0013, The scheduling (e.g., deployment) and/or migration of the workload resources may be managed to address the need for rapid deployment of services, at cloud scale, keeping in mind factors like agility, ease of application upgrades or rollbacks and cloud-native workload resources; Paragraph 0056, Further, in some examples, the processing resource 118 may execute one or more of the instructions 122 to determine a migration plan for a candidate workload resource of the workload resources based on the capability tag of each of the plurality of member nodes 102-106, the resource requirement classification and the temporal usage pattern classification of each workload resource hosted on the member nodes 102-106. Determination of the migration plan, in some examples, may include identifying the candidate workload resource, the target member node to which the candidate workload resource is to be migrated, and a time-schedule during which the migration of the candidate workload resource may be initiated; Paragraph 0063, Once the migration plan is determined, the processing resource 118 may execute one or more of the instructions 122 to migrate the candidate workload resource(s) as per the determined migration plan. In some examples, the candidate workload resource(s) may be migrated to the respective target node(s) without application data being lost by using a persistent storage. In some examples, migration of the candidate workload resource(s) may include configuring and deploying the candidate workload resource(s) on the identified target member nodes as recommended in the migration plan data 136. Once the candidate workload resource(s) are deployed on the identified target member nodes, the candidate workload resource(s) are operationalized on the target member nodes);
and … training at least a portion of the one or more artificial neural networks based at least in part on [training datasets] … (Paragraph 0052, The processing resource 118 may train the usage pattern classification ML model 133 using a training datasets that emulate workloads that demonstrate one or more of a periodic pattern, a seasonal pattern, a maintenance pattern, or an unpredictable operation. By using the training datasets of such known workloads to train the usage pattern classification ML model 133, the usage pattern classification ML model 133 may learn such characteristics which is then used to determine the temporal usage pattern classification of workload resources running on the member nodes 102-106).
Although Lange et al. discloses to recommend one or more cloud-based infrastructure migration tasks based on data related to at least one decision-making context (e.g., usage/utilization patterns for different SW and HW configurations, storage needs, etc.), Lange et al. does not specifically wherein the data related to the at least one decision-making context further includes hit rate data & disaster recovery data.
However, Guha discloses comprising hit rate data and disaster recovery data, data pertaining to one or more cluster-specific redundancy …, data pertaining to one or more concurrent computational requests associated with the at least one system (Paragraph 0006, Unfortunately, reactively migrating VM virtual storage can result in performance problems. For example, the new storage system to which the VM has been migrated may not be the best choice. This is a limitation of the VM manager enforcing the SLAs for VMs since it does not have visibility into the detailed performance capabilities of the storage system. The storage system in many cases can make better decisions since it has in-depth knowledge of the physical storage attributes including availability or redundancy, compression, performance, encryption, and storage capacity. However, the physical storage system that contains the VM virtual storage does not always have visibility into the application workload's performance requirements. The combination of the limitations faced by the VM manager and storage systems increases the difficulty of dynamically provisioning VM storage in virtualized data centers; Paragraph 0064, The basis for determining whether a VM 108 can be satisfied by an LSV 102 is determined by the service level objectives (SLOs) of the VM 108, that includes specifications or limits or thresholds on performance, availability, compression, security, etc. An example of a performance SLO could be latency less than 1 ms. An SLO on availability might include recovery time objective (RTO) or time it takes to recover from a data loss event and how long it takes to return to service; Paragraph 0225, Cache hit rate (CHR) for a given workload is estimated by observing the completion times of IOs for the workload. Whenever a random IO completes less than typical disk times (<0 (ms)), then it is expected to be from a cache hit, otherwise it is from a disk. If the CHR is consistent, it can be used to get a better weighted estimate of the IO service time; Paragraph 0238, IOs are submitted to the SDS 100 from the ordered set as soon as the schedule for submission is completed. It is assumed that the SDS 100 can execute then in any order or concurrently).
It would have been obvious to one ordinary skill in the art before the effective filing date to modify the method for recommending one or more cloud-based infrastructure migration tasks based on data related to at least one decision-making context (e.g., usage/utilization patterns for different SW and HW configurations, requirements, performance, etc.) of the invention of Lange et al. to further incorporate hit rate and disaster recovery data of the invention of Guha because doing so would allow the method to make better migration decisions based on performance requirements such as recovery time objective and cache hit (see Guha, Paragraphs 0006 & 0064). Further, the claimed invention is merely a combination of old elements, and in combination each element would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Although the combination of Lange et al. and Guha discloses data pertaining to one or more cluster-specific redundancy (see Lange et al., one or more replicas of resources to enable high availability of workload resources; Guha, Paragraph 0006, physical storage attributes including availability or redundancy), the combination of Lange et al. and Guha does not specifically disclose wherein the data pertaining to one or more cluster-specific redundancy includes redundancy amounts.
However, Sheshadi et al. discloses data pertaining to one or more cluster-specific redundancy amounts, data pertaining to one or more concurrent computational requests associated with the at least one system (Paragraph 0049, These ML models may therefore predict future resource usage (e.g., a CPU usage rate or percentage, as well as similar usages and/or required allocation for latency, TPM, container count, and other requirements of compute pools and other machines). Such recommendations may be for rising and falling flux in future predicted resource usage, which may include a predicted max TPM, a buffer of extra resources, a threshold or baseline amount of resources that may always be allocated, and/or an architectural buffer based on rising, flux or peak, and falling predicted usages; Paragraph 0050, Reactive sizing 204 may receive a prediction of future resource usage from ML components 208, and may utilize the prediction to allocate server and computing resources at one or more future times based on the available resources of the service provider's platform and/or system at the future time(s). Reactive sizing 204, based on predictive outputs by ML components 208, may perform reactive sizing and allocation of server and computing resources, such as machines and pools of machines for pool 218, based on a future window (e.g., periodically and/or continuously in 30-minute forward windows). Further, the reactive sizing may include scaling zones, such as climbing, peak, and descending zones for resource usage and demand, and consider scale down lag for sizing and allocation of resources based on usage and demand. Reactive sizing 204 may perform monitoring after allocation. Monitoring by reactive sizing 204 may include alert dynamic sizing for hierarchical alerts on CPU and latency, such as monitoring CPU usage when between 70-110% capacity. Reserve sizing 206 may also establish a reserve of additional server and/or computing resources that may be provided to demand systems in response to data processing requests and the like. The reserved or extra capacity may be associated with unused capacity and may be reserved for required overages from demand and resource usage, or provided for other computational tasks and requirements of the service provider's computing platform and/or system. For example, reserve sizing 206 may provide a strategy to size one or more compute pools up to a peak and size down to a valley, such as by combining information from alerts, recommendations, and raw TPM at certain time intervals (e.g., 15 minutes). In some embodiments, a baseline threshold or amount of resources may always be allocated to prevent reactive sizing 204 from allocating too little or no resources based on a ML prediction of future resource usage; Examiner interprets “buffer and/or reserve” as the “specific redundancy amounts”).
It would have been obvious to one ordinary skill in the art before the effective filing date to modify the method for recommending one or more cloud-based infrastructure migration tasks based on data related to at least one decision-making context (e.g., usage/utilization patterns for different SW and HW configurations, requirements, performance, etc.) of the invention of Lange et al. to further incorporate data pertaining to one or more cluster-specific redundancy amounts of the invention of Sheshadi et al. because doing so would allow the method to allocate an amount of resources to prevent reactive sizing (see Sheshadi et al., Paragraph 0050). Further, the claimed invention is merely a combination of old elements, and in combination each element would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Lange et al. discloses recommending, using one or more classification algorithms such as a k-nearest neighbor, one or more cloud-based infrastructure migration tasks. Although Lange et al. discloses all the limitations above and one or more classification algorithms, the combination of Lange et al., Guha, and Sheshadi et al. does not specifically disclose wherein the classification algorithm is a logistic regression algorithm.
However, Shrestha et al. discloses wherein recommending one or more cloud- based infrastructure migration tasks comprises processing, using one or more artificial neural networks in conjunction with one or more logistic regression algorithms (Paragraph 0090, In some embodiments, a given pretrained predictive model may include a classifier or a regression model that was trained using: a support vector machine technique, a classification and regression tree technique, least-squares regression, logistic regression, another regression technique, lasso logistic regression, LASSO, logistic linear regression, a neural network technique (such as a convolutional neural network technique, a generative adversarial network or another type of neural network technique) and/or another linear or nonlinear supervised-learning technique; Paragraph 0110; Paragraph 0156, Note that the network problem may be detected (operation 1012) using a pretrained model, such as a machine-learning model or a neural network. When detecting the network problem (operation 1012), the information may be input to the pretrained model and information specifying the network problem may be output from the pretrained model. Alternatively, or additionally, the remedial action may be determined (operation 1016) using a rule engine, a look-up table or a second pretrained model, such as a machine-learning model or a neural network. When determining the remedial action (operation 1016), the information specifying the network problem may be used as an input and the remedial action may be an output from the rule engine, the look-up table or the second pretrained model; Paragraph 0160, Note that the remedial action or the second remedial action may include a configuration change in the network), …
and automatically training at least a portion of the one or more artificial neural networks based at least in part on feedback related to the one or more recommended tasks (Paragraph 0065, By automatically determining and performing the remedial action when possible and, when it is not possible to determine the remedial action, by dynamically collecting additional data, diagnosing the network problem, computing the second remedial action, and receiving approval for the second remedial action, these monitoring techniques may provide automated feedback and continuous learning for the network. These capabilities may allow a relationship between a potential cause (e.g., a configuration) and an effect (e.g., the network problem) to be determined. These capabilities may facilitate accurate anomaly detection (e.g., with reduced false positives or false alarms) and appropriate corrective action (such as the remedial action or the second remedial action) to address the network problem, such as a component failure or communication-performance degradation in the network; Paragraph 0084, Moreover, computer system 104 may determine a recommended configuration change for the network based at least in part on the detected network problem, where the recommended configuration change is predicted to improve communication performance of the network in at least a portion of the network. Note that the recommended configuration change may be determined using the same or a different pretrained model, such as a machine-learning model or a neural network; Paragraph 0137, Furthermore, during the monitoring techniques, the recommendation knowledgebase may be built from or using: domain expertise: machine learning of current and historical communication-performance metrics and recommendations. Additionally, during the monitoring techniques, the recommendation knowledge graph may be optimized using continuous learning of dynamic and static factors: and/or communication-performance metrics and key performance indicators before and after a recommendation was applied).
It would have been obvious to one ordinary skill in the art before the effective filing date to modify the method for recommending one or more cloud-based infrastructure migration tasks based on data related to at least one decision-making context (e.g., by using one or more classification algorithms such as a k-nearest neighbor) of the invention of Lange et al. to further incorporate other classification algorithms and feedback related to the one or more recommended tasks of the invention of Shrestha et al. because doing so would allow the method to optimize recommendations by receiving continuous learning (see Shrestha et al., Paragraph 0137). Further, the claimed invention is merely a combination of old elements, and in combination each element would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Regarding claims 2, 14, and 18 (Original), which are dependent of claims 1, 13, and 17, the combination of Lange et al., Guha, Sheshadi et al., and Shrestha et al. discloses all the limitations in claims 1, 13, and 17. Lange et al. further discloses wherein classifying at least a portion of the obtained data comprises classifying the at least a portion of the obtained data into one or more of multiple categories of functional requirements associated with the at least one decision-making context and multiple categories (Paragraph 0018, To that end, in accordance with aspects of the present disclosure, a management node is presented that facilitates intelligently managed runtime migration of workload resources taking into consideration parameters such as, for example, performance characteristics of the member nodes, resource requirement classifications, and temporal usage pattern classifications of the workload resources running on the member nodes of a networked system. In some examples, the management node may assign a capability tag to each of a plurality of member nodes hosting workload resources. The management node may determine the capability tag for each of the plurality of member nodes based on platform capability data published by each of the plurality of member nodes; Paragraph 0026, The member nodes 102-106 may have similar or varying hardware and/or software configurations in a given implementation of the networked system 100. By way of example, while some member nodes may have high-performance compute capabilities, some member nodes may facilitate strong data security, some member nodes may facilitate low-latency data read and/or write operations, certain member nodes may have enhanced thermal capabilities, some member nodes may be good at handling database operations, or some member nodes may be good at handling graphics processing operations; Examiner interprets “resource requirements” as the “functional requirements”) of non-functional requirements associated with the at least one decision-making context (Paragraph 0001, The computing nodes may host workload resources that may generate or consume the data during their respective operations. Examples of the workload resources may include an application (e.g., software program), a virtual machine (VM), a container, a pod, a database, a data store, a logical disk, or a containerized application; As stated in Figure 3 of Applicant’s specification, non-functional requirements may include a virtual machine infrastructure).
Regarding claims 3, 15, and 19 (Original), which are dependent of claims 1, 13, and 17, the combination of Lange et al., Guha, Sheshadi et al., and Shrestha et al. discloses all the limitations in claims 1, 13, and 17. Lange et al. further discloses wherein performing one or more automated actions comprises automatically initiating at least one of the one or more recommended tasks (Paragraph 0063, Once the migration plan is determined, the processing resource 118 may execute one or more of the instructions 122 to migrate the candidate workload resource(s) as per the determined migration plan. In some examples, the candidate workload resource(s) may be migrated to the respective target node(s) without application data being lost by using a persistent storage. In some examples, migration of the candidate workload resource(s) may include configuring and deploying the candidate workload resource(s) on the identified target member nodes as recommended in the migration plan data 136. Once the candidate workload resource(s) are deployed on the identified target member nodes, the candidate workload resource(s) are operationalized on the target member nodes).
Regarding claims 4, 16, and 20 (Previously Presented), which are dependent of claims 1, 13, and 17, the combination of Lange et al., Guha, Sheshadi et al., and Shrestha et al. discloses all the limitations in claims 1, 13, and 17. Lange et al. further discloses wherein performing one or more automated actions comprises automatically outputting information pertaining to the one or more recommended tasks to one or more domain experts associated with the at least one system and the at least one decision-making context (Paragraph 0063, Once the migration plan is determined, the processing resource 118 may execute one or more of the instructions 122 to migrate the candidate workload resource(s) as per the determined migration plan. In some examples, the candidate workload resource(s) may be migrated to the respective target node(s) without application data being lost by using a persistent storage. In some examples, migration of the candidate workload resource(s) may include configuring and deploying the candidate workload resource(s) on the identified target member nodes as recommended in the migration plan data 136. Once the candidate workload resource(s) are deployed on the identified target member nodes, the candidate workload resource(s) are operationalized on the target member nodes).
Regarding claim 6 (Original), which is dependent of claim 1, the combination of Lange et al., Guha, Sheshadi et al., and Shrestha et al. discloses all the limitations in claim 1. Lange et al. further discloses wherein classifying at least a portion of the obtained data comprises determining one or more user-related patterns pertaining to the at least one decision-making context by processing the at least a portion of the obtained data (Paragraph 0052, Moreover, in some examples, the processing resource 118 may execute one or more of the instructions 122 to determine a temporal usage pattern classification of each workload resource of the workload resource WLR1-WLR6. In some examples, the processing resource 118 may execute one or more machine learning (ML) models, for example, a usage pattern classification ML model 133 (labeled as UPC MLM 133 in FIG. 1), stored in the machine-readable medium 120 to determine the temporal usage pattern classification of each of the workload resources (WLR1-WLR2). Examples of the temporal usage classifications may include, but are not limited to, a periodic pattern, a seasonal pattern, a maintenance pattern, or an unpredictable operation. The usage pattern classification ML model 133 may include any or combinations of a Random Forest classifier, Adaptive Boosting (Ada Boost) algorithm, or K Nearest Neighbor (KNN) classifier. The processing resource 118 may train the usage pattern classification ML model 133 using a training datasets that emulate workloads that demonstrate one or more of a periodic pattern, a seasonal pattern, a maintenance pattern, or an unpredictable operation. By using the training datasets of such known workloads to train the usage pattern classification ML model 133, the usage pattern classification ML model 133 may learn such characteristics which is then used to determine the temporal usage pattern classification of workload resources running on the member nodes 102-106).
Regarding claim 7 (Original), which is dependent of claim 1, the combination of Lange et al., Guha, Sheshadi et al., and Shrestha et al. discloses all the limitations in claim 1. Lange et al. further discloses wherein classifying at least a portion of the obtained data comprises classifying the at least a portion of the obtained data into one or more of the multiple categories of action-related requirements associated with the at least one decision-making context in response to one or more infrastructure changes to one or more systems associated with the at least one decision-making context (Paragraph 0056, Further, in some examples, the processing resource 118 may execute one or more of the instructions 122 to determine a migration plan for a candidate workload resource of the workload resources based on the capability tag of each of the plurality of member nodes 102-106, the resource requirement classification and the temporal usage pattern classification of each workload resource hosted on the member nodes 102-106. Determination of the migration plan, in some examples, may include identifying the candidate workload resource, the target member node to which the candidate workload resource is to be migrated, and a time-schedule during which the migration of the candidate workload resource may be initiated).
Regarding claim 8 (Original), which is dependent of claim 1, the combination of Lange et al., Guha, Sheshadi et al., and Shrestha et al. discloses all the limitations in claim 1. Lange et al. further discloses building at least one domain-related repository pertaining to the at least one decision-making context based at least in part on information pertaining to one or more domain-specific requirements related to the at least one decision-making context and one or more policy parameters related to the at least one decision-making context (Paragraph 0052, Moreover, in some examples, the processing resource 118 may execute one or more of the instructions 122 to determine a temporal usage pattern classification of each workload resource of the workload resource WLR1-WLR6. In some examples, the processing resource 118 may execute one or more machine learning (ML) models, for example, a usage pattern classification ML model 133 (labeled as UPC MLM 133 in FIG. 1), stored in the machine-readable medium 120 to determine the temporal usage pattern classification of each of the workload resources (WLR1-WLR2). Examples of the temporal usage classifications may include, but are not limited to, a periodic pattern, a seasonal pattern, a maintenance pattern, or an unpredictable operation. The usage pattern classification ML model 133 may include any or combinations of a Random Forest classifier, Adaptive Boosting (Ada Boost) algorithm, or K Nearest Neighbor (KNN) classifier. The processing resource 118 may train the usage pattern classification ML model 133 using a training datasets that emulate workloads that demonstrate one or more of a periodic pattern, a seasonal pattern, a maintenance pattern, or an unpredictable operation. By using the training datasets of such known workloads to train the usage pattern classification ML model 133, the usage pattern classification ML model 133 may learn such characteristics which is then used to determine the temporal usage pattern classification of workload resources running on the member nodes 102-106; It can be noted that the claim language is written in alternative form. The limitation taught by Lange et al. is based on “one or more domain-specific requirements related to the at least one decision-making context,” wherein the one or more domain-specific requirements includes at least usage pattern of each workload resource).
Regarding claim 10 (Original), which is dependent of claim 1, the combination of Lange et al., Guha, Sheshadi et al., and Shrestha et al. discloses all the limitations in claim 1. Lange et al. further discloses wherein the at least one decision-making context comprises at least one information technology deployment-related decision-making context, and wherein recommending one or more tasks in furtherance of the at least one decision-making context comprises recommending one or more tasks related to virtual infrastructure (Paragraph 0001, Examples of the workload resources may include an application (e.g., software program), a virtual machine (VM), a container, a pod, a database, a data store, a logical disk, or a containerized application; Paragraph 0056, Further, in some examples, the processing resource 118 may execute one or more of the instructions 122 to determine a migration plan for a candidate workload resource of the workload resources based on the capability tag of each of the plurality of member nodes 102-106, the resource requirement classification and the temporal usage pattern classification of each workload resource hosted on the member nodes 102-106. Determination of the migration plan, in some examples, may include identifying the candidate workload resource, the target member node to which the candidate workload resource is to be migrated, and a time-schedule during which the migration of the candidate workload resource may be initiated).
Regarding claim 11 (Previously Presented), which is dependent of claim 1, the combination of Lange et al., Guha, Sheshadi et al., and Shrestha et al. discloses all the limitations in claim 1. Lange et al. further discloses wherein the at least one decision-making context comprises at least one information technology deployment-related decision-making context, and wherein obtaining data related to at least one decision-making context in connection with at least one system comprises obtaining one or more of storage data, throughput data, hit rate data, and gateway-related information (Paragraph 0016, Furthermore, in some instances, the workload resources may have different resource utilizations based on the types of workloads running thereon. For example, a workload resource running CPU and memory workloads (e.g., machine learning (ML), integer, floating point operations) may utilize more compute power, whereas another workload resource running storage-centric database workloads (e.g., SQL server, SAP HANA) may utilize more storage from a respective member node. In some instances, a performance of a given workload may be adversely impacted if a workload resource running the given workload is placed on hardware that is not tuned or optimized for a given workload type. In such case, to achieve the customer's Service Level Agreement (SLA) requirements, additional compute and storage may be provisioned to the workload resource, thereby increasing the overall hardware cost, which, in turn, may increase the capital expenditure of in the networked system; Paragraph 0035, In some examples, the performance monitor 112 may collect performance data of each workload resource hosted on the member node 102 using various sources; It can be noted that the claim language is written in alternative form. The limitation taught by Lange et al. is based on “storage data").
Regarding claim 12 (Previously Presented), which is dependent of claim 1, the combination of Lange et al., Guha, Sheshadi et al., and Shrestha et al. discloses all the limitations in claim 1. Although Lange et al. further discloses wherein obtaining data related to at least one decision-making context in connection with at least one system comprises obtaining the data in accordance with one or more defined service level agreements associated with the at least one system (Paragraph 0016, Furthermore, in some instances, the workload resources may have different resource utilizations based on the types of workloads running thereon. For example, a workload resource running CPU and memory workloads (e.g., machine learning (ML), integer, floating point operations) may utilize more compute power, whereas another workload resource running storage-centric database workloads (e.g., SQL server, SAP HANA) may utilize more storage from a respective member node. In some instances, a performance of a given workload may be adversely impacted if a workload resource running the given workload is placed on hardware that is not tuned or optimized for a given workload type. In such case, to achieve the customer's Service Level Agreement (SLA) requirements, additional compute and storage may be provisioned to the workload resource, thereby increasing the overall hardware cost, which, in turn, may increase the capital expenditure of in the networked system; Paragraph 0023, For example, the workload resource that are periodic in nature may be migrated to low-power or less compute intensive member nodes when such periodic workload resources are inactive or idle. Such migration of the workload resources according to respective temporal usage pattern classifications may ensure that the workload resources are not placed statically on the same hardware, thereby reducing the operational expenditure by lowering power and cooling requirements in the networked system, for example. Moreover, as the workload resources are migrated when the workload resources are inactive or idle, impact to the performance of the workload resources and violations of SLAs may be avoided).
Regarding claim 21 (New), which is dependent of claim 17, the combination of Lange et al., Guha, Sheshadi et al., and Shrestha et al. discloses all the limitations in claim 17. Lange et al. further discloses wherein the at least one decision-making context comprises at least one information technology deployment-related decision-making context, and wherein recommending one or more tasks in furtherance of the at least one decision- making context comprises recommending one or more tasks related to virtual infrastructure (Paragraph 0001, Examples of the workload resources may include an application (e.g., software program), a virtual machine (VM), a container, a pod, a database, a data store, a logical disk, or a containerized application; Paragraph 0015, In some instances, to adopt to such new SaaS model offering the services on the pay-per use basis, several workload resources may be migrated from one information technology (IT) set-up to another IT set-up; Paragraph 0056, Further, in some examples, the processing resource 118 may execute one or more of the instructions 122 to determine a migration plan for a candidate workload resource of the workload resources based on the capability tag of each of the plurality of member nodes 102-106, the resource requirement classification and the temporal usage pattern classification of each workload resource hosted on the member nodes 102-106. Determination of the migration plan, in some examples, may include identifying the candidate workload resource, the target member node to which the candidate workload resource is to be migrated, and a time-schedule during which the migration of the candidate workload resource may be initiated).
Claim 9 are rejected under 35 U.S.C. 103 as being unpatentable over as being unpatentable over Lange et al. (US 2022/0229707 A1), in view of Guha (US 2021/0349749 A1), in further view of Sheshadi et al. (US 2022/0383324 A1) and Shrestha et al. (US 2024/0195687 A1), and Gupta et al. (US 11,941,454 В1).
Regarding claim 9 (Original), which is dependent of claim 8, the combination of Lange et al., Guha, Sheshadi et al., and Shrestha et al. discloses all the limitations in claim 1. Lange et al. further discloses wherein building the at least one domain-related repository comprises processing one or more of domain-related [inputs] (Paragraph 0001, Examples of the workload resources may include an application (e.g., software program), a virtual machine (VM), a container, a pod, a database, a data store, a logical disk, or a containerized application; Paragraph 0052, Moreover, in some examples, the processing resource 118 may execute one or more of the instructions 122 to determine a temporal usage pattern classification of each workload resource of the workload resource WLR1-WLR6. In some examples, the processing resource 118 may execute one or more machine learning (ML) models, for example, a usage pattern classification ML model 133 (labeled as UPC MLM 133 in FIG. 1), stored in the machine-readable medium 120 to determine the temporal usage pattern classification of each of the workload resources (WLR1-WLR2)).
Although Lange et al. discloses wherein building the at least one domain-related repository comprises processing user pattern data, Lange et al. does not specifically discloses wherein building the at least one domain-related repository comprises processing one or more of domain-related application forms, domain-related proposal request forms, and domain-related questions and corresponding responses.
However, Gupta et al. discloses wherein building the at least one domain-related repository comprises processing one or more of domain-related application forms, domain-related proposal request forms, and domain-related questions and corresponding responses (Column 2, lines 11-25, The wizard may present user interface(s) that include text-input fields to receive a textual description of a workload from a user, or fields with a drop-down menu that include answers for a question regarding the workload of the user, such that a user can answer high-level questions about their workloads. For example, the wizard may present the user with questions such as “is your workload a publicly facing website,” or “how many visitors do you expect per day?”. The storage optimization system may use the input received from the user to classify the workload as belonging to a predefined workload category (e.g., web-server category, database category, compute-heavy category, etc.), and provide the user account with a listing of recommended VM instance types to support their workload).
It would have been obvious to one ordinary skill in the art before the effective filing date to modify the method for recommending one or more cloud-based infrastructure migration tasks in furtherance of the at least one decision-making context (e.g. recommending migration of one or more tasks for improving/optimizing performance metrics based on domain-specific requirements) of the invention of Lange et al. to further incorporate domain-related questions and/or corresponding responses of the invention of Gupta et al. because doing so would allow the method to include answers for a question regarding the workload of the user (see Gupta et al., Column 2, lines 11-25). Further, the claimed invention is merely a combination of old elements, and in combination each element would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
Bhangu et al. (US 2025/0080415 A1) – discloses an AI/ML model, based on the data referring to historical and/or current utilization patterns as set forth above, predicts a performance degradation (over time and/or at a location) of at least one O-cloud node and/or one or more NFs hosted thereon. To this end, for example, in order to ensure that a robust performance of the O-RAN is preserved, the prediction may be based on suitable telemetric data that are performance-centric and allow the AI-ML model to provide for a prediction of one or more unhealthy NFs to be migrated (i.e., relocated) from their O-Cloud nodes to other O-Cloud nodes that enable the newly (i.e., re-instantiated) NFs to run in a healthy state. (i.e., instantiated new NFs on other O-Cloud nodes that are suitable to accommodate the workload of the NFs. As a result, this prediction allows a performance-centric migration recommendation (i.e., a migration decision of the rApp) in order to optimize the performance of the O-RAN operation (see at least Paragraph 0064).
Sheshadri et al. (US 2022/0383324 A1) – discloses an intelligent machine learning (ML) engine that analyzes past computing resource usage during different time periods to predict potential future usage of computing resources. The ML engine may utilize one or more ML models, such as linear and/or linear regression fit curves based on past usage data, as well as gradient boosting machine (GMB) and light GBM tree-based decision-making models, to identify patterns and/or momentums in past user activity, computing resource usage, and/or compute pool requests and processing by the computing resources of the service provider. Based on this analysis, the ML models and engine may predict and determine potential future usage of computing resources and availability of the service provider. For example, the service provider may determine usage of various compute pools during different periods of time and by different computing services. This may include CPU/GPU usage and throughput, processing time and completeness, latency, and other computing resource use and effectiveness (see at least Paragraphs 0013, 0017, & 0030).
Martin et al. (US 2021/0125128 A1) – discloses to generate a benchmark (e.g., an average cost index) representative of a per unit cost of consumed resources for one or more users and/or accounts. The usage analyzer 386 may receive a total resource usage value represented as a single normalized unit associated with one or more accounts 350, resource consuming users 352, and/or machine collections 356. In some cases, the usage analyzer 386 may receive a total resource usage value that corresponds to a workload type (e.g., SPARK cluster workloads, ELASTICSEARCH workloads, data warehousing workloads, disaster recovery workloads, developer workloads, quality assurance workloads, production workloads, and/or the like), a service provider (e.g., AMAZON, MICROSOFT, GOOGLE, and/or any other service provider), a hardware provider (e.g., DELL, SUPERMICRO, HP, and/or any other hardware provider), a hardware configuration, a hypervisor (e.g., VMWARE, CITRIX, OPENSTRACK, and/or any other hypervisor), and/or a group (e.g., a business unit within an organization such as an engineering, sales, or marketing department) (see at least Paragraph 0102).
Anchi et al. (US 2022/0398038 A1) – discloses different storage performance metrics at various granularity of host groups, storage groups, storage controllers, storage devices, storage array ports etc. Third-party software like PowerPath® can be configured to obtain access to these performance metrics from Unisphere through a Representational State Transfer (REST) application programming interface (API). Some of these performance metrics include host TOPS, read/write RT, workload pattern on storage device, sequential write/read, controller metrics, and cache metrics such as read/write hit percentage, read/write randomness, read/write percentage, etc. PowerPath® multi-pathing software manages storage devices and implements load balancing policies to distribute IO using its knowledge of application IO workload and visibility of storage endpoints. PowerPath® also has a feature called Performance Metrics Insight (PMI) that provides host-side view of storage performance (see at least Paragraphs 0102-0103).
Woan et al. (US 2023/0078773 A1) – discloses machine learning techniques to identify the root cause of error conditions or poor network performance metrics detected or predicted from the streams of event data. VNA 133 may generate a notification indicative of the root cause and/or one or more remedial actions that may be taken to address the root cause of the error conditions or poor network performance metrics. In some examples, if the root cause may be automatically resolved, VNA 133 invokes one or more remedial or mitigating actions to address the root cause of the error condition or poor network performance metrics, thus automatically improving the underlying network performance metrics (e.g., one or more SLE metrics) and also automatically improving the user experience of the network (see at least Paragraph 0040).
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 nonprovisional extension fee (37 CFR 1.17(a)) 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 mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MARJORIE PUJOLS-CRUZ whose telephone number is (571)272-4668. The examiner can normally be reached Mon-Thru 7:30 AM - 5:00 PM.
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, Patricia H Munson can be reached at (571)270-5396. 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.
/M.P./Examiner, Art Unit 3624 /PATRICIA H MUNSON/Supervisory Patent Examiner, Art Unit 3624
Prosecution Insights