T 1494/10 (Multi-dimensional database/YANICKLO) 14-03-2016

1. The appeal is admissible.

2. According to the present application (see page 11, lines 11 to 18 of the published international application), modern operational and informational databases typically utilise a relational database management system (RDBMS) as a repository for storing data and querying data. "However, the querying component of RDBMS technology suffers from performance and optimization problems stemming from the very nature of the relational data model" (page 11, lines 22 to 24).

In particular, "to support queries that involve aggregation operations, such aggregation operations must be performed over the raw data elements that match the query. For large multi-dimensional databases, a naive implementation of these operations involves computational intensive table scans that leads to unacceptable query response times" (page 11, lines 25 to 29).

As pointed out in the description (page 17, lines 8 to 20), prior art Multidimensional OLAP (MOLAP) systems provide for improved access time to aggregated data within their underlying multidimensional data (MDD) structures, and have performance advantages when carrying out joining and aggregations operations.

However, when atomic (raw) data is moved, in a single transfer, to the MOLAP system for aggregation, analysis, querying and the aggregation results are external to the database management system (DBMS). Hence, because "the MDD query processing logic in prior art MOLAP systems is separate from that of the DBMS, users must procure rights to access to the MOLAP system and be instructed (and be careful to conform to such instructions) to access the MDD (or the DBMS) under certain conditions. Such requirements can present security issues, highly undesirable for system administration" (page 17, lines 14 to 18).

2.1 The gist of the invention disclosed in the present application consists essentially in combining a relational datastore with a multidimensional database aggregation module (see Figure 19A) which stores atomic data and aggregated data in a MDDB. "The MDDB is a non-relational data structure - it uses other data structures, either instead of or in addition to tables - to store data" (cf. page 43, lines 18 to 20). A query handler and the relational data store (tables and meta-data store) are coupled to the MDD Aggregation Module. They operate so as "to make user-querying of the non-relational MDDB no different than querying a relational table of the DBMS, in a manner that minimizes the delays associated with queries that involve aggregation or drill down operations" (page 43, lines 29 to 32).

Main request

3. Claim 1 of the main request relates to a "database management system having an associated relational query interface for accessing data stored as relational tables", and comprises the following features itemised by the Board:

(a) a relational datastore storing data in tables;

(b) an integrated aggregation module, operatively coupled to the relational datastore,

(i) for aggregating the data stored in the tables of the relational datastore and

(ii) storing the resultant aggregated data in a multi-dimensional database;

(c) a reference generating mechanism for generating a reference to aggregated fact data generated by said aggregation module,

(i) wherein the reference is such that it can be referred to in a relational query statement; and

(d) a query servicing mechanism for servicing a given query statement,

(i) wherein, upon identifying that the given query statement refers to said reference, the query servicing mechanism communicates with said aggregation module to retrieve portions of aggregated fact data pointed to by said reference that are relevant to said given query statement.

Article 84 EPC

4. A first reason given by the Examining Division in the contested decision for refusing the present application was that claim 1 was unclear within the meaning of Article 84 EPC because the expression "multi-dimensional database" used in this claim was vague and unclear.

4.1 In particular, the Examining Division noted that the term multi-dimensional "might simply be an attempt to characterize the content of the data as being related to multiple dimensions (physical, geographical, temporal or merely logical dimensions) or it might relate to particular ways of implementing the storage of the data in a computer (e.g. as a multidimensional array in main memory)" (see contested decision, page 5, second paragraph).

4.2 The Examining Division also considered that no clarification was provided by the description where this expression was only vaguely defined on page 43, lines 18 to 20 as a data structure using other data structures instead of or in addition to tables to store data. According to the Examining Division, this definition included traditional relational databases which used for example tree structured indexes to store data in addition to tables. Moreover, tables could also be stored as bit lists (see contested decision, page 5, third paragraph).

4.3 As to the references to prior art documents provided by the applicant for clarifying the meaning of, inter alia, the expression "multi-dimensional database", the Examining Division found that the numerous "definitions" provided in the prior art varied to such an extent that it was not possible to infer any particular technical features of the claimed database. In fact, the term "multi-dimensional" did not restrict claim 1 to a particular definition of a database, since a "table" was also a physical implementation of a multidimensional array and relational OLAP systems provided also logical storage as a multi-dimensional array (cf. page 5, fourth paragraph to page 6, first paragraph).

5. In the appellant's opinion, however, the term "multidimensional database" had a clear meaning for those skilled in the art which was also expressed in the original application.

