Drawing the Line: When Does a User Requirement Become Technical?
The Board of Appeal in T 0035/20 clarifies the boundary between non-technical user requirements and technical features in GUI inventions. Discover why Apple's double-press to pay involves technical considerations.
The doctrinal line separating a non-technical user requirement from a technical system feature remains one of the most heavily litigated boundaries under the Comvik framework (T 0641/00). While users are permitted to formulate broad desires for how they interact with a device, Technical Board of Appeal decision T 0035/20 demonstrates that there is a strict limit to what a notional user can demand before their requests cross into technical considerations.
The dual-function biometric button
The application, filed by Apple Inc., sought to simplify contactless payments on a mobile phone. On the closest prior art—the iPhone 6—a user had to first unlock the device using the fingerprint sensor in the home button, and then separately open a payment app to authenticate the transaction using that same sensor (reasons 6).
The claimed invention allowed the user to bypass this sequence. By double-pressing the home button from the lock screen, the device would read the fingerprint, check for the double press within a predetermined time, and if both conditions were met, transition directly into a payment-enabled mode without fully unlocking the phone (reasons 2).
The examining division refused the application for lacking an inventive step (Article 56 EPC). In their view, the double press was merely a user requirement defining "when and how" to enable the payment functionality, which the skilled person would implement as a matter of routine (reasons 7).
Constraining the non-technical user
Board 3.5.01 took a much closer look at what constitutes a "user requirement" in the context of user interfaces. The panel acknowledged that a user, lacking technical understanding, can legitimately formulate broad needs such as "simplify payment" or "pay in as few steps as possible" (reasons 9). A user might even request simple input mappings, such as pressing a specific "pay" button (reasons 10).
However, the examining division had stretched this concept too far by categorising the specific double-click interaction and the reuse of the unlocking authentication as non-technical preferences. The Board held that the constraint not to involve technical considerations limits the extent of such aspects of user requirements (reasons 11).
Demanding a double press on a specific button that simultaneously integrates a biometric sensor is not a simple mapping. Because the home button was already tasked with unlocking the device, reusing it to activate a lock-screen payment mode required technical understanding to determine if the interaction was even possible (reasons 12). The user was effectively dictating a solution that involved technical choices.
Assessing obviousness on a crowded device
Having established that the specific interaction was technical, the Board formulated the objective technical problem as "how to simplify payment with fingerprint authentication" (reasons 14). The panel notably rejected the appellant's attempt to include "increased security" in the problem, categorising the security of the lock screen as a mere bonus effect of the known prior art.
When assessing obviousness, the Board found the claimed solution inventive. The prior art lacked any input mechanism with an integrated sensor performing such a dual function (reasons 16). More importantly, the panel noted that the home button on the iPhone 6 was already "overloaded" with functions. This existing burden would have actively deterred the skilled person from assigning it yet another task, particularly when other lock-screen gestures—such as swiping left to open the camera—were readily available alternatives (reasons 16).
Drawing an analogy to T 1188/04, where oscillating a mouse icon involved technical considerations for graphical user interface implementation, the Board concluded that the specific hardware interaction here went well beyond a mere input mapping (reasons 17–18). The decision was set aside with an order to grant the patent.
Practical implications
When an examining division dismisses a specific user interface interaction as a non-technical "user requirement", practitioners should carefully analyze the hardware context. If the claimed interaction requires reusing an "overloaded" physical input, or if it combines a mechanical input with a simultaneous sensor reading, argue that the feature requires technical considerations to implement. A notional user can ask for a faster payment process, but they cannot dictate the multiplexing of a biometric hardware button. By framing the specific interaction as a technical choice made to overcome hardware constraints, applicants can successfully move the feature out of the non-technical problem formulation and into the technical solution.