Unless a new device has been developed, most fintech inventions can be characterised, on some level at least, as relating to computer programs or business methods, but typically both. Obtaining European patent protection in this field often requires an acute understanding of a complex area of law.
In Europe, the question of whether a computer-implemented invention is patentable is approached by asking whether the novel part of the invention produces a ‘technical effect’. We are directed to focus specifically on the novel features of the claim with respect to the closest prior art and then ask whether these novel features achieve a technical effect. Any features not contributing to a technical effect will be disregarded in the assessment of inventive step. If a technical effect is not produced, then the invention will be found unpatentable for lacking an inventive step.
So, what might be considered technical?
There is no precise definition of the term ‘technical’. This is by design to take account of the ever-changing nature of technological developments.
For computer-implemented processes we normally look for improvements in the operation of a device or a particular process. Often, we seek to frame the invention as improving data security, reducing consumption of processing resources or enhancing the device’s usability – to name a few examples of accepted technical effects. Higher-level, abstract advantages that could be characterised as administrative improvements, business methods or the presentation of information are unlikely to be considered technical. For example, suppose the advantage relates to a human construct (such as improved financial modelling, debt collection or revenue generation) or is subjective to the user. In that case, it is unlikely to be considered technical.
The boundary between what is technical and what is not can sometimes be subtle. It is helpful to know which effects have previously been recognised as technical by the EPO so that the invention can be presented as falling on the right side of the line. This is easiest to do when drafting the application so that the right details (and buzzwords) can be included in the specification. The following examples are relevant to fintech and show where including the right sort of language and details at the point of drafting an application can make all the difference.
Data security vs data privacy
The EPO distinguishes between protecting data privacy and improving data security, with the latter providing a technical problem while the former is generally considered an administrative scheme.
Data privacy concerns what information to share and not to share (and ensuring that only the information that is intended for sharing is shared). Advantages relating to data privacy are likely to be considered abstract, subjective to the user and therefore non-technical.
In contrast, inventions that improve data security (i.e., prevent unwanted access or interception of data) are likely to be seen as contributing a technical improvement to a device or process.
Therefore, if seeking patent protection for an invention having relevance to data privacy, it is typically best to frame the invention instead in the context of digital security and focus on these advantages if possible.
EPO case law divides fraud detection and prevention into two distinct categories – technical fraud protection, based on understanding a system’s technical element, and non-technical fraud protection, based on business or administrative rules in a payment system or equivalent.
In the case of a technical machine like an ATM, features of a fraud detection mechanism that require an understanding of how the machine operates are likely to be considered technical and may contribute to an inventive step. For example, inventions that detect or prevent machine tampering would be technical.
On the other hand, if no understanding of a technical machine is required to arrive at the fraud prevention scheme, the EPO is unlikely to find it technical. For example, mathematical functions that identify anomalous user behaviour are unlikely to be considered technical.
Therefore, if seeking patent protection for an invention having relevance to fraud detection or prevention, it is important to focus on any parts of the invention requiring knowledge of a technical entity (normally a device).
Tips for ‘mining’ business methods for patentable inventions
It is often the case that in implementing what was initially a high-level business or administrative method (inherently unpatentable in Europe), one or more technical problems that might be patentable are solved. For example, a method for processing a transaction per se is likely to be considered an administrative or business method and, therefore, not technical. However, if non-obvious steps are taken to protect sensitive user data from interception as part of this method or if the method requires fewer messages to be sent in contrast to the prior art (leading to efficiency improvements), the invention is likely patentable.
If what has been innovated is essentially a new business method without any technical problems being at the forefront of the minds of the inventors, it is important to look closely at the implementation of that method. For example, the details of the messaging steps, user verification steps and any other security considerations should be reviewed. If these aspects have not been thought through, it may be too early to draft a patent application. If the envisaged implementation is straightforward and relies heavily on existing infrastructure and known processes without solving a technical problem in the process, then this suggests the idea is unpatentable in Europe. On the other hand, if the idea’s implementation goes beyond ordinary computer programming or involves new hardware or security considerations, then it is more likely to be patentable.
At GJE, we have attorneys specialising in this area. If you would like to know more about how our expertise can help you, you can find my contact details on my web profile here, or please contact us at firstname.lastname@example.org.