Author Archive

Eenforcing a documented workflow across distributed computing entities: technical effect not decided

The application underlying the discussed decision concerns a method for changing software code executed by a production system by combining continuous integration (CI) with a change management computer system (CMCS) to enforce a documented workflow across distributed computing entities. The decisive issue was whether the method steps defining the workflow for checking, testing, and deploying changed software code across a distributed system constituted merely a non-technical change management workflow or involved technical features requiring a more detailed assessment. The Board found that the examining division had insufficiently analyzed the technical character of the individual method steps and remitted the case for further prosecution, including an additional search covering continuous integration.

Here are the practical takeaways from the decision: T 0156/21 (Changing a software code executed by a production system/SAP) of 14 May 2024, of the Technical Board of Appeal 3.5.01.

Key takeaways

When assessing inventive step of a computer-implemented method under the COMVIK approach, the examining division must start from a single piece of prior art and provide detailed reasoning on individual method steps rather than generically dismissing them all as a non-technical workflow. Failure to properly search the relevant technical field (here: continuous integration) and an overly abstract analysis may constitute special reasons for remittal under Article 11 RPBA 2020.

The invention

The Board of Appeal summarized the invention as follows:

The invention relates to a combination of continuous integration (CI) of software development and change management computer systems (CMCS). CI is popular because it fosters creativity and quick development cycles, but does not cover requirements in the area of compliance, such as auditable documentation for regulatory purposes. CMCS are known to enforce a standardized workflow for changing, testing, and deploying of changed software code, including the assignment of tasks to developers, testers, and change managers. It also requires the documentation of all relevant activities in an auditable way that ensures fulfilment of regulatory requirements. The invention proposes a method for changing software code which combines the concept of CI with the safety and quality control of CMCS. The CMCS controls the integration of new code into the source code management computer system (SCMS) as well as the deployment of artifacts (machine code) emerging from the CI/SCMS domain in accordance with a predefined workflow implemented by the CMCS. In particular, the CI uses the CMCS to perform two series of checks which must be met before the method is allowed to continue, verifying the change document identification, the document status (“development approved”), and the developer assignment. Each generated artifact is tested, driven by the CI or CMCS. The verified and tested artifact is then deployed via controlled deployment interfaces to a test system and, upon successful testing and change manager confirmation, to the production system.

  • Main Request - Claim 1

Is it patentable?

The Examining Division’s position

The examining division considered that the method steps of claim 1 defined a change management workflow for software development. It cited D1 (US 2016/378434) and D2 (US 9,965,377) as examples of a conventional distributed information system that disclosed the technical features of the claim. D1 was cited for most features, while D2 was additionally referenced for the transport management system (TMS) that creates a container for artifact deployment. The examining division then defined the technical problem as how to implement the workflow in a conventional distributed information system “such as the one disclosed in D1 or D2.” Based on this reasoning, it concluded that a person skilled in the art would implement the workflow on such conventional systems in an obvious manner, resulting in a lack of inventive step under Article 56 EPC.

The Appellant’s arguments

The appellant argued that the invention addresses a specific technical problem that known continuous integration (CI) systems face: when a large number of small pieces of software are delivered by developers to update the master code, a bottleneck arises in the source code management system. The invention solves this problem by defining different stages of checking and testing and by distributing functionality among the entities of a combined SCMS and CMCS computer system. According to the appellant, all features of claim 1 are inventively combined so as to provide increased security when developers change the software code. The appellant further requested that the case be remitted to the examining division for further prosecution.

The Board’s analysis

The Board identified several fundamental issues with the examining division’s reasoning:

  1. Incorrect application of the problem-solution approach: The examining division combined D1 and D2 in its analysis while the COMVIK approach (T 641/00) requires starting from a single piece of prior art. The examining division cited D1 for most features and D2 for the TMS/container feature, but then framed the problem as implementing a workflow on a system “such as the one disclosed in D1 or D2.” When starting from exemplifying “conventional” prior art, each single cited document must disclose all the features on its own.
  2. Overly abstract analysis: The Board found that the examining division’s approach led to a rather generic or abstract analysis of the invention. Instead, the invention should be analyzed more specifically as either a further development of the revision control system of D1 or a modification to the known continuous integration technique, with a precise analysis of the differences and their effects.
  3. Insufficient reasoning on individual steps: The Board agreed with the appellant that the examining division went too far by considering all method steps of claim 1 to define a non-technical change management workflow without providing enough detailed reasoning on the individual steps. A proper assessment would require explaining the role of each differentiating feature, identifying its technical effect (if any), and explaining how the different entities of the computer system implement particular method steps.
  4. Incomplete search: The Board noted that continuous integration did not appear to have been considered in any detail and expressed doubts whether the search even covered it, as the examining division treated these features as notorious or non-technical. The field of search indicated in the search report was limited to G06Q10 (business methods).

The Board did not substantively discuss the first and second auxiliary requests. The appellant’s primary request at oral proceedings was remittal to the examining division.

Conclusion

The Board set aside the examining division’s decision and remitted the case for further prosecution. It found special reasons for remittal under Article 11 RPBA 2020, because it was not in a position to examine inventive step without a further search being carried out, particularly in the field of continuous integration. The decision underscores that examining divisions must rigorously follow the COMVIK framework: starting from a single prior art document, conducting a precise feature-by-feature analysis, and ensuring that the search adequately covers the relevant technical fields before concluding that method steps are merely non-technical workflow specifications.

More information

You can read the full decision here: T 0156/21 (Changing a software code executed by a production system/SAP) of 14 May 2024, of the Technical Board of Appeal 3.5.01.

Stay in the loop

Never miss a beat by subscribing to the email newsletter. Please see our Privacy Policy.

Privacy policy 
* = Required field

Changing a mobile device’s notification settings based on a user’s location: non-technical

The application underlying the discussed decision concerns a computerized method for automatically changing notification settings on a mobile device based on the user’s inferred availability at a venue. The key feature at issue was the concept of determining a communication context for a venue using the user’s location and historical communication patterns, and then automatically adjusting the device’s notification settings to conform with that context. The Board of Appeal considered this feature to be non-technical, treating it as a non-technical aim that could legitimately appear in the formulation of the technical problem under the Comvik approach.

Here are the practical takeaways from the decision: T 0877/22 (Automatic changing of notification settings/MICROSOFT) of 5 December 2024, of the Technical Board of Appeal 3.5.01.

Key takeaways

The idea of changing a mobile device’s notification settings based on the user’s location in a venue and historical availability patterns is a non-technical aim, even though the final act of changing the settings is itself technical. Features that merely form part of a causal chain leading to a technical change of a device’s state are not automatically rendered technical; the Board termed this reasoning the “technical leakage fallacy” (citing T 1670/07).

The invention

The Board of Appeal summarized the invention as follows:

The invention concerns a computerized method for inferring user availability to communicate through a mobile computing device and automatically adjusting the device’s notification settings. The method analyzes sensor data, such as GPS data, to determine the present location of the mobile device. This location is then mapped to a venue, for example a library, school, or church. Historical communication records associated with that venue are analyzed to identify an availability pattern, relying on a confidence score that must satisfy a defined threshold. The confidence score may depend on factors such as the number of records forming the pattern, the variance within the pattern, and the age of the information. Based on the identified pattern, a communication context is determined for the venue at the present time, indicating which communication modes are available. If the current notification setting on the device does not conform with the determined communication context, the device automatically changes the notification setting to a contextual value. For example, when a user enters a library, the device may automatically switch to silent mode if this has been the user’s previous setting when visiting the library. The venues may also be categorized to assist in determining a communication context when little or no data is available for a specific venue.

  • Claim 1 of the Main Request

Is it patentable?

The Examining Division’s position

The Examining Division found that the method of inferring user availability based on location and an availability pattern for that location was an administrative matter rather than a technical one. It did not contribute to the solution of a technical problem but rather solved the non-technical problem of determining the user’s notification preferences. Furthermore, the idea of providing notifications according to the user’s preferences was considered non-technical, as it did not achieve any technical effect. Accordingly, changing the manner in which the user was notified based on the user’s preferences was a non-technical requirement. The Examining Division concluded that the technical character of claim 1 resided only in the technical implementation of this administrative method on a well-known computerised system comprising a mobile device, means for analyzing sensor data to determine a location, one or more processors, and one or more computer storage media. Such a system was considered to be well known at the priority date (citing documents D1 to D3 and D5), and the implementation of the administrative method would have been obvious for the skilled person, as it merely amounted to changing the device’s settings based on information obtained using the device’s own technical means, including location data and data relating to communication events recorded in the phone.

The Appellant’s arguments

