T 1441/07 (Update of remote data using persistent keys/ACXIOM) of 28.6.2011

Summary of Facts and Submissions

I. The appeal is against the decision by the examining division, posted on 13 April 2007, to refuse European patent application No. 98 935 878.3 because the subject-matter of claim 1 according to the then main request lacked inventive step, Article 56 EPC 1973, in view of the combination of the disclosure of the following document:

D1: Rafi Ahmed et al., "The Pegasus Heterogeneous Multidatabase System", Computer, IEEE Computer Society, Vol. 24, No. 12, 1 December 1991, pages 19 to 26

with common general knowledge as exemplified by the following document:

D3: Ralph Kimball, "The Data Warehouse Toolkit Passage", Data Warehouse Toolkit, 1996, pages 100 to 106, XP002243860.

The claims according to an auxiliary request were not admitted into the proceedings, Rules 71a and 86(3) EPC 1973.

II. The following document was cited during examination proceedings but not relied upon in the appealed decision:

D2: Lim E-P et al., "Entity Identification In Database Integration", Proceedings of the International Conference on Data Engineering. Vienna, April 19 to 23, 1993, Los Alamitos, IEEE Comp. Soc. Press, US, Vol. Conf. 9, 19 April 1993, XP 0010095513.

III. A notice of appeal was received on 13 June 2007, the appeal fee being paid on the same day.

IV. With a statement of grounds of appeal, received on 15 August 2007, the appellant filed claims according to first and second auxiliary requests. As a main request, the appellant requested that a patent be granted on the basis of the claims according to the main request forming the basis of the decision. As first and second auxiliary requests, the appellant requested grant of a patent on the basis of the claims filed with the statement of grounds of appeal according to the first and second auxiliary requests. The appellant also requested oral proceedings if the board considered rejecting the appeal.

V. In an annex to a summons to oral proceedings the board raised objections under Articles 83 EPC 1973 (sufficiency of disclosure), 84 EPC 1973 (clarity), 123(2) EPC (added subject-matter) and 56 EPC 1973 (inventive step).

VI. With a letter dated 30 May 2011, and received on the same day, the appellant filed amended claims according to new main and first and second auxiliary requests. The appellant stated that, on condition that the amended claims were deemed admissible, the appellant requested that the new requests replace the previous ones. The appellant also requested that the appeal be allowed based on the main or the first or second auxiliary request. If the board was minded to reject the appeal then the appellant requested oral proceedings.

VII. In the oral proceedings held on 28 June 2011 the appellant 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 the claims of one of the auxiliary requests 1 or 2, all filed with the letter dated 30 May 2011. At the end of the oral proceedings the board announced its decision.

VIII. Claim 1 according to the main request filed with the letter dated 30 May 2011 reads as follows:

"A system for the creation, enhancement, and update of data stored at a remote location using data stored at a central location comprising:

(a) a central database (224) at a central location comprising:

(i) a plurality of records, each comprising a plurality of records fields, and

(ii) a plurality of persistent keys, the number of said plurality of persistent keys and said plurality of records being equal, each of said plurality of persistent keys being linked to one of said plurality of records, and being distinguishable from each other;

(b) a customer database (210) at a remote location comprising a plurality of customer records, each comprising a plurality of customer records fields, and each of said plurality of customer records comprising data relevant to the same entity as one of said plurality of records stored at said central database (224) the customer database (210) including a persistent key linked to each customer record, the persistent key corresponding to the said persistent key linked to the record of the same entity in the central database (224); and

(c) a bi-directional transfer means communicatively connecting said central database (224) and said customer database (210)

wherein each of said plurality of persistent keys comprises:

(a) an entity code (512), said entity code (512) denoting the type of data stored in that record on said central database (224) linked to said persistent key comprising said entity code (512);

(b) a unique number (514);

(c) a version number (516), said version number (516) incrementable each time any of said fields of said record on said central database (224) linked to said persistent key comprising said version number (516) is modified; and

(d) a check digit (518) manipulable to check that said persistent key comprising said check digit originated from said central database (224);

wherein the persistent key of the customer record corresponding to the persistent key of the same entity in the central database by having the same entity code and unique number, the system being arranged to identify differences between records of the customer database (210) and those of the central database linked by a persistent key having the same entity code (512) and unique number but different version number (516)."

The claims according to this request also comprise an independent method claim 22.

IX. Claim 1 according to the first auxiliary request filed with the letter dated 30 May 2011 reads as follows, additions with respect to claim 1 of the main request being indicated in bold and deletions being [deleted: struck through ]:

"A system for the creation, enhancement, and update of data stored at a remote location using data stored at a central location comprising:

(a) a central database (224) at a central location comprising:

(i) a plurality of records, each comprising a plurality of records fields, and

(ii) a plurality of persistent keys, the number of said plurality of persistent keys and said plurality of records being equal, each of said plurality of persistent keys being linked to one of said plurality of records, and being distinguishable from each other;

wherein said central database (224) comprises:

a central database manager (220);

a plurality of linked physical databases; and

a plurality of partial records resident on said plurality of linked physical databases, said partial records combinable to form the plurality of records resident on said central database (224), and corresponding persistent keys being linked to each of said partial records that are combinable to form a single record resident on said central database (224);

(b) a customer database (210) at a remote location comprising a plurality of customer records, each comprising a plurality of customer records fields, and each of said plurality of customer records comprising data relevant to the same entity as one of said plurality of records stored at said central database (224) the customer database (210) including a persistent key linked to each customer record, the persistent key corresponding to the said persistent key linked to the record of the same entity in the central database (224); and

(c) a bi-directional transfer means communicatively connecting said central database (224) and said customer database (210)

wherein each of said plurality of persistent keys comprises:

(a) an entity code (512), said entity code (512) denoting the type of data stored in that record on said central database (224) linked to said persistent key comprising said entity code (512);

(b) a unique number (514);

(c) a version number (516), said version number (516) incrementable each time any of said fields of said record on said central database (224) linked to said persistent key comprising said version number (516) is modified; and

(d) a check digit (518) manipulable to check that said persistent key comprising said check digit originated from said central database (224);

wherein the persistent key of the customer record corresponding to the persistent key of the same entity in the central database by having the same [deleted: entity code and ]unique number, the system being arranged to identify differences between records of the customer database (210) and those of the central database linked by a persistent key having the same [deleted: entity code (512) and ]unique number but different version number (516), said central database manager (220) is arranged to:

receive, in a first batch mode procedure, a persistent key of interest and a request for certain data associated with said persistent key of interest are received from a customer server (214); compare, in a second batch mode procedure, said unique number in said persistent key of interest and the persistent key linked to each of said partial records to determine if each of said linked physical databases contains data associated with said persistent key of interest, and, if a match is found, return said data from said partial record to said central database (224) manager; compile data, in a third batch mode procedure, from each of said matched partial records resident on said linked physical databases to form a full record linked to said persistent key of interest comprising said requested data; and compile all said full records and send that portion of said full records to said customer database (210) that was the subject of said customer server (214) request."

The claims according to this request also comprise an independent method claim 20.

X. Editorial amendments aside, the text of claim 1 according to the second auxiliary request filed with the letter dated 30 May 2011 is the same as that of claim 1 of the first auxiliary request except that the following passage has been added at the end:

", wherein the central database manager (220) is arranged only to return said data from said partial record to said central database manager (220) if said version number (516) on said persistent key of interest does not match said version number (516) on the persistent key linked to said partial record."

The claims according to this request also comprise an independent method claim 19.

Reasons for the Decision

1. Admissibility of the appeal

In view of the facts set out at points I, III and IV above, the appeal is admissible.

2. The admittance of the requests received with the letter dated 30 May 2011 into the procedure

2.1 The main and first and second auxiliary requests comprising amended claims filed with the letter dated 30 May 2011 constitute an amendment to the appellant's case after it had filed its grounds of appeal and thus, under Article 13(1) RPBA (Rules of Procedure of the Boards of Appeal, OJ EPO 2007, 536), may be admitted and considered at the board's discretion. The discretion shall be exercised in view of inter alia the complexity of the new subject-matter submitted, the current state of the proceedings and the need for procedural economy. Amendments sought to be made after oral proceedings have been arranged shall, under Article 13(3) RPBA, not be admitted if they raise issues which the board cannot readily be expected to deal with without adjournment of the oral proceedings.

2.2 In the present case, the amendments largely overcame the board's objections under Articles 84 EPC 1973 (clarity) and 123(2) EPC (added subject-matter). Moreover the amendments in substance made only minor changes to the subject-matter set out in the claims, so that the effect of the amendments could be readily assessed by the board and certainly did not require the adjournment of the oral proceedings. The board consequently admitted the new main and first and second auxiliary requests comprising amended claims filed with the letter dated 30 May 2011 into the procedure. It follows that these requests replace the main and first and second auxiliary requests previously on file, as requested by the appellant.

