T 2573/16 (OLAP-cube specification/ACCENTURE GLOBAL SERVICES) 06-11-2019

1. The appeal complies with the provisions referred to in Rule 101 EPC and is therefore admissible.

2. The application

2.1 The application relates to online analytical processing (OLAP). OLAP software tools allow multidimensional analytical queries of a database to be answered quickly by means of "OLAP cubes", which provide multidimensional views of data (paragraphs [0002] and [0003] of the description as originally filed). An OLAP cube is a data structure that has a number of "dimensions" (such as "time", "product", "location") and which contains a data value (a "measure") in each cell as defined by the dimensions selected for a view (paragraphs [0003] and [0004]).

2.2 According to paragraph [0005] of the application's background section, at the priority date it was conventional for a "technical solution team" to define the OLAP cube. If users, such as business analysts, wanted to change the cube, for example by adding or removing dimensions, the changes had to be implemented by the technical solution team in a cumbersome process involving burdensome back-and-forth communications.

2.3 The application essentially proposes an "OLAP specification system" that allows users to specify a new OLAP cube by modifying an existing "OLAP cube template" (paragraphs [0006] and [0015]).

Main request

3. The invention as defined by claim 1

3.1 Claim 1 of the main request is directed to an "OLAP specification system" that comprises an OLAP-cube template determination module, a metadata copy module, a viable-options generation module, and a metadata receipt module.

3.2 The OLAP-cube template determination module allows a user to select an OLAP-cube template from an OLAP-cube template data store (see paragraph [0020]). It retrieves a "template metadata file" that defines the structure of the OLAP cube of the selected OLAP-cube template.

Hence, an OLAP-cube template is essentially a sample OLAP-cube structure that is intended to be modified by the user. The template metadata file is a file that contains the specification of this structure (in some unspecified format).

3.3 The metadata copy module creates a "base metadata file" from the template metadata file.

Paragraph [0021] discloses that this module creates the base metadata file simply by copying the template metadata file. The base metadata file is intended to be modified by the user.

3.4 As explained in paragraph [0022], the viable-options generation module presents the user with a number of possible modifications of the OLAP cube as "viable options". Modifications are performed by changing the metadata of the base metadata file or inserting new metadata.

Modifications include adding, removing or changing dimensions, categories and hierarchies; modifying the order of dimensions; and specifying the order of categories in a dimension and its hierarchies.

Which options are "viable" is determined by "predetermined rules". One of these rules is a rule that specifies that certain levels of a dimension (such as the "years", "month" and "quarters" levels of the "time" dimension) have to stay grouped in a view.

3.5 The metadata receipt module allows the user to indicate a modification to be made to the metadata in the base metadata file on the basis of the presented viable options. This results in a modified base metadata file which defines the new/modified structure of an OLAP cube.

3.6 Claim 1 further specifies that the OLAP specification system "is configured to perform subsequent operations on the new OLAP cube". Examples of such operations are slicing and drill-down operations (paragraph [0027]).

The OLAP specification system's four modules, discussed in points 3.2 to 3.5 above, allow the user to create a new metadata file that defines the structure of an OLAP cube. Operations such as slicing and drill down are not performed on such a metadata file but on an instantiated OLAP cube that is populated with data.

Hence, the OLAP specification system of claim 1 provides two distinct types of functionality. First, it allows the user to create a metadata file that specifies the structure of an OLAP cube. Second, it allows the user to view data through an OLAP cube corresponding to the newly created metadata file. The first type of functionality is implemented by means of the four modules. The implementation of the second type of functionality is not detailed in the claim.

4. The Examining Division's reasoning

4.1 The Examining Division argued, in point 10.1.1.1 of its decision, that claim 1 of the then main request was essentially directed to a scheme (the decision uses the term "rationale") for defining the structure of a new OLAP cube by modifying existing OLAP-cube templates on the basis of a set of predetermined rules that specify "modifiable aspects of dimensions of the new OLAP cube". Although the decision appears not to say so explicitly, let alone to give reasons why, the Board understands that this scheme was considered to be non-technical.

The Examining Division argued, in points 10.1.1.2 and 10.1.1.3, that claim 1 was silent on the details of the technical implementation of that scheme and that it could be implemented using standard components such as a commonly known general-purpose computer, a graphical user interface and a network interface. It therefore had to be determined which of the non-technical features made a technical contribution (point 10.1.1.4).

