T 0729/09 (Data linking using tokens/ACXIOM) of 9.4.2014

Summary of Facts and Submissions

I. The applicant (appellant) filed an appeal against the decision of the Examining Division refusing European patent application No. 00311258.8.

II. In the contested decision, reference was made to the document

D1: WO 99/06914 A (ACXIOM CORP) 11 February 1999.

The Examining Division decided that neither the main request nor the auxiliary request complied with Article 123(2) EPC. Under the heading "Obiter dicta" it was further noted that claim 9 of the main request was not clear and lacked an inventive step.

III. With the statement of grounds of appeal, the appellant filed a main request and an auxiliary request.

IV. Oral proceedings were appointed by the Board. In a communication accompanying the summons to oral proceedings, the Board expressed the provisional opinion that neither of the appellant's requests was allowable.

V. With a letter dated 7 March 2014, the appellant replaced the requests on file with a main request and first to fourth auxiliary requests.

VI. The oral proceedings took place on 9 April 2014. At the end of the oral proceedings, the chairman announced the decision of the Board.

VII. The appellant requested that the decision under appeal be set aside and that a patent be granted on the basis of the main request, or in the alternative on the basis of one of the first to fourth auxiliary requests. As a procedural request, the appellant requested that the case be remitted to the department of first instance for further prosecution.

VIII. Claim 9 of the main request reads as follows:

"A method of constructing a total customer view for an entity wherein an entity comprises one of a consumer, a business, a household, and an occupancy, the total customer view comprising an assimilation of relevant information for an entity, the method using a data processing system and a plurality of independent data stores encoding data elements pertaining to a plurality of said entities, wherein at least two of said data stores contain data elements pertaining to the same entity, each data element being tagged to a token (10) corresponding to the entity to which the data element pertains; each token (10) being unique over time and uniquely corresponding to a particular entity throughout time, characterized by the steps of:

(a) receiving a request for the total customer view (101) for an entity, comprising the steps of:

(i) providing access to the data processing system via a communications network;

(ii) receiving input data on the entity via the communications network, wherein the input data corresponds to at least one of the data elements;

(iii) matching the input data to one of the data elements; and

(iv) returning the token (10) tagged to the data element matched to the input data;

(b) matching the returned token (10) corresponding to the entity with the same token (10) tagged to data elements in the plurality of data stores;

(c) retrieving all data elements to which the token (10) corresponding to the entity is tagged; and

(d) forming the total customer view (101) based on the retrieved data elements."

IX. Claim 9 of the first auxiliary request reads as follows:

"A method of constructing a total customer view for a customer, the total customer view comprising an assimilation of relevant information for a customer, the method using a data processing system and a plurality of independent data stores encoding data elements pertaining to a plurality of said customers, wherein at least two of said data stores contain data elements pertaining to the same customer, each data element being tagged to a token (10) corresponding to the customer to which the data element pertains; each token (10) being unique over time and uniquely corresponding to a particular customer throughout time, characterized by the steps of:

(a) receiving a request for the total customer view (101) for a customer, comprising the steps of:

(i) providing access to the data processing system via a communications network;

(ii) receiving input data on the customer via the communications network, wherein the input data corresponds to at least one of the data elements;

(iii) matching the input data to one of the data elements; and

(iv) returning the token (10) tagged to the data element matched to the input data;

(b) matching the returned token (10) corresponding to the customer with the same token (10) tagged to data elements in the plurality of data stores;

(c) retrieving all data elements to which the token (10) corresponding to the customer is tagged; and

(d) forming the total customer view (101) based on the retrieved data elements."

X. Claim 9 of the second auxiliary request reads as follows:

"A method of constructing a total customer view for a customer, the total customer view comprising an assimilation of relevant information for a customer, the method using a data processing system and a plurality of independent data stores encoding data elements pertaining to a plurality of said customers, wherein at least two of said data stores contain data elements pertaining to the same customer, each data element being tagged to a token (10) corresponding to the customer to which the data element pertains; each token (10) being unique over time and uniquely corresponding to a particular customer throughout time, characterized by the steps of:

