A cloud-based system for optimized multi-domain processing of input problems using multiple solver types

Abstract

Various embodiments of the present disclosure provide methods, apparatuses, systems, computing devices, computing entities, etc. for determining an optimized solution to an input problem in a containerized, cloud-based (e.g., serverless) manner using multiple solver types. In one embodiment, an example method includes: receiving a problem type of an input problem originating from a client computing entity; mapping the problem type to one or more selected solver types; generating one or more container instances of one or more computing containers, wherein each computing container corresponds to a selected solver type; using the one or more container instances to generate a problem output; and providing the problem output to the client computing entity, wherein the problem output includes an optimized solution to the input problem that can be used to perform one or more prediction-based actions.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This patent application claims the benefit of U.S. Provisional Patent Application No. 63 / 231,997, filed on August 11, 2021, entitled “CLOUD-BASED SYSTEMS FOR OPTIMIZED MULTI-DOMAIN PROCESSING OF INPUT PROBLEMS,” which is hereby incorporated by reference in its entirety. This patent application also claims the benefit of U.S. Patent Application No. 17 / 675,439, filed on February 18, 2022, entitled “CLOUD-BASED SYSTEMS FOR OPTIMIZED MULTI-DOMAIN PROCESSING OF INPUT PROBLEMS USING MULTIPLE SOLVER TYPES,” which is hereby incorporated by reference in its entirety. This patent application also claims the benefit of U.S. Patent Application No. 17 / 675,454, filed on February 18, 2022, entitled “CLOUD-BASED SYSTEMS FOR OPTIMIZED MULTI-DOMAIN PROCESSING OF INPUT PROBLEMS USING A SERVERLESS REQUEST MANAGEMENT ENGINE NATIVE TO A SERVERCLOUD INFRASTRUCTURE”, the entire contents of which are incorporated herein by reference. This patent application also claims the benefit of U.S. Patent Application No. 17 / 675,471, filed on February 18, 2022, entitled “CLOUD-BASED SYSTEMSFOR OPTIMIZED MULTI-DOMAIN PROCESSING OF INPUT PROBLEMS USING MACHINELEARNING SOLVER TYPE SELECTION”, the entire contents of which are incorporated herein by reference. Background Art

[0003] Various embodiments of the present disclosure solve technical challenges related to using a cloud-based system architecture to determine optimal solutions to multiple problems belonging to different problem domains. Various embodiments of the present disclosure make important technical contributions to the operational efficiency of determining optimal solutions to multiple problems and the delivery of such optimal solutions. Summary of the invention

[0004] In general, various embodiments of the present disclosure provide methods, apparatuses, systems, computing devices, computing entities, etc. for determining an optimal solution to an input problem based at least in part on the execution of one or more container instances of one or more computing containers, wherein each computing container corresponds to a solver type. Various embodiments are configured to determine an optimal solution to an input problem for various problem types, and specifically, the input problem can be a polynomial problem (P problem) or a non-deterministic polynomial problem (NP problem). In various embodiments, a cloud-based multi-domain solver system is configured to receive a type-agnostic problem solving application programming interface (API) request defining an input problem, and generate one or more container instances of one or more computing containers, each computing container corresponding to a solver type. Each container instance is executed according to the solver type to determine an optimal solution to the defined input problem. The cloud-based multi-domain solver system is then configured to provide an optimal solution to the defined input problem via a type-agnostic problem solving API response. In various embodiments, the cloud-based multi-domain solver system intelligently scales the count of executing container instances based at least in part on various factors, including the availability and consumption of computing and processing resources and the volume of type-agnostic problem solving API requests received. Thus, various embodiments provide technical advantages in flexible and resilient determination of optimized solutions to multiple input problems.

[0005] According to one aspect, a method is provided. In one embodiment, the method includes receiving a problem type of an input problem originating from a client computing entity, mapping the problem type to one or more selected solver types, and generating one or more container instances of one or more computing containers. Each computing container corresponds to the selected solver type. The method also includes generating a problem output using the one or more container instances and providing the problem output to the client computing entity. The problem output includes an optimized solution to the input problem, wherein the problem output can be used to perform one or more prediction-based actions.

[0006] In various embodiments, mapping a problem type to one or more selected solver types includes: determining a solver domain based at least in part on the problem type of the input problem and one or more problem features of the input problem; identifying a set of domain-by-domain solver types associated with the solver domain; and determining the one or more selected solver types from the set of domain-by-domain solver types. In various embodiments, the problem type of the input problem and the one or more problem features of the input problem are received via a type-agnostic problem solving application programming interface API request, and the problem output is provided to the client computing entity via a type-agnostic problem solving API response. In various embodiments, the type-agnostic problem solving API request includes a plurality of static fields, each of which is configured to describe problem features across different problem types. In various embodiments, determining the selected solver type from a set of domain-by-domain solver types includes providing one or more problem features of the input problem to a solver selection machine learning model for the problem type, the model being configured to determine the selected solver type from a set of domain-by-domain solver types based at least in part on the problem features of the input problem.

[0007] In various embodiments, the problem type of the input problem is received at a serverless request management engine that is local to a server cloud infrastructure and corresponds to one of one or more availability zones. In various embodiments, wherein the one or more container instances are managed by a serverless container management engine that is local to the server cloud infrastructure. The serverless container management engine is configured to scale the total count of container instances based at least in part on the total count of the selected solver type. wherein an inbound problem queue is updated to identify the input problem, and the serverless container management engine is configured to scale the total count of container instances for the one or more selected solver types based at least in part on the number of problems identified by the inbound problem queue.

[0008] In various embodiments, generating a problem output includes receiving one or more container outputs generated based at least in part on execution of the one or more container instances; and generating the problem output based at least in part on the one or more container outputs. In various embodiments, execution of each container instance is monitored during each execution iteration, and execution of the container instance is paused if a per-iteration optimization gain of an execution iteration fails to satisfy a configurable per-iteration optimization gain threshold. Execution of the container instance is configured to generate container outputs in parallel for each of the one or more problems identified by the inbound problem queue.

[0009] According to another aspect, a cloud-based system is provided. The cloud-based system includes one or more processors and one or more memory storage areas, and the one or more memory storage areas are configured to be dynamically allocated in a serverless manner. In one embodiment, the cloud-based system is configured to receive a problem type of an input problem originating from a client computing entity, map the problem type to one or more selected solver types, and generate one or more container instances of one or more computing containers. Each computing container corresponds to the selected solver type. The cloud-based system is also configured to use the one or more container instances to generate a problem output and provide the problem output to the client computing entity. The problem output includes an optimized solution to the input problem, wherein the problem output can be used to perform one or more prediction-based actions.

[0010] According to another aspect, a computer program product is provided. The computer program product includes at least one non-transitory computer-readable storage medium having a computer-readable program code portion stored therein. The computer-readable program code portion is configured to receive a problem type of an input problem originating from a client computing entity, map the problem type to one or more selected solver types, and generate one or more container instances of one or more computing containers. Each computing container corresponds to a selected solver type. The computer-readable program code portion is also configured to generate a problem output using the one or more container instances and provide the problem output to the client computing entity. The problem output includes an optimized solution to the input problem, wherein the problem output can be used to perform one or more prediction-based actions.

[0011] According to another aspect, a computer-implemented method, cloud-based system, and computer program product involve processing including the following steps: receiving a problem type of an input problem originating from a client computing entity; mapping the problem type to one or more selected solver types; generating one or more container instances of one or more computation containers, each corresponding to a selected solver type; using the one or more container instances to generate a problem output; and providing the problem output to the client computing entity. The problem output includes an optimized solution to the input problem, wherein the problem output can be used to perform one or more prediction-based actions.

[0012] In various alternative embodiments, mapping a problem type to one or more selected solver types includes: determining a solver domain based at least in part on the problem type of the input problem and one or more problem features of the input problem; identifying a set of domain-by-domain solver types associated with the solver domain; and determining the one or more selected solver types from the set of domain-by-domain solver types. The problem type of the input problem and the one or more problem features of the input problem may be received via a type-agnostic problem solving application programming interface API request, in which case the problem output may be provided to the client computing entity via a type-agnostic problem solving API response. The type-agnostic problem solving API request may include a plurality of static fields, each of which is configured to describe problem features across different problem types. Determining the selected solver type from a set of domain-by-domain solver types may include providing the one or more problem features of the input problem to a solver selection machine learning model for the problem type, the solver selection machine learning model being configured to determine the selected solver type from a set of domain-by-domain solver types based at least in part on the problem features of the input problem. The problem type of the input problem can be received at a serverless request management engine that is local to the server cloud infrastructure and corresponds to one of the one or more availability zones. One or more container instances can be managed by a serverless container management engine that is local to the server cloud infrastructure. The serverless container management engine can be configured to scale the total count of container instances based at least in part on the total count of the selected solver type. The inbound problem queue can be updated to identify the input problem, in which case the serverless container management engine can be configured to scale the total count of container instances for one or more selected solver types based at least in part on the number of problems identified by the inbound problem queue. Generating a problem output can include receiving one or more container outputs generated at least in part based on the execution of one or more container instances, and generating a problem output based at least in part on the one or more container outputs. The processing can also include monitoring the execution of each container instance during each execution iteration, and pausing the execution of the container instance if the per-iteration optimization gain of the execution iteration fails to meet a configurable per-iteration optimization gain threshold. The execution of the container instance can be configured to generate a container output in parallel for each of the one or more problems identified by the inbound problem queue.

[0013] Additional implementations may be disclosed and claimed. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] The patent or application file contains at least one drawing printed in color. Copies of this patent or patent application publication with color drawing(s) will be provided by the Office upon request and payment of the necessary fee.

[0015] Having thus generally described the present disclosure, reference will now be made to the accompanying drawings, which are not necessarily drawn to scale, and in which:

[0016] Figure 1 Provides an exemplary overview of a system architecture that can be used to practice embodiments of the present disclosure according to some embodiments discussed herein;

[0017] Figure 2 An example cloud computing server computing entity according to some embodiments discussed herein is provided;

[0018] Figure 3 An example client computing entity according to some embodiments discussed herein is provided;

[0019] Figure 4 A flowchart of an example process for determining an optimized solution to an input problem requested by a client computing entity according to some embodiments discussed herein is provided;

[0020] FIG. 5A to FIG. 5B A block diagram of a cloud computing server computing entity according to some embodiments discussed herein is provided;

[0021] Figure 6 A flowchart of an example process for mapping an input problem to one or more selected solver types according to some implementations discussed herein is provided;

[0022] Figure 7 A flowchart of an example process for generating a question output for an input question based at least in part on the execution of one or more container instances according to some implementations discussed herein is provided;

[0023] Figure 8 An example of the operation of a predictive output user interface according to some embodiments discussed herein is provided;

[0024] Fig. 9 It runs through Figures 10 to 18 legend of the symbols used;

[0025] Fig.10 is a schematic diagram showing details of a cloud-based multi-domain solver system 101 according to various embodiments;

[0026] Fig.11 It shows Fig.10 A schematic diagram of additional details of a cloud-based multi-domain solver system 101, and specifically shows how the various components are logically and physically interconnected in a cloud deployment environment;

[0027] Fig. 12A It is shown Fig.11 A schematic diagram of the details of the request service block;

[0028] Fig. 12B is a schematic diagram showing two request service instances running in separate availability zones within a container;

[0029] Fig.13A It is shown Fig.11 A schematic diagram of the details of the response (solver) service block;

[0030] Fig. 13B is a schematic diagram showing multiple generated solver instances running in availability zones within a container;

[0031] Fig. 13C is a schematic diagram showing Elastic Load Balancing for running independent copies of each application stack in two availability zones;

[0032] Fig.13D is a schematic diagram showing an active / standby proxy with Amazon EFS storage;

[0033] Fig.14 It is shown Fig.11 Schematic diagram of the details of the response (solver) preprocessor block;

[0034] Fig.15 It shows that according to Fig.11 A schematic diagram of the details of the REST API of the implementation method;

[0035] Fig.16 is a schematic diagram showing how multiple domain-specific client computing entities can access a constraint scheduler via a common REST API;

[0036] Fig.17 is a schematic diagram illustrating a distance service used by a VRP solver according to certain embodiments; and

[0037] Fig.18 is a flow chart illustrating the progression of a solver transaction according to certain embodiments. DETAILED DESCRIPTION

[0038] Various embodiments of the present disclosure are described more fully below with reference to the accompanying drawings, in which some but not all embodiments of the present disclosure are shown. In fact, the present disclosure can be implemented in many different forms and should not be construed as limited to the embodiments set forth herein; on the contrary, these embodiments are provided so that the present disclosure will satisfy applicable legal requirements. Unless otherwise indicated, the term "or" is used herein in an alternative and joint sense. The terms "illustrative" and "exemplary" are used as examples without indicating a level of quality. The same numbers throughout the text represent the same elements. In addition, although certain embodiments of the present disclosure are described with reference to predictive data analysis, a person of ordinary skill in the art will recognize that the disclosed concepts can be used to perform other types of data analysis. As used herein, the terms "data entity" and "data structure" can be used interchangeably.

[0039] I. General Overview and Technical Advantages

[0040] Various embodiments of the present disclosure generally relate to determining an optimal solution to an input problem in a containerized, cloud-based (e.g., serverless) manner. Specifically, determining the optimal solution to the input problem is based at least in part on the execution of one or more container instances of one or more computing containers, each computing container corresponding to a solver type. The container instance is executed in a serverless manner in a cloud-based multi-domain solver system. That is, computing and processing resources can be recruited for executing container instances on demand. Therefore, various embodiments of the present invention provide technical advantages by enabling flexible and elastic determination of optimal solutions for a certain amount of input problems. In various example instances, for specific input problems with priorities, computing and processing resources can be transferred, allocated, reserved, etc., and when the amount of input problems is low, computing and processing resources can be saved. Therefore, the cloud-based and serverless determination of the optimal solution to the input problem in various embodiments of the present disclosure leads to efficient, flexible and elastic use of computing and processing resources, which further translates into saving time and real-world costs.

