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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on April 20, 2026 has been entered.
Status of Claims
The following is a Non-Final Office Action in response to applicant’s filing on April 20, 2026. claims 1, 6, 7, 12, 13, and 18 are currently amended. As a result, claims 1-24 are pending, of which claims 1, 7, and 13 are in independent form.
Response to Amendment
Applicant’s amendment regarding claims 6, 12, and 18 obviates the claim rejection, therefore, the claim rejection under 35 USC § 112(a), is withdrawn.
However, the newly amended claims 1, 7, and 13 are rejected under 35 U.S.C.112(a) and 35 U.S.C.112(b) for being indefinite and failing to comply with the written description and enablement requirements regarding the limitation “wherein an agent is not …used to obtain the at least one result and the obtained at least one result comprises identifiable information for the detected host device;”.
Response to Arguments
Applicant’s arguments with respect to claim(s) are rejected, under 35 USC 103(a), have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter.
Rejection under 35 U.S.C. § 112(a)
On Page 9 of remarks, Applicant states that the limitation " encapsulating one or more address resolution protocol (ARP) packets comprising an Internet Protocol address for the detected host device " has been canceled from dependent claims 6, 12, and 18. In view of the amendments and remarks, the examiner withdraws the previous rejection under 35 U.S.C.112(a).
However, the newly amended claims 1, 7, and 13 are rejected under 35 U.S.C.112(a) and 35 U.S.C.112(b) for being indefinite and failing to comply with the written description and enablement requirements regarding the limitation “wherein an agent is not deployed on the detected host device or used to obtain the at least one result and the obtained at least one result comprises identifiable information for the detected host device;”.
Rejection under 35 U.S.C. § 103
On Pages 10-13 of remarks, Applicant argues that Kelekar, Dang, Aziz, Takahashi, and Vincent, alone or in combination, also do not disclose or suggest the limitations “wherein an agent is not deployed on the detected host device or used to obtain the at least one result and the obtained at least one result comprises identifiable information for the detected host device;… when the identifiable information uniquely identifies the detected host device based on whether the classification value exceeds a classification threshold” in amended claims 1, 7, and 13.
In regard to the limitation “wherein an agent is not deployed on the detected host device or used to obtain the at least one result and the obtained at least one result comprises identifiable information for the detected host device” as amended in claim 1, If the claim does not require to apply an agent, then how the plurality of tests are applied as claimed. The claim scope, while it states “is not deployed on the detected host device…”, can be interpreted that at the time of the agent it is not deployed, as the reference states “…an agent application which runs on the host/device. both the agent and server can run on the same host/device, see paragraph [0154].
Therefore, there is no deployment and it is unclear how the applicant achieves this limitation without having a ‘software component” on the host device that communicates with the “scanning device”.
Further, in regards to the limitations “generating, by the network scanning device, a classification value for the detected host device based on the identifiable information, wherein the classification value represents a likelihood that the identifiable information is capable of uniquely identifying the detected host device; determining, by the network scanning device and before vulnerability scanning of the detected host device is conducted, when the identifiable information uniquely identifies the detected host device based on whether the classification value exceeds a classification threshold”. Applicant’s arguments, have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Oberheide et al. (US 2018/0173881A1).
As to the dependent claims 2-6, 8-12 and 14-24, these claims remain rejected by virtue of dependency to their independent claims.
Accordingly, the rejection under 35 USC § 103 of claims 1-24 are maintained.
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-AlA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection |, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AlA 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-AlA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AlA35 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-AlA 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-AlA 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-AlA 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-AlA 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: “wherein an agent is not deployed on the detected host device or used to obtain the at least one result and the obtained at least one result comprises identifiable information for the detected host device; generating, by the network scanning device, a classification value for the detected host device based on the identifiable information” in claim 1.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AlA 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. In claim 1, network scanning device, device uses as part of the nonce word device “network scanning” these pertain to the function it performs device [for” network scanning”], that performs the functions of “identify, apply, generate, etc. Upon reading the specification, it refers to 12 in Fig. 1, which according to the specification, generally simply states in paragraphs [0020]-[0022]”, the application(s) can be implemented as modules or components of other applications. Further, the application(s) can be implemented as operating system extensions, modules, plugins, or the like. However, there is not sufficient algorithm for “network scanning”.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AlA 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-AlA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); 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 the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL. — The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1, 7, and 13 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claim 1 recites “wherein an agent is not deployed … used to obtain the at least one result and the obtained at least one result comprises identifiable information for the detected host device;".
Given that the limitation of claim 1, for the “wherein an agent is not deployed on the detected host device or used to obtain the at least one result and the obtained at least one result comprises identifiable information for the detected host device;", (i.e., this technology advantageously is able to inventory host devices across network segments to further facilitate vulnerability scanning and without requiring agents deployed on the segments or the particular host devices, see paragraph [0058]). The disclosure does not provide any teaching, or steps as to how an agent is not used to obtain the at least one result and the obtained at least one result comprises identifiable information for the detected host device. Applicant’s spec states, which is part of the argument, [0039], Examples of this technology are advantageously able to implement and provide network inventorying and security across network segments and through the network scanning device 12 while avoiding the need to load any type of agent on any of the systems, devices, or hosts (e.g., host devices 20(1)-20(n))” However, there is no distinction of what the applicant considers to be an agent, versus “The application(s) can be implemented as modules or components of other applications. Further, the application(s) can be implemented as operating system extensions, modules, plugins, or the like. To claim negative limitation, there must be exclusionary proviso must have basis in the original disclosure. If no agent is deployed, then it is unclear as to how is it possible to apply a test to the host device.
MPEP 2173.05(i), In describing alternative features, the applicant need not articulate advantages or disadvantages of each feature in order to later exclude the alternative features. See Inphi Corporation v. Netlist, Inc., 805 F.3d 1350, 1356-57, 116 USPQ2d 2006, 2010-11 (Fed. Cir. 2015). Therefore, while the applicant may have states that “avoids” agents, there is no differentiation of how it is different from such extensions, modules, plugins, to have exclusionary provisions sufficient in the specification, in accordance to the MPEP.
Independent claims 7 and 13 are similarly rejected. As to the dependent claims 2-6, 8-12 and 14-24, these claims remain rejected by virtue of dependency to their independent claims.
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 1-24 are 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 1 recites the limitation “wherein an agent is not deployed … used to obtain the at least one result and the obtained at least one result comprises identifiable information for the detected host device;", which is a negative limitation that does not find proviso basis in the original disclosure to the open-ended scope. The negative limitation renders the claim indefinite because it is an attempt to claim the invention by excluding what the inventors did not invent rather than distinctly and particularly pointing out what they did invent.
Independent claims 7 and 13 are similarly rejected. As to the dependent claims 2-6, 8-12 and 14-24, these claims remain rejected by virtue of dependency to their independent claims.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3, 5, 7-9, 11-15, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Kelekar (US 2005/0005169 A1), hereinafter Kelekar, in view of Oberheide et al. (US 2018/0173881A1), hereinafter Oberheide, in view of Aziz et al. (US 10,462,173 B1), hereinafter Aziz.
Regarding claim 1, Kelekar discloses a method for inventorying network hosts, the method comprising:
identifying, by a network scanning device (Kelekar, Para. 0287, on a signal that the vulnerability database is updated, the VA server scans the target system for presence of these new vulnerabilities, and if found sends a report to the agent), at least one of a plurality of tests based on an application of a model to one or more characteristics of a network following detection of a host device in a segment of the network (Kelekar, Para. 0156, this is referred to as real-time; that is, even though it cannot be categorized it in clock cycles as is done to characterize a real-time application, this is done the moment it is possible. Thus, the system ensures that at no time—excepting the time taken to report the services, and run the tests as described above—the host/device/target has network services listening on it which have undetected vulnerabilities in them, thus resulting in real-time vulnerability detection for services);
applying, by the network scanning device, the identified at least one of the plurality of tests on the detected host device via one or more communications over the network to the detected host device to obtain at least one result of the identified at least one of the plurality of tests from the detected host device (Kelekar, Para. 0157, it can find out which new port is opened or if any new interface has become active, and do tests to detect the services that have started on those ports, and then conduct vulnerability tests on those services),
wherein an agent is not deployed on the detected host device or used to obtain the at least one result and the obtained at least one result comprises identifiable information for the detected host device (Kelekar, Para. 0157, the point is the agent passes information that indicates that the vulnerability status of the host/device could have changed and vulnerability tests may have to be conducted by the server to produce the latest vulnerability status of the host/device) and (Kelekar, Para. 0154, in a special case, both the agent and server can run on the same host/device, but generally the server would be run on one machine, and agents would be run on each of the machines on which one wants to do real-time vulnerability assessment);
Kelekar does not explicitly disclose generating, by the network scanning device, a classification value for the detected host device based on the identifiable information,
wherein the classification value represents a likelihood that the identifiable information is capable of uniquely identifying the detected host device;
determining, by the network scanning device and before vulnerability scanning of the detected host device is conducted, when the identifiable information uniquely identifies the detected host device based on whether the classification value exceeds a classification threshold;
However, Oberheide teaches generating, by the network scanning device, a classification value for the detected host device based on the identifiable information (Oberheide, Para. 0063, generating endpoint health intelligence can include comparing endpoint health data to endpoint health standards. Specific endpoint health data types (e.g., browser type, browser, version, etc.) can be compared to specific endpoint health standards related to the endpoint health data types),
wherein the classification value represents a likelihood that the identifiable information is capable of uniquely identifying the detected host device (Oberheide, Para. 0067, such historical data can be used in generating endpoint health intelligence regarding a current endpoint user device (e.g., an endpoint user device currently attempting to access a network));
determining, by the network scanning device and before vulnerability scanning of the detected host device is conducted, when the identifiable information uniquely identifies the detected host device based on whether the classification value exceeds a classification threshold (Oberheide, Para. 0079, endpoint health notifications can be generated at specified time intervals (e.g., every hour, every day, every week, etc.), manually determined (e.g., in response to an administrator requesting endpoint health intelligence), automatically determined (e.g., in response to a vulnerability level of an endpoint user device or a network exceeding a threshold vulnerability level), and/or otherwise generated) and (Oberheide, Para. 0078, the form of endpoint health notifications can include one or more of: verbal content (e.g., endpoint user device “A” is currently using web browser “B”, etc.), numerical content (e.g., 80% of users in the network over the past week have used operating system “X” in accessing the network, etc.), graphical content (e.g., a notification highlighted in red to illustrate a high level of security risk for an endpoint user device, etc.)); and
Kelekar and Oberheide are both considered to be analogous to the claim invention because they are in the same field of protecting the network environment from vulnerabilities that may be present on host devices communicating via the network. Therefore, it would have been obvious to someone ordinary skill in the art before the effective filing date of the claimed invention to have modified Kelekar to incorporate the teachings of Oberheide to include generating, by the network scanning device, a classification value for the detected host device based on the identifiable information (Oberheide, Para. 0063), wherein the classification value represents a likelihood that the identifiable information is capable of uniquely identifying the detected host device (Oberheide, Para. 0067); determining, by the network scanning device and before vulnerability scanning of the detected host device is conducted, when the identifiable information uniquely identifies the detected host device based on whether the classification value exceeds a classification threshold (Oberheide, Para. 0079) and (Oberheide, Para. 0078). Doing so would aid to ensure compliance (that is, that a host agent has been installed and is up-to-date on every endpoint accessing the network) across the myriad devices in use on a computer network. Thus, there is a need in the authentication field to create a new and useful method for enforcing endpoint health standards (Oberheide, Para. 0004).
Kelekar and Oberheide do not explicitly disclose updating, by the network scanning device, a host inventory database to include at least the identifiable information, when the determination indicates that the classification value exceeds the classification threshold.
However, Aziz teaches updating, by the network scanning device, a host inventory database to include at least the identifiable information (Aziz, Col. 10, Lines 28-36, the indicator scanner 330 may incorporate, in memory (not separately shown), a database of known malware indicators. The database of known malware indicators may be updated by receiving through the network interface(s) 310 from the public network 110 or the private network 120, via network interconnects 130, new indicators of malware. The database of indicators may also be updated by the indicator generator 385), when the determination indicates that the classification value exceeds the classification threshold (Aziz, Col. 10, Lines 65-68 and Col. 11, Lines 1-4, the heuristics engine 335 may include scoring logic to correlate one or more characteristics of potential malware with a score of maliciousness, the score indicating the level of suspiciousness and/or maliciousness of the object. In one embodiment, when the score is above a first threshold, the heuristic engine 335 may generate an alert that the object is malicious).
Kelekar, Oberheide and Aziz are all considered to be analogous to the claim invention because they are in the same field of protecting the network environment from vulnerabilities that may be present on host devices communicating via the network. Therefore, it would have been obvious to someone ordinary skill in the art before the effective filing date of the claimed invention to have modified Kelekar and Oberheide to incorporate the teachings of Aziz to include updating, by the network scanning device, a host inventory database to include at least the identifiable information (Aziz, Col. 10, Lines 28-36), when the determination indicates that the classification value exceeds the classification threshold (Aziz, Col. 10, Lines 65-68 and Col. 11, Lines 1-4).. Doing so would aid to enhance the determination of maliciousness used to evaluate or modify the risk represented by the malware to endpoints on the network. For example, a malicious object is determined to affect a greater set of applications, or versions of an application, included in the software profiles of the original and additional endpoints, and thereby represent a threat to a larger set of endpoints on the network running those software profiles (Aziz, Col. 4, lines, 60-67).
Regarding claim 2, the combination of Kelekar and Oberheide in view of Aziz teaches the method of claim 1, further comprising ranking, by the network scanning device, a subset of the plurality of tests based on the one or more characteristics of the network to identify the at least one of the plurality of tests (Kelekar, Para. 0008, The (network-based) vulnerability assessment itself is usually carried in two stages: the first stage comprises of finding out which services are running and the second stage comprises running scripts to do vulnerability assessment on these services. Part of the first stage consists of port scanning. Port scanning is the process of figuring out if a particular port on the target host is open, and this is done by sending various kinds of packets to the port), wherein each of the plurality tests is configured to target one or more unique attributes of the detected host device or another host device (Kelekar, Para. 0328, all the plugins are loaded from a directory meant for plugins (this directory is specified in the nessusd.conf file) while starting nessusd, and then nessus is used to run the tests on a particular IP address as target).
Regarding claim 3, the combination of Kelekar and Oberheide in view of Aziz teaches the method of claim 1, further comprising identifying, by the network scanning device, the at least one of the plurality of tests based at least in part on a protocol used by the detected host device to provide a service or to communicate with another host device within the network (Kelekar, Para. 0328, all the plugins are loaded from a directory meant for plugins (this directory is specified in the nessusd.conf file) while starting nessusd, and then nessus is used to run the tests on a particular IP address as target. The plugins that are loaded usually consist of a port scanner such as nmap, plugins such as find_services which identify the services running on specific ports, and plugins meant for specific services and for standard ports (this is explained in detail below)), wherein the updating facilities subsequent vulnerability scanning of the detected host device in accordance with contents of the host inventory database (Aziz, Col. 10, Lines 28-36, the indicator scanner 330 may incorporate, in memory (not separately shown), a database of known malware indicators. The database of known malware indicators may be updated by receiving through the network interface(s) 310 from the public network 110 or the private network 120, via network interconnects 130, new indicators of malware. The database of indicators may also be updated by the indicator generator 385). Therefore, it would have been obvious to someone ordinary skill in the art before the effective filing date of the claimed invention to have modified Kelekar and Oberheide to incorporate the teachings of Aziz to include updating, by the network scanning device, a host inventory database to include at least the identifiable information, when the determination indicates the detected host device is uniquely identifiable (Aziz, Col. 10, Lines 28-36. Doing so would aid to enhance the determination of maliciousness used to evaluate or modify the risk represented by the malware to endpoints on the network. For example, a malicious object is determined to affect a greater set of applications, or versions of an application, included in the software profiles of the original and additional endpoints, and thereby represent a threat to a larger set of endpoints on the network running those software profiles (Aziz, Col. 4, lines, 60-67).
Regarding claim 5, the combination of Kelekar and Oberheide in view of Aziz teaches the method of claim 1, further comprising (Kelekar, Para. 0162, tracking the starting and stopping of each of the listening network services on each of the open ports of each of the active interfaces on the target machine, and intimating the open port numbers along with the IP address of the interface(s) to the server); storing, by the network scanning device, the identifiable information correlated with a generated unique identifier for the detected host device in an entry of the host inventory database to facilitate subsequent vulnerability scanning of the detected host device (Aziz, Col. 10, Lines 28-36, the indicator scanner 330 may incorporate, in memory (not separately shown), a database of known malware indicators. The database of known malware indicators may be updated by receiving through the network interface(s) 310 from the public network 110 or the private network 120, via network interconnects 130, new indicators of malware. The database of indicators may also be updated by the indicator generator 385), when determination indicates that the classification value exceeds the classification threshold (Aziz, Col. 10, Lines 65-68 and Col. 11, Lines 1-4, the heuristics engine 335 may include scoring logic to correlate one or more characteristics of potential malware with a score of maliciousness, the score indicating the level of suspiciousness and/or maliciousness of the object. In one embodiment, when the score is above a first threshold, the heuristic engine 335 may generate an alert that the object is malicious). Therefore, it would have been obvious to someone ordinary skill in the art before the effective filing date of the claimed invention to have modified Kelekar and Oberheide to incorporate the teachings of Aziz to include storing, by the network scanning device, the identifiable information correlated with a generated unique identifier for the detected host device in an entry of the host inventory database to facilitate subsequent vulnerability scanning of the detected host device (Aziz, Col. 10, Lines 28-36), when determination indicates that the classification value exceeds the classification threshold (Aziz, Col. 10, Lines 65-68 and Col. 11, Lines 1-4). Doing so would aid to enhance the determination of maliciousness used to evaluate or modify the risk represented by the malware to endpoints on the network. For example, a malicious object is determined to affect a greater set of applications, or versions of an application, included in the software profiles of the original and additional endpoints, and thereby represent a threat to a larger set of endpoints on the network running those software profiles (Aziz, Col. 4, lines, 60-67).
Regarding claim 7, the claim is interpreted and rejected for the same rational set forth
in claim 1.
Regarding claim 8, the claim is interpreted and rejected for the same rational set forth
in claim 2.
Regarding claim 9, the combination of Kelekar and Oberheide in view of Aziz teaches the network scanning device of claim 7, wherein the one or more processors are further configured to execute the stored programmed instructions to identify the at least one of the plurality of tests based at least in part on a protocol used by the detected host device to provide a service or to communicate with another host device within the network (Kelekar, Para. 0328, All the plugins are loaded from a directory meant for plugins (this directory is specified in the nessusd.conf file) while starting nessusd, and then nessus is used to run the tests on a particular IP address as target. The plugins that are loaded usually consist of a port scanner such as nmap, plugins such as find_services which identify the services running on specific ports, and plugins meant for specific services and for standard ports (this is explained in detail below)).
Regarding claim 11, the claim is interpreted and rejected for the same rational set forth
in claim 5.
Regarding claim 13, the claim is interpreted and rejected for the same rational set forth
in claims 1 and 7.
Regarding claim 14, the claim is interpreted and rejected for the same rational set forth
in claims 2 and 8.
Regarding claim 15, the combination of Kelekar and Oberheide in view of Aziz teaches the non-transitory machine-readable medium of claim 13, wherein the executable code, when executed by the one or more processors, further causes the one or more processors to identify the at least one of the plurality of tests based at least in part on a protocol used by the host device to provide a service or to communicate with another host device within the network (Kelekar, Para. 0328, All the plugins are loaded from a directory meant for plugins (this directory is specified in the nessusd.conf file) while starting nessusd, and then nessus is used to run the tests on a particular IP address as target. The plugins that are loaded usually consist of a port scanner such as nmap, plugins such as find_services which identify the services running on specific ports, and plugins meant for specific services and for standard ports (this is explained in detail below)).
Regarding claim 17, the claim is interpreted and rejected for the same rational set forth
in claims 5 and 11.
Claims 4, 10, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Kelekar (US 2005/0005169 A1), hereinafter Kelekar, in view of Oberheide et al. (US 2018/0173881A1), hereinafter Oberheide, in view of Aziz et al. (US 10,462,173 B1), hereinafter Aziz, and further in view of Takahashi et al. (US 2019/0052652 A1), hereinafter Takahashi.
Regarding claim 4, the combination of Kelekar and Oberheide in view of Aziz fails to teach the method of claim 1, wherein the model comprises a machine learning model and the method further comprises updating, by the network scanning device, the machine learning model based on the one or more characteristics of the network, the identified at least one of the plurality of tests, and the identifiable information.
However, Takahashi teaches wherein the model comprises a machine learning model and the method further comprises updating, by the network scanning device, the machine learning model based on the one or more characteristics of the network, the identified at least one of the plurality of tests, and the identifiable information (Takahashi, Para. 0068, the generated statistics, the raw Netflow statistics described above and the extracted features may be used by a machine learning process classifier (220) with a model to generate the predictions (222) about the behavior of the hosts).
Kelekar, Oberheide, Aziz and Takahashi considered to be analogous to the claim invention because they are in the same field of protecting the network environment from vulnerabilities that may be present on host devices communicating via the network. Therefore, it would have been obvious to someone ordinary skill in the art before the effective filing date of the claimed invention to have modified Kelekar, Oberheide, Aziz to incorporate the teachings of Takahashi to include wherein the model comprises a machine learning model and the method further comprises updating, by the network scanning device, the machine learning model based on the one or more characteristics of the network, the identified at least one of the plurality of tests, and the identifiable information (Takahashi, Para. 0068). Doing so would aid to prioritize finding data that have a reasonable level of confidence in to avoid False Positives (even though false positives still appear from time to time). Furthermore, innovations in internet crime (such as new types of malicious activity, new attack tools, new hardware types used to form botnets, etc.) makes confirming that addresses are malicious a very slow process and error prone process (Takahashi, Para. 0004).
Regarding claim 10, the claim is interpreted and rejected for the same rational set forth
in claim 4.
Regarding claim 16, the claim is interpreted and rejected for the same rational set forth
in claim 4 and 10.
Claims 6, 12, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Kelekar (US 2005/0005169 A1), hereinafter Kelekar, in view of Oberheide et al. (US 2018/0173881A1), hereinafter Oberheide, in view of Aziz et al. (US 10,462,173 B1), hereinafter Aziz, and further in view of Dixon et al (US 2015/0043576 A1), hereinafter Dixon.
Regarding claim 6, the combination of Kelekar and Oberheide in view of Aziz does not explicitly teach the method of claim 1, wherein the traffic comprises a segment boundary between the network scanning device and the detected host device at which link layer information is stripped away from network traffic originating at the host device.
However, Dixon teaches wherein the traffic comprises a segment boundary between the network scanning device (Dixon, Para. 0027, a system includes a switch cluster having a plurality of switches, the plurality of switches including at least an entry switch having an interface for connecting to a first host and an exit switch having an interface for connecting to a second host, and a switch controller in communication with the plurality of switches in the switch cluster via a communication protocol, a switch controller corresponds to network scanning device) and the detected host device at which link layer information is stripped away from network traffic originating at the host device (Dixon, Para. 0099, this ARP response packet (5) is received by the Exit Switch Z 504 c, which then reformats the packet to adhere to the communication protocol by adding an appropriate header (such as OF Hdr PKT IN) and sends this packet (6), which maintains all the information from packet (5), to the switch controller 506) and (Dixon, Para. 0100, the switch controller 506 resolves the ARP request with the ARP response, and therefore sends the original packet (7) from Device A 502 a to Device C 502 c via switch Z 504 c. This packet will be formatted with the communication protocol header (such as OF Hdr PKT OUT) and indicates the SMAC as the virtual router (VRT_MAC) on the switch controller 506, the DMAC as Device C 502 c (MAC_C), the SRC-IP as Device A 502 a (10.1.1.2), and the DEST-IP as Device C 502 c (10.2.1.2)) and (Dixon, Para. 0006, forward the ARP request packet to the switch controller after adding a header to the ARP request packet that adheres to the communication protocol, receive an ARP response packet from the switch controller, the ARP response packet indicating: a source IP address corresponding to a virtual router of the switch controller and a source media access address (SMAC) corresponding to the switch controller, forward the ARP response packet to the first host after stripping a header from the ARP response packet that adheres to the communication protocol, and set the virtual router of the switch controller as a default gateway for traffic received from the first host).
Kelekar, Oberheide, Aziz and Dixon are all considered to be analogous to the claim invention because they are in the same field of protecting the network environment from vulnerabilities that may be present on host devices communicating via the network. Therefore, it would have been obvious to someone ordinary skill in the art before the effective filing date of the claimed invention to have modified Kelekar, Oberheide, Aziz to incorporate the teachings of Dixon to include wherein the traffic comprises a segment boundary between the network scanning device (Dixon, Para. 0027) and the detected host device at which link layer information is stripped away from network traffic originating at the host device (Dixon, Para. 0099) and (Dixon, Para. 0100) and (Dixon, Para. 0006). Doing so would aid to provide a mechanism to provide L3 support for a SDN-based switch cluster in a scalable fashion. Existing conventional methods to accomplish L3 communications rely on OpenFlow 1.0 style TCAM tables, also known as access control list (ACL) tables, alone which are expensive to implement and typically have a much lower number of total entries. (Dixon, Para. 0005).
Regarding claim 12, the claim is interpreted and rejected for the same rational set forth
in claim 6.
Regarding claim 18, the claim is interpreted and rejected for the same rational set forth
in claims 6 and 12.
Claims 19-21 are rejected under 35 U.S.C. 103 as being unpatentable over Kelekar (US 2005/0005169 A1), hereinafter Kelekar, in view of Oberheide et al. (US 2018/0173881A1), hereinafter Oberheide, in view of Aziz et al. (US 10,462,173 B1), hereinafter Aziz, and further in view of Vincent et al. (US 2016/0110214 A1), hereinafter Vincent.
Regarding claim 19, The method of claim 1, the combination of Kelekar and Oberheide in view of Aziz does not explicitly teach further comprising determining, by the network scanning device, that the detected host device is not uniquely identifiable via an address resolution protocol (ARP) request before identifying the at least one of the plurality of tests, wherein the segment of the network comprises a subnet, a virtual local area network (VLAN), or a virtual private network (VPN).
However, Vincent teaches further comprising determining, by the network scanning device, that the detected host device is not uniquely identifiable via an address resolution protocol (ARP) request before identifying the at least one of the plurality of tests, wherein the segment of the network comprises a subnet, a virtual local area network (VLAN), or a virtual private network (VPN) (Vincent, Para. 0085, for example, L2 and/or L3 source anti-spoofing, as well as trapping for all non-IP and broadcast packets (i.e., to service DHCP, ARP, etc.). The offload device can perform a lookup in a pre-populated rule table 706, such as may be based on an L2 destination and an L3 destination with a subnet mask, with a generic case being an IPV4 “/32” subnet that specifies a single target. Assuming a rule hit with a rule type of forward, the rule can also specify a pointer in system memory to the tunnel header that the offload device will prepend to the outgoing packet).
Kelekar, Oberheide, Aziz and Vincent are all considered to be analogous to the claim invention because they are in the same field of protecting the network environment from vulnerabilities that may be present on host devices communicating via the network. Therefore, it would have been obvious to someone ordinary skill in the art before the effective filing date of the claimed invention to have modified Kelekar, Oberheide and Aziz to incorporate the teachings of Quinlan to include further comprising determining, by the network scanning device, that the detected host device is not uniquely identifiable via an address resolution protocol (ARP) request before identifying the at least one of the plurality of tests, wherein the segment of the network comprises a subnet, a virtual local area network (VLAN), or a virtual private network (VPN) (Vincent, Para. 0085). Doing so would aid to by including a fake port information, conventional routers and other such devices which can obtain improved load distribution, as many conventional hardware devices base load distribution decisions at least in part upon the port specified in the header. A router or offload device can see an IP address and TCP information, for example, and can process the packet as a standard packet. Such an approach also can be advantageous as it can be implemented primarily in software using conventional hardware devices and networks (Vincent, Para. 0056).
Regarding claim 20, the claim is interpreted and rejected for the same rational set forth
in claim 19.
Regarding claim 21, the claim is interpreted and rejected for the same rational set forth
in claims 19 and 20.
Claims 22-24 are rejected under 35 U.S.C. 103 as being unpatentable over Kelekar (US 2005/0005169 A1), hereinafter Kelekar, in view of Oberheide et al. (US 2018/0173881A1), hereinafter Oberheide, in view of Aziz et al. (US 10,462,173 B1), hereinafter Aziz, and further in view of Dang et al. (US 2018/0324030 A1), hereinafter Dang.
Regarding claim 22, the combination of Kelekar and Oberheide in view of Aziz does not explicitly teach the method of claim 1, further comprising determining, by the network scanning device, that the classification value fails to exceed the classification threshold when the identifiable information comprises only one or more port numbers of one or more open ports of the detected host device.
However, Dang teaches determining, by the network scanning device, that the classification value fails to exceed the classification threshold when the identifiable information comprises only one or more port numbers of one or more open ports of the detected host device (Dang, Para. 0130, performance thresholds and target performance levels could be used as lower bounds, such that an observed or monitored performance would need to fall below a threshold or target level in order to trigger an alert. Target ranges could be similarly used to define acceptable operation either within a range or instead outside of a range) and (Dang, Para. 0094, in the classification phase, proxy servers 312 may further probe each discovered device to determine the version of its operating system. The probes used for a particular device are based on information gathered about the devices during the scanning phase. For example, if a device is found with TCP port 22 open, a set of UNIX®-specific probes may be used). Kelekar, Oberheide, Aziz and Dang are all considered to be analogous to the claim invention because they are in the same field of protecting the network environment from vulnerabilities that may be present on host devices communicating via the network. Therefore, it would have been obvious to someone ordinary skill in the art before the effective filing date of the claimed invention to have modified Kelekar and Aziz to incorporate the teachings of Dang to include further comprising determining, by the network scanning device, that the classification value fails to exceed the classification threshold when the identifiable information comprises only one or more port numbers of one or more open ports of the detected host device (Dang, Para. 0130) and (Dang, Para. 0094). Doing so would aid to efficiently create custom applications; enterprises would benefit from a remotely-hosted application platform that eliminates unnecessary development complexity. The goal of such a platform would be to reduce time-consuming, repetitive application development tasks so that software engineers and individuals in other roles can focus on developing unique, high-value features (Dang, Para. 0030).
Regarding claim 23, the claim is interpreted and rejected for the same rational set forth
in claim 22.
Regarding claim 24, the claim is interpreted and rejected for the same rational set forth
in claims 22 and 23.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See PTO-892.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GITA FARAMARZI whose telephone number is (571)272-0248. The examiner can normally be reached Monday- Friday 9:00 am- 6:00 pm.
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, Jorge L. Ortiz-Criado can be reached at (571)272-7624. 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.
/GITA FARAMARZI/Examiner, Art Unit 2496 /KEVIN AYALA/Primary Examiner, Art Unit 2496
Prosecution Insights