Point 10.1.1.5 of the decision essentially repeats point 10.1.1.3 by stating that the only technical aspects present in claim 1 were the feature specifying that the metadata receipt module was "configured to receive input via a user interface", which implied the use of a general-purpose computer, and the features relating to "files", which were to be interpreted as "electronic data files in a computer memory" of that general-purpose computer. All other aspects of claim 1 were non-technical in nature and therefore formed "part of a given framework within which the technical problem [was] posed, for example in the form of a requirements specification provided to the person skilled in a technical field".

The Examining Division, in points 10.1.1.6 and 10.1.1.7, then argued that a notoriously known general-purpose computer could be regarded as the closest prior art and that the features distinguishing the claimed invention from this closest prior art made no technical contribution because they were either part of the non-technical requirements specification or achieved no technical effect going beyond the well-known and normal physical interactions between a program and a computer. Since there was no technical contribution to the art, the subject-matter of claim 1 lacked inventive step.

4.2 Although in many cases the implementation of a non-technical scheme on a general-purpose computer results in subject-matter that is obvious, this is not inevitably the case. As the Examining Division essentially stated in point 10.1.1.4 of its decision, non-technical features are to be taken into account in the assessment of inventive step to the extent that they interact with the technical subject-matter of the claim to solve a technical problem or bring about a technical effect (see G 1/04, OJ EPO 2006, 334, reasons 5.3; T 154/04, OJ EPO 2008, 46, reasons 5, under (F), and 13 to 15). It therefore still has to be analysed whether, and to what extent, the non-technical scheme, when implemented on a computer, produces a technical effect over that computer.

4.3 From the logic of the decision's reasoning, it appears that point 10.1.1.5 is supposed to represent this analysis. But there, the Examining Division merely re-examined the wording of the claim to distinguish, once more, between technical and non-technical features. It did not explain why the non-technical features, when implemented on a computer, made no contribution to a technical effect, for example by analysing the functionality of the claimed system as a whole and any effects put forward by the appellant.

4.4 The closest to such an analysis appears to be the second paragraph of point 10.1.1.2, which states that "effects stemming from the algorithmi[c] definition of a method do not define a technical character of the corresponding features" and refers to decision T 1954/08 of 6 March 2013, reasons 6.2, which argues that "the sole processing speed" of a computer-implemented algorithm and "the sole amount of memory" it requires are not suitable criteria for determining whether or not a method step contributes to the solution of a technical problem.

However, these statements in decision T 1954/08 cannot be taken to mean that any effect resulting from the implementation of a non-technical feature or combination of features is non-technical. If non-technical features could not contribute to a technical effect because they are non-technical, there would be no need for the analysis referred to in point 4.2 above.

At the same time, just because non-technical features, when implemented on a computer, almost inevitably have some effect on physical quantities such as processing time and memory usage, this does not mean that any such physical effect qualifies as a technical effect for the purpose of assessing inventive step. Something more is needed, for otherwise any computer program feature would make a technical contribution when the computer program is executed. In the Board's view, this is how point 6.2 of the reasons of T 1954/08 is to be understood. This line of reasoning has been developed further in later decisions (see, for example, decisions T 817/16 of 10 January 2019, reasons 3.6, 3.7 and 3.12; and T 697/17 of 17 October 2019, reasons 5.2.3 and 5.2.4).

4.5 In sum, the contested decision's inventive-step reasoning is incomplete as it stands, and the general approach to assessing inventive step taken in the decision is prone to overlook technical contributions made by non-technical features.

5. The Board's assessment of inventive step

5.1 There can be no doubt that the claimed OLAP specification system is a physical (computer) system in any reasonable interpretation and does not encompass entirely non-technical "systems" such as organisational schemes (e.g. a patent system). This is already clear from the four "modules" it comprises and is confirmed by the claim's references to files, presentation of options and receipt of input via a user interface based on the presented options, and also by the feature specifying that the system is configured to perform operations on the new OLAP cube. Hence, the subject-matter of claim 1 is not excluded from patentability as a "non-invention" under Articles 52(2) and (3) EPC.

5.2 As discussed in point 3.6 above, the claimed OLAP specification system allows a user not only to create a metadata file that specifies the structure of an OLAP cube but also to view data through an OLAP cube corresponding to the newly created metadata file.

At the oral proceedings before the Board, the appellant agreed with the Board that the latter type of functionality corresponds to the functionality of the conventional OLAP system described in paragraphs [0002] to [0005] of the background section of the application. This conventional OLAP system allows a user to view data through and perform operations on OLAP cubes defined by a "technical solution team" in accordance with the user's wishes. The OLAP-cube definition provided by the technical solution team must somehow be stored as a "metadata file" and be instantiated by the conventional OLAP system.

