Review of EPO Software Decisions in 2019

As has been the case for many years now, the definition of “technical” remains the most significant unanswered question in this field. However, progress has been made, with several decisions developing the approach to separating technical and non-technical features by reference to the “notional business person” first expounded in Cardinal Commerce (T 1463/11) and some other decisions analysing the circumstances in which non-technical features may be considered to contribute to a technical effect.

Procedure and Statistics

The overall number of cases processed in 2019 was similar to previous years – now that board 3.5.01 has resumed a full workload – and rejection rates remain high, with board 3.5.06 rejecting more than 90% of patents it reviewed.

Rejection rates where a non-technical problem is identified or some feature of the claim is excluded from consideration are still high, but a few more cases have been allowed this year.

New rules of procedure of the Boards of Appeal come into effect in 2020 and are discussed in more detail here. It is a stated aim of the new rules that fewer cases will be remitted to first instance (examination or opposition division) for further prosecution but whether that will come about remains to be seen. The new rules also make it harder to introduce new prior art, arguments and amendments on appeal, reflecting the boards’ increased propensity to hold new requests on appeal inadmissible even to the extent that, in T 1695/15 (Click haptic feedback/KYOCERA), the board refused to readmit requests that had been withdrawn earlier in the proceedings.

Simulation and Modelling

As mentioned above, in decision T 0489/14 (Pedestrian simulation/CONNOR) board 3.5.07 referred three questions to the Enlarged Board of Appeal:

1. In the assessment of inventive step, can the computer-implemented simulation of a technical system or process solve a technical problem by producing a technical effect which goes beyond the simulation’s implementation on a computer, if the computer-implemented simulation is claimed as such?
2. If the answer to the first question is yes, what are the relevant criteria for assessing whether a computer-implemented simulation claimed as such solves a technical problem? In particular, is it a sufficient condition that the simulation is based, at least in part, on technical principles underlying the simulated system or process?
3. What are the answers to the first and second questions if the computer-implemented simulation is claimed as part of a design process, in particular for verifying a design?

This case is discussed in more detail in our briefing here. At the time of writing, a board has been appointed and numerous amicus curiae briefs have been filed, along with invited comments from the President of the EPO. However no timetable for oral proceedings or a decision has been set.

The majority of the amicus curiae briefs and the comments from the President of the EPO are supportive of the existing case law: that simulation or modelling of a specific technical or physical system is patentable, that the simulation has to be based on scientific or technical principles and that the same applies if the simulation is part of a design process. However, there is no guarantee that the Enlarged Board will follow this approach and previous Enlarged Boards have rewritten the questions they have been asked. It is possible therefore that the Enlarged Board will give a decision that has ramifications beyond the field of simulation.

Having said that simulation or modelling of a technical system or process is usually patentable, T 2677/16 (Drug target/QIAGEN) is a case where it was not. In this case, the purpose of the method was “identifying a drug discovery target”. A drug target is a molecule in the body, usually a protein or a gene, that is associated with a particular disease process, and could theoretically be targeted by a drug to treat the disease by interrupting the disease-related metabolic pathway. The examining division considered that the potential to produce a therapeutic effect was a sufficient technical purpose but rejected the application for lacking inventive step for not achieving that purpose. The board however held this unduly broadens the concept of a technical purpose to encompass any scientific endeavour in medicine, observing that a “drug target is not a therapy: it has no therapeutic effect, but is merely a promising direction for future research.” Thus the invention was considered to be about making discoveries, which are not patentable.

Determining what is technical

EPO presentations relating to examination of computer-implemented inventions often refer to the need to overcome two “hurdles”. The first hurdle is ensuring that the invention does not relate to non-technical subject matter “as such” and is achieved by including at least one technical feature in the claims. The second hurdle is to demonstrate a technical inventive step, following the “Comvik approach” whereby non-technical features are effectively disregarded.

“First Hurdle” – some technical feature

