DETAILED ACTION
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 .
This office action is in response to applicant’s amendment filed on 06/08/2026.
Claims 1-6, 11-16 are pending and examined.
Response to Arguments
Applicant’s arguments filed on 06/08/2026 have been fully considered.
Per 101 abstract idea rejection, applicant’s arguments are not persuasive. Applicant argued about the limitations of “processing the result data for each software part to extract metrics, wherein the result data is in a format which is not readily evaluated as the metrics”. Specifically, applicant stated “this limitation specifies that the result data produced by the quality assurance test is in a machine-generated format that cannot be directly used as metrics and must be parsed into a usable form. This is a data transformation operation performed on raw test output, not a mental evaluation of readily available numbers”. The examiner respectfully disagrees. The claim does not state the result data is in a non-human readable format. Thus, a human can receive and process the result data to extract useful metrics for comparison. Therefore, this step is considered as a mental step that can be performed in human mind.
Applicant then argued “this limitation recites a specific request-and-response mechanism for obtaining a machine-readable configuration file, rather than the passive "receiving" of data that the Office Action characterized as mere data gathering”. The examiner respectfully disagrees. The above two steps are merely for data requesting and data receiving, which are insignificant additional elements and extra-solution activities. These steps are well known in the state of the art, see the 103 rejection below.
Applicant then argued “this limitation specifies that the output is directed to a particular user interface that provides a structured overview of the build and the build status of each software part across the plurality, rather than a generic display of comparison results”. The examiner respectfully disagrees. The above step can be performed by a person manually on a piece of paper, i.e. a person can compare the test results and produce a comparison report. Thus, this step is considered as a mental step. Also, outputting a report to a user interface is considered as an insignificant additional element.
Applicant then argued “The claimed method is directed to this specific technical problem and provides a specific technical solution - enforcing a uniform quality gate configuration across every software part sharing a software part type”. The examiner respectfully disagrees. The claimed method does not improve upon a specific technical problem because it is shown that that prior art already disclose such solution, see the updated 103 prior art rejection below.
Therefore, the 101 abstract idea rejection is maintained.
Per 103 prior art rejection, applicant’s arguments are moot in light of new grounds of rejection with different mappings and a new reference applied (Suit).
The examiner is available for a phone interview with applicant.
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-6 and 11-16 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, mathematical relationship or an abstract idea) without significantly more.
Statutory Category: Claim 1 recites a method, comprising: building each software part of the plurality of software parts; executing a quality assurance test on the each software part of the plurality of software parts to receive result data; processing the result data for each software part to extract metrics, wherein the result data is in a format which is not readily evaluated as the metrics; sending a request for a quality gate configuration file for the software part type and receiving a quality gate configuration for the software part type, wherein the quality gate configuration comprises at least one metric gate; comparing the metrics for each software part based on the at least one metric gate; and based on the comparison and the quality gate configuration, outputting a result of the build and the metrics to a user interface providing an overview of the build and a build status of each software part of the plurality of software parts, thereby enforcing a standardized quality assurance method across each software part of the plurality of software parts of the software part type, wherein the quality gate configuration for the software part type is enforced across each software part of the plurality of software parts having the software part type, such that a standardized quality assurance method is applied to each software part of the software part type..
Step 2A – Prong 1: Claim 1 recites: processing the result data for each software part to extract metrics, wherein the result data is in a format which is not readily evaluated as the metrics; (a user can mentally analyze result data to extract metrics); comparing the metrics for each software part based on the at least one metric gate (a mental step of comparison); based on the comparison and the quality gate configuration, outputting a result of the build and the metrics, providing an overview of the build and a build status of each software part of the plurality of software parts, thereby enforcing a standardized quality assurance method across each software part of the plurality of software parts of the software part type, wherein the quality gate configuration for the software part type is enforced across each software part of the plurality of software parts having the software part type, such that a standardized quality assurance method is applied to each software part of the software part type (a user can mentally produce a report to show comparison results and build status). That is, nothing in the claim elements precludes the steps from practically being performed mentally or using pen and paper. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the mental process grouping of abstract idea. Accordingly, the claim recites an abstract idea under step 2A prong 1.
This judicial exception is not integrated into a practical application. In particular, the claim 1 recites additional elements such as “building each software part of the plurality of software parts”. Examiner would like to point out that with the broad reasonable interpretation, these elements amount to mere building a software component, which do not impose any meaningful limits on practicing the mental process (insignificant additional element and an extra-solution activity, as evidenced in Wan (US PGPUB 20230086361, paragraph [0013]; building a software component). Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to insignificant additional elements under Step 2B.
This judicial exception is not integrated into a practical application. In particular, the claim 1 recites additional elements such as “executing a quality assurance test on the each software part of the plurality of software parts to receive result data”. Examiner would like to point out that with the broad reasonable interpretation, these elements amount to mere executing a test on software components, which do not impose any meaningful limits on practicing the mental process (insignificant additional element and an extra-solution activity, as evidenced in Wan, paragraphs [0024][0025][0032][0018]; executing a quality assurance test on an application which comprises of a plurality of components). Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to insignificant additional elements under Step 2B.
This judicial exception is not integrated into a practical application. In particular, the claim 1 recites additional elements such as “sending a request for a quality gate configuration file for the software part type”. Examiner would like to point out that with the broad reasonable interpretation, these elements amount to mere data request for a mental process, which do not impose any meaningful limits on practicing the mental process (insignificant additional element and an extra-solution activity). Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to insignificant additional elements under Step 2B.
This judicial exception is not integrated into a practical application. In particular, the claim 1 recites additional elements such as “receiving a quality gate configuration for the software part type, wherein the quality gate configuration comprises at least one metric gate”. Examiner would like to point out that with the broad reasonable interpretation, these elements amount to mere data gathering for a mental process, which do not impose any meaningful limits on practicing the mental process (insignificant additional element and an extra-solution activity). Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to insignificant additional elements under Step 2B.
This judicial exception is not integrated into a practical application. In particular, the claim 1 recites additional elements such as using a user interface. The additional element in the claim amounts to no more than generic software component to apply the exception, which cannot integrate a judicial exception into a practical application or provide an inventive concept. Thus, the claim is directed to an abstract idea under Prong II step 2A and 2B.
Dependent claims 2-6 do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the dependent claims 2-6 recite more steps of mental process (such as comparison), and also recite extra-solution activities (such as outputting results of comparisons, visualizing test results), which do not impose any meaningful limits on practicing the mental process (insignificant additional element). Therefore, these claims are not patent eligible.
Independent claim 11 (a system with memory to perform the method of claim 1) and its dependent claims 12-16 are rejected under the similar rational as claims 1-6. The additional elements in the claim amount to no more than generic software/hardware components with instructions to apply the exception, which cannot integrate a judicial exception into a practical application or provide an inventive concept.
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-4, 11-14 are rejected under 35 U.S.C. 103 as being unpatentable over Reyes et al. (US PGPUB 2018/0121322) hereinafter Reyes, in view of Wan et al. (US PGPUB 2023/0086361) hereinafter Wan, in view of Suit (US PUPUB 2012/0166625).
Per claim 1, Reyes discloses a method for verifying quality assurance on a plurality of software parts, the method comprising: providing each software part of the plurality of software parts; (paragraphs [0004][0022]; providing updated applications (software parts) for testing); executing a quality assurance test on the each software part of the plurality of software parts to receive result data; processing the result data for each software part to extract metrics, wherein the result data is in a format which is not readily evaluated as the metrics (paragraphs [0022]-[0024]; executing performance tests on updated applications (software parts) and collect test results; the test results must be normalized first, i.e. the test results are not readily evaluated as metrics unless they are normalized); receiving a quality gate configuration, wherein the quality gate configuration comprises at least one metric gate; comparing the metrics for each software part based on the at least one metric gate; and based on the comparison and the quality gate configuration, outputting a result of the build and the metrics to a user interface (paragraph [0049]; receiving an established baseline performance indicator for an application (software part), compare the performance indicator of the updated application to the established baseline performance indicator to determine an amount of deviation; display the comparison in a report, the report shows performance of the updated application and how it compares to the baseline (a result of the build and the metrics); paragraph [0004]; testing a plurality of updated applications (software parts)); providing an overview of the build and a build status of each software part of the plurality of software parts, thereby enforcing a standardized quality assurance method across each software part of the plurality of software parts of the software part type (paragraph [0049]; the server system compares a respective performance indicator against the baseline established for performance indicator, in the event that the respective performance indicator deviates from the baseline established for performance indicator by a threshold amount, the respective performance indicator may be provided in a report; the server system may provide the results from each compare operation in the report; i.e. the report shows the performance of each updated application (software part) and performance deviation against its corresponding baseline performance indicator (showing build and a build status of the software part); the same method is applied for each updated application being tested); wherein the quality gate configuration for the software part type is enforced across each software part of the plurality of software parts having the software part type, such that a standardized quality assurance method is applied to each software part of the software part type (paragraphs [0004][0049]; testing and comparing performance data from different versions of an application, and generating a report showing each performance of against its corresponding baseline performance indicator; it would be obvious to use the same baseline performance indicator (quality gate configuration for the software part type) to test different versions of an application to have a standardized quality assurance method is applied to each software part of the software part type (the application identifier); i.e. comparing performance data of application A version 1, and application A version 2 to the baseline performance indicator for application A (software part type); comparing performance data of application B version 1, and application B version 2 to the baseline performance indicator for application B (software part type); using a baseline performance indicator for application B (software part type) to compare against performance data of application A version 1 would produce incorrect results).
Reyes discloses providing each software part of the plurality of software parts, but does not explicitly teach building each software part of the plurality of software parts. However, a person skilled in the art would recognize that the updated applications must be generated (built) first, then tested; as evidenced in Wan (paragraph [0013]; using a CI/CD pipeline to build an updated software component, then test it). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Reyes and Wan to use a CI/CD pipeline described in Wan to build an updated application then test it, because of a significant automation advantage of the CI/CD pipeline (Wan, paragraph [0011]).
Reyes does not explicitly teach sending a request for a quality gate configuration file for the software part. However, Suit suggests sending a request for a quality gate configuration file for the software part type and receiving a quality gate configuration for the software part type, wherein the quality gate configuration comprises at least one metric gate (claims 1 and 6; paragraph [0041]; testing a business application (software part), requesting a database to retrieve baseline and threshold data for testing the business application; the baseline and threshold data includes CPU utilization rate (metric gate)). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Reyes, Wan and Suit to request a database for baseline and threshold data for testing an application, this gives the user the flexibility to set the baseline and threshold data in the database to customized values.
Per claim 2, Wan further discloses wherein if the comparison of the metrics with the metric gate has a negative result, the result of the build is an indication that the build failed (paragraphs [0016][0027]; based on the comparison, output if performance test passes or fails; whenever there is a test failure, the CI/CD pipeline can pause and wait for a fix before resuming running; test result can be kept in the CI/CD pipeline as a status indicator (e.g., a red flag)).
Per claim 3, Wan further discloses wherein if the comparison of the metrics with the metric gate has a positive result, the result of the build is an indication that the build succeeded (paragraphs [0016][0027]; based on the comparison, output if performance test passes or fails; successfully passes the software test, the status indicator can be updated to a green flag).
Per claim 4, Wan further discloses wherein the quality gate configuration comprises: a stage name identifier which may be used to identify the development stage where a quality gate is being enforced; and an enforcement level parameter which may be output as the result of the build if the metric gate has a negative result (Fig. 1; paragraphs [0011][0016][0027]; the CI/CD pipeline comprises of a plurality of stages, the configuration for the software test corresponds to the testing stage; successfully passes the software test allows the software to move to the next stage; whenever there is a test failure, the CI/CD pipeline can pause and wait for a fix before resuming running; test result can be kept in the CI/CD pipeline as a status indicator (a red flag/enforcement level parameter)).
Claims 11-14 recite similar limitations as claims 1-4. Therefore, claims 11-14 are rejected under similar rationales as claims 1-4.
Claims 5-6 and 15-16 are rejected under 35 U.S.C. 103 as being unpatentable over Reyes, in view of Wan, in view of Suit, in view of Gardner et al. (US PGPUB 2021/0089438) hereinafter Gardner.
Per claim 5, Reyes in view Suit further discloses wherein the at least one metric gate comprises: a metric name identifier which may be used to identify the type of metric being compared, and a comparison type parameter which indicates how the values of the metrics should be compared with the threshold parameter (Suit, paragraph [0041]; collected performance data include CPU utilization rate or a disk utilization rate (a metric name identifier); Reyes, paragraph [0049]; receiving an established baseline performance indicator for an application (software part), compare the performance indicator of the updated application to the established baseline performance indicator; it would have been obvious that each performance indicator is compared to its corresponding baseline performance indicator by the metric name). Reyes in view Suit does not explicitly teach a threshold parameter comprising a warning threshold value and an error threshold value, wherein if the warning threshold value is met by the comparison, the result of the build includes specifying a warning, and wherein if the error threshold is met by the comparison, the result of the build includes specifying an error, wherein if the result of the build is neither a warning or an error, the result of the build instead includes specifying a success. However, Gardner suggests the above (paragraphs [0069]-[0071][0075][0108][0139]; a performance monitoring module compares a monitored performance metric to a performance threshold, if the monitored performance metric deviates by 25%, a warning is issue, if it deviates by 200%, an error is issued; a success is defined as when the deviation is below 20%). Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Reyes, Wan, Suit and Gardner to have separate definitions for test success, test warning and test error when comparing test performances to threshold values, this gives a user more details of a performance testing.
Per claim 6, Gardner further suggests wherein outputting the result of the build and the metrics further comprises: rendering a visualization of the result of the build, wherein if the result includes specifying a warning, a first style is rendered; or if the result includes specifying an error, a second style is rendered, or if it the result instead includes specifying a success, a third style is rendered, wherein the first style, the second style, and the third style are different from each other (paragraphs [0069]-[0071][0075][0108]; if a performance metric is determined to be below a warning threshold but above an error threshold, it may be presented with a warning color (e.g., yellow) or shade that is different from a healthy color (e.g., green) or shade (or absence of shade) and different from an error color (e.g., red) or shade).
Claims 15-16 are rejected under similar rationales as claims 5-6.
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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HANG PAN whose telephone number is (571)270-7667. The examiner can normally be reached 9 AM to 5 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Chat Do can be reached at 571-272-3721. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/HANG PAN/Primary Examiner, Art Unit 2193
Prosecution Insights