0!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 .
Claims 1-23 are currently pending for examination.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-23 are rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1 of U.S. Patent Application 18/379,689 in view of Tripathi (US 20230048653 A1) in view of Berry (US 20220137946 A1) in further view of McClory (US 20180321993 A1) in further view Malfait (US 12531138 B2) in further view of Raman (US 20200089791 A1) in further view of Neild (US 10884797 B2).
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Claims 1-23 are compared to claim 1 of the reference application, as well as the accompanying citations from the secondary references in the following table:
Instant Application : 18/226,817
US Patent Application : 18/379,689
An infrastructure-as-code cloud-infrastructure-management service comprising: one or more computer systems, each containing one or more processors, one or more memories, and one or more data-storage devices; and processor instructions, stored in one or more of the one or more memories that, when executed by one or more of the one or more processors, control the one or more computer systems to implement the infrastructure-as-code cloud-infrastructure-management service,
the infrastructure-as-code cloud-infrastructure-management service including a frontend having a management interface that receives cloud-infrastructure-management commands and requests, including idempotent state commands,
a database that stores information related to managed cloud infrastructure and received cloud-infrastructure-management requests and commands, and
a frontend service that throttles the cloud-infrastructure-management commands and requests received through the management interface, generates tasks corresponding to the cloud-infrastructure- management commands and requests received through the management interface, prioritizes tasks, implements forced-state management, ingests events, and stores events,
a task manager which receives tasks from the frontend and coordinates multiple stages of task execution using multiple task queues, including task preemption, and
multiple workers that each provides a worker interface and that each executes tasks.
An infrastructure-as-code cloud-infrastructure-management service or system comprising: one or more computer systems, each containing one or more processors, one or more memories, and one or more data-storage devices; and processor instructions, stored in one or more of the one or more memories that, when executed by one or more of the one or more processors, control the one or more computer systems to implement the infrastructure-as-code cloud-infrastructure-management service or system,
the infrastructure-as-code cloud-infrastructure-management service or system including a frontend having a management interface that receives cloud-infrastructure-management commands and requests, including idempotent state commands and enforce requests,
a database that stores information related to managed cloud infrastructure, received cloud-infrastructure-management requests and commands, and enforced-state management,
an archive that stores structured-layered-state data files, and
a frontend service that throttles the cloud-infrastructure-management commands and generates tasks corresponding to the cloud-infrastructure- management commands and requests received through the management interface, prioritizes tasks, implements forced-state management, ingests events, and stores events, and
a task manager which receives tasks from the frontend and coordinates multiple stages of task execution using multiple task queues, including task preemption, and
multiple workers that each provides a worker interface and that each executes tasks, including execution of tasks that result in generation of enforcedstateID values and enforced state version values.
As per claim 2, claim 1 of U.S. Patent Application 18/379,689 fully discloses the limitations of claim 1, but does not disclose multiple GraphQL APIs.
However, Malfait discloses:
the frontend-service management interface comprises multiple GraphQL APIs ("In addition to supporting direct content access externally via GraphQL API calls, the platform also provides reporting microservice 134 which exposes platform content via configured REST APIs. Each configured API is exposed via API Gateway 103 and is associated with an internal GraphQL query that retrieves content of interest for the report.", 0041)
It would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the system of with the system of U.S. Patent Application 18/379,689 with that of Malfait in order to provide the system with GraphQL APIs which allow API consumers to precisely identify which object fields (attributes) are to be returned in query results, thus eliminating the potential concern of very large datasets being returned to the client in response to a broad query invocation, while at the same time eliminating the need to implement multiple purpose-specific APIs supporting various combinations of object content to suit the needs of the client. (Malfait, [0052]).
As per claim 3, claim 1 of U.S. Patent Application 18/379,689 in view of Malfait fully discloses the limitations of claim 2.
Furthermore, Malfait discloses:
the multiple GraphQL APIs include: a Submit Task GraphQL API, through which cloud-infrastructure-management deployment-and-configuration commands are input to the infrastructure-as-code cloud- infrastructure-management service ("In some examples, database 105 implements GraphQL queries and mutations to manage data. For example, study design microservice 126 implements GraphQL APIs that invoke database 105 as an efficient and flexible way to retrieve clinical development content.”, 0049 ; “Microservices 122, 124, 126, 128, 130, 132, and 134 are “GraphQL first” in nature. Microservices 122, 124, 126, 128, 130, 132, and 134 expose core Create/Read/Update/Delete (CRUD) actions on their business objects via GraphQL queries and mutations.", 0050 ; Examiner Note: the “create” and “update” actions performed via GraphQL queries equate to a Submit Task GraphQL API)
a Query Task GraphQL API, through which status queries regarding previously submitted cloud-infrastructure-management commands and requests are input to the infrastructure-as-code cloud-infrastructure-management service (“Microservices 122, 124, 126, 128, 130, 132, and 134 are “GraphQL first” in nature. Microservices 122, 124, 126, 128, 130, 132, and 134 expose core Create/Read/Update/Delete (CRUD) actions on their business objects via GraphQL queries and mutations.", 0050 ; Examiner Note: the “read” action performed via GraphQL query equates to a Query task GraphQL API.
a Retrieved Schema GraphQL API, through which the schemas for infrastructures within cloud-computing-facilities can be requested from the infrastructure-as-code cloud- infrastructure-management service. ("In addition to supporting direct content access externally via GraphQL API calls, the platform also provides reporting microservice 134 which exposes platform content via configured REST APIs. Each configured API is exposed via API Gateway 103 and is associated with an internal GraphQL query that retrieves content of interest for the report.", 0041)
Claim 1 of U.S. Patent Application 18/379,689 in view of Malfait discloses the above limitations of claim 3, but does not disclose requests to validate structured-layered-state data.
However, Raman discloses:
a Validate SLS GraphQL API, through which requests to validate structured-layered- state data are input to the infrastructure-as-code cloud-infrastructure-management service ("the processor may be further configured to control the network interface to transmit a blockchain request to validate state data within a first data point among the plurality of successive data points to a first subset of endorsing nodes of a blockchain network, and transmit a blockchain request to validate state data within a second data point among the plurality of successive data points to a second subset of endorsing nodes which are mutually exclusive from the first subset of endorsing nodes of the blockchain network for parallel endorsement of the first and second data points.", 0008 ; Examiner Note: the state data of set of endorsing nodes of a blockchain network equates to structured-layered-state data)
The system of Claim 1 of U.S. Patent Application 18/379,689 in view of Malfait would be capable of using a GraphQL API to input requests for validation. It would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the system of Claim 1 of U.S. Patent Application 18/379,689 in view of Malfait with the system of Raman in order to provide a coded computing-based endorsement allocation to reduce computational time for state validation (Raman, [0052]).
As per claim 4, Claim 1 of U.S. Patent Application 18/379,689 fully discloses the limitations of claim 1, but does not disclose idempotent state commands including structured-layered-state data.
However, Berry discloses:
an idempotent state command includes structured-layered-state data or a reference to structured-layered-state data ("the herein-disclosed techniques employ a combination of (a) an intent engine that accepts an overall expressed intent to achieve an intended/desired state (e.g., completion of an imaging process), and (b) a mechanism to decompose the overall expressed intent into many smaller constituent intents that are in turn achievable through a series of smaller idempotent operations.", 0025; Examiner Note: the intended/desired state of the image equates to structured-layered-state data.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the teachings of claim 1 of U.S. Patent Application 18/379,689 with those Berry in order to provide the benefits of idempotent state commands, such as eliminating the need to codify specific error handling for a myriad of possible error conditions that could occur during virtualization system imaging (Berry, [0024]).
As per claim 5, claim 1 of U.S. Patent Application 18/379,689 in view of Berry fully discloses the limitations of claim 4.
Furthermore, Berry discloses:
an idempotent state command directs the infrastructure-as-code cloud-infrastructure- management service to ensure that cloud infrastructure within a cloud-computing facility described by the structured-layered-state data is deployed within the cloud-computing facility and configured according to the structured-layered-state data (“the herein-disclosed techniques employ a combination of (a) an intent engine that accepts an overall expressed intent to achieve an intended/desired state (e.g., completion of an imaging process), and (b) a mechanism to decompose the overall expressed intent into many smaller constituent intents that are in turn achievable through a series of smaller idempotent operations.", 0025)
As per claim 6, claim 1 of U.S. Patent Application 18/379,689 fully discloses the limitations of claim 1, but does not disclose message-based communications between the frontend, task manager, and workers.
However, McClory discloses:
message-based communications connections between the frontend, the task manager, and the multiple workers; and an event stream to which the multiple workers publish events and from which an event- stream processing component retrieves events, filters the retrieved events, and sends events to the frontend (“A worker process may detect the task message upon transmission of the task message to the command queue and execute the task specified by the task message. Upon completion of the task, a completion message may be transmitted to an event publish queue", 0005 ; Examiner Note: the command API (frontend) necessarily sends task messages to the command task queue (within service 401 equating to a task manager))
It would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the teachings of claim 1 of U.S. Patent Application 18/379,689 with those of McClory in order to provide a frontend and task manager, and provide the system with the ability to continuously deploy their applications with certainty and consistency validated by built in, frequent, recurring, automated, and configurable testing (McClory, [0032]).
As per claim 7, claim 1 of U.S. Patent Application 18/379,689 in view of McClory fully discloses the limitations of claim 6.
Furthermore, McClory discloses:
the task manager maintains three task queues that include: a Request Queue task queue; a Notified Queue task queue; and a Running Queue task queue ("A read cache may be updated with the request identifier, and the task message may be transmitted to a command task queue. A worker process may detect the task message upon transmission of the task message to the command queue and execute the task specified by the task message. ", 0005 ; "In an embodiment, a status of the task specified by the task message may be periodically transmitted to the read queue.", 0006 ; Examiner Note: the read cache equates to a Request Queue task queue, the command task queue equates to a notified queue task queue, and the read queue equates to a running queue task queue)
As per claim 8, claim 1 of U.S. Patent Application 18/379,689 in view of McClory fully discloses the limitations of claim 7.
Furthermore, McClory discloses:
when the task manager receives a task for execution from the front end, the task manager queues the task to the RequestQueue (“"According to an embodiment, a request for a service may be received by a command application programming interface (API) from a client device. A request identifier and a task message specifying a task to be performed by the service may be generated based on the received request. A read cache may be updated with the request identifier", 0005)
As per claim 9, claim 1 of U.S. Patent Application 18/379,689 in view of McClory fully discloses the limitations of claim 7.
Furthermore, McClory discloses:
one or more workers are available to execute a task, the task manager selects a task queued to the Request Queue for execution; notifies one or more of the multiple workers that the selected task is available for execution; and moves the selected task from the Request Queue to the Notified Queue. (“A read cache may be updated with the request identifier, and the task message may be transmitted to a command task queue. A worker process may detect the task message upon transmission of the task message to the command queue and execute the task specified by the task message.”, 0005)
As per claim 10, claim 1 of U.S. Patent Application 18/379,689 in view of McClory fully discloses the limitations of claim 9.
Furthermore, McClory discloses:
the task manager selects the task queued to the Request Queue based on one or more of: a priority assigned to the task; the capabilities and capacities of the available workers; the numbers of tasks queued to the Request Queue for each priority; and the length of time since a task of each priority was last executed. (“command task queue and event publish queue may implement any type of queuing method such as but not limited to FIFO, LIFO, priority queuing, or fair queuing.”, 0135)
As per claim 11, claim 1 of U.S. Patent Application 18/379,689 in view of McClory fully discloses the limitations of claim 7.
Furthermore, McClory discloses:
when a worker, having been notified of a task available for execution, accepts the task for execution and notifies the task manager of the worker's acceptance of the task, the task manager moves the accepted task from the Notified Queue to the Running Queue (“A worker process may detect the task message upon transmission of the task message to the command queue and execute the task specified by the task message.”, 0005 ; “A status request including the request identifier may be received by a read API, and the status from the read queue may be retrieved in response to receiving the status request.”, 0006)
claim 1 of U.S. Patent Application 18/379,689 in view of McClory fully discloses the above limitations of claim 11, but does not disclose assigning a status of “picked” when a worker accepts a task.
However, Neild discloses:
associates a status of Picked with the task. “In various examples there may be at least two distinct not active states: a ‘ready state and one or more waiting’ states. A scheduled task in the ready state is available to be selected by the scheduled task scheduler for execution and once selected (i.e. activated) the scheduled task would move from the ready state into the active state..”, detailed description, Par.8 ; Examiner Note: being in the ready state equates to having a status of ‘picked’ )
It would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the system of claim 1 of U.S. Patent Application 18/379,689 in view of McClory with that of Neild in order to provide the system with the ability to be schedule and de-schedule (e.g. by placing a task into one or more Waiting states' where they are not active) a task many times by the scheduled task scheduler before a task is completed (Neild, [detailed description, Par.6])
As per claim 12, claim 1 of U.S. Patent Application 18/379,689 in view of McClory in further view of Neild fully discloses the limitations of claim 7
Furthermore, Neild discloses:
when a worker begins execution of a task and notifies the task manager that execution of the task has begun, the task manager changes the status associated with the task to Running. (“each queue corresponding to a particular state and comprising only the scheduled tasks that are in that state (e.g. an active queue comprising only those scheduled tasks in the active state)”, detailed description, Par.9)
The combination of claim 1 of U.S. Patent Application 18/379,689 in view of McClory in further view of Neild would provide a system capable of changing the task status to “running” (or active) when a worker begins execution and notifies the task manager that execution has begun.
As per claim 13, claim 1 of U.S. Patent Application 18/379,689 in view of McClory fully discloses the limitations of claim 7.
Furthermore, McClory discloses:
when execution of a task finishes, the worker executing the task publishes a task-completion or task-failure event to the event stream which is received by the frontend service, ("Upon completion of the task, a completion message may be transmitted to an event publish queue.", 0005 )
claim 1 of U.S. Patent Application 18/379,689 in view of McClory discloses the above limitation of claim 13, but does not explicitly removing a task from a Running queue.
However, Vasanth discloses:
in response to which the frontend service notifies the task manager that execution of the task is finished and the task manager removes the task from the Running Queue. ("Upon completion of the task 116, the task manager component 138 may update the task queue 202 and remove the task 116 from the task queue 202", 0074)
It would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the system of claim 1 of U.S. Patent Application 18/379,689 in view of McClory with the system of Vasanth in order to provide a centralized platform to manage agents, optimize the assignment of tasks, and increase productivity (Vasanth, [0009]).
As per claim 14, claim 1 of U.S. Patent Application 18/379,689 in view of McClory fully discloses the limitations of claim 9.
Furthermore, McClory discloses:
When execution of a task has continued for more than a threshold time and/or has consumed more than a threshold amount of computational resources, the task manager preempts execution of the task and moves the task from the Running Queue to the Request Queue. (““command task queue and event publish queue may implement any type of queuing method such as but not limited to FIFO, LIFO, priority queuing, or fair queuing.”, 0135”)
As per claim 15, McClory discloses:
A method that manages coordinates multiple stages of task execution using multiple task queues by a task manager within an infrastructure-as-code cloud-infrastructure- management service, the infrastructure-as-code cloud-infrastructure-management service comprising a frontend having a management interface that receives cloud-infrastructure- management commands and requests, ("A read cache may be updated with the request identifier, and the task message may be transmitted to a command task queue. A worker process may detect the task message upon transmission of the task message to the command queue and execute the task specified by the task message. Upon completion of the task, a completion message may be transmitted to an event publish queue.", 0005 ; “command task queue and event publish queue may implement any type of queuing method such as but not limited to FIFO, LIFO, priority queuing, or fair queuing.”, 0135 ; Examiner Note: the service (fig.1, 401) of McClory equates to a task manager. The service (401) of McClory receives tasks from the command API, equating to the frontend)
a frontend service that generates tasks corresponding to the cloud-infrastructure-management commands and requests received through the management interface ("According to an embodiment, a request for a service may be received by a command application programming interface (API) from a client device. A request identifier and a task message specifying a task to be performed by the service may be generated based on the received request", 0005)
task manager which receives tasks from the frontend, (see fig.1, service 401)
multiple workers that each executes tasks ; (see fig.1, worker 430 ; “According to an embodiment, worker 430 may represent one or more processes or threads executing as part of service 410 designed to execute a service task.”, 0132)
managing, by the task manager, a RequestQueue task queue, a NotifiedQueue task queue, and a RunningQueue task queue; and moving, by the task manager, a task among the RequestQueue, the Notified Queue task queue, and the Running Queue as the task traverses multiple execution stages. ("According to an embodiment, a request for a service may be received by a command application programming interface (API) from a client device. A request identifier and a task message specifying a task to be performed by the service may be generated based on the received request. A read cache may be updated with the request identifier, and the task message may be transmitted to a command task queue. A worker process may detect the task message upon transmission of the task message to the command queue and execute the task specified by the task message. Upon completion of the task, a completion message may be transmitted to an event publish queue.", 0005 ; "In an embodiment, a status of the task specified by the task message may be periodically transmitted to the read queue.", 0006)
an event stream to which the multiple workers publish events ("Upon completion of the task, a completion message may be transmitted to an event publish queue.", 0005)
Furthermore, Tripathi discloses:
an infrastructure-as-code cloud-infrastructure- management service ("Embodiments herein can facilitate IAC deployments", 0132)
Furthermore, Berry discloses:
including idempotent state commands ("As shown, a user expresses a desire (e.g., intent) for a particular virtualization system image to be built. Intent engine 101 receives the expressed desire and interacts with an image builder 131 that generates a virtualization system image that comports with the expressed desire. The user need only express a desired final state of the virtualization system image (operation 1). The intent engine recursively decomposes the expressed intent into a set of executable idempotent steps (operation 2). The executable idempotent steps are fired or otherwise communicated to the image builder 131 (operation 3). When all of the executable idempotent steps have been carried out by the image builder, a virtualization system image that comports with the expressed desire has been built and is in a condition to be deployed (operation 4).", 0033 ; Examiner Note: the intent engine equates to a management interface)
As per claim 16, it is a method claim with substantially the same limitations as claim 8, and as such, it is rejected for substantially the same reasons.
As per claim 17, it is a method claim with substantially the same limitations as claim 9, and as such, it is rejected for substantially the same reasons.
As per claim 18, it is a method claim with substantially the same limitations as claim 10, and as such, it is rejected for substantially the same reasons.
As per claim 19, it is a method claim with substantially the same limitations as claim 11, and as such, it is rejected for substantially the same reasons.
As per claim 20, it is a method claim with substantially the same limitations as claim 12, and as such, it is rejected for substantially the same reasons.
As per claim 21, it is a method claim with substantially the same limitations as claim 13, and as such, it is rejected for substantially the same reasons.
As per claim 22 it is a method claim with substantially the same limitations as claim 14, and as such, it is rejected for substantially the same reasons.
As per claim 23, it is a physical data-storage device claim with substantially the same limitations as claim 1, and as such, it is rejected for substantially the same reasons.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 4-10, 14, 15-18, and 22-23 are rejected under 35 U.S.C. 103 as being unpatentable over Tripathi (US 20230048653 A1) in view of Berry (US 20220137946 A1) in further view of McClory (US 20180321993 A1).
As per claim 1, Tripathi discloses:
An infrastructure-as-code cloud-infrastructure-management service comprising: one or more computer systems, each containing one or more processors, one or more memories, and one or more data-storage devices; and processor instructions, stored in one or more of the one or more memories that, when executed by one or more of the one or more processors, control the one or more computer systems to implement the infrastructure-as-code cloud-infrastructure-management service ("The method can include, for example: obtaining a first computing environment specific application deployment software code instance associated to a first computing environment, the first computing environment specific application deployment software code instance for deployment of a certain application on the first computing environment", 0005 ; "An application deployment software code instance can facilitate an infrastructure as code (IAC) deployment.", 0038 ; "Computing environment 140, in addition to having computing node stacks 10A-10Z, can include manager 210 that runs availability management process 211. Manager 210 running availability management process 211 can adjust a hosting configuration for a given application to achieve a specified Service Level Agreement (SLA) requirement.", 0034 ; "Computer system 12 may be described in the general context of computer system-executable instructions, such as program processes, being executed by a computer system. Generally, program processes may include routines, programs, objects, components, logic, data structures, and so on that perform particular tasks or implement particular abstract data types.", 0155 ; "Embodiments herein can facilitate IAC deployments", 0132 ; “According to one embodiment, where computing environments 140A-140Z include computing environments configured as public cloud multitenancy computing environments, computing environment providers associated to respective computing environments 140A-140Z can be providers known as public cloud service providers, e.g., IBM® CLOUD® cloud services, AMAZON® WEB SERVICES® (AWS®), or MICROSOFT® AZURE® cloud services”, 0032)
Tripathi discloses an Infrastructure-as-code cloud-infrastructure-management service, but does not disclose a frontend which receives idempotent state commands.
However, Berry discloses:
a management interface that receives cloud-infrastructure-management commands and requests, including idempotent state commands, ("As shown, a user expresses a desire (e.g., intent) for a particular virtualization system image to be built. Intent engine 101 receives the expressed desire and interacts with an image builder 131 that generates a virtualization system image that comports with the expressed desire. The user need only express a desired final state of the virtualization system image (operation 1). The intent engine recursively decomposes the expressed intent into a set of executable idempotent steps (operation 2). The executable idempotent steps are fired or otherwise communicated to the image builder 131 (operation 3). When all of the executable idempotent steps have been carried out by the image builder, a virtualization system image that comports with the expressed desire has been built and is in a condition to be deployed (operation 4).", 0033 ; Examiner Note: the intent engine equates to a management interface)
implements forced-state management ("“…The specification is decomposed into lower level specifications and the lower level specifications are decomposed into idempotent operations. The virtualization system image corresponding to the expressed end state is assembled by processing the idempotent operations. The expressed end state, decomposed lower level intents, and decomposed idempotent operations are codified into a decomposition hierarchy. The decomposition hierarchy is query-able such that, for a given intent, an idempotent operation is returned. An idempotent operation code library is query-able such that, for a given idempotent operation, a corresponding set of executable code is returned. An image builder executes the executable code. When all of the idempotent operations have been successfully executed, the virtualization system image is complete…”, abstract ; Examiner Note: This teaches that the system receives a state specification (“specification of an expressed end state”) and repeatedly applies idempotent operations until the actual system image matches the state. This implies classic forced-state management, the controller enforces convergence of actual state to desired state.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the teachings of Tripathi with those Berry in order to provide the benefits of idempotent state commands, such as eliminating the need to codify specific error handling for a myriad of possible error conditions that could occur during virtualization system imaging (Berry, [0024]).
Tripathi in view of Berry discloses the above limitations of claim 1, but does not disclose the frontend or it’s functionality.
However, McClory discloses:
the infrastructure-as-code cloud-infrastructure-management service including a frontend…
a frontend service that throttles the cloud-infrastructure-management commands and requests received through the management interface, generates tasks corresponding to the cloud-infrastructure- management commands and requests received through the management interface, prioritizes tasks, … , ingests events, and stores events ("According to an embodiment, a request for a service may be received by a command application programming interface (API) from a client device. A request identifier and a task message specifying a task to be performed by the service may be generated based on the received request. A read cache may be updated with the request identifier, and the task message may be transmitted to a command task queue. A worker process may detect the task message upon transmission of the task message to the command queue and execute the task specified by the task message. Upon completion of the task, a completion message may be transmitted to an event publish queue.", 0005 ; “Command task queue 420 and event publish queue 422 may implement any type of queuing method, such as but not limited to first-in-first-out (FIFO), last-in-first-out (LIFO), priority queuing, or fair queuing.”, 0135 ; Examiner Note: requests are buffered in a command queue and only executed when a worker is free to "detect" the message and process it. Execution throughput is limited by worker capacity; excess incoming requests accumulate in the queue. McClory discloses the command API (which equates to a frontend) receives a request and generates task message specifying a task based on that request. McClory further discloses ingesting and storing events (i.e., “ Upon completion of the task, a completion message may be transmitted to an event publish queue”, 0005; “In an embodiment, a status of the task specified by the task message may be periodically transmitted to the read queue. A status request including the request identifier may be received by a read API, and the status from the read queue may be retrieved in response to receiving the status request”, 0006). The event publish queue and read queue receive completion/status messages (event) from workers and hold them until read. Thus, McClory discloses a service that ingests events (messages from workers) and stores events (in queues/caches) for later consumption by a read API)
a task manager which receives tasks from the frontend and coordinates multiple stages of task execution using multiple task queues including task preemption ("A read cache may be updated with the request identifier, and the task message may be transmitted to a command task queue. A worker process may detect the task message upon transmission of the task message to the command queue and execute the task specified by the task message. Upon completion of the task, a completion message may be transmitted to an event publish queue.", 0005 ; “command task queue and event publish queue may implement any type of queuing method such as but not limited to FIFO, LIFO, priority queuing, or fair queuing.”, 0135 ; Examiner Note: the service (fig.1, 401) of McClory equates to a task manager. The service (401) of McClory receives tasks from the command API, equating to the frontend. Fair queueing equates to task preemption)
multiple workers that each provides a worker interface and that each executes tasks. ("A worker process may detect the task message upon transmission of the task message to the command queue and execute the task specified by the task message. Upon completion of the task, a completion message may be transmitted to an event publish queue.", 0005)
It would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the teachings of Tripathi in view of Berry with those of McClory in order to provide a frontend and task manager, and provide the system with the ability to continuously deploy their applications with certainty and consistency validated by built in, frequent, recurring, automated, and configurable testing (McClory, [0032]).
As per claim 4, Tripathi in view of Berry in further view of McClory fully discloses the limitations of claim 1.
Furthermore, Berry discloses:
an idempotent state command includes structured-layered-state data or a reference to structured-layered-state data ("the herein-disclosed techniques employ a combination of (a) an intent engine that accepts an overall expressed intent to achieve an intended/desired state (e.g., completion of an imaging process), and (b) a mechanism to decompose the overall expressed intent into many smaller constituent intents that are in turn achievable through a series of smaller idempotent operations.", 0025; Examiner Note: the intended/desired state of the image equates to structured-layered-state data.)
As per claim 5, Tripathi in view of Berry in further view of McClory fully discloses the limitations of claim 4.
Furthermore, Berry discloses:
an idempotent state command directs the infrastructure-as-code cloud-infrastructure- management service to ensure that cloud infrastructure within a cloud-computing facility described by the structured-layered-state data is deployed within the cloud-computing facility and configured according to the structured-layered-state data (“the herein-disclosed techniques employ a combination of (a) an intent engine that accepts an overall expressed intent to achieve an intended/desired state (e.g., completion of an imaging process), and (b) a mechanism to decompose the overall expressed intent into many smaller constituent intents that are in turn achievable through a series of smaller idempotent operations.", 0025)
As per claim 6, Tripathi in view of Berry in further view of McClory fully discloses the limitations of claim 1.
Furthermore, McClory discloses:
message-based communications connections between the frontend, the task manager, and the multiple workers; and an event stream to which the multiple workers publish events and from which an event- stream processing component retrieves events, filters the retrieved events, and sends events to the frontend (“A worker process may detect the task message upon transmission of the task message to the command queue and execute the task specified by the task message. Upon completion of the task, a completion message may be transmitted to an event publish queue", 0005 ; Examiner Note: the command API (frontend) necessarily sends task messages to the command task queue (within service 401 equating to a task manager))
As per claim 7, Tripathi in view of Berry in further view of McClory fully discloses the limitations of claim 6.
Furthermore, McClory discloses:
the task manager maintains three task queues that include: a Request Queue task queue; a Notified Queue task queue; and a Running Queue task queue ("A read cache may be updated with the request identifier, and the task message may be transmitted to a command task queue. A worker process may detect the task message upon transmission of the task message to the command queue and execute the task specified by the task message. ", 0005 ; "In an embodiment, a status of the task specified by the task message may be periodically transmitted to the read queue.", 0006 ; Examiner Note: the read cache equates to a Request Queue task queue, the command task queue equates to a notified queue task queue, and the read queue equates to a running queue task queue)
As per claim 8, Tripathi in view of Berry in further view of McClory fully discloses the limitations of claim 7.
Furthermore, McClory discloses:
when the task manager receives a task for execution from the front end, the task manager queues the task to the RequestQueue (“"According to an embodiment, a request for a service may be received by a command application programming interface (API) from a client device. A request identifier and a task message specifying a task to be performed by the service may be generated based on the received request. A read cache may be updated with the request identifier", 0005)
As per claim 9, Tripathi in view of Berry in further view of McClory fully discloses the limitations of claim 7.
Furthermore, McClory discloses:
one or more workers are available to execute a task, the task manager selects a task queued to the Request Queue for execution; notifies one or more of the multiple workers that the selected task is available for execution; and moves the selected task from the Request Queue to the Notified Queue. (“A read cache may be updated with the request identifier, and the task message may be transmitted to a command task queue. A worker process may detect the task message upon transmission of the task message to the command queue and execute the task specified by the task message.”, 0005)
As per claim 10, Tripathi in view of Berry in further view of McClory fully discloses the limitations of claim 9.
Furthermore, McClory discloses:
the task manager selects the task queued to the Request Queue based on one or more of: a priority assigned to the task; the capabilities and capacities of the available workers; the numbers of tasks queued to the Request Queue for each priority; and the length of time since a task of each priority was last executed. (“command task queue and event publish queue may implement any type of queuing method such as but not limited to FIFO, LIFO, priority queuing, or fair queuing.”, 0135)
As per claim 14, Tripathi in view of Berry in further view of McClory fully discloses the limitations of claim 9.
Furthermore, McClory discloses:
When execution of a task has continued for more than a threshold time and/or has consumed more than a threshold amount of computational resources, the task manager preempts execution of the task and moves the task from the Running Queue to the Request Queue. (““command task queue and event publish queue may implement any type of queuing method such as but not limited to FIFO, LIFO, priority queuing, or fair queuing.”, 0135”)
As per claim 15, McClory discloses:
A method that manages coordinates multiple stages of task execution using multiple task queues by a task manager within an infrastructure-as-code cloud-infrastructure- management service, the infrastructure-as-code cloud-infrastructure-management service comprising a frontend having a management interface that receives cloud-infrastructure- management commands and requests, ("A read cache may be updated with the request identifier, and the task message may be transmitted to a command task queue. A worker process may detect the task message upon transmission of the task message to the command queue and execute the task specified by the task message. Upon completion of the task, a completion message may be transmitted to an event publish queue.", 0005 ; “command task queue and event publish queue may implement any type of queuing method such as but not limited to FIFO, LIFO, priority queuing, or fair queuing.”, 0135 ; Examiner Note: the service (fig.1, 401) of McClory equates to a task manager. The service (401) of McClory receives tasks from the command API, equating to the frontend)
a frontend service that generates tasks corresponding to the cloud-infrastructure-management commands and requests received through the management interface ("According to an embodiment, a request for a service may be received by a command application programming interface (API) from a client device. A request identifier and a task message specifying a task to be performed by the service may be generated based on the received request", 0005)
task manager which receives tasks from the frontend, (see fig.1, service 401)
multiple workers that each executes tasks ; (see fig.1, worker 430 ; “According to an embodiment, worker 430 may represent one or more processes or threads executing as part of service 410 designed to execute a service task.”, 0132)
managing, by the task manager, a RequestQueue task queue, a NotifiedQueue task queue, and a RunningQueue task queue; and moving, by the task manager, a task among the RequestQueue, the Notified Queue task queue, and the Running Queue as the task traverses multiple execution stages. ("According to an embodiment, a request for a service may be received by a command application programming interface (API) from a client device. A request identifier and a task message specifying a task to be performed by the service may be generated based on the received request. A read cache may be updated with the request identifier, and the task message may be transmitted to a command task queue. A worker process may detect the task message upon transmission of the task message to the command queue and execute the task specified by the task message. Upon completion of the task, a completion message may be transmitted to an event publish queue.", 0005 ; "In an embodiment, a status of the task specified by the task message may be periodically transmitted to the read queue.", 0006)
an event stream to which the multiple workers publish events ("Upon completion of the task, a completion message may be transmitted to an event publish queue.", 0005)
Furthermore, Tripathi discloses:
an infrastructure-as-code cloud-infrastructure- management service ("Embodiments herein can facilitate IAC deployments", 0132)
Furthermore, Berry discloses:
including idempotent state commands ("As shown, a user expresses a desire (e.g., intent) for a particular virtualization system image to be built. Intent engine 101 receives the expressed desire and interacts with an image builder 131 that generates a virtualization system image that comports with the expressed desire. The user need only express a desired final state of the virtualization system image (operation 1). The intent engine recursively decomposes the expressed intent into a set of executable idempotent steps (operation 2). The executable idempotent steps are fired or otherwise communicated to the image builder 131 (operation 3). When all of the executable idempotent steps have been carried out by the image builder, a virtualization system image that comports with the expressed desire has been built and is in a condition to be deployed (operation 4).", 0033 ; Examiner Note: the intent engine equates to a management interface)
As per claim 16, it is a method claim with substantially the same limitations as claim 8, and as such, it is rejected for substantially the same reasons.
As per claim 17, it is a method claim with substantially the same limitations as claim 9, and as such, it is rejected for substantially the same reasons.
As per claim 18, it is a method claim with substantially the same limitations as claim 10, and as such, it is rejected for substantially the same reasons.
As per claim 22 it is a method claim with substantially the same limitations as claim 14, and as such, it is rejected for substantially the same reasons.
As per claim 23, it is a physical data-storage device claim with substantially the same limitations as claim 1, and as such, it is rejected for substantially the same reasons.
Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over Tripathi (US 20230048653 A1) in view of Berry (US 20220137946 A1) in further view of McClory (US 20180321993 A1) in further view of Malfait (US 12531138 B2).
As per claim 2, Tripathi in view of Berry in further view of McClory fully discloses the limitations of claim 1, but does not disclose multiple GraphQL APIs.
However, Malfait discloses:
the frontend-service management interface comprises multiple GraphQL APIs ("In addition to supporting direct content access externally via GraphQL API calls, the platform also provides reporting microservice 134 which exposes platform content via configured REST APIs. Each configured API is exposed via API Gateway 103 and is associated with an internal GraphQL query that retrieves content of interest for the report.", 0041)
It would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the system of Tripathi in view of Berry in further view of McClory with the system of Malfait in order to provide the system with GraphQL APIs which allow API consumers to precisely identify which object fields (attributes) are to be returned in query results, thus eliminating the potential concern of very large datasets being returned to the client in response to a broad query invocation, while at the same time eliminating the need to implement multiple purpose-specific APIs supporting various combinations of object content to suit the needs of the client. (Malfait, [0052]).
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over Tripathi (US 20230048653 A1) in view of Berry (US 20220137946 A1) in further view of McClory (US 20180321993 A1) in further view of Malfait (US 12531138 B2) in further view of Raman (US 20200089791 A1).
As per claim 3, Tripathi in view of Berry in further view of McClory in further view of Malfait fully discloses the limitations of claim 2.
Furthermore, Malfait discloses:
the multiple GraphQL APIs include: a Submit Task GraphQL API, through which cloud-infrastructure-management deployment-and-configuration commands are input to the infrastructure-as-code cloud- infrastructure-management service ("In some examples, database 105 implements GraphQL queries and mutations to manage data. For example, study design microservice 126 implements GraphQL APIs that invoke database 105 as an efficient and flexible way to retrieve clinical development content.”, 0049 ; “Microservices 122, 124, 126, 128, 130, 132, and 134 are “GraphQL first” in nature. Microservices 122, 124, 126, 128, 130, 132, and 134 expose core Create/Read/Update/Delete (CRUD) actions on their business objects via GraphQL queries and mutations.", 0050 ; Examiner Note: the “create” and “update” actions performed via GraphQL queries equate to a Submit Task GraphQL API)
a Query Task GraphQL API, through which status queries regarding previously submitted cloud-infrastructure-management commands and requests are input to the infrastructure-as-code cloud-infrastructure-management service (“Microservices 122, 124, 126, 128, 130, 132, and 134 are “GraphQL first” in nature. Microservices 122, 124, 126, 128, 130, 132, and 134 expose core Create/Read/Update/Delete (CRUD) actions on their business objects via GraphQL queries and mutations.", 0050 ; Examiner Note: the “read” action performed via GraphQL query equates to a Query task GraphQL API.
a Retrieved Schema GraphQL API, through which the schemas for infrastructures within cloud-computing-facilities can be requested from the infrastructure-as-code cloud- infrastructure-management service. ("In addition to supporting direct content access externally via GraphQL API calls, the platform also provides reporting microservice 134 which exposes platform content via configured REST APIs. Each configured API is exposed via API Gateway 103 and is associated with an internal GraphQL query that retrieves content of interest for the report.", 0041)
Tripathi in view of Berry in further view of McClory in further view of Malfait discloses the above limitations of claim 3, but does not disclose requests to validate structured-layered-state data.
However, Raman discloses:
a Validate SLS GraphQL API, through which requests to validate structured-layered- state data are input to the infrastructure-as-code cloud-infrastructure-management service ("the processor may be further configured to control the network interface to transmit a blockchain request to validate state data within a first data point among the plurality of successive data points to a first subset of endorsing nodes of a blockchain network, and transmit a blockchain request to validate state data within a second data point among the plurality of successive data points to a second subset of endorsing nodes which are mutually exclusive from the first subset of endorsing nodes of the blockchain network for parallel endorsement of the first and second data points.", 0008 ; Examiner Note: the state data of set of endorsing nodes of a blockchain network equates to structured-layered-state data)
The system of Tripathi in view of Berry in further view of McClory in further view of Malfait would be capable of using a GraphQL API to input requests for validation. It would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the system of Tripathi in view of Berry in further view of McClory in further view of Malfait with the system of Raman in order to provide a coded computing-based endorsement allocation to reduce computational time for state validation (Raman, [0052]).
Claims 11-12, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Tripathi (US 20230048653 A1) in view of Berry (US 20220137946 A1) in further view of McClory (US 20180321993 A1) in further view of Neild (US 10884797 B2).
As per claim 11, Tripathi in view of Berry in further view of McClory fully discloses the limitations of claim 7.
Furthermore, McClory discloses:
when a worker, having been notified of a task available for execution, accepts the task for execution and notifies the task manager of the worker's acceptance of the task, the task manager moves the accepted task from the Notified Queue to the Running Queue (“A worker process may detect the task message upon transmission of the task message to the command queue and execute the task specified by the task message.”, 0005 ; “A status request including the request identifier may be received by a read API, and the status from the read queue may be retrieved in response to receiving the status request.”, 0006)
Tripathi in view of Berry in further view of McClory fully discloses the above limitations of claim 11, but does not disclose assigning a status of “picked” when a worker accepts a task.
However, Neild discloses:
associates a status of Picked with the task. “In various examples there may be at least two distinct not active states: a ‘ready state and one or more waiting’ states. A scheduled task in the ready state is available to be selected by the scheduled task scheduler for execution and once selected (i.e. activated) the scheduled task would move from the ready state into the active state..”, detailed description, Par.8 ; Examiner Note: being in the ready state equates to having a status of ‘picked’ )
It would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the system of Tripathi in view of Berry in further view of McClory with that of Neild in order to provide the system with the ability to be schedule and de-schedule (e.g. by placing a task into one or more Waiting states' where they are not active) a task many times by the scheduled task scheduler before a task is completed (Neild, [detailed description, Par.6])
As per claim 12, Tripathi in view of Berry in further view of McClory fully discloses the limitations of claim 7
Furthermore, Neild discloses:
when a worker begins execution of a task and notifies the task manager that execution of the task has begun, the task manager changes the status associated with the task to Running. (“each queue corresponding to a particular state and comprising only the scheduled tasks that are in that state (e.g. an active queue comprising only those scheduled tasks in the active state)”, detailed description, Par.9)
The combination of Tripathi in view of Berry in view of McClory would provide a system capable of changing the task status to “running” (or active) when a worker begins execution and notifies the task manager that execution has begun.
As per claim 19, it is a method claim with substantially the same limitations as claim 11, and as such, it is rejected for substantially the same reasons.
As per claim 20, it is a method claim with substantially the same limitations as claim 12, and as such, it is rejected for substantially the same reasons.
Claims 13 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Tripathi (US 20230048653 A1) in view of Berry (US 20220137946 A1) in further view of McClory (US 20180321993 A1) in further view of Vasanth (US 12008496 B1) .
As per claim 13, Tripathi in view of Berry in further view of McClory fully discloses the limitations of claim 7.
Furthermore, McClory discloses:
when execution of a task finishes, the worker executing the task publishes a task-completion or task-failure event to the event stream which is received by the frontend service, ("Upon completion of the task, a completion message may be transmitted to an event publish queue.", 0005 )
McClory discloses the above limitation of claim 13, but does not explicitly removing a task from a Running queue.
However, Vasanth discloses:
in response to which the frontend service notifies the task manager that execution of the task is finished and the task manager removes the task from the Running Queue. ("Upon completion of the task 116, the task manager component 138 may update the task queue 202 and remove the task 116 from the task queue 202", 0074)
It would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the system of Tripathi in view of Berry in further view of McClory with the system of Vasanth in order to provide a centralized platform to manage agents, optimize the assignment of tasks, and increase productivity (Vasanth, [0009]).
As per claim 21, it is a method claim with substantially the same limitations as claim 13, and as such, it is rejected for substantially the same reasons.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ROSS MICHAEL VINCENT whose telephone number is (703)756-1408. The examiner can normally be reached Mon-Fri 8:30AM-5:30PM.
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, April Blair can be reached at (571) 270-1014. 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.
/R.M.V./
Examiner, Art Unit 2196
/HIREN P PATEL/Primary Examiner, Art Unit 2196