DETAILED ACTION
This is a non-final Office Action in response to communications received on 02/27/2024. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Drawings
The drawings filed on 02/27/2024 are acknowledged.
Allowable Subject Matter
The Claims 5-7, 12-14, and 19-20 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
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 1-3, 8-10, and 15-17 are rejected under 35 U.S.C. 103 over Levin (US 2022/0222351) in view of Banzhof (US 2005/0229256).
Regarding claim 1, Levin teaches the limitations of claim 1 as follows:
A method comprising: receiving a detection element that comprises a vulnerability identifier and a version identifier, wherein the vulnerability identifier corresponds to a vulnerability of an application and the version identifier corresponds to a version of the application effected by the vulnerability; (Levin, Paras. [0044]-[0053], [0058]-[0061], Figs. 2-4, the system obtains and analyzes version identifier for software packages. Also determines/receives vulnerability identifiers).
determining, by a processing device, a remediation version identifier based on the vulnerability identifier and the version identifier, wherein the remediation version identifier corresponds to a remediation version of the application that remediates the vulnerability; (Levin, Paras. [0044]-[0053], [0058]-[0061], Figs. 2-4, show selecting rules that correlate vulnerabilities with software versions, and identifying which versions are vulnerable and which ones are not. Therefore, a version is identified as vulnerable if its version identifier is earlier than or equal to the vulnerability threshold. The system determines the versions that are not vulnerable (i.e., remediation version) as the earliest versions that are not identified as vulnerable).
Levin determines a remediation version identifier of an application, but does not explicitly teach:
initiating an update at a client system based on the vulnerability identifier and the remediation version identifier.
However, Banzhof in the same field of endeavor discloses:
initiating an update at a client system based on the vulnerability identifier and the remediation version identifier. (Banzhof, Paras. [0021]-[0026], [0028]-[0033], vulnerabilities are identified using vulnerability identifiers, and are mapped to corresponding remediation signatures where each vulnerability has an associated remediation signature (i.e., a remediation version identifier). The system initiates downloads and applying updates based on the vulnerability ID and the remediation signature).
Banzhof is combinable with Levin, because both are from the same field of identifying vulnerabilities on a system/device. It would have been obvious to a person having ordinary skill in the art before the effective filling date of the invention to patch a system/device to resolve a vulnerability by using the vulnerability identifier and the remediation version identifier, as taught by Banzhof with Levin’s method in order to ensure that the right patch is selected.
As per claims 8 and 15, claims 8 and 15 encompass same or similar scope as claim 1. Therefore, claims 8 and 15 are rejected based on the reasons set forth above in rejecting claim 1.
Regarding claim 2, Levin and Banzhof teach the limitations of claim 1. Levin and Banzhof teach the limitations of claim 2 as follows:
The method of claim 1, further comprising: receiving a plurality of detection elements, wherein each one of the plurality of detection elements comprises a respective vulnerability identifier from a plurality of vulnerability identifiers, a respective version identifier from a plurality of version identifiers, (Levin, Paras. [0044]-[0053], [0058]-[0061], Figs. 2-4, S230-S240, S440 and S460 refers to identifiers from a set of identifiers (i.e., a plurality of vulnerability identifiers). And the vulnerability identification rules are selected based on the availability of version identifiers for the software (i.e., a plurality of version identifiers), including earlier vs later versions). and a corresponding operation from a plurality of operations corresponding to the respective version identifier; (Levin, Paras. [0044]-[0053], [0058]-[0061], Figs. 2-4, performing operations such as: earlier than, same as, later than, before, after, and within a threshold are operations applied to version identifiers (i.e., a plurality of operations)).
Levin does not explicitly teach:
wherein the remediation version of the application remediates each one of a plurality of vulnerabilities corresponding to the plurality of vulnerability identifiers.
However, Banzhof in the same field of endeavor discloses:
wherein the remediation version of the application remediates each one of a plurality of vulnerabilities corresponding to the plurality of vulnerability identifiers. (Banzhof, Paras. [0021]-[0026], [0028]-[0033], the system applies a remediation signature as a remediation actions to remediate vulnerabilities of software/application installed on the client system. And a remediation signature addresses one or more vulnerabilities).
The same motivation to combine utilized in claim 1 is equally applicable in the instant claim.
As per claims 9 and 16, claims 9 and 16 encompass same or similar scope as claim 2. Therefore, claims 9 and 16 are rejected based on the reasons set forth above in rejecting claim 2.
Regarding claim 3, Levin and Banzhof teach the limitations of claims 1-2. Levin teaches the limitations of claim 3 as follows:
The method of claim 2, wherein the remediation version is a different version than a most recent version of the application. (Levin, Paras. [0044]-[0053], [0058]-[0061], Figs. 2-4, a remediation version (a fixed version, patched version, or non-vulnerable version) is the first version that contains a fix for a known vulnerability. While the most recent version is the latest version).
As per claims 10 and 17, claims 10 and 17 encompass same or similar scope as claim 3. Therefore, claims 10 and 17 are rejected based on the reasons set forth above in rejecting claim 3.
Claims 4, 11, and 18 are rejected under 35 U.S.C. 103 over Levin (US 2022/0222351) in view of Banzhof (US 2005/0229256), and further in view of Velur (US 2020/0242254).
Regarding claim 4, Levin and Banzhof teach the limitations of claims 1-2. However, Velur in the same field of endeavor and Banzhof teach the limitations of claim 4 as follows:
The method of claim 2, further comprising: identifying a minimal vulnerability of the client system, wherein the minimal vulnerability corresponds to a portion of the plurality of vulnerabilities that impact the client system; (Velur, Paras. [0047]-[0052], [0079]-[0085], and Fig. 3A blocks 302-314, and Fig. 7 blocks 702-710, determines which of the vulnerabilities actually affect the specific APIs used in the client system (i.e., a portion of the plurality of vulnerabilities), narrowing the vulnerabilities to those that affect the system by filtering them, then identifying a minimal set/list of vulnerabilities).
determining a minimal remediation identifier based on the minimal vulnerability, the plurality of version identifiers, and the plurality of operations, wherein the minimal remediation identifier corresponds to a minimal remediation version of the application that remediates the portion of the plurality of vulnerabilities; (Velur, Paras. [0047]-[0052], [0079]-[0085], and Fig. 3A blocks 302-314, and Fig. 7 blocks 702-710, determines a remediation version based on the minimal set of vulnerabilities that actually affect the system, the version identifiers, and the operations by determining whether a newer version fixes the vulnerabilities that impact the system and whether an update is required).
and wherein the initiating is based on the vulnerability identifier and the minimal remediation identifier. (Banzhof, Paras. [0021]-[0026], [0028]-[0033], vulnerabilities are identified using vulnerability identifiers, and are mapped to corresponding remediation signatures where each vulnerability has an associated remediation signature (i.e., a remediation version identifier). The system initiates downloads and applying updates based on the vulnerability ID and the remediation signature).
Velur is combinable with Levin- Banzhof, because all are from the same field of identifying vulnerabilities on a system/device. It would have been obvious to a person having ordinary skill in the art before the effective filling date of the invention to patch a system/device to resolve a vulnerability by utilizing the minimal vulnerability and the minimal remediation, as taught by Velur with Levin- Banzhof’s method in order to reduce unnecessary version updates.
As per claims 11 and 18, claims 11 and 18 encompass same or similar scope as claim 4. Therefore, claims 11 and 18 are rejected based on the reasons set forth above in rejecting claim 4.
References Considered But Not Relied Upon
Oberheide (US 9,607,156) discloses a system and method of vulnerability assessment and patching system.
Dinh (US 2021/0124830) discloses a system and method that vulnerability identifiers are captured from AST structures and their derived vectors.
Conclusion
Accordingly, claims 1-20 are rejected.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to PEGAH BARZEGAR whose telephone number is (703)756-4755.
The examiner can normally be reached M-F, 9:00 - 5:30. Examiner interviews are available via telephone 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, Taghi T Arani can be reached on 571-272-3787. The fax phone number for the Application/Control Number: 17/470,067 Page 17 Art Unit: 2438 organization where this application or proceeding is assigned is 571-273- 8300. Application/Control Number: 17/386,076 Page 25 Art Unit: 2438 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/patentcenter 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.
/P.B./Examiner, Art Unit 2438 /TAGHI T ARANI/Supervisory Patent Examiner, Art Unit 2438
Prosecution Insights