T 0409/24 (Multi-user project handling/ZURICH INSURANCE COMPANY) of 9.4.2025

Summary of Facts and Submissions

I. The appellant (applicant) appealed against the examining division's decision refusing European patent application No. 21217462.7 (published as EP 4 202 721) with a filing date of 23 December 2021.

II. The documents cited in the contested decision were:

D1 WO 2019/070766 A1, published on 11 April 2019

D2 US 2016/0350716 A1, published on 1 December 2016

D3 US 2016/0063840 A1, published on 3 March 2016

D4 US 2018/0189706 A1, published on 5 July 2018

D5 US 2012/0016849 A1, published on 19 January 2012

D6 WO 2013/162837 A1, published on 31 October 2013

III. The examining division decided that the subject-matter of the claims of the main request and of the independent claims of each of the first to fifth auxiliary requests lacked inventive step over the prior art disclosed in document D1 and the common general knowledge. The examining division cited documents D2 to D4 as evidence for the common general knowledge of the skilled person. The examining division also decided that the independent claims of the second to fourth auxiliary requests were unclear.

IV. In its statement of grounds of appeal, the appellant requested that the contested decision be set aside and that a patent be granted on the basis of the main request considered in the contested decision and resubmitted with the statement of grounds of appeal or one of auxiliary requests A1 to A5 submitted with the statement of grounds of appeal.

V. In a communication under Article 15(1) RPBA, the board expressed among other things its provisional opinion that the subject-matter of claim 1 of the main request lacked inventive step in view of document D1 and the common general knowledge of the skilled person and that auxiliary requests A1 to A5 were not admissible.

VI. By letter of reply, the appellant maintained all of its claim requests and submitted further arguments in view of the board's preliminary opinion.

VII. Oral proceedings were held as scheduled and the appellant was heard on the relevant issues. At the end of the oral proceedings, the Chair announced the board's decision.

VIII. The appellant's final requests were that the decision under appeal be set aside and that a patent be granted on the basis of the main request considered in the decision under appeal or one of auxiliary requests A1 to A5 filed with the statement of grounds of appeal.

IX. Claim 1 of the main request reads as follows (the itemisation "a" to "h3" of the claim features has been added by the board):

a "Digital workbench (WB) for multi-user project handling, configured such as to allow for multiple user (U1, U2, ?) to change data (D) in a database system (DBS), the digital workbench (WB) comprising:

b i) a user interface (UI);

c ii) two or more modules (M1, M2, ?), each comprising a document store (DS1, DS2, ?);

d wherein a user (U1) has access to only one module (M1);

e wherein the data (D) comprises distinct entities (A, B,?);

f wherein the same entities (A1, A2, ?; B1, B2, ?) are comprised in two or more document stores (DS1, DS2, ?);

g1 wherein the entities (A1, A2, ?; B1, B2, ?) can be changed by a user in the respective document store (DS1, DS2, ?) of the respective module (M1, M2, ?);

g2 wherein the system is configured such that, when a change is being made to an entity (A1) in the document store (DS1) of a module (M1), a change notification (N) is sent out to respective other module(s) (M2, ?);

h1 wherein the system is configured such that in respective other module(s) (M2, ?) in response to the change notification (N)

h2 - the respective entity (A2, ?) that corresponds to the changed entity (A1) is being updated accordingly;

and/or

h3 - other entities (B2, ?) than the one corresponding to the changed entity (A1) are being changed based on (a) pre-defined rule(s)."

X. Claim 1 of auxiliary request A1 differs from claim 1 of the main request in that the following text has been added at the end of the claim:

"; wherein the digital workbench (WB) comprises a central operational data store (ODS), wherein the system is configured such that the central operational data store (ODS) is kept continuously up to date to a pre-defined level by tracking changes in the document stores (DS1, DS2, ?) of the two or more modules (M1, M2, ?);

wherein not each change is tracked in the central operational data store (ODS)".

XI. Claim 1 of auxiliary request A2 differs from claim 1 of auxiliary request A1 in that the following text has been added at the end of the claim:

"wherein the digital workbench (WB) is configured such that the same entity (A1, A2, ...) can be updated at the same time in different modules (M1, M2, ...)".

XII. Claim 1 of auxiliary request A3 differs from claim 1 of auxiliary request A2 in that the following text has been added at the end of the claim:

"; wherein the updating is dealt with by each module based on the change notifications and change handling rules that are customized to the respective module".

