DETAILED ACTION
Examiner acknowledges receipt of Applicant’s amendment filed on 01/02/2026
Claims 1, 7-8, and 14-15 are currently amended
Claims 1, 4, 6-8, 11, 13-15, 18, and 20 are pending
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
Examiner has fully considered Applicant’s amendments to the Claims in the arguments filed on 01/02/2026. Examiner has withdrawn the objections to the Claims in view of the amendments.
Response to Arguments
Applicant’s arguments filed 01/02/2026, with respect to the rejections of independent claims 1, 8, and 15 under 35 USC 103 have been fully considered and are persuasive. Therefore, the rejections have been withdrawn. However, upon further consideration, new grounds of rejection are made in view of the previously applied references from Reid, Karasev, and Lancioni, in addition to newly applied references from Muddu et al. (US 20170063902 A1), hereinafter Muddu, and Teal (US 20190080102 A1), hereinafter Teal. Specifically, Muddu is sufficient to modify the previously applied combination to teach the amended limitation “determining the correlation matches a cryptojacking model, based on a preconfigured threshold number of process matches between the process history table and the cryptojacking model”. Teal additionally modifies the previously applied combination to teach the amended limitation “determining … that the identified program is not approved by a system administrator, wherein system administrator approval is determined by comparing a program file extension, a program installation date, and a name of the identified program to a preconfigured approval list”. With regard to at least the rejections of the independent claims herein, Teal will be relied upon to teach limitations previously relying on Humphrey.
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, 4, 6, 8, 11, 13, 15, 18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Reid et al. (US 11159407 B2), hereinafter Reid, in view of Karasev et al. (US 20200387597 A1), hereinafter Karasev, Lancioni et al. (US 20200053109 A1), hereinafter Lancioni, Muddu et al. (US 20170063902 A1), hereinafter Muddu, and Teal (US 20190080102 A1), hereinafter Teal.
Regarding Claim 1:
Reid teaches a processor-implemented method, the method comprising (Reid – Col. 12, Lines 40-42: the steps, functions, or operations of method 200 may be performed by a computing device or system 300, and/or processor 302) capturing processor usage information and vector processor usage information (Reid – Col. 1, Lines 25-31: a processing system of a device having at least one processor may… obtain... utilization information of the device comprising: processor utilization information, memory utilization information, and network utilization information; and Col. 2, Line 6-14: In one example, the present disclosure may comprise a service implemented by a processing system of the device that may be embedded on top of a device operating system (OS) as an installable application with certain privileged accesses, and that may monitor the following upon being activated: processor usage (e.g., central processing unit (CPU) usage, graphics processing unit (GPU) usage, etc.), memory usage, and network activity (e.g., network interface card (NIC) usage); Examiner’s Comment: the GPU usage taught by Reid is interpreted as the “vector processor” usage of the claimed invention, as discussed in the Response to Arguments section above); identifying [and flagging] a program (Reid – Col. 6, Lines 18-21: As stated above, in one example, the unauthorized cryptomining detection service may assign a score, e.g., with confidence intervals, for the “likelihood that an unauthorized cryptomining program is running.”) using processing power above a preconfigured threshold for a preconfigured period of time based on the captured processor usage information and the vector processor usage information (Reid – Col. 13, Lines 51-58: At step 250, the processing system detects from the utilization information of the device a pattern comprising: a first network utilization burst, a processor utilization exceeding a processor utilization threshold and a memory utilization exceeding a memory utilization threshold over at least a designated period of time following the first network utilization burst, and a second network utilization burst after at least the designated period of time; and Reid – Col. 14, Lines 42-48: In one example, the designated period of time may comprise at least 5 minutes. In another example, the designated period of time may comprise at least 10 minutes. In other words, the designated period of time may comprise a minimum duration of time threshold over which the processor utilization and memory utilization remain elevated in order to determine a pattern match; and Reid – Col. 13, Lines 65-66: the pattern is detected for a particular process that is running on the device; and Col. 2, Line 6-14: In one example, the present disclosure may comprise a service implemented by a processing system of the device that may be embedded on top of a device operating system (OS) as an installable application with certain privileged accesses, and that may monitor the following upon being activated: processor usage (e.g., central processing unit (CPU) usage, graphics processing unit (GPU) usage, etc.), memory usage, and network activity (e.g., network interface card (NIC) usage)); determining [the correlation] matches a cryptojacking model (Reid – Col. 5, Line 51-59: In one example, the MLM may provide a confidence score regarding a prediction that the device is engaged in unauthorized cryptomining. For instance, if the MLM is a SVM-based model, a set of utilization metrics may be characterized as a vector in a hyperspace, where a separation hyperplane may distinguish between a “normal” state and unauthorized cryptomining. When the vector is on a side of the separation hyperplane that is indicative of unauthorized cryptomining, an alert may be generated) and that the identified program is not approved by a system administrator … the identified program to a preconfigured approval list (Reid – Col. 16, Lines 1-6: the method 200 may additionally include verifying that the process is not a whitelisted process and/or a scheduled process. For instance, legitimate processes may engage in operations which consume significant processor and memory resources, and which may also generate significant device heat. Accordingly, the method 200 may include verifying that the process is not authorized, prior to performing additional steps of the method 200 to confirm that unauthorized cryptomining is occurring).
Reid does not expressly teach generating a process history table of the identified program using the captured processor usage information and the vector processor usage information; correlating process history in the process history table to in-network processes and system input/output (I/0) usage; determining the correlation matches a cryptojacking model, based on a preconfigured threshold number of process matches between the process history table and the cryptojacking model; and preventing the identified program from utilizing the one or more processors based on the determining.
However, Karasev teaches generating a process history table of the identified program using the captured processor usage information and the [vector] processor usage information (Karasev – Paragraph [0046]: As described above, the process tracker 104 receives or collects process data such as process data 110-1. This process data is then analyzed by the process tracker 104 to generate process characteristics 200. The process characteristics 200 may include normalized information about the process such as the CPU usage, command line usage and or other information the cryptominer detector 101 can use to detect cryptominer software. For example, process data 110-1 may include a data structure listing the CPU usage percentage over a period of time and timestamps. Process tracker 104 may filter out this data by determining the largest CPU usage percentage over the period of time, the average CPU usage percentage, the lowest CPU usage percentage, etc. These processes values (e.g., the average percentage) are stored in process characteristics 200); correlating process history in the process history table to in-network processes and system input/output (I/0) usage (Karasev – Paragraph [0053]: Once a pattern defined in the rules 210 is matched by the process characteristics 200, the cryptominer detector 101 issues a suspicious behavior alert 220. In further aspects, the cryptominer detector 101 obtains telemetry data 140 for the computing devices 102 to aid in the identification of suspicious behavior, and/or to modify the rules 210 to improve identification of suspicious behavior; and Paragraph [0039]: The telemetry tracker 108 of cryptominer detector 101 obtains telemetry data of the computer devices 120 in response to identifying suspicious behavior, in order to improve cryptomining detection … When enough telemetry data is gathered (e.g., greater than a predefined amount or type of data), the telemetry tracker 108 analyzes the telemetry data and adjusts existing detection rules in rule engine 106 or introduces new ones; and Paragraph [0041]: the telemetry data comprises system data for a period of time between when the at least one process was launched and when the at least one process was ended. For example, a process may begin at 1:00 pm and in response to being labelled suspicious behavior, the process may be ended at 1:03 pm. During this three-minute period telemetry data may be collected and stored. The telemetry data may include, but is not limited to, CPU load percentage, memory allocation (e.g., RAM), a read/write log (e.g., to track new objects being created in various directories of the computer system), thread creation, process chains, network parameter log (e.g., the number of data packets received and from where), and power information; Examiner’s Comment: the rules 210 to which the process characteristics 200 are correlated are based on telemetry data including system I/O usage and in-network processes); determining the correlation matches a cryptojacking model, based on [a preconfigured threshold number of] process matches between the process history table and the cryptojacking model (Paragraph [0053]: Once a pattern defined in the rules 210 is matched by the process characteristics 200, the cryptominer detector 101 issues a suspicious behavior alert 220; and Paragraph [0068]: In exemplary aspects if a file or process is loaded onto a computer from a network, and if there are a number of suspicious signs, the file can be identified as having a high probability of being a cryptominer not authorized by the user. In some examples, the number of suspicious signs include high CPU consumption, lack of an active graphical window in a display of the computing device, attempts to inject code into other executables threads, network calls to known cryptomining pools, and/or the like); and preventing the identified program from utilizing the one or more processors based on the determining (Karasev – Paragraph [0074]: the cryptominer detector 101 determines whether an incoming file is a cryptominer when the incoming file performs one or more of the following: loads the CPU past a predetermined threshold, uses the command line, and/or accesses suspicious network addresses; and Paragraph [0075]: At 610, the cryptominer detector 101 establishes a danger rating for the source(s) associated with the one or more network addresses based on the scanning of the incoming files; and Paragraph [0076]: the threshold danger rating may be 7. If the current danger rating is 4 (i.e., less than the threshold danger rating), the source associated with the network addresses is not deemed dangerous (e.g., the source is not a cryptominer); and Paragraph [0077]: In response to determining that the danger rating is greater than a threshold danger rating, method 600 proceeds to 616, where the cryptominer detector 101 stops the incoming files activity on the computer system. In some aspects, this involves halting receipt of all incoming files over the network and quarantining/removing all files previously received from the network addresses).
Karasev further teaches determining … that the identified program is not approved by a system administrator wherein system administrator approval is determined by comparing … the identified program to a preconfigured approval list (Karasev – Paragraph [0035]: the process tracker 104 specifically detects the launch of processes that are not whitelisted and/or signed applications because these applications are generally trusted and authorized by a user or administrator to run on the computer system).
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 Reid, further incorporating Karasev to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Karasev’s teaching for a system administrator to pre-approve legitimate processes that may trigger cryptojacking alerts, in addition to generating a process history table storing historical program metrics to be compared against network/system activity to detect potential cryptojacking into Reid’s method for detecting unauthorized cryptomining within a system. This combination would help to decrease false alarms within the system and would prevent the system from disrupting legitimate processes, as well as provide self-updating reference values for detecting anomalous behavior indicative of unauthorized cryptomining.
The combination of Reid and Karasev does not expressly teach flagging a program.
However, Lancioni teaches flagging a program (Lancioni – Paragraph [0052]: detection block 232, ... can detect a potential ongoing cryptojacking operation and classify the operation as such).
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 Reid and Karasev, further incorporating Lancioni to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Lancioni’s teaching to classify a process as a potential cryptojacking operation into Reid and Karasev’s method for detecting unauthorized cryptomining within a system. This combined functionality would highlight specific suspicious processes in the system for further investigation of potential cryptojacking.
The combination of Reid, Karasev, and Lancioni does not expressly teach determining the correlation matches a cryptojacking model, based on a preconfigured threshold number of process matches between the process history table and the cryptojacking model.
However, Muddu teaches determining the correlation matches [a cryptojacking] model, based on a preconfigured threshold number of process matches between the process history table and the [cryptojacking] model (Muddu – Figure 82: example table illustrating criteria for rarity (anomaly) determination; and Paragraph [0725]: FIG. 82 shows a table 8200 listing examples of thresholds and/or parameters of a rarity criterion, for various example events, that can be used for determining whether an event is anomalous. The thresholds in the table 8200 include a score threshold, a feature count threshold (which specifies the minimum number of features and/or feature pairs to be anomalous) and an anomaly count threshold).
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 Reid, Karasev, and Lancioni, further incorporating Muddu to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Muddu’s teaching to incorporate a threshold for a count of anomalous features to detect some anomaly into Reid, Karasev, and Lancioni’s method for detecting unauthorized cryptomining within a system. Muddu is directed broadly to detecting “cybersecurity related anomalies”. However, the techniques taught by Muddu naturally combine with the process observations and behavior collection for comparison with known cryptojacking behaviors taught by the combination of Reid, Karasev, and Lancioni. Therefore, the addition of Muddu’s anomalous feature count threshold to the combined comparison of observed process behavior to targeted/known malicious behavior would result in the obvious benefit of a binary decision point for detecting anomalous (or malicious) behavior. Thus, the teachings are obvious to combine.
The combination of Reid, Karasev, Lancioni, and Muddu does not expressly teach a program file extension, a program installation date, and a name of the identified program.
However, Teal teaches a program file extension, a program installation date, and a name of the identified program (Teal – Paragraph [0263]: identifying information for an application or application type may … be used, including, for example, a file name, a process name, an installation date, an application source, an uninstaller location (or existence), and so forth; and Figure 14: includes app name/file name, e.g. “program.exe”, including file name and extension).
Teal further teaches and that the identified program is not approved by a system administrator … the identified program to a preconfigured approval list (Teal – Paragraph [0084]: The policy management facility 112 may be a set of rules or policies that may indicate enterprise facility 102 access permissions for the client facility, such as access permissions associated with the network, applications, external computer devices, and the like. The policy management facility 112 may include a database, a text file, a combination of databases and text files, or the like. In an embodiment, a policy database may be a block list, a black list, an allowed list, a white list, or the like that may provide a list of enterprise facility 102 external network locations/applications that may or may not be accessed by the client facility. The policy management facility 112 may include rules that may be interpreted with respect to an enterprise facility 102 network access request to determine if the request should be allowed. The rules may provide a generic rule for the type of access that may be granted).
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 Reid, Karasev, Lancioni, and Muddu, further incorporating Teal to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Teal’s teaching of verifiable identifying information for an application including at least a file name, file extension, and installation date into Reid, Karasev, Lancioni, and Muddu’s combined method for detecting unauthorized cryptomining within a system. Like Muddu, Teal is directed broadly to endpoint security. However, Teal’s teaching to associate each running application on an endpoint with identifying information that includes the app/file name, extension, and install date would be obvious to combine with Reid, Karasev, Lancioni, and Muddu. Reid and Karasev, in particular, highlight methods for checking suspicious activity against lists of known-good programs in order to prevent false positive alarms. The addition of Teal’s application identifying information would produce the obvious benefit of a more reliable authentication process based on multiple elements of process information.
Regarding Claim 4:
The combination of Reid, Karasev, Lancioni, Muddu, and Teal teaches the method of Claim 1.
Reid further teaches further comprising: in response to determining the identified program is not approved … (Reid – Col. 3, Lines 62-67 and Col. 4, Lines 1-2: expected and authorized remote applications running on the local device may be registered with the service in order that such services are not flagged as being associated with potential unauthorized cryptomining. As an example, a user workstation may access a server to perform legitimate computations. Activities of this nature and the associated applications may therefore be whitelisted with the service; and Reid – Col. 16, Lines 1-3: the method 200 may additionally include verifying that the process is not a whitelisted process and/or a scheduled process), transmitting a notification to the system administrator (Reid – Col. 9, Line 67 and Col. 10, Lines 1-3: the alert may be sent to one or more other devices, such as device 112. For instance, device 112 may be associated with a network administrator responsible for device 110).
Karasev further teaches approved by the system administrator (Karasev – Paragraph [0035]: the process tracker 104 specifically detects the launch of processes that are not whitelisted and/or signed applications because these applications are generally trusted and authorized by a user or administrator to run on the computer system).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 6:
The combination of Reid, Karasev, Lancioni, Muddu, and Teal teaches the method of Claim 1.
Reid further teaches wherein the preconfigured threshold is a value of processor usage or a value of time (Reid – Col. 10, Lines 52-55: DB 118 may store patterns for detecting unauthorized cryptomining from device utilization information (e.g., heat thresholds, processor and/or memory utilization thresholds, network utilization timing thresholds, and so forth).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 8:
Reid teaches a computer system, the computer system comprising: one or more processors, one or more computer-readable memories, one or more computer-readable tangible storage medium, and program instructions stored on at least one of the one or more tangible storage medium for execution by at least one of the one or more processors via at least one of the one or more memories, wherein the computer system is capable of performing a method comprising (Reid – Col. 17, Lines 37-54: The processor executing the computer readable or software instructions relating to the above described method(s) can be perceived as a programmed processor or a specialized processor. As such, the present module 305 for generating an unauthorized cryptomining alert (including associated data structures) of the present disclosure can be stored on a tangible or physical (broadly non-transitory) computer-readable storage device or medium, e.g., volatile memory, non-volatile memory, ROM memory, RAM memory, magnetic or optical drive, device or diskette and the like. Furthermore, a “tangible” computer-readable storage device or medium comprises a physical device, a hardware device, or a device that is discernible by the touch. More specifically, the computer-readable storage device may comprise any physical devices that provide the ability to store information such as data and/or instructions to be accessed by a processor or a computing device such as a computer or an application server) capturing processor usage information and vector processor usage information and the vector processor usage information (Reid – Col. 1, Lines 25-31: a processing system of a device having at least one processor may… obtain... utilization information of the device comprising: processor utilization information, memory utilization information, and network utilization information; and Col. 2, Line 6-14: In one example, the present disclosure may comprise a service implemented by a processing system of the device that may be embedded on top of a device operating system (OS) as an installable application with certain privileged accesses, and that may monitor the following upon being activated: processor usage (e.g., central processing unit (CPU) usage, graphics processing unit (GPU) usage, etc.), memory usage, and network activity (e.g., network interface card (NIC) usage); Examiner’s Comment: the GPU usage taught by Reid is interpreted as the “vector processor” usage of the claimed invention, as discussed in the Response to Arguments section above); identifying [and flagging] a program (Reid – Col. 6, Lines 18-21: As stated above, in one example, the unauthorized cryptomining detection service may assign a score, e.g., with confidence intervals, for the “likelihood that an unauthorized cryptomining program is running.”) using processing power above a preconfigured threshold for a preconfigured period of time based on the captured processor usage information and the vector processor usage information (Reid – Col. 13, Lines 51-58: At step 250, the processing system detects from the utilization information of the device a pattern comprising: a first network utilization burst, a processor utilization exceeding a processor utilization threshold and a memory utilization exceeding a memory utilization threshold over at least a designated period of time following the first network utilization burst, and a second network utilization burst after at least the designated period of time; and Reid – Col. 14, Lines 42-48: In one example, the designated period of time may comprise at least 5 minutes. In another example, the designated period of time may comprise at least 10 minutes. In other words, the designated period of time may comprise a minimum duration of time threshold over which the processor utilization and memory utilization remain elevated in order to determine a pattern match; and Reid – Col. 13, Lines 65-66: the pattern is detected for a particular process that is running on the device; and Col. 2, Line 6-14: In one example, the present disclosure may comprise a service implemented by a processing system of the device that may be embedded on top of a device operating system (OS) as an installable application with certain privileged accesses, and that may monitor the following upon being activated: processor usage (e.g., central processing unit (CPU) usage, graphics processing unit (GPU) usage, etc.), memory usage, and network activity (e.g., network interface card (NIC) usage)); determining [the correlation] matches a cryptojacking model (Reid – Col. 5, Line 51-59: In one example, the MLM may provide a confidence score regarding a prediction that the device is engaged in unauthorized cryptomining. For instance, if the MLM is a SVM-based model, a set of utilization metrics may be characterized as a vector in a hyperspace, where a separation hyperplane may distinguish between a “normal” state and unauthorized cryptomining. When the vector is on a side of the separation hyperplane that is indicative of unauthorized cryptomining, an alert may be generated) and that the identified program is not approved by a system administrator … the identified program to a preconfigured approval list (Reid – Col. 16, Lines 1-6: the method 200 may additionally include verifying that the process is not a whitelisted process and/or a scheduled process. For instance, legitimate processes may engage in operations which consume significant processor and memory resources, and which may also generate significant device heat. Accordingly, the method 200 may include verifying that the process is not authorized, prior to performing additional steps of the method 200 to confirm that unauthorized cryptomining is occurring).
Reid does not expressly teach generating a process history table of the identified program using the captured processor usage information and the vector processor usage information; correlating process history in the process history table to in-network processes and system input/output (I/0) usage; determining the correlation matches a cryptojacking model, based on a preconfigured threshold number of process matches between the process history table and the cryptojacking model; and preventing the identified program from utilizing the one or more processors based on the determining.
However, Karasev teaches generating a process history table of the identified program using the captured processor usage information and the [vector] processor usage information (Karasev – Paragraph [0046]: As described above, the process tracker 104 receives or collects process data such as process data 110-1. This process data is then analyzed by the process tracker 104 to generate process characteristics 200. The process characteristics 200 may include normalized information about the process such as the CPU usage, command line usage and or other information the cryptominer detector 101 can use to detect cryptominer software. For example, process data 110-1 may include a data structure listing the CPU usage percentage over a period of time and timestamps. Process tracker 104 may filter out this data by determining the largest CPU usage percentage over the period of time, the average CPU usage percentage, the lowest CPU usage percentage, etc. These processes values (e.g., the average percentage) are stored in process characteristics 200); correlating process history in the process history table to in-network processes and system input/output (I/0) usage (Karasev – Paragraph [0053]: Once a pattern defined in the rules 210 is matched by the process characteristics 200, the cryptominer detector 101 issues a suspicious behavior alert 220. In further aspects, the cryptominer detector 101 obtains telemetry data 140 for the computing devices 102 to aid in the identification of suspicious behavior, and/or to modify the rules 210 to improve identification of suspicious behavior; and Paragraph [0039]: The telemetry tracker 108 of cryptominer detector 101 obtains telemetry data of the computer devices 120 in response to identifying suspicious behavior, in order to improve cryptomining detection … When enough telemetry data is gathered (e.g., greater than a predefined amount or type of data), the telemetry tracker 108 analyzes the telemetry data and adjusts existing detection rules in rule engine 106 or introduces new ones; and Paragraph [0041]: the telemetry data comprises system data for a period of time between when the at least one process was launched and when the at least one process was ended. For example, a process may begin at 1:00 pm and in response to being labelled suspicious behavior, the process may be ended at 1:03 pm. During this three-minute period telemetry data may be collected and stored. The telemetry data may include, but is not limited to, CPU load percentage, memory allocation (e.g., RAM), a read/write log (e.g., to track new objects being created in various directories of the computer system), thread creation, process chains, network parameter log (e.g., the number of data packets received and from where), and power information; Examiner’s Comment: the rules 210 to which the process characteristics 200 are correlated are based on telemetry data including system I/O usage and in-network processes); determining the correlation matches a cryptojacking model, based on [a preconfigured threshold number of] process matches between the process history table and the cryptojacking model (Paragraph [0053]: Once a pattern defined in the rules 210 is matched by the process characteristics 200, the cryptominer detector 101 issues a suspicious behavior alert 220; and Paragraph [0068]: In exemplary aspects if a file or process is loaded onto a computer from a network, and if there are a number of suspicious signs, the file can be identified as having a high probability of being a cryptominer not authorized by the user. In some examples, the number of suspicious signs include high CPU consumption, lack of an active graphical window in a display of the computing device, attempts to inject code into other executables threads, network calls to known cryptomining pools, and/or the like); and preventing the identified program from utilizing the one or more processors based on the determining (Karasev – Paragraph [0074]: the cryptominer detector 101 determines whether an incoming file is a cryptominer when the incoming file performs one or more of the following: loads the CPU past a predetermined threshold, uses the command line, and/or accesses suspicious network addresses; and Paragraph [0075]: At 610, the cryptominer detector 101 establishes a danger rating for the source(s) associated with the one or more network addresses based on the scanning of the incoming files; and Paragraph [0076]: the threshold danger rating may be 7. If the current danger rating is 4 (i.e., less than the threshold danger rating), the source associated with the network addresses is not deemed dangerous (e.g., the source is not a cryptominer); and Paragraph [0077]: In response to determining that the danger rating is greater than a threshold danger rating, method 600 proceeds to 616, where the cryptominer detector 101 stops the incoming files activity on the computer system. In some aspects, this involves halting receipt of all incoming files over the network and quarantining/removing all files previously received from the network addresses).
Karasev further teaches determining … that the identified program is not approved by a system administrator wherein system administrator approval is determined by comparing … the identified program to a preconfigured approval list (Karasev – Paragraph [0035]: the process tracker 104 specifically detects the launch of processes that are not whitelisted and/or signed applications because these applications are generally trusted and authorized by a user or administrator to run on the computer system).
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 Reid, further incorporating Karasev to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Karasev’s teaching for a system administrator to pre-approve legitimate processes that may trigger cryptojacking alerts, in addition to generating a process history table storing historical program metrics to be compared against network/system activity to detect potential cryptojacking into Reid’s method for detecting unauthorized cryptomining within a system. This combination would help to decrease false alarms within the system and would prevent the system from disrupting legitimate processes, as well as provide self-updating reference values for detecting anomalous behavior indicative of unauthorized cryptomining.
The combination of Reid and Karasev does not expressly teach flagging a program.
However, Lancioni teaches flagging a program (Lancioni – Paragraph [0052]: detection block 232, ... can detect a potential ongoing cryptojacking operation and classify the operation as such).
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 Reid and Karasev, further incorporating Lancioni to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Lancioni’s teaching to classify a process as a potential cryptojacking operation into Reid and Karasev’s method for detecting unauthorized cryptomining within a system. This combined functionality would highlight specific suspicious processes in the system for further investigation of potential cryptojacking.
The combination of Reid, Karasev, and Lancioni does not expressly teach determining the correlation matches a cryptojacking model, based on a preconfigured threshold number of process matches between the process history table and the cryptojacking model.
However, Muddu teaches determining the correlation matches [a cryptojacking] model, based on a preconfigured threshold number of process matches between the process history table and the [cryptojacking] model (Muddu – Figure 82: example table illustrating criteria for rarity (anomaly) determination; and Paragraph [0725]: FIG. 82 shows a table 8200 listing examples of thresholds and/or parameters of a rarity criterion, for various example events, that can be used for determining whether an event is anomalous. The thresholds in the table 8200 include a score threshold, a feature count threshold (which specifies the minimum number of features and/or feature pairs to be anomalous) and an anomaly count threshold).
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 Reid, Karasev, and Lancioni, further incorporating Muddu to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Muddu’s teaching to incorporate a threshold for a count of anomalous features to detect some anomaly into Reid, Karasev, and Lancioni’s method for detecting unauthorized cryptomining within a system. Muddu is directed broadly to detecting “cybersecurity related anomalies”. However, the techniques taught by Muddu naturally combine with the process observations and behavior collection for comparison with known cryptojacking behaviors taught by the combination of Reid, Karasev, and Lancioni. Therefore, the addition of Muddu’s anomalous feature count threshold to the combined comparison of observed process behavior to targeted/known malicious behavior would result in the obvious benefit of a binary decision point for detecting anomalous (or malicious) behavior. Thus, the teachings are obvious to combine.
The combination of Reid, Karasev, Lancioni, and Teal does not expressly teach a program file extension, a program installation date, and a name of the identified program.
However, Teal teaches a program file extension, a program installation date, and a name of the identified program (Teal – Paragraph [0263]: identifying information for an application or application type may … be used, including, for example, a file name, a process name, an installation date, an application source, an uninstaller location (or existence), and so forth; and Figure 14: includes app name/file name, e.g. “program.exe”, including file name and extension).
Teal further teaches and that the identified program is not approved by a system administrator … the identified program to a preconfigured approval list (Teal – Paragraph [0084]: The policy management facility 112 may be a set of rules or policies that may indicate enterprise facility 102 access permissions for the client facility, such as access permissions associated with the network, applications, external computer devices, and the like. The policy management facility 112 may include a database, a text file, a combination of databases and text files, or the like. In an embodiment, a policy database may be a block list, a black list, an allowed list, a white list, or the like that may provide a list of enterprise facility 102 external network locations/applications that may or may not be accessed by the client facility. The policy management facility 112 may include rules that may be interpreted with respect to an enterprise facility 102 network access request to determine if the request should be allowed. The rules may provide a generic rule for the type of access that may be granted).
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 Reid, Karasev, Lancioni, and Muddu, further incorporating Teal to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Teal’s teaching of verifiable identifying information for an application including at least a file name, file extension, and installation date into Reid, Karasev, Lancioni, and Muddu’s combined method for detecting unauthorized cryptomining within a system. Like Muddu, Teal is directed broadly to endpoint security. However, Teal’s teaching to associate each running application on an endpoint with identifying information that includes the app/file name, extension, and install date would be obvious to combine with Reid, Karasev, Lancioni, and Muddu. Reid and Karasev, in particular, highlight methods for checking suspicious activity against lists of known-good programs in order to prevent false positive alarms. The addition of Teal’s application identifying information would produce the obvious benefit of a more reliable authentication based on multiple elements of process information.
Regarding Claim 11:
The combination of Reid, Karasev, Lancioni, Muddu, and Teal teaches the computer system of claim 8.
Reid further teaches further comprising: in response to determining the identified program is not approved … (Reid – Col. 3, Lines 62-67 and Col. 4, Lines 1-2: expected and authorized remote applications running on the local device may be registered with the service in order that such services are not flagged as being associated with potential unauthorized cryptomining. As an example, a user workstation may access a server to perform legitimate computations. Activities of this nature and the associated applications may therefore be whitelisted with the service; and Reid – Col. 16, Lines 1-3: the method 200 may additionally include verifying that the process is not a whitelisted process and/or a scheduled process), transmitting a notification to the system administrator (Reid – Col. 9, Line 67 and Col. 10, Lines 1-3: the alert may be sent to one or more other devices, such as device 112. For instance, device 112 may be associated with a network administrator responsible for device 110).
Karasev further teaches approved by the system administrator (Karasev – Paragraph [0035]: the process tracker 104 specifically detects the launch of processes that are not whitelisted and/or signed applications because these applications are generally trusted and authorized by a user or administrator to run on the computer system).
The motivation to combine the arts is the same as that of Claim 8.
Regarding Claim 13:
The combination of Reid, Karasev, Lancioni, Muddu, and Teal teaches the computer system of claim 8.
Reid further teaches wherein the preconfigured threshold is a value of processor usage or a value of time (Reid – Col. 10, Lines 52-55: DB 118 may store patterns for detecting unauthorized cryptomining from device utilization information (e.g., heat thresholds, processor and/or memory utilization thresholds, network utilization timing thresholds, and so forth).
The motivation to combine the arts is the same as that of Claim 8.
Regarding Claim 15:
Reid teaches a computer program product, the computer program product comprising: one or more computer-readable tangible storage medium and program instructions stored on at least one of the one or more tangible storage medium, the program instructions executable by a processor capable of performing a method, the method comprising (Reid – Col. 17, Lines 37-54: The processor executing the computer readable or software instructions relating to the above described method(s) can be perceived as a programmed processor or a specialized processor. As such, the present module 305 for generating an unauthorized cryptomining alert (including associated data structures) of the present disclosure can be stored on a tangible or physical (broadly non-transitory) computer-readable storage device or medium, e.g., volatile memory, non-volatile memory, ROM memory, RAM memory, magnetic or optical drive, device or diskette and the like. Furthermore, a “tangible” computer-readable storage device or medium comprises a physical device, a hardware device, or a device that is discernible by the touch. More specifically, the computer-readable storage device may comprise any physical devices that provide the ability to store information such as data and/or instructions to be accessed by a processor or a computing device such as a computer or an application server): capturing processor usage information and vector processor usage information (Reid – Col. 1, Lines 25-31: a processing system of a device having at least one processor may… obtain... utilization information of the device comprising: processor utilization information, memory utilization information, and network utilization information; and Col. 2, Line 6-14: In one example, the present disclosure may comprise a service implemented by a processing system of the device that may be embedded on top of a device operating system (OS) as an installable application with certain privileged accesses, and that may monitor the following upon being activated: processor usage (e.g., central processing unit (CPU) usage, graphics processing unit (GPU) usage, etc.), memory usage, and network activity (e.g., network interface card (NIC) usage); Examiner’s Comment: the GPU usage taught by Reid is interpreted as the “vector processor” usage of the claimed invention, as discussed in the Response to Arguments section above); identifying [and flagging] a program (Reid – Col. 6, Lines 18-21: As stated above, in one example, the unauthorized cryptomining detection service may assign a score, e.g., with confidence intervals, for the “likelihood that an unauthorized cryptomining program is running.”) using processing power above a preconfigured threshold for a preconfigured period of time based on the captured processor usage information and the vector processor usage information (Reid – Col. 13, Lines 51-58: At step 250, the processing system detects from the utilization information of the device a pattern comprising: a first network utilization burst, a processor utilization exceeding a processor utilization threshold and a memory utilization exceeding a memory utilization threshold over at least a designated period of time following the first network utilization burst, and a second network utilization burst after at least the designated period of time; and Reid – Col. 14, Lines 42-48: In one example, the designated period of time may comprise at least 5 minutes. In another example, the designated period of time may comprise at least 10 minutes. In other words, the designated period of time may comprise a minimum duration of time threshold over which the processor utilization and memory utilization remain elevated in order to determine a pattern match; and Reid – Col. 13, Lines 65-66: the pattern is detected for a particular process that is running on the device; and Col. 2, Line 6-14: In one example, the present disclosure may comprise a service implemented by a processing system of the device that may be embedded on top of a device operating system (OS) as an installable application with certain privileged accesses, and that may monitor the following upon being activated: processor usage (e.g., central processing unit (CPU) usage, graphics processing unit (GPU) usage, etc.), memory usage, and network activity (e.g., network interface card (NIC) usage)); determining [the correlation] matches a cryptojacking model (Reid – Col. 5, Line 51-59: In one example, the MLM may provide a confidence score regarding a prediction that the device is engaged in unauthorized cryptomining. For instance, if the MLM is a SVM-based model, a set of utilization metrics may be characterized as a vector in a hyperspace, where a separation hyperplane may distinguish between a “normal” state and unauthorized cryptomining. When the vector is on a side of the separation hyperplane that is indicative of unauthorized cryptomining, an alert may be generated) and that the identified program is not approved by a system administrator … the identified program to a preconfigured approval list (Reid – Col. 16, Lines 1-6: the method 200 may additionally include verifying that the process is not a whitelisted process and/or a scheduled process. For instance, legitimate processes may engage in operations which consume significant processor and memory resources, and which may also generate significant device heat. Accordingly, the method 200 may include verifying that the process is not authorized, prior to performing additional steps of the method 200 to confirm that unauthorized cryptomining is occurring).
Reid does not expressly teach generating a process history table of the identified program using the captured processor usage information and the vector processor usage information; correlating process history in the process history table to in-network processes and system input/output (I/0) usage; determining the correlation matches a cryptojacking model, based on a preconfigured threshold number of process matches between the process history table and the cryptojacking model; and preventing the identified program from utilizing the one or more processors based on the determining.
However, Karasev teaches generating a process history table of the identified program using the captured processor usage information and the [vector] processor usage information (Karasev – Paragraph [0046]: As described above, the process tracker 104 receives or collects process data such as process data 110-1. This process data is then analyzed by the process tracker 104 to generate process characteristics 200. The process characteristics 200 may include normalized information about the process such as the CPU usage, command line usage and or other information the cryptominer detector 101 can use to detect cryptominer software. For example, process data 110-1 may include a data structure listing the CPU usage percentage over a period of time and timestamps. Process tracker 104 may filter out this data by determining the largest CPU usage percentage over the period of time, the average CPU usage percentage, the lowest CPU usage percentage, etc. These processes values (e.g., the average percentage) are stored in process characteristics 200); correlating process history in the process history table to in-network processes and system input/output (I/0) usage (Karasev – Paragraph [0053]: Once a pattern defined in the rules 210 is matched by the process characteristics 200, the cryptominer detector 101 issues a suspicious behavior alert 220. In further aspects, the cryptominer detector 101 obtains telemetry data 140 for the computing devices 102 to aid in the identification of suspicious behavior, and/or to modify the rules 210 to improve identification of suspicious behavior; and Paragraph [0039]: The telemetry tracker 108 of cryptominer detector 101 obtains telemetry data of the computer devices 120 in response to identifying suspicious behavior, in order to improve cryptomining detection … When enough telemetry data is gathered (e.g., greater than a predefined amount or type of data), the telemetry tracker 108 analyzes the telemetry data and adjusts existing detection rules in rule engine 106 or introduces new ones; and Paragraph [0041]: the telemetry data comprises system data for a period of time between when the at least one process was launched and when the at least one process was ended. For example, a process may begin at 1:00 pm and in response to being labelled suspicious behavior, the process may be ended at 1:03 pm. During this three-minute period telemetry data may be collected and stored. The telemetry data may include, but is not limited to, CPU load percentage, memory allocation (e.g., RAM), a read/write log (e.g., to track new objects being created in various directories of the computer system), thread creation, process chains, network parameter log (e.g., the number of data packets received and from where), and power information; Examiner’s Comment: the rules 210 to which the process characteristics 200 are correlated are based on telemetry data including system I/O usage and in-network processes); determining the correlation matches a cryptojacking model, based on [a preconfigured threshold number of] process matches between the process history table and the cryptojacking model (Paragraph [0053]: Once a pattern defined in the rules 210 is matched by the process characteristics 200, the cryptominer detector 101 issues a suspicious behavior alert 220; and Paragraph [0068]: In exemplary aspects if a file or process is loaded onto a computer from a network, and if there are a number of suspicious signs, the file can be identified as having a high probability of being a cryptominer not authorized by the user. In some examples, the number of suspicious signs include high CPU consumption, lack of an active graphical window in a display of the computing device, attempts to inject code into other executables threads, network calls to known cryptomining pools, and/or the like); and preventing the identified program from utilizing the one or more processors based on the determining (Karasev – Paragraph [0074]: the cryptominer detector 101 determines whether an incoming file is a cryptominer when the incoming file performs one or more of the following: loads the CPU past a predetermined threshold, uses the command line, and/or accesses suspicious network addresses; and Paragraph [0075]: At 610, the cryptominer detector 101 establishes a danger rating for the source(s) associated with the one or more network addresses based on the scanning of the incoming files; and Paragraph [0076]: the threshold danger rating may be 7. If the current danger rating is 4 (i.e., less than the threshold danger rating), the source associated with the network addresses is not deemed dangerous (e.g., the source is not a cryptominer); and Paragraph [0077]: In response to determining that the danger rating is greater than a threshold danger rating, method 600 proceeds to 616, where the cryptominer detector 101 stops the incoming files activity on the computer system. In some aspects, this involves halting receipt of all incoming files over the network and quarantining/removing all files previously received from the network addresses).
Karasev further teaches determining … that the identified program is not approved by a system administrator wherein system administrator approval is determined by comparing … the identified program to a preconfigured approval list (Karasev – Paragraph [0035]: the process tracker 104 specifically detects the launch of processes that are not whitelisted and/or signed applications because these applications are generally trusted and authorized by a user or administrator to run on the computer system).
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 Reid, further incorporating Karasev to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Karasev’s teaching for a system administrator to pre-approve legitimate processes that may trigger cryptojacking alerts, in addition to generating a process history table storing historical program metrics to be compared against network/system activity to detect potential cryptojacking into Reid’s method for detecting unauthorized cryptomining within a system. This combination would help to decrease false alarms within the system and would prevent the system from disrupting legitimate processes, as well as provide self-updating reference values for detecting anomalous behavior indicative of unauthorized cryptomining.
The combination of Reid and Karasev does not expressly teach flagging a program.
However, Lancioni teaches flagging a program (Lancioni – Paragraph [0052]: detection block 232, ... can detect a potential ongoing cryptojacking operation and classify the operation as such).
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 Reid and Karasev, further incorporating Lancioni to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Lancioni’s teaching to classify a process as a potential cryptojacking operation into Reid and Karasev’s method for detecting unauthorized cryptomining within a system. This combined functionality would highlight specific suspicious processes in the system for further investigation of potential cryptojacking.
The combination of Reid, Karasev, and Lancioni does not expressly teach determining the correlation matches a cryptojacking model, based on a preconfigured threshold number of process matches between the process history table and the cryptojacking model.
However, Muddu teaches determining the correlation matches [a cryptojacking] model, based on a preconfigured threshold number of process matches between the process history table and the [cryptojacking] model (Muddu – Figure 82: example table illustrating criteria for rarity (anomaly) determination; and Paragraph [0725]: FIG. 82 shows a table 8200 listing examples of thresholds and/or parameters of a rarity criterion, for various example events, that can be used for determining whether an event is anomalous. The thresholds in the table 8200 include a score threshold, a feature count threshold (which specifies the minimum number of features and/or feature pairs to be anomalous) and an anomaly count threshold).
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 Reid, Karasev, and Lancioni, further incorporating Muddu to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Muddu’s teaching to incorporate a threshold for a count of anomalous features to detect some anomaly into Reid, Karasev, and Lancioni’s method for detecting unauthorized cryptomining within a system. Muddu is directed broadly to detecting “cybersecurity related anomalies”. However, the techniques taught by Muddu naturally combine with the process observations and behavior collection for comparison with known cryptojacking behaviors taught by the combination of Reid, Karasev, and Lancioni. Therefore, the addition of Muddu’s anomalous feature count threshold to the combined comparison of observed process behavior to targeted/known malicious behavior would result in the obvious benefit of a binary decision point for detecting anomalous (or malicious) behavior. Thus, the teachings are obvious to combine.
The combination of Reid, Karasev, Lancioni, and Teal does not expressly teach a program file extension, a program installation date, and a name of the identified program.
However, Teal teaches a program file extension, a program installation date, and a name of the identified program (Teal – Paragraph [0263]: identifying information for an application or application type may … be used, including, for example, a file name, a process name, an installation date, an application source, an uninstaller location (or existence), and so forth; and Figure 14: includes app name/file name, e.g. “program.exe”, including file name and extension).
Teal further teaches and that the identified program is not approved by a system administrator … the identified program to a preconfigured approval list (Teal – Paragraph [0084]: The policy management facility 112 may be a set of rules or policies that may indicate enterprise facility 102 access permissions for the client facility, such as access permissions associated with the network, applications, external computer devices, and the like. The policy management facility 112 may include a database, a text file, a combination of databases and text files, or the like. In an embodiment, a policy database may be a block list, a black list, an allowed list, a white list, or the like that may provide a list of enterprise facility 102 external network locations/applications that may or may not be accessed by the client facility. The policy management facility 112 may include rules that may be interpreted with respect to an enterprise facility 102 network access request to determine if the request should be allowed. The rules may provide a generic rule for the type of access that may be granted).
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 Reid, Karasev, Lancioni, and Muddu, further incorporating Teal to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Teal’s teaching of verifiable identifying information for an application including at least a file name, file extension, and installation date into Reid, Karasev, Lancioni, and Muddu’s combined method for detecting unauthorized cryptomining within a system. Like Muddu, Teal is directed broadly to endpoint security. However, Teal’s teaching to associate each running application on an endpoint with identifying information that includes the app/file name, extension, and install date would be obvious to combine with Reid, Karasev, Lancioni, and Muddu. Reid and Karasev, in particular, highlight methods for checking suspicious activity against lists of known-good programs in order to prevent false positive alarms. The addition of Teal’s application identifying information would produce the obvious benefit of a more reliable authentication based on multiple elements of process information.
Regarding Claim 18:
The combination of Reid, Karasev, Lancioni, Muddu, and Teal teaches the computer program product of claim 15.
Reid further teaches further comprising: in response to determining the identified program is not approved … (Reid – Col. 3, Lines 62-67 and Col. 4, Lines 1-2: expected and authorized remote applications running on the local device may be registered with the service in order that such services are not flagged as being associated with potential unauthorized cryptomining. As an example, a user workstation may access a server to perform legitimate computations. Activities of this nature and the associated applications may therefore be whitelisted with the service; and Reid – Col. 16, Lines 1-3: the method 200 may additionally include verifying that the process is not a whitelisted process and/or a scheduled process), transmitting a notification to the system administrator (Reid – Col. 9, Line 67 and Col. 10, Lines 1-3: the alert may be sent to one or more other devices, such as device 112. For instance, device 112 may be associated with a network administrator responsible for device 110).
Karasev further teaches approved by the system administrator (Karasev – Paragraph [0035]: the process tracker 104 specifically detects the launch of processes that are not whitelisted and/or signed applications because these applications are generally trusted and authorized by a user or administrator to run on the computer system).
The motivation to combine the arts is the same as that of Claim 15.
Regarding Claim 20:
The combination of Reid, Karasev, Lancioni, Muddu, and Teal teaches the computer system of claim 8.
Reid further teaches wherein the preconfigured threshold is a value of processor usage or a value of time (Reid – Col. 10, Lines 52-55: DB 118 may store patterns for detecting unauthorized cryptomining from device utilization information (e.g., heat thresholds, processor and/or memory utilization thresholds, network utilization timing thresholds, and so forth).
The motivation to combine the arts is the same as that of Claim 8.
Claims 7 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Reid, in view of Karasev, Lancioni, Muddu, Teal, and Hibbert et al. (US 20140245376 A1), hereinafter Hibbert.
Regarding Claim 7:
The combination of Reid, Karasev, Lancioni, and Humphrey teaches the method of Claim 1.
The combination of Reid, Karasev, Lancioni, and Humphrey does not expressly teach wherein the comparing further compares a program publisher and a program type of the identified program to the preconfigured approval list.
However, Hibbert teaches wherein the comparing further compares a program publisher and a program type of the identified program to the preconfigured approval list (Hibbert – Paragraph [0168]-[0179]: The rules and/or filters may allow the information retrieval module 510 to identify one or more segments (e.g., locations) within each record as containing relevant information. Further, in some embodiments, the rules and/or filters allow the information retrieval module 510 to identify the type, name, and/or nature of the information of one or more of the identified segments. For example, a location in a specific record type may contain an application version number. Another location of the same specific record type may contain an identifier of a specific process. In some embodiments, one or more records maybe encoded. The information retrieval module 510 may decode one or more records based on the retrieved rules and/or filters. In one example, the information retrieval module 510 may identify the following nonlimiting exemplary types of information (e.g., application or file attributes): [0169] Application Name [0170] Application Publisher [0171] File Name [0172] File Location/Path [0173] File Version [0174] File Timestamp [0175] File Description [0176] File Checksum (MD5, SHA-1, etc.) [0177] Digital Signature [0178] Execution Time [0179] Calling Process Those skilled in the art will appreciate that any other kind, type, or name of information may be utilized to assess security by the assessment module 513; and Paragraph [0180]: The assessment module 512 may assess the information in the records located by the information retrieval module 510; and Paragraph [0181]: The assessment module 512 may compare segments or any information contained within any of the records to all or part of the vulnerability database 522. In some embodiments, the vulnerability database 522 includes known good application and files (e.g., a whitelist), known vulnerable applications and files (e.g., a blacklist), and/or those applications and files that are suspicious (e.g., a greylist). In one example of a whitelist, the assessment module 512 may compare any number of segments from any number of records of any number of assessment requests to confirm and/or verify that the digital device has one or more trusted (e.g., nonvulnerable) applications or files).
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 Reid, Karasev, Lancioni, and Humphrey, further incorporating Hibbert to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Hibbert’s teaching to compare the various information of an identified program to corresponding information of processes on a preconfigured approved list into Reid, Karasev, Lancioni, and Humphrey’s method for detecting unauthorized cryptomining within a system. This combination would add specific parameters for verifying that a process detected as being potentially harmful is not on a list of approved processes, thus reducing false positives in detection.
Regarding Claim 14:
The combination of Reid, Karasev, Lancioni, and Humphrey teaches the computer system of Claim 8.
The combination of Reid, Karasev, Lancioni, and Humphrey does not expressly teach wherein the comparing further compares a program publisher and a program type of the identified program to the preconfigured approval list.
However, Hibbert teaches wherein the comparing further compares a program publisher and a program type of the identified program to the preconfigured approval list (Hibbert – Paragraph [0168]-[0179]: The rules and/or filters may allow the information retrieval module 510 to identify one or more segments (e.g., locations) within each record as containing relevant information. Further, in some embodiments, the rules and/or filters allow the information retrieval module 510 to identify the type, name, and/or nature of the information of one or more of the identified segments. For example, a location in a specific record type may contain an application version number. Another location of the same specific record type may contain an identifier of a specific process. In some embodiments, one or more records maybe encoded. The information retrieval module 510 may decode one or more records based on the retrieved rules and/or filters. In one example, the information retrieval module 510 may identify the following nonlimiting exemplary types of information (e.g., application or file attributes): [0169] Application Name [0170] Application Publisher [0171] File Name [0172] File Location/Path [0173] File Version [0174] File Timestamp [0175] File Description [0176] File Checksum (MD5, SHA-1, etc.) [0177] Digital Signature [0178] Execution Time [0179] Calling Process Those skilled in the art will appreciate that any other kind, type, or name of information may be utilized to assess security by the assessment module 513; and Paragraph [0180]: The assessment module 512 may assess the information in the records located by the information retrieval module 510; and Paragraph [0181]: The assessment module 512 may compare segments or any information contained within any of the records to all or part of the vulnerability database 522. In some embodiments, the vulnerability database 522 includes known good application and files (e.g., a whitelist), known vulnerable applications and files (e.g., a blacklist), and/or those applications and files that are suspicious (e.g., a greylist). In one example of a whitelist, the assessment module 512 may compare any number of segments from any number of records of any number of assessment requests to confirm and/or verify that the digital device has one or more trusted (e.g., nonvulnerable) applications or files).
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 Reid, Karasev, Lancioni, and Humphrey, further incorporating Hibbert to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Hibbert’s teaching to compare the various information of an identified program to corresponding information of processes on a preconfigured approved list into Reid, Karasev, Lancioni, and Humphrey’s method for detecting unauthorized cryptomining within a system. This combination would add specific parameters for verifying that a process detected as being potentially harmful is not on a list of approved processes, thus reducing false positives in detection.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Borlick et al. (US 20180293176 A1) teaches a system and method for identifying suspicious/malicious processes based on at least observed I/O activity
Agarwal et al. (US 20120311708 A1) teaches systems and methods for detecting malicious processes including rules and features
Ye et al. (US 9317686 B1) teaches a process for detect and protect against detected ransomware, the detection including an evaluation of processes based on a set of rules
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 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
Prosecution Insights