Author Archive

Providing an interactive seat map by building an overlay: technical

The application underlying the discussed decision concerns a method for providing an interactive seat map showing the locations of available tickets in an event venue, built at a client computer using a base map, a coded image map, and ticket inventory data received from a network-based system. The decisive feature was the implementation of the interactive seat map by building an overlay on top of a raster graphics base map using an HTML coded image map, as opposed to using vector graphics technologies like Adobe Flash. The Board of Appeal considered this implementation choice to involve technical considerations, leading to remittal of the case for further search and prosecution.

Here are the practical takeaways from the decision: T 0133/21 (Interactive seat map/STUBHUB) of 2 July 2024, of the Technical Board of Appeal 3.5.01.

Key takeaways

The choice of how to implement an interactive map in a web browser, specifically using raster graphics combined with an HTML image map overlay instead of vector graphics such as Flash, involves technical considerations that go beyond mere presentation of information. However, the claim must be sufficiently specific to clearly achieve the associated technical effect; a broadly worded claim that does not exclude vector graphics fails to do so.

The invention

The Board of Appeal summarized the invention as follows:

The invention concerns an online marketplace for tickets, which includes an interactive seat map displaying where tickets are available at an event venue. The venue has different sections, and ticket availability in the respective sections is shown using different colouring, such as fill colour, stroke colour, and transparent colour. The user can click on a section of the map to get more information about tickets. The interactive seat map is implemented by building, at the client computer, a map overlay on top of a base map of the event venue. The overlay has polygons aligned with the sections of the event venue depicted on the base map. The base map is a compressed raster graphics image, for example a JPEG image. The coded image map is defined using HTML area tags specifying clickable areas of the base image, including their shapes, coordinates, and associated hyperlinks. The map overlay itself is created using a JavaScript library called “Canvas” in a client-side web application. The overall aim was to implement the interactive seat map without using vector graphics such as Adobe Flash, which required browser plug-ins not available on all browsers, particularly mobile browsers.

  • Claim 1 of the First Auxiliary Request

Is it patentable?

The Examining Division’s position

The examining division considered that claim 1 of the main request consisted of a mix of technical and non-technical features. The effect of the claimed method was said to be presentation of information. In particular, the interactive seat map consisting of a base map with sections and a map overlay on top of the base map did not provide a technical effect. The only features contributing to the technical character of the invention were the hardware features, namely a data processing system comprising a client device, a network, and another computer. D1 (US 2007/265892) was cited as an example of such a data processing system. D1 disclosed a system for providing an interactive map in which a client computer received a base map with sections, created overlays with specific colours corresponding to ticket availability, displayed the map, received user selections, and redirected the user to corresponding data blocks. The examining division did not explicitly identify the differences between the claimed method and D1, but merely stated that they related to the implementation of an administrative method and the corresponding presentation of information, which did not involve an inventive step under the COMVIK approach. The division further did not agree that claim 1 excluded the use of vector graphics, and considered that providing a combination of a base map and a coded image map defining polygons for sections of an overlay did not have a technical effect. The first auxiliary request (filed as the third auxiliary request before the examining division) was not admitted under Rule 137(3) EPC because it was found to contravene Article 123(2) EPC and not to overcome the inventive step objection.

The Appellant’s arguments

The appellant argued that, in the prior art, interactive maps were implemented using vector graphics such as Flash, which required a browser plug-in that was not available for all browsers, in particular mobile browsers. The invention sought to implement the interactive seat map without using vector graphics, but rather using tools compatible with and common to all web browsers. The appellant explained that the base map was a raster graphics image (e.g., JPEG), the coded image map was defined in HTML (using area tags), and the map overlay was created using a JavaScript library called “Canvas” in a client-side web application. At the time of the invention, it was not possible to overlay an area of an image using HTML alone, so the combination of HTML image maps with JavaScript Canvas represented a specific technical implementation choice. This implementation involved technical considerations beyond mere information presentation.

The Board’s analysis

Overall technical character

