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 .
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.
Claim(s) 1, 6, 10-12, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over JIA et al. (C.N. Pub. No. CN 118051583 A) in view of SHULZ et al. (U.S. Pub. No. US 20250328524 A1).
Regarding claim 1, JIA teaches the invention substantially as claimed, including:
A computer-implemented method for deploying a system, comprising:
generating a term in a configuration file using a prompt to a language model, constrained by an initial template that identifies fixed and variable parts according to a schema; ((Jia page 8, paragraphs 12-13)Furthermore, in creating the third Prompt structure, a ECharts visualization template may be created first, namely: a structural template of an option object is prepared forspecific configuration information of each visual option. Wherein ECharts is an open source JavaScript data visualization library. The method has rich visual effect andflexible configuration options, and can help users to easily create interactive charts and data visual interfaces. The option parameter object refers to the configurationitem object in ECharts. This object contains configuration information for the chart, including chart type, title, coordinate axis, data series, label style, visual mapping, andinteraction behavior, etc. By setting the configuration information, the customization and control of the aspects of the style, the layout, the interaction behavior and thelike of the chart can be realized. In practical application, the appearance and behavior of the data visualization chart can be controlled by setting each attribute value ofthe option parameter object. For example, data to be displayed, control colors, setting coordinate axis labels, adding legends, and the like can be specified by settingattributes of the option parameter object.And integrating the query result data, the user input information and the option template sample into a template structure, namely a third template structure, andrequiring the large language model to generate an option parameter object based on the template structure. This third Prompt structure is essentially the specifiedECharts configuration requirements.)
dynamically updating the template in accordance with an output of the language model; ((Jia page 8, paragraphs 12-13)Furthermore, in creating the third Prompt structure, a ECharts visualization template may be created first, namely: a structural template of an option object is prepared forspecific configuration information of each visual option. Wherein ECharts is an open source JavaScript data visualization library. The method has rich visual effect andflexible configuration options, and can help users to easily create interactive charts and data visual interfaces. The option parameter object refers to the configurationitem object in ECharts. This object contains configuration information for the chart, including chart type, title, coordinate axis, data series, label style, visual mapping, andinteraction behavior, etc. By setting the configuration information, the customization and control of the aspects of the style, the layout, the interaction behavior and thelike of the chart can be realized. In practical application, the appearance and behavior of the data visualization chart can be controlled by setting each attribute value ofthe option parameter object. For example, data to be displayed, control colors, setting coordinate axis labels, adding legends, and the like can be specified by settingattributes of the option parameter object.And integrating the query result data, the user input information and the option template sample into a template structure, namely a third template structure, andrequiring the large language model to generate an option parameter object based on the template structure. This third Prompt structure is essentially the specifiedECharts configuration requirements. (the option template sample is injected into the template structure to update the template.)))
While JIA does teach generating a configuration file term and updating a template after the generation, it does not explicitly teach:
generating a next term in the configuration file based on the prompt, constrained by the updated template; and iteratively generating next terms and updating the template until a halt condition has been reached to complete the configuration file.
However, in analogous art that similarly handles templates applied to network tasks using a LLM, SCHULZ teaches:
generating a next term in the configuration file based on the prompt, constrained by the updated template; ([0017] In another aspect, there is provided a computer program product that includes a non-transitory computer readable medium. The non-transitory computer readable medium may store instructions that cause operations when executed by at least one processor. The operations may include: exporting a domain model for processing by a large language model, the domain model being structured into tasks according to a defined schema, wherein exporting the domain model comprises generating a text file comprising code that represents structured data; receiving, by the large language model, a prompt and a context window associated with a task of the domain model; modifying, using the large language model, a task template associated with the task; enriching the modified task template with data from a backend system; performing content validation on content of the modified task template enriched with the data from the backend system; performing schema validation for validating the modified task template enriched with the data from the backend system against the defined schema; in response to performing the content validation and the schema validation, correcting invalid tasks, wherein the correcting is repeated and performed recursively until the modified task template enriched with the data from the backend system is validated; and applying changes to the domain model. (A domain model task can be generating a term in a configuration file. When modified by JIA, one of reasonable skill in the art could use the method of SCHULZ in combination with JIA’s configuration file parameter generation to generate a configuration file parameter based on the prompt constrained by an updated template.)) and iteratively generating next terms and updating the template until a halt condition has been reached to complete the configuration file. (([0017] In another aspect, there is provided a computer program product that includes a non-transitory computer readable medium. The non-transitory computer readable medium may store instructions that cause operations when executed by at least one processor. The operations may include: exporting a domain model for processing by a large language model, the domain model being structured into tasks according to a defined schema, wherein exporting the domain model comprises generating a text file comprising code that represents structured data; receiving, by the large language model, a prompt and a context window associated with a task of the domain model; modifying, using the large language model, a task template associated with the task; enriching the modified task template with data from a backend system; performing content validation on content of the modified task template enriched with the data from the backend system; performing schema validation for validating the modified task template enriched with the data from the backend system against the defined schema; in response to performing the content validation and the schema validation, correcting invalid tasks, wherein the correcting is repeated and performed recursively until the modified task template enriched with the data from the backend system is validated; and applying changes to the domain model. (SCHULZ goes through each task, both iterating through all task and iterating the same task over again until the task is validated, making SCHULZ’s method iterative)))
It would have been obvious to a person skilled in the art before the effective filing date of the invention to have combined with SCHULZ’s teaching of further generating output with the LLM prompt and updating a template iteratively and, with JIA’s teaching of generating configuration file terms and updating a template, to realize, with a reasonable expectation of success, a method that creates a configuration file term and updates the template, as in JIA, where the next term is then generated and the template updated iteratively, as in SCHULZ. A person of ordinary skill would have been motivated to make this combination to be prepared to better improve automation (SCHULZ [0002]).
Regarding claim 6, JIA further teaches:
The method of claim 1, wherein the initial template includes a constraint selected from the group consisting of generation from a given set of options, generation of a value that follows a particular pattern, data format constraints, and grammar rules. ((JIA page 7, paragraph 8) In the solution of this embodiment, the prompt template in this step includes a reserved position for inserting key information points, including user input information, data resource object information (i.e., the service ID of the data resource object with query authority of the user), time information and return format requirements.)
Regarding claim 10, JIA further teaches:
The method of claim 1, wherein the language model is a large language model that is pretrained on code generation samples. ((JIA page 7, paragraph 11) The large language model refers to a large scale neural network model trained by deep learning technology, which is used for processing natural language text. For example, ChatGPT-4.)
Regarding claims 11-12, they comprise of limitations similar to those of claim 1 and are therefore rejected for similar rationale. Regarding claim 17, it comprises of limitations similar to those of claim 6 and is therefore rejected for similar rationale.
Claim(s) 2, 5, 8-9, 13, 16, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over JIA et al. (C.N. Pub. No. CN 118051583 A), SHULZ et al. (U.S. Pub. No. US 20250328524 A1) in further view of FRESE et al. (U.S. Pub. No. US 20240394151 A1).
Regarding claim 2, while JIA as modified by SCHULZ does teach claim 1, which claim 2 is dependent upon, it does not explicitly teach:
The method of claim 1, wherein dynamically updating the template is performed responsive to a last term by adding a predetermined new template to the initial template.
However, in analogous art that similarly handles templates for configurations, FRESE teaches:
The method of claim 1, wherein dynamically updating the template is performed responsive to a last term by adding a predetermined new template to the initial template. ([0269] The method of FIG. 4 further includes comparing (404) the enumeration to a codified state of the cloud-based storage system (318). The codified state of the cloud-based storage system (318) comprises a codified indication of resources that should be allocated and configured for use in the cloud-based storage system (318). The codified state may comprise an Infrastructure as Code (IaC) configuration template, such as a CloudFormation Template. For example, the cloud computing environment (316) may be configured to allocate, provision, and configure resources according to a submitted configuration template. Resources may be added, removed, updated, or otherwise provisioned by submitting new configuration templates reflecting the desired change. Such a configuration template would indicate a full inventory of resources to be provisioned for the cloud-based storage system (318), including those resources unaffected by the change. For example, assume a cloud-based storage system (318) with provisioned resources A, B, and C, and that a resource D is to be added. The configuration template would indicate resources A, B, C, and D. The cloud computing environment (316) would then identify a difference between the submitted configuration template and currently provisioned resources (e.g., the inclusion of resource D), and provision the resource D. Similarly, if resource B were to be removed, a configuration template indicating resources A, C, and D would be submitted. The cloud computing environment (316) would then identify a difference between the submitted configuration template and currently provisioned resources (e.g., the exclusion of resource B), and remove the resource B. Accordingly, the codified state may comprise a configuration template last submitted to the cloud computing environment (316).)
It would have been obvious to a person skilled in the art before the effective filing date of the invention to have combined with FRESE’s teaching updating the template with a predetermined new template and, with JIA’s, as modified by SCHULZ, teaching of generating configuration file terms and updating a template, to realize, with a reasonable expectation of success, a method that creates a configuration file term and updates the template, as in JIA, as modified by SCHULZ, where the updating includes using a predetermined new template for the update, as in FRESE. A person of ordinary skill would have been motivated to make this combination to be prepared to better improve performance (FRESE [0346]).
Regarding claim 5, FRESE further teaches:
The method of claim 1, wherein dynamically updating the template identifies that a previous term is a key for a nested schema and adds a nested template to the template. ([0102] A series of address-space transformations takes place across an entire storage system. At the top are the directory entries (file names) which link to an inode. Inodes point into medium address space, where data is logically stored. Medium addresses may be mapped through a series of indirect mediums to spread the load of large files, or implement data services like deduplication or snapshots. Segment addresses are then translated into physical flash locations. Physical flash locations have an address range bounded by the amount of flash in the system in accordance with some embodiments. Medium addresses and segment addresses are logical containers, and in some embodiments use a 128 bit or larger identifier so as to be practically infinite, with a likelihood of reuse calculated as longer than the expected life of the system. Addresses from logical containers are allocated in a hierarchical fashion in some embodiments. Initially, each non-volatile solid state storage 152 unit may be assigned a range of address space. Within this assigned range, the non-volatile solid state storage 152 is able to allocate addresses without synchronization with other non-volatile solid state storage 152.)
Regarding claim 8, FRESE further teaches:
The method of claim 1, further comprising specifying the initial template and a template update for dynamically updating the template prior to generating the term. (([0269] The method of FIG. 4 further includes comparing (404) the enumeration to a codified state of the cloud-based storage system (318). The codified state of the cloud-based storage system (318) comprises a codified indication of resources that should be allocated and configured for use in the cloud-based storage system (318). The codified state may comprise an Infrastructure as Code (IaC) configuration template, such as a CloudFormation Template. For example, the cloud computing environment (316) may be configured to allocate, provision, and configure resources according to a submitted configuration template. Resources may be added, removed, updated, or otherwise provisioned by submitting new configuration templates reflecting the desired change. Such a configuration template would indicate a full inventory of resources to be provisioned for the cloud-based storage system (318), including those resources unaffected by the change. For example, assume a cloud-based storage system (318) with provisioned resources A, B, and C, and that a resource D is to be added. The configuration template would indicate resources A, B, C, and D. The cloud computing environment (316) would then identify a difference between the submitted configuration template and currently provisioned resources (e.g., the inclusion of resource D), and provision the resource D. Similarly, if resource B were to be removed, a configuration template indicating resources A, C, and D would be submitted. The cloud computing environment (316) would then identify a difference between the submitted configuration template and currently provisioned resources (e.g., the exclusion of resource B), and remove the resource B. Accordingly, the codified state may comprise a configuration template last submitted to the cloud computing environment (316).))
Regarding claim 9, FRESE further teaches:
The method of claim 8, wherein specifying the template update includes determining conditions from the schema that are triggered by particular terms. (([0269] The method of FIG. 4 further includes comparing (404) the enumeration to a codified state of the cloud-based storage system (318). The codified state of the cloud-based storage system (318) comprises a codified indication of resources that should be allocated and configured for use in the cloud-based storage system (318). The codified state may comprise an Infrastructure as Code (IaC) configuration template, such as a CloudFormation Template. For example, the cloud computing environment (316) may be configured to allocate, provision, and configure resources according to a submitted configuration template. Resources may be added, removed, updated, or otherwise provisioned by submitting new configuration templates reflecting the desired change. Such a configuration template would indicate a full inventory of resources to be provisioned for the cloud-based storage system (318), including those resources unaffected by the change. For example, assume a cloud-based storage system (318) with provisioned resources A, B, and C, and that a resource D is to be added. The configuration template would indicate resources A, B, C, and D. The cloud computing environment (316) would then identify a difference between the submitted configuration template and currently provisioned resources (e.g., the inclusion of resource D), and provision the resource D. Similarly, if resource B were to be removed, a configuration template indicating resources A, C, and D would be submitted. The cloud computing environment (316) would then identify a difference between the submitted configuration template and currently provisioned resources (e.g., the exclusion of resource B), and remove the resource B. Accordingly, the codified state may comprise a configuration template last submitted to the cloud computing environment (316).))
Regarding claim 13, it comprises of limitations similar to those of claim 2 and is therefore rejected for similar rationale. Regarding claim 16, it comprises of limitations similar to those of claim 5 and is therefore rejected for similar rationale. Regarding claims 19-20, they comprise of limitations similar to those of claims 8-9 and are therefore rejected for similar rationale.
Claim(s) 3 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over JIA et al. (C.N. Pub. No. CN 118051583 A), SHULZ et al. (U.S. Pub. No. US 20250328524 A1) in further view of KOGIAS et al. (U.S. Pub. No. US 9811394 B1).
Regarding claim 3, while JIA, as modified by SCHULZ does teach claim 1, which claim 3 is dependent upon, it does not explicitly teach:
The method of claim 1, wherein the schema is derived from documentation for a software module being configured by the configuration file.
However, in analogous art that similarly uses schema, KOGIAS teaches:
The method of claim 1, wherein the schema is derived from documentation for a software module being configured by the configuration file. ((Col. 19, lines 55-58) The static definition may be included in the schema. Further, using the static schema obtained from the documentation, the schema may be augmented with dynamic introspection.)
It would have been obvious to a person skilled in the art before the effective filing date of the invention to have combined with KOGIAS’ teaching of getting the schema from documentation and, with JIA’s, as modified by SCHULZ, teaching of generating configuration file terms and updating a template, to realize, with a reasonable expectation of success, a method that creates a configuration file term and updates the template, as in JIA, as modified by SCHULZ, where according to a schema found in documentation, as in KOGIAS. A person of ordinary skill would have been motivated to make this combination to be prepared to better improve costs and performance (KOGIAS col 1, lines 45-56).
Regarding claim 14, it comprises of limitations similar to those of claim 3 and is therefore rejected for similar rationale.
Claim(s) 4 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over JIA et al. (C.N. Pub. No. CN 118051583 A), SHULZ et al. (U.S. Pub. No. US 20250328524 A1) in further view of BREINING et al. (U.S. Pub. No. US 20030212664 A1) in further view of LI (U.S. Pub. No. US 10817490 B2).
Regarding claim 4, while jia, as modified by SCHULZ, does teach claim 1, which claim 4 is dependent upon, it does not explicitly teach:
The method of claim 1, wherein the schema includes a set of required keys
However, in analogous art that similarly handles schema, BREINING teaches:
The method of claim 1, wherein the schema includes a set of required keys ([0036] A structure of an XML document is logically similar to a relational schema where the nested and the repeating elements are modeled as separate tables with foreign keys.)
It would have been obvious to a person skilled in the art before the effective filing date of the invention to have combined with BREINING’s teaching a schema that has a set of keys and, with JIA’s, as modified by SCHULZ, teaching of generating configuration file terms and updating a template, to realize, with a reasonable expectation of success, a method that creates a configuration file term and updates the template, as in JIA, as modified by SCHULZ, where the schema used to constrict the configuration template has a set of keys, as in BREINING. A person of ordinary skill would have been motivated to make this combination to be prepared to better improve data management (BREINING [0007]).
While JIA, as modified by SCHULZ and BREINING, does teach a schema that has a set of keys, it does not explicitly teach:
and wherein the template expresses the required keys in a syntax that is interpreted by a grammar parser.
However, in analogous art that similarly handles schema, LI teaches:
and wherein the template expresses the required keys in a syntax that is interpreted by a grammar parser. ((col 3, 55-61) Existing parsers for schema-free data exchange formats, such as Jackson and Gson are mature and have been optimized and tuned for many years. These parsers are based on finite state machines (FSM) which is the textbook approach to build parsers. In contrast, embodiments of the present subject matter include a parser that may be based on speculation and data parallel algorithms. (col 5, line 61 – col 6, line 6) The characters used in the dataset may be changed in different datasets. For instance, the colon character used with the key/value pair may be a different character in further embodiments. However, for convenience, the description of examples and algorithms refer to a JSON dataset and use a colon character for convenience. The term “colon” and “:” shall be interpreted as any character with a similar function in various datasets expressed with different grammar than JSON.s. The same convention may also be used for all the other characters used in the JSON grammar, including but not limited to quotes, left bracket, right bracket, escape characters, right and left braces, commas, etc.
(col 6, lines 7-20) The JSON grammar standard ECMA-404 specifies no behavior on duplicate keys. However, the use of JSON in applications is often more restrictive. The standard RFC-7159 defines the JSON Data Interchange Format and declares that “the names within an object SHOULD be unique”, in the sense that software implementations often use a hash map to represent a JSON object and therefore have unpredictable behavior when receiving an object with duplicate keys. As per RFC-7159, most existing JSON parsers, e.g. Jackson and Gson, either do not accept duplicate keys or take only one of the duplicated keys. In the following, we assume that all keys are unique within an object.)
It would have been obvious to a person skilled in the art before the effective filing date of the invention to have combined with LI’s teaching that parses a schema’s keys with a grammar parser and, with JIA’s, as modified by SCHULZ and BREINING, teaching of generating configuration file terms and updating a template using a schema with keys, to realize, with a reasonable expectation of success, a method that creates a configuration file term and updates the template using a schema with keys, as in JIA, as modified by SCHULZ and BREINING, where the schema keys are parsed by a grammar parser, as in LI. A person of ordinary skill would have been motivated to make this combination to be prepared to better improve costs (LI Background).
Regarding claim 15, it comprises of limitations similar to those of claim 4 and is therefore rejected for similar rationale.
Claim(s) 7 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over JIA et al. (C.N. Pub. No. CN 118051583 A), SHULZ et al. (U.S. Pub. No. US 20250328524 A1) in further view of BUENECHEA et al. (U.S. Pub. No. US 9813449 B1).
Regarding claim 7, while jia, as modified by SCHULZ, does teach claim 1, which claim 4 is dependent upon, it does not explicitly teach:
The method of claim 1, further comprising executing the configuration file to configure a software module in a distributed computing system, wherein the prompt specifies the software module.
However, in analogous art that similarly handles schema, BUENECHEA teaches:
The method of claim 1, further comprising executing the configuration file to configure a software module in a distributed computing system, wherein the prompt specifies the software module. ((col 10, 45-54) Subsequently, at 412, the authentication module 112 retrieves the command comprising the configuration information from the database 118 and transmits the command (i.e., configuration file) to the specified module (i.e., probes module 136), at 415. Upon receipt of the command, in one embodiment, the specified module (i.e., probes module 136) processes the command and loads the proper configuration. As discussed previously, in one embodiment, the agent 310 of the module receives and processes the configuration file 315.)
It would have been obvious to a person skilled in the art before the effective filing date of the invention to have combined with BUENECHEA’s teaching of executing the configuration file to configure the module and, with JIA’s, as modified by SCHULZ, teaching of generating configuration file terms and updating a template, to realize, with a reasonable expectation of success, a method that creates a configuration file term and updates the template, as in JIA, as modified by SCHULZ, where file generated is executed to configure a module, as in BUENECHEA. A person of ordinary skill would have been motivated to make this combination to be prepared to better improve automation (BUENECHEA Background).
Regarding claim 18, it comprises of limitations similar to those of claim 7 and is therefore rejected for similar rationale.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SKIELER A KOWALIK whose telephone number is (571)272-1850. The examiner can normally be reached 8-5.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Mariela D Reyes can be reached at (571)270-1006. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/SKIELER ALEXANDER KOWALIK/Examiner, Art Unit 2142
/HAIMEI JIANG/Primary Examiner, Art Unit 2142
Prosecution Insights