T 1628/11 (Distributing master data objects/SAP) of 27.3.2014

Summary of Facts and Submissions

I. Euro-PCT application number 03 794 019.4 published as WO 2004/023338 A2 claims priority dates from national filings in 2002 and 2003 related to sharing and distributing data in a data management system.

II. The examining division refused the application, for the first time, for lack of clarity of the claims and, after a successful appeal (T 2245/08) of the applicant and remittal of the case to the examining division, a second time, then essentially for lack of inventive step in the claims 1 of all three sets of claims filed as main request and as auxiliary requests I and II, respectively.

III. Claim 1 of the main request was worded as follows (brackets ¹<> etc. added for convenience of reference):

"A method of distributing data in a data management system (cMDM)¹<, comprising>:

specifying identification attributes for master data objects and ²<establishing rules for matching the master data objects,> ³<identifying one or more objects in a central data store for distribution, the one or more objects including the master data objects for use by all systems in a data management system (cMDM);>

determining if a routing exists for at least one object of the one or more objects, wherein, if a routing exists for the at least one object, the routing determines one or more target systems to which to supply the at least one **(4)<object,> and if no routing exists, the step of identifying one or more objects in the central data store for distribution is repeated;

distributing the at least one object to one or more target systems specified by the routing based on a distribution profile for the at least one object, the one or more target systems being part of the data management system (cMDM),

wherein the distribution profile includes criteria for distributing the object to a target system, what part of the master data object is to be distributed, and the context in which the master data object should be distributed, **(5)<>

wherein data are distributed as packets or as individual mater (sic) data objects,

wherein objects that are related or have interdependencies are distributed as a packet data periodically, and

wherein individual master data objects are distributed immediately."

In both auxiliary requests, passage ¹<...> in claim 1 above reads as follows: "comprising a central module (100) and one or more client modules (110) each client module (110) being linked directly to the central module (100), the central module (100) including a central system representing a centralized control of data management for an entity, and the client modules (110) including systems or groups performing processes on master data, and wherein the central module (100) allows master data used by each client (110) to include master data that is shared by all clients (110), the method compromising"

In auxiliary request I, passage ²<...> above was amended and passage ³<...> deleted. Passage ²<...> as amended reads as follows:

"establishing rules for matching and mapping the master data objects, wherein in the matching step identical or similar objects are identified and are mapped to each other,

wherein identical data objects are master data objects that are semantically identical, and which are received from different client modules (110), the matching step further including comparing the identification attributes of the master data objects, and

wherein master data objects can be created in the central module (100) or in the client modules (110), wherein portions of the master data objects and mappings between master data objects are stored in the central module (100), the portions including global attributes of the master objects, the global attributes including the identifying attributes,".

In auxiliary request II, passage **(4)<...> above reads "object; wherein the target system is determined based on subscription routing, historic routing, or rule-based routing,"; at passage **(5)<...>, a piece of text was inserted which reads as follows (brackets **(6)<> and **(7)<> added for convenience of reference):

"publishing one or more of the identified objects, the one or more published objects available for subscription by a client system; and

assigning the distribution profile based on **(6)<historic routing, rule-based routing or> subscription routing, wherein

**(7)<if assignment is based on historic routing, all client modules (110) which are already target systems for a published object or have a replicate of the published object are assigned to be target systems for the published object to receive changes to the published object, and

if assignment is based on rule-based routing, target systems are determined based on the content of the master data object,and

if assignment is based on subscription routing,> a client module (110) is assigned to a published object based on a subscription for the published object received from the client module (110),".

IV. The examining division cited document D1 (US 6 226 650 B1 published in 2001) as well as the common general knowledge as closest prior art. The common general knowledge was said to be exemplified by what had been described in prior art document D1 as the "traditional approach" for synchronising the server and client databases of an ICDB (Intermittently Connected Database) computer system.

According to the examining division, "the difference between D1 and claim 1", cited in another passage of the decision as "the features of claim 1 not known from the common general knowledge", was either non-technical or, if technical, obvious for solving the problem of reducing network load. No synergistic effect was found in the combination of the features. Essentially the same reasons were given for refusing the auxiliary requests.

