T 1039/13 (Updating information/EQUIFAX) of 11.12.2019

Summary of Facts and Submissions

I. This is an appeal against the decision of the examining division to refuse the European patent application No. 02792279.8 for lack of inventive step (Article 56 EPC).

II. The examining division considered that the invention in claim 1 was an obvious implementation of a business-related process on a notorious networked computer system. Furthermore, in an "obiter dictum", the subject-matter of claim 1 was found to lack an inventive step over D6 - an extract (chapters 10 and 12) from the book Ponniah P.: "Data Warehouse Fundamentals: A Comprehensive Guide for IT Professionals" September 2001, John Wiley & Sons, NY.

III. The applicant (appellant) appealed and requested that the decision of the examining division be set aside and that a patent be granted on the basis of the main request or the first or second auxiliary request, all filed with the statement of grounds of appeal. In support of its arguments on inventive step, the appellant cited further pages from the book above.

IV. In the communication accompanying the summons to oral proceedings, the Board, apart from having doubts whether high-level database design was technical, tended to consider that the invention as defined in the main request, and the first and second auxiliary requests, lacked an inventive step over D6.

V. In a letter of reply, the appellant submitted further arguments in favour of inventive step.

VI. In a further letter, the appellant informed the Board that nobody would attend the oral proceedings.

VII. The oral proceedings were held in the absence of the appellant. It was announced that a decision would be issued in writing.

VIII. Claim 1 of the main request reads:

A computer method for managing and updating massive amounts of information relating to at least one event generating entity (106A-ZZ, 402) and contained in a networked computer system having:-

a) an information supplier (102, 206, 306) having at least one memory device to store, in an information supplier universe database file UF (104, 310), a plurality of customer database files CF (120, 204, 304), each having a plurality of record entries (420);

b) at least one information customer (108A-N,202,410a) computer having at least one memory device to store a customer data file CF (120a-n, 204);

c) an Internet, wireless communication link, or other real-time communication link operable between the customer computer and the supplier computer;

wherein the information supplier (102, 206, 306) computer is organised and arranged to:

i) receive raw data corresponding to at least one event generating entity (106, 402);

ii) process the raw data and generate at least one processed record entry (420);

iii) associate each processed record entry with a unique universe identifier UUID (404);

iv) store in at least one memory device a plurality of processed record entries (420) for the universe database file UF (104, 210, 310);

characterised in that the information supplier (102, 206, 306) computer is further organised and arranged to:

v) receive a transfer customer database file CF (120, 204, 304) from an information customer (108A-N,202, 410a) using storage devices or via any communication means, including wired or wireless communications such as satellite transmissions and the Internet;

vi) store in at least one memory device a plurality of transferred customer database files CF (120a-n, 204, 304);

vii) assign a unique customer identifier UCID (412) for each record entry contained in the transferred customer database files CF (120, 204, 304);

viii) compare the content of the transferred customer database files CF (120, 204, 304) with the content of the universe database file UF (104, 210, 310);

ix) generate a conversion table CT (218, 318, 440) providing a mapping between the unique customer identifiers UCID's (412) and a corresponding set of unique universal identifiers UIID's (404) contained in the universe database file UF (104, 210, 310);

x) update a portion of at least one record entry in a transferred customer database file CF (212) with information contained in the processed record entry associated with the unique universe identifier UUID (404) corresponding to the unique customer identifier UCID (412) associated with the at least one record entry; and,

xi) deliver an updated transfer customer database file to the information customer via communication means.

IX. Claim 1 of the first auxiliary request reads:

A computer method for managing and updating massive amounts of information relating to at least one event generating entity (106A-ZZ, 402) and contained in a networked computer system having:-

a) an information supplier (102, 206, 306) computer having at least one memory device to store, in an information supplier universe database file UF (104, 310), a plurality of customer database files CF (120, 204, 304), each having a plurality of record entries (420);

