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 .
Response to Amendment
With respect to Applicant’s amendment of claims 1, 8 and 15 with regards to minor informalities, the claim objections with respect to the same have been withdrawn.
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-5, 7-12 and 14-19 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claims recite methods for performing model testing and evaluation. The Office has maintained the outstanding 35 U.S.C. 101 rejection in view of the newly amended claim language, see the below updated rejection for further details.
The limitations in Independent Claims 1, 8 and 15 of evaluating an update, as drafted, are processes that, under their broadest reasonable interpretation, covers steps that could reasonably be performed in the mind, including with the aid of pen and paper, but for the recitation of generic computer components. That is, the limitations of “identifying one or more changes that the update will require to the current configuration, wherein the one or more changes include a requested change to a first piece of software and one or more additional changes that will be required to a second piece of software to implement the requested change,” “calculating a confidence score for the update based on the performance data, wherein calculating the confidence score comprises …an adoption rate of the update across a plurality of computing systems, a number and severity of reported bugs associated with the update, and performance and downtime metrics associated with the update,” “a determination that the confidence score is greater than a second threshold level, which is less than the first threshold,” and “a determination that the confidence score is greater than a first threshold level” in Claims 1, 8 and 15, as drafted, are processes that, under their broadest reasonable interpretation, recite the abstract idea of mental processes. These limitations encompass a human mind carrying out these functions through observation, evaluation judgment and/or opinion, or even with the aid of pen and paper. Thus, these limitations recite and fall within the “Mental Processes” grouping of abstract ideas.
This judicial exception is not integrated into a practical application. Claims 1, 8 and 15 recite the following additional elements, “receiving, from a computing system, a request to evaluate an update to the computing system,” “obtaining a current configuration of the computing system,” “obtaining performance data corresponding to the one or more changes from a data repository, wherein the performance data comprises historical performance data collected from a plurality of computing systems, including the computing system and other computing systems that have previously implemented the one or more changes” and “providing a notification to a user of the computing system that the update is pending, wherein the notification includes the confidence score and one or more pieces of data that were used to determine the confidence score” these limitations do nothing more than add insignificant extra solution activity to the judicial exception, such as data gathering and outputting the results of the abstract idea, see MPEP 2106.05(g). With regard to the additional limitations which recite, “…from a computing system… an update to the computing system”, “…a current configuration of the computing system”, and “wherein the update includes an update to a firmware of a hardware device that is part of the computing system,” in Claims 1, 8 and 15, these recitations do nothing more than generally link the judicial exception to a particular technological environment, see MPEP 2106.05(h).
Further, with regard to the “computing system”, “data repository”, “wherein calculating the confidence score comprises inputting, into a trained machine learning model”, “wherein the confidence score is output by the machine learning model as a weighted function of these inputs” and “automatically applying the update to the computing system” elements of Claims 1, 8 and 15; the “memory having computer readable instructions” and “one or more processors for executing the computer readable instructions…” elements of Claim 8; and the “computer program product comprising a computer readable storage medium… the program instructions executable by a processor to cause the processor to perform operations” elements of Claim 15; these elements are recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using a generic computer component, see MPEP 2106.05(f). Accordingly, the additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea, thus failing to integrate the abstract idea into a practical application.
With regard to the individual dependent claims:
Claims 2, 9 and 16 recite, “wherein the update further includes at least one of: an update to a software installed on the computing system; and an update to the hardware device that is part of the computing system.”
Claims 3, 10 and 17 recite, “wherein the data repository includes performance data obtained from a plurality of computing systems, including the computing system, and wherein the performance data includes observed performance metrics associated with multiple configurations of each of the plurality of computing systems.”
Claims 4, 11 and 18 recite, “wherein each of the multiple configurations includes an identification of one or more pieces of software, a version of the one or more pieces of software, one or more pieces of hardware, and a firmware version of the one or more pieces of hardware.”
Claims 5, 12 and 19 recite, “wherein the update includes an identification of a component of the computing system to be updated.”
These limitations of Claims 2-5, 9-12 and 16-19 do nothing more than add insignificant extra solution activity to the judicial exception, such as data gathering, transmitting and outputting the results of the abstract idea, see MPEP 2106.05(g). Accordingly, these additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea.
Further, these limitations of Claims 2-5, 9-12 and 16-19 amount to no more than mere instructions to apply the exception using well-understood, routine and conventional computer components and functions, recited at a high level of generality, i.e. receiving/transmitting data over a network and storing/retrieving information in memory. As such, these additional elements do not amount to an inventive concept and are not by themselves sufficient to transform the judicial exception into a patent eligible invention, see MPEP 2106.05(d).
Claims 5, 12 and 19 further recite, “identifying the one or more changes that the update will require to the current configuration includes identifying at least one additional component of the computing system that will be impacted by the update.”
Claims 7 and 14 recite, “wherein the confidence score is further based on a number of computing systems that have applied the one or more changes.”
These limitations of Claims 5, 7, 12, 14 and 19, as drafted, are processes that, under their broadest reasonable interpretation, recite the abstract idea of a mental process. These limitations encompass a human mind carrying out this function through observation, evaluation judgment and/or opinion, or even with the aid of pen and paper. Thus, these limitations recite and fall within the “Mental Processes” grouping of abstract ideas. Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
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, 5, 7-10, 12, 14-17 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Schibler et al. (US PGPUB 2019/0312800; hereinafter “Schibler”) in view of Gupta et al. (US PGPUB 2014/0245290; hereinafter “Gupta”), Doyle et al. (US PGPUB 2018/0307480; hereinafter “Doyle”) and Jain et al. (US PGPUB 2024/0095012; hereinafter “Jain”).
Claim 1: (Currently Amended)
Schibler teaches a computer-implemented method comprising:
receiving, from a computing system, a request to evaluate an update to the computing system ([0654] “The interface requesting the selection of a next runtime configuration to assess may be configured or designed to provide as input the current application state and may be configured or designed to provide as output a list of actions (both as described above in the explication of the environment controller) to be used to update the application to its next state,” wherein “requesting the selection of a next runtime configuration to assess” is “a request to evaluate.”);
obtaining a current configuration of the computing system ([0070] “runtime configuration (e.g., CPU, memory, and network bandwidth resource assignments).” [0043] “initiate a first measurement of a first operational metric of the first application while the first application is operating in accordance with a first runtime configuration.” [0561] “the application state represents the runtime configuration of the application as a list of numbers, where at least one number is the value of an actuator.” [0602] “get the current application state from the environment controller.”);
identifying one or more changes that the update will require to the current configuration ([0580] “When the environment controller is instructed to change the current application state to a target state, the driver specifies the update to perform as a list of actions relative to the current state. At least one action is represented as a tuple of an index in the list of actuators and the delta for that actuator's modification, including a sign for the direction of modification (e.g., change the CPU allocation by adding 0.2 cores or removing 0.2 cores, +0.2 or −0.2).” [0603] “get the target application state from the optimization controller, providing the current state and receiving the target state in the form of a list of actions,” wherein the “list of actions” is “identifying one or more changes.”);
obtaining performance data corresponding to the one or more changes from a data repository ([0112] “application operational metrics (e.g., performance metrics such as the number of requests per seconds served by the application, or request latency) to assess the application under load, in various runtime configurations, in order to determine, or converge upon, an optimal runtime configuration.” [0119] “updating the application so that this next/updated runtime configuration is deployed.” [0120] “measuring the operational metrics of the application with these new settings: this assessment may be configured or designed to provide feedback to inform further selection of new runtime configurations to assess.” [0605] “2. Update the remote application to the target state.” [0611] “get the performance and cost measurements for the application from the environment controller.” [0630] “the driver also saves the application and optimization descriptors to the optimizer database as part of the trace for this run. This live trace may be used by a UI client to display graphs of the performance, cost and score over time during the course of the run.” [0094] “the Optimizer System may use Google Firestore for database services,” wherein “Google Firestore” is the “data repository”.); and
calculating a confidence score for the update based on the performance data ([0087] “Score Generator 117: In at least one embodiment, the Score Generator may be configured or designed to dynamically generate one or more ‘score(s)’, where each score represents an assessment of the application's current runtime configuration in relation to the optimization objective (e.g., where higher scores are better).” [0581] “the environment controller also may be configured or designed to provide a cost or performance measurement of the current state of the application.” [0614] “calculate the score for the new current application state from the performance and cost”).
With further regard to Claim 1, Schibler does not teach the following, however, Gupta teaches:
wherein the one or more changes include a requested change to a first piece of software and one or more additional changes that will be required to a second piece of software to implement the requested change ([0035] “At step 208, the method 200 identifies the shared files, or binaries from step 206 that may be needed for the software product to function properly… Dependency types may be, but are not limited to, critical, required, and recommended… A critical dependency is where the shared file must be present with the executable code for the software product to work… A recommended dependency indicates that the shared file is completely optional for the software product,” wherein the “critical dependency” and “recommended dependency” are the claimed “one or more additional changes that will be required” and “requested change,” 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 Schibler with the types of software changes as taught by Gupta so that “Advantageously, the software and/or upgrades are deployed without the need to package all configurations associated with all operating systems, bit rates, languages, etc.” (Gupta [0019]).
With further regard to Claim 1, Schibler in view Gupta does not teach the following, however, Doyle teaches:
based on a determination that the confidence score is greater than a first threshold level, automatically applying the update to the computing system ([0005] “determining a confidence score of one of the plurality of updates associated with the one of the plurality of signatures. The method further includes, in response to the confidence score satisfying a second predetermined threshold, automatically, with an electronic processor, applying the one of the plurality of updates associated with the one of the plurality of signatures to the file.” [0039] “the update manager 70 may also be configured to automatically take particular actions without requiring intervention from the IT administrator through the user interface 200, such as automatically apply updates when a confidence score satisfies a particular threshold, and the like.”); and
based on a determination that the confidence score is greater than a second threshold level, which is less than the first threshold, providing a notification to a user of the computing system that the update is pending, wherein the notification includes the confidence score and one or more pieces of data that were used to determine the confidence score ([0035] “the update manager 70 may generate and transmit a warning to a user, such as an administrator using the administrator device 40, in response to an update having a low confidence score,” wherein the “second threshold level” in Doyle is ‘0’, thereby causing updates having a confidence score which is greater then zero but less than the “second predetermined threshold” discussed in Doyle [0005] which causes the update to automatically be applied. Further, [0037] “The user interfaces may provide an administrator with insight into the impact of an update to a software product on existing code file 75, such as a list or count of code files 75 (code files 75 needing updating), a list or count of code files 75 requiring manual updating, and the like. For example, FIG. 4 illustrates one example user interface 200,” wherein “c:/users/john/file3” is an example of an update requiring review and including both the confidence score of ‘48’ and one or more pieces of data, i.e. specifying the issue as “Issue C”.).
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 Schibler in view Gupta with the confidence score based updating processes as taught by Doyle in order to “control how much risk can be assumed for a particular code file (for example, based on the criticality of the code file) to allow automatic updating of the code file and whether any manual verification is required for the update” (Doyle [0041]).
With further regard to Claim 1, Schibler in view Gupta and Doyle does not teach the following, however, Jain teaches:
wherein the performance data comprises historical performance data collected from a plurality of computing systems, including the computing system and other computing systems that have previously implemented the one or more changes ([0017] “train a machine learning model on troves of historical customer firmware update data on a dynamic basis.” [0035] “the firmware version updates may be upgrades (i.e., updates from a pre-update firmware version to a newer/later firmware version).” [0036] “The individual historical firmware update data may include… information related to the post-update firmware version (the firmware version the network device was updated to). Such information may include… a numerical value measuring a level of operational performance for the firmware versions.”);
calculating a confidence score for the update based on the performance data, wherein calculating the confidence score comprises inputting, into a trained machine learning model, an adoption rate of the update across a plurality of computing systems, a number and severity of reported bugs associated with the update, and performance and downtime metrics associated with the update, and wherein the confidence score is output by the machine learning model as a weighted function of these inputs ([0099] “apply machine learning (ML) or other models or algorithms (referred to herein as ‘ML models’) on data inputs to generate various analytics.” [0019] “use the machine learning model to compute a plurality of firmware update likelihood scores for each network device of a network device cluster based on:… (2) features of all the available/prospective ‘update’ firmware versions compatible on network devices of the network device cluster (e.g., a number of bugs raised by customers—weighted by severity of bugs—for the update firmware versions, a number of internal bugs—weighted by severity of bugs—for the update firmware versions, … numerical values measuring a level of popularity for update firmware versions, … a numerical value measuring a level of operational performance for the update firmware versions,” wherein “a level of popularity” metric is the claimed “adoption rate”. [0073] “the features of the first prospective update firmware version may comprise: … (6) a numerical value measuring a level of operational performance (e.g., SLA, device uptime, crashes, speed, etc.) for the first prospective update firmware version,” wherein “device uptime” is the inverse of “downtime” and as such directly indicates the claimed “downtime metrics”.);
wherein the update includes an update to a firmware of a hardware device that is part of the computing system ([0017] “examples of the presently disclosed technology provide automated firmware recommendation systems that inject the intelligence of machine learning into the firmware recommendation process… . From this dynamic training, the machine learning model can learn to predict/recommend an optimal firmware version for a customer/network device cluster.”).
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 Schibler in view Gupta and Doyle with the scoring using a machine learning model as taught by Jain in order to “improve functionality for a vendor's network management system while also improving its performance” (Jain [0017]).
Claim 2:
Schibler in view of Gupta, Doyle and Jain teaches the computer-implemented method of claim 1. Schibler further teaches wherein the update further includes at least one of:
an update to the first piece of software installed on the computing system; and an update to the hardware device that is part of the computing system ([0043] “a first set of updated application settings relating to the mutable runtime configuration of the first application,” wherein “a first set of updated application settings” is “an update to the first piece of software.” [0036]-[0041] “Example List of types of application settings that may be dynamically adjusted may include various types of resources provided to any virtual machine or container, such as, for example, one or more of the following (and/or combinations thereof): CPU cores, memory, network bandwidth, number of replicas (copies) of a component deployed, etc.”).
Claim 3:
Schibler in view of Gupta, Doyle and Jain teaches the computer-implemented method of claim 1. Schibler further teaches wherein the data repository includes performance data obtained from a plurality of computing systems, including the computing system, and wherein the performance data includes observed performance metrics associated with multiple configurations of each of the plurality of computing systems ([0094] “the database stores account and user data as well as application specific data such as traces of optimization runs, and configuration for these runs.” [0111] “the database stores account and user data as well as application specific data such as traces of optimization runs, and configuration for these runs.” [0215] “FIG. 7 illustrates an example embodiment of an Application Optimization Procedure 700.” [0216] “the Optimizer System may be configured or designed to include functionality for enabling multiple instances of the Application Optimization Procedure to run simultaneously or concurrently for different client applications,” wherein “multiple instances of the Application Optimization Procedure” indicates “a plurality of computing systems.” [0228] “As shown at 714, based on these measurements, the optimizer application calculates performance precision and normalization coefficients for performance and cost in the scoring function. The optimizer application stores these computed values in the database.”).
Claim 5:
Schibler in view of Gupta, Doyle and Jain teaches the computer-implemented method of claim 1. Schibler further teaches wherein the update includes an identification of a component of the computing system to be updated and identifying the one or more changes that the update will require to the current configuration includes identifying at least one additional component of the computing system that will be impacted by the update ([0043] “a first set of updated application settings relating to the mutable runtime configuration of the first application.” [0036]-[0041] “Example List of types of application settings that may be dynamically adjusted may include various types of resources provided to any virtual machine or container, such as, for example, one or more of the following (and/or combinations thereof): CPU cores, memory, network bandwidth, number of replicas (copies) of a component deployed, etc.” [0412] “The update command uses the kubect1 patch command to effect changes in the applications settings (e.g., by patching Kubernetes deployment objects).” [0580] “When the environment controller is instructed to change the current application state to a target state, the driver specifies the update to perform as a list of actions relative to the current state. At least one action is represented as a tuple of an index in the list of actuators and the delta for that actuator's modification, including a sign for the direction of modification (e.g., change the CPU allocation by adding 0.2 cores or removing 0.2 cores, +0.2 or −0.2).”).
Claim 7:
Schibler in view of Gupta, Doyle and Jain teaches all the limitations of claim 1 as described above. Schibler in view Gupta and Doyle does not teach the following, however, Jain teaches:
wherein the confidence score is further based on a number of computing systems that have applied the one or more changes ([0017] “train a machine learning model on troves of historical customer firmware update data on a dynamic basis.” [0034] “The set of historical firmware update data may comprise data related to a plurality of historical firmware updates made on a plurality of network devices of customers.” [0036] “The individual historical firmware update data may include… information related to the post-update firmware version (the firmware version the network device was updated to).”).
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 Schibler in view Gupta and Doyle with the score being based on a number of computing systems as taught by Jain in order to “improve functionality for a vendor's network management system while also improving its performance” (Jain [0017]).
Claims 8-10, 12 and 14:
With regard to Claims 8-10, 12 and 14, these claims are equivalent in scope to Claims 1-3, 5 and 7 rejected above, merely having a different independent claim type, and as such Claims 8-10, 12 and 14 are rejected under the same grounds and for the same reasons as discussed above with regard to Claims 1-3, 5 and 7.
With further regard to Claim 8, the claim recites additional elements not specifically addressed in the rejection of Claim 1. The Schibler reference also anticipates these additional elements of Claim 8, for example, wherein the system comprises:
a memory having computer readable instructions; and one or more processors for executing the computer readable instructions, the computer readable instructions controlling the one or more processors to perform operations ([0043] “At least one aspect disclosed herein is directed to different methods, systems, and computer program products for optimizing a mutable runtime configuration of a first application… various method(s), system(s) and/or computer program product(s) may be operable to cause at least one processor to execute a plurality of instructions stored in non-transient memory to…”).
Claims 15-17 and 19:
With regard to Claims 15-17 and 19, these claims are equivalent in scope to Claims 8-10 and 12 rejected above, merely having a different independent claim type, and as such Claims 15-17 and 19 are rejected under the same grounds and for the same reasons as discussed above with regard to Claims 8-10 and 12.
Claims 4, 11 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Schibler in view of Gupta, Doyle and Jain as applied to Claims 3, 10 and 17 above, and further in view of Wu et al. (US Patent 10,263,844; hereinafter “Wu”).
Claim 4:
Schibler in view of Gupta, Doyle and Jain teaches the computer-implemented method of claim 3. Schibler further teaches wherein each of the multiple configurations includes an identification of one or more pieces of software and one or more pieces of hardware ([0070] “if an application is comprised of five components, and at least one of these components has three settings which define its runtime configuration (e.g., CPU, memory, and network bandwidth resource assignments), and at least one setting varies through a range of 20 possible values.” [0097] “the Optimizer System may issue instructions to one or more of the nodes or components deployed at the customer environment 210 to carry out specific optimization-related operations or activities, including, for example, measuring application metrics, reporting application measurement information and/or other information to the Optimizer System, deploying updated application settings for one or more customer applications, etc.”).
With further regard to Claim 4, Schibler in view of Gupta, Doyle and Jain does not teach the following, however, Wu teaches:
wherein each of the multiple configurations includes an identification of a version of the one or more pieces of software and a firmware version of the one or more pieces of hardware (Col. 1 Ln. 59: “collecting configuration information describing a current configuration of the system, wherein the configuration information includes data storage device information identifying particular data storage devices in the system, a current version of software on the system, and a current version of firmware for a particular type of data storage device in the system.”).
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 Schibler in view of Gupta, Doyle and Jain with the software and firmware version identification information as taught by Wu for purposes of “performing proactive analysis of the configuration information that determines whether to recommend performing an upgrade” (Wu Col. 1 Ln. 65).
Claims 11 and 18:
With regard to Claims 11 and 18, these claims are equivalent in scope to Claim 4 rejected above, merely having a different independent claim type, and as such Claims 11 and 18 are rejected under the same grounds and for the same reasons as discussed above with regard to Claim 4.
Response to Arguments
Applicant's arguments, see Pages 9-10 of the Remarks filed October 9, 2025, with respect to the rejections under 35 U.S.C. 101 of Claims 1-5, 7-12 and 14-19 have been fully considered but they are not persuasive. The Office has maintained the outstanding 35 U.S.C. 101 rejection in view of the newly amended claim language, as the newly amended claim language does not assist in overcoming the outstanding 35 U.S.C. 101 rejection, see the above updated rejection for further details.
With respect to the Applicant’s argument, Page 10 Paragraph 1 of the Remarks, that Claims 1, 8 and 15 are eligible under 35 U.S.C. 101 since “The recited steps can no longer be performed in the human mind or with pen and paper, as they require the use of a trained machine-learning model operating on large-scale, cross-system historical data, an approach that is inherently computer-implemented and not reasonably performed by a human,” the Office respectfully disagrees. With regard to the newly amended limitation which recites, “inputting, into a trained machine learning model…,” this limitation is recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using a generic computer component, see MPEP 2106.05(f). Accordingly, the additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea, thus failing to integrate the abstract idea into a practical application.
With regard to the Applicant’s further argument regarding the 35 U.S.C 101 rejection, Page 10 Paragraph 3 of the Remarks, the Applicant’s states that the claims are patent-eligible under 35 U.S.C. 101 because “claims that recite a specific improvement to the functioning of a computer or another technology are not ‘directed to’ an abstract idea.” The Office contends that the claim limitations do not appear to positively recite any functional steps which necessarily result in “improving the functioning of a computer,” as the claim limitations amount to steps for calculating a score based on obtained performance data and applying an update when the score is greater than a threshold, none of which necessarily result in an improved functionality of the computing system, i.e. in cases where the threshold performance score is lower than a performance score prior to the update being applied.
Therefore, for at least the reasons discussed above, the 35 U.S.C. 101 rejection of Claims 1-5, 7-12 and 14-19 has been maintained.
Applicant's arguments, see Pages 10-12 of the Remarks, with respect to the rejections under 35 U.S.C. 103 of Claims 1-5, 7-12 and 14-19 have been fully considered but they are not persuasive.
With respect to the Applicant’s argument regarding Claim 1, Page 11 of the Remarks, that the newly amended language of Claim 1 is not taught by the previously cited prior art, this argument has been fully considered but is moot in view of the newly cited Jain et al. (US PGPUB 2024/0095012) reference as discussed above in the modified rejection of Claim 1.
With respect to the Applicant’s further argument, Page 12 Paragraph 2 of the Remarks, that the features of the remaining claims are not taught by the cited prior art, the Office respectfully disagrees. These arguments rely upon the arguments as presented in relation to Claim 1 discussed above, and as such the Office directs the Applicant to the responses above regarding these arguments.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure is as follows:
Zweifel et al. (US PGPUB 2006/0101457) discloses a method and system for selecting patches to recommend for installation on a given computer system, including selecting and executing one or more patch analyzer programs, causing it to generate issues by processing a set of patches compatible with the selected program and with the computer system's installed operating system, programs, and patches.
Lechtaler et al. (“Automated Analysis of Source Code Patches using Machine Learning Algorithms,” 2015) discusses a tool for automated analysis of source code patches and branch differences, including use of machine learning techniques.
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 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.
/J.G.M/Examiner, Art Unit 2197
/BRADLEY A TEETS/Supervisory Patent Examiner, Art Unit 2197