Further evidence of such prior art is given by document D1, which discloses, in paragraphs [0099] to [0102] and Figures 5A to 5D, a GUI-based process for defining an OLAP cube structure.

5.3 The system of claim 1 differs from the prior-art OLAP system in that it comprises the four modules listed in claim 1, which together implement the "OLAP specification" functionality that is the focus of the application. This functionality allows the system's user to specify the metadata file that, in the prior-art OLAP system, is received from the external technical solution team.

The Board agrees with the Examining Division that each of the four modules can be implemented by suitably programming a general-purpose computer having conventional input/output means such as a keyboard, mouse and display. It has to be determined to what extent these software features interact with the technical features of the claim to achieve a technical effect over the prior-art OLAP system.

5.4 The overall effect of the four modules is the generation of a metadata file which defines the structure of an OLAP cube and which is to be used by the claimed system's conventional OLAP functionality.

This generated metadata file cannot be technically distinguished from the metadata file produced by the technical solution team of the prior art: the four claimed modules do not ensure any special property of the generated metadata file that translates into a technical effect, occurring when the file is used by the system's conventional OLAP functionality, that is different from the technical effects that occur when a metadata file produced by a technical solution team is processed.

Indeed, the only feature imposing a specific limitation on the generated metadata file is the rule "that certain levels of a dimension must stay grouped in a view", but this rule merely implements non-technical requirements such as the above-mentioned requirement that "years", "month" and "quarters" levels of the "time" dimension must not be separated. Although the rule influences the results of queries executed against the specified OLAP cube, this is not a technical effect but rather the consequence of a non-technical requirement not based on technical considerations (see also T 817/16, reasons 3.12). For the same reason, the Board is not convinced by the appellant's argument that the generated metadata file is technically distinguished from an existing metadata file because the corresponding OLAP cubes may have different dimensions.

Hence, the generated metadata file does not represent a technical effect achieved over the prior-art OLAP system. Any technical effect is thus to be found in the generation process itself.

5.5 The generation process implemented by the four modules is largely based on a non-technical, clerical process: the user chooses a template metadata specification and modifies it by carrying out a number of modifications that comply with one or more predetermined rules, where one of the predetermined rules includes a rule to specify that certain levels of a dimension must stay grouped in a view.

The four modules implement this non-technical process in a straightforward manner:

- the OLAP-cube template determination module is configured to allow the user to select a template metadata specification and to retrieve the corresponding metadata file;

- the metadata copy module is configured to create a copy of the retrieved file for further modification;

- the viable-options generation module is configured to present modification options that comply with the predetermined rules, where one of the predetermined rules includes a rule to specify that certain levels of a dimension must stay grouped in a view;

- the metadata receipt module is configured to allow the user to select a modification and to carry out the selected modification.

Indeed, the only technical features here relate to reading and writing data from and to files and the use of implicit input and output devices for receiving input from and presenting information to the user. Since these features are well known and are used for their normal purpose, they do not support an inventive step.

5.6 The appellant's argument that there were many ways to begin creating a new OLAP cube and that claim 1 taught the skilled person to start from a template metadata file and make a copy of the file has no bearing on this finding because the existence of alternative approaches to generating a metadata file is unrelated to the (lack of) technicality of the generation process implemented by the claimed invention.

5.7 The appellant also argued, with respect to the OLAP-cube template determination module, that the "structure of the OLAP cube" was essentially the schema of an OLAP cube, and that storing a schema in its own file was a (technical) implementation detail, in particular because schemas were generally stored in a central metadata table or a data dictionary and because how data was stored in a database system was technical.

As explained in point 5.2 above, the Board considers that in the prior-art conventional OLAP system, the OLAP-cube structure defined by the technical solution team is already provided as a "metadata file".

5.8 In sum, since the features distinguishing the claimed invention from the prior-art OLAP system amount to the straightforward and thus obvious implementation of a non-technical process, the subject-matter of claim 1 lacks inventive step (Article 56 EPC).

First auxiliary request

6. Inventive step

6.1 Compared with claim 1 of the main request, claim 1 of the first auxiliary request adds the following features:

- an OLAP-cube template data store storing a plurality of OLAP-cube templates defined in read-only template metadata files;

- a user-interface module for receiving a user selection of an OLAP-cube template;