(a) receiving a request for the total customer view (101) for a customer, comprising the steps of:

(i) providing access to the data processing system via a communications network;

(ii) receiving input data on the customer via the communications network, wherein the input data corresponds to at least one of the data elements;

(iii) matching the input data to one of the data elements; and

(iv) returning the token (10) tagged to the data element matched to the input data;

(b) matching the returned token (10) corresponding to the customer with the same token (10) tagged to data elements in the plurality of data stores;

(c) retrieving all data elements to which the token (10) corresponding to the customer is tagged including:

(I) transmitting the token (10) corresponding to the customer from the data store to a repository (24), wherein a plurality of identification classes (30) are resident on the repository (24), each of said identification classes (30) is tagged with at least one token (10), and each of said identification classes (30) pertains to a particular customer;

(II) matching the token (10) to the identification class (30) that is tagged with that token (10);

(III) retrieving additional data from the matched identification class (30);

(IV) transmitting from the repository (24) to the data processing system the additional data, linked to the token (10) corresponding to the identification class (30) from which the additional data was retrieved; and

(d) forming the total customer view (101) based on the retrieved data elements including at least a portion of the additional data."

XI. Claim 9 of the third auxiliary request reads as follows:

"A method of constructing a total customer view for a customer, the total customer view comprising an assimilation of relevant information for a customer, the method using a data processing system and a plurality of independent data stores encoding data elements pertaining to a plurality of said customers, wherein at least two of said data stores contain data elements pertaining to the same customer, characterized by the steps of:

(a) creating the set of identification classes (30);

storing the set of identification classes (30) on a repository (24);

creating a set of tokens (10), wherein each of the tokens (10) uniquely matches to a particular one of the customers, and wherein the unique matching of each of the tokens (10) to a particular one of the customers corresponds to the customer throughout;

associating each of the identification classes (30) on the repository (24) with that one of the tokens (10) that is matched to the one of the customers to which each of the identification classes (30) pertains;

building a transfer file from at least one of the data storage systems, wherein said transfer file comprises a plurality of data elements, and wherein each of the plurality of data elements is resident on the respective data store;

transmitting the transfer file to the repository (24);

matching each of the data elements in the transfer file to the corresponding identification class (30);

tagging each of the data elements in the transfer file with at least one of the tokens (10) contained in the identification class (30) matched to that data element;

rebuilding the data store using the data elements and tokens (10) in the transfer file;

(b) receiving a request for the total customer view (101) for a customer, comprising the steps of:

(i) providing access to the data processing system via a communications network;

(ii) receiving input data on the customer via the communications network, wherein the input data corresponds to at least one of the data elements;

(iii) matching the input data to one of the data elements; and

(iv) returning the token (10) tagged to the data element matched to the input data;

(c) matching the returned token (10) corresponding to the customer with the same token (10) tagged to data elements in the plurality of data stores;

(d) retrieving all data elements to which the token (10) corresponding to the customer is tagged including:

collecting all data elements resident on the respective data store that are tagged with a particular token (10) by searching for the particular token (10) across the respective data store;

(I) transmitting the token (10) corresponding to the customer from the data store to a repository (24), wherein a plurality of identification classes (30) are resident on the repository (24), each of said identification classes (30) is tagged with at least one token (10), and each of said identification classes (30) pertains to a particular customer;

(II) matching the token (10) to the identification class (30) that is tagged with that token (10);

(III) retrieving additional data from the matched identification class (30);

(IV) transmitting from the repository (24) to the data processing system the additional data, linked to the token (10) corresponding to the identification class (30) from which the additional data was retrieved; and

(e) forming the total customer view (101) based on the retrieved data elements including at least a portion of the additional data."

XII. Claim 9 of the fourth auxiliary request reads as follows:

