Author Archive

Database for sequences of time-stamped records: technical

The European Patent Office acknowledged a number of technical aspects of a method of organizing a database for sequences of time-stamped records occurring in continuous streams, but found the invention to be obvious. Here are the practical takeaways of the decision T 0818/16 (Time series search engine/SPLUNK) of 10.9.2019 of Technical Board of Appeal 3.5.07:

Key takeaways

The provision of events as data that can be analysed is a non-technical requirement that reflects the information needed by a data analyst.

The use of indexes for querying was well-known in relational database management systems and thus indexing cannot be the basis for acknowledging inventive step.

The invention

This European patent application relates to time series data organisation, search and retrieval. Time series data are sequences of time-stamped records occurring in one or more usually continuous streams, representing some type of activity made up of discrete events such as information processing logs, market transactions and sensor data from real-time monitors (supply chains, military operation networks or security systems). The ability to index, search and present relevant search results is important for understanding and working with systems emitting large quantities of time series data.

According to the application, existing large scale search engines (e.g. Google and Yahoo web search) are designed to address the needs of less time-sensitive types of data and are built on the assumption that data only needs to be stored in one state in the index repository, for example URLs in a web search index, records in a customer database, or documents as part of a file system. Searches for information are generally based on keywords.

The invention proposes a time series search engine (TSSE) for the indexing, searching and retrieval of time series data. One aspect of such TSSEs is the use of time as a primary mechanism for indexing, searching and/or presenting of search results.

Fig. 3 of EP 2 074 505
Fig. 3 of EP 2 074 505

Here is how the invention is defined in claim 1 (sole request):

  • Claim 1 (sole request)

Is it technical?

Since claim 1 is directed to a computer-implemented method and therefore requires the use of a computer, patent-eligibility was not an issue and was not even questioned by the board.

Turning to inventive step, the board identified two feature groups that distinguished the invention from the closest prior art. Since the board did not see a synergistic effect shared by the two feature groups, they could be treated separately concerning the questions of non-obviousness.

The first feature group was found to aim to provide event data with normalised time stamps. Here, the board noted:

The provision of events as data that can be analysed is a non-technical requirement that reflects the information needed by a data analyst. According to the established case law of the boards of appeal, when assessing inventive step in accordance with the problem/solution approach, an aim to be achieved in a non-technical field may legitimately appear in the formulation of the problem as part of the framework of the technical problem to be solved as a constraint that has to be met (see decisions T 641/00, OJ EPO 2003, 352; T 154/04, OJ EPO 2008, 46). Hence, steps B2 to B4 solve the problem of how to implement the conversion of the classified machine data into event data that can be analysed with respect to time.

As to step B2, D11 discloses parsing machine data in paragraph [0050]. According to the description of the present application (paragraph [0046]), an example of an aggregation rule for detecting beginning and ending boundaries of events consists of detecting line breaks. The Board is aware that the wording of step B2 is rather broad and that the event boundaries may be defined based on non-technical considerations or at least not based on further technical considerations (see opinion G 3/08, OJ EPO 2011, 10, reasons 13.5.1). However, in any case, on the relevant date the skilled person would have extended the parser of D11 with rules to detect event boundaries such as line breaks in the machine data without exercising inventive skill.

As to steps B3 and B4, D11 (see paragraphs [0028] and [0037]) discloses that the time stamps are received in different formats and that the data is stored in a sequentially ordered table. Moreover, D11 (paragraph [0046]) discloses that the system performance can be improved if the data is sorted (e.g. in chronological order) prior to insertion into the database. In view of this, it was obvious for a skilled person to store the database table in the sort order of the data to be inserted, i.e. in chronologically sorted order. Moreover, the skilled person would consider providing some kind of normalisation of the time stamps, such as normalisation to a common offset, as they are received in different formats. The application itself mentions the well-known Unix epoch as a common offset (description, paragraph [0049]). Hence, the skilled person would have considered using such a well-known common offset for normalisation.

It follows that the skilled person could and would arrive at steps B2 to B4 of claim 1 without exercising inventive skill.

The second feature group defined that the time stamps are used to assign the events to time buckets instantiated in random access computer memory. Here, the board took the following view:

However, the use of indexes for querying was well-known in relational database management systems and thus indexing cannot be the basis for acknowledging inventive step. Document D11 does not explain how the sorted table is actually stored, but it was usual to store such a table not in a single storage area, but in several storage areas (in the main memory or secondary storage). As the data table is sorted in chronological order, different parts of this table, which are stored in different storage areas, correspond to non-overlapping time buckets as claimed. The Board is aware that generally a further difference could be that with a sorted table the events stored within a particular part of the table are stored in sorted order, whereas the events assigned to an individual time bucket may be stored unordered. However, as steps C and D of claim 1 do not specify whether or not the data within an individual time bucket is sorted, there is no further difference which the Board needs to take into account.

In view of the above, the Board considers that, on the relevant date, the skilled person would arrive at steps C and D in an obvious manner.

Therefore, the board ultimately decided that claim 1 lacks inventive step and dismissed the appeal.

More information

You can read the whole decision here: T 0818/16 (Time series search engine/SPLUNK) of 10.9.2019

Never miss a beat by subscribing to the email newsletter. We will send you a monthly digest of new knowledge base entries, as well as occasional interesting information about European software patents. Please see our Privacy Policy for details.

* = Required field

SQL language extensions for modifying columns in a single statement: technical

The European Patent Office considered an SQL language extension for modifying collection-valued and scalar valued columns in a single statement to be technical. Here are the practical takeaways of the decision T 0697/17 (SQL extensions/MICROSOFT TECHNOLOGY LICENSING) of 17.10.2019 of Technical Board of Appeal 3.5.07:

Key takeaways

The terms “relational database system”, “parser”, “query optimizer” and “query execution engine” have well-known meanings in the field of database management systems.

Describing a technical feature at a high level of abstraction does not necessarily take away the feature’s technical character. Such a feature does not lose its technical nature just because it is too generic or functionally defined.

In order to decide whether a performance improvement of a computer program is a technical effect it has to be further determined how the improvement is achieved, for instance whether it is the result of technical considerations regarding the functioning of the technical context of the invention (e.g. computer, system, process, transmission channel).

Features make a technical contribution if they result from technical considerations on how to, for instance, improve processing speed, reduce the amount of memory required, improve availability or scalability, or reduce network traffic, when compared with the prior art or once added to the other features of the invention, and contribute in combination with technical features to achieve such an effect.

A change in the quality of a program in terms of the user preferences or other subjective criteria in principle do not give indications of a technical contribution.

A possible test for determining whether non-technical features are based on technical considerations is to consider whether the non-technical features would have been formulated by a technical or by a non-technical expert.

While a database system is used to store non-technical information and database design usually involves information-modelling aspects which do not contribute to solving a technical problem, the implementation of a database management system involves technical considerations. Therefore, a database management system is not a computer program as such but rather a technical system.

The invention

This European patent application relates to a relational database system and a corresponding method for updating values in a complex-structured-type column. According to the description, the purpose of the invention is to achieve complex and partial updates efficiently.