In particular, the description explained that a multi-dimensional database (MDDB) was one that was "logically organized as a multidimensional array (typically referred to as a multidimensional cube or hypercube or cube) whose rows/columns each represent a different dimension (i.e., a relation). A data value is associated with each combination of dimensions (typically referred to as a 'coordinate')" (page 5, lines 8 to 12 of the published application).

According to page 5, lines 11 to 13, the main premise of the multi-dimensional database architecture was that the data had to be stored multi-dimensionally to be accessed and viewed multi-dimensionally.

Page 43, lines 18 and 19 of the description expressly stated that a MDDB was a non-relational data structure.

5.1 In the appellant's opinion, prior art documents, such as D5 to D7, used the term "multi-dimensional database" as a "term of the art" in a manner that was consistent with the meaning given to this term in the present application.

5.2 As further proof that the meaning of the term "multi-dimensional database" was clear to the person skilled in the art, the appellant referred to the Witness Statement (D8).

According to D8 (point 8.), "[t]he commonly accepted meaning of the term 'multi-dimensional database' is, as the name suggests, a database where the concepts of dimensions, typically with a hierarchy of levels, and multi-dimensional coordinates, sometimes called cells are native, first-order concepts".

According to point 9. of D8, there was no native concept of dimension and no native concept of coordinate/cell in a relational database. "A relational database can only emulate these concepts, but cannot capture them natively, thus a relational database is not a type of multidimensional database".

6. The Board agrees with the Examining Division that the attribute "multi-dimensional" per se does not allow drawing any conclusion as to the physical implementation of a database.

6.1 On the other hand, claim 1 refers to a "relational datastore storing data in tables" (see feature (a) of claim 1) and to "a multi-dimensional database" where aggregated data provided by an aggregation module coupled to the relational datastore are stored (see features (b)(i) and (ii)). Thus, in the opinion of the Board, the skilled person would interpret claim 1 as distinguishing between a "relational datastore" and a "multi-dimensional database".

6.2 This distinction is further spelt out in independent claim 16 as originally filed which relates to a relational database management system comprising "a relational datastore storing fact data" and "a non-relational multi-dimensional datastore" for storing aggregated data.

6.3 Turning to the description of the present invention, the Board notes that it is specified on page 5, lines 7 to 13 that "[m]ultidimensional OLAP (MOLAP) systems utilize a proprietary multidimensional database (MDDB) to provide OLAP analyses. The MDDB is logically organized as a multidimensional array (typically referred to as a multidimensional cube or hypercube or cube) whose rows/columns each represent a different dimension (i.e., relation). A data value is associated with each combination of dimensions (typically referred to as a 'coordinate'). The main premise of this architecture is that data must be stored multidimensionally to be accessed and viewed multidimensionally" (underlining added).

6.4 Furthermore, the underlying teaching of the present invention, which consists essentially in combining the advantages of a ROLAP system architecture with the capabilities of MOLAP systems to carry out joining and aggregations operations, seems to imply that the term "multi-dimensional database" does not provide just another definition of "traditional" relational databases (cf. contested decision, page 5, third paragraph), but that it is meant to specify a database which is at least logically organised as a multi-dimensional array.

6.5 In any case, as the outcome of the present decision does not hinge on the clarity issue raised by the Examining Division, the Board finds it expedient to assume that it is sufficiently clear, in the context of claim 1 and of the present invention, that the expression "a multi-dimensional database" relates to a database which is at least logically organised as a multi-dimensional array directed to storing aggregated data based on data stored in tables of the relational datastore.

Article 83 EPC

7. As a second reason for refusing the application, the Examining Division found that the description and the drawings failed to provide a sufficiently clear enabling disclosure of the invention.

7.1 In particular, the Examining Division pointed out that the application described as the sole means to carry out the claimed invention a "link" from the database management system (DBMS) to a multi-dimensional database (MDDB) by means of a "view" or a "trigger" (see dependent claims 3 and 7 of the main request).

In the opinion of the Examining Division, if the MDDB referred to in claim 1 were to be interpreted as something different from a "traditional relational table", the application would not satisfy Article 83 EPC because it did not explain how the views or triggers referred to in claims 3 and 7 could be defined and implemented. Although views and triggers were well-known in RDBMS, triggers were normally triggered by data manipulation operations, and not by query operations.