b) at least one information customer (108A-N, 202, 410a) computer having at least one memory device to store a customer database file CF (120a-n, 204);

c) an Internet, wireless communication link, or other real-time communication link operable between the customer computer and the supplier computer;

wherein the information supplier (102, 206, 306) computer is organised and arranged to:

i) receive raw data corresponding to at least one event generating entity (106, 402);

ii) process the raw data and generate at least one processed record entry (420);

iii) associate each processed record entry with a unique universe identifier UUID (404);

iv) receive a transfer customer database file CF (120, 204, 304) from an information customer (108A-N,202, 410a) using storage devices or via any communication means, including wired or wireless communications such as satellite transmissions and the Internet;

v) store in at least one memory device a plurality of transferred customer database files CF (120a-n, 204, 304);

vi) assign a unique customer identifier UCID (412) for each record entry contained in the transferred customer database files CF (120, 204, 304);

vii) compare the content of the transferred customer database files CF (120, 204, 304) with the content of the universe database file UF (104, 210, 310);

viii) generate a conversion table CT (218, 318, 440) providing a mapping between the unique customer identifiers UCID's (412) and a corresponding set of unique universal identifiers UUID's (404) contained in the universe database file UF (104, 210, 310;

ix) update a portion of at least one record entry in a transferred customer database file CF (212) with information contained in the processed record entry associated with the unique universe identifier UUID (404) corresponding to the unique customer identifier UCID (412) associated with the at least one record entry; and,

x) deliver an updated transfer customer database file CF to the information customer via communication means;

characterized in that the information supplier (102, 206, 306) computer is organised and arranged to:

xi) assign a set of unique customer identifiers UCID's (412) for each record entry contained in the customer database files CF (120, 204, 304);

xii) assign a different set of unique customer identifiers UCID's (412) per information customer (108a-n);

xiii) associate the unique customer identifier sets with corresponding unique universe identifiers (404); and

xiv) generate the conversion table (218, 318, 440) to provide a mapping unique universe identifies UUID (404) and each of a set of unique customer identifiers UCID (412) assigned to each of the plurality of customer database files CF.

X. Claim 1 of the second auxiliary request reads:

A computer method for managing and updating massive amounts of information relating to at least one event generating entity (106A-ZZ, 402) and contained in a networked computer system having:

a) an information supplier (102, 206, 306) computer having at least one memory device to store, in an information supplier universe database file UF (104, 310), a plurality of customer database files (120, 204, 304), each having a plurality of record entries (420);

b) at least one information customer (108A-N,202, 410a) computer having at least one memory device to store a customer database file CF (120a-n, 204);

c) an Internet, wireless communication link, or other real-time communication link operable between the customer computer and the supplier computer;

wherein the information supplier (102, 206, 306) computer is organised and arranged to:

i) receive raw data corresponding to at least one event generating entity (106, 402);

ii) process the raw data and generate at least one processed record entry (420);

iii) associate each processed record entry with a unique universe identifier UUID (404);

v) receive a transfer customer database file CF (120, 204, 304) from an information customer (108A-N,202, 410a) using storage devices or via any communication means, including wired or wireless communications such as satellite transmissions and the Internet;

v) store in at least one memory device a plurality of transferred customer database files CF (120a-n, 204, 304);

vi) assign a unique customer identifier UCID (412) for each record entry contained in the transferred customer database files CF (120, 204, 304);

vii) compare the content of the transferred customer databases CF (120, 204, 304) with the content of the universe database file UF (104, 210, 310);

viii) generate a conversion table CT (218, 318, 440) providing a mapping between the unique customer identifiers UCID's (412) and a corresponding set of unique universal identifiers UIID's (404) contained in the universe database file UF (104, 210, 310);

ix) update a portion of at least one record entry in a transferred customer database file CF (212) with information contained in the processed record entry associated with the unique universe identifier UUID (404) corresponding to the unique customer identifier UCID (412) associated with the at least one record entry; and,