A complex structured type consists of a set of fields, properties and methods, wherein each field or property can be a scalar type, a complex structured type itself, or a multiset in which each element is a complex structured type. The database system of the invention 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. The system includes a parser that parses a database modification (query) statement and produces a logical description of changes to the table as specified by the UPDATE statement, a query optimizer that produces the execution algorithm that will perform the modifications, and finally a query execution engine that implements the execution algorithm.

In order to modify collection-valued columns, the execution algorithm uses a data structure named “change descriptor”. The change descriptor represents an aggregation of changes to the values in the collection-valued column and the location of the values to be updated in the hierarchy of the complex structured type column. It aggregates all changes, both scalar and collection-valued, into a single value. The query execution engine reads the change descriptor and applies the changes as described by it to the collection-valued columns in addition to using simple scalar updates for the scalar valued columns.

The change descriptor was said to enable the efficient application of multiple updates at various granularity levels in a single operation, enable the implementation of efficient index maintenance algorithms and have the benefit of separating the computation of the changes from their application itself (known as Halloween Protection).

Fig. 5 of EP 1 597 655
Fig. 5 of EP 1 597 655

Here is how the invention is defined in claim 1 (main request):

  • Claim 1 (main request)

Is it technical?

Concerning the first hurdle of patentability (patent-eligibility), the first instance examining division had taken the view that claim 1 in its entirety described a purely abstract method. The division held that the wording of the claim did not describe the method as one that was “technically realised (e.g. computer implemented)”, nor did it mention any “technical entities (e.g. a computer, a processor, etc.)”.

The board of appeal did not agree to this assessment and gave an interesting recapitulation of the legal requirements of the exclusion from patentability, citing various earlier decisions:

Claim 1 of the main request defines a method of “updating values in a complex structured type column having a hierarchical structure in a relational database system”. The terms “relational database system”, “parser”, “query optimizer” and “query execution engine” used in the claim have well-known meanings in the field of database management systems.

According to the established case law, a claim directed to a computer-implemented invention avoids exclusion merely by explicitly mentioning the use of a computer, a computer-readable storage medium or other technical means. A claim specifying e.g. a computer-implemented method, a computer-readable storage medium or a program on a computer-readable storage medium is therefore not to be considered excluded from patentability under Article 52(2) and (3) EPC (see e.g. opinion G 3/08, OJ EPO 2011, 10, reasons 10.6, 10.8.5, 10.8.6 and 10.13; T 258/03, OJ EPO 2004, 575, reasons 4; Case Law of the Boards of Appeal of the EPO, 8th edition 2016, I.A.1.4.3 and 2.4.3, e), Guidelines for Examination in the EPO, G-II, 3.3 and 3.6).

In decision T 388/04 (OJ EPO 2007, 16), subject-matter or activities that are excluded from patentability under Article 52(2) and (3) EPC were considered “to remain so even where they impl[ied] the possibility of making use of unspecified technical means” (reasons 3). But that is not the case where the claimed subject-matter does not only merely “imply the possibility of making use of unspecified technical means” but in fact clearly implies the use of concrete technical means. For example, in decision T 650/13 of 2 October 2018 the board considered that the method of claim 1 was not excluded because “transmitting the symbol in a code word to a decoder” implied the use of technical means (reasons 6.1).

In the decision under appeal, the Examining Division argued that claim 1 merely enumerated a number of logical entities, for example a “relational database system” and a “parser”, fulfilling a certain logical functionality.

The Board finds the Examining Division’s assessment to be incorrect. Claim 1 defines a “method of updating values in a complex structured type column … in a relational database system” including steps performed by modules of a database system. Claim 1 therefore defines a method performed in a relational database system. In principle, the terms used in a claim should be given the common meaning they have in the relevant technical field. In computer science, the term “relational database system” relates to a software system implemented in one or more computers for storing, controlling and processing data. Carrying out a method performed in a relational database system involves the use of a computer system. Therefore, the claimed method cannot be seen as a purely abstract method, as argued by the Examining Division, but as a method which uses technical means.

In this context, the Board notes that describing a technical feature at a high level of abstraction does not necessarily take away the feature’s technical character. As explained in opinion G 3/08, reasons 10.8.5, 10.8.7 and 10.13, the feature “computer-readable storage medium” has the technical effects of being computer-readable and of storing data, even if a more concrete technical implementation is not specified. Such a feature does not lose its technical nature just because it is too generic or “functionally defined” (G 3/08, reasons 10.8.7), or commonly known (see T 258/03, reasons 4.3).

Finally, the Board notes that there are several examples in the case law in which features of a database system have been considered as technical aspects when assessing inventive step (see e.g. T 1242/04, OJ EPO 2007, 421, reasons 3.2 and 4.3; T 1025/08 of 19 April 2013, reasons 2.12; T 1500/08 of 4 November 2011, reasons 5.9 and 5.10; T 1414/10 of 23 March 2015, reasons 4.9 and 4.10; and T 1924/17 of 29 July 2019, reasons 9 and 11 to 11.8).

The board therefore disagreed with the examining division’s assessment and had no doubt that claim 1 must be considered an invention in a field of technology within the meaning of Article 52(2) and (3) EPC.

Then, the board moved on with the assessment of inventive step, again giving a helpful summary of the legal framework concerning mixed-type inventions:

Inventive step can be based only on features that contribute to the solution of a technical problem bringing about a technical effect (T 641/00, OJ EPO 2003, 352, reasons 4 to 6). Features which are non-technical when taken in isolation but which interact with technical features of the invention to solve such a technical problem should be taken into account in assessing inventive step (see e.g. T 208/84, OJ EPO 1987, 14, reasons 4 et seq.; T 154/04, OJ EPO 2008, 46, reasons 5 (F) and (G), and 13 to 15; T 1227/05, OJ EPO 2007, 574, reasons 4; G 3/08, reasons 12.2.1 and 12.2.2). In assessing a claim it is therefore important to avoid missing any such features that contribute to a technical effect (T 756/06 of 18 April 2008, reasons 5 and 6).

As mentioned in some decisions, in practice it may be difficult to distinguish between features making a technical contribution and those not contributing, especially in cases in which the non-technical aspects are tightly intermingled with the technical features (T 154/04, reasons 15) or in which “an invention may have technical aspects which are hidden in a largely non-technical context”. Such technical aspects may be easier to identify within the framework of the examination as to inventive step (T 258/03, reasons 3.6 and 5.8).

The problem-solution approach to examining mixed-type inventions described in the Guidelines, section G-VII, 5.4, in the current version and in the version of 2015 prior to the contested decision, is based on a “two-level technicality analysis”. In a first step (i) of the approach, features are classified as either contributing or not contributing to the technical character of the invention on the basis of the technical effects achieved in the context of the invention. In step (ii) a suitable starting point is selected as the closest prior art with a focus on (or “based on” in the 2015 version) the features contributing to the technical character (Guidelines, G-VII, 5.4 (ii)). And in step (iii) the differences over the closest prior art are identified and further examined. In particular, the technical effects of these differences, in the context of the claim as a whole, are determined in order to identify the distinguishing features which make a technical contribution.

