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 .
Status of Claims
The following is a Final Office Action in response to applicant’s filing on December 23, 2025. 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 1, 7, and 13 obviates the claim rejection, therefore the claim rejection under 35 USC § 112(a), is withdrawn.
However, the newly amended claims 6, 12, and 18 are rejected under 35 U.S.C.112(a) for failing to comply with the written description and enablement requirements.
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 "identifiable information excludes an Internet protocol (IP) address associated with the detected host device" has been canceled. 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 6, 12, and 18 are rejected under 35 U.S.C.112(a) for failing to comply with the written description and enablement requirements.
Rejection under 35 U.S.C. § 103
No Motivation to Combine
On Pages 10-12 of remarks, Applicant states that the Office has acknowledged that Kelekar does not disclose generating a classification value or a likelihood of unique identification, and Office relies on Dang to address this deficiency. Further, Applicant argues that “The Office action is simply devoid of any motivation to combine rationale. As explained in MPEP § 2143, "[t]he Supreme Court in KSR noted that the analysis supporting a rejection under 35 U.S.C. 103 should be made explicit." Kelekar does not have anything to do with creating custom applications or application development tasks, as facilitated by the platform disclosed by Dang.”.
The Examiner agrees that Kelekar alone does not expressly disclose generating a likelihood-based classification value. However, obviousness under 35 U.S.C. § 103 does not require that a single reference disclose all limitations. As set forth in KSR, a reference may be modified by the teachings of another reference where doing so would have been obvious to a person of ordinary skill in the art. Dang is relied upon specifically to provide the likelihood-based classification functionality absent from Kelekar. The presence of of an agent in Kelekar does not preclude further analysis or validation of host identiry information at the server level. Moereover, upon review of independent claims 1, 7, and, 13, the Examiner confirms that the claims do not recite or exclude the use of host-based agents. Accordingly Applicant’s arguments distinguishing the prior art based on agent deployment rely on features that are not claimed and therefore cannot overcome the 103 rejection.
B. Prior Art Combination Fails to Teach Claim Limitations
On pages 12-13 of remarks, Applicant argues that “The technology in Dang relates to performance analytics for managed network entities. As explained in paragraph [0006]… However, the likelihood in Dang that a different alert will be issued for monitored performance of a network entity has nothing to do with a likelihood that identifiable information is capable of uniquely identifying a detected host device”. The Examiner disagrees. The Federal Circuit has held that intended use or application context does not limit claim scope unless explicitly recited. Dang expressly discloses this challenge can be met by constructing one or more sets of performance analytics of both individual and groups of manageable network entities that are tracked or monitored by way of status alerts, which in turn are jointly analyzed to determine specific performance interdependencies between the services and servers of any given group, See Paragraph [0006]. The likelihood determination is therefore inherently associated with information sufficient to distinguish one network entity from another.
Further, Dang in paragraph [0117] discloses this challenge can be met by constructing one or more sets of performance analytics of both individual and groups of manageable network entities that are tracked or monitored by way of status alerts, which in turn are jointly analyzed to determine specific performance interdependencies between the services and servers of any given group. Applicant’s argument attempts to impose a requirement that the likelihood itself must represent a standalone “identity confidence” metric. The claims do not require such a limitation.
Under the BRI, it is sufficient that the likelihood be determined for an identified entity, and Dang explicitly satisfies this requirement by issuing a score notification that includes both (i) the likelihood and (ii) the identity of the particular network entity to which the likelihood applies, see paragraph [0007].
Furthermore, on pages 11-12 of remarks, Applicant argues that “the likelihood in Dang that a different alert will be issued for monitored performance of a network entity has nothing to do with a likelihood that identifiable information is capable of uniquely identifying a detected host device, as required by the above-identified claim limitations”. The Examiner disagrees. While Dang frames its likelihood analysis in terms of alerts, the claims are not limited by that context. The claim recites “generating a classification value…wherein the classification value represents a likelihood that the identifiable information is capable of uniquely identifying the detected host device”. However, the “likelihood” is not restricted to any particular semantic interpretation. Dang expressly teaches “computing a statical value”, “associating that likelihood with a specific network entity identity”, and “comparing the likelihood to a threshold”. These structural and functional aspects correspond directly to the claim classification value under the broadest reasonable interpretation.
Therefore, the Applicant’s argument is not persuasive. Accordingly, the rejection under 35 USC § 103 of claims 1-24 are maintained.
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 6, 12, and 18 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 6 recites “wherein the network comprises a segment boundary between the network scanning device and the detected host device at which link layer information encapsulating one or more address resolution protocol (ARP) packets comprising an Internet Protocol address for the detected host device is stripped away from network traffic originating at the detected host device.”. Given that the limitation of claim 1, for the encapsulating one or more address resolution protocol (ARP) packets, there is no disclosure as to how one or more address resolution protocol (ARP) packets have been encapsulated, (i.e., ARP messages are encapsulated by a link layer protocol communicated within the boundaries of a single network, such as the internal communication network 18. Accordingly, while some hosts, such as the host device 20(1) coupled directly to the external communication network 22, may have an IP address that is detected by the network scanning device 12, the network scanning device 12 will not be able to inventory such hosts utilizing ARP packets, and will not therefore be able to obtain the uniquely identifiable information in the form of a MAC address, see paragraph [0038]). The disclosure does not provide any teaching, or algorithm as to how an APR packet would be encapsulated or how such encapsulation would be implemented in the context of the claimed network scanning device.
The level of detail required to satisfy the written description requirement varies depending on the nature and scope of the claims and on the complexity and predictability of the relevant technology. Ariad, 598 F.3d at 1351, 94 USPQ2d at 1172; Capon v. Eshhar, 418 F.3d 1349, 1357-58, 76 USPQ2d 1078, 1083-84 (Fed. Cir. 2005). Computer-implemented inventions are often disclosed and claimed in terms of their functionality. For computer-implemented inventions, the determination of the sufficiency of disclosure will require an inquiry into the sufficiency of both the disclosed hardware and the disclosed software due to the interrelationship and interdependence of computer hardware and software. The critical inquiry is whether the disclosure of the application relied upon reasonably conveys to those skilled in the art that the inventor had possession of the claimed subject matter as of the filing date. Vasudevan Software, Inc. v. MicroStrategy, Inc., 782 F.3d 671, 682. 114 USPQ2d 1349, 1356 (citing Ariad Pharm., Inc. V. Eli Lilly & Co, 598 F.3d 1336, 1351, 94 USPQ2d 1161, 1172 (Fed. Cir. 2010) in the context of determining possession of a claimed means of accessing disparate databases).
dependent claims 12 and 18 are similarly rejected.
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, 17, 22-24 are rejected under 35 U.S.C. 103 as being unpatentable over Kelekar (US 2005/0005169 A1), hereinafter Kelekar, in view of Dang et al. (US 2018/0324030 A1), hereinafter Dang, 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 the obtained at least one result comprises identifiable information for the detected host device (Kelekar, Para. 0092, Vulnerability assessment server compares the status of open ports that it has with the new status and if it finds a difference then it finds which service is running and does Vulnerability assessment and reports the result to the Agent);
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, that the classification value exceeds a classification threshold; and 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, Dang teaches generating, by the network scanning device, a classification value for the detected host device based on the identifiable information (Dang, Para. 0007, issuing a score notification for the different alert in response to the determined statistical likelihood exceeding a score threshold, wherein the score notification includes the determined statistical likelihood and an identity of the particular network entity),
wherein the classification value represents a likelihood that the identifiable information is capable of uniquely identifying the detected host device (Dang, Para. 0007, wherein the score notification includes the determined statistical likelihood and an identity of the particular network entity);
determining, by the network scanning device and before vulnerability scanning of the detected host device is conducted, that the classification value exceeds a classification threshold (Dang, Para. 0007, issuing a score notification for the different alert in response to the determined statistical likelihood exceeding a score threshold, wherein the score notification includes the determined statistical likelihood and an identity of the particular network entity) and (Dang, Para. 0128, the severity levels illustrated in FIG. 8B could correspond to gradations of thresholds for issuing alerts. By way of example, the white circle could correspond to a capacity utilization of less than 10%, while the black circle could correspond to a capacity utilization of 90%, and the gradations in between could correspond to capacity utilizations of 30%, 50%, and 70%. An alert of a given gradation could then be issued for observed/monitored capacity utilization greater than the corresponding threshold for the given gradation);
Kelekar and Dang 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 Dang to include generating, by the network scanning device, a classification value for the detected host device based on the identifiable information (Dang, Para. 0007), wherein the classification value represents a likelihood that the identifiable information is capable of uniquely identifying the detected host device (Dang, Para. 0007). 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).
Kelekar and Dang 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, Dang 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 Dang 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). 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 Nyanchama 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 2, the combination of Kelekar and Dang 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 Dang 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 Dang 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 Dang 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 Nyanchama 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 Dang 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 Dang 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.
Regarding claim 22, the combination of Kelekar and Dang in view of Aziz teaches 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 (Dang, Para. 0130, performance thresholds and target performance levels could be used as lower bounds, such that a 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). 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.
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 Dang et al. (US 2018/0324030 A1), hereinafter Dang, 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 Dang 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, Dang, 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, Dang, 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 Dang et al. (US 2018/0324030 A1), hereinafter Dang, 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 Dang 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 encapsulating one or more address resolution protocol (ARP) packets comprising an Internet Protocol address for the detected host device 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, Dang, 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, Dang, 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 encapsulating one or more address resolution protocol (ARP) packets comprising an Internet Protocol address for the detected host device 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 Dang et al. (US 2018/0324030 A1), hereinafter Dang, 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 Dang 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, Dang, 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, Dang 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.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See PTO-892.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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
/JORGE L ORTIZ CRIADO/Supervisory Patent Examiner, Art Unit 2496