x) deliver an updated transfer customer database file CF to the information customer via communication means;

characterized in that:

xi) a customer transfer database file CF (120, 204, 304) includes a subset of the information included in the information supplier universe database file UF (104, 310); and,

xii) the information customer (108A-N, 202, 410a) identifies the content to be delivered in a customer transfer database file CF according to the information customer's specifications.

Reasons for the Decision

1. Background

1.1 The invention concerns a method involving an information supplier that gathers information about consumers and sells it to a number of information buyers ("information customers" in claim 1). The information buyers may use the processed information for marketing purposes (see the published application at page 1, lines 17 to 25).

Looking at Figure 1 of the published application, the information supplier (102) stores the consumer data in a "universe database file" (UF, 104). Each record in the UF has a "unique universe identifier" (UUID), which is stable over time (page 3, lines 10 to 12). The information buyers (108A-N), on their end, store information about their existing or potential customers in "customer database files" (CF, 120a-n). The records in the CFs are indexed by a "unique customer identifier" (UCID).

2. Main request, claim 1

2.1 Claim 1 of the main request covers the initial transfer of information from the information supplier to an information buyer as depicted in Figure 2 of the published application. At this stage, the information buyer's CF is essentially a list of customers that it presumably already knows about, but whose records do not have UCIDs assigned to them (page 7, lines 18 to 19).

The information buyer sends the list of customers to the information supplier in a "transfer customer database file". The information supplier assigns a UCID to each entry in the list, compares the list of customers with the information stored in the UF, and updates the customer database file (page 7, line 31 to page 8, line 8). The information supplier may, for example, add information about the customers' income and debts. The information supplier also generates a conversion table (CT) that provides a mapping between the UCIDs and the UUIDs. The CT will be used for mapping the records in the CF to the records in the UF the next time the CF is to be updated (Figure 3; page 8, lines 18 to 28).

3. Main request, inventive step (Article 56 EPC)

3.1 D6 discloses a database system comprising a central data warehouse that contains data (e.g. customer data) imported from a plurality of different source systems. The data warehouse uses UUIDs (system-generated "surrogate keys") as primary keys. The source systems have different keys ("production keys").

3.2 The examining division mapped the data warehouse in D6 to the information supplier's UF in claim 1. The Board agrees that this is a reasonable mapping.

The Board furthermore agrees with both the examining division and the appellant that the source systems in D6 cannot be mapped directly to the CFs in claim 1. In D6, the central data warehouse imports data from the source systems, whereas in claim 1, the information supplier provides information to the information buyers.

An information buyer or user that wants to obtain information about (potential) customers from the data warehouse in D6 would have to query the database. The query would have to be in an appropriate format, taking into account the structure of the database tables, and it would necessarily include a list of customers. The response from the database would be the requested information in some format.

3.3 The subject-matter of claim 1 of the main request differs from D6 in that the information buyer provides a database file to the information supplier, which, in turn, assigns unique identifiers (UCIDs) to the records in the file and updates them. The identifiers used for the customer database file are different from the UUIDs used in the central database. The information supplier also creates a conversion table between the UCIDs and the UUIDs.

3.4 The examining division found that the provision of customer database files by the information buyer, as well as the updating of those files by the information supplier, were non-technical business requirements. The skilled person would have implemented those requirements on the system in D6 using the teachings available in D6 to generate and map the identifiers.

3.5 The appellant argued that the invention increased the security of the information supplier's database by limiting the extent to which it was accessed by outside systems, whilst also increasing the efficiency of information retrieval at the client end, because the CF could be hosted on the information buyer's systems.

The appellant furthermore argued that the skilled person would not have considered teachings in D6 relating to information acquisition (the import of data from the source system to the data warehouse) for the purpose of information delivery (the provision of information to the information buyers).