V. The appellant (applicant) lodged an appeal against the decision and filed the grounds of appeal including three sets of claims filed as main request and auxiliary requests I and II, respectively.

The independent claims 1 of these three requests correspond identically with the respective claim 1 already considered by the examining division in the decision under appeal, except for an amendment in claim 1 of auxiliary request II, in which the text passages indicated above by brackets **(6)<...> and **(7)<...> have been deleted.

VI. In a communication annexed to a summons to oral proceedings, the Board indicated that in its preliminary view the invention failed to meet the requirement of inventive step in the light of document D1.

VII. In reply, the appellant filed a new auxiliary set of claims for preparation of the oral proceedings and made observations discussing novelty and inventive step in the light of the "data centric approach" disclosed in document D1 as an improved method of database synchronisation.

VIII. In the oral proceedings held on 27 March 2014, the matter in issue was discussed with the appellant. The appellant withdrew the auxiliary request filed in preparation of the oral proceedings and requested that the decision under appeal be set aside and that a patent be granted on the basis of the claims of the main request or on the basis of auxiliary requests I or II as submitted with the statement setting out the grounds of appeal.

IX. In support of its requests, the appellant submitted that the invention provided an inventive solution to the technical problem of managing and distributing master data in a distributed master data management system centrally and in a consistent and flexible manner, avoiding the duplication of master data and removing any existing duplicates. In contradistinction to the present invention, the traditional data-centric approach was closely tied to an intermittently connected database system and required the definition of static groups of data to which the clients had to subscribe in advance. Only modification files to which a client had subscribed were downloaded on request in an inflexible periodical update process.

The invention achieved data synchronisation in a more efficient and consistent manner, allowing the master data to be shared by all clients under central control of the central module. To this end, the invention used specific distribution profiles defining the parts of the master data object to be distributed and the context in which a distribution should take place. Data that was related or interdependent could be distributed together as data packets, which further improved the efficiency of the distribution process.

Auxiliary request I further specified the matching and mapping procedure for ensuring data consistency by recognising similarity between master data objects on the basis of global attributes of the data objects.

Auxiliary request II defined the assignment of the distribution profile on the basis of subscription routing. This feature provided in a synergistic manner for an even better data consistency and more flexibility since the clients could flexibly register themselves as distribution targets for specific data objects.

A data management system using such a consistent and flexible method of data distribution was clearly novel and inventive over the cited prior art.

Reasons for the Decision

1. The admissible appeal is not allowable since the objections of lack of inventive step raised in the decision under appeal are not unfounded and remain valid for claim 1 according to all three present requests.

2. Document D1 has already been cited by the examining division in combination with the common general knowledge as the most relevant piece of prior art. There were no objections raised against those findings; the appellant itself cited document D1 as relevant prior art in its submissions on inventive step. The available facts and arguments on file do not justify a different assessment or a general reconsideration of the prior art; accordingly, document D1 is used as closest prior art in the following reasoning.

3. As a preliminary point, it is noted that the claims under consideration are directed to a method of distributing data "in a data management system (cMDM)". This system is described in the present application essentially as a distributed client-server network and computing system (see WO-publication e.g. figures 1, 2 and 8 with page 15, line 24 ff., page 17, line 6 ff., page 18, line 1 ff., and page 22, line 23 ff.). It is appropriate first to compare this data management system (all requests) with that described in document D1.

4. Document D1 discloses a data management system for implementing a database synchronisation method (ICDB, see e.g. D1, figure 1). In the terminology of the present claims, the data management system of document D1 comprises a central module and a central data store (computer server 18 with database 15D) as well as one or more client modules (16A, ...), each client module being linked directly to the central module (Internet, LAN or WAN 26, or via a telephone line, see D1, column 3, line 44 ff.). Since the central module (server 18 and server database 15D) communicates with all clients and manages the update process for the data shared between individual clients (by organising data, tracking changes etc.) it can be said to be "representing a centralized control of data management" as required by the present claims.

