Routing payment and other data to different screen zones via a single firmware proxy: Technical

The invention relates to displaying payment information.  The Applicant argued that this was done by using a single proxy firmware, which makes a simpler and more secure implementation. Although the Board disagreed that the effect may not be achieved, it was an alternative implementation, which is not to say that it is an obvious one, as the Board does not see that the skilled person would arrive at the solution. 

Here are the practical takeaways from the decision: T 0055/23 (Displaying payment information/INGENICO) of June 27, 2025 of the Technical Board of Appeal 3.5.01

Key takeaways

The invention

The Board defined the invention as follows:

1. The invention in claim 1 of the main request concerns a method for displaying payment information together with other information, for example advertisements (see page 5, lines 1 to 6), on the screen of an electronic payment acceptance device (100). Data from a payment application are routed, by a proxy (121) located in the firmware of the device, to a first zone (111) of the screen (110), while data from other applications (such as an application providing advertisements) are routed by the same proxy to a second zone (112) of the screen (110). As the proxy is located in the firmware, it cannot be bypassed by applications implemented in the application layer (130) of the device.

Claim 1 also specifies that data from the payment application are verified by the proxy before being routed to the first zone of the screen, the verification comprising checking a signature. Thus, the user can be sure that the payment information displayed in the first zone comes from the payment application and not an unauthorised application prompting the user to give away sensitive information.

Fig.2a and 2b of EP 3742373 A1

Is it patentable?

The Examining division alleged that it was obvious over document D5 and interpreted “firmware” as being either a standardised operating environment for the device’s more complex software allowing more hardware-independence, or, for less complex devices, the device’s complete operating system, performing all control, monitoring and data manipulation functions. Thus, the OS of D5 were considered as firmware. However, the Board disagreed and considered as

5. In the Board’s view, the skilled person would understand “firmware” as referring to code that is stored in a non-volatile memory (e.g. ROM or EPROM) of a device and that provides low level control of the device’s hardware. It might well be that, in very simple devices, this code also performs some basic OS functions, but the device in D5 is clearly more complex than that. Thus, in the Board’s view, the skilled person would not understand the operating systems (OS and MC) in D5 as “firmware”.

6. Furthermore, D5 does not disclose sending data from both a secure application and a normal application throughout the same “proxy”. Those applications are rather implemented in different run-time environments (NZ, TZ).

7. Thus, the Board agrees with the appellant that claim 1 differs from D5 by the following features:

a) displaying payment information,

b) a single proxy routing information and verifying the signatures,

c) the localization of this proxy in firmware.

The Applicant argued that the feature provided the technical effect as follows, which the Board did not agree:

9. The appellant argued that features b) and c) together provided the technical effects of a simpler implementation not requiring double run-time environments, and increased security since all data had to go through a check by the firmware proxy.

10. The Board is not convinced of these technical effects. The complexity of the implementation appears rather speculative, and implementing things in firmware has its limitations. At best, this seems to be a trade-off (reduced complexity of the code while accepting the limitations of firmware). Also, the increased security is not necessarily achieved, because all the proxy in claim 1 does is to check whether data comes from the payment application or not, and route the data accordingly. In D5, this is not necessary, as the payment application has its own run-time environment.

However, the Board considered that :

11. Thus, claim 1 rather provides an alternative implementation. That is not to say that it is an obvious one. Starting from D5, the Board does not see that the skilled person would arrive at the solution in claim 1. There is no apparent motivation for the skilled person to do this. While it’s conceivable that the skilled person would generally consider low level solutions involving firmware, he would still have to provide the single “proxy”. This does not appear to be common knowledge. For these reasons, the Board judges that claim 1 involves an inventive step over D5.

Therefore, the Board considered the subject-matter inventive.

More information

You can read the full decision here: T 0055/23 (Displaying payment information/INGENICO) of June 27, 2025 of the Technical Board of Appeal 3.5.01

Please share this article if you enjoyed it!