A failure at the first hurdle occurred in T 2457/13 (Laying-out a business park/HOFMAN) where claims to a “method for laying out a business park” were held to be a mental act and excluded from patentability under Article 52(2)(c) EPC. However the lowness of this hurdle is shown by the fact that claims to a method of actually building the infrastructure of the business park or to that infrastructure itself would not be excluded. Similarly in T 1959/13 (Datenverarbeitungseinrichtung/SIX FINANCIAL INFORMATION AG) a “hierarchical data structure for messages for the financial area”¹ was held not to be an invention because the data structure did not inevitably lead to any technical effect.

“Second hurdle” – a technical solution to a technical problem

If the first hurdle is passed, due to the presence of at least one technical feature in the claim, the Comvik approach is applied, as for example in T 0520/13 (Advertisement selection/MICROSOFT). Non-technical features are assigned to a requirements phase and only technical features contribute to inventive step.  In this case, board 3.5.01 held that the selection of an advertisement based on state data comprising at least one of a current time, a user’s location, and the user’s travelling direction is not technical and is therefore part of the requirements that the skilled person has to implement. The appellant argued that a two-step selection reduced latency and it would not have been obvious at the priority date in February 2008 to perform the selection locally, in a mobile device, because, at that time, mobile phones were not smart. Although these arguments are based on technical issues, the Board was unconvinced, holding that whether to process data locally or centrally is the sort of trade-off that the skilled person routinely deals with and that the claim was not actually limited to a mobile device.

A rare example of a trading case not being rejected was T 1072/11 (Matching unit comprising two computer entities/Nasdaq) which related to a trading system comprising two computer entities and a shared memory. One of the computer entities precalculated values that would be required by the other in matching “combination orders”. Although the board acknowledged that multiprocessor architectures and co-processors sharing cache memory were known, they held that this did not make the technical features specified in the claims notorious. Hence the case was remitted for further search and examination. At the time of writing, the Examining Division are maintaining new objections of lack of inventive step based on new prior art.

To implement the Comvik approach it is necessary to determine what features are technical and what are not and this is often a subject for debate. To make this determination, the boards increasingly apply and develop the Cardinal Commerce approach which proposes a notional business person as the author of the non-technical requirements which are to be implemented by the skilled person.

Notional business person

In T 0817/16 (Document scoring/GOOGLE) board 3.5.07 analysed an invention relating to ranking documents based on how much and often they have been edited. The board approved the Cardinal Commerce decision (T 1463/11) and commented that asking whether the non-technical features would have been formulated by a technical person rather than by a non-technical person or persons “is not an enquiry into the actual state of technical or non-technical knowledge at the effective filing date; the question is rather whether the knowledge required for coming up with the non-technical features in the particular case is of a kind that only a technical person, i.e. a person not working exclusively in areas falling under Article 52(2) EPC, could possess.”

The board goes on to comment that “determining the semantic similarity between documents by means of term vectors belongs to the field of linguistics, which is a non-technical area” and that “the idea to use this concept in a computer program to reduce the amount of data to be stored is arguably one that the notional computer programmer would have had – more data requiring more memory being a concept inherent to computer programming.”

This pairing of the linguist and the computer programmer, and the implied definition of a non-technical person as one “working exclusively in areas falling under Article 52(2) EPC” (which of course includes programs for computers) could be taken as indicating that the programmer is a non-technical person and hence the contribution of a programmer to an invention would not contribute to inventive step. However, the board did say they “need not make a judgment as to the technicality of the use of term vectors in the context of claim 1, as the outcome of the inventive-step assessment does not depend on it.” Also, this decision should be considered in conjunction with a subsequent decision of the same board, discussed next.

T 0697/17 (SQL extensions/MICROSOFT TECHNOLOGY LICENSING) relates to an invention that uses “a nested extension of the SQL UPDATE statement which supports the modification of collection-valued columns using syntax and semantics analogous to those of the conventional UPDATE statement” and contains considerable discussion of how the technicality of claim features should be judged. In particular, the board criticised the examining division’s objection, that the invention was merely the implementation of an algorithm, as meaning that no technical implementation of a non-technical idea could ever be patentable and commented that ‘a feature does not lose its technical nature just because it is too generic or “functionally defined”’.