- the OLAP-cube template determination module retrieves the user-selected template metadata file from the OLAP-cube template data store.

6.2 The user-selection aspect was already taken into account in point 5.5 above. Since it would have been a routine matter for the skilled person to provide a data store for storing the available (read-only) template metadata files and a user-interface module for receiving the user selection of a template metadata file, the features added to claim 1 do not overcome the objection of lack of inventive step (Article 56 EPC).

Second auxiliary request

7. Admission into the proceedings

7.1 Compared with claim 1 of the main request, claim 1 of the second auxiliary request defines a "rules module" for receiving and processing "rules for data access". These rules for data access are stored "in the form of a dimension for the new OLAP cube".

7.2 The "rules module" features of claim 1 are based, inter alia, on original dependent claim 5, which includes the features "receive rules of data access", "store the rules as a rules dimension in the new OLAP cube" and "determine whether a user has access to a dimension or a level in the dimension in the new OLAP cube by accessing the rules dimension".

7.3 In point 2.2 of the European search opinion, original claim 5 was objected to under Articles 83 and 84 EPC because it contained the term "rules dimension". In response, the appellant, in its letter of 20 October 2011, deleted this feature from the claim.

7.4 The appellant has now re-introduced the "rules dimension" feature in a slightly reworded form in the second auxiliary request. Since the feature was already present in original claim 5, the second auxiliary request could have been filed in the first-instance proceedings. Its admission into the appeal proceedings is therefore at the Board's discretion under Article 12(4) RPBA.

7.5 The re-introduction of the feature re-introduces the issues under Articles 83 and 84 EPC raised in the European search opinion that the appellant had chosen to address by deleting rather than defending the feature. This alone could be a reason for not admitting the request into the appeal proceedings.

7.6 Moreover, the Board considers that the issues raised are genuine and cannot be easily resolved without deleting the feature.

7.6.1 The Board first notes that, although the claim now refers to storing the rules in the form of a "dimension for the new OLAP cube" (as taken from paragraph [0026] of the description), the appellant continued to refer to claim 1 as specifying that the data-access rules are stored in the form of a dimension of the OLAP cube (see e.g. the paragraph bridging pages 11 and 12 of the appellant's letter of 2 October 2019). This is also consistent with original claim 5, which states that the rules are stored "as a rules dimension in the new OLAP cube" and with paragraph [0018], which discloses that "[d]ata-access rules may be defined by a dimension of an OLAP cube". According to paragraphs [0016] and [0020], data-access rules are defined by metadata in a template metadata file.

7.6.2 The "new OLAP cube" defined by the new metadata file is not an actual OLAP cube populated with data but merely the structure of an OLAP cube. The question therefore arises whether the data-access rules are somehow defined "in the form of a dimension" in the new metadata file or whether they are stored in the actual multidimensional data store on which the OLAP cube provides a view and are viewed through a dimension of the OLAP cube.

7.6.3 At the oral proceedings, the appellant argued for the latter interpretation. For each created OLAP cube, data-access rules were created in a portion of the multidimensional data store, and the "rules dimension" of the OLAP cube provided a view on this portion. But this interpretation conflicts with paragraphs [0016] and [0020], which disclose that the data-access rules are themselves defined by metadata in the (template) metadata file.

On the other hand, the former interpretation, whereby the data-access rules are stored "in the form of a dimension" in the metadata file, is also problematic, since the application contains no details on how metadata that defines the structure of an OLAP cube could at the same time define data-access rules.

7.6.4 Hence, the meaning of the feature specifying that the data-access rules are stored "in the form of a dimension for the new OLAP cube" is uncertain and remains so when the claim is read in the light of the application as a whole.

7.7 In view of these issues caused by the re-introduction of a previously deleted feature, the Board decides to exercise its discretion under Article 12(4) RPBA not to admit the second auxiliary request into the appeal proceedings.

Third auxiliary request

8. Inventive step

8.1 Compared with claim 1 of the first auxiliary request, claim 1 of the third auxiliary specifies that the operations performed on the new OLAP cube are "slicing and drill down" operations.

8.2 The appellant explained that this amendment was intended to address a potential clarity objection and that "slicing and drill down" operations were standard OLAP analysis operations which were well-known to the skilled person.

8.3 The Board sees no reason to disagree and concludes that the amendment made to claim 1 of the third auxiliary request does not overcome the objection of lack of inventive step (Article 56 EPC).

Conclusion

9. Since none of the requests admitted into the appeal proceedings is allowable, the appeal is to be dismissed.