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 .
Claims 1-22 are pending for examination.
Claim Objections
Claims 2 and 14 are objected to because of the following informalities:
Claims 2 and 10 recite in line 2-3, “…a computing device or network scanning module adapted to configure a target computing device or network scan and convert said scan to machine readable form, …”, which is difficult to understand. It is suggested to amend the claim to recite, “…a scanning module adapted to configure scanning of a target computing device or network and convert said scanning data to machine readable form, …”
Appropriate correction is required.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “a scanning module”, “an ingest module”, “a command module”, “an attack module” and “a verifier module” in claims 2, 4-10 and 12-13.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
A review of the specification shows that the following appears to be the corresponding structure described in the specification for the 35 U.S.C. 112(f) or pre-AIA 35 USC. 112, sixth paragraph limitation: Fig. 9 illustrates those modules.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function, for example, …an instruction when executed by the processor, cause the processor to perform….); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 4-13 and 17 and 21-22 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 4 recites the limitation "the attack module", “the one of the one or more computing device or network vulnerabilities” and “the command module”. There are insufficient antecedent basis for these limitations in the claim.
Claim 5 recites the limitation "the verifier module", “the one of the one or more computing device or network vulnerabilities” and “the command module”. There are insufficient antecedent basis for these limitations in the claim.
Claim 6 recites the limitation "the attack module" and “the verifier module”. There are insufficient antecedent basis for these limitations in the claim.
Claim 7 recites the limitation “the ingest module”, “said nodes representative” and “the target computing device or network port”. There are insufficient antecedent basis for these limitations in the claim.
Claim 8 recites the limitation “the scanning module” and “the machine-readable form”. There are insufficient antecedent basis for these limitations in the claim.
Claim 8 also recites “NMap”. The meaning of “NMap” is unclear. This could be overcome by spelling-out the acronym the first time used in each (independent) claim.
Claim 9 recites the limitation "the attack module" and “the target computing device or network ”. There are insufficient antecedent basis for these limitations in the claim.
Claim 10 recites the limitation “the assigned attack”. There is insufficient antecedent basis for this limitation in the claim.
Claim 11 recites the limitation “the target computing device or network”. There is insufficient antecedent basis for this limitation in the claim.
Claim 12 recites the limitation “the group”. There is insufficient antecedent basis for this limitation in the claim.
Claim 13 recites the limitation “the group”. There is insufficient antecedent basis for this limitation in the claim.
Claim 17 recites “NMap”. The meaning of “NMap” is unclear. This could be overcome by spelling-out the acronym the first time used in each (independent) claim.
Claim 21 recites the limitation “the group”. There is insufficient antecedent basis for this limitation in the claim.
Claim 22 recites the limitation “the group”. There is insufficient antecedent basis for this limitation in the claim.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1, 3 and 4 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by US 2021/0029154 (Picard).
Regarding Claim 1, Picard teaches a system for autonomous cybersecurity probing of a computing device or network, comprising: processing circuitry; and one or more storage devices comprising instructions, which when executed by the processing circuitry configure the system to conduct autonomous cybersecurity probing of a computing device or network ([¶ 0006], Systems and methods for network security testing of target computer networks. [0033] The system is ideally tasked with automated security testing of a target system. To this end, based on the data stored on the data hive regarding the target system, the system generates, validates, and executes attacks, exploits, and penetration tests against the target system. Data generated during an attack or exploit is stored in the data hive. This data generated by tests, exploits, and attacks is then used to formulate, validate, and execute further actions aimed at determining any security vulnerabilities that the target system may have. [¶ 0073] The embodiments of the invention may be executed by a computer processor or similar device programmed in the manner of method steps, or may be executed by an electronic system which is provided with means for executing these steps. Similarly, an electronic memory means such as computer diskettes, CD-ROMs, Random Access Memory (RAM), Read Only Memory (ROM) or similar computer software storage media known in the art, may be programmed to execute such method steps).
Regarding Claim 3, Picard teaches the system of claim 1, wherein the cybersecurity probing of the computing device or network is a vulnerability probing selected from one or more of a vulnerability identification, a vulnerability exploitation, and a vulnerability assessment ([¶ 0029] each hemisphere group [i.e., a vulnerability probing] is dedicated to one type of attack or one type of network vulnerability that can be exploited. (hemisphere group activation may be based on what a client wants in terms of testing. Some clients may want all possible types of attacks to be tested while other clients may only want certain types of attacks to be tested). Each target system has an associated “hive state”, that represents the overall state of the system. Each hemisphere group has access to this hive state, and uses it to generate a predictive score related to the type of attack to which that hemisphere group is dedicated. Each predictive score indicates whether that type of attack is likely to be successful against the target system. [¶ 0033] based on the data stored on the data hive regarding the target system, the system generates, validates, and executes attacks, exploits, and penetration tests against the target system. Data generated by tests, exploits, and attacks is used to formulate, validate, and execute further actions aimed at determining any security vulnerabilities that the target system may have. …the one or more of the hemisphere groups may launch probes against the target system as an attack component to gather such data and/or seek data regarding the target system online. all or most aspects of the target system may be subject to the attacks and/or tests from the system, including any ports, services, and/or protocols that may be available or present in the target system).
Regarding Claim 4, Picard teaches the system of claim 1, wherein the attack module is provided the one of the one or more computing device or network vulnerabilities and a target IP address by the command module ([¶¶ 0036-0037] The system operates by first receiving data regarding the target system. This may come from a client wishing to have his or her corporate website/corporate network/IT assets tested for vulnerabilities. This data may be as simple as the corporate website address, the corporate IP address, and any other data which may be made available to the system. The data and known characteristics about the target system are then stored in the data hive. The system then generates a hive state based on the known data and characteristics of the target system. …each hive state can be seen as a composition of binary substrings, each binary substring corresponding to a specific attack and/or execution module. The hive state can also be seen as an indication of the state of the hive data for that particular target system indicating which features, data, and characteristics about the target system exist on the data hive. Once the initial hive state is calculated, this is made available to the various active hemispheres tasked with a specific project (e.g., the penetration testing of a specific target system using a specific type of attack or specific groups of attacks).
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 2, 13-15 and 22 are rejected under 35 U.S.C. 103 as being unpatentable over Picard in view of US 20030097557 (Tarquini et al.), and further in view of US 2005/0010571 (Solotorevsky et al.).
Regarding Claim 2, Picard teaches The system of claim 1, comprising: a computing device or network scanning module adapted to configure a target computing device or network scan ([¶¶ 0013-0014], …organizing computer resources for testing a security of a target network, the target network being a computer network, comprising: a) receiving data and characteristics for said target network and storing said data and characteristics in a central data storage data hive. [¶ 0036], first receiving data regarding the target system. This data may be as simple as the corporate website address, the corporate IP address, and any other data which may be made available to the system. The data are then stored in the data hive. The system then generates a hive state based on the known data and characteristics of the target system. [¶¶ 0058-0059] scanning methods involve scanning for open ports and attempting to grab version information related to the listening service. This version information is then cross-referenced with publicly disclosed vulnerabilities to determine the risk associated with the finding. [¶ 0060], the system may probe and scan the target system for what services and ports may be open and vulnerable. As noted above, the result of such probes provides data for later possible attacks and exploits); a command module comprising a plurality of nodes representing facts, rules, actions, and verifiers associated with one or more computing device or network vulnerabilities identified by the scanning module, said command module being configured to determine whether to launch an attack ([¶¶ 0015-0016], determining a state of said target network based on data and characteristics stored [i.e., identified by the scanning module] in data hive; c) formulating a plurality of potential attacks [i.e., a plurality of nodes], said potential attacks being against said target network based on said state. [¶ 0029], Each target system has an associated “hive state”, a binary string based on the data in the hive storage that represents the overall state of the system. Each hemisphere group has access to this hive state, and uses it to generate a predictive score related to the type of attack to which that hemisphere group is dedicated. Each predictive score indicates whether that type of attack is likely to be successful against the target system. These predictive scores undergo a validation process. Attacks corresponding to any valid predictive scores are passed to an execution unit for execution. (If no predictive scores are valid, a probability function is used to determine whether a random attack should be selected for execution). The execution unit tasked with a specific attack can then execute the attack or component by calling on other available resources. [¶ 0037], Once the initial hive state is calculated, this is made available to the various active hemispheres tasked with a specific project (e.g., the penetration testing of a specific target system using a specific type of attack or specific groups of attacks). …produce predictive scores representing potential attacks and/or exploits for the system to try on the target system. This prediction step predicts which attacks and/or exploits may succeed against the target system. The prediction step essentially determine which attacks/exploits may work on the target system. The prediction step also determines which attacks/exploits may be launched based on the available data. The neural networks determine which combinations of available assets (e.g., ports, services, protocols, data, emails, etc.) are suitable for a specific attack or exploit. complex combinations and sub-combinations of attacks and/or exploits, and even what-if scenarios, can be determined to be possible against a specific target system. [0061], Once services have been identified and version information is known, the system can then attempt to predict which modules can be executed to trigger vulnerabilities. Each module is a standalone attack which can be executed in an attack chain within any order. The module(s) executed depends on the predictions produced by the classifier); an attack module configured to, on receipt of instructions from the command module, assign an attack based on a one of the one or more computing device or network vulnerabilities ([¶¶ 0017-0021] d) for each one of said plurality of potential attacks, determining if a module exists for said one of said plurality of potential attacks based on said state, said one of said plurality of potential attacks being a module-validated potential attack if said module exists for said one of said plurality of potential attacks; e) when at least one of said plurality of potential attacks is a module-validated potential attack, determining if conditions for said module-validated potential attack are present based on said data and characteristics in said data hive, said module-validated potential attack being an executable attack if said conditions are present; f) when each of said plurality of potential attacks is invalid, executing a probability function that determines if a random module is selected for use in executing a random attack against said target computer system; g) provisioning resources for each executable attack determined in step e) and for each random attack selected in step f); and h) executing said each executable attack and each said random attack, data being generated by each said executable attack and each said random attack being saved in said data hive. [¶ 0033], the system is ideally tasked with automated security testing of a target system. the system generates, validates, and executes attacks, exploits, and penetration tests against the target system. …data generated by tests, exploits, and attacks is then used to formulate, validate, and execute further actions aimed at determining any security vulnerabilities that the target system may have); and a verifier module configured to determine success or failure of the assigned attack and to return an indicator of the determined success or failure to the command module ([¶ 0033] the system is ideally tasked with automated security testing of a target system. Data generated by tests, exploits, and attacks is used to formulate, validate, and execute further actions aimed at determining any security vulnerabilities that the target system may have. [¶ 0040], as information about successful attacks is stored in the hive storage, if a randomly selected attack module is successful against the target system, information about that successful randomly selected attack will be preserved. [¶ 0041], any successful penetrations of the target system can be included in a suitable report to the client. …such a report would include the vulnerabilities, the methods used to gain access to those vulnerabilities, and an indication as to how such vulnerabilities can be exploited to gain further unauthorized access to the target system. Depending on the tests executed as well as the configuration of the system, the report may include a vulnerability analysis report, a remediation plan based on vulnerabilities detected in the target system, a penetration test report, an application test report, and a social engineering test report (i.e., whether and how spoofing/phishing attacks were successful/unsuccessful), as well as remediation plans based on any of the above tests. [¶ 0071], If an attack or exploit is successful, the initial hive state and data from the relevant attack or exploit module are stored in the hive storage and provide a basis for future predictions).
Picard does not explicitly teach, however, Tarquini teaches convert said scan to machine readable form ([¶ 0039] input one or more text-files. Each text-file may define a network-based exploit and comprise a logical description of an attack signature as well as network intrusion prevention system (IPS) directives to execute upon an IPS evaluation of an intrusion-related event associated with the described attack signature. Each text file may be stored in a database and compiled by a compiler into a respective machine-readable signature file. Each of the machine-readable signature files comprises binary logic representative of the attack signature as described in the respectively associated text-file).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Tarquini's teachings of converting text file to a machine-readable format to the teachings of Picard because such incorporation would have enabled automated processing and analysis of the data, thereby reducing manual intervention and improving system efficiency. Machine-readable format allow to automatically parse, interpret, and act upon the data, which is a common and well-recognized design objective in a computer-implemented system.
Picard in view of Tarquini do not teach, however, Solotorevsky teaches the scanning module further comprising an ingest module configured to process said scan to create nodes representative of the target computing device or network ports, port status, and vulnerabilities ([¶¶ 0056-0057] a description of the network is translated into a symbolic network representation where network elements and their connections and ports may be represented by nodes. Fig. 4, there is shown an example of a symbolic network representation which is a representation of the network of Fig. 3. A pair of nodes represents bi-directional connections or ports connected to bi-directional connections. Each node that represents a port is connected by a directed edge to the node that represents the connection Each network elements is represented by a node, which are linked by edges to all the nodes that represent that network elements ports. All the relevant attributes of network elements, ports, and connections are associated with the correspondent nodes).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Solotorevsky's teachings of translate a description of a network into a symbolic network representation where network elements and their connections and ports may be represented by nodes to the combined teachings of Picard and Tarquini because such incorporation would have enabled automated network analysis. Symbolic representations allow security tools to systematically evaluate relationship between devices, services, and ports.
Regarding Claim 13, Picard teaches the system of claim 2, wherein the command module comprising: facts which are values defining target computing device or network information selected from the group consisting of host information, port information, computing device or network vulnerability information, an identification field, and a description field ([¶ 0036-0037] first receiving data regarding the target system. This data may be as simple as the corporate website address, the corporate IP address, and any other data which may be made available to the system. The data and known characteristics about the target system are then stored in the data hive. The system then generates a hive state based on the known data and characteristics of the target system. Once the initial hive state is calculated, this is made available to the various active hemispheres tasked with a specific project (e.g., the penetration testing of a specific target system using a specific type of attack or specific groups of attacks). the hive state produce predictive scores representing potential attacks and/or exploits for the system to try on the target system. predicts which attacks and/or exploits may succeed against the target system. The prediction step also determines which attacks/exploits may be launched based on the available data. The neural networks determine which combinations of available assets (e.g., ports, services, protocols, data, emails, etc.) are suitable for a specific attack or exploit. complex combinations and sub-combinations of attacks and/or exploits, and even what-if scenarios, can be determined to be possible against a specific target system); rules which are triggered when all facts identified as necessary pre-conditions to an action are determined to be true; actions which are triggered by rules to perform a task ([¶ 0037], Complex combinations and sub-combinations of attacks and/or exploits, and even what-if scenarios, can be determined to be possible against a specific target system. …multiple predictions as to which attacks, exploits, and tests may work may result from the output of a single neural network. As a simplified example, may determine that, since ports A, B, and C are known to be open on the target system and since services X, Y, and Z are known to be available on the same target system, then attacks D, E, and F and exploits G, H, and I are all possible against that target system); and verifiers which verify whether an action was successful ([¶ 0040], information about successful attacks is stored in the hive storage, if a randomly selected attack module is successful against the target system, information about that successful randomly selected attack will be preserved).
Picard does not explicitly teach, however, Solotorevsky teaches using a Blackboard Architecture [¶ 0076], The optimization may be performed or attempted by using various algorithms that run simultaneously and use a Blackboard-based Architecture to cooperate and compete).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Solotorevsky's Blackboard Architecture to the network vulnerability test of Picard because such incorporation would have coordinated multiple modules to provide a shared knowledge space that allows these modules to exchange results indirectly and operate in a coordinate manner.
Regarding Claim 14, the claim limitations are identical and/or equivalent in scope to claims 1 and 2, therefore, Claim 14 is rejected under the same rationale as claims 1and 2.
Claims 15 and 22 are identical and/or equivalent in scope to claims 3 and 13, respectfully. Therefore, Claims 15 and 22 are rejected under the same rationale as claims 3 and 13.
Claims 5 and 9-12 are rejected under 35 U.S.C. 103 as being unpatentable over Picard in view of US 8365289 (Russ et al.).
Regarding Claim 5, Picard does not explicitly teach, however, Russ teaches the system of claim 1, wherein the verifier module is provided the one of the one or more computing device or network vulnerabilities and a target IP address by the command module ([C.12:L.66 – C.13:L.22], the network vulnerability scanner validator module 600 takes as input a report produced by a vulnerability scanner. This report will contain a list of IP addresses and vulnerabilities. When started, the network vulnerability scanner validator module might execute the network information gathering module to confirm some of the information provided in the report. …for each pair of IP address and vulnerability, the network vulnerability scanner validator module runs the exploit underlying this vulnerability against the pairing IP in order to confirm that the vulnerability is present. All tested vulnerabilities and the results are annotated for constructing a report).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Russ's validation for each IP address and vulnerability to the network vulnerability test of Picard because such incorporation would have improved accuracy and correctness of penetration testing result.
Regarding Claim 9, Picard teaches the system of claim 5, wherein the attack module is configured to: assign an attack according to the one of the one or more computing device or network vulnerabilities ([¶ 0029] In operation, each hemisphere group is dedicated to one type of attack or one type of network vulnerability that can be exploited. (hemisphere group activation may be based on what a client wants in terms of testing. Some clients may want all possible types of attacks to be tested while other clients may only want certain types of attacks to be tested. [¶¶ 0036-0037], each hive state can be seen as a composition of binary substrings, each binary substring corresponding to a specific attack and/or execution module. The hive state can also be seen as an indication of the state of the hive data for that particular target system indicating which features, data, and characteristics about the target system exist on the data hive. Once the initial hive state is calculated, this is made available to the various active hemispheres tasked with a specific project (e.g., the penetration testing of a specific target system using a specific type of attack or specific groups of attacks)); assign an attack script to implement against the target computing device or network, the attack script defining a corresponding attack; and execute the assigned attack using the assigned attack script ([¶ 0029], The execution unit tasked with a specific attack (or tasked with a component of such an attack) can then execute the attack or component by calling on other available resources. A module score is generated by the execution of the attack component [i.e., attack script] or the attack itself, and any data generated is then passed on to the data hive. [¶ 0033], the system is ideally tasked with automated security testing of a target system. To this end, based on the data stored on the data hive regarding the target system, the system generates, validates, and executes attacks, exploits, and penetration tests against the target system.)
Regarding Claim 10, although, Picard teaches validating the penetration testing, however, Picard does not explicitly teach, however, Russ teaches the system of claim 5, wherein the verifier module is configured to: select a verification method according to the provided one of the one or more computing device or network vulnerabilities and the target IP address; verify a success of the assigned attack ([C.12:L.66 – C.13:L.22], the network vulnerability scanner validator module takes as input a report produced by a vulnerability scanner. This report will contain a list of IP addresses and vulnerabilities. When started, the network vulnerability scanner validator module might execute the network information gathering module to confirm some of the information provided in the report. …for each pair of IP address and vulnerability, the network vulnerability scanner validator module runs the exploit underlying this vulnerability against the pairing IP in order to confirm that the vulnerability is present. All tested vulnerabilities and the results are annotated for constructing a report).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Russ's validation for each IP address and vulnerability to the network vulnerability test of Picard because such incorporation would have improved accuracy and correctness of penetration testing result.
Regarding Claim 11, Picard teaches the system of claim 10, wherein the verification method is one of determining whether an expected change has been made to the target computing device or network or determining whether the target computing device or network is operational ([¶ 0040], information about successful attacks is stored in the hive storage, if a randomly selected attack module is successful against the target system (i.e., the module score differs from the corresponding section of the hive state). …any successful penetrations of the target system can be included in a suitable report to the client. Preferably, such a report would include the vulnerabilities, the methods used to gain access to those vulnerabilities, and an indication as to how such vulnerabilities can be exploited to gain further unauthorized access to the target system. Depending on the tests executed as well as the configuration of the system, the report may include a vulnerability analysis report, a remediation plan based on vulnerabilities detected in the target system, a penetration test report, an application test report, and a social engineering test report (i.e., whether and how spoofing/phishing attacks were successful/unsuccessful), as well as remediation plans based on any of the above tests).
Regarding Claim 12, Picard teaches the system of claim 10, wherein the verifier module is selected from one or more of the group consisting of: a triggered verifier, a specific date/time verifier, a time in the future verifier, and a data expiration verifier ([¶¶ 0035-0037], an exploit is a specific type of attack, one which takes advantage of a particular vulnerability of the target system. …first receiving data regarding the target system. The data and known characteristics about the target system are then stored in the data hive. The system then generates a hive state based on the known data and characteristics of the target system. …each hive state can be seen as a composition of binary substrings, each binary substring corresponding to a specific attack and/or execution module. The hive state can also be seen as an indication of the state of the hive data for that particular target system indicating which features, data, and characteristics about the target system exist on the data hive. Once the initial hive state is calculated, this is made available to the various active hemispheres tasked with a specific project (e.g., the penetration testing of a specific target system using a specific type of attack or specific groups of attacks. …then take the hive state and, based on the bit values, combinations of bit values, and perhaps the overall hive state, produce predictive scores representing potential attacks and/or exploits for the system to try on the target system. …determine which attacks/exploits may work on the target system. The prediction step also determines which attacks/exploits may be launched based on the available data. [¶ 0041], any successful penetrations of the target system can be included in a suitable report to the client. Preferably, such a report would include the vulnerabilities, the methods used to gain access to those vulnerabilities, and an indication as to how such vulnerabilities can be exploited to gain further unauthorized access to the target system. Since Picard teaches that the system determined, based on the hive state, which potential exploits should be attempted against the target system to verify attack success, Picard thus discloses a verification process that is triggered in response to the hive state).
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Picard in view of US 2021/0357507 (Sulatycki et al.).
Regarding Claim 6, Sulatycki teaches the system of claim 1, wherein the attack module and the verifier module are not configured to communicate one with the other ([Fig. 3, ¶ 0025] The penetration manager 102 provides services for penetration testing of any computer device. The penetration manager 102 is implemented in a distributed fashion to be able to scale and perform multiple tests in parallel. The penetration testing includes reconnaissance, vulnerability identification, exploitation, and reporting. …the results are also asynchronously managed and delivered, either via call back APIs, or via the standard API for reporting download. [¶ 0041] The penetration manager 102 infrastructure is distributed and scalable. The penetration manager 102 allows asynchronous calling of processes or systems and is able to return information on currently running attacks or scans. Further, the penetration manager 102 is API-driven for ease of use and integration into systems. The reporting module 308 provides reports that include the results of the penetration attacks. Since Sulatycki teaches attack coordinator, attacker and reporting module are decoupled and access via APIs, therefore it would be realized that the attack execution does not directly communicate with the verification/reporting module).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Sulatycki's asynchronously managed process in a security-testing infrastructure to the teachings of Picard because such incorporation would have improved scalability and efficiency of penetration testing operation.
Claims 7 are rejected under 35 U.S.C. 103 as being unpatentable over Picard in view of Solotorevsky.
Regarding Claim 7, Picard does not explicitly teach, however, Solotorevsky teaches the system of claim 1, wherein the ingest module creates said nodes representative of the target computing device or network ports, port status, and vulnerabilities within a Blackboard Architecture network ([¶¶ 0056-0057] a description of the network is translated into a symbolic network representation where network elements and their connections and ports may be represented by nodes. Fig. 4, there is shown an example of a symbolic network representation which is a representation of the network of Fig. 3. A pair of nodes represents bi-directional connections or ports connected to bi-directional connections. Each node that represents a port is connected by a directed edge to the node that represents the connection Each network elements is represented by a node, which are linked by edges to all the nodes that represent that network elements ports. All the relevant attributes of network elements, ports, and connections are associated with the correspondent nodes. [¶ 0076], The optimization may be performed or attempted by using various algorithms that run simultaneously and use a Blackboard-based Architecture to cooperate and compete).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Solotorevsky's teachings of translate a description of a network into a symbolic network representation where network elements and their connections and ports may be represented by nodes to the teachings of Picard because such incorporation would have enabled automated network analysis. Symbolic representations allow security tools to systematically evaluate relationship between devices, services, and ports.
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Picard in view of Tarquini.
Regarding Claim 8, Picard does not explicitly teach, however, Tarquini teaches the system of claim 1, wherein the scanning module is configured to convert an NMap computing device or network scan output to the machine-readable form ([¶ 0039] input one or more text-files. Each text-file may define a network-based exploit and comprise a logical description of an attack signature as well as network intrusion prevention system (IPS) directives to execute upon an IPS evaluation of an intrusion-related event associated with the described attack signature. Each text file may be stored in a database and compiled by a compiler into a respective machine-readable signature file. Each of the machine-readable signature files comprises binary logic representative of the attack signature as described in the respectively associated text-file. [¶ 0047], The signature description describes an exploit referred to as an Internet control message protocol (ICMP) scan. An ICMP scan is a network mapping that uses ICMP and is commonly utilized by well-known utilities such as traceroute, ping, fping, gping or Nmap).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Tarquini's teachings of converting text file generated scan of network using NMap, to a machine-readable format to the teachings of Picard because such incorporation would have enabled automated processing and analysis of the data, thereby reducing manual intervention and improving system efficiency. Machine-readable format allow to automatically parse, interpret, and act upon the data, which is a common and well-recognized design objective in a computer-implemented system.
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over the combined teachings of Picard-Tarquini-Solotorevsky, and further in view of Sulatycki.
Regarding Claim 16, the claim limitations are identical and/or equivalent in scope to claim 6, therefore, Claim 16 is rejected under the same rationale as claim 6.
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over the combined teachings of Picard-Tarquini-Solotorevsky.
Regarding Claim 17, the claim limitations are identical and/or equivalent in scope to claim 8, therefore, Claim 17 is rejected under the same rationale as claim 8.
Claims 18-21 are rejected under 35 U.S.C. 103 as being unpatentable over the combined teachings of Picard-Tarquini-Solotorevsky, and further in view of Russ.
Regarding Claims 18-21, the claim limitations are identical and/or equivalent in scope to claims 9-12, therefore, Claims 18-21 are rejected under the same rationale as claims 9-12.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MOHAMMAD YOUSUF A MIAN whose telephone number is (571)272-9206. The examiner can normally be reached Monday-Friday 9am-5:30pm.
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, ARIO ETIENNE can be reached at 571-272-4001. 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.
/MOHAMMAD YOUSUF A. MIAN/Examiner, Art Unit 2457
/MOUSTAFA M MEKY/Primary Examiner, Art Unit 2457