The Board agreed with the examining division that the overall purpose of the interactive seat map was to provide the user with information, which was not technical per se. However, the Board found that the implementation of the interactive map involved technical considerations which went beyond the domain of the notional non-technical person (citing T 1463/11). The choice of implementation, whether to use vector graphics or raster graphics with an overlay in HTML/JavaScript, was a matter for the technically skilled person.

Main request

The Board agreed with the examining division that claim 1 of the main request was not clearly limited to a particular implementation. It did not exclude the use of vector graphics. The terms “base map,” “map overlay,” and “coded image map” were not defined in sufficient detail in the claim to give rise to a technical effect beyond providing an alternative implementation of an interactive map. The Board noted that the colouring of sections in D1 could, at a general and abstract level, be regarded as a form of “coding” and thus as involving a “coded image map,” with the colour constituting an “overlay” in a broad sense. Claim 1 of the main request therefore lacked inventive step (Article 56 EPC).

First auxiliary request

Claim 1 of the first auxiliary request added that the base map was formed using raster graphics and that the coded image map was in HTML. The Board found that these features were clearly not disclosed in D1 and could not simply be dismissed as non-technical. Furthermore, taking into account that the map overlay was built at the client side using the coded image map, the claimed solution was not clearly well known. The Board did not consider claim 1 of the first auxiliary request to be obvious in view of D1 or any of the cited prior art documents, because none of them dealt with implementations involving the combination of HTML coded image maps and overlays. However, the Board was not in a position to grant a patent because it had doubts whether the implementation based on HTML/JavaScript had been searched. The examining division had considered the concept of building an overlay on top of a base map using a coded image map to be non-technical, which indicated that this concept was not specifically searched. None of the documents in the search report dealt with HTML and JavaScript-based solutions for creating an interactive image map.

Conclusion

The decision under appeal was set aside and the case was remitted to the examining division for further prosecution, including a further search. The Board recognized that the specific technical implementation of building an interactive map overlay using raster graphics and HTML coded image maps involved genuine technical considerations that went beyond mere presentation of information. The examining division had treated these features as non-technical and consequently had not searched them, meaning no prior art was on file covering HTML and JavaScript-based solutions for creating interactive image maps. While HTML image maps were undoubtedly known at the priority date, no prior art on file showed how JavaScript Canvas was used in connection with HTML image maps to create an overlay. A further search was therefore necessary before the inventive step assessment could be completed.

More information

You can read the full decision here: T 0133/21 (Interactive seat map/STUBHUB) of 2 July 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

Determining a resource allocation for controlling a facility’s equipment: non-technical

The application underlying the discussed decision concerns an energy optimization system for controlling building equipment of a facility participating in a capacity market program (CMP), where the facility commits to reducing its energy load upon dispatch by a utility. The key features at issue were the CMP-specific objective function and optimization constraints, including a dispatch probability and a raw baseline, used to determine a resource allocation for controlling the facility’s equipment. The Board considered these features non-technical, as they related to financial optimization aimed at maximizing economic profit under contractual obligations.

Here are the practical takeaways from the decision: T 1596/22 (Energy optimisation with Capacity Market Program/JOHNSON CONTROLS) of 9 December 2025, of the Technical Board of Appeal 3.5.01.

Key takeaways

Optimizing a resource allocation for building equipment based on an objective function and constraints tailored to a capacity market program is non-technical where the optimization serves to maximize economic profit while fulfilling contractual obligations. Processing physical parameters such as historic load data or weather data does not impart technical character to what is essentially a financial optimization.

The invention

The Board of Appeal summarized the invention as follows:

The invention relates to an energy optimization system for a facility participating in a capacity market program (CMP). In a CMP, a utility company rewards a facility owner for being on standby to reduce the facility’s energy load by a predetermined amount, known as the nominated capacity value, upon receiving a dispatch notice at an unknown future time. The system generates a raw baseline from historic load data to establish the typical load of the facility. It then generates an objective function and CMP-specific constraints and optimizes the objective function to determine a resource allocation for the facility’s building equipment. The optimization incorporates the probability of receiving a dispatch from the utility, estimated based on historic weather data, historic dispatch hours, and predicted regional peak loads. The constraints ensure that the facility can reduce its load by the nominated capacity value, or by an even greater amount, when dispatched. According to the description, the objective function calculates the facility’s operating cost during CMP participation, defined as the difference between equipment operating expenses and potential CMP revenue. The resulting resource allocation specifies how the facility’s equipment should adjust its capacity, and the building equipment is controlled accordingly.

  • Claim 1 of Auxiliary Request 4

Is it patentable?

The Examining Division’s position

The examining division found that claim 1 of the main request and auxiliary requests 1 to 4 did not involve an inventive step. The division primarily assessed inventive step starting from a generally known computing system and also referred to D1 (US 2017/103483 A1), concluding that the differences over D1 did not contribute to the technical character of the invention. The distinguishing features, namely the CMP-specific objective function and optimization constraints, were considered non-technical as they related to mathematical formulations driven by economic and financial considerations concerning the facility’s operational costs, expected revenues, and contractual obligations under the CMP. The examining division further found that merely specifying physical input parameters, such as historic load data, was insufficient to impart technical character to the generation and optimization of the objective function.

The Appellant’s arguments

  1. Claim 1 had technical character as a whole because the resource allocation was used to control building equipment.
  2. The resource allocation was based on technical considerations because it ensured that building equipment was controlled to satisfy both the building’s load demand and the curtailment capacity agreed with the utility, constituting a technical solution to a technical problem.
  3. Unlike conventional demand response programs, a CMP does not provide a time schedule for load reduction. The invention addressed this by incorporating a dispatch probability, reducing the risk of underperformance. The probability depended on factors such as historic weather data, involving technical considerations about energy generation.
  4. Participation in a CMP contributed to maintaining a stable and reliable energy grid, which constituted a technical effect.
  5. The objective function was not based on business considerations. Even if the description disclosed financially motivated embodiments, claim 1 itself did not include such financial aspects. The optimization relied on physical parameters such as the facility’s historical load.

The Board’s analysis

The Board chose auxiliary request 4 as the most specific definition among the admitted requests and used D1 as the closest prior art. Like the invention, D1 concerns determining an optimal resource allocation for a facility and controlling its equipment, balancing operating costs against potential revenues from incentive-based demand-response programs. The differences over D1 were that the objective function and constraints were specifically adapted to CMP participation.

Non-technical nature of the distinguishing features

The Board found that claim 1 did not define the calculations performed by the objective function. Merely specifying inputs such as dispatch probability did not indicate what was being optimized. The constraints merely defined the optimization framework reflecting CMP requirements. According to the description, the objective function calculated the facility’s operating cost (expenses minus CMP revenues). The distinguishing features were therefore non-technical, relating to financial and economic considerations. Under the COMVIK approach (T 641/00), the objective technical problem was how to implement these non-technical optimization requirements within D1’s system, which was deemed obvious.

Responses to the Appellant’s arguments

  1. Overall technical character of the claim does not mean every feature contributes to technical character. The control of building equipment is driven by a resource allocation aimed at maximizing profit, which is non-technical.
  2. Claim 1 contains no features ensuring the building’s load demand is met. The only mandatory requirement, load reduction, is an administrative constraint from contractual obligations. The “balancing of interests” merely determines the most financially advantageous allocation while ensuring contractual compliance.
  3. Claim 1 does not specify how the dispatch probability is determined or used. According to the description, it estimates potential penalties for underperformance, demonstrating the parameter is employed purely for financial optimization.
  4. Load reduction can help lower overall grid load, but here the reduction arises from contractual obligations, not technical considerations. The claimed optimization does not itself produce any effect on the grid. Any grid stability effect results from load reduction, which is already known from D1.
  5. Leaving the objective function undefined does not make it technical; it still encompasses financial optimization embodiments. A method serving no technical purpose cannot gain technical character just because it processes technical data, citing T 154/04, T 677/09, and T 2626/18.