XIII. Claim 1 of auxiliary request A4 differs from claim 1 of auxiliary request A3 in that the following text has been added at the end of the claim:

"; wherein changing an entity means that a value is set for an entity".

XIV. Claim 1 of auxiliary request A5 differs from claim 1 of auxiliary request A4 in that the text "and/or" at the end of feature h2 has been amended to "and".

XV. The appellant's arguments relevant to the present decision are discussed in detail below.

Reasons for the Decision

1. The object of the invention is to run multi-user project handling systems in the digital environment more efficiently and more reliably, and at the same time to avoid user frustration when simultaneous changes of various users on the same project, such as an infrastructure planning and building project, are carried out in a document database (description of the application as filed, pages 1 and 2).

Main request

2. The main request corresponds to the main request considered in the decision under appeal and is therefore in the appeal proceedings according to Article 12(1) and (2) RPBA.

3. Inventive step

3.1 The appellant agreed with the examining division that document D1 is a suitable starting point for assessing inventive step.

3.2 The examining division argued that document D1 disclosed all features of claim 1 of the main request except for features d, g2 and h1.

3.2.1 The examining division considered that feature d did not interact with the further distinguishing features to bring about a synergistic effect and applied the problem-solution approach separately to feature d on the one hand and to the two further distinguishing features g2 and h1 on the other hand. Feature d was merely a trivial implementation of the non-technical constraint that a user has only access to a single module of the application.

The distinguishing features g2 and h1 specified that changes were pushed by change notifications whereas document D1 disclosed that the changes were pulled. However, a push distribution of data by sending change notifications was well known in data exchange systems as shown by document D3, for example.

3.3 The appellant argued that the examining division's feature mapping was artificial and incorrect. The system disclosed in Figure 1 of document D1 and the system according to Figure 1 of the application as filed had different system architectures. Figure 1 of document D1 is reproduced below.

FORMULA/TABLE/GRAPHIC

3.4 The appellant pointed out that the examining division had changed the initial mapping of features of claim 1 to the features disclosed in document D1. In the decision under appeal, the examining division had mapped a first module of the claimed workbench to server 40 and a second module to the third party application 60. This mapping was technically forced and artificial and did not reflect what claim 1 specified. The system of document D1 was a centralised system. The third party application in D1 was passive. It was not notified of any changes and there was no disclosure that the user could modify data at the third party application 60, or that any user changes were replicated to the server 40.

3.5 In the prior art D1, several collaborating users (see the user devices with reference signs 20 and 30 in Figure 1) could change data, but the data storage was centralised in server 40 (corresponding to a first module in claim 1). The third party server 60 of D1 (corresponding to a second module in claim 1) was not part of a collaborative system. D1 did not disclose that any user changed data on the third party server 60 and no change notifications were sent between the servers 40 and 60. At best document D1 disclosed that the server 40 requested data from the third party application 60 but not the other way around. However, there was no disclosure that the user made the update at the third party application. Moreover, requesting data was different from sending change notifications whenever a change was made as claimed. In the system of document D1 data was requested only at certain points in time whereas according to claim 1 change notifications were sent for each change made and symmetrically between the modules.

3.5.1 In sum, the appellant argued that the system of D1 was very different from the claimed invention and that document D1 did not disclose features d, g1, g2, h1, h2 and h3. The appellant did not contest that document D1 disclosed features a, b, c, e and f of claim 1.

According to the appellant, the effect of the combination of the distinguishing features was "to prevent clashes within the database when several users want to change the same data at the same time" (statement of grounds of appeal, paragraph bridging pages 7 and 8). In this context, the appellant also submitted that the module available to a user was configured to the specific expertise of the user in each case as disclosed in paragraph [0008] of the description of the published application.

3.5.2 According to the appellant, the objective technical problem to be solved over D1 was "to provide a multi-user project management system with improved efficiency and reliability, thereby avoiding user frustration" as disclosed in page 2, line 12 of the description of the application as filed.

At the oral proceedings, the appellant confirmed that the alleged effects of improved efficiency and reliability were achieved by avoiding conflicting updates of the same entity at the same time (in different modules; see page 4, lines 22 to 23 of the description of the application as filed).

3.5.3 According to the appellant, the technical effect achieved by the invention was not achieved by the system disclosed in D1. Neither D1 nor the further prior art provided a motivation for the skilled person to arrive at the claimed solution.

