DETAILED ACTION
This Action is a response to the filing received 2 November 2023. Claims 1-20 are presented for examination.
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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 2 November 2023 is being considered by the examiner.
Claim Objections
Claims 1, 3, 11 and 13 are objected to because of the following informalities:
At line 4 of claim 1, “execute the instructions” should be corrected to “execute the computer-executable instructions”; at line 12 of claim 1, “add the received software part” should be corrected to “add the received at least one software part”; and at lines 14-15 of claim 1, “include one or more indication” should be corrected to “includes one or more indications.” Similar language is present in claim 11.
At line 2 of claim 3, “indication” should be corrected to “indications;” similar language is present in claim 13.
Appropriate correction is required.
Claim Rejections - 35 USC § 101
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.
Claims 1-20 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to an abstract idea without significantly more.
As claims 1-10 recite machines and claims 11-20 recite processes, the claims pass Step 1 of the analysis (MPEP § 2106.03), and the eligibility determination proceeds to Step 2.
At Step 2A, Prong 1, the claims are evaluated for whether they are directed to (recite or set forth) a judicial exception; judicial exceptions include abstract ideas, including mental processes (MPEP §§ 2106.04, 2106.04(II)(A)(1) and 2106.04(a)). Mental processes include thinking that can be performed in the human mind with or without the aid of pen and paper and/or methods which can be performed mentally or which are the equivalent of human mental work, such as observations, evaluations, judgments and/or opinions (MPEP § 2106.04(a)(2)(III)).
Exemplary claim 1 recites the following mental process steps: (a) determine whether the received software part passes a quality check; (b) in response to determining the software part passes the quality check: adding the received part to a list; (c) performing a first validation of the list, wherein each of the software parts in the list include an indication of a type of quality check with the software parts in the list pass.
Element (a) represents an observation by a human user as to whether one or more software parts have passed a quality check. Of note, the claim does not actively recite performing the quality check, merely a determination as to whether any quality check has been passed for one or more software parts. Based on information, a human user can verify whether a software part has passed one or more quality checks.
Element (b) represents an evaluation or judgment by the human user that the software part should be included in a list, such as a list of validated software parts. Element (c) represents an evaluation or judgment by the human user that the list is validated (such as by a determination that all necessary software parts are in the list) and to include or note which quality check(s) each part has passed.
In view of the foregoing, claim 1 is directed to a mental process, and the evaluation proceeds to Step 2A, Prong 2. At this step, the claims are evaluated for whether they include additional limitations which integrate the abstract idea into a practical application (MPEP §§ 2106.04(II)(a)(2) and 2106.04(d)).
Claim 1 additionally recites (1) a system comprising memory storing computer instructions and a processor coupled thereto and configured to execute the instructions and (2) receiving software part(s) from a user, the part(s) being new version(s) of one or more parts in a list. Element (1) recites the statutory category of the invention, and further sets forth that the abstract idea is performed using a generic computer as a tool to perform the mental process and/or performed in a general-purpose computing environment; and element (2) recites the insignificant extra-solution activity of necessary pre-solution data gathering. Whether considered individually or in any combination, including with the above-identified mental process steps, these elements fail to integrate the abstract idea into a practical application.
The analysis thus proceeds to Step 2B, wherein the additional elements are further evaluated for whether they recite significantly more than the abstract idea (MPEP § 2106.05). The conclusions reached with respect to Step 2A, Prong 2 are incorporated; further, the additional elements are evaluated for whether they recite other than what is well-understood, routine and/or conventional in the field (MPEP § 2106.05(II)).
Element (1) recites that the abstract idea is performed using a generic computer as a tool to perform the mental process and/or performed in a general-purpose computing environment. This does not recite an improvement to the functioning of a computer or to any other technology (MPEP § 2106.05(a)), and recites well-understood, routine and/or conventional activities such as receiving or storing information (such as computer instructions) from memory, and performing repetitive calculations (executing computer instructions) (MPEP §2106.05(d)(II)). Element (2) recites receiving or transmitting data (the software parts and/or the list) over a network or storing and retrieving information (the software parts and/or the list) from memory (id.). Whether considered individually or in any combination, the additional elements do not recite significantly more than the abstract idea. Accordingly, claim 1 is ineligible under 35 U.S.C. § 101.
Claim 11 is ineligible for the same reasons provided with respect to claim 1 above, with the exception that the mental process is set forth as a method rather than a computer-implemented method.
Claims 2 and 12 set forth the type of quality check, which does not alter the finding that the determination that a software part has passed a quality check is an observation, evaluation and/or judgment that can be made by a human user.
Claims 3 and 13 set forth that the indication comprises a cryptographic signature resulting from the software part(s) being signed and which indicates an entity responsible for performing the quality check. This merely describes the information included in the list, which does not alter the findings made above.
Claims 4-5 and 14-15 describe performing the quality check on the received software part and a second validation of the part based on a quality check type by determining whether the result of the check satisfies a threshold comprising a quality gate defining an expected level of quality for the software part. These steps represent mere data gathering, such as performing tests to obtain input for an equation or testing a system for a response to determine a level of system function (MPEP § 2106.05(g)). That is, a quality check is performed, the type of check and means for performing the check recited at a high level of generality, merely to obtain a result used to determine whether the software part quality meets a threshold. The determination of whether the result of the check meets a threshold is an observation, evaluation, judgment and/or opinion a human user may make based on a known result and a known threshold. Accordingly, these additional limitations do not result in a finding that the abstract idea is integrated into a practical application or recite significantly more than the abstract idea.
Claims 6 and 16 recite transmitting the software part to a checking entity, receiving a result of performing the quality check from the checking entity, and determining whether the part passes the quality check based on a received result and a type of quality check performed by the checking entity. These steps represent receiving and transmitting data over a network; performing a test to obtain a result as input for an equation, and an additional observation, evaluation, judgment and/or opinion by a human user, consistent with the analysis provided above with respect to claims 4-5 and 14-15. Accordingly, these additional limitations do not result in a finding that the abstract idea is integrated into a practical application or recite significantly more than the abstract idea.
Claims 7 and 17 describe that the list is a software bill of materials, which does not alter the determinations made above with respect to claim 1.
Claims 8 and 18 recite that in response to determining a part fails a quality check, outputting a notification to a user including an indication of the failed check. This is an insignificant application (MPEP § 2106.05(g)) of the abstract idea, and/or mere output of the results of the abstract idea steps. Accordingly, these additional limitations do not result in a finding that the abstract idea is integrated into a practical application or recite significantly more than the abstract idea.
Claims 9 and 19 recite that in response to determining a part fails a quality check, determining whether the part has a dependent part that should receive a quality check based on the type of the failed check, and performing such a quality check. These additional elements recite an additional observation, evaluation, judgment and/or opinion by a human user (the first determining) and an insignificant application (the second determining). Accordingly, these additional limitations do not result in a finding that the abstract idea is integrated into a practical application or recite significantly more than the abstract idea.
Claims 10 and 20 recite validating the list by cryptographically signing the list, which is an insignificant application of the abstract idea. Accordingly, these additional limitations do not result in a finding that the abstract idea is integrated into a practical application or recite significantly more than the abstract idea.
In view of the foregoing, claims 2-20 are also ineligible under 35 U.S.C. § 101.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. § 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-20 are rejected under 35 U.S.C. § 102(a)(2) as being anticipated by Palanki et al., U.S. 2025/0086270 A1 (“Palanki”).
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 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 …”);
determine whether the received at least one software part passes a quality check (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 …”);
in response to determining that the received 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 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
performing 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 …”);
wherein each of the plurality of software parts specified in the list include one or more indication 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)).
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 indication comprises a cryptographic signature resulting from a respective one of the plurality of software parts specified in the list being cryptographically signed; and the cryptographic signature indicates an entity that is responsible for performing the 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); 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 instructions to: perform the quality check on the received at least one software part (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 …”); and
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; wherein the at least one processor is configured to execute the instructions to determine whether the received at least one software part passes the quality check by determining whether a result of performing the quality check on the received at least one software part satisfies a threshold (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 instructions to: transmit the received at least one software part to a checking entity; and receive a result of performing the quality check on the received at least one software part from the checking entity; wherein the at least one processor is configured to execute the instructions to determine whether the received at least one software part passes the quality check by determining whether the received result indicates that the checking entity has performed 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 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 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 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 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.
Conclusion
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
Prosecution Insights