[0041] In various embodiments, an optimal solution to an input problem is determined based at least in part on the execution of a container instance or an instantiation of a computation container. A computation container may be understood as a containerization or packaging of computer executable instructions for determining an optimal solution to an input problem according to a specific solver type (e.g., a specific algorithm, a specific heuristic), and may include additional data (e.g., libraries, dependency data) required to determine the optimal solution. Various embodiments of the present disclosure relate to the use of computation containers for various or a group of solver types, and the containerization of various solver types provides various technical advantages. In particular, the use of computation containers enables flexibility and scalability because multiple container instances of a computation container can be executed substantially in parallel without excessive consumption of computing and processing resources. In addition, different container instances of a computation container may be executed to determine an optimal solution for different input problems, thereby enabling efficient response and processing of multiple input problems.

[0042] II. Exemplary Definitions of Certain Terms

[0043] The term "input problem" may refer to and describe a data construct configured to describe a defined problem provided to a cloud-based multi-domain solver system for solving. That is, the input problem may be accompanied by or may embody a request for an optimized solution to the input problem. In various embodiments, the input problem is a constrained optimization problem, and the input problem may be solved by an optimization or optimal solution that satisfies various defined constraints. The input problem may define various constraints and other problem features (e.g., problem type, assets to be optimized, parameters / attributes / characteristics of each asset, optimization gain threshold, maximum execution iteration count). Examples of input problems discussed herein and that are constrained optimization problems include the traveling salesman problem (finding an optimized solution as a path of minimum distance between multiple locations) and the asset scheduling / distribution problem (finding an optimized solution as a scheduling and / or distribution of assets to different locations and / or times). The input problem may be a polynomial problem that can be solved by a polynomial time algorithm, or a non-deterministic polynomial problem that can be solved by checking the correctness of various solutions in polynomial time.

[0044] The term "problem type" may refer to and describe a data construct that is configured to describe a classification of an input problem and that may be determined by problem characteristics of the input problem (e.g., based on characteristics provided by an end user of a client computing entity). In various embodiments, the problem type of an input problem may be defined as the problem characteristics of the input problem. In general, the problem type may describe the purpose of the problem, examples of which include determining a path of minimum distance (a path-finding problem type, such as a traveling salesman problem) or determining an investment distribution of maximum return (an asset distribution problem type, such as an investment problem). In various cases, the problem type may describe or characterize the solution required for the input problem. In various embodiments, the problem type of a problem may be described using embeddings, probabilities, one-hot encodings, associated or linked data objects, and the like.

[0045] The expression "type-agnostic problem solving application programming interface (API) request" may refer to and describe a data construct configured to describe a communication between a client computing entity and a cloud-based multi-domain solver system requesting a solution to an input problem. In various embodiments, the cloud-based multi-domain solver system includes a type-agnostic problem API, and receives a type-agnostic problem solving API request originating from a client computing entity via the type-agnostic problem solving API. The type-agnostic problem solving API request may have a standardized configuration, such that each type-agnostic problem solving API request received by the cloud-based multi-domain solver system includes various data fields in a specific configuration, each data field defining data with a specific meaning. In various embodiments, the type-agnostic problem solving API request may be defined as a data structure, a data object, and the like, such as a vector, an array, or a matrix. The type-agnostic problem solving API request is type-agnostic in that the type-agnostic problem solving API request may be used to define an input problem of any problem type. That is, the type-agnostic problem solving API request includes various static data fields and various dynamic data fields, which may be used to define an input problem of any problem type to be solved by the cloud-based multi-domain solver system. In various embodiments, one or more dynamic data fields may be conditional or dependent on the problem type of the input problem. For example, one or more dynamic data fields may be used to define an input problem that is a traveling salesman problem and / or substantially similar to a traveling salesman problem, while the same dynamic data fields may not be used to define an asset allocation problem and / or another input problem that is substantially similar to an asset allocation problem. In some embodiments, the problem type of the input problem defined by a type-agnostic problem solving API request is described by a specific static data field of the type-agnostic problem solving API request. In various instances, multiple type-agnostic problem solving API requests may be received by a cloud-based multi-domain solver system, and the multiple type-agnostic problem solving API requests may each originate from a different client computing entity that communicates with the cloud-based multi-domain solver system. Multiple type-agnostic problem solving API requests may be received simultaneously and / or substantially simultaneously.

[0046] The term "inbound problem queue" may refer to and describe a data store, data construct, data structure, data object, matrix, array, vector, etc. that identifies and / or describes a plurality of input problems to be solved by a cloud-based multi-domain solver system. In various instances, a cloud-based multi-domain solver system may receive a plurality of type-agnostic problem solving API requests, and an inbound problem queue may organize the input problems described by the type-agnostic problem solving API requests. In various embodiments, the inbound problem queue may organize a plurality of input problems with different priorities, such that, for example, another input problem may be solved before a particular input problem is processed. In some embodiments, the inbound problem queue may organize the various input problems based at least in part on the time at which the corresponding type-agnostic problem solving API request is received by the cloud-based multi-domain solver system. In some embodiments, the inbound problem queue may be configured to individually define each input problem (including various problem features) to be solved. In other embodiments, the inbound problem queue may be configured to identify, link to, reference, etc. each input problem and / or associated type-agnostic problem solving API request.

[0047] The term "solver type" may refer to and describe a data construct configured to describe a type of algorithm, heuristic, method, etc. for solving a problem or for determining a solution to a problem, wherein the type may be determined based at least in part on the problem type of the corresponding problem. It is understood that a plurality of different solver types may be used to determine a solution to an input problem, each solver type providing a solution with a different accuracy and a different efficiency. With reference to the traveling salesman input problem as an illustrative example, a brute force solver type, a first fit solver type, a strongest fit solver type, a tabu search solver type, a simulated annealing solver type, a late acceptance solver type, a hill climbing solver type, a strategic oscillation solver type, etc. may be used to determine a solution. For polynomial problems, various solver types may describe algorithms, heuristics, methods, etc. for solving an input problem or determining an exact solution to a problem. For non-deterministic polynomial problems, various solver types may describe algorithms, heuristics, methods, etc. for determining a proposed solution to the input problem and for determining the "correctness" or accuracy of a proposed solution to the input problem.

[0048] The term "solver domain" may refer to and describe a data construct that is configured to describe common characteristics of a set of solver types. For example, in some embodiments, the solver type may be "truck dispatch" and the solver domain may be "dispatch". In some embodiments, a solver domain may be associated with a set of domain-by-domain solver types based at least in part on the optimization solutions determined by the respective domain-by-domain solver types. The optimization solutions determined by the respective domain-by-domain solver types are similar in form and may be applied to solve input problems of a problem type. Thus, a problem type may be mapped to a solver domain to identify a set of domain-by-domain solver types that may be used to solve the input problems of the problem type. As an example, a solver domain may be associated with a set of domain solver types that are each directed to finding an optimized path.

[0049] The term "computation container" may refer to and describe a data construct that is configured to describe an instantiable package, bundle, image, etc. of computer executable instructions. According to various embodiments, the computation container includes computer executable instructions for determining a specific solver type of a solution to an input problem. That is, the computation container corresponding to the solver type may electronically embody and / or implement the solver type. The computation container may further include various libraries, dependency data, etc. required to embody and / or implement the solver type. The computation container may include a constraint mapper that is configured to identify problem constraints and ensure that the determined solution satisfies the problem constraints of the input problem during optimization. The computation container can be instantiated within a cloud-based multi-domain solver system as a container instance that consumes computing and processing resources individually on demand. Computation containers can be defined using various systems, methods, architectures, etc. such as Docker.

[0050] The term "container instance" may refer to and describe a data construct configured to describe an instantiation of a computation container, which involves the execution of computer executable instructions defined by the computation container. Multiple container instances for a computation container may be executed substantially in parallel; that is, a computation container may be instantiated more than once. The container instance may be executed within a cloud-based multi-domain solver system and thus use computing and processing resources on demand. The cloud-based multi-domain solver system may include container instances corresponding to different computation containers of different solver types for determining solutions to different problems in parallel and / or substantially simultaneously. In various embodiments, various container instances of a computation container may be used to determine solutions to different input problems. For example, for a computation container of a simulated annealing solver type, a first container instance may be executed to determine a solution to a first traveling salesman input problem, and a second container instance may be executed to determine a solution to a second traveling salesman input problem. Therefore, it should be understood that the different solver types containerization provides various technical advantages for a computation container that can be instantiated multiple times in different container instances, in that solutions to multiple input problems may be determined in parallel by multiple container instances and / or multiple competing solutions to an input problem may be determined in parallel by multiple container instances. The count of container instances of a compute container may be scaled up and / or down, which also provides technical advantages in improved management and use of computing and processing resources within a cloud-based multi-domain solver system.

[0051] Execution of the container instance may involve determining a solution to the input problem using various problem features (e.g., parameters, values, constraints) of the input problem, and such problem features may be retrieved, received, etc. from an inbound problem queue, a type-agnostic problem solving API request defining the input problem, and / or a storage subsystem of a cloud-based multi-domain solver system. Execution of the container instance may occur over multiple execution iterations to iteratively determine and improve a solution to the input problem according to various solver types of the compute containers associated with the container instance. For example, for various solver types, the compute container may use previously determined solutions from previous execution iterations when determining subsequent solutions in subsequent execution iterations.

[0052] The term "per-iteration optimization gain" may refer to and describe a data construct configured to describe a measure of convergence or near correctness of a solution determined by a container instance of a computation container corresponding to a solver type. As discussed, a container instance of a computation container corresponding to a certain solver type executes to iteratively determine a solution to an input problem, and the per-iteration optimization gain may describe the difference between a first solution determined during a first execution iteration and a second solution determined during a second (and subsequent) execution iteration and / or may be a value describing the difference. In various instances, such as for non-deterministic polynomial problems, the per-iteration optimization gain may describe the improvement (or degradation) in the correctness of the second solution compared to the first solution. In various embodiments, the per-iteration optimization gain during the execution of the container instance is compared to a configurable gain threshold, and if the per-iteration optimization gain does not meet the configurable gain threshold, the execution of the container instance is paused or canceled. For example, if the difference between two consecutive solutions determined by the container instance is small and less than a configurable gain threshold, it may be determined that the solution determined by the container instance has converged. In such an example, the execution of the container instance may be paused, and the last solution determined by the container instance may be provided as a container output. Likewise, if the difference between two consecutive solutions determined by the container instance increases and is greater than a configurable gain threshold, then the solution determined by the container instance may be determined to be divergent. In such an instance, in various embodiments, execution of the container instance may be paused and / or terminated, and computing and processing resources may be transferred to other container instances. In various embodiments, the configurable gain threshold may be defined as an attribute or parameter of a solver type, an attribute or parameter of a computation container corresponding to the solver type, and / or an attribute or parameter of a container instance of a computation container. The configurable gain threshold may be additionally or alternatively defined as a problem feature of an input feature.

[0053] The term "serverless container management engine" may refer to a data entity configured to manage the execution of container instances of compute containers, each compute container corresponding to a solver type within a cloud-based multi-domain solver system. In doing so, the serverless container management engine may monitor the execution of the container instances. In various embodiments, the serverless container management engine is configured to determine a per-iteration optimization gain of a solution determined by the container instance at each execution iteration, and is configured to pause and / or terminate the execution of the container instance based at least in part on comparing the per-iteration optimization gain to one or more configurable gain thresholds. Typically, the serverless container management engine is configured to scale (up or down) the count of container instances based at least in part on various factors, including the per-iteration optimization gain mentioned previously. For example, the serverless container management engine can reduce the count of currently and concurrently executing container instances within the cloud-based multi-domain solver system (e.g., by pausing and / or terminating some container instances) based at least in part on the availability of computing and processing resources within the cloud-based multi-domain solver system, current request demand (e.g., the count of problems identified by the inbound problem queue), the dispersion of multiple solutions to a particular input problem, etc. Similarly, for similar reasons, the serverless container management engine can increase the count of currently and concurrently executing container instances within the cloud-based multi-domain solver system. In various embodiments, the serverless container management engine is configured to generate new container instances of computing containers, and in doing so, can be configured to access data of the computing containers. Typically, the serverless container management engine can be configured to allocate, assign, distribute, etc. computing and processing resources to various container instances. Example serverless container management engines that can be used in accordance with various embodiments of the present disclosure include (but are not limited to) Amazon Web Services (AWS) Fargate and Kubernetes.

[0054] The term "computing and processing resources" may generally refer to and describe computing and processing components, such as one or more processors, memory, network interfaces, etc., and portions thereof, for processing and executing computer-executable instructions. For example, the processor, memory, and network interface of a cloud computing server computing entity may be computing and processing resources for executing container instances. For various computer-executable instructions (e.g., container instances), the use and utilization of computing and processing resources may be measured, monitored, allocated, distributed, etc. In an example where the processor is a central processing unit (CPU), CPU time may be divided and distributed among different container instances. Similarly, resource utilization or usage may include the amount of memory reserved or used by a container instance, and monitoring such resource utilization or usage may include locating potential memory leaks.

[0055] The term "outbound solution queue" may refer to and describe a data store, data construct, data structure, data object, matrix, array, vector, etc. that identifies, describes, and / or stores a plurality of problem outputs corresponding to a plurality of input problems. Each problem output of the outbound solution queue may correspond to an input problem of an inbound problem queue, and may include a solution to the corresponding input problem. In various embodiments, an input problem may be removed from the inbound problem queue in response to adding a corresponding problem output to the outbound solution queue, thereby indicating that the input problem has been processed. The outbound solution queue may organize the plurality of problem outputs based at least in part on the organization of the input problems of the inbound problem queue and / or the time at which the problem outputs are generated. In various embodiments, each problem output of the outbound solution queue is associated with and / or identified with a specific client computing entity to which the problem output should be sent.