"A method of constructing a total customer view for a customer, the total customer view comprising an assimilation of relevant information for a customer, the method using a data processing system and a plurality of independent data stores encoding data elements pertaining to a plurality of said customers, wherein at least two of said data stores contain data elements pertaining to the same customer, each data element being tagged to a token (10) corresponding to the customer to which the data element pertains; each token (10) being unique over time and uniquely corresponding to a particular customer throughout time, characterized by the steps of:

(a) pushing update data from a repository (24) to a plurality of the data stores, on each of which reside a plurality of data elements, wherein the repository (24) contains a list of tokens (152) for each of said data stores, each of said lists (152) containing all of said tokens (10) maintained by each corresponding data stores [sic];

overlaying update data (78, 156) onto at least one of a plurality of identification classes (30) resident on the repository (24), wherein each of the identification classes (30) comprises at least one of name aliases, name change history, address aliases, address change history, alternate name and address spellings, and common name and address misspellings pertaining to a particular customer, and wherein each of the identification classes (30) is tagged with at least one token (10);

searching the token lists (152) to determine which lists contain the token (10) tagged to the at least one identification class (30) onto which update data (78, 156) was overlaid; and

transmitting the update data (78, 156) from the repository (24) to each of the data storage systems having token lists (152) containing the token (10) tagged to the at least one identification class (30) onto which update data was overlaid;

(b) receiving a request for the total customer view (101) for a customer, comprising the steps of:

(i) providing access to the data processing system via a communications network;

(ii) receiving input data on the customer via the communications network, wherein the input data corresponds to at least one of the data elements;

(iii) matching the input data to one of the data elements; and

(iv) returning the token (10) tagged to the data element matched to the input data;

(c) matching the returned token (10) corresponding to the customer with the same token (10) tagged to data elements in the plurality of data stores;

(d) retrieving all data elements to which the token (10) corresponding to the customer is tagged; and

(e) forming the total customer view (101) based on the retrieved data elements."

Reasons for the Decision

1. The appeal complies with the provisions referred to in Rule 101 EPC and is therefore admissible.

2. Request for remittal to the department of first instance

2.1 At the oral proceedings, after the Board had indicated that it intended to discuss the issue of inventive step first, the appellant requested that the case instead be remitted to the department of first instance for further prosecution. In support of this request, it submitted that the application had not been refused on the ground of lack of inventive step. The contested decision merely discussed inventive step by way of an obiter dictum. In addition, the subject-matter of the second to fourth auxiliary requests had never been a subject of discussion before the Examining Division.

2.2 Although it is correct that the Examining Division refused the application for lack of compliance with Article 123(2) EPC, the Board notes that under the EPC there is no absolute "right to two instances" in the sense that a party in all circumstances is entitled to have every aspect of its case examined by two instances (see e.g. decision J 6/98 of 17 October 2000, reasons 4). In addition, the issue of inventive step was discussed during the examination procedure. For example, in the annex to the summons to oral proceedings the Examining Division gave reasons why it considered the subject-matter of the then pending claim 1 to lack an inventive step in view of document D1.

2.3 The appellant is again correct in stating that the subject-matter of the second to fourth auxiliary requests has not been examined by the Examining Division, given that these requests comprise substantial amendments and were filed for the first time during the appeal procedure. However, these requests were not filed in response to prior art that the appellant had not already been made aware of during the first-instance proceedings. In such a case the Board considers the fact that newly filed requests have not been considered by the Examining Division to carry little weight as an argument in support of a request for remittal.

2.4 For these reasons, and considering the overall length of the present grant proceedings, the Board decided to exercise its discretion under Article 111(1) EPC and to proceed with the examination of inventive step.

3. The invention

The core idea of the present application is the use of "tokens" to link together data elements present in a plurality of independent data stores. Each token uniquely corresponds to a certain entity, for example a customer. All data elements pertaining to this entity are "tagged" with the token.