The Appellant argued that automatically changing notification settings on a mobile communication device was technical, as it related to controlling the internal functioning of the device. All claim features defining how this was done were therefore technical features contributing to solving a technical problem. The Appellant further contended that, according to the Comvik approach (T 641/00), the technicality of a feature had to be assessed in its own right, without having regard to the state of the art. Once a feature was found to be technical by its own nature, it entered into the assessment of inventive step using the normal problem-and-solution approach. Determining technicality based on a feature’s contribution over the prior art was, in the Appellant’s view, an impermissible shortcut. The Appellant also argued that the objective technical problem should be realistic and not include pointers to the solution, warning against hindsight. In the present case, the Appellant formulated the technical problem as automatically inferring and implementing the device’s notification settings in a way that reflected socially acceptable behaviour or user preference associated with a given location or venue. The Appellant specifically argued that the following features were technical and contributed to the solution of the technical problem:

  1. Capturing and analysing sensor data to determine the present location of the mobile device.
  2. Associating the location with a venue and determining the availability pattern for that venue to establish a communication context, which was not a simple mapping but involved data processing means and databases.
  3. The availability pattern itself, as it determined criteria for setting the communication context used for changing communication settings.
  4. The confidence score, as it was used for reliably determining the availability pattern.
  5. The last two claim features (determining and automatically changing the notification setting), as they involved controlling and setting functional data of the mobile device as opposed to storing cognitive data (referring to the Guidelines G-II, 3.6.3).

The Board’s analysis

The Board systematically addressed both the Appellant’s interpretation of the Comvik approach and the individual claim features:

On the Comvik approach and technical character

  1. The Board confirmed that the assessment of whether subject-matter has technical character under Article 52(1) EPC (the “first hurdle”) must be made without regard to the state of the art (citing T 258/03 and T 931/95). However, this does not mean that once the first hurdle is passed, the question of technicality no longer arises. The technical contribution of claimed features must then be assessed when examining inventive step (the “second hurdle”).
  2. Computer-implemented inventions pass the first hurdle by definition, but not every such invention necessarily provides a technical contribution supporting inventive step.
  3. The Board identified the Appellant’s reasoning as an instance of the “technical leakage fallacy” (T 1670/07), in which the inherently technical nature of the implementation is inappropriately projected onto non-technical aspects of the underlying problem. The mere fact that a feature is part of a sequence ultimately resulting in a change of a device’s state does not automatically render that feature technical.
  4. Regarding the “realistic problem” argument, the Board clarified that while this applies to a technical problem formulated from technical differences, it does not apply to non-technical requirements. A technically skilled person, starting from prior art, would conceive neither a realistic nor an unrealistic non-technical requirement, since the notional skilled person lacks creativity and expertise outside the relevant technical field. Formulating the problem as implementing given non-technical requirements is realistic by definition.
  5. The Board also noted that formulating the problem in a way that entails direct technical consequences is not excluded under the Comvik approach (citing T 630/11).

On individual claim features

  1. Controlling the notification settings (audial, visual, tactile output) is technical. However, the idea to change the notification mode based on the user’s location and previous settings for that venue is a non-technical aim (citing T 1989/12 for a similar conclusion regarding calendar-based profile switching).
  2. Obtaining the user’s location from a GPS sensor is technical but was known and commonly included in mobile devices at the priority date.
  3. Mapping location data to a venue or category of venues would have been a routine task, e.g., by using a database.
  4. The availability pattern data is not itself technical in the sense of contributing beyond the provision of data required by the non-technical method. While “functional data” (T 1194/97) may serve a technical function, where it merely implements a non-technical requirement, it is not relevant for inventive step.
  5. The confidence score is not a technical feature. It merely ensures data reliability based on straightforward considerations. A business person could readily formulate requirements such as “base the notification settings on the user’s recent activities.” Excluding unreliable or one-off data is a standard measure, since the very notion of a pattern implies repetition.
  6. The final step of automatically changing the settings is technical in nature, but trivial.

On the auxiliary requests

  1. The first auxiliary request added that the notification setting indicates whether a ringtone is set to mute. The Board found this was already covered by the main request reasoning and lacked inventive step for the same reasons.
  2. The second auxiliary request added receiving device state information from other devices in the venue and using it to determine the communication context. The Board agreed with the Examining Division that taking into account the communication preferences of other users is non-technical and part of the problem. The implementation (e.g., via a centralized data collection source) would have been obvious.
  3. The third auxiliary request combined the first and second auxiliary requests. The Board found no synergistic effect between the additional features and rejected it for the same reasons.

Conclusion

The Board dismissed the appeal and confirmed the Examining Division’s refusal. The Board concluded that claim 1 of none of the requests defined an implementation going beyond a straightforward and obvious realization of non-technical requirements on known technical means, and therefore all requests lacked inventive step under Article 56 EPC. The decision reinforces that the idea of adapting a device’s notification behaviour based on location and user patterns is a non-technical concept, regardless of whether it ultimately results in a physical change to device settings. It also provides a clear articulation of the “technical leakage fallacy,” cautioning that the technical nature of an implementation step cannot be projected back onto the preceding non-technical reasoning that motivates it.

More information

You can read the full decision here: T 0877/22 (Automatic changing of notification settings/MICROSOFT) of 5 December 2024, of the Technical Board of Appeal 3.5.01.

Stay in the loop

Never miss a beat by subscribing to the email newsletter. Please see our Privacy Policy.

Privacy policy 
* = Required field

Registration-based enablement: non-technical

The application underlying the discussed decision concerns an electrically heated smoking system equipped with an interface for connecting to an Internet-enabled host to upload and download data and to receive software updates. The decisive feature required that the system is only enabled after registration with an Internet application on the host via a communications link (feature 1.7). The Board of Appeal found that this registration-based enablement feature does not contribute to the technical character of the invention, as it reflects a non-technical business or administrative requirement.

Here are the practical takeaways from the decision: T 1745/23 (Electrically heated smoking system/PHILIP MORRIS) of 6 March 2026, of the Technical Board of Appeal 3.5.01.

Key takeaways

A requirement that a device is only enabled after registration constitutes a non-technical business or administrative constraint that does not contribute to the technical character of the invention. The fact that implementing such a requirement causes a material change in the device’s operational state does not alter the non-technical nature of the underlying concept.

The invention

The Board of Appeal summarized the invention as follows:

The invention concerns an electrically heated smoking system that holds an aerosol-forming substrate and heats it in order to produce an inhalable aerosol. The system includes a housing containing a power supply, such as a lithium-ion battery, electrical hardware in the form of a printed circuit board, and a heating element, such as a heating blade, in contact with a tobacco plug. An interface, for example a USB socket, allows the system to establish a communication link with an Internet-enabled host, such as a personal computer, for uploading and downloading data. This connection also enables software to be downloaded from the host to program the system’s electronic hardware, allowing extended capabilities without requiring complex onboard components. Furthermore, the system is configured to be enabled only after registration via an Internet application on the host. The patent describes this as a security feature, for example when the device is supplied by post. In addition, the patent refers to various business-related applications such as “pay-as-you-smoke” billing, personalized recommendations of smoking articles, and smoking behaviour management.

  • Main request, Claim 1

Is it patentable?

The Opposition Division’s position

This case arises from opposition proceedings, not examination. Two oppositions were filed against the patent by JT International S.A. and British-American Tobacco (Investments) Limited. In a first decision, the Opposition Division revoked the patent on the ground of added subject-matter. That decision was set aside by Board of Appeal 3.2.01 in decision T 2358/19, and the case was remitted for further prosecution. Upon resumption, the Opposition Division decided to maintain the patent in amended form based on auxiliary request 1, finding that claim 1 was novel over D6 (US 2007/0045288 A1) and involved an inventive step. In particular, the Opposition Division considered that feature 1.7 contributed to the technical character of the invention, relying on the reasoning from T 2358/19 that enabling the system only after registration constituted a “security feature” intended to prevent unauthorised use.

The Appellants’ arguments

Both opponents appealed and requested revocation of the patent. Their key arguments on inventive step were as follows:

  1. Feature 1.7 (enabling the system only after registration) does not contribute to the technical character of the invention. Simply entering data, without any verification or evaluation, does not prevent unauthorised use. Under the broad wording of the claim, any user could enter some data and activate the system.
  2. The concept of enabling the smoking system only after registration is not necessarily motivated by technical reasons but may equally be motivated by non-technical business or administrative considerations.
  3. D6 already discloses that the volatilising device can be remotely controlled from the host via a communication link. It would therefore have been obvious for the skilled person to also control the device’s enablement via the same link, making the technical implementation trivial.
  4. The fact that registration is with an “internet application” on an “internet-enabled” host concerns the functionality of the host, which lies outside the scope of the device claim and is irrelevant to the assessment of inventive step.