Other requests

The main request and auxiliary requests 1 to 3, being broader than auxiliary request 4, likewise lacked inventive step. Auxiliary requests 6, 7, 7A, 8, and 9 were not admitted under Article 13(2) RPBA as they were filed less than two working days before oral proceedings without exceptional circumstances and did not address the central deficiency. Auxiliary request 5 was not admitted under Articles 12(4) and 12(6) RPBA as it was filed with the grounds of appeal without reasons, and its added features related to determining an optimal nominated capacity to maximize financial profit, which was non-technical.

Conclusion

The appeal was dismissed. The Board confirmed that the CMP-specific objective function and constraints were non-technical features driven by financial optimization considerations. Under the COMVIK approach, these features were incorporated into the objective technical problem formulation, and their implementation in the system of D1 was deemed obvious. The Board emphasized that processing physical data such as historic loads or weather data does not render a fundamentally financial optimization technical, and that controlling building equipment based on a financially motivated resource allocation does not make the underlying optimization technical either. The request for remittal was also refused, as the Board found no special reasons warranting it.

More information

You can read the full decision here: T 1596/22 (Energy optimisation with Capacity Market Program/JOHNSON CONTROLS) of 9 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

Judging whether an item meeting an item condition had been retrieved from an RFID-based cabinet: non-technical

The application underlying the discussed decision concerns a storage cabinet that manages stored items using RFID technology and automatically checks whether items meeting a specified retrieval condition have been correctly removed. The key feature at issue was the controller’s function of judging whether an item meeting an item condition had been retrieved from the cabinet after a user opened and closed the door. The Board considered this feature to be a non-technical administrative requirement that could not contribute to inventive step.

Here are the practical takeaways from the decision: T 1189/23 (Storage cabinet/SATO) of 24 October 2025, of the Technical Board of Appeal 3.5.01.

Key takeaways

Automatically checking whether items meeting a specified retrieval condition have been removed from an RFID-based storage cabinet is a non-technical administrative requirement under the COMVIK approach. The cognitive content of the data checked and any deduction or judgement derived from it (i.e., whether certain items have been removed or not) are part of a non-technical scheme, and their straightforward implementation on a known system cannot support inventive step.

The invention

The Board of Appeal summarized the invention as follows:

The invention concerns a storage cabinet that stores a plurality of items, each tagged with an RFID tag recording item information such as item codes, expiry dates, and lot numbers. The cabinet comprises a housing with a door and two RFID readers. A first reader reads all item tags inside the cabinet when the door is in a closed state, and the read item information is stored in a memory. A second reader is positioned on the outside of the housing and reads a second recording medium, such as a picking list card, when it is brought proximate to a predetermined area on the housing while the door is closed. The second recording medium contains information relating to an item condition specifying which items should be retrieved from the cabinet. When an operator presents the picking list card to the external reader, the controller identifies matching items in the stored inventory. After the operator opens and closes the door, i.e. after completing a retrieval transaction, the first reader scans all remaining items. The controller then determines a judgment result as to whether items meeting the item condition have been successfully retrieved by checking whether the identified items are still present. The system may output alarms or display messages to inform the operator of the result.

  • Main request, Claim 1

Is it patentable?

The Examining Division’s position

The examining division considered that the technical features of claim 1, as defined in the preamble, were all known from D1 (US 2014/138440 A1), which disclosed an RFID-based storage cabinet with a housing, a door, two RFID readers (including an external scanner), a computer system (controller), and a memory storing inventory data. The examining division found that claim 1 was distinguished from D1 only by the last feature of the characterizing portion, namely the determination of “a judgment result as to whether an item that meets the item condition of an item to be retrieved from the storage cabinet has been retrieved therefrom.” The examining division considered this feature to define a non-technical business requirement. D1 already maintained an accurate inventory, and scanning by its RFID scanners enabled storing transactions and checking them against the inventory database. The setting of a goal or condition by the user and the corresponding scan were used for inventory purposes, which required accessing and checking the database data. The examining division took the view that performing such checks was based on non-technical inventory policy rules, which could not confer a technical effect, and concluded that the subject-matter of claim 1 lacked inventive step over D1.