3.6 In the following, the board reviews the disclosure of document D1 and the examining division's feature mapping.

3.6.1 Document D1 discloses a network-based server system that facilitates collaboration by a plurality of users. The system is used to prepare a construction project estimate in accordance with an established workflow and assigned tasks that are carried out by the plurality of users that collaborate to prepare the construction project estimate. The established workflow may include various interdependent tasks and the construction project estimate is updated in real time based on current material and labour costs obtained from a local database or from a third-party application device that provides real time material cost information (D1, abstract).

Figure 1 of D1 shows that the system comprises various user interface devices connected to a server 40. This server communicates with a further server 60 running third-party software to provide or receive information (paragraphs [18] and [19]). Paragraph [18] discloses that the system depicted in Figure 1 of D1 optionally comprises multiple servers 40 and third-party servers 60, i.e. does not necessarily have a centralised system architecture. Both types of servers have a data storage area (see reference signs 45 and 65 in Figure 1 of D1). Material costs are stored both in the third-party server and the server 40. On request from the server 40, material costs are transmitted for real-time updates to the server 40 (D1, paragraphs [09], [10], [17], [18], [19], [21], [27] to [30], [34], [39]), i.e. the server "pulls" the update from the third-party server by means of an "integrations module".

The integrations module is configured to integrate the server 40 with one or more third party application devices 60. In one embodiment, the integrations module comprises a plurality of programmed interfaces that are each customised to integrate the server 40 with a specific third party application device 60. In operation, the server 40 requests to send or receive information to or from a specific third party application device 60 and the appropriate programmed interface is configured to contact the specific third party application device 60 via a data communication network and provide or receive information to or from the specific third party application device 60. Examples of third party applications are accounting utilities or construction project management utilities (D1, paragraph [39]).

The examining division considered that the third-party server 60 and the server 40 could be mapped to two modules in claim 1. The board agrees that this is a possible feature mapping which was accepted by the appellant as a basis for the debates. The system disclosed in document D1 achieves the function of multi-user "project handling", since relevant data are exchanged between modules/servers to prepare a construction project estimate and multiple users participate in this project.

3.6.2 In view of the above, it follows that document D1 discloses features a to c, e and f and this was not contested by the appellant.

3.6.3 It is also not controversial that features d, g2 and h1 are not disclosed in document D1. The latter two distinguishing features being a consequence of using "pull"-based communication (asking for an updated value when accessing a data item) instead of "push"-based communication (sending notifications of changes after updates) for updates. The board agrees with the appellant that in "pull"-based communication, not each update triggers a communication, but considers that this is inherent in pull-based communication since the server 40 does at least in general not know when relevant data on server 60 was updated, for example. This also means that the server 40 might request the data from server 60 even though that data was not changed on server 60.

In the context of the feature mapping at hand, it is irrelevant that the user interface devices 20 and 30 of Figure 1 of document D1 modify data on server 40, but not on server 60. Feature a of claim 1 includes the word "comprising" at its end. Consequently, features b to h3 specify only a subset of all features of a "digital workbench" according to feature a of claim 1. Already for this reason, in the feature mapping for claim 1, not all of the components of the system according to Figure 1 of D1 have to meet the limitations regarding modules specified by claim 1.

3.6.4 Regarding feature g1 the examining division argued that document D1 disclosed in paragraphs [28] and [50] that material costs could be updated both on the server 40 and third-party server. The appellant did not contest that a user updated costs in the cost module on server 40 but argued that D1 did not disclose that a user updated the costs in the third-party server.

The board agrees that paragraph [50] of document D1 does not explicitly disclose that a user updates the cost information in the third-party server. However, in its communication, the board argued that this was implicitly disclosed in paragraphs [39] and [50] of D1 since the skilled person understood that construction project management utilities supported user updates of material and labour costs, for example. The appellant disputed this since there was no evidence and the board does not insist that this aspect is implicitly disclosed in document D1. Consequently, the board accepts that feature g1 is new.

3.6.5 Regarding feature h2, the board considers that D1 discloses in paragraph [50] that the material costs are updated on server 40 after they have been updated on the third-party server (but in response to a "pull" of the update by server 40, i.e. not in response to a "pushed" change notification originating from server 60). Consequently, document D1 discloses feature h2.

