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 .
This office action is in response to the amendment filed on 07/29/2026.
Claims 1, 6, 10-12, 17 and 20-24 have been amended.
Claims 2-3 and 13-14 have been cancelled.
Claims 1, 4-12 and 15-24 have been examined.
Response to Arguments
Applicant’s arguments, see Remarks, filed 07/29/2026, with respect to the rejection(s) of claims under 35 U.S.C. 103 have been fully considered and moot in view of new ground(s) of rejection set forth below.
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.
3. Claims 1, 6. 12, 17, 20 and 23-24 is/are rejected under 35 U.S.C. 103 as being unpatentable over Grieco et al. (Pub. No. US 2016/0232358), hereinafter, Greico in view of in view of Holeman et al. (US 20180191766) hereinafter Holeman in view of Papaxenopoulos; Harry et al. (US 20180336356), hereinafter Harry.
Regarding Claim 12; Grieco discloses:
A tangible, non-transitory, computer-readable medium having computer-executable instructions stored thereon that, when executed by a processor on a computer, cause the computer to perform a method comprising (See fig.1, system 10, and system 30):
identifying one or more vulnerable portions of a program to be observed based on security vulnerability information; (in [0010] and [0011], see fig. 1, identify and highlight vulnerabilities within IT infrastructure- collect metadata for software and programs.)
instrumenting the program with an observability control to configure collecting of observability information regarding the one or more vulnerable portions of the program; (in [0011], The vulnerability assessment system 30 is configured to obtain application metadata 35 for the applications (e.g., files, software, programs, etc.) observed at the devices 25(1)-25(N).))
modifying the observability control based on one or more attributes associated with the collecting of the observability information regarding the one or more vulnerable portions of the program; (in [0036], mapping application metadata based on correlation attributes to global security risk metadata.)
and collecting the observability information regarding the one or more vulnerable portions of the program [[according to the observability control as modified]] (in [0016] and [0040], fig. 2B., mapping of the metadata to the global security risk is used to generate a Vulnerable Application Dataset (VAD) 0016, 0040, fig 2B shows the VAD entries include metadata).
While Grieco discloses vulnerability assessment by collecting and mapping application metadata as discussed above, Grieco does not explicitly disclose, however, Holeman discloses the modifying of the observability control based on one or more attributes including at least one metric characterizing an amount, a logging level, or a frequency of logging of observability information, the at least one metric having been derived from logging of observability information previously performed according to the observability control, wherein instrumenting the program comprises, in response to identifying the one or more vulnerable portions, [[instrumenting one or more observability components in code in, around, or associated with the one or more vulnerable portions of the program]], the one or more observability components being configured by the observability control to collect the observability information from execution of the one or more vulnerable portions of the program (para. [0049]-[0056], event sensors collecting network and user activity including logging information, para. [0066], selectively abstract context and attribution data, either through a static configuration or using dynamic risk assessment to determine the appropriate level of data detail. Dynamic risk assessment tracks the current risk level associated with the system, user, process, and network activity, for example based upon how usual versus unusual the activity pattern appears, para. [0084], observation instrumentation may include settings for time periods of observation variability, continuous versus sampled observation, time granularity of sampling para. [0087]-[0089] observation instrumentation monitoring observation points 602 is programmable to control the extent, level, and/or detail of produced observation data,,, observation instrumentation may include settings for time periods of observation variability, continuous versus sampled observation, time granularity of sampling, etc.; settings for metadata collection versus full content capture … settings for degree of measurement precision such as approximate versus exact data transfer sizes, approximate versus exact points in time, etc.; settings for degree of expected pattern departure such as providing additional detail or measurement frequency on unusual or anomalous observations or uncharacteristic departures from normality; settings for sessions of interest such as when certain users are logged in or when the login is remote, or when the system is operated outside the enterprise network or geo boundaries, etc. (i.e profile evaluation algorithm continuously evaluate dynamic profile data and make adjustments to observation points and take particular actions))
wherein modifying the observability control includes one or both of i) changing an activation state of the observability control or ii) changing a degree of the observability information associated with the one or more vulnerable portions of the program that is collected; (para. [0036], monitoring of an endpoint to collect information from an endpoint [0083]-[0085], Profile evaluation algorithm 608 is operable to continuously evaluate dynamic profile data (collection of scores) received from analyzer 106 against policy 606 in order to make adjustments to observation points 602 and take particular actions at control points 604 ... evaluates profile data with respect to dynamic risk profiles pertaining to the current risk exposure of one or more components, dynamic performance profiles pertaining to the current performance of one or more components, and dynamic operational state profiles pertaining to the current operation states of one or more component, para. [0086], performance of control actions may allow appropriate policy-based responses to be taken to dynamically maintain risk, performance, and operational state profiles within guidelines of policy 606 or to mitigate excursions from policy guidelines application restrictions to limit or control the usage or capabilities or privileges of particular enterprise applications; user restrictions to limit which users may operate the system or its applications or during what time periods or situations, etc.; network access restrictions to restrict or limit the network access capabilities of a system and/or user and/or application (e.g., adjusting an endpoint's security policy pertaining to its firewall settings, DNS enforcement, etc.)) and
collecting, by the device, and via the one or more observability components, [[the observability information from execution of the one or more vulnerable portions of the program]] according to the observability control as modified (para. [0018]-[0019], assessment of system activity is performed dynamically using an algorithm that considers multiple metrics, para. [0059]-[0063], agent summarization and control logic how important or how likely is it that the collected information corresponds to a security threat… sensor modules assemble any suitable data records associated with user activity, file access, registry operations, performance characteristics, device attach/detach, location data, log/audit events, etc., [0086], performance of control actions may allow appropriate policy-based responses to be taken to dynamically maintain risk, performance, and operational state profiles within guidelines of policy 606 or to mitigate excursions from policy guidelines application restrictions to limit or control the usage or capabilities or privileges of particular enterprise applications; user restrictions to limit which users may operate the system or its applications or during what time periods or situations, etc.; network access restrictions to restrict or limit the network access capabilities of a system and/or user and/or application (e.g., adjusting an endpoint's security policy pertaining to its firewall settings, DNS enforcement, etc))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Griego’s that specific executable components/processes are identified as vulnerable by per-process observability controls with dynamic observability and modification by selectively collected and dynamically adjusted based on prior collected metrics and profiles taught by Holeman. One would have been motivated to do so in order to improve detection using observation points while adjusting the monitoring of the set of observation points based on the risk profile (Abstract, Herman).
While Griego in view of Holeman discloses observability instrumentation and dynamic monitoring, it does not explicitly discloses wherein instrumenting the program comprises, in response to identifying the one or more vulnerable portions, instrumenting one or more observability components in code in, around, or associated with the one or more vulnerable portions of the program, the one or more observability components being configured by the observability control to collect the observability information from execution of the one or more vulnerable portions of the program; and the observability information from execution of the one or more vulnerable portions of the program.
Harry in analogous art, however discloses wherein instrumenting the program comprises, in response to identifying the one or more vulnerable portions, instrumenting one or more observability components in code in, around, or associated with the one or more vulnerable portions of the program, the one or more observability components being configured by the observability control to collect the observability information from execution of the one or more vulnerable portions of the program; and the observability information from execution of the one or more vulnerable portions of the program. (para. [0018], the patch rules can be automatically generated and/or automatically selected based on rules expressing such previous experience, known vulnerabilities, or known computer system conditions. For example, in the above instance with source code that processes unencrypted credit card numbers, a security patch rule can be authored to encrypt the credit card number by a security subject matter expert and stored in a patch rules repository. The rule can be generated by automatically selecting from the patch rules repository by an auto-remediation service based on the detected vulnerability; para. [0029]-[0031], [0039]-[0045], [0051]-[0057], auto-remediation on computer system security vulnerabilities in source code using static analysis and/or dynamic analysis, the static and/or dynamic analysis tools can be altered or enhanced to provide additional information (also referred to herein as “additional metadata”) to the auto-remediation service. For example, some method of detecting conflicts when merging security patches can be needed such as, for example, by generating file name hashes. Additionally, some consistent method of determining line numbers and/or column numbers (i.e., for the beginning and end columns) of each line can be needed. … static and/or dynamic analysis tools can determine what portion of a string or input an attacker can control throughout a source code representation in order to determine a best location for applying a security patch).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method disclosed by Griego and Hermann with teaching of Harry. One would have been motivated to do so in order to improve auto-remediation of vulnerabilities in source code utilizing a set of security patch rules are generated that may be used to automatically remediate the vulnerabilities (Abstract, Harry).
Regarding Claim 17; Grieco in view of Holeman in view of Harry discloses: The tangible, non-transitory, computer-readable medium as in claim 12, wherein the at least one metric characterizes an amount of the observability information logged, according to the observability control, by the one or more observability components from execution of the one or more vulnerable portions of the program. (Grieco, in [0025], The vulnerable application dataset 60 may analyzed by the vulnerability assessment system 30 in a number of different ways to assess the security risks of devices 25(1)-25(N) and provide remediation information to the organization. For example, the vulnerability assessment system 30 may be configured to provide (display, email, text message, etc.) security risk assessment information to an individual associated with the organization 15(1), such as an IT manager, including a list of hosts running vulnerable software, a list of vulnerable executable applications (i.e., vulnerable applications being run by, or installed on) observed at one or more devices.) In addition, Holeman further discloses (see para. [0085]-[0086] adjusting includes controlling an amount of information… received… controlling how much… stored… or how long… stored…) Same motivation set forth for claims 12 applies.
Regarding Claim 1; Claim 1 is substantially similar in scope as Claim 12. Therefore, Claim 1 is rejected on the same grounds as Claim 12.
Regarding Claim 6; Claim 6 is substantially similar in scope as Claim 17. Therefore, Claim 6 is rejected on the same grounds as Claim 17.
Regarding Claim 20; Claim 20 is substantially similar to Claim 12. Therefore, Claim 20 is rejected on the same grounds as Claim 12. Additionally, Grieco discloses an apparatus, comprising: one or more network interfaces to communicate with a network; a processor coupled to the one or more network interfaces and configured to execute one or more processes; and a memory configured to store a process that is executable by the processor (Grieco, Fig. 3, 105, 110, 115, para. [0042], one or more network interface ports; a memory; and a processor coupled to the one or more network interface ports and the memory).
Regarding Claim 23; Grieco in view of Holeman in view of Harry discloses: The tangible, non-transitory, computer-readable medium as in claim 1. Grieco in view of Holeman in view of Harry further discloses further comprising, after collecting the observability information according to the observability control as modified: deriving, from logging of the observability information collected according to the observability control as modified, an updated value of the at least one metric characterizing an amount, a logging level, or a frequency of logging of the observability information; and again modifying the observability control based on the updated value of the at least one metric (Holeman, para. [0080]-[0082, Enterprise policy 606… set of criteria… thresholds… specifying extent, degree, granularity… and when control actions are taken….; Harry [0029]-[0031], [0039]-[0045], [0051]-[0057], [0029] In some examples, in order to perform auto-remediation on computer system security vulnerabilities in source code using static analysis and/or dynamic analysis, the static and/or dynamic analysis tools can be altered or enhanced to provide additional information (also referred to herein as “additional metadata”). The same rationale as claim 12 above applies.
Regarding Claim 24; Grieco in view of Holeman in view of Harry discloses: The tangible, non-transitory, computer-readable medium as in claim 1. Grieco in view of Holeman further discloses wherein the one or more vulnerable portions comprise one or more locations in code of the program that correspond to a vulnerability indicated by the security vulnerability information, and wherein instrumenting the one or more observability components comprises automatically selecting, based on the one or more locations in the code, one or more instrumentation locations in or around the one or more locations in code and instrumenting the one or more observability components at the one or more instrumentation locations (Holeman, para. [0050]-[0053], Network activity sensors 460… collect source/destination network address… volume of network traffic… failed DNS lookups… ARP manipulations…collects telemetry for network communication paths) Same motivation as claim 1 applies; Harry para [0039] the vulnerability data 306 can include position data and/or metadata that can be used to determine a location within the source code representation where the source … [0049], receive 502 the security patch rules and the source code changes, descriptions of the security patches, and/or other such information including metadata (e.g., location of vulnerability fixes (column, line), vulnerability fix implemented, etc.) associated with the security patch rules provided for further processing 426 (from FIG. 4)… end user can use a selection tool such as a web page interface to verify and/or not verify the security patch rules and, as a result of not verifying a security patch rule, the report can be provided to the auto-remediation service). The same rationale as claim 12 above applies.
7. Claims 4 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Grieco in view of Holeman in view of Papaxenopoulos, Harry et al. (US 20180336356), hereinafter Harry and further in view of Hibbert et al. (Pub. No. US 2014/0245376), hereinafter, Hibbert.
Regarding Claim 15; Grieco in view of Holeman in view of Harry discloses: The tangible, non-transitory, computer-readable medium as in claim 12. Grieco in view of Holman further discloses wherein the one or more attributes associated with collecting the observability information include [[a risk level associated with the one or more vulnerable portions]] of the program. (Holeman, para. [0088]-[0096], risk profile module 612… dynamically determine risk profiles… including assessed risks for a computer system or its components…)
Grieco in view of Holeman in view of Harry does not explicitly disclose:
the one or more attributes associated with collecting the observability information include a risk level associated with the one or more vulnerable portions of the program.
However, Hibbert discloses:
the one or more attributes associated with collecting the observability information include a risk level associated with the one or more vulnerable portions of the program. (Grieco, in [0022], [0248] The vulnerability checker module 1106 is configured to utilize the identified application and/or attributes to retrieve risk information. Risk information is any information associated with risk of the launching application. The risk information may include number of known vulnerabilities associated with the launching application, information regarding one or more specific vulnerabilities associated with the launching application, number of days (or any amount of elapsed time) the launching application has been unpatched, number of days (or any amount of elapsed time) since one or more vulnerabilities associated with application has been detected, whether one or more public exploits of one or more vulnerabilities exist, potential damage associated with one or more vulnerabilities to the user device 1000, potential damage associated with one or more vulnerabilities to a trust device of a network in communication with the user device 1000, CVSS scores of one or more vulnerabilities, risk values, available patch(es) that have not been utilized, number of days since unutilized patch(es) has been available, and/or the like.)
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify Grieco and Holeman and Harry with Hibbert to include the one or more attributes associated with collecting the observability information include a risk level associated with the one or more vulnerable portions of the program, as taught by Hibbert because it allows risk to be analyzed, compared to greylist, as well as comparing the risk value to a user threshold wherein providing the alert based on the risk value comprises providing the alert based on the comparison. [Hibbert 0013].
Regarding Claim 4; Claim 4 is substantially similar to Claim 15. Therefore, Claim 4 is rejected on the same grounds as Claim 15.
8. Claims 5 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Grieco in view of Holeman in view of Harry and further in view of Gathala et al. (Pub. No. US 2018/0077195), hereinafter, Gathala.
Regarding Claim 16; Grieco in view of Holeman in view of Harry discloses: The tangible, non-transitory, computer-readable medium as in claim 12. Grieco in view of Holman further discloses, wherein the one or more attributes of the one or more vulnerable portions of the program include [[a type of a vulnerability of the one or more vulnerable portions of the program]] (see Grieco, para. [0015], [0021]-[0023], vulnerability metadata entries (CVE, risk score, vector)
Grieco in view of Holeman in view of Harry does not explicitly disclose:
the one or more attributes of the one or more vulnerable portions of the program include a type of a vulnerability of the one or more vulnerable portions of the program.
However, Gathala discloses:
the one or more attributes of the one or more vulnerable portions of the program include a type of a vulnerability of the one or more vulnerable portions of the program. (in [0039], In the various embodiments, the server computing device may be configured to generate the threat-profile to include information that identifies the nature of an identified vulnerability, potential attack vectors, newly discovered non-benign software applications, recently broken exploits, vulnerabilities in the client computing devices that exploited by the non-benign software applications, types of threats discovered, types of client devices that are vulnerable to a discovered threat, and/or vulnerabilities in a client device that could be exploited by a discovered threat.)
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify Grieco in view of Holeman in view of Harry with Gathala to include the one or more attributes of the one or more vulnerable portions of the program include a type of a vulnerability of the one or more vulnerable portions of the program, as taught by Gathala because it generates a threat-profile which represents or characterizes a specific threat, facilitating the restriction, and protection against the identified threat [Gathala 0038].
Regarding Claim 5; Claim 5 is substantially similar to Claim 16. Therefore, Claim 5 is rejected on the same grounds as Claim 16.
9. Claims 7 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Grieco in view of Holeman in view of Harry and further in view of Tsitkin et al. (Pub. No. US 2020/0314137), hereinafter, Tsitkin.
Regarding Claim 18; Grieco in view of Holeman in view of Harry discloses: The tangible, non-transitory, computer-readable medium as in claim 12, wherein
Grieco in view of Holeman in view of Harry does not explicitly disclose:
the one or more attributes of the one or more vulnerable portions of the program include a cost of collecting the observability information.
However, Tsitkin discloses:
the one or more attributes of the one or more vulnerable portions of the program include a cost of collecting the observability information (in [0024], In some embodiments, the pool of actual data being collected by the data collection engine 102 may further include one or more cost of analytics and detection of the threats of cyber attacks in dollar amounts.)
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify Grieco in view of Holeman in view of Harry with Tsitkin to include the one or more attributes of the one or more vulnerable portions of the program include a cost of collecting the observability information, as taught by Tsitkin because it allows a data collection engine which may include information such as cost of analytics and detection of the threats in terms of resources required, and the number of cyber attack incidents that have been analyzed and/or detected. [Tsitkin 0177].
Regarding Claim 7; Claim 7 is substantially similar to Claim 18. Therefore, Claim 7 is rejected on the same grounds as Claim 18.
10. Claims 8 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Grieco in view of Holeman in view of Harry and further in view of Sheridan et al. (Pub. No. US 2019/0311133), hereinafter, Sheridan.
Regarding Claim 19; Grieco in view of Holeman in view of Harry discloses: The tangible, non-transitory, computer-readable medium as in claim 12, wherein
Grieco in view of Holeman in view of Harry does not explicitly disclose:
the one or more attributes of the one or more vulnerable portions of the program include a patch available for the one or more vulnerable portions of the program.
However, Sheridan discloses:
the one or more attributes of the one or more vulnerable portions of the program include a patch available for the one or more vulnerable portions of the program. (in [0039] The auto-remediation engine 208 may then use the security vulnerabilities 206 so that a patch generator 210 may generate a patch to remediate one or more of the security vulnerabilities 206 and the generated patch 212 may then be verified by a patch verifier.)
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify Grieco in view of Holeman in view of Harry with Sharidan to include the one or more attributes of the one or more vulnerable portions of the program include a patch available for the one or more vulnerable portions of the program, as taught by Sharidan because it allows performing auto-remediation, by use of security patch rules, on computer system security vulnerabilities in source code [0023].
Regarding Claim 8; Claim 8 is substantially similar to Claim 19. Therefore, Claim 8 is rejected on the same grounds as Claim 19.
11. Claims 9 is rejected under 35 U.S.C. 103 as being unpatentable over Grieco in view of Holeman in view of Harry and further in view of Waplington et al. (Pub. No. US 2022/0215100), hereinafter, Waplington.
Regarding Claim 9; Grieco in view of Holeman in view of Harry discloses: The method as in claim 1,
wherein identifying the one or more vulnerable portions of the program to be observed based on the security vulnerability information further comprises: analyzing code of the program (in [0023], Fig. 2B, vulnerability identifier in code.)
Grieco in view of Holeman in view of Harry does not explicitly disclose:
and identifying the one or more vulnerable portions of the program based on their similarity to known vulnerabilities.
However, Waplington discloses:
and identifying the one or more vulnerable portions of the program based on their similarity to known vulnerabilities. ([0031] If a vulnerability is received, and the configuration item has not been scanned for the vulnerability, then the vulnerability may be input to the machine-learning model, which may determine a similarity between the vulnerability and the past vulnerabilities of the configuration item. If the similarity is sufficiently high (e.g., greater than a threshold value), then a predicted vulnerable item may be generated that references the configuration item and the vulnerability to indicate that the configuration item may be subject to the vulnerability.)
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify Grieco in view of Holeman in view of Harry with Waplington to include and identifying the one or more vulnerable portions of the program based on their similarity to known vulnerabilities, as taught by Waplington because it allows a machine-learning model to help determine how similar past vulnerabilities of a configuration item are to an new input vulnerability (Waplington [0011].)
12. Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Grieco, in view of Holeman in view of Harry and further in view of Handurukande et al. (Pub. No. US 2021/0157926), hereinafter, Handurukande.
Regarding Claim 10; Grieco in view of Holeman in view of Harry discloses: The method as in claim 1,
Grieco in view of Holeman in view of Harry does not explicitly disclose:
wherein instrumenting the one or more observability components comprises modifying a binary of the program, a binary of one or more libraires associated with the program, or both, to include the one or more observability components.
However, Handurukande discloses:
wherein instrumenting the one or more observability components comprises modifying a binary of the program, a binary of one or more libraires associated with the program, or both, to include the one or more observability components. (in [0045], Control parameters may provide and specify configuration and operating options for the control instructions and other functionality of the system 100. The system 100 may further include various databases or data sources, each of which may be accessed by the system 100 to obtain data for consideration during any one or more of the processes. Fig. 10 is an example of control flow path involving vulnerable portions of a program)
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify Grieco in view of Holeman in view of Harry with Handurukande to include, instrumenting a control flow path to report its flow involving the one or more vulnerable portions of the program, and combinations thereof, as taught by Handurukande because it allows a path to reporting of vulnerability data initially from the scan engine to the vulnerability report engine, which generates the vulnerability report [Handurukande 0021].
13. Claims 11 is rejected under 35 U.S.C. 103 as being unpatentable over Grieco in view of Holeman in view of Harry and further in view of Bang et al. (Pub. No. US 2016/0300065), hereinafter, Bang.
Regarding Claim 11; Grieco in view of Holeman in view of Harry discloses: The method as in claim 1. Grieco in view of Holeman in view of Harry discloses wherein instrumenting the program further comprises, using at least one of the one or more observability components, instrumenting [[a data flow involving the one or more vulnerable portions of the program or instrumenting a control flow path involving the one or more vulnerable portions]] of the program to report a flow of the control flow path. (Holeman, [para. [0032], [0086], the vulnerability assessment system 30 determines that a device … is running a piece of software that is vulnerable … the vulnerability assessment system 30 could trigger deeper inspections … information about vulnerable software can be provided to systems that would redirect traffic … actions taken at control points 604 may be performed globally or locally depending on what is being observed … if observation instrumentation is consuming too much network bandwidth, a control action to reduce the amount of what is being reported may be taken at some observation points 602, but not all).
Grieco in view of Holeman in view of Harry does not explicitly disclose, however, Bang discloses: instrumenting [a data flow involving the one or more vulnerable portions of the program or instrumenting a control flow path involving the one or more vulnerable portions]] of the program to report a flow of the control flow path (in [0043], tagged vulnerabilities 157 may reduce redundancies in system 100. Before storing a new tagged vulnerability 157 in reporting database 159, vulnerability optimization processor 154 may first scan reporting database 159 to determine whether there is already a tagged vulnerability 157 having the same vulnerability identifier, application identifier, and review version.)
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify Grieco in view of Holeman in view of Harry with Bang to include wherein modifying the observability control includes reducing collection of the observability information regarding the one or more vulnerable portions of the program when the one or more vulnerable portions of the program are used for collection of observability data, as taught by Bang because it allows for tracking and synchronization of application vulnerabilities, resulting in reduced processing requirements for application scanning and vulnerability reporting. [Bang 0005].
Claims 21-22 are rejected under 35 U.S.C. 103 as being unpatentable over Grieco in view of Holeman in view of Harry and further in view of Katta (Pub. No. US 2022/0414226).
Regarding Claim 21;
Grieco in view of Holeman in view of Harry teaches the method of claim 1. Grieco in view of Holeman in view of Harry does not explicitly teach wherein the one or more attributes further comprise an indication that the observability information includes collected by the one or more observability components from execution of the one or more vulnerable portions of the program includes sensitive data.
However, Katta discloses wherein the one or more attributes further comprise an indication that the observability information includes collected by the one or more observability components from execution of the one or more vulnerable portions of the program includes sensitive data. (para. [0018]-[0019], dynamic detection of vulnerable credentials… provide credential vulnerability protection by detecting a login attempt from a user, and dynamically generating an executable code module that is configured to request a vulnerability check, in response to that detection)
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify Grieco in view of Holeman in view of Harry with Katta to include the observability information includes sensitive data, as taught by Katta in order to protect sensitive data while providing an alert regarding the vulnerability (Abstract, Katta).
Regarding Claim 22;
Grieco in view of Holeman in view of Harry in view of Katta teaches the method of claim 22. Grieco in view of Holeman in view of Katta further discloses wherein modifying the observability control comprises reducing collection or logging of at least a portion of the observability information by the one or more observability components to reduce a risk of exposing the sensitive data. (Katta, para. [0019-[0020], code module is configured to extract the credentials and send a request to a vulnerability checking service to validate the credentials (e.g., determine whether they are vulnerable or safe) … to transmit the results of the vulnerability check back to the ADS server… security action can then be performed based on the results of the vulnerability check (including blocking the credential submission to the remote server, requiring that the vulnerable credentials be updated)). The same rationale set forth for claim 21 above applies.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Rajan et al., (US 11347853) - directed to monitoring and binary translation software allow detection of return-oriented programming (ROP) exploits with low overhead and low false positive rates.
Lamont et al. (US 20090165135) - directed A system and method determines whether software includes malicious code. A validation machine is instrumented with tools and monitors that capture the static and dynamic behavior of software. Software under examination is executed on the validation machine, and the tools and monitors are used to log data representative of the behavior of the software to detect vulnerable or malicious code.
Sharma et al. (20210073107) directed to test source code changes. The techniques include generating an incremental intermediate representation of a security vulnerability fix to repair an identified security vulnerability of a source code application. The techniques also include merging the incremental intermediate representation with a full intermediate representation of a previous version of the source code application
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Shewaye Gelagay whose telephone number is (571)272-4219. The examiner can normally be reached Monday to Friday 8 A.M. - 4 P.M..
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, Amy Cohen Johnson can be reached at (571) 272 2238. 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.
/SHEWAYE GELAGAY/Supervisory Patent Examiner, Art Unit 2436
