Review of EPO Software Decisions in 2018

Fate of cases in 2018 in which some feature was found non-technical

Inventive step

The first case in 2018 to cite CardinalCommerce was T 1722/12 (Dynamic ad placement/ALCATEL LUCENT – GREENEDEN U.S HOLDING II) which concerned a system to serve advertisements while taking account of the current availability of resources to service people who might respond to those advertisements. Although the Board disagreed with the Examining Division’s analysis of what in the claim was non-technical, they still found the claim to be mostly non-technical and the remaining technical features to be obvious. Specifically, the Examining Division had considered a step of “storing advertisements” to be non-technical, but the Board, applying the CardinalCommerce approach held that “while the advertisement itself is cognitive content, which belongs in the non-technical requirement specification, the step of storing it is part of the technical implementation.”

In T 2079/10 (Control of Cellular Alarm Systems/SWISSRE) the Board again disagreed with the Examining Division’s analysis of the technical content of the claims and remitted the case for re-examination. Crucially, the Board held that a “gridwise graduated propagation of measurement parameters between [dual-cell and grid-based] structures for generating activation signals on the basis of a lookup table cannot in the opinion of the Board be regarded as a requirement of a pure business procedure. Rather, this also requires engineering considerations in the context of a cellular structure where input layer and output layer do not have to overlap and mapping is required.” Since these features had not been properly searched, the case was remitted for further search and examination.

Board 3.5.01 in T 0144/11 (Security rating System/SATO MICHIHIRO) started with a summary of CardinalCommerce and went on to say:

A corollary of this approach, and what is seen in practice, is that a problem of the type “implement [the business requirement]” will normally never lead to an allowable claim. Either the implementation will be obvious or have no technical effect, or if not, the implementation will have a technical effect that can be used to reformulate the problem essentially to “achieve [the effect of the implementation]”. However, the implementation-type problem is just a starting point that might have to be modified when the implementation is considered. It helps when a technical problem is not apparent at the outset. Examining the business requirements like that and correctly establishing what is to be implemented ensures that all technical matter arising from the idea of the invention and its implementation is taken into account for inventive step.

In the Board’s view, another constraint is that the technical skilled person must receive a complete description of the business requirement, or else he would not be able to implement it and he should not be providing any input in the non-technical domain.

In other words, if the only problem that can be formulated is to implement a business method then there is little chance of grant; it is necessary to formulate a more specific problem involving some technical issue. The subsequent detailed analysis of the features of the alleged invention found nothing technically inventive. The invention concerned rating securities and the most borderline “technical” feature seems to have been the idea of counting transmissions of information about the securities. As the board said, counting transmissions “does indeed sound technical” but the board considered it merely a measure of the popularity of the securities being rated.

The final decision in 2018 citing CardinalCommerce was T 0136/13 (Location-based advertising/LOCATOR IP) which concerned advertising tailored on the basis of position tracking. The Board 3.5.01 held that:

the idea of providing targeted advertising based on the user’s real-time location within a store, and the time that the user spends in proximity to certain products, can be formulated by the business person. This sort of concept does not rely on any technical knowledge or skill. Therefore, it is part of the business requirements that the technical implementation has to meet.

All of the technical infrastructure for implementing the invention was known in one document and the processing of the information was held to merely follow from the business requirements, hence there was no inventive step.

The same applicant also had a case before Board 3.5.06 – T 1325/17 (Location-based dating/LOCATOR) – but with no better outcome. Although the invention was again rejected for lack of inventive step, the Board did criticise the decision under appeal for not identifying a motivation to modify the prior art, even where the objective problem is considered to be to find any implementation of a business method.

The board identified two common situations for such inventions. Firstly, the prior art might consist of a platform on which the business method could be implemented. In that case a refusal decision should cite “an argument as to why the skilled person would have chosen the known platform to implement the method”. Secondly, the prior art might be an implementation of a different non-technical method on some platform, in which case “an argument is required as to why the skilled person would have considered modifying or replacing the disclosed method.” These comments could be seen as applying the “could/would” test (under which it is not enough to show that the person skilled in the art could have arrived at the invention, it must be shown that he would have) to non-technical matters and are perhaps out of step with other case law, especially of Board 3.5.01.

