In many inventions—particularly in control systems, signal processing, and software—an important feature can be what the system does when something expected to occur does not actually occur. Maybe a motor does not spin up, an actuator does not respond, or a process step is skipped. Applicants often want to claim an invention directed to such situations; but language aiming to cover such features—e.g., “if X should happen and doesn’t, then Y”—presents a multi-pronged challenge involving issues such as:
- Negative claim limitations (claiming the absence of an event).
- Omission of essential elements.
- Heightened § 112 written-description scrutiny.
- Intended-use or functional claiming risk.
- Schulhauser-based ignoring of if-then features as optional.
A recent Patent Trial and Appeal Board (“PTAB”) decision: Appeal 2025-001179, App. No. 17/198,235, illustrates some of these issues—and how an applicant can might address them.
When a claim recites an action that depends on something not happening, examiners may (purposefully) struggle in reaching a proper interpretation, and further may be more prone to cite clarity issues.
The MPEP recognizes this challenge. The MPEP cautions that claims reciting the absence of a structure or absence of a step may give rise to rejections under 35 U.S.C. 112(a) unless the specification supports the claimed absence. Further, enablement may fail where a claim defines an invention in terms of the absence of an element or step unless the disclosure explains how that absence is determined.
Beyond § 112, these claims can veer into intended use territory—especially if the “should happen” part is characterized as aspirational. For example, an examiner may assert that If the claim does not specify how the system detects the failure to occur, for example, it may risks being seen as claiming a goal (e.g., “ensuring reliability”) rather than a technical implementation.
Turning now to the recent PTAB case, the application involved an augmented-reality (AR) system that runs multiple software applications (“first” and “second”) to generate visual overlays. These applications normally execute in a defined order—one overlay feeds into another. But the inventors recognized that sometimes that order could be violated and the system must still decide whether the results remain usable.
Claim 1 recited, in part:
“… wherein the first and second applications are configured to process an augmented display according to an application execution order, wherein the application execution order defines that the second application should process an augmented overlay provided by the first application…
… wherein said executing the second application is performed without providing the first overlay to the second application, whereby said executing the second application violates the application execution order.”
In other words, the claim explicitly covered the case where the second application acts as though it should receive data from the first—but doesn’t.
The examiner rejected claims 1–24 as indefinite (§ 112(b)), arguing that claim 1 “clearly requires the application execution order while also requiring a violation of the execution order.” The examiner also found the claims obvious over several references, which described different AR “skins” executed in varying order.
The Board reversed every rejection.
On indefiniteness, the panel found no contradiction:
“Claim 1 addresses the situation where what should happen does not in fact happen, that is, the order is violated. … Such a scenario is described in the Specification … ‘contrary to the skin execution order that requires to first obtain the previous overlay before generating a next overlay.’ ”
The Board concluded the claim was clear because both the normal and violation cases were defined in the specification.
Regarding obviousness, the Board found that the cited art failed to teach or suggest a system in which something that should happen … does not happen. The prior art described executing applications in different orders, but never one where the system recognizes a violation of a prescribed order and still processes results. All § 103 rejections were reversed.
The decision is instructive on multiple levels:
- Negative events can be claimed — for example, when the specification explicitly describes both (a) what should occur and (b) how the system behaves when it does not, as in this case, it is possible for such claims to have proper written description support. The Board treated the violation case as a legitimate, disclosed system state, not an abstract “non-event.”
- Clarity trumps formal logic. The examiner attempted to create a contradiction in the claim language; the Board saw that specification made a clear distinction between the two conditions (normal and failure). As such, operational contingencies do not create a contradiction in the claim.
- Substance over semantics in § 103. The rejection failed because the art did not disclose any recognition of what should occur.
For practitioners, this case confirms that well-supported “failure-to-occur” claims can survive both § 112 and § 103 scrutiny. Practitioners may consider include both success and failure paths in the detailed description of the specification. If the invention acts when something fails to occur that otherwise should, describe explicitly:
- the expected condition;
- how the system detects non-occurrence (timeouts, missing signals, logic checks); and
- what corrective action follows.
In this way, it can be helpful to explain why the absence of an event expected to occur matters and how technical behavior changes, including linking such changes to a real technical effect. Further, providing at least one example or embodiment of the failure scenario and the corrective action path can be helpful to consider.
Claims directed to actions taken when a condition that should occur, fails to occur, can base successful, and can be supported by careful detailed description and framing. Making an absence as tangible as the presence of something else might seem non-intuitive, but it is possible to turn “nothing happening” into something patentable.

Leave a comment