3.6 Thus, the key question and the point of dispute in this case is where to draw the line between the technical and non-technical features of the invention. This is crucial, because the non-technical features are given to the skilled person as a set of requirements to implement. Since they are part of the problem rather than the solution, they cannot contribute to inventive step (see T 641/00 - Two identities/COMVIK).

Drawing the line between what is technical and not technical requires careful consideration of all the features of the invention and their associated effects.

In decision T 1463/11 (Universal merchant platform/CardinalCommerce), the "notional business person" was used as a tool for drawing the line between the non-technical requirements and the technical implementation of those requirements. The business person can require things such as "Move the money from the payer's account to the payee's account", but the choice of technical means for carrying out the business requirements is normally left to the technical skilled person.

3.7 The Board is not persuaded by the appellant's arguments that the alleged increased security is a technical effect that counts towards inventive step. It is rather a question of what and how much information to give away. That is something for the business person.

The Board agrees with the examining division that the invention is to a large extent a consequence of the relationship between the information supplier and the (plurality of) information buyers. The information supplier sells data to the information buyers. It wants to retain control over its data as much as possible. That is good for business. The information buyer keeps information about its customers or potential new customers. That is part of their business.

The business person might say: We (the information supplier) do not want to give away more information than necessary, and we want to control what information we give away. Give us a list of customers and we will update the records with information that we have about those customers. Thus, those are non technical requirements that are given to the skilled person.

3.8 It follows directly from the business requirements that the customer list be provided to the information supplier in some appropriate format, and that the information supplier update the file.

The Board also has doubts whether assigning a unique identifier (a key) to the customer records is technical. The business person could require: "We must be able to identify each customer." In any case, the use of unique identifiers (primary keys) to identify records in a database was standard practice since long before the priority date.

The skilled person implementing the business requirements would assign keys to the customer records. Whether to use the same keys as in the central database or different keys is, from a technical point of view, a matter of convenient choice. In view of the non technical requirement "Don't give away information", using different keys would be the natural choice.

3.9 Furthermore, the keys used in the source systems in D6 are different from the keys in the central data warehouse. The skilled person would not see this as a teaching limited to data acquisition. On the contrary, he would recognise that the same arrangement could be used for the central database and the information buyer's customer database.

3.10 Also, it is evident to the skilled person that, if different keys are used, a conversion between them is necessary. That is also known from D6.

3.11 For these reasons, the Board concludes that the skilled person would have arrived at the invention as defined in claim 1 of the main request in an obvious manner starting from D6. Therefore, the subject-matter of claim 1 lacks an inventive step (Article 56 EPC).

4. First auxiliary request

4.1 The first auxiliary request looks rather different from the main request. This is due to the rearrangements and renumbering of features. In terms of substance, claim 1 of the first auxiliary request essentially adds that a different set of unique customer identifiers UCIDs is assigned per information customer (information buyer).

4.2 In the Board's view, the reason for having a separate set of keys for each information buyer is administrative rather than technical. It comes from the business relationship between the central information supplier and a plurality of information buyers. The information supplier might want to separate the buyers. Therefore, the additional feature in claim 1 of the auxiliary request does not contribute to inventive step. Consequently, the first auxiliary request lacks an inventive step (Article 56 EPC) for the same reasons as the main request.

5. Second auxiliary request

5.1 The second auxiliary request adds that the CF includes a subset of the information included in the UF and that the information buyer specifies the content to be delivered in the transfer database file according to the information buyers specification.

5.2 In the Board's view, this does not establish an inventive step. Specifying the information to be delivered is part of the non-technical requirement to buy certain information. The business person might say: "We want credit information about these customers". Furthermore, the user in D6 would need to specify the information that he wants to retrieve from the data warehouse. Indeed, the purpose of a database is to allow the user to retrieve specified information. The specification or query needs to be transmitted to the central database, and putting it in the transfer database file would have been an obvious option.

Order

For these reasons it is decided that:

The appeal is dismissed.