3.6.6 Regarding feature h3, document D1 discloses automatically updating cost estimates based on the updated material costs, for example, after pulling material cost information from the third-party server (see D1, abstract and paragraphs [44] and [50]). It follows that feature h3 is disclosed in document D1. The board also notes that this feature is merely one of two alternatives (feature h2 being the other alternative). Already for this reason, feature h3 is not a distinguishing feature.

3.7 In view of the above, the board concludes that the subject-matter of claim 1 differs from the disclosure of document D1 in features d, g1, g2 and h1.

3.8 Regarding the effect of the distinguishing features, the board does not accept the appellant's alleged effect of "improved efficiency and reliability, thereby avoiding user frustration". This alleged effect is based on the assumption that the claimed subject-matter would enable reliable and consistent updating of the same entity at the same time by different modules (see page 4, lines 22 to 23 of the description). However, as discussed at the oral proceedings and below, claim 1 does not specify any features which achieve that simultaneous updates of the same entity are made in a reliable and consistent manner. Consequently, the alleged effect is not achieved over the whole scope of the claim as required by decision G 1/19, points 82 to 84 and 95.

For example, consider the following scenario encompassed by claim 1: entity A (having the value 30) is stored in two document stores DS1 and DS2 of two modules M1 and M2. Module M1 updates entity A by updating the value of A1 to 40 and, at about the same time, module M2 updates the value of A2 to 50. Change notifications could then be triggered to change the value of A1 to 50 and the value of A2 to 40. The result is then an inconsistent state of the data of entity A, which has the values 40 and 50 at the same time in its two copies A1 and A2.

Furthermore, claim 1 encompasses that feature h2 is one of two alternatives, which means that claim 1 encompasses a workbench in which entity data corresponding to an entity changed by a user in one module is not updated in "respective other modules" (in the above example this would mean that entity A1 is updated by module M1 to 40 and entity A2 by module M2 to 50 without any subsequent updates by the system in response to a change notification to entity A1 or entity A2). Obviously, not updating corresponding entity data in "respective other modules" has also the consequence of inconsistent entity states.

At the oral proceedings, in view of the board's arguments, the appellant conceded that claim 1 does not specify how the updates are made in feature h2 or how data consistency is achieved.

In view of the above, the board does not see that the alleged technical effect is achieved over the whole scope of the claim by the distinguishing features d, g1, g2 and h1.

This conclusion would equally apply if all distinguishing features alleged by the appellant (i.e. features d, g1, g2 and h1 to h3) had been accepted as distinguishing features over document D1. In particular, the claimed subject-matter does not improve, over the whole scope of the claim, efficiency or reliability in the context of consistent updating of entity data by multiple users. Consequently, the claimed subject-matter does also not avoid user frustration over the whole scope of the claim, but rather encompasses achieving increased user frustration due to inconsistent and/or incorrect data.

3.9 Since the distinguishing features in combination do not achieve the alleged effect, the board assesses in the following whether the distinguishing features contribute to any technical effect since distinguishing features which do not contribute to a technical effect do not enter into the assessment of inventive step (see decision T 154/04, Reasons 5).

3.9.1 Regarding feature d, the decision under appeal already noted that document D1 discloses in paragraphs [0028] to [0032] that users can have privileges to access multiple modules. Feature d of claim 1 limits the access to one module only. Access restrictions may play a role in a scheme for maintaining data consistency. However, that is not the case in the workbench of claim 1 since two users may have access to the same entity and, as the above example illustrates, data consistency between two copies of an entity may not be guaranteed. Since document D1 already discloses using access privileges, the distinguishing feature d merely implements a different access policy. An access or security policy corresponds to a non-technical requirement, since access restrictions to one or more resources for users are in general set up for non-technical reasons (see e.g. decisions T 1195/09, Reasons 5.3; T 398/10, Reasons 9.3 and 9.4; T 1073/15, Reasons 6; T 1847/18, Reasons 6).

It is not derivable from claim 1 that the access restriction specified in feature d interacts with the further features of claim 1 to achieve any technical effect over the whole scope of the claim. Feature d of claim 1 specifies that a user has access to only one out of several modules. However, claim 1 encompasses that all entity data might be stored on and accessible via the module to which the user has access. Furthermore, features g1 to h3 of claim 1 encompass that a user who has access to only one module can update indirectly (via the change notifications) entity data stored in the document stores comprised in other modules. In other words, the access restriction by feature d does not restrict the user regarding the updating of entity data. Consequently, the appellant's argument that by confining each user's access to a single module, "the system effectively partitioned the editing workspace per user" is not convincing.