The Guidelines also explain that, due to the complexity of the task, the classification in step (i) may be performed on a first-glance basis (“prima facie” in the 2015 version) only and that the analysis in step (iii) may “reveal that some features considered in step (i) at first glance as not contributing to the technical character […] do, on closer inspection, make such a contribution” (Guidelines, G-VII, 5.4, third last paragraph).

In step (iii) the distinguishing features are identified with regard to all claim features, not only those previously identified as contributing to the technical character. All the distinguishing features are then analysed to identify those making a technical contribution, on the basis of which the objective technical problem is formulated.

In the problem-solution approach as described in the Guidelines, the two-level technicality analysis provides a review in step (iii) of the classification in step (i) of a feature as not making a technical contribution. It is important to apply the two-level technicality analysis correctly in order to avoid errors in classifying features with regard to technical contribution. In addition, if the technical and non-technical features closely interact, the starting point in step (ii) should in principle be selected with all claim features in mind, even if the focus is on those identified as contributing to the technical character.

Since the result of the classification of features with regard to technical contribution in step (i) is reviewed in step (iii), it could be argued that step (i) is unnecessary. The Board nevertheless agrees that it is useful, for instance in order to direct the search for relevant prior art, to perform a preliminary classification of features contributing to the technical character as a first step where the classification may be performed only on a preliminary basis, especially in complex cases in which the non-technical aspects are tightly intermingled with the technical features.

According to established case law, either a “conventional approach”, starting with a selection of the prior art, or an approach relying on an initial analysis of the technical character of the claim features may be adopted depending on the circumstances (T 258/03, reasons 3.5 and 3.6; T 756/06, reasons 5; G 3/08, reasons 10.13.2).

Still before looking at the specifics of the invention under consideration, the board then recapitulated the established practice regarding the assessment of technical contribution:

Some decisions have held that in certain circumstances program performance improvements may be unsuitable for distinguishing between technical and non-technical features, and that technical character is assessed without regard to the prior art. For example, according to T 1784/06 of 21 September 2012 (which cites T 1227/05), “[e]nhanced speed of an algorithm, as compared to other algorithms, is not sufficient to establish a technical character of the algorithm” (T 1784/06, reasons 3.1.2). And decision T 2230/10 of 3 July 2015 (reasons 3.6) reads:

“the determination of the claim features which contribute to the technical character of the invention is made, at least in principle (the question may in practice be left open for features which anyway are part of the closest prior art), without reference to the prior art (see T 154/04, supra, as explained in T 1358/09 of 21 November 2014, reasons 5.4). That the claimed invention might achieve better results than the method of document D1 is therefore in itself not an indication that the algorithmic modification is technical, although it may be important in the assessment of inventive step once technicality has been established. Technicality is hence more about control of technical parameters than about improvement.”

The proposition that the issue of “contributing to the technical character” may be determined without reference to the prior art does not imply that technical effects over the prior art never play a role in the process of determining which features make a technical contribution.

More recently this Board considered in T 817/16 of 10 January 2019 (reasons 3.12) that “if non-technical claim features interact with technical claim features to cause a physical effect over the prior art, such as an effect on memory usage in a general-purpose computer, the physical effect is to be regarded as a technical effect for the purpose of assessing inventive step if the non-technical features are based on technical considerations aimed at controlling that physical effect (see e.g. decisions T 2230/10, reasons 3.8; and T 2035/11 of 25 July 2014, reasons 5.2.3)”.

In addition, since a non-technical feature can only be considered to make a technical contribution if it interacts with the technical features of the invention to solve a technical problem, bringing about a technical effect, it is legitimate to establish the technical contribution of a feature by analysing the effect caused once it is added to the other features of the invention. Decision T 336/14 of 2 September 2015 affirms that “in the assessment of whether or not a feature provides a technical contribution, the feature shall not be taken by itself, but its technical character shall be decided by the effect it brings about after being added to an object which did not comprise that feature before” (reasons 1.2.2, referring to T 119/88, OJ EPO 1990, 395, reasons 4.1).

With regard to the role of program performance improvements in distinguishing between technical and non-technical features, the Examining Division’s a priori reluctance to recognise some effects as technical is not convincing. From none of the above cited decisions can it be concluded that execution time, processing speed, latency, amount of memory required or other such program performance measurements are per se non-technical measurements which cannot play a role in establishing a technical effect and determining whether a technical contribution is present. The above cited decisions merely teach that an improvement with regard to one of those performance measurements alone (“the sole”, “not sufficient”, “in itself”), is insufficient to establish technical character. In order to decide whether such an improvement is a technical effect it has to be further determined how the improvement is achieved, for instance whether it is the result of technical considerations (T 258/03, reasons 5.8; T 1358/09, reasons 5.5) regarding the functioning of the technical context of the invention (e.g. computer, system, process, transmission channel). Features that purposively use technical means to achieve such an improvement are technical.

In other words, features make a technical contribution if they result from technical considerations on how to for instance improve processing speed, reduce the amount of memory required, improve availability or scalability, or reduce network traffic, when compared with the prior art or once added to the other features of the invention, and contribute in combination with technical features to achieve such an effect (see also T 1924/17, reasons 21 to 22). In particular, the Board considers that such an effect on computing efficiency corresponds to a physical effect mentioned in the above-cited passage of decision T 817/16, reasons 3.12, or a change in a physical entity within the meaning of T 208/84, reasons 5 and 7 (see also interlocutory decision T 489/14, OJ EPO 2019, A86, reasons 11).

On the other hand, such effects and the respective features are non-technical if the effects are achieved by non-technical modifications to the underlying non-technical method or scheme (for example, a change of the business model, or a “pure algorithmic scheme”, i.e. an algorithmic scheme not based on technical considerations).

Furthermore, a change in the quality of a program in terms of the user preferences or other subjective criteria in principle do not give indications of a technical contribution. For example, decision T 598/14 of 6 November 2014, reasons 2.4, did not recognise query enhancement (meant as modifying the original user query to obtain semantically “better results”), as a technical effect because it relied on a semantic distinction and the concept of “better search” was subjective in the context of retrieval based on semantic similarity.

A possible test for determining whether non-technical features are based on technical considerations is to consider whether the non-technical features would have been formulated by a technical or by a non-technical expert (T 817/16, reasons 3.12). Since computer programming involves technical and non-technical aspects (G 3/08, reasons 13.5.1; T 1463/11 of 29 November 2016, reasons 21), it is difficult to apply that test to distinguish abstract algorithmic aspects from “technical programming” aspects. In that case, the test would have to be whether the features were determined by a “programmer as such” or by a “technical programmer”. It may therefore be preferable to directly determine whether the decision to adopt the non-technical features is a technical one (T 1463/11, reasons 21) or whether it required “technical considerations beyond ‘merely’ finding a computer algorithm to carry out some procedure” (G 3/08, reasons 13.5).

Several decisions of the boards of appeal have considered subject-matter or features which on their own are excluded to nonetheless contribute, in combination with technical features, to the solution of a technical problem bringing about a technical effect. In some of those cases, the relevant technical effect corresponded to one of the above-mentioned efficiency measures.

According to decisions T 650/13 and T 107/87, a compression algorithm contributes to the technical character of the claimed compression method if it is used for the purpose of reducing the amount of data to be stored or transmitted (T 650/13, reasons 6.3 and 6.4; T 107/87 of 26 April 1991, reasons 3).