7.2 Furthermore, the Examining Division noted that the actions of triggers normally referred to a relational database management system (RDBMS), so that providing for a query a link to a MDDB via a trigger seemed not to be within the common general knowledge of the skilled person at the priority date. Views were commonly used to define a logical table as a result of a select query within the RDBMS. However, the use of views to provide links to an external MDDB did not appear to be within the common general knowledge.

8. According to the appellant, the application contained a clear and complete disclosure of how to carry out the invention.

8.1 The appellant explained that according to the present invention the query interface parsed a query received at the query interface into a series of query statements (e.g. SQL statements). If the query required aggregated data, the query interface generated a query statement that included a reference to the aggregated data. The generated query statements were forwarded to a query handler which looked for references to aggregated data in the received query statements. If such references were found, the query handler forwarded those statements to an SQL handler in the aggregation module using a standard interface. The SQL handler of the aggregation module received the query statements and extracted information, in the form of dimensional coordinates, which could be used to address the multi-dimensional database. An MDD handler in the aggregation module used these dimensional coordinates to address the multidimensional database.

8.2 Furthermore, the appellant argued that the skilled person would have known how to implement the above teaching and, in particular, how to define a reference to aggregated fact data by a view mechanism. In fact, it was common general knowledge that an SQL CREATE VIEW statement included a SELECT statement, and that a view could be defined such that its SELECT statement queried a table of a remote database or external database. Document D4 illustrated that it was common general knowledge to create a view on a table of a remote relational database.

8.3 Hence, in the appellant's view, the application contained a clear and complete teaching of how a view could be used to reference an MDDB. Figure 19C(i) described a step of defining a reference that provided the user with the ability to query MDDB in the MDD Aggregation Module. Figure 19E specified that a remote referencing view mechanism enabled referencing a remote table such that the MDD was mimicked as a remote relational table. In summary, from a relational database's point of view, a reference defined by a "view" appeared to be a simple query to a remote table in the aggregation module. Hence, the relational database's query handler would forward the view's SELECT statement which appeared to query the remote table to the aggregation module's SQL handler. In combination with the MDD handler, the SQL handler allowed the received SQL statement to be converted into an MDDB query by extracting dimensional coordinates.

9. According to the description and, in particular, to the passages cited by the appellant in support of its arguments (published application, paragraph bridging pages 45 and 46), "a reference is defined that provides users with the ability to query the data generated by the MDD Aggregation Module and/or stored in the MDDB of the MDD Aggregation Module. This reference is preferably defined using the Create View SQL statement, which allows the user to: i) define a table name (TN) associated with the MDDB stored in the MDD Aggregation Module, and ii) define a link used to route SQL statements on the table TN to the MDD Aggregation Module. In this embodiment, the view mechanism of the DBMS enables reference and linking to the data stored in the MDDB of the MDD Aggregation Engine as illustrated in FIG. 6(E). [...] Thus, the view mechanism enables the query handler of the DBMS system to forward any SQL query on table TN to the MDD aggregation module via the associated link. In an alternative embodiment, a direct mechanism (e.g., NA trigger mechanism) may be used to enable the DBMS system to reference and link to the data generated by the MDD Aggregation Module and/or stored in the MDDB of the MDD Aggregation Engine as illustrated in FIG. 6F".

9.1 Hence, the application essentially confirms the appellant's explanation that a reference to aggregated data can be defined using the CREATE VIEW statement known to the skilled person, thereby "mimicking" the multi-dimensional database as a remote relational table (cf. paragraph bridging pages 45 and 46, and Figure 19E). The Board also agrees that it belonged to the common knowledge of the skilled person to use the CREATE VIEW statement for accessing remote relational databases. Furthermore, the Board is willing to accept the appellant's argument that technology extending the functionality of the CREATE VIEW statement, such as described on page 4 of document D4, was well known to the skilled person and could be used to implement the referencing mechanism of the present invention to reference "MDD mimicked as a remote relational table" (see Figure 19E).

9.2 As to the use of "a trigger" in the context of the present invention, the Board is not fully convinced that this feature of the invention could have been implemented only on the basis of the skilled person's general knowledge.

9.3 However, as the description refers to at least a detailed embodiment of the system according to claim 1 which for its implementation relies on technical features available to the skilled person at the relevant filing date, the invention as defined in claim 1 meets the requirements of Article 83 EPC.

Article 54 EPC