5. Taking a closer look at the present claim wording it is noticed that different terms - data, object, master data, and master data object - are used. Only the terms "master data objects" and "master data" are more specifically defined: according to the main request, "master data objects" are included in the objects identified for distribution "for use by all systems in a data management system" and, according to the auxiliary requests, "master data used by each client (is allowed) to include master data that is shared by all clients" (cf. T 2245/08, point 4.1). Another point to consider is that distributed data may represent an entire master data object as well as changes to an object (see e.g. WO-publication page 6, line 19 ff., page 12, line 21 ff., page 14, line 19 f., page 15, line 19 ff., page 17, line 24 ff.).

6. Referring again to the prior art system of document D1, the data stored and processed by the central module comprises data potentially or actually shared by all clients (see for example the data group ALL-ENROLL 218 in D1, figures 3B and 3C) or by a group of clients (see for example the data group GRADUATE-STUDENTS 206) and hence includes master data in terms of the present claims. Indeed, the data (e.g. GRADUATE-STUDENTS) used and shared by a client group (e.g. GRADUATE) may include master data (e.g. STUDENTID) that is shared by all clients (via ALL DATA, see figures 3B and 3C).

It follows that a data management system with the claimed computing components is known from document D1.

7. However, there may be a "hidden" difference between the two systems: the central server in document D1 is an intermediary element whose main purpose is to facilitate inter-client communication and data sharing between independent client databases. Accordingly, its primary task is to provide update information to the individual client databases. The present application is more generally directed to a centralised data management providing data and updates through the central module. The central module stores and controls the master data information centrally; it may itself create master data and manage changes to master data (see for example WO-publication, page 5, line 14 ff. or page 14, line 1 ff.). These differences in the system structure and functionality do not find a clear expression in the present claims; nevertheless, they will in the following be taken into account in construing the claims.

8. Turning now to the steps of the method as defined in claim 1 of the main request, it is immediately apparent that they can be divided into four independent groups. These groups may be summarised as follows:

A. Merging data from different clients: Identification attributes for (master data) objects are specified and rules for matching the objects are established.

B. Distributing data to clients: In a processing loop, objects are identified for distribution and if a routing determining one or more target clients exists the object is distributed to those clients.

C. Determining the routing: The routing is based on a distribution profile for the respective object. The distribution profile includes criteria for distributing the object to a target system, what part of the object is to be distributed, and the context in which the object should be distributed.

D. Frequency of data distribution: Related objects are distributed as packet data periodically, individual objects immediately.

In the light of the prior art document D1, none of these features provides an inventive contribution over the prior art, for the following reasons.

9. Regarding group A above, it is noted that the technical effect to be achieved by providing identification attributes and matching rules is not apparent from a first look at the claims; it becomes more clear only from the description of the invention: the purpose of the identification of a matching process is to find and remove duplicate objects on the one hand and to provide mapping information about similar or identical objects, i.e. a mapping function or table indicating the IDs of the corresponding objects, on the other hand (see e.g. page 8, line 11 ff. and page 9, line 1 ff.).

Identifying and removing duplicates from a database improves data integrity. In the field of database management this is a common procedure. In document D1 duplicate removal is suggested under the heading "data filtering" for data stored in the client databases (see D1, column 8, line 46 ff.; column 9, line 23 ff.). Clearly, the data filtering process is based on predefined data attributes (graduate, undergraduate, etc.) and matching rules (having identical student IDs).

Providing mapping information about similar or identical objects is another common and obvious measure to ensure data integrity in particular in distributed databases and client server systems. An example for the client databases is given in document D1 under the term "schema mapping", which ensures that objects which are semantically identical but differently named are properly matched during updating to ensure data integrity (see D1, column 8, line 58 ff.).

A skilled person would consider it obvious to apply such data filtering techniques not only to the client databases as in document D1, but generally, i.e. in particular to the central module. Hence, the features of group A above do not provide an inventive contribution over the prior art.