The Board’s analysis

Novelty

The Board confirmed that claim 1 is novel over D6 (Article 54(2) EPC). Although D6 discloses entering a username or password, it does not clearly and unambiguously disclose that the device as a whole can be used only after registration. At most, such an implicit “registration” might allow for user-specific settings, not full device enablement.

Inventive step: technical character of feature 1.7

The Board disagreed with the Opposition Division and found that feature 1.7 does not contribute to the technical character of the invention:

  1. Feature 1.7 merely requires that the system is enabled after registration, i.e. after the entry of some user or device data. Without any claimed verification or evaluation step, any user, whether authorised or not, could enter data and activate the system. The alleged prevention of unauthorised use is therefore speculative and cannot confer technical character.
  2. The idea of enabling the system only after registration may equally be motivated by non-technical business or administrative considerations. This interpretation is consistent with paragraph [0052] of the patent, which refers to business-related applications such as “pay-as-you-smoke” billing or personalised recommendations.
  3. The Board acknowledged that claim 1, as a device claim, has technical character as a whole. However, this does not mean that every claimed feature contributes to technical character. Feature 1.7 contributes technically only insofar as it implies enablement occurs via the communication link. The concept of enabling the system only after registration itself reflects a non-technical requirement, and the fact that its implementation entails a change in operational state does not alter this assessment.

Inventive step: COMVIK approach and obviousness

Applying the approach from T 641/00 (COMVIK), the Board formulated the objective technical problem as how to adapt the device of D6 to meet the non-technical requirement that it is only enabled as a whole after registration:

  1. D6 already discloses remote control of the device from the host via a communication link. It would have been obvious for the skilled person to also control the device’s enablement via the same link.
  2. The claim does not specify how the enablement is technically realised, so conventional techniques within the skilled person’s common general knowledge must be assumed.
  3. The aspects concerning the “internet application” and “internet-enabled” host relate to the host’s functionality, which falls outside the scope of the claimed smoking system and cannot limit the device claim.

Auxiliary requests

Auxiliary request 1 differed from the main request only in that independent method claim 13 was deleted. Claim 1 was identical and therefore lacked inventive step for the same reasons. Auxiliary request 2 added to feature 1.7 that enabling the system after registration is “a security feature.” The Board found that the notion of “security” in this context is not limited to technical security but equally encompasses non-technical administrative or regulatory-based measures. Labelling such non-technical features as “security” does not confer technical character upon them.

Conclusion

The Board concluded that claim 1 of all three requests lacked an inventive step under Article 56 EPC. The decision of the Opposition Division was set aside and the patent was revoked. This decision illustrates that a feature requiring a device to be enabled only after registration is treated as a non-technical business requirement under the COMVIK framework. Without a claimed technical mechanism for verification or authentication, the mere concept of conditioning device use on prior registration does not contribute to inventive step, even when the claim is directed to a physical device. The straightforward implementation of such a non-technical requirement using known communication means already disclosed in the prior art renders the solution obvious.

More information

You can read the full decision here: T 1745/23 (Electrically heated smoking system/PHILIP MORRIS) of 6 March 2026, of the Technical Board of Appeal 3.5.01.

Stay in the loop

Never miss a beat by subscribing to the email newsletter. Please see our Privacy Policy.

Privacy policy 
* = Required field

Gateways, request generators, and request handlers as standard components: non-technical

The application underlying the discussed decision concerns a data integration system for automating the exchange of data between a heat sub-metering service provider and a real estate administrator in the context of utility billing for multi-apartment buildings. The key features at issue were the data integration components, namely gateways, a request generator, and a request handler, enabling automated push and pull requests between the two data systems. The Board of Appeal considered these features to be a standard computer implementation providing no technical effect beyond the mere automation of a previously manual information exchange.

Here are the practical takeaways from the decision: T 0850/21 (Data integration system/ISTA) of 26 November 2024, of the Technical Board of Appeal 3.5.01.

Key takeaways

Automating the exchange of information between two existing data systems by means of standard computer components such as gateways, request generators, and request handlers does not, in itself, provide a technical contribution beyond the well-known advantages of computerizing a manual task. The improved reliability, availability, and accuracy of data resulting from such automation are inherent consequences of using computers and do not establish inventive step.

The invention

The Board of Appeal summarized the invention as follows:

The invention relates to distributing data between a real estate administrator, who typically bills residents for services such as heating consumption in a multi-apartment building, and a heat sub-metering service provider who actually measures the consumption. Sub-metering is necessary because there is generally only one master meter for the whole building or property. The individual consumption for each apartment is calculated from heat cost allocation meters attached to heating radiators and parameters relating to the property and the apartments as a share of the total consumption. Typically, the administration of the sub-metering is outsourced to a sub-metering service provider, and both parties need to exchange information. In the prior art, this information was exchanged via post or e-mail and entered manually into respective computer systems, a process prone to error and with information not always up to date. Basing the heat cost allocation calculations on obsolete data about the apartments could lead to errors in the calculations for the whole building. The invention seeks to automate the exchange of information such that the real estate administrator data system can pull and push heat cost allocation related data from and to the heat sub-metering service provider data system. This ensures that the data relevant to the heat cost allocation is up to date in both systems, reducing human error. It also facilitates the interaction between the sub-metering service provider and several real estate administrators.

  • Main request, Claim 1

Is it patentable?

The Examining Division’s position

The Examining Division refused the application for lack of inventive step (Article 56 EPC). The division applied the well-established Comvik approach to assess the technical character of the claimed features. It identified the data integration features, specifically the gateways, the request generator, and the request handler, as standard means of automating a known manual process. The division argued that the effects cited by the appellant, namely improved reliability, availability, and accuracy of data, were known advantages of using a computer to automate a manual task. On this basis, the division concluded that it would have been obvious for the skilled person to automate the task of exchanging information between the sub-metering service provider and the real estate administrator, and that the claimed implementation was a straightforward computer automation of a known workflow. The ninth and tenth auxiliary requests were not admitted under Rule 137(3) EPC.

The Appellant’s arguments

The appellant argued that the claimed invention provided a specific technical improvement by ensuring the reliability, availability, and accuracy of the exchanged data, resulting in a more accurate heat cost allocation calculation. The appellant further contended that the specific implementation of the data integration system, using gateways, request generators, and request handlers, ensured both data security and protection of personal information, which should be recognized as a technical contribution. During oral proceedings before the Board, the appellant also argued, somewhat contradictorily according to the Board, that the solution in claim 1 was not obvious since allowing the real estate administrator to push data into the sub-metering service provider database caused security issues that a skilled person would not have accepted. Additionally, the appellant argued that a proper discussion of inventive step starting from D5 had not taken place until the oral proceedings in appeal, justifying the filing of a new second auxiliary request at that stage. The appellant also requested reimbursement of the appeal fee, alleging that the examining division’s decision was insufficiently reasoned and that its right to be heard had been violated.

The Board’s analysis

Starting point for inventive step

The Board agreed with the appellant that D5 (EP 1971055 A2), which relates specifically to sub-metering and heat cost allocation, provided a better starting point for the inventive step analysis than D1 (US 2004/113810 A1), which the examining division had used. D5 essentially discloses the conventional sub-metering system as described in the introductory portion of the application, including heat cost allocation meters in apartments that can transmit data automatically.

Main request

  1. The Board found that the distinguishing features over D5 (and the conventional sub-metering context) were limited to the data integration features: the gateways between the two computer systems, the request generator, and the request handler. The concepts of “pulling” cost allocation data and “pushing” property-related data already existed in the conventional (manual) workflow.
  2. The Board considered that the implementation by means of gateways, a request generator, a request handler, and electronic push/pull requests constitutes a standard computer implementation. No technical effect could be derived beyond providing a computer automation of the information exchange between the two systems.
  3. Regarding the appellant’s argument on data security, the Board held that there is nothing in the claimed implementation that makes the system more secure, and that the protection of privacy is not a technical effect. Regarding the argument that the skilled person would not have considered pushing data due to security risks, the Board noted that the invention merely accepts this foreseeable disadvantage rather than overcoming it, which does not involve an inventive step.
  4. The Board concluded that claim 1 of the main request lacks an inventive step (Article 56 EPC).

