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 Arguments
Applicant's arguments filed May 22, 2026 have been fully considered but they are not persuasive.
In page 1 of the remarks, claims 1-7 and 15-20 were rejected under §112(a) for allegedly lacking written description support for the recitation of multiple thresholds. Applicant has amended the claims to remove the ‘ordinal modifiers’ and recite threshold language that is consistent with the original disclosure, in particular, that an expression is filtered as a false positive when an occurrence count or the method usage index does not exceed said threshold. Applicant requests withdrawal of the 112(a) rejections. Examiner states that as the limitations that have been rejected under 112(a) have been removed in the amendments, the 112(a) rejections have been withdrawn.
In pages 2-3 of the remarks, the claims were rejected under 35 U.S.C. §103 in view of combinations including “Smith 389” (US 2020/0097389 A1), Barr Group (“How and When to Use C’s assert() Macro”, NPL), “Smith 446” (US 2020/0117446 A1), and additional references such as Li, Vaswani, Alt, and Hu. Applicant states that the amended limitations added to independent claim 1, as well as those from dependent claim 9 overcome the rejections made by the primary reference of Smith 389. These include the limitations of “mining a codebase to identify macro definitions that accept error codes or corresponding types”, “performing a first pass that selectively identifies macros in which an error-code parameter alters program flow”, a requirement “that positive training samples are generated specifically from expressions passed to macros that satisfy both stages of filtering”, among other limitations added to the claims. Applicant further states that Smith 389 “is directed to extracting features from source code and using those features to train models that predict errors”, as stated in page 2 of the remarks, and that the claims require constructing a specific set of signals through a defined sequence where macro definitions are first collected, then filtered based on if the parameters alter control flow, with a second procedure that depends on relationships between macros in the first procedure. Next, in pages 3-4 of the remarks, Applicant states that Barr Group’s assert-style macros for “validating conditions and altering program execution” does not teach the amended limitations present in claim 1 when taught in conjunction with Smith 389. Applicant also asserts that Smith 446 describes code search and ranking mechanisms based on similarity and usage metrics, but does not disclose generating training data from macros selected through a dependency-based filtering process or applying a method usage index as a post-classification filter within a vulnerability detection workflow, Li relates to version management and file matching, Vaswani and Alt describe transformer architectures and training techniques, and Hu describes software quality prediction. Applicant states that these references address different aspects of software processing and not suggesting a sequence of macro-based signals being used to generate training data, nor do they modify Smith 389 to establish a ‘dependency-driven macro filtering process that governs the formation of training data’. Applicant respectfully requests withdrawal of the rejections under § 103 and reconsideration of the claims for allowance.
Examiner states that the limitations that have been added in the amendments are provided in the existing prior art from the previous Office Actions. The limitation of “add the first error-checking macro to a list of candidate macro definitions” is provided by the section of Smith 389: [0057] Fig. 7, block 706, where the breaking code, fixing code, and information about an error are saved and associated, corresponding to a first error-checking macro being added to a list of candidate macro definitions, where the association with the code and the error information are saved as well, corresponding to a first error-checking macro added to a list of candidate macro definition. Barr Group describes, in page 3, “if the expression passed to the macro [i.e., assert()] is false [i.e., an error], output an error message that includes the file name and line number, and then exit”. This teaches the use of an error code with the error-checking macro, as well as altering the flow of the source code program (i.e., exiting the program based on the value of the code, where the flow of the code can be altered if errors are detected by the error-checking macros. Next, the limitation of “in a second pass, determine that a second error-checking macro […] makes a call to the first error-checking macro” is described in Smith 389 describes the monitoring of an execution of a program, where errors may be detected, as described above [i.e., “[0057] describes how the execution of a program is monitored, where the monitoring system may detect a thrown error, exception, or corresponding error code. Some errors may be attributed to a breaking change, which can cause breaking of the program.”], where the execution of the error causes changes in the execution of the program, invoked in Smith 389: a lack of an error code may indicate that the program is error-free, or a return code may be used to indicate the correct execution of the program. Next, the limitation of “wherein generating the positive training samples further comprises assigning a binary label indicating a software vulnerability to each extracted expression” is described in the reference of Smith 389: [0053] describes how errors in the source code (i.e., vulnerabilities) may be labeled and classified by an error classification system, where the examples may contain an error indication, error content, and optionally an error type label for the error indication. Examiner maintains the rejections previously recited, with claims 1-3, 6, 21-25, and 27-34 are rejected under 35 U.S.C. 103 as being unpatentable over Smith 389 in view of Barr Group, further in view of Smith 446.
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.
Claim(s) 1-3, 6, 21-25, and 27-34 are rejected under 35 U.S.C. 103 as being unpatentable over Smith et al (US 2020/0097389 A1), hereinafter Smith 389, in view of Barr Group (“How and When to Use C’s assert() Macro”, 2001), and Smith et al (US 2020/0117446 A1), hereinafter Smith 446.
Regarding Claim 1, Smith 389 discloses “A system comprising: a processor; and a memory that stores instructions that are executable by the processor to cause the system to: receive a source code file having an expression” (Smith 389: Figure 11 depicts an exemplary system to implement the methods taught in the reference, including memory (reference character 1106) and processor (reference character 1102). [0007] describes how source code may be provided, where a plurality of features are extracted, such as expressions used in said source code);
“wherein the source code file is associated with a codebase, which is associated with a program” (Smith 389: [0030] describes how the source code may be stored in some form of code storage, which may comprise a codebase.);
“wherein the codebase includes a plurality of files” (Smith 389: [0030] describes how the aforementioned codebase may comprise a code repository, which keeps track of all changes and versions of all code files in the repository);
“mine the code base to identify a first macro having a first parameter that accepts a first error code, wherein the first macro is categorized as being a first error-checking macro, and wherein the first macro is identified from a first header file of the plurality of files” (Smith 389: [0057] describes how the execution of a program is monitored, where the monitoring system may detect a thrown error, exception, or corresponding error code. Some errors may be attributed to a breaking change, which can cause breaking of the program. The lack of an error code may indicate that the program is error-free, or a return code may be used to indicate the correct execution of the program. Barr Group: page 3, “if the expression passed to the macro [i.e., assert()] is false [i.e., an error], output an error message that includes the file name and line number, and then exit”. This teaches the use of an error code with the error-checking macro, as well as altering the flow of the source code program (i.e., exiting the program based on the value of the code.);
“add the first error-checking macro to a list of candidate macro definitions” (Smith 389: [0057] Fig. 7, block 706, where the breaking code, fixing code, and information about an error are saved and associated, corresponding to a first error-checking macro being added to a list of candidate macro definitions.);
“in a first pass, determine that the first parameter of the first error-checking macro alters a flow of the program and add the first error-checking macro to a candidate signal list” (Barr Group: page 3, “if the expression passed to the macro [i.e., assert()] is false [i.e., an error], output an error message that includes the file name and line number, and then exit”. This teaches the use of an error code with the error-checking macro, as well as altering the flow of the source code program (i.e., exiting the program based on the value of the code).);
“in a second pass, determine that a second error-checking macro, which is included in the list of candidate macro definitions, makes a call to the first error-checking macro, which is included in the candidate signal list” (Barr Group discusses the use of multiple versions of the assert() macro. Smith 389 describes the monitoring of an execution of a program, where errors may be detected, as described above [i.e., “[0057] describes how the execution of a program is monitored, where the monitoring system may detect a thrown error, exception, or corresponding error code. Some errors may be attributed to a breaking change, which can cause breaking of the program. The lack of an error code may indicate that the program is error-free, or a return code may be used to indicate the correct execution of the program”].);
“add the second error-checking macro to the candidate signal list” (Smith 389: [0057] Fig. 7, block 706, where the breaking code, fixing code, and information about an error are saved and associated, corresponding to a second error-checking macro being added to a list of candidate macro definitions.);
“use macros in the candidate signal list to generate positive training samples reflective of possible software vulnerabilities” (Smith 389: [0064] Fig. 8, process 800 receives a code sample containing an error, which is input into a machine learning model, and then returns corrected code. Step 801 states that code sample contains error information, which allows for samples reflective of possible software vulnerabilities.);
“cause a neural classifier given the expression, to determine that the expression has a software vulnerability” (Smith 389: [0037] describes how a neural network may be used as a machine learning model for code analysis. [0044] (and Figure 2B) show the use of said machine learning model (i.e., neural classifier) to perform inference on an input (i.e., source code containing expression(s)). The machine learning model generates some output which comprises information such as predicted errors (i.e., vulnerabilities), predicted fix, or other data.);
“wherein the neural classifier is trained, based on the positive training samples reflective of the possible software vulnerabilities, to identify the software vulnerability” (Smith 389: [0036], which recites “Machine learning model 200 may be, for example, a neural network…”, and [0051], which recites “For example, a RNN, CNN, or other machine learning algorithm capable of reading sequence data may be applied to the communication channels and trained to identify messages that indicate errors”; [0065], which states “The training data generator may create additional training examples comprising corresponding sets of code samples with errors, additional error information, and corrected code”. As understood by one of ordinary skill in the art, a machine learning model (such as a neural classifier) ingests training data and uses it to perform an action, such as identifying or classifying error-riddled code.);
“determine that the expression is not a false positive when a number of occurrences of the expression in the codebase exceeds a threshold number of occurrences” (Smith 389: [0055] describes how no error may be predicted if the error probability falls below a certain threshold value. This implies that an error will be predicted if the probability exceeds said threshold value. [0055] “the error prediction may comprise a probability that an error will occur and an identification of the type of the likely error”. This error prediction is based on the input of code (i.e., “[t]he code portion may comprise a few lines of code, a class or method definition, an entire file, an entire project of multiple related files, or other code portions”, [0055]), which would include the code expression in question that may contain the error. The error prediction probability is based upon on the input of these code expressions, and corresponds to a first threshold of at least one expression not being a false positive. Presence of an error in a code expression corresponds to an expression not being a false positive.)
“search the plurality of files of the codebase for occurrences of the expression outside of the error-checking macros” (Smith 389: [0051] describes how rule-based heuristics may be used in the machine learning model to evaluate error status. Source code is searched for keywords (i.e., keywords of expressions) or evaluating some other component of the source code to determine error occurrences and error context. [0051] additionally states that communication channels are monitored for potential error events, where these may comprise “a stream such as standard output or standard error, a local log file or remote server log file, a mechanism for viewing program execution state such as an application profiler, thread dump, heap dump, or stack trace, or another communication channel”);
“assemble a plurality of repair code candidates from occurrences of the expression found in the codebase” (Smith 389: [0079] describes how predicted fixes are assembled and presented to the user);
“and output the plurality of repair code candidates as suggestions to fix the potential software vulnerability” (Smith 389: [0076] describes how a user console is provided to the user, with errors and fixes to said errors are presented to the user. The code fixes are presented to a user in the form of a dialog box).
Smith 389 teaches the above subject matter content, but fails to expressly disclose an error-checking macro. However, analogous art from the same field of endeavor, Barr Group, teaches this: “The assert() macro is used to check expressions that ought to be true as long as the program is running correctly”. In the C programming language, the assert() macro is used to ensure whether a software expression, passed as an argument, is free of error (i.e., returns “true”). If there is a fault in the expression, then the assert() function returns a value of “false” (Barr Group, pg. 3 of attached document).
Therefore, based on Smith 389 in view of Barr Group, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of error-checking macros of Barr Group to the system of Smith 389 in order to provide a convenient, effective way to insert a “sanity check” when writing code (Barr Group, pg. 3 of attached document). By integrating these “sanity checks” into written code, it lessens the time and effort required when attempting to identify potential software vulnerabilities and errors.
Smith 389 and Barr Group fail to expressly disclose, but Smith 446 teaches the limitation of “calculate a method usage index for a method used in the expression, wherein the method usage index is based on a number of uses of the method used in the expression in the error-checking macros in the plurality of files of the codebase and a number of times the method used in the expression is used in the codebase” (Smith 446: [0109] describes how a set of code entities may be returned to a user following some search. Usages of these code entities may be calls to a function (i.e., methods), and are returned to the user. These code snippets (containing the code entities) are indexed according to an indexing method, as described in [0112]. [0109], which states “the search results may further include usages of the code entities or links to usages of the code entities….in addition to returning a code entity as a responsive search result, a collections of various usages of that code entity including a snippet of context may also be returned as a part of the search results….usages may include calls to a function, use as a parameter, use in an expression or statement, use in an assignment, or other uses”. [0112] states “A database or corpus of code snippets is first indexed according to one or more indexing methods as described above. a user may then execute search queries against the database to search for code snippets according to a search query”. [0138] describes how the frequency or count of usages of a particular term (i.e., method/expression) is recorded for a corpus of code. These are scored based on their reputation or popularity of use and search. [0138] recites “code entities and code snippets are scored based on the number of occurrences or the context of occurrence in different codebases”. [0140] recites “a code entity or code snippet may be ranked according to the context provided by a local development environment. for example, code entities or code snippets may be scored based on appearing in a similar context in their codebase or usage context or may be scored based on having similar code to the programmer’s current development environment… a presence or absence of code entities or code snippets in a user’s local code repository may be used to rank search results”. The recitations cited above in Smith449 describe ranking the search results based on the usage of the specified method.).
and “the method usage index for the method associated with the expression exceeds a threshold corresponding to the method usage index” (Smith 446: [0118] Fig. 11, step 1104, Code snippet embeddings within threshold distance of a search query is selected as responsive to the search query. [0095] Fig. 7, similarity measure 705 measures distance (also known as similarity) between embeddings, and in combination with the search query of paragraph [0118] of Smith 446, which states that similarity of the search query and code snippets within a certain distance as considered as responsive to the search query, corresponding to at least one expression exceeding a second threshold, which is measured by similarity in Smith 446.).
Therefore, based on Smith 389 in view of Barr Group, and in further view of Smith 446, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of a method usage index of Smith 446 to the system of Smith 389 and Barr Group in order to provide access to code entities and use machine learning models to analyze these code entities (Smith 446, [0008]). By using specific algorithms for usage analysis, it provides an effective, quick way for a developer to identify potentially vulnerable functions.
Regarding Claim 2, Smith 389 in view of Barr Group and Smith 446 teaches the limitations recited in claim 1 above. Smith 389 further discloses “The system of claim 1, wherein the one or more programs include instructions that perform acts to: determine that the at least one expression is a false positive when a number of occurrences of the at least one expression in the codebase is less than the first threshold” (Smith 389: [0055] describes how no error may be predicted if the error probability falls below a certain threshold value, corresponding to at least one expression is a false positive when a number of occurrences is less than the first threshold. [0055] “the error prediction may comprise a probability that an error will occur and an identification of the type of the likely error”. This error prediction is based on the input of code (i.e., “[t]he code portion may comprise a few lines of code, a class or method definition, an entire file, an entire project of multiple related files, or other code portions”, [0055]), which would include the code expression in question that may contain the error. The error prediction probability is based upon on the input of these code expressions.).
Regarding Claim 3, Smith 389 in view of Barr Group and Smith 446 teaches the limitations recited in claim 1 above. Smith 389 further discloses “The system of claim 2, wherein the one or more programs include instructions that perform acts to: determine that the at least one expression is a false positive a number of occurrences of the at least one expression in the codebase exceeds the first threshold” (Smith 389: [0055] describes how no error may be predicted if the error probability falls below a certain threshold value. This implies that an error will be predicted if the probability exceeds said threshold value. The error prediction probability is based upon on the input of these code expressions, and corresponds to a first threshold of at least one expression not being a false positive. Presence of an error in a code expression corresponds to an expression not being a false positive.).
Smith389 in view of Barr Group does not appear to disclose, but Smith 446 teaches “and the method usage index is less than the second threshold” (Smith 446: [0118] Fig. 11, step 1104, Code snippet embeddings within threshold distance of a search query is selected as responsive to the search query. [0095] Fig. 7, similarity measure 705 measures distance (also known as similarity) between embeddings, and in combination with the search query of paragraph [0118] of Smith 446, which states that similarity of the search query and code snippets, corresponding to at least one expression exceeding a second threshold, which is measured by similarity in Smith 446. This implies that when similarity measure is not responsive to the search query in step 1104 of Fig. 11 in paragraph [0118], the method usage index is less than the second threshold, and the code snippet cannot be searched for.).
Therefore, based on Smith 389 in view of Barr Group, and in further view of Smith 446, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of a method usage index of Smith 446 to the system of Smith 389 and Barr Group in order to provide access to code entities and use machine learning models to analyze these code entities (Smith 446, [0008]). By using specific algorithms for usage analysis, it provides an effective, quick way for a developer to identify potentially vulnerable functions.
Regarding Claim 6, Smith 389 in view of Barr Group and Smith 446 teaches the limitations recited in claim 1 above. Smith 389 and Barr Group further discloses “The system of claim 1, wherein each of the plurality of repair code candidates includes an error-checking macro” (Smith 389: Para. 0069 describes how change sequence code (i.e., error-checking macro) may be determined from the machine learning model, where these sequences may be corrections to erroneous code; Barr Group: “The assert() macro is used to check expressions that ought to be true as long as the program is running correctly”. In the C programming language, the assert() macro is used to ensure whether a software expression, passed as an argument, is free of error (i.e., returns “true”). If there is a fault in the expression, then the assert() function returns a value of “false”).
Therefore, based on Smith 389 in view of Barr Group, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of error-checking macros of Barr Group to the system of Smith 389 in order to provide a convenient, effective way to insert a “sanity check” when writing code (Barr Group, pg. 3 of attached document). By integrating these “sanity checks” into written code, it lessens the time and effort required when attempting to identify potential software vulnerabilities and errors.
Regarding claim 21, Smith 389 in view of Barr Group and Smith 446 teaches the limitations recited in claim 1 above.
Regarding claim 22, Smith 389 in view of Barr Group and Smith 446 teaches the limitations recited in claim 1 above. Smith 389 further discloses “wherein mining the code base further comprises extracting macro definitions from header files of each source code program of the codebase” (Smith 389: [0057] describes how the execution of a program is monitored, where the monitoring system may detect a thrown error, exception, or corresponding error code. Some errors may be attributed to a breaking change, which can cause breaking of the program. The lack of an error code may indicate that the program is error-free, or a return code may be used to indicate the correct execution of the program.).
Regarding claim 23, Smith 389 in view of Barr Group and Smith 446 teaches the limitations recited in claim 1 above. Smith 389 further discloses “wherein generating the positive training samples comprises assigning a label indicating a software vulnerability to each expression used as an argument in a macro included in the candidate signal list” (Smith 389: [0064] Fig. 8, process 800 receives a code sample containing an error, which is input into a machine learning model, and then returns corrected code. Step 801 states that code sample contains error information, which allows for samples reflective of possible software vulnerabilities.);
“and generating negative training samples from expressions not included in the candidate signal list” (Smith 389: [0064] Fig. 8, process 800, step 803, code sample is returned with the error corrected, with the error expression removed from the sample in the list.);
Regarding claim 24, Smith 389 in view of Barr Group and Smith 446 teaches the limitations recited in claim 1 above. Smith 389 further discloses “wherein the neural classifier comprises a neural encoder transformer model that is pre-trained on an unsupervised dataset of source code samples and fine-tuned using the positive training samples” (Smith 389: [0036], which recites “Machine learning model 200 may be, for example, a neural network…”, and [0051], which recites “For example, a RNN, CNN, or other machine learning algorithm capable of reading sequence data may be applied to the communication channels and trained to identify messages that indicate errors”; [0065], which states “The training data generator may create additional training examples comprising corresponding sets of code samples with errors, additional error information, and corrected code”.).
Regarding claim 25, […] disclose/teach the above subject matter content, […] “wherein calculating the method usage index further comprises determining the method usage index as a ratio of a number of times the method is used in expressions of error-checking macros to a number of times the method is used in the codebase” (Smith 446 teaches this: [0109] describes how a set of code entities may be returned to a user following some search. Usages of these code entities may be calls to a function (i.e., methods), and are returned to the user. These code snippets (containing the code entities) are indexed according to an indexing method, as described in [0112]. [0109], which states “the search results may further include usages of the code entities or links to usages of the code entities….in addition to returning a code entity as a responsive search result, a collections of various usages of that code entity including a snippet of context may also be returned as a part of the search results….usages may include calls to a function, use as a parameter, use in an expression or statement, use in an assignment, or other uses”. [0112] states “A database or corpus of code snippets is first indexed according to one or more indexing methods as described above. a user may then execute search queries against the database to search for code snippets according to a search query”. [0138] describes how the frequency or count of usages of a particular term (i.e., method/expression) is recorded for a corpus of code. These are scored based on their reputation or popularity of use and search. [0138] recites “code entities and code snippets are scored based on the number of occurrences or the context of occurrence in different codebases”. [0140] recites “a code entity or code snippet may be ranked according to the context provided by a local development environment. for example, code entities or code snippets may be scored based on appearing in a similar context in their codebase or usage context or may be scored based on having similar code to the programmer’s current development environment… a presence or absence of code entities or code snippets in a user’s local code repository may be used to rank search results”. The recitations cited above in Smith449 describe ranking the search results based on the usage of the specified method.);
Therefore, based on Smith 389 in view of Barr Group, and in further view of Smith 446, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of a method usage index of Smith 446 to the system of Smith 389 and Barr Group in order to provide access to code entities and use machine learning models to analyze these code entities (Smith 446, [0008]). By using specific algorithms for usage analysis, it provides an effective, quick way for a developer to identify potentially vulnerable functions.
Regarding claim 27, Smith 389 in view of Barr Group and Smith 446 teaches the limitations recited in claim 1 above. Smith 389 also disclose “a hardware storage device that stores instructions that are executable by a processor to cause the processor” ([0028] Computer system includes a processor and a non-transitory computer-readable medium, which stores instructions for performing methods, where paragraph [0081] states that a storage medium 1124 stores instructions that are performed with a processing device 1102.);
Regarding claim 28, Smith 389 in view of Barr Group and Smith 446 teaches the limitations recited in claim 1 above. Smith 389 further discloses “wherein mining the code base further comprises parsing macro definitions to identify parameters that accept error codes or types corresponding to error codes” (Smith 389: [0057] Fig. 7, block 706, where the breaking code, fixing code, and information about an error are saved and associated, corresponding to a first error-checking macro being added to a list of candidate macro definitions.).
Regarding claim 29, Smith 389 in view of Barr Group and Smith 446 teaches the limitations recited in claim 1 above. Smith 389 further discloses “wherein the first parameter of the first error-checking macro is evaluated to determine whether the parameter controls execution of a return statement based on the first error code” (Smith 389: [0064] Fig. 8, process 800, step 802, code sample input to a machine learning model has one or more features extracted to determine additional error information as to whether the code sample outputs the error associated with the sample, which contains a method definition and a logical statement.);
Regarding claim 30, Smith 389 in view of Barr Group and Smith 446 teaches the limitations recited in claim 1 above. Smith 389 further discloses “wherein the first pass further comprises identifying a conditional statement within the first error-checking macro that compares the first error code to a predetermined value” (Smith 389: [0064] Fig. 8, process 800, step 802, code sample input to a machine learning model has one or more features extracted to determine additional error information as to whether the code sample outputs the error associated with the sample. Fig. 4 states, in paragraph [0050], that an error detection system is performed by compiler 320, with errors identified at compile time, run time, or test time when execution results are compared against default value for errors that occurred.);
Regarding claim 31, Smith 389 in view of Barr Group and Smith 446 teaches the limitations recited in claim 1 above. Smith 389 and Barr Group further teach “wherein the second error- checking macro invokes the first error-checking macro by passing an argument corresponding to the first error code” (Barr Group discusses the use of multiple versions of the assert() macro. Smith 389 describes the monitoring of an execution of a program, where errors may be detected, as described above [i.e., “[0057] describes how the execution of a program is monitored, where the monitoring system may detect a thrown error, exception, or corresponding error code. Some errors may be attributed to a breaking change, which can cause breaking of the program.]).
Regarding claim 32, […] disclose/teach the above subject matter content, […] “wherein the candidate signal list comprises macros that alter execution flow of the program in response to error codes” (Barr Group discusses the use of multiple versions of the assert() macro. Smith 389 describes the monitoring of an execution of a program, where errors may be detected, as described above [i.e., “[0057] describes how the execution of a program is monitored, where the monitoring system may detect a thrown error, exception, or corresponding error code.” Some errors may be attributed to a breaking change, which can cause breaking of the program.]).
Regarding claim 33, […] disclose/teach the above subject matter content, […] “wherein generating the positive training samples further comprises extracting expressions passed as parameters to macros in the candidate signal list” (Smith 446: [0109] describes how a set of code entities may be returned to a user following some search. Usages of these code entities may be calls to a function (i.e., methods), and are returned to the user. These code snippets (containing the code entities) are indexed according to an indexing method, as described in [0112]. [0109], which states “the search results may further include usages of the code entities or links to usages of the code entities….in addition to returning a code entity as a responsive search result, a collections of various usages of that code entity including a snippet of context may also be returned as a part of the search results….usages may include calls to a function, use as a parameter, use in an expression or statement, use in an assignment, or other uses”.).
Regarding claim 34, Smith 389 in view of Barr Group and Smith 446 teaches the limitations recited in claim 1 above. Smith 389 further discloses “wherein generating the positive training samples further comprises assigning a binary label indicating a software vulnerability to each extracted expression” (Smith 389: [0053] describes how errors in the source code (i.e., vulnerabilities) may be labeled and classified by an error classification system, where the examples may contain an error indication, error content, and optionally an error type label for the error indication.);
Claim(s) 5 and 26 are rejected under 35 U.S.C. 103 as being unpatentable over Smith 389, in view of in view of Barr Group, in further view of Smith 446, in further view of Li (CN 111124478 A).
Regarding Claim 5, Smith 446 further discloses “The system of claim 1, wherein the one or more programs include instructions that perform acts to: rank the plurality of repair code candidates…” (Smith 446: [0137] – [0138] describe ranking search results of code entity embeddings (i.e., repair codes) to determine an order to present to the user. Several ranking factors may be taken into consideration).
The combination of Smith 389, Barr Group, and Smith 446 discloses the above subject content matter, but fails to expressly disclose “based on each repair code candidate closely matching a directory and file name of the source code program having the software vulnerability”. However, analogous art from the same field of endeavor, Li, teaches this: [0022] of the translated reference describes how a compiled file (i.e., repair code file) may match the same name and directory as a source code file (i.e., source code program with vulnerability), in the context of version management to determine whether the files are the same or not.
Therefore, based on Smith 389 in view of Barr Group, further in view of Smith 446, and further in view of Li, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Li to the system of Smith 389, Barr Group, and Smith 446 in order to provide version management of compiled source code and previously existing source code (Li, Abstract). Version management is an important and widely-used mechanism for source code comparison and protection.
Regarding claim 26, Smith 389 in view of Barr Group and Smith 446, and further in view of Li teaches the limitations recited in claim 1 above. Smith 389 in view of Barr Group and Smith 446, and further in view of Li teach similar limitations that are described in claim 5 above.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Smith 389, in view of Barr Group, further in view of Smith 446, in further view of Vaswani et al (“Attention Is All You Need”), hereinafter Vaswani.
Regarding Claim 7, the combination of Smith 389 and Barr Group discloses the above subject matter content, but fails to expressly disclose “The system of claim 1, wherein the neural classifier includes a neural encoder transformer with attention”. However, analogous art from the same field of endeavor, Vaswani, teaches this: The Abstract describes how an encoder and decoder mechanism of a transformer neural network is connected with an attention mechanism. Page 5, section 3.2.3 “Applications of Attention in our Model” describes the varieties of utilization of attention in the transformer model.
Therefore, based on Smith 389 in view of Barr Group, and in further view of Vaswani, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Vaswani to the system of Smith 389 and Cobb in order to provide a model that relies solely on an attention mechanism for a robust neural network encoder-decoder transformer model (Vaswani, p. 2, Section 1 “Introduction”).
Conclusion
THIS ACTION IS MADE FINAL. 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 TOMMY MARTINEZ whose telephone number is (703)756-5651. The examiner can normally be reached Monday thru Friday 8AM-4PM ET.
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, Jorge L. Ortiz-Criado can be reached at (571) 272-7624 on Monday thru Friday 7AM-7PM ET. 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.
/T.M./ Examiner, Art Unit 2496
/JORGE L ORTIZ CRIADO/Supervisory Patent Examiner, Art Unit 2496
Prosecution Insights