T 2841/19 (Business service context/BMC SOFTWARE) 25-10-2022

The invention

1. The application relates to the collection and display of information related to a business service (description as published, paragraph [0001]).

The description discloses (paragraph [0032]) that the term "business service" refers to a software application or a computing device operated within an information technology environment. The description discloses (paragraph [0033]) that the term "business application" refers to a business service that is a software application (e.g. a help-desk application or a sales automation application) and that the term "business server" or "business application server" refers to a computing device that executes a business application. A business service context may include a means by which applications can reach into data they do not normally provide themselves or have access to in order to give users a condensed view ("service context summary view") of what a given business service is and how it is performing (paragraphs [0044] and [0153]). The description (paragraphs [0090] and [0091]) provides an example of a service context summary view in Figure 4a, which shows a status indicator (reference sign 418) as an orange "X" icon. This icon gives a user a quick indication that the business service "Sales Automation" is in a "warning" state (e.g. a "critical" or "imperfect" state). The service context may include information such as the business service description, business service owner or business service state (paragraph [0053]). The use of a business service context for routing service desk tickets to the correct personnel is disclosed in paragraph [0049].

A federated database may be partially virtual as the federated database may include both non-virtual fields (database entries) and virtual fields that are aggregated to provide the illusion that the federated database includes a larger, more informative database than actually exists. The virtual fields may include any database fields and values that are retrieved from a provider application and only nominally stored in the federated database (description, paragraphs [0059], [0068] and [0071]).

Main request

2. Inventive step

2.1 The examining division considered document D2 to be a suitable starting point for assessing inventive step; the appellant did not contest this and the board agrees.

2.1.1 The examining division concluded that the method of claim 1 differs from the disclosure in document D2 as follows.

- According to claim 1 the application that requests, receives and displays the data is a mobile application, and the computing device that executes the application is a mobile computing device that receives the data by a network interface, whereas D2 is silent on both the type of application/computing device and the way the data are received.

- According to claim 1 the requested portion of the business context is a portion regarding a business server being a computing device executing a business application, whereas in D2 the requested portion of the business context is sales data from department stores.

The examining division then concluded that the distinguishing features regarding the use of a mobile device were obvious as they did not contribute to any surprising or unexpected effect. The examining division considered that the distinguishing features concerning essentially the kind of "business context", i.e. the kind of data requested, received and displayed, did not contribute to the technical character. It argued that the claim did not go beyond displaying the data, which did not produce a technical effect. The examining division was also of the opinion that even a notification of a critical hardware failure (although the claimed method was not limited to this) as such only satisfied a user's need for information and would not contribute to a technical effect. Consequently, the method of claim 1 lacked an inventive step in view of document D2.

2.2 In its statement of grounds of appeal, the appellant argued that the feature mapping between claim 1 and the disclosure in document D2 was incorrect and that the examining division had therefore arrived at the wrong conclusions with respect to inventive step.

2.3 Consequently, in the following the board will review the disclosure in document D2 and the feature mapping used by the examining division.

2.3.1 For the relational database management system DB2, document D2 discloses a usage scenario regarding the integration of data from various data sources. The examining division referred to the sections "Why use a database engine for data integration" (D2, pages 587 and 588) and "DB2 federation usage scenarios" with the subsection "Federation of distributed data" (D2, pages 588 and 589; Figure 4).

2.3.2 Figure 4 depicts an overview of the federation architecture in the usage scenario disclosed in document D2. DB2 is used in a corporate office to integrate transaction data from department store sales. The New York and San Francisco department stores use an Oracle database management system to record business transactions. The corporate office using DB2 can then use an Oracle wrapper to access data in the New York and San Francisco Oracle databases and can access other stores using appropriate wrappers for their databases, if needed. This makes it possible to use DB2 to generate a (nationwide) sales report across all stores.