Auxiliary requests

  1. First auxiliary request (adding that the pushed data comprises data related to consumption units): The Board found that the known method of calculating heat cost allocations already used such data. Any improved accuracy was a mere consequence of automating the information exchange, which was considered obvious.
  2. Second auxiliary request (filed during oral proceedings, adding automatic updating upon data change): Not admitted under Article 13(2) RPBA 2020. The Board found no exceptional circumstances and noted the added features were already taken into account in the assessment of higher-ranking requests.
  3. Third auxiliary request (adding a system of foreign data identifiers): The Board agreed with the examining division that this was a straightforward database implementation for identifying data across both systems.
  4. Fourth auxiliary request (only a subset of RA data stored at SP): Considered motivated by administrative/privacy considerations rather than technical ones.
  5. Fifth auxiliary request (request generator generates requests automatically): Already covered by the reasoning for the main request.
  6. Sixth auxiliary request (adding data identifier maintenance requests): Data management was not considered a technical effect per se.
  7. Seventh and ninth auxiliary requests (specifying cost allocation calculation and billing facilitation): The calculation of cost allocation was already known from the prior art.
  8. Eighth auxiliary request (multiple groups of properties with different RA systems): Adapting the system to handle multiple real estate administrators was considered an obvious administrative choice with straightforward implementation.
  9. Tenth and eleventh auxiliary requests: Not admitted under Article 12(6) RPBA 2020 as they had not been admitted by the examining division under Rule 137(3) EPC, and no error in discretion was demonstrated.

Reimbursement of appeal fee

The Board acknowledged some deficiencies in the decision under appeal but found none so serious as to warrant setting aside the decision and remitting to the examining division. The Board noted that the examining division provided a logical chain of reasons and applied the Comvik approach properly. The request for reimbursement of the appeal fee was rejected.

Conclusion

The appeal was dismissed. The Board found that all claims across the main request and auxiliary requests lacked inventive step under Article 56 EPC. The core reasoning was that automating the known manual exchange of information between a heat sub-metering service provider and a real estate administrator by means of standard computer components (gateways, request generators, request handlers, push/pull requests) constitutes an obvious computer implementation. The claimed features provided no technical effect beyond the well-known benefits of computerization, namely increased speed, accuracy, and reduced human error. The additional features introduced in the auxiliary requests, including foreign data identifiers, data subsets for privacy, automatic request generation, and multi-administrator support, were each found to be either non-technical in nature or straightforward implementations that would have been obvious to the skilled person.

More information

You can read the full decision here: T 0850/21 (Data integration system/ISTA) of 26 November 2024, of the Technical Board of Appeal 3.5.01.

Stay in the loop

Never miss a beat by subscribing to the email newsletter. Please see our Privacy Policy.

Privacy policy 
* = Required field

Arbitrary size reduction and antenna placement: non-technical

The application underlying the discussed decision concerns a hearing aid comprising a rigid printed circuit board (PCB) with an indentation at its edge to accommodate at least part of an antenna terminal from a separate flexible printed circuit board. The features at the center of the decision were the “indentation” features (h) to (j), which the Board found did not credibly achieve any technical effect, such as size reduction or correct antenna placement, over the entire breadth of the claim. Because no credible technical effect could be established, the Board treated these distinguishing features as arbitrary modifications of the prior art that could not contribute to inventive step.

Here are the practical takeaways from the decision: T 0094/24 (Indentation in a hearing aid/GN HEARING) of 19 January 2026, of the Technical Board of Appeal 3.5.05.

Key takeaways

Even purely technical features are treated as arbitrary, non-functional modifications that cannot support an inventive step if they do not credibly achieve a technical effect over the whole scope of the claim. The Board confirmed that this principle, often associated with the COMVIK approach for mixed-type inventions, applies to all inventions regardless of technical field.

The invention

The Board of Appeal summarized the invention as follows:

The opposed patent relates to a hearing aid comprising an antenna arranged on a flexible printed circuit board (FPCB). A perennial challenge in hearing aid design is minimizing physical size while ensuring robust mechanical and electrical connections. The patent proposes a specific assembly geometry between the hearing aid’s rigid PCB, which carries signal-processing electronics, and the antenna-carrying FPCB. The rigid PCB is provided with an “indentation” (a recess or cut-out) at its edge. The antenna terminal on the FPCB is connected to a pad on the rigid PCB at an angle between 30 and 150 degrees, and at least part of the terminal is accommodated within the indentation. According to the patent, this arrangement facilitates compact connections compared to traditional surface-mount or wire-bridged solutions.

  • Main request - Claim 1 (patent as granted)

Is it patentable?

The Opposition Division’s position

The Opposition Division rejected the opposition and maintained the patent as granted. It considered document D2 (US 2015/0036854 A1) as a suitable starting point and noted agreement between the parties that features (h) to (j), relating to the indentation accommodating at least part of the antenna terminal, were the sole distinguishing features over D2. The Opposition Division found that these features provided a sufficient technical contribution to establish an inventive step.

The Appellant’s arguments

The opponent (appellant) argued that features (h) to (j) did not provide an inventive step over D2. Its core argument was that if there is no credible technical effect, there is no technical contribution, and therefore no inventive step. The opponent demonstrated with specific examples and drawings that the broad claim wording, particularly “accommodating at least a part”, allowed for embodiments where none of the alleged effects (size reduction, correct placement, alignment) would be achieved. For instance, a wide notch accommodating a narrow terminal results in a “floating” configuration with no mechanical support.

The Board’s analysis

Credibility of alleged technical effects

The Board assessed whether the alleged effects of features (h) to (j) were credibly achieved over the whole scope of claim 1. The proprietor alleged three effects: size reduction, correct placement, and correct alignment. The Board found none credible:

  1. No credible “correct placement”: The expression “at least a part” allows “laterally unconstrained” embodiments where the indentation is significantly larger than the terminal, providing no mechanical guidance.
  2. No credible “alignment”: Claim 1 does not require the terminal to be parallel to the PCB surface. A terminal at a significant skew angle still falls within the claimed scope.
  3. No credible “size reduction”: The claim encompasses embodiments where the indentation is in a raised portion of the PCB (potentially increasing Z-height), and large indentations may require enlarging the PCB footprint.

Arbitrary features and inventive step

Since no credible technical effect was established, the Board concluded that features (h) to (j), while undoubtedly technical in nature, did not credibly contribute to solving a technical problem. Citing extensive case law (T 37/82, T 176/97, T 746/22, and many others), the Board held that such features are “arbitrary” or “non-functional” modifications that cannot support an inventive step, even if the skilled person would never think of such a modification.

Auxiliary requests and referral

  1. Auxiliary requests 1-3 were not admitted under Article 13(2) RPBA (no exceptional circumstances). The Board also found them not prima facie allowable: request 1 (indentation dimensions) still left the “floating” problem unresolved; request 2 (negative limitation excluding raised portions) raised concerns under Articles 84, 123(2) EPC and G 1/03; request 3 (specifying “solder”) involved an arbitrary choice of a standard material.
  2. Referral to the Enlarged Board: The proprietor argued the Board’s approach was a “novel doctrine” unique to Board 3.5.05 and limited to mixed-type (COMVIK/software) inventions under G 1/19. The Board refused the referral, confirming this principle is consistently applied across all technical fields and represents decades of established jurisprudence, not a departure from G 1/19 or G 2/21.

Conclusion

The Board set aside the Opposition Division’s decision and revoked the patent. Features (h) to (j) did not credibly achieve any technical effect over the whole scope of claim 1 and thus constituted arbitrary modifications that could not contribute to inventive step under Article 56 EPC. This decision is notable for its explicit confirmation that the principle of treating features without credible technical effect as arbitrary applies to all inventions, extending the reasoning familiar from COMVIK and G 1/19 well beyond mixed-type computer-implemented inventions.

More information

You can read the full decision here: T 0094/24 (Indentation in a hearing aid/GN HEARING) of 19 January 2026, of the Technical Board of Appeal 3.5.05.

Stay in the loop

Never miss a beat by subscribing to the email newsletter. Please see our Privacy Policy.

Privacy policy 
* = Required field

Double-pressing a physical input mechanism to activate a payment mode: technical

The application underlying the discussed decision concerns a method for enabling contactless NFC payment on a mobile phone directly from the lock screen by using a double press on a home button with an integrated fingerprint sensor. The key feature under scrutiny was whether the specific interaction of double-pressing the physical input mechanism to activate payment mode, as distinguished from a single press to unlock, constitutes a mere non-technical “user requirement” or a technical contribution. The Board of Appeal found this feature to be technical, as it involves technical considerations that go beyond a simple input-to-function mapping.

Here are the practical takeaways from the decision: T 0035/20 (Double press to pay/APPLE) of 17 May 2024, of the Technical Board of Appeal 3.5.01.

Key takeaways

