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 11/21/2025 has been entered.
Response to Amendment
Examiner has fully considered Applicant’s amendments to the Claims in the arguments filed on 11/21/2025. Claims 1, 11, and 21 are amended. Claims 22-27 are newly added. Claims 1-9, 11-19, and 21-27 are pending in the application. Outstanding objections to claims 3, 6, 13, and 16 are upheld herein.
Examiner notes that the Amendments presented in the Response After Final Action, dated 09/25/2025, are not reflected in the claims presented in the Request For Continued Examination, dated 11/21/2025. However, Examiner will consider the additional amendments presented on 09/25/2025 as is believed to have been intended herein.
Response to Arguments
Applicant’s arguments filed 11/21/2025, with respect to the rejections of independent claims 1, 11, and 21 and their corresponding dependent claims under 35 USC 103 have been fully considered, but they are not persuasive. Examiner respectfully submits that the previously applied reference from Raugus is sufficient to teach the amended limitation(s) “wherein the alert information describes a possibly-compromised status/suspicious activity of a device associated with the IP address information”. Specifically, Raugus teaches generating and transmitting an alert based on a determination that a score indicating a likelihood of malware presence on a monitored computing system exceeds a threshold (Raugus – Paragraph [0077]). The score is generated by observing behavioral features which indicate that a system exhibits activity of a specific class of malware, for example (Raugus – Paragraph [0078]; [0022]; [0029]-[0067]). Thus, the generation of the alert represents both the observation of suspicious activity and the determination of a possibly-compromised status, the score itself reflecting the suspicious activity and the threshold marking the decision point for the possibly-compromised status. Raugus further teaches generating and sending alerts regarding detections of user-specified instances/classes/types of malware, the alerts including a timestamp of a detection, triggering file name, the name or IP address of the infected host, a hash for the malware, the name/type of the alert, and a URL which when accessed provides further details on the circumstances or activity which contributed to the alert (Raugus – Paragraph [0079]). Therefore, in view of the above, the score is interpreted to represent the claimed suspicious activity, the score exceeding the threshold is interpreted to represent the claimed possibly-compromised status, and the contents of the alert which provide context of the triggering event(s) and the status are interpreted to represent the claimed alert information which describes the possibly-compromised status of the device and/or suspicious activity of the device. Raugus’ alert may also include an IP address of the host, likewise associating the status, activity, and alert information with the host.
Claim Objections
Claims 1, 3, 6, 11, 13, 16, and 21 are objected to because of the following informalities:
Independent Claims 1, 11, and 21 are objected to because they do not include the previously presented amendments included in the Response After Final Action, dated 09/25/2025
Each of claims 3, 6, 13, and 16 include the limitation “threat information”. This limitation is unclear because it is unclear if the “threat information” of claims 3, 6, 13, and 16 are intended to represent the same threat information established in independent claims 1 and 11. The limitation could be re-written as “the threat information” for clarity.
Appropriate correction is required.
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, 6-9, 11-13, 16-19, 21-23, and 26-27 are rejected under 35 U.S.C. 103 as being unpatentable over Glenn et al. (US 20140007235 A1), hereinafter Glenn, in view of Raugus et al. (US 20150128263 A1), hereinafter Raugus, and Bardenstein (US 10291637 B1), hereinafter Bardenstein.
Regarding Claim 1:
Glenn teaches a method of monitoring network activity, the method comprising (Glenn – Paragraph [0008]: A set of embodiments, therefore, provides improved solutions for detecting and/or treating malware on a subscriber's premise network. Such solutions can include, but are not limited to, tools and techniques that can detect, and/or enable the detection of, malware infections on individual subscriber devices within the subscriber's network. In a particular embodiment, for example, a premise gateway, or other device on the subscriber's premise network, is configured to analyze packets traveling through the premise gateway and, based on that analysis, identify one or more subscriber devices that are infected with malware): monitoring, at an internet-service-provider (ISP) server, a plurality of data packets (Glenn – Paragraph [0008]: a premise gateway, or other device on the subscriber's premise network, is configured to analyze packets traveling through the premise gateway … in certain embodiments, the malware detection device (whether the premise gateway or another device on the premise network) can be operated and/or configured by the ISP), the plurality of data packets including data packets sent by a local network to an external network and data packets received by the local network from the external network (Glenn – Paragraph [0008]: a premise gateway, or other device on the subscriber's premise network, is configured to analyze packets traveling through the premise gateway; and Paragraph [0012]: a method in accordance with one set of embodiments can be used to identify a malware infection. In an exemplary embodiment, the method comprises providing, with a premise gateway, communication between a premise network at a customer premises and an external network outside the customer premises; and Paragraph [0035]: FIG. 1A illustrates a system 100 that can be used to detect a malware infection at a subscriber premises. The system comprises a premise gateway 105, which as noted above, can include a broadband modem (e.g., xDSL modem, cable modem, etc.), wireless (and/or wired) router, wireless access point, and/or any other hardware or software that can provide network access for the customer premises (indicated by the broken lines on FIG. 1). In an embodiment, the premise gateway includes a first interface (internal) in communication with a premise network 110 and a second (external) interface in communication with an ISP network 115 (which can provide communication with, inter alia, the Internet, which is not shown on FIG. 1A). Such interfaces can be any suitable interface, and the interface with the ISP network 115 might be different than the interface with the premise network 110, as is known in the art); identifying, at the ISP server, at least one data packet for review from among the plurality of data packets based on the plurality of data packets [and the threat information] (Glenn – Paragraph [0030]: certain embodiments allow for a device within the ISP network to detect a malware infection at particular subscriber premises, e.g., based on comprehensive analysis of packets received from the premise gateway for that subscriber. This analysis, in some cases, can identify the type of malware with which the subscriber is infected; and Paragraph [0031]: In other embodiments, the ISP might tunnel traffic from the premise network to a location in the ISP's network (e.g., using GRE, MPLS, LT2P tunnels and/or other VPN/tunneling technologies familiar to the skilled person), to allow for more detailed analysis of the traffic to identify infected devices; and Paragraph [0040]: In some embodiments, the system 100 will include a server 130, which might be in the ISP network or elsewhere (e.g., on the Internet) and/or might be operated by the ISP. The server 130, in an aspect, can configure and/or control the operation of the malware detection device 125. Merely by way of example, in some cases, the server 130 (or another device in the ISP network, such as an edge router, etc.) might be configured to analyze network traffic received from the premise gateway 105. If a malware infection is detected and/or the malware is specifically identified, the server 130 might be configured to activate the malware detection device 125 to begin detecting malware in the premise network 110. Alternatively and/or additionally, the server 130 might configure the malware detection device 105 by sending appropriate malware signatures and/or heuristic algorithms to the malware detection device 105 to assist in the detection of the identified malware in the premise network 110. In other cases, the server 130 might configure the malware detection device 125 and/or the premise gateway 105 to cause those device(s) to take specific actions, as described elsewhere herein, in response to the detection of malware at one of the devices 120 on the premise network 110); determining, at the ISP server, Internet Protocol (IP) address information associated with the at least one data packet (Glenn – Paragraph [0028]: Based on the analysis of the traffic (e.g., IP packets), the malware detection device can identify one or more subscriber devices (e.g., by IP address, MAC address, etc.) that are infected with malware); receiving, at the ISP server, first information from a first device connected to the local network, the first information including at least a device name associated with the IP address information (Glenn – Paragraph [0052]: In some cases, the malware detection device might send a notification to the ISP (e.g., via communication with the server, an e-mail message to the ISP, and/or the like) via the external network, so that the ISP can contact the customer to inform the customer of infection. Such notification to the ISP might include, without limitation, identification of the affected device, e.g., by MAC address, IP address, hostname, device type, and/or any other possible identification information that can be obtained by the malware detection device).
Glenn does not expressly teach generating, at the ISP server, second information that includes at least the device name and alert information related to the at least one data packet, wherein the alert information describes a possibly-compromised status of a device associated with the IP address information; and sending, from the ISP server to at least one device, the second information.
However, Raugus teaches generating, at the ISP server, second information that includes at least the device name and alert information related to the at least one data packet (Raugus – Paragraph [0022]: The systems, methods, media, or computer based products for malware detection discussed herein may ingest samples of network traffic passing to and/or from each computing resource selected for monitoring. For example, a span port located inside an Internet Service Provider's (ISP) network point-of-presence (POP) would permit monitoring of many computing resources simultaneously; and Paragraphs [0029-0064]: Multiple Feature sets derived from packet analysis for detecting malware; and Paragraph [0079]: In system 400, alert 460 may be generated to inform users when the results of new analyses are available … alert 460 may include the timestamp for the identification, the name of the file containing the triggering malware, or the name or IP address of the host containing the triggering malware, the SHA1 or other unique hash for the malware binary file, the alert, and the name of the type of alert that was triggered), wherein the alert information describes a possibly-compromised status of a device (Raugus – Paragraph [0077]: The generated score 440 may provide a relative measure of the likelihood of malware presence on each computing system; and Paragraph [0078]: at decision 450, the model 420 may have an associated threshold, t, 430, such that a score depicted in block 440 greater than t may indicate the likelihood that a particular computing resource 106 and 107 in computer network depicted in block 105 in system 100 has a malicious software program and/or more specifically has a malicious software program of a specific class; and Paragraph [0079]: In system 400, alert 460 may be generated to inform users when the results of new analyses are available. For example, a user may a priori have indicated the user's desire to receive notice of the suspected presence of a particular instance, type, or class of malware) associated with the IP address information (Raugus – Paragraph [0079]: alert 460 may include the timestamp for the identification, the name of the file containing the triggering malware, or the name or IP address of the host containing the triggering malware, the SHA1 or other unique hash for the malware binary file, the alert, and the name of the type of alert that was triggered. In one or more embodiments, a URL may also be provided to the user who may be used to view any meta-data or report information generated for the sample); and sending, from the ISP server to at least one device, the second information (Raugus – Paragraph [0079]: System 400 may transmit an alert 460 to the user when the new analysis is available).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Glenn, further incorporating Raugus to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Raugus’s teaching to generate and send an alert regarding a potentially compromised device in a system into Glenn’s method for monitoring network activity. This combined functionality would add practicality to Glenn’s monitoring system by generating actionable notifications of potential malicious activity.
The combination of Glenn and Raugus does not expressly teach monitoring, at the ISP server, data exchange of other local networks to determine threat information; identifying, at the ISP server, at least one data packet for review from among the plurality of data packets based on an association between the at least one data packet and the threat information.
However, Bardenstein teaches monitoring[, at the ISP server,] data exchange of other local networks to determine threat information (Bardenstein – Col. 4, Lines 41-44: The network 105 can be any type of network. For example, it can be a virtual private network (VPN), the internet, an intranet, an internal network, corporate network, local area network (LAN), wireless network, etc.; and Col. 6, Line 20-24: The analysis engine may receive network activity data 202[a-d] from one or more different networks (e.g., through network 105). For example, multiple networks may each be monitored, and the collected network activity data from each network received by the analysis engine); identifying[, at the ISP server,] at least one data packet for review from among the plurality of data packets based on an association between the at least one data packet and the threat information (Bardenstein – Col. 5, Line 49-58: Even though FIG. 1 illustrates anomaly detection system 101 as being associated with one network 105, in some embodiments, an anomaly detection system 101 may be connected to multiple networks. For example, the anomaly detection system 101 may receive logged network activity data from a plurality of different monitored networks to be stored in activity log 109. In some embodiments, the larger amount of available data from multiple networks may allow for better detection of anomalous activity and more accurate attribution of the activity to various actors and groups; and Col. 6, Line 50-54: The collected network activity data from the network activity log is analyzed by an anomaly detection model 208 in order to detect and identify anomalous activity; and Col. 7, Line 39-45: In some embodiments, the profiling model 210 may extract one or more features from the session data associated with the anomalous activity. These features may include source/destination IP addresses, source/destination ports, MAC addresses, user agent strings, URLs accessed, time of activity, commands used, filenames created, and/or the like; and Col. 5, Line 11-16: The anomaly detection system 101 logs user activity in an activity log 109. The anomaly detection system can obtain this information on its own, e.g., by itself analyzing network packets, or it can receive this information from other sources in the network, e.g. from network routers or servers; and Col. 5, Line 29-35: The analysis engine 111 can analyze the activity log and compare it to user activity to determine if the user activity is anomalous, even if the user has presented the proper authenticating username and password or other credentials. If the analysis engine 111 detects anomalous user activity, the warning generator 113 can generate a warning to a system administrator 115).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Glenn and Raugus, further incorporating Bardenstein to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Bardenstein’s teaching to monitor data traffic of a plurality of various types of networks to gather anomalous activity data for threat detection and analysis into Glenn and Raugus’s method for monitoring network activity. This additional functionality would enrich the threat detection capabilities of the method by collecting threat information from various networks.
Regarding Claim 2:
Glenn, Raugus, and Bardenstein combine to teach the method according to claim 1.
Glenn further teaches wherein the external network is the Internet (Glenn – Paragraph [0042]: The method 200 of FIG. 2 comprises providing (e.g., with a premise gateway) communication between a premise network at a customer premises and an external network outside the customer premises (block 205). In an exemplary embodiment, the external network is an ISP network and/or the Internet).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 3:
Glenn, Raugus, and Bardenstein combine to teach the method according to claim 1.
Raugus further teaches further comprising identifying the at least one data packet for review based on threat information (Raugus – Paragraph [0027]: Network 105 may be monitored, thereby generating samples of network traffic 110 … the network traffic may include traffic flowing to or from a particular device on the network which may be executing malware. Network monitoring 135 may be configured to associate network samples on a particular subset of traffic associated with a particular suspect host or network device).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 6:
Glenn, Raugus, and Bardenstein combine to teach the method according to claim 1.
Raugus further teaches wherein the alert information related to the at least one data packet includes threat information (Raugus – Paragraph [0079]: In one or more embodiments, alert 460 may include the timestamp for the identification, the name of the file containing the triggering malware, or the name or IP address of the host containing the triggering malware, the SHA1 or other unique hash for the malware binary file, the alert, and the name of the type of alert that was triggered).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 7:
Glenn, Raugus, and Bardenstein combine to teach the method according to claim 1.
Raugus further teaches further comprising sending at least some of the second information (Raugus – Paragraph [0079]: System 400 may transmit an alert 460 to the user when the new analysis is available).
Bardenstein further teaches further comprising sending at least some of the second information to an electronic mail address associated with the local network (Bardenstein – Col. 5, Lines 33-42: anomalous activity detection can result in sending a warning to a system administrator through text message/email/immediate alert).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 8:
Glenn, Raugus, and Bardenstein combine to teach the method according to claim 1.
Raugus further teaches further comprising posting at least some of the second information to a customer portal associated with the local network (Raugus – Paragraph [0079]: System 400 may transmit an alert 460 to the user when the new analysis is available. In one or more embodiments, alert 460 may include the timestamp for the identification, the name of the file containing the triggering malware, or the name or IP address of the host containing the triggering malware, the SHA1 or other unique hash for the malware binary file, the alert, and the name of the type of alert that was triggered; and Paragraph [0084]: Communication interface 580 may include any transceiver-like mechanism that enables computing device 500 to communicate with other devices and/or systems, such as a client, a server, a license manager, a vendor, etc. For example, communication interface 580 may include one or more interfaces, such as a first interface coupled to a network and/or a second interface coupled to a license manager. Alternatively, communication interface 580 may include other mechanisms (e.g., a wireless interface) for communicating via a network, such as a wireless network. In one implementation, communication interface 580 may include logic to send code to a destination device, such as a target device; Examiner’s Comment: Communication interface 580 is interpreted to represent the customer portal, as it provides a means for a system (such as System 400) to communicate information to a customer via a network).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 9:
Glenn, Raugus, and Bardenstein combine to teach the method according to claim 1.
Glenn further teaches wherein the first information further includes media access control (MAC) address information (Glenn – Paragraph [0052]: In some cases, the malware detection device might send a notification to the ISP (e.g., via communication with the server, an e-mail message to the ISP, and/or the like) via the external network, so that the ISP can contact the customer to inform the customer of infection. Such notification to the ISP might include, without limitation, identification of the affected device, e.g., by MAC address, IP address, hostname, device type, and/or any other possible identification information that can be obtained by the malware detection device).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 11:
Glenn teaches a system for monitoring network activity, at an internet- service-provider server, the system comprising (Glenn – Paragraph [0008]: A set of embodiments, therefore, provides improved solutions for detecting and/or treating malware on a subscriber's premise network. Such solutions can include, but are not limited to, tools and techniques that can detect, and/or enable the detection of, malware infections on individual subscriber devices within the subscriber's network. In a particular embodiment, for example, a premise gateway, or other device on the subscriber's premise network, is configured to analyze packets traveling through the premise gateway and, based on that analysis, identify one or more subscriber devices that are infected with malware … in certain embodiments, the malware detection device (whether the premise gateway or another device on the premise network) can be operated and/or configured by the ISP): a memory configured to store instructions (Glenn – Paragraph [0011]: The tools provided by various embodiments include, without limitation, devices, methods, systems, and/or software products. Merely by way of example, a method might comprise one or more procedures, any or all of which are executed by a computer system or other device. Correspondingly, an embodiment might provide a computer system configured with instructions to perform one or more procedures in accordance with methods provided by various other embodiments and/or a device so configured. Similarly, a computer program might comprise a set of instructions that are executable by a computer system or other device (and/or a processor therein) to perform such operations. In many cases, such software programs are encoded on physical, tangible and/or non-transitory computer readable media (such as, to name but a few examples, optical media, magnetic media, and/or the like)); and at least one processor configured to execute the instructions and cause the at least one processor to (Glenn – Paragraph [0011]: The tools provided by various embodiments include, without limitation, devices, methods, systems, and/or software products. Merely by way of example, a method might comprise one or more procedures, any or all of which are executed by a computer system or other device. Correspondingly, an embodiment might provide a computer system configured with instructions to perform one or more procedures in accordance with methods provided by various other embodiments and/or a device so configured. Similarly, a computer program might comprise a set of instructions that are executable by a computer system or other device (and/or a processor therein) to perform such operations. In many cases, such software programs are encoded on physical, tangible and/or non-transitory computer readable media (such as, to name but a few examples, optical media, magnetic media, and/or the like)): monitor a plurality of data packets the plurality of data packets including data packets sent by a local network to an external network and data packets sent by the external network to the local network (Glenn – Paragraph [0008]: a premise gateway, or other device on the subscriber's premise network, is configured to analyze packets traveling through the premise gateway; and Paragraph [0012]: a method in accordance with one set of embodiments can be used to identify a malware infection. In an exemplary embodiment, the method comprises providing, with a premise gateway, communication between a premise network at a customer premises and an external network outside the customer premises; and Paragraph [0035]: FIG. 1A illustrates a system 100 that can be used to detect a malware infection at a subscriber premises. The system comprises a premise gateway 105, which as noted above, can include a broadband modem (e.g., xDSL modem, cable modem, etc.), wireless (and/or wired) router, wireless access point, and/or any other hardware or software that can provide network access for the customer premises (indicated by the broken lines on FIG. 1). In an embodiment, the premise gateway includes a first interface (internal) in communication with a premise network 110 and a second (external) interface in communication with an ISP network 115 (which can provide communication with, inter alia, the Internet, which is not shown on FIG. 1A). Such interfaces can be any suitable interface, and the interface with the ISP network 115 might be different than the interface with the premise network 110, as is known in the art); identify, from the plurality of data packets, at least one data packet for review based on the plurality of data packets [and the threat information] (Glenn – Paragraph [0030]: certain embodiments allow for a device within the ISP network to detect a malware infection at particular subscriber premises, e.g., based on comprehensive analysis of packets received from the premise gateway for that subscriber. This analysis, in some cases, can identify the type of malware with which the subscriber is infected; and Paragraph [0031]: In other embodiments, the ISP might tunnel traffic from the premise network to a location in the ISP's network (e.g., using GRE, MPLS, LT2P tunnels and/or other VPN/tunneling technologies familiar to the skilled person), to allow for more detailed analysis of the traffic to identify infected devices; and Paragraph [0040]: In some embodiments, the system 100 will include a server 130, which might be in the ISP network or elsewhere (e.g., on the Internet) and/or might be operated by the ISP. The server 130, in an aspect, can configure and/or control the operation of the malware detection device 125. Merely by way of example, in some cases, the server 130 (or another device in the ISP network, such as an edge router, etc.) might be configured to analyze network traffic received from the premise gateway 105. If a malware infection is detected and/or the malware is specifically identified, the server 130 might be configured to activate the malware detection device 125 to begin detecting malware in the premise network 110. Alternatively and/or additionally, the server 130 might configure the malware detection device 105 by sending appropriate malware signatures and/or heuristic algorithms to the malware detection device 105 to assist in the detection of the identified malware in the premise network 110. In other cases, the server 130 might configure the malware detection device 125 and/or the premise gateway 105 to cause those device(s) to take specific actions, as described elsewhere herein, in response to the detection of malware at one of the devices 120 on the premise network 110); determine Internet Protocol (IP) address information associated with the at least one data packet (Glenn – Paragraph [0028]: Based on the analysis of the traffic (e.g., IP packets), the malware detection device can identify one or more subscriber devices (e.g., by IP address, MAC address, etc.) that are infected with malware); receive first information from a first device connected to the local network, the first information including at least a device name associated with the IP address information (Glenn – Paragraph [0052]: In some cases, the malware detection device might send a notification to the ISP (e.g., via communication with the server, an e-mail message to the ISP, and/or the like) via the external network, so that the ISP can contact the customer to inform the customer of infection. Such notification to the ISP might include, without limitation, identification of the affected device, e.g., by MAC address, IP address, hostname, device type, and/or any other possible identification information that can be obtained by the malware detection device).
Glenn does not expressly teach generate second information that includes at least the device name and alert information related to the at least one data packet, wherein the alert information describes a suspicious activity of a device associated with the IP address information; and send the second information to at least one device.
However, Raugus teaches generate second information that includes at least the device name and alert information related to the at least one data packet (Raugus – Paragraph [0022]: The systems, methods, media, or computer based products for malware detection discussed herein may ingest samples of network traffic passing to and/or from each computing resource selected for monitoring. For example, a span port located inside an Internet Service Provider's (ISP) network point-of-presence (POP) would permit monitoring of many computing resources simultaneously; and Paragraphs [0029-0064]: Multiple Feature sets derived from packet analysis for detecting malware; and Paragraph [0079]: In system 400, alert 460 may be generated to inform users when the results of new analyses are available … alert 460 may include the timestamp for the identification, the name of the file containing the triggering malware, or the name or IP address of the host containing the triggering malware, the SHA1 or other unique hash for the malware binary file, the alert, and the name of the type of alert that was triggered), wherein the alert information describes a suspicious activity of a device (Raugus – Paragraph [0022]: Using one or more methods of feature extraction, the network samples may be prepared for scoring. Subsequently, a specific machine learning algorithm may use models trained a priori against specific and/or known classes of malware to compute rankable scores (for a given time window). The scores may indicate whether particular hosts or network devices exhibit network behavior most similar to a particular class of malware; and Paragraph [0067]: At least one machine learning model 125 is applied to the features 145, thereby generating score 130, wherein the score indicates the likelihood of malware being present in a host or network device in network 105. The machine learning model 125 may be trained prior to applying the machine learning model to the extracted features. The training may include at least one of the following: scoring network traffic based on similarity to malicious behavior by software executing on a network-connected host system; and Paragraph [0079]: In system 400, alert 460 may be generated to inform users when the results of new analyses are available. For example, a user may a priori have indicated the user's desire to receive notice of the suspected presence of a particular instance, type, or class of malware … alert 460 may include the timestamp for the identification, the name of the file containing the triggering malware, or the name or IP address of the host containing the triggering malware, the SHA1 or other unique hash for the malware binary file, the alert, and the name of the type of alert that was triggered. In one or more embodiments, a URL may also be provided to the user who may be used to view any meta-data or report information generated for the sample) associated with the IP address information (Raugus – Paragraph [0079]: alert 460 may include the timestamp for the identification, the name of the file containing the triggering malware, or the name or IP address of the host containing the triggering malware, the SHA1 or other unique hash for the malware binary file, the alert, and the name of the type of alert that was triggered. In one or more embodiments, a URL may also be provided to the user who may be used to view any meta-data or report information generated for the sample); and send the second information to at least one device (Raugus – Paragraph [0079]: System 400 may transmit an alert 460 to the user when the new analysis is available).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Glenn, further incorporating Raugus to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Raugus’s teaching to generate and send an alert regarding a potentially compromised device in a system into Glenn’s system for monitoring network activity. This combined functionality would add practicality to Glenn’s monitoring system by generating actionable notifications of potential malicious activity.
The combination of Glenn and Raugus does not expressly teach monitor data exchange of other local networks to determine threat information; identify, from the plurality of data packets, at least one data packet for review based on an association between the at least one data packet and the threat information.
However, Bardenstein teaches monitor data exchange of other local networks to determine threat information (Bardenstein – Col. 4, Lines 41-44: The network 105 can be any type of network. For example, it can be a virtual private network (VPN), the internet, an intranet, an internal network, corporate network, local area network (LAN), wireless network, etc.; and Col. 6, Line 20-24: The analysis engine may receive network activity data 202[a-d] from one or more different networks (e.g., through network 105). For example, multiple networks may each be monitored, and the collected network activity data from each network received by the analysis engine); identify from the plurality of data packets, at least one data packet for review based on an association between the at least one data packet and the threat information (Bardenstein – Col. 5, Line 49-58: Even though FIG. 1 illustrates anomaly detection system 101 as being associated with one network 105, in some embodiments, an anomaly detection system 101 may be connected to multiple networks. For example, the anomaly detection system 101 may receive logged network activity data from a plurality of different monitored networks to be stored in activity log 109. In some embodiments, the larger amount of available data from multiple networks may allow for better detection of anomalous activity and more accurate attribution of the activity to various actors and groups; and Col. 6, Line 50-54: The collected network activity data from the network activity log is analyzed by an anomaly detection model 208 in order to detect and identify anomalous activity; and Col. 7, Line 39-45: In some embodiments, the profiling model 210 may extract one or more features from the session data associated with the anomalous activity. These features may include source/destination IP addresses, source/destination ports, MAC addresses, user agent strings, URLs accessed, time of activity, commands used, filenames created, and/or the like; and Col. 5, Line 11-16: The anomaly detection system 101 logs user activity in an activity log 109. The anomaly detection system can obtain this information on its own, e.g., by itself analyzing network packets, or it can receive this information from other sources in the network, e.g. from network routers or servers; and Col. 5, Line 29-35: The analysis engine 111 can analyze the activity log and compare it to user activity to determine if the user activity is anomalous, even if the user has presented the proper authenticating username and password or other credentials. If the analysis engine 111 detects anomalous user activity, the warning generator 113 can generate a warning to a system administrator 115).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Glenn and Raugus, further incorporating Bardenstein to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Bardenstein’s teaching to monitor data traffic of a plurality of various types of networks to gather anomalous activity data for threat detection and analysis into Glenn and Raugus’s system for monitoring network activity. This additional functionality would enrich the threat detection capabilities of the system by collecting threat information from various networks.
Regarding Claim 12:
Glenn, Raugus, and Bardenstein combine to teach the system according to claim 11.
Glenn further teaches wherein the external network is the Internet (Glenn – Paragraph [0042]: The method 200 of FIG. 2 comprises providing (e.g., with a premise gateway) communication between a premise network at a customer premises and an external network outside the customer premises (block 205). In an exemplary embodiment, the external network is an ISP network and/or the Internet).
The motivation to combine the arts is the same as that of Claim 11.
Regarding Claim 13:
Glenn, Raugus, and Bardenstein combine to teach the system according to claim 11.
Glenn further teaches wherein the at least one processor is further configured to execute the instructions and cause the at least one processor to (Glenn – Paragraph [0011]: The tools provided by various embodiments include, without limitation, devices, methods, systems, and/or software products. Merely by way of example, a method might comprise one or more procedures, any or all of which are executed by a computer system or other device. Correspondingly, an embodiment might provide a computer system configured with instructions to perform one or more procedures in accordance with methods provided by various other embodiments and/or a device so configured. Similarly, a computer program might comprise a set of instructions that are executable by a computer system or other device (and/or a processor therein) to perform such operations. In many cases, such software programs are encoded on physical, tangible and/or non-transitory computer readable media (such as, to name but a few examples, optical media, magnetic media, and/or the like)).
Raugus further teaches identify the at least one data packet for review based on threat information (Raugus – Paragraph [0027]: Network 105 may be monitored, thereby generating samples of network traffic 110 … the network traffic may include traffic flowing to or from a particular device on the network which may be executing malware. Network monitoring 135 may be configured to associate network samples on a particular subset of traffic associated with a particular suspect host or network device).
The motivation to combine the arts is the same as that of Claim 11.
Regarding Claim 16:
Glenn, Raugus, and Bardenstein combine to teach the system according to claim 11.
Raugus further teaches wherein the alert information related to the at least one data packet includes threat information (Raugus – Paragraph [0079]: In one or more embodiments, alert 460 may include the timestamp for the identification, the name of the file containing the triggering malware, or the name or IP address of the host containing the triggering malware, the SHA1 or other unique hash for the malware binary file, the alert, and the name of the type of alert that was triggered).
The motivation to combine the arts is the same as that of Claim 11.
Regarding Claim 17:
Glenn, Raugus, and Bardenstein combine to teach the system according to claim 11.
Glenn further teaches wherein the at least one processor is further configured to execute the instructions and cause the at least one processor to (Glenn – Paragraph [0011]: The tools provided by various embodiments include, without limitation, devices, methods, systems, and/or software products. Merely by way of example, a method might comprise one or more procedures, any or all of which are executed by a computer system or other device. Correspondingly, an embodiment might provide a computer system configured with instructions to perform one or more procedures in accordance with methods provided by various other embodiments and/or a device so configured. Similarly, a computer program might comprise a set of instructions that are executable by a computer system or other device (and/or a processor therein) to perform such operations. In many cases, such software programs are encoded on physical, tangible and/or non-transitory computer readable media (such as, to name but a few examples, optical media, magnetic media, and/or the like)).
Raugus further teaches send at least some of the second information (Raugus – Paragraph [0079]: System 400 may transmit an alert 460 to the user when the new analysis is available).
Bardenstein further teaches send at least some of the second information to an electronic mail address associated with the local network (Bardenstein – Col. 5, Lines 33-42: anomalous activity detection can result in sending a warning to a system administrator through text message/email/immediate alert).
The motivation to combine the arts is the same as that of Claim 11.
Regarding Claim 18:
Glenn, Raugus, and Bardenstein combine to teach the system according to claim 11.
Glenn further teaches wherein the at least one processor is further configured to execute the instructions and cause the at least one processor to (Glenn – Paragraph [0011]: The tools provided by various embodiments include, without limitation, devices, methods, systems, and/or software products. Merely by way of example, a method might comprise one or more procedures, any or all of which are executed by a computer system or other device. Correspondingly, an embodiment might provide a computer system configured with instructions to perform one or more procedures in accordance with methods provided by various other embodiments and/or a device so configured. Similarly, a computer program might comprise a set of instructions that are executable by a computer system or other device (and/or a processor therein) to perform such operations. In many cases, such software programs are encoded on physical, tangible and/or non-transitory computer readable media (such as, to name but a few examples, optical media, magnetic media, and/or the like)).
Raugus further teaches post at least some of the second information to a customer portal associated with the local network (Raugus – Paragraph [0079]: System 400 may transmit an alert 460 to the user when the new analysis is available. In one or more embodiments, alert 460 may include the timestamp for the identification, the name of the file containing the triggering malware, or the name or IP address of the host containing the triggering malware, the SHA1 or other unique hash for the malware binary file, the alert, and the name of the type of alert that was triggered; and Paragraph [0084]: Communication interface 580 may include any transceiver-like mechanism that enables computing device 500 to communicate with other devices and/or systems, such as a client, a server, a license manager, a vendor, etc. For example, communication interface 580 may include one or more interfaces, such as a first interface coupled to a network and/or a second interface coupled to a license manager. Alternatively, communication interface 580 may include other mechanisms (e.g., a wireless interface) for communicating via a network, such as a wireless network. In one implementation, communication interface 580 may include logic to send code to a destination device, such as a target device; Examiner’s Comment: Communication interface 580 is interpreted to represent the customer portal, as it provides a means for a system (such as System 400) to communicate information to a customer via a network).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 19:
Glenn, Raugus, and Bardenstein combine to teach the system according to claim 11.
Glenn further teaches wherein the first information further includes media access control (MAC) address information (Glenn – Paragraph [0052]: In some cases, the malware detection device might send a notification to the ISP (e.g., via communication with the server, an e-mail message to the ISP, and/or the like) via the external network, so that the ISP can contact the customer to inform the customer of infection. Such notification to the ISP might include, without limitation, identification of the affected device, e.g., by MAC address, IP address, hostname, device type, and/or any other possible identification information that can be obtained by the malware detection device).
The motivation to combine the arts is the same as that of Claim 11.
Regarding Claim 21:
Glenn teaches a non-transitory computer-readable storage medium having stored thereon instructions that, when executed by at least one processor, cause the at least one processor to (Glenn – Paragraph [0061]: The computer system 400 also may comprise software elements, shown as being currently located within the working memory 435, including an operating system 440, device drivers, executable libraries, and/or other code, such as one or more application programs 445, which may comprise computer programs provided by various embodiments, and/or may be designed to implement methods, and/or configure systems, provided by other embodiments, as described herein. Merely by way of example, one or more procedures described with respect to the method(s) discussed above might be implemented as code and/or instructions executable by a computer (and/or a processor within a computer); in an aspect, then, such code and/or instructions can be used to configure and/or adapt a general purpose computer (or other device) to perform one or more operations in accordance with the described methods.; and Paragraph [0062]: A set of these instructions and/or code might be encoded and/or stored on a non-transitory computer readable storage medium, such as the storage device(s) 425 described above. In some cases, the storage medium might be incorporated within a computer system, such as the system 400): monitor, at an internet-service-provider (ISP) server, a plurality of data packets (Glenn – Paragraph [0008]: a premise gateway, or other device on the subscriber's premise network, is configured to analyze packets traveling through the premise gateway … in certain embodiments, the malware detection device (whether the premise gateway or another device on the premise network) can be operated and/or configured by the ISP), the plurality of data packets including data packets sent by a local network to an external network and data packets sent by the external network to the local network (Glenn – Paragraph [0008]: a premise gateway, or other device on the subscriber's premise network, is configured to analyze packets traveling through the premise gateway; and Paragraph [0012]: a method in accordance with one set of embodiments can be used to identify a malware infection. In an exemplary embodiment, the method comprises providing, with a premise gateway, communication between a premise network at a customer premises and an external network outside the customer premises; and Paragraph [0035]: FIG. 1A illustrates a system 100 that can be used to detect a malware infection at a subscriber premises. The system comprises a premise gateway 105, which as noted above, can include a broadband modem (e.g., xDSL modem, cable modem, etc.), wireless (and/or wired) router, wireless access point, and/or any other hardware or software that can provide network access for the customer premises (indicated by the broken lines on FIG. 1). In an embodiment, the premise gateway includes a first interface (internal) in communication with a premise network 110 and a second (external) interface in communication with an ISP network 115 (which can provide communication with, inter alia, the Internet, which is not shown on FIG. 1A). Such interfaces can be any suitable interface, and the interface with the ISP network 115 might be different than the interface with the premise network 110, as is known in the art); identify, at the ISP server, at least one data packet for review from among the plurality of data packets based on the plurality of data packets [and the threat information] (Glenn – Paragraph [0030]: certain embodiments allow for a device within the ISP network to detect a malware infection at particular subscriber premises, e.g., based on comprehensive analysis of packets received from the premise gateway for that subscriber. This analysis, in some cases, can identify the type of malware with which the subscriber is infected; and Paragraph [0031]: In other embodiments, the ISP might tunnel traffic from the premise network to a location in the ISP's network (e.g., using GRE, MPLS, LT2P tunnels and/or other VPN/tunneling technologies familiar to the skilled person), to allow for more detailed analysis of the traffic to identify infected devices; and Paragraph [0040]: In some embodiments, the system 100 will include a server 130, which might be in the ISP network or elsewhere (e.g., on the Internet) and/or might be operated by the ISP. The server 130, in an aspect, can configure and/or control the operation of the malware detection device 125. Merely by way of example, in some cases, the server 130 (or another device in the ISP network, such as an edge router, etc.) might be configured to analyze network traffic received from the premise gateway 105. If a malware infection is detected and/or the malware is specifically identified, the server 130 might be configured to activate the malware detection device 125 to begin detecting malware in the premise network 110. Alternatively and/or additionally, the server 130 might configure the malware detection device 105 by sending appropriate malware signatures and/or heuristic algorithms to the malware detection device 105 to assist in the detection of the identified malware in the premise network 110. In other cases, the server 130 might configure the malware detection device 125 and/or the premise gateway 105 to cause those device(s) to take specific actions, as described elsewhere herein, in response to the detection of malware at one of the devices 120 on the premise network 110); determine, at the ISP server, Internet Protocol (IP) address information associated with the at least one data packet (Glenn – Paragraph [0028]: Based on the analysis of the traffic (e.g., IP packets), the malware detection device can identify one or more subscriber devices (e.g., by IP address, MAC address, etc.) that are infected with malware); receive, at the ISP server, first information from a first device connected to the local network, the first information including at least a device name associated with the IP address information (Glenn – Paragraph [0052]: In some cases, the malware detection device might send a notification to the ISP (e.g., via communication with the server, an e-mail message to the ISP, and/or the like) via the external network, so that the ISP can contact the customer to inform the customer of infection. Such notification to the ISP might include, without limitation, identification of the affected device, e.g., by MAC address, IP address, hostname, device type, and/or any other possible identification information that can be obtained by the malware detection device).
Glenn does not expressly teach generate, at the ISP server, second information that includes at least the device name and alert information related to the at least one data packet, wherein the alert information describes a possibly-compromised status of a device associated with the IP address information and suspicious activity of the device associated with the IP address information; and sending, from the ISP server to at least one device, the second information.
However, Raugus teaches generate, at the ISP server, second information that includes at least the device name and alert information related to the at least one data packet (Raugus – Paragraph [0022]: The systems, methods, media, or computer based products for malware detection discussed herein may ingest samples of network traffic passing to and/or from each computing resource selected for monitoring. For example, a span port located inside an Internet Service Provider's (ISP) network point-of-presence (POP) would permit monitoring of many computing resources simultaneously; and Paragraphs [0029-0064]: Multiple Feature sets derived from packet analysis for detecting malware; and Paragraph [0079]: In system 400, alert 460 may be generated to inform users when the results of new analyses are available … alert 460 may include the timestamp for the identification, the name of the file containing the triggering malware, or the name or IP address of the host containing the triggering malware, the SHA1 or other unique hash for the malware binary file, the alert, and the name of the type of alert that was triggered), wherein the alert information describes a possibly-compromised status of a device associated with the IP address information and suspicious activity of the device (Raugus – Paragraph [0022]: Using one or more methods of feature extraction, the network samples may be prepared for scoring. Subsequently, a specific machine learning algorithm may use models trained a priori against specific and/or known classes of malware to compute rankable scores (for a given time window). The scores may indicate whether particular hosts or network devices exhibit network behavior most similar to a particular class of malware; and Paragraph [0067]: At least one machine learning model 125 is applied to the features 145, thereby generating score 130, wherein the score indicates the likelihood of malware being present in a host or network device in network 105. The machine learning model 125 may be trained prior to applying the machine learning model to the extracted features. The training may include at least one of the following: scoring network traffic based on similarity to malicious behavior by software executing on a network-connected host system; and Paragraph [0077]: The generated score 440 may provide a relative measure of the likelihood of malware presence on each computing system; and Paragraph [0078]: at decision 450, the model 420 may have an associated threshold, t, 430, such that a score depicted in block 440 greater than t may indicate the likelihood that a particular computing resource 106 and 107 in computer network depicted in block 105 in system 100 has a malicious software program and/or more specifically has a malicious software program of a specific class; and Paragraph [0079]: In system 400, alert 460 may be generated to inform users when the results of new analyses are available. For example, a user may a priori have indicated the user's desire to receive notice of the suspected presence of a particular instance, type, or class of malware … alert 460 may include the timestamp for the identification, the name of the file containing the triggering malware, or the name or IP address of the host containing the triggering malware, the SHA1 or other unique hash for the malware binary file, the alert, and the name of the type of alert that was triggered. In one or more embodiments, a URL may also be provided to the user who may be used to view any meta-data or report information generated for the sample) associated with the IP address information (Raugus – Paragraph [0079]: alert 460 may include the timestamp for the identification, the name of the file containing the triggering malware, or the name or IP address of the host containing the triggering malware, the SHA1 or other unique hash for the malware binary file, the alert, and the name of the type of alert that was triggered. In one or more embodiments, a URL may also be provided to the user who may be used to view any meta-data or report information generated for the sample); and send, from the ISP server to at least one device, the second information (Raugus – Paragraph [0079]: System 400 may transmit an alert 460 to the user when the new analysis is available).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Glenn, further incorporating Raugus to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Raugus’s teaching to generate and send an alert regarding a potentially compromised device in a system into Glenn’s method for monitoring network activity. This combined functionality would add practicality to Glenn’s monitoring system by generating actionable notifications of potential malicious activity.
The combination of Glenn and Raugus does not expressly teach monitor, at the ISP server, data exchange of other local networks to determine threat information; identify, at the ISP server, at least one data packet for review from among the plurality of data packets based on an association between the at least one data packet and the threat information.
However, Bardenstein teaches monitor[, at the ISP server,] data exchange of other local networks to determine threat information (Bardenstein – Col. 4, Lines 41-44: The network 105 can be any type of network. For example, it can be a virtual private network (VPN), the internet, an intranet, an internal network, corporate network, local area network (LAN), wireless network, etc.; and Col. 6, Line 20-24: The analysis engine may receive network activity data 202[a-d] from one or more different networks (e.g., through network 105). For example, multiple networks may each be monitored, and the collected network activity data from each network received by the analysis engine); identify[, at the ISP server,] at least one data packet for review from among the plurality of data packets based on an association between the at least one data packet and the threat information (Bardenstein – Col. 5, Line 49-58: Even though FIG. 1 illustrates anomaly detection system 101 as being associated with one network 105, in some embodiments, an anomaly detection system 101 may be connected to multiple networks. For example, the anomaly detection system 101 may receive logged network activity data from a plurality of different monitored networks to be stored in activity log 109. In some embodiments, the larger amount of available data from multiple networks may allow for better detection of anomalous activity and more accurate attribution of the activity to various actors and groups; and Col. 6, Line 50-54: The collected network activity data from the network activity log is analyzed by an anomaly detection model 208 in order to detect and identify anomalous activity; and Col. 7, Line 39-45: In some embodiments, the profiling model 210 may extract one or more features from the session data associated with the anomalous activity. These features may include source/destination IP addresses, source/destination ports, MAC addresses, user agent strings, URLs accessed, time of activity, commands used, filenames created, and/or the like).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Glenn and Raugus, further incorporating Bardenstein to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Bardenstein’s teaching to monitor data traffic of a plurality of various types of networks to gather anomalous activity data for threat detection and analysis into Glenn and Raugus’s system for monitoring network activity. This additional functionality would enrich the threat detection capabilities of the system by collecting threat information from various networks.
Regarding Claim 22:
Glenn, Raugus, and Bardenstein combine to teach the method of claim 1.
Glenn further teaches wherein receiving, at the ISP server, the first information from the first device comprises, based on identifying the at least one data packet for review, collecting the first information from the first device (Glenn – Paragraph [0047]: At block 225, the malware detection device identifies one or more infected devices on the premise network. This identification, in an embodiment, is based on the analysis of the network traffic. Merely by way of example, if the malware detection device identifies (either through signature comparison, heuristic application, and/or some other technique) one or more IP packets as indicating a malware infection, the malware identification device can identify the source address for those packets; and Paragraph [0052]: In some cases, the malware detection device might send a notification to the ISP (e.g., via communication with the server, an e-mail message to the ISP, and/or the like) via the external network, so that the ISP can contact the customer to inform the customer of infection. Such notification to the ISP might include, without limitation, identification of the affected device, e.g., by MAC address, IP address, hostname, device type, and/or any other possible identification information that can be obtained by the malware detection device).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 23:
Glenn, Raugus, and Bardenstein combine to teach the method of claim 1.
Glenn further teaches wherein receiving, at the ISP server, the first information from the first device comprises, based on identifying the at least one data packet for review, periodically polling the first device to collect the first information from the first device (Glenn – Paragraph [0047]: At block 225, the malware detection device identifies one or more infected devices on the premise network. This identification, in an embodiment, is based on the analysis of the network traffic. Merely by way of example, if the malware detection device identifies (either through signature comparison, heuristic application, and/or some other technique) one or more IP packets as indicating a malware infection, the malware identification device can identify the source address for those packets. This source address can provide a network identifier (e.g., an IP address, a media access control ("MAC") address, etc.) of the device that generated the packets, and this device can be identified as being infected with malware; and Paragraph [0048]: At block 230, the method 200 comprises taking one or more actions to notify the customer of the identification of the device(s) that is/are infected with malware; and Paragraph [0052]: In some cases, the malware detection device might send a notification to the ISP (e.g., via communication with the server, an e-mail message to the ISP, and/or the like) via the external network, so that the ISP can contact the customer to inform the customer of infection. Such notification to the ISP might include, without limitation, identification of the affected device, e.g., by MAC address, IP address, hostname, device type, and/or any other possible identification information that can be obtained by the malware detection device; Examiner’s Comment: Paragraph [0041] of the instant specification describes periodic collection of information by the ISP occurring in response to a “trigger event”. Therefore, the collection of device information upon identification of one or more infected devices is interpreted to represent the claimed periodic polling for the information).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 26:
Glenn, Raugus, and Bardenstein combine to teach the method of claim 1.
Raugus further teaches wherein: the threat information relates to a denial-of-service attack (Raugus – Paragraph [0027]: Network 105 may be monitored, thereby generating samples of network traffic 110; and Paragraph [0028]: Features 120 may be extracted from the sampled network traffic in block 140; and Paragraph [0037]-[0038]: Feature Set E: Time Series Formed by Sizes of IP Packets … This feature may be intended in part to detect "amplification" denial of service (DoS) attacks, in which a sequence of small request packets engender significantly larger packets in response; and Paragraph [0043]-[0044]: Feature Set H: Packets Per Unit Time … This feature is intended in part to detect DoS attacks); the at least one data packet is identified for review based on the at least one data packet being associated with the denial-of-service attack (Raugus – Paragraph [0027]: Network 105 may be monitored, thereby generating samples of network traffic 110; and Paragraph [0028]: Features 120 may be extracted from the sampled network traffic in block 140; and Paragraph [0037]-[0038]: Feature Set E: Time Series Formed by Sizes of IP Packets … This feature may be intended in part to detect "amplification" denial of service (DoS) attacks, in which a sequence of small request packets engender significantly larger packets in response; and Paragraph [0043]-[0044]: Feature Set H: Packets Per Unit Time … This feature is intended in part to detect DoS attacks); and the alert information describes the denial-of-service attack (Raugus – Paragraph [0079]: alert 460 may include the timestamp for the identification, the name of the file containing the triggering malware, or the name or IP address of the host containing the triggering malware, the SHA1 or other unique hash for the malware binary file, the alert, and the name of the type of alert that was triggered. In one or more embodiments, a URL may also be provided to the user who may be used to view any meta-data or report information generated for the sample).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 27:
Glenn, Raugus, and Bardenstein combine to teach the method of claim 1.
Raugus further teaches wherein the alert information describes suspicious activity of the device (Raugus – Paragraph [0022]: Using one or more methods of feature extraction, the network samples may be prepared for scoring. Subsequently, a specific machine learning algorithm may use models trained a priori against specific and/or known classes of malware to compute rankable scores (for a given time window). The scores may indicate whether particular hosts or network devices exhibit network behavior most similar to a particular class of malware; and Paragraph [0067]: At least one machine learning model 125 is applied to the features 145, thereby generating score 130, wherein the score indicates the likelihood of malware being present in a host or network device in network 105. The machine learning model 125 may be trained prior to applying the machine learning model to the extracted features. The training may include at least one of the following: scoring network traffic based on similarity to malicious behavior by software executing on a network-connected host system; and Paragraph [0079]: In system 400, alert 460 may be generated to inform users when the results of new analyses are available. For example, a user may a priori have indicated the user's desire to receive notice of the suspected presence of a particular instance, type, or class of malware … alert 460 may include the timestamp for the identification, the name of the file containing the triggering malware, or the name or IP address of the host containing the triggering malware, the SHA1 or other unique hash for the malware binary file, the alert, and the name of the type of alert that was triggered. In one or more embodiments, a URL may also be provided to the user who may be used to view any meta-data or report information generated for the sample) associated with the IP address information (Raugus – Paragraph [0079]: alert 460 may include the timestamp for the identification, the name of the file containing the triggering malware, or the name or IP address of the host containing the triggering malware, the SHA1 or other unique hash for the malware binary file, the alert, and the name of the type of alert that was triggered. In one or more embodiments, a URL may also be provided to the user who may be used to view any meta-data or report information generated for the sample).
The motivation to combine the arts is the same as that of Claim 1.
Claims 4, 5, 14, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Glenn, in view of Raugus, Bardenstein, and Jiang et al. (US 20100103941 A1), hereinafter Jiang.
Regarding Claim 4:
Glenn, Raugus, and Bardenstein combine to teach the method according to claim 1.
The combination of Glenn and Raugus does not expressly teach further comprising receiving the first information according to the Device Data Model for TR-069.
However, Jiang teaches further comprising receiving the first information according to the Device Data Model for TR-069 (Jiang – Paragraph [0039]: CPE devices present data for collection in a stand data model entitled "Internet Gateway Device Data Model for TR-069").
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Glenn and Raugus, further incorporating Jiang to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Jiang’s implementation of the Device Data Model for TR-069 to collect data from CPE devices into Glenn and Raugus’s method for network monitoring and alert generation. This combination would result in having a standard model for data collection from devices in a customer network, which would help to facilitate data analysis with enhanced clarity and consistency.
Regarding Claim 5:
Glenn, Raugus, and Bardenstein combine to teach the method according to claim 1.
The combination of Glenn and Raugus does not expressly teach further comprising using the Customer Provided Equipment (CPE) Wide Area Network (WAN) management protocol to receive the first information.
However, Jiang teaches further comprising using the Customer Provided Equipment (CPE) Wide Area Network (WAN) management protocol to receive the first information (Jiang – Paragraph [0003]: "CPE WAN Management Protocol" described in TR-069; and Paragraph [0039]: CPE devices present data for collection in a standard data model entitled "Internet Gateway Device Data Model for TR-069").
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Glenn and Raugus, further incorporating Jiang to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Jiang’s use of the Customer Provided Equipment (CPE) Wide Area Network (WAN) management protocol to collect data from CPE devices into Glenn and Raugus’s method for network monitoring and alert generation. This combination would result in having a standard model for data collection from devices in a customer network, which would help to facilitate data analysis with enhanced clarity and consistency.
Regarding Claim 14:
Glenn, Raugus, and Bardenstein combine to teach the system according to claim 11.
Glenn further teaches wherein the at least one processor is further configured to execute the instructions and cause the at least one processor to (Glenn – Paragraph [0011]: The tools provided by various embodiments include, without limitation, devices, methods, systems, and/or software products. Merely by way of example, a method might comprise one or more procedures, any or all of which are executed by a computer system or other device. Correspondingly, an embodiment might provide a computer system configured with instructions to perform one or more procedures in accordance with methods provided by various other embodiments and/or a device so configured. Similarly, a computer program might comprise a set of instructions that are executable by a computer system or other device (and/or a processor therein) to perform such operations. In many cases, such software programs are encoded on physical, tangible and/or non-transitory computer readable media (such as, to name but a few examples, optical media, magnetic media, and/or the like)).
The combination of Glenn and Raugus does not expressly teach further comprising receiving the first information according to the Device Data Model for TR-069.
However, Jiang teaches receive the first information according to the Device Data Model for TR-069 (Jiang – Paragraph [0039]: CPE devices present data for collection in a stand data model entitled "Internet Gateway Device Data Model for TR-069").
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Glenn and Raugus, further incorporating Jiang to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Jiang’s implementation of the Device Data Model for TR-069 to collect data from CPE devices into Glenn and Raugus’s system for network monitoring and alert generation. This combination would result in having a standard model for data collection from devices in a customer network, which would help to facilitate data analysis with enhanced clarity and consistency.
Regarding Claim 15:
Glenn, Raugus, and Bardenstein combine to teach the system according to claim 11.
Glenn further teaches wherein the at least one processor is further configured to execute the instructions and cause the at least one processor to (Glenn – Paragraph [0011]: The tools provided by various embodiments include, without limitation, devices, methods, systems, and/or software products. Merely by way of example, a method might comprise one or more procedures, any or all of which are executed by a computer system or other device. Correspondingly, an embodiment might provide a computer system configured with instructions to perform one or more procedures in accordance with methods provided by various other embodiments and/or a device so configured. Similarly, a computer program might comprise a set of instructions that are executable by a computer system or other device (and/or a processor therein) to perform such operations. In many cases, such software programs are encoded on physical, tangible and/or non-transitory computer readable media (such as, to name but a few examples, optical media, magnetic media, and/or the like)).
The combination of Glenn and Raugus does not expressly teach use the Customer Provided Equipment (CPE) Wide Area Network (WAN) management protocol to receive the first information.
However, Jiang teaches use the Customer Provided Equipment (CPE) Wide Area Network (WAN) management protocol to receive the first information (Jiang – Paragraph [0003]: "CPE WAN Management Protocol" described in TR-069; and Paragraph [0039]: CPE devices present data for collection in a standard data model entitled "Internet Gateway Device Data Model for TR-069").
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Glenn and Raugus, further incorporating Jiang to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Jiang’s use of the Customer Provided Equipment (CPE) Wide Area Network (WAN) management protocol to collect data from CPE devices into Glenn and Raugus’s system for network monitoring and alert generation. This combination would result in having a standard model for data collection from devices in a customer network, which would help to facilitate data analysis with enhanced clarity and consistency.
Claim 24 is rejected under 35 U.S.C. 103 as being unpatentable over Glenn, in view of Raugus, Bardenstein, and McNamee et al. (US 20100154059 A1), hereinafter McNamee.
Regarding Claim 24:
Glenn, Raugus, and Bardenstein combine to teach the method of claim 1.
The combination of Glenn, Raugus, and Bardenstein does not expressly teach wherein: the threat information relates to a computer virus; the at least one data packet is identified for review based on the at least one data packet being associated with the computer virus; and the alert information describes the computer virus.
However, McNamee teaches wherein: the threat information relates to a computer virus (McNamee – Paragraph [0003]: Malware infection is a major problem for users of Internet connected network devices, … Malware comes in a number of forms such as, for example, virus, worm, spyware, adware, Trojan, bot, root-kit, and other similar forms of malware; and Paragraph [0026]: The network sensor 204 comprises a detection engine 210 that analyzes the received packets using signature based matching … The signatures specify the characteristics that the malware network traffic will have. This includes data patterns that may be present in network packets, state information associated with the network protocols, and sequences of events that may be considered anomalous network behaviour. These signatures are expressed as detection engine rules. When the detection engine 210 detects a packet or sequence of packets that matches a specific rule it generates an alert event using the alert generation module 214. The detection engine rule includes a signature for detecting malware in the network traffic as well as an action to take when the rule is matched); the at least one data packet is identified for review based on the at least one data packet being associated with the computer virus (McNamee – Paragraph [0003]: Malware infection is a major problem for users of Internet connected network devices, … Malware comes in a number of forms such as, for example, virus, worm, spyware, adware, Trojan, bot, root-kit, and other similar forms of malware; and Paragraph [0026]: The network sensor 204 comprises a detection engine 210 that analyzes the received packets using signature based matching … The signatures specify the characteristics that the malware network traffic will have. This includes data patterns that may be present in network packets, state information associated with the network protocols, and sequences of events that may be considered anomalous network behaviour. These signatures are expressed as detection engine rules. When the detection engine 210 detects a packet or sequence of packets that matches a specific rule it generates an alert event using the alert generation module 214. The detection engine rule includes a signature for detecting malware in the network traffic as well as an action to take when the rule is matched); and the alert information describes the computer virus (McNamee – Paragraph [0003]: Malware infection is a major problem for users of Internet connected network devices, … Malware comes in a number of forms such as, for example, virus, worm, spyware, adware, Trojan, bot, root-kit, and other similar forms of malware; and Paragraph [0040]:The reporting infrastructure 208 may further comprise a subscriber notification generator 226. The subscriber notification generator 226 generates a notification to a subscriber once the subscriber's summary alerts have passed a threshold value; and Paragraph [0041]: When the notification is generated, additional information associated with the signature ID of the alert, or alerts, the notification is being generated for may be retrieved. This additional information may be associated with a signature ID for the various malware signatures. The additional information may include, for example, a name of the malware, the type of malware associated with the signature ID, the severity of the malware or malware type).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Glenn, Raugus, and Bardenstein, further incorporating McNamee to arrive at the conclusion of the claimed invention. One would be motivated to incorporate McNamee’s teaching to monitor data traffic for activity related to or indicative of computer viruses and provide alert describing the virus(es) into Glenn, Raugus, and Bardenstein’s system for monitoring network activity. This addition would enhance the system by providing a capability to target specific types of malicious activity during packet analysis.
Claim 25 is rejected under 35 U.S.C. 103 as being unpatentable over Glenn, in view of Raugus, Bardenstein, Alhawi et al. (Alhawi, O. M., Baldwin, J., & Dehghantanha, A. (2018). Leveraging machine learning techniques for windows ransomware network traffic detection. Advances in Information Security, 93–106. arXiv:1807.10440), hereinafter Alhawi, and Striem-Amit et al. (US 10503897 B1), hereinafter Striem-Amit.
Regarding Claim 25:
Glenn, Raugus, and Bardenstein combine to teach the method of claim 1.
The combination of Glenn, Raugus, and Bardenstein does not expressly teach wherein: the threat information relates to a ransomware attack; the at least one data packet is identified for review based on the at least one data packet being associated with the ransomware attack.
However, Alhawi teaches wherein: the threat information relates to a ransomware attack (Alhawi – P. 1: In this paper we introduce NetConverse, a machine learning analysis of Windows ransomware network traffic to achieve a high, consistent detection rate; and P. 2: The NetConverse model will focus on the Windows environment and proposes to leverage machine learning techniques for detecting Windows ransomware through analysing network traffic; and P. 5: Feature extraction was achieved using TShark, a terminal based feature of the network protocol analyser Wireshark [30]. The network traffic capture PCAP files can be analysed within Wireshark, but it offers limited export features. TShark provides a more flexible, powerful export feature that can create statistical, calculated data in addition to static feature extraction. We chose to extract several basic, traffic and connection based features using the TShark conversations export option. This aggregated each network capture file into unique conversations based on the 5-tuple [31] protocol, source/destination IP address, source/destination port values); the at least one data packet is identified for review based on the at least one data packet being associated with the ransomware attack (Alhawi – P. 1: In this paper we introduce NetConverse, a machine learning analysis of Windows ransomware network traffic to achieve a high, consistent detection rate; and P. 2: The NetConverse model will focus on the Windows environment and proposes to leverage machine learning techniques for detecting Windows ransomware through analysing network traffic; and P. 5: Feature extraction was achieved using TShark, a terminal based feature of the network protocol analyser Wireshark [30]. The network traffic capture PCAP files can be analysed within Wireshark, but it offers limited export features. TShark provides a more flexible, powerful export feature that can create statistical, calculated data in addition to static feature extraction. We chose to extract several basic, traffic and connection based features using the TShark conversations export option. This aggregated each network capture file into unique conversations based on the 5-tuple [31] protocol, source/destination IP address, source/destination port values).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Glenn, Raugus, and Bardenstein, further incorporating Alhawi to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Alhawi’s teaching to monitor network traffic and detect ransomware based on a combination of basic traffic features into Glenn, Raugus, and Bardenstein’s system for monitoring network activity. While Alhawi is not directed specifically directed to performing ransomware detection and alerting by an ISP server, it would have been obvious for one of ordinary skill in the art to combine the techniques disclosed in Alhawi with the system taught by the combination of Glenn, Raugus, and Bardenstein. Alwahi implements a feature set that would be available to an ISP server monitoring customer network activity in ransomware detection. Therefore, the addition of Alwahi would result in the obvious benefit of a capability to detect ransomware, in addition to the more generally stated malware detections described primarily by Raugus.
The combination of Glenn, Raugus, Bardenstein, and Alhawi does not expressly teach and the alert information describes the ransomware attack.
However, Striem-Amit teaches and the alert information describes the ransomware attack (Striem-Amit – Col. 1, Line 12-13: This description relates to preventing malware, especially ransomware, from running on computers; and Col. 6, Line 12-18: The alert manager 134 is configured to generate an alert according to the alert data 144 in response to a triggering condition as described above. In some implementations, the alert data 144 includes an alert type, e.g., email, SMS message, dialog box, and the like. In some implementations, the alert data 144 includes a message based on the triggering condition triggering the alert).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Glenn, Raugus, Bardenstein, and Alhawi, further incorporating Striem-Amit to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Striem-Amit’s teaching to provide a ransomware alert with information describing a detected ransomware attack into Glenn, Raugus, Bardenstein, and Alhawi’s combined system for monitoring network activity. This combination would enhance the convenience and functionality for system users by providing helpful information in responding to a possible attack.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Cai (CN 110417709 A) teaches a method for early detection and warning of a ransomware attack, performed in cooperation with an ISP
Childress et al. (US 20230254334 A1) teaches a method of monitoring network communication to/from a device to determine threats and corresponding risk levels
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NICHOLAS JOSEPH DILUZIO whose telephone number is (703)756-1229. The examiner can normally be reached Mon - Fri -- 7:30 AM - 5 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, Yin-Chen Shaw can be reached at 571-272-8878. 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.
/NICHOLAS JOSEPH DILUZIO/Examiner, Art Unit 2498
/YIN CHEN SHAW/Supervisory Patent Examiner, Art Unit 2498