DETAILED ACTION
This action is in response to the application filed on 8/13/2024.
Claims 1-9 and 12-13 are pending in this application.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Objections
Claims 1-9 and 12-13 are objected to because of the following informalities:
Claim 1 :
at line 2 “configured to store” should be –storing--.
at line 7 “the processing purposes” lacks proper antecedent basis. Claims 12 and 13 have a similar issue.
at line 14 “ the selected environment construction tool” lacks proper antecedent basis. Claims 4, 5, 12, and 13 have a similar issue.
Claim 9 “the corresponding code character string” at lines 3-4 lacks proper antecedent basis.
Dependent claims 2-9 do not overcome the deficiency of the base claim and, therefore, are objected for the same reasons as the base claim.
Appropriate correction is required
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-9, and 12-13 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
The term “can be” in claim 1 is a relative term which renders the claim indefinite. The term “can be” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. The limitations has been interpreted as “that is described” for the purpose of compact prosecution. However, appropriate correction is required. Claims 4, 9, 12, and 13 have a similar issue.
Claims 2-3, and 5-8 do not overcome the deficiency of the base claim and, therefore, are rejected for the same reasons as the base claim.
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-9 and 12-13 are rejected under 35 U.S.C. 103 as being unpatentable over
Khakare et al. (US Patent Application Publication 2021/0055917 A1) in view of Zang et al. (US Patent Application Publication 2018/0143809 A1).
As to claim 1, Khakare teaches an environment construction support apparatus (see e.g. Figs.1 and 10 and associated text) comprising:
at least one storage device configured to store instructions (See e.g. Fig.10, 208 and associated text e.g. [0108]); and
at least one processor configured to execute the instructions (see e.g. Fig.10, 203 and associated text, e.g. [0105]) to:
receive selection of a notation related to a processing purpose in a predetermined environment construction tool (e.g. solution blueprint) in an information system (see e.g. Figs.2 and 3 and associated text, e.g. [0058]- blueprints may contain one or more environments that are connected or layered, and retain the dependencies between these environments. In this context, an environment is a single blueprint template, and a blueprint can contain multiple environments and [0072]- the user selects an item from the solution catalog. Users can select a pre-built blueprint or can build a custom blueprint; To begin designing an architecture, users need to determine which capabilities are required for this environment and [0073]- A cloud deploy software solution catalog lists the solution blueprints available for a particular software vendor. The cloud deploy software solution catalog includes all the pre-built solution blueprints, grouped according to the functionality they provide. An example of a pre-built solution blueprint is a solution blueprint for deploying a unified threat management (UTM) solution on a specific cloud provider (e.g., a Sophos UTM on AWS). Users can select solution blueprints from the solution catalog);
specify, for each of the processing purposes in the environment construction tool, a first set corresponding to the selected notation (e.g. selected resources) from first registration information (see e.g. Fig.5 and associated text [0086]- If the modify button next to the imported solution catalog item is clicked, the blueprints associated with that item are opened in a canvas for further configuration) in which a set of a code character string that can be described for execution by the environment construction tool (e.g. name of available resource that is selected) and an accompanying character string that can be described accompanying the code character string (e.g. name of another available related resource that is selected) is registered (see e.g. [0087]- the Droplet and Floating IP blueprint components represent the cloud resources that have been dragged and dropped from the resources section into the canvas),
generate a template code to be executed by the selected environment construction tool by using the code character string and the accompanying character string included in the specified first set (See e.g. Fig.8 and associated text, e.g. [0096]- Generate infrastructure as code. Cloud deploy software supports the option of deploying (e.g., executing scripts in the IaC files created for a blueprint against the cloud provider to create the infrastructure); IaC files are created on a server. In one embodiment, an action such as clicking a deploy button, will generate the IaC code and create the infrastructure defined in the blueprint in the cloud).
Khakare teaches the generated template code (se e.g. [0096]), does not specifically teach displaying the generated template code in a code display field of a screen.
In an analogous art of code development, however, Zang teaches displaying generated template code in a code display field of a screen (see Fig.2. and associated text, e.g. [0030]- Code database 211 may store templates that can be customized to generate code snippets and may also store the generated code snippets when directed by the developer. For example, code snippets that are generated from the stored templates may be displayed within generated snippet section 206).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified the system of Khakare to incorporate/implement the limitations as taught by Zang in order to provide a more efficient editor system that would enable users to generate code in a more timely manner.
As to claim 2, Khakare also teaches wherein the at least one processor is further configured to execute the instructions to receive selection of a version in the predetermined environment construction tool (e.g. type of functionality, see e.g. [0072]- The cloud deploy software solution catalog includes all the pre-built solution blueprints, grouped according to the functionality they provide and [0078]- To select a solution blueprint from the solution catalog, a user can check the relevant solution icon and click Import), specify a second set corresponding to the selected version in the predetermined environment construction tool from second registration information in which a set of the code character string and the accompanying character string supported by a specific version in the environment construction tool is registered (see e.g. [0083]- the user has the option to modify/configure the blueprint or deploy from the blueprint using default settings. In one typical use case for modifying a blueprint, a user configures the names, versions, size or other attributes of the cloud resources within the blueprint), and generate the template code by excluding the accompanying character string in the code character string included in the specified second set (See e.g. [0085]- The canvas also has additional capabilities to import or copy non-catalog blueprints to build custom solutions and [0096]- an action, such as clicking on an export button and entering a name for the generated file, will export infrastructure as code (e.g., IaC) for a blueprint. In one embodiment, one or more IaC files are created on the user computing device. In another embodiment, IaC files are created on a server. In one embodiment, an action such as clicking a deploy button, will generate the IaC code and create the infrastructure defined in the blueprint in the cloud).
As to claim 3, Khakare also teaches wherein the at least one processor is further configured to execute the instructions to generate the template code so as to satisfy a description rule in the predetermined environment construction tool (see e.g. [0095]- Common configuration choices include software versions, and resource settings such as sizes, names, etc. For example, the size of a virtual private cloud instance might be modified from medium to large (e.g., an AMI may be modified from a m4.medium to a m4.large) to support the expected load on the application. Once the blueprint configuration is complete and saved, it is ready for code generation and [0096]- Cloud deploy software supports the option of deploying (e.g., executing scripts in the IaC files created for a blueprint against the cloud provider to create the infrastructure) or exporting a blueprint. In one embodiment, an action, such as clicking on an export button and entering a name for the generated file, will export infrastructure as code (e.g., IaC) for a blueprint).
As to claim 4, Khakare also teaches wherein a set of the code character string and the accompanying character string that can be described to be executed by each environment construction tool is registered in the first registration information for each processing purpose in each of a plurality of environment construction tools (see e.g. [0074]- Cloud deploy software pre-built solution blueprints are designed based on a recommended architecture to deliver specific functionality. For example, a UTM pre-built solution blueprint could automatically create a high-availability architecture consisting of two servers configured as recommended by the cloud deploy software. All the infrastructure resources required to install this blueprint are already created within the pre-built blueprint) and
wherein the at least one processor is further configured to execute the instructions to receive one of the plurality of environment construction tools as selection of the predetermined environment construction tool (see e.g. [0072]- The user selects an item from the solution catalog. Users can select a pre-built blueprint or can build a custom blueprint),
specify a candidate for a processing purpose in the selected environment construction tool (see e.g. [0078]- To select a solution blueprint from the solution catalog, a user can check the relevant solution icon and click Import. The import process renders the resources within the blueprints on the canvas by pulling the template metadata from a cloud deploy software database, display the notation related to the specified candidate for the processing purpose in a processing purpose selection field of the screen (see e.g. [0080]- Some of the solution catalog items might consist of multiple cloud deploy software blueprints. The next step in the process is importing the solution blueprints to prepare them for deployment. This involves gathering all the underlying blueprint components (e.g., cloud provider resources and application packages) that comprise each selected blueprint, and receive selection of the notation from the processing purpose selection field (See e.g. [0087]- the Droplet and Floating IP blueprint components represent the cloud resources that have been dragged and dropped from the resources section into the canvas).
As to claim 5, Khakare also teaches wherein the at least one processor is further configured to execute the instructions to specify one or more code character strings corresponding to the selected environment construction tool from the first registration information as notation related to the candidate for the processing purpose (See e.g. [0084]- Users can select the modify button on the import icon to modify and configure blueprint components according to one embodiment. The modify button opens the blueprints associated with the solution catalog in a canvas for further configuration. The cloud deploy software canvas is the main area of the user interface where the components of the blueprints are displayed).
As to claim 6, Khakare also teaches wherein the at least one processor is further configured to execute the instructions to add and display the notation in a processing flow display field of the screen, when the environment construction support apparatus receives the selection of the notation (See Fig. 5 and associated text, e.g. [0087]- the Droplet and Floating IP blueprint components represent the cloud resources that have been dragged and dropped from the resources section into the canvas. These are graphical representations of cloud resources that will be installed on the cloud when the user deploys the solution, for example, by clicking on an icon).
As to claim 7, Zang further teaches wherein the at least one processor is further configured to execute the instructions to output a content displayed in the code display field to a request source in response to an output request (see e.g. Fig.2 and 4 and associated text, e.g. [0030]- code snippets that are generated from the stored templates may be displayed within generated snippet section 206. The code snippets may be executed and the runtime behavior may be displayed in preview view 202 and/or stored in code database 211, which may also store the relevant controller files for the application and [0033]- After the visual code editor generates a code snippet as discussed above with respect to FIG. 3, the visual code editor provides the developer with an option to preview the generated code snippet within the same GUI. In one embodiment, the visual code editor provides a button that is selectable by the developer that injects the generated code snippet from the snippet area of the visual code editor to a preview section of the visual code editor. The snippet area and the preview section are visible within the same GUI. In one embodiment, the snippet area and the preview section are adjacent. At step 400, the visual code editor receives a command from the developer to preview the runtime behavior of the generated code snippet. The visual code editor may then inject the generated code snippet into the preview section. At step 405, preview section simulates the runtime behavior of the generated code snippet).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified the system of Khakare to incorporate/implement the limitations as taught by Zang in order to provide a more efficient editor system that would enable users to generate code in a more timely manner.
As to claim 8, Zang further teaches wherein at least one processor is further configured to execute the instructions to display the template code in the code display field in an editable manner (See e.g. [0015]- Preview section 110 allows developer to immediately simulate execution of the generated code and made any adjustments to the code snippet) and [0030]- code snippets that are generated from the stored templates may be displayed within generated snippet section 206. The code snippets may be executed and the runtime behavior may be displayed in preview view 202).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified the system of Khakare to incorporate/implement the limitations as taught by Zang in order to provide a more efficient editor system that would enable users to generate code in a more timely manner.
As to claim 9, Khakare also teaches wherein the accompanying character string includes an option character string and a connection character string that can be designated by the corresponding code character string (See e.g. Fig.6 and associated text, e.g. [0088]- FIG. 6 shows the different elements that are a part of a blueprint according to one embodiment. Within the cloud deploy software canvas, there are three main categories of blueprint components: resources, packages and links (blueprint components are also referred to herein as code artifacts) and [0091]- links: Visual representations of dependencies between various resources in an environment. For example, a dependency may be a parent-child relationship where the child resource can only be installed if the parent resources exist).
As to claim 12, the limitations of the claims are substantially similar to the limitations of
claim 1, and therefore, it is rejected for the reasons stated above.
As to claim 13, the limitations of the claims are substantially similar to the limitations of
claim 1, and therefore, it is rejected for the reasons stated above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Mathon et al. (US Patent Application Publication 2020/0387357 A1) discloses implementing a system that uses machine generated infrastructure code for software development and infrastructure operations, allowing automated deployment and maintenance of a complete set of infrastructure components. Rizo et al. (US Patent Application Publication 2020/0012480 A1) discloses providing a cloud infrastructure visualizer and generator that may use an Infrastructure Diagramming Tool to create Infrastructure Design Diagrams (IDD) to allow System Engineers to design the Infrastructure to meet various application needs.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHENECA SMITH whose telephone number is (571)270-1651. The examiner can normally be reached Mon-Fri 8:00AM-4:30PM EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Hyung S Sough can be reached at 571-272-6799. 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.
/CHENECA SMITH/Examiner, Art Unit 2192
/S. Sough/SPE, Art Unit 2192
Prosecution Insights