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 November 21, 2025 have been fully considered but they are not persuasive.
In page 1 of the remarks, Applicant states that independent claim 13 was rejected under 35 U.S.C. 112(b) (“112(b)”) as being indefinite with regards to the term “Q&A” present in the claim, with the abbreviation being undefined, despite it existing in independent claims 1 and 12. Applicant has amended claim 13 to add the abbreviation to the claim. As a result, the 112(b) rejection for claim 13 has been withdrawn.
In pages 1-4 of the remarks, Applicant states that claims 1-2, 4-5, 11-13 were rejected under 35 U.S.C. 102(a)(1) as being anticipated by Feng (US 20220269794 A1), with independent claim 1 being amended to recite “collecting […] first security patch […] on a vulnerability information page of a public vulnerability database”, “collecting […] second security patch […] using predetermined hint information comprising commit ID information or bug ID information”, and “collecting […] third security patch […] for a commit message including a common vulnerabilities and exposures (CVE) identiifer”. Applicant states that the reference of Feng does not describe the following: scanning an external vulnerability database page with pattern logic (remarks page 2) with Feng’s Fig. 20 only showing a UI table of results; pattern-matching on an NVD (“national vulnerability database”) page, with Feng only showing repository paths and commits (remarks pages 2-3); an indirect path link, as Feng’s Fig. 20 shows a Git commit link 2014 (remarks page 3), using CVE IDs to search commit history (remarks page 3); usage of code snippets from Stack Overflow answers to find matching results with CVE identifiers (remarks page 3); and patches being collected through “three types of links”, with Feng containing various bug fix snippets, but only performed through general crawling and matching, with no separation or annotating patches based on how it was obtained (remarks page 4).
Examiner disagrees with the Applicant regarding the use of Feng not describing any of the above limitations and features of the invention of the Applicant. Regarding the Applicant’s argument of Feng never describing an external vulnerability database page being scanned with pattern logic, the use of paragraph [0103] of Feng, which shows Fig. 20, being a table displaying user source code searched in a bug/vulnerability knowledge database with fixes also displayed, with the bug fix code accessed through a direct patch link through fix file 2018, being matched with existing files in the user’s repository, with matching services of Feng scanning the repository and Fig. 15 searching through public knowledge databases, including results 1504, containing a page to a github commit and file path to a bug fix file itself, corresponds to pattern matching to scan an external vulnerability database page. Next, pattern-matching on an NVD page, which is not explicitly recited in the amended claims, is nevertheless described in Feng [0095], Fig. 15, where the user selects searching through public knowledge databases, searches through public repositories, such as 'github.com' seen in the 'homepage' column, to which the link in the homepage column corresponds to a vulnerability data source domain name information. By analyzing the github commit to identify the repository and the file path of a specific file, Feng recites pattern-matching on an NVD page, in this scenario, identifying patterns on a github commit, which also corresponds to analyzing an issue-tracker link on an NVD page. Feng’s commit link 2014 corresponds to an indirect patch link, with [0102] describing bug fixes being identified by crawling web sites and other databases in Fig. 18, which is then displayed in the table of Fig. 20 as repository 2012 containing the file fix 2018 of Fig. 20, and as a result, Feng suggests using a crawling service to search for indirect file patches, in this case, the repository containing the fix code. Next, Feng describes CVE IDs in the table 2010 of Fig. 20, and paragraph [0103] of Feng states that a bug identifier includes a CVE 2010, and [0102] further describes using a bug identifier for a system to suggest fixes for identified bugs from a knowledge base in Fig. 19, corresponding to using CVE IDs to search commit history. Examiner states that the use of Fig. 19, describing use of Stack Overflow being used as website 1902 as a public database, and bug fix submissions 1802 used as input to identify a bug, where CVE IDs are used as bug identifiers for a system to suggest bug fixes for identified bugs from a knowledge base in Fig. 19, Feng suggests the usage of code snippets from Stack Overflow answers to find matching results with CVE identifiers. Finally, the use of fix file 2018 as the direct patch link, a git commit hyperlink 2014 as the indirect patch link, and the searching of a website such as Stack Overflow corresponding to an invisible patch link with a snippet matching service, as described in paragraph [0040] of Feng, is described in Fig. 20 of Feng with separate links to the commit link and fix file directly for indirect patch and direct patch, respectively. Fig. 10’s snippet reference view is utilized for viewing code from a developer community website such as Stack Overflow, and corresponds to a third security patch from an invisible patch link. As a result, Examiner maintains the rejections under 102 for claim 1 as being anticipated under Feng.
In page 4 of the remarks, Applicant states that claims 12 and 13 were rejected under 35 U.S.C. 102(a)(1), and as claim 1 has allowable subject matter, claims 12 and 13 should also be rendered allowable over the prior art.
Examiner maintains the rejections under 102 for claims 12 and 13 as being anticipated under Feng, as the claims recite similar limitations to claim 1 above.
In pages 4-5 of the remarks, Applicant states that the rejections under 35 U.S.C. 103 relies on a combination of Feng in view of Rush et al. (US 8688676 B2), but it fails to render the amended claims obvious, with Feng not disclosing the NVD-based pattern matching, and Rush being a source-code search engine, triggering a search when a code change is made in an API. Applicant states that the reliance on Rush to teach “predetermined feature includes changes in a security-sensitive API”, as recited in claims 6 and 10, is misplaced with Rush’s description of API-changed-triggered search, stated in Rush [Col. 9, lines 32-36], as it only reflects a general code-search UI, and argues that even with the combination of Feng, the combination does not suggest a specific collection steps claimed (NVD-based link identification and CVE-based commit search), and that the 103 rejection is traversed.
Examiner states that pattern-matching on an NVD page, which is not explicitly recited in the amended claims, is nevertheless described in Feng [0095], Fig. 15, where the user selects searching through public knowledge databases, searches through public repositories, such as such as 'github.com' seen in the 'homepage' column. By analyzing the github link to identify the commit and the file path of a specific file, Feng recites pattern-matching on an NVD page, in this scenario, identifying patterns on a github commit, which also corresponds to analyzing an issue-tracker link on an NVD page. Rush describes the API used in the searching as a security API, as stated in [Col. 15, lines 49-53], that can be used for the API 1070. Furthermore, with regards to the specific collection steps, the use of [Col. 9, lines 59-61] of Rush, one can refine a search in search interface 460 in Fig. 4, which can include a keyword in a file, corresponding to a security-related keyword, and in combination with paragraph [0103] of Feng states that a bug identifier includes a CVE 2010, and [0102] further describes using a bug identifier for a system to suggest fixes for identified bugs from a knowledge base in Fig. 19, corresponding to using CVE IDs to search commit history, teach the recited specific collection steps claimed using a CVE-based search.
Finally, in page 5 of the remarks, Applicant states that the Office Action (“OA”) misinterprets Feng’s disclosures, including treating Feng’s Fig. 20 user interface table as “vulnerability information page”; “file path” and “git commit” not corresponding to scanning an NVD page for links; generic repository crawling in [0042] of Feng differing from Applicant’s indirect-link crawling; and Feng’s Stack Overflow snippet feature not being the invisible patch step.
Examiner disagrees with the Applicant regarding the misinterpretations of the claimed limitations and the phrases above, as the user interface table 2006 displays information regarding the vulnerabilities and fixes, which also collects to a vulnerability database the user has access to, as described in paragraph [0103] of Feng. Next, pattern-matching on an NVD page, which is not explicitly recited in the amended claims, is nevertheless described in Feng [0095], Fig. 15, where the user selects searching through public knowledge databases, searches through public repositories, such as 'github.com' seen in the 'homepage' column, and by analyzing the github commit to identify the repository and the file path of a specific file, Feng recites pattern-matching on an NVD page, in this scenario, identifying patterns on a github commit, which also corresponds to analyzing an issue-tracker link on an NVD page. The specific file link and the github commit correspond to the direct patch link and the indirect patch link, respectively. Feng’s [0042] Fig. 1, crawling service 104 is configured to download data repositories from hosting websites, including from GitHub, Gitlab, and maven.org, wherein the crawlers use organization/author list as seeds to crawl repositories from these organizations/authors, wherein the crawlers are configured to identify information in the pages, where the use of author/organization list as seeds to begin the crawling of repositories corresponds to indirect-link crawling of the invention. Finally, Examiner disagrees with the Applicant regarding the statement that Stack Overflow snippet feature not being the invisible patch step, as Feng’s Fig. 10’s snippet reference view is utilized for viewing code from a developer community website such as Stack Overflow, and corresponds to a third security patch from an invisible patch link.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-2, 4-5, and 11-12 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Feng (US 20220269794 A1).
Regarding claim 1, Feng discloses ‘A processor-implemented method for building a vulnerability database, performed by a computing device comprising at least one processor and memory, the method comprising’ ([0015] "The systems and techniques described herein, or portions thereof, may be implemented as an apparatus, method, or electronic system that may include one or more processing devices and computer memory to store executable instructions to implement control of the stated functions" Systems and techniques described in the invention can be implemented as an apparatus, method, or electronic system, wherein the invention can be an electronic system, and contain computer memory with one or more processing devices. [0015] Computer program product includes instructions that are stored on one or more non-transitory machine-readable storage media and are executable on one or more processing devices, such as microprocessors, programmed logic such as field programmable gate array(s), or the like. [0102] Fig. 19 has a bug and vulnerability finding and remediation system using public databases 1902, and a database 1904 is built by collecting code and other information related to a repository or commits, including ‘git’ commits information for bug fixes, both with the code that contains bugs and potential fixes that a developer might need.):
‘collecting, by the computing device, a first security patch from a data source based on a direct patch link, the collecting including identifying a security patch link having a predetermined pattern on a vulnerability information page of a public vulnerability database, the page comprising vulnerability data source domain name information and security patch identification character string information, and retrieving the first security patch from a security patch page connected through the identified security patch link’ ([0102] Database 1904 is built with 'git' commits information for bug fixes and known security and vulnerability issues, which can include code snippets and corresponding code snippets with fixes, with Fig. 19 has a bug and vulnerability finding and remediation system using public databases 1902. Multiple bug fixes can be retrieved through different methods. [0103] Fig. 20, matched files contains bug code returned from knowledge base that is displayed in table 2006, wherein the table columns include hyperlinks to file paths 2018 that contain corresponding bug fix code, where the hyperlink to file paths that contain the bug fix code corresponds to the direct patch link, as it links directly to the file for easier collecting of a data patch. The hyperlink to a corresponding bug fix code corresponds to a first security patch of the Applicant, when also accounting for different bugs corresponding to different bug fixes of paragraph [0102]. [0103] Fig. 20 shows the corresponding file accessed through the direct patch link matches the file in use at the current moment, showing a side-by-side comparison. The naming of the file in the table column has a pattern of showing the directories in the repository, along with a commit value in the same column, which is a snapshot of the code from that point in time. The link also leads to the security patch file, which is collected by the crawler and the service. [0103] "The table columns include... hyperlinks to file paths 2018 that contain the corresponding bug fix code", where the path corresponds to the security patch identification character string information, in this case the file path in the repository. [0095] Fig. 14 and 15, the homepage column in a table 1404/1504 contains the homepage to a repository, such as 'github.com' seen in the 'homepage' column, to which the link in the homepage column corresponds to a vulnerability data source domain name information of the applicant, which describes a domain of a website that can host repositories.);
‘collecting, by the computing device, a second security patch from the data source based on an indirect patch link, the collecting including crawling a website address identified on the same vulnerability information page of a public vulnerability database to discover the indirect patch link using predetermined hint information comprising commit ID information or big ID information, and retrieving the second security patch based on the indirect patch link’ ([0103] Fig. 20, table 2006, where the Git commit hyperlink corresponds to the indirect patch link, as it leads to the commit of the potential bug fix that a developer of a repository is working on. [0042] Crawling service 104 is configured to download data repositories from hosting websites, such as GitHub, Gitlab, and maven.org, wherein the contents from the repositories are obtained and saved into file stores on one or more computer devices, which include the big fix/patch file that would be used to fix current issues with the code that the developers need at that point in time. Bug fixes or patch files retrieved with a crawling service 104 correspond to retrieval of a second security patch of the Applicant, when also accounting for different bugs corresponding to different bug fixes of paragraph [0102]. [0042] Fig. 1, crawling service 104 is configured to download data repositories from hosting websites, including from GitHub, Gitlab, and maven.org, wherein the crawlers use organization/author list as seeds to crawl repositories from these organizations/authors, wherein the crawlers are configured to identify information in the pages and potentially gather files as they go along the page and, in the case of GitHub, the repositories as well. File contents from these repositories are obtained and saved into the file stores on one or more computer devices. [0103] Fig. 20, table 2006 corresponds to the vulnerability information page which shows the information regarding vulnerabilities and fixes, and the invention is collected to the vulnerability database that the user has access to. [0103] Fig. 20 shows the corresponding commit through the indirect patch link, with the pattern of the hyperlink 2014 containing the commit value that identifies the specific revision of the code, contains the file or files in use at the current moment, showing a side-by-side comparison. The crawler will retrieve files that are related to the repository based on the hyperlink, and will be shown to the user, corresponding to collecting including crawling a website address identified on the same vulnerability information page using predetermined hint information of the Applicant. [0101] “bug and vulnerability finding and remediation system uses “git” and commits information to build a private knowledge base”, where the commit information corresponds to the commit ID information, as they are versions of the repository/software from a particular point in time.);
‘collecting, by the computing device, a third security patch from the data source based on an invisible patch link, the collecting including analyzing a question-and-answer (Q&A) post for a code snippet change associated with a known vulnerability and searching a source code repository commit message including a common vulnerabilities and exposures (CVE) identifier to identify a patch commit, and retrieving the third security patch from the identified patch commit’ ([0040] Matching service 132 and reporting service 134 are configured to provide snippet matching and detailed comparison through web services 128 using RESTful APIs 130, in which the service and the API will be used to obtain and display the code from an invisible patch link, which can include searching through a website such as Stack Overflow, as stated by the applicant. [0099] Snippet reference view can be useful for a social media or developer community website such as ‘stackoverflow.com’, and matching service searches the code snippet and report matched details similar to 1000, in Fig. 10, and wherein 1100 is Fig. 11, where it displays a side-by-side comparison between the source code the user has written and the matched file from the knowledge base, which in this scenario, originates from Stack Overflow. Snippet reference in paragraph [0099] corresponds to a third security patch, when utilized in conjunction with the matching service 132 in paragraph [0040]. [0102] With support from paragraph [0099] and Fig. 10, a matching service can extract the code section of an answer from a community website such as Stack Overflow including repository name, release version, known vulnerability issues if any, along with other information. Back to Fig. 19, as Stack Overflow can take the form of a website 1902 as a public database. Fig. 19, use of bug fix submissions 1802 as input content to identify a bug is obtained, and the invention crawls websites or other databases to identify a bug that the bug fix submission would identify and fix up, which includes repositories that a commit is a part of, and database 1904 stores 'git' commits information for bug fixes and known security and vulnerability issues including both code snippets with bugs and their corresponding code snippets with fixes. Paragraph [0103] further states that a bug identifier can include a CVE (common vulnerabilities and exposures) 2010, as identified from a table 2006 in Fig. 20 in the vulnerability knowledge database.);
‘and building, by the computing device, at the vulnerability database loaded with multiple security patches including the first, second, and third security patches respectively collected from the data source based on the direct patch link, the indirect patch link, and the invisible patch link’ ([0102] Fig. 19, database 1904 stores ‘git’ commits information for bug fixes and known security and vulnerability issues including both code snippets with bugs and the code snippets and fixes, and Fig. 20 is described in paragraph [0103] as a computer display showing a user’s source code with the knowledge database information shown in table 2006. Direct patch links of the Applicant are disclosed with hyperlinks to file paths 2018 that contain corresponding bug fix code, indirect patch links are disclosed with Git commit hyperlink corresponds to the indirect patch link, as it leads to the commit of the potential bug fix that a developer of a repository is working on, and invisible patch links are disclosed with paragraph [0099], with Fig. 11 showing a snippet reference view can be useful for a social media or developer community website such as ‘stackoverflow.com’, which is another form of viewing code and searching through a knowledge database of Feng. [0102] Fig. 19 has a bug and vulnerability finding and remediation system using public databases 1902.);
Regarding claim 2, Feng discloses the method of claim 1. Feng also discloses the limitations of ‘wherein the first security patch is identified by scanning the vulnerability information page of the public vulnerability database for the direct patch link having the predetermined pattern’ ([0103] Fig. 20, table 2006 corresponds to the vulnerability information page which shows the information regarding vulnerabilities and fixes, and is collected to the vulnerability database that the user has access to, such as matched files containing bug code returned from the knowledge base are displayed in table 2006, with the file patch 2008 having a predetermined pattern as a string of characters displaying the name of a file with respect to a repository. [0102] Fig. 19 has a bug and vulnerability finding and remediation system using public databases 1902.).
Regarding claim 4, Feng discloses the method of claim 1. Feng also discloses the limitations of ‘wherein the third security patch is collected by analyzing the Q&A post to extract a code change corresponding to the known vulnerability, and retrieving the third security patch based on that change’ ([0040] Matching service 132 and reporting service 134 are configured to provide snippet matching and detailed comparison through web services 128 using RESTful APIs 130, in which the service and the API will be used to obtain and display the code from an invisible patch link, which can include searching through a website such as Stack Overflow, as stated by the applicant. [0102] With support from paragraph [0099] and Fig. 10, a matching service can extract the code section of an answer from a community website such as Stack Overflow including repository name, release version, known vulnerability issues if any, along with other information. Back to Fig. 19, as Stack Overflow can take the form of a website 1902 as a public database. Fig. 19, code snippets are extracted and diffs (or compares) file contents 1906 in the form of diff commits/snippets 1908 with previous versions that may exist, as stated with 'for example by comparing the code containing the file snippets containing bug fixes to one or more prior versions of the code'. Back to Fig. 19, the different versions of an answer can be extracted when a previous version(s) exists. [0099] Snippet reference view can be useful for a social media or developer community website such as ‘stackoverflow.com’, and matching service searches the code snippet and report matched details similar to 1000, in Fig. 10, wherein the service acquires the code snippet and uses it to display to the user in a development environment while it continues to search for resources in the background.).
Regarding claim 5, Feng discloses the method of claim 1. Feng also discloses the limitations of ‘wherein the third security patch is retrieved by searching a commit message that includes a CVE ID from the repository corresponding to the vulnerability’ ([0040] Matching service 132 and reporting service 134 are configured to provide snippet matching and detailed comparison through web services 128 using RESTful APIs 130, in which the service and the API will be used to obtain and display the code from an invisible patch link, which can include searching through a website such as Stack Overflow, as stated by the applicant. [0102] Fig. 19, use of bug fix submissions 1802 as input content to identify a bug is obtained, and the invention crawls websites or other databases to identify a bug that the bug fix submission would identify and fix up, which includes repositories that a commit is a part of, when utilized in conjunction with the services of paragraph [0040] in Feng. Paragraph [0103] further states that a bug identifier can include a CVE (common vulnerabilities and exposures) 2010, as identified from a table 2006 in Fig. 20 in the vulnerability knowledge database).
Regarding claim 11, Feng discloses the elements of claim 1 above. Feng also discloses ‘wherein the collecting of the third security patch from the data source based on the invisible patch link includes’ ([0040] Matching service 132 and reporting service 134 are configured to provide snippet matching and detailed comparison through web services 128 using RESTful APIs 130, in which the service and the API will be used to obtain and display the code from an invisible patch link, which can include searching through a website such as Stack Overflow, as stated by the applicant.);
searching a commit message including common vulnerabilities and exposures identifier (CVE ID) information in a repository or an issue tracker ([0102] Fig. 19, use of bug fix submissions 1802 as input content to identify a bug is obtained, and the invention crawls websites or other databases to identify a bug that the bug fix submission would identify and fix up, which includes repositories that a commit is a part of. Paragraph [0103] further states that a bug identifier can include a CVE (common vulnerabilities and exposures) 2010, as identified from a table 2006 in Fig. 20 in the vulnerability knowledge database),
and collecting the third security patch from the searched commit message by analyzing the searched commit message based on a predetermined feature ([0102] Fig. 19, database 1904 stores 'git' commits information for bug fixes and known security and vulnerability issues including both code snippets with bugs and their corresponding code snippets with fixes.).
Regarding claim 12, Feng discloses similar limitations present in independent claim 1 above, and also discloses the additional limitations of ‘computer program stored in a non-transitory computer-readable medium, the computer program comprising instructions that, when executed by one or more processors, cause the one or more processors to perform operations for building a vulnerability database, the operations comprising’ ([0013] One or more non-transitory machine-readable storage media may store instructions that are executable by one or more processing devices to perform operations in method and variants. Fig. 19 has a bug and vulnerability finding and remediation system using public databases 1902, and a database 1904 is built by collecting code and other information related to a repository or commits, including ‘git’ commits information for bug fixes, both with the code that contains bugs and potential fixes that a developer might need. [0103] Fig. 20, matched files contains bug code returned from knowledge base that is displayed in table 2006, wherein the table columns include hyperlinks to file paths 2018 that contain corresponding bug fix code, where the hyperlink to file paths that contain the bug fix code corresponds to the direct patch link, as it links directly to the file for easier collecting of a data patch.):
Regarding claim 13, Feng discloses similar limitations present in independent claim 1 above, and also discloses the additional limitations of ‘a computing device comprising:’ ([0015] "The systems and techniques described herein, or portions thereof, may be implemented as an apparatus, method, or electronic system that may include one or more processing devices and computer memory to store executable instructions to implement control of the stated functions" Systems and techniques described in the invention can be implemented as an apparatus, method, or electronic system, wherein the invention can be an electronic system, and contain computer memory with one or more processing devices. [0015] Computer program product includes instructions that are stored on one or more non-transitory machine-readable storage media and are executable on one or more processing devices, such as microprocessors, programmed logic such as field programmable gate array(s), or the like.);
‘a memory storing computer executable components’ ([0015] Computer program product includes instructions to implement control of the functions of the invention, which includes the components present in the invention, which includes the components present in the figures in the invention, primarily in Figs. 18-20.);
‘and at least one processor configured to execute the components, the components comprising’ ([0015] Computer program product includes instructions that are stored on one or more non-transitory machine-readable storage media and are executable on one or more processing devices, such as microprocessors, programmed logic such as field programmable gate array(s), or the like. Control of functions in invention of Feng includes components of the invention.);
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 6-10 are rejected under 35 U.S.C. 103 as being unpatentable over Feng in view of Rush et al. (US 8688676 B2), hereinafter Rush.
Regarding claim 6, Feng discloses the method of claim 5. Feng does not appear to fully teach, but Rush teaches the method of claim 6, ‘wherein the third security patch corresponds to a predetermined feature identified in the commit, such as a change in security-sensitive application programming interfaces (APIs) or a security-related keyword’ ([Col. 9, lines 32-36] When changes are made in source code, a search can be initiated, and this can be triggered based on modification of existing code, such as changing an API of a portion of code, which corresponds to a predetermined feature including changes in a security-sensitive API of the applicant. Section [Col. 15, lines 49-53] further describes an API as being a security API 1070 that can be utilized. In section [Col. 9, lines 59-61] of Rush, one can refine a search in search interface 460 in Fig. 4, which can include a keyword in a file, corresponding to a security-related keyword of the Applicant, when utilized in conjunction with a Q&A post corresponding to a third security patch as described in paragraph [0099] of Feng.).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Feng and Rush before them, to include Rush’s ‘wherein the predetermined feature includes changes in a security-sensitive application programming interface (API)’, ‘a security-related keyword’, and ‘and a control flow’ in Feng’s method performing ‘building a vulnerability database’. One would have been motivated to make such a combination to increase efficiency by sending notifications to two parties when a file has changed, and when an author of code updates a file with bug fixes, or when a developer reuses that same file with bug fixes included, with further fixes made by the developer, and it notifies the author of the use of their code to integrate those changes into a project, which includes changes made to an API, as stated by Rush [Col. 5, lines 53-65].
Regarding claim 7, Feng discloses the method of claim 6. Feng also discloses the limitations of ‘wherein the third security patch is identified by analyzing code changes in the Q&A post on a site such as Stack Overflow’ ([0040] Matching service 132 and reporting service 134 are configured to provide snippet matching and detailed comparison through web services 128 using RESTful APIs 130, in which the service and the API will be used to obtain and display the code from an invisible patch link, which can include searching through a website such as Stack Overflow, as stated by the applicant. [0102] Fig. 19, code snippets are extracted and diffs (or compares) file contents 1906 in the form of diff commits/snippets 1908 with previous versions that may exist, as stated with 'for example by comparing the code containing the file snippets containing bug fixes to one or more prior versions of the code'. Back to Fig. 19, the different versions of an answer can be extracted when a previous version(s) exists, when utilized in conjunction with the services of paragraph [0040] in Feng.).
Regarding claim 8, Feng discloses the method of claim 7. Feng also discloses ‘wherein the third security patch is a code snippet from the post that is analyzed for security-related features’ ([0102] When snippets 1908 container in prior versions differ from an initial bug fix submission, the snippets are sent to match service 1910 to obtain matching files 1912, the matched files can contain a bug to be fixed, to which the snippets 1908 can contain a fix to the bug to be fixed, and a fix corresponds to a predetermined feature of extracted change history of the applicant, which is used to fix bugs that matched files contain, when utilized in conjunction with a Q&A post corresponding to a third security patch as described in paragraph [0099].).
Regarding claim 9, Feng discloses the method of claim 8. Feng also discloses the limitations of ‘wherein the third security patch is identified based on a change in control flow in the Q&A post’ ([Col. 4, lines 38-40] One can identify entities and members referenced by each statement in the code, to which a statement in the code can correspond to a control flow of the applicant. This allows developers to find a location of where an entity is defined, and find other locations where it is referenced.).
Regarding claim 10, Feng discloses the elements of claims 1 and 9 above. Feng does not appear to fully teach, but Rush teaches the method of claim 9, wherein the predetermined feature includes changes in a security-sensitive application programming interface (API) ([Col. 9, lines 32-36] When changes are made in source code, a search can be initiated, and this can be triggered based on modification of existing code, such as changing an API of a portion of code, which corresponds to a predetermined feature including changes in a security-sensitive API of the applicant. Section [Col. 15, lines 49-53] further describes an API as being a security API 1070 that can be utilized.),
a security-related keyword (In paragraph [0102] of Feng, in Fig. 9, files that are matched in step 1910 and are further specified in the 'potential bugs in private code base' step as containing the same vulnerability issue, based on an input bug fix submission, which can be a form of security-related input. While Feng does not fully teach the limitation, we can utilize a 'keyword' of Rush to teach the 'keyword' aspect of this claim, as in section [Col. 9, lines 59-61] of Rush, one can refine a search in search interface 460 in Fig. 4, which can include a keyword in a file, and combining the two references teaches the limitation of security-related keyword of the applicant.),
and a control flow ([Col. 4, lines 38-40] One can identify entities and members referenced by each statement in the code, to which a statement in the code can correspond to a control flow of the applicant. This allows developers to find a location of where an entity is defined, and find other locations where it is referenced.).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Feng and Rush before them, to include Rush’s ‘wherein the predetermined feature includes changes in a security-sensitive application programming interface (API)’, ‘a security-related keyword’, and ‘and a control flow’ in Feng’s method performing ‘building a vulnerability database’. One would have been motivated to make such a combination to increase efficiency by sending notifications to two parties when a file has changed, and when an author of code updates a file with bug fixes, or when a developer reuses that same file with bug fixes included, with further fixes made by the developer, and it notifies the author of the use of their code to integrate those changes into a project, which includes changes made to an API, as stated by Rush [Col. 5, lines 53-65].
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