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 .
DETAILED ACTION
1. This Office Action is in response to the application filed on 02/19/2024. Claims 1-26 are pending in this application. Claims 1 and 14 are independent claims.
Claim Rejections - 35 USC § 101
2. 35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
3. Claims 1-26 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The independent claims 1 and 14 are corresponding to one of four statutory categories including method, system, and method respectively under step 1. The claims 1 and 14 similarly recite “an infrastructure as code system for creating and managing cloud infrastructure, wherein the system comprising one or more processors configured to perform the operations of: retrieving, from one or more service providers, provider documentation and one or more provider schema; analyzing, for each provider, the provider documentation and one or more provider schema; identifying, based on the analysis, one or more resources from the one or more service providers; generating, based on the analysis, an identity card for each of the one or more resources wherein the identity card comprises one or more parameters; and generating, based on the analysis, a resource panel wherein the resource panel comprises one or more resource icons, wherein the one or more resource icons correspond to the one or more resources” and claim 14 additionally recites “generating a user interface comprising a resource panel, a design panel and a code panel”.
The limitation of the claims 1 and 14 of “analyzing, for each provider, the provider documentation and one or more provider schema;” as drafted, is a mental process that, under its broadest reasonable interpretation, covers mental processes but for the recitation of generic computer components. For example, but for the “analyzing” in the context of this claim encompasses the user may analyze, for each provider, the provider documentation and one or more provider schema with a pen and paper or in a human mind. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea under Step 2A Prong 1.
The limitation of the claims 1 and 14 of “identifying, based on the analysis, one or more resources from the one or more service providers” as drafted, is a mental process that, under its broadest reasonable interpretation, covers mental processes but for the recitation of generic computer components. For example, but for the “identifying” in the context of this claim encompasses the user may identify, based on the analysis, one or more resources from the one or more service providers with a pen and paper or in a human mind. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea under Step 2A Prong 1.
This judicial exception is not integrated into a practical application. In particular, the claims 1 and 14 recite additional elements such as “retrieving, from one or more service providers, provider documentation and one or more provider schema”.
Examiner would like to point out that with the broad reasonable interpretation, this element amounts to mere data gathering under MPEP § 2106.05(g): Insignificant Extra-Solution Activity, which does not impose any meaningful limits on practicing the mental process (insignificant additional element). Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to insignificant additional elements under Step 2A Prong 2 and Step 2B.
This judicial exception is not integrated into a practical application. In particular, the claims 1 and 14 recite additional elements such as “generating, based on the analysis, an identity card for each of the one or more resources wherein the identity card comprises one or more parameters”.
Examiner would like to point out that with the broad reasonable interpretation, this element amounts to mere data displaying under MPEP § 2106.05(g): Insignificant Extra-Solution Activity, which does not impose any meaningful limits on practicing the mental process (insignificant additional element). Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to insignificant additional elements under Step 2A Prong 2 and Step 2B.
This judicial exception is not integrated into a practical application. In particular, the claims 1 and 14 recite additional elements such as “generating, based on the analysis, a resource panel wherein the resource panel comprises one or more resource icons, wherein the one or more resource icons correspond to the one or more resources”.
Examiner would like to point out that with the broad reasonable interpretation, this element amounts to mere data displaying under MPEP § 2106.05(g): Insignificant Extra-Solution Activity, which does not impose any meaningful limits on practicing the mental process (insignificant additional element). Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to insignificant additional elements under Step 2A Prong 2 and Step 2B.
This judicial exception is not integrated into a practical application. In particular, the claims 2 and 14 recite additional elements such as “generating a user interface comprising a resource panel, a design panel and a code panel”.
Examiner would like to point out that with the broad reasonable interpretation, this element amounts to mere data gathering under MPEP § 2106.05(g): Insignificant Extra-Solution Activity, which does not impose any meaningful limits on practicing the mental process (insignificant additional element). Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to insignificant additional elements under Step 2A Prong 2 and Step 2B.
The limitation of the claims 2 and 15 of “generating a user interface comprising a resource panel, a design panel and a code panel” as drafted, is a mental process that, under its broadest reasonable interpretation, covers mental processes but for the recitation of generic computer components. For example, but for the “generating a user interface (designing)” in the context of this claim encompasses the user may generate a user interface with a pen and paper or in a human mind. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea under Step 2A Prong 1.
The limitation of the claims 2 and 15 of “receiving, from a user, selection of a resource in the resource panel to be added to a design architecture displayed in the design panel and a placement of the resource within the design architecture” as drafted, is a mental process that, under its broadest reasonable interpretation, covers mental processes but for the recitation of generic computer components. For example, but for the “selecting” in the context of this claim encompasses the user may select a resource in the resource panel to be added to a design architecture displayed in the design panel and a placement of the resource within the design architecture with a pen and paper or in a human mind. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea under Step 2A Prong 1.
The limitation of the claims 2 and 15 of “identifying the placement of the resource; displaying, in the user interface, the identity card corresponding to the added resource” as drafted, is a mental process that, under its broadest reasonable interpretation, covers mental processes but for the recitation of generic computer components. For example, but for the “identifying” in the context of this claim encompasses the user may identify the placement of the resource; displaying, in the user interface, the identity card corresponding to the added resource with a pen and paper or in a human mind. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea under Step 2A Prong 1.
The limitation of the claims 2 and 15 of “generating code based on the design architecture and the identity card parameters corresponding to the resource” as drafted, is a mental process that, under its broadest reasonable interpretation, covers mental processes but for the recitation of generic computer components. For example, but for the “generating a code (writing)” in the context of this claim encompasses the user may generate code based on the design architecture and the identity card parameters corresponding to the resource with a pen and paper or in a human mind. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea under Step 2A Prong 1.
The limitation of the claims 2 and 15 of “determining one or more affected resources in the design architecture affected by the addition of the resource” as drafted, is a mental process that, under its broadest reasonable interpretation, covers mental processes but for the recitation of generic computer components. For example, but for the “determining” in the context of this claim encompasses the user may determine one or more affected resources in the design architecture affected by the addition of the resource with a pen and paper or in a human mind. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea under Step 2A Prong 1.
The limitation of the claims 2 and 15 of “updating one or more affected identity card parameters of the one or more affected resources” as drafted, is a mental process that, under its broadest reasonable interpretation, covers mental processes but for the recitation of generic computer components. For example, but for the “updating parameters (writing)” in the context of this claim encompasses the user may update one or more affected identity card parameters of the one or more affected resources with a pen and paper or in a human mind. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea under Step 2A Prong 1.
The limitation of the claims 2 and 15 of “generate updated code for the one or more affected resources based at least in part on the one or more updated identity card parameters” as drafted, is a mental process that, under its broadest reasonable interpretation, covers mental processes but for the recitation of generic computer components. For example, but for the “generating updated code (writing)” in the context of this claim encompasses the user may generate updated code for the one or more affected resources based at least in part on the one or more updated identity card parameters with a pen and paper or in a human mind. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea under Step 2A Prong 1.
This judicial exception is not integrated into a practical application. In particular, the claims 2 and 15 recite additional elements such as “receiving, from the user, input for each of the one or more identity card parameters, wherein the input comprises text values or selection of a displayed predefined value”.
Examiner would like to point out that with the broad reasonable interpretation, this element amounts to mere data gathering under MPEP § 2106.05(g): Insignificant Extra-Solution Activity, which does not impose any meaningful limits on practicing the mental process (insignificant additional element). Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to insignificant additional elements under Step 2A Prong 2 and Step 2B.
This judicial exception is not integrated into a practical application. In particular, the claims 3 and 16 recite additional elements such as “the selection and placement of the resource within the design architecture is performed by a drag and drop operation”.
Examiner would like to point out that with the broad reasonable interpretation, this element amounts to apply it under MPEP § 2106.05(f): Mere Instructions to Apply an Exception, which does not impose any meaningful limits on practicing the mental process (insignificant additional element). Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to insignificant additional elements under Step 2A Prong 2 and Step 2B.
This judicial exception is not integrated into a practical application. In particular, the claims 4 and 17 recite additional elements such as “the user interface is a browser-based application”.
Examiner would like to point out that with the broad reasonable interpretation, this element
amounts to field of use under MPEP § 2106.05(h): Field of Use and Technological Environment, which
does not impose any meaningful limits on practicing the mental process. Accordingly, this additional
element does not integrate the abstract idea into a practical application because it does not impose any
meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea under Step 2A Prong 2 and 2B.
This judicial exception is not integrated into a practical application. In particular, the claims 5 and 18 recite additional elements such as “the user interface is a standalone application running on a client device”.
Examiner would like to point out that with the broad reasonable interpretation, this element
amounts to field of use under MPEP § 2106.05(h): Field of Use and Technological Environment, which
does not impose any meaningful limits on practicing the mental process. Accordingly, this additional
element does not integrate the abstract idea into a practical application because it does not impose any
meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea under Step 2A Prong 2 and 2B.
The limitation of the claims 6 and 19 of “analyzing the provider documentation and provider schema and identifying the one or more resources are performed by a trained machine learning model” as drafted, is a mental process that, under its broadest reasonable interpretation, covers mental processes but for the recitation of generic computer components. For example, but for the “analyzing” and “identifying” in the context of this claim encompasses the user may analyze the provider documentation and provider schema and identify the one or more resources are performed by a trained machine learning model with a pen and paper or in a human mind. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea under Step 2A Prong 1.
This judicial exception is not integrated into a practical application. In particular, the claims 7 and 20 recite additional elements such as “the trained machine learning model is a large language model”.
Examiner would like to point out that with the broad reasonable interpretation, this element
amounts to field of use under MPEP § 2106.05(h): Field of Use and Technological Environment, which
does not impose any meaningful limits on practicing the mental process. Accordingly, this additional
element does not integrate the abstract idea into a practical application because it does not impose any
meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea under Step 2A Prong 2 and 2B.
This judicial exception is not integrated into a practical application. In particular, the claims 8 and 21 recite additional elements such as “the trained machine learning model is a neural network”.
Examiner would like to point out that with the broad reasonable interpretation, this element
amounts to field of use under MPEP § 2106.05(h): Field of Use and Technological Environment, which
does not impose any meaningful limits on practicing the mental process. Accordingly, this additional
element does not integrate the abstract idea into a practical application because it does not impose any
meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea under Step 2A Prong 2 and 2B.
The limitation of the claims 9 and 22 of “automatically populate one or more identity card parameters of the resource based at least in part on the identifying the placement of the resource” as drafted, is a mental process that, under its broadest reasonable interpretation, covers mental processes but for the recitation of generic computer components. For example, but for the “analyzing” and “populating parameters (writing)” in the context of this claim encompasses the user may populate one or more identity card parameters of the resource based at least in part on the identifying the placement of the resource with a pen and paper or in a human mind. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea under Step 2A Prong 1.
This judicial exception is not integrated into a practical application. In particular, the claims 10 and 23 recite additional elements such as “automatically populating the one or more identity card parameters is further based at least in part on analysis by a second trained machine learning model, wherein the second trained machine learning model is trained on a dataset comprising one or more historic design architectures”.
Examiner would like to point out that with the broad reasonable interpretation, this element
amounts to field of use under MPEP § 2106.05(h): Field of Use and Technological Environment, which
does not impose any meaningful limits on practicing the mental process. Accordingly, this additional
element does not integrate the abstract idea into a practical application because it does not impose any
meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea under Step 2A Prong 2 and 2B.
This judicial exception is not integrated into a practical application. In particular, the claims 11 and 24 recite additional elements such as “the resource panel is organized into categories and sections”.
Examiner would like to point out that with the broad reasonable interpretation, this element
amounts to field of use under MPEP § 2106.05(h): Field of Use and Technological Environment, which
does not impose any meaningful limits on practicing the mental process. Accordingly, this additional
element does not integrate the abstract idea into a practical application because it does not impose any
meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea under Step 2A Prong 2 and 2B.
This judicial exception is not integrated into a practical application. In particular, the claims 12 and 25 recite additional elements such as “one or more of the resources has more than one version and wherein an identity card is generated for each version”.
Examiner would like to point out that with the broad reasonable interpretation, this element
amounts to field of use under MPEP § 2106.05(h): Field of Use and Technological Environment, which
does not impose any meaningful limits on practicing the mental process. Accordingly, this additional
element does not integrate the abstract idea into a practical application because it does not impose any
meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea under Step 2A Prong 2 and 2B.
This judicial exception is not integrated into a practical application. In particular, the claims 13 and 26 recite additional elements such as “receiving, from the user, a block of edited code”.
Examiner would like to point out that with the broad reasonable interpretation, this element amounts to mere data gathering under MPEP § 2106.05(g): Insignificant Extra-Solution Activity, which does not impose any meaningful limits on practicing the mental process (insignificant additional element). Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to insignificant additional elements under Step 2A Prong 2 and Step 2B.
The limitation of the claims 13 and 26 of “updating, based on the received block of edited code, the design architecture and identity card parameters of one or more linked resources” as drafted, is a mental process that, under its broadest reasonable interpretation, covers mental processes but for the recitation of generic computer components. For example, but for the “updating the design architecture and parameters (designing/writing)” in the context of this claim encompasses the user may update, based on the received block of edited code, the design architecture and identity card parameters of one or more linked resources with a pen and paper or in a human mind. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea under Step 2A Prong 1.
Dependent claims 2-13 and 15-26 are also similar rejected under same rationale as cited above wherein these claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. These claims are merely further elaborate the mental process itself or providing additional definition of process which does not impose any meaningful limits on practicing the abstract idea. Claims 2-13 and 15-26 are also rejected for incorporating the deficiency of their independent claims 1 and 14 respectively.
Claim Rejections - 35 USC § 103
4. 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.
5. 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.
6. Claim 1 is rejected under 35 U.S.C. 103 as being unpatentable over Gao (US PGPub 20180302335), in view of Parulekar (US PGPub 20230059526).
As per Claim 1, Gao teaches of an infrastructure as code system for creating and managing cloud infrastructure, (Par 2, Cloud providers offer both Infrastructure as a Service (IaaS) and Container as a Service (CaaS) (i.e., Container Cloud) to users.)
wherein the system comprising one or more processors configured to perform the operations of: retrieving, from one or more service providers, provider documentation and one or more provider schema; (Par 7, Embodiments of the present invention provide computing resource deployment that automatically meets cloud users' business requirements via advanced orchestration crossing IaaS and CaaS clouds. Orchestration patterns and deployment utilities may be generated and optimized through continuous monitoring and analysis of utilization time and user behavior. Par 28, In step 206, requirement module 110 (see FIG. 1) receives a user request which specifies user requirements of computing resources that need to be newly placed in IaaS cloud 126 (see FIG. 1) or container cloud 128 (see FIG. 1). Par 29, (see FIG. 1) generates an orchestration topology that specifies a new placement of one or more of the computing resources into IaaS cloud 126 (see FIG. 1) Par 31, In step 210, based on the orchestration topology generated in step 208, deployment orchestration module 112 (see FIG. 1) automatically deploys the one or more of the computing resources into IaaS cloud 126 (see FIG. 1) and automatically deploys the other one or more of the computing resources into container cloud 128 (see FIG. 1). )
analyzing, for each provider, the provider documentation and one or more provider schema; (Par 7, Embodiments of the present invention provide computing resource deployment that automatically meets cloud users' business requirements via advanced orchestration crossing IaaS and CaaS clouds. Orchestration patterns and deployment utilities may be generated and optimized through continuous monitoring and analysis of utilization time and user behavior.)
Gao does not specifically teach, however Parulekar teaches of identifying, based on the analysis, one or more resources from the one or more service providers; (Par 68, The solution provides the ability to choose the resources to which the fixes can be applied along with workflows for managing exceptions.)
generating, based on the analysis, an identity card for each of the one or more resources wherein the identity card comprises one or more parameters; and (Par 91, FIG. 5 with 500 shows an exploded view of asset/resource hierarchy and the different metadata that will be collected for contextualization to be done by the Cloud Security Engine (CSE) for policies and deployments. 510 shows the hierarchy of different cloud resources. FIG. 5 shows how context and risk is specified for the environment in which the component or module or architecture will be deployed. Example, “The Secure Enterprise Inc.” with the main overarching control of all different resources is at the top)
generating, based on the analysis, a resource panel wherein the resource panel comprises one or more resource icons, wherein the one or more resource icons correspond to the one or more resources. (Par 37, FIG. 5 is a view navigating the Cloud Security Engine (CSE), resource hierarchy design with context and risk information, according to one embodiment. Par 92, FIG. 6 depicts 600 view illustrating an example of using different components while building a new cloud-based architecture. 610 [resource icons representing resources] shows different available components. Par 95, FIG. 7 shows different pre-coded, pre-tested, standards compliant, risk reduction policy recommendations 700 with regards to different cloud components and services, computing software designs techniques depicted with background and decision intelligence for each policy.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add identifying, based on the analysis, one or more resources from the one or more service providers; generating, based on the analysis, an identity card for each of the one or more resources wherein the identity card comprises one or more parameters; and generating, based on the analysis, a resource panel wherein the resource panel comprises one or more resource icons, wherein the one or more resource icons correspond to the one or more resources, as conceptually seen from the teaching of Parulekar, into that of Gao because this modification can help visualize the resource and service configuration for Cloud-based Infrastructure as a Service (IaaS) and Container as a Service (CaaS) in order to design, manage and update the resources and services for the IaaS and CaaS.
7. Claims 2-4, 6, 9, 11-17, 19, 22 and 24-26 are rejected under 35 U.S.C. 103 as being unpatentable over Gao (US PGPub 20180302335), in view of Parulekar (US PGPub 20230059526), and further in view of Douglas (US PGPub 20180217818).
As per Claim 2, Gao does not specifically teach, however Parulekar teaches of the system of claim 1, wherein the one or more processors are further configured to perform the operations of: generating a user interface comprising a resource panel, a design panel and [a code panel]; (Figs. 5-7 and par 90-92, FIG. 5 with 500 shows an exploded view of asset/resource hierarchy and the different metadata that will be collected for contextualization to be done by the Cloud Security Engine (CSE) for policies and deployments. 510 shows the hierarchy of different cloud resources. FIG. 5 shows how context and risk is specified for the environment in which the component or module or architecture will be deployed.)
receiving, from a user, selection of a resource in the resource panel to be added to a design architecture displayed in the design panel and a placement of the resource within the design architecture; (Figs. 5-7 and par 90-92, For example, a user may select his or her own architecture and just leverage modules or components. In some instances, a user may use all three.)
identifying the placement of the resource; (par 83 and 90-92, FIG. 5 shows how context and risk is specified for the environment in which the component or module or architecture will be deployed. Example, “The Secure Enterprise Inc.” with the main overarching control of all different resources is at the top. In the example, Engineering, Infrastructure Ops and Business Units are three different example parts of the main business. Further subcomponents or categories are displayed for each of the categories. For example, each business function, Infrastructure and services deployed under any node in the hierarchy will have configuration rules contextualized based on the metadata including that collected in interface 520. Contextual and risk information including asset ownership and risk categorization can be configured using an easy to use interface at 520.)
displaying, in the user interface, the identity card corresponding to the added resource; receiving, from the user, input for each of the one or more identity card parameters, wherein the input comprises text values or selection of a displayed predefined value; (Figs. 5-7 and par 92, FIG. 6 depicts 600 view illustrating an example of using different components while building a new cloud-based architecture. 610 shows different available components. FIG. 6 is example of pre-seeded in, design in, or baked in security. The security policy baseline on the right is pre-seeded when they drag the Virtual Private Cloud (“vpc”) component on the graph. When a user drags one or more, the s creates a module or architecture, 600 is the design window that allows different components to be dragged or dropped into the window. 620 shows a detailed configuration view for each of the components that is selected.)
determining one or more affected resources in the design architecture affected by the addition of the resource; (Par 61, The solution provides pre-coded, pre-tested, drag and drop, plug and play cloud components, modules (pre-coded collection of components) and architectures that have security policies and frameworks predefined and designed-in based on applicable baselines and compliance standards that can further be contextualized and modified to meet business and technical needs. Par 68, The solution's decision intelligence engine guides monitoring and remediation with contextual and specific fixes for drifts and policy compliance issues that can be tested in non-live environments, approved and then rapidly deployed in live environments supporting agile processes. The solution provides the ability to choose the resources to which the fixes can be applied along with workflows for managing exceptions.)
updating one or more affected identity card parameters of the one or more affected resources; and (Par 75, FIG. 1 shows a diagram illustrating an example of systems and methods systems of the invention, the Cloud Security Engine (CSE), with different types and categories of computing devices including virtual devices. In one embodiment, as depicted in FIG. 1 different types of computing devices connect to the Cloud Security Engine (CSE) architecture 120. In the example of FIG. 1, different possible devices have been shown 110-1 through an nth client system 110-n, smartphones from 130-1 to 130-n, servers from 140-1, . . . 140-n. The computing devices with end-users is separated from the use of the computing devices in hosting applications, backend or server side in the Cloud Security Engine (CSE) architecture 120.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add identifying, based on the analysis, one or more resources from the one or more service providers; generating, based on the analysis, an identity card for each of the one or more resources wherein the identity card comprises one or more parameters; and generating, based on the analysis, a resource panel wherein the resource panel comprises one or more resource icons, wherein the one or more resource icons correspond to the one or more resources, as conceptually seen from the teaching of Parulekar, into that of Gao because this modification can help visualize the resource and service configuration for Cloud-based Infrastructure as a Service (IaaS) and Container as a Service (CaaS) in order to design, manage and update the resources and services for the IaaS and CaaS.
Neither Gao nor Parulekar specifically teaches, however Douglas teaches of generating a user interface comprising [a resource panel, a design panel and] a code panel; (Fig. 3 and par 22, Visual devops application 22 is configured and/or programmed for visual design of the architectural resources for a software product via the GUI 30. GUI 30 includes a top bar including an application title (shown as “Visual Devops”), a title for the current project (shown as “Test Stack #1”), and other interface elements such as a “Save” and “Options” button. GUI 30 further includes a development canvas 32 to place and arrange nodes to design an application as an architectural flow diagram 50. Par 80. Settings for the Function node may include name, outputs, timeout, memory, and/or source code. The name setting is a label for the node in the canvas. The name setting also may be used to identify the location of the source code in a repository (such as a Git repository).)
generating code based on the design architecture and the identity card parameters corresponding to the resource; (Par 52, In some examples, the set of architectural resources includes one or more function nodes. When the set of architectural resources includes a function node, method 200 may further include compiling source code associated with the function node into compiled code, and sending the compiled code to one or more of the infrastructure computers.)
generating updated code for the one or more affected resources based at least in part on the one or more updated identity card parameters. (Par 30, Furthermore, after visually presenting the architectural flow diagram at 220 based on the GUI inputs, method 200 optionally may include returning to 210 to further modify the architectural flow diagram, e.g., by recognizing selection of a different set of architectural resources based on GUI inputs adding or deleting an architectural resource to/from the development canvas. Based on the visual feedback of the architectural flow diagram, a software developer may design an architectural flow diagram incrementally/iteratively, adding/removing nodes and relationships to obtain a desired design.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add generating a user interface comprising a code panel; generating code based on the design architecture and the identity card parameters corresponding to the resource; generating updated code for the one or more affected resources based at least in part on the one or more updated identity card parameters, as conceptually seen from the teaching of Douglas, into that of Gao and Parulekar because this modification can help design the resource and service configurations for Cloud-based Infrastructure as a Service (IaaS) and Container as a Service (CaaS) in order for the user to code and update the resources and services for the IaaS and CaaS.
As per Claim 3, neither Gao nor Douglas specifically teaches, however Parulekar teaches of the system of claim 2, wherein the selection and placement of the resource within the design architecture is performed by a drag and drop operation. (Par 57, For example, the invention includes modeling, designing, building, configuring, testing, deploying and implementing secure hybrid cloud architecture, infrastructure and environments. Using a drag-and-drop graphical user interface, infrastructure, services and application designs may be selected and assembled. The CSE provides elements and components to build designs as secured elements and components which can ultimately be tested, staged, deployed and orchestrated.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add the selection and placement of the resource within the design architecture is performed by a drag and drop operation, as conceptually seen from the teaching of Parulekar, into that of Gao and Douglas because this modification can help design, manage and update the resource and service configuration for Cloud-based Infrastructure as a Service (IaaS) and Container as a Service (CaaS) by visualizing the resources and services for the IaaS and CaaS via GUI.
As per Claim 4, neither Gao nor Douglas specifically teaches, however Parulekar teaches of the system of claim 2, wherein the user interface is a browser-based application. (Par 46, Examples include architectures with pre-seeded secure configurations customizable in drag and drop, point and click interfaces for Mobile Applications and Services, Website Applications and Services, Operational Cloud Services, and Internet of Things, among others. Par 112, Users can access the protocols of the private network through a web browser or other container application located on their client system.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add the user interface is a browser-based application, as conceptually seen from the teaching of Parulekar, into that of Gao and Douglas because this modification can help design, manage and update the resource and service configuration for Cloud-based Infrastructure as a Service (IaaS) and Container as a Service (CaaS) by visualizing the resources and services for the IaaS and CaaS via GUI.
As per Claim 6, Gao further teaches of the system of claim 2, wherein analyzing the provider documentation and provider schema and identifying the one or more resources are performed by a trained machine learning model. (Par 12, Embodiments of the present invention create a mixed orchestration mechanism which employs machine learning to optimize computing resource deployment between an IaaS cloud and a container cloud (i.e., between an IaaS cloud environment and a CaaS cloud environment). Based on a business analysis of continuous infrastructure monitoring data (i.e., utilization, nodes relationship, middleware, tools, and user behavior), embodiments of the present invention automatically generate and maintain a pattern repository with a self-study pattern decision tree. Par 30-33, In step 210, based on the orchestration topology generated in step 208, deployment orchestration module 112 (see FIG. 1) automatically deploys the one or more of the computing resources into IaaS cloud 126 (see FIG. 1) and automatically deploys the other one or more of the computing resources into container cloud 128 (see FIG. 1). The utilization threshold amount is a result of machine learning from utilization data from cloud nodes. In one embodiment, pattern management module 104 (see FIG. 1) determines the most common node relationship patterns in pattern decision tree 124 (see FIG. 1) and determines that the data monitored in step 202 does not include node relationships.)
As per Claim 9, Gao further teaches of the system of claim 6, wherein the system is further configured to automatically populate one or more identity card parameters of the resource based at least in part on the identifying the placement of the resource. (Par 61-62, The solution provides pre-coded, pre-tested, drag and drop, plug and play cloud components, modules (pre-coded collection of components) and architectures that have security policies and frameworks predefined and designed-in based on applicable baselines and compliance standards that can further be contextualized and modified to meet business and technical needs. The solution automatically codes for the organization's cloud infrastructure, services, and software component deployments as the user models, tests and deploys with the plug and play components, modules and architectures that are prebaked with security.)
As per Claim 11, neither Gao nor Douglas specifically teaches, however Parulekar teaches of the system of claim 2, wherein the resource panel is organized into categories and sections. (Par 75, FIG. 1 shows a diagram illustrating an example of systems and methods systems of the invention, the Cloud Security Engine (CSE), with different types and categories of computing devices including virtual devices. In one embodiment, as depicted in FIG. 1 different types of computing devices connect to the Cloud Security Engine (CSE) architecture 120. In the example of FIG. 1, different possible devices have been shown 110-1 through an nth client system 110-n, smartphones from 130-1 to 130-n, servers from 140-1, . . . 140-n. The computing devices with end-users is separated from the use of the computing devices in hosting applications, backend or server side in the Cloud Security Engine (CSE) architecture 120. Par 91, Further subcomponents or categories are displayed for each of the categories. For example, each business function, Infrastructure and services deployed under any node in the hierarchy will have configuration rules contextualized based on the metadata including that collected in interface 520. Contextual and risk information including asset ownership and risk categorization can be configured using an easy to use interface at 520.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add the resource panel is organized into categories and sections, as conceptually seen from the teaching of Parulekar, into that of Gao and Douglas because this modification can help visualize the resource and service configuration for Cloud-based Infrastructure as a Service (IaaS) and Container as a Service (CaaS) in order to design, manage and update the resources and services for the IaaS and CaaS.
As per Claim 12, neither Gao nor Douglas specifically teaches, however Parulekar teaches of the system of claim 2, wherein one or more of the resources has more than one version and wherein an identity card is generated for each version. (Par 75, FIG. 1 shows a diagram illustrating an example of systems and methods systems of the invention, the Cloud Security Engine (CSE), with different types and categories of computing devices including virtual devices. In one embodiment, as depicted in FIG. 1 different types of computing devices connect to the Cloud Security Engine (CSE) architecture 120. In the example of FIG. 1, different possible devices have been shown 110-1 through an nth client system 110-n, smartphones from 130-1 to 130-n, servers from 140-1, . . . 140-n. The computing devices with end-users is separated from the use of the computing devices in hosting applications, backend or server side in the Cloud Security Engine (CSE) architecture 120.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add one or more of the resources has more than one version and wherein an identity card is generated for each version, as conceptually seen from the teaching of Parulekar, into that of Gao and Douglas because this modification can help visualize the resource and service configuration for Cloud-based Infrastructure as a Service (IaaS) and Container as a Service (CaaS) in order to design, manage and update the resources and services for the IaaS and CaaS.
As per Claim 13, neither Gao nor Douglas specifically teaches, however Parulekar teaches of the system of claim 2, wherein the system is further configured for: receiving, from the user, a block of edited code; and (Par 21, The systems and methods of the CSE, wherein the Cloud Security Engine provides a user interface for designing, modeling, simulation, testing, staging and deploying. Par 57, Using a drag-and-drop graphical user interface, infrastructure, services and application designs may be selected and assembled. The CSE provides elements and components to build designs as secured elements and components which can ultimately be tested, staged, deployed and orchestrated.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add receiving, from the user, a block of edited code, as conceptually seen from the teaching of Parulekar, into that of Gao and Douglas because this modification can help visualize the resource and service configuration for Cloud-based Infrastructure as a Service (IaaS) and Container as a Service (CaaS) in order to design, manage and update the resources and services for the IaaS and CaaS. Neither Gao nor Parulekar specifically teaches, however Douglas teaches of updating, based on the received block of edited code, the design architecture and identity card parameters of one or more linked resources. (Par 30, Furthermore, after visually presenting the architectural flow diagram at 220 based on the GUI inputs, method 200 optionally may include returning to 210 to further modify the architectural flow diagram, e.g., by recognizing selection of a different set of architectural resources based on GUI inputs adding or deleting an architectural resource to/from the development canvas. Based on the visual feedback of the architectural flow diagram, a software developer may design an architectural flow diagram incrementally/iteratively, adding/removing nodes and relationships to obtain a desired design.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add updating, based on the received block of edited code, the design architecture and identity card parameters of one or more linked resources, as conceptually seen from the teaching of Douglas, into that of Gao and Parulekar because this modification can help visualize the resource and service configuration for Cloud-based Infrastructure as a Service (IaaS) and Container as a Service (CaaS) in order to design, manage and update the resources and services for the IaaS and CaaS.
Re Claim 14, it is the method claim, having similar limitations of claim 1. Thus, claim 14 is also rejected
under the similar rationale as cited in the rejection of claim 1.
The following claim limitation of the claim 14 is not recited in the claim 1, however Gao does not specifically teach, however Parulekar teaches of generating a user interface comprising a resource panel, a design panel (Figs. 5-7 and par 90-92, FIG. 5 with 500 shows an exploded view of asset/resource hierarchy and the different metadata that will be collected for contextualization to be done by the Cloud Security Engine (CSE) for policies and deployments. 510 shows the hierarchy of different cloud resources. FIG. 5 shows how context and risk is specified for the environment in which the component or module or architecture will be deployed.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add generating a user interface comprising a resource panel, a design panel, as conceptually seen from the teaching of Parulekar, into that of Gao because this modification can help visualize the resource and service configuration for Cloud-based Infrastructure as a Service (IaaS) and Container as a Service (CaaS) in order to design, manage and update the resources and services for the IaaS and CaaS.
Neither Gao nor Parulekar specifically teaches, however Douglas teaches of generating a user interface comprising … a code panel; (Fig. 3 and par 22, Visual devops application 22 is configured and/or programmed for visual design of the architectural resources for a software product via the GUI 30. GUI 30 includes a top bar including an application title (shown as “Visual Devops”), a title for the current project (shown as “Test Stack #1”), and other interface elements such as a “Save” and “Options” button. GUI 30 further includes a development canvas 32 to place and arrange nodes to design an application as an architectural flow diagram 50. Par 80. Settings for the Function node may include name, outputs, timeout, memory, and/or source code. The name setting is a label for the node in the canvas. The name setting also may be used to identify the location of the source code in a repository (such as a Git repository).)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add generating a user interface comprising … a code panel, as conceptually seen from the teaching of Douglas, into that of Gao and Parulekar because this modification can help visualize the resource and service configuration for Cloud-based Infrastructure as a Service (IaaS) and Container as a Service (CaaS) in order to design, manage and update the resources and services for the IaaS and CaaS.
Re Claim 15, it is the method claim, including similar limitations of claim 2. Thus, claim 15 is also rejected
under the similar rationale as cited in the rejection of claim 2.
Re Claim 16, it is the method claim, including similar limitations of claim 3. Thus, claim 16 is also rejected
under the similar rationale as cited in the rejection of claim 3.
Re Claim 17, it is the method claim, including similar limitations of claim 4. Thus, claim 17 is also rejected
under the similar rationale as cited in the rejection of claim 4.
Re Claim 19, it is the method claim, including similar limitations of claim 6. Thus, claim 19 is also rejected
under the similar rationale as cited in the rejection of claim 6.
Re Claim 22, it is the method claim, including similar limitations of claim 9. Thus, claim 22 is also rejected
under the similar rationale as cited in the rejection of claim 9.
Re Claim 24, it is the method claim, including similar limitations of claim 11. Thus, claim 24 is also rejected under the similar rationale as cited in the rejection of claim 11.
Re Claim 25, it is the method claim, including similar limitations of claim 12. Thus, claim 25 is also rejected under the similar rationale as cited in the rejection of claim 12.
Re Claim 26, it is the method claim, including similar limitations of claim 13. Thus, claim 26 is also rejected under the similar rationale as cited in the rejection of claim 13.
8. Claims 5 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Gao (US PGPub 20180302335), in view of Parulekar (US PGPub 20230059526), in view of Douglas (US PGPub 20180217818), and further in view of Huang (US PGPub 20210279160).
As per Claim 5, none of Gao, Parulekar and Douglas specifically teaches, however Huang teaches of the system of claim 2, wherein the user interface is a standalone application running on a client device. (Par 51, Depending on the embodiment, one or more of graphical user interfaces shown by FIGS. 4 through 6 are generated by one or more operations of the method 200 described with respect to FIG. 2. Additionally, one or more of the graphical user interfaces illustrated by FIGS. 4 through 6 can, for example, be presented on a client device (e.g., 102) via a standalone application (e.g., a runbook standalone application) or a web browser that is accessing a web page of an embodiment.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add the user interface is a browser-based application, as conceptually seen from the teaching of Huang, into that of Gao, Parulekar and Douglas because this modification can help design, manage and update the resource and service configuration for Cloud-based Infrastructure as a Service (IaaS) and Container as a Service (CaaS) by visualizing the resources and services for the IaaS and CaaS via GUI.
Re Claim 18, it is the method claim, including similar limitations of claim 5. Thus, claim 18 is also rejected
under the similar rationale as cited in the rejection of claim 5.
9. Claims 7-8 and 20-21 are rejected under 35 U.S.C. 103 as being unpatentable over Gao (US PGPub 20180302335), in view of Parulekar (US PGPub 20230059526), in view of Douglas (US PGPub 20180217818), and further in view of Mancuso (US Patent 12033050).
As per Claim 7, none of Gao, Parulekar and Douglas specifically teaches, however Mancuso teaches of the system of claim 6, wherein the trained machine learning model is a large language model. (Col 16, lines 45-51, In one or more embodiments, the digital electronic communication assistant system 106 utilizes a large language model as the communication generation neural network. In particular, the digital electronic communication assistant system 106 can utilize a large language model that analyzes input text (e.g., a prompt) to generate a response to the input text.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add the trained machine learning model is a large language model, as conceptually seen from the teaching of Mancuso, into that of Gao, Parulekar and Douglas because this modification can help visualize the resource and service configuration for Cloud-based Infrastructure as a Service (IaaS) and Container as a Service (CaaS) in order to design, manage and update the resources and services for the IaaS and CaaS.
As per Claim 8, none of Gao, Parulekar and Douglas specifically teaches, however Mancuso teaches of the system of claim 6, wherein the trained machine learning model is a neural network. (Col 7, lines 29-36, In one or more instances, the communication generation neural network includes a machine learning model trained and/or fine-tuned to generate electronic communications from a prompt (e.g., an electronic communication thread) utilizing various user data to mimic a composition style of a user account and to contextualize the generated electronic communication based on content related to the user account.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add the trained machine learning model is a neural network., as conceptually seen from the teaching of Mancuso, into that of Gao, Parulekar and Douglas because this modification can help visualize the resource and service configuration for Cloud-based Infrastructure as a Service (IaaS) and Container as a Service (CaaS) in order to design, manage and update the resources and services for the IaaS and CaaS.
Re Claim 20, it is the method claim, including similar limitations of claim 7. Thus, claim 20 is also rejected
under the similar rationale as cited in the rejection of claim 7.
Re Claim 21, it is the method claim, including similar limitations of claim 8. Thus, claim 21 is also rejected
under the similar rationale as cited in the rejection of claim 8.
10. Claims 10 and 23 are rejected under 35 U.S.C. 103 as being unpatentable over Gao (US PGPub 20180302335), in view of Parulekar (US PGPub 20230059526), in view of Douglas (US PGPub 20180217818), and further in view of Ferrick (US PGPub 20190222544).
As per Claim 10, none of Gao, Parulekar and Douglas specifically teaches, however Ferrick teaches of the system of claim 9, wherein automatically populating the one or more identity card parameters is further based at least in part on analysis by a second trained machine learning model, wherein the second trained machine learning model is trained on a dataset comprising one or more historic design architectures. (Par 10 and 18, Further, in some embodiments, the triggering event registry is updated programmatically using machine learning techniques, the updating process comprises accessing user interaction data related data from a database; parsing, using a user interaction data analysis and normalization module, the user interaction data to generate one or more identification data units; extracting one or more features from the one or more identification data units, wherein the features are representative of at least one of user interaction data, user profile associated with the user interaction, topics associated with the user interaction data, and frequency of user interaction; receiving a triggering event identification model, wherein the triggering event identification model was derived using a historical triggering event identification data set; and generating an output based on the triggering event identification model and the one or more features, wherein the output is configured to update the triggering event registry.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add automatically populating the one or more identity card parameters is further based at least in part on analysis by a second trained machine learning model, wherein the second trained machine learning model is trained on a dataset comprising one or more historic design architectures, as conceptually seen from the teaching of Ferrick, into that of Gao, Parulekar and Douglas because this modification can help visualize the resource and service configuration for Cloud-based Infrastructure as a Service (IaaS) and Container as a Service (CaaS) in order to design, manage and update the resources and services for the IaaS and CaaS.
Re Claim 23, it is the method claim, including similar limitations of claim 10. Thus, claim 23 is also rejected under the similar rationale as cited in the rejection of claim 10.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAE UK JEON whose telephone number is (571)270-3649. The examiner can normally be reached 9am-6pm. 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, Chat Do can be reached at 571-272-3721. 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.
/JAE U JEON/Primary Examiner, Art Unit 2193
Prosecution Insights