Decisions T 1003/09 and T 1965/11 considered that the cost-based optimisation of a query in a relational database system normally had technical character (T 1003/09 of 29 April 2015, reasons 13.3 to 13.5; T 1965/11 of 24 March 2017, reasons 5.1). In particular, decision T 1965/11 found that such a cost-based query optimisation searched for low-cost query execution plans using a cost estimate for the computer resources (such as CPU, main memory or hard disk) needed to execute a query plan, and therefore involved further technical considerations relating to the internal functioning of the computer system (T 1965/11, reasons 5.1 and 5.3).

Even though data structures used to store cognitive data are not considered to contribute to the technical character beyond the mere storage of data, data structures used for functional purposes are considered to contribute to producing a technical effect (see e.g. T 1194/97, OJ EPO 2000, 525, reasons 3.3 or T 424/03 of 23 February 2006, reasons 5.2). In decision T 49/99 of 5 March 2002 the deciding board ruled that information modelling was a non-technical intellectual activity, but that the purposive use of information modelling in the context of a solution to a technical problem could contribute to the technical character of an invention (reasons 7). An object table used for storing “a system catalog supporting the technical functions of the database system” had technical character (reasons 8 to 10). In decision T 1351/04 of 18 April 2007, an index file used for the purpose of controlling the computer “along the path leading to the desired data” was considered to contribute to the solution of a technical problem (reasons 7.2). In decision T 1902/10 of 21 June 2016, a RAM-based hash table of fingerprints of stored URLs was used, in the context of web crawling, to determine whether a URL already existed in a database of processed web pages. The hash table was considered part of the solution to the technical problem (reasons 19 to 22). In decision T 2539/12 of 18 January 2018, search indexes used to provide access to stored data were considered to contribute to the technical character of the claimed method (reasons 5.5). And in decision T 2330/13 of 9 May 2018 the specific choice of the claimed bit strings and matrices and respective operations was considered to be determined by technical considerations concerning how to efficiently perform in parallel the steps of a method for evaluating selection conditions, and hence was considered to contribute to the technical character of the claimed invention (reasons 5.7.9 to 5.8).

Applying these legal considerations to the invention at hand, the board held the following:

A database management system uses data structures, software components and processing techniques for storing, controlling and processing data, and for providing an interface to let the user create, read, update and delete data. The internal data structures, such as an index and a query tree, and components, e.g. a parser, a query optimiser and a query execution engine, are used purposively for storing data to a computer storage medium and retrieving data from the medium. As explained above, the established case law considers these to be technical effects (G 3/08, reasons 10.8.5; T 1569/05 of 26 June 2008, reasons 3.6). The data structures used for providing access to data and for optimising and processing queries are functional data structures since they purposively control the operation of the database management system and of the computer system to perform those technical tasks. While a database system is used to store non-technical information and database design usually involves information-modelling aspects which do not contribute to solving a technical problem, the implementation of a database management system involves technical considerations. Therefore, a database management system is not a computer program as such but rather a technical system (see also decision T 1924/17, reasons 9, 13 and 14).

The subject-matter of claim 1 differs from standard relational database management systems in that it supports complex structured type columns. It may be questioned whether some aspects of providing complex structured type columns and deciding to support specific update operations on values of that type are technical, but implementing those operations in a relational database management system which does not support that functionality is a technical problem.

The claimed method solves that problem essentially by means of a data structure representing “values in the complex structured type column as an aggregation of changes to the values at any level of the hierarchical structure of the complex structured type column”. It has to be established whether that data structure is used to control the computer to update data in the database management system and makes a technical contribution. The claim also describes how the different components of the relational database system compute and use the data structure to update the data. It has to be assessed whether these features contribute to solving a technical problem and whether they achieve the effects alleged by the appellant.

In its decision, the Examining Division expressed the view that the “execution algorithm” was a non-technical feature which served no technical purpose, but instead consisted of a number of steps concerning the logical structure of data stored in the database, said steps being based on logical definitions of update operations. It was argued that the feature did not serve a technical purpose, e.g. it was not directed to a physical implementation, and did not involve further technical considerations, e.g. taking account of physical properties of the technical system.

In the Board’s opinion, however, the “execution algorithm” contributes to the overall technical purpose of implementing the update operation on data stored and managed by the relational database management system and to the computation of the data structure representing “values in the complex structured type column as an aggregation of changes to the values at any level of the hierarchical structure of the complex structured type column” mentioned above, and therefore has to be considered in the inventive-step assessment.

The Board does agree with the Examining Division that claim 1 provides a rather abstract description of the invention. Besides, many claimed features appear to be standard features of a relational database management system. But the claimed features do make a technical contribution over a general-purpose computer. Whether they are generic or well-known, or whether they are obvious in combination has to be judged in the context of an inventive-step assessment.

Ultimately, the board found that the first instance decision provided only a very incomplete inventive-step argumentation with respect to the cited prior art. Since the board would have had to start the inventive-step analysis from the beginning and present the appellant with new lines of reasoning to come to a conclusion with regard to inventive step, the board decided to remit the case back to the department of first instance for further prosecution.

More information

You can read the whole decision here: T 0697/17 (SQL extensions/MICROSOFT TECHNOLOGY LICENSING) of 17.10.2019

Never miss a beat by subscribing to the email newsletter. We will send you a monthly digest of new knowledge base entries, as well as occasional interesting information about European software patents. Please see our Privacy Policy for details.

* = Required field

Providing a unique code for identifying product data: non-technical

The European Patent Office refused to grant a software patent on a method of providing a unique code for identifying product data. Here are the practical takeaways of the decision T 1201/10 (Personalised interactive automated marketing/JEAN-LUC ROCHET) of 20.5.2019 of Technical Board of Appeal 3.5.01:

Key takeaways

The provision of a unique code for the identification of product data is a marketing and business idea.

The invention

This European patent application relates to providing a user with information about a product when he or she inputs a product code into a mobile phone.

The product code, also called “MInfo code”, is a unique alphanumerical code which is integrated and visualised on each publication and advertisement of the product. A marketing website, called “MInfo portal”, of a marketing service provider, maintains a marketing database with product data information. It receives the “MInfo code” per SMS via an SMS gateway from the mobile phone of the end-user and transmits the requested product data information to the end-user. This can be done by means of “modern communication tools”, e.g. fax, e-mail and/or via the end-user’s homepage on the marketing website.

According to the appellant, the invention does not require any prior set-up or registration on the part of the user. A user’s account and webpage are accessible from the home page of the MInfo portal (computer), just by entering a user’s mobile phone number (as authorisation data). There is no need for a user to set up an account with a username and password.

Fig. 1 of EP 1 402 441
Fig. 1 of EP 1 402 441

Here is how the invention is defined in claim 1 (main request):

  • Claim 1 (main request)

Is it technical?

The first-instance examining division took the position that claim 1 of the main request consisted of a mixture of technical and non-technical aspects to address a problem of a business nature, namely that consumers showed an unsatisfactory level of confidence in e-commerce, which required expensive conventional marketing operations, e.g. the advertisement of products in the media, printing of brochures and others. Furthermore, access to product data in prior art systems was time consuming. This, in summary, represented a marketing method.