Since claim 1 is entirely silent on any relationship between a user's specialisation and the accessible module, the appellant's arguments based on such a relationship have no basis in the wording of claim 1.

In view of the above discussion, distinguishing feature d does not achieve or contribute to any technical effect over the whole scope of the claim in view of document D1.

3.9.2 The appellant cited decisions T 1561/07 and T 2238/12 and argued that these decisions supported a different view regarding the technicality of feature d.

However, as explained below, the board does not consider that these decisions deal with a factual situation that is comparable to the present case. Already for this reason the two cited decisions are not relevant to the case at hand.

Decision T 1561/07 explains in points 7 to 7.2 of its reasons that " [...] the use of these usage rights to grant or deny the device access to a document stored on the repository depending on selections made by the user has the technical effect that documents may or may not be transmitted and, as a consequence, will or will not be available for access at the device. [...] The board therefore is of the opinion that the claimed invention in comparison with D3 solves, at least partially, the technical problem of controlling document access in conformity with associated usage rights. [...] D3 neither mentions usage rights nor suggests their relevance, let alone any technical support towards enforcing them [...]"

As explained above, in the case at hand the access restriction according to feature d does not necessarily (over the whole scope of the claim) restrict the access to data, but only to modules and an access restriction to modules via user privileges is already known from the closest prior art D1.

Decision T 2238/12 states in point 3.5 the following: "The technical effect of these distinguishing features can, therefore, be identified as allowing the tutor (workstation) to control remotely the access (browsing activity) of the student workstation to the (worldwide) web in order to improve the concentration of the students and their participation at the teaching session."

The factual context of the technical effect accepted by decision T 2238/12 is very different to the case at hand: it concerned the remote control of the data that a user of a different software system/browser can access over the internet.

3.9.3 Regarding feature g1 the board considers that allowing a user to update a data item was notoriously known at the filing date and cannot be the basis for acknowledging an inventive step. It was a commonplace option and thus straightforward to enable a user to input updated cost values, for example, in the third-party server 60.

The board does not see that the specific distinction of feature g1 over document D1 that the update of an entity is performed by a user (and not by the computer, for example) achieves any synergistic effect with the further distinguishing features or achieves, when considered in isolation, any technical effect beyond the use of a general-purpose computer (which enables a user to change stored data).

3.9.4 Features g2 and h1 change the communication scheme for update propagation from "pull" to "push". As already stated in point 13.1 on page 8 of the decision under appeal a "push" communication scheme was a well-known alternative to the "pull" communication scheme disclosed in D1 with known advantages and disadvantages. The appellant did not contest the examining division's view that push communication schemes were well-known and the board agrees. Consequently, the board concludes that the skilled person would arrive at features g2 and h1 as an obvious implementation option without exercising any inventive skill.

The appellant argued that changing between "pull" and "push" schemes was not a mere choice between alternatives. Firstly, a change notification was sent when a change was made, i.e. whenever a change was made and immediately. Compared to a pull-based approach, no delays were introduced and it led to a more synchronous state across the distributed system. Secondly, there was no indication in D1 that change notifications were sent from the server 40 to the third party application server 60 when changes are made in the server 40. In the invention, this made it possible for users in both the first module and the second module to receive changes from the other users in the other modules.

The board considers that the broad wording of feature g2 is not limited to a symmetric functioning of the system in the sense that for all entities and all modules an update of an entity triggers change notifications as argued by the appellant.

In any event, this question is irrelevant for the outcome of the inventive step assessment since no technical effect is achieved over the whole scope of the claim in view of the consistency problem discussed above even when considering the distinguishing features alleged by the appellant and the alleged symmetric change propagation. Which changes should be notified to which modules is merely a non-technical user requirement as no technical effect is achieved over the whole scope of the claim (since no consistent updating of entity data is achieved as discussed above).

In the context of the case at hand, the board also doubts that any technical effect relating to the use of a push instead of a pull communication scheme can be derived from the wording of claim 1. As stated above, document D1 already discloses that the server 40 requests to send or receive information to or from a specific third party application device 60, i.e. bi-directional communication between computers 40 and 60.

Since the change notifications in claim 1 do not achieve any technical effect regarding the consistent updating of entity data over the whole scope of the claim, the notifications do not achieve any technical effect over the communication between devices already disclosed in document D1.