Discussing general principles for determining whether features are technical, the board observes that an assessment of technicality may often be made without reference to the prior art, but in other cases a consideration of the technical contribution of a feature, i.e. the effect it brings about by being added, is necessary. A feature makes a technical contribution if it interacts with other technical features to solve a technical problem relative to the prior art.  Earlier case law has held that an increase in processing speed, or other performance improvement, is not sufficient to show a technical contribution. The board here emphasises that the reason for the improvement is key. Features that “purposively use technical means” to achieve an improvement are technical.  On the other hand, if an improvement is achieved by modifications to the non-technical method or scheme underlying the invention then that improvement cannot be considered a technical contribution. Also “a change in the quality of a program in terms of the user preferences or other subjective criteria” is not technical. Therefore it is important when drafting an application to set out a technical justification for novel features.

The board also states that features “make a technical contribution if they result from technical considerations on how to for instance improve processing speed,” etc.. The phrase “technical considerations” was previously used in T 0769/92 (General purpose management system) of 31.5.1994 which was understood as indicating that an invention was patentable merely if any technical considerations had been taken into account in devising it. This case was widely considered the most liberal point in patentability of software implemented inventions prior to Comvik, but the present case should not be considered a return to that regime.

The generality of a claim feature can be relevant to whether it is considered technical. In a network system it might be thought that a “timeout criterion” for determining availability of a service is a technical feature. However, in T 1082/13 (Computer implemented system offering replacement services/SAP) the relevant claim feature was “so general that it also covers non-technical interpretations, such as a requester telling the service broker to choose the preferred service provider and not waiting forever if nothing happens”. This case also discussed the Cardinal Commerce “notional business person” approach in detail and held that:

the notional business person cannot be assumed to be so blind that he does not even know about the existence of computers or the Internet. …

The choice of where to do a calculation in a distributed system is not necessarily technical, but can also be driven by administrative considerations (e.g. where the data is needed, collected or to be presented etc. following the business requirements specification). When referring to prejudices, it has to be carefully analysed, whether it is actually a technical prejudice or, in fact, a business prejudice (e.g. just a new way of organising a business transaction that goes against traditional ways of organising it etc.).

It probably did not help that the services in this case were tax calculations.

Databases and data management

Several cases addressed issues relating to databases and data management, which can include both technical and non-technical inventions. A good summary of the distinction to be applied in this field was given in T 1924/17 (Data consistency management/ACCENTURE GLOBAL SERVICES). There, board 3.5.07 noted that database systems “often have a technical character, as they have been designed based on engineering considerations concerning the efficient exploitation of the computer system as a technical system.” On the other hand, information retrieval systems that “calculate a semantic similarity of documents” are considered to be non-technical because they are “based on subjective criteria and the content (semantics) of the documents to be retrieved.” All features in the invention of T 1924/17, which related to maintaining data consistency in a cloud environment, were considered to contribute to a technical solution of a technical problem and the application was remitted for further search and examination.

Other problems in this field considered non-technical included de-identifying data, by removing individually identifiable information, and by aggregating data from a plurality of sources T 1248/12 (Privacy preserving data mining/CROSSIX) and provision of data in a suitable form for analysis T 0818/16 (Time series search engine/SPLUNK).

Functional data

A common argument for technicality is that data specified in a claim is “functional data” rather than “cognitive data”. Functional data is data that controls the operation of a “machine” whereas cognitive data is data that is processed by the machine. This distinction was considered in T 2049/12 (Data structure for defining transformations/MICROSOFT) which reviewed the original precedent (T 1194/97 – Data structure product/PHILIPS). The board noted that the real point of the Philips decision was that the functional data “mapped to technical features in a technical system” and that there are not only two categories of data: functional and cognitive. Therefore, it is not correct to argue that because data is not cognitive it is functional and therefore technical. Instead the “mapping to a technical system” test must be applied. This test failed in T 2049/12 because the invention arguably provided a better structured computer program and so “mapped” to the program, not the machine.

Other examples of non-technical problems included:

• helping a user to remember their place in a queue T 0748/13 (Queue image/Q.NOMY)
• uniquely identifying products using codes T 1201/10 (Personalised interactive automated marketing/JEAN-LUC ROCHET)
• mitigating credit risk positions T 1895/13 (Reducing delta values of credit risk positions/CREDITEX)
• translating different formats of credit report T 0005/13 (Resolving transactions/APOLLO)
• transfer of selected ownership records T 1898/13 (House information management/THERMODYNAMIC DESIGN LLC)
• identifying a carton by an identifier assigned to one packet in it T 0907/12 (Cigarette packaging/Jt INTERNATIONAL S.A.)
• limiting a number of user requests “to avoid deflating a return on investment” T 2276/13 (Prioritising a listing of information providers/YELLOWPAGES.COM)
• monitoring a derivatives transaction in real time T 2491/12 (Tracking derivative positions/TRADEWEB)
• preventing charges for failed calls T 1388/14 (METHOD OF COMMUNICATION/NOKIA)
• providing data storage capacity on demand T 1242/13 (Partitioned data library IV/HEWLETT PACKARD)
• to allow only gifts that the customer can use T 1503/12 (Compatible content gifts/QUALCOMM).

Examples of technical problems included:

• limiting the risk of piracy of streamed media T 0236/16 (Protection de contenu multimedia/VIACCESS)
• increasing security and avoiding unnecessary reservation of resources T 2263/13 (Logging out inactive printer users/CANON)
• converting a text description into parameters to control an ambient lighting system T 1228/15 (Determining an ambient parameter set/SIGNIFY HOLDING)

Inventive step

The problem and solution approach is applied across all fields of technology at the EPO and the importance of properly formulating the problem was emphasised by board 3.5.01 in T 1989/12 (Calendar-based profile switching/MICROSOFT). The board stated that formulation of the objective technical problem

“is often a crucial issue, because the problem defines what is given to the skilled person. A broadly formulated problem leaves a lot for the skilled person to solve. A narrowly formulated problem, on the other hand, puts the skilled person closer to the invention. The limit is the point just before elements of the solution enter into the problem (impermissible hindsight). In all cases, non-technical features cannot contribute to inventive step. Therefore, they may legitimately appear in the formulation of the problem to be solved without constituting such hindsight”.

A narrow formulation of the problem was justified in this case as the main concepts of the invention were considered non-technical. Therefore, the “only thing that is left for the skilled person to do is to implement the requirements on the mobile device” which would have been obvious.

A common basis for rejection of applications for lack of inventive step is that mere automation of a known procedure is obvious. In T 0475/16 (Program groups/MEDTRONIC), an argument that the invention lay not in mere automation but in the “idea of automating” the assembling of a program group or in that this task can be automated, was also rejected. Similarly, in T 2380/12 (Disassociated images/SYMANTEC) there was seen to be no technical effect in the claimed sequence of system administrator’s actions with known software tools (image builder, mounting tool, virus scanner) with the further flaw that these actions were not even fully automated.

In several cases, boards have held that various forms of trade-off are within the normal capabilities of the skilled programmer, for example:

• between activity at user level and kernel level T 2083/13 (Accessing locked files/LENOVO)
• between computational simplicity and reliability T 2353/12 (Detecting block artifacts/Thomson)
• between speed (pre-computation) and storage (computation on-the-fly) T 1718/17 (User habit list/HUAWEI)

User Interfaces

As in prior years, there are plenty of decisions addressing user interfaces of various kinds. To be patentable, a user interface must solve a technical problem and not simply provide merely aesthetic improvements. An example of the latter was T 2271/12 (Smooth continuous movement/SAMSUNG) which related to page flipping in an e-book. Board 3.5.05 held that providing “a smooth continuous movement of the pages” was “a mere aesthetic effect which does not contribute to the technical character of the invention.”

