DETAILED ACTION
This Action is a response to the reply filed 21 July 2026. Claims 1, 3-4, 6, 8-11, 13-14 and 16 are amended; no claims are canceled or newly added. Claims 1-20 remain pending for examination. In view of the amendments, the objections to the claims and the rejections under 35 U.S.C. § 101 are withdrawn.
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
In the event the determination of the status of the application as subject to AIA 35 U.S.C. §§ 102 and 103 (or as subject to pre-AIA 35 U.S.C. §§ 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. § 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. § 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Palanki et al., U.S. 2025/0086270 A1 (“Palanki”) in view of Cornilescu, Dan Iulian, U.S. 2017/0169370 A1 (“Cornilescu”).
Regarding claim 1, Palanki teaches: A system comprising: a memory storage storing computer-executable instructions; and at least one processor communicatively coupled to the memory storage (Palanki, e.g., ¶16, “computing environment 101 can include one or more computing devices that include a processor, a memory … can provide an environment for the LLM security service 103, a repository service 121, and other executable instructions”), wherein the at least one processor is configured to execute the computer-executable instructions to:
receive at least one software part from a user, wherein the received at least one software part is a new version of at least one of a plurality of software parts specified in a list (Palanki, e.g., ¶46, “When a new or modified LLM application 130 image is stored, for example, by branching or another repository action, the LLM security service 103 can automatically process the LLM application 130 image to attach the LLM-extended SBOM 142 using the LLM security libraries …” See also, e.g., ¶¶51-52, describing a user device checking out a clone or branch and then a commit. It is well known that a user (such as a developer) makes a commit request (i.e., receiving at least one software part, such as one or more files, from that user));
perform a quality check on [on at least the received software part] (Palanki, e.g., ¶52, “LLM security service 103 can perform a process that checks out a branch repository … generates an LLM signature for the commit or a snapshot of the cloned LLM application 130 … signature can indicate initial tests and/or previously existing tests associated with the cloned LLM application 130 … [or] indication or identification that the LLM application 130 itself is a verified version of the LLM application 130 that is to be tested further …” See also, e.g., ¶53, “LLM security service 103 can perform an automated programmatically performed LLM application test process …”);
based on determining that at least one software part passes the quality check (Palanki, e.g., ¶56, “Each of the LLM interaction tests can generate a test result such as a verification score or value … generate LLM attestations 145 for each of the automated or programmatically executed LLM interaction tests …”) add the received at least one software part to the list (Palanki, e.g., ¶59, “LLM security service 103 triggers the workflow actions 133 to perform code and composition analyses … used to add general application information to the LLM-extended SBOM 142 …”) and perform a first validation of the list (Palanki, e.g., ¶¶63-64, “completion of the various tests of the MLOps workflow can trigger a release candidate of the LLM application … perform a rules-based analysis that includes consideration of the verification statuses and other parameters of the LLM attestations and other aspects of the LLM-extended SBOM 142. If the rules-based analysis of the LLM-extended SBOM 142 indicates a threshold level production quality and safety value, then the LLM application 130 is provided to the production environment 456 as a production release candidate …”); …; and
based on the list, build a software (Palanski, e.g., ¶68, “If the rules-based analysis of the LLM-extended SBOM 142 indicates a threshold associated with a final release quality and safety value, then … the LLM application is provided to the production environment 256 as a release candidate for a final release and deployment …”), wherein each of the plurality of software parts specified in the list include one or more indications of a type of the quality check which a respective one of the plurality of software parts in the list passes (Palanki, e.g., FIG. 2, see the expanded version of LLM App Attestations 145, which include types of quality checks the referenced part(s) in the list passes (or fails)).
Palanki does not more particularly teach performing a quality check on each received software part, and performing a second validation of the received software part based on the type of the quality check which the received software part passes. However, Cornilescu does teach: [perform a quality check] on each of the received at least one software part (Cornilescu, e.g., ¶141, “Developers can submit candidate software changes to the CIS from development servers 140 by invoking a CIS submission application …” See also, e.g., ¶142, “For each candidate software change … CIS Agent informs the CIS Manager 111, which creates the changeset in the CIS Database 112 and passes it to the input port IN of the pre-commit verification stage 400 …” See also, e.g., ¶143, “Generally, the pre-commit verification stage 400 groups multiple non-overlapping changesets in bundles, performs a pre-commit quality verification process on these bundles and identifies any changesets causing blocking regressions.” See also, e.g., ¶145, “commit events 203 are triggered when bundles of committable changesets are produced at the output port COMMIT of the pre-commit verification stage 400. The CIS Manager 111 instructs the CIS Agent 120 to commit each and every individual changeset in the committable bundle to the software project’s integration branch …”) …
perform a second validation of the received at least one software part based on a type of the quality check which the received at least one software part passes (Cornilescu, e.g., ¶188, “A verification set can contain one or more verification steps to be executed in a certain sequence, some verification steps depending on the completion of one or more other verification steps in the sequence …” See also, e.g., ¶194, “A verification set configuration is used to completely describe … the sequence of quality verification steps of a verification set execution block and the dependency of one quality verification step execution on completion of other quality verification steps in the same sequence …”) for the purpose of providing a systematic and automated method for integrating diverse new software changesets with a plurality of validation stages through integration and deployment (Cornilescu, e.g., ¶¶41-48).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system and method for continuously validating extensions to software bundles as taught by Palanki to provide for performing a quality check on each received software part, and performing a second validation of the received software part based on the type of the quality check which the received software part passes because the disclosure of Cornilescu shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for the continuous development and integration of software changesets to provide for performing a quality check on each received software part, and performing a second validation of the received software part based on the type of the quality check which the received software part passes for the purpose of providing a systematic and automated method for integrating diverse new software changesets with a plurality of validation stages through integration and deployment (Cornilescu, Id.).
Claim 11 is rejected for the reasons given in the rejection of claim 1 above. Examiner notes that with respect to claim 11, Palanki further teaches: A method (Palanki, e.g., FIGS. 3 and 4, showing methods) comprising: [[[the operations performed by the system of claim 1]]].
Regarding claim 2, the rejection of claim 1 is incorporated, and Palanki further teaches: wherein the quality check comprises one or more of security check, safety check, performance check, and power consumption check (Palanki, e.g., ¶22, “list of LLM specific tests … that address security concerns … harmful content tests … malicious prompt injection tests …” Examiner’s note: these tests address safety and security concerns, and at least LLM hallucination test at ¶26 can be interpreted as a performance check).
Regarding claim 3, the rejection of claim 1 is incorporated, and Palanki further teaches: wherein: the one or more indications comprise (Palanki, e.g., FIG. 2, see the expanded version of LLM App Attestations 145, which include types of quality checks the referenced part(s) in the list passes (or fails); see also, e.g., ¶36, “LLM specific parameters … LLM bill of materials … LLM parameters can be specified in an LLM attestations 145 that is signed using a cryptographic process that uniquely identifies a particular signer, which can indicate a trusted party … indicate types of tests that have been performed …”).
Regarding claim 4, the rejection of claim 1 is incorporated, and Palanki further teaches: wherein the at least one processor is further configured to execute the computer-executable instructions to: (Palanki, e.g., ¶¶63-64, “completion of the various tests of the MLOps workflow can trigger a release candidate of the LLM application … perform a rules-based analysis that includes consideration of the verification statuses and other parameters of the LLM attestations and other aspects of the LLM-extended SBOM 142. If the rules-based analysis of the LLM-extended SBOM 142 indicates a threshold level production quality and safety value, then the LLM application 130 is provided to the production environment 456 as a production release candidate …” See also, e.g., ¶66, “LLM security service 103 can use the production environment 456 and other components to release the … LLM application 130 for infrastructure provisioning and validation. This can include performing a rules-based analysis of the LLM attestations …” and ¶68, “If the rules based analysis of the LLM-extended SBOM 142 indicates a threshold associated with a final release quality and safety value, then a specified one or more action can be performed … LLM application is provided to the production environment 456 as a release candidate for a final release and deployment …”).
Regarding claim 5, the rejection of claim 4 is incorporated, and Palanki further teaches: wherein: the threshold comprises a quality gate; and the quality gate defines a level of quality which the received at least one software part should meet (Palanki, e.g., ¶¶63-64, “completion of the various tests of the MLOps workflow can trigger a release candidate of the LLM application … perform a rules-based analysis that includes consideration of the verification statuses and other parameters of the LLM attestations and other aspects of the LLM-extended SBOM 142. If the rules-based analysis of the LLM-extended SBOM 142 indicates a threshold level production quality and safety value, then the LLM application 130 is provided to the production environment 456 as a production release candidate …”).
Regarding claim 6, the rejection of claim 1 is incorporated, and Palanki further teaches: wherein the at least one processor is further configured to execute the computer-executable instructions to: transmit the received at least one software part to a checking entity; and the second validation of the received at least one software part based on a type of the quality check which the received at least one software part passes from the checking entity (Palanki, e.g., ¶64, “If the rules-based analysis of the LLM-extended SBOM 142 indicates a threshold level production quality and safety value, then the LLM application 130 is provided to the production environment 456 as a production release candidate … transmit a security champion notification to the security developer environment … include the LLM application 130 and LLM-extended SBOM …” See also, e.g., ¶65, “security developer environment 453 can perform a manual test of the LLM application … can result in a score or other verification status … results are passed back to a component of the LLM security service 103 such as the production environment 456, and the LLM security service 103 attaches LLM attestation 145 that indicates the verification status …”).
Regarding claim 7, the rejection of claim 1 is incorporated, and Palanki further teaches: wherein the list comprises a Software Bill of Material (SBOM) (Palanki, e.g., ¶12, “extending a software bill of materials (SBOM), to include LLM specific provenance parameters that enable signed attestations …”).
Regarding claim 8, the rejection of claim 1 is incorporated, and Palanki further teaches: wherein the at least one processor is further configured to execute the computer-executable instructions to, in response to determining that the received at least one software part fails the quality check, provide a failure notification to the user; and wherein the failure notification indicates a type of the quality check which the received at least one software part fails (Palanki, e.g., ¶69, “If the rule-based analysis of the LLM-extended SBOM 142 indicates a threshold that is incommensurate with the final release quality and safety value … LLM application 130 can be transmitted … along with a specification of which LLM test was failed, and a particular aspect of the test that was failed. A notification can be transmitted to a client device 1065 or user interface of a developer … a textual description that specifies why the LLM application 130 failed the test …”).
Regarding claim 9, the rejection of claim 1 is incorporated, and Palanki further teaches: wherein the at least one processor is further configured to execute the computer-executable instructions to: in response to determining that the received at least one software part fails the quality check (Palanki, e.g., ¶69, “If the rule-based analysis of the LLM-extended SBOM 142 indicates a threshold that is incommensurate with the final release quality and safety value … LLM application 130 can be transmitted … along with a specification of which LLM test was failed, and a particular aspect of the test that was failed. A notification can be transmitted to a client device 1065 or user interface of a developer … a textual description that specifies why the LLM application 130 failed the test …”), determine whether the received at least one software part has at least one dependent software part that should receive the quality check based on a type of the quality check which the received at least one software part fails, wherein the at least one dependent software part is at least one software part in the plurality of software parts that depends from the received at least one software part; and in response to determining that the received at least one software part has at least one dependent software part that should receive the quality check, perform the quality check on the at least one dependent software part (Palanki, e.g., ¶61, “software composition analysis can analyze the dependencies, libraries, frameworks, and other external code resources of the LLM application 130 to assess their LLM specific security vulnerabilities …”).
Regarding claim 10, the rejection of claim 1 is incorporated, and Palanki further teaches: wherein the at least one processor is configured to execute the computer-executable instructions to perform the first validation of the list by cryptographically signing the list (Palanki, e.g., FIG. 2, see the expanded version of LLM App Attestations 145, which include types of quality checks the referenced part(s) in the list passes (or fails); see also, e.g., ¶36, “LLM specific parameters … LLM bill of materials … LLM parameters can be specified in an LLM attestations 145 that is signed using a cryptographic process that uniquely identifies a particular signer, which can indicate a trusted party … indicate types of tests that have been performed …”).
Claims 12-20 are rejected for the additional reasons given in the rejections of claims 2-10 above.
Response to Arguments
In the Remarks, Applicant Argues: At least the amendments to independent claims 1 and 11 render the claims eligible under 35 U.S.C. § 101 and distinguishable over Palanki. The claims are accordingly in condition for allowance.
Examiner’s Response: In view of the amendments, Examiner has withdrawn the rejections under 35 U.S.C. § 101, but newly cites to Cornilescu, and maintains the rejections under the new grounds set forth in full above.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Examiner has identified particular references contained in the prior art of record within the body of this action for the convenience of Applicant. Although the citations made are representative of the teachings in the art and are applied to the specific limitations within the enumerated claims, the teaching of the cited art as a whole is not limited to the cited passages. Other passages and figures may apply. Applicant, in preparing the response, should consider fully the entire reference as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art and/or disclosed by Examiner.
Examiner respectfully requests that, in response to this Office Action, support be shown for language added to any original claims on amendment and any new claims. That is, indicate support for newly added claim language by specifically pointing to page(s) and line number(s) in the specification and/or drawing figure(s). This will assist Examiner in prosecuting the application.
When responding to this Office Action, Applicant is advised to clearly point out the patentable novelty which he or she thinks the claims present, in view of the state of the art disclosed by the references cited or the objections made. He or she must also show how the amendments avoid such references or objections. See 37 C.F.R. 1.111(c).
Examiner interviews are available via telephone and video conferencing using a USPTO-supplied web-based collaboration tool. Applicant is encouraged to submit an Automated Interview Request (AIR) which may be done via https://www.uspto.gov/patent/uspto-automated-interview-request-air-form, or may contact Examiner directly via the methods below.
Any inquiry concerning this communication or earlier communication from Examiner should be directed to Andrew M. Lyons, whose telephone number is (571) 270-3529, and whose fax number is (571) 270-4529. The examiner can normally be reached Monday to Friday from 10:00 AM to 6:00 PM ET. If attempts to reach Examiner by telephone are unsuccessful, Examiner’s supervisor, Wei Mui, can be reached at (571) 272-3708. Information regarding the status of an application may be obtained from the Patent Center system. For more information about the Patent Center system, see https://www.uspto.gov/patents/apply/patent-center. If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call (800) 786-9199 (in USA or Canada) or (571) 272-1000.
/Andrew M. Lyons/Primary Examiner, Art Unit 2191