10. Regarding group B (see above), it is noted that the central server in document D1 has to identify data groups in central database 15D before they can be distributed to the target clients. In the dynamic grouping mode (see D1, column 7, line 11 ff.) the server processes only data groups associated with clients that are currently connected to the server, i.e. in terms of the present claims only data for which a routing exists. But even in a predefined static grouping mode, it is evident that data distribution requires that routing of data to one or more clients is possible. Browsing through database 15D to identify the appropriate data groups and to decide which to send to the currently connected clients (or which to prepare for distribution), using IF- or IF NOT-branching statements for implementing such decisions, is a common programming technique.

The appellant has argued that according to the invention the data is distributed under centralised control of the central module, whereas in document D1 the data is distributed only on request of a client, which is possible only intermittently when the client is connected to the server. However, claim 1 does not specify which components of the server-client system execute the individual method steps. Moreover, even if the claim were construed in this sense, the only relevant difference would be that between a push and a pull method. Both methods being common techniques in network communications, this difference would not involve an inventive step.

11. Turning to group C (see above), it is first noted that in the prior art system a data group is assigned to one or more client systems (see for example D1, column 2, line 59 ff.).

An example is given by the tables shown in figure 3A ff. They define an assignment of data objects (STUDENTS etc.) to clients (a professor client, a graduate student client etc.). The table in figure 3C determines target clients for the respective data objects and thus provides a distribution profile and basis for the routing of such data objects. The table further identifies which part of a data object is to be distributed (for example, for an undergraduate student client the data parts STUDENTID and NAME but not PHONE).

The flags {UNDERGRAD} and {GRAD} are suitable as criteria for distributing (or not distributing) objects to specific target clients.

Finally, the tables also determine the context in which the respective object is to be distributed. If the data object STUDENTS is sent to a professor client, then the phone number is also included.

In summary, the features of group C are anticipated by the prior art system.

12. Turning now to group D (see above), it is noted that the term "periodically" does not necessarily mean a fixed period or strictly regular interval. It may merely indicate an occasional event recurring or reappearing intermittently. In the prior art system, packets of related data ("groups" of data) are downloaded to a client on request. The download on request will normally take place periodically in the sense of a recurring event.

Clearly, the group of data in document D1 may consist not only of a plurality of data objects but also of a single (individual) data object. The decision regarding the number of data objects to be transmitted in a packet belongs to the normal considerations undertaken by the skilled person and depends on many known factors including network bandwidth (see e.g. D1, column 6, line 50 ff.). There is no inventive aspect involved in such a decision.

The server in the push mode and the client in the pull mode may initiate an immediate download of data, provided that the respective clients are connected to the server. Providing such an immediate action for individual master data objects (but not for related objects) might be a reasonable strategy in case the individual objects contain particularly important information (compare WO-publication, page 17, line 15 ff. mentioning the correction of address data), but does not serve any technical purpose and is thus not a technical contribution to the prior art.

13. In summary, none of the distinguishing features of claim 1 of the main request involves an inventive step. Accordingly, the main request does not meet the requirement of inventive step as set out in Articles 52(1) EPC and 56 EPC 1973.

14. Turning to auxiliary request I, it is first noted that claim 1 defines a more detailed embodiment of the merging and matching features cited in group A above. However, the above considerations apply analogously. The prior art "schema mapping" applies to semantically identical data stored under different names in the local client database and in the central server database (see D1, column 8, line 58 ff.). Storing such cross-system data in a central place is an obvious alternative. The same holds for the identification attributes. The implementation of identification attributes as global attributes is implicit in D1 since the matching and mapping is a system-wide process extending over all ICDB systems including the local clients and the central server.

Accordingly, the additional features in claim 1 of auxiliary request I do not provide an inventive contribution over the prior art.

15. Regarding auxiliary request II, it is noted that the method features added in respect to the main request concern the publication of objects for subscription, and the assigning of the distribution profile on the basis of subscription routing using the subscription for the published objects received from the client modules.

Subscription routing is the mode suggested in document D1 (e.g. column 3, line 10). Publishing objects available for subscription, i.e. giving notice to the clients in some form that an object can be subscribed to, is implicit in subscription routing since otherwise the clients would not know to what data they could subscribe.

It follows that claim 1 of auxiliary request II does not add anything inventive to what has been claimed in the main request.

Order

For these reasons it is decided that:

The appeal is dismissed.