DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
The following claim(s) is/are pending in this office action: 1-9, 11-16, 18, 20-23
The following claim(s) is/are amended: 1, 11, 18
The following claim(s) is/are cancelled: 10, 17, 19
The following claim(s) is/are new: 21-23
Claim(s) 1-9, 11-16, 18, 20-23 is/are rejected. This rejection is FINAL.
Response to Arguments
Applicant’s arguments filed in the amendment filed 3/11/2026, have been fully considered but are moot in view of new grounds of rejection. The reasons set forth below.
Applicant’s Invention as Claimed
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.
Claim(s) 1-9, 11-16, 18, 20-23 is/are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
Claim(s) 1-20 is/are rejected under 35 U.S.C. 101 because the claimed invention is directed to observation and judgment without significantly more. The claim(s) recite(s) “determining, based on the software patch, a pre-patch code property graph and a post-patch code property graph; determining, based on the pre-patch code property graph and the post-patch code property graph, a combined patch code property graph” which are observations about the patch. The claim further recites “determining, based on the combined patch code property graph and using a trained machine-learning model, a patch type for the software patch” which is a judgment based on the observation. This judicial exception is not integrated into a practical application because the claims do not improve a computer, rather they just command a determination be performed where the computer is used as a tool to assist in processing using generic computer features such as machine learning as a stand-in for a human’s mind. The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional features are generic computer components that simply place the abstract idea into a particular field of use, and the limitation of “receiving [] a software patch” is insignificant pre-solution data gathering. The additional features of the dependent claims do not change the above analysis.
Claims not specifically mentioned are rejected by virtue of dependency and because they do not obviate the above-recited deficiencies.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claim(s) 18 and 20 is/are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Claim limitation “second computing device configured to: [perform functions]” invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. “Device” is a nonce term that is modified by function and not limited by sufficient structure for performing the function. Therefore the claim invokes means plus. The specification fails to identify algorithms for performing each of the functions named. Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph. Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph;
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
The above cited rejections are merely exemplary.
The Applicant(s) are respectfully requested to correct all similar errors.
Claims not specifically mentioned are rejected by virtue of their dependency.
Claim Rejections - 35 USC § 103
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 of this title, 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-6, 11-15, 18, and 20-23 are rejected under 35 U.S.C. 103 as being unpatentable over Larmuseau (US Pub. 2019/0238593) in view of Cabrera Lozoya (hereinafter “Cabrera”, US Pub. 2022/0129261).
With respect to Claim 1, Larmuseau teaches a method comprising: receiving, by a computing device, a software patch for a software product; (Fig. 5, para. 66; computing device with communication path. paras. 29-31; patch for software or application that has a vendor. Para. 40; system receives patches.)
determining, based on the software patch, a pre-patch code property graph and a post-patch code property graph; (Property graphs in particular will be taught later. paras. 36, 41-44, 49-51; system determines what code and related functions are added or removed due to a particular patch. The system describes the source code using an abstract syntax tree.)
determining, based on the pre-patch code property graph and the post-patch code property graph, a combined patch code property graph; (para. 54; system uses a modification extractor to compute the overlap between two trees. The subsets that are not part of the overlap are extracted as the modifications of the patch.)
and determining, based on the combined patch code property graph, and using a trained machine-learning model, a patch type for the software patch. (paras. 33, 42, 51; system determines whether or not a patch contains a security fix. Paras. 42-43, 45; machine-learning used to analyze source code. Model can be trained.)
But Larmuseau does not explicitly teach property graphs.
Cabrera, however, does teach property graphs (Spec, para. 35, 43; identifies property graphs as “merging two or more of” abstract syntax trees, control-flow graphs, and program dependence graphs to contain all of their information in one place. Larmuseau only teaches graphing ASTs. Therefore, Examiner cites Cabrera, paras. 29-31, 75-77; Source code may be represented as graph-based representation, which may include ASTs, CFGs, DFGs, PDGs or combinations thereof. Further, simple combination for expected results is obvious, see MPEP 2143(I)(A). It would have been obvious to one of ordinary skill prior to the effective filing date to combine the two representations of the pre and post code in order to have a single location that represents the changes made by the patch.)
It would have been obvious to one of ordinary skill prior to the effective filing date to combine the method of Larmuseau with the property graphs in order to identify all possible change vectors for a patch.
With respect to Claim 2, modified Larmuseau teaches the method of claim 1, and Cabrera also teaches further comprising: receiving pre-patch source code for the software product associated with the software patch; and receiving post-patch source code for the software product, wherein the pre-patch code property graph is further determined based on the pre-patch source code and wherein the post-patch code property graph is further based on the post-patch source code. (paras. 28-30, 48-49; system determines pre- and post-changed source code and generates representations therefrom.)
The same motivation to combine as the independent claim applies here.
With respect to Claim 3, modified Larmuseau teaches the method of claim 2, and Cabrera also teaches further comprising: determining a plurality of functions in the pre-patch source code; (paras. 28-30, 48-49; system determines pre- and post-changed source code and generates representations therefrom.)
The same motivation to combine as the independent claim applies here.
And Larmuseau also teaches determining, based on the software patch, a portion of the plurality of functions associated with the software patch; and removing a second portion of the plurality of functions not associated with the software patch from the pre-patch source code. (paras. 36, 41-44, 49-51; system determines what code and related functions are added or removed due to a particular patch. The system describes the source code using an abstract syntax tree.)
With respect to Claim 4, modified Larmuseau teaches the method of claim 2, and Cabrera also teaches further comprising: determining a plurality of functions in the post-patch source code; (paras. 28-30, 48-49; system determines pre- and post-changed source code and generates representations therefrom.)
The same motivation to combine as the independent claim applies here.
And Larmuseau also teaches determining, based on the software patch, a portion of the plurality of functions associated with the software patch; and removing a second portion of the plurality of functions not associated with the software patch from the post-patch source code. (paras. 36, 41-44, 49-51; system determines what code and related functions are added or removed due to a particular patch. The system describes the source code using an abstract syntax tree.)
With respect to Claim 5, modified Larmuseau teaches the method of claim 1, and Larmuseau also teaches wherein the combined patch code property graph comprises one or more of a deleted component, an added component, or a context component. (paras. 36, 41-44, 49-51; system determines what code and related functions are added or removed due to a particular patch.)
With respect to Claim 6, modified Larmuseau teaches the method of claim 1, and Larmuseau also teaches wherein the patch type for the software patch comprises one of a security patch or a non-security patch. (paras. 33, 42, 51; system determines whether or not a patch contains a security fix.)
With respect to Claim 11, it is substantially similar to Claim 1 and is rejected in the same manner, the same art and reasoning applying. Further, Larmuseau also teaches an apparatus comprising: one or more processors; and memory storing processor-executable instructions that, when executed by the one or more processors, cause the apparatus to: (para. 67-68; processor and memory storing instructions)
With respect to Claims 12-13, they are substantially similar to Claims 2 and 4, respectively, and are rejected in the same manner, the same art and reasoning applying.
With respect to Claim 14, it is substantially similar to Claim 4 and is rejected in the same manner, the same art and reasoning applying.
With respect to Claim 15, it is substantially similar to Claim 6 and is rejected in the same manner, the same art and reasoning applying.
With respect to Claim 18, it is substantially similar to Claim 1 and is rejected in the same manner, the same art and reasoning applying. Further, Larmuseau also teaches a system comprising: a first computing device configured to send a software patch; and a second computing device configured to: receive the software patch; (para. 40; system retrieves a patch from another device.)
With respect to Claim 20, it is substantially similar to Claim 6 and is rejected in the same manner, the same art and reasoning applying.
With respect to Claim 21, modified Larmuseau teaches the method of claim 1, and Larmuseau also teaches wherein the combined patch code property graph comprises a portion of the pre-patch code not included in the post patch code. (paras. 36, 41-44, 49-51; system determines what code and related functions are added or removed due to a particular patch. Examiner notes that “comprises a portion of pre-patch code not included in the post-patch code” is a subset of “pre-patch code” and Cabrera teaches the entire pre-patch code, see Cabrera, paras. 29-31, 75-77; Source code may be represented as graph-based representation, which may include ASTs, CFGs, DFGs, PDGs or combinations thereof.)
With respect to Claim 22, modified Larmuseau teaches the method of claim 1, and Larmuseau also teaches wherein the combined patch code property graph comprises a portion of the post patch code not included in the pre-patch code. (paras. 36, 41-44, 49-51; system determines what code and related functions are added or removed due to a particular patch. Examiner notes that “comprises a portion of post patch code not included in the pre-patch code” is a subset of “post patch code” and Cabrera teaches the entire post patch code, see Cabrera, paras. 29-31, 75-77; Source code may be represented as graph-based representation, which may include ASTs, CFGs, DFGs, PDGs or combinations thereof.)
With respect to Claim 23, modified Larmuseau teaches the apparatus of claim 11, and Larmuseau also teaches wherein the combined patch code property graph comprises a portion of the pre-patch code not included in the post patch code (paras. 36, 41-44, 49-51; system determines what code and related functions are added or removed due to a particular patch. Examiner notes that “comprises a portion of pre-patch code not included in the post-patch code” is a subset of “pre-patch code” and Cabrera teaches the entire pre-patch code, see Cabrera, paras. 29-31, 75-77; Source code may be represented as graph-based representation, which may include ASTs, CFGs, DFGs, PDGs or combinations thereof.)
And a portion of the post patch code not included in the pre-patch code. (paras. 36, 41-44, 49-51; system determines what code and related functions are added or removed due to a particular patch. Examiner notes that “comprises a portion of post patch code not included in the pre-patch code” is a subset of “post patch code” and Cabrera teaches the entire post patch code, see Cabrera, paras. 29-31, 75-77; Source code may be represented as graph-based representation, which may include ASTs, CFGs, DFGs, PDGs or combinations thereof.)
Claims 7-8 and 16 are rejected under 35 U.S.C. 103(a) as being unpatentable over Larmuseau (US Pub. 2019/0238593) in view of Cabrera Lozoya (hereinafter “Cabrera”, US Pub. 2022/0129261), and further in view of Sahu (US Pub. 2024/0330455).
With respect to Claim 7, modified Larmuseau teaches the method of claim 1, but does not explicitly teach backward slicing.
Sahu, however, does teach further comprising performing a backward slicing technique on at least a portion of the combined patch code property graph. (para. 93; system detects vulnerabilities using forward or backward slicing.)
It would have been obvious to one of ordinary skill prior to the effective filing date to combine the method of modified Larmuseau with the backward slicing in order to detect vulnerabilities. (Sahu, para. 93)
With respect to Claim 8, modified Larmuseau teaches the method of claim 1, but does not explicitly teach backward slicing.
Sahu, however, does teach further comprising performing a forward slicing technique on at least a portion of the combined patch code property graph. (para. 93; system detects vulnerabilities using forward or backward slicing.)
It would have been obvious to one of ordinary skill prior to the effective filing date to combine the method of modified Larmuseau with the forward slicing in order to detect vulnerabilities. (Sahu, para. 93)
With respect to Claim 16, modified Larmuseau teaches the apparatus of claim 11, but does not explicitly teach forward or backward slicing.
Sahu, however, does teach wherein the processor-executable instructions, when executed by the one or more processors, further cause the apparatus to perform one or more of a backward slicing technique or a forward slicing technique on at least a portion of the combined patch code property graph. (para. 93; system detects vulnerabilities using forward or backward slicing.)
It would have been obvious to one of ordinary skill prior to the effective filing date to combine the apparatus of modified Larmuseau with the forward slicing in order to detect vulnerabilities. (Sahu, para. 93)
Claim 9 is rejected under 35 U.S.C. 103(a) as being unpatentable over Larmuseau (US Pub. 2019/0238593) in view of Cabrera Lozoya (hereinafter “Cabrera”, US Pub. 2022/0129261), and further in view of Bezzi (US Pub. 2019/0347424).
With respect to Claim 9, modified Larmuseau teaches the method of claim 1, but does not explicitly teach a property graph in a numeric format.
Bezzi, however, does teach further comprising transforming the combined patch code property graph into a numeric format. (para. 45-46, 54; vectors are expressed in numbers)
It would have been obvious to one of ordinary skill prior to the effective filing date to combine the method of modified Larmuseau with the numeric format in order to weight parameters. (Bezzi, para. 45)
Remarks
Applicant argues at Remarks, pgs. 7-10 that the claims are not a judicial exception because they do not recite a mental process. Applicant argues that the claims cannot be practically performed in the mind.
Examiner disagrees. Claim 1 relevantly determines properties of pre-patched code and post-patched code, generates a combined patch code property graph, and determines a patch type using a trained machine-learning model. In other words, the claim commands observing and making a judgment about the type of change that a patch makes to code. Applicant provides no evidence, and Examiner does not believe it to be true, that understanding code and making a judgment as to the effect of changing code is something that cannot be practically performed in the mind. Examiner believes this to be the conventional mental process that a software engineer routinely engages in. Indeed, Applicant’s Background appears to admit that precisely this type of analysis was conventionally performed by human administrators, see Spec, paras. 3-5. Consequently, Examiner concludes these processes “are the equivalent of human mental work” because all they do is command the computer to perform the analysis a human would perform in their head, except “do it on a computer” using machine learning.
Applicant argues that a human mind cannot perform the receiving step and the determining step, but the receiving step is not identified as part of the mental process and the determining step – which now by amendment utilizes machine learning – is a mental process because “courts have examined claims that required the use of a computer and still found that the underlying, patent-ineligible invention could be performed via pen and paper or in a person’s mind.” (MPEP 2106.04(a)(2)(III)) Indeed, the alleged utility of the invention is that “[For] silent security patches, it is hard for users and system administrators to understand their real security impacts” and “it is vital to distinguish security patches from software patches designed for other purposes” (Spec, para. 4) and the mechanism by which the system does that is to utilize the computer as a tool to perform the mental process of observation. Therefore, the claims use a computer as tool to perform a mental process because the claims perform a parsing and comparison of data that could be performed by humans without a computer, see MPEP 2106.04(a)(2)(III)(C).
Applicant argues that the usage of a machine learning classifier makes the claims eligible. But the examples Applicant points to are inventions that improve machine learning-qua-machine learning, not inventions that merely apply machine learning without improving the field of machine learning.
Applicant argues that the claims integrate into a practical application. Applicant argues that Examiner failed to consider the additional elements, but Examiner considered the remaining receiving step and concluded that the claim as a whole does not improve a computer.
Examiner has some difficulty pinning down exactly what Applicant thinks is the integration because Applicant quotes standards and makes some sweeping generalizations that the claims meet the standards, but Applicant does directly make two statements Examiner highlights. Applicant states “[i]n the present case, improvements relate to the determination of types of software patches in order to allow for prioritization of patches related to software vulnerabilities.” But Applicant previously acknowledged that the determination steps were cited as part of the mental process (Remarks, pg. 9) and that the practical application analysis requires identification of “additional elements recited in the claim beyond the judicial exception.” (pg. 10) A judicial exception alone is not eligible subject matter, so the consideration of the claim as a whole requires analysis of how the additional elements interact with the exception, see MPEP 2106.04(d)(III). Applicant does not explain why receiving the software patch when considered together with the observation and judgment made by the determining steps causes an integration. Rather, as Examiner previously stated and again repeats, the receiving step is an insignificant pre-solution data gathering step – It does nothing more than acquire the thing to be observed. That is not a practical application.
Applicant further states “The present claims improve upon existing technical solutions to technical problems by address a technical problem that is concrete: evaluating software patched to identify which patches are security related software patches in order to prioritizes those patches for installation.” This argument fails at least for the reason that it is not commensurate with the scope of the claims. The claims do not require a plurality of patches or a plurality of categorizations. The claims do not require placing two patches into different categorizations. The claims do not require installing any patch. The claims do not require installing the patches in a particular order based on a particular categorization. Nor, relevantly, even if all of the above were changed, would the claims identify a particular means for determining which patches would be classified as security patches, nor would it effectuate a change based on the determination. In other words, assuming arguendo that there is a technical problem in identifying security patches, it is not an eligible act to claim “determining, based on the combined patch code property graph, a [security classification] for the software patch” because (1) the claims merely command identifying something rather than actually applying the knowledge to cause a system that uses the described invention to be secured more quickly, and (2) “[a]n important consideration in determining whether a claim improves technology is the extent to which the claim covers a particular solution to a problem or a particular way to achieve a desired outcome, as opposed to merely claiming the idea of a solution or outcome.” (MPEP 2106.05(a)) Notably, in different embodiments of the claim, the exact same patches could be determined to be both security and non-security patches, which means in different embodiments of the claim the patches could be both prioritized and de-prioritized. This is because the claim does not limit what properties result in a classification that the patch is a security patch. Examiner fails to see how Claim 1 can “improve a computer” when it is infringing of different embodiments of the claim to classify the same underlying patch data as either a security patch or a non-security patch. Examiner fails to see how Claim 1 can “improve a computer” when - even assuming the computing device made intelligent classifications - the actual functioning of the computer is not changed absent a requirement to install a first patch immediately and to wait to install another patch based upon the classifications.
In other words, Examiner agrees that on some particular level, a claim that (1) identifies a pre-patch code state, (2) identifies a post-patch code state, (3) determines a change due to the patch, and (4) makes a connection between particular patch changes and a prioritization of installation compared to patches that do not include those changes would be a strong argument for the claims improving a computer. Examiner agrees generally with the concept that a claim that improves the speed of security patching is the type of action that would fall under the classification of improving a computer and therefore be eligible. But the instant claims do not do that. The result of performing the method of Claim 1 is that the system will have a categorization (a patch type) of a received software patch. Applicant identifies no computer function that is improved merely by possessing such a categorization, and Applicant’s argument is essentially that “Once one of skill has this categorization, if they performed other, unclaimed acts, they would improve a computer.” Applicant does not persuasively cite to authority that a claim may be eligible based upon unclaimed acts. To the contrary, the MPEP states that “the claim must be evaluated to ensure the claim itself reflects the disclosed improvement in technology.” (MPEP 2106.05(a))
Applicant next argues that the determining steps amount to “significantly more.” The analysis is unpersuasive because it considers the ineligible subject matter under the significantly more test, when the test is directed to other features.
Examiner maintains the 101 rejection to all claims.
Applicant argues at Remarks, pgs. 14-16 that Claims 18-20 do not invoke means plus. Applicant appears to acknowledge that “device for” is a generic nonce term that invokes 112f, (citing MPEP 2181(I)(A)) but argues “In contract, claims 18-20 recite ‘a second computing device configured to’…” (Emphasis in original)
The next MPEP section, MPEP 2181(I)(B), states “Typically, the claim limitation will use the linking word ‘for’ to associate ‘means’ or a generic placeholder with the function. However, other linking words may be used, such as ‘so that’ or ‘configured to’, provided it is clear that the claim element is reciting a function.” Consequently, the argument that “configured to” instead of “for” means 112f is not invoked is unpersuasive.
Applicant argues at Remarks, pgs. 16-17 that means-plus is not invoked because of Specification paras. 77-84, but even in the quoted section of para. 77 it explicitly states it is describing “non-limiting examples of a computing device 601.” Further, when the element being described is a special purpose computer, the “sufficient structure” to describe it includes an algorithm for performing the function, see MPEP 2181(II)(B). Consequently, even if “second computing device configured to” was limited by the specification to be “one or more computers configured to store one or more [modules]” (see Remarks, pg. 16, citing Spec, para. 77) that still would not be “a sufficiently definite means as the name for the structure that performs the function” because neither “one or more computers” or “[storages]” are structures that sufficiently describe the receive and determine functionality. Nor can Applicant point to devices “configured to” do things or “modules” as examples of structure, because MPEP 2181 identifies those terms as not imposing structural limitations.
Applicant argues at Remarks, pgs. 17-19 that “determining…a combined patch code property graph” is nonobvious. Applicant acknowledges that “Cabrera teaches a graph of pre-change source code may be created and a graph of post-change source code may be created.” (Remarks, pg. 19)
Applicant merely alleges patentability. The combined patch code graph may be nothing more than a merging of the pre- and post-patch code graph. See Spec, paras. 35, 43; “For example, the intermediate complete patchCPG is a data structure constructed by merging the CPGs 218, 220 of pre-patch 206 and post-patch 208 source code.” Applicant appears to admit that the prior art teaches the two graphs, and Examiner found that renders the combined graph obvious because the combined graph is simple combination of the pre-/post- graphs, see Non-Final, pg. 7. Applicant makes no argument against the obviousness of the feature, Applicant merely argues that Cabrera does not anticipate. This is not an anticipation rejection.
Moreover, Cabrera anticipates. Applicant acknowledges that Cabrera teaches “a graph of pre-change source code may be created and a graph of post-change source code may be created,” which is a combined graph. The specification does not define the graph as being an integrated dataset (“For example, the [combined graph]…is a data structure constructed by merging…”) and therefore possessing both the pre- and post- graphs is possessing a combined graph. In other words, if a merged dataset (i.e. possessing data within a single file) is an exemplary embodiment of the claim feature, an aggregated dataset (i.e. possessing data within two files) is an embodiment that falls within the broadest reasonable interpretation of the term. Applicant admits that the Cabrera system possesses both graphs.
Applicant further does not dispute that Sahu teaches slicing techniques but argues at Remarks, pg. 19 that Sahu does not cure any deficiency. This is flatly contradicted by the specification and claims. Spec, para. 99 states “the combined patchCPG may be the intermediate complete patchCPG 224 or the patchCPG 228 of Fig. 2.” But 228 in Fig. 2 is described as what results from performing slicing on a data structure which contains the Pre- and Post-patch CPGs. In other words, even if the intermediate complete patchCPG was not anticipated by Cabrera, Applicant either agrees or at least does not dispute that the Pre- and Post-patch CPGs existed, the slicing techniques existed, and the motivation for applying the slicing techniques to the data existed. Consequently, even if Spec, Fig. 2, element 224 was not obvious, the combination of teachings would render Spec, Fig. 2, element 228 obvious, and Spec, para. 99 explicitly states that 228 is a species of the disputed claim element. Consequently, Sahu would cure any deficiency if one existed.
Finally, Applicant argues at Remarks, pg. 20 that the amended determining, using a machine learning model is nonobvious. This argument appears to be commensurate with the combined patch code property graph argument above. Examiner previously cited machine learning with respect to Claim 10, and although the instant amended claim language is different, Applicant does not raise argument as to why the machine learning teaching (together with an additional citation for training the model, ante) would not render the amended claim obvious.
The new claims are taught above. All claims are obvious.
All claims remain rejected.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee 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 NICHOLAS P CELANI whose telephone number is (571)272-1205. The examiner can normally be reached on M-F 9-5.
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, Vivek Srivastava can be reached on 571-272-7304. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/NICHOLAS P CELANI/Examiner, Art Unit 2449
Prosecution Insights