The claimed invention applies this idea to the construction of a "total customer view" for an entity, which is an "assimilation of relevant information" for that entity, based on the data elements pertaining to that entity. These data elements are retrieved by first determining the token corresponding to the entity, and then matching this token with tokens of the data elements in the plurality of data stores.

4. The independent claims of all requests refer to "a plurality of independent data stores encoding data elements (...)". At the oral proceedings, the appellant agreed that this feature may be read as "a plurality of data stores containing data elements". This is consistent with the wording of the further feature "wherein at least two of said data stores contain data elements (...)".

5. Main request - Article 56 EPC

5.1 For the assessment of inventive step, the Board prefers to focus on independent method claim 9.

5.2 Document D1, page 10, lines 7-19, discloses the use of "persistent keys" to link together information stored in a plurality of (remote) databases. The Board notes that, at least in the technical context of document D1, the term "database" implies the presence of a "data store". Document D1 explains on page 5, line 16, to page 6, line 6, that a "persistent key" is uniquely linked to an entity such as a particular individual, a business, an address, a piece of real property, or a vehicle. Using the persistent keys, the plurality of remote databases appears to applications requesting information as a single central database, which document D1 terms a "virtual central database" (page 10, lines 11-16).

Since this architecture is similar to that of the invention, the Board considers that document D1 represents a suitable starting point for the assessment of inventive step.

5.3 The appellant argued that the virtual central database of document D1 represented a different approach to that set out in the claims. In the invention, no central database needed to be referred to in order to obtain tokens and create the total customer view. The overhead of maintaining such a database was thereby avoided.

However, the virtual central database of document D1 is, as the term implies, virtual. It does not exist as one physical database, but as a collection of remote databases linked via the persistent keys. This does not differ from the approach taken in the present application.

5.4 At the oral proceedings, the appellant clarified its argument. Document D1 on page 10, lines 7-19, referred to a "central database manager" that used the persistent keys to link information together across physically remote databases. The invention did not require such a component and therefore had the advantages of being quicker, creating less overhead and consuming less bandwidth.

The Board notes however that claim 9 does not exclude the presence of such a "central database manager".

5.5 At the oral proceedings, the appellant further submitted that the databases of document D1 were not "independent data stores" as required by claim 9. The description of the present application on page 2, first full paragraph, explained how the term "independent data store" was to be understood.

The Board notes that the description on page 2, first full paragraph, refers to "entirely independent databases" containing redundant information about the customers of a business, but where no mechanism is available to accurately link all of the information concerning a particular customer. Since such a mechanism is available for the data stores of claim 9, these data stores are not "independent" databases within the meaning of page 2, first full paragraph. The appellant's proposed interpretation can therefore not be followed.

In the view of the Board, the term "independent data stores" is to be understood in accordance with original dependent claim 21 as referring to physically independent data stores. This term therefore covers the "physically remote databases" that together form the virtual central database disclosed in document D1 on page 10, lines 7-19.

5.6 The persistent keys of document D1

5.6.1 According to document D1, page 6, lines 8-13, persistent keys are divided into several fields of information, including an entity code, a randomly assigned unique number, and a version number. The entity code represents the type of entity which the associated data structure represents.

Document D1, page 6, lines 15-27, explains that the unique number is used to ensure that each persistent key is distinguishable from all other persistent keys. If two persistent keys match, it may be assumed that they are linked to records with matching, but not necessarily identical, data. This passage further explains that a data structure representing an individual and a data structure representing the address of that individual may be assigned the same unique number, the different entity codes for these two data structures ensuring that the overall persistent keys are different. A further example given is the use of the same unique number to match an individual to that individual's vehicle. It therefore follows that two persistent keys "match", i.e. relate to "matching" data, if they contain the same unique number.

Other passages of document D1 are less precise about the distinction between "persistent keys" and "unique numbers". In particular, the description on page 22, lines 1-10, refers to the "same" persistent keys being linked to data elements pertaining to the same entity, for example real property records and driving records pertaining to the same individual.