3. The context of the invention

3.1 The application relates to the transfer of data between a central database and a remote customer database. Several types of transfer are possible: the creation of a new customer database from scratch, the enhancement of an existing customer database with additional data from the central database and the updating of the customer database using data from the central database. Data relating to the same "entity", in other words the same individual, in the central and customer databases is linked using corresponding "persistent keys" having the same "unique number". An example of the structure of the persistent keys is shown in figure 5. In addition to a "unique number", a persistent key also comprises an "entity code" identifying the type of data relating to the individual, for instance an address or credit card information; see figure 3. A persistent key also comprises a version number which is incremented every time the data linked to that key is changed. This is used to identify data which must be updated. Furthermore a persistent key has a check digit which performs a security function by ensuring that only users presenting persistent keys originating from the central database are allowed access to the central database.

3.2 Although the central database can be realized as one single database, it can also be realized as a series of physically remote databases managed by a central database manager so as to appear to be a virtual central database to the customer database. Each of the component databases can store different types of data regarding an individual in partial records which are compiled into full records by the database manager.

3.3 Whilst "near real-time" data transfers between the central and customer databases are possible, transfers can also take place according to a batch-mode procedure, meaning that a batch of data requests is sent from the customer database to the central database, possibly via the Internet or on a physical carrier, the appropriate partial records relating to the data requests are identified and full records are compiled and sent as a batch to the customer database.

4. Document D1

4.1 It is common ground between the board and the appellant that D1 forms the closest prior art. D1 concerns the Pegasus heterogeneous multidatabase management system which, in particular, can access and manipulate data in multiple relational databases. The system provides mapping facilities to give the plurality of local data sources (see figure 1) the appearance of a single database which can be queried using a common query language. In other words, the Pegasus system allows information in the different databases relating to the same entity to be linked.

4.2 The interpretation of the section in D1 entitled "object identification" (see pages 23 and 24) is especially relevant to the present decision. According to page 23, right column, lines 15 to 11 from the bottom, object identification in a heterogeneous multidatabase management system is difficult because logically different objects can have the same identifier in different data sources, the usual solution to the collision of object identifiers across multiple data sources being to introduce an independent system of globally unique identifiers that have to be mapped to the local identifiers of each participating local database. According to page 24, left column, lines 6 to 9, "There is, in general, no fully automatic way to deal with this. Therefore, Pegasus allows the user to specify equivalences. The specification of equivalences might be an algorithm that matches social security numbers or a user-constructed table of corresponding object identifiers. Pegasus will attempt to treat equivalent object identifiers as synonyms for the same object." D1 then goes on to describe a problem which occurs where a database lacks a unique local identifier for each object, stating that "Certain local data sources do not provide unique object identification. These sources can be handled ... by introducing user-specified object identifiers. In [this] case, object identifiers are constructed from user-imposed types and key properties, such as student type and student number. ... These problems are being investigated in the Pegasus project."

4.3 The appellant has challenged the statement in the appealed decision (page 5, section (b), second paragraph) that "D1 states on page 23, right col., penultimate paragraph - page 24, right col., first paragraph that Pegasus introduces a system of globally unique identifiers for identifying records that belong to the same entity; the identifiers can be compound keys, e.g. student type = entity type and student number (i.e. a unique number)". The board agrees with the appellant that D1 does not disclose globally unique identifiers in combination with compound keys and also does not disclose the generation of globally unique identifiers for identifying records that belong to the same entity.

4.4 The board also accepts the appellant's argument that D1 does not disclose entity codes denoting the type of data stored, the expression "student type" (see page 20, paragraph bridging left and middle columns) in D1 referring to the stored data, not the stored data type. The application uses the expression "type" in the sense of name and address, driving records, credit information and demographic information, all relating to the same entity; see figure 3, page 18, lines 10 to 14, and the paragraph bridging pages 21 and 22.

5. Document D3

D3 shows that the use of version numbers per se was known at the priority date, albeit in the different context to that of the present application, namely modifying a database to cope with an entity adding a new dimension/parameter, the example in D3 concerning an individual changing marital status. The "Type two" approach, which is mentioned on page 102, second paragraph, and relied upon in the appealed decision, "partitions history" by adding a second instance of the individual with a different version number relating to the new family status.

6. Document D2

6.1 D2 gives examples (see page 295, section 2.2) of the difficulties encountered in linking data in different databases relating to the same entity and refers to the approach taken in D1, stating:

"2. User specified equivalence. This approach requires the user to specify equivalence between object instances, e.g. as a table that maps local object-ids to global object-ids, i.e. the responsibility of matching the object instances is assigned to the user. This technique has been suggested for the Pegasus project [1]. Since the matching table can be very large, this approach can potentially be cumbersome."

6.2 The board understands this passage as confirming its view that D1 does not disclose the generation of globally unique identifiers for identifying records that belong to the same entity.

7. Novelty, Article 54(1,2) EPC 1973

7.1 Main request

7.1.1 In view of the above analysis, the subject-matter of claim 1 differs from the disclosure of D1 in the following features:

i. the persistent key linked to each customer record in the customer database corresponds to the persistent key linked to the record of the same entity in the central database, and

ii. each of the plurality of persistent keys comprises:

(a) an entity code, said entity code denoting the type of data stored in that record on said central database linked to said persistent key comprising said entity code;

(b) a unique number;

(c) a version number, said version number incrementable each time any of said fields of said record on said central database linked to said persistent key comprising said version number is modified and

(d) a check digit manipulable to check that said persistent key comprising said check digit originated from said central database;

wherein the persistent key of the customer record corresponding to the persistent key of the same entity in the central database by having the same entity code and unique number, the system being arranged to identify differences between records of the customer database and those of the central database linked by a persistent key having the same entity code and unique number but different version number.

7.1.2 The appellant has argued that D1 does not disclose a controlling source, central and remote/customer databases, the transferring of data between databases and means for creating, enhancing and updating the data on a customer database using data on a central database. In D1 all data remained in its respective databases, and there was no mention of automated updates. The board is not convinced by these arguments, since claim 1 of the main and first and second auxiliary requests sets out "A system for the creation, enhancement, and update of data stored at a remote location using data stored at a central location" (emphasis added by the board), the board interpreting the term "for" to mean "suitable for". The board takes the view that the means disclosed in D1, in particular in figures 1 and 2, is suitable for creating, transferring, enhancing and updating data in or between the relevant databases. The board regards the descriptors "central" and "remote"/"customer" as applicable to any of the databases in the system known from D1, these terms not being of any limitative effect.

7.2 First auxiliary request

7.2.1 Claim 1 differs from claim 1 according to the main request in the deletion of the entity code as a criterion for correspondence between persistent keys in the central and customer databases and for identifying differences between records in the central and customer databases.

7.2.2 Compared to claim 1 according to the main request, claim 1 of this request further differs from the disclosure of D1 in setting out the central database comprising a central database manager and a plurality of linked physical databases and setting out the steps relating to batch-mode procedures in which a request for data associated with a persistent key of interest is received by the database manager, the database manager comparing persistent keys to identifying partial records associated with the persistent key of interest stored in the linked physical databases, compiling a full record from a number of partial records and sending data corresponding to the request to the customer database.

7.3 Second auxiliary request

The subject-matter of claim 1 further differs from the disclosure of D1 in the central database manager being arranged only to return the data from the partial record to the central database manager if the version number on the persistent key of interest does not match the version number on the persistent key linked to the partial record.

8. Inventive step, Article 56 EPC 1973

8.1 Main request

8.1.1 The difference features between the subject-matter of claim 1 and the disclosure of D1 fall into three unrelated groups. Hence the contribution to inventive step of the three groups will be assessed separately.

8.1.2 Group I: features related to object identification, i.e. the persistent key linked to each customer record in the customer database corresponding to the persistent key linked to the record of the same entity in the central database, wherein each of said plurality of persistent keys comprises an entity code, said entity code denoting the type of data stored in that record on said central database linked to said persistent key comprising said entity code and a unique number.

8.1.3 The objective problem is regarded as avoiding the use of equivalence tables for identifying objects in heterogeneous databases. As D2 states (see page 295, right column, penultimate paragraph, last sentence), at the priority date such mapping was known to be a potentially cumbersome approach.

8.1.4 The skilled person would have found it obvious to solve this problem by designating records that belong together (for example belonging to the same individual) by the same identifier. It follows from this that such an identifier must be unique for each individual, otherwise the identifier could not designate exactly one individual. Using a number for that identifier is also considered obvious. However, in order to distinguish between data of different types relating to the same entity, the skilled person would also have realized that a further parameter would be needed. Hence the skilled person would have added such an "entity code" in an obvious manner.

