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 .
DETAILED ACTION
This is in response to the amendment filed on 6/30/26. Claims 16-33 and new claims 34-37 are presented for examination.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
Claim(s) 16, 17 and 20-37 are rejected under 35 U.S.C. 103 as being unpatentable over Karas et al., US Pub. No.20230185921 in view of Korotaev, US Pun. No.20210026974.
As to claim 16, Karas discloses a computer-implemented method for automatically
generating a patch of software or of a part of the software, wherein the software is configured to control and/or regulate and/or monitor a technical system or a part of the technical system, the method comprising:
generating, via a machine learning model, at least one patch for a vulnerability
of the software or the part of the software based on a prompt and a binary code of the
software or the part of the software (configuring to disassemble the binary into code
patches of functionality, versions, libraries, or the like, which can be matched against
publicly known vulnerabilities databases, privately retained vulnerabilities lists in, or the
like in software versions by using a machine learning module, see [0045] to [0046]).
Karas does not specifically disclose at least one patch is binary code which replaces part of the software and wherein the prompt including a natural language instruction to the machine learning model which includes a request to generate the at least one patch for the vulnerability in the binary code of the software or part of the software. However, Korotaev discloses at least one patch is binary code which replaces part of the software and wherein the prompt including a natural language instruction to the machine learning model which including a request to generate the at least one patch for the vulnerability in the binary code of the software or part of the software (producing the resulting file with optionally the original binary code for the honeypot update (which may address the software vulnerability if applied to vulnerable versions of the software and adds detection capability) in the very same file, including the information about which original code blocks should be replaced with new ones ,see [0043]). It would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention was made to implement Korotaev’s teachings into the computer system of Karas to control data information because it would have configured to detect attempts to exploit a software vulnerability is merged with the original source code of the software to form modified source code (see Korotaev’s [0042]).
As to claim 2, Karas discloses a foundation model and/or a large language model (LLM) (see [0045]). Karas does not specifically disclose the MLM is prompt with the prompt and output is binary code is at least one patch which is applied to the binary code of the software or part of the software. Korotaev discloses the MLM is prompt with the prompt and output is binary code is at least one patch which is applied to the binary code of the software or part of the software (producing the resulting file with optionally the original binary code for the honeypot update (which may address the software vulnerability if applied to vulnerable versions of the software and adds detection capability) in the very same file, including the information about which original code blocks should be replaced with new ones ,see [0043]). It would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention was made to implement Korotaev’s teachings into the computer system of Karas to control data information because it would have configured to detect attempts to exploit a software vulnerability is merged with the original source code of the software to form modified source code (see Korotaev’s [0042]).
As to claim 20, Karas discloses decompiling the binary code, wherein a decompiled code, including: (i) an intermediate representation of the binary code and/or (ii) a machine code and/or (iii) an assembly code, is a result of the decompiling, wherein the generating of the at least one patch is based on the decompiled code (binary including source code processing, see [0083] to [0084]).
As to claim 21, Karas discloses finding the vulnerability based on the binary code binary code controlling, (see [0045]). Karas does not specifically disclose wherein the finding of the vulnerability includes ascertaining one or more locations in the binary code of the software and wherein the prompt including one or mode locations of the vulnerability. Korotaev discloses wherein the finding of the vulnerability includes ascertaining one or more locations in the binary code of the software and wherein the prompt including one or mode locations of the vulnerability (producing the resulting file with optionally the original binary code for the honeypot update (which may address the software vulnerability if applied to vulnerable versions of the software and adds detection capability) in the very same file, including the information about which original code blocks should be replaced with new ones and the resulting file can be an object file (e.g., a Linux ELF file or some other platform-specific object file) with relocations information and sections, see [0043]). It would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention was made to implement Korotaev’s teachings into the computer system of Karas to control data information because it would have configured to detect attempts to exploit a software vulnerability is merged with the original source code of the software to form modified source code (see Korotaev’s [0042]).
As to claim 22, Karas discloses the finding of the vulnerability is further based on an
attack test and/or a description of at least one known vulnerability (CVE lookup process
may be performed in order to identify vulnerabilities, see [0045]).
As to claim 23, Karas discloses evaluating the at least one patch, wherein an evaluation result is a result (patch evaluations, see [0045]). Korotaev discloses the software modified by at least one patch and wherein the evaluation reflects whether the vulnerability is eliminated and whether the software modified by at least one patch is functionally correct (evaluating modified that variable, they will not be able to make use out of that variable because the patched code 201A no longer utilizes that original variable, see [0047] to [0048]). It would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention was made to implement Korotaev’s teachings into the computer system of Karas to control data information because it would have configured to detect attempts to exploit a software vulnerability is merged with the original source code of the software to form modified source code (see Korotaev’s [0042]).
As to claim 24, Karas discloses wherein the evaluating of the at least one patch
includes:
(i) a static test of the software modified by the patch or of the part of the software
modified by the patch (evaluating the impact of given CVE on the device using static
analysis, dynamic analysis, utilization of a Machine Learning based predictor, using
Deep Learning, see [0030] to [0031]), and/or
(ii) a dynamic test of the software modified by the patch or of the part of the
software modified by the patch, and/or
(iii) an attack test of the software modified by the patch or of the part of the
software modified by the patch, and/or
(iv) a comparison test which is configured to compare the software or the part of
the software with the software modified by the patch or with the part of the software
modified by the patch, wherein it is checked whether the software or the part of the
software with the software modified by the patch or with the part of the software
modified by the patch are identical in terms of functionality, and/or
(v) a non-functional test of the software modified by the patch or of the part of
the software modified by the patch, wherein the non-functional test tests performance
and/or runtime and/or memory requirement of the software modified by the patch; and
wherein the evaluation result is determined according to a predetermined
criterion from results of one or more of these tests.
As to claim 25, Karas discloses the at least one patch is released when the evaluation
result is positive (each contextual factor that was identified may be assigned a
relevance score for a CVE in a canonical form, see [0070] to [0071]). Korotaev discloses wherein the evaluation is positive the at least one patch is released and the software modified by the at least one patch is released for distribution (see [0043] to [0047]). It would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention was made to implement Korotaev’s teachings into the computer system of Karas to control data information because it would have configured to detect attempts to exploit a software vulnerability is merged with the original source code of the software to form modified source code (see Korotaev’s [0042]).
As to claim 26, Karas discloses the method is repeated when the evaluation result is
negative (each contextual factor that was identified may be assigned a relevance score
for a CVE in a canonical form, see [0070] to [0071]).
As to claim 27, Karas discloses at least one further patch is generated based on the at
Least one patch wherein the prompt for performing of the method includes at least one patch and a request to improve with regard to the evaluation (see [0070] to [0074]).
As to claim 28, Karas discloses computer-implemented method for further training a
machine learning model, wherein the machine learning model is configured to generate
at least one patch for a vulnerability of software or a part of the software based on a
prompt and a binary code of the software or the part of the software, the method
comprising:
adapting the machine learning model based on at least one patch generated by:
generating, via the machine learning model, the at least one patch for a vulnerability of
the software or the part of the software based on a prompt and a binary code of the
software or the part of the software, evaluating the at least one patch, wherein an
evaluation result is a result, adapting the machine learning model based on the result of
the evaluating (configuring to disassemble the binary into code patches of functionality,
versions, libraries, or the like, which can be matched against publicly known
vulnerabilities databases, privately retained vulnerabilities lists in, or the like in software
versions by using a machine learning module, see [0045] to [0046]). Karas does not specifically disclose at least one patch is binary code which replaces part of the software and wherein the prompt including a natural language instruction to the machine learning model which includes a request to generate the at least one patch for the vulnerability in the binary code of the software or part of the software. However, Korotaev discloses at least one patch is binary code which replaces part of the software and wherein the prompt including a natural language instruction to the machine learning model which including a request to generate the at least one patch for the vulnerability in the binary code of the software or part of the software and whether the software modified by at least one patch is functionally correct (producing the resulting file with optionally the original binary code for the honeypot update (which may address the software vulnerability if applied to vulnerable versions of the software and adds detection capability) in the very same file, including the information about which original code blocks should be replaced with new ones and evaluating modified that variable, they will not be able to make use out of that variable because the patched code 201A no longer utilizes that original variable, see [0043 ] and [0047] to [0048]). It would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention was made to implement Korotaev’s teachings into the computer system of Karas to control data information because it would have configured to detect attempts to exploit a software vulnerability is merged with the original source code of the software to form modified source code (see Korotaev’s [0042]).
As to claim 29, Karas discloses calculating at least one reward based on the evaluation
result; wherein the adapting the machine learning model based on the evaluation result
is based on the at least one reward (device-specific list of vulnerabilities may be
provided, generated, determined, or the like, according to the combined relevance score
of each CVE, see [0072] to [0073]).
As to claim 30, Karas discloses the at least one reward is greater when the at least one
evaluation result is better, and wherein the at least one reward is lower when the at
least one evaluation result is worse reward (device-specific list of vulnerabilities may be
provided, generated, determined, or the like, according to the combined relevance score
of each CVE, see [0072] to [0073]).
As to claim 31, Karas discloses the adapting of the machine learning model is based on
proximal policy optimization and when adapting of the machine learning model including weights of the MLM (analyzing the System Image 315 in order to identify contextual factors of the underlying system such as properties, attributes, configurations, or the like, that can prevent exploitation of vulnerabilities, mitigate exploitation of vulnerabilities, increase a risk of exploitation of vulnerabilities, see [0086]
to [0088]).
As to claim 32, Karas discloses a computer system configured to:
(i) automatically generate a patch of software or of a part of the software, wherein the software is configured to control and/or regulate and/or monitor a technical system or a part of the technical system, the automatic generating including generating, via a
machine learning model, at least one patch for a vulnerability of the software or the part
of the software based on a prompt and a binary code of the software or the part of the
software (configuring to disassemble the binary into code patches of functionality,
versions, libraries, or the like, which can be matched against publicly known
vulnerabilities databases, privately retained vulnerabilities lists in, or the like in software
versions by using a machine learning module, see [0045] to [0046]); and/or
(ii) train the machine learning model, including adapting the machine learning model
based on at least one patch generated by:
generating, via the machine learning model, the at least one patch for a vulnerability of
the software or the part of the software based on a prompt and a binary code of the
software or the part of the software, evaluating the at least one patch, wherein an
evaluation result is a result, adapting the machine learning model based on the result of
the evaluating.
Karas does not specifically disclose at least one patch is binary code which replaces part of the software and wherein the prompt including a natural language instruction to the machine learning model which includes a request to generate the at least one patch for the vulnerability in the binary code of the software or part of the software. However, Korotaev discloses at least one patch is binary code which replaces part of the software and wherein the prompt including a natural language instruction to the machine learning model which including a request to generate the at least one patch for the vulnerability in the binary code of the software or part of the software (producing the resulting file with optionally the original binary code for the honeypot update (which may address the software vulnerability if applied to vulnerable versions of the software and adds detection capability) in the very same file, including the information about which original code blocks should be replaced with new ones ,see [0043]). It would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention was made to implement Korotaev’s teachings into the computer system of Karas to control data information because it would have configured to detect attempts to exploit a software vulnerability is merged with the original source code of the software to form modified source code (see Korotaev’s [0042]).
As to claim 33, Karas discloses a non-transitory computer-readable medium on which is
stored a computer program, the computer program, when executed by a computer
system, causing the computer system to perform the following steps:
(i) automatically generate a patch of software or of a part of the software, wherein the
software is configured to control and/or regulate and/or monitor a technical system or a
part of the technical system, the automatic generating including generating, via a
machine learning model, at least one patch for a vulnerability of the software or the part
of the software based on a prompt and a binary code of the software or the part of the
software (configuring to disassemble the binary into code patches of functionality,
versions, libraries, or the like, which can be matched against publicly known
vulnerabilities databases, privately retained vulnerabilities lists in, or the like in software
versions by using a machine learning module, see [0045] to [0046]); and/or
(ii) train the machine learning model, including adapting the machine learning model
based on at least one patch generated by: generating, via the machine learning model,
the at least one patch for a vulnerability of the software or the part of the software based
on a prompt and a binary code of the software or the part of the software, evaluating the
at least one patch, wherein an evaluation result is a result, adapting the machine learning model.
Karas does not specifically disclose at least one patch is binary code which replaces part of the software and wherein the prompt including a natural language instruction to the machine learning model which includes a request to generate the at least one patch for the vulnerability in the binary code of the software or part of the software. However, Korotaev discloses at least one patch is binary code which replaces part of the software and wherein the prompt including a natural language instruction to the machine learning model which including a request to generate the at least one patch for the vulnerability in the binary code of the software or part of the software (producing the resulting file with optionally the original binary code for the honeypot update (which may address the software vulnerability if applied to vulnerable versions of the software and adds detection capability) in the very same file, including the information about which original code blocks should be replaced with new ones ,see [0043]). It would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention was made to implement Korotaev’s teachings into the computer system of Karas to control data information because it would have configured to detect attempts to exploit a software vulnerability is merged with the original source code of the software to form modified source code (see Korotaev’s [0042]).
As to claim 34, Karas discloses the at least one patch is generated without access to source code of the software (see [0070] to [0074]).
As to claim 35, Korotaev discloses wherein the prompt further includes the binary code of the software or the part of the software at the one or more locations of the vulnerability (producing the resulting file with optionally the original binary code for the honeypot update (which may address the software vulnerability if applied to vulnerable versions of the software and adds detection capability) in the very same file, including the information about which original code blocks should be replaced with new ones and the resulting file can be an object file (e.g., a Linux ELF file or some other platform-specific object file) with relocations information and sections, see [0043]). It would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention was made to implement Korotaev’s teachings into the computer system of Karas to control data information because it would have configured to detect attempts to exploit a software vulnerability is merged with the original source code of the software to form modified source code (see Korotaev’s [0042]).
As to claim 36, Karas modifying the software based on the at least one generated patch and executing in the technical system the software modified by the at least one generated patch (see [0070] to [0074]).
As to claim 37, Karas disclose evaluating the at least one patch including testing the software modified by the patch or of the part of the software modified by the patch, wherein the testing tests performance (see [0070] to [0076]) and/or runtime and/or memory requirement of the software modified by the patch or of the part of the software modified by the patch.
Claim(s) 18 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over
Karas and Korotaev as in above and in view of lyer et al., US Pub. No.20210056210.
As to claims 18 and 19, Karas and Korotaev' teachings still applied as in item 6 above. Neither Karas nor Korotaev specifically discloses the software is configured to be executed in a cyber-physical system, including at least one computing unit of: a vehicle, or a robot, or an industrial plant and configured for a safety-critical task including: a perception task and/or autonomous movement However, lyer discloses that the software is configured to be executed in a cyber-physical system, including at least one
computing unit of: a vehicle, or a robot, or an industrial plant and configured for a
safety-critical task including: a perception task and/or autonomous movement (car
movements, see [0019]) and/or powering and/or braking and/or airbag control
(identifying and processing vulnerabilities in the binary code as well as the original
source code in a car, see [0019] and [0027]). It would have been obvious to one of the
ordinary skill in the art before the effective filing date of the invention was made to
implement lyer's teachings in the computer system of Karas to control data information
because it would have increased reliability and quality while maintaining the
optimization of the original source code in a communication network (see lyers' [0018]).
Response to Arguments
Applicant’s arguments, see filed 6/30/26, with respect to the rejection(s) of claim(s) 16-37 under 35 USC 102 and 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Korotaev, US Pub. No.20210126974.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Khanh Dinh whose telephone number is (571) 272-3936. The examiner can normally be reached on Monday through Friday from 8:00 A.m. to 5:00 P.m.
If attempts to reach the examiner by telephone are unsuccessful, the examiner's
supervisor, Umar Cheema, can be reached on (571) 270-3037. The fax phone number
for this group 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).
Any response to this action should be mailed to:
Commissioner for patents
P O Box 1450
Alexandria, VA 22313-1450
/KHANH Q DINH/Primary Examiner, Art Unit 2458
Prosecution Insights