In the Board's view, the "persistent keys" of document D1, or more precisely the unique numbers they include, correspond to the "tokens" of the present invention.

5.6.2 Claim 9 specifies that each token is "uniquely corresponding to a particular entity throughout time". According to the appellant, this feature is based on page 11, first full paragraph, of the description as filed ("a permanent token will be assigned that will be used to link data pertaining to that entity for all time").

In the communication accompanying the summons, the Board expressed doubt as to whether this feature was originally disclosed and noted that the first full paragraph of page 11 of the description rather appeared to confirm that the correspondence between tokens and entities might change over time. Indeed, a temporary token might be replaced by a permanent token, two or more tokens might be combined into a single token, and a token might be split into two different tokens. The latter possibility was understood to refer to a case in which it was discovered that two different entities had been mistakenly considered to be one and the same entity. To correct the mistake, either the token originally assigned to the mixed-up entity was retired and two new tokens were assigned to the two different entities, or the token originally assigned to the mixed-up entity was reassigned to one of the two entities and a new token was assigned to the other.

In response, the appellant confirmed that this passage referred to instances where there was confusion as to an entity, such a single entity being given two tokens or two entities being mistakenly considered one and being given a single token. The appellant submitted that the resultant action taken did not affect the token assignment to an entity. In the case of merging of tokens, one token was retired and both tokens would still have pertained to the entity for all time. In the case of splitting, while in one embodiment the existing token might continue to be used, it was still in respect of that entity to which it had been assigned.

However, the Board considers that once a token is retired it no longer "corresponds" to an entity within the meaning of the claim. Indeed, it is no longer "tagged" to data elements and no longer used to retrieve data elements. Similarly, the splitting of a token into two tokens in response to a discovery that two entities have mistakenly been considered to be one and the same entity changes the correspondence between the original token and the original entity within the meaning of the claim.

For these reasons, the Board is of the view that when interpreting the feature "uniquely corresponding to a particular entity throughout time" in the context of page 11, first full paragraph, the words "throughout time" do not distinguish the claimed tokens from the permanent keys of document D1. The Board also notes that a more literal interpretation would not make much sense, as it would essentially require looking into the future in order to determine whether a particular token pertains to an entity "throughout time".

5.6.3 The appellant argued that in document D1 multiple persistent keys might be assigned to an entity over time. According to page 6, lines 29-30, the version number in each persistent key at a data vendor was incremented each time a field in the record linked to the persistent key was changed.

However, the Board considers that it is the unique number that determines the identity of the "persistent key", see point 5.6.15.6.1 above. Only one such unique number is assigned to an entity.

5.6.4 The appellant further pointed out that document D1 on page 6, lines 20-27, disclosed that the same unique number could be assigned to data structures representing different entities with related information. For example, the same unique number could be assigned to an individual and to the address for that individual.

The Board sees no inconsistency with the tokens of the claim. A data element representing the address of a particular individual certainly pertains to that individual. The claim therefore requires it to be tagged to the token corresponding to that individual.

5.7 As explained in point 5.25.2 , document D1, page 10, lines 7-19, discloses a virtual central database comprising a plurality of (remote) data stores, the information stored in the data stores being linked together using persistent keys. Document D1, page 21, line 28, to page 22, line 11, confirms that in each remote data store persistent keys are tagged to ("linked to") data elements, and that the persistent keys will be the same for data elements pertaining to the same entity.

5.8 The entities of document D1 may be individuals and/or businesses, see page 5, line 16, to page 6, line 6. The entities of document D1 hence fall within the scope of the entities of claim 9, which are defined as comprising one of a consumer, a business, a household and an occupancy.

5.9 The Board considers it implicit that the plurality of physically remote data stores and the central database manager forming the virtual central database mentioned in document D1 on page 10, lines 7-19, are connected via a communications network and that access to the virtual central database is provided over a communications network.