The examining division then reasoned that the invention solved a business problem rather than a technical one by providing product codes, so-called MInfo product codes, which were unique for each product and which were integrated on each publication and/or advertisement of product appearance. Each code allowed a customer to indicate interest in information on the particular product identified by the product code.

The Board of Appeal agreed that the provision of a unique code for the identification of product data is a marketing and business idea.

Concerning specifically the differences over the closest prior art as argued by the appellant, the Board took the following view:

The appellant argued that claim 1 differed from D2 in that the invention employed a “unique code” for a given product. This reduced the number of database entries, improved efficiency and reduced storage space.

The Board disagrees. Both codes (“Kennungen”) in Figure 2 and the introductory part of D2, have the same function and the person skilled in the art would combine the disclosure of the introductory part with the one of Figure 2.

The appellant argued that the MInfo code was not the database keycode.

The Board does not see that there are two different codes existing in the present application; one attached to the product data and a different one for retrieving the product data stored in a database. The application, page 6, second paragraph, does not make such a distinction; the user inputs a “product code” which is the same as the one which is integrated and visualised on each publication.

The appellant further argued that the term “authorization data” did not correspond to the password in D2.

The Board disagrees. In the invention “authorization data” is exchanged between a user’s PC and the MInfo portal, see page 9, lines 1 to 4, prior to transmitting requested product data from the marketing database server. The purpose of “authorization data” is to limit access to the product data. As discussed above, throughout the description, the feature “authorization data” is described “such as phone number and name”. In D2, access to product data is restricted and the identification of a user and a password is required, see page 22, lines 9 to 14.

The Board therefore concluded that claim 1 of the main request lacks an inventive step over D2 in combination with common general knowledge.

More information

You can read the whole decision here: T 1201/10 (Personalised interactive automated marketing/JEAN-LUC ROCHET) of 20.5.2019

Never miss a beat by subscribing to the email newsletter. We will send you a monthly digest of new knowledge base entries, as well as occasional interesting information about European software patents. Please see our Privacy Policy for details.

* = Required field

De-identifying data for privacy reasons: non-technical

The European Patent Office refused to grant a software patent on a method of de-identifying data for privacy reasons. Here are the practical takeaways of the decision T 1248/12 (Privacy preserving data mining/CROSSIX) of 12.3.2019 of Technical Board of Appeal 3.5.01:

Key takeaways

De-identifying data, by removing individually identifiable information, and by aggregating data from a plurality of sources, is not technical.

Protecting data privacy is not a technical problem. The problem of data privacy is not synonymous with data security. Data privacy concerns what information to share and not to share (and making sure that only the information that is to be shared is shared), whereas data security is about how to prevent unauthorised access to information.

The invention

This European patent application concerns data privacy in a database system.

The processing of privacy sensitive data, e.g. medical records, is subject to legal restrictions. For example, the Health Insurance Portability and Accountability Act 1996 (HIPAA) in the USA prevents health care providers from sharing individually identifiable health information with third parties, such as researchers or pharmaceutical companies. Similar data privacy laws exist in Europe, and in other jurisdictions.

However, it is possible to share de-identified data that does not identify or provide information that could identify an individual. But de-identification is a lossy process in that information is removed. Therefore, it might not be possible to extract certain information from the de-identified data, even if this information does not breach individual privacy. The invention seeks to overcome this problem.

Fig. 1 of EP 1 761 893
Fig. 1 of EP 1 761 893

Here is how the invention is defined in claim 1 (main request):

  • Claim 1 (main request)

Is it technical?

Claim 1 defines a data mining protocol that operates between an “aggregator” and a number of “source-entities”. The “source entities” correspond to health care providers. The “aggregator” is a trusted, central processor.

According to the appellant, the claimed data-mining protocol is as follows: A user, for example a researcher who wants to get information about a group of people, inputs a query including, for example, the names or IDs of the people in the group. The query (or “parameter list”) is sent via the aggregator to the source entities that store the data. The source entities collect the relevant data into files (the data items are “crunched together”), they de-identify the data to a certain extent, for example by removing addresses, and send the files to the aggregator that aggregates them into a data warehouse. The aggregation further protects privacy by de-identifying the source-entities. The aggregator also extracts query-relevant data from the data warehouse, and presents a condensed (“agglomerated”) extract to the user.

The board of appeal did not share the appellants view that de-identifying data is technical. Interestingly, the board made a distinction between data privacy, which was considered non-technical, and data security:

The Board shares the examining division’s view that de-identifying data, by removing individually identifiable information, and by aggregating data from a plurality of sources, is not technical. It aims to protect data privacy, which is not a technical problem. The problem of data privacy is not synonymous with data security. Data privacy concerns what information to share and not to share (and making sure that only the information that is to be shared is shared), whereas data security is about how to prevent unauthorised access to information.

It is established case law that non-technical features cannot contribute to inventive step. Therefore, non-technical features may legitimately be part of the problem to be solved (T 641/00 – Two identities/COMVIK), for example in the form of a requirement specification given to the skilled person to implement.

The board considered a generic data processing system to be the closest prior art, which includes at least a database system corresponding to the source-entities in claim 1. Regarding the distinguishing features of claim 1, the board took the following point of view:

[T]he steps of de-identifying the data at the source and aggregating the results from a plurality of sources is part of the non-technical requirement specification to be implemented. So is the presentation of the result in a condensed form.

The skilled person having been given the task of implementing the requirement specification would provide an “aggregator processor”, because that is what the requirement specification (“aggregate the results”) is telling him to do. The aggregator processor and the database system (source-entities) need to communicate with each other: the source entities need to obtain the query and the aggregator processor needs to obtain the query results. The skilled person would find suitable formats for this. The Board notes that the claims do not specify any particular format beyond the use of a “list” and files. The processing performed by the source-entities (de-identifying) and aggregator (aggregating, extracting and agglomerating), and the presentation of the results to the user, does not go beyond what the requirement specification dictates.

Thus, the skilled person would have arrived at the subject-matter of claim 1 without inventive effort.

For these reasons, the board concluded that claim 1 lacks an inventive step.

More information

You can read the whole decision here: T 1248/12 (Privacy preserving data mining/CROSSIX) of 12.3.2019

Never miss a beat by subscribing to the email newsletter. We will send you a monthly digest of new knowledge base entries, as well as occasional interesting information about European software patents. Please see our Privacy Policy for details.

* = Required field

Charging for content consumption: non-technical

The European Patent Office refused to grant a software patent on a method of charging for consuming dynamic content according to rules defined in server-side and client-side policies. Here are the practical takeaways of the decision T 0239/14 of 13.6.2019 of Technical Board of Appeal 3.5.01:

Key takeaways

Providing part of the rules of a billing model at the side of the client, rather than the server, is not of technical relevance.

Licence terms are not technical, since they are cognitive data, not functional data.

The invention

The invention underlying this European patent application concerns charging for consuming (e.g. downloading) dynamic content according to rules defined in a server-side charging policy, and the provision of licence terms in a client-side policy.

Fig. 1 of EP 1 379 983
Fig. 1 of EP 1 379 983