A user interface interaction that combines a physical input mechanism with an integrated sensor reading (here: double press on a home button with a fingerprint sensor) goes beyond a mere “user requirement” and constitutes a technical contribution when it involves technical considerations about reusing existing hardware for a new function. While non-technical user requirements may be relegated to the problem formulation under the Comvik approach, requirements that presuppose technical understanding of the underlying system cannot be treated as non-technical.

The invention

The Board of Appeal summarized the invention as follows:

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. By enabling payment from the lock screen, the device remains protected while the user pays. The phone has an input mechanism (a “home button”) containing an integrated fingerprint sensor. To activate the payment mechanism from the lock screen, the user double presses the home button. The device detects the first press, reads the fingerprint, and determines whether the read fingerprint matches an enrolled fingerprint. The device also detects if there is a second press within a predetermined time (e.g., 300 ms) after the first press. If there is no second press, the device merely unlocks. If, however, both conditions are met (fingerprint match and double press), the device is enabled for contactless NFC payment while remaining locked. Thus, the user input required to pay (a double press) is distinguished from the user input to merely unlock the device by simply placing a finger on the fingerprint sensor, optionally combined with a single press on the home button.

  • First auxiliary request (final main request), Claim 1

Is it patentable?

The Examining Division’s position

The Examining Division considered that the claimed invention represented a user requirement definition of “when and how” to enable the payment functionality of a well-known smartphone. It referred to the Guidelines for Examination at G-II 3.7.1, treating the entire specification of user interactions (double clicking within a certain time, using the unlocking authentication for payment instead of a separate authentication in a payment app) as non-technical user requirements. According to the Examining Division, these user requirements were simply given to the skilled person to implement, and the implementation itself would have been obvious. Therefore, the Examining Division concluded that an inventive step was lacking under Article 56 EPC.

The Appellant’s arguments

The Appellant argued that the distinguishing features produced technical effects, namely faster activation of the payment functionality and improved security. On this basis, the Appellant formulated the objective technical problem as “how to provide a more efficient electronic device for contactless payments with enhanced transaction security.” The Appellant further explained that 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. The home button was “overloaded,” meaning it already served multiple functions, which would have deterred the skilled person from assigning yet another function to it. The Appellant also pointed to the absence of any prior art showing an input means with an integrated sensor having the claimed dual function.

The Board’s analysis

Scope of “user requirements” under the Comvik approach

The Board provided a detailed analysis of the term “user requirement” as it is used when assessing the technicality of user interface features:

  1. Under the Comvik approach (T 641/00), user requirements may appear in the formulation of the technical problem because they do not make a technical contribution. A “user requirement” refers to needs and preferences defined by the end user, who does not possess any technical understanding of the system.
  2. Non-technical user requirements cannot normally specify any technical matter or be based on technical considerations (T 1463/11). However, they do not appear in a vacuum. A user may formulate requirements relating to the use of the underlying technical system (e.g., a mobile phone), as long as these requirements do not involve technical considerations or require technical understanding.
  3. Legitimate non-technical user requirements would include requests such as “simplify payment,” “pay faster,” or “pay in as few steps as possible.” The user may even require that the device should remain locked, as this does not require technical understanding of the phone’s internal workings.
  4. A user requirement may also include simple mappings of user inputs to functions, for example pressing a “pay” button in order to pay, if the technical means are known and the mapping does not involve further technical effects or considerations.

The double press feature is not a mere user requirement

  1. The Board disagreed with the Examining Division’s broad classification of all user interactions as non-technical user requirements. The constraint that user requirements must not involve technical considerations limits their scope.
  2. Requirements such as “use a double click” or “reuse the existing authentication for payment” involve technical considerations, because even a skilled person would have to verify whether these requirements are technically possible. In other words, the user is “over-stretching” non-technical requirements, going beyond what a “notional” user could require.
  3. The double press to activate payment in combination with fingerprint reading is not a simple mapping of an input to a function. Using a button with an integrated fingerprint sensor for both activating the payment functionality and authenticating the payment transaction is a technical choice that goes beyond mere mapping.
  4. 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. These are technical considerations for a technically skilled person.

Objective technical problem and inventive step

  1. The Board formulated the objective technical problem as “how to simplify payment with fingerprint authentication.” It did not accept the Appellant’s formulation that included “enhanced transaction security,” reasoning that increased security was provided by the known lock mechanism and was at best a “bonus effect” that cannot alone render an invention inventive.
  2. The Board found the solution (double press on the home button to activate payment, combined with fingerprint authentication via the integrated sensor) to be non-obvious for two reasons:
    1. No prior art showed an input means with an integrated sensor having the claimed dual function. This was different from, e.g., single and double mouse clicks, which do not involve considerations of the input command in combination with a sensor reading.
    2. The home button on the iPhone was already “overloaded” with functions, which would have deterred the skilled person from using it for yet another function, especially since alternative input mechanisms existed on the iPhone 6 (e.g., swiping to open the camera from the lock screen).
  3. The Board drew an analogy to T 1188/04 (Graphical user interface/SHARP), where a shortcut using oscillation of a dragged icon was found inventive. In both cases, the aim originated from the user, but the specific interaction was not a mere input mapping but involved technical considerations relating to the implementation.

Other requests

The original main request was withdrawn by the Appellant during oral proceedings as it was broader than the refused main request. The second and third auxiliary requests, as well as the fourth and fifth auxiliary requests filed later, did not need to be considered since the first auxiliary request (the final main request) was found to involve an inventive step.

Conclusion

The Board set aside the Examining Division’s refusal and remitted the case with the order to grant a patent based on claims 1 to 13 of the first auxiliary request. The decisive factor was the Board’s finding that the double press interaction on a home button with an integrated fingerprint sensor to activate contactless payment, while simultaneously distinguishing this action from unlocking the device, involves genuine technical considerations. It cannot be dismissed as a mere non-technical user requirement under the Comvik approach. The solution was non-obvious because no prior art suggested using an input mechanism with an integrated sensor for such a dual function, and the skilled person would have been deterred from further overloading the already multi-purpose home button.

More information

You can read the full decision here: T 0035/20 (Double press to pay/APPLE) of 17 May 2024, of the Technical Board of Appeal 3.5.01.

Stay in the loop

Never miss a beat by subscribing to the email newsletter. Please see our Privacy Policy.

Privacy policy 
* = Required field

Using a blockchain to log supply-chain custody transfers: non-technical

The application underlying the discussed decision concerns a system that uses blockchain encryption technology to record and maintain the chain-of-custody of physical or digital products as they move through a supply chain. The key features at issue were the use of a blockchain to log supply-chain custody transfers, including product registration, documentation of custody changes, and quantity verification at each transfer point. The Board concluded that these features lacked technical character, as they merely defined business content recorded on known blockchain infrastructure without improving the underlying technology.

Here are the practical takeaways from the decision: T 2078/22 (Blockchain storing supply-chain data/STOLLMAN AND MATEEV) of 19 November 2025, of the Technical Board of Appeal 3.5.01.

Key takeaways

Recording supply-chain custody transfer data on a blockchain does not constitute a technical contribution under the EPC, as it merely defines business content stored on known blockchain infrastructure. Applying the Comvik approach, the Board held that neither the choice of what data to record nor operational design choices such as who records a transaction or when involve technical considerations.

The invention

The Board of Appeal summarized the invention as follows:

The invention applies blockchain technology to record the movements of a product through a supply chain. The blockchain (or “chain-of-custody data file configured to use blockchain encryption technology”) contains the full history of a product’s transfers between parties (“agents”) in the supply chain. Agents run a client application that enables them to submit digitally signed transactions (“linked changes”) to the blockchain. The blockchain is initiated by the product’s manufacturer, who creates its genesis block (“initial custody record”) that identifies the product and its initial quantity supplied. Subsequently, each transfer of a quantity of the product is recorded on the blockchain by a receiving agent. Independently of the above, the invention generates reports (“change records”) detailing the product transfers and provides them to the agents involved. At each change of custody, the system confirms that the quantity transferred by an agent does not exceed the quantity they previously received, thereby detecting potential counterfeiting, gray-marketing, or product dilution. If an anomaly such as a quantity discrepancy is detected, the system triggers an alert and identifies the responsible agent.

  • Claim 1 of the first auxiliary request

Is it patentable?

The Examining Division’s position

The Examining Division refused the application for lack of inventive step (Article 56 EPC). It considered that the claims of the main request and all six auxiliary requests did not involve an inventive step over a notoriously known blockchain system, as evidenced by document D2, a Wikipedia entry on “Blockchain” published on 7 August 2015. The Examining Division took the position that the features defining what data is stored on the blockchain (i.e., the supply-chain content such as product registration, custody transfers, and quantity tracking) did not improve the known blockchain technology in terms of security or otherwise. Rather, these features merely used a known blockchain to record a particular business content. The design choice of assigning the creation of a blockchain entry to the receiving agent was found not to be based on any technical considerations, but rather on non-technical considerations relating to who records the product transfer and when. Similarly, using separate blockchains for product components, generating reports for agents, and recording sensor data on the blockchain were found to either lack technical character or constitute obvious implementations of non-technical business requirements.