5.10 Document D1 does not explicitly disclose the use of the virtual central database to construct a "total customer view" for an entity in accordance with claim steps (a)-(d), the claim defining a total customer view as comprising "an assimilation of relevant information for a customer".

However, the virtual central database of document D1 allows all data elements pertaining to a particular entity to be retrieved on the basis of the persistent key corresponding to that entity. The Board considers it an obvious use of such a database to query the database for a particular entity using certain "input data on the entity" and to retrieve all the data elements relating to said entity for assimilation, for example on a display, resulting in a "total customer view" for the entity.

In the context of document D1, this query would result in identifying the "persistent key" corresponding to the customer based on the input data and using the persistent key to obtain all data records corresponding to the entity from the plurality of remote data stores.

5.11 Claim 9 specifies in substep (iv) of step (a) that the "token" is "returned" and in step (b) that the "returned token" is matched with the tokens tagged to the data elements in the plurality of data stores. In the communication accompanying the summons, the Board noted that it appeared to be unclear which systems or entities performed the various steps listed in the claim. In response, the appellant submitted that claim 9 was clear to the skilled reader in terms of the required functions needed to implement the invention and that the skilled reader would appreciate that the entities that performed those functions would be an implementation choice. The term "returned" was a term regularly used in the context of computer systems, and the skilled reader would understand that it was merely used to refer to the passing of data. It might be that the data was passed to another physical entity. It might also be that the data was simply returned to another routine in the same program.

Accordingly, the Board considers that these features do not further distinguish the claimed subject-matter from what is disclosed in document D1.

5.12 The above-mentioned obvious use of the virtual central database of document D1 hence falls within the scope of claim 9. The subject-matter of claim 9 of the main request therefore does not involve an inventive step (Articles 52(1) and 56 EPC).

6. First auxiliary request - Article 56 EPC

Claim 9 of the first auxiliary request differs from claim 9 of the main request in that "entity" is replaced by "customer". Since document D1 on page 2, lines 3-17, anticipates the collection of data on customers, this further limitation cannot support an inventive step.

The subject-matter of claim 9 of the first auxiliary request hence lacks an inventive step (Articles 52(1) and 56 EPC).

7. Second auxiliary request - Article 56 EPC

7.1 Claim 9 of the second auxiliary request differs from claim 9 of the first auxiliary request in that the step of retrieving all data elements to which the token corresponding to the customer is tagged includes:

- transmitting the token corresponding to the customer from the data store to a repository, wherein a plurality of identification classes are resident on the repository, each of said identification classes is tagged with at least one token, and each of said identification classes pertains to a particular customer;

- matching the token to the identification class that is tagged with that token;

- retrieving additional data from the matched identification class;

- transmitting from the repository to the data processing system the additional data, linked to the token corresponding to the identification class from which the additional data was retrieved,

and in that the final step of forming the total customer view is based on the "retrieved data elements including at least a portion of the additional data".

7.2 At the oral proceedings, the appellant submitted that document D1 was silent on additional data and identification classes. The inclusion in the total customer view of the additional data resulted in a more accurate customer view.

7.3 The claimed repository stores data in the form of "identification classes". Each identification class pertains to a particular customer and is tagged with the token corresponding to that customer. The repository can hence be regarded as an independent data store containing data elements in the form of identification classes comprising "additional data".

Viewed in this way, the steps added to claim 9 merely specify that one of the independent data stores is labelled "repository" and that its data elements are labelled "identification classes" and store "additional data".

Since the claim does not define any specific technical characteristic or use of the "identification classes" and the "additional data", these limitations are of a non-technical cognitive nature and therefore do not contribute to an inventive step. Indeed, whether the inclusion of the "additional data" in the total customer view results in a "more accurate" customer view depends on the content of this additional data and its perception by the user.

7.4 The subject-matter of claim 9 of the second auxiliary request hence lacks an inventive step (Articles 52(1) and 56 EPC).

8. Third auxiliary request - Article 56 EPC

