Patenting of applications

The short answer is – it depends on what the App does. As with any other invention, the invention in question must solve a technical problem and fulfill the requirements of novelty and inventive step.

For some Apps the patent adventure might end early because there are already other solutions available solving the same technical problem as the invention with similar means, even though the two Apps may have different overall objectives. It is therefore of great importance to identify and distinguish the technical problem from any business-related problems solved by the App.

With this knowledge at hand, it will be easier for the applicant to decide whether secrecy and copyright protection will be a more favorable approach for protecting the App.

To recognize the reason why it is important to identify the correct technical problem, it is essential to understand the connection between the technical problem solved by the invention and the novelty and inventive step requirements. The link is that only the features of the invention that contributes to solving the technical problem, may be allowed to form the basis for the assessment of the invention's novelty and inventive step.

Identifying the correct technical problem solved by the invention will simplify the process of assessing whether the contributing features combined will be sufficient to fulfill the novelty and inventive step requirements. A correct identification of the technical problem will also enable the applicant to better foresee the extent of potential future patent protection of the invention.

With this in mind, we will now look closer at a couple of examples emphasizing the importance of identifying the technical problem solved without getting lost in the potential business-related problems solved by the respective App.

First up is the decision T 0658/18 Aggregated soft card/MASTERCARD of 13 June 2022. MasterCard International Incorporated ("MasterCard") applied for a patent on an App consisting of an aggregated or multi-component soft card, which is a combination of two or more electronic or virtual cards that are logically linked as a single aggregated soft card that is displayed on a mobile device as a single visual representation. A benefit of logically linking the two or more soft cards into an aggregated one is the ability to use them in a single payment transaction without the need of multiple taps on the card reader.

The idea of replacing physical cards with the provision of soft cards to a mobile device, was already known. Further, the idea of linking a credit card with a loyalty card may be seen as solving a business-related problem, ensuring that customers do not forget to register loyalty points after a purchase is made with the respective credit card. The App presented by MasterCard could therefore not be deemed as solving a technical problem for the above-mentioned reasons.

The technical problem solved by the claimed App was therefore identified as inventing a process of requesting and providing an "aggregated" soft card. This means that only features contributing to the process of requesting and providing an aggregated soft card may form the basis for the App's novelty and inventive step.

In addition, the patent protection will only protect the claimed underlying process of requesting and providing an aggregated soft card. Competitors may therefore still launch similar Apps enabling users to use multiple cards in a single payment transaction without the need of multiple taps on the card reader, provided that their underlying process of requesting and providing an aggregated soft card is not equivalent to MasterCard's solution.

In the specific case, T 0658/18 Aggregated soft card/MASTERCARD, the decision under appeal was set aside and the case was remitted to the first instance for further prosecution, including an additional search for reasons this article will not examine any further.

The second example is the decision T 1098/12 Computer program with limited lifetime/Nokia of 12 July 2017, with the applicant Nokia Technologies Oy. The purpose of the claimed App was to provide a new model for the commercialization of software on "mobile terminals", such as mobile phones. The problem to be solved was enabling the users to try out software on a mobile terminal for a limited time at a lower price.

This problem was considered as a non-technical vending model and therefore, the identified technical problem to be solved had to be the implementation of this vending model by technical means. The implementation of a vending model was considered not to be inventive for a person skilled in the art, thus resulting in the solution not being patentable.

The third and final example is T 1989/12 Calendar-based profile switching / Microsoft of 26 April 2018, with the applicant Microsoft Technology Licensing, LLC. The App comprised of a method of notifying a user of a notification event occurring in a small computer device, such as a phone. The notification may be any number or types of audible signals notifying of events, such as incoming telephone calls, text messages and emails.

The problem to be solved by the App, was that the receiver of the notifications would likely throughout the day be in different situations where specific notifications might not be appropriate, such as loud notifications during a meeting. The App intends to give an optimized alternative to the already known mute button by creating profiles for different situations (for example "General", "Silent", and "Meeting"), determining the desired properties of an event, and assigning varying notification characteristics to that event with the resulting in notifications being appropriate to the different situations.

However, the European Patent Office ("EPO") did not consider this as solving a technical problem. The technical problem solved by the invention had to be the implementation of the method itself. The EPO considered how to implement the needed requirements on a mobile device as obvious for a person skilled in the art. The invention was therefore not patentable.

The mentioned decisions exemplify that even though the App may be great and valuable from a business aspect, this value may still not necessarily give grounds for a patent, resulting in the patent application being rejected or that the extent of the patent protection of a granted patent being less than expected.

If you believe you have invented - or are in the process of inventing - an App consisting of schemes, rules or methods for doing business or playing games, we recommend doing a level-headed evaluation of the technical aspect to identify the technical problem solved by the respective App. If you have any questions, do not hesitate to contact us for more information.