[0056] The wording "type agnostic problem solution API response" may refer to and describe a data construct configured to describe a communication between a cloud-based multi-domain solver system and a client computing entity. Specifically, the type agnostic problem solution API response may be in response to receiving a type agnostic problem solution API request originating from a client computing entity by a cloud-based multi-domain solver system. The type agnostic problem solution API response may include a problem output, which includes a solution to an input problem defined by the type agnostic problem solution API request. The cloud-based multi-domain solver system may send multiple type agnostic problem solution API responses according to an outbound solution queue. For example, the type agnostic problem solution API response may be sent in sequence according to the organization of the problem output within the outbound solution queue. In various instances, the type agnostic problem solution API response may be asynchronous. Since solutions to different problems may require different amounts of time, the first time period between receiving a first type agnostic problem solution API request and sending a first type agnostic problem solution API response may be different from the second time period between receiving a second type agnostic problem solution API request and sending a second type agnostic problem solution API response.

[0057] The term "serverless request management engine" may refer to and describe a data entity configured to manage the receipt of type-agnostic problem solving API requests and the sending of type-agnostic problem solution API responses within a cloud-based multi-domain solver system. The serverless request management engine may be serverless because the receipt and processing of type-agnostic problem solving API requests and the sending of type-agnostic problem solution API responses may consume a dynamic or variable amount of computing and processing resources. At the serverless request management engine, multiple type-agnostic problem solving API requests may be received simultaneously and / or over a period of time, and the serverless request management engine may communicate with an inbound problem queue for processing (e.g., determining solutions) input problems defined by the multiple type-agnostic problem solving API requests. At the same time, the serverless request management engine is configured to communicate with an outbound solution queue to obtain problem solutions corresponding to the input problems defined by the multiple type-agnostic problem solving API requests. The serverless request management engine may generate multiple type-agnostic problem solution API responses including problem outputs from the outbound solution queue and send them to the multiple type-agnostic problem solving API requests. In various embodiments, the cloud-based multi-domain solver system includes one or more serverless request management engines, each serverless request management engine corresponding to an availability zone and configured to handle communications with a specific group of client computing entities, communications within a specific time period, communications with client computing entities located in a specific region, etc. The use of one or more serverless request management engines advantageously allows communications (e.g., receiving type agnostic problem solving API requests, sending type agnostic problem solving API responses) to be efficiently handled between a large number of client computing entities with minimal latency.

[0058] III. Computer Program Products, Methods and Computing Entities

[0059] Embodiments of the present invention can be implemented in various ways, including as a computer program product including a product. Such a computer program product may include one or more software components, including, for example, software objects, methods, data structures, etc. The software components may be encoded in any of a variety of programming languages. The illustrative programming language may be a lower-level programming language, such as an assembly language associated with a specific hardware architecture and / or operating system platform. Software components including assembly language instructions may need to be converted into executable machine code by an assembler before being executed by the hardware architecture and / or platform. Another example programming language may be a high-level programming language that can be carried across a variety of architectures. Software components including high-level programming language instructions may need to be converted into an intermediate representation by an interpreter or compiler before execution.

[0060] Other examples of programming languages ​​include, but are not limited to, macro languages, shell or command languages, job control languages, scripting languages, database query or search languages, and / or report writing languages. In one or more example embodiments, a software component comprising instructions in one of the aforementioned examples of a programming language can be directly executed by an operating system or other software component without first being converted into another form. The software component can be stored as a file or other data storage structure. Software components of similar type or functional relevance can be stored together, for example, in a specific directory, folder, or library. The software component can be static (e.g., pre-established or fixed) or dynamic (e.g., created or modified during execution).

[0061] A computer program product may include a non-transitory computer-readable storage medium storing an application, program, program module, script, source code, program code, object code, byte code, compiled code, interpreted code, machine code, executable instructions, etc. (also referred to herein as executable instructions, instructions for execution, computer program product, program code, and / or similar terms used interchangeably herein). Such non-transitory computer-readable storage media include all computer-readable media (including volatile and non-volatile media).

[0062] In one embodiment, the non-volatile computer-readable storage medium may include a floppy disk, a flexible disk, a hard disk, a solid-state storage (SSS) (e.g., a solid-state drive (SSD), a solid-state card (SSC), a solid-state module (SSM), an enterprise flash drive, a magnetic tape, or any other non-transitory magnetic medium, etc.). The non-volatile computer-readable storage medium may also include a punch card, a paper tape, an optical marker sheet (or any other physical medium with a hole pattern or other optically recognizable marker), a compact disk read-only memory (CD-ROM), a rewritable compact disk (CD-RW), a digital versatile disk (DVD), a Blu-ray disk (BD), any other non-transitory optical medium, etc. Such non-volatile computer-readable storage media may also include a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a flash memory (e.g., serial, NAND, NOR, and / or the like), a multimedia memory card (MMC), a secure digital (SD) memory card, a smart media card, a compact flash (CF) card, a memory stick, and / or the like. In addition, the non-volatile computer-readable storage medium may also include conductive bridging random access memory (CBRAM), phase change random access memory (PRAM), ferroelectric random access memory (FeRAM), non-volatile random access memory (NVRAM), magnetoresistive random access memory (MRAM), resistive random access memory (RRAM), silicon-oxide-nitride-oxide-silicon memory (SONOS), floating junction gate random access memory (FJG RAM), ultra-high density (Millipede) memory, racetrack memory and / or the like.

[0063] In one embodiment, the volatile computer-readable storage medium may include random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), fast page mode dynamic random access memory (FPM DRAM), extended data output dynamic random access memory (EDO DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), double data rate type two synchronous dynamic random access memory (DDR2 SDRAM), double data rate type three synchronous dynamic random access memory (DDR3 SDRAM), memory bus dynamic random access memory (RDRAM), two-transistor RAM (TTRAM), thyristor RAM (T-RAM), zero capacitor (Z-RAM), memory bus in-line memory module (RIMM), dual in-line memory module (DIMM), single in-line memory module (SIMM), video random access memory (VRAM), cache memory (including various levels), flash memory, register memory and / or the like. It should be appreciated that where embodiments are described as using computer-readable storage media, other types of computer-readable storage media may be used in place of or in addition to the computer-readable storage media described above.

[0064] It should be understood that various embodiments of the present invention may also be implemented as methods, apparatuses, systems, computing devices, computing entities, etc. Thus, embodiments of the present invention may take the form of apparatuses, systems, computing devices, computing entities, etc. that execute instructions stored on a computer-readable storage medium to perform certain steps or operations. Therefore, embodiments of the present invention may also take the form of an entirely hardware embodiment, an entirely computer program product embodiment, and / or an embodiment that includes a combination of a computer program product and hardware that performs certain steps or operations.

[0065] Embodiments of the present invention are described below with reference to block diagrams and flow charts. Therefore, it should be understood that each frame illustrated in the block diagram and flow chart can be implemented in the form of a device, system, computing device, computing entity, etc. for execution with instructions, operations, steps and similar words (e.g., executable instructions, instructions for execution, program codes, etc.) that can be used interchangeably on a computer program product, a complete hardware implementation, a combination of hardware and a computer program product, and / or on a computer-readable storage medium. For example, the acquisition, loading and execution of the code can be performed in sequence so that an instruction is acquired, loaded and executed at one time. In some exemplary embodiments, acquisition, loading and / or execution can be performed in parallel so that multiple instructions are acquired, loaded and / or executed together. Therefore, these embodiments can produce a machine that performs a specific configuration of the steps or operations specified in the block diagram and flow chart. Therefore, the block diagram and flow chart illustrate various combinations of embodiments for executing specified instructions, operations or steps.

[0066] Embodiments of the present disclosure may be implemented in various ways, including as a computer program product including a product. Such a computer program product may include one or more software components, including, for example, software objects, methods, data structures, etc. The software components may be encoded in any of a variety of programming languages. The illustrative programming language may be a lower-level programming language, such as an assembly language associated with a specific hardware architecture and / or operating system platform. Software components including assembly language instructions may need to be converted into executable machine code by an assembler before being executed by a hardware framework and / or platform. Another example programming language may be a high-level programming language that is portable across multiple frameworks. Software components including high-level programming language instructions may need to be converted into an intermediate representation by an interpreter or compiler before execution.

[0067] Other examples of programming languages ​​include, but are not limited to, macro languages, shell or command languages, job control languages, scripting languages, database query or search languages, and / or report writing languages. In one or more embodiments, a software component comprising an instruction in one of the aforementioned examples of a programming language can be directly executed by an operating system or other software component without first being converted into another form. A software component can be stored as a file or other data storage structure. Software components of similar type or functional relevance can be stored together in, for example, a specific directory, folder, or library. A software component can be static (e.g., pre-established or fixed) or dynamic (e.g., created or modified when executed).

[0068] A computer program product may include a non-transitory computer-readable storage medium storing an application, program, program module, script, source code, program code, object code, byte code, compiled code, interpreted code, machine code, executable instructions, etc. (also referred to herein as executable instructions, instructions for execution, computer program product, program code, and / or similar terms used interchangeably herein). Such non-transitory computer-readable storage media include all computer-readable media (including volatile and non-volatile media).

[0069] In one embodiment, the non-volatile computer-readable storage medium may include a floppy disk, a flexible disk, a hard disk, a solid-state storage (SSS) (e.g., a solid-state drive (SSD), a solid-state card (SSC), a solid-state module (SSM), an enterprise flash drive, a magnetic tape, or any other non-transitory magnetic medium, etc.). The non-volatile computer-readable storage medium may also include a punch card, a paper tape, an optical marker sheet (or any other physical medium with a hole pattern or other optically recognizable marker), a compact disk read-only memory (CD-ROM), a rewritable compact disk (CD-RW), a digital versatile disk (DVD), a Blu-ray disk (BD), any other non-transitory optical medium, etc. Such non-volatile computer-readable storage media may also include a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a flash memory (e.g., serial, NAND, NOR, and / or the like), a multimedia memory card (MMC), a secure digital (SD) memory card, a smart media card, a compact flash (CF) card, a memory stick, and / or the like. In addition, the non-volatile computer-readable storage medium may also include conductive bridging random access memory (CBRAM), phase change random access memory (PRAM), ferroelectric random access memory (FeRAM), non-volatile random access memory (NVRAM), magnetoresistive random access memory (MRAM), resistive random access memory (RRAM), silicon-oxide-nitride-oxide-silicon memory (SONOS), floating junction gate random access memory (FJG RAM), ultra-high density (Millipede) memory, racetrack memory and / or the like.

[0070] In one embodiment, the volatile computer-readable storage medium may include random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), fast page mode dynamic random access memory (FPM DRAM), extended data output dynamic random access memory (EDO DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), double data rate type two synchronous dynamic random access memory (DDR2 SDRAM), double data rate type three synchronous dynamic random access memory (DDR3 SDRAM), memory bus dynamic random access memory (RDRAM), two-transistor RAM (TTRAM), thyristor RAM (T-RAM), zero capacitor (Z-RAM), memory bus in-line memory module (RIMM), dual in-line memory module (DIMM), single in-line memory module (SIMM), video random access memory (VRAM), cache memory (including various levels), flash memory, register memory, and / or the like. It should be appreciated that where embodiments are described as using computer-readable storage media, other types of computer-readable storage media may be used in place of or in addition to the computer-readable storage media described above.

[0071] It should be understood that various embodiments of the present disclosure may also be implemented as methods, apparatuses, systems, computing devices, computing entities, etc. Therefore, embodiments of the present disclosure may take the form of apparatuses, systems, computing devices, computing entities, etc. that execute instructions stored on a computer-readable storage medium to perform certain steps or operations. Therefore, embodiments of the present disclosure may also take the form of a complete hardware embodiment, a complete computer program product embodiment, and / or an embodiment including a combination of a computer program product and hardware that performs certain steps or operations.

[0072] The embodiments of the present disclosure are described below with reference to block diagrams and flow charts. Therefore, it should be understood that each box in the block diagram and flow chart illustration can be implemented in the form of a computer program product, a complete hardware implementation, a combination of hardware and computer program products, and / or executing interchangeable instructions, operations, steps and similar words (e.g., executable instructions, instructions for execution, program codes, etc.) on a computer-readable storage medium, in the form of a device for execution, a system, a computing device, a computing entity, etc. For example, the acquisition, loading and execution of the code can be performed in sequence so that one instruction is acquired, loaded and executed at a time. In some exemplary embodiments, acquisition, loading and / or execution can be performed in parallel so that multiple instructions are acquired, loaded and / or executed together. Therefore, these embodiments can produce a machine with a specific configuration for executing the steps or operations specified in the block diagram and flow chart. Therefore, the block diagram and flow chart illustrate various combinations of embodiments for supporting the execution of specified instructions, operations or steps.

[0073] IV. Exemplary System Architecture

[0074] Figure 1 1 is a schematic diagram of an example architecture 100 for determining an optimized solution to an input problem in a containerized, cloud-based (e.g., serverless) manner. The architecture 100 includes a cloud-based multi-domain solver system 101 configured to receive a type-agnostic problem solving API request, manage the execution of a container instance corresponding to a compute container of a solver type, the container instance determining a solution to the input problem defined by the type-agnostic problem solving API request, and providing a problem output including an optimized solution to the input problem via a type-agnostic solution API response. In various embodiments, the cloud-based multi-domain solver system 101 scales the count of executing container instances based at least in part on various factors, including the availability of computing and processing resources and the number of type-agnostic problem solving API requests received. For example, the cloud-based multi-domain solver system 101 can allocate, increase, distribute, etc. computing and processing resources to the executing container instance, and / or can limit, reduce, cut off, etc. computing and processing resources to the executing container instance.

