There's a timing problem buried in malware response. The moment an endpoint flags something suspicious is often the worst moment to scan it — because the detection data and remediation tools that would correctly identify and clean it may be minutes away from an update that makes them far more effective. Scan immediately and you risk acting on stale information; wait too long and the threat runs free. The interesting question is how long to wait, and on what signal to stop waiting.

The grant US10997294B2, "Deferred malware scanning" (assigned to Sophos), turns that timing problem into an explicit, bounded policy. It identifies a suspicious code segment by behavior, deliberately defers the malware scan, and uses the deferral window to wait for fresher intelligence — but never longer than a hard ceiling.

"A code segment executing on a compute instance may be identified as suspicious based on runtime behavior or similar behavioral analysis or the like."— U.S. Patent No. 10,997,294 source

The mechanism rests on two distinct time periods, and the precision of their definitions is the heart of the patent. The independent claim describes "determining a deferral window that provides a predetermined time period to wait between the identification and a malware scan of the code segment," and then "determining a security update deferral time period that is less than the predetermined time period of the deferral window." The second period is defined as "a minimum time to wait between the identification and receipt of a security update for use in the malware scan." One number is a maximum — the longest you'll defer the scan. The other is a minimum — the shortest you'll wait before a freshly arrived update is allowed to count.

The trigger condition that ends the wait is where the design earns its name. After waiting the security-update deferral period, the system performs the malware scan "upon the earlier of expiration of the predetermined time period and a time at which a security update is received from a threat management facility after the security update deferral time period." In other words: scan as soon as a relevant update arrives — but not before a minimum settling time, and not after a maximum deadline. If new intelligence shows up, the system pounces on it; if none does, the scan still happens when the deferral window closes. The waiting is opportunistic, not open-ended.

What gets updated is spelled out. The "security update includes an update to detection data used by the malware scan" in one claim, and "an update to remediation tools for the compute instance" in another. So the deferral isn't merely about waiting for a better verdict — it's also about waiting for better cleanup capability, so that when the system does act it acts with the most current ability to both recognize and remediate the threat.

The patent is careful that deferring the scan does not mean leaving the suspicious code free to run. The claims surround the wait with containment. The code segment can be terminated upon identification as suspicious; it can be quarantined "while waiting the security update deferral time period"; the compute instance can be isolated "from a data network while waiting the predetermined time period"; and local monitoring of the code segment can be adjusted upon identification. The threat is boxed in during the deferral, so the system buys time for fresher tools without ceding ground to the thing it's suspicious of.

Several dependent claims show the deferral being used as productive time rather than idle time. The system can perform "a causal analysis on the compute instance to identify a root cause of the identification" and then remediate that root cause. It can notify the user and even query them "through a user interface... about whether to permit or terminate execution." It can transmit "information about the identification from the compute instance to a remote threat management resource for analysis while waiting the predetermined time period," and that remote resource can generate "security resolution data" — a remediation, a whitelist entry, or "an adjustment to security monitoring for an enterprise network to address a threat." The endpoint's wait becomes the threat management facility's working window: while the endpoint defers, the cloud investigates and can ship back exactly the update the endpoint is waiting for. The full system claim closes the loop, with the threat management facility receiving the endpoint's notification and generating the very detection-data or remediation update that satisfies the scan's trigger condition.

The patent also lets the deferral adapt to the threat. One claim has the identification step "determining a type of potential threat of the code segment," and the next selects the deferral window "based on the type of potential threat" — so a faster-moving or higher-severity threat can be given a shorter ceiling than a low-risk one. The threat management facility can also select the predetermined time period centrally and push it to the endpoint, keeping the policy tunable from one place.

The defensive insight is counterintuitive but sound: against a fast-changing threat, acting a few seconds later with current tools can beat acting immediately with stale ones — provided the wait is contained and bounded. The design refuses the false choice between "scan now on old data" and "wait indefinitely." It contains the suspect, waits a deliberate minimum, scans the instant fresh intelligence lands, and falls back to a hard deadline if it doesn't. The risk it must respect is its own premise — every second of deferral is a second a contained-but-live threat might find a gap — which is precisely why the containment steps and the maximum ceiling are not optional trimmings but the structural guardrails that make a deliberate delay a defensible one.