As explained in document D2 on page 589, left-hand column, DB2 can access the stores' two Oracle databases by means of a view ("National_Transactions"), which enables a national sales report to be generated by accessing the sales transaction data in the various store databases by means of a single SQL query ("SELECT MONTH ..."). Moreover, D2 discloses (last three paragraphs on page 589, left-hand column) that an automatic summary table, i.e. a materialised view, named "Past_Sales" is used to cache the sales transaction summary data for previous years in the local data store, i.e. in DB2. DB2 can then exploit this local store as a cache to avoid accessing data from remote store databases when these summary data are needed to answer a query (D2, page 589, left-hand column, last paragraph, to right-hand column, first paragraph).

2.3.3 Regarding the mapping of the features of claim 1 to the disclosure in document D2, the board agrees that D2 does not disclose a mobile application or a mobile computing device (having a network interface), as already accepted by the examining division. Consequently, features A1, B1, B9 and C1 are not disclosed in D2.

2.3.4 The board also accepts that the sales transaction data of the department stores mentioned in document D2 are business data but not "at least a portion of a business service context regarding a business server being a computing device executing a business application and including a plurality of attributes associated with a business service" as defined by feature A2. Consequently, the board presently considers that features A2, B4, B6a and C2, which all relate to business service context data, are not disclosed in document D2 either.

2.3.5 As to features A, B and B3 of claim 1, it is evident that, for example, performing the query disclosed in document D2 to generate the national sales report can be regarded as a computer-implemented method requesting aggregated business data which are then received "in a single database transaction". The board considers that claim 1 does not further specify the term "transaction" as regards its transactional properties, so it at least covers usual database transactions as implemented by DB2 (see D2, page 587, left-hand column, last paragraph; see also the description of the application, paragraphs [0062] and [0066]). Consequently, features A, B and B3 are disclosed in document D2.

Moreover, the federated database disclosed in D2, Figure 4 and the associated text is an at least partially virtual database in which the views for data stored remotely in the store databases (using Oracle databases, for example) correspond to virtual data fields and the data stored locally in DB2 are non-virtual data fields (such as the computed fields year, month and sales in the materialised view "Past_Sales"; the sales field is defined as the name of the expression "Count(*)", which computes a count of the total number of items sold per month in all stores - see page 589, left-hand column, the paragraph after the "CREATE VIEW" statement). Consequently, D2 discloses features B2 and B5.

Regarding feature B6, the board considers that at least the field "item_id" in the "Past_Sales" materialised view is a cached virtual field (see D2, page 589, left-hand column, the view definition National_Transactions, which refers to "item_id" fields in the nicknamed database tables; see also D2, page 587, right-hand column, second paragraph, which discloses that the local store is also used as a cache, i.e. for temporary storage). In addition, all data retrieved from the remote databases is "cached" locally by DB2 in the database buffer for further processing, as is well known to the skilled person, and can be materialised

for longer periods (see D2, page 587, second and third paragraphs; see also the application, Figure 3, reference signs 350, 354 and 360 (cache) and the description, paragraphs [0070] and [0072]).

The virtual and non-virtual fields are used in combination to answer a query for the national sales as disclosed in D2, page 589, left-hand column, last paragraph, to right-hand column, first paragraph and page 587, right-hand column, third paragraph, where re-using pre-aggregated data for later queries is disclosed. Consequently, D2 also discloses features B6, B7 and B10.

The board agrees with the examining division that feature B8 is disclosed in D2 because the store databases in D2 can be mapped to a "business application data repository" of a "business application" that records business transactions (see D2, page 588, right-hand column, first full paragraph).

The board agrees with the examining division that D2 implicitly discloses displaying the query results and thus feature C.

2.3.6 At the oral proceedings the appellant argued that document D2 did not disclose the features of claim 1 relating to a "virtual database" (see features B2, B5, B6, B7, B8 and B10, for example) since a virtual database and a federated database were different concepts. A federated database as disclosed in document D2 (see page 580, right-hand column, last paragraph; page 593, right-hand column, last paragraph; page 589, left-hand column and Figure 4, for example) integrated only databases, i.e. data sources such as the Oracle databases, that were in a "database format".

The appellant also argued that a virtual database according to the invention differed from a federated database as disclosed in document D2 in that it additionally provided access to data stored in data sources other than databases, such as a business application data repository. This was necessary to provide the business service context since not all relevant business data were available in databases. Consequently, accessing such data involved converting data that were not in a database format. To support its arguments about the distinction between a virtual database and a federated database, the appellant referred to the description (paragraphs [0059], [0067], [0068] and [0071], for example).

