DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 12/01/2025 has been entered.
Response to Arguments
The present office action is responsive to communication filed on 12/01/2025. Claims 1, 2, 5, 7-9, 12, 14-16, and 19 have been amended. Claims 1-20 are currently pending.
Applicant’s arguments filed on 12/01/2025, with respect to the rejections of claims 1, 8, and 15
under 35 USC 103 over Frank et al. (US PGPub 20200012787-A1) in view of Woodward et al. (US PGPub No. 20200034538-A1), Crosetto et al. (US PGPub No. 20130159977-A1), Littlejohn et al. (US PGPub No. 20140283042-A1) and Paris (US PGPub No. 20120311341-A1) with the amended limitations have been fully considered and are persuasive. Therefore, the rejection have been withdrawn. However, upon further consideration, a new grounds of rejection of is made in view of Knapp et al. (US PGPub No.20170351870-A1).
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.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Claims 1-3, 8-10, and 15-17 are rejected under 35 U.S.C. 103 as being unpatentable over Frank et al. (US PGPub 20200012787-A1) in view of Knapp et al. (US PGPub No.20170351870-A1), Crosetto et al. (US PGPub No. 20130159977-A1), Littlejohn et al. (US PGPub No. 20140283042-A1) and Paris (US PGPub No. 20120311341-A1).
With respect to claim 1, Frank teaches a computer-implemented method comprising: loading a logging agent to a kernel of an operating system executing on a computing device of [an industrial control system,] (Abstract: Methods and systems provide for detecting exploitation of kernel vulnerabilities which typically corrupt memory. The methods and systems are implemented, for example, via a host, which includes a hypervisor, which controls the operating system (OS) user space and the OS kernel space. ¶0040: As seen in Figure 2, the guest OS kernel Space 112, includes a trusted kernel modules logger (TKML) 112a, which operates as an agent inside the guest OS kernel space 112, and which logs kernel modules that are trusted, such as kernel drivers, in order to generate addresses for trusted code execution in guest OS kernel space 112. );
the logging agent being configured to detect kernel-level events occurring at the computing device, and (¶0041: As further seen in Figure 2,the hypervisor 116 includes kernel code execution enforcement logic (KCEEL) module 120. This module 120 is where the logic for hypervisor 116 is implemented. The KCEEL module is linked to the TKML 112a. The KCEEL module is linked to the TKML 112a (configured). The KCEEL links to an event logger (ELOG) 122, for logging security violation events, as detected by the hypervisor 116.);
the operating system being configured to define a kernel space and a user space of the computing device, (¶0038-0039: The methods and system are implemented, for example, via a host, which includes a hypervisor, which controls the operating system (OS) user space and the OS kernel space. The invention is also used in contained environments, where for example, the same kernel space associated with the memory is used, with different guest user space. As further exemplified, in Figure 2 details and exemplary system 100 in accordance with the present invention. The system 100 is located, for example in memory such as RAM. Within the RAM is an operating system (OS) 110, which is of virtual machine, formed of components example including guest OS Kernel Space 112 and guest OS user space 114. A host 111, runs a hypervisor 116, which is also part of the system 100 and links to the OS 110 , in order to control the guest OS Kernel Space 112 and the Guest OS User Space 114, in manner transparent to the guest OS Kernel Space 112 and guest OS user space 114. );
Frank does not disclose:
a computing device of an industrial control system,
wherein the computing device is a first type of computing device or a second type of computing device, and wherein the operating system comprises a general-purpose operating system of the first type of computing device or a real-time operating system of the second type of computing device;
wherein the one or more other computing devices comprise the first type of computing device or the second type of computing device, and wherein each of the first type of computing device and the second type of computing device are included in the industrial control system.
However, Knapp teaches a computing device of an industrial control system, (¶0063: Although Figure 2 illustrates one example of an industrial process control and automation system 200 in which removable media could be used, various changes may be made to FIG. 2. For example, industrial control and automation systems come in a wide variety of configurations.);
wherein the computing device is a first type of computing device or a second type of computing device, and wherein the operating system comprises a general-purpose operating system of the first type of computing device or a real-time operating system of the second type of computing device; (¶0047: As further seen in Figure 2, in the Purdue model, “Level 1” includes one or more controllers 206, which are coupled to the network 204. Each controller 206 includes any suitable structure for controlling one or more aspects of a process system. As a particular example, each controller 206 could represent a computing device running a real-time operating system. );
wherein the one or more other computing devices comprise the first type of computing device or the second type of computing device, and wherein each of the first type of computing device and the second type of computing device are included in the industrial control system. (¶0050: In the Purdue model, “Level 2” may include one or more machine-level controllers 214 coupled to the networks 212. The machine-level controllers 214 perform various functions to support the operation and control of the controllers 206, sensors 202a, and actuators 202b, which could be associated with a particular piece of industrial equipment (such as a boiler or other machine).);
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Knapp with regards to the computer devices to the method of Frank in order to provide a protected system such as securing confidential information and blocking malicious access (Knapp : ¶0026-0031 ).
Frank in view of Knapp does not disclose:
detecting, at the computing device, a kernel-level event using the logging agent loaded to the kernel, the kernel-level event being characterized by an attribute, and the kernel-level event being detected in the kernel space;
However, Crosetto teaches detecting, at the computing device, a kernel-level event using the logging agent loaded to the kernel, the kernel-level event being characterized by an attribute, and the kernel-level event being detected in the kernel space; (¶0030-0033: As seen in Figure 2, a flow diagram illustrates processing of the kernel trace system to insert new trace probes to an operating system kernel, in one embodiment. Beginning in block 210, the system receives information describing one or more traces to dynamically collect from an operating system that does not natively provide the described traces. The specification (attribute) may specify one or more operating system functions, APIs, or other entry points and specific data that the trace will collect (e.g., parameters, timestamp, thread/process identifier, and so on). ).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Crosetto of an attribute to the method of Frank in view of Knapp in order to leverage existing event reporting mechanism and more effectively analyze information (Crosetto : ¶0005).
Frank in view of Knapp and Crosetto does not disclose:
subsequent to detecting the kernel-level event, determining whether the detected kernel- level event satisfies a monitoring condition, the monitoring condition identifying at least one kernel-level event to log, and the determination being performed in the user space; in response to determining that the detected kernel-level event satisfies the monitoring condition, generating a log record that encapsulates the detected kernel-level event and the attribute, and the log record being generated in the user space; and transmitting the generated log record from the user space, wherein, upon receiving the log record,
However, Littlejohn teaches subsequent to detecting the kernel-level event, determining whether the detected kernel-level event satisfies a monitoring condition, the monitoring condition identifying at least one kernel-level event to log, and the determination being performed in the user space; (¶0043-0049: The real-time event configuration manager 131 also provides configuration of the real-time event evaluator 133. That is, the real-time event configuration manager 131 configures real-time event evaluator 133 (being configured to user space) to monitor events for resources over a given short period of time (a relatively small period of time that begins when a resource defined by the configuration information (discussed above) is first detected as having been accessed in some manner by the real-time user event configurer 141 (subsequent to detecting the kernel-level event). The real-time event configuration manager 131 can also configure the real-time event evaluator 133 with policies (may also be received by the real-time event configuration manager 131 via an API or GUI). The policies are conditions that inform the real-time event evaluator 133 on when the real-time event evaluator 133 should raise an event based on activity occurring in the queues for events received for the monitored resources (defined by the configuration information) during the monitored period of time (short during, such as between 30-90 seconds, which gives activity for resources a chance to stabilize and reduces noise associated with OS activity that may be irrelevant to whether the resource was changed or not). In an embodiment, the policies conditions include patterns of activity performed on a given resource that indicate reporting needs to occur (monitoring condition identifying at least one kernel-level event to log being in performed in the user space) .).
in response to determining that the detected kernel-level event satisfies the monitoring condition, generating a log record that encapsulates the detected kernel-level event and the attribute, and the log record being generated in the user space; and (¶0056: At the conclusion of the evaluation period, the real-time event evaluator 133 uses policy conditions (configured by real-time event configuration manager 131) to make decisions on whether any reporting is necessary or whether the activity on the resource can be ignored. This can be done by aggregating events for each resource over the evaluation then evaluating the policy conditions. ¶0067-0070: In the example situation of some policy conditions (notice the policy conditions can be hierarchical and nested), when the file (type of resource) was in the file system (another type of composite resource) and in the baseline resources 134, then the real-time event evaluator 133 can instruct the real-time reporter 135 to report (or raise an event at the OS user layer 130), using the event information (attribute) for the consolidated event being evaluated by the real-time event evaluator 133, stating user X (acting resource in the event information) modified or changed file Y (resource acted upon) at time Z by changing A to B, etc. Moreover, the reporting can be automated, such as when the real-time reporter 135 uses an API to interact with an automated service to take remedial real time action in response to the detected activity. So, the techniques not only improve security response times and the detail of security information but can also improve the quality of any security response and removes unnecessary OS noise. Still further, the techniques can be used for auditing and compliance. That is, the real-time event evaluator 133 can log the consolidated events for the resources for subsequent analysis (such as trend analysis, patterns, audit compliance reporting, and the like) (log record being generated in user space).)
transmitting the generated log record from the user space, wherein, upon receiving the log record, (¶0103: As seen in Figure 3, according to an embodiment, at 332 , the real-time event evaluator sends a real-time notification to an administrative service based on the evaluation. The communication channel or mechanism can be configured as well, such as API, log (indirect approach), posing to a webs site, text message service, etc.).
it would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Littlejohn with regards to conditions and encapsulation to the method of Frank in view of Knapp and Crosetto in order to prevent security breaches and prevent erroneous events and false positives (Littlejohn : ¶0002-0006).
Frank in view of Knapp, Crosetto, and Littlejohn does not disclose:
the detected kernel-level event and the attribute are combined with one or more other log records from one or more other computing devices into a time-ordered event data stream configured to be evaluated by a remote server,
Although, Frank in view of Knapp, Crosetto, and Littlejohn discloses the aggregation of events from one or more computing devices into a time-ordered event data stream, but the prior art does not explicitly disclose sending over kernel detected events to be evaluated by a remote server. However, Paris teaches the detected kernel-level event and the attribute are combined with one or more other log records from one or more other computing devices into a time-ordered event data stream configured to be evaluated by a remote server, (¶0103:As seen in Figure 4C, when detected, the centralized kernel module loader 460 computes the hash of the kernel module (464), and performs an upcall to a user space application 470 (466). The user space application 470 generates the load event request with the hash (472) and sends the load event request with the hash to a hypervisor 480 (474). The hypervisor 480 sends the load event request to an access control server 490 (482). . The access control server 490 processes the load event request 492, and sends a response to the hypervisor (494) with a decision of whether to allow or deny the load event.)
it would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Paris with regards to the remote server to the method of Frank in view of Knapp, Crosetto, and Littlejohn in order to provide control administrative control of the operating system and prevent unauthorized access (Paris : ¶0004 & ¶0015).
With respect to claim 2, the combination of Frank in view of Knapp, Crosetto, Littlejohn, and Paris teaches the method of claim 1 (see above claim 1 rejection), further comprising: generating a data signal using the computing device, the data signal being detected by the computing device or generated in response to operation of the computing device, the data signal being detected in the kernel space of the computing device, and (Knapp ¶0078: As seen in Figure 1, an SMX agent 103 can operate as a kernel-level driver or in kernel mode so that the SMX agent 103 allows access to a protected node's file system only upon validation and possibly decryption of certain files or elements. The SMX agent 103 could therefore intercept attempts to connect a storage device 402 at the driver level.);
the computing device is the second type of computing device executing the real-time operating system; and (Knapp ¶0047-0050: As seen in Figure 2, each controller 206 could represent a computing device running a real-time operating system.);
encapsulating the data signal as a log record, the encapsulation being performed in the user space. (Knapp ¶00083: Because an SMX agent 103 can operate in kernel mode on a protected node 102, the SMX agent 103 can be aware of all files copied to or from a storage device 402. The SMX agent 103 can save information related to all of these events or other events in an audit log file on an authorized storage device 402. For example, when an authorized storage device 402 is connected to a protected node 102, any or all available log files stored locally on the protected node 102 could be copied to the authorized storage device 402. When a storage device 402 with an audit log file connects to an SMX server 105 (such as for check-out), the SMX server 105 can copy the audit log file from the storage device 402 (such as to a local log store on the SMX server 105).);
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Knapp with regards to the computer devices to the method of Frank in view of Crosetto, Littlejohn, and Paris in order to provide a protected system such as securing confidential information and blocking malicious access (Knapp : ¶0026-0031 ).
With respect to claim 3, the combination of Frank in view of Knapp, Crosetto, Littlejohn, and Paris teaches the method of claim 2 (see above claim 2 rejection), wherein the computing device is a sensor, an actuator, a programmable logic controller, or a remote terminal unit of the industrial control system. (Knapp ¶0047-0050: As seen in Figure 2, in the Purdue model, “Level 1” includes one or more controllers 206, which are coupled to the network 204. Among other things, each controller 206 may use the measurements from one or more sensors 202a to control the operation of one or more actuators 202b.);
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Knapp with regards to the computer devices to the method of Frank in view of Crosetto, Littlejohn, and Paris in order to provide a protected system such as securing confidential information and blocking malicious access (Knapp : ¶0026-0031 ).
With respect to claim 8, Frank teaches an [industrial control] system, comprising: one or more processors; and a non-transitory computer-readable storage medium containing instructions which, when executed on the one or more processors, cause the one or more processors to perform operations including: (¶0064: As will be understood with reference to the paragraphs and the referenced drawings, provided above, various embodiments of computer-implemented methods are provided herein, some of which can be performed by various embodiments of apparatuses and systems described herein and some of which can be performed according to instructions stored in non-transitory computer-readable storage media described herein. Still, some embodiments of computer-implemented methods provided herein can be performed by other apparatuses or systems and can be performed according to instructions stored in computer-readable storage media other than that described herein, as will become apparent to those having skill in the art with reference to the embodiments described herein.);
loading a logging agent to a kernel of an operating system, the logging agent being configured to detect kernel-level events occurring at the kernel of the operating system, and (¶0041: As further seen in Figure 2,the hypervisor 116 includes kernel code execution enforcement logic (KCEEL) module 120. This module 120 is where the logic for hypervisor 116 is implemented. The KCEEL module is linked to the TKML 112a. The KCEEL module is linked to the TKML 112a (configured). The KCEEL links to an event logger (ELOG) 122, for logging security violation events, as detected by the hypervisor 116.)
the operating system being configured to define a kernel space and a user space, (¶0038-0039: The methods and system are implemented, for example, via a host, which includes a hypervisor, which controls the operating system (OS) user space and the OS kernel space. The invention is also used in contained environments, where for example, the same kernel space associated with the memory is used, with different guest user space. As further exemplified, in Figure 2 details and exemplary system 100 in accordance with the present invention. The system 100 is located, for example in memory such as RAM. Within the RAM is an operating system (OS) 110, which is of virtual machine, formed of components example including guest OS Kernel Space 112 and guest OS user space 114. A host 111, runs a hypervisor 116, which is also part of the system 100 and links to the OS 110 , in order to control the guest OS Kernel Space 112 and the Guest OS User Space 114, in manner transparent to the guest OS Kernel Space 112 and guest OS user space 114. );
Frank does not disclose:
an industrial control system
wherein the operating system comprises a general-purpose operating system of a first type of computing device or a real-time operating system of a second type of computing device of the industrial control system;
wherein the one or more computing devices comprise the first type of computing device or the second type of computing device, and wherein each of the first type of computing device and the second type of computing device are included in the industrial control system.
However, Knapp teaches an industrial control system(¶0063: Although Figure 2 illustrates one example of an industrial process control and automation system 200 in which removable media could be used, various changes may be made to Figure 2. For example, industrial control and automation systems come in a wide variety of configurations.);
wherein the operating system comprises a general-purpose operating system of a first type of computing device or a real-time operating system of a second type of computing device of the industrial control system; (¶0047: As further seen in Figure 2, in the Purdue model, “Level 1” includes one or more controllers 206, which are coupled to the network 204. Each controller 206 includes any suitable structure for controlling one or more aspects of a process system. As a particular example, each controller 206 could represent a computing device running a real-time operating system. );
wherein the one or more computing devices comprise the first type of computing device or the second type of computing device, and wherein each of the first type of computing device and the second type of computing device are included in the industrial control system. (¶0050: In the Purdue model, “Level 2” may include one or more machine-level controllers 214 coupled to the networks 212. The machine-level controllers 214 perform various functions to support the operation and control of the controllers 206, sensors 202a, and actuators 202b, which could be associated with a particular piece of industrial equipment (such as a boiler or other machine).);
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Knapp with regards to the computer devices to the method of Frank in order to provide a protected system such as securing confidential information
Frank in view of Knapp does not disclose:
detecting a kernel-level event using the logging agent loaded to the kernel, the kernel-level event being characterized by an attribute, and the kernel-level event being detected in the kernel space;
However, Crosetto teaches detecting a kernel-level event using the logging agent loaded to the kernel, the kernel-level event being characterized by an attribute, and the kernel-level event being detected in the kernel space; (¶0030-0033: As seen in Figure 2, a flow diagram illustrates processing of the kernel trace system to insert new trace probes to an operating system kernel, in one embodiment. Beginning in block 210, the system receives information describing one or more traces to dynamically collect from an operating system that does not natively provide the described traces. The specification (attribute) may specify one or more operating system functions, APIs, or other entry points and specific data that the trace will collect (e.g., parameters, timestamp, thread/process identifier, and so on). ).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Crosetto of an attribute to the method of Frank in view of Knapp in order to leverage existing event reporting mechanism and more effectively analyze information (Crosetto : ¶0005).
Frank in view of Knapp and Crosetto does not disclose:
subsequent to detecting the kernel-level event, determining whether the detected kernel- level event satisfies a monitoring condition, the monitoring condition identifying at least one kernel-level event to log, and the determination being performed in the user space; in response to determining that the detected kernel-level event satisfies the monitoring condition, generating a log record that encapsulates the detected kernel-level event and the attribute, and the log record being generated in the user space; and transmitting the generated log record from the user space, wherein, upon receiving the log record,
However, Littlejohn teaches subsequent to detecting the kernel-level event, determining whether the detected kernel-level event satisfies a monitoring condition, the monitoring condition identifying at least one kernel-level event to log, and the determination being performed in the user space; (¶0043-0049: The real-time event configuration manager 131 also provides configuration of the real-time event evaluator 133. That is, the real-time event configuration manager 131 configures real-time event evaluator 133 (being configured to user space) to monitor events for resources over a given short period of time (a relatively small period of time that begins when a resource defined by the configuration information (discussed above) is first detected as having been accessed in some manner by the real-time user event configurer 141 (subsequent to detecting the kernel-level event). The real-time event configuration manager 131 can also configure the real-time event evaluator 133 with policies (may also be received by the real-time event configuration manager 131 via an API or GUI). The policies are conditions that inform the real-time event evaluator 133 on when the real-time event evaluator 133 should raise an event based on activity occurring in the queues for events received for the monitored resources (defined by the configuration information) during the monitored period of time (short during, such as between 30-90 seconds, which gives activity for resources a chance to stabilize and reduces noise associated with OS activity that may be irrelevant to whether the resource was changed or not). In an embodiment, the policies conditions include patterns of activity performed on a given resource that indicate reporting needs to occur (monitoring condition identifying at least one kernel-level event to log being in performed in the user space) .).
in response to determining that the detected kernel-level event satisfies the monitoring condition, generating a log record that encapsulates the detected kernel-level event and the attribute, and the log record being generated in the user space; and (¶0056: At the conclusion of the evaluation period, the real-time event evaluator 133 uses policy conditions (configured by real-time event configuration manager 131) to make decisions on whether any reporting is necessary or whether the activity on the resource can be ignored. This can be done by aggregating events for each resource over the evaluation then evaluating the policy conditions. ¶0067-0070: In the example situation of some policy conditions (notice the policy conditions can be hierarchical and nested), when the file (type of resource) was in the file system (another type of composite resource) and in the baseline resources 134, then the real-time event evaluator 133 can instruct the real-time reporter 135 to report (or raise an event at the OS user layer 130), using the event information (attribute) for the consolidated event being evaluated by the real-time event evaluator 133, stating user X (acting resource in the event information) modified or changed file Y (resource acted upon) at time Z by changing A to B, etc. Moreover, the reporting can be automated, such as when the real-time reporter 135 uses an API to interact with an automated service to take remedial real time action in response to the detected activity. So, the techniques not only improve security response times and the detail of security information but can also improve the quality of any security response and removes unnecessary OS noise. Still further, the techniques can be used for auditing and compliance. That is, the real-time event evaluator 133 can log the consolidated events for the resources for subsequent analysis (such as trend analysis, patterns, audit compliance reporting, and the like) (log record being generated in user space).)
transmitting the generated log record from the user space, wherein, upon receiving the log record, (¶0103: As seen in Figure 3, according to an embodiment, at 332 , the real-time event evaluator sends a real-time notification to an administrative service based on the evaluation. The communication channel or mechanism can be configured as well, such as API, log (indirect approach), posing to a webs site, text message service, etc.).
it would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Littlejohn with regards to conditions and encapsulation to the method of Frank in view of Knapp and Crosetto in order to prevent security breaches and prevent erroneous events and false positives (Littlejohn : ¶0002-0006).
Frank in view of Knapp, Crosetto, and Littlejohn does not disclose:
the detected kernel-level event and the attribute are combined with one or more other log records from one or more other computing devices into a time-ordered event data stream configured to be evaluated by a remote server,
Although, Frank in view of Knapp, Crosetto, and Littlejohn discloses the aggregation of events from one or more computing devices into a time-ordered event data stream, but the prior art does not explicitly disclose sending over kernel detected events to be evaluated by a remote server. However, Paris teaches the detected kernel-level event and the attribute are combined with one or more other log records from one or more other computing devices into a time-ordered event data stream configured to be evaluated by a remote server, (¶0103:As seen in Figure 4C, when detected, the centralized kernel module loader 460 computes the hash of the kernel module (464), and performs an upcall to a user space application 470 (466). The user space application 470 generates the load event request with the hash (472) and sends the load event request with the hash to a hypervisor 480 (474). The hypervisor 480 sends the load event request to an access control server 490 (482). . The access control server 490 processes the load event request 492, and sends a response to the hypervisor (494) with a decision of whether to allow or deny the load event.)
it would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Paris with regards to the remote server to the method of Frank in view of Knapp, Crosetto, and Littlejohn in order to provide control administrative control of the operating system and prevent unauthorized access (Paris : ¶0004 & ¶0015).
With respect to claim 9, the combination of Frank in view of Knapp, Crosetto, Littlejohn, and Paris teaches the system of claim 8 (see rejection of claim 8 above), wherein the operations further comprise: generating a data signal, the data signal being detected by a computing device or generated in response to operation of the computing device, the data signal being detected in the kernel space of the computing device, and (Knapp ¶0078: As seen in Figure 1, an SMX agent 103 can operate as a kernel-level driver or in kernel mode so that the SMX agent 103 allows access to a protected node's file system only upon validation and possibly decryption of certain files or elements. The SMX agent 103 could therefore intercept attempts to connect a storage device 402 at the driver level.);
the computing device is the second type of computing device executing the real-time operating system; and (Knapp ¶0047-0050: As seen in Figure 2, each controller 206 could represent a computing device running a real-time operating system.);
encapsulating the data signal as a log record, the encapsulation being performed in the user space. (Knapp ¶00083: Because an SMX agent 103 can operate in kernel mode on a protected node 102, the SMX agent 103 can be aware of all files copied to or from a storage device 402. The SMX agent 103 can save information related to all of these events or other events in an audit log file on an authorized storage device 402. For example, when an authorized storage device 402 is connected to a protected node 102, any or all available log files stored locally on the protected node 102 could be copied to the authorized storage device 402. When a storage device 402 with an audit log file connects to an SMX server 105 (such as for check-out), the SMX server 105 can copy the audit log file from the storage device 402 (such as to a local log store on the SMX server 105).);
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Knapp with regards to the computer devices to the method of Frank in view of Crosetto, Littlejohn, and Paris in order to provide a protected system such as securing confidential information and blocking malicious access (Knapp : ¶0026-0031 ).
With respect to claim 10, the combination of Frank in view of Knapp, Crosetto, Littlejohn, and Paris teaches the system of claim 9 (see rejection of claim 9 above),wherein the operating system is installed on a programmable logic controller or a remote terminal unit of the industrial control system. (Knapp ¶0047-0050: As seen in Figure 2, in the Purdue model, “Level 1” includes one or more controllers 206, which are coupled to the network 204. Among other things, each controller 206 may use the measurements from one or more sensors 202a to control the operation of one or more actuators 202b.);
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Knapp with regards to the computer devices to the method of Frank in view of Crosetto, Littlejohn, and Paris in order to provide a protected system such as securing confidential information and blocking malicious access (Knapp : ¶0026-0031 ).
With respect to claim 15, Frank teaches a non-transitory machine-readable storage medium comprising instructions configured to cause a data processing apparatus of an [industrial control] system to perform operations including: (¶0062: For example, any combination of one or more non-transitory computer readable (storage) medium(s) may be utilized in accordance with the above-listed embodiments of the present invention. The non-transitory computer readable (storage) medium may be a computer readable signal medium or a computer readable storage medium. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.);
loading a logging agent to a kernel of an operating system, (Abstract: Methods and systems provide for detecting exploitation of kernel vulnerabilities which typically corrupt memory. The methods and systems are implemented, for example, via a host, which includes a hypervisor, which controls the operating system (OS) user space and the OS kernel space. ¶0040: As seen in Figure 2, the guest OS kernel Space 112, includes a trusted kernel modules logger (TKML) 112a, which operates as an agent inside the guest OS kernel space 112, and which logs kernel modules that are trusted, such as kernel drivers, in order to generate addresses for trusted code execution in guest OS kernel space 112. )the logging agent being configured to detect kernel-level events occurring at the kernel of the operating system, and (¶0041: As further seen in Figure 2,the hypervisor 116 includes kernel code execution enforcement logic (KCEEL) module 120. This module 120 is where the logic for hypervisor 116 is implemented. The KCEEL module is linked to the TKML 112a. The KCEEL module is linked to the TKML 112a (configured). The KCEEL links to an event logger (ELOG) 122, for logging security violation events, as detected by the hypervisor 116.)
the operating system being configured to define a kernel space and a user space, (¶0038-0039: The methods and system are implemented, for example, via a host, which includes a hypervisor, which controls the operating system (OS) user space and the OS kernel space. The invention is also used in contained environments, where for example, the same kernel space associated with the memory is used, with different guest user space. As further exemplified, in Figure 2 details and exemplary system 100 in accordance with the present invention. The system 100 is located, for example in memory such as RAM. Within the RAM is an operating system (OS) 110, which is of virtual machine, formed of components example including guest OS Kernel Space 112 and guest OS user space 114. A host 111, runs a hypervisor 116, which is also part of the system 100 and links to the OS 110 , in order to control the guest OS Kernel Space 112 and the Guest OS User Space 114, in manner transparent to the guest OS Kernel Space 112 and guest OS user space 114. );
Frank does not disclose
an industrial control system
wherein the operating system comprises a general-purpose operating system of a first type of computing device or a real-time operating system of a second type of computing device of the industrial control system;
wherein the one or more computing devices comprise the first type of computing device or the second type of computing device, and wherein each of the first type of computing device and the second type of computing device are included in the industrial control system.
However, Knapp teaches an industrial control system (¶0063: Although Figure 2 illustrates one example of an industrial process control and automation system 200 in which removable media could be used, various changes may be made to FIG. 2. For example, industrial control and automation systems come in a wide variety of configurations.);
wherein the operating system comprises a general-purpose operating system of a first type of computing device or a real-time operating system of a second type of computing device of the industrial control system; (¶0047: As further seen in Figure 2, in the Purdue model, “Level 1” includes one or more controllers 206, which are coupled to the network 204. Each controller 206 includes any suitable structure for controlling one or more aspects of a process system. As a particular example, each controller 206 could represent a computing device running a real-time operating system. );
wherein the one or more computing devices comprise the first type of computing device or the second type of computing device, and wherein each of the first type of computing device and the second type of computing device are included in the industrial control system. (¶0050: In the Purdue model, “Level 2” may include one or more machine-level controllers 214 coupled to the networks 212. The machine-level controllers 214 perform various functions to support the operation and control of the controllers 206, sensors 202a, and actuators 202b, which could be associated with a particular piece of industrial equipment (such as a boiler or other machine).);
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Knapp with regards to the computer devices to the method of Frank in order to provide a protected system such as securing confidential information and blocking malicious access (Knapp : ¶0026-0031 ).
Frank in view of Knapp does not disclose:
detecting a kernel-level event using the logging agent loaded to the kernel, the kernel- level event being characterized by an attribute, and the kernel-level event being detected in the kernel space;
However, Crosetto teaches detecting a kernel-level event using the logging agent loaded to the kernel, the kernel- level event being characterized by an attribute, and the kernel-level event being detected in the kernel space; (¶0030-0033: As seen in Figure 2, a flow diagram illustrates processing of the kernel trace system to insert new trace probes to an operating system kernel, in one embodiment. Beginning in block 210, the system receives information describing one or more traces to dynamically collect from an operating system that does not natively provide the described traces. The specification (attribute) may specify one or more operating system functions, APIs, or other entry points and specific data that the trace will collect (e.g., parameters, timestamp, thread/process identifier, and so on). ).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Crosetto of an attribute to the method of Frank in view of Knapp in order to leverage existing event reporting mechanism and more effectively analyze information (Crosetto : ¶0005).
Frank in view of Knapp and Crosetto does not disclose:
subsequent to detecting the kernel-level event, determining whether the detected kernel- level event satisfies a monitoring condition, the monitoring condition identifying at least one kernel-level event to log, and the determination being performed in the user space; in response to determining that the detected kernel-level event satisfies the monitoring condition, generating a log record that encapsulates the detected kernel-level event and the attribute, and the log record being generated in the user space; and transmitting the generated log record from the user space, wherein, upon receiving the log record,
However, Littlejohn teaches subsequent to detecting the kernel-level event, determining whether the detected kernel- level event satisfies a monitoring condition, the monitoring condition identifying at least one kernel-level event to log, and the determination being performed in the user space; (¶0043-0049: The real-time event configuration manager 131 also provides configuration of the real-time event evaluator 133. That is, the real-time event configuration manager 131 configures real-time event evaluator 133 (being configured to user space) to monitor events for resources over a given short period of time (a relatively small period of time that begins when a resource defined by the configuration information (discussed above) is first detected as having been accessed in some manner by the real-time user event configurer 141 (subsequent to detecting the kernel-level event). The real-time event configuration manager 131 can also configure the real-time event evaluator 133 with policies (may also be received by the real-time event configuration manager 131 via an API or GUI). The policies are conditions that inform the real-time event evaluator 133 on when the real-time event evaluator 133 should raise an event based on activity occurring in the queues for events received for the monitored resources (defined by the configuration information) during the monitored period of time (short during, such as between 30-90 seconds, which gives activity for resources a chance to stabilize and reduces noise associated with OS activity that may be irrelevant to whether the resource was changed or not). In an embodiment, the policies conditions include patterns of activity performed on a given resource that indicate reporting needs to occur (monitoring condition identifying at least one kernel-level event to log being in performed in the user space) .);
in response to determining that the detected kernel-level event satisfies the monitoring condition, generating a log record that encapsulates the detected kernel-level event and the attribute, and the log record being generated in the user space; and(¶0056: At the conclusion of the evaluation period, the real-time event evaluator 133 uses policy conditions (configured by real-time event configuration manager 131) to make decisions on whether any reporting is necessary or whether the activity on the resource can be ignored. This can be done by aggregating events for each resource over the evaluation then evaluating the policy conditions. ¶0067-0070: In the example situation of some policy conditions (notice the policy conditions can be hierarchical and nested), when the file (type of resource) was in the file system (another type of composite resource) and in the baseline resources 134, then the real-time event evaluator 133 can instruct the real-time reporter 135 to report (or raise an event at the OS user layer 130), using the event information (attribute) for the consolidated event being evaluated by the real-time event evaluator 133, stating user X (acting resource in the event information) modified or changed file Y (resource acted upon) at time Z by changing A to B, etc. Moreover, the reporting can be automated, such as when the real-time reporter 135 uses an API to interact with an automated service to take remedial real time action in response to the detected activity. So, the techniques not only improve security response times and the detail of security information but can also improve the quality of any security response and removes unnecessary OS noise. Still further, the techniques can be used for auditing and compliance. That is, the real-time event evaluator 133 can log the consolidated events for the resources for subsequent analysis (such as trend analysis, patterns, audit compliance reporting, and the like) (log record being generated in user space).);
transmitting the generated log record from the user space, wherein, upon receiving the log record, (¶0103: As seen in Figure 3, according to an embodiment, at 332 , the real-time event evaluator sends a real-time notification to an administrative service based on the evaluation. The communication channel or mechanism can be configured as well, such as API, log (indirect approach), posing to a webs site, text message service, etc.).
it would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Littlejohn with regards to conditions and encapsulation to the method of Frank in view of Knapp and Crosetto in order to prevent security breaches and prevent erroneous events and false positives (Littlejohn : ¶0002-0006).
Frank in view of Knapp, Crosetto, and Littlejohn does not disclose:
the detected kernel-level event and the attribute are combined with one or more other log records from one or more computing devices into a time-ordered event data stream configured to be evaluated by a remote server,
Although, Frank in view of Knapp, Crosetto, and Littlejohn discloses the aggregation of events from one or more computing devices into a time-ordered event data stream, but the prior art does not explicitly disclose sending over kernel detected events to be evaluated by a remote server. However, Paris teaches the detected kernel-level event and the attribute are combined with one or more other log records from one or more other computing devices into a time-ordered event data stream configured to be evaluated by a remote server, (¶0103:As seen in Figure 4C, when detected, the centralized kernel module loader 460 computes the hash of the kernel module (464), and performs an upcall to a user space application 470 (466). The user space application 470 generates the load event request with the hash (472) and sends the load event request with the hash to a hypervisor 480 (474). The hypervisor 480 sends the load event request to an access control server 490 (482). . The access control server 490 processes the load event request 492, and sends a response to the hypervisor (494) with a decision of whether to allow or deny the load event.)
it would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Paris with regards to the remote server to the method of Frank in view of Knapp, Crosetto, and Littlejohn in order to provide control administrative control of the operating system and prevent unauthorized access (Paris: ¶0004 & ¶0015).
With respect to claim 16, the combination of Frank in view of Knapp, Crosetto, Littlejohn, and Paris teaches the non-transitory machine-readable storage medium of claim 15 (see rejection of claim 15 above), wherein the operations further comprise :generating a data signal using a computing device, the data signal being detected by the computing device or generated in response to operation of the computing device, the data signal being detected in the kernel space of the computing device, and (Knapp ¶0078: As seen in Figure 1, an SMX agent 103 can operate as a kernel-level driver or in kernel mode so that the SMX agent 103 allows access to a protected node's file system only upon validation and possibly decryption of certain files or elements. The SMX agent 103 could therefore intercept attempts to connect a storage device 402 at the driver level.);
the computing device is the second type of computing device executing the real-time operating system; and (Knapp ¶0047-0050: As seen in Figure 2, each controller 206 could represent a computing device running a real-time operating system.);
encapsulating the data signal as a log record, the encapsulation being performed in the user space. Knapp ¶00083: Because an SMX agent 103 can operate in kernel mode on a protected node 102, the SMX agent 103 can be aware of all files copied to or from a storage device 402. The SMX agent 103 can save information related to all of these events or other events in an audit log file on an authorized storage device 402. For example, when an authorized storage device 402 is connected to a protected node 102, any or all available log files stored locally on the protected node 102 could be copied to the authorized storage device 402. When a storage device 402 with an audit log file connects to an SMX server 105 (such as for check-out), the SMX server 105 can copy the audit log file from the storage device 402 (such as to a local log store on the SMX server 105).);
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Knapp with regards to the computer devices to the method of Frank in view of Crosetto, Littlejohn, and Paris in order to provide a protected system such as securing confidential information and blocking malicious access (Knapp : ¶0026-0031 ).
With respect to claim 17, the combination of Frank in view of Knapp, Crosetto, Littlejohn, and Paris teaches the non-transitory machine-readable storage medium of claim 16 (see rejection of claim 16 above), wherein the operating system is installed on a programmable logic controller or a remote terminal unit of the industrial control system. (Knapp ¶0047-0050: As seen in Figure 2, in the Purdue model, “Level 1” includes one or more controllers 206, which are coupled to the network 204. Among other things, each controller 206 may use the measurements from one or more sensors 202a to control the operation of one or more actuators 202b.);
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Knapp with regards to the computer devices to the method of Frank in view of Crosetto, Littlejohn, and Paris in order to provide a protected system such as securing confidential information and blocking malicious access (Knapp : ¶0026-0031 ).
Claims 4, 11, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Frank et al. (US PGPub 20200012787-A1) in view of Knapp et al. (US PGPub No.20170351870-A1), Crosetto et al. (US PGPub No. 20130159977-A1), Littlejohn et al. (US PGPub No. 20140283042-A1), Paris (US PGPub No. 20120311341-A1), and Ginter et al. (US PGPub No.20090271504-A1).
With respect to claim 4, the combination of Frank in view of Knapp, Crosetto, Littlejohn, and Paris teaches the method of claim 2 (see above claim 2 rejection), but does not disclose wherein the data signal is associated with an event, and wherein the generated log record includes a value associated with the data signal and the event associated with the data signal.
However, Ginter teaches wherein the data signal is associated with an event, (Ginter: ¶0122-0123: The threat thermostat controller may be used in generating a response signal in accordance with one or more types of security threat inputs that derives from RTAP that signaled an event of an alarm level has been exceeded or reached) and wherein the generated log record includes a value associated with the data signal and the event associated with the data signal. (¶0138-0139: The threat indicator that may be produced by a threat thermostat controller as a signal may also serve as an input to RTAP that indicates the threat level that is associated with the event.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Ginter with regards to data signal is associated with event the method of Frank in view of Knapp, Crosetto, Littlejohn, and Paris in order to monitor the security activity and to efficiently handle potential malicious activity depending of the event of the system. (Ginter: ¶0120-122).
With respect to claim 11, the combination of Frank in view of Knapp, Crosetto, Littlejohn, and Paris teaches the system of claim 9 (see rejection of claim 9 above), but does not disclose wherein the data signal is associated with an event, and wherein the generated log record includes a value associated with the data signal and the event associated with the data signal.
However, Ginter teaches wherein the data signal is associated with an event, (Ginter: ¶0122-0123: The threat thermostat controller may be used in generating a response signal in accordance with one or more types of security threat inputs that derives from RTAP that signaled an event of an alarm level has been exceeded or reached) and wherein the generated log record includes a value associated with the data signal and the event associated with the data signal. (¶0138-0139: The threat indicator that may be produced by a threat thermostat controller as a signal may also serve as an input to RTAP that indicates the threat level that is associated with the event.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Ginter with regards to data signal is associated with event the method of Frank in view of Knapp, Crosetto, Littlejohn, and Paris in order to monitor the security activity and to efficiently handle potential malicious activity depending of the event of the system. (Ginter: ¶0120-122).
With respect to claim 18, the combination of Frank in view of Knapp, Crosetto, Littlejohn, and Paris teaches the non-transitory machine-readable storage medium of claim 16 (see rejection of claim 16 above), but does not disclose wherein the data signal is associated with an event, and wherein the generated log record includes a value associated with the data signal and the event associated with the data signal.
However, Ginter teaches wherein the data signal is associated with an event, (Ginter: ¶0122-0123: The threat thermostat controller may be used in generating a response signal in accordance with one or more types of security threat inputs that derives from RTAP that signaled an event of an alarm level has been exceeded or reached) and wherein the generated log record includes a value associated with the data signal and the event associated with the data signal. (¶0138-0139: The threat indicator that may be produced by a threat thermostat controller as a signal may also serve as an input to RTAP that indicates the threat level that is associated with the event.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Ginter with regards to data signal is associated with event the method of Frank in view of Knapp, Crosetto, Littlejohn, and Paris in order to monitor the security activity and to efficiently handle potential malicious activity depending of the event of the system. (Ginter: ¶0120-122).
Claims 5, 6, 12, 13, 19, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Frank et al. (US PGPub 20200012787-A1) in view of Knapp et al. (US PGPub No.20170351870-A1), Crosetto et al. (US PGPub No. 20130159977-A1), Littlejohn et al. (US PGPub No. 20140283042-A1), Paris (US PGPub No. 20120311341-A1), Diehl et al. (US PGPub No. 20190205533-A1), and Colgate et al. (US PGPub No. 20160117342-A1).
With respect to claim 5, the combination of Frank in view of Knapp, Crosetto, Littlejohn, and Paris teaches the method of claim 1 (see above claim 1 rejection), wherein the computing device is the first type of computing device executing the general purpose operating system, (Knapp ¶0050-0052:As seen in Figure 2, Each of the machine-level controllers 214 includes any suitable structure for providing access to, control of, or operations related to a machine or other individual piece of equipment.);
and wherein detecting the kernel-level event using the logging agent further comprises: identifying one or more user file activities (Knapp ¶0078-0083: Because an SMX agent 103 can operate in kernel mode on a protected node 102, the SMX agent 103 can be aware of all files copied to or from a storage device 402. The SMX agent 103 can also be aware of all file activity that is blocked, such as due to the presence of unauthorized files (like malware) or attempts to save files from a protected node 102 onto the storage device 402. ) being performed in the user space of the general purpose operating system executing on the computing device; (Knapp ¶0050-0052: Each of the operator stations 216 includes any suitable structure for supporting user access and control of one or more components in the system 200. Each of the operator stations 216 could, for example, represent a computing device running a MICROSOFT WINDOWS operating system. Each of the operator stations 216 includes any suitable structure for supporting user access and control of one or more components in the system 200. Each of the operator stations 216 could, for example, represent a computing device running a MICROSOFT WINDOWS operating system.);
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Knapp with regards to the computer devices to the method of Frank in view of Crosetto, Littlejohn, and Paris in order to prevent unauthorized file activity (Knapp : ¶0085).
Frank in view of Knapp, Crosetto, Littlejohn, and Paris does not disclose:
detecting one or more system calls that are triggered at the kernel space in response to the one or more user file activities being performed in the user space, each system call of the one or more system calls corresponding to a user file activity of the one or more user file activities, and filtering the one or more system calls using a device driver to determine which kernel- level event to monitor for security vulnerabilities; and encapsulating at least one user file activity in a log record when the at least one user file activity corresponds to the device driver.
However, Diehl detecting one or more system calls that are triggered at the kernel space in response to the one or more user file activities being performed in the user space, each system call of the one or more system calls corresponding to a user file activity of the one or more user file activities, and (¶0032 As described in Figure 1, when a user mode application issues a system call for a file I/O (for example, reading a file or writing to a file), a file I/O request is received by an I/O manager (such as I/O manager 120), which generates an I/O Request Packet (IRP) and routes the request to the appropriate file component. As shown in Figure 3, the I/O request 305 is intercepted by a filter manager 330, which may be embodied as filter manager 130 of Figure 1 (kernel space). Filter manager 330 loads kernel filter driver 350, as described in Figure 2. ).
filtering the one or more system calls using a device driver to determine which kernel- level event to monitor for security vulnerabilities; and(¶0042-0044: In, addition, the OS 114 may include hooks or filter drivers that allow other processes, such as the user-level security agent 116 and/or the kernel-level security agent 118 to receive notifications of the occurrence or non-occurrence of events. For example, at least some of the components 122, 128 may include “collectors” that receive notifications of semantically-interesting events (e.g., file writes and launching executables) from the OS's 114 hooks or filter drivers, from user-mode event monitors, kernel-mode event monitors, and/or from threads monitoring log files or memory locations. Further elaborated in ¶0028 the act of filtering events may be used among others, anti-malware security researchers, white-hat vulnerability researchers, or other analysts of events which implicates device driver is used to monitor security vulnerabilities. );
encapsulating at least one user file activity in a log record when the at least one user file activity corresponds to the device driver. (¶0045Other of the components 122, 128 may include “correlators” that note the fact of the occurrence of events, sometimes after filtering the semantically-interesting events down to a subset of events. Yet other of the components 122, 128 may include “actors” that may, among other things, gather forensic data associated with an event (encapsulating log record) and update a situational model of the user-mode security agent 116 and/or the kernel-level security agent 118 with the forensic data. Such a situational model can represent chains of execution activities and genealogies of processes, tracking attributes, behaviors, or patterns of processes executing on the computing device 102, enabling an “event consumer” component 122, 128 to determine when an event is interesting from a security standpoint. Events may include both actions performed by processes and non-occurrence of expected actions. For example, a collector component 122, 128 may register with a hook or filter driver offered by the OS 114 to receive notifications of the occurrence or non-occurrence of certain events, such as file creates, reads, or writes, or loading of executables (associated with the device driver) .).
it would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Diehl with regards to the detection of the kernel-level event to the method of Frank in view of Knapp, Crosetto, Littlejohn, and Paris in order to improve the system responsiveness and to protect a host computing system against malicious software—often called “malware”—that can steal or destroy system resources, data, and private information, security software configured to guard against such threats is often implemented in both a kernel mode and a user mode of the host computing system. (Diehl: ¶0002 & ¶0140).
Frank in view of Knapp, Crosetto, Littlejohn, Paris, and Diehl does not disclose:
each system call of the one or more system calls corresponding to an input/output (I/O) request associated with a kernel-level process;
However, Colgate teaches each system call of the one or more system calls corresponding to an input/output (I/O) request associated with a kernel-level process; (¶0020-0023 As shown in environment 100 of Figure 1 , when a user mode application or process (e.g., example process A, from above) issues a system call for a file I/O (for example, reading a file or writing to a file), a file I/O request 105 is received by the I/O manager 120. At a high level, once a file-write I/O request is detected, kernel filter driver 150 checks whether the file write is directed towards a monitored file. If it is not, then kernel filter driver 150 simply passes through the I/O request. On the other hand, if kernel filter driver 150 detects that the file write is for a file being monitored, then in an embodiment, the kernel filter driver 150 snoops (or copies without affecting) file-write information from the file-write request, which may be an IRP, and stores this information in a buffer in the kernel (such as kernel queue 360 of FIG. 3), which may be embodied as a kernel queue.).
it would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Colgate with regards to input/output request associated with a kernel-level process to the method of Frank in view of Knapp, Crosetto, Littlejohn, Paris, and Diehl in order to improve effectiveness of monitoring and reduce conflicts of the user mode application (Colgate ¶0001-0002).
With respect to claim 6, the combination of Frank in view of Knapp, Crosetto, Littlejohn, Paris, Diehl, and Colgate teaches the method of claim 5 (see above claim 5 rejection), wherein the computing device is an operator terminal or supervisory computer of the industrial control system. (Knapp ¶0051: One or more operator stations 216 are coupled to the networks 212. The operator stations 216 represent computing or communication devices providing user access to the machine-level controllers 214, which could then provide user access to the controllers 206 (and possibly the sensors 202a and actuators 202b). As particular examples, the operator stations 216 could allow users to review the operational history of the sensors 202a and actuators 202b using information collected by the controllers 206 and/or the machine-level controllers 214.);
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Knapp with regards to the computer devices to the method of Frank in view of Crosetto, Littlejohn, Paris, Diehl, and Colgate in order to provide a protected system such as securing confidential information and blocking malicious access (Knapp : ¶0026-0031 ).
With respect to claim 12, the combination of Frank in view of Knapp, Crosetto, Littlejohn, and Paris teaches the system of claim 8 (see rejection of claim 8 above), wherein the operating system comprises the general purpose operating system of the first type of computing device, and (Knapp ¶0050-0052:As seen in Figure 2, Each of the machine-level controllers 214 includes any suitable structure for providing access to, control of, or operations related to a machine or other individual piece of equipment.);
wherein the operation of detecting the kernel-level event using the logging agent further comprises: (Knapp ¶0078-0083: Because an SMX agent 103 can operate in kernel mode on a protected node 102, the SMX agent 103 can be aware of all files copied to or from a storage device 402. The SMX agent 103 can also be aware of all file activity that is blocked, such as due to the presence of unauthorized files (like malware) or attempts to save files from a protected node 102 onto the storage device 402. ) identifying one of more user file activities being performed in the user space of the operating system; (Knapp ¶0050-0052: Each of the operator stations 216 includes any suitable structure for supporting user access and control of one or more components in the system 200. Each of the operator stations 216 could, for example, represent a computing device running a MICROSOFT WINDOWS operating system. Each of the operator stations 216 includes any suitable structure for supporting user access and control of one or more components in the system 200. Each of the operator stations 216 could, for example, represent a computing device running a MICROSOFT WINDOWS operating system.);
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Knapp with regards to the computer devices to the method of Frank in view of Crosetto, Littlejohn, and Paris in order to prevent unauthorized file activity (Knapp : ¶0085).
Frank in view of Knapp, Crosetto, Littlejohn, and Paris does not disclose:
detecting one or more system calls that are triggered at the kernel space in response to the one or more user file activities being performed in the user space, each system call of the one or more system calls corresponding to a user file activity of the one or more user file activities, and each system call of the one or more system calls corresponding to an input/output (I/O) request associated with a kernel-level process; filtering the one or more system calls using a device driver to determine which kernel- level event to monitor for security vulnerabilities; and encapsulating at least one user file activity in a log record when the at least one user file activity corresponds to the device driver.
However, Diehl teaches detecting one or more system calls that are triggered at the kernel space in response to the one or more user file activities being performed in the user space, each system call of the one or more system calls corresponding to a user file activity of the one or more user file activities, and(¶0032 As described in Figure 1, when a user mode application issues a system call for a file I/O (for example, reading a file or writing to a file), a file I/O request is received by an I/O manager (such as I/O manager 120), which generates an I/O Request Packet (IRP) and routes the request to the appropriate file component. As shown in Figure 3, the I/O request 305 is intercepted by a filter manager 330, which may be embodied as filter manager 130 of Figure 1 (kernel space). Filter manager 330 loads kernel filter driver 350, as described in Figure 2. ).
filtering the one or more system calls using a device driver to determine which kernel- level event to monitor for security vulnerabilities; and (¶0042-0044: In, addition, the OS 114 may include hooks or filter drivers that allow other processes, such as the user-level security agent 116 and/or the kernel-level security agent 118 to receive notifications of the occurrence or non-occurrence of events. For example, at least some of the components 122, 128 may include “collectors” that receive notifications of semantically-interesting events (e.g., file writes and launching executables) from the OS's 114 hooks or filter drivers, from user-mode event monitors, kernel-mode event monitors, and/or from threads monitoring log files or memory locations. Further elaborated in ¶0028 the act of filtering events may be used among others, anti-malware security researchers, white-hat vulnerability researchers, or other analysts of events which implicates device driver is used to monitor security vulnerabilities. );
encapsulating at least one user file activity in a log record when the at least one user file activity corresponds to the device driver. (¶0045Other of the components 122, 128 may include “correlators” that note the fact of the occurrence of events, sometimes after filtering the semantically-interesting events down to a subset of events. Yet other of the components 122, 128 may include “actors” that may, among other things, gather forensic data associated with an event (encapsulating log record) and update a situational model of the user-mode security agent 116 and/or the kernel-level security agent 118 with the forensic data. Such a situational model can represent chains of execution activities and genealogies of processes, tracking attributes, behaviors, or patterns of processes executing on the computing device 102, enabling an “event consumer” component 122, 128 to determine when an event is interesting from a security standpoint. Events may include both actions performed by processes and non-occurrence of expected actions. For example, a collector component 122, 128 may register with a hook or filter driver offered by the OS 114 to receive notifications of the occurrence or non-occurrence of certain events, such as file creates, reads, or writes, or loading of executables (associated with the device driver) .).
it would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Diehl with regards to the detection of the kernel-level event to the method of Frank in view of Knapp, Crosetto, Littlejohn, and Paris in order to improve the system responsiveness and to protect a host computing system against malicious software—often called “malware”—that can steal or destroy system resources, data, and private information, security software configured to guard against such threats is often implemented in both a kernel mode and a user mode of the host computing system. (Diehl: ¶0002 & ¶0140).
Frank in view of Knapp, Crosetto, Littlejohn, Paris, and Diehl does not disclose:
each system call of the one or more system calls corresponding to an input/output (I/O) request associated with a kernel-level process;
However, Colgate teaches each system call of the one or more system calls corresponding to an input/output (I/O) request associated with a kernel-level process; (¶0020-0023 As shown in environment 100 of Figure 1 , when a user mode application or process (e.g., example process A, from above) issues a system call for a file I/O (for example, reading a file or writing to a file), a file I/O request 105 is received by the I/O manager 120. At a high level, once a file-write I/O request is detected, kernel filter driver 150 checks whether the file write is directed towards a monitored file. If it is not, then kernel filter driver 150 simply passes through the I/O request. On the other hand, if kernel filter driver 150 detects that the file write is for a file being monitored, then in an embodiment, the kernel filter driver 150 snoops (or copies without affecting) file-write information from the file-write request, which may be an IRP, and stores this information in a buffer in the kernel (such as kernel queue 360 of FIG. 3), which may be embodied as a kernel queue.).
it would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Colgate with regards to input/output request associated with a kernel-level process to the method of Frank in view of Knapp, Crosetto, Littlejohn, Paris, and Diehl in order to improve effectiveness of monitoring and reduce conflicts of the user mode application (Colgate ¶0001-0002).
With respect to claim 13, the combination of Frank in view of Knapp, Crosetto, Littlejohn, Paris, Diehl, and Colgate teaches the system of claim 12 (see rejection of claim 12 above), wherein the operating system is installed on an operator terminal or supervisory computer of the industrial control system. (Knapp ¶0051: One or more operator stations 216 are coupled to the networks 212. The operator stations 216 represent computing or communication devices providing user access to the machine-level controllers 214, which could then provide user access to the controllers 206 (and possibly the sensors 202a and actuators 202b). As particular examples, the operator stations 216 could allow users to review the operational history of the sensors 202a and actuators 202b using information collected by the controllers 206 and/or the machine-level controllers 214.);
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Knapp with regards to the computer devices to the method of Frank in view of Crosetto, Littlejohn, Paris, Diehl, and Colgate in order to provide a protected system such as securing confidential information and blocking malicious access (Knapp : ¶0026-0031 ).
With respect to claim 19, the combination of Frank in view of Knapp, Crosetto, Littlejohn, and Paris teaches the non-transitory machine-readable storage medium of claim 15 (see rejection of claim 15 above), wherein the operating system comprises the general purpose operating system of the first type of computing device, and (Knapp ¶0050-0052:As seen in Figure 2, Each of the machine-level controllers 214 includes any suitable structure for providing access to, control of, or operations related to a machine or other individual piece of equipment.);
wherein the operation of detecting the kernel-level event using the logging agent further comprises: identifying one of more user file activities (Knapp ¶0078-0083: Because an SMX agent 103 can operate in kernel mode on a protected node 102, the SMX agent 103 can be aware of all files copied to or from a storage device 402. The SMX agent 103 can also be aware of all file activity that is blocked, such as due to the presence of unauthorized files (like malware) or attempts to save files from a protected node 102 onto the storage device 402. ) being performed in the user space of the operating system; (Knapp ¶0050-0052: Each of the operator stations 216 includes any suitable structure for supporting user access and control of one or more components in the system 200. Each of the operator stations 216 could, for example, represent a computing device running a MICROSOFT WINDOWS operating system. Each of the operator stations 216 includes any suitable structure for supporting user access and control of one or more components in the system 200. Each of the operator stations 216 could, for example, represent a computing device running a MICROSOFT WINDOWS operating system.);
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Knapp with regards to the computer devices to the method of Frank in view of Crosetto, Littlejohn, and Paris in order to prevent unauthorized file activity (Knapp : ¶0085).
Frank in view of Knapp, Crosetto, Littlejohn, and Paris does not disclose:
detecting one or more system calls that are triggered at the kernel space in response to the one or more user file activities being performed in the user space, each system call of the one or more system calls corresponding to a user file activity of the one or more user file activities, and filtering the one or more system calls using a device driver to determine which kernel- level event to monitor for security vulnerabilities; and encapsulating at least one user file activity in a log record when the at least one user file activity corresponds to the device driver.
However, Diehl detecting one or more system calls that are triggered at the kernel space in response to the one or more user file activities being performed in the user space, each system call of the one or more system calls corresponding to a user file activity of the one or more user file activities, and (¶0032 As described in Figure 1, when a user mode application issues a system call for a file I/O (for example, reading a file or writing to a file), a file I/O request is received by an I/O manager (such as I/O manager 120), which generates an I/O Request Packet (IRP) and routes the request to the appropriate file component. As shown in Figure 3, the I/O request 305 is intercepted by a filter manager 330, which may be embodied as filter manager 130 of Figure 1 (kernel space). Filter manager 330 loads kernel filter driver 350, as described in Figure 2. ).
filtering the one or more system calls using a device driver to determine which kernel- level event to monitor for security vulnerabilities; and(¶0042-0044: In, addition, the OS 114 may include hooks or filter drivers that allow other processes, such as the user-level security agent 116 and/or the kernel-level security agent 118 to receive notifications of the occurrence or non-occurrence of events. For example, at least some of the components 122, 128 may include “collectors” that receive notifications of semantically-interesting events (e.g., file writes and launching executables) from the OS's 114 hooks or filter drivers, from user-mode event monitors, kernel-mode event monitors, and/or from threads monitoring log files or memory locations. Further elaborated in ¶0028 the act of filtering events may be used among others, anti-malware security researchers, white-hat vulnerability researchers, or other analysts of events which implicates device driver is used to monitor security vulnerabilities. );
encapsulating at least one user file activity in a log record when the at least one user file activity corresponds to the device driver. (¶0045Other of the components 122, 128 may include “correlators” that note the fact of the occurrence of events, sometimes after filtering the semantically-interesting events down to a subset of events. Yet other of the components 122, 128 may include “actors” that may, among other things, gather forensic data associated with an event (encapsulating log record) and update a situational model of the user-mode security agent 116 and/or the kernel-level security agent 118 with the forensic data. Such a situational model can represent chains of execution activities and genealogies of processes, tracking attributes, behaviors, or patterns of processes executing on the computing device 102, enabling an “event consumer” component 122, 128 to determine when an event is interesting from a security standpoint. Events may include both actions performed by processes and non-occurrence of expected actions. For example, a collector component 122, 128 may register with a hook or filter driver offered by the OS 114 to receive notifications of the occurrence or non-occurrence of certain events, such as file creates, reads, or writes, or loading of executables (associated with the device driver) .).
it would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Diehl with regards to the detection of the kernel-level event to the method of Frank in view of Knapp, Crosetto, Littlejohn, and Paris in order to improve the system responsiveness and to protect a host computing system against malicious software—often called “malware”—that can steal or destroy system resources, data, and private information, security software configured to guard against such threats is often implemented in both a kernel mode and a user mode of the host computing system. (Diehl: ¶0002 & ¶0140).
Frank in view of Knapp, Crosetto, Littlejohn, Paris, and Diehl does not disclose:
each system call of the one or more system calls corresponding to an input/output (I/O) request associated with a kernel-level process;
However, Colgate teaches each system call of the one or more system calls corresponding to an input/output (I/O) request associated with a kernel-level process; (¶0020-0023 As shown in environment 100 of Figure 1 , when a user mode application or process (e.g., example process A, from above) issues a system call for a file I/O (for example, reading a file or writing to a file), a file I/O request 105 is received by the I/O manager 120. At a high level, once a file-write I/O request is detected, kernel filter driver 150 checks whether the file write is directed towards a monitored file. If it is not, then kernel filter driver 150 simply passes through the I/O request. On the other hand, if kernel filter driver 150 detects that the file write is for a file being monitored, then in an embodiment, the kernel filter driver 150 snoops (or copies without affecting) file-write information from the file-write request, which may be an IRP, and stores this information in a buffer in the kernel (such as kernel queue 360 of FIG. 3), which may be embodied as a kernel queue.).
it would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Colgate with regards to input/output request associated with a kernel-level process to the method of Frank in view of Knapp, Crosetto, Littlejohn, Paris, and Diehl in order to improve effectiveness of monitoring and reduce conflicts of the user mode application (Colgate ¶0001-0002).
With respect to claim 20, the combination of Frank in view of Knapp, Crosetto, Littlejohn, Paris, Diehl, and Colgate teaches the non-transitory machine-readable storage medium of claim 19 (see rejection of claim 19 above), wherein the operating system is installed on an operator terminal or supervisory computer of the industrial control system. (Knapp ¶0051: One or more operator stations 216 are coupled to the networks 212. The operator stations 216 represent computing or communication devices providing user access to the machine-level controllers 214, which could then provide user access to the controllers 206 (and possibly the sensors 202a and actuators 202b). As particular examples, the operator stations 216 could allow users to review the operational history of the sensors 202a and actuators 202b using information collected by the controllers 206 and/or the machine-level controllers 214.);
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Knapp with regards to the computer devices to the method of Frank in view of Crosetto, Littlejohn, Paris, Diehl, and Colgate in order to provide a protected system such as securing confidential information and blocking malicious access (Knapp : ¶0026-0031 ).
Claims 7 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Frank et al. (US PGPub 20200012787-A1) in view of Knapp et al. (US PGPub No.20170351870-A1), Crosetto et al. (US PGPub No. 20130159977-A1), Littlejohn et al. (US PGPub No. 20140283042-A1), Paris (US PGPub No. 20120311341-A1), and Noeth et al. (US PGPub No. 20180307833-A1).
With respect to claim 7, the combination of Frank in view of Knapp, Crosetto, Littlejohn, and Paris teaches the method of claim 1 (see rejection of claim 1 above), wherein each of the first type of computing device and the second type of computing device are included in the industrial control system. (¶0063: Figure 2 illustrates one example of an industrial process control and automation system 200 in which removable media could be used, various changes may be made to Figure 2. For example, industrial control and automation systems come in a wide variety of configurations.);
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Knapp with regards to the computer devices to the method of Frank in view of Crosetto, Littlejohn, and Paris in order to provide a protected system such as securing confidential information and blocking malicious access (Knapp : ¶0026-0031 ).
Frank in view of Knapp, Crosetto, Littlejohn, and Paris does not disclose:
wherein the generated log record is received at the remote server, wherein the remote server additionally receives the one or more other log records, wherein the remote server generates the time-ordered event data stream that includes the generated log record and the one or more other log records in a sequence, such that a position of the generated log record or the one or more other log records in the sequence is based on a timestamp associated with each of the generated log record or the one or more other log records, and wherein the generated log record is generated the first type of computing device and the one or more other log records are generated by either the first type or the second type of computing device, and
However, Noeth teaches wherein the generated log record is received at the remote server, wherein the remote server additionally receives the one or more other log records, wherein the remote server generates the time-ordered event data stream that includes the generated log record and the one or more other log records in a sequence, (¶0067: Those details may include metadata of the packet, such as header information at various layers, the identifier of the application, identifiers of one or more filter criteria applied by the kernel driver indicating which criteria were satisfied or not satisfied, a timestamp of the network packet, and the like. In some embodiments, this log information may be processed by an agent 58, which in some cases may associate the logged information with additional forensic data gathered from user land application program interfaces of the operating system, like those described elsewhere herein. In some embodiments, the agent 58 may apply various criteria to determine whether the resulting aggregate information indicates a potential attack is occurring, and in some cases report this information into the cloud for further processing and aggregation and correlation across different computing devices, for instance by the security event processing system 14 (remote server). );
such that a position of the generated log record or the one or more other log records in the sequence is based on a timestamp associated with each of the generated log record or the one or more other log records, and (¶0067-0071: In some embodiments, the resulting network packet information may be logged to a listening application (e.g., an intrusion-detection agent) with details about the communication, as indicated by operation 3A. In some embodiments, the agent 58 (in connection with the remote server) may apply various criteria to determine whether the resulting aggregate information indicates a potential attack is occurring, and in some cases report this information into the cloud for further processing and aggregation and correlation across different computing devices, for instance by the security event processing system 14. In some embodiments, network packets (either directly or in virtue of being part of a session or other collection of activity that is classified) may be classified as malicious (e.g., by the driver, agent, or security event processing system) based on timing of packets.) wherein the generated log record is generated the first type of computing device and the one or more other log records are generated by either the first type or the second type of computing device, and (¶0057: As seen in Figure 1, in some embodiments, the computing devices 20 may implement techniques described below by which network traffic is monitored and classified, and the computing devices 20 may aggregate this information and send the gathered information to the security event processing system 14, which may aggregate information from a plurality of different user computing devices 20, for instance on a single subnet or a plurality of subnets 12.).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Noeth with regards to time-ordered data stream to the method Frank in view of Knapp, Crosetto, Littlejohn, and Paris in order to give indication whether have been consolidated and to track users rights/actions over time that contribute to afford a global view on potential attacks (Noeth: ¶0022-0029).
With respect to claim 14, the combination of Frank in view of Knapp, Crosetto, Littlejohn, and Paris teaches the system of claim 8 (see rejection of claim 8 above), wherein each of the first type of computing device and the second type of computing device are included in the industrial control system. (¶0063: Figure 2 illustrates one example of an industrial process control and automation system 200 in which removable media could be used, various changes may be made to Figure 2. For example, industrial control and automation systems come in a wide variety of configurations.);
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Knapp with regards to the computer devices to the method of Frank in view of Crosetto, Littlejohn, and Paris in order to provide a protected system such as securing confidential information and blocking malicious access (Knapp : ¶0026-0031 ).
Frank in view of Knapp, Crosetto, Littlejohn, and Paris does not disclose:
wherein the generated log record is received at the remote server, wherein the remote server additionally receives the one or more other log records, wherein the remote server generates the time-ordered event data stream that includes the generated log record and the one or more other log records in a sequence, such that a position of the generated log record or the one or more other log records in the sequence is based on a timestamp associated with each of the generated log record or the one or more other log records, and wherein the generated log record is generated by the first type of computing device and the one or more other log records are generated by either the first type or the second type of computing device, and
However, Noeth teaches wherein the generated log record is received at the remote server, wherein the remote server additionally receives the one or more other log records, wherein the remote server generates the time-ordered event data stream that includes the generated log record and the one or more other log records in a sequence, (¶0067: Those details may include metadata of the packet, such as header information at various layers, the identifier of the application, identifiers of one or more filter criteria applied by the kernel driver indicating which criteria were satisfied or not satisfied, a timestamp of the network packet, and the like. In some embodiments, this log information may be processed by an agent 58, which in some cases may associate the logged information with additional forensic data gathered from user land application program interfaces of the operating system, like those described elsewhere herein. In some embodiments, the agent 58 may apply various criteria to determine whether the resulting aggregate information indicates a potential attack is occurring, and in some cases report this information into the cloud for further processing and aggregation and correlation across different computing devices, for instance by the security event processing system 14 (remote server). );
such that a position of the generated log record or the one or more other log records in the sequence is based on a timestamp associated with each of the generated log record or the one or more other log records, and (¶0067-0071: In some embodiments, the resulting network packet information may be logged to a listening application (e.g., an intrusion-detection agent) with details about the communication, as indicated by operation 3A. In some embodiments, the agent 58 (in connection with the remote server) may apply various criteria to determine whether the resulting aggregate information indicates a potential attack is occurring, and in some cases report this information into the cloud for further processing and aggregation and correlation across different computing devices, for instance by the security event processing system 14. In some embodiments, network packets (either directly or in virtue of being part of a session or other collection of activity that is classified) may be classified as malicious (e.g., by the driver, agent, or security event processing system) based on timing of packets.) wherein the generated log record is generated the first type of computing device and the one or more other log records are generated by either the first type or the second type of computing device, and (¶0057: As seen in Figure 1, in some embodiments, the computing devices 20 may implement techniques described below by which network traffic is monitored and classified, and the computing devices 20 may aggregate this information and send the gathered information to the security event processing system 14, which may aggregate information from a plurality of different user computing devices 20, for instance on a single subnet or a plurality of subnets 12.).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Noeth with regards to time-ordered data stream to the method Frank in view of Knapp, Crosetto, Littlejohn, and Paris in order to give indication whether have been consolidated and to track users rights/actions over time that contribute to afford a global view on potential attacks (Noeth: ¶0022-0029).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TAYLOR P VU whose telephone number is (703)756-1218. The examiner can normally be reached MON - FRI (7:30 - 5:00).
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, Alexander Lagor can be reached at (571) 270-5143. 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.
/T.P.V./Examiner, Art Unit 2437
/ALEXANDER LAGOR/Supervisory Patent Examiner, Art Unit 2437