Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant’s arguments with respect to claim(s) 1-20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 7-8 and 14-15 are rejected under 35 U.S.C. 103 as being unpatentable over Gatti (US 20220229699 A1) in view of Panikkar (US 20230168940 A1).
Regarding claim 1, Gatti teaches:
A method for reducing startup times of applications, the method comprising: (Claim 1. A method comprising: monitoring computing resource usage associated with a first thread allocation configuration for applications to interact with a database.)
starting a proxy plugin process ([0011] FIG. 1 illustrates a computing environment 100 to manage thread allocation for applications to access a database according to an implementation. Computing environment 100 includes applications 110-113, database 125 with nodes 140-142, and coordination service 124. Coordination service 124 further includes allocation queues 128 and provides operation 200 that is further described below in FIG. 2 and provides operation 300 that is further described below in FIG. 3. Computing environment 100 further includes telemetry data 130-131 (computer resource usage information) that is supplied by database 125 and applications 110-113 and includes thread configuration 132 that is supplied by coordination service 124 to applications 110-113.; see also [0013])
wherein the proxy plugin process includes a pool of threads or fibers for running applications.. ([0012] Applications 110-113 are deployed in computing environment 100 to perform various operations in association with database 125. These operations may require reads from database 125 or may require writes to database 125. Applications 110-113 may run on virtual machines, containers, or some other virtualized endpoint. Each of application of applications 110-113 may be associated with a different quality of service based on the owner of the application or the types of operations provided by the applications. Based on the quality of service, coordination service 124 may allocate threads or connections to the application to support the required requests to database 125, wherein multiple threads may permit an application to use concurrent requests to the database.)
loading a first application into a first virtual machine running in the proxy plugin process; assigning one thread or fiber from the pool to the first virtual machine to run the first application; running the first application; ([0022] FIG. 3 illustrates an operation 300 of a coordination service to dynamically allocate threads to applications according to an implementation. The steps of operation 300 are referenced parenthetically in the paragraphs that follow with reference to systems and elements in computing environment 100 of FIG. 1. [0023] As described herein, applications 110-113 are deployed in a computing environment 100 to provide various operations with respect to database 125. Applications 110-113 may execute on virtual machines, containers, or some other virtualized endpoint, and may execute on physical computing systems in some examples. When the applications are deployed, coordination service 124 may allocate threads to each of the applications as part of a thread allocation configuration. These threads may be used to limit the number of operations or processes performed by each application at the database. For example, an application may be limited to three threads to provide parallel requests to the database, while another application may be limited to ten threads. These threads may be limited to a master node, may be limited to one or more slave nodes, or may be some combination thereof.)
loading a second application into a second virtual machine running in the proxy plugin process; ([0024] Once a first thread allocation configuration is implemented for applications 110-113, operation 300 may monitor (301) computing resource usage associated with the first thread allocation configuration for applications to interact with the database. In some implementations, the database nodes and/or the applications may report the computing resource usage information as telemetry data, wherein the usage information may be provided periodically, at intervals based on load at the database nodes, or at some other interval. The computing resource usage information may include processing resource usage at the database associated with each of the applications, memory resource usage at the database associated with each of the applications, or some other computing resource usage information. In particular, the computing resource usage for each of the applications may be measured at the computing system or systems that provide the database)
assigning one other thread or fiber from the pool to the second virtual machine to run upon termination of the first application, returning the one thread or fiber to the pool for re-use by other applications. ([0028] FIG. 4 illustrates a timing diagram 400 to dynamically allocate threads to applications according to an implementation. Timing diagram 400 includes applications 110-113, coordination service 124, and database 125 of FIG. 1.[0029] In operation, coordination service 124 may identify applications 110-113 to be deployed in the computing environment to provide various operations using database 125, wherein applications 110-113 write and/or read data from database 125. In some implementations, when an application is identified to be deployed in the computing environment, the application may be placed in a queue based on the quality of service for the application. Once allocated to a queue, coordination service 124 may select an application from the queue and allocate, at step 1, threads to the application to support the application. In some implementations, the queues may each be associated with rates from which applications are pulled from queues. In particular, the applications may be selected from a queue or queues with a better quality of service at a higher rate than a queue or queues with a lower quality of service. In some examples, the threads that are allocated to each of the applications may be based on requirements associated with the applications. [0033] FIG. 5 illustrates a timing diagram 500 to dynamically allocate threads to applications according to an implementation. Timing diagram 500 includes application 110, coordination service 124, and database 125 of FIG. 1.; see also [0034-0036])
Gatti does not teach the execution environment is a worker node of an orchestration system and is managed by a container manager of the worker node that operates as a container runtime interface with the orchestration system.
However, Panikkar teaches: [0021] FIG. 1 depicts an example of a pod-based container orchestration environment 100. As shown, a plurality of management nodes 110-1, . . . 110-L (herein each individually referred to as management node 110 or collectively as management nodes 110) are respectively operatively coupled to a plurality of clusters 115-1, . . . 115-L (herein each individually referred to as cluster 115 or collectively as clusters 115). As mentioned above, each cluster is managed by at least one management node. Illustrative embodiments provide for application copy management across multiple clusters (e.g., from one cluster of clusters 115 to another cluster of clusters 115), as will be further explained in detail herein. [0023] Worker nodes 120 of each cluster 115 execute one or more applications associated with pods 122 (containerized workloads). Each management node 110 manages the worker nodes 120, and therefore pods 122 and containers, in its corresponding cluster 115. More particularly, each management node 110 controls operations in its corresponding cluster 115 utilizing the above-mentioned components, i.e., controller 112, scheduler 114, API service 116, and a key-value database 118. In general, controller 112 executes control processes (controllers) that are used to manage operations in cluster 115. Scheduler 114 typically schedules pods to run on particular nodes taking into account node resources and application execution requirements such as, but not limited to, deadlines. In general, in a Kubernetes implementation, API service 116 exposes the Kubernetes API, which is the front end of the Kubernetes container orchestration system. Key-value database 118 typically provides key-value storage for all cluster data including, but not limited to, configuration data objects generated, modified, deleted, and otherwise managed, during the course of system operations.
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Gatti and Panikkar before them, to include Panikkar’s Kubernetes based orchestration system in Gatti’s thread allocation to applications in virtual environments. One would have been motivated to make such a combination to obtain predictable benefits of Kubernetes management, scheduling and deployment of applications across worker nodes as taught by Panikkar.
Regarding claim 7, Panikkar teaches:
The method of claim 1, wherein the orchestration system is a Kubernetes orchestration system. ([0048] As mentioned above, a Kubernetes microservices framework can be used by an OEM to manage computer-implemented tasks and other tasks associated with an equipment manufacturing process. By way of example, an equipment manufacturing process 300 is shown in FIG. 3. It is assumed that an equipment order planning task 310 (e.g., where customer orders for the equipment are processed and scheduled for manufacturing) has to be finished by 5 AM since a license key allocation task 320 (e.g., where unique digital codes are assigned to the equipment to be used by the customers to unlock purchased functionality in the equipment), which takes two hours, has to start by 5:30 AM in order to finish by 7:30 AM. The actual equipment manufacturing task 330 starts at 8 AM when the manufacturing labor shift begins work at each factory. Assuming the equipment manufacturing process 300 is managed using a Kubernetes microservices framework, certain microservices are typically scheduled and executed including data pipeline, demand and supply planning, data load tasks, and license key allocation. These tasks are considered time-critical since a later task starting on-time depends on a previous task completing on-time, e.g., license key allocation task 320 which is known to take two hours has to start and complete before actual manufacturing task 330 can start.)
Regarding claims 8 and 14-15 recite commensurate subject matter as claims 1 and 7. Therefore, they are rejected for the same reasons.
Claims 2-4, 9-11 and 16-18 are rejected under 35 U.S.C. 103 as being unpatentable over Gatti (US 20220229699 A1) in view of Panikkar (US 20230168940 A1) and further view of Jain (US 20210089348 A1).
Regarding claim 2, Gatti does not appear to explicitly teach:
The method of claim 1, wherein the first and second virtual machines run as lightning containers.
Jain teaches: ([0026] At S330, a dispatcher platform may create or “spin” a first web assembly module such that execution of the first web assembly module is associated with a first web assembly browser sandbox. Further details about the “web assembly” module are provided in connection with FIG. 4. According to some embodiments, the first web assembly browser sandbox is associated with a first memory heap that is not accessible from the second web assembly browser sandbox. [ E.N.: Applicant specification recites “a lightning container (LC) 412 is a WASM VM 408”. [0029] FIGS. 5 through 7 illustrate a tenant support process using web assembly according to some embodiments. In particular, FIG. 5 shows 500 a dispatcher platform 5150 selecting an available thread from a tenant thread pool 520 at (A). FIG. 6 illustrates 600 a dispatcher platform 610 creating a web assembly sandbox 630. E.N the specification in [0036] defines a lightning container (LC) 412 is a WASM VM 408.
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Gatti and Jain before them, to include Jain’s WebAssembly sandboxes in Gatti’s thread allocation to applications in virtual environments. One would have been motivated to use the well-known type of virtual machine to reduce application startup and loading times and improve isolation as taught by Jain[0027-29].
Regarding claim 3, Jain teaches:
The method of claim 1, wherein the first virtual machine and second virtual machine are WebAssembly virtual machines that run platform-independent binary code. ([0029]FIG. 6 illustrates 600 a dispatcher platform 610 creating a web assembly sandbox 630 at (B) (e.g., after selecting a thread from the tenant thread pool 620). Finally, FIG. 7 shows 700 how a dispatcher platform 710 can create a tenant actor 740 (using a thread selected from a tenant thread pool 720) in a web assembly sandbox 730 at (C) according to some embodiments. [0027] Note that higher-level languages can be compiled to a web assembly module 420 that is then run by the browser in the same sandboxed environment as the JavaScript code 410. Moreover, web assembly modules 420 compiled from higher-level languages may have been already parsed and compiled/optimized so they can go through a fast decoding phase (as the module is already in bytecode format close to machine code) before being injected into the JIT compiler 456. As a result, web assembly may represent a more efficient/faster way of running code in a browser, using any higher-level language that can target it for development, while being compatible with the existing web technologies.) Note further Gatti [0012, 0017, 0023].
Regarding claim 4, Jain teaches:
The method of claim 3, wherein the platform-independent binary code is generated by compiling a programming language. ([0027] Programming Interface (“API”) data 490). For a web assembly module 420, the browser sandbox 450 may utilize a decode element 458 before executing the JIT compiler 456. In either case, the output of the JIT compiler may comprise machine code 460. According to some embodiments, the web assembly module 420 is a portable binary format designed to be: compact and fast to parse/load so it can be efficiently transferred, loaded, and executed by the browser; compatible with existing web platforms (e.g., to alongside JavaScript, allows calls to/from, access Browser APIs 490, etc.; and run in the same secure sandbox 450 as the JavaScript code 410. Note that higher-level languages can be compiled to a web assembly module 420 that is then run by the browser in the same sandboxed environment as the JavaScript code 410. Moreover, web assembly modules 420 compiled from higher-level languages may have been already parsed and compiled/optimized so they can go through a fast decoding phase (as the module is already in bytecode format close to machine code) before being injected into the JIT compiler 456. As a result, web assembly may represent a more efficient/faster way of running code in a browser, using any higher-level language that can target it for development, while being compatible with the existing web technologies.)
Regarding claims 9-11 and 16-18 recite commensurate subject matter as claims 2-4. Therefore, they are rejected for the same reasons.
Claims 5, 12 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Gatti (US 20220229699 A1) in view of Panikkar (US 20230168940 A1) and further view of Hong “Introducing Container Runtime Interface (CRI) in Kubernetes.
Regarding claim 5, Gatti does not appear to teach:
The method of The method of wherein the worker node includes a container runtime; and wherein the proxy plugin process is coupled via remote procedure calls to the container runtime.
However, Hong teaches: On page 1, In the Kubernetes 1.5 release, we are proud to introduce the Container Runtime Interface (CRI) -- a plugin interface which enables kubelet to use a wide variety of container runtimes, without the need to recompile. CRI consists of a protocol buffers and gRPC API, and libraries, with additional specifications and tools under active development. CRI is being released as Alpha in Kubernetes 1.5. On page 2 Overview of CRIKubelet communicates with the container runtime (or a CRI shim for the runtime) over Unix sockets using the gRPC framework, where kubelet acts as a client and the CRI shim as the server. Overview of CRI Kubelet communicates with the container runtime (or a CRI shim for the runtime) over Unix sockets using the gRPC framework, where kubelet acts as a client and the CRI shim as the server. The protocol buffers API includes two gRPC services, ImageService, and RuntimeService. The ImageService provides RPCs to pull an image from a repository, inspect, and remove an image. The RuntimeService contains RPCs to manage the lifecycle of the pods and containers, as well as calls to interact with containers (exec/attach/port-forward). A monolithic container runtime that manages both images and containers (e.g., Docker and rkt) can provide both services simultaneously with a single socket. The sockets can be set in Kubelet by --container-runtime-endpoint and --image-service-endpoint flags. The protocol buffers API includes two gRPC services, ImageService, and RuntimeService. The ImageService provides RPCs to pull an image from a repository, inspect, and remove an image. The RuntimeService contains RPCs to manage the lifecycle of the pods and containers, as well as calls to interact with containers (exec/attach/port-forward). A monolithic container runtime that manages both images and containers (e.g., Docker and rkt) can provide both services simultaneously with a single socket. The sockets can be set in Kubelet by --container-runtime-endpoint and --image-service-endpoint flags.
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Gatti and Hong before them, to include Hong’s container runtime interface (CRI) using gRPC for communication between the Kubernetes node component and the container runtime. One would have been motivated to do so to provide a standard, pluggable runtime interface for Kubernetes environment ,as taught by Hong.
Regarding claims 12 and 19 recite commensurate subject matter as claims 5. Therefore, they are rejected for the same reasons.
Claims 6, 13 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Gatti (US 20220229699 A1) in view of Panikkar (US 20230168940 A1) and further view of Malviya (US 20220147893 A1).
Regarding claim 6, Gatti does not appear to teach:
The method of wherein the orchestration system has a command line interface to a master node; and wherein loading and running the first application and the second application are performed by a user accessing the master node via the command line interface.
However, Malviya teaches: a OSFD orchestration and scheduling framework device having a command line interface that allows for deployment of applications to virtual machines, see abstract, [0007, 0118, 0059-0061].
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Gatti and Pannikkar before them, to include Malviya’s command line interface for in an orchestration environment. One would have been motivated to do so to perform actions, such as to transmit, receive, or otherwise process network messages and other actions, as taught by Malviya.
Regarding claims 13 and 20 recite commensurate subject matter as claims 6. Therefore, they are rejected for the same reasons.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CARLOS A ESPANA whose telephone number is (703)756-1069. The examiner can normally be reached Monday - Friday 8 a.m - 5 p.m 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, LEWIS BULLOCK JR can be reached at (571)272-3759. 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.
/C.A.E./Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199
Prosecution Insights