2.3.7 At the oral proceedings, the board asked the appellant whether the method of claim 1 excluded the possibility of the business application data repository also encompassing a database or of a database query being used to access this repository. In this context, the board also pointed the appellant to Figure 3 of the application as filed, which depicts a communication between the "Federated / Virtual Database 304" and the "Application 306" to access data by means of a "DB Query 316". The appellant argued that Figure 3 disclosed only a particular embodiment but admitted that claim 1 did not include a limitation whereby the data repository according to feature B8 of claim 1 was different from a database. Consequently, the board is not convinced that its feature mapping for the features related to the "at least partially virtual database" was incorrect.

Moreover, at the oral proceedings, the board argued that the appellant's interpretation of the expressions "virtual database" and "virtual field" did not correspond to the disclosure in paragraphs [0068] to [0070] of the application, for example. In the light of the cited passages, the board considers that the application as filed discloses that the virtual fields are not those that are stored locally in the database but those accessed dynamically from provider applications, which is different from the appellant's interpretation. This is a further reason why the appellant's arguments are not convincing.

Lastly, at the oral proceedings, the board referred the appellant to document D2, page 582, left-hand column, second full paragraph, which discloses that DB2 provides wrappers for various data sources including not only relational databases but also other kinds of data stores. Consequently, even if further distinguishing features over document D2 were accepted, as argued by the appellant, these features would be obvious in view of the prior art disclosed in D2.

2.3.8 In view of the above, the board considers that features A1, A2, B1, B4, B6a, B9, C1 and C2 are the distinguishing features in view of document D2.

2.4 While the board's feature mapping deviates somewhat from that in the contested decision, the board agrees with the examining division's essential line of reasoning regarding the lack of an inventive step, for the following reasons.

2.5 Regarding the technicality of the distinguishing features, the appellant cited decision T 115/85, according to which automatically giving visual indications about conditions prevailing in an apparatus or system was a technical problem. Consequently, collecting data regarding the status of a technical system was a technical task and the distinguishing features relating to the business service context contributed to the technical character of the claimed method.

2.5.1 In decision T 115/85, Reasons 12, the responsible board decided that the subject-matter of claim 1 was not barred from protection by Article 52(2)(c) and (3) EPC; its decision was on whether there was patent eligibility under Article 52(2)(c) and (3) EPC, not on the issue of inventive step.

According to the recent case law from the Enlarged Board of Appeal in its decision G 1/19, points 28, 29 and 78, the criterion for computer-implemented inventions to be eligible for patent protection is now the "any hardware" approach, which was not used in decision T 115/85. For this reason alone, decision T 115/85 is irrelevant for the question of whether there is an inventive step under Article 56 EPC.

2.5.2 For the case in hand, decision G 1/19 provides the essential case law on how to assess the requirements of Article 56 EPC regarding subject-matter involving a computer program. Decision G 1/19, point 79, explains that for assessing inventive step, prior art has to be considered and the features of the claimed invention contributing to an inventive step have to solve a technical problem over the prior art. Solving a technical problem means that a technical effect is achieved over substantially the whole scope claimed (see decision G 1/19, points 82 to 84).

2.6 In the board's view, the examining division correctly arrived at the conclusion that the distinguishing features can be separated into two groups: a first group of features A1, B1, B9 and C1 relating to the use of a mobile client and mobile application to access the DB2 database in document D2, and a second group of features A2, B4, B6a and C2 relating to the use of the business service context. These feature groups can be dealt with independently of each other in the problem-solution approach since the board cannot see how these groups of features interact to produce a synergistic technical effect.

2.6.1 The appellant argued that these two groups of distinguishing features interacted to produce a synergistic effect. The size of the display of a mobile device such as a mobile phone was inherently more limited than that of other devices such as a PC, and the same was true for the communication bandwidth. In view of these device limitations, the business service context, which provided an aggregated view and not the full context, was particularly suitable for a mobile device. As an example of a business service status warning which took up only a small amount of space on the display, the appellant pointed to the visual indication of a performance status of a business service depicted in Figure 4a (reference sign 418) of the application. Furthermore, the idea underlying a mobile device was that users carry their device all the time and could receive information without delay. The mobile device with the service context also enabled the user to take appropriate steps without a need to start applications or the like.

