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 .
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, 3-6, 8, 10-13, 15 and 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over Mantripragada et al. (US PGPUB 2015/0199188; hereinafter “Mantri”) in view of Bendert et al. (US PGPUB 2024/0338310; hereinafter “Bendert”) and Avisror et al. (US PGPUB 2019/0294528; hereinafter “Avisror”).
Claim 1:
Mantri teaches a method for compiling a software package, the method comprising:
making a first determination that the software package is in a feature complete phase ([0057] “In step 410, software package deployment management program 104 (see FIG. 1) retrieves details about software lifecycle phase(s). The details retrieved in step 410 include identification(s) of the build, test and/or release phases of the software development lifecycle, where the phase(s) are associated with the QA seal being generated,” wherein the “test” phase is the “feature complete phase”. [0024] “In one embodiment, system 100 includes a QA seal-based verification of the test phase of SDLC.”);
identifying, based on the determination, a first artifact and a second artifact associated with the software package ([0045] “Software package profile 304 includes a list of components of the software package containing QA seal 300 together with related metadata. In one embodiment, software package profile 304 includes a name and version of a component of the software package (i.e., a component name 318 and a component version 320.” [0053] “The details retrieved in step 402 include… the contents or components and the version of the software package, and metadata for each component including… component version.”);
sending the compiled software package to a client device ([0021] “A software package is software deployed to multiple computers or multiple distributed target computing environments, such as cloud-based or virtualized environments.”).
With further regard to Claim 1, Mantri does not teach the following, however, Bendert teaches:
identifying a first version and a second version associated with the first artifact; identifying a third version and a fourth version associated with the second artifact ([0002] “Software dependencies may include standardized libraries, frameworks, toolkits, application programming interfaces (APIs), and the like. These dependencies may be components,” wherein the “dependencies” comprise the “first artifact” and the “second artifact”. [0045] “At operation 415, the test management service may identify a plurality of dependencies of the software component.” [0046] “At operation 420, the test management service identifies versions of the particular dependency. In some examples, the test management service identifies the versions by contacting the dependency version tracker service. At operation 425, the test management service determines if there are multiple versions.” [0048] “At operation 510, the test management service may identify a new version of a first dependency. For example, the dependency version tracker service 115 may notify the test management service 120—e.g., based upon a new version checked into a code repository service 130.”);
receiving a set of test results comprising ([0049] “the system may automatically run one or more test scripts on the software component with the new version at operation 520; identify the results at operation 525; and notify users at operation 530.” [0052] “the system may log test results for regulatory purposes.”):
a first defect test result and a first code churn result for the first version; a second defect test result and a second code churn result for the second version; a third defect test result and a third code churn result for the third version; and a fourth defect test result and a fourth code churn result for the fourth version ([0017] “the GUIs may provide a dashboard that shows… which versions of each dependency have been tested and confirmed as functional; which versions of each dependency currently have known defects.” [0049] “identify the results at operation 525; and notify users at operation 530,” wherein the identified “results” are the “defect test results”. [0050] “the test management service may analyze changes made to a second component to accommodate the new version of the dependency at operation 535. At operation 540, the test management service may determine predicted changes to the component based upon the changes made to the second component. As previously described this may be accomplished using machine-learning models. At operation 542, the user may be notified of the suggested changes,” wherein analyzing and notification of “changes” associated with the “components” is the “code churn results”.); and
determining a first promotion score for the first version, a second promotion score for the second version, a third promotion score for the third version, and a fourth promotion score for the fourth version ([0012] “the system may determine, for an updated dependency, given the dependency information and changes made to the dependency, a risk score… that describes a perceived risk of the change in the dependency. For example, if a functionality that changes is heavily used by the software component, a high risk score may be assigned; on the other hand, if the changes in the software dependency do not impact functionality heavily used by the software component, a lower risk score may be assigned,” wherein the “risk scores” are the “promotion scores”.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Mantri with the identifying and testing of artifact versions as taught by Bendert for purposes of “providing a risk rating or otherwise providing a recommendation as to whether the particular dependency will cause problems for the software component” (Bendert [0051]).
With further regard to Claim 1, Mantri in view of Bendert does not teach the following, however, Avisror teaches:
determining, based on the first determination and the set of test results, a promotion score set ([0072] “an overall risk factor may be calculated for each new build combination or version based on respective risk assessments or risk scores for the particular software artifacts that are modified, relative to one or more previous build combinations/versions at block 950,” wherein the “risk scores for the particular software artifacts that are modified” is the “risk scores” taught above in Bendert.);
generating, based on the promotion score set, a recommended software package comprising the first version of the first artifact and the fourth version of the second artifacts ([0027] “The build combinations 102, 102′, 102″ may represent respective collections or sets of the software artifacts 104, 104′, 104″.” [0036] “The build combination includes software artifacts (e.g., artifacts 104) of a specific software version to be deployed for testing.” [0059] “A subset of the stored test assets may thereby be selected as may be required for testing the modified software artifact, and/or as may be warranted based on the associated risk score. Also, at block 830, a subset of stored test cases (e.g., test cases 287) may be associated with a test operation or test cycle for the retrieved build combination, likewise based on the software artifact(s) identified as having the changes modifications and/or the associated risk score(s).” [0064] “an order or priority for testing the software artifacts of the build combination 402 may be determined based on the respective risk scores associated therewith. That is, for a given build combination, software artifacts that are associated with higher risk scores may be tested prior to and/or using more rigorous testing (in terms of selection of test cases and/or test assets) than software artifacts that are associated with lower risk scores.”);
compiling the recommended software package to obtain a compiled software package ([0022] “in continuous delivery (CD), software may be built, deployed, and tested in short cycles, such that the software can be reliably released at any time. Code may be compiled and packaged by a build server whenever a change is committed to a source repository, then tested by various techniques (which may include automated and/or manual testing) before it can be marked as releasable.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Mantri in view of Bendert with the recommendation based on a score set as taught by Avisror such that “efficiency in automated software test execution may be improved and processing requirements… in a test environment may be reduced by automatically adapting (e.g., limiting and/or prioritizing) testing based on identification of software artifacts that include changes to a software build and/or risks associated therewith” (Avisror [0022]).
Claim 3:
Mantri in view of Bendert and Avisror teaches the method of claim 1. Mantri in view of Bendert does not teach the following, however, Avisror teaches:
wherein the first artifact is an individual artifact and the second artifact is a package of multiple individual artifacts ([0023] “As used herein, software artifacts (or “artifacts”) can refer to files in the form of computer readable program code that can provide a software application, such as a web application, search engine, etc., and/or features thereof. As such, identification of software artifacts as described herein may include identification of the files or binary packages themselves, as well as classes, methods, and/or data structures thereof at the source code level,” wherein a “file” and “binary package” are examples of “individual” and “multiple individual” artifacts respectively.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Mantri in view of Bendert with the artifact composition as taught by Avisror such that “efficiency in automated software test execution may be improved and processing requirements… in a test environment may be reduced by automatically adapting (e.g., limiting and/or prioritizing) testing based on identification of software artifacts that include changes to a software build and/or risks associated therewith” (Avisror [0022]).
Claim 4:
Mantri in view of Bendert and Avisror teaches the method of claim 1. Mantri in view of Bendert does not teach the following, however, Avisror teaches:
wherein the first artifact is a first individual artifact and the second artifact is a second individual artifact ([0023] “As used herein, software artifacts (or “artifacts”) can refer to files in the form of computer readable program code that can provide a software application, such as a web application, search engine, etc., and/or features thereof. As such, identification of software artifacts as described herein may include identification of the files or binary packages themselves, as well as classes, methods, and/or data structures thereof at the source code level,” wherein a “file” is an example of an “individual” artifact.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Mantri in view of Bendert with the artifact composition as taught by Avisror such that “efficiency in automated software test execution may be improved and processing requirements… in a test environment may be reduced by automatically adapting (e.g., limiting and/or prioritizing) testing based on identification of software artifacts that include changes to a software build and/or risks associated therewith” (Avisror [0022]).
Claim 5:
Mantri in view of Bendert and Avisror teaches the method of claim 1. Mantri in view of Bendert does not teach the following, however, Avisror teaches:
wherein the first artifact is a first package of multiple individual artifacts and the second artifact is a second package of multiple individual artifacts ([0023] “As used herein, software artifacts (or “artifacts”) can refer to files in the form of computer readable program code that can provide a software application, such as a web application, search engine, etc., and/or features thereof. As such, identification of software artifacts as described herein may include identification of the files or binary packages themselves, as well as classes, methods, and/or data structures thereof at the source code level,” wherein a “binary package” is an example of “multiple individual” artifacts.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Mantri in view of Bendert with the artifact composition as taught by Avisror such that “efficiency in automated software test execution may be improved and processing requirements… in a test environment may be reduced by automatically adapting (e.g., limiting and/or prioritizing) testing based on identification of software artifacts that include changes to a software build and/or risks associated therewith” (Avisror [0022]).
Claim 6:
Mantri in view of Bendert and Avisror teaches the method of claim 1. Mantri in view of Avisror does not teach the following, however, Bendert teaches:
wherein the fourth version is an older version of the second artifact than the third version ([0020] “the test management service 120 may automatically test a software component when one of its dependencies is updated. For example, the test management service 120 may be notified of a new version from the software dependency version tracker service 115.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Mantri in view of Avisror with the identifying of different artifact/component version ages as taught by Bendert in order to “automatically test a software component when one of its dependencies is updated” (Bendert [0020]).
Claims 8 and 10-13:
With regard to Claims 8 and 10-13, these claims are equivalent in scope to Claims 1 and 3-6 rejected above, merely having a different independent claim type, and as such Claims 8 and 10-13 are rejected under the same grounds and for the same reasons as discussed above with regard to Claims 1 and 3-6.
With further regard to Claim 8, the claim recites additional elements not specifically addressed in the rejection of Claim 1. The Mantri reference also anticipates these additional elements of Claim 8, for example, Mantri teaches:
A non-transitory computer readable medium comprising computer readable program code, which when executed by a computer processor enables the computer processor to perform a method for compiling a software package ([0213] “FIG. 13 is a block diagram of a computer that is included in the system of FIG. 1 and that implements the processes… in accordance with embodiments of the present invention. Computer 102 generally includes a central processing unit (CPU) 1302, a memory 1304.” [0214] “Memory 1304 includes a known computer-readable storage medium.” [0223] “examples of the computer-readable storage medium includes: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM).”).
Claims 15 and 17-20:
With regard to Claims 15 and 17-20, these claims are equivalent in scope to Claims 1 and 3-6 rejected above, merely having a different independent claim type, and as such Claims 15 and 17-20 are rejected under the same grounds and for the same reasons as discussed above with regard to Claims 1 and 3-6.
With further regard to Claim 15, the claim recites additional elements not specifically addressed in the rejection of Claim 1. The Mantri reference also anticipates these additional elements of Claim 15, for example, Mantri teaches:
A software compiling recommendation system, comprising: a processor programmed to [perform operations] ([0213] “FIG. 13 is a block diagram of a computer that is included in the system of FIG. 1 and that implements the processes… in accordance with embodiments of the present invention. Computer 102 generally includes a central processing unit (CPU) 1302, a memory 1304.” [0214] “Memory 1304 includes a known computer-readable storage medium.” [0223] “examples of the computer-readable storage medium includes: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM).”).
Claims 2, 9 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Mantri in view of Bendert and Avisror as applied to Claims 1, 8 and 15 above, and further in view of Kabra et al. (US PGPUB 2021/0342143; hereinafter “Kabra”).
Claim 2:
Mantri in view of Bendert and Avisror teaches all the limitations of claim 1 as described above. Mantri in view of Bendert and Avisror does not teach the following, however, Kabra teaches further comprising:
making a second determination that the first version includes a defect; and making a third determination, in response to the second determination, that the defect is not a result of code churn of features to be completed, and wherein generating the recommended software package is further based on the third determination ([0003] “The operation includes identifying a build error for a software project including a plurality of software modules, and in response selecting a first software module… with one or more errors related to the build error, identifying a comparison software module… including at least one of: (i) a sibling software module to the first software module or (ii) an earlier version of the first software module, determining a potential problem with the first software module, related to the build error, based on comparing the first software module with the comparison software module, generating a solution to the potential problem based on the first software module, the solution including a modification to the software code of the first software module, and applying the solution by modifying the software code of the first software module.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Mantri in view of Bendert and Avisror with the defect determinations as taught by Kabra so that “a working build is created automatically, potentially saving significant time and resources” (Kabra [0019]).
Claims 9 and 16:
With regard to Claims 9 and 16, these claims are equivalent in scope to Claim 2 rejected above, merely having a different independent claim type, and as such Claims 9 and 16 are rejected under the same grounds and for the same reasons as discussed above with regard to Claim 2.
Claims 7 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Mantri in view of Bendert and Avisror as applied to Claims 1 and 8 above, and further in view of Koerber (US PGPUB 2006/0041509; hereinafter “Koerber”).
Claim 7:
Mantri in view of Bendert and Avisror teaches all the limitations of claim 1 as described above. Mantri in view of Bendert and Avisror does not teach the following, however, Koerber teaches further comprising:
making a second determination that each of the first version, the second version, the third version, and the fourth version are greater than a minimum version number, and wherein the generating is further based on the second determination ([0014] “the component version identification in the software package description includes at least one of the following:” and [0016] “an identification of a minimum or maximum version.” [0052] “Minimum version number: assuming that updates are number sequentially higher (using any suitable scheme), this option allows specifying that the package may only be installed in combination with `recent` components with versions numbers starting at the 1.sup.st version number of the package description.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Mantri in view of Bendert and Avisror with the minimum artifact version determination as taught by Koerber as “This makes it even easier to deal with differing configurations, in particular it makes it possible to specify for a software component one or more acceptable version numbers in one package description” (Koerber [0018]).
Claim 14:
With regard to Claim 14, this claim is equivalent in scope to Claim 7 rejected above, merely having a different independent claim type, and as such Claim 14 is rejected under the same grounds and for the same reasons as discussed above with regard to Claim 7.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure is as follows:
Back et al. (US PGPUB 2007/0220507) discloses a system which manages version information for a group of software components by maintaining a version repository containing version information for all of the components, including a process for determining whether each of a plurality of components has a version number greater than or equal to a minimum version number corresponding to a particular baseline version number.
Kaur et al. (“PROMETHEE based Component Evaluation and Selection for Component Based Software Engineering,” 2014) discusses a methodology for component selection based on Preference Ranking Organization Method for Enrichment Evaluation (PROMETHEE), wherein the software components are evaluated and ranked according to their quality attributes.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Joanne G. Macasiano whose telephone number is (571)270-7749. The examiner can normally be reached Monday to Thursday, 10:30 AM to 6:00 PM Eastern Standard Time.
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, Bradley Teets can be reached at (571) 272-3338. 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.
/JOANNE G MACASIANO/Examiner, Art Unit 2197
Prosecution Insights