The Appellant’s arguments

The Appellant argued that recording data documenting how a product moved within a supply chain onto a distributed blockchain eliminated the possibility of compromising supply-chain data through a single attack, thus providing the technical effect of assuring the integrity of the recorded supply-chain data. For the second auxiliary request, the Appellant contended that having the receiving party record a product transfer, rather than the transferring party as in conventional cryptocurrency blockchains, was a technical design choice that improved the security of supply-chain operations. For the fourth auxiliary request, the Appellant argued that maintaining separate blockchains for product components enabled tracking ownership changes at a more granular component level, ensuring integrity of supply-chain data more effectively. Regarding the fifth and sixth auxiliary requests, the Appellant submitted that sending reports to parties involved in product transfers and alerting multiple parties of policy violations improved the integrity and security of the supply chain. For the seventh auxiliary request, the Appellant argued that tracking product integrity through the supply chain using sensors enabled automatic alerts indicating when and where adverse conditions occurred, with these alerts being recorded on the blockchain. Finally, the Appellant filed a new main request during the appeal proceedings, intending to shift the invention from a distributed blockchain to a centralised database to distinguish it from the Bitcoin blockchain disclosed in D4.

The Board’s analysis

Choice of closest prior art

The Board preferred to start its inventive step analysis from document D4 (“Bitcoin and Beyond: A Technical Survey on Decentralized Digital Currencies,” published 15 May 2015) rather than from the Wikipedia entry D2 used by the Examining Division. D4 discusses the security features of blockchain technology in greater detail, including the use of digital signatures and distributed transaction logs. As D4 already disclosed the distributed nature of the blockchain and the use of digital signatures to ensure data integrity, the Appellant’s arguments emphasising these features as advantageous were no longer relevant.

First auxiliary request (main focus)

The Board identified three groups of distinguishing features over D4:

  1. Feature A: The blockchain’s genesis block indicates a product and its initial quantity, and subsequent transactions record how the product moves within the supply chain (features 1.3.1, 1.3.2, 1.3.3). The Board agreed with the Examining Division that this feature merely defines the blockchain’s business content and lacks technical character. It does not improve the known blockchain technology in terms of security or otherwise but merely uses it to record particular business content.
  2. Feature B: Generating reports indicating product transfers and confirming that the quantity transferred does not exceed the quantity previously received (feature 1.3.4). The Board found this to be a business feature with no technical implementation and, therefore, no technical contribution. Even assuming that reports are provided to supply-chain parties to assist in detecting irregularities, this is a purely business effect.
  3. Feature C: The server computer and the application it runs (feature 1.2). As long as the server application is not used, this feature has no technical effect. Even assuming it is used to register a new agent, applying the Comvik approach (T 641/00), this would be an obvious implementation of the business requirement to enable such a registration.

The Board also noted potential added subject-matter and clarity issues with features 1.2.2, 1.2.3, and 1.3 (use of cryptographic techniques to detect attempts to compromise data integrity), but interpreted them as referring to the use of asymmetric cryptography to sign blockchain transactions and proceeded with the inventive step analysis.

Second to seventh auxiliary requests

  1. Second auxiliary request (registering acceptance by the receiving agent): The Board found that this design choice was not based on technical considerations but merely involved non-technical considerations relating to who records the product transfer and when.
  2. Third auxiliary request (use of encryption key pairs to sign transactions): This was already disclosed in D4, section 2.4.
  3. Fourth auxiliary request (separate blockchains for product components): The Board agreed with the Examining Division that this was a business requirement, as the advantage of tracking at a component level rather than a product level is of a purely business nature.
  4. Fifth auxiliary request (sending reports to agents involved in transfers): This lacked technical character for the same reasons given for feature B of the first auxiliary request.
  5. Sixth auxiliary request (reporting policy violations to parties within and outside the supply chain): This was a further business idea whose implementation was not really claimed. Even assuming it contributed to preventing commercial abuse, this remained a purely business effect.
  6. Seventh auxiliary request (recording product damage on the blockchain using sensors): Recording what information to store on the blockchain lacked technical character. The use of a sensor (e.g., a camera) to capture damage was an obvious implementation of the non-technical requirement to record evidence of it, as sensor-based monitoring architectures were commonly known at the priority date, as also evidenced by documents D3 and D5.

Late-filed main request

The Board accepted that the introduction of new prior art D4 could constitute an exceptional circumstance under Article 13(2) RPBA. However, the late-filed main request gave rise to new objections under Article 123(2) EPC, as several claim features significantly paraphrased the description rather than being literally disclosed. In particular, the concepts of “each change in status of said agent identifier” and “source exogenous to said at least one host compute device” extended beyond the supporting passages in the application. The Board therefore did not admit the main request into the proceedings.

Conclusion

The Board dismissed the appeal in its entirety. The late-filed main request was not admitted into the proceedings under Article 13(2) RPBA because it introduced added subject-matter (Article 123(2) EPC). All auxiliary requests (first through seventh) were found to lack inventive step (Article 56 EPC) because the features distinguishing them from the prior art D4 were either non-technical business features (defining what data to store on a blockchain, who records a transaction, or what reports to generate) or obvious implementations of non-technical business requirements (using known sensors to monitor product condition). The decision underscores that using blockchain technology to record supply-chain data does not, by itself, constitute a technical improvement to blockchain technology but amounts to specifying non-technical business content for a known technical infrastructure.

More information

You can read the full decision here: T 2078/22 (Blockchain storing supply-chain data/STOLLMAN AND MATEEV) of 19 November 2025, of the Technical Board of Appeal 3.5.01.

Stay in the loop

Never miss a beat by subscribing to the email newsletter. Please see our Privacy Policy.

Privacy policy 
* = Required field

Determining personalized content to be inserted into a phishing document template: non-technical

The application underlying the discussed decision concerns a method for the automated creation of personalized phishing documents, intended for corporate security awareness training, that uses two separate databases and a hierarchical matching process to select tailored content for a target person. The central features at issue were the hierarchically organized property database with associated relevance values and the multi-step selection process (features M3 to M13) for determining suitable personalized content to be inserted into a phishing document template. The Board considered these features to be non-technical, characterizing them as a “business method” for selecting cognitive content aimed at psychologically deceiving the document recipient.

Here are the practical takeaways from the decision: T 1908/23 (Personalisiertes Phishing-Dokument/IT-SEAL) of 17 September 2025, of the Technical Board of Appeal 3.5.05.

Key takeaways

A hierarchical database structure and relevance-value-based matching process used to select personalized cognitive content for phishing simulation documents constitutes a non-technical “business method” under the COMVIK approach (T 641/00). The mere use of technically undefined database structures and parameter comparisons does not establish a technical contribution sufficient for inventive step when the underlying purpose is selecting psychologically effective content for a human recipient.

The invention

The Board of Appeal summarized the invention as follows:

The invention relates to a method for the automated creation of phishing documents that are personalized to a specific target person, primarily for use in corporate security awareness training. Personal data of the target person is stored in a personal database, while anonymous and categorizable personal properties of any number of persons are stored in a separate, hierarchically organized property database. Each property in the property database is assigned a relevance value. The method performs an automated comparison to check whether any of the target person’s properties (called “correspondence properties”) are hierarchically subordinate to a phishing-document-specific default property. If so, the subordinate correspondence property becomes a “creation property.” In a subsequent creation step, the system checks whether the relevance value of the creation property matches a predefined target relevance value. If it matches, the creation property is used directly as a “preparation property” for the phishing document. If it does not match, a hierarchically superior property whose relevance value does match is selected instead, ensuring that a personalized term is always available. The phishing document is then generated based on a template document using the selected preparation property. For example, if a person is associated with “TU Darmstadt” but the template requires a more general term, the system would traverse the hierarchy upward and select “University” instead.

  • Main Request - Claim 1 of the patent as granted (translation)

Is it patentable?

The Opposition Division’s position

The Opposition Division revoked the patent for lack of inventive step under Article 56 EPC. Starting from D1 (US 2015/0288717 A1), which already disclosed a method for the automated creation of phishing documents directed at specific persons, the Opposition Division found that the distinguishing features M3 to M13 merely represented a modification of the underlying “business method” of D1’s system. In particular, the hierarchically organized property database, the relevance values, and the multi-step property selection and matching process were considered to define a non-technical content-selection strategy rather than a technical improvement. Since the remaining technical implementation was deemed obvious, the patent was revoked.