2.6.2 When asked by the board at the oral proceedings, the appellant admitted that claim 1 was not limited to a particular type of mobile device such as a mobile phone, or to a display with size constraints. As a mobile device encompasses devices such as a laptop with a high-resolution screen that users may not always carry with them, and as claim 1 does not contain any limitation on the bandwidth of the mobile device's connection either, the appellant's arguments in that regard are not convincing. Furthermore, the claimed method is silent regarding any steps that users take when the service context is displayed. Consequently, the appellant's argument that it was easier to take appropriate action on the basis of the displayed service context is not convincing either.

2.6.3 Rather, the board considers that, when starting from document D2, features A1, B1, B9 and C1 provide the technical effect of accessing the DB2 database by means of a mobile device. The board also agrees with the examining division that a mobile device with a network interface and a mobile application was well known (if not notoriously known) at the priority date and that the use of this well-known device had only foreseeable, well-known advantages and was a matter of routine development. Thus, features A1, B1, B9 and C1 are obvious when starting from document D2.

2.6.4 Regarding the distinguishing features A2, B4, B6a and C2, the board agrees in essence with the examining division that features relating to the use of a business service context as data do not contribute to a technical effect in the internal operation of the computer system (and are evidently not related to controlling any device external to the computer system or the like). Rather, these distinguishing features relate to the content of the information that is displayed, i.e. to information presented to a user (Article 52(2)(d) EPC). It is not credible that the kind of data (sales transaction data in D2; business service context data in claim 1) has any technical impact on how the retrieval is carried out by the database management system (i.e. on the internal operation of the computer system) over substantially the whole scope claimed.

The board agrees with the examining division that the presentation of information to a user satisfies the user's information needs and, as such, has no other effect. In particular, the claimed method does not specify that the displayed information is used or how (e.g. for replacing a failed hardware component), so a technical effect relating to a potential use of the displayed information is not achieved over substantially the whole scope claimed (see also decision G 1/19, point 123).

2.7 Consequently, the subject-matter of claim 1 lacks an inventive step over the disclosure in document D2 (Article 56 EPC).

First auxiliary request

3. Claim 1 of the first auxiliary request differs from claim 1 of the main request in that the at least partially virtual database is further specified as being a configuration management database.

4. Inventive step

4.1 At the oral proceedings the appellant argued that a configuration management database added technicality as configuring business applications was technical. Users were able to configure what information they wished to see, for example.

4.2 Limiting the virtual database to a configuration management database is insufficient to establish a technical effect. A configuration management database for a business application may comprise non-technical configuration parameters such as languages, currencies, legal parameters and so on, and is not limited to "technical information". Moreover, the board cannot identify any configuration steps in the method of claim 1 and does not accept the appellant's argument that such steps are implied by the feature of a configuration management database.

4.3 Consequently, the board is not convinced that the amendment made in the auxiliary request provides further support for the technicality of the claimed method as argued by the appellant. It follows that the subject-matter of claim 1 of the first auxiliary request lacks an inventive step (Article 56 EPC).

Second auxiliary request

5. The second auxiliary request was submitted in reply to the board's summons as a direct response to an issue raised for the first time by the board under Article 123(2) EPC. At the oral proceedings, the appellant maintained the second auxiliary request but stated that this request did not address the inventive-step objections.

6. Inventive step

As claim 1 of the second auxiliary request differs from claim 1 of the first auxiliary request in that the words "status" and "including the virtual values and non-virtual values of the aggregated database result (166)" have been deleted from feature C2 of claim 1, its scope is broader than that of claim 1 of the first auxiliary request.

Consequently, the inventive-step objection against claim 1 of the first auxiliary request also applies to claim 1 of the second auxiliary request. It follows that the subject-matter of claim 1 of the second auxiliary request lacks an inventive step (Article 56 EPC) over document D1.

Conclusion

7. Since none of the appellant's requests is allowable, the appeal is to be dismissed.