8.1 Claim 9 of the third auxiliary request differs from claim 9 of the second auxiliary request in a number of steps essentially defining how the data elements in an independent data store are initially "tagged" with tokens:

- creating the set of identification classes;

- storing the set of identification classes on a repository;

- creating a set of tokens, wherein each of the tokens uniquely matches to a particular one of the customers, and wherein the unique matching of each of the tokens to a particular one of the customers corresponds to the customer throughout;

- associating each of the identification classes on the repository with that one of the tokens that is matched to the one of the customers to which each of the identification classes pertains;

- building a transfer file from at least one of the data storage systems, wherein said transfer file comprises a plurality of data elements, and wherein each of the plurality of data elements is resident on the respective data store;

- transmitting the transfer file to the repository;

- matching each of the data elements in the transfer file to the corresponding identification class;

- tagging each of the data elements in the transfer file with at least one of the tokens contained in the identification class matched to that data element;

- rebuilding the data store using the data elements and tokens in the transfer file.

These features are based on originally filed independent claim 10 and are further supported by the description as filed on page 20, second paragraph, to page 23, first full paragraph.

8.2 Document D1, page 7, first and second full paragraphs, discloses a process for "enhancing" the records in a data customer's database with persistent keys. First, a computer-readable medium containing the entire set of all persistent keys matched with a key field, for example a "last name" field, is delivered to a data customer. The records of the data customer's database are then matched with the key fields. The associated persistent key for each matched key field is copied onto the data customer's database and linked to the matched record.

The Board considers that this passage discloses the creation at an implicit repository of a set of identification classes (records with a "last name" key field) and a set of associated tokens (persistent keys).

8.3 The features added to claim 9 further distinguish the claimed invention from the method of document D1 in two aspects.

8.3.1 Firstly, these claim features relate to the initial tagging of the data elements of an independent data store that is being linked up with other independent data stores. The independent data stores of the claim correspond to the physical databases linked up to form the virtual central database discussed in document D1 on page 10, lines 7-19 (see point 5.25.2 above). The "data customer's database" referred to in document D1 on page 7, first and second full paragraphs, is not one of these databases.

However, the data elements of the physical databases forming the virtual central database of document D1 are all tagged with tokens (persistent keys). In order to add a further physical database to the virtual central database, it is necessary to tag each data element of this further physical database with an appropriate token. The Board therefore considers that the skilled person reading document D1 would obviously consider applying a "data enhancement" process to physical databases that are to become part of the virtual central database.

8.3.2 Secondly, according to claim 9 the tagging of data elements with tokens takes place at a repository storing the set of identification classes. To this end, a "transfer file" comprising data elements of the data store is built and transmitted to the repository (for example by means of electronic storage media such as magnetic tape or disks, see the description on page 23, first full paragraph). At the repository, the data elements in the transfer file are matched to identification classes and tagged with the associated tokens. The data elements and tokens in the transfer file are then used to "rebuild" the data store. Document D1 on the other hand proposes performing the tagging of data elements with tokens at the data customer's database on the basis of identification classes and associated tokens transmitted by means of a computer-readable medium to the data customer's database.

In the Board's judgment, the choice between performing the tagging at a repository containing the identification classes by essentially transferring the content of the data store to the repository, or at the data store by essentially transferring the contents of the repository to the data store, is a choice between obvious alternatives. Indeed, the present application does not disclose any specific technical advantage arising out of the choice to perform tagging at the repository, let alone a surprising technical advantage.

8.4 The subject-matter of claim 9 of the third auxiliary request hence lacks an inventive step (Articles 52(1) and 56 EPC).

9. Fourth auxiliary request - Article 56 EPC

9.1 Claim 9 of the fourth auxiliary request differs from claim 9 of the first auxiliary request in the addition of the following steps:

- pushing update data from a repository to a plurality of the data stores, on each of which reside a plurality of data elements, wherein the repository contains a list of tokens for each of said data stores, each of said lists containing all of said tokens maintained by each corresponding data stores [sic];