[0075] In various embodiments, the cloud-based multi-domain solver system 101 communicates with multiple client computing entities 102 using one or more communication networks. Examples of communication networks include any wired or wireless communication network, including, for example, a wired or wireless local area network (LAN), a personal area network (PAN), a metropolitan area network (MAN), a wide area network (WAN), etc., and any hardware, software, and / or firmware required to implement it (e.g., network routers, etc.). The cloud-based multi-domain solver system 101 can receive type-agnostic problem solving API requests originating from various client computing entities 102 via such communication networks, and can also send type-agnostic problem solving API responses to various client computing entities 102 via such communication networks.

[0076] The cloud-based multi-domain solver system 101 may include a cloud computing server computing entity 106 and a storage subsystem 108. The cloud computing server computing entity 106 may be configured to execute a container instance serverlessly to determine a solution to an input problem. That is, the execution of the container instance may be completed using a variable number of computing and processing resources of the cloud computing server computing entity 106. In this regard, the cloud computing server computing entity 106 may be understood as an abstraction of one or more separate computing entities that share computing and processing resources. The cloud computing server computing entity 106 may be configured to receive and process type-agnostic problem solving API requests that define input problems. In various embodiments, the cloud computing server computing entity 106 generates and terminates a container instance (e.g., by providing and / or by removing computing and processing resources from the container instance), generates a problem output based at least in part on a container output from the container instance, and provides the problem output via a type-agnostic problem solving API response.

[0077] The storage subsystem 108 may be configured to store data used by the cloud computing server computing entity 106 to determine an optimized solution to an input problem in a containerized, cloud-based manner. For example, the storage subsystem 108 is configured to store computing containers, each of which corresponds to a solver type and is configured to be instantiated and executed as a container instance. The storage subsystem 108 may also be configured to store inbound problem queues and outbound solution queues for scheduling and communication management. The storage subsystem 108 may include one or more storage units, such as multiple distributed storage units connected by a computer network (e.g., an internal communication network of a cloud-based multi-domain solver system 101). Each storage unit in the storage subsystem 108 may store at least one of one or more data assets and / or one or more data about the characteristics of the one or more data assets being calculated. In addition, each storage unit in the storage subsystem 108 may include one or more non-volatile storage or storage media, including but not limited to a hard disk, a ROM, a PROM, an EPROM, an EEPROM, a flash memory, an MMC, an SD memory card, a memory stick, a CBRAM, a PRAM, a FeRAM, a NVRAM, an MRAM, a RRAM, a SONOS, a FJG RAM, an ultra-high density (Millipede) memory, a racetrack memory and / or the like.

[0078] Exemplary Cloud Computing Server Computing Entity

[0079] Figure 2 A schematic diagram of a cloud computing server computing entity 106 according to one embodiment of the present disclosure is provided. In general, the terms computing entity, computer, entity, device, system and / or similar terms used interchangeably herein may refer to, for example, one or more computers, computing entities, desktop computers, mobile phones, tablet computers, tablet phones (phablets), notebook computers, laptop computers, distributed systems, self-service machines, input terminals, servers or server networks, blades, gateways, switches, processing devices, processing entities, set-top boxes, repeaters, routers, network access points, base stations, etc., and / or any combination of devices or entities suitable for performing the functions, operations and / or processes described herein. These functions, operations and / or processes may include, for example, sending, receiving, operating, processing, displaying, storing, determining, creating / generating, monitoring, evaluating, comparing and / or similar terms used interchangeably herein. In one embodiment, these functions, operations and / or processes may be performed on data, content, information and / or similar terms used interchangeably herein.

[0080] As indicated, in one embodiment, the cloud computing server computing entity 106 may also include one or more communication interfaces 220 for communicating with various computing entities, such as by communicating data, content, information, and / or similar terms used interchangeably herein that may be sent, received, manipulated, processed, displayed, stored, etc. The cloud computing server computing entity 106 may communicate with multiple client computing entities 102 via the one or more communication interfaces 220, such as receiving type agnostic problem solving API requests and sending type agnostic problem solving API responses.

[0081] like Figure 2 As shown, in one embodiment, the cloud computing server computing entity 106 may include or communicate with one or more processing elements 205 (also referred to as processors, processing circuits, and / or similar terms used interchangeably herein) that communicate with other elements within the cloud computing server computing entity 106, for example via a bus. It will be appreciated that the processing element 205 may be implemented in a variety of different ways.

[0082] For example, processing element 205 may be implemented as one or more complex programmable logic devices (CPLDs), microprocessors, multi-core processors, co-processing entities, application specific instruction set processors (ASIPs), microcontrollers, and / or controllers. In addition, processing element 205 may be implemented as one or more other processing devices or circuits. The term circuit may refer to a complete hardware implementation or a combination of hardware and computer program products. Thus, processing element 205 may be implemented as an integrated circuit, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a programmable logic array (PLA), a hardware accelerator, other circuits, and / or the like.

[0083] Therefore, it can be understood that the processing element 205 can be configured for a specific purpose, or configured to execute instructions stored in a volatile or non-volatile medium, or accessible by the processing element 205. Therefore, whether configured by hardware or a computer program product or a combination thereof, the processing element 205 is capable of performing steps or operations according to embodiments of the present disclosure when configured accordingly.

[0084] In one embodiment, the cloud computing server computing entity 106 may also include or communicate with non-volatile media (also referred to as non-volatile storage, memory, memory storage, memory circuits, and / or similar terms used interchangeably herein). In one embodiment, the non-volatile storage or memory may include one or more non-volatile storage or storage media 210, including but not limited to hard disks, ROMs, PROMs, EPROMs, EEPROMs, flash memory, MMCs, SD memory cards, memory sticks, CBRAMs, PRAMs, FeRAMs, NVRAMs, MRAMs, RRAMs, SONOSs, FJG RAMs, Millipede memories, racetrack memories, and / or the like.

[0085] As will be appreciated, non-volatile storage devices or storage media may store databases, database instances, database management systems, data, applications, programs, program modules, scripts, source code, object code, byte code, compiled code, interpreted code, machine code, executable instructions, etc. The terms database, database instance, database management system, and / or similar terms used interchangeably herein may refer to a collection of records or data stored in a computer-readable storage medium using one or more database models (e.g., hierarchical database model, network model, relational model, entity-relationship model, object model, document model, semantic model, graph model, etc.).

[0086] In one embodiment, the cloud computing server computing entity 106 may also include or communicate with volatile media (also referred to as volatile storage, memory, storage, storage circuitry, and / or similar terms used interchangeably herein). In one embodiment, the volatile storage or memory may also include one or more volatile storage or storage media 215, including, but not limited to, RAM, DRAM, SRAM, FPM DRAM, EDO DRAM, SDRAM, DDR SDRAM, DDR2 SDRAM, DDR3 SDRAM, RDRAM, TTRAM, T-RAM, Z-RAM, RIMM, DIMM, SIMM, VRAM, cache memory, register memory, and / or the like.

[0087] As will be appreciated, volatile storage devices or storage media may be used to store at least a portion of a database, database instance, database management system, data, applications, programs, program modules, scripts, source code, object code, byte code, compiled code, interpreted code, machine code, executable instructions, etc., which are executed by, for example, processing element 205. Thus, databases, database instances, database management systems, data, applications, programs, program modules, scripts, source code, object code, byte code, compiled code, interpreted code, machine code, executable instructions, etc. may be used to control certain aspects of the operation of cloud computing server computing entities 106 with the assistance of processing element 205 and an operating system.

[0088] As indicated, in one embodiment, the cloud computing server computing entities 106 may also include one or more communication interfaces 220 for communicating with various computing entities, such as by communicating data, content, information, and / or similar terms used interchangeably herein that may be sent, received, manipulated, processed, displayed, stored, etc. Such communications may be performed using a wired data transmission protocol, such as Fiber Distributed Data Interface (FDDI), Digital Subscriber Line (DSL), Ethernet, Asynchronous Transfer Mode (ATM), Frame Relay, Data Over Cable Service Interface Specification (DOCSIS), or any other wired transmission protocol. Similarly, the cloud computing server computing entity 106 may be configured to communicate via a wireless external communication network using any of a variety of protocols, such as General Packet Radio Service (GPRS), Universal Mobile Telecommunications System (UMTS), Code Division Multiple Access 2000 (CDMA2000), CDMA2000 1X (1xRTT), Wideband Code Division Multiple Access (WCDMA), Global System for Mobile Communications (GSM), Enhanced Data Rates for GSM Evolution (EDGE), Time Division Synchronous Code Division Multiple Access (TD-SCDMA), Long Term Evolution (LTE), Evolved Universal Terrestrial Radio Access Network (E-UTRAN), Evolution Data Optimized (EVDO), High Speed ​​Packet Access (HSPA), High Speed ​​Downlink Packet Access (HSDPA), IEEE 802.11 (Wi-Fi), Wi-Fi Direct, 802.16 (WiMAX), Ultra Wideband (UWB), Infrared (IR) protocol, Near Field Communication (NFC) protocol, Wibree, Bluetooth protocol, Wireless Universal Serial Bus (USB) protocol, and / or any other wireless protocol.

[0089] Although not shown, the cloud computing server computing entity 106 may include or communicate with one or more input elements, such as keyboard input, mouse input, touch screen / display input, motion input, movement input, audio input, pointing device input, joystick input, keypad input, etc. The cloud computing server computing entity 106 may also include or communicate with one or more output elements (not shown), such as audio output, video output, screen / display output, motion output, movement output, etc.

[0090] Exemplary Client Computing Entity

[0091] Figure 3 An illustrative schematic diagram of a client computing entity 102 that may be used in conjunction with embodiments of the present disclosure is provided. In general, the terms device, system, computing entity, entity, and / or similar terms used interchangeably herein may refer to, for example, one or more computers, computing entities, desktop computers, mobile phones, tablet computers, phablets, notebook computers, laptop computers, distributed systems, kiosks, input terminals, servers or server networks, blades, gateways, switches, processing devices, processing entities, set-top boxes, repeaters, routers, network access points, base stations, etc., and / or any combination of devices or entities suitable for performing the functions, operations, and / or processes described herein. The client computing entity 102 may be operated by parties. As Figure 3 As shown, the client computing entity 102 may include an antenna 312, a transmitter 304 (e.g., a radio), a receiver 306 (e.g., a radio), and a processing element 308 (e.g., a CPLD, a microprocessor, a multi-core processor, a co-processing entity, an ASIP, a microcontroller, and / or a controller) that provides signals to and receives signals from the transmitter 304 and the receiver 306, respectively.

[0092] Accordingly, the signals provided to and received from the transmitter 304 and the receiver 306 may include signaling information / data in accordance with the air interface standard of the applicable wireless system. In this regard, the client computing entity 102 is capable of operating with one or more air interface standards, communication protocols, modulation types, and access types. More specifically, the client computing entity 102 may operate in accordance with any of a variety of wireless communication standards and protocols, such as those described above with respect to the cloud computing server computing entity 106. In a particular embodiment, the client computing entity 102 may operate in accordance with a variety of wireless communication standards and protocols, such as UMTS, CDMA2000, 1xRTT, WCDMA, GSM, EDGE, TD-SCDMA, LTE, E-UTRAN, EVDO, HSPA, HSDPA, Wi-Fi, Wi-Fi Direct, WiMAX, UWB, IR, NFC, Bluetooth, USB, etc. Similarly, the client computing entity 102 may operate in accordance with a plurality of wired communication standards and protocols, such as those described above with respect to the cloud computing server computing entity 106 via the network interface 320.

[0093] Via these communication standards and protocols, the client computing entity 102 may communicate with various other entities using concepts such as Unstructured Supplementary Service Data (USSD), Short Message Service (SMS), Multimedia Messaging Service (MMS), Dual Tone Multi-Frequency Signaling (DTMF), and / or Subscriber Identity Module Dialer (SIM Dialer). The client computing entity 102 may also download changes, additions, and updates to, for example, its firmware, software (e.g., including executable instructions, applications, program modules), and operating system.

[0094] According to one embodiment, the client computing entity 102 may include location determination aspects, devices, modules, functions and / or similar terms used interchangeably herein. For example, the client computing entity 102 may include outdoor positioning aspects, such as a location module suitable for obtaining, for example, latitude, longitude, altitude, geocode, heading, direction, course, speed, universal time (UTC), date and / or various other information / data. In one embodiment, the positioning module may obtain data, sometimes referred to as ephemeris data, by identifying the number of visible satellites and the relative positions of these satellites (e.g., using the Global Positioning System (GPS)). The satellites may be a variety of different satellites, including low earth orbit (LEO) satellite systems, Department of Defense (DOD) satellite systems, the European Union Galileo Positioning System, the Chinese Compass Navigation System, the Indian Regional Navigation Satellite System, etc. The data may be collected using a variety of coordinate systems, such as decimal system (DD); degrees, minutes, seconds (DMS); universal transverse Mercator (UTM); universal polar coordinate (UPS) coordinate system; and / or the like. Alternatively, the location information / data may be determined by triangulating the location of the client computing entity 102 in association with various other systems, including cellular towers, Wi-Fi access points, etc. Similarly, the client computing entity 102 may include indoor positioning aspects, such as a location module adapted to obtain, for example, latitude, longitude, altitude, geocoding, heading, direction, course, speed, time, date, and / or various other information / data. Some indoor systems may use various positioning or location technologies, including RFID tags, indoor beacons or transmitters, Wi-Fi access points, cellular towers, nearby computing devices (e.g., smart phones, laptops), and / or the like. For example, such technologies may include iBeacons, Gimbal proximity beacons, Bluetooth low energy (BLE) transmitters, NFC transmitters, etc. These indoor positioning aspects may be used in various settings to determine the location of a person or object within inches or centimeters.

