The European Patent Office considered using a NoSQL data store and an RDBMS to provide performance improvement in a database system technical. Here are the practical takeaways from the decision T 1924/17 (Data consistency management/ACCENTURE GLOBAL SERVICES) of 29.7.2019 of Technical Board of Appeal 3.5.07:
The application underlying the present decision relates to data consistency management and aims at achieving scaling using cloud computing for applications relying on a relational database as the data tier to provide transaction support and to ensure data consistency (EP 2 735 979 A2, para. ). The purpose of the invention is explained by the Board in charge as follows:
2. (…) The invention proposes an automated approach for determining the trade-off between data consistency and scalability, thus accelerating the process of augmenting the data tier with NoSQL data stores for scalability in the cloud (paragraph ). The invention monitors database queries issued by an application, and identifies data tables with query patterns that are most suitable to be managed by a NoSQL data store (paragraph ). Based on a determination that a certain data table may be managed by a NoSQL data store, the invention creates data structures in the NoSQL data store according to the data schema of the table, and translates SQL queries to the data table into corresponding NoSQL application programming interface calls (paragraph ). For example, the invention may identify queries that select data from a single table using the primary key for this table. Such queries may be supported by key-value stores, which are NoSQL data stores, with high performance. As a further example, the invention may identify select queries aggregating a single column of a table. For such queries a column store may be suitable (paragraph ).
A data table ranking module of the invention ranks data tables with a linear combination of the percentage of read queries and the percentage of query patterns suitable for a NoSQL data store (paragraph ). A data table determination module automatically determines which data table can tolerate data inconsistency from the ranked data tables, and thus can be managed using a NoSQL data store (paragraph ).
Fig. 1 of EP 2 735 979 A2
Claim 1 (main request)
1. A data consistency management system (150) determining whether to forward a query to a not only structured query language (NoSQL) data store (152) or to a relational database management system (RDBMS) (160) by monitoring database queries issued by an application, and identifying data tables with query patterns that are suitable to be managed by the NoSQL data store (152), the system (150) comprising:
a query identification module (151) monitoring and parsing queries (153) to identify all queries of a data table, and calculating how many of the identified queries are read queries, and how many of the identified queries match the query patterns;
a data table ranking module (165) ranking data tables with a linear combination of a percentage of read queries and a percentage of the query patterns;
a data table determination module (167) automatically determining which data table [sic] are to be managed using the NoSQL data store (152);
a query translation module (168) automatically translating queries targeting the determined data tables to NoSQL API calls;
a memory (406) storing machine readable instructions to:
receive, by the query identification module (151), a query (153);
determine, by the query identification module (151), a suitability of the query (153) for processing by the NoSQL data store (152), or the RDBMS (161), wherein the machine readable instructions to determine the suitability of the query for processing by the NoSQL data store (152), or the RDBMS (161) further comprise:
determining whether the query (153) is a select query that selects data from a data table via a primary key (281) of the data table, the query matching a key-select pattern (181); and
determining whether the query (153) is a select query that aggregates a single column of a data table, the query matching an aggregation pattern (182);
rank, by the data table ranking module (165), data tables based on a combination of read queries for the data tables and the query patterns suitable for the NoSQL data store (152) for the data tables, at least one of the data tables containing information for responding to the query (153), wherein the machine readable instructions to rank the data tables further comprise:
ranking a data table based on a linear combination of a percentage of the read queries for the data table, a percentage of queries of the data table that matches [sic] the key-select pattern (181), and a percentage of queries of the data table that matches [sic] the aggregation pattern (182),
wherein the linear combination comprises an equation
rank(t) = λ1 rp(t) + λ2 kp(t) + λ3 maxc(ap(t,c)),
wherein rp(t) represents a percentage of read queries of a table t, kp(t) represents a percentage of queries of the table t that match the key-select pattern, ap(t,c) represents a percentage of queries of the table t that match the aggregation pattern and aggregate over the data in a column c of the table t, and λ1[,] λ2 and λ3 are linear coefficients;
based on the ranking, determine, by the data table determination module (167), data tables from the ranked data tables that are to be managed by the NoSQL data store (152), or by the RDBMS (161);
determine, by the query identification module (151), whether the query is for at least one data table managed by the NoSQL data store (152); and
based on a determination that the query (153) is for the at least one data table managed by the NoSQL data store (152), translate, by the query translation module (168), the query (153) to NoSQL application programming interface (API) calls for using the NoSQL data store (152) to respond to the query (153);
forward the translated query (153) to the NoSQL data store (152); and
a processor (402) to execute the machine readable instructions.
Is it patentable?
In its decision to reject the application, the first instance examining division argued that only the following features of claim 1 of the main request are technical: a system, a data store, a database
management system, a memory and a processor. All other features would only constitute a number of abstract procedural steps in terms of a computer program as such. Consequently, only the above-listed technical features were considered by the examining division for assessing inventive step. As a result, the examining division decided that the claimed-subject-matter is rendered-obvious by the closest prior art document D1 because D1 discloses all of the technical features listed above. To substantiate this decision, the examining division outlined that features may only contribute to the technical character of an invention if they provide a “further” technical effect:
6. (…) The Division considered that features of a computer program may contribute to the technical character of the invention if they were capable of bringing about a “further” technical effect, when being executed, or involved “further” technical considerations. It referred to the Guidelines for Examination, G-II, 3.6. In the system according to claim 1, the effect of the procedural steps was to achieve different execution times and data consistency levels. These effects, however, were not “further” technical effects. Achieving data consistency levels was a “human requirement”, as there was “no technical reason for keeping data consistent versus partially or totally inconsistent”. Hence, data consistency was part of the requirements specification. Achieving different execution times was “an inherent side effect of the (any) different computer programming” and, therefore, “not sufficient on its own to qualify as a technical effect”.
Particularly features like “key-value store” and “column store” were considered as data structures which could not contribute to inventive step:
6. Features like “key-value store” and “column store” were “data structures” and, hence, merely static memory configurations not contributing to the technical character of the invention (see point 3.2 of the contested decision).
Importantly, the Board in charge did not agree with the examining division’s identification of technical and non-technical features in claim 1. With respect to the features of “key-value store” and “column store”, the Board pointed to paragraphs  and  of the application as filed in which such data stores are correctly described as systems:
9. (…) As correctly stated in the application, paragraphs  and , NoSQL data stores including keyvalue stores and column stores are non-relational database management systems. A database management system is not a data structure, but a software system for storing, retrieving and processing data which typically uses various data structures for the efficient management of data. Hence, these systems are not merely static memory configurations, they implement methods operating on the data and the data structures to query the data, for example. Thus, the reasoning of the contested decision is not convincing.
Moreover, the Examining Division identified database management systems as being technical, but considered the features specific for relational database management systems to be non-technical. As the technical function of a database management system is, at least to a substantial part, determined by the data model supported by the system (e.g. the relational model of data), the Board sees no reason why relational database management systems should be non-technical, if it is accepted that database management systems in general are technical. (…)
Notably, in order to assess the issue whether and to which extent claim 1 contributes to the solution of a technical problem, the Board in charge reviewed a plurality of decisions of the boards of appeal in the field of information systems. A first group of reviewed decisions concerns inventions related to accessing data in database management systems and, in particular, the processing of structured queries for this purpose, whereas a second group of decisions relates to the field of information retrieval. The decisions of both groups are briefly summarized in the following:
First group (accessing data base management systems):
11.1 In decision T 1242/04 (OJ EPO 2007, 421), the invention according to claim 10 related to a system for providing product-specific data in a service station. (…) Hence, this decision identified not only the central database for storing and providing data as a feature contributing to the solution of a technical problem (in combination with the other listed features), but also the computer program communicating with this central database and an archive store.
11.2 Decision T 279/05 of 5 October 2007 concerned an invention related to determining airline seat availability. The invention involved a mixture of technical aspects, e.g. servers, and non-technical aspects, e.g. airline seat availability and yield management. (…) As evident from the cited reasons, the competent Board considered database querying to be a technical field.
11.3 The invention in decision T 862/05 of 20 February 2008 related to an electronic sales and service support system intended for banks. (…) It follows that the competent Board regarded a central database, means for searching this database and means for building structured queries as technical features of the invention.
11.4 In decision T 658/06 of 25 November 2010, the invention concerned recording and managing bonus points for telephone users. (…) Hence, the competent Board considered database operations (…) as conferring a technical character on the claimed method.
11.5 The invention in decision T 1500/08 of 4 November 2011 related to the automatic generation of formally specified structured queries for a database management system based on the user input received. (…) The technical effect was that, sometimes, a previous search could be reused by the database server (see reasons 5.8 and 5.9). (…)
11.6 According to the background section of the patent application underlying decision T 963/09 of 5 June 2014, conventional database systems typically provided a general auditing facility that recorded an audit trail containing general information about the user and the query issued. (…) Evidently, the competent Board considered database accesses in general (see point 7.6 of the reasons) and the specific implementation of rowbased selective auditing in an RDBMS, in particular, to be technical.
11.7 In decision T 104/12 of 8 September 2016, the invention concerned a method of extracting data using a database view query from an online transaction processing system to a data sink. In point 3.8 of the reasons, the competent Board acknowledged that implementing the execution of a database view query was a technical problem.
11.8 Decision T 1965/11 of 24 March 2017 concerned the optimisation of structured queries to an RDBMS in the presence of materialised views. (…) This decision makes it clear that query optimisation in an RDBMS is considered as contributing to the technical character of the invention.
Second group (information retrieval):
12.1 Decision T 1569/05 of 26 June 2008 concerned an information retrieval system for retrieving images using textual descriptions of the images as searchable metadata. (…) Hence, the competent Board confirmed that retrieval from a database was normally considered as having technical character. However, it regarded the mathematical model of meaning used to define and calculate the similarity of images via their textual descriptions as non-technical.
12.2 In its decision T 1316/09 of 18 December 2012, point 2 of the reasons, the competent Board considered a method or a combination of methods of text classification per se as not producing any relevant technical effect or providing a technical solution to any technical problem.
12.3 In decision T 309/10 of 19 June 2013, the invention concerned the archival and retrieval of documents. The competent Board considered that the core method of retrieval could well be performed without the technical aid of a computer and by a librarian solving the non-technical problem of storing and locating books (see reasons 9 and 10). (…)
12.4 Decision T 598/14 of 6 November 2014 concerned a method for generating, from an input set of documents, a word replaceability matrix defining semantic similarity between words occurring in the input document set. (…) The Board is convinced that no such “further technical considerations” can be found in the present case. As explained above, the translation simply reflects the linguistic aspects in the mathematical model. (…)
12.5 Decision T 2230/10 of 3 July 2015 states in its reasons, point 3.10, the following: “The Board […] does not accept that the algorithm is based on technical considerations in that it has been purposively designed with a view to the relevance to the user of the search results obtained, as this relates to the cognitive content of the returned documents.”
Hence, this decision regarded certain considerations relating to the cognitive content of the documents as non-technical.
In view of the above-presented decisions, the Board in charge summarized the situation with respect to the technicality of query processing in database management systems and information retrieval systems as follows:
13. (…) Structured declarative queries, which are used for retrieving data managed in a relational database management system, normally have precise, formally defined semantics, i.e. the query precisely describes the data that is to be retrieved, and the database management system then retrieves the specified data set as a result. Relational database management systems typically execute such queries by determining an efficient query execution plan based on cost estimates for the necessary internal operations of the computer system (e.g. in terms of main memory accesses, hard disk accesses, central processing unit resources). Such database management systems are software platforms for the centralized control of data (“central database”). Features of these platforms often have a technical character, as they have been designed based on engineering considerations concerning the efficient exploitation of the computer system as a technical system.
Information retrieval systems typically have to formally calculate a semantic similarity of documents, which is typically regarded as involving non-technical considerations and being based on subjective criteria and the content (semantics) of the documents to be retrieved.
In view of the above, there is no contradiction in the case law relating to retrieval of data from database management systems and to information retrieval. Rather, the different judgments of the technical character of the features of these systems reflect the different kinds of considerations in the different fields.
As a result, the competent Board concluded that many aspects of processing structured queries in database management systems are to be regarded as technical. Hence, the subject-matter of claim 1 according to the main request of the underlying application adequately defines a system that solves a technical problem:
14. (…) In particular, improving the efficiency of executing structured queries to, or improving the throughput of, an RDBMS by automatically managing the data in various data stores with different properties and exploiting the different performance characteristics of these data stores for enhanced query processing solves a technical problem.
Interestingly, the competent Board further investigated what may have led the first instance examining division to wrong conclusions regarding the identification of the technical and non-technical features of claim 1. The Board of Appeal was particularly concerned that the linear combination “rank(t) = λ1 rp(t) + λ2 kp(t) + λ3 maxc(ap(t,c))” as claimed may have caused the examining division to regard individual features of claim 1 according to the main request as non-technical. In this respect, the Board in charge examined how Article 52(3) EPC has to be understood that defines that particularly computer programs are excluded from patent protection only “as such”. After a comprehensive discussion of this aspect, the Board concluded as follows:
19.3 (…) In the Board’s view, the context provided in Article 52(1) EPC, i.e. the limitation of inventions to all fields of technology, makes it clear that methods applying mathematics in a non-technical field are generally excluded from patentability (unless they use technical means, see decision T 258/03, EPO OJ 2004, 575, headnote I, according to which a method involving technical means is an invention within the meaning of Article 52(1) EPC). However, where mathematical features of an invention contribute to the solution of a technical problem, such mathematical features cannot be ignored when assessing inventive step. (…)
(…) Hence, the present wording of Article 52(2)(a) and (3) EPC, which excludes mathematical methods only “as such”, enshrines in the convention that mathematical methods applied to solve a technical problem are patent eligible.
In view of the above, the Board concluded that the features of claim 1 referring to the above-mentioned linear combination are based on technical considerations:
20.1 In the present case, as the mathematical features concerning the linear combination, E3a and E3b of claim 1, contribute to the automatic determination of which data tables are to be managed by which type of database management system, they play an essential role in the technical functioning of the system and consequently serve the overall technical purpose of claim 1. Furthermore, these features are based on technical considerations concerning the functioning of the database technology used. Hence, they contribute to the solution of a technical problem and have to be taken into account when assessing inventive step.
Since a speed comparison of the claimed method was made with respect to the system as disclosed by the closest prior art D1, the Board in charge also ruled that the claimed method provides a “further” technical effect:
21. The Examining Division had also argued that the effects of different execution times and data consistency levels achieved were not “further” technical effects (see decision T 1173/97, OJ EPO 1999, 609). (…)
21.1 (…) By contrast, in the present case, the speed comparison was made with respect to a particular prior art, i.e. document D1.
21.2 (…) Consequently, in the present case, it has to be considered whether an improvement in the processing speed is based on “further” technical considerations, i.e. technical considerations going beyond the abstract formulation of algorithms or beyond “merely” finding a computer algorithm to carry out some procedure (see opinion G 3/08, OJ EPO 2011, 10, points 13.5 and 13.5.1 of the reasons). (…) However, program development may involve technical considerations relating to the specific internal functioning of the computer as a technical system, which are then typically to be regarded as “further” technical considerations within the meaning of opinion G 3/08, reasons 13.5.1. (…)
21.5 The Board agrees with the appellant that the claimed system is based on “further” technical considerations that concern a specific manner of improving response times for queries by automatically using different data stores, relational database management systems and NoSQL data stores, to manage data tables. (…)
It follows that the Board does not share the Examining Division’s conclusion that achieving data consistency levels was a “result of human requirement” and independent of any technical necessity.
Finally, the board ruled that the examining division’s reasoning for lack of inventive step is not convincing and the present application is remitted back to the first instance examining division for further examination.
You can read the whole decision here: T 1924/17 (Data consistency management/ACCENTURE GLOBAL SERVICES) of 29.7.2019.
Patrick is a European patent attorney at BARDEHLE PAGENBERG. He specializes in software patents in Europe both from a prosecution and litigation point of view.