The European Patent Office refused to grant a software patent on collecting and selling customer data. Here are the practical takeaways of the decision T 1039/13 (Updating information/EQUIFAX) of 11.12.2019 of Technical Board of Appeal 3.5.01:
Key takeaways
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 invention
This European patent application concerns a method involving an information supplier that gathers information about consumers and sells it to a number of information buyers. The information buyers may use the processed information for marketing purposes.
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. 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):
Here is how the invention is defined in claim 1:
-
Claim 1 (main request)
Is it technical?
Although the overall purpose of this application was to collect and sell customer data, claim 1 included a number of features concerning the database implementation. As summarized by the board:
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).
According to the board, claim 1 differed from the closest prior art 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.
The examining division had 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 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.
Thus, the key question and the point of dispute in this case was where to draw the line between the technical and non-technical features of the invention. Here is what the board said:
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.
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.
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.
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.
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.
Therefore, the board concluded that claim 1 lacks an inventive step and dismissed the appeal.
More information
You can read the whole decision here: T 1039/13 (Updating information/EQUIFAX) of 11.12.2019