The Appellant’s arguments

The patent proprietor (Appellant) argued that the distinguishing features should not be dismissed as merely non-technical. In particular, the Appellant contended that:

  1. Feature M2 (the personal database) must not be considered in isolation from feature M3 (the hierarchically organized property database), because the use of two databases with different structures was driven by technical considerations. Personal data such as names and affiliations cannot be hierarchically organized, necessitating a separate personal database, whereas the property database benefits from hierarchical organization for efficient automated matching.
  2. From a purely non-technical perspective, there would be no advantage in using two databases; the two-database architecture therefore reflects a technical design choice aimed at enabling “simple and efficient determination of creation properties.”
  3. The hierarchical tree structure (e.g., “professional affiliation – University – TU Darmstadt”) ensures that a solution for adapting the template document is always found, even without a highly relevant direct match. If, for example, “TU Darmstadt” does not match with sufficient relevance, the system traverses the hierarchy upward to select “University” instead, guaranteeing that personalized content is always available.

The Board’s analysis

The Board dismissed the appeal and confirmed the revocation. Its reasoning was as follows:

  1. D1 already discloses a method for the automated creation of personalized phishing documents (feature M1). D1’s paragraph [0070] mentions that the internet provides an easy way to collect information about target persons and that data collection can be automated. A “personal database” is neither mentioned nor strictly necessary in D1, but the Board considered this immaterial given the overall assessment.
  2. Even assuming that all of features M2 through M13 are distinguishing features over D1, the Board found that claim 1 follows a prescribed “business method” concerned with selecting the cognitive, i.e., non-technical, content for a personalized phishing document. The purpose is to psychologically deceive the recipient into trusting the document, thereby training personnel against real phishing attacks. Whether a recipient perceives the term “University” as more trustworthy than “TU Darmstadt” is a matter of human cognition, not technology.
  3. The Board held that abstract, technically undefined units such as a “personal database,” a “hierarchically organized property database,” “relevance values,” and various types of “properties” (correspondence, creation, preparation) cannot credibly lead to “simple and efficient” data determination or “high-quality” phishing documents based on their cognitive content. The claim does not specify what technical effect the hierarchical organization has on the method steps or how the hierarchy is technically structured (e.g., no tree structure is actually claimed).
  4. Applying the COMVIK approach (T 641/00, headnote II), the Board concluded that the objective technical problem is merely to implement the above-defined business method in a technically efficient manner.
  5. Starting from this objective problem, it would be a routine measure for the skilled person in digital security technology to use some form of property matching with relevance values stored in a (separate, hierarchical) property database. Hierarchical databases as such were common general knowledge at the relevant date, which the Appellant did not dispute. Likewise, comparing a computed relevance value against a target value and selecting either the matched property or a hierarchically superior one is a straightforward implementation choice.
  6. The Board further noted that the alternative problem formulation proposed by the Appellant during the oral proceedings, namely ensuring that at least one personal property is always available for template customization, would have given the skilled person even more reason to arrive at the claimed solution.

Conclusion

The Board confirmed the Opposition Division’s revocation of the patent. The features distinguishing the claimed method from D1 were found to define a non-technical “business method” for selecting personalized cognitive content for phishing training documents. Under the COMVIK approach, these non-technical aspects were excluded from the inventive step assessment. The remaining technical implementation, including the use of hierarchical databases and relevance-value comparisons, was considered a routine measure within the skill of the ordinary practitioner. Consequently, the claimed invention lacked inventive step under Article 56 EPC, and the appeal was dismissed.

More information

You can read the full decision here: T 1908/23 (Personalisiertes Phishing-Dokument/IT-SEAL) of 17 September 2025, of the Technical Board of Appeal 3.5.05.

Stay in the loop

Never miss a beat by subscribing to the email newsletter. Please see our Privacy Policy.

Privacy policy 
* = Required field

Avoiding unauthorized display of sensitive personal data (such as a user’s facial image) during a payment authentication process: non-technical

The application underlying the discussed decision concerns a method and system for managing secure electronic payments using biometric authentication (fingerprints), a PIN code, and a stored facial image of the user, allowing transactions without physical money, cards, or mobile devices. The critical feature at issue was the display of a stored facial image of the user to the seller for identity verification, including the sequencing of this display only after biometric authentication and, for transactions exceeding 30 euros, also after PIN verification, which the appellant argued was a safety measure preventing unauthorized third parties from viewing sensitive personal data. The Board of Appeal considered this data protection requirement to be non-technical under the established Comvik approach and found all requests to lack inventive step over a combination of prior art documents D1 and D3.

Here are the practical takeaways from the decision: T 1613/22 (Secure payment/GRE-LAB) of 12 December 2025, of the Technical Board of Appeal 3.5.01.

Key takeaways

A requirement to avoid the unauthorized display of sensitive personal data (such as a user’s facial image) during a payment authentication process is a non-technical requirement under the Comvik approach and can be treated as a “given” provided to the skilled person for implementation. Defining a specific monetary threshold (e.g. 30 euros) for triggering additional security checks is likewise non-technical and cannot contribute to inventive step.

The invention

The Board of Appeal summarized the invention as follows:

The invention concerns the management of secure electronic transactions. The system comprises at least one payment device (“terminal”) connected to a server storing user-specific information, including biometric data, a PIN, account data and a picture of a user’s face, all provided during a registration phase. When users want to make a payment, they provide their biometric data (for example, fingerprints) to the payment device. For transactions exceeding a predefined threshold, a PIN is also required. The data are compared with those stored on the server. If the check results are positive, the picture of the user’s face is retrieved from the server and displayed to the seller as a further identity check before authorizing the transaction. In this way, it is possible to perform authentication during a transaction without requiring users to carry cards, cash or mobile devices. The method thus enables fully dematerialized payments with multi-factor authentication combining biometric verification, a knowledge factor (PIN), and visual identity confirmation by the seller.

  • Claim 1 of the Fourth Auxiliary Request

Is it patentable?

The Examining Division’s position

The Examining Division refused the application on the grounds of a lack of inventive step of claim 1 of all requests in view of D1 (US 2015/046328 A1). The Examining Division identified the characterizing features of claim 1, namely the acquisition and storage of a picture of the user’s face and the display of that picture before authorizing a transaction, as the distinguishing features over D1. It argued that systems providing a seller (e.g. a POS clerk) with a registered image of a customer in the context of a payment transaction in order to verify the customer’s identity were already known, and cited D5 (US 2006/069922 A1) as an example thereof. In addition, the Examining Division raised objections of added subject-matter (Article 123(2) EPC) against all auxiliary requests and a lack of clarity (Article 84 EPC) against auxiliary requests 2 to 8 then on file.

The Appellant’s arguments

The appellant argued that neither D1 nor D3 discloses displaying the stored image of the user’s face after the user’s identity has been verified by means of biometric data and after the PIN has been checked. This argument was raised during the examination proceedings in the letter of 15 November 2021 and maintained on appeal. The appellant specifically argued that the feature of displaying the image only after successful authentication constituted a safety measure, ensuring that images of a registered user were not seen by third parties who may have illegally obtained a transaction number. The appellant thus contended that the sequencing of authentication steps, including the conditional display of the facial image based on the transaction amount, represented a meaningful security improvement over the prior art that should be recognized as contributing to inventive step. In a letter dated 12 June 2025, the appellant withdrew its request for oral proceedings.

The Board’s analysis

Main request

The Board agreed with the parties that the distinguishing features over D1 were the acquisition and storage of a picture of the user’s face and the display of that picture before authorizing the transaction. However, the Board departed from the Examining Division’s reasoning based on D5, noting that D5 stores the picture on the user device rather than on a central server, and therefore even a combination of D1 and D5 would not arrive at the claimed subject-matter. Instead, the Board relied on D3 (US 7523067 B1), which discloses a central server storing user-related authentication information including a picture of a user’s face and displaying said picture to a shop assistant for authentication. Since both D1 and D3 concern user authentication in the context of transactions and both disclose combining several authentication methods, the Board found it obvious to add the facial recognition process of D3 to D1 as a further safety measure.

First, second, and third auxiliary requests

The Board found that the amendments in the first and second auxiliary requests (specifying the central unit/server is remote from the payment device and replacing “central unit” with “server”) did not further limit the claimed subject-matter beyond what was already implicit in the main request. The third auxiliary request’s additional feature of the method being carried out “in a dematerialized mode without using physical money, such as banknotes/coins, or credit cards or telephone” was found to be anticipated by D1, which even explicitly mentions avoiding the use of cash or cards.

Fourth, fifth, and sixth auxiliary requests