10. In the contested decision, the Examining Division considered that document D1 disclosed all features recited in claim 1 of the main request. However, the Examining Division also emphasised that this conclusion was based on the understanding that claim 1 merely related to SQL query processing within a relational database wherein a query referred to a materialized view (summary table). According to this interpretation, a multi-dimensional database (MDDB) was simply understood as being a relational database table storing summary data (see statement of grounds point 5.).

11. Referring to arguments already submitted in the first instance proceedings, the appellant pointed out that document D1 disclosed a relational on-line analytical processing (ROLAP) server, in which fact data and dimension data were stored in relational tables. In contrast to the present invention, document D1 taught storing also aggregated data in relational tables, known as summary tables. Hence, D1 did not disclose the feature of an aggregation module, coupled to a relational datastore, for storing aggregated data in a multi-dimensional database (MDDB).

11.1 Thus, in the appellant's view, document D1 also failed to disclose the following features:

- a reference generating mechanism for generating a reference to the aggregated data (stored in the multi-dimensional database), wherein the reference is such that it can be referred to in a relational query statement; and

- a query servicing mechanism that, upon identifying such a reference, communicates with the aggregation module to retrieve aggregated fact data pointed to by the reference.

12. Adopting the appellant's interpretation of the expression "multi-dimensional database" (see above, point 6.5), the Board agrees that the subject-matter of claim 1 is new with respect to document D1.

Article 56 EPC

13. The Examining Division did not address the issue of inventive step in the contested decision, although it had noted in a communication dated 23 April 2009 (see point 8. thereof) that, after discussing and analysing the disclosure of the application, it had not found any basis for patentable subject-matter due to the lack of any new and non-obvious technical features which solved a technical problem and had been sufficiently clearly and completely disclosed.

13.1 In the statement of grounds of appeal, the appellant maintained that the claimed subject-matter involved an inventive step and repeated the arguments already put forward in its previous letters dated 20 September 2007 and 3 December 2009 to which it referred.

13.2 In the communication dated 10 December 2015, the Board raised an objection under Article 56 EPC and introduced two new documents, D9 and D10, relevant for inventive step. However, the Board also informed the appellant that it would be considering at the oral proceedings the possibility of remitting the case to the department of first instance for further prosecution.

13.3 As sole reaction to the Board's preliminary opinion set out in the communication of 10 December 2015, the appellant informed the Board that it did not intend to attend the oral proceedings.

13.4 By not attending the oral proceedings or requesting that the proceedings be continued in writing or the case be remitted to the Examining Division for further prosecution, the appellant has shown that it did not intend to argue against the Board's objection under Article 56 EPC.

In these circumstances, the Board considers that it would serve no purpose and merely delay the procedure to remit the case to the Examining Division for further prosecution.

14. The appellant argued on inventive step essentially as follows:

(a) The technical problem solved by the claimed subject-matter was to improve the speed of processing relational database management system (RDBMS) queries that made use of aggregated data, in a manner that was transparent to the user of RDBMS.

(b) The problem was solved by storing aggregated data in a multi-dimensional database, and enabling the aggregated data to be referenced in a relational query.

(c) By storing aggregated data in a multi-dimensional database, the invention avoided the need to perform scan and join operations on large summary tables.

(d) The claimed invention allowed aggregated data in a multi-dimensional database to be accessed directly from the RDBMS by providing a reference generating mechanism that allowed a reference to the aggregated data to be referred to in a relational query statement and by providing a query servicing mechanism and aggregation module that cooperated to retrieve aggregated data from the multidimensional database upon identifying such a reference.

(e) Document D1 provided no suggestion that the speed of processing queries could be improved by storing aggregated data in a multi-dimensional database (MDDB).

(f) Document D1 also contained no pointer towards the claimed features that allowed an RDBMS to interoperate transparently with a multi?dimensional database to retrieve aggregated data stored therein.

(g) Document D2 taught that precomputation was a solution to the problem of speeding up queries but did not suggest that aggregates should be stored in a multi-dimensional database.

(h) Document D3 disclosed that the performance of an OLAP server could be improved by caching aggregated data but did not point towards storing the aggregated data in a multi-dimensional database.

(i) Hence, the claimed subject-matter did not result from an obvious combination of the teachings of D1 and D2 or D1 and D3.

15. As pointed out in the application as published (page 4, lines 25 to 29), a typical prior art relational OLAP system (ROLAP) has a three-tier or layer client/server architecture. "The 'database layer' utilizes relational databases for data storage, access, and retrieval processes. The 'application logic layer' is the ROLAP engine which executes the multidimensional reports from multiple users. The ROLAP engine integrates with a variety of 'presentation layers,' through which users perform OLAP analyses".

