EP 2 478 097 B1, published originally as WO 2016/123309 A1, relates to a user interface for payments.
The invention concerns simplifying contactless payment with a mobile phone by removing the need for the user to unlock the device and open the payment app. Also, by enabling payment from the lock screen, the device remains protected while the user pays.
The phone has an input mechanism, called the “home button”, containing an integrated fingerprint sensor. To activate the payment mechanism from the lock screen, the user double presses the home button.
Brief outline of the case
The ED refused the application for breach of Art 123(2) and lack of IS.
The ED essentially argued that the invention was a specification of user requirements about “when and how” to enable the payment functionality of a smartphone which according to the Guidelines G-II 3.7.1 was not technical. Therefore, the problem to be solved was how to implement the user requirement.
The applicant appealed and took AR1 filed with the grounds of appeal as the MR.
The board’s decision
The board noted that the term “user requirement” is often used when assessing the technicality of features of user interfaces. For the board, the term to refer to needs and preferences defined by the end user of a system, who does not possess any technical understanding of the system.
Under the Comvik approach, T 641/00 (COMVIK), such user requirements may appear in the formulation of the technical problem as they do not make any technical contribution. It was confirmed in T 1463/11 that non-technical user requirements cannot normally specify any technical matter or be based on technical considerations.
That is not to say that they cannot refer to the underlying technical system at all. Just like the technically skilled person, the user starts from the technical system of the prior art; user requirements do not appear in a vacuum.
Thus, if the user uses software on a computer, he may formulate non-technical requirements relating to this software, see e.g. T 2019/12.
Analogously, if, as in the present case, the system is a mobile phone, the user may formulate requirements relating to the use of the phone, as long as they do not involve technical considerations or require technical understanding.
In the board’s view, this would cover requirements such as “simplify payment”, “pay faster” or “pay in as few steps as possible”. The user may arguably even formulate the requirement that the device should remain locked, as this does not require any technical understanding of how the phone works internally. In some sense, a lock merely disables a number of functions, and the non-technical user could formulate a requirement along the lines of “enable only payment”.
Furthermore, the board considered that a user requirement may also include simple mappings of user inputs to functions. For example, pressing a button “pay” in order to pay, may be considered a user requirement if the technical means as such are known and the mapping does not involve any further technical effects or considerations.
The examination division essentially considered that user requirements covered all user interactions with the mobile phone, including double clicking within a certain time and using the unlocking authentication for the payment instead of using a separate authentication in the payment app.
These were referred to as aspects of “how” to enable the payment functionality. However, the board considered that the constraint not to involve technical considerations limits the extent of such aspects of user requirements.
The difficulty arises from the fact that some of these requirements, although apparently actions of the user, such as a double click or using the existing way of authentication for payment, involve technical considerations to see if the requirements are even possible.
In other words, the user is saying things that even the skilled person would have to check. In other words, the user is over-stretching the non-technical requirements, going beyond what a “notional” user could require.
In particular, the double press to activate the payment functionality in combination with the fingerprint reading is not a simple mapping of an input to a function. In the board’s view, it involves technical considerations.
Using a button with an integrated fingerprint sensor for both activating the payment functionality and authenticating the payment transaction is a technical choice which goes beyond a mere mapping between input and function.
Using the home button on the iPhone for activating payment from the lock screen was not without technical difficulty, as the same button and fingerprint sensor were already used for unlocking the device.
Those are technical considerations for a technically skilled person, and the solution to use a double press defined by a predetermined time interval between a first and a second press, is a technical solution.
The board considered that the objective technical problem to be solved is “how to simplify payment with fingerprint authentication”.
The solution to the problem of simplifying payment with fingerprint authentication in claim 1 is the double press on the home button to activate the payment functionality in combination with fingerprint authentication of the payment using the fingerprint sensor integrated in the home button.
The board judged that the solution in claim 1 is not obvious.
No prior art discloses an input means with an integrated sensor having a dual function as in claim 1.
The home button on the iPhone is “overloaded” which would have deterred the skilled person from using it for yet another function, especially since there were other alternatives. Other input mechanisms were available to the skilled person for activating a functionality from the locked screen.
The considerations in favour of inventive step appear analogous to those in T 1188/04.
As in the present case, the aim in T 1188/04 originated from the user, whereas the specific interaction was not a mere input mapping but involved technical considerations relating to the implementation of the GUI.
Comments
It must be agreed with the board, that the invention has a clear technical character, and is not obvious. It manifestly goes further than taking into account a “user requirement”.
The decision is interesting and one wonders why a decision issued in 2024 has only be published in.2026.
We just have to wait to see it implemented on a future iPhone™.
Comments
4 replies on “T 0035/20-A user requirement with a technical implementation”
As to your penultimate sentence, it would appear that the Board handling the case has been closed down. Despite the decision having been announced at the oral hearing, and despite three reminders from the applicant, the Board were only in a position to issue the written decision one month before the end of their term with that Board.
Maybe this approaching deadline spurred then into action.
@PP,
Thanks for your comment. Indeed, board 3.5.01 has been shut down on 30.04.2026.
This is probably due to the transfer of business methods and the like to another directorate. Since then, there are hardly any cases ending in appeal, as the examiners have been encouraged to grant.
I think here as well to T 0759/23 commented in the present blog. T 0759/23 was also taken by board 3.5.01.
Good that you highlight this decision. The Board notes that “The home button on the iPhone is “overloaded” (as a key reason for non-obviousness). On the other hand, the Board notes a few sentences before that ” there is no prior art showing an input means with an integrated sensor having a dual function as in claim 1″.
Yet, the CPA is the iPhone 6, which “had a fingerprint sensor integrated in the home button. The fingerprint sensor was used both for unlocking the device and for authenticating contactless NFC payments”. So, the CPA has a home button with a fingerprint sensor. That home button is “overloaded”. Yet, “there is no prior art showing an input means [button?] with an integrated sensor [fingerprint sensor] having a dual function”, according to the Board, and that is a key reason for the Board for inventive step (point 16 of the reasons).
@ VelvetPixel
The case is indeed interesting as it allows the home button to be loaded with a further function.
The home button allows not only to identify the user and thereby give access to the phone, but also to authenticate a transaction on the basis of said finger print with a further action on the button within a given time period.
Before disclosing the invention, the latter was certainly not obvious. With hindsight, everyone is smarter….
I don’t know whether it has ever been patented, but the opening flap of a metal can left sticking to it appears also pretty obvious when one has seen it.