Here is how the invention is defined in claim 1 (main request):

  • Claim 1 (main request)

Is it technical?

First of all, the board acknowledged that claim 1 includes at least some technical features (a client and a server computer system), so that the invention passes the patent-eligibility hurdle:

The claim is directed to a mix of technical and non-technical features. The Board does not dispute that the method according to claim 1 appears in a technical context. The claimed method can be considered to be performed by technical means, because it involves a client and a server, i.e. inter-related devices with means for storing processing, transmitting, and receiving data. The overall subject-matter of claim 1 therefore, has technical character. Consequently, the claimed subject-matter is an invention in the sense of Article 52(1) EPC (see T 258/03 – Auction method/HITACHI).

But as the skilled reader will know, the presence of an inventive step requires the features distinguishing the invention from the prior art to contribute to the solution of a technical problem:

However, the question of inventive step requires an assessment of whether the invention makes a technical contribution over the prior art. Features, which do not make such a contribution, cannot support the presence of an inventive step (see T 641/00 Two identities/COMVIK, Headnote I). The non-technical features may instead be included in the framework of the technical problem that the skilled person has to solve (Headnote II).

Following the board’s assessment, the only difference over the closest prior art was that the “authorization of said user to consume said content unit is defined via license terms within a client side policy“. According to the board, this is not a technical difference:

The contribution is not a technical one, since it lies in the association of digital content with an authorization for its use/consumption.

What is called “client side policy” and “server-side policy” represents the underlying billing model in a mobile communication client-server environment. By providing part of the rules at the side of the client, rather than the server, they might be available offline (see page 12, lines 24 to 33). However, the Board does not regard this to be of technical relevance. The appellant has not brought forward convincing arguments to the contrary. The Board considers this split of rules between the client and the server to be part of the billing concept, which is provided to the skilled person as a set of requirements to implement. It is not the technically skilled person who comes up with the split in order to solve a technical problem.

The client-side policy defines license terms, i.e. rules specifying what the user can and cannot do with the content. For example, the licence terms could specify a limited period of usage or a limited number of uses (see page 12, lines 27-28 in the published application). In the Board’s view, those are administrative rules, which do not contribute to the solution of a technical problem.

Furthermore, the licence terms are not technical, since they are cognitive data, not functional data in the sense of having a technical effect (for this distinction see T 1194/97 Data structure product/PHILIPS, OJ EPO 2000, 525). The storage, selection, and processing of such cognitive data is an administrative measure, such as would be performed by a human when charging for consumed dynamic content, making use of general purpose computer or mobile communication device functions (e.g. transmitting, receiving, storing and retrieving information and content in electronic form) without creating a further technical effect.

The fact that steps of the claimed method are performed automatically is a mere consequence of implementing the non-technical billing model in a mobile communication client-server environment. Indeed, the automatic processing is already achieved in D1 (see the communications system underlying the MOBIVAS architecture in figure 1). D1 not only discloses the technical infrastructure necessary for implementing the non-technical billing concept, but also a significant part of the billing concept itself (see point 2.3 above).

Therefore, claim 1 was found not to involve an inventive step:

In the absence of any technical contribution beyond the straight-forward computer-implementation, the subject-matter of claim 1 does not involve an inventive step (Article 56 EPC) in view of D1 and the skilled person’s common general knowledge.

More information

You can read the whole decision here: T 0239/14 of 13.6.2019

Never miss a beat by subscribing to the email newsletter. We will send you a monthly digest of new knowledge base entries, as well as occasional interesting information about European software patents. Please see our Privacy Policy for details.

* = Required field

Authenticating individuals based on liveness probability: non-technical

The European Patent Office refused to grant a patent on a method of authenticating financial transactions based on biometric data. Here are the practical takeaways of the decision T 1386/14 (Fraud resistant biometric financial transaction / EYELOCK LLC) of 12.6.2019 of Technical Board of Appeal 3.4.01:

Key takeaways

The choice of “liveness” as criterion for authenticating an individual is a non-technical decision as to what sort of identification is acceptable.

A prerequisite for the existence of an inventive step is the existence of a technical difference that provides a technical effect.

The invention

This European patent application concerns biometric identification and authentication methods, in particular for authenticating financial transactions using biometrics.

According to the application, one problem faced by biometric recognition systems involves the possibility of spoofing, e.g. when an imposter presents a life-sized, high-resolution photograph of a person to an iris recognition system. To this end, known systems try to determine liveness of the subject to be authenticated, e.g. by shining a light onto the eye and determining whether the pupil dilates. The patent application criticizes that in prior art systems which determine liveness, the liveness test is conducted first, prior to the match process, i.e. the calculation of the probability of a match between acquired biometric data from the individual being authenticated and data acquired from known individuals.

Fig. 2 of EP 2 100 253
Fig. 2 of EP 2 100 253

Here is how the invention is defined in claim 1 (auxiliary request 4):

  • Claim 1 (auxiliary request 4)

Is it technical?

The board of appeal based its assessment of inventive step on a prior art document which concerned biometric authentication systems:

Document D8 concerns biometric authentication techniques. It focuses on the merits of multibiometric systems, that is, on systems making use of multiple biometric sensors for data acquisition. (…) In one category of multibiometric systems, data are fused together at the decision level, that is, at the end of the decision process. Such a configuration, as described in section “2.2 Fusion at the Matching Score Level” of D8, was considered as closest prior art by the Examining Division in its rejection of auxiliary request 2 (then pending) for lack of inventive step. (…) In view of the fact that multibiometric systems indeed address the problems of reliability and accuracy of matching and further attempt to remedy the problems of spoofing identified with regard to previous techniques (cf. D8, section “Introduction”, first paragraph), the selection of D8 as starting point is justified.

First of all, the board criticized the first instance examining division for failing to apply the proper problem-solution approach:

Although details are lacking, it seems that the Examining Division meant that it would have been obvious either to replace one of the sensors of Figure 3 in D8 by a sensor indicative of “liveness” or to add such a sensor.

The Examining Division defined neither the objective technical problem solved by the claimed invention, nor the technical features distinguishing the claimed subject-matter from D8.

Both are, however, essential in the problem – solution approach. A prerequisite for the existence of an inventive step is the existence of a technical difference that provides a technical effect.

Concerning inventive step, the board took the view that the feature of calculating a probability of “liveness” is a non-technical criterion which thus cannot establish non-obviousness:

The method according to claim 1 of the fourth auxiliary request differs from the method of D8 in that it calculates a probability of “liveness”, that is, a probability that biometric data have been “acquired from a live human”. (This construes the unclear wording in claim 1, in the appellant’s favour, as reflecting the teaching of paragraph [0012] of the published application). The choice of “liveness” as criterion is a non-technical decision as to what sort of identification is acceptable. The combination of probabilities, itself, is a mathematical operation and does not contribute to the technical character of the claimed method, at least insofar as it is construed as referring to mere calculations carried out on the available biometric data. The Board notes that the claim is not concerned with the technical means by which “liveness” is measured, but only with the fact that it is “liveness”.

