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 .
Claim Rejections - 35 USC § 102
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 (i.e., changing from AIA to pre-AIA ) 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.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1-9, 11-14 and 16-20 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Strogov et al. (Pub. No. US 2025/0390608).
Regarding claim 1. Strogov teaches a method (Strogov, the Abstract), comprising:
obtaining, by a processing system including at least one processor, a plurality of event data record based malware signatures (Strogov, Fig. 1, pp [43]-[45]: PRC database 108 stores registry data across system and retains data, such as known malware signatures, behavioral patterns, and historical telemetry data);
monitoring, by the processing system, a plurality of event data records associated with a mobility communication network (Strogov, Fig. 1, pp [50]-[51], [56]-[59]: detection engine 122 monitors and identifies potential security threats and suspicious activities on computing device 102, for example, based on data received from EDR driver 106, and detects signature-based detection, anomaly detection, behavior-based detection, threat intelligence feeds, and correlation of multiple events; pp [65]: EDR engine 126 tracks the status, history, and metadata associated with incoming event data, requests determinations on the event data from detection engine 122, and/or provides the event data to EDR database 112, allowing for real-time monitoring, reporting, and analysis);
detecting, by the processing system, at least one event data record of the plurality event data records matching at least one event data record based malware signature of the plurality of event data record based malware signatures (Strogov, Fig. 1, pp [50]-[51], [56]-[59]: detection engine 122 monitors and identifies potential security threats and suspicious activities on computing device 102, for example, based on data received from EDR driver 106, and detects signature-based detection, anomaly detection, behavior-based detection, threat intelligence feeds, and correlation of multiple events); and
performing, by the processing system, at least one remedial action for a mobile endpoint device of a subscriber associated with the at least one event data record matching the at least one event data record based malware signature (Strogov, Fig. 1, pp [50]-[51], [65]: EDR engine 126 can determine whether a response action is justified. For example, detected threats can be correlated with response actions, such as quarantine, isolation, remediation, or escalation for further investigation; Fig. 2, pp [80]-[82]: Remediation engine 216 facilitates response actions to mitigate security incidents and contain threats on the endpoint, the response actions may include isolating the endpoint from the network, terminating malicious processes, quarantining files, rolling back system changes, and/or alerting security operations personnel for further investigation and remediation).
Regarding claim 19. Strogov teaches a non-transitory computer-readable medium storing instructions which, when executed by a processing system including at least one processor (Strogov, the Abstract, Fig. 1), cause the processing system to perform operations, the operations comprising:
obtaining a plurality of event data record based malware signatures (Strogov, Fig. 1, pp [43]-[45]: PRC database 108 stores registry data across system and retains data, such as known malware signatures, behavioral patterns, and historical telemetry data);
monitoring a plurality of event data records associated with a mobility communication network (Strogov, Fig. 1, pp [50]-[51], [56]-[59]: detection engine 122 monitors and identifies potential security threats and suspicious activities on computing device 102, for example, based on data received from EDR driver 106, and detects signature-based detection, anomaly detection, behavior-based detection, threat intelligence feeds, and correlation of multiple events; pp [65]: EDR engine 126 tracks the status, history, and metadata associated with incoming event data, requests determinations on the event data from detection engine 122, and/or provides the event data to EDR database 112, allowing for real-time monitoring, reporting, and analysis);
detecting at least one event data record of the plurality event data records matching at least one event data record based malware signature of the plurality of event data record based malware signatures (Strogov, Fig. 1, pp [50]-[51], [56]-[59]: detection engine 122 monitors and identifies potential security threats and suspicious activities on computing device 102, for example, based on data received from EDR driver 106, and detects signature-based detection, anomaly detection, behavior-based detection, threat intelligence feeds, and correlation of multiple events); and
performing at least one remedial action for a mobile endpoint device of a subscriber associated with the at least one event data record matching the at least one event data record based malware signature (Strogov, Fig. 1, pp [50]-[51], [65]: EDR engine 126 can determine whether a response action is justified. For example, detected threats can be correlated with response actions, such as quarantine, isolation, remediation, or escalation for further investigation; Fig. 2, pp [80]-[82]: Remediation engine 216 facilitates response actions to mitigate security incidents and contain threats on the endpoint, the response actions may include isolating the endpoint from the network, terminating malicious processes, quarantining files, rolling back system changes, and/or alerting security operations personnel for further investigation and remediation).
Regarding claim 20. Strogov teaches an apparatus (Strogov, the Abstract), comprising:
a processing system including at least one processor (Strogov, Fig. 1, processor 118); and
a computer-readable medium storing instructions which, when executed by the processing system, cause the processing system to perform operations (Strogov, Fig. 1, processor 118), the operations comprising:
obtaining a plurality of event data record based malware signatures (Strogov, Fig. 1, pp [43]-[45]: PRC database 108 stores registry data across system and retains data, such as known malware signatures, behavioral patterns, and historical telemetry data);
monitoring a plurality of event data records associated with a mobility communication network (Strogov, Fig. 1, pp [50]-[51], [56]-[59]: detection engine 122 monitors and identifies potential security threats and suspicious activities on computing device 102, for example, based on data received from EDR driver 106, and detects signature-based detection, anomaly detection, behavior-based detection, threat intelligence feeds, and correlation of multiple events; pp [65]: EDR engine 126 tracks the status, history, and metadata associated with incoming event data, requests determinations on the event data from detection engine 122, and/or provides the event data to EDR database 112, allowing for real-time monitoring, reporting, and analysis);
detecting at least one event data record of the plurality event data records matching at least one event data record based malware signature of the plurality of event data record based malware signatures (Strogov, Fig. 1, pp [50]-[51], [56]-[59]: detection engine 122 monitors and identifies potential security threats and suspicious activities on computing device 102, for example, based on data received from EDR driver 106, and detects signature-based detection, anomaly detection, behavior-based detection, threat intelligence feeds, and correlation of multiple events); and
performing at least one remedial action for a mobile endpoint device of a subscriber associated with the at least one event data record matching the at least one event data record based malware signature (Strogov, Fig. 1, pp [50]-[51], [65]: EDR engine 126 can determine whether a response action is justified. For example, detected threats can be correlated with response actions, such as quarantine, isolation, remediation, or escalation for further investigation; Fig. 2, pp [80]-[82]: Remediation engine 216 facilitates response actions to mitigate security incidents and contain threats on the endpoint, the response actions may include isolating the endpoint from the network, terminating malicious processes, quarantining files, rolling back system changes, and/or alerting security operations personnel for further investigation and remediation).
Regarding claim 2. Strogov teaches the method of claim 1, wherein the processing system comprises an application server deployed within the mobility communication network for detecting malware (Strogov, pp [49], [52], [78]).
Regarding claim 3. Strogov teaches the method of claim 2, wherein the application server employs a machine learning model to perform at least one function of a malware detection module for detecting the malware (Strogov, pp [50], [57], [68], [95]).
Regarding claim 4. Strogov teaches the method of claim 1, further comprising:
determining, by the processing system, the mobile endpoint device is associated with the subscriber using the at least one event data record (Strogov, pp [36]-[37], [50], [60]).
Regarding claim 5. Strogov teaches the method of claim 4, wherein the determining the mobile endpoint device is associated with the subscriber using only the at least one event data record (Strogov, pp [36]-[37], [50], [60]).
Regarding claim 6. Strogov teaches the method of claim 1, wherein each of the plurality of event data record based malware signatures is generated by using an event data record associated with a mobile endpoint device having been infected with a known malware (Strogov, pp [43], [79]).
Regarding claim 7. Strogov teaches the method of claim 6, wherein the using the event data record associated with the mobile endpoint device having been infected with the known malware comprises using less than all fields of the event data record (Strogov, pp [43], [79]).
Regarding claim 8. Strogov teaches the method of claim 7, wherein the each of the plurality of event data record based malware signatures comprises an N-Tuple event data record based malware signature, where N is an integer value (Strogov, pp [57]-[60]).
Regarding claim 9. Strogov teaches the method of claim 8, wherein the N-Tuple event data record based malware signature comprises N fields of a respective event data record correlated with the each of the plurality of event data record based malware signatures (Strogov, pp [57]-[60]).
Regarding claim 11. Strogov teaches the method of claim 1, wherein each of the plurality of event data record based malware signatures is generated by applying a respective known malware to a test mobile endpoint device, where a subsequent respective event data record associated with this test mobile endpoint device is obtained and used to generate each respective event data record based malware signature (Strogov, pp [43], [50], [67], [79]).
Regarding claim 12. Strogov teaches the method of claim 11, wherein less than all fields of the subsequent respective event data record is used to generate the each respective event data record based malware signature (Strogov, pp [43], [50], [67], [79]).
Regarding claim 13. Strogov teaches the method of claim 12, wherein the each of the plurality of event data record based malware signatures comprises an N-Tuple event data record based malware signature, where N is an integer value (Strogov, pp [57]-[60]).
Regarding claim 14. Strogov teaches the method of claim 13, wherein the N-Tuple event data record based malware signature comprises N fields of a respective event data record correlated with the each of the plurality of event data record based malware signatures (Strogov, pp [57]-[60]).
Regarding claim 16. Strogov teaches the method of claim 1, wherein the at least one event data record based malware signature comprises supplemental information (Strogov, pp [56]-[61]).
Regarding claim 17. Strogov teaches the method of claim 16, wherein the supplemental information comprises at least one of:
an application attribute of an application used for a flow, a content type attribute of content transferred for a flow, a protocol attribute for a flow, or an operating system attribute of a mobile endpoint device for a flow (Strogov, pp [56]-[61]).
Regarding claim 18. Strogov teaches the method of claim 1, wherein the at least one remedial action comprises at least one of:
sending an update software patch to the mobile endpoint device, quarantining traffic of the mobile endpoint device, sending a notification to the subscriber, or notifying a security system of the mobility communication network to monitor the mobile endpoint device to discover an originating source of a malware associated with the at least one event data record based malware signature (Strogov, pp [51], [60]-[61], [65], [80]-[82]).
Claim Rejections - 35 USC § 103
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 (i.e., changing from AIA to pre-AIA ) 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.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 10 and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Strogov et al. (Pub. No. US 2025/0390608) and further in view of Thomas et al. (Pub. No. US 2023/0114821).
Regarding claim 10. Strogov does not teach the method of claim 9, wherein the N fields comprise at least two of:
an internet protocol address field of a user endpoint device that is a source of a flow, an internet protocol address field of a user endpoint device that is a destination of a flow, a transport layer port number used by the user endpoint device, a transport layer port number used by the destination of the flow, or a transport layer protocol identification.
Thomas teaches “an internet protocol address field of a user endpoint device that is a source of a flow, an internet protocol address field of a user endpoint device that is a destination of a flow, a transport layer port number used by the user endpoint device, a transport layer port number used by the destination of the flow, or a transport layer protocol identification.” (Thomas, Fig. 5, pp [113], [236]-[237]: number of nodes and edges, where computing objects associated with IP addresses, registry keys, domain names, uniform resource locators, are represented by nodes and events are represented by edges that mark directional relationships between computing objects such as data flows, control flows, network flows and so forth).
Therefore, it would have been obvious to a person of ordinary skill in the art before the affective filing date of the claimed invention was made to modify Strogov by incorporating teachings of Thomas, method and system for threat management of receiving data from a variety of sources such as compute instances within an enterprise network, cloud services and third-party data providers such as geolocation services. The system facilitates prompt notification of potential risks, the threat management facility may incrementally update data for use in threat assessments as the data becomes available from these different sources, and create suitable alerts or notifications whenever the currently accumulated data provides an indication of threat meeting a predetermined threshold. Additionally, the system also provides event graph that includes numbers of endpoint nodes, edges and computing objects which are associated with IP addresses where the system can provide communications regarding potential risks of malware, viruses, spyware, cryptoware, etc., for detecting and updating early information sufficiently and effectively to prevent and avoid any severe harms and damages to the endpoint devices and users.
Regarding claim 15. Strogov does not teach the method of claim 14, wherein the N fields comprise at least two of:
an internet protocol address field of a user endpoint device that is a source of a flow, an internet protocol address field of a user endpoint device that is a destination of a flow, a transport layer port number used by the user endpoint device, a transport layer port number used by the destination of the flow, or a transport layer protocol identification.
Thomas teaches “an internet protocol address field of a user endpoint device that is a source of a flow, an internet protocol address field of a user endpoint device that is a destination of a flow, a transport layer port number used by the user endpoint device, a transport layer port number used by the destination of the flow, or a transport layer protocol identification.” (Thomas, Fig. 5, pp [113], [236]-[237]: number of nodes and edges, where computing objects associated with IP addresses, registry keys, domain names, uniform resource locators, are represented by nodes and events are represented by edges that mark directional relationships between computing objects such as data flows, control flows, network flows and so forth).
Therefore, it would have been obvious to a person of ordinary skill in the art before the affective filing date of the claimed invention was made to modify Strogov by incorporating teachings of Thomas, method and system for threat management of receiving data from a variety of sources such as compute instances within an enterprise network, cloud services and third-party data providers such as geolocation services. The system facilitates prompt notification of potential risks, the threat management facility may incrementally update data for use in threat assessments as the data becomes available from these different sources, and create suitable alerts or notifications whenever the currently accumulated data provides an indication of threat meeting a predetermined threshold. Additionally, the system also provides event graph that includes numbers of endpoint nodes, edges and computing objects which are associated with IP addresses where the system can provide communications regarding potential risks of malware, viruses, spyware, cryptoware, etc., for detecting and updating early information sufficiently and effectively to prevent and avoid any severe harms and damages to the endpoint devices and users.
Relevant References to the claims but not used in the rejection above:
Ladnai (Pub. No. US 2017/0300690), teaches a data recorder stores endpoint activity on an ongoing basis as sequences of events that causally relate computer objects such as processes and files, and patterns within this event graph can be used to detect the presence of malware on the endpoint. The underlying recording process may be dynamically adjusted in order to vary the amount and location of recording as the security state of the endpoint changes over time. A threat management system providing protection to an enterprise against a plurality of threats—a context in which the following techniques may usefully be deployed. One aspect relates to corporate policy management and implementation through a unified threat management facility 100. As will be explained in more detail below, a threat management facility 100 may be used to protect computer assets from many threats, both computer-generated threats and user-generated threats. The threat management facility 100 may be multi-dimensional in that it may be designed to protect corporate assets from a variety of threats and it may be adapted to learn about threats in one dimension (e.g. worm detection) and apply the knowledge in another dimension (e.g. spam detection). Policy management is one of the dimensions for which the threat management facility can provide a control capability. A corporation or other entity may institute a policy that prevents certain people (e.g. employees, groups of employees, types of employees, guest of the corporation, etc.) from accessing certain types of computer programs. For example, the corporation may elect to prevent its accounting department from using a particular version of an instant messaging service or all such services. In this example, the policy management facility 112 may be used to update the policies of all corporate computing assets with a proper policy control facility or it may update a select few. By using the threat management facility 100 to facilitate the setting, updating and control of such policies the corporation only needs to be concerned with keeping the threat management facility 100 up to date on such policies. The threat management facility 100 may take care of updating all of the other corporate computing assets.
Nan (Pub. No. US 2025/0165240), teaches a processor-implemented method for software deployment is disclosed. A software agent is installed on endpoint devices in a network. Each software agent manages a unique endpoint device and communicates to orchestration software. The software agent provides access to one or more third-party applications running on the endpoint devices. The third-party applications communicate with the software agent running on the endpoint devices via an application programming interface (API). The software agent monitors the endpoint device activity generated by the third-party applications. The agent can send security information details from the endpoint device and the third-party applications to the orchestration software. The orchestration software can summarize the security information details from the endpoint devices and initiate actions on one or more of the endpoint devices when suspicious activity is detected. Actions can include blocking suspicious activities, and installing, updating, or removing software. The one of more third-party applications can include antivirus software, endpoint detection and response (EDR) software, incident response software, anti-ransomware, or advanced persistent threat (APT) software. Other third-party applications can be included. Antivirus or anti-malware applications are computer programs designed to prevent, detect, and remove malicious software viruses, worms, trojans, adware, and so on. They can scan files, directories, and memory for malware or known malware patterns and report any suspicious findings to the user or management software. EDR software records all activities and events occurring on endpoint devices, including active and passive workloads, and reports any unusual or suspicious activity in real time. It can detect events such as process creation, driver loads, registry modifications, disk access, memory access, and network connections. Incident response software can be used to automate the process of finding and resolving security breaches. Networks can monitor cloud connections, infrastructure, and endpoints for intrusions and abnormal activity. They then use the incident response programs to inspect and resolve intrusions and malware in the system. These products can provide capabilities to resolve issues that arise after threats have bypassed firewalls and other security mechanisms. They can alert administrators of unapproved access of applications and networks. Anti-ransomware applications can protect endpoint devices and files from ransomware attacks. Ransomware can be a malicious program that encrypts data on endpoint and network devices and demands a ransom for the decryption key. APT applications can be software tools designed to identify and block sustained endpoint or network cyberattacks in which the intruder establishes an undetected presence in order to steal sensitive data over a prolonged period of time. Networks often use combinations of these third-party applications to provide a comprehensive web of monitoring and protection programs to secure all internal and endpoint users, programs, and data. Many of these applications have overlapping functions that can generate multiple flags and alerts when suspicious activity occurs. In embodiments, the software agent connects to the third-party applications using an application program interface (API) tailored to each application. The software agent can monitor all third-party applications installed on the endpoint device and send the security information details from each of them to the orchestration software when suspicious activity occurs.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HUY C HO whose telephone number is (571)270-1108. The examiner can normally be reached M-F 8AM-5PM.
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, KATHY WANG-HURST can be reached at (571)270-5371. 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.
/HUY C HO/Primary Examiner, Art Unit 2644
Prosecution Insights