Multi-user Project Handling: Non-technical

Claim 1 (main request)

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)

h3 – 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).

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.9.1 Regarding feature d, .... 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.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.