Furthermore, it is explained in the application (page 4, line 31 to page 5, line 5) that "[a]fter the data model for the data warehouse is defined, data from on-line transaction-processing (OLTP) systems is loaded into the relational database management system (RDBMS). If required by the data model, database routines are run to pre-aggregate the data within the RDBMS. Indices are then created to optimize query access times. End users submit multidimensional analyses to the ROLAP engine, which then dynamically transforms the requests into SQL execution plans. The SQL execution plans are submitted to the relational database for processing, the relational query results are cross-tabulated, and a multidimensional result data set is returned to the end user. ROLAP is a fully dynamic architecture capable of utilizing precalculated results when they are available, or dynamically generating results from atomic information when necessary".

15.1 On the other hand, "[m]ultidimensional OLAP (MOLAP) systems utilize a proprietary multidimensional database (MDDB) to provide OLAP analyses. The MDDB is logically organized as a multidimensional array (typically referred to as a multidimensional cube or hypercube or cube) whose rows/columns each represent a different dimension (i.e., relation). A data value is associated with each combination of dimensions (typically referred to as a 'coordinate'). The main premise of this architecture is that data must be stored multidimensionally to be accessed and viewed multidimensionally" (ibid. page 5, first full paragraph).

16. The Board understands that the underlying idea of the present invention consists essentially in providing an OLAP system which combines relational and MOLAP technologies and which is known in the art as hybrid OLAP.

16.1 The Board's understanding of the invention is confirmed by the following observation made by Prof. Pedersen at the end of the "Witness Statement" D8:

- "it is indeed a very good idea to combine an MDDB with an RDB, as described in the Application, so that aggregates can be generated faster, while still allowing a user to use a relational query language. The combination of RDBs with MDDB is by now supported by many products, and termed Hybrid OLAP (HOLAP)" (underlining added).

17. Document D9 is concerned with the problem of building a data production system for market research and examines products based on the ROLAP and MOLAP architectures, mentioned in the present application, and on the HOLAP architecture, referred to in the "Witness Statement" D8 (see point 15. above).

17.1 In particular, it is explained in the section "External Requirements" of document D9 that a real data warehouse must sufficiently support two classes of users: "On the one hand, at the end of every analysis period, a collection of predefined reports (about 1000 pages each) is printed in a batch-oriented manner and sold to the customers. On the other hand, ad-hoc users must be supported during the complete analysis phase of the available data. These end-users are mostly consultants or statisticians which would like to speak in business terms, e.g. channel types and product features and navigate with a point-and-click interface in a multidimensional data cube instead of formulating SQL-queries. Their kind of work is typical 'On-line Analytical Processing' [...]. The second external requirement is to handle extremely large data volumes".

According to section 3.1 ("Architectural Designs"), data production systems are expected to meet the following requirements: First, the user level must provide a multidimensional user interface enabling the data analysis by use of "business terms". Second, the system should be capable of handling large data volumes.

17.2 Document D9 indicates that in "Multidimensional OLAP", the multidimensional view is directly reflected in multidimensional storage structures to efficiently support "slice"/"dice" and "drill-down"/"roll-up" operations (page 652, section 3.1).

Contrary to the MOLAP-approach, "Relational OLAP" visualises a relation as a multidimensional cube. Therefore, all OLAP-operations are directly translated into corresponding relational operation, i.e. into complex SQL statements. "No special multidimensional storage structures are needed" (page 652, section 3.1).

The "Hybrid OLAP" approach tries to combine the advantages from both MOLAP and ROLAP. In particular, the multidimensional component acts as a cache for the data stored in the relational database. Hence, "[i]n order to answer an OLAP-query, first the multidimensional cache is checked. If the requested data cannot be found there, appropriate SQL-queries are generated and sent to the relational database" (D9, page 652, right-hand column, lines 18 to 21).

17.3 In other words, the HOLAP approach implies that aggregated data generated by an aggregation module are stored in a "multidimensional component" and that a reference to the aggregated data is generated (see features (b)(i) and (b)(ii) of claim 1).

17.4 In document D9, SQL-queries are generated and sent to the relational database, if the requested aggregated data cannot be found in the multidimensional database.