The Appellant’s arguments

The appellant argued that D1’s external scanner could read information on an item, but this information did not concern an item condition of an item to be retrieved, and the operation did not trigger any identification of respective item information in the memory. D1 did not show any correlation between information about a particular item to be retrieved, read by an external reader, and the current database entries about items in the cabinet. In fact, D1 did not check whether a particular item desired to be retrieved was actually retrieved. D1’s scan of all items was not for making any judgement but only for updating the database. The appellant argued that the aim of the invention was to perform an automatic check as to whether a task for removing particular products meeting a certain retrieval condition had been correctly performed, so that an operator could immediately recognise the results without any manual check. This enhanced security by ensuring the correct retrieval of items from the storage cabinet. The objective technical problem, when starting from D1, was therefore how to provide a storage cabinet capable of enhancing security by ensuring correct retrieval. D1 could not solve this problem because it lacked a check of the inventory database after the door was closed to determine whether any item meeting the retrieval condition had been left inside.

The Board’s analysis

Main request

The Board agreed with the examining division that the technical features of claim 1, as defined in the preamble, were known from D1. The appellant also conceded this point. The Board then assessed the features of the characterizing portion and reached the following conclusions:

  1. The characterizing features aimed to check whether all items meeting a certain retrieval condition had been retrieved. The Board agreed with the examining division that this was a direct implementation of a non-technical requirement.
  2. The Board could not recognise any “enhanced security” because claim 1 determined only a “judgment result” without any further technical step that could ensure the correct retrieval of items from the storage cabinet. The claimed system did not prevent a user from retrieving a wrong item.
  3. In line with the COMVIK approach (T 641/00), features which do not solve a technical problem by providing a technical effect cannot contribute to inventive step. Determining whether an item meeting an unspecified condition has been retrieved from the cabinet is a non-technical requirement. The cognitive content of the data checked and any deduction or judgement derived from it are part of a non-technical scheme.
  4. The objective technical problem was formulated as how to automate this non-technical scheme in the system of D1. It would be obvious for the person skilled in the art to configure the computer system of D1 to perform the operations defined in the characterizing portion of claim 1.
  5. Regarding the appellant’s argument that D1 was only concerned with inventory management, the Board noted that D1 also mentioned maintaining an accurate inventory and using the database for checks when transactions were performed. D1’s external reader was used for quality assurance checks and for scanning patient wristbands, and its goal-selection mechanism implicitly taught a check as to whether the user had retrieved the correct item.

Auxiliary requests

  1. Auxiliary request 1 amended the judgment to check whether “all items” meeting the condition had been retrieved. The Board found this to be just a different administrative requirement belonging to the non-technical domain, obvious to implement. D1 clearly mentioned that a goal may require several transactions.
  2. Auxiliary request 2 added an alarm output if the item had not been retrieved. The Board held that this merely presented the result of a non-technical judgement. D1 already disclosed the ability to output alerts to a user, and it would be obvious to assist the user by outputting an alarm indicating incomplete retrieval.
  3. Auxiliary request 3 added a display and/or voice output of the judgment result. The Board found this to be an obvious and straightforward measure, noting that D1 disclosed a display for presenting output and D7 taught voice output.

Conclusion

The Board dismissed the appeal in its entirety. For all requests, the Board found that the distinguishing features over D1 defined non-technical administrative requirements relating to checking whether items meeting a retrieval condition had been removed from the storage cabinet. Under the COMVIK approach, these non-technical requirements were given to the skilled person as part of the problem formulation, and their implementation on the known RFID-based storage cabinet system of D1 was found to be obvious. The application was thus refused for lack of inventive step under Article 56 EPC.

More information

You can read the full decision here: T 1189/23 (Storage cabinet/SATO) of 24 October 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

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