Merely displaying search results on the basis of a defined prioritisation is not technical, according to T 2276/13 (Prioritising a listing of information providers/YELLOWPAGES.COM), if it “is not used for any purpose other than that of presenting the prioritised set of information providers to the user.” A similar conclusion was reached in T 1718/17 (User habit list/HUAWEI).  Nor are aspects of user interfaces that do not depend on objective technical considerations, but on subjective user preference (T 0933/16 (Zweistufige KFZ-Bedienung/AUDI) and T 1559/14 (Processing search information/EBAY) or the cognitive skills of the user (T 0700/16 (Meal axes/HOFFMANN-LAROCHE)).

There are several lines of case law indicating the kinds of problem that are considered technical. One kind of problem considered technical is to provide “a continued and/or guided human-machine interaction process”. However, reassuring feedback was not considered enough to “guide” the user to complete a gesture in T 2630/17 (Feedback on gesture input/APPLE). The process is not considered continuous if it relies on user evaluation of displayed information, as in T 1139/16 (Bestätigungselement/KARL STORZ). This situation is sometimes referred to by the boards as “a broken technical chain”.

An interesting case where more detail made the difference is T 1648/13 (Video editing/CORE WIRELESS). The main request defined the arrangement of display of two video streams, but with no apparent purpose for the arrangement, and was rejected. However, an auxiliary request that defined features relating to user input was found to improve an editing process and so was technical and non-obvious. Just displaying the video streams was a mere presentation of information, but the addition of editing features turned it into “a continued and/or guided human-machine interaction process”.

Another kind of problem considered technical is automatically indicating the internal state of a machine. However a distinction has to be drawn between the state of the machine and the state of a program running on the machine. In T 2261/14 (Selective time stamp display/BLACKBERRY) the board held that a time stamp linked to a message sent by an electronic device represents information related to the internal state of the electronic device, namely the time when the electronic device sent the message.  On the other hand T 2630/17 (Feedback on gesture input/APPLE) held that “not every internal state variable in a running computer can be considered a “technical condition” prevailing in the computer and that, therefore, the display of an internal state variable of a running computer program cannot, by itself, establish that a technical problem is solved.”

A further strand of arguments for technicality is that the improvement in the interface is based on technical issues of the machine on which it is used. For example T 1170/15 (Image processing of hand gestures for issuing commands/Sony) held that “to reduce the computational effort needed for detecting a hands movement” is a technical problem. A common argument is that an invention provides an interface adapted to a limited display, often a display of a mobile device. This argument failed in T 0064/16 (Database navigation/DASSAULT SYSTEMES) because the board considered that the claimed features, whilst achieving a compact display, were “typical for a graphical designer” and non-technical. Contrasting with T 1648/13 mentioned above, features relating to the user’s interaction with the display did not help because they did not relate to actions beyond changing the display of information.

Simple changes such as assigning more popular commands to short user input actions (T 2554/16 (Multi-context media control/SPOTIFY)) or combining two commands into one (T 0195/14 (Switch command/HTC)) were considered obvious.

Clarity and Sufficiency

The EPO recognises the claim categories method, apparatus and product (often created by the method or apparatus) and usually considers a claim to a “system” to be apparatus (hardware). However in T 1499/17 (Pathway recognition/UC) board 3.5.05 observed that ‘claims for an “ecosystem” are unheard of. An “ecosystem” neither has an established meaning in the relevant art nor can be construed as an apparatus solely because it has the word “system” as a sub-string.’

In T 1125/17 (Parallelizing computation graphs/AB INITIO) board 3.5.06 commented, obiter, that a “computation graph meant to be executed is, essentially, a computer program.” However, the fact that such a graph may be “easier to parallelise” does not provide a “further” technical effect in the absence of a parallel execution platform in the claim. The mere potential for a speed-up by parallelization was not sufficient.

A common issue in some fields of technology is whether a claimed invention provides a technical effect across the entire scope of the claim. This issue rarely arises in the software field but two cases raised similar issues in 2019. T 2223/15 (User-configurable multi-function key entry timeout/Doro) and T 1882/17 (Malware detection/QUALCOMM) refused cases for not demonstrating that a technical effect “is credibly achieved over essentially the whole scope of protection sought”.

In T 1164/15 (Printer colorant usage/IPC) the application was rejected because ‘the claimed printer controller is defined solely as a “black box” rather than specifying its essential properties for actually finding an optimised trade-off’.

Footnotes

1. Translation by Google