8.1.5 The appellant has argued that, if common identifiers were used in D1 for different objects, they would not be globally unique nor would they prevent collision. The board does not agree, since although a particular "unique number" or "entity code" may occur in a plurality of persistent keys, the combination of the two is unique.

8.1.6 The appellant has also argued that the skilled person implementing compound identifiers in D1 would, following the statement in D1 that compound identifiers are used if local data sources do not provide unique object identification (see D1, page 24, middle column, lines 1 to 12), only implement such compound identifiers where local data sources did not provide unique object identification. The board is not convinced by this argument that it would not be obvious to treat all databases in D1 in the same manner and implement object identifiers constructed from several properties of an individual uniformly.

8.1.7 Group II: features relating to efficient updating, i.e. each of the plurality of persistent keys comprising a version number, said version number incrementable each time any of said fields of said record on said central database linked to said persistent key comprising said version number is modified, the persistent key of the customer record corresponding to the persistent key of the same entity in the central database by having the same entity code and unique number, the system being arranged to identify differences between records of the customer database and those of the central database linked by a persistent key having the same entity code and unique number but different version number.

8.1.8 D3 shows that version numbers per se were known at the priority date, and their use to only update modified records is a usual matter of design. The skilled person would have sought to avoid unnecessary data transfers (such as the updating of unchanged records) without exercising inventive skill to optimise data transfer rates between the central and customer databases.

8.1.9 The appellant has argued that there is a synergy between the use of the "unique number" in group I and the use of the "version number" in group II, set out above, since the use of unique numbers and version numbers for the purpose of tracking changes across databases addressed a technical problem, such as identifying related data or outdated data, in a manner that was neither disclosed nor suggested in the cited prior art. The appellant has also argued that version numbers linked with unique numbers "represent entity". The board is not convinced by these arguments, since the version numbers do not represent an entity; persistent keys relating to data concerning the same individual, and therefore having the same "unique number", can nevertheless have different version numbers depending on when the data was last changed. The individual remains however the same. Moreover the effects of the unique numbers (identifying data relating to the same entity, meaning the same individual,) are independent of those of the version numbers (identifying outdated data); the appellant has not proved that there is a synergetic combinatorial effect.

8.1.10 Group III: features relating to an indication of key origin, i.e. each of the plurality of persistent keys comprises a check digit manipulable to check that said persistent key comprising said check digit originated from the central database.

8.1.11 It is common ground between the appellant and the board that the effects of this group of difference features are unrelated to those of groups I and II, there being no synergistic effect. The use of such a check digit as an indication of key origin is moreover a usual measure for ensuring data security. The appellant has not disputed this view.

8.1.12 Hence the subject-matter of claim 1 does not involve an inventive step, Article 56 EPC 1973.

8.2 First auxiliary request

8.2.1 It is common ground between the board and the appellant that figure 1 of D1 discloses partial records in different databases being combined; see data from "native database" and "Local data source 1 DBMS" being combined (by "Integrated schema x") and treated as equivalent to the data from the other local data sources. Moreover batch mode procedures for transferring data between databases are acknowledged as prior art on page 4, lines 23 to 30, of the description. Hence the added features relate to a usual embodiment of the central database as a virtual database and the necessary consequential changes. The appellant has not argued that the added features per se solve a technical problem in an inventive way.

8.2.2 Hence the features added to claim 1 with respect to claim 1 of the main request are unable to lend inventive step, Article 56 EPC 1973, to the claim.

8.3 Second auxiliary request

8.3.1 The features added to claim 1 with respect to that of the first auxiliary request require that only if the data in the customer database is outdated, this being identified by a comparison of the version numbers in the persistent keys in the request and the partial record in the central database, is it updated using data from said partial record in the central database. Hence the added features set out the implementation of data updating which the skilled person would implement in the realization of the system known from D1 in an obvious manner. As set out above in relation to the main request regarding the contribution to inventive step made by "group II" of the difference features of claim 1, the skilled person would have sought to avoid unnecessary data transfers (such as the updating of unchanged records) without exercising inventive skill to optimise data transfer rates between the central and customer databases.

8.3.2 Hence the features added to claim 1 with respect to claim 1 of the first auxiliary request are also unable to lend inventive step, Article 56 EPC 1973, to the claim.

9. Conclusion on the appellant's requests

Since the subject-matter of claim 1 according to the appellant's main and first and second auxiliary requests does not involve an inventive step, Article 56 EPC 1973, the appealed decision cannot be set aside.

ORDER

For these reasons it is decided that:

The appeal is dismissed.