The same conclusion would apply to the system of independent claim 14, which requires a corresponding calculating means for calculating the probability of “liveness”. Since the system of D8 also comprises calculating means, the contribution is limited to the calculation being carried out, as such.

A consequence of the previous analysis is that no distinction of a technical nature can be identified between the claimed inventions and the disclosure of D8 (cf. T 119/11, for example).

For these reasons, the board concluded that claim 1 does not involve an inventive step.

More information

You can read the whole decision here: T 1386/14 (Fraud resistant biometric financial transaction / EYELOCK LLC) of 12.6.2019

Never miss a beat by subscribing to the email newsletter. We will send you a monthly digest of new knowledge base entries, as well as occasional interesting information about European software patents. Please see our Privacy Policy for details.

* = Required field

Managing customer queues: non-technical

The European Patent Office refused to grant a patent on a method of managing a queue of customers. Here are the practical takeaways of the decision T 0748/13 (Queue image/Q.NOMY) of 20.8.2019 of Technical Board of Appeal 3.5.01:

Key takeaways

Letting the customer choose an image to represent him/her in the queue has only a psychological effect, but not a technical effect.

The invention

This European patent application concerns a method for queue management. In queuing systems before the invention, it was common that the customer received a ticket with a number representing the customer’s place in the queue, and the customer was summoned by displaying or announcing the number. This sometimes resulted in a failed summons, because the customer did not notice that his number was being displayed or announced.

The invention deals with this problem by allowing the customer to select an image, from a set of available images, to represent him in the queue. The customer is summoned by displaying the image. According to the application, the customer is more likely to notice an image that he himself has selected.

Fig. 7 of EP 2 237 203 A1
Fig. 7 of EP 2 237 203 A1

Here is how the invention is defined in claim 1:

  • Claim 1

Is it technical?

The board started from traditional queue management systems as prior art in which the customer draws a ticket with a number printed thereon to represent his/her position in the queue. Claim 1 differed from this prior art in that the customer is able to choose an image from a selection of images to represent him/her in the queue:

In the Board’s view, the subject-matter of claim 1, differs from D1 in that the image is selected by the customer (user) from a plurality of available images presented on a display. This is the same difference as identified by the examining division in the communication of 23 February 2012. Although present claim 1 does not say that the input is received from the user (see point 4.3 above), the Board continues its analysis on that basis.

According to the patent applicant, using a self-chosen image instead of a number was inventive for the following reasons:

The appellant argued that, if the user is able to choose an image, there is a greater likelihood of the image being remembered, firstly because the act of having selected the image will be in the mind of the user, and secondly, the user is able to choose the image that he or she is most likely to remember. Thus, in the appellant’s view, the invention reduces the risk of a failed summons, which is a technical effect.

The board did not follow this argument:

The Board is not persuaded. The effect mentioned by the appellant is psychological at best, and speculative at worst. It is entirely dependent on the user’s state of mind. The Board does not see any technical effect provided by allowing the user to select an image.

The technical problem solved by the invention is the modification of the QMS system of D1 to implement the user selection. The Board agrees with the examining division that the implementation would have been straightforward and obvious to the skilled person.

For these reasons, the board concluded that claim 1 does not involve an inventive step.

More information

You can read the whole decision here: T 0748/13 (Queue image/Q.NOMY) of 20.8.2019

Never miss a beat by subscribing to the email newsletter. We will send you a monthly digest of new knowledge base entries, as well as occasional interesting information about European software patents. Please see our Privacy Policy for details.

* = Required field

EUROPEAN SOFTWARE PATENTS August 2019 updates

August came with four new decisions in the EUROPEAN SOFTWARE PATENTS knowledge base relating to data retrieval, graphical user interfaces, and automation:

Patentability of data retrieval concepts

In the area of data retrieval, one recent decision refused to grant a software patent on a method of conducting internet search from an instant messenging application. The Board of Appeal decided that the desire to enable users to perform explicitly defined web search queries is not a technical aim but rather a non-technical requirement. Searching for documents using keywords has a non-technical character, and this is not changed by the mere use of a computer system.

Patenting graphical user interfaces

Improvements in graphical user interfaces are sometimes difficult to protect with patents when they are closely related to the presentation of information (which is as such excluded from patentability).

In one case, the European Patent Office decided that a confirmation element which is provided independent of a concrete content of related information displayed to a user is non-technical. The argument was that providing a confirmation element independent of a concrete content of related information displayed to a user and independent of the subsequent cognitive processes or decisions of the user does not solve a technical problem and thus cannot contribute to inventive step.

Automation

How the EPO examines software patents

By the way, if you are interested in a deeper look into how the European Patent Office examines software-related inventions, this 30-minute video gives a concise overview of the “two hurdle” approach with lots of examples.

In the field of automation, the European Patent Office considered a self-controlling documentation for validated processes non-technical. According to the Board of Appeal, the automation of a method known in the art cannot contribute to inventive step, wherein a method also has to be considered as automated when some steps still have to be carried out a human.

Likewise, another Board of Appeal decided that tracking SWAP derivatives transaction positions is non-technical, and emphasized that the pure automation in the sense of making financial information available quickly is not considered technical by the EPO.

Fear of missing out?

Never miss a beat by subscribing to the email newsletter. We will send you a monthly digest of new knowledge base entries, as well as occasional interesting information about European software patents. Please see our Privacy Policy for details.

* = Required field

EUROPEAN SOFTWARE PATENTS July 2019 updates

July came with four new decisions in the EUROPEAN SOFTWARE PATENTS knowledge base relating to graphical user interfaces, computer security, business methods and internal control:

Patents for graphical user interfaces

Improvements in graphical user interfaces are sometimes difficult to protect with patents when they are closely related to the presentation of information (which is as such excluded from patentability).

In one case, the European Patent Office refused to grant a software patent on a method of unlocking a device by performing gestures on an unlock image. The decisive argument was that giving visual indications about conditions prevailing in an apparatus or system can only be considered a technical problem if these are technical conditions. However, providing reassuring feedback – i.e. a confirmation that the user has been doing the right thing so far – was not in itself considered a technical effect.

Patentability of computer security concepts

In the field of computer security, the European Patent Office refused to grant a software patent on a method of managing booting of secure devices with untrusted software. The decision was appealed successfully and the case was remitted to the Examining Division because erasing user data outside of the security block before allowing the execution of an unsigned operating system was found to contribute to increasing the security of the claimed device.

How the EPO examines software patents

By the way, if you are interested in a deeper look into how the European Patent Office examines software-related inventions, this 30-minute video gives a concise overview of the “two hurdle” approach with lots of examples.

Business method patents

In the field of business methods, one Technical Board of Appeal decided that an improved risk-hedging approach in credit derivative trading is non-technical. In particular, associating information with trade related data (namely trader, credit risk positions, maturity dates, delta offsets) was found not to be technical. Storage, selection, transmission and processing of such data was considered not produce a further technical effect.

Internal control

In one recent decision, the European Patent Office confirmed that the concept of allowing a computer to access a data library without reconfiguration is technical. However, the board refused to grant a software patent because the claimed solution was found to be obvious.

Fear of missing out?

Never miss a beat by subscribing to the email newsletter. We will send you a monthly digest of new knowledge base entries, as well as occasional interesting information about European software patents. Please see our Privacy Policy for details.