However, Board 3.5.06 was consistent with Board 3.5.01’s CardinalCommerce line of case law in T 2101/12 (Authentication binding document with signature/VASCO) where they distinguished between the viewpoints of a legal person and the technical person skilled in the art.

A few cases make general comments on what is common practice, and hence obvious, to a skilled programmer. For example T 2324/12 (Persistent Security/HEWLETT-PACKARD DEVELOPMENT CO.) and T 1872/12 (Resource grid/ORACLE) observe that the partitioning of functions between different programs, operating systems or BIOS is common practice.

Given the new section in the Guidelines for Examination (F-IV, 3.9.1) covering approaches to claiming inventions in distributed computing environments, it is worth noting that T 0827/13 (Providing cloud storage/SAMSUNG ELECTRONICS) held that it was not inventive merely to do something in a cloud-based environment but an invention can lie in how that is achieved.

Technical and non-technical subject matter

The CardinalCommerce approach only goes so far in separating technical and non-technical features. Given the boards’ steadfast refusal to define “technical” we must continue to look at examples of what is technical and where abstract features can be considered technical through close association with technical matters.

A useful example of abstract information being considered technical is T 2539/12 (Searching a hierarchically structured database/SOFTWARE AG) where search indexes were considered to be data structures which provide access to stored data, and hence, to contribute to the technical character of the claimed method. Similarly in T 0650/13 (Adaptive data compression/GOOGLE) a compression algorithm was regarded as technical because “the term ‘compression’ itself implies the storage or transmission of the encoded data”.