These requests added the qualification that the image is displayed after authentication and, if the payment exceeds 30 euros, also after the PIN verification. The Board’s analysis proceeded as follows:

  1. D3 already discloses carrying out additional authentication checks for particularly expensive transactions. The definition of the exact monetary threshold (30 euros) is non-technical and cannot contribute to inventive step.
  2. The Board acknowledged the appellant’s argument that neither D1 nor D3 discloses displaying the stored image after biometric and PIN verification. In D3, the image appears to be displayed at the beginning of the authentication procedure.
  3. However, the Board noted that the image is shown to the shop assistant, not to the party requesting the transaction, making it unclear whether it would even be visible to an unauthorized third party.
  4. Critically, the Board considered the requirement of avoiding the unauthorized display of sensitive personal data (the user image) to be a non-technical requirement. Pursuant to the established Comvik approach, this can be treated as a “given,” i.e. a requirement provided to the skilled person for implementation.
  5. It would then be obvious to the skilled person to implement this requirement by executing the picture-based identification only after verifying the user’s biometric credentials, especially considering that D1 already discloses displaying a user’s name after fingerprint verification.

Conclusion

The Board dismissed the appeal, finding that claim 1 of all requests (main request and first through sixth auxiliary requests) lacked inventive step over a combination of D1 and D3 (Article 56 EPC). The core distinguishing features of the main request, namely the storage and display of a facial image for identity verification, were found obvious in light of D3’s disclosure of the same concept in a transaction authentication context. For the fourth through sixth auxiliary requests, the additional feature of sequencing the image display after biometric and PIN verification was found to implement a non-technical requirement (data protection/privacy) under the Comvik approach, which the skilled person would have implemented in an obvious manner. The specific monetary threshold of 30 euros was likewise deemed non-technical. The application was therefore refused.

More information

You can read the full decision here: T 1613/22 (Secure payment/GRE-LAB) of 12 December 2025, of the Technical Board of Appeal 3.5.01.

Stay in the loop

Never miss a beat by subscribing to the email newsletter. Please see our Privacy Policy.

Privacy policy 
* = Required field

Post-transaction reselection of a payment method: non-technical

The application underlying the discussed decision concerns a method and system for reversing a payment method selection after a transaction has already been processed using a consolidated payment device associated with multiple payment methods. The key feature at issue was the post-transaction reselection of a payment method, including finalizing a transaction with a first payment method and subsequently initiating a cancel and refund process for that first payment method while authorizing the same transaction with a second payment method. The Board of Appeal considered this feature to be a financial, i.e., non-technical matter that does not contribute to inventive step.

Here are the practical takeaways from the decision: T 1327/22 (Selecting a payment method/CURVE UK) of 19 November 2025, of the Technical Board of Appeal 3.5.01.

Key takeaways

Changing the payment method after a transaction has been finalized by refunding the first payment method and charging a second one is a financial arrangement, not a technical contribution. Defining such a non-technical requirement without specifying any technical implementation means beyond a standard computer system is insufficient to establish inventive step.

The invention

The Board of Appeal summarized the invention as follows:

The invention relates to changing the payment method using a consolidated payment device (CPD), such as a card or mobile phone, which allows payment with multiple payment methods. A consolidated payment device is associated with a plurality of payment methods and enables using any of them for transactions at a point of sale or online. In practice, a holder of such a device may need to reverse their payment method selection after a transaction has already been processed, for example due to a mistake or due to latency inherent to the payment method selection process of consolidated payment devices. The invention addresses this by allowing the holder to effectively “go back in time.” A remote server receives a transaction request from the CPD indicating a first payment method. Upon authorization, including verification of sufficient funds, the transaction is finalized using the first payment method. If the holder later decides to use a different payment method, the server receives a reselection request indicating a second payment method. The server then authorizes the transaction with the second payment method and initiates a cancel and refund process for the first payment method. The entire process is designed to be transparent to the merchant or payment recipient, meaning neither the merchant nor the recipient needs to take any action or is even aware that a payment method change has occurred.

  • Main request - Claim 1

Is it patentable?

The Examining Division’s position

The examining division refused the application in a “decision according to the state of the file,” referring to its communication dated 15 November 2021. In that communication, objections were raised under Articles 123(2), 54, and 56 EPC. Regarding Article 123(2) EPC, the examining division objected to the use of the term “reselection request” in the second “authorizing” feature, where the original application used “transaction request.” Regarding novelty (Article 54 EPC), the examining division considered claim 1 to lack novelty over D1 (US 2011/191149), which disclosed a system allowing a customer to change the payment method after a transaction at the POS. Regarding inventive step (Article 56 EPC), the examining division took the view that first finalizing the transaction using the first payment method and subsequently refunding the paid amount was a financial, i.e., non-technical matter which did not contribute to inventive step under the COMVIK approach (T 641/00). The examining division further noted that the claim did not specify any technical implementation means going beyond the use of a computer.

The Appellant’s arguments

The appellant argued that claim 1 included several technical features necessary for carrying out the underlying business activity. In particular, the appellant contended that the data carrier had to be configured to:

  1. Receive, process and authorize a transaction request in respect of a first payment method.
  2. Finalize and debit payment from an authorized first payment method.
  3. Receive and process a reselection request denoting a second payment method for the transaction amount.
  4. Check and authorize the reselection transaction using a second payment method.
  5. Cancel and refund/reimburse the original transaction amount to the first (original) payment method.

The appellant argued that the invention allowed the user of a consolidated payment device to “go back in time” and vary the payment method used for a particular registered transaction to a different payment method, and to have the transaction amount refunded to the original payment method. In the appellant’s view, this constituted a technical effect that contributed to inventive step.

The Board’s analysis

Main request

  1. The Board first addressed the Article 123(2) EPC objection. The amendment replacing “reselection request” with “transaction request” in the second “authorizing” feature overcame the examining division’s objection. The Board found no added matter.
  2. On novelty, the Board disagreed with the examining division and agreed with the appellant that D1 did not disclose finalizing the transaction request for the first payment method and subsequently initiating a cancel and refund process for that payment method. In D1, the payment to the retailer is provided by the financial institution without debiting the customer’s account until the time has elapsed for the customer to choose a payment method. This is not the same as the cancel and refund in claim 1.
  3. On inventive step, however, the Board shared the examining division’s view. First finalizing the transaction using the first payment method and subsequently refunding the paid amount is a financial, i.e., non-technical matter which does not contribute to inventive step under the COMVIK approach (T 641/00). This non-technical rule is given as part of the framework of the technical problem as a requirement to implement.
  4. The Board found that the means for sending, receiving, and processing transaction requests, including the reselection request, were already disclosed in D1. D1 indeed allows the user to “go back in time” by changing the payment method after the transaction has taken place at the POS. The difference over D1 is merely in how this is solved financially: instead of giving the customer a credit until the final payment method is indicated (as in D1), the claimed invention debits the customer’s account and later refunds the amount.
  5. The Board acknowledged that the implementation might require technical modifications to the payment system, but these were not specified in the claim. The mere definition of means that achieve this was considered self-evident.

First auxiliary request

  1. The first auxiliary request added explicit references to deducting funds corresponding to the transaction amount from both the first and second payment method, and that the reselection request is associated with the transaction request.
  2. The examining division had objected under Article 123(2) EPC because the originally filed application did not explicitly disclose “deducting funds.” The Board disagreed and found that deducting funds is implicit in the disclosure, since a refund on the first payment method implies that the amount was first charged, and paying via the second method involves charging it.
  3. However, the Board held that the first auxiliary request did not add any technical features contributing to inventive step. The appellant did not argue any further technical effects or advantages. The same reasoning as for the main request applied, and claim 1 of the first auxiliary request also lacked inventive step.

Conclusion

The Board dismissed the appeal. While the Board found that the claims met the requirements of Article 123(2) EPC and were novel over the cited prior art D1 (US 2011/191149), the distinguishing feature over D1, namely finalizing a transaction with a first payment method and subsequently initiating a cancel and refund to switch to a second payment method, was considered a purely financial arrangement. Under the COMVIK approach, this non-technical feature could not contribute to inventive step. Since the claims did not specify any technical implementation details beyond the use of a standard computer system, it would have been obvious for the skilled person to implement this financial requirement on the computer system known from D1. The application was therefore refused for lack of inventive step under Article 56 EPC for both the main request and the first auxiliary request.

More information

You can read the full decision here: T 1327/22 (Selecting a payment method/CURVE UK) of 19 November 2025, of the Technical Board of Appeal 3.5.01.

Stay in the loop

Never miss a beat by subscribing to the email newsletter. Please see our Privacy Policy.

Privacy policy 
* = Required field