DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Objections
Claims 9-14 objected to because of the following informalities: Recitations of claim 1 are likely a typographical error and should say claim 8. For the purposes of examination, claims 9 and 10 will be interpreted as dependent on claim 8 as this seems to be the intention. Appropriate correction is required.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 2, 5, 9, 12, 16 and 18 contain the trademark/trade name GitHub. Where a trademark or trade name is used in a claim as a limitation to identify or describe a particular material or product, the claim does not comply with the requirements of 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph. See Ex parte Simpson, 218 USPQ 1020 (Bd. App. 1982). The claim scope is uncertain since the trademark or trade name cannot be used properly to identify any particular material or product. A trademark or trade name is used to identify a source of goods, and not the goods themselves. Thus, a trademark or trade name does not identify or describe the goods associated with the trademark or trade name. In the present case, the trademark/trade name is used to identify/describe a code hosting platform and, accordingly, the identification/description is indefinite.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 15-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter because they can be interpreted as signals per se. Transitory signals are not eligible subject matter, and a tangible or physical storage medium can be interpreted as signals per se. Applicant’s specification does not limit the medium to exclude transitory signals. Claim language should be amended to specify non-transitory computer readable medium.
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, 7, 8, 14, 15 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Calvano (20210256426) in view of Kulshreshtha (US 20230252162).
Regarding claim 1, Calvano teaches A method for prioritizing code violations in a computer program, using machine learning, the method comprising: analyzing the computer program for code violations (“Although FIG. 4 illustrates one example of a process 400 for training a machine learning model that can be used for prioritizing and ranking static analysis results,” ¶50) training a machine learning model to differentiate between vulnerable and non-vulnerable code in the extracted code snippets; (“The trained machine learning algorithmic model comprises a variable space determined by patterns detected during the training of the applicable algorithm. The applicable algorithm may be any algorithm, e.g., linear regression, suitable for building a model based on the intended application of identifying a vulnerability in application logic” ¶29);… ranking the code snippets based on their respective vulnerability probability score, …and displaying the ranked code snippets to be fixed for their code violations (“When multiple probability ratings 530a-530c are generated by the machine learning model 505, the probability ratings 530a-530c can be ranked by probability or aggregated in some manner. For example, multiple probability ratings 530a-530c could be aggregated by averaging the values. Once the probability ratings 530a-530c are ranked or aggregated, the probability ratings 530a-530c can be reported for prioritization in the static analysis tool 510.” ¶57). Calvano does not teach inputting the extracted code snippets to a trained machine learning model to assign a vulnerability probability score to each snippet, wherein each vulnerability probability score indicates a severity of the violation for a respective snippet.
Kulshreshtha teaches inputting the extracted code snippets to a trained machine learning model to assign a vulnerability probability score to each snippet, (“Analytics engine 118 harvests variables from application related data 122, populates the variable space of the trained machine learning algorithmic model, and executes the algorithmic model against a sample of knowledge database 108 to determine probabilities and scores of each system call, each subroutine, each call stack, or any combination thereof.” ¶33); wherein each vulnerability probability score indicates a severity of the violation for a respective snippet; (“FIG. 1 illustrates an example of a system for detecting vulnerabilities in applications by evaluating call traces and scoring the severity of the vulnerabilities, according to certain embodiments,” ¶15). It would have been obvious for one of ordinary skill in the art prior to the filing of the claimed invention to combine the use of machine learning to score and rank vulnerabilities as taught by Calvano the scoring of vulnerability severity as taught by Kulshreshtha. Ranking detected vulnerabilities allows for prioritization that can make more efficient use of time (Calvano ¶17).
Regarding claim 7, Kulshreshtha teaches wherein the code violations include security vulnerabilities (“FIG. 1 illustrates an example of a system for detecting vulnerabilities in applications” ¶4).
Regarding claim 8, Calvano teaches what is considered the broadest reasonable interpretation for a system for prioritizing code violations in a computer program, the means for which being interpreted as a generic computer. The claim recites the same additional limitations as the method of claim 1 which are taught by Calvano and Kulshreshtha.
Regarding claim 14, it recites the same limitations as claim 7.
Regarding claim 15, Calvano teaches A tangible storage medium for storing a plurality of computer codes, the plurality of computer codes when executed by one more computers performing a method for prioritizing code violations in a computer program (“In a third embodiment, a non-transitory computer readable medium contains instructions that when executed cause at least one processor to obtain at least one program slice embedding vector and at least one register vector that are generated based on results from a static analysis tool,” ¶6). The claim recites the same methods as claims 1 and 8 which is taught by Calvano and Kulshreshtha.
Regarding claim 20, it recites the same limitations as claims 7 and 14.
Claim(s) 2, 3, 9, 10, and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Calvano and Kulshreshtha in view of Yaron (US 20230169170).
Regarding claim 2 Calvano and Kulshreshtha teach the method of claim 1, they do not teach wherein the vulnerable dataset is created from GitHub commit hashes found in the Common Vulnerabilities and Exposures (CVE).
Yaron teaches wherein the vulnerable dataset is created from GitHub commit hashes found in the Common Vulnerabilities and Exposures (CVE) (“As a non-limiting example, by analyzing log files from an integration or deployment server, links between code commits and binary hashes (and, consequently, the corresponding entities involved) may be identified.” ¶64, “In yet a further embodiment, S730 may further include analyzing meta information about the common trait or indicator (e.g., a CVE) and relevant packages such as, but not limited to, version” ¶111). It would have been obvious for one of ordinary skill in the art prior to the filing of the claimed invention to combine the code vulnerability analysis and ranking methods taught by Calvano and Kulshreshtha with the use of hashes associated with CVE data. Kulshreshtha teaches the use of CVE to identify vulnerabilities (¶30) and identifying code with commit hashes is another way to analyze files as taught by Yaron.
Regarding claim 3, Yaron teaches wherein the vulnerable dataset includes unique CVE identifier, a description of the vulnerability, a vulnerability potential impact, and references to related reports (“The Snyk™ tool generates an alert based on source code of the customer, i.e., the Snyk™ tool generates alerts related to a coding phase of the software development pipeline. In this example, both the Lacework™ tool and the Snyk™ tool generate an alert indicating the CVE with the identifier “CVE-2022-24434,” which indicates that a software component being developed may be vulnerable to Denial of Service (DoS) attacks” ¶120).
Regarding claims 9 and 16, they recite the same limitations as claim 2, and claim 10 recites the same limitations as claim 3, and are rejected for the same reasons shown above.
Claim(s) 4 , 11, and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Calvano and Kulshreshtha in view of Yawalkar (US 20200137126).
Regarding claim 4, Calvano and Kulshreshtha teach the method of claim 1, Kulshreshtha teaches wherein the non-vulnerable dataset is created (““For example, a stack that is present in environments/conditions for which the vulnerability is detected and is absent in environments/conditions for which the vulnerability is not detected…” ¶40), they do not teach wherein the non-vulnerable dataset is created from open source projects using static analysis tools
Yawalkar teaches wherein the non-vulnerable dataset is created from open source projects using static analysis tools (“For example, in at least one implementation, computing system 101 could be configured to crawl and download web resources 110 from open-source web object repositories” ¶22). It would have been obvious for one of ordinary skill in the art prior to the filing of the claimed invention to combine the vulnerability analysis and ranking methods of Calvano and Kulshreshtha with the analysis of open source projects as taught by Yawalkar. This is another analysis technique for security issues (Yawalkar ¶24).
Regarding claims 11 and 17, they recite the same limitations as claim 4 and are rejected for the same reasons shown above.
Claim(s) 5, 12 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Calvano and Kulshreshtha and Yaron in view of Viswambharan (US 20200358802).
Regarding claim 5, Calvano Kulshreshtha and Yaron teach the method of claim 2. Kulshreshtha teaches wherein creating the vulnerable dataset comprises: downloading a CVE dataset;(“ Application server 106 or analytics engine 118 may also access pre-built machine learning algorithmic models through one of the repositories for use in evaluating applications 120. Common Vulnerability Enumeration (CVE) model and Common Weakness Enumeration (CWE) model are two publicly available models that may be used by analytics engine 118 to identify vulnerabilities in applications 120. Application server 106 may be configured to process the feed, access the one or more repositories, access machine learning algorithmic models, or any combination thereof and store the same in knowledge database 108.” ¶30 Yaron teaches filtering entries in the CVE dataset to identify entries that contain GitHub commit hashes; (“As a non-limiting example, by analyzing log files from an integration or deployment server, links between code commits and binary hashes (and, consequently, the corresponding entities involved) may be identified. As another non-limiting example, by analyzing of files in a cloud environment, information identifying entities used by automation engines may be identified” ¶64); determining vulnerable files that contain code violation; and extracting vulnerable code snippets from the vulnerable files (“The root cause entities are collectively determined as the root cause of the cybersecurity event. As a non-limiting example, a root cause entity may be an entity containing faulty code (e.g., a file or container) which caused an alert to trigger.” ¶133”). They do not teach identifying code in the computer program that was affected by each patch; reversing each patch in the identified code to restored code in the computer program that was affected by each patch to its pre-patch state.
Viswambharan teaches teach identifying code in the computer program that was affected by each patch; reversing each patch in the identified code to restored code in the computer program that was affected by each patch to its pre-patch state (“In some aspects, the SVP 318 may further process the CVE and consult respective vulnerability databases to determine if there is a software version in the services catalog 320 which has a fix to the identified vulnerability in a different version of the same software. For example, if the services catalog 320 indicates availability of a different version of the service instance 328a which does not have the vulnerability (e.g., an existing version which never had the vulnerability or a version which has a patch to the vulnerability installed), then the SVP 318 may try to revert or roll back to the version of the service instance 328a which does not have the vulnerability.” ¶67). It would have been obvious for one of ordinary skill in the art prior to the filing of the claimed invention to combine the vulnerability analysis and ranking methods of Calvano Kulshreshtha and Yaron with the rolling back of updates associated with vulnerabilities as taught by Viswambharan. This would allow for a vulnerability to be fixed with an already existing version of the same software (¶67).
Regarding claims 12 and 18, they are substantially similar to claim 5 and are rejected for the same reasons shown above.
Claim(s) 6, 13, and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Calvano, Kulshreshtha and Yawalkar in view of Alibrahim (US 20240119161).
Regarding claim 6, Calvano, Kulshreshtha and Yawalkar teach the method of claim 4, Yawalkar further teaches wherein creating the non-vulnerable dataset comprises: downloading corpora of open-source (OS) projects from an OS project (“The web resources package list and the JavaScript library package list are also provided to a package information database, along with public code repositories, such as CDNJS, npm, unpkg, jsDelivr, and other open source repositories” ¶35). They do not teach analyzing the computer program using code violation testing tools to identify code violations; removing all functions and methods that are identified with the code violations; and creating a non-vulnerable) functions and methods dataset including functions or methods that do not contain any code violations from analyzing the computer program
Alibrahim teaches analyzing the computer program using code violation testing tools to identify code violations; (“Static analysis can be applied to prove the correctness of programs, or locate defects in source code” ¶37”); removing all functions and methods that are identified with the code violations; and creating a non-vulnerable) functions and methods dataset including functions or methods (“ Due to the inherent property of immutability of the DLT, once a smart contract is deployed, it cannot be modified, but can only be destroyed with a special self-destruct function (if this is defined in the source code). Therefore, if the source code contains a security vulnerability or a logical flaw, the contract must be redeployed with a new patched instance to replace the existing vulnerable one” ¶27);. It would have been obvious for one of ordinary skill in the art prior to the filing of the claimed invention to combine the code violation analysis and ranking methods with data retrieval from open source projects as taught by Calvano, Kulshreshtha and Yawalkar with the removal and replacement of vulnerable code as taught by Alibrahim. This would prevent the vulnerable functions being exploited (Alibrahim ¶28).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SEAN KEVIN MCNAMARA whose telephone number is (703)756-1884. The examiner can normally be reached Monday-Friday 7:30-5:00 EST.
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, Bryce Bonzo can be reached at 571-272-3655. 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.
/SEAN KEVIN MCNAMARA/Examiner, Art Unit 2113
/PHILIP GUYTON/Primary Examiner, Art Unit 2113