Usually, the use of real world and/or real time data such as location, environmental information or weather is regarded as technical (e.g. T 0956/17 (Weather and environmental sensor network/LOCATOR) but in T 2313/12 the use of user location data did not contribute to the technical character of the invention because it was used to provide subjectively improved recommendations.

In several cases, Boards have regarded features as non-technical because they relate to user preferences, for example:

• playlists (T 2469/12 (Generating a subgroup of media items/MICROSOFT TECHNOLOGY LICENSING))
• the desire to view only highlights of media content (T 1547/13 (Additional information/SAMSUNG ELECTRONICS))
• which different media streams could be combined (T 0823/13 (Reproducing device/SONY))

Business methods

In 2018 there were quite a few attempts to patent computer-implemented business methods. None were successful. Methods and concepts that the boards considered to be unpatentable included:

• consolidating multiple accounts to facilitate servicing efficiency, to reduce transaction costs, and to analyse account data with respect to business or legal rules (T 0744/12 (EXCHANGE OF FINANCIAL INSTRUMENTS/CREDIGY))
• paying a commission to a person based on a number of leads (T 0678/12 (Affiliate advertising/SONY))
• monitoring use of supplies in a commercial laundry (T 2516/12 (Laundry monitoring/ECOLAB))
• outsourcing the construction and operation of a webshop (T 1466/11 (WebShop) of 25.1.2018)
• generation of personalised commercials for inclusion in a personalised radio program (T 2372/12 (Individualized radio program/SONY))
• matching requests and bids and requiring them to be submitted on a standard form (T 0436/12 (Matching electronic proposals to electronic requests/GENESYS))
• “queuing a bid, offer, buy or sell” to trade at a certain price and holding back these bids or offers until a certain price can be obtained (T 0657/12 (Electronic training/ESPEED))
• an expert system for the purpose of concluding contracts between the service user and the provider (T 2048/11 (Transactionsserver/SWISSRE))
• automatically creating planograms (diagrams representing the position of products on shelves in a shop) (T 2214/12 (Extracted planogram/ACCENTURE))

In a couple of cases, the boards disagreed with the examining division’s analysis of what is technical and what not, and remitted the cases for further examination. In T 2328/13 (Automatic selection of a home agent/QUALCOMM) the Board 3.5.03 held that moving the home agent of a mobile subscriber in a mobile communication network was not merely a business policy decision as it has “technical consequences, for example concerned with hand-over from one base station to another which will impact on the various tunneling connections required.” This decision is difficult to reconcile with T 0630/11 (Gaming Server/Waterleaf) which rejected an argument that a feature should be taken into account for inventive step because it had “technical implications”. The difference between technical consequences and technical implications seems quite fine, although the outcomes in each case seem reasonable given the inventions at issue.

Board 3.5.01 heard T 0658/12 (Network order system and network server/FUJIFILM) and held that features relating to authentication and identification information as well as what databases to use for what purpose are technical and go beyond what can be considered to be notorious knowledge. Therefore the case was remitted for further examination. No detailed reasoning for why these features were to be considered technical is given so the case is of little precedential value.

The refusal of the application in T 1384/15 (Class-action prediction/SWISS RE) seems quite unsurprising since the case concerned predicting the likelihood of a class action being filed based on searching social media and other data sources. In response to a variety of arguments, the Board made some statements of principle, in particular:

• Although it is true that automating a particular activity by suitably programming a computer is technical because it involves the use of technical computer means, it does not follow that all the steps involved in automating the activity are technical.
• [T]he mere fact that [an] idea lends itself to being implemented on a computer … does not mean that it is technical.

The claims at issue in T 1546/12 (Responsive object proxy/AVAYA) contained plenty of technical features in the form of sensors and communication devices, but the Board found these to be not novel or not inventive so that inventive step turned on the feature of “a scheduler (151) comprising hardware and software modules configured to make a reservation based on a response from the proxy (121)”. The Board considered that making a reservation was not technical and so did not contribute to inventive step.

Two cases relating to advertising resulted in refusals. In T 0904/14 (Location aware product placement/NOKIA TECHNOLOGIES) Board 3.5.07 stated that “the provision of a location-specific advertisement is not a technical effect. In the present case, the underlying business problem is how to provide location-specific advertisements to users located in an area where the advertisement is potentially interesting. This problem is formulated by the business person.” This statement is consistent with CardinalCommerce, albeit that case was not cited.

In T 1568/13 Board 3.5.04 again took a consistent approach, commenting that “[d]isplaying advertisements or ‘product placement’ serves a commercial purpose. Hence, the problem that the viewer – when confronted with an advertisement – switches to a different channel is a commercial problem which essentially concerns a person active in the marketing of products.” The board also stated that “the effect of increased user satisfaction is a commercial one.”

Design/simulation/modelling

It has been long established that methods of design, simulation or modelling of technical systems are patentable, but several cases in 2018 illustrated that the technical system must be specified in the claim and the purpose of the modelling must be technical. The latter requirement was not met in T 2331/10 (Operating wind turbines/GENERAL ELECTRIC COMPANY) which aimed to make sales of electric power generation with increased confidence. The board also took the view that there is no control of a “physical process” based on a mathematical model, as stated in T 953/94, because the production forecast is used to facilitate revenue generation.

In T 0855/15 (Security architecture/WONDERWARE) the board considered that the claims were not concerned with any specific industrial process and doubted that the specified aim was achieved. They also reiterated early case law that a programming system does not solve a technical problem merely because it makes the programmer’s task easier (see e.g. T 1630/11). Much the same grounds for refusal were given in T 1565/17 (Configuring a system-of-systems with membrane computing/SIEMENS) which the board thought was lacking in any specific indication as to how the computed configuration might solve a concrete technical problem.

The claims at issue in T 0988/12 (Network deployment simulator/ACCENTURE) failed to “establish any clear, technical relationship” between various parameters, for example the number of cell sites and the spectrum, and did not define the complete relationships between the parameters. Overall it seems that the board felt that the invention was really about economic rather than technical issues of running a mobile communications network.

A similar point arose in T 0379/11 (Bewertung technischer Hilfsmittel/ABB AG) which had claims directed to a “method for the systematic evaluation and classification of technical equipment” but without really specifying what that technical equipment was. The board said the invention “does not solve a technical problem, but rather a purely administrative problem with the aim of making an administrative decision on the costs and lives of the evaluated resources. Furthermore, the use of knowledge-based methods for determining weighting factors or characteristics in the evaluation method according to the invention represents a use of purely mathematical concepts and models, with a non-technical objective.” An auxiliary request limiting to transformers was also rejected in view of prior art.

Computer science

Inventions in the field of computer science can in some cases derive technical character from the technical nature of the data being processed, and in other cases, from a technical improvement in processing data independently of the nature of the data itself. However, inventions where the data is too abstract, or is non-technical in nature, can fall between these two categories.

Thus, it is instructive to contrast T 2707/16 (Dynamically generating multiple hierarchies/MICROSOFT TECHNOLOGY with T 0841/16 (Business rule interface/AB INITIO). The latter case concerned a graph-based system for editing and compiling business rules where neither the nature of the data nor the alleged advantage of improved editing were considered technical. In the former case it was held that “the use of caching for dynamically generated data (i.e. the data polyarchy) with an authoritative store is a technical concept that serves as a compromise between higher scalability and fast response times for query processing on the one hand and freshness of the data on the other hand and that this goes beyond the notoriously known use of caching in general. Consequently, the Board considers that the claimed implementation achieves the technical effect of higher scalability of query processing on a server by means of a particular application of caching which reflects further technical considerations.” The claims at issue, which were remitted for further prosecution, did not specify the nature of the data being searched.

Independence of the nature of the program being executed also contributed to technical character in T 2052/15 (Asychronous antivirus processing/KASPERSKY) where an increase in the responsiveness of a computer by using computing resources in an asynchronous manner was considered a technical solution to a problem.

A rare case of the implementation of a non-technical method being considered technical is T 2330/13 (Checking selection conditions/SAP). This concerned a method for checking whether selected options for a “configurable product” (e.g. a car) are consistent before manufacture. The Board considered that the term “configurable product” did not confer technical character because it did not exclude non-technical products, such as insurance policies. However they did consider that “the specific claimed bit (sub-)matrices, bit strings and steps of the method, especially those of splitting the bit matrix, forming bit strings representing the selection and restriction conditions and determining inconsistent pairs of selection conditions when performed by parallel processing, do contribute to the technical character of the invention and should be taken into account when assessing inventive step.” The case was therefore remitted for further prosecution.

Given that computer programs are considered non-technical, it is perhaps not surprising that even higher abstractions such as programming languages and systems for assisting programmers have been rejected. In 2018, examples include T 0790/14 (Programming language construct/MATHWORKS), a programming language for mathematical operations; and T 2497/12 (Java RMI integration/MATHWORKS), a system for integrating programs in different languages.

Graphical and other user interfaces

As in previous years there were many cases relating to user interfaces, primarily GUIs. The main precedent in this area continues to be T 336/14 which sets a test of whether an alleged inventive user interface assists the user “by means of a continued and/or guided human-machine interaction process”. This approach was applied in T 1868/15 (Backup Management/APPLE) where a set of thumbnails representing backups were provided in a timeline which the board considered to “facilitate the efficient searching and restoration of a past version of a file”. Animation of the thumbnails was however not considered to provide a technical effect.

In T 0063/12 (Visually modified application icons/BlackBerry), the Board considered that modifying an icon of a communication application to indicate a count of unread messages was technical under the above criterion, but nevertheless considered the invention to be obvious.

However, the invention in T 1185/13 fell the other side of the line because a claimed user response was essential to the operation of the invention and a claimed message did not convey “functional data, essential to the operation of the [invention], rather than cognitive data, exclusively aimed at the mental activities of the user”.

Many graphical user interfaces are constructed on the basis of analogies to the physical world, but this can often be unhelpful to applicants. For example, in T 2028/11 (Overlapping icons/LG) the board considered that overlapping icons in a compact display was directly analogous to overlapping documents on a desk, and hence obvious.

In two related cases, T 1860/11 (3D Motion User Interface/HTC) and T 1861/11 (3D Motion User Interface/HTC) the board held that a “conceptual metaphor”, involving an abstract three-dimensional object, seemingly a cube, on which user interfaces were arranged, was not clearly disclosed.

Problems and features in user interfaces that the Boards considered to be technical included:

• Optimising presentation of displayed characters in portrait and landscape modes, T 1696/14 (Virtual keypad switching for portrait/landscape modes/SAMSUNG)
• using virtual function keys associated with the address field of a web browser, T 0505/13 (Adaptive web browser/NOKIA TECHNOLOGIES);
• controlling manipulation of icons in a GUI, T 1046/14 (Icon manipulations on touch screen/OPTIS CELLULLAR)

Problems and features considered non-technical included:

• displaying thumbnails of movie scenes adjacent a progress bar to facilitate searching for a scene T 2073/12
• displaying time varying data in tables T 0995/14 (Displaying time variant tabular data/SAP)
• interpreting strokes on a touch screen as functions rather than characters T 2074/12 (User-interface features for computers with contact sensitive displays)
• presentation of icons in default format T 0554/14 (Presentation of scrolling icons/BLACKBERRY);

A more complex case, covering several common themes in GUI inventions is T 1066/13 (Photo tag selection/BLACKBERRY). The claims of the main request were rejected as non-inventive because the problem of tagging photos, and the nature of the tags – friends or addresses – were considered non-technical. However, an auxiliary request including additional features relating to the source of tags and user interactions with the tags was considered technically inventive. The board thought that the additional features “define an advanced and complex type of user interaction with menu options” and the prior art was not suitable for implementation in “a device with a reduced display and limited input capabilities.”

Security

2018 saw quite a few notable decisions relating to security issues, such as authentication, detection of intrusion, and enforcing restrictions. Often, claims are rejected as being the obvious implementation of a non-technical problem, as occurred in T 1054/13 (Network firewall/ALCATEL) where the board commented that “it is further to be noted that the indication of a name in the role’s definition is a mere representation of a cognitive content, a name, which does not imply any technical effect in relation to the network security policy.”

Similarly, in T 1073/15 (Multi-level authentication/KASPERSKY) the board observed that the “hierarchy between two users A and B can be changed by an administrative act without any impact on the functioning of the claimed system or method of operating it.” However, they went on to say “that, in general, it is a non-technical matter to determine, as a security policy, under which conditions an individual user should or should not have access to a specific resource or ‘type of resources’. Evidently, different resources in a system may have different security requirements.”

In T 1948/15 (Mutual device authentication/FUJITSU) the board disagreed with the examining division’s assessment of what was technical. They commented that:

While non-technical considerations may play a role – even a major one – in determining which parties to trust, the board is unable to see why an assessment of how well a system’s resources are protected against a malicious entity is not a technical issue. The invention proposes that a transaction should be permitted only if, inter alia, “environment information” about the software or hardware constituting the first authentication apparatus is found to be “proper”. Again, even acknowledging that the claims do not specify how that decision is made in an individual case, the board is unable to see why the fact that the software and hardware equipment of the center server is security-relevant is not a technical issue.

The board therefore agrees with the appellant that the claimed mutual authentication is a technical feature rather than a non-technical requirement of the claimed invention, and it accepts that the claimed invention solves the objective technical problem … how to improve the security of the system of D1.

However, even though all features were taken into account, the board considered the invention to be obvious.

Several cases were rejected because the boards considered that no improvement in security was achieved by the invention. In T 1307/15 (Replacement certificates/POWERCLOUD) the board held that the mere potential to improve a system’s resistance to security breaches, in particular where it may rely on a person invalidating certificates, is not a technical effect. Similarly in T 1170/12 (Rights object/III HOLDINGS) actual enforcement of permissions claimed required entities not actually claimed. The board in T 1714/12 (Image processing apparatus/CANON) was not convinced that not displaying a directory structure (file path) had a technical effect in avoiding a security risk rather than being for purely aesthetic reasons, e.g. to “tidy up” a display, or a business policy of maintaining secrecy.

A more positive outcome was achieved in T 0277/16 (Location-based computer access/GOOGLE) where the board granted the application. The invention proposes that different levels of security be applied to a device at different locations and that the device learn “familiar” locations by monitoring where successful log-ins occur. The examining division had considered this idea to be a non-technical “policy” and the invention to be a straightforward implementation of it. However, the board disagreed, stating that “this feature increases the convenience of authorized users when using their electronic devices, and thus provides a new access method balancing user convenience and security considerations.” This can be regarded as “policy” but a technical one. The distinguishing features are “intimately tied to the use and usability of the device for the legitimate user and therefore contribute to the technical character of the invention”.

Also successful was T 0832/14 (Public key checking/CERTICOM) of 7.3.2018 which can be seen as a type of “problem invention”. The invention defended against a substitution attack in a public key infrastructure-based communication system. In an opposition, the patent proprietor plausibly argued that the attack was not known at the priority date. The attack not being known, the skilled person would not have been motivated to devise a defence.

Summary

As in previous years, the boards have rejected a high proportion of cases, approximately 70% where all features are considered technical but 85% where non-technical aims or features are identified. This perhaps reflects that many of the applications now under appeal were drafted when much more lenient patent-eligibility requirements were in force in the US. Also, since there are relatively few oppositions in this field, the boards only see the cases which have been rejected at first instance. A much higher chance of success can be expected if cases are drafted with European standards in mind.