[0095] The client computing entity 102 may also include a user interface (which may include a display 316 coupled to the processing element 308) and / or a user input interface (coupled to the processing element 308). For example, the user interface may be a user application, a browser, a user interface, and / or similar terms used interchangeably herein, which is executed on the client computing entity 102 and / or can be accessed via the client computing entity 102 to interact with the cloud computing server computing entity 106 and / or cause the display of information / data from the cloud computing server computing entity 106, as described herein. The user input interface may include any of a number of devices or interfaces that allow the client computing entity 102 to receive data, such as a keypad 318 (hard or soft), a touch display, a voice / speech or motion interface, or other input device. In embodiments that include a keypad 318, the keypad 318 may include (or cause to be displayed) conventional numeric (0-9) and related keys (#, *), as well as other keys for operating the client computing entity 102, and may include a full set of alphabetic keys or a set of keys that can be activated to provide a full set of alphanumeric keys. In addition to providing input, the user input interface may be used, for example, to activate or deactivate certain functions, such as a screen saver and / or a sleep mode.

[0096] The client computing entity 102 may also include embedded and / or removable volatile storage or memory 322 and / or non-volatile storage or memory 324. For example, the non-volatile memory may be ROM, PROM, EPROM, EEPROM, flash memory, MMC, SD memory card, memory stick, CBRAM, PRAM, FeRAM, NVRAM, MRAM, RRAM, SONOS, FJG RAM, Millipede memory, racetrack memory, and / or the like. The volatile memory may be RAM, DRAM, SRAM, FPM DRAM, EDO DRAM, SDRAM, DDR SDRAM, DDR2 SDRAM, DDR3 SDRAM, RDRAM, TTRAM, T-RAM, Z-RAM, RIMM, DIMM, SIMM, VRAM, cache memory, register memory, and / or the like. Volatile and non-volatile storage or memory may store databases, database instances, database management systems, data, applications, programs, program modules, scripts, source code, object code, byte code, compiled code, interpreted code, machine code, executable instructions, etc., to implement the functionality of the client computing entity 102. As indicated, this may include user applications resident on the entity or accessible through a browser or other user interface for communicating with the cloud computing server computing entity 106 and / or various other computing entities.

[0097] In another embodiment, the client computing entity 102 may include one or more components or functions that are the same or similar to the components or functions of the cloud computing server computing entity 106, as described in more detail above. As will be appreciated, these architectures and descriptions are provided for exemplary purposes only and are not limiting of the various embodiments.

[0098] In various embodiments, the client computing entity 102 may be implemented as an artificial intelligence (AI) computing entity, such as Amazon Echo, Amazon Echo Dot, Amazon Show, Google Home, etc. Accordingly, the client computing entity 102 may be configured to provide and / or receive information / data from a user via an input / output mechanism such as a display, camera, speaker, voice-activated input, etc. In certain embodiments, the AI ​​computing entity may include one or more predefined and executable program algorithms stored in an onboard memory storage module and / or accessible via a network. In various embodiments, the AI ​​computing entity may be configured to retrieve and / or execute one or more predetermined program algorithms upon the occurrence of a predetermined triggering event.

[0099] V. Exemplary System Operation

[0100] As described below, various embodiments of the present disclosure describe techniques for determining an optimized solution to an input problem based at least in part on serverless execution of one or more container instances of one or more computing containers that each correspond to a solver type. For example, various embodiments of the present disclosure provide techniques for generating and managing one or more container instances to generate problem outputs. The techniques involve efficient use of computing and processing resources that can be dynamically allocated to different container instances based at least in part on various factors (e.g., availability of resources, total capacity of input problems, execution progress, solution optimization gain). This in turn reduces the total operational load on a cloud-based multi-domain solver system according to various embodiments and increases its operational efficiency and reliability.

[0101] Figure 4 A flow chart of an example process 400 for determining an optimal solution to an input problem in a containerized, cloud-based (e.g., serverless) manner is provided. In various embodiments, the cloud computing server computing entity 106 includes means for performing the steps / operations of the process 400, such as one or more processing elements 205, one or more memories 210, 215, network interfaces, etc.

[0102] As illustrated, process 400 includes step / operation 401. In one embodiment, process 400 begins and / or is triggered by step / operation 401. Step / operation 401 includes receiving a problem type of an input problem originating from a client computing entity 102. In various embodiments, the problem type of the input problem may be received via a type agnostic problem solving API request. In various embodiments, the cloud-based multi-domain solver system 101 includes a type agnostic problem solving API, and receives a type agnostic problem solving API request originating from a client computing entity 102 via the type agnostic problem solving API.

[0103] In various embodiments, the type-agnostic problem solving API request indicates the problem type of the input problem and other problem characteristics of the input problem. The type-agnostic problem solving API request can have a standardized configuration so that each type-agnostic problem solving API request received by the cloud-based multi-domain solver system includes various data fields in a specific configuration, and each data field defines data with a specific meaning. In various embodiments, the type-agnostic problem solving API request can be defined as a data structure, a data object, etc., such as a vector, an array, or a matrix. The type-agnostic problem solving API request is type-agnostic in that the type-agnostic problem solving API request can be used to define an input problem of any problem type. That is, the type-agnostic problem solving API request can include various static data fields and various dynamic data fields, which can be used to define an input problem of any problem type solved by the cloud-based multi-domain solver system. In various embodiments, one or more dynamic data fields can be conditional or dependent on the problem type of the input problem. For example, one or more dynamic data fields may be used for an input problem defined as a traveling salesman problem or one substantially similar to the traveling salesman problem, while the same dynamic data fields may not be used for an input problem defined as an asset allocation problem or another input problem substantially similar to the asset allocation problem. In some embodiments, the problem type of an input problem defined by a type-agnostic problem solving API request is described by a specific static data field of the type-agnostic problem solving API request.

[0104] In various implementations, the cloud-based multi-domain solver system 101 includes a request management engine that communicates with and / or includes a type agnostic question API. Figure 5AAn example block diagram of a cloud computing server computing entity 106 including a request management engine 502 is shown. The request management engine 502 is configured to receive, process, handle, and / or similarly resolve type agnostic problem API requests originating from various client computing entities 102. In various embodiments, the request management engine 502 receives a type agnostic problem solving API request via a type agnostic problem API and validates the type agnostic problem solving API request. The request management engine 502 may further extract problem features of an input problem defined by the type agnostic problem solving API request and, for example, identify a problem type of the input problem defined by the type agnostic problem solving API request.

[0105] In various embodiments, the cloud computing server computing entity 106 includes one or more request management engines 502, each of which is configured to receive and process requests from, for example, Figure 5B 102. The type-agnostic problem solving API requests of various client computing entities 102 are shown. In such an embodiment, each request management engine 502 may correspond to availability zones 510A to 510B. Availability zones 510A to 510B describe the scope of responsibility of the corresponding request management engine 502. For example, a first request management engine 502A corresponding to a first availability zone 510A may be configured to receive and process type-agnostic problem solving API requests originating from a first group of client computing entities 102, and a second request management engine 502B corresponding to a second availability zone 510B may be configured to receive and process type-agnostic problem solving API requests originating from a second group of client computing entities 102. As another example, the use of the request management engines 502 of different availability zones 510A-510B can be based at least in part on demand, where a second request management engine 502B corresponding to a second availability zone 510B is configured to receive and process type-agnostic problem solving API requests when a first request management engine 502A corresponding to a first availability zone 510A consumes a threshold amount of computing and processing resources when receiving and processing type-agnostic problem solving API requests. Thus, using more than one request management engine 502 and dividing the request management engine 502 between different availability zones 510A-510B advantageously provides for efficient and flexible use of computing and processing resources.

[0106] In various embodiments, the request management engine 502 communicates with an inbound question queue 506. The inbound question queue 506 is configured to identify and / or describe a plurality of input problems to be solved by the cloud-based multi-domain solver system 101. In various examples, the request management engine 502 may receive a plurality of type-agnostic problem solving API requests, and the request management engine 502 may cause the plurality of input problems defined by the plurality of type-agnostic problem solving API requests to be identified and / or described by the inbound question queue 506. In various embodiments, the input problems may be organized within the inbound question queue 506, such as in a first-in, first-out (FIFO) manner.

[0107] Step / operation 402 includes mapping a problem type of the input problem to one or more selected solver types. As previously described, the problem type of the input problem describes the classification of the input problem and can be determined by the problem characteristics of the input problem. Generally, the problem type can describe the purpose of the problem, examples of which include determining a path of minimum distance (a path finding problem type, such as a traveling salesman problem) or determining an investment distribution with maximum return (an asset distribution problem type, such as an investment problem). In various cases, the problem type can describe or characterize the solution required for the input problem.

[0108] While a problem type may describe or characterize a desired solution to an input problem, a solver type describes an algorithm, heuristic, method, etc., used to determine a solution to a problem. In various embodiments, the cloud computing server computing entity 106 hosts, stores, accesses, etc., various solver types, each of which determines various solutions to various problems. The various solver types may be identified by a library or database of solver types that identifies the various solver types, and may describe the inputs, outputs, required parameters, calculations or algorithms, etc., of the various solver types. The various solver types may include solver types that are best applied or can only be applied to certain problems, and therefore, the cloud computing server computing entity 106 maps the problem type to one or more selected solver types.

[0109] Specifically, in some embodiments, mapping a problem type to one or more selected solver types is embodied in Figure 6 In the example steps / operations shown. That is, Figure 6 A flow chart is provided that illustrates an example process as an example implementation of step / operation 402. In various implementations, the cloud computing server computing entity 106 includes means for performing the steps / operations of process 600, such as one or more processing elements 205, one or more memories 210, 215, network interfaces, and the like.

[0110] At step / operation 601 of process 600, a solver domain is determined based at least in part on the problem type of the input problem and one or more problem features of the input problem. The solver domain describes the common features of a set of solver types. Specifically, the solver domain can be associated with a set of domain-by-domain solver types based at least in part on the optimization solutions determined by each domain-by-domain solver type. The optimization solutions determined by each domain-by-domain solver type are similar in form and can be applied to solve the input problem for the problem type. Therefore, a solver domain is determined to identify a set of domain-by-domain solver types that can be used to solve the input problem of the problem type and applied to the input problem. As an example, a solver domain can be associated with a set of domain solver types that each involve finding an optimization path.

[0111] Thus, step / operation 602 includes identifying a set of individual domain solver types corresponding to a solver domain. In various embodiments, each domain-by-domain solver type is associated with a unique identifier, and the solver domain is generated to include various identifiers for the domain-by-domain solver types. As an example, a solver domain that identifies individual domain solver types applicable to an input problem of a path-finding problem type may include an identifier for a brute force solver type, an identifier for a simulated annealing solver type, an identifier for a Dijkstra solver type, an identifier for a hill climbing solver type, and the like.

[0112] In step / operation 603, one or more selected solver types are then determined from a set of domain-by-domain solver types. One or more selected solver types may be domain-by-domain solver types that have relatively good performance metrics, resource usage requirements, etc. compared to other domain-by-domain solver types. As an example, one or more selected solver types are determined based at least in part on having low resource usage requirements (e.g., linear or low-order computational complexity) compared to a resource usage threshold. The resource usage threshold may be determined at least in part based on the amount of input problems in the inbound problem queue 506, and thus, the selected solver type may be determined at least in part based on the amount of input problems that need to be solved. Thus, at least using these steps / operations, the problem type of the input problem may be mapped to one or more selected solver types. In various embodiments, the mapping between the input problem and the one or more selected solver types is stored and used to train and configure a solver selection machine learning model. The solver selection machine learning (ML) model is configured (e.g., trained) to intelligently and automatically determine the selected solver type for the input problem. In certain exemplary embodiments described below, ML-based solver type selection is performed by a solver pre-processor.

[0113] In various embodiments, the inbound question queue 506 is configured to identify and describe the selected solver type after determining the selected solver type. For example, within the inbound question queue 506, an input question can be associated with one or more selected solver types that are determined to be mapped to the problem type of the input question. Therefore, the inbound question queue 506 in various embodiments advantageously stores comprehensive and complete information for each input question. Using the inbound question queue 506, the selected solver type mapped to the input question can be quickly identified, eliminating the need to search and / or obtain the selected solver type from other memory storage areas. By quickly identifying the selected solver type mapped to a specific input question, wherein each solver type can be associated with a certain indication of resource requirements, this is more advantageous in quickly and efficiently determining the estimated amount of computing and processing resources required for handling a specific input problem.

[0114] return Figure 4 , step / operation 403 includes generating one or more container instances of one or more compute containers, each compute container corresponding to the selected solver type. A compute container describes an instantiable package, bundle, image, etc. of computer executable instructions and / or additional data (e.g., data sets, databases, dependency data) required to execute the computer executable instructions. Since the compute container does not require standard and repetitive data (e.g., operating system), the compute container is advantageously lightweight at least with respect to memory storage. Since all required data for instantiation and execution of the compute container is encapsulated within the compute container, the compute container is further advantageous in being independent and does not require data retrieval and communication with other data modules, databases, data engines, etc.

[0115] In various embodiments, the computation container is configured to determine a solution to an input problem according to a solver type (e.g., an algorithm, heuristic, method). That is, the computation container corresponding to the solver type can electronically embody and / or implement the solver type. For example, a first computation container corresponding to a brute force solver type is configured to, when instantiated and executed, generate and test all possible solutions to the input problem to determine an optimized solution, while a second computation container corresponding to a taboo search solver type is configured to, when instantiated and executed, test similar solutions to a particular solution and evaluate improvements in the optimization of similar solutions to determine an optimized solution. Using each computation container corresponding to a solver type, the computation container can be uniquely identified (e.g., via various global or universal identifiers) and can be stored in a data store, a data set, a database, etc. with other computation containers. The computation container can also define a constraint mapper that is configured to identify problem constraints of the input problem and ensure that the determined solution satisfies various problem constraints during optimization.

[0116] Computational containers are instantiated as container instances within the cloud-based multi-domain solver system 101, and the container instances consume computing and processing resources individually on demand. That is, a container instance is defined as an instantiation of a computing container. When a container instance is generated, the container instance can be configured to start execution automatically and in an independent manner. The execution of the container instance consumes a certain amount of computing and processing resources, and these resources can be appropriately allocated and distributed between one or more container instances. In various embodiments, the minimum amount of computing and processing resources required to execute a container instance of a particular computing container can be a parameter of the definition and description of the particular computing container, and the container instance can be generated when at least the minimum amount of computing and processing resources required for execution is available.

[0117] The generation and execution of container instances may be managed by one or more container management engines 504 of the cloud computing server computing entity 106, such as Figure 5A and Figure 5B As shown. In various embodiments, the container management engine 504 is configured to generate a container instance of a computing container and dynamically allocate the amount of computing and processing resources to execute the container instance. As part of the dynamic allocation of computing and processing resources between one or more container instances, the container management engine 504 is configured to monitor the use and allocation of computing and processing resources of the cloud computing server computing entity 106, and reallocate such resources between container instances when deemed necessary. Similarly, the container management engine 504 is configured to monitor the available number of computing and processing resources, and if the available number of computing and processing resources meets the minimum number of computing and processing resources required to execute the container instance, a container instance is generated. In various embodiments, the container management engine 504 also does not allocate excessive computing and processing resources to the container instance, and the amount of computing and processing resources allocated to the container instance can be limited by one or more configurable thresholds or limits. A person skilled in the art of the present disclosure will think of various further changes in container instantiation. For example, dynamically generate one or more container instances of computing containers over time. In the example of an input problem that maps to five solver types, container instances of two solver types may be generated first (eg, due to limited availability of computational and processing resources), with container instances of the remaining three solver types generated at a subsequent point in time.

[0118] like Figure 5BAs shown, the cloud computing server computing entity 106 may include one or more container management engines 504, each container management engine corresponds to an availability zone 510, and each container management engine is configured to manage the generation and execution of container instances for input problems received in the corresponding availability zone 510. In addition, the computing and processing resources of the cloud computing server computing entity 106 may be divided or partitioned between multiple availability zones 510, and the container management engine 504 is configured to allocate the computing and processing resources for the corresponding availability zone 510 to the generation and execution of container instances. In the illustrated embodiment, the cloud computing server computing entity 106 includes a first container management engine 504A corresponding to the first availability zone 510A and a second container management engine 504B corresponding to the second availability zone 510B.

[0119] One or more container instances are generated (e.g., via the container management engine 504) based at least in part on the inbound problem queue 506. Specifically, the inbound problem queue 506 can indicate that a particular input problem is ready to be processed, and can communicate with the container management engine 504 to generate a container instance of one or more computation containers, each computation container corresponding to a selected solver type mapped to the particular input problem. In some embodiments, each input problem identified by the inbound problem queue 506 is associated with a state, one such state being a "ready" state. While communicating with the inbound problem queue 506, the container management engine 504 can receive or obtain problem characteristics of the input problem, including various parameters, values, and data related to the input problem, and can provide such problem characteristics to the container instance when generated. Thus, once the container instance is generated, it is configured to determine an optimized solution to the input problem.

[0120] As previously described, the container instance can be configured to automatically begin execution when generated, and can be provided with the problem features required to determine the optimized solution for a particular input problem. In various embodiments, the container instance includes a heartbeat API that is used to indicate that the container instance is currently being used to determine the optimized solution for the input problem (e.g., the container instance is "valid"). In various embodiments, the container instance communicates with the container management engine 504 and / or the inbound problem queue 506 via the heartbeat API to notify the container management engine 504 and / or the inbound problem queue 506 that the container instance is "alive" and is executing. During the execution of at least one container instance of a particular input problem, the state associated with the particular input problem at the inbound problem queue 506 can be configured as a "processing", "disposing", or the like state.

[0121] Thus, using step / operation 403, one or more container instances are generated, and each container instance is executed to determine an optimized solution to the input problem. At step / operation 404, the one or more container instances are then used to generate a problem output. The problem output may include an optimized solution generated based at least in part on the execution of the one or more container instances.

[0122] In some embodiments, by using container instances to determine the optimal solution, various embodiments of the present disclosure are generally directed to determining the optimal solution of an input problem in a containerized, cloud-based (e.g., serverless) manner. Specifically, determining the optimal solution of the input problem is based at least in part on the execution of one or more container instances of one or more computing containers, each computing container corresponding to a solver type. The container instance is executed in a serverless manner in a cloud-based multi-domain solver system. That is, computing and processing resources can be recruited for executing container instances on demand. Therefore, various embodiments of the present invention provide technical advantages by enabling the optimal solution of a certain amount of input problems to be determined flexibly and elastically. In various example instances, for specific input problems with priority, computing and processing resources can be transferred, allocated, reserved, etc., and when the amount of input problems is low, computing and processing resources can be saved. Therefore, the cloud-based and serverless determination of the optimal solution of the input problem in various embodiments of the present disclosure leads to efficient, flexible and elastic use of computing and processing resources, which further translates into saving time and real-world costs.

[0123] In some embodiments, the generation of the question output is performed by Figure 7 The steps / operations shown are implemented. Figure 7 An example implementation for generating a question output (eg, step / operation 404 ) is shown.

[0124] In step / operation 701, for each execution iteration, the execution of each container instance is monitored. The execution of the container instances associated with various solver types is performed on multiple execution iterations that may be interdependent. At each execution iteration, the container instance can determine a proposed solution, and each proposed solution can be based at least in part on a previously determined solution from a previous execution iteration. Similarly, at each execution iteration, the container instance can determine a per-iteration optimization gain as a measure of convergence or near-optimization. The per-iteration optimization gain compares the determined solution with a previously determined solution (e.g., the most recent solution). In some embodiments, the container instance is configured to output a per-iteration optimization gain as an indication of the progress of the container instance toward the optimization of the solution. For example, the per-iteration optimization gain can be provided via the heartbeat API of the container instance. Therefore, the cloud computing server computing entity 106 (e.g., via the container management engine 504) can monitor the execution of the container instance and its progress.

[0125] In various embodiments, monitoring the execution of the container instance includes monitoring the amount of computing and processing resources allocated to and / or consumed by the container instance. When monitoring resource usage and utilization of the container instance, usage data associated with multiple time points can be collected and analyzed. In various embodiments, the usage data includes dedicated processing time (e.g., the portion of the total time spent by one or more processors processing the container instance), memory size (e.g., the amount of volatile and / or non-volatile memory storage reserved and used by the container instance), etc.

[0126] Step / operation 702 includes pausing execution of the container instance if the per-iteration optimization gain of the execution iteration fails to meet a configurable per-iteration optimization gain threshold. As previously described, the per-iteration optimization gain of the execution iteration indicates progress toward optimization of the container instance. In some cases, the solution determined by the container instance may diverge, resulting in an unsatisfactory per-iteration optimization gain. It will be appreciated that the divergence of the solution generally indicates that the optimization solution cannot be determined (e.g., it is impossible to reconverge), and therefore in order to avoid wasting computing and processing resources for the container instance, the execution of the container instance can be suspended. Various configurable per-iteration optimization gain thresholds can be further based at least in part on resource usage and utilization of the container instance. For example, the container instance can be paused when the optimization gain does not change or improve per iteration while resource usage and utilization increase.

[0127] In some embodiments, the suspension of execution of the container instance is caused via the heartbeat API of the container instance. For example, the container instance may receive a pause, cancel, terminate, and / or similar command originating from the container management engine 504 via the heartbeat API. In some embodiments, the container instance is configured to automatically suspend execution in response to one or more unsatisfactory per-iteration optimization gains, and a final heartbeat message indicating the suspension of execution may be sent via the heartbeat API. In various embodiments, the container instance may be suspended, aborted, destroyed, terminated, etc. by limiting or stopping the allocation of computing and processing resources to the container instance. Computing and processing resources may be actively de-allocated from the container instance (e.g., by the container management engine 504) to other container instances.

[0128] Step / operation 703 includes receiving one or more container outputs generated based at least in part on the execution of one or more container instances. The container instance provides a container output when the execution is complete, which can also be determined using a per-iteration optimization gain. For example, the per-iteration optimization gain can be evaluated to determine whether progress toward optimization is sufficiently complete. Additionally or alternatively, the solution can be tested for absolute correctness for some problem types of input problems. In any aspect, the container output provided by the container instance can include an optimized solution for the input problem. The container output can also include convergence data (e.g., per-iteration optimization gain for each execution iteration), iteration data (e.g., the number of execution iterations performed), etc.

[0129] Step / operation 704 includes generating a problem output based at least in part on one or more container outputs. In various instances, the input problem is mapped to multiple solver types, and multiple container outputs can be received from multiple container instances. Therefore, multiple container outputs can be aggregated and compared to generate a problem output. For example, the problem output can include a best-fit optimization solution of multiple optimization solutions from multiple container outputs. As an alternative example, the problem output can include an average solution of multiple optimization solutions of multiple container outputs. In various embodiments, the problem output includes additional data, such as performance metrics of multiple solver types mapped to the input problem. That is, the problem output can describe whether any container instance of the solver type is paused, the average number of execution iterations performed by the container instance of the solver type, etc. Such performance metrics of each solver type can be used later to map the solver type to the problem type, such as by training and configuring the solver selection machine learning model about which solver types (if any) are paused.

[0130] The generation of problem output can include updating Figure 5A and Figure 5B The outbound solution queue 508 is shown to identify (e.g., a question output). Since multiple input questions can be received with a time period and a question output is determined for each input question, the outbound solution queue 508 is configured to identify (e.g., store) more than one question output. The outbound solution queue 508 can also store a status associated with each question output, and the question output can be added to the outbound solution queue 508 along with a "ready to return", "ready to send", and / or similar status. At the same time, adding the question output to the outbound solution queue 508 can include updating the inbound question queue 506. For example, the input question in the inbound question queue 506 can be updated to a "completed" status and / or removed from the inbound question queue 506.

[0131] The generation of the problem output may also include narrowing down the container instance used to determine the optimized solution to the input problem. As the problem output is generated to solve and dispose of the input problem, it is no longer necessary to execute the container instance to determine the optimized solution to the input problem, and such container instance may be paused, suspended, and / or terminated. In some embodiments, some container instances may be redirected to determine the optimized solution to another input problem identified by the inbound problem queue 506, and the problem features of the input problem may be received and / or obtained from the inbound problem queue 506 accordingly. However, in some cases, another input problem may be unavailable, and in the absence of an input problem to determine a solution, the container instance may be terminated. Therefore, the count of the container instances in execution is flexible and is based at least in part on the amount of input problems in the inbound problem queue 506.

[0132] return Figure 4 , step / operation 405 includes providing a problem output to the client computing entity 102. As described above, the problem output may include an optimized solution to the input problem. In various embodiments, in response to a type-agnostic problem solving API request (e.g., received in step / operation 401), the problem output is provided to the client computing entity 102 via a type-agnostic problem solution API response. The type-agnostic problem solution API response is used to provide solutions to different input problems of different problem types. The problem output may additionally be configured to be provided via a display of the client computing entity 102.

[0133] In various embodiments, the problem output is provided to the client computing entity 102 via the request management engine 502. The problem output can be provided specifically via the request management engine 502 corresponding to the availability zone 510A-510B in which the type-agnostic problem solving API request is received. When providing the problem output, the request management engine 502 is configured to communicate with the outbound solution queue 508 (e.g., receive or obtain at least the optimized solution from the outbound solution queue 508). After providing the problem output, the outbound solution queue 508 can be updated, specifically, the problem solution in the outbound solution queue 508 is deleted.

[0134] Thus, various steps, operations, methods, processes, etc. for determining an optimized solution to an input problem in a containerized, cloud-based (e.g., serverless) manner are described herein. In an example implementation, a type-agnostic problem solving API request is received from a client computing entity 102. The type-agnostic problem solving API request is processed (e.g., validated), and the input problem defined by the type-agnostic problem solving API is added to an inbound problem queue 506 (e.g., by a request management engine 502). The container management engine 504 is notified of the input problem via the inbound problem queue 506, and one or more container instances are generated, each container instance being associated with a solver type mapped to the input problem (e.g., by the request management engine 502). Execution of the one or more container instances results in the generation of a problem output, which can be an aggregate, a combination, or based at least in part on various optimized solutions determined according to various solver types. The problem output is added to an outbound solution queue 508, and the input problem is removed from the inbound problem queue 506. The problem output is then provided to the client computing entity 102 via a type agnostic problem solving API response (eg, via the request management engine 502 ).

[0135] The various embodiments described herein provide various technical advantages by allowing for flexible and elastic determination of optimal solutions to the amount of input problems. In various example instances, for specific input problems with priorities, computing and processing resources can be transferred, allocated, reserved, etc., and when the amount of input problems is low, computing and processing resources can be saved. Therefore, the cloud-based and serverless determination of the optimal solution to the input problem in the various embodiments of the present disclosure leads to efficient, flexible and elastic use of computing and processing resources, which further translates into saving time and real-world costs. In addition, the use of computing containers of various solver types achieves flexibility and scalability because multiple container instances of the computing container can be executed substantially in parallel without excessive consumption of computing and processing resources. The container instance of the computing container can be executed to determine the optimal solution for different input problems, thereby enabling efficient response and processing of multiple input problems.

[0136] In some embodiments, the prediction outputs may be used (e.g., by a client computing entity) to perform one or more prediction-based actions. Examples of prediction-based actions include automatic scheduling, automatic generation of notifications, automatic load balancing operations for a network / system (e.g., for a transaction network such as a freight network), etc. In some embodiments, performing the prediction-based actions includes generating a prediction output user interface that displays one or more prediction outputs. Examples of such prediction output user interface operations are Figure 8 The prediction output user interface 800. Figure 8As shown, forecast output user interface 800 depicts a recommended load delivery plan for a truck identified by text box 801 , where the recommended load delivery plan may be determined based at least in part on one or more forecast outputs.

[0137] VI. Exemplary Implementations

[0138] Now refer to Figures 9 to 18 Some specific implementations of a cloud-based, multi-domain solver system 101 (sometimes referred to herein as a "constraint optimizer" or "optimized scheduler") are described. The solver system 101 is a constraint-based planning tool that addresses key problems faced by asset-intensive organizations, such as activity scheduling. Using optimization algorithms, limited resources are accounted for under varying constraints, and efficient solutions are provided that optimize industrial planning objectives. This can help reduce costs and increase efficiency by removing complexity and manual processes from typical planning (e.g., scheduling) exercises. Exemplary embodiments are configured for use in applications provided by Infor (US), LLC, and Intergraph Corporation. TM Industries and capabilities supported by an enterprise asset management (EAM) system, but it should be noted that embodiments may be configured for more general use across various systems. In one exemplary embodiment, two industries are supported, namely Maintenance Field Service (MFS) and Asset Investment Planning (AIP), where for Maintenance Field Service, an embodiment may generate a full-day schedule and route sequence based on available activities and resources such as crews or personnel traveling to static equipment locations to perform various planned activities, and for Asset Investment Planning, an embodiment may generate an asset investment action plan for a given planning scope, budget, and list of assets / projects to be maintained.

[0139] Fig. 9 It runs through Figures 10 to 18Legend for symbols used. It should be noted that many of these symbols refer to products or services from other vendors used in certain embodiments, and any such references are intended to refer to such products or services using their respective trademarks as adjectives and along with the appropriate trademark symbol (e.g., (R) versus (TM)), whether used without the trademark symbol or with the incorrect trademark symbol. For example, Amazon, AWS, EC2, S3, EventBridge, MQ, and DynamoDB are considered trademarks or registered trademarks of Amazon.com, Inc. or its affiliates in the United States and / or other countries, and references to such products and services should be construed as references to the corresponding products or services using their respective trademarks as adjectives and along with the appropriate trademark symbol. It should also be noted that in many cases, alternative products or services from other sources may be used in various alternative embodiments (e.g., different cloud services, different database services, different communication protocols, etc.).

[0140] Fig.10 1 is a schematic diagram showing details of a cloud-based multi-domain solver system 101 according to various embodiments. Among them, the cloud-based multi-domain solver system 101 includes a request service 1002, a response (solver) service (sometimes referred to as "solver" in this article) 1004, and a response (solver) preprocessor (sometimes referred to as "preprocessor" in this article) 1006. The solver 1004 is called by various scheduler (domain) plug-ins, which are microservices that can be embedded in various applications. All of these components are discussed in more detail below.

[0141] Fig.11 It shows Fig.10 1 is a schematic diagram of additional details of a cloud-based multi-domain solver system 101 , and specifically illustrates how the various components are logically and physically interconnected within a cloud deployment environment.

[0142] Among them, the solver system 101 includes a constraint optimizer provisioning API 1008, which authenticates the client of the system. Specifically, when the system receives a specific customer ID for the first time, the customer ID is verified via the provisioning API and persisted in the database, and then each time a solve request transaction is received from the customer, the system can confirm that the customer is valid and can use the solver service.

[0143] Constraint Scheduler Request Service 1002 is wrapped in the Infor TM Docker running in the cloud TMThe main responsibility of the request service 1002 is to handle web service requests from various client computing entities 1010 via a common constraint scheduler API, which in this embodiment is a REST API discussed in more detail below. The request service 1002 is also responsible for spawning instances of solvers 1004 as requests are added to the inbound queue. The system can run multiple instances of the request service 1002, for example, in different availability zones (e.g., two instances of the request service 1002).

[0144] Fig. 12A It is shown Fig.11 A schematic diagram of the details of the request service 1002 block. Fig. 12B 1004 generates a solution and places it on the outbound queue, the solution listener of the request service 1002 returns the solution to the client.

[0145] The constraint scheduler solver 1004 is packaged in the Infor TM Docker running in the cloud TM Microservices in containers. The system can generate separate instances of solver 1004 so that there is no need to have a persistent presence running in the cloud (e.g., constraint scheduler instances can be stateless). Constraint scheduling solver 1004 is responsible for pulling requests from the inbound queue, creating solutions, and pushing solutions to the outbound queue. Instances of solver 1004 are dynamically created by the scaling algorithm of request service 1002. Solver 1004 is also responsible for shrinking instances that are no longer needed. When a solver 1004 instance completes a solution, it attempts to pull another request from the queue. If it cannot pull a request within a predetermined time period, it will destroy the instance and remove the Fargate container.

[0146] Fig.13A It is shown Fig.11 A schematic diagram of the details of the Response (Resolver) Service 1004 block. Fig. 13B1 is a schematic diagram showing multiple spawned solver 1004 instances running in an availability zone in a container. The components of the solver 1004 include a request listener that pulls requests from an inbound queue and spawns solver 1004 instances, a solver engine / controller and constraint mapper for each instance, an abstraction layer through which solutions running Java Message Service (JMS) and Spring Data Redistribution (SDR) are pushed to an outbound queue, and a logger.

[0147] As mentioned above, the solver 1004 instance is stateless in this exemplary embodiment. All state information is maintained in the cloud management component with redundancy. The queue ensures that the request is processed before being removed. The system is designed to be fault-tolerant so that it can keep running even if some components in the system fail.

[0148] In order to deploy applications in multiple availability zones (AZs), each AWS region is a collection of data centers logically grouped into availability zones (AZs). AWS regions provide multiple (usually three) physically separated and isolated availability zones, which are connected with low latency, high throughput and highly redundant networks. Each AZ includes one or more physical data centers. Availability zones are designed for physical redundancy and provide resilience, so that uninterrupted performance can be achieved even in the case of power outages, Internet shutdowns, floods and other natural disasters. Elastic Load Balancing (ELB) is used to provide improved fault tolerance because the ELB service automatically balances the business flows of multiple instances across multiple availability zones, thereby ensuring that only "healthy" instances receive business flows. The system preferably runs independent copies of each application stack in two or more availability zones and routes automatic business flows to healthy resources. If a loss of availability, a loss of network connectivity, a computer unit failure, or a storage failure occurs in one region, multi-AZ deployment mitigates application failures. Fig. 13C is a diagram illustrating Elastic Load Balancing for running independent copies of various application stacks in two Availability Zones. In some embodiments, multi-AZ deployments are enabled on the Redis replication group. Whether or not multi-AZ is enabled, failed primary nodes are automatically detected and replaced. However, how this occurs varies based on whether or not multi-AZ is enabled. For example, when multi-AZ is enabled, ElastiCache detects a primary node failure and promotes a read replica node with minimal replication lag to the primary node, the other replica nodes synchronize with the new primary node, ElastiCache rotates read replicas in the AZ of the failed primary node, and the new nodes synchronize with the newly promoted primary node. Failover to a replica node is typically faster than creating and provisioning a new primary node, which allows solver applications to resume writes to your primary node faster than if multi-AZ is not enabled.

[0149] In some embodiments, the active / standby broker includes two brokers in two different availability zones configured as a redundant pair. These brokers communicate synchronously with the solver application and with Amazon EFS (broker storage). Typically, only one broker instance is active at any time, while the other broker instance is standby. If one of the broker instances fails or undergoes maintenance, AmazonMQ takes a short time to suspend the inactive instance. This allows the healthy standby instance to become active and begin accepting incoming communications. When you restart the broker, failover takes only seconds. Fig.13D is a diagram showing an active / standby proxy with Amazon EFS storage.

[0150] The Spring JMS Session in the resolver is configured to use transactional acknowledgement mode for messages. If the resolver application crashes for any reason, the ActiveMQ server redelivers the request message. This prevents any request message from being lost in case of an instance crash. The Spring JMS Session can be configured to: set "sessionAcknowledgeMode" to "AUTO_ACKNOWLEDGE" (default) for automatic message acknowledgement before listener execution without redelivery if an exception is thrown; set "sessionAcknowledgeMode" to "CLIENT_ACKNOWLEDGE" for automatic message acknowledgement after a successful listener execution without redelivery if an exception is thrown; set "sessionAcknowledgeMode" to "DUPS_OK_ACKNOWLEDGE" for lazy message acknowledgement during or after listener execution with potential redelivery if an exception is thrown, or set "sessionTransacted" to "true" for transactional acknowledgement after a successful listener execution and guaranteed redelivery if an exception is thrown.

[0151] As described above, in various embodiments, determining the selected solver type from a set of domain-by-domain solver types includes providing one or more problem features of an input problem to a solver selection machine learning model for the problem type, the solver selection machine learning model being configured to determine the selected solver type from a set of domain-by-domain solver types based at least in part on the problem features of the input problem. Figure 10 to Figure 11 In the context of , this functionality is performed by the response (solver) preprocessor 1006 through the scheduler solver domain including the machine learning algorithm model builder and the machine learning algorithm selector.

[0152] Fig.14It is shown Fig.11 Schematic diagram of the details of the response (solver) preprocessor 1006 block. As described above, the wording "solver type" can refer to and describe a data construct that is configured to describe the type of algorithm, heuristic, method, etc. used to solve a problem or to determine the solution of a problem, wherein the type can be determined at least in part based on the problem type of the corresponding problem. It will be understood that a plurality of different solver types can be used to determine the solution to the input problem, each solver type providing a solution with different accuracy and different efficiency. With reference to the traveling salesman input problem as an illustrative example, a brute force solver type, a first fit solver type, a strongest fit solver type, a taboo search solver type, a simulated annealing solver type, a late acceptance solver type, a hill climbing solver type, a strategic oscillation solver type, etc. can be used to determine the solution. For polynomial problems, various solver types can describe algorithms, heuristics, methods, etc. used to solve the input problem or determine the exact solution to the problem. For non-deterministic polynomial problems, various solver types may describe algorithms, heuristics, methods, etc., for determining proposed solutions to an input problem and for determining the "correctness" or accuracy of proposed solutions to the input problem.

[0153] Refer again Fig.10 , the Algorithm Model Creator runs periodically to generate a solver type model from the analysis in DynamoDB and stores the model in the S3 cloud. The ML algorithm selector loads the model from the S3 cloud into storage. The request service verifies the request and places it on the inbound queue, marking the request for preprocessing. The queue selector filters requests that need preprocessing and redirects these requests to the solver preprocessor. The solver preprocessor issues a request to the ML algorithm selector to select an algorithm, removes the original request from the queue, and pushes the updated request back to the queue with the preprocessing tag turned off. In general, the algorithm selector analyzes the request to determine the type of problem involved (e.g., a vehicle routing problem), and assuming that multiple solver type models are available for the requested problem, the ML algorithm selector selects the best model based on various constraints. The solver pulls the request from the queue, generates a solution, and pushes the solution to the outbound queue. The solver records the analysis in DynamoDB for future model creation.

[0154] exist Fig.11In the illustrated embodiment, a domain-specific client computing entity (client) 1010 accesses the constraint-optimized scheduler via a multi-domain Representational State Transfer (REST) ​​API, which is preferably configured to allow multiple different domain-specific client computing entities to be added to or removed from the system in a plug-and-play manner, for example, as support for new domains is added to the system.

[0155] Fig.15 It shows that according to Fig.11 A schematic diagram of the details of a REST API of an embodiment of the present invention. Different domain-specific client computing entities may utilize different parameters, and the REST API allows such domain-specific client computing entities to utilize the common API by transmitting domain-specific information to the constraint-optimized scheduler when making requests in a stateless manner (e.g., using JSON or other suitable representation format).

[0156] Fig.16 is a schematic diagram showing how multiple domain-specific client computing entities can access the solver system via a public REST API. In this example, there is an EAM group member scheduling plug-in client, an EAM asset investment plug-in client, and space for adding future plug-in clients. The REST API provides an extensible API that allows new functionality to be added without breaking backward compatibility. It uses JSON, a lightweight data exchange format that is easy for humans to read and write, and easy for machines to parse and generate. The API is based on the open API specification. The REST API is associated with different specifications and properties for different domains, which allows clients to use only APIs with the domains they need, and allows the solver system to send responses with domain-specific information to the client.

[0157] In some embodiments, the REST API includes four primitives, namely, a POST / solve primitive for sending a request to a solver, a GET / solution / {id} primitive for requesting an identified solution, a GET / status / {id} primitive for requesting the status of an identified scheduler execution, and a POST / cancel / {id} primitive for canceling an identified solver execution.

[0158] The client sends a solve request to the solver system. The request is a POST, and because some requests are expected to be long running, the response must be delivered asynchronously. The data payload of the solve request contains static fields for activities and mediators, and also contains dynamic fields for scheduler type and period. Using both static and dynamic fields allows the API to be easily extensible. The static field concept means that fields cannot be changed to avoid breaking backward compatibility. However, they can be extended by adding optional fields to existing objects. The dynamic field concept means that fields can be changed and extended without breaking backward compatibility. This can be done by creating a new schema and adding it as a new option for dynamic fields. All dynamic fields must contain an id to be referenced by other json objects.

[0159] The system provides responses to the client through a similar callback API. The solve method body has two main JSON schemas, assigned activities and unassigned activities. Assigned activities are activities that the solver was able to successfully assign, and unassigned activities cannot be assigned by the solver. The schema is extensible to implement additional capabilities.

[0160] Solving the vehicle routing problem (VRP) and other applications may require access to distance information, such as for determining an appropriate route for a theoretical traveling salesman problem. Thus, the system may include a generic distance service through which distance and map information (e.g., OpenStreetMap information) may be obtained. Fig.17 is a schematic diagram showing a distance service used by a VRP solver according to certain embodiments. The distance service utilizes the GraphHopper routing service integrated with OpenStreetMap data and other data. The system can use any of a variety of distance algorithms, such as Dijkstra, A*, landmarks, and contraction hierarchies, and can include scheduling for any of a variety of transportation modes, such as walking, car, bicycle, and public transportation.

[0161] Fig.18 is a flow chart illustrating the progression of a solver transaction according to certain embodiments. A client (plugin) sends a request to a request service via a REST API, which authenticates the client and, assuming the client is authenticated, validates the request and pushes the request to an inbound queue. The solver pulls the request from the inbound queue, solves the request, and pushes the solution to an outbound queue. Throughout the process, the solver updates state information, e.g., to indicate when the solver is processing a request and when the solver has completed a request. The response service pulls the solution from the outbound queue and sends the solution to the client via a callback API.

[0162] VII. Potential Claims

[0163] Various embodiments of the present invention are characterized by potential claims listed in the paragraphs following this paragraph (and before the actual claims provided at the end of this application). These potential claims form part of the written description of this application. Therefore, the subject matter of the following potential claims may be presented as actual claims in subsequent proceedings involving this application or any application claiming priority based on this application. The inclusion of these potential claims should not be interpreted as meaning that the actual claims do not cover the subject matter of the possible claims. Therefore, a decision not to raise these possible claims in subsequent proceedings should not be interpreted as donating the subject matter to the public. These potential claims are also not intended to limit the various claims pursued.

[0164] Without limitation, potential subject matter that may be claimed (prefaced with the letter "P" to avoid confusion with the actual claims set forth below) includes:

[0165] P1. A computer-implemented method, the method comprising the following steps: using one or more processors to receive a problem type of an input problem originating from a client computing entity; using the one or more processors to map the problem type to one or more selected solver types; using the one or more processors to generate one or more container instances of one or more computing containers, each computing container corresponding to the selected solver type; using the one or more processors, using the one or more container instances to generate a problem output; and using the one or more processors to provide the problem output to the client computing entity, the problem output including an optimized solution to the input problem, wherein the problem output can be used to perform one or more prediction-based actions.

[0166] P2. A computer-implemented method according to claim P1, wherein the step of mapping the problem type to one or more selected solver types includes: determining a solver domain based at least in part on the problem type of the input problem and one or more problem characteristics of the input problem; identifying a set of domain-by-domain solver types associated with the solver domain; and determining the one or more selected solver types from the set of domain-by-domain solver types.

[0167] P3. A computer-implemented method according to claim P2, wherein the question type of the input question and the one or more question features of the input question are received via a type-agnostic problem solving application programming interface (API) request, and wherein the question output is provided to the client computing entity via a type-agnostic problem solving API response.

[0168] P4. A computer-implemented method according to claim P3, wherein the type-agnostic problem solving API request includes multiple static fields, each static field being configured to describe problem characteristics across different problem types.

[0169] P5. A computer-implemented method according to claim P2, wherein the step of determining the selected solver type from the set of domain-by-domain solver types includes: providing one or more problem features of the input problem to a solver selection machine learning model for the problem type, and the solver selection machine learning model is configured to determine the selected solver type from the set of domain-by-domain solver types based at least in part on the problem features of the input problem.

[0170] P6. A computer-implemented method according to claim P1, wherein the question type of the input question is received at a serverless request management engine, which is local to the server cloud infrastructure and corresponds to one of one or more availability zones.

[0171] P7. A computer-implemented method according to claim P1, wherein the one or more container instances are managed by a serverless container management engine that is local to the server cloud infrastructure.

[0172] P8. A computer-implemented method according to claim P7, wherein the serverless container management engine is configured to scale the total count of container instances based at least in part on the total count of the selected solver type.

[0173] P9. A computer-implemented method according to claim P7, wherein an inbound problem queue is updated to identify the input problem, and wherein the serverless container management engine is configured to scale the total count of container instances for the one or more selected solver types based at least in part on the number of problems identified by the inbound problem queue.

[0174] P10. A computer-implemented method according to claim P1, wherein the step of generating the problem output includes: receiving one or more container outputs generated at least in part based on the execution of the one or more container instances; and generating the problem output based at least in part on the one or more container outputs.

[0175] P11. According to the computer-implemented method described in claim P1, the method also includes: monitoring the execution of each container instance during each execution iteration, and pausing the execution of the container instance if the per-iteration optimization gain of the execution iteration fails to meet a configurable per-iteration optimization gain threshold.

[0176] P12. The computer-implemented method of claim 1, wherein execution of the container instance is configured to generate container outputs in parallel for each of the one or more issues identified by the inbound issue queue.

[0177] P13. A cloud-based system, comprising: one or more processors and one or more memory storage areas, wherein the one or more processors and the one or more memory storage areas are configured to be dynamically allocated in a serverless manner, and the cloud-based system is configured to: receive a problem type of an input problem originating from a client computing entity; map the problem type to one or more selected solver types; generate one or more container instances of one or more computing containers, each computing container corresponding to the selected solver type; generate a problem output using the one or more container instances; and provide the problem output to the client computing entity, the problem output comprising an optimized solution to the input problem, wherein the problem output can be used to perform one or more prediction-based actions.

[0178] P14. A cloud-based system according to claim P13, wherein the step of mapping the problem type to one or more selected solver types includes: determining a solver domain based at least in part on the problem type of the input problem and one or more problem characteristics of the input problem; identifying a set of domain-by-domain solver types associated with the solver domain; and determining the one or more selected solver types from the set of domain-by-domain solver types.

[0179] P15. A cloud-based system according to claim P14, wherein the problem type of the input problem and the one or more problem features of the input problem are received via a type-agnostic problem solving application programming interface (API) request, and wherein the problem output is provided to the client computing entity via a type-agnostic problem solving API response.

[0180] P16. A cloud-based system according to claim P15, wherein the type-agnostic problem solving API request includes multiple static fields, each static field is configured to describe problem characteristics across different problem types.

[0181] P17. A cloud-based system according to claim P15, wherein the step of determining the selected solver type from the set of domain-by-domain solver types includes: providing one or more problem features of the input problem to a solver selection machine learning model for the problem type, and the solver selection machine learning model is configured to determine the selected solver type from the set of domain-by-domain solver types based at least in part on the problem features of the input problem.

[0182] P18. A cloud-based system according to claim P13, wherein the question type of the input question is received at a serverless request management engine, and the serverless request management engine corresponds to an availability zone of one or more availability zones.

[0183] P19. A cloud-based system according to claim P13, wherein the one or more container instances are managed by a serverless container management engine that is local to the server cloud infrastructure.

[0184] P20. A computer program product, comprising at least one non-transitory computer-readable storage medium, wherein the non-transitory computer-readable storage medium stores a computer-readable program code portion, wherein the computer-readable program code portion is configured to: receive a problem type of an input problem originating from a client computing entity; map the problem type to one or more selected solver types; generate one or more container instances of one or more computing containers, each computing container corresponding to the selected solver type; generate a problem output using the one or more container instances; and provide the problem output to the client computing entity, wherein the problem output includes an optimized solution to the input problem, wherein the problem output can be used to perform one or more prediction-based actions.

[0185] VIII. Conclusion

[0186] With the benefit of the teachings presented in the foregoing description and the related drawings, those skilled in the art will appreciate many modifications and other embodiments. Therefore, it should be understood that the present disclosure is not limited to the specific embodiments disclosed, and modifications and other embodiments are intended to be included within the scope of the appended claims concept. Although specific wording is used herein, they are used only in a general and descriptive sense, and not for the purpose of limitation.

Claims

1. A method implemented by a computer, the method comprising the following steps: receiving, using one or more processors, a question type of an input question originating from a client computing entity; mapping the problem type to one or more selected solver types using the one or more processors; generating, using the one or more processors, one or more container instances of one or more compute containers stored in a storage subsystem, each compute container corresponding to the selected solver type; executing the one or more container instances using the one or more processors; generating, using the one or more processors, a question output using the one or more container instances; as well as providing the problem output to the client computing entity using the one or more processors, the problem output comprising an optimized solution to the input problem, wherein the step of mapping the problem type to one or more selected solver types comprises: determining a solver domain based at least in part on the problem type of the input problem and one or more problem characteristics of the input problem; identifying a set of domain-by-domain solver types associated with the solver domain; and The one or more selected solver types are determined from the set of domain-wise solver types.

2. The computer-implemented method of claim 1, wherein: The question output is enabled for use in performing one or more prediction-based actions.

3. The computer-implemented method of claim 2, wherein: The question type of the input question and the one or more question features of the input question are received via a type agnostic problem solving application programming interface (API) request, and wherein the question output is provided to the client computing entity via a type agnostic problem solving API response.

4. The computer-implemented method of claim 3, wherein: The type-agnostic problem solving API request includes a plurality of static fields, each of which is configured to describe problem characteristics across different problem types.

5. The computer-implemented method of claim 2, wherein: The step of determining the selected solver type from the set of domain-by-domain solver types includes: providing one or more problem features of the input problem to a solver selection machine learning model for the problem type, the solver selection machine learning model being configured to determine the selected solver type from the set of domain-by-domain solver types based at least in part on the problem features of the input problem.

6. The computer-implemented method of claim 1, wherein: The question type of the input question is received at a serverless request management engine that is local to a server cloud infrastructure and corresponds to an availability zone of one or more availability zones.

7. The computer-implemented method of claim 1, wherein: The one or more container instances are managed by a serverless container management engine that is local to the server cloud infrastructure.

8. The computer-implemented method of claim 7, wherein: The serverless container management engine is configured to scale a total count of container instances based at least in part on the total count of the selected solver type.

9. The computer-implemented method of claim 7, wherein: An inbound problem queue is updated to identify the input problem, and wherein the serverless container management engine is configured to scale a total count of container instances for the one or more selected solver types based at least in part on a number of problems identified by the inbound problem queue.

10. The computer-implemented method of claim 1, wherein: The steps of generating the problem output include: receiving one or more container outputs generated based at least in part on execution of the one or more container instances; and The question output is generated based at least in part on the one or more container outputs.

11. The computer-implemented method of claim 1 , further comprising: Execution of each container instance is monitored during each execution iteration, and execution of the container instance is paused if a per-iteration optimization gain of an execution iteration fails to satisfy a configurable per-iteration optimization gain threshold.

12. The computer-implemented method of claim 1, wherein: Execution of the container instance is configured to generate container outputs in parallel for each of the one or more problems identified by the inbound problem queue.

13. A cloud-based system, the system comprising: one or more processors and one or more memory storage areas, wherein the one or more processors and the one or more memory storage areas are configured to be dynamically allocated in a serverless manner, the cloud-based system being configured to: A question type for receiving an input question originating from a client computing entity; mapping the problem type to one or more selected solver types; generating one or more container instances of one or more compute containers stored in a storage subsystem, each compute container corresponding to the selected solver type; executing the one or more container instances using the one or more processors; generating a question output using the one or more container instances; and providing the problem output to the client computing entity, the problem output comprising an optimized solution to the input problem, wherein the step of mapping the problem type to one or more selected solver types comprises: determining a solver domain based at least in part on the problem type of the input problem and one or more problem characteristics of the input problem; identifying a set of domain-by-domain solver types associated with the solver domain; and The one or more selected solver types are determined from the set of domain-wise solver types.

14. The cloud-based system of claim 13, wherein: The question output is enabled for use in performing one or more prediction-based actions.

15. The cloud-based system of claim 14, wherein: The question type of the input question and the one or more question features of the input question are received via a type agnostic problem solving application programming interface (API) request, and wherein the question output is provided to the client computing entity via a type agnostic problem solving API response.

16. The cloud-based system of claim 15, wherein: The type-agnostic problem solving API request includes a plurality of static fields, each of which is configured to describe problem characteristics across different problem types.

17. The cloud-based system of claim 15, wherein: The step of determining the selected solver type from the set of domain-by-domain solver types includes: providing one or more problem features of the input problem to a solver selection machine learning model for the problem type, the solver selection machine learning model being configured to determine the selected solver type from the set of domain-by-domain solver types based at least in part on the problem features of the input problem.

18. The cloud-based system of claim 13, wherein: The question type of the input question is received at a serverless request management engine corresponding to an availability zone of one or more availability zones.

19. The cloud-based system of claim 13, wherein: The one or more container instances are managed by a serverless container management engine that is local to the server cloud infrastructure.

20. A computer program product, the computer program product comprising at least one non-transitory computer-readable storage medium, the non-transitory computer-readable storage medium having a computer-readable program code portion stored therein, the computer-readable program code portion being configured to: A question type for receiving an input question originating from a client computing entity; mapping the problem type to one or more selected solver types; generating one or more container instances of one or more compute containers stored in a storage subsystem, each compute container corresponding to the selected solver type; executing the one or more container instances using the one or more processors; generating a question output using the one or more container instances; as well as providing the problem output to the client computing entity, the problem output comprising an optimized solution to the input problem, wherein the step of mapping the problem type to one or more selected solver types comprises: determining a solver domain based at least in part on the problem type of the input problem and one or more problem characteristics of the input problem; identifying a set of domain-by-domain solver types associated with the solver domain; and The one or more selected solver types are determined from the set of domain-wise solver types.

Images