3.10 It follows from the above that the subject-matter of claim 1 of the main request is obvious when starting from document D1 (Article 56 EPC).

Auxiliary requests A1 to A5

4. Claim 1 of auxiliary requests A1 to A5 additionally recites the following features when compared with claim 1 of the main request (itemisation of the features has been added by the board):

(i) wherein the digital workbench (WB) comprises a central operational data store (ODS), wherein the system is configured such that the central operational data store (ODS) is kept continuously up to date to a pre-defined level by tracking changes in the document stores (DS1, DS2, ...) of the two or more modules (M1, M2, ...);

wherein not each change is tracked in the central operational data store (ODS)[auxiliary requests A1 to A5];

(ii) wherein the digital workbench (WB) is configured such that the same entity (A1, A2, ...) can be updated at the same time in different modules (M1, M2, ...)

[auxiliary requests A2 to A5];

(iii) wherein the updating is dealt with by each module based on the change notifications and change handling rules that are customized to the respective module [auxiliary requests A3 to A5];

(iv) wherein changing an entity means that a value is set for an entity [auxiliary requests A4 and A5];

(v) the "and/or" at the end of feature h2 has been limited to "and" [auxiliary request A5].

5. Admissibility of auxiliary requests A1 to A5

5.1 With its statement of grounds of appeal, the appellant filed its auxiliary requests A1 to A5 for the first time. Contrary to the requirements of Article 12(4) RPBA, second paragraph, it did not submit specific arguments for submitting these auxiliary requests only in the appeal proceedings.

The appellant argued that auxiliary request A1 was drafted to overcome the objections under Articles 84 and 56 EPC in points 16 and 17 of the decision under appeal against its former auxiliary request 2 (statement of grounds of appeal, page 10). The central operational data store provided a "snapshot" by keeping track of "important" changes.

The appellant submitted that it added a feature from former auxiliary request 5 to auxiliary request A2 (statement of grounds of appeal, page 12).

Furthermore, auxiliary requests A3 to A5 added features that had not been in any claim request during the first-instance proceedings. Auxiliary request A3 was an attempt to address an objection raised by the examining division in the oral proceedings (point 33 of the minutes) and auxiliary request A4 addressed the reasoning in point 13.1 of the decision under appeal.

The amendment made in auxiliary request A5 was admissible because the wording "had been always part of the claim".

5.2 In its reply to the board's communication and at the oral proceedings, the appellant argued that auxiliary requests A1 to A5 should be admitted for the following reasons.

On 7 September 2023, the examining division had issued a brief communication raising new objections for the main request and the auxiliary requests, thereby citing two new documents D5 and D6. This brief communication was received by the applicant only on the day of the oral proceedings on 13 September 2023 (see paragraph 4 of the minutes). The applicant did not have time to review the new documents to respond to the new objections concerning the auxiliary requests. In view of this situation, it was agreed on that the examining division's decision would not be based on documents D5 and D6 (see paragraph 57 of the minutes).

Therefore, the evidence and arguments used for objecting to auxiliary requests 1 to 5 in the brief communication of 7 September 2023 were different to the evidence and arguments used to reject these requests in the decision under appeal. The auxiliary requests 1 to 5 were therefore deemed to be direct responses to objections raised for the first time in the decision under appeal.

The feature regarding the presence of a central operational data store in the digital workbench that is kept continuously up to date to a pre-defined level had been added to auxiliary request A1 submitted with the statement of grounds of appeal dated 22 January 2024. This feature had already been present in auxiliary request 2 submitted during the examination proceedings. In the decision under appeal, a clarity objection regarding this feature had been raised for the first time in the examination proceedings.

The feature additionally added in auxiliary request A1 "wherein not each change is tracked in the central operational data store" had been added to overcome this clarity objection in the decision under appeal. In the appellant's opinion, this feature merely explicitly stated what was already implicit in the phrase "kept continuously up to date to a pre-defined level". Therefore, auxiliary request A1 in appeal corresponded essentially to what was auxiliary request 2 in examination. Auxiliary request A1 was therefore directed to an objection on which the decision under

appeal was based (Article 12(2) RPBA).

5.3 The board is not convinced that the appellant's arguments provide a convincing justification for filing auxiliary requests A1 to A5 only in the appeal proceedings.

5.4 According to Article 12(6) RPBA, the board shall not admit requests which should have been submitted in the proceedings leading to the decision under appeal, unless the circumstances of the appeal case justify their admittance.

