DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This office action is in responsive to communication(s): original application filed on 05/09/2023. Claims 1-20 are pending. Claims 1, 8, and 15 are independent.
Drawings
The drawings are objected to as failing to comply with 37 CFR 1.84(p)(4) because reference character “146” has been used to designate both "Counter images" in FIG. 1 and "container images" in Page 14, line 27; Page 15, line 3; and Page 22, lines 20 and 25. Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Specification
The use of the term "WiFi", "WiGig", "WiMax", and "Bluetooth" in Page 11, lines 1-3, which is a trade name or a mark used in commerce, has been noted in this application. The term should be accompanied by the generic terminology; furthermore the term should be capitalized wherever it appears or, where appropriate, include a proper symbol indicating use in commerce such as ™, SM , or ® following the term.
Although the use of trade names and marks used in commerce (i.e., trademarks, service marks, certification marks, and collective marks) are permissible in patent applications, the proprietary nature of the marks should be respected and every effort made to prevent their use in any manner which might adversely affect their validity as commercial marks.
Claim Objections
Claims 1, 3-5, 8, 11, 14-15, 18, and 20 are objected to because of the following informalities:
in Claim 1, lines 9-41, "… wherein each container configuration comprises … and wherein generating each container configuration comprises … receiving performance scores for each container configuration; determining a total performance score for each container configuration based on … simulate each container configuration … wherein the final quantum state comprises the performance scores for each container configuration …" appears to be "… wherein each container configuration comprises … and wherein generating said each container configuration comprises … receiving performance scores for said each container configuration; determining a total performance score for said each container configuration based on … simulate said each container configuration … wherein the final quantum state comprises the performance scores for said each container configuration …";
in Claim 3, line 8, "… send the initial quantum state the quantum computing system …" appears to be "… send the initial quantum state to the quantum computing system …";
in Claim3, lines 10-11, "… determine the performance scores for each container configuration from the final quantum state" appears to be "… determine the performance scores for said each container configuration from the final quantum state";
in Claim 4, lines 1-2, "… wherein determining the performance scores for each container configuration from the final quantum state comprises …" appears to be "… wherein determining the performance scores for said each container configuration from the final quantum state comprises …";
in Claim 5, line 3, "… determining the total performance score for each container configuration based on …" appears to be "… determining the total performance score for said each container configuration based on …"
in Claim 8, lines 6-21, "… wherein each container configuration comprises … and wherein generating each container configuration comprises … simulating each container configuration … wherein the final quantum state comprises performance scores for each container configuration … determining a total performance score for each container configuration based on …" appears to be "… wherein each container configuration comprises … and wherein generating said each container configuration comprises … simulating said each container configuration … wherein the final quantum state comprises performance scores for said each container configuration … determining a total performance score for said each container configuration based on …";
in Claim 11, line 3, "… determining the total performance score for each container configuration based on …" appears to be "… determining the total performance score for said each container configuration based on …";
in Claim 14, lines 1-2, "… wherein simulating each container configuration comprises …" appears to be "… wherein simulating said each container configuration comprises …";
in Claim 15, lines 8-23, "… wherein each container configuration comprises … and wherein generating each container configuration comprises … simulate each container configuration … wherein the final quantum state comprises performance scores for each container configuration … determine a total performance score for each container configuration based on …" appears to be "… wherein each container configuration comprises … and wherein generating said each container configuration comprises … simulate said each container configuration … wherein the final quantum state comprises performance scores for said each container configuration … determine a total performance score for said each container configuration based on …";
in Claim 18, line 2, "… determining the total performance score for each container configuration based on …" appears to be "… determining the total performance score for said each container configuration based on …";
in Claim 20, lines 1-2, "… wherein simulating each container configuration comprises …" appears to be "… wherein simulating said each container configuration comprises …".
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-7, 9-10, and 16-17 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1 recites the limitation "…" in lines 35-41, which rendering the claim indefinite because it is unclear whether these two instances of ".
Claim 2-7 are rejected for fully incorporating the deficiency of their respective base claims.
Claims 2, 9, and 16 recite the limitation "... wherein the performance scores comprise a memory utilization score, a network bandwidth utilization score, an API call volume score, a central processing unit performance score, a graphics processing unit performance score, and/or a data security score" in lines 1-4, which rendering these claims indefinite because it is unclear what is included or excluded by the claim language. For examination purpose, "A, B, C, D, E, and/or F" will be considered as "at least one or more of A, B, C, D, E, or F".
Claim 4 recites the limitation "… converting the final quantum state from quantum bits to classical binary bits" in line 3, which rendering the claim indefinite because ".
Claim 10 recites the limitation "… converting the final quantum state from quantum bits to classical binary bits" in line , which rendering the claim indefinite because ".
Claim 17 recites the limitation "… converting the final quantum state from quantum bits to classical binary bits" in line , which rendering the claim indefinite because ".
Allowable Subject Matter
Claims 1-7, 9-10, and 16-17 would be allowable if rewritten or amended to overcome the rejection(s) under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), 2nd paragraph, set forth in this Office action.
Claims 8, 11-15, and 18-20 are allowed.
The following is a statement of reasons for the indication of allowable subject matter:
In regard to independent Claims 1, 8, and 15, prior arts of records, either singularly or in combination, do not teach or suggest the combination of claimed elements including "a system comprising: a container generation system, the container generation system comprising: a first classical processor configured to: receive an application code of a legacy application; and containerize the legacy application to generate a containerized application code of a containerized application, wherein containerizing the legacy application comprises: analyzing the application code to generate a plurality of container configurations for the containerized application, wherein each container configuration comprises a plurality of container images and a plurality of application programming interfaces (APIs), and wherein generating each container configuration comprises: determining a plurality of logical units of the legacy application; clustering the plurality of logical units into a plurality of clusters; determining a plurality of interaction flows between the plurality of clusters; generating a respective container image for each cluster; and mapping the plurality of interaction flows to the plurality of APIs; receiving performance scores for each container configuration; determining a total performance score for each container configuration based on the performance scores and a rule; determining a highest total performance score; and determining an improved container configuration from the plurality of container configurations based on the highest total performance score; and deploy the containerized application code having the improved container configuration to a cloud computing system; and a quantum computing system communicatively coupled to the container generation system, the quantum computing system comprising: a quantum processor configured to: receive an initial quantum state, wherein the initial quantum state comprises the plurality of container configurations represented using quantum bits; simulate each container configuration; and generate a final quantum state from the initial quantum state, wherein the final quantum state comprises the performance scores for each container configuration represented using quantum bits", "a method comprising: receiving an application code of a legacy application; containerizing the legacy application to generate a containerized application code of a containerized application, wherein containerizing the legacy application comprises: analyzing the application code to generate a plurality of container configurations for the containerized application, wherein each container configuration comprises a plurality of container images and a plurality of application programming interfaces (APIs), and wherein generating each container configuration comprises: determining a plurality of logical units of the legacy application; clustering the plurality of logical units into a plurality of clusters; determining a plurality of interaction flows between the plurality of clusters; generating a respective container image for each cluster; and mapping the plurality of interaction flows to the plurality of APIs; generating an initial quantum state from the plurality of container configurations; simulating each container configuration; generating a final quantum state from the initial quantum state, wherein the final quantum state comprises performance scores for each container configuration represented using quantum bits; determining a total performance score for each container configuration based on the performance scores and a rule; determining a highest total performance score; determining an improved container configuration from the plurality of container configurations based on the highest total performance score; and deploying the containerized application code having the improved container configuration to a cloud computing system", or "a non-transitory computer-readable medium storing instructions that, when executed by at least one classical processor and at least one quantum processor, cause the at least one classical processor and the at least one quantum processor to: receive an application code of a legacy application; containerize the legacy application to generate a containerized application code of a containerized application, wherein containerizing the legacy application comprises: analyzing the application code to generate a plurality of container configurations for the containerized application, wherein each container configuration comprises a plurality of container images and a plurality of application programming interfaces (APIs), and wherein generating each container configuration comprises: determining a plurality of logical units of the legacy application; clustering the plurality of logical units into a plurality of clusters; determining a plurality of interaction flows between the plurality of clusters; generating a respective container image for each cluster; and mapping the plurality of interaction flows to the plurality of APIs; generate an initial quantum state from the plurality of container configurations; simulate each container configuration; generate a final quantum state from the initial quantum state, wherein the final quantum state comprises performance scores for each container configuration represented using quantum bits; determine a total performance score for each container configuration based on the performance scores and a rule; determine a highest total performance score; determine an improved container configuration from the plurality of container configurations based on the highest total performance score; and deploy the containerized application code having the improved container configuration to a cloud computing system" when interpreted as a whole.
Jaeger et al. (US 2020/0142675 A1, pub. date: 05/07/2020) discloses in ¶¶ [0009]-[0014] that (1) compared to a virtual machine, a container is a relatively lightweight construct, and is not burdened with the overhead of its own full operating system and all of the state information associated with a physical or virtual machine; (2) consequently, the starting up and tearing down of a container requires little overhead, which makes the deployment and termination of containers an effective technique for application upgrade, dynamic load balancing and resource allocation within a cluster; (3) although the behavior of different container may differ based on binary and library programs that are incorporated into the image loaded into those particular containers, the use of shared operating system services significantly reduces the overhead associated with each individual instance of a container; (4) for this reason, containers are lightweight, relative to virtual machines, which makes the instantiation and termination of containers in response to application demands more feasible; (5) container management systems may also include pods which is a deployment unit in a container system that includes one or more containers that are deployed together on the same host or cluster; (6) microservices are typically small, autonomous services that can collaborate tightly together to provide the functionality of an application; (7) the autonomous nature of microservices enables them to be deployed independently of each other as isolated services, that may communicate with other services through network calls; (8) a set of closely related microservices, or microservices that, in their operation, share access to a common volume, may be deployed within the same pod; (9) a microservice architecture offers important advantages of manageability, availability, scalability, and deployability on clustered systems; (10) however, the monolithic nature of many legacy applications, makes translating such monolithic applications into sets of minimally interdependent microservices a difficult and manually intensive task; (11) further complicating the problem, legacy monolithic applications written in Cobol and compiled to run on legacy architectures such as MVS or z/OS with their proprietary APIs cannot generally be exported from the legacy architecture and executed onto a Linux or other operating system or cluster, especially when based on x86 servers due to differences in instruction sets and APIs; (12) systems that translate application code from one operating environment to another, whether through emulation, cross-compiling, transcoding, or a hybrid approach can be developed to enable the execution of a compiled legacy program to run on a guest operating system using a different underlying architecture; and (13) however, such systems tend themselves to be large programs that do not easily scale, which is particularly problematic in the case of executing applications that perform high transaction volumes. Additionally, emulation or transcoding systems. Jaeger further discloses in ¶¶ [0015]-[0063] that (1) a source code repository containing the source code of a monolithic legacy application containing a plurality of programs executable in a legacy computing environment to perform a plurality of transactions; (2) a source code analyzer operable to parse the source code and to identify, for each transaction in the plurality of transactions a transaction definition vector identifying each program potentially called during the transaction, to create a plurality of transaction definition vectors; (3) an activity log analyzer operable to create a dynamic definition repository identifying which programs are actually used by the monolithic legacy application in performing in at least a subset of the plurality of transactions; (4) a microservice definition optimizer operable to compare the plurality of transaction definition vectors to the dynamic definition repository and remove unused programs from the transaction definition vectors to create a plurality of microservice definition vectors defining a plurality of microservices; (5) a microservice image builder operable to, for each microservice definition vector of the plurality of microservice definition vectors, locate for each program identified by the microservice definition vector compiled source code binaries compiled to run in the legacy computing environment to form a plurality of microservice images corresponding to the microservice definition vectors; (6) a complementary component repository operable to store a set of binary images of emulator elements of a legacy emulator that, together, are less than a complete legacy emulator, said images corresponding to a plurality of functions or sets of functions of said legacy computing environment, and said images executable in a distinct computer environment characterized by an instruction set distinct from the instruction set of the legacy environment; (7) a container builder operable to form a container image for each micro service or a set of micro services in the plurality of microservices using the corresponding microservice image or images from the microservice image repository and using image files from the complementary component repository for the emulator elements of the legacy emulator corresponding to functions or sets of functions employed by the micro service or set of micro services when executed, as identified by signatures of calls in the binaries in the micro service or set of micro services, to create a plurality of container images; (8) a container management system operable to create at least one container for execution in the distinct computing environment and to run at least one microservice stored in container image repository in the at least one container; (9) the microservice definition optimizer compares each dynamic transaction definition vector to each corresponding transaction definition vector to create the plurality of microservice definition vectors; (10) the activity log analyzer uses legacy activity logs of the monolithic legacy application generated by running the monolithic legacy application in the legacy computing environment; (11) the activity log analyzer uses an emulator to run the monolithic legacy application to generate log files and to determine which programs are used by the monolithic legacy application during the execution of transactions; (12) the source code analyzer is operable to use information from the activity log analyzer to identify the transaction definition vectors; (13) the source code analyzer is further operable to create a plurality of translation tables; (14) the microservice definition optimizer is operable to further optimize the microservice definition vectors by creating additional microservice definition vectors containing programs shared by more than one transaction in the plurality of transactions; (15) a binary repository operable to store the compiled source code containing binaries compiled to run in the legacy computing environment; (16) the compiled source code in the binary repository is compiled from the source code in the source code repository into binary files; (17) the legacy computing environment includes a Multiple Virtual Storage (MYS) or z/OS computer system; (18) the complementary component repository is further operable to store a plurality of images of operating system software packages used by the legacy emulator, and wherein the container builder also places images of any software packages used by a particular element of the legacy emulator in a particular container image containing the particular element of the legacy emulator; (19) the container builder is further operable to replace the signatures of calls in the binaries in the microservice or set of microservices with instructions for calls operable in the legacy emulator; (20) the container management system is operable to create a plurality of containers; (21) a set of complementary images are instantiated in a separate container within a common pod; (22) more than one copies of at least one container image are activated in more than one separate containers; (23) the container management system is operable to vary the number of containers in the plurality of containers; (24) the container management system is operable to allocate varying resources to separate containers; (25) the container management system is operable to use information from the activity log analyzer to determine how the number of copies of at least one container image to place into more than one separate containers, to determine the number of containers in the plurality of containers, and/or to determine resources to allocate to separate containers; (26) the container management system is operable to use information from use of the scalable container-based system to determine how the number of copies of at least one container image to place into more than one separate containers, to determine the number of containers in the plurality of containers, and/or to determine resources to allocate to separate containers; (27) the source code analyzer is further operable to create one or more sub-databases or clusters of sub-databases from a database of the monolithic legacy application; (28) the container builder is operable to place the one or more sub-databases or clusters of sub-databases in one or more containers; and (29) when the source code is changed, the container-based system is operable to automatically update at least one microservice image, at least one container image, and at least one container to contain an updated binary based on the source code change. Jaeger also discloses in ¶¶ [0073]-[0154] with FIGS. 2A-2B and 3-5 that (1) a scalable container-based system that can automatically partition a monolithic legacy application into a set of microservices, and deploy such microservices with appropriate elements of a legacy emulator in containers; (2) the scalable container-based system optimizes legacy emulator use by placing emulator elements, such as binary images of functional components, of the legacy emulator in containers only when microservices use those elements, rather than requiring an image of the full legacy emulator in every container to accomplish every task performable by the monolithic legacy application; (3) rather than place an image of the entire operating system in every container, the scalable container-based system also optimizes operating system use by placing OS elements, such as binary images of functional components, of the operating system in container with microservices and emulator elements that effectively use those OS elements; (4) the scalable container-based system may identify individual transactions that may be performed using the monolithic legacy application, such as creating a record, placing order, performing a query, etc.; (5) the scalable container- based system then identifies programs included in each individual transaction; (6) finally, the scalable container-based system creates microservices that may be used or combined to perform the same transaction outside of the monolithic legacy application;(7) individual programs that make up a transaction from the monolithic legacy application may be located in a distinct microservices; (8) a microservice may contain more than one program from the monolithic legacy application; (9) in addition, because microservices may group programs in any manner to efficiently accomplish transactions from the monolithic legacy application, any one program from the monolithic legacy application may be located in only one microservice of the scalable container-based system, or it may be located in multiple distinct microservices of the scalable container-based system; (10) a micro service in a single container image may be deployed in multiple parallel instances, typically in separate containers, through a scalable container-based system; (11) a container may include more than one microservice as well as other information as needed to allow the microservice(s) to execute and function; (12) microservices may preferably be structured so as to be minimally interdependent and/or to minimize the number of microservices requiring changes when programs are updated; (13) the microservice container image may be limited to application binaries and then associated with generic utility (error logging, activity journaling, security, etc.) containers to form a pod; (14) the scalable container-based system is highly flexible, allowing for changes in the microservices themselves, as well as the type and number of containers, the microservice(s) grouped in a particular container or containers, and supporting programs such as emulator elements and OS elements included in containers and the resources devoted to particular containers or pods based on changes in the transactions, programs, other information, or use of transactions or microservices, among other factors; (15) the total number of microservices created from a monolithic legacy application or a portion thereof may be greater than the total number of individual transactions in the monolithic legacy application or the portion thereof; (16) a source code repository (305) that stores the source code of the monolithic legacy application, wherein the source code of the monolithic legacy application may be for example, a monolithic COBOL application that may include dozens, hundreds, or even as many as tens of thousands of individual program files designed to individually or in groups perform hundreds of distinct transactions; (2) a compiler (310), compiles the source code into a set of one or more binaries that are stored in a binary repository (315); (3) a source code analyzer (320), typically via a dependency analyzer component, parses the source code and associated files in the monolithic legacy application as stored in the source code repository (305), and generates a code tree that identifies interdependencies ( caller < > callee) in the source code; (4) preferably, the source code analyzer (320) iterates through each transaction of the monolithic legacy application, as defined in the configuration parameters of the transactional system, such as CICS, IMS, etc.; (5) the source code analyzer (320) receives as input from the source code repository (305), a file identifying the available CICS transaction definitions that may be invoked by the users in their interactions with the monolithic legacy application; (6) preferably, this file identifies each transaction and its root, or first program invoked when performing the transaction, which may include the root program as the callee of an EXEC CICS LINK, used as in many of the transactions; (7) the root program refers to the first program called by the program handling the interface (e.g. doing the SEND/RECEIVE MAPs when interface is 3270 but also other equivalent APIs when interface is different); (8) the source code analyzer (320) may parse all of the program files associated with the monolithic legacy application, to detect interdependency relationships (caller<> callee for programs or inclusion for resources like copybooks) between program files for all of the transactions of the monolithic legacy application; (8) a dependency analyzer within the source code analyzer (320) identifies caller-callee or inclusion relationships between the programs used by a transaction; (9) the static analyzer may generate a call or inclusion tree in the form of a vector or set of vectors or a graph that identifies the programs or modules that the source code for a particular transaction may invoke or include.; (10) a partitioning of the monolithic legacy application is desired to divide the application into a set of minimally interdependent transactions accessible, e.g., via SOAP or REST (with JSON or other data format); (11) each of the minimally interdependent transactions may be able to run in an independent instance of the legacy emulator (325); (12) an output of the source code analyzer (320) may be a program call or inclusion tree or graph identifying, for each transaction, the complete set of programs that may be invoked or used performing each transaction and the caller-callee or inclusion relationships between the programs; (13) the call tree may be translated into a set of vectors, one for each transaction or a defined subset of the possible transactions of the monolithic legacy application, identifying the programs that may be invoked in carrying out a transaction; (14) the source code analyzer (320) may also, based on the interface definition of the root program, extract or generate the data types, messages, message formats/bindings, and sets of message inputs and outputs, and define addresses and endpoints of each transaction, and translate this information into a message structure for use in constructing and defining an interface to the transactions(s) when the message is provided to the container builder (330) and/or the container management system (335), e.g., as part of a microservices image; (15) the source code analyzer may also be further configured to generate bidirectional data-encoding translation tables or procedures to convert UTF characters to 8-bit EBCDIC characters and vice versa (or between different character sets including ASCII), and this translation may be implemented by generating a script/program to be used with microservices based on the transactions and at their interfaces toward the requester; (16) the source code analyzer (320) may also include part of a transcoding application to present a transcoder path for the use of transcoded programs into the scalable container-based system; (17) in this way, the source code analyzer may also be used to support transitioning the source code from its original language, such as Cobol, to a different language, such as Java; (18) each transaction definition vector (210), (220), (230) in the transaction state definition repository (340) includes a superset of the programs that are actually invoked in the course of performing actual transactions using the monolithic legacy application; (19) frequently, transaction applications contain many programs that are never invoked; (20) the inclusion of these unused programs in the code results in reduced efficiency of the containerized application for a number of reasons, including the overhead required to move around on permanent storage, load and unload into central computer memory programs that are not invoked, as well as additional delays in compiling, building or transporting over a network updates to transaction containers; (21) to eliminate these unused programs from the microservice application images, the microservice definition optimizer (345) extracts the transaction definition vector, interface definition, and translation tables from the transaction state definition repository (340), and applies a dynamic definition vector stored in the dynamic definition repository (350) to eliminate unused programs included in the transaction definition vectors (210), (220), (230) of the transaction state definition repository (340) to arrive at corresponding microservice definition vectors (260) (270), (280), as shown in FIG. 2B, which may be stored in an intermediate state by the microservice definition optimizer (345) pending further refinement and definition of the microservices, or processed by the microservice image builder (350) to create microservice images stored in the microservice image repository (355); (22) the dynamic definition vector is developed separately from the transaction state definition vectors by a dynamic definition process, which typically runs on a different system or uses legacy activity logs; (23) the dynamic definition vector may previously exist or it may be developed in parallel with the transaction definition vectors; (24) in the dynamic definition process, the monolithic legacy application is run and each transaction is analyzed to determine which programs are actually called and which are not; (25) when the system is run for a sufficient period of time (e.g. week, month, quarter, year depending on the nature of the application) or using sets of data that invoke all actual use cases, then the dynamic definition vector will more precisely identify the programs that are actually called when performing a transaction; (26) alternatively, the dynamic definition vector may also be generated by starting with the static transaction state definition vector, which may be over-inclusive of programs, that then selecting only those programs that are actually invoked; (27) thus, the dynamic definition vector may be built up as programs are identified, or it may be created by eliminating unneeded programs from the transaction state definition vector; (28) pre-existing legacy activity logs (360) of the monolithic legacy application run in its legacy computing environment are used by activity log analyzer (365) to identify program that are actually invoked by the execution of real-world transactions and thereby generate a program vector indicating which programs are used for each transaction; (29) the monolithic legacy application is run on a legacy emulator (325) and an activity log data generated by the emulator is analyzed by an activity log analyzer (365) to generate a program vector indicating which programs are used for each transaction; (30) the legacy emulator (325) executes each transaction for a period of time sufficient to achieve confidence that all actual variants of use cases for each transaction have been encountered; (31) alternatively, a defined set of test transactions designed to exercise each actual use case may be carried out, enabling the activity log analyzer (365) to similarly determine which programs are actually used by the transactions in the monolithic legacy application; (32) the activity log analyzer (365) may use information from both legacy activity logs (360) and legacy emulator (325) to determine which programs are actually used by the transactions in the monolithic legacy application; (33) the output of the activity log analyzer is stored in the dynamic definition repository (370), which stores vectors corresponding to programs actually used, for each transaction; (34) legacy emulator (325) may be an emulator developed to allow the execution of a compiled legacy application or load module from a z/OS or other legacy computing environment to run in a distinct computing environment, such as an x86 platform with the Linux operating system; (35) the legacy emulator may convert each native instruction or native operating system service call of the original executable program into equivalent instructions and systems calls of the distinct computing environment; (36) the legacy emulator (325) may implement a set of native APIs to allow the emulation of individual legacy instructions or system service calls; (37) the legacy emulator (325) may be a single image of the entire emulator, or it may include partitioned images as discussed further herein; (38) the legacy emulator (325) may further include or have operable access to an operating system or components thereof actually used by the legacy emulator; (38) microservice definition optimizer (345) applies dynamic transaction vectors stored in the dynamic definition repository (370) to the transaction definition vectors stored in the transaction state definition repository (340) to arrive at microservice definition vectors that may be used by the microservice image builder (350) to create microservice images which are then stored in the microservice image repository (355); (39) the resulting architecture includes a set of Tx transactions, each defined by the smallest number of programs; (40) any of the Tx transactions of the monolithic legacy application can be defined as an independently callable microservice, MSx both in the translated operation of the previously monolithic legacy application, and in enhanced or modified applications that may invoke the defined microservices MSx; (41) any of the Tx transactions can also be defined as a set of independently callable microservices; (42) for the total set of Tx transactions from a monolithic legacy application, some subset may be defined by one microservice per transaction, while another subset may be defined by a set of microservices per transaction; (43) as illustrated in FIG. 5, if transactions Tl and T2 use common programs D and E, when these transactions are translated into microservices by microservice definition optimizer (345), those common programs may be grouped as an independent microservice, MS3, that may be called by MS1, which contains the other programs of T1, or called by MS2, which contains the other programs of T2; (44) the microservice definition optimizer (345) may store the microservice image vectors or intermediate microservice image vectors that it then further changes or optimize; e.g., the microservice definition optimizer (345), when presented with transaction definition vectors for the transactions of FIG. 4, may first create intermediate microservice definition vectors, MS1 and MS2 both of which contain the programs also located in the transaction definition vectors; (45) the microservice definition optimizer (345), may recognize the common component of these microservice definition vectors MS1 and MS2, as indicated by elements D and E of FIG. 4, and extract the common component from the first two microservice definition vectors; (46) as depicted in FIG. 5, in addition to the first and second microservices, MS1 and MS2, common elements D and E are used to create a third microservice definition vector, MS3, that contains these common components and that may be called by MS1 or MS2; (47) these optimized microservice definition vectors, MS1, MS2 and MS3, are then provided to the microservice image builder (350); (48) compiler (310), compiles source code in source code repository (305) to produce binaries in binary repository (315); (49) the compiler (310) generates binaries for a legacy computing environment, such as a System 390 or z/OS mainframe; (5) in this way, the binaries used to construct microservice images in the scalable container-based system described herein may be the same as the binaries run in the legacy computing environment, facilitating interoperability and gradual migration of the monolithic legacy application from the legacy computing environment to the scalable container-based system; (51) the microservice image builder (350) retrieves compiled binaries from the binary repository (315) that correspond to the programs identified in the microservice definition vectors or optimized microservice definition vectors, as applicable and combines the binaries to generate an image for each microservice that includes binary images for each program in the microservice definition vector; (52) the microservice images may also include associated artifacts and information, such as shared resource definitions, etc. retrieved by the microservice image builder (350), which are stored in the microservice image repository (355); (53) the container builder (375) constructs container images by combining the binary image(s) associated with a specific microservice stored in the microservice image repository (355) with binary images stored in the complementary component repository (380); (54) the complementary component repository (380) may store a set of image files of emulator elements that together make up a legacy emulator, which is typically the same as the legacy emulator (325) otherwise used by the scalable container-based system; (55) the legacy emulator may be partitioned by functions or subsets of functions to form legacy elements, which provides advantages for deployment of the legacy emulator in the container-based system described herein; (56) only an individual legacy element or set of elements of the legacy emulator used by microservices in a container may run inside a given container; (57) additionally, certain legacy elements used by containers in a pod may be stored in separate containers, then accessed by microservices in other containers in the pod; (58) suitable legacy elements include tracing and logging functions of emulator's runtime environment, and such a set up may improve performance and/or security; (59) the complementary component repository (380) may also store software packages from the operating system that the legacy emulator may use, which may be referred to as OS elements; e.g., individual system API components may also be stored individually as separate images; (60) individual packages and library files can be combined at runtime to increase the functionality offered by Linux or another operating system, and the binaries may be stored in the complementary component repository (380); (61) the container builder (375) can selectively incorporate emulator elements and/or OS elements to provide functionalities associated with a microservice or set of microservices into the container image containing that microservice or set of microservices; (62) in this manner, the overall image size for each container may be smaller than if the full legacy emulator image or a full OS image were included in each container; (63) the partitioning of the legacy emulator into emulator elements and the inclusion of less than all such elements in a container, or in a container in a pod, may reduce the memory used to house the container or the pod by five to seven times as compared to an otherwise identical container or pod containing an image of the full legacy emulator, or emulator elements not used by microservices in the container or pod; (64) the inclusion of less than all OS elements in a container, or in a container in a pod, may similarly reduce the memory used to house the container or the pod by five to seven times as compared to an otherwise identical container or pod containing an image of the full OS, or OS elements not used by microservices and/or emulator elements in the container or pod; (65) the relative contributions of the reduction of legacy emulator size and operating system size to the reduction of the memory used to house the combination of the two may depend on the relative overall sizes of the legacy emulator and the operating system and the degree of partitioning of both; (66) the legacy emulator may be partitioned into emulator elements that correspond with the likely needs of microservices; (67) the legacy emulator may also be partitioned to place core functionalities, relied on by other components of the legacy emulator, into a core emulator element; (68) the legacy emulator may further be partitioned to place functionalities likely to be generally used in one or a few containers in a pod, but not all containers, such as security functionalities, in a separate element, such as a security emulator element; (69) the size of an emulator element as compared to the total legacy emulator, along with other factors such as likelihood of use together, may be used in determining which functionalities are separated into different emulator elements;(70) the container builder (375) includes a load module compiler, that receives as input, the binaries, such as System 390 or z/OS executable image files, stored in the microservice image repository (355); (71) the load module compiler detects all signatures in the binaries of calls to programs, services or functions of the legacy computing environment by the monolithic legacy application, such as a suite of assembler instructions; (72) the load module compiler may use this information to determine the legacy emulator functions used by the microservice or set of microservices; (73) the container builder (375) may then locate emulator elements able to perform these functions among the emulator elements in the complementary component repository (380) and place the emulator elements, along with any associated OS elements from the complementary component repository (380) with the microservice images or set of microservice images into a container image; (74) alternatively, the container builder (375) will place the images of the emulator elements and OS elements in a container image associated with a container image of the micro services image or set of images, such that both container images will be placed in a pod; (75) the load module compiler may replace the signature or signatures in the binaries with instructions to call the same function or functions called in the legacy computing environment in the legacy emulator instead, thereby forming a legacy emulator-optimized microservice image that may be stored in the container image; (76) the container builder (375) may replace the identified legacy function calls with calls to native APIs of the legacy emulator and construct a modified image or images; (77) during or after any optimization or modifications of microservice images or container images as described herein, the container builder (375) then stores in the container image repository (390); (78) subsequently the container images in the container image repository (390) are executed in containers (395) managed by the container management system (385); (79) container management system (385) may combine the functions of scheduling the instantiation of containers, running containers, allocating them a controlled amount of computing/storage/networking resources, upgrading them, and/or may perform additional logging and management functions to track and manage the health of the system; (80) the selective allocation of resources by container management system (385) may be done by the use of cgroups when the containers are based on Docker; (81) containers (395) and container management system (385) may reside in sub-system (400); (82) a typical large monolithic legacy application still has clusters of independent data in its large database composed of thousands of table; (83) in a scalable container-based system, these clusters should, to improve various system capabilities, be separated into independent sub-databases, each used by an independent set of microservices; (84) these sub-databases can then be isolated, e.g. in separate database servers and can be managed independently from each other; (85) this increases flexibility and agility of the system overall because local data structure changes are simpler to execute from an operational standpoint than global ones; (86) this separation of databases into sub-databases also increases global availability of the scalable container-based system because a problem with one sub-database or its maintenance does not impact the other databases and microservices that use them; (87) similar to identifying program dependencies, data may be partitioned according to the microservice architecture by creating dependency trees that identify data clusters through their use in corresponding transactions or sets of transactions; (88) this identification may be done by the source code analyzer (320), and particularly its dependency analyzer, as it parses the monolithic legacy application to produce sub-databases and sub-database clusters, typically in the form of vectors or tables, that can be separated from each other to achieve at least some of the benefits described above; (89) various microservices images may share similar access to same sub-databases; (90) in particular, relational database service transactions may be separately packaged from transactions for other functionalities of the legacy emulator, so that e.g., processing services and database services are ultimately defined in separate microservices; (91) typically, containers with processing microservices may be in a pod with one or more containers housing the relational database services and sub-databases used by the processing microservices; (92) in similar types of structures, support for objects shared across transactions in the monolithic legacy application may be implemented by detecting the shared objects using the source code analyzer and then gathering support objects in specialized resource containers using the container builder as informed by the source code analyzer; (93) in another similar type of structure, in order to maximize data separation, transactions may be constructed that span across several microservices calling each other synchronously in cascade after the initial service request to Kubernetes; (94) the container-based system described herein presents a changed landscape from a build standpoint by providing an adaptive, integrated build process that is flexibly coupled to the production environment; (95) when modifications to the source code stored in source code repository (305) are made, compiled by compiler (310), and stored in binary repository (315), the source code analyzer (320), transaction state definition repository (340), microservice definition optimizer (345), and microservice image builder (350) can be used to construct an updated micro service image or set of microservice images for the microservice or microservices corresponding to only those transactions impacted by the changes; (96) the container builder (375) can then trigger construct procedures, automatically and optimally defined and setup based on microservices definition vectors previously extracted by the container builder, container images for the updated microservices, which can then be deployed by the container management system (385); (97) in the case of more extreme or multiple changes to the source code, the microservice definition vectors may be changed, so that a different microservice or set of microservices is created; (98) the entire update process is preferably automated, but deployment of updated microservices may also be placed under control of an administrative management console (not shown); (99) automatic steps of the update process may include: (a) source code structure placed into the source code repository (310); (b) Jenkins (or other DevOps build system) build job definition; (c) Docker image construction through proper clustering of mainframe binaries; and (d) Kubernetes management parameters; (100) the high level of granularity presented by a large number of independent microservices permits, and preferably operates under full automation; (101) the formation of such microservices can improve overall system manageability, since upgrades or changes to the application code that change the subtree need only cause upgrades to the corresponding containers for the internal microservice, and not for all microservices that invoke it; (102) given the ease with which containers may be constructed and the reduced time for loading a container image into a container if it is smaller, the microservice definition optimizer (345) in many scalable container-based systems may implement instructions to create multiple microservice definition vectors per transaction definition vector, particularly where, as illustrated in FIG. 4 and FIG. 5, transactions use common programs or sets of programs that are amenable to being placed in a separate micro service; (103) greater parsing of transactions into microservices and more minimal micro service definition vectors may be possible in a scalable container-based system designed to use pods than in one not so designed; (104) the only limits on the number of separate microservices defined may be the number of separate programs in the monolithic legacy application and/or memory available in the scalable container-based system for housing microservice image repository (355) and/or containers (395); (105) because a given container image may be placed in any number of active containers, the scalable container-based system allows checking and gradual implementation of updates, with some containers running old versions of a microservice or set of microservices, with newer containers running the updated microservice or set of microservices, which allows updates to be checked and tested for failures, while maintaining the ability to perform a transaction using an old version of the microservice or set of microservices if need be; (106) containers running old version of microservices can be automatically tom down (or removed based on a user instruction) once the update has been sufficiently verified; (107) because containers can be built and torn down easily, if a transaction is running in some containers, new containers with updates can be built to perform new requests for that transaction, while it finishes in existing containers lacking the update, when can then be automatically tom down when they complete the transaction they are immediately running; and (108) the initial deployment of container images containing microservices or sets of microservices into container or pods may be based, at least in part, on transaction activity when the monolithic legacy application is executed in a legacy computing environment, or an emulation thereof. Such information may be derived from a legacy emulator, such as legacy emulator (325). Jaeger further teaches in ¶¶ [0156]-[0168] with FIG. 6 that (1) in step 605, a monolithic legacy application is parsed and program files are automatically partitioned; (2) in step 610, transaction root programs are identified; (3) in step, 615, which may occur before or after step 610, program interdependencies are identified; (4) steps 610 and 615 may occur simultaneously for different transactions in a plurality of transactions; (5) next, in step 620, a plurality of transaction call trees is identified; (6) preferably, this plurality of transaction call trees represents all transactions possible in the monolithic legacy application or all transactions possible in a defined subpart of the monolithic legacy application; (6) in step 625, the plurality of transaction call trees is used to create a plurality of transaction definition vectors that are stored, for example in a transaction state definition repository; (7) in step 650, an activity log analyzer determines which programs are actually used in all transactions possible in the monolithic legacy application, or in all transactions possible in a defined subpart of the monolithic legacy application; (8) if only a defined subpart of the monolithic legacy application is used, it will typically be the same as, include the entirety of, or overlap at least partially with the subpart of step 625; (9) in step 630, the plurality of transaction definition vectors from step 625 are compared to the dynamic definition repository from step 650 by a microservice definition optimizer and programs not actually used in a transaction are removed from each transaction definition vector to create a plurality of micro service definition vectors corresponding to the plurality of transactions; (10) in step 635, the microservice definition optimizer determines if further optimization will occur; (11) if further optimization will occur, then in step 640, at least one of the plurality of the microservice definition vector is further optimized, then in step 645 it is provided to a microservice image builder; (12) if further optimization will not occur for any of the plurality of microservice definition vectors, then in step 645, the microservice definition vector is provided to a microservice image builder; (13) regardless of whether optimization occurs for any of the microservice definition vectors, the plurality of micro service definition vectors derived from the plurality of transaction vectors is provided to the microservice image builder in step 645; (14) in step 655, the microservice image builder takes each microservice definition vector of the plurality of microservice definition vectors and locates corresponding compiled source code compiled to run in the legacy computing environment from a binary repository to form a microservice image in a microservice image repository; (15) after step 655 is completed, the microservice image repository preferably contains plurality of microservice images corresponding to each of a plurality of transactions possible in the monolithic legacy application or a defined subpart thereof; (16) in step 660, a complementary component repository is created from separate images of elements of a legacy emulator; (17) in step 665, a container builder forms a container image for each micro service or a set of microservices using image(s) from the microservice image repository along with images from the complementary component repository of emulator elements of the legacy emulator used to execute the microservice or microservices; (18) in step 670, the plurality of container images is stored in a container image repository; (19) in step 675, at least one container image in the container image repository is stored in a container by a container management system; and (20) in step 680, at least one microservice is executed in a container in the container management system.
Haasjes ("Containerization of legacy applications", IBM Developer Article, https://developer.ibm.com/articles/containerization-of-legacy-applications/, September 16, 2020, pp. 1-16) discloses in Section "Overview" of Pages 1-2 that (1) running applications as containers is the new default for cloud-native developed software and solutions: (2) because of their size and complexity, modernizing monolithic applications and databases is difficult in practice; (3) how benefits can be realized by moving legacy applications to containers and to the cloud; (4) containerization of legacy apps always requires some form of transformation and corresponding investments; and (5) go into a business case model that helps to make these investment decisions by answering the question of when containerization of legacy apps makes sense and to what extent. Haasjes further discloses in Section "Containerization in the context of legacy app modernization" of Pages 2-4 that (1) for cloud-native scenarios, containerization is the process of packaging compiled software code, libraries, configuration, and compute, network, and storage definitions into a set of containers and container management (Kubernetes) definitions; (2) these containers are deployed on a runtime engine, such as Docker Engine or CRI-O; (3) scalability, high availability, and cluster management are arranged by the container orchestration tool; (4) in a legacy apps context, the meaning of the word containerization needs to be augmented to include all that is necessary to make an existing app ready to adopt the run-as-a-container concept; i.e., to an extent that is well balanced with technical feasibility and expected business benefits; (5) by looking at containerization in this way, the next logical step is to introduce a scale to which a legacy app can adopt the run-as-a-container concept; (6) this scale ranges from a simple containerization that does not change anything about the legacy app to more complex containerizations where apps are refactored or even recoded; (7) so, containerization of legacy apps is a spectrum of simple, medium, and complex techniques that can be applied where appropriate from technical and business perspectives; (8) at the leftmost side of this spectrum, package an application as-is to one or a couple of containers, store container images to a container registry, and run the app as one or a set of containers on a platform, such as Docker Engine or CRI-O; (9) shifting to the right along the containerization spectrum, introduce container orchestration tools to start-stop-restart containers based on external events; (10) further right along the spectrum, deploy parts of the legacy app that are suitable to run independently from the user or business logic state (stateless), such as the frontend of a web application, as separate containers, wherein these containers can be automatically controlled by Kubernetes to adhere to declared availability or scalability constraints; (11) shifting a bit further to the right of the spectrum, partly refactor the legacy app by identifying the parts that are suitable to run as independent, yet coarse-grained, macro-services as part of the legacy app cluster; (12) even further to the right along the spectrum, find techniques to refactor your application in such a way that microservices-level modules can be deployed and run independently, and fully use containers and Kubernetes as if the app was designed for them from the beginning, which is the rightmost and closest to cloud-native side of the spectrum; (13) moving from left to right along this spectrum, the higher extent to which your app uses the containerized platform increases the number of benefits that it receives; (14) as a result, gain more cost-effectiveness and business agility; (15) at the same time, the investments for making to transform the legacy app goes up; (16) more risks are introduced to these types of projects as the technical complexity increases to refactor or recode the app; and (17) as with all migration approaches, choosing the right legacy containerization technique within this spectrum is a matter of striking the right balance between investment, business outcome, cost-effectiveness gain, technical feasibility, and risk appetite. Haasjes also discloses in Section "Emerging container technologies open paths to cloud" of Pages 5-6 that (1) a key principle of a container-based architecture is lightweight components that can be restarted quickly; (2) the aim is to keep the containers as lightweight as possible; (3) in most cases, the operating system files do not have to be part of the container since containers reuse the operating system files from the hosting platform; (4) a light version of a web application server that includes just the components and files that are needed to facilitate the functions that the app in the container requires, which results in middleware software that contributes to a lower footprint and shorter restart times of containers; (5) a container-based architecture works well for stateless designed applications; (6) after all, resiliency and scalability are implemented by restarts of failed containers or initiate identical containers in parallel to perform the application functions at a higher load, which works best when no state must be managed in the application logic; (7) however, most legacy applications require state management and data persistency; (8) Kubernetes can coordinate states and data persistency by providing a mechanism to track storage volumes and maintain hostnames after a restart of the container by using the StatefulSet resource, which allows containerization of the parts of the legacy app that manages states such as databases; (9) the advantage of Windows Server Containers is that it allows for containerization of.NET applications, which makes the scope for containerization much larger; (10) older versions of .NET apps are supported and one can eliminate conflicts between different versions of Internet Information Services (IIS) or.NET apps as they can co-exist too; and (11) another interesting containerization case is to isolate an older Windows operating system version in a Windows Server 2016 container as a quick evergreen win. Haasjes further teaches in Section "Brief discussion of how to containerize legacy apps " of Pages 6-9 that (1) successful containerization programs require five critical components: (a) asses application portfolio to select the right containerization candidates; (b) select the right migration approach; (c) define and govern a fit-for-purpose target architecture to host the containerized apps; (d) reuse and govern recipes, patterns, and standards; and (e) develop a business case to progress the containerization program; (2) a cloud affinity assessment of applications is necessary to identify the right candidates within the application portfolio that are suitable for an initial form of containerization; (3) receive good results when the relevant parameters of the application are analyzed during this first pass affinity analysis; (4) the parameters should include use frequency of the app, business criticality, programming languages used, operating system, hardware requirements, database technology, and infrastructure usage, to name a few important ones; (5) after a first pass filtering is done, perform a more detailed analysis per application to understand the technology dependencies; (6) This analysis uses the code or deployment archives, such as web archives (WARs) and enterprise application archives(EARs), as input to determine which programming languages and frameworks are used; (7) this analysis should also aim to identify the parts that might be able to run independently as a container, either as macro-services or even micro-services; (8) most legacy apps can move to containers without much initial adaptation; (9) by following a containerization method on the left, less complex side of the containerization spectrum, one can manually build up a container image by defining a Dockerfile that includes all of the installations and configurations that are needed to run as a container natively on a server; (10) a more supported way is using the tool, which takes virtual machine (VM) level images as input to create a Docker container image; (11) other tooling comes into play when the legacy app needs to be refactored or recoded; (12) the most complex part of containerization is the movement of the container into a new cloud environment, where integration with the auxiliary system needs to take place, such as security authentication systems; (13) another thing to pay attention to is defining how the containerized application fits in the directory server domain; (14) reconnecting the containerized app to the required databases might require design, depending on your migration strategy for the databases, especially when the databases remain on premises; (15) for such scenarios, network design needs to be carried out to facilitate the exchange between the containerized app on the cloud and the on-premises database environment; (16) the latter is also important for the connected applications that remain on premises; (17) there are three important considerations to incorporate containers and Kubernetes in the IT landscape: (a) building a containers and Kubernetes platform is complex, which requires making many interlinked architectural decisions, especially around network and security, and since most enterprises adopt two or more hyperscaler cloud platforms, deploying a containers and Kubernetes layer increases complexity with respect to the different flavors of services that hyperscalers offer, and therefore, recommend an open architecture approach to create an overall control plane across the clouds, which can be realized by Red Hat OpenShift, which is available on all major hyperscalers; (b) containers and Kubernetes services on hyperscalers come with different service levels so one must consider what level of services (no service level, service objective, or service level agreements) fits the IT enterprise strategy best, and in many cases, enterprises adopt a fully managed containers and Kubernetes service to free up resources to focus on applications and business processes; and (c) building a containers and Kubernetes platform is a journey, and using a grow-as-you-go model for the services needed to run initial workloads as containers is the best approach to balance the investments with outcomes; e.g., start with Windows Server Containers just to host your Windows and .NET workloads; (18) capturing successful patterns and recipes for solution development and application modernization is key to repeatable success and to scale within the working domain and beyond; (19) Repeatable patterns and recipes should be captured to assess, migrate, and run applications as containers, providing a detailed description of what works and what doesn't work in the context of the specific enterprise IT landscape; (2) A well-governed and maintained containerization playbook is a good way to capture these recipes and standards; (21) a consistent business case development approach is important to fuel the containerization program; and (22) continuous business case development aligns investment with outcome and changes over time when more container technology becomes available and matures. Haasjes further teaches in Section "Technical benefits of containerizing legacy apps" of Pages 10-13 that (1) there is a fundamental difference between the results after containerization of a legacy application versus the results after virtualization; (2) virtualization focuses on how infrastructure can be defined and shared to host applications;(3) virtualization manages the dependencies with the infrastructure resources that provide a layer to run applications; (4) in contrast, containers focus on the app requirements that need to be fulfilled by infrastructure; (5) containers and Kubernetes support a declarative approach to managing these non-functional requirements; (6) imagine a traditional technology stack with hardware, an operating system, and a hosted application, and virtualization looks from the app down to the infrastructure, while containers and Kubernetes look up to the application; (7) faster handling of containers through lower footprint: the total disk volume that a container needs to run an application is lower than that of VMs, and as a result, containers are more lightweight to operate; e.g., the start-up time for containers can be within seconds, which allows for high-speed service recovery by just restarting a fresh container; (8) readiness for Kubernetes container orchestration: (a) after a legacy application is containerized, it can use container orchestration capabilities, such as those from the de facto leader, Kubernetes, which can achieve better resiliency and scalability for the app by just defining requirements and constraints that the application should adhere to; and (b) Kubernetes takes care of the container management to guarantee that the app runs according to these requirements, which increases the programmability of how and under what constraints the app should run; (9) better service automation: (a) Kubernetes container orchestration is implemented by YAML configuration files that define the outcome of the application service in terms of where it should be deployed, where it should be replicated in cases of higher load or fail-over, or how to manage persistency; and (b) in this way, deployment, scalability, resiliency, and monitoring are fully automated by the Kubernetes platform; and (c) the higher scale of automation contributes to cost takeout of service management; (10) easier flow of changes to production and continuous delivery: the declarative approach to deployment recognizes an automatic code-to-deployment process, which allows for an easier flow of changes to production and contributes to continuous delivery of application features to the business; (11) increased resiliency leads to self-healing systems: the automatic fail-over of restarting new container instances when there is a problem can increase the overall resiliency of the application landscape, which also leads to a self-healing system approach with fewer manual interactions and results in a higher uptime of the applications with less effort; (12) faster problem detection through log collection and tracing: due to the Kubernetes cluster approach of a control plane that oversees worker nodes, one can identify problems with log collection and analysis at a fine-grained level; (13) software-defined deployment: (a) Kubernetes and containers allow for a dense deployment of the application with a relatively loose coupling to the infrastructure; (b) one can keep application and domains separate with namespaces while control the compute resource allocation, network, storage, and access control; and (c) this define-once-run-everywhere concept facilitates application deployment at a global scale and in a controlled and consistent fashion; (14) higher portability of applications: (a) the standardized foundational layer of container engines and Kubernetes makes it possible to deploy apps on different environments, even on different clouds, on premises, and at the edge; and (b) this accommodates loose coupling with cloud technology providers and increases negotiation power for resource contracting; (15) lower footprint on infrastructure resources: (a) the container's low footprint and fast deployment mechanism allows for smarter deployment on infrastructure, which leads to lower resource usage; and (b) in addition to lower storage use of the application installation files, one can share compute resources among a set of applications or across non-production and productions environments; (15) legacy technology isolation: containers provide a way to isolate older technologies that are prerequisites for the application code without interfering with other application stacks; and (16) No recoding at all: (a) gain initial quick wins just by applying the simplest containerization technique possible without any recoding or refactoring of your legacy application; and (b) this low investment approach is a new path to the cloud and opens up the possibility to move more workloads to the cloud, and especially in cases where a VM lift and shift is complex due to dependencies on underlying infrastructure.
KHALAF et al. (US 2016/0261684 A1, pub. date: 09/08/2016) discloses in ABSTRACT and ¶¶ [0003]-[0005] that (1) migrate a legacy application to a multitenant computing environment; (2) at least one virtualized computing container is instantiated on a host system in a multi-tenant computing environment; (3) an instance of the legacy application is executed within the virtualized computing container; (4) the legacy application having been initially configured to run on premise and serve one tenant at a time; (5) the virtualized computing container securely isolates the executing instance of the legacy application from other executing instances of the legacy application; (6) at least one request received from a first client is sent to the instance of the legacy application executing within the virtualized computing container; and (7) the virtualized computing container is quiesced based on at least one quiescing criterion having been satisfied by the instance of the legacy application. KHALAF further discloses in ¶¶ [0019]-[0024] with FIG. 1 that (1) an interface 114 allowing a user such as a developer to access an interactive environment 116 of the computing environment 108; (2) users access the interactive environment 116 programmatically via an application programming interface (API), wherein the interactive environment 116 allows for the user to, among other things, migrate legacy applications 118 to the computing environment 108; (3) a legacy application is any application that was not originally designed and configured for a multi-tenancy computing environment such as a cloud computing environment; (4) in particular, a legacy application/code is any software application designed to run on premise (i.e., not designed to run as a cloud service) and to handle one tenant at a time; (5) legacy applications generally do not support the following properties: full isolation among users; scalability, elasticity, fault-tolerance, and high availability; high density of users; and quiescing to save resources when the system is idle; (6) a virtual machine is an emulation of a given computing system (hardware and software) and operates based on the architecture and functions of the given computing system; (7) a virtual machine comprises its own operating system that is separate from the operating system of the host machine; (8) a container, such as a Docker container, is an operating system level virtualization where the kernel of the operating system allows for multiple isolated user space instances instead of just one; (9) a container does not require a separate operating system from that of its host; (10) containers utilize the kernel's functionality and resource isolation along with separate namespaces to completely isolate an application's view of the operation system; (11) containers comprising applications 122 can be executed and run on physical machines 124, 126 or on virtual machines; (12) containers allow applications to be presented in a multi-tenancy computing environment; (13) allows for a single instance of software to be executed on a physical information processing system or a virtualized computing environment while serving multiple tenants; (14) a tenant a user or application that shares the same view of the software with other tenants, each requiring its own exclusive, secure, and isolated computing environment; (15) the tenants share the same application that is running on the same operating system and hardware; however, each tenant is provided a dedicated share of software instance including its data, configuration, user management, and the like; (16) each tenant's dedicated share is isolated from each other such that the tenant's cannot see or manipulate each other's data; (17) the load balancer 130 and the dispatcher 132 are collectively referred to herein as the "resource manager 133"; (18) the load balancer 130 utilizes one or more balancing mechanisms to select a dispatcher 132 to forward the requests to; (19) the dispatcher 132 then sends the request to the appropriate virtualized computing environment 128 associated with the request; (20) the dispatcher 132 creates and maintains tenant mapping information 138 identifying which virtualized computing environment is associated with a given tenant, which allows for the dispatcher 132 to send a request to the appropriate virtualized computing environment 128; (21) the applications 120, 122 or instances of applications generate the state data 142 at various points of time of their operation such as upon startup, upon exit or completion, and any time there between; (22) the state data 142 allows for the application or a given instance of the application to resume its operation at the time the state data 142 was saved; and (23) when the application exits for whatever reason the state data 142 contains everything that is needed by the newly started application to restore its state in memory and continue execution from the restored state. KHALAF also discloses in ¶¶ [0025]-[0035] with FIGS. 1-2 that (1) the resource manager 133 can analyze the legacy application and/or a specification or model of the application to automatically determine whether the legacy application can be migrated to the computing environment 108; e.g., the user, via the interface 114, can upload the legacy application to the computing environment 108, send a link with the location of the legacy application, and/or send a specification file and/or model of the application to the resource manager 133; (2) the resource manager 133 analyzes the legacy application, specification of the application, and/or the model of the application to identify various attributes and characteristics of the legacy application; (3) the resource manager 133 can also analyze the source code of the legacy application if available; (4) based on this analysis the resource manager 133 determines (a) if the legacy application be executed within a container; (b) if the legacy application can be changed to use a database for configuration if it is currently using a file system for configuration; (c) if the legacy application can be changed to use a database for saving its state if it is currently using a file system to save its state; and (d) if a REST API and a HTML interface can be added to the legacy application if it currently does not comprise a REST API or a HTML interface, respectively; (4) if the resource manager 133 determines that legacy application fails to satisfy any of the above requirements it notifies the user that the application cannot be migrated to the computing environment 108; (5) if the resource manager 133 determines that legacy application fails satisfies all of the above requirements it notifies the user that the application can be migrated to the computing environment 108; (5) once a determination is made that a legacy application 118 is migratable to the computing environment 108 the user or an automated agent such as the resource manager 133 adds a REST API and/or HTML interface to the legacy application 118 if not already included within the application 118; (6) the REST API and HTML interface are necessary to make the legacy application 118 accessible through the resource manager 133 as it requires uniform representation of the application resources so it can perform load balancing and dispatch requests; (7) if the legacy application 118 is currently utilizing a file system for configuration, the user or the resource manager 133 changes the application 118 to utilize a database for the configuration; (8) if the legacy application 118 is currently utilizing a file system for saving its state, the user or the resource manager 133 changes the application 118 to utilize a database for saving its state; (9) once the above changes are made (if required), an image(s) comprising the legacy application 118 and its dependencies is created by the user or the resource manager 133 for executing the application 118 within a container; and (10) a container is built from an image, which tells the resource manager 133 what the container holds, what process to run when the container is launched, and a variety of other configuration data. KHALAF further teaches in ¶¶ [0036]-[0045] with FIGS. 1-2 and 4-6 that (1) a separate container 402, 404 with a given instance of the legacy application 218 has been instantiated for each tenant requesting access to the application 218, where each container 402, 404 is securely isolated from the other; i.e., any data being accessed or generated by an instance of legacy application 218 in a given container; any processes being executed by an instance of legacy application 218 in a given container; and or the like are not accessible by other clients or other instances of the legacy application executing in other containers; (2) in addition to security isolation, performance isolation is also provided by the containers; e.g., the computer processing unit (CPU), memory, and network consumption of each tenant can be separately restricted for each container 402, 404; (3) one or more additional containers 406 can be utilize the perform administrative functions 407 such as managing data for multiple tenants; (4) a load balancer 430 is disposed between the clients/tenants 408, 410, 412 and a plurality of dispatchers 432, 433; (5) the load balancer 430 receives requests such as Hyper Text Transfer Protocol (HTTP) requests from a tenant 408, 410, 412 for interaction with the legacy application 218; (6) the load balancer 430 utilizes one or more load balancing algorithms to select one of the plurality of dispatchers 432, 433; (6) the load balancer 430 then sends the received request to the selected dispatcher 432; (7) the dispatcher 432 receives the request and analyzes the request from the load balancer 430; e.g., an extraction component (or script) of the dispatcher 432 analyzes the request to extract the tenant identifier (ID) within the request, wherein the tenant ID uniquely identifies the tenant who sent the request and the tenant ID is embedded within the uniform resource locator (URL) of the request; (8) the dispatcher 432 compares the tenant ID to data stored within the tenant mapping information 138 maintained by the dispatchers 432,433; (9) the tenant mapping information 138 comprises mappings between tenant IDs and container IDs, which uniquely identify currently running containers; (10) when the dispatcher 432 compares the tenant ID to the tenant mapping information 138 it determines if an entry exists within the mapping information 138 comprises the tenant ID extracted from the request; (11) if match exists, the dispatcher 432 identifies the container ID associated with the tenant ID and sends the request to the container 402 associated with the container ID for processing; (12) if a match does not exist (a container is not currently running that is associated with the tenant), the dispatcher 432 starts a container 404 dynamically (on the fly) with an instance of the application 218 for the requesting tenant; (13) the dispatcher 432 also adds entries in the mapping information 138 mapping the tenant to the started container; e.g., the dispatcher 432 adds entries comprising the tenant ID of the tenant and the container ID of the started container within the same record of the table 500; (14) multiple containers can be started and running for a tenant; (15) in some instances, the application 218 may be state-full, i.e., there is state or a relationship between multiple requests received from a tenant; (16) in this situation, each of the related requests comprises an instance ID that is common amongst the related requests; (17) instance ID used together with tenant ID allows ensures that all requests are sent to the same container as long as they have the same tenant ID and instance ID; (18) by using instance ID for dispatching all requests with the same instance ID to the same container (as there can be more than one) the application can perform all of the computations and modify state related to that instance ID without being concerned that multiple requests have fragmented state of the instance ID across multiple containers; (19) the dispatcher 432 tracks the relation between requests for multiple containers associated with a given tenant; e.g., in addition to maintaining tenant and container IDs in the mapping information 138 the dispatcher 432 also maintains instance IDs that it extracts from the requests; (20) when the dispatcher 432 receives a request with tenant and instance IDs, the dispatcher 432 compares these IDs to the mapping information 138 to determine which container to send the request to; (21) if a match exists, the dispatcher 432 sends the request to the container identified from the mapping information 138, which ensures that the same container receives requests associated with the same instance ID; (22) if a match does not exist (a container associated with the tenant and instance is not currently running) the dispatcher determines if there is another container currently running that is associated with the tenant ID.; (23) if so, the dispatcher 432 sends the request to this container and updates the mapping information 138 to associate the instance ID with this container; (24) if not, the dispatcher 432 starts a new container with an instance of the application 218 and updates the mapping information to map the tenant ID and instance ID to the ID of the newly started container; (25) the legacy application 218 is modified as part of the migration process to save its state a persistent store such as a database 412 as part of the application state data 142, and exit; e.g., code is added to the source code of the legacy application 218 providing the legacy application with this capability; (26) the legacy application 218 is configured to save its state and exit (the container 402 executing the application 218 stops running) when it determines that all requests have been processed and no requests are pending; (27) the dispatcher 432 detects that the container 402 has exited and removes the corresponding tenant-container mapping from the mapping information 138; (28) he legacy application 218 may not be able to be modified to exit such that its container 402 stops running so that resources can be reclaimed; (29) in this situation, the REST API added to the application 218 can be configured to notify the dispatcher if the container 402 is idle (not processing any requests); (30) if the dispatcher 432 determines that a container 402 is idle based on a notification from the container's REST API, the dispatcher stops/quiesces the container 402 to reclaim resources; and (31) the dispatcher 432 removes the corresponding tenant-container mapping from the mapping information 138. KHALAF also teaches in ¶¶ [0047]-[0049] with FIGS, 7-8 that (1) he operational flow diagram of FIG. 7 for migrating and executing a legacy application in a multi-tenant computing environment begins at step 702 and flows directly to step 704; (2) the load balancer 130, at step 704, receives a request from a client for accessing a legacy application 118; (3) the load balancer 130, at step 706, selects one of a plurality of dispatchers 132; (4) the load balancer 130, at step 708, sends the request to the selected dispatcher 132; (5) the dispatcher 132, at step 710, extracts a tenant ID from the request that uniquely identifies the client; (6) the dispatcher 132, at step 712, determines if a virtualized computing container 402 is currently mapped to the tenant ID; (7) if the result of this determination is positive, the dispatcher 132, at step 716, sends the request to the container 40; (8) if the result of the determination is negative, the dispatcher 132, at step 716, dynamically instantiates a container 402 for the client and executes an instance of the legacy application 118 within the container 402; (9) the dispatcher 132 then sends the request to the container at step 716; (10) the container 402, at step 718, processes the request; (11) the dispatcher 132, at step 720, determines if at least one quiescing criterion has been satisfied by the instance of the legacy application; (12) if the result of this determination is negative, the control flows back to step 704; (13) if the result of this determination is positive, the dispatcher 132, at step 722, quiesces the container 402; (14) the control flow exits at step 722; (15) the operational flow diagram of FIG. 8 for migrating and executing a legacy application in a multi-tenant computing environment begins at step 802 and flows directly to step 804; (16) the load balancer 130, at step 804, receives a request from a client for accessing a legacy application 118; (17) the load balancer 130, at step 806, selects one of a plurality of dispatchers 132; (18) the load balancer 130, at step 808, sends the request to the selected dispatcher 132; (19) the dispatcher 132, at step 810, determines that the request is state-full and related to at least one other request from the client; (20) the dispatcher 132, at step 812 analyses a set of mapping information 138 that maps each of a set of clients to a set of virtualized computing containers and further maps each of the set of virtualized computing containers to a set of related requests; (21) the dispatcher 132, at step 814, identifies a container 402 from a plurality of containers serving the client that is processing the requests related to the received request; (22) the dispatcher 132, at step 816, sends the request to the identified container 402; (23) the container 402 processes the request; and (24) the control flow exits at step 820.
Seth et al. (US 2023/0004370 A1, filed on 07/04/2022) discloses in ABSTRACT and ¶¶ [0002]-[0014] and [0031] that (1) deploys a data collecting agent on a machine that operates on a host computer and executes a set of one or more workload applications; (2) receive data regarding consumption of a set of resources allocated to the machine by the set of workload applications; (3) assess excess capacity of the set of resources for use to execute a set of one or more containers, and then deploys the set of one or more containers on the machine to execute one or more containerized applications; (4) the set of workload applications are legacy workloads deployed on the machine before the installation of the data collecting agent; (5) by deploying one or more containers on the machine, maximize the usages of the machine, which was previously deployed to execute legacy non-containerized workloads; (6) harvesting excess compute capacity in a set of one or more datacenters, and using the harvested excess capacity to deploy containerized applications; (7) deploys data collecting agents on several machines (e.g., virtual machines, VMs, or Pods) operating on one or more host computers in a datacenter and executing a set of one or more workload applications; (8) the data collecting agents are deployed on hypervisors executing on host computers; (9) these workload applications are legacy non-containerized workloads that were deployed on the machines before the installation of the data collecting agents; (10) from each agent deployed on a machine, iteratively (e.g., periodically) receive consumption data that specifies how much of a set of resources that is allocated to the machine is used by the set of workload applications; (11) for each machine, iteratively (e.g., periodically) computes excess capacity of the set of resources allocated to the machine; (12) use the computed excess capacities to deploy on at least one machine a set of one or more containers to execute one or more containerized applications; (13) by deploying one or more containers on one or more machines with excess capacity, maximize the usages of the machine(s); (14) to deploy the set of containers, deploy a workload first Pod, configures the set of containers to operate within the workload first Pod, and installs one or more applications to operate within each configured container; (15) define an occupancy, second Pod on the machine, and associates with this Pod a set of one or more resource consumption data values collected regarding consumption of the set of resources by the set of workload applications, or derived from this collected data; (16) some embodiments deploy an occupancy, second Pod on the machine, while other embodiments simply define one such Pod in a data store in order to emulate the set of workload applications; (17) irrespective of how the second Pod is defined or deployed, provide data regarding the set of resource consumption values associated with the occupancy, second Pod to a container manager for the container manager to use to manage the deployed set of containers on the machine; (18) use the occupancy Pod because the container manager does not manage nor has insight into the management of the set of workload applications; (19) iteratively collect data regarding consumption of the set of resources by the set of containers deployed on the workload first Pod; (20) the container manager iteratively analyzes this data along with consumption data associated with the occupancy, second Pod (i.e., with data regarding the use of the set of resources by the set of workload applications); (21) in each analysis, the container manager determines whether the host computer has sufficient resources for the deployed set of containers; (22) when it determines that the host computer does not have sufficient resources, the container manager designates one or more containers in the set of containers for migration from the host computer. Based on this designation, the containers are then migrated to one or more other host computers; (23) use priority designations (e.g., designates the occupancy, second Pod as a lower priority Pod than the workload first Pod) to ensure that when the set of resources are constrained on the host computer, the containerized workload Pod will be designated for migration from the host computer, or designated for a reduction of their resource allocations; (24) this migration or reduction of resources, in turn, ensures that the computer resources have sufficient capacity for the set of workload application. In some embodiments, one or more containers in the set of containers can be migrated from the resource constrained machine, or have their allocation of the resources reduced; (25) after deploying the set of containers, provide configuration data to a set of load balancers that configure these load balancers to distribute API calls to one or more containers in the set of containers as well as to other containers executing on the same host computer or on different host computers; (26) when a subset of containers in the deployed set of containers is moved to another computer or machine, provide updated configuration data to the set of load balancers to account for the migration of the subset of containers; (27) optimizing deployment of containerized applications across a set of one or more VPCs; (28) collect operational data from each cluster controller of a VPC that is responsible for deploying containerized applications in its VPC; (29) analyze the operational data to identify modifications to the deployment of one or more containerized applications in the set of VPCs; (30) produce a recommendation report for displaying on a display screen, in order to present the identified modifications as recommendations to an administrator of the set of VPCs; (31) moving a group of one or more containerized applications in a first VPC from a larger, first set of machines to a smaller, second set of machine, wherein the second set of machines can be a smaller subset of the first set of machines, or can include at least one other machine not in the first set of machines; (32) moving the containerized applications to the smaller, second set of machines reduces the cost for deployment of the containerized applications by using less deployed machines to execute the containerized applications; (33) identifying possible migrations of each of a group of containerized applications to new candidate machines for executing containerized application; (34) for each possible migration, using a costing engine to compute a cost associated with the migration; (35) using the computed costs to identify the possible migrations that should be recommended; (36) including in the recommendation report each possible migration that is identified as a migration that should be recommended; (37) in response to user input accepting a recommended migration of a first containerized application from a first machine to a second machine, direct a first cluster controller set of the first VPC to direct the migration of the first containerized application; (38) the computed costs are used to calculate different output values of a cost function, with each output value associated with a different deployment of the group of containerized applications; (39) use the calculated output values of the cost function to identify the possible migrations that should be recommended; and (40) identifying possible adjustments to resources allocated to each of a group of containerized applications, and produces a recommendation report by generating a recommended adjustment to at least a first allocation of a first resource to at least a first container/Pod on which a first container application executes. Seth further discloses in ¶¶ [0032]-[0056] with FIGS. 1-4 that (1) a VPC controller cluster 300 executes the process 100 of FIG. 1 to harvest excess compute capacity on machines deployed in the VPC 305, and executes the process 200 of FIG. 2 to use the harvested excess capacity to deploy containerized applications on these machines; (2) a network administrator computer 315 interacts with the global controller clusters 310 to specify workloads, policies for managing the workloads, and the VPC(s) managed by the administrator; (3) the global controller cluster 310 then directs the VPC controller cluster 300 to deploy these workloads and effectuate the specified policies; (3) each VPC includes several host computers 325, each of which executes one or more machines 330 (e.g., virtual machines, VMs, or Pods), wherein some or all of these machines 330 execute legacy workloads 335 (e.g., legacy applications), and are managed by legacy compute managers; (4) each VPC controller cluster 300 performs the process 100 to harvest excess capacity of machines 330 in its VPC 305; (5) the process 100 initially deploys (at 105) a data collecting agent 345 on each of several machines 330 in the VPC 305; (6) the VPC controller cluster 300 has a cluster agent 355 that directs the deployment of the data collecting agents 345 on the machines 330, wherein some or all of these machines 330 execute legacy workloads 335 (e.g., legacy applications, such as webserver, application servers, database servers), and these machines are referred to below as legacy workload machines; (7) from each deployed agent 345, the process 100 receives (at 110) consumption data (e.g., operational metric data) that can be used to identify the portion of a set of the host-computer resources that is consumed by the set of legacy workload applications that execute on the agent's machine; (8) the set of host-computer resources is the set of resources of the host computer 325 that has been allocated to the machine 330; (9) when multiple machines 330 execute on a host computer 325, the host computer's resources are partitioned into multiple resources sets with each resource set being allocated to a different machine, wherein examples of such resources include processor resources (e.g., processor cores or portions of processor cores), memory resources (e.g., portion of the host computer RAM), disk resources (e.g., portion of non-volatile semiconductor or hard disk storage), etc.; (10) each deployed agent 345 collects operational metrics from an operating system of the agent's machine 330; e.g. the operating system of each machine has a set of APIs that the deployed agent 345 on that machine 330 can use to collect the desired operational metrics, e.g., the amount of CPU cycles consumed by the workload applications executing on the machine, the amount of memory and/or disk used by the workload applications, etc.; (11) in some embodiments, each deployed agent 345 iteratively pushes (e.g., periodically sends) its collected operational metric data since its previous push operation, while in other embodiments the VPC controller cluster 300 iteratively pulls (e.g., periodically retrieves) the operational metrics collected by each deployment agent since its previous pull operation; (12) the cluster agent 355 of the VPC controller cluster 300 receives the collected operational metrics (through a push or pull model) from the agents 345 on the machines 330 and stores these metrics in a set of one or more data stores 360; (13) the cluster agent 355 stores the received data in the time series data store as raw data samples regarding different amounts of resources (e.g., different amounts of processor resource, memory resource, and/or disk resource that are allocated to each machine) consumed at different instances in time by the workload applications executing on the machine; (14) conjunctively, or alternatively, a data analyzer 365 of the VPC controller cluster 300 analyzes (at 115) the collected data to derive other data that is stored in the time series database; (15) the excess capacity of each machine is expressed as a set of one or more capacity values that express an overall excess capacity of the machine 330 for the set of resources allocated to the machine, or an excess capacity per each of several resources allocated to the machine (e.g., one excess capacity value for each resource in the set resources allocated to the machine); (16) the excess capacity computation (at 115) is performed by the Kubemetes (KS) master 370 of the VPC controller cluster 300; (17) the KS master 370 just uses the computed excess capacities to migrate containerized workloads deployed by the process 200 or to reduce the amount of resources allocated to the containerized workloads; (18) the KS master 370 directs the migration of the containerized workloads, or the reduction of resource to these workloads, after it retrieves the computed excess capacities and detects that one or more machines no longer have sufficient capacity for both the legacy workloads and containerized workloads deployed on the machine(s); (19) at 120, the process 100 ( e.g., the cluster agent 355) defines an occupancy Pod on each machine executing legacy workload (e.g., executing legacy workload applications), and associates with this occupancy Pod the set of one or more resource consumption values (i.e., the metrics received at 110, or values derived from these metrics) regarding consumption of the set of resources by the set of workload applications; (20) the VPC controller cluster 300 deploys the occupancy Pod because neither the KS manager 370 nor the kubelets 385 manage or have insight into the management of the set of legacy workload applications 335; (21) hence, the VPC controller cluster 300 uses the occupancy Pod 405 as a mechanism to relay information to the KS manager 370 and the kubelets 385 regarding the usages of resources by the legacy workload applications 335 on each machine 330; (22) the VPC controller cluster 300 uses priority designations (e.g., designates an occupancy Pod 405 on a machine 330 as having a higher priority than containerized workload Pods) to ensure that when the set of resources are constrained on the host computer, the containerized workload Pod will be designated for migration from the host computer, or designated for a reduction of their resource allocations; (23) this migration or reduction of resources, in turn, ensures that the computer resources have sufficient capacity for the set of workload application; (24) one or more containers in the set of containers can be migrated from the resource constrained machine, or have their allocation of the resources reduced.; (25) to compute the excess capacity, the cluster agent 355 of the VPC controller cluster 300 estimates the peak CPU/memory usage of legacy workloads 335 by analyzing the data sample records stored in the time series database 360, and sets the request of the occupancy Pod 405 to the peak usage of legacy workloads 335; (26) the occupancy Pod 405 prevents containerized workloads from being scheduled on machines that do not have sufficient resources due to legacy workloads 335; (27) the peak usage of legacy workloads 335 is calculated by subtracting the Pod total usage from the machine total usage; (28) the cluster agent 355 sets the QoS class of occupancy Pods 405 to guaranteed by setting the resource limits, and by setting the priority of occupancy Pods 405 to a value higher than the default priority; (28) based on these two settings, bias the eviction process of the kubelet 385 operating within each host agent 345 to prefer evicting containerized workloads over occupancy Pods; (29) since both occupancy Pods and containerized workloads are in the guaranteed QoS class, the kubelet 385 evicts containerized workloads, which have lower priority than occupancy Pods; (30) the priority of the occupancy Pods is also needed to allow occupancy Pods to preempt containerized workloads that are already running on a machine; (31) once occupancy Pods become guaranteed, the OOM (ONAP (Open Network Automation Platform) Operation Manager) operating on the machine 330 will prefer evicting containerized workloads over evicting occupancy Pods since the usage of occupancy Pods is close to O (just "sleep" process); (32) the process 200 that uses the computed excess capacities of the legacy workload machines in order to select one or more of these machines and to deploy one or more sets of containers on these machines to execute containerized applications; (33) the process 200 starts each time that one or more sets of containerized applications have to be deployed in a VPC 305; (34) the process 200 initially selects (at 205) a machine in the VPC with excess capacity, wherein this machines can be a legacy workload machine with excess capacity, or a machine that executes no legacy workloads; (35) the process 200 selects legacy workload machines so long as such machines are available with a minimum excess capacity of X % ( e.g., 30% ); (36) select the legacy workload machine in the VPC with the highest excess capacity; (37) when the VPC 305 does not have legacy workload machines with the minimum excess capacity, the process 200 selects (at 205) a machine that does not execute any legacy workloads; (38) at 210, the process 200 selects a set of one or more containers that need to be deployed in the VPC; (39) next, at 215, the process 200 deploys a workload Pod on the machine selected at 205, deploys the container set selected at 210 onto this workload Pod, and installs and configures one or more applications to run on each container in the container set deployed at 215; (40) at 220, the process 200 adjusts the excess capacity of the selected machine to account for the new workload Pod 420 that was deployed on it at 215; (41) this adjustment is just a static adjustment of the machine's capacity (as stored on the VPC controller cluster data store 360) for a first time period, until data samples are collected by the agent 345 (executing on the selected machine 330) a transient amount of time after the workload Pod starts to operate on the selected machine; (42) the process 200 does not adjust the excess capacity value of the selected machine 330, but rather allows for this value to be adjusted by the VPC controller cluster processes after the consumption data values are received from the agent 345 deployed on the machine; (43) after 220, the process 200 determines (at 225) whether it has deployed all the containers that need to be deployed; (44) if so, it ends; (45) otherwise, it returns to 205 to select a machine for the next container set that needs to be deployed, and then repeats its operations 210-225 for the next container set; and (46) by deploying one or more containers on legacy workload machines, the process 200 maximizes the usages of these machines, which were previously deployed to execute legacy noncontainerized workloads. Seth also discloses in ¶¶ [0056]-[0062] with FIGS. 5-7 that (1) continuously monitor consumption of resources on machines with containerized workloads, and to migrate, or to adjust resource allocations, to the containerized workloads when the process detects a lack of resources for the legacy workloads on these machines; (2) the process 500 collects (at 505) data regarding consumption of resources by legacy and containerized workloads executing on machines in the VPC; (3) at 510, the process analyzes the collected data to determine whether it has identified a lack of sufficient resources (e.g., memory, CPU, disk, etc.) for any of the legacy workloads; (4) if not, the process returns to 505 to collect additional data regarding resource consumption; (5) otherwise, when the process identifies (at 510) that the set of resources allocated to a machine are not sufficient for a legacy workload application executing on the machine, the process modifies (at 515) the deployment of the containerized application(s) on the machine to make additional resources available to the legacy workload application, wherein examples of such a modification include (a) migrating one or more containerized workloads that are deployed on the machine to another machine in order to free up additional resources for the legacy workload application(s) on the machine, or (b) reducing the allocation of resources to one or more containerized workloads on the machine to free up more of the resources for the legacy workload application(s) on the machine; (6) when migrating a containerized application to a new machine, the process 500 moves the containerized application to a machine (with or without legacy workloads) that has sufficient resource capacity for the migrating containerized application; (7) when the process 500 moves the containerized workload to another machine, the process 500 configures (at 520) forwarding elements and/or load balancers in the VPC to forward API (application programming interface) requests that are sent to the containerized application to the new machine that now executes the containerized application; (8) when a container is migrated to another computer or machine to free up resources for legacy workloads, the process 500 provides updated configuration data to the set of load balancers to account for the migration of the container; and (9) after 520, the process 500 returns to 505 to continue its monitoring of the resource consumption of the legacy and containerized workloads. Seth further teaches in ¶¶ [0063]-[0070] with FIGS. 8-9 that (1) he process 800 starts (at 805) when an administrator directs the global controller cluster 310 through its user interface (e.g., its web interface or APIs) to reduce the number of machines on which the legacy and containerized workloads managed by the administrator are deployed; (2) next, at 810, the process 800 identifies a set of machines to examine, and for each machine in the set, identifies excess capacity of the set of resources allocated to the machine; (3) at 815, the process 800 explores different solutions for packing different combinations of legacy and containerized workloads onto a smaller set of machines than the set of machines identified at 810; (4) the process 800 then selects (at 820) one of the explored solutions.; (5) the process 800 uses a constrained optimization search process to explore the different packing solutions and to select an optimal solution from the explored solutions; and (6) after selecting a packing solution, the process 800 migrates (at 825) one or more legacy workloads and/or containerized workloads in order to implement the selected packing solution. Seth also teaches in ¶¶ [0073]-[0085] with FIGS. 10-12 that (1) a global controller 310 with a recommendation engine 1020 that generates cost simulation results and optimization plans; (2) the cluster monitor 1040 receives operational metrics from each VPC controller cluster through the VPC interface 1015, wherein these operational metrics are metrics collected by the capacity harvesting agents 345 deployed on the machines in each VPC; (3) the recommendation engine 1020 retrieves data samples from the time series database, and generates cost simulation results as well as optimization plans; (4) the recommendation engine uses its optimization search engine 1025 to identify different optimization solutions, and uses its costing engine 1030 to compute a cost for each identified solution; (5) the recommendation engine 1020 generates a report that identifies the usage results that it has identified, as well as the cost simulation and optimization plan that engine has generated; (6) the recommendation engine 1020 then provides this report to the network administrator through one or more electronic mechanisms, such as email, web interface, API, etc.; (7) the administrator reviews this report and decides whether to apply one or more of the presented plans; (8) when the administrator decides to apply the plan for one or more of the VPCs, the workload manager 1010 of the global controller 310 sends a command to the cluster agent of the controller cluster of each affected VPC; (9) each cluster agent that receives a command then makes the API calls to cloud infrastructure managers (e.g., the AWS managers) to execute the plan (e.g., resize instance types); (10) the process 1100 initially collects (at 1105) placement information regarding current deployment of legacy and containerized workloads; (11) next, at 1110, the process 1100 computes excess capacity of the machines identified at 1105; (12) at 1115, the process 1100 explores different solutions for packing different combinations of legacy and containerized workloads onto existing and new machines in one or more VPCs; (13) the process 1100 then generates (at 1120) a report that includes one or more recommendations for one or more possible optimizations to the current deployment of the legacy and containerized workloads; (14) the administrator reviews this report and accept (at 1125) one or more of the presented recommendations; (15) the recommendation engine 1020 then directs the workload manager 1010 to instruct (at 1130) the VPC controller cluster(s) to migrate one or more legacy workloads and/or containerized workloads in order to implement the selected recommendation; and (16) for this migration, the VPC controllers also configures (at 1135) forwarding elements and/or load balancers in one or more affected VPCs to forward API ( application programming interface) requests that are sent to the migrated workload applications to the new machine on which the workloads now execute.
Rivas (US 12,530,222 B1, filed on 02/10/2021) discloses in Col. 6, line 1 – Col. 11, line 64 with FIGS.1 and 13 that (1) the servers 108 may operate as a cloud provider that dynamically manages the allocation and provisioning of physical computing resources (e.g., GPU s, CPUs, 5 QPUs, etc.); (2) accordingly, the servers 108 may provide services by defining virtualized resources for each user account; e.g., the virtualized resources may be constructed as virtual machines, containers, or virtualized resources that can be provisioned for a user account and in an example implementation may be configured by a user; e.g., utilize containers as virtualized resources is shown in FIG. 13; (3) the Container Management & Execution System 1312 is implemented using a resource such as, e.g., Kubernetes® which is an example of a software platform for container management; (4) the server 108 creates and manages virtualized resources for each user account; e.g., operate as a virtual computing resource for users of the cloud-based QC environment; (5) the virtualized resource may engage either of the quantum processor units 102A, 102B, and interact with a remote user device (110B or 110C) to provide a user programming environment; (6) the virtualized resource may operate in close physical 35 proximity to and have a low-latency communication link with the quantum computing systems 103A, 103B; (7) the servers 108 can allocate quantum and classical computing resources in the hybrid computing environment, and delegate programs to the allocated computing resources for execution; (8) the quantum computing resources in the hybrid environment may include, for example, one or more quantum processing units (QPUs), one or more quantum processing simulators (such as the Rigetti Computing QVM), or possibly other types of quantum resources; (9) hybrid classical/quantum algorithms may employ a variational execution model in order to accomplish tasks such as, e.g., solving combinatorial optimization problems or simulating quantum chemistry; (10) the server 108 can generate an initial quantum program (e.g., based on a proposed solution to a problem, starting with an initial guess, etc.), and send the initial quantum program to quantum computer resource (e.g., the quantum computer system 103A, the quantum computer system 103B, a QVM, or a combination of them) for execution; (11) then, from the output of executing the initial quantum program, a classical optimizer running on the server 108 (or another classical computer resource) may update the quantum program for the next round of iteration on the quantum computer resource; (12) depending on the difficulty of the problem, the quality of the quantum computer resource, and other factors, the iteration loop may be repeated many times before completing the computational task; (13) the servers 108 can select the type of computing resource (e.g., quantum or classical) to execute an individual program, or part of a program, in the computing system 101; e.g., the servers 108 may select a particular quantum processing unit (QPU) or other computing resource based on availability of the resource, speed of the resource, information or state capacity of the resource, a performance metric ( e.g., process fidelity) of the resource, or based on a combination of these and other factors; (14) the servers 108 can perform load balancing, resource testing and calibration, and other types of operations to improve or optimize computing performance; (15) process quantum information by applying control signals to the qubits in the quantum processing unit 102A, wherein the control signals can be configured to encode information in the qubits, to process the information by performing quantum logic gates or other types of operations, or to extract information from the qubits; (16) the operations can be expressed as single-qubit quantum logic gates, two-qubit quantum logic gates, or other types of quantum logic gates that operate on one or more qubits; (17) a quantum logic circuit, which includes a sequence of quantum logic operations, can be applied to the qubits to perform a quantum algorithm, wherein the quantum algorithm may correspond to a computational task, a hardware test, a quantum error correction procedure, a quantum state distillation procedure, or a combination of these and other types of operations; (18) the controllers 106A extract qubit state information from qubit readout signals, e.g., to identify the quantum states of qubits in the quantum processing unit 102A or for other purposes; e.g., the controllers may receive the qubit readout signals (e.g., in the form of analog waveforms) from the signal hardware 104A, digitize the qubit readout signals, and extract qubit state information from the digitized signals; (19) the controllers 106A compute measurement statistics based on qubit state information from multiple shots of a quantum program; e.g., each shot may produce a bitstring representing qubit state measurements for a single execution of the quantum program, and a collection of bitstrings from multiple shots may be analyzed to compute quantum state probabilities; (20) the controllers 106A may include an optimizer that performs classical computational tasks of a hybrid classical/quantum program; and (21) the controllers 106A may update binary programs ( e.g., at runtime) to include new parameters based on an output of the optimizer, etc. Rivas further discloses in Col. 11, line 65 – Col. 14, line 64 with FIG.2 that (1) the host server 220 shown in FIG. 2 includes a virtualized resource 222, which includes a programming environment and software development kit (SDK) 224; (2) the host server 220 further includes a compiler 221 which allows the virtualized resource 222 to convert device-independent quantum programs (e.g., Quil programs) into binary programs that can be sent to the engine 240 for execution; (3) the host server 220 includes a Quantum Virtual Machine (QVM) 223, which allows the virtualized resource 222 to classically simulate the execution of quantum programs; (4) the SDK includes a QVM (e.g., for simulating smaller numbers of qubit; say less than 30 qubits), wherein the QVM can operate on a separate high-performance computer that allows for simulating large number of qubits, e.g., greater than 30 qubits; (5) the compiler 221 can operate on a separate server, as part of the virtualized resource 222 on the host server 220, or otherwise; (6) when the virtualized resource 222 operates on the host server 220, the virtualized resource 222 provides a virtualized execution environment for quantum programs (which may include hybrid classical/quantum programs); (7) the virtualized representation of the execution environment allows many user accounts to concurrently utilize the hardware resources in the computing system 200 (e.g., rather than allocating distinct hardware elements to each user account); e.g., virtualized representations may provide each user account a respective virtualized resource 222 that can be loaded on the host server 220 (e.g., concurrently) to access a collection of virtual resources (e.g., classical processors, memory, operating system, applications, etc.); (8) the virtualized resource 222 may be implemented as a virtual machine image that operates on virtual computing resource such as, e.g., a virtual machine or a container; (9) the virtualized resource 222 may be stored ( e.g., as one or more files on the host server 220 or a storage server), e.g., to save a configuration of an execution environment; e.g. a virtualized resource 222 can be stored with default configuration settings, with user-defined configuration settings, or otherwise; (10) thus, the virtualized resource 222 may represent a preconfigured execution environment; (11) when a user's virtualized resource 222 has access to a quantum resource, then the user's virtualized resource 222 is QPU-engaged, and otherwise, the virtualized resource 222 is disengaged; (12) the engagement process is comprised of a defined list of tasks that allows the virtualized resource 222 to obtain access to the quantum resource; (13) if there are enough quantum resources, the engagement process can be automatic; (14) once a user's account is connected to the virtualized resource 222, the user may develop quantum programs (which may include hybrid classical/quantum programs), e.g., using quantum instruction languages ( e.g., Quil), wherein the generated quantum programs are not necessarily readable by the electronics in the rack 250; (15) the quantum programs are transformed into instrument commands before the programs can be used to manipulate the state of the QPU 260; (16) the virtualized resource 222 may become QPU-engaged by establishing a connection with the QPU 260 (e.g., by closing the switchable link 230); (17) when the virtualized resource 222 is QPU-engaged and the compiler 221 has compiled the quantum program into instrument binaries, the virtualized resource 222 may obtain access to the engine 240 where the instrument binaries are loaded and run; (18) the run time can be optimized for hybrid classical/quantum execution, e.g., using binary patching and possibly other techniques, wherein binary patching can be accomplished, e.g., by updating a partial binary program for execution (e.g., by filling in an incomplete data memory section of an instrument binary that has instructions in its instruction memory that reference incomplete entries in that data memory section); (19) low-latency hybrid execution may be enhanced by an active reset process or another process that quickly sets all or individual qubits in the QPU 260 to a fiducial state (e.g., the ground state or another basis state); and (20) such an active reset process may reduce the delay between running successive programs on the QPU 260, by as much as an order of magnitude in some instances. Rivas also discloses in Col. 14, line 65 – Col. 16, line 45 with FIG. 3 that (1) a virtualized resource configuration 300 includes a classical processing unit (CPU) 320 that is powerful enough to perform mathematical optimization routines such as Nelder-Mead, e.g., rapidly enough to be within the hybrid classical/quantum program execution loop, or to perform post-processing/analysis on data taken from the QPU 350; (2) the virtualized resource configuration 300 also includes a virtualized resource 310 that includes a quantum software development kit (SDK) 315, where each user account has a virtualized resource 310 and resource latency is important, the virtualized resource 310 can be packaged as a virtual machine image; (3) packaging the virtualized resource 310 as a virtual machine image may facilitate easy replication and migration of the virtualized resource 310; (4) virtual packaging allows full control of an underlying network stack 340 and classical resources (e.g., random access memory (RAM) 330 and classical processing unit (CPU) 320); (5) the virtualized resource 310 can be configured/reconfigured according to the quantum resource that is being targeted for execution; (6) the virtualized resource 310 is deployed on-premises with the QPU 350, to allow the virtualized resource 310 to establish low-latency access to the QPU; (7) when users have access to a preconfigured quantum programming environment (such as e.g., PYQUIL®) on the virtualized resource 310, they can build quantum programs, compile them to instrument binaries using a compiler 360, and execute them on the QPU 350; (8) in order to further accelerate the classical optimization component of the hybrid classical/quantum programming loop, a graphical processing unit (GPU) (not shown) can be leveraged in addition to the CPU 320; (9) when quantum resources are scarce, the virtualized resource 310 can access a simulator as a development tool to test or debug their quantum programs between scheduled QPU 55 access time; e.g., the virtualized resource 310 can run a quantum program on the QVM to benchmark the quantum program; (10) in addition to the base quantum programming environment, the virtualized resource 310 can include a quantum SDK 315 with tools for composing quantum programs for various applications, e.g., for quantum chemistry simulations or machine learning; and (11) additional high-performance computing resources can be used for some applications of quantum computing, e.g., where the post processing and analysis of data output from the QPU is more (classical) resource intensive than is practical to provide on every virtualized resource. Rivas further teaches in Col.17, line 57 – Col. 19, line 14 with FIG. 5 that (1) a hybrid classical/quantum program execution process 500 can be used to optimize or otherwise improve execution of a hybrid classical/quantum program such as, e.g., a MAXCUT-style parametrized ansatz hybrid classical/quantum program; (2) at 510, a quantum program written in a quantum instruction language is compiled to a set of parametric instrument binaries to form a binary program; (3) at 520, a desired parameter set is accessed for collection of desired parameters; (4) at 530, the parametric instrument binaries corresponding to the compiled quantum program are sent to a quantum computer system for execution (e.g., to an engine that provides access to a QPU); (5) at 540, the parametric/patchable binaries are filled in with the desired parameters for the current run; (6) at 550, the quantum program is executed on the QPU; (7) at 560, the results of the execution at 550 by the QPU are received by the virtualized resource; (8) at 570, a decision engine determines whether further runs are necessary to satisfy the termination condition or whether the condition has already been reached; (9) if the condition has already been reached, the loop is exited and the process ends at 590; (10) if the condition has not been met, the process 500 proceeds to classical optimization at 580; (11) at 580, using the results received at 560, an optimization engine performs classical optimization to compute the parameters for the next run; (12) the new parameters are then chosen at 520, providing the desired parameter set, and the loop is repeated; (13) operations 520, 530 and 540 40 can be collapsed into the step of loading the parametric program onto the instruments once for all subsequent executions; (14) in some cases, within each iteration only the parameter memory section of the binary program is updated, which can further reduce the time required to load settings onto the instruments; and (15) parametric compilation may be used, e.g., in the hybrid execution model represented by the process 500 or in other contexts, wherein parametric compilation includes two types of processes: (a) generating native programs, e.g., using Quil, and (b) generating parametric binaries from the native programs. Rivas also teaches in Col. 25, line 46 – Col. 31, line 26 with FIGS. 13-16 that (1) a computing environment 1300 using containers as virtual resources includes a developer 1302, data centers 1304, 1330, 1331, 1332 such as a server, a collection or a cluster of servers, server farm, container farm, etc.; (2) the Non-Quantum Application Execution Elements 1316 may include a Container Management & Execution System such as the Container Management & Execution System 1312; (3) the API 1335 shown in FIG. 13 is configured to provide one or more administration functions such as, e.g. account management services, security credentials, billing reports, etc.; (4) the API 1335 may also provide a common entry point enabling user devices to access and interact with the computing system 1308; (5) the API 1335 may be connected to Container Management & Execution System 1312 by communication channel 1341; (6) the API 1335 may include one or more servers, virtual machines or containers configured as a single machine or distributed configurations depending on the number of user requests; (7) the computing system 1308 may include a container management and execution system 1312 which may include multiple nodes 1320 which may be configured to provide container management and execution services to users; (8) the nodes 1320 are configured to interact with the quantum computing system 1314 within the computing system 1308 by communication channel 1343 to provide low communication latency, e.g., when frequent access to the quantum computing system 1314 by the user's classical application workload managed by the container management and execution system 1312 is utilized; (9) workloads provided by the user are managed as application containers 1322 deployed on the nodes 1320 of the computing system 1308; (10) container orchestration may be deployed as an automatic process of coordinating, scheduling, and managing containers; (11) each of the containers 1322 may include an application, an operating system (OS), dependencies, etc.; and in some cases, a container 1322 gets executed based on access policies, priorities and any other pre-defined criteria on one node 1320; (12) a container-based workload management framework allows flexible, automated mapping of workloads to classical computing resources; e.g., using the container-based workloads management framework, a container can be executed on any available classical computing resource and the classical computing resources can be dynamically allocated as the workloads dynamically reshape; (13) the container-based workload management framework may enable simple, automated recovery from hardware failures; (14) the container management and execution system 1312 can use its collective hardware resources (represented as the nodes 1320) to operate containers 1322 from a number of different user devices (clients) or a number of different virtualized resources, or to operate multiple containers 1322 from the same client representing e.g. multiple instances of a container; e.g., the same classical hardware can receive containers 1322 from different clients, receive multiple containers from one client, receive a container from one client for which multiple instances are to be run, etc., and operate two or more of the containers 1322 concurrently (e.g., in parallel); (15) accordingly, the quantum computing system 1314 may be accessed and utilized by multiple containers 1322 concurrently, which may entail secure, concurrent utilization of quantum resources by multiple different clients; (16) the quantum computing system 1314 may be accessed and utilized by multiple containers 1322 concurrently, which may entail secure, serial utilization of quantum resources by multiple different clients, wherein the utilization is managed by a scheduler or orchestrator, which may improve utilization of quantum resources without compromising speed, security and other system attributes; (17) the classical resources running in a container management system 1312 may be moved into a separate data center; (18) FIG. 15 shows a system 1500 with a multiplicity of Container Management & Execution Systems 15121, 15122, 15123 (there may be two or more of these container management systems) in Data Center(s) 1533; (19) a multiplicity of communication channels 1541 are shown between API 1335 and the container management systems — one communication channel per container management system; and (20) system 1600 comprises container management systems 16121 and 16122 which may be strategically utilized during running a quantum computing job where a very low latency communication channel 16432 is desired for part of the job, and a higher latency communication channel 16431 can be tolerated for other parts of the job.
Durazzo et al. (US 2021/0406151 A1, pub. date: 12/30/2021) discloses in ¶¶ [0008]-[0012] that (1) determining, for one or more particular tasks, whether real QPUs (quantum Processing Units) or simulation should be used to carry out the task, and for allocating computing resources accordingly; (2) provide the abstraction for the infrastructure of a quantum computing platform that may offer end-to-end computing solutions with both real quantum processing units and quantum simulation clusters; (3) the standard resource allocation infrastructure problems of the cloud have an added level of complexity due to QPU scarcity and availability of quantum simulation alternatives; (4) employ a runtime statistics estimator to predict resource consumption of quantum circuits on different hardware, and then efficiently allocate clusters either in one datacenter or cross-datacenter; (5) embrace a quantum computing platform that offers an end-to-end solution in which both real quantum processing units and quantum simulation clusters may be employed to perform computing tasks; (6) an estimator may be provided that may predict runtime statistics of quantum algorithms, including the execution time and memory space requirements; (7) the information may then be transformed into a recommendation as to whether real QPUs, or simulation, should be used for one or more computing tasks; (8) quantum computing resources and/or quantum simulation may allocated and employed for one or more particular tasks in order to take best advantage of the strengths of each type of computing; (9) employ both real quantum processing units (QPU) and quantum simulation clusters, depending upon the particular circumstances; (10) provide for automated allocation of resources such as QPU and quantum simulation clusters; and (11) provide for allocation of resources based on actual, and/or expected, usage of those resources. Durazzo further discloses in ¶¶ [0014]-[0022] that (1) Quantum Processing Units (QPUs), may be able to construct and manipulate a quantum state in a controlled way, so as to perform computing tasks; (2) although QPUs may not outperform CPUs (Central Processing Unit) for many tasks, QPUs may potentially be much better at solving certain problems; (3) concern hardware resource and runtime statistics prediction for quantum computing and simulation; (4) when using a real QPU, quantum algorithms may have to wait in a queue to be executed one after the other; (5) notably, if a circuit claims to use a qubit, then it is expected that qubit will be in use until the circuit is done executing the quantum algorithm; (6) thus, provide for a quantum computing platform that is configured to, and does, provide an estimated wait time for jobs in a queue; (7) in this way, establish reasonable expectations as to when a quantum algorithm may be expected to begin, and complete, execution; (8) effective in addressing hardware resource allocation for quantum computing simulations; (9) quantum computing simulations may require significant processing, memory, bandwidth, and/or storage, resources; (10)however, it may be unlikely that a quantum simulation cluster is consistently using the same amount of resources, since different quantum circuits may require different amount of resources based on the number of qubits consumed by the quantum circuits; (11) when a computing cluster does not have enough resources, it may not be able to execute quantum computing jobs; (12) on the other hand, when a computing cluster has excess resources that it is not consuming, the computing cluster may be preventing other use cases from being executed; (13) thus, provide for a mechanism to dynamically allocate one or more resources for quantum computing clusters based on usage, rather than employing a static resource allocation process; (14) moreover, because each iteration of quantum algorithm development may impact the number of qubits required for execution of the updated algorithm, determine the resources required by the algorithm prior its execution, so that those resources can be allocated accurately; (15) effective in addressing container development, management and deployment; and (16) challenge with traditional software development may still apply to quantum computing software, such as code development, management and deployment. Durazzo also discloses in ¶¶ [0023]-[0042] with FIG. 1 that (1) the operating environment 100 may comprise a runtime cluster 125, a marketplace 150, a quantum simulation cluster 175, and a real hardware group 200; (2) the runtime cluster 125 may comprise, e.g., one or more applications 127, runtime module, system, information and parameters 129 (which may be collectively referred to as 'runtime environment'), Open-QUASM 131 (Open Quantum Assembly Language); (3) the runtime environment 129 may also include a runtime statistic estimator module, which may also be referred to herein simply as an 'estimator'; (3) the runtime cluster 125 may further comprise quantum middleware 133, one or more container images such as an image of the container 135, an OS (operating system) 137, and a container host 139.; (4) the marketplace 150, which may communicate with the quantum middleware 133, may comprise a service broker 152, and middleware 154; (5) the quantum simulation cluster 175 may comprise a quantum virtualization module 177, a quantum computing simulation module 179, a CaaS (Computing as a Service) module 181, one or more container hosts 183, and a cluster orchestration module 185; (6) finally, the real hardware group 200 may comprise any hardware needed to carry out any computing processes, and computing related processes.; (7) further, the real hardware group 200 may be abstracted by a quantum virtualization module 202; i.e., a representation of hardware of the real hardware group 200 may be created, and presented to a user, by the quantum virtualization module 202; (8) a software development cycle, for applications that may employ quantum computing, may include stages for writing, testing, and deployment of quantum code; (9) initially, the process may being with software development and containerization; e.g., the DevOps engineer may begin by creating quantum code written in traditional programming language, such as C/C++, or Python; (10) after the software is created and configured, the DevOps engineer may create a container image using Docker, or any other container image management framework; (11) a base container image, such as an image of the container 135 may include one, some, or all, elements of a quantum runtime group such as the quantum runtime group 125, such as the quantum middleware 133; (12) the container 135 may be constructed and upload to a container image repository (e.g., the service marketplace 154); (13) once the container is uploaded to a container image repository, the DevOps engineer may go into the marketplace 150 to take the service(s) available that best match her need; (14) depending on the service marketplace 150 that is used, the service broker 152 may be employed; (15) different service broker APIs, such as and Open Service Broker API e.g., may be available for platform teams to define their services in a marketplace, such as the service marketplace 154, and to offer those services to customers; (16) when the container 135 and associated service(s) are ready, the services, which may be accessible by way of the service marketplace 150, may be executed for the benefit of a user that requested the service(s); (17) the quantum binary 131 comprises quantum code, rather than any hardware, although a quantum binary may also be referred to herein as a quantum circuit; (18) thus, as used herein, a 'quantum circuit' embraces an executable computational routine that may include one or more quantum operations which may be performed on quantum data such as qubits; (19) when the compilation is completed, the compiled quantum binary 131 may be transmitted to the quantum middleware 133, defined in the same container image, such as the container 135; (20) based on the particular quantum computing service(s) bound to the container, the quantum middleware 133 may then operate to obtain the destination and credentials that enable the quantum computing service( s) to communicate with the quantum simulation cluster 175; (21) the quantum code may also be referred to herein as 'software' or as a 'quantum algorithm'; (22) a container may be created that includes the quantum code, and a container image of the container may be generated; (23) the container image may be a binary that includes all the requirements needed to run the container, and may also include any associated metadata that describe the needs and capabilities of the container; (24) the service(s) provided by the quantum code, and included in the container, may then be made available to users through a marketplace; (25) when the quantum code is ready to be run, the runtime cluster may identify programming instructions in the quantum code which may require quantum computing; (26) the estimator of the runtime cluster 125, may, based on information provided to it by the quantum middleware 133, estimate one or more runtime statistics for one or more quantum computing services, that is, the services provided as a result of execution of one or more quantum circuits; (27) such runtime statistics may include, but are not limited to, the execution time and memory space consumption for the quantum computing services; (28) such estimates may be based on historical information for the same, or similar, quantum computing services; (29) the estimator of the runtime cluster may be implemented in various ways and, depending on the platform and use case, different implementations may be chosen; (30) in one example implementation, an estimator may employ a bottom-up approach in which the estimator may scan through the quantum binary 131 code, that is, the code embodied by one or more quantum circuits, from bottom to top; (31) for each instruction included in the code, the estimator may predict the time cost of that instruction, that is, the amount of time it will take to execute the instruction; (32) the instruction costs may be summed to predict, e.g., the time and/or memory space required by each quantum algorithm; i.e., the code in the container 135; (33) in cases where the quantum circuit will be run with quantum simulation, entanglement may be explicitly predicted from historical data; (34) 'entanglement' or 'quantum entanglement' refers to a physical phenomenon, wherein particularly, this physical phenomenon may occur when a group of two or more particles are related in some way such that the quantum state of a particle in the group cannot be described independently of the respective quantum states of the other particle(s) in the group; (35) in another example implementation, an estimator may alternatively employ a top-down approach which may involve the use of machine learning (ML); (36) in the top-down approach, the estimator may make one or more predictions based on previously defined ML models, wherein these ML models may be trained by historical data from experimentations; (37) an estimator may provide the quantum simulation cluster 175 with at least two predictions or inputs, namely, execution time for the quantum code, and memory space requirements for execution of the quantum code; (38) another input that may be generated by an estimator is processing requirements for execution of the quantum code; (39) as noted earlier, the estimator may reside in the runtime cluster 125, although that is not necessarily required; (40) thus, the runtime cluster 125 may communicate directly with the quantum simulation cluster 175, and/or indirectly with the quantum simulation cluster 175, such as by way of the marketplace 150; (41) a cluster orchestration module 185 of the quantum simulation cluster 175 may determine how to best execute the quantum algorithm based on available resource and user-chosen service plan; i.e. the cluster orchestration module 185 may determine how to employ processing resources in the execution of the quantum algorithm; (42) the determination may be optimal based on the expected availability of processing resources during the time when the quantum algorithm is to be run; (43) possible choices of processing resources may include, but are not limited to, QPUs, GPUs, and CPUs; (44) the processing resources are not required to reside at any particular location; (45) when a real QPU is unavailable to support execution of a quantum algorithm, quantum computing simulation may be possible, depending upon the requirements of the quantum circuit to be executed; (46) in a case that a quantum circuit may require more qubits for execution than are available, the simulation cluster 175, which would otherwise execute the quantum circuit, may error out; (47) in the case when the resources required for execution of quantum circuit fit within the total available resources, but some resources are consumed by another quantum circuit, the pending quantum circuit may enter a queue and return with a waiting-time estimation based on the jobs in front of it; (48) suppose that there is a pool of processing resources, such as RAM, CPUs, and GPUs, available for different types of use cases, one of which is a quantum computing simulation, and based on the resource(s) required for the use cases, the cluster orchestration component 185 may reserve the necessary resource and orchestrate to create a simulation cluster, which may be an ad hoc simulation cluster specifically created for a particular quantum computing simulation job; (49) the simulation cluster may be created by the cluster orchestration component 185 using the elements of the quantum simulation cluster 175; (50) once the simulation cluster is in place, the simulation cluster may then execute the quantum circuit, and the resources that had been allocated for that quantum circuit may be released after execution of the quantum circuit; (51) an estimator that may be operable to predict runtime statistics for a quantum circuit, such as execution time and memory space required; (52) a cluster orchestration engine may be operable to dynamically allocate, and release, resources based on estimated resources required for quantum circuits, as determined by an estimator; (53) implement dynamic resource allocation in quantum simulation by way of a cluster orchestration engine that may employ execution data, such as entanglement from quantum simulation, to dynamically allocate, and release, CPU and GPU resources for quantum simulation processes; (54) provide for service-based quantum execution environment with full resource utilization; (55) adjust resource consumption based on actual qubit usage by quantum circuits, so that the user would not need to adjust a service level when software changes, or there are qubits that are unused by a quantum circuit; (56) provide for fast error prediction on quantum circuits; (57) error out if a determination is made that there will not be sufficient resources to execute a quantum circuit, thus saving time for both the author of that circuit and for other users waiting for available resources; (58) provide for container-based quantum code deployment with a pass-through OS layer; i.e., enable the deployment of quantum code using containers; (59) provide for hybrid-cloud orchestration for quantum compute processes; e.g., by having de-coupled a container orchestration environment and quantum computing execution environment, a hybrid or multi-cloud orchestration model may be possible; and (60) the quantum simulation clusters may be orchestrated dynamically and share resource with other use cases, such as cloud native applications, AI (Artificial Intelligence), and ML (Machine Learning). Durazzo further teaches in ¶¶ [0045]-[0048] with FIG. 3 that (1) method 300 may begin with the scanning 302 of the code of a quantum circuit; (2) based on the scanning 302 of the code, an estimate may then be generated 304 of one or more runtime statistics implicated by the code, wherein (a) such runtime statistics may comprise, e.g., the amount of time needed for execution of the quantum circuit, and memory space requirements for execution of the quantum circuit; and (b) such memory space requirements may identify, e.g., an amount of RAM needed to support execution of the quantum circuits; (3) based on the outcome of the estimating process 304, a recommendation may then be generated 306 as to whether, e.g., one or more QPUs should be used to execution the quantum circuit or, alternatively, whether a quantum simulation should be employed for execution of the quantum circuit; (4) the recommendation that is generated 306 may indicate that execution of the quantum circuit should be split between one or more QPUs and a quantum simulation process; (5) after the recommendation is generated 306, a check may be performed 308 to determine whether adequate resources, such as QPUs, memory space, processing resources, and/or, quantum simulation resources, will be available when needed to execute the quantum circuit; (6) if adequate resources will not be available, the method 200 may terminate and the next quantum circuit in a queue may be scanned 302; (7) on the other hand, if adequate resources will be available to execute the quantum circuit, those resources may be allocated 310 for execution of the quantum circuit; (8) using the allocated resources, the quantum circuit may then be executed 312; and (9) after the quantum circuit has been executed 312, the resources that were employed for execution of the quantum circuit may then be released 314 and made available for another process.
Dreher et al. ("Prototype Container-Based Platform for Extreme Quantum Computing Algorithm Development", 2019 IEEE High Performance Extreme Computing Conference (HPEC), Sep. 24-26, 2019, pp. 1-7) discloses in ABSTRACT of Page 1 that (1) recent advances in the development of the first generation of quantum computing devices have provided researchers with computational platforms to explore new ideas and reformulate conventional computational codes suitable for a quantum computer; (2) developers can now implement these reformulations on both quantum simulators and hardware platforms through a cloud computing software environment; e.g. the IBM Q Experience provides the direct access to their quantum simulators and quantum computing hardware platforms; (3) however these current access options may not be an optimal environment for developers needing to download and modify the source codes and libraries; (4) focus on the construction of a Docker container environment with Qiskit source codes and libraries running on a local cloud computing system that can directly access the IBM Q Experience; and (5) this prototype container based system allows single user and small project groups to do rapid prototype development, testing and implementation of extreme capability algorithms with more agility and flexibility than can be provided through the IBM Q Experience website. Dreher further discloses in Section III in Page 2 that (1) although the new version of the IBM Q Experience improved the software environment for working with quantum simulators and hardware devices, this type of development environment is not optimally matched for developers who need direct access to download and modify the source code and libraries; (2) container technologies running on a cloud system offer the option of packaging application codes and all their dependencies and then agilely launching many instances with different parameters and variations of that application; (3) containers are portable, scalable and are standardized so that they can easily and rapidly be deployed in a cloud-based environment and have the additional advantage of quicker processing speed when compared to VMs; (4) containers also have the feature that they can run on the same machine and share the OS kernel with other containers, each running as isolated process in the user space; (5) containers can also offer the advantage that they can isolate the software from its environment in a way that ensures that the container incorporates portability and performs uniformly across many different platforms; (6) this project selected the Docker container software for building this prototype; and (7) the fundamental building block of this Docker technology is the container image which creates a docker container; and (8) the image is a lightweight, stand alone, executable package that includes the code, runtime, system tools, system libraries and settings needed to run an application.
Xiao et al. (US 2021/0279066 A1, pub. date: 09/09/2021) discloses in ¶¶ [0018]-[0020] that (1) facilitate transforming, migrating, deploying, and/or running an application (e.g., a non-cloud application, a legacy application, a classical computing application, etc.) in a cloud computing environment involve performing steps including one or more of the following: a) pre-defining and creating application connector types that a legacy application can use to expose application programming interfaces (APIs); b) enabling a particular application that is configured to store state information in the cloud computing system, exposing service specifications and ports; c) lifting-and-shifting discovery of infrastructure and applications hosted to automatically generate service-catalog entries for discovered service; and/or d) generating a development operations (DevOps) application deployment package for a deployment tool and executing the deployment, targeting applications with a DevOps service model; and (2) facilitate: a) legacy application transformation to cloud native runnable containers through CI/CD generation and error diagnosis; b) a multifactor analysis to determine application cloud readiness, benefits, and modernization complexity; c) operators planning and orchestration to address legacy application nonfunctional criteria (also referred to herein as nonfunctional criteria) in cloud native; and/or d) dataflow discovery for data modernization. Xiao further discloses in ¶¶ [0021]-[0040] and [0051]-[0066] with FIGS. 1 and 9-10 that (1) employ one or more computing resources of cloud computing environment 950 described below with reference to FIG. 9 and/or one or more functional abstraction layers (e.g., quantum software, etc.) described below with reference to FIG. 10 to execute one or more operations; e.g., cloud computing environment 950 and/or such one or more functional abstraction layers can comprise one or more classical computing devices (e.g., classical computer, classical processor, virtual machine, server, etc.), quantum hardware, and/or quantum software (e.g., quantum computing device, quantum computer, quantum processor, quantum circuit simulation software, superconducting circuit, etc.) that can be employed by application transformation system 102 and/or components thereof to execute one or more operations (e.g., mathematical function, calculation, and/or equation; computing and/or processing script; algorithm; model (e.g., artificial intelligence (AI) model, machine learning (ML) model, etc.); and/or another operation); (2) cloud computing is a model of service delivery for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal management effort or interaction with a provider of the service, wherein this cloud model may include at least five characteristics, at least three service models, and at least four deployment models; (3) characteristics are as follows: a) on-demand self-service; b) broad network access; c) resource pooling; d) rapid elasticity; and e) measured service; (4) Service Models are as follows: a) Software as a Service (SaaS); b) Platform as a Service (PaaS); and c) Infrastructure as a Service (IaaS); (5) Deployment Models are as follows: a) private cloud; b) community cloud; c) public cloud; and d) hybrid cloud; (6) a cloud computing environment is service oriented with a focus on statelessness, low coupling, modularity, and semantic interoperability; (7) at the heart of cloud computing is an infrastructure that includes a network of interconnected nodes; (8) application transformation system 102 can facilitate (e.g., via processor 106) performance of operations executed by and/or associated with analysis component 108, transformation component 110, and/or another component associated with application transformation system 102; (9) employing a model to discover attributes of an enterprise application; and/or generating artifacts based on the attributes to transform the enterprise application into a cloud native container, wherein the artifacts can be selected from a group consisting of one or more: development artifacts, build artifacts, deployment artifacts, operations artifacts, and continuous integration and continuous deployment artifacts; (10) performing assessments of the cloud native container prior to runtime and at runtime to determine at least one of application cloud native readiness, application cost to benefit, or application modernization strategy; (11) identifying an error in at least one of the attributes of the enterprise application or the artifacts and generating one or more modified artifacts based on the error, thereby facilitating at least one of reduced application transformation time, improved processing efficiency of the processor, or reduced computational costs of the processor; (12) generating one or more modified artifacts based on an error identified in at least one of the attributes of the enterprise application or the artifacts and recommending one or more application modernization strategies corresponding to the enterprise application based on the one or more modified artifacts; (13) planning one or more operators to satisfy one or more nonfunctional criteria of the enterprise application in the cloud native container and orchestrating the one or more operators to satisfy the one or more nonfunctional criteria of the enterprise application in the cloud native container; (14) constructing a dataflow corresponding to the enterprise application to support transformation of the enterprise application to the cloud native container; (15) the artifacts can be selected from a group consisting of one or more: development artifacts, build artifacts, deployment artifacts, operations artifacts, and continuous integration and continuous deployment artifacts; (16) analysis component 108 can employ a model to discover attributes of an enterprise application, which include application classes, build, configuration and properties, data dependencies, library dependencies, resource dependencies, data processes (e.g., file, storage, cache, queue, log, database, etc.), and/or another attribute of an enterprise application; (17) analysis component 108 can employ a model to discover attributes of an enterprise application by discovering domain-specific rules of the enterprise application (e.g., using IT document(s) defined above); (18) analysis component 108 can employ a model to discover attributes of an enterprise application by separating configuration and non-functional (nonfunctional) dependencies ( e.g., session persistence) from application computation logic of the enterprise application; (19) transformation component 110 can generate artifacts based on attributes of an enterprise application to transform the enterprise application into a cloud native container; (20) transformation component 110 can generate artifacts (e.g., scripts, code, etc.) to transform the enterprise application into a cloud native container, which includes one or more: development artifacts, build artifacts, deployment artifacts, operations artifacts, continuous integration and continuous deployment (CI/CD) artifacts, and/or another artifact that can facilitate transformation (e.g., by transformation component 110) of the enterprise application into a cloud native container; (21) transformation component 110 can generate runnable development and operations (DevOps) artifacts (e.g., dockerfile, CI/CD build files, CI/CD deploy files, secrets, yam!, etc.) to facilitate build and deploy in a cloud native environment based on the configuration and non-functional dependencies (e.g., session persistence) that can be separated by analysis component 108 from application computation logic of an enterprise application; (22) analysis component 108 can employ an intent classifier and a BI-LSTM-CRF to analyze build, deploy, and operations logs, as well as test reports to identify gaps in discovered configuration and dependencies of the enterprise application; (23) transformation component 110 can generate one or more modified artifacts based on the one or more errors identified by analysis component 108; (24) transformation component 110 can further recommend one or more application modernization strategies (e.g., to inform owner of enterprise application and/or accelerate transformation of the enterprise application to a cloud native container); (25) transformation component 110 can plan and orchestrate one or more operators to satisfy one or more non-functional criteria (also referred to herein as nonfunctional criteria) of the enterprise application in the cloud native container; (26) analysis component 108 can perform assessments of the enterprise application and/or the cloud native container prior to runtime and/ or at runtime to determine at least one of application cloud native readiness, application cost to benefit, or application modernization strategy; (27) analysis component 108 can employ a rule-based and/or template-driven methodology (e.g., using a checklist) to conduct a pre-flight multi-factor analysis of an enterprise application to assess cloud native readiness and/or to map findings to recommendations on application modernization strategies ( e.g., one or more of the application modernization strategies described above); and (28) transformation component 110 can construct a dataflow corresponding to an enterprise application to support transformation of the enterprise application to a cloud native container. Xiao also discloses in ¶¶ [0097[-[0105] with FIGS. 7A-B that (1) at 702a, employing a model to discover attributes (e.g., application classes, build, configuration and properties, data dependencies, library dependencies, resource dependencies, data processes, etc.) of an enterprise application (e.g., a polyglot application, a packaged application, etc.); (2) at 704a, generating artifacts (e.g., development artifacts, build artifacts, deployment artifacts, operations artifacts, continuous integration and continuous deployment (CI/CD) artifacts, etc.) based on the attributes to transform the enterprise application into a cloud native container; (3) at 702b, generating artifacts based on attributes of an enterprise application to transform the enterprise application into a cloud native container; (4) at 704b, assessing the attributes and/or the artifacts prior to runtime and/or at runtime; (5) at 706b, determining whether one or more errors are identified in the attributes and/or the artifacts assessed at 704b; (6) if it is determined at 706b that one or more errors are identified in the attributes and/or the artifacts, at 708b, generating one or more modified artifacts based on the error(s) and recommending one or more application modernization strategies based on the modified artifact(s); (7) based on such generation of modified artifact(s) and recommendation of one or more application modernization strategies at 708b, or if it is determined at 706b that one or more errors are not identified in the attributes and/or the artifacts, at 710b, planning and orchestrating one or more operators to satisfy one or more nonfunctional criteria of the enterprise application in the cloud native container; and (8) at 712b, constructing a dataflow corresponding to the enterprise application to support transformation of the enterprise application to the cloud native container.
However, closest arts of records, as discussed above, singly or in combination do not teach or suggest at least following features "a container generation system comprising: a first classical processor configured to: receive an application code of a legacy application; and containerize the legacy application to generate a containerized application code of a containerized application, wherein containerizing the legacy application comprises: analyzing the application code to generate a plurality of container configurations for the containerized application, wherein each container configuration comprises a plurality of container images and a plurality of application programming interfaces (APIs), and wherein generating each container configuration comprises: determining a plurality of logical units of the legacy application; clustering the plurality of logical units into a plurality of clusters; determining a plurality of interaction flows between the plurality of clusters; generating a respective container image for each cluster; and mapping the plurality of interaction flows to the plurality of APIs; receiving performance scores for each container configuration; determining a total performance score for each container configuration based on the performance scores and a rule; determining a highest total performance score; and determining an improved container configuration from the plurality of container configurations based on the highest total performance score; and deploy the containerized application code having the improved container configuration to a cloud computing system; and a quantum computing system communicatively coupled to the container generation system, the quantum computing system comprising: a quantum processor configured to: receive an initial quantum state, wherein the initial quantum state comprises the plurality of container configurations represented using quantum bits; simulate each container configuration; and generate a final quantum state from the initial quantum state, wherein the final quantum state comprises the performance scores for each container configuration represented using quantum bits", "receiving an application code of a legacy application; containerizing the legacy application to generate a containerized application code of a containerized application, wherein containerizing the legacy application comprises: analyzing the application code to generate a plurality of container configurations for the containerized application, wherein each container configuration comprises a plurality of container images and a plurality of application programming interfaces (APIs), and wherein generating each container configuration comprises: determining a plurality of logical units of the legacy application; clustering the plurality of logical units into a plurality of clusters; determining a plurality of interaction flows between the plurality of clusters; generating a respective container image for each cluster; and mapping the plurality of interaction flows to the plurality of APIs; generating an initial quantum state from the plurality of container configurations; simulating each container configuration; generating a final quantum state from the initial quantum state, wherein the final quantum state comprises performance scores for each container configuration represented using quantum bits; determining a total performance score for each container configuration based on the performance scores and a rule; determining a highest total performance score; determining an improved container configuration from the plurality of container configurations based on the highest total performance score; and deploying the containerized application code having the improved container configuration to a cloud computing system", or "receive an application code of a legacy application; containerize the legacy application to generate a containerized application code of a containerized application, wherein containerizing the legacy application comprises: analyzing the application code to generate a plurality of container configurations for the containerized application, wherein each container configuration comprises a plurality of container images and a plurality of application programming interfaces (APIs), and wherein generating each container configuration comprises: determining a plurality of logical units of the legacy application; clustering the plurality of logical units into a plurality of clusters; determining a plurality of interaction flows between the plurality of clusters; generating a respective container image for each cluster; and mapping the plurality of interaction flows to the plurality of APIs; generate an initial quantum state from the plurality of container configurations; simulate each container configuration; generate a final quantum state from the initial quantum state, wherein the final quantum state comprises performance scores for each container configuration represented using quantum bits; determine a total performance score for each container configuration based on the performance scores and a rule; determine a highest total performance score; determine an improved container configuration from the plurality of container configurations based on the highest total performance score; and deploy the containerized application code having the improved container configuration to a cloud computing system" when combining with all other limitations of these claims as a whole.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HWEI-MIN LU whose telephone number is (313)446-4913. The examiner can normally be reached Mon - Fri: 9:00 AM - 6:00 PM EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Mariela D. Reyes can be reached at (571) 270-1006. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/HWEI-MIN LU/Primary Examiner, Art Unit 2142