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 09/05/2025 has been entered.
Response to Arguments
Applicant’s arguments filed 09/05/2025, with respect to the rejections of independent claims 1, 8, and 15 and their corresponding dependent claims under 35 USC 103 have been fully considered and are persuasive. Therefore, the rejections have been withdrawn. However, upon further consideration and review of previously applied references, new grounds of rejection are made in view of previously applied references from Reid, Karasev, and Lancioni, in addition to a newly applied reference from Humphrey et al. (US 20210273960 A1), hereinafter Humphrey. Examiner respectfully submits that Reid, Karasev, and Lancioni are sufficient to teach the amended limitations capturing processor usage information and vector processor usage information; identifying and flagging a program using processing power above a preconfigured threshold for a preconfigured period of time based on the plurality of captured processor usage information and the vector processor usage information; generating a process history table of the identified program using the plurality of 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 (1/0) usage; determining the correlation matches a cryptojacking model and that the identified program is not approved by a system administrator; and preventing the identified program from utilizing the processor based on the determining.
Humphrey teaches the amended limitation wherein system administrator approval is determined by comparing a program file extension of the identified program to a preconfigured approval list.
For further clarification, upon review of the specification of the instant application in addition to an updated search and review of previously applied references, Examiner respectfully submits that the GPU (and usage information thereof) taught by Reid may be reasonably interpreted as the claimed “vector processor” (and usage information). The specification discusses a broadly stated vector processor. Paragraph [0028] implies that vector processor usage could be a useful metric in detecting cryptojacking because “cryptojacking typically does a large set of vector operations in order to crunch large sets of numbers quickly and communicate back to the blockchain as to what the next set of calculations are to be computed”, which in turn may cause “the processor(s) of the computing device (to) increase in speed and, at times, become fully utilized”. However, scarce detail is provided to further define the claimed “vector processor” as a uniquely-designed or uniquely-capable entity.
With attention to Figure 5 of the Drawings of the instant application, the processor 104 is illustrated as being able to accept “vector processing commands”, such as vector 0 (504), vector 1 (506), and vector N (508) in the vector processing pipeline. This illustration and description appear more analogous to SIMD instructions, which are a commonly known capability of modern CPUs.
Moreover, a supplemental reference from Chen (Chen, Z. (2016). Scalar-vector GPU architectures (Doctoral dissertation). Northeastern University. ProQuest Dissertations Publishing. Accessed From: https://ece.northeastern.edu/groups/nucar/publications/Zhongliang_Chen_thesis.pdf) demonstrates that, before the effective filing date of the claimed invention, one of ordinary skill in the art might reasonably consider a GPU to be a vector processor. Specifically, Chen recites “a vector
processor such as a GPU is a Single Instruction Multiple Data (SIMD) computer, where a single
instruction stream is executed on multiple data streams” (Chen – P. 1). Chen adds “We show that GPU compute applications typically have a mix of scalar and vector instructions” (Chen – P. 3). Therefore, it is concluded that a GPU can be understood to represent a “vector processor” as claimed and described in the specification of the instant application.
Claim Objections
Claims 7, 8, and 14 are objected to because of the following informalities:
Claims 7 and 14 include the similar limitation “the comparing further compares a program name, a program file name, a program file extension, a program installation date, a program publisher, and a program type to the preconfigured approval list”. This limitation could be amended to read: “the comparing further compares a program name, a program file name, a program installation date, a program publisher, and a program type of the identified program to the preconfigured approval list” to further clarify that the attributes being compared to the approval list are those of the identified program
In line 8 of Claim 8, the amended limitation “and the vector processor usage information” appears to have been added to the end of the “capturing” step instead of the “generating” step, as it is believed to have been intended (based on the amendments to Claim 1 and 15 in addition to the recent interview referenced in Applicant Arguments). Examiner respectfully submits the limitations should read “capturing a plurality of processor usage information and vector processor usage information” and “generating a process history table of the identified program using the captured processor usage information and the vector processor usage information”, respectively
In line 21 of Claim 8, the amended limitation “… utilizing the processor …” should read: “… utilizing the one or more processors …” in accordance with the antecedent basis of the “one or more processors” established in line 2 of the claim
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, 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, and Humphrey et al. (US 20210273960 A1), hereinafter Humphrey.
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 (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; and preventing the identified program from utilizing the processor 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 (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 preventing the identified program from utilizing the processor 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 (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 wherein system administrator approval is determined by comparing a program file extension of the identified program to a preconfigured approval list.
However, Humphrey teaches wherein system administrator approval is determined by comparing a program file extension of the identified program to a preconfigured approval list (Humphrey – Paragraph [0111]: The analyzer module can cooperate with the Artificial Intelligence models trained on potential cyber threats to detect suspicious network activity that exhibit traits that may suggest a malicious intent, such as network events taking place at unusual locations and/or times, unusual computer files leaving the network, unusual changes to computer files in the network, suspected crypto-mining behavior within the network, and/or suspicious or spam emails, as further described below; and Paragraph [0146]: The cyber threat detection platform is configured to detect Ransomware. This Ransomware Detection tool simplifies the cyber threat detection platform's way for detecting ransomware to make it faster and computationally less intensive. The Ransomware Detection tool uses an existing AI Analyst classifier that breaks down strings into subwords and letters to identify anomalies. The Ransomware Detection tool takes files that have been recently observed and sorts them alphabetically to establish pairs of files that have the same name and checks to see if the file extension, mimetype or byte-size has changed recently. The Ransomware Detection tool then takes those pairs and performs analysis on the file extension to see if it is likely a ransomware extension. The Ransomware Detection tool attempts to break down file extensions into subwords and, if not possible, individual letters and then looks for any frequency of use/proportion of files on the network. File extensions that are not divisible into subwords are deemed more anomalous than those that can break down into letters; and therefore, more likely to be ransomware. There is also a defined whitelist of known standard file extensions to minimize false positives. (AI analyst can use the Ransomware Detection tool on IT networks and other networks).
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 Humphrey to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Humphrey’s teaching to implement file extension analysis including a file extension whitelist into Reid, Karasev, and Lancioni’s method for detecting unauthorized cryptomining within a system. This addition would provide an additional means to detect suspicious file/process activity in addition to reducing false positive detections by using the whitelist.
Regarding Claim 4:
The combination of Reid, Karasev, Lancioni, and Humphrey 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, and Humphrey 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 (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; 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; and preventing the identified program from utilizing the processor based on the determining.
However, Karasev teaches generating a process history table of the identified program using the captured 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 (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 preventing the identified program from utilizing the processor 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 (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 wherein system administrator approval is determined by comparing a program file extension of the identified program to a preconfigured approval list.
However, Humphrey teaches wherein system administrator approval is determined by comparing a program file extension of the identified program to a preconfigured approval list (Humphrey – Paragraph [0111]: The analyzer module can cooperate with the Artificial Intelligence models trained on potential cyber threats to detect suspicious network activity that exhibit traits that may suggest a malicious intent, such as network events taking place at unusual locations and/or times, unusual computer files leaving the network, unusual changes to computer files in the network, suspected crypto-mining behavior within the network, and/or suspicious or spam emails, as further described below; and Paragraph [0146]: The cyber threat detection platform is configured to detect Ransomware. This Ransomware Detection tool simplifies the cyber threat detection platform's way for detecting ransomware to make it faster and computationally less intensive. The Ransomware Detection tool uses an existing AI Analyst classifier that breaks down strings into subwords and letters to identify anomalies. The Ransomware Detection tool takes files that have been recently observed and sorts them alphabetically to establish pairs of files that have the same name and checks to see if the file extension, mimetype or byte-size has changed recently. The Ransomware Detection tool then takes those pairs and performs analysis on the file extension to see if it is likely a ransomware extension. The Ransomware Detection tool attempts to break down file extensions into subwords and, if not possible, individual letters and then looks for any frequency of use/proportion of files on the network. File extensions that are not divisible into subwords are deemed more anomalous than those that can break down into letters; and therefore, more likely to be ransomware. There is also a defined whitelist of known standard file extensions to minimize false positives. (AI analyst can use the Ransomware Detection tool on IT networks and other networks).
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 Humphrey to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Humphrey’s teaching to implement file extension analysis including a file extension whitelist into Reid, Karasev, and Lancioni’s method for detecting unauthorized cryptomining within a system. This addition would provide an additional means to detect suspicious file/process activity in addition to reducing false positive detections by using the whitelist.
Regarding Claim 11:
The combination of Reid, Karasev, Lancioni, and Humphrey 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, and Humphrey 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 (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; 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; and preventing the identified program from utilizing the processor 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 (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 preventing the identified program from utilizing the processor 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 (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 wherein system administrator approval is determined by comparing a program file extension of the identified program to a preconfigured approval list.
However, Humphrey teaches wherein system administrator approval is determined by comparing a program file extension of the identified program to a preconfigured approval list (Humphrey – Paragraph [0111]: The analyzer module can cooperate with the Artificial Intelligence models trained on potential cyber threats to detect suspicious network activity that exhibit traits that may suggest a malicious intent, such as network events taking place at unusual locations and/or times, unusual computer files leaving the network, unusual changes to computer files in the network, suspected crypto-mining behavior within the network, and/or suspicious or spam emails, as further described below; and Paragraph [0146]: The cyber threat detection platform is configured to detect Ransomware. This Ransomware Detection tool simplifies the cyber threat detection platform's way for detecting ransomware to make it faster and computationally less intensive. The Ransomware Detection tool uses an existing AI Analyst classifier that breaks down strings into subwords and letters to identify anomalies. The Ransomware Detection tool takes files that have been recently observed and sorts them alphabetically to establish pairs of files that have the same name and checks to see if the file extension, mimetype or byte-size has changed recently. The Ransomware Detection tool then takes those pairs and performs analysis on the file extension to see if it is likely a ransomware extension. The Ransomware Detection tool attempts to break down file extensions into subwords and, if not possible, individual letters and then looks for any frequency of use/proportion of files on the network. File extensions that are not divisible into subwords are deemed more anomalous than those that can break down into letters; and therefore, more likely to be ransomware. There is also a defined whitelist of known standard file extensions to minimize false positives. (AI analyst can use the Ransomware Detection tool on IT networks and other networks).
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 Humphrey to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Humphrey’s teaching to implement file extension analysis including a file extension whitelist into Reid, Karasev, and Lancioni’s method for detecting unauthorized cryptomining within a system. This addition would provide an additional means to detect suspicious file/process activity in addition to reducing false positive detections by using the whitelist.
Regarding Claim 18:
The combination of Reid, Karasev, Lancioni, and Humphrey 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, and Humphrey 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, Humphrey, Hibbert et al. (US 20140245376 A1), hereinafter Hibbert, and Wu et al. (CN 113961936 A), hereinafter Wu.
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 name, a program file name, a program installation date, a program publisher, and a program type to the preconfigured approval list.
However, Hibbert teaches wherein the comparing further compares a program name, a program file name, … , a program publisher, and a program type 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.
The combination of Reid, Karasev, Lancioni, Humphrey, and Hibbert does not expressly teach wherein the comparing further compares … a program installation date … to the preconfigured approval list.
However, Wu teaches wherein the comparing further compares … a program installation date … to the preconfigured approval list (Wu – P. 3: the trusted white list comprises a white list software of the communication fingerprint, and the white list software software information the software information comprises at least one of … installation time).
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, Humphrey, and Hibbert further incorporating Wu to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Wu’s teaching to incorporate installation time into an application whitelist into Reid, Karasev, Lancioni, Humphrey, and Hibbert’s method for detecting unauthorized cryptomining within a system. This addition provides further means to verify a suspicious application.
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 name, a program file name, a program installation date, a program publisher, and a program type to the preconfigured approval list.
However, Binotto teaches wherein the comparing further compares a program name, a program file name, … a program publisher, and a program type 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.
The combination of Reid, Karasev, Lancioni, Humphrey, and Hibbert does not expressly teach wherein the comparing further compares … a program installation date … to the preconfigured approval list.
However, Wu teaches wherein the comparing further compares … a program installation date … to the preconfigured approval list (Wu – P. 3: the trusted white list comprises a white list software of the communication fingerprint, and the white list software software information the software information comprises at least one of … installation time).
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, Humphrey, and Hibbert further incorporating Wu to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Wu’s teaching to incorporate installation time into an application whitelist into Reid, Karasev, Lancioni, Humphrey, and Hibbert’s method for detecting unauthorized cryptomining within a system. This addition provides further means to verify a suspicious application.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Ning et al. (Ning, R., Wang, C., Xin, C., Li, J., Zhu, L., & Wu, H. (2019). CapJack: Capture in-browser crypto-jacking by deep capsule network through behavioral analysis. IEEE INFOCOM 2019 - IEEE Conference on Computer Communications, 1873–1881. https://doi.org/10.1109/infocom.2019.8737381) teaches a system for cryptojacking detection that implements a behavior analysis including I/O usage and network activity
Gomes et al. (Gomes, G., Dias, L., & Correia, M. (2020). Cryingjackpot: Network flows and performance counters against cryptojacking. 2020 IEEE 19th International Symposium on Network Computing and Applications (NCA), 1–10. https://doi.org/10.1109/nca51143.2020.9306698) teaches a model for cryptojacking that includes process I/O operations and network communications
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
/Jeremy S Duffield/Primary Examiner, Art Unit 2498
Prosecution Insights