5.4.1 The auxiliary requests A1 to A5 add to claim 1 of the main request, for the first time, the feature "wherein not each change is tracked in the central operational data store (ODS)". This feature is based on the description (page 5, lines 20 and 21). According to the appellant, this amendment was a reaction to the allegedly new clarity objection against auxiliary request 2 in point 16 of the decision under appeal against the wording "wherein the digital workbench (WB) comprises a central operational data store (ODS), wherein the system is configured such that the central operational data store (ODS) is kept continuously up to date to a pre-defined level by tracking changes in the document stores (DS1 , DS2 , ...) of the two or more modules (M1 , M2 , ...);".

However, this clarity objection was already stated in point 5 of the examining division's communication dated 7 September 2023 and seems to have been merely copied into point 16 of the decision under appeal. Even if the appellant received this communication only shortly before the oral proceedings, it was informed about this objection before the oral proceedings were held. According to point 4 of the minutes, the representative had read the examining division's communication before the oral proceedings and considered himself to be sufficiently prepared for the oral proceedings.

Furthermore, the appellant did not wish to discuss auxiliary requests 1 to 5 in the oral proceedings before the examining division provided that the newly introduced documents D5 and D6 were not used in the decision under appeal.

Since the appellant chose not to make any substantive submissions in the oral proceedings regarding auxiliary requests 1 to 5, the examining division refused auxiliary request 2 under Articles 56 and 84 EPC. The appellant was therefore not surprised by the examining division's clarity objection and did also not argue that this was the case. Rather, it decided to waive the opportunity, in the oral proceedings during the first-instance proceedings, to be heard on the examining division's clarity objection and to react to this objection which was then upheld by the examining division in its decision (see points 53 to 58 of the minutes of the examining division).

Consequently, the appellant's amendments in auxiliary requests A1 to A5 are not a reaction to any objection raised for the first time in the contested decision. Rather, the appellant could and should have filed its new auxiliary requests already in the first-instance proceedings. No circumstances of the appeal case are apparent which could justify admitting auxiliary requests A1 to A5 (Article 12(6) RPBA).

5.5 Moreover, auxiliary requests A1 to A5 raise fresh issues. For example, the board preliminarily objected in its communication that the wording "wherein not each change is tracked in the central operational data store (ODS)" which has been added to all auxiliary requests filed with the statement of grounds of appeal was vague and did not clarify the meaning of the wording that the ODS "is kept continuously up to date to a pre-defined level".

That amendment made in auxiliary requests A1 to A5 therefore also raises fresh issues. Consequently, the admission of these auxiliary requests would also be against the need for procedural economy. This constitutes a further reason for not admitting the new requests (Article 12(4) RPBA).

5.6 The board remarks that it does not consider that the above-discussed amendment ("wherein not each change is tracked in the central operational data store (ODS)") was suitable to address the examining division's clarity objection (Article 12(4) RPBA). The amendment does not address the core of this objection, namely that the claim does not specify any use of the up-to-date data in the operational data store.

On page 10 of its statement of grounds of appeal the appellant argued that the purpose of the operational data store was clear from the description: it allowed to obtain a snapshot view of the most critical data, since only the most important changes were tracked. That means that the appellant relied on the description of the application as filed to overcome the clarity objection. But reacting to the clarity objection that claim 1 did not specify any use of the operational data store by referring to the description is in the board's opinion not suitable to address the clarity objection in the case at hand.

5.7 The board also remarks that none of the amendments made in the further auxiliary requests A2 to A5 addresses the clarity objection of point 16 of the decision under appeal.

5.8 The board also remarks that none of the amendments made in auxiliary requests A1 to A5 is prima facie suitable to overcome the issue of inconsistent updating, which is crucial for the inventive-step objection against the main request. For example, the fact that, according to auxiliary request A3, the updating is dealt with by each module based on change handling rules that are customized to the respective module does not provide any consistency for the updated entity data. These change handling rules are not further specified in claim 1 so that it is not derivable what their effect on data consistency is over the whole scope of the claim.

5.9 In view of the above, auxiliary requests A1 to A5 are not admitted under Article 12(4) and (6) RPBA.

Conclusion

6. Since the sole request admitted into the appeal proceedings is not allowable, the appeal is to be dismissed.

Order

For these reasons it is decided that:

The appeal is dismissed.