* = Required field

Improved risk-hedging in credit derivative trading: non-technical

This decision is a good reminder that the European Patent Office does not grant software patents on purely financial concepts. The Board of Appeal in this case decided that an improved risk-hedging approach in credit derivative trading is non-technical. Here are the practical takeaways of the decision T 1895/13 (Reducing delta values of credit risk positions/CREDITEX) of 17.1.2019 of Technical Board of Appeal 3.5.01:

Key takeaways

Associating information with trade related data (namely trader, credit risk positions, maturity dates, delta offsets) is not technical. Storage, selection, transmission and processing of such data does not produce a further technical effect.

Providing for an improved risk-hedging approach in credit derivative trading (e.g. reducing or eliminating individual delta values, optimisation using notional amounts of original trades etc.) does not have technical implications for the functioning of the data processing system.

An unspecified data format per se does not contribute to the technical character. The organisation of data in the form of a table or a spreadsheet is commonly known in the art.

The invention

This European patent application relates to electronic trading systems such as the Creditex RealTime® platform. According to the description, traders or dealers representing large financial institutions (e.g., banks and funds) routinely use electronic trading systems to enter into credit derivative transactions involving large notional amounts.

However, while being delta neutral overall (i.e., with respect to parallel shifts in the entire credit curve of a particular reference entity), a financial institution may still be exposed to short/long credit risk positions in successive maturities on the credit curve. That is, although all the positive and negative delta values may offset one another and thus add up to almost zero, the large variance of the delta positions could be problematic to the bank holding these credit positions. In addition, the bank may be exposed to default gap risk if the delta values toggles between short and long positions too quickly in successive maturities.

Against this background, the application attempts to overcome the problems associated with current risk-hedging techniques in credit derivative trading by providing techniques for reducing delta values of credit risk positions in online trading of credit derivatives.

Fig. 1 of EP 2 212 850
Fig. 1 of EP 2 212 850

Here is how the invention is defined in claim 1:

  • Claim 1

Is it technical?

Applying the established “two hurdle” approach, the board first noted that the invention as claimed was not excluded from patentability due to the presence of technical means in the claim:

The claim is directed to a mix of technical and non-technical features. The Board does not dispute that the system according to claim 1 appears in a technical context. The system involves technical means such as a processor, a user interface and a communication network and, therefore, has technical character. Accordingly, the claimed subject-matter is an invention in the sense of Article 52(1) EPC (see T 258/03 “Auction method/HITACHI“).

However, as the avid reader will already know, the second hurdle of inventive step can be overcome only based on non-obvious technical features:

However, the question of inventive step requires an assessment of whether the invention makes a technical contribution over the prior art. Features which do not make such a contribution cannot support the presence of an inventive step (see T 641/00 “Two identities/COMVIK“, Headnote I).

In the present case, most of the features of claim 1 were found to not to contribute to the technical character of the invention, namely:

The Board agrees with the contested decision at point 3.3 that the following features “per se” pertain to an administrative business related method, i.e. to the non-technical part of claim 1:

– receiving, in the online trading system of credit derivatives, a plurality of credit risk positions submitted by a plurality of trader clients, each credit risk position having a delta value and a maturity date, wherein each trader client’s submission is unknown to other trader clients;

– automatically identifying, from the plurality of trader clients, at least two trader clients who hold offsetting credit risk positions on at least two maturity dates;

– determining delta offsets to be applied to delta values of the credit risk positions held by the at least two trader clients and having the at least two maturity dates, such that an overall delta of each of the at least two trader clients’ credit risk positions remains substantially unchanged after the application of the delta offsets;

– calculating, based on the determined delta offsets, notional amounts of credit derivative trades needed to realize the delta offsets; and

– executing the credit derivative trades among the at least two trader clients.

Here is how the board argued about these features:

The contribution of the invention does not lie in a faster and more efficient information processing as argued by the appellant (see point 1 of the statement setting out the grounds of appeal). The technical infrastructure and the user interface used according to claim 1 are that of a general purpose computer which was notorious knowledge before the priority date (see for example US 2006/0036535 A1 (D1) cited in the International Search Report: figures 1, 5A, 5B, 6 and 7; para. [0036] to [0041]).

The contribution lies rather in the way of associating information with trade related data (namely trader, credit risk positions, maturity dates, delta offsets). Such data, however, in the Board’s view, is not technical, since it is cognitive data, not functional data (see T 1194/97 Data structure product/PHILIPS, OJ EPO 2000, 525). Storage, selection, transmission and processing of such data are merely implementations of administrative measures following a financial concept, such as would be performed by a human trader, when mitigating credit risk positions, making use of general purpose computer functions (e.g. storing and retrieving information in electronic form) without creating a further technical effect.

The present invention may provide for an improved risk-hedging approach in credit derivative trading (e.g. reducing or eliminating individual delta values, optimisation using notional amounts of original trades etc.) and therefore an improved financial concept. Those measures, however, do not appear to have any technical implication for the functioning of the data processing system and its interactive graphical user interface (GUI), since the underlying operations are carried out by a conventional networked data processing system (such as exemplified in D1, see above).

By the way, if you are interested in a deeper look into how the European Patent Office examines software-related inventions, this 30-minute video gives a concise overview of the “two hurdle” approach with lots of examples:

The applicant had also argued that it was a technical feature of the invention that each client’s submission is unknown to the other trader clients. However, without success:

In contrast to the appellant, the Board does not consider the feature that each client’s submission is unknown to the other trader clients to be technical since such a limitation of data flow is not achieved by technical measures, but is a constraint of the underlying administrative/financial concept.

The same applied ultimately to the aspect of automating the processing of the financial data. As the skilled reader will know, the mere automation of something is regularly considered obvious by the European Patent Office:

The fact that the steps of receiving, identifying, selecting and calculating complementary offsetting credit risk positions are performed automatically and are scalable is an obvious consequence of using a computer system with commonly known database and network technology.

Therefore, the board decided that claim 1 of the main request did not involve an inventive step.

The applicant also tried an auxiliary request which defined that the credit risk positions can be uploaded by the trader clients using a spreadsheet format:

Claim 1 of this request additionally incorporates features of dependent claims 2 and 3 of the main request by further specifying that the plurality of trader clients are invited to upload the plurality of credit risk positions to the electronic trading system of credit derivatives in a spreadsheet format.

The Board concurs with the contested decision that an unspecified data format per se does not contribute to the technical character of the claim and that organisation of data in the form of a table or a spreadsheet was commonly known in the art (see point 8 of the decision under appeal).

In addition, a trading system comprising a standardized interface that allows processing of credit derivatives in a compact and uniform format was known in the art, including the use of tables (see e.g. D1, para. [0013], [0045] or [0046], [0069] to [0071] with figures 11, 14, and 15A to 15D).

The additional features therefore do not involve an inventive technical contribution.

More information

You can read the whole decision here: T 1895/13 (Reducing delta values of credit risk positions/CREDITEX)

Never miss a beat by subscribing to the email newsletter. We will send you a monthly digest of new knowledge base entries, as well as occasional interesting information about European software patents. Please see our Privacy Policy for details.

* = Required field