Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
In the remarks filed on 12/05/2025. The applicant amended claims 1, 7, 10, 11, 17, and 19 are amended. No claims were added.
With respect to claim objections:
Applicant’ claim amendments and remarks filed on 12/05/2025 have been fully considered and overcame the claim objections as presented in the non-final office action filed 06/05/2025. Therefore, objections have been withdrawn.
With respect to 35 U.S.C. §101 rejections:
Applicant’ claim amendments and remarks filed on 12/05/2025 have been fully considered and does not overcame the claim objections as presented in the non-final office action filed 06/05/2025.
Applicant argus that the claims do not recite a judicial exception and even if they do, that claims integrate the exception into practical application because the amended claims improve computing infrastructure by identifying integration points, detecting vulnerabilities, and mitigating those vulnerabilities using an automated cybersecurity tool, see Remarks 9-11. Applicant’s arguments have been fully considered but are not persuasive. Amended claim 1 recites “performing reconnaissance with respect to a computing infrastructure”, “correlating the plurality of portions of the computing infrastructure with the plurality of components of the computing infrastructure”, “identifying an integration point base on the correlation”, “identifying a potential vulnerability associated with the identified integration point” and “performing at least one mitigation action”. These limitations describes acts of observing, analyzing, corelating information, evaluating conditions, and making determinations. Such acts stills falls within the category of mental processes and can be performed in human mind. Although the claim is directed to a “computing infrastructure” merely applying these analytical steps in a technological environment does not remove the claim from the abstract idea category. The focus of the claim remains on information gathering, analysis, identification of condition (i.e., a vulnerability) and deciding to take an action. Thus, the amended claim still recites a judicial exception under step 2A.
Furthermore, the claims do not recite any specific improvement to a computer functionality or to cybersecurity technology itself. The claims does not define a specific reconnaissance technique, a particular correlation algorithm, a defined vulnerability detection mechanism, a particular mitigation action, or a specialized configuration of a cybersecurity tool. Instead, the claims recite the desired results of identifying vulnerabilities and mitigating them using an automated cybersecurity tool without specifying how the tool operates in technologically unconventional manner. The recited “automated cybersecurity tool” is described at a high level of generality and invoked as mechanism to carry out the mitigation step. Thus, merely using generic tool to automate an abstract analytical process does not integrate the exception into a practical application.
Applicant argues that examiner has not established that the claimed combination of reconnaissance, correlation, identification, and mitigation is well understood, routine, and conventional. This argument is not persuasive. The additional elements beyond the abstract ideas consist of generic computer implementation including a “computing infrastructure” and “an automated cybersecurity tool”. The claim does not recite any specific technological configuration or unconventional mechanism for performing the recited functions. Automating such an abstract process using generic computer components performing their expected functions does not amount to significantly more than the abstract idea itself. Thus §101 is maintained.
With respect to 35 U.S.C. §102 and 103 rejections:
Applicant's arguments filed on 12/05/2025 have been received and entered.
Applicant's arguments with respect to the newly amended independent claims, see Applicant Arguments 11-13, with respect to the rejection (s) of independent claims 1,10 and 11 have been fully considered.
Applicant argues that Ossipov (US 20240214425 A1) only identifies enforcement points and maps policies to enforcement points now the amended claim requires “responsive to identifying the integration point, identifying a potential vulnerability associated with the identified integration point; and responsive to identifying the potential vulnerability associated with the identified integration point, securing the computing infrastructure by performing at least one mitigation action in the computing infrastructure using an automated cybersecurity tool” but are moot because the claim amendment introduces new claim limitations that have not previously been considered. Therefore, the new 103 ground of rejection relies on new references in combination as presented below.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-19 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
Independent claims 1, 10 and 11:
Step1:
Claims 1 is drawn to “a method”, claim 10 is drawn to “a non-transitory computer-readable storage media configured to store instructions to perform the method”, and claim 11 is drawn to “a system”, therefore each of these claim groups falls under one of four categories of statutory subject matter (process/method, machines/products/apparatus, manufactures, and compositions of matter).
Step 2A, Prong 1:
Claims 1, 10, and 11 are directed to a judicially recognized exception of an abstract idea without significantly more. Each of claims 1, 10, and 11 recites limitations “performing reconnaissance with respect to a computing infrastructure in order to identify a plurality of portions of the computing infrastructure and a plurality of components of the computing infrastructure”, “correlating the plurality of portions of the computing infrastructure with the plurality of components of the computing infrastructure”, “identifying an integration point among the computing infrastructure based on the correlation, wherein the integration point is one of the plurality of components of the computing infrastructure through which the computing infrastructure is integrable”, “responsive to identifying the integration point, identifying a potential vulnerability associated with the identified integration point”, and “responsive to identifying the potential vulnerability associated with the identified integration point, securing the computing infrastructure by performing at least one mitigation action in the computing infrastructure using an automated cybersecurity tool” that under its broadest reasonable interpretation, enumerates a mental evaluation and abstract ideas. Other than reciting a generic “a processing circuitry” (Claims 10 and 11), nothing in the claims preclude the steps from practically being performed in the human mind. For example, other than the “a processing circuitry” language, the claims encompass data gathering such as performing reconnaissance and a user visually and manually organize the gathered information (reconnaissance), analyzing information (i.e., correlation and rule comparison), evaluating conditions against predefined criteria (i.e., vulnerability rule) , and responding to the valuation result (mitigation) The mere nominal recitation of a generic computer component (computer processor or processing circuitry) to automate the mental and abstract concepts does not take the claim limitations out of the as such, the steps of performing abstract ideas such as observation, evaluation, judgement, and decision making and are nothing more than abstract mental and abstract ideas (See MPEP 2106.04(a)(2)(I)(III)).
Step 2A, Prong 2:
Claims 1, 10, and 11 recites additional element “automated cybersecurity tool”, “computing infrastructure”, “a non-transitory computer readable medium” to store computer program instructions and “a processing circuitry” to execute the computer program instructions. The automated cybersecurity tool, computer readable storage media and the computer processor are recited at a high level of generality (i.e., a generic tool to carry out the mitigation step, generic computer components performing generic computer functions to store and to process data respectively). These generic computer functions are no more than mere instructions to apply the exception using generic computer components. The claims do not recite a specific technological solution to technological problem. Instead, they implement a generalized workflow identify the structure, apply rule, detect mismatch, and mitigate .The combination of these additional elements does not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea (MPEP 2106.05(f)).
Step 2B:
The additional elements “automated cybersecurity tool”, “computing infrastructure”, “a non-transitory computer readable medium” to store computer program instructions and “a processing circuitry” to execute the computer program instructions are no more than generic, off-the-shelf computer components, and the Symantec, TLI, OIP Techs, and Versata court decisions cited in MPEP 2106.05(d)(II) indicate that mere collection/receipt of data over a network and/or storing and retrieving information in memory are well-understood, routine, and conventional functions when it is claimed in a merely generic manner (See MPEP 2106.05(d)(II)(IV)). As drafted, the claim-language terms “mitigation action” and “automated cybersecurity tool” are generic computer-implemented steps/tools and the claim itself and the specification does not recite specific, technical ways the actions are performed or the tool is constructed. As such, claims 1, 10, and 11 are not patent eligible.
Dependent claims 2-9, and 12-19:
Step 1:
Claims 2-9 are drawn to “a method” and 12-19 are drawn to “a system” therefore each of these claims falls under one of four categories of statutory subject matter (process/method, machines/products/apparatus, manufactures, and compositions of matter).
Steps 2A-2B:
Dependent claims 2-9 and 12-19 are also ineligible for the same reasons given with respect to claims 1 and 11. Claims 2-9 and 12-19 recite further abstract mathematical concept of matching certificate between first domain and second domain, identifying common domain data between two domains and using that to pick components, generating and comparing hashes to find matches, mapping identified components back to portion of the infrastructure, refining the integration point selection, monitoring network traffic based on earlier correlation and building connection between components, applying a vulnerability identification rule to the chosen integration point, deriving the type of each interface and tailoring which vulnerability rules to apply, and performing the reconnaissance based on a domain address of a system (MPEP 2106.04(a)(2)(I)). Claims 2-9 and 12-19 adds another layer of conventional data collection, correlation, matching or rule application and fail to recite any additional elements/steps that might integrates the abstract idea into a practical application. As such, claims 2-9 and 12-19 are not patent eligible.
Claim Rejections - 35 USC § 103
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.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1,3, 5-11, 13, and 15-19 are rejected under 35 U.S.C. 103 as being unpatentable over Ossipov (US 20240214425 A1) in view of McClure (US 20030195861 A1).
Regarding claim 1, Ossipov teaches a method for securing a computing infrastructure, comprising:
performing reconnaissance with respect to a computing infrastructure in order to identify a plurality of portions of the computing infrastructure and a plurality of components of the computing infrastructure (Ossipov, the network controller may generate the inventory of enforcement points using network data collected from network devices in a network. For example, the network controller may receive log data from the network devices. The log data collected by the network controller may indicate events (e.g., firewall events, intrusion prevention system (IPS) events, NetFlow events, and/or any kind of workload application-source telemetry) occurring with respect to network traffic at the network devices in the network. The log data may provide indications as to where enforcement points are provisioned with respect to network traffic being observed. For example, the network controller may utilize the log data to determine a plurality of data paths associated with the network devices in the network through which a plurality of source endpoints may communicate with a plurality of destination endpoints, [0019]) [Examiner interprets that network controller receiving log data from network devices and utilizing the log data to determine a plurality of data paths (i.e., a plurality of portions of the computing infrastructure) through which a plurality of source endpoints can communicate with a plurality of destination endpoints using various network devices and enforcement points with in the network (i.e., a plurality of components of the computing infrastructure) as performing reconnaissance with respect to a computing infrastructure in order to identify a plurality of portions of the computing infrastructure and a plurality of components of the computing infrastructure];
correlating the plurality of portions of the computing infrastructure with the plurality of components of the computing infrastructure (Ossipov, The network controller may generate the inventory of enforcement points based on the logical network relationships of the network devices and/or the log data and may map the roles associated with the network devices to the inventory of enforcement points. The network controller may further be configured to update, or otherwise generate a new inventory of enforcement points, in response to a network device coming online, a network device going offline, new log data (e.g., indicating poor performance, new capabilities, improper functioning of a network device, etc.), and/or user input (e.g., provisioning new devices, removing provisioned devices, reconfiguring network devices, etc.). Additionally, or alternatively, the network controller may generate a logical topology of the network indicating the data paths through which the plurality of source endpoints may communicate with the plurality of destination endpoints and the enforcement points associated with the data paths. This may be achieved by mapping the roles of the network devices to the inventory of enforcement devices, as described in more detail below. In some examples, the logical topology of the network may be displayed on a computing device, [0020]) [Examiner interprets that generate a logical topology of the network indicating the data paths through which the plurality of source endpoints and mapping roles of the network devices in the data paths (i.e. the plurality of portions of the computing infrastructure), to the inventory of enforcement devices (i.e., the plurality of components of the computing infrastructure) as correlating the plurality of portions of the computing infrastructure with the plurality of components of the computing infrastructure];
identifying an integration point among the computing infrastructure based on the correlation, wherein the integration point is one of the plurality of components of the computing infrastructure through which the computing infrastructure is integrable (Ossipov, the network controller may determine multiple paths of network traffic between the entity and the resource. The network controller may also identify one or more enforcement points associated with the path(s) of network traffic. For example, the network controller may utilize the inventory of enforcement points to identify enforcement points provisioned along the path(s) of network traffic, [0023] The network controller 104 may then generate the chain of enforcement points 300 including the first enforcement point 110(1) and the second enforcement point 110(2) and distribute respective portions (or operations) of the policy to the corresponding enforcement points 110 based on the chain of enforcement points 300. In this way, the first enforcement point 110(1) may perform the first operation of the policy on network traffic between the source endpoint 302 and the destination endpoint 304 and the second enforcement point 110(2) may perform the second operation of the policy on network traffic between the source endpoint 302 and the destination endpoint 304, [0049]) [Examiner interprets that controller identifying one or more enforcement points associated with the path of the network traffic and choosing particular enforcement points (e.g., a firewall, IPS device) as the chain to enforce policy as identifying an integration point among the computing infrastructure based on the correlation, wherein the integration point is one of the plurality of components of the computing infrastructure through which the computing infrastructure is integrable]; and
Ossipov does not appear to explicitly teach:
responsive to identifying the integration point, identifying a potential vulnerability associated with the identified integration point; and responsive to identifying the potential vulnerability associated with the identified integration point, securing the computing infrastructure by performing at least one mitigation action in the computing infrastructure using an automated cybersecurity tool.
However, McClure teaches:
responsive to identifying the integration point, identifying a potential vulnerability associated with the identified integration point (McClure, in the vulnerability assessment routine 364, the method executes vulnerability scripts that apply known vulnerabilities to open ports of the live target computers to determine whether the ports of the target computers exhibit the potential vulnerabilities. The method uses information stored in a known vulnerability database 366 to select the vulnerability scripts to executes for each active port. Information collected from vulnerable target computers is advantageously stored to the target computer database 344, [0071] For each known TCP port, UDP port, and operating system, the known vulnerabilities for that configuration are stored in a vulnerability database based on vulnerability identification codes… a methodology for testing the vulnerability can be written into an automatic script, which will assess the actual weakness of the target system to the suspected vulnerability…. The information collected by the FASL script from the target computer, and the success or failure of the attempt, are stored in a database related to the target computer for later reporting, for use in additional vulnerability testing, or for repeating additional testing, [0192]) [Examiner interprets that identifying exposed ports and routers as connection between system (i.e., integration point) and identifying vulnerabilities to those identified ports/services as limitation above]; and
responsive to identifying the potential vulnerability associated with the identified integration point, securing the computing infrastructure by performing at least one mitigation in the computing infrastructure using an automated cybersecurity tool (McClure, in the vulnerability assessment routine 364, the method executes vulnerability scripts that apply known vulnerabilities to open ports of the live target computers to determine whether the ports of the target computers exhibit the potential vulnerabilities. The method uses information stored in a known vulnerability database 366 to select the vulnerability scripts to executes for each active port. Information collected from vulnerable target computers is advantageously stored to the target computer database 344, [0071] a methodology for testing the vulnerability can be written into an automatic script, which will assess the actual weakness of the target system to the suspected vulnerability. In one embodiment, these scripts are prepared in an assessment security scripting language, and are preferably prepared in FASL. FASL is a scripting language based on C++ and Java implementation, in one embodiment. FASL provides an adjustable, automated language for security testing various vulnerabilities. Multiple FASL scripts advantageously may be run in parallel. For example, in one embodiment up to eight simultaneous scripts may be run. Each FASL script, for example, will respond with a success or failure result noting whether the target computer was vulnerable or not to the given vulnerability identification code. The information collected by the FASL script from the target computer, and the success or failure of the attempt, are stored in a database related to the target computer for later reporting, for use in additional vulnerability testing, or for repeating additional testing, [0192]) [Examiner interprets that system automatically executing scripts to test and act on vulnerabilities such as reporting, repeating additional vulnerability test etc., as limitation above];
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Ossipov to include a concept of responsive to identifying the integration point, identifying a potential vulnerability associated with the identified integration point; and responsive to identifying the potential vulnerability associated with the identified integration point, securing the computing infrastructure by performing at least one mitigation action in the computing infrastructure using an automated cybersecurity tool as taught by McClure for the purpose of determining whether the ports of the target computers exhibit the potential vulnerabilities [McClure :0071] for automatic detection, monitoring and reporting of network vulnerabilities [McClure :0002].
Regarding claim 3, Ossipov and McClure teach the method of claim 1, wherein performing the reconnaissance further comprises: identifying common domain data between resources of a first domain of the computing infrastructure and resources of at least one second domain, wherein the plurality of components is identified based on the identified common domain data (Ossipov, physical server(s) in the computing resource network 102 may host the various network components of the computing resource network 102, such as, for example, a first enforcement point 110(1) deployed at a campus domain 112, a second enforcement point 110(2) associated with a first cloud service 114(1), a third enforcement point 110(3) deployed at a datacenter 116, a fourth enforcement point 110(N) associated with a second cloud service 114(N), and/or any other network device, [0033] the network controller 104 may utilize the network data 204 to determine a plurality of data paths associated with the network devices 206 in the network through which a plurality of source endpoints may communicate with a plurality of destination endpoints. The network controller 104 may further receive network data 204 representing role tags indicative of roles associated with the network devices 206 in the network 102 and/or location tags indicative of logical network relationships of the network devices 206 in the network 102. …the role tags may indicate that a network device is configured as a campus edge firewall device, a virtual private network (VPN) termination device, a branch edge device, a data center edge device, a campus internal device, and/or the like…The location tags may indicate a physical location associated with a network device 206. ..may be hierarchical in that a first location indicated by a first location tag may represent a headquarters and a second location indicated by a second location tag may represent a building or a room within the headquarters, [0036] The network controller 104 may generate the inventory of enforcement points 202 based on the logical network relationships of the network devices 206 and/or the network data 204 and may map the roles associated with the network devices 206 to the inventory of enforcement points 202, [0037] the network controller 104 may infer that the main headquarters 210 encompasses the first datacenter 214(1) and the second datacenter 214(N), and as such, the second network device 206(7) and the third network device 206(11) are associated with the first network device 206(8),….[0038] In response to the input data, the network controller 104 may generate a new logical topology 208 of the network to reflect the connection between the first network device 206(8) and the fifth network device 206(4), [0039]) [Examiner interprets that the network controller collecting network data including roles and location tags (i.e., metadata) that indicates logical network relationship of network devices (i.e., linking devices in different or across domains such as campus network, data centers, remote branches etc., (i.e., the first domain and second domain), identifying resources in multiple domains based on the collected network data including roles and location tags (i.e., metadata) and generating an inventory of enforcement points network devices (i.e. a plurality of components) by correlating network data and logical network relationships as identifying common domain data between resources of a first domain of the computing infrastructure and resources of at least one second domain, wherein the plurality of components is identified based on the identified common domain data].
Regarding claim 5, Ossipov and McClure teach the method of claim 1, further comprising: mapping the plurality of components of the computing infrastructure to the plurality of portions of the computing infrastructure based on the correlation, wherein the integration point is identified based on the mapping (Ossipov, The network controller may generate the inventory of enforcement points based on the logical network relationships of the network devices and/or the log data and may map the roles associated with the network devices to the inventory of enforcement points. The network controller may further be configured to update, or otherwise generate a new inventory of enforcement points, in response to a network device coming online, a network device going offline, new log data (e.g., indicating poor performance, new capabilities, improper functioning of a network device, etc.), and/or user input (e.g., provisioning new devices, removing provisioned devices, reconfiguring network devices, etc.). Additionally, or alternatively, the network controller may generate a logical topology of the network indicating the data paths through which the plurality of source endpoints may communicate with the plurality of destination endpoints and the enforcement points associated with the data paths. This may be achieved by mapping the roles of the network devices to the inventory of enforcement devices, as described in more detail below. In some examples, the logical topology of the network may be displayed on a computing device, [0020]) [Examiner interprets that system mapping the roles associated with the network devices to inventory of enforcement points and generating a logical topology indicating the data paths and enforcement points associated with the data paths as claim above].
Regarding claim 6, Ossipov and McClure teach the method of claim 1, further comprising: monitoring traffic based on the correlation; and establishing connections between the plurality of components of the computing infrastructure based on the monitored traffic (Ossipov, The network controller may generate the inventory of enforcement points based on the logical network relationships of the network devices and/or the log data and may map the roles associated with the network devices to the inventory of enforcement points. The network controller may further be configured to update, or otherwise generate a new inventory of enforcement points, in response to a network device coming online, a network device going offline, new log data (e.g., indicating poor performance, new capabilities, improper functioning of a network device, etc.), and/or user input (e.g., provisioning new devices, removing provisioned devices, reconfiguring network devices, etc.). Additionally, or alternatively, the network controller may generate a logical topology of the network indicating the data paths through which the plurality of source endpoints may communicate with the plurality of destination endpoints and the enforcement points associated with the data paths. This may be achieved by mapping the roles of the network devices to the inventory of enforcement devices,…the logical topology of the network may be displayed on a computing device, [0020-0021]) [Examiner interprets that system collecting and analyzing log data indicating events with respect to the network traffic, utilizing the log data to determine a plurality of data paths and establishing connections between networking devices and enforcement points as monitoring traffic based on the correlation; and establishing connections between the plurality of components of the computing infrastructure based on the monitored traffic].
Regarding claim 7, Ossipov and McClure teach the method of claim 1, further comprising: applying at least one integration point vulnerability identification rule with respect to the identified integration point in order to identify a vulnerability with respect to the integration point, wherein each integration point identification vulnerability rule defines at least one circumstance with respect to a respective location in the computing infrastructure such that a vulnerability is detected for the integration point when circumstances of the integration point do not meet the at least one circumstances defined in the at least one integration point vulnerability identification rule (McClure, a methodology for testing the vulnerability can be written into an automatic script, which will assess the actual weakness of the target system to the suspected vulnerability. In one embodiment, these scripts are prepared in an assessment security scripting language, and are preferably prepared in FASL. FASL is a scripting language based on C++ and Java implementation, in one embodiment. FASL provides an adjustable, automated language for security testing various vulnerabilities. Multiple FASL scripts advantageously may be run in parallel. For example, in one embodiment up to eight simultaneous scripts may be run. Each FASL script, for example, will respond with a success or failure result noting whether the target computer was vulnerable or not to the given vulnerability identification code. The information collected by the FASL script from the target computer, and the success or failure of the attempt, are stored in a database related to the target computer for later reporting, for use in additional vulnerability testing, or for repeating additional testing, [0192] FASL includes member functions in structure objects, constructors and destructors in structure objects, inheritance….associated functions, string constants that support embedded hex codes including embedded zero bytes, RPCCheck( ) and SMBCheck( ) functions for RPC and Netbios checks, debugMessage( ) on all scalar types that produces hex output on binary type, recursion, function overloading, reference parameters, and support for Active-Assessment, [0194, 0202]) [Examiner interprets that system having vulnerability database rules tied to port and OS, FASL scripts defining conditions, each vulnerability scripts defining circumstances for detection, and rules defining if vulnerability exists as limitation above];
Regarding claim 8, Ossipov and McClure teach the method of claim 7, wherein the plurality of components of the computing infrastructure include at least one computing interface, further comprising: determining a type for each of the at least one computing interface, wherein the at least one integration point vulnerability identification rule is applied based on the determined type for each of the at least one computing interface (Ossipov , the intent-based security policy may be configured to implement various operations along path(s) of network traffic between source endpoints and destination endpoints, such as, for example, intrusion prevention system (IPS) operations, application security operations, web application firewall operations, denial of service attack prevention operations, uniform resource locator (URL) filtering and categorization operations, application programming interface (API) inspection operations, malware protection operations, firewall operations, (i.e., type for each of the at least one computing interface) [0023] the network control may be configured to apply virtual patching capabilities on a downstream enforcement point having IPS capabilities based on such application vulnerability information indicating that a workload component may not be able to prevent an attack…., [0026] the network controller 104 may generate the chain of enforcement points from among multiple candidate enforcement points 110. For example, an intent-based security policy 108 may require a first capability to perform a first operation associated with the policy 108, and a first enforcement point 110(1) and a second enforcement point 110(2) may both have the first capability and be provisioned along a path of network traffic between a destination endpoint and a source endpoint associated with the policy 108. In some examples, the network controller 104 may generate a chain of enforcement points including the first enforcement point 110(1) and not the second enforcement point 110(2) based on determining that the first enforcement point 110(1) has more favorable performance metrics (e.g., bandwidth, current usage, more robust capabilities for a portion of the policy, etc.) than the second enforcement point 110(2)… the network controller 104 may determine to utilize the first enforcement point 110(1) rather than the second enforcement point 110(2) based on a number of connections associated with the enforcement points 110, location of the enforcement points 110, software associated with the enforcement points 110, [0043]) [Examiner interprets that system determining that a first enforcement point has a first capability and second enforcement points has second capability for example intrusion prevention, fire wall, malware protection (i.e., the type of computing interfaces) and applying those capabilities based on vulnerability information by mapping operations of the intent based security policy to enforcement points having those capabilities to implement those operations as determining a type for each of the at least one computing interface, wherein the at least one integration point vulnerability identification rule is applied based on the determined type for each of the at least one computing interface].
Regarding claim 9, Ossipov and McClure teach the method of claim 1, wherein the reconnaissance is performed based on a domain address of a system within the computing infrastructure (Ossipov, the network controller 104 may receive an intent-based security policy 108 associated with a network 102. The intent-based security policy 108 may indicate an entity (e.g., the user 118 in the campus domain 112), a resource (e.g., the application backend 120(2) offered as a cloud service 114(N)), and/or an authorization associated with the entity 118 accessing the resource 120(2) (e.g., how this entity 118 is authorized to access the resource 120(2) across a given managed network). The network controller 104 may then determine a path of network traffic including one or more network devices 110 between the entity 118 and the resource 120(2) based on the authorization, [0040] the network controller 104 may determine multiple paths of network traffic between the entity 118 and the resource 120(2)…..the network controller 104 may utilize the inventory of enforcement points 202 including the policy mapping 106 to identify enforcement points 110 provisioned along the path(s) of network traffic. For example, the network controller 104 may identify a first enforcement point 110(1) associated with the campus domain 112, a second enforcement point 110(2) associated with the cloud service 114(1) providing the application front end 122, a third enforcement point 110(3) associated with the data center 116 storing data associated with the application back end 120(1), and/or a fourth enforcement point 110(N) associated with the cloud service 114(N) providing the application back end 120(2), [0041]) [Examiner interprets that system using intent based policy that includes entity’s campus domain and resources’ cloud domain determining multiple paths of network traffic between the entity and the resource and setting up different enforcement points for policy mapping, log collection based on their respective domain as the reconnaissance is performed based on a domain address of a system within the computing infrastructure].
Regarding claims 10 and 11, Claims 10 and 11 recite commensurate subject matter as claim 1. Therefore, they are rejected for the same reasons. Except the additional elements.
Ossipov further teaches:
A non-transitory computer readable medium having stored thereon instructions for causing a processing circuitry to execute a process, the process (Ossipov, the techniques described herein may be performed by a system and/or device having non-transitory computer-readable media storing computer-executable instructions that, when executed by one or more processors, performs the method, [0017]) comprising
A system for securing a computing infrastructure, comprising: a processing circuitry (Ossipov, one or more processors, [0059]) ; and a memory, the memory containing instructions that, when executed by the processing circuitry, configure the system, (Ossipov, memory, [0115, 0121]) to:
Regarding claims 13, and 15-19, Claims 3, and 5-9 recite commensurate subject matter as claim 3, and 5-9. Therefore, they are rejected for the same reasons.
Claims 2, 4, 12 and 14 are rejected under 35 U.S.C. 103 being unpatentable over Ossipov (US 20240214425 A1) in view of McClure (US 20030195861 A1) in further view of Gilbert (US 20200228432 A1).
Regarding claim 2, Ossipov and McClure teach the method of claim 1, wherein performing the reconnaissance further comprises:
Ossipov and McClure do not explicitly teach:
identifying at least one use of a matching certificate between resources of the computing infrastructure in a first domain and resources in a second domain, wherein the plurality of components is identified based on the identified at least one use of a matching certificate
However, Gilbert teaches:
identifying at least one use of a matching certificate between resources of the computing infrastructure in a first domain and resources in a second domain, wherein the plurality of components is identified based on the identified at least one use of a matching certificate (Gilbert, a network asset or attribute suggester determining network assets or attributes based on certificate information or cryptographic information finds certificates and other appropriate cryptographic information in known IP ranges; takes certificate or other appropriate cryptographic information fields (e.g., manually or automatically entered data into certificate fields) from known IP ranges; finds places where individual known certificates or other appropriate cryptographic information have been observed in global scan data; finds certificates or other appropriate cryptographic information from other fields (e.g., looks up certificates based on data entered in certificate fields); or determines network assets or attributes based on certificate information or other appropriate cryptographic information in any other appropriate way, [0028] network assets or attributes determined (e.g., by network asset or attribute evaluator 208) to be relevant to the network entity are stored in network asset or attribute storage 212. Network asset or attribute mapper 214 comprises a network asset or attribute mapper for creating a map of relevant network assets or attributes. Network asset or attribute map analyzer 216 comprises an analyzer for.., analyzing the map of relevant network assets or attributes comprises comparing the map of relevant network assets or attributes to a map of expected network assets or attributes, [0031]) [Examiner interprets that a network asset or attribute suggester determining network assets or attributes based on certificate information or cryptographic information (i.e., the certificates) from known IP ranges (i.e., the first domain) finding places where individual known certificates have been overserved in global scan data (i.e., the second domain) for detecting the same certificate appearing in two different network zones or domains and once any network asset or attributes are relevant (i.e., finding a matching certificate), the relevant network assets (i.e., the plurality of components) are mapped and stored for further iteration as performing the reconnaissance further comprises: identifying at least one use of a matching certificate between resources of the computing infrastructure in a first domain and resources in a second domain, wherein the plurality of components is identified based on the identified at least one use of a matching certificate].
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Ossipov and McClure to include a concept of identifying at least one use of a matching certificate between resources of the computing infrastructure in a first domain and resources in a second domain, wherein the plurality of components is identified based on the identified at least one use of a matching certificate as taught by Gilbert for the purpose of detecting network assets or attributes associated with the network entity [Gilbert:0023] by determining network assets or attributes based on certificate information or cryptographic information in known IP ranges and finding places where individual known certificates or other appropriate cryptographic information have been observed in global scan data [Gilbert:0028].
Regarding claim 4, Ossipov and McClure teach the method of claim 1, wherein performing the reconnaissance further comprises:
Ossipov and McClure do not explicitly teach:
generating at least one first hash for at least one resource of the computing infrastructure; and comparing the generated at least one first hash to a plurality of second hashes in order to identify at least one match between one of the at least one first hash and one of the plurality of second hashes, wherein the plurality of components is identified based on the identified at least one match
However, Gilbert teaches:
generating at least one first hash for at least one resource of the computing infrastructure; and comparing the generated at least one first hash to a plurality of second hashes in order to identify at least one match between one of the at least one first hash and one of the plurality of second hashes, wherein the plurality of components is identified based on the identified at least one match (Gilbert, a network asset or attribute suggester determining network assets or attributes (i.e., wherein the plurality of components) based on certificate information or cryptographic information finds certificates and other appropriate cryptographic information in known IP ranges; takes certificate or other appropriate cryptographic information fields (e.g., manually or automatically entered data into certificate fields) from known IP ranges; finds places where individual known certificates or other appropriate cryptographic information have been observed in global scan data; finds certificates or other appropriate cryptographic information from other fields (e.g., looks up certificates based on data entered in certificate fields); or determines network assets or attributes based on certificate information or other appropriate cryptographic information in any other appropriate way, [0028]) [Examiner interprets that a network asset or attribute suggester determining network assets or attributes belongs to network entity based on certificate information or cryptographic information (i.e., at least one first hash) by finding or matching certificates and other appropriate cryptographic information in known IP ranges in the global scan data (i.e., the a plurality of second hashes) as performing the reconnaissance further comprises generating at least one first hash for at least one resource of the computing infrastructure; and comparing the generated at least one first hash to a plurality of second hashes in order to identify at least one match between one of the at least one first hash and one of the plurality of second hashes, wherein the plurality of components is identified based on the identified at least one match].
The motivation for claim 4 is same rationale as claim 2.
Regarding claims 12 and 14, Claims 12 and 14 recite commensurate subject matter as claim 2 and 4. Therefore, they are rejected for the same reasons.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20210083953 A1: “relates to identifying, based on first domain name system (DNS) data, first border gateway protocol (BGP) data, first whois data, identifying, based on second DNS data, second BGP data, second whois data, or a combination thereof, a plurality of second internet-facing assets related to at least one of the first internet-facing assets”
US 20250030745 A1: “relates to the field of computer management, and more particularly to the field of cybersecurity and threat analytics”
US 20240291853 A1: “relates to threat mitigation systems and, more particularly, to threat mitigation systems that utilize a universal query language”
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 SAMIKSHYA POUDEL whose telephone number is (703)756-1540. The examiner can normally be reached 7:30 AM - 5PM Mon- Fri.
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, SHEWAYE GELAGAY can be reached at (571)272-4219. 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.
/S.N.P./ Examiner, Art Unit 2436
/SHEWAYE GELAGAY/ Supervisory Patent Examiner, Art Unit 2436