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 .
1.This action is responsive to Election/ Restriction filed May 07, 2026. In response to the Restriction Requirement mailed March 23, 2026, Applicant elects Invention I drawn to claims 1-16 and 28-33 for prosecution on the merits. Therefore, claims 1-16 and 28-33 are pending.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Double Patenting
2. The statutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the "right to exclude" granted by a patent and to prevent possible harassment by multiple assignees. A statutory obviousness-type double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Omum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969). A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a statutory double patenting ground provided the conflicting application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement.
Effective January 1, 1994, a registered attorney or agent of record may sign a terminal disclaimer. A terminal disclaimer signed by the assignee must fully comply with 37 CFR 3.73(b).
Claims 1-7, 9-12 and 14-16 are rejected on the ground of statutory obviousness-type double patenting as being unpatentable over claims 1-14 of US Patent number 12072984. The conflicting claims are identical, they are not patentably distinct from each other because the current application contains claims that are identical in scope than the claims of the patent number 12072984 and are anticipated by the claims 12072984.
This is a Non-provisional double patenting rejection.
Claims Comparison Table
Instant Application 18/785,160
Patent Application 12072984
1. A computer-implemented method for monitoring vulnerabilities in a distributed computing environment, comprising: receiving, by a vulnerability identifier, vulnerability data, where the vulnerability data identifies one or more libraries affected by vulnerabilities, and identifies application programming interfaces (APIs) of the identified libraries which are affected by the vulnerabilities; detecting, by a library load sensor, loading of a given library by a monitored process running under an operating system of a host computer, where the library load sensor is injected into library loading functionality of the monitored process; in response to detecting the loading of the given library by the library load sensor, extracting, by the library load sensor, library data for the given library; determining, by the vulnerability identifier, whether the given library is vulnerable using the vulnerability data, where determining whether the given library is vulnerable includes comparing the library data for the given library with library data contained in the vulnerability data; detecting, by an API sensor, a given API that was called by the monitored process, where the given API resides in the given library and the API sensor is injected into the monitored process; determining, by the vulnerability identifier, whether the given API is affected by vulnerabilities using the vulnerability data; and indicating, by the vulnerability identifier, a particular vulnerability of the monitored process in response to a determination that the given library is vulnerable and a determination that the given API is vulnerable.
1. A computer-implemented method for monitoring vulnerabilities in a distributed computing environment, comprising: receiving, by a vulnerability identifier, vulnerability data, where the vulnerability data identifies one or more libraries affected by vulnerabilities, and identifies application programming interfaces (APIs) of the identified libraries which are affected by the vulnerabilities; detecting, by a library load sensor, loading of a given library by a monitored process running under an operating system of a host computer, where the library load sensor is injected into library loading functionality of the monitored process; in response to detecting the loading of the given library by the library load sensor, extracting, by the library load sensor, library data for the given library; determining, by the vulnerability identifier, whether the given library is vulnerable using the vulnerability data, where determining whether the given library is vulnerable includes comparing the library data for the given library with library data contained in the vulnerability data; detecting, by an API sensor, a given API that was called by the monitored process, where the given API resides in the given library and the API sensor is injected into the monitored process; determining, by the vulnerability identifier, whether the given API is affected by vulnerabilities using the vulnerability data; indicating, by the vulnerability identifier, a particular vulnerability of the monitored process in response to a determination that the given library is vulnerable and a determination that the given API is vulnerable; and receiving, by a vulnerability priority processor, a given topology entity on which the particular vulnerability was observed; retrieving a record for the given topology entity in a topology model, where the record represents the monitored process, and the topology model is defined as a graph with nodes representing entities in the distributed computing environment and edges representing communication between entities in the distributed computing environment; analyzing, by the vulnerability priority processor, connections between the given topology entity and other entities in the topology model, where the topology model identifies a subset of entities in the topology model that communicate with untrusted entities; calculating, by the vulnerability priority processor, a reachability priority score for the monitored process based on connections between the given topology entity and one or more entities that communicate with untrusted entities, where calculating the reachability priority score includes determining whether the connections of the topology model indicate that the monitored process is reachable from at least one untrusted entity; in response that topology model connections indicate no reachability, setting a reachability priority score indicating that the monitored process is not reachable from an untrusted entity; otherwise, setting a reachability priority score depending on a topological distance between the monitored process and the at least one untrusted entity.
2. The method of claim 1 further comprises determining, by the library load sensor, the library data for the given library, where the library data includes name of library, version of the library and a vendor associate with the library; and sending, by the library load sensor, the library data to a monitoring server, where the monitoring server is located remotely from the host computer.
2. The method of claim 1 further comprises determining, by the library load sensor, the library data for the given library, where the library data includes name of library, version of the library and a vendor associate with the library; and sending, by the library load sensor, the library data to a monitoring server, where the monitoring server is located remotely from the host computer.
3. The method of claim 2 further comprises determining, by the API sensor, call data for the given API, where the call data includes name of a method and name of a class; and sending, by the API sensor, the call data to the monitoring server.
3. The method of claim 2 further comprises determining, by the API sensor, call data for the given API, where the call data includes name of a method and name of a class; and sending, by the API sensor, the call data to the monitoring server.
4. The method of claim 3 wherein the vulnerability identifier resides on the host computer.
4. The method of claim 3 wherein the vulnerability identifier resides on the host computer.
5. The method of claim 3 wherein the vulnerability identifier resides on the monitoring server.
5. The method of claim 3 wherein the vulnerability identifier resides on the monitoring server.
6. The method of claim 5 further comprises receiving, by the vulnerability identifier, the vulnerability data; receiving, by the vulnerability identifier, the library data; comparing, by the vulnerability identifier, the library data to the vulnerability data; and generating, by the vulnerability identifier, a vulnerability issue report when the given library identified by the library data matches a library identified in the vulnerability data, where the vulnerability issue report identifies the given library loaded into the monitored process.
6. The method of claim 5 further comprises receiving, by the vulnerability identifier, the vulnerability data; receiving, by the vulnerability identifier, the library data; comparing, by the vulnerability identifier, the library data to the vulnerability data; and generating, by the vulnerability identifier, a vulnerability issue report when the given library identified by the library data matches a library identified in the vulnerability data, where the vulnerability issue report identifies the given library loaded into the monitored process.
7. The method of claim 6 further comprises assigning, by a vulnerability priority processor, a vulnerability score to each vulnerability issue report, where the vulnerability score quantifies risk associated with the library identified in the vulnerability issue report; and presenting, by the vulnerability priority processor, one or more vulnerability issue reports on a display according to the vulnerability score associated with the vulnerability issue report.
7. The method of claim 6 further comprises assigning, by a vulnerability priority processor, a vulnerability score to each vulnerability issue report, where the vulnerability score quantifies risk associated with the library identified in the vulnerability issue report; and presenting, by the vulnerability priority processor, one or more vulnerability issue reports on a display according to the vulnerability score associated with the vulnerability issue report.
9. The method of claim 8 further comprises receiving, by a call data processor residing on the monitoring server, call data for the given API executed by the monitored process, where the call data includes name of a method and name of a class; retrieving, by the call data processor, a record for a topology entity in a topology model, where the record represents the monitored process, and the topology model is defined as a graph with nodes representing entities in the distributed computing environment and edges representing communication between entities in the distributed computing environment; and updating, by the call data processor, the retrieved record with the call data.
8. The method of claim 7 further comprises receiving, by a call data processor residing on the monitoring server, call data for the given API executed by the monitored process, where the call data includes name of a method and name of a class; and updating, by the call data processor, the retrieved record with the call data.
10. The method of claim 9 further comprises retrieving, by the vulnerability processor, the record for the topology entity that represents the monitored process; from the retrieved record, retrieving, by the vulnerability processor, call data for one or more APIs called by the monitored process; for each of the one or more APIs, updating, by the vulnerability processor, the vulnerability issue report with the call data for the one or more retrieved APIs, where the library providing an API from the one or more retrieved APIs matches the library associated with the vulnerability report.
9. The method of claim 8 further comprises retrieving, by the vulnerability processor, the record for the topology entity that represents the monitored process; from the retrieved record, retrieving, by the vulnerability processor, call data for one or more APIs called by the monitored process; for each of the one or more APIs, updating, by the vulnerability processor, the vulnerability issue report with the call data for the one or more retrieved APIs, where the library providing an API from the one or more retrieved APIs matches the library associated with the vulnerability report.
11. The method of claim 10 wherein assigning a vulnerability score further comprises calculating a usage priority score for the monitored process based on frequency the one or more APIs are called by the monitored process, and updating the vulnerability issue report with the usage priority score.
10. The method of claim 9 wherein assigning a vulnerability score further comprises calculating a usage priority score for the monitored process based on frequency the one or more APIs are called by the monitored process, and updating the vulnerability issue report with the usage priority score.
12. The method of claim 11 wherein assigning a vulnerability score further comprises receiving, by the vulnerability priority processor, a given topology entity on which a vulnerability was observed; analyzing, by the vulnerability priority processor, connections between the given topology entity and other entities in the topology model, where the topology model identifies a subset of entities in the topology model that communicate with untrusted entities; calculating, by the vulnerability priority processor, a reachability priority score for the monitored process based on connections between the given topology entity and one or more entities that communicate with untrusted entities, where calculating the reachability priority score includes determining whether the connections of the topology model indicate that the monitored process is reachable from at least one untrusted entity; in response that topology model connections indicate no reachability, setting a reachability priority score indicating that the monitored process is not reachable from an untrusted entity; otherwise, setting a reachability priority score depending on a topological distance between the monitored process and the at least one untrusted entity.
11. The method of claim 10 wherein assigning a vulnerability score further comprises analyzing, by the vulnerability priority processor, connections between the given topology entity and other entities in the topology model, where the other entities store sensitive data; calculating, by the vulnerability priority processor, an access priority score for the monitored process based on connections between the given topology entity and the other entities in the topology model, where calculating the access priority score includes determining whether the connections of the topology model indicate that at least one of the other entities is reachable from the monitored process; in response that topology model connections indicate no reachability, setting an access priority score indicating that no other entity is reachable from the monitored process; otherwise, setting an access priority score depending on a topological distance between the monitored process and the at least one of the other entities.
14. The method of claim 1 further comprises instrumenting application code with a transaction sensor, where the transaction sensor executes within the monitored process and is configured to monitor a performance metric associated with execution of the application code.
12. The method of claim 1 further comprises instrumenting application code with a transaction sensor, where the transaction sensor executes within the monitored process and is configured to monitor a performance metric associated with execution of the application code.
15. The method of claim 14 further comprises receiving, by an in-process agent, a listing of instrumentation instructions, where the in-process agent is injected into the monitored process; instrumenting, by the in-process agent, the monitored process with the load sensor and the transaction sensor; and instrumenting, by the in-process agent, the given API with the API sensor in accordance with a given instrumentation instruction from the listing of instrumentation instructions, where instrumenting the given API with the API sensor includes detecting loading of code by the monitored process, comparing a signature of an API contained in the loaded code with at least one API signature pattern contained in the listing of instrumentation instructions, and instrumenting the API sensor in response to a match of the API signature with the at least one API signature pattern.
13. The method of claim 12 further comprises receiving, by an in-process agent, a listing of instrumentation instructions, where the in-process agent is injected into the monitored process; instrumenting, by the in-process agent, the monitored process with the load sensor and the transaction sensor; and instrumenting, by the in-process agent, the given API with the API sensor in accordance with a given instrumentation instruction from the listing of instrumentation instructions, where instrumenting the given API with the API sensor includes detecting loading of code by the monitored process, comparing a signature of an API contained in the loaded code with at least one API signature pattern contained in the listing of instrumentation instructions, and instrumenting the API sensor in response to a match of the API signature with the at least one API signature pattern.
16. The method of claim 15 further comprise analyzing, by the vulnerability identifier, the vulnerability data to create the listing of instrumentation instructions; and sending, by the vulnerability identifier, the listing of instrumentation instructions to the in-process agent.
14. The method of claim 13 further comprise analyzing, by the vulnerability identifier, the vulnerability data to create the listing of instrumentation instructions; and sending, by the vulnerability identifier, the listing of instrumentation instructions to the in-process agent.
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- 2 and 28-33 are rejected under 35 U.S.C 103 as being unpatentable over Vu, US 20220070197 A1 in view of Williams, US 20120222123 A1.
1.Vu discloses a computer-implemented method for monitoring vulnerabilities in a distributed computing environment, (See Vu, abstract; detecting vulnerabilities in real-time during execution of a process or an application. See also [0074] Sensors 310 can monitor network traffic between nodes, monitor processes executed on sensors 310, and send network traffic data and other data (e.g., host data, process data, user data, package data, vulnerability data, etc.) to the backend component 350. For example, sensors 310 can sniff packets being sent over its hosts' physical or virtual network interface card (NIC), or individual processes can be configured to report network traffic and corresponding data to sensors 310.) comprising:
receiving, by a vulnerability identifier, vulnerability data, where the vulnerability data identifies one or more libraries affected by vulnerabilities, and identifies application programming interfaces (APIs) of the identified libraries which are affected by the vulnerabilities; (See Vu, [0078]; Backend component 350 is configured to receive process attributes or process information associated with processes executing on sensors 310. Furthermore, backend component 350 may also be configured to receive package attributes or package information associated with processes executing on sensors 310. Backend component 350 may then utilize vulnerability database 370 to identify processes 320a and packages 330a ( i.e., libraries) that may have vulnerabilities or exploits. Backend component 350 may also be configured to have or be an API, such that backend component 350 can notify and/or display vulnerabilities to a user or an administrator. It is further contemplated that backend component 350 may have one or more processors 360 to implement the above. [0079] In one aspect, backend component 350 may be a cluster. Accordingly, backend component 350 may be configured with a plurality of processors 360 to distribute receiving process information and/or package information, accessing vulnerability database 370, and identifying vulnerabilities across various nodes. For example, backend component 350 may be a software cluster configured to allocate receiving process information and/or package information to certain nodes, while allocating accessing vulnerability database 370 and identifying vulnerabilities to other nodes. [0080] Vulnerability database 370 may be stored on and/or in communication with backend component 350. Vulnerability database 370 stores reports, information, and vulnerabilities associated with packages 330. Additionally, vulnerability database 370 is configured to communicate reports, information, and vulnerabilities associated with packages 330 to backend component 350. Thus, backend component 350 may identify vulnerabilities of packages 330 by accessing vulnerability database 370 with corresponding package information. In one aspect, the database of vulnerabilities is stored in a location other than an endpoint. [0076]; Sensors 310 can collect package information and send the package information to backend component 350. For example, sensors 310 can collect package information using MSI API and/or an enumerating registry. See also [0084]; In one aspect, the package information includes a package name, a package version, and a package publisher. Thus, process vulnerability mapping system 300 can associate running processes with packages based on process information.)
detecting, by a library load sensor, loading of a given library by a monitored process running under an operating system of a host computer, where the library load sensor is injected into library loading functionality of the monitored process; (See VU, [0009]; mechanism for identifying vulnerabilities in processes by obtaining real-time process information, determining package information for packages associated with the processes using sensors installed within processes or on associated endpoints, and providing the package information and process information to a backend component. Accordingly, this mechanism can identify vulnerabilities in a process while the process is executing (during runtime), and eliminates the need for sensors and endpoints to maintain a database of Common Vulnerabilities and Exposures (CVEs) for detection of network/process vulnerabilities. See also [0083] Method 400 begins at step 402, in which process vulnerability mapping system 300 obtains real-time process information associated with a process executing on an endpoint. For example, sensor 310 may create a running snapshot of processes executing thereon. The snapshot of processes may show a process, such as Microsoft Word. Additionally, the snapshot may include process information, such as the process name (e.g. word.exe), the executable path (e.g. C://Program Files/Microsoft Office/word.exe), etc. Thus, the process information can include process attributes as discussed above with respect to FIG. 3. As another example, one or more processors 360 may receive the running snapshot of processes executing on sensors 310. In one aspect, the process information of the process is obtained by one or more sensors 310 running on the endpoint. In one aspect, the process information may include an executable path and filename for the process.)
in response to detecting the loading of the given library by the library load sensor, extracting, by the library load sensor, library data for the given library; (See Vu, [0084]; In one aspect, one or more sensors 310 of process vulnerability mapping system 300 determines the package based on the executable path and filename of the process. In one aspect, the package information includes a package name, a package version, and a package publisher. Thus, process vulnerability mapping system 300 can associate running processes with packages based on process information.)
determining, by the vulnerability identifier, whether the given library is vulnerable using the vulnerability data, where determining whether the given library is vulnerable includes comparing the library data for the given library with library data contained in the vulnerability data; (See Vu, [0010] In one aspect, a method includes obtaining real-time process information associated with a process executing in an endpoint, determining package information for a package associated with the process based on the process information, and identifying at least one vulnerability associated with the package information using a database of vulnerabilities stored on a backend component of the network controller. The backend component may have a database of vulnerabilities for packages.)
determining, by the vulnerability identifier, whether the given API is affected by vulnerabilities using the vulnerability data; (See Vu, [0021] AND [0086]; For example, a sensor may be deployed at an endpoint (e.g., a Windows sensor) that can collect information related to packages installed, as well as extract information from currently executed processes to associate the processes with their respective package (e.g., whether a process belongs to a specific package such as a version of Outlook in the above example). With information gathered for package information, execution path, executables, publisher, architecture, etc., vulnerabilities in packages may be periodically (or in an event-based manner such as installation of a new package) ascertained at a backend component, such as a cluster. The cluster may determine Common Vulnerabilities and Exposures (CVEs) in the packages based on consulting databases such as National Vulnerability Database (NVD) or others. Then, if any existing processes are associated with packages affected by a known CVE, such processes may be flagged, based on snapshots of processes obtained periodically. One advantageous aspect of this process is elimination of the need for requiring sensors/endpoints to maintain a database of known CVEs, resulting in more efficient use of network processing resources and capabilities.)
and indicating, by the vulnerability identifier, a particular vulnerability of the monitored process in response to a determination that the given library is vulnerable and a determination that the given API is vulnerable. (See Vu, [0021] For example, a sensor may be deployed at an endpoint (e.g., a Windows sensor) that can collect information related to packages installed, as well as extract information from currently executed processes to associate the processes with their respective package (e.g., whether a process belongs to a specific package such as a version of Outlook in the above example). With information gathered for package information, execution path, executables, publisher, architecture, etc., vulnerabilities in packages may be periodically (or in an event-based manner such as installation of a new package) ascertained at a backend component, such as a cluster. The cluster may determine Common Vulnerabilities and Exposures (CVEs) in the packages based on consulting databases such as National Vulnerability Database (NVD) or others. Then, if any existing processes are associated with packages affected by a known CVE, such processes may be flagged, based on snapshots of processes obtained periodically. One advantageous aspect of this process is elimination of the need for requiring sensors/endpoints to maintain a database of known CVEs, resulting in more efficient use of network processing resources and capabilities. [0080] Vulnerability database 370 may be stored on and/or in communication with backend component 350. Vulnerability database 370 stores reports, information, and vulnerabilities associated with packages 330. Additionally, vulnerability database 370 is configured to communicate reports, information, and vulnerabilities associated with packages 330 to backend component 350. Thus, backend component 350 may identify vulnerabilities of packages 330 by accessing vulnerability database 370 with corresponding package information. In one aspect, the database of vulnerabilities is stored in a location other than an endpoint.)
Vu does not appear to explicitly disclose detecting, by an API sensor, a given API that was called by the monitored process, where the given API resides in the given library and the API sensor is injected into the monitored process;
However, Williams discloses detecting, by an API sensor, a given API that was called by the monitored process, where the given API resides in the given library and the API sensor is injected into the monitored process; (See Williams, [0005]; detecting the presence of at least one vulnerability in an application. The method includes modifying instructions of the application to include at least one sensor that is configurable to generate an event indicator, wherein the event indicator includes at least some data associated with the event. The method further includes storing the event indicator with the other stored event indicators generated by the at least one sensor during the execution of the application, analyzing the stored event indicators, detecting a presence of at least one vulnerability in the application based on the analysis of the stored event indicators, and reporting the presence of at least one vulnerability. Other implementations of this aspect include corresponding systems, apparatus, computer readable media, and computer program products. [0023] Implementations of the present disclosure are generally directed to a method for detecting a presence of at least one vulnerability in a software application. More specifically, implementations of the present disclosure relate to how the instructions of the application are modified to include at least one sensor that is configurable to generate one or more the event indicator, the event indicators are stored and analyzed, and a presence of at least one vulnerability is detected based on the analysis of the stored event indicators. Additionally, the detected vulnerabilities are reported to a user. [0034] The vulnerability detection system 200 inserts software sensors into each of the methods designated by the events in the security rules--a process referred to as "instrumentation." During execution of the application 230, each inserted sensor generates data that is collected and analyzed by the tracking module 240 whenever the instrumented method is invoked. This collected data, referred to as an "event indicator" is essentially a snapshot of data associated with the method instrumented for a particular event. For example, the event indicator can include various information associated with the invoked method, such as the parameters of the method, the copy of the object that invoked the method, the return value of the method, or the trace of the stack at the time the method was called.)
VU and Williams are analogous art because they are from the same field of endeavor which is vulnerability detection and testing in computer systems. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of VU with the teaching of Williams to include the API injection because it would have been used to detecting the presence of vulnerabilities in a software application. (See Williams, [0004])
2. The combination of VU and Williams discloses the method of claim 1 further comprises determining, by the library load sensor, the library data for the given library, where the library data includes name of library, version of the library and a vendor associate with the library; (See Vu, [0076] One or more packages 330 may run on and/or communicate with sensors 310. Packages 330 may include computer-readable instructions corresponding to processes 320. For example, packages may be installed on sensors 310 using MSI installers or EXE installers. Furthermore, packages 330 can be located based on process attributes of processes 320. For example, packages 330 can be located based on executable paths of respective processes 320. Packages 330 may have package attributes or package information. Package attributes may relate to package data and can include package name (e.g. packagename0.tar.gz, packagenamel.apk, etc.), package ID, package version number, package size, package type (e.g. 32-bit or 64-bit), date of installation, date of last modification, executable path (e.g., /usr2/username/bin/, /usr/local/bin, /usr/bin, etc.), processes included in and/or associated with the packages, package publisher, etc. Furthermore, the executable path of packages 330 may be the same as the executable path of processes 320 due to the nature of the packages 330. Sensors 310 can collect package information and send the package information to backend component 350. For example, sensors 310 can collect package information using MSI API and/or an enumerating registry.) and sending, by the library load sensor, the library data to a monitoring server, where the monitoring server is located remotely from the host computer. (See Vu, [0050])
28. The combination of VU and Williams discloses the method of claim 1 wherein extracting the library data for the given library includes determining a technology type for the monitored process; selecting a library identity evidence data extraction configuration based on the technology type, where the library identity evidence data extraction configuration defines an extraction method; (See Vu, [0021], [0086], [0084]; In one aspect, one or more sensors 310 of process vulnerability mapping system 300 determines the package based on the executable path and filename of the process. In one aspect, the package information includes a package name, a package version, and a package publisher. Thus, process vulnerability mapping system 300 can associate running processes with packages based on process information.) and extracting at least a portion of the library data using the extraction method. (See Vu, [0021], [0084], [0086]; In one aspect, one or more sensors 310 of process vulnerability mapping system 300 determines the package based on the executable path and filename of the process. In one aspect, the package information includes a package name, a package version, and a package publisher. Thus, process vulnerability mapping system 300 can associate running processes with packages based on process information.)
29. The combination of VU and Williams discloses the method of claim 1 further comprising maintaining, by an instrumentation manager, an instrumentation vulnerability mapping which maps APIs potentially affected by vulnerabilities to versions of libraries affected by those vulnerabilities, (See Williams, [0007]; [0007] In addition, these and other implementations can optionally include modifying instructions of the application to include at least one sensor based on at least one security rule. The security rule can verify that the application has a code segment that prevents a vulnerability risk. The security rule can also verify that the application does not have a code segment that creates a vulnerability risk. The security rule can include description of a triggering condition that, when satisfied, causes the sensor to generate an indicator of an event. The triggering condition can be satisfied when the application fails to securely authenticate a request or a response.) where those vulnerabilities are reported by vulnerability reports contained in the vulnerability data and a given vulnerability report contains a vulnerability report identifier, (See Williams, [0005-0007]) a vulnerability type and a vulnerability severity. (See Williams, [0083] FIG. 11 is a screen-shot of an example GUI 1100 used for specifying a security rule. The GUI 1100 includes a number of fields used to specify the details of a security rule that identifies a particular vulnerability. The GUI 1100 includes, among others elements, fields that permit the user to specify whether the rule is enabled or disabled, the name of the rule, and the shorthand id of the rule. In addition, the GUI 1100 includes fields that specify the category of the rule, the severity of the vulnerability identified by the rule, the risk associated with the vulnerability, the recommendation for fixing the vulnerability, and references to the internet or article sources that provide more information about the detected vulnerability.) VU and Williams are analogous art because they are from the same field of endeavor which is vulnerability detection and testing in computer systems. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of VU with the teaching of Williams to include the API injection because it would have been used to detecting the presence of vulnerabilities in a software application. (See Williams, [0004])
30. The combination of VU and Williams discloses the method of claim 29, wherein the instrumentation vulnerability mapping contains at least one vulnerability mapping entry, and each of the at least one vulnerability entries includes an instrumentation identifier and list of vulnerable library identifier records, such that each vulnerable library identifier record in the list of vulnerable library identifier records identifies a version of a library containing an API that matches the instrumentation identifier, (See Williams, [0041]; [0041] The process of inserting sensors in the application 230 is referred to as "instrumentation." Vulnerability detection system 200 uses the policy editor module 210 to govern the process of instrumenting the application 230. In particular, with the policy editor module 210, an administrative user can create or edit one or more security rules 302 that specify methods within the application 230 that require instrumentation with one or more sensors. In addition, security rules 302 can also specify a pattern that signals a presence of a security vulnerability, as well as other control information. Security rules 302 can also specify lists of methods that return untrusted data, methods that propagate data from one object to another, and methods that represent security controls. Policy editor module 210 can store the security rules 302 and can also provide a Graphical User Interface (GUI) to an administrative user to enable the user to add new security rules or make changes to the existing security rules. In other implementations, a text processor that permits editing and saving of security rules in some common file format can be used in addition or alternatively to the policy editor module 210. Security rules 302 can be implemented in XML or any other type of declarative or programming language. An exemplarily syntax for specifying security rules is illustrated in Appendix A.) and a vulnerability report for the vulnerability by which the version of the library is affected. (See Williams, [0078] ) VU and Williams are analogous art because they are from the same field of endeavor which is vulnerability detection and testing in computer systems. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of VU with the teaching of Williams to include the API injection because it would have been used to detecting the presence of vulnerabilities in a software application. (See Williams, [0004])
31. The combination of VU and Williams discloses the method of claim 30, wherein the instrumentation identifier identifies an API method to which an API sensor is injected, and the instrumentation identifier is created as a hash of the name of the API method and a name of the class containing the API method. (See Williams, [0064] In another example, a security rule can check whether the application 230 performs proper encryption. This could be checked by verifying that that only strong cryptographic algorithms, strong hash algorithms, and strong random numbers are used by the application 230. The security rule can also verify that sensitive information is encrypted before storage.) VU and Williams are analogous art because they are from the same field of endeavor which is vulnerability detection and testing in computer systems. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of VU with the teaching of Williams to include the API injection because it would have been used to detecting the presence of vulnerabilities in a software application. (See Williams, [0004])
32. The combination of VU and Williams discloses the method of claim 31, wherein the API sensor is configured to send call data for a called API method, along with an instrumentation identifier for the called API method. (See Williams, [0054] The event field 508 can also include a method signature field 510, which indicates the signature or the name of the method that is being instrumented for this event, such as "javax.servlet.Servelet.service( )." The instrumentation module 220 will instrument all methods that match the pattern listed by the event. The event field 508 can also include parameters field 511 that specifies input parameters passed to the specified method. In addition, the event field 508 can include a return value field 512 that specifies the required value to be returned by the method (e.g., "true".) These input and output parameters, as well as the object values, can be used by the tracking module 240 to determine whether the event matches a vulnerability pattern.) VU and Williams are analogous art because they are from the same field of endeavor which is vulnerability detection and testing in computer systems. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of VU with the teaching of Williams to include the API injection because it would have been used to detecting the presence of vulnerabilities in a software application. (See Williams, [0004])
33. The method of 32, wherein the vulnerability identifier uses the instrumentation identifier contained in the call data to select a vulnerability mapping entry for the called API method, and the library data provided by the library load sensor to select a vulnerable library identifier record from the selected vulnerability mapping entry. (See Vu, [0041], [0050], [0071], [0078])
Claims 3-6 are rejected under 35 U.S.C 103 as being unpatentable over Vu, US 20220070197 A1 in view of Williams, US 20120222123 A1 in further view of Dalessio, US pat. No 10229251(IDS Submitted, 07/26/2024).
3. The combination of VU and Williams discloses the method of claim 2 further comprises determining, by the API sensor, call data for the given API, where the call data includes name of a method and name of a class; (See Williams, [0054] The event field 508 can also include a method signature field 510, which indicates the signature or the name of the method that is being instrumented for this event, such as "javax.servlet.Servelet.service( )." The instrumentation module 220 will instrument all methods that match the pattern listed by the event. The event field 508 can also include parameters field 511 that specifies input parameters passed to the specified method. In addition, the event field 508 can include a return value field 512 that specifies the required value to be returned by the method (e.g., "true".) These input and output parameters, as well as the object values, can be used by the tracking module 240 to determine whether the event matches a vulnerability pattern.)
The combination of VU and Williams does not appear to explicitly disclose and sending, by the API sensor, the call data to the monitoring server.
However, Dalessio discloses and sending, by the API sensor, the call data to the monitoring server. (See Dalessio, fig 3; data and report server exchange)
VU, Williams and Dalessio are analogous art because they are from the same field of endeavor which is vulnerability detection and testing in computer systems. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of VU and Williams with the teaching of Dalessio to include the report because it would have prevented unauthorized information from accessing the system.
4. The combination of VU, Williams and Dalessio discloses the method of claim 3 wherein the vulnerability identifier resides on the host computer. (See vu, [0009])
5. The combination of VU, Williams and Dalessio discloses the method of claim 3 wherein the vulnerability identifier resides on the monitoring server. (See vu, [0071])
6. The combination of VU, Williams and Dalessio discloses the method of claim 5 further comprises receiving, by the vulnerability identifier, the vulnerability data; (See Vu, [0076-0078] ) receiving, by the vulnerability identifier, the library data; comparing, by the vulnerability identifier, the library data to the vulnerability data; (See Vu, [0037] ) and generating, by the vulnerability identifier, a vulnerability issue report when the given library identified by the library data matches a library identified in the vulnerability data, where the vulnerability issue report identifies the given library loaded into the monitored process. (See Vu, [0074] Sensors 310 can monitor network traffic between nodes, monitor processes executed on sensors 310, and send network traffic data and other data (e.g., host data, process data, user data, package data, vulnerability data, etc.) to the backend component 350. For example, sensors 310 can sniff packets being sent over its hosts' physical or virtual network interface card (NIC), or individual processes can be configured to report network traffic and corresponding data to sensors 310. Incorporating sensors 310 on multiple nodes and within multiple partitions of some nodes of the network can provide for robust capture of network traffic and corresponding data from each hop of data transmission. In some embodiments, each node of the network (e.g., VM, container, or other virtual partition, hypervisor, shared kernel, or physical server, ASIC, pcap, etc.) includes a respective sensor 310. However, it should be understood that various software and hardware configurations can be used to implement a network of sensors 310. It is further considered that as sensors 310 monitor data of processes running thereon, determine process information, extract package information associated with corresponding processes, generate logs or reports of usage on a respective node of the network, etc. Moreover, sensors 310 (and/or endpoints associated with sensors 310) are configured to extract process information from processes 320 running thereon, identify and locate packages 330, extract package information associated with packages 330, and report or provide the process information and package information to backend component 350 for analysis. Additionally, sensors 310 can create a running snapshot of processes executing thereon and send the snapshot to backend component 350. In some implementations, sensors 310 may also index and scan packages 330.)
Claims 7, 14 and 15-16 are rejected under 35 U.S.C 103 as being unpatentable over Vu, US 20220070197 A1 in view of Williams, US 20120222123 A1 in further view of Dalessio, US pat. No 10229251(IDS Submitted, 07/26/2024) in further view of Velur, US pat. No 20200242254 (IDS Submitted, 07/26/2024)
7. The combination of VU, Williams and Dalessio does not appear to explicitly disclose the method of claim 6 further comprises assigning, by a vulnerability priority processor, a vulnerability score to each vulnerability issue report, where the vulnerability score quantifies risk associated with the library identified in the vulnerability issue report; and presenting, by the vulnerability priority processor, one or more vulnerability issue reports on a display according to the vulnerability score associated with the vulnerability issue report. However, Velur discloses assigning, by a vulnerability priority processor, a vulnerability score to each vulnerability issue report, where the vulnerability score quantifies risk associated with the library identified in the vulnerability issue report; (See Velur, [0055]) and presenting, by the vulnerability priority processor, one or more vulnerability issue reports on a display according to the vulnerability score associated with the vulnerability issue report. (See Velur, [0092]) VU, Williams, Dalessio and Velur are analogous art because they are from the same field of endeavor which is monitoring system. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of VU, Williams and Dalessio with the teaching of Velur to include the report because it would have allowed to make available vulnerabilities data.
14. The combination of VU, Williams, Dalessio and Velur does not appear to explicitly disclose the method of claim 1 further comprises instrumenting application code with a transaction sensor, where the transaction sensor executes within the monitored process and is configured to monitor a performance metric associated with execution of the application code. However, Velur discloses instrumenting application code with a transaction sensor, where the transaction sensor executes within the monitored process and is configured to monitor a performance metric associated with execution of the application code. (See Velur, [0029]; An application can utilize one or more microservices to perform various functions. Microservices can perform various functions implementing one or more libraries. For example, an application 102 can use a microservice 104 to perform software related functions. The microservice 104 can call subroutines, data structures, procedures, scripts, or the like that are stored in a third-party library 106 to execute or aid in the execution of microservice functions.) VU, Williams, Dalessio and Velur are analogous art because they are from the same field of endeavor which is monitoring system. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of VU, Williams and Dalessio with the teaching of Velur to include the report because it would have allowed to make available vulnerabilities data.
15. The combination of VU, Williams, Dalessio and Velur discloses the method of claim 14 further comprises receiving, by an in-process agent, a listing of instrumentation instructions, where the in-process agent is injected into the monitored process; (See Velur, [0058], Code interceptors can be run along with a test suite. A name space can be created for each affected vulnerable library. An interceptor acting as a code hook can be implanted within the code of an affected library to cause any code that executes the name space to be logged. Code that is executed within a name space as identified and retrieved by an interceptor can be logged within a database. This can allow the number of code calls of that specific code within a namespace to be quantified. Quantifying the number of code calls during testing can determine which, if any, of the code corresponding to each name space creates a higher risk of vulnerability or exposure. For the following examples, assume test coverage is high (e.g., 90%). In one example, a code call with a CVE can be called a number of times, which can create a higher security risk compared to code with a CVE that is called only once during testing. See also [0065]; a vulnerable library list can be created using the dependencies mapped in lines 502 and 504 and the pseudo logic of FIG. 4. A for loop at line 508 can be executed to analyze each element (e.g., portion of code within a vulnerable dependency) in the vulnerable library list. Lines 510 and 512 can include processes described in block 316 of FIG. 3B for implementing code hooks within code of vulnerable libraries to determine the number of time a microservice calls a portion of code that is afflicted with a CVE.) instrumenting, by the in-process agent, the monitored process with the load sensor and the transaction sensor; (See Velur, [0058]) and instrumenting, by the in-process agent, the given API with the API sensor in accordance with a given instrumentation instruction from the listing of instrumentation instructions, (See Velur, [0058] and [0070-0071]) where instrumenting the given API with the API sensor includes detecting loading of code by the monitored process, comparing a signature of an API contained in the loaded code with at least one API signature pattern contained in the listing of instrumentation instructions, and instrumenting the API sensor in response to a match of the API signature with the at least one API signature pattern. (See Dalessio, Col 7, lines 31-50)
VU, Williams, Dalessio and Velur are analogous art because they are from the same field of endeavor which is monitoring system. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of VU, Williams and Dalessio with the teaching of Velur to include the report because it would have allowed to make available vulnerabilities data.
16.The combination of VU, Williams, Dalessio and Velur discloses the method of claim 15 further comprise analyzing, by the vulnerability identifier, the vulnerability data to create the listing of instrumentation instructions; (See Velur, [0058], Code interceptors can be run along with a test suite. A name space can be created for each affected vulnerable library. An interceptor acting as a code hook can be implanted within the code of an affected library to cause any code that executes the name space to be logged. Code that is executed within a name space as identified and retrieved by an interceptor can be logged within a database. This can allow the number of code calls of that specific code within a namespace to be quantified. Quantifying the number of code calls during testing can determine which, if any, of the code corresponding to each name space creates a higher risk of vulnerability or exposure. For the following examples, assume test coverage is high (e.g., 90%). In one example, a code call with a CVE can be called a number of times, which can create a higher security risk compared to code with a CVE that is called only once during testing. See also [0065]; a vulnerable library list can be created using the dependencies mapped in lines 502 and 504 and the pseudo logic of FIG. 4. A for loop at line 508 can be executed to analyze each element (e.g., portion of code within a vulnerable dependency) in the vulnerable library list. Lines 510 and 512 can include processes described in block 316 of FIG. 3B for implementing code hooks within code of vulnerable libraries to determine the number of time a microservice calls a portion of code that is afflicted with a CVE.) and sending, by the vulnerability identifier, the listing of instrumentation instructions to the in-process agent. (See Velur, [0058] and [0070-0071]) VU, Williams, Dalessio and Velur are analogous art because they are from the same field of endeavor which is monitoring system. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of VU, Williams and Dalessio with the teaching of Velur to include the report because it would have allowed to make available vulnerabilities data.
Claims 8- 13 are rejected under 35 U.S.C 103 as being unpatentable over Vu, US 20220070197 A1 in view of Williams, US 20120222123 A1 in further view of Dalessio, US pat. No 10229251 (IDS Submitted, 07/26/2024) in further view of Velur, US pat. No 20200242254 (IDS Submitted, 07/26/2024) in further view of Greifeneder, US pat. No 20160105350 (IDS Submitted, 07/26/2024).
8. The combination of VU, Williams, Dalessio and Velur does not appear to explicitly disclose the method of claim 7 further comprises retrieving, by a library data collector residing on the monitoring server, a record for a topology entity in a topology model, where the record represents the monitored process, and the topology model is defined as a graph with nodes representing entities in the distributed computing environment and edges representing communication between entities in the distributed computing environment; and updating, by the call data processor, the retrieved record with the library data. However, Greifeneder discloses retrieving, by a library data collector residing on the monitoring server, a record for a topology entity in a topology model, (See Greifeneder, fig 1; topology model See also [0073] and [0097; record process) where the record represents the monitored process, and the topology model is defined as a graph with nodes representing entities in the distributed computing environment and edges representing communication between entities in the distributed computing environment; (See Greifeneder, fig 1; topology model See also [0073] and [0097; record process and graph model of fig 1) and updating, by the call data processor, the retrieved record with the library data. (See Greifeneder, [ 0117]; update record)
VU, Williams, Dalessio, Velur and Greifeneder are analogous art because they are from the same field of endeavor which is monitoring system. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of VU, Williams and Dalessio and Velur with the teaching of Greifeneder to include the report because it would have allowed real-time discovery and monitoring of the topology of hardware and software components participating in the execution of software applications, including virtualization, process execution and transaction related aspects of the topology. (See Greifeneder, [0002])
9. The combination of VU, Williams, Dalessio, Velur and Greifeneder discloses the method of claim 8 further comprises receiving, by a call data processor residing on the monitoring server, call data for the given API executed by the monitored process, where the call data includes name of a method and name of a class; (See Greifeneder, [0081]; name of the main class) retrieving, by the call data processor, a record for a topology entity in a topology model, where the record represents the monitored process, and the topology model is defined as a graph with nodes representing entities in the distributed computing environment and edges representing communication between entities in the distributed computing environment; (See Greifeneder, fig 1; topology model See also [0073] and [0097; record process and graph model of fig 1) and updating, by the call data processor, the retrieved record with the call data. (See Greifeneder, [ 0117]; update record) VU, Williams, Dalessio, Velur and Greifeneder are analogous art because they are from the same field of endeavor which is monitoring system. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of VU, Williams and Dalessio and Velur with the teaching of Greifeneder to include the report because it would have allowed real-time discovery and monitoring of the topology of hardware and software components participating in the execution of software applications, including virtualization, process execution and transaction related aspects of the topology. (See Greifeneder, [0002])
10. The combination of VU, Williams, Dalessio, Velur and Greifeneder discloses the method of claim 9 further comprises retrieving, by the vulnerability processor, the record for the topology entity that represents the monitored process; (See Greifeneder, fig 1; topology model See also [0073] and [0097; record process) from the retrieved record, retrieving, by the vulnerability processor, call data for one or more APIs called by the monitored process; (See Greifeneder, [0016] The monitoring node may analyze data describing service calls being part of incoming transaction trace and monitoring data to identify services that are accessed from outside the data center.) for each of the one or more APIs, updating, by the vulnerability processor, the vulnerability issue report with the call data for the one or more retrieved APIs, where the library providing an API from the one or more retrieved APIs matches the library associated with the vulnerability report. (See Dalessio fig 3; data and report server exchange) VU, Williams, Dalessio, Velur and Greifeneder are analogous art because they are from the same field of endeavor which is monitoring system. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of VU, Williams and Dalessio and Velur with the teaching of Greifeneder to include the report because it would have allowed real-time discovery and monitoring of the topology of hardware and software components participating in the execution of software applications, including virtualization, process execution and transaction related aspects of the topology. (See Greifeneder, [0002])
11. The combination of VU, Williams, Dalessio, Velur and Greifeneder discloses the method of claim 10 wherein assigning a vulnerability score further comprises calculating a usage priority score for the monitored process based on frequency the one or more APIs are called by the monitored process, and updating the vulnerability issue report with the usage priority score. (See Greifeneder, [0096]; Reporting of OS topology data as described in FIG. 7a and reporting of communication topology data as described in FIG. 7b may either be performed synchronized, i.e. at the same point in time and with the same frequency, at the same frequency but at different points in time (i.e. phase-shifted) or with different frequencies.) VU, Williams, Dalessio, Velur and Greifeneder are analogous art because they are from the same field of endeavor which is monitoring system. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of VU, Williams and Dalessio and Velur with the teaching of Greifeneder to include the report because it would have allowed real-time discovery and monitoring of the topology of hardware and software components participating in the execution of software applications, including virtualization, process execution and transaction related aspects of the topology. (See Greifeneder, [0002])
12. The combination of VU, Williams, Dalessio, Velur and Greifeneder discloses the method of claim 11 wherein assigning a vulnerability score further comprises receiving, by the vulnerability priority processor, a given topology entity on which a vulnerability was observed; (See Velur, [0055]; a risk score can be assigned to each API affected by a CVE based on factors including the severity of the vulnerability, the number of code paths affected by the issue for each API, whether the affected dependency is a direct or transitive dependency, and the number of dependencies that have known CVEs affecting the API.) analyzing, by the vulnerability priority processor, connections between the given topology entity and other entities in the topology model, where the topology model identifies a subset of entities in the topology model that communicate with untrusted entities; (See Greifeneder, [0096]; Reporting of OS topology data as described in FIG. 7a and reporting of communication topology data as described in FIG. 7b may either be performed synchronized, i.e. at the same point in time and with the same frequency, at the same frequency but at different points in time (i.e. phase-shifted) or with different frequencies.) calculating, by the vulnerability priority processor, a reachability priority score for the monitored process based on connections between the given topology entity and one or more entities that communicate with untrusted entities, where calculating the reachability priority score includes determining whether the connections of the topology model indicate that the monitored process is reachable from at least one untrusted entity; in response that topology model connections indicate no reachability, setting a reachability priority score indicating that the monitored process is not reachable from an untrusted entity; (See Velur, [0055]; a risk score can be assigned to each API affected by a CVE based on factors including the severity of the vulnerability, the number of code paths affected by the issue for each API, whether the affected dependency is a direct or transitive dependency, and the number of dependencies that have known CVEs affecting the API.) otherwise, setting a reachability priority score depending on a topological distance between the monitored process and the at least one untrusted entity. (See Velur, [0055]; a risk score can be assigned to each API affected by a CVE based on factors including the severity of the vulnerability, the number of code paths affected by the issue for each API, whether the affected dependency is a direct or transitive dependency, and the number of dependencies that have known CVEs affecting the API.) VU, Williams, Dalessio, Velur and Greifeneder are analogous art because they are from the same field of endeavor which is monitoring system. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of VU, Williams and Dalessio and Velur with the teaching of Greifeneder to include the report because it would have allowed real-time discovery and monitoring of the topology of hardware and software components participating in the execution of software applications, including virtualization, process execution and transaction related aspects of the topology. (See Greifeneder, [0002])
13. The combination of VU, Williams, Dalessio, Velur and Greifeneder discloses the method of claim 12 wherein assigning a vulnerability score further comprises receiving, by the vulnerability priority processor, a given topology entity on which a vulnerability was observed; (See Velur, [0055]; a risk score can be assigned to each API affected by a CVE based on factors including the severity of the vulnerability, the number of code paths affected by the issue for each API, whether the affected dependency is a direct or transitive dependency, and the number of dependencies that have known CVEs affecting the API.) analyzing, by the vulnerability priority processor, connections between the given topology entity and other entities in the topology model, where the other entities store sensitive data; (See Greifeneder, fig 1; topology model and multiple connections) calculating, by the vulnerability priority processor, an access priority score for the monitored process based on connections between the given topology entity and the other entities in the topology model. (See Velur, [0055]; a risk score can be assigned to each API affected by a CVE based on factors including the severity of the vulnerability, the number of code paths affected by the issue for each API, whether the affected dependency is a direct or transitive dependency, and the number of dependencies that have known CVEs affecting the API.)
VU, Williams, Dalessio, Velur and Greifeneder are analogous art because they are from the same field of endeavor which is monitoring system. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of VU, Williams and Dalessio and Velur with the teaching of Greifeneder to include the report because it would have allowed real-time discovery and monitoring of the topology of hardware and software components participating in the execution of software applications, including virtualization, process execution and transaction related aspects of the topology. (See Greifeneder, [0002])
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Siman, Maty, US20220035928, Title “ Detecting exploitable paths in application software that uses third-party libraries.”
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOSNEL JEUDY whose telephone number is (571)270-7476. The examiner can normally be reached M-F 10:00-8:00.
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, Arani T Taghi can be reached at (571)272-3787. 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.
Date: 05/22/2026
/JOSNEL JEUDY/ Primary Examiner, Art Unit 2438
Prosecution Insights