- overlaying update data onto a least one of a plurality of identification classes resident on the repository, wherein each of the identification classes comprises at least one of name aliases, name change history, address aliases, address change history, alternate name and address spellings, and common name and address misspellings pertaining to a particular customer, and wherein each of the identification classes is tagged with at least one token;

- searching the token lists to determine which lists contain the token tagged to the at least one identification class onto which update data was overlaid; and

- transmitting the update data from the repository to each of the data storage systems having token lists containing the token tagged to the at least one identification class onto which update data was overlaid.

9.2 These features are based on originally filed independent claim 32 and are further supported by page 36, line 3, to page 37, line 7, of the description as filed and by Figure 16. The Board notes that these passages relate to an aspect of the invention that, although based on the same underlying architecture of independent data stores linked together through tokens, is unrelated to the method for "constructing a total customer view" as disclosed on page 29, line 13, to page 32, line 10, of the description as filed. The steps added to claim 9 hence are not part of the "method of constructing a total customer view". Instead, they define a separate mechanism through which data elements stored in a data store are updated with new information.

9.3 At the oral proceedings, it was discussed how the step of "pushing update data from a repository to a plurality of data stores" related to the steps of "overlaying", "searching" and "transmitting". It was agreed that these steps had to be understood in line with original claim 32, which defines a "method of pushing update data" comprising steps of "overlaying", "searching" and "transmitting".

9.4 At the oral proceedings it was further discussed what kind of "update data" was meant. It was suggested that the update data could be data relating to token maintenance as discussed on page 11, first full paragraph, of the description as filed and under point 5.6.25.6.2 above. However, if the update data related to a change in the correspondence between tokens and entities, this would be incompatible with the claimed use of "token lists" to determine the data stores to which update data is to be transmitted.

9.5 According to the description on page 36, lines 9 and 10, the update data is "additional information" about a particular customer. The Board therefore interprets the features added to claim 9 of the fourth auxiliary request in line with point 7.37.3 above. The "repository" is an independent data store which stores data in the form of "identification classes", each identification class comprising cognitive "additional data" pertaining to a particular customer and being tagged with the token corresponding to that customer. The added features specify that an update to the additional information is applied to ("overlayed onto") an identification class associated with a particular token and then transmitted to those other independent data stores which, according to token lists present on the repository, maintain data elements associated with the same token. For the reasons given under point 7.37.3 , the features defining the information content of the data elements contained in the "repository" data store are considered non-technical.

9.6 The general concept of updating data elements with new information is well-known in the art. As explained at the oral proceedings, the Board further considers that the skilled person is well aware of the possibilities of "pulling" and "pushing" such updates. In the case of update "pulling", the entity to be updated issues a request for update information to the entity providing the update information. In the case of update "pushing", the updated information is instead provided at the initiative of the entity providing the update information.

9.7 Document D1 discloses on page 11, last paragraph, that a data customer's database may issue an update request, thereby "pulling" updates. This request includes the list of persistent keys that correspond to each record in the data customer's database. It is implicit that only updates to records corresponding to persistent keys present on this list will be transmitted to the data customer's database.

9.8 The Board considers that the skilled person, starting from document D1 and wishing to implement the "pushing" of update data from one independent data store to a plurality of other independent data stores, would apply the same technique of using a list of persistent keys (i.e. tokens) for each of said data stores in order to determine to which data stores update data is to be transmitted. This implies that such lists must be available to, for example stored on, the data store performing the push operation. Applying this push technique to the updated additional information in the "repository" data store (see point 9.59.5 ), the skilled person would arrive at the subject-matter of claim 9 without the exercise of inventive skill.

9.9 The subject-matter of claim 9 of the fourth auxiliary request hence likewise does not involve an inventive step within the meaning of Articles 52(1) and 56 EPC.

10. Since none of the requests on file is allowable, the appeal is to be dismissed.

Order

For these reasons it is decided that:

The appeal is dismissed.