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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on February 24, 2026 has been entered.
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, 5-6, 10, 14-15 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Deziel et al. (US PGPUB 2022/0300261; hereinafter “Deziel”) in view of Kraft et al. (US PGUB 2011/0055798; hereinafter “Kraft”), Karlsson et al. (US PGPUB 2023/0091520; hereinafter “Karlsson”) and Weldemariam et al. (US PGPUB 2020/0110600; hereinafter “Weldemariam”).
Claim 1: (Currently Amended)
Deziel teaches a method for predicting a risky code commit, the method being implemented by at least one processor, the method comprising:
receiving, by the at least one processor, a first code commit ([0015] “The logical operations of the various embodiments of the disclosure described herein may be implemented as a sequence of computer implemented steps, operations or procedures running on a programmable circuit within a computer or within a directory system, database or compiler.” [0007] “receiving a commit submitted by an author in an open source project.”);
analyzing, by the at least one processor via a feature engineering component, the first code commit in order to determine a plurality of features that relate to the first code commit ([0006] “a method of determining if a commit is problematic includes determining a complexity of the commit; determining an author of the commit; determining an experience of the author, determining a component affected by the commit”. [0036] “The present invention uses an algorithm to indicate the modified component for each commit,” wherein the “algorithm” is the “feature engineering component”.),
wherein the feature engineering component uses historical software module data as a resource for identifying the plurality of features ([0035] “After collecting the historical information, it is determined which data points are useful for predicting a negative impact to the instruction processor emulator 120. Referring to FIG. 3, in one example embodiment, data points 300 for predicting a negative impact to the instruction processor emulator 120 are illustrated,” wherein the “data points” are the “features”. [0056] “If implemented in firmware and/or software, the functions described above may be stored as one or more instructions or code.”);
applying, by the at least one processor, a machine learning model that uses an artificial intelligence technique to project a result of executing the first code commit ([0007] “testing the commit using a pre-trained learning model; and determining if the commit is problematic.”),
wherein the machine learning model is trained using historical software module data developed in connection with the first code commit ([0034] “At 204, historical data on past commits is collected. In this example embodiment, because the LLVM project is open source, the entire commit history is available on GitHub. GitHub is used to collect data from the commits, comments and collaborators repositories and store it in formatted files.” [0035] “At 206, a learning model is created and trained on the historical data. After collecting the historical information, it is determined which data points are useful for predicting a negative impact to the instruction processor emulator 120.”);
assessing, by the at least one processor based on a result of the applying of the machine learning model, whether the first code commit is risky ([0044] “Referring back to FIG. 2, at 208, the [learning] model is used to determine if a commit is problematic. For each commit, the learning model can assign a level of risk, such as low, medium or high.”),
wherein the assessing of whether the first code commit is risky comprises detecting an anomaly with respect to at least one feature from among the plurality of features based on the result of the applying of the machine learning model ([0006] “a method of determining if a commit is problematic includes determining a complexity of the commit; determining an author of the commit; determining an experience of the author, determining a component affected by the commit; and assigning a risk value to the commit based on the complexity, the author, the experience of the author and the component affected.” [0035] “A commit author who has limited experience committing to the repository or modifying certain areas of the code could have a greater chance of introducing bugs or performance regressions. For purposes of this model, the following measures of author experience were used: the number of LLVM commits previously done by the author, the total number of code lines added at the time of the commit, and the total number of code lines removed at the time of the commit.” [0036] “Two additional predictive features include: the name of the author 306 who did the commit (because different authors may have a different rate of making error prone commits) and the component 308 in which the commit is made (because certain LLVM components may be more prone to bugs or performance regressions than others),” wherein the detected “anomaly” in Deziel would include detecting that the commit author is an author associated with a high “rate of making error prone commits”.), and
wherein the assessing is further based on an analysis of the first code commit, a file associated with the first code commit, and an experience metric associated with a developer of the first code commit ([0006] “a method of determining if a commit is problematic includes determining a complexity of the commit; determining an author of the commit; determining an experience of the author, determining a component affected by the commit; and assigning a risk value to the commit based on the complexity, the author, the experience of the author and the component affected.” [0035] “Referring to FIG. 3… data points 300 for predicting a negative impact… are illustrated. One factor is commit complexity 302… at least four measures of complexity that impacted performance were ascertained from the collected data: the number of characters in the commit message, the number of files changed, the number of code lines added, and the number of code lines removed. A second factor includes author experience,” wherein the “commit complexity” and the “author experience” are the claimed “analysis of the first code commit” and “experience metric” assessment factors. [0036] “Two additional predictive features include: the name of the author 306… and the component 308 in which the commit is made,” wherein the “component 308 in which the commit is made” is the claimed “file associated with the first code commit” assessment factor. See also [0037] “The file that has the greatest number of changed lines is assumed to be the main component that was changed… If the file with the most changed lines was ‘llvm/lib/Analysis/InstructionSimplify.cpp’, the algorithm asserts the component to be ‘InstructionSimplify’,” thereby clarifying that the “component” in Deziel is a file associated with a code commit.); and
when the first code commit is assessed as being risky, determining an explanation that relates to the assessment of riskiness ([0045] “If the learning model determines the commit is problematic, flow branches ‘YES’ to 214. The commit is sent for further review, for example by an engineer, and flow ends at 212.” [0007] “if the commit is problematic, sending a report in the open source project outlining the level of risk of implementing the commit and a reason for the level or risk.” [0044] “the learning model can generate a report of the level of risk and the reason(s) why the level of risk is high, for example, by citing to the factors of FIG. 3. The report could go to the reviewer to help aid in the review. The report could also be sent back to an author of the commit in order to give a chance for the author to rewrite the commit and reduce the level of risk of the commit.”).
With further regard to Claim 1, Deziel does not teach the following, however, Kraft teaches:
wherein the feature engineering component categorizes raw features into discrete groups to facilitate the determining of the plurality of features that relate to the first code commit ([0014] “a coding violation indication may comprise any output from the one or more automated review tools 106 signifying some manifestation of a deviation from accepted coding standards,” wherein the “coding violation indications” are the “raw features”. [0017] “The categorization component 202 takes as input the various coding violation indications and, based on one or more mappings 204, categorizes the coding violation indications. The resulting categorized violation indications are then provided to the quality analyzer component 206 that, in turn, determines one or more code quality indices based on the categorized violation indications.” [0018] “the coding violations indication may be generated each time a portion of software code is checked into the repository 104. In this case, the tools 106 are invoked in response to the code being checked into the repository, with the resulting coding violation indications (if any) being aggregated as necessary,” wherein the code being “checked into the repository” is a type of “code commit”. [0019] “processing continues at block 304 where the plurality of coding violation indications are categorized according to a plurality of coding quality attributes.” [0021] “one or more mappings are provided associating specific coding violation indications with particular ones of the coding quality attributes. For example, Tables 2 and 3 below list a number of coding violation indication…. and their corresponding classification according to plurality of coding quality attributes 402,” wherein Tables 2 and 3, below Kraft [0021], shows examples of the categorizing of “Coding Violation Indications”, i.e. “raw features”, into the different “Coding Quality Attributes,” i.e. “discrete groups”.).
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 Deziel with the categorizing of features as taught by Kraft in order “to provide techniques for determining software code quality” (Kraft [0006]).
With further regard to Claim 1, Deziel in view of Kraft does not teach the following, however, Karlsson teaches:
wherein the detecting of the anomaly includes predicting a possibility of a revert of the first code commit based on an unsupervised learning technique ([0038] “Risk Aware System 100 may provide a risk identification model that will predict the degree of risk for every code change/commit. This may be accomplished by using the incident journey, so that the system may reverse engineer and identify the patterns in incoming incidents due to code changes.” [0033] “Unsupervised learning may be done for incident descriptions, resolution notes, issue tracking tickets, and code repository commit messages, for example,” wherein Deziel discloses that the “commit messages” include information regarding reversions, i.e. Deziel [0039] “A commit message might contain the text ‘this reverts commit r345487’. This implies there was a problem with commit 345487.”); and
generating, by the at least one processor, a recommended action for overcoming the assessed riskiness ([0028] “Alert 131… may provide a first suggested action for reducing, for example, the determined risk level for the first proposed modification.” [0039] “Risk Aware System 100 may provide a model that can proactively suggest code changes/resolutions for incoming incidents, by building a classification/probability prediction… model.”).
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 Deziel in view of Kraft with the unsupervised learning technique and recommended action as taught by Karlsson in order to “provide intelligent alerts… to mitigate incidents, reduce development bugs, and identify risks proactively in real-time” (Karlsson [0011]).
With further regard to Claim 1, Deziel in view of Kraft and Karlsson does not teach the following, however, Weldemariam teaches:
receiving, by the at least one processor, user input regarding implementation of the first code; monitoring, by the at least one processor, the user input and the first code commit; and transmitting, by the at least one processor, a result of the monitoring of the user input and the first code commit to the machine learning model ([0046] “Previous pattern history related to understanding code risks and recording user's actions pertaining to said code risks helps in learning discrepancies.” [0049] “Further aspects provide for training a machine learning model to classify assessed valuation and risk vectors into actions that can be taken as part of a process for ameliorating deprecated code use, by gathering user feedback to define and improve the training set for the machine learning model.” [0075] “Once the ameliorative action generator is in use, at 308 it gathers user feedback in order to establish whether any given action was a suitable response to the presence of deprecated code or what additional/other action should have been taken… After a number of initial iterations, at 310 the self-learning ameliorative action generator retrains itself to learn an improved classification based on a filtered vector space of multidimensional risk vectors and actions defined by the user feedback. This re-training is done on a recurring schedule for ongoing refinement of the learning model.” ).
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 Deziel in view of Kraft and Karlsson with the monitoring of user input and related activities as taught by Weldemariam in order to “provide time efficiencies relative to previous scanning methods” (Weldemariam [0046]).
Claim 5:
Deziel in view of Kraft, Karlsson and Weldemariam teaches all the limitations of claim 1 as described above. Deziel in view of Kraft and Weldemariam does not teach the following, however, Karlsson teaches:
further comprising displaying, via a user interface (UI), a textual message that includes the explanation ([0038] “Risk Aware System 100 may provide a risk identification model that will predict the degree of risk for every code change/commit.” [0024] “The Risk Aware System 100 may use machine learning techniques to analyze the received information and display information on display 610.” [0028] “The displayed information may include a determined risk level 121 for a first product in DevOps System 190…The displayed information may also include specific alerts, e.g., an alert 131 and alert 132. Alert 131 may provide a first alert identifying, for example, a first proposed modification to DevOps System 190, may provide a first suggested action for reducing, for example, the determined risk level for the first proposed modification to the DevOps System 190, and may provide the determined risk level as a first score from 0 to 100.”).
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 Deziel in view of Kraft and Weldemariam with the displaying on a user interface as taught by Karlsson in order to “provide intelligent alerts… to mitigate incidents, reduce development bugs, and identify risks proactively in real-time” (Karlsson [0011]).
Claim 6:
Deziel in view of Kraft, Karlsson and Weldemariam teaches the method of Claim 5. Deziel in view of Kraft and Weldemariam does not teach the following, however, Karlsson teaches:
wherein the textual message further includes the recommended action ([0028] “Alert 131… may provide a first suggested action for reducing, for example, the determined risk level for the first proposed modification.” [0039] “Risk Aware System 100 may provide a model that can proactively suggest code changes/resolutions for incoming incidents, by building a classification/probability prediction… model.”).
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 Deziel in view of Kraft and Weldemariam with the recommendation as taught by Karlsson in order to “provide intelligent alerts… to mitigate incidents, reduce development bugs, and identify risks proactively in real-time” (Karlsson [0011]).
Claims 10 and 14-15:
With regard to Claims 10 and 14-15, these claims are equivalent in scope to Claims 1 and 5-6 rejected above, merely having a different independent claim type, and as such Claims 10 and 14-15 are rejected under the same grounds and for the same reasons as discussed above with regard to Claims 1 and 5-6.
With further regard to Claim 10, the claim recites additional elements not specifically addressed in the rejection of Claim 1. The Deziel reference also anticipates these additional elements of Claim 10, for example, wherein the computing apparatus comprises:
a processor (Fig. 5: CPU 502);
a memory (Fig. 5: ROM 506 and Data Storage 512);
a display (Fig. 5: Display 524); and
a communication interface coupled to each of the processor, the memory, and the display (Fig. 5: Communications Adapter 514).
Claim 19:
With regard to Claim 19, this claim is equivalent in scope to Claim 1 rejected above, merely having a different independent claim type, and as such Claim 19 is rejected under the same grounds and for the same reasons as discussed above with regard to Claim 1.
With further regard to Claim 19, the claim recites additional elements not specifically addressed in the rejection of Claim 1. The Deziel reference also anticipates these additional elements of Claim 19, for example, Deziel teaches:
A non-transitory computer readable storage medium storing instructions for predicting a risky code commit, the instructions comprising executable code which, when executed by a processor, causes the processor to… ([0056] “If implemented in firmware and/or software, the functions described above may be stored as one or more instructions or code on a computer-readable medium. Examples include non-transitory computer-readable media encoded with a data structure and computer-readable media encoded with a computer program.”).
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 3 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Deziel in view of Kraft, Karlsson and Weldemariam as applied to Claims 1 and 10 above, and further in view of Atyam et al. (US PGPUB 2017/0091078; hereinafter “Atyam”).
Claim 3:
Deziel in view of Kraft, Karlsson and Weldemariam teaches all the limitations of claim 1 as described above. Deziel in view of Kraft, Karlsson and Weldemariam does not teach the following, however, Atyam teaches:
wherein the assessing of whether the first code commit is risky further comprises calculating, for each respective feature from among the plurality of features, a corresponding ranking value, and detecting the anomaly based on each corresponding ranking value ([0013] “The risk assessment criteria includes risk assessment factors. The risk assessment factors are assigned a weight 74 (or weighted) as part of the risk assessment criteria, as in block 112. A risk assessment score 76 of the update is determined based on the risk assessment criteria, as in block 116,” wherein the “weight” is the “ranking value”.).
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 Deziel in view of Kraft, Karlsson and Weldemariam with the ranking value as taught by Atyam so that “A risk component's weight factors may be tuned based on the stage of the release of the project” (Atyam [0054]).
Claim 12:
With regard to Claim 12, this claim is equivalent in scope to Claim 3 rejected above, merely having a different independent claim type, and as such Claim 12 is rejected under the same grounds and for the same reasons as discussed above with regard to Claim 3.
Claims 4 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Deziel in view of Karlsson, Weldemariam and Atyam as applied to Claims 3 and 12 above, and further in view of Pekel et al. (US Patent 11,544,136; hereinafter “Pekel”).
Claim 4:
Deziel in view of Karlsson, Weldemariam and Atyam teaches all the limitations of claim 3 as described above. Deziel in view of Karlsson, Weldemariam and Atyam does not teach the following, however, Pekel teaches:
wherein the calculating of each corresponding ranking value comprises calculating a Shapley Additive exPlanations (SHAP) value of each respective feature from among the plurality of features (Col. 20 Ln. 13-16: “the report engine 325 may apply Shapley Additive Explanations (SHAP) to extract the information and generate a corresponding report.” Col. 20 Ln. 43: “The Shapley Additive Explanations library may calculate the effect of a single feature, such as a hyper-parameter, on the intermediary model predicting the target information.” Col. 20 Ln. 47-53: “The library can further provide a visualization of this effect as a function of the feature value, such as the possible hyper-parameter values, for all the machine learning trials in the dataset. As features can interact with each other, the Shapley Additive Explanations library supports a visualization mode where features are encoded by color to reveal the interaction between different features.”).
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 Deziel in view of Karlsson, Weldemariam and Atyam with the SHAP calculation as taught by Pekel in order to “explain a machine learning model's predictions and rate the importance of various input features” (Pekel Col. 20 Ln. 17-18).
Claim 13:
With regard to Claim 13, this claim is equivalent in scope to Claim 4 rejected above, merely having a different independent claim type, and as such Claim 13 is rejected under the same grounds and for the same reasons as discussed above with regard to Claim 4.
Claims 7-8 and 16-17 are rejected under 35 U.S.C. 103 as being unpatentable over Deziel in view of Kraft, Karlsson and Weldemariam as applied to Claims 5 and 14 above, and further in view of Silva et al. (US PGPUB 2022/0206786; hereinafter “Silva”).
Claim 7:
Deziel in view of Kraft, Karlsson and Weldemariam teaches the method of Claim 5. Deziel further teaches comprising
displaying, via the UI a first button and a second button ([0048] “the user interface device 410 may access the Internet or other wide area or local area network to access a web application or web service hosted by the server 402 and provide a user interface for enabling a user to enter or receive information.” [0053] “The computer system 500 may also include an input/output (I/O) adapter 510… a user interface adapter 516, and a display adapter 522. The I/O adapter 510 and/or the user interface adapter 516 may, in certain embodiments, enable a user to interact with the computer system 500. In a further embodiment, the display adapter 522 may display a graphical user interface (GUI) associated with a software or web-based application on a display device 524, such as a monitor or touch screen,” wherein a GUI such as that taught in Deziel is well-known to include a plurality of ‘buttons’ which enable the user to interact with information shown in the GUI.).
With further regard to Claim 7, Deziel in view of Kraft, Karlsson and Weldemariam does not teach the following, however, Silva teaches:
the first button for prompting a user to abort the first code commit and the second button for prompting the user to confirm the first code commit ([0079] “the code analysis module 320 then outputs the modification report for review by a user… the code analysis module 320 then awaits an indication of whether the user accepts or rejects the revised software application. In some embodiments, if the user accepts the revised software application, the library management server 306 takes further steps that are implementation-specific to commit the modifications to a runtime or production version of the source code for the software application.”).
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 Deziel in view of Kraft, Karlsson and Weldemariam with the user prompts as taught by Silva in order “to provide final confirmation before the modifications in the modification report will be finalized” (Silva [0079]).
Claim 8:
Deziel in view of Karlsson, Weldemariam and Silva teaches the method of Claim 7. Deziel in view of Kraft, Karlsson and Weldemariam does not teach the following, however, Silva teaches:
wherein when the user confirms the first code commit, the method further comprises prompting the user to input a justification for confirming the first code commit ([0079] “once the user has accepted or rejected the revised software application, the code analysis module 320 sends a feedback request to the user requesting a reason for the user's decision to accept or reject the revised software application.”).
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 Deziel in view of Kraft, Karlsson and Weldemariam with the input justification as taught by Silva since it is well known and obvious that associating a user’s justification with the choice to confirm the code commit beneficially provides enhanced clarity for other users when inspecting previously submitted code commits.
Claims 16-17:
With regard to Claim 16-17, this claim is equivalent in scope to Claim 7-8 rejected above, merely having a different independent claim type, and as such Claim 16-17 is rejected under the same grounds and for the same reasons as discussed above with regard to Claim 7-8.
Claims 9 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Deziel in view of Kraft, Karlsson and Weldemariam as applied to Claims 1 and 10 above, and further in view of Plotnik et al. (US PGPUB 2020/0379879; hereinafter “Plotnik”).
Claim 9: (Currently Amended)
Deziel in view of Kraft, Karlsson and Weldemariam teaches the method of claim 1. Deziel in view of Kraft, Karlsson and Weldemariam does not teach the following, however, Plotnik teaches:
wherein the plurality of features includes at least one from among a number of first modules importing second modules being changed, a time interval between making the first code commit and progressing into production, a number of times that the second modules have been reverted in a most recent 30-day period, a version of the second modules, and a number of developers who have contributed changes to the second modules ([0055] “Examples of Behavioral application risk factors include, but are not limited to: Number of developers per Software Material Change; Code amount per commit; Number of reviewers; Software Material Change expose to the internet; Software Material Change without Security Control; Software Material Change expose PII to vendor; Developer experience in the project; Time of commit; Time since the start of a feature branch/PR before the merge; Number of reverted commits in relevant code files.”).
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 Deziel in view of Kraft, Karlsson and Weldemariam with the feature types as taught by Plotnik in order “to assess the risk of implementing the new change” (Plotnik [0008]).
Claim 18:
With regard to Claim 18, this claim is equivalent in scope to Claim 9 rejected above, merely having a different independent claim type, and as such Claim 18 is rejected under the same grounds and for the same reasons as discussed above with regard to Claim 9.
Response to Arguments
Applicant’s arguments, see Pages 10-14 of the Remarks filed February 24, 2026, with respect to 35 U.S.C. 103 have been fully considered but they are not persuasive.
With respect to the Applicant’s argument, Page 11 Paragraphs 2-4 of the Remarks, that the Deziel in view of Karlsson and Weldemariam does not teach any of the newly amended features, Office respectfully disagrees.
The Office first contends that the previously Deziel et al. (US PGPUB 2022/0300261) reference does teach the newly amended language, “wherein the feature engineering component uses historical software module data as a resource for identifying the plurality of features” and “the assessing is further based on an analysis of the first code commit, a file associated with the first code commit, and an experience metric associated with a developer of the first code commit” recited in independent claims 1, 10 and 19. The Office respectfully directs the Applicant’s attention to the newly modified rejections of claims 1, 10 and 19 above for further explanation regarding how the Deziel reference has been interpreted as teaching the newly amended language of independent claims 1, 10 and 19.
With respect to the Applicant’s argument, Page 11 Paragraph 3, that the newly amended language of Claims 1, 10 and 19 which recites, “the feature engineering component categorizes raw features into discrete groups to facilitate the determining of the plurality of features that relate to the first code commit,” is not taught by the previously cited prior art, this argument has been fully considered but is moot in view of the Kraft et al. (US PGUB 2011/0055798) reference, newly cited in the rejection of the independent claims, as discussed above in the respective rejections.
With respect to the Applicant’s further argument, Pages 13-14 of the Remarks, that the newly amended language of Claims 9 and 18 is not taught by the previously cited prior art, this argument has been fully considered but is moot in view of the Plotnik et al. (US PGPUB 2020/0379879) reference, newly cited in the rejection of Claims 9 and 18, as discussed above in the respective rejections.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure is as follows:
Kabanov et al. (US Patent 8,539,282) discloses a method for managing quality testing of software, wherein a priority of tests is determined based on their relevance to characteristics of a product under test.
Wloka et al. (“Safe-Commit Analysis to Facilitate Team Software Development,” 2009) discusses an analysis-based algorithm to identify committable changes that can be released early, without causing failures of existing tests, even in the presence of failing tests in a developer’s local workspace.
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