According to claim 1 of the main request, however, the database management system has a relational query interface and in particular a query servicing mechanism for servicing a given query statement and identifying whether it refers to a reference to aggregated fact data (see feature (d) of the claim's itemisation).

17.5 Starting from document D9, a problem addressed by the claimed subject-matter can be seen in providing a database management based on the HOLAP approach and for which OLAP operations are expressed as query statements.

17.6 The desire to address the above problem is, in the Board's opinion, inspired by the necessities of the user.

As pointed out in D9, there are users who may not wish to express their problems as SQL queries. On the other hand, the possibility of addressing aggregated data stored in a multidimensional database by means of query statements would offer users the evident advantage of operating in a familiar and widely known language environment.

17.7 In view of the above, the Board considers that it would have been obvious to a person skilled in the art, starting from D9 and wishing to implement a HOLAP system, to consider the possibility of using a relational query interface for managing not only the relational datastore but also the multidimensional datastore. In doing so, the skilled person would have arrived at a system falling within the terms of claim 1.

17.8 The Board's conclusion is corroborated also by the fact that the application does not contain any special features concerning the implementation of a query interface in the context of the claimed system, so that it seems fair to assume that the applicant considered this aspect of the invention to be within the capabilities of the skilled person.

17.9 In the result, the Board considers that the subject-matter of claim 1 does not involve an inventive step within the meaning of Article 56 EPC.

Auxiliary request

18. Claim 1 according to the auxiliary request differs from claim 1 according to the main request in that feature (c)(i) reads as follows:

(i') wherein the reference is defined using a Create View SQL statement,

(i") whereby the reference defines a relational table name associated with the multidimensional database and wherein the reference further defines a link for routing SQL statements on the relational table name associated with the multidimensional database to the aggregation module.

According to the appellant, the claims of the auxiliary request met the requirements of Articles 84, 83, 54 and 56 EPC for the same reasons given in connection with the main request. Furthermore, by reciting explicitly that the reference to the MDDB was defined using a Create View SQL statement, the independent claims addressed directly the objection under Article 83 EPC raised by the Examining Division.

19. Document D10 in Figure 1 shows the traditional architecture for data warehousing which, inter alia, comprises an "operational layer" with various data sources and a "Data Warehouse layer" which can be represented in relational form (ROLAP systems) or in multidimensional form (MOLAP systems).

19.1 Figure 2 of document D10 relates to a "new" architecture for data warehousing in which the warehouse level is split into a logical layer, which describes the content of the data warehouse in multidimensional but abstract terms, and an internal layer, which describes how the data warehouse is implemented (relational or multidimensional structures).

According to D10, page 4, "[q]ueries and views are defined with respect to the logical data warehouse layer" (underlining added). As this logical layer may describe the content of the warehouse in multidimensional terms, document D10, inter alia, teaches defining views with respect to a multidimensional data representation.

In fact, multidimensional objects at the logical level can be manipulated using a "declarative SQL-like language for expert analysis" (document D10, page 2, last paragraph).

19.2 Furthermore, as pointed out by the appellant in the letter dated 3 December 2009, item 1.3, first paragraph, and in the statement of grounds of appeal page 8, paragraph (iv), it was common general knowledge at the filing date of the present application that a remote or external database (i.e. a database managed by a different DBMS from that used to execute a query) could be referenced by a view.

In particular, document D4, referred to by the appellant, explains how the CREATE VIEW command can be used to create a remote view in the current database container (cf. D4, page 4, section "Views").

19.3 In summary, claim 1 of the auxiliary request differs from claim 1 of the main request essentially in that it further specifies that the reference to aggregated fact data in the multidimensional database is defined using a CREATE VIEW SQL statement and that this reference defines a relational table name associated with the multidimensional database.

19.4 As it was common general knowledge to reference a table of a remote database using a view and document D10 shows that views can be defined with respect to a logical data warehouse layer describing data in multidimensional terms, it would have been obvious to the person skilled in the art seeking to implement a Hybrid OLAP system provided with a query interface to consider the possibility of using a CREATE VIEW SQL statement to reference aggregated fact data in the MDDB. Within the same context it would also have been obvious, for the purpose of referencing the multidimensional database, to associate a relational table name with this multidimensional database. In doing so, the skilled person would have arrived at a database management system falling within the terms of claim 1.

20. In summary, the Board comes also to the conclusion that the subject-matter of claim 1 according to the auxiliary request does not involve an inventive step within the meaning of Article 56 EPC.

21. As none of the appellant's request provides the basis for the grant of a patent, the appeal has to be dismissed.