The European Patent Office considered implementing the execution of a database view query technical. Here are the practical takeaways from the decision T 0104/12 (Metadata-based query/SAP) of 8.9.2016 of Technical Board of Appeal 3.5.07:
The application underlying the present decision relates to the field of data processing, and more particularly, to data extraction. A data extractor is a program used to fill a given extractor structure with data from a database. The extracted data is provided from the source system to a data warehouse (a sink) for the purposes of analysis and management information (cf. WO 2005/015435 A2, page 2, l. 2-5). One of the advantages of the present invention is that the interface between the data sink and the data source is generic such that not only specific data warehouses can act as a data sink but various different kinds of applications which require data from a data source for any purpose. Another advantage is that the data sink does not need to provide a complete extractor structure for all the data which are available from the data source. Rather the data sink is enabled to specify a sub-set of the data which is of interest. This reduces the amount of memory which is required by the data sink and it also substantially reduces the data transmission time from the data source to the data sink (cf. WO 2005/015435 A2, page 4, l. 8-18).
Fig. 1 of WO 2005/015435 A2.
Claim 1 (main request)
A method of providing data from an online transactional processing system (200) to a data sink (210), the method comprising the steps of:
a) receiving (300) a first request (226) from the data sink,
b) in response to the first request, sending (302) of a list (228) of entities of the online transactional processing system (200) to the data sink,
c) receiving (304) a second request (232) from the data sink, the second request being indicative of at least one of the entities (Ei),
d) in response to the second request, sending (306) of a first descriptor (234; FN1, FN2, FN3,…) being descriptive of an extractor structure (412) of the at least one entity of the online transactional processing system (200) to the data sink,
e) receiving (308) of a data request (236) from the data sink, the data request being indicative of the at least one entity and comprising a second descriptor being descriptive of a sub-structure (414; FN2, FN3) of the extractor structure of the at least one entity,
f) filling (310) the extractor structure with data from the online transactional processing system (200),
g) reducing (312) the extractor structure to the sub-structure,
h) sending (314) of the data (238) of the sub-structure to the data sink.
Is it patentable?
The present application was considered as not patentable by the first instance examining division. In more detail, the application was rejected due to lack of inventive step in light of prior art document D1. The rejection has been appealed by the applicant.
According to the Board of Appeal in charge, the subject-matter of claim 1 of the main request differs from well-known OLTP systems (considered to form the closest prior art for claim 1) in steps a. to d., which set out how the data sink obtains the information necessary to formulate the query, and in steps f. to h., which describe how the query is executed. Particularly, the Board considered the subject-matter of steps f. to h. as technical:
3.8 Hence, starting from the closest prior art identified in point 3.33.3 above, the Board considers that the technical problem solved by steps f) to h) is that of implementing the execution of a database view query. (…)
However, the Board in charge further outlined that the implementation of the execution of a query cannot render the claimed subject-matter inventive:
3.8 (…) The skilled person confronted with this problem would understand that, conceptually, such a query is to do what is described in point 3.63.6 above. The straightforward implementation of this conceptual approach corresponds to steps f) to h). Although the skilled person would be aware that this implementation will generally be inefficient, the acceptance of such a foreseeable disadvantage not offset by any unexpected technical advantage does not involve an inventive step.
As a result, the appeal was dismissed.
You can read the whole decision here: T 0104/12 (Metadata-based query/SAP) of 8.9.2016.